On Sat, 1 Dec 2012 00:33:46 +0530, Viresh Kumar wrote:
> On 30 November 2012 21:15, Lee Jones wrote:
> > But ... I don't see how the changes in the -i2c and -spi files
> > are of benefit either. When I boot without the ID table I still
> > get "stmpe-i2c 0-0040: stmpe1601 detected, chip id:
On Wed, 5 Dec 2012 10:49:45 +0100, Peter Ujfalusi wrote:
> When the GPIO is configured as output we need to read the GPIODATAOUT*
> register to get correct information. When the GPIO is output the GPIODATAIN*
> registers report 0 all the time (no feedback from output path).
>
> Signed-off-by:
On Wed, 5 Dec 2012 13:42:00 +0800, Qing Xu wrote:
> From: Qing Xu
>
> Signed-off-by: Qing Xu
No commit text?
This patch needs to be squashed together with the patch that changes the
driver. There is no value in separating them.
> ---
> Documentation/devicetree/bindings/mfd/88pm80x.txt |
On Wed, 2012-12-05 at 19:32 -0200, Marcelo Tosatti wrote:
> On Mon, Dec 03, 2012 at 04:39:05PM -0700, Alex Williamson wrote:
> > Memory slots are currently a fixed resource with a relatively small
> > limit. When using PCI device assignment in a qemu guest it's fairly
> > easy to exhaust the
On Wed, 2012-12-05 at 19:22 -0200, Marcelo Tosatti wrote:
> On Mon, Dec 03, 2012 at 04:39:24PM -0700, Alex Williamson wrote:
> > This allows us to resize this structure and therefore the number of
> > memslots as part of the RCU update.
>
> Why is this necessary? "struct memslots" is updated,
On Wed, 2012-12-05 at 19:24 -0200, Marcelo Tosatti wrote:
> On Mon, Dec 03, 2012 at 04:39:30PM -0700, Alex Williamson wrote:
> > In order to make the memslots array grow on demand, move the private
> > slots to the lower indexes of the array. The private slots are
> > assumed likely to be in use,
> This only makes sense if you can show a noticeable performance
> improvement using one of the those -march options with at least one
> benchmark from those which we have now in the kernel.
Thank you for the feedback, Boris. Can you point me to the built in benchmarks
to which you referred?
On Wed, 2012-12-05 at 19:26 -0200, Marcelo Tosatti wrote:
> On Mon, Dec 03, 2012 at 04:39:36PM -0700, Alex Williamson wrote:
> > struct kvm_memory_slot is currently 52 bytes (LP64), not counting the
> > arch data. On x86 this means the memslot array to support a tiny 32+3
> > entries
On Tue, 4 Dec 2012 18:30:37 -0800, Stepan Moskovchenko
wrote:
> In some situations, userspace may want to resolve a
> device by function and logical number (ie, "serial0")
> rather than by the base address or full device path. Being
> able to resolve a device by alias frees userspace from the
>
The following patchset enables 4 additional performance counters in
AMD family 15h processors that count northbridge events -- such as
number of DRAM accesses.
This patchset is based on previous work done by Robert Richter
:
https://lkml.org/lkml/2012/6/19/324
The main differences are:
* The
From: Robert Richter
Generalize northbridge constraints code for family 10h so that later
we can reuse the same code path with other AMD processor families that
have the same northbridge event constraints.
Signed-off-by: Robert Richter
Signed-off-by: Jacob Shin
---
From: Robert Richter
Code simplification. No functional changes.
Signed-off-by: Robert Richter
Signed-off-by: Jacob Shin
---
arch/x86/kernel/cpu/perf_event_amd.c | 68 +-
1 file changed, 26 insertions(+), 42 deletions(-)
diff --git
Move counter index to MSR address offset calculation to architecture
specific files. This prepares the way for perf_event_amd to enable
counter addresses that are not contiguous -- for example AMD Family
15h processors have 6 core performance counters starting at 0xc0010200
and 4 northbridge
Similar to config_base and event_base, allow architecture specific
RDPMC ECX values.
Signed-off-by: Jacob Shin
---
arch/x86/kernel/cpu/perf_event.c |2 +-
arch/x86/kernel/cpu/perf_event.h |6 ++
arch/x86/kernel/cpu/perf_event_amd.c |6 ++
3 files changed, 13
Update these AMD bit field names to be consistent with naming
convention followed by the rest of the file.
Signed-off-by: Jacob Shin
---
arch/x86/include/asm/perf_event.h|4 ++--
arch/x86/kernel/cpu/perf_event_amd.c |8
2 files changed, 6 insertions(+), 6 deletions(-)
diff
On AMD family 15h processors, there are 4 new performance counters
(in addition to 6 core performance counters) that can be used for
counting northbridge events (i.e. DRAM accesses). Their bit fields are
almost identical to the core performance counters. However, unlike the
core performance
On Wed, Dec 05, 2012 at 03:00:12PM -0800, John wrote:
> > This only makes sense if you can show a noticeable performance
>
> > improvement using one of the those -march options with at least one
> > benchmark from those which we have now in the kernel.
>
> Thank you for the feedback, Boris. Can
On Wed, Dec 05, 2012 at 10:14:48PM +0100, Peter Hüwe wrote:
> Hi Kent, Matthias,
>
> Am Mittwoch, 5. Dezember 2012, 19:07:20 schrieb Kent Yoder:
> > Heh, duh, well of course it is. I've now staged everything I'm
> > planning on pushing at:
> >
> > git://github.com/shpedoikal/linux.git
Hi Catalin,
Today's linux-next merge of the arm64 tree got a conflict in
arch/arm64/include/asm/unistd32.h between commit 9d73fc2d641f ("open*(2)
compat fixes (s390, arm64)") from Linus' tree and commit 18a80376ddb0
("arm64: compat for clock_adjtime(2) is miswired") from the arm64 tree.
I fixed
Signed-off-by: Michael Spang
---
arch/arm/plat-samsung/include/plat/gpio-core.h |5 +
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/arch/arm/plat-samsung/include/plat/gpio-core.h
b/arch/arm/plat-samsung/include/plat/gpio-core.h
index 1fe6917..8622c9a 100644
---
On Tue, 4 Dec 2012 15:53:48 +0800, Wenyou Yang wrote:
> From: Jean-Christophe PLAGNIOL-VILLARD
>
> This will allow to use gpio for chip select with no modification in the
> driver binding
>
> When use the cs-gpios, the gpio number will be passed via the cs_gpio field
> and the number of chip
On Wednesday, December 05, 2012 03:27:56 PM Alan Cox wrote:
> On Wed, 5 Dec 2012 15:29:35 +0100
> Borislav Petkov wrote:
>
> > On Wed, Dec 05, 2012 at 08:09:01AM +0100, Andreas Mohr wrote:
> > > Hi,
> > >
> > > drivers/pnp/pnpacpi/core.c: In function 'ispnpidacpi':
> > >
On Thu, Dec 06, 2012 at 12:38:34AM +0100, Rafael J. Wysocki wrote:
> The last patch you sent wasn't ignored. You got this comment from Bjorn:
>
> http://thread.gmane.org/gmane.linux.acpi.devel/56753
>
> that you didn't respond to, so I'm still unsure what to do with that patch.
Andrew picked
On Tue, 4 Dec 2012 00:16:18 -0500, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Use for_each_compatible_node() macro instead of open coding it.
>
> Signed-off-by: Wei Yongjun
Acked-by: Grant Likely
> ---
> drivers/tty/hvc/hvsi.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
On Wed, Dec 5, 2012 at 6:54 AM, Serban Constantinescu
wrote:
> On 05/12/12 00:26, Arve Hjønnevåg wrote:
>>
>> On Tue, Dec 4, 2012 at 2:44 AM, Serban Constantinescu
>> wrote:
>>>
>>> Android's IPC, Binder, does not support calls from a 32-bit userspace
>>> in a 64 bit kernel. This patch adds
On Mon, 3 Dec 2012 13:38:38 -0500, Murali Karicheri wrote:
> This adds OF support to DaVinci SPI controller to configure platform
> data through device bindings. Also replaces clk_enable() with
> of clk_prepare_enable() as well as clk_disable() with
> clk_disable_unprepare().
>
Hi Murali.
On Mon, 3 Dec 2012 08:36:03 -0500, Wei Yongjun wrote:
> From: Wei Yongjun
>
> Use for_each_compatible_node() macro instead of open coding it.
>
> Signed-off-by: Wei Yongjun
Acked-by: Grant Likely
> ---
> arch/powerpc/platforms/85xx/mpc85xx_mds.c | 4 +---
> 1 file changed, 1 insertion(+),
On Sun, 2 Dec 2012 12:54:25 +0900, Mark Brown
wrote:
> In order to avoid constantly allocating and deallocating there is a fixed
> buffer which spi_write_then_read() uses for transfers, with an early error
> check to ensure that the transfer fits within the buffer. This limits the
> size of
Hi,
Consider the following Kconfig file:
config MODULES
def_bool y
choice
tristate "C1"
config A
tristate "A"
config B
tristate "B"
endchoice
choice
bool "C2" if A
config C
bool "C"
config D
bool "D"
endchoice
When this Kconfig file is used with a
Am Donnerstag, 6. Dezember 2012, 00:09:41 schrieb Kent Yoder:
> >
> > > static int tpm_st33_i2c_pm_suspend(struct i2c_client *client,
> > > pm_message_t mesg)
> > >
> > >...
> > >
> > > static int tpm_st33_i2c_pm_resume(struct i2c_client *client)
> > >
> > >,,,
> > >static struct i2c_driver
Hi Henrik-
Thanks yet again, for your review. I very much appreciate your time and
efforts to get the driver closer to acceptance. Dmitry and Dudley, my
thanks to you as well.
Henrik, the forthcoming PATCH v5 includes all of your change requests
from this round. See below for additional notes
On Mon, Dec 3, 2012 at 12:02 PM, Seth Forshee
wrote:
> On Thu, Oct 25, 2012 at 11:35:57AM -0600, Bjorn Helgaas wrote:
>> On Thu, Aug 23, 2012 at 10:36 AM, Matthew Garrett wrote:
>> > V3 just fixes all the casting issues and incorporates David's change in
>> > search ordering.
>>
>> I think
Cypress PS/2 Trackpad (drivers/input/mouse/cypress_ps2.c) needs
this larger cmdbuf[] to handle 8-byte packet responses.
Signed-off-by: Kamal Mostafa
---
include/linux/libps2.h |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/linux/libps2.h b/include/linux/libps2.h
This driver, submitted on behalf of Cypress Semiconductor Corporation and
additional contributors, provides support for the Cypress PS/2 Trackpad.
This [PATCH v5] version differs from my previous submitted version[3]:
Patch #1 (cmdbuf to 8 bytes) and #3 (link in driver) are unchanged.
Patch
From: Dudley Du
Original code contributed by Dudley Du (Cypress Semiconductor Corporation),
modified by Kamal Mostafa.
BugLink: http://launchpad.net/bugs/978807
Signed-off-by: Dudley Du
Signed-off-by: Kamal Mostafa
Signed-off-by: Mario Limonciello
Signed-off-by: Tim Gardner
---
From: Dudley Du
Input/mouse driver for Cypress PS/2 Trackpad.
Original code contributed by Dudley Du (Cypress Semiconductor Corporation),
modified by Kamal Mostafa and Kyle Fazzari.
BugLink: http://launchpad.net/bugs/978807
Signed-off-by: Dudley Du
Signed-off-by: Kamal Mostafa
On 2012.12.04 23.24, Sebastian Andrzej Siewior wrote:
> > VLAIS is not something they are willing to accept (for various
> > reasons). There are other patches to LLVM that are still working
> Is this not described in C99 6.7.2.1p16?
No, this is not the case - flexible array members are a very
On Wed, Dec 05, 2012 at 04:15:56PM -0800, Yinghai Lu wrote:
> at the same time we should export setup_data into /sys, so kexec could
> append this pointer to command of
> second kernel, just like kexec append acpi_rsdp.
> That should address DavidW's concern.
Why should the kernel export data to
This patch converts the suspend and resume functions for
tpm_i2c_stm_st33 to the new dev_pm_ops.
Signed-off-by: Peter Huewe
---
Note:
I'm sending this patch on behalf of myself only and nobody else,
especially not my employer - and I'm doing this in my spare time.
I have to inform you that I'm
On 12/05/2012 04:18 PM, Matthew Garrett wrote:
> On Wed, Dec 05, 2012 at 04:15:56PM -0800, Yinghai Lu wrote:
>
>> at the same time we should export setup_data into /sys, so kexec could
>> append this pointer to command of
>> second kernel, just like kexec append acpi_rsdp.
>> That should address
On Wed, Dec 5, 2012 at 4:18 PM, Matthew Garrett wrote:
> On Wed, Dec 05, 2012 at 04:15:56PM -0800, Yinghai Lu wrote:
>
>> at the same time we should export setup_data into /sys, so kexec could
>> append this pointer to command of
>> second kernel, just like kexec append acpi_rsdp.
>> That should
Matthew Garrett writes:
> On Wed, Dec 05, 2012 at 04:15:56PM -0800, Yinghai Lu wrote:
>
>> at the same time we should export setup_data into /sys, so kexec could
>> append this pointer to command of
>> second kernel, just like kexec append acpi_rsdp.
>> That should address DavidW's concern.
>
>
Signed-off-by: Axel Lin
---
drivers/regulator/tps80031-regulator.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/regulator/tps80031-regulator.c
b/drivers/regulator/tps80031-regulator.c
index 50f89b0..b15d711 100644
---
On Wed, Dec 05, 2012 at 04:23:28PM -0800, Greg KH wrote:
> Hi all,
>
> I'd like to announce the LTSI 3.4.21-rc1 kernel. It's a first cut at
> the patches that have been submitted to be included in the LTSI 3.4
> kernel branch. I've tested it out on my machine, but it really needs
> testing from
On Wed, 21 Nov 2012 20:07:23 -0500, wf...@viridian.itc.virginia.edu (Bill
Pemberton) wrote:
> Grant Likely writes:
> >
> > You mean this series wasn't created with a script? You did this by
> > hand? If so then I must say kudos on your dedication!
> >
> > But it makes me more nervous about the
>OK, so the ENOMEM seems to be leaking from mem_cgroup_newpage_charge.
>This can only happen if this was an atomic allocation request
>(!__GFP_WAIT) or if oom is not allowed which is the case only for
>transparent huge page allocation.
>The first case can be excluded (in the clean 3.2 stable
On Wed, Dec 5, 2012 at 4:21 PM, H. Peter Anvin wrote:
> On 12/05/2012 04:18 PM, Matthew Garrett wrote:
> Because it also needs to modify it. Right now kexec userspace
> synthesizes struct boot_params from scratch, and does so incorrectly to
> boot. I think we have setup_data exported via
On 12/05/2012 04:15 PM, Yinghai Lu wrote:
>
> -#ifndef CONFIG_DEBUG_BOOT_PARAMS
> -struct boot_params __initdata boot_params;
> -#else
> struct boot_params boot_params;
> -#endif
>
> No, that is not a right fix
>
> We should only cache pointer to setup_data.
>
> at the same time we should
On 12/05/2012 04:30 PM, Yinghai Lu wrote:
> On Wed, Dec 5, 2012 at 4:21 PM, H. Peter Anvin wrote:
>> On 12/05/2012 04:18 PM, Matthew Garrett wrote:
>
>> Because it also needs to modify it. Right now kexec userspace
>> synthesizes struct boot_params from scratch, and does so incorrectly to
>>
On Thu, Dec 06, 2012 at 12:27:42AM +, Grant Likely wrote:
> On Wed, 21 Nov 2012 20:07:23 -0500, wf...@viridian.itc.virginia.edu (Bill
> Pemberton) wrote:
> > Grant Likely writes:
> > >
> > > You mean this series wasn't created with a script? You did this by
> > > hand? If so then I must say
On Wed, Dec 05, 2012 at 12:34:15PM -0500, Theodore Ts'o wrote:
> Because it's the on-disk encoding, when btrfs uses extra bits for its
> btrfs-specific inode flags, it means that I need to avoid using those
> bits in ext4, if it's a flag that needs to also be exposed via
> chattr/lsattr.
What,
I've legally changed my name with New York State, the US Social Security
Administration, et al. This patch propagates the name change and change
in initials and login to comments in the kernel source as well.
vs. next-20121205
Signed-off-by: Nadia Yvette Chambers
diff --git a/MAINTAINERS b
Thanks for the patience on this driver. I have stripped out firmware update,
the sysfs properties around firmware version, hardware version, update_fw,
and power state.
I have incorporated rydberg's suggestions for cleanup.
--
To unsubscribe from this list: send the line "unsubscribe
This patch introduces a driver for Cypress All Points Addressable
I2C Trackpad, including the ones in 2012 Samsung Chromebooks.
This device is compatible with MT protocol type B, providing identifiable
contacts.
Signed-off-by: Dudley Du
Signed-off-by: Daniel Kurtz
Signed-off-by: Benson Leung
On Wed, Dec 5, 2012 at 4:36 PM, H. Peter Anvin wrote:
> On 12/05/2012 04:15 PM, Yinghai Lu wrote:
>>
>
> I don't see why that isn't the right fix. We copy the data into
> boot_params early in the boot; that *is* the official copy as far as the
> kernel is concerned.
>
> So this patch very much
On Wed, Dec 5, 2012 at 4:51 PM, Yinghai Lu wrote:
> On Wed, Dec 5, 2012 at 4:36 PM, H. Peter Anvin wrote:
>> On 12/05/2012 04:15 PM, Yinghai Lu wrote:
>>>
>>
>> I don't see why that isn't the right fix. We copy the data into
>> boot_params early in the boot; that *is* the official copy as far
Hi Florian,
> -Original Message-
> From: Florian Fainelli [mailto:f.faine...@gmail.com] On Behalf Of Florian
> Fainelli
> Sent: 2012年12月5日 18:48
> To: Yang, Wenyou
> Cc: linux-arm-ker...@lists.infradead.org; Ferre, Nicolas;
> plagn...@jcrosoft.com; Lin,
> JM; w...@iguana.be;
On 12/05/2012 04:51 PM, Yinghai Lu wrote:
>
> it moves boot_params from __initdata to data.
> and just for using pointer to setup_data.
>
> should add setup_data pointer instead. so will not waste (4096 - 8) bytes.
>
That is not the only bit. We already have covered how kexec could use
the
"H. Peter Anvin" wrote:
>I don't think there is anything security-sensitive about that
>information, at least not to root. I could be wrong, of course; I
>wouldn't mind security people telling me about that.
I don't think there's anything at present, but we'll want to pass the
hibernation
The mm-of-the-moment snapshot 2012-12-05-16-59 has been uploaded to
http://www.ozlabs.org/~akpm/mmotm/
mmotm-readme.txt says
README for mm-of-the-moment:
http://www.ozlabs.org/~akpm/mmotm/
This is a snapshot of my -mm patch queue. Uploaded at random hopefully
more than once a week.
You
"H. Peter Anvin" wrote:
>Because it also needs to modify it. Right now kexec userspace
>synthesizes struct boot_params from scratch, and does so incorrectly to
>boot. I think we have setup_data exported via debugfs but IIRC we
>never
>got a strong enough use case for sysfs.
Kexec userspace
urce as well.
>
> vs. next-20121205
OK, that may be a problem. Does this patch apply to Linus' tree
currently? I guess not. So, either you need to split it up and send it
to the various maintainers (most if it can probably go through the trivial
tree (cc'd)). Or wait until after v3.8
On 12/05/2012 04:57 PM, Matthew Garrett wrote:
>
>
> "H. Peter Anvin" wrote:
>
>> I don't think there is anything security-sensitive about that
>> information, at least not to root. I could be wrong, of course; I
>> wouldn't mind security people telling me about that.
>
> I don't think
On Wed, 5 Dec 2012 20:15:47 +0100, Jiri Olsa wrote:
> On Wed, Dec 05, 2012 at 08:06:46PM +0100, Jiri Olsa wrote:
>> On Wed, Dec 05, 2012 at 03:56:42PM +0900, Namhyung Kim wrote:
>> > From: Namhyung Kim
>> > @@ -481,6 +459,11 @@ static void hists__process(struct hists *old, struct
>> > hists
"H. Peter Anvin" wrote:
>And that presumably would be something that cannot be exposed to root?
>If so we may want to use one of the bits in the setup_data type field
>as
>a security flag, perhaps...
Yeah, it needs to be hidden from root - but ideally we'd be passing it to the
second kernel
On Wed, Dec 05, 2012 at 10:25:17AM -0800, Linus Torvalds wrote:
> Yes, people can argue that "process" is about technical issues too,
> but let's be honest: our process is fluid. Not everything gets
> reviewed on the mailing list, and people *do* talk about things
> face-to-face at conferences.
On Thu, 2012-12-06 at 12:01 +1100, Stephen Rothwell wrote:
> OK, that may be a problem. Does this patch apply to Linus' tree
> currently? I guess not. So, either you need to split it up and send it
> to the various maintainers (most if it can probably go through the trivial
> tree (cc'd)). Or
On 12/05/2012 05:13 PM, Matthew Garrett wrote:
"H. Peter Anvin" wrote:
And that presumably would be something that cannot be exposed to root?
If so we may want to use one of the bits in the setup_data type field
as
a security flag, perhaps...
Yeah, it needs to be hidden from root - but
On 12/05/2012 11:46 PM, Jiang Liu wrote:
On 11/23/2012 06:44 PM, Tang Chen wrote:
This patch introduces a new array zone_movable_limit[] to store the
ZONE_MOVABLE limit from movablecore_map boot option for all nodes.
The function sanitize_zone_movable_limit() will find out to which
node the
On Wed, Dec 5, 2012 at 3:04 PM, Haojian Zhuang wrote:
> On Wed, Dec 5, 2012 at 2:49 PM, Chao Xie wrote:
>> the pxa95x rtc need access PBSR register before write to
>> RTTR, RCNR, RDCR, and RYCR registers.
>>
>> Signed-off-by: Chao Xie
>> ---
>> drivers/rtc/rtc-pxa.c | 100
>>
On Tue, 2012-12-04 at 10:30 +0100, Borislav Petkov wrote:
> Steve,
>
> AFAIU, this will create all tracepoint code from the ras.h header
> in this compilation unit, i.e. aerdrv_errprint.c. It has only one
> tracepoint now but with time, as more RAS TPs are being added, it would
> make sense to
On Wed, Dec 05, 2012 at 04:02:53PM -0700, Alex Williamson wrote:
> On Wed, 2012-12-05 at 19:26 -0200, Marcelo Tosatti wrote:
> > On Mon, Dec 03, 2012 at 04:39:36PM -0700, Alex Williamson wrote:
> > > struct kvm_memory_slot is currently 52 bytes (LP64), not counting the
> > > arch data. On x86
On 12/05/2012 11:43 PM, Jiang Liu wrote:
If we make "movablecore_map" take precedence over "movablecore/kernelcore",
the logic could be simplified. I think it's not so attractive to support
both "movablecore_map" and "movablecore/kernelcore" at the same time.
Hi Liu,
Thanks for you advice. :)
From: Qing Xu
add dt support for 88pm800 and 88pm805
Signed-off-by: Qing Xu
---
Documentation/devicetree/bindings/mfd/88pm80x.txt | 52 +
drivers/mfd/88pm800.c | 26 +-
drivers/mfd/88pm805.c | 26
Hi Eric,
Could you give a list of struct boot_params field which are initialized
properly by kexec? I think we need to do the sentinel hack, and want to
know what to whitelist.
Also, does kexec set a bootloader ID?
-hpa
--
To unsubscribe from this list: send the line "unsubscribe
On 12/06/2012 06:55 AM, Grant Likely wrote:
On Wed, 5 Dec 2012 13:42:00 +0800, Qing Xu wrote:
From: Qing Xu
Signed-off-by: Qing Xu
No commit text?
This patch needs to be squashed together with the patch that changes the
driver. There is no value in separating them.
---
First of all, thanks for explaining :)
On 6 December 2012 04:12, Grant Likely wrote:
> On Sat, 1 Dec 2012 00:33:46 +0530, Viresh Kumar
> wrote:
>> This first tries to match the table my patch added, _BUT_ the string will
>> never match as we had "st,stmpe810" in table and "stmpe810" in dev.
>
On Wed, Dec 05, 2012 at 02:05:06PM -0800, Joe Perches wrote:
> On Wed, 2012-12-05 at 16:48 -0500, Jason Baron wrote:
> > Here's a collection of the latest dynamic debug patches that I have
> > pending.
>
> Any update on the jump table support?
>
I have patches that implement the support,
Grant Likely , on Thu 2012.11.29 said:
> On Mon, 29 Oct 2012 15:03:08 +0100, Michal Marek wrote:
> > (Adding lkml and Thomas as IRQ subsystem maintainer to CC)
> >
> > On Sun, Oct 21, 2012 at 03:40:16AM -0400, Paul Thompson wrote:
> > > Hi;
> > >
> > > In menuconfig, General setup -> IRQ
On 2012-12-6 9:26, Tang Chen wrote:
> On 12/05/2012 11:43 PM, Jiang Liu wrote:
>> If we make "movablecore_map" take precedence over "movablecore/kernelcore",
>> the logic could be simplified. I think it's not so attractive to support
>> both "movablecore_map" and "movablecore/kernelcore" at the
On 12/06/2012 05:09 AM, Marcelo Tosatti wrote:
> On Tue, Dec 04, 2012 at 07:17:11AM +0800, Xiao Guangrong wrote:
>> There are two cases we need to adjust page size in set_spte:
>> 1): the one is other vcpu creates new sp in the window between
>> mapping_level()
>> and acquiring mmu-lock.
>>
On 6 December 2012 04:12, Grant Likely wrote:
> On Sat, 1 Dec 2012 00:33:46 +0530, Viresh Kumar
> wrote:
>> This first tries to match the table my patch added, _BUT_ the string will
>> never match as we had "st,stmpe810" in table and "stmpe810" in dev.
>
> of_driver_match_device() matches
On Wed, Dec 05, 2012 at 11:22:57AM +0200, Vitalii Demianets wrote:
> 1. uioinfo was kfreed based on the presence of pdev->dev.of_node, which was
> obviously wrong and unrelated to the fact if uioinfo was allocated statically
> or dynamically. This patch introduces new flag which clearly shows if
I'm announcing the release of the 3.0.55 kernel.
This only fixes a build error that some people have reported from the
3.0.54 kernel, if you don't have a problem with 3.0.54 then don't worry
about upgrading at this point in time.
The updated 3.0.y git tree can be found at:
diff --git a/Makefile b/Makefile
index ae984ab..06df950 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 0
-SUBLEVEL = 54
+SUBLEVEL = 55
EXTRAVERSION =
NAME = Sneaky Weasel
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index 8ede567..911e16d
I'm announcing the release of the 3.4.22 kernel.
This release contains a single fix for a build error that some people
have reported with the 3.4.21 kernel, if you don't have a problem with
3.4.21 then don't worry about upgrading at this point in time.
The updated 3.4.y git tree can be found at:
diff --git a/Makefile b/Makefile
index 7f9f649..320663d 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,6 @@
VERSION = 3
PATCHLEVEL = 4
-SUBLEVEL = 21
+SUBLEVEL = 22
EXTRAVERSION =
NAME = Saber-toothed Squirrel
diff --git a/arch/x86/kernel/ptrace.c b/arch/x86/kernel/ptrace.c
index
Hi Tang,
There is a bug in Gerry's patch, please apply this patch to fix it.
---
mm/page_alloc.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 41c3b51..d981810 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4383,7
hi
When develop the clk drivers for SOCs based on common clock framework.
I met a issue.
For example there is a uart device, it's function clock comes from a
divider, and the divider's parent is a mux. It means
MUX --> DIV --> UART
As we know that UART can work at low baudrate for a terminal,
Hi Liu, Wu,
I got it, thank you very much. The idea is very helpful. :)
I'll apply your patches and do some tests later.
Thanks. :)
On 12/06/2012 10:51 AM, Jianguo Wu wrote:
Hi Tang,
There is a bug in Gerry's patch, please apply this patch to fix it.
---
mm/page_alloc.c |2 +-
1
On Wed, Dec 5, 2012 at 5:14 PM, Dave Chinner wrote:
>
> And for changes to syscalls? That's something that must be peer
> reviewed because we are going to be stuck with those changes forever
> as we can't undo them at a later date. It doesn't matter who made the
> change in question, I would have
On Wed, Dec 5, 2012 at 5:57 PM, H. Peter Anvin wrote:
> Hi Eric,
>
> Could you give a list of struct boot_params field which are initialized
> properly by kexec? I think we need to do the sentinel hack, and want to
> know what to whitelist.
the one with *
? means set only when lfb_depth > 8
On 12/05/2012 11:19 PM, Alex Shi wrote:
> Hi Paul:
>
> Runnable load tracking patch set introduce a good way to tracking each
> entity/rq's running time.
> But when I try to enable it in load balance, I found burst forking
> many new tasks will make just few cpu heavy while other cpu has no
>
On Wed, Dec 05, 2012 at 01:02:41PM +0100, Jan Kara wrote:
> On Mon 26-11-12 14:55:09, Herton Ronaldo Krzesinski wrote:
> > 3.5.7u1 -stable review patch. If anyone has any objections, please let me
> > know.
> Note that this fix causes another problem which is fixed by
>
HI, guys
THe perf testing is done separately with fs_mark, fio, ffsb and
compilebench in one kvm guest.
Below is the performance testing report for hot tracking, and no obvious
perf downgrade is found.
Note: original kernel means its source code is not changed;
kernel with enabled hot
From: Marko Katic
Changing backlight intensity on an Akita (Sharp Zaurus C-1000)
triggers WARN_ON message:
WARNING: at drivers/gpio/gpiolib.c:1672 __gpio_set_value+0x38/0xa4()
Modules linked in:
Backtrace:
[] (dump_backtrace+0x0/0x110) from [] (dump_stack+0x18/0x1c)
r6:c0158fc8 r5:0009
Hi Linus,
I rewrote some parts according to your comments, but I still have some
concerns.
On Fri, 2012-10-12 at 22:53 +0200, Linus Walleij wrote:
> >> (...)
> >> > +static int ts5500_gpio_to_irq(struct gpio_chip *chip, unsigned
> offset)
> >> > +{
> >> > + const struct ts5500_dio line =
On Wed, 2012-12-05 at 23:45 -0200, Marcelo Tosatti wrote:
> On Wed, Dec 05, 2012 at 04:02:53PM -0700, Alex Williamson wrote:
> > On Wed, 2012-12-05 at 19:26 -0200, Marcelo Tosatti wrote:
> > > On Mon, Dec 03, 2012 at 04:39:36PM -0700, Alex Williamson wrote:
> > > > struct kvm_memory_slot is
Quoting Aristeu Rozanski (a...@redhat.com):
> On Mon, Dec 03, 2012 at 06:01:25PM +, Serge E. Hallyn wrote:
> > First, generally, I don't think 'allows' added to parent should be
> > automatically propagated to descendents.
>
> that's what I think too and what I tried to do
>
> > In
diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig
index 126d8ce..abd0396 100644
--- a/drivers/xen/Kconfig
+++ b/drivers/xen/Kconfig
@@ -206,4 +206,15 @@ config XEN_MCE_LOG
Allow kernel fetching MCE error from Xen platform and
converting it into
901 - 1000 of 1044 matches
Mail list logo
