Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
On 10/17/2013 03:37 PM, Timur Tabi wrote: Lars-Peter Clausen wrote: Maybe I've been out of the loop for too long, but why is that a particular problem with this driver? It is usually something you'd want to check in general to make sure that you don't have multiple device that access the same iomem region at the same time. I understand that, but I'm trying to figure out why of_iomap() is okay for hundreds of other drivers, but not this one. I've used it dozens of times myself, without ever worrying about overlapping regions. The driver would work fine with just of_iomap(). But the resource range check comes basically for free and it does help to catch errors, so I'd recommend on using it rather than not using it. - Lars -- 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/2] vmsplice: unmap gifted pages for recipient
* Vlastimil Babka (vba...@suse.cz) wrote:
On 10/07/2013 10:21 PM, Robert C Jennings wrote:
Introduce use of the unused SPLICE_F_MOVE flag for vmsplice to zap
pages.
When vmsplice is called with flags (SPLICE_F_GIFT | SPLICE_F_MOVE) the
writer's gift'ed pages would be zapped. This patch supports further work
to move vmsplice'd pages rather than copying them. That patch has the
restriction that the page must not be mapped by the source for the move,
otherwise it will fall back to copying the page.
Signed-off-by: Matt Helsley matt.hels...@gmail.com
Signed-off-by: Robert C Jennings r...@linux.vnet.ibm.com
---
Since the RFC went out I have coalesced the zap_page_range() call to
operate on VMAs rather than calling this for each page. For a 256MB
vmsplice this reduced the write side 50% from the RFC.
---
fs/splice.c| 51
+-
include/linux/splice.h | 1 +
2 files changed, 51 insertions(+), 1 deletion(-)
diff --git a/fs/splice.c b/fs/splice.c
index 3b7ee65..a62d61e 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -188,12 +188,17 @@ ssize_t splice_to_pipe(struct pipe_inode_info *pipe,
{
unsigned int spd_pages = spd-nr_pages;
int ret, do_wakeup, page_nr;
+ struct vm_area_struct *vma;
+ unsigned long user_start, user_end;
ret = 0;
do_wakeup = 0;
page_nr = 0;
+ vma = NULL;
+ user_start = user_end = 0;
pipe_lock(pipe);
+ down_read(current-mm-mmap_sem);
Seems like you could take the mmap_sem only when GIFT and MOVE is set.
Maybe it won't help that much for performance but at least serve as
documenting the reason it's needed?
Vlastimil
I had been doing that previously but moving this outside the loop and
acquiring it once did improve performance. I'll add a comment on
down_read() as to the reason for taking this though.
-Rob
for (;;) {
if (!pipe-readers) {
@@ -212,8 +217,44 @@ ssize_t splice_to_pipe(struct pipe_inode_info *pipe,
buf-len = spd-partial[page_nr].len;
buf-private = spd-partial[page_nr].private;
buf-ops = spd-ops;
- if (spd-flags SPLICE_F_GIFT)
+ if (spd-flags SPLICE_F_GIFT) {
+ unsigned long useraddr =
+ spd-partial[page_nr].useraddr;
+
+ if ((spd-flags SPLICE_F_MOVE)
+ !buf-offset
+ (buf-len == PAGE_SIZE)) {
+ /* Can move page aligned buf, gather
+* requests to make a single
+* zap_page_range() call per VMA
+*/
+ if (vma (useraddr == user_end)
+ ((useraddr + PAGE_SIZE) =
+ vma-vm_end)) {
+ /* same vma, no holes */
+ user_end += PAGE_SIZE;
+ } else {
+ if (vma)
+ zap_page_range(vma,
+ user_start,
+ (user_end -
+user_start),
+ NULL);
+ vma = find_vma_intersection(
+ current-mm,
+ useraddr,
+ (useraddr +
+PAGE_SIZE));
+ if (!IS_ERR_OR_NULL(vma)) {
+ user_start = useraddr;
+ user_end = (useraddr +
+ PAGE_SIZE);
+ } else
+ vma = NULL;
+ }
+ }
buf-flags |= PIPE_BUF_FLAG_GIFT;
+ }
pipe-nrbufs++;
page_nr++;
@@ -255,6 +296,10 @@ ssize_t splice_to_pipe(struct pipe_inode_info *pipe,
pipe-waiting_writers--;
}
+ if (vma)
+ zap_page_range(vma, user_start, (user_end - user_start), NULL);
+
+
Re: [PATCH] netfilter: fix ordering of jumpstack allocation and table update
On Thu, 2013-10-17 at 14:24 +0100, Will Deacon wrote: During kernel stability testing on an SMP ARMv7 system, Yalin Wang reported the following panic from the netfilter code: On weakly ordered memory architectures, the writes to table-private and newinfo-jumpstack from CPU1 can be observed out of order by CPU0. Furthermore, on architectures which don't respect ordering of address dependencies (i.e. Alpha), the reads from CPU0 can also be re-ordered. This patch adds an smp_wmb() before the assignment to table-private (which is essentially publishing newinfo) to ensure that all writes to newinfo will be observed before plugging it into the table structure. A dependent-read barrier is also added on the consumer side, to ensure the same ordering requirement are also respected there. Cc: Pablo Neira Ayuso pa...@netfilter.org Cc: Paul E. McKenney paul...@linux.vnet.ibm.com Reported-by: Wang, Yalin yalin.w...@sonymobile.com Tested-by: Wang, Yalin yalin.w...@sonymobile.com Signed-off-by: Will Deacon will.dea...@arm.com --- Nice catch ! Acked-by: Eric Dumazet eduma...@google.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 v2 0/4] Exynos 5410 Dual cluster support
On 17.10.2013 17:04, Aliaksei Katovich wrote: hi Kevin; Vyacheslav Tyrtov v.tyr...@samsung.com writes: The series of patches represent support of Exynos 5410 SoC The Exynos 5410 is the first Samsung SoC based on bigLITTLE architecture. Patches allow all 8 CPU cores (4 x A7 and 4 x A15) to run at the same time Patches add new platform description, support of clock controller, dual cluster support and device tree for Exynos 5410 Has been build on v3.12-rc5. Has been tested on Exynos 5410 reference board (exynos_defconfig). Has anyone tried this on the exynos5410 based odroid-xu yet? I tried booting this on my recently arrived odroid-xu, but am not getting it to boot. I am able to boot my odroid-xu+e to busybox with these patches applied against 3.12-rc5: exynos_defconfig and exynos5410-smdk5410.dtb were used. However there seem to be some issues with virq allocations, like this: snippet Starting kernel ... [0.00] [c0014d48] (unwind_backtrace+0x0/0xf8) from [c00117d0] (show_stack+0x10/0x14) [0.00] [c00117d0] (show_stack+0x10/0x14) from [c0363488] (dump_stack+0x6c/0xac) [0.00] [c0363488] (dump_stack+0x6c/0xac) from [c001e330] (warn_slowpath_common+0x64/0x88) [0.00] [c001e330] (warn_slowpath_common+0x64/0x88) from [c001e3e8] (warn_slowpath_fmt+0x30/0x40) [0.00] [c001e3e8] (warn_slowpath_fmt+0x30/0x40) from [c005a1b4] (irq_domain_associate+0x128/0x1a8) [0.00] [c005a1b4] (irq_domain_associate+0x128/0x1a8) from [c005a508] (irq_domain_associate_many+0x30/0x3c ) [0.00] [c005a508] (irq_domain_associate_many+0x30/0x3c) from [c005a768] (irq_domain_add_simple+0x78/0x90) [0.00] [c005a768] (irq_domain_add_simple+0x78/0x90) from [c04b044c] (combiner_of_init+0xb4/0x198) [0.00] [c04b044c] (combiner_of_init+0xb4/0x198) from [c04b6938] (of_irq_init+0x278/0x2a0) [0.00] [c04b6938] (of_irq_init+0x278/0x2a0) from [c049b8fc] (start_kernel+0x18c/0x384) [0.00] [c049b8fc] (start_kernel+0x18c/0x384) from [40008074] (0x40008074) [0.00] ---[ end trace 1b75b31a2719edcd ]--- [0.00] [ cut here ] [0.00] WARNING: CPU: 0 PID: 0 at kernel/irq/irqdomain.c:278 irq_domain_associate+0x128/0x1a8() [0.00] error: virq337 is not allocated [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW 3.12.0-rc5-4-g1cb405f #1 [0.00] [c0014d48] (unwind_backtrace+0x0/0xf8) from [c00117d0] (show_stack+0x10/0x14) [0.00] [c00117d0] (show_stack+0x10/0x14) from [c0363488] (dump_stack+0x6c/0xac) [0.00] [c0363488] (dump_stack+0x6c/0xac) from [c001e330] (warn_slowpath_common+0x64/0x88) [0.00] [c001e330] (warn_slowpath_common+0x64/0x88) from [c001e3e8] (warn_slowpath_fmt+0x30/0x40) [0.00] [c001e3e8] (warn_slowpath_fmt+0x30/0x40) from [c005a1b4] (irq_domain_associate+0x128/0x1a8) [0.00] [c005a1b4] (irq_domain_associate+0x128/0x1a8) from [c005a508] (irq_domain_associate_many+0x30/0x3c ) [0.00] [c005a508] (irq_domain_associate_many+0x30/0x3c) from [c005a768] (irq_domain_add_simple+0x78/0x90) [0.00] [c005a768] (irq_domain_add_simple+0x78/0x90) from [c04b044c] (combiner_of_init+0xb4/0x198) [0.00] [c04b044c] (combiner_of_init+0xb4/0x198) from [c04b6938] (of_irq_init+0x278/0x2a0) [0.00] [c04b6938] (of_irq_init+0x278/0x2a0) from [c049b8fc] (start_kernel+0x18c/0x384) [0.00] [c049b8fc] (start_kernel+0x18c/0x384) from [40008074] (0x40008074) [0.00] ---[ end trace 1b75b31a2719edce ]--- [0.00] [ cut here ] /snippet You can check full boot log here http://sprunge.us/NKcU -- Aliaksei I'm not yet terribly familiar with this SoC, what are the settings needed for DEBUG_LL on this board? Thanks, Kevin ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel This will be fixed in 3.13. Now you can just change irq_base = 160 to irq_base = 256 in static int __init combiner_of_init(struct device_node *np, struct device_node *parent) function in drivers/irqchip/exynos-combiner.c Best regards, Tarek Dakhran -- 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/2] vmsplice: unmap gifted pages for recipient
* Dave Hansen (d...@sr71.net) wrote:
On 10/07/2013 01:21 PM, Robert C Jennings wrote:
spd.partial[page_nr].offset = loff;
spd.partial[page_nr].len = this_len;
+ spd.partial[page_nr].useraddr = index PAGE_CACHE_SHIFT;
len -= this_len;
loff = 0;
spd.nr_pages++;
@@ -656,6 +702,7 @@ ssize_t default_file_splice_read(struct file *in,
loff_t *ppos,
this_len = min_t(size_t, vec[i].iov_len, res);
spd.partial[i].offset = 0;
spd.partial[i].len = this_len;
+ spd.partial[i].useraddr = (unsigned long)vec[i].iov_base;
if (!this_len) {
__free_page(spd.pages[i]);
spd.pages[i] = NULL;
@@ -1475,6 +1522,8 @@ static int get_iovec_page_array(const struct iovec
__user *iov,
partial[buffers].offset = off;
partial[buffers].len = plen;
+ partial[buffers].useraddr = (unsigned long)base;
+ base = (void*)((unsigned long)base + PAGE_SIZE);
off = 0;
len -= plen;
diff --git a/include/linux/splice.h b/include/linux/splice.h
index 74575cb..56661e3 100644
--- a/include/linux/splice.h
+++ b/include/linux/splice.h
@@ -44,6 +44,7 @@ struct partial_page {
unsigned int offset;
unsigned int len;
unsigned long private;
+ unsigned long useraddr;
};
useraddr confuses me. You make it an 'unsigned long', yet two of the
three assignments are from void __user *. The other assignment:
spd.partial[page_nr].useraddr = index PAGE_CACHE_SHIFT;
'index' looks to be the offset inside the file, not a user address, so
I'm confused what that is doing.
Could you elaborate a little more on why 'useraddr' is suddenly needed
in these patches? How is index PAGE_CACHE_SHIFT a virtual address?
Also, are we losing any of the advantages of sparse checking since
'useraddr' is without the __user annotation?
I'm working on cleaning this up. Trying to remove useraddr altogher
through the use of the existing 'private' field just for the
splice_to_user/pipe_to_user flow without upsetting other uses of the
private field.
--
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] kmod: Run usermodehelpers only on cpus allowed for kthreadd
On Wed, Oct 16, 2013 at 02:44:28PM +, Christoph Lameter wrote: This is a follow on patch related to the earlier discussion about restricting the spawning of kernel threads. See https://lkml.org/lkml/2013/9/5/426 usermodehelper() threads can currently run on all processors. This is an issue for low latency cores. This might be redundant with akpm's reply but here we go: low latency is a very confusing term nowadays. It's used by real time to describe the time it takes for a high prio task to take the CPU, and it's used by you for extreme HPC mode for deterministic undisturbed throughput. The changelog needs to be expanded to describe what's needed, or people will be confused when they will stare at that git blame line in one year from now :) Restrict usermodehelper() threads to the cores that kthreadd is restricted to. The default for kthreadd is to be allowed to run on an processors. s/an/all ? If the user restricts kthreadd then threads spawned by usermodhelper() will similarly restricted. Before this patch there is no way to limit the cpus that usermodehelper can run on since the affinity is set when the thread is spawned to all processors. Signed-off-by: Christoph Lameter c...@linux.com Index: linux/include/linux/kthread.h === --- linux.orig/include/linux/kthread.h2013-10-10 11:00:34.167771996 -0500 +++ linux/include/linux/kthread.h 2013-10-15 13:57:52.859056676 -0500 @@ -51,6 +51,7 @@ void kthread_parkme(void); int kthreadd(void *unused); extern struct task_struct *kthreadd_task; extern int tsk_fork_get_node(struct task_struct *tsk); +void set_kthreadd_affinity(void); /* * Simple work processor based on kthread. Index: linux/kernel/kmod.c === --- linux.orig/kernel/kmod.c 2013-10-10 11:00:39.091771917 -0500 +++ linux/kernel/kmod.c 2013-10-15 14:02:01.904261324 -0500 @@ -40,6 +40,7 @@ #include linux/ptrace.h #include linux/async.h #include asm/uaccess.h +#include linux/kthread.h #include trace/events/module.h @@ -209,8 +210,8 @@ static int call_usermodehelper(void flush_signal_handlers(current, 1); spin_unlock_irq(current-sighand-siglock); - /* We can run anywhere, unlike our parent keventd(). */ - set_cpus_allowed_ptr(current, cpu_all_mask); + /* We can run anywhere kthreadd can run */ + set_kthreadd_affinity(); If you really want your isolated CPUs to be undisturbed, you need this affinity to be set before the creation of this usermode helper. Otherwise it's going to run to any random place before you call the above function. Is there now way to control the kworker affinity which create this usermode helpers threads instead? -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH v2 2/6] ARM: dts: Specify clocks for UARTs on bcm11351
On Wed, Oct 16, 2013 at 10:47:06PM +0100, Tim Kryger wrote: Rather than declaring the frequency of the external clock, specify the label of the clock such that the driver may determine the frequency on its own. Nit: we're not specifying the label of the clock. Clocks are represented py a phand+args pair, and the important part is that we're specifying the clock itself. How about something like: 8 Currently the rate of the external clock input to snps,dw-apb-uart devices is described by a clock-frequency property rather than by reference to the clock itself. This patch changes the snps,dw-apb-uart entries in bcm11351.dtsi to refer to the parent clock directly, following the common clock bindings. 8 Also, this should probably be moved after the driver change, so as to not be unbootable temporarily. Thanks, Mark. Signed-off-by: Tim Kryger tim.kry...@linaro.org Reviewed-by: Markus Mayer markus.ma...@linaro.org Reviewed-by: Matt Porter matt.por...@linaro.org --- arch/arm/boot/dts/bcm11351.dtsi | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi index c6464fb..ce65367 100644 --- a/arch/arm/boot/dts/bcm11351.dtsi +++ b/arch/arm/boot/dts/bcm11351.dtsi @@ -43,7 +43,7 @@ compatible = brcm,bcm11351-dw-apb-uart, snps,dw-apb-uart; status = disabled; reg = 0x3e00 0x1000; - clock-frequency = 1300; + clocks = uartb_clk; interrupts = GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH; reg-shift = 2; reg-io-width = 4; @@ -53,7 +53,7 @@ compatible = brcm,bcm11351-dw-apb-uart, snps,dw-apb-uart; status = disabled; reg = 0x3e001000 0x1000; - clock-frequency = 1300; + clocks = uartb2_clk; interrupts = GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH; reg-shift = 2; reg-io-width = 4; @@ -63,7 +63,7 @@ compatible = brcm,bcm11351-dw-apb-uart, snps,dw-apb-uart; status = disabled; reg = 0x3e002000 0x1000; - clock-frequency = 1300; + clocks = uartb3_clk; interrupts = GIC_SPI 65 IRQ_TYPE_LEVEL_HIGH; reg-shift = 2; reg-io-width = 4; @@ -73,7 +73,7 @@ compatible = brcm,bcm11351-dw-apb-uart, snps,dw-apb-uart; status = disabled; reg = 0x3e003000 0x1000; - clock-frequency = 1300; + clocks = uartb4_clk; interrupts = GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH; reg-shift = 2; reg-io-width = 4; -- 1.8.0.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: [PATCHv3] mmc: atmel-mci: add vmmc-supply support
On 17 October 2013 12:46, Alexandre Belloni
alexandre.bell...@free-electrons.com wrote:
Other MMC hosts handle a regulator named vmmc-supply that allows to power the
MMC card or SDIO device before communicating on the bus.
Signed-off-by: Alexandre Belloni alexandre.bell...@free-electrons.com
Acked-by: Ulf Hansson ulf.hans...@linaro.org
---
Changes in v2:
- use mmc_regulator_get_supply instead of devm_regulator_get
Changes in v3:
- en/disable the regulator in .set_ios using mmc_regulator_set_ocr
drivers/mmc/host/atmel-mci.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/mmc/host/atmel-mci.c b/drivers/mmc/host/atmel-mci.c
index 69e438e..a9e1ba6 100644
--- a/drivers/mmc/host/atmel-mci.c
+++ b/drivers/mmc/host/atmel-mci.c
@@ -1385,8 +1385,14 @@ static void atmci_set_ios(struct mmc_host *mmc, struct
mmc_ios *ios)
clk_unprepare(host-mck);
switch (ios-power_mode) {
+ case MMC_POWER_OFF:
+ if (!IS_ERR(mmc-supply.vmmc))
+ mmc_regulator_set_ocr(mmc, mmc-supply.vmmc, 0);
+ break;
case MMC_POWER_UP:
set_bit(ATMCI_CARD_NEED_INIT, slot-flags);
+ if (!IS_ERR(mmc-supply.vmmc))
+ mmc_regulator_set_ocr(mmc, mmc-supply.vmmc,
ios-vdd);
break;
default:
/*
@@ -2196,6 +2202,7 @@ static int __init atmci_init_slot(struct atmel_mci
*host,
}
host-slot[id] = slot;
+ mmc_regulator_get_supply(mmc);
mmc_add_host(mmc);
if (gpio_is_valid(slot-detect_pin)) {
--
1.8.1.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 2/2] ARM: OMAP4460: cpuidle: WA for ROM bug because of CA9 r2pX gic control register change
On Thursday 17 October 2013 05:24 AM, Grygorii Strashko wrote:
On OMAP4+ devices, GIC register context is lost when MPUSS hits the
OSWR. On the CPU wakeup path, ROM code gets executed and one of the
steps in it is to restore the saved context of the GIC.
The ROM code uses GICD != 1 condition to decide how the GIC registers
are handled in wakeup path from OSWR. But, GICD register has changed
between CortexA9 r1pX and r2pX and it contains 2 bits now. Secure view
which ROM code sees:
bit 1 == Enable Non-secure
bit 0 == Enable secure
Non-secure view which HLOS sees:
bit 0 == Enable Non-secure
As result, on OMAP4460(r2pX) devices, when the ROM code is executed
during CPU1 wakeup, GICD == 3 and it fails to understand the real wakeup
power state and reconfigures GIC distributor to boot values and, as
result, the entire interrupt controller context will loose in a live
system.
Hence, implement a workaround on OMAP4460 devices in case if MPUSS has
hit OSWR - as long as CPU1 sees GICD == 1 in it's wakeup path from OSWR,
the issue won't happen:
1.1) CPU0 must disable the GIC distributor, before doing the CPU1
wakeup,
1.2) CPU0 should wait until CPU1 will re-enable the GIC distributor
2) CPU1 must re-enable the GIC distributor on it's wakeup path.
The workaround for CPUIdle has been implemented in the same way as
for boot-up hot-plug path in:
- http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;
a=commitdiff;h=ff999b8a0983ee15668394ed49e38d3568fc6859
For more information see:
- https://patchwork.kernel.org/patch/1609011/
- http://www.spinics.net/lists/arm-kernel/msg201402.html
The ROM code bug is applicable to only OMAP4460(r2pX) devices.
OMAP4470 (also r2pX) is not affected by this bug because ROM code has been
fixed.
Just give reference to the commit which has best description about
the bug and just say applying the fix for idle case.
ff999b8a {ARM: OMAP4460: Workaround for ROM...}
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Reported-and-Tested-by: Taras Kondratiuk taras.kondrat...@linaro.org
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/cpuidle44xx.c | 34 +-
arch/arm/mach-omap2/omap4-common.c |6 ++
3 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index b875a4a..7957110 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -232,6 +232,7 @@ static inline void __iomem *omap4_get_scu_base(void)
extern void __init gic_init_irq(void);
extern void gic_dist_disable(void);
+extern void gic_dist_enable(void);
extern bool gic_dist_disabled(void);
extern void gic_timer_retrigger(void);
extern void omap_smc1(u32 fn, u32 arg);
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 384aa1c..528638b 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -80,6 +80,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
int index)
{
struct idle_statedata *cx = state_ptr + index;
+u32 mpuss_context_lost = 0;
/*
* CPU0 has to wait and stay ON until CPU1 is OFF state.
@@ -126,13 +127,44 @@ static int omap_enter_idle_coupled(struct
cpuidle_device *dev,
omap4_enter_lowpower(dev-cpu, cx-cpu_state);
cpu_done[dev-cpu] = true;
+mpuss_context_lost = omap4_mpuss_read_prev_context_state();
+
Just use the targeted state since couple idle almost grantees
the low power entry. Even in failed case, applying errata sequence
is harmless.
/* Wakeup CPU1 only if it is not offlined */
if (dev-cpu == 0 cpumask_test_cpu(1, cpu_online_mask)) {
+/*
+ * GIC distributor control register has changed between
+ * CortexA9 r1pX and r2pX. The Control Register secure
+ * banked version is now composed of 2 bits:
+ * bit 0 == Secure Enable
+ * bit 1 == Non-Secure Enable
+ * The Non-Secure banked register has not changed
+ * Because the ROM Code is based on the r1pX GIC, the CPU1
+ * GIC restoration will cause a problem to CPU0 Non-Secure SW.
+ * The workaround must be:
+ * 1) Before doing the CPU1 wakeup, CPU0 must disable
+ * the GIC distributor and wait until it will be enabled by CPU1
+ * 2) CPU1 must re-enable the GIC distributor on
+ * it's wakeup path.
+ */
+if (IS_PM44XX_ERRATUM(PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD)
+mpuss_context_lost)
Use target state here..
+gic_dist_disable();
+
clkdm_wakeup(cpu_clkdm[1]);
omap_set_pwrdm_state(cpu_pd[1], PWRDM_POWER_ON);
clkdm_allow_idle(cpu_clkdm[1]);
+
+if
Re: [PATCH v2 1/2] ata: ahci_platform: Manage SATA PHY
Hi,
On Wednesday, October 16, 2013 02:42:52 PM Roger Quadros wrote:
From: Balaji T K balaj...@ti.com
Some platforms have a PHY hooked up to the
SATA controller. The PHY needs to be initialized
and powered up for SATA to work. We do that
using the PHY framework.
[Roger Q] Cleaned up.
CC: Tejun Heo t...@kernel.org
Signed-off-by: Balaji T K balaj...@ti.com
Signed-off-by: Roger Quadros rog...@ti.com
---
.../devicetree/bindings/ata/ahci-platform.txt |3 +-
drivers/ata/ahci.h |2 ++
drivers/ata/ahci_platform.c| 29
+++-
3 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt
b/Documentation/devicetree/bindings/ata/ahci-platform.txt
index 89de156..c8a6cea 100644
--- a/Documentation/devicetree/bindings/ata/ahci-platform.txt
+++ b/Documentation/devicetree/bindings/ata/ahci-platform.txt
@@ -4,7 +4,8 @@ SATA nodes are defined to describe on-chip Serial ATA
controllers.
Each SATA controller should have its own node.
Required properties:
-- compatible: compatible list, contains snps,spear-ahci
+- compatible: compatible list, contains snps,spear-ahci,
+ snps,exynos5440-ahci or snps,dwc-ahci
minor nit:
s/snps,exynos5440-ahci/snps,exynos5440-ahci/
- interrupts: interrupt mapping for SATA IRQ
- reg : registers mapping
diff --git a/drivers/ata/ahci.h b/drivers/ata/ahci.h
index 1145637..94484cb 100644
--- a/drivers/ata/ahci.h
+++ b/drivers/ata/ahci.h
@@ -37,6 +37,7 @@
#include linux/clk.h
#include linux/libata.h
+#include linux/phy/phy.h
/* Enclosure Management Control */
#define EM_CTRL_MSG_TYPE 0x000f
@@ -322,6 +323,7 @@ struct ahci_host_priv {
u32 em_buf_sz; /* EM buffer size in byte */
u32 em_msg_type;/* EM message type */
struct clk *clk; /* Only for platforms
supporting clk */
+ struct phy *phy; /* If platforms use phy */
minor nit:
s/If platforms use phy/If platform uses PHY/
void*plat_data; /* Other platform data */
};
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 2daaee0..5a0f1418 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -141,6 +141,21 @@ static int ahci_probe(struct platform_device *pdev)
}
}
+ hpriv-phy = devm_phy_get(dev, sata-phy);
+ if (IS_ERR(hpriv-phy)) {
+ dev_dbg(dev, can't get sata-phy\n);
+ /* return only if -EPROBE_DEFER */
+ if (PTR_ERR(hpriv-phy) == -EPROBE_DEFER) {
+ rc = -EPROBE_DEFER;
+ goto disable_unprepare_clk;
+ }
+ }
+
+ if (!IS_ERR(hpriv-phy)) {
+ phy_init(hpriv-phy);
+ phy_power_on(hpriv-phy);
+ }
+
/*
* Some platforms might need to prepare for mmio region access,
* which could be done in the following init call. So, the mmio
@@ -150,7 +165,7 @@ static int ahci_probe(struct platform_device *pdev)
if (pdata pdata-init) {
rc = pdata-init(dev, hpriv-mmio);
if (rc)
- goto disable_unprepare_clk;
+ goto disable_phy;
}
ahci_save_initial_config(dev, hpriv,
@@ -220,6 +235,12 @@ static int ahci_probe(struct platform_device *pdev)
pdata_exit:
if (pdata pdata-exit)
pdata-exit(dev);
+disable_phy:
+ if (!IS_ERR(hpriv-phy)) {
+ phy_power_off(hpriv-phy);
+ phy_exit(hpriv-phy);
+ }
+
disable_unprepare_clk:
if (!IS_ERR(hpriv-clk))
clk_disable_unprepare(hpriv-clk);
@@ -238,6 +259,11 @@ static void ahci_host_stop(struct ata_host *host)
if (pdata pdata-exit)
pdata-exit(dev);
+ if (!IS_ERR(hpriv-phy)) {
+ phy_power_off(hpriv-phy);
+ phy_exit(hpriv-phy);
+ }
+
if (!IS_ERR(hpriv-clk)) {
clk_disable_unprepare(hpriv-clk);
clk_put(hpriv-clk);
@@ -328,6 +354,7 @@ static SIMPLE_DEV_PM_OPS(ahci_pm_ops, ahci_suspend,
ahci_resume);
Shouldn't phy_power_off/on also be used in ahci_suspend() and ahci_resume()?
static const struct of_device_id ahci_of_match[] = {
{ .compatible = snps,spear-ahci, },
{ .compatible = snps,exynos5440-ahci, },
+ { .compatible = snps,dwc-ahci, },
This change together with ahci-platform.txt one should be in a separate patch.
{},
};
MODULE_DEVICE_TABLE(of, ahci_of_match);
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
Samsung Electronics
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to
Re: [PATCH] x86: Remove WARN_ON(in_nmi()) from vmalloc_fault
On Wed, Oct 16, 2013 at 12:36:32PM -0700, Paul E. McKenney wrote: On Wed, Oct 16, 2013 at 03:08:57PM +0200, Frederic Weisbecker wrote: On Wed, Oct 16, 2013 at 08:45:18AM -0400, Steven Rostedt wrote: On Wed, 16 Oct 2013 13:40:37 +0200 Frederic Weisbecker fweis...@gmail.com wrote: On Tue, Oct 15, 2013 at 04:39:06PM -0400, Steven Rostedt wrote: Since the NMI iretq nesting has been fixed, there's no reason that an NMI handler can not take a page fault for vmalloc'd code. No locks are taken in that code path, and the software now handles nested NMIs when the fault re-enables NMIs on iretq. Not only that, if the vmalloc_fault() WARN_ON_ONCE() is hit, and that warn on triggers a vmalloc fault for some reason, then we can go into an infinite loop (the WARN_ON_ONCE() does the WARN() before updating the variable to make it happen once). Reported-by: Liu, Chuansheng chuansheng@intel.com Signed-off-by: Steven Rostedt rost...@goodmis.org Thanks! For now we probably indeed want this patch. But I hope it's only for the short term. Why? I still think that allowing faults in NMIs is very nasty, as we expect NMIs to never be disturbed. We do faults (well, breakpoints really) in NMI to enable tracing. I'm not even sure if that interacts correctly with the rcu_nmi_enter() and preempt_count NMI_MASK things. Not sure how perf is ready for that either (now hardware events can be interrupted by fault trace events). I'm a bit confused. What doesn't interact correctly with rcu_nmi_enter()? Faults can call rcu_user_exit() / rcu_user_enter(). This is not supposed to happen between rcu_nmi_enter() and rcu_nmi_exit(). rdtp-dynticks would be incremented in the wrong way. I can attest to this! NMIs check for being nested within process/irq-based non-idle sojourns, but not the other way around. The result is that RCU will be ignoring you during that time, and not even disabling interrupts will save you. It will check rdtp-dynticks, see that its value is even, and register a quiescent state on behalf of the hapless CPU. Fortunately, we are avoiding this with the in_interrupt() check on user_enter() and user_exit(). Their goal is precisely to deal with traps/faults happening on interrupts :) Ah but we have an in_interrupt() check in context_tracking_user_enter() that protects us against that. Here you are relying on the exception being treated as an interrupt, correct? From an RCU point of view yeah. In these cases the exception is either protected under rcu_irq_* and rcu_nmi* APIs, depending on where it happened. -- 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] scsi: BusLogic: Fix an oops when intializing multimaster adapter
On Wed, Sep 25, 2013 at 10:45 AM, Khalid Aziz khalid.a...@oracle.com wrote:
This fixes an oops caused by buslogic driver when initializing a BusLogic
MultiMaster adapter. Initialization code used scope of a variable
incorrectly which created a NULL pointer. Oops message is below:
BUG: unable to handle kernel NULL pointer dereference at 000c
IP: [c150c137] blogic_init_mm_probeinfo.isra.17+0x20a/0x583
*pde =
Oops: 002 [#1] PREEMPT SMP
Modules linked in:
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.11.1.puz1 #1
Hardware name:/Canterwood, BIOS 6.00 PG 05/16/2003
task: f705 ti: f7054000 task.ti: f7054000
EIP: 0060:[c150c137] EFLAGS: 00010246 CPU:1
EIP is at blogic_init_mm_probeinfo.isra.17+0x20a/0x583
EAX: 0013 EBX: ECX: EDX: f8001000
ESI: f71cb800 EDI: f7388000 EBP: 7800 ESP: f7055c84
DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
CR0: 8005003b CR2: 000c CR3: 0154f000 CR4: 07d0
Stack:
001c c11a59f6 f7055c98 8130
0003 0013 f8001000 0001 03d0
c14e3f84 f78803c8 f738c000 00e9
Call Trace:
[c11a59f6] ? pci_get_subsys+0x33/0x38
[c150c4fb] ? blogic_init_probeinfo_list+0x4b/0x19e
[c108d593] ? __alloc_pages_nodemask+0xe3/0x623
[c108d593] ? __alloc_pages_nodemask+0xe3/0x623
[c10fb99e] ? sysfs_link_sibling+0x61/0x8d
[c10b0519] ? kmem_cache_alloc+0x8b/0xb5
[c150cce5] ? blogic_init+0xa1/0x10e8
[c10fc0a8] ? sysfs_add_one+0x10/0x9d
[c10fc18a] ? sysfs_addrm_finish+0x12/0x85
[c10fca37] ? sysfs_do_create_link_sd+0x9d/0x1b4
[c117c272] ? blk_register_queue+0x69/0xb3
[c10fcb68] ? sysfs_create_link+0x1a/0x2c
[c1181a07] ? add_disk+0x1a1/0x3c7
[c138737b] ? klist_next+0x60/0xc3
[c122cc3a] ? scsi_dh_detach+0x68/0x68
[c1213e36] ? bus_for_each_dev+0x51/0x61
[c1000356] ? do_one_initcall+0x22/0x12c
[c10f3688] ? __proc_create+0x8c/0xba
[c150cc44] ? blogic_setup+0x5f6/0x5f6
[c14e94aa] ? repair_env_string+0xf/0x4d
[c14e949b] ? do_early_param+0x71/0x71
[c103efaa] ? parse_args+0x21f/0x33d
[c14e9a54] ? kernel_init_freeable+0xdf/0x17d
[c14e949b] ? do_early_param+0x71/0x71
[c1388b64] ? kernel_init+0x8/0xc0
[c139] ? ret_from_kernel_thread+0x6/0x28
[c1392227] ? ret_from_kernel_thread+0x1b/0x28
[c1388b5c] ? rest_init+0x6c/0x6c
Code: 89 44 24 10 0f b6 44 24 3d 89 44 24 0c c7 44 24 08 00 00 00 00 c7 44 24
04 38 62 46 c1 c7 04 24 02 00 00 00 e8 78 13 d2 ff 31 db 89 6b 0c b0 20 89
ea ee
c7 44 24 08 04 00 00 00 8d 44 24 4c 89
EIP: [c150c137] blogic_init_mm_probeinfo.isra.17+0x20a/0x583 SS:ESP
0068:f7055c84
CR2: 000c
---[ end trace 17f45f5196d40487 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0009
Signed-off-by: Khalid Aziz khalid.a...@oracle.com
Cc: sta...@vger.kernel.org # 3.11.x
Cc: Khalid Aziz kha...@gonehiking.org
Reported-by: Pierre Uszynski pie...@rahul.net
Tested-by: Pierre Uszynski pie...@rahul.net
We had a user report an issue starting VMWare guests using BusLogic
with the 3.11 kernel in Fedora. They tested a kernel build based on
3.11.5 plus this patch and it fixes their issue. Details here:
https://bugzilla.redhat.com/show_bug.cgi?id=1015558
You can add a Tested-by: Bojan Smojver bo...@rexursive.com if you'd like.
josh
---
drivers/scsi/BusLogic.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/scsi/BusLogic.c b/drivers/scsi/BusLogic.c
index feab3a5..757eb07 100644
--- a/drivers/scsi/BusLogic.c
+++ b/drivers/scsi/BusLogic.c
@@ -696,7 +696,7 @@ static int __init blogic_init_mm_probeinfo(struct
blogic_adapter *adapter)
while ((pci_device = pci_get_device(PCI_VENDOR_ID_BUSLOGIC,
PCI_DEVICE_ID_BUSLOGIC_MULTIMASTER,
pci_device)) != NULL) {
- struct blogic_adapter *adapter = adapter;
+ struct blogic_adapter *host_adapter = adapter;
struct blogic_adapter_info adapter_info;
enum blogic_isa_ioport mod_ioaddr_req;
unsigned char bus;
@@ -744,9 +744,9 @@ static int __init blogic_init_mm_probeinfo(struct
blogic_adapter *adapter)
known and enabled, note that the particular Standard ISA
I/O
Address should not be probed.
*/
- adapter-io_addr = io_addr;
- blogic_intreset(adapter);
- if (blogic_cmd(adapter, BLOGIC_INQ_PCI_INFO, NULL, 0,
+ host_adapter-io_addr = io_addr;
+ blogic_intreset(host_adapter);
+ if (blogic_cmd(host_adapter, BLOGIC_INQ_PCI_INFO, NULL, 0,
adapter_info, sizeof(adapter_info)) ==
sizeof(adapter_info)) {
if (adapter_info.isa_port 6)
@@ -762,7 +762,7 @@
Re: epoll oops.
On 10/16, Eric Wong wrote: Oleg Nesterov o...@redhat.com wrote: Yes. Before that 971316f0503a hack epoll can't even know if the task which did signalfd_poll() exits and frees the active signalfd_wqh. If for example that task forked a child before exit. And the whole RCU logic is only needed if exit/ep_remove_wait_queue actually race with each other. Is there any chance this oops is caused by (or at least more easily exposed by) commit 91cf5ab60ff82ecf4550a596867787c1e360dd3f ? (epoll: add a reschedule point in ep_free()) I thought 91cf5ab would be benign, except... Yes, ugly, agreed. d80e731ecab4 even tries to docunent that this all is the hack. .. the following sentence from d80e731ecab4 caught my eye: It also assumes that nobody can take tasklist_lock under epoll locks, this seems to be true. This just reminds that with this patch __wake_up/ep_poll_callback can be called under write_lock(tasklist). I haven't been able to trace if cond_resched() can take tasklist_lock. No, it can't hold the non-sleepable rwlock_t. And the sentence above doesn't mean the locks like epmutex, it is mostlt about ep-lock. Oleg. -- 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] vmsplice: Add limited zero copy to vmsplice
* Vlastimil Babka (vba...@suse.cz) wrote:
On 10/07/2013 10:21 PM, Robert C Jennings wrote:
From: Matt Helsley matt.hels...@gmail.com
It is sometimes useful to move anonymous pages over a pipe rather than
save/swap them. Check the SPLICE_F_GIFT and SPLICE_F_MOVE flags to see
if userspace would like to move such pages. This differs from plain
SPLICE_F_GIFT in that the memory written to the pipe will no longer
have the same contents as the original -- it effectively faults in new,
empty anonymous pages.
On the read side the page written to the pipe will be copied unless
SPLICE_F_MOVE is used. Otherwise copying will be performed and the page
will be reclaimed. Note that so long as there is a mapping to the page
copies will be done instead because rmap will have upped the map count for
each anonymous mapping; this can happen do to fork(), for example. This
is necessary because moving the page will usually change the anonymous
page's nonlinear index and that can only be done if it's unmapped.
You might want to update comments of vmsplice_to_user() and
SYSCALL_DEFINE4(vmsplice) as they both explain how it's done only via
copying.
Vlastimil
I will update those as well. Thanks.
Signed-off-by: Matt Helsley matt.hels...@gmail.com
Signed-off-by: Robert C Jennings r...@linux.vnet.ibm.com
---
fs/splice.c | 63
+
1 file changed, 63 insertions(+)
diff --git a/fs/splice.c b/fs/splice.c
index a62d61e..9d2ed128 100644
--- a/fs/splice.c
+++ b/fs/splice.c
@@ -32,6 +32,10 @@
#include linux/gfp.h
#include linux/socket.h
#include linux/compat.h
+#include linux/page-flags.h
+#include linux/hugetlb.h
+#include linux/ksm.h
+#include linux/swapops.h
#include internal.h
/*
@@ -1562,6 +1566,65 @@ static int pipe_to_user(struct pipe_inode_info
*pipe, struct pipe_buffer *buf,
char *src;
int ret;
+ if (!buf-offset (buf-len == PAGE_SIZE)
+ (buf-flags PIPE_BUF_FLAG_GIFT) (sd-flags SPLICE_F_MOVE)) {
+ struct page *page = buf-page;
+ struct mm_struct *mm;
+ struct vm_area_struct *vma;
+ spinlock_t *ptl;
+ pte_t *ptep, pte;
+ unsigned long useraddr;
+
+ if (!PageAnon(page))
+ goto copy;
+ if (PageCompound(page))
+ goto copy;
+ if (PageHuge(page) || PageTransHuge(page))
+ goto copy;
+ if (page_mapped(page))
+ goto copy;
+ useraddr = (unsigned long)sd-u.userptr;
+ mm = current-mm;
+
+ ret = -EAGAIN;
+ down_read(mm-mmap_sem);
+ vma = find_vma_intersection(mm, useraddr, useraddr + PAGE_SIZE);
+ if (IS_ERR_OR_NULL(vma))
+ goto up_copy;
+ if (!vma-anon_vma) {
+ ret = anon_vma_prepare(vma);
+ if (ret)
+ goto up_copy;
+ }
+ zap_page_range(vma, useraddr, PAGE_SIZE, NULL);
+ ret = lock_page_killable(page);
+ if (ret)
+ goto up_copy;
+ ptep = get_locked_pte(mm, useraddr, ptl);
+ if (!ptep)
+ goto unlock_up_copy;
+ pte = *ptep;
+ if (pte_present(pte))
+ goto unlock_up_copy;
+ get_page(page);
+ page_add_anon_rmap(page, vma, useraddr);
+ pte = mk_pte(page, vma-vm_page_prot);
+ set_pte_at(mm, useraddr, ptep, pte);
+ update_mmu_cache(vma, useraddr, ptep);
+ pte_unmap_unlock(ptep, ptl);
+ ret = 0;
+unlock_up_copy:
+ unlock_page(page);
+up_copy:
+ up_read(mm-mmap_sem);
+ if (!ret) {
+ ret = sd-len;
+ goto out;
+ }
+ /* else ret 0 and we should fallback to copying */
+ VM_BUG_ON(ret 0);
+ }
+copy:
/*
* See if we can use the atomic maps, by prefaulting in the
* pages and doing an atomic copy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/4] Exynos 5410 Dual cluster support
On 17.10.2013 17:04, Aliaksei Katovich wrote: hi Kevin; Vyacheslav Tyrtov v.tyr...@samsung.com writes: The series of patches represent support of Exynos 5410 SoC The Exynos 5410 is the first Samsung SoC based on bigLITTLE architecture. Patches allow all 8 CPU cores (4 x A7 and 4 x A15) to run at the same time Patches add new platform description, support of clock controller, dual cluster support and device tree for Exynos 5410 Has been build on v3.12-rc5. Has been tested on Exynos 5410 reference board (exynos_defconfig). Has anyone tried this on the exynos5410 based odroid-xu yet? I tried booting this on my recently arrived odroid-xu, but am not getting it to boot. I am able to boot my odroid-xu+e to busybox with these patches applied against 3.12-rc5: exynos_defconfig and exynos5410-smdk5410.dtb were used. However there seem to be some issues with virq allocations, like this: snippet Starting kernel ... [0.00] [c0014d48] (unwind_backtrace+0x0/0xf8) from [c00117d0] (show_stack+0x10/0x14) [0.00] [c00117d0] (show_stack+0x10/0x14) from [c0363488] (dump_stack+0x6c/0xac) [0.00] [c0363488] (dump_stack+0x6c/0xac) from [c001e330] (warn_slowpath_common+0x64/0x88) [0.00] [c001e330] (warn_slowpath_common+0x64/0x88) from [c001e3e8] (warn_slowpath_fmt+0x30/0x40) [0.00] [c001e3e8] (warn_slowpath_fmt+0x30/0x40) from [c005a1b4] (irq_domain_associate+0x128/0x1a8) [0.00] [c005a1b4] (irq_domain_associate+0x128/0x1a8) from [c005a508] (irq_domain_associate_many+0x30/0x3c ) [0.00] [c005a508] (irq_domain_associate_many+0x30/0x3c) from [c005a768] (irq_domain_add_simple+0x78/0x90) [0.00] [c005a768] (irq_domain_add_simple+0x78/0x90) from [c04b044c] (combiner_of_init+0xb4/0x198) [0.00] [c04b044c] (combiner_of_init+0xb4/0x198) from [c04b6938] (of_irq_init+0x278/0x2a0) [0.00] [c04b6938] (of_irq_init+0x278/0x2a0) from [c049b8fc] (start_kernel+0x18c/0x384) [0.00] [c049b8fc] (start_kernel+0x18c/0x384) from [40008074] (0x40008074) [0.00] ---[ end trace 1b75b31a2719edcd ]--- [0.00] [ cut here ] [0.00] WARNING: CPU: 0 PID: 0 at kernel/irq/irqdomain.c:278 irq_domain_associate+0x128/0x1a8() [0.00] error: virq337 is not allocated [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW 3.12.0-rc5-4-g1cb405f #1 [0.00] [c0014d48] (unwind_backtrace+0x0/0xf8) from [c00117d0] (show_stack+0x10/0x14) [0.00] [c00117d0] (show_stack+0x10/0x14) from [c0363488] (dump_stack+0x6c/0xac) [0.00] [c0363488] (dump_stack+0x6c/0xac) from [c001e330] (warn_slowpath_common+0x64/0x88) [0.00] [c001e330] (warn_slowpath_common+0x64/0x88) from [c001e3e8] (warn_slowpath_fmt+0x30/0x40) [0.00] [c001e3e8] (warn_slowpath_fmt+0x30/0x40) from [c005a1b4] (irq_domain_associate+0x128/0x1a8) [0.00] [c005a1b4] (irq_domain_associate+0x128/0x1a8) from [c005a508] (irq_domain_associate_many+0x30/0x3c ) [0.00] [c005a508] (irq_domain_associate_many+0x30/0x3c) from [c005a768] (irq_domain_add_simple+0x78/0x90) [0.00] [c005a768] (irq_domain_add_simple+0x78/0x90) from [c04b044c] (combiner_of_init+0xb4/0x198) [0.00] [c04b044c] (combiner_of_init+0xb4/0x198) from [c04b6938] (of_irq_init+0x278/0x2a0) [0.00] [c04b6938] (of_irq_init+0x278/0x2a0) from [c049b8fc] (start_kernel+0x18c/0x384) [0.00] [c049b8fc] (start_kernel+0x18c/0x384) from [40008074] (0x40008074) [0.00] ---[ end trace 1b75b31a2719edce ]--- [0.00] [ cut here ] /snippet You can check full boot log here http://sprunge.us/NKcU -- Aliaksei I'm not yet terribly familiar with this SoC, what are the settings needed for DEBUG_LL on this board? Thanks, Kevin ___ linux-arm-kernel mailing list linux-arm-ker...@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel Also change NR_CPUS to 8 in kernel config, so you will get 8 cores booted instead of 2. Best regards, Tarek Dakhran -- 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 -next] misc: fix various misc/mic/host/ build errors
On Wed, Oct 16, 2013 at 01:37:27PM -0700, Greg Kroah-Hartman wrote: On Wed, Oct 16, 2013 at 10:30:25PM +0200, Thierry Reding wrote: On Wed, Oct 16, 2013 at 12:44:40PM -0700, Greg Kroah-Hartman wrote: On Wed, Oct 16, 2013 at 12:41:08PM -0700, Randy Dunlap wrote: On 10/16/13 12:26, Greg Kroah-Hartman wrote: On Mon, Oct 14, 2013 at 12:38:06PM -0700, Randy Dunlap wrote: From: Randy Dunlap rdun...@infradead.org Fix various build errors (on x86_64) for drivers/misc/mic/host/: drivers/misc/mic/host/mic_main.c:378:3: error: too many arguments to function 'sysfs_get_dirent' drivers/misc/mic/host/mic_intr.h:134:58: warning: 'struct pci_dev' declared inside parameter list [enabled by default] drivers/misc/mic/host/mic_intr.h:134:58: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] drivers/misc/mic/host/mic_intr.h:135:58: warning: 'struct pci_dev' declared inside parameter list [enabled by default] drivers/misc/mic/host/mic_device.h:169:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] drivers/misc/mic/host/mic_device.h: In function 'mic_mmio_read': drivers/misc/mic/host/mic_device.h:169:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] drivers/misc/mic/host/mic_device.h: In function 'mic_mmio_write': drivers/misc/mic/host/mic_device.h:183:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration] Signed-off-by: Randy Dunlap rdun...@infradead.org Cc: Harshavardhan R Kharche harshavardhan.r.khar...@intel.com Cc: Ashutosh Dixit ashutosh.di...@intel.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Nikhil Rao nikhil@intel.com Cc: Sudeep Dutt sudeep.d...@intel.com This is a -next issue only at this point in time, I thought it was in the -next tree as a fixup already? Are you asking the driver maintainers? No, the linux-next maintainers. The driver maintainers have nothing to do with this, it's a sysfs change in my driver-core tree that causes this issue. Well, we do carry a patch to fix this, but that generally doesn't get carried to Linus' tree automatically as far as I know. So I guess it's fine for now, but when the merge window opens you'll need to make sure that Linus merges the branches in the correct order so that the build doesn't break in between. Yes, I'll do that as part of my normal tree submission process. Actually, ensuring correct merge order won't be enough, will it? That doesn't magically fixes that the function's signature actually changed. Shouldn't the update of the sysfs_get_dirent() call be fixed within the same patch that updates the sysfs_get_dirent() signature? Thierry pgpxiT_0qzUSq.pgp Description: PGP signature
Re: [RESEND PATCH v2 4/6] clocksource: kona: Add basic use of external clock
On Wed, Oct 16, 2013 at 10:47:08PM +0100, Tim Kryger wrote:
When an clock handle is specified in the device tree, enable it and use
it to determine the external clock frequency.
I'd drop handle here and just say When a clock is specified.
This will need a binding document update.
Signed-off-by: Tim Kryger tim.kry...@linaro.org
Reviewed-by: Markus Mayer markus.ma...@linaro.org
Reviewed-by: Matt Porter matt.por...@linaro.org
---
drivers/clocksource/bcm_kona_timer.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/clocksource/bcm_kona_timer.c
b/drivers/clocksource/bcm_kona_timer.c
index 0d7d8c3..fd11f96 100644
--- a/drivers/clocksource/bcm_kona_timer.c
+++ b/drivers/clocksource/bcm_kona_timer.c
@@ -17,6 +17,7 @@
#include linux/jiffies.h
#include linux/clockchips.h
#include linux/types.h
+#include linux/clk.h
#include linux/io.h
#include asm/mach/time.h
@@ -107,11 +108,18 @@ static const struct of_device_id bcm_timer_ids[]
__initconst = {
static void __init kona_timers_init(struct device_node *node)
{
u32 freq;
+ struct clk *external_clk;
- if (!of_property_read_u32(node, clock-frequency, freq))
+ external_clk = of_clk_get_by_name(node, NULL);
Is there only a single external clock input to the kona timer, or is
only one relevant here?
Are there any other inputs currently not modelled (e.g. regulators)?
+
+ if (!IS_ERR(external_clk)) {
+ arch_timer_rate = clk_get_rate(external_clk);
+ clk_prepare_enable(external_clk);
+ } else if (!of_property_read_u32(node, clock-frequency, freq)) {
arch_timer_rate = freq;
- else
- panic(clock-frequency not set in the .dts file);
+ } else {
+ panic(neither clock-frequency or clocks handle in .dts file);
Nit: it's not a handle, it's a phandle+args pair.
Why not just Unable to determine clock frequency?
Do we need to panic here? Might a system have other clocks it could use
to continue?
Thanks,
Mark.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH v2 5/6] ARM: dts: Specify clocks for timer on bcm11351
diff --git a/arch/arm/boot/dts/bcm11351.dtsi b/arch/arm/boot/dts/bcm11351.dtsi index 193659c..39c1395 100644 --- a/arch/arm/boot/dts/bcm11351.dtsi +++ b/arch/arm/boot/dts/bcm11351.dtsi @@ -95,7 +95,7 @@ compatible = brcm,kona-timer; reg = 0x35006000 0x1000; interrupts = GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH; - clock-frequency = 32768; + clocks = hub_timer_clk; This should probably be after the code change that enables support for a clocks property. Thanks, Mark. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC V4 PATCH 00/15] Signature verification of hibernate snapshot
On Sunday, September 15, 2013 08:56:46 AM Lee, Chun-Yi wrote: Hi experts, This patchset is the implementation for signature verification of hibernate snapshot image. The origin idea is from Jiri Kosina: Let EFI bootloader generate key-pair in UEFI secure boot environment, then pass it to kernel for sign/verify S4 image. Due to there have potential threat from the S4 image hacked, it may causes kernel lost the trust in UEFI secure boot. Hacker attack the S4 snapshot image in swap partition through whatever exploit from another trusted OS, and the exploit may don't need physical access machine. So, this patchset give the ability to kernel for parsing RSA private key from EFI bootloader, then using the private key to generate the signature of S4 snapshot image. Kernel put the signature to snapshot header, and verify the signature when kernel try to recover snapshot image to memory. I wonder what the status of this work is? Is it considered ready for inclusion or are you still going to work on it and resubmit? Rafael -- 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 2/3] arm: Add [U]EFI runtime services support
On Thu, 03 Oct, at 12:24:40PM, Leif Lindholm wrote:
+/*
+ * If you need to (temporarily) support buggy firmware.
+ */
+#define KEEP_BOOT_SERVICES_REGIONS
Have you seen firmware that requires this? I'm just curious more than
anything else.
+/*
+ * Returns 1 if 'facility' is enabled, 0 otherwise.
+ */
+int efi_enabled(int facility)
+{
+ return test_bit(facility, arm_efi_facility) != 0;
+}
+EXPORT_SYMBOL(efi_enabled);
This should move to drivers/firmware/efi/efi.c. Let me write a patch
that moves the x86 stuff out of arch/x86 and means you can get rid of
this hunk.
+/*
+ * Called explicitly from init/mm.c
+ */
That's init/main.c.
+void __init efi_enter_virtual_mode(void)
+{
+ efi_status_t status;
+
+ if (!efi_enabled(EFI_BOOT)) {
+ pr_info(EFI services will not be available.\n);
+ return;
This is dead code as PATCH 3 does,
diff --git a/init/main.c b/init/main.c
index af310af..ec6d76e 100644
--- a/init/main.c
+++ b/init/main.c
@@ -875,6 +875,10 @@ static noinline void __init
kernel_init_freeable(void)
smp_prepare_cpus(setup_max_cpus);
do_pre_smp_initcalls();
+
+ if (IS_ENABLED(CONFIG_ARM) efi_enabled(EFI_BOOT))
+ efi_enter_virtual_mode();
+
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCHv1 1/8] ALSA: Add SAI SoC Digital Audio Interface driver.
On Thu, Oct 17, 2013 at 03:51:54PM +0200, Lars-Peter Clausen wrote: On 10/17/2013 03:37 PM, Timur Tabi wrote: I understand that, but I'm trying to figure out why of_iomap() is okay for hundreds of other drivers, but not this one. I've used it dozens of times myself, without ever worrying about overlapping regions. The driver would work fine with just of_iomap(). But the resource range check comes basically for free and it does help to catch errors, so I'd recommend on using it rather than not using it. There's also the fact that it's a devm_ function which means less error handling code that we can break which is nice. There's probably a case for an improved OF helper here... signature.asc Description: Digital signature
Re: [RESEND PATCH v2 6/6] mmc: sdhci-bcm-kona: Add basic use of clocks
On Wed, Oct 16, 2013 at 10:47:10PM +0100, Tim Kryger wrote:
Enable the external clock needed by the host controller during the
probe and disable it during the remove.
This requires a biding document update.
I note that the binding is already incomplete (it does not describe the
interrupts or reg).
Signed-off-by: Tim Kryger tim.kry...@linaro.org
Reviewed-by: Markus Mayer markus.ma...@linaro.org
Reviewed-by: Matt Porter matt.por...@linaro.org
---
drivers/mmc/host/sdhci-bcm-kona.c | 30 --
1 file changed, 28 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/sdhci-bcm-kona.c
b/drivers/mmc/host/sdhci-bcm-kona.c
index 85472d3..91db099 100644
--- a/drivers/mmc/host/sdhci-bcm-kona.c
+++ b/drivers/mmc/host/sdhci-bcm-kona.c
@@ -54,6 +54,7 @@
struct sdhci_bcm_kona_dev {
struct mutexwrite_lock; /* protect back to back writes */
+ struct clk *external_clk;
Is this the only clock input the unit has?
Are there any other external resources the device needs (e.g. gpios,
regulators)?
};
@@ -252,11 +253,29 @@ static int sdhci_bcm_kona_probe(struct platform_device
*pdev)
mmc_of_parse(host-mmc);
if (!host-mmc-f_max) {
- dev_err(pdev-dev, Missing max-freq for SDHCI cfg\n);
+ dev_err(dev, Missing max-freq for SDHCI cfg\n);
This seems like an unrelated change.
ret = -ENXIO;
goto err_pltfm_free;
}
+ /* Get and enable the external clock */
+ kona_dev-external_clk = devm_clk_get(dev, NULL);
+ if (IS_ERR(kona_dev-external_clk)) {
+ dev_err(dev, Failed to get external clock\n);
+ ret = PTR_ERR(kona_dev-external_clk);
+ goto err_pltfm_free;
This seems like a pretty clear breakage of existing DTBs.
Why?
Thanks,
Mark.
--
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] tty/serial: at91: add a fallback option to determine uart/usart property
On Thu, Oct 17, 2013 at 10:16:47AM +0200, Nicolas Ferre wrote:
On 16/10/2013 22:14, Greg Kroah-Hartman :
On Tue, Oct 15, 2013 at 11:19:18AM +0200, Nicolas Ferre wrote:
On 14/10/2013 15:59, Jean-Christophe PLAGNIOL-VILLARD :
On 10:43 Thu 10 Oct , Nicolas Ferre wrote:
On older SoC, the name field is not filled in the register map.
Fix the way to figure out if the serial port is an uart or an usart for
these
older products (with corresponding properties).
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
---
drivers/tty/serial/atmel_serial.c | 19 ++-
include/linux/atmel_serial.h | 1 +
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/atmel_serial.c
b/drivers/tty/serial/atmel_serial.c
index 6b0f75e..c7d99af 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -99,6 +99,7 @@ static void atmel_stop_rx(struct uart_port *port);
#define UART_PUT_RTOR(port,v) __raw_writel(v, (port)-membase +
ATMEL_US_RTOR)
#define UART_PUT_TTGR(port, v) __raw_writel(v, (port)-membase +
ATMEL_US_TTGR)
#define UART_GET_IP_NAME(port) __raw_readl((port)-membase +
ATMEL_US_NAME)
+#define UART_GET_IP_VERSION(port) __raw_readl((port)-membase +
ATMEL_US_VERSION)
/* PDC registers */
#define UART_PUT_PTCR(port,v) __raw_writel(v, (port)-membase +
ATMEL_PDC_PTCR)
@@ -1503,6 +1504,7 @@ static void atmel_get_ip_name(struct uart_port
*port)
{
struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
int name = UART_GET_IP_NAME(port);
+u32 version;
int usart, uart;
/* usart and uart ascii */
usart = 0x55534152;
@@ -1517,7 +1519,22 @@ static void atmel_get_ip_name(struct uart_port
*port)
dev_dbg(port-dev, This is uart\n);
atmel_port-is_usart = false;
} else {
-dev_err(port-dev, Not supported ip name, set to
uart\n);
+/* fallback for older SoCs: use version field */
+version = UART_GET_IP_VERSION(port);
+switch (version) {
+case 0x302:
+case 0x10213:
+dev_dbg(port-dev, This version is usart\n);
+atmel_port-is_usart = true;
+break;
+case 0x203:
+case 0x10202:
+dev_dbg(port-dev, This version is uart\n);
+atmel_port-is_usart = false;
+break;
+default:
+dev_err(port-dev, Not supported ip name nor
version, set to uart\n);
it's not really an error a dev_warn is more oppropriate
As we are already in -rc5 and that these fixes are critical for at91
platforms, I will not re-spin another patch just for this.
Moreover, I have the feeling that if we end up in this case, it
means that we are in big troubles because the usart/uart included in
the product triggering this log is not known (I recall that newer
products do not have to hit these lines of code).
With these 2 reasons, I prefer to keep my patch like it is.
Greg, can you consider taking these two patches as regression fixes
for 3.12 (with Tested-by tag from Thomas)?
Is this really a regression from 3.11?
Yes it is. Commit id that I am referring to in patch 1/2
(055560b04a8cd063aea916fd083b7aec02c2adb8) hit the mainline in 3.12-rc
time-frame.
Ok.
What's the worry about waiting
for 3.13-rc1, getting this correct, and then backporting them to the
3.12-stable trees?
It will break all older at91 in 3.12-final. Moreover, I do think that
the actual patches are bringing an incorrect solution and I do not plan
to have a better one (which one?) for 3.13...
I'd prefer that, so, please clean this up properly and resend it, with
the tested-by: lines and I'll queue them up for 3.13-rc1.
I do not know what to cleanup. Anyway, tell me if you want that I resend
the series of 2 patches with the Tested-by tag included.
I thought there was some dev_warn() changes that were asked for...
Anyway, please resend them if you want me to take them for any tree as I
no longer have them in my queue.
thanks,
greg k-h
--
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] omapdss: Add new panel driver for Topolly td028ttec1 LCD.
Signed-off-by: Marek Belisko ma...@goldelico.com
Signed-off-by: H. Nikolaus Schaller h...@goldelico.com
---
changes from v1:
- reworked to be spi driver instead platform with custom spi bitbang
this configuration was tested with spi_gpio bitbang driver on gta04 board
and works fine (thanks Tomi and Lars-Peter for comments)
- address previous comments
drivers/video/omap2/displays-new/Kconfig | 6 +
drivers/video/omap2/displays-new/Makefile | 1 +
.../omap2/displays-new/panel-tpo-td028ttec1.c | 486 +
include/video/omap-panel-data.h| 13 +
4 files changed, 506 insertions(+)
create mode 100644 drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
diff --git a/drivers/video/omap2/displays-new/Kconfig
b/drivers/video/omap2/displays-new/Kconfig
index 6c90885..1054249 100644
--- a/drivers/video/omap2/displays-new/Kconfig
+++ b/drivers/video/omap2/displays-new/Kconfig
@@ -56,6 +56,12 @@ config DISPLAY_PANEL_SHARP_LS037V7DW01
help
LCD Panel used in TI's SDP3430 and EVM boards
+config DISPLAY_PANEL_TPO_TD028TTEC1
+tristate TPO TD028TTEC1 LCD Panel
+depends on SPI
+help
+ LCD panel used in Openmoko.
+
config DISPLAY_PANEL_TPO_TD043MTEA1
tristate TPO TD043MTEA1 LCD Panel
depends on SPI
diff --git a/drivers/video/omap2/displays-new/Makefile
b/drivers/video/omap2/displays-new/Makefile
index 5aeb11b..0323a8a 100644
--- a/drivers/video/omap2/displays-new/Makefile
+++ b/drivers/video/omap2/displays-new/Makefile
@@ -8,5 +8,6 @@ obj-$(CONFIG_DISPLAY_PANEL_DSI_CM) += panel-dsi-cm.o
obj-$(CONFIG_DISPLAY_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
obj-$(CONFIG_DISPLAY_PANEL_LGPHILIPS_LB035Q02) += panel-lgphilips-lb035q02.o
obj-$(CONFIG_DISPLAY_PANEL_SHARP_LS037V7DW01) += panel-sharp-ls037v7dw01.o
+obj-$(CONFIG_DISPLAY_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
obj-$(CONFIG_DISPLAY_PANEL_TPO_TD043MTEA1) += panel-tpo-td043mtea1.o
obj-$(CONFIG_DISPLAY_PANEL_NEC_NL8048HL11) += panel-nec-nl8048hl11.o
diff --git a/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
b/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
new file mode 100644
index 000..5a44d30
--- /dev/null
+++ b/drivers/video/omap2/displays-new/panel-tpo-td028ttec1.c
@@ -0,0 +1,486 @@
+/*
+ * Toppoly TD028TTEC1 panel support
+ *
+ * Copyright (C) 2008 Nokia Corporation
+ * Author: Tomi Valkeinen tomi.valkei...@nokia.com
+ *
+ * Neo 1973 code (jbt6k74.c):
+ * Copyright (C) 2006-2007 by OpenMoko, Inc.
+ * Author: Harald Welte lafo...@openmoko.org
+ *
+ * Ported and adapted from Neo 1973 U-Boot by:
+ * H. Nikolaus Schaller h...@goldelico.com
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program. If not, see http://www.gnu.org/licenses/.
+ */
+
+#include linux/module.h
+#include linux/delay.h
+#include linux/spi/spi.h
+#include linux/gpio.h
+#include video/omapdss.h
+#include video/omap-panel-data.h
+
+struct panel_drv_data {
+ struct omap_dss_device dssdev;
+ struct omap_dss_device *in;
+
+ int data_lines;
+
+ struct omap_video_timings videomode;
+
+ struct spi_device *spi_dev;
+
+ u16 tx_buf[4];
+};
+
+static struct omap_video_timings td028ttec1_panel_timings = {
+ .x_res = 480,
+ .y_res = 640,
+ .pixel_clock= 22153,
+ .hfp= 24,
+ .hsw= 8,
+ .hbp= 8,
+ .vfp= 4,
+ .vsw= 2,
+ .vbp= 2,
+
+ .vsync_level= OMAPDSS_SIG_ACTIVE_LOW,
+ .hsync_level= OMAPDSS_SIG_ACTIVE_LOW,
+
+ .data_pclk_edge = OMAPDSS_DRIVE_SIG_FALLING_EDGE,
+ .de_level = OMAPDSS_SIG_ACTIVE_HIGH,
+ .sync_pclk_edge = OMAPDSS_DRIVE_SIG_OPPOSITE_EDGES,
+};
+
+#define JBT_COMMAND0x000
+#define JBT_DATA 0x100
+
+int jbt_reg_write_nodata(struct panel_drv_data *ddata, u8 reg)
+{
+ int rc;
+
+ ddata-tx_buf[0] = JBT_COMMAND | reg;
+ rc = spi_write(ddata-spi_dev, (u8 *)ddata-tx_buf,
+ 1*sizeof(u16));
+ if (rc != 0)
+ dev_err(ddata-spi_dev-dev,
+ jbt_reg_write_nodata spi_write ret %d\n, rc);
+
+ return rc;
+}
+
+int jbt_reg_write(struct panel_drv_data *ddata, u8 reg, u8 data)
+{
+ int rc;
+
+ ddata-tx_buf[0] = JBT_COMMAND | reg;
+ ddata-tx_buf[1] = JBT_DATA | data;
+ rc = spi_write(ddata-spi_dev, (u8
Re: [PATCH -next] misc: fix various misc/mic/host/ build errors
On Thu, Oct 17, 2013 at 04:02:25PM +0200, Thierry Reding wrote: On Wed, Oct 16, 2013 at 01:37:27PM -0700, Greg Kroah-Hartman wrote: On Wed, Oct 16, 2013 at 10:30:25PM +0200, Thierry Reding wrote: On Wed, Oct 16, 2013 at 12:44:40PM -0700, Greg Kroah-Hartman wrote: On Wed, Oct 16, 2013 at 12:41:08PM -0700, Randy Dunlap wrote: On 10/16/13 12:26, Greg Kroah-Hartman wrote: On Mon, Oct 14, 2013 at 12:38:06PM -0700, Randy Dunlap wrote: From: Randy Dunlap rdun...@infradead.org Fix various build errors (on x86_64) for drivers/misc/mic/host/: drivers/misc/mic/host/mic_main.c:378:3: error: too many arguments to function 'sysfs_get_dirent' drivers/misc/mic/host/mic_intr.h:134:58: warning: 'struct pci_dev' declared inside parameter list [enabled by default] drivers/misc/mic/host/mic_intr.h:134:58: warning: its scope is only this definition or declaration, which is probably not what you want [enabled by default] drivers/misc/mic/host/mic_intr.h:135:58: warning: 'struct pci_dev' declared inside parameter list [enabled by default] drivers/misc/mic/host/mic_device.h:169:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] drivers/misc/mic/host/mic_device.h: In function 'mic_mmio_read': drivers/misc/mic/host/mic_device.h:169:2: error: implicit declaration of function 'ioread32' [-Werror=implicit-function-declaration] drivers/misc/mic/host/mic_device.h: In function 'mic_mmio_write': drivers/misc/mic/host/mic_device.h:183:2: error: implicit declaration of function 'iowrite32' [-Werror=implicit-function-declaration] Signed-off-by: Randy Dunlap rdun...@infradead.org Cc: Harshavardhan R Kharche harshavardhan.r.khar...@intel.com Cc: Ashutosh Dixit ashutosh.di...@intel.com Cc: Greg Kroah-Hartman gre...@linuxfoundation.org Cc: Nikhil Rao nikhil@intel.com Cc: Sudeep Dutt sudeep.d...@intel.com This is a -next issue only at this point in time, I thought it was in the -next tree as a fixup already? Are you asking the driver maintainers? No, the linux-next maintainers. The driver maintainers have nothing to do with this, it's a sysfs change in my driver-core tree that causes this issue. Well, we do carry a patch to fix this, but that generally doesn't get carried to Linus' tree automatically as far as I know. So I guess it's fine for now, but when the merge window opens you'll need to make sure that Linus merges the branches in the correct order so that the build doesn't break in between. Yes, I'll do that as part of my normal tree submission process. Actually, ensuring correct merge order won't be enough, will it? That doesn't magically fixes that the function's signature actually changed. Shouldn't the update of the sysfs_get_dirent() call be fixed within the same patch that updates the sysfs_get_dirent() signature? Yes, _if_ those files are actually part of that tree, but they aren't (they got added in my staging-next tree, while these sysfs changes are in my driver-next tree.) So the trees on their own build just fine, it's only when you merge them that there is an issue. This happens all the time when apis change, nothing new here... greg k-h -- 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 2/2] ata: ahci_platform: runtime resume the device before use
Hi,
On Wednesday, October 16, 2013 02:42:53 PM Roger Quadros wrote:
On OMAP platforms the device needs to be runtime resumed before
it can be accessed. The OMAP HWMOD framework takes care of
enabling the module and its resources based on the
device's runtime PM state.
In this patch we runtime resume during .probe() and runtime suspend
during .remove() (i.e. ahci_host_stop()).
We also update the runtime PM state during .resume().
Signed-off-by: Roger Quadros rog...@ti.com
Signed-off-by: Balaji T K balaj...@ti.com
---
drivers/ata/ahci_platform.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
index 5a0f1418..0da3b95 100644
--- a/drivers/ata/ahci_platform.c
+++ b/drivers/ata/ahci_platform.c
@@ -23,6 +23,7 @@
#include linux/platform_device.h
#include linux/libata.h
#include linux/ahci_platform.h
+#include linux/pm_runtime.h
#include ahci.h
static void ahci_host_stop(struct ata_host *host);
@@ -141,6 +142,9 @@ static int ahci_probe(struct platform_device *pdev)
}
}
+ pm_runtime_enable(dev);
+ pm_runtime_get_sync(dev);
+
hpriv-phy = devm_phy_get(dev, sata-phy);
if (IS_ERR(hpriv-phy)) {
dev_dbg(dev, can't get sata-phy\n);
@@ -268,6 +272,9 @@ static void ahci_host_stop(struct ata_host *host)
clk_disable_unprepare(hpriv-clk);
clk_put(hpriv-clk);
}
+
+ pm_runtime_put_sync(dev);
+ pm_runtime_disable(dev);
It would be better to add proper .remove callback (i.e. named
ahci_remove_one) and put this code there so it matches .probe
callback.
}
#ifdef CONFIG_PM_SLEEP
@@ -339,6 +346,11 @@ static int ahci_resume(struct device *dev)
ata_host_resume(host);
+ /* We resumed so update PM runtime state */
+ pm_runtime_disable(dev);
+ pm_runtime_set_active(dev);
+ pm_runtime_enable(dev);
+
return 0;
disable_unprepare_clk:
Best regards,
--
Bartlomiej Zolnierkiewicz
Samsung RD Institute Poland
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 -next] misc: fix various misc/mic/host/ build errors
On Thu, Oct 17, 2013 at 04:02:25PM +0200, Thierry Reding wrote: On Wed, Oct 16, 2013 at 01:37:27PM -0700, Greg Kroah-Hartman wrote: Yes, I'll do that as part of my normal tree submission process. Actually, ensuring correct merge order won't be enough, will it? That doesn't magically fixes that the function's signature actually changed. Shouldn't the update of the sysfs_get_dirent() call be fixed within the same patch that updates the sysfs_get_dirent() signature? They're applied in different trees so they're both OK by themselves, it's the merge that brings the two together that needs to do the fixup. signature.asc Description: Digital signature
Re: [PATCH 1/2] efi: Add asm-generic/efi.h for non-x86
On Thu, 17 Oct, at 01:19:14PM, Matt Fleming wrote:
From: Matt Fleming matt.flem...@intel.com
From the #ifdef CONFIG_X86 in linux/efi.h it's clear we need a place to
declare functions that are implemented differently for each
architecture.
Since it's only x86 that needs to do special things, add a generic EFI
header file that can be used by everyone else and move the x86-specific
stuff to arch/x86/include/asm/efi.h.
Because the asm files are now included from linux/efi.h directly, this
change means we no longer have to include the asm file explicitly from C
files, allowing us to delete quite a few #include lines.
Cc: H. Peter Anvin h...@zytor.com
Cc: Ingo Molnar mi...@kernel.org
Cc: Thomas Gleixner t...@linutronix.de
Cc: Tony Luck tony.l...@intel.com
Cc: Leif Lindholm leif.lindh...@linaro.org
Signed-off-by: Matt Fleming matt.flem...@intel.com
---
[...]
diff --git a/include/asm-generic/efi.h b/include/asm-generic/efi.h
new file mode 100644
index 000..8a31713
--- /dev/null
+++ b/include/asm-generic/efi.h
@@ -0,0 +1,17 @@
+#ifndef _ASM_GENERIC_EFI_H
+#define _ASM_GENERIC_EFI_H
+
+static inline void efi_late_init(void) {}
+static inline void efi_free_boot_services(void) {}
+
+static inline efi_status_t efi_query_variable_store(u32 attributes, unsigned
long size)
+{
+ return EFI_SUCCESS;
+}
+
+static inline int efi_enabled(int facility)
+{
+ return IS_ENABLED(CONFIG_EFI);
+}
+
+#endif /* _ASM_GENERIC_EFI_H */
After reading Leif's arm runtime patches this patch obviously doesn't
make much sense. I'll work on something better.
--
Matt Fleming, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 15/28] dmaengine: k3dma: use DMA_COMPLETE for dma completion status
On Thu, Oct 17, 2013 at 12:28 AM, Vinod Koul vinod.k...@intel.com wrote: Signed-off-by: Vinod Koul vinod.k...@intel.com CC: Zhangfei Gao zhangfei@linaro.org Thanks Vinod Acked-by: Zhangfei Gao zhangfei@linaro.org -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] dma: cppi41: return code 0 of pm_runtime_get_sync() is not an error
Return code of pm_runtime_get_sync() 0 is not an error and may happen. Noticed during rmmod modprobe testing. Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de --- drivers/dma/cppi41.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c index 272969c..42134f9 100644 --- a/drivers/dma/cppi41.c +++ b/drivers/dma/cppi41.c @@ -957,7 +957,7 @@ static int cppi41_dma_probe(struct platform_device *pdev) pm_runtime_enable(dev); ret = pm_runtime_get_sync(dev); - if (ret) + if (ret 0) goto err_get_sync; cdd-queues_rx = glue_info-queues_rx; -- 1.8.4.rc3 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] dma: cppi41: redo descriptor collection in abort case
Most of the logic here is try and error since what actually happens does
not match the trm or I miss read it.
My first assumption was that the queue on which the tear-down descriptor
completes (their own complete queue vs active descriptor complete
queue) depends on the transfer direction. This seems not to be true
because I manage to trigger
| WARN_ON(c-desc_phys != desc_phys);
and the other few were fine means the tear-down descriptor was valid but
on different queue.
This patch changes the logic here to look on both queues for the
descriptor.
Cc: Daniel Mack zon...@gmail.com
Signed-off-by: Sebastian Andrzej Siewior bige...@linutronix.de
---
drivers/dma/cppi41.c | 41 -
1 file changed, 16 insertions(+), 25 deletions(-)
diff --git a/drivers/dma/cppi41.c b/drivers/dma/cppi41.c
index 42d1c58..272969c 100644
--- a/drivers/dma/cppi41.c
+++ b/drivers/dma/cppi41.c
@@ -563,36 +563,27 @@ static int cppi41_tear_down_chan(struct cppi41_channel *c)
c-td_retry = 100;
}
- if (!c-td_seen) {
+ if (!c-td_seen || !c-td_desc_seen) {
unsigned td_comp_queue;
- if (c-is_tx)
- td_comp_queue = cdd-td_queue.complete;
- else
- td_comp_queue = c-q_comp_num;
+ desc_phys = cppi41_pop_desc(cdd, cdd-td_queue.complete);
+ if (!desc_phys)
+ desc_phys = cppi41_pop_desc(cdd, c-q_comp_num);
- desc_phys = cppi41_pop_desc(cdd, td_comp_queue);
- if (desc_phys) {
- __iormb();
+ if (desc_phys == c-desc_phys) {
+ c-td_desc_seen = 1;
+
+ } else if (desc_phys == td_desc_phys) {
+ u32 pd0;
- if (desc_phys == td_desc_phys) {
- u32 pd0;
- pd0 = td-pd0;
- WARN_ON((pd0 DESC_TYPE) != DESC_TYPE_TEARD);
- WARN_ON(!c-is_tx !(pd0 TD_DESC_IS_RX));
- WARN_ON((pd0 0x1f) != c-port_num);
- } else {
- WARN_ON_ONCE(1);
- }
- c-td_seen = 1;
- }
- }
- if (!c-td_desc_seen) {
- desc_phys = cppi41_pop_desc(cdd, c-q_comp_num);
- if (desc_phys) {
__iormb();
- WARN_ON(c-desc_phys != desc_phys);
- c-td_desc_seen = 1;
+ pd0 = td-pd0;
+ WARN_ON((pd0 DESC_TYPE) != DESC_TYPE_TEARD);
+ WARN_ON(!c-is_tx !(pd0 TD_DESC_IS_RX));
+ WARN_ON((pd0 0x1f) != c-port_num);
+ c-td_seen = 1;
+ } else if (desc_phys) {
+ WARN_ON_ONCE(1);
}
}
c-td_retry--;
--
1.8.4.rc3
--
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 16/28] dmaengine: mmp_tdma: use DMA_COMPLETE for dma completion status
On Thu, Oct 17, 2013 at 12:28 AM, Vinod Koul vinod.k...@intel.com wrote: Signed-off-by: Vinod Koul vinod.k...@intel.com CC: Zhangfei Gao zhangfei@gmail.com Thanks Vinod Acked-by: Zhangfei Gao zhangfei@gmail.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 v2] pwm: add ep93xx PWM support
On Tue, Oct 15, 2013 at 06:40:03PM -0700, H Hartley Sweeten wrote: Remove the non-standard EP93xx PWM driver in drivers/misc and add a new driver for the PWM controllers on the EP93xx platform based on the PWM framework. These PWM controllers each support 1 PWM channel with programmable duty cycle, frequency, and polarity inversion. Signed-off-by: H Hartley Sweeten hswee...@visionengravers.com Cc: Ryan Mallon rmal...@gmail.com Cc: Thierry Reding thierry.red...@gmail.com Cc: Arnd Bergmann a...@arndb.de Cc: Greg Kroah-Hartman gre...@linuxfoundation.org --- v2: address issues pointed out by Thierry Reding. drivers/misc/Kconfig | 13 --- drivers/misc/Makefile | 1 - drivers/misc/ep93xx_pwm.c | 286 -- drivers/pwm/Kconfig | 9 ++ drivers/pwm/Makefile | 1 + drivers/pwm/pwm-ep93xx.c | 230 + 6 files changed, 240 insertions(+), 300 deletions(-) delete mode 100644 drivers/misc/ep93xx_pwm.c create mode 100644 drivers/pwm/pwm-ep93xx.c Applied, thanks. Thierry pgp3yvMzpqGxP.pgp Description: PGP signature
Re: [PATCH 1/2] dma: cppi41: redo descriptor collection in abort case
On 10/17/2013 04:19 PM, Sebastian Andrzej Siewior wrote: This patch changes the logic here to look on both queues for the descriptor. Daniel, could please look if this solves your suspend / resume warnings? Sebastian -- 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/
[char-misc] mei: move host_clients_map cleanup to device init
From: Alexander Usyskin alexander.usys...@intel.com
Move host_clients_map cleanup from host client init to device init.
This fixes bug where we cleaned up the bitmask that servers as pool for
host client ids while file descriptors are kept open during suspend.
On resume a new connection will be assigned id that is already taken
by opened file descriptor. Consequently read/write will fail due to
mismatched book keeping.
Signed-off-by: Alexander Usyskin alexander.usys...@intel.com
Signed-off-by: Tomas Winkler tomas.wink...@intel.com
---
drivers/misc/mei/client.c | 9 -
drivers/misc/mei/init.c | 8
2 files changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/misc/mei/client.c b/drivers/misc/mei/client.c
index a48c0e7..0ccc22c 100644
--- a/drivers/misc/mei/client.c
+++ b/drivers/misc/mei/client.c
@@ -365,15 +365,6 @@ void mei_host_client_init(struct work_struct *work)
mutex_lock(dev-device_lock);
- bitmap_zero(dev-host_clients_map, MEI_CLIENTS_MAX);
- dev-open_handle_count = 0;
-
- /*
-* Reserving the first three client IDs
-* 0: Reserved for MEI Bus Message communications
-*/
- bitmap_set(dev-host_clients_map, 0, 1);
-
for (i = 0; i dev-me_clients_num; i++) {
client_props = dev-me_clients[i].props;
diff --git a/drivers/misc/mei/init.c b/drivers/misc/mei/init.c
index bcb4a6b..4c93e3d 100644
--- a/drivers/misc/mei/init.c
+++ b/drivers/misc/mei/init.c
@@ -68,6 +68,14 @@ void mei_device_init(struct mei_device *dev)
mei_io_list_init(dev-amthif_cmd_list);
mei_io_list_init(dev-amthif_rd_complete_list);
+ bitmap_zero(dev-host_clients_map, MEI_CLIENTS_MAX);
+ dev-open_handle_count = 0;
+
+ /*
+* Reserving the first client ID
+* 0: Reserved for MEI Bus Message communications
+*/
+ bitmap_set(dev-host_clients_map, 0, 1);
}
EXPORT_SYMBOL_GPL(mei_device_init);
--
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 1/2] dma: cppi41: redo descriptor collection in abort case
On 10/17/2013 04:20 PM, Sebastian Andrzej Siewior wrote: On 10/17/2013 04:19 PM, Sebastian Andrzej Siewior wrote: This patch changes the logic here to look on both queues for the descriptor. Daniel, could please look if this solves your suspend / resume warnings? Will do (hopefully) tomorrow. So this is a replacement for my dma: cppi41: move -EAGAIN in tear_down patch, or does it go on top of it? How does your patch queue look like? Someone should probably re-collect all necessary patches for the next merge window eventually, so Vinod knows what to apply :) Thanks, Daniel -- 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 -next] misc: fix various misc/mic/host/ build errors
On Thu, Oct 17, 2013 at 03:16:29PM +0100, Mark Brown wrote: On Thu, Oct 17, 2013 at 04:02:25PM +0200, Thierry Reding wrote: On Wed, Oct 16, 2013 at 01:37:27PM -0700, Greg Kroah-Hartman wrote: Yes, I'll do that as part of my normal tree submission process. Actually, ensuring correct merge order won't be enough, will it? That doesn't magically fixes that the function's signature actually changed. Shouldn't the update of the sysfs_get_dirent() call be fixed within the same patch that updates the sysfs_get_dirent() signature? They're applied in different trees so they're both OK by themselves, it's the merge that brings the two together that needs to do the fixup. Right, as long as the person doing that merge remembers to do that. It sounds like the thing that could easily be forgotten. But Linus has been doing this for a long time, so I'm sure he'll know what to look for. I'm curious though, are maintainers supposed to mention it when sending pull requests with such a dependency? Thierry pgpHAUDaq7V6v.pgp Description: PGP signature
Re: [BUG 3.12.rc4] Oops: unable to handle kernel paging request during shutdown
On Tue, Oct 15, 2013 at 08:40:25AM +0200, Ingo Molnar wrote: * Frederic Weisbecker fweis...@gmail.com wrote: I've been thinking that CONFIG_DEBUG_LIST could help. Unfortunately it's good to spot list APIs misuse but, if Linus is right, the problem may be that the list belongs to an object that has been freed, and I believe that won't detect such a thing. Use-after free should be reliably detectable via CONFIG_DEBUG_PAGEALLOC=y. A couple of years ago I wrote a list debugging beast that would catch use-after-free mishaps (sent it to lkml too IIRC), but it was a bit complex and I never found the time to nurse it upstream. Ok, well CONFIG_DEBUG_PAGEALLOC=y should work for list as for anything, right? Thanks. Thanks, Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/4] Exynos 5410 Dual cluster support
hi Tarek; skip However there seem to be some issues with virq allocations, like this: snippet Starting kernel ... [0.00] [c0014d48] (unwind_backtrace+0x0/0xf8) from [c00117d0] (show_stack+0x10/0x14) [0.00] [c00117d0] (show_stack+0x10/0x14) from [c0363488] (dump_stack+0x6c/0xac) [0.00] [c0363488] (dump_stack+0x6c/0xac) from [c001e330] (warn_slowpath_common+0x64/0x88) [0.00] [c001e330] (warn_slowpath_common+0x64/0x88) from [c001e3e8] (warn_slowpath_fmt+0x30/0x40) [0.00] [c001e3e8] (warn_slowpath_fmt+0x30/0x40) from [c005a1b4] (irq_domain_associate+0x128/0x1a8) [0.00] [c005a1b4] (irq_domain_associate+0x128/0x1a8) from [c005a508] (irq_domain_associate_many+0x30/0x3c ) [0.00] [c005a508] (irq_domain_associate_many+0x30/0x3c) from [c005a768] (irq_domain_add_simple+0x78/0x90) [0.00] [c005a768] (irq_domain_add_simple+0x78/0x90) from [c04b044c] (combiner_of_init+0xb4/0x198) [0.00] [c04b044c] (combiner_of_init+0xb4/0x198) from [c04b6938] (of_irq_init+0x278/0x2a0) [0.00] [c04b6938] (of_irq_init+0x278/0x2a0) from [c049b8fc] (start_kernel+0x18c/0x384) [0.00] [c049b8fc] (start_kernel+0x18c/0x384) from [40008074] (0x40008074) [0.00] ---[ end trace 1b75b31a2719edcd ]--- [0.00] [ cut here ] [0.00] WARNING: CPU: 0 PID: 0 at kernel/irq/irqdomain.c:278 irq_domain_associate+0x128/0x1a8() [0.00] error: virq337 is not allocated [0.00] Modules linked in: [0.00] CPU: 0 PID: 0 Comm: swapper/0 Tainted: GW 3.12.0-rc5-4-g1cb405f #1 [0.00] [c0014d48] (unwind_backtrace+0x0/0xf8) from [c00117d0] (show_stack+0x10/0x14) [0.00] [c00117d0] (show_stack+0x10/0x14) from [c0363488] (dump_stack+0x6c/0xac) [0.00] [c0363488] (dump_stack+0x6c/0xac) from [c001e330] (warn_slowpath_common+0x64/0x88) [0.00] [c001e330] (warn_slowpath_common+0x64/0x88) from [c001e3e8] (warn_slowpath_fmt+0x30/0x40) [0.00] [c001e3e8] (warn_slowpath_fmt+0x30/0x40) from [c005a1b4] (irq_domain_associate+0x128/0x1a8) [0.00] [c005a1b4] (irq_domain_associate+0x128/0x1a8) from [c005a508] (irq_domain_associate_many+0x30/0x3c ) [0.00] [c005a508] (irq_domain_associate_many+0x30/0x3c) from [c005a768] (irq_domain_add_simple+0x78/0x90) [0.00] [c005a768] (irq_domain_add_simple+0x78/0x90) from [c04b044c] (combiner_of_init+0xb4/0x198) [0.00] [c04b044c] (combiner_of_init+0xb4/0x198) from [c04b6938] (of_irq_init+0x278/0x2a0) [0.00] [c04b6938] (of_irq_init+0x278/0x2a0) from [c049b8fc] (start_kernel+0x18c/0x384) [0.00] [c049b8fc] (start_kernel+0x18c/0x384) from [40008074] (0x40008074) [0.00] ---[ end trace 1b75b31a2719edce ]--- [0.00] [ cut here ] /snippet This will be fixed in 3.13. Now you can just change irq_base = 160 to irq_base = 256 in static int __init combiner_of_init(struct device_node *np, struct device_node *parent) function in drivers/irqchip/exynos-combiner.c Thanks, this works for me! -- Aliaksei Best regards, Tarek Dakhran -- 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 01/28] dmaengine: use DMA_COMPLETE for dma completion status
On Thu, Oct 17, 2013 at 07:37:45AM +0530, Vinod Koul wrote:
index 0bc7275..683c380 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -45,16 +45,17 @@ static inline int dma_submit_error(dma_cookie_t cookie)
/**
* enum dma_status - DMA transaction status
- * @DMA_SUCCESS: transaction completed successfully
+ * @DMA_COMPLETE: transaction completed
* @DMA_IN_PROGRESS: transaction not yet processed
* @DMA_PAUSED: transaction is paused
* @DMA_ERROR: transaction failed
*/
enum dma_status {
- DMA_SUCCESS,
+ DMA_COMPLETE,
DMA_IN_PROGRESS,
DMA_PAUSED,
DMA_ERROR,
+ DMA_SUCCESS,
};
There are some drivers which compare against == or != DMA_SUCCESS. Shouldn't
this
become
enum dma_status {
- DMA_SUCCESS,
+ DMA_COMPLETE = 0, DMA_SUCCESS = 0,
DMA_IN_PROGRESS,
DMA_PAUSED,
DMA_ERROR,
};
so nothing breaks during the transition?
Sebastian
--
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] perf: disable PERF_RECORD_MMAP2 support
For now, we disable the extended MMAP record support (MMAP2).
We have identified cases where it would not report the correct
mapping information, clone(VM_CLONE) but with separate pids.
We will revisit the support once we find a solution for this case.
The patch changes the kernel to return EINVAL if attr-mmap2
is set. The patch also modifies the perf tool to use regular PERF_RECORD_MMAP
for synthetic events and it also prevents the tool from requesting attr-mmap2
mode because the kernel would reject it.
The support will be revisited once the kenrel interface is updated.
In V2, we reduce the patch to the strict minimum.
Signed-off-by: Stephane Eranian eran...@google.com
---
kernel/events/core.c|4
tools/perf/util/event.c | 30 +-
2 files changed, 17 insertions(+), 17 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index c716385..5bd7fe4 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -6773,6 +6773,10 @@ static int perf_copy_attr(struct perf_event_attr __user
*uattr,
if (ret)
return -EFAULT;
+ /* disabled for now */
+ if (attr-mmap2)
+ return -EINVAL;
+
if (attr-__reserved_1)
return -EINVAL;
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index 9b393e7..63df031 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -187,7 +187,7 @@ static int perf_event__synthesize_mmap_events(struct
perf_tool *tool,
return -1;
}
- event-header.type = PERF_RECORD_MMAP2;
+ event-header.type = PERF_RECORD_MMAP;
/*
* Just like the kernel, see __perf_event_mmap in kernel/perf_event.c
*/
@@ -198,7 +198,6 @@ static int perf_event__synthesize_mmap_events(struct
perf_tool *tool,
char prot[5];
char execname[PATH_MAX];
char anonstr[] = //anon;
- unsigned int ino;
size_t size;
ssize_t n;
@@ -209,13 +208,10 @@ static int perf_event__synthesize_mmap_events(struct
perf_tool *tool,
strcpy(execname, );
/* 0040-0040c000 r-xp fd:01 41038 /bin/cat */
- n = sscanf(bf, %PRIx64-%PRIx64 %s %PRIx64 %x:%x %u %s\n,
- event-mmap2.start, event-mmap2.len, prot,
- event-mmap2.pgoff, event-mmap2.maj,
- event-mmap2.min,
- ino, execname);
-
- event-mmap2.ino = (u64)ino;
+ n = sscanf(bf, %PRIx64-%PRIx64 %s %PRIx64 %*x:%*x %*u
%s\n,
+ event-mmap.start, event-mmap.len, prot,
+ event-mmap.pgoff,
+ execname);
if (n != 8)
continue;
@@ -227,15 +223,15 @@ static int perf_event__synthesize_mmap_events(struct
perf_tool *tool,
strcpy(execname, anonstr);
size = strlen(execname) + 1;
- memcpy(event-mmap2.filename, execname, size);
+ memcpy(event-mmap.filename, execname, size);
size = PERF_ALIGN(size, sizeof(u64));
- event-mmap2.len -= event-mmap.start;
- event-mmap2.header.size = (sizeof(event-mmap2) -
- (sizeof(event-mmap2.filename) - size));
- memset(event-mmap2.filename + size, 0, machine-id_hdr_size);
- event-mmap2.header.size += machine-id_hdr_size;
- event-mmap2.pid = tgid;
- event-mmap2.tid = pid;
+ event-mmap.len -= event-mmap.start;
+ event-mmap.header.size = (sizeof(event-mmap) -
+ (sizeof(event-mmap.filename) - size));
+ memset(event-mmap.filename + size, 0, machine-id_hdr_size);
+ event-mmap.header.size += machine-id_hdr_size;
+ event-mmap.pid = tgid;
+ event-mmap.tid = pid;
if (process(tool, event, synth_sample, machine) != 0) {
rc = -1;
--
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 v3] efivars,efi-pstore: Hold off deletion of sysfs entry until, the scan is completed
Oops, It seems my mu4e(a email client for emacs)'s auto-indent breaks the patch... I apologize for this... seiji.agu...@hds.com writes: Hi Madper, I tested this patch on 3.12-rc4. Could you please send me the log when you failed to apply? Seiji -Original Message- From: Madper Xie [mailto:c...@redhat.com] Sent: Thursday, October 17, 2013 1:54 AM To: Seiji Aguchi Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; matt.flem...@intel.com; tony.l...@intel.com; Tomoki Sekiyama; dle- deve...@lists.sourceforge.net Subject: Re: [PATCH v3] efivars,efi-pstore: Hold off deletion of sysfs entry until, the scan is completed Howdy Seiji, I failed appily this patch to both 3.12-rc2 and 3.12-rc4. Could you please let me know which is the right tree for this patch? Thanks, Madper. seiji.agu...@hds.com writes: Change from v2: - Move dynamic memory allocation to efi_pstore_read() before holding efivars-lock to protect entry-var.Data. - Access to entry-scanning while holding efivars-lock. - Move a comment about a returned value from efi_pstore_read_func() to efi_pstore_read() because size 0 case may happen in efi_pstore_read(). Currently, when mounting pstore file system, a read callback of efi_pstore driver runs mutiple times as below. - In the first read callback, scan efivar_sysfs_list from head and pass a kmsg buffer of a entry to an upper pstore layer. - In the second read callback, rescan efivar_sysfs_list from the entry and pass another kmsg buffer to it. - Repeat the scan and pass until the end of efivar_sysfs_list. In this process, an entry is read across the multiple read function calls. To avoid race between the read and erasion, the whole process above is protected by a spinlock, holding in open() and releasing in close(). At the same time, kmemdup() is called to pass the buffer to pstore filesystem during it. And then, it causes a following lockdep warning. To make the dynamic memory allocation runnable without taking spinlock, holding off a deletion of sysfs entry if it happens while scanning it via efi_pstore, and deleting it after the scan is completed. To implement it, this patch introduces two flags, scanning and deleting, to efivar_entry. [1.143710] [ cut here ] [1.144058] WARNING: CPU: 1 PID: 1 at kernel/lockdep.c:2740 lockdep_trace_alloc+0x104/0x110() [1.144058] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) [1.144058] Modules linked in: [1.144058] CPU: 1 PID: 1 Comm: systemd Not tainted 3.11.0-rc5 #2 [1.144058] 0009 8800797e9ae0 816614a5 8800797e9b28 [1.144058] 8800797e9b18 8105510d 0080 0046 [1.144058] 00d0 03af 81ccd0c0 8800797e9b78 [1.144058] Call Trace: [1.144058] [816614a5] dump_stack+0x54/0x74 [1.144058] [8105510d] warn_slowpath_common+0x7d/0xa0 [1.144058] [8105517c] warn_slowpath_fmt+0x4c/0x50 [1.144058] [8131290f] ? vsscanf+0x57f/0x7b0 [1.144058] [810bbd74] lockdep_trace_alloc+0x104/0x110 [1.144058] [81192da0] __kmalloc_track_caller+0x50/0x280 [1.144058] [815147bb] ? efi_pstore_read_func.part.1+0x12b/0x170 [1.144058] [8115b260] kmemdup+0x20/0x50 [1.144058] [815147bb] efi_pstore_read_func.part.1+0x12b/0x170 [1.144058] [81514800] ? efi_pstore_read_func.part.1+0x170/0x170 [1.144058] [815148b4] efi_pstore_read_func+0xb4/0xe0 [1.144058] [81512b7b] __efivar_entry_iter+0xfb/0x120 [1.144058] [8151428f] efi_pstore_read+0x3f/0x50 [1.144058] [8128d7ba] pstore_get_records+0x9a/0x150 [1.158207] [812af25c] ? selinux_d_instantiate+0x1c/0x20 [1.158207] [8128ce30] ? parse_options+0x80/0x80 [1.158207] [8128ced5] pstore_fill_super+0xa5/0xc0 [1.158207] [811ae7d2] mount_single+0xa2/0xd0 [1.158207] [8128ccf8] pstore_mount+0x18/0x20 [1.158207] [811ae8b9] mount_fs+0x39/0x1b0 [1.158207] [81160550] ? __alloc_percpu+0x10/0x20 [1.158207] [811c9493] vfs_kern_mount+0x63/0xf0 [1.158207] [811cbb0e] do_mount+0x23e/0xa20 [1.158207] [8115b51b] ? strndup_user+0x4b/0xf0 [1.158207] [811cc373] SyS_mount+0x83/0xc0 [1.158207] [81673cc2] system_call_fastpath+0x16/0x1b [1.158207] ---[ end trace 61981bc62de9f6f4 ]--- Signed-off-by: Seiji Aguchi seiji.agu...@hds.com --- drivers/firmware/efi/efi-pstore.c | 143 +++--- drivers/firmware/efi/efivars.c| 12 ++-- drivers/firmware/efi/vars.c | 12 +++- include/linux/efi.h | 2 + 4 files changed, 153
Re: [PATCH v2] xhci: fix usb3 streams
On Wed, 16 Oct 2013, Sarah Sharp wrote: xhci maintains a radix tree for each stream endpoint because it must be able to map a trb address to the stream ring. Each ring segment must be added to the ring for this to work. Currently xhci sticks only the first segment of each stream ring into the radix tree. There may be a simpler approach to this problem. When using a new ring segment, keep the first TRB entry in reserve. Don't put a normal TRB in there, instead leave it as a no-op entry containing a pointer to the stream ring. (Make the prior Link TRB point to the second entry in the new segment instead of the first.) Then you won't have to add to or remove anything from the radix tree. I don't understand how this would help. Are you advocating a different way of mapping TRB DMA addresses to stream rings that would allow us to ditch the radix tree all together? Ok, so with your solution, we have a virtual stream ring pointer as the first TRB of the segment. We get an event with the DMA address of a TRB in one of many stream rings on an endpoint. From that, I think we can infer the DMA address of the first TRB on the segment, due to the alignment requirements and ring size. And then what do we do with that? We don't have the virtual address of that first TRB, so the xHCI driver can't read the ring pointer from it. I'm confused as to what the next steps would be to solve this. My mistake; I misunderstood the original description of the problem. I didn't realize that map a trb address referred to the TRB's DMA address. BTW, ohci-hcd faces the same problem (of mapping DMA addresses to kernel addresses). It solves the problem with a hash table rather than a radix tree. Alan Stern -- 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 2/3] arm: Add [U]EFI runtime services support
On Thu, Oct 17, 2013 at 03:07:39PM +0100, Matt Fleming wrote:
+/*
+ * If you need to (temporarily) support buggy firmware.
+ */
+#define KEEP_BOOT_SERVICES_REGIONS
Have you seen firmware that requires this? I'm just curious more than
anything else.
Not really.
I _think_ I saw it on a debug build of a development platform once.
That coincided with me seeing a post on linux-efi about some laptop
that broke unless boot services regions were preserved, so I decided
to put it in there for any future debugging.
+/*
+ * Returns 1 if 'facility' is enabled, 0 otherwise.
+ */
+int efi_enabled(int facility)
+{
+ return test_bit(facility, arm_efi_facility) != 0;
+}
+EXPORT_SYMBOL(efi_enabled);
This should move to drivers/firmware/efi/efi.c. Let me write a patch
that moves the x86 stuff out of arch/x86 and means you can get rid of
this hunk.
Excellent, thanks!
+/*
+ * Called explicitly from init/mm.c
+ */
That's init/main.c.
*cough*, right.
+void __init efi_enter_virtual_mode(void)
+{
+ efi_status_t status;
+
+ if (!efi_enabled(EFI_BOOT)) {
+ pr_info(EFI services will not be available.\n);
+ return;
This is dead code as PATCH 3 does,
diff --git a/init/main.c b/init/main.c
index af310af..ec6d76e 100644
--- a/init/main.c
+++ b/init/main.c
@@ -875,6 +875,10 @@ static noinline void __init
kernel_init_freeable(void)
smp_prepare_cpus(setup_max_cpus);
do_pre_smp_initcalls();
+
+ if (IS_ENABLED(CONFIG_ARM) efi_enabled(EFI_BOOT))
+ efi_enter_virtual_mode();
+
True.
However, this call site is likely to change in the future (preferably
to an early_initcall), if we redesign the memory mapping to be reusable
after kexec(). At which point the test in efi_enter_virtual_mode() will
make sense again.
Could I change the test in init/main.c to do
if (IS_ENABLED(CONFIG_ARM) IS_ENABLED(CONFIG_EFI))
instead?
/
Leif
--
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 3/4] ARM: EXYNOS: add Exynos Dual Cluster Support
On Thu, Oct 17, 2013 at 12:45:29PM +0200, Daniel Lezcano wrote:
On 10/14/2013 05:08 PM, Vyacheslav Tyrtov wrote:
From: Tarek Dakhran t.dakh...@samsung.com
Add EDCS(Exynos Dual Cluster Support) for Samsung Exynos5410 SoC.
This enables all 8 cores, 4 x A7 and 4 x A15 run at the same time.
[...]
+ __mcpm_cpu_down(cpu, cluster);
+
+ if (!skip_wfi) {
+ exynos_core_power_down(cpu, cluster);
+ wfi();
+ }
+}
I did not looked line by line but these functions looks very similar
than the tc2_pm.c's function. no ?
This is true.
May be some code consolidation could be considered here.
Added Nico and Lorenzo in Cc.
Thanks
-- Daniel
Nico can commnent further, but I think the main concern here was that
this code shouldn't be factored prematurely.
There are many low-level platform specifics involved here, so it's
hard to be certain that all platforms could fit into a more abstracted
framework until we have some evidence to look at.
This could be revisited when we have a few diverse MCPM ports to
compare.
The low-level A15/A7 cacheflush sequence is already being factored
by Nico [1].
Cheers
---Dave
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-October/205085.html
[PATCH] ARM: cacheflush: consolidate single-CPU ARMv7 cache disabling code
[...]
--
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/2] dma: cppi41: redo descriptor collection in abort case
On 10/17/2013 04:23 PM, Daniel Mack wrote: Daniel, could please look if this solves your suspend / resume warnings? Will do (hopefully) tomorrow. So this is a replacement for my dma: cppi41: move -EAGAIN in tear_down patch, or does it go on top of it? I applied your three patches and manage to break 2 of 4 tests I had. It was still the same without your patch. So I made this change and merged it back into your patch so this patch should apply ontop of your 2/3. How does your patch queue look like? Someone should probably re-collect all necessary patches for the next merge window eventually, so Vinod knows what to apply :) dma: cppi41: add support for suspend and resume dma: cppi41: restore more registers dma: cppi41: use cppi41_pop_desc() where possible dma: cppi41: redo descriptor collection in abort case dma: cppi41: return code 0 of pm_runtime_get_sync() is not an error The first one is in Vinod's tree. Thanks, Daniel Sebastian -- 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 v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 17/10/13 15:19, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 10:33 Thu 17 Oct , srinivas kandagatla wrote:
On 17/10/13 08:27, Maxime COQUELIN wrote:
...
+
+static struct of_device_id st_i2c_match[] = {
+ { .compatible = st,comms-ssc-i2c, },
the rules is to put the first soc that use the ip in the compatible
as st,sti7100-scc-i2c
Ok. There are no plans to upstream the SH4 platforms, it will only
remains in stlinux.com.
Maybe I can set the first ARM platform (STiH415)?
That would give st,stih415-ssc-i2c.
NAK, for st,stih415-ssc-i2c naming.
IMO, this makes sense when the same IP integration done on different SOC
changes slightly/very differently.
But in this case the comms IP remains unchanged across all the SOCs.
I would still prefer st,comms-ssc-i2c, allowing a single device driver
to match against several SoCs. ST comms IP it is integrated across all
the STi series of SoCs, so we don't want to add new entry in compatible
for every new SOC.
you never need this you always the first SoC that's all
Sorry to ask this but, Where is this requirement coming from?
I have not spotted any thing as such in ePAPR specs.
All the spec says is.
===
The compatible property value consists of one or more strings that
define the specific programming model for the device. This list of
strings should be used by a client program for device driver selection.
The property value consists of a concatenated list of null terminated
strings, *from most specific to most general.* They allow a device to
express its compatibility with a family of similar devices, potentially
allowing a single device driver to match against several devices.
The recommended format is “manufacturer,model”, where manufacturer is a
string describing the name of the manufacturer (such as an OUI), and
model specifies the model number.
Example:
compatible = “fsl,mpc8641-uart”, “ns16550;
In this example, an operating system would first try to locate a device
driver that supported fsl,mpc8641-uart. If a driver was not found, it
would then try to locate a driver that supported the more general
ns16550 device type.
===
The more general compatible string in this case is st,comms-ssc-i2c,
rather than the first soc name.
How can a first SOC name be more general?
As this driver is not very specific to StiH415, it is generic driver for
ST comms-ssc-i2c block.
Thanks,
srini
see other bindings on at91 as example sorry NACK
Best Regards,
J.
Thanks,
srini
Thanks for the review,
Maxime
--
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 01/28] dmaengine: use DMA_COMPLETE for dma completion status
Hi Sebastian
On Thu, 17 Oct 2013, Sebastian Andrzej Siewior wrote:
On Thu, Oct 17, 2013 at 07:37:45AM +0530, Vinod Koul wrote:
index 0bc7275..683c380 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -45,16 +45,17 @@ static inline int dma_submit_error(dma_cookie_t cookie)
/**
* enum dma_status - DMA transaction status
- * @DMA_SUCCESS: transaction completed successfully
+ * @DMA_COMPLETE: transaction completed
* @DMA_IN_PROGRESS: transaction not yet processed
* @DMA_PAUSED: transaction is paused
* @DMA_ERROR: transaction failed
*/
enum dma_status {
- DMA_SUCCESS,
+ DMA_COMPLETE,
DMA_IN_PROGRESS,
DMA_PAUSED,
DMA_ERROR,
+ DMA_SUCCESS,
};
There are some drivers which compare against == or != DMA_SUCCESS. Shouldn't
this
become
enum dma_status {
-DMA_SUCCESS,
+DMA_COMPLETE = 0, DMA_SUCCESS = 0,
DMA_IN_PROGRESS,
DMA_PAUSED,
DMA_ERROR,
};
so nothing breaks during the transition?
Good catch. I would do
enum dma_status {
- DMA_SUCCESS,
+ DMA_COMPLETE,
DMA_IN_PROGRESS,
DMA_PAUSED,
DMA_ERROR,
};
+ #define DMA_SUCCESS DMA_COMPLETE
and then just remove the last line again
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.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 v3 6/7] arm64, jump label: optimize jump label implementation
On 10/17/2013 05:39 PM, Will Deacon wrote:
On Wed, Oct 16, 2013 at 06:11:45PM +0100, Jiang Liu wrote:
On 10/16/2013 07:46 PM, Will Deacon wrote:
+ } else {
+ insn = aarch64_insn_gen_nop();
You could make the code more concise by limiting your patching ability to
branch immediates. Then a nop is simply a branch to the next instruction (I
doubt any modern CPUs will choke on this, whereas the architecture requires
a NOP to take time).
I guess a NOP should be more effecient than a B #4 on real CPUs:)
Well, I was actually questioning that. A NOP *has* to take time (the
architecture prevents implementations from discaring it) whereas a static,
unconditional branch will likely be discarded early on by CPUs with even
simple branch prediction logic.
I naively thought NOP is cheaper than a B :(
Will use a B #1 to replace NOP.
Thanks!
Gerry
Will
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND][PATCH] of: add vendor prefix for PHYTEC Messtechnik GmbH
On Thu, Oct 17, 2013 at 7:09 AM, Matt Porter matt.por...@linaro.org wrote: Adds PHYTEC to the list of DT vendor prefixes. Signed-off-by: Matt Porter matt.por...@linaro.org --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) Applied. Rob diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 2956800..ddcd322 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -45,6 +45,7 @@ nintendo Nintendo nvidia NVIDIA nxpNXP Semiconductors onnn ON Semiconductor Corp. +phytec PHYTEC Messtechnik GmbH picochip Picochip Ltd powervrPowerVR (deprecated, use img) qcaQualcomm Atheros, Inc. -- 1.8.4 -- To unsubscribe from this list: send the line unsubscribe devicetree in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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 01/28] dmaengine: use DMA_COMPLETE for dma completion status
On Thu, Oct 17, 2013 at 04:27:55PM +0200, Sebastian Andrzej Siewior wrote:
On Thu, Oct 17, 2013 at 07:37:45AM +0530, Vinod Koul wrote:
index 0bc7275..683c380 100644
--- a/include/linux/dmaengine.h
+++ b/include/linux/dmaengine.h
@@ -45,16 +45,17 @@ static inline int dma_submit_error(dma_cookie_t cookie)
/**
* enum dma_status - DMA transaction status
- * @DMA_SUCCESS: transaction completed successfully
+ * @DMA_COMPLETE: transaction completed
* @DMA_IN_PROGRESS: transaction not yet processed
* @DMA_PAUSED: transaction is paused
* @DMA_ERROR: transaction failed
*/
enum dma_status {
- DMA_SUCCESS,
+ DMA_COMPLETE,
DMA_IN_PROGRESS,
DMA_PAUSED,
DMA_ERROR,
+ DMA_SUCCESS,
};
There are some drivers which compare against == or != DMA_SUCCESS. Shouldn't
this
become
enum dma_status {
-DMA_SUCCESS,
+DMA_COMPLETE = 0, DMA_SUCCESS = 0,
DMA_IN_PROGRESS,
DMA_PAUSED,
DMA_ERROR,
};
so nothing breaks during the transition?
Yes i missed it in first place update the patch to fix that
~Vinod
--
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/
Backlight enabled by default
While working on integrating backlight functionality with the DRM sub- system, I came across an oddity of sorts. The backlight subsystem seems to have an implicit policy of enabling the backlight device when it's registered. Pretty much every driver seems to do something like this in .probe(): bl-props.brightness = default_brightness; bl-props.fb_blank = FB_BLANK_UNBLANK; backlight_update_status(bl); There are variations of this theme, but the tendency is certainly to enable the backlight once it has been registered. Some don't even set the .fb_blank field, so it will usually stay initialized to zero, which happens to be FB_BLANK_UNBLANK, so the result will be the same. I understand that this is actually useful when using something such as fbdev where the backlight isn't necessarily bound to a display device, but when used in conjunction with a higher-level API such as DRM, then this default behaviour becomes somewhat annoying. The problem is that backlight devices are usually instantiated separately from the display driver, so with the current default the backlight will be enabled at some random point in time during boot. However, DRM for example provides for a display to control very precisely when the backlight should be enabled, which in turn makes it easy to light it up right after the display has initialized. If the backlight is turned on right after it has been probed this could mean that the display hasn't been initialized yet and therefore there's no meaningful content yet, and worse, the display might show garbage during initialization of the display controller. So I wonder if perhaps a better default would be to not enable the backlight on boot. If so, this will actually cause a regression of some sort on non-DRM systems because suddenly the backlight is no longer enabled by default on boot. Does anyone have any comments or ideas? My first reaction was to add a property to the DT so that the driver could skip enabling the backlight, but I don't think that will be accepted because it encodes software policy in DT rather than purely a description of hardware. Thierry pgpENm5fFW6pn.pgp Description: PGP signature
Re: [PATCH -next] misc: fix various misc/mic/host/ build errors
On Thu, Oct 17, 2013 at 04:21:39PM +0200, Thierry Reding wrote: On Thu, Oct 17, 2013 at 03:16:29PM +0100, Mark Brown wrote: On Thu, Oct 17, 2013 at 04:02:25PM +0200, Thierry Reding wrote: On Wed, Oct 16, 2013 at 01:37:27PM -0700, Greg Kroah-Hartman wrote: Yes, I'll do that as part of my normal tree submission process. Actually, ensuring correct merge order won't be enough, will it? That doesn't magically fixes that the function's signature actually changed. Shouldn't the update of the sysfs_get_dirent() call be fixed within the same patch that updates the sysfs_get_dirent() signature? They're applied in different trees so they're both OK by themselves, it's the merge that brings the two together that needs to do the fixup. Right, as long as the person doing that merge remembers to do that. It sounds like the thing that could easily be forgotten. But Linus has been doing this for a long time, so I'm sure he'll know what to look for. I'm curious though, are maintainers supposed to mention it when sending pull requests with such a dependency? Sometimes, if we remember, we do, sometimes we don't :) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/9] Extended H/W error log driver
On Wed, Oct 16, 2013 at 08:11:17PM +0200, Borislav Petkov wrote: Date: Wed, 16 Oct 2013 20:11:17 +0200 From: Borislav Petkov b...@alien8.de To: Steven Rostedt rost...@goodmis.org, Chen, Gong gong.c...@linux.intel.com Cc: tony.l...@intel.com, j...@perches.com, naveen.n@linux.vnet.ibm.com, aroza...@redhat.com, linux-a...@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v2 0/9] Extended H/W error log driver User-Agent: Mutt/1.5.21 (2010-09-15) On Wed, Oct 16, 2013 at 08:00:38PM +0200, Borislav Petkov wrote: Right, the only difference I can see is that include/ras/ras_event.h doesn't have those below: #undef TRACE_INCLUDE_PATH #undef TRACE_INCLUDE_FILE #define TRACE_INCLUDE_PATH . Perhaps that is the problem? Gong, what is exactly the issue you're observing? Ok, I think I know what the issue is: Gong has diff --git a/drivers/acpi/extlog_trace.c b/drivers/acpi/extlog_trace.c new file mode 100644 index ..28640807fb09 --- /dev/null +++ b/drivers/acpi/extlog_trace.c @@ -0,0 +1,107 @@ +#include linux/export.h +#include linux/dmi.h +#include extlog_trace.h + +#define CREATE_TRACE_POINTS +#define TRACE_INCLUDE_PATH ../../include/ras +#include ras/ras_event.h for the ras tracepoint although this is done already in drivers/edac/edac_mc.c Sorry I don't express clearly enough. The patch [v2 9/9] in this patch seris can work well. The bogus one is in myself reply for patch [v2 0/9]. In this patch series I keep trace interface always builtin, so it can work for module builtin, whether CREATE_TRACE_POINTS is defined multi-times or not. The weird thing for bogus patch is if it is compiled as a module, I can find the trace_xxx function is called definitely and paramerters are expected but nothing output via trace interface, just like below: # tracer: nop # # entries-in-buffer/entries-written: 0/0 #P:120 # # _-= irqs-off # / _= need-resched #| / _---= hardirq/softirq #|| / _--= preempt-depth #||| / delay # TASK-PID CPU# TIMESTAMP FUNCTION # | | | | | I highly suspect my trace_xxx function is compiled as an empty function if following my bogus patch. Gong, can you try moving the CREATE_TRACE_POINTS line to a new file - arch/x86/ras/ras.c and define it there and not anywhere else, i.e. move it away from edac_mc.c. Does that help? In current kernel we haven't arch/x86/ras/ras.c. You mean I create a new one there and just add some trace macro definition? Also, see Documentation/trace/tracepoints.txt for more info. HTH. -- Regards/Gruss, Boris. Sent from a fat crate under my desk. Formatting is fine. -- signature.asc Description: Digital signature
Re: [PATCH 2/2] ARM: OMAP4460: cpuidle: WA for ROM bug because of CA9 r2pX gic control register change
On 10/17/2013 04:57 PM, Santosh Shilimkar wrote:
On Thursday 17 October 2013 05:24 AM, Grygorii Strashko wrote:
On OMAP4+ devices, GIC register context is lost when MPUSS hits the
OSWR. On the CPU wakeup path, ROM code gets executed and one of the
steps in it is to restore the saved context of the GIC.
The ROM code uses GICD != 1 condition to decide how the GIC registers
are handled in wakeup path from OSWR. But, GICD register has changed
between CortexA9 r1pX and r2pX and it contains 2 bits now. Secure view
which ROM code sees:
bit 1 == Enable Non-secure
bit 0 == Enable secure
Non-secure view which HLOS sees:
bit 0 == Enable Non-secure
As result, on OMAP4460(r2pX) devices, when the ROM code is executed
during CPU1 wakeup, GICD == 3 and it fails to understand the real wakeup
power state and reconfigures GIC distributor to boot values and, as
result, the entire interrupt controller context will loose in a live
system.
Hence, implement a workaround on OMAP4460 devices in case if MPUSS has
hit OSWR - as long as CPU1 sees GICD == 1 in it's wakeup path from OSWR,
the issue won't happen:
1.1) CPU0 must disable the GIC distributor, before doing the CPU1
wakeup,
1.2) CPU0 should wait until CPU1 will re-enable the GIC distributor
2) CPU1 must re-enable the GIC distributor on it's wakeup path.
The workaround for CPUIdle has been implemented in the same way as
for boot-up hot-plug path in:
- http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap.git;
a=commitdiff;h=ff999b8a0983ee15668394ed49e38d3568fc6859
For more information see:
- https://patchwork.kernel.org/patch/1609011/
- http://www.spinics.net/lists/arm-kernel/msg201402.html
The ROM code bug is applicable to only OMAP4460(r2pX) devices.
OMAP4470 (also r2pX) is not affected by this bug because ROM code has been
fixed.
Just give reference to the commit which has best description about
the bug and just say applying the fix for idle case.
ff999b8a {ARM: OMAP4460: Workaround for ROM...}
Cc: Santosh Shilimkar santosh.shilim...@ti.com
Cc: Kevin Hilman khil...@linaro.org
Reported-and-Tested-by: Taras Kondratiuk taras.kondrat...@linaro.org
Signed-off-by: Grygorii Strashko grygorii.stras...@ti.com
---
arch/arm/mach-omap2/common.h |1 +
arch/arm/mach-omap2/cpuidle44xx.c | 34 +-
arch/arm/mach-omap2/omap4-common.c |6 ++
3 files changed, 40 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index b875a4a..7957110 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -232,6 +232,7 @@ static inline void __iomem *omap4_get_scu_base(void)
extern void __init gic_init_irq(void);
extern void gic_dist_disable(void);
+extern void gic_dist_enable(void);
extern bool gic_dist_disabled(void);
extern void gic_timer_retrigger(void);
extern void omap_smc1(u32 fn, u32 arg);
diff --git a/arch/arm/mach-omap2/cpuidle44xx.c
b/arch/arm/mach-omap2/cpuidle44xx.c
index 384aa1c..528638b 100644
--- a/arch/arm/mach-omap2/cpuidle44xx.c
+++ b/arch/arm/mach-omap2/cpuidle44xx.c
@@ -80,6 +80,7 @@ static int omap_enter_idle_coupled(struct cpuidle_device *dev,
int index)
{
struct idle_statedata *cx = state_ptr + index;
+u32 mpuss_context_lost = 0;
/*
* CPU0 has to wait and stay ON until CPU1 is OFF state.
@@ -126,13 +127,44 @@ static int omap_enter_idle_coupled(struct cpuidle_device
*dev,
omap4_enter_lowpower(dev-cpu, cx-cpu_state);
cpu_done[dev-cpu] = true;
+mpuss_context_lost = omap4_mpuss_read_prev_context_state();
+
Just use the targeted state since couple idle almost grantees
the low power entry. Even in failed case, applying errata sequence
is harmless.
/* Wakeup CPU1 only if it is not offlined */
if (dev-cpu == 0 cpumask_test_cpu(1, cpu_online_mask)) {
+/*
+ * GIC distributor control register has changed between
+ * CortexA9 r1pX and r2pX. The Control Register secure
+ * banked version is now composed of 2 bits:
+ * bit 0 == Secure Enable
+ * bit 1 == Non-Secure Enable
+ * The Non-Secure banked register has not changed
+ * Because the ROM Code is based on the r1pX GIC, the CPU1
+ * GIC restoration will cause a problem to CPU0 Non-Secure SW.
+ * The workaround must be:
+ * 1) Before doing the CPU1 wakeup, CPU0 must disable
+ * the GIC distributor and wait until it will be enabled by CPU1
+ * 2) CPU1 must re-enable the GIC distributor on
+ * it's wakeup path.
+ */
+if (IS_PM44XX_ERRATUM(PM_OMAP4_ROM_SMP_BOOT_ERRATUM_GICD)
+mpuss_context_lost)
Use target state here..
+gic_dist_disable();
+
clkdm_wakeup(cpu_clkdm[1]);
omap_set_pwrdm_state(cpu_pd[1], PWRDM_POWER_ON);
clkdm_allow_idle(cpu_clkdm[1]);
+
+if
Re: [PATCH] perf, x86: Optimize intel_pmu_pebs_fixup_ip()
On Wed, Oct 16, 2013 at 12:57:55PM +0200, Peter Zijlstra wrote:
A prettier patch below. The main difference is on-demand allocation of
the scratch buffer.
---
Subject: perf, x86: Optimize intel_pmu_pebs_fixup_ip()
From: Peter Zijlstra pet...@infradead.org
Date: Tue, 15 Oct 2013 12:14:04 +0200
On Mon, Oct 14, 2013 at 04:35:49PM -0400, Don Zickus wrote:
While there are a few places that are causing latencies, for now I focused
on
the longest one first. It seems to be 'copy_user_from_nmi'
intel_pmu_handle_irq -
intel_pmu_drain_pebs_nhm -
__intel_pmu_drain_pebs_nhm -
__intel_pmu_pebs_event -
intel_pmu_pebs_fixup_ip -
copy_from_user_nmi
In intel_pmu_pebs_fixup_ip(), if the while-loop goes over 50, the sum of
all the copy_from_user_nmi latencies seems to go over 1,000,000 cycles
(there are some cases where only 10 iterations are needed to go that high
too, but in generall over 50 or so). At this point copy_user_from_nmi
seems to account for over 90% of the nmi latency.
So avoid having to call copy_from_user_nmi() for every instruction.
Since we already limit the max basic block size, we can easily
pre-allocate a piece of memory to copy the entire thing into in one
go.
Don reports (for a previous version):
Your patch made a huge difference in improvement. The
copy_from_user_nmi() no longer hits the million of cycles. I still
have a batch of 100,000-300,000 cycles. My longest NMI paths used
to be dominated by copy_from_user_nmi, now it is not (I have to dig
up the new hot path).
Hi Peter,
For some reason this patch is page faulting at an invalid address inside
__intel_pmu_pebs_event().
Cheers,
Don
Cc: eran...@google.com
Cc: a...@linux.intel.com
Cc: jma...@redhat.com
Cc: a...@infradead.org
Cc: dave.han...@linux.intel.com
Reported-by: Don Zickus dzic...@redhat.com
Signed-off-by: Peter Zijlstra pet...@infradead.org
---
arch/x86/kernel/cpu/perf_event_intel_ds.c | 48
+-
1 file changed, 34 insertions(+), 14 deletions(-)
--- a/arch/x86/kernel/cpu/perf_event_intel_ds.c
+++ b/arch/x86/kernel/cpu/perf_event_intel_ds.c
@@ -12,6 +12,7 @@
#define BTS_BUFFER_SIZE (PAGE_SIZE 4)
#define PEBS_BUFFER_SIZE PAGE_SIZE
+#define PEBS_FIXUP_SIZE PAGE_SIZE
/*
* pebs_record_32 for p4 and core not supported
@@ -228,12 +229,14 @@ void fini_debug_store_on_cpu(int cpu)
wrmsr_on_cpu(cpu, MSR_IA32_DS_AREA, 0, 0);
}
+static DEFINE_PER_CPU(void *, insn_buffer);
+
static int alloc_pebs_buffer(int cpu)
{
struct debug_store *ds = per_cpu(cpu_hw_events, cpu).ds;
int node = cpu_to_node(cpu);
int max, thresh = 1; /* always use a single PEBS record */
- void *buffer;
+ void *buffer, *ibuffer;
if (!x86_pmu.pebs)
return 0;
@@ -242,6 +245,15 @@ static int alloc_pebs_buffer(int cpu)
if (unlikely(!buffer))
return -ENOMEM;
+ if (x86_pmu.intel_cap.pebs_format 2) {
+ ibuffer = kzalloc_node(PEBS_FIXUP_SIZE, GFP_KERNEL, node);
+ if (!ibuffer) {
+ kfree(buffer);
+ return -ENOMEM;
+ }
+ per_cpu(insn_buffer, cpu) = ibuffer;
+ }
+
max = PEBS_BUFFER_SIZE / x86_pmu.pebs_record_size;
ds-pebs_buffer_base = (u64)(unsigned long)buffer;
@@ -262,6 +274,9 @@ static void release_pebs_buffer(int cpu)
if (!ds || !x86_pmu.pebs)
return;
+ kfree(per_cpu(insn_buffer, cpu));
+ per_cpu(insn_buffer, cpu) = NULL;
+
kfree((void *)(unsigned long)ds-pebs_buffer_base);
ds-pebs_buffer_base = 0;
}
@@ -729,6 +744,7 @@ static int intel_pmu_pebs_fixup_ip(struc
unsigned long old_to, to = cpuc-lbr_entries[0].to;
unsigned long ip = regs-ip;
int is_64bit = 0;
+ void *kaddr;
/*
* We don't need to fixup if the PEBS assist is fault like
@@ -752,7 +768,7 @@ static int intel_pmu_pebs_fixup_ip(struc
* unsigned math, either ip is before the start (impossible) or
* the basic block is larger than 1 page (sanity)
*/
- if ((ip - to) PAGE_SIZE)
+ if ((ip - to) PEBS_FIXUP_SIZE)
return 0;
/*
@@ -763,29 +779,33 @@ static int intel_pmu_pebs_fixup_ip(struc
return 1;
}
+ if (!kernel_ip(ip)) {
+ int size, bytes;
+ u8 *buf = this_cpu_ptr(insn_buffer);
+
+ size = ip - to; /* Must fit our buffer, see above */
+ bytes = copy_from_user_nmi(buf, (void __user *)to, size);
+ if (bytes != size)
+ return 0;
+
+ kaddr = buf;
+ } else {
+ kaddr = (void *)to;
+ }
+
do {
struct insn insn;
- u8
[PATCH] mm: Check for NULL return values from allocating functions
A security audit revealed that several functions were not checking
return value of allocation functions. These allocations may return
NULL which may lead to NULL pointer dereferences and crashes or
security concerns. Fix this by properly checking the return value
and handling the error appropriately.
Signed-off-by: Laura Abbott lau...@codeaurora.org
---
fs/buffer.c | 17 +++--
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index 4d74335..b53f863 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1561,6 +1561,9 @@ void create_empty_buffers(struct page *page,
struct buffer_head *bh, *head, *tail;
head = alloc_page_buffers(page, blocksize, 1);
+ if (head == NULL)
+ return;
+
bh = head;
do {
bh-b_state |= b_state;
@@ -3008,16 +3011,18 @@ int _submit_bh(int rw, struct buffer_head *bh, unsigned
long bio_flags)
BUG_ON(buffer_unwritten(bh));
/*
-* Only clear out a write error when rewriting
-*/
- if (test_set_buffer_req(bh) (rw WRITE))
- clear_buffer_write_io_error(bh);
-
- /*
* from here on down, it's all bio -- do the initial mapping,
* submit_bio - generic_make_request may further map this bio around
*/
bio = bio_alloc(GFP_NOIO, 1);
+ if (bio == NULL)
+ return -ENOMEM;
+
+ /*
+* Only clear out a write error when rewriting
+*/
+ if (test_set_buffer_req(bh) (rw WRITE))
+ clear_buffer_write_io_error(bh);
bio-bi_sector = bh-b_blocknr * (bh-b_size 9);
bio-bi_bdev = bh-b_bdev;
--
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] KVM: x86: fix KVM_SET_XCRS for CPUs that do not support XSAVE
The KVM_SET_XCRS ioctl must accept anything that KVM_GET_XCRS
could return. XCR0's bit 0 is always 1 in real processors with
XSAVE, and KVM_GET_XCRS will always leave bit 0 set even if the
emulated processor does not have XSAVE. So, KVM_SET_XCRS must
ignore that bit when checking for attempts to enable unsupported
save states.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
Introduced between v2 and v3, when I stopped hardcoding
XSTATE_FPSSE in guest_supported_xcr0.
arch/x86/kvm/x86.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index c951c71..f4e1391 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -577,6 +577,7 @@ static void kvm_put_guest_xcr0(struct kvm_vcpu *vcpu)
int __kvm_set_xcr(struct kvm_vcpu *vcpu, u32 index, u64 xcr)
{
u64 xcr0;
+ u64 valid_bits;
/* Only support XCR_XFEATURE_ENABLED_MASK(xcr0) now */
if (index != XCR_XFEATURE_ENABLED_MASK)
@@ -586,8 +587,16 @@ int __kvm_set_xcr(struct kvm_vcpu *vcpu, u32 index, u64
xcr)
return 1;
if ((xcr0 XSTATE_YMM) !(xcr0 XSTATE_SSE))
return 1;
- if (xcr0 ~vcpu-arch.guest_supported_xcr0)
+
+ /*
+* Do not allow the guest to set bits that we do not support
+* saving. However, xcr0 bit 0 is always set, even if the
+* emulated CPU does not support XSAVE (see fx_init).
+*/
+ valid_bits = vcpu-arch.guest_supported_xcr0 | XSTATE_FP;
+ if (xcr0 ~valid_bits)
return 1;
+
kvm_put_guest_xcr0(vcpu);
vcpu-arch.xcr0 = xcr0;
return 0;
--
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 0/2] KVM_SET_XCRS fixes
The first patch fixes bugs 63121 and 63131 (yeah, all kernel bugs end with 1). The second patch fixes a typo (the same typo exists in QEMU). Paolo Bonzini (2): KVM: x86: fix KVM_SET_XCRS for CPUs that do not support XSAVE KVM: x86: fix KVM_SET_XCRS loop arch/x86/kvm/x86.c | 15 --- 1 file changed, 12 insertions(+), 3 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 2/2] KVM: x86: fix KVM_SET_XCRS loop
The loop was always using 0 as the index. This means that
any rubbish after the first element of the array went undetected.
It seems reasonable to assume that no KVM userspace did that.
Signed-off-by: Paolo Bonzini pbonz...@redhat.com
---
arch/x86/kvm/x86.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index f4e1391..f91dff2 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -3062,9 +3062,9 @@ static int kvm_vcpu_ioctl_x86_set_xcrs(struct kvm_vcpu
*vcpu,
for (i = 0; i guest_xcrs-nr_xcrs; i++)
/* Only support XCR0 currently */
- if (guest_xcrs-xcrs[0].xcr == XCR_XFEATURE_ENABLED_MASK) {
+ if (guest_xcrs-xcrs[i].xcr == XCR_XFEATURE_ENABLED_MASK) {
r = __kvm_set_xcr(vcpu, XCR_XFEATURE_ENABLED_MASK,
- guest_xcrs-xcrs[0].value);
+ guest_xcrs-xcrs[i].value);
break;
}
if (r)
--
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] perf, x86: Optimize intel_pmu_pebs_fixup_ip()
On Thu, Oct 17, 2013 at 10:49:13AM -0400, Don Zickus wrote: For some reason this patch is page faulting at an invalid address inside __intel_pmu_pebs_event(). Ah yes, I lost a refresh, but read on; I've send a gazillion new emails since ;-) I think it was something like: s/this_cpu_ptr/this_cpu_read/ to make it work again. -- 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 v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
Am Donnerstag, den 17.10.2013, 15:30 +0100 schrieb srinivas kandagatla: [...] Sorry to ask this but, Where is this requirement coming from? I have not spotted any thing as such in ePAPR specs. All the spec says is. === The compatible property value consists of one or more strings that define the specific programming model for the device. This list of strings should be used by a client program for device driver selection. The property value consists of a concatenated list of null terminated strings, *from most specific to most general.* They allow a device to express its compatibility with a family of similar devices, potentially allowing a single device driver to match against several devices. The recommended format is “manufacturer,model”, where manufacturer is a string describing the name of the manufacturer (such as an OUI), and model specifies the model number. Example: compatible = “fsl,mpc8641-uart”, “ns16550; In this example, an operating system would first try to locate a device driver that supported fsl,mpc8641-uart. If a driver was not found, it would then try to locate a driver that supported the more general ns16550 device type. === The more general compatible string in this case is st,comms-ssc-i2c, rather than the first soc name. How can a first SOC name be more general? As this driver is not very specific to StiH415, it is generic driver for ST comms-ssc-i2c block. You just can't know if someone in the future decides to subtly change the register layout or make some other incompatible change to the comms-ssc-i2c block. So as a general rule of thumb you take the first SoC where a particular IP block appeared as the compatible string, so you can just pick the name of the SoC where the incompatible change was made as the next string and not need to invent generic and unspecific comms-ssc-i2c-v2 compatibles. Regards, Lucas -- Pengutronix e.K. | Lucas Stach | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-5076 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/7] usb: dwc3: get usb_phy only if the platform indicates the presence of PHY's
On Wed, Oct 16, 2013 at 04:27:26PM +0300, Roger Quadros wrote:
On 10/16/2013 04:10 PM, Kishon Vijay Abraham I wrote:
Hi roger,
On Wednesday 16 October 2013 06:33 PM, Roger Quadros wrote:
Hi Kishon,
On 10/15/2013 10:54 PM, Kishon Vijay Abraham I wrote:
There can be systems which does not have a external usb_phy, so get
usb_phy only if dt data indicates the presence of PHY in the case of dt
boot or
if platform_data indicates the presence of PHY. Also remove checking if
return value is -ENXIO since it's now changed to always enable usb_phy
layer.
Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
In usb_get_phy_by_phandle, index 0 always refers to usb2 phy and index 1
always
refers to usb3 phy. Since we've lived so long with this, this patch will
make
an assumption that if only one entry is populated in *usb-phy* property,
it will
be usb2 phy and the next entry will be usb3 phy.
drivers/usb/dwc3/Kconfig |1 +
drivers/usb/dwc3/core.c | 72
--
drivers/usb/dwc3/platform_data.h |2 ++
3 files changed, 41 insertions(+), 34 deletions(-)
diff --git a/drivers/usb/dwc3/Kconfig b/drivers/usb/dwc3/Kconfig
index 70fc430..8e385b4 100644
--- a/drivers/usb/dwc3/Kconfig
+++ b/drivers/usb/dwc3/Kconfig
@@ -1,6 +1,7 @@
config USB_DWC3
tristate DesignWare USB3 DRD Core Support
depends on (USB || USB_GADGET) HAS_DMA
+ select USB_PHY
select USB_XHCI_PLATFORM if USB_SUPPORT USB_XHCI_HCD
help
Say Y or M here if your system has a Dual Role SuperSpeed
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 474162e..cb91d70 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -354,6 +354,7 @@ static int dwc3_probe(struct platform_device *pdev)
struct device_node *node = dev-of_node;
struct resource *res;
struct dwc3 *dwc;
+ int count;
int ret = -ENOMEM;
@@ -387,16 +388,49 @@ static int dwc3_probe(struct platform_device *pdev)
if (node) {
dwc-maximum_speed = of_usb_get_maximum_speed(node);
- dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 0);
- dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev, usb-phy, 1);
+ count = of_count_phandle_with_args(node, usb-phy, NULL);
+ switch (count) {
+ case 2:
+ dwc-usb3_phy = devm_usb_get_phy_by_phandle(dev,
+ usb-phy, 1);
+ if (IS_ERR(dwc-usb3_phy)) {
+ dev_err(dev, usb3 phy not found\n);
+ return PTR_ERR(dwc-usb3_phy);
+ }
+ case 1:
+ dwc-usb2_phy = devm_usb_get_phy_by_phandle(dev,
+ usb-phy, 0);
+ if (IS_ERR(dwc-usb2_phy)) {
+ dev_err(dev, usb2 phy not found\n);
+ return PTR_ERR(dwc-usb2_phy);
+ }
+ break;
In the Exynos case, there is only 1 phy and it is the USB3 phy. This code
will wrongly treat it as usb2_phy.
That was the case even before this patch no? Unfortunately the old USB PHY
library doesn't have APIs to get PHYs in a better way. If we try modifying
the
USB PHY library, it'll be kind of duplicating what is already there in the
Generic PHY library. I'd rather prefer Exynos guys to use the new framework.
OK. I agree with you.
Do you know if there are users of dwc3 other than exynos5250 and omap5?
If not, we should get rid of the old USB PHY altogether.
Intel's Baytrail, at least. But they don't use DT.
--
balbi
signature.asc
Description: Digital signature
Re: [PATCH 3/4] ARM: pinctrl: Add Broadcom Capri pinctrl driver
On 10/17/2013 12:03 AM, Christian Daudt wrote: On Thu, Oct 3, 2013 at 5:23 PM, Sherman Yin s...@broadcom.com wrote: Adds pinctrl driver for Broadcom Capri (BCM281xx) SoCs. Signed-off-by: Sherman Yin s...@broadcom.com Reviewed-by: Christian Daudt b...@fixthebug.org Reviewed-by: Matt Porter matt.por...@linaro.org --- arch/arm/mach-bcm/Kconfig |2 + drivers/pinctrl/Kconfig | 10 + drivers/pinctrl/Makefile|1 + drivers/pinctrl/pinctrl-capri.c | 1727 +++ 4 files changed, 1740 insertions(+) create mode 100644 drivers/pinctrl/pinctrl-capri.c diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig index 69d67f7..2546365 100644 --- a/arch/arm/mach-bcm/Kconfig +++ b/arch/arm/mach-bcm/Kconfig @@ -10,6 +10,8 @@ config ARCH_BCM select GENERIC_CLOCKEVENTS select GENERIC_TIME select GPIO_BCM + select PINCTRL + select PINCTRL_CAPRI select SPARSE_IRQ select TICK_ONESHOT select CACHE_L2X0 On your subsequent patchset pls move this from Kconfig to arm/configs/bcm_defconfig, and break that modification into a separate patch from the drivers/* modification. The other SoCs I'm familiar with all select this from their ARCH_xxx config symbol. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: linux-next: manual merge of the kvm-arm tree
On Wed, Oct 16, 2013 at 12:02:08PM -0700, Christoffer Dall wrote: On 16 October 2013 11:58, Marc Zyngier marc.zyng...@arm.com wrote: On 16/10/13 19:51, Thierry Reding wrote: Today's linux-next merge of the kvm-arm tree got conflicts in arch/arm/kvm/reset.c caused by commits e8c2d99 (KVM: ARM: Add support for Cortex-A7) and ac570e0 (ARM: kvm: rename cpu_reset to avoid name clash). I've fixed them up (see below). Please verify that the resolution looks good. Looks good to me (I have the same resolution in my own tree). Yes, fix is good. This will stay a conflict until kvm/next and kvm/fixes merge, which doesn't happen before after the merge window, usually. If that's So in this case it happened today because part of powerpc patches where based on commit after -rc4 and I had to merge to be able to pull them. Christoffer can you look at queue branch of kvm.git and see that the resolution is correct? -- 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: [tpmdd-devel] TPM patches for 2.13
On Sun, Oct 06, 2013 at 01:31:20PM -0600, Jason Gunthorpe wrote: I've prepared this branch: https://github.com/jgunthorpe/linux/commits/for-tpm dd783708a8c6fd713c784be68fcbcb7000c43c49 Jason Gunthorpe (11): tpm: ibmvtpm: Use %zd formatting for size_t format arguments tpm atmel: Call request_region with the correct base tpm: Store devname in the tpm_chip tpm: Use container_of to locate the tpm_chip in tpm_open tpm: Remove redundant dev_set_drvdata tpm: st33: Remove chip-data_buffer access from this driver tpm: Remove tpm_show_caps_1_2 tpm: Rename tpm.c to tpm-interface.c tpm: Merge the tpm-bios module with tpm.o tpm: Add support for the Nuvoton NPCT501 I2C TPM tpm: Add support for Atmel I2C TPMs Which contains the first half of the clean-up patches and my two drivers. The cleanups are well ack'd now, and I've done quite a bit of testing with the two drivers, so I'd like to see agreement that this batch can move forward as a series, and the other patches can sit ontop of this series. Folks, the 3.13 merge window is fast approaching, any chance of advancing this work? Jason -- 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] drm: never write to the userspace more data than the caller wants
On Thu, 17 Oct 2013 13:26:47 +0100 Chris Wilson ch...@chris-wilson.co.uk wrote: On Wed, Oct 16, 2013 at 08:12:35PM -0400, Pavel Roskin wrote: The amount of data wanted by the userspace caller is encoded in the ioctl number. Generic drm ioctls were ignoring it. As a result, Intel Xorg driver didn't work for i386 userspace on x86_64 kernel on some systems. sizeof(struct drm_mode_get_connector) is 76 bytes on i686 and 80 bytes on x86_64 due to the tail alignment (the data positions match). The userspace was using the 4 bytes after the structure to hold the result of the ioctl. Since drm_ioctl() was copying 80 bytes instead of 76, it was clobbering that data. A workaround has been committed to xf86-video-intel. Signed-off-by: Pavel Roskin pro...@gnu.org Cc: sta...@vger.kernel.org Similar patch: http://lists.freedesktop.org/archives/dri-devel/2013-October/047412.html -Chris Wow, it's great that you also thought about it! Your patch does almost the same thing. There is one difference. If the userspace requests more data than the kernel needs, your patch would trust the userspace and set usize to whatever the user wants. It would set asize to the same value, allocating more memory than the driver wants, up to 16383 bytes. I don't think it's a good idea for performance reasons. My patch would decrease usize rather than increase asize. The code for driver-specific ioctls could be fixed too, it's just not so urgent as fixing a real bug. That said, I have no format objection against your patch. It would be great to have that bug fixed. -- Regards, Pavel Roskin -- 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 v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On 09:27 Thu 17 Oct , Maxime COQUELIN wrote:
Hi Jean-Christophe,
On 10/16/2013 05:14 PM, Jean-Christophe PLAGNIOL-VILLARD wrote:
...
+
+static inline void st_i2c_set_bits(void __iomem *reg, u32 mask)
+{
+ writel(readl(reg) | mask, reg);
+}
+
+static inline void st_i2c_clr_bits(void __iomem *reg, u32 mask)
+{
+ writel(readl(reg) ~mask, reg);
use set_bit api and use relaxed version
Using the set_bit api here does not match with the purpose of these
functions.
We want to be able to set/clear multiple bits, and AFAICS the set_bit
api does not
provide this possibility.
I took example on i2c-nomadik for these functions.
so factorize the code not copy and paste
+}
+
+/* From I2C Specifications v0.5 */
+static struct st_i2c_timings i2c_timings[] = {
+ [I2C_MODE_STANDARD] = {
+ .rate = 10,
+ .rep_start_hold = 4000,
+ .rep_start_setup= 4700,
+ .start_hold = 4000,
+ .data_setup_time= 250,
+ .stop_setup_time= 4000,
+ .bus_free_time = 4700,
+ },
+ [I2C_MODE_FAST] = {
+ .rate = 40,
+ .rep_start_hold = 600,
+ .rep_start_setup= 600,
+ .start_hold = 600,
+ .data_setup_time= 100,
+ .stop_setup_time= 600,
+ .bus_free_time = 1300,
+ },
+};
so how do you plane to support other rate that 100k and 400k?
The SSC IP only supports Standard and Fast modes.
There are no plans to support faster modes.
+
+static void st_i2c_flush_rx_fifo(struct st_i2c_dev *i2c_dev)
+{
+ int count, i;
+
+ /*
+ * Counter only counts up to 7 but fifo size is 8...
+ * When fifo is full, counter is 0 and RIR bit of status register is
+ * set
+ */
+ if (readl(i2c_dev-base + SSC_STA) SSC_STA_RIR)
+ count = SSC_RXFIFO_SIZE;
+ else
+ count = readl(i2c_dev-base + SSC_RX_FSTAT)
+ SSC_RX_FSTAT_STATUS;
+
+ for (i = 0; i count; i++)
+ readl(i2c_dev-base + SSC_RBUF);
use readsl
Since the read content is flushed, I prefer keeping it as it is instead
of allocating
a buffer of the FIFO's size.
keep point is to speedup the bus
use relaxed version as much as possible
I was not comfortable with the different possibilities (_raw_readl,
readl_relaxed, readl...).
I found this interresting discussion:
_http://comments.gmane.org/gmane.linux.ports.arm.kernel/117626
From what I understood, you are right, I should be able to use
readl_relaxed everywhere.
Maybe I should perform a readl on the interrupt mask register before
returning from the interrupt handler,
in order to ensure that the write to the IEN register is effective
before the IRQ for the device is re-enabled at GIC level.
Maybe this could avoid the few spurious interrupts I face sometimes, I
will have a try.
ok
+}
+
...
+
+static int st_i2c_wait_free_bus(struct st_i2c_dev *i2c_dev)
+{
+ u32 sta;
+ int i;
+
+ for (i = 0; i 10; i++) {
+ sta = readl(i2c_dev-base + SSC_STA);
+ if (!(sta SSC_STA_BUSY))
+ return 0;
+
+ usleep_range(2000, 4000);
can not use interrupt?
Sadly, no.
There is no interrupt linked to the busy bit.
+ }
+
...
+
+static struct of_device_id st_i2c_match[] = {
+ { .compatible = st,comms-ssc-i2c, },
the rules is to put the first soc that use the ip in the compatible
as st,sti7100-scc-i2c
Ok. There are no plans to upstream the SH4 platforms, it will only
remains in stlinux.com.
Maybe I can set the first ARM platform (STiH415)?
That would give st,stih415-ssc-i2c.
no you need to put the first soc even not mainline dt is not relaated to linux
mainline of not we describe hw
IIRC it was even present before sh4, on st200 IIRC need to check my old
datasheet
Best Regards,
J.
Thanks for the review,
Maxime
Best Regards,
J.
--
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] perf, x86: Optimize intel_pmu_pebs_fixup_ip()
On Thu, Oct 17, 2013 at 04:51:31PM +0200, Peter Zijlstra wrote: On Thu, Oct 17, 2013 at 10:49:13AM -0400, Don Zickus wrote: For some reason this patch is page faulting at an invalid address inside __intel_pmu_pebs_event(). Ah yes, I lost a refresh, but read on; I've send a gazillion new emails since ;-) Yes, I have noticed, but I got worried when you labeled some of them with 'untested'. :-) Thought I would stick to something a little more close to working. I think it was something like: s/this_cpu_ptr/this_cpu_read/ to make it work again. Thanks. I will try some of the other pieces today (unlike yesterday). Cheers, Don -- 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] efivars,efi-pstore: Hold off deletion of sysfs entry until, the scan is completed
Hi folks, I tested it on my DELL XPS desktop. And it won't show any warnings when I mounting pstore and deleting pstore items after this patch applied. Tested-by: Madper Xie c...@redhat.com writes: Oops, It seems my mu4e(a email client for emacs)'s auto-indent breaks the patch... I apologize for this... seiji.agu...@hds.com writes: Hi Madper, I tested this patch on 3.12-rc4. Could you please send me the log when you failed to apply? Seiji -Original Message- From: Madper Xie [mailto:c...@redhat.com] Sent: Thursday, October 17, 2013 1:54 AM To: Seiji Aguchi Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; matt.flem...@intel.com; tony.l...@intel.com; Tomoki Sekiyama; dle- deve...@lists.sourceforge.net Subject: Re: [PATCH v3] efivars,efi-pstore: Hold off deletion of sysfs entry until, the scan is completed Howdy Seiji, I failed appily this patch to both 3.12-rc2 and 3.12-rc4. Could you please let me know which is the right tree for this patch? Thanks, Madper. seiji.agu...@hds.com writes: Change from v2: - Move dynamic memory allocation to efi_pstore_read() before holding efivars-lock to protect entry-var.Data. - Access to entry-scanning while holding efivars-lock. - Move a comment about a returned value from efi_pstore_read_func() to efi_pstore_read() because size 0 case may happen in efi_pstore_read(). Currently, when mounting pstore file system, a read callback of efi_pstore driver runs mutiple times as below. - In the first read callback, scan efivar_sysfs_list from head and pass a kmsg buffer of a entry to an upper pstore layer. - In the second read callback, rescan efivar_sysfs_list from the entry and pass another kmsg buffer to it. - Repeat the scan and pass until the end of efivar_sysfs_list. In this process, an entry is read across the multiple read function calls. To avoid race between the read and erasion, the whole process above is protected by a spinlock, holding in open() and releasing in close(). At the same time, kmemdup() is called to pass the buffer to pstore filesystem during it. And then, it causes a following lockdep warning. To make the dynamic memory allocation runnable without taking spinlock, holding off a deletion of sysfs entry if it happens while scanning it via efi_pstore, and deleting it after the scan is completed. To implement it, this patch introduces two flags, scanning and deleting, to efivar_entry. [1.143710] [ cut here ] [1.144058] WARNING: CPU: 1 PID: 1 at kernel/lockdep.c:2740 lockdep_trace_alloc+0x104/0x110() [1.144058] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) [1.144058] Modules linked in: [1.144058] CPU: 1 PID: 1 Comm: systemd Not tainted 3.11.0-rc5 #2 [1.144058] 0009 8800797e9ae0 816614a5 8800797e9b28 [1.144058] 8800797e9b18 8105510d 0080 0046 [1.144058] 00d0 03af 81ccd0c0 8800797e9b78 [1.144058] Call Trace: [1.144058] [816614a5] dump_stack+0x54/0x74 [1.144058] [8105510d] warn_slowpath_common+0x7d/0xa0 [1.144058] [8105517c] warn_slowpath_fmt+0x4c/0x50 [1.144058] [8131290f] ? vsscanf+0x57f/0x7b0 [1.144058] [810bbd74] lockdep_trace_alloc+0x104/0x110 [1.144058] [81192da0] __kmalloc_track_caller+0x50/0x280 [1.144058] [815147bb] ? efi_pstore_read_func.part.1+0x12b/0x170 [1.144058] [8115b260] kmemdup+0x20/0x50 [1.144058] [815147bb] efi_pstore_read_func.part.1+0x12b/0x170 [1.144058] [81514800] ? efi_pstore_read_func.part.1+0x170/0x170 [1.144058] [815148b4] efi_pstore_read_func+0xb4/0xe0 [1.144058] [81512b7b] __efivar_entry_iter+0xfb/0x120 [1.144058] [8151428f] efi_pstore_read+0x3f/0x50 [1.144058] [8128d7ba] pstore_get_records+0x9a/0x150 [1.158207] [812af25c] ? selinux_d_instantiate+0x1c/0x20 [1.158207] [8128ce30] ? parse_options+0x80/0x80 [1.158207] [8128ced5] pstore_fill_super+0xa5/0xc0 [1.158207] [811ae7d2] mount_single+0xa2/0xd0 [1.158207] [8128ccf8] pstore_mount+0x18/0x20 [1.158207] [811ae8b9] mount_fs+0x39/0x1b0 [1.158207] [81160550] ? __alloc_percpu+0x10/0x20 [1.158207] [811c9493] vfs_kern_mount+0x63/0xf0 [1.158207] [811cbb0e] do_mount+0x23e/0xa20 [1.158207] [8115b51b] ? strndup_user+0x4b/0xf0 [1.158207] [811cc373] SyS_mount+0x83/0xc0 [1.158207] [81673cc2] system_call_fastpath+0x16/0x1b [1.158207] ---[ end trace 61981bc62de9f6f4 ]--- Signed-off-by: Seiji Aguchi seiji.agu...@hds.com ---
RE: [PATCH v9 3/7] thermal:boost: Automatic enable/disable of BOOST feature
-Original Message-
From: Lukasz Majewski [mailto:l.majew...@samsung.com]
Sent: Tuesday, October 15, 2013 11:43 PM
To: Zhang, Rui
Cc: Viresh Kumar; Rafael J. Wysocki; Eduardo Valentin;
cpuf...@vger.kernel.org; Linux PM list; Jonghwa Lee; Lukasz Majewski;
linux-kernel; Bartlomiej Zolnierkiewicz; Myungjoo Ham; R, Durgadoss
Subject: Re: [PATCH v9 3/7] thermal:boost: Automatic enable/disable of
BOOST feature
Importance: High
Hi Zhang,
Hi, Lukasz,
thanks for the patch, sorry that I didn't look into this one earlier.
Yes, I would _really_ appreciate _earlier_ feedback from thermal
maintainers :-)
On Mon, 2013-10-14 at 14:17 +0200, Lukasz Majewski wrote:
This patch provides auto disable/enable operation for boost. When
any defined trip point is passed, the boost is disabled.
Do you mean boost is disabled if the system is in a overheating state?
In short - Yes.
To be more precise - the thermal here is a safe valve.
Its role is to provide hysteresis similar to the one available for
Intel processors.
Intel does it in HW. Here I'm trying to do the same with SW for ARM.
In that moment thermal monitor workqueue is woken up and it
monitors
if the device temperature drops below 75% of the smallest trip
point.
Just FYI, the smallest trip point does not equal the trip point with
lowest temperature value.
Thermal processors to which I've looked (exynos 4/5, ste-snowball) had
trip points defined monotonically with smallest value defined first.
This was the rationale for choosing thermal trip point 0.
But this is not a hard rule for all thermal drivers, thus you can't make this
assumption.
Say, here is a platform with an active trip point at 40C, and an
critical trip point at 100C, you want to enable boost only if the
temperature is under 30C, right?
In short: no (please read below explanation).
The boost rough idea:
1. I enable boost from cpufreq (no matter what is the state of thermal)
2. If temperature is too high, then thermal interrupt would trigger and
disable boost 3. If device cools down - I enable the boost again
When device cools down, the boost is enabled again.
Signed-off-by: Lukasz Majewski l.majew...@samsung.com
Signed-off-by: Myungjoo Ham myungjoo@samsung.com
---
Changes for v9:
- None
Changes for v8:
- Move cpufreq_boost_* stub functions definition (needed when
cpufreq is not compiled in) to cpufreq.h at cpufreq core support
commit
Changes for v7:
- None
Changes for v6:
- Disable boost only when supported and enabled
- Protect boost related thermal_zone_device struct fields with
mutex
- Evaluate temperature trend during boost enable decision
- Create separate methods to handle boost enable/disable
(thermal_boost_{enable|disable}) operations
- Boost is disabled at any trip point passage (not only the non
critical one)
- Add stub definitions for cpufreq boost functions used when
CONFIG_CPU_FREQ is NOT defined.
Changes for v5:
- Move boost disable code from cpu_cooling.c to thermal_core.c
(to handle_non_critical_trips)
- Extent struct thermal_zone_device by adding overheated bool flag
- Implement auto enable of boost after device cools down
- Introduce boost_polling flag, which indicates if thermal uses
it's
predefined pool delay or has woken up thermal workqueue only to
wait
until device cools down.
Changes for v4:
- New patch
drivers/thermal/thermal_core.c | 55
include/linux/thermal.h|2 ++ 2 files changed, 57
insertions(+)
diff --git a/drivers/thermal/thermal_core.c
b/drivers/thermal/thermal_core.c index 4962a6a..a167ab9 100644
--- a/drivers/thermal/thermal_core.c
+++ b/drivers/thermal/thermal_core.c
@@ -34,6 +34,7 @@
#include linux/thermal.h
#include linux/reboot.h
#include linux/string.h
+#include linux/cpufreq.h
Actually, I do not like to see this as thermal_core.c.
Because it is the platform thermal driver that owns the thermal
policy, e.g. it tells the thermal core to take what action at what
temperature.
And this cpufreq boost support should be part of the thermal policy.
Boost is defined as policy independent at cpufreq.
So I believe that
it shall be also thermal policy independent.
Boost mode support itself is policy independent, but when to use it is kind of
a policy, right?
Say, if you introduce boost support in cpufreq cooling code, either as a
cooling device or as a special cooling state, it is thermal policy independent,
but when to use this cooling device/state is surely part of thermal policy.
In the end thermal shall
help cpufreq to not burn the device.
For example, here is a platform that supports boost. And it has a
passive trip point at 40C, which means the platform driver wants to
reduce the
Re: [PATCH] perf, x86: Optimize intel_pmu_pebs_fixup_ip()
On Thu, Oct 17, 2013 at 11:03:58AM -0400, Don Zickus wrote: On Thu, Oct 17, 2013 at 04:51:31PM +0200, Peter Zijlstra wrote: On Thu, Oct 17, 2013 at 10:49:13AM -0400, Don Zickus wrote: For some reason this patch is page faulting at an invalid address inside __intel_pmu_pebs_event(). Ah yes, I lost a refresh, but read on; I've send a gazillion new emails since ;-) Yes, I have noticed, but I got worried when you labeled some of them with 'untested'. :-) Thought I would stick to something a little more close to working. I think it was something like: s/this_cpu_ptr/this_cpu_read/ to make it work again. Thanks. I will try some of the other pieces today (unlike yesterday). The patches you find in: http://programming.kicks-ass.net/sekrit/patches.tar.bz2 are actually running on my machine now. One of the things I was considering was further shrinking the max basic block size from 4k to maybe 1k or 512 bytes. Not sure what a sane basic block length limit would be. I did try 1k earlier today and I seemed to still get near 100% rewind success rates. Stephane, Andi, any clues? -- 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] efivars,efi-pstore: Hold off deletion of sysfs entry until, the scan is completed
Hi Madper, Thank you for assisting me. But, I need to discuss the implementation with Matt more. After the discussion, I will post v4 and ask you to test it. Please wait for a while. Seiji -Original Message- From: Madper Xie [mailto:c...@redhat.com] Sent: Thursday, October 17, 2013 11:07 AM To: Madper Xie Cc: Seiji Aguchi; linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; matt.flem...@intel.com; tony.l...@intel.com; Tomoki Sekiyama; dle-deve...@lists.sourceforge.net Subject: Re: [PATCH v3] efivars,efi-pstore: Hold off deletion of sysfs entry until, the scan is completed Hi folks, I tested it on my DELL XPS desktop. And it won't show any warnings when I mounting pstore and deleting pstore items after this patch applied. Tested-by: Madper Xie c...@redhat.com writes: Oops, It seems my mu4e(a email client for emacs)'s auto-indent breaks the patch... I apologize for this... seiji.agu...@hds.com writes: Hi Madper, I tested this patch on 3.12-rc4. Could you please send me the log when you failed to apply? Seiji -Original Message- From: Madper Xie [mailto:c...@redhat.com] Sent: Thursday, October 17, 2013 1:54 AM To: Seiji Aguchi Cc: linux-kernel@vger.kernel.org; linux-...@vger.kernel.org; matt.flem...@intel.com; tony.l...@intel.com; Tomoki Sekiyama; dle- deve...@lists.sourceforge.net Subject: Re: [PATCH v3] efivars,efi-pstore: Hold off deletion of sysfs entry until, the scan is completed Howdy Seiji, I failed appily this patch to both 3.12-rc2 and 3.12-rc4. Could you please let me know which is the right tree for this patch? Thanks, Madper. seiji.agu...@hds.com writes: Change from v2: - Move dynamic memory allocation to efi_pstore_read() before holding efivars-lock to protect entry-var.Data. - Access to entry-scanning while holding efivars-lock. - Move a comment about a returned value from efi_pstore_read_func() to efi_pstore_read() because size 0 case may happen in efi_pstore_read(). Currently, when mounting pstore file system, a read callback of efi_pstore driver runs mutiple times as below. - In the first read callback, scan efivar_sysfs_list from head and pass a kmsg buffer of a entry to an upper pstore layer. - In the second read callback, rescan efivar_sysfs_list from the entry and pass another kmsg buffer to it. - Repeat the scan and pass until the end of efivar_sysfs_list. In this process, an entry is read across the multiple read function calls. To avoid race between the read and erasion, the whole process above is protected by a spinlock, holding in open() and releasing in close(). At the same time, kmemdup() is called to pass the buffer to pstore filesystem during it. And then, it causes a following lockdep warning. To make the dynamic memory allocation runnable without taking spinlock, holding off a deletion of sysfs entry if it happens while scanning it via efi_pstore, and deleting it after the scan is completed. To implement it, this patch introduces two flags, scanning and deleting, to efivar_entry. [1.143710] [ cut here ] [1.144058] WARNING: CPU: 1 PID: 1 at kernel/lockdep.c:2740 lockdep_trace_alloc+0x104/0x110() [1.144058] DEBUG_LOCKS_WARN_ON(irqs_disabled_flags(flags)) [1.144058] Modules linked in: [1.144058] CPU: 1 PID: 1 Comm: systemd Not tainted 3.11.0-rc5 #2 [1.144058] 0009 8800797e9ae0 816614a5 8800797e9b28 [1.144058] 8800797e9b18 8105510d 0080 0046 [1.144058] 00d0 03af 81ccd0c0 8800797e9b78 [1.144058] Call Trace: [1.144058] [816614a5] dump_stack+0x54/0x74 [1.144058] [8105510d] warn_slowpath_common+0x7d/0xa0 [1.144058] [8105517c] warn_slowpath_fmt+0x4c/0x50 [1.144058] [8131290f] ? vsscanf+0x57f/0x7b0 [1.144058] [810bbd74] lockdep_trace_alloc+0x104/0x110 [1.144058] [81192da0] __kmalloc_track_caller+0x50/0x280 [1.144058] [815147bb] ? efi_pstore_read_func.part.1+0x12b/0x170 [1.144058] [8115b260] kmemdup+0x20/0x50 [1.144058] [815147bb] efi_pstore_read_func.part.1+0x12b/0x170 [1.144058] [81514800] ? efi_pstore_read_func.part.1+0x170/0x170 [1.144058] [815148b4] efi_pstore_read_func+0xb4/0xe0 [1.144058] [81512b7b] __efivar_entry_iter+0xfb/0x120 [1.144058] [8151428f] efi_pstore_read+0x3f/0x50 [1.144058] [8128d7ba] pstore_get_records+0x9a/0x150 [1.158207] [812af25c] ? selinux_d_instantiate+0x1c/0x20 [1.158207] [8128ce30] ? parse_options+0x80/0x80 [1.158207] [8128ced5]
Re: [PATCH] perf, x86: Optimize intel_pmu_pebs_fixup_ip()
On Thu, Oct 17, 2013 at 05:09:44PM +0200, Peter Zijlstra wrote: The patches you find in: http://programming.kicks-ass.net/sekrit/patches.tar.bz2 # sha256sum patches.tar.bz2 28e26d4a20004eee231a4c0c6067508a322241046b400a226af1cceed8854bfb patches.tar.bz2 -- 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 1/7] arm64: introduce basic aarch64 instruction decoding helpers
Hi Will,
Thanks for review and will make those small changes.
Gerry
On 10/17/2013 06:47 PM, Will Deacon wrote:
On Thu, Oct 17, 2013 at 07:19:34AM +0100, Jiang Liu wrote:
From: Jiang Liu jiang@huawei.com
Introduce basic aarch64 instruction decoding helper
aarch64_get_insn_class() and aarch64_insn_hotpatch_safe().
Signed-off-by: Jiang Liu jiang@huawei.com
Cc: Jiang Liu liu...@gmail.com
---
arch/arm64/include/asm/insn.h | 67
arch/arm64/kernel/Makefile| 2 +-
arch/arm64/kernel/insn.c | 72
+++
3 files changed, 140 insertions(+), 1 deletion(-)
create mode 100644 arch/arm64/include/asm/insn.h
create mode 100644 arch/arm64/kernel/insn.c
diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
new file mode 100644
index 000..6190016
--- /dev/null
+++ b/arch/arm64/include/asm/insn.h
@@ -0,0 +1,67 @@
+/*
+ * Copyright (C) 2013 Huawei Ltd.
+ * Author: Jiang Liu jiang@huawei.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program. If not, see http://www.gnu.org/licenses/.
+ */
+#ifndef _ASM_ARM64_INSN_H
+#define _ASM_ARM64_INSN_H
We've tried to be consistent using __ASM_name_H here.
+#include linux/types.h
+
+/*
+ * ARM Architecture Reference Manual ARMv8, Section C3.1
+ * AArch64 main encoding table
+ * Bit position
+ * 28 27 26 25Encoding Group
+ * 0 0 - - Unallocated
+ * 1 0 0 - Data processing, immediate
+ * 1 0 1 - Branch, exception generation and system
instructions
+ * - 1 - 0 Loads and stores
+ * - 1 0 1 Data processing - register
+ * 0 1 1 1 Data processing - SIMD and floating point
+ * 1 1 1 1 Data processing - SIMD and floating point
+ * - means don't care
+ */
+enum aarch64_insn_encoding_class {
+AARCH64_INSN_CLS_UNKNOWN, /* UNALLOCATED */
+AARCH64_INSN_CLS_DP_IMM,/* Data processing - immediate */
+AARCH64_INSN_CLS_DP_REG,/* Data processing - register */
+AARCH64_INSN_CLS_DP_FPSIMD, /* Data processing - SIMD and FP */
+AARCH64_INSN_CLS_LDST, /* Loads and stores */
+AARCH64_INSN_CLS_BR_SYS,/* Branch, exception generation and
+ * system instructions */
+};
+
+#define __AARCH64_INSN_FUNCS(abbr, mask, val) \
+static __always_inline bool aarch64_insn_is_##abbr(u32 code) \
+{ return (code (mask)) == (val); }\
+static __always_inline u32 aarch64_insn_get_##abbr##_mask(void) \
+{ return (mask); } \
+static __always_inline u32 aarch64_insn_get_##abbr##_value(void) \
+{ return (val); }
+
+__AARCH64_INSN_FUNCS(b, 0xFC00, 0x1400)
+__AARCH64_INSN_FUNCS(bl,0xFC00, 0x9400)
+__AARCH64_INSN_FUNCS(svc, 0xFFE0001F, 0xD401)
+__AARCH64_INSN_FUNCS(hvc, 0xFFE0001F, 0xD402)
+__AARCH64_INSN_FUNCS(smc, 0xFFE0001F, 0xD403)
+__AARCH64_INSN_FUNCS(brk, 0xFFE0001F, 0xD420)
+__AARCH64_INSN_FUNCS(nop, 0x, 0xD503201F)
+
+#undef __AARCH64_INSN_FUNCS
+
+enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn);
+
+bool aarch64_insn_hotpatch_safe(u32 old_insn, u32 new_insn);
+
+#endif /* _ASM_ARM64_INSN_H */
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 7b4b564..9af6cb3 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -9,7 +9,7 @@ AFLAGS_head.o:= -DTEXT_OFFSET=$(TEXT_OFFSET)
arm64-obj-y := cputable.o debug-monitors.o entry.o irq.o fpsimd.o
\
entry-fpsimd.o process.o ptrace.o setup.o signal.o
\
sys.o stacktrace.o time.o traps.o io.o vdso.o
\
- hyp-stub.o psci.o
+ hyp-stub.o psci.o insn.o
arm64-obj-$(CONFIG_COMPAT) += sys32.o kuser32.o signal32.o
\
sys_compat.o
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
new file mode 100644
index 000..1c501f3
--- /dev/null
+++ b/arch/arm64/kernel/insn.c
@@ -0,0 +1,72 @@
+/*
+ * Copyright (C) 2013 Huawei Ltd.
+ * Author: Jiang Liu jiang@huawei.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU
Re: [PATCH v4 2/7] arm64: introduce interfaces to hotpatch kernel and module code
On Thu, 2013-10-17 at 12:38 +0100, Will Deacon wrote:
[adding Tixy for stop_machine() question below]
On Thu, Oct 17, 2013 at 07:19:35AM +0100, Jiang Liu wrote:
[...]
+int __kprobes aarch64_insn_patch_text_sync(void *addrs[], u32 insns[], int
cnt)
+{
+ struct aarch64_insn_patch patch = {
+ .text_addrs = addrs,
+ .new_insns = insns,
+ .insn_cnt = cnt,
+ };
+
+ if (cnt = 0)
+ return -EINVAL;
+
+ /*
+* Execute __aarch64_insn_patch_text() on every online CPU,
+* which ensure serialization among all online CPUs.
+*/
+ return stop_machine(aarch64_insn_patch_text_cb, patch, NULL);
+}
Whoa, whoa, whoa! The comment here is wrong -- we only run the patching on
*one* CPU, which is the right thing to do. However, the arch/arm/ call to
stop_machine in kprobes does actually run the patching code on *all* the
online cores (including the cache flushing!). I think this is to work around
cores without hardware cache maintenance broadcasting, but that could easily
be called out specially (like we do in patch.c) and the flushing could be
separated from the patching too.
[...]
For code modifications done in 32bit ARM kprobes (and ftrace) I'm not
sure we ever actually resolved the possible cache flushing issues. If
there was specific reasons for flushing on all cores I can't remember
them, sorry. I have a suspicion that doing so was a case of sticking
with what the code was already doing, and flushing on all cores seemed
safest to guard against problems we hadn't thought about.
Some of the issues discussed were that we couldn't have one core
potentially executing instructions being modified by another CPU,
because that's architecturally unpredictable except for a few
instructions [1], and we also have the case where a 32-bit Thumb
instruction can straddle two different cache-lines. But these may not be
reasons to flush on all cores if stop machine is synchronising all CPU's
in a kind of holding pen and the cache operations done on one core are
broadcast to others. (Are there correct barriers involved in
stop-machine so that when the other cores resume they are guaranteed to
only see the new version of the modified code, or do we only get that
guarantee because we happen to execute the cache flushing on all cores?)
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2012-December/136441.html
Another of the issues I hit was big.LITTLE related whereby the cache
line size is different on different cores [2].
[2]
http://lists.infradead.org/pipermail/linux-arm-kernel/2013-February/149794.html
I don't think anything I've said above actually gives a solid reason why
we _must_ execute cache flushing on all cores for kprobes and can't just
use the relatively new patch_text function (which checks for the one
case we do need to flush on all cores using cache_ops_need_broadcast).
Sorry, I don't think I've added much light on things here have I?
--
Tixy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/9] Extended H/W error log driver
On Thu, 17 Oct 2013 10:33:48 -0400 Chen Gong gong.c...@linux.intel.com wrote: Gong, can you try moving the CREATE_TRACE_POINTS line to a new file - arch/x86/ras/ras.c and define it there and not anywhere else, i.e. move it away from edac_mc.c. Does that help? In current kernel we haven't arch/x86/ras/ras.c. You mean I create a new one there and just add some trace macro definition? The CREATE_TRACE_POINTS will cause the TRACE_EVENT() macro to define the functions used for tracing. If you have it defined more than once, it will either cause a kernel compile error (variables declared more than once), or if used in modules, will cause confusion (as well as bloat) because different functions and variables will be defined for the same tracepoint. If you need to create a separate file that you can have it defined in a single place, then please do so! -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 6/7] arm64, jump label: optimize jump label implementation
On Thu, 17 Oct 2013 22:40:32 +0800 Jiang Liu liu...@gmail.com wrote: You could make the code more concise by limiting your patching ability to branch immediates. Then a nop is simply a branch to the next instruction (I doubt any modern CPUs will choke on this, whereas the architecture requires a NOP to take time). I guess a NOP should be more effecient than a B #4 on real CPUs:) Well, I was actually questioning that. A NOP *has* to take time (the architecture prevents implementations from discaring it) whereas a static, unconditional branch will likely be discarded early on by CPUs with even simple branch prediction logic. I naively thought NOP is cheaper than a B :( Will use a B #1 to replace NOP. Really?? What's the purpose of a NOP then? It seems to me that an architecture is broken if a NOP is slower than a static branch. -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] (Was: perf_event_mmap(vma) !vma-vm_mm)
On 10/16, Peter Zijlstra wrote:
On Wed, Oct 16, 2013 at 10:58:00PM +0200, Oleg Nesterov wrote:
OK. I'll wait for your review on this series, then send the next patch.
Those two patches look good; thanks.
Thanks, can I have your acks for Ingo ?
How about something like so on top?
---
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5103,18 +5103,16 @@ static void perf_event_mmap_event(struct
struct file *file = vma-vm_file;
int maj = 0, min = 0;
u64 ino = 0, gen = 0;
- unsigned int size;
+ unsigned int size, len;
char tmp[16];
char *buf = NULL;
const char *name;
- memset(tmp, 0, sizeof(tmp));
-
if (file) {
struct inode *inode;
dev_t dev;
- buf = kzalloc(PATH_MAX, GFP_KERNEL);
+ buf = kmalloc(PATH_MAX, GFP_KERNEL);
if (!buf) {
name = strncpy(tmp, //enomem, sizeof(tmp));
goto got_name;
@@ -5160,7 +5158,15 @@ static void perf_event_mmap_event(struct
}
got_name:
- size = ALIGN(strlen(name)+1, sizeof(u64));
+ /*
+ * Since our buffer works in 8 byte units we need to align our string
+ * size to a multiple of 8. However, we must guarantee the tail end is
+ * zero'd out to avoid leaking random bits to userspace.
+ */
+ len = strlen(name)+1;
+ size = ALIGN(len, sizeof(u64));
+ for (; len size; len++)
+ name[len] = '\0';
Yes, this is almost what I meant, but:
- name is const char *, we need another variable
- we do not really need len, we can simply do
size = strlen(name) + 1;
while (size % sizeof(u64))
name[size++] = '\0';
although I won't argue if you dislike size 7 in while().
- we can factor out strncpy(tmp, name).
Could you look at 3/2 I'll send in a minute?
Oleg.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/2] perf: Optimize the fill/align code in perf_event_mmap_event()
1. memset(tmp, 0) and especially kzalloc(PATH_MAX) are suboptimal,
we only need to zero-fill the alignment.
Remove this memset/__GFP_ZERO and fill the extra bytes by hand.
2. The usage of strncpy(tmp) is not optimal too, we can add the new
label and do this in one place.
Signed-off-by: Oleg Nesterov o...@redhat.com
---
kernel/events/core.c | 47 +++
1 files changed, 23 insertions(+), 24 deletions(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index 4a1e7b8..777a268 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -5098,20 +5098,17 @@ static void perf_event_mmap_event(struct
perf_mmap_event *mmap_event)
int maj = 0, min = 0;
u64 ino = 0, gen = 0;
unsigned int size;
- char tmp[16];
- char *buf = NULL;
- const char *name;
-
- memset(tmp, 0, sizeof(tmp));
+ char tmp[16], *name, *buf = NULL;
+ const char *str;
if (file) {
struct inode *inode;
dev_t dev;
- buf = kzalloc(PATH_MAX, GFP_KERNEL);
+ buf = kmalloc(PATH_MAX, GFP_KERNEL);
if (!buf) {
- name = strncpy(tmp, //enomem, sizeof(tmp));
- goto got_name;
+ str = //enomem;
+ goto cpy_name;
}
/*
* d_path works from the end of the rb backwards, so we
@@ -5120,8 +5117,8 @@ static void perf_event_mmap_event(struct perf_mmap_event
*mmap_event)
*/
name = d_path(file-f_path, buf, PATH_MAX - sizeof(u64));
if (IS_ERR(name)) {
- name = strncpy(tmp, //toolong, sizeof(tmp));
- goto got_name;
+ str = //toolong;
+ goto cpy_name;
}
inode = file_inode(vma-vm_file);
dev = inode-i_sb-s_dev;
@@ -5129,32 +5126,34 @@ static void perf_event_mmap_event(struct
perf_mmap_event *mmap_event)
gen = inode-i_generation;
maj = MAJOR(dev);
min = MINOR(dev);
-
+ goto got_name;
} else {
- name = arch_vma_name(vma);
- if (name) {
- name = strncpy(tmp, name, sizeof(tmp) - 1);
- tmp[sizeof(tmp) - 1] = '\0';
- goto got_name;
- }
+ str = arch_vma_name(vma);
+ if (str)
+ goto cpy_name;
if (vma-vm_start = vma-vm_mm-start_brk
vma-vm_end = vma-vm_mm-brk) {
- name = strncpy(tmp, [heap], sizeof(tmp));
- goto got_name;
+ str = [heap];
+ goto cpy_name;
}
if (vma-vm_start = vma-vm_mm-start_stack
vma-vm_end = vma-vm_mm-start_stack) {
- name = strncpy(tmp, [stack], sizeof(tmp));
- goto got_name;
+ str = [stack];
+ goto cpy_name;
}
- name = strncpy(tmp, //anon, sizeof(tmp));
- goto got_name;
+ str = //anon;
+ goto cpy_name;
}
+cpy_name:
+ strlcpy(tmp, str, sizeof(tmp));
+ name = tmp;
got_name:
- size = ALIGN(strlen(name)+1, sizeof(u64));
+ size = strlen(name) + 1;
+ while (size % sizeof(u64))
+ name[size++] = '\0';
mmap_event-file_name = name;
mmap_event-file_size = size;
--
1.5.5.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] ARM: pinctrl: Add Broadcom Capri pinctrl driver
On Thu, Oct 17, 2013 at 7:54 AM, Stephen Warren swar...@wwwdotorg.org wrote: On 10/17/2013 12:03 AM, Christian Daudt wrote: On Thu, Oct 3, 2013 at 5:23 PM, Sherman Yin s...@broadcom.com wrote: Adds pinctrl driver for Broadcom Capri (BCM281xx) SoCs. Signed-off-by: Sherman Yin s...@broadcom.com Reviewed-by: Christian Daudt b...@fixthebug.org Reviewed-by: Matt Porter matt.por...@linaro.org --- arch/arm/mach-bcm/Kconfig |2 + drivers/pinctrl/Kconfig | 10 + drivers/pinctrl/Makefile|1 + drivers/pinctrl/pinctrl-capri.c | 1727 +++ 4 files changed, 1740 insertions(+) create mode 100644 drivers/pinctrl/pinctrl-capri.c diff --git a/arch/arm/mach-bcm/Kconfig b/arch/arm/mach-bcm/Kconfig index 69d67f7..2546365 100644 --- a/arch/arm/mach-bcm/Kconfig +++ b/arch/arm/mach-bcm/Kconfig @@ -10,6 +10,8 @@ config ARCH_BCM select GENERIC_CLOCKEVENTS select GENERIC_TIME select GPIO_BCM + select PINCTRL + select PINCTRL_CAPRI select SPARSE_IRQ select TICK_ONESHOT select CACHE_L2X0 On your subsequent patchset pls move this from Kconfig to arm/configs/bcm_defconfig, and break that modification into a separate patch from the drivers/* modification. The other SoCs I'm familiar with all select this from their ARCH_xxx config symbol. I had a discussion on what is best left under ARCH and what is best left to defconfig with Kevin Hilman a while back and the conclusion was that any config not strictly required for bootup is best left to defconfig. This will allow multiplatform kernels to switch to using them as loadable modules later on, something not possible with configs put under ARCH_xxx. Thanks, csd -- 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] tty/serial: at91: add a fallback option to determine uart/usart property
On 17/10/2013 16:13, Greg Kroah-Hartman :
On Thu, Oct 17, 2013 at 10:16:47AM +0200, Nicolas Ferre wrote:
On 16/10/2013 22:14, Greg Kroah-Hartman :
On Tue, Oct 15, 2013 at 11:19:18AM +0200, Nicolas Ferre wrote:
On 14/10/2013 15:59, Jean-Christophe PLAGNIOL-VILLARD :
On 10:43 Thu 10 Oct , Nicolas Ferre wrote:
On older SoC, the name field is not filled in the register map.
Fix the way to figure out if the serial port is an uart or an usart for these
older products (with corresponding properties).
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
---
drivers/tty/serial/atmel_serial.c | 19 ++-
include/linux/atmel_serial.h | 1 +
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/atmel_serial.c
b/drivers/tty/serial/atmel_serial.c
index 6b0f75e..c7d99af 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -99,6 +99,7 @@ static void atmel_stop_rx(struct uart_port *port);
#define UART_PUT_RTOR(port,v)__raw_writel(v, (port)-membase +
ATMEL_US_RTOR)
#define UART_PUT_TTGR(port, v) __raw_writel(v, (port)-membase +
ATMEL_US_TTGR)
#define UART_GET_IP_NAME(port) __raw_readl((port)-membase +
ATMEL_US_NAME)
+#define UART_GET_IP_VERSION(port) __raw_readl((port)-membase +
ATMEL_US_VERSION)
/* PDC registers */
#define UART_PUT_PTCR(port,v)__raw_writel(v, (port)-membase +
ATMEL_PDC_PTCR)
@@ -1503,6 +1504,7 @@ static void atmel_get_ip_name(struct uart_port *port)
{
struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
int name = UART_GET_IP_NAME(port);
+ u32 version;
int usart, uart;
/* usart and uart ascii */
usart = 0x55534152;
@@ -1517,7 +1519,22 @@ static void atmel_get_ip_name(struct uart_port *port)
dev_dbg(port-dev, This is uart\n);
atmel_port-is_usart = false;
} else {
- dev_err(port-dev, Not supported ip name, set to uart\n);
+ /* fallback for older SoCs: use version field */
+ version = UART_GET_IP_VERSION(port);
+ switch (version) {
+ case 0x302:
+ case 0x10213:
+ dev_dbg(port-dev, This version is usart\n);
+ atmel_port-is_usart = true;
+ break;
+ case 0x203:
+ case 0x10202:
+ dev_dbg(port-dev, This version is uart\n);
+ atmel_port-is_usart = false;
+ break;
+ default:
+ dev_err(port-dev, Not supported ip name nor version, set
to uart\n);
it's not really an error a dev_warn is more oppropriate
As we are already in -rc5 and that these fixes are critical for at91
platforms, I will not re-spin another patch just for this.
Moreover, I have the feeling that if we end up in this case, it
means that we are in big troubles because the usart/uart included in
the product triggering this log is not known (I recall that newer
products do not have to hit these lines of code).
With these 2 reasons, I prefer to keep my patch like it is.
Greg, can you consider taking these two patches as regression fixes
for 3.12 (with Tested-by tag from Thomas)?
Is this really a regression from 3.11?
Yes it is. Commit id that I am referring to in patch 1/2
(055560b04a8cd063aea916fd083b7aec02c2adb8) hit the mainline in 3.12-rc
time-frame.
Ok.
What's the worry about waiting
for 3.13-rc1, getting this correct, and then backporting them to the
3.12-stable trees?
It will break all older at91 in 3.12-final. Moreover, I do think that
the actual patches are bringing an incorrect solution and I do not plan
to have a better one (which one?) for 3.13...
I'd prefer that, so, please clean this up properly and resend it, with
the tested-by: lines and I'll queue them up for 3.13-rc1.
I do not know what to cleanup. Anyway, tell me if you want that I resend
the series of 2 patches with the Tested-by tag included.
I thought there was some dev_warn() changes that were asked for...
Asked for, but I do not agree (my arguments above).
Anyway, please resend them if you want me to take them for any tree as I
no longer have them in my queue.
Okay, I re-send you them right now.
Thanks, bye,
--
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 0/2] (Was: perf_event_mmap(vma) !vma-vm_mm)
On 10/17, Oleg Nesterov wrote: - we do not really need len, we can simply do size = strlen(name) + 1; while (size % sizeof(u64)) name[size++] = '\0'; although I won't argue if you dislike size 7 in while(). Or, perhaps, while (!IS_ALIGNED(size, sizeof(u64))) name[size++] = '\0'; to make it self-explanatory. Oleg. -- 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] kmod: Run usermodehelpers only on cpus allowed for kthreadd
On Thu, 17 Oct 2013, Frederic Weisbecker wrote: - /* We can run anywhere, unlike our parent keventd(). */ - set_cpus_allowed_ptr(current, cpu_all_mask); + /* We can run anywhere kthreadd can run */ + set_kthreadd_affinity(); If you really want your isolated CPUs to be undisturbed, you need this affinity to be set before the creation of this usermode helper. Otherwise it's going to run to any random place before you call the above function. Is there now way to control the kworker affinity which create this usermode helpers threads instead? The invocation is coming from keventd so the affinity seems to be set to a different cpu before we get the thread moved. A tsc loop is running on the processor that gets hit by the usermodehelper spawns. We see spawning by the tty notifier (when typing on a vt) as well as by a mellanox driver (periodically). -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/9] Extended H/W error log driver
On Thu, Oct 17, 2013 at 11:25:41AM -0400, Steven Rostedt wrote: On Thu, 17 Oct 2013 10:33:48 -0400 Chen Gong gong.c...@linux.intel.com wrote: Gong, can you try moving the CREATE_TRACE_POINTS line to a new file - arch/x86/ras/ras.c and define it there and not anywhere else, i.e. move it away from edac_mc.c. Does that help? In current kernel we haven't arch/x86/ras/ras.c. You mean I create a new one there and just add some trace macro definition? The CREATE_TRACE_POINTS will cause the TRACE_EVENT() macro to define the functions used for tracing. If you have it defined more than once, it will either cause a kernel compile error (variables declared more than once), or if used in modules, will cause confusion (as well as bloat) because different functions and variables will be defined for the same tracepoint. If you need to create a separate file that you can have it defined in a single place, then please do so! Yes, the plan was this all along to have arch/x86/ras/ras.c or arch/x86/ras/core.c where CREATE_TRACE_POINTS is done, among other things. Btw, Gong, there's an easier way to test this, if you wanna: simply make sure EDAC is disabled in the kernel with your patches - i.e., CONFIG_EDAC is not set in your config. It should work then. But, the final solution should be what Steve says with the file I'm suggesting :) Thanks. -- 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 RESEND 1/2] tty/serial: at91: fix uart/usart selection for older products
Since commit 055560b04a8cd063aea916fd083b7aec02c2adb8 (serial: at91:
distinguish usart and uart) the older products which do not have a
name field in their register map are unable to use their serial output.
As the main console output is usually the serial interface (aka DBGU) it
is pretty unfortunate.
So, instead of failing during probe() we just silently configure the serial
peripheral as an uart. It allows us to use these serial outputs.
The proper solution is proposed in another patch.
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
---
drivers/tty/serial/atmel_serial.c | 9 ++---
1 file changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/tty/serial/atmel_serial.c
b/drivers/tty/serial/atmel_serial.c
index d067285..6b0f75e 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -1499,7 +1499,7 @@ static void atmel_set_ops(struct uart_port *port)
/*
* Get ip name usart or uart
*/
-static int atmel_get_ip_name(struct uart_port *port)
+static void atmel_get_ip_name(struct uart_port *port)
{
struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
int name = UART_GET_IP_NAME(port);
@@ -1518,10 +1518,7 @@ static int atmel_get_ip_name(struct uart_port *port)
atmel_port-is_usart = false;
} else {
dev_err(port-dev, Not supported ip name, set to uart\n);
- return -EINVAL;
}
-
- return 0;
}
/*
@@ -2405,9 +2402,7 @@ static int atmel_serial_probe(struct platform_device
*pdev)
/*
* Get port name of usart or uart
*/
- ret = atmel_get_ip_name(port-uart);
- if (ret 0)
- goto err_add_port;
+ atmel_get_ip_name(port-uart);
return 0;
--
1.8.2.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 RESEND 2/2] tty/serial: at91: add a fallback option to determine uart/usart property
On older SoC, the name field is not filled in the register map.
Fix the way to figure out if the serial port is an uart or an usart for these
older products (with corresponding properties).
Signed-off-by: Nicolas Ferre nicolas.fe...@atmel.com
---
drivers/tty/serial/atmel_serial.c | 19 ++-
include/linux/atmel_serial.h | 1 +
2 files changed, 19 insertions(+), 1 deletion(-)
diff --git a/drivers/tty/serial/atmel_serial.c
b/drivers/tty/serial/atmel_serial.c
index 6b0f75e..c7d99af 100644
--- a/drivers/tty/serial/atmel_serial.c
+++ b/drivers/tty/serial/atmel_serial.c
@@ -99,6 +99,7 @@ static void atmel_stop_rx(struct uart_port *port);
#define UART_PUT_RTOR(port,v) __raw_writel(v, (port)-membase + ATMEL_US_RTOR)
#define UART_PUT_TTGR(port, v) __raw_writel(v, (port)-membase + ATMEL_US_TTGR)
#define UART_GET_IP_NAME(port) __raw_readl((port)-membase + ATMEL_US_NAME)
+#define UART_GET_IP_VERSION(port) __raw_readl((port)-membase +
ATMEL_US_VERSION)
/* PDC registers */
#define UART_PUT_PTCR(port,v) __raw_writel(v, (port)-membase +
ATMEL_PDC_PTCR)
@@ -1503,6 +1504,7 @@ static void atmel_get_ip_name(struct uart_port *port)
{
struct atmel_uart_port *atmel_port = to_atmel_uart_port(port);
int name = UART_GET_IP_NAME(port);
+ u32 version;
int usart, uart;
/* usart and uart ascii */
usart = 0x55534152;
@@ -1517,7 +1519,22 @@ static void atmel_get_ip_name(struct uart_port *port)
dev_dbg(port-dev, This is uart\n);
atmel_port-is_usart = false;
} else {
- dev_err(port-dev, Not supported ip name, set to uart\n);
+ /* fallback for older SoCs: use version field */
+ version = UART_GET_IP_VERSION(port);
+ switch (version) {
+ case 0x302:
+ case 0x10213:
+ dev_dbg(port-dev, This version is usart\n);
+ atmel_port-is_usart = true;
+ break;
+ case 0x203:
+ case 0x10202:
+ dev_dbg(port-dev, This version is uart\n);
+ atmel_port-is_usart = false;
+ break;
+ default:
+ dev_err(port-dev, Not supported ip name nor version,
set to uart\n);
+ }
}
}
diff --git a/include/linux/atmel_serial.h b/include/linux/atmel_serial.h
index be201ca..00beddf 100644
--- a/include/linux/atmel_serial.h
+++ b/include/linux/atmel_serial.h
@@ -125,5 +125,6 @@
#define ATMEL_US_IF0x4c/* IrDA Filter Register
*/
#define ATMEL_US_NAME 0xf0/* Ip Name */
+#define ATMEL_US_VERSION 0xfc/* Ip Version */
#endif
--
1.8.2.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] [CRYPTO] kconfig: Corrected a typo
Corrected a typo in option description in Kconfig Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=60848 Signed-off-by: Siddharth Goel siddharth98...@gmail.com --- crypto/Kconfig |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/crypto/Kconfig b/crypto/Kconfig index 69ce573..84698cf 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -1084,7 +1084,7 @@ config CRYPTO_SERPENT Keys are allowed to be from 0 to 256 bits in length, in steps of 8 bits. Also includes the 'Tnepres' algorithm, a reversed - variant of Serpent for compatibility with old kerneli.org code. + variant of Serpent for compatibility with old kernel.org code. See also: http://www.cl.cam.ac.uk/~rja14/serpent.html -- 1.7.0.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 v4 2/7] arm64: introduce interfaces to hotpatch kernel and module code
On 10/17/2013 07:38 PM, Will Deacon wrote:
[adding Tixy for stop_machine() question below]
On Thu, Oct 17, 2013 at 07:19:35AM +0100, Jiang Liu wrote:
From: Jiang Liu jiang@huawei.com
Introduce three interfaces to patch kernel and module code:
aarch64_insn_patch_text_nosync():
patch code without synchronization, it's caller's responsibility
to synchronize all CPUs if needed.
aarch64_insn_patch_text_sync():
patch code and always synchronize with stop_machine()
aarch64_insn_patch_text():
patch code and synchronize with stop_machine() if needed
Signed-off-by: Jiang Liu jiang@huawei.com
Cc: Jiang Liu liu...@gmail.com
---
arch/arm64/include/asm/insn.h | 24 +-
arch/arm64/kernel/insn.c | 77
+++
2 files changed, 100 insertions(+), 1 deletion(-)
diff --git a/arch/arm64/include/asm/insn.h b/arch/arm64/include/asm/insn.h
index 6190016..fc439b9 100644
--- a/arch/arm64/include/asm/insn.h
+++ b/arch/arm64/include/asm/insn.h
@@ -60,8 +60,30 @@ __AARCH64_INSN_FUNCS(nop, 0x, 0xD503201F)
#undef __AARCH64_INSN_FUNCS
-enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn);
+/*
+ * In ARMv8-A, A64 instructions have a fixed length of 32 bits and are
always
+ * little-endian. On the other hand, SCTLR_EL1.EE (bit 25, Exception
Endianness)
+ * flag controls endianness for EL1 explicit data accesses and stage 1
+ * translation table walks as below:
+ * 0: little-endian
+ * 1: big-endian
+ * So need to handle endianness when patching kernel code.
+ */
You can delete this comment now that we're using the helpers...
+static __always_inline u32 aarch64_insn_read(void *addr)
+{
+return le32_to_cpu(*(u32 *)addr);
+}
+static __always_inline void aarch64_insn_write(void *addr, u32 insn)
+{
+*(u32 *)addr = cpu_to_le32(insn);
+}
... then just inline these calls directly.
+enum aarch64_insn_encoding_class aarch64_get_insn_class(u32 insn);
bool aarch64_insn_hotpatch_safe(u32 old_insn, u32 new_insn);
+int aarch64_insn_patch_text_nosync(void *addrs[], u32 insns[], int cnt);
+int aarch64_insn_patch_text_sync(void *addrs[], u32 insns[], int cnt);
+int aarch64_insn_patch_text(void *addrs[], u32 insns[], int cnt);
+
#endif /* _ASM_ARM64_INSN_H */
diff --git a/arch/arm64/kernel/insn.c b/arch/arm64/kernel/insn.c
index 1c501f3..8dd5fbe 100644
--- a/arch/arm64/kernel/insn.c
+++ b/arch/arm64/kernel/insn.c
@@ -16,6 +16,9 @@
*/
#include linux/compiler.h
#include linux/kernel.h
+#include linux/smp.h
+#include linux/stop_machine.h
+#include asm/cacheflush.h
#include asm/insn.h
static int aarch64_insn_encoding_cls[] = {
@@ -70,3 +73,77 @@ bool __kprobes aarch64_insn_hotpatch_safe(u32 old_insn,
u32 new_insn)
return __aarch64_insn_hotpatch_safe(old_insn)
__aarch64_insn_hotpatch_safe(new_insn);
}
+
+int __kprobes aarch64_insn_patch_text_nosync(void *addrs[], u32 insns[],
+ int cnt)
+{
+int i;
+u32 *tp;
+
+if (cnt = 0)
+return -EINVAL;
Isn't cnt always 1 for the _nosync patching? Can you just drop the argument
and simplify this code? Patching a sequence without syncing is always racy.
Will drop the third parameter and simplify the code.
+for (i = 0; i cnt; i++) {
+tp = addrs[i];
+/* A64 instructions must be word aligned */
+if ((uintptr_t)tp 0x3)
+return -EINVAL;
+aarch64_insn_write(tp, insns[i]);
+flush_icache_range((uintptr_t)tp, (uintptr_t)tp + sizeof(u32));
+}
+
+return 0;
+}
+
+struct aarch64_insn_patch {
+void**text_addrs;
+u32 *new_insns;
+int insn_cnt;
+};
+
+static int __kprobes aarch64_insn_patch_text_cb(void *arg)
+{
+struct aarch64_insn_patch *pp = arg;
+
+return aarch64_insn_patch_text_nosync(pp-text_addrs, pp-new_insns,
+ pp-insn_cnt);
+}
+
+int __kprobes aarch64_insn_patch_text_sync(void *addrs[], u32 insns[], int
cnt)
+{
+struct aarch64_insn_patch patch = {
+.text_addrs = addrs,
+.new_insns = insns,
+.insn_cnt = cnt,
+};
+
+if (cnt = 0)
+return -EINVAL;
+
+/*
+ * Execute __aarch64_insn_patch_text() on every online CPU,
+ * which ensure serialization among all online CPUs.
+ */
+return stop_machine(aarch64_insn_patch_text_cb, patch, NULL);
+}
Whoa, whoa, whoa! The comment here is wrong -- we only run the patching on
*one* CPU, which is the right thing to do. However, the arch/arm/ call to
stop_machine in kprobes does actually run the patching code on *all* the
online cores (including the cache flushing!). I think this is to work around
cores without hardware cache maintenance broadcasting, but that could easily
be called
[PATCH v3] sound: pci: emu10k1: code refactoring and casting removal
Partially restructures _snd_emu10k1_audigy_init_efx() and
_snd_emu10k1_init_efx() functions.
Removes useless casting (void *) from value returned by kcalloc;
see Documentation/CodingStyle, Chap 14.
Signed-off-by: Geyslan G. Bem geys...@gmail.com
---
sound/pci/emu10k1/emufx.c | 76 ---
1 file changed, 45 insertions(+), 31 deletions(-)
diff --git a/sound/pci/emu10k1/emufx.c b/sound/pci/emu10k1/emufx.c
index 0275209..6c45714 100644
--- a/sound/pci/emu10k1/emufx.c
+++ b/sound/pci/emu10k1/emufx.c
@@ -1182,15 +1182,20 @@ static int _snd_emu10k1_audigy_init_efx(struct
snd_emu10k1 *emu)
u32 *gpr_map;
mm_segment_t seg;
- if ((icode = kzalloc(sizeof(*icode), GFP_KERNEL)) == NULL ||
- (icode-gpr_map = (u_int32_t __user *)
-kcalloc(512 + 256 + 256 + 2 * 1024, sizeof(u_int32_t),
-GFP_KERNEL)) == NULL ||
- (controls = kcalloc(SND_EMU10K1_GPR_CONTROLS,
- sizeof(*controls), GFP_KERNEL)) == NULL) {
- err = -ENOMEM;
- goto __err;
- }
+ err = -ENOMEM;
+ icode = kzalloc(sizeof(*icode), GFP_KERNEL);
+ if (!icode)
+ return err;
+
+ icode-gpr_map = (__user) kcalloc(512 + 256 + 256 + 2 * 1024,
+ sizeof(u_int32_t), GFP_KERNEL);
+ if (!icode-gpr_map)
+ goto __err_gpr;
+ controls = kcalloc(SND_EMU10K1_GPR_CONTROLS,
+ sizeof(*controls), GFP_KERNEL);
+ if (!controls)
+ goto __err_ctrls;
+
gpr_map = (u32 __force *)icode-gpr_map;
icode-tram_data_map = icode-gpr_map + 512;
@@ -1741,12 +1746,12 @@ A_OP(icode, ptr, iMAC0, A_GPR(var), A_GPR(var),
A_GPR(vol), A_EXTIN(input))
emu-support_tlv = 0; /* clear again */
snd_leave_user(seg);
- __err:
+__err:
kfree(controls);
- if (icode != NULL) {
- kfree((void __force *)icode-gpr_map);
- kfree(icode);
- }
+__err_ctrls:
+ kfree((void __force *)icode-gpr_map);
+__err_gpr:
+ kfree(icode);
return err;
}
@@ -1813,18 +1818,26 @@ static int _snd_emu10k1_init_efx(struct snd_emu10k1
*emu)
u32 *gpr_map;
mm_segment_t seg;
- if ((icode = kzalloc(sizeof(*icode), GFP_KERNEL)) == NULL)
- return -ENOMEM;
- if ((icode-gpr_map = (u_int32_t __user *)
-kcalloc(256 + 160 + 160 + 2 * 512, sizeof(u_int32_t),
-GFP_KERNEL)) == NULL ||
-(controls = kcalloc(SND_EMU10K1_GPR_CONTROLS,
- sizeof(struct snd_emu10k1_fx8010_control_gpr),
- GFP_KERNEL)) == NULL ||
- (ipcm = kzalloc(sizeof(*ipcm), GFP_KERNEL)) == NULL) {
- err = -ENOMEM;
- goto __err;
- }
+ err = -ENOMEM;
+ icode = kzalloc(sizeof(*icode), GFP_KERNEL);
+ if (!icode)
+ return err;
+
+ icode-gpr_map = (__user) kcalloc(256 + 160 + 160 + 2 * 512,
+ sizeof(u_int32_t), GFP_KERNEL);
+ if (!icode-gpr_map)
+ goto __err_gpr;
+
+ controls = kcalloc(SND_EMU10K1_GPR_CONTROLS,
+ sizeof(struct snd_emu10k1_fx8010_control_gpr),
+ GFP_KERNEL);
+ if (!controls)
+ goto __err_ctrls;
+
+ ipcm = kzalloc(sizeof(*ipcm), GFP_KERNEL);
+ if (!ipcm)
+ goto __err_ipcm;
+
gpr_map = (u32 __force *)icode-gpr_map;
icode-tram_data_map = icode-gpr_map + 256;
@@ -2363,13 +2376,14 @@ static int _snd_emu10k1_init_efx(struct snd_emu10k1
*emu)
snd_leave_user(seg);
if (err = 0)
err = snd_emu10k1_ipcm_poke(emu, ipcm);
- __err:
+__err:
kfree(ipcm);
+__err_ipcm:
kfree(controls);
- if (icode != NULL) {
- kfree((void __force *)icode-gpr_map);
- kfree(icode);
- }
+__err_ctrls:
+ kfree((void __force *)icode-gpr_map);
+__err_gpr:
+ kfree(icode);
return err;
}
--
1.8.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: unify copy_from_user() checking
On 10/17/2013 2:45 AM, Jan Beulich wrote: Sure: Let's take __tun_chr_ioctl(): While a static function, it gets called with two different values for ifreq_len, both of which are provably (for a human) correct. I don't think, however, that the compiler can be expected to do so on its own in all cases - I would expect it to be able to when it decides to inline the function in both callers, but the larger that function grows, the more likely it'll become that the compiler chooses to keep it separate (and it surely would when CONFIG_CC_OPTIMIZE_FOR_SIZE). with multiple callers I would feel safer if there was a check inside the function. but this is a fair point (the function is large so indeed it is unlikely to get inlined) Otoh one would expect a modern compiler to be able to do the checking in the case of aer_inject_write(). Yet not everyone is using most recent compiler versions, but I personally expect a warning free compilation in that case too (at least outside the staging sub-tree, which I avoid to build as much as possible). And I know that I had seen the warning there (or else it wouldn't have caught my attention, and I wouldn't have quoted it in the patch description). if gcc doesn't find this one then arguably that's a gcc bug. (which is the thing that has been plaguing this feature unfortunately. in theory gcc should be able to cope with many of these in practice...) for me, the value of the feature overall is this range checking, not the fixed size part. for fixed size... the chance of the programmer getting it wrong is near zero. the chance of getting one of the checks wrong is much higher (we've had cases of wrong sign in the checks, off by ones in the checks etc) and that is what it was supposed to find. If that's not possible due practical issues (like the inline case above but more the compiler practicalities) removing the warning part entirely is likely just better. Having a runtime check for the case where the argument is not constant but we know the buffer size... is likely still clear value... cheap (perfect branch prediction unless disaster hits!) and the failure case is obviously the disaster case. -- 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 03/17] clk: at91: add PMC base support
On 11/10/2013 09:37, Boris BREZILLON :
This patch adds at91 PMC (Power Management Controller) base support.
All at91 clocks managed by the PMC unit will use this framework.
This framework provides the following fonctionalities:
- define a new struct at91_pmc to hide PMC internals (lock, PMC memory
mapping, irq domain, ...)
- read/write helper functions (pmc_read/write) to access PMC registers
- lock/unlock helper functions (pmc_lock/unlock) to lock/unlock access to
pmc registers
- a new irq domain and its associated irq chip to request PMC specific
interrupts (useful for clk prepare callbacks)
The PMC unit is declared as a dt clk provider (CLK_OF_DECLARE), and every
clk using this framework will declare a table of of_at91_clk_init_cb_t
and add it to the pmc_clk_ids table.
When the pmc dt clock setup function is called (by of_clk_init function),
it triggers the registration of every supported child clk (those matching
the definitions in pmc_clk_ids).
This patch copies at91_pmc_base (memory mapping) and at91sam9_idle
(function) from arch/arm/mach-at91/clock.c (which is not compiled if
COMMON_CLK_AT91 is enabled).
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
---
drivers/clk/Makefile |1 +
drivers/clk/at91/Makefile |5 +
drivers/clk/at91/pmc.c| 283 +
drivers/clk/at91/pmc.h| 58 ++
4 files changed, 347 insertions(+)
create mode 100644 drivers/clk/at91/Makefile
create mode 100644 drivers/clk/at91/pmc.c
create mode 100644 drivers/clk/at91/pmc.h
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index 7b11106..28c2678 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -32,6 +32,7 @@ obj-$(CONFIG_ARCH_VT8500) += clk-vt8500.o
obj-$(CONFIG_ARCH_ZYNQ) += zynq/
obj-$(CONFIG_ARCH_TEGRA) += tegra/
obj-$(CONFIG_PLAT_SAMSUNG)+= samsung/
+obj-$(CONFIG_COMMON_CLK_AT91) += at91/
obj-$(CONFIG_X86) += x86/
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
new file mode 100644
index 000..1d4fb21
--- /dev/null
+++ b/drivers/clk/at91/Makefile
@@ -0,0 +1,5 @@
+#
+# Makefile for at91 specific clk
+#
+
+obj-y += pmc.o
diff --git a/drivers/clk/at91/pmc.c b/drivers/clk/at91/pmc.c
new file mode 100644
index 000..d92e46c
--- /dev/null
+++ b/drivers/clk/at91/pmc.c
@@ -0,0 +1,283 @@
+/*
+ * drivers/clk/at91/pmc.c
+ *
+ * Copyright (C) 2013 Boris BREZILLON b.brezil...@overkiz.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include linux/clk-provider.h
+#include linux/clkdev.h
+#include linux/clk/at91_pmc.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/io.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/irqchip/chained_irq.h
+#include linux/irqdomain.h
+#include linux/of_irq.h
+
+#include asm/proc-fns.h
+
+#include pmc.h
+
+void __iomem *at91_pmc_base;
+EXPORT_SYMBOL_GPL(at91_pmc_base);
+
+void at91sam9_idle(void)
+{
+ at91_pmc_write(AT91_PMC_SCDR, AT91_PMC_PCK);
+ cpu_do_idle();
+}
+
+static void pmc_irq_mask(struct irq_data *d)
+{
+ struct at91_pmc *pmc = irq_data_get_irq_chip_data(d);
+
+ pmc_write(pmc, AT91_PMC_IDR, 1 d-hwirq);
+}
+
+static void pmc_irq_unmask(struct irq_data *d)
+{
+ struct at91_pmc *pmc = irq_data_get_irq_chip_data(d);
+
+ pmc_write(pmc, AT91_PMC_IER, 1 d-hwirq);
+}
+
+static int pmc_irq_set_type(struct irq_data *d, unsigned type)
+{
+ if (type != IRQ_TYPE_LEVEL_HIGH) {
+ pr_warn(PMC: type not supported (support only IRQ_TYPE_LEVEL_HIGH
type)\n);
+ return -EINVAL;
+ }
+
+ return 0;
+}
+
+static struct irq_chip pmc_irq = {
+ .name = PMC,
+ .irq_disable = pmc_irq_mask,
+ .irq_mask = pmc_irq_mask,
+ .irq_unmask = pmc_irq_unmask,
+ .irq_set_type = pmc_irq_set_type,
+};
+
+static struct lock_class_key pmc_lock_class;
+
+static int pmc_irq_map(struct irq_domain *h, unsigned int virq,
+ irq_hw_number_t hw)
+{
+ struct at91_pmc *pmc = h-host_data;
+
+ irq_set_lockdep_class(virq, pmc_lock_class);
+
+ irq_set_chip_and_handler(virq, pmc_irq,
+handle_level_irq);
+ set_irq_flags(virq, IRQF_VALID);
+ irq_set_chip_data(virq, pmc);
+
+ return 0;
+}
+
+static int pmc_irq_domain_xlate(struct irq_domain *d,
+ struct device_node *ctrlr,
+ const u32 *intspec, unsigned int intsize,
+ irq_hw_number_t *out_hwirq,
+ unsigned int *out_type)
+{
+ struct at91_pmc *pmc = d-host_data;
+ const
Re: [PATCH v4 04/17] clk: at91: add PMC macro file for dt definitions
On 11/10/2013 10:41, Boris BREZILLON : This patch adds a new macro file for PMC macros. This macro file includes the definitions of SR (status register) bit offsets and will be use to reference PMC irqs. Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com Acked-by: Nicolas Ferre nicolas.fe...@atmel.com --- include/dt-bindings/clk/at91.h | 22 ++ 1 file changed, 22 insertions(+) create mode 100644 include/dt-bindings/clk/at91.h diff --git a/include/dt-bindings/clk/at91.h b/include/dt-bindings/clk/at91.h new file mode 100644 index 000..0b4cb99 --- /dev/null +++ b/include/dt-bindings/clk/at91.h @@ -0,0 +1,22 @@ +/* + * This header provides constants for AT91 pmc status. + * + * The constants defined in this header are being used in dts. + * + * Licensed under GPLv2 or later. + */ + +#ifndef _DT_BINDINGS_CLK_AT91_H +#define _DT_BINDINGS_CLK_AT91_H + +#define AT91_PMC_MOSCS 0 /* MOSCS Flag */ +#define AT91_PMC_LOCKA 1 /* PLLA Lock */ +#define AT91_PMC_LOCKB 2 /* PLLB Lock */ +#define AT91_PMC_MCKRDY3 /* Master Clock */ +#define AT91_PMC_LOCKU 6 /* UPLL Lock */ +#define AT91_PMC_PCKRDY(id)(8 + (id)) /* Programmable Clock */ +#define AT91_PMC_MOSCSELS 16 /* Main Oscillator Selection */ +#define AT91_PMC_MOSCRCS 17 /* Main On-Chip RC */ +#define AT91_PMC_CFDEV 18 /* Clock Failure Detector Event */ + +#endif -- 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 v2 3/4] ARM: EXYNOS: add Exynos Dual Cluster Support
On Mon, Oct 14, 2013 at 07:08:24PM +0400, Vyacheslav Tyrtov wrote:
From: Tarek Dakhran t.dakh...@samsung.com
Add EDCS(Exynos Dual Cluster Support) for Samsung Exynos5410 SoC.
This enables all 8 cores, 4 x A7 and 4 x A15 run at the same time.
Signed-off-by: Tarek Dakhran t.dakh...@samsung.com
Signed-off-by: Vyacheslav Tyrtov v.tyr...@samsung.com
---
arch/arm/mach-exynos/Makefile | 2 +
arch/arm/mach-exynos/edcs.c | 270
++
2 files changed, 272 insertions(+)
create mode 100644 arch/arm/mach-exynos/edcs.c
diff --git a/arch/arm/mach-exynos/Makefile b/arch/arm/mach-exynos/Makefile
index 5369615..ba6efdb 100644
--- a/arch/arm/mach-exynos/Makefile
+++ b/arch/arm/mach-exynos/Makefile
@@ -34,3 +34,5 @@ AFLAGS_exynos-smc.o :=-Wa,-march=armv7-a$(plus_sec)
obj-$(CONFIG_MACH_EXYNOS4_DT)+= mach-exynos4-dt.o
obj-$(CONFIG_MACH_EXYNOS5_DT)+= mach-exynos5-dt.o
+
+obj-$(CONFIG_SOC_EXYNOS5410) += edcs.o
diff --git a/arch/arm/mach-exynos/edcs.c b/arch/arm/mach-exynos/edcs.c
new file mode 100644
index 000..e304bd9
--- /dev/null
+++ b/arch/arm/mach-exynos/edcs.c
@@ -0,0 +1,270 @@
+/*
+ * arch/arm/mach-exynos/edcs.c - exynos dual cluster power management support
+ *
+ * Copyright (c) 2013 Samsung Electronics Co., Ltd.
+ * Author: Tarek Dakhran t.dakh...@samsung.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * EDCS(exynos dual cluster support) for Exynos5410 SoC.
+ */
+
+#include linux/init.h
+#include linux/io.h
+#include linux/of_address.h
+#include linux/spinlock.h
+#include linux/errno.h
+
+#include asm/mcpm.h
+#include asm/proc-fns.h
+#include asm/cacheflush.h
+#include asm/cputype.h
+#include asm/cp15.h
+
+#include linux/arm-cci.h
+#include mach/regs-pmu.h
+
+#define EDCS_CPUS_PER_CLUSTER4
+#define EDCS_CLUSTERS2
+
+/* Exynos5410 power management registers */
+#define EDCS_CORE_CONFIGURATION(_nr) (S5P_ARM_CORE0_CONFIGURATION\
+ + ((_nr) * 0x80))
+#define EDCS_CORE_STATUS(_nr)(EDCS_CORE_CONFIGURATION(_nr) +
0x4)
+#define EDCS_CORE_OPTION(_nr)(EDCS_CORE_CONFIGURATION(_nr) +
0x8)
+
+#define REG_CPU_STATE_ADDR0 (S5P_VA_SYSRAM_NS + 0x28)
Is there any reason why S5P_VA_SYSRAM_NS needs to be a static mapping?
+#define REG_CPU_STATE_ADDR(_nr) (REG_CPU_STATE_ADDR0 + \
+ _nr * EDCS_CPUS_PER_CLUSTER)
+
+static arch_spinlock_t edcs_lock = __ARCH_SPIN_LOCK_UNLOCKED;
+
+static int edcs_use_count[EDCS_CPUS_PER_CLUSTER][EDCS_CLUSTERS];
+static int core_count[EDCS_CLUSTERS];
+
+static void exynos_core_power_control(unsigned int cpu, unsigned int cluster,
+ bool enable)
+{
+ unsigned int offset = cluster * EDCS_CPUS_PER_CLUSTER + cpu;
+ int value = enable ? S5P_CORE_LOCAL_PWR_EN : 0;
+
+ if ((__raw_readl(EDCS_CORE_STATUS(offset)) 0x3) != value)
+ __raw_writel(value, EDCS_CORE_CONFIGURATION(offset));
I think you need to replace all the __raw_readl() / __raw_writel() calls
in this file with readl_relaxed() / writel_relaxed().
This ensures little-endian byte order, so that BE8 kernels will work.
+}
+
+static void exynos_core_power_up(unsigned int cpu, unsigned int cluster)
+{
+ exynos_core_power_control(cpu, cluster, true);
+}
+
+static void exynos_core_power_down(unsigned int cpu, unsigned int cluster)
+{
+ exynos_core_power_control(cpu, cluster, false);
+}
+
+void set_boot_flag(unsigned int cpu, unsigned int mode)
+{
+ __raw_writel(mode, REG_CPU_STATE_ADDR(cpu));
+}
+
+static int exynos_power_up(unsigned int cpu, unsigned int cluster)
+{
+ pr_debug(%s: cpu %u cluster %u\n, __func__, cpu, cluster);
+ BUG_ON(cpu = EDCS_CPUS_PER_CLUSTER || cluster = EDCS_CLUSTERS);
+
+ local_irq_disable();
+ arch_spin_lock(edcs_lock);
+
+ edcs_use_count[cpu][cluster]++;
+ if (edcs_use_count[cpu][cluster] == 1) {
+ ++core_count[cluster];
+ set_boot_flag(cpu, 0x2);
0x2 looks like a magic number. Can we have a #define for that?
If the boot flag is read by the inbound CPU or by a peripheral then
there are memory ordering issues to take into account. Otherwise, can't
the inbound CPU come online and race with the write to the boot flag?
What is the memory type of REG_STATE_ADDR()?
+ exynos_core_power_up(cpu, cluster);
+ } else if (edcs_use_count[cpu][cluster] != 2) {
+ /*
+ * The only possible values are:
+ * 0 = CPU down
+ * 1 = CPU (still) up
+ * 2 = CPU requested to be up before it had a chance
+ *
Re: [PATCH] swap: fix setting PAGE_SIZE blocksize during swapoff/swapon race
On Wed, Oct 16, 2013 at 1:19 AM, Hugh Dickins hu...@google.com wrote: On Tue, 15 Oct 2013, Krzysztof Kozlowski wrote: On Tue, 2013-10-15 at 02:59 -0700, Hugh Dickins wrote: On Mon, 14 Oct 2013, Krzysztof Kozlowski wrote: Fix race between swapoff and swapon resulting in setting blocksize of PAGE_SIZE for block devices during swapoff. The swapon modifies swap_info-old_block_size before acquiring swapon_mutex. It reads block_size of bdev, stores it under swap_info-old_block_size and sets new block_size to PAGE_SIZE. On the other hand the swapoff sets the device's block_size to old_block_size after releasing swapon_mutex. This patch locks the swapon_mutex much earlier during swapon. It also releases the swapon_mutex later during swapoff. The effect of race can be triggered by following scenario: - One block swap device with block size of 512 - thread 1: Swapon is called, swap is activated, p-old_block_size = block_size(p-bdev); /512/ block_size(p-bdev) = PAGE_SIZE; Thread ends. - thread 2: Swapoff is called and it goes just after releasing the swapon_mutex. The swap is now fully disabled except of setting the block size to old value. The p-bdev-block_size is still equal to PAGE_SIZE. - thread 3: New swapon is called. This swap is disabled so without acquiring the swapon_mutex: - p-old_block_size = block_size(p-bdev); /PAGE_SIZE (!!!)/ - block_size(p-bdev) = PAGE_SIZE; Swap is activated and thread ends. - thread 2: resumes work and sets blocksize to old value: - set_blocksize(bdev, p-old_block_size) But now the p-old_block_size is equal to PAGE_SIZE. The patch swap-fix-set_blocksize-race-during-swapon-swapoff does not fix this particular issue. It reduces the possibility of races as the swapon must overwrite p-old_block_size before acquiring swapon_mutex in swapoff. Signed-off-by: Krzysztof Kozlowski k.kozlow...@samsung.com Sorry you're being blown back and forth on this, but I say Nack to this version. I've not spent the time to check whether it ends up correct or not; but your original patch was appropriate to the bug, and this one is just unnecessary churn in my view. Hi, I still think my previous patch does not solve the issue entirely. The call set_blocksize() in swapoff quite often sets PAGE_SIZE instead of valid block size (e.g. 512). I trigger this with: PAGE_SIZE and 512 are equally valid block sizes, it's just hard to support both consistently at the same instant. -- for i in `seq 1000` do swapoff /dev/sdc1 swapon /dev/sdc1 swapon /dev/sdc1 done -- 10 seconds run of this script resulted in 50% of set_blocksize(PAGE_SIZE). Although effect can only be observed after adding printks (block device is released). But despite PAGE_SIZE being a valid block size, I agree that it's odd if you see variation there. Here's my guess: it looks as if the p-bdev test is inadequate, in the decision whether bad_swap should set_blocksize() or not: p-bdev is not usually reset when a swap_info_struct is released for reuse. Please try correcting that, either by resetting p-bdev where necessary, or by putting a better test in bad_swap: see if that fixes this oddity. I still much prefer your original little patch, to this extension of the use of swapon_mutex. However, a bigger question would be, why does swapoff have to set block size back to old_block_size anyway? That was introduced in 2.5.13 by v...@math.psu.edu (02/05/01 1.447.69.1) [PATCH] (1/6) blksize_size[] removal - preliminary cleanups: make sure that swapoff restores original block size, kill set_blocksize() (and use of __bread()) in multipath.c, reorder opening device and finding its block size in mtdblock.c. Al, not an urgent question, but is this swapoff old_block_size stuff still necessary? And can't swapon just use whatever bd_block_size is already in force? IIUC, it plays no part beyond the initial readpage of swap header. Thanks, Hugh Let me try to explain(and guess): we have to set_block in swapon. the swap_header is PAGE_SIZE, if device's blocksize is more than PAGE_SIZE, then the swap entry address on swapfile would be not PAGE_SIZE aligned. or one swap page can not fill a block. There maybe a problem for some device. The set_blocksize() do the judgement work for swapon. And may be some userland tools assume swap device blocksize is PAGE_SIZE？ issues here are more than this one: After swap_info_struct is released for reuse in swapoff. Its corresponding resources are released later, such as: - swap_cgroup_swapoff(type); - blkdev_put - inode-i_flags = ~S_SWAPFILE; we need release(or clean) these resources before release swap_info_struct. to Krzysztof: I think it is better to add this handle to your patch regards -- To unsubscribe from this list: send
Re: [PATCH] x86: unify copy_from_user() checking
On 17.10.13 at 17:45, Arjan van de Ven ar...@linux.intel.com wrote: for me, the value of the feature overall is this range checking, not the fixed size part. for fixed size... the chance of the programmer getting it wrong is near zero. the chance of getting one of the checks wrong is much higher (we've had cases of wrong sign in the checks, off by ones in the checks etc) and that is what it was supposed to find. If that's not possible due practical issues (like the inline case above but more the compiler practicalities) removing the warning part entirely is likely just better. But it would at least cover the case where, for some pointer, someone mixes up sizeof(ptr) and sizeof(*ptr). So I think - it being cheap - the current constant size check could stay, ... Having a runtime check for the case where the argument is not constant but we know the buffer size... is likely still clear value... cheap (perfect branch prediction unless disaster hits!) and the failure case is obviously the disaster case. ... and the non-constant case be taken care of at run time. That's precisely what the patch does. 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 v2] perf: disable PERF_RECORD_MMAP2 support
On 10/17/13 8:28 AM, Stephane Eranian wrote: For now, we disable the extended MMAP record support (MMAP2). We have identified cases where it would not report the correct mapping information, clone(VM_CLONE) but with separate pids. We will revisit the support once we find a solution for this case. The patch changes the kernel to return EINVAL if attr-mmap2 is set. The patch also modifies the perf tool to use regular PERF_RECORD_MMAP for synthetic events and it also prevents the tool from requesting attr-mmap2 mode because the kernel would reject it. The support will be revisited once the kenrel interface is updated. Why not disable mmap2 as well: diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c index 0ce9febf1ba0..289f34dbe970 100644 --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -678,7 +678,7 @@ void perf_evsel__config(struct perf_evsel *evsel, attr-sample_type |= PERF_SAMPLE_WEIGHT; attr-mmap = track; - attr-mmap2 = track !perf_missing_features.mmap2; + /* attr-mmap2 = track !perf_missing_features.mmap2; */ attr-comm = track; 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: [PATCH v5 1/4] i2c: busses: i2c-st: Add ST I2C controller
On Thu, 17 Oct 2013, Jean-Christophe PLAGNIOL-VILLARD wrote:
On 10:33 Thu 17 Oct , srinivas kandagatla wrote:
On 17/10/13 08:27, Maxime COQUELIN wrote:
...
+
+static struct of_device_id st_i2c_match[] = {
+ { .compatible = st,comms-ssc-i2c, },
the rules is to put the first soc that use the ip in the compatible
as st,sti7100-scc-i2c
Ok. There are no plans to upstream the SH4 platforms, it will only
remains in stlinux.com.
Maybe I can set the first ARM platform (STiH415)?
That would give st,stih415-ssc-i2c.
NAK, for st,stih415-ssc-i2c naming.
IMO, this makes sense when the same IP integration done on different SOC
changes slightly/very differently.
But in this case the comms IP remains unchanged across all the SOCs.
I would still prefer st,comms-ssc-i2c, allowing a single device driver
to match against several SoCs. ST comms IP it is integrated across all
the STi series of SoCs, so we don't want to add new entry in compatible
for every new SOC.
you never need this you always the first SoC that's all
see other bindings on at91 as example sorry NACK
I'm guessing that using the first SoC is an I2C'isum.
Guys, if you don't want to be too specific, just make it as generic as
possible whilest still using the SoC as a POR: st,stih41x-ssc-i2c will
do for now, as it covers all current bases.
--
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 v2] perf: disable PERF_RECORD_MMAP2 support
On Thu, Oct 17, 2013 at 5:54 PM, David Ahern dsah...@gmail.com wrote: On 10/17/13 8:28 AM, Stephane Eranian wrote: For now, we disable the extended MMAP record support (MMAP2). We have identified cases where it would not report the correct mapping information, clone(VM_CLONE) but with separate pids. We will revisit the support once we find a solution for this case. The patch changes the kernel to return EINVAL if attr-mmap2 is set. The patch also modifies the perf tool to use regular PERF_RECORD_MMAP for synthetic events and it also prevents the tool from requesting attr-mmap2 mode because the kernel would reject it. The support will be revisited once the kenrel interface is updated. Why not disable mmap2 as well: diff --git a/tools/perf/util/evsel.c b/tools/perf/util/evsel.c index 0ce9febf1ba0..289f34dbe970 100644 --- a/tools/perf/util/evsel.c +++ b/tools/perf/util/evsel.c @@ -678,7 +678,7 @@ void perf_evsel__config(struct perf_evsel *evsel, attr-sample_type |= PERF_SAMPLE_WEIGHT; attr-mmap = track; - attr-mmap2 = track !perf_missing_features.mmap2; + /* attr-mmap2 = track !perf_missing_features.mmap2; */ attr-comm = track; It is disabled automatically later on. I checked that. Wanted to minimize the changes. -- 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 05/17] clk: at91: add PMC main clock
On 11/10/2013 10:44, Boris BREZILLON :
This patch adds new at91 main oscillator clock implementation using common
clk framework.
If rate is not provided during clock registration it is calculated using
the slow clock (main clk parent in this case) rate and MCFR register.
Signed-off-by: Boris BREZILLON b.brezil...@overkiz.com
Acked-by: Nicolas Ferre nicolas.fe...@atmel.com
---
drivers/clk/at91/Makefile |1 +
drivers/clk/at91/clk-main.c | 189 +++
drivers/clk/at91/pmc.c |5 ++
drivers/clk/at91/pmc.h |3 +
4 files changed, 198 insertions(+)
create mode 100644 drivers/clk/at91/clk-main.c
diff --git a/drivers/clk/at91/Makefile b/drivers/clk/at91/Makefile
index 1d4fb21..44105bd 100644
--- a/drivers/clk/at91/Makefile
+++ b/drivers/clk/at91/Makefile
@@ -3,3 +3,4 @@
#
obj-y += pmc.o
+obj-y += clk-main.o
diff --git a/drivers/clk/at91/clk-main.c b/drivers/clk/at91/clk-main.c
new file mode 100644
index 000..905ceff
--- /dev/null
+++ b/drivers/clk/at91/clk-main.c
@@ -0,0 +1,189 @@
+/*
+ * drivers/clk/at91/clk-main.c
+ *
+ * Copyright (C) 2013 Boris BREZILLON b.brezil...@overkiz.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ */
+
+#include linux/clk-provider.h
+#include linux/clkdev.h
+#include linux/clk/at91_pmc.h
+#include linux/delay.h
+#include linux/of.h
+#include linux/of_address.h
+#include linux/of_irq.h
+#include linux/io.h
+#include linux/interrupt.h
+#include linux/irq.h
+#include linux/sched.h
+#include linux/wait.h
+
+#include pmc.h
+
+#define SLOW_CLOCK_FREQ32768
+#define MAINF_DIV 16
+#define MAINFRDY_TIMEOUT (((MAINF_DIV + 1) * USEC_PER_SEC) / \
+SLOW_CLOCK_FREQ)
+#define MAINF_LOOP_MIN_WAIT(USEC_PER_SEC / SLOW_CLOCK_FREQ)
+#define MAINF_LOOP_MAX_WAITMAINFRDY_TIMEOUT
+
+struct clk_main {
+ struct clk_hw hw;
+ struct at91_pmc *pmc;
+ unsigned long rate;
+ unsigned int irq;
+ wait_queue_head_t wait;
+};
+
+#define to_clk_main(hw) container_of(hw, struct clk_main, hw)
+
+static irqreturn_t clk_main_irq_handler(int irq, void *dev_id)
+{
+ struct clk_main *clkmain = (struct clk_main *)dev_id;
+
+ wake_up(clkmain-wait);
+ disable_irq_nosync(clkmain-irq);
+
+ return IRQ_HANDLED;
+}
+
+static int clk_main_prepare(struct clk_hw *hw)
+{
+ struct clk_main *clkmain = to_clk_main(hw);
+ struct at91_pmc *pmc = clkmain-pmc;
+ unsigned long halt_time, timeout;
+ u32 tmp;
+
+ while (!(pmc_read(pmc, AT91_PMC_SR) AT91_PMC_MOSCS)) {
+ enable_irq(clkmain-irq);
+ wait_event(clkmain-wait,
+ pmc_read(pmc, AT91_PMC_SR) AT91_PMC_MOSCS);
+ }
+
+ if (clkmain-rate)
+ return 0;
+
+ timeout = jiffies + usecs_to_jiffies(MAINFRDY_TIMEOUT);
+ do {
+ halt_time = jiffies;
+ tmp = pmc_read(pmc, AT91_CKGR_MCFR);
+ if (tmp AT91_PMC_MAINRDY)
+ return 0;
+ usleep_range(MAINF_LOOP_MIN_WAIT, MAINF_LOOP_MAX_WAIT);
+ } while (time_before(halt_time, timeout));
+
+ return 0;
+}
+
+static int clk_main_is_prepared(struct clk_hw *hw)
+{
+ struct clk_main *clkmain = to_clk_main(hw);
+
+ return !!(pmc_read(clkmain-pmc, AT91_PMC_SR) AT91_PMC_MOSCS);
+}
+
+static unsigned long clk_main_recalc_rate(struct clk_hw *hw,
+ unsigned long parent_rate)
+{
+ u32 tmp;
+ struct clk_main *clkmain = to_clk_main(hw);
+ struct at91_pmc *pmc = clkmain-pmc;
+
+ if (clkmain-rate)
+ return clkmain-rate;
+
+ tmp = pmc_read(pmc, AT91_CKGR_MCFR) AT91_PMC_MAINF;
+ clkmain-rate = (tmp * parent_rate) / MAINF_DIV;
+
+ return clkmain-rate;
+}
+
+static const struct clk_ops main_ops = {
+ .prepare = clk_main_prepare,
+ .is_prepared = clk_main_is_prepared,
+ .recalc_rate = clk_main_recalc_rate,
+};
+
+static struct clk * __init
+at91_clk_register_main(struct at91_pmc *pmc,
+ unsigned int irq,
+ const char *name,
+ const char *parent_name,
+ unsigned long rate)
+{
+ int ret;
+ struct clk_main *clkmain;
+ struct clk *clk = NULL;
+ struct clk_init_data init;
+
+ if (!pmc || !irq || !name)
+ return ERR_PTR(-EINVAL);
+
+ if (!rate !parent_name)
+ return ERR_PTR(-EINVAL);
+
+ clkmain = kzalloc(sizeof(*clkmain), GFP_KERNEL);
+ if (!clkmain)
+ return ERR_PTR(-ENOMEM);
+
+ init.name = name;
+ init.ops = main_ops;
+ init.parent_names
