These clocks are fixed rate board sources that should be in DT.
Add them.
Cc: Georgi Djakov
Signed-off-by: Stephen Boyd
---
It seems that I never sent out the updated version of this patch
to cover all the SoCs we have. This is on top of linux-next.
arch/arm/boot/dts/qcom-apq8084.dtsi | 14
> "Mike" == mchristi writes:
Mike> The following patches begin to cleanup the request->cmd_flags and
bio-> bi_rw mess. We currently use cmd_flags to specify the operation,
Mike> attributes and state of the request. For bi_rw we use it for
Mike> similar info and also the priority but then
of_irq_count() is not an exported symbol (and it shouldn't be
used by platform drivers anyway) so use platform_irq_count()
instead. This allows us to make the qcom pinctrl drivers modular
again.
Cc: Rob Herring
Cc: Andy Gross
Cc: Bjorn Andersson
Signed-off-by: Stephen Boyd
---
Changes from
Hi,
On 01/05/2016 07:25 PM, Rameshwar Sahu wrote:
> Hi Ulf,
>
> On Wed, Dec 23, 2015 at 6:59 PM, Rameshswar Prasad Sahu wrote:
>> From: Rameshwar Prasad Sahu
>>
>> The Arason SD host controller supports set block count command (cmd23)
>> and high speed mode. This patch re-enable both of these
On Mon, Jan 04, 2016 at 12:34:44PM +, Harvey Hunt wrote:
> diff --git a/arch/mips/boot/dts/ingenic/ci20.dts
> b/arch/mips/boot/dts/ingenic/ci20.dts
> index 9fcb9e7..782258c 100644
> --- a/arch/mips/boot/dts/ingenic/ci20.dts
> +++ b/arch/mips/boot/dts/ingenic/ci20.dts
As I noted on patch 1,
On 01/06/16 17:19, Bjorn Andersson wrote:
> On Wed, Jan 6, 2016 at 5:12 PM, Stephen Boyd wrote:
>> of_irq_count() is not an exported symbol (and it shouldn't be
>> used by platform drivers anyway) so use platform_irq_count()
>> instead. This allows us to make the qcom pinctrl drivers modular
>>
On Mon, Jan 04, 2016 at 12:34:42PM +, Harvey Hunt wrote:
> From: Alex Smith
>
> Add DT bindings for NAND devices connected to the NEMC on JZ4780 SoCs,
> as well as the hardware BCH controller, used by the jz4780_{nand,bch}
> drivers.
>
> Signed-off-by: Alex Smith
> Cc: Zubair Lutfullah
On Tue, Dec 29, 2015 at 01:45:09PM -0500, Insu Yun wrote:
> kmalloc needs to be handled when failing in memory pressure.
> Also, it has memory leak in error routine.
>
> Signed-off-by: Insu Yun
Applied to l2-mtd.git
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On 01/05/2016 02:13 PM, Mike Snitzer wrote:
> On Tue, Jan 05 2016 at 3:16pm -0500,
> Mike Snitzer wrote:
>
>> On Tue, Dec 08 2015 at 1:26pm -0500,
>> Scotty Bauer wrote:
>>
>>> Friendly ping, is anyone interested in this?
>>
>> The passed @user argument is flagged via __user so it can be
>>
On Wed, Jan 6, 2016 at 5:12 PM, Stephen Boyd wrote:
> of_irq_count() is not an exported symbol (and it shouldn't be
> used by platform drivers anyway) so use platform_irq_count()
> instead. This allows us to make the qcom pinctrl drivers modular
> again.
>
[..]
> diff --git
On Wed, Jan 6, 2016 at 7:12 PM, Stephen Boyd wrote:
> A recent patch added calls to of_irq_count() in the qcom pinctrl
> drivers and that caused module build failures because
> of_irq_count() is not an exported symbol. We shouldn't export
> of_irq_count() to modules because it's an internal OF
Hi Harvey,
On Mon, Jan 04, 2016 at 12:34:43PM +, Harvey Hunt wrote:
> From: Alex Smith
>
> Add a driver for NAND devices connected to the NEMC on JZ4780 SoCs, as
> well as the hardware BCH controller. DMA is not currently implemented.
>
> While older 47xx SoCs also have a BCH controller,
One of my recent changes to the qcom pinctrl drivers introduced
a module build failure due to of_irq_count() missing an export.
Rob doesn't want us to export that API though, so this series
introduces platform_irq_count() and uses it in the pinctrl
drivers. Linus changed the Kconfig to bool so
This reverts commit bda7c4c2b9767ce2af4394754498662d62079af5.
These drivers build as modules now that we use
platform_irq_count() instead of of_irq_count().
Cc: Rob Herring
Cc: Andy Gross
Signed-off-by: Stephen Boyd
---
drivers/pinctrl/qcom/Kconfig | 4 ++--
1 file changed, 2 insertions(+), 2
of_irq_count() is not an exported symbol (and it shouldn't be
used by platform drivers anyway) so use platform_irq_count()
instead. This allows us to make the qcom pinctrl drivers modular
again.
Cc: Rob Herring
Cc: Andy Gross
Signed-off-by: Stephen Boyd
---
A recent patch added calls to of_irq_count() in the qcom pinctrl
drivers and that caused module build failures because
of_irq_count() is not an exported symbol. We shouldn't export
of_irq_count() to modules because it's an internal OF API that
shouldn't be used by drivers. Platform drivers should
On 6 November 2015 at 17:57, Darren Hart wrote:
>
> On Fri, Nov 06, 2015 at 03:19:43PM +0100, David Herrmann wrote:
> > Hi Darren!
> >
> > On Wed, Oct 21, 2015 at 4:44 PM, Darren Hart wrote:
> > > On Wed, Oct 21, 2015 at 12:33:52PM -0200, Henrique de Moraes Holschuh
> > > wrote:
> > >> On Wed,
On Wed, Jan 06, 2016 at 10:23:51PM +0200, Michael S. Tsirkin wrote:
[...]
> > >
> > > Sorry, I don't understand - why do you have to do anything?
> > > I changed all users of smp_lwsync so they
> > > use __smp_lwsync on SMP and barrier() on !SMP.
> > >
> > > This is exactly the current
Hi all,
On Mon, 21 Dec 2015 11:23:01 +1100 Stephen Rothwell
wrote:
>
> On Thu, 10 Dec 2015 11:18:47 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the vfs tree, today's linux-next build (x86_64 allmodconfig)
> > failed like this:
> >
> > fs/orangefs/symlink.c:26:2: error: unknown
David Howells wrote:
> Partially revert commit 41c89b64d7184a780f12f2cccdabe65cb2408893:
>
> Author: Petko Manolov
> Date: Wed Dec 2 17:47:55 2015 +0200
> IMA: create machine owner and blacklist keyrings
>
> The problem is that prep->trusted is a simple boolean and the
Hi All,
>> The current driver uses input clock source frequency to calculate
>> values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we do not
>> currently have a good way to provide the frequency information.
>> Instead, we can leverage the SSCN and FFCN ACPI methods, which can be
Commit afd7f88f1577 ("serial: 8250: move of_serial code to 8250 directory")
moved the serial port driver for Open Firmware platform devices from one
directory to another, but a mixup in Kconfig options resulted in the driver
never being built. This results in runtime failures for some xtensa,
Commit 097d88e94c44 ("gpio: xilinx: use gpiochip data pointer") replaces
the use of container_of() with gpiochip_get_data(). Unfortunately, the
data pointer is not yet set by the time xgpio_save_regs() is called,
causing a system hang.
Fixes: 097d88e94c44 ("gpio: xilinx: use gpiochip data
On Wed, Jan 06, 2016 at 07:11:41PM -0500, Dave Jones wrote:
> On Wed, Jan 06, 2016 at 06:55:27PM -0500, Dave Jones wrote:
> > I just spotted this in /proc/meminfo on an old Core2 machine with 4G.
> >
> > DirectMap2M:18446744073709543424 kB
> >
> > Looks like we subtracted 8192
Currently, the dynamic sort keys compares trace data using memcmp().
But for output sorting, it should check data size and compare by word.
Also it sorted strings in reverse order, fix it.
Before)
$ perf report -F overhead -s prev_pid,next_pid
...
# Overheadprev_pidnext_pid
#
Now dynamic sort keys are supported for tracepoint events, add it to
output fields too.
Signed-off-by: Namhyung Kim
---
tools/perf/util/sort.c | 51 --
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/tools/perf/util/sort.c
To use dynamic sort keys, it might be good to add an option to see the
list of field names.
$ perf evlist -i perf.data.sched
sched:sched_switch
sched:sched_stat_wait
sched:sched_stat_sleep
sched:sched_stat_iowait
sched:sched_stat_runtime
sched:sched_process_fork
sched:sched_wakeup
Currently it sorts entries in reverse (alphabetic) order, fix it.
Signed-off-by: Namhyung Kim
---
This patch can be folded into the original patch c7c2a5e40f17
("perf tools: Add dynamic sort key for tracepoint events")
tools/perf/util/sort.c | 2 +-
1 file changed, 1 insertion(+), 1
The ->sort callback is used for final output sorting. As it's called
after processing all hist entries, it doesn't need to update dynamic
length anymore. Also it needs additional handling to sort them
properly (which is the topic of next patch).
Signed-off-by: Namhyung Kim
---
On Wed, Jan 06, 2016 at 06:55:27PM -0500, Dave Jones wrote:
> I just spotted this in /proc/meminfo on an old Core2 machine with 4G.
>
> DirectMap2M:18446744073709543424 kB
>
> Looks like we subtracted 8192 from 0 somewhere.
>
> Should split_page_count() be checking that
Memory Protection Keys for User pages is a CPU feature which will
first appear on Skylake Servers, but will also be supported on
future non-server parts (there is also a QEMU implementation). It
provides a mechanism for enforcing page-based protections, but
without requiring modification of the
From: Dave Hansen
There are two CPUID bits for protection keys. One is for whether
the CPU contains the feature, and the other will appear set once
the OS enables protection keys. Specifically:
Bit 04: OSPKE. If 1, OS has set CR4.PKE to enable
Protection keys (and the
On Fri, Dec 18, 2015 at 03:57:53PM +0100, Arnd Bergmann wrote:
> The newly added MSI support for iproc causes a link error when its
> Kconfig option is disabled:
>
> ERROR: "iproc_msi_exit" [drivers/pci/host/pcie-iproc.ko] undefined!
> ERROR: "iproc_msi_init" [drivers/pci/host/pcie-iproc.ko]
From: Dave Hansen
There is an XSAVE state component for Intel Processor Trace (PT).
But, we do not currently use it.
We add a placeholder in the code for it so it is not a mystery and
also so we do not need an explicit enum initialization for Protection
Keys in a moment.
Why don't we use it?
From: Dave Hansen
There is a new bit in CR4 for enabling protection keys. We
will actually enable it later in the series.
Signed-off-by: Dave Hansen
Reviewed-by: Thomas Gleixner
---
b/arch/x86/include/uapi/asm/processor-flags.h |2 ++
1 file changed, 2 insertions(+)
diff -puN
From: Dave Hansen
Previous documentation has referred to these 4 bits as "ignored".
That means that software could have made use of them. But, as
far as I know, the kernel never used them.
They are still ignored when protection keys is not enabled, so
they could theoretically still get used
From: Dave Hansen
For protection keys, we need to understand whether protections
should be enforced in software or not. In general, we enforce
protections when working on our own task, but not when on others.
We call these "current" and "foreign" operations.
This introduces two new
From: Dave Hansen
Lots of things seem to do:
vma->vm_page_prot = vm_get_page_prot(flags);
and the ptes get created right from things we pull out
of ->vm_page_prot. So it is very convenient if we can
store the protection key in flags and vm_page_prot, just
like the existing permission
On Wed, Jan 06, 2016 at 08:50:45PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Jan 06, 2016 at 08:31:49PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Thu, Jan 07, 2016 at 08:26:45AM +0900, Namhyung Kim escreveu:
> > > On Wed, Jan 06, 2016 at 08:06:43PM -0300, Arnaldo Carvalho de Melo
From: Dave Hansen
The protection keys register (PKRU) is saved and restored using
xsave. Define the data structure that we will use to access it
inside the xsave buffer.
Note that we also have to widen the printk of the xsave feature
masks since this is feature 0x200 and we only did two
From: Dave Hansen
I don't have a strong opinion on whether we need a Kconfig prompt
or not. Protection Keys has relatively little code associated
with it, and it is not a heavyweight feature to keep enabled.
However, I can imagine that folks would still appreciate being
able to disable it.
From: Dave Hansen
During a page fault, we look up the VMA to ensure that the fault
is in a region with a valid mapping. But, in the top-level page
fault code we don't need the VMA for much else. Once we have
decided that an access is bad, we are going to send a signal no
matter what and do
From: Dave Hansen
Note: "PK" is how the Intel SDM refers to this bit, so we also
use that nomenclature.
This only defines the bit, it does not plumb it anywhere to be
handled.
Signed-off-by: Dave Hansen
Reviewed-by: Thomas Gleixner
---
b/arch/x86/mm/fault.c |8
1 file
From: Dave Hansen
This code matches a fault condition up with the VMA and ensures
that the VMA allows the fault to be handled instead of just
erroring out.
We will be extending this in a moment to comprehend protection
keys.
Signed-off-by: Dave Hansen
Reviewed-by: Thomas Gleixner
---
From: Dave Hansen
This fills in the new siginfo field: si_pkey to indicate to
userspace which protection key was set on the PTE that we faulted
on.
Note though that *ALL* protection key faults have to be generated
by a valid, present PTE at some point. But this code does no PTE
lookups which
On Tue, Aug 11, 2015 at 09:57:12PM +0200, Robert Jarzmik wrote:
> Add verbose debug for register accesses. This enables easier debugging
> by following where and how hardware is stimulated, and how it answers.
>
> Signed-off-by: Robert Jarzmik
> ---
> drivers/mtd/nand/pxa3xx_nand.c | 22
From: Dave Hansen
As discussed earlier, we attempt to enforce protection keys in
software.
However, the code checks all faults to ensure that they are not
violating protection key permissions. It was assumed that all
faults are either write faults where we check PKRU[key].WD (write
disable)
From: Dave Hansen
The current get_user_pages() code is a wee bit more complicated
than it needs to be for pte bit checking. Currently, it establishes
a mask of required pte _PAGE_* bits and ensures that the pte it
goes after has all those bits.
This consolidates the three identical copies of
From: Dave Hansen
This adds the raw instruction to access PKRU as well as some
accessor functions that correctly handle when the CPU does not
support the instruction. We don't use it here, but we will use
read_pkru() in the next patch.
Signed-off-by: Dave Hansen
---
From: Dave Hansen
Protection Keys never affect kernel mappings. But, they can
affect whether the kernel will fault when it touches a user
mapping. The kernel doesn't touch user mappings without some
careful choreography and these accesses don't generally result in
oopses. But, if one does,
From: Dave Hansen
We might not strictly have to make modifictions to
access_error() to check the VMA here.
If we do not, we will do this:
1. app sets VMA pkey to K
2. app touches a !present page
3. do_page_fault(), allocates and maps page, sets pte.pkey=K
4. return to userspace
5. touch
> Partially revert commit 41c89b64d7184a780f12f2cccdabe65cb2408893:
>
> Author: Petko Manolov
> Date: Wed Dec 2 17:47:55 2015 +0200
> IMA: create machine owner and blacklist keyrings
>
If you need this applied to a tree, please state which.
--
James Morris
--
To
From: Dave Hansen
Today, for normal faults and page table walks, we check the VMA
and/or PTE to ensure that it is compatible with the action. For
instance, if we get a write fault on a non-writeable VMA, we
SIGSEGV.
We try to do the same thing for protection keys. Basically, we
try to make
From: Dave Hansen
I don't have a strong opinion on whether we need this or not.
Protection Keys has relatively little code associated with it,
and it is not a heavyweight feature to keep enabled. However,
I can imagine that folks would still appreciate being able to
disable it.
Here's the
From: Dave Hansen
We want to modify the Protection Key rights inside the kernel, so
we need to change PKRU's contents. But, if we do a plain
'wrpkru', when we return to userspace we might do an XRSTOR and
wipe out the kernel's 'wrpkru'. So, we need to go after PKRU in
the xsave buffer.
We do
On Sat, Dec 19, 2015 at 01:19:26PM +0100, Robert Jarzmik wrote:
> Brian Norris writes:
>
> > I don't have very strong opinions on this. It's kind of annoying to have
> > this sort of stuff duplicated for every driver, if it's really needed.
> > But I'll admit this kind of infrastructure is
From: Dave Hansen
The protection key can now be just as important as read/write
permissions on a VMA. We need some debug mechanism to help
figure out if it is in play. smaps seems like a logical
place to expose it.
arch/x86/kernel/setup.c is a bit of a weirdo place to put
this code, but it
From: Dave Hansen
calc_vm_prot_bits() takes PROT_{READ,WRITE,EXECUTE} bits and
turns them in to the vma->vm_flags/VM_* bits. We need to do a
similar thing for protection keys.
We take a protection key (4 bits) and encode it in to the 4
VM_PKEY_* bits.
Note: this code is not new. It was
From: Dave Hansen
This sets the bit in 'cr4' to actually enable the protection
keys feature. We also include a boot-time disable for the
feature "nopku".
Seting X86_CR4_PKE will cause the X86_FEATURE_OSPKE cpuid
bit to appear set. At this point in boot, identify_cpu()
has already run the
From: Dave Hansen
The arch-specific mm_context_t is a great place to put
protection-key allocation state.
But, we need to initialize the allocation state because pkey 0 is
always "allocated". All of the runtime initialization of
mm_context_t is done in *_ldt() manipulation functions. This
From: Dave Hansen
This plumbs a protection key through calc_vm_flag_bits(). We
could have done this in calc_vm_prot_bits(), but I did not feel
super strongly which way to go. It was pretty arbitrary which
one to use.
Signed-off-by: Dave Hansen
Cc: linux-...@vger.kernel.org
Cc:
From: Dave Hansen
The syscall-level code is passed a protection key and need to
return an appropriate error code if the protection key is bogus.
We will be using this in subsequent patches.
Note that this also begins a series of arch-specific calls that
we need to expose in otherwise
From: Dave Hansen
The Protection Key Rights for User memory (PKRU) is a 32-bit
user-accessible register. It contains two bits for each
protection key: one to write-disable (WD) access to memory
covered by the key and another to access-disable (AD).
Userspace can read/write the register with
From: Dave Hansen
Protection keys provide new page-based protection in hardware.
But, they have an interesting attribute: they only affect data
accesses and never affect instruction fetches. That means that
if we set up some memory which is set as "access-disabled" via
protection keys, we can
From: Dave Hansen
We try to enforce protection keys in software the same way that we
do in hardware. (See long example below).
But, we only want to do this when accessing our *own* process's
memory. If GDB set PKRU[6].AD=1 (disable access to PKEY 6), then
tried to PTRACE_POKE a target
From: Dave Hansen
vma->vm_flags is an 'unsigned long', so has space for 32 flags
on 32-bit architectures. The high 32 bits are unused on 64-bit
platforms. We've steered away from using the unused high VMA
bits for things because we would have difficulty supporting it
on 32-bit.
Protection
From: Dave Hansen
A protection key fault is very similar to any other access error.
There must be a VMA, etc... We even want to take the same action
(SIGSEGV) that we do with a normal access fault.
However, we do need to let userspace know that something is
different. We do this the same way
On Tue, Jan 05, 2016 at 05:54:19PM +0100, Pali Rohár wrote:
> On Monday 23 March 2015 12:42:25 Hans de Goede wrote:
> > Hi,
> >
> > On 22-03-15 14:47, Pali Rohár wrote:
> > >This patch move v3 pinnacle code for trackstick detection from
> > >alps_hw_init_v3()
> > >to alps_set_protocol() so
On Wed, Jan 6, 2016 at 3:03 PM, Jerry Hoemann wrote:
> The NVDIMM code in the kernel supports an IOCTL interface to user
> space based upon the Intel Example DSM:
>
> http://pmem.io/documents/NVDIMM_DSM_Interface_Example.pdf
>
> This interface cannot be used by other NVDIMM DSMs that
Use the local uapi headers to keep in sync with "recently" added #define's
(e.g. VSS_OP_REGISTER1).
Fixes: 3eb2094c59e8 ("Adding makefile for tools/hv")
Cc:
Signed-off-by: Kamal Mostafa
Signed-off-by: K. Y. Srinivasan
---
tools/hv/Makefile | 2 ++
1 file changed, 2 insertions(+)
diff --git
I just spotted this in /proc/meminfo on an old Core2 machine with 4G.
DirectMap2M:18446744073709543424 kB
Looks like we subtracted 8192 from 0 somewhere.
Should split_page_count() be checking that direct_pages_count > 0 ?
Dave
--
To unsubscribe from this list: send the line
On Wed, Jan 06, 2016 at 09:12:30AM +0100, Hans de Goede wrote:
> Hi,
>
> On 05-01-16 17:44, Pali Rohár wrote:
> >On Sunday 22 March 2015 14:46:11 Pali Rohár wrote:
> >>This patch adds detection of trackstick for v7 protocol devices. Code in
> >>this
> >>patch is used in official Dell touchpad
On Wed, Jan 06, 2016 at 10:23:12PM +0200, Michael S. Tsirkin wrote:
> On Wed, Jan 06, 2016 at 01:23:50PM -0500, Rich Felker wrote:
> > On Wed, Jan 06, 2016 at 03:32:18PM +0100, Peter Zijlstra wrote:
> > > On Wed, Jan 06, 2016 at 01:52:17PM +0200, Michael S. Tsirkin wrote:
> > > > > > Peter, what
On Thu, Jan 7, 2016 at 4:27 AM, Tejun Heo wrote:
> Hello,
>
> On Thu, Jan 07, 2016 at 04:14:26AM +0530, Parav Pandit wrote:
>> Yes. I read through. I can see two changes to be made in V2 version of
>> this patch.
>> 1. rdma.resource.verb.usage and rdma.resource.verb.limit to change
>>
Em Wed, Jan 06, 2016 at 08:31:49PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Thu, Jan 07, 2016 at 08:26:45AM +0900, Namhyung Kim escreveu:
> > On Wed, Jan 06, 2016 at 08:06:43PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Wed, Jan 06, 2016 at 09:54:59AM +0900, Namhyung Kim escreveu:
> > >
Florian Westphal wrote:
> Thadeu Lima de Souza Cascardo wrote:
> > On Wed, Jan 06, 2016 at 11:11:41PM +0300, Konstantin Khlebnikov wrote:
[ skb_gso_segment uses skb->cb[], causes oops if ip_fragment is invoked
on segmented skbs ]
> > I have hit this as well, this fixes it for me on an older
On Wed, Jan 06, 2016 at 08:31:49PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jan 07, 2016 at 08:26:45AM +0900, Namhyung Kim escreveu:
> > On Wed, Jan 06, 2016 at 08:06:43PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Wed, Jan 06, 2016 at 09:54:59AM +0900, Namhyung Kim escreveu:
> > > >
On Wed, Jan 06, 2016 at 08:29:49PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jan 07, 2016 at 08:21:44AM +0900, Namhyung Kim escreveu:
> > On Wed, Jan 06, 2016 at 08:10:51PM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Wed, Jan 06, 2016 at 09:55:01AM +0900, Namhyung Kim escreveu:
> > > >
The Camera Adaptation Layer (CAL) is a block which consists of a dual
port CSI2/MIPI camera capture engine.
Port #0 can handle CSI2 camera connected to up to 4 data lanes.
Port #1 can handle CSI2 camera connected to up to 2 data lanes.
The driver implements the required API/ioctls to be V4L2
The Camera Adaptation Layer (CAL) is a block which consists of a dual
port CSI2/MIPI camera capture engine.
This camera engine is currently found on DRA72xx family of devices.
Port #0 can handle CSI2 camera connected to up to 4 data lanes.
Port #1 can handle CSI2 camera connected to up to 2 data
Device Tree bindings for the Camera Adaptation Layer (CAL) driver
Signed-off-by: Benoit Parrot
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/media/ti-cal.txt | 72 ++
1 file changed, 72 insertions(+)
create mode 100644
Signed-off-by: Benoit Parrot
---
MAINTAINERS | 8
1 file changed, 8 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4635e1d14612..ebbdb410c0f0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10631,6 +10631,14 @@ L: linux-o...@vger.kernel.org
S: Maintained
F:
Building with CONFIG_CC_STACKPROTECTOR_STRONG triggers protection code
generation under CONFIG_ARM_ATAG_DTB_COMPAT but this is too early for
being able to use any of the stack_chk code. Explicitly disable it for
only the atags_to_fdt bits.
Suggested-by: zhxihu
Signed-off-by: Kees Cook
---
v3:
-
On Wed, Jan 6, 2016 at 3:31 AM, Tejun Heo wrote:
> Hello,
>
> On Wed, Jan 06, 2016 at 12:28:03AM +0530, Parav Pandit wrote:
>> +/* hash table to keep map of tgid to owner cgroup */
>> +DEFINE_HASHTABLE(pid_cg_map_tbl, 7);
>> +DEFINE_SPINLOCK(pid_cg_map_lock);/* lock to protect hash table
Em Thu, Jan 07, 2016 at 08:26:45AM +0900, Namhyung Kim escreveu:
> On Wed, Jan 06, 2016 at 08:06:43PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Jan 06, 2016 at 09:54:59AM +0900, Namhyung Kim escreveu:
> > > Currently, the dynamic sort keys compares trace data using memcmp().
> > > But for
Em Thu, Jan 07, 2016 at 08:21:44AM +0900, Namhyung Kim escreveu:
> On Wed, Jan 06, 2016 at 08:10:51PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Wed, Jan 06, 2016 at 09:55:01AM +0900, Namhyung Kim escreveu:
> > > To use dynamic sort keys, it might be good to add an option to see the
> > > list
On Wed, Jan 06, 2016 at 08:06:43PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Jan 06, 2016 at 09:54:59AM +0900, Namhyung Kim escreveu:
> > Currently, the dynamic sort keys compares trace data using memcmp().
> > But for output sorting, it should check data size and compare by word.
> > Also
On Mon, Jan 4, 2016 at 6:13 AM, Wolfram Sang wrote:
> From: Grant Likely
>
> Add a single resource to the test bus device to exercise the platform
> bus code a little more. This isn't strictly a devicetree test, but it is
> a corner case that the devicetree runs into. Until we've got platform
>
On Sun, Dec 20, 2015 at 01:43:58PM +0300, Sergei Ianovich wrote:
> On Sat, 2015-12-19 at 21:38 -0600, Rob Herring wrote:
> > On Tue, Dec 15, 2015 at 09:58:53PM +0300, Sergei Ianovich wrote:
> > > +Required properties:
> > > +- compatible : should be "icpdas,sram-lp8x4x"
> >
> > No wildcards
On Sat, Dec 26, 2015 at 12:37:16AM +0100, Pali Rohár wrote:
> Property names do not match real names needed by driver itself.
> This patch fix this problem.
>
> Signed-off-by: Pali Rohár
Applied, thanks.
Rob
> ---
> .../devicetree/bindings/media/i2c/adp1653.txt |7 ---
> 1 file
On Wed, Jan 06, 2016 at 08:10:51PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Jan 06, 2016 at 09:55:01AM +0900, Namhyung Kim escreveu:
> > To use dynamic sort keys, it might be good to add an option to see the
> > list of field names.
> >
> > $ perf evlist -i perf.data.sched
> >
On Thu, Dec 31, 2015 at 04:21:22PM +0100, Nicholas Mc Guire wrote:
> This is an API consolidation only. The use of kmalloc + memset to 0
> is equivalent to kzalloc.
>
> Signed-off-by: Nicholas Mc Guire
Applied to l2-mtd.git
--
To unsubscribe from this list: send the line "unsubscribe
> "Mike" == mchristi writes:
+enum req_op {
+ REQ_OP_READ,
+ REQ_OP_WRITE= REQ_WRITE,
+ REQ_OP_DISCARD = REQ_DISCARD,
+ REQ_OP_WRITE_SAME = REQ_WRITE_SAME,
+};
+
I have been irked by the REQ_ prefix in bios since the flags were
On Fri, Jan 01, 2016 at 10:06:27PM +0800, Geliang Tang wrote:
> Use to_delayed_work() instead of open-coding it.
>
> Signed-off-by: Geliang Tang
Applied to l2-mtd.git
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
On Wed, Jan 6, 2016 at 3:26 AM, Tejun Heo wrote:
> On Wed, Jan 06, 2016 at 12:28:02AM +0530, Parav Pandit wrote:
>> Added function pointer table to store resource pool specific
>> operation for each resource type (verb and hw).
>> Added list node to link device to rdma cgroup so that it can
>>
On Thu, Jan 07, 2016 at 12:45:40AM +0530, Pranjal Bhor wrote:
> Signed-off-by: Pranjal Bhor
Your subject is very "odd", please fix it up and provide a real
changelog entry as well.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On Wed, Jan 6, 2016 at 3:28 AM, Fengguang Wu wrote:
> Hi Steven,
>
> On Mon, Jan 04, 2016 at 10:42:46AM -0500, Steven Rostedt wrote:
>> On Wed, 30 Dec 2015 23:06:41 +
>> Colin King wrote:
>>
>> > From: Colin Ian King
>> >
>> > Fix build warning:
>> >
>> > scripts/recordmcount.c:589:4:
On Sat, Dec 19, 2015 at 04:01:24AM +0100, Boris Brezillon wrote:
> Actually the nand_{get,set}_controller_data() helpers are not about
> assigning NAND controller private data (as you pointed those can
> already be retrieved thanks to the ->controller field using the
> container_of() trick), but
Hi Tejun,
On Wed, Jan 6, 2016 at 3:26 AM, Tejun Heo wrote:
> Hello,
>
> On Wed, Jan 06, 2016 at 12:28:00AM +0530, Parav Pandit wrote:
>> Resources are not defined by the RDMA cgroup. Resources are defined
>> by RDMA/IB stack & optionally by HCA vendor device drivers.
>
> As I wrote before, I
Hello,
On Thu, Jan 07, 2016 at 04:14:26AM +0530, Parav Pandit wrote:
> Yes. I read through. I can see two changes to be made in V2 version of
> this patch.
> 1. rdma.resource.verb.usage and rdma.resource.verb.limit to change
> respectively to,
> 2. rdma.resource.verb.stat and
101 - 200 of 1814 matches
Mail list logo
