Re: [PATCH v6 3/8] arm, dts: add TC2 cpu capacity-dmips-mhz information
Hi Juri, On 19/07/16 13:40, Juri Lelli wrote: Add TC2 cpu capacity binding information. If you repost it, s/binding// Cc: Liviu Dudau Cc: Sudeep Holla Acked-by: Sudeep Holla (assuming you take it via some other tree, let us know if it's OK to merge the DTS separately and you want us to pick them) -- Regards, Sudeep
[tip:sched/core] sched/fair: Fix typo in sync_throttle()
Commit-ID: b8922125e4790fa237a8a4204562ecf457ef54bb
Gitweb: http://git.kernel.org/tip/b8922125e4790fa237a8a4204562ecf457ef54bb
Author: Xunlei Pang
AuthorDate: Sat, 9 Jul 2016 15:54:22 +0800
Committer: Ingo Molnar
CommitDate: Wed, 10 Aug 2016 13:32:55 +0200
sched/fair: Fix typo in sync_throttle()
We should update cfs_rq->throttled_clock_task, not
pcfs_rq->throttle_clock_task.
The effects of this bug was probably occasionally erratic
group scheduling, particularly in cgroups-intense workloads.
Signed-off-by: Xunlei Pang
[ Added changelog. ]
Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Konstantin Khlebnikov
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Fixes: 55e16d30bd99 ("sched/fair: Rework throttle_count sync")
Link:
http://lkml.kernel.org/r/1468050862-18864-1-git-send-email-xlp...@redhat.com
Signed-off-by: Ingo Molnar
---
kernel/sched/fair.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 4088eed..039de34 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -4269,7 +4269,7 @@ static void sync_throttle(struct task_group *tg, int cpu)
pcfs_rq = tg->parent->cfs_rq[cpu];
cfs_rq->throttle_count = pcfs_rq->throttle_count;
- pcfs_rq->throttled_clock_task = rq_clock_task(cpu_rq(cpu));
+ cfs_rq->throttled_clock_task = rq_clock_task(cpu_rq(cpu));
}
/* conditionally throttle active cfs_rq's from put_prev_entity() */
Re: [PACTH v1] mm, proc: Implement /proc//totmaps
On 2016-08-09 04:17 PM, Robert Foss wrote:
+static int totmaps_proc_show(struct seq_file *m, void *data)
+{
+struct proc_maps_private *priv = m->private;
+struct mm_struct *mm;
+struct vm_area_struct *vma;
+struct mem_size_stats *mss_sum = priv->mss;
+
+/* reference to priv->task already taken */
+/* but need to get the mm here because */
+/* task could be in the process of exiting */
+mm = get_task_mm(priv->task);
+if (!mm || IS_ERR(mm))
+return -EINVAL;
+
That's not how it's done in smaps.
Alright, I'll have to look into the difference between this approach and
the smaps one.
I had a look at show_smaps(), and it's not entirely clear to me what the
advantage of doing it show_smaps() way.
mm = get_task_mm(priv->task) is needed to iterate through all of the
mappings. Is there a preferable way of doing that?
[tip:sched/core] sched/fair: Remove 'cpu_busy' parameter from update_next_balance()
Commit-ID: 31851a9874d63dbb532910a86b2be49c15997ea3
Gitweb: http://git.kernel.org/tip/31851a9874d63dbb532910a86b2be49c15997ea3
Author: Leo Yan
AuthorDate: Fri, 5 Aug 2016 14:31:29 +0800
Committer: Ingo Molnar
CommitDate: Wed, 10 Aug 2016 14:03:32 +0200
sched/fair: Remove 'cpu_busy' parameter from update_next_balance()
The update_next_balance() function is only used by idle balancing, so its
'cpu_busy' parameter is always 0.
Open code it instead of passing it around.
Signed-off-by: Leo Yan
Signed-off-by: Peter Zijlstra (Intel)
Cc: Linus Torvalds
Cc: Mike Galbraith
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: linux-kernel@vger.kernel.org
Link:
http://lkml.kernel.org/r/1470378689-14892-1-git-send-email-leo@linaro.org
Signed-off-by: Ingo Molnar
---
kernel/sched/fair.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 039de34..d300536 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -7704,11 +7704,12 @@ get_sd_balance_interval(struct sched_domain *sd, int
cpu_busy)
}
static inline void
-update_next_balance(struct sched_domain *sd, int cpu_busy, unsigned long
*next_balance)
+update_next_balance(struct sched_domain *sd, unsigned long *next_balance)
{
unsigned long interval, next;
- interval = get_sd_balance_interval(sd, cpu_busy);
+ /* used by idle balance, so cpu_busy = 0 */
+ interval = get_sd_balance_interval(sd, 0);
next = sd->last_balance + interval;
if (time_after(*next_balance, next))
@@ -7738,7 +7739,7 @@ static int idle_balance(struct rq *this_rq)
rcu_read_lock();
sd = rcu_dereference_check_sched_domain(this_rq->sd);
if (sd)
- update_next_balance(sd, 0, &next_balance);
+ update_next_balance(sd, &next_balance);
rcu_read_unlock();
goto out;
@@ -7756,7 +7757,7 @@ static int idle_balance(struct rq *this_rq)
continue;
if (this_rq->avg_idle < curr_cost + sd->max_newidle_lb_cost) {
- update_next_balance(sd, 0, &next_balance);
+ update_next_balance(sd, &next_balance);
break;
}
@@ -7774,7 +7775,7 @@ static int idle_balance(struct rq *this_rq)
curr_cost += domain_cost;
}
- update_next_balance(sd, 0, &next_balance);
+ update_next_balance(sd, &next_balance);
/*
* Stop searching for tasks to pull if there are
Re: [PATCH] video: fbdev: mb862xx: mb862xx-i2c: don't print error when adding adapter fails
> One comment: the patch description should be "stand-alone" text, not a > continuation of the subject. I fixed this. I see. Will keep that in mind for the future. Thanks! signature.asc Description: PGP signature
[PATCH v2 4/4] ARM: dts: da850-lcdk: Add NAND to DT
This adds DT support for the NAND connected to the SoC AEMIF.
The parameters (timings, ecc) are the same as what the board ships with
(default AEMIF timings, 1bit ECC) and improvements will be handled in
due course.
This passed elementary tests hashing a 20MB file on top of ubifs on my
LCDK.
Signed-off-by: Karl Beldan
---
arch/arm/boot/dts/da850-lcdk.dts | 107 +++
1 file changed, 107 insertions(+)
diff --git a/arch/arm/boot/dts/da850-lcdk.dts b/arch/arm/boot/dts/da850-lcdk.dts
index dbcca0b..a3f9845 100644
--- a/arch/arm/boot/dts/da850-lcdk.dts
+++ b/arch/arm/boot/dts/da850-lcdk.dts
@@ -27,6 +27,27 @@
&pmx_core {
status = "okay";
+
+ nand_pins: nand_pins {
+ pinctrl-single,bits = <
+ /* EMA_WAIT[0], EMA_OE, EMA_WE, EMA_CS[3] */
+ 0x1c 0x10110010 0xf0ff00f0
+ /*
+* EMA_D[0], EMA_D[1], EMA_D[2],
+* EMA_D[3], EMA_D[4], EMA_D[5],
+* EMA_D[6], EMA_D[7]
+*/
+ 0x24 0x 0x
+ /*
+* EMA_D[8], EMA_D[9], EMA_D[10],
+* EMA_D[11], EMA_D[12], EMA_D[13],
+* EMA_D[14], EMA_D[15]
+*/
+ 0x20 0x 0x
+ /* EMA_A[1], EMA_A[2] */
+ 0x30 0x0110 0x0ff0
+ >;
+ };
};
&serial2 {
@@ -68,3 +89,89 @@
cd-gpios = <&gpio 64 GPIO_ACTIVE_HIGH>;
status = "okay";
};
+
+&aemif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_pins>;
+ status = "ok";
+ cs3 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-ranges;
+ ranges;
+
+ ti,cs-chipselect = <3>;
+
+ nand@200,0 {
+ compatible = "ti,davinci-nand";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0 0x0200 0x0200
+ 1 0x 0x8000>;
+
+ ti,davinci-chipselect = <1>;
+ ti,davinci-mask-ale = <0>;
+ ti,davinci-mask-cle = <0>;
+ ti,davinci-mask-chipsel = <0>;
+
+ /*
+* nand_ecc_strength_good will emit a warning
+* but the LCDK ships with these settings [1].
+* Also HW 4bits ECC with 16bits NAND seems to
+* require some attention.
+*
+* ATM nand_davinci_probe handling of nand-ecc-*
+* is broken, e.g.
+* chip.ecc.strength = pdata->ecc_bits occurs after
+* scan_ident(), otherwise I would have used:
+* nand-ecc-mode = "hw";
+* nand-ecc-strength = <1>;
+* nand-ecc-step-size = <512>;
+*/
+ ti,davinci-nand-buswidth = <16>;
+ ti,davinci-ecc-mode = "hw";
+ ti,davinci-ecc-bits = <1>;
+ ti,davinci-nand-use-bbt;
+
+ /*
+* LCDK original partitions:
+* 0x-0x0002 : "u-boot env"
+* 0x0002-0x000a : "u-boot"
+* 0x000a-0x002a : "kernel"
+* 0x002a-0x2000 : "filesystem"
+*
+* The 1st NAND block being guaranted to be valid w/o
ECC (> 1k cycles),
+* it makes a perfect candidate as an SPL for the
BootROM to jump to.
+* However the OMAP-L132/L138 Bootloader doc SPRAB41E
reads:
+* "To boot from NAND Flash, the AIS should be written
to NAND block 1
+* (NAND block 0 is not used by default)", which
matches the LCDK
+* original partitioning.
+* Also, the LCDK ships with only the u-boot partition
provisioned and
+* boots on it in its default configuration while using
the MMC for the
+* kernel and rootfs, so preserve that one as is for
now.
+* [1]: Ensuring for example that U-Boot LCDK SPL can
handle it properly
+* and a proper boot chain ROM->SPL->U-Boot->Linux wrt
ECC, would allow
+* for a better partitioning.
+*/
+ partitions {
+ compatible = "fixed-p
Re: of_clk_add_(hw_)providers multipule times for one node?
Hi Stephen, 2016-08-09 8:37 GMT+09:00 Stephen Boyd : > On 08/08, Masahiro Yamada wrote: >> Hi Stephen, >> >> >> 2016-08-05 6:25 GMT+09:00 Stephen Boyd : >> > +Rob in case he has any insight >> > >> > On 07/09, Masahiro Yamada wrote: >> >> Hi. >> >> >> >> I think the current code allows to add >> >> clk_providers multiple times against one DT node. >> >> >> >> Are there cases that really need to do so? >> > >> > If we have clk drivers that have a device driver structure and >> > also use CLK_OF_DECLARE then we could get into a situation where >> > they register two providers for the same device node. I can't >> > think of any other situation where this would happen though. >> >> >> What is the benefit for splitting one clock device >> into CLK_OF_DECLARE() and a platform_driver? >> >> >> If we go this way, I think we need to fix the current code. > > Sure. Do we have anyone registering two providers for the same > node? I'm trying to weigh the urgency of this. > >> >> of_clk_add_provider() calls of_clk_del_provider() >> in its failure path. >> >> Notice of_clk_del_provider() unregister >> all the providers associated with the device node. > > Where is that? I see a break statement in the while loop after > the first matching np is found. Ah, I missed the "break". So, this works *almost* well. I mean *almost* because the of_clk_mutex is released between of_clk_add_hw_provider() and of_clk_del_provider(). What if two providers are added concurrently. I know it never happens in use-cases we assume, though. >> >> So, if of_clk_add_provider() fails to register a platform driver, >> it may unregister another provider added by OF_CLK_DECLARE(). > > I suppose if we loop over the list in the incorrect order we > would unregister the wrong one. Right. Here, the last added will be first deleted. >> >> Some platform drivers call of_clk_del_provider() in a .remove callback, >> so the same problem could happen. >> >> Why does of_clk_del_provider() take (struct device_node *np) ? >> Shouldn't it take (struct of_clk_provider *cp)? >> > > Not sure. Probably someone thought they could hide the structure > from consumers and just return success or failure. consumers? or did you mean providers? I think consumers have no chance to call of_clk_del_provider(). > We could make > it an opaque pointer though and properly cleanup without > iterating the list. Maybe we should do that for the hw provider > API so that it simplifies the search. > >> >> >> >> > It used to return the last provider's error, but I accidentally >> > changed that behavior when adding clk_hw providers in commit >> > 0861e5b8cf80 (clk: Add clk_hw OF clk providers, 2016-02-05). >> > Nobody seems to have complained though, so you're the first to >> > have reported this. >> >> >> If we allow multiple OF-providers for one device node, >> I think any error should be treated as EPROBE_DEFER, >> i.e. the current code is good. >> >> >> The scenario is: >> >> - Clocks with ID 0 thru 3 are provided by CLK_OF_DECLARE() >> - Clocks with ID 4 thru 9 are provided by a platform driver. >> >> What if a clock consumer requests the clk ID 5 >> after CLK_OF_DECLARE(), but before the clk platform driver is registered? >> >> If the clock consumer gets the last provider's error >> (-EINVAL returned from CLK_OR_DECLARE one in this case) >> it will lose a chance to retry it after clocks from a platform driver >> are registered. >> >> A bit nasty... >> > > Yes, but right now if we get an error from a provider and that's > the only provider in the list we don't return the error. Also, > this case should be fixed by having the first provider return > EPROBE_DEFER for clks that aren't populated early on. OK. I like this idea. > The best we can do is have the framework only return probe defer > if there isn't a provider registered. Once a provider is > registered, it needs to do the right thing and return the > appropriate error (invalid or probe defer for example) at the > right time. Agreed. Lastly, we have two solutions so far. Which do you think is better? One solution is, as others suggested, CLK_OF_DECLARE() can allocate a bigger array than it needs, so that blank entries can be filled by a platfrom_driver later. The other way is, CLK_OF_DECLARE() and a platfrom_driver allocate separate of_clk_provider for each of them. -- Best Regards Masahiro Yamada
Re: [PATCH 1/7] ima: on soft reboot, restore the measurement list
Am Mittwoch, 10 August 2016, 13:41:08 schrieb Michael Ellerman:
> Thiago Jung Bauermann writes:
> > Am Dienstag, 09 August 2016, 09:01:13 schrieb Mimi Zohar:
> >> On Tue, 2016-08-09 at 20:59 +1000, Michael Ellerman wrote:
> >> > Mimi Zohar writes:
> >> > > +/* Some details preceding the binary serialized measurement list
> >> > > */
> >> > > +struct ima_kexec_hdr {
> >> > > + unsigned short version;
> >> > > + unsigned long buffer_size;
> >> > > + unsigned long count;
> >> > > +} __packed;
> >> > > +
> >> >
> >> > Am I understanding it correctly that this structure is passed between
> >> > kernels?
> >>
> >> Yes, the header prefixes the measurement list, which is being passed on
> >> the same computer to the next kernel. Could the architecture (eg.
> >> LE/BE) change between soft re-boots?
> >
> > Yes. I am able to boot a BE kernel from an LE kernel with my patches.
> > Whether we want to support that or not is another question...
>
> Yes you must support that. BE -> LE and vice versa.
I didn't test BE - LE yet, but will do.
> You should also consider the possibility that the next kernel is not
> Linux.
If the next kernel is an ELF binary and it supports the kexec "calling
convention", it should work too. What could possibly go wrong? I can try
FreeBSD (I suppose it's an ELF kernel) and see what happens.
--
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center
Re: [PATCH v3 10/13] net; ethernet: ti: cpsw: move irq stuff under cpsw_common
On Wednesday 10 August 2016 04:52 AM, Ivan Khoronzhuk wrote: > The irq data are common for net devs in dual_emac mode. So no need to > hold these data in every priv struct, move them under cpsw_common. > Also delete irq_num var, as after optimization it's not needed. > Correct number of irqs to 2, as anyway, driver is using only 2, > at least for now. > > Signed-off-by: Ivan Khoronzhuk Reviewed-by: Mugunthan V N Regards Mugunthan V N
Re: [PATCH v3 13/13] net: ethernet: ti: cpsw: move ale, cpts and drivers params under cpsw_common
On Wednesday 10 August 2016 04:52 AM, Ivan Khoronzhuk wrote: > The ale, cpts, version, rx_packet_max, bus_freq, interrupt pacing > parameters are common per net device that uses the same h/w. So, > move them to common driver structure. > > Signed-off-by: Ivan Khoronzhuk Reviewed-by: Mugunthan V N Regards Mugunthan V N
[tip:sched/core] sched/deadline: Fix lock pinning warning during CPU hotplug
Commit-ID: c0c8c9fa210c9a042060435f17e40ba4a76d6d6f
Gitweb: http://git.kernel.org/tip/c0c8c9fa210c9a042060435f17e40ba4a76d6d6f
Author: Wanpeng Li
AuthorDate: Thu, 4 Aug 2016 09:42:20 +0800
Committer: Ingo Molnar
CommitDate: Wed, 10 Aug 2016 14:02:55 +0200
sched/deadline: Fix lock pinning warning during CPU hotplug
The following warning can be triggered by hot-unplugging the CPU
on which an active SCHED_DEADLINE task is running on:
WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:3531
lock_release+0x690/0x6a0
releasing a pinned lock
Call Trace:
dump_stack+0x99/0xd0
__warn+0xd1/0xf0
? dl_task_timer+0x1a1/0x2b0
warn_slowpath_fmt+0x4f/0x60
? sched_clock+0x13/0x20
lock_release+0x690/0x6a0
? enqueue_pushable_dl_task+0x9b/0xa0
? enqueue_task_dl+0x1ca/0x480
_raw_spin_unlock+0x1f/0x40
dl_task_timer+0x1a1/0x2b0
? push_dl_task.part.31+0x190/0x190
WARNING: CPU: 0 PID: 0 at kernel/locking/lockdep.c:3649
lock_unpin_lock+0x181/0x1a0
unpinning an unpinned lock
Call Trace:
dump_stack+0x99/0xd0
__warn+0xd1/0xf0
warn_slowpath_fmt+0x4f/0x60
lock_unpin_lock+0x181/0x1a0
dl_task_timer+0x127/0x2b0
? push_dl_task.part.31+0x190/0x190
As per the comment before this code, its safe to drop the RQ lock
here, and since we (potentially) change rq, unpin and repin to avoid
the splat.
Signed-off-by: Wanpeng Li
[ Rewrote changelog. ]
Signed-off-by: Peter Zijlstra (Intel)
Cc: Juri Lelli
Cc: Linus Torvalds
Cc: Luca Abeni
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1470274940-17976-1-git-send-email-wanpeng...@hotmail.com
Signed-off-by: Ingo Molnar
---
kernel/sched/deadline.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c
index fcb7f02..1ce8867 100644
--- a/kernel/sched/deadline.c
+++ b/kernel/sched/deadline.c
@@ -658,8 +658,11 @@ static enum hrtimer_restart dl_task_timer(struct hrtimer
*timer)
*
* XXX figure out if select_task_rq_dl() deals with offline cpus.
*/
- if (unlikely(!rq->online))
+ if (unlikely(!rq->online)) {
+ lockdep_unpin_lock(&rq->lock, rf.cookie);
rq = dl_task_offline_migration(rq, p);
+ rf.cookie = lockdep_pin_lock(&rq->lock);
+ }
/*
* Queueing this task back might have overloaded rq, check if we need
Re: [PATCH] drivers: net: cpsw: fix kmemleak false-positive reports for sk buffers
On Tuesday 09 August 2016 05:39 PM, Grygorii Strashko wrote: > Kmemleak reports following false positive memory leaks for each sk > buffers allocated by CPSW (__netdev_alloc_skb_ip_align()) in > cpsw_ndo_open() and cpsw_rx_handler(): > > unreferenced object 0xea915000 (size 2048): > comm "systemd-network", pid 713, jiffies 4294938323 (age 102.180s) > hex dump (first 32 bytes): > 00 58 91 ea ff ff ff ff ff ff ff ff ff ff ff ff .X.. > ff ff ff ff ff ff fd 0f 00 00 00 00 00 00 00 00 > backtrace: > [] __kmalloc_track_caller+0x1a4/0x230 > [] __alloc_skb+0x68/0x16c > [] __netdev_alloc_skb+0x40/0x104 > [] cpsw_ndo_open+0x374/0x670 [ti_cpsw] > [] __dev_open+0xb0/0x114 > [] __dev_change_flags+0x9c/0x14c > [] dev_change_flags+0x20/0x50 > [] do_setlink+0x2cc/0x78c > [] rtnl_setlink+0xcc/0x100 > [] rtnetlink_rcv_msg+0x184/0x224 > [] netlink_rcv_skb+0xa8/0xc4 > [] rtnetlink_rcv+0x2c/0x34 > [] netlink_unicast+0x16c/0x1f8 > [] netlink_sendmsg+0x334/0x348 > [] sock_sendmsg+0x1c/0x2c > [] SyS_sendto+0xc0/0xe8 > > unreferenced object 0xec861780 (size 192): > comm "softirq", pid 0, jiffies 4294938759 (age 109.540s) > hex dump (first 32 bytes): > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 b0 5a ed 00 00 00 00 00 00 00 00 ..Z. > backtrace: > [] kmem_cache_alloc+0x190/0x208 > [] __build_skb+0x30/0x98 > [] __netdev_alloc_skb+0xb8/0x104 > [] cpsw_rx_handler+0x68/0x1e4 [ti_cpsw] > [] __cpdma_chan_free+0xa8/0xc4 [davinci_cpdma] > [] __cpdma_chan_process+0x14c/0x16c [davinci_cpdma] > [] cpdma_chan_process+0x44/0x5c [davinci_cpdma] > [] cpsw_rx_poll+0x1c/0x9c [ti_cpsw] > [] net_rx_action+0x1f0/0x2ec > [] __do_softirq+0x134/0x258 > [] do_softirq+0x68/0x70 > [] __local_bh_enable_ip+0xd4/0xe8 > [] _raw_spin_unlock_bh+0x30/0x34 > [] igmp6_group_added+0x4c/0x1bc > [] ipv6_dev_mc_inc+0x398/0x434 > [] addrconf_dad_work+0x224/0x39c > > This happens because CPSW allocates SK buffers and then passes > pointers on them in CPDMA where they stored in internal CPPI RAM > (SRAM) which belongs to DEV MMIO space. Kmemleak does not scan IO > memory and so reports memory leaks. > > Hence, mark allocated sk buffers as false positive explicitly. > > Cc: Catalin Marinas > Signed-off-by: Grygorii Strashko Reviewed-by: Mugunthan V N Regards Mugunthan V N
Re: [PATCH 0244/1285] Replace numeric parameter like 0444 with macro
> > I assume Wolfram will merge this. > > I assume not, see http://lwn.net/Articles/696227/ Thanks for the pointer. I missed the discussion but came up with the same conclusions: a) octals are easier to read and b) original author should have asked if this change was feasible before posting 1285 patches :( signature.asc Description: PGP signature
Re: [PATCH] perf intel-pt: Fix ip compression
On 20/07/16 12:00, Adrian Hunter wrote: > June 2015 Intel SDM introduced IP Compression types 4 and 6. Refer section > 36.4.2.2 Target IP (TIP) Packet - IP Compression. > > Existing Intel PT packet decoder did not support type 4, and got type 6 > wrong. Because type 3 and type 4 have the same number of bytes, the packet > 'count' has been changed from being the number of ip bytes to being the > type code. That allows the Intel PT decoder to correctly decide whether to > sign-extend or use the last ip. However that also meant the code had to be > adjusted in a number of places. > > Currently hardware is not using the new compression types, so this fix has > no effect on existing hardware. > > Signed-off-by: Adrian Hunter > --- > .../perf/util/intel-pt-decoder/intel-pt-decoder.c | 44 > +++--- > .../util/intel-pt-decoder/intel-pt-pkt-decoder.c | 24 > 2 files changed, 40 insertions(+), 28 deletions(-) Hi This is outstanding but still applies. Regards Adrian
[PATCH v2] clocksource/drivers/time-armada-370-xp: Fix the clock reference
While converting the init function to return an error, the wrong clock
was get. This lead to wrong clock rate and slow down the kernel. For
example, before the patch a typical boot was around 15s after it was 1
minute slower.
Fixes: 12549e27c63c ("clocksource/drivers/time-armada-370-xp: Convert init
function to return error")
Signed-off-by: Gregory CLEMENT
---
Changelog:
v1 -> v2
Move the of_clk_get_by_name out of the declaration as sugested by
Thomas Petazzoni.
drivers/clocksource/time-armada-370-xp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clocksource/time-armada-370-xp.c
b/drivers/clocksource/time-armada-370-xp.c
index 719b478d136e..376ed13fe739 100644
--- a/drivers/clocksource/time-armada-370-xp.c
+++ b/drivers/clocksource/time-armada-370-xp.c
@@ -335,10 +335,10 @@ static int __init armada_370_xp_timer_common_init(struct
device_node *np)
static int __init armada_xp_timer_init(struct device_node *np)
{
- struct clk *clk = of_clk_get_by_name(np, "fixed");
+ struct clk *clk;
int ret;
- clk = of_clk_get(np, 0);
+ clk = of_clk_get_by_name(np, "fixed");
if (IS_ERR(clk)) {
pr_err("Failed to get clock");
return PTR_ERR(clk);
--
2.8.1
Re: [PATCH 10/10] docs: Sphinxify gdb-kernel-debugging.txt and move to dev-tools
On 2016-08-09 01:35, Jonathan Corbet wrote:
> Cc: Jan Kiszka
> Signed-off-by: Jonathan Corbet
> ---
> .../gdb-kernel-debugging.rst} | 77
> +-
> Documentation/dev-tools/tools.rst | 1 +
> 2 files changed, 46 insertions(+), 32 deletions(-)
> rename Documentation/{gdb-kernel-debugging.txt =>
> dev-tools/gdb-kernel-debugging.rst} (73%)
>
> diff --git a/Documentation/gdb-kernel-debugging.txt
> b/Documentation/dev-tools/gdb-kernel-debugging.rst
> similarity index 73%
> rename from Documentation/gdb-kernel-debugging.txt
> rename to Documentation/dev-tools/gdb-kernel-debugging.rst
> index 7050ce8..5e93c9b 100644
> --- a/Documentation/gdb-kernel-debugging.txt
> +++ b/Documentation/dev-tools/gdb-kernel-debugging.rst
> @@ -1,3 +1,5 @@
> +.. highlight:: none
> +
> Debugging kernel and modules via gdb
>
>
> @@ -13,54 +15,58 @@ be transferred to the other gdb stubs as well.
> Requirements
>
>
> - o gdb 7.2+ (recommended: 7.4+) with python support enabled (typically true
> - for distributions)
> +- gdb 7.2+ (recommended: 7.4+) with python support enabled (typically true
> + for distributions)
>
>
> Setup
> -
>
> - o Create a virtual Linux machine for QEMU/KVM (see www.linux-kvm.org and
> - www.qemu.org for more details). For cross-development,
> - http://landley.net/aboriginal/bin keeps a pool of machine images and
> - toolchains that can be helpful to start from.
> +- Create a virtual Linux machine for QEMU/KVM (see www.linux-kvm.org and
> + www.qemu.org for more details). For cross-development,
> + http://landley.net/aboriginal/bin keeps a pool of machine images and
> + toolchains that can be helpful to start from.
>
> - o Build the kernel with CONFIG_GDB_SCRIPTS enabled, but leave
> - CONFIG_DEBUG_INFO_REDUCED off. If your architecture supports
> - CONFIG_FRAME_POINTER, keep it enabled.
> +- Build the kernel with CONFIG_GDB_SCRIPTS enabled, but leave
> + CONFIG_DEBUG_INFO_REDUCED off. If your architecture supports
> + CONFIG_FRAME_POINTER, keep it enabled.
>
> - o Install that kernel on the guest.
> +- Install that kernel on the guest.
> + Alternatively, QEMU allows to boot the kernel directly using -kernel,
> + -append, -initrd command line switches. This is generally only useful if
> + you do not depend on modules. See QEMU documentation for more details on
> + this mode.
>
> - Alternatively, QEMU allows to boot the kernel directly using -kernel,
> - -append, -initrd command line switches. This is generally only useful if
> - you do not depend on modules. See QEMU documentation for more details on
> - this mode.
> +- Enable the gdb stub of QEMU/KVM, either
>
> - o Enable the gdb stub of QEMU/KVM, either
> - at VM startup time by appending "-s" to the QEMU command line
> - or
> +
> + or
> +
> - during runtime by issuing "gdbserver" from the QEMU monitor
>console
>
> - o cd /path/to/linux-build
> +- cd /path/to/linux-build
>
> - o Start gdb: gdb vmlinux
> +- Start gdb: gdb vmlinux
>
> - Note: Some distros may restrict auto-loading of gdb scripts to known safe
> - directories. In case gdb reports to refuse loading vmlinux-gdb.py, add
> + Note: Some distros may restrict auto-loading of gdb scripts to known safe
> + directories. In case gdb reports to refuse loading vmlinux-gdb.py, add::
>
> add-auto-load-safe-path /path/to/linux-build
>
> - to ~/.gdbinit. See gdb help for more details.
> + to ~/.gdbinit. See gdb help for more details.
> +
> +- Attach to the booted guest::
>
> - o Attach to the booted guest:
> (gdb) target remote :1234
>
>
> Examples of using the Linux-provided gdb helpers
>
>
> - o Load module (and main kernel) symbols:
> +- Load module (and main kernel) symbols::
> +
> (gdb) lx-symbols
> loading vmlinux
> scanning for modules in /home/user/linux/build
> @@ -72,17 +78,20 @@ Examples of using the Linux-provided gdb helpers
> ...
> loading @0xa000:
> /home/user/linux/build/drivers/ata/ata_generic.ko
>
> - o Set a breakpoint on some not yet loaded module function, e.g.:
> +- Set a breakpoint on some not yet loaded module function, e.g.::
> +
> (gdb) b btrfs_init_sysfs
> Function "btrfs_init_sysfs" not defined.
> Make breakpoint pending on future shared library load? (y or [n]) y
> Breakpoint 1 (btrfs_init_sysfs) pending.
>
> - o Continue the target
> +- Continue the target::
> +
> (gdb) c
>
> - o Load the module on the target and watch the symbols being loaded as well
> as
> - the breakpoint hit:
> +- Load the module on the target and watch the symbols being loaded as well as
> + the breakpoint hit::
> +
> loading @0xa0034000: /home/user/linux/build/lib/libcrc32c.ko
> loading @0xa005:
> /home/user/linux/build/lib/lzo/lzo_com
[PATCH 4/4] ARM: dts: STiH41x-b2020: Update gpio specifier
From: Patrice Chotard
- Remove useless gpio-cells
- Update second parameter by using GPIO_ACTIVE_HIGH/LOW
instead of hardcoded value
Signed-off-by: Patrice Chotard
---
arch/arm/boot/dts/stih41x-b2020.dtsi | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/boot/dts/stih41x-b2020.dtsi
b/arch/arm/boot/dts/stih41x-b2020.dtsi
index 487d7d8..322e0e9 100644
--- a/arch/arm/boot/dts/stih41x-b2020.dtsi
+++ b/arch/arm/boot/dts/stih41x-b2020.dtsi
@@ -7,6 +7,7 @@
* publishhed by the Free Software Foundation.
*/
#include "stih41x-b2020x.dtsi"
+#include
/ {
memory{
device_type = "memory";
@@ -30,13 +31,12 @@
leds {
compatible = "gpio-leds";
red {
- #gpio-cells = <1>;
label = "Front Panel LED";
- gpios = <&pio4 1>;
+ gpios = <&pio4 1 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "heartbeat";
};
green {
- gpios = <&pio4 7>;
+ gpios = <&pio4 7 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
};
--
1.9.1
[tip:sched/core] sched/core: Add documentation for 'cookie' argument
Commit-ID: 9279e0d2e565e0217618c2087de83d3239811329
Gitweb: http://git.kernel.org/tip/9279e0d2e565e0217618c2087de83d3239811329
Author: Luis de Bethencourt
AuthorDate: Sun, 10 Jul 2016 15:00:26 +0100
Committer: Ingo Molnar
CommitDate: Wed, 10 Aug 2016 14:03:32 +0200
sched/core: Add documentation for 'cookie' argument
Add documentation for the cookie argument in try_to_wake_up_local().
This caused the following warning when building documentation:
kernel/sched/core.c:2088: warning: No description found for parameter 'cookie'
Signed-off-by: Luis de Bethencourt
Signed-off-by: Peter Zijlstra (Intel)
Cc: Linus Torvalds
Cc: Mike Galbraith
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: a...@linux-foundation.org
Fixes: e7904a28f533 ("ilocking/lockdep, sched/core: Implement a better lock
pinning scheme")
Link:
http://lkml.kernel.org/r/1468159226-17674-1-git-send-email-lui...@osg.samsung.com
Signed-off-by: Ingo Molnar
---
kernel/sched/core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 4a5f52e..10f2595 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2073,6 +2073,7 @@ out:
/**
* try_to_wake_up_local - try to wake up a local task with rq lock held
* @p: the thread to be awakened
+ * @cookie: context's cookie for pinning
*
* Put @p on the run-queue if it's not already there. The caller must
* ensure that this_rq() is locked, @p is bound to this_rq() and not
Re: [PATCH v3 12/13] net: ethernet: ti: cpsw: move napi struct to cpsw_common
On Wednesday 10 August 2016 04:52 AM, Ivan Khoronzhuk wrote: > The napi structs are common for both net devices in dual_emac > mode, In order to not hold duplicate links to them, move to > cpsw_common. > > Signed-off-by: Ivan Khoronzhuk > --- Reviewed-by: Mugunthan V N Regards Mugunthan V N
Re: [PATCH] clk: prevent __of_clk_get_hw_from_provider() from returning NULL
2016-08-05 5:57 GMT+09:00 Stephen Boyd : > On 07/19, Masahiro Yamada wrote: >> The .get(_hw) callback of an OF clock provider can return a NULL >> pointer in some cases. >> >> For example, of_clk_src_onecell_get() returns NULL for index 1 of a >> sparse array of clocks like follows: >> >> clk_num == 3 >> idx 0: UART clk >> idx 1: NULL (no clk is allocated) >> idx 2: I2C clk >> >> In such cases, clk_get() successfully returns NULL. >> >> A problem is that most drivers only check IS_ERR(), like follows: >> >> clk = devm_clk_get(dev, NULL); >> if (IS_ERR(clk)) >> return PTR_ERR(clk); >> >> It carries on moving forward and will probably be hit by a different >> error check with a different error message. > > NULL is a valid clk pointer, so we can't really do anything here > besides rely on driver authors to do the right thing. I still do not understand this. I think clk_get() should return > 0 pointer on success, error-pointer on failure. I have no idea when NULL is useful as a return value of clk_get(). -- Best Regards Masahiro Yamada
Re: [Regression] "irqdomain: Don't set type when mapping an IRQ" breaks nexus7 gpio buttons
Hi Marc, Linus, On 10/08/16 10:41, Marc Zyngier wrote: > Hi Linus, > > On 10/08/16 00:03, Linus Walleij wrote: >> On Tue, Aug 9, 2016 at 3:20 PM, Jon Hunter wrote: >> >>> If that works, then does the following also work (without the above) ... >>> >>> diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c >>> index b4c1bc7c9ca2..e111b72e3162 100644 >>> --- a/kernel/irq/chip.c >>> +++ b/kernel/irq/chip.c >>> @@ -824,6 +824,7 @@ __irq_do_set_handler(struct irq_desc *desc, >>> irq_flow_handler_t handle, >>> irq_settings_set_norequest(desc); >>> irq_settings_set_nothread(desc); >>> desc->action = &chained_action; >>> + __irq_set_trigger(desc, >>> irqd_get_trigger_type(&desc->irq_data)); >>> irq_startup(desc, true); >>> } >>> } >>> >>> It looks like there is a path for parent interrupts where the type >>> is not getting set. If the above works then we can discuss with Thomas >>> and Marc on the correct fix. >> >> I tried this on my problematic platform and then this happens: >> >> preparing networking... >> [2.628246] [ cut here ] >> [2.628303] WARNING: CPU: 0 PID: 92 at ../kernel/irq/chip.c:26 >> bad_chained_irq+0x44/0x4c >> [2.631939] Chained irq 109 should not call an action >> [2.640008] Modules linked in: >> [2.647909] CPU: 0 PID: 92 Comm: ip Not tainted >> 4.8.0-rc1-00011-ga21e27b4cb66 #194 >> [2.647996] Hardware name: Generic DT based system >> [2.655486] [] (unwind_backtrace) from [] >> (show_stack+0x10/0x14) >> [2.660254] [] (show_stack) from [] >> (dump_stack+0x78/0x8c) >> [2.668147] [] (dump_stack) from [] >> (__warn+0xec/0x104) >> [2.675173] [] (__warn) from [] >> (warn_slowpath_fmt+0x38/0x48) >> [2.682033] [] (warn_slowpath_fmt) from [] >> (bad_chained_irq+0x44/0x4c) >> [2.689687] [] (bad_chained_irq) from [] >> (__handle_irq_event_percpu+0x5c/0x290) >> [2.697836] [] (__handle_irq_event_percpu) from >> [] (handle_irq_event_percpu+0x1c/0x58) >> [2.706778] [] (handle_irq_event_percpu) from >> [] (handle_irq_event+0x38/0x5c) >> [2.716498] [] (handle_irq_event) from [] >> (handle_level_irq+0xc4/0x150) >> [2.725438] [] (handle_level_irq) from [] >> (generic_handle_irq+0x24/0x34) >> [2.733602] [] (generic_handle_irq) from [] >> (msm_gpio_irq_handler+0xc8/0x150) >> [2.742280] [] (msm_gpio_irq_handler) from [] >> (generic_handle_irq+0x24/0x34) >> [2.751048] [] (generic_handle_irq) from [] >> (__handle_domain_irq+0x7c/0xec) >> [2.759901] [] (__handle_domain_irq) from [] >> (gic_handle_irq+0x48/0x8c) >> [2.768323] [] (gic_handle_irq) from [] >> (__irq_svc+0x6c/0xa8) >> [2.776644] Exception stack(0xdeca1d48 to 0xdeca1d90) >> [2.784284] 1d40: deca1dc0 >> deca0018 8bd6 deca1dc0 >> [2.789324] 1d60: c0378ad0 60070013 >> 001f3df8 c108fa04 deca1d98 >> [2.797481] 1d80: c08b77fc c0377930 60070013 >> [2.805651] [] (__irq_svc) from [] >> (init_timer_key+0x28/0x104) >> [2.810679] [] (init_timer_key) from [] >> (schedule_timeout+0x48/0x410) >> [2.818145] [] (schedule_timeout) from [] >> (msleep+0x2c/0x38) >> [2.826399] [] (msleep) from [] >> (smsc911x_open+0x268/0x50c) >> [2.833859] [] (smsc911x_open) from [] >> (__dev_open+0xa8/0x10c) >> [2.840887] [] (__dev_open) from [] >> (__dev_change_flags+0x94/0x144) >> [2.848525] [] (__dev_change_flags) from [] >> (dev_change_flags+0x18/0x48) >> [2.856428] [] (dev_change_flags) from [] >> (devinet_ioctl+0x6b0/0x768) >> [2.865120] [] (devinet_ioctl) from [] >> (sock_ioctl+0x1f4/0x2c8) >> [2.873186] [] (sock_ioctl) from [] >> (do_vfs_ioctl+0x9c/0x910) >> [2.880645] [] (do_vfs_ioctl) from [] >> (SyS_ioctl+0x34/0x5c) >> [2.888290] [] (SyS_ioctl) from [] >> (ret_fast_syscall+0x0/0x3c) >> [2.895395] ---[ end trace a53e1e63b7bdfc4a ]--- >> [2.903917] random: fast init done >> [3.036378] random: crng init done >> [3.883906] irq 109: nobody cared (try booting with the "irqpoll" option) >> [3.883940] CPU: 0 PID: 92 Comm: ip Tainted: GW >> 4.8.0-rc1-00011-ga21e27b4cb66 #194 >> [3.889673] Hardware name: Generic DT based system >> [3.898538] [] (unwind_backtrace) from [] >> (show_stack+0x10/0x14) >> [3.903137] [] (show_stack) from [] >> (dump_stack+0x78/0x8c) >> [3.911034] [] (dump_stack) from [] >> (__report_bad_irq+0x28/0xcc) >> [3.918065] [] (__report_bad_irq) from [] >> (note_interrupt+0x298/0x2e8) >> [3.925971] [] (note_interrupt) from [] >> (handle_irq_event_percpu+0x4c/0x58) >> [3.934040] [] (handle_irq_event_percpu) from >> [] (handle_irq_event+0x38/0x5c) >> [3.942634] [] (handle_irq_event) from [] >> (handle_level_irq+0xc4/0x150) >> [3.951660] [] (handle_level_irq) from [] >> (generic_handle_irq+0x24/0x34) >> [3.959821] [] (generic_handle_irq) from [] >> (msm_gpio_irq_handler+0xc8/0x150
[PATCH REBASED v10 2/6] drm/i915/gen9: Only copy WM results for changed pipes to skl_hw
From: Matt Roper
When we write watermark values to the hardware, those values are stored
in dev_priv->wm.skl_hw. However with recent watermark changes, the
results structure we're copying from only contains valid watermark and
DDB values for the pipes that are actually changing; the values for
other pipes remain 0. Thus a blind copy of the entire skl_wm_values
structure will clobber the values for unchanged pipes...we need to be
more selective and only copy over the values for the changing pipes.
This mistake was hidden until recently due to another bug that caused us
to erroneously re-calculate watermarks for all active pipes rather than
changing pipes. Only when that bug was fixed was the impact of this bug
discovered (e.g., modesets failing with "Requested display configuration
exceeds system watermark limitations" messages and leaving watermarks
non-functional, even ones initiated by intel_fbdev_restore_mode).
Changes since v1:
- Add a function for copying a pipe's wm values
(skl_copy_wm_for_pipe()) so we can reuse this later
Fixes: 734fa01f3a17 ("drm/i915/gen9: Calculate watermarks during atomic 'check'
(v2)")
Fixes: 9b6130227495 ("drm/i915/gen9: Re-allocate DDB only for changed pipes")
Signed-off-by: Matt Roper
Signed-off-by: Lyude
Reviewed-by: Matt Roper
Cc: sta...@vger.kernel.org
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Radhakrishna Sripada
Cc: Hans de Goede
---
drivers/gpu/drm/i915/intel_pm.c | 28 ++--
1 file changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e90b974..ee6590d 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4066,6 +4066,24 @@ skl_compute_ddb(struct drm_atomic_state *state)
return 0;
}
+static void
+skl_copy_wm_for_pipe(struct skl_wm_values *dst,
+struct skl_wm_values *src,
+enum pipe pipe)
+{
+ dst->wm_linetime[pipe] = src->wm_linetime[pipe];
+ memcpy(dst->plane[pipe], src->plane[pipe],
+ sizeof(dst->plane[pipe]));
+ memcpy(dst->plane_trans[pipe], src->plane_trans[pipe],
+ sizeof(dst->plane_trans[pipe]));
+
+ dst->ddb.pipe[pipe] = src->ddb.pipe[pipe];
+ memcpy(dst->ddb.y_plane[pipe], src->ddb.y_plane[pipe],
+ sizeof(dst->ddb.y_plane[pipe]));
+ memcpy(dst->ddb.plane[pipe], src->ddb.plane[pipe],
+ sizeof(dst->ddb.plane[pipe]));
+}
+
static int
skl_compute_wm(struct drm_atomic_state *state)
{
@@ -4138,8 +4156,10 @@ static void skl_update_wm(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct skl_wm_values *results = &dev_priv->wm.skl_results;
+ struct skl_wm_values *hw_vals = &dev_priv->wm.skl_hw;
struct intel_crtc_state *cstate = to_intel_crtc_state(crtc->state);
struct skl_pipe_wm *pipe_wm = &cstate->wm.skl.optimal;
+ int pipe;
if ((results->dirty_pipes & drm_crtc_mask(crtc)) == 0)
return;
@@ -4151,8 +4171,12 @@ static void skl_update_wm(struct drm_crtc *crtc)
skl_write_wm_values(dev_priv, results);
skl_flush_wm_values(dev_priv, results);
- /* store the new configuration */
- dev_priv->wm.skl_hw = *results;
+ /*
+* Store the new configuration (but only for the pipes that have
+* changed; the other values weren't recomputed).
+*/
+ for_each_pipe_masked(dev_priv, pipe, results->dirty_pipes)
+ skl_copy_wm_for_pipe(hw_vals, results, pipe);
mutex_unlock(&dev_priv->wm.wm_mutex);
}
--
2.7.4
Re: [tip:perf/urgent] perf probe: Support signedness casting
Em Wed, Aug 10, 2016 at 07:28:08AM +0900, Masami Hiramatsu escreveu: > Hi Ingo, > > Could you add my Acked-by for this patch? > (I thought I've sent it...) Sorry about that, I usually put those acks diligently, but this one slipped by... I saw the discussion, waited for it to settle and you ack to be provided, but then, while testing it and editing the log, I forgot to collect the ack. - Arnaldo > Thank you, > > On Tue, 9 Aug 2016 12:19:02 -0700 > tip-bot for Naohiro Aota wrote: > > > Commit-ID: 19f00b011729417f69e4df53cc3fe5ecc25134a4 > > Gitweb: > > http://git.kernel.org/tip/19f00b011729417f69e4df53cc3fe5ecc25134a4 > > Author: Naohiro Aota > > AuthorDate: Tue, 9 Aug 2016 11:40:08 +0900 > > Committer: Arnaldo Carvalho de Melo > > CommitDate: Tue, 9 Aug 2016 10:52:22 -0300 > > > > perf probe: Support signedness casting > > > > The 'perf probe' tool detects a variable's type and use the detected > > type to add a new probe. Then, kprobes prints its variable in > > hexadecimal format if the variable is unsigned and prints in decimal if > > it is signed. > > > > We sometimes want to see unsigned variable in decimal format (i.e. > > sector_t or size_t). In that case, we need to investigate the variable's > > size manually to specify just signedness. > > > > This patch add signedness casting support. By specifying "s" or "u" as a > > type, perf-probe will investigate variable size as usual and use the > > specified signedness. > > > > E.g. without this: > > > > $ perf probe -a 'submit_bio bio->bi_iter.bi_sector' > > Added new event: > > probe:submit_bio (on submit_bio with > > bi_sector=bio->bi_iter.bi_sector) > > You can now use it in all perf tools, such as: > > perf record -e probe:submit_bio -aR sleep 1 > > $ cat trace_pipe|head > > dbench-9692 [003] d..1 971.096633: submit_bio: > > (submit_bio+0x0/0x140) bi_sector=0x3a3d00 > > dbench-9692 [003] d..1 971.096685: submit_bio: > > (submit_bio+0x0/0x140) bi_sector=0x1a3d80 > > dbench-9692 [003] d..1 971.096687: submit_bio: > > (submit_bio+0x0/0x140) bi_sector=0x3a3d80 > > ... > > // need to investigate the variable size > > $ perf probe -a 'submit_bio bio->bi_iter.bi_sector:s64' > > Added new event: > > probe:submit_bio (on submit_bio with > > bi_sector=bio->bi_iter.bi_sector:s64) > > You can now use it in all perf tools, such as: > > perf record -e probe:submit_bio -aR sleep 1 > > > > With this: > > > > // just use "s" to cast its signedness > > $ perf probe -v -a 'submit_bio bio->bi_iter.bi_sector:s' > > Added new event: > > probe:submit_bio (on submit_bio with > > bi_sector=bio->bi_iter.bi_sector:s) > > You can now use it in all perf tools, such as: > > perf record -e probe:submit_bio -aR sleep 1 > > $ cat trace_pipe|head > > dbench-9689 [001] d..1 1212.391237: submit_bio: > > (submit_bio+0x0/0x140) bi_sector=128 > > dbench-9689 [001] d..1 1212.391252: submit_bio: > > (submit_bio+0x0/0x140) bi_sector=131072 > > dbench-9697 [006] d..1 1212.398611: submit_bio: > > (submit_bio+0x0/0x140) bi_sector=30208 > > > > This commit also update perf-probe.txt to describe "types". Most parts > > are based on existing documentation: Documentation/trace/kprobetrace.txt > > > > Committer note: > > > > Testing using 'perf trace': > > > > # perf probe -a 'submit_bio bio->bi_iter.bi_sector' > > Added new event: > > probe:submit_bio (on submit_bio with > > bi_sector=bio->bi_iter.bi_sector) > > > > You can now use it in all perf tools, such as: > > > > perf record -e probe:submit_bio -aR sleep 1 > > > > # trace --no-syscalls --ev probe:submit_bio > > 0.000 probe:submit_bio:(ac3aee00) bi_sector=0xc133c0) > >3181.861 probe:submit_bio:(ac3aee00) bi_sector=0x6cffb8) > >3181.881 probe:submit_bio:(ac3aee00) bi_sector=0x6cffc0) > >3184.488 probe:submit_bio:(ac3aee00) bi_sector=0x6cffc8) > > > >4717.927 probe:submit_bio:(ac3aee00) bi_sector=0x4dc7a88) > >4717.970 probe:submit_bio:(ac3aee00) bi_sector=0x4dc7880) > > ^C[root@jouet ~]# > > > > Now, using this new feature: > > > > [root@jouet ~]# perf probe -a 'submit_bio bio->bi_iter.bi_sector:s' > > Added new event: > > probe:submit_bio (on submit_bio with > > bi_sector=bio->bi_iter.bi_sector:s) > > > > You can now use it in all perf tools, such as: > > > > perf record -e probe:submit_bio -aR sleep 1 > > > > [root@jouet ~]# trace --no-syscalls --ev probe:submit_bio > > 0.000 probe:submit_bio:(ac3aee00) bi_sector=7145704) > > 0.017 probe:submit_bio:(ac3aee00) bi_sector=7145712) > > 0.019 probe:submit_bio:(ac3aee00) bi_sector=7145720) > > 2.567 probe:submit_bio:(ac3aee00) bi_sector=7145728) > > 5631.919 probe:submit_bio:(ac3aee00) bi_sector=0) > > 5631.941 probe:su
Re: [PACTH v1] mm, proc: Implement /proc//totmaps
On Wed, Aug 10, 2016 at 10:45:51AM -0700, Sonny Rao wrote:
> On Wed, Aug 10, 2016 at 10:37 AM, Jann Horn wrote:
> > On Wed, Aug 10, 2016 at 10:23:53AM -0700, Sonny Rao wrote:
> >> On Tue, Aug 9, 2016 at 2:01 PM, Robert Foss
> >> wrote:
> >> >
> >> >
> >> > On 2016-08-09 03:24 PM, Jann Horn wrote:
> >> >>
> >> >> On Tue, Aug 09, 2016 at 12:05:43PM -0400, robert.f...@collabora.com
> >> >> wrote:
> >> >>>
> >> >>> From: Sonny Rao
> >> >>>
> >> >>> This is based on earlier work by Thiago Goncales. It implements a new
> >> >>> per process proc file which summarizes the contents of the smaps file
> >> >>> but doesn't display any addresses. It gives more detailed information
> >> >>> than statm like the PSS (proprotional set size). It differs from the
> >> >>> original implementation in that it doesn't use the full blown set of
> >> >>> seq operations, uses a different termination condition, and doesn't
> >> >>> displayed "Locked" as that was broken on the original implemenation.
> >> >>>
> >> >>> This new proc file provides information faster than parsing the
> >> >>> potentially
> >> >>> huge smaps file.
> >> >>>
> >> >>> Signed-off-by: Sonny Rao
> >> >>>
> >> >>> Tested-by: Robert Foss
> >> >>> Signed-off-by: Robert Foss
> >> >>
> >> >>
> >> >>
> >> >>> +static int totmaps_proc_show(struct seq_file *m, void *data)
> >> >>> +{
> >> >>> + struct proc_maps_private *priv = m->private;
> >> >>> + struct mm_struct *mm;
> >> >>> + struct vm_area_struct *vma;
> >> >>> + struct mem_size_stats *mss_sum = priv->mss;
> >> >>> +
> >> >>> + /* reference to priv->task already taken */
> >> >>> + /* but need to get the mm here because */
> >> >>> + /* task could be in the process of exiting */
> >> >>
> >> >>
> >> >> Can you please elaborate on this? My understanding here is that you
> >> >> intend for the caller to be able to repeatedly read the same totmaps
> >> >> file with pread() and still see updated information after the target
> >> >> process has called execve() and be able to detect process death
> >> >> (instead of simply seeing stale values). Is that accurate?
> >> >>
> >> >> I would prefer it if you could grab a reference to the mm_struct
> >> >> directly at open time.
> >> >
> >> >
> >> > Sonny, do you know more about the above comment?
> >>
> >> I think right now the file gets re-opened every time, but the mode
> >> where the file is opened once and repeatedly read is interesting
> >> because it avoids having to open the file again and again.
> >>
> >> I guess you could end up with a wierd situation where you don't read
> >> the entire contents of the file in open call to read() and you might
> >> get inconsistent data across the different statistics?
> >
> > If the file is read in two chunks, totmaps_proc_show is only called
> > once. The patch specifies seq_read as read handler. Have a look at its
> > definition. As long as you don't read from the same seq file in
> > parallel or seek around in it, simple sequential reads will not
> > re-invoke the show() method for data that has already been formatted.
> > For partially consumed data, the kernel buffers the rest until someone
> > reads it or seeks to another offset.
>
> Ok that's good. If the consumer were using pread() though, would that
> look like a seek?
Only if the consumer uses pread() with an offset that is not the same as
the end offset of the previous read.
So if you tried to use the same file from multiple threads in parallel,
you might still have issues, but as long as you don't do that, it should
be fine.
I guess it might make sense to document this behavior somewhere - maybe
the proc.5 manpage?
signature.asc
Description: Digital signature
[tip:locking/core] locking/qrwlock: Fix write unlock bug on big endian systems
Commit-ID: 2db34e8bf9a22f4e38b29deccee57457bc0e7d74
Gitweb: http://git.kernel.org/tip/2db34e8bf9a22f4e38b29deccee57457bc0e7d74
Author: pan xinhui
AuthorDate: Mon, 18 Jul 2016 17:47:39 +0800
Committer: Ingo Molnar
CommitDate: Wed, 10 Aug 2016 14:13:27 +0200
locking/qrwlock: Fix write unlock bug on big endian systems
This patch aims to get rid of endianness in queued_write_unlock(). We
want to set __qrwlock->wmode to NULL, however the address is not
&lock->cnts in big endian machine. That causes queued_write_unlock()
write NULL to the wrong field of __qrwlock.
So implement __qrwlock_write_byte() which returns the correct
__qrwlock->wmode address.
Suggested-by: Peter Zijlstra (Intel)
Signed-off-by: Pan Xinhui
Signed-off-by: Peter Zijlstra (Intel)
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: waiman.l...@hpe.com
Cc: a...@arndb.de
Cc: boqun.f...@gmail.com
Cc: will.dea...@arm.com
Link:
http://lkml.kernel.org/r/1468835259-4486-1-git-send-email-xinhui@linux.vnet.ibm.com
Signed-off-by: Ingo Molnar
---
include/asm-generic/qrwlock.h | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/include/asm-generic/qrwlock.h b/include/asm-generic/qrwlock.h
index 54a8e65..7d026bf 100644
--- a/include/asm-generic/qrwlock.h
+++ b/include/asm-generic/qrwlock.h
@@ -25,7 +25,20 @@
#include
/*
- * Writer states & reader shift and bias
+ * Writer states & reader shift and bias.
+ *
+ * | +0 | +1 | +2 | +3 |
+ * +++++
+ *LE | 78 | 56 | 34 | 12 | 0x12345678
+ * +++++
+ * | wr | rd |
+ * +++++
+ *
+ * +++++
+ *BE | 12 | 34 | 56 | 78 | 0x12345678
+ * +++++
+ * | rd | wr |
+ * +++++
*/
#define_QW_WAITING 1 /* A writer is waiting */
#define_QW_LOCKED 0xff/* A writer holds the lock */
@@ -134,12 +147,22 @@ static inline void queued_read_unlock(struct qrwlock
*lock)
}
/**
+ * __qrwlock_write_byte - retrieve the write byte address of a queue rwlock
+ * @lock : Pointer to queue rwlock structure
+ * Return: the write byte address of a queue rwlock
+ */
+static inline u8 *__qrwlock_write_byte(struct qrwlock *lock)
+{
+ return (u8 *)lock + 3 * IS_BUILTIN(CONFIG_CPU_BIG_ENDIAN);
+}
+
+/**
* queued_write_unlock - release write lock of a queue rwlock
* @lock : Pointer to queue rwlock structure
*/
static inline void queued_write_unlock(struct qrwlock *lock)
{
- smp_store_release((u8 *)&lock->cnts, 0);
+ smp_store_release(__qrwlock_write_byte(lock), 0);
}
/*
Re: [PATCH v12] acpi, apei, arm64: APEI initial support for aarch64.
Hi Borislav
On 4 August 2016 at 17:48, Borislav Petkov wrote:
> On Fri, Jul 29, 2016 at 04:57:44PM +0800, fu@linaro.org wrote:
>> From: Tomasz Nowicki
>>
>> This commit provides APEI arch-specific bits for aarch64
>>
>> Meanwhile,
>> (1)add a new subfunction "hest_ia32_init" for
>> "acpi_disable_cmcff" which is used by IA-32 Architecture
>> Corrected Machine Check (CMC).
>> (2)move HEST type (ACPI_HEST_TYPE_IA32_CORRECTED_CHECK) checking to
>> a generic place.
>> (3)select HAVE_ACPI_APEI when EFI and ACPI is set on ARM64,
>> because arch_apei_get_mem_attribute is using efi_mem_attributes on ARM64.
>>
>> [Fu Wei: improve && upstream]
>>
>> Signed-off-by: Tomasz Nowicki
>> Tested-by: Jonathan (Zhixiong) Zhang
>> Signed-off-by: Fu Wei
>> Acked-by: Hanjun Guo
>> Tested-by: Tyler Baicar
>> Acked-by: Will Deacon
>> ---
>
> ...
>
>> @@ -110,8 +111,21 @@ static inline const char *acpi_get_enable_method(int
>> cpu)
>> }
>>
>> #ifdef CONFIG_ACPI_APEI
>> +#define acpi_disable_cmcff 1
>
> What does that mean? ARM doesn't have firmware-first mode?
>
> A piece of comment please.
Thanks I have added a comment on v13, please check.
>
>> pgprot_t arch_apei_get_mem_attribute(phys_addr_t addr);
>> -#endif
>> +
>> +/*
>> + * Despite its name, this function must still broadcast the TLB
>> + * invalidation in order to ensure other CPUs don't up with junk
> ^
> end
Fixed, thanks :-)
>
>> + * entries as a result of speculation. Unusually, its also called in
>> + * IRQ context (ghes_iounmap_irq) so if we ever need to use IPIs for
>> + * TLB broadcasting, then we're in trouble here.
>> + */
>> +static inline void arch_apei_flush_tlb_one(unsigned long addr)
>> +{
>> + flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
>> +}
>> +#endif /* CONFIG_ACPI_APEI */
>>
>> #ifdef CONFIG_ACPI_NUMA
>> int arm64_acpi_numa_init(void);
>> diff --git a/arch/x86/kernel/acpi/apei.c b/arch/x86/kernel/acpi/apei.c
>> index c280df6..ea3046e 100644
>> --- a/arch/x86/kernel/acpi/apei.c
>> +++ b/arch/x86/kernel/acpi/apei.c
>
> ...
>
>> diff --git a/drivers/acpi/apei/hest.c b/drivers/acpi/apei/hest.c
>> index 20b3fcf..792a0d9 100644
>> --- a/drivers/acpi/apei/hest.c
>> +++ b/drivers/acpi/apei/hest.c
>> @@ -232,8 +243,9 @@ void __init acpi_hest_init(void)
>> goto err;
>> }
>>
>> - if (!acpi_disable_cmcff)
>> - apei_hest_parse(hest_parse_cmc, NULL);
>> + rc = hest_ia32_init();
>
> Why do you need a separate hest_ia32_init() here?
>
> You can do
>
> rc = apei_hest_parse(hest_parse_cmc, NULL);
>
> directly here AFAICT.
yes, we can do that.
But the reason for a separate hest_ia32_init() is:
For now(ACPI 6.1), we have three IA-32 Architecture-specific error
source structures, maybe we will parse them later.
So I made this hest_ia32_init() for all these structures. maybe we can do :
---
static int __init hest_parse_cmc(struct acpi_hest_header *hest_hdr, void *data)
{
if (hest_hdr->type != ACPI_HEST_TYPE_IA32_CORRECTED_CHECK)
return 0;
if (!acpi_disable_cmcff)
return !arch_apei_enable_cmcff(hest_hdr, data);
return 0;
}
static int __init hest_parse_mce(struct acpi_hest_header *hest_hdr, void *data)
{
if (hest_hdr->type != ACPI_HEST_TYPE_IA32_CHECK)
return 0;
// do something
return 0;
}
static int __init hest_parse_nmi(struct acpi_hest_header *hest_hdr, void *data)
{
if (hest_hdr->type != ACPI_HEST_TYPE_IA32_NMI)
return 0;
// do something
return 0;
}
static inline int __init hest_ia32_init(void)
{
int ret = apei_hest_parse(hest_parse_nmi, NULL);
if (ret)
return ret;
ret = apei_hest_parse(hest_parse_mce, NULL);
if (ret)
return ret;
return apei_hest_parse(hest_parse_cmc, NULL);
}
---
But it is just my thought, please correct me if I misunderstand
something. Thanks :-)
>
>> + if (rc)
>> + goto err;
>>
>> if (!ghes_disable) {
>> rc = apei_hest_parse(hest_parse_ghes_count, &ghes_count);
>> --
>> 2.5.5
>>
>
> --
> Regards/Gruss,
> Boris.
>
> ECO tip #101: Trim your mails when you reply.
>
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB
> 21284 (AG Nürnberg)
> --
--
Best regards,
Fu Wei
Software Engineer
Red Hat
[tip:sched/core] sched/fair: Optimize find_idlest_cpu() when there is no choice
Commit-ID: eaecf41f5abf80b63c8e025fcb9ee4aa203c3038
Gitweb: http://git.kernel.org/tip/eaecf41f5abf80b63c8e025fcb9ee4aa203c3038
Author: Morten Rasmussen
AuthorDate: Wed, 22 Jun 2016 18:03:14 +0100
Committer: Ingo Molnar
CommitDate: Wed, 10 Aug 2016 14:03:32 +0200
sched/fair: Optimize find_idlest_cpu() when there is no choice
In the current find_idlest_group()/find_idlest_cpu() search we end up
calling find_idlest_cpu() in a sched_group containing only one CPU in
the end. Checking idle-states becomes pointless when there is no
alternative, so bail out instead.
Signed-off-by: Morten Rasmussen
Signed-off-by: Peter Zijlstra (Intel)
Cc: Linus Torvalds
Cc: Mike Galbraith
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: dietmar.eggem...@arm.com
Cc: linux-kernel@vger.kernel.org
Cc: mgalbra...@suse.de
Cc: vincent.guit...@linaro.org
Cc: yuyang...@intel.com
Link:
http://lkml.kernel.org/r/1466615004-3503-4-git-send-email-morten.rasmus...@arm.com
Signed-off-by: Ingo Molnar
---
kernel/sched/fair.c | 4
1 file changed, 4 insertions(+)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index d819da6..acdc351 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5239,6 +5239,10 @@ find_idlest_cpu(struct sched_group *group, struct
task_struct *p, int this_cpu)
int shallowest_idle_cpu = -1;
int i;
+ /* Check if we have any choice: */
+ if (group->group_weight == 1)
+ return cpumask_first(sched_group_cpus(group));
+
/* Traverse only the allowed CPUs */
for_each_cpu_and(i, sched_group_cpus(group), tsk_cpus_allowed(p)) {
if (idle_cpu(i)) {
[PATCH REBASED v10 4/6] drm/i915/skl: Ensure pipes with changed wms get added to the state
If we're enabling a pipe, we'll need to modify the watermarks on all active planes. Since those planes won't be added to the state on their own, we need to add them ourselves. Signed-off-by: Lyude Reviewed-by: Matt Roper Cc: sta...@vger.kernel.org Cc: Ville Syrjälä Cc: Daniel Vetter Cc: Radhakrishna Sripada Cc: Hans de Goede --- drivers/gpu/drm/i915/intel_pm.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index df0fab6..165dc42 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -4079,6 +4079,10 @@ skl_compute_ddb(struct drm_atomic_state *state) ret = skl_allocate_pipe_ddb(cstate, ddb); if (ret) return ret; + + ret = drm_atomic_add_affected_planes(state, &intel_crtc->base); + if (ret) + return ret; } return 0; -- 2.7.4
[PATCH] exynos-drm: Fix error messages to print flags and size
Fix exynos_drm_gem_create() error messages to include flags and size when
flags and size are invalid.
Signed-off-by: Shuah Khan
---
drivers/gpu/drm/exynos/exynos_drm_gem.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_gem.c
b/drivers/gpu/drm/exynos/exynos_drm_gem.c
index cdf9f1a..4c4cb0e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gem.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gem.c
@@ -231,12 +231,12 @@ struct exynos_drm_gem *exynos_drm_gem_create(struct
drm_device *dev,
int ret;
if (flags & ~(EXYNOS_BO_MASK)) {
- DRM_ERROR("invalid flags.\n");
+ DRM_ERROR("invalid GEM buffer flags: %u\n", flags);
return ERR_PTR(-EINVAL);
}
if (!size) {
- DRM_ERROR("invalid size.\n");
+ DRM_ERROR("invalid GEM buffer size: %lu\n", size);
return ERR_PTR(-EINVAL);
}
--
2.7.4
Re: [kernel-hardening] Re: [PATCH 2/2] arm: apply more __ro_after_init
On Wed, 2016-08-10 at 10:43 +0100, Russell King - ARM Linux wrote:
> On Fri, Jun 03, 2016 at 11:40:24AM -0700, Kees Cook wrote:
> >
> > @@ -1309,16 +1309,11 @@ void __init arm_mm_memblock_reserve(void)
> > * Any other function or debugging method which may touch any
> > device _will_
> > * crash the kernel.
> > */
> > +static char vectors[PAGE_SIZE * 2] __ro_after_init
> > __aligned(PAGE_SIZE);
> > static void __init devicemaps_init(const struct machine_desc
> > *mdesc)
> > {
> > struct map_desc map;
> > unsigned long addr;
> > - void *vectors;
> > -
> > - /*
> > - * Allocate the vector page early.
> > - */
> > - vectors = early_alloc(PAGE_SIZE * 2);
>
> This one is not appropriate. We _do_ write to these pages after init
> for FIQ handler updates. See set_fiq_handler().
This is one of the many cases where pax_open_kernel/pax_close_kernel are
needed to temporarily toggle it read-only. From grsecurity:
@@ -95,7 +95,10 @@ void set_fiq_handler(void *start, unsigned int
length)
void *base = vectors_page;
unsigned offset = FIQ_OFFSET;
+ pax_open_kernel();
memcpy(base + offset, start, length);
+ pax_close_kernel();
signature.asc
Description: This is a digitally signed message part
Re: [PATCH 3/4] ARM: dts: da850-lcdk: Add NAND to DT
On Wed, Aug 10, 2016 at 02:01:57PM +0530, Sekhar Nori wrote: > On Tuesday 09 August 2016 10:45 PM, Karl Beldan wrote: > > This adds DT support for the NAND connected to the SoC AEMIF. > > The parameters (timings, ecc) are the same as what the board ships with > > (default AEMIF timings, 1bit ECC) and improvements will be handled in > > due course. > > I disagree that we need to be compatible to the software that ships with > the board. Thats software was last updated 3 years ago. Instead I would > concern with what the hardware supports. So, if the hardware can support > 4-bit ECC, I would use that. > I am not saying we _need_ to be compatible. > If driver is broken for 4-bit ECC, please fix that up first. > Since this issue is completely separate from my DT improvements I'll stick to resubmitting the series, applying my LCDK changes to the EVM too, besides you'll be able to compare the behavior without ECC discrepancies. I took note that you are likely to not apply without the ECC fix. Karl > > This passed elementary tests hashing a 20MB file on top of ubifs on my > > LCDK. > > > > Signed-off-by: Karl Beldan > > Thanks, > Sekhar
Re: [PATCH v4 3/3] locking/mutex: Ensure forward progress of waiter-spinner
On 08/10/2016 05:29 AM, Peter Zijlstra wrote: On Tue, Aug 09, 2016 at 02:00:00PM -0400, Waiman Long wrote: Alternative might be to use the LSB of mutex::owner, but that's going to be somewhat icky too. I was thinking about doing that. However, the owner field is used in quite a number of places. It may be a bit risky to change all of them. Agreed. It will be easier to do that for rwsem as the owner field isn't used for the debug code, unlike the mutex. Cheers, Longman
[tip:locking/core] locking/pvstat: Separate wait_again and spurious wakeup stats
Commit-ID: 08be8f63c40c030b5cf95b4368e314e563a86301
Gitweb: http://git.kernel.org/tip/08be8f63c40c030b5cf95b4368e314e563a86301
Author: Waiman Long
AuthorDate: Tue, 31 May 2016 12:53:47 -0400
Committer: Ingo Molnar
CommitDate: Wed, 10 Aug 2016 14:16:02 +0200
locking/pvstat: Separate wait_again and spurious wakeup stats
Currently there are overlap in the pvqspinlock wait_again and
spurious_wakeup stat counters. Because of lock stealing, it is
no longer possible to accurately determine if spurious wakeup has
happened in the queue head. As they track both the queue node and
queue head status, it is also hard to tell how many of those comes
from the queue head and how many from the queue node.
This patch changes the accounting rules so that spurious wakeup is
only tracked in the queue node. The wait_again count, however, is
only tracked in the queue head when the vCPU failed to acquire the
lock after a vCPU kick. This should give a much better indication of
the wait-kick dynamics in the queue node and the queue head.
Signed-off-by: Waiman Long
Signed-off-by: Peter Zijlstra (Intel)
Cc: Andrew Morton
Cc: Boqun Feng
Cc: Douglas Hatch
Cc: Linus Torvalds
Cc: Pan Xinhui
Cc: Paul E. McKenney
Cc: Peter Zijlstra
Cc: Scott J Norton
Cc: Thomas Gleixner
Link:
http://lkml.kernel.org/r/1464713631-1066-2-git-send-email-waiman.l...@hpe.com
Signed-off-by: Ingo Molnar
---
kernel/locking/qspinlock_paravirt.h | 12 +++-
kernel/locking/qspinlock_stat.h | 4 ++--
2 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/kernel/locking/qspinlock_paravirt.h
b/kernel/locking/qspinlock_paravirt.h
index 429c3dc..3acf16d 100644
--- a/kernel/locking/qspinlock_paravirt.h
+++ b/kernel/locking/qspinlock_paravirt.h
@@ -288,12 +288,10 @@ static void pv_wait_node(struct mcs_spinlock *node,
struct mcs_spinlock *prev)
{
struct pv_node *pn = (struct pv_node *)node;
struct pv_node *pp = (struct pv_node *)prev;
- int waitcnt = 0;
int loop;
bool wait_early;
- /* waitcnt processing will be compiled out if !QUEUED_LOCK_STAT */
- for (;; waitcnt++) {
+ for (;;) {
for (wait_early = false, loop = SPIN_THRESHOLD; loop; loop--) {
if (READ_ONCE(node->locked))
return;
@@ -317,7 +315,6 @@ static void pv_wait_node(struct mcs_spinlock *node, struct
mcs_spinlock *prev)
if (!READ_ONCE(node->locked)) {
qstat_inc(qstat_pv_wait_node, true);
- qstat_inc(qstat_pv_wait_again, waitcnt);
qstat_inc(qstat_pv_wait_early, wait_early);
pv_wait(&pn->state, vcpu_halted);
}
@@ -458,12 +455,9 @@ pv_wait_head_or_lock(struct qspinlock *lock, struct
mcs_spinlock *node)
pv_wait(&l->locked, _Q_SLOW_VAL);
/*
-* The unlocker should have freed the lock before kicking the
-* CPU. So if the lock is still not free, it is a spurious
-* wakeup or another vCPU has stolen the lock. The current
-* vCPU should spin again.
+* Because of lock stealing, the queue head vCPU may not be
+* able to acquire the lock before it has to wait again.
*/
- qstat_inc(qstat_pv_spurious_wakeup, READ_ONCE(l->locked));
}
/*
diff --git a/kernel/locking/qspinlock_stat.h b/kernel/locking/qspinlock_stat.h
index b9d0315..eb0a599 100644
--- a/kernel/locking/qspinlock_stat.h
+++ b/kernel/locking/qspinlock_stat.h
@@ -24,8 +24,8 @@
* pv_latency_wake - average latency (ns) from vCPU kick to wakeup
* pv_lock_slowpath - # of locking operations via the slowpath
* pv_lock_stealing - # of lock stealing operations
- * pv_spurious_wakeup- # of spurious wakeups
- * pv_wait_again - # of vCPU wait's that happened after a vCPU kick
+ * pv_spurious_wakeup- # of spurious wakeups in non-head vCPUs
+ * pv_wait_again - # of wait's after a queue head vCPU kick
* pv_wait_early - # of early vCPU wait's
* pv_wait_head - # of vCPU wait's at the queue head
* pv_wait_node - # of vCPU wait's at a non-head queue node
Re: Regarding AHCI_MAX_SG and (ATA_HORKAGE_MAX_SEC_1024)
Hi, On 08/10/2016 10:14 AM, Tejun Heo wrote: Hello, Tom. On Wed, Aug 10, 2016 at 06:04:10PM +0800, Tom Yan wrote: On 10 August 2016 at 11:26, Tejun Heo wrote: Hmmm.. why not? The hardware limit is 64k and the driver is using a Is that referring to the maximum number of entries allowed in the PRDT, Physical Region Descriptor Table (which is, more precisely, 65535)? Yeap. Not necessarily. A single sg entry can point to an area larger than PAGE_SIZE. You mean the 4MB limit of "Data Byte Count" in "DW3: Description Information" of the PRDT? Is that what max_segment_size (which is set to a general fallback of 65536: http://lxr.free-electrons.com/ident?i=dma_get_max_seg_size) is about in this case? Ah, ahci isn't setting the hardware limit properly but yeah that's the maximum segment size. And my point was, it will be a multiple of 168 anyway, if 1344 is just an example. As written above, that probably makes the ahci command table size nicely aligned. I think that's what bothers me ultimately, cause I don't see how 168 makes it (more) nicely aligned (or even, aligned to what?). Hmmm... Looked at the sizes and they don't seem to align to anything meaningful. No idea. The 168 makes AHCI_CMD_TBL_SZ equal to 2816 AHCI_CMD_TBL_SZ = AHCI_CMD_TBL_HDR_SZ + (AHCI_MAX_SG * 16) AHCI_CMD_TBL_SZ = 128 + (168 * 16) I think if you add in AHCI_CMD_SLOT_SZ (1024) and AHCI_RX_FIS_SZ (256) the DMA is 4K aligned, I think that is where the 168 came from. Thanks, David
[PATCH REBASED v10 3/6] drm/i915/skl: Update plane watermarks atomically during plane updates
Thanks to Ville for suggesting this as a potential solution to pipe
underruns on Skylake.
On Skylake all of the registers for configuring planes, including the
registers for configuring their watermarks, are double buffered. New
values written to them won't take effect until said registers are
"armed", which is done by writing to the PLANE_SURF (or in the case of
cursor planes, the CURBASE register) register.
With this in mind, up until now we've been updating watermarks on skl
like this:
non-modeset {
- calculate (during atomic check phase)
- finish_atomic_commit:
- intel_pre_plane_update:
- intel_update_watermarks()
- {vblank happens; new watermarks + old plane values => underrun }
- drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- end vblank evasion
}
or
modeset {
- calculate (during atomic check phase)
- finish_atomic_commit:
- crtc_enable:
- intel_update_watermarks()
- {vblank happens; new watermarks + old plane values => underrun }
- drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- end vblank evasion
}
Now we update watermarks atomically like this:
non-modeset {
- calculate (during atomic check phase)
- finish_atomic_commit:
- intel_pre_plane_update:
- intel_update_watermarks() (wm values aren't written yet)
- drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- write new wm values
- end vblank evasion
}
modeset {
- calculate (during atomic check phase)
- finish_atomic_commit:
- crtc_enable:
- intel_update_watermarks() (actual wm values aren't written
yet)
- drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- write new wm values
- end vblank evasion
}
So this patch moves all of the watermark writes into the right place;
inside of the vblank evasion where we update all of the registers for
each plane. While this patch doesn't fix everything, it does allow us to
update the watermark values in the way the hardware expects us to.
Changes since original patch series:
- Remove mutex_lock/mutex_unlock since they don't do anything and we're
not touching global state
- Move skl_write_cursor_wm/skl_write_plane_wm functions into
intel_pm.c, make externally visible
- Add skl_write_plane_wm calls to skl_update_plane
- Fix conditional for for loop in skl_write_plane_wm (level < max_level
should be level <= max_level)
- Make diagram in commit more accurate to what's actually happening
- Add Fixes:
Changes since v1:
- Use IS_GEN9() instead of IS_SKYLAKE() since these fixes apply to more
then just Skylake
- Update description to make it clear this patch doesn't fix everything
- Check if pipes were actually changed before writing watermarks
Changes since v2:
- Write PIPE_WM_LINETIME during vblank evasion
Changes since v3:
- Rebase against new SAGV patch changes
Changes since v4:
- Add a parameter to choose what skl_wm_values struct to use when
writing new plane watermarks
Changes since v5:
- Remove cursor ddb entry write in skl_write_cursor_wm(), defer until
patch 6
- Write WM_LINETIME in intel_begin_crtc_commit()
Changes since v6:
- Remove redundant dirty_pipes check in skl_write_plane_wm (we check
this in all places where we call this function, and it was supposed
to have been removed earlier anyway)
- In i9xx_update_cursor(), use dev_priv->info.gen >= 9 instead of
IS_GEN9(dev_priv). We do this everywhere else and I'd imagine this
needs to be done for gen10 as well
Fixes: 2d41c0b59afc ("drm/i915/skl: SKL Watermark Computation")
Signed-off-by: Lyude
Reviewed-by: Matt Roper
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Radhakrishna Sripada
Cc: Hans de Goede
---
drivers/gpu/drm/i915/intel_display.c | 16 +++-
drivers/gpu/drm/i915/intel_drv.h | 5
drivers/gpu/drm/i915/intel_pm.c | 50
drivers/gpu/drm/i915/intel_sprite.c | 6 +
4 files changed, 60 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 302cb1f..429810b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2980,6 +2980,7 @@ static void skylake_update_primary_plane(struct drm_plane
*plane,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_framebuffer *fb = plane_state->base.fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+ struct skl_wm_values *wm = &dev_priv->wm.skl_results;
int pipe = intel_crtc->pipe;
u32 plane_ctl, stride_div, stride;
u32 tile_height, plane_offset, plane_size;
@@ -3
RE: [RFC PATCH v5 3/3] net: phy: Add gmiitorgmii converter support
Hi Florian,
Thanks for the review...
> >
> > This converter sits between the MAC and the external phy MAC <==>
> > GMII2RGMII <==> RGMII_PHY
>
> This looks good, just a few things, see below:
Thanks...
> > +config XILINX_GMII2RGMII
> > + tristate "Xilinx GMII2RGMII converter driver"
> > + default y
>
> Don't force that, or at least make the default based on the potential
> users/drivers here.
Ok sure will fix in the next version...
>
> > + ---help---
> > + This driver support xilinx GMII to RGMII IP core it provides
> > + the Reduced Gigabit Media Independent Interface(RGMII) between
> > + Ethernet physical media devices and the Gigabit Ethernet
> > controller.
> > +
> > endif # PHYLIB
> > +#define XILINX_GMII2RGMII_REG 0x10
> > +#define XILINX_GMII2RGMII_SPEED_MASK 0x2040
>
> BMCR_SPEED1000 | BMCR_SPEED100 would be clearer here.
Sure will fix...
>
> > +
> > +struct gmii2rgmii {
> > + struct phy_device *phy_dev;
> > + struct phy_driver *phy_drv;
> > + struct phy_driver conv_phy_drv;
> > + int addr;
> > +};
> > +
> > +static int xgmiitorgmii_read_status(struct phy_device *phydev) {
> > + struct gmii2rgmii *priv = (struct gmii2rgmii *)phydev->priv;
>
> Casting is not required here, priv is void *.
Ok will remove...
>
> > + u16 val = 0;
> > +
> > + priv->phy_drv->read_status(phydev);
> > +
> > + val = mdiobus_read(phydev->mdio.bus, priv->addr,
> XILINX_GMII2RGMII_REG);
> > + val &= XILINX_GMII2RGMII_SPEED_MASK;
> > +
> > + switch (phydev->speed) {
> > + case SPEED_1000:
> > + val |= BMCR_SPEED1000;
>
> Is the fall through really intentional here? See genphy_setup_forced() for
> instance.
Ok will fix...
>
> > + case SPEED_100:
> > + val |= BMCR_SPEED100;
> > + case SPEED_10:
> > + val |= BMCR_SPEED10;
> > + }
> > +
> > + mdiobus_write(phydev->mdio.bus, priv->addr,
> XILINX_GMII2RGMII_REG,
> > +val);
> > +
> > + return 0;
> > +}
> [snip]
>
> > +static int __init xgmiitorgmii_init(void) {
> > + return mdio_driver_register(&xgmiitorgmii_driver);
> > +}
> > +module_init(xgmiitorgmii_init);
> > +
> > +static void __exit xgmiitorgmii_cleanup(void) {
> > + mdio_driver_unregister(&xgmiitorgmii_driver);
> > +}
> > +module_exit(xgmiitorgmii_cleanup);
>
> mdio_module_driver() does eliminate a bit of this boilerplate code.
Sure will fix in the next version...
Regards,
Kedar.
> --
> Florian
Re: [PATCH] i2c: don't print error when adding adapter fails
On Tue, Aug 09, 2016 at 01:36:17PM +0200, Wolfram Sang wrote:
> The core will do this for us now.
>
> Signed-off-by: Wolfram Sang
> ---
[...]
> drivers/i2c/busses/i2c-at91.c | 2 --
Acked-by: Ludovic Desroches
[...]
> diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
> index f23372669f770f..03a519d29616d7 100644
> --- a/drivers/i2c/busses/i2c-at91.c
> +++ b/drivers/i2c/busses/i2c-at91.c
> @@ -1118,8 +1118,6 @@ static int at91_twi_probe(struct platform_device *pdev)
>
> rc = i2c_add_numbered_adapter(&dev->adapter);
> if (rc) {
> - dev_err(dev->dev, "Adapter %s registration failed\n",
> - dev->adapter.name);
> clk_disable_unprepare(dev->clk);
>
> pm_runtime_disable(dev->dev);
[PATCH V3] clk: bcm: Add driver for Northstar ILP clock
From: Rafał Miłecki
This clock is present on cheaper Northstar devices like BCM53573 or
BCM47189 using Corex-A7. ILP is a part of PMU (Power Management Unit)
and so it should be defined as one of its subnodes (subdevices). For
more details see Documentation entry.
Unfortunately there isn't a set of registers related to ILP clock only.
We use registers 0x66c, 0x674 and 0x6dc and between them there are e.g.
"retention*" and "control_ext" regs. This is why this driver maps all
0x1000 B of space.
Signed-off-by: Rafał Miłecki
---
V2: Rebase on top of clk-next
Use ALP as parent clock
Improve comments
Switch from ioremap_nocache to ioremap
Check of_clk_add_provide result for error
V3: Drop #include
Make ILP DT entry part of PMU
Describe ILP as subdevice of PMU in Documentation
---
.../devicetree/bindings/clock/brcm,ns-ilp.txt | 40 ++
drivers/clk/bcm/Makefile | 1 +
drivers/clk/bcm/clk-ns-ilp.c | 146 +
3 files changed, 187 insertions(+)
create mode 100644 Documentation/devicetree/bindings/clock/brcm,ns-ilp.txt
create mode 100644 drivers/clk/bcm/clk-ns-ilp.c
diff --git a/Documentation/devicetree/bindings/clock/brcm,ns-ilp.txt
b/Documentation/devicetree/bindings/clock/brcm,ns-ilp.txt
new file mode 100644
index 000..a18c73f
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/brcm,ns-ilp.txt
@@ -0,0 +1,40 @@
+Broadcom Northstar ILP clock
+
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+This binding is used for ILP clock (sometimes referred as "slow clock")
+on Broadcom Northstar devices using Corex-A7 CPU.
+
+This clock is part of PMU (Power Management Unit), a Broadcom's device
+handing power-related aspects. Please note PMU contains more subdevices,
+ILP is only one of them.
+
+ILP's rate has to be calculated on runtime and it depends on ALP clock
+which has to be referenced.
+
+Required properties:
+- compatible: "brcm,ns-ilp"
+- reg: iomem address range of PMU (Power Management Unit)
+- reg-names: "pmu", the only needed & supported reg right now
+- clocks: has to reference an ALP clock
+- #clock-cells: should be <0>
+
+Example:
+
+pmu@18012000 {
+ compatible = "simple-bus";
+ ranges = <0x 0x18012000 0x1000>;
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ ilp: ilp@0 {
+ compatible = "brcm,ns-ilp";
+ reg = <0 0x1000>;
+ reg-names = "pmu";
+ clocks = <&alp>;
+ #clock-cells = <0>;
+ clock-output-names = "ilp";
+ };
+};
diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
index 1d79bd2..1389379 100644
--- a/drivers/clk/bcm/Makefile
+++ b/drivers/clk/bcm/Makefile
@@ -10,3 +10,4 @@ obj-$(CONFIG_COMMON_CLK_IPROC)+= clk-ns2.o
obj-$(CONFIG_ARCH_BCM_CYGNUS) += clk-cygnus.o
obj-$(CONFIG_ARCH_BCM_NSP) += clk-nsp.o
obj-$(CONFIG_ARCH_BCM_5301X) += clk-nsp.o
+obj-$(CONFIG_ARCH_BCM_5301X) += clk-ns-ilp.o
diff --git a/drivers/clk/bcm/clk-ns-ilp.c b/drivers/clk/bcm/clk-ns-ilp.c
new file mode 100644
index 000..53b4a23
--- /dev/null
+++ b/drivers/clk/bcm/clk-ns-ilp.c
@@ -0,0 +1,146 @@
+/*
+ * Copyright (C) 2016 Rafał Miłecki
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define PMU_XTAL_FREQ_RATIO0x66c
+#define XTAL_ALP_PER_4ILP 0x1fff
+#define XTAL_CTL_EN 0x8000
+#define PMU_SLOW_CLK_PERIOD0x6dc
+
+struct ns_ilp {
+ struct clk *clk;
+ struct clk_hw hw;
+ void __iomem *pmu;
+};
+
+static int ns_ilp_enable(struct clk_hw *hw)
+{
+ struct ns_ilp *ilp = container_of(hw, struct ns_ilp, hw);
+
+ writel(0x10199, ilp->pmu + PMU_SLOW_CLK_PERIOD);
+ writel(0x1, ilp->pmu + 0x674);
+
+ return 0;
+}
+
+static unsigned long ns_ilp_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ struct ns_ilp *ilp = container_of(hw, struct ns_ilp, hw);
+ void __iomem *pmu = ilp->pmu;
+ u32 last_val, cur_val;
+ u32 sum = 0, num = 0, loop_num = 0;
+ u32 avg;
+
+ /* Enable measurement */
+ writel(XTAL_CTL_EN, pmu + PMU_XTAL_FREQ_RATIO);
+
+ /* Read initial value */
+ last_val = readl(pmu + PMU_XTAL_FREQ_RATIO) & XTAL_ALP_PER_4ILP;
+
+ /*
+* At minimum we should loop for a bit to let hardware do the
+* measurement. This isn't very accurate however, so for a better
+* precision lets try getting 20 different values for and use average.
+*/
+ while (num < 20) {
+
Re: [PATCH v4] mtd: spi-nor: Add support for S3AN spi-nor devices
ping?
On Thu, Jul 14, 2016 at 10:18 PM, Ricardo Ribalda Delgado
wrote:
> Xilinx Spartan-3AN FPGAs contain an In-System Flash where they keep
> their configuration data and (optionally) some user data.
>
> The protocol of this flash follows most of the spi-nor standard. With
> the following differences:
>
> - Page size might not be a power of two.
> - The address calculation (default addressing mode).
> - The spi nor commands used.
>
> Protocol is described on Xilinx User Guide UG333
>
> Signed-off-by: Ricardo Ribalda Delgado
> ---
> v4:
> -Rebase on top of l2-mtd/master
>
> v3:
> -Rebase on top of mtd-next
> -Rename ADDR_NATIVE to ADDR_DEFAULT to follow UG333 naming
> -Fix bug on probe
>
> v2: Suggested by Brian Norris
>
> -Remove inline qualifier
> -Improve documentation of Default Addressing Mode
> -Convert function callbacks into SNOR_F_
> -Fix missmatch braces
> -Improve documentation of SPI_S3AN flag
>
> drivers/mtd/devices/m25p80.c | 3 ++
> drivers/mtd/spi-nor/spi-nor.c | 110
> --
> include/linux/mtd/spi-nor.h | 26 ++
> 3 files changed, 136 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
> index 9cf7fcd28034..a44465f2b73d 100644
> --- a/drivers/mtd/devices/m25p80.c
> +++ b/drivers/mtd/devices/m25p80.c
> @@ -49,6 +49,9 @@ static int m25p80_read_reg(struct spi_nor *nor, u8 code, u8
> *val, int len)
>
> static void m25p_addr2cmd(struct spi_nor *nor, unsigned int addr, u8 *cmd)
> {
> + if (nor->flags & SNOR_F_S3AN_ADDR_DEFAULT)
> + addr = spi_nor_s3an_addr_convert(nor, addr);
> +
> /* opcode is in cmd[0] */
> cmd[1] = addr >> (nor->addr_width * 8 - 8);
> cmd[2] = addr >> (nor->addr_width * 8 - 16);
> diff --git a/drivers/mtd/spi-nor/spi-nor.c b/drivers/mtd/spi-nor/spi-nor.c
> index d0fc165d7d66..dce0a2f156e1 100644
> --- a/drivers/mtd/spi-nor/spi-nor.c
> +++ b/drivers/mtd/spi-nor/spi-nor.c
> @@ -75,6 +75,12 @@ struct flash_info {
> * bit. Must be used with
> * SPI_NOR_HAS_LOCK.
> */
> +#defineSPI_S3ANBIT(10) /*
> +* Xilinx Spartan 3AN In-System Flash
> +* (MFR cannot be used for probing
> +* because it has the same value as
> +* ATMEL flashes)
> + */
> };
>
> #define JEDEC_MFR(info)((info)->id[0])
> @@ -217,6 +223,21 @@ static inline int set_4byte(struct spi_nor *nor, const
> struct flash_info *info,
> return nor->write_reg(nor, SPINOR_OP_BRWR, nor->cmd_buf, 1);
> }
> }
> +
> +static int s3an_sr_ready(struct spi_nor *nor)
> +{
> + int ret;
> + u8 val;
> +
> + ret = nor->read_reg(nor, SPINOR_OP_XRDSR, &val, 1);
> + if (ret < 0) {
> + pr_err("error %d reading XRDSR\n", (int) ret);
> + return ret;
> + }
> +
> + return !!(val & XSR_RDY);
> +}
> +
> static inline int spi_nor_sr_ready(struct spi_nor *nor)
> {
> int sr = read_sr(nor);
> @@ -238,7 +259,9 @@ static inline int spi_nor_fsr_ready(struct spi_nor *nor)
> static int spi_nor_ready(struct spi_nor *nor)
> {
> int sr, fsr;
> - sr = spi_nor_sr_ready(nor);
> +
> + sr = nor->flags & SNOR_F_READY_XSR_RDY ? s3an_sr_ready(nor) :
> +spi_nor_sr_ready(nor);
> if (sr < 0)
> return sr;
> fsr = nor->flags & SNOR_F_USE_FSR ? spi_nor_fsr_ready(nor) : 1;
> @@ -320,6 +343,23 @@ static void spi_nor_unlock_and_unprep(struct spi_nor
> *nor, enum spi_nor_ops ops)
> }
>
> /*
> + * This code converts an address to the Default Address Mode, that has non
> + * power of two page sizes. We must support this mode because it is the
> default
> + * mode supported by Xilinx tools, it can access the whole flash area and
> + * changing over to the Power-of-two mode is irreversible and corrupts the
> + * original data.
> + */
> +unsigned int spi_nor_s3an_addr_convert(struct spi_nor *nor, unsigned int
> addr)
> +{
> + unsigned int offset;
> +
> + offset = (nor->page_size == 264) ? (addr % 264) : (addr % 528);
> +
> + return ((addr - offset) << 1) | offset;
> +}
> +EXPORT_SYMBOL_GPL(spi_nor_s3an_addr_convert);
> +
> +/*
> * Initiate the erasure of a single sector
> */
> static int spi_nor_erase_sector(struct spi_nor *nor, u32 addr)
> @@ -330,6 +370,9 @@ static int spi_nor_erase_sector(struct spi_nor *nor, u32
> addr)
> if (nor->erase)
> return nor->erase(nor, addr);
>
> + if (nor->flags & SNOR_F_S3AN_ADDR_DEFAULT)
> + addr = spi_nor_s3an_addr_convert(nor, addr);
> +
> /*
> * Default implem
[PATCH v2 0/4] Add DT support for NAND to LCDK
Changes from v1: - s/cs2/cs3 - kept "ti,.." only nand properties (the adjustments made by nand_davinci_probe are broken) - replaced v1_1/4: "memory: ti-aemif: Get a named clock rather than an unnamed one" with v2_1/4: "davinci: da8xx-dt: Add ti-aemif lookup for clock matching" - Make the same improvements for the EVM (and retire nand_cs3) Karl Beldan (4): ARM: davinci: da8xx-dt: Add ti-aemif lookup for clock matching ARM: davinci_all_defconfig: Enable AEMIF as a module ARM: dts: da850,da850-evm: Add an aemif node and use it for the NAND ARM: dts: da850-lcdk: Add NAND to DT arch/arm/boot/dts/da850-evm.dts| 49 +-- arch/arm/boot/dts/da850-lcdk.dts | 107 + arch/arm/boot/dts/da850.dtsi | 19 +++--- arch/arm/configs/davinci_all_defconfig | 2 + arch/arm/mach-davinci/da850.c | 1 + arch/arm/mach-davinci/da8xx-dt.c | 1 + 6 files changed, 163 insertions(+), 16 deletions(-) -- 2.9.2
[PATCH v3] hwmon/max6650.c: Add devicetree support
Parse devicetree parameters for voltage and prescaler setting. This allows
using multiple max6550 devices with varying settings, and also makes it
possible to instantiate and configure the device using devicetree.
Signed-off-by: Mike Looijmans
---
v3: Resubmit because mailing lists bounced
Fix style errors as reported by checkpatch.pl
Fix bug in DT parsing of fan-prescale
v2: Add devicetree binding documentation
Code changes as suggested by Guenter
Reduce log info, output only a single line
.../devicetree/bindings/hwmon/max6650.txt | 20
drivers/hwmon/max6650.c| 28 +-
2 files changed, 37 insertions(+), 11 deletions(-)
create mode 100644 Documentation/devicetree/bindings/hwmon/max6650.txt
diff --git a/Documentation/devicetree/bindings/hwmon/max6650.txt
b/Documentation/devicetree/bindings/hwmon/max6650.txt
new file mode 100644
index 000..89d87c6
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/max6650.txt
@@ -0,0 +1,20 @@
+Bindings for MAX6651 and MAX6650 I2C fan controllers
+
+Required properties:
+- compatible : One of "max6650" or "max6651"
+- reg: I2C address
+
+Optional properties:
+- fan-voltage: The supply voltage of the fan. Valid values are 5 and 12.
+ Default is to use the chip's current setting.
+- fan-prescale : Pre-scaling value as per datasheet. Valid are 1, 2, 4, 8,
16.
+ Default is to use the chip's current setting.
+
+
+Example:
+ fan-max6650: max6650@1b {
+ reg = <0x1b>;
+ compatible = "max6650";
+ fan-voltage = <12>;
+ fan-prescale = <4>;
+ };
diff --git a/drivers/hwmon/max6650.c b/drivers/hwmon/max6650.c
index 162a520..56a6c87 100644
--- a/drivers/hwmon/max6650.c
+++ b/drivers/hwmon/max6650.c
@@ -41,14 +41,14 @@
#include
/*
- * Insmod parameters
+ * Insmod parameters (for backward compatibility)
*/
/* fan_voltage: 5=5V fan, 12=12V fan, 0=don't change */
static int fan_voltage;
/* prescaler: Possible values are 1, 2, 4, 8, 16 or 0 for don't change */
static int prescaler;
-/* clock: The clock frequency of the chip the driver should assume */
+/* clock: The clock frequency of the chip (max6651 can be clocked externally)
*/
static int clock = 254000;
module_param(fan_voltage, int, S_IRUGO);
@@ -566,6 +566,15 @@ static int max6650_init_client(struct max6650_data *data,
struct device *dev = &client->dev;
int config;
int err = -EIO;
+ u32 voltage;
+ u32 prescale;
+
+ if (of_property_read_u32(client->dev.of_node, "fan-voltage",
+&voltage))
+ voltage = fan_voltage;
+ if (of_property_read_u32(client->dev.of_node, "fan-prescale",
+&prescale))
+ prescale = prescaler;
config = i2c_smbus_read_byte_data(client, MAX6650_REG_CONFIG);
@@ -574,7 +583,7 @@ static int max6650_init_client(struct max6650_data *data,
return err;
}
- switch (fan_voltage) {
+ switch (voltage) {
case 0:
break;
case 5:
@@ -584,14 +593,10 @@ static int max6650_init_client(struct max6650_data *data,
config |= MAX6650_CFG_V12;
break;
default:
- dev_err(dev, "illegal value for fan_voltage (%d)\n",
- fan_voltage);
+ dev_err(dev, "illegal value for fan_voltage (%d)\n", voltage);
}
- dev_info(dev, "Fan voltage is set to %dV.\n",
-(config & MAX6650_CFG_V12) ? 12 : 5);
-
- switch (prescaler) {
+ switch (prescale) {
case 0:
break;
case 1:
@@ -614,10 +619,11 @@ static int max6650_init_client(struct max6650_data *data,
| MAX6650_CFG_PRESCALER_16;
break;
default:
- dev_err(dev, "illegal value for prescaler (%d)\n", prescaler);
+ dev_err(dev, "illegal value for prescaler (%d)\n", prescale);
}
- dev_info(dev, "Prescaler is set to %d.\n",
+ dev_info(dev, "Fan voltage: %dV, prescaler: %d.\n",
+(config & MAX6650_CFG_V12) ? 12 : 5,
1 << (config & MAX6650_CFG_PRESCALER_MASK));
/*
--
1.9.1
[tip:x86/mm] x86, kasan, ftrace: Put APIC interrupt handlers into .irqentry.text
Commit-ID: 469f00231278da68062a809306df0bac95a27507 Gitweb: http://git.kernel.org/tip/469f00231278da68062a809306df0bac95a27507 Author: Alexander Potapenko AuthorDate: Fri, 15 Jul 2016 11:42:43 +0200 Committer: Ingo Molnar CommitDate: Wed, 10 Aug 2016 14:19:33 +0200 x86, kasan, ftrace: Put APIC interrupt handlers into .irqentry.text Dmitry Vyukov has reported unexpected KASAN stackdepot growth: https://github.com/google/kasan/issues/36 ... which is caused by the APIC handlers not being present in .irqentry.text: When building with CONFIG_FUNCTION_GRAPH_TRACER=y or CONFIG_KASAN=y, put the APIC interrupt handlers into the .irqentry.text section. This is needed because both KASAN and function graph tracer use __irqentry_text_start and __irqentry_text_end to determine whether a function is an IRQ entry point. Reported-by: Dmitry Vyukov Signed-off-by: Alexander Potapenko Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Josh Poimboeuf Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: aryabi...@virtuozzo.com Cc: kasan-...@googlegroups.com Cc: k...@google.com Cc: rost...@goodmis.org Link: http://lkml.kernel.org/r/1468575763-144889-1-git-send-email-gli...@google.com [ Minor edits. ] Signed-off-by: Ingo Molnar --- arch/x86/entry/entry_64.S | 11 +++ 1 file changed, 11 insertions(+) diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S index b846875..9f85827 100644 --- a/arch/x86/entry/entry_64.S +++ b/arch/x86/entry/entry_64.S @@ -601,9 +601,20 @@ apicinterrupt3 \num trace(\sym) smp_trace(\sym) .endm #endif +/* Make sure APIC interrupt handlers end up in the irqentry section: */ +#if defined(CONFIG_FUNCTION_GRAPH_TRACER) || defined(CONFIG_KASAN) +# define PUSH_SECTION_IRQENTRY .pushsection .irqentry.text, "ax" +# define POP_SECTION_IRQENTRY .popsection +#else +# define PUSH_SECTION_IRQENTRY +# define POP_SECTION_IRQENTRY +#endif + .macro apicinterrupt num sym do_sym +PUSH_SECTION_IRQENTRY apicinterrupt3 \num \sym \do_sym trace_apicinterrupt \num \sym +POP_SECTION_IRQENTRY .endm #ifdef CONFIG_SMP
Re: [PATCH][RESEND] thermal: hwmon: EXPORT_SYMBOL_GPL for thermal hwmon sysfs
On 三, 2016-08-10 at 02:54 +, Kuninori Morimoto wrote: > Hi Zhang > > > > > > > > > Hi Linux-PM, Linux-Kernel ML > > > > > > I posted thermal driver patch 2month ago, but no response and > > > nothing > > > happen. > > > I'm following scripts/get_maintainer.pl, but am I wrong ?? > > > Who is the maintainer of these patches ?? > > > > > The patch is queued for 4.8-rc2. > > As you can see at https://git.kernel.org/cgit/linux/kernel/git/rzha > > ng/linux.git/log/?h=next > Oh, thanks > But, I think it doesn't include [1/2] patch, is it rejected ? > Usually, soc thermal driver changes should go to Eduardo' tree first. I can also take soc thermal driver changes only if they've got ACK from either Eduardo or the driver Author. In your case, I can take patch 1/2, but let's see what Eduardo says first. thanks, rui > > > > > > > > > > > > > > > > > > > > Kuninori Morimoto (2): > > > > > thermal: rcar-thermal: enable hwmon when thermal_zone > > > > > thermal: hwmon: EXPORT_SYMBOL_GPL for thermal hwmon > > > > > sysfs > > Best regards > --- > Kuninori Morimoto
Re: [PATCH v4 2/4] mfd: Add Samsung Exynos Low Power Audio Subsystem driver
On Wed, 10 Aug 2016, Sylwester Nawrocki wrote:
> On 08/09/2016 10:50 PM, Lee Jones wrote:
> > On Tue, 09 Aug 2016, Sylwester Nawrocki wrote:
> >
> >> > On 08/09/2016 05:05 PM, Lee Jones wrote:
> > >> +static SIMPLE_DEV_PM_OPS(lpass_pm_ops, exynos_lpass_suspend,
> > > >> > +exynos_lpass_resume);
> >>> > > Put this up by the PM functions.
> >> >
> >> > Sorry, I don't understand this comment, which PM functions do you
> >> > mean exactly?
> > *_suspend and *_resume. PM == Power Management.
> >
> > You also need to place the functions in side some CONFIG_PM_SLEEP
> > guards. Grep around, you'll see what I mean.
>
> OK, but couldn't we just leave it with that SIMPLE_DEV_PM_OPS()
> macro? It saves us an #ifdef ugliness and if I actually grep
> drivers/mfd most of the drivers use either SIMPLE_DEV_PM_OPS() or
> SET_SYSTEM_SLEEP_PM_OPS. Are you asking me to change the above to:
>
> static const struct dev_pm_ops exynos_lpass_pm_ops = {
> #ifdef CONFIG_PM_SLEEP
> .suspend = exynos_lpass_suspend,
> .resume = exynos_lpass_resume,
> .freeze = exynos_lpass_suspend,
> .thaw = exynos_lpass_resume,
> .poweroff = exynos_lpass_suspend,
> .restore = exynos_lpass_resume,
> #endif
> }
>
> or perhaps
>
> static const struct dev_pm_ops exynos_lpass_pm_ops = {
> SET_SYSTEM_SLEEP_PM_OPS(exynos_lpass_suspend, exynos_lpass_resume)
> }
>
> ?
Not like that. Grep 'drivers/mfd' for "CONFIG_PM_SLEEP" as
suggested. You will find that the actual *_suspend and *_resume
functions are guarded in order to save space.
> I agree about the CONFIG_PM_SLEEP guards. There is very little
> chance though the LPASS driver will ever be used with
> CONFIG_PM_SLEEP disabled. How about adding __maybe_unused attribute
> to the *_suspend/*_resume functions then? I can see this pattern
> used already in drivers/mfd.
It's more common practice to use CONFIG_PM_SLEEP:
$ git grep __maybe_unused -- drivers/mfd/ | wc -l
7
$ git grep CONFIG_PM_SLEEP -- drivers/mfd/ | wc -l
31
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
Re: [PATCH v5 1/2] Use kmap_atomic when rewriting attached page
On Wed, Aug 10, 2016 at 5:56 AM, Tom Yan wrote:
> On 10 August 2016 at 09:00, Shaun Tancheff wrote:
>> static unsigned int ata_scsi_write_same_xlat(struct ata_queued_cmd *qc)
>> {
>> struct ata_taskfile *tf = &qc->tf;
>> struct scsi_cmnd *scmd = qc->scsicmd;
>> struct ata_device *dev = qc->dev;
>> const u8 *cdb = scmd->cmnd;
>> + struct scatterlist *sg;
>> u64 block;
>> u32 n_block;
>> + const u32 trmax = ATA_MAX_TRIM_RNUM;
>> u32 size;
>> - void *buf;
>> u16 fp;
>> u8 bp = 0xff;
>>
>> @@ -3319,10 +3363,9 @@ static unsigned int ata_scsi_write_same_xlat(struct
>> ata_queued_cmd *qc)
>> if (!scsi_sg_count(scmd))
>> goto invalid_param_len;
>>
>> - buf = page_address(sg_page(scsi_sglist(scmd)));
>> -
>> - if (n_block <= 65535 * ATA_MAX_TRIM_RNUM) {
>> - size = ata_set_lba_range_entries(buf, ATA_MAX_TRIM_RNUM,
>> block, n_block);
>> + sg = scsi_sglist(scmd);
>> + if (n_block <= 0x * cmax) {
>
> Although this got moved and corrected in the next patch, but perhaps
> you should still correct the `cmax` here, which should be `trmax`.
You are correct. I will fix this up. Thanks!
>> + size = ata_format_dsm_trim_descr(sg, trmax, block, n_block);
>> } else {
>> fp = 2;
>> goto invalid_fld;
--
Shaun Tancheff
[PATCH] time,virt: resync steal time when guest & host lose sync
On Wed, 10 Aug 2016 07:39:08 +0800
Wanpeng Li wrote:
> The regression is caused by your commit "sched,time: Count actually
> elapsed irq & softirq time".
Wanpeng, does this patch fix your issue?
Paolo, what is your opinion on this issue?
I can think of all kinds of ways in which guest and host might lose
sync with steal time, from uninitialized values at boot, to guest
pause, followed by save to disk, and reload, to live migration, to...
---8<---
Subject: time,virt: resync steal time when guest & host lose sync
When guest and host wildly disagree on steal time, a guest can
do several things:
1) Quickly account all the steal time at once (the kernel did this before
57430218317e ("sched/cputime: Count actually elapsed irq & softirq time"),
when steal_account_process_ticks got ULONG_MAX as its maximum value.
2) Stay out of sync for an indeterminate amount of time. This is what the
system does today.
3) Sync up the guest value to the host-provided value, without accounting
an absurdly large value in the cpu time statistics.
This patch makes the kernel do (3), which seems like the right thing
to do.
The exact value of the threshold use probably does not matter too much,
as long as it is long enough to cover all the timer ticks that passed
during an idle period, because (irqtime_)account_idle_ticks can process
a large amount of time all at once.
Signed-off-by: Rik van Riel
Reported-by: Wanpeng Li
---
kernel/sched/cputime.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 1934f658c036..c18f9e717af6 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -273,7 +273,17 @@ static __always_inline cputime_t
steal_account_process_time(cputime_t maxtime)
steal = paravirt_steal_clock(smp_processor_id());
steal -= this_rq()->prev_steal_time;
- steal_cputime = min(nsecs_to_cputime(steal), maxtime);
+ steal_cputime = nsecs_to_cputime(steal);
+ if (steal_cputime > 32 * maxtime) {
+ /*
+* Guest and host steal time values are way out of
+* sync. Sync up the guest steal time with the host.
+*/
+ this_rq()->prev_steal_time +=
+ cputime_to_nsecs(steal_cputime);
+ return 0;
+ }
+ steal_cputime = min(steal_cputime, maxtime);
account_steal_time(steal_cputime);
this_rq()->prev_steal_time += cputime_to_nsecs(steal_cputime);
Re: [PATCH v12 02/11] genirq/msi: msi_compose wrapper
Hi Thomas, On 09/08/2016 11:19, Thomas Gleixner wrote: > On Tue, 2 Aug 2016, Eric Auger wrote: > >> Currently the MSI message is composed by directly calling >> irq_chip_compose_msi_msg and erased by setting the memory to zero. >> >> On some platforms, we will need to complexify this composition to >> properly handle MSI emission through IOMMU. Also we will need to track >> when the MSI message is erased. > > I just can't find how you do that. After applying the series the > >> +if (erase) >> +memset(msg, 0, sizeof(*msg)); > > branch is still just a memset(). The wrapper is fine for the compose side, but > having the extra argument just to wrap the memset() for no gain is silly. Yes you're right: this was true in the first releases of the series where the iommu mapping/unmapping were done at composition & erase time. Now the mapping/unmapping is done on msi_domain_alloc/free_irqs, this is not mandated anymore. I will keep the wrapper for the compose side and remove the rest + update the commit message accordingly. Thank you for your time. Eric > > Thanks, > > tglx > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >
[PATCH REBASED v10 6/6] drm/i915/skl: Update DDB values atomically with wms/plane attrs
Now that we can hook into update_crtcs and control the order in which we
update CRTCs at each modeset, we can finish the final step of fixing
Skylake's watermark handling by performing DDB updates at the same time
as plane updates and watermark updates.
The first major change in this patch is skl_update_crtcs(), which
handles ensuring that we order each CRTC update in our atomic commits
properly so that they honor the DDB flush order.
The second major change in this patch is the order in which we flush the
pipes. While the previous order may have worked, it can't be used in
this approach since it no longer will do the right thing. For example,
using the old ddb flush order:
We have pipes A, B, and C enabled, and we're disabling C. Initial ddb
allocation looks like this:
| A | B |xxx|
Since we're performing the ddb updates after performing any CRTC
disablements in intel_atomic_commit_tail(), the space to the right of
pipe B is unallocated.
1. Flush pipes with new allocation contained into old space. None
apply, so we skip this
2. Flush pipes having their allocation reduced, but overlapping with a
previous allocation. None apply, so we also skip this
3. Flush pipes that got more space allocated. This applies to A and B,
giving us the following update order: A, B
This is wrong, since updating pipe A first will cause it to overlap with
B and potentially burst into flames. Our new order (see the code
comments for details) would update the pipes in the proper order: B, A.
As well, we calculate the order for each DDB update during the check
phase, and reference it later in the commit phase when we hit
skl_update_crtcs().
This long overdue patch fixes the rest of the underruns on Skylake.
Changes since v1:
- Add skl_ddb_entry_write() for cursor into skl_write_cursor_wm()
Changes since v2:
- Use the method for updating CRTCs that Ville suggested
- In skl_update_wm(), only copy the watermarks for the crtc that was
passed to us
Changes since v3:
- Small comment fix in skl_ddb_allocation_overlaps()
Fixes: 0e8fb7ba7ca5 ("drm/i915/skl: Flush the WM configuration")
Fixes: 8211bd5bdf5e ("drm/i915/skl: Program the DDB allocation")
[omitting CC for stable, since this patch will need to be changed for
such backports first]
Testcase: kms_cursor_legacy
Signed-off-by: Lyude
Reviewed-by: Maarten Lankhorst
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Radhakrishna Sripada
Cc: Hans de Goede
Cc: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 100 +++--
drivers/gpu/drm/i915/intel_drv.h | 7 ++
drivers/gpu/drm/i915/intel_pm.c | 207 +--
3 files changed, 144 insertions(+), 170 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 9670ec0..8e81514 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12974,16 +12974,23 @@ static void verify_wm_state(struct drm_crtc *crtc,
hw_entry->start, hw_entry->end);
}
- /* cursor */
- hw_entry = &hw_ddb.plane[pipe][PLANE_CURSOR];
- sw_entry = &sw_ddb->plane[pipe][PLANE_CURSOR];
-
- if (!skl_ddb_entry_equal(hw_entry, sw_entry)) {
- DRM_ERROR("mismatch in DDB state pipe %c cursor "
- "(expected (%u,%u), found (%u,%u))\n",
- pipe_name(pipe),
- sw_entry->start, sw_entry->end,
- hw_entry->start, hw_entry->end);
+ /*
+* cursor
+* If the cursor plane isn't active, we may not have updated it's ddb
+* allocation. In that case since the ddb allocation will be updated
+* once the plane becomes visible, we can skip this check
+*/
+ if (intel_crtc->cursor_addr) {
+ hw_entry = &hw_ddb.plane[pipe][PLANE_CURSOR];
+ sw_entry = &sw_ddb->plane[pipe][PLANE_CURSOR];
+
+ if (!skl_ddb_entry_equal(hw_entry, sw_entry)) {
+ DRM_ERROR("mismatch in DDB state pipe %c cursor "
+ "(expected (%u,%u), found (%u,%u))\n",
+ pipe_name(pipe),
+ sw_entry->start, sw_entry->end,
+ hw_entry->start, hw_entry->end);
+ }
}
}
@@ -13735,6 +13742,72 @@ static void intel_update_crtcs(struct drm_atomic_state
*state,
}
}
+static void skl_update_crtcs(struct drm_atomic_state *state,
+unsigned int *crtc_vblank_mask)
+{
+ struct drm_device *dev = state->dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *old_crtc_state;
+ struct skl_ddb_allocation *new_ddb = &intel_state->wm_results.ddb;
+ struct skl_ddb_allocatio
Re: [PATCH v2] exynos-drm: Fix unsupported GEM memory type error message to be clear
Hello Shuah,
On 08/08/2016 07:48 PM, Shuah Khan wrote:
> Fix unsupported GEM memory type error message to include the memory type
> information.
>
> Signed-off-by: Shuah Khan
> ---
> Changes since v1:
> -- Comment changed to read clearly
>
> drivers/gpu/drm/exynos/exynos_drm_fb.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> index e016640..40ce841 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
> @@ -55,11 +55,11 @@ static int check_fb_gem_memory_type(struct drm_device
> *drm_dev,
> flags = exynos_gem->flags;
>
> /*
> - * without iommu support, not support physically non-continuous memory
> - * for framebuffer.
> + * Physically non-contiguous memory type for framebuffer is not
> + * supported without IOMMU.
>*/
> if (IS_NONCONTIG_BUFFER(flags)) {
> - DRM_ERROR("cannot use this gem memory type for fb.\n");
> + DRM_ERROR("Non-contiguous GEM memory is not supported.\n");
> return -EINVAL;
> }
>
>
Patch looks good to me.
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
Re: [PATCH 1/7] ima: on soft reboot, restore the measurement list
Thiago Jung Bauermann writes:
> Am Mittwoch, 10 August 2016, 13:41:08 schrieb Michael Ellerman:
>> Thiago Jung Bauermann writes:
>> > Am Dienstag, 09 August 2016, 09:01:13 schrieb Mimi Zohar:
>> >> On Tue, 2016-08-09 at 20:59 +1000, Michael Ellerman wrote:
>> >> > Mimi Zohar writes:
>> >> > > +/* Some details preceding the binary serialized measurement list
>> >> > > */
>> >> > > +struct ima_kexec_hdr {
>> >> > > + unsigned short version;
>> >> > > + unsigned long buffer_size;
>> >> > > + unsigned long count;
>> >> > > +} __packed;
>> >> > > +
>> >> >
>> >> > Am I understanding it correctly that this structure is passed between
>> >> > kernels?
>> >>
>> >> Yes, the header prefixes the measurement list, which is being passed on
>> >> the same computer to the next kernel. Could the architecture (eg.
>> >> LE/BE) change between soft re-boots?
>> >
>> > Yes. I am able to boot a BE kernel from an LE kernel with my patches.
>> > Whether we want to support that or not is another question...
>>
>> Yes you must support that. BE -> LE and vice versa.
>
> I didn't test BE - LE yet, but will do.
Thanks.
>> You should also consider the possibility that the next kernel is not
>> Linux.
>
> If the next kernel is an ELF binary and it supports the kexec "calling
> convention", it should work too. What could possibly go wrong? I can try
> FreeBSD (I suppose it's an ELF kernel) and see what happens.
At least for old style kexec (not sys_kexec_load()) I don't think it
even needs to be an ELF binary.
I think there are folks working on FreeBSD (or $?BSD), so I think the
basic kexec part works.
There's nothing (yet) that wants to use this measurement list obviously,
but it should be designed such that it could be used by an unknown
future kernel that knows the ABI.
So given what you have above, you'd use something like:
struct ima_kexec_hdr {
u16 version;
u16 _reserved0;
u32 _reserved1;
u64 buffer_size;
u64 count;
};
cheers
[tip:x86/mm] x86/mm/KASLR: Fix physical memory calculation on KASLR memory randomization
Commit-ID: c7d2361f7524f365c1ae42f47880e3fa9efb2c2a
Gitweb: http://git.kernel.org/tip/c7d2361f7524f365c1ae42f47880e3fa9efb2c2a
Author: Thomas Garnier
AuthorDate: Tue, 9 Aug 2016 10:11:04 -0700
Committer: Ingo Molnar
CommitDate: Wed, 10 Aug 2016 14:45:19 +0200
x86/mm/KASLR: Fix physical memory calculation on KASLR memory randomization
Initialize KASLR memory randomization after max_pfn is initialized. Also
ensure the size is rounded up. It could create problems on machines
with more than 1Tb of memory on certain random addresses.
Signed-off-by: Thomas Garnier
Cc: Aleksey Makarov
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Baoquan He
Cc: Borislav Petkov
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Christian Borntraeger
Cc: Dan Williams
Cc: Dave Hansen
Cc: Dave Young
Cc: Denys Vlasenko
Cc: Fabian Frederick
Cc: H. Peter Anvin
Cc: Joerg Roedel
Cc: Josh Poimboeuf
Cc: Kees Cook
Cc: Linus Torvalds
Cc: Lv Zheng
Cc: Mark Salter
Cc: Peter Zijlstra
Cc: Rafael J . Wysocki
Cc: Thomas Gleixner
Cc: Toshi Kani
Cc: kernel-harden...@lists.openwall.com
Fixes: 021182e52fe0 ("Enable KASLR for physical mapping memory regions")
Link:
http://lkml.kernel.org/r/1470762665-88032-1-git-send-email-thgar...@google.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/setup.c | 8 ++--
arch/x86/mm/kaslr.c | 2 +-
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 991b779..95cf31c 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -936,8 +936,6 @@ void __init setup_arch(char **cmdline_p)
x86_init.oem.arch_setup();
- kernel_randomize_memory();
-
iomem_resource.end = (1ULL << boot_cpu_data.x86_phys_bits) - 1;
setup_memory_map();
parse_setup_data();
@@ -1055,6 +1053,12 @@ void __init setup_arch(char **cmdline_p)
max_possible_pfn = max_pfn;
+ /*
+* Define random base addresses for memory sections after max_pfn is
+* defined and before each memory section base is used.
+*/
+ kernel_randomize_memory();
+
#ifdef CONFIG_X86_32
/* max_low_pfn get updated here */
find_low_pfn_range();
diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index 26dccd6..ec8654f 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -97,7 +97,7 @@ void __init kernel_randomize_memory(void)
* add padding if needed (especially for memory hotplug support).
*/
BUG_ON(kaslr_regions[0].base != &page_offset_base);
- memory_tb = ((max_pfn << PAGE_SHIFT) >> TB_SHIFT) +
+ memory_tb = DIV_ROUND_UP(max_pfn << PAGE_SHIFT, 1UL << TB_SHIFT) +
CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING;
/* Adapt phyiscal memory region size based on available memory */
Re: [PATCH v3 08/13] net: ethernet: ti: cpsw: move links on h/w registers to cpsw_common
On Wednesday 10 August 2016 04:52 AM, Ivan Khoronzhuk wrote: > The pointers on h/w registers are common for every cpsw_private > instance, so no need to hold them for every ndev. > > Signed-off-by: Ivan Khoronzhuk Reviewed-by: Mugunthan V N Regards Mugunthan V N
[PATCH REBASED v10 3/6] drm/i915/skl: Update plane watermarks atomically during plane updates
Thanks to Ville for suggesting this as a potential solution to pipe
underruns on Skylake.
On Skylake all of the registers for configuring planes, including the
registers for configuring their watermarks, are double buffered. New
values written to them won't take effect until said registers are
"armed", which is done by writing to the PLANE_SURF (or in the case of
cursor planes, the CURBASE register) register.
With this in mind, up until now we've been updating watermarks on skl
like this:
non-modeset {
- calculate (during atomic check phase)
- finish_atomic_commit:
- intel_pre_plane_update:
- intel_update_watermarks()
- {vblank happens; new watermarks + old plane values => underrun }
- drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- end vblank evasion
}
or
modeset {
- calculate (during atomic check phase)
- finish_atomic_commit:
- crtc_enable:
- intel_update_watermarks()
- {vblank happens; new watermarks + old plane values => underrun }
- drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- end vblank evasion
}
Now we update watermarks atomically like this:
non-modeset {
- calculate (during atomic check phase)
- finish_atomic_commit:
- intel_pre_plane_update:
- intel_update_watermarks() (wm values aren't written yet)
- drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- write new wm values
- end vblank evasion
}
modeset {
- calculate (during atomic check phase)
- finish_atomic_commit:
- crtc_enable:
- intel_update_watermarks() (actual wm values aren't written
yet)
- drm_atomic_helper_commit_planes_on_crtc:
- start vblank evasion
- write new plane registers
- write new wm values
- end vblank evasion
}
So this patch moves all of the watermark writes into the right place;
inside of the vblank evasion where we update all of the registers for
each plane. While this patch doesn't fix everything, it does allow us to
update the watermark values in the way the hardware expects us to.
Changes since original patch series:
- Remove mutex_lock/mutex_unlock since they don't do anything and we're
not touching global state
- Move skl_write_cursor_wm/skl_write_plane_wm functions into
intel_pm.c, make externally visible
- Add skl_write_plane_wm calls to skl_update_plane
- Fix conditional for for loop in skl_write_plane_wm (level < max_level
should be level <= max_level)
- Make diagram in commit more accurate to what's actually happening
- Add Fixes:
Changes since v1:
- Use IS_GEN9() instead of IS_SKYLAKE() since these fixes apply to more
then just Skylake
- Update description to make it clear this patch doesn't fix everything
- Check if pipes were actually changed before writing watermarks
Changes since v2:
- Write PIPE_WM_LINETIME during vblank evasion
Changes since v3:
- Rebase against new SAGV patch changes
Changes since v4:
- Add a parameter to choose what skl_wm_values struct to use when
writing new plane watermarks
Changes since v5:
- Remove cursor ddb entry write in skl_write_cursor_wm(), defer until
patch 6
- Write WM_LINETIME in intel_begin_crtc_commit()
Changes since v6:
- Remove redundant dirty_pipes check in skl_write_plane_wm (we check
this in all places where we call this function, and it was supposed
to have been removed earlier anyway)
- In i9xx_update_cursor(), use dev_priv->info.gen >= 9 instead of
IS_GEN9(dev_priv). We do this everywhere else and I'd imagine this
needs to be done for gen10 as well
Fixes: 2d41c0b59afc ("drm/i915/skl: SKL Watermark Computation")
Signed-off-by: Lyude
Reviewed-by: Matt Roper
Cc: sta...@vger.kernel.org
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Radhakrishna Sripada
Cc: Hans de Goede
---
drivers/gpu/drm/i915/intel_display.c | 16 +++-
drivers/gpu/drm/i915/intel_drv.h | 5
drivers/gpu/drm/i915/intel_pm.c | 50
drivers/gpu/drm/i915/intel_sprite.c | 6 +
4 files changed, 60 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 302cb1f..429810b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2980,6 +2980,7 @@ static void skylake_update_primary_plane(struct drm_plane
*plane,
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_framebuffer *fb = plane_state->base.fb;
struct drm_i915_gem_object *obj = intel_fb_obj(fb);
+ struct skl_wm_values *wm = &dev_priv->wm.skl_results;
int pipe = intel_crtc->pipe;
u32 plane_ctl, stride_div, stride;
u32 tile_height, plane_offset, plane_size;
@@ -3
[tip:x86/urgent] x86/platform/UV: Fix problem with UV4 BIOS providing incorrect PXM values
Commit-ID: 22ac2bca92f2d92c6495248d65ff648182df428d
Gitweb: http://git.kernel.org/tip/22ac2bca92f2d92c6495248d65ff648182df428d
Author: Mike Travis
AuthorDate: Mon, 1 Aug 2016 13:40:52 -0500
Committer: Ingo Molnar
CommitDate: Wed, 10 Aug 2016 15:55:38 +0200
x86/platform/UV: Fix problem with UV4 BIOS providing incorrect PXM values
There are some circumstances where the UV4 BIOS cannot provide the
correct Proximity Node values to associate with specific Sockets and
Physical Nodes. The decision was made to remove these values from BIOS
and for the kernel to get these values from the standard ACPI tables.
Tested-by: Frank Ramsay
Tested-by: John Estabrook
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Nathan Zimmer
Cc: Alex Thorlton
Cc: Andrew Banman
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Russ Anderson
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/20160801184050.414210...@asylum.americas.sgi.com
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/uv/bios.h | 5 +++--
arch/x86/kernel/apic/x2apic_uv_x.c | 28 ++--
2 files changed, 13 insertions(+), 20 deletions(-)
diff --git a/arch/x86/include/asm/uv/bios.h b/arch/x86/include/asm/uv/bios.h
index c852590..e652a7c 100644
--- a/arch/x86/include/asm/uv/bios.h
+++ b/arch/x86/include/asm/uv/bios.h
@@ -79,7 +79,7 @@ struct uv_gam_range_entry {
u16 nasid; /* HNasid */
u16 sockid; /* Socket ID, high bits of APIC ID */
u16 pnode; /* Index to MMR and GRU spaces */
- u32 pxm;/* ACPI proximity domain number */
+ u32 unused2;
u32 limit; /* PA bits 56:26 (UV_GAM_RANGE_SHFT) */
};
@@ -88,7 +88,8 @@ struct uv_gam_range_entry {
#defineUV_SYSTAB_VERSION_UV4 0x400 /* UV4 BIOS base
version */
#defineUV_SYSTAB_VERSION_UV4_1 0x401 /* + gpa_shift */
#defineUV_SYSTAB_VERSION_UV4_2 0x402 /* +
TYPE_NVRAM/WINDOW/MBOX */
-#defineUV_SYSTAB_VERSION_UV4_LATESTUV_SYSTAB_VERSION_UV4_2
+#defineUV_SYSTAB_VERSION_UV4_3 0x403 /* - GAM Range PXM
Value */
+#defineUV_SYSTAB_VERSION_UV4_LATESTUV_SYSTAB_VERSION_UV4_3
#defineUV_SYSTAB_TYPE_UNUSED 0 /* End of table (offset
== 0) */
#defineUV_SYSTAB_TYPE_GAM_PARAMS 1 /* GAM PARAM
conversions */
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c
b/arch/x86/kernel/apic/x2apic_uv_x.c
index d918733..6aa0545 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -1156,19 +1156,18 @@ static void __init decode_gam_rng_tbl(unsigned long ptr)
for (; gre->type != UV_GAM_RANGE_TYPE_UNUSED; gre++) {
if (!index) {
pr_info("UV: GAM Range Table...\n");
- pr_info("UV: # %20s %14s %5s %4s %5s %3s %2s %3s\n",
+ pr_info("UV: # %20s %14s %5s %4s %5s %3s %2s\n",
"Range", "", "Size", "Type", "NASID",
- "SID", "PN", "PXM");
+ "SID", "PN");
}
pr_info(
- "UV: %2d: 0x%014lx-0x%014lx %5luG %3d %04x %02x %02x %3d\n",
+ "UV: %2d: 0x%014lx-0x%014lx %5luG %3d %04x %02x %02x\n",
index++,
(unsigned long)lgre << UV_GAM_RANGE_SHFT,
(unsigned long)gre->limit << UV_GAM_RANGE_SHFT,
((unsigned long)(gre->limit - lgre)) >>
(30 - UV_GAM_RANGE_SHFT), /* 64M -> 1G */
- gre->type, gre->nasid, gre->sockid,
- gre->pnode, gre->pxm);
+ gre->type, gre->nasid, gre->sockid, gre->pnode);
lgre = gre->limit;
if (sock_min > gre->sockid)
@@ -1287,7 +1286,7 @@ static void __init build_socket_tables(void)
_pnode_to_socket[i] = SOCK_EMPTY;
/* fill in pnode/node/addr conversion list values */
- pr_info("UV: GAM Building socket/pnode/pxm conversion tables\n");
+ pr_info("UV: GAM Building socket/pnode conversion tables\n");
for (; gre->type != UV_GAM_RANGE_TYPE_UNUSED; gre++) {
if (gre->type == UV_GAM_RANGE_TYPE_HOLE)
continue;
@@ -1295,20 +1294,18 @@ static void __init build_socket_tables(void)
if (_socket_to_pnode[i] != SOCK_EMPTY)
continue; /* duplicate */
_socket_to_pnode[i] = gre->pnode;
- _socket_to_node[i] = gre->pxm;
i = gre->pnode - minpnode;
_pnode_to_socket[i] = gre->sockid;
pr_info(
- "UV: sid:%02x type:%d nasid:%04x pn:%02x pxm:%2d pn2s:%2x\n",
+ "UV: sid:%02x type:%d nasid:%04x pn:%02x pn2s
[PATCH v6 00/11] make direct compaction more deterministic
Changes since v3 * The first part with cleanups (v4, v5) went separately to 4.8-rc1 * Rebased to 4.8-rc1 * Patch 1 - don't touch cached pfns in whole-zone compaction (Joonsoo) * New patches 2 and 3 in response to Joonsoo pointing out missing adustments to watermark checks in patch 7 - turns out we can remove those watermark checks altogether. * Patch 6 made less aggressive to avoid premature OOM (Joonsoo) This is mostly a followup to Michal's oom detection rework, which highlighted the need for direct compaction to provide better feedback in reclaim/compaction loop, so that it can reliably recognize when compaction cannot make further progress, and allocation should invoke OOM killer or fail. We've discussed this at LSF/MM [1] where I proposed expanding the async/sync migration mode used in compaction to more general "priorities". This patchset adds one new priority that just overrides all the heuristics and makes compaction fully scan all zones. I don't currently think that we need more fine-grained priorities, but we'll see. Other than that there's some smaller fixes and cleanups, mainly related to the THP-specific hacks. I've tested this with stress-highalloc in GFP_KERNEL order-4 and THP-like order-9 scenarios. There's some improvement for compaction stats for the order-4, which is likely due to the better watermarks handling. In the previous version I reported mostly noise wrt compaction stats, and decreased direct reclaim - now the reclaim is without difference. I believe this is due to the less aggressive compaction priority increase in patch 6. "before" is a mmotm tree prior to 4.7 release plus the first part of the series that was sent and merged separately beforeafter order-4: Compaction stalls27216 30759 Compaction success 19598 25475 Compaction failures 76175283 Page migrate success370510 464919 Page migrate failure 25712 27987 Compaction pages isolated 849601 1041581 Compaction migrate scanned 143146541 101084990 Compaction free scanned 208355124 144863510 Compaction cost 14031210 order-9: Compaction stalls 73117401 Compaction success16341683 Compaction failures 56775718 Page migrate success194657 183988 Page migrate failure 47534170 Compaction pages isolated 498790 456130 Compaction migrate scanned 565371 524174 Compaction free scanned4230296 4250744 Compaction cost215 203 [1] https://lwn.net/Articles/684611/ Vlastimil Babka (11): mm, compaction: make whole_zone flag ignore cached scanner positions mm, compaction: cleanup unused functions mm, compaction: rename COMPACT_PARTIAL to COMPACT_SUCCESS mm, compaction: don't recheck watermarks after COMPACT_SUCCESS mm, compaction: add the ultimate direct compaction priority mm, compaction: more reliably increase direct compaction priority mm, compaction: use correct watermark when checking compaction success mm, compaction: create compact_gap wrapper mm, compaction: use proper alloc_flags in __compaction_suitable() mm, compaction: require only min watermarks for non-costly orders mm, vmscan: make compaction_ready() more accurate and readable include/linux/compaction.h| 32 +--- include/trace/events/compaction.h | 2 +- mm/compaction.c | 154 +- mm/internal.h | 2 +- mm/page_alloc.c | 22 +++--- mm/vmscan.c | 49 ++-- 6 files changed, 128 insertions(+), 133 deletions(-) -- 2.9.2
[PATCH 08/21] net: thunderx: Add 81xx support to BGX driver
From: Sunil Goutham
This patch adds support for BGX module on 81xx where a BGX
can be split and have different LMACs configured in
different modes.
Signed-off-by: Sunil Goutham
---
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 112 --
drivers/net/ethernet/cavium/thunder/thunder_bgx.h | 11 +++
2 files changed, 113 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
index 4497427..9c3c273 100644
--- a/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
+++ b/drivers/net/ethernet/cavium/thunder/thunder_bgx.c
@@ -50,6 +50,7 @@ struct bgx {
int lmac_count;
void __iomem*reg_base;
struct pci_dev *pdev;
+ boolis_81xx;
};
static struct bgx *bgx_vnic[MAX_BGX_THUNDER];
@@ -803,9 +804,17 @@ static void bgx_print_qlm_mode(struct bgx *bgx, u8 lmacid)
struct device *dev = &bgx->pdev->dev;
struct lmac *lmac;
char str[20];
+ u8 dlm;
+
+ if (lmacid > MAX_LMAC_PER_BGX)
+ return;
lmac = &bgx->lmac[lmacid];
- sprintf(str, "BGX%d QLM mode", bgx->bgx_id);
+ dlm = (lmacid / 2) + (bgx->bgx_id * 2);
+ if (!bgx->is_81xx)
+ sprintf(str, "BGX%d QLM mode", bgx->bgx_id);
+ else
+ sprintf(str, "BGX%d DLM%d mode", bgx->bgx_id, dlm);
switch (lmac->lmac_type) {
case BGX_MODE_SGMII:
@@ -857,26 +866,81 @@ static void lmac_set_lane2sds(struct lmac *lmac)
static void bgx_set_lmac_config(struct bgx *bgx, u8 idx)
{
struct lmac *lmac;
+ struct lmac *olmac;
u64 cmr_cfg;
+ u8 lmac_type;
+ u8 lane_to_sds;
lmac = &bgx->lmac[idx];
- lmac->lmacid = idx;
- /* Read LMAC0 type to figure out QLM mode
-* This is configured by low level firmware
+ if (!bgx->is_81xx) {
+ /* Read LMAC0 type to figure out QLM mode
+* This is configured by low level firmware
+*/
+ cmr_cfg = bgx_reg_read(bgx, 0, BGX_CMRX_CFG);
+ lmac->lmac_type = (cmr_cfg >> 8) & 0x07;
+ lmac->use_training =
+ bgx_reg_read(bgx, 0, BGX_SPUX_BR_PMD_CRTL) &
+ SPU_PMD_CRTL_TRAIN_EN;
+ lmac_set_lane2sds(lmac);
+ return;
+ }
+
+ /* On 81xx BGX can be split across 2 DLMs
+* firmware programs lmac_type of LMAC0 and LMAC2
*/
- cmr_cfg = bgx_reg_read(bgx, 0, BGX_CMRX_CFG);
- lmac->lmac_type = (cmr_cfg >> 8) & 0x07;
- lmac->use_training =
- bgx_reg_read(bgx, 0, BGX_SPUX_BR_PMD_CRTL) &
+ if ((idx == 0) || (idx == 2)) {
+ cmr_cfg = bgx_reg_read(bgx, idx, BGX_CMRX_CFG);
+ lmac_type = (u8)((cmr_cfg >> 8) & 0x07);
+ lane_to_sds = (u8)(cmr_cfg & 0xFF);
+ /* Check if config is not reset value */
+ if ((lmac_type == 0) && (lane_to_sds == 0xE4))
+ lmac->lmac_type = BGX_MODE_INVALID;
+ else
+ lmac->lmac_type = lmac_type;
+ lmac->use_training =
+ bgx_reg_read(bgx, idx, BGX_SPUX_BR_PMD_CRTL) &
+ SPU_PMD_CRTL_TRAIN_EN;
+ lmac_set_lane2sds(lmac);
+
+ /* Set LMAC type of other lmac on same DLM i.e LMAC 1/3 */
+ olmac = &bgx->lmac[idx + 1];
+ olmac->lmac_type = lmac->lmac_type;
+ olmac->use_training =
+ bgx_reg_read(bgx, idx + 1, BGX_SPUX_BR_PMD_CRTL) &
SPU_PMD_CRTL_TRAIN_EN;
- lmac_set_lane2sds(lmac);
+ lmac_set_lane2sds(olmac);
+ }
+}
+
+static bool is_dlm0_in_bgx_mode(struct bgx *bgx)
+{
+ struct lmac *lmac;
+
+ if (!bgx->is_81xx)
+ return true;
+
+ lmac = &bgx->lmac[1];
+ if (lmac->lmac_type == BGX_MODE_INVALID)
+ return false;
+
+ return true;
}
static void bgx_get_qlm_mode(struct bgx *bgx)
{
+ struct lmac *lmac;
+ struct lmac *lmac01;
+ struct lmac *lmac23;
u8 idx;
+ /* Init all LMAC's type to invalid */
+ for (idx = 0; idx < MAX_LMAC_PER_BGX; idx++) {
+ lmac = &bgx->lmac[idx];
+ lmac->lmac_type = BGX_MODE_INVALID;
+ lmac->lmacid = idx;
+ }
+
/* It is assumed that low level firmware sets this value */
bgx->lmac_count = bgx_reg_read(bgx, 0, BGX_CMR_RX_LMACS) & 0x7;
if (bgx->lmac_count > MAX_LMAC_PER_BGX)
@@ -884,7 +948,28 @@ static void bgx_get_qlm_mode(struct bgx *bgx)
for (idx = 0; idx < bgx->lmac_count; idx++)
bgx_set_lmac_config(bgx, idx);
- bgx_print_qlm_mode(bgx, 0);
+
+ if (!bgx->is_81xx) {
+ bgx_print_qlm_mode(bgx, 0)
dmatest no longer works on ARC SDP with DW DMAC
dmatest on ARC SDP with DW DMAC became broken after df5c7386
("dmaengine: dw: some Intel devices has no memcpy support") and
30cb2639 ("dmaengine: dw: don't override platform data with autocfg")
commits.
* After df5c7386 commit "DMA_MEMCPY" capability option doesn't
get set correctly in platform driver version.
* After 30cb2639 commit
"data_width" and "nollp" parameters don't get set correctly in platform
driver version.
This happens because in old driver version there are three sources
of parameters: pdata, device tree and autoconfig hardware registers.
Some parameters were read from pdata and others from autoconfig
hardware registers. If pdata was absent some pdata structure
fields were filled with parameters from device tree. But 30cb2639
commit disabled overriding pdata with autocfg, so if we use platform
driver version without pdata some parameters will not be set.
I'm wondering what would be the best way to fix this situation?
Should we strictly read parameters from only one source (pdata/device
tree/autoconfig) or we may mix some of them (for example getting
missing data from autoconf regs)?
Re: [Patch v3 2/2] x86/acpi: Remove the repeated lapic address override entry parsing
* Baoquan He wrote: > ACPI MADT has a 32-bit field providing lapic address at which > each processor can access its lapic information. MADT also contains > an optional entry to provide a 64-bit address to override the 32-bit > one. However the current code does the lapic address override entry > parsing twice. One is in early_acpi_boot_init() because AMD NUMA need > get boot_cpu_id earlier. The other is in acpi_boot_init() which parses > all MADT entries. > > So in this patch remove the repeated code in the 2nd part. Meanwhile > print lapic override entry information like other MADT entry, this > will be added to boot log. it is not at all clear to me from this changelog whether the change is supposed to change anything. If not then please spell it out explicitly: "This patch is not supposed to change any behavior." Or so. Thanks, Ingo
Re: [PATCH] perf unwind: check symsrc ELF for .debug_frame
Em Wed, Aug 10, 2016 at 03:36:16PM +0200, Rabin Vincent escreveu:
> From: Rabin Vincent
>
> When using split debug info, the file without debug info may not have a
> .debug_frame section, so we need to check the symsrc ELF also, since
> that's the file we actually read the unwind information from.
Thanks for your work, next time please also copy the persons that did
work on this file recently, like:
He Kuang
And people who acked or reviewed their patches, like:
Jiri Olsa
Guys, are you ok with these changes? 2/2 seems trivial enough.
- Arnaldo
> Signed-off-by: Rabin Vincent
> ---
> tools/perf/util/unwind-libunwind-local.c | 14 ++
> 1 file changed, 14 insertions(+)
>
> diff --git a/tools/perf/util/unwind-libunwind-local.c
> b/tools/perf/util/unwind-libunwind-local.c
> index 97c0f8f..d492192 100644
> --- a/tools/perf/util/unwind-libunwind-local.c
> +++ b/tools/perf/util/unwind-libunwind-local.c
> @@ -308,6 +308,20 @@ static int read_unwind_spec_debug_frame(struct dso *dso,
> dso__data_put_fd(dso);
> }
>
> + /*
> + * With split debug info, the file without debug info may not have a
> + * .debug_frame, so check the symsrc too.
> + */
> + if (ofs == 0 && dso->symsrc_filename) {
> + fd = open(dso->symsrc_filename, O_RDONLY);
> + if (fd < 0)
> + return -EINVAL;
> +
> + ofs = elf_section_offset(fd, ".debug_frame");
> + dso->data.debug_frame_offset = ofs;
> + close(fd);
> + }
> +
> *offset = ofs;
> if (*offset)
> return 0;
> --
> 2.1.4
[tip:x86/mm] x86/mm/64: Enable KASLR for vmemmap memory region
Commit-ID: 25dfe4785332723f09311dcb7fd91015a60c022f
Gitweb: http://git.kernel.org/tip/25dfe4785332723f09311dcb7fd91015a60c022f
Author: Thomas Garnier
AuthorDate: Wed, 27 Jul 2016 08:59:56 -0700
Committer: Ingo Molnar
CommitDate: Wed, 10 Aug 2016 16:10:06 +0200
x86/mm/64: Enable KASLR for vmemmap memory region
Add vmemmap in the list of randomized memory regions.
The vmemmap region holds a representation of the physical memory (through
a struct page array). An attacker could use this region to disclose the
kernel memory layout (walking the page linked list).
Signed-off-by: Thomas Garnier
Signed-off-by: Kees Cook
Cc: Andy Lutomirski
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Denys Vlasenko
Cc: H. Peter Anvin
Cc: Josh Poimboeuf
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: kernel-harden...@lists.openwall.com
Link:
http://lkml.kernel.org/r/1469635196-122447-1-git-send-email-thgar...@google.com
[ Minor edits. ]
Signed-off-by: Ingo Molnar
---
arch/x86/include/asm/kaslr.h| 1 +
arch/x86/include/asm/pgtable_64_types.h | 4 +++-
arch/x86/mm/kaslr.c | 26 --
3 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/arch/x86/include/asm/kaslr.h b/arch/x86/include/asm/kaslr.h
index 2674ee3..1052a79 100644
--- a/arch/x86/include/asm/kaslr.h
+++ b/arch/x86/include/asm/kaslr.h
@@ -6,6 +6,7 @@ unsigned long kaslr_get_random_long(const char *purpose);
#ifdef CONFIG_RANDOMIZE_MEMORY
extern unsigned long page_offset_base;
extern unsigned long vmalloc_base;
+extern unsigned long vmemmap_base;
void kernel_randomize_memory(void);
#else
diff --git a/arch/x86/include/asm/pgtable_64_types.h
b/arch/x86/include/asm/pgtable_64_types.h
index 6fdef9e..3a26420 100644
--- a/arch/x86/include/asm/pgtable_64_types.h
+++ b/arch/x86/include/asm/pgtable_64_types.h
@@ -57,11 +57,13 @@ typedef struct { pteval_t pte; } pte_t;
#define MAXMEM _AC(__AC(1, UL) << MAX_PHYSMEM_BITS, UL)
#define VMALLOC_SIZE_TB_AC(32, UL)
#define __VMALLOC_BASE _AC(0xc900, UL)
-#define VMEMMAP_START _AC(0xea00, UL)
+#define __VMEMMAP_BASE _AC(0xea00, UL)
#ifdef CONFIG_RANDOMIZE_MEMORY
#define VMALLOC_START vmalloc_base
+#define VMEMMAP_START vmemmap_base
#else
#define VMALLOC_START __VMALLOC_BASE
+#define VMEMMAP_START __VMEMMAP_BASE
#endif /* CONFIG_RANDOMIZE_MEMORY */
#define VMALLOC_END(VMALLOC_START + _AC((VMALLOC_SIZE_TB << 40) - 1, UL))
#define MODULES_VADDR(__START_KERNEL_map + KERNEL_IMAGE_SIZE)
diff --git a/arch/x86/mm/kaslr.c b/arch/x86/mm/kaslr.c
index ec8654f..aec03aa 100644
--- a/arch/x86/mm/kaslr.c
+++ b/arch/x86/mm/kaslr.c
@@ -40,17 +40,26 @@
* You need to add an if/def entry if you introduce a new memory region
* compatible with KASLR. Your entry must be in logical order with memory
* layout. For example, ESPFIX is before EFI because its virtual address is
- * before. You also need to add a BUILD_BUG_ON in kernel_randomize_memory to
+ * before. You also need to add a BUILD_BUG_ON() in kernel_randomize_memory()
to
* ensure that this order is correct and won't be changed.
*/
static const unsigned long vaddr_start = __PAGE_OFFSET_BASE;
-static const unsigned long vaddr_end = VMEMMAP_START;
+
+#if defined(CONFIG_X86_ESPFIX64)
+static const unsigned long vaddr_end = ESPFIX_BASE_ADDR;
+#elif defined(CONFIG_EFI)
+static const unsigned long vaddr_end = EFI_VA_START;
+#else
+static const unsigned long vaddr_end = __START_KERNEL_map;
+#endif
/* Default values */
unsigned long page_offset_base = __PAGE_OFFSET_BASE;
EXPORT_SYMBOL(page_offset_base);
unsigned long vmalloc_base = __VMALLOC_BASE;
EXPORT_SYMBOL(vmalloc_base);
+unsigned long vmemmap_base = __VMEMMAP_BASE;
+EXPORT_SYMBOL(vmemmap_base);
/*
* Memory regions randomized by KASLR (except modules that use a separate logic
@@ -63,6 +72,7 @@ static __initdata struct kaslr_memory_region {
} kaslr_regions[] = {
{ &page_offset_base, 64/* Maximum */ },
{ &vmalloc_base, VMALLOC_SIZE_TB },
+ { &vmemmap_base, 1 },
};
/* Get size in bytes used by the memory region */
@@ -89,6 +99,18 @@ void __init kernel_randomize_memory(void)
struct rnd_state rand_state;
unsigned long remain_entropy;
+ /*
+* All these BUILD_BUG_ON checks ensures the memory layout is
+* consistent with the vaddr_start/vaddr_end variables.
+*/
+ BUILD_BUG_ON(vaddr_start >= vaddr_end);
+ BUILD_BUG_ON(config_enabled(CONFIG_X86_ESPFIX64) &&
+vaddr_end >= EFI_VA_START);
+ BUILD_BUG_ON((config_enabled(CONFIG_X86_ESPFIX64) ||
+ config_enabled(CONFIG_EFI)) &&
+vaddr_end >= __START_KERNEL_map);
+ BUILD_BUG_ON(vaddr_end > __START_KERNEL_map);
+
if (!kaslr_memory_enabled())
return;
Re: [PACTH v1] mm, proc: Implement /proc//totmaps
On Wed, Aug 10, 2016 at 10:23:53AM -0700, Sonny Rao wrote:
> On Tue, Aug 9, 2016 at 2:01 PM, Robert Foss wrote:
> >
> >
> > On 2016-08-09 03:24 PM, Jann Horn wrote:
> >>
> >> On Tue, Aug 09, 2016 at 12:05:43PM -0400, robert.f...@collabora.com wrote:
> >>>
> >>> From: Sonny Rao
> >>>
> >>> This is based on earlier work by Thiago Goncales. It implements a new
> >>> per process proc file which summarizes the contents of the smaps file
> >>> but doesn't display any addresses. It gives more detailed information
> >>> than statm like the PSS (proprotional set size). It differs from the
> >>> original implementation in that it doesn't use the full blown set of
> >>> seq operations, uses a different termination condition, and doesn't
> >>> displayed "Locked" as that was broken on the original implemenation.
> >>>
> >>> This new proc file provides information faster than parsing the
> >>> potentially
> >>> huge smaps file.
> >>>
> >>> Signed-off-by: Sonny Rao
> >>>
> >>> Tested-by: Robert Foss
> >>> Signed-off-by: Robert Foss
> >>
> >>
> >>
> >>> +static int totmaps_proc_show(struct seq_file *m, void *data)
> >>> +{
> >>> + struct proc_maps_private *priv = m->private;
> >>> + struct mm_struct *mm;
> >>> + struct vm_area_struct *vma;
> >>> + struct mem_size_stats *mss_sum = priv->mss;
> >>> +
> >>> + /* reference to priv->task already taken */
> >>> + /* but need to get the mm here because */
> >>> + /* task could be in the process of exiting */
> >>
> >>
> >> Can you please elaborate on this? My understanding here is that you
> >> intend for the caller to be able to repeatedly read the same totmaps
> >> file with pread() and still see updated information after the target
> >> process has called execve() and be able to detect process death
> >> (instead of simply seeing stale values). Is that accurate?
> >>
> >> I would prefer it if you could grab a reference to the mm_struct
> >> directly at open time.
> >
> >
> > Sonny, do you know more about the above comment?
>
> I think right now the file gets re-opened every time, but the mode
> where the file is opened once and repeatedly read is interesting
> because it avoids having to open the file again and again.
>
> I guess you could end up with a wierd situation where you don't read
> the entire contents of the file in open call to read() and you might
> get inconsistent data across the different statistics?
If the file is read in two chunks, totmaps_proc_show is only called
once. The patch specifies seq_read as read handler. Have a look at its
definition. As long as you don't read from the same seq file in
parallel or seek around in it, simple sequential reads will not
re-invoke the show() method for data that has already been formatted.
For partially consumed data, the kernel buffers the rest until someone
reads it or seeks to another offset.
signature.asc
Description: Digital signature
RE: [PATCH V1] mfd: da9053: ensure the FAULT_LOG is cleared during MFD driver probe
On 08 August 2016 12:06, Steve Twiss wrote:
> On 05 August 2016 10:05, Lee Jones wrote:
> > On Wed, 06 Jul 2016, Steve Twiss wrote:
> > > From: Steve Twiss
> > >
> > > Clearance of any the persistent information within the DA9053 FAULT_LOG
> > > register must be completed during start-up so the fault-log does not
> > > continue with previous values. A clearance function has been added here in
> > > the kernel driver because wiping the fault-log cannot be counted on
> > > outside
> > > the Linux kernel.
>
> [...]
>
> > > This patch is similar to the requirements for DA9062 and DA9063: to ensure
> > > the FAULT_LOG is started from a 'clean' position.
> > >
> > > The Dialog datasheet for DA9053 suggests: "The FAULT_LOG register has to
> > > be cleared from the host after reading, by writing a value of ".
> > >
> > > See reference:
> > > commit 9011e4a8a6fe57f76511609930ed00d305389089
> > > Author: Steve Twiss
> > > Date: Tue May 19 11:32:45 2015 +0100
> >
> > Looks like much of the same code. Can you have a pop at generifying
> > this to avoid any unnecessary duplication?
>
> Hi Lee,
>
> Although the function looks like those found in both the DA9062 and DA9063
> drivers, I was just
> intending to highlight the "requirement similarities" to clear the fault
> register on start-up. This
> requirement for the Dialog PMIC chips extends across those devices, but the
> function is not
> really general enough to be merged into the kernel core or reused across
> other Dialog devices.
>
> I don't think there is unnecessary duplication in this particular case for
> the DA9052/53 driver.
>
> This da9052_clear_fault_log() function will apply to both the Dialog DA9052
> and DA9053 PMICs
> and so I am making good use of code re-use in this place. But, this does not
> extend to the
> DA9062 or DA9063.
>
> I don't think this FAULT_LOG clearance function in this case is really open
> to generalisation past
> the DA9052/53 driver.
Hi Lee,
There is another point I missed out for this.
The fault log function is individual for each chip and would be customisable to
meet the needs
of the customer's target platform.
The function is meant to be individual. This allows for multiple chips in the
same platform -- each
fault log function could be cleared slightly differently in that case.
To start with, I just added the fault log function in my last patch and
highlighted its similarity
to DA9062 and DA9063 so that previous commits of the same type could be used to
back-up my
request to add this new one to the DA9052/53 driver. I did not intended to
cause confusion or
and it was not intended to suggest a possible point to generalise functionality
across a range
of Dialog PMICs.
Regards,
Steve
> > > drivers/mfd/da9052-core.c | 51
> > +++
> > > 1 file changed, 51 insertions(+)
> > >
> > > diff --git a/drivers/mfd/da9052-core.c b/drivers/mfd/da9052-core.c
> > > index c0bf68a..a88c206 100644
> > > --- a/drivers/mfd/da9052-core.c
> > > +++ b/drivers/mfd/da9052-core.c
> > > @@ -167,6 +167,7 @@ static bool da9052_reg_writeable(struct device *dev,
> > > unsigned int reg)
> > > case DA9052_EVENT_B_REG:
> > > case DA9052_EVENT_C_REG:
> > > case DA9052_EVENT_D_REG:
> > > + case DA9052_FAULTLOG_REG:
> > > case DA9052_IRQ_MASK_A_REG:
> > > case DA9052_IRQ_MASK_B_REG:
> > > case DA9052_IRQ_MASK_C_REG:
> > > @@ -541,6 +542,52 @@ const struct regmap_config da9052_regmap_config = {
> > > };
> > > EXPORT_SYMBOL_GPL(da9052_regmap_config);
> > >
> > > +static int da9052_clear_fault_log(struct da9052 *da9052)
> > > +{
> > > + int ret = 0;
> > > + int fault_log = 0;
> > > +
> > > + fault_log = da9052_reg_read(da9052, DA9052_FAULTLOG_REG);
> > > + if (fault_log < 0) {
> > > + dev_err(da9052->dev,
> > > + "Cannot read FAULT_LOG %d\n", fault_log);
> > > + return fault_log;
> > > + }
> > > +
> > > + if (fault_log) {
> > > + if (fault_log & DA9052_FAULTLOG_TWDERROR)
> > > + dev_dbg(da9052->dev,
> > > + "Fault log entry detected: TWD_ERROR\n");
> > > + if (fault_log & DA9052_FAULTLOG_VDDFAULT)
> > > + dev_dbg(da9052->dev,
> > > + "Fault log entry detected: VDD_FAULT\n");
> > > + if (fault_log & DA9052_FAULTLOG_VDDSTART)
> > > + dev_dbg(da9052->dev,
> > > + "Fault log entry detected: VDD_START\n");
> > > + if (fault_log & DA9052_FAULTLOG_TEMPOVER)
> > > + dev_dbg(da9052->dev,
> > > + "Fault log entry detected: TEMP_OVER\n");
> > > + if (fault_log & DA9052_FAULTLOG_KEYSHUT)
> > > + dev_dbg(da9052->dev,
> > > + "Fault log entry detected: KEY_SHUT\n");
> > > + if (fault_log & DA9052_FAULTLOG_NSDSET)
> > > + dev_dbg(da9052->dev,
> > > + "Fault log
Re: [PATCH] Map in physical addresses in efi_map_region_fixed
On Fri, Aug 05, 2016 at 06:59:35PM -0500, Alex Thorlton wrote:
> This is a simple change to add in the physical mappings as well as the
> virtual mappings in efi_map_region_fixed. The motivation here is to
> get access to EFI runtime code that is only available via the 1:1
> mappings on a kexec'd kernel.
>
> The added call is essentially the kexec analog of the first __map_region
> that Boris put in efi_map_region in commit d2f7cbe7b26a ("x86/efi:
> Runtime services virtual mapping").
Just wanted to ping and see if anybody has had a chance to look at this?
Also, linux-kernel looks broken today (latest e-mails on lkml look to be
from last night?) so I wanted to send something to see if it goes
through :)
- Alex
[PATCH 8/8] hisi_sas: update version to 1.6
Signed-off-by: John Garry --- drivers/scsi/hisi_sas/hisi_sas.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/hisi_sas/hisi_sas.h b/drivers/scsi/hisi_sas/hisi_sas.h index 4ae864d..fc51e87 100644 --- a/drivers/scsi/hisi_sas/hisi_sas.h +++ b/drivers/scsi/hisi_sas/hisi_sas.h @@ -23,7 +23,7 @@ #include #include -#define DRV_VERSION "v1.5" +#define DRV_VERSION "v1.6" #define HISI_SAS_MAX_PHYS 9 #define HISI_SAS_MAX_QUEUES32 -- 1.9.1
Re: [PATCH] usb: core: Add runtime resume checking
On Wed, Aug 10, 2016 at 02:43:50PM +0800, Baolin Wang wrote: > Hi Peter, > > On 10 August 2016 at 14:18, Peter Chen wrote: > > On Wed, Aug 10, 2016 at 10:33:31AM +0800, Baolin Wang wrote: > >> Hi Greg, > >> > >> On 9 August 2016 at 18:26, Greg KH wrote: > >> > On Tue, Aug 09, 2016 at 05:33:33PM +0800, Baolin Wang wrote: > >> >> When the usb device has entered suspend state by runtime suspend > >> >> method, and > >> >> the sustem also try to enter suspend state by issuing > >> >> usb_dev_suspend(), it > >> >> will issue pm_runtime_resume() function to deal with wrong wakeup > >> >> setting in > >> >> choose_wakeup() function. > >> >> > >> >> But if usb device resumes failed due to xhci has been into suspend > >> >> state and > >> >> hardware is not accessible, which will set runtime errors. Thus when > >> >> there is > >> >> slave attached, usb device will resume failed by runtime resume method > >> >> due to > >> >> previous runtime errors. > >> > > >> > I really can't parse the first sentance in this paragraph, what exactly > >> > makes xhci so "unique" here? > >> > >> Sorry for confusing, I try to explain it clearly. Considering strict > >> power management for mobile device, we should also power off the usb > >> controller if there are no slaves attached even though it is usb host > >> function. > >> > >> For example: No slave attached> usb interface runtime suspend > >> > usb device runtime suspend -> xhci suspend -> power off > >> usb controller. After that if the system wants to enter suspend state, > >> then it also will issue usb_dev_suspend(), then the > >> pm_runtime_resume() function (issued in choose_wakeup() function) will > >> return -ESHUTDOWN due to xhci has been suspend and hardware is not > >> accessible. > > > > Why the controller does not be resumed when the root hub has issued > > runtime resume? > > Because now there is no slave attached, we will not power on usb > controller and resume xhci. > I don't know why you set policy like this. Even the controller is resumed, it will still be suspended by system suspend. What's more, if you disallow it, how can you change your wakeup setting? Eg, at runtime suspend, we enable wakeup by default. But for system sleep, we disable wakeup by default. At runtime, if there is no device on the port, even we resumes the controller and roohub, it still will be suspended soon. -- Best Regards, Peter Chen
[PATCH 6/8] hisi_sas: fail tmf task prep when port detached
When the port is detached we cannot execute a TMF,
as there can be no device attached to the port.
Signed-off-by: John Garry
---
drivers/scsi/hisi_sas/hisi_sas_main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/hisi_sas/hisi_sas_main.c
b/drivers/scsi/hisi_sas/hisi_sas_main.c
index 6c82e07..af92b137 100644
--- a/drivers/scsi/hisi_sas/hisi_sas_main.c
+++ b/drivers/scsi/hisi_sas/hisi_sas_main.c
@@ -204,7 +204,7 @@ static int hisi_sas_task_prep(struct sas_task *task, struct
hisi_hba *hisi_hba,
return rc;
}
port = device->port->lldd_port;
- if (port && !port->port_attached && !tmf) {
+ if (port && !port->port_attached) {
if (sas_protocol_ata(task->task_proto)) {
struct task_status_struct *ts = &task->task_status;
--
1.9.1
[tip:timers/urgent] x86/hpet: Fix /dev/rtc breakage caused by RTC cleanup
Commit-ID: 22cc1ca3c5469cf17e149be232817b9223afa5e4
Gitweb: http://git.kernel.org/tip/22cc1ca3c5469cf17e149be232817b9223afa5e4
Author: Arnd Bergmann
AuthorDate: Tue, 9 Aug 2016 21:54:53 +0200
Committer: Ingo Molnar
CommitDate: Wed, 10 Aug 2016 14:37:06 +0200
x86/hpet: Fix /dev/rtc breakage caused by RTC cleanup
Ville Syrjälä reports "The first time I run hwclock after rebooting
I get this:
open("/dev/rtc", O_RDONLY) = 3
ioctl(3, PHN_SET_REGS or RTC_UIE_ON, 0) = 0
select(4, [3], NULL, NULL, {10, 0}) = 0 (Timeout)
ioctl(3, PHN_NOT_OH or RTC_UIE_OFF, 0) = 0
close(3)= 0
On all subsequent runs I get this:
open("/dev/rtc", O_RDONLY) = 3
ioctl(3, PHN_SET_REGS or RTC_UIE_ON, 0) = -1 EINVAL (Invalid argument)
ioctl(3, RTC_RD_TIME, 0x7ffd76b3ae70) = -1 EINVAL (Invalid argument)
close(3)= 0"
This was caused by a stupid typo in a patch that should have been
a simple rename to move around contents of a header file, but
accidentally wrote zeroes into the rtc rather than reading from
it:
463a86304cae ("char/genrtc: x86: remove remnants of asm/rtc.h")
Reported-by: Ville Syrjälä
Tested-by: Jarkko Nikula
Tested-by: Ville Syrjälä
Signed-off-by: Arnd Bergmann
Cc: Alessandro Zummo
Cc: Alexandre Belloni
Cc: Borislav Petkov
Cc: Geert Uytterhoeven
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Thomas Gleixner
Cc: rtc-li...@googlegroups.com
Fixes: 463a86304cae ("char/genrtc: x86: remove remnants of asm/rtc.h")
Link: http://lkml.kernel.org/r/20160809195528.1604312-1-a...@arndb.de
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/hpet.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kernel/hpet.c b/arch/x86/kernel/hpet.c
index ed16e58..c6dfd80 100644
--- a/arch/x86/kernel/hpet.c
+++ b/arch/x86/kernel/hpet.c
@@ -1242,7 +1242,7 @@ irqreturn_t hpet_rtc_interrupt(int irq, void *dev_id)
memset(&curr_time, 0, sizeof(struct rtc_time));
if (hpet_rtc_flags & (RTC_UIE | RTC_AIE))
- mc146818_set_time(&curr_time);
+ mc146818_get_time(&curr_time);
if (hpet_rtc_flags & RTC_UIE &&
curr_time.tm_sec != hpet_prev_update_sec) {
Re: [PATCH] cgroup: add tracepoints for basic operations
On Tue, Aug 09, 2016 at 01:27:03AM -0400, Tejun Heo wrote: > From 471f89b317a21a78dacaee85957984b9f11e79e4 Mon Sep 17 00:00:00 2001 > From: Tejun Heo > Date: Tue, 9 Aug 2016 01:11:13 -0400 > > Debugging what goes wrong with cgroup setup can get hairy. Add > tracepoints for cgroup hierarchy mount, cgroup creation/destruction > and task migration operations for better visibility. > > Signed-off-by: Tejun Heo Applied to cgroup/for-4.9. Thanks. -- tejun
[PATCH 5/5] mm/page_owner: don't define fields on struct page_ext by hard-coding
From: Joonsoo Kim
There is a memory waste problem if we define field on struct page_ext
by hard-coding. Entry size of struct page_ext includes the size of
those fields even if it is disabled at runtime. Now, extra memory request
at runtime is possible so page_owner don't need to define it's own fields
by hard-coding.
This patch removes hard-coded define and uses extra memory for storing
page_owner information in page_owner. Most of code are just mechanical
changes.
Signed-off-by: Joonsoo Kim
---
include/linux/page_ext.h | 6
mm/page_owner.c | 83 +---
2 files changed, 58 insertions(+), 31 deletions(-)
diff --git a/include/linux/page_ext.h b/include/linux/page_ext.h
index 179bdc4..9298c39 100644
--- a/include/linux/page_ext.h
+++ b/include/linux/page_ext.h
@@ -44,12 +44,6 @@ enum page_ext_flags {
*/
struct page_ext {
unsigned long flags;
-#ifdef CONFIG_PAGE_OWNER
- unsigned int order;
- gfp_t gfp_mask;
- int last_migrate_reason;
- depot_stack_handle_t handle;
-#endif
};
extern void pgdat_page_ext_init(struct pglist_data *pgdat);
diff --git a/mm/page_owner.c b/mm/page_owner.c
index 14c8e65..59d7490 100644
--- a/mm/page_owner.c
+++ b/mm/page_owner.c
@@ -17,6 +17,13 @@
*/
#define PAGE_OWNER_STACK_DEPTH (16)
+struct page_owner {
+ unsigned int order;
+ gfp_t gfp_mask;
+ int last_migrate_reason;
+ depot_stack_handle_t handle;
+};
+
static bool page_owner_disabled = true;
DEFINE_STATIC_KEY_FALSE(page_owner_inited);
@@ -85,10 +92,16 @@ static void init_page_owner(void)
}
struct page_ext_operations page_owner_ops = {
+ .size = sizeof(struct page_owner),
.need = need_page_owner,
.init = init_page_owner,
};
+static inline struct page_owner *get_page_owner(struct page_ext *page_ext)
+{
+ return (void *)page_ext + page_owner_ops.offset;
+}
+
void __reset_page_owner(struct page *page, unsigned int order)
{
int i;
@@ -155,14 +168,16 @@ noinline void __set_page_owner(struct page *page,
unsigned int order,
gfp_t gfp_mask)
{
struct page_ext *page_ext = lookup_page_ext(page);
+ struct page_owner *page_owner;
if (unlikely(!page_ext))
return;
- page_ext->handle = save_stack(gfp_mask);
- page_ext->order = order;
- page_ext->gfp_mask = gfp_mask;
- page_ext->last_migrate_reason = -1;
+ page_owner = get_page_owner(page_ext);
+ page_owner->handle = save_stack(gfp_mask);
+ page_owner->order = order;
+ page_owner->gfp_mask = gfp_mask;
+ page_owner->last_migrate_reason = -1;
__set_bit(PAGE_EXT_OWNER, &page_ext->flags);
}
@@ -170,21 +185,26 @@ noinline void __set_page_owner(struct page *page,
unsigned int order,
void __set_page_owner_migrate_reason(struct page *page, int reason)
{
struct page_ext *page_ext = lookup_page_ext(page);
+ struct page_owner *page_owner;
+
if (unlikely(!page_ext))
return;
- page_ext->last_migrate_reason = reason;
+ page_owner = get_page_owner(page_ext);
+ page_owner->last_migrate_reason = reason;
}
void __split_page_owner(struct page *page, unsigned int order)
{
int i;
struct page_ext *page_ext = lookup_page_ext(page);
+ struct page_owner *page_owner;
if (unlikely(!page_ext))
return;
- page_ext->order = 0;
+ page_owner = get_page_owner(page_ext);
+ page_owner->order = 0;
for (i = 1; i < (1 << order); i++)
__copy_page_owner(page, page + i);
}
@@ -193,14 +213,18 @@ void __copy_page_owner(struct page *oldpage, struct page
*newpage)
{
struct page_ext *old_ext = lookup_page_ext(oldpage);
struct page_ext *new_ext = lookup_page_ext(newpage);
+ struct page_owner *old_page_owner, *new_page_owner;
if (unlikely(!old_ext || !new_ext))
return;
- new_ext->order = old_ext->order;
- new_ext->gfp_mask = old_ext->gfp_mask;
- new_ext->last_migrate_reason = old_ext->last_migrate_reason;
- new_ext->handle = old_ext->handle;
+ old_page_owner = get_page_owner(old_ext);
+ new_page_owner = get_page_owner(new_ext);
+ new_page_owner->order = old_page_owner->order;
+ new_page_owner->gfp_mask = old_page_owner->gfp_mask;
+ new_page_owner->last_migrate_reason =
+ old_page_owner->last_migrate_reason;
+ new_page_owner->handle = old_page_owner->handle;
/*
* We don't clear the bit on the oldpage as it's going to be freed
@@ -219,6 +243,7 @@ void pagetypeinfo_showmixedcount_print(struct seq_file *m,
pg_data_t *pgdat,
{
struct page *page;
struct page_ext *page_ext;
+ struct page_owner *page_owner;
unsigned long pfn = zone->zone_start_pfn, block_end_pfn;
unsigned long end_pfn = pfn +
[PATCH] get_maintainer: Don't check if STDIN exists in a VCS repository
If get_maintainer is not given any filename arguments on the command line,
the standard input is read for a patch.
But checking if a VCS has a file named &STDIN is not a good idea and fails.
Verify the nominal input file is not &STDIN before checking the VCS.
Fixes: 4cad35a7ca69 ("get_maintainer.pl: reduce need for command-line option
-f")
Reported-by: Christopher Covington
Signed-off-by: Joe Perches
---
scripts/get_maintainer.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/get_maintainer.pl b/scripts/get_maintainer.pl
index 122fcda..49a00d5 100755
--- a/scripts/get_maintainer.pl
+++ b/scripts/get_maintainer.pl
@@ -432,7 +432,7 @@ foreach my $file (@ARGV) {
die "$P: file '${file}' not found\n";
}
}
-if ($from_filename || vcs_file_exists($file)) {
+if ($from_filename || ($file ne "&STDIN" && vcs_file_exists($file))) {
$file =~ s/^\Q${cur_path}\E//; #strip any absolute path
$file =~ s/^\Q${lk_path}\E//; #or the path to the lk tree
push(@files, $file);
--
2.8.0.rc4.16.g56331f8
[PATCH] nios2: use of_property_read_bool
Use of_property_read_bool instead of open-coding it as fpcu_has. Convert
the members of struct cpuinfo from u32 to bool accordingly as they are
only used as boolean anyhow.
Signed-off-by: Tobias Klauser
---
arch/nios2/include/asm/cpuinfo.h | 8
arch/nios2/kernel/cpuinfo.c | 15 +--
2 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/arch/nios2/include/asm/cpuinfo.h b/arch/nios2/include/asm/cpuinfo.h
index e88fcae464d9..348bb228fec9 100644
--- a/arch/nios2/include/asm/cpuinfo.h
+++ b/arch/nios2/include/asm/cpuinfo.h
@@ -25,10 +25,10 @@ struct cpuinfo {
/* Core CPU configuration */
char cpu_impl[12];
u32 cpu_clock_freq;
- u32 mmu;
- u32 has_div;
- u32 has_mul;
- u32 has_mulx;
+ bool mmu;
+ bool has_div;
+ bool has_mul;
+ bool has_mulx;
/* CPU caches */
u32 icache_line_size;
diff --git a/arch/nios2/kernel/cpuinfo.c b/arch/nios2/kernel/cpuinfo.c
index 1d96de0bd4aa..136877bc 100644
--- a/arch/nios2/kernel/cpuinfo.c
+++ b/arch/nios2/kernel/cpuinfo.c
@@ -41,11 +41,6 @@ static inline u32 fcpu(struct device_node *cpu, const char
*n)
return val;
}
-static inline u32 fcpu_has(struct device_node *cpu, const char *n)
-{
- return of_get_property(cpu, n, NULL) ? 1 : 0;
-}
-
void __init setup_cpuinfo(void)
{
struct device_node *cpu;
@@ -56,7 +51,7 @@ void __init setup_cpuinfo(void)
if (!cpu)
panic("%s: No CPU found in devicetree!\n", __func__);
- if (!fcpu_has(cpu, "altr,has-initda"))
+ if (!of_property_read_bool(cpu, "altr,has-initda"))
panic("initda instruction is unimplemented. Please update your "
"hardware system to have more than 4-byte line data "
"cache\n");
@@ -69,10 +64,10 @@ void __init setup_cpuinfo(void)
else
strcpy(cpuinfo.cpu_impl, "");
- cpuinfo.has_div = fcpu_has(cpu, "altr,has-div");
- cpuinfo.has_mul = fcpu_has(cpu, "altr,has-mul");
- cpuinfo.has_mulx = fcpu_has(cpu, "altr,has-mulx");
- cpuinfo.mmu = fcpu_has(cpu, "altr,has-mmu");
+ cpuinfo.has_div = of_property_read_bool(cpu, "altr,has-div");
+ cpuinfo.has_mul = of_property_read_bool(cpu, "altr,has-mul");
+ cpuinfo.has_mulx = of_property_read_bool(cpu, "altr,has-mulx");
+ cpuinfo.mmu = of_property_read_bool(cpu, "altr,has-mmu");
if (IS_ENABLED(CONFIG_NIOS2_HW_DIV_SUPPORT) && !cpuinfo.has_div)
err_cpu("DIV");
--
2.9.0
[tip:x86/mm] x86/mm/KASLR: Increase BRK pages for KASLR memory randomization
Commit-ID: fb754f958f8e46202c1efd7f66d5b3db1208117d
Gitweb: http://git.kernel.org/tip/fb754f958f8e46202c1efd7f66d5b3db1208117d
Author: Thomas Garnier
AuthorDate: Tue, 9 Aug 2016 10:11:05 -0700
Committer: Ingo Molnar
CommitDate: Wed, 10 Aug 2016 14:45:19 +0200
x86/mm/KASLR: Increase BRK pages for KASLR memory randomization
Default implementation expects 6 pages maximum are needed for low page
allocations. If KASLR memory randomization is enabled, the worse case
of e820 layout would require 12 pages (no large pages). It is due to the
PUD level randomization and the variable e820 memory layout.
This bug was found while doing extensive testing of KASLR memory
randomization on different type of hardware.
Signed-off-by: Thomas Garnier
Cc: Aleksey Makarov
Cc: Andrew Morton
Cc: Andy Lutomirski
Cc: Baoquan He
Cc: Borislav Petkov
Cc: Borislav Petkov
Cc: Brian Gerst
Cc: Christian Borntraeger
Cc: Dan Williams
Cc: Dave Hansen
Cc: Dave Young
Cc: Denys Vlasenko
Cc: Fabian Frederick
Cc: H. Peter Anvin
Cc: Joerg Roedel
Cc: Josh Poimboeuf
Cc: Kees Cook
Cc: Linus Torvalds
Cc: Lv Zheng
Cc: Mark Salter
Cc: Peter Zijlstra
Cc: Rafael J . Wysocki
Cc: Thomas Gleixner
Cc: Toshi Kani
Cc: kernel-harden...@lists.openwall.com
Fixes: 021182e52fe0 ("Enable KASLR for physical mapping memory regions")
Link:
http://lkml.kernel.org/r/1470762665-88032-2-git-send-email-thgar...@google.com
Signed-off-by: Ingo Molnar
---
arch/x86/mm/init.c | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 6209289..d28a2d7 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -122,8 +122,18 @@ __ref void *alloc_low_pages(unsigned int num)
return __va(pfn << PAGE_SHIFT);
}
-/* need 3 4k for initial PMD_SIZE, 3 4k for 0-ISA_END_ADDRESS */
-#define INIT_PGT_BUF_SIZE (6 * PAGE_SIZE)
+/*
+ * By default need 3 4k for initial PMD_SIZE, 3 4k for 0-ISA_END_ADDRESS.
+ * With KASLR memory randomization, depending on the machine e820 memory
+ * and the PUD alignment. We may need twice more pages when KASLR memory
+ * randomization is enabled.
+ */
+#ifndef CONFIG_RANDOMIZE_MEMORY
+#define INIT_PGD_PAGE_COUNT 6
+#else
+#define INIT_PGD_PAGE_COUNT 12
+#endif
+#define INIT_PGT_BUF_SIZE (INIT_PGD_PAGE_COUNT * PAGE_SIZE)
RESERVE_BRK(early_pgt_alloc, INIT_PGT_BUF_SIZE);
void __init early_alloc_pgt_buf(void)
{
[tip:x86/urgent] x86/platform/UV: Fix kernel panic running RHEL kdump kernel on UV systems
Commit-ID: 5a52e8f822374bebc702bb2688ed8b5515bbb55b
Gitweb: http://git.kernel.org/tip/5a52e8f822374bebc702bb2688ed8b5515bbb55b
Author: Mike Travis
AuthorDate: Mon, 1 Aug 2016 13:40:53 -0500
Committer: Ingo Molnar
CommitDate: Wed, 10 Aug 2016 15:55:39 +0200
x86/platform/UV: Fix kernel panic running RHEL kdump kernel on UV systems
The latest UV kernel support panics when RHEL7 kexec's the kdump kernel
to make a dumpfile. This patch fixes the problem by turning off all UV
support if NUMA is off.
Tested-by: Frank Ramsay
Tested-by: John Estabrook
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Nathan Zimmer
Cc: Alex Thorlton
Cc: Andrew Banman
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Russ Anderson
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/20160801184050.577755...@asylum.americas.sgi.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/apic/x2apic_uv_x.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 6aa0545..cb0673c 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -223,6 +223,11 @@ static int __init uv_acpi_madt_oem_check(char *oem_id,
char *oem_table_id)
if (strncmp(oem_id, "SGI", 3) != 0)
return 0;
+ if (numa_off) {
+ pr_err("UV: NUMA is off, disabling UV support\n");
+ return 0;
+ }
+
/* Setup early hub type field in uv_hub_info for Node 0 */
uv_cpu_info->p_uv_hub_info = &uv_hub_info_node0;
[PATCH 0/8] hisi_sas internal abort support
This patchset introduces support for the internal abort feature for the HiSilicon SAS controller. The internal abort feature allows commands which are active in the controller to be aborted before being sent to the slave device. Only support will be added for v2 HW since v1 HW has issues in supporting internal abort feature. John Garry (8): hisi_sas: add internal abort core code hisi_sas: for internal abort in hisi_sas_dev_gone() hisi_sas: add internal abort to hisi_sas_abort_task() hisi_sas: add prep_abort_v2_hw() hisi_sas: add v2 hw slot complete internal abort support hisi_sas: fail tmf task prep when port detached hisi_sas: add TMF success check hisi_sas: update version to 1.6 drivers/scsi/hisi_sas/hisi_sas.h | 5 +- drivers/scsi/hisi_sas/hisi_sas_main.c | 179 +++-- drivers/scsi/hisi_sas/hisi_sas_v2_hw.c | 64 3 files changed, 241 insertions(+), 7 deletions(-) -- 1.9.1
[PATCH v3 2/2] powerpc/fadump: parse fadump reserve memory size based on memory range
When fadump is enabled, by default 5% of system RAM is reserved for
fadump kernel. While that works for most cases, it is not good enough
for every case.
Currently, to override the default value, fadump supports specifying
memory to reserve with fadump_reserve_mem=size, where only a fixed size
can be specified. This patch adds support to specify memory size to
reserve for different memory ranges as below:
fadump_reserve_mem=:[,:,...]
Supporting range based input for "fadump_reserve_mem" parameter helps
using the same commandline parameter for different system memory sizes.
Signed-off-by: Hari Bathini
Reviewed-by: Mahesh J Salgaonkar
---
Changes from v2:
1. Updated changelog
arch/powerpc/kernel/fadump.c | 63 --
1 file changed, 54 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/kernel/fadump.c b/arch/powerpc/kernel/fadump.c
index b3a6633..7c01b5b 100644
--- a/arch/powerpc/kernel/fadump.c
+++ b/arch/powerpc/kernel/fadump.c
@@ -193,6 +193,55 @@ static unsigned long init_fadump_mem_struct(struct
fadump_mem_struct *fdm,
return addr;
}
+/*
+ * This function parses command line for fadump_reserve_mem=
+ *
+ * Supports the below two syntaxes:
+ *1. fadump_reserve_mem=size
+ *2. fadump_reserve_mem=ramsize-range:size[,...]
+ *
+ * Sets fw_dump.reserve_bootvar with the memory size
+ * provided, 0 otherwise
+ *
+ * The function returns -EINVAL on failure, 0 otherwise.
+ */
+static int __init parse_fadump_reserve_mem(void)
+{
+ char *name = "fadump_reserve_mem=";
+ char *fadump_cmdline = NULL, *cur;
+
+ fw_dump.reserve_bootvar = 0;
+
+ /* find fadump_reserve_mem and use the last one if there are many */
+ cur = strstr(boot_command_line, name);
+ while (cur) {
+ fadump_cmdline = cur;
+ cur = strstr(cur+1, name);
+ }
+
+ /* when no fadump_reserve_mem= cmdline option is provided */
+ if (!fadump_cmdline)
+ return 0;
+
+ fadump_cmdline += strlen(name);
+
+ /* for fadump_reserve_mem=size cmdline syntax */
+ if (!is_colon_in_param(fadump_cmdline)) {
+ fw_dump.reserve_bootvar = memparse(fadump_cmdline, NULL);
+ return 0;
+ }
+
+ /* for fadump_reserve_mem=ramsize-range:size[,...] cmdline syntax */
+ cur = fadump_cmdline;
+ fw_dump.reserve_bootvar = parse_mem_range_size("fadump_reserve_mem",
+ &cur, memblock_phys_mem_size());
+ if (cur == fadump_cmdline) {
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
/**
* fadump_calculate_reserve_size(): reserve variable boot area 5% of System RAM
*
@@ -212,12 +261,17 @@ static inline unsigned long
fadump_calculate_reserve_size(void)
{
unsigned long size;
+ /* sets fw_dump.reserve_bootvar */
+ parse_fadump_reserve_mem();
+
/*
* Check if the size is specified through fadump_reserve_mem= cmdline
* option. If yes, then use that.
*/
if (fw_dump.reserve_bootvar)
return fw_dump.reserve_bootvar;
+ else
+ printk(KERN_INFO "fadump: calculating default boot size\n");
/* divide by 20 to get 5% of value */
size = memblock_end_of_DRAM() / 20;
@@ -348,15 +402,6 @@ static int __init early_fadump_param(char *p)
}
early_param("fadump", early_fadump_param);
-/* Look for fadump_reserve_mem= cmdline option */
-static int __init early_fadump_reserve_mem(char *p)
-{
- if (p)
- fw_dump.reserve_bootvar = memparse(p, &p);
- return 0;
-}
-early_param("fadump_reserve_mem", early_fadump_reserve_mem);
-
static void register_fw_dump(struct fadump_mem_struct *fdm)
{
int rc;
[PATCH 5/6] crypto: sun4i-ss: Always use sun4i_tfm_ctx for storing pointer to dev ss
The dev *ss is stored both in sun4i_tfm_ctx and sun4i_req_ctx.
Since this pointer will never be changed during tfm life, it is better
to remove it from sun4i_req_ctx.
Signed-off-by: LABBE Corentin
---
drivers/crypto/sunxi-ss/sun4i-ss-hash.c | 13 +++--
drivers/crypto/sunxi-ss/sun4i-ss.h | 1 -
2 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
index 60031e0..2ee3b59 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
+++ b/drivers/crypto/sunxi-ss/sun4i-ss-hash.c
@@ -20,6 +20,15 @@
int sun4i_hash_crainit(struct crypto_tfm *tfm)
{
+ struct sun4i_tfm_ctx *op = crypto_tfm_ctx(tfm);
+ struct ahash_alg *alg = __crypto_ahash_alg(tfm->__crt_alg);
+ struct sun4i_ss_alg_template *algt;
+
+ memset(op, 0, sizeof(struct sun4i_tfm_ctx));
+
+ algt = container_of(alg, struct sun4i_ss_alg_template, alg.hash);
+ op->ss = algt->ss;
+
crypto_ahash_set_reqsize(__crypto_ahash_cast(tfm),
sizeof(struct sun4i_req_ctx));
return 0;
@@ -36,7 +45,6 @@ int sun4i_hash_init(struct ahash_request *areq)
memset(op, 0, sizeof(struct sun4i_req_ctx));
algt = container_of(alg, struct sun4i_ss_alg_template, alg.hash);
- op->ss = algt->ss;
op->mode = algt->mode;
return 0;
@@ -168,8 +176,9 @@ int sun4i_hash(struct ahash_request *areq)
*/
struct sun4i_req_ctx *op = ahash_request_ctx(areq);
- struct sun4i_ss_ctx *ss = op->ss;
struct crypto_ahash *tfm = crypto_ahash_reqtfm(areq);
+ struct sun4i_tfm_ctx *tfmctx = crypto_ahash_ctx(tfm);
+ struct sun4i_ss_ctx *ss = tfmctx->ss;
unsigned int in_i = 0; /* advancement in the current SG */
unsigned int end;
/*
diff --git a/drivers/crypto/sunxi-ss/sun4i-ss.h
b/drivers/crypto/sunxi-ss/sun4i-ss.h
index ece5a1c..f04c0f8 100644
--- a/drivers/crypto/sunxi-ss/sun4i-ss.h
+++ b/drivers/crypto/sunxi-ss/sun4i-ss.h
@@ -163,7 +163,6 @@ struct sun4i_req_ctx {
u32 hash[5]; /* for storing SS_IVx register */
char buf[64];
unsigned int len;
- struct sun4i_ss_ctx *ss;
int flags;
};
--
2.7.3
Re: [PATCH 3/9] remoteproc: core: Remove pointless OOM print
On Tue 09 Aug 11:10 PDT 2016, Lee Jones wrote: > On Tue, 09 Aug 2016, Bjorn Andersson wrote: > > > On Thu 04 Aug 02:21 PDT 2016, Lee Jones wrote: > > > > > These types of error prints are superfluous. The system will > > > pick up on OOM issues and let the user know. > > > > > > Signed-off-by: Lee Jones > > > > Acked-by: Bjorn Andersson > > This doesn't rely on anything else, so you can just take it. > Of course... Applied patch 1 through 3. Regards, Bjorn
[PATCH REBASED v10 5/6] drm/i915: Move CRTC updating in atomic_commit into it's own hook
Since we have to write ddb allocations at the same time as we do other
plane updates, we're going to need to be able to control the order in
which we execute modesets on each pipe. The easiest way to do this is to
just factor this section of intel_atomic_commit_tail()
(intel_atomic_commit() for stable branches) into it's own function, and
add an appropriate display function hook for it.
Based off of Matt Rope's suggestions
Changes since v1:
- Drop pipe_config->base.active check in intel_update_crtcs() since we
check that before calling the function
Signed-off-by: Lyude
Reviewed-by: Matt Roper
[omitting CC for stable, since this patch will need to be changed for
such backports first]
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Radhakrishna Sripada
Cc: Hans de Goede
Signed-off-by: Lyude
---
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/intel_display.c | 74 +---
2 files changed, 54 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fa3c9f9..f0b2ef8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -630,6 +630,8 @@ struct drm_i915_display_funcs {
struct intel_crtc_state *crtc_state);
void (*crtc_enable)(struct drm_crtc *crtc);
void (*crtc_disable)(struct drm_crtc *crtc);
+ void (*update_crtcs)(struct drm_atomic_state *state,
+unsigned int *crtc_vblank_mask);
void (*audio_codec_enable)(struct drm_connector *connector,
struct intel_encoder *encoder,
const struct drm_display_mode
*adjusted_mode);
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 429810b..9670ec0 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -13689,6 +13689,52 @@ static bool needs_vblank_wait(struct intel_crtc_state
*crtc_state)
return false;
}
+static void intel_update_crtc(struct drm_crtc *crtc,
+ struct drm_atomic_state *state,
+ struct drm_crtc_state *old_crtc_state,
+ unsigned int *crtc_vblank_mask)
+{
+ struct drm_device *dev = crtc->dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+ struct intel_crtc_state *pipe_config = to_intel_crtc_state(crtc->state);
+ bool modeset = needs_modeset(crtc->state);
+
+ if (modeset) {
+ update_scanline_offset(intel_crtc);
+ dev_priv->display.crtc_enable(crtc);
+ } else {
+ intel_pre_plane_update(to_intel_crtc_state(old_crtc_state));
+ }
+
+ if (drm_atomic_get_existing_plane_state(state, crtc->primary)) {
+ intel_fbc_enable(
+ intel_crtc, pipe_config,
+ to_intel_plane_state(crtc->primary->state));
+ }
+
+ drm_atomic_helper_commit_planes_on_crtc(old_crtc_state);
+
+ if (needs_vblank_wait(pipe_config))
+ *crtc_vblank_mask |= drm_crtc_mask(crtc);
+}
+
+static void intel_update_crtcs(struct drm_atomic_state *state,
+ unsigned int *crtc_vblank_mask)
+{
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *old_crtc_state;
+ int i;
+
+ for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
+ if (!crtc->state->active)
+ continue;
+
+ intel_update_crtc(crtc, state, old_crtc_state,
+ crtc_vblank_mask);
+ }
+}
+
static void intel_atomic_commit_tail(struct drm_atomic_state *state)
{
struct drm_device *dev = state->dev;
@@ -13788,17 +13834,9 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
intel_modeset_verify_disabled(dev);
}
- /* Now enable the clocks, plane, pipe, and connectors that we set up. */
+ /* Complete the events for pipes that have now been disabled */
for_each_crtc_in_state(state, crtc, old_crtc_state, i) {
- struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
bool modeset = needs_modeset(crtc->state);
- struct intel_crtc_state *pipe_config =
- to_intel_crtc_state(crtc->state);
-
- if (modeset && crtc->state->active) {
- update_scanline_offset(to_intel_crtc(crtc));
- dev_priv->display.crtc_enable(crtc);
- }
/* Complete events for now disable pipes here. */
if (modeset && !crtc->state->active && crtc->state->event) {
@@ -13808,21 +13846,11 @@ static void intel_atomic_commit_tail(struct
drm_atomic_state *state)
crtc->state->event = NULL;
[tip:smp/hotplug] cpu/hotplug: Prevent alloc/free of irq descriptors during CPU up/down (again)
Commit-ID: aa877175e7a9982233ed8f10cb4bfddd78d82741
Gitweb: http://git.kernel.org/tip/aa877175e7a9982233ed8f10cb4bfddd78d82741
Author: Boris Ostrovsky
AuthorDate: Wed, 3 Aug 2016 13:22:28 -0400
Committer: Ingo Molnar
CommitDate: Wed, 10 Aug 2016 15:42:57 +0200
cpu/hotplug: Prevent alloc/free of irq descriptors during CPU up/down (again)
Now that Xen no longer allocates irqs in _cpu_up() we can restore
commit:
a89941816726 ("hotplug: Prevent alloc/free of irq descriptors during cpu
up/down")
Signed-off-by: Boris Ostrovsky
Reviewed-by: Juergen Gross
Acked-by: Thomas Gleixner
Cc: Anna-Maria Gleixner
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Sebastian Andrzej Siewior
Cc: david.vra...@citrix.com
Cc: xen-de...@lists.xenproject.org
Link:
http://lkml.kernel.org/r/1470244948-17674-3-git-send-email-boris.ostrov...@oracle.com
Signed-off-by: Ingo Molnar
---
arch/x86/kernel/smpboot.c | 11 ---
kernel/cpu.c | 8
2 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 2a6e84a..067de61 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1108,17 +1108,8 @@ int native_cpu_up(unsigned int cpu, struct task_struct
*tidle)
common_cpu_up(cpu, tidle);
- /*
-* We have to walk the irq descriptors to setup the vector
-* space for the cpu which comes online. Prevent irq
-* alloc/free across the bringup.
-*/
- irq_lock_sparse();
-
err = do_boot_cpu(apicid, cpu, tidle);
-
if (err) {
- irq_unlock_sparse();
pr_err("do_boot_cpu failed(%d) to wakeup CPU#%u\n", err, cpu);
return -EIO;
}
@@ -1136,8 +1127,6 @@ int native_cpu_up(unsigned int cpu, struct task_struct
*tidle)
touch_nmi_watchdog();
}
- irq_unlock_sparse();
-
return 0;
}
diff --git a/kernel/cpu.c b/kernel/cpu.c
index 341bf80..ec12b72 100644
--- a/kernel/cpu.c
+++ b/kernel/cpu.c
@@ -349,8 +349,16 @@ static int bringup_cpu(unsigned int cpu)
struct task_struct *idle = idle_thread_get(cpu);
int ret;
+ /*
+* Some architectures have to walk the irq descriptors to
+* setup the vector space for the cpu which comes online.
+* Prevent irq alloc/free across the bringup.
+*/
+ irq_lock_sparse();
+
/* Arch-specific enabling code. */
ret = __cpu_up(cpu, idle);
+ irq_unlock_sparse();
if (ret) {
cpu_notify(CPU_UP_CANCELED, cpu);
return ret;
Re: [PATCH] scripts: add kasan_symbolize.py
On Wed, Aug 10, 2016 at 4:22 PM, Alexander Potapenko wrote:
> Commit the script that symbolizes BUG messages and KASAN error reports
> by adding file:line information to each stack frame.
> The script is a copy of
> https://github.com/google/sanitizers/blob/master/address-sanitizer/tools/kasan_symbolize.py
> , originally written by Andrey Konovalov.
>
> Cc: Andrey Ryabinin
> Cc: Dmitry Vyukov
> Signed-off-by: Alexander Potapenko
> ---
> MAINTAINERS| 1 +
> scripts/kasan_symbolize.py | 321
> +
> 2 files changed, 322 insertions(+)
> create mode 100755 scripts/kasan_symbolize.py
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 20bb1d0..d5622ed 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -6592,6 +6592,7 @@ F:include/linux/kasan*.h
> F: lib/test_kasan.c
> F: mm/kasan/
> F: scripts/Makefile.kasan
> +F: scripts/kasan_symbolize.py
>
> KCONFIG
> M: "Yann E. MORIN"
> diff --git a/scripts/kasan_symbolize.py b/scripts/kasan_symbolize.py
> new file mode 100755
> index 000..067a2d1
> --- /dev/null
> +++ b/scripts/kasan_symbolize.py
Dmitry told me that "kasan_symbolize" isn't a good name for a script
that can be used for generic BUG messages and reports from other
tools, e.g. KTSAN.
He proposed the name "ksymbolize.py", which sounds good to me.
If there won't be better suggestions, I'll rename the script when I
send v2 for review.
I wonder if I'll need to create a separate MAINTAINERS record for it
in that case.
> @@ -0,0 +1,321 @@
> +#!/usr/bin/python
> +
> +# Tool for symbolizing stack traces in BUG reports, mainly those produced
> +# by KASAN.
> +
> +from collections import defaultdict
> +import getopt
> +import os
> +import re
> +import sys
> +import subprocess
> +
> +# A hexadecimal number without the leading 0x.
> +HEXNUM = '[0-9A-Fa-f]+'
> +
> +# An address in the form [].
> +FRAME_ADDR = (
> +'(\[\<(?P' + HEXNUM + ')\>\])?\s*'
> +)
> +
> +# A function name with an offset and function size, plus an optional module
> +# name, e.g.:
> +# __asan_load8+0x64/0x66
> +FRAME_BODY = (
> +'(?P' +
> +'(?P[^\+]+)' +
> +'\+' +
> +'0x(?P' + HEXNUM + ')' +
> +'/' +
> +'0x(?P' + HEXNUM + ')' +
> +'( \[(?P.+)\])?' +
> +')')
> +
> +# Matches the timestamp prefix of a log line.
> +TIME_RE = re.compile(
> +'^(?P\[[ ]*[0-9\.]+\]) ?(?P.*)$'
> +)
> +
> +# Matches a single stacktrace frame.
> +FRAME_RE = re.compile(
> +'^' +
> +'(?P[^\[\t]*)' +
> +FRAME_ADDR +
> +'( |\t)' +
> +'((?P\?) )?' +
> +FRAME_BODY +
> +'$'
> +)
> +
> +# Matches the 'RIP:' line in BUG reports.
> +RIP_RE = re.compile(
> +'^' +
> +'(?P\s*RIP: ' + HEXNUM + ':\[[^]]+\]\s*)' +
> +FRAME_ADDR +
> +FRAME_BODY +
> +'$'
> +)
> +
> +# Matches a single line of `nm -S` output.
> +NM_RE = re.compile(
> +'^(?P' + HEXNUM + ') (?P' + HEXNUM + ')' +
> +' [a-zA-Z] (?P[^ ]+)$'
> +)
> +
> +
> +class Symbolizer(object):
> +def __init__(self, binary_path):
> +self.proc = subprocess.Popen(
> +['addr2line', '-f', '-i', '-e', binary_path],
> +stdin=subprocess.PIPE, stdout=subprocess.PIPE)
> +
> +def __enter__(self):
> +return self
> +
> +def __exit__(self, type, value, traceback):
> +self.close()
> +
> +def process(self, addr):
> +self.proc.stdin.write(addr + '\n')
> +self.proc.stdin.write('\n')
> +self.proc.stdin.flush()
> +
> +result = []
> +while True:
> +func = self.proc.stdout.readline().rstrip()
> +fileline = self.proc.stdout.readline().rstrip()
> +if func == '??':
> +if len(result) == 0:
> +self.proc.stdout.readline()
> +self.proc.stdout.readline()
> +return result
> +result.append((func, fileline))
> +
> +def close(self):
> +self.proc.kill()
> +self.proc.wait()
> +
> +
> +def find_file(path, name):
> +path = os.path.expanduser(path)
> +for root, dirs, files in os.walk(path):
> +if name in files:
> +return os.path.join(root, name)
> +return None
> +
> +
> +class SymbolOffsetLoader(object):
> +def __init__(self, binary_path):
> +output = subprocess.check_output(['nm', '-S', binary_path])
> +self.offsets = defaultdict(dict)
> +for line in output.split('\n'):
> +match = NM_RE.match(line)
> +if match != None:
> +offset = int(match.group('offset'), 16)
> +size = int(match.group('size'), 16)
> +# There can be several functions with similar names, but
> +# different sizes.
> +self.offsets[match.group('symbol')][size] = offset
> +
> +def lookup_offset(self, symbol, size):
> +offsets = self.offsets.get(symbol)
> +if (offse
Re: [PATCH 08/10] docs: sphinxify kmemleak.txt and move it to dev-tools
On Mon, Aug 08, 2016 at 05:35:00PM -0600, Jonathan Corbet wrote:
> Cc: Catalin Marinas
> Signed-off-by: Jonathan Corbet
> ---
> .../{kmemleak.txt => dev-tools/kmemleak.rst} | 93
> --
> Documentation/dev-tools/tools.rst | 1 +
> MAINTAINERS| 2 +-
> 3 files changed, 52 insertions(+), 44 deletions(-)
> rename Documentation/{kmemleak.txt => dev-tools/kmemleak.rst} (73%)
FWIW:
Acked-by: Catalin Marinas
[PATCH 3/4] ARM: dts: STiH418-B2199: Update gpio specifier
From: Patrice Chotard
- Remove useless gpio-cells
- Update second parameter by using GPIO_ACTIVE_HIGH/LOW
instead of hardcoded value
Signed-off-by: Patrice Chotard
---
arch/arm/boot/dts/stih418-b2199.dts | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/arch/arm/boot/dts/stih418-b2199.dts
b/arch/arm/boot/dts/stih418-b2199.dts
index 772d2bb..24e98a9 100644
--- a/arch/arm/boot/dts/stih418-b2199.dts
+++ b/arch/arm/boot/dts/stih418-b2199.dts
@@ -8,6 +8,7 @@
*/
/dts-v1/;
#include "stih418.dtsi"
+#include
/ {
model = "STiH418 B2199";
compatible = "st,stih418-b2199", "st,stih418";
@@ -35,14 +36,12 @@
leds {
compatible = "gpio-leds";
red {
- #gpio-cells = <2>;
label = "Front Panel LED";
- gpios = <&pio4 1 0>;
+ gpios = <&pio4 1 GPIO_ACTIVE_HIGH>;
linux,default-trigger = "heartbeat";
};
green {
- #gpio-cells = <2>;
- gpios = <&pio1 3 0>;
+ gpios = <&pio1 3 GPIO_ACTIVE_HIGH>;
default-state = "off";
};
};
--
1.9.1
Re: [PATCH 1/4] memory: ti-aemif: Get a named clock rather than an unnamed one
On Tue, Aug 09, 2016 at 05:15:15PM +, Karl Beldan wrote: > Many davinci boards (da830 and da850 families) don't have their clocks > in DT yet and won't be successful in getting an unnamed aemif clock. > Also the sole current users of ti-aemif (keystone boards) use 'aemif' as > their aemif device clock clock-name and should remain unaffected. > > Signed-off-by: Karl Beldan > --- > drivers/memory/ti-aemif.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/memory/ti-aemif.c b/drivers/memory/ti-aemif.c > index a579a0f..c251fc8 100644 > --- a/drivers/memory/ti-aemif.c > +++ b/drivers/memory/ti-aemif.c > @@ -345,7 +345,7 @@ static int aemif_probe(struct platform_device *pdev) > > platform_set_drvdata(pdev, aemif); > > - aemif->clk = devm_clk_get(dev, NULL); > + aemif->clk = devm_clk_get(dev, "aemif"); Looking further it seems to me that the struct clk_lookup da850_clks registered by davinci_clk_init() should be enough to clk_get() unnamed clocks using only the dev name. I look into what's going on but it would make this patch unnecessary. Karl
Re: [PATCH] usb: core: Add runtime resume checking
On 10 August 2016 at 17:07, Peter Chen wrote: > On Wed, Aug 10, 2016 at 02:43:50PM +0800, Baolin Wang wrote: >> Hi Peter, >> >> On 10 August 2016 at 14:18, Peter Chen wrote: >> > On Wed, Aug 10, 2016 at 10:33:31AM +0800, Baolin Wang wrote: >> >> Hi Greg, >> >> >> >> On 9 August 2016 at 18:26, Greg KH wrote: >> >> > On Tue, Aug 09, 2016 at 05:33:33PM +0800, Baolin Wang wrote: >> >> >> When the usb device has entered suspend state by runtime suspend >> >> >> method, and >> >> >> the sustem also try to enter suspend state by issuing >> >> >> usb_dev_suspend(), it >> >> >> will issue pm_runtime_resume() function to deal with wrong wakeup >> >> >> setting in >> >> >> choose_wakeup() function. >> >> >> >> >> >> But if usb device resumes failed due to xhci has been into suspend >> >> >> state and >> >> >> hardware is not accessible, which will set runtime errors. Thus when >> >> >> there is >> >> >> slave attached, usb device will resume failed by runtime resume method >> >> >> due to >> >> >> previous runtime errors. >> >> > >> >> > I really can't parse the first sentance in this paragraph, what exactly >> >> > makes xhci so "unique" here? >> >> >> >> Sorry for confusing, I try to explain it clearly. Considering strict >> >> power management for mobile device, we should also power off the usb >> >> controller if there are no slaves attached even though it is usb host >> >> function. >> >> >> >> For example: No slave attached> usb interface runtime suspend >> >> > usb device runtime suspend -> xhci suspend -> power off >> >> usb controller. After that if the system wants to enter suspend state, >> >> then it also will issue usb_dev_suspend(), then the >> >> pm_runtime_resume() function (issued in choose_wakeup() function) will >> >> return -ESHUTDOWN due to xhci has been suspend and hardware is not >> >> accessible. >> > >> > Why the controller does not be resumed when the root hub has issued >> > runtime resume? >> >> Because now there is no slave attached, we will not power on usb >> controller and resume xhci. >> > > I don't know why you set policy like this. Even the controller is > resumed, it will still be suspended by system suspend. What's more, > if you disallow it, how can you change your wakeup setting? > Eg, at runtime suspend, we enable wakeup by default. But for system > sleep, we disable wakeup by default. > > At runtime, if there is no device on the port, even we resumes the > controller and roohub, it still will be suspended soon. For saving power, if there is no slave attached, why we need to power on usb controller and resume xhci? Especially for mobile device. Moreover the usb device runtime suspend/resume is separate with xhci suspend/resume, when xhci entered suspend state, only slave attaching can resume xhci. -- Baolin.wang Best Regards
[tip:x86/urgent] x86/platform/UV: Fix bug with iounmap() of the UV4 EFI System Table causing a crash
Commit-ID: e363d24c2b997c421476c6aa00547edadf678efe
Gitweb: http://git.kernel.org/tip/e363d24c2b997c421476c6aa00547edadf678efe
Author: Mike Travis
AuthorDate: Mon, 1 Aug 2016 13:40:51 -0500
Committer: Ingo Molnar
CommitDate: Wed, 10 Aug 2016 15:55:38 +0200
x86/platform/UV: Fix bug with iounmap() of the UV4 EFI System Table causing a
crash
Save the uv_systab::size field before doing the iounmap()
of the struct pointer, to avoid a NULL dereference crash.
Tested-by: Frank Ramsay
Tested-by: John Estabrook
Signed-off-by: Mike Travis
Reviewed-by: Dimitri Sivanich
Reviewed-by: Nathan Zimmer
Cc: Alex Thorlton
Cc: Andrew Banman
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Peter Zijlstra
Cc: Russ Anderson
Cc: Thomas Gleixner
Link: http://lkml.kernel.org/r/20160801184050.250424...@asylum.americas.sgi.com
Signed-off-by: Ingo Molnar
---
arch/x86/platform/uv/bios_uv.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/arch/x86/platform/uv/bios_uv.c b/arch/x86/platform/uv/bios_uv.c
index 66b2166..4e9fd13 100644
--- a/arch/x86/platform/uv/bios_uv.c
+++ b/arch/x86/platform/uv/bios_uv.c
@@ -199,12 +199,14 @@ void uv_bios_init(void)
return;
}
+ /* Starting with UV4 the UV systab size is variable */
if (uv_systab->revision >= UV_SYSTAB_VERSION_UV4) {
+ int size = uv_systab->size;
+
iounmap(uv_systab);
- uv_systab = ioremap(efi.uv_systab, uv_systab->size);
+ uv_systab = ioremap(efi.uv_systab, size);
if (!uv_systab) {
- pr_err("UV: UVsystab: ioremap(%d) failed!\n",
- uv_systab->size);
+ pr_err("UV: UVsystab: ioremap(%d) failed!\n", size);
return;
}
}
Re: [PATCH V3] clk: bcm: Add driver for Northstar ILP clock
On Wed, Aug 10, 2016 at 8:05 AM, Rafał Miłecki wrote:
> From: Rafał Miłecki
>
> This clock is present on cheaper Northstar devices like BCM53573 or
> BCM47189 using Corex-A7. ILP is a part of PMU (Power Management Unit)
> and so it should be defined as one of its subnodes (subdevices). For
> more details see Documentation entry.
>
> Unfortunately there isn't a set of registers related to ILP clock only.
> We use registers 0x66c, 0x674 and 0x6dc and between them there are e.g.
> "retention*" and "control_ext" regs. This is why this driver maps all
> 0x1000 B of space.
>
> Signed-off-by: Rafał Miłecki
> ---
> V2: Rebase on top of clk-next
> Use ALP as parent clock
> Improve comments
> Switch from ioremap_nocache to ioremap
> Check of_clk_add_provide result for error
> V3: Drop #include
> Make ILP DT entry part of PMU
> Describe ILP as subdevice of PMU in Documentation
> ---
> .../devicetree/bindings/clock/brcm,ns-ilp.txt | 40 ++
> drivers/clk/bcm/Makefile | 1 +
> drivers/clk/bcm/clk-ns-ilp.c | 146
> +
> 3 files changed, 187 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/clock/brcm,ns-ilp.txt
> create mode 100644 drivers/clk/bcm/clk-ns-ilp.c
>
> diff --git a/Documentation/devicetree/bindings/clock/brcm,ns-ilp.txt
> b/Documentation/devicetree/bindings/clock/brcm,ns-ilp.txt
> new file mode 100644
> index 000..a18c73f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/brcm,ns-ilp.txt
> @@ -0,0 +1,40 @@
> +Broadcom Northstar ILP clock
> +
> +
> +This binding uses the common clock binding:
> +Documentation/devicetree/bindings/clock/clock-bindings.txt
> +
> +This binding is used for ILP clock (sometimes referred as "slow clock")
> +on Broadcom Northstar devices using Corex-A7 CPU.
> +
> +This clock is part of PMU (Power Management Unit), a Broadcom's device
> +handing power-related aspects. Please note PMU contains more subdevices,
> +ILP is only one of them.
> +
> +ILP's rate has to be calculated on runtime and it depends on ALP clock
> +which has to be referenced.
> +
> +Required properties:
> +- compatible: "brcm,ns-ilp"
> +- reg: iomem address range of PMU (Power Management Unit)
> +- reg-names: "pmu", the only needed & supported reg right now
> +- clocks: has to reference an ALP clock
> +- #clock-cells: should be <0>
> +
> +Example:
> +
> +pmu@18012000 {
> + compatible = "simple-bus";
> + ranges = <0x 0x18012000 0x1000>;
I don't see a corresponding DT entry in this patch, but 18012000 is
the PCI block. So, I am concerned this will collide if used there.
I looked at the NS register reference guide, and I cannot find the
registers you are trying to reference. Is this supposed to be
referencing the LCPLL clock registers in DMU? If so, there is already
a driver in there for this (see drivers/clk/bcm/clk-nsp.c).
> + #address-cells = <1>;
> + #size-cells = <1>;
> +
> + ilp: ilp@0 {
> + compatible = "brcm,ns-ilp";
> + reg = <0 0x1000>;
> + reg-names = "pmu";
> + clocks = <&alp>;
> + #clock-cells = <0>;
> + clock-output-names = "ilp";
> + };
> +};
> diff --git a/drivers/clk/bcm/Makefile b/drivers/clk/bcm/Makefile
> index 1d79bd2..1389379 100644
> --- a/drivers/clk/bcm/Makefile
> +++ b/drivers/clk/bcm/Makefile
> @@ -10,3 +10,4 @@ obj-$(CONFIG_COMMON_CLK_IPROC)+= clk-ns2.o
> obj-$(CONFIG_ARCH_BCM_CYGNUS) += clk-cygnus.o
> obj-$(CONFIG_ARCH_BCM_NSP) += clk-nsp.o
> obj-$(CONFIG_ARCH_BCM_5301X) += clk-nsp.o
> +obj-$(CONFIG_ARCH_BCM_5301X) += clk-ns-ilp.o
> diff --git a/drivers/clk/bcm/clk-ns-ilp.c b/drivers/clk/bcm/clk-ns-ilp.c
> new file mode 100644
> index 000..53b4a23
> --- /dev/null
> +++ b/drivers/clk/bcm/clk-ns-ilp.c
> @@ -0,0 +1,146 @@
> +/*
> + * Copyright (C) 2016 Rafał Miłecki
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define PMU_XTAL_FREQ_RATIO0x66c
> +#define XTAL_ALP_PER_4ILP 0x1fff
> +#define XTAL_CTL_EN 0x8000
> +#define PMU_SLOW_CLK_PERIOD0x6dc
> +
> +struct ns_ilp {
> + struct clk *clk;
> + struct clk_hw hw;
> + void __iomem *pmu;
> +};
> +
> +static int ns_ilp_enable(struct clk_hw *hw)
> +{
> + struct ns_ilp *ilp = container_of(hw, struct ns_ilp, hw);
> +
> + writel(0x10199, ilp->pmu + PMU_SLOW_CLK_PERIOD);
> + writel(0x1, ilp->pmu + 0x674);
> +
> + return 0;
> +}
> +
> +static unsigned long ns_ilp_recalc_rate(struct clk_hw *hw,
> +
[PATCH 3/3] arm64: kernel: declare cpu_ops __read_mostly
cpu_ops is initialized once by cpu_read_ops(), and thereafter is mostly
read in hot path, such as arm_cpuidle_suspend().
The fact that it is mostly read and not written to makes it candidates
for __read_mostly declarations.
Signed-off-by: Jisheng Zhang
---
arch/arm64/kernel/cpu_ops.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/arm64/kernel/cpu_ops.c b/arch/arm64/kernel/cpu_ops.c
index c7cfb8f..c1e4802 100644
--- a/arch/arm64/kernel/cpu_ops.c
+++ b/arch/arm64/kernel/cpu_ops.c
@@ -28,7 +28,7 @@ extern const struct cpu_operations smp_spin_table_ops;
extern const struct cpu_operations acpi_parking_protocol_ops;
extern const struct cpu_operations cpu_psci_ops;
-const struct cpu_operations *cpu_ops[NR_CPUS];
+const struct cpu_operations *cpu_ops[NR_CPUS] __read_mostly;
static const struct cpu_operations *dt_supported_cpu_ops[] __initconst = {
&smp_spin_table_ops,
--
2.8.1
[PATCH v2 3/4] ARM: dts: da850,da850-evm: Add an aemif node and use it for the NAND
Currently the davinci da8xx boards use the mach-davinci aemif code.
Instantiating an aemif node into the DT allows to use the ti-aemif
memory driver and is another step to better DT support.
This change adds an aemif node in the dtsi while retiring the nand_cs3
node. The NAND is now instantiated in the dts as a subnode of the aemif
one along with its pins.
Signed-off-by: Karl Beldan
---
arch/arm/boot/dts/da850-evm.dts | 49 -
arch/arm/boot/dts/da850.dtsi| 19 +++-
2 files changed, 52 insertions(+), 16 deletions(-)
diff --git a/arch/arm/boot/dts/da850-evm.dts b/arch/arm/boot/dts/da850-evm.dts
index 1a15db8..eedcc59 100644
--- a/arch/arm/boot/dts/da850-evm.dts
+++ b/arch/arm/boot/dts/da850-evm.dts
@@ -29,6 +29,20 @@
0x04 0x00011000 0x000ff000
>;
};
+ nand_pins: nand_pins {
+ pinctrl-single,bits = <
+ /* EMA_WAIT[0], EMA_OE, EMA_WE,
EMA_CS[4], EMA_CS[3] */
+ 0x1c 0x10110110 0xf0ff0ff0
+ /*
+* EMA_D[0], EMA_D[1], EMA_D[2],
+* EMA_D[3], EMA_D[4], EMA_D[5],
+* EMA_D[6], EMA_D[7]
+*/
+ 0x24 0x 0x
+ /* EMA_A[1], EMA_A[2] */
+ 0x30 0x0110 0x0ff0
+ >;
+ };
};
serial0: serial@42000 {
status = "okay";
@@ -131,11 +145,6 @@
status = "okay";
};
};
- nand_cs3@6200 {
- status = "okay";
- pinctrl-names = "default";
- pinctrl-0 = <&nand_cs3_pins>;
- };
vbat: fixedregulator@0 {
compatible = "regulator-fixed";
regulator-name = "vbat";
@@ -250,3 +259,33 @@
&edma1 {
ti,edma-reserved-slot-ranges = <32 90>;
};
+
+&aemif {
+ pinctrl-names = "default";
+ pinctrl-0 = <&nand_pins>;
+ status = "ok";
+ cs3 {
+ #address-cells = <2>;
+ #size-cells = <1>;
+ clock-ranges;
+ ranges;
+
+ ti,cs-chipselect = <3>;
+
+ nand@200,0 {
+ compatible = "ti,davinci-nand";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ reg = <0 0x0200 0x0200
+ 1 0x 0x8000>;
+
+ ti,davinci-chipselect = <1>;
+ ti,davinci-mask-ale = <0>;
+ ti,davinci-mask-cle = <0>;
+ ti,davinci-mask-chipsel = <0>;
+ ti,davinci-ecc-mode = "hw";
+ ti,davinci-ecc-bits = <4>;
+ ti,davinci-nand-use-bbt;
+ };
+ };
+};
diff --git a/arch/arm/boot/dts/da850.dtsi b/arch/arm/boot/dts/da850.dtsi
index bc10e7e..e73fd64 100644
--- a/arch/arm/boot/dts/da850.dtsi
+++ b/arch/arm/boot/dts/da850.dtsi
@@ -411,17 +411,14 @@
dma-names = "tx", "rx";
};
};
- nand_cs3@6200 {
- compatible = "ti,davinci-nand";
- reg = <0x6200 0x807ff
- 0x6800 0x8000>;
- ti,davinci-chipselect = <1>;
- ti,davinci-mask-ale = <0>;
- ti,davinci-mask-cle = <0>;
- ti,davinci-mask-chipsel = <0>;
- ti,davinci-ecc-mode = "hw";
- ti,davinci-ecc-bits = <4>;
- ti,davinci-nand-use-bbt;
+ aemif: aemif@6800 {
+ compatible = "ti,da850-aemif";
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ reg = <0x6800 0x8000>;
+ ranges = <0 0 0x6000 0x0800
+ 1 0 0x6800 0x8000>;
status = "disabled";
};
};
--
2.9.2
[RESEND PATCH v3 0/3] ARM: cleanup PCI specific configs
This series was initially sent to add support for two PCIe ports in dra7. This included selecting PCI_DOMAINS config in SOC_DRA7XX. However from the review, PCI_DOMAINS can instead be selected from ARCH_MULTIPLATFORM. This is fixed in this series along with removing PCI_DOMAINS from other configs. Since this series was initially sent to add support for two PCIe ports in dra7, it has been tested to see if there are regressions with 1 PCIe port. Though testing of 2 PCIe ports is not done while sending this patch series, it has been verified before in few of the customer boards. Changes from v2: *) v2 removed MIGHT_HAVE_PCI from platforms that are not ARCH_MULTIPLATFORM. Fixed it in this version Changes from v1: *) select PCI_DOMAINS config from ARCH_MULTIPLATFORM *) Fix *MIGHT_HAVE_PCI* config from being selected redundantly Kishon Vijay Abraham I (3): ARM: dts: DRA7: Add "linux,pci-domain" property for pci dt nodes ARM: Fix *MIGHT_HAVE_PCI* config from being selected redundantly ARM: select PCI_DOMAINS config from ARCH_MULTIPLATFORM arch/arm/Kconfig |1 + arch/arm/boot/dts/dra7.dtsi |2 ++ arch/arm/mach-at91/Kconfig |1 - arch/arm/mach-axxia/Kconfig |2 -- arch/arm/mach-cns3xxx/Kconfig|1 - arch/arm/mach-exynos/Kconfig |2 -- arch/arm/mach-imx/Kconfig|2 -- arch/arm/mach-integrator/Kconfig |1 - arch/arm/mach-keystone/Kconfig |2 -- arch/arm/mach-shmobile/Kconfig |1 - arch/arm/mach-spear/Kconfig |1 - arch/arm/mach-versatile/Kconfig |1 - 12 files changed, 3 insertions(+), 14 deletions(-) -- 1.7.9.5
Re: [PATCH 2/2] arm: apply more __ro_after_init
On Fri, Jun 03, 2016 at 11:40:24AM -0700, Kees Cook wrote:
> @@ -1309,16 +1309,11 @@ void __init arm_mm_memblock_reserve(void)
> * Any other function or debugging method which may touch any device _will_
> * crash the kernel.
> */
> +static char vectors[PAGE_SIZE * 2] __ro_after_init __aligned(PAGE_SIZE);
> static void __init devicemaps_init(const struct machine_desc *mdesc)
> {
> struct map_desc map;
> unsigned long addr;
> - void *vectors;
> -
> - /*
> - * Allocate the vector page early.
> - */
> - vectors = early_alloc(PAGE_SIZE * 2);
This one is not appropriate. We _do_ write to these pages after init
for FIQ handler updates. See set_fiq_handler().
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
[PATCH v5 2/3] pcie-designware: add iATU Unroll feature
This patch adds the support to the new iATU mechanism that will be used
from Core version 4.80, which is called iATU Unroll.
The new Cores can support the iATU Unroll or support the "old" iATU
method now called Legacy Mode. The driver is perfectly capable of
performing well for both.
In order to make sure that the iATU is really enabled a for loop was
introduced in dw_pcie_prog_outbound_atu() to improve reliability.
Signed-off-by: Joao Pinto
---
changes v4->v5:
- v4 patch was not done properly
changes v3->v4:
- Unroll Mode is now obtained before the host initialization
- The iATU enable check loop is now returning instead of only
interrupting the loop
changes v2->v3 (Bjorn Helgaas):
- Unused *CTRL3 and *UPPR iATU Unroll registers were removed
- Inbound addr builder macro was removed to simplifiy the code
- *readl_unroll and *writel_unroll functions were simplified. Now the
scope is always outbound.
- dw_pcie_get_atu_mode changed to return the status
- iATU enable check routine was improved in dw_pcie_prog_outbound_atu()
changes v1->v2:
- Patch was breaking kernel build due to bad definition in macro funtion.
- Rebased on top of pci/next.
drivers/pci/host/pcie-designware.c | 131 -
drivers/pci/host/pcie-designware.h | 1 +
2 files changed, 116 insertions(+), 16 deletions(-)
diff --git a/drivers/pci/host/pcie-designware.c
b/drivers/pci/host/pcie-designware.c
index 6fb88de..d239bc9 100644
--- a/drivers/pci/host/pcie-designware.c
+++ b/drivers/pci/host/pcie-designware.c
@@ -31,6 +31,11 @@
#define LINK_WAIT_USLEEP_MIN 9
#define LINK_WAIT_USLEEP_MAX 10
+/* Parameters for the waiting for iATU enabled routine */
+#define LINK_WAIT_MAX_IATU_RETRIES 5
+#define LINK_WAIT_IATU_MIN 9000
+#define LINK_WAIT_IATU_MAX 1
+
/* Synopsis specific PCIE configuration registers */
#define PCIE_PORT_LINK_CONTROL 0x710
#define PORT_LINK_MODE_MASK(0x3f << 16)
@@ -75,6 +80,26 @@
#define PCIE_ATU_FUNC(x) (((x) & 0x7) << 16)
#define PCIE_ATU_UPPER_TARGET 0x91C
+/*
+ * iATU unroll specific registers and definitions
+ * from 4.80 core version the address translation will be made by unroll
+ */
+
+/* Registers */
+#define PCIE_ATU_UNR_REGION_CTRL1 0x00
+#define PCIE_ATU_UNR_REGION_CTRL2 0x01
+#define PCIE_ATU_UNR_LOWER_BASE0x02
+#define PCIE_ATU_UNR_UPPER_BASE0x03
+#define PCIE_ATU_UNR_LIMIT 0x04
+#define PCIE_ATU_UNR_LOWER_TARGET 0x05
+#define PCIE_ATU_UNR_UPPER_TARGET 0x06
+
+/* Register address builder */
+#define PCIE_GET_ATU_OUTB_UNR_REG_ADDR(region, register) \
+ ((0x3 << 20) | (region << 9) | \
+ (register << 2))
+/* End of Unroll specific */
+
/* PCIe Port Logic registers */
#define PLR_OFFSET 0x700
#define PCIE_PHY_DEBUG_R1 (PLR_OFFSET + 0x2c)
@@ -136,6 +161,28 @@ static inline void dw_pcie_writel_rc(struct pcie_port *pp,
u32 val, u32 reg)
writel(val, pp->dbi_base + reg);
}
+static inline void dw_pcie_readl_unroll(struct pcie_port *pp,
+ u32 index, u32 reg, u32 *val)
+{
+ u32 reg_addr = PCIE_GET_ATU_OUTB_UNR_REG_ADDR(index, reg);
+
+ if (pp->ops->readl_rc)
+ pp->ops->readl_rc(pp, pp->dbi_base + reg_addr, val);
+ else
+ *val = readl(pp->dbi_base + reg_addr);
+}
+
+static inline void dw_pcie_writel_unroll(struct pcie_port *pp,
+ u32 index, u32 val, u32 reg)
+{
+ u32 reg_addr = PCIE_GET_ATU_OUTB_UNR_REG_ADDR(index, reg);
+
+ if (pp->ops->writel_rc)
+ pp->ops->writel_rc(pp, val, pp->dbi_base + reg_addr);
+ else
+ writel(val, pp->dbi_base + reg_addr);
+}
+
static int dw_pcie_rd_own_conf(struct pcie_port *pp, int where, int size,
u32 *val)
{
@@ -157,24 +204,61 @@ static int dw_pcie_wr_own_conf(struct pcie_port *pp, int
where, int size,
static void dw_pcie_prog_outbound_atu(struct pcie_port *pp, int index,
int type, u64 cpu_addr, u64 pci_addr, u32 size)
{
- u32 val;
-
- dw_pcie_writel_rc(pp, PCIE_ATU_REGION_OUTBOUND | index,
- PCIE_ATU_VIEWPORT);
- dw_pcie_writel_rc(pp, lower_32_bits(cpu_addr), PCIE_ATU_LOWER_BASE);
- dw_pcie_writel_rc(pp, upper_32_bits(cpu_addr), PCIE_ATU_UPPER_BASE);
- dw_pcie_writel_rc(pp, lower_32_bits(cpu_addr + size - 1),
- PCIE_ATU_LIMIT);
- dw_pcie_writel_rc(pp, lower_32_bits(pci_addr), PCIE_ATU_LOWER_TARGET);
- dw_pcie_writel_rc(pp, upper_32_bits(pci_addr), PCIE_ATU_UPPER_TARGET);
- dw_pcie_writel_rc(pp, type, PCIE_ATU_CR1);
- dw_pcie_writel_rc(pp, PCIE_ATU_ENABLE, PCIE_ATU_CR2);
+ u32 val = 0;
+ u32 ret
Re: [lkp] [nfsd] b44061d0b9: BUG: Dentry ffff880027d7c540{i=1846f,n=0a} still in use (1) [unmount of btrfs vda]
On 08/10/2016 02:06 PM, Linus Torvalds wrote:
On Tue, Aug 9, 2016 at 10:39 PM, kernel test robot
wrote:
[ 1537.558739] nfsd: last server has exited, flushing export cache
[ 1540.627795] BUG: Dentry 880027d7c540{i=1846f,n=0a} still in use (1)
[unmount of btrfs vda]
[ 1540.633915] [ cut here ]
[ 1540.636551] WARNING: CPU: 0 PID: 20552 at fs/dcache.c:1474
umount_check+0x72/0x80
Hmm. Adding Al and the btrfs people to the cc, and expanding the nfs
list. Unlike the flakey-IO warning, this one sounds like a real issue.
Whether it's some dentry leak by nfsd or a VFS or btrfs issue, I can't
begin to guess. Al, ideas?
More information in the original email on lkml.
I'm not subscribed to lkml and for some reason I can't find the original email
in any of the lkml/linux-nfs archives. Could you forward more of the details?
Thanks,
Josef
[PATCH] iio: light: us5182d: Add missing error code assignment before test
It is likely that checking the result of 'pm_runtime_set_active' is
expected here.
Fixes: f0e5f57d3ac2 ("iio: light: us8152d: Add power management support")
Signed-off-by: Christophe JAILLET
---
drivers/iio/light/us5182d.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/light/us5182d.c b/drivers/iio/light/us5182d.c
index 20c40f780964..18cf2e29e4d5 100644
--- a/drivers/iio/light/us5182d.c
+++ b/drivers/iio/light/us5182d.c
@@ -894,7 +894,7 @@ static int us5182d_probe(struct i2c_client *client,
goto out_err;
if (data->default_continuous) {
- pm_runtime_set_active(&client->dev);
+ ret = pm_runtime_set_active(&client->dev);
if (ret < 0)
goto out_err;
}
--
2.7.4
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel
antivirus Avast.
https://www.avast.com/antivirus
[PATCH v2 0/2] PCI: designware: let dw_pcie_link_up() beware of LTSSM training bit
patch1 is a trivial clean up: move the parameters for wait for link into the core pcie-designware.c Since link may be UP but still in link training, if so, we can't think the link is up and operating correctly. So patch2 teaches dw_pcie_link_up() beware of the PCIE_PHY_DEBUG_R1_LINK_IN_TRAINING bit. Since v1: - add Joao's Ack - rebased on v4.8-rc1 Jisheng Zhang (2): PCI: designware: mv parameters for wait for link into pcie-designware.c PCI: designware: let dw_pcie_link_up() beware of LTSSM training bit drivers/pci/host/pcie-designware.c | 11 +-- drivers/pci/host/pcie-designware.h | 5 - 2 files changed, 9 insertions(+), 7 deletions(-) -- 2.8.1
Re: [PATCH v1] firmware_class: encapsulate firmware loading status
On 10.08.2016 03:10, Luis R. Rodriguez wrote:
> On Thu, Aug 04, 2016 at 02:27:16PM +0200, Daniel Wagner wrote:
>> From: Daniel Wagner
>> In [0] we have a discussion on how the firmware_class API might be
>> changed to improve the current handling of firmware loading. This
>> patch was part of the orignal RFC which triggered the discussion.
>>
>> I think it is worth taking this one anyway. Maybe as I suggested it
>> could be part of the series from Luis.
>
> I'm happy to queue it in on my end however your changes are a bit orthogonal
> as you help optimize us away from the usermode helper, I just
> compartamentalize
> that whole API away into a new one so this can go in separately.
Okay.
> In terms of
> coordination -- sure order will help to get right so I can queue it in, in
> that sense. But we're not yet sure if sysdsata will go in first, and I'm happy
> for this to go in first as it does not conflict as its slightly orthogonal.
>
> So order here does not interfere with my series -- lets just review this and
> its good lets let it go in.
Alright, let's do this then first.
> What you do is strip us further from the user mode helper and that
> is a good thing.
>
> My review below.
>
>> It cleans up the code base (okay my opinion)
>
> You do little to sell this. In fact, if this is OK, it does a good
> compartamentalization of a completion and a lock and implicates the
> wait stuff only onto the usermoder helper, indeed that's a win
> worth documenting on the commit log.
My selling skill has still a lot of room to grow. I'll add your points
to the commit message.
>> and removes the
>> complete_all() call which is problematic for -rt. complete_all() can
>> be used in any context including IRQ.
>
> I see. But in this case the code in question should never run in IRQ context?
No, this code is not running in IRQ context. See below.
>> That could lead to unbounded
>> work in the IRQ context and that is a no go for -rt.
>
> Is the fear of the call to be used in IRQ context or the waiters to
> somehow work in IRQ context somehow. The waiters were sleeping.. so
> that I think leaves only the call site of the complete_all() to worry
> about, but I can't see that happening in IRQ context. Please
> correct me if I'm wrong.
The only problem for -rt is if the complete_all() happens in IRQ
context. If that happens the waker wakes up all waiters in one go (in
IRQ). That leads to the 'unbounded work' which can't be preempted. There
is no further restriction for -rt on waiters or wakers.
>> So here the
>> attempt to reduce the number of complete_all() calls where possible.
>
> OK so this is the real motivation.
Yes, this is more ore less a clean up work :)
>> I have left this argument out in the commit message because I was told '-rt'
>> arguments don't count for inclusion.
>
> Sure, but I appreciate this explanation, thanks for that !
>
> Can you provide a set of commits accepted upstream or on linux-next
> where such conversion has been done and accepted as well elsewhere
> in the kernel ?
Not so far. I have started to send out patches last week. It seems most
people are enjoying holiday.
https://lkml.org/lkml/2016/8/4/264
https://patchwork.kernel.org/project/linux-amlogic/list/?submitter=47731
> I know its just pending patches for review but this has me thinking, is
> the use of async functionality in the sysdata patches kosher for RT ?
I haven't looked into deeply but from what I saw there is no obvious
show stopper. I'll give it another look next week. I am AFK till next
week ;)
>
>> cheers,
>> daniel
>>
>> [0] http://www.spinics.net/lists/linux-wireless/msg153005.html
>>
>> drivers/base/firmware_class.c | 154
>> --
>> 1 file changed, 89 insertions(+), 65 deletions(-)
>>
>> diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
>> index 22d1760..33eb372 100644
>> --- a/drivers/base/firmware_class.c
>> +++ b/drivers/base/firmware_class.c
>> @@ -30,6 +30,7 @@
>> #include
>> #include
>> #include
>> +#include
>>
>> #include
>>
>> @@ -91,19 +92,83 @@ static inline bool fw_is_builtin_firmware(const struct
>> firmware *fw)
>> }
>> #endif
>>
>> +static int loading_timeout = 60;/* In seconds */
>> +
>> +static inline long firmware_loading_timeout(void)
>> +{
>> +return loading_timeout > 0 ? loading_timeout * HZ : MAX_JIFFY_OFFSET;
>> +}
>
> Seems like we can wrap the above loading_timeout and firmware_loading_timeout
> onto
> CONFIG_FW_LOADER_USER_HELPER -- or provide a helper that returns some
> static nonsense value that works for !CONFIG_FW_LOADER_USER_HELPER.
>
> The move of the code above also makes this change harder to review.
Yeah, I moved it up because in one version I had a dependency to
firmware_loading_timeout. Hmm, maybe it can be removed or integrated a
bit more tightly.
[...]
> Other than that this looks nice so far. Can you please run the tests
>
> tools/testing/selftests/firmware/fw
Re: [PATCH 1/4] media: pci: netup_unidvb: don't print error when adding adapter fails
yes, you right. If we remove this message there is no big problem. But
if we do not remove this it's also ok, right ? What the big deal to
remove this type of messages (i'm just interested) ?
For me it's ok to remove:
Acked-by: Abylay Ospan
2016-08-09 10:58 GMT-04:00 Wolfram Sang :
>
>> Sometimes it better to show more message - especially in error conditions :)
>
> Sure, if they contain additional information.
>
>> btw, do you make sanity check for "duplicate" log messages ?
>
> I checked all error messages if they contain additional information.
>
>> ret = i2c_add_adapter(&i2c->adap);
>> - if (ret) {
>> - dev_err(&ndev->pci_dev->dev,
>> - "%s(): failed to add I2C adapter\n", __func__);
>> + if (ret)
>> return ret;
>> - }
>
> IMHO, this one doesn't. __func__ is not helpful to users. And the error
> messages in the core will make sure that a developer knows where to
> start looking.
>
--
Abylay Ospan,
NetUP Inc.
http://www.netup.tv
Re: [PATCH 1/1 v2] net: i10e: use matching format indentifiers
On Tue, 2016-08-02 at 20:15 +0200, Heinrich Schuchardt wrote: > i is defined as int but output as %u several times. > Adjust the format identifiers. > > v2: > Keep definition of i as int. > David indicated that this is the preferable way to define > loop variables. > > Signed-off-by: Heinrich Schuchardt > --- > drivers/net/ethernet/intel/i40e/i40e_ethtool.c | 26 +--- > -- > 1 file changed, 13 insertions(+), 13 deletions(-) your title needs fixing as well... s/i10e/i40e/ and s/indentifiers/identifiers/ signature.asc Description: This is a digitally signed message part
[PATCH v2 0/2] PCI: designware: let dw_pcie_link_up() beware of LTSSM training bit
patch1 is a trivial clean up: move the parameters for wait for link into the core pcie-designware.c Since link may be UP but still in link training, if so, we can't think the link is up and operating correctly. So patch2 teaches dw_pcie_link_up() beware of the PCIE_PHY_DEBUG_R1_LINK_IN_TRAINING bit. Since v1: - add Joao's Ack - rebased on v4.8-rc1 Jisheng Zhang (2): PCI: designware: mv parameters for wait for link into pcie-designware.c PCI: designware: let dw_pcie_link_up() beware of LTSSM training bit drivers/pci/host/pcie-designware.c | 11 +-- drivers/pci/host/pcie-designware.h | 5 - 2 files changed, 9 insertions(+), 7 deletions(-) -- 2.8.1
[PATCH] ARM: cpuidle: declare cpuidle_ops __read_mostly
cpuidle_ops is initialized once by arm_cpuidle_read_ops() during initialization, and thereafter is mostly read in arm_cpuidle_suspend() The fact that it is mostly read and not written to makes it candidates for __read_mostly declarations. Signed-off-by: Jisheng Zhang --- arch/arm/kernel/cpuidle.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/kernel/cpuidle.c b/arch/arm/kernel/cpuidle.c index 7dccc96..762e0929 100644 --- a/arch/arm/kernel/cpuidle.c +++ b/arch/arm/kernel/cpuidle.c @@ -19,7 +19,7 @@ extern struct of_cpuidle_method __cpuidle_method_of_table[]; static const struct of_cpuidle_method __cpuidle_method_of_table_sentinel __used __section(__cpuidle_method_of_table_end); -static struct cpuidle_ops cpuidle_ops[NR_CPUS]; +static struct cpuidle_ops cpuidle_ops[NR_CPUS] __read_mostly; /** * arm_cpuidle_simple_enter() - a wrapper to cpu_do_idle() -- 2.8.1
Re: [PATCH V3] clk: bcm: Add driver for Northstar ILP clock
On Wed, Aug 10, 2016 at 1:44 PM, Ray Jui wrote:
>
>
> On 8/10/2016 10:28 AM, Rafał Miłecki wrote:
>>
>> On 10 August 2016 at 19:22, Jon Mason wrote:
>>>
>>> On Wed, Aug 10, 2016 at 8:05 AM, Rafał Miłecki wrote:
diff --git a/Documentation/devicetree/bindings/clock/brcm,ns-ilp.txt
b/Documentation/devicetree/bindings/clock/brcm,ns-ilp.txt
new file mode 100644
index 000..a18c73f
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/brcm,ns-ilp.txt
@@ -0,0 +1,40 @@
+Broadcom Northstar ILP clock
+
+
+This binding uses the common clock binding:
+Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+This binding is used for ILP clock (sometimes referred as "slow clock")
+on Broadcom Northstar devices using Corex-A7 CPU.
+
+This clock is part of PMU (Power Management Unit), a Broadcom's device
+handing power-related aspects. Please note PMU contains more
subdevices,
+ILP is only one of them.
+
+ILP's rate has to be calculated on runtime and it depends on ALP clock
+which has to be referenced.
+
+Required properties:
+- compatible: "brcm,ns-ilp"
+- reg: iomem address range of PMU (Power Management Unit)
+- reg-names: "pmu", the only needed & supported reg right now
+- clocks: has to reference an ALP clock
+- #clock-cells: should be <0>
+
+Example:
+
+pmu@18012000 {
+ compatible = "simple-bus";
+ ranges = <0x 0x18012000 0x1000>;
>>>
>>>
>>> I don't see a corresponding DT entry in this patch, but 18012000 is
>>> the PCI block. So, I am concerned this will collide if used there.
>>>
>>> I looked at the NS register reference guide, and I cannot find the
>>> registers you are trying to reference. Is this supposed to be
>>> referencing the LCPLL clock registers in DMU? If so, there is already
>>> a driver in there for this (see drivers/clk/bcm/clk-nsp.c).
>>
>>
>> This patch is for BCM53573 family, not BCM4708 family you are looking at.
>>
>> Found chip with id 53573, rev 0x02 and package 0x01
>> Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x36, class 0x0)
>> Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x38, class 0x0)
>> Core 2 found: PCIe Gen 2 (manuf 0x4BF, id 0x501, rev 0x05, class 0x0)
>> Core 3 found: ARM CA7 (manuf 0x4BF, id 0x847, rev 0x00, class 0x0)
>> Core 4 found: USB 2.0 Host (manuf 0x4BF, id 0x819, rev 0x05, class 0x0)
>> Core 5 found: GBit MAC (manuf 0x4BF, id 0x82D, rev 0x08, class 0x0)
>> Core 6 found: I2S (manuf 0x4BF, id 0x834, rev 0x06, class 0x0)
>> Core 7 found: CNDS DDR2/3 memory controller (manuf 0x4BF, id 0x846,
>> rev 0x00, class 0x0)
>> Core 8 found: NAND flash controller (manuf 0x4BF, id 0x509, rev 0x01,
>> class 0x0)
>> Core 9 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x38, class 0x0)
>> Core 10 found: GBit MAC (manuf 0x4BF, id 0x82D, rev 0x08, class 0x0)
>> Core 11 found: I2S (manuf 0x4BF, id 0x834, rev 0x06, class 0x0)
>> Core 12 found: GCI (manuf 0x4BF, id 0x840, rev 0x08, class 0x0)
>> Core 13 found: PMU (manuf 0x4BF, id 0x827, rev 0x1C, class 0x0)
>>
>
> Out of curiosity, I searched the datasheet and found this is a wireless
> router SoC done by the WLAN team. It happens to share some peripherals with
> other iProc based SoCs.
>
> I cannot find a code name for this SoC from our internal documents. I guess
> that name "Northstar" used here has confused both Jon and me.
>
> Thanks,
>
> Ray
Ray is right. I just spoke to one of the people here with knowledge
of the HW, and this is not related at all to the 4708/9/5301X. It MAY
have some of the same peripherals, but the core is different (Cortex
A7 instead of A9).
I think we are best off to change the name and turn this into a
separate device tree, driver base, etc. I wasn't able to get a code
name, so perhaps simply call it "BCM53573".
Thanks,
Jon
