atomic_t variables are currently used to implement reference
counters with the following properties:
- counter is initialized to 1 using atomic_set()
- a resource is freed upon counter reaching zero
- once counter reaches zero, its further
increments aren't allowed
- counter schema uses basi
atomic_t variables are currently used to implement reference
counters with the following properties:
- counter is initialized to 1 using atomic_set()
- a resource is freed upon counter reaching zero
- once counter reaches zero, its further
increments aren't allowed
- counter schema uses basi
atomic_t variables are currently used to implement reference
counters with the following properties:
- counter is initialized to 1 using atomic_set()
- a resource is freed upon counter reaching zero
- once counter reaches zero, its further
increments aren't allowed
- counter schema uses basi
atomic_t variables are currently used to implement reference
counters with the following properties:
- counter is initialized to 1 using atomic_set()
- a resource is freed upon counter reaching zero
- once counter reaches zero, its further
increments aren't allowed
- counter schema uses basi
atomic_t variables are currently used to implement reference
counters with the following properties:
- counter is initialized to 1 using atomic_set()
- a resource is freed upon counter reaching zero
- once counter reaches zero, its further
increments aren't allowed
- counter schema uses basi
On Wed 29-11-17 10:22:34, Michal Hocko wrote:
> What about this on top. I haven't tested this yet though.
OK, it seem to work:
root@test1:~# echo 1 > /proc/sys/vm/nr_hugepages
root@test1:~# echo 1 >
/sys/kernel/mm/hugepages/hugepages-2048kB/nr_overcommit_hugepages
root@test1:~# grep . /sys/devic
On Sat, 11 Nov 2017, Johan Hovold wrote:
> A helper purported to look up a child node based on its name was using
> the wrong of-helper and ended up prematurely freeing the parent of-node
> while leaking any matching node.
>
> To make things worse, any matching node would not even necessarily be
On Sat, 11 Nov 2017, Johan Hovold wrote:
> Fix child-node lookup during probe, which ended up searching the whole
> device tree depth-first starting at the parent rather than just matching
> on its children.
>
> To make things worse, the parent node was prematurely freed, while the
> child node w
atomic_t variables are currently used to implement reference
counters with the following properties:
- counter is initialized to 1 using atomic_set()
- a resource is freed upon counter reaching zero
- once counter reaches zero, its further
increments aren't allowed
- counter schema uses basi
On 11/26/2017 03:21 PM, Jarkko Sakkinen wrote:
> On Wed, Nov 22, 2017 at 08:25:29PM +0100, Javier Martinez Canillas wrote:
>> That was my interpretation as well and what I was arguing about. I'm glad to
>> know that you also think the same.
>
> It could be that this rationale has been your earlier
On Tue, Nov 28, 2017 at 06:52:32PM +0100, Dmitry Vyukov wrote:
> On Tue, Nov 28, 2017 at 4:24 PM, Mark Rutland wrote:
> >> ... it looks suspiciously like something is setting up non-zero shadow
> >> bytes, but not zeroing them upon return.
> >
> > It looks like this is the case.
> >
> > The hack
On Mon, 20 Nov 2017, Johan Hovold wrote:
> Fix child-node lookup during probe, which ended up searching the whole
> device tree depth-first starting at the parent rather than just matching
> on its children.
>
> To make things worse, the parent mfd node was also prematurely freed.
>
> Fixes: 59e
On Mon, 20 Nov 2017, Johan Hovold wrote:
> Fix child-node lookup during probe, which ended up searching the whole
> device tree depth-first starting at the parent rather than just matching
> on its children.
>
> To make things worse, the parent mfd node was also prematurely freed,
> while the chi
On Mon, 20 Nov 2017, Johan Hovold wrote:
> Two framebuffer device-node names were looked up during probe, but were
> only used as flags to indicate the presence of two framebuffer device.
>
> Drop the unused framebuffer name along with a likewise unused device
> pointer from the driver data, and
On Mon, 20 Nov 2017, Johan Hovold wrote:
> Fix child-node lookup during probe, which ended up searching the whole
> device tree depth-first starting at the parent rather than just matching
> on its children.
>
> This would only cause trouble if the child node is missing while there
> is an unrela
On Wed, Nov 29, 2017 at 12:16 PM, Tobin C. Harding wrote:
> On Wed, Nov 29, 2017 at 09:59:59AM +0200, Alexander Kapshuk wrote:
>> On Tue, Nov 28, 2017 at 11:10 PM, Tobin C. Harding wrote:
>> > On Tue, Nov 28, 2017 at 03:16:24PM +0200, Alexander Kapshuk wrote:
>> >> On Tue, Nov 28, 2017 at 8:32 AM
OK, so this is the v2 with all the fixups folded in. It doesn't blow up
immediately and even seem to work.
---
>From 5de969daf882122690f0dfc028d09f88f312b7fa Mon Sep 17 00:00:00 2001
From: Michal Hocko
Date: Wed, 29 Nov 2017 12:31:49 +0100
Subject: [PATCH] mm, hugetlb: do not rely on overcommit li
On Mon, 20 Nov 2017, Thierry Escande wrote:
> This patch splits the cros_ec_devs module in two parts with a
> cros_ec_dev module responsible for handling MFD devices registration and
> a cros_ec_ctl module responsible for handling the various user-space
> interfaces.
>
> For consistency purpose,
On Mon, 20 Nov 2017, Thierry Escande wrote:
> The cros_ec_dev module is responsible for registering the MFD devices
> attached to the ChromeOS EC. This patch moves this module to drivers/mfd
> so calls to mfd_add_devices() are not done from outside the MFD subtree
> anymore.
>
> Signed-off-by: Th
On Tue, 07 Nov 2017, Masahiro Yamada wrote:
> These registers are only used in drivers/mfd/tmio_core.c
>
> Signed-off-by: Masahiro Yamada
> ---
>
> drivers/mfd/tmio_core.c | 20
> include/linux/mfd/tmio.h | 20
> 2 files changed, 20 insertions(+), 20
On 29/11/17 10:18, Linus Walleij wrote:
On Thu, Nov 23, 2017 at 6:13 PM, Richard Fitzgerald
wrote:
+config MFD_MADERA_I2C
+ bool "Cirrus Logic Madera codecs with I2C"
+ select MFD_MADERA
+ select REGMAP_I2C
+ depends on I2C
+ depends on PINCTRL
+ help
+
On Wed, Nov 29 2017, Greg Kroah-Hartman wrote:
> On Wed, Nov 29, 2017 at 02:01:12PM +1100, NeilBrown wrote:
>> Subject: [PATCH] staging: lustre: lov: use list_for_each_entry in lov_obd.c
>
> Why is there a subject line in the body of the text here? Will git
> figure this out correctly?
Because I
atomic_t variables are currently used to implement reference
counters with the following properties:
- counter is initialized to 1 using atomic_set()
- a resource is freed upon counter reaching zero
- once counter reaches zero, its further
increments aren't allowed
- counter schema uses basi
atomic_t variables are currently used to implement reference
counters with the following properties:
- counter is initialized to 1 using atomic_set()
- a resource is freed upon counter reaching zero
- once counter reaches zero, its further
increments aren't allowed
- counter schema uses basi
atomic_t variables are currently used to implement reference
counters with the following properties:
- counter is initialized to 1 using atomic_set()
- a resource is freed upon counter reaching zero
- once counter reaches zero, its further
increments aren't allowed
- counter schema uses basi
atomic_t variables are currently used to implement reference
counters with the following properties:
- counter is initialized to 1 using atomic_set()
- a resource is freed upon counter reaching zero
- once counter reaches zero, its further
increments aren't allowed
- counter schema uses basi
atomic_t variables are currently used to implement reference
counters with the following properties:
- counter is initialized to 1 using atomic_set()
- a resource is freed upon counter reaching zero
- once counter reaches zero, its further
increments aren't allowed
- counter schema uses basi
Hi Dave,
Following our previous conversation I have updated each
patch with a highlight of potential problematic places
with regards to the memory ordering guarantees, as well
as link to the document I am working on to clarify the
matter.
While I didn't see any issues with these 5 particular
conv
On Mon, 20 Nov 2017, Vasyl Gomonovych wrote:
> drivers/mfd/kempld-core.c:461:13-16: WARNING: Suspicious code. resource_size
> is maybe missing with ioport
>
> Generated by: scripts/coccinelle/api/resource_size.cocci
>
> Signed-off-by: Vasyl Gomonovych
> ---
> drivers/mfd/kempld-core.c | 2 +-
2017-11-29 17:25 GMT+08:00 Arnd Bergmann :
> On Wed, Nov 29, 2017 at 10:10 AM, Geert Uytterhoeven
> wrote:
>> Hi Arnd,
>>
>> On Wed, Nov 29, 2017 at 9:58 AM, Arnd Bergmann wrote:
>>> On Wed, Nov 29, 2017 at 9:39 AM, Greentime Hu wrote:
2017-11-27 22:21 GMT+08:00 Arnd Bergmann :
> On Mon
On Wed, Nov 29, 2017 at 12:26 PM, Mark Rutland wrote:
> On Tue, Nov 28, 2017 at 06:52:32PM +0100, Dmitry Vyukov wrote:
>> On Tue, Nov 28, 2017 at 4:24 PM, Mark Rutland wrote:
>
>> >> ... it looks suspiciously like something is setting up non-zero shadow
>> >> bytes, but not zeroing them upon retu
On Wed, 29 Nov 2017, Linus Walleij wrote:
> This should be enabled so that we get full compile coverage
> of the PM8xxx MFD core with the different subdrivers.
>
> Tested on the build servers.
>
> Suggested-by: Jonathan Cameron
> Signed-off-by: Linus Walleij
> ---
> drivers/mfd/Kconfig | 2 +-
On Mon, Nov 13, 2017 at 09:32:09AM +0100, Paolo Bonzini wrote:
> On 13/11/2017 08:15, Wanpeng Li wrote:
> > 2017-11-10 17:49 GMT+08:00 Paolo Bonzini :
> >> Sometimes, a processor might execute an instruction while another
> >> processor is updating the page tables for that instruction's code page,
On 29/11/2017 12:44, Eduardo Habkost wrote:
> On Mon, Nov 13, 2017 at 09:32:09AM +0100, Paolo Bonzini wrote:
>> On 13/11/2017 08:15, Wanpeng Li wrote:
>>> 2017-11-10 17:49 GMT+08:00 Paolo Bonzini :
Sometimes, a processor might execute an instruction while another
processor is updating the
On Wed, Nov 29, 2017 at 12:32:25PM +0300, Yury Norov wrote:
> On Tue, Nov 28, 2017 at 06:33:55PM +, Will Deacon wrote:
> > On Sat, Nov 25, 2017 at 12:41:27PM +0300, Yury Norov wrote:
> > > It was discovered during LTO-enabled compilation with gcc/ld.bfd.
> >
> > What was discovered? Could you
On Wed, Nov 29, 2017 at 11:33:05AM +0100, Peter Zijlstra wrote:
> XXX we could do a much larger ALTERNATIVE, there is no point in
> testing the mask if we don't have PCID support.
This.
> @@ -220,7 +215,27 @@ For 32-bit we have the following convent
> .macro SWITCH_TO_USER_CR3 scratch_reg:req
>
The vendor code waits for infoframe to detect video mode set by source.
We do not need to follow this pattern, because video mode information is
provided by drm core. As a result most of the infoframe handling
code can be removed.
Start transmission immediately after detecting stream on HDMI lines
Hi Lee,
On 14/11/17 17:00, Shawn N wrote:
> On Wed, Sep 27, 2017 at 3:19 PM, Brian Norris
> wrote:
>> On Wed, Sep 27, 2017 at 02:35:27PM -0700, Shawn Nematbakhsh wrote:
>>> For host commands that take a long time to process, cros ec can return
>>> early by signaling a EC_RES_IN_PROGRESS result.
On 29.11.2017 11:01, Geert Uytterhoeven wrote:
> On 64-bit (e.g. powerpc64/allmodconfig):
>
> drivers/net/ethernet/xilinx/ll_temac_main.c: In function
> 'temac_start_xmit_done':
> drivers/net/ethernet/xilinx/ll_temac_main.c:633:22: warning: cast to
> pointer from integer of different siz
Hi, Arnd:
2017-11-27 22:33 GMT+08:00 Arnd Bergmann :
> On Mon, Nov 27, 2017 at 1:28 PM, Greentime Hu wrote:
>> +
>> +#define L2C_R_REG(offset) __raw_readl(atl2c_base + offset)
>> +#define L2C_W_REG(offset, value)__raw_writel(value, atl2c_base +
>> offset)
>
> __raw_readl()
On Wed, 29 Nov 2017 15:27:46 +1100
"Tobin C. Harding" wrote:
> On Tue, Nov 28, 2017 at 09:39:57PM -0500, Steven Rostedt wrote:
> > On Wed, 29 Nov 2017 13:05:02 +1100
> > "Tobin C. Harding" wrote:
> >
> > > + /*
> > > + * kptr_restrict==1 cannot be used in IRQ context
> > > +
On Thu 23-11-17 14:55:40, Al Viro wrote:
> On Thu, Nov 23, 2017 at 03:35:37PM +0100, Michal Hocko wrote:
> > Hopefully less screwed version. But as I've said I am not really
> > familiar with the code and do not feel competent to change it so please
> > be very careful here. I've moved the shrinke
On Wed, Nov 29, 2017 at 10:24:57AM +0100, Vincent Guittot wrote:
> Hi Morten,
>
> On 27 November 2017 at 18:29, Morten Rasmussen
> wrote:
> > SD_PREFER_SIBLING adds an additional bias towards spreading tasks on the
> > _parent_ sched_domain even if a sched_group isn't overloaded. It is
> > curren
On 2017/11/27 14:54, Yunlong Song wrote:
> Sometimes f2fs_gc is called with no target victim (e.g. xfstest
> generic/027, ndirty_node:545 ndiry_dent:1 ndirty_imeta:513 rsvd_segs:21
> free_segs:27, has_not_enough_free_secs will return true). This patch
> first merges pages and then converts into sec
On Wed, Nov 29, 2017 at 12:39 PM, Greentime Hu wrote:
> 2017-11-29 17:25 GMT+08:00 Arnd Bergmann :
>> On Wed, Nov 29, 2017 at 10:10 AM, Geert Uytterhoeven
>> wrote:
>>> Hi Arnd,
>>>
>>> On Wed, Nov 29, 2017 at 9:58 AM, Arnd Bergmann wrote:
On Wed, Nov 29, 2017 at 9:39 AM, Greentime Hu wrot
[Resent without the disclaimer at the bottom. Sorry!]
On Wed, Nov 29, 2017 at 10:24:57AM +0100, Vincent Guittot wrote:
> Hi Morten,
>
> On 27 November 2017 at 18:29, Morten Rasmussen
> wrote:
> > SD_PREFER_SIBLING adds an additional bias towards spreading tasks on the
> > _parent_ sched_domain e
On Mon, Nov 20, 2017 at 2:28 PM, Dmitry Vyukov wrote:
>>> > R13: 00402260 R14: 004022f0 R15:
>>> > kasan: CONFIG_KASAN_INLINE enabled
>>> > kasan: GPF could be caused by NULL-ptr deref or user memory access
>>> > general protection fault: [#1] SMP KASAN
>>> >
On Wed 29-11-17 17:13:27, zhong jiang wrote:
> Currently, Arm64 and x86 use the common code wehn parsing numa node
> in a acpi way. The arm64 will set the parsed node in numa_add_memblk,
> but the x86 is not set in that , then it will result in the repeatly
> setting. And the parsed node maybe is
On 2017/11/29 16:38, Gang He wrote:
> Add ocfs2_try_rw_lock and ocfs2_try_inode_lock functions, which
> will be used in non-block IO scenarios.
>
> Signed-off-by: Gang He
> ---
> fs/ocfs2/dlmglue.c | 21 +
> fs/ocfs2/dlmglue.h | 4
> 2 files changed, 25 insertions(+)
It looks fine to me.
On 2017/11/29 16:39, Gang He wrote:
> Add ocfs2_overwrite_io function, which is used to judge if
> overwrite allocated blocks, otherwise, the write will bring extra
> block allocation overhead.
>
> Signed-off-by: Gang He
Reviewed-by: Changwei Ge
> ---
> fs/ocfs2/extent_m
On Wed, 27 Sep 2017, Shawn Nematbakhsh wrote:
> For host commands that take a long time to process, cros ec can return
> early by signaling a EC_RES_IN_PROGRESS result. The host must then poll
> status with EC_CMD_GET_COMMS_STATUS until completion of the command.
>
> None of the above applies whe
On Wed, 29 Nov 2017 05:36:35 +
NAMIT GUPTA wrote:
> ping
>
Thanks for the ping. I should have sent a note that I see your email.
I'm just a bit backed up in other patches, I haven't gotten to it yet.
I should get to it this week, if not, ping me again next week.
-- Steve
On 29 November 2017 at 00:00, Sami Tolvanen wrote:
> From: Greg Hackmann
>
> LLVM bug 30792 causes clang's AArch64 backend to crash compiling
> arch/arm64/crypto/aes-ce-cipher.c. Replacing -mgeneral-regs-only with
> -mno-implicit-float is the suggested workaround.
>
Do we still need these patch
On Wed, 29 Nov 2017 16:35:01 +0800
Xie XiuQi wrote:
> We meet this compile warning, which caused by missing bpf.h in xdp.h.
>
> In file included from ./include/trace/events/xdp.h:10:0,
> from ./include/linux/bpf_trace.h:6,
> from drivers/net/ethernet/intel/i40e/
On Tue 28-11-17 14:00:23, Kemi Wang wrote:
> The existed implementation of NUMA counters is per logical CPU along with
> zone->vm_numa_stat[] separated by zone, plus a global numa counter array
> vm_numa_stat[]. However, unlike the other vmstat counters, numa stats don't
> effect system's decision
On Wed, Nov 29, 2017 at 12:05:13PM +0100, Stephan Müller wrote:
>
> Shouldn't we then create a patch for the pre-4.14 algif_skcipher code that
> moves the wait out of the while loop to the beginning of the function in
> recvmsg?
When I said dead-lock I just meant that the recvmsg will block
inde
On 29.11.2017 12:10, Mikko Perttunen wrote:
> On 12.11.2017 13:23, Dmitry Osipenko wrote:
>> On 11.11.2017 00:15, Dmitry Osipenko wrote:
>>> On 07.11.2017 18:29, Dmitry Osipenko wrote:
On 07.11.2017 16:11, Mikko Perttunen wrote:
> On 05.11.2017 19:14, Dmitry Osipenko wrote:
>> On 05.11
Hi Christian,
On Wed, 29 Nov 2017 09:44:44 +0100 Christian Gromm
wrote:
>
> Hmm, am I missing something here? I have it in.
> Here are copies of the patches in question and both have
> a "Signed-off-by" line in.
According to the From: line in the body of these emails, the author of
this patch i
On 29.11.2017 14:18, Dmitry Osipenko wrote:
On 29.11.2017 12:10, Mikko Perttunen wrote:
On 12.11.2017 13:23, Dmitry Osipenko wrote:
On 11.11.2017 00:15, Dmitry Osipenko wrote:
On 07.11.2017 18:29, Dmitry Osipenko wrote:
On 07.11.2017 16:11, Mikko Perttunen wrote:
On 05.11.2017 19:14, Dmitry
On Wed, Nov 29, 2017 at 10:43:07AM +0800, Baoquan He wrote:
> On 11/28/17 at 10:58pm, Jiri Bohac wrote:
> > On Sun, Nov 12, 2017 at 04:04:26PM +0800, Baoquan He wrote:
> > > Solution:
> > > 1) Remove the code which support GART IOMMU when it's not enabled in
> > > BIOS. This has been done in the ne
On Tue, Nov 28, 2017 at 11:28 PM, Willem de Bruijn
wrote:
> On Tue, Nov 28, 2017 at 3:32 PM, Arnd Bergmann wrote:
>> As I noticed in my previous patch to remove the 'timespec' usage in
>> the packet socket, the timestamps in the packet socket are slightly
>> inefficient as they convert a nanoseco
On Nov 23 2017 or thereabouts, Benjamin Tissoires wrote:
> This is something that bothered us from a long time. When hid-input
> doesn't know how to map a usage, it uses *_MISC. But there is something
> else which increments the usage if the evdev code is already used.
>
> This leads to few issues
On Wed, Nov 29, 2017 at 11:33:05AM +0100, Peter Zijlstra wrote:
> @@ -220,7 +215,27 @@ For 32-bit we have the following convent
> .macro SWITCH_TO_USER_CR3 scratch_reg:req
> STATIC_JUMP_IF_FALSE .Lend_\@, kaiser_enabled_key, def=1
> mov %cr3, \scratch_reg
> - ADJUST_USER_CR3 \s
On 11/24/2017 03:16 PM, Thomas Richter wrote:
> This patch fixes a bug introduced with commit d9f8dfa9baf9
> ("perf annotate s390: Implement jump types for perf annotate").
>
> Perf annotate displays annotated assembler output by reading
> output of command objdump and parsing the disassembled li
Hi all,
On Wed, 29 Nov 2017 23:24:46 +1100 Stephen Rothwell
wrote:
>
> On Wed, 29 Nov 2017 09:44:44 +0100 Christian Gromm
> wrote:
> >
> > Hmm, am I missing something here? I have it in.
> > Here are copies of the patches in question and both have
> > a "Signed-off-by" line in.
>
> Accordin
On 29.11.2017 15:25, Mikko Perttunen wrote:
> On 29.11.2017 14:18, Dmitry Osipenko wrote:
>> On 29.11.2017 12:10, Mikko Perttunen wrote:
>>> On 12.11.2017 13:23, Dmitry Osipenko wrote:
On 11.11.2017 00:15, Dmitry Osipenko wrote:
> On 07.11.2017 18:29, Dmitry Osipenko wrote:
>> On 07.11
Some functions from refcount_t API provide different
memory ordering guarantees that their atomic counterparts.
This adds a document outlining these differences.
Signed-off-by: Elena Reshetova
---
Documentation/core-api/index.rst | 1 +
Documentation/core-api/refcount-vs-atomic.rs
On Mon, Nov 20, 2017 at 4:19 PM, Mika Westerberg
wrote:
> When a GPIO is requested using gpiod_get_* APIs the intel pinctrl driver
> switches the pin to GPIO mode and makes sure interrupts are routed to
> the GPIO hardware instead of IOAPIC. However, if the GPIO is used
> directly through irqchip
Changes in v3:
- fixes from Kees incorporated apart from concrete examples
for practical cases.
- document converted to rst and linked under core-api
Changes in v2:
- typos and english are fixed based on Randy Dunlap's
proof reading
- structure of document improved:
* definition
On 11/29/2017 11:28 AM, Thomas Gleixner wrote:
On Wed, 29 Nov 2017, Jarkko Nikula wrote:
On 11/29/2017 09:09 AM, Ingo Molnar wrote:
Hm, that commit looks broken with irq-tracing enabled. Does the
patch below fix it?
No, it makes the machine not to boot at all :-(
Log below when I used my co
On 29.11.2017 13:24, Stephen Rothwell wrote:
Hi Christian,
On Wed, 29 Nov 2017 09:44:44 +0100 Christian Gromm
wrote:
Hmm, am I missing something here? I have it in.
Here are copies of the patches in question and both have
a "Signed-off-by" line in.
According to the From: line in the body o
On 2017/11/29 20:03, Michal Hocko wrote:
> On Wed 29-11-17 17:13:27, zhong jiang wrote:
>> Currently, Arm64 and x86 use the common code wehn parsing numa node
>> in a acpi way. The arm64 will set the parsed node in numa_add_memblk,
>> but the x86 is not set in that , then it will result in the repe
On Mon, Nov 27, 2017 at 2:54 PM, Mika Westerberg
wrote:
> We added acpi_gpiochip_pin_to_gpio_offset() because there was a need to
> translate from ACPI GpioIo/GpioInt number to Linux GPIO number in the
> Cherryview pinctrl driver. This translation is necessary because
> Cherryview has gaps in the
Hi Linus,
please pull this one patch to your tree.
Thanks,
Michal
The following changes since commit 0b07194bb55ed836c2cc7c22e866b87a14681984:
Linux 4.14-rc7 (2017-10-29 13:58:38 -0700)
are available in the git repository at:
git://git.monstr.eu/linux-2.6-microblaze.git tags/microblaze-4.
On Mon, Nov 27, 2017 at 2:54 PM, Mika Westerberg
wrote:
> Currently we always have direct mapping between GPIO numbers and the
> hardware pin numbers. However, there are cases where that's not the case
> anymore (more about this in the next patch). Instead we need to be able
> to specify custom G
On Wed, Nov 29, 2017 at 08:09:51AM +0100, Ingo Molnar wrote:
> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> index f81d50d7ceac..c0b52df8ee4f 100644
> --- a/arch/x86/entry/entry_64.S
> +++ b/arch/x86/entry/entry_64.S
> @@ -945,16 +945,16 @@ idtentry simd_coprocessor_error
On Wed, 29 Nov 2017 12:03:14 +0200
Vladislav Valtchev wrote:
> On Tue, 2017-11-28 at 14:35 -0500, Steven Rostedt wrote:
> >
> > Yes. Simply because we lost the fact that we can do it better.
> >
>
> Hi Steven,
> of course we can do better, if we make a step further than just
> a mechanical r
On Wed, Nov 29, 2017 at 10:45 AM, Lukasz Majewski wrote:
> Dear All,
>
>> This patch series adds support for Liebherr's BK3 board, being
>> a derivative of TS72XX design.
>>
>> This patchset consists of following patches:
>>
>> - ts72xx.[c|h] cosmetic cleanup/improvement
>> - Rewrite ts72xx.c to b
From: Volodymyr Babchuk
These two function will be needed for shared memory registration in OP-TEE
Signed-off-by: Volodymyr Babchuk
---
include/linux/tee_drv.h | 20
1 file changed, 20 insertions(+)
diff --git a/include/linux/tee_drv.h b/include/linux/tee_drv.h
index 70b9
From: Volodymyr Babchuk
This change adds ops for shm_(un)register functions in tee interface.
Client application can use these functions to (un)register an own shared
buffer in OP-TEE address space. This allows zero copy data sharing between
Normal and Secure Worlds.
Please note that while those
From: Volodymyr Babchuk
In order to register a shared buffer in TEE, we need accessor
function that return list of pages for that buffer.
Signed-off-by: Volodymyr Babchuk
---
include/linux/tee_drv.h | 13 +
1 file changed, 13 insertions(+)
diff --git a/include/linux/tee_drv.h b/in
On Mon, Nov 27, 2017 at 2:54 PM, Mika Westerberg
wrote:
> It turns out that the Cannon Lake GPIO driver in Windows uses different
> GPIO numbering scheme than what Linux uses. Instead of hardware numbers it
> has "banks" of 32 pins even if the hardware group actually does not have
> that many pin
From: Volodymyr Babchuk
Now, when client applications can register own shared buffers in OP-TEE,
we need to extend ABI for parameter passing to/from OP-TEE.
So, if OP-TEE core detects that parameter belongs to registered shared
memory, it will use corresponding parameter attribute.
Signed-off-b
From: Volodymyr Babchuk
Previous patches added various features that are needed for dynamic SHM.
Dynamic SHM allows Normal World to share any buffers with OP-TEE.
While original design suggested to use pre-allocated region (usually of
1M to 2M of size), this new approach allows to use all non-sec
From: Volodymyr Babchuk
There were changes in REE<->OP-TEE ABI recently.
Now ABI allows us to pass non-contiguous memory buffers as list of
pages to OP-TEE. This can be achieved by using new parameter attribute
OPTEE_MSG_ATTR_NONCONTIG.
OP-TEE also is able to use all non-secure RAM for shared bu
From: Volodymyr Babchuk
Those capabilities will be used in subsequent patches.
Signed-off-by: Volodymyr Babchuk
---
drivers/tee/optee/core.c | 1 +
drivers/tee/optee/optee_private.h | 3 +++
2 files changed, 4 insertions(+)
diff --git a/drivers/tee/optee/core.c b/drivers/tee/optee/co
From: Volodymyr Babchuk
We need to ensure that tee_context is present until last
shared buffer will be freed.
Signed-off-by: Volodymyr Babchuk
---
drivers/tee/tee_core.c| 40 +++-
drivers/tee/tee_private.h | 3 +++
drivers/tee/tee_shm.c | 7 +++
From: Volodymyr Babchuk
Now, when struct tee_shm is defined in public header,
we can inline small getter functions like this one.
Signed-off-by: Volodymyr Babchuk
---
drivers/tee/tee_shm.c | 11 ---
include/linux/tee_drv.h | 5 -
2 files changed, 4 insertions(+), 12 deletions(-)
From: Volodymyr Babchuk
This is simple pool that uses kernel page allocator. This pool can be
used in case OP-TEE supports dynamic shared memory.
Signed-off-by: Volodymyr Babchuk
---
drivers/tee/optee/Makefile | 1 +
drivers/tee/optee/shm_pool.c | 75
From: Volodymyr Babchuk
With latest changes to OP-TEE we can use any buffers as a shared memory.
Thus, it is possible for supplicant to provide part of own memory
when OP-TEE asks to allocate a shared buffer.
This patch adds support for such feature into RPC handling code.
Now when OP-TEE asks s
On Mon, Oct 30, 2017 at 4:46 PM, SF Markus Elfring
wrote:
> From: Markus Elfring
> Date: Mon, 30 Oct 2017 16:03:12 +0100
>
> * Add a jump target so that a call of the function "mutex_unlock" is stored
> only twice in this function implementation.
>
> * Replace five calls by goto statements.
>
From: Volodymyr Babchuk
These functions will be used to pass information about shared
buffers to OP-TEE. ABI between Linux and OP-TEE is defined
in optee_msg.h and optee_smc.h.
optee_msg.h defines OPTEE_MSG_ATTR_NONCONTIG attribute
for shared memory references and describes how such references
s
From: Jens Wiklander
Makes creation of shm pools more flexible by adding new more primitive
functions to allocate a shm pool. This makes it easier to add driver
specific shm pool management.
Signed-off-by: Jens Wiklander
Signed-off-by: Volodymyr Babchuk
---
drivers/tee/tee_private.h | 57 +-
From: Jens Wiklander
Added new ioctl to allow users register own buffers as a shared memory.
Signed-off-by: Jens Wiklander
Signed-off-by: Volodymyr Babchuk
---
drivers/tee/tee_core.c | 41 +-
drivers/tee/tee_shm.c| 205 +--
include/li
From: Volodymyr Babchuk
Hello all,
This is resend of OP-TEE dynamic SHM series. No changes
from last time. Correct version is used in the subject.
---
Changes from v1:
* Added support for 16K and 64K pages. Elaborated commit messages
* More minor changes are described in corresponding patch
On 11/29/2017 12:34 AM, Andrew Morton wrote:
> On Wed, 22 Nov 2017 15:52:55 +0100 Vlastimil Babka wrote:
>
>>
>> Thanks a lot, that's very encouraging!
>
> Yup.
>
> Should we proceed with this patch for now, or wait for something better
> to come along?
I'm working on the refined version, so w
Hi,
On 28-11-17 17:15, Larry Finger wrote:
On 11/28/2017 04:01 AM, Hans de Goede wrote:
Hi,
I did have two problems when I tried to build these commits and the one that
creates vboxsf.
The more serious one is that it is possible to build vboxguest without vboxvideo.
When that happens, a
On Mon, Oct 30, 2017 at 4:47 PM, SF Markus Elfring
wrote:
> + if (t)
> + goto report_failure;
>
> for (t = 0, mask = BIT(0); t < chip->ngpio; t++, mask <<= 1) {
> const char *label;
> @@ -758,8 +753,13 @@ static void mcp23s08_dbg_show(struct seq_file *s
On Mon, Oct 30, 2017 at 4:49 PM, SF Markus Elfring
wrote:
> From: Markus Elfring
> Date: Mon, 30 Oct 2017 16:34:44 +0100
>
> * Print a line break together with other data in a single function call.
>
> * Adjust indentation.
>
> Signed-off-by: Markus Elfring
This does not apply.
Possibly depend
On Thu, 23 Nov 2017 14:32:32 +0200
Vladislav Valtchev wrote:
> Agree.
> We might also add an if (!isdigit(buf)) die() before return, but I understand
> that, on the other side, we might not need to check the kernel's behavior
> this way. We might ultimately trust the kernel [every part of it] and
201 - 300 of 1346 matches
Mail list logo
