Otherwise the value from the last probe would be retained that possibly is
freed since (the UDC is removed) and therefore no longer relevant. Reproducible
with the dummy UDC:
modprobe dummy_hcd
mount -t gadgetfs gadgetfs /dev/gadget
umount /dev/gadget
rmmod dummy_hcd
mount -t gadgetfs ga
* Mike Galbraith wrote:
> On Thu, 2014-03-27 at 02:37 +0800, Yuyang du wrote:
> > Hi all,
> >
> > This is continued after the first RFC about splitting the scheduler. Still
> > work-in-progress, and call for feedback.
> >
> > The question addressed here is how load balance should be changed.
Hi all,
This tree still fails (more than usual) the powerpc allyesconfig build.
Changes since 20140325:
The powerpc tree still had its build failure.
The staging tree gained a conflict against the net-next tree.
Non-merge commits (relative to Linus' tree): 11008
9412 files changed, 451457 ins
Hi Michal,
On 03/27/2014 01:53 AM, Michal Hocko wrote:
> On Wed 26-03-14 19:28:04, Vladimir Davydov wrote:
>> We don't track any random page allocation, so we shouldn't track kmalloc
>> that falls back to the page allocator.
> Why did we do that in the first place? d79923fad95b (sl[au]b: allocate
Hi Greg,
On 03/27/2014 08:31 AM, Greg Thelen wrote:
> On Wed, Mar 26 2014, Vladimir Davydov wrote:
>
>> We don't track any random page allocation, so we shouldn't track kmalloc
>> that falls back to the page allocator.
> This seems like a change which will leads to confusing (and arguably
> impro
"Michael S. Tsirkin" writes:
> On Wed, Mar 26, 2014 at 11:08:03PM -0300, Alejandro Comisario wrote:
>> Hi List!
>> Hope some one can help me, we had a big issue in our cloud the other
>> day, a couple of our openstack regions ( +2000 kvm guests with qcow2 )
>> went read only filesystem from the g
On 03/27/2014 01:58 AM, Michal Hocko wrote:
> On Wed 26-03-14 19:28:05, Vladimir Davydov wrote:
>> We have only a few places where we actually want to charge kmem so
>> instead of intruding into the general page allocation path with
>> __GFP_KMEMCG it's better to explictly charge kmem there. All km
On 03/27/2014 02:00 AM, Michal Hocko wrote:
> On Wed 26-03-14 19:28:06, Vladimir Davydov wrote:
>> We have only a few places where we actually want to charge kmem so
>> instead of intruding into the general page allocation path with
>> __GFP_KMEMCG it's better to explictly charge kmem there. All km
On Tue, Mar 25, 2014 at 09:58:45PM +0200, Aaro Koskinen wrote:
> Enabling EARLY_PRINTK_8250 breaks OCTEON builds because of multiple
> prom_putchar() implementations. OCTEON provides its own prom_putchar()
> (also used by the watchdog driver), so we should prevent user from
> selecting EARLY_PRINT
On many new phone/tablet platforms like Baytrail/Merrifield etc,
the HPET are either defeatured or has some problem to be used
as a reliable timer. As these platforms also have X86_64, we
should not make HPET_TIMER default y for all X86_64.
Signed-off-by: Feng Tang
---
arch/x86/Kconfig |3 +-
Le 26/03/2014 21:14, Fabio Estevam a écrit :
On Wed, Mar 26, 2014 at 4:57 PM, Sylwester Nawrocki
wrote:
Perhaps a change as below helps ?
From 85ee85e4a92b42442354f3f2454be50c173e1c59 Mon Sep 17 00:00:00 2001
From: Sylwester Nawrocki
Date: Wed, 26 Mar 2014 20:54:13 +0100
Subject: [PATCH] cl
With CONFIG_LPAE=y, memory in 32-bit ARM systems can exceed
4G. So if we use kdump in such systems. The capture kernel
should parse 64-bit elf header(parse_crash_elf64_headers).
And this process can not pass because ARM linux does not
supply related check function.
This patch adds check functions
For vmcore generated by LPAE enabled kernel, user space
utility such as crash needs additional infomation to
parse.
So this patch add arch_crash_save_vmcoreinfo as what PAE enabled
i386 linux does.
Signed-off-by: Liu Hua
To: Russell King
Cc: Stephen Warren
Cc: Will Deacon
Cc: Vijaya Kumar K
For 32-bit ARM systems with CONFIG_ARM_LPAE=y, when kexec utility
loads the crash kernel. 32-bit elf header is not enough if the
physical address exceeds 4G.
This patch check whether the largest physical address of the system
exceeds 4G. If so, kexec creates 64-bit elf header.Otherwise it
creates
On 27 March 2014 06:35, wrote:
> From: Micky Ching
>
> v2:
> fix checkpatch warning.
> WARNING: Missing a blank line after declarations
>
> v1:
> Add new command type(R1 without CRC) handle, without this
> patch mmc card initialize will be failed.
>
> Using a more careful handle in request timeo
On Thu, Mar 27, 2014 at 08:36:57AM +0100, Markus Armbruster wrote:
> "Michael S. Tsirkin" writes:
>
> > On Wed, Mar 26, 2014 at 11:08:03PM -0300, Alejandro Comisario wrote:
> >> Hi List!
> >> Hope some one can help me, we had a big issue in our cloud the other
> >> day, a couple of our openstack
Signed-off-by: Boris BREZILLON
---
arch/arm/boot/dts/imx6qdl.dtsi |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index cfc85be..060e94c 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -
Sometimes we won't need all the information from
get_xtime_and_monotonic_and_sleep_offset(),
so let's check the params before assign the value to them.
Signed-off-by: Neil Zhang
---
kernel/time/timekeeping.c |9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/kernel/t
Add sleep time into timestamp to reflect the actual time since
sched_clock will be stopped during suspend.
This patch depends on the following patch.
timekeeping: check params before use them
Signed-off-by: Neil Zhang
---
kernel/printk/printk.c | 15 +--
1 file changed, 13 inserti
Hi Geert,
> > From: Angus Clark
> >
> > Add Macronix MX25L25655E to the list of known devices.
> >
> > Signed-off-by: Angus Clark
> > Signed-off-by: Lee Jones
> > ---
> > drivers/mtd/devices/st_spi_fsm.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/mtd/devices/st_s
Am 26.03.2014 23:37, schrieb Alexander Holler:
Am 26.03.2014 22:55, schrieb Alexander Holler:
Am 26.03.2014 22:38, schrieb Levente Kurusa:
This is walkable but probably not worth the effort. Besides, why would
anyone want to put spaces, colons and arbitrary characters to filenames
in the init
On 03/27/2014 03:38 AM, Mike Turquette wrote:
Quoting Lars-Peter Clausen (2014-02-26 22:20:53)
On 02/27/2014 02:04 AM, Mike Turquette wrote:
Quoting Lars-Peter Clausen (2014-02-17 01:31:53)
This patch adds support for the new v2 version of the axi-clkgen core.
Unfortunately the method of acces
On Fri, Mar 21, 2014 at 2:06 PM, Peter Hurley wrote:
>> When a serial port is closed, uart_close() takes care of shutting down the
>> hardware, and powering it down.
>>
>> When a serial port is unbound while in use, uart_close() bypasses all of
>> this, as this is supposed to be done through uart_
Le 27/03/2014 09:11, Boris BREZILLON a écrit :
Signed-off-by: Boris BREZILLON
---
arch/arm/boot/dts/imx6qdl.dtsi |4
1 file changed, 4 insertions(+)
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index cfc85be..060e94c 100644
--- a/arch/arm/boot/dts/imx
On Fri, Mar 21, 2014 at 2:06 PM, Peter Hurley wrote:
>> When a serial port is closed, uart_close() takes care of shutting down the
>> hardware, and powering it down.
>>
>> When a serial port is unbound while in use, uart_close() bypasses all of
>> this, as this is supposed to be done through uart_
On 27/03/14 09:27, Alexander Yarygin wrote:
>
> Trace events potentially can have a '-' in their trace system name,
> e.g. kvm on s390 defines kvm-s390:* tracepoints.
> tools/perf could not parse them, because there was no rule for this:
> $ sudo ./perf top -e "kvm-s390:*"
> invalid or unsupported
On 03/27/2014 07:01 AM, Sasha Levin wrote:
Commit 4af712e8df ("random32: add prandom_reseed_late() and call when
nonblocking pool becomes initialized") has added a late reseed stage
that happens as soon as the nonblocking pool is marked as initialized.
This fails in the case that the nonblocking
On Thu, Mar 27, 2014 at 10:10:40AM +0200, Michael S. Tsirkin wrote:
> On Thu, Mar 27, 2014 at 08:36:57AM +0100, Markus Armbruster wrote:
> > "Michael S. Tsirkin" writes:
> >
> > > On Wed, Mar 26, 2014 at 11:08:03PM -0300, Alejandro Comisario wrote:
> > >> Hi List!
> > >> Hope some one can help me
For the following cases of the SoCs using regmap-mmio:
Index CPU mode Device mode Need Bytes Swap ?
--
1 LE LENo
2 LE BEYes
3 BE BENo
4 BE LE
On 03/27/2014 03:21 AM, Hannes Frederic Sowa wrote:
On Wed, Mar 26, 2014 at 07:35:01PM -0400, Sasha Levin wrote:
On 03/26/2014 07:18 PM, Daniel Borkmann wrote:
On 03/26/2014 06:12 PM, Sasha Levin wrote:
Commit 4af712e8df ("random32: add prandom_reseed_late() and call when
nonblocking pool beco
On 03/26/14 16:10, Mauro Carvalho Chehab wrote:
Em Wed, 26 Mar 2014 15:55:07 +0100
"Rafael J. Wysocki" escreveu:
On Wednesday, March 26, 2014 01:08:10 PM Tomasz Nowicki wrote:
Hi,
Hi,
This is a question for Tony, Boris and Mauro (CCed now).
Currently APEI depends on x86 architecture. It
On 03/26/2014 11:41 PM, Songhee Baek wrote:
-Original Message-
From: Lars-Peter Clausen [mailto:l...@metafoo.de]
Sent: Wednesday, March 26, 2014 12:39 PM
To: Arun Shamanna Lakshmi
Cc: lgirdw...@gmail.com; broo...@kernel.org; swar...@wwwdotorg.org;
Songhee Baek; alsa-de...@alsa-project.org
On 03/26/14 21:36, Borislav Petkov wrote:
On Wed, Mar 26, 2014 at 12:10:47PM -0300, Mauro Carvalho Chehab wrote:
Yet, it would be better if you could be a little more specific about
what are your plans and what are the common/not-common features that
you're mapping.
Well, I don't see anything
On Thu, Mar 27, 2014 at 10:04:03AM +0100, Daniel Borkmann wrote:
> On 03/27/2014 03:21 AM, Hannes Frederic Sowa wrote:
> >On Wed, Mar 26, 2014 at 07:35:01PM -0400, Sasha Levin wrote:
> >>On 03/26/2014 07:18 PM, Daniel Borkmann wrote:
> >>>On 03/26/2014 06:12 PM, Sasha Levin wrote:
> Commit 4af7
On 28 February 2014 12:49, Ulf Hansson wrote:
> The sdio func device is added to the driver model after the card
> device.
>
> This means the sdio func device will be suspend before the card device
> and thus resumed after. The consequence are the mmc core don't
> explicity need to protect itself
Hi Peter,
On Wed, Mar 26, 2014 at 9:10 PM, Peter Hurley wrote:
> On 03/26/2014 02:58 PM, Geert Uytterhoeven wrote:
>> Thanks for your comments!
>
> Not a problem; just wanted to save you some time and frustration :)
Much appreciated!
>> On Fri, Mar 21, 2014 at 9:29 PM, Peter Hurley
>> wrote:
>
When mergeable buffers are disabled, and the
incoming packet is too large for the rx buffer,
get_rx_bufs returns success.
This was intentional in order for make recvmsg
truncate the packet and then handle_rx would
detect err != sock_len and drop it.
Unfortunately we pass the original sock_len to
From: Mark Brown
> On Wed, Mar 26, 2014 at 11:59:53AM +, David Laight wrote:
> > From: Nicolin Chen
>
> > > + regmap_read(sai->regmap, FSL_SAI_TCSR, &xcsr);
> > > + regmap_write(sai->regmap, FSL_SAI_TCSR, xcsr);
>
> > Assuming these are 'write to clear' bits, you might want
> > to make the wr
> -Original Message-
> From: Sander Eikelenboom [mailto:li...@eikelenboom.it]
> Sent: 26 March 2014 19:57
> To: Paul Durrant
> Cc: Wei Liu; annie li; Zoltan Kiss; xen-de...@lists.xen.org; Ian Campbell;
> linux-
> kernel; net...@vger.kernel.org
> Subject: Re: [Xen-devel] Xen-unstable Linux
> -Original Message-
> From: Sander Eikelenboom [mailto:li...@eikelenboom.it]
> Sent: 26 March 2014 20:18
> To: Paul Durrant
> Cc: Wei Liu; annie li; Zoltan Kiss; xen-de...@lists.xen.org; Ian Campbell;
> linux-
> kernel; net...@vger.kernel.org
> Subject: Re: [Xen-devel] Xen-unstable Linux
On Thu, Mar 27, 2014 at 11:38:41AM +0200, Michael S. Tsirkin wrote:
> When mergeable buffers are disabled, and the
> incoming packet is too large for the rx buffer,
> get_rx_bufs returns success.
>
> This was intentional in order for make recvmsg
> truncate the packet and then handle_rx would
> de
Thursday, March 27, 2014, 10:47:02 AM, you wrote:
>> -Original Message-
>> From: Sander Eikelenboom [mailto:li...@eikelenboom.it]
>> Sent: 26 March 2014 19:57
>> To: Paul Durrant
>> Cc: Wei Liu; annie li; Zoltan Kiss; xen-de...@lists.xen.org; Ian Campbell;
>> linux-
>> kernel; net...@vge
Hi Boris,
On 27/03/14 08:58, Boris BREZILLON wrote:
> This solution solve the problem for this specific case because clks are
> declared in the correct order in imx DTs.
> But, even with your patch I think we could see similar issues by
> reordering DT nodes...
>
> The real problem here is that
Hrmm i don't know if it's your mailer or my mailer .. but i seem to get a lot
of your mails truncated somehow :S
though the xen-devel list archive seem to have them in complete form .. so it's
probably my mailer tripping over something
> I'll come up with some patches shortly.
OK will test them
On Sat, Mar 22, 2014 at 2:31 AM, Bartlomiej Zolnierkiewicz
wrote:
> Hi,
>
> This patch series generalizes PPMU support for Exynos devfreq
> drivers.
>
> It is based on top of "devfreq: exynos: Fix minor issue and code
> clean to remove legacy method" patch series from Chanwoo Choi
> (https://lk
CPUFreq core doesn't control value of .driver_data and this field is completely
driver specific. This can contain any value and not only indexes. For most of
the drivers, which aren't using this field, its value is zero. So, printing this
from core doesn't make any sense. Don't print it.
Signed-of
On 03/27/2014 11:58 AM, Srivatsa S. Bhat wrote:
>
> Actually, my suggestion was to remove the dying CPU from the force_mask alone,
> in the CPU_DYING notifier. The rest of the cleanup (removing it from the other
> masks, moving the broadcast duty to someone else etc can still be done at
> the CPU_
On 03/27/2014 03:37 PM, Viresh Kumar wrote:
> CPUFreq core doesn't control value of .driver_data and this field is
> completely
> driver specific. This can contain any value and not only indexes. For most of
> the drivers, which aren't using this field, its value is zero. So, printing
> this
> fr
Hello,
[1.971778] [ cut here ]
[1.971960] WARNING: CPU: 1 PID: 6 at mm/page_alloc.c:2497
__alloc_pages_nodemask+0x1b9/0x693()
[1.972246] Modules linked in: sd_mod ahci
[1.972604] CPU: 1 PID: 6 Comm: kworker/u8:0 Not tainted
3.14.0-rc8-next-20140327-dbg
> > After taking a quick glance at the whole driver I noticed you have something
> > strange going on. AFAIK, the typical NAND driver probe() should be one of
> > these two:
> >
> > * Call nand_scan() which calls nand_scan_ident() + nand_scan_tail().
> >
> > * Call nand_scan_ident() to identify t
When mergeable buffers are disabled, and the
incoming packet is too large for the rx buffer,
get_rx_bufs returns success.
This was intentional in order for make recvmsg
truncate the packet and then handle_rx would
detect err != sock_len and drop it.
Unfortunately we pass the original sock_len to
Hi,
I've attached another oops (initial one from untainted kernel, and
then successive ones) on the same machine.
Please see the HW stress-testing I've already done below (without
seeing such an oops). Any further suggestions?
Also, how can I tell from the registers you decoded (below) that it'
From: Geert Uytterhoeven
When a serial port is closed, uart_close() takes care of shutting down the
hardware, and powering it down.
When a serial port is unbound while in use, uart_close() bypasses all of
this, as this is supposed to be done through uart_hangup() (invoked via
tty_vhangup() in ua
From: Geert Uytterhoeven
Signed-off-by: Geert Uytterhoeven
---
arch/sh/drivers/pci/pcie-sh7786.h |3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/sh/drivers/pci/pcie-sh7786.h
b/arch/sh/drivers/pci/pcie-sh7786.h
index 1ee054e47eae..4a6ff55f759b 100644
--- a/arch/sh/drivers/pci/pcie
This restores the default clocks registration order as parsed from
devicetree, i.e. as before commit 1771b10d605d26ccee771a7fb4b08718
"clk: respect the clock dependencies in of_clk_init", for when there
is no explicit parent clock dependencies between clock providers
specified in the device tree.
On 27/03/14 11:43, Sylwester Nawrocki wrote:
> This restores the default clocks registration order as parsed from
> devicetree, i.e. as before commit 1771b10d605d26ccee771a7fb4b08718
> "clk: respect the clock dependencies in of_clk_init", for when there
> is no explicit parent clock dependencies be
On Thu, Mar 27, 2014 at 03:37:22PM +0530, Viresh Kumar wrote:
> CPUFreq core doesn't control value of .driver_data and this field is
> completely
> driver specific. This can contain any value and not only indexes. For most of
> the drivers, which aren't using this field, its value is zero. So, pr
On Wed, Mar 26, 2014 at 12:55:02PM +0100, Lothar Waßmann wrote:
> Hi,
>
> Huang Shijie wrote:
> > 于 2014年03月26日 16:51, Lothar Waßmann 写道:
> > > I don't see why this should not be supported on i.MX28 (i.MX23 doesn't
> > > do byteswapping anyway, so this wouldn't change anything for i.MX23).
> > > T
On Mon, Mar 24, 2014 at 10:36 AM, Chanwoo Choi wrote:
> Hi Tomasz,
>
> On 03/22/2014 11:52 PM, Tomasz Figa wrote:
>> Hi,
>>
>> [fixing mistyped addresses of me and Bartlomiej]
>>
>> On 20.03.2014 03:59, Chanwoo Choi wrote:
>>> This patchset use SIMPLE_DEV_PM_OPS macro intead of legacy method and
vhost fails to validate negative error code
from vhost_get_vq_desc causing
a crash: we are using -EFAULT which is 0xfff2
as vector size, which exceeds the allocated size.
The code in question was introduced in commit
8dd014adfea6f173c1ef6378f7e5e7924866c923
vhost-net: mergeable buffers sup
Mike, please ignore this patch for now. It turns out a less intrusive
change [1] is enough to fix the regressions on both imx and exynos.
I'm going to address the issue properly for next kernel release and
make exynos use regular fixed-clock driver, rather than registering
the external clock gener
On Thu, Mar 27, 2014 at 11:57:27AM +0800, Nicolin Chen wrote:
> On Thu, Mar 27, 2014 at 12:06:53PM +0800, Xiubo Li-B47053 wrote:
> > I have checked in the Vybrid and LS1 SoC datasheets, and they are all the
> > Same as above, and nothing else.
> > Have I missed ?
> What i.MX IC team told me is S
On Thu, Mar 27, 2014 at 12:42:42PM +0800, Xiubo Li wrote:
> Signed-off-by: Xiubo Li
Applied both, thanks.
signature.asc
Description: Digital signature
On 27 March 2014 16:18, Gautham R Shenoy wrote:
> So after this patch, driver_data is only going to be used by drivers
> which want an "unsigned int" value to be saved along with the
> frequency in the frequency_table and for those who want to overload
> its interpretation to indicate BOOST.
>
> F
Feng Tang wrote:
> On many new phone/tablet platforms like Baytrail/Merrifield etc,
> the HPET are either defeatured or has some problem to be used
> as a reliable timer. As these platforms also have X86_64, we
> should not make HPET_TIMER default y for all X86_64.
The help text still says:
| You
.driver_data field is only required to be filled if drivers want to preserve
some data in there which they can use according to the value of .frequency
field. But this driver isn't using this field at all, but just setting it equal
to the index value. Which isn't required. Fix it.
Signed-off-by: V
Hi all,
We're facing an issue that we cannot add 64 VLANs or more per VF.
When using SR-IOV, pass through a VF to the KVM guest and a lot of VLANs,
we could add 63 VLANs using vconfig but we failed to add 64th VLAN.
We'd like to use many VLANs on the guest with SR-IOV.
We're using Intel's 82599EB
Presently, after we fail the first try to walk the pcpu_slot list
to find a chunk for allocating, we just drop the pcpu_lock spinlock,
and go allocating a new chunk. Then we re-gain the pcpu_lock and
anchoring our hope on that during this period, some guys might have
freed space for us(we still hol
It's quite cricial to clear error flags because SAI might hang if getting
FIFO underrun during playback (I haven't confirmed the same issue on Rx
overflow though).
So this patch enables those irq and adds isr() to clear the flags so as to
keep playback entirely safe.
Signed-off-by: Nicolin Chen
During pcpu_alloc_area(), we might merge the current head with the
previous block. Since we have calculated the max_contig using the
size of previous block before we skip it, and now we update the size
of previous block, so we should renew the max_contig.
Signed-off-by: Jianyu Zhan
---
mm/percpu
Hi all,
This is a trivial fix, but I think the patch itself has problem too.
The function requires a phys_addr_t, but we feed it with a dma_handle_t.
AFAIK, this implicit conversion does not always work.
Can I use virt_to_phys(mem->vaddr) to get the physical address instead?
(mem->vaddr and mem->
Signed-off-by: Sylwester Nawrocki
---
drivers/clk/clk.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index c859adf..29dc1e7 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -2575,7 +2575,7 @@ static int parent_ready(stru
The second argument should be physical address rather than virtual address.
Signed-off-by: Ma Haijun
---
drivers/media/v4l2-core/videobuf-dma-contig.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/media/v4l2-core/videobuf-dma-contig.c
b/drivers/media/v4l2-core/vide
Hi Hanjun,
On 25/03/14 11:09, Hanjun Guo wrote:
> Hi Sudeep,
>
> On 2014-3-25 18:00, Sudeep Holla wrote:
>> Hi Hanjun,
>>
>> On 25/03/14 09:00, Hanjun Guo wrote:
>>> After commit 74397174989e5 (arm64: Fix duplicated Kconfig entries),
>>> I still get a duplicate Power management options section in
Hi Sylwester,
Le 27/03/2014 11:01, Sylwester Nawrocki a écrit :
Hi Boris,
On 27/03/14 08:58, Boris BREZILLON wrote:
This solution solve the problem for this specific case because clks are
declared in the correct order in imx DTs.
But, even with your patch I think we could see similar issues by
On Thu, Mar 27, 2014 at 5:11 AM, Boris BREZILLON
wrote:
> Signed-off-by: Boris BREZILLON
Please provide a commit message, thanks.
--
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.k
On Thu, Mar 27, 2014 at 04:29:37PM +0530, Viresh Kumar wrote:
> On 27 March 2014 16:18, Gautham R Shenoy wrote:
> > So after this patch, driver_data is only going to be used by drivers
> > which want an "unsigned int" value to be saved along with the
> > frequency in the frequency_table and for th
This series identifies some low-hanging fruit for speeding up emulation
of invalid guest state. I am a bit worried about patch 2, while
everything else should be relatively safe.
On the kvm-unit-tests microbenchmarks I get a 1.8-2.5x speedup (from
740-1100 cycles/instruction to 280-600).
This i
We can just blindly move all 16 bytes of ctxt->src's value to ctxt->dst.
write_register_operand will take care of writing only the lower bytes.
Avoiding a call to memcpy (the compiler optimizes it out) gains about 50
cycles on kvm-unit-tests for register-to-register moves, and makes them
about as
Despite the provisions to emulate up to 130 consecutive instructions, in
practice KVM will emulate just one before exiting handle_invalid_guest_state,
because x86_emulate_instructionn always sets KVM_REQ_EVENT.
However, we only need to do this if an interrupt could be injected,
which happens a) if
The only purpose of this patch is to make the next patch simpler
to review. No semantic change.
Signed-off-by: Paolo Bonzini
---
arch/x86/kvm/emulate.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kvm/emulate.c b/arch/x86/kvm/emulate.c
index c9
There are several checks for "peculiar" aspects of instructions in both
x86_decode_insn and x86_emulate_insn. Group them together, and guard
them with a single "if" that lets the processor quickly skip them all.
To do this effectively, add two more flag bits that say whether the
.intercept and .ch
About 25% of the time spent in emulation of invalid guest state
is wasted in checking whether emulation is required for the next
instruction. However, this almost never changes except when a
segment register (or TR or LDTR) changes, or when there is a mode
transition (i.e. CR0 changes).
In fact,
On Wed, 2014-03-26 at 21:18 +, Zoltan Kiss wrote:
> An old inefficiency of the TX path that we are grant mapping the first slot,
> and then copy the header part to the linear area. Instead, doing a grant copy
> for that header straight on is more reasonable. Especially because there are
> ongoi
> Generally real-time applications should not be doing mlock calls during
> their real-time execution for that reason. The required memory regions
> should be locked during startup so that this kind of execution delay can
> be avoided at runtime.
Total agreement on this.
.
Regards,
Bud Da
On Thu, Mar 27, 2014 at 04:17:39PM +0800, Xiubo Li wrote:
> For the DT node, just one property like 'endian-swap' will be okey
> for cases 2 and 4.
I'm not convinced that the cost of having to define explicit big and
little endian properties for the hardware is worth having this - it
seems like a
On Wed, Mar 26, 2014 at 02:23:21AM +, Neil Zhang wrote:
> Signed-off-by: Neil Zhang
> ---
> Documentation/arm64/memory.txt |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/arm64/memory.txt b/Documentation/arm64/memory.txt
> index 5e054bf..c2765e2 1006
Hi,
This gives up adding randomness to the entropy pool when block devices
are busy, to avoid lock contention in I/O intensive situation.
Currently randomness is added to the entropy pool for each 4096 I/O
completion, and holds a global spinlock during its process.
Contention for the spinlock occ
On Wednesday, March 26, 2014 10:58 PM, Kishon Vijay Abraham I wrote:
>
> In DRA7, the cpu sees 32bit address, but the pcie controller can see only
> 28bit
> address. So whenever the cpu issues a read/write request, the 4 most
> significant bits are used by L3 to determine the target controller.
>
Hello.
On 27-03-2014 10:18, Zhao Qiang wrote:
The at8031 can work on polling mode and interrupt mode.
Add ack_interrupt and config intr funcs to enable
interrupt mode for it.
Signed-off-by: Zhao Qiang
---
drivers/net/phy/at803x.c | 30 ++
1 file changed, 30 in
Hello Kishon,
> -Original Message-
> From: Jingoo Han [mailto:jg1@samsung.com]
> Sent: Thursday, March 27, 2014 5:15 PM
> To: 'Kishon Vijay Abraham I'; Mohit KUMAR DCG; Pratyush ANAND
> Cc: devicet...@vger.kernel.org; linux-...@vger.kernel.org; linux-
> ker...@vger.kernel.org; linux-ar
This patch fix minor issue about checking wrong return type.
The of_cm_parse_desc() return ERR_PTR(errnor number) when some error happen
in this function. But, charger_manager_probe() has only checked whether
desc is NULL or not. If of_cm_parse_desc() returns ERR_PTR(-ENOMEM), desc
isn't NULL but
please omit this patch and wait for my new patchset.
Thanks,
Lai
On 03/26/2014 10:41 PM, Lai Jiangshan wrote:
> worker_idr is always accessed in manager lock context currently.
> worker_idr is highly related to managers, it will be unlikely
> accessed in pool->lock only in future.
>
> Signed-off
Il 27/03/2014 09:31, Jet Chen ha scritto:
Hi Paolo,
I helped to test for your patch on our LKP system. It fixes the bug
reported by Fengguang.
I applied your patch based on commit
93c4adc7afedf9b0ec190066d45b6d67db5270da.
Thanks Jet!
Paolo
--
To unsubscribe from this list: send the line "uns
On 03/25/2014 05:56 PM, Lai Jiangshan wrote:
> freezing is nothing related to pools, but POOL_FREEZING adds a connection,
> and causes freeze_workqueues_begin() and thaw_workqueues() complicated.
>
> Since freezing is workqueue instance attribute, so we introduce __WQ_FREEZING
> to wq->flags inste
This patch set adds a DT binding documentation for new 'clock-parents'
and 'clock-rates' DT properties and a helper function to parse them.
The helper is now being called from within the driver core, similarly
as it is done for the pins configuration binding to a device.
Patch 1/2 adds a variant o
The of_clk_get_by_property() function added by this patch is similar to
of_clk_get(), except it allows to pass name of a DT property containing
list of phandles and clock specifiers. For of_clk_get() this has been
hard coded to "clocks".
Signed-off-by: Sylwester Nawrocki
---
Changes since v2:
-
This function adds a helper function to configure clock parents and rates
as specified in clock-parents, clock-rates DT properties for a consumer
device and a call to it before driver is bound to a device.
Signed-off-by: Sylwester Nawrocki
---
Changes since v2:
- edited in clock-bindings.txt, ad
On Thu, Mar 27, 2014 at 02:29:18AM +, Li Zefan wrote:
> On 2014/3/22 7:37, Catalin Marinas wrote:
> > On 17 Mar 2014, at 04:07, Li Zefan wrote:
> >> Currently if kmemleak is disabled, the kmemleak objects can never be freed,
> >> no matter if it's disabled by a user or due to fatal errors.
> >
Hi,
Huang Shijie wrote:
> > > Please see "Figure 12-13" in the 12.12.1.12:
> > >"In order to preserve the BI (bad block information), flash updater
> > > or gang programmer
> > > applications need to swap Bad Block Information (BI) data to byte 0 of
> > > metadata area for
> > > every page b
1 - 100 of 343 matches
Mail list logo
