On Sun, Jun 26, 2016 at 05:19:54PM +0200, Michal Suchanek wrote:
> On 26 June 2016 at 14:57, Mark Brown wrote:
> > That would be a binding for the connector which is the big missing bit
> > here - it's not clear that such a limited connector description would be
> > a good idea.
> It would work
On Sun, Jun 26, 2016 at 10:13:32AM -0700, Linus Torvalds wrote:
> On Sun, Jun 26, 2016 at 2:50 AM, Thorsten Leemhuis
> wrote:
> >
> > Al, what's the status here? This made it on my 4.7 regressions report
> > due to the "regression" keyword in the subject.
>
> I don't think the tmpfs locking is go
On 22/06/16 06:40, Srinivas Pandruvada wrote:
> Document explaining ISH HID operation and implementation.
>
> Signed-off-by: Srinivas Pandruvada
A few really trivial point inline. I unfortunately don't have the time to
dive into this in sufficient depth to grasp every detail, but the
description
On Mon, Jun 20, 2016 at 03:40:27PM +0100, Colin King wrote:
> From: Colin Ian King
>
> An ENOMEM when creating a pair tty in tty_ldisc_setup causes a null
> pointer dereference in devpts_kill_index because tty->link->driver_data
> is NULL. The oops was triggered with the pty stressor in stress-n
On Sun, May 29, 2016 at 01:52:44PM -0400, Sasha Levin wrote:
> Hi all,
>
> I've hit the following while fuzzing with syzkaller inside a KVM tools guest
> running the latest -next kernel:
>
> [ 2662.777566] BUG: KASAN: global-out-of-bounds in
> do_compute_shiftstate+0x161/0x370 at addr b2
Hi!
> Yes, I understand the argument that the networking stack is now
> requiring the crypto layer --- but not all IOT devices may necessarily
> require the IP stack (they might be using some alternate wireless
> communications stack) and I'd much rather not make things worse.
>
>
> The final th
On Mon 2016-06-13 11:48:39, Theodore Ts'o wrote:
> Signed-off-by: Theodore Ts'o
> ---
> drivers/char/random.c | 54
> ++-
> 1 file changed, 49 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/char/random.c b/drivers/char/random.c
> index d64
On Sun, Jun 26, 2016 at 05:10:06PM +0200, Ondřej Jirman wrote:
> Hello, I assume that means "regulator: dt-bindings: ..." in this case.
> I'll keep that in mind in the future. Thank you.
Yes, or "regulator: sy8106a: " - as ever take a look at how other
commits in the same file/directory are done.
On Thu, Jun 23, 2016 at 05:41:20PM -, Michal Suchanek wrote:
> This allows binding spidev on any slave device by hand using sysfs
> without adding superfluous compatibles or any other needless
> complication.
>
> Note that any slave driver that requires configuration will fail to
> probe anywa
Hi!
> > FWIW, testing with ltp, I noticed a new failure in logs. It turns out
> > to be intermittent, but the testcase mostly fails.
>
> You forgot to cc the LTP folks ...
>
> > rtbox:~ #
> > /usr/local/ltp/conformance/interfaces/sigtimedwait/sigtimedwait_1-1.run-test
> > Test FAILED: sigtim
On 06/24/16 17:21, Eric W. Biederman wrote:
> "Serge E. Hallyn" writes:
>
>> Quoting Tejun Heo (t...@kernel.org):
>>> Hello,
>>>
>>> On Fri, Jun 24, 2016 at 10:59:16AM -0500, Serge E. Hallyn wrote:
Quoting Tejun Heo (t...@kernel.org):
> But isn't being recursive orthogonal to using cgrou
On 26 June 2016 at 20:28, Greg Kroah-Hartman wrote:
> On Thu, Jun 23, 2016 at 05:41:20PM -, Michal Suchanek wrote:
>> This allows binding spidev on any slave device by hand using sysfs
>> without adding superfluous compatibles or any other needless
>> complication.
>>
>> Note that any slave dr
Am Sonntag, 26. Juni 2016, 20:47:43 schrieb Pavel Machek:
Hi Pavel,
> Hi!
>
> > Yes, I understand the argument that the networking stack is now
> > requiring the crypto layer --- but not all IOT devices may necessarily
> > require the IP stack (they might be using some alternate wireless
> > com
On 06/24/16 17:24, Tejun Heo wrote:
> Hello, Serge.
>
> On Fri, Jun 24, 2016 at 11:59:10AM -0500, Serge E. Hallyn wrote:
>>> Just monitoring is less jarring than implementing security enforcement
>>> via cgroup, but it is still jarring. What's wrong with recursive
>>> process hierarchy monitoring
On Sun, Jun 26, 2016 at 12:00 PM, Pavel Machek wrote:
>
> Umm. I'm not sure if you should be designing kernel...
>
> I have alarm clock application. It does sleep(60) many times till its
> time to wake me up. I'll be very angry if sleep(60) takes 65 seconds
> without some very, very good reason.
RT_TRACE does not add a newline to the end of a message and always
emits at KERN_DEBUG so these are susceptible to message interleaving
from other processes without the newline.
Signed-off-by: Joe Perches
---
drivers/net/wireless/realtek/rtlwifi/core.c| 2 +-
drivers/net/wireles
On Tue, Jun 14, 2016 at 09:58:53PM +0200, Christoph Hellwig wrote:
> This series enhances the irq and PCI code to allow spreading around MSI and
> MSI-X vectors so that they have per-cpu affinity if possible, or at least
> per-node. For that it takes the algorithm from blk-mq, moves it to
> a comm
(adding back Cc:, just dropped it to send the logs)
On Mon, Jun 27, 2016 at 01:35:14AM +0900, Tetsuo Handa wrote:
>
> It seems to me that GFP_NOIO allocation requests are depleting memory reserves
> because they are passing ALLOC_NO_WATERMARKS to get_page_from_freelist().
> But I'm not familiar w
From: Chanho Min
Date: Wed, 22 Jun 2016 19:08:13 +0900
> To fix this, I suggested patch that checks if device is available
> before the DHCP packet is sended.
The bug is more fundamental than this.
The code is not taking a reference to the netdevice, and that's
the only reason it is able to dis
From: Xing Zheng
Date: Tue, 21 Jun 2016 20:33:28 +0800
> Add constants and callback functions for the dwmac on rk3228/rk3229 socs.
> As can be seen, the base structure is the same, only registers and the
> bits in them moved slightly.
>
> Signed-off-by: Xing Zheng
Applied, thanks.
Hi!
On Sun 2016-06-26 12:21:46, Arjan van de Ven wrote:
> On Sun, Jun 26, 2016 at 12:00 PM, Pavel Machek wrote:
> >
> > Umm. I'm not sure if you should be designing kernel...
> >
> > I have alarm clock application. It does sleep(60) many times till its
> > time to wake me up. I'll be very angry i
From: David Howells
Date: Wed, 22 Jun 2016 17:06:19 +0100
> David Howells wrote:
>
>> The patches can be found here also:
>>
>>
>> http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-rewrite
>>
>> Tagged thusly:
>>
>> git://git.kernel.org/pub/scm/linux/k
Hello,
This series introduces the necessary device tree binding to
perform DT boot.
Tested with MAX11644 (DT boot).
Best regards,
Florian
---
Since v1:
- First patch applied by Jonathan
- Added DT maintainer's Ack
- Fixed handling of data pointer in struct of_device_id
Florian Vaussard (2):
This patch adds the necessary device tree binding to allow DT probing of
currently supported parts.
Signed-off-by: Florian Vaussard
---
drivers/iio/adc/max1363.c | 169 +-
1 file changed, 168 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/adc/m
Add the device tree documentation for all the supported parts. Mandatory
binding is the compatible string and the slave I2C address.
Optional properties can be used to specify the Vcc / Vref regulators, as
well as the IRQ line if available.
Acked-by: Rob Herring
Signed-off-by: Florian Vaussard
Hello,
while testing overlay loading I found some issues with applying the overlay.
I sent these like a year ago already. One was since fixed but two still apply.
Thanks
Michal
Michal Suchanek (2):
of: overlay: add resolver error prints
of: fdt: mark unflattened tree as detached
drivers/
The tree returned from of_fdt_unflatten_tree cannot be attached to the
live tree because it is not marked as detached so mark it as such. The
dt resolver checks the flag and refuses to process the tree otherwise.
Signed-off-by: Michal Suchanek
---
drivers/of/fdt.c | 12 +---
1 file chang
Applying overlay fails silently in case of an error. Add error prints.
Most notably the lack of symbols in the live tree is not reported.
Signed-off-by: Michal Suchanek
---
drivers/of/resolver.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/of/resolver.c b/drivers/of/resolver
This patch adds support for MCP454x, MCP456x, MCP464x and MCP466x parts.
The main difference with currently supported parts (MCP453x and alike) is
the addition of a non-volatile memory in order to recall the wiper setting
at power-on. This feature is currently not supported and only the
volatile me
Add the device tree documentation for all the supported parts. Apart the
compatible string and standard I2C binding, no other binding is currently
needed.
Signed-off-by: Florian Vaussard
---
.../devicetree/bindings/i2c/trivial-devices.txt| 64 ++
1 file changed, 64 insert
Hello,
This series first adds support for parts missing from mcp4531 driver
(MCP454x, MCP456x, MCP464x and MCP466x). It then introduces the necessary
device tree binding to perform DT boot. Finally it fixes a typo in the
Kconfig.
Tested with MCP4561-103 and MCP4561-503 (DT boot).
Best regards,
F
This patch adds the necessary device tree binding to allow DT probing of
currently supported parts.
Signed-off-by: Florian Vaussard
---
drivers/iio/potentiometer/mcp4531.c | 273 +++-
1 file changed, 272 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/poten
Fix s/potentiomenter/potentiometer/.
Suggested-by: Peter Meerwald-Stadler
Signed-off-by: Florian Vaussard
---
drivers/iio/potentiometer/Kconfig | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/potentiometer/Kconfig
b/drivers/iio/potentiometer/Kconfig
index
On Sun, 2016-06-26 at 11:52 +0800, kbuild test robot wrote:
> Hi,
>
> [auto build test ERROR on robh/for-next]
> [also build test ERROR on v4.7-rc4 next-20160624]
> [if your patch is applied to the wrong git tree, please drop us a
> note to help improve the system]
>
> url:https://github.com/
On Sun, Jun 26, 2016 at 11:20:52AM +, He Kuang wrote:
> This patchset is based on Wang Nan's v1:
> http://thread.gmane.org/gmane.linux.kernel/2203717/focus=2203707
>
> """
> This patch set allows to perf invoke some user space BPF scripts on
> some point. uBPF scripts and kernel BPF
On 26 June 2016 at 06:20, He Kuang wrote:
> From: Wang Nan
>
> This patch copies "include/linux/math64.h" into
> "tools/include/linux/math64.h" and copies
> "include/asm-generic/div64.h" into
> "tools/include/asm-generic/div64.h", to enable other libraries use
> arithmetic operation defined in th
We were getting build warning:
arch/m32r/boot/compressed/m32r_sio.c:11:13:
warning: conflicting types for built-in function 'putc'
Here putc is used as a static function so lets just rename it to avoid
the conflict with the builtin putc.
Signed-off-by: Sudip Mukherjee
---
build log is a
On Sun, Jun 26, 2016 at 11:06 AM, Al Viro wrote:
>
> FWIW, #work.dcache_readdir in vfs.git seems to recover the performance.
> Not sure if it's worth pushing right now, but if it ends up the next
> cycle stuff, I think it'll be worth Cc:stable.
Hmm. I guess that if you're confident enough about i
Previous version was probably written referencing the man page for
glibc's wrapper, but the wrapper's behavior differs from that of the
syscall itself in this case.
Signed-off-by: Zev Weiss
---
kernel/sched/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/sched
Saudações,
Eu sou a senhora Annie Ethan de uma empresa de crédito privado
conhecido como Aspire dinheiro Loan®. Oferecemos todos os tipos de empréstimo a
taxa de juro de 3%. Se você está na necessidade de empréstimo favor
contacte-nos com as informações abaixo.
Nome completo:
Gênero:
P
We were getting build warning:
arch/m32r/boot/compressed/m32r_sio.c:11:13:
warning: conflicting types for built-in function 'putc'
Here putc is used as a static function so lets just rename it to avoid
the conflict with the builtin putc.
Signed-off-by: Sudip Mukherjee
---
v1: was having
Hi!
> From: Gustavo Padovan
>
> Hi Greg,
>
> This is the last step in the Sync Framwork de-stage task. It
Typo: "fram_e_work"
> de-stage
> the SW_SYNC validation framework and the sync_debug info debugfs file.
>
> The first 3 patches are clean up and improvements and the rest is preparation
Hi!
> >+struct ncp5623_led {
> >+bool active;
> >+unsigned int led_no;
> >+struct led_classdev ldev;
> >+struct work_struct work;
> >+struct ncp5623_priv *priv;
> >+};
> >+
> >+struct ncp5623_priv {
> >+struct ncp5623_led leds[NCP5623_MAX_LEDS];
>
> Please allocate memory
Hi all-
Since the dawn of time, a kernel stack overflow has been a real PITA
to debug, has caused nondeterministic crashes some time after the
actual overflow, and has generally been easy to exploit for root.
With this series, arches can enable HAVE_ARCH_VMAP_STACK. Arches
that enable it (just x
Currently, NR_KERNEL_STACK tracks the number of kernel stacks in a
zone. This only makes sense if each kernel stack exists entirely in
one zone, and allowing vmapped stacks could break this assumption.
Since frv has THREAD_SIZE < PAGE_SIZE, we need to track kernel stack
allocations in a unit that
It's not going to work, because the scheduler will explode if we try
to schedule when running on an IST stack or similar.
This will matter when we let kernel stack overflows (which are #DF)
call die().
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/dumpstack.c | 3 +++
1 file changed, 3 ins
If we overflow the stack, print_context_stack will abort. Detect
this case and rewind back into the valid part of the stack so that
we can trace it.
Reviewed-by: Josh Poimboeuf
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/dumpstack.c | 10 +-
1 file changed, 9 insertions(+), 1 de
From: Linus Torvalds
It was a nice optimization while it lasted, but thread_info is moving
and this optimization will no longer work.
Quoting Linus:
Oh Gods, Andy. That pt_regs_to_thread_info() thing made me want
to do unspeakable acts on a poor innocent wax figure that looked
_exac
If we call do_exit with a clean stack, we greatly reduce the risk of
recursive oopses due to stack overflow in do_exit, and we allow
do_exit to work even if we OOPS from an IST stack. The latter gives
us a much better chance of surviving long enough after we detect a
stack overflow to write out ou
The comment suggests that show_stack(NULL, NULL) should backtrace
the current context, but the code doesn't match the comment. If
regs are given, start the "Stack:" hexdump at regs->sp.
Reviewed-by: Josh Poimboeuf
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/dumpstack_32.c | 4 +++-
arch
If we overflow the stack into a guard page, we'll recursively fault
when trying to dump the contents of the guard page. Use
probe_kernel_address so we can recover if this happens.
Reviewed-by: Josh Poimboeuf
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/dumpstack_64.c | 12 ++--
1
If we're using CONFIG_VMAP_STACK and we manage to point an sg entry
at the stack, then either the sg page will be in highmem or sg_virt
will return the direct-map alias. In neither case will the existing
check_for_stack() implementation realize that it's a stack page.
Fix it by explicitly checkin
If CONFIG_VMAP_STACK is selected, kernel stacks are allocated with
vmalloc_node.
grsecurity has had a similar feature (called
GRKERNSEC_KSTACKOVERFLOW) for a long time.
Cc: Oleg Nesterov
Signed-off-by: Andy Lutomirski
---
arch/Kconfig| 29 +
arch/ia64/includ
vmalloc is a bit slow, and pounding vmalloc/vfree will eventually
force a global TLB flush.
To reduce pressure on them, if CONFIG_VMAP_STACK, cache two thread
stacks per cpu. This will let us quickly allocate a hopefully
cache-hot, TLB-hot stack under heavy forking workloads (shell script
style).
We currently keep every task's stack around until the task_struct
itself is freed. This means that we keep the stack allocation alive
for longer than necessary and that, under load, we free stacks in
big batches whenever RCU drops the last task reference. Neither of
these is good for reuse of cac
We should account for stacks regardless of stack size, and we need
to account in sub-page units if THREAD_SIZE < PAGE_SIZE. Change the
units to kilobytes and Move it into account_kernel_stack().
Fixes: 12580e4b54ba8 ("mm: memcontrol: report kernel stack usage in cgroup2
memory.stat")
Cc: Vladimi
Now that most of the thread_info users have been cleaned up,
this is straightforward.
Most of this code was written by Linus.
Signed-off-by: Andy Lutomirski
---
arch/x86/Kconfig | 1 +
arch/x86/entry/entry_64.S | 9 +---
arch/x86/include/asm/switch_to.h | 6 +
kernel_unmap_pages_in_pgd() is dangerous: if a pgd entry in
init_mm.pgd were to be cleared, callers would need to ensure that
the pgd entry hadn't been propagated to any other pgd.
Its only caller was efi_cleanup_page_tables(), and that, in turn,
was unused, so just delete both functions. This le
This avoids pointless races in which another CPU or task might see a
partially populated global pgd entry. These races should normally
be harmless, but, if another CPU propagates the entry via
vmalloc_fault and then populate_pgd fails (due to memory allocation
failure, for example), this prevents
We'll need this cleanup to make the cpu field in thread_info be
optional.
Cc: Jason Wessel
Signed-off-by: Andy Lutomirski
---
include/linux/kdb.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/kdb.h b/include/linux/kdb.h
index a19bcf9e762e..410decacff8f 100644
From: Linus Torvalds
thread_info may move in the future, so use the accessors.
[changelog written by Andy]
Message-Id:
Signed-off-by: Andy Lutomirski
---
arch/x86/um/ptrace_32.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/um/ptrace_32.c b/arch/x86/um/p
If an arch opts in by setting CONFIG_THREAD_INFO_IN_TASK_STRUCT,
then thread_info is defined as a single 'u32 flags' and is the first
entry of task_struct. thread_info::task is removed (it serves no
purpose if thread_info is embedded in task_struct), and
thread_info::cpu gets its own slot in task_
thread_info is a legacy mess. To prepare for its partial removal,
move addr_limit out.
As an added benefit, this way is simpler.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/checksum_32.h | 3 +--
arch/x86/include/asm/processor.h | 17 ++---
arch/x86/include/asm/threa
On Thu, 23 Jun 2016, Andrew F. Davis wrote:
> Add a script to check for unneeded conversions to bool.
>
> Signed-off-by: Andrew F. Davis
Acked-by: Julia Lawall
> ---
> scripts/coccinelle/misc/boolconv.cocci | 90
> ++
> 1 file changed, 90 insertions(+)
>
It's statically initialized to zero -- no need to dynamically
initialize it to zero as well.
Signed-off-by: Andy Lutomirski
---
arch/x86/kernel/smpboot.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index fafe8b923cac..0e91dbeca2fd 1006
Becuase sched.h and thread_info.h are a tangled mess, I turned
in_compat_syscall into a macro. If we had current_thread_struct()
or similar and we could use it from thread_info.h, then this would
be a bit cleaner.
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/common.c| 4 ++--
In general, there's no need for the "restore sigmask" flag to live in
ti->flags. alpha, ia64, microblaze, powerpc, sh, sparc (64-bit only),
tile, and x86 use essentially identical alternative implementations,
placing the flag in ti->status.
Replace those optimized implementations with an equally
From: Ingo Molnar
So when memory hotplug removes a piece of physical memory from pagetable
mappings, it also frees the underlying PGD entry.
This complicates PGD management, so don't do this. We can keep the
PGD mapped and the PUD table all clear - it's only a single 4K page
per 512 GB of memory
From: Herbert Xu
rxkad uses stack memory in SG lists which would not work if stacks
were allocated from vmalloc memory. In fact, in most cases this
isn't even necessary as the stack memory ends up getting copied
over to kmalloc memory.
This patch eliminates all the unnecessary stack memory uses
It serves no purpose -- raw_smp_processor_id() works fine. This
change will be needed to move thread_info off the stack.
Signed-off-by: Andy Lutomirski
---
arch/x86/include/asm/cpu.h | 1 -
arch/x86/include/asm/smp.h | 6 --
arch/x86/kernel/cpu/common.c | 2 +-
3 files changed, 1 insert
ds17287rtc.h is unused since commit 15beb694c661 ("mips: ip32: add
platform data hooks to use DS1685 driver"), remove it.
Signed-off-by: Alexandre Belloni
---
include/linux/ds17287rtc.h | 66 --
1 file changed, 66 deletions(-)
delete mode 100644 inclu
SMP does ECB crypto on stack buffers. This is complicated and
fragile, and it will not work if the stack is virtually allocated.
Switch to the crypto_cipher interface, which is simpler and safer.
Cc: Marcel Holtmann
Cc: Gustavo Padovan
Cc: Johan Hedberg
Cc: "David S. Miller"
Cc: linux-blueto
thread_info is a legacy mess. To prepare for its partial removal,
move the uaccess control fields out -- they're straightforward.
Signed-off-by: Andy Lutomirski
---
arch/x86/entry/vsyscall/vsyscall_64.c | 6 +++---
arch/x86/include/asm/processor.h | 3 +++
arch/x86/include/asm/thread_info.
rtc-ds2404.h belongs to include/linux/platform_data/
Signed-off-by: Alexandre Belloni
---
drivers/rtc/rtc-ds2404.c | 2 +-
include/linux/{ => platform_data}/rtc-ds2404.h | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename include/linux/{ => platform_data}/rtc-ds2404
rtc-v3020.h belongs to include/linux/platform_data/
Signed-off-by: Alexandre Belloni
---
Cc: Daniel Mack
Cc: Haojian Zhuang
Cc: Robert Jarzmik
Cc: linux-arm-ker...@lists.infradead.org
arch/arm/mach-pxa/cm-x270.c | 2 +-
arch/arm/mach-pxa/cm-x300.c | 2 +-
a
m48t86.h belongs to include/linux/platform_data/
Signed-off-by: Alexandre Belloni
---
Cc: Hartley Sweeten
Cc: Ryan Mallon
Cc: Alexander Clouter
Cc: Jason Cooper
Cc: Andrew Lunn
Cc: Sebastian Hesselbarth
Cc: Gregory Clement
Cc: linux-arm-ker...@lists.infradead.org
arch/arm/mach-ep93xx/ts7
If we get a page fault indicating kernel stack overflow, invoke
handle_stack_overflow(). To prevent us from overflowing the stack
again while handling the overflow (because we are likely to have
very little stack space left), call handle_stack_overflow() on the
double-fault stack
Signed-off-by: A
Move ds1286.h to rtc specific folder.
Signed-off-by: Alexandre Belloni
---
Cc: Ralf Baechle
Cc: linux-m...@linux-mips.org
arch/mips/sgi-ip22/ip22-reset.c | 2 +-
drivers/rtc/rtc-ds1286.c | 2 +-
include/linux/{ => rtc}/ds1286.h | 0
3 files changed, 2 insertions(+), 2 deletions(-)
ren
This allows x86_64 kernels to enable vmapped stacks. There are a
couple of interesting bits.
First, x86 lazily faults in top-level paging entries for the vmalloc
area. This won't work if we get a page fault while trying to access
the stack: the CPU will promote it to a double-fault and we'll die
On 2016-06-26 22:22, Florian Vaussard wrote:
> Add the device tree documentation for all the supported parts. Apart the
> compatible string and standard I2C binding, no other binding is currently
> needed.
>
> Signed-off-by: Florian Vaussard
> ---
> .../devicetree/bindings/i2c/trivial-devices.tx
Hi Florian,
On 2016-06-26 22:22, Florian Vaussard wrote:
> This patch adds the necessary device tree binding to allow DT probing of
> currently supported parts.
>
> Signed-off-by: Florian Vaussard
> ---
> drivers/iio/potentiometer/mcp4531.c | 273
> +++-
> 1 fil
Am Dienstag, 21. Juni 2016, 17:31:16 schrieb Doug Anderson:
> OK, so what do we do? Personally I can't see us coming up with a
> one-size fits all approach, can you? That means some type of
> configuration. ...and, as seen by the assigned-clocks device tree
> binding, _some_ types of configurati
Hello, Topi.
On Sun, Jun 26, 2016 at 3:14 PM, Topi Miettinen wrote:
> The parent might be able do it if proc/pid/xyz files are still
> accessible after child exit but before its exit status is collected. But
> if the parent doesn't do it (and you are not able to change it to do it)
> and it colle
On Wed 2016-06-22 16:24:41, Torsten Duwe wrote:
> Live patching, as we use it, deliberately disrupts the fabric of
> compile units; thus all assumptions a compiler can make about the
> control flow may be invalid. As an example, it could analyse that a
> callee does not touch a caller-saved registe
On Thu 2016-06-23 14:47:03, Jiri Kosina wrote:
> On Thu, 23 Jun 2016, Jiri Kosina wrote:
>
> > > I haven't looked at the fentry solution, but the code I'm involved in
> > > saves
> > > the registers so that ftrace, live patch and friends can work freely. But
> > > then it restores all regs and _t
On Sun, Jun 26, 2016 at 08:47:43PM +0200, Pavel Machek wrote:
> Ok, so lets say I'm writing some TLS server, and I know that traffic
> is currently heavy because it was heavy in last 5 minutes. Would it
> make sense for me to request 128M of randomness from /dev/urandom, and
> then use that interna
From: Anton Blanchard
Many targets enable CONFIG_DEBUG_STACK_USAGE, and while the information
is useful, it isn't worthy of pr_warn(). Reduce it to pr_info().
Signed-off-by: Anton Blanchard
---
kernel/exit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/exit.c b/ke
From: Anton Blanchard
commit 612e44939c3c ("mm: workingset: eviction buckets for bigmem/lowbit
machines") added a printk without a log level. Quieten it by using
pr_info().
Signed-off-by: Anton Blanchard
---
mm/workingset.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm
On Sun, Jun 26, 2016 at 08:47:53PM +0200, Pavel Machek wrote:
>
> You are basically trying to turn CRNG into one way hash function here,
> right? Do you have any explanation that it has the required
> properties?
Well, not really. A CRNG has the property that if you generate a
series of outputs:
Am Dienstag, 14. Juni 2016, 13:21:11 schrieb Douglas Anderson:
> There are two sleep related pins on rk3399: ap_pwroff and ddrio_pwroff.
> Let's add the definition of these two pins to rk3399's main dtsi file so
> that boards can use them.
>
> These two pins are similar to the global_pwroff and dd
While backporting nfit_test to distro kernels a conflict between CMA and
SWIOTLB was discovered. CMA requirements have also been a stumbling
point for others trying to execute the tests.
---
Dan Williams (2):
libnvdimm, pmem: allow nfit_test to override pmem_direct_access()
tools/test
Currently phys_to_pfn_t() is an exported symbol to allow nfit_test to
override it and indicate that nfit_test-pmem is not device-mapped. Now,
we want to enable nfit_test to operate without DMA_CMA and the pmem it
provides will no longer be physically contiguous, i.e. won't be capable
of supporting
DMA_CMA is incompatible with SWIOTLB used in enterprise distro
configurations. Switch to vmalloc() allocations for all resources.
Signed-off-by: Dan Williams
---
tools/testing/nvdimm/Kbuild |2 ++
tools/testing/nvdimm/pmem-dax.c | 22 +
tools/testing/nvdimm/test/io
On Mon, Jun 20, 2016 at 01:15:03PM -0600, Logan Gunthorpe wrote:
> Sorry, I thought this was done but I found one more minor issue with
> these patches so I'm resubmitting them one last time. Besides this isuse,
> I think I have acks for all the patches and everything is working as I'd
> like.
App
Hi Jarkko,
I noticed that a large number of the patches in the tpmdd tree appear
twice (and some three times). They appear to have been rebased on top
of the security tree before being remerged. Please clean this all up.
--
Cheers,
Stephen Rothwell
On Sun, Jun 26, 2016 at 5:55 PM, Andy Lutomirski wrote:
> From: Linus Torvalds
>
> thread_info may move in the future, so use the accessors.
>
> [changelog written by Andy]
> Message-Id:
>
> Signed-off-by: Andy Lutomirski
> ---
> arch/x86/um/ptrace_32.c | 8
> 1 file changed, 4 inser
Hello,
On Sun, Jun 26, 2016 at 09:34:41PM +1000, Aleksa Sarai wrote:
> If a user has a setup where they wait for notifications on changes to
> pids.event, and then auto-adjust the cgroup limits based on the number of
> failures you have a race condition between reading the pids.event file and
> th
On Sun, Jun 26, 2016 at 4:40 PM, Brian Gerst wrote:
> On Sun, Jun 26, 2016 at 5:55 PM, Andy Lutomirski wrote:
>> From: Linus Torvalds
>>
>> thread_info may move in the future, so use the accessors.
>>
>> [changelog written by Andy]
>> Message-Id:
>>
>> Signed-off-by: Andy Lutomirski
>> ---
>>
On Sun, Jun 26, 2016 at 5:55 PM, Andy Lutomirski wrote:
> Becuase sched.h and thread_info.h are a tangled mess, I turned
> in_compat_syscall into a macro. If we had current_thread_struct()
> or similar and we could use it from thread_info.h, then this would
> be a bit cleaner.
>
> Signed-off-by:
Hi Rob
Thank you for your review
> > +Each ports / port / endpoint can have its type if needed.
>
> I think type should only apply to a port. ports is only a grouping for
> multiple ports. endpoints are just the connection. A port is a single
> data flow, so 2 endpoints on a port reflect 2 poss
201 - 300 of 424 matches
Mail list logo
