fixed below checkpatch warning.
-Prefer netdev_info(netdev, ... then dev_info(dev, ... then pr_info(... to
printk(KERN_INFO ...
Signed-off-by: YAMANE Toshiaki
---
drivers/staging/comedi/drivers/rtd520.c | 25 +
1 file changed, 13 insertions(+), 12 deletions(-)
diff
fixed below checkpatch warnings.
- WARNING: Prefer netdev_info(netdev, ... then dev_info(dev, ... then
pr_info(... to printk(KERN_INFO ...
- WARNING: Prefer netdev_warn(netdev, ... then dev_warn(dev, ... then
pr_warn(... to printk(KERN_WARNING ...
- WARNING: Prefer netdev_err(netdev, ... then
fixed below checkpatch warning.
- WARNING: Prefer netdev_dbg(netdev, ... then dev_dbg(dev, ... then
pr_debug(... to printk(KERN_DEBUG ...
Signed-off-by: YAMANE Toshiaki
---
drivers/staging/comedi/drivers/adl_pci8164.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff
fixed below checkpatch warnings.
- WARNING: Prefer netdev_err(netdev, ... then dev_err(dev, ... then pr_err(...
to printk(KERN_ERR ...
- WARNING: quoted string split across lines
Signed-off-by: YAMANE Toshiaki
---
drivers/staging/comedi/drivers/me_daq.c | 19 ---
1 file
The retry loop in neigh_resolve_output() and neigh_connected_output()
call dev_hard_header() with out reseting the skb to network_header.
This causes the retry to fail with skb_under_panic. The fix is to
reset the network_header within the retry loop.
Signed-off-by: Ramesh Nagappa
Reviewed-by:
On 10/05/2012 04:02 PM, Josh Triplett wrote:
> On Fri, Oct 05, 2012 at 10:58:58PM +0200, Borislav Petkov wrote:
>> On Fri, Oct 05, 2012 at 02:42:48PM -0500, danielfsan...@att.net wrote:
>>> Add BUILD_BUG_ON_MSG which behaves like BUILD_BUG_ON (with optimizations
>>> turned enabled), except that it
On 10/05/2012 03:59 PM, Josh Triplett wrote:
> On Fri, Oct 05, 2012 at 02:42:46PM -0500, danielfsan...@att.net wrote:
>> --- a/include/linux/compiler.h
>> +++ b/include/linux/compiler.h
>> @@ -296,6 +296,11 @@ void ftrace_likely_update(struct ftrace_branch_data *f,
>> int val, int expect);
>>
Not much to say here, except that we've reduced the number of different
Kconfig options, which will hopefully make it easier to configure RMI4
support in kernels.
Signed-off-by: Christopher Heiny
Cc: Dmitry Torokhov
Cc: Linus Walleij
Cc: Naveen Kumar Gaddipati
Cc: Joeri de Gram
---
RMI Function 01 implements basic device control and power management
behaviors for the RMI4 sensor. Since the last patch, we've decoupled rmi_f01.c
implementation from rmi_driver.c, so rmi_f01.c acts as a standard driver
module to handle F01 devices on the RMI bus.
Like other modules, a number
As requested in the feedback from the previous patch, we've documented the
debugfs and sysfs attributes in files in Documentation/ABI/testing. There's
two files, one for debugfs and one for sysfs.
Signed-off-by: Christopher Heiny
Cc: Dmitry Torokhov
Cc: Linus Walleij
Cc: Naveen Kumar
The I2C physical driver is not extensively changed in terms of functionality
since the previous patch. Management of the attention GPIO has been moved to
rmi_driver.c (see previous email), and most of the debug related interfaces
have been moved from sysfs to debugfs. Control of the debug
This patch implements a driver supporting Synaptics ClearPad and other
touchscreen sensors that use the RMI4 protocol, as defined here:
http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4%20Intrfacing%20Guide.pdf
as well as successor documents that haven't made their way
I've rebased this to tip/master and pushed some minor updates (most
notable: rounding down in decay_load).
Tree is at:
http://git.kernel.org/?p=linux/kernel/git/pjt/sched.git;a=summary
(branch: load-tracking)
If you prefer raw patches there's a quilt series at:
On Fri, 2012-10-05 at 17:16 -0700, H. Peter Anvin wrote:
> On 10/05/2012 07:13 AM, Steven Rostedt wrote:
> >
> > Peter,
> >
> > I agree that the IDT version is a zero cost in performance, where as the
> > tracepoint version is a negligible cost in performance. But my worry is
> > the complexity
Hello, Glauber.
On Thu, Oct 04, 2012 at 03:55:14PM +0400, Glauber Costa wrote:
> I don't want to bloat unrelated kmem_cache structures, so I can't embed
> a memcg array in there: I would have to have a pointer to a memcg array
> that gets assigned at first use. But if we don't want to have a
On Fri, Oct 05, 2012 at 04:55:21PM +0200, Arnd Bergmann wrote:
> In a configuration where the base cgroup support is enabled but
> every single cgroup subsys is turned off, CGROUP_BUILTIN_SUBSYS_COUNT
> is zero, which causes the sanity check code in cgroup_load_subsys
> to trigger:
>
>
This patch adds main part(out of three) of the I2C driver for the
"core" of MFD device.
Signed-off-by: Andrey Smirnov
---
drivers/mfd/si476x-i2c.c | 972 ++
1 file changed, 972 insertions(+)
create mode 100644 drivers/mfd/si476x-i2c.c
diff --git
This patch adds all the functions used for exchanging commands with
the chip.
Signed-off-by: Andrey Smirnov
---
drivers/mfd/si476x-cmd.c | 1493 ++
1 file changed, 1493 insertions(+)
create mode 100644 drivers/mfd/si476x-cmd.c
diff --git
This patch adds code related to manipulation of the properties of
SI476X chips.
Signed-off-by: Andrey Smirnov
---
drivers/mfd/si476x-prop.c | 477 +
1 file changed, 477 insertions(+)
create mode 100644 drivers/mfd/si476x-prop.c
diff --git
This commit adds a driver that exposes all the radio related
functionality of the Si476x series of chips via the V4L2 subsystem.
Signed-off-by: Andrey Smirnov
---
drivers/media/radio/Kconfig| 17 +
drivers/media/radio/Makefile |1 +
drivers/media/radio/radio-si476x.c | 1153
This commit add a sound codec driver for Silicon Laboratories 476x
series of AM/FM radio chips.
Signed-off-by: Andrey Smirnov
---
sound/soc/codecs/Kconfig |4 +
sound/soc/codecs/Makefile |2 +
sound/soc/codecs/si476x.c | 255 +
3 files
This patch adds all necessary header files and Kbuild plumbing for the
core driver for Silicon Laboratories Si476x series of AM/FM tuner
chips.
The driver as a whole is implemented as an MFD device and this patch
adds a core portion of it that provides all the necessary
functionality to the two
This is a second version of the patchset originaly posted here:
https://lkml.org/lkml/2012/9/13/590
To save everyone's time I'll repost the original description of it:
This patchset contains a driver for a Silicon Laboratories 476x series
of radio tuners. The driver itself is implemented as an
Hello Linus!
Here are the target pending updates for v3.7-rc1 code. Please go ahead
and pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending.git for-next
Things have been calm for the most part with no new fabric drivers in
flight for v3.7 (we're up to eight now !), so
less jitter != less latency
you could (in theory) eliminate jitter by delaying every keypress
processed for exactly 1 second by having the code paths that process
keypresses faster insert delays before implementing the results.
that would result in zero jitter, but horrific latency.
latency
That disappeared 10 years ago...
ebied...@xmission.com wrote:
>"H. Peter Anvin" writes:
>
>> On 10/05/2012 02:41 PM, Eric W. Biederman wrote:
>>> Yinghai Lu writes:
>>>
with bzImage or vmlinux?
>>>
>>> bzImage I presume. Certainly the bzImage has lost it's 896M limit,
>>> which is where
Reducing jitter seems central for many things.
First of all keypresses seem faster. (less jitter = less latency).
Doom 3 and similar jittersensitive OpenGL applications run smoothly, and
better than windows. Doom 3 was also my main app to get running well, and
measuring jitter in the
"H. Peter Anvin" writes:
> On 10/05/2012 02:41 PM, Eric W. Biederman wrote:
>> Yinghai Lu writes:
>>
>>> with bzImage or vmlinux?
>>
>> bzImage I presume. Certainly the bzImage has lost it's 896M limit,
>> which is where ultimiately the 896M limite came from.
>>
>
> ~896M (actually comes from
On 10/05/2012 05:28 PM, Eric W. Biederman wrote:
Seriously, any case where we can't load anywhere in physical ram on x86-64 is a
bug. i386 is another matter.
As I recall there are data structures like the IDT that only have a
32bit base address.
Not true. The only one I know of is memory
This change makes it so that the unmap functionality also uses physical
addresses. This helps to further reduce the use of virt_to_phys and
phys_to_virt functions.
In order to clarify things since we now have 2 physical addresses in use
inside of swiotlb_tbl_unmap_single I am renaming phys to
Currently swiotlb is the only consumer for swiotlb_bounce. Since that is the
case it doesn't make much sense to be exporting it so make it a static
function only.
In addition we can save a few more lines of code by making it so that it
accepts the DMA address as a physical address instead of a
This change makes it so that the sync functionality also uses physical
addresses. This helps to further reduce the use of virt_to_phys and
phys_to_virt functions.
In order to clarify things since we now have 2 physical addresses in use
inside of swiotlb_tbl_sync_single I am renaming phys to
This change makes it so that we can avoid virt_to_phys overhead when using the
io_tlb_overflow_buffer. My original plan was to completely remove the value
and replace it with a constant but I had seen that there were recent patches
that stated this couldn't be done until all device drivers that
This change makes it so that swiotlb_tbl_map_single will return a physical
address instead of a virtual address when called. The advantage to this once
again is that we are avoiding a number of virt_to_phys and phys_to_virt
translations by working with everything as a physical address.
One
This change replaces all references to the virtual address for io_tlb_start
with references to the physical address io_tlb_addr. The main advantage of
replacing the virtual address with a physical address is that we can avoid
having to do multiple translations from the virtual address to the
In the case of swiotlb we already have the start of the region and the number
of slabs that give us the region size. Instead of having to call
virt_to_phys on two pointers we can just take advantage of the fact that the
region is linear and just compute the end based on the start plus the size.
While working on 10Gb/s routing performance I found a significant amount of
time was being spent in the swiotlb DMA handler. Further digging found that a
significant amount of this was due to virtual to physical address translation
and calling the function that did it. It accounted for nearly
"H. Peter Anvin" writes:
> On 10/05/2012 02:32 PM, Eric W. Biederman wrote:
>> Yinghai Lu writes:
>>
>>> On Fri, Oct 5, 2012 at 2:04 PM, Eric W. Biederman
>>> wrote:
>> Is there a git commit that explains what the 'big range' problem is?
At least on x86_64 this was recently
Commit-ID: 385ddeac7ed99cf7dc62d76274d55fbd7cae1b5a
Gitweb: http://git.kernel.org/tip/385ddeac7ed99cf7dc62d76274d55fbd7cae1b5a
Author: Luck, Tony
AuthorDate: Fri, 5 Oct 2012 15:05:34 -0700
Committer: H. Peter Anvin
CommitDate: Fri, 5 Oct 2012 15:59:07 -0700
X86 ACPI: Use #ifdef not
On 10/05/2012 02:41 PM, Eric W. Biederman wrote:
Yinghai Lu writes:
with bzImage or vmlinux?
bzImage I presume. Certainly the bzImage has lost it's 896M limit,
which is where ultimiately the 896M limite came from.
~896M (actually comes from i386, not from bzImage...
-hpa
--
On 10/05/2012 02:32 PM, Eric W. Biederman wrote:
Yinghai Lu writes:
On Fri, Oct 5, 2012 at 2:04 PM, Eric W. Biederman wrote:
Is there a git commit that explains what the 'big range' problem is?
At least on x86_64 this was recently tested and anywhere below 4G is
good, and there is a patch
On 10/05/2012 07:13 AM, Steven Rostedt wrote:
>
> Peter,
>
> I agree that the IDT version is a zero cost in performance, where as the
> tracepoint version is a negligible cost in performance. But my worry is
> the complexity (read error prone and possible openings of security
> exploits) worth
Tim Chen writes:
>>
>
> I remembered that 3 months ago when Alex tested the numa/sched patches
> there were 20% regression on SpecJbb2005 due to the numa balancer.
20% on anything sounds like a show stopper to me.
-Andi
--
a...@linux.intel.com -- Speaking for myself only
--
To unsubscribe
Hi Miles,
On Thu, 2012-10-04 at 10:14 -0400, Miles Lane wrote:
> ACPI Warning: 0x0828-0x082f SystemIO conflicts
> with Region \PMIO 1 (20120711/utaddress-251)
> ACPI: If an ACPI driver is available for this device, you should use
> it instead of the native driver
> ACPI
On Fri, 5 Oct 2012, Ben Hutchings wrote:
> On Fri, 2012-10-05 at 11:28 -0700, Min Zhang wrote:
> > ifconfig mlx4_en port reported RUNNING even though the link was down.
> >
> > mlx4_en_init_netdev didn't initialize the dev operstate properly so
> > the operstate stayed as default
On Sat, Oct 06, 2012 at 09:48:57AM +1000, Dave Airlie wrote:
> Any reason you don't have KMS, you'll keep hitting these non-kms bugs
> since it has no users anymore really.
>
> Granted they'll get fixed, but I suspect its a losing battle over time.
Well, back in old times every time I tried to
On Fri, 2012-10-05 at 16:14 -0700, Andi Kleen wrote:
> Andrew Morton writes:
>
> > On Thu, 4 Oct 2012 01:50:42 +0200
> > Andrea Arcangeli wrote:
> >
> >> This is a new AutoNUMA27 release for Linux v3.6.
> >
> > Peter's numa/sched patches have been in -next for a week.
>
> Did they pass
On Sat, Oct 6, 2012 at 9:42 AM, Willy Tarreau wrote:
> Chris, Daniel,
>
> since version 3.5, my Asus EeePC 1005HA bugs during startx. I didn't
> have the time to investigate until this evening.
>
> I could bisect the commits and found that the following one was merged
> in 3.5-rc1 and is
Chris, Daniel,
since version 3.5, my Asus EeePC 1005HA bugs during startx. I didn't
have the time to investigate until this evening.
I could bisect the commits and found that the following one was merged
in 3.5-rc1 and is responsible for these bugs that can reliably be
triggered :
On 10/05/2012 01:02 PM, Andi Kleen wrote:
>> I was thinking the issue was all of the calls to relatively small
>> functions occurring in quick succession. The way most of this code is
>> setup it seems like it is one small function call in turn calling
>> another, and then another, and I would
Andrew Morton writes:
> On Thu, 4 Oct 2012 01:50:42 +0200
> Andrea Arcangeli wrote:
>
>> This is a new AutoNUMA27 release for Linux v3.6.
>
> Peter's numa/sched patches have been in -next for a week.
Did they pass review? I have some doubts.
The last time I looked it also broke numactl.
>
On Fri, Oct 5, 2012 at 4:01 PM, Rafael J. Wysocki wrote:
> On Thursday 04 of October 2012 15:46:39 Yinghai Lu wrote:
>> > Your patches seem to affect all devices in the ACPI namespace added after
>> > boot, though, not only host bridges.
>>
>> yes, but it still should be safe.
>
> I'm not really
On Thursday 04 of October 2012 15:46:39 Yinghai Lu wrote:
> On Thu, Oct 4, 2012 at 3:36 PM, Rafael J. Wysocki wrote:
> > On Thursday 04 of October 2012 15:01:21 Yinghai Lu wrote:
> >> during adding pci root bus hotplug, Bjorn found some unsafe searching
> >> that caused by pci_bus_add_devices.
>
Hi:
I am getting this in the current linus tree.
[0.408781] ===
[0.408783] [ INFO: suspicious RCU usage. ]
[0.408786] 3.6.0-canneverbe-07124-g5f3d2f2 #18 Not tainted
[0.408789] ---
[0.408791] include/linux/cgroup.h:566
On Thu, 04 Oct 2012 19:23:13 -0600
Shuah Khan wrote:
> A recent dma mapping error analysis effort showed that a large percentage
> of dma_map_single() and dma_map_page() returns are not checked for mapping
> errors.
>
> Reference:
>
From: Peter Senna Tschudin
The function skge_probe() return 0 for success and negative value
for most of its internal tests failures. There is one exception
that is error case going to err_out_led_off:. For this error case, the
function abort its success execution path, but returns non negative
From: Peter Senna Tschudin
The function niu_pci_init_one() return 0 for success and negative value
for most of its internal tests failures. There is one exception
that is error case going to err_out_free_res:. For this error case, the
function abort its success execution path, but returns non
From: Peter Senna Tschudin
The function gem_init_one() return 0 for success and negative value
for most of its internal tests failures. There is one exception
that is error case going to err_out_free_consistent:. For this error
case, the function abort its success execution path, but returns non
From: Peter Senna Tschudin
The function sky2_probe() return 0 for success and negative value
for most of its internal tests failures. There are two exceptions
that are error cases going to err_out*:. For this two cases, the
function abort its success execution path, but returns non negative
From: Peter Senna Tschudin
The function sh_eth_drv_probe() return 0 for success and negative value
for most of its internal tests failures. There is one exception
that is error case going to out_release:. For this error case, the
function abort its success execution path, but returns non
Hello.
On 05-10-2012 12:07, Kishon Vijay Abraham I wrote:
Platfrom device for ocp2scp is created using omap_device_build in
devices file. This is used for both omap4(musb) and omap5(dwc3).
Signed-off-by: Kishon Vijay Abraham I
---
arch/arm/mach-omap2/devices.c | 72
On Thu, Oct 04, 2012 at 08:51:19PM +0100, David Howells wrote:
> Can you merge the following branch into the hexagon tree please.
>
> This is to complete part of the UAPI disintegration for which the preparatory
> patches were pulled recently.
>
> Note that there are some fixup patches which are
I find that I can reliably crash 3.6 by booting to a kernel with
CONFIG_INTEL_IDLE set and running
dd if=/dev/zero of=BIG
If I turn off CONFIG_INTEL_IDLE there's no crash. (dd just hits ENOSPC
eventually.)
This isn't new--I originally saw it on 2.6.35.6. (An upgrade to F14
failed, and
On Wed, 03 Oct 2012 09:23:36 +0200, Paul Bolle said:
> By the way, GCC doesn't warn if I add an early check whether 'val_count'
> is non-zero:
>
> diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
> index c241ae2..d41527b 100644
> --- a/drivers/base/regmap/regmap.c
> +++
From: Peter Senna Tschudin
The function qlcnic_probe() return 0 for success and negative value
for most of its internal tests failures. There is one exception
that is error case going to err_out_free_netdev:. For this error case,
the function abort its success execution path, but returns non
From: Peter Senna Tschudin
The function sonic_probe1() return 0 for success and negative value
for most of its internal tests failures. There is one exception
that is error case going to out:. For this error case, the
function abort its success execution path, but returns non negative
value,
From: Peter Senna Tschudin
The function amd8111e_probe_one() return 0 for success and negative
value for most of its internal tests failures. There are two exceptions
that are error cases going to err_free_reg:. For this two cases, the
function abort its success execution path, but returns non
From: Peter Senna Tschudin
The function sh_sir_probe() return 0 for success and negative value
for most of its internal tests failures. There are two exceptions
that are error cases going to err_mem_*:. For this two cases, the
function abort its success execution path, but returns non negative
From: Peter Senna Tschudin
The function au1000_probe() return 0 for success and negative value
for most of its internal tests failures. There are exceptions
that are error cases going to err_out:. For this cases, the
function abort its success execution path, but returns non negative
value,
There are no users of this macro anymore in the kernel tree, so finally
delete it.
Signed-off-by: Greg Kroah-Hartman
---
include/linux/usb.h | 11 ---
1 file changed, 11 deletions(-)
diff --git a/include/linux/usb.h b/include/linux/usb.h
index 07915a3..10278d1 100644
---
Hi Dave,
On Fri, Oct 05, 2012 at 05:59:29PM -0400, Dave Jones wrote:
> On boot in Linus' current tree..
>
>
> ===
> [ INFO: suspicious RCU usage. ]
> 3.6.0+ #22 Not tainted
> ---
> include/linux/cgroup.h:566 suspicious
Fix a build warning on ia64:
include/linux/acpi.h:437:5: warning: "CONFIG_X86" is not defined
Signed-off-by: Tony Luck
---
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 4f42332..f70f18d 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -434,7 +434,7 @@ void
Takashi,
I've been seeing this on one machine since around 3.3 (perhaps earlier, I
forget)
I reported it a while ago, and you had me test some patch that didn't make any
difference, then it fell off my radar..
Dave
=
[ INFO: possible recursive
I am going to see about merging these two threads.
Yinghai Lu writes:
> On Fri, Oct 5, 2012 at 2:41 PM, Eric W. Biederman
> wrote:
>> Yinghai Lu writes:
>>
>>> with bzImage or vmlinux?
>>
>> bzImage I presume. Certainly the bzImage has lost it's 896M limit,
>> which is where ultimiately
On Thu, 04 Oct 2012 15:47:38 -0400 (EDT)
David Miller wrote:
> The transparent huge page code passes a PMD pointer in as the third
> argument of update_mmu_cache(), which expects a PTE pointer.
>
> This never got noticed because X86 implements update_mmu_cache() as a
> macro and thus we don't
On Fri, 05 Oct 2012 17:45:08 -0400 (EDT)
David Miller wrote:
> From: Andrew Morton
> Date: Fri, 5 Oct 2012 14:36:44 -0700
>
> > David, I don't know what to do until there's some clarity on the
> > numa/sched changes. Andrea has a new autonuma patchset, Peter's code
> > is in -next and I don't
Peter Senna Tschudin :
[...]
> The function natsemi_probe1() return 0 for success and negative value
> for most of its internal tests failures. There is one exception
> that is error case going to err_create_file:. Fore this error case the
> function abort its success execution path, but returns
On boot in Linus' current tree..
===
[ INFO: suspicious RCU usage. ]
3.6.0+ #22 Not tainted
---
include/linux/cgroup.h:566 suspicious rcu_dereference_check() usage!
other info that might help us debug this:
rcu_scheduler_active = 1,
From: Andrew Morton
Date: Fri, 5 Oct 2012 14:36:44 -0700
> David, I don't know what to do until there's some clarity on the
> numa/sched changes. Andrea has a new autonuma patchset, Peter's code
> is in -next and I don't know if it's planned for 3.7 merging. And I
> suspect (hope) that it
On Fri, 05 Oct 2012, da...@lang.hm wrote:
> >On Thu, Oct 4, 2012 at 9:50 PM, Kurt H Maier wrote:
> >>On Wed, Oct 03, 2012 at 07:27:01PM +, Al Viro wrote:
> >>>Al, that -><- close to volunteering for maintaining that FPOS
> >>>kernel-side...
> >>
> >>This would be fantastic.
> >
> >And that
On Fri, Oct 5, 2012 at 2:41 PM, Eric W. Biederman wrote:
> Yinghai Lu writes:
>
>> with bzImage or vmlinux?
>
> bzImage I presume. Certainly the bzImage has lost it's 896M limit,
> which is where ultimiately the 896M limite came from.
they are using updated kexec-tools ?
last time when i
Yinghai Lu writes:
> with bzImage or vmlinux?
bzImage I presume. Certainly the bzImage has lost it's 896M limit,
which is where ultimiately the 896M limite came from.
Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Fri, Oct 5, 2012 at 2:32 PM, Eric W. Biederman wrote:
> Yinghai Lu writes:
>
>> On Fri, Oct 5, 2012 at 2:04 PM, Eric W. Biederman
>> wrote:
> Is there a git commit that explains what the 'big range' problem is?
>>>
>>> At least on x86_64 this was recently tested and anywhere below 4G is
On Thu, 04 Oct 2012 15:46:24 -0400 (EDT)
David Miller wrote:
>
> Changes since V1:
>
> 1) Respun against mmotm
>
> 2) Bug fix for pgtable allocation, need real locking instead of
>just preemption disabling.
>
> Andrew, you can probably take patch #5 in this series and combine
> it into:
size to something that's known to work
> for them.
>
> [1] http://www.spinics.net/lists/arm-kernel/msg198854.html
Tested again on top of v4 of the uio_pruss/genalloc series
http://www.spinics.net/lists/arm-kernel/msg199255.html
on next-20121005 since there's some conflicts falling out o
From: Peter Senna Tschudin
The function pxa_irda_probe() return 0 for success and negative value
for most of its internal tests failures. There is one exception
that is error case going to err_mem_3:. For this error case, the
function abort its success execution path, but returns non negative
From: Peter Senna Tschudin
The function sh_irda_probe() return 0 for success and negative value
for most of its internal tests failures. There is one exception
that is error case going to err_mem_4:. For this error case, the
function abort its success execution path, but returns non negative
From: Peter Senna Tschudin
The function sa1100_irda_probe() return 0 for success and negative
value for most of its internal tests failures. There is one exception
that is error case going to err_mem_4:. For this error case, the
function abort its success execution path, but returns non negative
From: Peter Senna Tschudin
The function mcs_probe() return 0 for success and negative value
for most of its internal tests failures. There is one exception
that is error case going to error2:. For this error case, the
function abort its success execution path, but returns non negative
value,
From: Peter Senna Tschudin
The function irtty_open() return 0 for success and negative value
for most of its internal tests failures. There is one exception
that is error case going to out_put:. For this error case, the
function abort its success execution path, but returns non negative
value,
Yinghai Lu writes:
> On Fri, Oct 5, 2012 at 2:04 PM, Eric W. Biederman
> wrote:
Is there a git commit that explains what the 'big range' problem is?
>>
>> At least on x86_64 this was recently tested and anywhere below 4G is
>> good, and there is a patch floating around somewhere to remove
On Sun, 30 Sep 2012 14:54:07 +0200, Uwaysi Bin Kareem said:
> Compiled 3.6-rc7, with a hz timer of 3956 for a "natural" psychovisual
> profile jitter level in OpenGL, and a shaved config for minimal jitter.
I'll bite - how did you measure the difference between 3956 and 4000?
The other stuff in
On Fri, Oct 05, 2012 at 04:43:56AM +, Hebbar, Gururaja wrote:
> Matt,
>
> On Wed, Oct 03, 2012 at 20:30:58, Porter, Matt wrote:
> > On Fri, Sep 28, 2012 at 03:37:45PM -0400, Matt Porter wrote:
> > > Changes since v1:
> > > - Replaced uio_pruss private SRAM API use with genalloc
> > > -
VMAC implementation, as it is, does not work with blocks that
are not multiples of 128-bytes. Furthermore, this is a problem
when using the implementation on scatterlists, even
when the complete plain text is 128-byte multiple, as the pieces
that get passed to vmac_update can be pretty much any
On Fri, Oct 5, 2012 at 2:04 PM, Eric W. Biederman wrote:
>>> Is there a git commit that explains what the 'big range' problem is?
>
> At least on x86_64 this was recently tested and anywhere below 4G is
> good, and there is a patch floating around somewhere to remove this
> issue.
patch for
On Fri, Oct 05, 2012 at 09:59:15AM +0300, Antti P Miettinen wrote:
> From: "Paul E. McKenney"
> > b. Maybe sysfs setting. Initially, this can be simple "on" and "off",
> > exported with root-only access (like you have above). If more
> > elaborate use cases appear, this might become
On 10/05/2012 10:54 AM, Dan Luedtke wrote:
> On Fri, 2012-10-05 at 20:56 +0900, 김재극 wrote:
>> +__le32 i_atime; /* Access time */
>> +__le32 i_ctime; /* inode Change time */
>> +__le32 i_mtime; /* Modification time */
>> +__le32
On 10/05/2012 10:41 PM, Peter Senna Tschudin wrote:
> From: Peter Senna Tschudin
>
> The function pcan_probe() return 0 for success and negative value
> for most of its internal tests failures. There is one exception
> that is error case going to probe_err_4:. Fore this error case, the
>
On 10/05/2012 10:41 PM, Peter Senna Tschudin wrote:
> From: Peter Senna Tschudin
>
> The function peak_pci_probe() return 0 for success and negative value
> for most of its internal tests failures. There are two exceptions
> that are error cases going to failure_*:. Fore this two cases the
>
Yinghai Lu writes:
> On Thu, Oct 4, 2012 at 9:46 AM, Konrad Rzeszutek Wilk
> wrote:
>>> then kdump may have problem get big range again.
>>
>> Is there a git commit that explains what the 'big range' problem is?
At least on x86_64 this was recently tested and anywhere below 4G is
good, and
1 - 100 of 1180 matches
Mail list logo
