* Linus Torvalds wrote:
> On Fri, Dec 12, 2014 at 11:58 AM, David Lang wrote:
> >
> > If the machine has NOHZ and has a cpu bound userspace task,
> > it could take quite a while before userspace would trigger a
> > reschedule (at least if I've understood the comments on this
> > thread
* Linus Torvalds wrote:
> I'm also not sure if the bug ever happens with preemption
> disabled. Sasha, was that you who reported that you cannot
> reproduce it without preemption? It strikes me that there's a
> race condition in __cond_resched() wrt preemption, for example:
> we do
>
>
hi,
On Saturday 13 December 2014 05:49 AM, Doug Anderson wrote:
> Yunzhi,
>
> On Fri, Dec 12, 2014 at 7:07 AM, Yunzhi Li wrote:
>> This patch to add a generic PHY driver for ROCKCHIP usb PHYs,
>> currently this driver can support RK3288. The RK3288 SoC have
>> three independent USB PHY IPs
On 12/12/14, 1:19 AM, Varlese, Marco wrote:
-Original Message-
From: Roopa Prabhu [mailto:ro...@cumulusnetworks.com]
Sent: Thursday, December 11, 2014 5:41 PM
To: Jiri Pirko
Cc: Varlese, Marco; John Fastabend; net...@vger.kernel.org;
step...@networkplumber.org; Fastabend, John R;
If I understand it correctly, the whole idea indeed is very simple,
the consumer/provider and circular buffer model. use SSD as a circular
write buffer, write flush thread stores incoming writes to this buffer
sequentially as provider, and writeback thread write those data logs
sequentially into
On Fri, 2014-12-12 at 23:58 +0100, Krzysztof Konopko wrote:
> This patch changes the types of the struct fields involved to be
> little-endian which is what is received over the air and consistent with
> relevant structs in include/linux/ieee80211.h.
[]
> diff --git
> I'd like to honestly ask why you are being so difficult?
There are several factors which contribute to your perception of
difficulty here.
1. I try to extract from every feedback the information about the amount
of acceptance or rejection for a specific update suggestion.
A terse feedback
> We are in the merge window, tracking bugs added in latest dev cycle.
I am also curious on the software evolution about how many improvements will
arrive in the next Linux versions.
> Having to deal with patches like yours is adding pressure
> on the maintainer (and other developers) at the
Add the kernel command line tracepoint_printk option that will
have tracepoints that are active sent to printk().
Passing "tracepoint_printk" will activate this. To turn it off
the sysctl /proc/sys/kernel/tracepoint_printk can have '0' echoed
into it. Note, this only works if the cmdline option
Enabling tracepoints at boot up can be very useful. The tracepoint
can be initialized right after memory has been. There's no need to
wait for the early_initcall() to be called. That's too late for some
things that can use tracepoints for debugging. Move the logic to
enable tracepoints out of the
On Fri, 12 Dec 2014 18:14:20 -0500
Steven Rostedt wrote:
> On Fri, 12 Dec 2014 21:35:14 +0100 (CET)
> Thomas Gleixner wrote:
>
>
> > We're almost there with x86 but my gut feeling tells me that pushing
> > it now is too risky. I rather prefer quiet holidays for all of us than
> > the nagging
Your e-mail account needs to be improved, with our new F-Secure ?HTK4S
anti-virus/anti-spam
2015-version. Due to increase in Account Hacking.
Fill in the columns below and send to Us or your account will be temporarily
excluded from our services.
E-mail:
User name:
Password:
Department:
*
Hi Felipe,
In DWC3 driver, for three stage Control OUT transfer there is a check:
else if (!IS_ALIGNED(req->request.length, dep->endpoint.maxpacket)
&& (dep->number == 0)) {.
}
I understand that we check for alignment of sizes and if not we
prepare trb with maxpacket and
On Dec 13 2014 04:28, Dan Carpenter wrote:
> This code causes a static checker warning:
>
> sound/firewire/oxfw/oxfw.c:46 detect_loud_models()
> warn: signedness bug returning '(-2)'
>
> The detect_loud_models() function should return false on falure, so that
> we don't try to set up
Linus,
This code is a fork from the trace-3.19 pull as it needed the trace_seq
clean ups from that branch.
This code solves the issue of performing stack dumps from NMI context.
The issue is that printk() is not safe from NMI context as if the NMI
were to trigger when a printk() was being
From: "Steven Rostedt (Red Hat)"
When recording the state of a task for the sched_switch tracepoint a check of
task_preempt_count() is performed to see if PREEMPT_ACTIVE is set. This is
because, technically, a task being preempted is really in the TASK_RUNNING
state, and that is what should be
From: "Steven Rostedt (Red Hat)"
The parameters for prepare_ftrace_return() used by the function graph
tracer were swapped to simplify the code on x86_64. But i386 function
graph trampoline also calls this function, and it did not have its
parameters swapped.
Link:
Linus,
Here's two fixes:
1) Discovered by Fengguang Wu's tests. I changed the parameters to
the function graph x86 prepare_ftrace_return() call but forgot
to update the call from entry_32 (i386 version). This patch corrects
that.
2) I was tracing some code and found that the
Hi Andrew,
On Fri, 12 Dec 2014 14:56:23 -0800 Andrew Morton
wrote:
>
> How'd that happen?
> http://ozlabs.org/~akpm/mmots/broken-out/init-remove-config_init_fallback.patch
> removes all mention of CONFIG_INIT_FALLBACK?
Well, the patch now in Linus's tree adds the INIT_FALLBACK bit to the
On 12/11/2014 09:20 PM, Huang Ying wrote:
> FYI, we noticed the below changes on
>
> git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
> commit 2ed09fc090fc0488e2ab27604a141679fe2ef610 ("ipmi: clean up the device
> handling for the bmc device")
Thanks. The surprising
On 12/12/2014 04:50 PM, Krzysztof Konopko wrote:
On 12/12/14 18:35, Larry Finger wrote:
On 12/12/2014 05:35 AM, Krzysztof Konopko wrote:
On 12/12/14 00:53, Larry Finger wrote:
In particular, did you test on big-endian hardware after you
made this change?
Nope. I don't have any big-endian
Hi Linus,
This is the pull request for the core block IO changes for 3.19. Not a
huge round this time, mostly lots of little good fixes. The pull request
contains:
- Fix a bug in sysfs blktrace interface causing a NULL pointer
dereference, when enabled/disabled through that API. From Arianna
Hi Rafael,
On Wed, Sep 03, 2014 at 04:55:35PM -0700, Brian Norris wrote:
> When CONFIG_PM_DEBUG=y, we provide a sysfs file (/sys/power/pm_test) for
> selecting one of a few suspend test modes, where rather than entering a
> full suspend state, the kernel will perform some subset of suspend
>
On Fri, Dec 12, 2014 at 04:23:16PM -0800, Linus Torvalds wrote:
> On Fri, Dec 12, 2014 at 3:54 PM, Sasha Levin wrote:
> >
> > I ran bisection on trinity, rather than the kernel, and got the following
> > result:
>
> Heh. That commit is pretty small, but I guess the effect of having a
>
Hi,
On Fri, Dec 12, 2014 at 10:50 PM, Matthias Brugger
wrote:
> This patch adds a driver for the Mediatek SoC integrated
> watchdog. This driver supports watchdog and software reset
> for mt65xx and mt81xx SoCs.
>
> Signed-off-by: Matthias Brugger
> ---
> drivers/watchdog/Kconfig | 10 ++
>
Hi,
On Sat, Dec 13, 2014 at 2:25 AM, VishnuPatekar
wrote:
> 1. Please note that ps20 pins conflict with HDMI on Lime2 Board
> so, by deault ps20 and ps21 are disabled for Lime2 Board.
> There is no on board ps2 connector and these pins can be used
> for different purpose.
>
> Signed-off-by:
Signed-off-by: Silvio Fricke
CC: Thomas Gleixner
CC: Jason Cooper
CC: Marc Zyngier
---
arch/arm/boot/dts/tegra30-apalis.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/tegra30-apalis.dtsi
b/arch/arm/boot/dts/tegra30-apalis.dtsi
index a5446cb..c2a7528 100644
---
Hi,
I have found some dts entries which are not evaluated by the drivers. This
patch remove this entries from the dts files.
Jason has mentioned I should CC: Thomas, Marc and him self to this mails.
thanks and best regards,
Silvio
Silvio Fricke (3):
ARM: mx5: dts: remove unused irq-trigger
Signed-off-by: Silvio Fricke
CC: Thomas Gleixner
CC: Jason Cooper
CC: Marc Zyngier
---
arch/arm/boot/dts/spear1310-evb.dts | 1 -
arch/arm/boot/dts/spear1340-evb.dts | 2 --
arch/arm/boot/dts/spear320-hmi.dts | 3 ---
3 files changed, 6 deletions(-)
diff --git
Signed-off-by: Silvio Fricke
CC: Thomas Gleixner
CC: Jason Cooper
CC: Marc Zyngier
---
arch/arm/boot/dts/imx53-m53.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/imx53-m53.dtsi b/arch/arm/boot/dts/imx53-m53.dtsi
index 87a7fc7..8a5acb5 100644
---
On Fri, Dec 12, 2014 at 4:23 PM, Dave Hansen wrote:
> On 12/12/2014 04:11 PM, Andy Lutomirski wrote:
>> On Fri, Dec 12, 2014 at 3:16 PM, Dave Hansen wrote:
>>> On 12/12/2014 03:04 PM, Andy Lutomirski wrote:
Anyway, do your patches handle the case where a 32-bit app maliciously
executes
On Sat, 2014-12-13 at 02:34 +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
> selected) PM_RUNTIME is always set if PM is set, so files that are
> build conditionally if CONFIG_PM_RUNTIME is set may now be build
From: Rafael J. Wysocki
After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME within #ifdef blocks depending on
CONFIG_PM may be dropped now.
Do that in
From: Rafael J. Wysocki
Subject: NFC / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.
From: Rafael J. Wysocki
After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so files that are
build conditionally if CONFIG_PM_RUNTIME is set may now be build
if CONFIG_PM is set.
Replace CONFIG_PM_RUNTIME with CONFIG_PM in
The array tps_comparators starts at zero,
yet COMP1 starts at 1. So COMP2 is out of bounds.
cppcheck reported:
[drivers/mfd/tps65911-comparator.c:61]: (error) Array 'tps_comparators[2]'
accessed at index 2, which is out of bounds.
[drivers/mfd/tps65911-comparator.c:88]: (error) Array
Reported by cppcheck
Signed-off-by: Thomas Jarosch
---
drivers/staging/unisys/uislib/uisutils.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/unisys/uislib/uisutils.c
b/drivers/staging/unisys/uislib/uisutils.c
index 8ff6d26..d821c82 100644
---
On Fri, Dec 12, 2014 at 4:34 PM, Sasha Levin wrote:
>
> Right, it's virtio-9p. However, virtio-9p acts merely as a proxy to an
> underlying
> tmpfs - so while it's slow, I don't think it's way slower than the average
> disk
> backed ext4.
I was thinking more in the sense of "how much of the
Here goes... :)
Signed-off-by: Andy Lutomirski
---
Wow, screwing up a MAINTAINERS patch. I win!
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e186bf90ed8a..27ab8bcec3a0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10476,6 +10476,13 @@
On 12/12/2014 07:23 PM, Linus Torvalds wrote:
> On Fri, Dec 12, 2014 at 3:54 PM, Sasha Levin wrote:
>> >
>> > I ran bisection on trinity, rather than the kernel, and got the following
>> > result:
> Heh. That commit is pretty small, but I guess the effect of having a
> number of regular files
Here goes... :)
Signed-off-by: Andy Lutomirski
---
MAINTAINERS | 7 +++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index e186bf90ed8a..8737081d8546 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10476,6 +10476,13 @@ L: linux-e...@vger.kernel.org
S:
On 12/12/2014 04:11 PM, Andy Lutomirski wrote:
> On Fri, Dec 12, 2014 at 3:16 PM, Dave Hansen wrote:
>> On 12/12/2014 03:04 PM, Andy Lutomirski wrote:
>>> Anyway, do your patches handle the case where a 32-bit app maliciously
>>> executes a 64-bit mpx insn with a very large address? I think it's
On Fri, Dec 12, 2014 at 3:54 PM, Sasha Levin wrote:
>
> I ran bisection on trinity, rather than the kernel, and got the following
> result:
Heh. That commit is pretty small, but I guess the effect of having a
number of regular files open and being used on the trinity loads can
be almost
Yunzhi,
On Fri, Dec 12, 2014 at 7:07 AM, Yunzhi Li wrote:
> This patch to add a generic PHY driver for ROCKCHIP usb PHYs,
> currently this driver can support RK3288. The RK3288 SoC have
> three independent USB PHY IPs which are all configured through a
> set of registers located in the GRF
On Fri, 12 Dec 2014, Stephen Boyd wrote:
> Commit 6314b6796e3c (clk: Don't hold prepare_lock across debugfs
> creation, 2014-09-04) forgot to update one place where we hold
> the prepare_lock while creating debugfs directories. This means
> we still have the chance of a deadlock that the commit
On Fri, Dec 12, 2014 at 3:16 PM, Dave Hansen wrote:
> On 12/12/2014 03:04 PM, Andy Lutomirski wrote:
>> Anyway, do your patches handle the case where a 32-bit app maliciously
>> executes a 64-bit mpx insn with a very large address? I think it's
>> okay, but I might have missed something.
>
> You
Thanks for the review.
On Fri, Dec 12, 2014 at 09:47:39AM +, Al Viro wrote:
> First of all, your checks in ovl_mount_dir_noesc() have no effect besides
> spamming the logs. In
> if (err)
> pr_err("overlayfs: failed to resolve '%s': %i\n", name, err);
> else
On Thu, Dec 11, 2014 at 11:26:07AM +0100, Éric Piel wrote:
> On 13-11-14 20:57, Takashi Iwai wrote:
> >From: Dominique Leuenberger
> >
> >HP ZBook 15 laptop needs a non-standard mapping (x_inverted).
> >
> >BugLink: http://bugzilla.opensuse.org/show_bug.cgi?id=905329
> >Signed-off-by: Dominique
On 12/11/2014 05:57 PM, Sasha Levin wrote:
> On 12/11/2014 05:36 PM, Linus Torvalds wrote:
>> > On Thu, Dec 11, 2014 at 1:52 PM, Sasha Levin
>> > wrote:
>> >
>> > Is it possible that Dave and myself were seeing the same problem after
>> > all?
>> > Could be. You do have
Hi,
On Fri, Dec 12, 2014 at 12:22 PM, Heiko Stübner wrote:
> Hi,
>
> when trying linux-next for 20141210 on my rk3288 eval board I got errors
> when ejecting sd cards. Especially a timeout for a command and following
> this an rcu stall which essentially stops everything [0].
>
> My way to
On Fri, Dec 12, 2014 at 5:27 AM, Mark Brown wrote:
> On Wed, Dec 10, 2014 at 08:15:26PM -0800, Ben Zhang wrote:
>
>> The MICBIAS voltage for IN1 can be set to 1.476V/2.970V/1.242V/2.475V
>
> The changelog says "platform config" but this is adding DT binding.
>
>> +- realtek,micbias1
>> + Select
Hi MST,
On Wed, 2014-12-10 at 21:14 +0200, Michael S. Tsirkin wrote:
> OK, so far I got positive test reports from Cornelia, so tomorrow, I'm
> going to send a pull request with the following:
> - this huge patchset
> - virtio 1.0 enhancements
> - virtio_ccw: minor enhancements
>
> Everything
On Sat, Dec 13, 2014 at 12:24:03AM +0100, Thomas Gleixner wrote:
> - Posting of massive patch sets right during or just before the merge
>window
>
> - Reposting of patchsets before the reviewer/maintainer had a chance
>to reply to ALL of N patches
Absolutely agreed.
The rule of
On Fri, Dec 12, 2014 at 03:07:23PM -0800, Vinson Lee wrote:
> On Fri, Dec 12, 2014 at 2:45 PM, Luis R. Rodriguez wrote:
> > On Fri, Dec 12, 2014 at 02:38:26PM -0800, Vinson Lee wrote:
> >> From: Nate Stahl
> >>
> >> A full task stack dump of all tasks on a machine can generate more than
> >> 4MB
On Fri, Dec 12, 2014 at 03:24:16PM -0800, Mike Turquette wrote:
> Quoting Russell King - ARM Linux (2014-12-12 15:05:43)
> > On Fri, Dec 12, 2014 at 03:04:16PM -0800, Stephen Boyd wrote:
> > > Commit 6314b6796e3c (clk: Don't hold prepare_lock across debugfs
> > > creation, 2014-09-04) forgot to
Quoting Russell King - ARM Linux (2014-12-12 15:05:43)
> On Fri, Dec 12, 2014 at 03:04:16PM -0800, Stephen Boyd wrote:
> > Commit 6314b6796e3c (clk: Don't hold prepare_lock across debugfs
> > creation, 2014-09-04) forgot to update one place where we hold
> > the prepare_lock while creating debugfs
I'm really starting to get seriously grumpy about this.
Everyone is aware that we are in the middle of the merge window. So
this is definetely NOT the time to send anything else than urgent
bugfixes or the usual question/reply on something which was discussed
before.
I really consider it to be
On 12/12/2014 03:04 PM, Andy Lutomirski wrote:
> Anyway, do your patches handle the case where a 32-bit app maliciously
> executes a 64-bit mpx insn with a very large address? I think it's
> okay, but I might have missed something.
You mean in the instruction decoder? I haven't tried that case
On Fri, 12 Dec 2014 21:35:14 +0100 (CET)
Thomas Gleixner wrote:
> We're almost there with x86 but my gut feeling tells me that pushing
> it now is too risky. I rather prefer quiet holidays for all of us than
> the nagging fear that the post holiday inbox will be full of obscure
> bug reports
Hi Mark,
Thanks for review.
Mark Brown wrote on 12.12.2014 17:36:
On Wed, Dec 10, 2014 at 04:48:19PM +0100, Andrzej Hajda wrote:
track is a generic framework for safe tracking presence of any kernel objects
having an id. There are no special requirements about type of object or its
id. Id
On 12 December 2014 at 22:42, David Long wrote:
> On 12/10/14 11:38, Steve Capper wrote:
>>
>> On Tue, Dec 09, 2014 at 09:27:18AM -0500, David Long wrote:
>>>
>>> On 12/09/14 08:33, Steve Capper wrote:
On Thu, Dec 04, 2014 at 08:53:03PM +0900, Masami Hiramatsu wrote:
>>
>>
>> [...]
>>
On Fri, Dec 12, 2014 at 2:45 PM, Luis R. Rodriguez wrote:
> On Fri, Dec 12, 2014 at 02:38:26PM -0800, Vinson Lee wrote:
>> From: Nate Stahl
>>
>> A full task stack dump of all tasks on a machine can generate more than
>> 4MB of output to dmesg. Dumping this data to the serial console causes
>>
On Fri, Dec 12, 2014 at 03:04:16PM -0800, Stephen Boyd wrote:
> Commit 6314b6796e3c (clk: Don't hold prepare_lock across debugfs
> creation, 2014-09-04) forgot to update one place where we hold
> the prepare_lock while creating debugfs directories. This means
> we still have the chance of a
n Fri, Dec 12, 2014 at 1:41 PM, Dave Hansen wrote:
> On 12/12/2014 12:48 PM, Andy Lutomirski wrote:
>> On Fri, Dec 12, 2014 at 12:27 PM, Dave Hansen wrote:
>>> You want the same size structures with the same format for 32-bit and
>>> 64-bit modes?
>>
>> Yes. Especially because programs can
Commit 6314b6796e3c (clk: Don't hold prepare_lock across debugfs
creation, 2014-09-04) forgot to update one place where we hold
the prepare_lock while creating debugfs directories. This means
we still have the chance of a deadlock that the commit was trying
to fix. Actually fix it by moving the
On Fri, Dec 12, 2014 at 12:35 PM, Thomas Gleixner wrote:
>
> This will block other things in that area for a while, but it's the
> only sane decision at the moment, unless Linus insists on pulling the
> lot and promises to deal with the fallout. :)
Heh, no. I'll happily vote for a calm xmas
Some struct fields in wifi.h are meant to be __le16 but were declared as
unsigned short. This was reported by sparse:
rtw_wlan_util.c:538:24: warning: cast to restricted __le16
rtw_wlan_util.c:1544:29: warning: cast to restricted __le16
rtw_wlan_util.c:1546:25: warning: cast to restricted
On Fri, 2014-12-12 at 17:45 -0500, Peter Hurley wrote:
> [ +cc Daniel because of the i915 lockdep report ]
>
> On 12/12/2014 05:03 PM, Imre Deak wrote:
> > On Fri, 2014-12-12 at 16:03 -0500, Peter Hurley wrote:
> >> On 12/12/2014 03:29 PM, Imre Deak wrote:
> >>> Hi Peter,
> >>>
> >>> thanks for
gt; this out takes rather long, that is.
> >
> > Is there some problem with the current mainline 3.19 code?
>
> The problem I noticed is with next-20141212. For some reason - Stephen
> appears to not know exactly why - it ended up with a Kconfig entry for
> INIT_FALLBACK without any act
On 12/12/14 19:52, Jes Sorensen wrote:
> Larry Finger writes:
>> On 12/12/2014 05:35 AM, Krzysztof Konopko wrote:
>>> I was hunting particularly for inconsistencies with `sparse` and came
>>> across this one. But I dug a bit further and I wonder why the driver is
>>> not using standard stuff
On 12/12/14 15:56, Bruno Wolff III wrote:
On Fri, Dec 12, 2014 at 13:23:19 +0100,
toki clover wrote:
Now, I did not see any Linux FS devs activity/response to this... What
a waste of time because if those patch don't make it for this merge
window, rebasing/reposting will be, again,
Hello,
I have a weird problem with CONFIG_CC_OPTIMIZE_FOR_SIZE.
When it's enabled, tridentfb hangs with Blade3D card (ID 0x9880) in
blade_image_blit(). The screen is blank with some artifacts and machine does
not respond to ping or keyboard. However, it can be rebooted by Alt+SysRq+B.
It
On 12/12/14 18:35, Larry Finger wrote:
> On 12/12/2014 05:35 AM, Krzysztof Konopko wrote:
>> On 12/12/14 00:53, Larry Finger wrote:
>>> In particular, did you test on big-endian hardware after you
>>> made this change?
>>
>> Nope. I don't have any big-endian hardware. I don't even have the
>>
On 12/11/2014 01:04 PM, Juergen Gross wrote:
diff --git a/scripts/xen-hypercalls.sh b/scripts/xen-hypercalls.sh
new file mode 100644
index 000..e6447b7
--- /dev/null
+++ b/scripts/xen-hypercalls.sh
@@ -0,0 +1,11 @@
+#!/bin/sh
+out="$1"
+shift
+in="$@"
+
+for i in $in; do
+ eval $CPP
On Fri, Dec 12, 2014 at 02:38:26PM -0800, Vinson Lee wrote:
> From: Nate Stahl
>
> A full task stack dump of all tasks on a machine can generate more than
> 4MB of output to dmesg. Dumping this data to the serial console causes
> the machine to hang for a number of minutes (an unacceptable
[ +cc Daniel because of the i915 lockdep report ]
On 12/12/2014 05:03 PM, Imre Deak wrote:
> On Fri, 2014-12-12 at 16:03 -0500, Peter Hurley wrote:
>> On 12/12/2014 03:29 PM, Imre Deak wrote:
>>> Hi Peter,
>>>
>>> thanks for your review.
>>>
>>> On Fri, 2014-12-12 at 13:32 -0500, Peter Hurley
On 12/10/14 11:38, Steve Capper wrote:
On Tue, Dec 09, 2014 at 09:27:18AM -0500, David Long wrote:
On 12/09/14 08:33, Steve Capper wrote:
On Thu, Dec 04, 2014 at 08:53:03PM +0900, Masami Hiramatsu wrote:
[...]
Not sure if this is helpful, but the following also caused a crash for
me:
From: Nate Stahl
A full task stack dump of all tasks on a machine can generate more than
4MB of output to dmesg. Dumping this data to the serial console causes
the machine to hang for a number of minutes (an unacceptable impact),
but dumping the same data to memory is feasible if the dmesg
nt mainline 3.19 code?
The problem I noticed is with next-20141212. For some reason - Stephen
appears to not know exactly why - it ended up with a Kconfig entry for
INIT_FALLBACK without any actually users of that Kconfig symbol. My
infamous 800 line perl monster - which I run on every linux-next release
On 12/12/14 18:12, Jes Sorensen wrote:
> Krzysztof Konopko writes:
>> Some struct fields in wifi.h are meant to be __le16 bu were declared as
>> unsigned short. This was reported by sparse:
>>
>> rtw_wlan_util.c:538:24: warning: cast to restricted __le16
>> rtw_wlan_util.c:1544:29: warning:
On 12/12/14 17:43, Larry Finger wrote:
> On 12/12/2014 06:52 AM, Dan Carpenter wrote:
>> On Thu, Dec 11, 2014 at 05:53:30PM -0600, Larry Finger wrote:
>>> On 12/11/2014 04:23 PM, Krzysztof Konopko wrote:
Some struct fields in wifi.h are meant to be __le16 bu were declared as
unsigned
From: Joshua Kinard
This adds a driver for the Dallas/Maxim DS1685-family of RTC chips. It
supports the DS1685/DS1687, DS1688/DS1691, DS1689/DS1693, DS17285/DS17287,
DS17485/DS17487, and DS17885/DS17887 RTC chips. These chips are commonly found
in SGI O2 and SGI Octane systems. It was
From: Joshua Kinard
This modifies the IP32 (SGI O2) platform and reset code to utilize the new
rtc-ds1685 driver. The old mc146818rtc.h header is removed and ip32_defconfig
is updated as well.
Signed-off-by: Joshua Kinard
---
arch/mips/configs/ip32_defconfig |3
While trying to deal with errata i856 on the dra7xx I encountered some
obvious typos in the frequencies checked in timer.c, so those are being
fixed in case anyone ever tries to use one of them.
Also implement a fix for errata i856. Without the fix the time on the
system will get ahead by 43
This function was renamed to mips_cpu_irq_of_init(), so fix it to avoid
a compile error.
Signed-off-by: Kevin Cernekee
---
arch/mips/bcm3384/irq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/bcm3384/irq.c b/arch/mips/bcm3384/irq.c
index 0fb5134..fd94fe8 100644
Add GPIO hogging documentation to gpio.txt
Signed-off-by: Benoit Parrot
---
Changes since v3:
* Renamed the "direction" DT properties to "state".
Documentation/devicetree/bindings/gpio/gpio.txt | 23 +++
1 file changed, 23 insertions(+)
diff --git
11 platforms require at least one of these workarounds to be enabled; 22
platforms do not. In the latter case we can fall back to a generic version.
Note that this also deletes an orphaned reference to RM9000_CDEX_SMP_WAR.
Suggested-by: Arnd Bergmann
Signed-off-by: Kevin Cernekee
---
Several drivers now use this API, including the ARM GIC driver, so remove
the outdated comment.
Signed-off-by: Kevin Cernekee
---
Documentation/IRQ-domain.txt | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/Documentation/IRQ-domain.txt b/Documentation/IRQ-domain.txt
index
V4->V5:
- Rebase on top of Linus' head of tree, converting BCM3384 platform code
to Generic BMIPS platform code.
- Fix a couple of #include's
- Remove a couple of bogus entries from bmips_be_defconfig
Compile-tested only. Some BMIPS platforms may require acked-but-unmerged
changes in
This platform is configured primarily through device tree, and we can
reuse the same code to support a bunch of other chips. Change the name
to reflect this.
Signed-off-by: Kevin Cernekee
---
arch/mips/Kbuild.platforms | 2 +-
arch/mips/Kconfig
These controllers support multiple enable/status pairs (64+ IRQs),
can put the enable/status words at different offsets, and do not
support multiple parent IRQs.
Signed-off-by: Kevin Cernekee
---
.../interrupt-controller/brcm,bcm3380-l2-intc.txt | 41
If the machine doesn't set its own _machine_restart callback, call the
common do_kernel_restart() instead. This allows arch-independent reset
drivers from drivers/power/reset/ to be used to reboot the machine.
Signed-off-by: Kevin Cernekee
---
arch/mips/kernel/reset.c | 2 ++
1 file changed, 2
From: Brian Norris
Wakeable interrupts might be pending at boot/init time, because wakeup
interrupts might have triggered a resume from S5. So don't clear such
wakeups.
This means that any driver which requests a wakeable interrupt bit
should be prepared to handle an interrupt as soon as they
Currently the driver assumes that REG_BASE+0x00 is the IRQ enable mask,
and REG_BASE+0x04 is the IRQ status mask. This is true on BCM3384 and
BCM7xxx, but it is not true for some of the controllers found on BCM63xx
chips. So we will change a couple of key assumptions:
- Don't assume that both
BMIPS 3300/435x/438x CPUs have a readahead cache that is separate from
the L1/L2. During a DMA operation, accesses adjacent to a DMA buffer
may cause parts of the DMA buffer to be prefetched into the RAC. To
avoid possible coherency problems, flush the RAC upon DMA completion.
Signed-off-by:
There is no "bcm3384" bus so let's just remove it to avoid confusion.
Signed-off-by: Kevin Cernekee
---
arch/mips/bmips/setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/mips/bmips/setup.c b/arch/mips/bmips/setup.c
index 5099109..ac402ed 100644
---
This is the main peripheral IRQ controller on the BCM7xxx MIPS chips;
it has the following characteristics:
- 64 to 160+ level IRQs
- Atomic set/clear registers
- Reasonably predictable register layout (N status words, then N
mask status words, then N mask set words, then N mask clear
Enabling support for more than one BMIPS CPU in the same build may
result in different L1_CACHE_SHIFT values, e.g.
CPU_BMIPS5000 selects MIPS_L1_CACHE_SHIFT_7
CPU_BMIPS4380 selects MIPS_L1_CACHE_SHIFT_6
anything else defaults to MIPS_L1_CACHE_SHIFT_5
Ensure that if more than one
Some machines only have one bus type to register (e.g. "simple-bus").
Signed-off-by: Kevin Cernekee
---
arch/mips/kernel/prom.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/arch/mips/kernel/prom.c b/arch/mips/kernel/prom.c
index 452d435..e303cb1 100644
---
This is a more standardized way of handling DMA remapping, and it is
suitable for the memory map found on BCM3384.
Signed-off-by: Kevin Cernekee
---
arch/mips/bmips/dma.c | 100 ++
1 file changed, 68 insertions(+), 32 deletions(-)
diff --git
1 - 100 of 1270 matches
Mail list logo
