* Re: [PATCH 2/6] drm/bridge: anx6345: Clean up error handling in probe()
From: Laurent Pinchart @ 2020-02-20 13:52 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, Neil Armstrong, David Airlie, Linus Walleij,
dri-devel, Andrzej Hajda, Thierry Reding, Sam Ravnborg,
Stephen Rothwell, Samuel Holland, Heiko Stuebner, Chen-Yu Tsai,
Icenowy Zheng, Stephan Gerhold, Jonas Karlman, Torsten Duwe,
Rob Herring, Maxime Ripard, linux-arm-kernel, Jernej Skrabec,
linux-kernel, Mark Brown, Daniel Vetter
In-Reply-To: <20200220083508.792071-3-anarsoul@gmail.com>
Hi Vasily,
Thank you for the patch.
On Thu, Feb 20, 2020 at 12:35:04AM -0800, Vasily Khoruzhick wrote:
> devm_regulator_get() returns either a dummy regulator or -EPROBE_DEFER,
> we don't need to print scary message in either case.
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> index 0d8d083b0207..0204bbe4f0a0 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -713,17 +713,13 @@ static int anx6345_i2c_probe(struct i2c_client *client,
>
> /* 1.2V digital core power regulator */
> anx6345->dvdd12 = devm_regulator_get(dev, "dvdd12");
> - if (IS_ERR(anx6345->dvdd12)) {
> - DRM_ERROR("dvdd12-supply not found\n");
> + if (IS_ERR(anx6345->dvdd12))
> return PTR_ERR(anx6345->dvdd12);
> - }
There could be other errors such as -EBUSY or -EPERM. The following
would ensure a message gets printed in those cases, while avoiding
spamming the kernel log in the EPROBE_DEFER case.
if (IS_ERR(anx6345->dvdd12)) {
if (PTR_ERR(anx6345->dvdd12) != -EPROBE_DEFER)
DRM_ERROR("Failed to get dvdd12 supply (%d)\n",
PTR_ERR(anx6345->dvdd12));
return PTR_ERR(anx6345->dvdd12);
}
But maybe it's overkill ? With or without that change (for the second
regulator below too),
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> /* 2.5V digital core power regulator */
> anx6345->dvdd25 = devm_regulator_get(dev, "dvdd25");
> - if (IS_ERR(anx6345->dvdd25)) {
> - DRM_ERROR("dvdd25-supply not found\n");
> + if (IS_ERR(anx6345->dvdd25))
> return PTR_ERR(anx6345->dvdd25);
> - }
>
> /* GPIO for chip reset */
> anx6345->gpiod_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
--
Regards,
Laurent Pinchart
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [Ask for Help]LBR usage in kernel
From: 陈弋玺 @ 2020-02-20 13:53 UTC (permalink / raw)
To: linux-kernel, linux-x86_64
Hi experts,
We want to try to retreive callchains of some perf events from LBR rather than frame stacks, as the information in frame stacks would be optimized by compiler. After investigating the usage of LBR in kernel, we found that LBR can only operated via Intel PMU, that means for now only callchains of hardware events can be retrieved from LBR. Is that correct?
If yes, I wonder if callchains of other perf events(eg. tracepoint, software events) can be retrieved from LBR? Or only callchains of events on PMU can be retrieved from LBR as there are some hardware restrictions?
Thanks for any help you can offer!
Best Regards,
Yixi Chen
^ permalink raw reply
* Re: [PATCH 2/6] drm/bridge: anx6345: Clean up error handling in probe()
From: Laurent Pinchart @ 2020-02-20 13:52 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Mark Rutland, Neil Armstrong, David Airlie, dri-devel,
Andrzej Hajda, Thierry Reding, Sam Ravnborg, Stephen Rothwell,
Samuel Holland, Heiko Stuebner, Chen-Yu Tsai, Icenowy Zheng,
Stephan Gerhold, Jonas Karlman, Torsten Duwe, Rob Herring,
Maxime Ripard, linux-arm-kernel, Jernej Skrabec, linux-kernel,
Mark Brown
In-Reply-To: <20200220083508.792071-3-anarsoul@gmail.com>
Hi Vasily,
Thank you for the patch.
On Thu, Feb 20, 2020 at 12:35:04AM -0800, Vasily Khoruzhick wrote:
> devm_regulator_get() returns either a dummy regulator or -EPROBE_DEFER,
> we don't need to print scary message in either case.
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> index 0d8d083b0207..0204bbe4f0a0 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -713,17 +713,13 @@ static int anx6345_i2c_probe(struct i2c_client *client,
>
> /* 1.2V digital core power regulator */
> anx6345->dvdd12 = devm_regulator_get(dev, "dvdd12");
> - if (IS_ERR(anx6345->dvdd12)) {
> - DRM_ERROR("dvdd12-supply not found\n");
> + if (IS_ERR(anx6345->dvdd12))
> return PTR_ERR(anx6345->dvdd12);
> - }
There could be other errors such as -EBUSY or -EPERM. The following
would ensure a message gets printed in those cases, while avoiding
spamming the kernel log in the EPROBE_DEFER case.
if (IS_ERR(anx6345->dvdd12)) {
if (PTR_ERR(anx6345->dvdd12) != -EPROBE_DEFER)
DRM_ERROR("Failed to get dvdd12 supply (%d)\n",
PTR_ERR(anx6345->dvdd12));
return PTR_ERR(anx6345->dvdd12);
}
But maybe it's overkill ? With or without that change (for the second
regulator below too),
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> /* 2.5V digital core power regulator */
> anx6345->dvdd25 = devm_regulator_get(dev, "dvdd25");
> - if (IS_ERR(anx6345->dvdd25)) {
> - DRM_ERROR("dvdd25-supply not found\n");
> + if (IS_ERR(anx6345->dvdd25))
> return PTR_ERR(anx6345->dvdd25);
> - }
>
> /* GPIO for chip reset */
> anx6345->gpiod_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
--
Regards,
Laurent Pinchart
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 2/6] drm/bridge: anx6345: Clean up error handling in probe()
From: Laurent Pinchart @ 2020-02-20 13:52 UTC (permalink / raw)
To: Vasily Khoruzhick
Cc: Thierry Reding, Sam Ravnborg, David Airlie, Daniel Vetter,
Rob Herring, Mark Rutland, Maxime Ripard, Chen-Yu Tsai,
Andrzej Hajda, Neil Armstrong, Jonas Karlman, Jernej Skrabec,
Icenowy Zheng, Torsten Duwe, Heiko Stuebner, Linus Walleij,
Stephan Gerhold, Mark Brown, Stephen Rothwell, Samuel Holland,
dri-devel, linux-kernel, linux-arm-kernel
In-Reply-To: <20200220083508.792071-3-anarsoul@gmail.com>
Hi Vasily,
Thank you for the patch.
On Thu, Feb 20, 2020 at 12:35:04AM -0800, Vasily Khoruzhick wrote:
> devm_regulator_get() returns either a dummy regulator or -EPROBE_DEFER,
> we don't need to print scary message in either case.
>
> Signed-off-by: Vasily Khoruzhick <anarsoul@gmail.com>
> ---
> drivers/gpu/drm/bridge/analogix/analogix-anx6345.c | 8 ++------
> 1 file changed, 2 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> index 0d8d083b0207..0204bbe4f0a0 100644
> --- a/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> +++ b/drivers/gpu/drm/bridge/analogix/analogix-anx6345.c
> @@ -713,17 +713,13 @@ static int anx6345_i2c_probe(struct i2c_client *client,
>
> /* 1.2V digital core power regulator */
> anx6345->dvdd12 = devm_regulator_get(dev, "dvdd12");
> - if (IS_ERR(anx6345->dvdd12)) {
> - DRM_ERROR("dvdd12-supply not found\n");
> + if (IS_ERR(anx6345->dvdd12))
> return PTR_ERR(anx6345->dvdd12);
> - }
There could be other errors such as -EBUSY or -EPERM. The following
would ensure a message gets printed in those cases, while avoiding
spamming the kernel log in the EPROBE_DEFER case.
if (IS_ERR(anx6345->dvdd12)) {
if (PTR_ERR(anx6345->dvdd12) != -EPROBE_DEFER)
DRM_ERROR("Failed to get dvdd12 supply (%d)\n",
PTR_ERR(anx6345->dvdd12));
return PTR_ERR(anx6345->dvdd12);
}
But maybe it's overkill ? With or without that change (for the second
regulator below too),
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> /* 2.5V digital core power regulator */
> anx6345->dvdd25 = devm_regulator_get(dev, "dvdd25");
> - if (IS_ERR(anx6345->dvdd25)) {
> - DRM_ERROR("dvdd25-supply not found\n");
> + if (IS_ERR(anx6345->dvdd25))
> return PTR_ERR(anx6345->dvdd25);
> - }
>
> /* GPIO for chip reset */
> anx6345->gpiod_reset = devm_gpiod_get(dev, "reset", GPIOD_OUT_LOW);
--
Regards,
Laurent Pinchart
^ permalink raw reply
* RE: RFC: Split EPT huge pages in advance of dirty logging
From: Zhoujian (jay) @ 2020-02-20 13:52 UTC (permalink / raw)
To: Peter Xu
Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org, pbonzini@redhat.com,
dgilbert@redhat.com, quintela@redhat.com, Liujinsong (Paul),
linfeng (M), wangxin (U), Huangweidong (C), bgardon@google.com
In-Reply-To: <20200219171919.GA34517@xz-x1>
> -----Original Message-----
> From: Peter Xu [mailto:peterx@redhat.com]
> Sent: Thursday, February 20, 2020 1:19 AM
> To: Zhoujian (jay) <jianjay.zhou@huawei.com>
> Cc: kvm@vger.kernel.org; qemu-devel@nongnu.org; pbonzini@redhat.com;
> dgilbert@redhat.com; quintela@redhat.com; Liujinsong (Paul)
> <liu.jinsong@huawei.com>; linfeng (M) <linfeng23@huawei.com>; wangxin (U)
> <wangxinxin.wang@huawei.com>; Huangweidong (C)
> <weidong.huang@huawei.com>
> Subject: Re: RFC: Split EPT huge pages in advance of dirty logging
>
> On Wed, Feb 19, 2020 at 01:19:08PM +0000, Zhoujian (jay) wrote:
> > Hi Peter,
> >
> > > -----Original Message-----
> > > From: Peter Xu [mailto:peterx@redhat.com]
> > > Sent: Wednesday, February 19, 2020 1:43 AM
> > > To: Zhoujian (jay) <jianjay.zhou@huawei.com>
> > > Cc: kvm@vger.kernel.org; qemu-devel@nongnu.org;
> pbonzini@redhat.com;
> > > dgilbert@redhat.com; quintela@redhat.com; Liujinsong (Paul)
> > > <liu.jinsong@huawei.com>; linfeng (M) <linfeng23@huawei.com>;
> > > wangxin (U) <wangxinxin.wang@huawei.com>; Huangweidong (C)
> > > <weidong.huang@huawei.com>
> > > Subject: Re: RFC: Split EPT huge pages in advance of dirty logging
> > >
> > > On Tue, Feb 18, 2020 at 01:13:47PM +0000, Zhoujian (jay) wrote:
> > > > Hi all,
> > > >
> > > > We found that the guest will be soft-lockup occasionally when live
> > > > migrating a 60 vCPU, 512GiB huge page and memory sensitive VM. The
> > > > reason is clear, almost all of the vCPUs are waiting for the KVM
> > > > MMU spin-lock to create 4K SPTEs when the huge pages are write
> > > > protected. This
> > > phenomenon is also described in this patch set:
> > > > https://patchwork.kernel.org/cover/11163459/
> > > > which aims to handle page faults in parallel more efficiently.
> > > >
> > > > Our idea is to use the migration thread to touch all of the guest
> > > > memory in the granularity of 4K before enabling dirty logging. To
> > > > be more specific, we split all the PDPE_LEVEL SPTEs into
> > > > DIRECTORY_LEVEL SPTEs as the first step, and then split all the
> > > > DIRECTORY_LEVEL SPTEs into
> > > PAGE_TABLE_LEVEL SPTEs as the following step.
> > >
> > > IIUC, QEMU will prefer to use huge pages for all the anonymous
> > > ramblocks (please refer to ram_block_add):
> > >
> > > qemu_madvise(new_block->host, new_block->max_length,
> > > QEMU_MADV_HUGEPAGE);
> >
> > Yes, you're right
> >
> > >
> > > Another alternative I can think of is to add an extra parameter to
> > > QEMU to explicitly disable huge pages (so that can even be
> > > MADV_NOHUGEPAGE instead of MADV_HUGEPAGE). However that
> should also
> > > drag down the performance for the whole lifecycle of the VM.
> >
> > From the performance point of view, it is better to keep the huge
> > pages when the VM is not in the live migration state.
> >
> > > A 3rd option is to make a QMP
> > > command to dynamically turn huge pages on/off for ramblocks globally.
> >
> > We're searching a dynamic method too.
> > We plan to add two new flags for each memory slot, say
> > KVM_MEM_FORCE_PT_DIRECTORY_PAGES and
> > KVM_MEM_FORCE_PT_PAGE_TABLE_PAGES. These flags can be set through
> > KVM_SET_USER_MEMORY_REGION ioctl.
> >
> > The mapping_level which is called by tdp_page_fault in the kernel side
> > will return PT_DIRECTORY_LEVEL if the
> KVM_MEM_FORCE_PT_DIRECTORY_PAGES
> > flag of the memory slot is set, and return PT_PAGE_TABLE_LEVEL if the
> > KVM_MEM_FORCE_PT_PAGE_TABLE_PAGES flag is set.
> >
> > The key steps to split the huge pages in advance of enabling dirty log
> > is as follows:
> > 1. The migration thread in user space uses
> KVM_SET_USER_MEMORY_REGION
> > ioctl to set the KVM_MEM_FORCE_PT_DIRECTORY_PAGES flag for each
> memory
> > slot.
> > 2. The migration thread continues to use the KVM_SPLIT_HUGE_PAGES
> > ioctl (which is newly added) to do the splitting of large pages in the
> > kernel side.
> > 3. A new vCPU is created temporally(do some initialization but will
> > not
> > run) to help to do the work, i.e. as the parameter of the tdp_page_fault.
> > 4. Collect the GPA ranges of all the memory slots with the
> > KVM_MEM_FORCE_PT_DIRECTORY_PAGES flag set.
> > 5. Split the 1G huge pages(collected in step 4) into 2M by calling
> > tdp_page_fault, since the mapping_level will return
> > PT_DIRECTORY_LEVEL. Here is the main difference from the usual path
> > which is caused by the Guest side(EPT violation/misconfig etc), we
> > call it directly in the hypervisor side.
> > 6. Do some cleanups, i.e. free the vCPU related resources 7. The
> > KVM_SPLIT_HUGE_PAGES ioctl returned to the user space side.
> > 8. Using KVM_MEM_FORCE_PT_PAGE_TABLE_PAGES instread of
> > KVM_MEM_FORCE_PT_DIRECTORY_PAGES to repeat step 1 ~ step 7, in step
> 5
> > the 2M huge pages will be splitted into 4K pages.
> > 9. Clear the KVM_MEM_FORCE_PT_DIRECTORY_PAGES and
> > KVM_MEM_FORCE_PT_PAGE_TABLE_PAGES flags for each memory slot.
> > 10. Then the migration thread calls the log_start ioctl to enable the
> > dirty logging, and the remaining thing is the same.
>
> I'm not sure... I think it would be good if there is a way to have finer granularity
> control on using huge pages for any process, then KVM can directly leverage
> that because KVM page tables should always respect the mm configurations on
> these (so e.g. when huge page split, KVM gets notifications via mmu notifiers).
> Have you thought of such a more general way?
I did have thought of this, if we split the huge pages into 4K of a process, I'm
afraid it will not be workable for the huge pages sharing scenario, e.g. DPDK,
SPDK etc. So, only split the EPT page table and keep the VM process page table
(e.g. qemu) untouched is the goal.
>
> (And I just noticed that MADV_NOHUGEPAGE is only a hint to khugepaged
> and probably won't split any huge page at all after madvise() returns..)
> To tell the truth I'm still confused on how split of huge pages helped in your
> case...
I'm sorry if the meaning is not expressed clearly, and thanks for your patience.
> If I read it right the test reduced some execution time from 9s to a
> few ms after your splittion of huge pages.
Yes
> The thing is I don't see how split of
> huge pages could solve the mmu_lock contention with the huge VM, because
> IMO even if we split the huge pages into smaller ones, those pages should still
> be write-protected and need merely the same number of page faults to resolve
> when accessed/written? And I thought that should only be fixed with
> solutions like what Ben has proposed with the MMU rework. Could you show
> me what I've missed?
Let me try to describe the reason of mmu_lock contention more clearly and the
effort we tried to do...
The huge VM only has EPT >= level 2 sptes, and level 1 sptes don't
exist at the beginning. Write protect all the huge pages will trigger EPT
violation to create level 1 sptes for all the vCPUs which want to write the
content of the memory. Different vCPU write the different areas of
the memory, but they need the same kvm->mmu_lock to create the level 1
sptes, this situation will be worse if the number of vCPU and the memory of
VM is large(in our case 60U512G), meanwhile the VM has
memory-write-intensive work to do. In order to reduce the mmu_lock
contention, we try to: write protect VM memory gradually in small chunks,
such as 1G or 2M. Using a vCPU temporary creately by migration thread to
split 1G to 2M as the first step, and to split 2M to 4K as the second step
(this is a little hacking...and I do not know any side effect will be triggered
indeed).
Comparing to write protect all VM memory in one go, the write
protected range is limited in this way and only the vCPUs write this limited
range will be involved to take the mmu_lock. The contention will be reduced
since the memory range is small and the number of vCPU involved is small
too.
Of course, it will take some extra time to split all the huge pages into 4K
page before the real migration started, about 60s for 512G in my experiment.
During the memory iterative copy phase, PML will do the dirty logging work
(not write protected case for 4K), or IIRC using fast_page_fault to mark page
dirty if PML is not supported, which case the mmu_lock does not needed.
Regards,
Jay Zhou
^ permalink raw reply
* Re: Git Test Coverage Report (Feb. 18, 2020)
From: Johannes Schindelin @ 2020-02-20 13:52 UTC (permalink / raw)
To: Taylor Blau; +Cc: Derrick Stolee, Git List
In-Reply-To: <20200219204430.GB5101@syl.local>
Hi Taylor,
On Wed, 19 Feb 2020, Taylor Blau wrote:
> On Tue, Feb 18, 2020 at 07:46:03AM -0500, Derrick Stolee wrote:
>
> > Taylor Blau 5d5916fd builtin/commit-graph.c: support '--split[=<strategy>]'
> > commit-graph.c
> > 5d5916fd 1751) break;
>
> This 'break' line only changed indentation, so I don't think that this
> is new 'uncovered' code in my series, only that it got a little bit
> harder to trigger.
>
> It is interesting that this is uncovered, but I don't think that there's
> a huge sense of urgency to add tests to cover it.
I could imagine that this is actually not the `break` statement, but the
one before that. It seems to be an issue with the way GCC optimizes that
sometimes GDB (and gcov) have problems attributing precisely the line that
is associated with a given assembler instruction. My guess is that the
optimizer often seems to "reflow" the code, e.g. it would jump to the end
of a switch statement only to jump _back_ to the actual switch case.
So I would expect the report to be legit, but pointing to the incorrect
source code line. At least that's what I seem to recall from the last time
a Test Code Coverage report pointed at one of the `break` statements I had
added.
>
> > Taylor Blau a599e2c9 builtin/commit-graph.c: introduce '--input=<source>'
> > builtin/commit-graph.c
> > a599e2c9 75) *to = 0;
> > a599e2c9 76) return 0;
>
> These seem more interesting to cover, but only marginally so.
>
> > a599e2c9 86) *to |= COMMIT_GRAPH_INPUT_APPEND;
>
> This one I think we could ignore, though, since the same behavior is
> triggered by simply '--append' instead of '--input=append'. We decided
> in [1] to
to...? :-D
Thanks,
Dscho
>
> Thanks,
> Taylor
>
> [1]: 846706e9-efe2-448d-67a3-a96638e9bcbc@gmail.com
>
^ permalink raw reply
* Re: [yocto] Debugging gdb built by Yocto
From: Patrick Doyle @ 2020-02-20 13:52 UTC (permalink / raw)
To: Richard Purdie; +Cc: Yocto discussion list
In-Reply-To: <2c0fedf92f8a5cf805cc9908b438dab40ffd72ec.camel@linuxfoundation.org>
On Wed, Feb 19, 2020 at 5:19 PM Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Tue, 2020-02-18 at 11:26 -0500, Patrick Doyle wrote:
> > Does anybody have any tips or tricks for how I might debug the
> > (cross-canadian) gdb built by Yocto's SDK?
> Do you perhaps want gdb-cross-mipsel ?
>
> cross-canadian is designed to be run as part of the SDK.
Thank you. That is, indeed, what I want. It demonstrates the same
problem, and I can debug it.
Aside... it's quite a mind bending experience to debug gdb with gdb :-)
Just imagine...
$ gdb gdb-cross-mipsel
(gdb) break main
(gdb) run
(gdb)
That last "(gdb)" prompt is from the gdb I'm debugging :-)
Also aside... and totally off topic, except that I'm sure some might
be wondering why I feel the need to debug gdb...
I am trying to understand why I can't get stack traces from cores file
on a mipsel system. At the moment (after strategic additions of
breakpoints, printf statements, and more breakpoints, and lots of
internet combing), I am chasing down a rabbit hole related to the
facts that the MIPS build uses/produces PIE code (Position Independent
Executables, which is somehow different than Position Independent
Code), a new ELF tag (MIPS_RLD_MAP_REL) was added 5 years ago to
binutils, gdb looks for that tag, but the musl dynamic loader is not
aware of it. I don't know if this is the root cause of my problem or
just (another) rabbit hole. If anybody has any suggestions, I'm all
ears.
--wpd
^ permalink raw reply
* Re: [PATCH v3 02/20] hw: Remove unnecessary cast when calling dma_memory_read()
From: Philippe Mathieu-Daudé @ 2020-02-20 13:51 UTC (permalink / raw)
To: Eric Blake, Peter Maydell, qemu-devel
Cc: Fam Zheng, Dmitry Fleytman, Matthew Rosato, Michael S. Tsirkin,
Jason Wang, Gerd Hoffmann, Edgar E. Iglesias, Stefano Stabellini,
kvm, qemu-block, David Hildenbrand, Halil Pasic,
Christian Borntraeger, Hervé Poussineau, Anthony Perard,
xen-devel, Aleksandar Rikalo, David Gibson, Laurent Vivier,
Thomas Huth, Eduardo Habkost, Stefan Weil, Alistair Francis,
Richard Henderson, Paul Durrant, Eric Auger, qemu-s390x, qemu-arm,
Cédric Le Goater, John Snow, Richard Henderson,
Igor Mitsyanko, Cornelia Huck, Michael Walle, qemu-ppc,
Paolo Bonzini
In-Reply-To: <be623afd-0605-0bdf-daae-f38ba5562012@redhat.com>
On 2/20/20 2:43 PM, Philippe Mathieu-Daudé wrote:
> On 2/20/20 2:16 PM, Eric Blake wrote:
>> On 2/20/20 7:05 AM, Philippe Mathieu-Daudé wrote:
>>> Since its introduction in commit d86a77f8abb, dma_memory_read()
>>> always accepted void pointer argument. Remove the unnecessary
>>> casts.
>>>
>>> This commit was produced with the included Coccinelle script
>>> scripts/coccinelle/exec_rw_const.
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>>> ---
>>> scripts/coccinelle/exec_rw_const.cocci | 15 +++++++++++++++
>>> hw/arm/smmu-common.c | 3 +--
>>> hw/arm/smmuv3.c | 10 ++++------
>>> hw/sd/sdhci.c | 15 +++++----------
>>> 4 files changed, 25 insertions(+), 18 deletions(-)
>>> create mode 100644 scripts/coccinelle/exec_rw_const.cocci
>>>
>>> diff --git a/scripts/coccinelle/exec_rw_const.cocci
>>> b/scripts/coccinelle/exec_rw_const.cocci
>>> new file mode 100644
>>> index 0000000000..a0054f009d
>>> --- /dev/null
>>> +++ b/scripts/coccinelle/exec_rw_const.cocci
>>> @@ -0,0 +1,15 @@
>>> +// Usage:
>>> +// spatch --sp-file scripts/coccinelle/exec_rw_const.cocci --dir .
>>> --in-place
>>
>> This command line should also use '--macro-file
>> scripts/cocci-macro-file.h' to cover more of the code base (Coccinelle
>> skips portions of the code that uses macros it doesn't recognize).
>>
>>
>>> @@ -726,13 +724,10 @@ static void get_adma_description(SDHCIState *s,
>>> ADMADescr *dscr)
>>> }
>>> break;
>>> case SDHC_CTRL_ADMA2_64:
>>> - dma_memory_read(s->dma_as, entry_addr,
>>> - (uint8_t *)(&dscr->attr), 1);
>>> - dma_memory_read(s->dma_as, entry_addr + 2,
>>> - (uint8_t *)(&dscr->length), 2);
>>> + dma_memory_read(s->dma_as, entry_addr, (&dscr->attr), 1);
>>> + dma_memory_read(s->dma_as, entry_addr + 2, (&dscr->length), 2);
>>
>> The () around &dscr->length are now pointless.
>
> Thanks Eric, patch updated. Peter are you OK if I change the cocci
> header using /* */ as:
>
> -- >8 --
> diff --git a/scripts/coccinelle/exec_rw_const.cocci
> b/scripts/coccinelle/exec_rw_const.cocci
> index a0054f009d..7e42682240 100644
> --- a/scripts/coccinelle/exec_rw_const.cocci
> +++ b/scripts/coccinelle/exec_rw_const.cocci
> @@ -1,5 +1,13 @@
> -// Usage:
> -// spatch --sp-file scripts/coccinelle/exec_rw_const.cocci --dir .
> --in-place
> +/*
> + Usage:
> +
> + spatch \
> + --macro-file scripts/cocci-macro-file.h \
> + --sp-file scripts/coccinelle/exec_rw_const.cocci \
> + --keep-comments \
> + --in-place \
> + --dir .
> +*/
>
> // Remove useless cast
> @@
> @@ -7,9 +15,9 @@ expression E1, E2, E3, E4;
> type T;
> @@
> (
> -- dma_memory_read(E1, E2, (T *)E3, E4)
> +- dma_memory_read(E1, E2, (T *)(E3), E4)
> + dma_memory_read(E1, E2, E3, E4)
> |
> -- dma_memory_write(E1, E2, (T *)E3, E4)
> +- dma_memory_write(E1, E2, (T *)(E3), E4)
> + dma_memory_write(E1, E2, E3, E4)
> )
> diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
> index d5abdaad41..de63ffb037 100644
> --- a/hw/sd/sdhci.c
> +++ b/hw/sd/sdhci.c
> @@ -724,10 +724,10 @@ static void get_adma_description(SDHCIState *s,
> ADMADescr *dscr)
> }
> break;
> case SDHC_CTRL_ADMA2_64:
> - dma_memory_read(s->dma_as, entry_addr, (&dscr->attr), 1);
> - dma_memory_read(s->dma_as, entry_addr + 2, (&dscr->length), 2);
> + dma_memory_read(s->dma_as, entry_addr, &dscr->attr, 1);
> + dma_memory_read(s->dma_as, entry_addr + 2, &dscr->length, 2);
> dscr->length = le16_to_cpu(dscr->length);
> - dma_memory_read(s->dma_as, entry_addr + 4, (&dscr->addr), 8);
> + dma_memory_read(s->dma_as, entry_addr + 4, &dscr->addr, 8);
> dscr->addr = le64_to_cpu(dscr->addr);
> dscr->attr &= (uint8_t) ~0xC0;
> dscr->incr = 12;
> ---
Series updated here:
https://github.com/philmd/qemu/commits/exec_rw_const_v4
Relevant spatch:
https://github.com/philmd/qemu/blob/exec_rw_const_v4/scripts/coccinelle/exec_rw_const.cocci
I will respin later to let people time to review.
^ permalink raw reply
* Re: [Xen-devel] [PATCH v3 02/20] hw: Remove unnecessary cast when calling dma_memory_read()
From: Philippe Mathieu-Daudé @ 2020-02-20 13:51 UTC (permalink / raw)
To: Eric Blake, Peter Maydell, qemu-devel
Cc: Fam Zheng, Dmitry Fleytman, Matthew Rosato, Michael S. Tsirkin,
Jason Wang, Gerd Hoffmann, Edgar E. Iglesias, Stefano Stabellini,
kvm, qemu-block, David Hildenbrand, Halil Pasic,
Christian Borntraeger, Hervé Poussineau, Anthony Perard,
xen-devel, Aleksandar Rikalo, David Gibson, Laurent Vivier,
Thomas Huth, Eduardo Habkost, Stefan Weil, Alistair Francis,
Richard Henderson, Paul Durrant, Eric Auger, qemu-s390x, qemu-arm,
Cédric Le Goater, John Snow, Richard Henderson,
Igor Mitsyanko, Cornelia Huck, Michael Walle, qemu-ppc,
Paolo Bonzini
In-Reply-To: <be623afd-0605-0bdf-daae-f38ba5562012@redhat.com>
On 2/20/20 2:43 PM, Philippe Mathieu-Daudé wrote:
> On 2/20/20 2:16 PM, Eric Blake wrote:
>> On 2/20/20 7:05 AM, Philippe Mathieu-Daudé wrote:
>>> Since its introduction in commit d86a77f8abb, dma_memory_read()
>>> always accepted void pointer argument. Remove the unnecessary
>>> casts.
>>>
>>> This commit was produced with the included Coccinelle script
>>> scripts/coccinelle/exec_rw_const.
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>>> ---
>>> scripts/coccinelle/exec_rw_const.cocci | 15 +++++++++++++++
>>> hw/arm/smmu-common.c | 3 +--
>>> hw/arm/smmuv3.c | 10 ++++------
>>> hw/sd/sdhci.c | 15 +++++----------
>>> 4 files changed, 25 insertions(+), 18 deletions(-)
>>> create mode 100644 scripts/coccinelle/exec_rw_const.cocci
>>>
>>> diff --git a/scripts/coccinelle/exec_rw_const.cocci
>>> b/scripts/coccinelle/exec_rw_const.cocci
>>> new file mode 100644
>>> index 0000000000..a0054f009d
>>> --- /dev/null
>>> +++ b/scripts/coccinelle/exec_rw_const.cocci
>>> @@ -0,0 +1,15 @@
>>> +// Usage:
>>> +// spatch --sp-file scripts/coccinelle/exec_rw_const.cocci --dir .
>>> --in-place
>>
>> This command line should also use '--macro-file
>> scripts/cocci-macro-file.h' to cover more of the code base (Coccinelle
>> skips portions of the code that uses macros it doesn't recognize).
>>
>>
>>> @@ -726,13 +724,10 @@ static void get_adma_description(SDHCIState *s,
>>> ADMADescr *dscr)
>>> }
>>> break;
>>> case SDHC_CTRL_ADMA2_64:
>>> - dma_memory_read(s->dma_as, entry_addr,
>>> - (uint8_t *)(&dscr->attr), 1);
>>> - dma_memory_read(s->dma_as, entry_addr + 2,
>>> - (uint8_t *)(&dscr->length), 2);
>>> + dma_memory_read(s->dma_as, entry_addr, (&dscr->attr), 1);
>>> + dma_memory_read(s->dma_as, entry_addr + 2, (&dscr->length), 2);
>>
>> The () around &dscr->length are now pointless.
>
> Thanks Eric, patch updated. Peter are you OK if I change the cocci
> header using /* */ as:
>
> -- >8 --
> diff --git a/scripts/coccinelle/exec_rw_const.cocci
> b/scripts/coccinelle/exec_rw_const.cocci
> index a0054f009d..7e42682240 100644
> --- a/scripts/coccinelle/exec_rw_const.cocci
> +++ b/scripts/coccinelle/exec_rw_const.cocci
> @@ -1,5 +1,13 @@
> -// Usage:
> -// spatch --sp-file scripts/coccinelle/exec_rw_const.cocci --dir .
> --in-place
> +/*
> + Usage:
> +
> + spatch \
> + --macro-file scripts/cocci-macro-file.h \
> + --sp-file scripts/coccinelle/exec_rw_const.cocci \
> + --keep-comments \
> + --in-place \
> + --dir .
> +*/
>
> // Remove useless cast
> @@
> @@ -7,9 +15,9 @@ expression E1, E2, E3, E4;
> type T;
> @@
> (
> -- dma_memory_read(E1, E2, (T *)E3, E4)
> +- dma_memory_read(E1, E2, (T *)(E3), E4)
> + dma_memory_read(E1, E2, E3, E4)
> |
> -- dma_memory_write(E1, E2, (T *)E3, E4)
> +- dma_memory_write(E1, E2, (T *)(E3), E4)
> + dma_memory_write(E1, E2, E3, E4)
> )
> diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
> index d5abdaad41..de63ffb037 100644
> --- a/hw/sd/sdhci.c
> +++ b/hw/sd/sdhci.c
> @@ -724,10 +724,10 @@ static void get_adma_description(SDHCIState *s,
> ADMADescr *dscr)
> }
> break;
> case SDHC_CTRL_ADMA2_64:
> - dma_memory_read(s->dma_as, entry_addr, (&dscr->attr), 1);
> - dma_memory_read(s->dma_as, entry_addr + 2, (&dscr->length), 2);
> + dma_memory_read(s->dma_as, entry_addr, &dscr->attr, 1);
> + dma_memory_read(s->dma_as, entry_addr + 2, &dscr->length, 2);
> dscr->length = le16_to_cpu(dscr->length);
> - dma_memory_read(s->dma_as, entry_addr + 4, (&dscr->addr), 8);
> + dma_memory_read(s->dma_as, entry_addr + 4, &dscr->addr, 8);
> dscr->addr = le64_to_cpu(dscr->addr);
> dscr->attr &= (uint8_t) ~0xC0;
> dscr->incr = 12;
> ---
Series updated here:
https://github.com/philmd/qemu/commits/exec_rw_const_v4
Relevant spatch:
https://github.com/philmd/qemu/blob/exec_rw_const_v4/scripts/coccinelle/exec_rw_const.cocci
I will respin later to let people time to review.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH v3 02/20] hw: Remove unnecessary cast when calling dma_memory_read()
From: Philippe Mathieu-Daudé @ 2020-02-20 13:51 UTC (permalink / raw)
To: Eric Blake, Peter Maydell, qemu-devel
Cc: Fam Zheng, Dmitry Fleytman, kvm, Michael S. Tsirkin, Jason Wang,
Gerd Hoffmann, Edgar E. Iglesias, Stefano Stabellini,
Matthew Rosato, qemu-block, David Hildenbrand, Halil Pasic,
Christian Borntraeger, Hervé Poussineau, Anthony Perard,
xen-devel, Aleksandar Rikalo, Richard Henderson, Laurent Vivier,
Thomas Huth, Eduardo Habkost, Stefan Weil, Alistair Francis,
Richard Henderson, Paul Durrant, Eric Auger, qemu-s390x, qemu-arm,
Cédric Le Goater, John Snow, David Gibson, Igor Mitsyanko,
Cornelia Huck, Michael Walle, qemu-ppc, Paolo Bonzini
In-Reply-To: <be623afd-0605-0bdf-daae-f38ba5562012@redhat.com>
On 2/20/20 2:43 PM, Philippe Mathieu-Daudé wrote:
> On 2/20/20 2:16 PM, Eric Blake wrote:
>> On 2/20/20 7:05 AM, Philippe Mathieu-Daudé wrote:
>>> Since its introduction in commit d86a77f8abb, dma_memory_read()
>>> always accepted void pointer argument. Remove the unnecessary
>>> casts.
>>>
>>> This commit was produced with the included Coccinelle script
>>> scripts/coccinelle/exec_rw_const.
>>>
>>> Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
>>> ---
>>> scripts/coccinelle/exec_rw_const.cocci | 15 +++++++++++++++
>>> hw/arm/smmu-common.c | 3 +--
>>> hw/arm/smmuv3.c | 10 ++++------
>>> hw/sd/sdhci.c | 15 +++++----------
>>> 4 files changed, 25 insertions(+), 18 deletions(-)
>>> create mode 100644 scripts/coccinelle/exec_rw_const.cocci
>>>
>>> diff --git a/scripts/coccinelle/exec_rw_const.cocci
>>> b/scripts/coccinelle/exec_rw_const.cocci
>>> new file mode 100644
>>> index 0000000000..a0054f009d
>>> --- /dev/null
>>> +++ b/scripts/coccinelle/exec_rw_const.cocci
>>> @@ -0,0 +1,15 @@
>>> +// Usage:
>>> +// spatch --sp-file scripts/coccinelle/exec_rw_const.cocci --dir .
>>> --in-place
>>
>> This command line should also use '--macro-file
>> scripts/cocci-macro-file.h' to cover more of the code base (Coccinelle
>> skips portions of the code that uses macros it doesn't recognize).
>>
>>
>>> @@ -726,13 +724,10 @@ static void get_adma_description(SDHCIState *s,
>>> ADMADescr *dscr)
>>> }
>>> break;
>>> case SDHC_CTRL_ADMA2_64:
>>> - dma_memory_read(s->dma_as, entry_addr,
>>> - (uint8_t *)(&dscr->attr), 1);
>>> - dma_memory_read(s->dma_as, entry_addr + 2,
>>> - (uint8_t *)(&dscr->length), 2);
>>> + dma_memory_read(s->dma_as, entry_addr, (&dscr->attr), 1);
>>> + dma_memory_read(s->dma_as, entry_addr + 2, (&dscr->length), 2);
>>
>> The () around &dscr->length are now pointless.
>
> Thanks Eric, patch updated. Peter are you OK if I change the cocci
> header using /* */ as:
>
> -- >8 --
> diff --git a/scripts/coccinelle/exec_rw_const.cocci
> b/scripts/coccinelle/exec_rw_const.cocci
> index a0054f009d..7e42682240 100644
> --- a/scripts/coccinelle/exec_rw_const.cocci
> +++ b/scripts/coccinelle/exec_rw_const.cocci
> @@ -1,5 +1,13 @@
> -// Usage:
> -// spatch --sp-file scripts/coccinelle/exec_rw_const.cocci --dir .
> --in-place
> +/*
> + Usage:
> +
> + spatch \
> + --macro-file scripts/cocci-macro-file.h \
> + --sp-file scripts/coccinelle/exec_rw_const.cocci \
> + --keep-comments \
> + --in-place \
> + --dir .
> +*/
>
> // Remove useless cast
> @@
> @@ -7,9 +15,9 @@ expression E1, E2, E3, E4;
> type T;
> @@
> (
> -- dma_memory_read(E1, E2, (T *)E3, E4)
> +- dma_memory_read(E1, E2, (T *)(E3), E4)
> + dma_memory_read(E1, E2, E3, E4)
> |
> -- dma_memory_write(E1, E2, (T *)E3, E4)
> +- dma_memory_write(E1, E2, (T *)(E3), E4)
> + dma_memory_write(E1, E2, E3, E4)
> )
> diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
> index d5abdaad41..de63ffb037 100644
> --- a/hw/sd/sdhci.c
> +++ b/hw/sd/sdhci.c
> @@ -724,10 +724,10 @@ static void get_adma_description(SDHCIState *s,
> ADMADescr *dscr)
> }
> break;
> case SDHC_CTRL_ADMA2_64:
> - dma_memory_read(s->dma_as, entry_addr, (&dscr->attr), 1);
> - dma_memory_read(s->dma_as, entry_addr + 2, (&dscr->length), 2);
> + dma_memory_read(s->dma_as, entry_addr, &dscr->attr, 1);
> + dma_memory_read(s->dma_as, entry_addr + 2, &dscr->length, 2);
> dscr->length = le16_to_cpu(dscr->length);
> - dma_memory_read(s->dma_as, entry_addr + 4, (&dscr->addr), 8);
> + dma_memory_read(s->dma_as, entry_addr + 4, &dscr->addr, 8);
> dscr->addr = le64_to_cpu(dscr->addr);
> dscr->attr &= (uint8_t) ~0xC0;
> dscr->incr = 12;
> ---
Series updated here:
https://github.com/philmd/qemu/commits/exec_rw_const_v4
Relevant spatch:
https://github.com/philmd/qemu/blob/exec_rw_const_v4/scripts/coccinelle/exec_rw_const.cocci
I will respin later to let people time to review.
^ permalink raw reply
* Re: [PATCH v7 14/24] btrfs: Convert from readpages to readahead
From: Matthew Wilcox @ 2020-02-20 13:48 UTC (permalink / raw)
To: Johannes Thumshirn
Cc: linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com,
linux-mm@kvack.org, ocfs2-devel@oss.oracle.com,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-erofs@lists.ozlabs.org, linux-btrfs@vger.kernel.org
In-Reply-To: <SN4PR0401MB35987D7B76007B93B1C5CE5E9B130@SN4PR0401MB3598.namprd04.prod.outlook.com>
On Thu, Feb 20, 2020 at 09:42:19AM +0000, Johannes Thumshirn wrote:
> On 19/02/2020 22:03, Matthew Wilcox wrote:
> > From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> >
> > Use the new readahead operation in btrfs. Add a
> > readahead_for_each_batch() iterator to optimise the loop in the XArray.
>
> OK I must admit I haven't followed this series closely, but what
> happened to said readahead_for_each_batch()?
>
> As far as I can see it's now:
>
> [...]
> > + while ((nr = readahead_page_batch(rac, pagepool))) {
Oops, forgot to update the changelog there. Yes, that's exactly what it
changed to. That discussion was here:
https://lore.kernel.org/linux-fsdevel/20200219144117.GP24185@bombadil.infradead.org/
... and then Christoph pointed out the iterators weren't really adding
much value at that point, so they got deleted. New changelog for
this patch:
btrfs: Convert from readpages to readahead
Implement the new readahead method in btrfs. Add a readahead_page_batch()
to optimise fetching a batch of pages at once.
^ permalink raw reply
* Re: [PATCH v3 6/6] powerpc/fsl_booke/kaslr: rename kaslr-booke32.rst to kaslr-booke.rst and add 64bit part
From: Christophe Leroy @ 2020-02-20 13:50 UTC (permalink / raw)
To: Jason Yan, mpe, linuxppc-dev, diana.craciun, benh, paulus,
npiggin, keescook, kernel-hardening, oss
Cc: linux-kernel, zhaohongjiang
In-Reply-To: <20200206025825.22934-7-yanaijie@huawei.com>
Le 06/02/2020 à 03:58, Jason Yan a écrit :
> Now we support both 32 and 64 bit KASLR for fsl booke. Add document for
> 64 bit part and rename kaslr-booke32.rst to kaslr-booke.rst.
>
> Signed-off-by: Jason Yan <yanaijie@huawei.com>
> Cc: Scott Wood <oss@buserror.net>
> Cc: Diana Craciun <diana.craciun@nxp.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: Kees Cook <keescook@chromium.org>
> ---
> .../{kaslr-booke32.rst => kaslr-booke.rst} | 35 ++++++++++++++++---
> 1 file changed, 31 insertions(+), 4 deletions(-)
> rename Documentation/powerpc/{kaslr-booke32.rst => kaslr-booke.rst} (59%)
Also update Documentation/powerpc/index.rst ?
Christophe
^ permalink raw reply
* Re: [PATCH v1 0/2] perf report: Support annotation of code without symbols
From: Jin, Yao @ 2020-02-20 13:50 UTC (permalink / raw)
To: Jiri Olsa
Cc: acme, jolsa, peterz, mingo, alexander.shishkin, Linux-kernel, ak,
kan.liang, yao.jin
In-Reply-To: <20200220120655.GA586895@krava>
On 2/20/2020 8:06 PM, Jiri Olsa wrote:
> On Thu, Feb 20, 2020 at 08:03:18PM +0800, Jin, Yao wrote:
>>
>>
>> On 2/20/2020 7:56 PM, Jiri Olsa wrote:
>>> On Thu, Feb 20, 2020 at 08:59:00AM +0800, Jin Yao wrote:
>>>> For perf report on stripped binaries it is currently impossible to do
>>>> annotation. The annotation state is all tied to symbols, but there are
>>>> either no symbols, or symbols are not covering all the code.
>>>>
>>>> We should support the annotation functionality even without symbols.
>>>>
>>>> The first patch uses al_addr to print because it's easy to dump
>>>> the instructions from this address in binary for branch mode.
>>>>
>>>> The second patch supports the annotation on stripped binary.
>>>>
>>>> Jin Yao (2):
>>>> perf util: Print al_addr when symbol is not found
>>>> perf annotate: Support interactive annotation of code without symbols
>>>
>>> looks good, but I'm getting crash when annotating unresolved kernel address:
>>>
>>> jirka
>>>
>>>
>>
>> Thanks for reporting the issue.
>>
>> I guess you are trying the "0xffffffff81c00ae7", let me try to reproduce
>> this issue.
>
> yes, I also checked and it did not happen before
>
> jirka
>
I can reproduce it now.
perf record -e cycles:u ls
perf report --stdio
75.29% ls ld-2.27.so [.] do_lookup_x
23.64% ls ld-2.27.so [.] __GI___tunables_init
1.04% ls [unknown] [k] 0xffffffff85c01210
0.03% ls ld-2.27.so [.] _start
Looks it's caused by skid.
Thanks
Jin Yao
^ permalink raw reply
* Re: [PATCH v3 5/6] powerpc/fsl_booke/64: clear the original kernel if randomized
From: Christophe Leroy @ 2020-02-20 13:49 UTC (permalink / raw)
To: Jason Yan, mpe, linuxppc-dev, diana.craciun, benh, paulus,
npiggin, keescook, kernel-hardening, oss
Cc: linux-kernel, zhaohongjiang
In-Reply-To: <20200206025825.22934-6-yanaijie@huawei.com>
Le 06/02/2020 à 03:58, Jason Yan a écrit :
> The original kernel still exists in the memory, clear it now.
No such problem with PPC32 ? Or is that common ?
Christophe
>
> Signed-off-by: Jason Yan <yanaijie@huawei.com>
> Cc: Scott Wood <oss@buserror.net>
> Cc: Diana Craciun <diana.craciun@nxp.com>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Nicholas Piggin <npiggin@gmail.com>
> Cc: Kees Cook <keescook@chromium.org>
> ---
> arch/powerpc/mm/nohash/kaslr_booke.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/mm/nohash/kaslr_booke.c b/arch/powerpc/mm/nohash/kaslr_booke.c
> index c6f5c1db1394..ed1277059368 100644
> --- a/arch/powerpc/mm/nohash/kaslr_booke.c
> +++ b/arch/powerpc/mm/nohash/kaslr_booke.c
> @@ -378,8 +378,10 @@ notrace void __init kaslr_early_init(void *dt_ptr, phys_addr_t size)
> unsigned int *__kaslr_offset = (unsigned int *)(KERNELBASE + 0x58);
> unsigned int *__run_at_load = (unsigned int *)(KERNELBASE + 0x5c);
>
> - if (*__run_at_load == 1)
> + if (*__run_at_load == 1) {
> + kaslr_late_init();
> return;
> + }
>
> /* Setup flat device-tree pointer */
> initial_boot_params = dt_ptr;
>
^ permalink raw reply
* [PATCH v2 0/1] scsi: ufs: fix waiting time for reference clock
From: Stanley Chu @ 2020-02-20 13:48 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: Stanley Chu, bvanassche, andy.teng, chun-hung.wu, kuohong.wang,
linux-kernel, cang, linux-mediatek, peter.wang, matthias.bgg,
beanhuo, linux-arm-kernel, asutoshd
Hi,
This patchset adds waiting time for reference clock provided to UFS device in MediaTek UFS implementation.
v1 -> v2:
- Drop patch #1 "scsi: ufs: add required delay after gating reference clock" since it will impact ufs-qcom flow without solid conclusion yet.
Stanley Chu (1):
scsi: ufs: ufs-mediatek: add waiting time for reference clock
drivers/scsi/ufs/ufs-mediatek.c | 46 +++++++++++++++++++++++++++++++--
drivers/scsi/ufs/ufs-mediatek.h | 2 ++
2 files changed, 46 insertions(+), 2 deletions(-)
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply
* Re: [PATCH v1 07/13] migrate/ram: Get rid of "place_source" in ram_load_postcopy()
From: Peter Xu @ 2020-02-20 13:48 UTC (permalink / raw)
To: David Hildenbrand
Cc: Eduardo Habkost, Juan Quintela, qemu-devel,
Dr . David Alan Gilbert, Paolo Bonzini, Richard Henderson
In-Reply-To: <899dc544-757f-29ac-3a97-f45a92e68040@redhat.com>
On Thu, Feb 20, 2020 at 02:22:48PM +0100, David Hildenbrand wrote:
> > For resizing test, an easy way (I can think of) is to temporarily
> > remove the size check below in your test branch:
>
> Yeah, it's especially hard to have a reliable test one can materialize.
> I played with manual tests like this myself.
Great!
>
> I'm thinking about testing this with a device that can trigger resizes
> on demand, e.g., virtio-mem, for now on my private branch. But I'd
> really like to have some test one can automate at one point ... however,
> there seems to be no easy way to achieve that right now.
Yes I totally agree.
Thanks,
--
Peter Xu
^ permalink raw reply
* [PATCH v2 0/1] scsi: ufs: fix waiting time for reference clock
From: Stanley Chu @ 2020-02-20 13:48 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: Stanley Chu, bvanassche, andy.teng, chun-hung.wu, kuohong.wang,
linux-kernel, cang, linux-mediatek, peter.wang, matthias.bgg,
beanhuo, linux-arm-kernel, asutoshd
Hi,
This patchset adds waiting time for reference clock provided to UFS device in MediaTek UFS implementation.
v1 -> v2:
- Drop patch #1 "scsi: ufs: add required delay after gating reference clock" since it will impact ufs-qcom flow without solid conclusion yet.
Stanley Chu (1):
scsi: ufs: ufs-mediatek: add waiting time for reference clock
drivers/scsi/ufs/ufs-mediatek.c | 46 +++++++++++++++++++++++++++++++--
drivers/scsi/ufs/ufs-mediatek.h | 2 ++
2 files changed, 46 insertions(+), 2 deletions(-)
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v2 1/1] scsi: ufs: ufs-mediatek: add waiting time for reference clock
From: Stanley Chu @ 2020-02-20 13:48 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: Stanley Chu, bvanassche, andy.teng, chun-hung.wu, kuohong.wang,
linux-kernel, cang, linux-mediatek, peter.wang, matthias.bgg,
beanhuo, linux-arm-kernel, asutoshd
In-Reply-To: <20200220134848.8807-1-stanley.chu@mediatek.com>
Some delays may be required either after gating or before ungating
reference clock for device according to vendor requirements.
Note that in UFS 3.0, the delay time after gating reference
clock can be defined by attribute bRefClkGatingWaitTime. Use the
formal value instead if it can be queried from device.
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
---
drivers/scsi/ufs/ufs-mediatek.c | 46 +++++++++++++++++++++++++++++++--
drivers/scsi/ufs/ufs-mediatek.h | 2 ++
2 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 9d05962feb15..de650822c9d9 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -100,6 +100,17 @@ static int ufs_mtk_bind_mphy(struct ufs_hba *hba)
return err;
}
+static void ufs_mtk_udelay(unsigned long us)
+{
+ if (!us)
+ return;
+
+ if (us < 10)
+ udelay(us);
+ else
+ usleep_range(us, us + 10);
+}
+
static int ufs_mtk_setup_ref_clk(struct ufs_hba *hba, bool on)
{
struct ufs_mtk_host *host = ufshcd_get_variant(hba);
@@ -112,6 +123,7 @@ static int ufs_mtk_setup_ref_clk(struct ufs_hba *hba, bool on)
if (on) {
ufs_mtk_ref_clk_notify(on, res);
+ ufs_mtk_udelay(host->ref_clk_ungating_wait_us);
ufshcd_writel(hba, REFCLK_REQUEST, REG_UFS_REFCLK_CTRL);
} else {
ufshcd_writel(hba, REFCLK_RELEASE, REG_UFS_REFCLK_CTRL);
@@ -137,12 +149,29 @@ static int ufs_mtk_setup_ref_clk(struct ufs_hba *hba, bool on)
out:
host->ref_clk_enabled = on;
- if (!on)
+ if (!on) {
+ ufs_mtk_udelay(host->ref_clk_gating_wait_us);
ufs_mtk_ref_clk_notify(on, res);
+ }
return 0;
}
+static void ufs_mtk_setup_ref_clk_wait_us(struct ufs_hba *hba,
+ u16 gating_us, u16 ungating_us)
+{
+ struct ufs_mtk_host *host = ufshcd_get_variant(hba);
+
+ if (hba->dev_info.clk_gating_wait_us) {
+ host->ref_clk_gating_wait_us =
+ hba->dev_info.clk_gating_wait_us;
+ } else {
+ host->ref_clk_gating_wait_us = gating_us;
+ }
+
+ host->ref_clk_ungating_wait_us = ungating_us;
+}
+
static u32 ufs_mtk_link_get_state(struct ufs_hba *hba)
{
u32 val;
@@ -502,10 +531,23 @@ static void ufs_mtk_dbg_register_dump(struct ufs_hba *hba)
static int ufs_mtk_apply_dev_quirks(struct ufs_hba *hba)
{
struct ufs_dev_info *dev_info = &hba->dev_info;
+ u16 mid = dev_info->wmanufacturerid;
- if (dev_info->wmanufacturerid == UFS_VENDOR_SAMSUNG)
+ if (mid == UFS_VENDOR_SAMSUNG)
ufshcd_dme_set(hba, UIC_ARG_MIB(PA_TACTIVATE), 6);
+ /*
+ * Decide waiting time before gating reference clock and
+ * after ungating reference clock according to vendors'
+ * requirements.
+ */
+ if (mid == UFS_VENDOR_SAMSUNG)
+ ufs_mtk_setup_ref_clk_wait_us(hba, 1, 1);
+ else if (mid == UFS_VENDOR_SKHYNIX)
+ ufs_mtk_setup_ref_clk_wait_us(hba, 30, 30);
+ else if (mid == UFS_VENDOR_TOSHIBA)
+ ufs_mtk_setup_ref_clk_wait_us(hba, 100, 32);
+
return 0;
}
diff --git a/drivers/scsi/ufs/ufs-mediatek.h b/drivers/scsi/ufs/ufs-mediatek.h
index 492414e5f481..4c787b99fe41 100644
--- a/drivers/scsi/ufs/ufs-mediatek.h
+++ b/drivers/scsi/ufs/ufs-mediatek.h
@@ -92,6 +92,8 @@ struct ufs_mtk_host {
struct ufs_hba *hba;
struct phy *mphy;
bool ref_clk_enabled;
+ u16 ref_clk_ungating_wait_us;
+ u16 ref_clk_gating_wait_us;
};
#endif /* !_UFS_MEDIATEK_H */
--
2.18.0
_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek
^ permalink raw reply related
* Re: [f2fs-dev] [PATCH v7 14/24] btrfs: Convert from readpages to readahead
From: Matthew Wilcox @ 2020-02-20 13:48 UTC (permalink / raw)
To: Johannes Thumshirn
Cc: linux-xfs@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com,
linux-mm@kvack.org, ocfs2-devel@oss.oracle.com,
linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org,
linux-erofs@lists.ozlabs.org, linux-btrfs@vger.kernel.org
In-Reply-To: <SN4PR0401MB35987D7B76007B93B1C5CE5E9B130@SN4PR0401MB3598.namprd04.prod.outlook.com>
On Thu, Feb 20, 2020 at 09:42:19AM +0000, Johannes Thumshirn wrote:
> On 19/02/2020 22:03, Matthew Wilcox wrote:
> > From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> >
> > Use the new readahead operation in btrfs. Add a
> > readahead_for_each_batch() iterator to optimise the loop in the XArray.
>
> OK I must admit I haven't followed this series closely, but what
> happened to said readahead_for_each_batch()?
>
> As far as I can see it's now:
>
> [...]
> > + while ((nr = readahead_page_batch(rac, pagepool))) {
Oops, forgot to update the changelog there. Yes, that's exactly what it
changed to. That discussion was here:
https://lore.kernel.org/linux-fsdevel/20200219144117.GP24185@bombadil.infradead.org/
... and then Christoph pointed out the iterators weren't really adding
much value at that point, so they got deleted. New changelog for
this patch:
btrfs: Convert from readpages to readahead
Implement the new readahead method in btrfs. Add a readahead_page_batch()
to optimise fetching a batch of pages at once.
_______________________________________________
Linux-f2fs-devel mailing list
Linux-f2fs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel
^ permalink raw reply
* [PATCH v2 1/1] scsi: ufs: ufs-mediatek: add waiting time for reference clock
From: Stanley Chu @ 2020-02-20 13:48 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: beanhuo, asutoshd, cang, matthias.bgg, bvanassche, linux-mediatek,
linux-arm-kernel, linux-kernel, kuohong.wang, peter.wang,
chun-hung.wu, andy.teng, Stanley Chu
In-Reply-To: <20200220134848.8807-1-stanley.chu@mediatek.com>
Some delays may be required either after gating or before ungating
reference clock for device according to vendor requirements.
Note that in UFS 3.0, the delay time after gating reference
clock can be defined by attribute bRefClkGatingWaitTime. Use the
formal value instead if it can be queried from device.
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
---
drivers/scsi/ufs/ufs-mediatek.c | 46 +++++++++++++++++++++++++++++++--
drivers/scsi/ufs/ufs-mediatek.h | 2 ++
2 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 9d05962feb15..de650822c9d9 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -100,6 +100,17 @@ static int ufs_mtk_bind_mphy(struct ufs_hba *hba)
return err;
}
+static void ufs_mtk_udelay(unsigned long us)
+{
+ if (!us)
+ return;
+
+ if (us < 10)
+ udelay(us);
+ else
+ usleep_range(us, us + 10);
+}
+
static int ufs_mtk_setup_ref_clk(struct ufs_hba *hba, bool on)
{
struct ufs_mtk_host *host = ufshcd_get_variant(hba);
@@ -112,6 +123,7 @@ static int ufs_mtk_setup_ref_clk(struct ufs_hba *hba, bool on)
if (on) {
ufs_mtk_ref_clk_notify(on, res);
+ ufs_mtk_udelay(host->ref_clk_ungating_wait_us);
ufshcd_writel(hba, REFCLK_REQUEST, REG_UFS_REFCLK_CTRL);
} else {
ufshcd_writel(hba, REFCLK_RELEASE, REG_UFS_REFCLK_CTRL);
@@ -137,12 +149,29 @@ static int ufs_mtk_setup_ref_clk(struct ufs_hba *hba, bool on)
out:
host->ref_clk_enabled = on;
- if (!on)
+ if (!on) {
+ ufs_mtk_udelay(host->ref_clk_gating_wait_us);
ufs_mtk_ref_clk_notify(on, res);
+ }
return 0;
}
+static void ufs_mtk_setup_ref_clk_wait_us(struct ufs_hba *hba,
+ u16 gating_us, u16 ungating_us)
+{
+ struct ufs_mtk_host *host = ufshcd_get_variant(hba);
+
+ if (hba->dev_info.clk_gating_wait_us) {
+ host->ref_clk_gating_wait_us =
+ hba->dev_info.clk_gating_wait_us;
+ } else {
+ host->ref_clk_gating_wait_us = gating_us;
+ }
+
+ host->ref_clk_ungating_wait_us = ungating_us;
+}
+
static u32 ufs_mtk_link_get_state(struct ufs_hba *hba)
{
u32 val;
@@ -502,10 +531,23 @@ static void ufs_mtk_dbg_register_dump(struct ufs_hba *hba)
static int ufs_mtk_apply_dev_quirks(struct ufs_hba *hba)
{
struct ufs_dev_info *dev_info = &hba->dev_info;
+ u16 mid = dev_info->wmanufacturerid;
- if (dev_info->wmanufacturerid == UFS_VENDOR_SAMSUNG)
+ if (mid == UFS_VENDOR_SAMSUNG)
ufshcd_dme_set(hba, UIC_ARG_MIB(PA_TACTIVATE), 6);
+ /*
+ * Decide waiting time before gating reference clock and
+ * after ungating reference clock according to vendors'
+ * requirements.
+ */
+ if (mid == UFS_VENDOR_SAMSUNG)
+ ufs_mtk_setup_ref_clk_wait_us(hba, 1, 1);
+ else if (mid == UFS_VENDOR_SKHYNIX)
+ ufs_mtk_setup_ref_clk_wait_us(hba, 30, 30);
+ else if (mid == UFS_VENDOR_TOSHIBA)
+ ufs_mtk_setup_ref_clk_wait_us(hba, 100, 32);
+
return 0;
}
diff --git a/drivers/scsi/ufs/ufs-mediatek.h b/drivers/scsi/ufs/ufs-mediatek.h
index 492414e5f481..4c787b99fe41 100644
--- a/drivers/scsi/ufs/ufs-mediatek.h
+++ b/drivers/scsi/ufs/ufs-mediatek.h
@@ -92,6 +92,8 @@ struct ufs_mtk_host {
struct ufs_hba *hba;
struct phy *mphy;
bool ref_clk_enabled;
+ u16 ref_clk_ungating_wait_us;
+ u16 ref_clk_gating_wait_us;
};
#endif /* !_UFS_MEDIATEK_H */
--
2.18.0
^ permalink raw reply related
* [PATCH v2 1/1] scsi: ufs: ufs-mediatek: add waiting time for reference clock
From: Stanley Chu @ 2020-02-20 13:48 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: Stanley Chu, bvanassche, andy.teng, chun-hung.wu, kuohong.wang,
linux-kernel, cang, linux-mediatek, peter.wang, matthias.bgg,
beanhuo, linux-arm-kernel, asutoshd
In-Reply-To: <20200220134848.8807-1-stanley.chu@mediatek.com>
Some delays may be required either after gating or before ungating
reference clock for device according to vendor requirements.
Note that in UFS 3.0, the delay time after gating reference
clock can be defined by attribute bRefClkGatingWaitTime. Use the
formal value instead if it can be queried from device.
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
---
drivers/scsi/ufs/ufs-mediatek.c | 46 +++++++++++++++++++++++++++++++--
drivers/scsi/ufs/ufs-mediatek.h | 2 ++
2 files changed, 46 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/ufs/ufs-mediatek.c b/drivers/scsi/ufs/ufs-mediatek.c
index 9d05962feb15..de650822c9d9 100644
--- a/drivers/scsi/ufs/ufs-mediatek.c
+++ b/drivers/scsi/ufs/ufs-mediatek.c
@@ -100,6 +100,17 @@ static int ufs_mtk_bind_mphy(struct ufs_hba *hba)
return err;
}
+static void ufs_mtk_udelay(unsigned long us)
+{
+ if (!us)
+ return;
+
+ if (us < 10)
+ udelay(us);
+ else
+ usleep_range(us, us + 10);
+}
+
static int ufs_mtk_setup_ref_clk(struct ufs_hba *hba, bool on)
{
struct ufs_mtk_host *host = ufshcd_get_variant(hba);
@@ -112,6 +123,7 @@ static int ufs_mtk_setup_ref_clk(struct ufs_hba *hba, bool on)
if (on) {
ufs_mtk_ref_clk_notify(on, res);
+ ufs_mtk_udelay(host->ref_clk_ungating_wait_us);
ufshcd_writel(hba, REFCLK_REQUEST, REG_UFS_REFCLK_CTRL);
} else {
ufshcd_writel(hba, REFCLK_RELEASE, REG_UFS_REFCLK_CTRL);
@@ -137,12 +149,29 @@ static int ufs_mtk_setup_ref_clk(struct ufs_hba *hba, bool on)
out:
host->ref_clk_enabled = on;
- if (!on)
+ if (!on) {
+ ufs_mtk_udelay(host->ref_clk_gating_wait_us);
ufs_mtk_ref_clk_notify(on, res);
+ }
return 0;
}
+static void ufs_mtk_setup_ref_clk_wait_us(struct ufs_hba *hba,
+ u16 gating_us, u16 ungating_us)
+{
+ struct ufs_mtk_host *host = ufshcd_get_variant(hba);
+
+ if (hba->dev_info.clk_gating_wait_us) {
+ host->ref_clk_gating_wait_us =
+ hba->dev_info.clk_gating_wait_us;
+ } else {
+ host->ref_clk_gating_wait_us = gating_us;
+ }
+
+ host->ref_clk_ungating_wait_us = ungating_us;
+}
+
static u32 ufs_mtk_link_get_state(struct ufs_hba *hba)
{
u32 val;
@@ -502,10 +531,23 @@ static void ufs_mtk_dbg_register_dump(struct ufs_hba *hba)
static int ufs_mtk_apply_dev_quirks(struct ufs_hba *hba)
{
struct ufs_dev_info *dev_info = &hba->dev_info;
+ u16 mid = dev_info->wmanufacturerid;
- if (dev_info->wmanufacturerid == UFS_VENDOR_SAMSUNG)
+ if (mid == UFS_VENDOR_SAMSUNG)
ufshcd_dme_set(hba, UIC_ARG_MIB(PA_TACTIVATE), 6);
+ /*
+ * Decide waiting time before gating reference clock and
+ * after ungating reference clock according to vendors'
+ * requirements.
+ */
+ if (mid == UFS_VENDOR_SAMSUNG)
+ ufs_mtk_setup_ref_clk_wait_us(hba, 1, 1);
+ else if (mid == UFS_VENDOR_SKHYNIX)
+ ufs_mtk_setup_ref_clk_wait_us(hba, 30, 30);
+ else if (mid == UFS_VENDOR_TOSHIBA)
+ ufs_mtk_setup_ref_clk_wait_us(hba, 100, 32);
+
return 0;
}
diff --git a/drivers/scsi/ufs/ufs-mediatek.h b/drivers/scsi/ufs/ufs-mediatek.h
index 492414e5f481..4c787b99fe41 100644
--- a/drivers/scsi/ufs/ufs-mediatek.h
+++ b/drivers/scsi/ufs/ufs-mediatek.h
@@ -92,6 +92,8 @@ struct ufs_mtk_host {
struct ufs_hba *hba;
struct phy *mphy;
bool ref_clk_enabled;
+ u16 ref_clk_ungating_wait_us;
+ u16 ref_clk_gating_wait_us;
};
#endif /* !_UFS_MEDIATEK_H */
--
2.18.0
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply related
* [PATCH v2 0/1] scsi: ufs: fix waiting time for reference clock
From: Stanley Chu @ 2020-02-20 13:48 UTC (permalink / raw)
To: linux-scsi, martin.petersen, avri.altman, alim.akhtar, jejb
Cc: beanhuo, asutoshd, cang, matthias.bgg, bvanassche, linux-mediatek,
linux-arm-kernel, linux-kernel, kuohong.wang, peter.wang,
chun-hung.wu, andy.teng, Stanley Chu
Hi,
This patchset adds waiting time for reference clock provided to UFS device in MediaTek UFS implementation.
v1 -> v2:
- Drop patch #1 "scsi: ufs: add required delay after gating reference clock" since it will impact ufs-qcom flow without solid conclusion yet.
Stanley Chu (1):
scsi: ufs: ufs-mediatek: add waiting time for reference clock
drivers/scsi/ufs/ufs-mediatek.c | 46 +++++++++++++++++++++++++++++++--
drivers/scsi/ufs/ufs-mediatek.h | 2 ++
2 files changed, 46 insertions(+), 2 deletions(-)
--
2.18.0
^ permalink raw reply
* Re: [PATCH v7 14/24] btrfs: Convert from readpages to readahead
From: Matthew Wilcox @ 2020-02-20 13:48 UTC (permalink / raw)
To: Johannes Thumshirn
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org,
linux-erofs@lists.ozlabs.org, linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com,
ocfs2-devel@oss.oracle.com, linux-xfs@vger.kernel.org
In-Reply-To: <SN4PR0401MB35987D7B76007B93B1C5CE5E9B130@SN4PR0401MB3598.namprd04.prod.outlook.com>
On Thu, Feb 20, 2020 at 09:42:19AM +0000, Johannes Thumshirn wrote:
> On 19/02/2020 22:03, Matthew Wilcox wrote:
> > From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> >
> > Use the new readahead operation in btrfs. Add a
> > readahead_for_each_batch() iterator to optimise the loop in the XArray.
>
> OK I must admit I haven't followed this series closely, but what
> happened to said readahead_for_each_batch()?
>
> As far as I can see it's now:
>
> [...]
> > + while ((nr = readahead_page_batch(rac, pagepool))) {
Oops, forgot to update the changelog there. Yes, that's exactly what it
changed to. That discussion was here:
https://lore.kernel.org/linux-fsdevel/20200219144117.GP24185@bombadil.infradead.org/
... and then Christoph pointed out the iterators weren't really adding
much value at that point, so they got deleted. New changelog for
this patch:
btrfs: Convert from readpages to readahead
Implement the new readahead method in btrfs. Add a readahead_page_batch()
to optimise fetching a batch of pages at once.
^ permalink raw reply
* [Ocfs2-devel] [PATCH v7 14/24] btrfs: Convert from readpages to readahead
From: Matthew Wilcox @ 2020-02-20 13:48 UTC (permalink / raw)
To: Johannes Thumshirn
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org,
linux-erofs@lists.ozlabs.org, linux-ext4@vger.kernel.org,
linux-f2fs-devel@lists.sourceforge.net, cluster-devel@redhat.com,
ocfs2-devel@oss.oracle.com, linux-xfs@vger.kernel.org
In-Reply-To: <SN4PR0401MB35987D7B76007B93B1C5CE5E9B130@SN4PR0401MB3598.namprd04.prod.outlook.com>
On Thu, Feb 20, 2020 at 09:42:19AM +0000, Johannes Thumshirn wrote:
> On 19/02/2020 22:03, Matthew Wilcox wrote:
> > From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> >
> > Use the new readahead operation in btrfs. Add a
> > readahead_for_each_batch() iterator to optimise the loop in the XArray.
>
> OK I must admit I haven't followed this series closely, but what
> happened to said readahead_for_each_batch()?
>
> As far as I can see it's now:
>
> [...]
> > + while ((nr = readahead_page_batch(rac, pagepool))) {
Oops, forgot to update the changelog there. Yes, that's exactly what it
changed to. That discussion was here:
https://urldefense.com/v3/__https://lore.kernel.org/linux-fsdevel/20200219144117.GP24185 at bombadil.infradead.org/__;!!GqivPVa7Brio!NowpsY7jqCHi3nk-7KYRB6OMBhU9RUBOzzoIQZqqy0USKzVxxygQi3ltRqDxPjzhgEcEiw$
... and then Christoph pointed out the iterators weren't really adding
much value at that point, so they got deleted. New changelog for
this patch:
btrfs: Convert from readpages to readahead
Implement the new readahead method in btrfs. Add a readahead_page_batch()
to optimise fetching a batch of pages at once.
^ permalink raw reply
* [Cluster-devel] [PATCH v7 14/24] btrfs: Convert from readpages to readahead
From: Matthew Wilcox @ 2020-02-20 13:48 UTC (permalink / raw)
To: cluster-devel.redhat.com
In-Reply-To: <SN4PR0401MB35987D7B76007B93B1C5CE5E9B130@SN4PR0401MB3598.namprd04.prod.outlook.com>
On Thu, Feb 20, 2020 at 09:42:19AM +0000, Johannes Thumshirn wrote:
> On 19/02/2020 22:03, Matthew Wilcox wrote:
> > From: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> >
> > Use the new readahead operation in btrfs. Add a
> > readahead_for_each_batch() iterator to optimise the loop in the XArray.
>
> OK I must admit I haven't followed this series closely, but what
> happened to said readahead_for_each_batch()?
>
> As far as I can see it's now:
>
> [...]
> > + while ((nr = readahead_page_batch(rac, pagepool))) {
Oops, forgot to update the changelog there. Yes, that's exactly what it
changed to. That discussion was here:
https://lore.kernel.org/linux-fsdevel/20200219144117.GP24185 at bombadil.infradead.org/
... and then Christoph pointed out the iterators weren't really adding
much value at that point, so they got deleted. New changelog for
this patch:
btrfs: Convert from readpages to readahead
Implement the new readahead method in btrfs. Add a readahead_page_batch()
to optimise fetching a batch of pages at once.
^ 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.