[PATCH 01/05] ARM: shmobile: Add r8a7790 thermal device node to DTS
From: Magnus Damm d...@opensource.se
Hook up the r8a7790 thermal sensor to the DTS.
Signed-off-by: Magnus Damm d...@opensource.se
---
arch/arm/boot/dts/r8a7790.dtsi |7 +++
1 file changed, 7 insertions(+)
--- 0004/arch/arm/boot/dts/r8a7790.dtsi
+++ work/arch/arm/boot/dts/r8a7790.dtsi 2013-11-20 08:25:53.0 +0900
@@ -162,6 +162,13 @@
interrupt-controller;
};
+ thermal@e61f {
+ compatible = renesas,thermal-r8a7790, renesas,rcar-thermal;
+ reg = 0 0xe61f 0 0x14, 0 0xe61f0100 0 0x38;
+ interrupt-parent = gic;
+ interrupts = 0 69 IRQ_TYPE_LEVEL_HIGH;
+ };
+
timer {
compatible = arm,armv7-timer;
interrupts = 1 13 (GIC_CPU_MASK_SIMPLE(4) |
IRQ_TYPE_LEVEL_LOW),
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/05] ARM: shmobile: Add r8a7791 thermal platform device
From: Magnus Damm d...@opensource.se
Add a thermal platform device for the legacy case
on the r8a7791 SoC. This keeps the r8a7791 in sync
with the r8a7790 sister device.
Signed-off-by: Magnus Damm d...@opensource.se
---
arch/arm/mach-shmobile/setup-r8a7791.c | 12
1 file changed, 12 insertions(+)
--- 0001/arch/arm/mach-shmobile/setup-r8a7791.c
+++ work/arch/arm/mach-shmobile/setup-r8a7791.c 2013-11-20 15:54:42.0
+0900
@@ -189,6 +189,17 @@ static struct resource irqc0_resources[]
irqc##idx##_data,\
sizeof(struct renesas_irqc_config))
+static const struct resource thermal_resources[] __initconst = {
+ DEFINE_RES_MEM(0xe61f, 0x14),
+ DEFINE_RES_MEM(0xe61f0100, 0x38),
+ DEFINE_RES_IRQ(gic_spi(69)),
+};
+
+#define r8a7791_register_thermal() \
+ platform_device_register_simple(rcar_thermal, -1, \
+ thermal_resources, \
+ ARRAY_SIZE(thermal_resources))
+
void __init r8a7791_add_dt_devices(void)
{
r8a7791_register_scif(SCIFA0);
@@ -213,6 +224,7 @@ void __init r8a7791_add_standard_devices
{
r8a7791_add_dt_devices();
r8a7791_register_irqc(0);
+ r8a7791_register_thermal();
}
void __init r8a7791_init_early(void)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 05/05] ARM: shmobile: Add r8a7791 clocks for thermal devices
From: Magnus Damm d...@opensource.se
Add the r8a7791 thermal device as legacy clocks.
Signed-off-by: Magnus Damm d...@opensource.se
---
arch/arm/mach-shmobile/clock-r8a7791.c |4
1 file changed, 4 insertions(+)
--- 0001/arch/arm/mach-shmobile/clock-r8a7791.c
+++ work/arch/arm/mach-shmobile/clock-r8a7791.c 2013-11-20 15:52:07.0
+0900
@@ -124,6 +124,7 @@ static struct clk *main_clks[] = {
enum {
MSTP726, MSTP724, MSTP723, MSTP721, MSTP720,
MSTP719, MSTP718, MSTP715, MSTP714,
+ MSTP522,
MSTP216, MSTP207, MSTP206,
MSTP204, MSTP203, MSTP202, MSTP1105, MSTP1106, MSTP1107,
MSTP124,
@@ -140,6 +141,7 @@ static struct clk mstp_clks[MSTP_NR] = {
[MSTP718] = SH_CLK_MSTP32(p_clk, SMSTPCR7, 18, 0), /* SCIF3 */
[MSTP715] = SH_CLK_MSTP32(p_clk, SMSTPCR7, 15, 0), /* SCIF4 */
[MSTP714] = SH_CLK_MSTP32(p_clk, SMSTPCR7, 14, 0), /* SCIF5 */
+ [MSTP522] = SH_CLK_MSTP32(extal_clk, SMSTPCR5, 22, 0), /* Thermal */
[MSTP216] = SH_CLK_MSTP32(mp_clk, SMSTPCR2, 16, 0), /* SCIFB2 */
[MSTP207] = SH_CLK_MSTP32(mp_clk, SMSTPCR2, 7, 0), /* SCIFB1 */
[MSTP206] = SH_CLK_MSTP32(mp_clk, SMSTPCR2, 6, 0), /* SCIFB0 */
@@ -188,6 +190,8 @@ static struct clk_lookup lookups[] = {
CLKDEV_DEV_ID(sh-sci.13, mstp_clks[MSTP1106]), /* SCIFA4 */
CLKDEV_DEV_ID(sh-sci.14, mstp_clks[MSTP1107]), /* SCIFA5 */
CLKDEV_DEV_ID(sh_cmt.0, mstp_clks[MSTP124]),
+ CLKDEV_DEV_ID(e61f.thermal, mstp_clks[MSTP522]),
+ CLKDEV_DEV_ID(rcar_thermal, mstp_clks[MSTP522]),
};
#define R8A7791_CLOCK_ROOT(e, m, p0, p1, p30, p31) \
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: user defined OOM policies
On Tue, 19 Nov 2013, Michal Hocko wrote: We have basically ended up with 3 options AFAIR: 1) allow memcg approach (memcg.oom_control) on the root level for both OOM notification and blocking OOM killer and handle the situation from the userspace same as we can for other memcgs. This looks like a straightforward approach as the similar thing is done on the local (memcg) level. There are several problems though. Running userspace from within OOM context is terribly hard to do right. Not sure it's hard if you have per-memcg memory reserves which I've brought up in the past with true and complete kmem accounting. Even if you don't allocate slab, it guarantees that there will be at least a little excess memory available so that the userspace oom handler isn't oom itself. This involves treating processes waiting on memory.oom_control to be treated as a special class so that they are allowed to allocate an additional pre-configured amount of memory. For non-root memcgs, this would simply be a dummy usage that would be charged to the memcg when the oom notification is registered and actually accessible only by the oom handler itself while memcg-under_oom. For root memcgs, this would simply be a PF_MEMALLOC type behavior that dips into per-zone memory reserves. This is true even in the memcg case and we strongly discurage users from doing that. The global case has nothing like outside of OOM context though. So any hang would blocking the whole machine. Why would there be a hang if the userspace oom handlers aren't actually oom themselves as described above? I'd suggest against the other two suggestions because hierarchical per-memcg userspace oom handlers are very powerful and can be useful without actually killing anything at all, and parent oom handlers can signal child oom handlers to free memory in oom conditions (in other words, defer a parent oom condition to a child's oom handler upon notification). I was planning on writing a liboom library that would lay the foundation for how this was supposed to work and some generic functions that make use of the per-memcg memory reserves. So my plan for the complete solution was: - allow userspace notification from the root memcg on system oom conditions, - implement a memory.oom_delay_millisecs timeout so that the kernel eventually intervenes if userspace fails to respond, including for system oom conditions, for whatever reason which would be set to 0 if no userspace oom handler is registered for the notification, and - implement per-memcg reserves as described above so that userspace oom handlers have access to memory even in oom conditions as an upfront charge and have the ability to free memory as necessary. We already have the ability to do the actual kill from userspace, both the system oom killer and the memcg oom killer grants access to memory reserves for any process needing to allocate memory if it has a pending SIGKILL which we can send from userspace. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 13/16] cpuidle: free all state kobjects from cpuidle_free_state_kobj()
On 3 October 2013 21:26, Viresh Kumar viresh.ku...@linaro.org wrote:
Loop for states is currently present on callers side and so is replicated at
several places. It would be better to move that inside
cpuidle_free_state_kobj()
instead.
This patch does it.
Acked-by: Daniel Lezcano daniel.lezc...@linaro.org
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpuidle/sysfs.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
Hi Rafael,
You missed applying this one?
diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
index e918b6d..ade31a9 100644
--- a/drivers/cpuidle/sysfs.c
+++ b/drivers/cpuidle/sysfs.c
@@ -378,12 +378,17 @@ static struct kobj_type ktype_state_cpuidle = {
.release = cpuidle_state_sysfs_release,
};
-static inline void cpuidle_free_state_kobj(struct cpuidle_device *device,
int i)
+static inline void cpuidle_free_state_kobj(struct cpuidle_device *device,
+ int count)
{
- kobject_put(device-kobjs[i]-kobj);
- wait_for_completion(device-kobjs[i]-kobj_unregister);
- kfree(device-kobjs[i]);
- device-kobjs[i] = NULL;
+ int i;
+
+ for (i = 0; i count; i++) {
+ kobject_put(device-kobjs[i]-kobj);
+ wait_for_completion(device-kobjs[i]-kobj_unregister);
+ kfree(device-kobjs[i]);
+ device-kobjs[i] = NULL;
+ }
}
/**
@@ -419,8 +424,7 @@ static int cpuidle_add_state_sysfs(struct cpuidle_device
*device)
return 0;
error_state:
- for (i = i - 1; i = 0; i--)
- cpuidle_free_state_kobj(device, i);
+ cpuidle_free_state_kobj(device, i);
return ret;
}
@@ -430,10 +434,7 @@ error_state:
*/
static void cpuidle_remove_state_sysfs(struct cpuidle_device *device)
{
- int i;
-
- for (i = 0; i device-state_count; i++)
- cpuidle_free_state_kobj(device, i);
+ cpuidle_free_state_kobj(device, device-state_count);
}
#ifdef CONFIG_CPU_IDLE_MULTIPLE_DRIVERS
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 13/16] cpuidle: free all state kobjects from cpuidle_free_state_kobj()
Fixing Rafael's email id..
On 20 November 2013 13:33, Viresh Kumar viresh.ku...@linaro.org wrote:
On 3 October 2013 21:26, Viresh Kumar viresh.ku...@linaro.org wrote:
Loop for states is currently present on callers side and so is replicated at
several places. It would be better to move that inside
cpuidle_free_state_kobj()
instead.
This patch does it.
Acked-by: Daniel Lezcano daniel.lezc...@linaro.org
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpuidle/sysfs.c | 23 ---
1 file changed, 12 insertions(+), 11 deletions(-)
Hi Rafael,
You missed applying this one?
diff --git a/drivers/cpuidle/sysfs.c b/drivers/cpuidle/sysfs.c
index e918b6d..ade31a9 100644
--- a/drivers/cpuidle/sysfs.c
+++ b/drivers/cpuidle/sysfs.c
@@ -378,12 +378,17 @@ static struct kobj_type ktype_state_cpuidle = {
.release = cpuidle_state_sysfs_release,
};
-static inline void cpuidle_free_state_kobj(struct cpuidle_device *device,
int i)
+static inline void cpuidle_free_state_kobj(struct cpuidle_device *device,
+ int count)
{
- kobject_put(device-kobjs[i]-kobj);
- wait_for_completion(device-kobjs[i]-kobj_unregister);
- kfree(device-kobjs[i]);
- device-kobjs[i] = NULL;
+ int i;
+
+ for (i = 0; i count; i++) {
+ kobject_put(device-kobjs[i]-kobj);
+ wait_for_completion(device-kobjs[i]-kobj_unregister);
+ kfree(device-kobjs[i]);
+ device-kobjs[i] = NULL;
+ }
}
/**
@@ -419,8 +424,7 @@ static int cpuidle_add_state_sysfs(struct cpuidle_device
*device)
return 0;
error_state:
- for (i = i - 1; i = 0; i--)
- cpuidle_free_state_kobj(device, i);
+ cpuidle_free_state_kobj(device, i);
return ret;
}
@@ -430,10 +434,7 @@ error_state:
*/
static void cpuidle_remove_state_sysfs(struct cpuidle_device *device)
{
- int i;
-
- for (i = 0; i device-state_count; i++)
- cpuidle_free_state_kobj(device, i);
+ cpuidle_free_state_kobj(device, device-state_count);
}
#ifdef CONFIG_CPU_IDLE_MULTIPLE_DRIVERS
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [to-be-updated] mm-memcg-add-memoryoom_control-notification-for-system-oom.patch removed from -mm tree
On Tue, 19 Nov 2013, a...@linux-foundation.org wrote: Subject: [to-be-updated] mm-memcg-add-memoryoom_control-notification-for-system-oom.patch removed from -mm tree To: rient...@google.com,han...@cmpxchg.org,kamezawa.hir...@jp.fujitsu.com,mho...@suse.cz,mm-comm...@vger.kernel.org From: a...@linux-foundation.org Date: Tue, 19 Nov 2013 13:38:14 -0800 The patch titled Subject: mm, memcg: add memory.oom_control notification for system oom has been removed from the -mm tree. Its filename was mm-memcg-add-memoryoom_control-notification-for-system-oom.patch This patch was dropped because an updated version will be merged Why is this removed? I've laid out my perspective for doing userspace oom handling and this is a vital part for system oom handling. I know that we are currently discussing alternative proposals but my proposal is by far the most complete and allows the most powerful policies to be implemented in userspace. I'd prefer if we would keep the patch unless an actual alternative is proposed and agreed upon, we can still discuss alternatives while this in -mm and this patch in no way precludes other mechanisms from being implemented. So why remove this? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Regression x2, 3.13-git] virtio block mq hang, iostat busted on virtio devices
On Tue, Nov 19, 2013 at 02:43:51PM -0700, Jens Axboe wrote: No, the nr_requests isn't actually relevant in the blk-mq context, the driver sets its own depth. For the above, it's 64 normal commands, and 2 reserved. The reserved would be for a flush, for instance. If someone attempts to queue more than the allocated number of requests, it'll stop the blk-mq queue and kick things into gear on the virtio side. Then when requests complete, we start the queue again. Btw, any reason we lowerered the queue depth from 128 to 64 in virtio-blk? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 14/16] cpuidle: don't calculate time-diff if entered_state 0
On 3 October 2013 21:26, Viresh Kumar viresh.ku...@linaro.org wrote:
If entered_state 0, we don't need to set dev-last_residency to 'diff' as we
will be setting it to zero without using its new value.
And so move calculation of diff also inside the if statement.
Acked-by: Daniel Lezcano daniel.lezc...@linaro.org
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
drivers/cpuidle/cpuidle.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
Missed applying this one too?
diff --git a/drivers/cpuidle/cpuidle.c b/drivers/cpuidle/cpuidle.c
index b45257a..1a6e9f5 100644
--- a/drivers/cpuidle/cpuidle.c
+++ b/drivers/cpuidle/cpuidle.c
@@ -77,23 +77,22 @@ int cpuidle_enter_state(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
struct cpuidle_state *target_state = drv-states[index];
ktime_t time_start, time_end;
- s64 diff;
time_start = ktime_get();
entered_state = target_state-enter(dev, drv, index);
- time_end = ktime_get();
+ if (entered_state = 0) {
+ s64 diff;
- local_irq_enable();
+ time_end = ktime_get();
+ diff = ktime_to_us(ktime_sub(time_end, time_start));
- diff = ktime_to_us(ktime_sub(time_end, time_start));
- if (diff INT_MAX)
- diff = INT_MAX;
+ if (diff INT_MAX)
+ diff = INT_MAX;
- dev-last_residency = (int) diff;
+ dev-last_residency = (int) diff;
- if (entered_state = 0) {
/* Update cpuidle counters */
/* This can be moved to within driver enter routine
* but that results in multiple copies of same code.
@@ -104,6 +103,8 @@ int cpuidle_enter_state(struct cpuidle_device *dev,
struct cpuidle_driver *drv,
dev-last_residency = 0;
}
+ local_irq_enable();
+
return entered_state;
}
--
1.7.12.rc2.18.g61b472e
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Having troubles in updating MTD partitions
hi, i am trying to change mtd partition sizes, I am successfully able to change size of mtdblock as u can see cat /proc/partitions major minor #blocks name 31 0 8192 mtdblock0 31 1 256 mtdblock1 31 2 2048 mtdblock2 31 3 5884 mtdblock3 31 4 4 mtdblock4 but when i try to use memory relevant tools, it shows me something like # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/root 5824 5824 0 100% / 5824 was the previous size of mtdblock3 all i have done is build rootfs with size 5884*1024 and update mtd partition array in kernel, build jffs2 and burn jffs2 in device there is one more thing, Can any one tell me how i can change eraseblock for a partition, i believe i also having wrong eraseblock for mtdblock3 any help would be appreciative... thanks -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Regression x2, 3.13-git] virtio block mq hang, iostat busted on virtio devices
Just stumbled on that too. You need one more, btw, for the sg failure
case:
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 588479d58f52..6a680d4de7f1 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -199,15 +199,16 @@ static int virtio_queue_rq(struct blk_mq_hw_ctx *hctx,
struct request *req)
spin_lock_irqsave(vblk-vq_lock, flags);
if (__virtblk_add_req(vblk-vq, vbr, vbr-sg, num) 0) {
+ virtqueue_kick(vblk-vq);
spin_unlock_irqrestore(vblk-vq_lock, flags);
blk_mq_stop_hw_queue(hctx);
- virtqueue_kick(vblk-vq);
return BLK_MQ_RQ_QUEUE_BUSY;
}
- spin_unlock_irqrestore(vblk-vq_lock, flags);
if (last)
virtqueue_kick(vblk-vq);
+
+ spin_unlock_irqrestore(vblk-vq_lock, flags);
Note that virtqueue_kick can be split into a virtqueue_prepare_split
that needs the lock, and a virtqueue_notify that doesn't, but it might
not be nessecary to do that optimization right now.
Btw, how much do I need to bribe you to send mails where I don't have
step over 500 lines of dead quotes to find the actual patch?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 0/3] Add dirty-tracking infrastructure for non-page-backed address spaces
On 11/19/2013 11:51 PM, Andy Lutomirski wrote: On 11/19/2013 12:06 PM, Thomas Hellstrom wrote: Hi! Before going any further with this I'd like to check whether this is an acceptable way to go. Background: GPU buffer objects in general and vmware svga GPU buffers in particular are mapped by user-space using MIXEDMAP or PFNMAP. Sometimes the address space is backed by a set of pages, sometimes it's backed by PCI memory. In the latter case in particular, there is no way to track dirty regions using page_mkwrite() and page_mkclean(), other than allocating a bounce buffer and perform dirty tracking on it, and then copy data to the real GPU buffer. This comes with a big memory- and performance overhead. So I'd like to add the following infrastructure with a callback pfn_mkwrite() and a function mkclean_mapping_range(). Typically we will be cleaning a range of ptes rather than random ptes in a vma. This comes with the extra benefit of being usable when the backing memory of the GPU buffer is not coherent with the GPU itself, and where we either need to flush caches or move data to synchronize. So this is a RFC for 1) The API. Is it acceptable? Any other suggestions if not? 2) Modifying apply_to_page_range(). Better to make a standalone non-populating version? 3) tlb- mmu- and cache-flushing calls. I've looked at unmap_mapping_range() and page_mkclean_one() to try to get it right, but still unsure. Most (all?) architectures have real dirty tracking -- you can mark a pte as clean and the hardware (or arch code) will mark it dirty when written, *without* a page fault. I'm not convinced that it works completely correctly right now (I suspect that there are some TLB flushing issues on the dirty-clean transition), and it's likely prone to bit-rot, since the page cache doesn't rely on it. That being said, using hardware dirty tracking should be *much* faster and less latency-inducing than doing it in software like this. It may be worth trying to get HW dirty tracking working before adding more page fault-based tracking. (I think there's also some oddity on S/390. I don't know what that oddity is or whether you should care.) --Andy Andy, Thanks for the tip. It indeed sounds interesting, however there are a couple of culprits: 1) As you say, it sounds like there might be TLB flushing issues. Let's say the TLB detects a write and raises an IRQ for the arch code to set the PTE dirty bit, and before servicing that interrupt, we clear the PTE and flush that TLB. What will happen? And if the TLB hardware would write directly to the in-memory PTE I guess we'd have the same synchronization issues. I guess we'd then need an atomic read-modify-write against the TLB hardware? 2) Even if most hardware is capable of this stuff, I'm not sure what would happen in a virtual machine. Need to check. 3) For dirty contents that need to appear on a screen within a short interval, we need the write notification anyway, to start a delayed task that will gather the dirty data and flush it to the screen... Thanks, /Thomas -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/05] ARM: shmobile: r8a7790 and r8a7791 thermal update
Hi ARM: shmobile: r8a7790 and r8a7791 thermal update [PATCH 01/05] ARM: shmobile: Add r8a7790 thermal device node to DTS [PATCH 02/05] ARM: shmobile: Add r8a7790 clocks for thermal devices [PATCH 03/05] ARM: shmobile: Add r8a7791 thermal device node to DTS [PATCH 04/05] ARM: shmobile: Add r8a7791 thermal platform device [PATCH 05/05] ARM: shmobile: Add r8a7791 clocks for thermal devices Update the thermal support for the r8a7790 and the r8a7791 SoCs. As usual the code is split between the DT reference code and the legacy case. The DT reference code is written to be multiplatform aware and is used to point out the future direction. Hardware support may however be limited there due to lacking DT bindings. For all patches Acked-by: Kuninori Morimoto kuninori.morimoto...@renesas.com Best regards --- Kuninori Morimoto -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] mmc: rtsx: modify phase searching method for tunning
On Tue, Nov 19, 2013 at 07:10:35PM +0800, micky_ch...@realsil.com.cn wrote:
-static u8 sd_search_final_phase(struct realtek_pci_sdmmc *host, u32
phase_map)
+static inline u32 sd_get_phase_point(u32 phase_map, unsigned int idx)
{
- struct timing_phase_path path[MAX_PHASE + 1];
- int i, j, cont_path_cnt;
- int new_block, max_len, final_path_idx;
- u8 final_phase = 0xFF;
+ idx = MAX_PHASE;
+ return phase_map (1 idx);
+}
+
This function is confusing
MAX_PHASE is a terrible name. It's in a global header but it doesn't
have a prefix. It should be #define RTS_MAX_PHASE. It's weird that we
are using it both as a number and as bit mask. It's weird that we
always add a + 1 to MAX_PHASE. It means the name is chosen poorly.
Maybe it should be:
#define RTS_MAX_PHASE 32
#define RTS_PHASE_MASK 0x1f
So this function takes a phase_map and an index and it wraps the index
by masking away the top bits then it tests to see if the wrapped index
bit is set? The wrapping is very strange.
The name of the function is sd_get_phase_point() but we only test to
see if it returns zero. The name of the function is not helpful.
sd is a generic prefix.
get is misleading because we don't get anything it only returns zero
on success?
phase_point might be helpful but I don't know what a phase_point is.
Add a comment about that maybe.
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, efi: change name of efi_no_storage_paranoia parameter to efi_storage_paranoia
於 三，2013-11-20 於 15:26 +0900，Yasuaki Ishimatsu 提到： (2013/11/19 12:16), Madper Xie wrote: isimatu.yasu...@jp.fujitsu.com writes: Hi Matt, Sorry for late the reply. (2013/11/11 19:54), Matt Fleming wrote: On Mon, 11 Nov, at 05:52:59PM, Yasuaki Ishimatsu wrote: Hi Matt, I uses FUJITSU's x86 box. This does not become bricked even if I use all efi variable storage. Thus I want a way to not need to specify efi_no_storage_paranoia parameter. The efi_no_storage_paranoia parameter was introduced because some machines do not initiate garbage collection of the NVRAM until you allocate all space - basically it's a switch to turn off the save 5KB of stoarge at all times workaround that is needed to avoid bricking some machines. The intention of the switch is not to allow you to fill your NVRAM just because you can. If that is something you want to do then I think it's fair to require you to explicitly turn on efi_no_storage_paranoia. But I'm assuming here that you are doing something like writing lots and lots of pstore entries and just want to write as many as your variable storage will allow? Or are you doing something more fundamental like creating Boot entries? What are you doing to run into the 5KB reserve? How much NVRAM does your machine come with? I just add boot entry to NVRAM by efibootmgr command. But when Linux boots up, the remaining NVRAM is less than 5Kbyte. So I cannnot add new entry. Howdy Yasuaki, If the remaining NVRAM is less than 5Kb, your writing will trigger a NVRAM storage reclamation. However you still failed creating entry. So I'm just curious what itmes occupy lots of nvram storage space. Even if we got EFI_OUT_OF_RESOURCES while running Linux, gc does not run. Trigger of gc is when EFI_OUT_OF_RESOURCES occurs on pre OS environment with UEFI. So on my system, if EFI_OUT_OF_RESOURCES occurs by the 5Kbyte threshold, we cannot use nvram storage until EFI_OUT_OF_RESOURCES occurs on pre OS environment with UEFI. Thanks, Yasuaki Ishimatsu Can we try to trigger gc by EFI_OUT_OF_RESOURCE in EFI stub kernel or EFI boot loader to recover NVRAM space? Does work with the BIOS on this machine? Thanks a lot! Joey Lee -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] scripts: Have make TAGS not include structure members
On Sun, Nov 17, 2013 at 6:08 PM, Steven Rostedt rost...@goodmis.org wrote:
On Sun, 17 Nov 2013 16:19:53 +0100
Geert Uytterhoeven ge...@linux-m68k.org wrote:
Thanks! Now I have to look into my vim setup, why it doesn't do the
above...
$ vim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Sep 11 2013 12:28:07)
I have 7.3.
And from the ctags man pages, I did:
:ta dev_name
and it gave me a list of tags.
Not for me.
# pri kind tag file
1 F mdev_name drivers/clk/samsung/clk.h
struct:samsung_clock_alias
const char *dev_name;
I do remember seeing such a list on a different machine, though.
However, this encouraged me to dive into some docs.
:ts tag (or just :ts after a previous :ta) does give me the list.
The same for g CTRL-] instead of plain CTRL-], so I'm happy now ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/7] Squashfs: add multi-threaded decompression using percpu variables (V2)
On Wed, Nov 20, 2013 at 01:48:06AM +, Phillip Lougher wrote: Add a multi-threaded decompression implementation which uses percpu variables. Using percpu variables has advantages and disadvantages over implementations which do not use percpu variables. Advantages: * the nature of percpu variables ensures decompression is load-balanced across the multiple cores. * simplicity. Disadvantages: it limits decompression to one thread per core. V2: * squashfs_decompressor_create: improve error handling path, re freeing of decompressors and comp_opts * decompressor_multi_percpu.c: include percpu.h header * Kconfig: indentation Signed-off-by: Phillip Lougher phil...@squashfs.org.uk --- fs/squashfs/Kconfig | 57 ++- fs/squashfs/Makefile| 10 +--- fs/squashfs/decompressor_multi_percpu.c | 98 + 3 files changed, 145 insertions(+), 20 deletions(-) create mode 100644 fs/squashfs/decompressor_multi_percpu.c diff --git a/fs/squashfs/Kconfig b/fs/squashfs/Kconfig index 1c6d340..159bd66 100644 --- a/fs/squashfs/Kconfig +++ b/fs/squashfs/Kconfig @@ -25,6 +25,50 @@ config SQUASHFS If unsure, say N. +choice + prompt Decompressor parallelisation options Nitpick: How about adding default explicitly? default SQUASHFS_DECOMP_SINGLE + depends on SQUASHFS + help + Squashfs now supports three parallelisation options for + decompression. Each one exhibits various trade-offs between + decompression performance and CPU and memory usage. + + If in doubt, select Single threaded compression + +config SQUASHFS_DECOMP_SINGLE + bool Single threaded compression + help + Traditionally Squashfs has used single-threaded decompression. + Only one block (data or metadata) can be decompressed at any + one time. This limits CPU and memory usage to a minimum. + +config SQUASHFS_DECOMP_MULTI + bool Use multiple decompressors for parallel I/O + help + By default Squashfs uses a single decompressor but it gives + poor performance on parallel I/O workloads when using multiple CPU + machines due to waiting on decompressor availability. + + If you have a parallel I/O workload and your system has enough memory, + using this option may improve overall I/O performance. + + This decompressor implementation uses up to two parallel + decompressors per core. It dynamically allocates decompressors + on a demand basis. + +config SQUASHFS_DECOMP_MULTI_PERCPU + bool Use percpu multiple decompressors for parallel I/O + help + By default Squashfs uses a single decompressor but it gives + poor performance on parallel I/O workloads when using multiple CPU + machines due to waiting on decompressor availability. + + This decompressor implementation uses a maximum of one + decompressor per core. It uses percpu variables to ensure Minor: ^ unnecessary white space. + decompression is load-balanced across the cores. Actually, I am not sure it's good idea to mention percpu in description. Normal people wouldn't know that and I think what they can want to know is what's benefit compared to SQUASHFS_DECOMP_MULTI. How about this? This decompressor implementation uses a maximum of one decompressor per core and the decompressor is allocated statically so memory footprint is small and limited and I/O cannot be fluctuated by not failing decompressor dynamic allocation compared to SQUAHSDS_DECOMP_MULTI. And I'd like to see what's your point about decompression is load-balanced across the cores. If scheduler assigns process A, B, C into a core, it couldn't be load-balanced. If scheduler assign process A, B, C into each core, it could be load-balanced. And it's same with SQUSHFS_DECOMP_MULTI. Could you elaborate it a bit? Otherwise, looks good to me. Thanks! + +endchoice + config SQUASHFS_XATTR bool Squashfs XATTR support depends on SQUASHFS @@ -63,19 +107,6 @@ config SQUASHFS_LZO If unsure, say N. -config SQUASHFS_MULTI_DECOMPRESSOR - bool Use multiple decompressors for handling parallel I/O - depends on SQUASHFS - help - By default Squashfs uses a single decompressor but it gives - poor performance on parallel I/O workloads when using multiple CPU - machines due to waiting on decompressor availability. - - If you have a parallel I/O workload and your system has enough memory, - using this option may improve overall I/O performance. - - If unsure, say N. - config SQUASHFS_XZ bool Include support for XZ compressed file systems depends on SQUASHFS diff --git
Re: [PATCH v2 01/03] clocksource: Add Kconfig entries for CMT, MTU2, TMU and STI
On 11/14/2013 01:40 PM, Arnd Bergmann wrote: On Wednesday 13 November 2013, John Stultz wrote: +config EM_TIMER_STI + bool STI timer driver + default y if ARM + help + This enables build of the STI timer driver. So since I do want to avoid adding user-selectable configs if possible, here are some concrete thoughts on this patch, trying to provide an example from my more abstract rants down thread. :) I think we should be using the CONFIG_BUILD_TEST (or whatever it's called) here to allow building the drivers everywhere but at the same time be specific with the platform. How about this: config EM_TIMER_STI bool Renesas EMMA EV2 STI timer driver if BUILD_TEST !ARCH_EMEV2 default ARCH_EMEV2 help ... This makes it a silent option that is set correctly all the time but lets you enable it everywhere when BUILD_TEST is set. It sounds like a good compromise. We could skip the !ARCH_EMEV2 part to allow building an EMEV2 kernel without this driver when build testing if that is possible. -- http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs Follow Linaro: http://www.facebook.com/pages/Linaro Facebook | http://twitter.com/#!/linaroorg Twitter | http://www.linaro.org/linaro-blog/ Blog -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86, efi: add no_bricked_efi whitelist
By following works, my system very often fails set_variable() to set new
variable to efi variable storage and shows efivars: set_variable() failed:
status=-28 message.
- commit 68d929862e29a8b52a7f2f2f86a0600423b093cd
efi: be more paranoid about available space when creating variables
- commit 31ff2f20d9003e74991d135f56e503fe776c127c
efi: Distinguish between remaining space and actually used space
- commit 8c58bf3eec3b8fc8162fe557e9361891c20758f2
x86,efi: Implement efi_no_storage_paranoia parameter
- commit f8b8404337de4e2466e2e1139ea68b1f8295974f
Modify UEFI anti-bricking code
When booting my system, remaining space of efi variable storage is about
5KB. So there is no room that sets a new variable to the storage. On my
system, trigger of gc is when EFI_OUT_OF_RESOURCES occurs on pre OS
environment with UEFI. So if EFI_OUT_OF_RESOURCES occurs by the 5Kbyte
threshold, nvram storage cannot be used until EFI_OUT_OF_RESOURCES occurs
on pre OS environment with UEFI.
This patch adds whitelist. If a server is in the whitelist,
efi_no_storage_paranoia is set to true. And the system can use all efi
variable storage.
Signed-off-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
CC: Matthew Garrett matthew.garr...@nebula.com
CC: Richard Weinberger rich...@nod.at
CC: Lee, Chun-Y j...@suse.com
CC: Madper Xie c...@redhat.com
CC: Matt Fleming matt.flem...@intel.com
---
arch/x86/platform/efi/efi.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index c7e22ab..9fadf5d 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -116,6 +116,15 @@ static int __init setup_storage_paranoia(char *arg)
}
early_param(efi_no_storage_paranoia, setup_storage_paranoia);
+struct no_bricked_efi {
+ char vendor[100];
+ u32 revision;
+};
+
+static struct no_bricked_efi efi_whitelist[] __initdata = {
+ {FUJITSU LIMITED, 0},
+ {}
+};
static efi_status_t virt_efi_get_time(efi_time_t *tm, efi_time_cap_t *tc)
{
@@ -704,6 +713,24 @@ static int __init efi_memmap_init(void)
return 0;
}
+static bool __init is_no_bricked_efi(char *vendor, u32 revision)
+{
+ int i = 0;
+
+ while (efi_whitelist[i].vendor[0] != '\0') {
+ if (strncmp(efi_whitelist[i].vendor, vendor,
+ sizeof(efi_whitelist[i].vendor))) {
+ i++;
+ continue;
+ }
+
+ if (revision = efi_whitelist[i].revision)
+ return true;
+ }
+
+ return false;
+}
+
void __init efi_init(void)
{
efi_char16_t *c16;
@@ -778,6 +805,8 @@ void __init efi_init(void)
#if EFI_DEBUG
print_efi_memmap();
#endif
+ if (is_no_bricked_efi(vendor, efi.systab-hdr.revision))
+ efi_no_storage_paranoia = true;
}
void __init efi_late_init(void)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[f2fs-dev] [PATCH 2/2] f2fs: adds a tracepoint for f2fs_submit_read_bio
This patch adds a tracepoint for f2fs_submit_read_bio.
Signed-off-by: Chao Yu chao2...@samsung.com
---
fs/f2fs/data.c |2 ++
include/trace/events/f2fs.h | 27 +++
2 files changed, 29 insertions(+)
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 0ca93be..c9e9d79 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -407,6 +407,8 @@ void f2fs_submit_read_bio(struct f2fs_sb_info *sbi, int rw)
if (!io-bio)
return;
+ trace_f2fs_submit_read_bio(sbi-sb, rw, io-bio);
+
mutex_lock(io-io_mutex);
if (io-bio) {
submit_bio(rw, io-bio);
diff --git a/include/trace/events/f2fs.h b/include/trace/events/f2fs.h
index 571f39a..ac970e3 100644
--- a/include/trace/events/f2fs.h
+++ b/include/trace/events/f2fs.h
@@ -453,6 +453,33 @@ TRACE_EVENT_CONDITION(f2fs_readpage,
show_bio_type(__entry-type))
);
+TRACE_EVENT(f2fs_submit_read_bio,
+
+ TP_PROTO(struct super_block *sb, int rw, struct bio *bio),
+
+ TP_ARGS(sb, rw, bio),
+
+ TP_STRUCT__entry(
+ __field(dev_t, dev)
+ __field(int,rw)
+ __field(sector_t, sector)
+ __field(unsigned int, size)
+ ),
+
+ TP_fast_assign(
+ __entry-dev= sb-s_dev;
+ __entry-rw = rw;
+ __entry-sector = bio-bi_sector;
+ __entry-size = bio-bi_size;
+ ),
+
+ TP_printk(dev = (%d,%d), bio_type = %s, sector = %lld, size = %u,
+ show_dev(__entry),
+ show_bio_type(__entry-rw),
+ (unsigned long long)__entry-sector,
+ __entry-size)
+);
+
TRACE_EVENT(f2fs_submit_read_page,
TP_PROTO(struct page *page, block_t blk_addr, int rw),
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[f2fs-dev] [PATCH 1/2] f2fs: adds a tracepoint for submit_read_page
This patch adds a tracepoint for submit_read_page. Signed-off-by: Chao Yu chao2...@samsung.com --- fs/f2fs/data.c |1 + include/trace/events/f2fs.h | 30 ++ 2 files changed, 31 insertions(+) diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c index 9cf3f6c..0ca93be 100644 --- a/fs/f2fs/data.c +++ b/fs/f2fs/data.c @@ -448,6 +448,7 @@ alloc_new: io-last_block_in_bio = blk_addr; mutex_unlock(io-io_mutex); + trace_f2fs_submit_read_page(page, blk_addr, rw); } /* diff --git a/include/trace/events/f2fs.h b/include/trace/events/f2fs.h index e0dc355..571f39a 100644 --- a/include/trace/events/f2fs.h +++ b/include/trace/events/f2fs.h @@ -453,6 +453,36 @@ TRACE_EVENT_CONDITION(f2fs_readpage, show_bio_type(__entry-type)) ); +TRACE_EVENT(f2fs_submit_read_page, + + TP_PROTO(struct page *page, block_t blk_addr, int rw), + + TP_ARGS(page, blk_addr, rw), + + TP_STRUCT__entry( + __field(dev_t, dev) + __field(ino_t, ino) + __field(int, rw) + __field(pgoff_t, index) + __field(block_t, block) + ), + + TP_fast_assign( + __entry-dev= page-mapping-host-i_sb-s_dev; + __entry-ino= page-mapping-host-i_ino; + __entry-rw = rw; + __entry-index = page-index; + __entry-block = blk_addr; + ), + + TP_printk(dev = (%d,%d), ino = %lu, bio_type = %s, + index = %lu, blkaddr = 0x%llx, + show_dev_ino(__entry), + show_bio_type(__entry-rw), + (unsigned long)__entry-index, + (unsigned long long)__entry-block) +); + TRACE_EVENT(f2fs_get_data_block, TP_PROTO(struct inode *inode, sector_t iblock, struct buffer_head *bh, int ret), -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Tomasz, On Sun, Nov 10, 2013 at 7:38 PM, Tomasz Figa tomasz.f...@gmail.com wrote: Hi Vivek, On Thursday 31 of October 2013 13:15:41 Vivek Gautam wrote: Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs. The new driver uses the generic PHY framework and will interact with DWC3 controller present on Exynos5 series of SoCs. Signed-off-by: Vivek Gautam gautam.vi...@samsung.com --- .../devicetree/bindings/phy/samsung-phy.txt| 20 + drivers/phy/Kconfig|7 + drivers/phy/Makefile |1 + drivers/phy/phy-exynos5-usb3.c | 562 4 files changed, 590 insertions(+), 0 deletions(-) create mode 100644 drivers/phy/phy-exynos5-usb3.c diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt index c0fccaa..9b5c111 100644 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt @@ -20,3 +20,23 @@ Required properties: - compatible : should be samsung,exynos5250-dp-video-phy; - reg : offset and length of the Display Port PHY register set; - #phy-cells : from the generic PHY bindings, must be 0; + +Samsung Exynos5 SoC seiries USB 3.0 PHY controller typo: s/seiries/series/ will correct it. +-- + +Required properties: +- compatible : + should be samsung,exynos5250-usb3phy for exynos5250 SoC + should be samsung,exynos5420-usb3phy for exynos5420 SoC I'd slightly change this into something like this: - compatible: Should be set to one of following supported values: - samsung,exynos5250-usb3phy - for Exynos5250 SoC, - samsung,exynos5420-usb3phy - for Exynos5420 SoC. sure, will make it as suggested. +- reg : Register offset and length array + - first field corresponds to USB 3.0 PHY register set; + - second field corresponds to PHY power isolation register + present in PMU; For consistency and to make things more future-proof, you should consider using the PMU indirectly, through the syscon interface, as done in Leela Krishna Amudala's series[1] in case of watchdog driver. Right that's a better way to do. But this will again introduce the register offset arithmetic once again. And in case of multiple USB 3.0 PHY controllers (like for Exynos5420), we would need to take extra care of each such offset, by having provision for aliases for the usb3phy nodes and then setting required offset before doing isolation. For Exynos5420 USB3.0 PHY channel 0 is controlled by 0x10040704; and USB3.0 PHY channel 1 is controlled by 0x10040708. I will tell Kamil to do the same for USB 2.0 PHY as well. [1] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/24652 +- clocks: Clock IDs array as required by the controller +- clock-names: names of clocks correseponding to IDs in the clock property; + Required clocks: + - first clock is main PHY clock (same as USB 3.0 controller IP clock) + - second clock is reference clock (usually crystal clock) + optional clock: + - third clock is special clock used by PHY for operation Is this clock really optional? It looks like it's required for Exynos5420. Yes, this clock is an additional clock for Exynos5420 rather then being just optional If so, you should instead change this to: Additional clocks required for Exynos5420: Ok will change this. Also you have not specified names of the clocks, just what they are. Please remember that those are input names, so you can imagine them as names of clock input pins of the IP block, not SoC-level clock names. So you mean, similar to what driver requests (clocks with their input names) ? will add clock names. +- #phy-cells : from the generic PHY bindings, must be 0; I'd also add an example of correct USB 3.0 PHY device tree node here. Sorry, forgot to add an example of the device node :-) will add one. diff --git a/drivers/phy/phy-exynos5-usb3.c b/drivers/phy/phy-exynos5-usb3.c new file mode 100644 index 000..b9a2674 --- /dev/null +++ b/drivers/phy/phy-exynos5-usb3.c @@ -0,0 +1,562 @@ [snip] +#define EXYNOS5_DRD_PHYRESUME(0x34) +#define EXYNOS5_DRD_LINKPORT (0x44) + + nit: Duplicate blank line. will remove it. +/* Isolation, configured in the power management unit */ +#define EXYNOS5_USB_ISOL_DRD (1 0) + +#define CLKSEL_ERROR -1 What's this? Hmm..i shouldn't be defining error codes out of blue, will remove it. + +#ifndef KHZ +#define KHZ 1000 +#endif + +#ifndef MHZ +#define MHZ (KHZ * KHZ) +#endif Do you really need the #ifndef's above? You are right. #ifndef not really needed, since no header included here have these definitions. Although for samsung i can see they are defined in
Re: [PATCH 34/34] mm: dynamically allocate page-ptl if it cannot be embedded to struct page
Hi Kirill, Looks like this patch adds memory leaks. [ 116.188310] kmemleak: 15672 new suspected memory leaks (see /sys/kernel/debug/kmemleak) unreferenced object 0x8800da45a350 (size 96): comm dracut-initqueu, pid 93, jiffies 4294671391 (age 362.277s) hex dump (first 32 bytes): 07 00 07 00 ad 4e ad de ff ff ff ff 6b 6b 6b 6b .N.. ff ff ff ff ff ff ff ff 80 24 b4 82 ff ff ff ff .$.. backtrace: [817152fe] kmemleak_alloc+0x5e/0xc0 [811c34f3] kmem_cache_alloc_trace+0x113/0x290 [811920f7] __ptlock_alloc+0x27/0x50 [81192849] __pmd_alloc+0x59/0x170 [81195ffa] copy_page_range+0x38a/0x3e0 [8105a013] dup_mm+0x313/0x540 [8105b9da] copy_process+0x161a/0x1880 [8105c01b] do_fork+0x8b/0x360 [8105c306] SyS_clone+0x16/0x20 [81727b79] stub_clone+0x69/0x90 [] 0x It's quite serious, because my test host went to panic in a few hours. [12000.632734] kmemleak: 74155 new suspected memory leaks (see /sys/kernel/debug/kmemleak) [12080.734075] zombie00[29282]: segfault at 0 ip 00401862 sp 7fffc509bc20 error 6 in zombie00[40+5000] [12619.799052] BUG: unable to handle kernel paging request at 7aa9e3a0 [12619.800044] IP: [810b2c07] cpuacct_charge+0x97/0x1e0 [12619.800044] PGD 0 [12619.800044] Thread overran stack, or stack corrupted [12619.800044] Oops: [#1] SMP [12619.800044] Modules linked in: binfmt_misc ip6table_filter ip6_tables tun netlink_diag af_packet_diag udp_diag tcp_diag inet_diag unix_diag joydev microcode pcspkr i2c_piix4 virtio_balloon virtio_net i2c_core virtio_blk floppy [12619.800044] CPU: 1 PID: 1324 Comm: kworker/u4:2 Not tainted 3.12.0+ #142 [12619.800044] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2007 [12619.800044] Workqueue: writeback bdi_writeback_workfn (flush-252:0) [12619.800044] task: 88001f1a8000 ti: 880096f26000 task.ti: 880096f26000 [12619.800044] RIP: 0010:[810b2c07] [810b2c07] cpuacct_charge+0x97/0x1e0 [12619.800044] RSP: 0018:88011b403ce8 EFLAGS: 00010002 [12619.800044] RAX: d580 RBX: 000f11b1 RCX: 0003 [12619.800044] RDX: 81c49e40 RSI: 81c4bb00 RDI: 88001f1a8c68 [12619.800044] RBP: 88011b403d18 R08: 0001 R09: 0001 [12619.800044] R10: 0001 R11: 0007 R12: 88001f1a8000 [12619.800044] R13: 1f1a8000 R14: 82a86320 R15: 06b1bda1e433 [12619.800044] FS: () GS:88011b40() knlGS: [12619.800044] CS: 0010 DS: ES: CR0: 8005003b [12619.800044] CR2: 7aa9e3a0 CR3: 01c0b000 CR4: 06e0 [12619.800044] Stack: [12619.800044] 810b2b70 0002 88011b5d40c0 000f11b1 [12619.800044] 88001f1a8068 88001f1a8000 88011b403d58 810a108f [12619.800044] 88011b403d88 88001f1a8068 88011b5d40c0 88011b5d4000 [12619.800044] Call Trace: [12619.800044] IRQ [12619.800044] [810b2b70] ? cpuacct_css_alloc+0xb0/0xb0 [12619.800044] [810a108f] update_curr+0x13f/0x230 [12619.800044] [810a9e57] task_tick_fair+0x2d7/0x650 [12619.800044] [8109dcc8] ? sched_clock_cpu+0xb8/0x120 [12619.800044] [8109482d] scheduler_tick+0x6d/0xf0 [12619.800044] [8106afd1] update_process_times+0x61/0x80 [12619.800044] [810e38c7] tick_sched_handle+0x37/0x80 [12619.800044] [810e3e74] tick_sched_timer+0x54/0x90 [12619.800044] [8108bd21] __run_hrtimer+0x71/0x2d0 [12619.800044] [810e3e20] ? tick_nohz_handler+0xc0/0xc0 [12619.800044] [8108c246] hrtimer_interrupt+0x116/0x2a0 [12619.800044] [81062959] ? __local_bh_enable+0x49/0x70 [12619.800044] [81033dcb] local_apic_timer_interrupt+0x3b/0x60 [12619.800044] [81727c05] smp_apic_timer_interrupt+0x45/0x60 [12619.800044] [8172686f] apic_timer_interrupt+0x6f/0x80 [12619.800044] EOI [12619.800044] [810b8e10] ? mark_held_locks+0x90/0x150 [12619.800044] [8171c6f2] ? _raw_spin_unlock_irqrestore+0x42/0x70 [12619.800044] [a001b71b] virtio_queue_rq+0xdb/0x1b0 [virtio_blk] [12619.800044] [8134647a] __blk_mq_run_hw_queue+0x1ca/0x520 [12619.800044] [81346b35] blk_mq_run_hw_queue+0x35/0x40 [12619.800044] [813470f2] blk_mq_insert_requests+0xe2/0x190 [12619.800044] [813472d4] blk_mq_flush_plug_list+0x134/0x150 [12619.800044] [8133d0cd] blk_flush_plug_list+0xbd/0x220 [12619.800044] [81346f1a] blk_mq_make_request+0x3da/0x4d0 [12619.800044] [813397aa] generic_make_request+0xca/0x100 [12619.800044] [81339856] submit_bio+0x76/0x160 [12619.800044] [81173c66] ? test_set_page_writeback+0x36/0x2b0 [12619.800044] [811a9ae0] ?
[PATCH] doc: fix generation of device-drivers
Since commit 7a6354e241d8 (sched: Move wait.c into kernel/sched/), the path of this file has changed. CC: Peter Zijlstra pet...@infradead.org CC: Ingo Molnar mi...@kernel.org Signed-off-by: Nicolas Dichtel nicolas.dich...@6wind.com --- Documentation/DocBook/device-drivers.tmpl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/DocBook/device-drivers.tmpl b/Documentation/DocBook/device-drivers.tmpl index 6c9d9d37c83a..f5170082bdb3 100644 --- a/Documentation/DocBook/device-drivers.tmpl +++ b/Documentation/DocBook/device-drivers.tmpl @@ -58,7 +58,7 @@ /sect1 sect1titleWait queues and Wake events/title !Iinclude/linux/wait.h -!Ekernel/wait.c +!Ekernel/sched/wait.c /sect1 sect1titleHigh-resolution timers/title !Iinclude/linux/ktime.h -- 1.8.4.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Having troubles in updating MTD partitions
On Wed, Nov 20, 2013 at 8:59 AM, Suki Buryani sukibury...@yahoo.com wrote:
31 3 5884 mtdblock3
5884 is the raw size of mtdblock3.
but when i try to use memory relevant tools, it shows me something like
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 5824 5824 0 100% /
5824 is the usable size of the file system on mtdblock3, i.e. after subtracting
the overhead for file system bookkeeping.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] xen: tmem: rmove useless parameters
tmem only takes a page as unit, so parameters tmem_offset, pfn_offset and len
are meanless, this patch remove those always 0 parameters.
Signed-off-by: Bob Liu bob@oracle.com
---
drivers/xen/tmem.c | 18 ++
1 file changed, 6 insertions(+), 12 deletions(-)
diff --git a/drivers/xen/tmem.c b/drivers/xen/tmem.c
index 83b5c53..9fd0fdc 100644
--- a/drivers/xen/tmem.c
+++ b/drivers/xen/tmem.c
@@ -89,7 +89,7 @@ struct tmem_oid {
/* xen tmem foundation ops/hypercalls */
static inline int xen_tmem_op(u32 tmem_cmd, u32 tmem_pool, struct tmem_oid oid,
- u32 index, unsigned long gmfn, u32 tmem_offset, u32 pfn_offset, u32 len)
+ u32 index, unsigned long gmfn)
{
struct tmem_op op;
int rc = 0;
@@ -100,9 +100,6 @@ static inline int xen_tmem_op(u32 tmem_cmd, u32 tmem_pool,
struct tmem_oid oid,
op.u.gen.oid[1] = oid.oid[1];
op.u.gen.oid[2] = oid.oid[2];
op.u.gen.index = index;
- op.u.gen.tmem_offset = tmem_offset;
- op.u.gen.pfn_offset = pfn_offset;
- op.u.gen.len = len;
set_xen_guest_handle(op.u.gen.gmfn, (void *)gmfn);
rc = HYPERVISOR_tmem_op(op);
return rc;
@@ -133,8 +130,7 @@ static int xen_tmem_put_page(u32 pool_id, struct tmem_oid
oid,
{
unsigned long gmfn = xen_pv_domain() ? pfn_to_mfn(pfn) : pfn;
- return xen_tmem_op(TMEM_PUT_PAGE, pool_id, oid, index,
- gmfn, 0, 0, 0);
+ return xen_tmem_op(TMEM_PUT_PAGE, pool_id, oid, index, gmfn);
}
static int xen_tmem_get_page(u32 pool_id, struct tmem_oid oid,
@@ -142,19 +138,17 @@ static int xen_tmem_get_page(u32 pool_id, struct tmem_oid
oid,
{
unsigned long gmfn = xen_pv_domain() ? pfn_to_mfn(pfn) : pfn;
- return xen_tmem_op(TMEM_GET_PAGE, pool_id, oid, index,
- gmfn, 0, 0, 0);
+ return xen_tmem_op(TMEM_GET_PAGE, pool_id, oid, index, gmfn);
}
static int xen_tmem_flush_page(u32 pool_id, struct tmem_oid oid, u32 index)
{
- return xen_tmem_op(TMEM_FLUSH_PAGE, pool_id, oid, index,
- 0, 0, 0, 0);
+ return xen_tmem_op(TMEM_FLUSH_PAGE, pool_id, oid, index, 0);
}
static int xen_tmem_flush_object(u32 pool_id, struct tmem_oid oid)
{
- return xen_tmem_op(TMEM_FLUSH_OBJECT, pool_id, oid, 0, 0, 0, 0, 0);
+ return xen_tmem_op(TMEM_FLUSH_OBJECT, pool_id, oid, 0, 0);
}
@@ -163,7 +157,7 @@ static int xen_tmem_destroy_pool(u32 pool_id)
{
struct tmem_oid oid = { { 0 } };
- return xen_tmem_op(TMEM_DESTROY_POOL, pool_id, oid, 0, 0, 0, 0, 0);
+ return xen_tmem_op(TMEM_DESTROY_POOL, pool_id, oid, 0, 0);
}
/* cleancache ops */
--
1.7.10.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, efi: add no_bricked_efi whitelist
Am Mittwoch, 20. November 2013, 17:34:18 schrieb Yasuaki Ishimatsu:
By following works, my system very often fails set_variable() to set new
variable to efi variable storage and shows efivars: set_variable() failed:
status=-28 message.
- commit 68d929862e29a8b52a7f2f2f86a0600423b093cd
efi: be more paranoid about available space when creating variables
- commit 31ff2f20d9003e74991d135f56e503fe776c127c
efi: Distinguish between remaining space and actually used space
- commit 8c58bf3eec3b8fc8162fe557e9361891c20758f2
x86,efi: Implement efi_no_storage_paranoia parameter
- commit f8b8404337de4e2466e2e1139ea68b1f8295974f
Modify UEFI anti-bricking code
When booting my system, remaining space of efi variable storage is about
5KB. So there is no room that sets a new variable to the storage. On my
system, trigger of gc is when EFI_OUT_OF_RESOURCES occurs on pre OS
environment with UEFI. So if EFI_OUT_OF_RESOURCES occurs by the 5Kbyte
threshold, nvram storage cannot be used until EFI_OUT_OF_RESOURCES occurs
on pre OS environment with UEFI.
This patch adds whitelist. If a server is in the whitelist,
efi_no_storage_paranoia is set to true. And the system can use all efi
variable storage.
Signed-off-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
CC: Matthew Garrett matthew.garr...@nebula.com
CC: Richard Weinberger rich...@nod.at
CC: Lee, Chun-Y j...@suse.com
CC: Madper Xie c...@redhat.com
CC: Matt Fleming matt.flem...@intel.com
---
arch/x86/platform/efi/efi.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/arch/x86/platform/efi/efi.c b/arch/x86/platform/efi/efi.c
index c7e22ab..9fadf5d 100644
--- a/arch/x86/platform/efi/efi.c
+++ b/arch/x86/platform/efi/efi.c
@@ -116,6 +116,15 @@ static int __init setup_storage_paranoia(char *arg)
}
early_param(efi_no_storage_paranoia, setup_storage_paranoia);
+struct no_bricked_efi {
+ char vendor[100];
+ u32 revision;
+};
+
+static struct no_bricked_efi efi_whitelist[] __initdata = {
+ {FUJITSU LIMITED, 0},
So, no UEFI from Fujitsu on planet earth suffers from such issues?
How can you guarantee that?
Thanks,
//richard
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net] virtio-net: fix page refcnt leaking when fail to allocate frag skb
On Tue, Nov 19, 2013 at 02:00:11PM -0800, Eric Dumazet wrote: On Tue, 2013-11-19 at 23:53 +0200, Michael S. Tsirkin wrote: Which NIC? Virtio? Prior to 2613af0ed18a11d5c566a81f9a6510b73180660a it didn't drop packets received from host as far as I can tell. virtio is more like a pipe than a real NIC in this respect. Prior/after to this patch, you were not posting buffers, so if packets were received on a physical NIC, you were dropping the packets anyway. It makes no difference at all, adding a cushion might make you feel better, but its really not worth it. Under memory stress, it makes better sense to drop a super big GRO packet (The one needing frag_list extension ...) It gives a better signal to the sender to reduce its pressure, and gives opportunity to free more of your memory. OK, but in that case one wonders whether we should do more to free memory? E.g. imagine that we dropped a packet of a specific TCP flow because we couldn't allocate a new packet. What happens now is that the old packet is freed as well. So quite likely the next packet in queue will get processed since it will reuse the memory we have just freed. The next packet and the next after it etc all will have to go through the net stack until they get at the socket and are dropped then because we missed a segment. Even worse, GRO gets disabled so the load on receiver goes up instead of down. Sounds like a problem doesn't it? GRO actually detects it's the same flow and can see packet is out of sequence. Why doesn't it drop the packet then? Alternatively, we could (for example using the pre-allocated skb like I suggested) notify GRO that it should start dropping packets of this flow. What do you think? -- MST -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
On Wed, Nov 20, 2013 at 2:14 PM, Vivek Gautam gautamvivek1...@gmail.com wrote:
Hi Tomasz,
On Sun, Nov 10, 2013 at 7:38 PM, Tomasz Figa tomasz.f...@gmail.com wrote:
Hi Vivek,
On Thursday 31 of October 2013 13:15:41 Vivek Gautam wrote:
Add a new driver for the USB 3.0 PHY on Exynos5 series of SoCs.
The new driver uses the generic PHY framework and will interact
with DWC3 controller present on Exynos5 series of SoCs.
Signed-off-by: Vivek Gautam gautam.vi...@samsung.com
---
.../devicetree/bindings/phy/samsung-phy.txt| 20 +
drivers/phy/Kconfig|7 +
drivers/phy/Makefile |1 +
drivers/phy/phy-exynos5-usb3.c | 562
4 files changed, 590 insertions(+), 0 deletions(-)
create mode 100644 drivers/phy/phy-exynos5-usb3.c
diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
b/Documentation/devicetree/bindings/phy/samsung-phy.txt
index c0fccaa..9b5c111 100644
--- a/Documentation/devicetree/bindings/phy/samsung-phy.txt
+++ b/Documentation/devicetree/bindings/phy/samsung-phy.txt
@@ -20,3 +20,23 @@ Required properties:
- compatible : should be samsung,exynos5250-dp-video-phy;
- reg : offset and length of the Display Port PHY register set;
- #phy-cells : from the generic PHY bindings, must be 0;
+
+Samsung Exynos5 SoC seiries USB 3.0 PHY controller
typo: s/seiries/series/
will correct it.
+--
+
+Required properties:
+- compatible :
+ should be samsung,exynos5250-usb3phy for exynos5250 SoC
+ should be samsung,exynos5420-usb3phy for exynos5420 SoC
I'd slightly change this into something like this:
- compatible: Should be set to one of following supported values:
- samsung,exynos5250-usb3phy - for Exynos5250 SoC,
- samsung,exynos5420-usb3phy - for Exynos5420 SoC.
sure, will make it as suggested.
+- reg : Register offset and length array
+ - first field corresponds to USB 3.0 PHY register set;
+ - second field corresponds to PHY power isolation register
+ present in PMU;
For consistency and to make things more future-proof, you should consider
using the PMU indirectly, through the syscon interface, as done in Leela
Krishna Amudala's series[1] in case of watchdog driver.
Right that's a better way to do.
But this will again introduce the register offset arithmetic once again.
And in case of multiple USB 3.0 PHY controllers (like for Exynos5420),
we would need to take extra care of each such offset, by having
provision for aliases
for the usb3phy nodes and then setting required offset before doing isolation.
For Exynos5420 USB3.0 PHY channel 0 is controlled by 0x10040704; and
USB3.0 PHY channel 1 is controlled by 0x10040708.
Or i think i can add PHY IDs similar to what Sylwester does for
MIPI_CSIS and MIPI_DSIM,
so that i will have something like this:
enum exynos5_usb3phy_id {
EXYNOS5_USB3PHY0,
EXYNOS5_USB3PHY1,
};
and then make use of this to add respective offsets to the pmu reg
base address as obtained from syscon node (0x1004).
I will tell Kamil to do the same for USB 2.0 PHY as well.
[1] http://thread.gmane.org/gmane.linux.kernel.samsung-soc/24652
+- clocks: Clock IDs array as required by the controller
+- clock-names: names of clocks correseponding to IDs in the clock property;
+ Required clocks:
+ - first clock is main PHY clock (same as USB 3.0 controller IP clock)
+ - second clock is reference clock (usually crystal clock)
+ optional clock:
+ - third clock is special clock used by PHY for operation
Is this clock really optional? It looks like it's required for Exynos5420.
Yes, this clock is an additional clock for Exynos5420 rather then
being just optional
If so, you should instead change this to:
Additional clocks required for Exynos5420:
Ok will change this.
Also you have not specified names of the clocks, just what they are.
Please remember that those are input names, so you can imagine them as
names of clock input pins of the IP block, not SoC-level clock names.
So you mean, similar to what driver requests (clocks with their input names) ?
will add clock names.
+- #phy-cells : from the generic PHY bindings, must be 0;
I'd also add an example of correct USB 3.0 PHY device tree node here.
Sorry, forgot to add an example of the device node :-)
will add one.
diff --git a/drivers/phy/phy-exynos5-usb3.c b/drivers/phy/phy-exynos5-usb3.c
new file mode 100644
index 000..b9a2674
--- /dev/null
+++ b/drivers/phy/phy-exynos5-usb3.c
@@ -0,0 +1,562 @@
[snip]
+#define EXYNOS5_DRD_PHYRESUME(0x34)
+#define EXYNOS5_DRD_LINKPORT (0x44)
+
+
nit: Duplicate blank line.
will remove it.
+/* Isolation, configured in the power management unit */
+#define EXYNOS5_USB_ISOL_DRD (1 0)
+
+#define
Re: [PATCH net] virtio-net: fix page refcnt leaking when fail to allocate frag skb
On Tue, Nov 19, 2013 at 05:34:16PM -0800, Michael Dalton wrote: Hi, After further reflection I think we're looking at two related issues: (a) a memory leak that Jason has identified that occurs when a memory allocation fails in receive_mergeable. Jasons commit solves this issue. (b) virtio-net does not dequeue all buffers for a packet in the case that an error occurs on receive and mergeable receive buffers is enabled. For (a), this bug is new and due to changes in 2613af0ed18a, and the net impact is memory leak on the physical page. However, I believe (b) has always been possible in some form because if page_to_skb() returns NULL (e.g., due to SKB allocation failure), receive_mergeable is never called. AFAICT this is also the behavior prior to 2613af0ed18a. The net impact of (b) would be that virtio-net would interpret a packet buffer that is in the middle of a mergeable packet as the start of a new packet, which is definitely also a bug (and the buffer contents could contain bytes that resembled a valid virtio-net header). A solution for (b) will require handling both the page_to_skb memory allocation failures and the memory allocation failures in receive_mergeable introduced by 2613af0ed18a. Best, Mike Absolutely. I missed this fact yesterday night but I can see it clearly in the morning. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
Hi Kishon, On Mon, Nov 11, 2013 at 4:41 PM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, sorry for the delayed response. On Wednesday 06 November 2013 05:37 AM, Jingoo Han wrote: On Wednesday, November 06, 2013 2:58 AM, Vivek Gautam wrote: On Tue, Nov 5, 2013 at 5:33 PM, Jingoo Han jg1@samsung.com wrote: [.] USB3.0 PHY consists of two blocks such as 3.0 block and 2.0 block. This USB3.0 PHY can support UTMI+ and PIPE3 interface for 3.0 block and 2.0 block, respectively. Conclusion: 1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device Base address: 0x1213 2) USB3.0 PHY: USB3.0 DRD (3.0 HOST 3.0 Device) Base address: 0x1210 2.0 block(UTMI+) 3.0 block(PIPE3) And this is of course the PHY used by DWC3 controller, which works at both High speed as well as Super Speed. Right ? Right. While 3.0 block(PIPE3) can be used for Super Speed, 2.0 block(UTMI+) can be used for High speed. It should then come under *single IP muliple PHY* category similar to what Sylwester has done. Do you mean that i should be including PHY IDs for UTMI+ phy and PIPE3 phy present in this PHY block ? AFAICS the two phys (UTMI+ and PIPE3) do not really have separate registers to program, and that's the reason we program the entire PHY in a shot. Thanks Kishon -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] clksrc-of: warn if no clock sources are found
Many platforms rely on clocksource_of_init() being implicitly
called for registering clock sources and will get zero warnings
if no working clock source is available. Let's print a critical
error message if no clock source is found.
Acked-by: Lee Jones lee.jo...@linaro.org
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
drivers/clocksource/clksrc-of.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/clocksource/clksrc-of.c b/drivers/clocksource/clksrc-of.c
index 35639cf4e5a2..a30b42c3ac3b 100644
--- a/drivers/clocksource/clksrc-of.c
+++ b/drivers/clocksource/clksrc-of.c
@@ -28,6 +28,7 @@ void __init clocksource_of_init(void)
struct device_node *np;
const struct of_device_id *match;
clocksource_of_init_fn init_func;
+ unsigned clocksources = 0;
for_each_matching_node_and_match(np, __clksrc_of_table, match) {
if (!of_device_is_available(np))
@@ -36,5 +37,8 @@ void __init clocksource_of_init(void)
init_func = match-data;
init_func(np);
of_node_put(np);
+ clocksources++;
}
+ if (!clocksources)
+ pr_crit(%s: no matching clocksources found\n, __func__);
}
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] AVR32 updates for 3.13
Hello Linus, please pull git://git.kernel.org/pub/scm/linux/kernel/git/egtvedt/linux-avr32.git for-linus to receive the following AVR32 updates for 3.13 Andreas Bießmann (2): avr32: setup crt for early panic() avr32: fix out-of-range jump in large kernels Chen Gang (1): avr32: uapi: be sure of _UAPI prefix for all guard macros Eirik Aanonsen (1): avr32: add kprobe_ctlblk memory struct arch/avr32/boot/u-boot/head.S | 35 +-- arch/avr32/include/asm/kprobes.h | 14 ++ arch/avr32/include/uapi/asm/Kbuild| 24 arch/avr32/include/uapi/asm/auxvec.h | 6 +++--- arch/avr32/include/uapi/asm/bitsperlong.h | 1 - arch/avr32/include/uapi/asm/byteorder.h | 6 +++--- arch/avr32/include/uapi/asm/cachectl.h| 6 +++--- arch/avr32/include/uapi/asm/errno.h | 6 -- arch/avr32/include/uapi/asm/fcntl.h | 6 -- arch/avr32/include/uapi/asm/ioctl.h | 6 -- arch/avr32/include/uapi/asm/ioctls.h | 6 -- arch/avr32/include/uapi/asm/ipcbuf.h | 1 - arch/avr32/include/uapi/asm/kvm_para.h| 1 - arch/avr32/include/uapi/asm/mman.h| 1 - arch/avr32/include/uapi/asm/msgbuf.h | 6 +++--- arch/avr32/include/uapi/asm/poll.h| 1 - arch/avr32/include/uapi/asm/posix_types.h | 6 +++--- arch/avr32/include/uapi/asm/resource.h| 6 -- arch/avr32/include/uapi/asm/sembuf.h | 6 +++--- arch/avr32/include/uapi/asm/setup.h | 1 - arch/avr32/include/uapi/asm/shmbuf.h | 6 +++--- arch/avr32/include/uapi/asm/sigcontext.h | 6 +++--- arch/avr32/include/uapi/asm/siginfo.h | 6 -- arch/avr32/include/uapi/asm/signal.h | 1 - arch/avr32/include/uapi/asm/socket.h | 6 +++--- arch/avr32/include/uapi/asm/sockios.h | 6 +++--- arch/avr32/include/uapi/asm/stat.h| 6 +++--- arch/avr32/include/uapi/asm/statfs.h | 6 -- arch/avr32/include/uapi/asm/swab.h| 6 +++--- arch/avr32/include/uapi/asm/termbits.h| 6 +++--- arch/avr32/include/uapi/asm/termios.h | 1 - arch/avr32/include/uapi/asm/types.h | 5 + arch/avr32/include/uapi/asm/unistd.h | 1 - arch/avr32/kernel/entry-avr32b.S | 3 ++- arch/avr32/kernel/head.S | 20 35 files changed, 101 insertions(+), 129 deletions(-) delete mode 100644 arch/avr32/include/uapi/asm/bitsperlong.h delete mode 100644 arch/avr32/include/uapi/asm/errno.h delete mode 100644 arch/avr32/include/uapi/asm/fcntl.h delete mode 100644 arch/avr32/include/uapi/asm/ioctl.h delete mode 100644 arch/avr32/include/uapi/asm/ioctls.h delete mode 100644 arch/avr32/include/uapi/asm/ipcbuf.h delete mode 100644 arch/avr32/include/uapi/asm/kvm_para.h delete mode 100644 arch/avr32/include/uapi/asm/mman.h delete mode 100644 arch/avr32/include/uapi/asm/poll.h delete mode 100644 arch/avr32/include/uapi/asm/resource.h delete mode 100644 arch/avr32/include/uapi/asm/siginfo.h delete mode 100644 arch/avr32/include/uapi/asm/statfs.h -- mvh Hans-Christian Egtvedt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net] virtio-net: fix page refcnt leaking when fail to allocate frag skb
On Tue, Nov 19, 2013 at 01:38:16PM -0800, Michael Dalton wrote: Great catch Jason. I agree this now raises the larger issue of how to handle a memory alloc failure in the middle of receive. As Eric mentioned, we can drop the packet and free the remaining (num_buf) frags. Michael, perhaps I'm missing something, but why would you prefer pre-allocating buffers in this case? If the guest kernel is OOM'ing, dropping packets should provide backpressure. Also, we could just as easily fail the initial skb alloc in page_to_skb, and I think that case also needs to be handled now in the same fashion as a memory allocation failure in receive_mergeable. Best, Mike Yes I missed this last night. Thanks a lot Eric and Michael for pointing this out. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
On Wednesday 20 November 2013 02:27 PM, Vivek Gautam wrote: Hi Kishon, On Mon, Nov 11, 2013 at 4:41 PM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, sorry for the delayed response. On Wednesday 06 November 2013 05:37 AM, Jingoo Han wrote: On Wednesday, November 06, 2013 2:58 AM, Vivek Gautam wrote: On Tue, Nov 5, 2013 at 5:33 PM, Jingoo Han jg1@samsung.com wrote: [.] USB3.0 PHY consists of two blocks such as 3.0 block and 2.0 block. This USB3.0 PHY can support UTMI+ and PIPE3 interface for 3.0 block and 2.0 block, respectively. Conclusion: 1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device Base address: 0x1213 2) USB3.0 PHY: USB3.0 DRD (3.0 HOST 3.0 Device) Base address: 0x1210 2.0 block(UTMI+) 3.0 block(PIPE3) And this is of course the PHY used by DWC3 controller, which works at both High speed as well as Super Speed. Right ? Right. While 3.0 block(PIPE3) can be used for Super Speed, 2.0 block(UTMI+) can be used for High speed. It should then come under *single IP muliple PHY* category similar to what Sylwester has done. Do you mean that i should be including PHY IDs for UTMI+ phy and PIPE3 phy present in this PHY block ? AFAICS the two phys (UTMI+ and PIPE3) do not really have separate registers to program, and that's the reason we program the entire PHY in a shot. you mean you program the same set of bits for UTMI+ and PIPE3? Thanks Kishon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net 2/3] virtio-net: fix num calculation on frag skb allocation failure
We need decrease the rq-num after we can get a buf through
virtqueue_get_buf() even if we could not allocate frag skb. Otherwise, the
refill routine won't be triggered under heavy memory stress since the driver may
still think there's enough room.
This bug was introduced by commit 2613af0ed18a11d5c566a81f9a6510b73180660a
(virtio_net: migrate mergeable rx buffers to page frag allocators).
Cc: Rusty Russell ru...@rustcorp.com.au
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Michael Dalton mwdal...@google.com
Cc: Eric Dumazet eduma...@google.com
Signed-off-by: Jason Wang jasow...@redhat.com
---
The patch was needed for 3.12 stable.
---
drivers/net/virtio_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 24fd502..de1d6ca 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -333,6 +333,7 @@ static int receive_mergeable(struct receive_queue *rq,
struct sk_buff *head_skb)
head_skb-dev-stats.rx_length_errors++;
return -EINVAL;
}
+ --rq-num;
if (unlikely(len MERGE_BUFFER_LEN)) {
pr_debug(%s: rx error: merge buffer too long\n,
head_skb-dev-name);
@@ -367,7 +368,6 @@ static int receive_mergeable(struct receive_queue *rq,
struct sk_buff *head_skb)
skb_add_rx_frag(curr_skb, num_skb_frags, page,
offset, len, MERGE_BUFFER_LEN);
}
- --rq-num;
}
return 0;
}
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net 1/3] virtio-net: drop the rest of buffers when we can't allocate skb
When mergeable buffer were used, we only put the first page buf leave the rest
of buffers in the virt queue. This will cause the driver could not get the
correct head buffer any more. Fix this by dropping the rest of buffers for this
packet.
The bug was introduced by commit 9ab86bbcf8be755256f0a5e994e0b38af6b4d399
(virtio_net: Defer skb allocation in receive path).
Cc: Rusty Russell ru...@rustcorp.com.au
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Michael Dalton mwdal...@google.com
Cc: Eric Dumazet eduma...@google.com
Cc: Shirley Ma x...@us.ibm.com
Signed-off-by: Jason Wang jasow...@redhat.com
---
This patch was needed for stable
---
drivers/net/virtio_net.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 7bab4de..24fd502 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -222,6 +222,17 @@ static void skb_xmit_done(struct virtqueue *vq)
netif_wake_subqueue(vi-dev, vq2txq(vq));
}
+static void drop_mergeable_buffer(struct receive_queue *rq, int num_buf)
+{
+ char *buf;
+ int len;
+
+ while (--num_buf (buf = virtqueue_get_buf(rq-vq, len)) != NULL) {
+ --rq-num;
+ put_page(virt_to_head_page(buf));
+ }
+}
+
/* Called from bottom half context */
static struct sk_buff *page_to_skb(struct receive_queue *rq,
struct page *page, unsigned int offset,
@@ -237,8 +248,13 @@ static struct sk_buff *page_to_skb(struct receive_queue
*rq,
/* copy small packet so we can reuse these pages for small data */
skb = netdev_alloc_skb_ip_align(vi-dev, GOOD_COPY_LEN);
- if (unlikely(!skb))
+ if (unlikely(!skb)) {
+ if (vi-mergeable_rx_bufs) {
+ hdr = (struct skb_vnet_hdr *)p;
+ drop_mergeable_buffer(rq, hdr-mhdr.num_buffers);
+ }
return NULL;
+ }
hdr = skb_vnet_hdr(skb);
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net 3/3] virtio-net: fix resources leaking when fail to allocate frag skb
When we fail to allocate a frag skb, we need put the refcnt of the page and drop
the rest of the buffers. Otherwise the page was leaked and driver won't get a
correct head buffer after this failure.
This bug was introduced by commit 2613af0ed18a11d5c566a81f9a6510b73180660a
(virtio_net: migrate mergeable rx buffers to page frag allocators).
Cc: Rusty Russell ru...@rustcorp.com.au
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Michael Dalton mwdal...@google.com
Cc: Eric Dumazet eduma...@google.com
Signed-off-by: Jason Wang jasow...@redhat.com
---
The patch was needed for 3.12 stable.
---
drivers/net/virtio_net.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index de1d6ca..f6f1e20 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -339,9 +339,12 @@ static int receive_mergeable(struct receive_queue *rq,
struct sk_buff *head_skb)
head_skb-dev-name);
len = MERGE_BUFFER_LEN;
}
+ page = virt_to_head_page(buf);
if (unlikely(num_skb_frags == MAX_SKB_FRAGS)) {
struct sk_buff *nskb = alloc_skb(0, GFP_ATOMIC);
if (unlikely(!nskb)) {
+ put_page(page);
+ drop_mergeable_buffer(rq, num_buf);
head_skb-dev-stats.rx_dropped++;
return -ENOMEM;
}
@@ -358,7 +361,6 @@ static int receive_mergeable(struct receive_queue *rq,
struct sk_buff *head_skb)
head_skb-len += len;
head_skb-truesize += MERGE_BUFFER_LEN;
}
- page = virt_to_head_page(buf);
offset = buf - (char *)page_address(page);
if (skb_can_coalesce(curr_skb, num_skb_frags, page, offset)) {
put_page(page);
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clksrc-of: warn if no clock sources are found
On 11/20/2013 09:58 AM, Linus Walleij wrote:
Many platforms rely on clocksource_of_init() being implicitly
called for registering clock sources and will get zero warnings
if no working clock source is available. Let's print a critical
error message if no clock source is found.
Acked-by: Lee Jones lee.jo...@linaro.org
Signed-off-by: Linus Walleij linus.wall...@linaro.org
+1.
Added Stephen Warren in Cc.
---
drivers/clocksource/clksrc-of.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/clocksource/clksrc-of.c b/drivers/clocksource/clksrc-of.c
index 35639cf4e5a2..a30b42c3ac3b 100644
--- a/drivers/clocksource/clksrc-of.c
+++ b/drivers/clocksource/clksrc-of.c
@@ -28,6 +28,7 @@ void __init clocksource_of_init(void)
struct device_node *np;
const struct of_device_id *match;
clocksource_of_init_fn init_func;
+ unsigned clocksources = 0;
for_each_matching_node_and_match(np, __clksrc_of_table, match) {
if (!of_device_is_available(np))
@@ -36,5 +37,8 @@ void __init clocksource_of_init(void)
init_func = match-data;
init_func(np);
of_node_put(np);
+ clocksources++;
}
+ if (!clocksources)
+ pr_crit(%s: no matching clocksources found\n, __func__);
}
--
http://www.linaro.org/ Linaro.org │ Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro Facebook |
http://twitter.com/#!/linaroorg Twitter |
http://www.linaro.org/linaro-blog/ Blog
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xen: tmem: rmove useless parameters
On 20.11.13 at 09:52, Bob Liu lliu...@gmail.com wrote: @@ -100,9 +100,6 @@ static inline int xen_tmem_op(u32 tmem_cmd, u32 tmem_pool, struct tmem_oid oid, op.u.gen.oid[1] = oid.oid[1]; op.u.gen.oid[2] = oid.oid[2]; op.u.gen.index = index; - op.u.gen.tmem_offset = tmem_offset; - op.u.gen.pfn_offset = pfn_offset; - op.u.gen.len = len; But you can't leave these fields uninitialized. Jan -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] mmc: rtsx: modify phase searching method for tunning
Hi Dan:
On 11/20/2013 04:17 PM, Dan Carpenter wrote:
On Tue, Nov 19, 2013 at 07:10:35PM +0800, micky_ch...@realsil.com.cn wrote:
-static u8 sd_search_final_phase(struct realtek_pci_sdmmc *host, u32 phase_map)
+static inline u32 sd_get_phase_point(u32 phase_map, unsigned int idx)
{
- struct timing_phase_path path[MAX_PHASE + 1];
- int i, j, cont_path_cnt;
- int new_block, max_len, final_path_idx;
- u8 final_phase = 0xFF;
+ idx = MAX_PHASE;
+ return phase_map (1 idx);
+}
+
This function is confusing
MAX_PHASE is a terrible name. It's in a global header but it doesn't
have a prefix. It should be #define RTS_MAX_PHASE. It's weird that we
are using it both as a number and as bit mask. It's weird that we
always add a + 1 to MAX_PHASE. It means the name is chosen poorly.
Maybe it should be:
#define RTS_MAX_PHASE 32
#define RTS_PHASE_MASK 0x1f
That's good, I will modify and resend.
So this function takes a phase_map and an index and it wraps the index
by masking away the top bits then it tests to see if the wrapped index
bit is set? The wrapping is very strange.
We use this function to find whether the bit of index in the phase_map
is 1. The index can be twice as MAX_PHASE(reach to 63), because we use
a unidirectional search, start search continuous phase to found the
max continuous length from 0, 1, ..., to 31. When we start from
bit31, index 32 should wrap as 0. This function can be replaced by mod
function(idx %= MAX_PHASE + 1).
The name of the function is sd_get_phase_point() but we only test to
see if it returns zero. The name of the function is not helpful.
sd is a generic prefix.
get is misleading because we don't get anything it only returns zero
on success?
phase_point might be helpful but I don't know what a phase_point is.
Add a comment about that maybe.
Yes, thank you for your suggestion, the function name is really not good.
I want use test_phase_bit(u32 phase_map, unsigned int bit), is that ok?
regards,
dan carpenter
.
--
Best Regards
Micky.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] ASoC: wm5110: Expose input high pass filter controls
On Tue, 19 Nov 2013, Charles Keepax wrote: Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com --- drivers/mfd/wm5110-tables.c |4 +++ include/linux/mfd/arizona/registers.h | 37 + sound/soc/codecs/arizona.c| 10 + sound/soc/codecs/arizona.h|1 + sound/soc/codecs/wm5110.c | 19 + 5 files changed, 71 insertions(+), 0 deletions(-) For the MFD parts: Acked-by: Lee Jones lee.jo...@linaro.org How do you want to play this ASoC? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] mfd: wm5110: Make DSP memories readable
On Tue, 19 Nov 2013, Charles Keepax wrote: Expose the memory regions used by the DSP cores on WM5110 as readable and volatile. Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com --- drivers/mfd/wm5110-tables.c | 69 -- 1 files changed, 65 insertions(+), 4 deletions(-) Applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IRQF_RESUME_EARLY and errors in dpm_suspend_noirq
Hi, Commit 9bab0b7fbace (genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier) split the suspend/resume of the irqs into two parts. The early-irqs get resumed during syscore_resume, while the rest get resumed by the regular resume_device_irqs. I may be blind, but where get the early-irqs resumed in the error path of dpm_suspend_noirq? When a suspend_noirq callback returns an error, dpm_resume_noirq gets called, which only calls resume_device_irqs while the suspend_device_irqs call in dpm_suspend_noirq suspends all irqs. So it does not seem that the early-irqs get resumed at all in this case. Thanks Heiko -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xen: tmem: rmove useless parameters
On 11/20/2013 05:10 PM, Jan Beulich wrote:
On 20.11.13 at 09:52, Bob Liu lliu...@gmail.com wrote:
@@ -100,9 +100,6 @@ static inline int xen_tmem_op(u32 tmem_cmd, u32
tmem_pool, struct tmem_oid oid,
op.u.gen.oid[1] = oid.oid[1];
op.u.gen.oid[2] = oid.oid[2];
op.u.gen.index = index;
-op.u.gen.tmem_offset = tmem_offset;
-op.u.gen.pfn_offset = pfn_offset;
-op.u.gen.len = len;
But you can't leave these fields uninitialized.
Oh, yes.
And I should remove those members totally from struct tmem_op {}
--
Thanks,
-Bob
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] clocksource: time-efm32: Select CLKSRC_MMIO
On Wed, Nov 20, 2013 at 10:15:11AM +0800, Axel Lin wrote: The time-efm32 driver uses the clocksource MMIO functions. Thus it needs to select CLKSRC_MMIO in Kconfig. Signed-off-by: Axel Lin axel@ingics.com Good catch. I selected CLKSRC_MMIO from MACH_EFM32 (still out-of-tree) but of course this is wrong. Acked-by: Uwe Kleine-König u.kleine-koe...@pengutronix.de Thanks Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] xen: tmem: rmove useless parameters
On 20.11.13 at 10:22, Bob Liu bob@oracle.com wrote:
On 11/20/2013 05:10 PM, Jan Beulich wrote:
On 20.11.13 at 09:52, Bob Liu lliu...@gmail.com wrote:
@@ -100,9 +100,6 @@ static inline int xen_tmem_op(u32 tmem_cmd, u32
tmem_pool, struct tmem_oid oid,
op.u.gen.oid[1] = oid.oid[1];
op.u.gen.oid[2] = oid.oid[2];
op.u.gen.index = index;
- op.u.gen.tmem_offset = tmem_offset;
- op.u.gen.pfn_offset = pfn_offset;
- op.u.gen.len = len;
But you can't leave these fields uninitialized.
Oh, yes.
And I should remove those members totally from struct tmem_op {}
That's an established ABI - you can't just remove members there.
Jan
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/9] staging/lustre/lnet: Fix assert on empty group in selftest module
On Wed, Nov 20, 2013 at 2:37 AM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: On Tue, Nov 19, 2013 at 09:23:43PM +0800, Peng Tao wrote: From: Amir Shehata amir.sheh...@intel.com The core of the issue is that the selftest module doesn't sanitize its own API, but it depends on lst utility to do such checks. As a result this issue manifests itself in this particular LU through an assert on an empty group. If the NID is misspelled then an empty group is added. An error output is provided, but if that's never checked in a batch script, as is the case with this issue, then the script will try to add an empty group to a test to run in a batch, and that will cause an assert The fix is two fold. Ensure that lst utility checks that a group is added with at least one node. If not the group is subsequently deleted. And the add_test command would fail, since the group no longer exists. The second fix is to ensure that the kernel module itself sanitizes its own API in this particular case, so that if a different utility is used other than lst to communicate with the selftest kernel module then this error would be caught. This fix looks up the batch and the groups, src and dst, in the ioctl handle and sanitizes that input at this point. If the group looked up either doesn't exist or doesn't have at least one ACTIVE node, then the command fails. NOTE:there are many other cases in the code where the selftest kernel module doesn't check for sanity of the input, but depends totally on the lst module to do such checks. Particularly around length of strings passed in. Thus it is possible to crash the selftest module if someone tries to create another userspace app to communicate with the selftest kernel module without ensuring sanity of the params sent to the kernel module. In effect, it's always assumed that lst is the front end for selftest and no other front end is to be used. This patch adds build warnings to the kernel build process, so I can't apply it, sorry. Please fix that up before sending it again. Hi Greg, Can you please be explicit about what build warning you saw? I tried to reproduce it with gcc version 4.1.2 and 4.6.3 on my machine, but didn't see any build warnings with this patch applied. Thanks, Tao -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Make efi-pstore return a unique id
rich...@nod.at writes: Am 01.11.2013 20:22, schrieb Seiji Aguchi: Agreed. I liked your ((timestamp * 100 + part) * 100 + count function much more than this. I was worried that the part and count could be more than 100. If it happens, the id may not be unique... But, currently, size of nvram storage is limited, so it is a corner case. I respect your opinion. What about feeding the bytes of all three integers into a non-cryptographic hash function? Then will lost the sequence of our log. We will get lots of entries like dmesg-efi-`unique but meaningless number here` in pstore fs. Who will know which file is the latest record? A possible way is sort them by created time. But pstore splits large messages into many parts. So they will have the same created-time. Like the following case: [root@dhcp-13-41 ~]# ls -rtl /dev/pstore/ total 0 -r--r--r--. 1 root root 930 Nov 15 08:42 dmesg-efi-9 -r--r--r--. 1 root root 1017 Nov 15 08:42 dmesg-efi-8 -r--r--r--. 1 root root 993 Nov 15 08:42 dmesg-efi-7 -r--r--r--. 1 root root 984 Nov 15 08:42 dmesg-efi-6 -r--r--r--. 1 root root 1008 Nov 15 08:42 dmesg-efi-5 -r--r--r--. 1 root root 909 Nov 15 08:42 dmesg-efi-10 -r--r--r--. 1 root root 1003 Nov 15 08:42 dmesg-efi-11 -r--r--r--. 1 root root 980 Nov 18 00:41 dmesg-efi-4 -r--r--r--. 1 root root 990 Nov 18 00:41 dmesg-efi-3 -r--r--r--. 1 root root 966 Nov 18 00:41 dmesg-efi-2 -r--r--r--. 1 root root 1010 Nov 18 00:41 dmesg-efi-1 or more intuitive: ls /sys/firmware/efi/efivars/ | grep -i dump | cut -d'-' -f5 | sort |wc -l 103 ls /sys/firmware/efi/efivars/ | grep -i dump | cut -d'-' -f5 | sort |uniq |wc -l 26 So if we using a hashed unique number for uniqueness, we will lose the sequence. We must sort them manually. And another side, the combin of timestamp, count and part is unique. Why we generate a unique number from a unique number? if you think making a string from three ints and then a parse it to a int again is odd, i'd like to use ((timestamp * 100 + part) * 100 + count. Using this way you get a cheap unique id. Thanks, //richard -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net v5 1/4] r8152: fix tx/rx memory overflow
The tx/rx would access the memory which is out of the desired range.
Modify the method of checking the end of the memory to avoid it.
For r8152_tx_agg_fill(), the variable remain may become negative.
However, the declaration is unsigned, so the while loop wouldn't
break when reaching the end of the desied memory. Although to change
the declaration from unsigned to signed is enough to fix it, I also
modify the checking method for safe. Replace
remain = rx_buf_sz - sizeof(*tx_desc) -
(u32)((void *)tx_data - agg-head);
with
remain = rx_buf_sz - (int)(tx_agg_align(tx_data) - agg-head);
to make sure the variable remain is always positive. Then, the
overflow wouldn't happen.
For rx_bottom(), the rx_desc should not be used to calculate the
packet length before making sure the rx_desc is in the desired range.
Change the checking to two parts. First, check the descriptor is in
the memory. The other, using the descriptor to find out the packet
length and check if the packet is in the memory.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 30 +-
1 file changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f3fce41..428600d 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -24,7 +24,7 @@
#include linux/ipv6.h
/* Version Information */
-#define DRIVER_VERSION v1.01.0 (2013/08/12)
+#define DRIVER_VERSION v1.02.0 (2013/10/28)
#define DRIVER_AUTHOR Realtek linux nic maintainers nic_s...@realtek.com
#define DRIVER_DESC Realtek RTL8152 Based USB 2.0 Ethernet Adapters
#define MODULENAME r8152
@@ -1136,14 +1136,14 @@ r8152_tx_csum(struct r8152 *tp, struct tx_desc *desc,
struct sk_buff *skb)
static int r8152_tx_agg_fill(struct r8152 *tp, struct tx_agg *agg)
{
- u32 remain;
+ int remain;
u8 *tx_data;
tx_data = agg-head;
agg-skb_num = agg-skb_len = 0;
- remain = rx_buf_sz - sizeof(struct tx_desc);
+ remain = rx_buf_sz;
- while (remain = ETH_ZLEN) {
+ while (remain = ETH_ZLEN + sizeof(struct tx_desc)) {
struct tx_desc *tx_desc;
struct sk_buff *skb;
unsigned int len;
@@ -1152,12 +1152,14 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct
tx_agg *agg)
if (!skb)
break;
+ remain -= sizeof(*tx_desc);
len = skb-len;
if (remain len) {
skb_queue_head(tp-tx_queue, skb);
break;
}
+ tx_data = tx_agg_align(tx_data);
tx_desc = (struct tx_desc *)tx_data;
tx_data += sizeof(*tx_desc);
@@ -1167,9 +1169,8 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct
tx_agg *agg)
agg-skb_len += len;
dev_kfree_skb_any(skb);
- tx_data = tx_agg_align(tx_data + len);
- remain = rx_buf_sz - sizeof(*tx_desc) -
-(u32)((void *)tx_data - agg-head);
+ tx_data += len;
+ remain = rx_buf_sz - (int)(tx_agg_align(tx_data) - agg-head);
}
usb_fill_bulk_urb(agg-urb, tp-udev, usb_sndbulkpipe(tp-udev, 2),
@@ -1188,7 +1189,6 @@ static void rx_bottom(struct r8152 *tp)
list_for_each_safe(cursor, next, tp-rx_done) {
struct rx_desc *rx_desc;
struct rx_agg *agg;
- unsigned pkt_len;
int len_used = 0;
struct urb *urb;
u8 *rx_data;
@@ -1204,17 +1204,22 @@ static void rx_bottom(struct r8152 *tp)
rx_desc = agg-head;
rx_data = agg-head;
- pkt_len = le32_to_cpu(rx_desc-opts1) RX_LEN_MASK;
- len_used += sizeof(struct rx_desc) + pkt_len;
+ len_used += sizeof(struct rx_desc);
- while (urb-actual_length = len_used) {
+ while (urb-actual_length len_used) {
struct net_device *netdev = tp-netdev;
struct net_device_stats *stats;
+ unsigned int pkt_len;
struct sk_buff *skb;
+ pkt_len = le32_to_cpu(rx_desc-opts1) RX_LEN_MASK;
if (pkt_len ETH_ZLEN)
break;
+ len_used += pkt_len;
+ if (urb-actual_length len_used)
+ break;
+
stats = rtl8152_get_stats(netdev);
pkt_len -= 4; /* CRC */
@@ -1234,9 +1239,8 @@ static void rx_bottom(struct r8152 *tp)
rx_data = rx_agg_align(rx_data + pkt_len + 4);
rx_desc = (struct rx_desc *)rx_data;
- pkt_len = le32_to_cpu(rx_desc-opts1)
[PATCH net v5 3/4] r8152: support stopping/waking tx queue
The maximum packet number which a tx aggregation buffer could contain
is the tx_qlen.
tx_qlen = buffer size / (packet size + descriptor size).
If the tx buffer is empty and the queued packets are more than the
maximum value which is defined above, stop the tx queue. Wake the
tx queue if tx queue is stopped and the queued packets are less than
tx_qlen.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 8a786b6..f92e0cf 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -365,6 +365,7 @@ struct r8152 {
struct mii_if_info mii;
int intr_interval;
u32 msg_enable;
+ u32 tx_qlen;
u16 ocp_base;
u8 *intr_buff;
u8 version;
@@ -1173,6 +1174,14 @@ static int r8152_tx_agg_fill(struct r8152 *tp, struct
tx_agg *agg)
remain = rx_buf_sz - (int)(tx_agg_align(tx_data) - agg-head);
}
+ netif_tx_lock(tp-netdev);
+
+ if (netif_queue_stopped(tp-netdev)
+ skb_queue_len(tp-tx_queue) tp-tx_qlen)
+ netif_wake_queue(tp-netdev);
+
+ netif_tx_unlock(tp-netdev);
+
usb_fill_bulk_urb(agg-urb, tp-udev, usb_sndbulkpipe(tp-udev, 2),
agg-head, (int)(tx_data - (u8 *)agg-head),
(usb_complete_t)write_bulk_callback, agg);
@@ -1393,6 +1402,10 @@ static netdev_tx_t rtl8152_start_xmit(struct sk_buff
*skb,
skb_queue_tail(tp-tx_queue, skb);
+ if (list_empty(tp-tx_free)
+ skb_queue_len(tp-tx_queue) tp-tx_qlen)
+ netif_stop_queue(netdev);
+
if (!list_empty(tp-tx_free))
tasklet_schedule(tp-tl);
@@ -1423,6 +1436,14 @@ static void rtl8152_nic_reset(struct r8152 *tp)
}
}
+static void set_tx_qlen(struct r8152 *tp)
+{
+ struct net_device *netdev = tp-netdev;
+
+ tp-tx_qlen = rx_buf_sz / (netdev-mtu + VLAN_ETH_HLEN + VLAN_HLEN +
+ sizeof(struct tx_desc));
+}
+
static inline u8 rtl8152_get_speed(struct r8152 *tp)
{
return ocp_read_byte(tp, MCU_TYPE_PLA, PLA_PHYSTATUS);
@@ -1434,6 +1455,7 @@ static int rtl8152_enable(struct r8152 *tp)
int i, ret;
u8 speed;
+ set_tx_qlen(tp);
speed = rtl8152_get_speed(tp);
if (speed _10bps) {
ocp_data = ocp_read_word(tp, MCU_TYPE_PLA, PLA_EEEP_CR);
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
On Wed, Nov 20, 2013 at 2:34 PM, Kishon Vijay Abraham I kis...@ti.com wrote: On Wednesday 20 November 2013 02:27 PM, Vivek Gautam wrote: Hi Kishon, On Mon, Nov 11, 2013 at 4:41 PM, Kishon Vijay Abraham I kis...@ti.com wrote: Hi, sorry for the delayed response. On Wednesday 06 November 2013 05:37 AM, Jingoo Han wrote: On Wednesday, November 06, 2013 2:58 AM, Vivek Gautam wrote: On Tue, Nov 5, 2013 at 5:33 PM, Jingoo Han jg1@samsung.com wrote: [.] USB3.0 PHY consists of two blocks such as 3.0 block and 2.0 block. This USB3.0 PHY can support UTMI+ and PIPE3 interface for 3.0 block and 2.0 block, respectively. Conclusion: 1) USB2.0 PHY: USB2.0 HOST, USB2.0 Device Base address: 0x1213 2) USB3.0 PHY: USB3.0 DRD (3.0 HOST 3.0 Device) Base address: 0x1210 2.0 block(UTMI+) 3.0 block(PIPE3) And this is of course the PHY used by DWC3 controller, which works at both High speed as well as Super Speed. Right ? Right. While 3.0 block(PIPE3) can be used for Super Speed, 2.0 block(UTMI+) can be used for High speed. It should then come under *single IP muliple PHY* category similar to what Sylwester has done. Do you mean that i should be including PHY IDs for UTMI+ phy and PIPE3 phy present in this PHY block ? AFAICS the two phys (UTMI+ and PIPE3) do not really have separate registers to program, and that's the reason we program the entire PHY in a shot. you mean you program the same set of bits for UTMI+ and PIPE3? No, looking closely into PHY datasheet as well as Exynos5250 manual, i can see that UTMI+ and PIPE3 phys have separate bit settings. So i think we should be able to segregate the two PHYs (UTMI+ and PIPE3). Pardon me for my earlier observations. Let me clarify more with our h/w team also on this and then i will confirm with this. Thanks Kishon -- Best Regards Vivek Gautam Samsung RD Institute, Bangalore India -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net v5 4/4] r8152: fix incorrect type in assignment
The data from the hardware should be little endian. Correct the
declaration.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index f92e0cf..5107372 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -307,22 +307,22 @@ enum rtl8152_flags {
#define MCU_TYPE_USB 0x
struct rx_desc {
- u32 opts1;
+ __le32 opts1;
#define RX_LEN_MASK0x7fff
- u32 opts2;
- u32 opts3;
- u32 opts4;
- u32 opts5;
- u32 opts6;
+ __le32 opts2;
+ __le32 opts3;
+ __le32 opts4;
+ __le32 opts5;
+ __le32 opts6;
};
struct tx_desc {
- u32 opts1;
+ __le32 opts1;
#define TX_FS (1 31) /* First segment of a packet */
#define TX_LS (1 30) /* Final segment of a packet */
#define TX_LEN_MASK0x3
- u32 opts2;
+ __le32 opts2;
#define UDP_CS (1 31) /* Calculate UDP/IP checksum */
#define TCP_CS (1 30) /* Calculate TCP/IP checksum */
#define IPV4_CS(1 29) /* Calculate IPv4 checksum */
@@ -877,7 +877,7 @@ static void write_bulk_callback(struct urb *urb)
static void intr_callback(struct urb *urb)
{
struct r8152 *tp;
- __u16 *d;
+ __le16 *d;
int status = urb-status;
int res;
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net v5 0/4] r8152 bug fixes
For the patch #3, I add netif_tx_lock() before checking the netif_queue_stopped(). Besides, I add checking the skb queue length before waking the tx queue. Hayes Wang (4): r8152: fix tx/rx memory overflow r8152: modify the tx flow r8152: support stopping/waking tx queue r8152: fix incorrect type in assignment drivers/net/usb/r8152.c | 114 +--- 1 file changed, 50 insertions(+), 64 deletions(-) -- 1.8.3.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net v5 2/4] r8152: modify the tx flow
Remove the code for sending the packet in the rtl8152_start_xmit().
Let rtl8152_start_xmit() to queue the packet only, and schedule a
tasklet to send the queued packets. This simplify the code and make
sure all the packet would be sent by the original order.
Signed-off-by: Hayes Wang hayesw...@realtek.com
---
drivers/net/usb/r8152.c | 46 +++---
1 file changed, 3 insertions(+), 43 deletions(-)
diff --git a/drivers/net/usb/r8152.c b/drivers/net/usb/r8152.c
index 428600d..8a786b6 100644
--- a/drivers/net/usb/r8152.c
+++ b/drivers/net/usb/r8152.c
@@ -1388,53 +1388,13 @@ static netdev_tx_t rtl8152_start_xmit(struct sk_buff
*skb,
struct net_device *netdev)
{
struct r8152 *tp = netdev_priv(netdev);
- struct net_device_stats *stats = rtl8152_get_stats(netdev);
- unsigned long flags;
- struct tx_agg *agg = NULL;
- struct tx_desc *tx_desc;
- unsigned int len;
- u8 *tx_data;
- int res;
skb_tx_timestamp(skb);
- /* If tx_queue is not empty, it means at least one previous packt */
- /* is waiting for sending. Don't send current one before it. */
- if (skb_queue_empty(tp-tx_queue))
- agg = r8152_get_tx_agg(tp);
-
- if (!agg) {
- skb_queue_tail(tp-tx_queue, skb);
- return NETDEV_TX_OK;
- }
-
- tx_desc = (struct tx_desc *)agg-head;
- tx_data = agg-head + sizeof(*tx_desc);
- agg-skb_num = agg-skb_len = 0;
+ skb_queue_tail(tp-tx_queue, skb);
- len = skb-len;
- r8152_tx_csum(tp, tx_desc, skb);
- memcpy(tx_data, skb-data, len);
- dev_kfree_skb_any(skb);
- agg-skb_num++;
- agg-skb_len += len;
- usb_fill_bulk_urb(agg-urb, tp-udev, usb_sndbulkpipe(tp-udev, 2),
- agg-head, len + sizeof(*tx_desc),
- (usb_complete_t)write_bulk_callback, agg);
- res = usb_submit_urb(agg-urb, GFP_ATOMIC);
- if (res) {
- /* Can we get/handle EPIPE here? */
- if (res == -ENODEV) {
- netif_device_detach(tp-netdev);
- } else {
- netif_warn(tp, tx_err, netdev,
- failed tx_urb %d\n, res);
- stats-tx_dropped++;
- spin_lock_irqsave(tp-tx_lock, flags);
- list_add_tail(agg-list, tp-tx_free);
- spin_unlock_irqrestore(tp-tx_lock, flags);
- }
- }
+ if (!list_empty(tp-tx_free))
+ tasklet_schedule(tp-tl);
return NETDEV_TX_OK;
}
--
1.8.3.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kvm: mmu: delay mmu audit activation
On Tue, Nov 19, 2013 at 03:22:47PM -0500, Sasha Levin wrote:
We should not be using jump labels before they were initialized. Push back
the callback to until after jump label initialization.
Signed-off-by: Sasha Levin sasha.le...@oracle.com
Applied, thanks.
---
arch/x86/kvm/mmu_audit.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/kvm/mmu_audit.c b/arch/x86/kvm/mmu_audit.c
index daff69e..1185fe7 100644
--- a/arch/x86/kvm/mmu_audit.c
+++ b/arch/x86/kvm/mmu_audit.c
@@ -296,4 +296,4 @@ static struct kernel_param_ops audit_param_ops = {
.get = param_get_bool,
};
-module_param_cb(mmu_audit, audit_param_ops, mmu_audit, 0644);
+arch_param_cb(mmu_audit, audit_param_ops, mmu_audit, 0644);
--
1.7.10.4
--
Gleb.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/7] Squashfs: add multi-threaded decompression using percpu variables (V2)
On 20/11/13 08:33, Minchan Kim wrote: On Wed, Nov 20, 2013 at 01:48:06AM +, Phillip Lougher wrote: Add a multi-threaded decompression implementation which uses percpu variables. Using percpu variables has advantages and disadvantages over implementations which do not use percpu variables. Advantages: * the nature of percpu variables ensures decompression is load-balanced across the multiple cores. * simplicity. Disadvantages: it limits decompression to one thread per core. V2: * squashfs_decompressor_create: improve error handling path, re freeing of decompressors and comp_opts * decompressor_multi_percpu.c: include percpu.h header * Kconfig: indentation Signed-off-by: Phillip Lougher phil...@squashfs.org.uk --- fs/squashfs/Kconfig | 57 ++- fs/squashfs/Makefile| 10 +--- fs/squashfs/decompressor_multi_percpu.c | 98 + 3 files changed, 145 insertions(+), 20 deletions(-) create mode 100644 fs/squashfs/decompressor_multi_percpu.c diff --git a/fs/squashfs/Kconfig b/fs/squashfs/Kconfig index 1c6d340..159bd66 100644 --- a/fs/squashfs/Kconfig +++ b/fs/squashfs/Kconfig @@ -25,6 +25,50 @@ config SQUASHFS If unsure, say N. +choice + prompt Decompressor parallelisation options Nitpick: How about adding default explicitly? default SQUASHFS_DECOMP_SINGLE I initially did that :-) only to get an error returned from kbuild that defaults on choices were not supported. PITA. + depends on SQUASHFS + help + Squashfs now supports three parallelisation options for + decompression. Each one exhibits various trade-offs between + decompression performance and CPU and memory usage. + + If in doubt, select Single threaded compression + +config SQUASHFS_DECOMP_SINGLE + bool Single threaded compression + help + Traditionally Squashfs has used single-threaded decompression. + Only one block (data or metadata) can be decompressed at any + one time. This limits CPU and memory usage to a minimum. + +config SQUASHFS_DECOMP_MULTI + bool Use multiple decompressors for parallel I/O + help + By default Squashfs uses a single decompressor but it gives + poor performance on parallel I/O workloads when using multiple CPU + machines due to waiting on decompressor availability. + + If you have a parallel I/O workload and your system has enough memory, + using this option may improve overall I/O performance. + + This decompressor implementation uses up to two parallel + decompressors per core. It dynamically allocates decompressors + on a demand basis. + +config SQUASHFS_DECOMP_MULTI_PERCPU + bool Use percpu multiple decompressors for parallel I/O + help + By default Squashfs uses a single decompressor but it gives + poor performance on parallel I/O workloads when using multiple CPU + machines due to waiting on decompressor availability. + + This decompressor implementation uses a maximum of one + decompressor per core. It uses percpu variables to ensure Minor: ^ unnecessary white space. Two spaces after the full stop, starting a new sentence? As a kid back in the 1970s and early 80s that's what I was taught. Maybe it's become old fashioned and I've not noticed. http://www.rednovalabs.com/generation-gap-one-space-or-two-after-a-period/ + decompression is load-balanced across the cores. Actually, I am not sure it's good idea to mention percpu in description. Normal people wouldn't know that and I think what they can want to know is what's benefit compared to SQUASHFS_DECOMP_MULTI. The people who have asked me for the percpu implementation will know :-) Some people want to have the percpu implementation. Some don't. Some people who want the percpu implementation *only* want the percpu implementation. Some people who don't want the percpu implementation *only* want the non-percpu implementation. People are different, and try as I might, that's not going to go away anytime soon. I have spent more time arguing over this 90 odd lines of code than anything else. Should I call the percpu implementation the new bike shed? Because that's how it seems to me at the moment. Life's too short to get hung up about this. I'm adding both implementations because that keeps more people happy than the alternative. Maybe I should just drop both implementations for this merge window, and invite everyone else to fight it out over which single implementation they want, and I'll take a ring side seat while it happens. How about this? This decompressor implementation uses a maximum of one decompressor per core and the decompressor is allocated statically so
Re: [PATCH 1/9] staging/lustre/llite: Access to released file trigs a restore
On Wed, Nov 20, 2013 at 3:35 PM, Peng Tao bergw...@gmail.com wrote: On Wed, Nov 20, 2013 at 2:29 AM, Greg Kroah-Hartman gre...@linuxfoundation.org wrote: trigs? Come on, we don't have a lack of characters here... Will fix up. On Tue, Nov 19, 2013 at 09:23:40PM +0800, Peng Tao wrote: From: JC Lafoucriere jacques-charles.lafoucri...@cea.fr When a client accesses data in a released file, or truncate it, client must trig a restore request. During this restore, the client must not glimpse and must use size from MDT. To bring the restore is running information on the client we add a new t_state bit field to mdt_info which will be used to carry transient file state. To memorise this information in the inode we add a new flag LLIF_FILE_RESTORING. Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3432 Lustre-change: http://review.whamcloud.com/6537 Signed-off-by: JC Lafoucriere jacques-charles.lafoucri...@cea.fr Reviewed-by: Oleg Drokin oleg.dro...@intel.com Tested-by: Oleg Drokin oleg.dro...@intel.com Signed-off-by: Peng Tao bergw...@gmail.com Signed-off-by: Andreas Dilger andreas.dil...@intel.com --- drivers/staging/lustre/lustre/include/cl_object.h |6 ++- .../lustre/lustre/include/lustre/lustre_idl.h | 14 +++-- drivers/staging/lustre/lustre/lclient/lcommon_cl.c |6 +++ drivers/staging/lustre/lustre/llite/file.c | 39 +- .../staging/lustre/lustre/llite/llite_internal.h |3 ++ drivers/staging/lustre/lustre/llite/llite_lib.c| 36 + drivers/staging/lustre/lustre/llite/vvp_io.c | 54 ++-- drivers/staging/lustre/lustre/lov/lov_io.c | 15 -- .../staging/lustre/lustre/ptlrpc/pack_generic.c|2 +- drivers/staging/lustre/lustre/ptlrpc/wiretest.c| 17 +++--- 10 files changed, 168 insertions(+), 24 deletions(-) This patch has checkpatch errors, sorry, please fix them before sending them again. The quoted string split across lines warning is a bit confusing. WARNING: quoted string split across lines #265: FILE: drivers/staging/lustre/lustre/llite/vvp_io.c:125: + CDEBUG(D_VFSTRACE, DFID ignore/verify layout %d/%d, layout version %d + restore needed %d\n, If I put the quoted string in the same line, I got WARNING: line over 80 characters #264: FILE: drivers/staging/lustre/lustre/llite/vvp_io.c:124: + CDEBUG(D_VFSTRACE, DFID ignore/verify layout %d/%d, layout version %d restore needed %d\n, So one way or another, the patch breaks a rule. Looking at scripts/checkpatch.pl commit log, I saw commit ca56dc098caf93b5437cd6c4ee49f02aa18f84d6 Author: Josh Triplett j...@joshtriplett.org Date: Fri Mar 23 15:02:21 2012 -0700 checkpatch: check for quoted strings broken across lines checkpatch already makes an exception to the 80-column rule for quoted strings, and Documentation/CodingStyle recommends not splitting quoted strings across lines, because it breaks the ability to grep for the string. Rather than just permitting this, actively warn about quoted strings split across lines. But it seems that the exception for quoted strings to the 80-column rule no longer holds? I found out that the quoted strings exception only applies to lines that have only quoted strings. I'll fix up. Thanks, Tao -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [f2fs-dev] [PATCH V2 2/2] f2fs: read contiguous sit entry pages by merging for mount performance
Hi Yu,
On 11/20/2013 01:37 PM, Chao Yu wrote:
Hi Gu,
-Original Message-
From: Gu Zheng [mailto:guz.f...@cn.fujitsu.com]
Sent: Monday, November 18, 2013 7:16 PM
To: Chao Yu
Cc: '???'; linux-fsde...@vger.kernel.org; linux-kernel@vger.kernel.org;
linux-f2fs-de...@lists.sourceforge.net; 谭姝
Subject: Re: [f2fs-dev] [PATCH V2 2/2] f2fs: read contiguous sit entry pages
by merging for mount performance
Hi Yu,
One more comment, please refer to inline.
On 11/16/2013 02:15 PM, Chao Yu wrote:
Previously we read sit entries page one by one, this method lost the chance
of reading contiguous page together.
So we read pages as contiguous as possible for better mount performance.
v1--v2:
o merge judgements/use 'Continue' or 'Break' instead of 'Goto' as Gu Zheng
suggested.
o add mark_page_accessed () before release page to delay VM reclaiming
them.
Signed-off-by: Chao Yu chao2...@samsung.com
---
fs/f2fs/segment.c | 108
-
fs/f2fs/segment.h |2 +
2 files changed, 84 insertions(+), 26 deletions(-)
diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
index fa284d3..656fe40 100644
--- a/fs/f2fs/segment.c
+++ b/fs/f2fs/segment.c
@@ -14,6 +14,7 @@
#include linux/blkdev.h
#include linux/prefetch.h
#include linux/vmalloc.h
+#include linux/swap.h
#include f2fs.h
#include segment.h
@@ -1480,41 +1481,96 @@ static int build_curseg(struct f2fs_sb_info *sbi)
return restore_curseg_summaries(sbi);
}
+static int ra_sit_pages(struct f2fs_sb_info *sbi, int start,
+ int nrpages, bool *is_order)
+{
+ struct address_space *mapping = sbi-meta_inode-i_mapping;
+ struct sit_info *sit_i = SIT_I(sbi);
+ struct page *page;
+ block_t blk_addr;
+ int blkno = start, readcnt = 0;
+ int sit_blk_cnt = SIT_BLK_CNT(sbi);
+
+ for (; blkno start + nrpages blkno sit_blk_cnt; blkno++) {
+
+ if ((!f2fs_test_bit(blkno, sit_i-sit_bitmap) ^ !*is_order)) {
+ *is_order = !*is_order;
+ break;
+ }
+
+ blk_addr = sit_i-sit_base_addr + blkno;
+ if (*is_order)
+ blk_addr += sit_i-sit_blocks;
+repeat:
+ page = grab_cache_page(mapping, blk_addr);
+ if (!page) {
+ cond_resched();
+ goto repeat;
+ }
+ if (PageUptodate(page)) {
+ mark_page_accessed(page);
+ f2fs_put_page(page, 1);
+ readcnt++;
+ continue;
+ }
+
+ submit_read_page(sbi, page, blk_addr, READ_SYNC);
+
+ mark_page_accessed(page);
+ f2fs_put_page(page, 0);
+ readcnt++;
+ }
+
+ f2fs_submit_read_bio(sbi, READ_SYNC);
+ return readcnt;
+}
+
static void build_sit_entries(struct f2fs_sb_info *sbi)
{
struct sit_info *sit_i = SIT_I(sbi);
struct curseg_info *curseg = CURSEG_I(sbi, CURSEG_COLD_DATA);
struct f2fs_summary_block *sum = curseg-sum_blk;
- unsigned int start;
-
- for (start = 0; start TOTAL_SEGS(sbi); start++) {
- struct seg_entry *se = sit_i-sentries[start];
- struct f2fs_sit_block *sit_blk;
- struct f2fs_sit_entry sit;
- struct page *page;
- int i;
+ bool is_order = f2fs_test_bit(0, sit_i-sit_bitmap) ? true : false;
+ int sit_blk_cnt = SIT_BLK_CNT(sbi);
+ unsigned int i, start, end;
+ unsigned int readed, start_blk = 0;
- mutex_lock(curseg-curseg_mutex);
- for (i = 0; i sits_in_cursum(sum); i++) {
- if (le32_to_cpu(segno_in_journal(sum, i)) == start) {
- sit = sit_in_journal(sum, i);
- mutex_unlock(curseg-curseg_mutex);
- goto got_it;
+ do {
How about using find_next_bit to get the suitable start_blk if the next blk
is not ordered here? And it also can simplify the logic of ra_sit_pages().
That's a good idea.
But I thought there maybe endianness problem between test_bit and
f2fs_test_bit, so find_next_bit may get wrong result. Am I right?
IMO, find_next_bit can do well with endianness issue internally, if
it's not so, that may be a weakness.
On the other side, why not introduce a 'f2fs_find_next_bit' if it's
seriously needed?:)
Regards,
Gu
Thanks,
Yu
Thanks,
Gu
+ readed = ra_sit_pages(sbi, start_blk, sit_blk_cnt, is_order);
+
+ start = start_blk * sit_i-sents_per_block;
+ end = (start_blk + readed) * sit_i-sents_per_block;
+
+ for (; start end start TOTAL_SEGS(sbi); start++) {
+ struct seg_entry *se = sit_i-sentries[start];
+ struct f2fs_sit_block *sit_blk;
+ struct f2fs_sit_entry sit;
+ struct page *page;
+
+
Re: 3.12: kernel panic when resuming from suspend to RAM (x86_64)
Hello Borislav, On 11/19/2013 11:15 AM, Borislav Petkov wrote: On Tue, Nov 19, 2013 at 11:01:14AM +0100, Francis Moreau wrote: I think the easiest way to do it is to install a minimal system on a USB stick and try to reproduce first in order to preserve my system. Yep, sounds simple enough. Then I'll try to see if this issue exists in a previous kernel version and if so, I'll do a git-bisect session. I can't find a quicker way to do that although using git-bisect (which implies several kernel builds) is a PITA. You can start with a coarse bisect by testing the major kernel versions first, i.e. 3.11, 3.10, 3.9 ... and once you find good and bad, then you can do the git-bisect thing. Unfortunately the bisect session didn't give any positive results: I couldn't be sure if a specific revision was good or bad because the bug wasn't reproductible every time. But I got a different kernel oops on my stripped system that may give us a clue: http://imgur.com/zdCknbY Does this help ? Thanks. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] PM / devfreq: Consider hibernation in pm notifier
On Tue, Nov 19, 2013 at 10:30 PM, Jonghwan Choi jhbird.c...@gmail.com wrote:
Frequency lock should be considered in suspend/hibernation.
Signed-off-by: Jonghwan Choi jhbird.c...@samsung.com
Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Applied in driver-update branch.
Do you want this to be synchronously merged with others (1/4, 2/4) or
is it ok to be done asynchronously?
Cheers,
MyungJoo.
---
drivers/devfreq/exynos/exynos4_bus.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/devfreq/exynos/exynos4_bus.c
b/drivers/devfreq/exynos/exynos4_bus.c
index cede6f7..dd6947e 100644
--- a/drivers/devfreq/exynos/exynos4_bus.c
+++ b/drivers/devfreq/exynos/exynos4_bus.c
@@ -962,6 +962,7 @@ static int exynos4_busfreq_pm_notifier_event(struct
notifier_block *this,
int err = 0;
switch (event) {
+ case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
/* Set Fastest and Deactivate DVFS */
mutex_lock(data-lock);
@@ -1005,6 +1006,7 @@ unlock:
if (err)
return err;
return NOTIFY_OK;
+ case PM_POST_HIBERNATION:
case PM_POST_RESTORE:
case PM_POST_SUSPEND:
/* Reactivate */
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] PM / devfreq: Consider hibernation in pm notifier
On Tue, Nov 19, 2013 at 10:30 PM, Jonghwan Choi jhbird.c...@gmail.com wrote:
Frequency lock should be considered in suspend/hibernation.
Signed-off-by: Jonghwan Choi jhbird.c...@samsung.com
Signed-off-by: MyungJoo Ham myungjoo@samsung.com
Cheers,
MyungJoo.
---
drivers/devfreq/exynos/exynos5_bus.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/devfreq/exynos/exynos5_bus.c
b/drivers/devfreq/exynos/exynos5_bus.c
index a60da3c..bd672de0 100644
--- a/drivers/devfreq/exynos/exynos5_bus.c
+++ b/drivers/devfreq/exynos/exynos5_bus.c
@@ -268,6 +268,7 @@ static int exynos5_busfreq_int_pm_notifier_event(struct
notifier_block *this,
int err = 0;
switch (event) {
+ case PM_HIBERNATION_PREPARE:
case PM_SUSPEND_PREPARE:
/* Set Fastest and Deactivate DVFS */
mutex_lock(data-lock);
@@ -300,6 +301,7 @@ unlock:
if (err)
return NOTIFY_BAD;
return NOTIFY_OK;
+ case PM_POST_HIBERNATION:
case PM_POST_RESTORE:
case PM_POST_SUSPEND:
/* Reactivate */
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-samsung-soc
in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/2] mmc: rtsx: fix card poweroff bug
From: Micky Ching micky_ch...@realsil.com.cn
If the host driver removed while card in the slot, the host will not
power off card power correctly. This bug is produced because host
eject flag set before the last mmc_set_ios callback, we should set the
eject flag after power off.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
---
drivers/mmc/host/rtsx_pci_sdmmc.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index 375a880e..c9a7328 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -1328,7 +1328,6 @@ static int rtsx_pci_sdmmc_drv_remove(struct
platform_device *pdev)
pcr-slots[RTSX_SD_CARD].p_dev = NULL;
pcr-slots[RTSX_SD_CARD].card_event = NULL;
mmc = host-mmc;
- host-eject = true;
mutex_lock(host-host_mutex);
if (host-mrq) {
@@ -1346,6 +1345,8 @@ static int rtsx_pci_sdmmc_drv_remove(struct
platform_device *pdev)
mutex_unlock(host-host_mutex);
mmc_remove_host(mmc);
+ host-eject = true;
+
mmc_free_host(mmc);
dev_dbg((pdev-dev),
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/2] fix sd power bug and modify phase-searching method
From: Micky Ching micky_ch...@realsil.com.cn If the driver removed while sd/mmc card still in the slot, the card power will not power down correctly, if we insert the driver module again, UHS card will not switch to UHS mode. This bug is fixed in this patch. We use another phase search method for tuning, which looks more simple, and reduce some source code. Micky Ching (2): mmc: rtsx: fix card poweroff bug mmc: rtsx: modify phase searching method for tunning drivers/mmc/host/rtsx_pci_sdmmc.c | 115 +++-- include/linux/mfd/rtsx_pci.h |3 +- 2 files changed, 36 insertions(+), 82 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC] Timer: Migrate running timers
Hi Thomas,
This was earlier discussed here (Well, Not much :)):
https://lkml.org/lkml/2012/11/6/160
I am floating the idea again to get more attention on this patch. This is just
an idea for now, haven't seen much testing..
Migration of timers from idle cores to non-idle ones for power saving is very
well working and really saves a lot of power for us. What's currently not
working is the migration of running timers Or timers which re-arms themselves.
There are complications with migrating timers which schedules themselves again
from their handler. del_timer_sync() can't detect that the timer's handler
yet has not finished.
__mod_timer migrates the timer with following code:
...
spin_lock(old_base-lock);
...
timer_set_base(timer, NULL);
spin_unlock(old_base-lock); -A
spin_lock(new_base-lock); -B
timer_set_base(timer, new_base);
...
After the unlock at time A, old_base-running_timer may get updated to the next
timer in queue. After lock at time B, lock_timer_base() will return new_base
where another timer might be running timer at that point of time.
Whereas, del_timer_sync() depends on below code to check if a timer's handler is
currently running or not.
if (base-running_timer != timer)
Because there is window where timer's handler would be running and at the same
time it wasn't marked as running timer for any of the bases (well, it matters
only for its current base, i.e. new_base). del_timer_sync() wouldn't know this
and will go on and delete the timer, whose handler is currently running.
The new approach tries to mark such timers with wait_for_migration_to_complete
flag (can be named better and some memory can be saved as PeterZ suggested),
which will be used in del_timer_sync() to see if the timer is currently
migrating and so isn't marked as running_timer of its base.
Benefits: Well, obviously saving power for a core which is being interrupted
again and again in its idle loop by this timer event. Which will also prevent
the core to go in deeper idle states if possible.
Please share your feedback on this approach.
Signed-off-by: Viresh Kumar viresh.ku...@linaro.org
---
include/linux/timer.h | 1 +
kernel/timer.c| 29 +
2 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/include/linux/timer.h b/include/linux/timer.h
index 8c5a197..ad00ebe 100644
--- a/include/linux/timer.h
+++ b/include/linux/timer.h
@@ -20,6 +20,7 @@ struct timer_list {
void (*function)(unsigned long);
unsigned long data;
+ int wait_for_migration_to_complete;
int slack;
diff --git a/kernel/timer.c b/kernel/timer.c
index 6582b82..30a93e6 100644
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -748,21 +748,15 @@ __mod_timer(struct timer_list *timer, unsigned long
expires,
new_base = per_cpu(tvec_bases, cpu);
if (base != new_base) {
- /*
-* We are trying to schedule the timer on the local CPU.
-* However we can't change timer's base while it is running,
-* otherwise del_timer_sync() can't detect that the timer's
-* handler yet has not finished. This also guarantees that
-* the timer is serialized wrt itself.
-*/
- if (likely(base-running_timer != timer)) {
- /* See the comment in lock_timer_base() */
- timer_set_base(timer, NULL);
- spin_unlock(base-lock);
- base = new_base;
- spin_lock(base-lock);
- timer_set_base(timer, base);
- }
+ if (base-running_timer == timer)
+ timer-wait_for_migration_to_complete = 1;
+
+ /* See the comment in lock_timer_base() */
+ timer_set_base(timer, NULL);
+ spin_unlock(base-lock);
+ base = new_base;
+ spin_lock(base-lock);
+ timer_set_base(timer, base);
}
timer-expires = expires;
@@ -992,7 +986,8 @@ int try_to_del_timer_sync(struct timer_list *timer)
base = lock_timer_base(timer, flags);
- if (base-running_timer != timer) {
+ if ((base-running_timer != timer)
+ !timer-wait_for_migration_to_complete) {
timer_stats_timer_clear_start_info(timer);
ret = detach_if_pending(timer, base, true);
}
@@ -1185,6 +1180,8 @@ static inline void __run_timers(struct tvec_base *base)
call_timer_fn(timer, fn, data);
spin_lock_irq(base-lock);
}
+ if (timer-wait_for_migration_to_complete)
+ timer-wait_for_migration_to_complete = 0;
}
}
base-running_timer = NULL;
--
[PATCH v2 2/2] mmc: rtsx: modify phase searching method for tunning
From: Micky Ching micky_ch...@realsil.com.cn
The new phase searching method is more concise and easier to
understand.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
---
drivers/mmc/host/rtsx_pci_sdmmc.c | 112 +++--
include/linux/mfd/rtsx_pci.h |3 +-
2 files changed, 34 insertions(+), 81 deletions(-)
diff --git a/drivers/mmc/host/rtsx_pci_sdmmc.c
b/drivers/mmc/host/rtsx_pci_sdmmc.c
index c9a7328..0f4acb8 100644
--- a/drivers/mmc/host/rtsx_pci_sdmmc.c
+++ b/drivers/mmc/host/rtsx_pci_sdmmc.c
@@ -31,16 +31,6 @@
#include linux/mfd/rtsx_pci.h
#include asm/unaligned.h
-/* SD Tuning Data Structure
- * Record continuous timing phase path
- */
-struct timing_phase_path {
- int start;
- int end;
- int mid;
- int len;
-};
-
struct realtek_pci_sdmmc {
struct platform_device *pdev;
struct rtsx_pcr *pcr;
@@ -511,85 +501,47 @@ static int sd_change_phase(struct realtek_pci_sdmmc *host,
return 0;
}
-static u8 sd_search_final_phase(struct realtek_pci_sdmmc *host, u32 phase_map)
+static inline u32 test_phase_bit(u32 phase_map, unsigned int bit)
{
- struct timing_phase_path path[MAX_PHASE + 1];
- int i, j, cont_path_cnt;
- int new_block, max_len, final_path_idx;
- u8 final_phase = 0xFF;
+ bit = RTSX_PHASE_MASK;
+ return phase_map (1 bit);
+}
- /* Parse phase_map, take it as a bit-ring */
- cont_path_cnt = 0;
- new_block = 1;
- j = 0;
- for (i = 0; i MAX_PHASE + 1; i++) {
- if (phase_map (1 i)) {
- if (new_block) {
- new_block = 0;
- j = cont_path_cnt++;
- path[j].start = i;
- path[j].end = i;
- } else {
- path[j].end = i;
- }
- } else {
- new_block = 1;
- if (cont_path_cnt) {
- /* Calculate path length and middle point */
- int idx = cont_path_cnt - 1;
- path[idx].len =
- path[idx].end - path[idx].start + 1;
- path[idx].mid =
- path[idx].start + path[idx].len / 2;
- }
- }
- }
+static int sd_get_phase_len(u32 phase_map, unsigned int start_bit)
+{
+ int i;
- if (cont_path_cnt == 0) {
- dev_dbg(sdmmc_dev(host), No continuous phase path\n);
- goto finish;
- } else {
- /* Calculate last continuous path length and middle point */
- int idx = cont_path_cnt - 1;
- path[idx].len = path[idx].end - path[idx].start + 1;
- path[idx].mid = path[idx].start + path[idx].len / 2;
+ for (i = 0; i RTSX_PHASE_MAX; i++) {
+ if (test_phase_bit(phase_map, start_bit + i) == 0)
+ return i;
}
+ return RTSX_PHASE_MAX;
+}
+
+static u8 sd_search_final_phase(struct realtek_pci_sdmmc *host, u32 phase_map)
+{
+ int start = 0, len = 0;
+ int start_final = 0, len_final = 0;
+ u8 final_phase = 0xFF;
- /* Connect the first and last continuous paths if they are adjacent */
- if (!path[0].start (path[cont_path_cnt - 1].end == MAX_PHASE)) {
- /* Using negative index */
- path[0].start = path[cont_path_cnt - 1].start - MAX_PHASE - 1;
- path[0].len += path[cont_path_cnt - 1].len;
- path[0].mid = path[0].start + path[0].len / 2;
- /* Convert negative middle point index to positive one */
- if (path[0].mid 0)
- path[0].mid += MAX_PHASE + 1;
- cont_path_cnt--;
+ if (phase_map == 0) {
+ dev_err(sdmmc_dev(host), phase error: [map:%x]\n, phase_map);
+ return final_phase;
}
- /* Choose the longest continuous phase path */
- max_len = 0;
- final_phase = 0;
- final_path_idx = 0;
- for (i = 0; i cont_path_cnt; i++) {
- if (path[i].len max_len) {
- max_len = path[i].len;
- final_phase = (u8)path[i].mid;
- final_path_idx = i;
+ while (start RTSX_PHASE_MAX) {
+ len = sd_get_phase_len(phase_map, start);
+ if (len_final len) {
+ start_final = start;
+ len_final = len;
}
-
- dev_dbg(sdmmc_dev(host), path[%d].start = %d\n,
- i, path[i].start);
- dev_dbg(sdmmc_dev(host), path[%d].end = %d\n,
- i, path[i].end);
-
Re: [PATCH] PCI: Init NumVFs register to zero in sriov_init()
Bjorn, To be honest, the output above is picked up from other guy's mail, because I composed the patch mail at home and left the real bug material at company, they 'really' hit an issue confused by lspci output while SR-IOV is initialized to disabled . There is an error in above output as description that not made on purpose, sorry again, the IOVCtl: Enable+ should be IOVCtl: Enable- Current iov.c code, in fact, initializing the SR-IOV to disabled whatever BIOS setup the PCI_SRIOV_XX registers. Thanks, Ethan On Wed, Nov 20, 2013 at 8:07 AM, Bjorn Helgaas bhelg...@google.com wrote: On Tue, Nov 19, 2013 at 3:24 PM, Bjorn Helgaas bhelg...@google.com wrote: [+cc linux-pci] On Wed, Nov 6, 2013 at 7:49 AM, ethan.zhao ethan.ker...@gmail.com wrote: Though no specification about NumVFs register initial value after POST, to void the confusion lspci output as following before VF was enabled, we should clear the NumVFs value left by BIOS to zero: $lspci -vvv -s 03:00.0 Ethernet controller: Intel Corporation 82599EB 10-Gigabit SFI/SFP+ Network Connection (rev 01) ~ Capabilities: [160 v1] Single Root I/O Virtualization (SR-IOV) IOVCap: Migration-, Interrupt Message Number: 000 IOVCtl: Enable+ Migration- Interrupt- MSE+ ARIHierarchy+ IOVSta: Migration- Initial VFs: 64, Total VFs: 64, Number of VFs: 64, Function Dependency Link: 00 ^dazed ! Did you mean to show lspci output from before SR-IOV was enabled? It looks like SR-IOV is enabled here, so I don't think your patch would change this output at all. Bjorn -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] PM / devfreq: Consider hibernation in pm notifier
On Wed, Nov 20, 2013 at 7:08 AM, Sebastian Capella sebastian.cape...@linaro.org wrote: Quoting Bartlomiej Zolnierkiewicz (2013-11-19 06:50:05) Hi, Are you planning to add hibernation support to ARM? If so then this should be stated somewhere in the patch description. OTOH if you are not going to add hibernation support to ARM I see a little sense in adding hibernation support to ARM-only drivers.. FYI, we at Linaro and a few others have been working on adding hibernation support for ARM. I have not coordinated with Jonghwan however. That is great. We once tried to upstream hibernation support and forgot it for a while, too. http://lists.infradead.org/pipermail/linux-arm-kernel/2010-December/036101.html I have not coordinated with Jonghwan Choi, either. However, it appears that some others are trying now, too. Cheers, MyungJoo Apoligies for the earlier toppost. Thanks, Sebastian Capella -- To unsubscribe from this list: send the line unsubscribe linux-samsung-soc in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- MyungJoo Ham, Ph.D. System S/W Lab, S/W Center, Samsung Electronics -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/5] f2fs: move the list_head initialization into the lock protection region
Hi Kim,
On 11/20/2013 09:31 AM, Jaegeuk Kim wrote:
Hi Gu,
IMO, there is no reason to cover the list header by the lock.
In any flows, sbi should have the header all the time.
Yes, you're right.
What is your opinion?
Moving the list_head initialization into the lock protection region, so
that we can ignore the list change during the gap(initialization--use).
And on the other side, it can keep the code style uniform for better
maintenance.
Regards,
Gu
Thanks,
2013-11-19 (화), 18:03 +0800, Gu Zheng:
Signed-off-by: Gu Zheng guz.f...@cn.fujitsu.com
---
fs/f2fs/checkpoint.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index f884589..1de70cc 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -511,8 +511,8 @@ void add_dirty_dir_inode(struct inode *inode)
void remove_dirty_dir_inode(struct inode *inode)
{
struct f2fs_sb_info *sbi = F2FS_SB(inode-i_sb);
-struct list_head *head = sbi-dir_inode_list;
-struct list_head *this;
+
+struct list_head *this, *head;
if (!S_ISDIR(inode-i_mode))
return;
@@ -523,6 +523,7 @@ void remove_dirty_dir_inode(struct inode *inode)
return;
}
+head = sbi-dir_inode_list;
list_for_each(this, head) {
struct dir_inode_entry *entry;
entry = list_entry(this, struct dir_inode_entry, list);
@@ -544,11 +545,13 @@ void remove_dirty_dir_inode(struct inode *inode)
struct inode *check_dirty_dir_inode(struct f2fs_sb_info *sbi, nid_t ino)
{
-struct list_head *head = sbi-dir_inode_list;
-struct list_head *this;
+
+struct list_head *this, *head;
struct inode *inode = NULL;
spin_lock(sbi-dir_inode_lock);
+
+head = sbi-dir_inode_list;
list_for_each(this, head) {
struct dir_inode_entry *entry;
entry = list_entry(this, struct dir_inode_entry, list);
@@ -563,11 +566,13 @@ struct inode *check_dirty_dir_inode(struct
f2fs_sb_info *sbi, nid_t ino)
void sync_dirty_dir_inodes(struct f2fs_sb_info *sbi)
{
-struct list_head *head = sbi-dir_inode_list;
+struct list_head *head;
struct dir_inode_entry *entry;
struct inode *inode;
retry:
spin_lock(sbi-dir_inode_lock);
+
+head = sbi-dir_inode_list;
if (list_empty(head)) {
spin_unlock(sbi-dir_inode_lock);
return;
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: IRQF_RESUME_EARLY and errors in dpm_suspend_noirq
On Wednesday 20 November 2013 02:50 PM, Heiko Stübner wrote: Hi, Commit 9bab0b7fbace (genirq: Add IRQF_RESUME_EARLY and resume such IRQs earlier) split the suspend/resume of the irqs into two parts. The early-irqs get resumed during syscore_resume, while the rest get resumed by the regular resume_device_irqs. I may be blind, but where get the early-irqs resumed in the error path of dpm_suspend_noirq? When a suspend_noirq callback returns an error, dpm_resume_noirq gets called, which only calls resume_device_irqs while the suspend_device_irqs call in dpm_suspend_noirq suspends all irqs. So it does not seem that the early-irqs get resumed at all in this case. I also faced same issue in our suspend failure path and posted fix sometime ago as https://lkml.org/lkml/2013/8/13/373 It is still under review. You can try this patch if it resolve the issue. Thanks, Laxman -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] sysfs: handle duplicate removal attempts in sysfs_remove_group()
Commit bcdde7e221a8 (sysfs: make __sysfs_remove_dir() recursive) changed
the behavior so that directory removals will be done recursively. This
means that the sysfs group might already be removed if its parent directory
has been removed.
The current code outputs warnings similar to following log snippet when it
detects that there is no group for the given kobject:
WARNING: CPU: 0 PID: 4 at fs/sysfs/group.c:214 sysfs_remove_group+0xc6/0xd0()
sysfs group 81c6f1e0 not found for kobject 'host7'
Modules linked in:
CPU: 0 PID: 4 Comm: kworker/0:0 Not tainted 3.12.0+ #13
Hardware name: /D33217CK, BIOS
GKPPT10H.86A.0042.2013.0422.1439 04/22/2013
Workqueue: kacpi_hotplug acpi_hotplug_work_fn
0009 8801002459b0 817daab1 8801002459f8
8801002459e8 810436b8 81c6f1e0
88006d440358 88006d440188 88006e8b4c28 880100245a48
Call Trace:
[817daab1] dump_stack+0x45/0x56
[810436b8] warn_slowpath_common+0x78/0xa0
[81043727] warn_slowpath_fmt+0x47/0x50
[811ad319] ? sysfs_get_dirent_ns+0x49/0x70
[811ae526] sysfs_remove_group+0xc6/0xd0
[81432f7e] dpm_sysfs_remove+0x3e/0x50
[8142a0d0] device_del+0x40/0x1b0
[8142a24d] device_unregister+0xd/0x20
[8144131a] scsi_remove_host+0xba/0x110
[8145f526] ata_host_detach+0xc6/0x100
[8145f578] ata_pci_remove_one+0x18/0x20
[812e8f48] pci_device_remove+0x28/0x60
[8142d854] __device_release_driver+0x64/0xd0
[8142d8de] device_release_driver+0x1e/0x30
[8142d257] bus_remove_device+0xf7/0x140
[8142a1b1] device_del+0x121/0x1b0
[812e43d4] pci_stop_bus_device+0x94/0xa0
[812e437b] pci_stop_bus_device+0x3b/0xa0
[812e437b] pci_stop_bus_device+0x3b/0xa0
[812e44dd] pci_stop_and_remove_bus_device+0xd/0x20
[812fc743] trim_stale_devices+0x73/0xe0
[812fc78b] trim_stale_devices+0xbb/0xe0
[812fc78b] trim_stale_devices+0xbb/0xe0
[812fcb6e] acpiphp_check_bridge+0x7e/0xd0
[812fd90d] hotplug_event+0xcd/0x160
[812fd9c5] hotplug_event_work+0x25/0x60
[81316749] acpi_hotplug_work_fn+0x17/0x22
[8105cf3a] process_one_work+0x17a/0x430
[8105db29] worker_thread+0x119/0x390
[8105da10] ? manage_workers.isra.25+0x2a0/0x2a0
[81063a5d] kthread+0xcd/0xf0
[81063990] ? kthread_create_on_node+0x180/0x180
[817eb33c] ret_from_fork+0x7c/0xb0
[81063990] ? kthread_create_on_node+0x180/0x180
On this particular machine I see ~16 of these message during Thunderbolt
hot-unplug.
Fix this in similar way that was done for sysfs_remove_one() by checking
if the parent directory has already been removed and bailing out early.
Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
Acked-by: Tejun Heo t...@kernel.org
---
fs/sysfs/group.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/fs/sysfs/group.c b/fs/sysfs/group.c
index 1898a10e38ce..3796afdff40c 100644
--- a/fs/sysfs/group.c
+++ b/fs/sysfs/group.c
@@ -206,6 +206,15 @@ void sysfs_remove_group(struct kobject *kobj,
struct sysfs_dirent *dir_sd = kobj-sd;
struct sysfs_dirent *sd;
+ /*
+* Sysfs directories are now removed recursively by
+* sysfs_remove_dir(). This means that the function can be called
+* for a group whose sysfs entry is already removed. In that case
+* all its groups are guaranteed to be already removed.
+*/
+ if (dir_sd-s_flags SYSFS_FLAG_REMOVED)
+ return;
+
if (grp-name) {
sd = sysfs_get_dirent(dir_sd, grp-name);
if (!sd) {
--
1.8.4.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] memstick: rtsx: fix ms card data transfer bug
From: Micky Ching micky_ch...@realsil.com.cn
This patch is used to add support for ms card. The main difference
between ms card and mspro card is long data transfer mode. mspro card
can use auto mode DMA for long data transfer, but ms can not use this
mode, it should use normal mode DMA.
The memstick core add support for ms card, but the original driver will
make ms card fail at initialize, because it use auto mode DMA. This
patch can make ms card work properly.
Signed-off-by: Micky Ching micky_ch...@realsil.com.cn
---
drivers/memstick/host/rtsx_pci_ms.c | 30 --
1 file changed, 20 insertions(+), 10 deletions(-)
diff --git a/drivers/memstick/host/rtsx_pci_ms.c
b/drivers/memstick/host/rtsx_pci_ms.c
index 25f8f93..2a635b6 100644
--- a/drivers/memstick/host/rtsx_pci_ms.c
+++ b/drivers/memstick/host/rtsx_pci_ms.c
@@ -145,6 +145,8 @@ static int ms_transfer_data(struct realtek_pci_ms *host,
unsigned char data_dir,
unsigned int length = sg-length;
u16 sec_cnt = (u16)(length / 512);
u8 val, trans_mode, dma_dir;
+ struct memstick_dev *card = host-msh-card;
+ bool pro_card = card-id.type == MEMSTICK_TYPE_PRO;
dev_dbg(ms_dev(host), %s: tpc = 0x%02x, data_dir = %s, length = %d\n,
__func__, tpc, (data_dir == READ) ? READ : WRITE,
@@ -152,19 +154,21 @@ static int ms_transfer_data(struct realtek_pci_ms *host,
unsigned char data_dir,
if (data_dir == READ) {
dma_dir = DMA_DIR_FROM_CARD;
- trans_mode = MS_TM_AUTO_READ;
+ trans_mode = pro_card ? MS_TM_AUTO_READ : MS_TM_NORMAL_READ;
} else {
dma_dir = DMA_DIR_TO_CARD;
- trans_mode = MS_TM_AUTO_WRITE;
+ trans_mode = pro_card ? MS_TM_AUTO_WRITE : MS_TM_NORMAL_WRITE;
}
rtsx_pci_init_cmd(pcr);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, MS_TPC, 0xFF, tpc);
- rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, MS_SECTOR_CNT_H,
- 0xFF, (u8)(sec_cnt 8));
- rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, MS_SECTOR_CNT_L,
- 0xFF, (u8)sec_cnt);
+ if (pro_card) {
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, MS_SECTOR_CNT_H,
+ 0xFF, (u8)(sec_cnt 8));
+ rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, MS_SECTOR_CNT_L,
+ 0xFF, (u8)sec_cnt);
+ }
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, MS_TRANS_CFG, 0xFF, cfg);
rtsx_pci_add_cmd(pcr, WRITE_REG_CMD, IRQSTAT0,
@@ -192,8 +196,14 @@ static int ms_transfer_data(struct realtek_pci_ms *host,
unsigned char data_dir,
}
rtsx_pci_read_register(pcr, MS_TRANS_CFG, val);
- if (val (MS_INT_CMDNK | MS_INT_ERR | MS_CRC16_ERR | MS_RDY_TIMEOUT))
- return -EIO;
+ if (pro_card) {
+ if (val (MS_INT_CMDNK | MS_INT_ERR |
+ MS_CRC16_ERR | MS_RDY_TIMEOUT))
+ return -EIO;
+ } else {
+ if (val (MS_CRC16_ERR | MS_RDY_TIMEOUT))
+ return -EIO;
+ }
return 0;
}
@@ -462,8 +472,8 @@ static int rtsx_pci_ms_set_param(struct memstick_host *msh,
clock = 1900;
ssc_depth = RTSX_SSC_DEPTH_500K;
- err = rtsx_pci_write_register(pcr, MS_CFG,
- 0x18, MS_BUS_WIDTH_1);
+ err = rtsx_pci_write_register(pcr, MS_CFG, 0x58,
+ MS_BUS_WIDTH_1 | PUSH_TIME_DEFAULT);
if (err 0)
return err;
} else if (value == MEMSTICK_PAR4) {
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [to-be-updated] mm-memcg-add-memoryoom_control-notification-for-system-oom.patch removed from -mm tree
On Wed 20-11-13 00:05:18, David Rientjes wrote: On Tue, 19 Nov 2013, a...@linux-foundation.org wrote: Subject: [to-be-updated] mm-memcg-add-memoryoom_control-notification-for-system-oom.patch removed from -mm tree To: rient...@google.com,han...@cmpxchg.org,kamezawa.hir...@jp.fujitsu.com,mho...@suse.cz,mm-comm...@vger.kernel.org From: a...@linux-foundation.org Date: Tue, 19 Nov 2013 13:38:14 -0800 The patch titled Subject: mm, memcg: add memory.oom_control notification for system oom has been removed from the -mm tree. Its filename was mm-memcg-add-memoryoom_control-notification-for-system-oom.patch This patch was dropped because an updated version will be merged Why is this removed? I've asked Andrew to drop it for now (you were CCed) and mentioned my reasons. I've laid out my perspective for doing userspace oom handling and this is a vital part for system oom handling. I know that we are currently discussing alternative proposals but my proposal is by far the most complete and allows the most powerful policies to be implemented in userspace. I'd prefer if we would keep the patch unless an actual alternative is proposed and agreed upon, we can still discuss alternatives while this in -mm and this patch in no way precludes other mechanisms from being implemented. So why remove this? This is a user interface visible change. I do not want to do it until we agree on a way to go. I do not see any advantage of having this in -mm until then. It doesn't need any testing from -next (does it?) and the code is simple enough to push it later on without troubles if the memcg.oom_control is considered as a way to go. I do not see any reason to rush it in now. -- Michal Hocko SUSE Labs -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: at91: remove redundant dependency
On 20/11/2013 08:23, Michael Opdenacker : From: Yanis Moreno yanis.moren...@gmail.com This removes the depends on SOC_SAM_V7 statement in a Kconfig section that's under an if SOC_SAM_V7 condition (same parameter). Signed-off-by: Yanis Moreno yanis.moren...@gmail.com Reviewed-by: Michael Opdenacker michael.opdenac...@free-electrons.com Acked-by: Nicolas Ferre nicolas.fe...@atmel.com Thanks for this fix. Integrated in at91-3.14-cleanup branch. Best regards. --- arch/arm/mach-at91/Kconfig |1 - 1 file changed, 1 deletion(-) diff --git a/arch/arm/mach-at91/Kconfig b/arch/arm/mach-at91/Kconfig index 699b71e..d1b3fe5 100644 --- a/arch/arm/mach-at91/Kconfig +++ b/arch/arm/mach-at91/Kconfig @@ -61,7 +61,6 @@ comment Atmel AT91 Processor if SOC_SAM_V7 config SOC_SAMA5D3 bool SAMA5D3 family - depends on SOC_SAM_V7 select SOC_SAMA5 select HAVE_FB_ATMEL select HAVE_AT91_DBGU1 -- Nicolas Ferre -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] ASoC: wm5110: Expose input high pass filter controls
On Wed, Nov 20, 2013 at 09:16:36AM +, Lee Jones wrote: For the MFD parts: Acked-by: Lee Jones lee.jo...@linaro.org How do you want to play this ASoC? I expect this to collide with future changes from Wolfson so it'll need to go via ASoC. signature.asc Description: Digital signature
BUG: Patch Convert some mftb/mftbu into mfspr breaks MPC885
Scott, The patch Convert some mftb/mftbu into mfspr (beb2dc0a7a84be003ce54e98b95d65cc66e6e536) breaks startup on MPC885. The CPU traps (SoftwareEmulation trap) at sched_clock() when trying to read TBU with mfspr. Reverting the patch solves the issue. What's the prefered way to fix this ? Christophe -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, acpi, idle: Restructure the mwait idle routines
On Tue, Nov 19, 2013 at 01:06:30PM -0800, Jacob Pan wrote: On Tue, 19 Nov 2013 16:13:38 +0100 Peter Zijlstra pet...@infradead.org wrote: On Tue, Nov 19, 2013 at 03:51:43PM +0100, Peter Zijlstra wrote: That said, that drive is completely wrecked. It uses preempt_enable_no_resched() wrong too, it has uncommented barriers.. Dude, wtf are you guys smoking? I applied this patch on top of upstream kernel (801a760) and found out my machine completely failed to enter idle when nothing is running. turbostate shows 100% C0. ftrace shows kernel coming in and out of idle frequently. Both ACPI idle and intel_idle behaves the same way. I have to do the following change to allow entering C-states again. diff --git a/arch/x86/include/asm/mwait.h b/arch/x86/include/asm/mwait.h index 80014da..b51d1e1 100644 --- a/arch/x86/include/asm/mwait.h +++ b/arch/x86/include/asm/mwait.h @@ -49,10 +49,8 @@ static inline void mwait_idle_with_hints(unsigned long eax, unsigned long ecx) clflush((void *)current_thread_info()-flags); __monitor((void *)current_thread_info()-flags, 0, 0); - if (!current_set_polling_and_test()) +if (!need_resched()) __mwait(eax, ecx); - - __current_clr_polling(); } #endif /* _ASM_X86_MWAIT_H */ That doesn't make any sense; current_set_polling_and_test() returns the same thing need_resched() does. But you're right, intel_idle resides 100% in C0 and acpi_idle has 100% C1 residency... most weird. /me goes prod at it -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH net 1/3] virtio-net: drop the rest of buffers when we can't allocate skb
On Wed, Nov 20, 2013 at 05:07:25PM +0800, Jason Wang wrote:
When mergeable buffer were used, we only put the first page buf leave the rest
of buffers in the virt queue. This will cause the driver could not get the
correct head buffer any more. Fix this by dropping the rest of buffers for
this
packet.
The bug was introduced by commit 9ab86bbcf8be755256f0a5e994e0b38af6b4d399
(virtio_net: Defer skb allocation in receive path).
Cc: Rusty Russell ru...@rustcorp.com.au
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Michael Dalton mwdal...@google.com
Cc: Eric Dumazet eduma...@google.com
Cc: Shirley Ma x...@us.ibm.com
Signed-off-by: Jason Wang jasow...@redhat.com
---
This patch was needed for stable
---
drivers/net/virtio_net.c | 18 +-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 7bab4de..24fd502 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -222,6 +222,17 @@ static void skb_xmit_done(struct virtqueue *vq)
netif_wake_subqueue(vi-dev, vq2txq(vq));
}
+static void drop_mergeable_buffer(struct receive_queue *rq, int num_buf)
+{
+ char *buf;
+ int len;
+
+ while (--num_buf (buf = virtqueue_get_buf(rq-vq, len)) != NULL) {
+ --rq-num;
+ put_page(virt_to_head_page(buf));
+ }
+}
+
This is the same code we have in receive_mergeable anyway.
So let's reuse that.
/* Called from bottom half context */
static struct sk_buff *page_to_skb(struct receive_queue *rq,
struct page *page, unsigned int offset,
@@ -237,8 +248,13 @@ static struct sk_buff *page_to_skb(struct receive_queue
*rq,
/* copy small packet so we can reuse these pages for small data */
skb = netdev_alloc_skb_ip_align(vi-dev, GOOD_COPY_LEN);
- if (unlikely(!skb))
+ if (unlikely(!skb)) {
+ if (vi-mergeable_rx_bufs) {
+ hdr = (struct skb_vnet_hdr *)p;
+ drop_mergeable_buffer(rq, hdr-mhdr.num_buffers);
+ }
return NULL;
+ }
hdr = skb_vnet_hdr(skb);
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 09/10] ARM: dts: omap3-beagle-xm: Add USB Host support
Nishant,
On 11/19/2013 11:05 PM, Nishanth Menon wrote:
On 09/24/2013 03:53 AM, Roger Quadros wrote:
Provide RESET GPIO and Power regulator for the USB PHY,
the USB Host port mode and the PHY device for the controller.
Also provide pin multiplexer information for USB host pins.
We also relocate omap3_pmx_core pin definations so that they
are close to omap3_pmx_wkup pin definations.
Signed-off-by: Roger Quadros rog...@ti.com
---
just using this thread, but a question -
I am kernel * master dec8e46 Merge
tag 'arc-v3.13-rc1-part2' of
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc
and I see that VAUX2 which supplies USB_1V8[1] is not enabled - I did
a quick patch and it did seem to work (Usb keyboard, networking, mouse
etc on my ehci ports seems to come up good) - any suggestions how we'd
like to handle this?
It worked for me without your patch. It could be that u-boot is enabling
that regulator for me. I'm on u-boot-v2013.10.
In any case, your patch seems the right thing to do. We should take it in
the rc cycle.
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -169,6 +169,14 @@
bus-width = 8;
};
+vaux2 {
+ regulator-name = HubPower;
+ regulator-min-microvolt = 180;
+ regulator-max-microvolt = 180;
+ regulator-always-on;
+};
+
+
[1]
https://github.com/CircuitCo/BeagleBoard-xM-RevC/blob/master/BeagleBoard-xM_revC_SCH.pdf?raw=true
cheers,
-roger
arch/arm/boot/dts/omap3-beagle-xm.dts | 65
-
1 files changed, 56 insertions(+), 9 deletions(-)
diff --git a/arch/arm/boot/dts/omap3-beagle-xm.dts
b/arch/arm/boot/dts/omap3-beagle-xm.dts
index afdb164..b081f5a 100644
--- a/arch/arm/boot/dts/omap3-beagle-xm.dts
+++ b/arch/arm/boot/dts/omap3-beagle-xm.dts
@@ -69,6 +69,23 @@
};
};
+
+/* HS USB Port 2 Power */
+hsusb2_power: hsusb2_power_reg {
+compatible = regulator-fixed;
+regulator-name = hsusb2_vbus;
+regulator-min-microvolt = 330;
+regulator-max-microvolt = 330;
+gpio = twl_gpio 18 0;/* GPIO LEDA */
+startup-delay-us = 7;
+};
+
+/* HS USB Host PHY on PORT 2 */
+hsusb2_phy: hsusb2_phy {
+compatible = usb-nop-xceiv;
+reset-gpios = gpio5 19 GPIO_ACTIVE_LOW; /* gpio_147 */
+vcc-supply = hsusb2_power;
+};
};
omap3_pmx_wkup {
@@ -79,6 +96,37 @@
};
};
+omap3_pmx_core {
+pinctrl-names = default;
+pinctrl-0 =
+hsusbb2_pins
+;
+
+uart3_pins: pinmux_uart3_pins {
+pinctrl-single,pins =
+0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /*
uart3_rx_irrx.uart3_rx_irrx */
+0x170 (PIN_OUTPUT | MUX_MODE0) /*
uart3_tx_irtx.uart3_tx_irtx OUTPUT | MODE0 */
+;
+};
+
+hsusbb2_pins: pinmux_hsusbb2_pins {
+pinctrl-single,pins =
+0x5c0 (PIN_OUTPUT | MUX_MODE3) /*
etk_d10.hsusb2_clk */
+0x5c2 (PIN_OUTPUT | MUX_MODE3) /*
etk_d11.hsusb2_stp */
+0x5c4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d12.hsusb2_dir */
+0x5c6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d13.hsusb2_nxt */
+0x5c8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d14.hsusb2_data0 */
+0x5cA (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
etk_d15.hsusb2_data1 */
+0x1a4 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi1_cs3.hsusb2_data2 */
+0x1a6 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_clk.hsusb2_data7 */
+0x1a8 (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_simo.hsusb2_data4 */
+0x1aa (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_somi.hsusb2_data5 */
+0x1ac (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs0.hsusb2_data6 */
+0x1ae (PIN_INPUT_PULLDOWN | MUX_MODE3) /*
mcspi2_cs1.hsusb2_data3 */
+;
+};
+};
+
i2c1 {
clock-frequency = 260;
@@ -148,15 +196,6 @@
power = 50;
};
-omap3_pmx_core {
-uart3_pins: pinmux_uart3_pins {
-pinctrl-single,pins =
-0x16e (PIN_INPUT | PIN_OFF_WAKEUPENABLE | MUX_MODE0) /*
uart3_rx_irrx.uart3_rx_irrx */
-0x170 (PIN_OUTPUT | MUX_MODE0) /*
uart3_tx_irtx.uart3_tx_irtx OUTPUT | MODE0 */
-;
-};
-};
-
uart3 {
pinctrl-names = default;
pinctrl-0 = uart3_pins;
@@ -166,3 +205,11 @@
pinctrl-names = default;
pinctrl-0 = gpio1_pins;
};
+
+usbhshost {
+port2-mode = ehci-phy;
+};
+
+usbhsehci {
+phys = 0 hsusb2_phy;
+};
--
To unsubscribe from this list: send
Re: [PATCH net 2/3] virtio-net: fix num calculation on frag skb allocation failure
On Wed, Nov 20, 2013 at 05:07:26PM +0800, Jason Wang wrote:
We need decrease the rq-num after we can get a buf through
virtqueue_get_buf() even if we could not allocate frag skb. Otherwise, the
refill routine won't be triggered under heavy memory stress since the driver
may
still think there's enough room.
This bug was introduced by commit 2613af0ed18a11d5c566a81f9a6510b73180660a
(virtio_net: migrate mergeable rx buffers to page frag allocators).
Cc: Rusty Russell ru...@rustcorp.com.au
Cc: Michael S. Tsirkin m...@redhat.com
Cc: Michael Dalton mwdal...@google.com
Cc: Eric Dumazet eduma...@google.com
Signed-off-by: Jason Wang jasow...@redhat.com
So let's wrap virtqueue_get_buf to make sure we get it right?
---
The patch was needed for 3.12 stable.
---
drivers/net/virtio_net.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 24fd502..de1d6ca 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -333,6 +333,7 @@ static int receive_mergeable(struct receive_queue *rq,
struct sk_buff *head_skb)
head_skb-dev-stats.rx_length_errors++;
return -EINVAL;
}
+ --rq-num;
if (unlikely(len MERGE_BUFFER_LEN)) {
pr_debug(%s: rx error: merge buffer too long\n,
head_skb-dev-name);
@@ -367,7 +368,6 @@ static int receive_mergeable(struct receive_queue *rq,
struct sk_buff *head_skb)
skb_add_rx_frag(curr_skb, num_skb_frags, page,
offset, len, MERGE_BUFFER_LEN);
}
- --rq-num;
}
return 0;
}
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 0/7] crypto: at91/atmel: add Device Tree support
On 08/11/2013 16:08, Nicolas Ferre : This series adds Device Tree support to the Atmel crypto drivers (AES/[T]DES/SHA). The Device Tree entries are very simple and only declare the reg/irq values and the link to DMA. Herbert, ping? Could I have your Acked-by for taking these patches through the arm-soc git tree, or do you want that we split this series so that you can take the driver part of it? Best regards, Some trivial patches are preceding this move to Device Tree to clean things up beforehand. The series has already been sent but a little bit scattered. So I collect everything, this time. Nicolas Ferre (7): ARM: at91/dt/trivial: use macro for AES irq type ARM: at91/dt/trivial: before sama5d3, Atmel MPU were using at91 prefix ARM: at91/dt/sama5d3: add DMA information to SHA/AES/TDES nodes crypto: atmel-aes - add support for Device Tree crypto: atmel-tdes - add support for Device Tree crypto: atmel-sha - add support for Device Tree crypto: atmel-sha - add sha information to the log .../devicetree/bindings/crypto/atmel-crypto.txt| 68 ++ arch/arm/boot/dts/sama5d3.dtsi | 16 ++- drivers/crypto/atmel-aes.c | 143 ++--- drivers/crypto/atmel-sha.c | 103 +++ drivers/crypto/atmel-tdes.c| 143 ++--- 5 files changed, 346 insertions(+), 127 deletions(-) create mode 100644 Documentation/devicetree/bindings/crypto/atmel-crypto.txt -- Nicolas Ferre -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ipc,shm: Correct error return value in shmctl (SHM_UNLOCK)
Commit 2caacaa82a51b78fc0c800e206473874094287ed restructured
the ipc shm to shorten critical region, but introduced a path
where the return value could be -EPERM, even if the operation
actually was performed.
Before the commit, the err return value was reset by the return value
from security_shm_shmctl() after the if (!ns_capable(...)) statement.
Now, we still exit the if statement with err set to -EPERM,
and in the case of SHM_UNLOCK, it is not reset at all,
and used as the return value from shmctl.
To fix this, we only set err when errors occur, leaving the
fallthrough case alone.
Signed-off-by: Jesper Nilsson jesper.nils...@axis.com
Cc: Andrew Morton a...@linux-foundation.org
Cc: Davidlohr Bueso davidl...@hp.com
Cc: Rik van Riel r...@redhat.com
Cc: Michel Lespinasse wal...@google.com
Cc: Al Viro v...@zeniv.linux.org.uk
Cc: sta...@vger.kernel.org
---
ipc/shm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/ipc/shm.c b/ipc/shm.c
index d697396..4076f9e 100644
--- a/ipc/shm.c
+++ b/ipc/shm.c
@@ -974,12 +974,15 @@ SYSCALL_DEFINE3(shmctl, int, shmid, int, cmd, struct
shmid_ds __user *, buf)
ipc_lock_object(shp-shm_perm);
if (!ns_capable(ns-user_ns, CAP_IPC_LOCK)) {
kuid_t euid = current_euid();
- err = -EPERM;
if (!uid_eq(euid, shp-shm_perm.uid)
- !uid_eq(euid, shp-shm_perm.cuid))
+ !uid_eq(euid, shp-shm_perm.cuid)) {
+ err = -EPERM;
goto out_unlock0;
- if (cmd == SHM_LOCK !rlimit(RLIMIT_MEMLOCK))
+ }
+ if (cmd == SHM_LOCK !rlimit(RLIMIT_MEMLOCK)) {
+ err = -EPERM;
goto out_unlock0;
+ }
}
shm_file = shp-shm_file;
--
1.8.4
/^JN - Jesper Nilsson
--
Jesper Nilsson -- jesper.nils...@axis.com
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/4] ASoC: wm5110: Expose input high pass filter controls
On Wed, 20 Nov 2013, Mark Brown wrote: On Wed, Nov 20, 2013 at 09:16:36AM +, Lee Jones wrote: For the MFD parts: Acked-by: Lee Jones lee.jo...@linaro.org How do you want to play this ASoC? I expect this to collide with future changes from Wolfson so it'll need to go via ASoC. Okay, what if I make you a branch to pull from? Or visa-versa? -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Having troubles in updating MTD partitions
5824 is the usable size of the file system on mtdblock3, i.e. after subtracting
the overhead for file system bookkeeping.
By default mtd partitions were like
cat /proc/partitions
major minor #blocks name
31 0 8192 mtdblock0
31 1 256 mtdblock1
31 2 2048 mtdblock2
31 3 5824 mtdblock3
31 4 64 mtdblock4
mtdblock3 was having 5824 blocks and 5824 blocks were able to use,
I think you are missing my point, i have increase size of mtdblock3 but i am
unable use whole partion and idk why
kindly also inform me how i can change erasesize of a partition
On Wednesday, November 20, 2013 1:51 PM, Geert Uytterhoeven
ge...@linux-m68k.org wrote:
On Wed, Nov 20, 2013 at 8:59 AM, Suki Buryani sukibury...@yahoo.com wrote:
31 3 5884 mtdblock3
5884 is the raw size of mtdblock3.
but when i try to use memory relevant tools, it shows me something like
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 5824 5824 0 100% /
5824 is the usable size of the file system on mtdblock3, i.e. after subtracting
the overhead for file system bookkeeping.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 00/05] gpio: R-Car and EM GPIO update V2
Hi Magnus, Thank you for the patch. On Wednesday 20 November 2013 09:22:59 Magnus Damm wrote: gpio: R-Car and EM GPIO update V2 [PATCH 01/05 v2] gpio: rcar: Use lazy disable [PATCH 02/05 v2] gpio: rcar: Enable mask on suspend [PATCH 03/05] gpio: em: Setup gpiochip-dev [PATCH 04/05 v2] gpio: em: Use lazy disable [PATCH 05/05 v2] gpio: em: Enable mask on suspend Update the R-Car GPIO driver and the GPIO driver used on EMEV2 to use lazy disable and mask on suspend. This fixes the Suspend-to-RAM behavior to make sure wakeup sources are left enabled while suspending. Also include a small fix for gpio-em that fixes the DT use case. Thanks to Laurent and Linus for feedback. Signed-off-by: Magnus Damm d...@opensource.se For the whole series, Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- Written against renesas.git tag renesas-devel-v3.12-20131119 Changes since V1: - Split lazy disable and mask on suspend patches - Improved commit messages drivers/gpio/gpio-em.c |5 ++--- drivers/gpio/gpio-rcar.c |5 ++--- 2 files changed, 4 insertions(+), 6 deletions(-) -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] irq-gic: add capability to set bypass flag in GIC
[dropping patc...@apm.com from the CC list, as someone seems to have
tripped on the config file, and I'm tired of getting bounces]
Feng,
On 19/11/13 21:42, Feng Kan wrote:
The GIC-400 implementation allows for FIQ and IRQ bypass. In the
X-Gene implementation, the FIQ bypass must be enabled at all time.
Otherwise, some PPI will appear as FIQ and cause kernel problem.
How comes? Are only PPIs affected? When you say some PPIs, can you be
more specific?
Signed-off-by: Feng Kan f...@apm.com
---
drivers/irqchip/irq-gic.c | 15 +++
include/linux/irqchip/arm-gic.h |4 ++--
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index d0e9480..aa7342e 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -65,6 +65,7 @@ struct gic_chip_data {
#endif
struct irq_domain *domain;
unsigned int gic_irqs;
+ unsigned int bypass_flag;
#ifdef CONFIG_GIC_NON_BANKED
void __iomem *(*get_base)(union gic_base *);
#endif
@@ -450,7 +451,7 @@ static void gic_cpu_init(struct gic_chip_data *gic)
writel_relaxed(0xa0a0a0a0, dist_base + GIC_DIST_PRI + i * 4 /
4);
writel_relaxed(0xf0, base + GIC_CPU_PRIMASK);
- writel_relaxed(1, base + GIC_CPU_CTRL);
+ writel_relaxed(gic-bypass_flag | 1, base + GIC_CPU_CTRL);
}
void gic_cpu_if_down(void)
@@ -591,7 +592,7 @@ static void gic_cpu_restore(unsigned int gic_nr)
writel_relaxed(0xa0a0a0a0, dist_base + GIC_DIST_PRI + i * 4);
writel_relaxed(0xf0, cpu_base + GIC_CPU_PRIMASK);
- writel_relaxed(1, cpu_base + GIC_CPU_CTRL);
+ writel_relaxed(gic_data[gic_nr].bypass_flag | 1, cpu_base +
GIC_CPU_CTRL);
}
static int gic_notifier(struct notifier_block *self, unsigned long cmd,
void *v)
@@ -733,7 +734,8 @@ const struct irq_domain_ops gic_irq_domain_ops = {
void __init gic_init_bases(unsigned int gic_nr, int irq_start,
void __iomem *dist_base, void __iomem *cpu_base,
-u32 percpu_offset, struct device_node *node)
+u32 percpu_offset, u32 bypass_val,
+struct device_node *node)
{
irq_hw_number_t hwirq_base;
struct gic_chip_data *gic;
@@ -821,6 +823,7 @@ void __init gic_init_bases(unsigned int gic_nr, int
irq_start,
set_handle_irq(gic_handle_irq);
+ gic-bypass_flag = (bypass_val 0xf) 4;
Beware, the top 2 bits are reserved on GICv1, and shouldn't be messed with.
gic_chip.flags |= gic_arch_extn.flags;
gic_dist_init(gic);
gic_cpu_init(gic);
@@ -835,6 +838,7 @@ int __init gic_of_init(struct device_node *node, struct
device_node *parent)
void __iomem *cpu_base;
void __iomem *dist_base;
u32 percpu_offset;
+ u32 bypass_val;
int irq;
if (WARN_ON(!node))
@@ -849,7 +853,10 @@ int __init gic_of_init(struct device_node *node, struct
device_node *parent)
if (of_property_read_u32(node, cpu-offset, percpu_offset))
percpu_offset = 0;
- gic_init_bases(gic_cnt, -1, dist_base, cpu_base, percpu_offset, node);
+ if (of_property_read_u32(node, bypass-flags, bypass_val))
+ bypass_val = 0;
[adding Mark on Cc, so he can comment on the DT parts]
Where's the DT documentation update? Also, as this is an
implementation-specific quirk, you should consider using a separate
compatible string and move the handling of this issue into some X-Gene
specific code.
+ gic_init_bases(gic_cnt, -1, dist_base, cpu_base, percpu_offset,
bypass_val, node);
if (parent) {
irq = irq_of_parse_and_map(node, 0);
diff --git a/include/linux/irqchip/arm-gic.h b/include/linux/irqchip/arm-gic.h
index 0e5d9ec..999515b 100644
--- a/include/linux/irqchip/arm-gic.h
+++ b/include/linux/irqchip/arm-gic.h
@@ -64,14 +64,14 @@ struct device_node;
extern struct irq_chip gic_arch_extn;
void gic_init_bases(unsigned int, int, void __iomem *, void __iomem *,
- u32 offset, struct device_node *);
+ u32 offset, u32 bypass_val, struct device_node *);
void gic_cascade_irq(unsigned int gic_nr, unsigned int irq);
void gic_cpu_if_down(void);
static inline void gic_init(unsigned int nr, int start,
void __iomem *dist , void __iomem *cpu)
{
- gic_init_bases(nr, start, dist, cpu, 0, NULL);
+ gic_init_bases(nr, start, dist, cpu, 0, 0, NULL);
}
#endif /* __ASSEMBLY */
Cheers,
M.
--
Jazz is not dead. It just smells funny...
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, acpi, idle: Restructure the mwait idle routines
On Wed, Nov 20, 2013 at 11:28:03AM +0100, Peter Zijlstra wrote:
On Tue, Nov 19, 2013 at 01:06:30PM -0800, Jacob Pan wrote:
I applied this patch on top of upstream kernel (801a760) and found out
my machine completely failed to enter idle when nothing is running.
turbostate shows 100% C0. ftrace shows kernel coming in and out of idle
frequently.
Both ACPI idle and intel_idle behaves the same way. I have to do the
following change to allow entering C-states again.
That doesn't make any sense; current_set_polling_and_test() returns the
same thing need_resched() does.
But you're right, intel_idle resides 100% in C0 and acpi_idle has 100%
C1 residency... most weird.
So pretty silly actually; you cannot do a store (any store) in between
monitor and mwait.
The below version seems to work properly again with both acpi_idle and
intel_idle.
Now to go make that preempt_disable_no_resched cleanup compile.. :-)
---
Subject: x86, acpi, idle: Restructure the mwait idle routines
From: Peter Zijlstra pet...@infradead.org
Date: Tue, 19 Nov 2013 12:31:53 +0100
People seem to delight in writing wrong and broken mwait idle routines;
collapse the lot.
This leaves mwait_play_dead() the sole remaining user of __mwait() and
new __mwait() users are probably doing it wrong.
Also remove __sti_mwait() as its unused.
Cc: ar...@linux.intel.com
Cc: jacob.jun@linux.intel.com
Cc: Mike Galbraith bitbuc...@online.de
Cc: Ingo Molnar mi...@kernel.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: h...@zytor.com
Cc: l...@kernel.org
Cc: shaohua...@intel.com
Cc: rui.zh...@intel.com
Acked-by: Rafael J. Wysocki rafael.j.wyso...@intel.com
Signed-off-by: Peter Zijlstra pet...@infradead.org
---
arch/x86/include/asm/mwait.h | 40 +
arch/x86/include/asm/processor.h | 23 -
arch/x86/kernel/acpi/cstate.c | 23 -
drivers/acpi/acpi_pad.c|5
drivers/acpi/processor_idle.c | 15 -
drivers/idle/intel_idle.c |8 ---
drivers/thermal/intel_powerclamp.c |4 ---
7 files changed, 43 insertions(+), 75 deletions(-)
--- a/arch/x86/include/asm/mwait.h
+++ b/arch/x86/include/asm/mwait.h
@@ -1,6 +1,8 @@
#ifndef _ASM_X86_MWAIT_H
#define _ASM_X86_MWAIT_H
+#include linux/sched.h
+
#define MWAIT_SUBSTATE_MASK0xf
#define MWAIT_CSTATE_MASK 0xf
#define MWAIT_SUBSTATE_SIZE4
@@ -13,4 +15,42 @@
#define MWAIT_ECX_INTERRUPT_BREAK 0x1
+static inline void __monitor(const void *eax, unsigned long ecx,
+unsigned long edx)
+{
+ /* monitor %eax, %ecx, %edx; */
+ asm volatile(.byte 0x0f, 0x01, 0xc8;
+:: a (eax), c (ecx), d(edx));
+}
+
+static inline void __mwait(unsigned long eax, unsigned long ecx)
+{
+ /* mwait %eax, %ecx; */
+ asm volatile(.byte 0x0f, 0x01, 0xc9;
+:: a (eax), c (ecx));
+}
+
+/*
+ * This uses new MONITOR/MWAIT instructions on P4 processors with PNI,
+ * which can obviate IPI to trigger checking of need_resched.
+ * We execute MONITOR against need_resched and enter optimized wait state
+ * through MWAIT. Whenever someone changes need_resched, we would be woken
+ * up from MWAIT (without an IPI).
+ *
+ * New with Core Duo processors, MWAIT can take some hints based on CPU
+ * capability.
+ */
+static inline void mwait_idle_with_hints(unsigned long eax, unsigned long ecx)
+{
+ if (!current_set_polling_and_test()) {
+ if (this_cpu_has(X86_FEATURE_CLFLUSH_MONITOR))
+ clflush((void *)current_thread_info()-flags);
+
+ __monitor((void *)current_thread_info()-flags, 0, 0);
+ if (!need_resched())
+ __mwait(eax, ecx);
+ }
+ __current_clr_polling();
+}
+
#endif /* _ASM_X86_MWAIT_H */
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -700,29 +700,6 @@ static inline void sync_core(void)
#endif
}
-static inline void __monitor(const void *eax, unsigned long ecx,
-unsigned long edx)
-{
- /* monitor %eax, %ecx, %edx; */
- asm volatile(.byte 0x0f, 0x01, 0xc8;
-:: a (eax), c (ecx), d(edx));
-}
-
-static inline void __mwait(unsigned long eax, unsigned long ecx)
-{
- /* mwait %eax, %ecx; */
- asm volatile(.byte 0x0f, 0x01, 0xc9;
-:: a (eax), c (ecx));
-}
-
-static inline void __sti_mwait(unsigned long eax, unsigned long ecx)
-{
- trace_hardirqs_on();
- /* mwait %eax, %ecx; */
- asm volatile(sti; .byte 0x0f, 0x01, 0xc9;
-:: a (eax), c (ecx));
-}
-
extern void select_idle_routine(const struct cpuinfo_x86 *c);
extern void init_amd_e400_c1e_mask(void);
--- a/arch/x86/kernel/acpi/cstate.c
+++ b/arch/x86/kernel/acpi/cstate.c
@@ -150,29 +150,6 @@ int acpi_processor_ffh_cstate_probe(unsi
}
Re: Having troubles in updating MTD partitions
On Wed, Nov 20, 2013 at 11:49 AM, Suki Buryani sukibury...@yahoo.com wrote:
5824 is the usable size of the file system on mtdblock3, i.e. after
subtracting
the overhead for file system bookkeeping.
By default mtd partitions were like
cat /proc/partitions
major minor #blocks name
31 0 8192 mtdblock0
31 1256 mtdblock1
31 2 2048 mtdblock2
31 3 5824 mtdblock3
31 4 64 mtdblock4
mtdblock3 was having 5824 blocks and 5824 blocks were able to use,
I think you are missing my point, i have increase size of mtdblock3 but i am
unable use whole partion and idk why
Sorry, I indeed misunderstood you.
Could it be that jffs2 requires a minimum granularity for file system sizes?
Probably the size needs to be a multiple of the eraseblock size?
$ factor 5824
5824: 2 2 2 2 2 2 7 13
$ factor 5884
5884: 2 2 1471
I.e. the former is a multiple of 64 (KiB), the latter is a multiple of 4 (KiB).
there is one more thing, Can any one tell me how i can change eraseblock for
a partition, i believe i also having wrong eraseblock for mtdblock3
Sorry, I don't know.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] uprobes: Document xol_area and arch_uprobe-insn/ixol
OK. Let me try to make a first step to improve this a little bit...
How about the patch below? Srikar?
Subject: [PATCH] uprobes: Document xol_area and arch_uprobe-insn/ixol
Document xol_area and arch_uprobe.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
Acked-by: Srikar Dronamraju sri...@linux.vnet.ibm.com
kernel/events/uprobes.c | 15 +++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 51a7f53..b886a5e 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -73,6 +73,17 @@ struct uprobe {
struct inode*inode; /* Also hold a ref to inode */
loff_t offset;
unsigned long flags;
+
+ /*
+ * The generic code assumes that it has two members of unknown type
+ * owned by the arch-specific code:
+ *
+ * insn - copy_insn() saves the original instruction here for
+ * arch_uprobe_analyze_insn().
+ *
+ * ixol - potentially modified instruction to execute out of
+ * line, copied to xol_area by xol_get_insn_slot().
+ */
struct arch_uprobe arch;
};
@@ -86,6 +97,10 @@ struct return_instance {
};
/*
+ * Execute out of line area: anonymous executable mapping installed
+ * by the probed task to execute the copy of the original instruction
+ * mangled by set_swbp().
+ *
* On a breakpoint hit, thread contests for a slot. It frees the
* slot after singlestep. Currently a fixed number of slots are
* allocated.
--
1.5.5.1
--
Thanks and Regards
Srikar Dronamraju
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.4 00/12] 3.4.70-stable review
At Mon, 18 Nov 2013 10:41:33 -0800, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.4.70 release. There are 12 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Nov 20 18:41:11 UTC 2013. Anything received after that time might be too late. This kernel can be built and boot without any problem. Building a kernel with this kernel also works fine. - Build Machine: debian jessy x86_64 CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 memory: 8GB - Test machine: debian jessy x86_64(KVM guest on the Build Machine) vCPU: x2 memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.10 00/24] 3.10.20-stable review
At Mon, 18 Nov 2013 10:42:10 -0800, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.10.20 release. There are 24 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Nov 20 18:42:04 UTC 2013. Anything received after that time might be too late. This kernel can be built and boot without any problem. Building a kernel with this kernel also works fine. - Build Machine: debian jessy x86_64 CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 memory: 8GB - Test machine: debian jessy x86_64(KVM guest on the Build Machine) vCPU: x2 memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.11 00/25] 3.11.9-stable review
At Mon, 18 Nov 2013 10:40:29 -0800, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.11.9 release. There are 25 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Nov 20 18:40:06 UTC 2013. Anything received after that time might be too late. This kernel can be built and boot without any problem. Building a kernel with this kernel also works fine. - Build Machine: debian jessy x86_64 CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 memory: 8GB - Test machine: debian jessy x86_64(KVM guest on the Build Machine) vCPU: x2 memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.12 00/19] 3.12.1-stable review
At Mon, 18 Nov 2013 10:37:13 -0800, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.12.1 release. There are 19 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Wed Nov 20 18:36:14 UTC 2013. Anything received after that time might be too late. This kernel can be built and boot without any problem. Building a kernel with this kernel also works fine. - Build Machine: debian jessy x86_64 CPU: Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz x 4 memory: 8GB - Test machine: debian jessy x86_64(KVM guest on the Build Machine) vCPU: x2 memory: 2GB Thanks, Satoru -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4] Add Documentation/module-signing.txt file
Rusty Russell ru...@rustcorp.com.au wrote: ? I changed this to an Acked-by... I made a heap of restructuring and changes that James incorporated into his v4. David -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] possible divide by 0 in kernel/sched/cputime.c scale_stime()
On Mon, Nov 18, 2013 at 06:27:06PM +0100, Peter Zijlstra wrote: The below is a compile tested only attempt to deal with both these problems. Comments? Just two nits as I don't understand vast of the patch. + delta_exec = now - curr-exec_start; + if ((s64)delta_exec 0) return; Check here should probably use = and also unlikely() would be reasonable. + schedstat_set(curr-statistics.exec_max, + max((u64)delta_exec, curr-statistics.exec_max)); (u64) cast not needed. Stanislaw -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 1/2] genirq: Add an accessor for IRQ_PER_CPU flag
This patch adds an accessor function for IRQ_PER_CPU flag.
The accessor function is useful to dertermine whether an IRQ is percpu or not.
Signed-off-by: Vinayak Kale vk...@apm.com
---
include/linux/irqdesc.h |8
1 file changed, 8 insertions(+)
diff --git a/include/linux/irqdesc.h b/include/linux/irqdesc.h
index 56fb646..26e2661 100644
--- a/include/linux/irqdesc.h
+++ b/include/linux/irqdesc.h
@@ -152,6 +152,14 @@ static inline int irq_balancing_disabled(unsigned int irq)
return desc-status_use_accessors IRQ_NO_BALANCING_MASK;
}
+static inline int irq_is_percpu(unsigned int irq)
+{
+ struct irq_desc *desc;
+
+ desc = irq_to_desc(irq);
+ return desc-status_use_accessors IRQ_PER_CPU;
+}
+
static inline void
irq_set_lockdep_class(unsigned int irq, struct lock_class_key *class)
{
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RESEND 0/7] crypto: at91/atmel: add Device Tree support
On Wed, Nov 20, 2013 at 11:43:26AM +0100, Nicolas Ferre wrote: On 08/11/2013 16:08, Nicolas Ferre : This series adds Device Tree support to the Atmel crypto drivers (AES/[T]DES/SHA). The Device Tree entries are very simple and only declare the reg/irq values and the link to DMA. Herbert, ping? Could I have your Acked-by for taking these patches through the arm-soc git tree, or do you want that we split this series so that you can take the driver part of it? Sure please push them through the arm-soc tree. You can add my ack: Acked-by: Herbert Xu herb...@gondor.apana.org.au Thanks, -- Email: Herbert Xu herb...@gondor.apana.org.au Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 0/2] genirq: arm64: perf: support for percpu pmu interrupt
This patch series adds support to handle interrupt registration/deregistration in arm64 pmu driver when pmu interrupt type is percpu. Changelog: V4: * In arm64 pmu driver: Avoid using irq_to_desc() to check validity of irq. V3: * Remove validity check for 'desc' from accessor function in irqdesc.h . Instead, check the irq 'desc' validity in arm64 pmu driver. V2: * To determine whether an IRQ is percpu or not, added an accessor function in irqdesc.h . This approach was used by Chris Smith here[1] for similar changes in arm pmu driver. * In arm64 pmu driver: Got rid of unnecessary pointer typecastings. [1] http://lkml.indiana.edu/hypermail/linux/kernel/1207.3/02955.html Vinayak Kale (2): genirq: Add an accessor for IRQ_PER_CPU flag arm64: perf: add support for percpu pmu interrupt arch/arm64/kernel/perf_event.c | 108 ++-- include/linux/irqdesc.h|8 +++ 2 files changed, 89 insertions(+), 27 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.12: kernel panic when resuming from suspend to RAM (x86_64)
On Wed, Nov 20, 2013 at 10:45:05AM +0100, Francis Moreau wrote: Unfortunately the bisect session didn't give any positive results: I couldn't be sure if a specific revision was good or bad because the bug wasn't reproductible every time. But I got a different kernel oops on my stripped system that may give us a clue: http://imgur.com/zdCknbY Does this help ? Unfortunately, this is the second oops: Oops: [#2] ... The first has scrolled off but I can see the RIP: ioread32+0x40 and the code must be: 812a1e40 ioread32: 812a1e40: 48 81 ff ff ff 03 00cmp$0x3,%rdi 812a1e47: 77 37 ja 812a1e80 ioread32+0x40 ... 812a1e77: 66 0f 1f 84 00 00 00nopw 0x0(%rax,%rax,1) 812a1e7e: 00 00 812a1e80: 8b 07 mov(%rdi),%eax --- faulting insn 812a1e82: c3 retq 812a1e83: 66 66 66 66 2e 0f 1fdata32 data32 data32 nopw %cs:0x0(%rax,%rax,1) 812a1e8a: 84 00 00 00 00 00 and judging by the instruction, that's addr in %rdi which we try to read and I'd guess %rdi contains garbage after resume. IOW, this looks like another corruption that happens when you suspend to ram. I asked you already but you didn't say: Also, you can check for BIOS updates for your machine and if there are, check their changelogs whether they fix something suspend-related. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V4 2/2] arm64: perf: add support for percpu pmu interrupt
Add support for irq registration when pmu interrupt is percpu.
Signed-off-by: Vinayak Kale vk...@apm.com
Signed-off-by: Tuan Phan tp...@apm.com
---
arch/arm64/kernel/perf_event.c | 108 ++--
1 file changed, 81 insertions(+), 27 deletions(-)
diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c
index cea1594..de12ba8 100644
--- a/arch/arm64/kernel/perf_event.c
+++ b/arch/arm64/kernel/perf_event.c
@@ -22,6 +22,7 @@
#include linux/bitmap.h
#include linux/interrupt.h
+#include linux/irq.h
#include linux/kernel.h
#include linux/export.h
#include linux/perf_event.h
@@ -363,22 +364,55 @@ validate_group(struct perf_event *event)
}
static void
+armpmu_disable_percpu_irq(void *data)
+{
+ struct arm_pmu *armpmu = data;
+ struct platform_device *pmu_device = armpmu-plat_device;
+ int irq = platform_get_irq(pmu_device, 0);
+
+ cpumask_test_and_clear_cpu(smp_processor_id(), armpmu-active_irqs);
+ disable_percpu_irq(irq);
+}
+
+static void
armpmu_release_hardware(struct arm_pmu *armpmu)
{
int i, irq, irqs;
struct platform_device *pmu_device = armpmu-plat_device;
irqs = min(pmu_device-num_resources, num_possible_cpus());
+ if (irqs 1)
+ return;
- for (i = 0; i irqs; ++i) {
- if (!cpumask_test_and_clear_cpu(i, armpmu-active_irqs))
- continue;
- irq = platform_get_irq(pmu_device, i);
- if (irq = 0)
- free_irq(irq, armpmu);
+ irq = platform_get_irq(pmu_device, 0);
+ if (irq 0)
+ return;
+
+ if (irq_is_percpu(irq)) {
+ on_each_cpu(armpmu_disable_percpu_irq, armpmu, 1);
+ free_percpu_irq(irq, cpu_hw_events);
+ } else {
+ for (i = 0; i irqs; ++i) {
+ if (!cpumask_test_and_clear_cpu(i,
armpmu-active_irqs))
+ continue;
+ irq = platform_get_irq(pmu_device, i);
+ if (irq = 0)
+ free_irq(irq, armpmu);
+ }
}
}
+static void
+armpmu_enable_percpu_irq(void *data)
+{
+ struct arm_pmu *armpmu = data;
+ struct platform_device *pmu_device = armpmu-plat_device;
+ int irq = platform_get_irq(pmu_device, 0);
+
+ enable_percpu_irq(irq, 0);
+ cpumask_set_cpu(smp_processor_id(), armpmu-active_irqs);
+}
+
static int
armpmu_reserve_hardware(struct arm_pmu *armpmu)
{
@@ -396,34 +430,54 @@ armpmu_reserve_hardware(struct arm_pmu *armpmu)
return -ENODEV;
}
- for (i = 0; i irqs; ++i) {
- err = 0;
- irq = platform_get_irq(pmu_device, i);
- if (irq 0)
- continue;
+ irq = platform_get_irq(pmu_device, 0);
+ if (irq 0) {
+ pr_err(failed to get an irq for PMU device\n);
+ return -ENODEV;
+ }
- /*
-* If we have a single PMU interrupt that we can't shift,
-* assume that we're running on a uniprocessor machine and
-* continue. Otherwise, continue without this interrupt.
-*/
- if (irq_set_affinity(irq, cpumask_of(i)) irqs 1) {
- pr_warning(unable to set irq affinity (irq=%d,
cpu=%u)\n,
- irq, i);
- continue;
- }
+ if (irq_is_percpu(irq)) {
+ err = request_percpu_irq(irq, armpmu-handle_irq,
+ arm-pmu, cpu_hw_events);
- err = request_irq(irq, armpmu-handle_irq,
- IRQF_NOBALANCING,
- arm-pmu, armpmu);
if (err) {
- pr_err(unable to request IRQ%d for ARM PMU counters\n,
- irq);
+ pr_err(unable to request percpu IRQ%d for ARM PMU
counters\n,
+ irq);
armpmu_release_hardware(armpmu);
return err;
}
- cpumask_set_cpu(i, armpmu-active_irqs);
+ on_each_cpu(armpmu_enable_percpu_irq, armpmu, 1);
+ } else {
+ for (i = 0; i irqs; ++i) {
+ err = 0;
+ irq = platform_get_irq(pmu_device, i);
+ if (irq 0)
+ continue;
+
+ /*
+* If we have a single PMU interrupt that we can't
shift,
+* assume that we're running on a uniprocessor machine
and
+* continue. Otherwise, continue without this interrupt.
+*/
+ if (irq_set_affinity(irq, cpumask_of(i)) irqs 1)
