Herbert,
Currently the CRC-T10DIF checksum is computed using a generic table lookup
algorithm. By switching the checksum to PCLMULQDQ based computation,
we can speedup the computation by 8x for checksumming 512 bytes and
even more for larger buffer size. This will improve performance of SCSI
Hi Pavel,
On Tue, 16 Apr 2013 23:51:36 +0400 Pavel Emelyanov wrote:
>
> As Stephen Rothwell pointed out, config options, that depend on
> architecture support, are better to be wrapped into a select +
> depends on scheme.
>
> Do this for CONFIG_MEM_SOFT_DIRTY, as it currently works only
> for
Commit-ID: c889ba801dc3b3a0155fa77d567f2c3a6097de1c
Gitweb: http://git.kernel.org/tip/c889ba801dc3b3a0155fa77d567f2c3a6097de1c
Author: H. Peter Anvin
AuthorDate: Tue, 16 Apr 2013 16:02:58 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 16 Apr 2013 16:02:58 -0700
x86, relocs: Refactor
Commit-ID: 17c961f7702ff6037b66bb2e5f3ddd58de4ce7e5
Gitweb: http://git.kernel.org/tip/17c961f7702ff6037b66bb2e5f3ddd58de4ce7e5
Author: Kees Cook
AuthorDate: Fri, 12 Apr 2013 13:13:45 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 16 Apr 2013 15:22:01 -0700
x86, relocs: Build
Commit-ID: 946166af95d1defacfbc21e7c902d0556a2a7660
Gitweb: http://git.kernel.org/tip/946166af95d1defacfbc21e7c902d0556a2a7660
Author: Kees Cook
AuthorDate: Fri, 12 Apr 2013 13:13:44 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 16 Apr 2013 15:19:22 -0700
x86, relocs: Add 64-bit
Commit-ID: 5d442e63d6a1b5736fd48a907bd7d2d87e411816
Gitweb: http://git.kernel.org/tip/5d442e63d6a1b5736fd48a907bd7d2d87e411816
Author: Kees Cook
AuthorDate: Fri, 12 Apr 2013 13:13:43 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 16 Apr 2013 15:19:13 -0700
x86, relocs: Consolidate
Commit-ID: bf11655cf2ecdcfaacbc8324da4a3edfe276ba9d
Gitweb: http://git.kernel.org/tip/bf11655cf2ecdcfaacbc8324da4a3edfe276ba9d
Author: Kees Cook
AuthorDate: Fri, 12 Apr 2013 13:13:42 -0700
Committer: H. Peter Anvin
CommitDate: Tue, 16 Apr 2013 15:19:06 -0700
x86, relocs: Generalize
On Wed, 17 Apr 2013, Richard Weinberger wrote:
> Using this parameter one can disable the storage_size/2 check if
> he is really sure that the UEFI does sane gc and fulfills the spec.
>
> This parameter is useful if a devices uses more than 50% of the
> storage by default.
> The Intel DQSW67
Hi Shawn,
On Tue, Apr 09, 2013 at 02:53:44PM -0700, Shawn Nematbakhsh wrote:
> Hi Dmitry,
>
> Thanks for the review. Comments in-line.
>
> On Wed, Mar 27, 2013 at 10:32 PM, Dmitry Torokhov
> wrote:
> > Hi Shawn,
> >
> > On Tue, Mar 26, 2013 at 12:36:41PM -0700, Shawn Nematbakhsh wrote:
> >>
Hi Kamal,
On Monday 15 April 2013 12:01:51 Kamal Mostafa wrote:
> BugLink: https://bugs.launchpad.net/bugs/1168430
>
> OminiVision webcam 0x05a9:0x264a (in Dell Studio Hybrid 140g) needs the
> same UVC_QUIRK_PROBE_DEF as other OmniVision model to be recognized
> consistently.
>
> Signed-off-by:
Using this parameter one can disable the storage_size/2 check if
he is really sure that the UEFI does sane gc and fulfills the spec.
This parameter is useful if a devices uses more than 50% of the
storage by default.
The Intel DQSW67 desktop board is such a sucker for exmaple.
Signed-off-by:
On 04/16/2013 03:38 PM, Kees Cook wrote:
>>
>> Have simple wrapper files which do:
>>
>> /* relocs_32.c */
>> #define ELF_BITS 32
>> #include "relocs.c"
>>
>> /* relocs_64.c */
>> #define ELF_BITS 64
>> #include "relocs.c"
>
> That's what I did in my first pass, but it seemed even worse to me. I
On Tue, Apr 16, 2013 at 3:21 PM, H. Peter Anvin wrote:
> On 04/12/2013 01:13 PM, Kees Cook wrote:
>> Since the ELF structures and access macros change size based on 32 vs
>> 64 bits, build a separate 32-bit relocs tool (for handling realmode
>> and 32-bit relocations), and a 64-bit relocs tool
Hi David,
On Tue, Apr 16, 2013 at 07:27:25PM +0100, David Howells wrote:
> This is only needed by the xt_hashlimit netfilter module as that appears to
> use the name in the pde to save a label in the xt_hashlimit_htable struct -
> which will be a problem if CONFIG_PROC_FS=n.
I don't know the
On Tue, Apr 16, 2013 at 2:27 PM, David Rientjes wrote:
> On Fri, 12 Apr 2013, Jiang Liu wrote:
>
>> diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
>> index 901177d..305c68b 100644
>> --- a/arch/x86/pci/common.c
>> +++ b/arch/x86/pci/common.c
>> @@ -6,6 +6,7 @@
>>
>> #include
>>
Quoting Tang Yuantian-B29983 (2013-04-15 23:59:34)
> Hi Mike,
>
> I really appreciate if you can spend some times to review this patch.
>
Yauntian,
Thanks for submitting this patch. I have frozen the changes I plan to
submit for 3.10, with the exception of any last-minute fixes. I'll take
a
On 04/12/2013 01:13 PM, Kees Cook wrote:
> Since the ELF structures and access macros change size based on 32 vs
> 64 bits, build a separate 32-bit relocs tool (for handling realmode
> and 32-bit relocations), and a 64-bit relocs tool (for handling 64-bit
> kernel relocations).
>
> Signed-off-by:
On Tue, Apr 16, 2013 at 3:07 PM, David Howells wrote:
>
> KOSAKI Motohiro wrote:
>
>> I have no seen any issue in this change. but why? Is there any
>> motivation rather than cleanup?
>
> Stopping stuff mucking about with the internals of procfs incorrectly
> (sometimes because the internals of
Hi Grant, Stephen,
On Tue, Apr 16, 2013 at 2:45 AM, Grant Likely wrote:
>>> Grant, if this is ok with you, how shall we have this integrated into your
>>> branch? Half of this has been tested in my -next branch, and the present
>>> patches
>>> make the next half, should I resend you the whole
On 04/16/2013 04:38 PM, Neil Horman wrote:
A few years back intel published a spec update:
http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf
For the 5520 and 5500 chipsets which contained an errata (specificially errata
53), which noted
KOSAKI Motohiro wrote:
> I have no seen any issue in this change. but why? Is there any
> motivation rather than cleanup?
Stopping stuff mucking about with the internals of procfs incorrectly
(sometimes because the internals of procfs have changed, but the drivers
haven't).
David
--
To
On Mon, 15 Apr 2013 12:59:06 -0500 Mike Miller wrote:
> Patch 1/1
>
> If hpsa is selected as the Smart Array driver cciss may try to load in the
> kdump kernel. When this happens kdump fails and a core file cannot be created.
> This patch prevents cciss from trying to load in this scenario.
2013/4/16 Oleg Nesterov :
> On 04/16, Frederic Weisbecker wrote:
>> > rc = ptrace_modify_breakpoint(bp, len, type, tsk, disabled);
>> > if (rc)
>> > break;
>>
>> It would be nice to warn here:
>>
>>WARN_ON_ONCE(rc && second_pass);
>
> Well, I
Thanks Ted!
On Mon, Apr 15, 2013 at 09:47:42PM -0400, Theodore Ts'o wrote:
> Sarah,
>
> Thanks so much for improving the REPORTING-BUGS file. With your
> changes it looks way better!
>
>
> - Ted
--
To unsubscribe from this list: send the line "unsubscribe
Fixed: warning: cast from pointer to integer of different size
The Hyper-V hosts always use 64 bit request id. The guests can have 32 or 64
bit pointers which equal to the ulong type size. So we cast it to ulong type.
And, assigning 32bit integer to 64 bit variable works fine.
The VMBus returns
Signed-off-by: Richard Weinberger
---
arch/um/Kconfig.common | 1 +
arch/um/kernel/process.c | 27 ---
2 files changed, 5 insertions(+), 23 deletions(-)
diff --git a/arch/um/Kconfig.common b/arch/um/Kconfig.common
index bceee66..5783406 100644
---
commit 6d191a5fc7a969d972f1681e1c23781aecb06a61
(regulator: core: Don't defer probe if there's no DT binding for a supply)
Attempted to differentiate between regulator_get() with an actual
DT binding for the supply and when there is none to avoid unnecessary
deferal.
However, ret value supplied
From: Matt Fleming
Now that efivarfs uses the efivar API, move it out of efivars.c and
into fs/efivarfs where it belongs. This move will eventually allow us
to enable the efivarfs code without having to also enable
CONFIG_EFI_VARS built, and vice versa.
Furthermore, things like,
mount -t
From: Matt Fleming
efivars.c has grown far too large and needs to be divided up. Create a
new directory and move the persistence storage code to efi-pstore.c now
that it uses the new efivar API. This helps us to greatly reduce the
size of efivars.c and paves the way for moving other code out of
From: Matt Fleming
There are currently two implementations of the utf16 string functions.
Somewhat confusingly, they've got different names.
Centralise the functions in efi.h.
Cc: Tom Gundersen
Reviewed-by: Mike Waychison
Signed-off-by: Matt Fleming
---
drivers/firmware/efivars.c |
From: Matt Fleming
Some machines have an EFI variable interface that does not conform to
the UEFI specification, e.g. CONFIG_GOOGLE_SMI. Add the necessary code
so that it's only possible to use one implementation of EFI variable
operations at runtime. This allows us to keep a single (file-scope)
From: Matt Fleming
drivers/firmware/efivars.c has grown pretty large and is ~2K lines.
Inside efivars.c there's currently,
o code for handling EFI variables at the firmware-level
o sysfs code for exposing EFI variables
o a new EFI variable filesystem
o a persistent storage backend
all
Em 16-04-2013 15:26, David Howells escreveu:
Add proc_mkdir_data() to allow procfs directories to be created that are
annotated at the time of creation with private data rather than doing this
post-creation. This means no access is then required to the proc_dir_entry
struct to set this.
Em 16-04-2013 15:26, David Howells escreveu:
Supply accessor functions to set attributes in proc_dir_entry structs.
The following are supplied: proc_set_size() and proc_set_user().
Signed-off-by: David Howells
cc: linuxppc-...@lists.ozlabs.org
cc: linux-me...@vger.kernel.org
cc:
On Tue, Apr 16, 2013 at 11:26 AM, David Howells wrote:
> Split kcore bits from linux/procfs.h into linux/kcore.h.
>
> Signed-off-by: David Howells
> cc: linux-m...@linux-mips.org
> cc: sparcli...@vger.kernel.org
> cc: x...@kernel.org
> cc: linux...@kvack.org
I have no seen any issue in this
Em 16-04-2013 15:26, David Howells escreveu:
Don't print proc_dir_entry data in debug as we're soon to have no direct
access to the contents of the PDE. Print what was put in there instead.
Let me just apply this simple one, as it doesn't depend on the rest of the
patches in this series.
On Tue, Apr 16, 2013 at 04:07:25PM -0500, Serge Hallyn wrote:
> Quoting Aristeu Rozanski (a...@redhat.com):
> > On Tue, Apr 16, 2013 at 11:24:55PM +0300, Rami Rosen wrote:
> > > In devcgroup_css_alloc(), there is no longer need for parent_cgroup.
> > > bd2953ebbb("devcg: propagate local changes
On Mon, Apr 15, 2013 at 03:00:27PM +0200, Paolo Bonzini wrote:
> KVM does not use the activity state VMCS field, and does not support
> it in nested VMX either (the corresponding bits in the misc VMX feature
> MSR are zero). Fail entry if the activity state is set to anything but
> "active".
>
>
On 16.04.2013, at 21:49, Alex Williamson wrote:
> We hope to at some point deprecate KVM legacy device assignment in
> favor of VFIO-based assignment. Towards that end, allow legacy
> device assignment to be deconfigured.
>
> Signed-off-by: Alex Williamson
Definitely a step into the right
On Mon, 15 Apr 2013 17:46:46 +0800 Tang Chen wrote:
> kernel_physical_mapping_remove() is only called by arch_remove_memory() in
> init_64.c, which is enclosed in CONFIG_MEMORY_HOTREMOVE. So when we don't
> configure CONFIG_MEMORY_HOTREMOVE, the compiler will give a warning:
>
> warning:
Quoting Aristeu Rozanski (a...@redhat.com):
> On Tue, Apr 16, 2013 at 11:24:55PM +0300, Rami Rosen wrote:
> > In devcgroup_css_alloc(), there is no longer need for parent_cgroup.
> > bd2953ebbb("devcg: propagate local changes down the hierarchy") made
> > the variable parent_cgroup redundant. This
On 04/16/2013 04:06 AM, Stanislaw Gruszka wrote:
> On Thu, Apr 11, 2013 at 11:47:37AM -0700, Dave Hansen wrote:
>> On 04/11/2013 12:45 AM, Stanislaw Gruszka wrote:
>>> On Mon, Apr 08, 2013 at 08:57:16AM -0700, Dave Hansen wrote:
On 04/04/2013 04:41 PM, Frederic Weisbecker wrote:
> Does
On Tue, 16 Apr 2013 13:32:08 -0700, David Ahern wrote:
> On 4/16/13 10:08 AM, Michael Witten wrote:
>> You should probably disable python support more directly:
>>
>>make NO_LIBPYTHON=1
>
> sure, but I should not have to do anything. The intent of the existing
> auto-probing code is to
> -Original Message-
> From: Joe Perches [mailto:j...@perches.com]
> Sent: Tuesday, April 16, 2013 4:31 PM
> To: Haiyang Zhang
> Cc: David Miller; net...@vger.kernel.org; KY Srinivasan; o...@aepfle.de;
> jasow...@redhat.com; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org
>
From: Joe Perches
Date: Mon, 15 Apr 2013 18:17:19 -0700
> Update debugging messages to a more current style.
>
> Emit these debugging messages at KERN_DEBUG instead
> of KERN_DEFAULT.
>
> Add and use neigh_dbg(level, fmt, ...) macro
> Add dynamic_debug capability via pr_debug
> Convert
From: Eric Dumazet
Date: Tue, 16 Apr 2013 07:25:17 -0700
> On Tue, 2013-04-16 at 06:51 -0700, Eric Dumazet wrote:
>
>> Perfect, thanks a lot for all this !
>>
>> Tested-by: Vitaly V. Bursov
>>
>>
>
> By the way, we probably should use skb_flow_dissect() to get proper
> hashing for tunnels
A few years back intel published a spec update:
http://www.intel.com/content/dam/doc/specification-update/5520-and-5500-chipset-ioh-specification-update.pdf
For the 5520 and 5500 chipsets which contained an errata (specificially errata
53), which noted that these chipsets can't properly do
On Tue, Apr 16, 2013 at 11:24:55PM +0300, Rami Rosen wrote:
> In devcgroup_css_alloc(), there is no longer need for parent_cgroup.
> bd2953ebbb("devcg: propagate local changes down the hierarchy") made
> the variable parent_cgroup redundant. This patch removes parent_cgroup
> from
On 4/16/13 10:08 AM, Michael Witten wrote:
You should probably disable python support more directly:
make NO_LIBPYTHON=1
sure, but I should not have to do anything. The intent of the existing
auto-probing code is to figure out what is installed and build a binary
with those capabilities.
On Tue, 2013-04-16 at 20:18 +, Haiyang Zhang wrote:
> > From: David Miller [mailto:da...@davemloft.net]
> > It works fine, but it's unclean.
> > Keep the req_id type as "u64", because that's what it is, a 64-bit request
> > ID.
> I will make this update and submit a new patch, with the added
On Fri, 12 Apr 2013, Jiang Liu wrote:
> diff --git a/arch/x86/pci/common.c b/arch/x86/pci/common.c
> index 901177d..305c68b 100644
> --- a/arch/x86/pci/common.c
> +++ b/arch/x86/pci/common.c
> @@ -6,6 +6,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@
In devcgroup_css_alloc(), there is no longer need for parent_cgroup.
bd2953ebbb("devcg: propagate local changes down the hierarchy") made
the variable parent_cgroup redundant. This patch removes parent_cgroup
from devcgroup_css_alloc().
Signed-off-by: Rami Rosen
---
security/device_cgroup.c | 2
> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Tuesday, April 16, 2013 3:49 PM
> To: Haiyang Zhang
> Cc: net...@vger.kernel.org; KY Srinivasan; o...@aepfle.de;
> jasow...@redhat.com; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org
> Subject:
Hi
I am trying to implement a pinctrl driver.
I have given a brief description of the relevant pinctrl hw features as
well as a the use cases and my proposed solution for them. Please
advise/comment.
HW:
The pin controller has the following properties
1) Each pin has its own 32 bit register
On Tue, 16 Apr 2013, Han Pingtian wrote:
> Hi list,
>
> On a power7 system, we have installed 3.9-rc7 and crash 6.1.6. If I run
> something like "make -j 64" to compile linux kernel from source, sooner
> or latter, oom-killer will be triggered. Before that, when I trying to
> analyse the live
Hi Mike,
On Tue, Apr 16, 2013 at 12:58:26PM -0700, Mike Turquette wrote:
> Quoting Soren Brinkmann (2013-04-16 10:06:50)
> > A clock's notifier count only reflects notifiers which are registered
> > directly for that clock. A reparent operation though affects the whole
> > subtree because of a
The first three patches fix outstanding issues with v3.9 (and earlier)
kernels where the simple sequence of:
echo 0 > /sys/devices/system/cpu/cpu1/online
echo 1 > /sys/devices/system/cpu/cpu1/online
would embarrassingly not work. As such they also have the sta...@vger.kernel.org
on them.
We naively assume that the IRQ value passed in is correct.
If it is not, then any dereference operation for the 'info'
structure will result in crash - so might as well guard ourselves
and sprinkle copious amounts of WARN_ON.
Signed-off-by: Konrad Rzeszutek Wilk
---
drivers/xen/events.c | 20
There is no need to use the PV version of the IRQ_WORKER mechanism
as under PVHVM we are using the native version. The native
version is using the SMP API.
They just sit around unused:
69: 0 0 xen-percpu-ipi irqwork0
83: 0 0 xen-percpu-ipi
The default (uninitialized) value of the IRQ line is -1.
Check if we already have allocated an spinlock interrupt line
and if somebody is trying to do it again. Also set it to -1
when we offline the CPU.
Signed-off-by: Konrad Rzeszutek Wilk
---
arch/x86/xen/spinlock.c | 4
1 file changed,
In the PVHVM path when we do CPU online/offline path we would
leak the timer%d IRQ line everytime we do a offline event. The
online path (xen_hvm_setup_cpu_clockevents via
x86_cpuinit.setup_percpu_clockev) would allocate a new interrupt
line for the timer%d.
But we would still use the old
The "xen_cpu_die" and "xen_hvm_cpu_die" are very similar.
Lets coalesce them.
Signed-off-by: Konrad Rzeszutek Wilk
---
arch/x86/xen/smp.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/arch/x86/xen/smp.c b/arch/x86/xen/smp.c
index 415694c..0d466d7 100644
---
When we online the CPU, we get this splat:
smpboot: Booting Node 0 Processor 1 APIC 0x2
installing Xen timer for CPU 1
BUG: sleeping function called from invalid context at
/home/konrad/ssd/konrad/linux/mm/slab.c:3179
in_atomic(): 1, irqs_disabled(): 0, pid: 0, name: swapper/1
Pid: 0, comm:
If the timer interrupt has been de-init or is just now being
initialized, the default value of -1 should be preset as
interrupt line. Check for that and if something is odd
WARN us.
Signed-off-by: Konrad Rzeszutek Wilk
---
arch/x86/xen/time.c | 7 +--
1 file changed, 5 insertions(+), 2
While we don't use the spinlock interrupt line (see for details
commit f10cd522c5fbfec9ae3cc01967868c9c2401ed23 -
xen: disable PV spinlocks on HVM) - we should still do the proper
init / deinit sequence. We did not do that correctly and for the
CPU init for PVHVM guest we would allocate an
See git commit f10cd522c5fbfec9ae3cc01967868c9c2401ed23
(xen: disable PV spinlocks on HVM) for details.
But we did not disable it everywhere - which means that when
we boot as PVHVM we end up allocating per-CPU irq line for
spinlock. This fixes that.
Signed-off-by: Konrad Rzeszutek Wilk
---
On Tue, Apr 16, 2013 at 12:11 PM, Miklos Szeredi wrote:
> On Tue, Apr 16, 2013 at 8:29 PM, Colin Cross wrote:
>> Dropping __linux__ causes a make headers_check warning, which the
>> kbuild test robot reported this morning:
>> usr/include/linux/fuse.h:99: found __[us]{8,16,32,64} type without
>>
On Tue, 16 Apr 2013, Oskar Andero wrote:
> > > The comment in shrinker.h is misleading, not the source code.
> > > do_shrinker_shrink() will fail for anything negative and 0.
> >
> > The comment is correct. The only acceptable negative return is -1.
> > Look at the second time
>>> >From that perspective, the dependency on X86 is awful. What's the
>>> problem here and what do other architectures need to do to be able to
>>> support the feature?
>>
>> The problem here is that I don't know what free bits are available on
>> page table entries on other architectures. I was
As Stephen Rothwell pointed out, config options, that depend on
architecture support, are better to be wrapped into a select +
depends on scheme.
Do this for CONFIG_MEM_SOFT_DIRTY, as it currently works only
for X86.
Signed-off-by: Pavel Emelyanov
Cc: Stephen Rothwell
---
diff --git
We hope to at some point deprecate KVM legacy device assignment in
favor of VFIO-based assignment. Towards that end, allow legacy
device assignment to be deconfigured.
Signed-off-by: Alex Williamson
---
This depends on Alex Graf's irqfd generalization series to remove
IRQ routing code from
From: Haiyang Zhang
Date: Tue, 16 Apr 2013 19:34:52 +
> The Hyper-V hosts always use 64 bit request id. The guests can have
> 32 or 64 bit pointers which equal to the ulong type size. So we cast
> it to ulong type. And, assigning 32bit integer to 64 bit variable
> works fine.
It works fine,
On Tue, 16 Apr 2013, Tejun Heo wrote:
> Hey,
>
> On Mon, Apr 15, 2013 at 09:02:06AM -0400, Mikulas Patocka wrote:
> > The patch is not bug-prone, because we already must make sure that the
> > cloned bio has shorter lifetime than the master bio - so the patch doesn't
> > introduce any new
On Tue, Apr 09, 2013 at 02:39:32AM -0700, Eric W. Biederman wrote:
> Andrew Morton writes:
> > On Wed, 20 Mar 2013 15:18:17 -0400 Richard Guy Briggs
> > wrote:
> >> audit rule additions containing "-F auid!=4294967295" were failing with
> >> EINVAL.
>
> The only case where this appears to
> -Original Message-
> From: David Miller [mailto:da...@davemloft.net]
> Sent: Tuesday, April 16, 2013 3:12 PM
> To: Haiyang Zhang
> Cc: net...@vger.kernel.org; KY Srinivasan; o...@aepfle.de;
> jasow...@redhat.com; linux-kernel@vger.kernel.org;
> de...@linuxdriverproject.org
> Subject:
Hi,
On Mon, Apr 8, 2013 at 12:22 AM, Kukjin Kim wrote:
> Mike Turquette wrote:
>>
>> Quoting Tushar Behera (2013-04-02 01:20:40)
>> > In legacy setup, sclk_mmc{0,1,2,3} used PRE_RATIO bit-field (8-bit wide)
>> > instead of RATIO bit-field (4-bit wide) for dividing clock rate.
>> >
>> > With
On Tue, Apr 16, 2013 at 09:25:45AM -0700, Andrey Smirnov wrote:
> On Tue, Apr 16, 2013 at 6:51 AM, Samuel Ortiz wrote:
> > Hi Mauro,
> >
> > On Wed, Apr 10, 2013 at 06:48:28AM -0300, Mauro Carvalho Chehab wrote:
> >> Em Wed, 10 Apr 2013 08:42:53 +0200
> >> Samuel Ortiz escreveu:
> >>
> >> > Hi
From: Haiyang Zhang
Date: Tue, 16 Apr 2013 12:03:51 -0700
> Fixed: warning: cast from pointer to integer of different size
>
> Reported-by: kbuild test robot
> Signed-off-by: Haiyang Zhang
> Reviewed-by: K. Y. Srinivasan
If you're coding pointers into request IDs you better make that
On Tue, Apr 16, 2013 at 8:29 PM, Colin Cross wrote:
> Dropping __linux__ causes a make headers_check warning, which the
> kbuild test robot reported this morning:
> usr/include/linux/fuse.h:99: found __[us]{8,16,32,64} type without
> #include
> Using my patch without modification does not cause
On Tue, 16 Apr 2013, Geert Uytterhoeven wrote:
> JFYI, when comparing v3.9-rc7 to v3.9-rc6[3], the summaries are:
> - build errors: +8/-10
+ drivers/pcmcia/electra_cf.c: error: implicit declaration of function
'__ioremap_at' [-Werror=implicit-function-declaration]: => 225:2
+
On Tue, Apr 16, 2013 at 07:28:42AM +0100, Al Viro wrote:
> On Tue, Apr 16, 2013 at 03:11:13PM +0900, Simon Horman wrote:
> > On Thu, Apr 11, 2013 at 02:30:09PM +0100, David Howells wrote:
> > > Don't use create_proc_read_entry() as that is deprecated, but rather use
> > > proc_create_data() and
On 04/16/2013 11:37 AM, Dave Hansen wrote:
> Instead of bothering to store the index, why not just calculate it, like:
>
> On 04/15/2013 08:37 PM, zhang.y...@zte.com.cn wrote:
>> +static inline int get_page_compound_index(struct page *page)
>> +{
>> + if (PageHead(page))
>> +
On 04/16/2013 08:31 AM, Laxman Dewangan wrote:
> Add of_device_id table for Palma GPIO to be enable the
> driver from DT file.
>
> The driver can be registered from DT file as:
> palmas: tps65913@58 {
> :::
> palmas_gpio: palmas_gpio {
>
Instead of bothering to store the index, why not just calculate it, like:
On 04/15/2013 08:37 PM, zhang.y...@zte.com.cn wrote:
> +static inline int get_page_compound_index(struct page *page)
> +{
> + if (PageHead(page))
> + return 0;
> + return compound_head(page) -
In commit d166991234347215dc23fc9dc15a63a83a1a54e1
idle: Implement generic idle function
Thomas Gleixner cleaned up many things but perturbed some
fragile code that was keeping ia64 alive. So we started
seeing:
WARNING: at kernel/cpu/idle.c:94 cpu_idle_loop+0x360/0x380()
and other
Split kcore bits from linux/procfs.h into linux/kcore.h.
Signed-off-by: David Howells
cc: linux-m...@linux-mips.org
cc: sparcli...@vger.kernel.org
cc: x...@kernel.org
cc: linux...@kvack.org
---
arch/mips/mm/init.c |1 +
arch/score/mm/init.c|2 +-
arch/x86/mm/init_64.c |1
On 04/10/2013 06:22 AM, Viresh Kumar wrote:
On 9 April 2013 22:26, Stratos Karafotis wrote:
On 04/05/2013 10:50 PM, Stratos Karafotis wrote:
Hi Viresh,
On 04/04/2013 07:54 AM, Viresh Kumar wrote:
Hi Stratos,
Yes, your results show some improvements. BUT if performance is the only
thing
Don't need to save the PDE of a directory created under /proc/net/rtl8192/ as
we can use proc subtree deletion to get rid of it and all its children.
Signed-off-by: David Howells
cc: Jerry Chuang
cc: Mauro Carvalho Chehab
cc: linux-wirel...@vger.kernel.org
cc: de...@driverdev.osuosl.org
---
Supply accessor functions to set attributes in proc_dir_entry structs.
The following are supplied: proc_set_size() and proc_set_user().
Signed-off-by: David Howells
cc: linuxppc-...@lists.ozlabs.org
cc: linux-me...@vger.kernel.org
cc: net...@vger.kernel.org
cc: linux-wirel...@vger.kernel.org
Create a dir under /proc/net/r8180/ named for the device and create that
device's files under there. This means that there won't be a problem for
multiple devices in the system (if such is possible) and it means we don't
need to save the 'device directory' PDE any more as we can just do a proc
Move proc_fd() to fs/proc/fd.h.
Signed-off-by: David Howells
---
fs/proc/fd.h |5 +
fs/proc/internal.h |5 -
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/fs/proc/fd.h b/fs/proc/fd.h
index cbb1d47..7c047f2 100644
--- a/fs/proc/fd.h
+++ b/fs/proc/fd.h
@@
Split the proc namespace stuff out into linux/proc_ns.h.
Signed-off-by: David Howells
cc: net...@vger.kernel.org
cc: Serge E. Hallyn
cc: Eric W. Biederman
---
fs/namespace.c |6 ++--
fs/proc/inode.c |8 ++---
fs/proc/namespaces.c | 17 +++
Here is a series of patches to make the procfs internals private to the procfs
filesystem. This is built on top of the patches to eliminate
create_proc_read_entry() after the kill-read_proc_t tag.
These patches include fixes for the places that are attempting to abuse
proc_dir_entry->count and
Fixed: warning: cast from pointer to integer of different size
Reported-by: kbuild test robot
Signed-off-by: Haiyang Zhang
Reviewed-by: K. Y. Srinivasan
---
drivers/net/hyperv/netvsc.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/hyperv/netvsc.c
On Tue, Apr 16, 2013 at 12:01 PM, Rafael J. Wysocki wrote:
> On Monday, April 15, 2013 02:18:18 PM Bjorn Helgaas wrote:
>> On Fri, Apr 12, 2013 at 11:50 PM, Yinghai Lu wrote:
>> > On Fri, Apr 12, 2013 at 4:58 PM, Rafael J. Wysocki wrote:
>> >> From: Rafael J. Wysocki
>> >>
>> >> Commit b51306c
Supply an accessor function for getting the private data from the parent
proc_dir_entry struct of the proc_dir_entry struct associated with an inode.
ReiserFS, for instance, stores the super_block pointer in the proc directory
it makes for that super_block, and a pointer to the respective
Use remove_proc_subtree() to remove the airo device subdir and all its
children instead of doing it manually.
Signed-off-by: David Howells
cc: linux-wirel...@vger.kernel.org
---
drivers/net/wireless/airo.c | 49 +++
1 file changed, 13 insertions(+), 36
Use minor->index to label things, not the name field from the proc_dir_entry
of the /proc/dwm// directory.
Also, use "%u" not "%d" to render the value and use a 12-byte buffer in which
to render the integer, not a 16-byte buffer. The longest string an unsigned
int can give you is 10 chars
On Tue, Apr 16, 2013 at 11:21 AM, Linus Torvalds
wrote:
>> What I meant is IF is included by userspace (it sure is
>> meant to be included and *is* included by libfuse and other stuff)
>> THEN using instead of is fine regardless of
>> whether __linux__ is defined or not.
>
> That's probably
Don't print proc_dir_entry data in debug as we're soon to have no direct
access to the contents of the PDE. Print what was put in there instead.
Signed-off-by: David Howells
cc: mjpeg-us...@lists.sourceforge.net
cc: linux-me...@vger.kernel.org
---
drivers/media/pci/zoran/zoran_procfs.c |2
101 - 200 of 1154 matches
Mail list logo
