Hello,
I find that identifiers like the following do not fit to the expected naming
convention of the C language standard.
- _ALPHA_BUG_H
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/alpha/include/asm/bug.h?id=acadbfb90a54673d6c8b05aa4e93218433890411#n1
- __BARRIER_H
Depending on peripheral capabilities, print SHA information at the end
of the probe function.
Signed-off-by: Nicolas Ferre
---
drivers/crypto/atmel-sha.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/atmel-sha.c b/drivers/crypto/atmel-sha.c
index ecfdf72..
On 11/8/13, 2:11 AM, Adrian Hunter wrote:
This prevents:
--out-pages=0
from working e.g.
tools/perf/perf record -vv --out-pages=0 uname
rounding mmap pages size to 4096 (1 pages)
Although without this patch:
tools/perf/perf record -vv --out-pages=0 uname
--mmap_pages
On Thu, Nov 07 2013, Christoph Hellwig wrote:
> Btw, I have to state that I very much disagree with dropping the
> direct I/O kernel changes, and I also very much disagree with keeping
> the immutable iovecs in.
>
> For the latter I think the immutable iovecs are useful and do want to
> see them e
On Wed, 30 Oct, at 03:57:41PM, Geyslan G. Bem wrote:
> This reorganization:
>
> Removes useless 'bytes' prior assignment.
>
> Uses 'memdup_user' instead 'kmalloc' + 'copy_from_user'.
>
> Signed-off-by: Geyslan G. Bem
> ---
> fs/efivarfs/file.c | 13 -
> 1 file changed, 4 insertions
On Fri, Nov 08, 2013 at 09:44:09AM +0800, Zhenzhong Duan wrote:
>
> On 2013-11-07 07:51, Bjorn Helgaas wrote:
> >[+cc Thomas, Ingo, Peter, x86 list]
> >
> >On Wed, Nov 6, 2013 at 2:16 PM, Konrad Rzeszutek Wilk
> > wrote:
> >>Certain platforms do not allow writes in the MSI-X bars
> >>to setup or t
On 11/08/2013 12:11 PM, Prabhakar Lad wrote:
From: "Lad, Prabhakar"
the devm_*() helper prints error messages in case of
errors no need to do the same in the driver.
Pls, drop it - devm_clk_get() doesn't always print error messages
Signed-off-by: Lad, Prabhakar
---
drivers/gpio/gpio-davi
On Fri, Nov 08, 2013 at 07:32:53PM +0800, Nicolin Chen wrote:
> By enabling dual fifo mode, it would allow SSI enter a better performance
> to transimit/receive data without occasional hardware underrun/overrun.
Acked-by: Mark Brown
signature.asc
Description: Digital signature
On Thu, Nov 7, 2013 at 8:40 PM, Yijing Wang wrote:
> HI Bjorn,
>Thanks for your review and comments very much!
>
>>> +list_for_each_entry(dmar_dev, head, list)
>>> +if (dmar_dev->segment == pci_domain_nr(dev->bus)
>>> +&& dmar_dev->bus == dev
On Fri, 08 Nov 2013, Krzysztof Kozlowski wrote:
> The last two parameters of certain register access functions were in
> different order than regmap API. This was confusing and error-prone.
>
> Reorder parameters for register access API to match regmap API:
> - sec_bulk_read() reorder count and
> On Wed, 6 Nov 2013, Simon Wood wrote:
>
>> Adjust the scaling and lineartity to match that of the Windows
>> driver (from MOMO testing).
>>
>> Reported-by: Elias Vanderstuyft
>> Signed-off-by: Simon Wood
>
> I have applied the series, thanks.
Thanks to all involved.
Simon
--
To unsubscribe fr
Ingo,
I am stupid. aa59c53fd459 "uprobes: Change uprobe_copy_process()
to dup xol_area" needs the trivial fix, see 1/1. Sorry.
Perhaps I should add this patch to my tree and ask you to pull
this one-liner? Probably I can also add another "uprobes: Fix
the memory out of bound overwrite in copy_ins
On Thu, Nov 07, 2013 at 11:27:32PM -0800, Christoph Hellwig wrote:
> On Fri, Nov 08, 2013 at 05:58:48PM +1100, Stephen Rothwell wrote:
> > Hi Eric,
> >
> > After merging the userns tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > fs/namei.c: In function 'cove
Commit aa59c53fd459 "uprobes: Change uprobe_copy_process() to dup
xol_area" has a stupid typo, we need to setup t->utask->vaddr but
the code wrongly uses current->utask.
Even with this bug dup_xol_work() works "in practice", but only
because get_unmapped_area(NULL, TASK_SIZE - PAGE_SIZE) likely
re
On Wed, Nov 06, 2013 at 12:07:37PM +, Vinayak Kale wrote:
> Add support for irq registration when pmu interrupt is percpu.
>
> Signed-off-by: Vinayak Kale
> Signed-off-by: Tuan Phan
> ---
> arch/arm64/kernel/perf_event.c | 109
> +---
> 1 file changed,
Dave,
Here is one more pull request for the 3.13 window. This is primarily
composed of downstream pull requests that were posted while I was
traveling during the last part of the 3.12 release.
For the mac80211 bits, Johannes says:
"I have two DFS fixes (ath9k already supports DFS) and a fix for
On Fri, Nov 08, 2013 at 06:45:34AM -0800, Paul E. McKenney wrote:
> On Fri, Nov 08, 2013 at 03:29:38PM +0100, Frederic Weisbecker wrote:
> > On Fri, Nov 08, 2013 at 06:03:31AM -0800, Paul E. McKenney wrote:
> > > On Fri, Nov 08, 2013 at 02:26:28PM +0100, Mike Galbraith wrote:
> > > > On Fri, 2013-1
Hi James,
We've got appropriate acks on this, and we've also established
that it doesn't appear to even be enabled in any of the common
distros, and nobody voiced any strong objections in the past
month+ since posting, so please pull this driver deletion.
Thanks,
Paul.
---
The following changes
On Fri, 08 Nov 2013, Krzysztof Kozlowski wrote:
> The last two parameters of certain register access functions were in
> different order than regmap API. This was confusing and error-prone.
>
> Reorder parameters for register access API to match regmap API:
> - max77693_bulk_read() reorder count
Hi Linus,
Please pull from the git repository at
git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git
pm+acpi-3.13-rc1
to receive ACPI and power management updates for v3.13-rc1 with
top-most commit faddf2f5d278f1656e9444961bdd8d9db4deb5bf
Merge branch 'pm-cpufreq'
on top of
On Fri, Nov 08, 2013 at 03:53:47PM +0100, Mike Galbraith wrote:
> On Fri, 2013-11-08 at 15:29 +0100, Frederic Weisbecker wrote:
> > On Fri, Nov 08, 2013 at 06:03:31AM -0800, Paul E. McKenney wrote:
> > > On Fri, Nov 08, 2013 at 02:26:28PM +0100, Mike Galbraith wrote:
> > > > On Fri, 2013-11-08 at
On Nov 5, 2013, at 8:28 AM, Sebastian Hesselbarth wrote:
> This adds very basic device tree files for the Marvell Armada 1500 SoC
> (Berlin BG2) and the Sony NSZ-GS7 GoogleTV board. Currently, SoC only has
> nodes for cpus, some clocks, l2 cache controller, local timer, apb timers,
> uart, and in
On Wed, Oct 23, 2013 at 12:01:24AM +0900, HATAYAMA Daisuke wrote:
> If crash occurs on some AP, then kdump 2nd kernel is booted up on the
> AP. Therefore, it is not always correct that the CPU that is currently
> booting up the kernel is BSP. It's wrong to reflect BSP information in
> MP table as f
On Fri, Nov 08 2013, Jens Axboe wrote:
> On Thu, Nov 07 2013, Christoph Hellwig wrote:
> > Btw, I have to state that I very much disagree with dropping the
> > direct I/O kernel changes, and I also very much disagree with keeping
> > the immutable iovecs in.
> >
> > For the latter I think the immu
On 11/08/2013 07:14 AM, Vivek Goyal wrote:
>
> Hi Bao,
>
> This patch fixes the issue for me too. I noticed that we have generic
> function migrate_to_reboot_cpu() to achieve what we want and rest of
> the reboot paths are using it. So how about using that function. I
> wrote the new patch below
On 11/08/2013 11:04 AM, Paul Gortmaker wrote:
Paul Gortmaker (1):
scsi: delete decade+ obsolete aic7xxx_old driver
Documentation/scsi/00-INDEX | 2 -
Documentation/scsi/aic7xxx_old.txt | 511 --
MAINTAINERS | 1 -
drivers/scsi/K
Acked-by: Christoph Lameter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Acked-by: Christoph Lameter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Acked-by: Christoph Lameter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 11/07, Oleg Nesterov wrote:
>
> Note: we do not care if offset + size > i_size, the users of
> arch_uprobe->insn can't know how many bytes were actually copied
> anyway. But perhaps this needs more changes.
I guess this not is not very clear...
What I tried to say. Suppose that offset == 0 and
On Wed, Nov 06, 2013 at 12:07:38PM -0800, Joe Perches wrote:
> On Wed, 2013-11-06 at 15:02 -0500, Neil Horman wrote:
> > On Wed, Nov 06, 2013 at 09:19:23AM -0800, Joe Perches wrote:
> []
> > > __always_inline instead of inline
> > > static __always_inline void prefetch_lines(const void *addr, size_
On Fri, Nov 8, 2013 at 5:24 AM, Yaroslav Molochko wrote:
> Sorry. I was not using this machine for quite a bit, I've updated to the new
> kernel and updated bug with the information you asked
Thanks.
Note that this appears to be vanilla v3.12, which has e1000e version
2.3.2-k in it. Intel maint
commit 6efa20e49b9cb1db1ab66870cc37323474a75a13
("xen: Support 64-bit PV guest receiving NMIs") and
commit cd9151e26d31048b2b5e00fd02e110e07d2200c9
( "xen/balloon: set a mapping for ballooned out pages")
added new instances of __cpuinit usage.
We removed this a couple versions ago; we now want to
On Fri, Nov 08, 2013 at 08:12:00AM -0800, H. Peter Anvin wrote:
> On 11/08/2013 07:14 AM, Vivek Goyal wrote:
> >
> > Hi Bao,
> >
> > This patch fixes the issue for me too. I noticed that we have generic
> > function migrate_to_reboot_cpu() to achieve what we want and rest of
> > the reboot paths
On Thu, Nov 7, 2013 at 5:58 PM, Olav Haugan wrote:
> zsmalloc encodes a handle using the pfn and an object
> index. On hardware platforms with physical memory starting
> at 0x0 the pfn can be 0. This causes the encoded handle to be
> 0 and is incorrectly interpreted as an allocation failure.
>
> T
On Thursday, November 07, 2013 11:05:26 AM Andy Lutomirski wrote:
> On Thu, Nov 7, 2013 at 10:56 AM, Eric Paris wrote:
>
> > Isn't x32 similarly screwy? Does it work because the syscall numbers
> > are different?
>
> Yes (from reading the code -- I haven't actually tried it).
I've got a x32 VM
On Fri, Nov 08, 2013 at 03:06:59PM +, Christoph Lameter wrote:
> On Thu, 7 Nov 2013, Frederic Weisbecker wrote:
>
> > usermodehelper works are created via workqueues, right? And workqueues are
> > an issue as
> > well for those who want CPU isolation.
>
> AFAICT usermodehelper can be called
If perf fails to write data to the data file (e.g., ENOSPC error) it fails
with the message:
failed to write perf data, error: No space left on device
and stops — killing the workload too. The file is an unknown state. Trying
to read it (e.g., perf report) fails with a SIGBUS error.
Fix by dele
On Fri, Nov 8, 2013 at 8:29 AM, Paul Moore wrote:
> On Thursday, November 07, 2013 11:05:26 AM Andy Lutomirski wrote:
>> On Thu, Nov 7, 2013 at 10:56 AM, Eric Paris wrote:
>>
>> > Isn't x32 similarly screwy? Does it work because the syscall numbers
>> > are different?
>>
>> Yes (from reading the
Hi Stephen,
On 11/07/2013 02:20 PM, Stephen Boyd wrote:
> If we're running on a v7 ARM CPU, detect if the CPU supports the
> sdiv/udiv instructions and replace the signed and unsigned
> division library functions with an sdiv/udiv instruction.
[...]
> +++ b/arch/arm/lib/div-v7.c
> @@ -0,0 +1,58
On Fri, 2013-11-08 at 11:25 -0500, Neil Horman wrote:
> On Wed, Nov 06, 2013 at 12:07:38PM -0800, Joe Perches wrote:
> > On Wed, 2013-11-06 at 15:02 -0500, Neil Horman wrote:
> > > On Wed, Nov 06, 2013 at 09:19:23AM -0800, Joe Perches wrote:
> > []
> > > > __always_inline instead of inline
> > > >
Hi Namhyung,
sorry for delay.
On 11/07, Namhyung Kim wrote:
>
> >> > As for "-= tu->offset"... Can't we avoid it? User-space needs to
> >> > calculate
> >> > the "@" argument anyway, why it can't also substruct this offset?
> >>
> >> Hmm.. it makes sense too. :)
> >
> > I am no longer sure ;)
>
On 11/8/13, 2:34 AM, Jiri Olsa wrote:
+ if (ftruncate(fd, len) != 0)
+ pr_err("ftruncate failed\n");
I think we should fail here and dont let the finishing
code run on probably corrupted file.
the code that process build IDs could even get stuck
Yes, I'll fix that in v5.
On Fri, Nov 08, 2013 at 10:58:42AM +0100, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> On 11:20 Thu 07 Nov , Stephen Boyd wrote:
> > @@ -381,6 +384,13 @@ static void __init cpuid_init_hwcaps(void)
> > elf_hwcap |= HWCAP_IDIVT;
> > }
> >
> > +#ifdef CONFIG_THUMB2_KERNEL
> if (IS_
I'm seeing a build failure for a no-MMU system:
mm/built-in.o: In function `__vm_enough_memory':
(.text+0x1ce70): undefined reference to `vm_commit_limit'
fs/built-in.o: In function `meminfo_proc_show':
meminfo.c:(.text+0x6852c): undefined reference to `vm_commit_limit'
This patch added
On Fri, Nov 08, 2013 at 12:50:04PM +0100, Jean-Christophe PLAGNIOL-VILLARD
wrote:
> On 19:34 Thu 07 Nov , Rob Herring wrote:
> > On Thu, Nov 7, 2013 at 1:20 PM, Stephen Boyd wrote:
> > > If we're running on a v7 ARM CPU, detect if the CPU supports the
> > > sdiv/udiv instructions and replace
On Thu, Nov 07, 2013 at 05:21:58PM -0600, Kumar Gala wrote:
> As we start having more sharing of device trees between architectures
> (arm & arm64, arm & powerpc, guessing maybe mips & arm) we need dts to
> live in location that
>
> I was wondering what people felt about doing:
>
> arch/dt
Hi Sandeepa,
On Thu, Oct 17, 2013 at 12:17:47PM +0100, Sandeepa Prabhu wrote:
> Add support for basic kernel probes(kprobes), jump probes (jprobes)
> for ARM64.
I think this series will conflict quite heavily with the jump_label series,
since they both introduce some common instruction manipulati
On Fri, Nov 08, 2013 at 10:13:19AM -0600, Kumar Gala wrote:
> On Nov 5, 2013, at 8:28 AM, Sebastian Hesselbarth wrote:
...
> > .../devicetree/bindings/arm/marvell,berlin.txt | 24 +++
> > arch/arm/boot/dts/Makefile |2 +
> > arch/arm/boot/dts/berlin2-sony-nsz-gs7.dts
On Thu, 7 Nov 2013, Julius Werner wrote:
> This patch adds a check for USB_STATE_NOTATTACHED to the
> hub_port_warm_reset_required() workaround for ports that end up in
> Compliance Mode in hub_events() when trying to decide which reset
> function to use. Trying to call usb_reset_device() with a N
On 11/07, Namhyung Kim wrote:
>
> On Wed, 6 Nov 2013 19:24:08 +0100, Oleg Nesterov wrote:
> >
> > Note that instruction_pointer_set() is not really nice in any case,
> > this can obviously confuse FETCH_MTD_reg("ip").
>
> Yes.
>
> >
> > But lets ignore this. The solution is simple, we can pass/use
Hi Jason,
Just want to let you know that I'm not forgetting about reviewing these
patches. It is on my to do list, I will get to it by this or next
weekend.
--Ashley Lai
On Sun, 2013-11-03 at 20:38 -0700, Jason Gunthorpe wrote:
> Here is the last five patches from the prior series I sent that d
On 11/08/2013 02:49 AM, Florian Meier wrote:
> In order to find I2C devices in the device tree, the platform nodes
> have to be known by the I2C core. Analogous to the i2c-omap driver
> this requires setting the dev.of_node parameter of the adapter.
(CCing the I2C maintainers...)
> diff --git a/d
On Thursday 07 November 2013 08:20 PM, Stephen Boyd wrote:
> From: Mahesh Sivasubramanian
>
> LPAE enabled kernels use the 64-bit version of TTBR0 and TTBR1
> registers. If we're running an LPAE kernel, fill the upper half
> of TTBR0 with 0 because we're setting it to the idmap here (the
> idmap
On Fri, 8 Nov 2013, Frederic Weisbecker wrote:
> But it looks like it always end up calling a workqueue. May be I missed
> something though.
>
> Now we can argue that this workqueue seem to create kernel threads, which in
> turn create other kernel thread (uhh?)
> and I don't know if those inher
On Thu, Oct 17, 2013 at 12:17:48PM +0100, Sandeepa Prabhu wrote:
> Add support for AArch64 instruction simulation in kprobes.
>
> Kprobes need simulation of instructions that cannot be stepped
> right-away from different memory location. i.e. those instructions
> that uses PC-relative addressing.
On 09/12/2013 02:01 PM, Ingo Molnar wrote:
* Sasha Levin wrote:
On 07/08/2013 04:39 AM, Ingo Molnar wrote:
* Sasha Levin wrote:
The other issue is that with lock classes disabled you have to hit an
actual deadlock to trigger any output.
I.e. much of the power of lockdep is diminished :-
On Thu, Oct 17, 2013 at 12:17:49PM +0100, Sandeepa Prabhu wrote:
> AArch64 ISA does not instructions to pop PC register value
> from stack(like ARM v7 has ldmia {...,pc}) without using
> one of the general purpose registers. This means return probes
> cannot return to the actual return address dire
Stephen Boyd writes:
> +int __aeabi_idiv(int numerator, int denominator)
> +{
> + if (static_key_false(&cpu_has_idiv)) {
> + int ret;
> +
> + asm volatile (
> + ".arch_extension idiv\n"
> + "sdiv %0, %1, %2"
> + : "=&r" (ret)
There
During pci hotplug tests I received this one:
[ 34.735836] ==
[ 34.735838] [ INFO: possible circular locking dependency detected ]
[ 34.735840] 3.12.0-01915-g6c86ae2-dirty #125 Not tainted
[ 34.735842]
On 11/06, Eric W. Biederman wrote:
>
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -1174,7 +1174,7 @@ static struct task_struct *copy_process(unsigned long
> clone_flags,
> * do not allow it to share a thread group or signal handlers or
> * parent with the forking task.
>
Add support for DMA controller of BCM2835 as used in the Raspberry Pi.
Currently it only supports cyclic DMA for serving the I2S driver.
Signed-off-by: Florian Meier
---
arch/arm/boot/dts/bcm2835.dtsi | 22 +
drivers/dma/Kconfig|6 +
drivers/dma/Makefile |1 +
dri
Hi Jason, Ashley
> Just want to let you know that I'm not forgetting about reviewing these
> patches. It is on my to do list, I will get to it by this or next
> weekend.
I'm also on it ;)
But of course it's quite a lot
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
On Fri, Nov 8, 2013 at 7:12 AM, James Hogan wrote:
> On 07/10/13 17:29, Rob Herring wrote:
>> From: Rob Herring
>>
>> Use the common unflatten_and_copy_device_tree to copy the built-in FDT
>> out of init section.
>>
>> Signed-off-by: Rob Herring
>> Cc: James Hogan
>
> With Qais' suggestion of r
On Fri, Nov 8, 2013 at 9:50 AM, Thomas Hellstrom wrote:
> This, however comes with two implications
> 1) Once a DMA-buf is added, it stays alive at least until someone removes
> the gem name of the exporting object, regardless whether there are any
> external users or not. I think this is OK, but
On 08/11/13 17:26, Rob Herring wrote:
> On Fri, Nov 8, 2013 at 7:12 AM, James Hogan wrote:
>> On 07/10/13 17:29, Rob Herring wrote:
>>> From: Rob Herring
>>>
>>> Use the common unflatten_and_copy_device_tree to copy the built-in FDT
>>> out of init section.
>>>
>>> Signed-off-by: Rob Herring
>>>
The PCI MMCONFIG area is usually reserved via the E820 so the Xen hypervisor
is aware of these regions. But they can also be enumerated in the ACPI
DSDT which means the hypervisor won't know of them until the initial
domain informs it of via PHYSDEVOP_pci_mmcfg_reserved.
This is what this patch do
There is a race case where the user does 'poweroff'
and at the same time the system admin does 'xl shutdown'.
Depending on the race, the system_state will be SYSTEM_RUNNING or
SYSTEM_POWER_OFF. If SYSTEM_RUNNING we just end up making
a duplicate call to 'poweroff' (while it is running).
That will
The 'read_reply' works with 'process_msg' to read of a reply in XenBus.
'process_msg' is running from within the 'xenbus' thread. Whenever
a message shows up in XenBus it is put on a xs_state.reply_list list
and 'read_reply' picks it up.
The problem is if the backend domain or the xenstored proces
The user can launch the guest in this sequence:
xl create -p /vm.cfg[launch, but pause it]
xl shutdown latest [sets control/shutdown=poweroff]
xl unpause latest
xl console latest [and see that the guest has completely
ignored the shutdown request]
In reality the guest hasn't ignore
Hey,
Two of these:
[PATCH 2/4] xen/manage: Poweroff forcefully if user-space is not yet
[PATCH 4/4] xen/xenbus: Avoid synchronous wait on XenBus stalling
fix the bugs.xenproject.org outstanding bugs.
The other ones are that were discovered on xen-devel and discussed.
They should go in v3.13 an
On Fri, Nov 8, 2013 at 6:55 AM, Viresh Kumar wrote:
> On 8 November 2013 00:36, Stratos Karafotis wrote:
>> I think the existing code already checks if the requested_freq is greater
>> than policy->max in __cpufreq_driver_target.
>
> Yes it does. But the problem is:
> - cs_check_cpu() sets reques
Hi Linus,
This is the pull request for the core changes in the block layer for
3.13. It contains:
- The new blk-mq request interface. This is a new and more scalable
queueing model that marries the best part of the request based
interface we currently have (which is fully featured, but scales
Hi Linus,
This is the block driver pull request for 3.13. As with the core pull
request just sent out, this was rebased on top of the core branch again
after the immutable series was pulled. This also means that bcache gets
to sit the initial pull over. I will send a second driver pull request
in
This patch uses architecture specific load-acquire and store-release
primitives for synchronization, if available. Generic implementations
are provided in case they are not defined even though they may not
be optimal. These generic implementation could be removed later on
once changes are made in a
Here's my take on it.
Rusty deleted the original docs from the patches rather than fixing them up.
Bad Rusty;-).
David
---
commit 49827f443556c0866b13d37edb34f0553f71b22c
Author: James Solner
Date: Wed Nov 6 12:53:36 2013 -0600
Add Documentation/module-signing.txt file
This patc
On Fri, 2013-11-08 at 09:53 +, Ian Campbell wrote:
> On Thu, 2013-11-07 at 18:14 -0800, Kamal Mostafa wrote:
> > 3.8.13.13 -stable review patch. If anyone has any objections, please let
> > me know.
>
> This patch caused a regression in the 3.10 stable tree. Two additional
> patches were nee
> > > That make sense? I can show you more concretely what I'm working on if
> > > you want. Or if I'm full of crap and this is useless for what you guys
> > > want I'm sure you'll let me know :)
> >
> > It sounds interesting, but also a little confusing at this point, at
> > least from the non-bl
On Fri, Nov 08, 2013 at 09:41:46AM -0700, David Ahern wrote:
> If perf fails to write data to the data file (e.g., ENOSPC error) it fails
> with the message:
> failed to write perf data, error: No space left on device
>
> and stops — killing the workload too. The file is an unknown state. Trying
Hi Michal,
On 11/08/2013 04:23 AM, Michal Nazarewicz wrote:
On Thu, Nov 07 2013, Alan Stern wrote:
What happens if the userspace daemon writes to epfile but the host
changes the config or altsetting before all the data can be sent? Does
the remaining data get flushed?
Each read and write is
On Nov 8, 2013, at 10:52 AM, Jason Cooper wrote:
> On Thu, Nov 07, 2013 at 05:21:58PM -0600, Kumar Gala wrote:
>> As we start having more sharing of device trees between architectures
>> (arm & arm64, arm & powerpc, guessing maybe mips & arm) we need dts to
>> live in location that
>>
>> I was
From: Luciano Coelho
Add a flag that indicate whether the clock is a crystal or not.
Additionally, parse a new device tree binding in clk-fixed-rate to set
this flag.
If clock-xtal isn't set, the clock framework will assume clock to be
generated by an oscillator. There's only one user for this
Hey Ric,
On Fri, Nov 08, 2013 at 06:03:41AM -0500, Ric Wheeler wrote:
> In the XFS community, we have 2 clear leaders in terms of
> contributions of significant feaures and depth of knowledge -
> Christoph and Dave.
>
> If you look at the number of patches submitted by developers since
> 3.0 who
Hi Linus,
Please pull the arm64 patches below. Thanks.
The following changes since commit d0e639c9e06d44e713170031fe05fb60ebe680af:
Linux 3.12-rc4 (2013-10-06 14:00:20 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/cmarinas/linux-aarch64.git
t
On Nov 8, 2013, at 10:57 AM, Jason Cooper wrote:
> On Fri, Nov 08, 2013 at 10:13:19AM -0600, Kumar Gala wrote:
>> On Nov 5, 2013, at 8:28 AM, Sebastian Hesselbarth wrote:
> ...
>>> .../devicetree/bindings/arm/marvell,berlin.txt | 24 +++
>>> arch/arm/boot/dts/Makefile
The selection of the process to be killed happens in two spots:
first in select_bad_process and then a further refinement by
looking for child processes in oom_kill_process. Since this is
a two step process, it is possible that the process selected by
select_bad_process may get a SIGKILL just befor
On Tue, Sep 17, 2013 at 05:43:26AM -0700, Russ Dill wrote:
> This patch adds support for and demonstrates the usage of an embedded
> position independent executable (PIE). The goal is to allow the use of C
> code in situations where carefully written position independent assembly
> was previously r
On 11/08/2013 01:03 PM, Ben Myers wrote:
Hey Ric,
On Fri, Nov 08, 2013 at 06:03:41AM -0500, Ric Wheeler wrote:
In the XFS community, we have 2 clear leaders in terms of
contributions of significant feaures and depth of knowledge -
Christoph and Dave.
If you look at the number of patches submit
On Fri, Nov 08, 2013 at 11:59:56AM -0600, Kumar Gala wrote:
>
> On Nov 8, 2013, at 10:52 AM, Jason Cooper wrote:
>
> > On Thu, Nov 07, 2013 at 05:21:58PM -0600, Kumar Gala wrote:
> >> As we start having more sharing of device trees between architectures
> >> (arm & arm64, arm & powerpc, guessing
On 8 November 2013 23:13, Stratos Karafotis wrote:
> Please let me rephrase my previous post. In some circumstances (depending
> on freq_step and freq_table values) CPU frequency will never reach to
> policy->max.
>
> For example suppose that (for simplicity values in MHz):
> policy->max = 1000
>
From: "John W. Linville"
Date: Fri, 8 Nov 2013 10:48:03 -0500
> Here is one more pull request for the 3.13 window. This is primarily
> composed of downstream pull requests that were posted while I was
> traveling during the last part of the 3.12 release.
Pulled, thanks John.
--
To unsubscribe f
On Nov 8, 2013, at 12:13 PM, Jason Cooper wrote:
> On Fri, Nov 08, 2013 at 11:59:56AM -0600, Kumar Gala wrote:
>>
>> On Nov 8, 2013, at 10:52 AM, Jason Cooper wrote:
>>
>>> On Thu, Nov 07, 2013 at 05:21:58PM -0600, Kumar Gala wrote:
As we start having more sharing of device trees between a
On Fri, Nov 08, 2013 at 06:22:34PM +0100, Florian Meier wrote:
> Add support for DMA controller of BCM2835 as used in the Raspberry Pi.
> Currently it only supports cyclic DMA for serving the I2S driver.
Adding in Martin Sperl who's been looking at DMA with regard to the SPI
controller (which will
On Thu, Nov 7, 2013 at 2:25 PM, Olof Johansson wrote:
> It makes sense to split out the Chromebook/Chromebox hardware platform
> drivers to a separate subdirectory, since some of it will be shared
> between ARM and x86.
>
> This moves over the existing chromeos_laptop driver without making
> any o
On Fri, Nov 08, 2013 at 12:06:26PM -0600, Kumar Gala wrote:
>
> On Nov 8, 2013, at 10:57 AM, Jason Cooper wrote:
>
> > On Fri, Nov 08, 2013 at 10:13:19AM -0600, Kumar Gala wrote:
> >> On Nov 5, 2013, at 8:28 AM, Sebastian Hesselbarth wrote:
> > ...
> >>> .../devicetree/bindings/arm/marvell,berlin
On Friday, November 08, 2013 08:39:29 AM Andy Lutomirski wrote:
> On Fri, Nov 8, 2013 at 8:29 AM, Paul Moore wrote:
> > On Thursday, November 07, 2013 11:05:26 AM Andy Lutomirski wrote:
> >> On Thu, Nov 7, 2013 at 10:56 AM, Eric Paris wrote:
> >> > Isn't x32 similarly screwy? Does it work becaus
On Fri, Nov 08, 2013 at 12:17:30PM -0600, Kumar Gala wrote:
...
> I get the point, just not sure how else to sort the 800+ .dts{i} files
> that we have in the kernel tree right now.
Well, to start with, all #include'd files could go into a
arch/dts/include directory. That would clean things up a
On Fri, Nov 08, 2013 at 10:10:31AM +0200, Jani Nikula wrote:
> Fix CONFIG_ACPI=n build fail
>
> CC drivers/gpu/drm/i915/intel_opregion.o
> drivers/gpu/drm/i915/intel_opregion.c: In function ‘intel_opregion_setup’:
> drivers/gpu/drm/i915/intel_opregion.c:879:2: error: ‘asle_work’ undeclared
On 11/08/2013 12:23 AM, Magnus Damm wrote:
> On Thu, Nov 7, 2013 at 8:27 PM, Daniel Lezcano
> wrote:
>> On 11/06/2013 12:05 PM, Magnus Damm wrote:
>>> From: Magnus Damm
>>>
>>> Add Kconfig entries for CMT, MTU2, TMU and STI to
>>> drivers/clocksource/Kconfig. This will allow us to
>>> get rid of
Sorry.
I didn't have time to answer other emails, will try to do later.
And yes, yes, while_each_thread() should be fixed, still on my
TODO list... But just in case, whatever we do with while_each_thread()
we should also fix some users.
Until then,
On 11/08, Sameer Nanda wrote:
>
> @@ -412,13 +
201 - 300 of 699 matches
Mail list logo
