On 15/08/13 02:30, Joel Fernandes wrote:
> On 08/14/2013 06:12 PM, Joel Fernandes wrote:
>> This patch series is a rewrite of the DMA portion of omap-aes driver
>> and also adds support for PIO mode. Both these modes, give better
>> performance than before.
>>
>> Earlier, only a single SG was used
Alexey,
On Thu, Aug 15, 2013 at 12:57:19PM +1000, Alexey Kardashevskiy wrote:
>The current implementation of IOMMU on sPAPR does not use iommu_ops
>and therefore does not call IOMMU API's bus_set_iommu() which
>1) sets iommu_ops for a bus
>2) registers a bus notifier
>Instead, PCI devices are
The "di_size" variable comes from the disk and it's a signed 64 bit.
We check the upper limit but we should check for negative numbers as
well.
Signed-off-by: Dan Carpenter
diff --git a/fs/xfs/xfs_inode_fork.c b/fs/xfs/xfs_inode_fork.c
index 123971b..849fc70 100644
--- a/fs/xfs/xfs_inode_fork.c
The memcg_cache_params structure contains the common part and the union,
which represents two different types of data: one for root cashes and
another for child caches.
The size of child data is fixed. The size of the memcg_caches array is
calculated in runtime.
Currently the size of
Current early_pfn_to_nid() on arch that support memblock go
over memblock.memory one by one, so will take too many try
near the end.
We can use existing memblock_search to find the node id for
given pfn, that could save some time on bigger system that
have many entries memblock.memory array.
On 08/15/2013 05:54 AM, Naoya Horiguchi wrote:
> On Thu, Aug 08, 2013 at 06:16:17PM +0800, Tang Chen wrote:
>> --- a/mm/memblock.c
>> +++ b/mm/memblock.c
> ...
>> @@ -719,6 +723,10 @@ void __init_memblock __next_free_mem_range_rev(u64
>> *idx, int nid,
>> if (nid != MAX_NUMNODES&&
On Tue, Aug 13, 2013 at 11:43:30AM -0700, James Bottomley wrote:
> Can we actually boot a 32 bit kernel on an EFI64 system? The last time
> I tried on my Secure Boot SDV it wouldn't work; the problem is getting
> someting in the transfer of control path to boot the processor back to
> 32 bit
On 08/14/2013 07:47 PM, Joe Perches wrote:
> On Wed, 2013-08-14 at 18:40 -0500, Joel Fernandes wrote:
>> On 08/14/2013 06:29 PM, Joe Perches wrote:
>>> On Wed, 2013-08-14 at 18:12 -0500, Joel Fernandes wrote:
When DEBUG is enabled, these macros can be used to print variables
in integer
On Sat, Aug 10, 2013 at 08:42:58AM -0700, Linus Torvalds wrote:
> On Fri, Aug 9, 2013 at 4:04 PM, Andi Kleen wrote:
> > From: Andi Kleen
> >
> > Move the cond_resched() check for CONFIG_PREEMPT_VOLUNTARY into
> > the low level copy_*_user code. This avoids some code bloat and
> > makes check
On Thu, Aug 15, 2013 at 03:38:47AM +, Caizhiyong wrote:
> > -Original Message-
> > From: Brian Norris [mailto:computersforpe...@gmail.com]
> > Sent: Thursday, August 15, 2013 8:12 AM
> > To: Andrew Morton
> > Cc: Caizhiyong; Karel Zak; linux-...@lists.infradead.org;
> >
On Wed, Aug 14, 2013 at 9:32 PM, Eric W. Biederman
wrote:
>> The solution is also theoretically simple: mounts in unpriv namespaces
>> are marked "volatile" and are dissolved on an unlink type operation.
>>
>> Such volatile mounts would be useful in general too.
>
> Agreed.
>
> This is a problem
Hey Christoph,
On Wed, Aug 14, 2013 at 04:58:36PM +, Christoph Lameter wrote:
> On Thu, 15 Aug 2013, Minchan Kim wrote:
>
> > When I look API of mmu_notifier, it has mm_struct so I guess it works
> > for only user process. Right?
>
> Correct. A process must have mapped the pages. If you can
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/include/debug/highbank.S between commits df917c8c18b4 ("ARM:
debug: provide PL01x debug uart phys/virt address configuration options")
and 5e33abe38413 ("ARM: debug: move PL01X debug include into
On Wed, Aug 14, 2013 at 7:10 PM, Dave Chinner wrote:
> On Wed, Aug 14, 2013 at 09:11:01PM -0400, Theodore Ts'o wrote:
>> On Wed, Aug 14, 2013 at 04:38:12PM -0700, Andy Lutomirski wrote:
>> > > It would be better to write zeros to it, so we aren't measuring the
>> > > cost of the
On Wed, Aug 14, 2013 at 07:24:01PM -0700, Andi Kleen wrote:
> > And FWIW, it's no secret that XFS has more per-operation overhead
> > than ext4 through the write path when it comes to allocation, so
> > it's no surprise that on a workload that is highly dependent on
> > allocation overhead that
On Thu, Aug 15, 2013 at 01:17:55PM +0900, Minchan Kim wrote:
> Hello,
>
> On Thu, Aug 15, 2013 at 11:46:07AM +0800, Xishi Qiu wrote:
> > On 2013/8/15 10:44, Minchan Kim wrote:
> >
> > > Hi Xishi,
> > >
> > > On Thu, Aug 15, 2013 at 10:32:50AM +0800, Xishi Qiu wrote:
> > >> On 2013/8/15 2:00,
Hello,
On Thu, Aug 15, 2013 at 11:46:07AM +0800, Xishi Qiu wrote:
> On 2013/8/15 10:44, Minchan Kim wrote:
>
> > Hi Xishi,
> >
> > On Thu, Aug 15, 2013 at 10:32:50AM +0800, Xishi Qiu wrote:
> >> On 2013/8/15 2:00, Mel Gorman wrote:
> >>
> > Even if the page is still page buddy, there is no
> -Original Message-
> From: Andy Lutomirski [mailto:l...@amacapital.net]
> Sent: Thursday, August 15, 2013 03:15
> To: Winkler, Tomas; linux-kernel@vger.kernel.org
> Subject: mei oopses at startup if it's built-in (3.11-rc5)
>
> It blows up early enough that it's awkward to get the
This patch implements fallocate and punch hole support for Ceph kernel client.
Signed-off-by: Li Wang
Signed-off-by: Yunchuan Wen
---
Against v3:
Passed the fsx test from xfstests.
Truncate rather than delete the first object. Thanks go to Sage and Zheng for
the explanation.
Silence the OSD
On 2013/8/15 10:44, Minchan Kim wrote:
> Hi Xishi,
>
> On Thu, Aug 15, 2013 at 10:32:50AM +0800, Xishi Qiu wrote:
>> On 2013/8/15 2:00, Mel Gorman wrote:
>>
> Even if the page is still page buddy, there is no guarantee that it's
> the same page order as the first read. It could have be
On 08/15/2013 11:27 AM, Tejun Heo wrote:
Hello, Tang.
On Thu, Aug 15, 2013 at 11:23:19AM +0800, Tang Chen wrote:
Furthermore, we don't need to check "if (this_end< size)" actually. Without
this confusing check, we only waste some loops. So this patch removes the
check.
Signed-off-by: Tang
> -Original Message-
> From: Brian Norris [mailto:computersforpe...@gmail.com]
> Sent: Thursday, August 15, 2013 8:12 AM
> To: Andrew Morton
> Cc: Caizhiyong; Karel Zak; linux-...@lists.infradead.org;
> linux-kernel@vger.kernel.org; Wanglin (Albert); Artem Bityutskiy; Shmulik
> Ladkani;
>
On Thu, 15 Aug 2013 11:32:10 +0930
Rusty Russell wrote:
> Steven Rostedt writes:
> > But the thing about this that bothers me is that there's no way to say,
> > "Enable all tracepoints in this module on load". I would like a way to
> > do that, but I don't know of a way to do that without
2013/8/15 Guenter Roeck :
> On 08/14/2013 02:11 AM, Julia Lawall wrote:
>>
>> From: Julia Lawall
>>
>> Remove unneeded error handling on the result of a call to
>> platform_get_resource when the value is passed to devm_ioremap_resource.
>>
>> A simplified version of the semantic patch that makes
Hello, Tang.
On Thu, Aug 15, 2013 at 11:23:19AM +0800, Tang Chen wrote:
> Furthermore, we don't need to check "if (this_end < size)" actually. Without
> this confusing check, we only waste some loops. So this patch removes the
> check.
>
> Signed-off-by: Tang Chen
> ---
> mm/memblock.c |3
In memblock_find_in_range_node(), it has the following check at line 117 and
118:
113 for_each_free_mem_range_reverse(i, nid, _start, _end,
NULL) {
114 this_start = clamp(this_start, start, end);
115 this_end = clamp(this_end, start, end);
116
117
Steven Rostedt writes:
> But the thing about this that bothers me is that there's no way to say,
> "Enable all tracepoints in this module on load". I would like a way to
> do that, but I don't know of a way to do that without modifying the
> module code. Have any ideas? Basically, I would love to
On 08/14/2013 02:11 AM, Julia Lawall wrote:
From: Julia Lawall
Remove unneeded error handling on the result of a call to
platform_get_resource when the value is passed to devm_ioremap_resource.
Move the call to platform_get_resource adjacent to the call to
devm_ioremap_resource to make the
On 08/14/2013 02:11 AM, Julia Lawall wrote:
From: Julia Lawall
Remove unneeded error handling on the result of a call to
platform_get_resource when the value is passed to devm_ioremap_resource.
A simplified version of the semantic patch that makes this change is as
follows:
On 08/14/2013 02:11 AM, Julia Lawall wrote:
From: Julia Lawall
Remove unneeded error handling on the result of a call to
platform_get_resource when the value is passed to devm_ioremap_resource.
A simplified version of the semantic patch that makes this change is as
follows:
The current implementation of IOMMU on sPAPR does not use iommu_ops
and therefore does not call IOMMU API's bus_set_iommu() which
1) sets iommu_ops for a bus
2) registers a bus notifier
Instead, PCI devices are added to IOMMU groups from
subsys_initcall_sync(tce_iommu_init) which does basically
Hi Xishi,
On Thu, Aug 15, 2013 at 10:32:50AM +0800, Xishi Qiu wrote:
> On 2013/8/15 2:00, Mel Gorman wrote:
>
> >>> Even if the page is still page buddy, there is no guarantee that it's
> >>> the same page order as the first read. It could have be currently
> >>> merging with adjacent buddies
On 2013/8/15 2:00, Mel Gorman wrote:
>>> Even if the page is still page buddy, there is no guarantee that it's
>>> the same page order as the first read. It could have be currently
>>> merging with adjacent buddies for example. There is also a really
>>> small race that a page was freed,
As an experiment this year, the Linux Kernel Summit Program Committee
would like to put out a call for hobbyists. This year, we have up to
three places to give to people who do Linux Kernel development as a
hobby rather than a profession (Our definition of "hobbyist" is anyone
who doesn't get
> And FWIW, it's no secret that XFS has more per-operation overhead
> than ext4 through the write path when it comes to allocation, so
> it's no surprise that on a workload that is highly dependent on
> allocation overhead that ext4 is a bit faster
This cannot explain a worse scaling curve
On Wed, Aug 14, 2013 at 09:44:19PM -0400, KOSAKI Motohiro wrote:
> >This is doubly idiotic because this is all early boot. Most users
> >don't even have a way to access the debug info if the machine crashes
> >that early. Developement convenience is something that we consider
> >too but,
On Wed, Aug 14, 2013 at 04:52:53PM -0500, Seth Jennings wrote:
> On Wed, Aug 14, 2013 at 02:37:26PM -0700, Yinghai Lu wrote:
> > On Wed, Aug 14, 2013 at 1:35 PM, Greg Kroah-Hartman
> > wrote:
> > > On Wed, Aug 14, 2013 at 01:05:33PM -0700, Dave Hansen wrote:
> > >> On 08/14/2013 12:43 PM, Greg
On Wed, Aug 14, 2013 at 09:11:01PM -0400, Theodore Ts'o wrote:
> On Wed, Aug 14, 2013 at 04:38:12PM -0700, Andy Lutomirski wrote:
> > > It would be better to write zeros to it, so we aren't measuring the
> > > cost of the unwritten->written conversion.
> >
> > At the risk of beating a dead horse,
On 14/08/2013 05:02, Pali Rohár wrote:
On Tuesday 13 August 2013 15:55:28 Martin Peres wrote:
On 13/08/2013 09:53, Pali Rohár wrote:
On utorok, 13. augusta 2013 15:32:45 CEST, Martin Peres
wrote:
On 13/08/2013 09:23, Pali Rohár wrote:
On Tuesday 13 August 2013 09:01:19 Martin Peres wrote:
From: Oleg Nesterov
The next patch tries to avoid the costly perf_trace_buf_* calls
when possible but there is a problem. We can only do this if
__task == NULL, perf_tp_event(task != NULL) has the additional
code for this case.
Unfortunately, TP_perf_assign/__perf_xxx which changes the default
From: Oleg Nesterov
To simplify the review of the next patches:
1. We are going to reimplent __perf_task/counter and embedd them
into TP_ARGS(). expand TRACE_EVENT(sched_stat_runtime) into
DECLARE_EVENT_CLASS() + DEFINE_EVENT(), this way they can use
different TP_ARGS's.
2. Change
Ingo,
These three patches from Oleg are more perf related, but they
are based on some of the updates that Oleg did that are in 3.11-rc5.
I based this work off of v3.11-rc5 as it seems that tip/perf/core is
still based on 3.11-rc1. You may want to merge Linus's 3.11-rc5 before
pulling this.
All
From: Oleg Nesterov
perf_trace_buf_prepare() + perf_trace_buf_submit(task => NULL)
make no sense if hlist_empty(head). Change perf_trace_##call()
to check ->perf_events beforehand and do nothing if it is empty.
This removes the overhead for tasks without events associated
with them. For
On Tue, Aug 6, 2013 at 8:06 PM, Xiaotian Feng wrote:
> If doms_new is NULL, partition_sched_domains() will reset ndoms_cur
> to 0, and free old sched domains with free_sched_domains(doms_cur, ndoms_cur).
> As ndoms_cur is 0, the cpumask will not be freed.
>
> Signed-off-by: Xiaotian Feng
> Cc:
On 2013/8/15 2:43, Oleg Nesterov wrote:
> On 08/14, Rui Xiang wrote:
>>
>> On 2013/8/14 13:06, Andy Lutomirski wrote:
>>> On Tue, Aug 13, 2013 at 10:04 PM, Rui Xiang wrote:
The level of init_user_ns shoule be 1.
>>>
>>> What's wrong with zero?
>>>
>>
>> No problem. It is just consistent with
On Wed, Aug 14, 2013 at 09:38:12PM -0400, KOSAKI Motohiro wrote:
> As you think makes no sense, I also think your position makes no sense. So,
> please
> stop emotional word. That doesn't help discussion progress.
Would you then please stop making nonsense assertions like "the
fundamental rule
(8/14/13 9:33 PM), Tejun Heo wrote:
On Wed, Aug 14, 2013 at 09:21:33PM -0400, Tejun Heo wrote:
Secondly, memory hotplug is now maintained I and kamezawa-san. Then, I much
likely
have a chance to get a hotplug related bug report. For protecting my life, I
don't
want get a false bug claim.
On Wed, 14 Aug 2013 15:28:27 +0200
Jan Kara wrote:
> A CPU can be caught in console_unlock() for a long time (tens of seconds
> are reported by our customers) when other CPUs are using printk heavily
> and serial console makes printing slow. Despite serial console drivers
> are calling
(8/14/13 9:21 PM), Tejun Heo wrote:
Hello, KOSAKI.
On Wed, Aug 14, 2013 at 09:08:22PM -0400, KOSAKI Motohiro wrote:
...
a fallback. Bogus and misguided fallback give a user false relief and they don't
notice their mistake quickly. The answer is, there is the fundamental rule.
We always said,
On Wed, Aug 14, 2013 at 09:21:33PM -0400, Tejun Heo wrote:
> > Secondly, memory hotplug is now maintained I and kamezawa-san. Then, I much
> > likely
> > have a chance to get a hotplug related bug report. For protecting my life,
> > I don't
> > want get a false bug claim. Then, I wouldn't like
>> +* Marvell 88PM800 Power Management IC
>> +
>> +Required parent device properties:
>> +- compatible : "marvell,88pm800"
>> +- reg : the I2C slave address for the 88pm800 chip
>> +- interrupts : IRQ line for the 88pm800 chip
>> +- interrupt-controller: describes the 88pm800 as an interrupt
Hello, KOSAKI.
On Wed, Aug 14, 2013 at 09:08:22PM -0400, KOSAKI Motohiro wrote:
...
> a fallback. Bogus and misguided fallback give a user false relief and they
> don't
> notice their mistake quickly. The answer is, there is the fundamental rule.
> We always said, "measure your system carefully,
(8/12/13 3:34 PM), Toshi Kani wrote:
> lock_device_hotplug() serializes hotplug & online/offline operations.
> The lock is held in common sysfs online/offline interfaces and ACPI
> hotplug code paths.
>
> try_offline_node() off-lines a node if all memory sections and cpus
> are removed on the
On Wed, Aug 14, 2013 at 04:41:00PM -0700, Andrew Morton wrote:
> On Fri, 9 Aug 2013 01:21:36 -0400 Naoya Horiguchi
> wrote:
>
> > +static void check_hugetlb_pmd_range(struct vm_area_struct *vma, pmd_t *pmd,
> > + const nodemask_t *nodes, unsigned long flags,
> > +
On Wed, Aug 14, 2013 at 04:38:12PM -0700, Andy Lutomirski wrote:
> > It would be better to write zeros to it, so we aren't measuring the
> > cost of the unwritten->written conversion.
>
> At the risk of beating a dead horse, how hard would it be to defer
> this part until writeback?
Part of the
(8/14/13 5:36 PM), Tejun Heo wrote:
> On Wed, Aug 14, 2013 at 05:17:23PM -0400, KOSAKI Motohiro wrote:
>> You haven't explain practical benefit of your opinion. As far as users have
>> no benefit, I'm never agree. Sorry.
>
> Umm... how about being more robust and actually useable to begin with?
>
This patch implements fallocate and punch hole support for Ceph kernel client.
Signed-off-by: Li Wang
Signed-off-by: Yunchuan Wen
---
Passed the fsx test from xfstests.
Truncate rather than delete the first object. Thanks go to Sage and Zheng for
the explanation.
---
fs/ceph/file.c|
On 2013-8-14 19:27, Catalin Marinas wrote:
> On Mon, Jul 29, 2013 at 10:54:01AM +0100, Will Deacon wrote:
>> On Mon, Jul 29, 2013 at 10:46:06AM +0100, Vincent Guittot wrote:
>>> On 27 July 2013 12:42, Hanjun Guo wrote:
Power aware scheduling needs the cpu topology information to improve the
On Wed, 2013-08-14 at 18:40 -0500, Joel Fernandes wrote:
> On 08/14/2013 06:29 PM, Joe Perches wrote:
> > On Wed, 2013-08-14 at 18:12 -0500, Joel Fernandes wrote:
> >> When DEBUG is enabled, these macros can be used to print variables
> >> in integer and hex format, and clearly display which
After commit 9bdac91424075("sparsemem: Put mem map for one node together."),
vmemmap for one node will be allocated together, its logic is similiar as
memory allocation for pageblock flags. This patch introduce
alloc_usemap_and_memmap
to extract the same logic of memory alloction for pageblock
On Wed, 14 Aug 2013 17:11:51 -0700 Brian Norris
wrote:
> On Wed, Aug 14, 2013 at 3:57 PM, Andrew Morton
> wrote:
> > On Tue, 13 Aug 2013 06:02:17 + Caizhiyong wrote:
> >
> >> move the command line parser to a separate module, and change it into
> >> library-style code.
> >>
> >>
preallocate_pmds will continue to preallocate pmds even if failure
occurrence, and then free all the preallocate pmds if there is
failure, this patch fix it by stop preallocate if failure occurrence
and go to free path.
Signed-off-by: Wanpeng Li
---
arch/x86/mm/pgtable.c | 4 +++-
1 file
Use wrapper function get_vm_area_size to calculate size of vm area.
Signed-off-by: Wanpeng Li
---
mm/vmalloc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c
index 93d3182..553368c 100644
--- a/mm/vmalloc.c
+++ b/mm/vmalloc.c
@@ -1553,7 +1553,7
It's not used globally and could be static.
Signed-off-by: Wanpeng Li
---
fs/fs-writeback.c | 2 +-
include/linux/writeback.h | 2 --
2 files changed, 1 insertion(+), 3 deletions(-)
diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c
index 68851ff..a75951c 100644
--- a/fs/fs-writeback.c
On Wed, Aug 14, 2013 at 10:10:07AM -0700, Dave Hansen wrote:
> We talked a little about this issue in this thread:
>
> http://marc.info/?l=linux-mm=137573185419275=2
>
> but I figured I'd follow up with a full comparison. ext4 is about 20%
> slower in handling write page faults than ext3.
Hello, Kent.
On Wed, Aug 14, 2013 at 05:04:27PM -0700, Kent Overstreet wrote:
> I was just telling you how I felt :) Regardless of that, IMO what I've
> got now is superior to any radix tree based approach for what ida/idr
> are supposed to do. I could of course be wrong, but I'm not convinced...
Em Wed, 14 Aug 2013 16:27:06 +0530
"Naveen N. Rao" escreveu:
> On 08/13/2013 11:28 PM, Borislav Petkov wrote:
> > On Tue, Aug 13, 2013 at 11:02:08PM +0530, Naveen N. Rao wrote:
> >> If I'm not mistaken, even for systems that have EDAC drivers, it looks
> >> to me like EDAC can't really decode to
On Thu, Aug 15, 2013 at 12:17 AM, Minchan Kim wrote:
> Hi Luigi,
>
> On Wed, Aug 14, 2013 at 08:53:31AM -0700, Luigi Semenzato wrote:
>> During earlier discussions of zswap there was a plan to make it work
>> with zsmalloc as an option instead of zbud. Does zbud work for
>
> AFAIR, it was not an
Em Wed, 14 Aug 2013 16:17:26 +0530
"Naveen N. Rao" escreveu:
> On 08/13/2013 11:09 PM, Luck, Tony wrote:
> >> In the meantime, like Boris suggests, I think we can have a different
> >> trace event for raw APEI reports - userspace can use it as it pleases.
> >>
> >> Once ghes_edac gets better,
It blows up early enough that it's awkward to get the whole oops, but
it's in the probe function. If it's a module, I get instead:
[ 73.401679] mei_me :00:16.0: Device doesn't have valid ME Interface
[ 73.401684] mei_me :00:16.0: initialization failed.
Let me know if I should debug
On Wed, Aug 14, 2013 at 3:57 PM, Andrew Morton
wrote:
> On Tue, 13 Aug 2013 06:02:17 + Caizhiyong wrote:
>
>> move the command line parser to a separate module, and change it into
>> library-style code.
>>
>> reference: https://lkml.org/lkml/2013/8/6/550
The most recent patch is an addendum
Em Wed, 14 Aug 2013 07:43:22 +0200
Borislav Petkov escreveu:
> On Tue, Aug 13, 2013 at 08:13:56PM +, Luck, Tony wrote:
> > Generic tracepoints are architected to be able to fire at very high
> > rates and log huge amounts of information. So we'd need something
> > special to say just log
On Tue, Aug 13, 2013 at 07:59:47PM -0400, Tejun Heo wrote:
> Hey, Kent.
>
> On Tue, Aug 13, 2013 at 04:51:33PM -0700, Kent Overstreet wrote:
> > Should probably be almost as good, yeah... in theory, but the space
> > efficiency still isn't going to be as good, and it'll probably be more
> >
Em Tue, 13 Aug 2013 23:02:08 +0530
"Naveen N. Rao" escreveu:
> On 08/13/2013 06:12 PM, Borislav Petkov wrote:
> > On Tue, Aug 13, 2013 at 04:51:33PM +0530, Naveen N. Rao wrote:
> >> You're right - my trace point makes all the data provided by apei
> >> as-is to userspace. However, ghes_edac
On Wed, Aug 14, 2013 at 08:16:56PM +, Paul Zimmerman wrote:
> Mark's original complaint about USB was this:
>
> > the device). The hub needs to be "plugged" into the SoC after the SoC
> > USB controller has started with some GPIOs so we need to tell the system
> > that the hub exists and
Em Tue, 13 Aug 2013 22:47:36 +0530
"Naveen N. Rao" escreveu:
> On 08/13/2013 06:11 PM, Mauro Carvalho Chehab wrote:
> > Em Tue, 13 Aug 2013 17:11:18 +0530
> > "Naveen N. Rao" escreveu:
> >
> >> On 08/12/2013 08:14 PM, Mauro Carvalho Chehab wrote:
> But, this only seems to expose the APEI
On Wed, Aug 14, 2013 at 03:39:20PM -0400, Alan Stern wrote:
> I don't see the point of all this. Obviously the device can't be used
> until it physically appears on the bus. What benefit do you get from
> registering it and making it available to userspace before that?
Two things. One is that
Em Tue, 13 Aug 2013 22:25:58 +0530
"Naveen N. Rao" escreveu:
(sorry for a late answer, I had to do a small travel yesterday)
> On 08/13/2013 05:51 PM, Mauro Carvalho Chehab wrote:
> > Em Tue, 13 Aug 2013 17:06:14 +0530
> > "Naveen N. Rao" escreveu:
> >
> >> On 08/12/2013 11:26 PM, Borislav
On Wednesday, August 14, 2013 02:31:45 PM Seth Jennings wrote:
> Large memory systems (~1TB or more) experience boot delays on the order
> of minutes due to the initializing the memory configuration part of
> sysfs at /sys/devices/system/memory/.
>
> ppc64 has a normal memory block size of 256M
On Wed, 2013-08-14 at 16:45 -0700, Andrew Morton wrote:
> On Wed, 14 Aug 2013 17:34:02 -0600 Toshi Kani wrote:
>
> > > Printing a u64 is problematic. Here you assume that u64 is implemented
> > > as unsigned long long. But it can be implemented as unsigned long, by
> > > architectures which
On Wed, 14 Aug 2013 17:34:02 -0600 Toshi Kani wrote:
> > Printing a u64 is problematic. Here you assume that u64 is implemented
> > as unsigned long long. But it can be implemented as unsigned long, by
> > architectures which use include/asm-generic/int-l64.h. Such an
> > architecture will
On 08/14/2013 06:29 PM, Joe Perches wrote:
> On Wed, 2013-08-14 at 18:12 -0500, Joel Fernandes wrote:
>> When DEBUG is enabled, these macros can be used to print variables
>> in integer and hex format, and clearly display which registers,
>> offsets and values are being read/written , including
On Fri, 9 Aug 2013 01:21:36 -0400 Naoya Horiguchi
wrote:
> +static void check_hugetlb_pmd_range(struct vm_area_struct *vma, pmd_t *pmd,
> + const nodemask_t *nodes, unsigned long flags,
> + void *private)
> +{
> +#ifdef CONFIG_HUGETLB_PAGE
> +
On Fri, 9 Aug 2013 01:21:33 -0400 Naoya Horiguchi
wrote:
> Here is the 5th version of hugepage migration patchset.
> Changes in this version are as follows:
> - removed putback_active_hugepages() as a cleanup (1/9)
> - added code to check movability of a given hugepage (8/9)
> - set GFP
On Wed, Aug 14, 2013 at 4:06 PM, Theodore Ts'o wrote:
> On Wed, Aug 14, 2013 at 01:50:02PM -0700, Dave Hansen wrote:
>>
>> Would a plain old fallocate() do the trick, or does it actually need
>> zeros written to it?
>
> It would be better to write zeros to it, so we aren't measuring the
> cost of
On Wed, 2013-08-14 at 15:09 -0700, Andrew Morton wrote:
> On Sat, 10 Aug 2013 13:17:32 -0600 Toshi Kani wrote:
>
> > add_memory() and remove_memory() can only handle a memory range aligned
> > with section. There are problems when an unaligned range is added and
> > then deleted as follows:
> >
linux-omap, linux-arm-list should also be CCed, Benoit needs to be
addressed for allowing him to merge,
I have not done a proper schematics Vs data manual review yet
(apologies on that), but, a couple of comments:
On 08/13/2013 12:42 AM, Keerthy wrote:
> The Patch adds nodes for TPS659038 PMIC
On 08/14/2013 06:12 PM, Joel Fernandes wrote:
> This patch series is a rewrite of the DMA portion of omap-aes driver
> and also adds support for PIO mode. Both these modes, give better
> performance than before.
>
> Earlier, only a single SG was used for DMA purpose, and the SG-list
> passed from
On Wed, 2013-08-14 at 18:12 -0500, Joel Fernandes wrote:
> When DEBUG is enabled, these macros can be used to print variables
> in integer and hex format, and clearly display which registers,
> offsets and values are being read/written , including printing the
> names of the offsets and their
On Wed, Aug 14, 2013 at 12:47:44PM -0700, Greg KH wrote:
> On Wed, Aug 14, 2013 at 08:39:50PM +0100, Mark Brown wrote:
> > That resource is the USB bus I think (I suspect the issue is that the
> > fact that power is always present confuses the USB enumeration protocol
> > if the device gets
On Fri, 9 Aug 2013 18:26:18 +0900 Joonsoo Kim wrote:
> Without a hugetlb_instantiation_mutex, if parallel fault occur, we can
> fail to allocate a hugepage, because many threads dequeue a hugepage
> to handle a fault of same address. This makes reserved pool shortage
> just for a little while
On Wed, Aug 14, 2013 at 2:52 PM, Seth Jennings
wrote:
> On Wed, Aug 14, 2013 at 02:37:26PM -0700, Yinghai Lu wrote:
> If I am understanding you correctly, you are suggesting we make the block size
> a boot time tunable. It can't be a runtime tunable since the memory blocks
> are
> currently
When DEBUG is enabled, these macros can be used to print variables
in integer and hex format, and clearly display which registers,
offsets and values are being read/written , including printing the
names of the offsets and their values.
Signed-off-by: Joel Fernandes
---
We initialize the scatter gather walk lists needed for PIO mode
and avoid all DMA paths such as mapping/unmapping buffers by
checking for the pio_only flag.
Signed-off-by: Joel Fernandes
---
drivers/crypto/omap-aes.c | 43 ++-
1 file changed, 30
Add IRQ information to pdata and helper macros. These are
required for PIO-mode support.
Signed-off-by: Joel Fernandes
---
drivers/crypto/omap-aes.c |8
1 file changed, 8 insertions(+)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index 71da52b..c057eac 100644
In cases where requesting for DMA channels fails for some reason, or channel
numbers are not provided in DT or platform data, we switch to PIO-only mode
also checking if platform provides IRQ numbers and interrupt register offsets
in DT and platform data. All dma-only paths are avoided in this
In early version of this driver, assumptions were made such as
DMA layer requires contiguous buffers etc. Due to this, new buffers
were allocated, mapped and used for DMA. These assumptions are no
longer true and DMAEngine scatter-gather DMA doesn't have such
requirements. We simply the DMA
Earlier functions that did a similar sync are replaced by
the dma_sync_sg_* which can operate on entire SG list.
Signed-off-by: Joel Fernandes
---
drivers/crypto/omap-aes.c |4
1 file changed, 4 insertions(+)
diff --git a/drivers/crypto/omap-aes.c b/drivers/crypto/omap-aes.c
index
We add an IRQ handler that implements a state-machine for PIO-mode
and data structures for walking the scatter-gather list. The IRQ handler
is called in succession both when data is available to read or next
data can be sent for processing. This process continues till the entire
in/out SG lists
Crypto layer only passes nbytes but number of SG elements is needed
for mapping/unmapping SGs at one time using dma_map* API and also
needed to pass in for dmaengine prep function.
We call function added to scatterwalk for this purpose in omap_aes_handle_queue
to populate the values which are
1 - 100 of 1754 matches
Mail list logo
