Substitute ALC889 for ALC882 in macro and function names.
Cc: sta...@vger.kernel.org
Cc: alsa-de...@alsa-project.org
Signed-off-by: Fernando Luis Vazquez Cao
---
diff -urNp linux-3.7.6-orig/sound/pci/hda/patch_realtek.c
linux-3.7.6/sound/pci/hda/patch_realtek.c
---
The problem addressed by this fixup is not specific to Vaio Z, affecting
some Vaio all-in-one desktop PCs too. Update the code comments accordingly.
Cc: sta...@vger.kernel.org
Cc: alsa-de...@alsa-project.org
Signed-off-by: Fernando Luis Vazquez Cao
---
diff -urNp
Some Vaio all-in-one desktop PCs (for example VGC-LN51JGB) are affected by
the same issue that caused Vaio Z laptops to become silent: the speaker pin
must be connected to the first DAC even though the codec itself advertises
flexible routing through any of the DACs.
Use the no-primary-hp fixup
On 02/11/2013 06:07 PM, Sascha Hauer wrote:
> On Mon, Feb 11, 2013 at 05:44:23PM +0200, Roger Quadros wrote:
>> Currently on OMAP, it is not possible to specify a clock consumer
>> to any of the OMAP generated clocks using the device tree. This can pose
>> a problem for external devices that run
From: Ben Hutchings
Date: Fri, 01 Feb 2013 18:40:57 +0100
> On Wed, 2013-01-16 at 13:56 -0200, Herton Ronaldo Krzesinski wrote:
>> 3.5.7.3 -stable review patch. If anyone has any objections, please let me
>> know.
>>
>> --
>>
>> From: Eric Dumazet
>>
>> commit
From: "Philip, Avinash"
EHRPWM module requires explicit clock gating of TBCLK from control
module. Hence add TBCLK clock node in clock tree for EHRPWM modules.
Signed-off-by: Philip Avinash
---
Changes since v1:
- Remove sparse warnings
On 02/11/2013 09:22 PM, Jon Hunter wrote:
> Good point. I just noticed that none of my omap2+ board were booting and
> on omap3/4 I was the panic in the twl code. I can't say that I checked
> the panic on omap2, so may be that was another problem?
Do you have insights on the code path leading to
This driver supports GRGPIO gpio cores available in the GRLIB VHDL IP
core library from Aeroflex Gaisler.
This also adds support to gpio-generic for using custom accessor
functions. The grgpio driver uses this to use ioread32be and iowrite32be
for big endian register accesses.
Signed-off-by:
Just to be sure, I re-ran the comparison using gcc 4.6.3 instead of gcc
4.7.2. With gcc 4.6.3 I consistently get a few hundred bytes longer
with the bitfield variant than with the pre-get_user() baseline.
I looked at some of the diffed disassembly, and the differences seem to
be in the code
On Tue, 2013-02-12 at 01:31 +0400, Kirill Tkhai wrote:
> It's possible a situation when rq->rt is throttled or
> it has no child entities and there are RT tasks ready
> for execution in the rq which are the only tasks
> of TASK_RUNNING state. In this case pick_next_task
> takes idle tasks and
On Fri, Feb 08, 2013 at 20:40:18, Paul Walmsley wrote:
> Hi
>
> On Wed, 2 Jan 2013, Philip Avinash wrote:
>
> > EQEP entry is HWMOD entry is not present in HWMOD entry.
>
> Patch descriptions need to make sense. This one does not. I've fixed it
> for you this time, but please take more care
On Fri, Feb 08, 2013 at 20:36:53, Paul Walmsley wrote:
> Hi,
>
> On Wed, 2 Jan 2013, Philip Avinash wrote:
>
> > EHRPWM module requires explicit clock gating of TBCLK from control
> > module. Hence add TBCLK clock node in clock tree for EHRPWM modules.
> >
> > Signed-off-by: Philip Avinash
>
11.02.2013 20:37, J. Bruce Fields пишет:
On Mon, Feb 11, 2013 at 10:18:18AM +0400, Stanislav Kinsbursky wrote:
This one looks a bit complicated and confusing to me. Probably because
I'm not that familiar with service transports processing logic. So,
as I can see, we now try to run over all
On Mon, Feb 11, 2013 at 01:43:03PM -0600, Rob Herring wrote:
> On 02/11/2013 02:22 AM, Thierry Reding wrote:
> > From: Andrew Murray
> >
> > DT bindings for PCI host bridges often use the ranges property to describe
> > memory and IO ranges - this binding tends to be the same across
> >
tried Linus' tree and linux-next but they
> > didn't apply cleanly against either.
>
> The series was generated against next-20130204. 13/23 doesn't apply
> cleanly at next-20130211 because of changes since. Rebases fine
> though :)
Should have tried harder against next, git-am is very p
On Mon, Feb 11, 2013 at 02:52:36PM +, Mel Gorman wrote:
> A user reported the following oops when a backup process read
> /proc/kcore.
>
> BUG: unable to handle kernel paging request at bb00ff33b000
> IP: [] kern_addr_valid+0xbe/0x110
> PGD 0
> Oops: [#1] SMP
> CPU 6
> Modules
Hello.
> On Monday 11 February 2013, Alexander Shiyan wrote:
> > The driver can be used in various subsystems and therefore should not
> > be unloaded when it is defined in the kernel configuration, so remove
> > support for unloading it.
> >
> > Signed-off-by: Alexander Shiyan
>
> Can you
Populate OF_DEV_AUXDATA with desired device name expected by
davinci_mmc driver. Without this clk_get of davinci_mmc DT driver
fails.
Signed-off-by: Manjunathappa, Prakash
Cc: linux-...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Cc:
On 2/7/2013 1:27 PM, Manjunathappa, Prakash wrote:
> Adds device tree support for davinci_mmc. Also add binding documentation.
> Tested in non-dma PIO mode and without GPIO card_detect/write_protect
> option because of dependencies on EDMA and GPIO module DT support.
>
> Signed-off-by:
On Tue, Feb 12, 2013 at 11:16:21, Nori, Sekhar wrote:
> On 2/7/2013 1:27 PM, Manjunathappa, Prakash wrote:
> > Populate OF_DEV_AUXDATA with desired device name expected by
> > davinci_mmc driver. Without this clk_get of davinci_mmc DT driver
> > fails.
>
> But there is no mmc DT support for
On Tue, Feb 12, 2013 at 11:51:13AM +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2013-02-11 at 20:52 +, Grant Likely wrote:
> > Really the irq mappings should be using reference counting. The existing
> > code is naive on this count and just releases the irq on the first call
> > to
On Mon, 2013-02-11 at 17:39 -0700, Stephen Warren wrote:
> From: Stephen Warren
>
> Allow K: entries in MAINTAINERS to match directly against filenames;
> either those extracted from patch +++ or --- lines, or those specified
> on the command-line using the -f option.
[]
> diff --git
On 02/11/2013 01:34 AM, Ingo Molnar wrote:
>
> * Yinghai Lu wrote:
>
>> Hi,
>>
>> Current x86 code does not support iapic hotplug yet.
>
> Please give a better high-level description: outline how an
> IO-APIC will be hotplugged physically and what changes the
> user will experience.
>
>
Johannes Weiner writes:
> On Mon, Feb 11, 2013 at 01:43:03PM +1030, Rusty Russell wrote:
>> I am writing an app which really wants to know if a file is on the
>> disk or not (ie. do I need to sync?).
>
> When the page is under writeback, it's not necessarily on disk yet,
> but you also don't
Andrew Morton writes:
> On Mon, 11 Feb 2013 11:27:01 -0500
> Johannes Weiner wrote:
>
>> > Is PG_dirty the right choice? Is that right for huge pages? Should I
>> > assume is_migration_entry(entry) means it's not dirty, or is there some
>> > other check here?
>>
>> If your only consequence of
On 2/7/2013 1:27 PM, Manjunathappa, Prakash wrote:
> Populate OF_DEV_AUXDATA with desired device name expected by
> davinci_mmc driver. Without this clk_get of davinci_mmc DT driver
> fails.
But there is no mmc DT support for DaVinci at this time. This patch
should come after the driver DT
From: Loic Pallardy
Some mailboxes are made up of cross interrupts
and associated shared memory.
Shared memory mapping is fixed and cross interrupt/shared
memory relation make impossible the use of virtio.
Mailbox framework must be enough opened to support
any kind of mailbox.
Signed-off-by:
On Tue, 2013-02-12 at 15:06 +1100, Alexey Kardashevskiy wrote:
> Having this patch in a tree, adding new nodes in sysfs
> for IOMMU groups is going to be easier.
>
> The first candidate for this change is a "dma-window-size"
> property which tells a size of a DMA window of the specific
> IOMMU
From: Loic Pallardy
TX: replace spin by mutex to release CPU
during wait on mailbox resource.
Signed-off-by: Loic Pallardy
Signed-off-by: Linus Walleij
---
drivers/mailbox/mailbox.c | 5 +++--
drivers/mailbox/mailbox_internal.h | 1 +
2 files changed, 4 insertions(+), 2 deletions(-)
Hi,
Please find below the updated patch series for mailbox framework creation.
After commit e8d3d47 (ARM: OMAP2+: Drop plat/cpu.h for omap2plus), the
cpu_is_xxx() checks for OMAP are restricted to arch/arm/mach-omap2. The
series includes 4 new patches, first patch removes these earch specific
Add a NULL check for iomem resource in mailbox probe functions.
Signed-off-by: Fernando Guzman Lugo
Signed-off-by: Suman Anna
---
drivers/mailbox/mailbox-omap1.c | 3 +++
drivers/mailbox/mailbox-omap2.c | 5 +
2 files changed, 8 insertions(+)
diff --git a/drivers/mailbox/mailbox-omap1.c
From: Loic Pallardy
Add STEriccson DBX500 PRCM mailbox support.
Signed-off-by: Loic Pallardy
Signed-off-by: Linus Walleij
---
drivers/mailbox/Kconfig | 7 +
drivers/mailbox/Makefile | 1 +
drivers/mailbox/mailbox-dbx500.c | 611
Stephen Warren wrote @ Tue, 12 Feb 2013 05:47:20 +0100:
> >>> static void __init harmony_init(void)
> >>> {
> >>> -#ifdef CONFIG_TEGRA_PCI
> >>> int ret;
> >>>
> >>> ret = harmony_pcie_init();
> >>> if (ret)
> >>> pr_err("harmony_pcie_init() failed: %d\n", ret);
> >>> -#endif
From: Loic Pallardy
Coprocessor must be accessible during suspend transitions.
Signed-off-by: Loic Pallardy
Signed-off-by: Linus Walleij
---
drivers/mailbox/mailbox.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
From: Loic Pallardy
In order to create a generic mailbox framework, functions
and structures should be renamed in mailbox.
Taking care of remoteproc and tidspbridge while at it.
Signed-off-by: Loic Pallardy
Signed-off-by: Omar Ramirez Luna
Signed-off-by: Linus Walleij
---
From: Omar Ramirez Luna
Now internal structures can remain hidden to the user and just API
related functions and defines are made available.
Signed-off-by: Omar Ramirez Luna
Signed-off-by: Linus Walleij
---
drivers/mailbox/mailbox.c | 34 ++
The OMAP mailbox platform driver code has been cleaned up to
remove the dependencies with soc.h in preparation for moving
the mailbox code to drivers folder.
The code relied on cpu_is_xxx/soc_is_xxx macros previously to
pick the the right set of mailbox devices and register with the
mailbox
The mailbox_put function must check the notifier block for
NULL before trying to unregister it.
Signed-off-by: Fernando Guzman Lugo
Signed-off-by: Suman Anna
---
drivers/mailbox/mailbox.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mailbox/mailbox.c
From: Loic Pallardy
Current message type is a u32 to fit HW fifo format.
This should be extended to support any message exchanges
and type of mailbox.
Proposed structure owns the original u32 and an optional
pointer on additional data.
Adaptations made to remoteproc and tidspbridge drivers.
From: Loic Pallardy
For debug purpose, mailbox must be available when
interrupts are disabled to collect dump information.
Signed-off-by: Loic Pallardy
Signed-off-by: Linus Walleij
---
drivers/mailbox/mailbox.c | 66 +++
include/linux/mailbox.h |
The mailbox startup code is enabling the interrupt even before
any of the associated mailbox queues are allocated. Any pending
received mailbox message could cause a kernel panic as soon as
the interrupt is enabled due to the dereferencing of non-existing
mailbox queues within the ISR.
On 02/11/2013 08:47 PM, Linus Torvalds wrote:
On Mon, Feb 11, 2013 at 8:42 PM, Linus Torvalds
wrote:
But I don't see anything fundamentally wrong with it. Certainly it
looks much better than the disgusting and warning-prone
unsigned long long __val_gu8
thing.
Oh. I just realized.
On 02/11/2013 09:12 PM, Hiroshi Doyu wrote:
> Stephen Warren wrote @ Tue, 12 Feb 2013 00:54:03
> +0100:
>
>>> -obj-$(CONFIG_ARCH_TEGRA_2x_SOC)+= tegra.o
>>> -obj-$(CONFIG_ARCH_TEGRA_3x_SOC)+= board-dt-tegra30.o
>>> -obj-$(CONFIG_ARCH_TEGRA_114_SOC) +=
On Mon, Feb 11, 2013 at 8:42 PM, Linus Torvalds
wrote:
>
> But I don't see anything fundamentally wrong with it. Certainly it
> looks much better than the disgusting and warning-prone
>
> unsigned long long __val_gu8
>
> thing.
Oh. I just realized. That was your _baseline_ in the
On Mon, Feb 11, 2013 at 8:21 PM, H. Peter Anvin wrote:
> On 02/11/2013 07:33 PM, Linus Torvalds wrote:
>
>> Has anybody run this past any gcc developers? And if so, did they run
>> away screaming?
>
> I haven't no... H.J., any comments on this patch?
I'd be most worried about any known pitfalls
Hi James,
On Mon, 11 Feb 2013 11:57:28 + James Hogan wrote:
>
> On 12/11/12 21:26, Stephen Rothwell wrote:
> > Make if easier for more architectures to select it and thus disable
> > drivers that use virt_to_bus().
> >
> > Signed-off-by: Stephen Rothwell
>
> I was just wondering what the
Commit-ID: 385404e0ce4dbceb72f3f89cb172b2e60ef8e6d3
Gitweb: http://git.kernel.org/tip/385404e0ce4dbceb72f3f89cb172b2e60ef8e6d3
Author: Mike Travis
AuthorDate: Mon, 11 Feb 2013 13:45:14 -0600
Committer: H. Peter Anvin
CommitDate: Mon, 11 Feb 2013 17:18:19 -0800
x86, uv, uv3: Check
On 02/11/2013 07:33 PM, Linus Torvalds wrote:
> On Mon, Feb 11, 2013 at 5:37 PM, tip-bot for H. Peter Anvin
> wrote:
>>
>> However, we can declare a bitfield using sizeof(), which is legal
>> because sizeof() is a constant expression. This quiets the warning,
>> although the code generated isn't
Commit-ID: 0af6352045a3bf359a2d5f55965266d67d262b47
Gitweb: http://git.kernel.org/tip/0af6352045a3bf359a2d5f55965266d67d262b47
Author: Mike Travis
AuthorDate: Mon, 11 Feb 2013 13:45:13 -0600
Committer: H. Peter Anvin
CommitDate: Mon, 11 Feb 2013 17:18:12 -0800
x86, uv, uv3: Update
Commit-ID: b15cc4a12bed8026bc70f469f514862b027b0c75
Gitweb: http://git.kernel.org/tip/b15cc4a12bed8026bc70f469f514862b027b0c75
Author: Mike Travis
AuthorDate: Mon, 11 Feb 2013 13:45:12 -0600
Committer: H. Peter Anvin
CommitDate: Mon, 11 Feb 2013 17:18:03 -0800
x86, uv, uv3: Update
Commit-ID: 6edbd4714edd8af64ec6a1bb8d89d0cb2bbe671e
Gitweb: http://git.kernel.org/tip/6edbd4714edd8af64ec6a1bb8d89d0cb2bbe671e
Author: Mike Travis
AuthorDate: Mon, 11 Feb 2013 13:45:11 -0600
Committer: H. Peter Anvin
CommitDate: Mon, 11 Feb 2013 17:17:50 -0800
x86, uv, uv3: Update Hub
Commit-ID: 526018bc5eccfe3177780f03d2aaba0efee40720
Gitweb: http://git.kernel.org/tip/526018bc5eccfe3177780f03d2aaba0efee40720
Author: Mike Travis
AuthorDate: Mon, 11 Feb 2013 13:45:10 -0600
Committer: H. Peter Anvin
CommitDate: Mon, 11 Feb 2013 17:17:44 -0800
x86, uv, uv3: Update
unregister_dgrp_device on a NULL pointer is a no-op, so the NULL checks in
dgrp_remove_nd() can be removed.
Signed-off-by: Cyril Roelandt
---
drivers/staging/dgrp/dgrp_specproc.c |9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git
Stephen Warren wrote @ Tue, 12 Feb 2013 00:54:03 +0100:
> > -obj-$(CONFIG_ARCH_TEGRA_2x_SOC)+= tegra.o
> > -obj-$(CONFIG_ARCH_TEGRA_3x_SOC)+= board-dt-tegra30.o
> > -obj-$(CONFIG_ARCH_TEGRA_114_SOC) += board-dt-tegra114.o
> > +obj-y
unregister_and_remove_pcpu on a NULL pointer is a no-op, so the NULL check in
sync_pcpu can be removed.
Signed-off-by: Cyril Roelandt
---
drivers/xen/pcpu.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/xen/pcpu.c b/drivers/xen/pcpu.c
index 067fcfa..5a27a45
dma_ops_domain_free on a NULL pointer is a no-op, so the NULL check in
amd_iommu_init_dma_ops() can be removed.
Signed-off-by: Cyril Roelandt
---
drivers/iommu/amd_iommu.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/iommu/amd_iommu.c
delete_msg_mgr on a NULL pointer is a no-op, so the NULL check in
bridge_msg_delete can be removed.
Signed-off-by: Cyril Roelandt
---
drivers/staging/tidspbridge/core/msg_sm.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/tidspbridge/core/msg_sm.c
Remove redundant NULL checks before calls to functions that are equivalent to a
no-op when run on a NULL pointer.
These patches were generated by the following semantic patch, and manually
reviewed:
@r@
identifier noop_func;
identifier param;
type T;
@@
noop_func (T *param) {
...
radeon_i2c_destroy on a NULL pointer is a no-op.
Signed-off-by: Cyril Roelandt
---
drivers/gpu/drm/radeon/radeon_i2c.c |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_i2c.c
b/drivers/gpu/drm/radeon/radeon_i2c.c
index fc60b74..850df44
Having this patch in a tree, adding new nodes in sysfs
for IOMMU groups is going to be easier.
The first candidate for this change is a "dma-window-size"
property which tells a size of a DMA window of the specific
IOMMU group which can be used later for locked pages accounting.
Signed-off-by:
Argh, your right. I completely misread that section.
It'll take me a few days to respin and retest properly.
Thanks,
Nate
From: Rafael J. Wysocki [r...@sisk.pl]
Sent: Monday, February 11, 2013 1:36 PM
To: Nathan Zimmer
Cc: viresh.ku...@linaro.org;
On 02/12/2013 12:38 AM, Paul E. McKenney wrote:
> On Mon, Feb 11, 2013 at 05:53:41PM +0530, Srivatsa S. Bhat wrote:
>> On 02/11/2013 05:28 PM, Vincent Guittot wrote:
>>> On 8 February 2013 19:09, Srivatsa S. Bhat
>>> wrote:
>
> [ . . . ]
>
Adding Vincent to CC, who had previously evaluated
Hi all,
Today's linux-next merge of the arm-soc tree got a conflict in
arch/arm/mach-omap2/board-zoom-peripherals.c between commit 51482be9dcfd
("ARM: OMAP: USB: Add phy binding information") from the usb tree and
commit c5913935657f ("ARM: OMAP: zoom: Audio support via the common
omap-twl4030
Hi all,
Today's linux-next merge of the arm-soc tree got conflicts in
drivers/clocksource/Makefile and drivers/clocksource/Kconfig between
commit 3fedb0674fbc ("metag: Time keeping") from the metag tree and
commits 8a4da6e36c58 ("arm: arch_timer: move core to
drivers/clocksource") and ("arm64:
Hi Linus,
Can you please pull the m68knommu git tree, for-linus branch.
It contains a single critical fix for the non-MMU m68k platforms. The change
of the kernel exec code path has revealed a problem in the start thread code
that causes crashing on boot. This is the fix for it.
Regards
Greg
On Mon, Feb 11, 2013 at 5:37 PM, tip-bot for H. Peter Anvin
wrote:
>
> However, we can declare a bitfield using sizeof(), which is legal
> because sizeof() is a constant expression. This quiets the warning,
> although the code generated isn't 100% identical from the baseline
> before 96477b4
On Mon, Feb 11, 2013 at 4:08 PM, Yinghai Lu wrote:
> On Mon, Feb 11, 2013 at 2:41 PM, Bjorn Helgaas wrote:
>> [+cc linux-acpi, linux-pci]
>>
>> The _PRT describes motherboard interrupt wiring, which has nothing to
>> do with PCI bus numbers. Our current drivers/acpi/pci_irq.c caches
>> the PCI
"Ext Spk", "PREDRIVER",
>>> "MAINMIC", "Main Mic",
>>> "Main Mic", "Mic Bias 1";
>>>
>>> So you connect the MicBias1 to Main Mic. When you start playback MicBias1
>>> w
Re: [Patch 0/2] Exclude hwpoison page from vmcore dump
(2012/11/01 19:40), Eric W. Biederman wrote:
> Mitsuhiro Tanino writes:
> I agree. If we are performing filtering filtering out of poisoned pages
> seems very reasonable. So ack on the basic concept.
>
> Eric
Hello, Eric,
Could you
do_initcalls() could call all driver initialization code in kernel_init
thread. It means that probe() function will be also called from that
time. After this, kernel could access console & release __init section
in the same thread.
But if device probe fails and moves into deferred probe list, a
gt; > [PATCH v3 00/23] ldisc fixes
>
> What are they against? I tried Linus' tree and linux-next but they
> didn't apply cleanly against either.
The series was generated against next-20130204. 13/23 doesn't apply
cleanly at next-20130211 because of changes since. Rebases fine
though :)
On 12 February 2013 07:10, Andrew Morton wrote:
> On Sun, 10 Feb 2013 00:57:57 +0800
> Haojian Zhuang wrote:
>
>> do_initcalls() could call all driver initialization code in kernel_init
>> thread. It means that probe() function will be also called from that
>> time. After this, kernel could
On Mon, Feb 11, 2013 at 8:31 PM, Grant Likely wrote:
> On Mon, Feb 11, 2013 at 4:28 AM, Alex Courbot wrote:
>> Just wondering: if we manage to change this spinlock into a mutex in the
>> future, wouldn't it be better to acquire it only once in gpiolib_seq_start()
>> and release it in
pdc_desc_get() is called from pd_prep_slave_sg, and the function is
called from interrupt context(e.g. Uart driver "pch_uart.c").
In fact, I saw kernel error message.
So, GFP_ATOMIC must be used not GFP_NOIO.
Signed-off-by: Tomoya MORINAGA
---
drivers/dma/pch_dma.c |2 +-
1 files changed, 1
On 12 February 2013 03:49, Rafael J. Wysocki wrote:
> On Monday, February 11, 2013 08:27:49 PM Rafael J. Wysocki wrote:
>> On Monday, February 11, 2013 12:01:37 PM Bjorn Helgaas wrote:
>> > [+cc Rafael]
>> >
>> > On Mon, Feb 11, 2013 at 10:08 AM, Daniel J Blueman
>> > wrote:
>> > > On 11
Hi,
As discussed in this thread:
http://marc.info/?l=linux-mm=131490523222031=2
(with this cleanup as well: https://lkml.org/lkml/2011/9/2/225)
A tunable was proposed to allow specifying the distance between pages_min
and the low watermark before kswapd is kicked in to free up pages. I'd
like to
On Mon, Feb 11, 2013 at 09:42:30AM -0500, Peter Hurley wrote:
> Hi Michael,
>
> On Mon, 2013-02-11 at 13:44 +1100, Michael Ellerman wrote:
> > On Wed, Jan 30, 2013 at 01:33:57PM -0500, Peter Hurley wrote:
> > > On Sat, 2013-01-19 at 22:00 +0100, Jiri Slaby wrote:
> > > > On 01/18/2013 10:07 PM,
On Fri, Jan 25, 2013 at 10:16:31AM -0800, David Brown wrote:
> Arnd Bergmann writes:
>
> > msm_smd_probe is a driver probe function and may get
> > called after the __init time, so it must not call
> > any __init function, as the link-time warning reports.
> > Take away the __init annotation on
Commit-ID: b390784dc1649f6e6c5e66e5f53c21e715ccf39b
Gitweb: http://git.kernel.org/tip/b390784dc1649f6e6c5e66e5f53c21e715ccf39b
Author: H. Peter Anvin
AuthorDate: Mon, 11 Feb 2013 16:27:28 -0800
Committer: H. Peter Anvin
CommitDate: Mon, 11 Feb 2013 17:26:51 -0800
x86, mm: Use a
On Mon, Feb 11, 2013 at 05:24:13PM -0800, Andi Kleen wrote:
> On Mon, Feb 11, 2013 at 04:53:26PM -0800, Kent Overstreet wrote:
> > I finally started hacking on the dio code, and it's far from done but
> > it's turning out better than I expected so I thought I'd show off what
> > I've got so far.
>
On Mon, Feb 11, 2013 at 04:53:26PM -0800, Kent Overstreet wrote:
> I finally started hacking on the dio code, and it's far from done but
> it's turning out better than I expected so I thought I'd show off what
> I've got so far.
The critical metric for some of the highend workloads
is the number
Hi,
It looks like the bindings here are still completely unsettled, or at least
unimplemented -- there seems to be a preference for an encoding similar to how
interrupts/gpios/clks work. I think that wouldn't be a bad idea.
For the case of this particular driver and connections, it'd just mean
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/broadcom/bnx2x/bnx2x_cmn.c between commit
0aba93e2b9fb ("bnx2x: set gso_type") from the net tree and commit
cbf1de72324a ("bnx2x: fix GRO parameters") from the net-next tree.
I fixed it up (since the
Sarah Sharp wrote:
> Can you turn on CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING,
> recompile the 3.7.5 kernel, and send me dmesg starting from the point
> you unmount the device and then power it off?
>
> I'd like to keep that patch in stable, but I need to understand what
> exactly is
I finally started hacking on the dio code, and it's far from done but
it's turning out better than I expected so I thought I'd show off what
I've got so far.
The end result is _vastly_ simpler - direct-io.c is now ~700 lines, vs.
~1300 previously. dio_submit is almost gone, I'm down to 4 things
This was suggested by Mark Brown in response to a patch for adding
this functionality only for the s3c2410 bus:
https://lkml.org/lkml/2012/11/20/681
I have also modified the i2c-pxa driver to use this new functionality.
The i2c-pxa driver changes have only been compile-tested and are just
for
On Mon, 2013-02-11 at 20:52 +, Grant Likely wrote:
> Really the irq mappings should be using reference counting. The existing
> code is naive on this count and just releases the irq on the first call
> to irq_dispose_mapping(). I've not gotten around to fixing that. Anyone
> want to take that
Wolfram,
Thanks for the review. New patch was just sent. :)
On Sun, Feb 10, 2013 at 4:19 AM, Wolfram Sang wrote:
>> +static int i2c_get_number_from_dt(struct i2c_adapter *adap)
>
> i2c_get_id_from_dt()?
Done.
>> + if (!dev->of_node)
>> + return -1;
>
> -ESOMETHING?
The commit: "i2c-core: dt: Pick i2c bus number from i2c alias if
present" adds support for automatically picking the bus number based
on the alias ID. Remove the now unnecessary code from i2c-pxa that
did the same thing.
Signed-off-by: Doug Anderson
---
Changes in v3: None
Changes in v2:
- No
This allows you to get the equivalent functionality of
i2c_add_numbered_adapter() with all data in the device tree and no
special case code in your driver. This is a common device tree
technique.
For quick reference, the FDT syntax for using an alias to provide an
ID looks like:
aliases {
it is reported that code hit DMA-API errors on 3.8-rc6+,
(see https://bugzilla.redhat.com/show_bug.cgi?id=908436, and
https://bugzilla.redhat.com/show_bug.cgi?id=908550)
this patch just adds error handler for
pci_map_single and skb_frag_dma_map.
Signed-off-by: xiong
---
On Mon, Feb 11, 2013 at 5:34 PM, Bjorn Helgaas wrote:
> On Mon, Feb 4, 2013 at 1:23 PM, Rafael J. Wysocki wrote:
>> On Monday, February 04, 2013 03:55:47 PM Konstantin Khlebnikov wrote:
>>> This patchset contains some fixes for e1000e diver (broken since v2.6.35)
>>> and some related fixes and
Hi Holger,
Can you turn on CONFIG_USB_DEBUG and CONFIG_USB_XHCI_HCD_DEBUGGING,
recompile the 3.7.5 kernel, and send me dmesg starting from the point
you unmount the device and then power it off?
I'd like to keep that patch in stable, but I need to understand what
exactly is failing with it.
From: Stephen Warren
The intent is to ensure that all Tegra-related patches are sent to the
linux-tegra@ mailing list, so people can keep up-to-date on all misc
driver changes.
Doing this with a keyword is far simpler and more compact than listing
all Tegra-related drivers, even if wildcards
From: Stephen Warren
Allow K: entries in MAINTAINERS to match directly against filenames;
either those extracted from patch +++ or --- lines, or those specified
on the command-line using the -f option.
This potentially allows fewer lines in a MAINTAINERS entry, if all the
relevant files are
On Mon, Feb 4, 2013 at 1:23 PM, Rafael J. Wysocki wrote:
> On Monday, February 04, 2013 03:55:47 PM Konstantin Khlebnikov wrote:
>> This patchset contains some fixes for e1000e diver (broken since v2.6.35)
>> and some related fixes and useful debug for PCI code.
>>
>> All together this fixes my
On Mon, 2013-02-11 at 16:08 +, Arnd Bergmann wrote:
> I tend to disagree. You should never assume that a device is the same
> endianess as the the CPU, and you should try not to use the __raw_*
> accessors in device drivers either.
>
> In particular, ARM can run both big- and little-endian
On Mon, 2013-02-11 at 16:57 +0100, Michal Simek wrote:
> But it reminds me that maybe the easiest solution is not to use endian
> accessors just use two simple macros which should work on all systems.
>
> #define _readreg(offset) ({__raw_readl(offset); rmb(); })
> #define
On Tue, 2013-02-12 at 10:45 +1100, Alexey Kardashevskiy wrote:
> On 12/02/13 09:17, Alex Williamson wrote:
> > On Mon, 2013-02-11 at 22:54 +1100, Alexey Kardashevskiy wrote:
> >> VFIO implements platform independent stuff such as
> >> a PCI driver, BAR access (via read/write on a file descriptor
>
On Mon, 2013-02-11 at 17:08 -0700, Stephen Warren wrote:
> Does "that" above mean "not setting exact_pattern_match_hash", or
> "changing the patch so that it does set exact_pattern_match_hash". Sorry...
I think what you have is fine.
--
To unsubscribe from this list: send the line "unsubscribe
1 - 100 of 1182 matches
Mail list logo
