* Re: [PATCHv2] fpga: stratix10-soc: remove the pre-set reconfiguration condition
From: Russ Weight @ 2020-05-29 16:18 UTC (permalink / raw)
To: Richard Gong, mdf; +Cc: linux-fpga, linux-kernel, dinguyen, Richard Gong
In-Reply-To: <1d9b21df-7421-b25e-5139-f297e24d99d4@linux.intel.com>
Minor comment below.
- Russ
On 5/29/20 6:15 AM, Richard Gong wrote:
> Hi Moritz,
>
> Sorry for asking.
>
> When you get chance, can you review my version 2 patch submitted on
> 05/15/20?
>
> Regards,
> Richard
>
> On 5/15/20 9:35 AM, richard.gong@linux.intel.com wrote:
>> From: Richard Gong <richard.gong@intel.com>
>>
>> The reconfiguration mode is pre-set by driver as the full
>> reconfiguration.
>> As a result, user have to change code and recompile the drivers if he or
>> she wants to perform a partial reconfiguration. Removing the pre-set
>> reconfiguration condition so that user can select full or partial
>> reconfiguration via overlay device tree without recompiling the drivers.
>>
>> Also add an error message if the configuration request is failure.
s/is failure/fails/
>>
>> Signed-off-by: Richard Gong <richard.gong@intel.com>
>> ---
>> v2: define and use constant values
>> ---
>> drivers/fpga/stratix10-soc.c | 9 +++++++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/fpga/stratix10-soc.c b/drivers/fpga/stratix10-soc.c
>> index 44b7c56..4d52a80 100644
>> --- a/drivers/fpga/stratix10-soc.c
>> +++ b/drivers/fpga/stratix10-soc.c
>> @@ -14,9 +14,13 @@
>> /*
>> * FPGA programming requires a higher level of privilege (EL3), per
>> the SoC
>> * design.
>> + * SoC firmware supports full and partial reconfiguration.
>> */
>> #define NUM_SVC_BUFS 4
>> #define SVC_BUF_SIZE SZ_512K
>> +#define FULL_RECONFIG_FLAG 0
>> +#define PARTIAL_RECONFIG_FLAG 1
>> +
>> /* Indicates buffer is in use if set */
>> #define SVC_BUF_LOCK 0
>> @@ -182,12 +186,12 @@ static int s10_ops_write_init(struct
>> fpga_manager *mgr,
>> uint i;
>> int ret;
>> - ctype.flags = 0;
>> if (info->flags & FPGA_MGR_PARTIAL_RECONFIG) {
>> dev_dbg(dev, "Requesting partial reconfiguration.\n");
>> - ctype.flags |= BIT(COMMAND_RECONFIG_FLAG_PARTIAL);
>> + ctype.flags = PARTIAL_RECONFIG_FLAG;
>> } else {
>> dev_dbg(dev, "Requesting full reconfiguration.\n");
>> + ctype.flags = FULL_RECONFIG_FLAG;
>> }
>> reinit_completion(&priv->status_return_completion);
>> @@ -210,6 +214,7 @@ static int s10_ops_write_init(struct fpga_manager
>> *mgr,
>> ret = 0;
>> if (!test_and_clear_bit(SVC_STATUS_OK, &priv->status)) {
>> + dev_err(dev, "RECONFIG_REQUEST failed\n");
>> ret = -ETIMEDOUT;
>> goto init_done;
>> }
>>
^ permalink raw reply
* Re: [PATCH v8 0/8] Add support for devices in the Energy Model
From: Rafael J. Wysocki @ 2020-05-29 16:18 UTC (permalink / raw)
To: Lukasz Luba
Cc: Nishanth Menon, Juri Lelli, Peter Zijlstra, Viresh Kumar,
Liviu Dudau, dri-devel, Bjorn Andersson, Benjamin Segall,
alyssa.rosenzweig, Matthias Kaehlcke, Amit Kucheria,
Lorenzo Pieralisi, Vincent Guittot, Kevin Hilman, Andy Gross,
Daniel Lezcano, steven.price, Chanwoo Choi, Ingo Molnar,
dl-linux-imx, Zhang, Rui, Mel Gorman, orjan.eide, Linux PM,
linux-arm-msm, Sascha Hauer, Steven Rostedt,
moderated list:ARM/Mediatek SoC..., Matthias Brugger,
Linux OMAP Mailing List, Dietmar Eggemann, Linux ARM,
David Airlie, Tomeu Vizoso, Quentin Perret, Stephen Boyd,
Randy Dunlap, Rafael J. Wysocki, Linux Kernel Mailing List,
Bartlomiej Zolnierkiewicz, Sascha Hauer, Sudeep Holla,
patrick.bellasi, Shawn Guo
In-Reply-To: <8fca24a1-93f7-f859-bd1f-b7bf484737f4@arm.com>
On Fri, May 29, 2020 at 5:01 PM Lukasz Luba <lukasz.luba@arm.com> wrote:
>
> Hi Rafael,
>
>
> On 5/27/20 10:58 AM, Lukasz Luba wrote:
> > Hi all,
> >
> > Background of this version:
> > This is the v8 of the patch set and is has smaller scope. I had to split
> > the series into two: EM changes and thermal changes due to devfreq
> > dependencies. The patches from v7 9-14 which change devfreq cooling are
> > going to be sent in separate patch series, just after this set get merged
> > into mainline. These patches related to EM got acks and hopefully can go
> > through linux-pm tree. The later thermal patches will go through thermal
> > tree.
> >
> > The idea and purpose of the Energy Model framework changes:
> > This patch set introduces support for devices in the Energy Model (EM)
> > framework. It will unify the power model for thermal subsystem. It will
> > make simpler to add support for new devices willing to use more
> > advanced features (like Intelligent Power Allocation). Now it should
> > require less knowledge and effort for driver developer to add e.g.
> > GPU driver with simple energy model. A more sophisticated energy model
> > in the thermal framework is also possible, driver needs to provide
> > a dedicated callback function. More information can be found in the
> > updated documentation file.
> >
> > First 7 patches are refactoring Energy Model framework to add support
> > of other devices that CPUs. They change:
> > - naming convention from 'capacity' to 'performance' state,
> > - API arguments adding device pointer and not rely only on cpumask,
> > - change naming when 'cpu' was used, now it's a 'device'
> > - internal structure to maintain registered devices
> > - update users to the new API
> > Patch 8 updates OPP framework helper function to be more generic, not
> > CPU specific.
> >
> > The patch set is based on linux-pm branch linux-next 813946019dfd.
> >
>
> Could you take the patch set via your linux-pm?
I can do that, but I didn't realize that it was targeted at me, so I
need some more time to review the patches.
Thanks!
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH] block: improve discard bio alignment in __blkdev_issue_discard()
From: Bart Van Assche @ 2020-05-29 16:17 UTC (permalink / raw)
To: Coly Li, linux-block
Cc: Acshai Manoj, Christoph Hellwig, Enzo Matsumiya, Hannes Reinecke,
Jens Axboe, Ming Lei, Xiao Ni
In-Reply-To: <20200529160350.99710-1-colyli@suse.de>
On 2020-05-29 09:03, Coly Li wrote:
> +static inline unsigned int bio_aligned_discard_max_sectors(
> + struct request_queue *q)
> +{
> + return round_down(UINT_MAX, (q->limits.max_discard_sectors << 9)) >> 9;
> +}
How about changing '9' into 'SECTOR_SHIFT'?
Thanks,
Bart.
^ permalink raw reply
* Re: [PATCH] sched/headers: Fix sched_setattr userspace compilation breakage
From: Joel Fernandes @ 2020-05-29 16:17 UTC (permalink / raw)
To: Linus Torvalds
Cc: Linux Kernel Mailing List, Matthew Blecker, Jesse Barnes,
Mike Frysinger, Christian Brauner, vpillai, vineethrp,
Peter Zijlstra, stable, Greg Kroah-Hartman, Ingo Molnar
In-Reply-To: <CAHk-=wgO86MS-=G2D=aDpOvZVYARD2kBZ43sofX6WwK0OAzmwg@mail.gmail.com>
Hi Linus,
On Thu, May 28, 2020 at 07:17:38PM -0700, Linus Torvalds wrote:
> On Thu, May 28, 2020 at 6:45 PM Joel Fernandes <joel@joelfernandes.org> wrote:
> >
> > glibc's <sched.h> already defines struct sched_param (which is a POSIX
> > struct), so my inclusion of <linux/sched/types.h> above which is a UAPI
> > header exported by the kernel, breaks because the following commit moved
> > sched_param into the UAPI:
> > e2d1e2aec572a ("sched/headers: Move various ABI definitions to <uapi/linux/sched/types.h>")
> >
> > Simply reverting that part of the patch also fixes it, like below. Would
> > that be an acceptable fix? Then I can go patch glibc to get struct
> > sched_attr by including the UAPI's <linux/sched/types.h>. Otherwise, I
> > suspect glibc will also break if it tried to include the UAPI header.
>
> Hmm.
>
> Reverting that commit makes some sense as a "it broke things", and
> yes, if this was some recent change that caused problems with user
> headers, that would be what we should do (at least to then think about
> it a bit more).
>
> But that commit was done three years ago and you're the first person
> to report breakage.
>
> So for all I know, modern glibc source bases have already fixed
> themselves up, and take advantage of the new UAPI location. Or they
> just did that kernel header sync many years ago, and will fix it up
> the next time they do a header sync.
>
> So then reverting things (or adding the __KERNEL__ guard) would only
> break _those_ cases instead and make for only more problems.
>
> Basically, I think you should treat this as a glibc header bug, not a
> kernel header bug.
Got it, thanks.
> And when you say
> > The reason is, since <sched.h> did not provide struct sched_attr as the
> > manpage said, so I did the include of uapi's linux/sched/types.h myself:
>
> instead of starting to include the kernel uapi header files - that
> interact at a deep level with those system header files - you should
> just treat it as a glibc bug.
>
> And then you can either work around it locally, or make a glibc
> bug-report and hope it gets fixed that way.
>
> The "work around it locally" might be something like a
> "glibc-sched-h-fixup.h" header file that does
>
> #ifndef SCHED_FIXUP_H
> #define SCHED_FIXUP_H
> #include <sched.h>
>
> /* This is documented to come from <sched.h>, but doesn't */
> struct sched_attr {
> __u32 size;
>
> __u32 sched_policy;
> __u64 sched_flags;
>
> /* SCHED_NORMAL, SCHED_BATCH */
> __s32 sched_nice;
>
> /* SCHED_FIFO, SCHED_RR */
> __u32 sched_priority;
>
> /* SCHED_DEADLINE */
> __u64 sched_runtime;
> __u64 sched_deadline;
> __u64 sched_period;
>
> /* Utilization hints */
> __u32 sched_util_min;
> __u32 sched_util_max;
>
> };
> #end /* SCHED_FIXUP_H */
>
> in your build environment (possibly with configure magic etc to find
> the need for this fixup, depending on how fancy you want to be).
Got it, I will look into these options. Thanks.
Turns out I hit the same/similar issue in 2018 but for a different reason. At
the time I was working on Android and needed this struct. The bionic C
library folks refused to add it because no other libc exposed it either (that
was their reason to not have it, anyway). I suspect everyone was just doing
their own fixups to use it and that was what I was asked to do.
I think it would be better to just do the fixup you suggested above for now.
> Because when we have a change that is three+ years old, we can't
> reasonably change the kernel back again without then likely just
> breaking some other case that depends on that uapi file that has been
> there for the last few years.
>
> glibc and the kernel aren't developed in sync, so glibc generally
> takes a snapshot of the kernel headers and then works with that. That
> allows glibc developers to work around any issues they have with our
> uapi headers (we've had lots of namespace issues, for example), but it
> also means that the system headers aren't using some "generic kernel
> UAPI headers". They are using a very _particular_ set of kernel uapi
> headers from (likely) several years ago, and quite possibly then
> further edited too.
>
> Which is why you can't then mix glibc system headers that are years
> old with kernel headers that are modern (or vice versa).
>
> Well, with extreme luck and/or care you can. But not in general.
Got it, thank you Linus !!!
- Joel
^ permalink raw reply
* Re: [PATCH v6 4/9] dt-bindings: display: panel: Add ilitek ili9341 panel bindings
From: Rob Herring @ 2020-05-29 16:17 UTC (permalink / raw)
To: dillon.minfei
Cc: dillonhua, airlied, linus.walleij, dri-devel, thierry.reding, sam,
linux-stm32, linux-clk, andy.shevchenko, p.zabel, mturquette,
devicetree, alexandre.torgue, robh+dt, daniel, linux-arm-kernel,
sboyd, linux-kernel, linux-spi, noralf, broonie, mcoquelin.stm32
In-Reply-To: <1590564453-24499-5-git-send-email-dillon.minfei@gmail.com>
On Wed, 27 May 2020 15:27:28 +0800, dillon.minfei@gmail.com wrote:
> From: dillon min <dillon.minfei@gmail.com>
>
> Add documentation for "ilitek,ili9341" panel.
>
> Signed-off-by: dillon min <dillon.minfei@gmail.com>
> ---
> .../bindings/display/panel/ilitek,ili9341.yaml | 69 ++++++++++++++++++++++
> 1 file changed, 69 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH v6 4/9] dt-bindings: display: panel: Add ilitek ili9341 panel bindings
From: Rob Herring @ 2020-05-29 16:17 UTC (permalink / raw)
To: dillon.minfei
Cc: dillonhua, airlied, dri-devel, thierry.reding, sam, linux-stm32,
linux-clk, andy.shevchenko, mturquette, devicetree,
alexandre.torgue, robh+dt, linux-arm-kernel, sboyd, linux-kernel,
linux-spi, broonie, mcoquelin.stm32
In-Reply-To: <1590564453-24499-5-git-send-email-dillon.minfei@gmail.com>
On Wed, 27 May 2020 15:27:28 +0800, dillon.minfei@gmail.com wrote:
> From: dillon min <dillon.minfei@gmail.com>
>
> Add documentation for "ilitek,ili9341" panel.
>
> Signed-off-by: dillon min <dillon.minfei@gmail.com>
> ---
> .../bindings/display/panel/ilitek,ili9341.yaml | 69 ++++++++++++++++++++++
> 1 file changed, 69 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v6 4/9] dt-bindings: display: panel: Add ilitek ili9341 panel bindings
From: Rob Herring @ 2020-05-29 16:17 UTC (permalink / raw)
To: dillon.minfei
Cc: robh+dt, alexandre.torgue, dillonhua, daniel, linux-spi,
mturquette, linux-clk, sam, mcoquelin.stm32, devicetree,
linus.walleij, linux-arm-kernel, thierry.reding, sboyd, broonie,
noralf, airlied, dri-devel, linux-kernel, andy.shevchenko,
p.zabel, linux-stm32
In-Reply-To: <1590564453-24499-5-git-send-email-dillon.minfei@gmail.com>
On Wed, 27 May 2020 15:27:28 +0800, dillon.minfei@gmail.com wrote:
> From: dillon min <dillon.minfei@gmail.com>
>
> Add documentation for "ilitek,ili9341" panel.
>
> Signed-off-by: dillon min <dillon.minfei@gmail.com>
> ---
> .../bindings/display/panel/ilitek,ili9341.yaml | 69 ++++++++++++++++++++++
> 1 file changed, 69 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/panel/ilitek,ili9341.yaml
>
Reviewed-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PULL 00/21] Vga 20200528 patches
From: Philippe Mathieu-Daudé @ 2020-05-29 16:15 UTC (permalink / raw)
To: Peter Maydell, Gerd Hoffmann
Cc: Igor Mitsyanko, Alistair Francis, Mark Cave-Ayland,
QEMU Developers, qemu-arm, qemu-ppc
In-Reply-To: <CAFEAcA98OyyyC6gs34e3U03=dXz8GkDn5qf38UaO_XBB679V+g@mail.gmail.com>
Hi Peter,
On 5/29/20 12:29 PM, Peter Maydell wrote:
> On Thu, 28 May 2020 at 13:36, Gerd Hoffmann <kraxel@redhat.com> wrote:
>>
>> The following changes since commit 06539ebc76b8625587aa78d646a9d8d5fddf84f3:
>>
>> Merge remote-tracking branch 'remotes/philmd-gitlab/tags/mips-hw-next-20200526' into staging (2020-05-26 20:25:06 +0100)
>>
>> are available in the Git repository at:
>>
>> git://git.kraxel.org/qemu tags/vga-20200528-pull-request
>>
>> for you to fetch changes up to fa0013a1bc5f6011a1017e0e655740403e5555d9:
>>
>> sm501: Remove obsolete changelog and todo comment (2020-05-28 11:38:57 +0200)
>>
>> ----------------------------------------------------------------
>> hw/dispaly/sm501: bugfixes, add sanity checks.
>> hw/display: use tracepoints, misc cleanups.
>>
>
>
> Applied, thanks.
>
> Please update the changelog at https://wiki.qemu.org/ChangeLog/5.1
> for any user-visible changes.
>
> Could somebody send a followup patch to fix the indentation
> error checkpatch notices, please?
If this is part of your scripts, this is a nice feature :)
>
> 5/21 Checking commit 97f369f2479d (hw/display/cirrus_vga: Use
> qemu_log_mask(ERROR) instead of debug printf)
> ERROR: suspect code indent for conditional statements (16, 12)
> #34: FILE: hw/display/cirrus_vga.c:1038:
> if (s->cirrus_blt_pixelwidth > 2) {
> + qemu_log_mask(LOG_GUEST_ERROR,
I explained on the patches:
False positive.
Checkpatch is confused by the mis-indented code
previous to this line.
https://www.mail-archive.com/qemu-devel@nongnu.org/msg706364.html
>
> -- PMM
>
^ permalink raw reply
* Re: [PULL 00/21] Vga 20200528 patches
From: Philippe Mathieu-Daudé @ 2020-05-29 16:15 UTC (permalink / raw)
To: Peter Maydell, Gerd Hoffmann
Cc: Igor Mitsyanko, Alistair Francis, Mark Cave-Ayland,
QEMU Developers, BALATON Zoltan, qemu-arm, qemu-ppc,
Andrzej Zaborowski
In-Reply-To: <CAFEAcA98OyyyC6gs34e3U03=dXz8GkDn5qf38UaO_XBB679V+g@mail.gmail.com>
Hi Peter,
On 5/29/20 12:29 PM, Peter Maydell wrote:
> On Thu, 28 May 2020 at 13:36, Gerd Hoffmann <kraxel@redhat.com> wrote:
>>
>> The following changes since commit 06539ebc76b8625587aa78d646a9d8d5fddf84f3:
>>
>> Merge remote-tracking branch 'remotes/philmd-gitlab/tags/mips-hw-next-20200526' into staging (2020-05-26 20:25:06 +0100)
>>
>> are available in the Git repository at:
>>
>> git://git.kraxel.org/qemu tags/vga-20200528-pull-request
>>
>> for you to fetch changes up to fa0013a1bc5f6011a1017e0e655740403e5555d9:
>>
>> sm501: Remove obsolete changelog and todo comment (2020-05-28 11:38:57 +0200)
>>
>> ----------------------------------------------------------------
>> hw/dispaly/sm501: bugfixes, add sanity checks.
>> hw/display: use tracepoints, misc cleanups.
>>
>
>
> Applied, thanks.
>
> Please update the changelog at https://wiki.qemu.org/ChangeLog/5.1
> for any user-visible changes.
>
> Could somebody send a followup patch to fix the indentation
> error checkpatch notices, please?
If this is part of your scripts, this is a nice feature :)
>
> 5/21 Checking commit 97f369f2479d (hw/display/cirrus_vga: Use
> qemu_log_mask(ERROR) instead of debug printf)
> ERROR: suspect code indent for conditional statements (16, 12)
> #34: FILE: hw/display/cirrus_vga.c:1038:
> if (s->cirrus_blt_pixelwidth > 2) {
> + qemu_log_mask(LOG_GUEST_ERROR,
I explained on the patches:
False positive.
Checkpatch is confused by the mis-indented code
previous to this line.
https://www.mail-archive.com/qemu-devel@nongnu.org/msg706364.html
>
> -- PMM
>
^ permalink raw reply
* Re: [PATCH 0/2] xen: credit2: limit the number of CPUs per runqueue
From: George Dunlap @ 2020-05-29 16:15 UTC (permalink / raw)
To: Dario Faggioli
Cc: Juergen Gross, xen-devel@lists.xenproject.org, Paul Durrant,
Jan Beulich, Andrew Cooper
In-Reply-To: <ab810b293ca8324ca3fba22476401a58435243fa.camel@suse.com>
> On May 29, 2020, at 12:46 PM, Dario Faggioli <dfaggioli@suse.com> wrote:
>
> So,
>
> I felt like providing some additional thoughts about this series, from
> a release point of view (adding Paul).
>
> Timing is *beyond tight* so if this series, entirely or partly, has any
> chance to go in, it would be through some form of exception, which of
> course comes with some risks, etc.
>
> I did work hard to submit the full series, because I wanted people to
> be able to see the complete solution. However, I think the series
> itself can be logically split in two parts.
>
> Basically, if we just consider patches 1 and 4 we will end up, right
> after boot, with a system that has smaller runqueues. They will most
> likely be balanced in terms of how many CPUs each one has, so a good
> setup. This will likely (actual differences seems to depend *quite a
> bit* on the actual workload) be an improvement for very large systems.
Fundamentally, I feel like the reason we have the feature freeze is exactly to have to avoid questions like this. Something very much like patch 4 was posted before the last posting date; patches 1-4 received R-b’s before the feature freeze. I think they should probably go in.
The rebalancing patches I’m inclined to say should wait until they’ve had a bit more time to be thought about.
-George
^ permalink raw reply
* Re: mmotm 2020-05-13-20-30 uploaded (objtool warnings)
From: Peter Zijlstra @ 2020-05-29 16:12 UTC (permalink / raw)
To: Josh Poimboeuf
Cc: Christoph Hellwig, Randy Dunlap, Andrew Morton, broonie,
linux-fsdevel, linux-kernel, linux-mm, linux-next, mhocko,
mm-commits, sfr, Linus Torvalds, viro, x86, Steven Rostedt
In-Reply-To: <20200529160514.cyaytn33thphb3tz@treble>
On Fri, May 29, 2020 at 11:05:14AM -0500, Josh Poimboeuf wrote:
> It looks to me like GCC is doing the right thing. That likely()
> translates to:
>
> # define likely(x) (__branch_check__(x, 1, __builtin_constant_p(x)))
>
> which becomes:
>
> #define __branch_check__(x, expect, is_constant) ({ \
> long ______r; \
> static struct ftrace_likely_data \
> __aligned(4) \
> __section(_ftrace_annotated_branch) \
> ______f = { \
> .data.func = __func__, \
> .data.file = __FILE__, \
> .data.line = __LINE__, \
> }; \
> ______r = __builtin_expect(!!(x), expect); \
> ftrace_likely_update(&______f, ______r, \
> expect, is_constant); \
> ______r; \
> })
>
> Here 'x' is the call to user_access_begin(). It evaluates 'x' -- and
> thus calls user_access_begin() -- before the call to
> ftrace_likely_update().
>
> So it's working as designed, right? The likely() just needs to be
> changed to likely_notrace().
But if !x (ie we fail user_access_begin()), we should not pass STAC() on
the way to out_err. OTOH if x, we should not be jumping to out_err.
I'm most confused... must not stare at asm for a while.
^ permalink raw reply
* [linux-next:master 11894/13554] arch/riscv/mm/ptdump.c:255:17: error: initialization of 'void (*)(struct ptdump_state *, long unsigned int, int, u64)' {aka 'void (*)(struct ptdump_state *, long unsigned int, int, long long unsigned int)'} from incompatible pointer type 'void (*)(struct ptdump_state *, long unsigned int, int, long unsigned int)'
From: kbuild test robot @ 2020-05-29 16:14 UTC (permalink / raw)
To: Steven, Price,; +Cc: kbuild-all, Andrew Morton, Linux Memory Management List
[-- Attachment #1: Type: text/plain, Size: 3515 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head: ff387fc20c697cdc887b2abf7ef494e853795a2f
commit: f6396a9ececda3fa26571ccd38167373db1d2ec3 [11894/13554] mm: ptdump: expand type of 'val' in note_page()
config: riscv-allyesconfig (attached as .config)
compiler: riscv64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout f6396a9ececda3fa26571ccd38167373db1d2ec3
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=riscv
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>, old ones prefixed by <<):
arch/riscv/mm/ptdump.c: In function 'ptdump_walk':
>> arch/riscv/mm/ptdump.c:255:17: error: initialization of 'void (*)(struct ptdump_state *, long unsigned int, int, u64)' {aka 'void (*)(struct ptdump_state *, long unsigned int, int, long long unsigned int)'} from incompatible pointer type 'void (*)(struct ptdump_state *, long unsigned int, int, long unsigned int)' [-Werror=incompatible-pointer-types]
255 | .note_page = note_page,
| ^~~~~~~~~
arch/riscv/mm/ptdump.c:255:17: note: (near initialization for 'st.ptdump.note_page')
arch/riscv/mm/ptdump.c: In function 'ptdump_check_wx':
arch/riscv/mm/ptdump.c:277:17: error: initialization of 'void (*)(struct ptdump_state *, long unsigned int, int, u64)' {aka 'void (*)(struct ptdump_state *, long unsigned int, int, long long unsigned int)'} from incompatible pointer type 'void (*)(struct ptdump_state *, long unsigned int, int, long unsigned int)' [-Werror=incompatible-pointer-types]
277 | .note_page = note_page,
| ^~~~~~~~~
arch/riscv/mm/ptdump.c:277:17: note: (near initialization for 'st.ptdump.note_page')
cc1: some warnings being treated as errors
vim +255 arch/riscv/mm/ptdump.c
59c4da8640ccf4 Zong Li 2020-03-12 247
59c4da8640ccf4 Zong Li 2020-03-12 248 static void ptdump_walk(struct seq_file *s)
59c4da8640ccf4 Zong Li 2020-03-12 249 {
59c4da8640ccf4 Zong Li 2020-03-12 250 struct pg_state st = {
59c4da8640ccf4 Zong Li 2020-03-12 251 .seq = s,
59c4da8640ccf4 Zong Li 2020-03-12 252 .marker = address_markers,
59c4da8640ccf4 Zong Li 2020-03-12 253 .level = -1,
59c4da8640ccf4 Zong Li 2020-03-12 254 .ptdump = {
59c4da8640ccf4 Zong Li 2020-03-12 @255 .note_page = note_page,
59c4da8640ccf4 Zong Li 2020-03-12 256 .range = (struct ptdump_range[]) {
59c4da8640ccf4 Zong Li 2020-03-12 257 {KERN_VIRT_START, ULONG_MAX},
59c4da8640ccf4 Zong Li 2020-03-12 258 {0, 0}
59c4da8640ccf4 Zong Li 2020-03-12 259 }
59c4da8640ccf4 Zong Li 2020-03-12 260 }
59c4da8640ccf4 Zong Li 2020-03-12 261 };
59c4da8640ccf4 Zong Li 2020-03-12 262
59c4da8640ccf4 Zong Li 2020-03-12 263 ptdump_walk_pgd(&st.ptdump, &init_mm, NULL);
59c4da8640ccf4 Zong Li 2020-03-12 264 }
59c4da8640ccf4 Zong Li 2020-03-12 265
:::::: The code at line 255 was first introduced by commit
:::::: 59c4da8640ccf4721d54d36835706f3eefb521a4 riscv: Add support to dump the kernel page tables
:::::: TO: Zong Li <zong.li@sifive.com>
:::::: CC: Palmer Dabbelt <palmerdabbelt@google.com>
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 63370 bytes --]
^ permalink raw reply
* Re: Kernel crash due to memory corruption with v5.4.26-rt17 and PowerPC e500
From: Sebastian Andrzej Siewior @ 2020-05-29 16:15 UTC (permalink / raw)
To: Mark Marshall
Cc: linux-rt-users, Mark Marshall, thomas.graziadei, Thomas Gleixner,
linux-kernel, rostedt
In-Reply-To: <CAD4b4WLS36JKepz31m98Z3Ve05d63GnfBGsuuWRXpjXZqPoBrA@mail.gmail.com>
On 2020-05-29 17:38:39 [+0200], Mark Marshall wrote:
> Hi Sebastian & list,
Hi,
> I had assumed that my e-mail had got lost or overlooked, I was meaning to
> post a follow up message this week...
>
> All I could find from the debugging and tracing that we added was that
> something was going wrong with the mm data structures somewhere in the
> exec code. In the end I just spent a week or two pouring over the diffs
> of this code between the versions that I new worked and didn't work.
>
> I eventually found the culprit. On the working kernel versions there is
> a patch called "mm: Protect activate_mm() by preempt_[disable&enable]_rt()".
> This is commit f0b4a9cb253a on the V4.19.82-rt30 branch, for instance.
> Although the commit message talks about ARM, it seems that we need this for
> PowerPC too (I guess, any PowerPC with the "nohash" MMU?).
Could you drop me your config, please? I need to dig here a little and I
should have seen this on qemu, right?
> Could you please add this commit back to the RT branch? I'm not sure how
> to find out the history of this commit. For instance, why has it been
> removed from the RT patchset? How are these things tracked, generally?
I dropped that patch in v5.4.3-rt1. I couldn't reproduce the issue that
was documented in the patch and the code that triggered the warning was
removed / reworked in commit
b5466f8728527 ("ARM: mm: remove IPI broadcasting on ASID rollover")
So it looked like no longer needed and then got dropped during the
rebase.
In order to get it back into the RT queue I need to understand why it is
required. What exactly is it fixing. Let me stare at for a little…
> Best regards,
> Mark
Sebastian
^ permalink raw reply
* Re: [PATCH for-4.14] tools/libxl: fix setting altp2m param broken by 1e9bc407cf0
From: Andrew Cooper @ 2020-05-29 16:15 UTC (permalink / raw)
To: Tamas K Lengyel, xen-devel; +Cc: Anthony PERARD, Ian Jackson, Wei Liu
In-Reply-To: <20200529160621.3123-1-tamas@tklengyel.com>
On 29/05/2020 17:06, Tamas K Lengyel wrote:
> The patch 1e9bc407cf0 mistakenly converted the altp2m config option to a
> boolean. This is incorrect and breaks external-only usecases of altp2m that
> is set with a value of 2.
>
> Signed-off-by: Tamas K Lengyel <tamas@tklengyel.com>
Urg yes. Sorry.
However, this doesn't build because there is another use of the altp2m
variable between the two hunks below, for compatiblity with the older
altp2mhvm option.
I think changing its type just to int out to suffice?
~Andrew
> ---
> tools/libxl/libxl_x86.c | 3 +--
> 1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/tools/libxl/libxl_x86.c b/tools/libxl/libxl_x86.c
> index f8bc828e62..272736850b 100644
> --- a/tools/libxl/libxl_x86.c
> +++ b/tools/libxl/libxl_x86.c
> @@ -391,7 +391,6 @@ static int hvm_set_conf_params(libxl__gc *gc, uint32_t domid,
> libxl_ctx *ctx = libxl__gc_owner(gc);
> xc_interface *xch = ctx->xch;
> int ret = ERROR_FAIL;
> - bool altp2m = info->altp2m;
>
> switch(info->type) {
> case LIBXL_DOMAIN_TYPE_HVM:
> @@ -433,7 +432,7 @@ static int hvm_set_conf_params(libxl__gc *gc, uint32_t domid,
> LOG(ERROR, "Couldn't set HVM_PARAM_NESTEDHVM");
> goto out;
> }
> - if (xc_hvm_param_set(xch, domid, HVM_PARAM_ALTP2M, altp2m)) {
> + if (xc_hvm_param_set(xch, domid, HVM_PARAM_ALTP2M, info->altp2m)) {
> LOG(ERROR, "Couldn't set HVM_PARAM_ALTP2M");
> goto out;
> }
^ permalink raw reply
* [PATCH] libvhost-user: advertise vring features
From: Stefan Hajnoczi @ 2020-05-29 16:13 UTC (permalink / raw)
To: qemu-devel
Cc: Marc-André Lureau, Jason Wang, Michael S. Tsirkin,
Stefan Hajnoczi, Raphael Norwitz
libvhost-user implements several vring features without advertising
them. There is no way for the vhost-user master to detect support for
these features.
Things more or less work today because QEMU assumes the vhost-user
backend always implements certain feature bits like
VIRTIO_RING_F_EVENT_IDX. This is not documented anywhere.
This patch explicitly advertises features implemented in libvhost-user
so that the vhost-user master does not need to make undocumented
assumptions.
Feature bits that libvhost-user now advertises can be removed from
vhost-user-blk.c. Devices should not be responsible for advertising
vring feature bits, that is libvhost-user's job.
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Jason Wang <jasowang@redhat.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
---
I have tested make check and virtiofsd.
---
contrib/libvhost-user/libvhost-user.c | 10 ++++++++++
contrib/vhost-user-blk/vhost-user-blk.c | 4 +---
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/contrib/libvhost-user/libvhost-user.c b/contrib/libvhost-user/libvhost-user.c
index 3bca996c62..b43874ba12 100644
--- a/contrib/libvhost-user/libvhost-user.c
+++ b/contrib/libvhost-user/libvhost-user.c
@@ -495,6 +495,16 @@ static bool
vu_get_features_exec(VuDev *dev, VhostUserMsg *vmsg)
{
vmsg->payload.u64 =
+ /*
+ * The following VIRTIO feature bits are supported by our virtqueue
+ * implementation:
+ */
+ 1ULL << VIRTIO_F_NOTIFY_ON_EMPTY |
+ 1ULL << VIRTIO_RING_F_INDIRECT_DESC |
+ 1ULL << VIRTIO_RING_F_EVENT_IDX |
+ 1ULL << VIRTIO_F_VERSION_1 |
+
+ /* vhost-user feature bits */
1ULL << VHOST_F_LOG_ALL |
1ULL << VHOST_USER_F_PROTOCOL_FEATURES;
diff --git a/contrib/vhost-user-blk/vhost-user-blk.c b/contrib/vhost-user-blk/vhost-user-blk.c
index 6fd91c7e99..25eccd02b5 100644
--- a/contrib/vhost-user-blk/vhost-user-blk.c
+++ b/contrib/vhost-user-blk/vhost-user-blk.c
@@ -382,9 +382,7 @@ vub_get_features(VuDev *dev)
1ull << VIRTIO_BLK_F_DISCARD |
1ull << VIRTIO_BLK_F_WRITE_ZEROES |
#endif
- 1ull << VIRTIO_BLK_F_CONFIG_WCE |
- 1ull << VIRTIO_F_VERSION_1 |
- 1ull << VHOST_USER_F_PROTOCOL_FEATURES;
+ 1ull << VIRTIO_BLK_F_CONFIG_WCE;
if (vdev_blk->enable_ro) {
features |= 1ull << VIRTIO_BLK_F_RO;
--
2.25.4
^ permalink raw reply related
* [linux-next:master 11894/13554] arch/riscv/mm/ptdump.c:255:17: error: initialization of 'void (*)(struct ptdump_state *, long unsigned int, int, u64)' {aka 'void (*)(struct ptdump_state *, long unsigned int, int, long long unsigned int)'} from incompatible pointer type 'void (*)(struct ptdump_state *, long unsigned int, int, long unsigned int)'
From: kbuild test robot @ 2020-05-29 16:14 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 3577 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head: ff387fc20c697cdc887b2abf7ef494e853795a2f
commit: f6396a9ececda3fa26571ccd38167373db1d2ec3 [11894/13554] mm: ptdump: expand type of 'val' in note_page()
config: riscv-allyesconfig (attached as .config)
compiler: riscv64-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout f6396a9ececda3fa26571ccd38167373db1d2ec3
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross ARCH=riscv
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot <lkp@intel.com>
All errors (new ones prefixed by >>, old ones prefixed by <<):
arch/riscv/mm/ptdump.c: In function 'ptdump_walk':
>> arch/riscv/mm/ptdump.c:255:17: error: initialization of 'void (*)(struct ptdump_state *, long unsigned int, int, u64)' {aka 'void (*)(struct ptdump_state *, long unsigned int, int, long long unsigned int)'} from incompatible pointer type 'void (*)(struct ptdump_state *, long unsigned int, int, long unsigned int)' [-Werror=incompatible-pointer-types]
255 | .note_page = note_page,
| ^~~~~~~~~
arch/riscv/mm/ptdump.c:255:17: note: (near initialization for 'st.ptdump.note_page')
arch/riscv/mm/ptdump.c: In function 'ptdump_check_wx':
arch/riscv/mm/ptdump.c:277:17: error: initialization of 'void (*)(struct ptdump_state *, long unsigned int, int, u64)' {aka 'void (*)(struct ptdump_state *, long unsigned int, int, long long unsigned int)'} from incompatible pointer type 'void (*)(struct ptdump_state *, long unsigned int, int, long unsigned int)' [-Werror=incompatible-pointer-types]
277 | .note_page = note_page,
| ^~~~~~~~~
arch/riscv/mm/ptdump.c:277:17: note: (near initialization for 'st.ptdump.note_page')
cc1: some warnings being treated as errors
vim +255 arch/riscv/mm/ptdump.c
59c4da8640ccf4 Zong Li 2020-03-12 247
59c4da8640ccf4 Zong Li 2020-03-12 248 static void ptdump_walk(struct seq_file *s)
59c4da8640ccf4 Zong Li 2020-03-12 249 {
59c4da8640ccf4 Zong Li 2020-03-12 250 struct pg_state st = {
59c4da8640ccf4 Zong Li 2020-03-12 251 .seq = s,
59c4da8640ccf4 Zong Li 2020-03-12 252 .marker = address_markers,
59c4da8640ccf4 Zong Li 2020-03-12 253 .level = -1,
59c4da8640ccf4 Zong Li 2020-03-12 254 .ptdump = {
59c4da8640ccf4 Zong Li 2020-03-12 @255 .note_page = note_page,
59c4da8640ccf4 Zong Li 2020-03-12 256 .range = (struct ptdump_range[]) {
59c4da8640ccf4 Zong Li 2020-03-12 257 {KERN_VIRT_START, ULONG_MAX},
59c4da8640ccf4 Zong Li 2020-03-12 258 {0, 0}
59c4da8640ccf4 Zong Li 2020-03-12 259 }
59c4da8640ccf4 Zong Li 2020-03-12 260 }
59c4da8640ccf4 Zong Li 2020-03-12 261 };
59c4da8640ccf4 Zong Li 2020-03-12 262
59c4da8640ccf4 Zong Li 2020-03-12 263 ptdump_walk_pgd(&st.ptdump, &init_mm, NULL);
59c4da8640ccf4 Zong Li 2020-03-12 264 }
59c4da8640ccf4 Zong Li 2020-03-12 265
:::::: The code at line 255 was first introduced by commit
:::::: 59c4da8640ccf4721d54d36835706f3eefb521a4 riscv: Add support to dump the kernel page tables
:::::: TO: Zong Li <zong.li@sifive.com>
:::::: CC: Palmer Dabbelt <palmerdabbelt@google.com>
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 63370 bytes --]
^ permalink raw reply
* Re: Re: [PATCH] PCI: Relax ACS requirement for Intel RCiEP devices.
From: Darrel Goeddel @ 2020-05-29 15:59 UTC (permalink / raw)
To: Ashok Raj
Cc: Alex Williamson, linux-pci, Bjorn Helgaas, Joerg Roedel,
linux-kernel, iommu, Lu Baolu, Darrel Goeddel, Mark Scott,
Romil Sharma
In-Reply-To: <20200528153826.257a0145@x1.home>
On 5/28/20 4:38 PM, Alex Williamson wrote:
> On Thu, 28 May 2020 13:57:42 -0700
> Ashok Raj <ashok.raj@intel.com> wrote:
>
>> All Intel platforms guarantee that all root complex implementations
>> must send transactions up to IOMMU for address translations. Hence for
>> RCiEP devices that are Vendor ID Intel, can claim exception for lack of
>> ACS support.
>>
>>
>> 3.16 Root-Complex Peer to Peer Considerations
>> When DMA remapping is enabled, peer-to-peer requests through the
>> Root-Complex must be handled
>> as follows:
>> • The input address in the request is translated (through first-level,
>> second-level or nested translation) to a host physical address (HPA).
>> The address decoding for peer addresses must be done only on the
>> translated HPA. Hardware implementations are free to further limit
>> peer-to-peer accesses to specific host physical address regions
>> (or to completely disallow peer-forwarding of translated requests).
>> • Since address translation changes the contents (address field) of
>> the PCI Express Transaction Layer Packet (TLP), for PCI Express
>> peer-to-peer requests with ECRC, the Root-Complex hardware must use
>> the new ECRC (re-computed with the translated address) if it
>> decides to forward the TLP as a peer request.
>> • Root-ports, and multi-function root-complex integrated endpoints, may
>> support additional peerto-peer control features by supporting PCI Express
>> Access Control Services (ACS) capability. Refer to ACS capability in
>> PCI Express specifications for details.
>>
>> Since Linux didn't give special treatment to allow this exception, certain
>> RCiEP MFD devices are getting grouped in a single iommu group. This
>> doesn't permit a single device to be assigned to a guest for instance.
>>
>> In one vendor system: Device 14.x were grouped in a single IOMMU group.
>>
>> /sys/kernel/iommu_groups/5/devices/0000:00:14.0
>> /sys/kernel/iommu_groups/5/devices/0000:00:14.2
>> /sys/kernel/iommu_groups/5/devices/0000:00:14.3
>>
>> After the patch:
>> /sys/kernel/iommu_groups/5/devices/0000:00:14.0
>> /sys/kernel/iommu_groups/5/devices/0000:00:14.2
>> /sys/kernel/iommu_groups/6/devices/0000:00:14.3 <<< new group
>>
>> 14.0 and 14.2 are integrated devices, but legacy end points.
>> Whereas 14.3 was a PCIe compliant RCiEP.
>>
>> 00:14.3 Network controller: Intel Corporation Device 9df0 (rev 30)
>> Capabilities: [40] Express (v2) Root Complex Integrated Endpoint, MSI 00
>>
>> This permits assigning this device to a guest VM.
>>
>> Fixes: f096c061f552 ("iommu: Rework iommu_group_get_for_pci_dev()")
>
> I don't really understand this Fixes tag. This seems like a feature,
> not a fix. If you want it in stable releases as a feature, request it
> via Cc: stable@vger.kernel.org. I'd drop that tag, that's my nit.
> Otherwise:
>
> Reviewed-by: Alex Williamson <alex.williamson@redhat.com>
I have tested this patch with 5.6.14 as well as a slightly modified
version (without pci_acs_ctrl_enabled()) in a 3.10 enterprise linux
kernel.
Tested-by: Darrel Goeddel <dgoeddel@forcepoint.com>
>> Signed-off-by: Ashok Raj <ashok.raj@intel.com>
>> To: Joerg Roedel <joro@8bytes.org>
>> To: Bjorn Helgaas <bhelgaas@google.com>
>> Cc: linux-kernel@vger.kernel.org
>> Cc: iommu@lists.linux-foundation.org
>> Cc: Lu Baolu <baolu.lu@linux.intel.com>
>> Cc: Alex Williamson <alex.williamson@redhat.com>
>> Cc: Darrel Goeddel <DGoeddel@forcepoint.com>
>> Cc: Mark Scott <mscott@forcepoint.com>,
>> Cc: Romil Sharma <rsharma@forcepoint.com>
>> Cc: Ashok Raj <ashok.raj@intel.com>
>> ---
>> v2: Moved functionality from iommu to pci quirks - Alex Williamson
>>
>> drivers/pci/quirks.c | 15 +++++++++++++++
>> 1 file changed, 15 insertions(+)
>>
>> diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> index 28c9a2409c50..63373ca0a3fe 100644
>> --- a/drivers/pci/quirks.c
>> +++ b/drivers/pci/quirks.c
>> @@ -4682,6 +4682,20 @@ static int pci_quirk_mf_endpoint_acs(struct pci_dev *dev, u16 acs_flags)
>> PCI_ACS_CR | PCI_ACS_UF | PCI_ACS_DT);
>> }
>>
>> +static int pci_quirk_rciep_acs(struct pci_dev *dev, u16 acs_flags)
>> +{
>> + /*
>> + * RCiEP's are required to allow p2p only on translated addresses.
>> + * Refer to Intel VT-d specification Section 3.16 Root-Complex Peer
>> + * to Peer Considerations
>> + */
>> + if (pci_pcie_type(dev) != PCI_EXP_TYPE_RC_END)
>> + return -ENOTTY;
>> +
>> + return pci_acs_ctrl_enabled(acs_flags,
>> + PCI_ACS_SV | PCI_ACS_RR | PCI_ACS_CR | PCI_ACS_UF);
>> +}
>> +
>> static int pci_quirk_brcm_acs(struct pci_dev *dev, u16 acs_flags)
>> {
>> /*
>> @@ -4764,6 +4778,7 @@ static const struct pci_dev_acs_enabled {
>> /* I219 */
>> { PCI_VENDOR_ID_INTEL, 0x15b7, pci_quirk_mf_endpoint_acs },
>> { PCI_VENDOR_ID_INTEL, 0x15b8, pci_quirk_mf_endpoint_acs },
>> + { PCI_VENDOR_ID_INTEL, PCI_ANY_ID, pci_quirk_rciep_acs },
>> /* QCOM QDF2xxx root ports */
>> { PCI_VENDOR_ID_QCOM, 0x0400, pci_quirk_qcom_rp_acs },
>> { PCI_VENDOR_ID_QCOM, 0x0401, pci_quirk_qcom_rp_acs },
>
^ permalink raw reply
* Re: [PATCH v2 1/3] media: dt-bindings: media: Document Rockchip CIF bindings
From: Rob Herring @ 2020-05-29 16:14 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Mark Rutland, devicetree, Heiko Stuebner, linux-kernel,
Paul Kocialkowski, linux-rockchip, Rob Herring, Thomas Petazzoni,
Miquel Raynal, Hans Verkuil, Mauro Carvalho Chehab, Robin Murphy,
linux-arm-kernel, linux-media
In-Reply-To: <20200529130405.929429-2-maxime.chevallier@bootlin.com>
On Fri, 29 May 2020 15:04:03 +0200, Maxime Chevallier wrote:
> Add a documentation for the Rockchip Camera Interface controller
> binding.
>
> This controller can be found on platforms such as the PX30 or the
> RK3288, the PX30 being the only platform supported so far.
>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> ---
>
> Changes since V1
>
> - Updated the clock and reset names
> - Added missing includes in the example, so that the make dt_binding_check passes
>
> .../bindings/media/rockchip-cif.yaml | 100 ++++++++++++++++++
> 1 file changed, 100 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/rockchip-cif.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names: Additional items are not allowed ('cif_out' was unexpected)
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names:0: 'aclk' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names:1: 'hclkf' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names:2: 'pclkin' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names: ['aclk_cif', 'hclk_cif', 'pclk_cif', 'cif_out'] is too long
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clocks: Additional items are not allowed ([4294967295, 52] was unexpected)
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clocks: [[4294967295, 179], [4294967295, 249], [4294967295, 352], [4294967295, 52]] is too long
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: reset-names:0: 'axi' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: reset-names:1: 'ahb' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: reset-names:2: 'pclkin' was expected
See https://patchwork.ozlabs.org/patch/1300680
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:
pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade
Please check and re-submit.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 7/8] blk-mq: add blk_mq_all_tag_iter
From: Bart Van Assche @ 2020-05-29 16:14 UTC (permalink / raw)
To: Christoph Hellwig, Jens Axboe, Ming Lei
Cc: linux-block, John Garry, Hannes Reinecke, Thomas Gleixner,
Hannes Reinecke, Daniel Wagner
In-Reply-To: <20200529135315.199230-8-hch@lst.de>
On 2020-05-29 06:53, Christoph Hellwig wrote:
> Add a new blk_mq_all_tag_iter function to iterate over all allocated
> scheduler tags and driver tags. This is more flexible than the existing
> blk_mq_all_tag_busy_iter function as it allows the callers to do whatever
> they want on allocated request instead of being limited to started
> requests.
>
> It will be used to implement draining allocated requests on specified
> hctx in this patchset.
Reviewed-by: Bart van Assche <bvanassche@acm.org>
^ permalink raw reply
* Re: [PATCH v2 1/3] media: dt-bindings: media: Document Rockchip CIF bindings
From: Rob Herring @ 2020-05-29 16:14 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Robin Murphy, Hans Verkuil, devicetree, Heiko Stuebner,
Paul Kocialkowski, Thomas Petazzoni, linux-rockchip,
Mauro Carvalho Chehab, Miquel Raynal, Rob Herring, linux-media,
linux-arm-kernel, Mark Rutland, linux-kernel
In-Reply-To: <20200529130405.929429-2-maxime.chevallier@bootlin.com>
On Fri, 29 May 2020 15:04:03 +0200, Maxime Chevallier wrote:
> Add a documentation for the Rockchip Camera Interface controller
> binding.
>
> This controller can be found on platforms such as the PX30 or the
> RK3288, the PX30 being the only platform supported so far.
>
> Signed-off-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
> ---
>
> Changes since V1
>
> - Updated the clock and reset names
> - Added missing includes in the example, so that the make dt_binding_check passes
>
> .../bindings/media/rockchip-cif.yaml | 100 ++++++++++++++++++
> 1 file changed, 100 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/rockchip-cif.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names: Additional items are not allowed ('cif_out' was unexpected)
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names:0: 'aclk' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names:1: 'hclkf' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names:2: 'pclkin' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names: ['aclk_cif', 'hclk_cif', 'pclk_cif', 'cif_out'] is too long
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clocks: Additional items are not allowed ([4294967295, 52] was unexpected)
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clocks: [[4294967295, 179], [4294967295, 249], [4294967295, 352], [4294967295, 52]] is too long
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: reset-names:0: 'axi' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: reset-names:1: 'ahb' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: reset-names:2: 'pclkin' was expected
See https://patchwork.ozlabs.org/patch/1300680
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:
pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade
Please check and re-submit.
^ permalink raw reply
* Re: [PATCH v2 1/3] media: dt-bindings: media: Document Rockchip CIF bindings
From: Rob Herring @ 2020-05-29 16:14 UTC (permalink / raw)
To: Maxime Chevallier
Cc: Robin Murphy, Hans Verkuil, devicetree-u79uwXL29TY76Z2rM5mHXA,
Heiko Stuebner, Paul Kocialkowski, Thomas Petazzoni,
linux-rockchip-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Mauro Carvalho Chehab, Miquel Raynal, Rob Herring,
linux-media-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Mark Rutland,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200529130405.929429-2-maxime.chevallier-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
On Fri, 29 May 2020 15:04:03 +0200, Maxime Chevallier wrote:
> Add a documentation for the Rockchip Camera Interface controller
> binding.
>
> This controller can be found on platforms such as the PX30 or the
> RK3288, the PX30 being the only platform supported so far.
>
> Signed-off-by: Maxime Chevallier <maxime.chevallier-LDxbnhwyfcJBDgjK7y7TUQ@public.gmane.org>
> ---
>
> Changes since V1
>
> - Updated the clock and reset names
> - Added missing includes in the example, so that the make dt_binding_check passes
>
> .../bindings/media/rockchip-cif.yaml | 100 ++++++++++++++++++
> 1 file changed, 100 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/media/rockchip-cif.yaml
>
My bot found errors running 'make dt_binding_check' on your patch:
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names: Additional items are not allowed ('cif_out' was unexpected)
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names:0: 'aclk' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names:1: 'hclkf' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names:2: 'pclkin' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clock-names: ['aclk_cif', 'hclk_cif', 'pclk_cif', 'cif_out'] is too long
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clocks: Additional items are not allowed ([4294967295, 52] was unexpected)
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: clocks: [[4294967295, 179], [4294967295, 249], [4294967295, 352], [4294967295, 52]] is too long
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: reset-names:0: 'axi' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: reset-names:1: 'ahb' was expected
/builds/robherring/linux-dt-review/Documentation/devicetree/bindings/media/rockchip-cif.example.dt.yaml: cif@ff490000: reset-names:2: 'pclkin' was expected
See https://patchwork.ozlabs.org/patch/1300680
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure dt-schema is up to date:
pip3 install git+https://github.com/devicetree-org/dt-schema.git@master --upgrade
Please check and re-submit.
^ permalink raw reply
* Re: [PATCH 1/2] anqp: refactor to use frame-xchg
From: Denis Kenzior @ 2020-05-29 16:13 UTC (permalink / raw)
To: iwd
In-Reply-To: <cc0280b8867ed533e6cdcb06bbf38ea5647bdc91.camel@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1465 bytes --]
Hi James,
>> Well, can't we just check if anqp is pending for the network inside
>> network_connect() or so, and if it is, defer taking any action until
>> anqp succeeds / fails?
>
> Checking for pending is easy, defering is the hard part. We could set a
> flag in network if ANQP is pending, then if/when the network info gets
> set by station we could attempt a connect then (basically from inside
> network_set_info). But I have a feeling you wont like this, it just
> feels wrong.
Well we have to communicate between the two modules somehow.
>
> Then a further issue is how do we ultimately decide when to fail with
> NotConfigured if ANQP fails or there is an error? Unless we add some
> other mechanism for station to signal that ANQP failed like
> network_set_info_failed(). Again doesn't really feel right.
So one thing we could do is to have network actually drive the anqp
queries. Might be what we want to do anyway since we actually should be
doing multiple queries for grabbing icons, etc. The scanning suspension
and resumption of auto-connect is the only tricky part. Perhaps we just
have a reference count or something on the anqp request and station can
kick off autoconnect when that reaches 0.
>
> Maybe a per-station watch for ANQP that network can subscribe to?
> Network could get notified both if ANQP is being performed and when it
> finished.
Or something like this, yes.
Regards,
-Denis
^ permalink raw reply
* Re: [BUG] Core scheduling patches causing deadlock in some situations
From: Tamas K Lengyel @ 2020-05-29 16:12 UTC (permalink / raw)
To: Michał Leszczyński
Cc: Jürgen Groß, Xen-devel, chivay, bonus
In-Reply-To: <CABfawhmjeoVpRgAbDAA_T6rMiqPjQUvLPEn5t1-1JwZFJicNKQ@mail.gmail.com>
On Fri, May 29, 2020 at 8:48 AM Tamas K Lengyel
<tamas.k.lengyel@gmail.com> wrote:
>
> On Fri, May 29, 2020 at 7:51 AM Michał Leszczyński
> <michal.leszczynski@cert.pl> wrote:
> >
> > ----- 29 maj 2020 o 15:15, Jürgen Groß jgross@suse.com napisał(a):
> >
> > > On 29.05.20 14:51, Michał Leszczyński wrote:
> > >> ----- 29 maj 2020 o 14:44, Jürgen Groß jgross@suse.com napisał(a):
> > >>
> > >>> On 29.05.20 14:30, Michał Leszczyński wrote:
> > >>>> Hello,
> > >>>>
> > >>>> I'm running DRAKVUF on Dell Inc. PowerEdge R640/08HT8T server with Intel(R)
> > >>>> Xeon(R) Gold 6132 CPU @ 2.60GHz CPU.
> > >>>> When upgrading from Xen RELEASE 4.12 to 4.13, we have noticed some stability
> > >>>> problems concerning freezes of Dom0 (Debian Buster):
> > >>>>
> > >>>> ---
> > >>>>
> > >>>> maj 27 23:17:02 debian kernel: rcu: INFO: rcu_sched self-detected stall on CPU
> > >>>> maj 27 23:17:02 debian kernel: rcu: 0-....: (5250 ticks this GP)
> > >>>> idle=cee/1/0x4000000000000002 softirq=11964/11964 fqs=2515
> > >>>> maj 27 23:17:02 debian kernel: rcu: (t=5251 jiffies g=27237 q=799)
> > >>>> maj 27 23:17:02 debian kernel: NMI backtrace for cpu 0
> > >>>> maj 27 23:17:02 debian kernel: CPU: 0 PID: 643 Comm: z_rd_int_1 Tainted: P OE
> > >>>> 4.19.0-6-amd64 #1 Debian 4.19.67-2+deb10u2
> > >>>> maj 27 23:17:02 debian kernel: Hardware name: Dell Inc. PowerEdge R640/08HT8T,
> > >>>> BIOS 2.1.8 04/30/2019
> > >>>> maj 27 23:17:02 debian kernel: Call Trace:
> > >>>> maj 27 23:17:02 debian kernel: <IRQ>
> > >>>> maj 27 23:17:02 debian kernel: dump_stack+0x5c/0x80
> > >>>> maj 27 23:17:02 debian kernel: nmi_cpu_backtrace.cold.4+0x13/0x50
> > >>>> maj 27 23:17:02 debian kernel: ? lapic_can_unplug_cpu.cold.29+0x3b/0x3b
> > >>>> maj 27 23:17:02 debian kernel: nmi_trigger_cpumask_backtrace+0xf9/0xfb
> > >>>> maj 27 23:17:02 debian kernel: rcu_dump_cpu_stacks+0x9b/0xcb
> > >>>> maj 27 23:17:02 debian kernel: rcu_check_callbacks.cold.81+0x1db/0x335
> > >>>> maj 27 23:17:02 debian kernel: ? tick_sched_do_timer+0x60/0x60
> > >>>> maj 27 23:17:02 debian kernel: update_process_times+0x28/0x60
> > >>>> maj 27 23:17:02 debian kernel: tick_sched_handle+0x22/0x60
> > >>>>
> > >>>> ---
> > >>>>
> > >>>> This usually results in machine being completely unresponsive and performing an
> > >>>> automated reboot after some time.
> > >>>>
> > >>>> I've bisected commits between 4.12 and 4.13 and it seems like this is the patch
> > >>>> which introduced a bug:
> > >>>> https://github.com/xen-project/xen/commit/7c7b407e77724f37c4b448930777a59a479feb21
> > >>>>
> > >>>> Enclosed you can find the `xl dmesg` log (attachment: dmesg.txt) from the fresh
> > >>>> boot of the machine on which the bug was reproduced.
> > >>>>
> > >>>> I'm also attaching the `xl info` output from this machine:
> > >>>>
> > >>>> ---
> > >>>>
> > >>>> release : 4.19.0-6-amd64
> > >>>> version : #1 SMP Debian 4.19.67-2+deb10u2 (2019-11-11)
> > >>>> machine : x86_64
> > >>>> nr_cpus : 14
> > >>>> max_cpu_id : 223
> > >>>> nr_nodes : 1
> > >>>> cores_per_socket : 14
> > >>>> threads_per_core : 1
> > >>>> cpu_mhz : 2593.930
> > >>>> hw_caps :
> > >>>> bfebfbff:77fef3ff:2c100800:00000121:0000000f:d19ffffb:00000008:00000100
> > >>>> virt_caps : pv hvm hvm_directio pv_directio hap shadow
> > >>>> total_memory : 130541
> > >>>> free_memory : 63591
> > >>>> sharing_freed_memory : 0
> > >>>> sharing_used_memory : 0
> > >>>> outstanding_claims : 0
> > >>>> free_cpus : 0
> > >>>> xen_major : 4
> > >>>> xen_minor : 13
> > >>>> xen_extra : -unstable
> > >>>> xen_version : 4.13-unstable
> > >>>> xen_caps : xen-3.0-x86_64 xen-3.0-x86_32p hvm-3.0-x86_32 hvm-3.0-x86_32p
> > >>>> hvm-3.0-x86_64
> > >>>> xen_scheduler : credit2
> > >>>> xen_pagesize : 4096
> > >>>> platform_params : virt_start=0xffff800000000000
> > >>>> xen_changeset : Wed Oct 2 09:27:27 2019 +0200 git:7c7b407e77-dirty
> > >>>
> > >>> Which is your original Xen base? This output is clearly obtained at the
> > >>> end of the bisect process.
> > >>>
> > >>> There have been quite some corrections since the release of Xen 4.13, so
> > >>> please make sure you are running the most actual version (4.13.1).
> > >>>
> > >>>
> > >>> Juergen
> > >>
> > >> Sure, we have tested both RELEASE 4.13 and RELEASE 4.13.1. Unfortunately these
> > >> corrections didn't help and the bug is still reproducible.
> > >>
> > >> From our testing it turns out that:
> > >>
> > >> Known working revision: 997d6248a9ae932d0dbaac8d8755c2b15fec25dc
> > >> Broken revision: 6278553325a9f76d37811923221b21db3882e017
> > >> First bad commit: 7c7b407e77724f37c4b448930777a59a479feb21
> > >
> > > Would it be possible to test xen unstable, too?
> > >
> > > I could imagine e.g. commit b492c65da5ec5ed or 99266e31832fb4a4 to have
> > > an impact here.
> > >
> > >
> > > Juergen
> >
> >
> > I've tried b492c65da5ec5ed revision but it seems that there is some problem with ALTP2M support, so I can't launch anything at all.
> >
> > maj 29 15:45:32 debian drakrun[1223]: Failed to set HVM_PARAM_ALTP2M, RC: -1
> > maj 29 15:45:32 debian drakrun[1223]: VMI_ERROR: xc_altp2m_switch_to_view returned rc: -1
>
> Ough, great, that's another regression in 4.14-unstable. I ran into it
> myself but couldn't spend time to figure out whether its just
> something in my configuration or not so I reverted to 4.13.1. Now we
> know it's a real bug.
This was a bug in libxl, I've sent a patch in that fixes it but you
can grab it from https://github.com/tklengyel/xen/tree/libxl_fix.
There is also an update to DRAKVUF that will need to be applied due to
the recent altp2m visibility option having to be specified, you can
grab that from https://github.com/tklengyel/drakvuf/tree/4.14.
Tamas
^ permalink raw reply
* Re: [PATCH v3 net-next 1/8] sctp: setsockopt, expand some #defines
From: Marcelo Ricardo Leitner @ 2020-05-29 16:12 UTC (permalink / raw)
To: David Miller
Cc: David.Laight, vyasevich, nhorman, kuba, linux-sctp, netdev, hch
In-Reply-To: <20200526.153631.1486651154492951372.davem@davemloft.net>
On Tue, May 26, 2020 at 03:36:31PM -0700, David Miller wrote:
> From: David Laight <David.Laight@ACULAB.COM>
> Date: Tue, 26 May 2020 16:44:07 +0000
>
> > This should be 3/8.
>
> David just respin this at some point and with this fixed and also the
> header posting saying "0/8" properly instead of "0/1", this is really
> messy.
>
> Thanks.
I don't know why David's workflow is that cumbersome. I'll try to
respin this myself, on top of Christoph's latest changes.
^ permalink raw reply
* Re: [PATCH v3 net-next 1/8] sctp: setsockopt, expand some #defines
From: Marcelo Ricardo Leitner @ 2020-05-29 16:12 UTC (permalink / raw)
To: David Miller
Cc: David.Laight, vyasevich, nhorman, kuba, linux-sctp, netdev, hch
In-Reply-To: <20200526.153631.1486651154492951372.davem@davemloft.net>
On Tue, May 26, 2020 at 03:36:31PM -0700, David Miller wrote:
> From: David Laight <David.Laight@ACULAB.COM>
> Date: Tue, 26 May 2020 16:44:07 +0000
>
> > This should be 3/8.
>
> David just respin this at some point and with this fixed and also the
> header posting saying "0/8" properly instead of "0/1", this is really
> messy.
>
> Thanks.
I don't know why David's workflow is that cumbersome. I'll try to
respin this myself, on top of Christoph's latest changes.
^ 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.