On Fri, 2012-07-13 at 14:42 -0700, Andrew Morton wrote:
The issue Alan raised around the superblock timestamp is still up in
the air. I guess he's a slow typist ;)
My take is no, we don't need to do that any more - surely all Linux
systems have a functional hardware clock. But the
If a seccomp filter program is installed, older static binaries and
distributions with older libc implementations (glibc 2.13 and earlier)
that rely on vsyscall use will be terminated regardless of the filter
program policy when executing time, gettimeofday, or getcpu. This is
only the case when
With the addition of seccomp support to vsyscall emulation:
http://permalink.gmane.org/gmane.linux.kernel/1327732
with some minor changes in the first patch in this series.
Update the documentation to indicate quirky behaviors when the 'ip' is
in the vsyscall page and vsyscall emulation is in
On Fri, 2012-07-13 at 13:37 -0700, Linus Torvalds wrote:
So this has long been one of my pet configuration peeves: as a user I
am perfectly happy answering the questions about what kinds of
hardware I want the kernel to support (I kind of know that), but many
of the support infrastructure
On Fri, 2012-07-13 at 15:09 +0100, Chris Webb wrote:
Eric Dumazet eric.duma...@gmail.com writes:
Have you read firmware/README.AddingFirmware ?
I hadn't, but now I have, and if firmware upgrades are considered 'adding
new firmware', I agree this patch is wrong, and should have just
Seeing code like this
+ return (*nr_running)[0];
just makes me go WTF?
Why are you taking the address of something you just dereferenced (the
[0] part).
And you actually do that *twice*, except the inner one is more
complicated. When you assign nr_runing, you take the address of it, so
Hello, Linus.
On Fri, Jul 13, 2012 at 09:27:03PM -0700, Linus Torvalds wrote:
Seeing code like this
+ return (*nr_running)[0];
just makes me go WTF?
I was going WTF too. This was the smallest fix and I wanted to make
it minimal because there's another stack of patches on top of it.
On 07/13/2012 04:42 AM, Sebastian Hesselbarh wrote:
On 07/13/2012 05:19 AM, Rob Herring wrote:
What's implemented in Linux should not define the binding. The binding
should describe the hardware.
[...]
True, but not your problem to implement. A binding doesn't necessarily
mean there is a
On Fri, Jul 13, 2012 at 9:44 PM, Tejun Heo t...@kernel.org wrote:
nr_running is atomic_t (*nr_running)[2]. Ignoring the pointer to
array part, it's just returning the address of N'th element of the
array. ARRAY + N == ARRAY[N].
None of this matters one whit.
You did (x)[0].
That's insane.
On 13/07/2012 21:20, Olaf Hering o...@aepfle.de wrote:
On Tue, Jul 10, Keir Fraser wrote:
On 10/07/2012 19:09, Olaf Hering o...@aepfle.de wrote:
I'm not sure, most likely the gfn will just disappear from the guest,
like a ballooned page disappears. Accessing it will likely cause a
crash.
Hey, Linus.
On Fri, Jul 13, 2012 at 10:00:10PM -0700, Linus Torvalds wrote:
On Fri, Jul 13, 2012 at 9:44 PM, Tejun Heo t...@kernel.org wrote:
nr_running is atomic_t (*nr_running)[2]. Ignoring the pointer to
array part, it's just returning the address of N'th element of the
array. ARRAY
Hi Dave,
On Sat, Jul 14, 2012 at 01:33:45PM +1000, Dave Airlie wrote:
Can you try this patch on top of the previous one?
I think it should fix it.
You are right, it works! Thank you very much! :-)
Thanks,
Fengguang
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
From 4ce62e9e30cacc26885cab133ad1de358dd79f21 Mon Sep 17 00:00:00 2001
From: Tejun Heo t...@kernel.org
Date: Fri, 13 Jul 2012 22:16:44 -0700
Introduce NR_WORKER_POOLS and for_each_worker_pool() and convert code
paths which need to manipulate all pools in a gcwq to use them.
NR_WORKER_POOLS is
From a465fcee388d62d22e390b57c81ca8411f25a1da Mon Sep 17 00:00:00 2001
From: Tejun Heo t...@kernel.org
Date: Fri, 13 Jul 2012 22:16:45 -0700
WQ_HIGHPRI was implemented by queueing highpri work items at the head
of the global worklist. Other than queueing at the head, they weren't
handled
The voltage selection logic is supposed to find the samllest voltage falls
within specified range. When using equation to calculate vsel, we need to
ensure the requested min_uV meet the range of using the equation.
Otherwise we may select a voltage that is out of specified range.
For example, in
Signed-off-by: Axel Lin axel@gmail.com
---
drivers/regulator/twl-regulator.c | 24 +---
1 file changed, 13 insertions(+), 11 deletions(-)
diff --git a/drivers/regulator/twl-regulator.c
b/drivers/regulator/twl-regulator.c
index 03d0bea..8dae1e3 100644
---
On Sat, Jul 14, 2012 at 01:14:03AM +0200, Jiri Pirko wrote:
Fri, Jul 13, 2012 at 11:45:00PM CEST, jon.ma...@intel.com wrote:
A virtual ethernet device that uses the NTB transport API to send/receive
data.
Signed-off-by: Jon Mason jon.ma...@intel.com
---
drivers/net/Kconfig |4 +
On Fri, Jul 13, 2012 at 05:08:26PM -0700, Stephen Hemminger wrote:
On Fri, 13 Jul 2012 14:45:00 -0700
Jon Mason jon.ma...@intel.com wrote:
A virtual ethernet device that uses the NTB transport API to send/receive
data.
Signed-off-by: Jon Mason jon.ma...@intel.com
---
* John Stultz wrote:
> +static void tk_set_xtime(struct timekeeper *tk, const struct timespec *ts)
> +{
> + tk->xtime_sec = ts->tv_sec;
> + tk->xtime_nsec = ts->tv_nsec << tk->shift;
> +}
> +
> +
> +static void tk_xtime_add(struct timekeeper *tk, const struct timespec *ts)
Small nit:
Hi Linus,
Plese pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media
v4l_for_linus
for the fixes for the media subsystem, including:
- Some regression fixes at the audio part for devices with
cx23885/cx25840;
- A DMA corruption fix at cx231xx;
* John Stultz wrote:
> When we make adjustments speeding up the clock, its possible
> for xtime_nsec to underflow. We already handle this properly,
> but we do so from update_wall_time() instead of the more logical
> timekeeping_adjust(), where the possible underflow actually
> occurs.
>
>
On Fri 13 Jul 2012 02:54:26 PM JST, R, Durgadoss wrote:
As of now, we are getting the definitions done through the platform layer
data. Considerations for device tree .. yes.. but I do not have any sample
implementation..
Maybe we can help with that then, since we are going to need it.
On
* John Stultz wrote:
> +}
> +
> +
> +/**
Stray newline added here as well.
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 五, 2012-07-13 at 15:08 +0900, Alex Courbot wrote:
> On Fri 13 Jul 2012 02:54:26 PM JST, R, Durgadoss wrote:
> > As of now, we are getting the definitions done through the platform layer
> > data. Considerations for device tree .. yes.. but I do not have any sample
> > implementation..
>
>
* John Stultz wrote:
> + nsec >>= timekeeper.shift;
> +
> + /* If arch requires, add in gettimeoffset() */
> + nsec += arch_gettimeoffset();
> + return nsec;
As a factoring out bonus, this could be further shortened to:
return nsec + arch_gettimeoffset();
> + /*
Looks sensible.
Reviewed-by: Ingo Molnar
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
The @smsc.com email address is bouncing.
Should it be removed from MAINTAINERS or switched to this
@shawell.net address?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On 13/07/12 05:35, Raghavendra K T wrote:
> Yes! I forgot about archs in init function.
> How about having
> #ifdef CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT
> vcpu->ple.cpu_relax_intercepted = false;
> vcpu->ple.dy_eligible = false;
> #endif
>
> This would solve all the problem.
No, you need to mask
2012/07/12 21:41, Srivatsa S. Bhat wrote:
> On 07/12/2012 05:10 PM, Yasuaki Ishimatsu wrote:
>> Even if acpi_processor_handle_eject() offlines cpu, there is a chance
>> to online the cpu after that. So the patch closes the window by using
>> get/put_online_cpus().
>>
>> Why does the patch change
Hi Toshi,
2012/07/13 1:48, Toshi Kani wrote:
On Thu, 2012-07-12 at 20:22 +0900, Yasuaki Ishimatsu wrote:
Even if cpu_down() fails, acpi_processor_remove() continues to remove the cpu.
But in this case, it should return error number since some process may run on
the cpu. If the cpu has a
Hi Toshi,
2012/07/13 1:49, Toshi Kani wrote:
On Thu, 2012-07-12 at 20:40 +0900, Yasuaki Ishimatsu wrote:
Even if acpi_processor_handle_eject() offlines cpu, there is a chance
to online the cpu after that. So the patch closes the window by using
get/put_online_cpus().
Why does the patch change
On Fri, 2012-07-13 at 11:09 +0530, Laxman Dewangan wrote:
> On Friday 13 July 2012 08:45 AM, Vinod Koul wrote:
> > On Mon, 2012-07-02 at 10:02 -0600, Stephen Warren wrote:
> >> On 07/02/2012 02:22 AM, Laxman Dewangan wrote:
> >>> In cyclic mode of DMA, the byte transferred can be more
> >>> than
Hi Srivatsa,
2012/07/12 21:32, Srivatsa S. Bhat wrote:
> On 07/12/2012 04:52 PM, Yasuaki Ishimatsu wrote:
>> Even if cpu_down() fails, acpi_processor_remove() continues to remove the
>> cpu.
>> But in this case, it should return error number since some process may run on
>> the cpu. If the cpu
On Wed, Jun 13, 2012 at 04:22:40PM +0800, Sonic Zhang wrote:
> From: Michael Hennerich
>
> For transfer counts > 255 bytes i2c-bfin-twi sets the data
> transfer counter DCNT to 0xFF indicating unlimited transfers.
> It then uses a flag iface->manual_stop to manually issue the STOP
> condition,
On Thu, 2012-07-12 at 15:31 +0200, Thomas Gleixner wrote:
> On Thu, 12 Jul 2012, Mike Galbraith wrote:
> > On Thu, 2012-07-12 at 13:43 +0200, Thomas Gleixner wrote:
> > > rawlock points to ...968 and the node_list to ...970.
> > >
> > > struct rt_mutex {
> > > raw_spinlock_t
On Wed, Jun 13, 2012 at 04:22:43PM +0800, Sonic Zhang wrote:
> From: Sonic Zhang
>
> In order to mark I2C transfer fail when MEN bit in I2C controller is reset
> unexpeced
"unexpected"
> in MCOMP interrupt, interrupt status bits XMTSERV or RCVSERV should be
> checked.
>
> Master Transfer
On Wed, Jun 13, 2012 at 04:22:44PM +0800, Sonic Zhang wrote:
> From: Sonic Zhang
>
> Current driver was developed based on BF537 0.2 HRM. In high system load,
> BUFRDERR error
> interrupt may be raised if XMTSERV interrupt of last TX byte is not served in
> time
> (set RSTART bit), which
On Friday 13 July 2012 11:58 AM, Vinod Koul wrote:
On Fri, 2012-07-13 at 11:09 +0530, Laxman Dewangan wrote:
You didnt get my other mail about applying?
Read carefully now and saw both are applied.
Thanks for care.
Thanks,
Laxman
--
To unsubscribe from this list: send the line
On Wed, May 02, 2012 at 09:36:51PM -0700, Dmitry Torokhov wrote:
> Hi Sven,
>
> On Sat, Apr 07, 2012 at 08:38:33PM +0200, Sven Neumann wrote:
> > Hi,
> >
> > On 07.04.12 09:02, Dmitry Torokhov wrote:
> > >On Fri, Apr 06, 2012 at 10:40:07PM -0700, Olof Johansson wrote:
> > >>This seems to have
Hi Shan,
2012/7/12 shan kang :
> Hello,
>I wonder why smp_mb() is not needed in the "__mutex_fastpath_lock"
> and "__mutex_fastpath_unlock" functions which are located in the
> "arch/arm/include/asm/mutex.h"?
>I think "dmb" instruction is necessary there.
Why necessary? Could you explain
On Thursday, July 12, 2012 2:55 PM, Vivek Gautam wrote:
>
> This patch adds support to parse probe data for
> ehci driver for exynos using device tree
>
> Signed-off-by: Thomas Abraham
> Signed-off-by: Abhilash Kesavan
> Signed-off-by: Vivek Gautam
>
> diff --git
On Thursday, July 12, 2012 2:55 PM, Vivek Gautam wrote:
>
> This patch adds support to parse probe data for
> ohci driver for exynos using device tree.
>
> Signed-off-by: Thomas Abraham
> Signed-off-by: Abhilash Kesavan
> Signed-off-by: Vivek Gautam
>
> diff --git
On Fri, Jul 13, 2012 at 7:33 AM, Joe Perches wrote:
> Convert the existing uses of random_ether_addr to
> the new eth_random_addr.
>
> Signed-off-by: Joe Perches
For the rt2x00 parts:
Acked-by: Gertjan van Wingerde
> ---
> drivers/net/wireless/adm8211.c |2 +-
>
2012/07/13 1:50, Toshi Kani wrote:
On Thu, 2012-07-12 at 20:28 +0900, Yasuaki Ishimatsu wrote:
acpi_bus_trim() stops removing devices, when acpi_bus_remove() return error
number. But acpi_bus_remove() cannot return error number correctly.
acpi_bus_remove() only return -EINVAL, when dev argument
* Kukjin Kim [120712 15:13]:
>
> +1 same here, I'm interested in ARM mini-summit :)
Yeah me too!
Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Hi Miklos,
Thank you for your comments.
(2012/07/12 19:13), Miklos Szeredi wrote:
HAYASAKA Mitsuo writes:
Hi Yuan and Han-Wen,
Thank you for your comments.
(2012/07/06 22:58), Han-Wen Nienhuys wrote:
On Fri, Jul 6, 2012 at 2:53 AM, Liu Yuan wrote:
On 07/05/2012 06:50 PM, Mitsuo
On Fri, 2012-07-13 at 09:51 +0800, Zhang Rui wrote:
> On 四, 2012-07-12 at 04:54 -0600, R, Durgadoss wrote:
> > Hi,
> >
> > > -Original Message-
> > > From: Wei Ni [mailto:w...@nvidia.com]
> > > Sent: Thursday, July 12, 2012 3:53 PM
> > > To: Zhang, Rui; Brown, Len;
On Do, 12.07.2012, 23:35, Stephen Hemminger wrote:
> On Thu, 12 Jul 2012 22:55:57 +0200
> "Piotr Sawuk" wrote:
>
>> + * Federico D. Sacerdoti: Added TCP health monitoring.
>
> Please don't do this.
> The kernel community no longer maintains a list of contributors
> in the comments. The
Hi Pantelis,
In case you do not know the process of ARM core patches. You need to
put the patch into Russell's patch system [1] after review gets done.
Then the patch will show up on Russell's git tree.
Regards,
Shawn
[1] http://www.arm.linux.org.uk/developer/patches/
On Fri, May 25, 2012 at
On 五, 2012-07-13 at 15:30 +0800, Wei Ni wrote:
> On Fri, 2012-07-13 at 09:51 +0800, Zhang Rui wrote:
> > On 四, 2012-07-12 at 04:54 -0600, R, Durgadoss wrote:
> > > Hi,
> > >
> > > > -Original Message-
> > > > From: Wei Ni [mailto:w...@nvidia.com]
> > > > Sent: Thursday, July 12, 2012 3:53
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus
to receive updates for the input subsystem. The changes are limited to
adding new VID/PID combinations to drivers to enable support for new
versions of hardware, most notably hardware
BCM63XX implements the clk interface, but does not advertise it.
Signed-off-by: Jonas Gorski
---
This fixes a build failure in linux-next caused by
5afae362dc79cb8b6b3965422d13d118c63d4ee4 ("clk: Add non CONFIG_HAVE_CLK
routines"):
CC arch/mips/bcm63xx/clk.o
Hi Ted,
Did you get time to check this patch?
If possible, can you collect the patch from the last sent mail?
On Tue, Jul 10, 2012 at 9:56 PM, Ashish Sangwan
wrote:
> Whether to continue removing extents or not is decided by the return value
> of function ext4_ext_more_to_rm() which checks 2
Am Freitag, den 13.07.2012, 02:16 +0300 schrieb Michael S. Tsirkin:
> My concern was people will ask for more and more stuff that pci
> sysfs already has.
> If we do add these is there a way to not duplicate code from pci?
I have some concerns about the placing for the BAR mapping code inside
Use 'u32' for the LLI structure members, which are defined by hardware to be
32-bit. dma_addr_t is much more vague about its actual size.
Signed-off-by: Andy Shevchenko
---
drivers/dma/dw_dmac.c |7 ++-
drivers/dma/dw_dmac_regs.h |6 +++---
2 files changed, 5 insertions(+), 8
Signed-off-by: Andy Shevchenko
---
drivers/dma/dw_dmac.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
index 9151511..db56ef4 100644
--- a/drivers/dma/dw_dmac.c
+++ b/drivers/dma/dw_dmac.c
@@ -413,7 +413,7 @@ static void
The default values are filled to support at least mem-to-mem tests provided by
dmatest module. It makes sense to choose the 4 bytes (2 least significant bits)
alignment by the default.
Signed-off-by: Andy Shevchenko
---
drivers/dma/dw_dmac.c |6 ++
1 file changed, 6 insertions(+)
diff
On Fri, 2012-07-13 at 15:41 +0800, Zhang Rui wrote:
> On 五, 2012-07-13 at 15:30 +0800, Wei Ni wrote:
> > Our tegra thermal framework also will use the generic thermal layer. It
> > will register the cooling device, and run the throttling in this generic
> > framework.
> > But we have a special
* Oleg Nesterov [2012-07-08 22:30:11]:
> Kill insert_vm_struct()->uprobe_mmap(). It is not needed, nobody
> except arch/ia64/kernel/perfmon.c uses insert_vm_struct(vma) with
> vma->vm_file != NULL.
>
Right, but somebody else might start using this later.
I cant think of a use case though.
>
On Thu, Jun 28, 2012 at 01:59:19PM +0300, Mika Westerberg wrote:
> This is similar than what is done for other busses before (PCI, I2C, SPI,
> platform). It reduces a lot of unnecessary boilerplate code from modules.
>
> We also remove following redundant check on few drivers:
>
> if
* Oleg Nesterov [2012-07-08 22:30:08]:
> Kill copy_vma()->uprobe_mmap(new_vma), it is absolutely wrong.
>
> This new_vma was just initialized to represent the new unmapped area,
> [vm_start, vm_end) was returned by get_unmapped_area() in the caller.
>
> This means that
On Thu 12-07-12 15:42:53, Hugh Dickins wrote:
> On Thu, 12 Jul 2012, Andrew Morton wrote:
> > On Thu, 12 Jul 2012 09:05:01 +0200
> > Michal Hocko wrote:
> >
> > > When we are back to the patch. Is it going into 3.5? I hope so and I
> > > think it is really worth stable as well. Andrew?
> >
> >
Hi,
looks like [1] is fixing my suspend/resume problem with v3.5-rc6+
(attached call-trace is with a v3.5-rc6 kernel before the commit got
upstream).
Thanks for the fix!
I am wondering if those new-lines are intended (see attachment)?
- Sedat -
P.S.: Commit details
commit
It would be nice to keep spear-devel in cc, as this is the second
platform that uses this driver.
On Fri, Jul 13, 2012 at 9:09 AM, Andy Shevchenko
wrote:
> The default values are filled to support at least mem-to-mem tests provided by
> dmatest module. It makes sense to choose the 4 bytes (2
On Fri, Jul 13, 2012 at 9:09 AM, Andy Shevchenko
wrote:
> Signed-off-by: Andy Shevchenko
> ---
> drivers/dma/dw_dmac.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
> index 9151511..db56ef4 100644
> ---
On Fri, Jul 13, 2012 at 9:09 AM, Andy Shevchenko
wrote:
> Use 'u32' for the LLI structure members, which are defined by hardware to be
> 32-bit. dma_addr_t is much more vague about its actual size.
>
> Signed-off-by: Andy Shevchenko
> ---
> drivers/dma/dw_dmac.c |7 ++-
>
Hi Joe,
> On 13 July 2012 07:13, Joe Perches wrote:
>
> The @smsc.com email address is bouncing.
> Should it be removed from MAINTAINERS or switched to this
> @shawell.net address?
It should be changed, I posted a patch to do this back in April - I guess
it didn't get picked up. Did I need to
On 13/07/12 08:58, Jonas Gorski wrote:
> BCM63XX implements the clk interface, but does not advertise it.
>
> Signed-off-by: Jonas Gorski
> ---
>
> This fixes a build failure in linux-next caused by
> 5afae362dc79cb8b6b3965422d13d118c63d4ee4 ("clk: Add non CONFIG_HAVE_CLK
> routines"):
>
> CC
When populate pages across a mem boundary at bootup, the page count
populated isn't correct. This is due to mem populated to non-mem
region and ignored.
Pfn range is also wrongly aligned when mem boundary isn't page aligned.
-v2: If xen_do_chunk fail(populate), abort this chunk and any others.
On Wed, May 30, 2012 at 11:43:05AM +0200, Karol Lewandowski wrote:
> This commit fixes warning introduced in 27452498a ("i2c-s3c2410: Rework
> device type handling"):
>
> drivers/i2c/busses/i2c-s3c2410.c: In function 's3c24xx_get_device_quirks':
> drivers/i2c/busses/i2c-s3c2410.c:125:
This patchset implements bio-based IO path for virito-blk to improve
performance.
Fio test shows bio-based IO path gives the following performance improvement:
1) Ramdisk device
With bio-based IO path, sequential read/write, random read/write
IOPS boost : 28%, 24%, 21%, 16%
This patch introduces bio-based IO path for virtio-blk.
Compared to request-based IO path, bio-based IO path uses driver
provided ->make_request_fn() method to bypasses the IO scheduler. It
handles the bio to device directly without allocating a request in block
layer. This reduces the IO path in
On Thu, Jul 12, 2012 at 10:02 PM, Bjorn Helgaas wrote:
> Why don't you fix this right where the problem occurs, in
> __reserve_region_with_split(), with something like this:
>
> if (end > conflict->start && conflict->start > start)
> __reserve_region_with_split(root,
Split the mapping code in blk_rq_map_sg() to a helper
__blk_segment_map_sg(), so that other mapping function, e.g.
blk_bio_map_sg(), can share the code.
Cc: Jens Axboe
Cc: Tejun Heo
Cc: Shaohua Li
Cc: linux-kernel@vger.kernel.org
Suggested-by: Tejun Heo
Suggested-by: Jens Axboe
Add a helper to map a bio to a scatterlist, modelled after
blk_rq_map_sg.
This helper is useful for any driver that wants to create
a scatterlist from its ->make_request_fn method.
Changes in v2:
- Use __blk_segment_map_sg to avoid duplicated code
- Add cocbook style function comment
Cc: Jens
On Fri, Jul 13, 2012 at 11:26 AM, viresh kumar wrote:
> It would be nice to keep spear-devel in cc, as this is the second
> platform that uses this driver.
I used to get the list of recipients via get_maintainer script. Will
try to not forget about that address in the future.
>> The default
Even if cpu_down() fails, acpi_processor_remove() continues to remove the cpu.
But in this case, it should return error number since some process may run on
the cpu. If the cpu has a running process and the cpu is turned the power off,
the system may not work well.
Reviewed-by: Srivatsa S. Bhat
Hello,
[I added git@vger.k.o to Cc: please strip the recipents accordingly if
you reply.]
On Fri, Jul 13, 2012 at 09:02:56AM +1000, Marc Reilly wrote:
> Hi Uwe,
>
> > This series was tested on a Phytec pcm038 (mc13783 on spi) using
> > traditional boot (i.e. not dt) and on a i.MX53 based
Even if acpi_processor_handle_eject() offlines cpu, there is a chance
to online the cpu after that. So the patch closes the window by using
get/put_online_cpus().
Why does the patch change _cpu_up() logic?
The patch cares the race of hot-remove cpu and _cpu_up(). If the patch
does not change it,
acpi_bus_trim() stops removing devices, when acpi_bus_remove() return error
number. But acpi_bus_remove() cannot return error number correctly.
acpi_bus_remove() only return -EINVAL, when dev argument is NULL. Thus even if
device cannot be removed correctly, acpi_bus_trim() ignores and continues
Hi folks,
[I am resending to fix the broken thread in the previous one.]
This patchset adds vhost-blk support. vhost-blk is a in kernel virito-blk
device accelerator. Compared to userspace virtio-blk implementation, vhost-blk
gives about 5% to 15% performance improvement.
Asias He (5):
aio:
This is useful for people who want to create an eventfd in kernel,
e.g. vhost-blk.
Cc: Alexander Viro
Cc: Jeff Moyer
Cc: Michael S. Tsirkin
Cc: linux-fsde...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: k...@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by:
vhost-blk is a in kernel virito-blk device accelerator.
This patch is based on Liu Yuan's implementation with various
improvements and bug fixes. Notably, this patch makes guest notify and
host completion processing in parallel which gives about 60% performance
improvement compared to Liu Yuan's
This is useful for people who want to use aio in kernel, e.g. vhost-blk.
Cc: Benjamin LaHaise
Cc: Alexander Viro
Cc: Jeff Moyer
Cc: James Bottomley
Cc: Michael S. Tsirkin
Cc: linux-...@kvack.org
Cc: linux-fsde...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: k...@vger.kernel.org
Cc:
vhost-net's feature does not deseve the name VHOST_FEATURES. Use
VHOST_NET_FEATURES instead.
Cc: Michael S. Tsirkin
Cc: linux-kernel@vger.kernel.org
Cc: k...@vger.kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Signed-off-by: Asias He
---
drivers/vhost/net.c |4 ++--
On 13/07/12 09:45, Andy Shevchenko wrote:
>> > To understand it more, what does this mean? We will not support
>> > transfers with unaligned
>> > addresses/length to word size?
> The dmatest module uses those constants to get source, destination
> addresses and length of the test data aligned. On
Currently, vhost-net is the only consumer of vhost infrastructure. So
vhost infrastructure and vhost-net driver are in a single module.
Separating this as a vhost.ko module and a vhost-net.ko module makes it
is easier to share code with other vhost drivers, e.g. vhost-blk.ko,
tcm-vhost.ko.
Cc:
On Thu, Jul 12, 2012 at 8:40 PM, Valentin, Eduardo
wrote:
> Amit,
>
> On Thu, Jul 12, 2012 at 4:41 PM, Amit Daniel Kachhap
> wrote:
>> This patchset introduces a new generic cooling device based on cpufreq
>> that can be used on non-ACPI platforms. As a proof of concept, we have
>> drivers for
At 07/09/2012 06:26 PM, Yasuaki Ishimatsu Wrote:
> When (hot)adding memory into system, /sys/firmware/memmap/X/{end, start, type}
> sysfs files are created. But there is no code to remove these files. The patch
> implements the function to remove them.
>
> Note : The code does not free
For example, in the following scenario, Process2 may get the wrong value;
Process1:
mutex_lock();
write data; (store operation)
mutex_unlock();
Process2:
mutex_lock();
read data; (load operation)
mutex_unlock();
Suppose Process1 gets the lock first, write data and unlock. If the
store operation
On 12 July 2012 18:24, Thomas Abraham wrote:
> Some platforms allow for clock gating and control of bus interface unit clock
> and card interface unit clock. Add support for clock lookup of optional biu
> and ciu clocks for clock gating and clock speed determination.
>
> Signed-off-by: Abhilash
On Thu, Jul 12, 2012 at 10:02:42AM -0700, Paul E. McKenney wrote:
> On Fri, Jul 13, 2012 at 12:57:38AM +0800, Fengguang Wu wrote:
> > On Thu, Jul 12, 2012 at 09:43:08AM -0700, Paul E. McKenney wrote:
> > > On Wed, Jul 11, 2012 at 12:49:24AM -0700, Paul E. McKenney wrote:
> > > > On Tue, Jul 10,
From: "G.Shark Jeong"
LM3554 :
The LM3554 is a 2 MHz fixed-frequency synchronous boost
converter with 1.2A dual high side led drivers.
Datasheet: www.ti.com
G.Shark Jeong (1):
leds: Add LED driver for lm3554 chip
drivers/leds/Kconfig |8 +
drivers/leds/Makefile
From: "G.Shark Jeong"
LM3554 :
The LM3554 is a 2 MHz fixed-frequency synchronous boost
converter with 1.2A dual high side led drivers.
Datasheet: www.ti.com
Signed-off-by: G.Shark Jeong
---
drivers/leds/Kconfig |8 +
drivers/leds/Makefile |1 +
This patch is a driver for SiS964 I2C bus.
It was forked from i2c-sis630 and modified with SiS datasheets.
Tested with kmemleak.
Signed-off-by: Amaury Decrême
---
Documentation/i2c/busses/i2c-sis964 | 34 ++
MAINTAINERS | 16 +
drivers/i2c/busses/Kconfig |
On 07/13/2012 05:19 AM, Rob Herring wrote:
What's implemented in Linux should not define the binding. The binding
should describe the hardware.
[...]
True, but not your problem to implement. A binding doesn't necessarily
mean there is a full Linux implementation. We just don't want to create
On Fri, Jul 13, 2012 at 10:10:52AM +0100, shan kang wrote:
> For example, in the following scenario, Process2 may get the wrong value;
> Process1:
> mutex_lock();
> write data; (store operation)
> mutex_unlock();
>
> Process2:
> mutex_lock();
> read data; (load operation)
> mutex_unlock();
Yes,
Hi,
while dealing with [1], I saw this mei-related infos in dmesg when
doing a suspend + resume (see [1] for more logs):
[17046.348467] [] mei_pci_suspend+0x78/0xd0 [mei]
[17047.460315] mei :00:16.0: irq 47 for MSI/MSI-X
[17047.460512] mei :00:16.0: request_threaded_irq failed: irq =
On Thu, Jul 05, 2012 at 05:02:12PM -0700, Colin Cross wrote:
[...]
> KGDB can obviously only be enabled on development
> devices, although perhaps a more limited KDB could be left enabled.
Um, I would argue about 'obviously'. :-) It doesn't require
CONFIG_DEBUG_INFO (-g) or something like this,
On Fri, 13 Jul 2012, Mike Galbraith wrote:
> On Thu, 2012-07-12 at 15:31 +0200, Thomas Gleixner wrote:
> > Bingo, that makes it more likely that this is caused by copying w/o
> > initializing the lock and then freeing the original structure.
> >
> > A quick check for memcpy finds that
401 - 500 of 836 matches
Mail list logo
