On Sat, Aug 11, 2012 at 07:26:38PM +0200, Sebastian Andrzej Siewior wrote:
> * Thierry Reding | 2012-08-08 14:07:37 [+0200]:
>
> >With that in place, the driver code can match on "intel,hpet" to catch
> >all implementations and use the more specific entries if quirks are
> >required for the specif
>
> Sorry, you cannot do this.
>
> You are adding a new lock and insert into a global list for
> pretty much every socket created, that will destroy performance.
I think there are no serious performance penalty in generally use.
Most frequently used types of sockets like tcp, udp, and unix are n
On Wed, Aug 8, 2012 at 5:19 AM, Vasily Kulikov wrote:
> Hi Kees,
>
> On Wed, Jul 25, 2012 at 17:29 -0700, Kees Cook wrote:
>> +/**
>> + * safe_hardlink_source - Check for safe hardlink conditions
>> + * @inode: the source inode to hardlink from
>> + *
>> + * Return false if at least one of the fol
rcu_dereference occurs in update section. Replacement by
rcu_dereference_protected in order to prevent lockdep
complaint.
Found by Linux Driver Verification project (linuxtesting.org)
Signed-off-by: Denis Efremov
---
drivers/net/macvtap.c |3 ++-
1 files changed, 2 insertions(+), 1 deletion
> Fix the following compiler warnings:
>
> - drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:2908:3: warning:
> comparison
>of distinct pointer types lacks a cast [enabled by default]
> - drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c:1709:7: warning: comparison
>of distinct pointer t
On Fri, 10 Aug 2012, Cyril Chemparathy wrote:
> On Keystone platforms, physical memory is entirely outside the 32-bit
> addressible range. Therefore, the (bank->start > ULONG_MAX) check below marks
> the entire system memory as highmem, and this causes unpleasentness all over.
>
> This patch eli
On Fri, 10 Aug 2012, Cyril Chemparathy wrote:
> This patch modifies the highmem sanity checking code to use physical addresses
> instead. This change eliminates the wrap-around problems associated with the
> original virtual address based checks, and this simplifies the code a bit.
>
> The one c
On Fri, 10 Aug 2012, Cyril Chemparathy wrote:
> This patch moves the TTBR1 offset calculation and the T1SZ calculation out
> of the TTB setup assembly code. This should not affect functionality in
> any way, but improves code readability as well as readability of subsequent
> patches in this seri
On Fri, 10 Aug 2012, Cyril Chemparathy wrote:
> This patch adds TTBR accessor macros, and modifies cpu_get_pgd() and
> the LPAE version of cpu_set_reserved_ttbr0() to use these instead.
>
> In the process, we also fix these functions to correctly handle cases
> where the physical address lies bey
On Fri, Aug 10, 2012 at 9:48 PM, Michal Hocko wrote:
> It's been compile tested because it only restores the previous code with
> a simple and obvious bug fix.
It helps more if you elaborate on such a simple and obvious bug and
enrich your change log accordingly?
--
To unsubscribe from this list
I also want to mention that I absolutely do not consider better lsof
support important at all.
So if you want to add this, it had to be exactly zero overhead and it
must not break anything that exists already. Your patch set violates
this on both counts.
--
To unsubscribe from this list: send th
Namjae Jeon writes:
> Use accessor function for msdos_dir_entry 'start'
Acked-by: OGAWA Hirofumi
Looks good. Thanks.
> Signed-off-by: Namjae Jeon
> Signed-off-by: Amit Sahrawat
> ---
> fs/fat/dir.c |6 ++
> 1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/fs/fat/dir
On Fri, 10 Aug 2012, Cyril Chemparathy wrote:
> This patch modifies the switch_mm() processor functions to use phys_addr_t.
> On LPAE systems, we now honor the upper 32-bits of the physical address that
> is being passed in, and program these into TTBR as expected.
>
> Signed-off-by: Cyril Chempa
Sorry, you cannot do this.
You are adding a new lock and insert into a global list for
pretty much every socket created, that will destroy performance.
You also cannnot add new fields to socket listing procfs files,
it will break existing application which depend upon the existing
exact layout o
Hi. Jan.
Would you check this patch also ?
Thanks.
2012/7/21, Ashish Sangwan :
> If s_lvid_bh is not freed and set to NULL before re-scanning partition
> with default block size, we might end up using wrong lvid in case
> s_lvid_bh is not updated in udf_load_logicalvolint during rescan.
>
> Sign
Hi Jan.
Would you check this patch if you return from vacation ?
Thanks.
2012/7/29, Namjae Jeon :
> From: Namjae Jeon
>
> While mapping logical blocks of a file to physical blocks on the partition,
> everytime UDF read file metadata from the begining which decrease
> preformance.
> The drawback
On Fri, 10 Aug 2012, Cyril Chemparathy wrote:
> From: Vitaly Andrianov
>
> This patch fixes the initrd setup code to use phys_addr_t instead of assuming
> 32-bit addressing. Without this we cannot boot on systems where initrd is
> located above the 4G physical address limit.
>
> Signed-off-by:
On Fri, 10 Aug 2012, Cyril Chemparathy wrote:
> This patch applies to PAGE_MASK, PMD_MASK, and PGDIR_MASK, where forcing
> unsigned long math truncates the mask at the 32-bits. This clearly does bad
> things on PAE systems.
>
> This patch fixes this problem by defining these masks as signed quan
Use accessor function for msdos_dir_entry 'start'
Signed-off-by: Namjae Jeon
Signed-off-by: Amit Sahrawat
---
fs/fat/dir.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/fs/fat/dir.c b/fs/fat/dir.c
index 7b1b9c1..2f3e66e 100644
--- a/fs/fat/dir.c
+++ b/fs/fat/dir.c
On Fri, 10 Aug 2012, Cyril Chemparathy wrote:
> This patch adds support for 64-bit physical addresses in virt_to_phys()
> patching. This does not do real 64-bit add/sub, but instead patches in the
> upper 32-bits of the phys_offset directly into the output of virt_to_phys.
>
> There is no corres
> > That function uses a global lock. fdatawait is quite common. This will
> > likely cause performance problems in IO workloads.
>
> OK, I should avoid it.
Maybe just RCU the hash table.
> > You need to get that lock out of the hot path somehow.
> >
> > Probably better to try to put the data
Fix the following compiler warnings:
- drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:2908:3: warning: comparison
of distinct pointer types lacks a cast [enabled by default]
- drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c:1709:7: warning: comparison
of distinct pointer types lacks a ca
On Fri, 10 Aug 2012, Cyril Chemparathy wrote:
> This patch fixes up the types used when converting back and forth between
> physical and virtual addresses.
>
> Signed-off-by: Vitaly Andrianov
> Signed-off-by: Cyril Chemparathy
Reviewed-by: Nicolas Pitre
> ---
> arch/arm/include/asm/memory.h
On Fri, 10 Aug 2012, Cyril Chemparathy wrote:
> This patch replaces the original physical offset patching implementation
> with one that uses the newly added patching framework. In the process, we now
> unconditionally initialize the __pv_phys_offset and __pv_offset globals in the
> head.S code.
On 12/08/12 14:10, Fengguang Wu wrote:
> On Sun, Aug 12, 2012 at 01:33:09PM +1200, Michael Cree wrote:
>> On 03/08/12 03:02, Fengguang Wu wrote:
>>> On Thu, Jul 26, 2012 at 10:06:41AM -0700, Tony Luck wrote:
On Tue, Jul 24, 2012 at 10:10 PM, James Bottomley
wrote:
>> Here is the line
On Fri, 10 Aug 2012, Cyril Chemparathy wrote:
> This patch adds basic sanity tests to ensure that the instruction patching
> results in valid instruction encodings. This is done by verifying the output
> of the patch process against a vector of assembler generated instructions at
> init time.
>
On Fri, 10 Aug 2012, Cyril Chemparathy wrote:
> The original phys_to_virt/virt_to_phys patching implementation relied on early
> patching prior to MMU initialization. On PAE systems running out of >4G
> address space, this would have entailed an additional round of patching after
> switching over
From: Mel Gorman
The following build error occurred during an alpha build:
net/core/sock.c:274:36: error: initializer element is not constant
Dave Anglin says:
> Here is the line in sock.i:
>
> struct static_key memalloc_socks = ((struct static_key) { .enabled =
> ((atomic_t) { (0) }) });
The
On Sun, Aug 12, 2012 at 01:33:09PM +1200, Michael Cree wrote:
> On 03/08/12 03:02, Fengguang Wu wrote:
> > On Thu, Jul 26, 2012 at 10:06:41AM -0700, Tony Luck wrote:
> >> On Tue, Jul 24, 2012 at 10:10 PM, James Bottomley
> >> wrote:
> Here is the line in sock.i:
>
> struct static_ke
Em 31-07-2012 17:20, Federico Vaga escreveu:
> I'm sorry for the email duplication, I press the wrong key on git-send email.
> Ignore these emails. Sorry
>
Ok, I'll mark those patches as "RFC" per your request.
Regards,
mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-ker
On 03/08/12 03:02, Fengguang Wu wrote:
> On Thu, Jul 26, 2012 at 10:06:41AM -0700, Tony Luck wrote:
>> On Tue, Jul 24, 2012 at 10:10 PM, James Bottomley
>> wrote:
Here is the line in sock.i:
struct static_key memalloc_socks = ((struct static_key) { .enabled =
((atomic_t) { (0)
From: Denis Efremov
Date: Sat, 11 Aug 2012 14:05:27 +0400
> - if (rcu_dereference(vlan->taps[i]) == q)
> + if (rcu_dereference_protected(vlan->taps[i],
> + lockdep_is_held(&macvtap_lock)) == q)
You must use the proper combination of TAB charact
On Sun, Aug 12, 2012 at 12:39:19AM +0200, Rafael J. Wysocki wrote:
> Hi,
>
> The usb-wwan driver triggers a NULL pointer dereference oops after resume
> from system suspend on my Toshiba Portege R500, but since that driver
> hasn't changed since v3.5 and it is only used by the option driver, I sup
> dirty pagecache error recoverable under some conditions. Consider that
> if there is a copy of the corrupted dirty pagecache on user buffer and
> you write() over the error page with the copy data, then we can ignore
> the effect of the error because no one consumes the corrupted data.
This soun
Hi,
The usb-wwan driver triggers a NULL pointer dereference oops after resume
from system suspend on my Toshiba Portege R500, but since that driver
hasn't changed since v3.5 and it is only used by the option driver, I suppose
that the latter is responsible for that.
This is a clear regression fro
On Saturday, August 11, 2012, Geert Uytterhoeven wrote:
> On Mon, Aug 6, 2012 at 1:49 AM, Rafael J. Wysocki wrote:
> > @@ -341,8 +346,19 @@ static int __devinit sh_mtu2_probe(struc
> > if (ret) {
> > kfree(p);
> > platform_set_drvdata(pdev, NULL);
> > +
Hi,
On Sat, Aug 11, 2012 at 04:15:06AM -0700, Andi Kleen wrote:
> Naoya Horiguchi writes:
>
> I'm sceptical on the patch, but here's my review.
Thank you for taking your time for the review.
> > - return -EHWPOISON when we access to the error-affected address with
> > read(), partial-pag
On Thu, 9 Aug 2012 18:14:30 +0800
wrote:
> + strcpy(netdev->name, "eth%d");
> + retval = register_netdev(netdev);
The strcpy is unnecessary, alloc_etherdev already sets that.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@
On Sat, Aug 11, 2012 at 2:22 PM, Daniel Vetter wrote:
>> >> +
>> >> +/**
>> >> + * dma_fence_wait - wait for a fence to be signaled
>> >> + *
>> >> + * @fence: [in]The fence to wait on
>> >> + * @intr:[in]if true, do an interruptible wait
>> >> + * @timeout: [in]absolute time for
Declaring raw protocols has its own proc entry.
Signed-off-by: Masatake YAMATO
---
net/ipv4/raw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/raw.c b/net/ipv4/raw.c
index ff0f071..3980a4a 100644
--- a/net/ipv4/raw.c
+++ b/net/ipv4/raw.c
@@ -901,6 +901,7 @@ struct proto raw_prot
Declaring rawv6 protocols has its own proc entry.
Signed-off-by: Masatake YAMATO
---
net/ipv6/raw.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/raw.c b/net/ipv6/raw.c
index ef0579d..62ac59f 100644
--- a/net/ipv6/raw.c
+++ b/net/ipv6/raw.c
@@ -1226,6 +1226,7 @@ struct proto rawv6
Declaring icmp protocols has its own proc entry.
Signed-off-by: Masatake YAMATO
---
net/ipv4/ping.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index 6232d47..c4bb504 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -748,6 +748,7 @@ struct proto pin
Declaring unix protocols has its own proc entry.
Signed-off-by: Masatake YAMATO
---
net/unix/af_unix.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index e4768c1..7f109e6 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -616,6 +616,7 @@ s
Declaring udpv6 protocols has its own proc entry.
Signed-off-by: Masatake YAMATO
---
net/ipv6/udp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/udp.c b/net/ipv6/udp.c
index 99d0077..1b28eaf 100644
--- a/net/ipv6/udp.c
+++ b/net/ipv6/udp.c
@@ -1537,6 +1537,7 @@ struct proto udpv6
Declaring packet protocols has its own proc entry.
Signed-off-by: Masatake YAMATO
---
net/packet/af_packet.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/packet/af_packet.c b/net/packet/af_packet.c
index ceaca7c..6a0e47c 100644
--- a/net/packet/af_packet.c
+++ b/net/packet/af_packet.c
Declaring tcp protocols has its own proc entry.
Signed-off-by: Masatake YAMATO
---
net/ipv4/tcp_ipv4.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/tcp_ipv4.c b/net/ipv4/tcp_ipv4.c
index c660d2c..6f36929 100644
--- a/net/ipv4/tcp_ipv4.c
+++ b/net/ipv4/tcp_ipv4.c
@@ -2635,6 +2635,
Declaring tcpv6 protocols has its own proc entry.
Signed-off-by: Masatake YAMATO
---
net/ipv6/tcp_ipv6.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c
index aa41b0e..741cb3b 100644
--- a/net/ipv6/tcp_ipv6.c
+++ b/net/ipv6/tcp_ipv6.c
@@ -2017,6 +201
Declaring udplite protocols has its own proc entry.
Signed-off-by: Masatake YAMATO
---
net/ipv4/udplite.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/udplite.c b/net/ipv4/udplite.c
index 2c46acd..14c9dec 100644
--- a/net/ipv4/udplite.c
+++ b/net/ipv4/udplite.c
@@ -62,6 +62,7 @@
Declaring ipx protocols has its own proc entry.
Signed-off-by: Masatake YAMATO
---
net/ipx/af_ipx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipx/af_ipx.c b/net/ipx/af_ipx.c
index dfd6faa..14be087 100644
--- a/net/ipx/af_ipx.c
+++ b/net/ipx/af_ipx.c
@@ -1345,6 +1345,7 @@ static str
Declaring udplitev6 protocols has its own proc entry.
Signed-off-by: Masatake YAMATO
---
net/ipv6/udplite.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv6/udplite.c b/net/ipv6/udplite.c
index 1d08e21..9013897 100644
--- a/net/ipv6/udplite.c
+++ b/net/ipv6/udplite.c
@@ -57,6 +57,7 @
Declaring netlink protocols has its own proc entry.
Signed-off-by: Masatake YAMATO
---
net/netlink/af_netlink.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c
index 5463969..9094be5 100644
--- a/net/netlink/af_netlink.c
+++ b/net/netlink/a
I've worked on improving lsof output on linux both lsof and linux
sides. Sometimes lsof cannot resolve socket descriptors and as the
result it prints them like:
[yamato@localhost]/tmp% sudo lsof | grep dbus | grep iden
dbus-daem 652 dbus6u sock ... 17812 can't identify
Declaring ax25 protocols has its own proc entry.
Signed-off-by: Masatake YAMATO
---
net/ax25/af_ax25.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ax25/af_ax25.c b/net/ax25/af_ax25.c
index 779095d..ff23c8a 100644
--- a/net/ax25/af_ax25.c
+++ b/net/ax25/af_ax25.c
@@ -803,6 +803,7 @@ s
Declaring udp protocols has its own proc entry.
Signed-off-by: Masatake YAMATO
---
net/ipv4/udp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/ipv4/udp.c b/net/ipv4/udp.c
index b4c3582..a16c4fa 100644
--- a/net/ipv4/udp.c
+++ b/net/ipv4/udp.c
@@ -1963,6 +1963,7 @@ struct proto udp_pro
Hello,
On Thu, Aug 09, 2012 at 04:23:09PM -0500, Jacob Shin wrote:
> Since we now call init_memory_mapping for each E820_RAM region in a
> loop, move cr4 writes out to setup_arch.
Shouldn't this happen before init_memory_mapping() is called multiple
times? Also, there seem to be other stuff whic
On Thu, Aug 09, 2012 at 04:23:07PM -0500, Jacob Shin wrote:
> Update later calls to init_memory_mapping to keep track of direct mapped
> pfn ranges.
so that
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.o
Hello,
On Thu, Aug 09, 2012 at 04:23:06PM -0500, Jacob Shin wrote:
> Current logic finds enough space to cover number of tables from 0 to end.
> Instead, we only need to find enough space to cover from mr[0].start to
> mr[nr_range].end.
>
> Signed-off-by: Jacob Shin
> ---
> arch/x86/mm/init.c |
On Thu, Aug 09, 2012 at 04:23:04PM -0500, Jacob Shin wrote:
> This is a revision of an earlier attempt, with suggestions and concernes
> from previous conversation (https://lkml.org/lkml/2011/12/16/486) taken
> into account.
>
> The following patchset creates direct mappings only for E820_RAM regi
Hello, Jacob.
On Thu, Aug 09, 2012 at 04:23:05PM -0500, Jacob Shin wrote:
> +struct range pfn_mapped[E820_X_MAX];
> +int nr_pfn_mapped;
Why aren't these __initdata? Are they gonna be used for other
purposes?
> +void add_pfn_range_mapped(unsigned long start_pfn, unsigned long end_pfn)
> +{
> +
On Fri, Aug 10, 2012 at 12:24:29PM +0200, Benoit Gschwind wrote:
>
> Hello,
>
> I confirm this patch work apply to kernel 3.6-rc1
Ok, I've picked this up for -fixes, with the commit message a bit
improved. Let's see whether this blows up anywhere.
-Daniel
--
Daniel Vetter
Mail: dan...@ffwll.ch
On Sat, Aug 11, 2012 at 06:00:46PM +0200, Maarten Lankhorst wrote:
> Op 11-08-12 17:14, Rob Clark schreef:
> > On Fri, Aug 10, 2012 at 3:29 PM, Daniel Vetter wrote:
> >>> +/**
> >>> + * dma_fence_signal - signal completion of a fence
> >>> + * @fence: the fence to signal
> >>> + *
> >>> + * All re
On Sat, Aug 11, 2012 at 11:34:22AM -0700, H. Peter Anvin wrote:
> On 08/11/2012 11:26 AM, Jerry Snitselaar wrote:
> >>
> >>This patch from Jacob Shin solves the problem, and seems like it might
> >>be a better solution.
> >>
> >>[PATCH 2/5] x86: find_early_table_space based on memory ranges that
>
On Sat, Aug 11, 2012 at 10:14:40AM -0500, Rob Clark wrote:
> On Fri, Aug 10, 2012 at 3:29 PM, Daniel Vetter wrote:
> > On Fri, Aug 10, 2012 at 04:57:52PM +0200, Maarten Lankhorst wrote:
> >> +
> >> + if (!ret) {
> >> + cb->base.flags = 0;
> >> + cb->base.func = __dma_fe
On Sat, Aug 11, 2012 at 08:56:42AM +0200, Takashi Iwai wrote:
> When you reopen the lid on a laptop with PCH, the panel suddenly goes
> blank sometimes. It seems because BLC_PWM_CPU_CTL register is cleared
> to zero when BLC_PWM_CPU_CTL2 and BLC_PWM_PCH_CTL1 registers are
> enabled.
>
> This patc
On 08/11/2012 11:34 AM, H. Peter Anvin wrote:
On 08/11/2012 11:26 AM, Jerry Snitselaar wrote:
This patch from Jacob Shin solves the problem, and seems like it might
be a better solution.
[PATCH 2/5] x86: find_early_table_space based on memory ranges that
are being mapped
https://lkml.org/lkml
On 08/09/2012 03:03 PM, Yinghai Lu wrote:
can you put those line in another function?
setup_arch is way too big now.
I agree with this ... Jacob, could you rev the patch?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
On 08/11/2012 11:26 AM, Jerry Snitselaar wrote:
This patch from Jacob Shin solves the problem, and seems like it might
be a better solution.
[PATCH 2/5] x86: find_early_table_space based on memory ranges that
are being mapped
https://lkml.org/lkml/2012/8/9/540
Actually, apply that series of
On Sat Aug 11 12, Jerry Snitselaar wrote:
> On Wed Jul 25 12, Takao Indoh wrote:
> > >Thanks for tracking this, Takao!
> > >
> > >I bet you are using x86_64 not x86 PAE? If so, could you try this patch
> > >https://patchwork.kernel.org/patch/1195751/
> > >? I already reviewed it.
> >
> > Great, I
Em Sat, Aug 11, 2012 at 10:47:45PM +0900, Namhyung Kim escreveu:
> Hi Arnaldo,
>
> Your current perf/core branch fails to build like this:
>
> $ make
> Makefile:494: No libunwind found. Please install libunwind >= 0.99
> CC perf.o
> make: *** No rule to make target `util/unwind.h', ne
Fengguang Wu writes:
> Hi Eric,
>
> The below warning shows up since commit
Thanks. I am believe the usage is actually correct but I will dig some
more and see what it takes to convince the tools of that.
Eric
>
> tree:
> git://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespac
On Wed Jul 25 12, Takao Indoh wrote:
> >Thanks for tracking this, Takao!
> >
> >I bet you are using x86_64 not x86 PAE? If so, could you try this patch
> >https://patchwork.kernel.org/patch/1195751/
> >? I already reviewed it.
>
> Great, I applied it and now kdump works. Thanks!
>
> Thanks,
> Tak
Hello,
I upgrade to each new kernel release and with 3.5.1 (from 3.4) I can no
longer mount my 60TB ext4 volume.
If I boot back to 3.4, it works fine.
Details here:
https://lkml.org/lkml/2012/8/10/205
Anything I can do besides testing each 3.5-rcX to find where the regression
lies?
Justin.
--
* Thierry Reding | 2012-08-08 14:07:37 [+0200]:
>With that in place, the driver code can match on "intel,hpet" to catch
>all implementations and use the more specific entries if quirks are
>required for the specific hardware.
from http://lkml.org/lkml/2011/2/16/350:
|"intel,ioapic" is probably t
Op 10-08-12 21:57, Daniel Vetter schreef:
> On Fri, Aug 10, 2012 at 04:57:58PM +0200, Maarten Lankhorst wrote:
>> This type of fence can be used with hardware synchronization for simple
>> hardware that can block execution until the condition
>> (dma_buf[offset] - value) >= 0 has been met.
>>
>> A
Hey,
Op 11-08-12 17:14, Rob Clark schreef:
> On Fri, Aug 10, 2012 at 3:29 PM, Daniel Vetter wrote:
>> On Fri, Aug 10, 2012 at 04:57:52PM +0200, Maarten Lankhorst wrote:
>>> A dma-fence can be attached to a buffer which is being filled or consumed
>>> by hw, to allow userspace to pass the buffer w
On Fri, Aug 10, 2012 at 2:32 PM, Daniel Vetter wrote:
> On Fri, Aug 10, 2012 at 04:57:43PM +0200, Maarten Lankhorst wrote:
>> Documentation says that code requiring dma-buf should add it to
>> select, so inline fallbacks are not going to be used. A link error
>> will make it obvious what went wron
On Fri, Aug 10, 2012 at 3:29 PM, Daniel Vetter wrote:
> On Fri, Aug 10, 2012 at 04:57:52PM +0200, Maarten Lankhorst wrote:
>> A dma-fence can be attached to a buffer which is being filled or consumed
>> by hw, to allow userspace to pass the buffer without waiting to another
>> device. For example
Hi Arnaldo,
Your current perf/core branch fails to build like this:
$ make
Makefile:494: No libunwind found. Please install libunwind >= 0.99
CC perf.o
make: *** No rule to make target `util/unwind.h', needed by
`builtin-annotate.o'. Stop.
$ ls util/unwind*
ls: cannot access
11.08.2012 15:20, Manfred Spraul пишет:
Hi Stanislav,
2012/8/10 Stanislav Kinsbursky :
This patch is required for checkpoint/restore in userspace.
IOW, c/r requires some way to get all pending IPC messages without deleting
them from the queue (checkpoint can fail and in this case tasks will be
2012-08-10 (금), 15:22 -0700, Cody P Schafer:
> Factors opening of certain sections & tracking certain elf info into an
> external structure.
>
> The goal here is to keep multiple elfs (and their looked up
> sections/indexes) around during the symbol generation process (in
> dso__load()).
>
> We n
On Tue, Aug 7, 2012 at 3:43 AM, Zhao Chenhui wrote:
> +int mpc85xx_pmc_set_wake(struct device *dev, bool enable)
> +{
> + int ret = 0;
> + struct device_node *clk_np;
> + const u32 *prop;
> + u32 pmcdr_mask;
> +
> + if (!pmc_regs) {
> + pr_err("%s: PMC
2012-08-10 (금), 15:22 -0700, Cody P Schafer:
> In kallsyms_parse() when calling process_symbol() (a callback argument
> to kallsyms_parse()), we pass start as both start & end (ie:
> start=start, end=start).
>
> In map__process_kallsym_symbol(), the length is calculated as 'end - start +
> 1',
>
From: Thomas Petazzoni
Signed-off-by: Thomas Petazzoni
---
Cc: Grant Likely
Cc: Rob Herring
Cc: Rob Landley
Cc: Russell King
Cc: Linus Walleij
Cc: Lior Amsalem
Cc: Andrew Lunn
Cc: Gregory CLEMENT
Cc: Ben Dooks
Cc: Sebastian Hesselbarth
Cc: Thomas Petazzoni
Cc: devicetree-disc...@lists
This patch adds a SoC specific pinctrl driver for Marvell Kirkwood SoCs
plus DT binding documentation. This driver will use the mvebu pinctrl
driver core.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Grant Likely
Cc: Rob Herring
Cc: Rob Landley
Cc: Russell King
Cc: Linus Walleij
Cc: Lior Ams
This patch adds a pinctrl driver core for Marvell SoCs plus DT
binding documentation. This core driver will be used by SoC family
specific drivers, i.e. Armada XP, Armada 370, Dove, Kirkwood, aso.
Signed-off-by: Sebastian Hesselbarth
Signed-off-by: Thomas Petazzoni
---
Cc: Grant Likely
Cc: Rob
From: Thomas Petazzoni
Now that we have a proper pinctrl driver for Marvell EBU platforms,
enable PINCTRL support in ARCH_MVEBU.
Signed-off-by: Thomas Petazzoni
---
Cc: Grant Likely
Cc: Rob Herring
Cc: Rob Landley
Cc: Russell King
Cc: Linus Walleij
Cc: Lior Amsalem
Cc: Andrew Lunn
Cc: Gr
From: Thomas Petazzoni
The Armada XP evaluation board is based on the MV78460 Armava XP
SoC. Now that we have separate .dtsi files for the three different
SoCs of the Armada XP family, use the appropriate one as include for
the Armada XP evaluation board .dts file.
Signed-off-by: Thomas Petazzon
From: Thomas Petazzoni
This pinctrl driver is not a full-blown pinctrl driver from scratch:
it relies on the common pinctrl-mvebu driver, which is used for all
Marvell EBU SoCs.
Signed-off-by: Thomas Petazzoni
---
Cc: Grant Likely
Cc: Rob Herring
Cc: Rob Landley
Cc: Russell King
Cc: Linus W
From: Thomas Petazzoni
This commits adds the necessary device tree information to define the
compatible property for the pinctrl driver instance of Armada 370 SoC.
Signed-off-by: Thomas Petazzoni
---
Cc: Grant Likely
Cc: Rob Herring
Cc: Rob Landley
Cc: Russell King
Cc: Linus Walleij
Cc: Li
From: Thomas Petazzoni
This commits adds the necessary device tree information to define the
compatible property for the pinctrl driver instance of Armada XP SoCs.
Until now, the device tree representation considered the Armada XP as
a single SoC. But in fact, there are three different SoCs in t
From: Thomas Petazzoni
This pinctrl driver is not a full-blown pinctrl driver from scratch:
it relies on the common pinctrl-mvebu driver, which is used for all
Marvell EBU SoCs.
Signed-off-by: Thomas Petazzoni
---
Cc: Grant Likely
Cc: Rob Herring
Cc: Rob Landley
Cc: Russell King
Cc: Linus W
From: Thomas Petazzoni
The Armada 370 and XP SoCs have configurable muxing for a certain
number of their pins, controlled through a pinctrl driver.
The 'compatible' property is defined in the SoC-specific .dtsi files,
since the compatible string identifies the number of pins and other
SoC-specif
This patch adds a SoC specific pinctrl driver for Marvell Dove SoCs
plus DT binding documentation. This driver will use the mvebu pinctrl
driver core.
Signed-off-by: Sebastian Hesselbarth
---
Cc: Grant Likely
Cc: Rob Herring
Cc: Rob Landley
Cc: Russell King
Cc: Linus Walleij
Cc: Lior Amsalem
This patch set adds a core pinctrl driver for Marvell MVEBU SoCs and
SoC specific stubs for Armada 370, Armada XP, Dove, and Kirkwood.
The SoC specific stubs use the pinctrl-mvebu core driver that handles
pinctrl API and register accesses for common pinctrl registers.
As especially Dove has some p
On Sat, Aug 11, 2012 at 12:23 AM, Nicholas A. Bellinger
wrote:
> Using a KVM guest with 32x vCPUs and 4G memory, the results for 4x
> random I/O now look like:
>
> workload | jobs | 25% write / 75% read | 75% write / 25% read
> -|--|--|--
On Fri, Aug 10, 2012 at 6:30 PM, Ohad Ben-Cohen wrote:
> This will solve all sort of open issues we have (or going to have soon):
>
> 1. dynamically-allocated address of the vrings can be communicated
> 2. vdev statuses can be communicated
> 3. virtio config space will finally become bi-directiona
On 09.08.2012 13:37, Felipe Balbi wrote:
Hi,
I have pushed a patch which I think solves this issue. Can you test ?
Hi,
my patch is unneeded since this is a threaded interrupt handler. And it
runs with
interrupt line masked globally on the controller(because of IRQF_ONESHOT).
And I think that
Hi Stanislav,
2012/8/10 Stanislav Kinsbursky :
> This patch is required for checkpoint/restore in userspace.
> IOW, c/r requires some way to get all pending IPC messages without deleting
> them from the queue (checkpoint can fail and in this case tasks will be
> resumed,
> so queue have to be val
11.08.2012 10:23, Pavel Emelyanov пишет:
On 08/11/2012 03:09 AM, H. Peter Anvin wrote:
On 08/10/2012 12:28 PM, Alan Cox wrote:
Explicitly for Linux yes - this is not generally true of the AF_UNIX
socket domain and even the permissions aspect isn't guaranteed to be
supported on some BSD environm
Naoya Horiguchi writes:
I'm sceptical on the patch, but here's my review.
> - return -EHWPOISON when we access to the error-affected address with
> read(), partial-page write(), fsync(),
Note that a lot of user space does not like new errnos (nothing in
strerror etc.). It's probably bette
1 - 100 of 141 matches
Mail list logo
