[Was: Re: [GIT pull] timer fixes for 3.4]
[CC+=Trevor Woerner, after an independent mail led me to find this thread.]
[CC+=linux-api@, which really should have been CCed on the original patch]
Linus,
On Fri, Apr 13, 2012 at 12:19 AM, Linus Torvalds
wrote:
> On Thu, Apr 12, 2012 at 3:06 PM, Thom
From: Nicholas Bellinger
This patch converts iscsi_target_seq_pdu_list.c code for DataSequenceInOrder=No
+
DataPDUInOrder=No operation to honor the MaxXmitDataSegmentLength value
for iscsi_cmd->se_cmd.data_direction == DMA_TO_DEVICE cases.
Cc: Mike Christie
Cc: Andy Grover
Cc: Hannes Reinecke
From: Nicholas Bellinger
This patch re-adds the ability to optionally run in buffered FILEIO mode
(eg: w/o O_DSYNC) for device backends in order to once again use the
Linux buffered cache as a write-back storage mechanism.
This logic was originally dropped with mainline v3.5-rc commit:
commit a
From: Nicholas Bellinger
This patch activates MaxXmitDataSegmentLength usage that performs the
following sequence of events:
- Once the incoming initiator's MAXRECVDATASEGMENTLENGTH key is detected
within iscsi_check_acceptor_state(), save the requested MRDSL into
conn->conn_ops->MaxRecvData
From: Nicholas Bellinger
The iSCSI TMR TASK_REASSIGN completion logic in iscsi_tmr_task_reassign()
does an explict check for MRDSL across task reassignment, so go ahead and
add an explict MaxXmitDataSegmentLength check here as well to be safe.
Cc: Mike Christie
Cc: Andy Grover
Cc: Hannes Reine
From: Nicholas Bellinger
Now that iscsi-target supports a local configurable MaxXmitDataSegmentLength,
go ahead and make ISCSI_OP_SCSI_CMD, ISCSI_OP_SCSI_DATA_OUT, ISCSI_OP_NOOP_OUT
and ISCSI_OP_TEXT PDU payload checks honor conn_ops->MaxXmitDataSegmentLength.
Cc: Mike Christie
Cc: Andy Grover
From: Nicholas Bellinger
This patch introduces a new per connection MaxXmitDataSegmentLength
parameter value used to represent the outgoing MaxRecvDataSegmentLength
that is actually sent over the wire during iSCSI login response back
to the initiator side.
It also adds a new MaxXmitDataSegmentLe
From: Nicholas Bellinger
Hi folks,
This following series is destined for v3.7-rc1 code, and re-adds support for
buffered FILEIO + emulate_write_cache=1 emulation removed in v3.5, as well as
fixing up a long standing issue wrt to MaxRecvDataSegmentLength handling within
iscsi-target code.
The la
On Sat, 2012-09-29 at 10:13 +0300, Dan Carpenter wrote:
> psy->properties is an enum (32 bit type) so adding sizeof() puts us
> four times further along than we intended. It should be cast to a char
> pointer before doing the math.
You really read this driver to find out this one.
Good one.
>
> S
On Fri, 2012-09-28 at 08:33 +0800, Axel Lin wrote:
> This driver can be built as a module, add MODULE_LICENSE for it.
> For completeness, also adds MODULE_AUTHOR and MODULE_DESCRIPTION.
Aha I forgot that.Good one.
>
> Signed-off-by: Axel Lin
> ---
> drivers/extcon/extcon-adc-jack.c |5 +
On Fri, 2012-09-28 at 07:36 +0800, Axel Lin wrote:
> On failure, request_any_context_irq() returns a negative value.
> On success, it returns either IRQC_IS_HARDIRQ or IRQC_IS_NESTED.
>
> Also ensure adc_jack_probe() return 0 on success.
this patch makes sense.
>
> Signed-off-by: Axel Lin
> ---
Commit-ID: 2223af389032425e3d1a70f9cb3a63feaa654ced
Gitweb: http://git.kernel.org/tip/2223af389032425e3d1a70f9cb3a63feaa654ced
Author: Josh Triplett
AuthorDate: Fri, 28 Sep 2012 17:57:05 -0700
Committer: H. Peter Anvin
CommitDate: Sat, 29 Sep 2012 12:21:03 -0700
efi: Fix the ACPI BGRT
Commit-ID: 785107923a83d8456bbd8564e288a24d84109a46
Gitweb: http://git.kernel.org/tip/785107923a83d8456bbd8564e288a24d84109a46
Author: Josh Triplett
AuthorDate: Fri, 28 Sep 2012 17:55:44 -0700
Committer: H. Peter Anvin
CommitDate: Sat, 29 Sep 2012 12:21:01 -0700
efi: Defer freeing boot
On Sat, Sep 29, 2012 at 09:36:36AM -0400, Franklin Wei wrote:
> Well, I managed to compile the kernel (3.6rc7) using the code in the
> tar.gz. However, when I try to boot it, it gives a kernel panic. I
> suspect that it has to do with the initrd I created, judging from the
> messages on the screen.
On Sun, 2012-09-30 at 00:10 +0200, Maxim Levitsky wrote:
> On Sat, 2012-09-29 at 10:11 +0300, Dan Carpenter wrote:
> > We need to free "overwrite_flags" before returning.
> >
> > Signed-off-by: Dan Carpenter
> >
> > diff --git a/drivers/memstick/core/ms_block.c
> > b/drivers/memstick/core/ms_
On Sat, 2012-09-29 at 10:11 +0300, Dan Carpenter wrote:
> We need to free "overwrite_flags" before returning.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/memstick/core/ms_block.c
> b/drivers/memstick/core/ms_block.c
> index a8e8915..1f9d5cf 100644
> --- a/drivers/memstick/core/ms
Hello Bjorn,
thank you very much for the patch.
I tested it; it works.
(typing mistake: it must read PCI_COMMAND_MEMORY instead of
PCI_COMMAND_MEM at one location;
some hunks of the patch couldn't be applied automatically on Kernel
3.2.23 because some comments in the contexts are different)
On Sat, 2012-09-29 at 10:11 +0300, Dan Carpenter wrote:
> The original code dereferenced "msb" after freeing it.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/drivers/memstick/core/ms_block.c
> b/drivers/memstick/core/ms_block.c
> index c815fe5..a8e8915 100644
> --- a/drivers/memstick/core
On Sat, Sep 29, 2012 at 11:38:31PM +0200, Krzysztof Halasa wrote:
> Note I'm not only doing ARM, but also X86 and MIPS, with additional code
> shared between them, and the "stable" part of it is what I'm paid for.
> I can't simply work with arm-soc, none of my platforms will even boot
> with pure a
On Sat, Sep 29, 2012 at 06:49:51PM +0200, Sasha Levin wrote:
> On 09/29/2012 03:37 PM, Paul E. McKenney wrote:
> > Sasha, is the easily reproducible? If so, could you please try the
> > previous patch? It will likely give us more information on where
> > this bug really lives. (Yes, it might tot
I realize my work flow is probably suboptimal, though I can't see
an easy solution.
Russell King - ARM Linux writes:
> That makes no sense what so ever. The tree which is used for the next
> stable tree will be Linus' tree, which will be the result of merging all
> those other trees into Linus'
On Tue, Sep 25, 2012 at 10:27:01AM +0200, Roland Stigge wrote:
> Hi Arnd and Olof,
>
> this is a second round of mach-lpc32xx specific updates for 3.7. Below,
> the core branch.
>
> Thanks,
>
> Roland
>
>
> The following changes since commit 7a5deff68f9e0a1db170ac9dd3b2b4aaddc1b80c:
>
> ARM
On Tue, Sep 25, 2012 at 10:25:08AM +0200, Roland Stigge wrote:
> Hi Arnd and Olof,
>
> this is a second round of mach-lpc32xx specific updates for 3.7, below
> the dts branch. Only one patch for adjusting phy3250.dts.
>
> Thanks,
>
> Roland
>
>
> The following changes since commit 25b3ab6c7e39
On Sat, 29 Sep 2012, H. Peter Anvin wrote:
> >Intel doesn't make it easy to get all processor specification updates at
> >once so that I could hunt down every processor which acknowledges the
> >existence of that errata before replying, so I will assume for the moment
> >that the comment is mostly
> From: Stephen Warren
>
> This updates scripts/dtc to commit 317a5d9 "dtc: zero out new label
> objects" from git://git.jdl.com/software/dtc.git.
>
> This adds features such as:
> * /bits/ syntax for cell data.
> * Math expressions within cell data.
> * The ability to delete properties or nodes
On Sat, Sep 29, 2012 at 10:43 PM, Al Viro wrote:
> On Sat, Sep 29, 2012 at 10:27:44PM +0200, Geert Uytterhoeven wrote:
>> On Sat, Sep 29, 2012 at 10:10 PM, Joe Perches wrote:
>> >> @@ -88,7 +88,7 @@ static int do_aio(aio_context_t ctx, enum aio_type
>> >> type, int fd, char *buf,
>> >>
On Sat, Sep 29, 2012 at 10:27:44PM +0200, Geert Uytterhoeven wrote:
> On Sat, Sep 29, 2012 at 10:10 PM, Joe Perches wrote:
> >> @@ -88,7 +88,7 @@ static int do_aio(aio_context_t ctx, enum aio_type type,
> >> int fd, char *buf,
> >> iocbp->aio_nbytes = sizeof(c);
> >> b
On Sat, Sep 29, 2012 at 10:24 PM, John David Anglin
wrote:
> Had to remove the kvm_para.h hunk because I hit this issue:
> https://lkml.org/lkml/2012/6/13/226
> Assume this is now fixed.
Unfortunately not :-(
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lot
On Sat, Sep 29, 2012 at 10:10 PM, Joe Perches wrote:
>> @@ -88,7 +88,7 @@ static int do_aio(aio_context_t ctx, enum aio_type type,
>> int fd, char *buf,
>> iocbp->aio_nbytes = sizeof(c);
>> break;
>> default:
>> - printk(UM_KERN_ERR "Bogus op in do_ai
On 28-Sep-12, at 9:43 AM, James Bottomley wrote:
On Tue, 2012-09-25 at 19:23 -0400, John David Anglin wrote:
On 24-Sep-12, at 8:39 AM, Denys Vlasenko wrote:
Maybe it needs to be removed?
Worked for me with 3.5.4.
It's probably time to tidy up all of our asm-generic code and use the
proper
On 13:32 Fri 28 Sep , Stephen Warren wrote:
> From: Stephen Warren
>
> cmd_dtc_cpp runs the C pre-processor on the input .dts file before
> passing it to dtc for final compilation. This allows used of #define
> within the .dts file.
>
> Introduce a new rule for %.dtsp -> %.dtb, which uses cm
The warning check for duplicate sysfs entries can cause a buffer overflow
when printing the warning, as strcat() doesn't check buffer sizes.
Use strlcat() instead.
Since strlcat() doesn't return a pointer to the passed buffer, unlike
strcat(), I had to convert the nested concatenation in sysfs_add
Intel doesn't make it easy to get all processor specification updates at
once so that I could hunt down every processor which acknowledges the
existence of that errata before replying, so I will assume for the moment
that the comment is mostly correct.
I should say: as far as I know the blackl
On 09/29/2012 01:11 PM, Henrique de Moraes Holschuh wrote:
On Sat, 29 Sep 2012, H. Peter Anvin wrote:
PAT support are lacking only in the Pentium Pro and Pentium II. Sorry, if
you're using crap that old, you don't get to screw up the kernel for
everyone else.
PAT is blacklisted for x86_model
On 13:32 Fri 28 Sep , Stephen Warren wrote:
> From: Stephen Warren
>
> All architectures that use cmd_dtc do so in the same way. Move the build
> rule to a central location to avoid duplication.
>
> Signed-off-by: Stephen Warren
> ---
> Jean-Christophe,
> Moving the build rule to Makefile.l
On Sat, 29 Sep 2012, H. Peter Anvin wrote:
> PAT support are lacking only in the Pentium Pro and Pentium II. Sorry, if
> you're using crap that old, you don't get to screw up the kernel for
> everyone else.
PAT is blacklisted for x86_model < 15 on Intel, which covers a lot
more boxes than p-pro a
On Sat, 2012-09-29 at 19:07 +0200, Geert Uytterhoeven wrote:
> Since commit 9429ec96c2718c0d1e3317cf60a87a0405223814 ("um: Preinclude
> include/linux/kern_levels.h") the non-prefixed printk() level specifiers
> are usable for the user parts of UML.
Thanks here too.
> diff --git a/arch/um/os-Linux
On 20:32 Fri 28 Sep , Roland Stigge wrote:
> Hi,
>
> On 28/09/12 18:01, Jean-Christophe PLAGNIOL-VILLARD wrote:
> >>Maybe like this, for some struct block *?
> >>
> >>block = set_block_prepare(gc, pins, values, size);
> >>if (block) {
> >>set_block(gc, block);
> >>...
> >>set_block
On Sat, 2012-09-29 at 19:07 +0200, Geert Uytterhoeven wrote:
> Since commit 9429ec96c2718c0d1e3317cf60a87a0405223814 ("um: Preinclude
> include/linux/kern_levels.h") the non-prefixed printk() level specifiers
> are usable for the user parts of UML.
Thanks Geert.
--
To unsubscribe from this list
On 23:36 Fri 28 Sep , Arnd Bergmann wrote:
> The atmel_nand driver was broken by b654a9a46fc2 "mtd: atmel nand: fix
> gpio missing request". This is a rather helpless attempt to fix this,
> probably messing up the error handling even further but getting the
> build to work again, so please trea
Ping on this patch?
-hpa
On 08/13/2012 10:26 AM, H. Peter Anvin wrote:
From: "H. Peter Anvin"
When we write entropy into a non-empty pool, we currently don't
account at all for the fact that we will probabilistically overwrite
some of the entropy in that pool. This means that unless
Am 27.09.2012 22:03, schrieb Jan Kara:
On Thu 27-09-12 17:46:48, Alexander Holler wrote:
Hello,
Am 27.09.2012 17:12, schrieb Jan Kara:
Just some thoughts about your oops:
The assertion which fails is:
BUG_ON(!list_empty(&bh->b_assoc_buffers));
Now b_assoc_buffers isn't used very much. In p
- UM_ELF_CLASS and UM_ELFCLASS32 became unused in commit
b743ac54e54ca18fb7164a97cc77cf1ccee0b0f7 ("um: disable scan_elf_aux()
on x86_64"),
- UM_ELFCLASS64 was never used, but only added for consistency with
UM_ELFCLASS32,
- UM_NR_CPUS became unused in commit
e6a2d1f7024f93e46
On Fri, 2012-09-28 at 11:50 -0700, Greg Kroah-Hartman wrote:
> From: Greg KH
>
> 3.5-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Sebastian Andrzej Siewior
>
> commit 1b68a4ca2d038addb7314211d122fb6d7002b38b upstream.
>
> If USB2 ho
On 2012.09.29 at 11:13 -0700, Andi Kleen wrote:
> From: Andi Kleen
>
> When linking perf statically some of the library dependencies are always
> rejected, so libdwarf and libbfd do not work. The problem is that these
> libraries (at least on my system) require other libraries. But unlike
> a sh
cc Omar
Hi Matt
On Fri, 28 Sep 2012, Matt Porter wrote:
> The AM33xx support requires some help in hwmod due to the following
> comment in arch/arm/mach-omap2/omap_hwmod.c:
> /*
>* If an IP block contains HW reset lines and any of them are
>* asserted, we let integration c
From: Andi Kleen
When linking perf statically some of the library dependencies are always
rejected, so libdwarf and libbfd do not work. The problem is that these
libraries (at least on my system) require other libraries. But unlike
a shared link the static link doesn't find those by itself, and
On Sat, Sep 29, 2012 at 07:02:36PM +0200, Krzysztof Halasa wrote:
> Arnd Bergmann writes:
> > explaining that we're closing the window for 3.7 except for a
> > few things that were already submitted earlier.
>
> No offense, but... You say how does it work for YOU but that's not
> exactly what I'm
On 09/24, Oleg Nesterov wrote:
>
> Anyway,
>
> > for example
> > 0f 1f 40 00
>
> OK, thanks, objdump reports "nopl 0x0(%rax)", looks fine.
>
> But. I do not see how __skip_sstep() can handle this case correctly.
> Not only it should update regs->ip afaics, it should also account 2
> extra bytes _af
On Sat, Sep 29, 2012 at 10:02 AM, Krzysztof Halasa wrote:
> It would be different if my tree included e.g. core ARM changes - but it
> doesn't. What's the _real_ reason for asking me to push my changes
> indirectly?
The reason is that when all ARM platform maintainers pushed code
straight to Lin
On Wed, Sep 26, 2012 at 11:49 AM, Maxim Levitsky
wrote:
> --- /dev/null
> +++ b/drivers/memstick/core/ms_block.c
> +#define pr_fmt(fmt) DRIVER_NAME ": " fmt
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#in
Since commit 9429ec96c2718c0d1e3317cf60a87a0405223814 ("um: Preinclude
include/linux/kern_levels.h") the non-prefixed printk() level specifiers
are usable for the user parts of UML.
Signed-off-by: Geert Uytterhoeven
---
arch/um/os-Linux/aio.c | 26 +-
arch/um/os-Linux
Since commit 9429ec96c2718c0d1e3317cf60a87a0405223814 ("um: Preinclude
include/linux/kern_levels.h") the non-prefixed printk() level specifiers
are usable for the user parts of UML.
Signed-off-by: Geert Uytterhoeven
---
arch/um/drivers/chan_user.c | 28 ++--
arch/um
Since commit 9429ec96c2718c0d1e3317cf60a87a0405223814 ("um: Preinclude
include/linux/kern_levels.h") the non-prefixed printk() level specifiers
are usable for the user parts of UML.
Signed-off-by: Geert Uytterhoeven
---
arch/x86/um/bugs_32.c| 14 +++---
arch/x86/um/os-Linux
All user parts of UML are using the non-prefixed printk() level specifiers
Signed-off-by: Geert Uytterhoeven
---
arch/um/include/shared/user.h | 11 ---
1 files changed, 0 insertions(+), 11 deletions(-)
diff --git a/arch/um/include/shared/user.h b/arch/um/include/shared/user.h
index c
Arnd Bergmann writes:
>> Could you please point me to a statement requiring eg. my changes to go
>> through arm-soc?
>
> We've been doing it like this for some time. Stephen Warren replied
> to your request to add your tree to linux-next in
>
> http://comments.gmane.org/gmane.linux.kernel/1356118
On 09/29/2012 03:37 PM, Paul E. McKenney wrote:
> Sasha, is the easily reproducible? If so, could you please try the
> previous patch? It will likely give us more information on where
> this bug really lives. (Yes, it might totally obscure the bug, but
> in that case we will just need to try som
Hi Heiko,
On Thu, Sep 27, 2012 at 1:51 PM, Heiko Carstens
wrote:
> On Sun, Sep 16, 2012 at 09:07:54PM +0200, Geert Uytterhoeven wrote:
>> After applying http://www.spinics.net/lists/linux-next/msg21973.html,
>> the s390 allmodconfig build in linux-next fails in the linking stage with:
>>
>> ERROR
On Sat, 2012-09-29 at 17:11 +0100, David Woodhouse wrote:
>
> That check seems to have been missing from David's commit 402d3265 in
> which he introduced the mtd_mmap() operation, and wasn't fixed in commit
> dd02b67d5 where Anatolij fixed things to actually *work* in the MMU code
> path. This sho
On Fri, 2012-09-28 at 13:16 -0700, Greg Kroah-Hartman wrote:
> 3.4-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Andre Guedes
>
> commit 61a0cfb008f57ecf7eb28ee762952fb42dc15d15 upstream.
>
> If SMP fails, we should always cancel secur
On Fri, 2012-09-28 at 20:04 +0100, David Woodhouse wrote:
> > I was really hoping it would go through the regular channels and come
> > back to me that way, since I can't really test it, and it's bigger
> > than the trivial obvious one-liners that I'm happy to commit.
>
> I can't test it on real h
Dear Sarah,
got some time off work, for the sake of those good old days...
Don's patch worked, it sees now the device and I can mount both
partitions (one dos, the other ext4) on it :)
The kernel I applied the pacth to was the openSuSE Factory 64-bit
3.6.0-rc7-1-desktop kernel. (Actually I just
On Fri, 28 Sep 2012, Benjamin Tissoires wrote:
> > From: Xianhan Yu
> >
> > Fix the touch-up no response problem on GeneralTouch twofingers
> > touchscreen and modify the driver for new GeneralTouch PWT
> > touchscreen.
> >
> > Signed-off-by: Xianhan Yu
>
> Hi,
>
> Thank you for re-submittin
On Sat, Sep 29, 2012 at 09:41:17AM -0400, Chris Ball wrote:
> On Sat, Sep 29 2012, Borislav Petkov wrote:
> > So, I think that this driver has seen a bunch of testing and reviewing
> > and we might start considering upstreaming it. There are a bunch of
> > laptops integrating those readers and mayb
Op 28-09-12 22:10, Thomas Hellstrom schreef:
> On 09/28/2012 09:42 PM, Thomas Hellstrom wrote:
>> On 09/28/2012 04:14 PM, Maarten Lankhorst wrote:
>>> Hey,
>>>
>>> Op 28-09-12 14:41, Maarten Lankhorst schreef:
Documentation says that code requiring dma-buf should add it to
select, so inli
PAT support are lacking only in the Pentium Pro and Pentium II. Sorry, if
you're using crap that old, you don't get to screw up the kernel for everyone
else.
Henrique de Moraes Holschuh wrote:
>On Fri, 28 Sep 2012, H. Peter Anvin wrote:
>> On 09/28/2012 10:37 AM, Peter Hurley wrote:
>> > An i
On Saturday 29 September 2012, Jonathan Cameron wrote:
> On 09/28/2012 10:36 PM, Arnd Bergmann wrote:
> > The driver has not been building for some time after the
> > irq_to_gpio function has been removed from the kernel.
> >
> > The only board in the upstream kernel that provides
> > this device
On Saturday 29 September 2012, Krzysztof Halasa wrote:
> > I realize it won't make 3.7 any more since the base patches are not
> > in arm-soc, but it's bad if linux-next is broken.
>
> Well, I'm not aware of any requirement to push my IXP4xx changes
> exclusively through arm-soc. I believe I can s
On Sat, Sep 29, 2012 at 07:30:06AM -0700, Andi Kleen wrote:
> On Sat, Sep 29, 2012 at 03:48:11PM +0200, Andrea Arcangeli wrote:
> > On Sat, Sep 29, 2012 at 02:37:18AM +0300, Kirill A. Shutemov wrote:
> > > Cons:
> > > - increases TLB pressure;
> >
> > I generally don't like using 4k tlb entries e
Hi,
Borislav Petkov writes:
Adding Peter.
Just wanted to say, that I've got currently very less spare time. I think
I'll be fully available again in about 2 weeks. I'll catch up then.
--
Thanks and kind regards,
--peter;
--
To unsubscribe from this list: send the line "unsubscribe linux-ke
On Sat, Sep 29, 2012 at 03:48:11PM +0200, Andrea Arcangeli wrote:
> On Sat, Sep 29, 2012 at 02:37:18AM +0300, Kirill A. Shutemov wrote:
> > Cons:
> > - increases TLB pressure;
>
> I generally don't like using 4k tlb entries ever. This only has the
>From theory I would also prefer the 2MB huge pa
On Sat, Sep 29, 2012 at 03:50:07PM +0200, Frederic Weisbecker wrote:
> On Sat, Sep 29, 2012 at 06:37:37AM -0700, Paul E. McKenney wrote:
> > On Sat, Sep 29, 2012 at 02:25:04PM +0200, Frederic Weisbecker wrote:
> > > 2012/9/29 Sasha Levin :
> > > > Maybe I could help here a bit.
> > > >
> > > > lapp
On Sat, Sep 29, 2012 at 06:37:37AM -0700, Paul E. McKenney wrote:
> On Sat, Sep 29, 2012 at 02:25:04PM +0200, Frederic Weisbecker wrote:
> > 2012/9/29 Sasha Levin :
> > > Maybe I could help here a bit.
> > >
> > > lappy linux # addr2line -i -e vmlinux 8111d45f
> > > /usr/src/linux/kernel/ti
On Sat, Sep 29, 2012 at 02:37:18AM +0300, Kirill A. Shutemov wrote:
> Cons:
> - increases TLB pressure;
I generally don't like using 4k tlb entries ever. This only has the
advantage of saving 2MB-4KB RAM (globally), and a chpxchg at the first
system-wide zero page fault. I like apps to only use 2
Hi,
On Sat, Sep 29 2012, Borislav Petkov wrote:
> So, I think that this driver has seen a bunch of testing and reviewing
> and we might start considering upstreaming it. There are a bunch of
> laptops integrating those readers and maybe a single three-month-ish -rc
> period of testing wouldn't hur
> -Original Message-
> From: Alan Cox [mailto:a...@lxorguk.ukuu.org.uk]
> Sent: Friday, September 28, 2012 8:54 PM
> To: Zhang, Rui
> Cc: LKML; linux-pm; linux-i2c; linux-a...@vger.kernel.org; Len, Brown;
> Rafael J. Wysocki; Grant Likely; Dirk Brandewie
> Subject: Re: [RFC PATCH 5/6] ACP
On Sat, Sep 29, 2012 at 02:25:04PM +0200, Frederic Weisbecker wrote:
> 2012/9/29 Sasha Levin :
> > Maybe I could help here a bit.
> >
> > lappy linux # addr2line -i -e vmlinux 8111d45f
> > /usr/src/linux/kernel/timer.c:549
> > /usr/src/linux/include/linux/jump_label.h:101
> > /usr/src/linux
I dumped a working registry by booting with acpi=off kernel parameter.
EC RAM:
00: 02 00 00 00 02 02 00 01 00 09 00 00 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
40: 00 00
> -Original Message-
> From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com]
> Sent: Friday, September 28, 2012 10:14 PM
> To: Zhang, Rui
> Cc: LKML; linux-pm; linux-i2c; linux-a...@vger.kernel.org; Len, Brown;
> Rafael J. Wysocki; Grant Likely; Dirk Brandewie
> Subject: Re: [RFC
Just to state it out explicitely, the power saving RC6 is broken on the GPU.
On 09/29/2012 10:16 AM, Toralf Förster wrote:
>
> Hello,
>
> I'm observed hot CPUs at my ThinkPad T420 (i5-2540M CPU) w/ integrated
> intel graphic with current git
> Powertop-2.1 shows that the GPU is always at 100%.
>
The correct syntax for gcc -x is "gcc -x assembler", not
"gcc -xassembler". Even though the latter happens to work, the former
is what is documented in the manual page and thus what gcc wrappers
such as icecream do expect.
This isn't a cosmetic change. The missing space prevents icecream from
reco
Dear Sarah,
I know this is not a very constructive reply, but these days I am so
busy that I just cannot find the time apply kernel patches :(
I would love to do that, indeed! In the good old days, I would even hack
the UDMI module in the kernel when my new notebook's
drive interface was not reco
Dear Dan,
thank you, I could not file the bugzilla report for some reason (can't
recall now why exactly).
The lsusb output is:
Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
Bus 004 Device 007: I
On Fri, 2012-09-28 at 11:49 -0700, Greg Kroah-Hartman wrote:
> From: Greg KH
>
> 3.5-stable review patch. If anyone has any objections, please let me know.
>
> --
>
> From: Will Deacon
>
> commit dbece45894d3ab1baac15a96dc4e1e8e23f64a93 upstream.
>
> When enabling the MMU fo
2012/9/29 Sasha Levin :
> Maybe I could help here a bit.
>
> lappy linux # addr2line -i -e vmlinux 8111d45f
> /usr/src/linux/kernel/timer.c:549
> /usr/src/linux/include/linux/jump_label.h:101
> /usr/src/linux/include/trace/events/timer.h:44
> /usr/src/linux/kernel/timer.c:601
> /usr/src/lin
Hi Ingo, hi Bernhard,
Le samedi 29 septembre 2012 à 09:24 +0100, Bernhard Walle a écrit :
> * Ingo Molnar [2012-09-29 08:37]:
> > * Jean Delvare wrote:
> >
> > > The correct syntax for gcc -x is "gcc -x assembler", not "gcc
> > > -xassembler". Even though the latter happens to work, the
> > >
Hi,
Thank you for your email addressed to Matt Zimmerman. After 7 years
extraordinary years at Canonical, Matt has moved on to a new project.
For Ubuntu / Canonical related issues:
* Ubuntu development - Rick Spencer - rick.spen...@canonical.com
* Commercial alliances / opportunities - Chris Ke
On Fri, Sep 28, 2012 at 09:00:04PM -0400, Phil Turmel wrote:
> > Wei WANG (3):
> > drivers/mfd: Add realtek pcie card reader driver
> > drivers/mmc: Add realtek pcie sdmmc host driver
> > drivers/memstick: Add realtek pcie memstick host driver
>
> I have a recent HP Pavilion dv6 with this ca
On Saturday 29 September 2012 12:37 PM, Jiri Slaby wrote:
> On 09/29/2012 08:40 AM, Vineet Gupta wrote:
>> On Friday 28 September 2012 06:32 PM, Jiri Slaby wrote:
>>> On 09/28/2012 02:19 PM, Alexey Brodkin wrote:
Modify divisor to select the nearest baud rate divider rather than the
lowes
On Fri, 28 Sep 2012, H. Peter Anvin wrote:
> On 09/28/2012 10:37 AM, Peter Hurley wrote:
> > An interesting side note: more recent revisions of this BIOS (rev. A11)
> > report one less variable MTRR (so, IA32_MTRRCAP is writable?)
> >
> >>> However, the right way to fix that is to use the PAT inte
Add ECAP and EHRPWM device tree nodes to AM33XX SoC family
by adding necessary properties like pwm-cells, base reg & set disabled
as status.
Signed-off-by: Philip, Avinash
---
:100644 100644 a9c885a... 736ba0a... M arch/arm/boot/dts/am33xx.dtsi
arch/arm/boot/dts/am33xx.dtsi | 48 +
This patch set adds support for device tree data for ECAP & EHRPWM
& device tree data for am335x-evm with PWM as backlight.
This has been based on [1] merged with [2] & depends on [3]
1. linux-next/master
2. linux-omap-dt/for_3.7/dts_part2
3. http://www.mail-archive.com/linux-kernel@vger.kernel.or
PWM output from ecap0 uses as backlight source. Also adds low threshold
value to have a uniform divisions in brightness-levels scales.
Signed-off-by: Philip, Avinash
---
:100644 100644 a5c4c62... 5516098... M arch/arm/boot/dts/am335x-evm.dts
arch/arm/boot/dts/am335x-evm.dts | 21 +
Arnd Bergmann writes:
> Krzysztof, please apply in your next branch so this problem goes away in
> 3.8.
Right, I'll look at it.
> I realize it won't make 3.7 any more since the base patches are not
> in arm-soc, but it's bad if linux-next is broken.
Well, I'm not aware of any requirement to pu
On Sat, Sep 29, 2012 at 15:12:53, Jonathan Cameron wrote:
> On 09/26/2012 06:20 AM, Patil, Rachna wrote:
> > This patch set adds a MFD core driver which registers touchscreen and
> > ADC as its client drivers.
> > The existing touchscreen has been modified to work as a MFD client
> > driver and a
On 09/28/2012 10:36 PM, Arnd Bergmann wrote:
> The driver has not been building for some time after the
> irq_to_gpio function has been removed from the kernel.
>
> The only board in the upstream kernel that provides
> this device is the "Stargate 2", which is also maintained
> by Jonathan Cameron
On 09/26/2012 11:09 AM, Patil, Rachna wrote:
> Hi Shubhrajyoti,
>
> On Wed, Sep 26, 2012 at 12:10:51, Datta, Shubhrajyoti wrote:
>> On Wednesday 26 September 2012 10:50 AM, Patil, Rachna wrote:
>>> This patch adds support for suspend/resume of
>>> TSC/ADC MFDevice.
>> this should be merged with th
On 09/26/2012 06:20 AM, Patil, Rachna wrote:
> This patch adds support for TI's ADC driver.
> This is a multifunctional device.
> Analog input lines are provided on which
> voltage measurements can be carried out.
> You can have upto 8 input lines.
>
> Signed-off-by: Patil, Rachna
Acked-by: Jonat
On 09/26/2012 06:20 AM, Patil, Rachna wrote:
> This patch set adds a MFD core driver which registers
> touchscreen and ADC as its client drivers.
> The existing touchscreen has been modified to work as
> a MFD client driver and a new ADC driver has been added
> in the IIO subsystem.
>
> There are
> > Hmm, it looks like the work on making evdev using dynamic device numbers
> > will clash with Henrik's changes. I think I will also pull this into my
> > tree and then git should be able to resolve it all properly in -next.
>
> That should work. Alternatively you can pull 'from-henrik' branch f
1 - 100 of 119 matches
Mail list logo
