On 29/06/19 2:07 AM, Nishanth Menon wrote:
On 09:08-20190628, Keerthy wrote:
[..]
+ select GPIO_SYSFS
+ select GPIO_DAVINCI
Could you help explain the logic of doing this? commit message is
basically the diff in English. To me, this does NOT make sense.
I understand
Currently, $(objtree)/modules.order is touched in two places.
In the 'prepare0' rule, scripts/Makefile.build creates an empty
modules.order while processing 'obj=.'
In the 'modules' rule, the top-level Makefile overwrites it with
the correct list of modules.
While this might be a good
Towards the goal of removing MODVERDIR, read out modules.order to get
the list of modules to be installed. This is simpler than parsing *.mod
files in $(MODVERDIR).
For external modules, $(KBUILD_EXTMOD)/modules.order should be read.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
The current format of *.mod is like this:
line 1: directory path to the .ko file
line 2: a list of objects linked into this module
line 3: unresolved symbols (only when CONFIG_TRIM_UNUSED_KSYMS=y)
Now that *.mod and *.ko are created in the same directory, the line 1
provides no valuable
Currently, only the top-level modules.order drops duplicated entries.
The modules.order files in sub-directories potentially contain
duplication. To list out the paths of all modules, I want to use
modules.order instead of parsing *.mod files in $(MODVERDIR).
To achieve this, I want to rip off
Towards the goal of removing MODVERDIR, read out modules.order to get
the list of modules to be processed. This is simpler than parsing *.mod
files in $(MODVERDIR).
For external modules, $(KBUILD_EXTMOD)/modules.order should be read.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
Towards the goal of removing MODVERDIR, read out modules.order to get
the list of modules to be signed. This is simpler than parsing *.mod
files in $(MODVERDIR).
The modules_sign target is only supported for in-kernel modules.
So, this commit does not take care of external modules.
Removing the 'kernel/' prefix will make our life easier because we can
simply do 'cat modules.order' to get all built modules with full paths.
Currently, we parse the first line of '*.mod' files in $(MODVERDIR).
Since we have duplicated functionality here, I plan to remove MODVERDIR
entirely.
In
Now that there is no rule for 'prepare1', it can go away.
Signed-off-by: Masahiro Yamada
---
Changes in v2: None
Makefile | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/Makefile b/Makefile
index 4243b6daffcf..8de893e41149 100644
--- a/Makefile
+++ b/Makefile
@@
While descending directories, Kbuild produces objects for modules,
but do not link final *.ko files; it is done in the modpost.
To keep track of modules, Kbuild creates a *.mod file in $(MODVERDIR)
for every module it is building. Some post-processing steps read the
necessary information from
This series kills the long standing MODVERDIR.
Since MODVERDIR has a flat structure, it cannot avoid a race
condition when somebody introduces a module name conflict.
Kbuild now reads modules.order to get the list of all modules.
The post-processing/installation stages will be more robust
and
Nothing depends on this, so it is dead code.
Signed-off-by: Masahiro Yamada
---
I will apply this to kbuild tree since it is trivial.
Changes in v2: None
drivers/scsi/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
Currently, *.mod is created as a side-effect of obj-m.
Split out *.mod as a dedicated build rule, which allows to unify
the %.c -> %.o rule, and remove the single-used-m rule.
This also makes the incremental build of allmodconfig faster because
it saves $(NM) invocation when there is no change
AVX512 BFLOAT16 instructions support 16-bit BFLOAT16 floating-point
format (BF16) for deep learning optimization.
Intel adds AVX512 BFLOAT16 feature in CooperLake, which is CPUID.7.1.EAX[5].
Detailed information of the CPUID bit can be found here,
On Thu, Jul 11, 2019 at 01:16:03PM +1000, Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 11 Jul 2019 13:13:44 +1000 Stephen Rothwell
> wrote:
> >
> > On Thu, 11 Jul 2019 02:26:27 + Jason Gunthorpe
> > wrote:
> > >
> > > On Thu, Jul 11, 2019 at 11:50:54AM +1000, Stephen Rothwell wrote:
> > >
On Wed, Jul 10, 2019 at 10:24:26PM -0700, Linus Torvalds wrote:
> On Mon, Jul 8, 2019 at 8:05 AM Christian Brauner wrote:
> >
> > /* Syscall number 435 */
> > clone3() uses syscall number 435 and is coordinated with pidfd_open() which
> > uses syscall number 434. I'm not aware of any other
Jian-Hong Pan 於 2019年7月11日 週四 下午1:25寫道：
>
> Since each skb in RX ring is reused instead of new allocation, we can
> treat the DMA in a more efficient way by DMA synchronization.
>
> Signed-off-by: Jian-Hong Pan
> Cc:
> ---
Sorry, also forget to place the version difference here
v2:
- New
The pull request you sent on Mon, 8 Jul 2019 15:54:23 +0200:
> g...@gitolite.kernel.org:pub/scm/linux/kernel/git/brauner/linux
> tags/pidfd-updates-v5.3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/5450e8a316a64cddcbc15f90733ebc78aa736545
Thank you!
--
The pull request you sent on Wed, 10 Jul 2019 14:11:20 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/geert/linux-m68k.git
> tags/m68k-for-v5.3-tag2
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/29cd581b59496c26334c910a8b848baa81a6becd
Thank you!
--
The pull request you sent on Wed, 10 Jul 2019 15:22:09 +1000:
> git://git.kernel.org/pub/scm/linux/kernel/git/gerg/m68knommu.git for-next
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/398364a35daed7361e76c3666fb9a97792edce09
Thank you!
--
Deet-doot-dot, I am a
Jian-Hong Pan 於 2019年7月11日 週四 下午1:25寫道：
>
> Testing with RTL8822BE hardware, when available memory is low, we
> frequently see a kernel panic and system freeze.
>
> First, rtw_pci_rx_isr encounters a memory allocation failure (trimmed):
>
> rx routine starvation
> WARNING: CPU: 7 PID: 9871 at
On Mon, Jul 8, 2019 at 8:05 AM Christian Brauner wrote:
>
> /* Syscall number 435 */
> clone3() uses syscall number 435 and is coordinated with pidfd_open() which
> uses syscall number 434. I'm not aware of any other syscall targeted for
> 5.3 that has chosen the same number.
You say that, and
Since each skb in RX ring is reused instead of new allocation, we can
treat the DMA in a more efficient way by DMA synchronization.
Signed-off-by: Jian-Hong Pan
Cc:
---
drivers/net/wireless/realtek/rtw88/pci.c | 24 +---
1 file changed, 21 insertions(+), 3 deletions(-)
Testing with RTL8822BE hardware, when available memory is low, we
frequently see a kernel panic and system freeze.
First, rtw_pci_rx_isr encounters a memory allocation failure (trimmed):
rx routine starvation
WARNING: CPU: 7 PID: 9871 at drivers/net/wireless/realtek/rtw88/pci.c:822
Hi David,
Ok, I will resubmit it.
Regards,
Parshuram Thombare
Hi all,
After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:
fs/f2fs/data.c: In function 'f2fs_merge_page_bio':
fs/f2fs/data.c:516:3: error: implicit declaration of function 'wbc_account_io';
did you mean 'blk_account_rq'?
On Wed, Jul 10, 2019 at 2:33 AM Mao Wenan wrote:
>
> There are some errors while compiling tls.c if
> CONFIG_MLX5_FPGA_TLS is not obvious on.
>
> drivers/net/ethernet/mellanox/mlx5/core/en_accel/tls.c: In function
> mlx5e_tls_set_ipv4_flow:
> ./include/linux/mlx5/device.h:61:39: error: invalid
Hi Sasha,
Thanks for helping port this patch to stable.
May I know if I can submit other bug fixes which has been accepted by
upstream to stable by myself?
If yes, where I can find related process for reference?
Thanks & Regards,
Ran
> -Original Message-
> From: Sasha
Hi all,
After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
fs/xfs/xfs_aops.c: In function 'xfs_add_to_ioend':
fs/xfs/xfs_aops.c:799:2: error: implicit declaration of function
'wbc_account_io'; did you mean 'blk_account_rq'?
Thanks for review.
On Wed, 10 Jul 2019 at 13:18, Boqun Feng wrote:
>
> On Fri, Jun 28, 2019 at 05:15:15PM +0800, Yuyang Du wrote:
> > Direct dependencies need to keep track of their read-write lock types.
> > Two bit fields, which share the distance field, are added to lock_list
> > struct so
Hi Numfor,
On 7/11/19 2:15 AM, Numfor Mbiziwo-Tiapo wrote:
> -static bool perf_evsel__should_store_id(struct perf_evsel *counter)
> +static bool perf_evsel__should_store_id(struct perf_evsel *counter, int
> run_idx)
> {
> - return STAT_RECORD || counter->attr.read_format & PERF_FORMAT_ID;
>
The pull request you sent on Tue, 9 Jul 2019 09:39:48 -0700:
> git://git.kernel.org/pub/scm/fs/xfs/xfs-linux.git tags/copy-file-range-fixes-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/40f06c799539739a08a56be8a096f56aeed05731
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Thu, 11 Jul 2019 00:22:27 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/gfs2/linux-gfs2.git
> tags/gfs2-for-5.3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/0248a8be6d21dad72b9ce80a7565cf13c11509d8
Thank you!
--
The pull request you sent on Tue, 9 Jul 2019 18:55:48 -0400:
> git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
> tags/ext4_for_linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/2e756758e5cb4ea29cba5865d00fad476ce94a93
Thank you!
--
Deet-doot-dot, I
Hi Kieran,
Thanks for your patch.
On 2019-07-10 13:37:19 +0100, Kieran Bingham wrote:
> The I2C core framework provides a simplified probe framework from commit
> b8a1a4cd5a98 ("i2c: Provide a temporary .probe_new() call-back type").
>
> Convert the ADV748x to utilise this simplfied i2c driver
The pull request you sent on Fri, 05 Jul 2019 22:45:39 +0100:
> git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
> tags/afs-next-20190628
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8dda9957e3a1c871dfbabf84c4760f9b26032442
Thank you!
--
The pull request you sent on Wed, 10 Jul 2019 18:02:36 -0400:
> git://linux-nfs.org/~bfields/linux.git tags/nfsd-5.3
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d2b6b4c832f7e3067709e8d4970b7b82b44419ac
Thank you!
--
Deet-doot-dot, I am a bot.
The pull request you sent on Mon, 08 Jul 2019 08:43:10 -0400:
> git://git.kernel.org/pub/scm/linux/kernel/git/jlayton/linux.git
> tags/locks-v5.3-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/988052f47adc5c3b0b004180b59bb3761d91b752
Thank you!
--
Deet-doot-dot,
The pull request you sent on Mon, 8 Jul 2019 08:53:33 -0700:
> git://git.kernel.org/pub/scm/fs/fscrypt/fscrypt.git tags/fscrypt-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/25cd6f355dab9d11b7c8a4005867d5a30b8b14ee
Thank you!
--
Deet-doot-dot, I am a
Rename macros as follows:
* s/SS_PIN_DECL()/PIN_DECL_1()/
* s/MS_PIN_DECL()/PIN_DECL_2()/
* s/MS_PIN_DECL_()/PIN_DECL_()/
This is in preparation for adding PIN_DECL_3(). We could clean this up
with e.g. CPPMAGIC_MAP() from ccan, but that might be a bridge too far
given how much of a macro jungle
The complement of SIG_DESC_SET().
Signed-off-by: Andrew Jeffery
---
drivers/pinctrl/aspeed/pinmux-aspeed.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/pinctrl/aspeed/pinmux-aspeed.h
b/drivers/pinctrl/aspeed/pinmux-aspeed.h
index 474820df6263..c59e936a7dde 100644
---
The AST260 differs from the 2400 and 2500 in that it supports multiple
groups for a subset of functions.
Signed-off-by: Andrew Jeffery
---
.../pinctrl/aspeed,ast2600-pinctrl.yaml | 128 ++
1 file changed, 128 insertions(+)
create mode 100644
The AST2600 pinmux is fairly similar to the previous generations of
ASPEED BMC SoCs in terms of architecture, though differ in some of the
design details. The complexity of the pin expressions is largely reduced
(e.g. there are no-longer signals with multiple expressions muxing them
to the
This case is common in the AST2600, so add to the collection.
Signed-off-by: Andrew Jeffery
---
drivers/pinctrl/aspeed/pinmux-aspeed.h | 72 ++
1 file changed, 40 insertions(+), 32 deletions(-)
diff --git a/drivers/pinctrl/aspeed/pinmux-aspeed.h
Hello!
This series adds pinmux support for the AST2600. Some more rework was required
on top of the previous cleanup series, but this rework was focussed on
supporting features of the AST2600 pinmux rather than fixing issues with the
existing infrastructure for the ASPEED drivers. Due to the
Hi James, Mark,
On Tue, Jul 9, 2019 at 8:52 PM Tyler Baicar OS
wrote:
> On Mon, Jul 8, 2019 at 10:10 AM James Morse wrote:
> > On 02/07/2019 17:51, Tyler Baicar OS wrote:
> > > @@ -632,6 +633,8 @@ static int do_sea(unsigned long addr, unsigned int
> > > esr, struct pt_regs *regs)
> > >
> > >
On Wed, Jul 10, 2019 at 1:30 AM Christoph Hellwig wrote:
>
> Is there any chance we could save ARCH in .config? That would make
> cross compile builds so much easier.. Same for CROSS_COMPILE.
Then, I have no idea how "make clean", "make help", etc. should work.
If a user has configured the
Hi experts,
On Mon, Jun 24, 2019 at 03:21:23PM +0200, Jiri Kosina wrote:
> On Sat, 22 Jun 2019, Pavel Machek wrote:
>
> > > There is currently no way to verify the resume image when returning
> > > from hibernate. This might compromise the signed modules trust model,
> > > so until we can work
On Wed, Jul 10, 2019 at 7:35 PM Eiichi Tsukata wrote:
>
> Once we find a lack of return address, there is no need to continue
> loop, so let's break out.
Looks good to me, feel free to add
Acked-by: Linus Torvalds
and I'll assume this comes through the x86 -tip tree..
Linus
On Tue, Jul 9, 2019 at 9:57 AM David Teigland wrote:
>
> Apart from a couple trivial fixes, the more notable fix makes the dlm
> continuing waiting for a user space result if a signal interrupts the
> wait event.
What? No.
That's not sensible at all.
If wait_event_interruptible() returns
David Laight 於 2019年7月10日 週三 下午4:57寫道：
>
> From: Jian-Hong Pan
> > Sent: 10 July 2019 09:38
> >
> > Testing with RTL8822BE hardware, when available memory is low, we
> > frequently see a kernel panic and system freeze.
> >
> > First, rtw_pci_rx_isr encounters a memory allocation failure
this patch removes the extra space and use bitmap_zalloc instead
Signed-off-by: yangxingwu
---
net/netfilter/ipvs/ip_vs_mh.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/netfilter/ipvs/ip_vs_mh.c b/net/netfilter/ipvs/ip_vs_mh.c
index 94d9d34..3229867 100644
---
On Wed, Jul 10, 2019 at 09:02:04PM +0200, Jan Kara wrote:
> So how about the attached patch? That keeps the interface sane and passes a
> smoketest for me (full fstest run running). Obviously it also needs a
> proper changelog...
Changelog and slightly massaged version along the lines of my two
Fix build warning:
drivers/mfd/rk808.c:752:12: warning: 'rk8xx_resume' defined but not used
[-Wunused-function]
drivers/mfd/rk808.c:732:12: warning: 'rk8xx_suspend' defined but not used
[-Wunused-function]
The function is declared unconditionally but only called
while CONFIG_PM_SLEEP is set.
Hi all,
On Thu, 11 Jul 2019 13:16:03 +1000 Stephen Rothwell
wrote:
>
> On Thu, 11 Jul 2019 13:13:44 +1000 Stephen Rothwell
> wrote:
> >
> > On Thu, 11 Jul 2019 02:26:27 + Jason Gunthorpe
> > wrote:
> > >
> > > On Thu, Jul 11, 2019 at 11:50:54AM +1000, Stephen Rothwell wrote:
> > >
On Thu, 04 Jul 2019 21:56:01 +0200
Peter Zijlstra wrote:
> Since INT3/#BP no longer runs on an IST, this workaround is no longer
> required.
>
> Tested by running lockdep+ftrace as described in the initial commit:
>
> 5963e317b1e9 ("ftrace/x86: Do not change stacks in DEBUG when calling
>
Hi all,
On Thu, 11 Jul 2019 13:13:44 +1000 Stephen Rothwell
wrote:
>
> On Thu, 11 Jul 2019 02:26:27 + Jason Gunthorpe wrote:
> >
> > On Thu, Jul 11, 2019 at 11:50:54AM +1000, Stephen Rothwell wrote:
> >
> > > So today this failed to build after I merged the rdma tree (previously
> > >
Remove the old drivers to replace them cleanly with a new one later on.
Signed-off-by: Dmitry Osipenko
---
arch/arm/mach-tegra/Makefile | 13 --
arch/arm/mach-tegra/cpuidle-tegra114.c | 89 ---
arch/arm/mach-tegra/cpuidle-tegra20.c | 212 -
The new CPU Idle driver has all necessary features in order to allow
the deepest idling state on Tegra30 SoC where the whole CPU cluster is
power-gated using the coupled idle state.
Note that outer_disable() now need to be invoked directly since it
produces erroneous warning message about
The Tegra CPU Idle driver was moved out into driver/cpuidle/ directory and
it is now a proper platform driver.
Signed-off-by: Dmitry Osipenko
---
arch/arm/configs/tegra_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/tegra_defconfig
Hi Jason,
On Thu, 11 Jul 2019 02:26:27 + Jason Gunthorpe wrote:
>
> On Thu, Jul 11, 2019 at 11:50:54AM +1000, Stephen Rothwell wrote:
>
> > So today this failed to build after I merged the rdma tree (previously
> > it didn;t until after the net-next tree was merged (I assume a
> >
The upcoming unified CPUIDLE driver will be added to the drivers/cpuidle/
directory and it will require all these Tegra PM-core functions.
Signed-off-by: Dmitry Osipenko
---
arch/arm/mach-tegra/Makefile | 2 +-
arch/arm/mach-tegra/platsmp.c | 2 --
arch/arm/mach-tegra/pm.c | 16
The new driver is based on the old CPU Idle drivers that are removed now
from arm/arch/mach-tegra/ directory. Those removed drivers were reworked
and squashed into a single unified driver that covers multiple hardware
generations, starting from Tegra20 and ending with Tegra124.
Signed-off-by:
The Tegra CPU Idle driver was moved out into driver/cpuidle/ directory and
it is now a proper platform driver.
Signed-off-by: Dmitry Osipenko
---
arch/arm/configs/multi_v7_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/configs/multi_v7_defconfig
Hello,
I was spending quite some time recently trying to hunt down CPU-suspend
bug on Tegra30 SoC and in the end it was nailed. During that time I
realized that the CPU Idle drivers could get some polish and gain new
features, thus that's what this series does:
1. Unifies Tegra20/30/114
Arnd, Olof,
Please ignore this.
I wanted to put this patch into Russell's patch tracker,
but just sent it to a wrong ML.
Masahiro Yamada
On Thu, Jul 11, 2019 at 12:08 PM Masahiro Yamada
wrote:
>
> To use Fastfpe, a user is supposed to enable CONFIG_FPE_FASTFPE
> and put downstream source
In function dmac_alloc_recources(), pl330->mcode_cpu is allocated using
dma_alloc_attrs() but freed with dma_free_coherent().
Use the correct dma_free_attrs() function to free pl330->mcode_cpu.
Signed-off-by: Fuqian Huang
---
drivers/dma/pl330.c | 9 +
1 file changed, 5 insertions(+), 4
On 7/7/19 10:52 PM, Suman Anna wrote:
The PRUSS INTC receives a number of system input interrupt source events
and supports individual control configuration and hardware prioritization.
These input events can be mapped to some output host interrupts through 2
levels of many-to-one mapping i.e.
In function __ttm_dma_alloc_page(), d_page->addr is allocated
by dma_alloc_attrs() but freed with use dma_free_coherent() in
__ttm_dma_free_page().
Use the correct dma_free_attrs() to free d_page->vaddr.
Signed-off-by: Fuqian Huang
---
drivers/gpu/drm/ttm/ttm_page_alloc_dma.c | 6 +-
1 file
To use Fastfpe, a user is supposed to enable CONFIG_FPE_FASTFPE
and put downstream source files into arch/arm/fastfpe/.
It is not working for O= build because $(wildcard arch/arm/fastfpe)
checks if it exists in $(objtree), not in $(srctree).
Add the $(srctree)/ prefix to fix it.
While I was
On Wed, Jul 10, 2019 at 09:02:04PM +0200, Jan Kara wrote:
> @@ -848,7 +853,7 @@ static int dax_writeback_one(struct xa_state *xas, struct
> dax_device *dax_dev,
> if (unlikely(dax_is_locked(entry))) {
> void *old_entry = entry;
>
> - entry =
To use Fastfpe, a user is supposed to enable CONFIG_FPE_FASTFPE
and put downstream source files into arch/arm/fastfpe/.
It is not working for O= build because $(wildcard arch/arm/fastfpe)
checks if it exists in $(objtree), not in $(srctree).
Add the $(srctree)/ prefix to fix it.
While I was
Hi Linus,
On Wed, 2019-07-10 at 18:59 -0700, Linus Torvalds wrote:
> Anyway, since it does seem like David is offline, I've just reverted
> this from my tree, and will be continuing my normal merge window pull
> requests (the other issues I have seen have fixes in their respective
> trees).
On Wed, Jul 10, 2019 at 04:53:50PM -0700, Nick Desaulniers wrote:
> On Wed, Jul 10, 2019 at 11:26 AM Jason Gunthorpe wrote:
> >
> > On Wed, Jul 10, 2019 at 10:48:00AM -0700, Nathan Chancellor wrote:
> > > clang warns several times:
> > >
> > > drivers/infiniband/sw/siw/siw_cq.c:31:4: warning:
From: Anson Huang
Add compatible for i.MX8MN and add i.MX8MM/i.MX8MN to the description.
Signed-off-by: Anson Huang
---
Documentation/devicetree/bindings/nvmem/imx-ocotp.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
From: Anson Huang
i.MX8MN is a new SoC of i.MX8M series, it is similar to i.MX8MM
in terms of addressing and clock setup, add support for its fuse
read/write.
Signed-off-by: Anson Huang
---
drivers/nvmem/imx-ocotp.c | 7 +++
1 file changed, 7 insertions(+)
diff --git
This patch fix following perf record error by linking vdso.so with
build id.
perf.data perf.data.old
[ perf record: Woken up 1 times to write data ]
free(): double free detected in tcache 2
Aborted
perf record use filename__read_build_id(util/symbol-minimal.c) to get
build id when libelf is
Current arch_stack_walk_user() checks `if (fp == frame.next_fp)`
to prevent infinite loop by self reference but it's not enogh for
circular reference.
Once we find a lack of return address, there is no need to continue
loop, so let's break out.
Fixes: 02b67518e2b1 ("tracing: add support for
On Thu, Jul 11, 2019 at 11:50:54AM +1000, Stephen Rothwell wrote:
> So today this failed to build after I merged the rdma tree (previously
> it didn;t until after the net-next tree was merged (I assume a
> dependency changed). It failed because in_dev_for_each_ifa_rcu (and
>
On 02/07/2019 20:07, Arnaldo Carvalho de Melo wrote:
Em Fri, Jun 28, 2019 at 10:35:49PM +0800, John Garry escreveu:
The jevent "Unit" field is used for uncore PMU alias definition.
The form uncore_pmu_example_X is supported, where "X" is a wildcard,
to support multiple instances of the same
Add devicetree support for RK3399Pro TB-96AI board, one of
the 96Boards family.
The TB-96AI board is a 96Boards Compute SOM design, launched
by Linaro, Rockchip and Beiqicloud.
More information can be obtained from the following websites:
1.https://www.96boards.org/product/tb-96ai/
From: Ryder Lee
This adds basic support for MT7629 reference board.
Tested-by: Kevin Hilman
Signed-off-by: Ryder Lee
---
Changes since v2:
- fix 'no newline at end of file'.
- fix addresses/sizes cells.
- update u3phy0 node.
- add eth/pcie related nodes.
- add the 'fixed-partitions' nodes in
On Wed, Jul 10, 2019 at 1:15 PM Eric Biggers wrote:
>
> Also worth noting that the key ACL patches were only in linux-next for 9 days
> before the pull request was sent.
Yes. I was not entirely happy with the whole key subsystem situation.
See my concerns in
On Wed, July 10, 2019 1:49 PM Vasily Averin wrote:
>On 7/10/19 6:09 AM, Xiaoming Ni wrote:
>> Registering the same notifier to a hook repeatedly can cause the hook
>> list to form a ring or lose other members of the list.
>
>I think is not enough to _prevent_ 2nd register attempt,
>it's enough to
On Wed, Jul 10, 2019 at 06:09:31PM -0400, J. Bruce Fields wrote:
> On Fri, Jun 28, 2019 at 12:33:58PM -0400, J. Bruce Fields wrote:
> > But I may just give up and go with my existing patch and put
> > off that project indefinitely, especially if there's no real need to fix
> > the existing
Hi all,
On Wed, 10 Jul 2019 17:52:17 + Jason Gunthorpe wrote:
>
> On Tue, Jul 09, 2019 at 09:43:46AM +0300, Leon Romanovsky wrote:
> > On Tue, Jul 09, 2019 at 01:56:36PM +1000, Stephen Rothwell wrote:
> > > Hi all,
> > >
> > > After merging the net-next tree, today's linux-next build
On Thu, 11 Jul 2019, at 00:56, Hongwei Zhang wrote:
> Add SGPIO driver support for Aspeed AST2500 SoC.
>
> Signed-off-by: Hongwei Zhang
> ---
> drivers/gpio/sgpio-aspeed.c | 450
>
> 1 file changed, 450 insertions(+)
> create mode 100644
On Thu, 11 Jul 2019, at 00:24, Hongwei Zhang wrote:
> Hello Andrew,
>
> Thanks for your review and comments, please find our inline response at
> below.
Out of interest, who is Karthik? Are they the one developing the code? If so
the patch should have their authorship/Signed-off-by. It's
On Wed, July 10, 2019 1:56 PM Greg KH wrote:
>On Wed, Jul 10, 2019 at 11:09:07AM +0800, Xiaoming Ni wrote:
>> Registering the same notifier to a hook repeatedly can cause the hook
>> list to form a ring or lose other members of the list.
>
>Then don't do that :)
>
Duplicate registration is
Hi all,
After merging the pm tree, today's linux-next build (powerpc
ppc64_defconfig) produced this warning:
drivers/cpufreq/pasemi-cpufreq.c: In function 'pas_cpufreq_cpu_init':
drivers/cpufreq/pasemi-cpufreq.c:199:1: warning: label 'out_unmap_sdcpwr'
defined but not used [-Wunused-label]
My Sincere Greetings ,
I am Mrs Ivvone Davida Balakiwal, I decided to donate what I have to
you for investment towards the good work of charity organization, and
also to help the motherless and the less privileged ones and to carry
out a charitable works in your Country and around the World on
Thanks for checking my patch.
> On Thu, May 30, 2019 at 06:22:11PM +0900, Takao Orito wrote:
> > Add the device-tree binding documentation for Milbeaut SDHCI driver.
> >
> > Signed-off-by: Takao Orito
> > ---
> > .../devicetree/bindings/mmc/sdhci-milbeaut.txt | 32
> >
When a process expects no accesses to a certain memory range
for a long time, it could hint kernel that the pages can be
reclaimed instantly but data should be preserved for future use.
This could reduce workingset eviction so it ends up increasing
performance.
This patch introduces the new
The isolate counting is pecpu counter so it would be not huge gain
to work them by batch. Rather than complicating to make them batch,
let's make it more stright-foward via adding the counting logic
into [isolate|putback]_lru_page API.
* v1
* fix accounting bug - Hillf
Link:
this patchset includes only first part of my entire patchset
- introduce MADV_COLD and MADV_PAGEOUT hint to madvise.
However, I keep entire description for others for easier understanding
why this kinds of hint was born.
Thanks.
This patchset is against on next-20190710.
Below is description
When a process expects no accesses to a certain memory range, it could
give a hint to kernel that the pages can be reclaimed when memory pressure
happens but data should be preserved for future use. This could reduce
workingset eviction so it ends up increasing performance.
This patch introduces
The local variable references in shrink_page_list is PAGEREF_RECLAIM_CLEAN
as default. It is for preventing to reclaim dirty pages when CMA try to
migrate pages. Strictly speaking, we don't need it because CMA didn't allow
to write out by .may_writepage = 0 in reclaim_clean_pages_from_list.
- Add a VM ioctl that can control which events the guest can monitor.
Signed-off-by: ehankland
---
Changes since v1:
-Moved to a vm ioctl rather than a vcpu one
-Changed from a whitelist to a configurable filter which can either be
white or black
-Only restrict GP counters since fixed counters
On Mon, Jul 8, 2019 at 3:42 PM Krzesimir Nowak wrote:
>
> The test case can now specify a custom length of the data member,
> context data and its length, which will be passed to
> bpf_prog_test_run_xattr. For backward compatilibity, if the data
> length is 0 (which is what will happen when the
Hi, Rob
> On Tue, Jul 9, 2019 at 7:30 PM Anson Huang wrote:
> >
> > Hi, Rob
> >
> > > On Mon, Jul 1, 2019 at 3:47 AM wrote:
> > > >
> > > > From: Anson Huang
> > >
> > > 'dt-bindings: timer: ...' for the subject.
> >
> > OK, I made a mistake.
> >
> > >
> > > >
> > > > Systems which use
1 - 100 of 756 matches
Mail list logo
