On Thu, Feb 13, 2014 at 03:54:14PM +, David Howells wrote:
>
> If we're going to be adding a new rename inode op, can we make it take a flag
> to white out the source for union type things? This would mean that
> rename-and-white-out can be done atomically.
That is an option, yes.
On Thu, Feb 13, 2014 at 01:35:41PM +0100, Tomasz Figa wrote:
> On 13.02.2014 13:07, Arend van Spriel wrote:
> >On 02/13/2014 10:13 AM, Tomasz Figa wrote:
> >>The BCM43xx WLAN chips I used to work always have been controlled by a
> >>simple power enable GPIO of the chip itself. Has this changed in
From: "Ivan T. Ivanov"
Qualcomm Universal Peripheral (QUP) core is an AHB slave that
provides a common data path (an output FIFO and an input FIFO)
for serial peripheral interface (SPI) mini-core. SPI in master
mode supports up to 50MHz, up to four chip selects, programmable
data path from 4
From: "Ivan T. Ivanov"
Hi,
Following two patches are adding initial support for SPI controller
available in Qualcomm SoC's.
Controller initialization is based on spi_qsd driver available in
CAF repository.
Controller supports SPI_CPOL | SPI_CPHA | SPI_CS_HIGH | SPI_LOOP modes,
up to 4 CS's
From: "Ivan T. Ivanov"
The Qualcomm Universal Peripheral (QUP) core is an
AHB slave that provides a common data path (an output
FIFO and an input FIFO) for serial peripheral interface
(SPI) mini-core.
Signed-off-by: Ivan T. Ivanov
---
.../devicetree/bindings/spi/qcom,spi-qup.txt | 85
Commit-ID: af0c23df96fbc16089e8eda4b94b7d69b845f81e
Gitweb: http://git.kernel.org/tip/af0c23df96fbc16089e8eda4b94b7d69b845f81e
Author: H. Peter Anvin
AuthorDate: Thu, 13 Feb 2014 07:46:04 -0800
Committer: H. Peter Anvin
CommitDate: Thu, 13 Feb 2014 08:08:58 -0800
x86, smap:
On 02/13/2014 04:27 AM, Laszlo Papp wrote:
On Thu, Feb 13, 2014 at 11:33 AM, Lee Jones wrote:
-static int max6650_probe(struct i2c_client *client,
-const struct i2c_device_id *id);
-static int max6650_init_client(struct i2c_client *client);
-static int max6650_remove(struct
On Wed 12-02-14 16:28:36, Roman Gushchin wrote:
> Hi, Michal!
>
> Sorry for a long reply.
>
> At Wed, 29 Jan 2014 19:22:59 +0100,
> Michal Hocko wrote:
> > > As you can remember, I've proposed to introduce low limits about a year
> > > ago.
> > >
> > > We had a small discussion at that time:
On 02/12/2014 09:41 PM, Weijie Yang wrote:
> We abort direct reclaim if find the zone is ready for compaction.
>
> Sometimes the zone is just a promoted highmem zone to force scan
> pinning highmem, which is not the intended zone the caller want to
> alloc page from. In this situation, setting
Rashika Kheria wrote:
> Remove unused function in afs/write.c.
>
> This eliminates the following warning in afs/write.c:
> fs/afs/write.c:749:5: warning: no previous prototype for ‘afs_page_mkwrite’
> [-Wmissing-prototypes]
>
> Signed-off-by: Rashika Kheria
> Reviewed-by: Josh Triplett
I
Alexander Gordeev writes:
> Signed-off-by: Alexander Gordeev
Thanks, all three patches applied to my ath.git tree.
--
Kalle Valo
--
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
To fix:
arch/sparc/kernel/leon_pci_grpci2.c: In function 'grpci2_of_probe':
arch/sparc/kernel/leon_pci_grpci2.c:720:2: error: implicit declaration of
function 'kzalloc' [-Werror=implicit-function-declaration]
arch/sparc/kernel/leon_pci_grpci2.c:720:20: error: assignment makes pointer
from
On Thu, Feb 13, 2014 at 07:51:56PM +0400, Kirill Tkhai wrote:
> For archs without __ARCH_WANT_UNLOCKED_CTXSW set this means
> that all newly created tasks execute finish_arch_post_lock_switch()
> and post_schedule() with preemption enabled.
That's IA64 and MIPS; do they have a 'good' reason to
On Thu, Feb 13, 2014 at 6:42 PM, Mel Gorman wrote:
> According to the swapon documentation
>
> Swap pages are allocated from areas in priority order,
> highest priority first. For areas with different priorities, a
> higher-priority area is exhausted before using a
Hi Greg,
On 11/02/14 00:13, Greg Kroah-Hartman wrote:
> On Mon, Feb 10, 2014 at 06:09:58PM +, Sudeep Holla wrote:
>> On 07/02/14 19:29, Greg Kroah-Hartman wrote:
>>> On Fri, Feb 07, 2014 at 04:49:16PM +, Sudeep Holla wrote:
From: Sudeep Holla
This patch adds initial
Commit-ID: 03bbd596ac04fef47ce93a730b8f086d797c3021
Gitweb: http://git.kernel.org/tip/03bbd596ac04fef47ce93a730b8f086d797c3021
Author: H. Peter Anvin
AuthorDate: Thu, 13 Feb 2014 07:34:30 -0800
Committer: H. Peter Anvin
CommitDate: Thu, 13 Feb 2014 07:50:25 -0800
x86, smap: Don't
Commit-ID: f27d7759ad1ff48673831e598d6df4c76b2bcd06
Gitweb: http://git.kernel.org/tip/f27d7759ad1ff48673831e598d6df4c76b2bcd06
Author: H. Peter Anvin
AuthorDate: Thu, 13 Feb 2014 07:46:04 -0800
Committer: H. Peter Anvin
CommitDate: Thu, 13 Feb 2014 07:50:45 -0800
x86, smap:
If we're going to be adding a new rename inode op, can we make it take a flag
to white out the source for union type things? This would mean that
rename-and-white-out can be done atomically.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Hi Linus,
Second round of updates and fixes for 3.14-rc2. Most of this stuff has
been queued up for a while. The notable exception is the blk-mq changes,
which are naturally a bit more in flux still.
The pull request contains:
- Two bug fixes for the new immutable vecs, causing crashes with
On Thu, 2014-02-13 at 08:19 +0100, Michal Simek wrote:
> On 02/13/2014 01:31 AM, Joe Perches wrote:
> > On Wed, 2014-02-12 at 16:55 +0100, Michal Simek wrote:
Hi again Michal.
> >> + netdev_warn(lp->ndev,
> >> + "Could not find clock ethernet controller property.");
>
On 02/13/2014 06:55 AM, H. Peter Anvin wrote:
> On 02/13/2014 04:45 AM, Fengguang Wu wrote:
>> Greetings,
>>
>> I find that when running
>>
>> qemu-system-x86_64 -cpu qemu64,+smep,+smap
>>
>> Some kernels will 100% produce this error, where the error code
>> -13,-14 are -EACCES and
Preemption state on enter in finish_task_switch() is different
in cases of context_switch() and schedule_tail().
In the first case we have it twice disabled: at the start of
schedule() and during spin locking. In the second it is only
once: the value which was set in init_task_preempt_count().
On 03/02/14 07:56, Suresh Siddha wrote:
> Here is the second patch, which should fix the issue reported in this
> thread. Maarten, Nate, George, please give this patch a try as is and
> see if it helps address the issue you ran into.
I can confirm that your patch fixes the bug I reported (core
On 02/13/2014 06:55 AM, H. Peter Anvin wrote:
> On 02/13/2014 04:45 AM, Fengguang Wu wrote:
>> Greetings,
>>
>> I find that when running
>>
>> qemu-system-x86_64 -cpu qemu64,+smep,+smap
>>
>> Some kernels will 100% produce this error, where the error code
>> -13,-14 are -EACCES and
On Wed, Feb 12, 2014 at 5:47 AM, David Herrmann wrote:
> Hi
>
> On Mon, Feb 10, 2014 at 6:58 PM, Benjamin Tissoires
> wrote:
>> We can not directly change the underlying struct hid_ll_driver here
>> as we did for hdev->hid_output_raw_report.
>> So allocate a struct ll_driver, and replace the old
On Thu, 13 Feb 2014 10:36:35 -0500
f...@redhat.com (Frank Ch. Eigler) wrote:
>
> rostedt wrote:
>
> > [...]
> > Oh! You are saying that if the kernel only *supports* signed modules,
> > and you load a module that is not signed, it will taint the kernel?
>
> Yes: this is the default for several
- Original Message -
> From: "Steven Rostedt"
> To: "Mathieu Desnoyers"
> Cc: "Ingo Molnar" , linux-kernel@vger.kernel.org, "Ingo
> Molnar" , "Thomas
> Gleixner" , "Rusty Russell" ,
> "David Howells" ,
> "Greg Kroah-Hartman"
> Sent: Thursday, February 13, 2014 10:28:17 AM
> Subject:
On Wed, Feb 12, 2014 at 5:35 AM, David Herrmann wrote:
> Hi
>
> On Mon, Feb 10, 2014 at 6:58 PM, Benjamin Tissoires
> wrote:
>> hid_output_raw_report() is not a ll_driver callback and should not be used.
>> To keep the same code path than before, we are forced to play with the
>> different
rostedt wrote:
> [...]
> Oh! You are saying that if the kernel only *supports* signed modules,
> and you load a module that is not signed, it will taint the kernel?
Yes: this is the default for several distros.
- FChE
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
On Thursday 13 February 2014, Gene Heskett wrote:
>On Wednesday 12 February 2014, Randy Dunlap wrote:
>>On 02/12/2014 11:08 AM, Gene Heskett wrote:
>>> Greetings, not making any progress on newer kernel builds yet.
>>>
>>> So I unpacked 3.13.2 this morning and copied its
>>>
From: Heiko Stuebner
Commit 934624d6e9f0 ("regulator: gpio-regulator: do not open-code counting
and access of dt array elements") forgot to convert the recently added
gpios-states property using the same pattern.
Convert this instance to use the of-helpers too, resolving the build error.
Hello,
On Thu, Feb 13, 2014 at 04:27:45PM +0100, Michal Hocko wrote:
> > Further testing showed that an ordered workqueue for cgroup_destroy_wq
> > is not always good enough: percpu_ref_kill_and_confirm's call_rcu_sched
> > stage on the way can mess up the order before reaching the workqueue.
>
2014-01-08 22:36 GMT+01:00 Pali Rohár :
> On Monday 30 December 2013 15:52:51 Sebastian Reichel wrote:
>> > > > +MODULE_DESCRIPTION("Bluetooth h4 driver with nokia
>> > > > extensions"); +MODULE_LICENSE("GPL");
>> > > > +MODULE_AUTHOR("Ville Tervo");
>> > > >
On Thu, 13 Feb 2014 15:10:14 + (UTC)
Mathieu Desnoyers wrote:
> - Original Message -
> > From: "Steven Rostedt"
> > To: "Ingo Molnar"
> > Cc: "Mathieu Desnoyers" ,
> > linux-kernel@vger.kernel.org, "Ingo Molnar"
> > , "Thomas Gleixner" , "Rusty Russell"
> > , "David Howells"
> >
On Wed 12-02-14 15:03:31, Hugh Dickins wrote:
> From: Filipe Brandenburger
>
> Sometimes the cleanup after memcg hierarchy testing gets stuck in
> mem_cgroup_reparent_charges(), unable to bring non-kmem usage down to 0.
>
> There may turn out to be several causes, but a major cause is this: the
On Thu, 13 Feb 2014 15:26:42 +0100
Frederic Weisbecker wrote:
> > Is this worth doing?
>
> It sounds worth yeah. I've run into this situation multiple times where I had
Is it?
> to pass 0 instead of nothing on a tracepoint.
What tracepoints?
The problem I have with a tracepoint that does
> I dare say either your bisect went sour or you don't have 945GM. Please
> verify your steps.
Well, what can I say? I was careful when testing and the last kernel I compiled
shows the problem. I can replay the bisection if needed but if I have to start
all over again it's gonna take some time.
On Thu, 13 Feb 2014, Luis Ortega wrote:
> Hi, testing 3.14-rc2 I noticed I could not adjust the brightness of the
> screen any longer. This problem is already present in 3.14-rc1. 3.13 works
> fine.
>
> My hardware is a netbook with intel atom and a 945GM graphics card.
>
> I bisected the
On Wed, Feb 12, 2014 at 5:25 AM, David Herrmann wrote:
> Hi
>
> On Mon, Feb 10, 2014 at 6:58 PM, Benjamin Tissoires
> wrote:
>> .request() can be emulated through .raw_request()
>> we can implement this emulation in hid-core, and make .request
>> not mandatory for transport layer drivers.
>>
>>
Hello
Can you send us your full Product catalog, we want to buy and ship to Doha,
Qatar.
waiting
for your response
Jermaine Shannon
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
On 02/13/2014 04:45 AM, Fengguang Wu wrote:
> Greetings,
>
> I find that when running
>
> qemu-system-x86_64 -cpu qemu64,+smep,+smap
>
> Some kernels will 100% produce this error, where the error code
> -13,-14 are -EACCES and -EFAULT:
>
> Any ideas?
>
I notice this is a non-SMAP
On Wed, Feb 12, 2014 at 5:49 AM, David Herrmann wrote:
> Hi
>
> On Mon, Feb 10, 2014 at 6:58 PM, Benjamin Tissoires
> wrote:
>> Remove hid_output_raw_report() call as it is not a ll_driver callbacj,
>> and switch to the hid_hw_* implementation. USB-HID used to fallback
>> into SET_REPORT when
On Wed, Feb 12, 2014 at 5:30 AM, David Herrmann wrote:
> Hi
>
> On Mon, Feb 10, 2014 at 6:58 PM, Benjamin Tissoires
> wrote:
>> Having our own .request() implementation does not give anything,
>> so use the generic binding.
>>
>> Signed-off-by: Benjamin Tissoires
>> ---
>>
Hi David,
On Wed, Feb 12, 2014 at 5:13 AM, David Herrmann wrote:
> Hi
>
> On Wed, Feb 5, 2014 at 10:33 PM, Benjamin Tissoires
> wrote:
>> Hi guys,
>>
>> well, here comes the promised v2 of the ll_transport cleanup.
>>
>> As I said, I removed patches which need some more work, and kept only the
- Original Message -
> From: "Steven Rostedt"
> To: "Ingo Molnar"
> Cc: "Mathieu Desnoyers" ,
> linux-kernel@vger.kernel.org, "Ingo Molnar"
> , "Thomas Gleixner" , "Rusty Russell"
> , "David Howells"
> , "Greg Kroah-Hartman"
> Sent: Tuesday, February 11, 2014 11:45:34 PM
> Subject:
On Wednesday 12 February 2014, Randy Dunlap wrote:
>On 02/12/2014 11:08 AM, Gene Heskett wrote:
>> Greetings, not making any progress on newer kernel builds yet.
>>
>> So I unpacked 3.13.2 this morning and copied its
>> arch/x86/i386_defconfig to .config.
>>
>> Ran make oldconfig, then 3 or 4
> -Original Message-
> From: Jason Wang [mailto:jasow...@redhat.com]
> Sent: Wednesday, February 12, 2014 10:52 PM
> To: Haiyang Zhang; da...@davemloft.net; net...@vger.kernel.org
> Cc: KY Srinivasan; o...@aepfle.de; linux-kernel@vger.kernel.org; driverdev-
> de...@linuxdriverproject.org
On Wed, Feb 12, 2014 at 05:40:12PM -0800, Andy Lutomirski wrote:
> This is a strawman proposal to simplify the idle implementation, eliminate
> a race
>
> Benefits over current code:
> - ttwu_queue_remote doesn't use an IPI unless needed
> - The diffstat should speak for itself :)
> - Less
On Thu, 2014-02-13 at 11:17 +, Matt Fleming wrote:
> On Wed, 05 Feb, at 05:03:54PM, Leif Lindholm wrote:
> > From: Mark Salter
> >
> > ARM and ARM64 architectures use the device tree to pass UEFI parameters
> > from stub to kernel. These parameters are things known to the stub but
> > not
Hi,
On 13.02.2014 10:14, Krzysztof Kozlowski wrote:
Add bindings documentation for S2MPS14 device to the s2mps11 driver.
Signed-off-by: Krzysztof Kozlowski
Cc: Mark Brown
Cc: Liam Girdwood
Cc: Tomasz Figa
Cc: devicet...@vger.kernel.org
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc:
On Wed 12-02-14 17:29:09, Hugh Dickins wrote:
> Commit d8ad30559715 ("mm/memcg: iteration skip memcgs not yet fully
> initialized") is not bad, but Greg Thelen asks "Are barriers needed?"
>
> Yes, I'm afraid so: this makes it a little heavier than the original,
> but there's no point in
2014-02-13 2:40 GMT+01:00 Andy Lutomirski :
> This is a strawman proposal to simplify the idle implementation, eliminate
> a race
Please describe the race in question.
>
> Benefits over current code:
> - ttwu_queue_remote doesn't use an IPI unless needed
> - The diffstat should speak for
From: "Ivan T. Ivanov"
SPI transfer lenght should be a power-of-two multiple
of eight bits.
Signed-off-by: Ivan T. Ivanov
---
drivers/spi/spi.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index 23756b0..474c0b0 100644
---
The driver is currently limited to a single periodic output. This patch makes
the number of peridodic output dynamic by dropping the gpio_tab module
parameter and adding calibrate_pin, perout_pins, and extts_pins parameters.
Signed-off-by: Stefan Sørensen
---
drivers/net/phy/dp83640.c | 73
This patch series add DT configuration to the DP83640 PHY driver and makes
the configuration of periodic output pins dynamic.
Changes since v2:
- Add patch to properly configure perout triggers 0+1
- Keep extts and perout numbers separate
- Shorten pr_err lines
Changes since v1:
- Add
This patch adds configuration of the periodic output and external timestamp
pins available on the dp83640 family of PHYs. It also configures the
master/slave relationship in a group of PHYs on the same MDIO bus and the pins
used for clock calibration in the group.
The configuration is retrieved
Periodic output triggers 0 and 1 of the dp83640 has a programmable
duty-cycle which is controlled by the Pulsewidth2 field of the trigger
data register. This field is not documented in the datasheet, but it
is described in the "PHYTER Software Development Guide" section
3.1.4.1. Failing to set
This patch adds configuration of the periodic output and external timestamp
pins available on the dp83640 family of PHYs. It also configures the
master/slave relationship in a group of PHYs on the same MDIO bus and the pins
used for clock calibration in the group.
The configuration is retrieved
This patch series add DT configuration to the DP83640 PHY driver and makes
the configuration of periodic output pins dynamic.
Changes since v2:
- Add patch to properly configure perout triggers 0+1
- Keep extts and perout numbers separate
- Shorten pr_err lines
Changes since v1:
- Add
The driver is currently limited to a single periodic output. This patch makes
the number of peridodic output dynamic by dropping the gpio_tab module
parameter and adding calibrate_pin, perout_pins, and extts_pins parameters.
Signed-off-by: Stefan Sørensen
---
drivers/net/phy/dp83640.c | 73
Periodic output triggers 0 and 1 of the dp83640 has a programmable
duty-cycle which is controlled by the Pulsewidth2 field of the trigger
data register. This field is not documented in the datasheet, but it
is described in the "PHYTER Software Development Guide" section
3.1.4.1. Failing to set
Hi, testing 3.14-rc2 I noticed I could not adjust the brightness of the
screen any longer. This problem is already present in 3.14-rc1. 3.13 works fine.
My hardware is a netbook with intel atom and a 945GM graphics card.
I bisected the problem down to the next commit:
On Tue, Feb 11, 2014 at 02:22:43PM +0530, Viresh Kumar wrote:
> On 28 January 2014 18:53, Frederic Weisbecker wrote:
> > No, when a single task is running on a full dynticks CPU, the tick is
> > supposed to run
> > every seconds. I'm actually suprised it doesn't happen in your traces, did
> >
On Fri, Feb 07, 2014 at 11:23:57AM -0500, Steven Rostedt wrote:
> A while back ago, Wolfgang (and others) have asked about the ability to
> add a trace event that recorder no data other than the fact that the
> trace event was hit.
>
> I've been reluctant to do so, but I noticed that one already
On Tue, 2014-02-11 at 21:19 +0100, Richard Cochran wrote:
> > +- dp83640,slave: If present, this phy will be slave to another dp83640
> > + on the same mdio bus.
>
> Wouldn't it be more natural to have one "dp83640,master" property
> rather than multiple slave properties?
I wanted to keep the
On Tue, 2014-02-11 at 21:09 +0100, Richard Cochran wrote:
> > -#define EXT_EVENT 1
>
> Regarding this EXT_EVENT thing ...
>
> > @@ -430,12 +419,12 @@ static int ptp_dp83640_enable(struct ptp_clock_info
> > *ptp,
> > switch (rq->type) {
> > case PTP_CLK_REQ_EXTTS:
> > index
On Wed 12-02-14 17:26:46, Hugh Dickins wrote:
> Commit 0eef615665ed ("memcg: fix css reference leak and endless loop in
> mem_cgroup_iter") got the interaction with the commit a few before it
> d8ad30559715 ("mm/memcg: iteration skip memcgs not yet fully initialized")
> slightly wrong, and we
The new functions are special cases for pci_enable_msi_range() and
pci_enable_msix_range() when a particular number of MSI or MSI-X
is needed.
By contrast with pci_enable_msi_range() and pci_enable_msix_range()
functions, pci_enable_msi_exact() and pci_enable_msix_exact()
return zero in case of
On Thursday 13 February 2014 07:17 PM, Heiko Schocher wrote:
> commit:
> From 0cd8f9cc0654c06adde353c6532114c5f53a18e8 Mon Sep 17 00:00:00 2001
> From: Mugunthan V N
> Date: Thu, 23 Jan 2014 00:03:12 +0530
> Subject: [PATCH] drivers: net: cpsw: enable promiscuous mode support
>
> Enable
On 10 February 2014 11:14, Ulf Hansson wrote:
> On 5 February 2014 15:34, Linus Walleij wrote:
>> On Tue, Feb 4, 2014 at 4:58 PM, Ulf Hansson wrote:
>>
>>> Since the device is active while a successful probe has been completed,
>>> the reference counting for the clock will be screwed up and
Use devm_* functions to simplify code and error handling.
Cc: Alessandro Rubini
Cc: Linus Walleij
Cc: Wolfram Sang
Signed-off-by: Ulf Hansson
---
Changes in v2:
Rebased on top of latest i2c-nomadik branch.
---
drivers/i2c/busses/i2c-nomadik.c | 29 +
1
On Wed, 12 Feb 2014, Vince Weaver wrote:
> On Tue, 11 Feb 2014, Peter Zijlstra wrote:
> >
> > I'll see if I can run through the reproduction case by hand.
>
> I've come up with an even simpler test case with all of the extraneous
> settings removed. Included below.
>
> It is triggered in
The amba bus are responsible for pm_runtime_enable|disable, remove the
redundant pm_runtime_disable at driver removal.
Cc: Alessandro Rubini
Cc: Linus Walleij
Cc: Wolfram Sang
Signed-off-by: Ulf Hansson
---
Changes in v2:
Rebased on top of latest i2c-nomadik branch.
---
For !CONFIG_PM_RUNTIME, the device were never put back into active
state while resuming.
For CONFIG_PM_RUNTIME, we blindly trusted the device to be inactive
while we were about to handle it at suspend late, which is just too
optimistic.
Even if the driver uses pm_runtime_put_sync() after each
Since the runtime PM state is expected to be active according to the
amba bus, we must align our behaviour while probing to it.
Moreover, this is needed to be able to have the driver fully functional
without depending on CONFIG_RUNTIME_PM.
Since the device is active while a successful probe has
We should never be busy performing transfers at suspend late, thus
there are no reason to check for it.
Cc: Alessandro Rubini
Cc: Linus Walleij
Cc: Wolfram Sang
Signed-off-by: Ulf Hansson
---
Changes in v2:
Rebased on top of latest i2c-nomadik branch.
---
At system suspend_late, runtime PM has been disabled by the PM core
which means we can safely operate on these resources. Consequentially
we no longer have to wait until the noirq phase of the system suspend.
Cc: Alessandro Rubini
Cc: Linus Walleij
Cc: Wolfram Sang
Signed-off-by: Ulf Hansson
On Wed, Feb 12, 2014 at 04:33:11PM -0800, Paul E. McKenney wrote:
>
> Fair point! I wordsmithed it into the following. Seem reasonable?
>
> Thanx, Paul
>
>
>
>
On 02/13/2014 02:31 AM, Matt Fleming wrote:
> On Wed, 12 Feb, at 03:31:05PM, H. Peter Anvin wrote:
>>
>> The real answer IMO ought to be that since arch/x86/boot/string.c is now
>> used separately from boot.h (eboot.c which includes efi-stub-helper.c
>> does *not* include boot.h) we may have to
On 02/13/2014 02:47 AM, Ulf Hansson wrote:
On 12 February 2014 22:21, Shuah Khan wrote:
Change cb710-mmc platform driver to register pm ops using dev_pm_ops instead
of legacy pm_ops. The existing legacy suspend/resume routines are identical
and simply clear IRQ mask in the device in case it
commit:
>From 0cd8f9cc0654c06adde353c6532114c5f53a18e8 Mon Sep 17 00:00:00 2001
From: Mugunthan V N
Date: Thu, 23 Jan 2014 00:03:12 +0530
Subject: [PATCH] drivers: net: cpsw: enable promiscuous mode support
Enable promiscuous mode support for CPSW.
Introduced a crash on an am335x based board
In panel_probe() the backlight node is never found, correct this.
Signed-off-by: Heiko Schocher
Cc: Anatolij Gustschin
Cc: Benoit Parrot
Cc: Rob Clark
Cc: David Airlie
Cc: Grant Likely
Cc: Rob Herring
Cc: Tomi Valkeinen
Cc: Sachin Kamat
Cc: dri-de...@lists.freedesktop.org
Cc:
It's the current Arch Linux GCC package:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/gcc/src/gcc-4.8-20140206/configure
--prefix=/usr --libdir=/usr/lib
m...@console-pimps.org writes:
> On Wed, 12 Feb, at 09:15:03AM, Toshi Kani wrote:
>>
>> Hi Matt,
>>
>> Yes, I agree that the table size should be 0x38. However, ACPI spec
>> states that bit0 of status indicates if the boot image graphic is valid.
>> This bit is set to 0 (invalid) on the
On Thu, Feb 13, 2014 at 12:57 PM, Jean Delvare wrote:
> Hi Laszlo,
>
> On Thu, 13 Feb 2014 12:27:28 +, Laszlo Papp wrote:
>> On Thu, Feb 13, 2014 at 11:33 AM, Lee Jones wrote:
>> > Right, I've had enough. I'm removing your patch from the MFD tree.
>> >
>> > I've asked too many people to give
> wrote:
>
> > The DBx500 and ABx500 should be getting their IRQs from the
> > device tree and nowhere else. Get rid of all the static assignments
> > everywhere, delete it from the driver, platform data and the
> > board files in one swift strike.
> >
> > Lots of cross-dependencies in the MFD
On Wed, Feb 12, 2014 at 11:30:44PM +0200, Kalle Valo wrote:
> Bjorn Helgaas writes:
>
> >> Well, as this series is small I thought it could quickly go thru your
> >> tree. But since ipr had conflicts, there is no point routing all patches
> >> altogether, so up to you guys. The wil6210 patch is
On Thu, Feb 13, 2014 at 2:02 PM, Jiri Olsa wrote:
> On Tue, Feb 11, 2014 at 08:50:13AM -0300, Arnaldo Carvalho de Melo wrote:
>> Em Tue, Feb 11, 2014 at 12:14:21PM +0100, Peter Zijlstra escreveu:
>> > On Tue, Feb 11, 2014 at 12:08:56PM +0100, Stephane Eranian wrote:
>> > > Assuming you can decode
On Tue, Feb 11, 2014 at 11:29 AM, Linus Walleij
wrote:
> The DBx500 and ABx500 should be getting their IRQs from the
> device tree and nowhere else. Get rid of all the static assignments
> everywhere, delete it from the driver, platform data and the
> board files in one swift strike.
>
> Lots of
On Thu, 2014-02-13 at 13:08 +, Linus Walleij wrote:
> On Tue, Feb 11, 2014 at 6:10 PM, Pawel Moll wrote:
>
> > ... so debugfs interfaces are easier to use.
> >
> > Cc: Linus Walleij
> > Cc: Alexandre Courbot
> > Cc: Samuel Ortiz
> > Cc: Lee Jones
> > Signed-off-by: Pawel Moll
>
> This
On Tue, Feb 11, 2014 at 6:10 PM, Pawel Moll wrote:
> ... so debugfs interfaces are easier to use.
>
> Cc: Linus Walleij
> Cc: Alexandre Courbot
> Cc: Samuel Ortiz
> Cc: Lee Jones
> Signed-off-by: Pawel Moll
This doesn't apply to the v3.14-rc1-based GPIO tree. Can you rebase it
with Lee's
On Wed, 12 Feb 2014, dl...@gmx.de wrote:
> From: Behan Webster
> The only real change is passing in event_mask to the formerly nested
> functions.
> Otherwise it's just moving around function and macro code.
>
> This is the only place in the Linux kernel where nested functions are still in
>
Hello,
The Project is about the exportation of 100,000 barrels of Light CrudeOil daily
out from Iraq to Turkey through my client's company in Iraq
at the rate of $92.00 a barrel. This amount to $9,200,000 daily. I ask for your
support as a foreigner to handle this business project with my
On Tue, Feb 11, 2014 at 08:50:13AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Feb 11, 2014 at 12:14:21PM +0100, Peter Zijlstra escreveu:
> > On Tue, Feb 11, 2014 at 12:08:56PM +0100, Stephane Eranian wrote:
> > > Assuming you can decode and get the info about the base registers used,
> > >
Can't suspend to ram/disk on the Lenovo X240 with Intel i7-4600.
kernel 3.14.0-rc2
The same kernel works find on Lenovo X230 with Intel i7-3520M.
Here's the trace ..
[] ? do_exit+0x852/0x89d
[] ? prinfk+0x4f/0x54
[] ? oops_end+0x78/0x7d
[] ? no_context+0x1e6/0x1f5
[] ?
On Thu, 2014-02-13 at 12:43 +, Lee Jones wrote:
> > S2MPS11/S2MPS14 regulators support different modes of operation:
> > - Always off;
> > - On/Off controlled by pin/GPIO (PWREN/LDOEN/EMMCEN);
> > - Always on;
> > This is very similar to S5M8767 regulator driver which also supports
> >
From: Martin Walch
Date: Thu, 13 Feb 2014 02:13:01 +0100
Subject: [PATCH 1/2] kconfig: completely remove expr_eliminate_dups2() and
related code
this removes expr_eliminate_dups2(), expr_extract_eq_and(),
expr_extract_eq_or(), and expr_extract_eq() from scripts/kconfig/expr.[ch]
As the
Hi Laszlo,
On Thu, 13 Feb 2014 12:27:28 +, Laszlo Papp wrote:
> On Thu, Feb 13, 2014 at 11:33 AM, Lee Jones wrote:
> > Right, I've had enough. I'm removing your patch from the MFD tree.
> >
> > I've asked too many people to give you a second chance and asked you
> > privately to behave
From: Martin Walch
Date: Thu, 13 Feb 2014 12:22:18 +0100
Subject: [PATCH 0/2] kconfig: Remove bad inference rules expr_eliminate_dups2()
PATCH 1: Removes expr_eliminate_dups2() and other related code.
This does not seem to actually affect the behaviour when using Kconfig files
from the mainline
From: Martin Walch
Date: Thu, 13 Feb 2014 12:17:06 +0100
Subject: [PATCH 2/2] kconfig: trivial - adjust comments
the line
(a='b') && (a!='c') -> 'b'='c' ? 'n' : a='b'
is probably copy & paste from above, missing the adjustment done in the code.
It should probably read
(a!='b') && (a='c') ->
501 - 600 of 1502 matches
Mail list logo
