Hi, Everyone,
This patch series adds support for the Switchtec MRPC DMA mode.
Switchtec switches supports 2 MRPC interaction modes: MRPC normal mode and
MRPC DMA mode, a new feature in the latest firmware versions. MRPC normal
mode requires the host to read the MRPC command status and output
From: Boris Glimcher
Switchtec hardware supports 64-bit DMA, set the correct DMA mask.
This allows the CMA to allocate larger buffers for memory windows.
Signed-off-by: Boris Glimcher
Signed-off-by: Wesley Sheng
---
drivers/pci/switch/switchtec.c | 4
1 file changed, 4 insertions(+)
From: Kelvin Cao
After submitting a Firmware Download MRPC command, Switchtec firmware will
delay Management EP BAR MemRd TLP responses by more than 10ms. This is a
firmware limitation. Delayed MemRd completions are problem for systems with
a low Completion Timeout (CTO).
The current driver
On Sunday, November 11, 2018 4:40:17 PM CET Peter Zijlstra wrote:
> On Thu, Nov 08, 2018 at 06:25:07PM +0100, Rafael J. Wysocki wrote:
> > +unsigned int teo_idle_duration(struct cpuidle_driver *drv,
> > + struct teo_cpu *cpu_data,
> > + unsigned
The SoC-specific compatible should come before the fallback compatible
string when multiple compatible strings are present, but the sequence is
wrong currently on H6 EMAC node (A64 fallback before H6 compatible).
Fix the sequence.
Fixes: c8ced5516d23 ("arm64: allwinner: h6: add EMAC device
On Sunday, November 11, 2018 4:40:17 PM CET Peter Zijlstra wrote:
> On Thu, Nov 08, 2018 at 06:25:07PM +0100, Rafael J. Wysocki wrote:
> > +unsigned int teo_idle_duration(struct cpuidle_driver *drv,
> > + struct teo_cpu *cpu_data,
> > + unsigned
The SoC-specific compatible should come before the fallback compatible
string when multiple compatible strings are present, but the sequence is
wrong currently on H6 EMAC node (A64 fallback before H6 compatible).
Fix the sequence.
Fixes: c8ced5516d23 ("arm64: allwinner: h6: add EMAC device
From: Kelvin Cao
After submitting a Firmware Download MRPC command, Switchtec firmware will
delay Management EP BAR MemRd TLP responses by more than 10ms. This is a
firmware limitation. Delayed MemRd completions are problem for systems with
a low Completion Timeout (CTO).
The current driver
On 11/06/18 at 10:55am, Michal Hocko wrote:
> From: Michal Hocko
>
> Page state checks are racy. Under a heavy memory workload (e.g. stress
> -m 200 -t 2h) it is quite easy to hit a race window when the page is
> allocated but its state is not fully populated yet. A debugging patch to
The
On 11/06/18 at 10:55am, Michal Hocko wrote:
> From: Michal Hocko
>
> Page state checks are racy. Under a heavy memory workload (e.g. stress
> -m 200 -t 2h) it is quite easy to hit a race window when the page is
> allocated but its state is not fully populated yet. A debugging patch to
The
Hi Subrahmanya,
As NXP does not integrate Mobiveil's INTx and MSI interrupt controller, I am
unable to test this fix.
Can you help to test this fix?
Thanks,
Zhiqiang
> -Original Message-
> From: Z.q. Hou
> Sent: 2018年11月6日 21:20
> To: linux-...@vger.kernel.org;
Hi Subrahmanya,
As NXP does not integrate Mobiveil's INTx and MSI interrupt controller, I am
unable to test this fix.
Can you help to test this fix?
Thanks,
Zhiqiang
> -Original Message-
> From: Z.q. Hou
> Sent: 2018年11月6日 21:20
> To: linux-...@vger.kernel.org;
> -Original Message-
> From: Vinod Koul
> Sent: Sunday, November 11, 2018 2:30 AM
> To: Radhey Shyam Pandey
> Cc: dan.j.willi...@intel.com; Michal Simek ; Appana
> Durga Kedareswara Rao ; dmaeng...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
>
> -Original Message-
> From: Vinod Koul
> Sent: Sunday, November 11, 2018 2:30 AM
> To: Radhey Shyam Pandey
> Cc: dan.j.willi...@intel.com; Michal Simek ; Appana
> Durga Kedareswara Rao ; dmaeng...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; linux-kernel@vger.kernel.org
>
On Sunday, November 11, 2018 4:20:34 PM CET Peter Zijlstra wrote:
> On Thu, Nov 08, 2018 at 06:25:07PM +0100, Rafael J. Wysocki wrote:
> > +/*
> > + * The SPIKE value is added to metrics when they grow and the DECAY_SHIFT
> > value
> > + * is used for decreasing metrics on a regular basis.
> > +
On Sunday, November 11, 2018 4:20:34 PM CET Peter Zijlstra wrote:
> On Thu, Nov 08, 2018 at 06:25:07PM +0100, Rafael J. Wysocki wrote:
> > +/*
> > + * The SPIKE value is added to metrics when they grow and the DECAY_SHIFT
> > value
> > + * is used for decreasing metrics on a regular basis.
> > +
On Saturday, November 10, 2018 8:10:01 PM CET Giovanni Gherdovich wrote:
> On Thu, 2018-11-08 at 18:25 +0100, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> > Subject: [PATCH] cpuidle: New timer events oriented governor for tickless
> > systems
> >
[cut]
> [NOTE: the tables in this
On Saturday, November 10, 2018 8:10:01 PM CET Giovanni Gherdovich wrote:
> On Thu, 2018-11-08 at 18:25 +0100, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> > Subject: [PATCH] cpuidle: New timer events oriented governor for tickless
> > systems
> >
[cut]
> [NOTE: the tables in this
Hi Leo,
> -Original Message-
> From: Leo Li
> Sent: 2018年11月15日 2:52
> To: Z.q. Hou ; linux-...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; bhelg...@google.com; robh...@kernel.org;
> mark.rutl...@arm.com;
Hi Leo,
> -Original Message-
> From: Leo Li
> Sent: 2018年11月15日 2:52
> To: Z.q. Hou ; linux-...@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; bhelg...@google.com; robh...@kernel.org;
> mark.rutl...@arm.com;
On Wed, Nov 14, 2018 at 7:26 AM Doug Smythies wrote:
>
> On 2018.11.08 00:00 Rafael J. Wysocki wrote:
> > On Wednesday, November 7, 2018 6:04:12 PM CET Doug Smythies wrote:
> >> On 2018.11.04 08:31 Rafael J. Wysocki wrote:
>
> ...[snip]...
> >> The results are:
> >>
On Wed, Nov 14, 2018 at 7:26 AM Doug Smythies wrote:
>
> On 2018.11.08 00:00 Rafael J. Wysocki wrote:
> > On Wednesday, November 7, 2018 6:04:12 PM CET Doug Smythies wrote:
> >> On 2018.11.04 08:31 Rafael J. Wysocki wrote:
>
> ...[snip]...
> >> The results are:
> >>
Hi Subrahmanya,
Thanks a lot for your ACK!
Regards,
Zhiqiang
> -Original Message-
> From: Subrahmanya Lingappa
> Sent: 2018年11月14日 17:33
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
Hi Subrahmanya,
Thanks a lot for your ACK!
Regards,
Zhiqiang
> -Original Message-
> From: Subrahmanya Lingappa
> Sent: 2018年11月14日 17:33
> To: Z.q. Hou
> Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
On Wed, Nov 14, 2018 at 01:14:57AM -0600, Kees Cook wrote:
> On Sat, Nov 3, 2018 at 6:38 PM, Joel Fernandes (Google)
> wrote:
> > Here are some simple cleanups and fixes for ramoops in pstore. Let me know
> > what you think, thanks.
>
> I took these and slightly tweaked code locations for the
On Wed, Nov 14, 2018 at 01:14:57AM -0600, Kees Cook wrote:
> On Sat, Nov 3, 2018 at 6:38 PM, Joel Fernandes (Google)
> wrote:
> > Here are some simple cleanups and fixes for ramoops in pstore. Let me know
> > what you think, thanks.
>
> I took these and slightly tweaked code locations for the
On Wed, 2018-11-14 at 14:27 +0100, John Crispin wrote:
> On 14/11/2018 13:47, Thierry Reding wrote:
> > On Tue, Nov 13, 2018 at 10:08:22AM +0800, Ryder Lee wrote:
> >> The flag 'has_clks' and related checks are superfluous as the CCF
> >> subsystem does this for you.
> > Both of these mechanisms
On Wed, 2018-11-14 at 14:27 +0100, John Crispin wrote:
> On 14/11/2018 13:47, Thierry Reding wrote:
> > On Tue, Nov 13, 2018 at 10:08:22AM +0800, Ryder Lee wrote:
> >> The flag 'has_clks' and related checks are superfluous as the CCF
> >> subsystem does this for you.
> > Both of these mechanisms
On Sun, Nov 11, 2018 at 10:26 PM Andi Kleen wrote:
> On Sat, Nov 10, 2018 at 09:50:05PM -0500, Travis Downs wrote:
> LBR is not part of PEBS, but is collected separately in the PMI handler.
Thanks for clearing this up - so you can ignore any earlier
suggestions on my part of trying to use LBR
On Sun, Nov 11, 2018 at 10:26 PM Andi Kleen wrote:
> On Sat, Nov 10, 2018 at 09:50:05PM -0500, Travis Downs wrote:
> LBR is not part of PEBS, but is collected separately in the PMI handler.
Thanks for clearing this up - so you can ignore any earlier
suggestions on my part of trying to use LBR
git-diff-index does not refresh the index for you, so using it for a
"-dirty" check can give misleading results. Commit 6147b1cf19651
("scripts/setlocalversion: git: Make -dirty check more robust") tried to
fix this by switching to git-status, but it overlooked the fact that
git-status also writes
git-diff-index does not refresh the index for you, so using it for a
"-dirty" check can give misleading results. Commit 6147b1cf19651
("scripts/setlocalversion: git: Make -dirty check more robust") tried to
fix this by switching to git-status, but it overlooked the fact that
git-status also writes
On Wed, Nov 14, 2018 at 8:20 AM Milian Wolff wrote:
> 3) I suggest we always keep the first frame and sample IP from the user regs,
> i.e. the accurate PEBS/IBS IP. Then we add the following frames from unwinding
> the ustack with the iregs.
Does this mean that the displayed unwind will
On Wed, Nov 14, 2018 at 8:20 AM Milian Wolff wrote:
> 3) I suggest we always keep the first frame and sample IP from the user regs,
> i.e. the accurate PEBS/IBS IP. Then we add the following frames from unwinding
> the ustack with the iregs.
Does this mean that the displayed unwind will
On Tue, Nov 13, 2018 at 2:03 PM Andreas Schwab wrote:
>
> On Nov 13 2018, Brian Norris wrote:
>
> > + } | grep -qv '^\(.. \)\?scripts/package'; then
>
> \? is a GNU extension, so if you want to stay portable you need to
> switch to ERE.
Ack. That's what I get for reading the GNU man
On Tue, Nov 13, 2018 at 2:03 PM Andreas Schwab wrote:
>
> On Nov 13 2018, Brian Norris wrote:
>
> > + } | grep -qv '^\(.. \)\?scripts/package'; then
>
> \? is a GNU extension, so if you want to stay portable you need to
> switch to ERE.
Ack. That's what I get for reading the GNU man
On 14/11/18 06:57 PM, Nadav Amit wrote:
> As long as the argument was *required* to get distcc to work at all, you
> could expect people would figure out an argument is needed. In this case, I
> suspect nobody will ever know about this argument (except you).
I agree with this completely.
>
On 14/11/18 06:57 PM, Nadav Amit wrote:
> As long as the argument was *required* to get distcc to work at all, you
> could expect people would figure out an argument is needed. In this case, I
> suspect nobody will ever know about this argument (except you).
I agree with this completely.
>
From: Logan Gunthorpe
Sent: November 15, 2018 at 1:19:45 AM GMT
> To: Nadav Amit , Ingo Molnar
> Cc: Ingo Molnar , Masahiro Yamada
> , Michal Marek ,
> Thomas Gleixner , Borislav Petkov , H.
> Peter Anvin , X86 ML , Linux Kbuild mailing
> list , LKML
> Subject: Re: [PATCH 1/2] Makefile: Fix
From: Logan Gunthorpe
Sent: November 15, 2018 at 1:19:45 AM GMT
> To: Nadav Amit , Ingo Molnar
> Cc: Ingo Molnar , Masahiro Yamada
> , Michal Marek ,
> Thomas Gleixner , Borislav Petkov , H.
> Peter Anvin , X86 ML , Linux Kbuild mailing
> list , LKML
> Subject: Re: [PATCH 1/2] Makefile: Fix
On Tue, Nov 06, 2018 at 05:36:42PM +0530, Souptick Joarder wrote:
> Page fault handlers are supposed to return VM_FAULT codes,
> but some drivers/file systems mistakenly return error
> numbers. Now that all drivers/file systems have been converted
> to use the vm_fault_t return type, change the
On Tue, Nov 06, 2018 at 05:36:42PM +0530, Souptick Joarder wrote:
> Page fault handlers are supposed to return VM_FAULT codes,
> but some drivers/file systems mistakenly return error
> numbers. Now that all drivers/file systems have been converted
> to use the vm_fault_t return type, change the
Fixes gcc '-Wunused-but-set-variable' warning:
sound/soc/amd/raven/acp3x-pcm-dma.c: In function 'acp3x_dma_hw_params':
sound/soc/amd/raven/acp3x-pcm-dma.c:333:25: warning:
variable 'dma_buffer' set but not used [-Wunused-but-set-variable]
It never used since introduction in commit
8de1b5ed0337
Fixes gcc '-Wunused-but-set-variable' warning:
sound/soc/amd/raven/acp3x-pcm-dma.c: In function 'acp3x_dma_hw_params':
sound/soc/amd/raven/acp3x-pcm-dma.c:333:25: warning:
variable 'dma_buffer' set but not used [-Wunused-but-set-variable]
It never used since introduction in commit
8de1b5ed0337
On 28/10/2018 13:55, Martin Blumenstingl wrote:
> This makes the driver use the names from S805 datasheet for the
> preprocessor #defines. This makes it easier to spot that the driver
> currently only supports Timer A (as clockevent with interrupt support)
> and Timer E (as clocksource without
On 28/10/2018 13:55, Martin Blumenstingl wrote:
> This makes the driver use the names from S805 datasheet for the
> preprocessor #defines. This makes it easier to spot that the driver
> currently only supports Timer A (as clockevent with interrupt support)
> and Timer E (as clocksource without
On 14/11/18 8:58 PM, Russell King - ARM Linux wrote:
Are you saying that's not possible on arm, because the current timer rundown
counter can't be read while the timer is running?
If I were to run a second timer at higher rate for clocksource, but keeping
the 10 ms timer as clock event
On 14/11/18 8:58 PM, Russell King - ARM Linux wrote:
Are you saying that's not possible on arm, because the current timer rundown
counter can't be read while the timer is running?
If I were to run a second timer at higher rate for clocksource, but keeping
the 10 ms timer as clock event
This patch is to balance the condition scope between hci_get_cmd_complete and
hci_event_packet about orig_skb as follows:
if (req_complete_skb || event == HCI_EV_CMD_STATUS ||
event == HCI_EV_CMD_COMPLETE)
orig_skb = skb_clone(skb, GFP_KERNEL);
And
This patch is to balance the condition scope between hci_get_cmd_complete and
hci_event_packet about orig_skb as follows:
if (req_complete_skb || event == HCI_EV_CMD_STATUS ||
event == HCI_EV_CMD_COMPLETE)
orig_skb = skb_clone(skb, GFP_KERNEL);
And
I need am Honest Person to support and your cooperation with me in business of
$26,700,000.00 thanks.
I need am Honest Person to support and your cooperation with me in business of
$26,700,000.00 thanks.
On 14/11/18 10:46 AM, Nadav Amit wrote:
>
> Actually, we can just figure out whether distcc or icecc are used in the
> Makefile according to the “version”, similarly to the way clang is detected.
> This would neither require new Makefile arguments or Kconfig options.
>
> What do you say about
On 14/11/18 10:46 AM, Nadav Amit wrote:
>
> Actually, we can just figure out whether distcc or icecc are used in the
> Makefile according to the “version”, similarly to the way clang is detected.
> This would neither require new Makefile arguments or Kconfig options.
>
> What do you say about
On Thu, Nov 01, 2018 at 11:26:06AM -0700, Florian Fainelli wrote:
> It is way too easy to miss enabling SERIAL_OF_PLATFORM which would
> result in the inability for the kernel to have a valid console device,
> which can be seen with:
>
> Warning: unable to open an initial console.
>
> and then:
On Thu, Nov 01, 2018 at 11:26:06AM -0700, Florian Fainelli wrote:
> It is way too easy to miss enabling SERIAL_OF_PLATFORM which would
> result in the inability for the kernel to have a valid console device,
> which can be seen with:
>
> Warning: unable to open an initial console.
>
> and then:
On Wed, 14 Nov 2018, Andrew Morton wrote:
Why was this moved to before the ep_reset_busy_poll_napi_id() call?
That movement placed the code ahead of the block comment which serves
to explain its function.
Yikes, that was a brain fart.
This? Which also fixes that comment and reflows it to
Joe Perches writes:
> The line continuation unintentionally adds whitespace so
> instead use a coalesced format to remove the whitespace.
>
> Miscellanea:
>
> o Use a more typical style for ternaries and arguments
> for this logging message
>
> Signed-off-by: Joe Perches
Acked-by: Vinicius
On Wed, 14 Nov 2018, Andrew Morton wrote:
Why was this moved to before the ep_reset_busy_poll_napi_id() call?
That movement placed the code ahead of the block comment which serves
to explain its function.
Yikes, that was a brain fart.
This? Which also fixes that comment and reflows it to
Joe Perches writes:
> The line continuation unintentionally adds whitespace so
> instead use a coalesced format to remove the whitespace.
>
> Miscellanea:
>
> o Use a more typical style for ternaries and arguments
> for this logging message
>
> Signed-off-by: Joe Perches
Acked-by: Vinicius
During development of a serial console driver with a gcc 8.2.0
toolchain for RISC-V, the following modpost warning appeared:
WARNING: vmlinux.o(.data+0x19b10): Section mismatch in reference from the
variable .LANCHOR1 to the function .init.text:sifive_serial_console_setup()
The variable
During development of a serial console driver with a gcc 8.2.0
toolchain for RISC-V, the following modpost warning appeared:
WARNING: vmlinux.o(.data+0x19b10): Section mismatch in reference from the
variable .LANCHOR1 to the function .init.text:sifive_serial_console_setup()
The variable
Drop modpost command line switches that are no longer used by
makefile.modpost, upon request from Sam Ravnborg ,
who wrote:
modpost is not supposed to be used outside the kernel build. [...]
I checked if there were any options supported by modpost that
was not configurable in
Drop modpost command line switches that are no longer used by
makefile.modpost, upon request from Sam Ravnborg ,
who wrote:
modpost is not supposed to be used outside the kernel build. [...]
I checked if there were any options supported by modpost that
was not configurable in
modpost reports section mismatch warnings on ELF local symbols. This
caused false positive warnings to be reported for a local symbol name
that would otherwise be elided by matching against a name pattern.
This was observed using a RISC-V gcc 8.2.0 toolchain that generates
section anchors.
To
modpost reports section mismatch warnings on ELF local symbols. This
caused false positive warnings to be reported for a local symbol name
that would otherwise be elided by matching against a name pattern.
This was observed using a RISC-V gcc 8.2.0 toolchain that generates
section anchors.
To
Hi Sam,
On Sat, 20 Oct 2018, Sam Ravnborg wrote:
modpost is not supposed to be used outside the kernel build.
And therefore if we introduce a new option then the infrastructure
to enable that option should also be in place.
In this particular case I cannot see why we should add the possibility
Hi Sam,
On Sat, 20 Oct 2018, Sam Ravnborg wrote:
modpost is not supposed to be used outside the kernel build.
And therefore if we introduce a new option then the infrastructure
to enable that option should also be in place.
In this particular case I cannot see why we should add the possibility
On 11/12/18 8:14 AM, Dan Williams wrote:
On Mon, Nov 12, 2018 at 7:45 AM Keith Busch wrote:
On Sat, Nov 10, 2018 at 12:50:36AM -0800, john.hubb...@gmail.com wrote:
From: John Hubbard
An upcoming patch wants to be able to operate on each page that
get_user_pages has retrieved. In order to
On 11/12/18 8:14 AM, Dan Williams wrote:
On Mon, Nov 12, 2018 at 7:45 AM Keith Busch wrote:
On Sat, Nov 10, 2018 at 12:50:36AM -0800, john.hubb...@gmail.com wrote:
From: John Hubbard
An upcoming patch wants to be able to operate on each page that
get_user_pages has retrieved. In order to
On 11/14/18 2:49 PM, Keith Busch wrote:
> + # tree sys/devices/system/node/node0/cache/
> + /sys/devices/system/node/node0/cache/
> + |-- index1
> + | |-- associativity
> + | |-- level
> + | |-- line_size
> + | |-- size
> + | `-- write_policy
Whoops, and
On 11/14/18 2:49 PM, Keith Busch wrote:
> System memory may have side caches to help improve access speed. While
> the system provided cache is transparent to the software accessing
> these memory ranges, applications can optimize their own access based
> on cache attributes.
>
> In preparation
On 11/14/18 2:49 PM, Keith Busch wrote:
> + # tree sys/devices/system/node/node0/cache/
> + /sys/devices/system/node/node0/cache/
> + |-- index1
> + | |-- associativity
> + | |-- level
> + | |-- line_size
> + | |-- size
> + | `-- write_policy
Whoops, and
On 11/14/18 2:49 PM, Keith Busch wrote:
> System memory may have side caches to help improve access speed. While
> the system provided cache is transparent to the software accessing
> these memory ranges, applications can optimize their own access based
> on cache attributes.
>
> In preparation
From: Eric Biggers
Reference counters should use refcount_t rather than atomic_t, since the
refcount_t implementation can prevent overflows, reducing the
exploitability of reference leak bugs. userfaultfd_ctx::refcount is a
reference counter with the usual semantics, so convert it to
From: Eric Biggers
Reference counters should use refcount_t rather than atomic_t, since the
refcount_t implementation can prevent overflows, reducing the
exploitability of reference leak bugs. userfaultfd_ctx::refcount is a
reference counter with the usual semantics, so convert it to
> On Nov 14, 2018, at 2:46 PM, Dmitry Torokhov wrote:
>
>> On Wed, Nov 14, 2018 at 2:38 PM Jann Horn wrote:
>>
>>> On Wed, Nov 14, 2018 at 11:29 PM Dmitry Torokhov wrote:
On Wed, Nov 14, 2018 at 2:05 PM Jann Horn wrote:
> On Wed, Nov 14, 2018 at 10:55 PM Eric Biggers wrote:
> On Nov 14, 2018, at 2:46 PM, Dmitry Torokhov wrote:
>
>> On Wed, Nov 14, 2018 at 2:38 PM Jann Horn wrote:
>>
>>> On Wed, Nov 14, 2018 at 11:29 PM Dmitry Torokhov wrote:
On Wed, Nov 14, 2018 at 2:05 PM Jann Horn wrote:
> On Wed, Nov 14, 2018 at 10:55 PM Eric Biggers wrote:
From: Eric Biggers
Reference counters should use refcount_t rather than atomic_t, since the
refcount_t implementation can prevent overflows, reducing the
exploitability of reference leak bugs. userfaultfd_ctx::refcount is a
reference counter with the usual semantics, so convert it to
From: Eric Biggers
Reference counters should use refcount_t rather than atomic_t, since the
refcount_t implementation can prevent overflows, reducing the
exploitability of reference leak bugs. userfaultfd_ctx::refcount is a
reference counter with the usual semantics, so convert it to
This silences -Wmissing-prototypes.
Signed-off-by: Adeodato Simó
---
It was suggested in the kernel-janitors mailing list that silencing
-Wmissing-prototypes would make for a worthy cause.
https://www.spinics.net/lists/linux-kernel-janitors/msg43981.html
I know the original commit for zstd
Sparse highlighted it, and appears to be a pure bug (from vs to).
./arch/riscv/include/asm/uaccess.h:403:35: warning: incorrect type in argument
1 (different address spaces)
./arch/riscv/include/asm/uaccess.h:403:39: warning: incorrect type in argument
2 (different address spaces)
On Tue, Nov 13, 2018 at 07:49:10PM +0100, Michal Hocko wrote:
> From: Michal Hocko
>
> Swap storage is restricted to max_swapfile_size (~16TB on x86_64)
> whenever the system is deemed affected by L1TF vulnerability. Even
> though the limit is quite high for most deployments it seems to be
> too
This silences -Wmissing-prototypes.
Signed-off-by: Adeodato Simó
---
It was suggested in the kernel-janitors mailing list that silencing
-Wmissing-prototypes would make for a worthy cause.
https://www.spinics.net/lists/linux-kernel-janitors/msg43981.html
I know the original commit for zstd
Sparse highlighted it, and appears to be a pure bug (from vs to).
./arch/riscv/include/asm/uaccess.h:403:35: warning: incorrect type in argument
1 (different address spaces)
./arch/riscv/include/asm/uaccess.h:403:39: warning: incorrect type in argument
2 (different address spaces)
On Tue, Nov 13, 2018 at 07:49:10PM +0100, Michal Hocko wrote:
> From: Michal Hocko
>
> Swap storage is restricted to max_swapfile_size (~16TB on x86_64)
> whenever the system is deemed affected by L1TF vulnerability. Even
> though the limit is quite high for most deployments it seems to be
> too
Use ZSTD_STATIC instead of vanilla static because the functions are
actually unused, and the macro adds the unused attribute.
This silences -Wmissing-prototypes when defining.
Signed-off-by: Adeodato Simó
---
I separated these two functions into a separate patch because they
are actually
Use ZSTD_STATIC instead of vanilla static because the functions are
actually unused, and the macro adds the unused attribute.
This silences -Wmissing-prototypes when defining.
Signed-off-by: Adeodato Simó
---
I separated these two functions into a separate patch because they
are actually
Hi Sven,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on char-misc/char-misc-testing]
[also build test ERROR on v4.20-rc2 next-20181114]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
Hi Sven,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on char-misc/char-misc-testing]
[also build test ERROR on v4.20-rc2 next-20181114]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com
Hi Linus,
The following changes since commit ccda4af0f4b92f7b4c308d3acc262f4a7e3affad:
Linux 4.20-rc2 (2018-11-11 17:12:31 -0600)
are available in the Git repository at:
git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-4.20-3
for you to fetch changes up to
Hi Linus,
The following changes since commit ccda4af0f4b92f7b4c308d3acc262f4a7e3affad:
Linux 4.20-rc2 (2018-11-11 17:12:31 -0600)
are available in the Git repository at:
git://git.linux-nfs.org/projects/trondmy/linux-nfs.git tags/nfs-for-4.20-3
for you to fetch changes up to
On Mon, 12 Nov 2018 at 18:53, Dietmar Eggemann wrote:
>
> On 11/9/18 8:20 AM, Vincent Guittot wrote:
>
> [...]
>
> > In order to achieve this time scaling, a new clock_pelt is created per rq.
> > The increase of this clock scales with current capacity when something
> > is running on rq and
On Mon, 12 Nov 2018 at 18:53, Dietmar Eggemann wrote:
>
> On 11/9/18 8:20 AM, Vincent Guittot wrote:
>
> [...]
>
> > In order to achieve this time scaling, a new clock_pelt is created per rq.
> > The increase of this clock scales with current capacity when something
> > is running on rq and
Hi Finn,
On 14/11/18 3:58 PM, Michael Schmitz wrote:
Hi Finn,
Am 14.11.2018 um 14:08 schrieb Michael Schmitz:
Can you also test tree fbf8405cd982 please?
My tests were on c606b5cf902 in case it wasn't clear. I've now seen
fbf8405cd982, one moment please ...
That one does appear to work -
Hi Finn,
On 14/11/18 3:58 PM, Michael Schmitz wrote:
Hi Finn,
Am 14.11.2018 um 14:08 schrieb Michael Schmitz:
Can you also test tree fbf8405cd982 please?
My tests were on c606b5cf902 in case it wasn't clear. I've now seen
fbf8405cd982, one moment please ...
That one does appear to work -
For one zone, there are three digits to describe its space range:
spanned_pages
present_pages
managed_pages
The detailed meaning is written in include/linux/mmzone.h. This patch
concerns about the last two.
present_pages is physical pages existing within the zone
For one zone, there are three digits to describe its space range:
spanned_pages
present_pages
managed_pages
The detailed meaning is written in include/linux/mmzone.h. This patch
concerns about the last two.
present_pages is physical pages existing within the zone
On Tue, Nov 13, 2018 at 6:51 PM, Isaac J. Manjarres
wrote:
> Currently, when checking to see if accessing n bytes starting at
> address "ptr" will cause a wraparound in the memory addresses,
> the check in check_bogus_address() adds an extra byte, which is
> incorrect, as the range of addresses
On Tue, Nov 13, 2018 at 6:51 PM, Isaac J. Manjarres
wrote:
> Currently, when checking to see if accessing n bytes starting at
> address "ptr" will cause a wraparound in the memory addresses,
> the check in check_bogus_address() adds an extra byte, which is
> incorrect, as the range of addresses
101 - 200 of 1344 matches
Mail list logo
