On Mon, Sep 16, 2019 at 10:52:50AM +0800, Anson Huang wrote:
> i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
> inside, the system controller is in charge of controlling power,
> clock and scu key etc..
>
> Adds i.MX system controller key driver support, Linux kernel has
> to com
account per-file, dentry, and inode data
blockdev/superblock and temporary per-request data was left alone, as
this usually isn't accounted
Signed-off-by: Khazhismel Kumykov
Reviewed-by: Shakeel Butt
---
fs/fuse/dir.c | 3 ++-
fs/fuse/file.c | 5 +++--
fs/fuse/inode.c | 3 ++-
3 files chang
Implements the optimization noted in f75fdf22b0a8 ("fuse: don't use
->d_time"), as the additional memory can be significant. (In particular,
on SLAB configurations this 8-byte alloc becomes 32 bytes). Per-dentry,
this can consume significant memory.
Reviewed-by: Shakeel Butt
Signed-off-by: Khazhi
On 9/10/19 4:31 PM, Mina Almasry wrote:
> A follow up patch in this series adds hugetlb cgroup uncharge info the
> file_region entries in resv->regions. The cgroup uncharge info may
> differ for different regions, so they can no longer be coalesced at
> region_add time. So, disable region coalescin
On Fri, Sep 13, 2019 at 05:42:13PM +0800, Shengjiu Wang wrote:
> Add the DT binding documentation for NXP MQS driver
>
> Signed-off-by: Shengjiu Wang
Acked-by: Nicolin Chen
> ---
> Changes in v2
> -refine the comments for properties
>
> .../devicetree/bindings/sound/fsl,mqs.txt | 36
On Fri, Sep 13, 2019 at 05:42:14PM +0800, Shengjiu Wang wrote:
> MQS (medium quality sound), is used to generate medium quality
> audio via a standard digital output pin. It can be used to
> connect stereo speakers or headphones simply via power amplifier
> stages without an additional DAC chip. It
The MDIO device reset line is optional and now that gpiod_get_optional()
returns proper value when GPIO support is compiled out, there is no
reason to use fwnode_get_named_gpiod() that I plan to hide away.
Let's switch to using more standard gpiod_get_optional() and
gpiod_set_consumer_name() to ke
On Mon, Sep 16, 2019 at 4:57 PM Mike Kravetz wrote:
>
> On 9/10/19 4:31 PM, Mina Almasry wrote:
> > A follow up patch in this series adds hugetlb cgroup uncharge info the
> > file_region entries in resv->regions. The cgroup uncharge info may
> > differ for different regions, so they can no longer
On Mon, Sep 16, 2019 at 12:36:11PM +0200, Thomas Gleixner wrote:
> > On Fri, 6 Sep 2019, Raj, Ashok wrote:
> > > On Fri, Sep 06, 2019 at 11:16:00PM +0200, Thomas Gleixner wrote:
> > > > Now #1 is actually a sensible and feasible solution which can be pulled
> > > > off
> > > > in a reasonably shor
On Mon, Sep 16, 2019 at 02:32:56PM -0700, Kees Cook wrote:
> When running on a system with >512MB RAM with a 32-bit kernel built with:
>
> CONFIG_DEBUG_VIRTUAL=y
> CONFIG_HIGHMEM=y
> CONFIG_HARDENED_USERCOPY=y
>
> all execve()s will fail due to argv copying into kmap()ed pages,
On 16 September 2019 16:18:00 GMT-07:00, Linus Torvalds
wrote:
>On Mon, Sep 16, 2019 at 4:11 PM Matthew Garrett
>wrote:
>>
>> In one case we have "Systems don't boot, but you can downgrade your
>> kernel" and in the other case we have "Your cryptographic keys are
>weak
>> and you have no way of
On 16 September 2019 16:18:00 GMT-07:00, Linus Torvalds
wrote:
>On Mon, Sep 16, 2019 at 4:11 PM Matthew Garrett
>wrote:
>>
>> In one case we have "Systems don't boot, but you can downgrade your
>> kernel" and in the other case we have "Your cryptographic keys are
>weak
>> and you have no way of
Hi Thierry,
On 16/09/2019 22:28:09+0200, Thierry Reding wrote:
> > > Yeah, I can just send the pull request for the 6 patches after -rc1.
> >
> > Ok, sounds good. I'm also happy to take the remaining patches
> > in that branch, for the other architectures.
>
> All of the patches beyond the 6 in
On (09/16/19 10:42), Steven Rostedt wrote:
[..]
> >
> > This will also fix the hang.
> >
> > Sergey, do you plan to submit this Ted?
>
> Perhaps for a quick fix (and a comment that says this needs to be fixed
> properly).
I guess it would make sense, since LTS and -stable kernels won't get new
The pull request you sent on Mon, 16 Sep 2019 14:03:14 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf-core-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/772c1d06bd402f7ee72c61a18c2db74cd74b6758
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Mon, 16 Sep 2019 13:26:41 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core-rcu-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/94d18ee9340e00ee3455bb45661484093e3b2674
Thank you!
--
Deet-doot-dot, I am a b
The pull request you sent on Mon, 16 Sep 2019 14:30:47 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched-core-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7e67a859997aad47727aff9c5a32e160da079ce3
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Mon, 16 Sep 2019 13:28:06 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> core-stacktrace-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/98c82b4b8be60b05bc96aa4ab664ca0b0e39001f
Thank you!
--
Deet-doot-dot
The pull request you sent on Mon, 16 Sep 2019 13:41:10 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> locking-core-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c7eba51cfdf9cd1ca7ed4201b30be8b2bef15ff5
Thank you!
--
Deet-doot-dot, I
The pull request you sent on Mon, 16 Sep 2019 13:11:01 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> core-headers-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/a480222f4c7cdafad22540f44487f009e359dfb8
Thank you!
--
Deet-doot-dot, I
The pull request you sent on Mon, 16 Sep 2019 13:15:30 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> core-objtool-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/d75a43c645c26ab58118bd35405666a12971350d
Thank you!
--
Deet-doot-dot, I
This RFC is to demonstrate below ideas,
a) Build vhost-mdev on top of the same abstraction defined in
the virtio-mdev series [1];
b) Introduce /dev/vhost-mdev to do vhost ioctls and support
setting mdev device as backend;
Now the userspace API looks like this:
- Userspace generates a comp
This patch introduces the support for getting VFIO device
from VFIO device fd. With this support, it's possible for
vhost to get VFIO device from the group fd and device fd
set by the userspace.
Signed-off-by: Tiwei Bie
---
drivers/vfio/vfio.c | 25 +
include/linux/vfio.
This patch introduces the support for checking the VFIO driver
by device ops. And vfio-mdev's device ops is also exported to
make it possible to check whether a VFIO device is based on a
mdev device.
Signed-off-by: Tiwei Bie
---
drivers/vfio/mdev/vfio_mdev.c | 3 ++-
drivers/vfio/vfio.c
More details about this patch can be found from the cover
letter for now. Only compile test has been done for now.
Signed-off-by: Tiwei Bie
---
drivers/vhost/Kconfig| 9 +
drivers/vhost/Makefile | 3 +
drivers/vhost/mdev.c | 462 +
On Mon, Sep 16, 2019 at 4:29 PM Ahmed S. Darwish wrote:
>
> Linus, in all honesty, the other case is _not_ a hypothetical .
Oh yes it is.
You're confusing "use" with "breakage".
The _use_ of getrandom(0) for key generation isn't hypothetical.
But the _breakage_ from the suggested patch that ma
From: Alastair D'Silva
This series adds bounds checks for hotplugged memory, ensuring that
it is within the physically addressable range (for platforms that
define MAX_(POSSIBLE_)PHYSMEM_BITS.
This allows for early failure, rather than attempting to access
bogus section numbers.
Changelog:
V3:
From: Alastair D'Silva
On PowerPC, the address ranges allocated to OpenCAPI LPC memory
are allocated from firmware. These address ranges may be higher
than what older kernels permit, as we increased the maximum
permissable address in commit 4ffe713b7587
("powerpc/mm: Increase the max addressable
From: Alastair D'Silva
The call to check_hotplug_memory_addressable() validates that the memory
is fully addressable.
Without this call, it is possible that we may remap pages that is
not physically addressable, resulting in bogus section numbers
being returned from __section_nr().
Signed-off-b
On Tue, Sep 10, 2019 at 5:53 AM Biwen Li wrote:
>
> Add some properties for pcf85263/pcf85363 as follows:
> - nxp,rtc-interrupt-type: integer type
> - nxp,rtc-interrupt-output-pin: string type
> - quartz-load-femtofarads: integer type
> - nxp,quartz-drive-strength: integer type
> - nxp,q
On 9/16/19 12:49 PM, George G. Davis wrote:
As reported by Eugeniu Rosca, a side of affect of commit c3f2490d6e92
("selftests: watchdog: Add optional file argument") is that arbitrary files
may be opened for watchdog testing, e.g.
You don't need to say this here since you are already have a
Re
On 16 September 2019 18:05:57 GMT-07:00, Linus Torvalds
wrote:
>On Mon, Sep 16, 2019 at 4:29 PM Ahmed S. Darwish
>wrote:
>>
>> Linus, in all honesty, the other case is _not_ a hypothetical .
>
>Oh yes it is.
>
>You're confusing "use" with "breakage".
>
>The _use_ of getrandom(0) for key generati
On 2019/9/17 上午9:02, Tiwei Bie wrote:
This RFC is to demonstrate below ideas,
a) Build vhost-mdev on top of the same abstraction defined in
the virtio-mdev series [1];
b) Introduce /dev/vhost-mdev to do vhost ioctls and support
setting mdev device as backend;
Now the userspace API lo
On 9/10/19 5:31 PM, Mina Almasry wrote:
Augements hugetlb_cgroup_charge_cgroup to be able to charge hugetlb
usage or hugetlb reservation counter.
Augments?
Adds a new interface to uncharge a hugetlb_cgroup counter via
hugetlb_cgroup_uncharge_counter.
Integrates the counter with hugetlb_cgro
d_absolute_path() regression in the last cycle (felt by tomoyo,
mostly)
The following changes since commit 5f9e832c137075045d15cd6899ab0505cfb2ca4b:
Linus 5.3-rc1 (2019-07-21 14:05:38 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/viro/v
From: Randy Dunlap
arch/microblaze/ is missing support for get_user() of size 8 bytes,
so add it by using __copy_from_user().
While there, also drop a lot of the code duplication.
Fixes these build errors:
drivers/infiniband/core/uverbs_main.o: In function `ib_uverbs_write':
drivers/infin
Infrastructure bits of mount API conversions; the rest is
more of per-filesystem patches and it'll go in a separate pull
request. Requests, actually, since some are (thankfully) in
the individual filesystem trees now (a huge NFS pile, for example).
The following changes since commit d1aba
On Mon, Sep 16, 2019 at 6:24 PM Matthew Garrett wrote:
>
> Exactly the scenario where you want getrandom() to block, yes.
It *would* block. Just not forever.
And btw, the whole "generate key at boot when nothing else is going
on" is already broken, so presumably nobody actually does it.
See why
On 2019/9/16 16:23, Jan Kara wrote:
> On Mon 16-09-19 10:53:08, Chao Yu wrote:
>> On 2019/9/12 18:06, Jan Kara wrote:
>>> On Wed 11-09-19 17:36:50, Chao Yu wrote:
diff --git a/include/linux/quotaops.h b/include/linux/quotaops.h
index dc905a4ff8d7..bd30acad3a7f 100644
--- a/include/li
From: Alastair D'Silva
This series provides the prerequisite infrastructure to allow
external drivers to map & access OpenCAPI LPC memory.
Alastair D'Silva (5):
powerpc: Add OPAL calls for LPC memory alloc/release
powerpc: Map & release OpenCAPI LPC memory
ocxl: Tally up the LPC memory on
From: Alastair D'Silva
Tally up the LPC memory on an OpenCAPI link & allow it to be mapped
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/core.c | 9 +
drivers/misc/ocxl/link.c | 61 +++
drivers/misc/ocxl/ocxl_internal.h | 42 ++
From: Alastair D'Silva
Map & release OpenCAPI LPC memory.
Signed-off-by: Alastair D'Silva
---
arch/powerpc/include/asm/pnv-ocxl.h | 2 ++
arch/powerpc/platforms/powernv/ocxl.c | 42 +++
2 files changed, 44 insertions(+)
diff --git a/arch/powerpc/include/asm/pnv-ocxl
From: Alastair D'Silva
Add OPAL calls for LPC memory alloc/release
Signed-off-by: Alastair D'Silva
---
arch/powerpc/include/asm/opal-api.h| 4 +++-
arch/powerpc/include/asm/opal.h| 3 +++
arch/powerpc/platforms/powernv/opal-call.c | 2 ++
3 files changed, 8 insertions(+), 1
From: Alastair D'Silva
This patch exposes the OpenCAPI device serial number to
userspace.
It also includes placeholders for the LPC & special purpose
memory information (which will be populated in a subsequent patch)
to avoid creating excessive versions of the IOCTL.
Signed-off-by: Alastair D'S
From: Alastair D'Silva
Add functions to map/unmap LPC memory
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/config.c| 4 +++
drivers/misc/ocxl/core.c | 50 +++
drivers/misc/ocxl/link.c | 4 +--
drivers/misc/ocxl/ocxl_internal.h | 1
On Mon, Aug 12, 2019 at 11:21 PM Jes Sorensen wrote:
>
> On 8/12/19 10:32 AM, Kalle Valo wrote:
> >> Signed-off-by: Jes Sorensen
> >
> > This is marked as RFC so I'm not sure what's the plan. Should I apply
> > this?
>
> I think it's at a point where it's worth applying - I kinda wish I had
> had
On 9/10/19 5:31 PM, Mina Almasry wrote:
The tests use both shared and private mapped hugetlb memory, and
monitors the hugetlb usage counter as well as the hugetlb reservation
counter. They test different configurations such as hugetlb memory usage
via hugetlbfs, or MAP_HUGETLB, or shmget/shmat, a
On Mon, Sep 16, 2019 at 4:39 PM syzbot
wrote:
>
> Hello,
>
> syzbot found the following crash on:
>
> HEAD commit:1609d760 Merge tag 'for-linus' of git://git.kernel.org/pub..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10236abe60
> kernel config:
On 9/10/19 5:31 PM, Mina Almasry wrote:
Add docs for how to use hugetlb_cgroup reservations, and their behavior.
Signed-off-by: Mina Almasry
Acked-by: Hillf Danton
---
.../admin-guide/cgroup-v1/hugetlb.rst | 84 ---
1 file changed, 73 insertions(+), 11 deletions(-)
On Mon, Sep 16, 2019 at 10:15:16PM +0100, Will Deacon wrote:
>On Sat, Sep 14, 2019 at 12:03:26AM +, Wei Yang wrote:
>> On Mon, Jul 08, 2019 at 04:27:40PM +0800, Wei Yang wrote:
>> >Since ptent will not be changed after previous assignment of entry, it
>> >is not necessary to do the assignment a
On 16 September 2019 18:41:36 GMT-07:00, Linus Torvalds
wrote:
>On Mon, Sep 16, 2019 at 6:24 PM Matthew Garrett
>wrote:
>>
>> Exactly the scenario where you want getrandom() to block, yes.
>
>It *would* block. Just not forever.
It's already not forever - there's enough running in the background
On Mon, Sep 16, 2019 at 02:38:40PM +0200, Johannes Weiner wrote:
> On Thu, Sep 05, 2019 at 02:45:48PM -0700, Roman Gushchin wrote:
> > In order to prepare for per-object slab memory accounting,
> > convert NR_SLAB_RECLAIMABLE and NR_SLAB_UNRECLAIMABLE vmstat
> > items to bytes.
> >
> > To make sur
On Mon, Sep 16, 2019 at 02:56:11PM +0200, Johannes Weiner wrote:
> On Thu, Sep 05, 2019 at 02:45:45PM -0700, Roman Gushchin wrote:
> > Introduce an API to charge subpage objects to the memory cgroup.
> > The API will be used by the new slab memory controller. Later it
> > can also be used to implem
Hi Rafael,
On Wednesday, August 21, 2019 11:16, Ran Wang wrote:
>
> Some user might want to go through all registered wakeup sources and doing
> things accordingly. For example, SoC PM driver might need to do HW
> programming to prevent powering down specific IP which wakeup source
> depending on
>(2) What prevents proc_comm_connector(p) running concurrently with itself
> via the prctl()? The locking seems to be confined to set_task_comm().
To be honest, I did not consider the concurrence problem at beginning. And
some comm change events may lost or are reported repeatly as follows:
set nam
In das1800_attach, the buffer allocated via kmalloc_array needs to be
released if an error happens.
Signed-off-by: Navid Emamdoost
---
drivers/staging/comedi/drivers/das1800.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/comedi/drivers/das1800.
On Wed, 4 Sep 2019 10:39:10 +0800, zhong jiang wrote:
> Use kzfree() instead of memset() + kfree().
>
> Signed-off-by: zhong jiang
> ---
> drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/ethernet/intel/
Hi, Dmitry
> On Mon, Sep 16, 2019 at 10:52:50AM +0800, Anson Huang wrote:
> > i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
> > inside, the system controller is in charge of controlling power, clock
> > and scu key etc..
> >
> > Adds i.MX system controller key driver support, Li
On 2019/09/09 16:46, David Hildenbrand wrote:
> Let's take a step back here to understand the issues I am aware of. I
> think we should solve this for good now:
>
> A PFN walker takes a look at a random PFN at a random point in time. It
> finds a PFN with SECTION_MARKED_PRESENT && !SECTION_IS_ONLI
On 9/16/19 4:42 AM, Helen Koike wrote:
On 9/15/19 8:52 PM, Shuah Khan wrote:
On 9/15/19 1:25 PM, Helen Koike wrote:
Hi Shuah,
On 9/6/19 11:42 PM, Shuah Khan wrote:
Move duplicated IS_SRC and IS_SINK dfines to common header. Rename
them to VIMC_IS_SRC and VIM_IS_SINK.
Signed-off-by: Shuah K
On Wed, 4 Sep 2019 11:46:23 +0800, zhong jiang wrote:
> Continue is not needed at the bottom of a loop.
>
> Signed-off-by: zhong jiang
> ---
> drivers/net/ethernet/netronome/nfp/nfp_net_main.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/net/ethernet/netro
The pull request you sent on Mon, 16 Sep 2019 14:58:11 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-entry-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e0d60a1e68a3fbf42cdf3546004e00230d9048ba
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Mon, 16 Sep 2019 14:42:56 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-build-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fc6fd1392a8f3d5f3d722ad9c92314477c1a2a35
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Mon, 16 Sep 2019 14:53:27 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-cpu-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/22331f895298bd23ca9f99f6a237aae883c9e1c7
Thank you!
--
Deet-doot-dot, I am a bo
The pull request you sent on Mon, 16 Sep 2019 15:36:46 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-vmware-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/7ac63f6ba5db5e2e81e4674551d6f9ec58e70618
Thank you!
--
Deet-doot-dot, I am a
The pull request you sent on Mon, 16 Sep 2019 15:31:09 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
> x86-platform-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/6f24671485d0d0eaeaccd910fa8148db72aac089
Thank you!
--
Deet-doot-dot, I
The pull request you sent on Mon, 16 Sep 2019 14:39:43 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-boot-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/49a21e52a6baeea076301fd944268fd0d1f75be1
Thank you!
--
Deet-doot-dot, I am a b
The pull request you sent on Mon, 16 Sep 2019 15:25:10 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-mm-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ac51667b5b95f1209aa97af780cecf0cf6f4003f
Thank you!
--
Deet-doot-dot, I am a bot
The pull request you sent on Mon, 16 Sep 2019 14:34:54 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-asm-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/df4c0b18f2a2798f1e3ae9dcf58c024bb33e4202
Thank you!
--
Deet-doot-dot, I am a bo
The pull request you sent on Mon, 16 Sep 2019 15:18:51 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86-hyperv-for-linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/e2bddc20b562ee23046ad541cf29314e4aebd934
Thank you!
--
Deet-doot-dot, I am a
On 9/17/19 2:25 AM, Leonardo Bras wrote:
If a process (qemu) with a lot of CPUs (128) try to munmap() a large chunk
of memory (496GB) mapped with THP, it takes an average of 275 seconds,
which can cause a lot of problems to the load (in qemu case, the guest
will lock for this time).
Trying to fi
NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller, the system controller is in charge of system
power, clock and scu key event etc. management, Linux kernel has
to communicate with system controller via MU (message unit) IPC
to get scu key event, add binding doc for i.M
Select CONFIG_KEYBOARD_IMX_SC_KEY as module by default to
support i.MX8QXP scu key driver.
Signed-off-by: Anson Huang
---
No changes.
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0a70e10..9c
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and scu key etc..
Adds i.MX system controller key driver support, Linux kernel has
to communicate with system controller via MU (message unit) IPC
to get scu key'
Add scu key node for i.MX8QXP, disabled by default as it
depends on board design.
Signed-off-by: Anson Huang
---
No changes.
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts
Enable scu key for i.MX8QXP MEK board.
Signed-off-by: Anson Huang
---
No changes.
---
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
index 1946805
We are excited to see this happening and would like to state that we appreciate
time and
effort which people put into upstreaming exfat. Thank you!
However, if possible, can we step back a little bit and re-consider it? We
would prefer to
see upstream the code which we are currently using in our p
The pull request you sent on Fri, 13 Sep 2019 20:06:55 +0300:
> git://git.infradead.org/linux-platform-drivers-x86.git
> tags/platform-drivers-x86-v5.4-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/ad062195731bea1624ce7160e79e0fcdaa25c1b5
Thank you!
--
Deet-doot
On Mon, Sep 16, 2019 at 05:32:09PM -0700, Matthew Wilcox wrote:
> On Mon, Sep 16, 2019 at 02:32:56PM -0700, Kees Cook wrote:
> > When running on a system with >512MB RAM with a 32-bit kernel built with:
> >
> > CONFIG_DEBUG_VIRTUAL=y
> > CONFIG_HIGHMEM=y
> > CONFIG_HARDENED_USERCOPY=y
On Mon, Sep 16, 2019 at 06:39:46PM -0700, keesc...@chromium.org wrote:
> commit 519248f36d6f3c80e176f6fa844c10d94f1f5990
> Author: Paul E. McKenney
> Date: Thu May 30 05:39:25 2019 -0700
>
> lockdep: Make print_lock() address visible
>
> Security is a wonderful thing, but so is the
On 2019/9/17 10:45, Jakub Kicinski wrote:
> On Wed, 4 Sep 2019 11:46:23 +0800, zhong jiang wrote:
>> Continue is not needed at the bottom of a loop.
>>
>> Signed-off-by: zhong jiang
>> ---
>> drivers/net/ethernet/netronome/nfp/nfp_net_main.c | 4 +---
>> 1 file changed, 1 insertion(+), 3 deletion
On 09/16/2019 02:20 PM, Anshuman Khandual wrote:
>
>
> On 09/16/2019 12:06 PM, Mike Rapoport wrote:
>> On Mon, Sep 16, 2019 at 11:17:37AM +0530, Anshuman Khandual wrote:
>>> In add_memory_resource() the memory range to be hot added first gets into
>>> the memblock via memblock_add() before arc
i.MX8QXP is an ARMv8 SoC which has a Cortex-M4 system controller
inside, the system controller is in charge of controlling power,
clock and scu key etc..
Adds i.MX system controller key driver support, Linux kernel has
to communicate with system controller via MU (message unit) IPC
to get scu key'
Select CONFIG_KEYBOARD_IMX_SC_KEY as module by default to
support i.MX8QXP scu key driver.
Signed-off-by: Anson Huang
---
No changes.
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 0a70e10..9c
Add scu key node for i.MX8QXP, disabled by default as it
depends on board design.
Signed-off-by: Anson Huang
---
No changes.
---
arch/arm64/boot/dts/freescale/imx8qxp.dtsi | 7 +++
1 file changed, 7 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp.dtsi
b/arch/arm64/boot/dts
Sorry, please ignore this version, it has build issue, just resent the patch
series.
Anson.
> Subject: [PATCH V5 1/5] dt-bindings: fsl: scu: add scu key binding
>
> NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as system
> controller, the system controller is in charge of system pow
NXP i.MX8QXP is an ARMv8 SoC with a Cortex-M4 core inside as
system controller, the system controller is in charge of system
power, clock and scu key event etc. management, Linux kernel has
to communicate with system controller via MU (message unit) IPC
to get scu key event, add binding doc for i.M
Enable scu key for i.MX8QXP MEK board.
Signed-off-by: Anson Huang
---
No changes.
---
arch/arm64/boot/dts/freescale/imx8qxp-mek.dts | 4
1 file changed, 4 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
b/arch/arm64/boot/dts/freescale/imx8qxp-mek.dts
index 1946805
On 2019/9/17 10:43, Jakub Kicinski wrote:
> On Wed, 4 Sep 2019 10:39:10 +0800, zhong jiang wrote:
>> Use kzfree() instead of memset() + kfree().
>>
>> Signed-off-by: zhong jiang
>> ---
>> drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 9 +++--
>> 1 file changed, 3 insertions(+), 6 deletions
Hi Vignesh,
Thank you for the review comments and suggestions.
On 17/9/2019 12:50 AM, Vignesh Raghavendra wrote:
Hi,
On 16/09/19 1:08 PM, Ramuthevar,Vadivel MuruganX wrote:
patch 1: Add YAML for cadence-qspi devicetree cdocumentation.
patch 2: cadence-qspi controller driver to support QSPI
In rpmsg_eptdev_write_iter, if copy_from_iter_full fails the allocated
buffer needs to be released.
Signed-off-by: Navid Emamdoost
---
drivers/rpmsg/rpmsg_char.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
inde
On 2019/9/17 上午9:02, Tiwei Bie wrote:
This RFC is to demonstrate below ideas,
a) Build vhost-mdev on top of the same abstraction defined in
the virtio-mdev series [1];
b) Introduce /dev/vhost-mdev to do vhost ioctls and support
setting mdev device as backend;
Now the userspace API lo
Hi Linus,
Can you please pull the m68knommu git tree, for-next branch.
Only a single change, fix up header include in ColdFire specific GPIO
handling code.
Regards
Greg
The following changes since commit f74c2bb98776e2de508f4d607cd519873065118e:
Linux 5.3-rc8 (2019-09-08 13:33:15 -0700
Hi Anson,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190916]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Anson
It's better to use memset_explicit() to replace memset() in crypto cases.
Signed-off-by: zhong jiang
---
drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ipsec.c
b/drivers/net/ethernet
Hi greg,
First apologies for sending this very late, I had to go out of town and
didn't have internet access, but I should have done better
Anyhow, here are the changes collected for v5.4-rc1 and as usual they
have been sitting in linux-next.
The following changes since commit 5f9e832c137075045d
In affs_init_bitmap, on error handling path we may release the allocated
memory.
Signed-off-by: Navid Emamdoost
---
fs/affs/bitmap.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/fs/affs/bitmap.c b/fs/affs/bitmap.c
index 5ba9ef2742f6..745ed2cc4b51 100644
--- a/fs/affs/bitmap.c
+++ b/fs/aff
On Tue, 17 Sep 2019 12:02:01 +0900, "Namjae Jeon" said:
> We are excited to see this happening and would like to state that we
> appreciate time and
> effort which people put into upstreaming exfat. Thank you!
The hard part - getting Microsoft to OK merging an exfat driver - is done.
All we need
Hi Alastair,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.3 next-20190916]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits
On 09/13/2019 03:39 PM, Catalin Marinas wrote:
> On Fri, Sep 13, 2019 at 11:28:01AM +0530, Anshuman Khandual wrote:
>> On 09/13/2019 01:45 AM, Catalin Marinas wrote:
>>> On Tue, Sep 03, 2019 at 03:15:58PM +0530, Anshuman Khandual wrote:
@@ -770,6 +1022,28 @@ int __meminit vmemmap_populate(u
701 - 800 of 847 matches
Mail list logo
