Re: frequent lockups in 3.18rc4
* 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 properly) > > The thing is, we'd have to return to user space for that to > happen. And when we do that, we check the "should we schedule" > flag again. So races like this really shouldn't matter, but > there could be something kind-of-similar that just ends up > causing a wakeup to be delayed. Furthermore there ought to be a scheduler tick active in that case - which won't be as fast as an immediate reschedule, but fast enough to beat the softlockup watchdog's threshold of 20 seconds or so. That is why I think it would be interesting to examine how the locked up state looks like: is the system truly locked up, impossible to log in to, locks held but not released, etc., or is the lockup transient? > But it would need to be delayed for seconds (for the RCU > threads) or for tens of seconds (for the watchdog) to matter. > > Which just seems unlikely. Even the "very high load" thing > shouldn't really matter, since while that could delay one > particular thread being scheduled, it shouldn't delay the next > "should we schedule" test. In fact, high load would normally be > extected to make the next "should we schedule" come faster. > > But this is where some load calculation overflow might screw > things up, of course. Also, the percpu watchdog threads are SCHED_FIFO:99, woken up through percpu hrtimers, which are not easy to delay through high SCHED_OTHER load. Thanks, Ingo -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sched: Fix lost reschedule in __cond_resched()
* 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 > > __preempt_count_add(PREEMPT_ACTIVE); > __schedule(); > __preempt_count_sub(PREEMPT_ACTIVE); > > and in between the __schedule() and __preempt_count_sub(), if > an interrupt comes in and wakes up some important process, it > won't reschedule (because preemption is active), but then we > enable preemption again and don't check whether we should > reschedule (again), and we just go on our merry ways. Indeed, that's a really good find regardless of whether it's the source of these lockups - the (untested) patch below ought to cure that. > Now, I don't see how that could really matter for a long time - > returning to user space will check need_resched, and sleeping > will obviously force a reschedule anyway, so these kinds of > races should at most delay things by just a tiny amount, but > maybe there is some case where we screw up in a bigger way. So > I do *not* believe that the one in __cond_resched() matters, > but I'm giving it as an example of the kind of things that > could go wrong. (as you later note) NOHZ is somewhat special in this regard, because there we try really hard not to run anything periodically, so a lost reschedule will matter more. But ... I'd be surprised if this patch made a difference: it should normally not be possible to go idle with tasks on the runqueue (even with this bug present), and with at least one busy task on the CPU we get the regular scheduler tick which ought to hide such latencies. It's nevertheless a good thing to fix, I'm just not sure it's the root cause of the observed lockup here. Thanks, Ingo -- Reported-by: Linus Torvalds diff --git a/kernel/sched/core.c b/kernel/sched/core.c index bb398c0c5f08..532809aa0544 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -4207,6 +4207,8 @@ static void __cond_resched(void) __preempt_count_add(PREEMPT_ACTIVE); __schedule(); __preempt_count_sub(PREEMPT_ACTIVE); + if (need_resched()) + __schedule(); } int __sched _cond_resched(void) -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 2/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
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 which are all configured through a
>> set of registers located in the GRF (general register files)
>> module.
>>
>> Signed-off-by: Yunzhi Li
>>
>> ---
>>
>> Changes in v7:
>> - Accept Kishon's comments to use phandle args to find a phy
>> struct directly and get rid of using a custom of_xlate
>> function.
>
> I'm going to assume you didn't test this version, since it doesn't
> work for me. At suspend time power is high and my printouts in the
> powerup/powerdown code aren't called...
>
>
>> + for_each_available_child_of_node(dev->of_node, child) {
>> + rk_phy = devm_kzalloc(dev, sizeof(*rk_phy), GFP_KERNEL);
>> + if (!rk_phy)
>> + return -ENOMEM;
>> +
>> + if (of_property_read_u32(child, "reg", ®_offset)) {
>> + dev_err(dev, "missing reg property in node %s\n",
>> + child->name);
>> + return -EINVAL;
>> + }
>> +
>> + rk_phy->reg_offset = reg_offset;
>> + rk_phy->reg_base = grf;
>> +
>> + rk_phy->clk = of_clk_get_by_name(child, "phyclk");
>> + if (IS_ERR(rk_phy->clk))
>> + rk_phy->clk = NULL;
>> +
>> + rk_phy->phy = devm_phy_create(dev, child, &ops);
>> + if (IS_ERR(rk_phy->phy)) {
>> + dev_err(dev, "failed to create PHY\n");
>> + return PTR_ERR(rk_phy->phy);
>> + }
>> + phy_set_drvdata(rk_phy->phy, rk_phy);
>> + }
>> +
>> + phy_provider = devm_of_phy_provider_register(dev,
>> of_phy_simple_xlate);
>
> I think your bug is here. I think you now need to register 3 phy
> providers, not just one.
No there should be only one phy provider. It means the bug is elsewhere.
Thanks
Kishon
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH net-next 1/1] net: Support for switch port configuration
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; sfel...@gmail.com; linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH net-next 1/1] net: Support for switch port configuration On 12/11/14, 8:56 AM, Jiri Pirko wrote: Thu, Dec 11, 2014 at 05:37:46PM CET, ro...@cumulusnetworks.com wrote: On 12/11/14, 3:01 AM, Jiri Pirko wrote: Thu, Dec 11, 2014 at 10:59:42AM CET, marco.varl...@intel.com wrote: -Original Message- From: John Fastabend [mailto:john.fastab...@gmail.com] Sent: Wednesday, December 10, 2014 5:04 PM To: Jiri Pirko Cc: Varlese, Marco; net...@vger.kernel.org; step...@networkplumber.org; Fastabend, John R; ro...@cumulusnetworks.com; sfel...@gmail.com; linux- ker...@vger.kernel.org Subject: Re: [RFC PATCH net-next 1/1] net: Support for switch port configuration On 12/10/2014 08:50 AM, Jiri Pirko wrote: Wed, Dec 10, 2014 at 05:23:40PM CET, marco.varl...@intel.com wrote: From: Marco Varlese Switch hardware offers a list of attributes that are configurable on a per port basis. This patch provides a mechanism to configure switch ports by adding an NDO for setting specific values to specific attributes. There will be a separate patch that extends iproute2 to call the new NDO. What are these attributes? Can you give some examples. I'm asking because there is a plan to pass generic attributes to switch ports replacing current specific ndo_switch_port_stp_update. In this case, bridge is setting that attribute. Is there need to set something directly from userspace or does it make rather sense to use involved bridge/ovs/bond ? I think that both will be needed. +1 I think for many attributes it would be best to have both. The in kernel callers and netlink userspace can use the same driver ndo_ops. But then we don't _require_ any specific bridge/ovs/etc module. And we may have some attributes that are not specific to any existing software module. I'm guessing Marco has some examples of these. [...] -- John Fastabend Intel Corporation We do have a need to configure the attributes directly from user-space and I have identified the tool to do that in iproute2. An example of attributes are: * enabling/disabling of learning of source addresses on a given port (you can imagine the attribute called LEARNING for example); * internal loopback control (i.e. LOOPBACK) which will control how the flow of traffic behaves from the switch fabric towards an egress port; * flooding for broadcast/multicast/unicast type of packets (i.e. BFLOODING, MFLOODING, UFLOODING); Some attributes would be of the type enabled/disabled while other will allow specific values to allow the user to configure different behaviours of that feature on that particular port on that platform. One thing to mention - as John stated as well - there might be some attributes that are not specific to any software module but rather have to do with the actual hardware/platform to configure. I hope this clarifies some points. It does. Makes sense. We need to expose this attr set/get for both in-kernel and userspace use cases. Please adjust you patch for this. Also, as a second patch, it would be great if you can convert ndo_switch_port_stp_update to this new ndo. Why are we exposing generic switch attribute get/set from userspace ?. We already have specific attributes for learning/flooding which can be extended further. Yes, but that is for PF_BRIDGE and bridge specific attributes. There might be another generic attrs, no? I cant think of any. And plus, the whole point of switchdev l2 offloads was to map these to existing bridge attributes. And we already have a match for some of the attributes that marco wants. If there is a need for such attributes, i don't see why it is needed for switch devices only. It is needed for any hw (nics etc). And, a precedence to this is to do it via ethtool. Having said that, am sure we will find a need for this in the future. And having a netlink attribute always helps. Today, it seems like these can be mapped to existing attributes that are settable via ndo_bridge_setlink/getlink. And for in kernel apii had a sample patch in my RFC series (Which i was going to resubmit, until it was decided that we will use existing api around ndo_bridge_setlink/ndo_bridge_getlink): http://www.spinics.net/lists/netdev/msg305473.html Yes, this might become handy for other generic non-bridge attrs. Thanks, Roopa The list I provided is only a subset of the attributes we will need to be exposed. I do have more and I'm sure that more will come in the future. As I mentioned in few posts earlier, some attributes are generic and some are not. I did not consider ethtool for few reasons but the main one is that I was under the impression that netlink w
Re: [dm-devel] [PATCH v2] staging: writeboost: Add dm-writeboost
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 backing device as consumer. If writeboost can do that without any random writes, then probably it can save SSD/FTL of doing a lot of dirty jobs, and utilize the faster sequential read/write performance from SSD. That'll be awesome. However, I saw every data log segment in its design has meta data header, like dirty_bits, so I guess writeboost has to randomly write those data headers of stored data logs in SSD; also, splitting all bio into 4KB will hurt its ability to get max raw SSD throughput, modern NAND Flash has pages much bigger than 4KB; so overall I think the actual benefits writeboost gets from this design will be discounted. The good thing is that it seems writeboost doesn't use garbage collection to clean old invalid logs, this will avoid the double garage collection effect other caching module has, which essentially both caching module and internal SSD will perform garbage collections twice. And one question, how long will be data logs replay time during init, if SSD is almost full of dirty data logs? Jianjian On Fri, Dec 12, 2014 at 7:09 AM, Akira Hayakawa wrote: >> However, after looking at the current code, and using it I think it's >> a long, long way from being ready for production. As we've already >> discussed there are some very naive design decisions in there, such as >> copying every bio payload to another memory buffer, splitting all io >> down to 4k. Think about the cpu overhead and memory consumption! >> Think about how it will perform when memory is constrained and it >> can't allocate many of those rambufs! I'm sure more issues will be >> found if I read further. > These decisions are made based on measurement. They are not naive. > I am a man who dislikes performance optimization without measurement. > As a result, I regard things brought by the simplicity much important > than what's from other design decisions possible. > > About the CPU consumption, > the average CPU consumption while performing random write fio > with consumer level SSD is only 3% or so, > which is 5 times efficient than bcache per iops. > > With RAM-backed cache device, it reaches about 1.5GB/sec throughput. > Even in this case the CPU consumption is only 12%. > Please see this post, > http://www.redhat.com/archives/dm-devel/2014-February/msg0.html > > I don't think the CPU consumption is small enough to ignore. > > About the memory consumption, > you seem to misunderstand the fact. > The rambufs are not dynamically allocated but statically. > The default amount is 8MB and this is usually not to argue. > >> Mike raised the question of why you want this in the kernel so much? >> You'd find none of the distros would support it; so it doesn't widen >> your audience much. It's far better for you to maintain it outside of >> the kernel at this point. Any users will be bold, adventurous people, >> who will be quite capable of building a kernel module. > Some people deploy Writeboost in their daily use. > The sound of "log-structured" seems to easily attract storage guys' attention. > If this driver is merged into upstream, I think it gains many audience and > thus feedback. > When my driver was introduced by Phoronix before, it actually drew attentions. > They must wait for Writeboost become available in upstream. > http://www.phoronix.com/scan.php?page=news_item&px=MTQ1Mjg > >> I'm sorry to have disappointed you so, but if I let this go upstream >> it would mean a massive amount of support work for me, not to mention >> a damaged reputation for dm. > If you read the code further, you will find how simple the mechanism is. > Not to mention the code itself is. > > - Akira > > On 12/12/14 11:24 PM, Joe Thornber wrote: >> On Fri, Dec 12, 2014 at 09:42:15AM +0900, Akira Hayakawa wrote: >>> The SSD-caching should be log-structured. >> >> No argument there, and this is why I've supported you with >> dm-writeboost over the last couple of years. >> >> However, after looking at the current code, and using it I think it's >> a long, long way from being ready for production. As we've already >> discussed there are some very naive design decisions in there, such as >> copying every bio payload to another memory buffer, splitting all io >> down to 4k. Think about the cpu overhead and memory consumption! >> Think about how it will perform when memory is constrained and it >> can't allocate many of those rambufs! I'm sure more issues will be >> found if I read further. >> >> I'm sorry to have disappointed you so, but if I let this go upstream >> it would mean a massive amount of support work for me, not to mention >> a damaged reputation for dm. >> >> Mike raised the question of why you want this in the kernel so much?
Re: [PATCH] staging: rtl8723au: Fix sparse warnings
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 a/drivers/staging/rtl8723au/include/wifi.h
> b/drivers/staging/rtl8723au/include/wifi.h
[]
> @@ -28,7 +28,7 @@
> struct AC_param {
> unsigned char ACI_AIFSN;
> unsigned char CW;
> - unsigned short TXOP_limit;
> + __le16 TXOP_limit;
> } __packed;
>
> struct WMM_para_element {
> @@ -39,9 +39,9 @@ struct WMM_para_element {
>
> struct ADDBA_request {
> unsigned char dialog_token;
> - unsigned short BA_para_set;
> - unsigned short BA_timeout_value;
> - unsigned short BA_starting_seqctrl;
> + __le16 BA_para_set;
> + __le16 BA_timeout_value;
> + __le16 BA_starting_seqctrl;
> } __packed;
If I did this, I would also change the
unsigned char uses to u8 at the same time.
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/6] net-PPP: Deletion of a few unnecessary checks
> 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 (like yours for this issue) makes it occasionally harder to see the next useful steps. So another constructive discussion is evolving around the clarification of some implementation details. 2. I prefer also different communication styles at some points. 3. I reached a point where the desired software updates were not immediately obvious for me while other contributors might have achieved a better understanding for the affected issues already. 4. I am on the way at the moment to get my Linux software development system running again. https://forums.opensuse.org/showthread.php/503327-System-startup-does-not-continue-after-hard-disk-detection > Everyone gets their code reviewed, everyone has to modify their > changes to adhere to the subsystem maintainer's wishes. That is fine as usual. > You are not being treated specially, and quite frankly nobody > is asking anything unreasonable of you. That is also true as the software development process will be continued. Regards, Markus -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/6] net-PPP: Deletion of a few unnecessary checks
> 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 wrong time. You can relax a bit eventually. More merge windows will follow, won't they? It will be nice if a bunch of recent code clean-ups which were also triggered by static source code analysis will be integrated into Linux 3.19 already. More update suggestions will be considered later again as usual. Regards, Markus -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 2/2] tracing: Add tracepoint_printk cmdline
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 is used.
Echoing 1 into the sysctl file without the cmdline option will
have no affect.
Note, this is a dangerous option. Having high frequency
tracepoints send their data to printk() can possibly cause
a live lock.
Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1412121539300.16494@nanos
Suggested-by: Thomas Gleixner
Signed-off-by: Steven Rostedt
---
Documentation/kernel-parameters.txt | 18 ++
include/linux/ftrace.h | 1 +
kernel/sysctl.c | 7 +++
kernel/trace/trace.c| 17 +
kernel/trace/trace.h| 1 +
kernel/trace/trace_events.c | 32
6 files changed, 76 insertions(+)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 1d09eb37c562..d81f464a7358 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -3500,6 +3500,24 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
See also Documentation/trace/ftrace.txt "trace options"
section.
+ tracepoint_printk[FTRACE]
+ Have the tracepoints sent to printk as well as the
+ tracing ring buffer. This is useful for early boot up
+ where the system hangs or reboots and does not give the
+ option for reading the tracing buffer or performing a
+ ftrace_dump_on_oops.
+
+ To turn off having tracepoints sent to printk,
+echo 0 > /proc/sys/kernel/tracepoint_printk
+ Note, echoing 1 into this file without the
+ tracepoint_printk kernel cmdline option has no effect.
+
+ ** CAUTION **
+
+ Having tracepoints sent to printk() and activating high
+ frequency tracepoints such as irq or sched, can cause
+ the system to live lock.
+
traceoff_on_warning
[FTRACE] enable this option to disable tracing when a
warning is hit. This turns off "tracing_on". Tracing can
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index 0fc3e720d4fd..9e20e7c28aab 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -879,6 +879,7 @@ static inline int test_tsk_trace_graph(struct task_struct
*tsk)
enum ftrace_dump_mode;
extern enum ftrace_dump_mode ftrace_dump_on_oops;
+extern int tracepoint_printk;
extern void disable_trace_on_warning(void);
extern int __disable_trace_on_warning;
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 4aada6d9fe74..bb50c2187194 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -622,6 +622,13 @@ static struct ctl_table kern_table[] = {
.mode = 0644,
.proc_handler = proc_dointvec,
},
+ {
+ .procname = "tracepoint_printk",
+ .data = &tracepoint_printk,
+ .maxlen = sizeof(tracepoint_printk),
+ .mode = 0644,
+ .proc_handler = proc_dointvec,
+ },
#endif
#ifdef CONFIG_KEXEC
{
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index ec3ca694665f..18a00ab4427e 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -63,6 +63,10 @@ static bool __read_mostly tracing_selftest_running;
*/
bool __read_mostly tracing_selftest_disabled;
+/* Pipe tracepoints to printk */
+struct trace_iterator *tracepoint_print_iter;
+int tracepoint_printk;
+
/* For tracers that don't implement custom flags */
static struct tracer_opt dummy_tracer_opt[] = {
{ }
@@ -193,6 +197,13 @@ static int __init set_trace_boot_clock(char *str)
}
__setup("trace_clock=", set_trace_boot_clock);
+static int __init set_tracepoint_printk(char *str)
+{
+ if ((strcmp(str, "=0") != 0 && strcmp(str, "=off") != 0))
+ tracepoint_printk = 1;
+ return 1;
+}
+__setup("tracepoint_printk", set_tracepoint_printk);
unsigned long long ns2usecs(cycle_t nsec)
{
@@ -6878,6 +6889,12 @@ out:
void __init trace_init(void)
{
+ if (tracepoint_printk) {
+ tracepoint_print_iter =
+ kmalloc(sizeof(*tracepoint_print_iter), GFP_KERNEL);
+ if (WARN_ON(!tracepoint_print_iter))
+ tracepoint_printk = 0;
+ }
tracer_alloc_buffers();
init_ftrace_syscalls();
trace_event_init();
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
ind
[RFC PATCH 1/2] tracing: Move enabling tracepoints to just after mm_init()
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 initcalls and into init/main.c to
right after mm_init().
This also allows trace_printk() to be used early too.
Link: http://lkml.kernel.org/r/alpine.DEB.2.11.1412121539300.16494@nanos
Suggested-by: Thomas Gleixner
Signed-off-by: Steven Rostedt
---
include/linux/ftrace.h| 6 ++
init/main.c | 3 +++
kernel/trace/trace.c | 8 +++-
kernel/trace/trace.h | 13 +
kernel/trace/trace_events.c | 10 --
kernel/trace/trace_syscalls.c | 3 +--
6 files changed, 38 insertions(+), 5 deletions(-)
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index ed501953f0b2..0fc3e720d4fd 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -39,6 +39,12 @@
# define FTRACE_FORCE_LIST_FUNC 0
#endif
+/* Main tracing buffer and events set up */
+#ifdef CONFIG_TRACING
+void trace_init(void);
+#else
+static inline trace_init(void) { }
+#endif
struct module;
struct ftrace_hash;
diff --git a/init/main.c b/init/main.c
index 800a0daede7e..060e60b6aa59 100644
--- a/init/main.c
+++ b/init/main.c
@@ -561,6 +561,9 @@ asmlinkage __visible void __init start_kernel(void)
trap_init();
mm_init();
+ /* trace_printk() and trace points may be used after this */
+ trace_init();
+
/*
* Set up the scheduler prior starting any interrupts (such as the
* timer interrupt). Full topology setup happens at smp_init()
diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 4ceb2546c7ef..ec3ca694665f 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -6876,6 +6876,13 @@ out:
return ret;
}
+void __init trace_init(void)
+{
+ tracer_alloc_buffers();
+ init_ftrace_syscalls();
+ trace_event_init();
+}
+
__init static int clear_boot_tracer(void)
{
/*
@@ -6895,6 +6902,5 @@ __init static int clear_boot_tracer(void)
return 0;
}
-early_initcall(tracer_alloc_buffers);
fs_initcall(tracer_init_debugfs);
late_initcall(clear_boot_tracer);
diff --git a/kernel/trace/trace.h b/kernel/trace/trace.h
index 3255dfb054a0..c138c149d6ef 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -1301,4 +1301,17 @@ int perf_ftrace_event_register(struct ftrace_event_call
*call,
#define perf_ftrace_event_register NULL
#endif
+#ifdef CONFIG_FTRACE_SYSCALLS
+void init_ftrace_syscalls(void);
+#else
+static inline void init_ftrace_syscalls(void) { }
+#endif
+
+#ifdef CONFIG_EVENT_TRACING
+void trace_event_init(void);
+#else
+static inline void __init trace_event_init(void) { }
+#endif
+
+
#endif /* _LINUX_KERNEL_TRACE_H */
diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
index f9d0cbe014b7..fd9deb0e03f0 100644
--- a/kernel/trace/trace_events.c
+++ b/kernel/trace/trace_events.c
@@ -2477,8 +2477,14 @@ static __init int event_trace_init(void)
#endif
return 0;
}
-early_initcall(event_trace_memsetup);
-core_initcall(event_trace_enable);
+
+void __init trace_event_init(void)
+{
+ event_trace_memsetup();
+ init_ftrace_syscalls();
+ event_trace_enable();
+}
+
fs_initcall(event_trace_init);
#ifdef CONFIG_FTRACE_STARTUP_TEST
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index a72f3d8d813e..542219ea33ed 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -514,7 +514,7 @@ unsigned long __init __weak arch_syscall_addr(int nr)
return (unsigned long)sys_call_table[nr];
}
-static int __init init_ftrace_syscalls(void)
+void __init init_ftrace_syscalls(void)
{
struct syscall_metadata *meta;
unsigned long addr;
@@ -539,7 +539,6 @@ static int __init init_ftrace_syscalls(void)
return 0;
}
-early_initcall(init_ftrace_syscalls);
#ifdef CONFIG_PERF_EVENTS
--
1.8.1.4
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/2] tracing: The Grinch who stole the stealing of Christmas
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 fear that the post holiday inbox will be full of obscure > > bug reports and we then start a chase and bandaid race which will kill > > the well earned recreation in an instant. > > > > > > Though one issue with that is, that for the early boot process > > there is no way to store that information as the tracer gets > > enabled way after init_IRQ(). But there is no reason why the > > tracer could not be enabled before that. All it needs is a > > working memory allocator. Steven? > > > > Now there is another class of problems which might be hard to > > debug. When the machine just boots into a hang, so we dont get a > > ftrace output neither from an oops nor from a console. It would > > be nice if we could have a command line option which prints > > enabled trace points via (early_)printk. That would avoid > > sending out ad hoc printk debug patches which will basically > > provide the same information as the trace_points. That would be > > useful for other hard to debug boot hangs as well. Steven? > > Sure sure, everyone gets a nice calm xmas except for poor Steven who > has to hack on early tracepoints such that this will be ready for 3.20! > > -- Steve (The Grinch who Hacked on Christmas) I guess I can enjoy my Holiday. -- Steve -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
anti-spam 2015-version
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: * Please note that your password is encrypted with 1024-bit RSA keys for increased security. " ACCOUNT SUPPORT TEAM". ? ACCOUNT ACCOUNT ABN 31 088 377 860 All Rights Reserved. E-Mail Account Maintenance. -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
query on DWC3
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 enable interrupt on short packet. In
databook I could not find anything related to this, it talks only
about addresses should be aligned. In Control transfer programming
model there is no difference between Control OUT or IN transfer, if
three stage transfer - prepare trb with length wLength. Initially I
followed this and not able to receive data on EP0 OUT.:( .After adding
the above check it is working. Please help me to understand why we do
this?
Thank in advance,
Sundeep.B.S.
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/2] ALSA: oxfw: fix detect_loud_models() return value
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 the loud code for hardware that doesn't support
> it.
>
> Signed-off-by: Dan Carpenter
>
> diff --git a/sound/firewire/oxfw/oxfw.c b/sound/firewire/oxfw/oxfw.c
> index cf1d0b5..60e5cad 100644
> --- a/sound/firewire/oxfw/oxfw.c
> +++ b/sound/firewire/oxfw/oxfw.c
> @@ -43,7 +43,7 @@ static bool detect_loud_models(struct fw_unit *unit)
> err = fw_csr_string(unit->directory, CSR_MODEL,
> model, sizeof(model));
> if (err < 0)
> - return err;
> + return false;
>
> for (i = 0; i < ARRAY_SIZE(models); i++) {
> if (strcmp(models[i], model) == 0)
Reviewd-by: Takashi Sakamoto
Thanks
Takashi Sakamoto
o-taka...@sakamocchi.jp
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL v2] tracing/NMI/printk: Use seq_buf for safe printing from NMI context
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 performed, the NMI could deadlock from the printk() internal locks. This has been seen in practice. With lots of review from Petr Mladek, this code went through several iterations, and we feel that it is now at a point of quality to be accepted into mainline. Here's what is contained in this patch set: o Creates a "seq_buf" generic buffer utility that allows a descriptor to be passed around where functions can write their own "printk()" formatted strings into it. The generic version was pulled out of the trace_seq() code that was made specifically for tracing. o The seq_buf code was change to model the seq_file code. I have a patch (not included for 3.19) that converts the seq_file.c code over to use seq_buf.c like the trace_seq.c code does. This was done to make sure that seq_buf.c is compatible with seq_file.c. I may try to get that patch in for 3.20. o The seq_buf.c file was moved to lib/ to remove it from being dependent on CONFIG_TRACING. o The printk() was updated to allow for a per_cpu "override" of the internal calls. That is, instead of writing to the console, a call to printk() may do something else. This made it easier to allow the NMI to change what printk() does in order to call dump_stack() without needing to update that code as well. o Finally, the dump_stack from all CPUs via NMI code was converted to use the seq_buf code. The caller to trigger the NMI code would wait till all the NMIs finished, and then it would print the seq_buf data to the console safely from a non NMI context. [ Updated to remove unnecessary preempt_disable in printk() ] Note, I only showed the difference between V1, as that full diff was already posted here: http://lkml.kernel.org/r/20141208100528.5f971...@gandalf.local.home Please pull the latest trace-seq-buf-3.19-v2 tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git trace-seq-buf-3.19-v2 Tag SHA1: b7a8e382200950f8f596376bfef82754569ccbaf Head SHA1: 1fb8915b9876a80f43732980208b39d013f8da9d Steven Rostedt (Red Hat) (1): printk: Do not disable preemption for accessing printk_func kernel/printk/printk.c | 10 -- 1 file changed, 8 insertions(+), 2 deletions(-) --- commit 1fb8915b9876a80f43732980208b39d013f8da9d Author: Steven Rostedt (Red Hat) Date: Thu Dec 11 09:12:01 2014 -0500 printk: Do not disable preemption for accessing printk_func As printk_func will either be the default function, or a per_cpu function for the current CPU, there's no reason to disable preemption to access it from printk. That's because if the printk_func is not the default then the caller had better disabled preemption as they were the one to change it. Link: http://lkml.kernel.org/r/ca+55afz5-_lkw4jhebowinn9_ouncgrwaf2fua35u46frn-...@mail.gmail.com Suggested-by: Linus Torvalds Signed-off-by: Steven Rostedt diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c index 5af2b8bc88f0..9b896e7a50a9 100644 --- a/kernel/printk/printk.c +++ b/kernel/printk/printk.c @@ -1859,10 +1859,16 @@ asmlinkage __visible int printk(const char *fmt, ...) int r; va_start(args, fmt); - preempt_disable(); + + /* +* If a caller overrides the per_cpu printk_func, then it needs +* to disable preemption when calling printk(). Otherwise +* the printk_func should be set to the default. No need to +* disable preemption here. +*/ vprintk_func = this_cpu_read(printk_func); r = vprintk_func(fmt, args); - preempt_enable(); + va_end(args); return r; -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] tracing/sched: Check preempt_count() for current when reading task->state
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 recorded when tracing a sched_switch, even if the task put itself into another state (it hasn't scheduled out in that state yet). But with the change to use per_cpu preempt counts, the task_thread_info(p)->preempt_count is no longer used, and instead task_preempt_count(p) is used. The problem is that this does not use the current preempt count but a stale one from a previous sched_switch. The task_preempt_count(p) uses saved_preempt_count and not preempt_count(). But for tracing sched_switch, if p is current, we really want preempt_count(). I hit this bug when I was tracing sleep and the call from do_nanosleep() scheduled out in the "RUNNING" state. sleep-4290 [000] 537272.259992: sched_switch: sleep:4290 [120] R ==> swapper/0:0 [120] sleep-4290 [000] 537272.260015: kernel_stack: => __schedule (8150864a) => schedule (815089f8) => do_nanosleep (8150b76c) => hrtimer_nanosleep (8108d66b) => SyS_nanosleep (8108d750) => return_to_handler (8150e8e5) => tracesys_phase2 (8150c844) After a bit of hair pulling, I found that the state was really TASK_INTERRUPTIBLE, but the saved_preempt_count had an old PREEMPT_ACTIVE set and caused the sched_switch tracepoint to show it as RUNNING. Link: http://lkml.kernel.org/r/20141210174428.3cb75...@gandalf.local.home Acked-by: Ingo Molnar Cc: sta...@vger.kernel.org # 3.13+ Cc: Peter Zijlstra Fixes: 01028747559a "sched: Create more preempt_count accessors" Signed-off-by: Steven Rostedt --- include/trace/events/sched.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/trace/events/sched.h b/include/trace/events/sched.h index 0a68d5ae584e..a7d67bc14906 100644 --- a/include/trace/events/sched.h +++ b/include/trace/events/sched.h @@ -100,7 +100,7 @@ static inline long __trace_sched_switch_state(struct task_struct *p) /* * For all intents and purposes a preempted task is a running task. */ - if (task_preempt_count(p) & PREEMPT_ACTIVE) + if (preempt_count() & PREEMPT_ACTIVE) state = TASK_RUNNING | TASK_STATE_MAX; #endif -- 2.1.3 -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] ftrace/x86: Update i386 call to prepare_ftrace_return()
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: http://lkml.kernel.org/r/20141210231732.ga24...@wfg-t540p.sh.intel.com Reported-by: Fengguang Wu Tested-by: Fengguang Wu Fixes: 6a06bdbf7f9c "ftrace/fgraph/x86: Have prepare_ftrace_return() take ip as first parameter" Signed-off-by: Steven Rostedt --- arch/x86/kernel/entry_32.S | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/x86/kernel/entry_32.S b/arch/x86/kernel/entry_32.S index b553ed89e5f5..df3e608d409b 100644 --- a/arch/x86/kernel/entry_32.S +++ b/arch/x86/kernel/entry_32.S @@ -1192,10 +1192,10 @@ ENTRY(ftrace_graph_caller) pushl %eax pushl %ecx pushl %edx - movl 0xc(%esp), %edx - lea 0x4(%ebp), %eax + movl 0xc(%esp), %eax + lea 0x4(%ebp), %edx movl (%ebp), %ecx - subl $MCOUNT_INSN_SIZE, %edx + subl $MCOUNT_INSN_SIZE, %eax call prepare_ftrace_return popl %edx popl %ecx -- 2.1.3 -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] [GIT PULL] tracing: Fixes old and new
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 sched_switch tracepoint was showing tasks in the INTERRUPTIBLE state as RUNNING. This was due to the updates to convert preempt_count into a per_cpu variable. The tracepoint logic was made to use the task's saved_preempt_count which could hold a stale "PREEMPT_ACTIVE", instead of using the current preempt_count() call. Please pull the latest trace-fixes-v3.18 tree, which can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git trace-fixes-v3.18 Tag SHA1: acbe5cd526bb9de84fe73d68f8d7bfcbde8ab9f4 Head SHA1: aee4e5f3d3abb7a2239dd02f6d8fb173413fd02f Steven Rostedt (Red Hat) (2): ftrace/x86: Update i386 call to prepare_ftrace_return() tracing/sched: Check preempt_count() for current when reading task->state arch/x86/kernel/entry_32.S | 6 +++--- include/trace/events/sched.h | 2 +- 2 files changed, 4 insertions(+), 4 deletions(-) -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Dec 12
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 Kconfig file, but in your patchset, the bit is added and then removed. So when git comes to merge the two results, it looks like the apm-current branch in linux-next does not change that file at all, so git just uses the version from Linus' tree. I missed it among all the other conflicts I had to fix up last evening. -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpz5wo8UHzVV.pgp Description: OpenPGP digital signature
Re: [LKP] [ipmi] BUG: key ffff880fcfc51ed0 not in .data!
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 thing is that this didn't give an error before.
But this should be fixed in linux-next the next time.
Thanks again,
-corey
>
>
> ++++
> || 8425c1276b |
> 2ed09fc090 |
> ++++
> | boot_successes | 9 | 6
> |
> | boot_failures | 1 |
> 23 |
> | Out_of_memory:Kill_process | 1 | 3
> |
> | BUG:key#not_in.data| 0 |
> 19 |
> | WARNING:at_kernel/locking/lockdep.c:#lockdep_init_map()| 0 |
> 10 |
> | BUG:unable_to_handle_kernel| 0 |
> 19 |
> | Oops | 0 |
> 19 |
> | RIP:kernfs_name_hash | 0 |
> 19 |
> | Kernel_panic-not_syncing:Fatal_exception | 0 |
> 19 |
> | backtrace:lockdep_init_map | 0 |
> 10 |
> | backtrace:warn_slowpath_fmt| 0 |
> 10 |
> | backtrace:ipmi_register_smi| 0 |
> 19 |
> | backtrace:try_smi_init | 0 |
> 19 |
> | backtrace:init_ipmi_si | 0 |
> 19 |
> | backtrace:kernel_init_freeable | 0 |
> 19 |
> | WARNING:at_kernel/locking/lockdep.c:#lockdep_trace_alloc() | 0 | 9
> |
> | backtrace:__get_free_pages | 0 | 9
> |
> | backtrace:init_espfix_ap | 0 | 9
> |
> | BUG:kernel_boot_hang | 0 | 1
> |
> ++++
>
>
> [ 33.605171] ipmi_si: SPMI: io 0xca2 regsize 1 spacing 1 irq 0
> [ 33.605172] ipmi_si: Adding SPMI-specified kcs state machine duplicate
> interface
> [ 33.605176] ipmi_si: Trying ACPI-specified kcs state machine at i/o
> address 0xca2, slave address 0x0, irq 0
> [ 33.775374] BUG: key 880fcfc51ed0 not in .data!
> [ 33.780822] [ cut here ]
> [ 33.785982] WARNING: CPU: 18 PID: 1 at kernel/locking/lockdep.c:2991
> lockdep_init_map+0x116/0x141()
> [ 33.798116] DEBUG_LOCKS_WARN_ON(1)
> [ 33.801719] Modules linked in:
> [ 33.805346] CPU: 18 PID: 1 Comm: swapper/0 Not tainted
> 3.18.0-next-20141208 #4
> [ 33.813408] Hardware name: Intel Corporation S2600WP/S2600WP, BIOS
> SE5C600.86B.02.02.0002.122320131210 12/23/2013
> [ 33.824862] 0009 88080f6dbbb8 82d71b35
> 001d03f0
> [ 33.833161] 88080f6dbc08 88080f6dbbf8 810c8f39
> 880fcfc51ed0
> [ 33.841445] 810ff31d 880fcfc64f50 880fcfc51ed0
>
> [ 33.849739] Call Trace:
> [ 33.852467] [] dump_stack+0x4c/0x65
> [ 33.858204] [] warn_slowpath_common+0xa1/0xbb
> [ 33.864910] [] ? lockdep_init_map+0x116/0x141
> [ 33.871615] [] warn_slowpath_fmt+0x46/0x48
> [ 33.878030] [] lockdep_init_map+0x116/0x141
> [ 33.884544] [] __kernfs_create_file+0x8c/0xdb
> [ 33.891249] [] sysfs_add_file_mode_ns+0xd6/0x17f
> [ 33.898245] [] sysfs_create_file_ns+0x2c/0x2e
> [ 33.904953] [] device_create_file+0x44/0x89
> [ 33.911466] [] ipmi_register_smi+0x705/0x92d
> [ 33.918079] [] ? signal_pending_state+0x31/0x31
> [ 33.924981] [] try_smi_init+0x58b/0x723
> [ 33.931105] [] init_ipmi_si+0x7d7/0x983
> [ 33.937229] [] ? cleanup_ipmi_si+0xab/0xab
> [ 33.943647] [] do_one_initcall+0xed/0x17b
> [ 33.949967] [] kernel_init_freeable+0x1ec/0x279
> [ 33.956869] [] ? rest_init+0xca/0xca
> [ 33.962703] [] kernel_init+0xe/0xdf
> [ 33.968440] [] ret_from_fork+0x7c/0xb0
> [ 33.974467] [] ? rest_init+0xca/0xca
> [ 33.980303] ---[ end trace 831fe511de8a7740 ]---
> [ 33.985468] BUG: key 880fcfc51ea0 not in .data!
>
>
>
> Thanks,
> Huang, Ying
>
>
>
> ___
> LKP mailing list
> l...@linux.intel.com
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Re: [PATCH] staging: rtl8723au: Fix sparse warnings
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 hardware. I don't even have the wireless card TBH. But I'm happy to try to get one. Is Rtl8723AE the right model? No. The device numbers that end in E are PCIe and use a mac80211-based driver. As none of my BE hardware has PCIe, I cannot test those drivers on other than LE hardware. I do not have the hardware either for the RTL8723AU. For that reason, I am careful when modifying the driver - I let Jes do that. Silly me. 'U' stands for USB here. But can't find this device on any auction. It's included in some ultrabooks but can't afford that for the sake of fixing some sparse warnings :) There are no stand-alone USB devices that I have found for either RTL8723AU or RTL8723BU. The closest are modules CM-8723U and CM-8723BU by CC&C (http://www.ccandc.com.tw/) with RTL8723AU and RTL8723BU, respectively. The former is obsolete and no longer on the web site. These modules have D+ and D- connectors for USB, but they take 3.3 V, not 5. As a result, one would need some sort of voltage regulator circuit. That would not be complicated as it would consist of a TI LM2937-3.3 and a couple of capacitors. I wrote to them to see if I could get samples, but no response yet. To be able to fix the kernel driver for RTL8188EU on PPC, I need to sort out these endian problems. Once I do, I will port them to the other drivers. Isn't `sparse` useful here? :) Yes, but the git repo works, and the kernel version does not, even though both do not have any Sparse warhings. Larry -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Core block IO bits for 3.19
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 Avanzini. - Various updates/fixes/improvements for blk-mq: - A set of updates from Bart, mostly fixing buts in the tag handling. - Cleanup/code consolidation from Christoph. - Extend queue_rq API to be able to handle batching issues of IO requests. NVMe will utilize this shortly. From me. - A few tag and request handling updates from me. - Cleanup of the preempt handling for running queues from Paolo. - Prevent running of unmapped hardware queues from Ming Lei. - Move the kdump memory limiting check to be in the correct location, from Shaohua. - Initialize all software queues at init time from Takashi. This prevents a kobject warning when CPUs are brought online that weren't online when a queue was registered. - Single writeback fix for I_DIRTY clearing from Tejun. Queued with the core IO changes, since it's just a single fix. - Version X of the __bio_add_page() segment addition retry from Maurizio. Hope the Xth time is the charm. - Documentation fixup for IO scheduler merging from Jan. - Introduce (and use) generic IO stat accounting helpers for non-rq drivers, from Gu Zheng. - Kill off artificial limiting of max sectors in a request from Christoph. Please pull! git://git.kernel.dk/linux-block.git for-3.19/core Arianna Avanzini (1): blktrace: don't let the sysfs interface remove trace from running list Bart Van Assche (6): blk-mq: fix hang in bt_get() blk-mq: Fix a use-after-free blk-mq: Avoid that __bt_get_word() wraps multiple times blk-mq: Fix a race between bt_clear_tag() and bt_get() blk-mq: Micro-optimize bt_get() blk-mq: Use all available hardware queues Christoph Hellwig (2): block: remove artifical max_hw_sectors cap blk-mq: handle the single queue case in blk_mq_hctx_next_cpu Gu Zheng (1): blk: introduce generic io stat accounting help function Jan Kara (1): block: Expand a bit documentation about elevator_allow_merge_fn Jens Axboe (8): blk-mq: add a 'list' parameter to ->queue_rq() blk-mq: add BLK_MQ_F_DEFER_ISSUE support flag blk-mq: export blk_mq_free_request() blk-mq: add blk_mq_free_hctx_request() genhd: check for int overflow in disk_expand_part_tbl() blk-mq: use 'nr_cpu_ids' as highest CPU ID count for hwq <-> cpu map blk-mq: cleanup tag free handling blk-mq: re-check for available tags after running the hardware queue Maurizio Lombardi (1): bio: modify __bio_add_page() to accept pages that don't start a new segment Ming Lei (1): blk-mq: prevent unmapped hw queue from being scheduled Paolo Bonzini (2): blk_mq: call preempt_disable/enable in blk_mq_run_hw_queue, and only if needed blk-mq: use get_cpu/put_cpu instead of preempt_disable/preempt_enable Shaohua Li (1): blk-mq: move the kdump check to blk_mq_alloc_tag_set Takashi Iwai (1): blk-mq: Fix uninitialized kobject at CPU hotplugging Tejun Heo (1): writeback: fix a subtle race condition in I_DIRTY clearing Documentation/block/biodoc.txt| 6 +- block/bio.c | 82 + block/blk-core.c | 3 + block/blk-mq-cpumap.c | 4 +- block/blk-mq-sysfs.c | 9 ++- block/blk-mq-tag.c| 60 +- block/blk-mq.c| 126 -- block/blk-mq.h| 5 ++ block/blk-settings.c | 4 +- block/blk-sysfs.c | 12 ++-- block/genhd.c | 11 +++- drivers/block/aoe/aoeblk.c| 2 +- drivers/block/mtip32xx/mtip32xx.c | 5 +- drivers/block/null_blk.c | 10 +-- drivers/block/virtio_blk.c| 7 ++- drivers/scsi/scsi_lib.c | 5 +- fs/fs-writeback.c | 29 ++--- include/linux/bio.h | 5 ++ include/linux/blk-mq.h| 10 ++- include/linux/blkdev.h| 1 - kernel/trace/blktrace.c | 3 - 21 files changed, 254 insertions(+), 145 deletions(-) -- Jens Axboe -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PM / sleep: add configurable delay for pm_test
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
> steps, wait 5 seconds, and then resume back to normal operation.
>
> This mode is useful for (among other things) observing the state of the
> system just before entering a sleep mode, for debugging or analysis
> purposes. However, a constant 5 second wait is not sufficient for some
> sorts of analysis; for example, on an SoC, one might want to use
> external tools to probe the power states of various on-chip controllers
> or clocks.
>
> This patch adds a companion sysfs file (/sys/power/pm_test_delay) that
> allows user-space to configure how long the system waits in this test
> state before resuming. It also updates the PM debugging documentation to
> mention the new file.
>
> Signed-off-by: Brian Norris
What do you think about this patch? It seems there is at least one other
developer who is independently interested in this.
Thanks,
Brian
> ---
> Documentation/power/basic-pm-debugging.txt | 14 --
> kernel/power/main.c| 27 +++
> kernel/power/power.h | 5 +
> kernel/power/suspend.c | 8 ++--
> 4 files changed, 46 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/power/basic-pm-debugging.txt
> b/Documentation/power/basic-pm-debugging.txt
> index edeecd447d23..bd9f27ae99fe 100644
> --- a/Documentation/power/basic-pm-debugging.txt
> +++ b/Documentation/power/basic-pm-debugging.txt
> @@ -75,12 +75,14 @@ you should do the following:
> # echo platform > /sys/power/disk
> # echo disk > /sys/power/state
>
> -Then, the kernel will try to freeze processes, suspend devices, wait 5
> seconds,
> -resume devices and thaw processes. If "platform" is written to
> -/sys/power/pm_test , then after suspending devices the kernel will
> additionally
> -invoke the global control methods (eg. ACPI global control methods) used to
> -prepare the platform firmware for hibernation. Next, it will wait 5 seconds
> and
> -invoke the platform (eg. ACPI) global methods used to cancel hibernation etc.
> +Then, the kernel will try to freeze processes, suspend devices, wait a few
> +seconds (5 by default, but configurable via /sys/power/pm_test_delay), resume
> +devices and thaw processes. If "platform" is written to /sys/power/pm_test,
> +then after suspending devices the kernel will additionally invoke the global
> +control methods (eg. ACPI global control methods) used to prepare the
> platform
> +firmware for hibernation. Next, it will wait a configurable number of
> seconds
> +and invoke the platform (eg. ACPI) global methods used to cancel hibernation
> +etc.
>
> Writing "none" to /sys/power/pm_test causes the kernel to switch to the
> normal
> hibernation/suspend operations. Also, when open for reading,
> /sys/power/pm_test
> diff --git a/kernel/power/main.c b/kernel/power/main.c
> index 9a59d042ea84..4d242c8b43a0 100644
> --- a/kernel/power/main.c
> +++ b/kernel/power/main.c
> @@ -73,6 +73,7 @@ power_attr(pm_async);
>
> #ifdef CONFIG_PM_DEBUG
> int pm_test_level = TEST_NONE;
> +int pm_test_seconds = PM_TEST_DELAY_DEFAULT;
>
> static const char * const pm_tests[__TEST_AFTER_LAST] = {
> [TEST_NONE] = "none",
> @@ -132,6 +133,31 @@ static ssize_t pm_test_store(struct kobject *kobj,
> struct kobj_attribute *attr,
> }
>
> power_attr(pm_test);
> +
> +static ssize_t pm_test_delay_show(struct kobject *kobj,
> + struct kobj_attribute *attr, char *buf)
> +{
> + return sprintf(buf, "%d\n", pm_test_seconds);
> +}
> +
> +static ssize_t pm_test_delay_store(struct kobject *kobj,
> +struct kobj_attribute *attr,
> +const char *buf, size_t n)
> +{
> + int val;
> +
> + if (kstrtoint(buf, 10, &val))
> + return -EINVAL;
> +
> + if (val < 0)
> + return -EINVAL;
> +
> + pm_test_seconds = val;
> +
> + return n;
> +}
> +
> +power_attr(pm_test_delay);
> #endif /* CONFIG_PM_DEBUG */
>
> #ifdef CONFIG_DEBUG_FS
> @@ -601,6 +627,7 @@ static struct attribute * g[] = {
> #endif
> #ifdef CONFIG_PM_DEBUG
> &pm_test_attr.attr,
> + &pm_test_delay_attr.attr,
> #endif
> #ifdef CONFIG_PM_SLEEP_DEBUG
> &pm_print_times_attr.attr,
> diff --git a/kernel/power/power.h b/kernel/power/power.h
> index 5d49dcac2537..28111795da71 100644
> --- a/kernel/power/power.h
> +++ b/kernel/power/power.h
> @@ -230,6 +230,11 @@ enum {
>
> extern int pm_test_level;
>
> +/* Default to 5 second delay */
> +#define PM_TEST_DELAY_DEFAULT5
> +
> +extern int pm_test_seconds;
> +
> #ifdef CONFIG_SUSPEND_FREEZER
> static inline int suspend_freeze_processes(
Re: frequent lockups in 3.18rc4
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 > number of regular files open and being used on the trinity loads can > be almost arbitrarily large. > > Where do those files get opened? What filesystem? in the cwd where trinity is run from. In my case, ext4 > > I've been running trinity f2be2d5ff^ on -next for two hours now, and > > there's > > no sign of a lockup. Previously it took ~10 minutes trigger. > > DaveJ? Is there anything limiting the size of those files? Nope. We could for eg, do a random truncate() with a huge size, and it would try and create something enormous. write()'s are limited to page size, there might be some other syscalls I haven't added safety guards to. Dave -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/2] watchdog: Add driver for Mediatek watchdog
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 ++
> drivers/watchdog/Makefile | 1 +
> drivers/watchdog/mtk_wdt.c | 257
> +
> 3 files changed, 268 insertions(+)
> create mode 100644 drivers/watchdog/mtk_wdt.c
>
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index d0107d4..fcbca1b 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -505,6 +505,16 @@ config MESON_WATCHDOG
> To compile this driver as a module, choose M here: the
> module will be called meson_wdt.
>
> +config MEDIATEK_WATCHDOG
> + tristate "Mediatek SoCs watchdog support"
> + depends on ARCH_MEDIATEK
> + select WATCHDOG_CORE
> + help
> + Say Y here to include support for the watchdog timer
> + in Mediatek SoCs.
> + To compile this driver as a module, choose M here: the
> + module will be called mtk_wdt.
> +
> # AVR32 Architecture
>
> config AT32AP700X_WDT
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index c569ec8..0d4821f 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -63,6 +63,7 @@ obj-$(CONFIG_QCOM_WDT) += qcom-wdt.o
> obj-$(CONFIG_BCM_KONA_WDT) += bcm_kona_wdt.o
> obj-$(CONFIG_TEGRA_WATCHDOG) += tegra_wdt.o
> obj-$(CONFIG_MESON_WATCHDOG) += meson_wdt.o
> +obj-$(CONFIG_MEDIATEK_WATCHDOG) += mtk_wdt.o
>
> # AVR32 Architecture
> obj-$(CONFIG_AT32AP700X_WDT) += at32ap700x_wdt.o
> diff --git a/drivers/watchdog/mtk_wdt.c b/drivers/watchdog/mtk_wdt.c
> new file mode 100644
> index 000..5f75442
> --- /dev/null
> +++ b/drivers/watchdog/mtk_wdt.c
> @@ -0,0 +1,257 @@
> +/*
> + * Mediatek Watchdog Driver
> + *
> + * Copyright (C) 2014 Matthias Brugger
> + *
> + * Matthias Brugger
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * Based on mtk_wdt.c
Did you base your code on itself from the future? :)
ChenYu
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define WDT_MAX_TIMEOUT31
> +#define WDT_MIN_TIMEOUT1
> +#define WDT_LENGTH_TIMEOUT(n) ((n) << 5)
> +
> +#define WDT_LENGTH 0x04
> +#define WDT_LENGTH_KEY 0x8
> +
> +#define WDT_RST0x08
> +#define WDT_RST_RELOAD 0x1971
> +
> +#define WDT_MODE 0x00
> +#define WDT_MODE_EN(1 << 0)
> +#define WDT_MODE_EXT_POL_LOW (0 << 1)
> +#define WDT_MODE_EXT_POL_HIGH (1 << 1)
> +#define WDT_MODE_EXRST_EN (1 << 2)
> +#define WDT_MODE_IRQ_EN(1 << 3)
> +#define WDT_MODE_AUTO_START(1 << 4)
> +#define WDT_MODE_DUAL_EN (1 << 6)
> +#define WDT_MODE_KEY 0x2200
> +
> +#define WDT_SWRST 0x14
> +#define WDT_SWRST_KEY 0x1209
> +
> +#define DRV_NAME "mtk-wdt"
> +#define DRV_VERSION"1.0"
> +
> +static bool nowayout = WATCHDOG_NOWAYOUT;
> +static unsigned int timeout = WDT_MAX_TIMEOUT;
> +
> +struct mtk_wdt_dev {
> + struct watchdog_device wdt_dev;
> + void __iomem *wdt_base;
> + struct notifier_block restart_handler;
> +};
> +
> +static int mtk_reset_handler(struct notifier_block *this, unsigned long mode,
> + void *cmd)
> +{
> + struct mtk_wdt_dev *mtk_wdt = container_of(this,
> + struct mtk_wdt_dev,
> + restart_handler);
> + void __iomem *wdt_base = mtk_wdt->wdt_base;
> + u32 reg;
> +
> + /* Reset system */
> + writel(WDT_SWRST_KEY, wdt_base + WDT_SWRST);
> +
> + while (1) {
> + mdelay(5);
> + writel(WDT_SWRST_KEY, wdt_base + WDT_SWRST);
> + }
> + return NOTIFY_DONE;
> +
> +}
> +
> +static int mtk_wdt_ping(struct watchdog_device *wdt_dev)
> +{
> + struct mtk_wdt_dev *mtk_wdt = watchdog_get_drvdata(wdt_dev);
> + void __iomem *wdt_base = mtk_wdt->wdt_base;
> +
> + iowrite32(WDT_RST_RELOAD, wdt_base + WDT_RST);
> +
> + return 0;
> +}
> +
> +static int mtk_wdt_se
Re: [PATCHv3 5/5] ARM: sunxi: dts: Add note ps2 pins conflict with hdmi
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: VishnuPatekar
> ---
> arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts |6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> index ed364d5..951b615 100644
> --- a/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> +++ b/arch/arm/boot/dts/sun7i-a20-olinuxino-lime2.dts
> @@ -112,7 +112,11 @@
> pinctrl-0 = <&uart0_pins_a>;
> status = "okay";
> };
> -
> +
> + /* PS2 0 and PS2 1 are disabled by default; Please note that
> + ps20 pins conflict with HDMI on Lime2 Board
> + */
> +
Multi-line comments should be:
/*
* line 1
* line 2
* ...
*/
And why is there a delete and insert for an empty line?
Weird... though git seems to ignore it when applying.
ChenYu
> i2c0: i2c@01c2ac00 {
> pinctrl-names = "default";
> pinctrl-0 = <&i2c0_pins_a>;
> --
> 1.7.9.5
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/3] ARM: tegra: dts: remove unused irq-trigger entry
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
--- a/arch/arm/boot/dts/tegra30-apalis.dtsi
+++ b/arch/arm/boot/dts/tegra30-apalis.dtsi
@@ -540,7 +540,6 @@
interrupt-controller;
id = <0>;
blocks = <0x5>;
- irq-trigger = <0x1>;
stmpe_touchscreen {
compatible = "st,stmpe-ts";
--
2.1.3
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/3] removing of some unused/unsupported dts entries
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 entry ARM: tegra: dts: remove unused irq-trigger entry ARM: SPEAr: dts: remove unused irq-trigger, id and block entries arch/arm/boot/dts/imx53-m53.dtsi | 1 - arch/arm/boot/dts/spear1310-evb.dts | 1 - arch/arm/boot/dts/spear1340-evb.dts | 2 -- arch/arm/boot/dts/spear320-hmi.dts| 3 --- arch/arm/boot/dts/tegra30-apalis.dtsi | 1 - 5 files changed, 8 deletions(-) -- 2.1.3 -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/3] ARM: SPEAr: dts: remove unused irq-trigger, id and block entries
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 a/arch/arm/boot/dts/spear1310-evb.dts
b/arch/arm/boot/dts/spear1310-evb.dts
index d42c84b..95c2ff1 100644
--- a/arch/arm/boot/dts/spear1310-evb.dts
+++ b/arch/arm/boot/dts/spear1310-evb.dts
@@ -369,7 +369,6 @@
pl022,duplex = <0>;
interrupts = <6 0x4>;
interrupt-parent = <&gpio1>;
- irq-trigger = <0x2>;
stmpe_touchscreen {
compatible = "st,stmpe-ts";
diff --git a/arch/arm/boot/dts/spear1340-evb.dts
b/arch/arm/boot/dts/spear1340-evb.dts
index b23e05e..bba3389 100644
--- a/arch/arm/boot/dts/spear1340-evb.dts
+++ b/arch/arm/boot/dts/spear1340-evb.dts
@@ -325,7 +325,6 @@
reg = <0x41>;
interrupts = <4 0x4>;
interrupt-parent = <&gpio0>;
- irq-trigger = <0x2>;
stmpegpio: stmpe_gpio {
compatible = "st,stmpe-gpio";
@@ -478,7 +477,6 @@
pl022,duplex = <0>;
interrupts = <100 0>;
interrupt-parent = <&gpiopinctrl>;
- irq-trigger = <0x2>;
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/spear320-hmi.dts
b/arch/arm/boot/dts/spear320-hmi.dts
index 0aa6fef..f8ed01e 100644
--- a/arch/arm/boot/dts/spear320-hmi.dts
+++ b/arch/arm/boot/dts/spear320-hmi.dts
@@ -243,9 +243,6 @@
reg = <0x41>;
irq-over-gpio;
irq-gpios = <&gpiopinctrl 29 0x4>;
- id = <0>;
- blocks = <0x5>;
- irq-trigger = <0x1>;
stmpegpio: stmpe-gpio {
compatible = "stmpe,gpio";
--
2.1.3
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] ARM: mx5: dts: remove unused irq-trigger entry
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
--- a/arch/arm/boot/dts/imx53-m53.dtsi
+++ b/arch/arm/boot/dts/imx53-m53.dtsi
@@ -60,7 +60,6 @@
blocks = <0x5>;
interrupts = <6 0x0>;
interrupt-parent = <&gpio7>;
- irq-trigger = <0x1>;
stmpe_touchscreen {
compatible = "st,stmpe-ts";
--
2.1.3
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/8] x86, mpx: Support 32-bit binaries on 64-bit kernels
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 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
>>> explicitly, but I did do a substantial amount of testing throwing random
>>> instruction streams at the decoder to make sure it never fell over.
>>> (Well, mostly random, I made sure to throw the MPX opcodes in there a
>>> bunch so it would get much deeper in to the decoder).
>>>
>>> It's not about the instruction size, it's about the mode the CPU is in.
>>> If a 32-bit app manages to switch over to 64-bit mode and doesn't tell
>>> the kernel (TIF_IA32 remains set), then we'll treat it as a 32-bit
>>> instruction.
>>
>> The insn decoder should probably use user_64bit_mode, not TIF_IA32.
>> It's actually quite easy to far jump/call/ret or sigreturn to a
>> different bitness.
>
> There are number of examples of this in the kernel today:
>
> #ifdef CONFIG_X86_64
> is_64bit = kernel_ip(to) || !test_thread_flag(TIF_IA32);
> #endif
> insn_init(&insn, kaddr, size, is_64bit);
>
> Are you saying that those need to get fixed up?
>
Yes, although so far it looks like the only real danger with them is
that userspace could shoot itself in the foot.
>>> The kernel might end up going and looking for the bounds tables in some
>>> funky places if the kernel and the hardware disagree about 32 vs. 64-bit
>>> modes, but it's not going to do any harm since we treat all of the data
>>> we get from MPX (instruction decoding, register contents, bounds table
>>> contents, etc...) as completely untrusted.
>>>
>>> It's a nice, paranoid thing to ask and I'm glad you brought it up
>>> because I hadn't thought about it, but I don't think any harm can come
>>> of it.
>>
>> Paranoia is fun!
>>
>> The only thing I'd really be worried about is if the code that turns
>> va into bounds table offset generates some absurdly large offset as a
>> result and causes a problem.
>
> The instructions that get decoded have *NOTHING* to do with the mode
> we're running in. By the time we take a bounds fault and copy the
> instruction in from the instruction pointer, we have absolutely no idea
> what was actually being executed, no matter what mode we are running in.
>
> I believe the instruction decoder already happily handles this.
>
> Furthermore, we don't even *USE* the result of the instruction decode in
> the kernel. We toss it in to the siginfo and hand it out to userspace.
Hmm. I may have confused myself.
I was thinking of this:
+ if (is_64bit_mm(mm)) {
+ vaddr_space_size = 1ULL << __VIRTUAL_MASK_SHIFT;
+ bd_entry_virt_space = vaddr_space_size / MPX_BD_NR_ENTRIES_64;
+ /*
+ * __VIRTUAL_MASK takes the 64-bit addressing hole
+ * in to accout. This is a noop on 32-bit.
+ */
+ addr &= __VIRTUAL_MASK;
+ return addr / bd_entry_virt_space;
+ } else {
+ vaddr_space_size = (1ULL << 32);
+ bd_entry_virt_space = vaddr_space_size / MPX_BD_NR_ENTRIES_32;
+ return addr / bd_entry_virt_space;
+ }
Is there a scenario in which the return value ends up being insanely
high? If so, does it matter?
--Andy
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Resend][PATCH] tracing / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
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 > if CONFIG_PM is set. > > Replace CONFIG_PM_RUNTIME with CONFIG_PM in kernel/trace/Makefile > for this reason. > > Signed-off-by: Rafael J. Wysocki > --- > > Please let me know if there are any objections against this. If not, I'll > take it through the linux-pm tree, as I'm going to remove CONFIG_PM_RUNTIME > entirely shortly. Feel free to take it. Acked-by: Steven Rostedt > --- > kernel/trace/Makefile |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > Index: linux-pm/kernel/trace/Makefile > === > --- linux-pm.orig/kernel/trace/Makefile > +++ linux-pm/kernel/trace/Makefile > @@ -55,7 +55,7 @@ obj-$(CONFIG_EVENT_TRACING) += trace_eve > obj-$(CONFIG_EVENT_TRACING) += trace_events_trigger.o > obj-$(CONFIG_KPROBE_EVENT) += trace_kprobe.o > obj-$(CONFIG_TRACEPOINTS) += power-traces.o > -ifeq ($(CONFIG_PM_RUNTIME),y) > +ifeq ($(CONFIG_PM),y) > obj-$(CONFIG_TRACEPOINTS) += rpm-traces.o > endif > ifeq ($(CONFIG_TRACING),y) -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[Resend][PATCH] power / PM: Eliminate CONFIG_PM_RUNTIME
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 drivers/power/pm2301_charger.c.
Signed-off-by: Rafael J. Wysocki
---
Please let me know if there are any objections against this. If not, I'll
take it through the linux-pm tree, as I'm going to remove CONFIG_PM_RUNTIME
entirely shortly.
---
drivers/power/pm2301_charger.c |4
1 file changed, 4 deletions(-)
Index: linux-pm/drivers/power/pm2301_charger.c
===
--- linux-pm.orig/drivers/power/pm2301_charger.c
+++ linux-pm/drivers/power/pm2301_charger.c
@@ -951,8 +951,6 @@ static int pm2xxx_wall_charger_suspend(s
#endif
-#ifdef CONFIG_PM_RUNTIME
-
static int pm2xxx_runtime_suspend(struct device *dev)
{
struct i2c_client *pm2xxx_i2c_client = to_i2c_client(dev);
@@ -977,8 +975,6 @@ static int pm2xxx_runtime_resume(struct
return 0;
}
-#endif
-
static const struct dev_pm_ops pm2xxx_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(pm2xxx_wall_charger_suspend,
pm2xxx_wall_charger_resume)
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Resend][PATCH] NFC / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
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.
Replace CONFIG_PM_RUNTIME with CONFIG_PM in drivers/nfc/trf7970a.c.
Signed-off-by: Rafael J. Wysocki
---
Please let me know if there are any objections against this. If not, I'll
take it through the linux-pm tree, as I'm going to remove CONFIG_PM_RUNTIME
entirely shortly.
---
drivers/nfc/trf7970a.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: linux-pm/drivers/nfc/trf7970a.c
===
--- linux-pm.orig/drivers/nfc/trf7970a.c
+++ linux-pm/drivers/nfc/trf7970a.c
@@ -2154,7 +2154,7 @@ static int trf7970a_resume(struct device
}
#endif
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
static int trf7970a_pm_runtime_suspend(struct device *dev)
{
struct spi_device *spi = container_of(dev, struct spi_device, dev);
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Resend][PATCH] tracing / PM: Replace CONFIG_PM_RUNTIME with 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 kernel/trace/Makefile for this reason. Signed-off-by: Rafael J. Wysocki --- Please let me know if there are any objections against this. If not, I'll take it through the linux-pm tree, as I'm going to remove CONFIG_PM_RUNTIME entirely shortly. --- kernel/trace/Makefile |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux-pm/kernel/trace/Makefile === --- linux-pm.orig/kernel/trace/Makefile +++ linux-pm/kernel/trace/Makefile @@ -55,7 +55,7 @@ obj-$(CONFIG_EVENT_TRACING) += trace_eve obj-$(CONFIG_EVENT_TRACING) += trace_events_trigger.o obj-$(CONFIG_KPROBE_EVENT) += trace_kprobe.o obj-$(CONFIG_TRACEPOINTS) += power-traces.o -ifeq ($(CONFIG_PM_RUNTIME),y) +ifeq ($(CONFIG_PM),y) obj-$(CONFIG_TRACEPOINTS) += rpm-traces.o endif ifeq ($(CONFIG_TRACING),y) -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH, untested] Fix off-by-one in tps_comparators[] access
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 'tps_comparators[2]'
accessed at index 2, which is out of bounds.
Signed-off-by: Thomas Jarosch
---
drivers/mfd/tps65911-comparator.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/mfd/tps65911-comparator.c
b/drivers/mfd/tps65911-comparator.c
index c0816eb..e8c2e32 100644
--- a/drivers/mfd/tps65911-comparator.c
+++ b/drivers/mfd/tps65911-comparator.c
@@ -58,13 +58,14 @@ static struct comparator tps_comparators[] = {
static int comp_threshold_set(struct tps65910 *tps65910, int id, int voltage)
{
- struct comparator tps_comp = tps_comparators[id];
+ struct comparator tps_comp;
int curr_voltage = 0;
int ret;
u8 index = 0, val;
- if (id == COMP)
+ if (id == COMP || id > COMP2)
return 0;
+ tps_comp = tps_comparators[id-1];
while (curr_voltage < tps_comp.uV_max) {
curr_voltage = tps_comp.vsel_table[index];
@@ -85,12 +86,13 @@ static int comp_threshold_set(struct tps65910 *tps65910,
int id, int voltage)
static int comp_threshold_get(struct tps65910 *tps65910, int id)
{
- struct comparator tps_comp = tps_comparators[id];
+ struct comparator tps_comp;
int ret;
u8 val;
- if (id == COMP)
+ if (id == COMP || id > COMP2)
return 0;
+ tps_comp = tps_comparators[id-1];
ret = tps65910->read(tps65910, tps_comp.reg, 1, &val);
if (ret < 0)
--
1.9.3
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[staging PATCH] Add missing va_end() call
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
--- a/drivers/staging/unisys/uislib/uisutils.c
+++ b/drivers/staging/unisys/uislib/uisutils.c
@@ -59,6 +59,7 @@ uisutil_add_proc_line_ex(int *total, char **buffer, int
*buffer_remaining,
DBGINF("buffer = 0x%p : *buffer = 0x%p.\n", buffer, *buffer);
va_start(args, format);
len = vsnprintf(*buffer, *buffer_remaining, format, args);
+ va_end(args);
if (len >= *buffer_remaining) {
*buffer += *buffer_remaining;
*total += *buffer_remaining;
--
1.9.3
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
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 trouble is about something like tmpfs eating tons of memory when trinity starts doing random system calls on those files". I was also thinking that some of it might be filesystem-specific. We already *did* see one trace where it was in the loop getting virtio channel data. Maybe it's actually possible to overwhelm the 9p filesystem exactly because the backing store is tmpfs, and basically have a CPU 100% busy handling ring events from the virtual filesystem.. But I'm just flailing.. Linus -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] MAINTAINERS: Add me as x86 vdso maintainer
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 @@ L: linux-e...@vger.kernel.org S: Maintained F: arch/x86/kernel/cpu/mcheck/* +X86 VDSO +M: Andy Lutomirski +L: linux-kernel@vger.kernel.org +T: git git://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git x86/vdso +S: Maintained +F: arch/x86/vdso/ + XC2028/3028 TUNER DRIVER M: Mauro Carvalho Chehab L: linux-me...@vger.kernel.org -- 2.1.0 -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
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 open and being used on the trinity loads can > be almost arbitrarily large. > > Where do those files get opened? What filesystem? 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. Thanks, Sasha -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] MAINTAINERS: Add me as x86 vdso maintainer
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: Maintained F: arch/x86/kernel/cpu/mcheck/* +X86 VDSO +M: Andy Lutomirski +L: linux-kernel@vger.kernel.org +T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/vdso +S: Maintained +F: arch/x86/vdso/ + XC2028/3028 TUNER DRIVER M: Mauro Carvalho Chehab L: linux-me...@vger.kernel.org -- 2.1.0 -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/8] x86, mpx: Support 32-bit binaries on 64-bit kernels
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 >>> okay, but I might have missed something. >> >> You mean in the instruction decoder? I haven't tried that case >> explicitly, but I did do a substantial amount of testing throwing random >> instruction streams at the decoder to make sure it never fell over. >> (Well, mostly random, I made sure to throw the MPX opcodes in there a >> bunch so it would get much deeper in to the decoder). >> >> It's not about the instruction size, it's about the mode the CPU is in. >> If a 32-bit app manages to switch over to 64-bit mode and doesn't tell >> the kernel (TIF_IA32 remains set), then we'll treat it as a 32-bit >> instruction. > > The insn decoder should probably use user_64bit_mode, not TIF_IA32. > It's actually quite easy to far jump/call/ret or sigreturn to a > different bitness. There are number of examples of this in the kernel today: #ifdef CONFIG_X86_64 is_64bit = kernel_ip(to) || !test_thread_flag(TIF_IA32); #endif insn_init(&insn, kaddr, size, is_64bit); Are you saying that those need to get fixed up? >> The kernel might end up going and looking for the bounds tables in some >> funky places if the kernel and the hardware disagree about 32 vs. 64-bit >> modes, but it's not going to do any harm since we treat all of the data >> we get from MPX (instruction decoding, register contents, bounds table >> contents, etc...) as completely untrusted. >> >> It's a nice, paranoid thing to ask and I'm glad you brought it up >> because I hadn't thought about it, but I don't think any harm can come >> of it. > > Paranoia is fun! > > The only thing I'd really be worried about is if the code that turns > va into bounds table offset generates some absurdly large offset as a > result and causes a problem. The instructions that get decoded have *NOTHING* to do with the mode we're running in. By the time we take a bounds fault and copy the instruction in from the instruction pointer, we have absolutely no idea what was actually being executed, no matter what mode we are running in. I believe the instruction decoder already happily handles this. Furthermore, we don't even *USE* the result of the instruction decode in the kernel. We toss it in to the siginfo and hand it out to userspace. -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
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 arbitrarily large. Where do those files get opened? What filesystem? That might actually explain your and DaveJ's big differences: you are running in virtualization, and I remember some 9p traces with virtio etc from your reports. While DaveJ obviously runs on bare hardware, possibly on /tmp and tmpfs? > I've been running trinity f2be2d5ff^ on -next for two hours now, and there's > no sign of a lockup. Previously it took ~10 minutes trigger. DaveJ? Is there anything limiting the size of those files? Linus -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 2/5] phy: add a driver for the Rockchip SoC internal USB2.0 PHY
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 (general register files)
> module.
>
> Signed-off-by: Yunzhi Li
>
> ---
>
> Changes in v7:
> - Accept Kishon's comments to use phandle args to find a phy
> struct directly and get rid of using a custom of_xlate
> function.
I'm going to assume you didn't test this version, since it doesn't
work for me. At suspend time power is high and my printouts in the
powerup/powerdown code aren't called...
> + for_each_available_child_of_node(dev->of_node, child) {
> + rk_phy = devm_kzalloc(dev, sizeof(*rk_phy), GFP_KERNEL);
> + if (!rk_phy)
> + return -ENOMEM;
> +
> + if (of_property_read_u32(child, "reg", ®_offset)) {
> + dev_err(dev, "missing reg property in node %s\n",
> + child->name);
> + return -EINVAL;
> + }
> +
> + rk_phy->reg_offset = reg_offset;
> + rk_phy->reg_base = grf;
> +
> + rk_phy->clk = of_clk_get_by_name(child, "phyclk");
> + if (IS_ERR(rk_phy->clk))
> + rk_phy->clk = NULL;
> +
> + rk_phy->phy = devm_phy_create(dev, child, &ops);
> + if (IS_ERR(rk_phy->phy)) {
> + dev_err(dev, "failed to create PHY\n");
> + return PTR_ERR(rk_phy->phy);
> + }
> + phy_set_drvdata(rk_phy->phy, rk_phy);
> + }
> +
> + phy_provider = devm_of_phy_provider_register(dev,
> of_phy_simple_xlate);
I think your bug is here. I think you now need to register 3 phy
providers, not just one.
I'll continue to assert my utter noviceness with this code, but my
attempt at a solution (which works) can be found at:
https://chromium-review.googlesource.com/235456
-Doug
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: Really fix deadlock with mmap_sem
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 was trying > to fix. Actually fix it by moving the debugfs creation outside > the prepare_lock. > > Reported-by: Russell King - ARM Linux > Fixes: 6314b6796e3c "clk: Don't hold prepare_lock across debugfs creation" > Signed-off-by: Stephen Boyd > + lockdep_assert_held(clk_debug_lock); That change is not mentioned in the changelog and seems to be unrelated to the issue at hand. Other than that: Reviewed-by: Thomas Gleixner -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/8] x86, mpx: Support 32-bit binaries on 64-bit kernels
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 mean in the instruction decoder? I haven't tried that case > explicitly, but I did do a substantial amount of testing throwing random > instruction streams at the decoder to make sure it never fell over. > (Well, mostly random, I made sure to throw the MPX opcodes in there a > bunch so it would get much deeper in to the decoder). > > It's not about the instruction size, it's about the mode the CPU is in. > If a 32-bit app manages to switch over to 64-bit mode and doesn't tell > the kernel (TIF_IA32 remains set), then we'll treat it as a 32-bit > instruction. The insn decoder should probably use user_64bit_mode, not TIF_IA32. It's actually quite easy to far jump/call/ret or sigreturn to a different bitness. > > The kernel might end up going and looking for the bounds tables in some > funky places if the kernel and the hardware disagree about 32 vs. 64-bit > modes, but it's not going to do any harm since we treat all of the data > we get from MPX (instruction decoding, register contents, bounds table > contents, etc...) as completely untrusted. > > It's a nice, paranoid thing to ask and I'm glad you brought it up > because I hadn't thought about it, but I don't think any harm can come > of it. Paranoia is fun! The only thing I'd really be worried about is if the code that turns va into bounds table offset generates some absurdly large offset as a result and causes a problem. --Andy -- Andy Lutomirski AMA Capital Management, LLC -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] multi-layer support for overlay filesystem
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 if (!ovl_is_allowed_fs_type(path->dentry))
> pr_err("overlayfs: filesystem on '%s' not supported\n", name);
> else if (!S_ISDIR(path->dentry->d_inode->i_mode))
> pr_err("overlayfs: '%s' not a directory\n", name);
> else
> err = 0;
> the fourth alternative is completely pointless and both the second and the
> third leave you with err being zero.
Fixed.
>
> That opens all kinds of unpleasant holes, obviously. If you fix that by
> setting err in the 2nd and thr 3rd alternatives, you get the next problem -
> leaks on such failures. Suppose the first ovl_mount_dir() call fails on
> those checks. You go to out_free_config and voila - upperpath has leaked.
> The same in the second call means leaked workpath. And those failures in
> ovl_lower_dir(), as well as failures of vfs_getattr() there, end up leaking
> vfsmount/dentry in stack[...].
Fixed.
>
> Next piece of fun: suppose you have in one of the lower layers a filesystem
> with ->lookup()-enforced upper limit on name length. Pretty much every
> local fs has one, but... they are not all equal. 255 characters is the
> common upper limit, but e.g. jffs2 stops at 254, minixfs upper limit is
> somewhere from 14 to 60, depending upon version, etc. You are doing a lookup
> for something that is present in upper layer, but happens to be too long for
> one of the lower layers. Too bad - ENAMETOOLONG for you...
Fixed.
>
> BTW, that sucker really needs cleaning up. I seriously suspect that
> quite a few conditions in there might be redundant, but after several
> hours of staring at it I'm still not sure that I hadn't missed some
> paths in there ;-/ AFAICS, it would get cleaner if you unrolled the idx == 0
> pass out of that loop - as in "deal with ovl_path_upper() if present, then
> simple for (lower = 0; lower < oe->numlower; lower++)". TBH, ovl_path_next()
> seems to be a bad primitive for that use and the other caller doesn't give
> a damn about upper vs. lower, so I wonder if the games with reporting that
> make any sense. They certainly make ovl_path_next() much uglier...
Done cleanup.
>
> Another thing: in theory, you can get up to about 2000 (identical)
> single-letter names in lowerdirs. Resulting arrays of struct path (i.e.
> pairs of pointers) will make allocators unhappy - 32Kb kmalloc() is
> not nice. IMO that needs more or less sane limit enforced at mount time -
> relying on "mount data is at most one page, can't fit too much there"
> is not enough.
Fixed.
>
> Logics in ovl_dir_read_merged() looks odd - why is the lowermost one special
> and not the uppermost? BTW, what if you find a whiteout in the lowermost
> layer?
Yeah, it was supposed to be an optimization (no need to check for whiteouts on
lower, since whiteouts never exist on lower) and is present in the lookup code
as well.
I switched to checking whiteouts in lowest layer as well, for consitency.
> And while we are at it, what happens when the _upper_ layer is an
> overlayfs - how do you create whiteouts there? That, AFAICS, applies to
> the current mainline as well...
It really doesn't make sense to make upper layer an overlayfs. It won't work,
but it shouldn't crash. Should we blacklist it, so any such stupidity is found
out at mount time?
Fixes pushed to
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs-next
Thanks,
Miklos
---
Miklos Szeredi (15):
ovl: check whiteout while reading directory
ovl: make path-type a bitmap
ovl: dont replace opaque dir
ovl: add mutli-layer infrastructure
ovl: helper to iterate layers
ovl: multi-layer readdir
ovl: multi-layer lookup
ovl: check whiteout on lowest layer as well
ovl: lookup ENAMETOOLONG on lower means ENOENT
ovl: allow statfs if no upper layer
ovl: mount: change order of initialization
ovl: improve mount helpers
ovl: make upperdir optional
ovl: support multiple lower layers
ovl: add testsuite to docs
hujianyang (2):
ovl: Cleanup redundant blank lines
ovl: Use macros to present ovl_xattr
---
Documentation/filesystems/overlayfs.txt | 24 ++
fs/overlayfs/copy_up.c | 5 +-
fs/overlayfs/dir.c | 28 +-
fs/overlayfs/inode.c| 12 +-
fs/overlayfs/overlayfs.h| 18 +-
fs/overlayfs/readdir.c | 145 -
fs/overlayfs/super.c| 546 +---
7 files changed, 482 insertions(+), 296 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo
Re: [PATCH] hp_accel: Add support for HP ZBook 15
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 Leuenberger > >Cc: > >Signed-off-by: Takashi Iwai > Sorry, it got a be delayed... but it looks completely fine :-) > > Signed-off-by: Éric Piel > > Darren, would you wind picking up this patch via your tree? Yes, already in next. Thanks :-) -- Darren Hart Intel Open Source Technology Center -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: frequent lockups in 3.18rc4
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 commonalities, even if the actual symptoms then >> > differ. And while it looked different when you could trigger it with >> > 3.16 but DaveJ couldn't, that's up in the air now that I doubt that >> > 3.16 really is ok for DaveJ after all.. >> > >> > And you might have a better luck bisecting it, since you seem to be >> > able to trigger your RCU lockup much more quickly (and apparently >> > reliably? Correct?) > Right, and it reproduces in 3.10 as well, so it's not really a new thing. > > What's odd is that I don't remember seeing this bug so long in the past, > I'll try bisecting trinity rather than the kernel - it's the only other > thing that changed. So I checked out trinity from half a year ago, and could not reproduce the stall any more. Not on v3.16 nor on the current -next. I ran bisection on trinity, rather than the kernel, and got the following result: commit f2be2d5ffe4bf896eb5418972013822a2bef0cee Author: Dave Jones Date: Mon Aug 4 19:55:17 2014 -0400 begin some infrastructure to use a bunch of test files for fsx like ops. I've been running trinity f2be2d5ff^ on -next for two hours now, and there's no sign of a lockup. Previously it took ~10 minutes trigger. Thanks, Sasha -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: regression on rk3288 with - mmc: dw_mmc: Remove old card detect infrastructure
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 reproduce the issue is: > - boot into an initramfs > - insert card > - remove card > - boom > > It happens 100% of the time on the first removal of the card. > > > Bisecting the issue brought me to > > first bad commit > 6130e7a9c34d01afbd4e7e215846d1f2d70333bb > mmc: dw_mmc: Remove old card detect infrastructure > > and indeed if I revert this one, card ejection works again - also multiple > times in a row. Affected machine is a rk3288-evb-rk808 board which > currently uses the internal card-detect mechanism of the dw_mmc and > relevant git history (--oneline) is: > > 864de9b Revert "mmc: dw_mmc: Remove old card detect infrastructure" > 5bd48e0 ARM: dts: Bump SD card pin drive strength up on rk3288-evb > 12fd072 Add linux-next specific files for 20141210 > ... > > > I'll try to dig deeper, but if anybody has ideas beforehand I would also > be very glad. I tried to reproduce this on the same board on 20141211. I have a different bootloader, but I hope that doesn't matter? git describe next-20141211-1-gf8afbb8 $ git log --oneline next-20141211~.. f8afbb8 FROMLIST: ARM: dts: Bump SD card pin drive strength up on rk3288-evb 291ca61 Add linux-next specific files for 20141211 In inserted 3 different cards into the SD card slots (a micro UHS, an older micro one, and a full sized UHS). I inserted / ejected each one several times. Could it be a different set of kernel config options? That's about the best guess I can come up with... -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] ASoC: rt5677: add a platform config option for MICBIAS voltage
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 0/1/2/3 to set MICBIAS1 voltage to 1.476V/2.970V/1.242V/2.475V
>> +
>
> Why is this being specified as some magic number rather than using the
> voltage (or at least providing defines for the voltage) - this is going
> to do little to make the DT legible and...
>
>> +enum rt5677_micbias {
>> + RT5677_MICBIAS_1_476V = 0,
>> + RT5677_MICBIAS_2_970V = 1,
>> + RT5677_MICBIAS_1_242V = 2,
>> + RT5677_MICBIAS_2_475V = 3,
>> +};
>
> ...I see there are defined for platform data.
This patch adds both an entry to the platform data and a DT binding
for MICBIAS level selection. The 4 voltage options
(1.476V/2.970V/1.242V/2.475V) are the only ones supported by the codec
hardware, so it seems an enum is better than specifying the exact
voltage directly. I was following the two examples below:
Documentation/devicetree/bindings/sound/cs42l52.txt (cirrus,micbias-lvl)
Documentation/devicetree/bindings/sound/tlv320aic3x.txt (ai3x-micbias-vg)
I'm new to devicetree bindings. Is there something like an enum in DT?
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 00/50] linux: towards virtio-1 guest support
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 can be found in my tree, vhost-next branch. > Apologies for the lack of response on the vhost-scsi part of this series.. The partial conversion looks fine, and just a head up that I'll be spending time on this for v3.20 code to add proper any-layout -> virtio 1.0 spec support into vhost-scsi. Thank you, --nab -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Maintainer abuse
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 sending out patches and collecting feedback for a week at least is not really being respected, from my experience. Shit gets blasted out at the highest rate possible. Maybe lkml should have a git-send-email throttle. And I have the sneaking impression that a lot of people have not really understood what merge window means. > Yours grumpy And then they wonder why reviewers/maintainers are grumpy. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Increase maximum size of dmesg buffer to 16MB.
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 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 buffer is > >> sized large enough to hold the output. Set to 16MB which will hopefully > >> be large enough to handle a dump from any of our servers at this time. > >> > >> Signed-off-by: Nate Stahl > >> Signed-off-by: Vinson Lee > > > > Isn't this the perpetual issue of having large number of CPUs? If so > > consider use of LOG_CPU_MAX_BUF_SHIFT instead, otherwise clarifying how > > this would be a different issue would be good. LOG_CPU_MAX_BUF_SHIFT > > should scale nicely but you can increase it as well, is it being used? > > > > Luis > > > No, it is not being used. > > LOG_CPU_MAX_BUF_SHIFT is a 3.17+ config and we do not have any of the > above mentioned production machines running 3.17 or later. Then consider backporting it. > This patch did help us with debugging when running on older stable kernels > though. Understood, give the other stuff a spin. Luis -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: Really fix deadlock with mmap_sem
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 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 debugfs creation outside > > > the prepare_lock. > > > > > > Reported-by: Russell King - ARM Linux > > > > Please use "Russell King " rather than this > > address, thanks. > > Applied to clk-next and fixed up the email address locally. Please make sure it gets into stable kernels too as v3.18 suffers from this bug, thanks. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: Really fix deadlock with mmap_sem
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 directories. This means > > we still have the chance of a deadlock that the commit was trying > > to fix. Actually fix it by moving the debugfs creation outside > > the prepare_lock. > > > > Reported-by: Russell King - ARM Linux > > Please use "Russell King " rather than this > address, thanks. Applied to clk-next and fixed up the email address locally. Regards, Mike > > -- > FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up > according to speedtest.net. -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Maintainer abuse
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 maintainer abuse to have [PATCH V5 00/23] Generic BMIPS kernel [RFC][PATCH 0/8] x86, mpx: Support 32-bit binaries on 64-bit kernels [v3 00/26] Add VT-d Posted-Interrupts support i.e. 57 patches to look at in my inbox TODAY in the middle of the merge window where I have to make other really more urgent decisions. Not to talk about the other patch series which arrived in the past few days after the merge window opened. That sums up to a total of more than 200 patches, some of them superseeded by now. Nothing of this is 3.19 material so posting it right now is just useless. I'm not going to look at it and I'm not going to look at it next week either. This whole featuritis driven 'post crap as fast as you can' thing has to stop, really. I'm observing the following patterns in a frightingly increasing way: - 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 This really has to stop. Yours grumpy tglx -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/8] x86, mpx: Support 32-bit binaries on 64-bit kernels
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 explicitly, but I did do a substantial amount of testing throwing random instruction streams at the decoder to make sure it never fell over. (Well, mostly random, I made sure to throw the MPX opcodes in there a bunch so it would get much deeper in to the decoder). It's not about the instruction size, it's about the mode the CPU is in. If a 32-bit app manages to switch over to 64-bit mode and doesn't tell the kernel (TIF_IA32 remains set), then we'll treat it as a 32-bit instruction. The kernel might end up going and looking for the bounds tables in some funky places if the kernel and the hardware disagree about 32 vs. 64-bit modes, but it's not going to do any harm since we treat all of the data we get from MPX (instruction decoding, register contents, bounds table contents, etc...) as completely untrusted. It's a nice, paranoid thing to ask and I'm glad you brought it up because I hadn't thought about it, but I don't think any harm can come of it. -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Status of tip/x86/apic
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 and we then start a chase and bandaid race which will kill > the well earned recreation in an instant. > > Though one issue with that is, that for the early boot process > there is no way to store that information as the tracer gets > enabled way after init_IRQ(). But there is no reason why the > tracer could not be enabled before that. All it needs is a > working memory allocator. Steven? > > Now there is another class of problems which might be hard to > debug. When the machine just boots into a hang, so we dont get a > ftrace output neither from an oops nor from a console. It would > be nice if we could have a command line option which prints > enabled trace points via (early_)printk. That would avoid > sending out ad hoc printk debug patches which will basically > provide the same information as the trace_points. That would be > useful for other hard to debug boot hangs as well. Steven? Sure sure, everyone gets a nice calm xmas except for poor Steven who has to hack on early tracepoints such that this will be ready for 3.20! -- Steve (The Grinch who Hacked on Christmas) -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 01/15] drivers/base: add track framework
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 shall be unique.
This is pretty confusing, when it talks about "kernel objects" that
sounds like it means struct kobject but in fact there's no connection
with that or any of the other kernel object stuff. Perhaps it makes
sense but it should be addressed.
OK
Typical usage of the framework by consumer looks as follow:
1. Consumer registers notifier callback for objects with given id.
This is also a custom thing not connected with the notifier mechanism
implemented by struct notifier_block. Again this should probably be
addressed, even if it's just used internally it seems like there should
be some opportunity for code reuse here.
I though about using notfier_block, but beside the struct itself there
wouldn't be too much code to reuse. In my previous attempt of this
framework more arguments were passed to the callback so I have dropped
this idea completely, but now after simplifying the callback it fits better.
+ case track_task_up:
+ node = track_get_node(track, task->type, task->id, true);
+
+ node->up = true;
+ node->data = task->data;
+ list_for_each_entry_safe(itb, node->itb_next, &node->itb_head,
+list)
+ itb->callback(itb, node->data, true);
+ return;
+ case track_task_down:
I'm not sure the up and down naming is the most obvious naming for
users. It's obviously inspired by semaphores but it's not entirely
obvious that this is going to make things clear and meaningful for
someone trying to understand the interface.
In my 1st attempt I have called the framework interface_tracker, so it
was named ifup/ifdown after unix commands:) Now it is less obvious.
Finding good names is always painful, anyway I will think about it.
+static int track_process_queue(struct tracker *track)
+{
+ struct track_task *task, *ptask = NULL;
+ unsigned long flags;
+ bool empty;
+
+ /* Queue non-emptiness is used as a sentinel to prevent processing
+* by multiple threads, so we cannot delete entry from the queue
+* until it is processed.
+*/
+ while (true) {
+ spin_lock_irqsave(&track->queue_lock, flags);
+
+ if (ptask)
+ list_del(&ptask->list);
+ task = list_first_entry(&track->queue,
+ struct track_task, list);
+
+ empty = list_empty(&track->queue);
+ if (empty)
+ complete_all(&track->queue_empty);
+
+ spin_unlock_irqrestore(&track->queue_lock, flags);
Here we get a task from the head of the list and drop the lock, leaving
the task on the list...
Yes and it is explained in the comment few lines above.
+ kfree(ptask);
+
+ if (empty)
+ break;
+
+ track_process_task(track, task);
...we then go and do some other stuff, including processing that task,
without the lock or or any other means I can see of excluding other
users before going round and removing the task. This seems to leave us
vulnerable to double execution.
No, if you look at track_add_task function you will see that the queue
is processed only if it is initially empty, otherwise the task is only
added to the queue, so it will be processed after processing earlier tasks.
So the rule is that if someone add task to the queue it checks if the
queue is empty, in such case it process all tasks from the queue until
the queue becomes empty, even the tasks added by other processed.
This way all tasks are serialized.
I *think* this is supposed to be
handled by your comment "Provider should take care of calling
notifications synchronously in proper order" in the changelog but that's
a bit obscure, it's not specific about what the requirements are (or
what the limits are supposed to be on the notification callbacks).
No, this comment is just to avoid advertising object (ie calling
track_up) that can be just removed by concurrent thread.
I'm also unclear what is supposed to happen if adding a notification
races with removing the thing being watched.
The sequence should be always as follows:
1. create thing, then call track_up(thing).
...
2. call track_down(thing) then remove thing.
If we put 1 into probe and 2 into remove callback of the driver it will
be safe - we are synchronised by device_lock. But if, for some reason,
we want to create object after probe we should do own synchronization or
just put device_lock around 1. The same applies if we want to remove
object earlier. This is the comment above abo
Re: [PATCH v3 0/5] ARM64: Add kernel probes(Kprobes) support
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:
>>
>>
>> [...]
>>
Not sure if this is helpful, but the following also caused a crash for
me:
echo "p:trace_event_buffer_lock_reserve trace_event_buffer_lock_reserve"
> /sys/kernel/debug/tracing/kprobe_events
echo "p:memcpy memcpy" >> /sys/kernel/debug/tracing/kprobe_events
echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable
[immediate crash]
The crash point for me is in the arm64 ASID allocator, it again looks
like the interrupts are in an unexpected state.
(check_and_switch_context goes down the irqs disabled code path, I
think incorrectly).
This occurred for me both with and without the proposed irq saving fix.
I will do some more digging.
>>>
>>> Thanks, more information is good.
>>>
>>
>> Hi,
>>
>> Some good news, I think I've fixed the problem I've been experiencing.
>>
>> Basically, I've torn out all the interrupt save/restore and have
>> narrowed the scope to just sandwich the instruction single-step. This
>> simplifies a lot of logic, and I've now been able to perf record a
>> kprobe on memcpy (and the trace_event_buffer_lock_reserve + memcpy
>> test) without any issues on a Juno platform.
>>
>> I may have been somewhat over-zealous with the chainsaw, so please do
>> put this fix through its paces.
>>
>> Cheers,
>> --
>> Steve
>>
>>
>> From d3f4d80ce19bec71bd03209beb2fbfd8084d6543 Mon Sep 17 00:00:00 2001
>> From: Steve Capper
>> Date: Mon, 1 Dec 2014 11:30:10 +
>> Subject: [PATCH] Fix the interrupt handling for kprobes
>>
>> ---
>> arch/arm64/kernel/kprobes.c | 16 ++--
>> 1 file changed, 2 insertions(+), 14 deletions(-)
>>
>> diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
>> index be7c330..d39d826 100644
>> --- a/arch/arm64/kernel/kprobes.c
>> +++ b/arch/arm64/kernel/kprobes.c
>> @@ -229,10 +229,6 @@ skip_singlestep_missed(struct kprobe_ctlblk *kcb,
>> struct pt_regs *regs)
>> {
>> /* set return addr to next pc to continue */
>> instruction_pointer(regs) += sizeof(kprobe_opcode_t);
>> -
>> - if (kcb->kprobe_status != KPROBE_REENTER)
>> - kprobes_restore_local_irqflag(regs);
>> -
>> }
>>
>> static void __kprobes setup_singlestep(struct kprobe *p,
>> @@ -259,7 +255,7 @@ static void __kprobes setup_singlestep(struct kprobe
>> *p,
>> spsr_set_debug_flag(regs, 0);
>>
>> /* IRQs and single stepping do not mix well. */
>> - local_irq_disable();
>> + kprobes_save_local_irqflag(regs);
>> kernel_enable_single_step(regs);
>> instruction_pointer(regs) = slot;
>> } else {
>> @@ -326,7 +322,6 @@ post_kprobe_handler(struct kprobe_ctlblk *kcb, struct
>> pt_regs *regs)
>> }
>>
>> reset_current_kprobe();
>> - kprobes_restore_local_irqflag(regs);
>> }
>>
>> int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int
>> fsr)
>> @@ -380,8 +375,6 @@ int __kprobes kprobe_fault_handler(struct pt_regs
>> *regs, unsigned int fsr)
>> return 1;
>>
>> break;
>> - default:
>> - break;
>> }
>> return 0;
>> }
>> @@ -446,7 +439,6 @@ void __kprobes kprobe_handler(struct pt_regs *regs)
>> * handling of this interrupt is appropriate.
>> * Return back to original instruction, and continue.
>> */
>> - kprobes_restore_local_irqflag(regs);
>> return;
>> } else if (cur) {
>> /* We probably hit a jprobe. Call its break handler. */
>> @@ -459,7 +451,6 @@ void __kprobes kprobe_handler(struct pt_regs *regs)
>> /* breakpoint is removed, now in a race
>> * Return back to original instruction & continue.
>> */
>> - kprobes_restore_local_irqflag(regs);
>> }
>> }
>>
>> @@ -485,6 +476,7 @@ kprobe_single_step_handler(struct pt_regs *regs,
>> unsigned int esr)
>> retval = kprobe_ss_hit(kcb, instruction_pointer(regs));
>>
>> if (retval == DBG_HOOK_HANDLED) {
>> + kprobes_restore_local_irqflag(regs);
>> kernel_disable_single_step();
>>
>> if (kcb->kprobe_status == KPROBE_REENTER)
>> @@ -499,7 +491,6 @@ kprobe_single_step_handler(struct pt_regs *regs,
>> unsigned int esr)
>> static int __kprobes
>> kprobe_breakpoint_handler(struct pt_regs *regs, unsigned int esr)
>> {
>> - kprobes_save_local_irqflag(regs);
>> kprobe_handler(regs);
>> return DBG_HOOK_HANDLED;
>> }
>> @@ -563,7 +554,6 @@ int __kprobes long
Re: [PATCH] Increase maximum size of dmesg buffer to 16MB.
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 >> the machine to hang for a number of minutes (an unacceptable impact), >> but dumping the same data to memory is feasible if the dmesg buffer is >> sized large enough to hold the output. Set to 16MB which will hopefully >> be large enough to handle a dump from any of our servers at this time. >> >> Signed-off-by: Nate Stahl >> Signed-off-by: Vinson Lee > > Isn't this the perpetual issue of having large number of CPUs? If so > consider use of LOG_CPU_MAX_BUF_SHIFT instead, otherwise clarifying how > this would be a different issue would be good. LOG_CPU_MAX_BUF_SHIFT > should scale nicely but you can increase it as well, is it being used? > > Luis No, it is not being used. LOG_CPU_MAX_BUF_SHIFT is a 3.17+ config and we do not have any of the above mentioned production machines running 3.17 or later. This patch did help us with debugging when running on older stable kernels though. Thanks for the quick reply. -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clk: Really fix deadlock with mmap_sem
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 deadlock that the commit was trying > to fix. Actually fix it by moving the debugfs creation outside > the prepare_lock. > > Reported-by: Russell King - ARM Linux Please use "Russell King " rather than this address, thanks. -- FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up according to speedtest.net. -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH 0/8] x86, mpx: Support 32-bit binaries on 64-bit kernels
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 switch between 32-bit and 64-bit >> mode entirely in userspace. I don't know whether any do in practice, >> but programs *can*. > > So, you want a 2GB of the 32-bit address space dedicated to a bounds > directory, and half of the space for the bounds tables to be simply > zero-filled unused address bits? That seems, um, a bit unreasonable. Fair enough. > >> Or better yet: Intel could have skipped supporting it at all in 32-bit >> mode. > > So, we should not have this security feature for 32-bit apps... because > it costs us 50 lines of code in the kernel to support? Did you look at > the diffstat? > >> Isn't mpx somewhat of an address space hog anyway? > > Yes, it will be troublesome for 32-bit apps that are already bumping up > against the virtual address space size to support it. But, really, how > many of those *are* there these days? I wonder how many 32-bit apps will end up using mpx regardless. 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. --Andy -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] clk: Really fix deadlock with mmap_sem
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 debugfs creation outside
the prepare_lock.
Reported-by: Russell King - ARM Linux
Fixes: 6314b6796e3c "clk: Don't hold prepare_lock across debugfs creation"
Signed-off-by: Stephen Boyd
---
drivers/clk/clk.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk.c b/drivers/clk/clk.c
index 44cdc47a6cc5..c9430653ddc9 100644
--- a/drivers/clk/clk.c
+++ b/drivers/clk/clk.c
@@ -240,12 +240,13 @@ static const struct file_operations clk_dump_fops = {
.release= single_release,
};
-/* caller must hold prepare_lock */
static int clk_debug_create_one(struct clk *clk, struct dentry *pdentry)
{
struct dentry *d;
int ret = -ENOMEM;
+ lockdep_assert_held(clk_debug_lock);
+
if (!clk || !pdentry) {
ret = -EINVAL;
goto out;
@@ -1944,7 +1945,6 @@ int __clk_init(struct device *dev, struct clk *clk)
else
clk->rate = 0;
- clk_debug_register(clk);
/*
* walk the list of orphan clocks and reparent any that are children of
* this clock
@@ -1979,6 +1979,9 @@ int __clk_init(struct device *dev, struct clk *clk)
out:
clk_prepare_unlock();
+ if (!ret)
+ clk_debug_register(clk);
+
return ret;
}
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Status of tip/x86/apic
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 season. Linus -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] staging: rtl8723au: Fix sparse warnings
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 __le16
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.
Signed-off-by: Krzysztof Konopko
---
drivers/staging/rtl8723au/include/wifi.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/rtl8723au/include/wifi.h
b/drivers/staging/rtl8723au/include/wifi.h
index fd3da3b..266c43e 100644
--- a/drivers/staging/rtl8723au/include/wifi.h
+++ b/drivers/staging/rtl8723au/include/wifi.h
@@ -28,7 +28,7 @@
struct AC_param {
unsigned char ACI_AIFSN;
unsigned char CW;
- unsigned short TXOP_limit;
+ __le16 TXOP_limit;
} __packed;
struct WMM_para_element {
@@ -39,9 +39,9 @@ struct WMM_para_element {
struct ADDBA_request {
unsigned char dialog_token;
- unsigned short BA_para_set;
- unsigned short BA_timeout_value;
- unsigned short BA_starting_seqctrl;
+ __le16 BA_para_set;
+ __le16 BA_timeout_value;
+ __le16 BA_starting_seqctrl;
} __packed;
--
2.1.3
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] vt: fix console lock vs. kernfs s_active lock order
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 your review. > >>> > >>> On Fri, 2014-12-12 at 13:32 -0500, Peter Hurley wrote: > Hi Imre, > > On 12/12/2014 11:38 AM, Imre Deak wrote: > > Currently there is a lock order problem between the console lock and the > > kernfs s_active lock of the console driver's bind sysfs entry. When > > writing to the sysfs entry the lock order is first s_active then console > > lock, when unregistering the console driver via > > do_unregister_con_driver() the order is the opposite. See the below > > bugzilla reference for one instance of a lockdep backtrace. > > This description didn't make sense to me because the driver core doesn't > try to take the console_lock. So I had to go pull the lockdep report > and I'm not sure I agree with your analysis. > > I see a three-way dependency which includes the fb atomic notifier call > chain? > >>> > >>> From the lockdep report in the bugzilla ticket I referenced, you can see > >>> the following two paths: > >>> > >>> i915_driver_load() > >>> console_lock() -> takes console_sem > >>> do_unregister_con_driver() > >>> vtconsole_deinit_device() > >>> device_remove_file() > >>> ... > >>> __kernfs_remove() > >>> kernfs_drain() -> > >>> takes s_active rwsem for the console's bind sysfs entry > >>> (tracked via kn->dep_map) > >> > >> I don't see this call chain. > >> > >> I see: (some obvious intermediate calls redacted) > >> > >> i915_driver_unload > >> do_unregister_framebuffer > >> fb_notifier_call_chain > >> fbcon_event_notify > >> do_unregister_con_driver > >> device_remove_file > >> sysfs_addrm_finish > >> > >> which has console_lock => fb notifier lock => kernfs lock dependency. > > > > Ah, right, there are two dmesg logs in the bug report, your sequence is > > the first one [1] and I talked about the second [2]. > > > > [1] https://bugs.freedesktop.org/attachment.cgi?id=87716 > > [2] https://bugs.freedesktop.org/attachment.cgi?id=107602 > > > Which is why your evidence/justification should be in the commit message > rather than presuming that it's self-evident from a reference to a bug report. > > However, it doesn't seem to me that reference [2] provides more evidence for > changing VT; why is i915 the only drm driver trying to unload the vga console > from it's .load method? Without that, the problem is back to fbcon. The same problem is present whenever you call do_unregister_con_driver(). This is the case in give_up_console(), which isn't fbcon specific. > [Aside: istm, the design error here was to expose bind/unbind as sysfs hooks > from the VT console code, but that doesn't look remediable. ] > > Regards, > Peter Hurley > > >> My point being that this occurs only because the fb notifier call chain > >> requires console_lock => fb notifier lock dependency ordering; that and > >> fbcon assumes that it can do whatever in the notifier. > > > > Yes this is correct and I don't see any place where we would have the > > opposite order. > > > > The lockdep report in [1] is really just the same problem I described > > which is the s_active->console_lock dependency: > > > > CPU0 CPU1 > > > > lock((fb_notifier_list).rwsem); > >lock(console_lock); > >lock((fb_notifier_list).rwsem); > > lock(s_active#114); > > *** DEADLOCK *** > > > > This can lead to a deadlock only because s_active already depends on > > console_lock. After removing this dependency I can't see any other way > > these locks could deadlock. > > > >> I would like to see more thorough justification for why this change > >> belongs in vt, and not in fbcon. That was my point about the 3-way > >> dependency. > > > > Since it's really about the dependency between console_lock and s_active > > and fbcon is not involved in all code paths where we take these locks > > (like in the [2] case) but vt is. > > > > --Imre > > > >> > >> Regards, > >> Peter Hurley > >> > >> > >>> vfs_write() for the above console bind sysfs entry > >>> kernfs_fop_write() > >>> kernfs_get_active() -> > >>> takes s_active rwsem for the above sysfs entry > >>> ... > >>> store_bind() -> takes console_sem > >>> > >>> So you have console_sem->s_active ordering on one path and > >>> s_active->console_sem ordering on the other. > >>> > >>> This patch gets rid of the ordering problem and the related lockdep > >>> warning. > >>> > >>> --Imre > >>> > > Regards, > Peter Hu
Re: linux-next: Tree for Dec 12
On Fri, 12 Dec 2014 23:36:37 +0100 Paul Bolle wrote: > On Fri, 2014-12-12 at 13:57 -0800, Andrew Morton wrote: > > On Fri, 12 Dec 2014 11:31:56 +0100 Paul Bolle wrote: > > > > I won't be bothering (Andrew and) you again about this. Unless sorting > > > 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 actually users of that Kconfig symbol. How'd that happen? http://ozlabs.org/~akpm/mmots/broken-out/init-remove-config_init_fallback.patch removes all mention of CONFIG_INIT_FALLBACK? -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rtl8723au: Fix sparse warnings
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 like the one in `include/linux/ieee80211.h` >>> where any data wider than one byte is clearly declared as __le? >> >> That is a good question. One possibility is that those definitions do >> not exist on some of the older kernels that Realtek supports. They >> generally work with 2.6.18 and newer. > > The reason the 8723au driver doesn't use the defines from there is that > in ieee80211.h they are part of struct ieee80211_mgmt, while the 8723au > driver access the addba etc. elements without the full struct in place. > And why is that the case? (I'm trying to understand, not debunk) Looks to me that this driver has been kept out of the tree for quite a while (by Realtek) and now suffers from locally invented stuff. I understand this is a lot of work to unify the codebase with ieee80211.h, but are there any technical hurdles? I'm just curious. Thanks, Kris -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Squashfs: add LZ4 compression
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, necessary. The patches got pulled into linux-next. For XZ, the patches sat in linux-next for a full release cycle. I don't know whether or not if that is the plan for the lz4 patches. . The plan is to send out the merge request this weekend. I've been too busy this week with my main job to do the merge request, sorry (I'll probably be working past midnight again tonight, the weeks leading up to Christmas are always really busy). Phillip -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
CONFIG_CC_OPTIMIZE_FOR_SIZE breaking tridentfb
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 works fine with other cards (3DImage 9750 and CyberBlade XP) with no blit
implementation. Commenting out contents of blade_image_blit() function makes
the hang go away (nothing useful on the screen, of course).
Compiled kernel without CONFIG_CC_OPTIMIZE_FOR_SIZE: works
Then inserted #pragma GCC optimize ("Os") line into tridentfb.c: hangs (1)
Then added __attribute__((optimize("O2"))) to blade_image_blit(): works (2)
Compiled kernel with CONFIG_CC_OPTIMIZE_FOR_SIZE: hangs.
Then inserted #pragma GCC optimize ("O2") line into tridentfb.c: still hangs!
Then added __attribute__((optimize("O2"))) to blade_image_blit(): still hangs
$ gcc --version
gcc (Debian 4.7.2-5) 4.7.2
WTF is going on here?
objdumps from case (1) and (2):
this one hangs:
0965 :
965: 55 push %ebp
966: 57 push %edi
967: 56 push %esi
968: 89 d6 mov%edx,%esi
96a: 53 push %ebx
96b: 8b 38 mov(%eax),%edi
96d: 8b 54 24 14 mov0x14(%esp),%edx
971: 8b 5c 24 18 mov0x18(%esp),%ebx
975: 8b 6c 24 1c mov0x1c(%esp),%ebp
979: 8b 44 24 20 mov0x20(%esp),%eax
97d: 89 87 60 21 00 00 mov%eax,0x2160(%edi)
983: 8b 44 24 24 mov0x24(%esp),%eax
987: 89 87 64 21 00 00 mov%eax,0x2164(%edi)
98d: b8 00 00 18 a0 mov$0xa018,%eax
992: 89 87 44 21 00 00 mov%eax,0x2144(%edi)
998: 89 d0 mov%edx,%eax
99a: c1 e0 10shl$0x10,%eax
99d: 09 c8 or %ecx,%eax
99f: 89 87 08 21 00 00 mov%eax,0x2108(%edi)
9a5: 8d 44 2a ff lea-0x1(%edx,%ebp,1),%eax
9a9: c1 e0 10shl$0x10,%eax
9ac: 8d 54 19 ff lea-0x1(%ecx,%ebx,1),%edx
9b0: 09 d0 or %edx,%eax
9b2: 89 87 0c 21 00 00 mov%eax,0x210c(%edi)
9b8: 8d 43 1flea0x1f(%ebx),%eax
9bb: 8d 0c ad 00 00 00 00lea0x0(,%ebp,4),%ecx
9c2: c1 e8 05shr$0x5,%eax
9c5: 8d 97 00 00 01 00 lea0x1(%edi),%edx
9cb: 0f af c8imul %eax,%ecx
9ce: 89 d7 mov%edx,%edi
9d0: f3 a4 rep movsb %ds:(%esi),%es:(%edi)
9d2: 5b pop%ebx
9d3: 5e pop%esi
9d4: 5f pop%edi
9d5: 5d pop%ebp
9d6: c3 ret
this one works:
0965 :
965: 01 d0 add%edx,%eax
967: 89 08 mov%ecx,(%eax)
969: c3 ret
96a: 8d b6 00 00 00 00 lea0x0(%esi),%esi
0970 :
970: 83 ec 1csub$0x1c,%esp
973: 89 5c 24 0c mov%ebx,0xc(%esp)
977: 89 c3 mov%eax,%ebx
979: 8b 44 24 28 mov0x28(%esp),%eax
97d: 89 74 24 10 mov%esi,0x10(%esp)
981: 89 ce mov%ecx,%esi
983: 8b 4c 24 2c mov0x2c(%esp),%ecx
987: 89 54 24 04 mov%edx,0x4(%esp)
98b: ba 60 21 00 00 mov$0x2160,%edx
990: 89 7c 24 14 mov%edi,0x14(%esp)
994: 8b 7c 24 20 mov0x20(%esp),%edi
998: 89 04 24mov%eax,(%esp)
99b: 8b 44 24 30 mov0x30(%esp),%eax
99f: 89 6c 24 18 mov%ebp,0x18(%esp)
9a3: 8b 6c 24 24 mov0x24(%esp),%ebp
9a7: 89 44 24 08 mov%eax,0x8(%esp)
9ab: 8b 03 mov(%ebx),%eax
9ad: e8 b3 ff ff ff call 965
9b2: 8b 4c 24 08 mov0x8(%esp),%ecx
9b6: ba 64 21 00 00 mov$0x2164,%edx
9bb: 8b 03 mov(%ebx),%eax
9bd: e8 a3 ff ff ff call 965
9c2: 8b 03 mov(%ebx),%eax
9c4: b9 00 00 18 a0 mov$0xa018,%ecx
9c9: ba 44 21 00 00 mov$0x2144,%edx
9ce: e8 92 ff f
Re: [PATCH] staging: rtl8723au: Fix sparse warnings
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 >> wireless card TBH. But I'm happy to try to get one. Is Rtl8723AE the >> right model? > > No. The device numbers that end in E are PCIe and use a mac80211-based > driver. As none of my BE hardware has PCIe, I cannot test those drivers > on other than LE hardware. I do not have the hardware either for the > RTL8723AU. For that reason, I am careful when modifying the driver - I > let Jes do that. > Silly me. 'U' stands for USB here. But can't find this device on any auction. It's included in some ultrabooks but can't afford that for the sake of fixing some sparse warnings :) >>> In RTL8188EU, both BA_starting_seqctrl and TXOP_limit are unsigned >>> short. >>> >> >> That's not quite the case. `TXOP_limit` is __le16 in RTL8188EU [1]. >> It's __le16 even in your GitHub repo [2]. And that made me thinking >> that there's probably some inconsistency in the header. > > All the USB drivers are a mess. The kernel version of rtl8188eu does not > work on PPC; however, the git repo now does. I'm working on finding the > differences and fixing the kernel version. > Right. I found your introductory message: https://lkml.org/lkml/2013/4/1/280 >> 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 like the one in `include/linux/ieee80211.h` >> where any data wider than one byte is clearly declared as __le? > > That is a good question. One possibility is that those definitions do > not exist on some of the older kernels that Realtek supports. They > generally work with 2.6.18 and newer. > That would be important if the driver was kept out of the tree. Isn't it the point of having the driver in the mainline to keep up with the kernel and don't bother with older versions? > To be able to fix the kernel driver for RTL8188EU on PPC, I need to sort > out these endian problems. Once I do, I will port them to the other > drivers. > Isn't `sparse` useful here? :) Kris -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] xen: build infrastructure for generating hypercall depending symbols
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 $LINUXINCLUDE -dD -imacros "$i" -x c /dev/null
+done | \
+awk '$1 == "#define" && $2 ~ /__HYPERVISOR_[a-z][a-z_0-9]*/ { v[$3] = $2 }
+ END {for (i in v) if (!(v[i] in v))
+ print "HYPERCALL("substr(v[i], 14)")"}' | sort -u >$out
Why do you 'sort -u'? Do you expect multiple definitions of the same
hypercall?
-boris
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Increase maximum size of dmesg buffer to 16MB.
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 impact), > but dumping the same data to memory is feasible if the dmesg buffer is > sized large enough to hold the output. Set to 16MB which will hopefully > be large enough to handle a dump from any of our servers at this time. > > Signed-off-by: Nate Stahl > Signed-off-by: Vinson Lee Isn't this the perpetual issue of having large number of CPUs? If so consider use of LOG_CPU_MAX_BUF_SHIFT instead, otherwise clarifying how this would be a different issue would be good. LOG_CPU_MAX_BUF_SHIFT should scale nicely but you can increase it as well, is it being used? Luis -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] vt: fix console lock vs. kernfs s_active lock order
[ +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 wrote: Hi Imre, On 12/12/2014 11:38 AM, Imre Deak wrote: > Currently there is a lock order problem between the console lock and the > kernfs s_active lock of the console driver's bind sysfs entry. When > writing to the sysfs entry the lock order is first s_active then console > lock, when unregistering the console driver via > do_unregister_con_driver() the order is the opposite. See the below > bugzilla reference for one instance of a lockdep backtrace. This description didn't make sense to me because the driver core doesn't try to take the console_lock. So I had to go pull the lockdep report and I'm not sure I agree with your analysis. I see a three-way dependency which includes the fb atomic notifier call chain? >>> >>> From the lockdep report in the bugzilla ticket I referenced, you can see >>> the following two paths: >>> >>> i915_driver_load() >>> console_lock() -> takes console_sem >>> do_unregister_con_driver() >>> vtconsole_deinit_device() >>> device_remove_file() >>> ... >>> __kernfs_remove() >>> kernfs_drain() -> >>> takes s_active rwsem for the console's bind sysfs entry >>> (tracked via kn->dep_map) >> >> I don't see this call chain. >> >> I see: (some obvious intermediate calls redacted) >> >> i915_driver_unload >> do_unregister_framebuffer >> fb_notifier_call_chain >> fbcon_event_notify >> do_unregister_con_driver >> device_remove_file >> sysfs_addrm_finish >> >> which has console_lock => fb notifier lock => kernfs lock dependency. > > Ah, right, there are two dmesg logs in the bug report, your sequence is > the first one [1] and I talked about the second [2]. > > [1] https://bugs.freedesktop.org/attachment.cgi?id=87716 > [2] https://bugs.freedesktop.org/attachment.cgi?id=107602 Which is why your evidence/justification should be in the commit message rather than presuming that it's self-evident from a reference to a bug report. However, it doesn't seem to me that reference [2] provides more evidence for changing VT; why is i915 the only drm driver trying to unload the vga console from it's .load method? Without that, the problem is back to fbcon. [Aside: istm, the design error here was to expose bind/unbind as sysfs hooks from the VT console code, but that doesn't look remediable. ] Regards, Peter Hurley >> My point being that this occurs only because the fb notifier call chain >> requires console_lock => fb notifier lock dependency ordering; that and >> fbcon assumes that it can do whatever in the notifier. > > Yes this is correct and I don't see any place where we would have the > opposite order. > > The lockdep report in [1] is really just the same problem I described > which is the s_active->console_lock dependency: > > CPU0 CPU1 > > lock((fb_notifier_list).rwsem); >lock(console_lock); >lock((fb_notifier_list).rwsem); > lock(s_active#114); > *** DEADLOCK *** > > This can lead to a deadlock only because s_active already depends on > console_lock. After removing this dependency I can't see any other way > these locks could deadlock. > >> I would like to see more thorough justification for why this change >> belongs in vt, and not in fbcon. That was my point about the 3-way >> dependency. > > Since it's really about the dependency between console_lock and s_active > and fbcon is not involved in all code paths where we take these locks > (like in the [2] case) but vt is. > > --Imre > >> >> Regards, >> Peter Hurley >> >> >>> vfs_write() for the above console bind sysfs entry >>> kernfs_fop_write() >>> kernfs_get_active() -> >>> takes s_active rwsem for the above sysfs entry >>> ... >>> store_bind() -> takes console_sem >>> >>> So you have console_sem->s_active ordering on one path and >>> s_active->console_sem ordering on the other. >>> >>> This patch gets rid of the ordering problem and the related lockdep >>> warning. >>> >>> --Imre >>> Regards, Peter Hurley > Fix this by unregistering the console driver from a deferred work, where > we can safely drop the console lock while unregistering the device and > corresponding sysfs entries (which in turn acquire s_active). Note that > we have to keep the console driver slot in the registered_con_driver > array reserved for the driver that's being unregistered until it's fully > removed. Otherwise a concurrent call to do_register
Re: [PATCH v3 0/5] ARM64: Add kernel probes(Kprobes) support
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:
echo "p:trace_event_buffer_lock_reserve trace_event_buffer_lock_reserve" >
/sys/kernel/debug/tracing/kprobe_events
echo "p:memcpy memcpy" >> /sys/kernel/debug/tracing/kprobe_events
echo 1 > /sys/kernel/debug/tracing/events/kprobes/enable
[immediate crash]
The crash point for me is in the arm64 ASID allocator, it again looks
like the interrupts are in an unexpected state.
(check_and_switch_context goes down the irqs disabled code path, I
think incorrectly).
This occurred for me both with and without the proposed irq saving fix.
I will do some more digging.
Thanks, more information is good.
Hi,
Some good news, I think I've fixed the problem I've been experiencing.
Basically, I've torn out all the interrupt save/restore and have
narrowed the scope to just sandwich the instruction single-step. This
simplifies a lot of logic, and I've now been able to perf record a
kprobe on memcpy (and the trace_event_buffer_lock_reserve + memcpy
test) without any issues on a Juno platform.
I may have been somewhat over-zealous with the chainsaw, so please do
put this fix through its paces.
Cheers,
--
Steve
From d3f4d80ce19bec71bd03209beb2fbfd8084d6543 Mon Sep 17 00:00:00 2001
From: Steve Capper
Date: Mon, 1 Dec 2014 11:30:10 +
Subject: [PATCH] Fix the interrupt handling for kprobes
---
arch/arm64/kernel/kprobes.c | 16 ++--
1 file changed, 2 insertions(+), 14 deletions(-)
diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
index be7c330..d39d826 100644
--- a/arch/arm64/kernel/kprobes.c
+++ b/arch/arm64/kernel/kprobes.c
@@ -229,10 +229,6 @@ skip_singlestep_missed(struct kprobe_ctlblk *kcb, struct
pt_regs *regs)
{
/* set return addr to next pc to continue */
instruction_pointer(regs) += sizeof(kprobe_opcode_t);
-
- if (kcb->kprobe_status != KPROBE_REENTER)
- kprobes_restore_local_irqflag(regs);
-
}
static void __kprobes setup_singlestep(struct kprobe *p,
@@ -259,7 +255,7 @@ static void __kprobes setup_singlestep(struct kprobe *p,
spsr_set_debug_flag(regs, 0);
/* IRQs and single stepping do not mix well. */
- local_irq_disable();
+ kprobes_save_local_irqflag(regs);
kernel_enable_single_step(regs);
instruction_pointer(regs) = slot;
} else {
@@ -326,7 +322,6 @@ post_kprobe_handler(struct kprobe_ctlblk *kcb, struct
pt_regs *regs)
}
reset_current_kprobe();
- kprobes_restore_local_irqflag(regs);
}
int __kprobes kprobe_fault_handler(struct pt_regs *regs, unsigned int fsr)
@@ -380,8 +375,6 @@ int __kprobes kprobe_fault_handler(struct pt_regs *regs,
unsigned int fsr)
return 1;
break;
- default:
- break;
}
return 0;
}
@@ -446,7 +439,6 @@ void __kprobes kprobe_handler(struct pt_regs *regs)
* handling of this interrupt is appropriate.
* Return back to original instruction, and continue.
*/
- kprobes_restore_local_irqflag(regs);
return;
} else if (cur) {
/* We probably hit a jprobe. Call its break handler. */
@@ -459,7 +451,6 @@ void __kprobes kprobe_handler(struct pt_regs *regs)
/* breakpoint is removed, now in a race
* Return back to original instruction & continue.
*/
- kprobes_restore_local_irqflag(regs);
}
}
@@ -485,6 +476,7 @@ kprobe_single_step_handler(struct pt_regs *regs, unsigned
int esr)
retval = kprobe_ss_hit(kcb, instruction_pointer(regs));
if (retval == DBG_HOOK_HANDLED) {
+ kprobes_restore_local_irqflag(regs);
kernel_disable_single_step();
if (kcb->kprobe_status == KPROBE_REENTER)
@@ -499,7 +491,6 @@ kprobe_single_step_handler(struct pt_regs *regs, unsigned
int esr)
static int __kprobes
kprobe_breakpoint_handler(struct pt_regs *regs, unsigned int esr)
{
- kprobes_save_local_irqflag(regs);
kprobe_handler(regs);
return DBG_HOOK_HANDLED;
}
@@ -563,7 +554,6 @@ int __kprobes longjmp_break_handler(struct kprobe *p,
struct pt_regs *regs)
memcpy((void *)stack_addr, kcb->jprobes_stack,
MIN_STACK_SIZE(stack_addr));
preempt_enable_no_resched();
- kprobes_restore_local_irqflag(regs);
return 1;
}
return 0;
@@ -655,8 +645,6 @@ trampoline_probe_handler(struct kprobe *p, struct pt_regs
*regs)
kfree(ri);
}
- kprobes_restore_local_irqf
[PATCH] Increase maximum size of dmesg buffer to 16MB.
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 buffer is sized large enough to hold the output. Set to 16MB which will hopefully be large enough to handle a dump from any of our servers at this time. Signed-off-by: Nate Stahl Signed-off-by: Vinson Lee --- init/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/init/Kconfig b/init/Kconfig index 903505e..266a3e8 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -812,7 +812,7 @@ config IKCONFIG_PROC config LOG_BUF_SHIFT int "Kernel log buffer size (16 => 64KB, 17 => 128KB)" - range 12 21 + range 12 24 default 17 depends on PRINTK help -- 1.9.1 -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: Tree for Dec 12
On Fri, 2014-12-12 at 13:57 -0800, Andrew Morton wrote: > On Fri, 12 Dec 2014 11:31:56 +0100 Paul Bolle wrote: > > I won't be bothering (Andrew and) you again about this. Unless sorting > > 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 actually users of that Kconfig symbol. My infamous 800 line perl monster - which I run on every linux-next release to check for exactly stuff like this - can't help but notice that. The idea being that my script notices these problems before they actually hit mainline. Note that the set of people actually worrying about this stuff contains me and, maybe, one or two other persons. Paul Bolle -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rtl8723au: Fix sparse warnings
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: cast to restricted __le16
>> rtw_wlan_util.c:1546:25: warning: cast to restricted __le16
>>
>> This patch changes declared types of the struct fields involved.
>>
>> Signed-off-by: Krzysztof Konopko
>> ---
>> drivers/staging/rtl8723au/include/wifi.h | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/staging/rtl8723au/include/wifi.h
>> b/drivers/staging/rtl8723au/include/wifi.h
>> index fd3da3b..8a2adc5 100644
>> --- a/drivers/staging/rtl8723au/include/wifi.h
>> +++ b/drivers/staging/rtl8723au/include/wifi.h
>> @@ -28,7 +28,7 @@
>> struct AC_param {
>> unsigned char ACI_AIFSN;
>> unsigned char CW;
>> -unsigned short TXOP_limit;
>> +__le16 TXOP_limit;
>> } __packed;
>>
>> struct WMM_para_element {
>> @@ -39,9 +39,9 @@ struct WMM_para_element {
>>
>> struct ADDBA_request {
>> unsigned char dialog_token;
>> -unsigned short BA_para_set;
>> +__le16 BA_para_set;
>> unsigned short BA_timeout_value;
>> -unsigned short BA_starting_seqctrl;
>> +__le16 BA_starting_seqctrl;
>> } __packed;
>
> If you are going to make the struct comply with the on-wire data format,
> be consistent. Don't just change half the elements of the struct - that
> will just lead to confusion.
>
> Jes
>
Yes, my change was inconsistent. Looking at `addba_req` and
`ieee80211_wmm_ac_param` in include/linux/ieee80211.h, all data wider
than 1 byte should be declared as __le. I'll send through a patch that
makes this change consistently.
Thanks,
Kris
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: rtl8723au: Fix sparse warnings
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 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 __le16
This patch changes declared types of the struct fields involved.
Signed-off-by: Krzysztof Konopko
---
drivers/staging/rtl8723au/include/wifi.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/rtl8723au/include/wifi.h
b/drivers/staging/rtl8723au/include/wifi.h
index fd3da3b..8a2adc5 100644
--- a/drivers/staging/rtl8723au/include/wifi.h
+++ b/drivers/staging/rtl8723au/include/wifi.h
@@ -28,7 +28,7 @@
struct AC_param {
unsigned charACI_AIFSN;
unsigned charCW;
-unsigned shortTXOP_limit;
+__le16TXOP_limit;
} __packed;
struct WMM_para_element {
@@ -39,9 +39,9 @@ struct WMM_para_element {
struct ADDBA_request {
unsigned chardialog_token;
-unsigned shortBA_para_set;
+__le16BA_para_set;
unsigned shortBA_timeout_value;
-unsigned shortBA_starting_seqctrl;
+__le16BA_starting_seqctrl;
} __packed;
>>>
>>> This fix may make the sparse warnings go away, but I think it
>>> introduces new bugs.
>>
>> This kind of change, doesn't change the compiled code only how Sparse
>> sees it. It can't introduce bugs.
>>
>> But it may well be that the calls to le16_to_cpu() should be removed. I
>> looked at it a bit but I don't know.
>
> Your point regarding bugs is taken. What I should have said is that
> blindly making _le changes to hide Sparse messages may hide existing
> bugs for BE hardware.
>
> Larry
>
>
Yes, I started it off blindly but dug further and now have a better
understanding. Looking in ieee80211.h and getting your feedback helped
me to get a better understanding of the situation.
I see nothing wrong in declaring data that is supposed to be
little-endian as __le. You say that making these changes blindly may
hide existing bugs but:
* not doing anything about it is not helpful either
* this is no longer changing anything blindly
Relevant structs: `addba_req` and `ieee80211_wmm_ac_param` do declare
their fields as __le where needed.
I do take a point though about making this change inconsistently
(blindly) in my initial patch.
Kris
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/02 resend] RTC: Add driver for DS1685 family of real time clocks
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 originally derived from a driver patch submitted by Matthias Fuchs many years ago for use in EPPC-405-UC modules, which also used these RTCs. In addition to the time-keeping functions, this RTC also handles the shutdown mechanism of the O2 and Octane and acts as a partial NVRAM for the boot PROMS in these systems. Verified on both an SGI O2 and an SGI Octane. Signed-off-by: Joshua Kinard --- MAINTAINERS|6 drivers/rtc/Kconfig| 90 + drivers/rtc/Makefile |1 drivers/rtc/rtc-ds1685.c | 2252 +++ include/linux/rtc/ds1685.h | 375 + 5 files changed, 2724 insertions(+) create mode 100644 drivers/rtc/rtc-ds1685.c create mode 100644 include/linux/rtc/ds1685.h The checkpatch errors regarding "Macros with complex values should be enclosed in parenthesis" should be fine. That macro construct I copied from elsewhere in the kernel, and I don't think wrapping them in parenthesis helps at all. Please let me know of any problems, thanks! linux-rtc-ds1685.patch diff --git a/MAINTAINERS b/MAINTAINERS index e186bf9..d081504 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -2915,6 +2915,12 @@ S: Supported F: drivers/input/touchscreen/cyttsp* F: include/linux/input/cyttsp.h +DALLAS/MAXIM DS1685-FAMILY REAL TIME CLOCK +M: Joshua Kinard +S: Maintained +F: drivers/rtc/rtc-ds1685.c +F: include/linux/rtc/ds1685.h + DAMA SLAVE for AX.25 M: Joerg Reuter W: http://yaina.de/jreuter/ diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig index f15cddf..f5693c4 100644 --- a/drivers/rtc/Kconfig +++ b/drivers/rtc/Kconfig @@ -790,6 +790,96 @@ config RTC_DRV_DS1553 This driver can also be built as a module. If so, the module will be called rtc-ds1553. +config RTC_DRV_DS1685_FAMILY + tristate "Dallas/Maxim DS1685 Family" + help + If you say yes here you get support for the Dallas/Maxim DS1685 + family of real time chips. This family includes the DS1685/DS1687, + DS1689/DS1693, DS17285/DS17287, DS17485/DS17487, and + DS17885/DS17887 chips. + + This driver can also be built as a module. If so, the module + will be called rtc-ds1685. + +choice + prompt "Subtype" + depends on RTC_DRV_DS1685_FAMILY + default RTC_DRV_DS1685 + +config RTC_DRV_DS1685 + bool "DS1685/DS1687" + help + This enables support for the Dallas/Maxim DS1685/DS1687 real time + clock chip. + + This chip is commonly found in SGI O2 (IP32) and SGI Octane (IP30) + systems, as well as EPPC-405-UC modules by electronic system design + GmbH. + +config RTC_DRV_DS1689 + bool "DS1689/DS1693" + help + This enables support for the Dallas/Maxim DS1689/DS1693 real time + clock chip. + + This is an older RTC chip, supplanted by the DS1685/DS1687 above, + which supports a few minor features such as Vcc, Vbat, and Power + Cycle counters, plus a customer-specific, 8-byte ROM/Serial number. + + It also works for the even older DS1688/DS1691 RTC chips, which are + virtually the same and carry the same model number. Both chips + have 114 bytes of user NVRAM. + +config RTC_DRV_DS17285 + bool "DS17285/DS17287" + help + This enables support for the Dallas/Maxim DS17285/DS17287 real time + clock chip. + + This chip features 2kb of extended NV-SRAM. It may possibly be + found in some SGI O2 systems (rare). + +config RTC_DRV_DS17485 + bool "DS17485/DS17487" + help + This enables support for the Dallas/Maxim DS17485/DS17487 real time + clock chip. + + This chip features 4kb of extended NV-SRAM. + +config RTC_DRV_DS17885 + bool "DS17885/DS17887" + help + This enables support for the Dallas/Maxim DS17885/DS17887 real time + clock chip. + + This chip features 8kb of extended NV-SRAM. + +endchoice + +config RTC_DS1685_PROC_REGS + bool "Display register values in /proc" + depends on RTC_DRV_DS1685_FAMILY && PROC_FS + help + Enable this to display a readout of all of the RTC registers in + /proc/drivers/rtc. Keep in mind that this can potentially lead + to lost interrupts, as reading Control Register C will clear + all pending IRQ flags. + + Unless you are debugging this driver, choose N. + +config RTC_DS1685_SYSFS_REGS + bool "SysFS access to RTC register bits" + depends on RTC_DRV_DS1685_FAMILY && SYSFS + help + Enable this to provide access to the RTC control register
[PATCH 02/02 resend] MIPS: IP32: Add platform data hooks to use DS1685 driver
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
arch/mips/include/asm/mach-ip32/mc146818rtc.h | 36
arch/mips/sgi-ip32/ip32-platform.c| 52 +-
arch/mips/sgi-ip32/ip32-reset.c | 132
4 files changed, 85 insertions(+), 138 deletions(-)
delete mode 100644 arch/mips/include/asm/mach-ip32/mc146818rtc.h
Ralf,
Similar to Maciej's DEC/RTC patches from a few months ago, this patch
requires the rtc-ds1685 driver be added upstream first before this can go into
into the LMO tree. If you can queue this someplace until that makes it in,
that would be great. Thanks!
linux-mips-ip32-use-rtc-ds1685.patch
diff --git a/arch/mips/configs/ip32_defconfig b/arch/mips/configs/ip32_defconfig
index 70ffe9b..fe48220 100644
--- a/arch/mips/configs/ip32_defconfig
+++ b/arch/mips/configs/ip32_defconfig
@@ -105,7 +105,8 @@ CONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
# CONFIG_RTC_INTF_SYSFS is not set
# CONFIG_RTC_INTF_PROC is not set
-CONFIG_RTC_DRV_CMOS=y
+CONFIG_RTC_DRV_DS1685_FAMILY=y
+CONFIG_RTC_DRV_DS1685=y
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
diff --git a/arch/mips/include/asm/mach-ip32/mc146818rtc.h
b/arch/mips/include/asm/mach-ip32/mc146818rtc.h
deleted file mode 100644
index 6b6bab4..000
--- a/arch/mips/include/asm/mach-ip32/mc146818rtc.h
+++ /dev/null
@@ -1,36 +0,0 @@
-/*
- * This file is subject to the terms and conditions of the GNU General Public
- * License. See the file "COPYING" in the main directory of this archive
- * for more details.
- *
- * Copyright (C) 1998, 2001, 03 by Ralf Baechle
- * Copyright (C) 2000 Harald Koerfgen
- *
- * RTC routines for IP32 style attached Dallas chip.
- */
-#ifndef __ASM_MACH_IP32_MC146818RTC_H
-#define __ASM_MACH_IP32_MC146818RTC_H
-
-#include
-
-#define RTC_PORT(x)(0x70 + (x))
-
-static unsigned char CMOS_READ(unsigned long addr)
-{
- return mace->isa.rtc[addr << 8];
-}
-
-static inline void CMOS_WRITE(unsigned char data, unsigned long addr)
-{
- mace->isa.rtc[addr << 8] = data;
-}
-
-/*
- * FIXME: Do it right. For now just assume that no one lives in 20th century
- * and no O2 user in 22th century ;-)
- */
-#define mc146818_decode_year(year) ((year) + 2000)
-
-#define RTC_ALWAYS_BCD 0
-
-#endif /* __ASM_MACH_IP32_MC146818RTC_H */
diff --git a/arch/mips/sgi-ip32/ip32-platform.c
b/arch/mips/sgi-ip32/ip32-platform.c
index 511e9ff..ec9eb7f 100644
--- a/arch/mips/sgi-ip32/ip32-platform.c
+++ b/arch/mips/sgi-ip32/ip32-platform.c
@@ -9,10 +9,13 @@
#include
#include
#include
+#include
#include
#include
+extern void ip32_prepare_poweroff(void);
+
#define MACEISA_SERIAL1_OFFS offsetof(struct sgi_mace, isa.serial1)
#define MACEISA_SERIAL2_OFFS offsetof(struct sgi_mace, isa.serial2)
@@ -90,22 +93,53 @@ static __init int sgio2btns_devinit(void)
device_initcall(sgio2btns_devinit);
-static struct resource sgio2_cmos_rsrc[] = {
+#define MACE_RTC_RES_START (MACE_BASE + offsetof(struct sgi_mace, isa.rtc))
+#define MACE_RTC_RES_END (MACE_RTC_RES_START + 32767)
+
+static struct resource ip32_rtc_resources[] = {
{
- .start = 0x70,
- .end = 0x71,
- .flags = IORESOURCE_IO
+ .start = MACEISA_RTC_IRQ,
+ .end= MACEISA_RTC_IRQ,
+ .flags = IORESOURCE_IRQ
+ }, {
+ .start = MACE_RTC_RES_START,
+ .end= MACE_RTC_RES_END,
+ .flags = IORESOURCE_MEM,
}
};
-static __init int sgio2_cmos_devinit(void)
+
+/* RTC registers on IP32 are each padded by 256 bytes (0x100). */
+static struct ds1685_rtc_platform_data
+ip32_rtc_platform_data[] = {
+ {
+ .regstep = 0x100,
+ .bcd_mode = true,
+ .no_irq = false,
+ .uie_unsupported = false,
+ .alloc_io_resources = true,
+ .plat_prepare_poweroff = ip32_prepare_poweroff,
+ },
+};
+
+struct platform_device ip32_rtc_device = {
+ .name = "rtc-ds1685",
+ .id = -1,
+ .dev= {
+ .platform_data = ip32_rtc_platform_data,
+ },
+ .num_resources = ARRAY_SIZE(ip32_rtc_resources),
+ .resource = ip32_rtc_resources,
+};
+
+static int __init sgio2_rtc_devinit(void)
{
- return IS_ERR(platform_device_register_simple("rtc_cmos", -1,
- sgio2_cmos_rsrc, 1));
+ return platform_device_register(&ip32_rtc_device);
+
}
-device_initcall(sgio2_cmos_devinit);
+device_initcall(sgio2_rtc_devinit);
MODULE_AUTHOR("Ralf Baechle ");
MODULE_LICENSE("GPL");
-MODULE_DESCRIPTION("
[PATCH 0/2] ARM: omap5/dra7xx counter frequency fixes
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 seconds per day if SYSCLK1 is 20MHz, which it is on the EVM boards as well as the other boards I am currently aware of. ntp declares that the system time drifts by over 500ppm (the maximum ntp will tolerate). To fix it, check the status register to determine if the 32.768KHz clock source is real (driven by an external crystal) or emulated (SYSCLK1 / 610), and if it is emulated use the appropriate numerator and divisor to make the fine master counter match the coarse master counter (which is driven directly from the 32KHz clock (real or emulated) with a fixed multiplier of 375 / 2). Making the fine counter run at a frequency different from the coarse counter is not an option, as the value in the fine counter is updated to match the coarse counter if they ever get out of sync. With 19.2MHz installed on the board, the clock runs almost 5% slow. With the change in place, ntp runs with a drift of around 3ppm on all boards I have tried which is well within the spec of the crystals used for SYSCLK1. Even if the errata is fixed in future revisions of the chip, there is still the option of someone purposely not connecting a 32.768KHz crystal to save cost or board space, and relying on the emulated clock instead, in which case this correction will still be necessary. Len Sorensen (2): ARM: omap5/dra7xx: Fix frequency typos. ARM: omap5/dra7xx: Fix counter frequency drift for AM572x errata i856. arch/arm/mach-omap2/timer.c | 120 +++ 1 file changed, 87 insertions(+), 33 deletions(-) -- 1.7.10.4 -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 01/23] MIPS: bcm3384: Fix outdated use of mips_cpu_intc_init()
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
--- a/arch/mips/bcm3384/irq.c
+++ b/arch/mips/bcm3384/irq.c
@@ -180,7 +180,7 @@ static int __init intc_of_init(struct device_node *node,
static struct of_device_id of_irq_ids[] __initdata = {
{ .compatible = "mti,cpu-interrupt-controller",
- .data = mips_cpu_intc_init },
+ .data = mips_cpu_irq_of_init },
{ .compatible = "brcm,bcm3384-intc",
.data = intc_of_init },
{},
--
2.1.1
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Patch v4 2/2] gpio: Document GPIO hogging mechanism
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 a/Documentation/devicetree/bindings/gpio/gpio.txt
b/Documentation/devicetree/bindings/gpio/gpio.txt
index 3fb8f53..a38da91 100644
--- a/Documentation/devicetree/bindings/gpio/gpio.txt
+++ b/Documentation/devicetree/bindings/gpio/gpio.txt
@@ -103,6 +103,22 @@ Every GPIO controller node must contain both an empty
"gpio-controller"
property, and a #gpio-cells integer property, which indicates the number of
cells in a gpio-specifier.
+The GPIO chip may contain GPIO hog definitions. GPIO hogging is a mechanism
+providing automatic GPIO request and configuration as part of the
+gpio-controller's driver probe function.
+
+Each GPIO hog definition is represented as a child node of the GPIO controller.
+Required properties:
+- gpio-hog: A property specifying that this child node represent a gpio-hog.
+- gpios: Store the gpio information (id, flags, ...). Shall contain the
+number of cells specified in its parent node (GPIO controller
+node).
+- state: A property specifying the direction/value needed. This property
+can take the folowing values: input, output-high, output-low.
+
+Optional properties:
+- line-name: The GPIO label name. If not present the node name is used.
+
Example of two SOC GPIO banks defined as gpio-controller nodes:
qe_pio_a: gpio-controller@1400 {
@@ -110,6 +126,13 @@ Example of two SOC GPIO banks defined as gpio-controller
nodes:
reg = <0x1400 0x18>;
gpio-controller;
#gpio-cells = <2>;
+
+ line_b {
+ gpio-hog;
+ gpios = <6 0>;
+ state = "output-low";
+ line-name = "foo-bar-gpio";
+ };
};
qe_pio_e: gpio-controller@1460 {
--
1.8.5.1
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 02/23] MIPS: Create a common
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
---
arch/mips/include/asm/mach-ar7/war.h | 24 -
arch/mips/include/asm/mach-ath25/war.h | 25 --
arch/mips/include/asm/mach-ath79/war.h | 24 -
arch/mips/include/asm/mach-au1x00/war.h| 24 -
arch/mips/include/asm/mach-bcm3384/war.h | 24 -
arch/mips/include/asm/mach-bcm47xx/war.h | 24 -
arch/mips/include/asm/mach-bcm63xx/war.h | 24 -
arch/mips/include/asm/mach-cavium-octeon/war.h | 25 --
arch/mips/include/asm/mach-cobalt/war.h| 24 -
arch/mips/include/asm/mach-dec/war.h | 24 -
arch/mips/include/asm/mach-emma2rh/war.h | 24 -
.../asm/{mach-ralink => mach-generic}/war.h| 6 +++---
arch/mips/include/asm/mach-jazz/war.h | 24 -
arch/mips/include/asm/mach-jz4740/war.h| 24 -
arch/mips/include/asm/mach-lantiq/war.h| 23
arch/mips/include/asm/mach-lasat/war.h | 24 -
arch/mips/include/asm/mach-loongson/war.h | 24 -
arch/mips/include/asm/mach-loongson1/war.h | 24 -
arch/mips/include/asm/mach-netlogic/war.h | 25 --
arch/mips/include/asm/mach-paravirt/war.h | 25 --
arch/mips/include/asm/mach-pnx833x/war.h | 24 -
arch/mips/include/asm/mach-tx39xx/war.h| 24 -
arch/mips/include/asm/mach-vr41xx/war.h| 24 -
23 files changed, 3 insertions(+), 534 deletions(-)
delete mode 100644 arch/mips/include/asm/mach-ar7/war.h
delete mode 100644 arch/mips/include/asm/mach-ath25/war.h
delete mode 100644 arch/mips/include/asm/mach-ath79/war.h
delete mode 100644 arch/mips/include/asm/mach-au1x00/war.h
delete mode 100644 arch/mips/include/asm/mach-bcm3384/war.h
delete mode 100644 arch/mips/include/asm/mach-bcm47xx/war.h
delete mode 100644 arch/mips/include/asm/mach-bcm63xx/war.h
delete mode 100644 arch/mips/include/asm/mach-cavium-octeon/war.h
delete mode 100644 arch/mips/include/asm/mach-cobalt/war.h
delete mode 100644 arch/mips/include/asm/mach-dec/war.h
delete mode 100644 arch/mips/include/asm/mach-emma2rh/war.h
rename arch/mips/include/asm/{mach-ralink => mach-generic}/war.h (86%)
delete mode 100644 arch/mips/include/asm/mach-jazz/war.h
delete mode 100644 arch/mips/include/asm/mach-jz4740/war.h
delete mode 100644 arch/mips/include/asm/mach-lantiq/war.h
delete mode 100644 arch/mips/include/asm/mach-lasat/war.h
delete mode 100644 arch/mips/include/asm/mach-loongson/war.h
delete mode 100644 arch/mips/include/asm/mach-loongson1/war.h
delete mode 100644 arch/mips/include/asm/mach-netlogic/war.h
delete mode 100644 arch/mips/include/asm/mach-paravirt/war.h
delete mode 100644 arch/mips/include/asm/mach-pnx833x/war.h
delete mode 100644 arch/mips/include/asm/mach-tx39xx/war.h
delete mode 100644 arch/mips/include/asm/mach-vr41xx/war.h
diff --git a/arch/mips/include/asm/mach-ar7/war.h
b/arch/mips/include/asm/mach-ar7/war.h
deleted file mode 100644
index 99071e5..000
diff --git a/arch/mips/include/asm/mach-ath25/war.h
b/arch/mips/include/asm/mach-ath25/war.h
deleted file mode 100644
index e3a5250..000
diff --git a/arch/mips/include/asm/mach-ath79/war.h
b/arch/mips/include/asm/mach-ath79/war.h
deleted file mode 100644
index 0bb3090..000
diff --git a/arch/mips/include/asm/mach-au1x00/war.h
b/arch/mips/include/asm/mach-au1x00/war.h
deleted file mode 100644
index 72e260d..000
diff --git a/arch/mips/include/asm/mach-bcm3384/war.h
b/arch/mips/include/asm/mach-bcm3384/war.h
deleted file mode 100644
index 59d7599..000
diff --git a/arch/mips/include/asm/mach-bcm47xx/war.h
b/arch/mips/include/asm/mach-bcm47xx/war.h
deleted file mode 100644
index a3d2f44..000
diff --git a/arch/mips/include/asm/mach-bcm63xx/war.h
b/arch/mips/include/asm/mach-bcm63xx/war.h
deleted file mode 100644
index 05ee867..000
diff --git a/arch/mips/include/asm/mach-cavium-octeon/war.h
b/arch/mips/include/asm/mach-cavium-octeon/war.h
deleted file mode 100644
index eb72b35..000
diff --git a/arch/mips/include/asm/mach-cobalt/war.h
b/arch/mips/include/asm/mach-cobalt/war.h
deleted file mode 100644
index 34ae404..000
diff --git a/arch/mips/include/asm/mach-dec/war.h
b/arch/mips/include/asm/mach-dec/war.h
deleted file mode 100644
index d29996f..000
diff
[PATCH V5 04/23] irqchip: Update docs regarding irq_domain_add_tree()
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 39cfa72..3a8e15c 100644 --- a/Documentation/IRQ-domain.txt +++ b/Documentation/IRQ-domain.txt @@ -95,8 +95,7 @@ since it doesn't need to allocate a table as large as the largest hwirq number. The disadvantage is that hwirq to IRQ number lookup is dependent on how many entries are in the table. -Very few drivers should need this mapping. At the moment, powerpc -iseries is the only user. +Very few drivers should need this mapping. No Map ===- irq_domain_add_nomap() -- 2.1.1 -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 00/23] Generic BMIPS kernel
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 other subsystems (like the native-endian serial8250/DT patches).
For 3.19 you'll want the first patch at the minimum (because the build is
currently broken).
Brian Norris (1):
irqchip: brcmstb-l2: don't clear wakeable interrupts at init time
Kevin Cernekee (22):
MIPS: bcm3384: Fix outdated use of mips_cpu_intc_init()
MIPS: Create a common
MIPS: bcm3384: Rename "bcm3384" target to "bmips"
irqchip: Update docs regarding irq_domain_add_tree()
irqchip: bcm7120-l2: Refactor driver for arbitrary IRQEN/IRQSTAT
offsets
irqchip: bcm7120-l2: Split STB-specific logic into its own function
irqchip: bcm7120-l2: Add support for BCM3380-style controllers
irqchip: Add new driver for BCM7038-style level 1 interrupt
controllers
MIPS: Let __dt_register_buses accept a single bus type
MIPS: Fall back to the generic restart notifier
MIPS: Reorder MIPS_L1_CACHE_SHIFT priorities
MIPS: BMIPS: Flush the readahead cache after DMA
MIPS: BMIPS: Document the firmware->kernel DTB interface
MIPS: BMIPS: Rewrite DMA code to use "dma-ranges" property
MIPS: BMIPS: Remove bogus bus name
MIPS: BMIPS: Add quirks for several Broadcom platforms
MIPS: BMIPS: Delete the irqchip driver from irq.c
MIPS: BMIPS: Use a non-default FIXADDR_TOP setting
MIPS: BMIPS: Enable additional peripheral and CPU support in defconfig
MIPS: BMIPS: Refresh BCM3384 DTS files
MIPS: BMIPS: Update DT bindings to reflect new SoC support
MIPS: BMIPS: Add DTS files for several platforms
Documentation/IRQ-domain.txt | 3 +-
.../interrupt-controller/brcm,bcm3380-l2-intc.txt | 41 +++
.../interrupt-controller/brcm,bcm7038-l1-intc.txt | 52
.../interrupt-controller/brcm,bcm7120-l2-intc.txt | 12 +-
.../devicetree/bindings/mips/brcm/bcm3384-intc.txt | 37 ---
.../devicetree/bindings/mips/brcm/cm-dsl.txt | 11 -
.../devicetree/bindings/mips/brcm/soc.txt | 12 +
Documentation/devicetree/booting-without-of.txt| 28 ++
arch/mips/Kbuild.platforms | 2 +-
arch/mips/Kconfig | 37 ++-
arch/mips/bcm3384/Platform | 7 -
arch/mips/bcm3384/dma.c| 81 -
arch/mips/bcm3384/irq.c| 193
arch/mips/bcm3384/setup.c | 97 --
arch/mips/bmips/Kconfig| 50 +++
arch/mips/{bcm3384 => bmips}/Makefile | 0
arch/mips/bmips/Platform | 7 +
arch/mips/bmips/dma.c | 117 +++
arch/mips/bmips/irq.c | 38 +++
arch/mips/bmips/setup.c| 194
arch/mips/boot/dts/Makefile| 10 +-
arch/mips/boot/dts/bcm3384.dtsi| 109 ---
arch/mips/boot/dts/bcm3384_viper.dtsi | 108 +++
arch/mips/boot/dts/bcm3384_zephyr.dtsi | 126
arch/mips/boot/dts/bcm6328.dtsi| 86 ++
arch/mips/boot/dts/bcm6368.dtsi| 93 ++
arch/mips/boot/dts/bcm7125.dtsi| 139 +
arch/mips/boot/dts/bcm7346.dtsi| 224 ++
arch/mips/boot/dts/bcm7360.dtsi| 161 ++
arch/mips/boot/dts/bcm7420.dtsi| 184 +++
arch/mips/boot/dts/bcm7425.dtsi| 225 ++
arch/mips/boot/dts/bcm93384wvg.dts | 9 +-
arch/mips/boot/dts/bcm93384wvg_viper.dts | 25 ++
arch/mips/boot/dts/bcm96368mvwg.dts| 31 ++
arch/mips/boot/dts/bcm97125cbmb.dts| 31 ++
arch/mips/boot/dts/bcm97346dbsmb.dts | 58
arch/mips/boot/dts/bcm97360svmb.dts| 34 +++
arch/mips/boot/dts/bcm97420c.dts | 45 +++
arch/mips/boot/dts/bcm97425svmb.dts| 60
arch/mips/boot/dts/bcm9ejtagprb.dts| 22 ++
.../{bcm3384_defconfig => bmips_be_defconfig} | 11 +-
arch/mips/configs/bmips_stb_defconfig | 88 ++
arch/mips/include/asm/mach-ar7/war.h | 24 --
arch/mips/include/asm/mach-ath25/war.h | 25 --
arch/mips/include/asm/mach-ath79/war.h | 24 --
arch/mips/include/asm/mach-au1x00/war.h| 24 --
arch/mips/include/asm/mach-bcm3384/war.h | 24 --
arch/mips/include/asm/mach-bcm47xx/war.h | 24 --
arch/mips/include/asm/mach-bcm63xx/war.h | 24 --
.../{mach-bcm3384 => mach-bmips}/dma-coherence.h | 6 +-
arch/mips/include/asm/mach-bmips/spa
[PATCH V5 03/23] MIPS: bcm3384: Rename "bcm3384" target to "bmips"
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| 12 ++--
arch/mips/bcm3384/Platform | 7 ---
arch/mips/{bcm3384 => bmips}/Makefile| 0
arch/mips/bmips/Platform | 7 +++
arch/mips/{bcm3384 => bmips}/dma.c | 0
arch/mips/{bcm3384 => bmips}/irq.c | 0
arch/mips/{bcm3384 => bmips}/setup.c | 2 +-
arch/mips/boot/dts/Makefile | 2 +-
arch/mips/configs/{bcm3384_defconfig => bmips_be_defconfig} | 2 +-
.../include/asm/{mach-bcm3384 => mach-bmips}/dma-coherence.h | 6 +++---
11 files changed, 20 insertions(+), 20 deletions(-)
delete mode 100644 arch/mips/bcm3384/Platform
rename arch/mips/{bcm3384 => bmips}/Makefile (100%)
create mode 100644 arch/mips/bmips/Platform
rename arch/mips/{bcm3384 => bmips}/dma.c (100%)
rename arch/mips/{bcm3384 => bmips}/irq.c (100%)
rename arch/mips/{bcm3384 => bmips}/setup.c (98%)
rename arch/mips/configs/{bcm3384_defconfig => bmips_be_defconfig} (98%)
rename arch/mips/include/asm/{mach-bcm3384 => mach-bmips}/dma-coherence.h (90%)
diff --git a/arch/mips/Kbuild.platforms b/arch/mips/Kbuild.platforms
index e5fc463..a4d1e4f 100644
--- a/arch/mips/Kbuild.platforms
+++ b/arch/mips/Kbuild.platforms
@@ -4,9 +4,9 @@ platforms += alchemy
platforms += ar7
platforms += ath25
platforms += ath79
-platforms += bcm3384
platforms += bcm47xx
platforms += bcm63xx
+platforms += bmips
platforms += cavium-octeon
platforms += cobalt
platforms += dec
diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
index 3289969..31bbec0 100644
--- a/arch/mips/Kconfig
+++ b/arch/mips/Kconfig
@@ -130,8 +130,8 @@ config ATH79
help
Support for the Atheros AR71XX/AR724X/AR913X SoCs.
-config BCM3384
- bool "Broadcom BCM3384 based boards"
+config BMIPS_GENERIC
+ bool "Broadcom Generic BMIPS kernel"
select BOOT_RAW
select NO_EXCEPT_FILL
select USE_OF
@@ -151,10 +151,10 @@ config BCM3384
select USB_OHCI_BIG_ENDIAN_DESC
select USB_OHCI_BIG_ENDIAN_MMIO
help
- Support for BCM3384 based boards. BCM3384/BCM33843 is a cable modem
- chipset with a Linux application processor that is often used to
- provide Samba services, a CUPS print server, and/or advanced routing
- features.
+ Build a generic DT-based kernel image that boots on select
+ BCM33xx cable modem chips, BCM63xx DSL chips, and BCM7xxx set-top
+ box chips. Note that CONFIG_CPU_BIG_ENDIAN/CONFIG_CPU_LITTLE_ENDIAN
+ must be set appropriately for your board.
config BCM47XX
bool "Broadcom BCM47XX based boards"
diff --git a/arch/mips/bcm3384/Platform b/arch/mips/bcm3384/Platform
deleted file mode 100644
index 8e1ca08..000
diff --git a/arch/mips/bcm3384/Makefile b/arch/mips/bmips/Makefile
similarity index 100%
rename from arch/mips/bcm3384/Makefile
rename to arch/mips/bmips/Makefile
diff --git a/arch/mips/bmips/Platform b/arch/mips/bmips/Platform
new file mode 100644
index 000..5f127fd
--- /dev/null
+++ b/arch/mips/bmips/Platform
@@ -0,0 +1,7 @@
+#
+# Broadcom Generic BMIPS kernel
+#
+platform-$(CONFIG_BMIPS_GENERIC) += bmips/
+cflags-$(CONFIG_BMIPS_GENERIC) += \
+ -I$(srctree)/arch/mips/include/asm/mach-bmips/
+load-$(CONFIG_BMIPS_GENERIC) := 0x8001
diff --git a/arch/mips/bcm3384/dma.c b/arch/mips/bmips/dma.c
similarity index 100%
rename from arch/mips/bcm3384/dma.c
rename to arch/mips/bmips/dma.c
diff --git a/arch/mips/bcm3384/irq.c b/arch/mips/bmips/irq.c
similarity index 100%
rename from arch/mips/bcm3384/irq.c
rename to arch/mips/bmips/irq.c
diff --git a/arch/mips/bcm3384/setup.c b/arch/mips/bmips/setup.c
similarity index 98%
rename from arch/mips/bcm3384/setup.c
rename to arch/mips/bmips/setup.c
index d84b840..5099109 100644
--- a/arch/mips/bcm3384/setup.c
+++ b/arch/mips/bmips/setup.c
@@ -33,7 +33,7 @@ void __init prom_free_prom_memory(void)
const char *get_system_type(void)
{
- return "BCM3384";
+ return "Generic BMIPS kernel";
}
void __init plat_time_init(void)
diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
index 4f49fa4..18d 100644
--- a/arch/mips/boot/dts/Makefile
+++ b/arch/mips/boot/dts/Makefile
@@ -1,4 +1,4 @@
-dtb-$(CONFIG_BCM3384) += bcm93384wvg.dtb
+dtb-$(CONFIG_BMIPS_GENERIC)+= bcm93384wvg.dtb
dtb-$(CONFIG_CAVIUM_OCTEON_SOC)+= octeon_3xxx.dtb
octeon_68xx.dtb
dtb-$(CONFIG_DT_EASY50712) += easy50712.dtb
[PATCH V5 08/23] irqchip: bcm7120-l2: Add support for BCM3380-style controllers
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
drivers/irqchip/irq-bcm7120-l2.c | 55 --
2 files changed, 92 insertions(+), 4 deletions(-)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/brcm,bcm3380-l2-intc.txt
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm3380-l2-intc.txt
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm3380-l2-intc.txt
new file mode 100644
index 000..8f48aad
--- /dev/null
+++
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm3380-l2-intc.txt
@@ -0,0 +1,41 @@
+Broadcom BCM3380-style Level 1 / Level 2 interrupt controller
+
+This interrupt controller shows up in various forms on many BCM338x/BCM63xx
+chipsets. It has the following properties:
+
+- outputs a single interrupt signal to its interrupt controller parent
+
+- contains one or more enable/status word pairs, which often appear at
+ different offsets in different blocks
+
+- no atomic set/clear operations
+
+Required properties:
+
+- compatible: should be "brcm,bcm3380-l2-intc"
+- reg: specifies one or more enable/status pairs, in the following format:
+ ...
+- interrupt-controller: identifies the node as an interrupt controller
+- #interrupt-cells: specifies the number of cells needed to encode an interrupt
+ source, should be 1.
+- interrupt-parent: specifies the phandle to the parent interrupt controller
+ this one is cascaded from
+- interrupts: specifies the interrupt line in the interrupt-parent controller
+ node, valid values depend on the type of parent interrupt controller
+
+Optional properties:
+
+- brcm,irq-can-wake: if present, this means the L2 controller can be used as a
+ wakeup source for system suspend/resume.
+
+Example:
+
+irq0_intc: interrupt-controller@1020 {
+ compatible = "brcm,bcm3380-l2-intc";
+ reg = <0x1024 0x4 0x102c 0x4>,
+ <0x1020 0x4 0x1028 0x4>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ interrupt-parent = <&cpu_intc>;
+ interrupts = <2>;
+};
diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index 6a62858..3ba5cc7 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -120,10 +121,15 @@ static int bcm7120_l2_intc_init_one(struct device_node
*dn,
/* For multiple parent IRQs with multiple words, this looks like:
*
*/
- for (idx = 0; idx < data->n_words; idx++)
- data->irq_map_mask[idx] |=
- be32_to_cpup(data->map_mask_prop +
-irq * data->n_words + idx);
+ for (idx = 0; idx < data->n_words; idx++) {
+ if (data->map_mask_prop) {
+ data->irq_map_mask[idx] |=
+ be32_to_cpup(data->map_mask_prop +
+irq * data->n_words + idx);
+ } else {
+ data->irq_map_mask[idx] = 0x;
+ }
+ }
irq_set_handler_data(parent_irq, data);
irq_set_chained_handler(parent_irq, bcm7120_l2_intc_irq_handle);
@@ -165,6 +171,37 @@ static int __init bcm7120_l2_intc_iomap_7120(struct
device_node *dn,
return 0;
}
+static int __init bcm7120_l2_intc_iomap_3380(struct device_node *dn,
+struct bcm7120_l2_intc_data *data)
+{
+ unsigned int gc_idx;
+
+ for (gc_idx = 0; gc_idx < MAX_WORDS; gc_idx++) {
+ unsigned int map_idx = gc_idx * 2;
+ void __iomem *en = of_iomap(dn, map_idx + 0);
+ void __iomem *stat = of_iomap(dn, map_idx + 1);
+ void __iomem *base = min(en, stat);
+
+ data->map_base[map_idx + 0] = en;
+ data->map_base[map_idx + 1] = stat;
+
+ if (!base)
+ break;
+
+ data->pair_base[gc_idx] = base;
+ data->en_offset[gc_idx] = en - base;
+ data->stat_offset[gc_idx] = stat - base;
+ }
+
+ if (!gc_idx) {
+ pr_err("unable to map registers\n");
+ return -EINVAL;
+ }
+
+ data->n_words = gc_idx;
+ return 0;
+}
+
int __init bcm7120_l2_intc_probe(struct device_node *dn,
struct device_node *parent,
int (*iomap_regs_fn)(struct device_node *,
@@ -279,5 +316,15 @@ int __init bcm7120_l2_intc_probe_7120(struct device_node
*dn,
"BCM7120 L2");
}
+int __init bcm7120_l2_intc_probe_
[PATCH V5 11/23] MIPS: Fall back to the generic restart notifier
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 insertions(+)
diff --git a/arch/mips/kernel/reset.c b/arch/mips/kernel/reset.c
index 07fc524..cf23ab5 100644
--- a/arch/mips/kernel/reset.c
+++ b/arch/mips/kernel/reset.c
@@ -29,6 +29,8 @@ void machine_restart(char *command)
{
if (_machine_restart)
_machine_restart(command);
+ else
+ do_kernel_restart(command);
}
void machine_halt(void)
--
2.1.1
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 05/23] irqchip: brcmstb-l2: don't clear wakeable interrupts at init time
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 call
request_irq(). (This is technically already the correct development
practice, but some drivers probably expect not to receive interrupts
until they have performed some I/O.)
Signed-off-by: Brian Norris
Signed-off-by: Kevin Cernekee
---
drivers/irqchip/irq-brcmstb-l2.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/irqchip/irq-brcmstb-l2.c b/drivers/irqchip/irq-brcmstb-l2.c
index 313c2c6..d6bcc6b 100644
--- a/drivers/irqchip/irq-brcmstb-l2.c
+++ b/drivers/irqchip/irq-brcmstb-l2.c
@@ -136,7 +136,11 @@ int __init brcmstb_l2_intc_of_init(struct device_node *np,
/* Disable all interrupts by default */
writel(0x, data->base + CPU_MASK_SET);
- writel(0x, data->base + CPU_CLEAR);
+
+ /* Wakeup interrupts may be retained from S5 (cold boot) */
+ data->can_wake = of_property_read_bool(np, "brcm,irq-can-wake");
+ if (!data->can_wake)
+ writel(0x, data->base + CPU_CLEAR);
data->parent_irq = irq_of_parse_and_map(np, 0);
if (!data->parent_irq) {
@@ -188,8 +192,7 @@ int __init brcmstb_l2_intc_of_init(struct device_node *np,
ct->chip.irq_suspend = brcmstb_l2_intc_suspend;
ct->chip.irq_resume = brcmstb_l2_intc_resume;
- if (of_property_read_bool(np, "brcm,irq-can-wake")) {
- data->can_wake = true;
+ if (data->can_wake) {
/* This IRQ chip can wake the system, set all child interrupts
* in wake_enabled mask
*/
--
2.1.1
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 06/23] irqchip: bcm7120-l2: Refactor driver for arbitrary IRQEN/IRQSTAT offsets
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 the IRQEN and IRQSTAT registers will be
covered by a single ioremap() operation.
- Don't assume any particular ordering (IRQSTAT might show up before
IRQEN on some chips).
- For an L2 controller with >=64 IRQs, don't assume that every
IRQEN/IRQSTAT pair will use the same register spacing.
This patch changes the "plumbing" but doesn't yet provide a way for users
to instantiate a controller with arbitrary IRQEN/IRQSTAT offsets.
Signed-off-by: Kevin Cernekee
---
drivers/irqchip/irq-bcm7120-l2.c | 41 +++-
1 file changed, 28 insertions(+), 13 deletions(-)
diff --git a/drivers/irqchip/irq-bcm7120-l2.c b/drivers/irqchip/irq-bcm7120-l2.c
index 8eec8e1..e8441ee 100644
--- a/drivers/irqchip/irq-bcm7120-l2.c
+++ b/drivers/irqchip/irq-bcm7120-l2.c
@@ -34,11 +34,15 @@
#define IRQSTAT0x04
#define MAX_WORDS 4
+#define MAX_MAPPINGS MAX_WORDS
#define IRQS_PER_WORD 32
struct bcm7120_l2_intc_data {
unsigned int n_words;
- void __iomem *base[MAX_WORDS];
+ void __iomem *map_base[MAX_MAPPINGS];
+ void __iomem *pair_base[MAX_WORDS];
+ int en_offset[MAX_WORDS];
+ int stat_offset[MAX_WORDS];
struct irq_domain *domain;
bool can_wake;
u32 irq_fwd_mask[MAX_WORDS];
@@ -61,7 +65,8 @@ static void bcm7120_l2_intc_irq_handle(unsigned int irq,
struct irq_desc *desc)
int hwirq;
irq_gc_lock(gc);
- pending = irq_reg_readl(gc, IRQSTAT) & gc->mask_cache;
+ pending = irq_reg_readl(gc, b->stat_offset[idx]) &
+ gc->mask_cache;
irq_gc_unlock(gc);
for_each_set_bit(hwirq, &pending, IRQS_PER_WORD) {
@@ -76,21 +81,24 @@ static void bcm7120_l2_intc_irq_handle(unsigned int irq,
struct irq_desc *desc)
static void bcm7120_l2_intc_suspend(struct irq_data *d)
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
struct bcm7120_l2_intc_data *b = gc->private;
irq_gc_lock(gc);
if (b->can_wake)
- irq_reg_writel(gc, gc->mask_cache | gc->wake_active, IRQEN);
+ irq_reg_writel(gc, gc->mask_cache | gc->wake_active,
+ ct->regs.mask);
irq_gc_unlock(gc);
}
static void bcm7120_l2_intc_resume(struct irq_data *d)
{
struct irq_chip_generic *gc = irq_data_get_irq_chip_data(d);
+ struct irq_chip_type *ct = irq_data_get_chip_type(d);
/* Restore the saved mask */
irq_gc_lock(gc);
- irq_reg_writel(gc, gc->mask_cache, IRQEN);
+ irq_reg_writel(gc, gc->mask_cache, ct->regs.mask);
irq_gc_unlock(gc);
}
@@ -137,9 +145,14 @@ int __init bcm7120_l2_intc_of_init(struct device_node *dn,
return -ENOMEM;
for (idx = 0; idx < MAX_WORDS; idx++) {
- data->base[idx] = of_iomap(dn, idx);
- if (!data->base[idx])
+ data->map_base[idx] = of_iomap(dn, idx);
+ if (!data->map_base[idx])
break;
+
+ data->pair_base[idx] = data->map_base[idx];
+ data->en_offset[idx] = IRQEN;
+ data->stat_offset[idx] = IRQSTAT;
+
data->n_words = idx + 1;
}
if (!data->n_words) {
@@ -157,7 +170,8 @@ int __init bcm7120_l2_intc_of_init(struct device_node *dn,
if (ret == 0 || ret == -EINVAL) {
for (idx = 0; idx < data->n_words; idx++)
__raw_writel(data->irq_fwd_mask[idx],
-data->base[idx] + IRQEN);
+data->pair_base[idx] +
+data->en_offset[idx]);
} else {
/* property exists but has the wrong number of words */
pr_err("invalid int-fwd-mask property\n");
@@ -215,11 +229,12 @@ int __init bcm7120_l2_intc_of_init(struct device_node *dn,
gc = irq_get_domain_generic_chip(data->domain, irq);
gc->unused = 0x & ~data->irq_map_mask[idx];
- gc->reg_base = data->base[idx];
gc->private = data;
ct = gc->chip_types;
- ct->regs.mask = IRQEN;
+ gc->reg_base = data->pair_base[idx];
+ ct->regs.mask = data->en_offset[idx];
+
ct->chip.irq_mask = irq_gc_mask_clr_bit;
ct->chip.irq_unmask = irq_gc_mask_set_bit;
ct->chip.irq_ack = irq_gc_noop;
@@ -237,16 +252,16 @@ int __init bcm7120_l2_intc_of_init(struct
[PATCH V5 13/23] MIPS: BMIPS: Flush the readahead cache after DMA
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: Kevin Cernekee
---
arch/mips/mm/dma-default.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/mips/mm/dma-default.c b/arch/mips/mm/dma-default.c
index af5f046..ee6d12c 100644
--- a/arch/mips/mm/dma-default.c
+++ b/arch/mips/mm/dma-default.c
@@ -18,6 +18,7 @@
#include
#include
+#include
#include
#include
#include
@@ -69,6 +70,18 @@ static inline struct page *dma_addr_to_page(struct device
*dev,
*/
static inline int cpu_needs_post_dma_flush(struct device *dev)
{
+ if (boot_cpu_type() == CPU_BMIPS3300 ||
+ boot_cpu_type() == CPU_BMIPS4350 ||
+ boot_cpu_type() == CPU_BMIPS4380) {
+ void __iomem *cbr = BMIPS_GET_CBR();
+
+ /* Flush stale data out of the readahead cache */
+ __raw_writel(0x100, cbr + BMIPS_RAC_CONFIG);
+ __raw_readl(cbr + BMIPS_RAC_CONFIG);
+
+ return 0;
+ }
+
return !plat_device_is_coherent(dev) &&
(boot_cpu_type() == CPU_R1 ||
boot_cpu_type() == CPU_R12000 ||
--
2.1.1
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 16/23] MIPS: BMIPS: Remove bogus bus name
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
--- a/arch/mips/bmips/setup.c
+++ b/arch/mips/bmips/setup.c
@@ -83,7 +83,7 @@ void __init device_tree_init(void)
int __init plat_of_setup(void)
{
- return __dt_register_buses("brcm,bcm3384", "simple-bus");
+ return __dt_register_buses("simple-bus", NULL);
}
arch_initcall(plat_of_setup);
--
2.1.1
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 09/23] irqchip: Add new driver for BCM7038-style level 1 interrupt controllers
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 words)
- SMP affinity supported on most systems
- Typically connected to MIPS IRQ 2,3,2,3 on CPUs 0,1,2,3
This driver registers one IRQ domain and one IRQ chip to cover all
instances of the block. Up to 4 instances of the block may appear, as
it supports 4-way IRQ affinity on BCM7435.
The same block exists on the ARM BCM7xxx chips, but typically the ARM GIC
is used instead. So this driver is primarily intended for MIPS STB chips.
Signed-off-by: Kevin Cernekee
---
.../interrupt-controller/brcm,bcm7038-l1-intc.txt | 52
drivers/irqchip/Kconfig| 5 +
drivers/irqchip/Makefile | 1 +
drivers/irqchip/irq-bcm7038-l1.c | 335 +
4 files changed, 393 insertions(+)
create mode 100644
Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7038-l1-intc.txt
create mode 100644 drivers/irqchip/irq-bcm7038-l1.c
diff --git
a/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7038-l1-intc.txt
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7038-l1-intc.txt
new file mode 100644
index 000..cc217b2
--- /dev/null
+++
b/Documentation/devicetree/bindings/interrupt-controller/brcm,bcm7038-l1-intc.txt
@@ -0,0 +1,52 @@
+Broadcom BCM7038-style Level 1 interrupt controller
+
+This block is a first level interrupt controller that is typically connected
+directly to one of the HW INT lines on each CPU. Every BCM7xxx set-top chip
+since BCM7038 has contained this hardware.
+
+Key elements of the hardware design include:
+
+- 64, 96, 128, or 160 incoming level IRQ lines
+
+- Most onchip peripherals are wired directly to an L1 input
+
+- A separate instance of the register set for each CPU, allowing individual
+ peripheral IRQs to be routed to any CPU
+
+- Atomic mask/unmask operations
+
+- No polarity/level/edge settings
+
+- No FIFO or priority encoder logic; software is expected to read all
+ 2-5 status words to determine which IRQs are pending
+
+Required properties:
+
+- compatible: should be "brcm,bcm7038-l1-intc"
+- reg: specifies the base physical address and size of the registers;
+ the number of supported IRQs is inferred from the size argument
+- interrupt-controller: identifies the node as an interrupt controller
+- #interrupt-cells: specifies the number of cells needed to encode an interrupt
+ source, should be 1.
+- interrupt-parent: specifies the phandle to the parent interrupt controller(s)
+ this one is cascaded from
+- interrupts: specifies the interrupt line(s) in the interrupt-parent
controller
+ node; valid values depend on the type of parent interrupt controller
+
+If multiple reg ranges and interrupt-parent entries are present on an SMP
+system, the driver will allow IRQ SMP affinity to be set up through the
+/proc/irq/ interface. In the simplest possible configuration, only one
+reg range and one interrupt-parent is needed.
+
+Example:
+
+periph_intc: periph_intc@1041a400 {
+compatible = "brcm,bcm7038-l1-intc";
+reg = <0x1041a400 0x30 0x1041a600 0x30>;
+
+interrupt-controller;
+#interrupt-cells = <1>;
+
+interrupt-parent = <&cpu_intc>;
+interrupts = <2>, <3>;
+};
diff --git a/drivers/irqchip/Kconfig b/drivers/irqchip/Kconfig
index e12cb23..2ffa66a 100644
--- a/drivers/irqchip/Kconfig
+++ b/drivers/irqchip/Kconfig
@@ -48,6 +48,11 @@ config ATMEL_AIC5_IRQ
select MULTI_IRQ_HANDLER
select SPARSE_IRQ
+config BCM7038_L1_IRQ
+ bool
+ select GENERIC_IRQ_CHIP
+ select IRQ_DOMAIN
+
config BCM7120_L2_IRQ
bool
select GENERIC_IRQ_CHIP
diff --git a/drivers/irqchip/Makefile b/drivers/irqchip/Makefile
index 4954a31..446ae7a 100644
--- a/drivers/irqchip/Makefile
+++ b/drivers/irqchip/Makefile
@@ -35,6 +35,7 @@ obj-$(CONFIG_TB10X_IRQC) += irq-tb10x.o
obj-$(CONFIG_XTENSA) += irq-xtensa-pic.o
obj-$(CONFIG_XTENSA_MX)+= irq-xtensa-mx.o
obj-$(CONFIG_IRQ_CROSSBAR) += irq-crossbar.o
+obj-$(CONFIG_BCM7038_L1_IRQ) += irq-bcm7038-l1.o
obj-$(CONFIG_BCM7120_L2_IRQ) += irq-bcm7120-l2.o
obj-$(CONFIG_BRCMSTB_L2_IRQ) += irq-brcmstb-l2.o
obj-$(CONFIG_KEYSTONE_IRQ) += irq-keystone.o
diff --git a/drivers/irqchip/irq-bcm7038-l1.c b/drivers/irqchip/irq-bcm7038-l1.c
new file mode 100644
index 000..d3b8c8b
--- /dev/null
+++ b/drivers/irqchip/irq-bcm7038-l1.c
@@ -0,0 +1,335 @@
+/*
+ * Broadcom BCM7038 style Level 1 interrupt controller driver
+ *
+ * Copyright (C) 2014 Broadcom Corporation
+ * Author: Kevin Cernekee
+ *
+ * This program is free software; you can redistribute it and/or mod
[PATCH V5 12/23] MIPS: Reorder MIPS_L1_CACHE_SHIFT priorities
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 MIPS_L1_CACHE_SHIFT_x option is selected, Kconfig sets CONFIG_MIPS_L1_CACHE_SHIFT to the highest value. Signed-off-by: Kevin Cernekee --- arch/mips/Kconfig | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 31bbec0..d28c29e 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -1193,10 +1193,10 @@ config MIPS_L1_CACHE_SHIFT_7 config MIPS_L1_CACHE_SHIFT int - default "4" if MIPS_L1_CACHE_SHIFT_4 - default "5" if MIPS_L1_CACHE_SHIFT_5 - default "6" if MIPS_L1_CACHE_SHIFT_6 default "7" if MIPS_L1_CACHE_SHIFT_7 + default "6" if MIPS_L1_CACHE_SHIFT_6 + default "5" if MIPS_L1_CACHE_SHIFT_5 + default "4" if MIPS_L1_CACHE_SHIFT_4 default "5" config HAVE_STD_PC_SERIAL_PORT -- 2.1.1 -- 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 http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 10/23] MIPS: Let __dt_register_buses accept a single bus type
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
--- a/arch/mips/kernel/prom.c
+++ b/arch/mips/kernel/prom.c
@@ -64,7 +64,10 @@ int __init __dt_register_buses(const char *bus0, const char
*bus1)
panic("device tree not present");
strlcpy(of_ids[0].compatible, bus0, sizeof(of_ids[0].compatible));
- strlcpy(of_ids[1].compatible, bus1, sizeof(of_ids[1].compatible));
+ if (bus1) {
+ strlcpy(of_ids[1].compatible, bus1,
+ sizeof(of_ids[1].compatible));
+ }
if (of_platform_populate(NULL, of_ids, NULL, NULL))
panic("failed to populate DT");
--
2.1.1
--
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 http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V5 15/23] MIPS: BMIPS: Rewrite DMA code to use "dma-ranges" property
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 a/arch/mips/bmips/dma.c b/arch/mips/bmips/dma.c
index ea42012..04790f4 100644
--- a/arch/mips/bmips/dma.c
+++ b/arch/mips/bmips/dma.c
@@ -6,76 +6,112 @@
* Copyright (C) 2014 Kevin Cernekee
*/
+#define pr_fmt(fmt)"bmips-dma: " fmt
+
#include
#include
#include
#include
-#include
+#include
#include
-#include
+#include
+#include
#include
#include
/*
- * BCM3384 has configurable address translation windows which allow the
+ * BCM338x has configurable address translation windows which allow the
* peripherals' DMA addresses to be different from the Zephyr-visible
* physical addresses. e.g. usb_dma_addr = zephyr_pa ^ 0x0800
*
- * If our DT "memory" node has a "dma-xor-mask" property we will enable this
- * translation using the provided offset.
+ * If the "brcm,ubus" node has a "dma-ranges" property we will enable this
+ * translation globally using the provided information. This implements a
+ * very limited subset of "dma-ranges" support and it will probably be
+ * replaced by a more generic version later.
*/
-static u32 bcm3384_dma_xor_mask;
-static u32 bcm3384_dma_xor_limit = 0x;
-/*
- * PCI collapses the memory hole at 0x1000 - 0x1fff.
- * On systems with a dma-xor-mask, this range is guaranteed to live above
- * the dma-xor-limit.
- */
-#define BCM3384_MEM_HOLE_PA0x1000
-#define BCM3384_MEM_HOLE_SIZE 0x1000
+struct bmips_dma_range {
+ u32 child_addr;
+ u32 parent_addr;
+ u32 size;
+};
-static dma_addr_t bcm3384_phys_to_dma(struct device *dev, phys_addr_t pa)
+static struct bmips_dma_range *bmips_dma_ranges;
+
+#define FLUSH_RAC 0x100
+
+static dma_addr_t bmips_phys_to_dma(struct device *dev, phys_addr_t pa)
{
- if (dev && dev_is_pci(dev) &&
- pa >= (BCM3384_MEM_HOLE_PA + BCM3384_MEM_HOLE_SIZE))
- return pa - BCM3384_MEM_HOLE_SIZE;
- if (pa <= bcm3384_dma_xor_limit)
- return pa ^ bcm3384_dma_xor_mask;
+ struct bmips_dma_range *r;
+
+ for (r = bmips_dma_ranges; r && r->size; r++) {
+ if (pa >= r->child_addr &&
+ pa < (r->child_addr + r->size))
+ return pa - r->child_addr + r->parent_addr;
+ }
return pa;
}
dma_addr_t plat_map_dma_mem(struct device *dev, void *addr, size_t size)
{
- return bcm3384_phys_to_dma(dev, virt_to_phys(addr));
+ return bmips_phys_to_dma(dev, virt_to_phys(addr));
}
dma_addr_t plat_map_dma_mem_page(struct device *dev, struct page *page)
{
- return bcm3384_phys_to_dma(dev, page_to_phys(page));
+ return bmips_phys_to_dma(dev, page_to_phys(page));
}
unsigned long plat_dma_addr_to_phys(struct device *dev, dma_addr_t dma_addr)
{
- if (dev && dev_is_pci(dev) &&
- dma_addr >= BCM3384_MEM_HOLE_PA)
- return dma_addr + BCM3384_MEM_HOLE_SIZE;
- if ((dma_addr ^ bcm3384_dma_xor_mask) <= bcm3384_dma_xor_limit)
- return dma_addr ^ bcm3384_dma_xor_mask;
+ struct bmips_dma_range *r;
+
+ for (r = bmips_dma_ranges; r && r->size; r++) {
+ if (dma_addr >= r->parent_addr &&
+ dma_addr < (r->parent_addr + r->size))
+ return dma_addr - r->parent_addr + r->child_addr;
+ }
return dma_addr;
}
-static int __init bcm3384_init_dma_xor(void)
+static int __init bmips_init_dma_ranges(void)
{
- struct device_node *np = of_find_node_by_type(NULL, "memory");
+ struct device_node *np =
+ of_find_compatible_node(NULL, NULL, "brcm,ubus");
+ const __be32 *data;
+ struct bmips_dma_range *r;
+ int len;
if (!np)
return 0;
- of_property_read_u32(np, "dma-xor-mask", &bcm3384_dma_xor_mask);
- of_property_read_u32(np, "dma-xor-limit", &bcm3384_dma_xor_limit);
+ data = of_get_property(np, "dma-ranges", &len);
+ if (!data)
+ goto out_good;
+
+ len /= sizeof(*data) * 3;
+ if (!len)
+ goto out_bad;
+
+ /* add a dummy (zero) entry at the end as a sentinel */
+ bmips_dma_ranges = kzalloc(sizeof(struct bmips_dma_range) * (len + 1),
+ GFP_KERNEL);
+ if (!bmips_dma_ranges)
+ goto out_bad;
+ for (r = bmips_dma_ranges; len; len--, r++) {
+ r->child_addr = be32_to_cpup(data++);
+ r->parent_addr = be32_to_cpup(data++);
+ r->size = be32_to_cpup(data++);
+ }
+
+out_good:
of_node_put(np);
return 0;
+
+out_bad:
+ pr_
