Re: [PATCH 1/3] Introduce FW_INFO* functions and messages
On Wed, 04 Dec, at 07:22:57PM, Arnd Bergmann wrote:
> The other part I noticed about this particular patchset is that it's
> not really "firmware" as such, but specifically PC wiht ACPI that
> gets covered here. So rather than generalizing the code, another
> option would be to narrow down the scope and make it
> acpi_{warn,info,dbg} instead.
Making this specific to ACPI runs the risk of people introducing a
multitude of new logging functions for every subsystem, e.g.
efi_{warn,info,dbg}.
FWIW, I'd be interested in using something like this patch series to
properly log EFI implementation bugs. The logging for EFI is currently
done fairly haphazardly.
--
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/
[PATCH v6 1/5] watchdog: davinci: change driver to use WDT core
To reduce code duplicate and increase code readability use WDT core
code to handle WDT interface.
Remove io_lock as the WDT core uses mutex to lock each wdt device.
Remove wdt_state as the WDT core tracks state with its own variable.
The watchdog_init_timeout() can read timeout value from timeout-sec
property if the passed value is out of bounds. The heartbeat is
initialized in next way. If heartbeat is not set thought module
parameter, try to read it's value from WDT node timeout-sec property.
If node has no one, use default value.
The heartbeat is hold in wdd->timeout by WDT core, so use it in
order to set timeout period.
Davinci WDT can't be stopped and once it's expired - it can be
rearmed only after hardware reset, that's why nowayout feature
is enforced.
Acked-by: Santosh Shilimkar
Reviewed-by: Guenter Roeck
Signed-off-by: Ivan Khoronzhuk
---
drivers/watchdog/Kconfig |1 +
drivers/watchdog/davinci_wdt.c | 147 ++--
2 files changed, 36 insertions(+), 112 deletions(-)
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 5be6e91..3ca69c8 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -271,6 +271,7 @@ config IOP_WATCHDOG
config DAVINCI_WATCHDOG
tristate "DaVinci watchdog"
depends on ARCH_DAVINCI
+ select WATCHDOG_CORE
help
Say Y here if to include support for the watchdog timer
in the DaVinci DM644x/DM646x processors.
diff --git a/drivers/watchdog/davinci_wdt.c b/drivers/watchdog/davinci_wdt.c
index dd625cc..3701f06 100644
--- a/drivers/watchdog/davinci_wdt.c
+++ b/drivers/watchdog/davinci_wdt.c
@@ -3,7 +3,7 @@
*
* Watchdog driver for DaVinci DM644x/DM646x processors
*
- * Copyright (C) 2006 Texas Instruments.
+ * Copyright (C) 2006-2013 Texas Instruments.
*
* 2007 (c) MontaVista Software, Inc. This file is licensed under
* the terms of the GNU General Public License version 2. This program
@@ -15,18 +15,12 @@
#include
#include
#include
-#include
-#include
#include
#include
-#include
#include
-#include
-#include
#include
#include
#include
-#include
#include
#define MODULE_NAME "DAVINCI-WDT: "
@@ -61,31 +55,12 @@
#define WDKEY_SEQ0 (0xa5c6 << 16)
#define WDKEY_SEQ1 (0xda7e << 16)
-static int heartbeat = DEFAULT_HEARTBEAT;
-
-static DEFINE_SPINLOCK(io_lock);
-static unsigned long wdt_status;
-#define WDT_IN_USE0
-#define WDT_OK_TO_CLOSE 1
-#define WDT_REGION_INITED 2
-#define WDT_DEVICE_INITED 3
-
+static int heartbeat;
static void __iomem*wdt_base;
struct clk *wdt_clk;
+static struct watchdog_device wdt_wdd;
-static void wdt_service(void)
-{
- spin_lock(_lock);
-
- /* put watchdog in service state */
- iowrite32(WDKEY_SEQ0, wdt_base + WDTCR);
- /* put watchdog in active state */
- iowrite32(WDKEY_SEQ1, wdt_base + WDTCR);
-
- spin_unlock(_lock);
-}
-
-static void wdt_enable(void)
+static int davinci_wdt_start(struct watchdog_device *wdd)
{
u32 tgcr;
u32 timer_margin;
@@ -93,8 +68,6 @@ static void wdt_enable(void)
wdt_freq = clk_get_rate(wdt_clk);
- spin_lock(_lock);
-
/* disable, internal clock source */
iowrite32(0, wdt_base + TCR);
/* reset timer, set mode to 64-bit watchdog, and unreset */
@@ -105,9 +78,9 @@ static void wdt_enable(void)
iowrite32(0, wdt_base + TIM12);
iowrite32(0, wdt_base + TIM34);
/* set timeout period */
- timer_margin = (((u64)heartbeat * wdt_freq) & 0x);
+ timer_margin = (((u64)wdd->timeout * wdt_freq) & 0x);
iowrite32(timer_margin, wdt_base + PRD12);
- timer_margin = (((u64)heartbeat * wdt_freq) >> 32);
+ timer_margin = (((u64)wdd->timeout * wdt_freq) >> 32);
iowrite32(timer_margin, wdt_base + PRD34);
/* enable run continuously */
iowrite32(ENAMODE12_PERIODIC, wdt_base + TCR);
@@ -119,84 +92,28 @@ static void wdt_enable(void)
iowrite32(WDKEY_SEQ0 | WDEN, wdt_base + WDTCR);
/* put watchdog in active state */
iowrite32(WDKEY_SEQ1 | WDEN, wdt_base + WDTCR);
-
- spin_unlock(_lock);
-}
-
-static int davinci_wdt_open(struct inode *inode, struct file *file)
-{
- if (test_and_set_bit(WDT_IN_USE, _status))
- return -EBUSY;
-
- wdt_enable();
-
- return nonseekable_open(inode, file);
+ return 0;
}
-static ssize_t
-davinci_wdt_write(struct file *file, const char *data, size_t len,
- loff_t *ppos)
+static int davinci_wdt_ping(struct watchdog_device *wdd)
{
- if (len)
- wdt_service();
-
- return len;
+ /* put watchdog in service state */
+ iowrite32(WDKEY_SEQ0, wdt_base + WDTCR);
+ /* put watchdog in active state */
+ iowrite32(WDKEY_SEQ1, wdt_base + WDTCR);
+ return 0;
}
-static const struct watchdog_info ident = {
[PATCH V4] ARM : unwinder : Prevent data abort due to stack overflow
While unwinding backtrace, stack overflow is possible. This stack
overflow can sometimes lead to data abort in system if the area after
stack is not mapped to physical memory.
To prevent this problem from happening, execute the instructions that
can cause a data abort in separate helper functions, where a check for
feasibility is made before reading each word from the stack.
Signed-off-by: Anurag Aggarwal
---
arch/arm/kernel/unwind.c | 127 -
1 files changed, 90 insertions(+), 37 deletions(-)
diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index 00df012..94f6ef4 100644
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -68,6 +68,7 @@ EXPORT_SYMBOL(__aeabi_unwind_cpp_pr2);
struct unwind_ctrl_block {
unsigned long vrs[16]; /* virtual register set */
const unsigned long *insn; /* pointer to the current instructions
word */
+ unsigned long sp_high; /* highest value of sp allowed*/
int entries;/* number of entries left to interpret
*/
int byte; /* current byte number in the
instructions word */
};
@@ -235,6 +236,86 @@ static unsigned long unwind_get_byte(struct
unwind_ctrl_block *ctrl)
return ret;
}
+/* Before poping a register check whether it is feasible or not */
+static int unwind_pop_register(struct unwind_ctrl_block *ctrl,
+ unsigned long **vsp, unsigned int reg)
+{
+ if (*vsp >= (unsigned long *)ctrl->sp_high)
+ return -URC_FAILURE;
+
+ ctrl->vrs[reg] = *(*vsp)++;
+ return URC_OK;
+}
+
+/* Helper functions to execute the instructions */
+static int unwind_exec_pop_subset_r4_to_r13(struct unwind_ctrl_block *ctrl,
+ unsigned long mask)
+{
+ unsigned long *vsp = (unsigned long *)ctrl->vrs[SP];
+ int load_sp, reg = 4;
+
+ load_sp = mask & (1 << (13 - 4));
+ while (mask) {
+ if (mask & 1)
+ if (unwind_pop_register(ctrl, , reg))
+ return -URC_FAILURE;
+ mask >>= 1;
+ reg++;
+ }
+ if (!load_sp)
+ ctrl->vrs[SP] = (unsigned long)vsp;
+
+ pr_debug("%s: fp = %08lx sp = %08lx lr = %08lx pc = %08lx\n", __func__,
+ ctrl->vrs[FP], ctrl->vrs[SP], ctrl->vrs[LR], ctrl->vrs[PC]);
+
+ return URC_OK;
+}
+
+static int unwind_exec_pop_r4_to_rN(struct unwind_ctrl_block *ctrl,
+ unsigned long insn)
+{
+ unsigned long *vsp = (unsigned long *)ctrl->vrs[SP];
+ int reg;
+
+ /* pop R4-R[4+bbb] */
+ for (reg = 4; reg <= 4 + (insn & 7); reg++)
+ if (unwind_pop_register(ctrl, , reg))
+ return -URC_FAILURE;
+
+ if (insn & 0x80)
+ if (unwind_pop_register(ctrl, , 14))
+ return -URC_FAILURE;
+
+ ctrl->vrs[SP] = (unsigned long)vsp;
+
+ pr_debug("%s: fp = %08lx sp = %08lx lr = %08lx pc = %08lx\n", __func__,
+ ctrl->vrs[FP], ctrl->vrs[SP], ctrl->vrs[LR], ctrl->vrs[PC]);
+
+ return URC_OK;
+}
+
+static int unwind_exec_pop_subset_r0_to_r3(struct unwind_ctrl_block *ctrl,
+ unsigned long mask)
+{
+ unsigned long *vsp = (unsigned long *)ctrl->vrs[SP];
+ int reg = 0;
+
+ /* pop R0-R3 according to mask */
+ while (mask) {
+ if (mask & 1)
+ if (unwind_pop_register(ctrl, , reg))
+ return -URC_FAILURE;
+ mask >>= 1;
+ reg++;
+ }
+ ctrl->vrs[SP] = (unsigned long)vsp;
+
+ pr_debug("%s: fp = %08lx sp = %08lx lr = %08lx pc = %08lx\n", __func__,
+ ctrl->vrs[FP], ctrl->vrs[SP], ctrl->vrs[LR], ctrl->vrs[PC]);
+
+ return URC_OK;
+}
+
/*
* Execute the current unwind instruction.
*/
@@ -250,8 +331,6 @@ static int unwind_exec_insn(struct unwind_ctrl_block *ctrl)
ctrl->vrs[SP] -= ((insn & 0x3f) << 2) + 4;
else if ((insn & 0xf0) == 0x80) {
unsigned long mask;
- unsigned long *vsp = (unsigned long *)ctrl->vrs[SP];
- int load_sp, reg = 4;
insn = (insn << 8) | unwind_get_byte(ctrl);
mask = insn & 0x0fff;
@@ -261,38 +340,19 @@ static int unwind_exec_insn(struct unwind_ctrl_block
*ctrl)
return -URC_FAILURE;
}
- /* pop R4-R15 according to mask */
- load_sp = mask & (1 << (13 - 4));
- while (mask) {
- if (mask & 1)
- ctrl->vrs[reg] = *vsp++;
- mask >>= 1;
- reg++;
- }
- if (!load_sp)
-
[PATCH] video: Replace local macro with PCI standard macro
Replace local macro TGA_BUS_PCI with PCI standard
marco dev_is_pci().
Signed-off-by: Yijing Wang
---
drivers/video/tgafb.c | 16 +---
1 files changed, 5 insertions(+), 11 deletions(-)
diff --git a/drivers/video/tgafb.c b/drivers/video/tgafb.c
index f28674f..5e94c6e 100644
--- a/drivers/video/tgafb.c
+++ b/drivers/video/tgafb.c
@@ -32,12 +32,6 @@
#include
-#ifdef CONFIG_PCI
-#define TGA_BUS_PCI(dev) (dev->bus == _bus_type)
-#else
-#define TGA_BUS_PCI(dev) 0
-#endif
-
#ifdef CONFIG_TC
#define TGA_BUS_TC(dev) (dev->bus == _bus_type)
#else
@@ -236,7 +230,7 @@ tgafb_set_par(struct fb_info *info)
};
struct tga_par *par = (struct tga_par *) info->par;
- int tga_bus_pci = TGA_BUS_PCI(par->dev);
+ int tga_bus_pci = dev_is_pci(par->dev);
int tga_bus_tc = TGA_BUS_TC(par->dev);
u32 htimings, vtimings, pll_freq;
u8 tga_type;
@@ -519,7 +513,7 @@ tgafb_setcolreg(unsigned regno, unsigned red, unsigned
green, unsigned blue,
unsigned transp, struct fb_info *info)
{
struct tga_par *par = (struct tga_par *) info->par;
- int tga_bus_pci = TGA_BUS_PCI(par->dev);
+ int tga_bus_pci = dev_is_pci(par->dev);
int tga_bus_tc = TGA_BUS_TC(par->dev);
if (regno > 255)
@@ -1472,7 +1466,7 @@ static void
tgafb_init_fix(struct fb_info *info)
{
struct tga_par *par = (struct tga_par *)info->par;
- int tga_bus_pci = TGA_BUS_PCI(par->dev);
+ int tga_bus_pci = dev_is_pci(par->dev);
int tga_bus_tc = TGA_BUS_TC(par->dev);
u8 tga_type = par->tga_type;
const char *tga_type_name = NULL;
@@ -1560,7 +1554,7 @@ static int tgafb_register(struct device *dev)
const struct fb_videomode *modedb_tga = NULL;
resource_size_t bar0_start = 0, bar0_len = 0;
const char *mode_option_tga = NULL;
- int tga_bus_pci = TGA_BUS_PCI(dev);
+ int tga_bus_pci = dev_is_pci(dev);
int tga_bus_tc = TGA_BUS_TC(dev);
unsigned int modedbsize_tga = 0;
void __iomem *mem_base;
@@ -1690,7 +1684,7 @@ static int tgafb_register(struct device *dev)
static void tgafb_unregister(struct device *dev)
{
resource_size_t bar0_start = 0, bar0_len = 0;
- int tga_bus_pci = TGA_BUS_PCI(dev);
+ int tga_bus_pci = dev_is_pci(dev);
int tga_bus_tc = TGA_BUS_TC(dev);
struct fb_info *info = NULL;
struct tga_par *par;
--
1.7.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: OMAPFB: CMA allocation failures
On 2013-11-30 12:00, Ivajlo Dimitrov wrote:
> Ping?
>
> - Original Message - From: "Ивайло Димитров"
> To: "Tomi Valkeinen"
> Cc: ; ; ;
> ; ;
> ;
> Sent: Tuesday, November 05, 2013 9:55 PM
> Subject: Re: OMAPFB: CMA allocation failures
>
>
>>
>>
>>
>>
>>
>> > Оригинално писмо
>> >От: Tomi Valkeinen
>> >Относно: Re: OMAPFB: CMA allocation failures
>> >До: Ивайло Димитров
>> >Изпратено на: Сряда, 2013, Октомври 30 14:19:32 EET
>> >
>> >I really dislike the idea of adding the omap vram allocator back. Then
>> >again, if the CMA doesn't work, something has to be done.
>> >
>>
>> If I got Minchan Kim's explanation correctly, CMA simply can't be used
>> for allocation of framebuffer memory, because it is unreliable.
Well. All memory allocation is unreliable. And
include/linux/dma-contiguous.h even clearly states that CMA is something
to be used in cases like omapfb.
>> >Pre-allocating is possible, but that won't work if there's any need to
>> >re-allocating the framebuffers. Except if the omapfb would retain and
>> >manage the pre-allocated buffers, but that would just be more or less
>> >the old vram allocator again.
>> >
>> >So, as I see it, the best option would be to have the standard dma_alloc
>> >functions get the memory for omapfb from a private pool, which is not
>> >used for anything else.
>> >
>> >I wonder if that's possible already? It sounds quite trivial to me.
>>
>> dma_alloc functions use either CMA or (iirc) get_pages_exact if CMA is
>> disabled. Both of those fail easily. AFAIK there are several
>> implementations with similar functionality, like CMEM and ION but
>> (correct me if I am wrong) neither of them is upstreamed. In the
>> current kernel I don't see anything that can be used for the purpose
>> of reliable allocation of big chunks of contiguous memory.
>> So, something should be done, but honestly, I can't think of anything
>> but bringing VRAM allocator back. Not that I like the idea of bringing
>> back ~700 lines of code, but I see no other option if omapfb driver is
>> to be actually useful.
How about the patch below? If I'm not mistaken (and I might) it reserves
separate memory area for omapfb, which is not used by CMA.
If it works, it should be extended to get the parameters via kernel
cmdline, and use that alloc only if the user requests it.
diff --git a/arch/arm/mach-omap2/common.c b/arch/arm/mach-omap2/common.c
index 2dabb9ecb986..9beecded0380 100644
--- a/arch/arm/mach-omap2/common.c
+++ b/arch/arm/mach-omap2/common.c
@@ -33,4 +33,5 @@ void __init omap_reserve(void)
omap_dsp_reserve_sdram_memblock();
omap_secure_ram_reserve_memblock();
omap_barrier_reserve_memblock();
+ omap_fb_reserve_memblock();
}
diff --git a/arch/arm/mach-omap2/common.h b/arch/arm/mach-omap2/common.h
index 48e9cd34cae0..874786f05ec3 100644
--- a/arch/arm/mach-omap2/common.h
+++ b/arch/arm/mach-omap2/common.h
@@ -40,6 +40,8 @@
#include "usb.h"
+void __init omap_fb_reserve_memblock(void);
+
#define OMAP_INTC_STARTNR_IRQS
#if defined(CONFIG_PM) && defined(CONFIG_ARCH_OMAP2)
diff --git a/arch/arm/mach-omap2/fb.c b/arch/arm/mach-omap2/fb.c
index 26e28e94f625..8f339e88c7cd 100644
--- a/arch/arm/mach-omap2/fb.c
+++ b/arch/arm/mach-omap2/fb.c
@@ -30,9 +30,11 @@
#include
#include
+#include
#include "soc.h"
#include "display.h"
+#include "common.h"
#ifdef CONFIG_OMAP2_VRFB
@@ -106,9 +108,41 @@ static struct platform_device omap_fb_device = {
.num_resources = 0,
};
+static phys_addr_t omapfb_mem_base __initdata;
+static phys_addr_t omapfb_mem_size __initdata;
+
+void __init omap_fb_reserve_memblock(void)
+{
+ omapfb_mem_size = ALIGN(1920*1200*4*3, SZ_2M);
+ omapfb_mem_base = arm_memblock_steal(omapfb_mem_size, SZ_2M);
+ if (omapfb_mem_base)
+ pr_info("omapfb: reserved %u bytes at %x\n",
+ omapfb_mem_size, omapfb_mem_base);
+ else
+ pr_err("omapfb: arm_memblock_steal failed\n");
+}
+
int __init omap_init_fb(void)
{
- return platform_device_register(_fb_device);
+ int r;
+ int dma;
+
+ r = platform_device_register(_fb_device);
+ if (r)
+ return r;
+
+ if (!omapfb_mem_base)
+ return 0;
+
+ dma = dma_declare_coherent_memory(_fb_device.dev,
+ omapfb_mem_base, omapfb_mem_base,
+ omapfb_mem_size,
+ DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE);
+
+ if (!(dma & DMA_MEMORY_MAP))
+ pr_err("omapfb: dma_declare_coherent_memory failed\n");
+
+ return 0;
}
#else
int __init omap_init_fb(void) { return 0; }
signature.asc
Description: OpenPGP digital signature
[PATCH] checkpatch: Do not hardcode perl path
checkpatch.pl requires perl v5.10.0 to run but it doesn't require to place in /usr/bin/perl Use env to ensure that the interpreter used is the first one on environment's $PATH on system with several versions of perl installed. Signed-off-by: Jagannadha Sutradharudu Teki --- scripts/checkpatch.pl | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl index 9c98100..241bb11 100755 --- a/scripts/checkpatch.pl +++ b/scripts/checkpatch.pl @@ -1,10 +1,11 @@ -#!/usr/bin/perl -w +#!/usr/bin/env perl # (c) 2001, Dave Jones. (the file handling bit) # (c) 2005, Joel Schopp (the ugly bit) # (c) 2007,2008, Andy Whitcroft (new conditions, test suite) # (c) 2008-2010 Andy Whitcroft # Licensed under the terms of the GNU GPL License version 2 +use warnings; use strict; use POSIX; -- 1.8.3 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] uwb: Use dev_is_pci() to check whether it is pci device
Use PCI standard marco dev_is_pci() instead of directly compare
pci_bus_type to check whether it is pci device.
Signed-off-by: Yijing Wang
---
drivers/uwb/umc-bus.c |2 +-
include/linux/uwb/umc.h |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/uwb/umc-bus.c b/drivers/uwb/umc-bus.c
index e3ed6ff..88a290f 100644
--- a/drivers/uwb/umc-bus.c
+++ b/drivers/uwb/umc-bus.c
@@ -85,7 +85,7 @@ int umc_match_pci_id(struct umc_driver *umc_drv, struct
umc_dev *umc)
const struct pci_device_id *id_table = umc_drv->match_data;
struct pci_dev *pci;
- if (umc->dev.parent->bus != _bus_type)
+ if (!dev_is_pci(umc->dev.parent))
return 0;
pci = to_pci_dev(umc->dev.parent);
diff --git a/include/linux/uwb/umc.h b/include/linux/uwb/umc.h
index 891d1d5..ba82f03 100644
--- a/include/linux/uwb/umc.h
+++ b/include/linux/uwb/umc.h
@@ -143,7 +143,7 @@ int umc_match_pci_id(struct umc_driver *umc_drv, struct
umc_dev *umc);
static inline struct pci_dev *umc_parent_pci_dev(struct umc_dev *umc_dev)
{
struct pci_dev *pci_dev = NULL;
- if (umc_dev->dev.parent->bus == _bus_type)
+ if (dev_is_pci(umc_dev->dev.parent))
pci_dev = to_pci_dev(umc_dev->dev.parent);
return pci_dev;
}
--
1.7.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] partitions/efi: complete gpt kernel param purpose
On Wed, Dec 04, 2013 at 03:16:02PM -0800, Davidlohr Bueso wrote: > From: Davidlohr Bueso > > The usage of the 'gpt' kernel parameter is twofold: > (i) skip any mbr integrity checks and (ii) enable the > backup GPT header to be used in situations where the > primary one is corrupted. This last "feature" is not > obvious and needs to be properly documented in the > kernel-parameters document. The question is if we really have to force users to specify "gpt" kernel parameter to use the backup GPT header. Maybe it would be enough to report the problem (print warning) and use the valid backup header. IMHO the current behaviour is overkill. Karel -- Karel Zak http://karelzak.blogspot.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/
[PATCH 1/2] usb: Use dev_is_pci() to check whether it is pci device
Use PCI standard marco dev_is_pci() instead of directly compare
pci_bus_type to check whether it is pci device.
Signed-off-by: Yijing Wang
---
drivers/usb/host/ehci-dbg.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/usb/host/ehci-dbg.c b/drivers/usb/host/ehci-dbg.c
index 4a9c2ed..0bb5e48 100644
--- a/drivers/usb/host/ehci-dbg.c
+++ b/drivers/usb/host/ehci-dbg.c
@@ -818,7 +818,7 @@ static ssize_t fill_registers_buffer(struct debug_buffer
*buf)
#ifdef CONFIG_PCI
/* EHCI 0.96 and later may have "extended capabilities" */
- if (hcd->self.controller->bus == _bus_type) {
+ if (dev_is_pci(hcd->self.controller)) {
struct pci_dev *pdev;
u32 offset, cap, cap2;
unsignedcount = 256/4;
--
1.7.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] x86: mcheck: call put_device on device_register failure
2013-12-05 03:57 keltezéssel, Chen, Gong írta:
> On Wed, Dec 04, 2013 at 07:39:07PM +0100, Levente Kurusa wrote:
>> Date:Wed, 04 Dec 2013 19:39:07 +0100
>> From: Levente Kurusa
>> To: Borislav Petkov , Ingo Molnar , Thomas
>> Gleixner , Tony Luck , "H. Peter
>> Anvin" , x...@kernel.org, EDAC ,
>> LKML
>> Subject: Re: [PATCH] x86: mcheck: call put_device on device_register failure
>> User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101
>> Thunderbird/24.1.0
>>
>> 2013-12-04 08:38, Chen, Gong:
>>> On Tue, Dec 03, 2013 at 06:01:50PM +0100, Borislav Petkov wrote:
Date: Tue, 3 Dec 2013 18:01:50 +0100
From: Borislav Petkov
To: "Chen, Gong"
Cc: Levente Kurusa , Ingo Molnar ,
Thomas Gleixner , Tony Luck , "H.
Peter Anvin" , x...@kernel.org, EDAC
, LKML
Subject: Re: [PATCH] x86: mcheck: call put_device on device_register
failure
User-Agent: Mutt/1.5.21 (2010-09-15)
Can you please fix your
Mail-Followup-To:
header? It is impossible to reply to your emails without fiddling with
the To: and Cc: by hand which gets very annoying over time.
>>>
>>> I add some configs in my muttrc. Hope it works.
>>>
On Mon, Dec 02, 2013 at 09:23:30PM -0500, Chen, Gong wrote:
> I have some concerns about it. if device_register is failed, it will
> backtraces all kinds of conditions automatically, including put_device
> definately. So do we really need an extra put_device when it returns
> failure?
Do you mean the "done:" label in device_add() which does put_device()
and which gets called by device_register()?
>>>
>>> Not only. I noticed that another put_device under label "Error:".
>>>
>>
>> That label is called when we failed to add the kobject to its parent.
>> It just puts the parent of the device. I don't think it has anything
>> to do with us put_device()-ing the actual device too.
>>
> OK, you are right. I read some kobject related codes and get:
>
> static inline void kref_init(struct kref *kref)
> {
> atomic_set(>refcount, 1);
> }
>
> The init refcount is 1, which means even if we meet an error and put_device
> in device_add, we still need an extra put_device to make refcount = 0
> and then release the dev object.
Exactly. This is why the comment you have found later on. :-)
>
> BTW, from the comments of device_register:
>
> "NOTE: _Never_ directly free @dev after calling this function, even
> if it returned an error! Always use put_device() to give up the
> reference initialized in this function instead. "
>
> Many caller don't follow this logic. For example:
> in arch/arm/common/locomo.c
> locomo_init_one_child
> ...
> ret = device_register(>dev);
> if (ret) {
> out:
> kfree(dev);
Umm, but it frees dev which is a container_of dev->dev so dev->dev is not
even freed. This is a memleak as well.
> }
> ...
>
> in arch/parisc/kernel/drivers.c
> create_tree_node
> ...
> if (device_register(>dev)) {
> kfree(dev);
Same here.
> return NULL;
> }
> ...
>
> etc.
>
> Maybe we need one more patch to fix them all. :-)
Yes, I will post a series which fixes this during the weekend when I am not
that busy. :-)
--
Regards,
Levente Kurusa
--
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 1/3] Documentation: arm: add UEFI support documentation
On Thu, 28 Nov 2013 16:41:21 +, Leif Lindholm wrote: > This patch provides documentation of the [U]EFI runtime service and > configuration features for the arm architecture. > > Changes since v1/v2: > - Complete rewrite. > - New FDT bindings. > > Cc: Rob Landley > Cc: linux-...@vger.kernel.org > > Signed-off-by: Leif Lindholm Acked-by: Grant Likely With a few minor comments below. g. > --- > Documentation/arm/00-INDEX |3 +++ > Documentation/arm/uefi.txt | 61 > > 2 files changed, 64 insertions(+) > create mode 100644 Documentation/arm/uefi.txt > > diff --git a/Documentation/arm/00-INDEX b/Documentation/arm/00-INDEX > index 36420e1..b3af704 100644 > --- a/Documentation/arm/00-INDEX > +++ b/Documentation/arm/00-INDEX > @@ -34,3 +34,6 @@ nwfpe/ > - NWFPE floating point emulator documentation > swp_emulation > - SWP/SWPB emulation handler/logging description > + > +uefi.txt > + - [U]EFI configuration and runtime services documentation > diff --git a/Documentation/arm/uefi.txt b/Documentation/arm/uefi.txt > new file mode 100644 > index 000..9ba59509 > --- /dev/null > +++ b/Documentation/arm/uefi.txt > @@ -0,0 +1,61 @@ > +UEFI, the Unified Extensible Firmware Interface is, a specification Nit: Comma in the wrong place. > +governing the behaviours of compatible firmware interfaces. It is > +maintained by the UEFI Forum - http://www.uefi.org/. > + > +UEFI is an evolution of its predecessor 'EFI', so the terms EFI and > +UEFI are used somewhat interchangeably in this document and associated > +source code. As a rule, anything new uses 'UEFI', whereas 'EFI' refers > +to legacy code or specifications. > + > +UEFI support in Linux > += > +Booting on a platform with firmware compliant with the UEFI specification > +makes it possible for the kernel to support additional features: > +- UEFI Runtime Services > +- Retrieving various configuration information through the standardised > + interface of UEFI configuration tables. (ACPI, SMBIOS, ...) > + > +For actually enabling [U]EFI support, enable: > +- CONFIG_EFI=y > +- CONFIG_EFI_VARS=y or m > + > +The implementation depends on receiving information about the UEFI > environment > +in a Flattened Device Tree (FDT) - so is only available with CONFIG_OF. > + > +UEFI stub > += > +The "stub" is a feature that turns the Image/zImage into a valid UEFI PE/COFF Nit: s/turns/extends/ > +executable, including a loader application that makes it possible to load the > +kernel directly from the UEFI shell, boot menu, or one of the lightweight > +bootloaders like Gummiboot or rEFInd. > + > +The kernel image built with stub support remains a valid kernel image for > +booting in non-UEFI environments. > + > +UEFI kernel support on ARM > +== > +UEFI kernel support on the ARM architectures (arm and arm64) is only > available > +when boot is performed through the stub. > + > +The stub populates the FDT /chosen node with (and the kernel scans for) the > +following parameters: > + > +Name | Size | Description > + > +linux,uefi-system-table | 64-bit | Physical address of the UEFI System > Table. > + > +linux,uefi-mmap-start | 64-bit | Physical address of the UEFI memory map, > + || populated by the UEFI GetMemoryMap() > call. > + > +linux,uefi-mmap-size | 32-bit | Size in bytes of the UEFI memory map > + || pointed to in previous entry. > + > +linux,uefi-mmap-desc-size | 32-bit | Size in bytes of each entry in the UEFI > + || memory map. > + > +linux,uefi-mmap-desc-ver | 32-bit | Version of the mmap descriptor format. > + > +linux,uefi-stub-kern-ver | string | Copy of linux_banner from build. > + > + > +For verbose debug messages, specify 'uefi_debug' on the kernel command line. > -- > 1.7.10.4 > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 00/38] perf/core improvements and fixes
On Thu, Dec 05, 2013 at 11:59:14AM +0100, Ingo Molnar wrote: > > * Ingo Molnar wrote: > > > > never saw that one.. starting your test on 24 CPUs server now > > > > I saw it again on a system by running two parallel build jobs: > > > > D=/tmp/perf-1; mkdir -p $D; while make O=$D install; do make O=$D clean; > > done > > D=/tmp/perf-2; mkdir -p $D; while make O=$D install; do make O=$D clean; > > done > > I'm running it now with the previous perf/core - no failures so far, > after dozens of build passes. > could you please try attached change? working for me so far.. thanks, jirka --- diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index ca3b87d..9a8cf37 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -722,7 +722,7 @@ $(LIBTRACEEVENT)-clean: $(call QUIET_CLEAN, libtraceevent) @$(MAKE) -C $(TRACE_EVENT_DIR) O=$(OUTPUT) clean >/dev/null -install-traceevent-plugins: +install-traceevent-plugins: $(LIBTRACEEVENT) $(QUIET_SUBDIR0)$(TRACE_EVENT_DIR) $(LIBTRACEEVENT_FLAGS) install_plugins LIBLK_SOURCES = $(wildcard $(LK_PATH)*.[ch]) -- 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] sched/numa: drop idx field of task_numa_env struct
Drop unused idx field of task_numa_env struct.
Signed-off-by: Wanpeng Li
---
kernel/sched/fair.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index fd773ad..ea3fd1e 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -1037,7 +1037,7 @@ struct task_numa_env {
struct numa_stats src_stats, dst_stats;
- int imbalance_pct, idx;
+ int imbalance_pct;
struct task_struct *best_task;
long best_imp;
--
1.7.7.6
--
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: [REPOST PATCH V2] irq: enable all irqs unconditionally in irq_resume
On Thursday 05 December 2013 04:31 PM, Heiko Stübner wrote: Hi Laxman, Am Donnerstag, 5. Dezember 2013, 11:49:05 schrieb Laxman Dewangan: Can you please review this patch? This patch is pending from long back for review. the patch already made it into the appropriate tree, as can be seen by tip-bot message and on [0]. Heiko [0] http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=irq-urgent-for-linus=ac01810c9d2814238f08a227062e66a35a0e1ea2 Seems I lost the applied mail and that's why I assumed that it is not reviewed yet. My bad, Sorry for noise. I can see the change in linux-next also. Thanks Thomas/Heiko for review. Thanks, Laxman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/3] Documentation: arm: add UEFI support documentation
On Wed, 4 Dec 2013 15:06:47 -0600, Matt Sealey wrote: > If your platform has UEFI, then your platform has UEFI - if you built > a multiplatform kernel that needs to boot on U-Boot, then you glued an > EFI stub to it to make it boot. At some point between the stub and the > runtime services driver, you're going through 10,000 lines of code > with the information that it *is* running on top of UEFI completely > lost to the boot process. > > I believe I am also objecting to the idea that the way this is BEST > implemented is to take a stock zImage (decompressor+Image payload) and > glue a stub in front to resolve the interface issue when the > implication is extra complication to the boot process. Adding UEFI support to an existing image type was a design goal when we started. Having yet another image format which is not compatibile with existing firmware adds yet another barrier to migrating from U-Boot to UEFI, or to supporting multiplatforms. g. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 00/38] perf/core improvements and fixes
On Thu, Dec 05, 2013 at 11:53:44AM +0100, Ingo Molnar wrote: SNIP > > I saw it again on a system by running two parallel build jobs: > > D=/tmp/perf-1; mkdir -p $D; while make O=$D install; do make O=$D clean; > done > D=/tmp/perf-2; mkdir -p $D; while make O=$D install; do make O=$D clean; > done > > one failed with: > > BUILDPLUGIN plugin_kmem.so > make[2]: *** [sub-make] Error 2 > make[1]: *** [/tmp/perf-1/libtraceevent.a] Error 2 > make[1]: *** Waiting for unfinished jobs > BUILDPLUGIN plugin_kvm.so > > the other with: > > CC FPIC plugin_cfg80211.o > CC /tmp/perf-2/builtin-help.o > CC /tmp/perf-2/builtin-sched.o > plugin_sched_switch.o: file not recognized: File truncated > collect2: error: ld returned 1 exit status > make[3]: *** [plugin_sched_switch.so] Error 1 BUILDPLUGIN > plugin_function.so > > > and that's clearly the new plugin code. yes, I reproduced... looks like 'plugins' target is racing with 'install_plugins' target.. both ending up building same objects at the same time working on fix thanks, jirka -- 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 v10 7/7] thermal:exynos:boost: Automatic enable/disable of BOOST feature (at Exynos4412)
Hi Eduardo, > Hey Lukasz!, > > On 03-12-2013 11:42, Lukasz Majewski wrote: > > Hi Eduardo, > > > >> On 03-12-2013 03:31, Lukasz Majewski wrote: > >>> Hi Eduardo, > >>> > On 05-11-2013 13:26, Lukasz Majewski wrote: > > This patch provides auto disable/enable operation for boost. It > > uses already present thermal infrastructure to provide boost > > hysteresis. A special set of TMU data has been defined for > > Exynos4412, which is only considered when BOOST is enabled. > > Can you please add more description why you need a different set > of thermal data when boost is enabled? > >>> > >>> It turned out that the Thermal subsystem (after rework done for > >>> v3.12) is capable of providing hysteresis for BOOST. > >>> > >> > >> So, the difference is only the hysteresis? > >> > >>> For version of the patch up to v8 I had to modify the thermal core > >>> to provide such functionality. Changes in core weren't accepted by > >>> Zhang Rui. > >> > >> Ok... But still I didn't get what you needed to modify and why.. > >> Sorry I jumped in the middle of ongoing discussion. > >> > >>> > >>> Then I've looked again to the code and it turned out that proper > >>> setting of Exynos4x12 data (like trigger levels and freq_clip_max) > >>> can solve the problem in a much better way by using Exynos thermal > >>> interrupts. > >>> Another advantage is that those changes are done per device. > >>> > This is also important in case you > (Exynos thermal folks) would like to migrate this driver to have > thermal data support in DT. > >>> > >>> Some work on this driver is ongoing (mainly done by Bartek > >>> Zolnierkiewicz). This BOOST change doesn't break anything and only > >>> extend the current thermal code. Thereof it will not break > >>> anything. > >> > >> Well, good that it does not break anything, right? > >> > >> But, My point, Lukasz, is that I am failing to understand, based on > >> your patch and description why we need a different data definition, > >> one for boost, other for without boost. Can you help me to get your > >> intention with this patch properly? > > > > I reduce the trigger_level[0] and set new .freq_table[0] entry. > > It works as follow (for BOOST): > > > > 1. Non-boost freq is 1.4 GHz on Exynos4412. BOOST is 1.5GHz. The > > BOOST itself is enabled by CONFIG_CPU_FREQ_BOOST_SW. > > > > 2. Exynos TMU driver reaches the lower TMU level (70 deg). Then the > > core thermal looks for proper frequency table (.freq_tab[0]). If the > > .temp_level matches the trigger_levels[0], then the frequency is > > reduced to .freq_clip_max = 1400 * 1000. > > > > When the device cools down to 60 deg (trigger_levels[0] - > > threshold_falling), then the max freq is restored to 1.5 GHz. This > > is done automatically by thermal core. > > > > For BOOST disabled we only can run with 1.4 GHz freq. For this > > reason the freq_tab[X] entries must be modified. Also the Exynos > > part of thermal requires that trigger_levels[0] is the lowest > > temperature trip, so I cannot add the "BOOST disable" temp level in > > the end of TMU_DATA_BOOST. > > OK. The entire thing is to allow dynamic control on your speedbin > frequencies, I see. Yes, correct. > What bugs me, is that this themal driver keeps > another table of frequencies. Yes, it does. It is the part of thermal_cooling_conf data. It is a very practical solution, since we can specify the threshold temperature and corresponding maximal frequency (up to 8 values). Those values are afterwards used at exynos_bind to bind zone to cooling device. > Ideally, it should not care about it, The above procedure is a part of passive cooling implementation for Exynos. > but about the thermal behavior changes, meaning, say, how fast your > temperature rises, when you jump from lowest opp to 1.4GHz or 1.5GHz, > on host process or cold process samples. Could you be more specific here? I assume that you are asking if slope of the temperature rise has been measured? I didn't measure this value, since it depends on the work environment (number of processes running, ambient temperature, current SoC temperature, etc.) and thereof is hard to reproduce. However, the exynos_thermal_common.c defines .get_trend callback. Unfortunately it only gives an information about the trend (rising, falling). The exact slope value is not given. Personally I think, that the slope measurement is not relevant for the BOOST. > > > > >> > >> Side question is what happens in runtime if user echo 0 > boost? > > > > As we had agreed with Rafael and Viresh, we are here mimic the HW > > CPUs behaviour (like Intel CPU). > > Which is fine and expected. > > > When user writes 'echo 0 > boost' then at cpufreq core we switch to > > max freq to 1.4 GHz. > > OK. > > > > > Thermal here is only for safety reasons. > > > >> Should we switch the data within the driver? > > > > No. When one decides to enable CONFIG_CPU_FREQ_BOOST_SW, then > >
[PATCH 2/4] ARM: tegra: add pinmux controller to tegra124.dtsi
The tegra124 pinmux controller is identical to tegra114 with
removing some of existing pins from T114 and adding new pins.
Signed-off-by: Laxman Dewangan
---
arch/arm/boot/dts/tegra124.dtsi |6 ++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/arch/arm/boot/dts/tegra124.dtsi b/arch/arm/boot/dts/tegra124.dtsi
index b741300..39bfcce 100644
--- a/arch/arm/boot/dts/tegra124.dtsi
+++ b/arch/arm/boot/dts/tegra124.dtsi
@@ -47,6 +47,12 @@
interrupt-controller;
};
+ pinmux: pinmux {
+ compatible = "nvidia,tegra124-pinmux";
+ reg = <0x7868 0x164 /* Pad control registers */
+ 0x70003000 0x434>; /* PinMux registers */
+ };
+
/*
* There are two serial driver i.e. 8250 based simple serial
* driver and APB DMA based serial driver for higher baudrate
--
1.7.1.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] pinctrl: tegra: Add pincontrol driver for Tegra124 SoC
Add pincontrol driver for NVIDIA's Tegra124 SoCs. This series add pincontrol driver which contains the pinmux tables for tegra124, pincontrol dt binding doc, dtsi file change for adding pinmux node, selecting pincontrol config for Tegra124. Ashwini Ghuge (1): pinctrl: tegra: add pinmux controller driver for Tegra124 Laxman Dewangan (3): pinctrl: tegra: Add devicetree binding document for Tegra124 ARM: tegra: add pinmux controller to tegra124.dtsi ARM: tegra: select PINCTRL_TEGRA124 for Tegra124 SoC .../bindings/pinctrl/nvidia,tegra124-pinmux.txt| 137 + arch/arm/boot/dts/tegra124.dtsi|6 + arch/arm/mach-tegra/Kconfig|1 + drivers/pinctrl/Kconfig|4 + drivers/pinctrl/Makefile |1 + drivers/pinctrl/pinctrl-tegra124.c | 3147 6 files changed, 3296 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt create mode 100644 drivers/pinctrl/pinctrl-tegra124.c -- 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/4] pinctrl: tegra: Add devicetree binding document for Tegra124
This device tree binding document describes the Tegra124 pincontrol DT bindings. This document lists all valid properties, names, mux options of Tegra124 pins. Signed-off-by: Laxman Dewangan --- .../bindings/pinctrl/nvidia,tegra124-pinmux.txt| 137 1 files changed, 137 insertions(+), 0 deletions(-) create mode 100644 Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt diff --git a/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt new file mode 100644 index 000..016dad6 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/nvidia,tegra124-pinmux.txt @@ -0,0 +1,137 @@ +NVIDIA Tegra124 pinmux controller + +The Tegra124 pinctrl binding is very similar to the Tegra20 and Tegra30 +pinctrl binding, as described in nvidia,tegra20-pinmux.txt and +nvidia,tegra30-pinmux.txt. In fact, this document assumes that binding as +a baseline, and only documents the differences between the two bindings. + +Required properties: +- compatible: "nvidia,tegra124-pinmux" +- reg: Should contain the register physical address and length for each of + the pad control and mux registers. The first bank of address must be the + driver strength pad control register address and second bank address must + be pinmux register address. + +Tegra124 adds the following optional properties for pin configuration subnodes: +- nvidia,enable-input: Integer. Enable the pin's input path. 0: no, 1: yes. +- nvidia,open-drain: Integer. Enable open drain mode. 0: no, 1: yes. +- nvidia,lock: Integer. Lock the pin configuration against further changes +until reset. 0: no, 1: yes. +- nvidia,io-reset: Integer. Reset the IO path. 0: no, 1: yes. +- nvidia,rcv-sel: Integer. Select VIL/VIH receivers. 0: normal, 1: high. +- nvidia,drive-type: Integer. Valid range 0...3. + +The macros for options are defined in the +include/dt-binding/pinctrl/pinctrl-tegra.h. + +Please refer the Tegra TRM for complete details regarding which groups +support which functionality. + +Valid values for pin and group names are: + + per-pin mux groups: + +These all support nvidia,function, nvidia,tristate, nvidia,pull, +nvidia,enable-input. Some support nvidia,lock nvidia,open-drain, +nvidia,io-reset and nvidia,rcv-sel. + + ulpi_data0_po1, ulpi_data1_po2, ulpi_data2_po3, ulpi_data3_po4, + ulpi_data4_po5, ulpi_data5_po6, ulpi_data6_po7, ulpi_data7_po0, + ulpi_clk_py0, ulpi_dir_py1, ulpi_nxt_py2, ulpi_stp_py3, dap3_fs_pp0, + dap3_din_pp1, dap3_dout_pp2, dap3_sclk_pp3, pv0, pv1, sdmmc1_clk_pz0, + sdmmc1_cmd_pz1, sdmmc1_dat3_py4, sdmmc1_dat2_py5, sdmmc1_dat1_py6, + sdmmc1_dat0_py7, clk2_out_pw5, clk2_req_pcc5, hdmi_int_pn7, ddc_scl_pv4, + ddc_sda_pv5, uart2_rxd_pc3, uart2_txd_pc2, uart2_rts_n_pj6, + uart2_cts_n_pj5, uart3_txd_pw6, uart3_rxd_pw7, uart3_cts_n_pa1, + uart3_rts_n_pc0, pu0, pu1, pu2, pu3, pu4, pu5, pu6, gen1_i2c_scl_pc4, + gen1_i2c_sda_pc5, dap4_fs_pp4, dap4_din_pp5, dap4_dout_pp6, + dap4_sclk_pp7, clk3_out_pee0, clk3_req_pee1, pc7, pi5, pi7, pk0, pk1, + pj0, pj2, pk3, pk4, pk2, pi3, pi6, pg0, pg1, pg2, pg3, pg4, pg5, pg6, + pg7, ph0, ph1, ph2, ph3, ph4, ph5, ph6, ph7, pj7, pb0, pb1, pk7, pi0, + pi1, pi2, pi4, gen2_i2c_scl_pt5, gen2_i2c_sda_pt6, sdmmc4_clk_pcc4, + sdmmc4_cmd_pt7, sdmmc4_dat0_paa0, sdmmc4_dat1_paa1, sdmmc4_dat2_paa2, + sdmmc4_dat3_paa3, sdmmc4_dat4_paa4, sdmmc4_dat5_paa5, sdmmc4_dat6_paa6, + sdmmc4_dat7_paa7, cam_mclk_pcc0, pcc1, pbb0, cam_i2c_scl_pbb1, + cam_i2c_sda_pbb2, pbb3, pbb4, pbb5, pbb6, pbb7, pcc2, jtag_rtck, + pwr_i2c_scl_pz6, pwr_i2c_sda_pz7, kb_row0_pr0, kb_row1_pr1, kb_row2_pr2, + kb_row3_pr3, kb_row4_pr4, kb_row5_pr5, kb_row6_pr6, kb_row7_pr7, + kb_row8_ps0, kb_row9_ps1, kb_row10_ps2, kb_row11_ps3, kb_row12_ps4, + kb_row13_ps5, kb_row14_ps6, kb_row15_ps7, kb_col0_pq0, kb_col1_pq1, + kb_col2_pq2, kb_col3_pq3, kb_col4_pq4, kb_col5_pq5, kb_col6_pq6, + kb_col7_pq7, clk_32k_out_pa0, core_pwr_req, cpu_pwr_req, pwr_int_n, + clk_32k_in, owr, dap1_fs_pn0, dap1_din_pn1, dap1_dout_pn2, + dap1_sclk_pn3, dap_mclk1_req_pee2, dap_mclk1_pw4, spdif_in_pk6, + spdif_out_pk5, dap2_fs_pa2, dap2_din_pa4, dap2_dout_pa5, dap2_sclk_pa3, + dvfs_pwm_px0, gpio_x1_aud_px1, gpio_x3_aud_px3, dvfs_clk_px2, + gpio_x4_aud_px4, gpio_x5_aud_px5, gpio_x6_aud_px6, gpio_x7_aud_px7, + sdmmc3_clk_pa6, sdmmc3_cmd_pa7, sdmmc3_dat0_pb7, sdmmc3_dat1_pb6, + sdmmc3_dat2_pb5, sdmmc3_dat3_pb4, pex_l0_rst_n_pdd1, + pex_l0_clkreq_n_pdd2, pex_wake_n_pdd3, pex_l1_rst_n_pdd5, + pex_l1_clkreq_n_pdd6, hdmi_cec_pee3, sdmmc1_wp_n_pv3, + sdmmc3_cd_n_pv2, gpio_w2_aud_pw2, gpio_w3_aud_pw3, usb_vbus_en0_pn4, + usb_vbus_en1_pn5, sdmmc3_clk_lb_out_pee4, sdmmc3_clk_lb_in_pee5, + gmi_clk_lb, reset_out_n, kb_row16_pt0, kb_row17_pt1,
Re: [REPOST PATCH V2] irq: enable all irqs unconditionally in irq_resume
Hi Laxman, Am Donnerstag, 5. Dezember 2013, 11:49:05 schrieb Laxman Dewangan: > Can you please review this patch? > This patch is pending from long back for review. the patch already made it into the appropriate tree, as can be seen by tip-bot message and on [0]. Heiko [0] http://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=irq-urgent-for-linus=ac01810c9d2814238f08a227062e66a35a0e1ea2 -- 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/4] ARM: tegra: select PINCTRL_TEGRA124 for Tegra124 SoC
The pincontrol driver for Tegra124 is build through config PINCTRL_TEGRA124. Select this config option whenever Tegra124 SoC is enabled. Signed-off-by: Laxman Dewangan --- arch/arm/mach-tegra/Kconfig |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-tegra/Kconfig b/arch/arm/mach-tegra/Kconfig index 09e740f..807e7bc 100644 --- a/arch/arm/mach-tegra/Kconfig +++ b/arch/arm/mach-tegra/Kconfig @@ -63,6 +63,7 @@ config ARCH_TEGRA_124_SOC bool "Enable support for Tegra124 family" select ARM_L1_CACHE_SHIFT_6 select HAVE_ARM_ARCH_TIMER + select PINCTRL_TEGRA124 help Support for NVIDIA Tegra T124 processor family, based on the ARM CortexA15MP CPU -- 1.7.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 tip/core/locking 0/4] Memory-barrier documentation updates
On Wed, Dec 04, 2013 at 02:46:28PM -0800, Paul E. McKenney wrote: > Hello! Hi Paul, > This series applies some long-needed updates to memory-barriers.txt: > > 1.Add ACCESS_ONCE() calls where needed to ensure their inclusion > in code copy-and-pasted from this file. > > 2.Add long atomic examples alongside the existing atomics. > > 3.Prohibit architectures supporting the Linux kernel from > speculating stores. Just me, or is the 3rd patch missing from lkml? > 4.Document what ACCESS_ONCE() does along with a number of situations > requiring its use. This was very useful, thanks! :) -- Henrik Austad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 00/38] perf/core improvements and fixes
* Ingo Molnar wrote: > > never saw that one.. starting your test on 24 CPUs server now > > I saw it again on a system by running two parallel build jobs: > > D=/tmp/perf-1; mkdir -p $D; while make O=$D install; do make O=$D clean; > done > D=/tmp/perf-2; mkdir -p $D; while make O=$D install; do make O=$D clean; > done I'm running it now with the previous perf/core - no failures so far, after dozens of build passes. 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 v3 1/3] Documentation: arm: add UEFI support documentation
On Mon, 2 Dec 2013 13:51:22 -0600, Matt Sealey wrote: > > +UEFI kernel support on ARM > > +== > > +UEFI kernel support on the ARM architectures (arm and arm64) is only > > available > > +when boot is performed through the stub. > > + > > +The stub populates the FDT /chosen node with (and the kernel scans for) the > > +following parameters: > > + > > +Name | Size | Description > > + > > +linux,uefi-system-table | 64-bit | Physical address of the UEFI System > > Table. > > + > > +linux,uefi-mmap-start | 64-bit | Physical address of the UEFI memory > > map, > > + || populated by the UEFI GetMemoryMap() > > call. > > + > > +linux,uefi-mmap-size | 32-bit | Size in bytes of the UEFI memory map > > + || pointed to in previous entry. > > + > > +linux,uefi-mmap-desc-size | 32-bit | Size in bytes of each entry in the > > UEFI > > + || memory map. > > + > > +linux,uefi-mmap-desc-ver | 32-bit | Version of the mmap descriptor format. > > + > > +linux,uefi-stub-kern-ver | string | Copy of linux_banner from build. > > + > > This flies in the face of actually using #address-cells and > #size-cells to define how big addresses and sizes are. You're limited > here by the root node definitions... that's the spec. > > Here's where I think this whole thing falls down as being the weirdest > possible implementation of this. It defies logic to put this > information in the device tree /chosen node while also attempting to > boot the kernel using an EFI stub; the stub is going to have this > information because it is going to have the pointer to the system > System Table (since it was called by StartImage()). Why not stash the > System Table pointer somewhere safe in the stub? Everything here is about getting from the stub to the kernel. We have a boot interface for the kernel proper. It works, and this patch set works with it. Also, this is effectively a kernel-internal interface between the stub and the kernel so there aren't any ABI issues that we need to deail with. Go ahead and propose patches for a better interface, but in the mean time I see no reason not to merge this series. g. -- 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: [REPOST PATCH V2] irq: enable all irqs unconditionally in irq_resume
Hi Thomas, On Monday 25 November 2013 07:39 PM, Laxman Dewangan wrote: When system enters into suspend, it disable all irqs in single function call. This disables EARLY_RESUME irqs also along with normal irqs. The EARLY_RESUME irqs get enabled in sys_core_ops->resume and non-EARLY_RESUME irqs get enabled in normal system resume path. When suspend_noirq failed or suspend is aborted for any reason, the EARLY_RESUME irqs do not get enabled as sys_core_ops->resume() call did not happen. It only enables the non-EARLY_RESUME irqs in normal disable for remaining life of system. Enable all irqs unconditionally in normal irq_resume() regardless of EARLY_RESUME irqs have been already enabled or not. Signed-off-by: Laxman Dewangan Acked-by-and-tested-by: Konrad Rzeszutek Wilk Acked-by: Heiko Stuebner Reviewed-by: Pavel Machek Can you please review this patch? This patch is pending from long back for review. Thanks, Laxman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL 00/38] perf/core improvements and fixes
* Jiri Olsa wrote: > On Thu, Dec 05, 2013 at 11:04:29AM +0100, Ingo Molnar wrote: > > > > * Arnaldo Carvalho de Melo wrote: > > > > > From: Arnaldo Carvalho de Melo > > > > > > Hi Ingo, > > > > > > Please consider pulling, > > > > > > - Arnaldo > > > > > > The following changes since commit > > > 89e3bbd58a6186b832fe2b9419ac2f9ab90e9089: > > > > > > Merge tag 'perf-core-for-mingo' of > > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core > > > (2013-12-04 10:17:17 +0100) > > > > > > are available in the git repository at: > > > > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux > > > tags/perf-core-for-mingo > > > > Hm, I saw such a build failure: > > > > CC FPIC plugin_kmem.o > > BUILDPLUGIN plugin_jbd2.so > > plugin_jbd2.o: file not recognized: File truncated > > collect2: error: ld returned 1 exit status > > make[2]: *** [plugin_jbd2.so] Error 1 > > make[1]: *** [install-traceevent-plugins] Error 2 > > make[1]: *** Waiting for unfinished jobs > > CC FPIC plugin_kvm.o > > CC FPIC plugin_mac80211.o > > > > which suggests some sort of build race ... > > > > I was doing several 'make clean; make install' runs - and the second > > run failed. Unfortunately the failure was not reproducible after that > > point - and I tried dozens of times. The test system has 12 CPUs. > > > > The following loop attempts to build until a failure occurs: > > > > cd tools/perf/ > > while make install; do make clean; done > > > > Any ideas? > > never saw that one.. starting your test on 24 CPUs server now I saw it again on a system by running two parallel build jobs: D=/tmp/perf-1; mkdir -p $D; while make O=$D install; do make O=$D clean; done D=/tmp/perf-2; mkdir -p $D; while make O=$D install; do make O=$D clean; done one failed with: BUILDPLUGIN plugin_kmem.so make[2]: *** [sub-make] Error 2 make[1]: *** [/tmp/perf-1/libtraceevent.a] Error 2 make[1]: *** Waiting for unfinished jobs BUILDPLUGIN plugin_kvm.so the other with: CC FPIC plugin_cfg80211.o CC /tmp/perf-2/builtin-help.o CC /tmp/perf-2/builtin-sched.o plugin_sched_switch.o: file not recognized: File truncated collect2: error: ld returned 1 exit status make[3]: *** [plugin_sched_switch.so] Error 1 BUILDPLUGIN plugin_function.so and that's clearly the new plugin code. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 2/4] ARM: tegra: convert dts files of Tegra114 platforms to use pinctrl defines
Use Tegra pinconrol dt-binding macro to set the values of different pinmux
properties of Tegra114 platforms.
Signed-off-by: Laxman Dewangan
---
Changes from V1:
- Changes based on new macro name.
Changes from V2:
- Add description in commit message.
arch/arm/boot/dts/tegra114-dalmore.dts | 548
arch/arm/boot/dts/tegra114.dtsi|1 +
2 files changed, 275 insertions(+), 274 deletions(-)
diff --git a/arch/arm/boot/dts/tegra114-dalmore.dts
b/arch/arm/boot/dts/tegra114-dalmore.dts
index cb5ec23..1fe2656 100644
--- a/arch/arm/boot/dts/tegra114-dalmore.dts
+++ b/arch/arm/boot/dts/tegra114-dalmore.dts
@@ -19,41 +19,41 @@
clk1_out_pw4 {
nvidia,pins = "clk1_out_pw4";
nvidia,function = "extperiph1";
- nvidia,pull = <0>;
- nvidia,tristate = <0>;
- nvidia,enable-input = <0>;
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
};
dap1_din_pn1 {
nvidia,pins = "dap1_din_pn1";
nvidia,function = "i2s0";
- nvidia,pull = <0>;
- nvidia,tristate = <1>;
- nvidia,enable-input = <1>;
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
};
dap1_dout_pn2 {
nvidia,pins = "dap1_dout_pn2",
"dap1_fs_pn0",
"dap1_sclk_pn3";
nvidia,function = "i2s0";
- nvidia,pull = <0>;
- nvidia,tristate = <0>;
- nvidia,enable-input = <1>;
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
};
dap2_din_pa4 {
nvidia,pins = "dap2_din_pa4";
nvidia,function = "i2s1";
- nvidia,pull = <0>;
- nvidia,tristate = <1>;
- nvidia,enable-input = <1>;
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
};
dap2_dout_pa5 {
nvidia,pins = "dap2_dout_pa5",
"dap2_fs_pa2",
"dap2_sclk_pa3";
nvidia,function = "i2s1";
- nvidia,pull = <0>;
- nvidia,tristate = <0>;
- nvidia,enable-input = <1>;
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
};
dap4_din_pp5 {
nvidia,pins = "dap4_din_pp5",
@@ -61,17 +61,17 @@
"dap4_fs_pp4",
"dap4_sclk_pp7";
nvidia,function = "i2s3";
- nvidia,pull = <0>;
- nvidia,tristate = <0>;
- nvidia,enable-input = <1>;
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
};
dvfs_pwm_px0 {
nvidia,pins = "dvfs_pwm_px0",
"dvfs_clk_px2";
nvidia,function = "cldvfs";
- nvidia,pull = <0>;
- nvidia,tristate = <0>;
- nvidia,enable-input = <0>;
+ nvidia,pull = ;
+ nvidia,tristate = ;
+ nvidia,enable-input = ;
};
ulpi_clk_py0 {
nvidia,pins = "ulpi_clk_py0",
@@ -84,128 +84,128 @@
"ulpi_data6_po7",
"ulpi_data7_po0";
[PATCH V3 0/4] ARM: tegra: convert dts files of all Tegra platforms to use pinctrl defines
This patch series convert dts files of all Tegra's platforms to use the pinctron dt-binding macro for better readability. Changes from V1: - Get rid of lots of macro and converge it to TEGRA_PIN_ENABLE/DISABLE. - Change macro name for PULL UP/DOWN/NONE. Changes from V2: - Add more comment on defines. - Add two more patches for having simialr change for Tegra20 and Tegra30 platforms. Laxman Dewangan (4): ARM: tegra: Add header file for pinctrl constants ARM: tegra: convert dts files of Tegra114 platforms to use pinctrl defines ARM: tegra: convert dts files of Tegra20 platforms to use pinctrl defines ARM: tegra: convert dts files of Tegra30 platforms to use pinctrl defines arch/arm/boot/dts/tegra114-dalmore.dts | 548 +- arch/arm/boot/dts/tegra114.dtsi |1 + arch/arm/boot/dts/tegra20-colibri-512.dtsi | 104 +++--- arch/arm/boot/dts/tegra20-harmony.dts | 30 +- arch/arm/boot/dts/tegra20-iris-512.dts | 10 +- arch/arm/boot/dts/tegra20-paz00.dts | 30 +- arch/arm/boot/dts/tegra20-seaboard.dts | 44 +- arch/arm/boot/dts/tegra20-tamonten.dtsi | 30 +- arch/arm/boot/dts/tegra20-trimslice.dts | 34 +- arch/arm/boot/dts/tegra20-ventana.dts | 44 +- arch/arm/boot/dts/tegra20-whistler.dts | 40 +- arch/arm/boot/dts/tegra20.dtsi |1 + arch/arm/boot/dts/tegra30-beaver.dts| 34 +- arch/arm/boot/dts/tegra30-cardhu.dtsi | 40 +- arch/arm/boot/dts/tegra30.dtsi |1 + include/dt-bindings/pinctrl/pinctrl-tegra.h | 45 +++ 16 files changed, 542 insertions(+), 494 deletions(-) create mode 100644 include/dt-bindings/pinctrl/pinctrl-tegra.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] Remove unnecessarily gendered language
On Mon 2013-12-02 20:18:52, Matthew Garrett wrote: > The kernel as a number of cases of gendered language. The majority of these > refer to objects that don't have gender in English, and so I've replaced > them with "it" and "its". Some refer to people (developers or users), and > I've replaced these with the singular "they" variant. Some are simply > typos that I've fixed up. Why is this good idea? I don't think this makes documentation better. > @@ -127,7 +127,7 @@ gid= > umask= Provide default owner, group, and access mode > mask. > These options work as documented in mount(8). By > default, the files/directories are owned by root and > - he/she has read and write permissions, as well as > + they have read and write permissions, as well as > browse permission for directories. No one else has any > access permissions. I.e. the mode on all files is by > default rw--- and for directories rwx--, a So... we had unambiguous text "user has read and write permissions" and now you have to wonder if they refers to "user" or "files/directories". (And I'm pretty sure most people will parse it the wrong way.) > @@ -23,7 +24,7 @@ Quota netlink interface > When user exceeds a softlimit, runs out of grace time or reaches hardlimit, > quota subsystem traditionally printed a message to the controlling terminal > of > the process which caused the excess. This method has the disadvantage that > -when user is using a graphical desktop he usually cannot see the message. > +when user is using a graphical desktop they usually cannot see the > message. Is this even correct english? NAK, FWIW. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/
[PATCH V3 4/4] ARM: tegra: convert dts files of Tegra30 platforms to use pinctrl defines
Use Tegra pinconrol dt-binding macro to set the values of different pinmux
properties of Tegra30 platforms.
Signed-off-by: Laxman Dewangan
---
- New patch on this series.
arch/arm/boot/dts/tegra30-beaver.dts | 34 ++--
arch/arm/boot/dts/tegra30-cardhu.dtsi | 40
arch/arm/boot/dts/tegra30.dtsi|1 +
3 files changed, 38 insertions(+), 37 deletions(-)
diff --git a/arch/arm/boot/dts/tegra30-beaver.dts
b/arch/arm/boot/dts/tegra30-beaver.dts
index 08cad69..48b89a4 100644
--- a/arch/arm/boot/dts/tegra30-beaver.dts
+++ b/arch/arm/boot/dts/tegra30-beaver.dts
@@ -52,8 +52,8 @@
sdmmc1_clk_pz0 {
nvidia,pins = "sdmmc1_clk_pz0";
nvidia,function = "sdmmc1";
- nvidia,pull = <0>;
- nvidia,tristate = <0>;
+ nvidia,pull = ;
+ nvidia,tristate = ;
};
sdmmc1_cmd_pz1 {
nvidia,pins = "sdmmc1_cmd_pz1",
@@ -62,14 +62,14 @@
"sdmmc1_dat2_py5",
"sdmmc1_dat3_py4";
nvidia,function = "sdmmc1";
- nvidia,pull = <2>;
- nvidia,tristate = <0>;
+ nvidia,pull = ;
+ nvidia,tristate = ;
};
sdmmc3_clk_pa6 {
nvidia,pins = "sdmmc3_clk_pa6";
nvidia,function = "sdmmc3";
- nvidia,pull = <0>;
- nvidia,tristate = <0>;
+ nvidia,pull = ;
+ nvidia,tristate = ;
};
sdmmc3_cmd_pa7 {
nvidia,pins = "sdmmc3_cmd_pa7",
@@ -78,15 +78,15 @@
"sdmmc3_dat2_pb5",
"sdmmc3_dat3_pb4";
nvidia,function = "sdmmc3";
- nvidia,pull = <2>;
- nvidia,tristate = <0>;
+ nvidia,pull = ;
+ nvidia,tristate = ;
};
sdmmc4_clk_pcc4 {
nvidia,pins = "sdmmc4_clk_pcc4",
"sdmmc4_rst_n_pcc3";
nvidia,function = "sdmmc4";
- nvidia,pull = <0>;
- nvidia,tristate = <0>;
+ nvidia,pull = ;
+ nvidia,tristate = ;
};
sdmmc4_dat0_paa0 {
nvidia,pins = "sdmmc4_dat0_paa0",
@@ -98,8 +98,8 @@
"sdmmc4_dat6_paa6",
"sdmmc4_dat7_paa7";
nvidia,function = "sdmmc4";
- nvidia,pull = <2>;
- nvidia,tristate = <0>;
+ nvidia,pull = ;
+ nvidia,tristate = ;
};
dap2_fs_pa2 {
nvidia,pins = "dap2_fs_pa2",
@@ -107,18 +107,18 @@
"dap2_din_pa4",
"dap2_dout_pa5";
nvidia,function = "i2s1";
- nvidia,pull = <0>;
- nvidia,tristate = <0>;
+ nvidia,pull = ;
+ nvidia,tristate = ;
};
pex_l1_prsnt_n_pdd4 {
nvidia,pins = "pex_l1_prsnt_n_pdd4",
"pex_l1_clkreq_n_pdd6";
- nvidia,pull = <2>;
+ nvidia,pull = ;
};
sdio3 {
nvidia,pins = "drive_sdio3";
- nvidia,high-speed-mode = <0>;
- nvidia,schmitt = <0>;
+ nvidia,high-speed-mode = ;
+ nvidia,schmitt = ;
nvidia,pull-down-strength = <46>;
nvidia,pull-up-strength = <42>;
nvidia,slew-rate-rising = <1>;
diff --git
[PATCH V3 1/4] ARM: tegra: Add header file for pinctrl constants
This new header file defines pincontrol constants for Tegra to use from Tegra's DTS file for pincontrol properties option. Signed-off-by: Laxman Dewangan Reviewed-by: Thierry Reding --- Changes from V1: - Get rid of lots of macro and converge it to TEGRA_PIN_ENABLE/DISABLE. - Change macro name for PULL UP/DOWN/NONE. Changes from V2: - Convert TEGRA -> Tegra. - Add comment on ENABLE/DSIABLE and remove from pulls. include/dt-bindings/pinctrl/pinctrl-tegra.h | 45 +++ 1 files changed, 45 insertions(+), 0 deletions(-) create mode 100644 include/dt-bindings/pinctrl/pinctrl-tegra.h diff --git a/include/dt-bindings/pinctrl/pinctrl-tegra.h b/include/dt-bindings/pinctrl/pinctrl-tegra.h new file mode 100644 index 000..ebafa49 --- /dev/null +++ b/include/dt-bindings/pinctrl/pinctrl-tegra.h @@ -0,0 +1,45 @@ +/* + * This header provides constants for Tegra pinctrl bindings. + * + * Copyright (c) 2013, NVIDIA CORPORATION. All rights reserved. + * + * Author: Laxman Dewangan + * + * This program is free software; you can redistribute it and/or modify it + * under the terms and conditions of the GNU General Public License, + * version 2, as published by the Free Software Foundation. + * + * This program is distributed in the hope 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. + */ + +#ifndef _DT_BINDINGS_PINCTRL_TEGRA_H +#define _DT_BINDINGS_PINCTRL_TEGRA_H + +/* + * Enable/disable for diffeent dt properties. This is applicable for + * properties nvidia,enable-input, nvidia,tristate, nvidia,open-drain, + * nvidia,lock, nvidia,rcv-sel, nvidia,high-speed-mode, nvidia,schmitt. + */ +#define TEGRA_PIN_DISABLE 0 +#define TEGRA_PIN_ENABLE 1 + +#define TEGRA_PIN_PULL_NONE0 +#define TEGRA_PIN_PULL_DOWN1 +#define TEGRA_PIN_PULL_UP 2 + +/* Low power mode driver */ +#define TEGRA_PIN_LP_DRIVE_DIV_8 0 +#define TEGRA_PIN_LP_DRIVE_DIV_4 1 +#define TEGRA_PIN_LP_DRIVE_DIV_2 2 +#define TEGRA_PIN_LP_DRIVE_DIV_1 3 + +/* Rising/Falling slew rate */ +#define TEGRA_PIN_SLEW_RATE_FASTEST0 +#define TEGRA_PIN_SLEW_RATE_FAST 1 +#define TEGRA_PIN_SLEW_RATE_SLOW 2 +#define TEGRA_PIN_SLEW_RATE_SLOWEST3 + +#endif -- 1.7.1.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V3 3/4] ARM: tegra: convert dts files of Tegra20 platforms to use pinctrl defines
Use Tegra pinconrol dt-binding macro to set the values of different pinmux
properties of Tegra20 platforms.
Signed-off-by: Laxman Dewangan
---
- New patch on this series.
arch/arm/boot/dts/tegra20-colibri-512.dtsi | 104 ++--
arch/arm/boot/dts/tegra20-harmony.dts | 30
arch/arm/boot/dts/tegra20-iris-512.dts | 10 ++--
arch/arm/boot/dts/tegra20-paz00.dts| 30
arch/arm/boot/dts/tegra20-seaboard.dts | 44 ++--
arch/arm/boot/dts/tegra20-tamonten.dtsi| 30
arch/arm/boot/dts/tegra20-trimslice.dts| 34 +-
arch/arm/boot/dts/tegra20-ventana.dts | 44 ++--
arch/arm/boot/dts/tegra20-whistler.dts | 40 +-
arch/arm/boot/dts/tegra20.dtsi |1 +
10 files changed, 184 insertions(+), 183 deletions(-)
diff --git a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
index d5c9bca..6ae66ad 100644
--- a/arch/arm/boot/dts/tegra20-colibri-512.dtsi
+++ b/arch/arm/boot/dts/tegra20-colibri-512.dtsi
@@ -27,20 +27,20 @@
audio_refclk {
nvidia,pins = "cdev1";
nvidia,function = "plla_out";
- nvidia,pull = <0>;
- nvidia,tristate = <0>;
+ nvidia,pull = ;
+ nvidia,tristate = ;
};
crt {
nvidia,pins = "crtp";
nvidia,function = "crt";
- nvidia,pull = <0>;
- nvidia,tristate = <1>;
+ nvidia,pull = ;
+ nvidia,tristate = ;
};
dap3 {
nvidia,pins = "dap3";
nvidia,function = "dap3";
- nvidia,pull = <0>;
- nvidia,tristate = <0>;
+ nvidia,pull = ;
+ nvidia,tristate = ;
};
displaya {
nvidia,pins = "ld0", "ld1", "ld2", "ld3",
@@ -50,151 +50,151 @@
"lhs", "lpw0", "lpw2", "lsc0",
"lsc1", "lsck", "lsda", "lspi", "lvs";
nvidia,function = "displaya";
- nvidia,tristate = <1>;
+ nvidia,tristate = ;
};
gpio_dte {
nvidia,pins = "dte";
nvidia,function = "rsvd1";
- nvidia,pull = <0>;
- nvidia,tristate = <0>;
+ nvidia,pull = ;
+ nvidia,tristate = ;
};
gpio_gmi {
nvidia,pins = "ata", "atc", "atd", "ate",
"dap1", "dap2", "dap4", "gpu", "irrx",
"irtx", "spia", "spib", "spic";
nvidia,function = "gmi";
- nvidia,pull = <0>;
- nvidia,tristate = <0>;
+ nvidia,pull = ;
+ nvidia,tristate = ;
};
gpio_pta {
nvidia,pins = "pta";
nvidia,function = "rsvd4";
- nvidia,pull = <0>;
- nvidia,tristate = <0>;
+ nvidia,pull = ;
+ nvidia,tristate = ;
};
gpio_uac {
nvidia,pins = "uac";
nvidia,function = "rsvd2";
- nvidia,pull = <0>;
- nvidia,tristate = <0>;
+ nvidia,pull = ;
+ nvidia,tristate = ;
};
hdint {
nvidia,pins = "hdint";
nvidia,function = "hdmi";
- nvidia,tristate = <1>;
+ nvidia,tristate = ;
};
i2c1 {
nvidia,pins = "rm";
nvidia,function = "i2c1";
- nvidia,pull = <0>;
- nvidia,tristate = <1>;
+ nvidia,pull = ;
+
Re: [PATCH 28/28] perf tools: Add udis86 disassembler feature check
* Jiri Olsa wrote: > On Thu, Dec 05, 2013 at 10:25:02AM +0100, Ingo Molnar wrote: > > > > * Jiri Olsa wrote: > > > > > On Wed, Dec 04, 2013 at 03:50:24PM -0300, Arnaldo Carvalho de Melo wrote: > > > > Em Tue, Dec 03, 2013 at 02:09:42PM +0100, Jiri Olsa escreveu: > > > > > Adding udis86 disassembler feature check which support > > > > > is needed for kvm:kvm_emulate_insn tracepoint. > > > > > > > > > > +$(call feature_check,udis86) > > > > > +ifeq ($(feature-udis86), 1) > > > > > + LIBTRACEEVENT_CFLAGS += -DHAVE_UDIS86 > > > > > + EXTLIBS += -ludis86 > > > > > +else > > > > > + msg := $(warning No udis86 support.); > > > > > +endif > > > > > > > > That is really an incomplete message, what package should I install? > > > > Perhaps we should add this there then: > > > > > > > > http://bit.ly/1hyrN52 > > > > > > nice :-) > > > > > > > > > > > Wow, that was easy, but yeah, could be made easier 8-) ;-P > > > > > > so something like: > > > No udis86 found. Please install udis86-devel. > > > > > > or: > > > No udis86 found, disabling kvm tracepoints instruction disassembly. > > > Please install udis86-devel. > > > > 1) > > > > So, the first problem I can see is in the output: > > > > Auto-detecting system features: > > ... backtrace: [ on ] > > ... dwarf: [ on ] > > ...fortify-source: [ on ] > > ... glibc: [ on ] > > ... gtk2: [ on ] > > ... gtk2-infobar: [ on ] > > ... libaudit: [ on ] > > ...libbfd: [ on ] > > ...libelf: [ on ] > > ... libelf-getphdrnum: [ on ] > > ... libelf-mmap: [ on ] > > ... libnuma: [ on ] > > ... libperl: [ on ] > > ... libpython: [ on ] > > ... libpython-version: [ on ] > > ... libslang: [ on ] > > ... libunwind: [ on ] > > ... on-exit: [ on ] > > ...stackprotector-all: [ on ] > > ... timerfd: [ on ] > > > > config/Makefile:421: No udis86 support. > > > > such a 'no XYZ support' message should only occur if a feature test > > failed. _If_ we decide that 'udis86' support is required for a full > > perf build then there should be a new line saying something like: > > > > ...udis86: [ OFF ] > > hum, just sent v4 that added udis86 into above list ;-) > > So.. do we consider 'full perf build' to be build with all > possible libraries linked in? So my worry is, how widely is libudis86 available in distros? What is the package name on Debian/Ubuntu for example? 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 v4 12/15] usb: phy: msm: Add support for secondary PHY control
On Mon, Nov 18, 2013 at 12:57:42PM +, Ivan T. Ivanov wrote: > > Hi Mark, > > On Fri, 2013-11-15 at 16:42 +, Mark Rutland wrote: > > On Tue, Nov 12, 2013 at 02:51:47PM +, Ivan T. Ivanov wrote: > > > From: "Ivan T. Ivanov" > > > > > > Allow support to use 2nd HSPHY with USB2 Core. > > > Some platforms may have configuration to allow USB controller > > > work with any of the two HSPHYs present. By default driver > > > configures USB core to use primary HSPHY. Add support to allow > > > user select 2nd HSPHY using DT parameter. > > > > > > Signed-off-by: Ivan T. Ivanov > > > Cc: Manu Gautam > > > Cc: devicet...@vger.kernel.org > > > --- > > > .../devicetree/bindings/usb/msm-hsusb.txt |6 + > > > drivers/usb/phy/phy-msm-usb.c | 24 > > > ++-- > > > include/linux/usb/msm_hsusb.h |1 + > > > include/linux/usb/msm_hsusb_hw.h |1 + > > > 4 files changed, 30 insertions(+), 2 deletions(-) > > > > > > diff --git a/Documentation/devicetree/bindings/usb/msm-hsusb.txt > > > b/Documentation/devicetree/bindings/usb/msm-hsusb.txt > > > index 3f21204..d105ba9 100644 > > > --- a/Documentation/devicetree/bindings/usb/msm-hsusb.txt > > > +++ b/Documentation/devicetree/bindings/usb/msm-hsusb.txt > > > @@ -72,6 +72,12 @@ Optional properties: > > > - qcom,phy-init-sequence: PHY configuration sequence. val, reg pairs > > > terminate with -1 > > > > > > +- qcom,phy-num: Select number of pyco-phy to use, can be one of > > > + 0 - PHY one, default > > > + 1 - Second PHY > > > + Some platforms may have configuration to allow > > > USB > > > + controller work with any of the two HSPHYs > > > present. > > > + > > > > Only one can be used at a time? > > Yes only one of them. Selected at driver init time. Ok. For a given platform, is it likely that both are wired up and _possibly_ usable? 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 v4 10/15] usb: phy: msm: Add device tree support and binding information
On Mon, Nov 18, 2013 at 12:54:37PM +, Ivan T. Ivanov wrote: > Hi Mark, > > On Fri, 2013-11-15 at 16:38 +, Mark Rutland wrote: > > On Tue, Nov 12, 2013 at 02:51:45PM +, Ivan T. Ivanov wrote: > > > From: "Ivan T. Ivanov" > > > > > > Allows MSM OTG controller to be specified via device tree. > > > > > > Signed-off-by: Ivan T. Ivanov > > > Cc: devicet...@vger.kernel.org > > > --- > > > .../devicetree/bindings/usb/msm-hsusb.txt | 57 +- > > > drivers/usb/phy/phy-msm-usb.c | 79 > > > +--- > > > 2 files changed, 124 insertions(+), 12 deletions(-) [...] > > > + > > > +- dr_mode: One of "host", "peripheral" or "otg". Defaults > > > to "otg" > > > > If this has a default and thus isn't required, it should be listed as > > optional. > > This is part of the standard USB bindings, Perhaps I could just > refer to: Documentation/devicetree/bindings/usb/generic.txt That would be fine, but it should also be moved to the optional properties section. > > > > > > > + > > > +- vdccx-supply: phandle to the regulator for the vdd supply for > > > + digital circuit operation. > > > +- v1p8-supply: phandle to the regulator for the 1.8V supply > > > +- v3p3-supply: phandle to the regulator for the 3.3V supply > > > + > > > +- qcom,otg-control: OTG control (VBUS and ID notifications) can be one of > > > + 1 - PHY control > > > + 2 - PMIC control > > > + 3 - User control (via debugfs) > > > > NAK. This does not seem like a description of the hardware, and given > > the debugfs comment is fundamentally tied to the way Linux functions > > today. > > I will remove option 3, but rest are really property of the chipset. Can you elaborate on the diffence please? > > > > > > + > > > +Optional properties: > > > +- qcom,phy-init-sequence: PHY configuration sequence. val, reg pairs > > > + terminate with -1 > > > > What is this? I'm really not keen on having arbitrary register/memory > > poking sequences in the dt. > > This is related Device Mode Eye Diagram test and values used could be > different between chipsets. Ok. Then we should encode the tuning data rather than adding a mechanism to allow for writes to arbitrary addresses. > > > > > Why does it need to be terminated? Surely the size of the property tells > > you that it's terminated. > > Yes. -1 termination could be done in driver. Please do. There's no need for it to be in the DT. Cheers, 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 PATCH tip 0/5] tracing filters with BPF
* Alexei Starovoitov wrote:
> > On Tue, Dec 3, 2013 at 4:01 PM, Andi Kleen wrote:
> >>
> >> Can you do some performance comparison compared to e.g. ktap?
> >> How much faster is it?
>
> Did simple ktap test with 1M alloc_skb/kfree_skb toy test from earlier email:
> trace skb:kfree_skb {
> if (arg2 == 0x100) {
> printf("%x %x\n", arg1, arg2)
> }
> }
> 1M skb alloc/free 350315 (usecs)
>
> baseline without any tracing:
> 1M skb alloc/free 145400 (usecs)
>
> then equivalent bpf test:
> void filter(struct bpf_context *ctx)
> {
> void *loc = (void *)ctx->regs.dx;
> if (loc == 0x100) {
> struct sk_buff *skb = (struct sk_buff *)ctx->regs.si;
> char fmt[] = "skb %p loc %p\n";
> bpf_trace_printk(fmt, sizeof(fmt), (long)skb, (long)loc, 0);
> }
> }
> 1M skb alloc/free 183214 (usecs)
>
> so with one 'if' condition the difference ktap vs bpf is 350-145 vs 183-145
>
> obviously ktap is an interpreter, so it's not really fair.
>
> To make it really unfair I did:
> trace skb:kfree_skb {
> if (arg2 == 0x100 || arg2 == 0x200 || arg2 == 0x300 || arg2 == 0x400
> ||
> arg2 == 0x500 || arg2 == 0x600 || arg2 == 0x700 || arg2 == 0x800
> ||
> arg2 == 0x900 || arg2 == 0x1000) {
> printf("%x %x\n", arg1, arg2)
> }
> }
> 1M skb alloc/free 484280 (usecs)
Real life scripts, for examples the ones related to network protocol
analysis will often have such patterns in them, so I don't think this
measurement is particularly unfair.
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: [RFC PATCH tip 0/5] tracing filters with BPF
* Alexei Starovoitov wrote: > > I mean more than that, I mean the licensing of BFP filters a user > > can find on his own system's kernel should be very clear: by the > > act of loading a BFP script into the kernel the user doing the > > 'upload' gives permission for it to be redistributed on > > kernel-compatible license terms. > > > > The easiest way to achieve that is to make sure that all loaded > > BFP scripts are 'registered' and are dumpable, viewable and > > reusable. That's good for debugging and it's good for > > transparency. > > > > This means a minimal BFP decoder will have to be in the kernel as > > well, but that's OK, we actually have several x86 instruction > > decoder in the kernel already, so there's no complexity threshold. > > sure. there is pr_info_bpf_insn() in bpf_run.c that dumps bpf insn in > human readable format. > I'll hook it up to trace_seq, so that "cat > /sys/kernel/debug/.../filter" will dump it. > > Also I'm thinking to add 'license_string' section to bpf binary format > and call license_is_gpl_compatible() on it during load. > If false, then just reject it…. not even messing with taint flags... > That would be way stronger indication of bpf licensing terms than what > we have for .ko But will BFP tools generate such gpl-compatible license tags by default? If yes then this might work, combined with the facility below. If not then it's just a nuisance to users. Also, 'tainting' is a non-issue here, as we don't want the kernel to load license-incompatible scripts at all. This should be made clear in the design of the facility and the tooling itself. > >> wow. I guess if the whole thing takes off, we would need an > >> in-kernel directory to store upstreamed bpf filters as well :) > > > > I see no reason why not, but more importantly all currently loaded > > BFP scripts should be dumpable, displayable and reusable in a > > kernel license compatible fashion. > > ok. will add global bpf list as well (was hesitating to do something > like this because of central lock) A lock + list is no big issue here I think, we do such central lookup locks all the time. If it ever becomes measurable it can be made scalable via numerous techniques. > and something in debugfs that dumps bodies of all currently loaded > filters. > > Will that solve the concern? My concern would be solved by adding a facility to always be able to dump source code as well, i.e. trivially transform it to C or so, so that people can review it - or just edit it on the fly, recompile and reinsert? Most BFP scripts ought to be pretty simple. (For example the most common way to load OpenGL shaders is to load the GLSL source code and that source code can be queried after insertion as well, so this is not an unusual model for small plugin-alike scriptlets.) 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: [GIT PULL 00/38] perf/core improvements and fixes
On Thu, Dec 05, 2013 at 11:04:29AM +0100, Ingo Molnar wrote: > > * Arnaldo Carvalho de Melo wrote: > > > From: Arnaldo Carvalho de Melo > > > > Hi Ingo, > > > > Please consider pulling, > > > > - Arnaldo > > > > The following changes since commit 89e3bbd58a6186b832fe2b9419ac2f9ab90e9089: > > > > Merge tag 'perf-core-for-mingo' of > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core > > (2013-12-04 10:17:17 +0100) > > > > are available in the git repository at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux > > tags/perf-core-for-mingo > > Hm, I saw such a build failure: > > CC FPIC plugin_kmem.o > BUILDPLUGIN plugin_jbd2.so > plugin_jbd2.o: file not recognized: File truncated > collect2: error: ld returned 1 exit status > make[2]: *** [plugin_jbd2.so] Error 1 > make[1]: *** [install-traceevent-plugins] Error 2 > make[1]: *** Waiting for unfinished jobs > CC FPIC plugin_kvm.o > CC FPIC plugin_mac80211.o > > which suggests some sort of build race ... > > I was doing several 'make clean; make install' runs - and the second > run failed. Unfortunately the failure was not reproducible after that > point - and I tried dozens of times. The test system has 12 CPUs. > > The following loop attempts to build until a failure occurs: > > cd tools/perf/ > while make install; do make clean; done > > Any ideas? never saw that one.. starting your test on 24 CPUs server now jirka -- 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] cpufreq_ at32ap-cpufreq.c: Fix section mismatch
Around Thu 05 Dec 2013 10:59:57 +0100 or thereabout, Matthias Brugger wrote:
> The function at32_cpufreq_driver_init was marked as __init but will be
> called from inside the cpufreq framework. This lead to the following a
> section mismatch during compilation:
>
> WARNING: drivers/built-in.o(.data+0x2448): Section mismatch in reference
> from the variable at32_driver to the function
> .init.text:at32_cpufreq_driver_init()
> The variable at32_driver references
> the function __init at32_cpufreq_driver_init()
> If the reference is valid then annotate the
> variable with __init* or __refdata (see linux/init.h) or name the
> variable:
> *_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
You're right, it is added in struct cpufreq_driver, and AFAICT the cpufreq
core might call init every now and then.
Added to my for-linus branch.
> Signed-off-by: Matthias Brugger
Acked-by: Hans-Christian Egtvedt
> ---
> drivers/cpufreq/at32ap-cpufreq.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpufreq/at32ap-cpufreq.c
> b/drivers/cpufreq/at32ap-cpufreq.c
> index e0c38d9..372c426 100644
> --- a/drivers/cpufreq/at32ap-cpufreq.c
> +++ b/drivers/cpufreq/at32ap-cpufreq.c
> @@ -83,7 +83,7 @@ static int at32_set_target(struct cpufreq_policy *policy,
> return 0;
> }
>
> -static int __init at32_cpufreq_driver_init(struct cpufreq_policy *policy)
> +static int at32_cpufreq_driver_init(struct cpufreq_policy *policy)
> {
> if (policy->cpu != 0)
> return -EINVAL;
--
mvh
Hans-Christian Egtvedt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 2/2] mmc: sdhci-msm: Initial support for MSM chipsets
On Wed, Nov 06, 2013 at 03:56:45PM +, Georgi Djakov wrote:
> This platform driver adds the initial support of Secure
> Digital Host Controller Interface compliant controller
> found in Qualcomm MSM chipsets.
>
> Signed-off-by: Georgi Djakov
> ---
> drivers/mmc/host/Kconfig | 13 +
> drivers/mmc/host/Makefile|1 +
> drivers/mmc/host/sdhci-msm.c | 651
> ++
> 3 files changed, 665 insertions(+)
> create mode 100644 drivers/mmc/host/sdhci-msm.c
[...]
> +static int sdhci_msm_dt_parse_vreg_info(struct device *dev,
> + struct sdhci_msm_reg_data *vreg,
> + const char *vreg_name)
> +{
> + int len;
> + const __be32 *prop;
Seeing raw property handling in drivers worries me. If there's a reason
to touch the raw DTB we should add helpers to do it rather than leaking
binary format issues into drivers.
> + char prop_name[MAX_PROP_SIZE];
> + struct device_node *np = dev->of_node;
> +
> + snprintf(prop_name, MAX_PROP_SIZE, "%s-supply", vreg_name);
> + if (!of_parse_phandle(np, prop_name, 0)) {
> + dev_info(dev, "No vreg data found for %s\n", vreg_name);
> + return -EINVAL;
> + }
> +
> + vreg->name = vreg_name;
> +
> + snprintf(prop_name, MAX_PROP_SIZE, "qcom,%s-lpm-sup", vreg_name);
> + if (of_get_property(np, prop_name, NULL))
> + vreg->lpm_sup = true;
> +
> + snprintf(prop_name, MAX_PROP_SIZE, "qcom,%s-voltage-level",
> vreg_name);
> + prop = of_get_property(np, prop_name, );
> + if (!prop || (len != (2 * sizeof(__be32 {
> + dev_warn(dev, "%s %s property\n",
> + prop ? "invalid format" : "no", prop_name);
> + } else {
> + vreg->low_vol_level = be32_to_cpup([0]);
> + vreg->high_vol_level = be32_to_cpup([1]);
> + }
You can use of_property_read_u32_array here.
> +
> + snprintf(prop_name, MAX_PROP_SIZE, "qcom,%s-current-level",
> vreg_name);
> + prop = of_get_property(np, prop_name, );
> + if (!prop || (len != (2 * sizeof(__be32 {
> + dev_warn(dev, "%s %s property\n",
> +prop ? "invalid format" : "no", prop_name);
> + } else {
> + vreg->lpm_uA = be32_to_cpup([0]);
> + vreg->hpm_uA = be32_to_cpup([1]);
> + }
Likewise.
[...]
> + /*
> +* CORE_SW_RST above may trigger power irq if previous status of
> PWRCTL
> +* was either BUS_ON or IO_HIGH_V. So before we enable the power irq
> +* interrupt in GIC (by registering the interrupt handler), we need to
> +* ensure that any pending power irq interrupt status is acknowledged
> +* otherwise power irq interrupt handler would be fired prematurely.
> +*/
> + irq_status = readl_relaxed(msm_host->core_mem + CORE_PWRCTL_STATUS);
> + writel_relaxed(irq_status, (msm_host->core_mem + CORE_PWRCTL_CLEAR));
> + irq_ctl = readl_relaxed(msm_host->core_mem + CORE_PWRCTL_CTL);
> + if (irq_status & (CORE_PWRCTL_BUS_ON | CORE_PWRCTL_BUS_OFF))
> + irq_ctl |= CORE_PWRCTL_BUS_SUCCESS;
> + if (irq_status & (CORE_PWRCTL_IO_HIGH | CORE_PWRCTL_IO_LOW))
> + irq_ctl |= CORE_PWRCTL_IO_SUCCESS;
> + writel_relaxed(irq_ctl, (msm_host->core_mem + CORE_PWRCTL_CTL));
> + /*
> +* Ensure that above writes are propogated before interrupt enablement
> +* in GIC.
> +*/
> + mb();
Does this guarantee that the device has finished responding to the write
and deasserted the interrupt line (i.e. does the device only acknowledge
the write once that is true)?
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] mm, x86: Skip NUMA_NO_NODE while parsing SLIT
(2013/12/05 6:09), Toshi Kani wrote:
> When ACPI SLIT table has an I/O locality (i.e. a locality unique
> to an I/O device), numa_set_distance() emits the warning message
> below.
>
> NUMA: Warning: node ids are out of bound, from=-1 to=-1 distance=10
>
> acpi_numa_slit_init() calls numa_set_distance() with pxm_to_node(),
> which assumes that all localities have been parsed with SRAT previously.
> SRAT does not list I/O localities, where as SLIT lists all localities
> including I/Os. Hence, pxm_to_node() returns NUMA_NO_NODE (-1) for
> an I/O locality. I/O localities are not supported and are ignored
> today, but emitting such warning message leads unnecessary confusion.
In this case, the warning message should not be shown. But if SLIT table
is really broken, the message should be shown. Your patch seems to not care
for second case.
Thanks,
Yasuaki Ishimatsu
>
> Change acpi_numa_slit_init() to avoid calling numa_set_distance()
> with NUMA_NO_NODE.
>
> Signed-off-by: Toshi Kani
> ---
> arch/x86/mm/srat.c | 10 --
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/arch/x86/mm/srat.c b/arch/x86/mm/srat.c
> index 266ca91..29a2ced 100644
> --- a/arch/x86/mm/srat.c
> +++ b/arch/x86/mm/srat.c
> @@ -47,10 +47,16 @@ void __init acpi_numa_slit_init(struct acpi_table_slit
> *slit)
> {
> int i, j;
>
> - for (i = 0; i < slit->locality_count; i++)
> - for (j = 0; j < slit->locality_count; j++)
> + for (i = 0; i < slit->locality_count; i++) {
> + if (pxm_to_node(i) == NUMA_NO_NODE)
> + continue;
> + for (j = 0; j < slit->locality_count; j++) {
> + if (pxm_to_node(j) == NUMA_NO_NODE)
> + continue;
> numa_set_distance(pxm_to_node(i), pxm_to_node(j),
> slit->entry[slit->locality_count * i + j]);
> + }
> + }
> }
>
> /* Callback for Proximity Domain -> x2APIC mapping */
>
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org. For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.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/
Re: gfs2 deadlock (was Re: Found it)
Hi,
On Thu, 2013-12-05 at 08:12 +, Al Viro wrote:
> On Tue, Dec 03, 2013 at 04:28:30AM +, Al Viro wrote:
>
> > These should be safe, but damnit, we really need the lifecycle documented
> > for
> > all objects - the above is only a part of it (note that for e.g. superblocks
> > we have additional rules re "->s_active can't be incremented for any reason
> > once it drops to zero, it can't be incremented until superblock had been
> > marked 'born' and it crosses over to zero only with ->s_umount held";
> > there's
> > 6 stages in life cycle of struct super_block and we had interesting bugs due
> > to messing the transitions up). The trouble is, attempt to write those down
> > tends to stray into massive grep session, with usual results - some other
> > crap gets found (e.g. in some odd driver) and needs to be dealt with ;-/
> > Sigh...
>
> ... and sure enough, this time is no different - gfs2 sysfs-related code
> cheerfully violates lifetime rules for superblocks, which would've
> caused a major mess later, if it had not immediately caused a deadlock
> on the same superblock ;-/
>
> Watch: gfs2 creates a bunch of files in sysfs (/sys/fs/gfs2//*).
> Said bunch gets removed from ->put_super(). Which is called under
> ->s_umount. Guess what happens if somebody tries to write "1" to
> /sys/fs/gfs2/.../freeze just as we enter that ->put_super() (or at any
> point starting from the moment when deactivate_locked_super() has dropped
> the last active reference)? This:
> static ssize_t freeze_store(struct gfs2_sbd *sdp, const char *buf, size_t len)
> {
> int error;
> int n = simple_strtol(buf, NULL, 0);
>
> if (!capable(CAP_SYS_ADMIN))
> return -EPERM;
>
> switch (n) {
> [snip]
> case 1:
> error = freeze_super(sdp->sd_vfs);
>
> And freeze_super(sb) assumes that caller has an active reference to
> sb:
> int freeze_super(struct super_block *sb)
> {
> int ret;
>
> atomic_inc(>s_active);
>
> ... which is not legitimate when ->s_active has already reached zero.
> And right after that we hit this:
> down_write(>s_umount);
>
> Voila - write(2) is waiting for ->s_umount, while umount(2) is holding
> ->s_umount and waits for write(2) to get past freeze_store().
>
> Hell knows what to do here - atomic_inc_not_zero() in freeze_super()
> (and failing if it fails) would've worked, but it doesn't help with
> the deadlock - just write "0" instead and we hit thaw_super(), which
> starts with grabbing ->s_umount. atomic_inc_not_zero()/deactivate_super()
> around that call of thaw_super() would probably work, but I'll need to
> look at that after I get some sleep...
>
> Why bother with sysfs, anyway? What's wrong with putting those same files
> on gfs2meta, seeing that _this_ would have no problems with object lifetimes?
> Too late by now, of course, but...
Well now. Thats is a bit of a can of worms :(
Short answer is that the sysfs stuff was largely inherited from GFS
unchanged. The metafs was added in GFS2 as a way to access files which
are otherwise hidden from the user (e.g. the journals). In retrospect,
both were probably a mistake, for different reasons.
Quite a large number of the interfaces in sysfs were added to do what
should really have been the job of mount options. Over time we've now
got to the point that anything that can be done with sysfs that makes
sense as a mount option, is now a mount option and thats the recommended
way to do things.
Freeze can be done via dmsetup suspend, and thats what we've recommended
that people use for a long time now. The only thing in userspace that
used the sysfs interface was gfs2_tool (an obsolete and no longer
shipping userspace tool). So the chances are that nothing uses that
interface any more, but it has been left for backward compatibility
purposes. Maybe we could remove it now?
In any case freeze in GFS2 is due for an overhaul and Ben Marzinski has
patches which he is currently working on as we speak, that are a big
step forward in this area, even though they won't (I think) solve the
issue that you've identified here.
What we do need to preserve are the uevents which are generated though,
since those are used by the older cluster suite programs, and are also
useful for debugging mount/umount/recovery issues, even with the latest
pcs based cluster suite.
Returning briefly to the metafs, the locking there has also been a pain
to deal with. Over time I hope to transition to using "proper"
interfaces rather than trying to directly touch the internal files.
We've already done that with quota - that means that extending the fs
and adding journals are the only two operations left which still use the
metafs as an interface. Eventually I'd like those to have fs independent
(if possible!) interfaces too and then userspace will no longer require
direct access to the metafs. Extending the fs is fairly easy to fix I
think, adding journals will be more tricky to
Re: [PATCH -tip v4 0/6] kprobes: introduce NOKPROBE_SYMBOL() and fixes crash bugs
* Masami Hiramatsu wrote: > > So we need both a maintainable and a sane/safe solution, and I'd > > like to apply the whole thing at once and be at ease that the > > solution is round. We should have done this years ago. > > For the safeness of kprobes, I have an idea; introduce a whitelist > for dynamic events. AFAICS, the biggest unstable issue of kprobes > comes from putting *many* probes on the functions called from > tracers. If the number of 'noprobe' annotations is expected to explode then maybe another approach should be considered. For example in perf we detect recursion. Could kprobes do that and detect hitting a probe while running kprobes code, and ignore it [do an early return]? That way most of the annotations could be removed and kprobes would become inherently safe. Is there any complication I'm missing? 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: [Consult] About tool chains of metag
On 12/05/2013 05:41 PM, James Hogan wrote: > On 05/12/13 08:46, Chen Gang wrote: >> On 12/05/2013 09:57 AM, Chen Gang wrote: >>> I will/should try my best to let it pass allmodconfig, and I guess >>> https://lkml.kernel.org/r/201211161520.03974.a...@arndb.de is valuable >>> to me, and I will/should reference it. >>> >> >> Oh, excuse me, I can not access "https://lkml.kernel.org/r/...; in >> normal way in China. :-( >> >> Could you please provide another links which include the same contents? > > http://marc.info/?l=linux-arch=135307927916985 > http://article.gmane.org/gmane.linux.kernel.cross-arch/15908 > That is really valuable to me!! You and arnd have done much for HAVE_XXX, and I should continue to try based on your work. For me, it is really a suitable solution for all HAVE_XXX (although still need think of more details). :-) Welcome another related members to provide your suggestions or completions. Thanks. -- Chen Gang Open, share, and attitude like air, water and life which God blessed -- 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 tip/core/locking 4/4] Documentation/memory-barriers.txt: Document ACCESS_ONCE()
* Mathieu Desnoyers wrote:
> - Original Message -
> > From: "Ingo Molnar"
> > To: "Paul E. McKenney"
> > Cc: linux-kernel@vger.kernel.org, la...@cn.fujitsu.com,
> > dipan...@in.ibm.com, a...@linux-foundation.org, "mathieu
> > desnoyers" , j...@joshtriplett.org,
> > n...@us.ibm.com, t...@linutronix.de,
> > pet...@infradead.org, rost...@goodmis.org, dhowe...@redhat.com,
> > eduma...@google.com, dar...@dvhart.com,
> > fweis...@gmail.com, s...@mit.edu, "Oleg Nesterov" ,
> > "Jonathan Corbet" , "Rusty
> > Russell"
> > Sent: Thursday, December 5, 2013 10:33:34 AM
> > Subject: Re: [PATCH tip/core/locking 4/4]
> > Documentation/memory-barriers.txt: Document ACCESS_ONCE()
> >
> >
> > * Paul E. McKenney wrote:
> >
> > > + (*) The compiler is within its rights to reorder memory accesses unless
> > > + you tell it not to. For example, consider the following interaction
> > > + between process-level code and an interrupt handler:
> > > +
> > > + void process_level(void)
> > > + {
> > > + msg = get_message();
> > > + flag = true;
> > > + }
> > > +
> > > + void interrupt_handler(void)
> > > + {
> > > + if (flag)
> > > + process_message(msg);
> > > + }
> > > +
> > > + There is nothing to prevent the the compiler from transforming
> > > + process_level() to the following, in fact, this might well be a
> > > + win for single-threaded code:
> > > +
> > > + void process_level(void)
> > > + {
> > > + flag = true;
> > > + msg = get_message();
> > > + }
> > > +
> > > + If the interrupt occurs between these two statement, then
> > > + interrupt_handler() might be passed a garbled msg. Use
> > > ACCESS_ONCE()
> > > + to prevent this as follows:
> > > +
> > > + void process_level(void)
> > > + {
> > > + ACCESS_ONCE(msg) = get_message();
> > > + ACCESS_ONCE(flag) = true;
> > > + }
> > > +
> > > + void interrupt_handler(void)
> > > + {
> > > + if (ACCESS_ONCE(flag))
> > > + process_message(ACCESS_ONCE(msg));
> > > + }
> >
> > Technically, if the interrupt handler is the innermost context, the
> > ACCESS_ONCE() is not needed in the interrupt_handler() code.
> >
> > Since for the vast majority of Linux code IRQ handlers are the most
> > atomic contexts (very few drivers deal with NMIs) I suspect we should
> > either remove that ACCESS_ONCE() from the example or add a comment
> > explaining that in many cases those are superfluous?
>
> It might be worthwhile to state clearly those two different use-cases:
>
> * no nesting (e.g. process vs process), where both sides of the access
> need ACCESS_ONCE().
>
> * nested access: the outer context needs ACCESS_ONCE(), but not the
> inner context.
>
> We don't actually care about IRQs being the "most atomic" context,
> and we should not care about NMIs in this example. Only the relative
> nesting of the execution contexts accessing the data matter.
I meant 'most atomic' in the sense of no NMI context having access to
those same shared variables, obviously.
We do actually have 'triple' nesting in Linux, NMI context code with
non-trivial complexity that accesses variables in different code paths
from IRQ codepaths and from process level code paths, so technically
the original example is valid - I just think misleading to most
readers.
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 1/2] usb: chipidea: fix mistake in device tree binding of nspire-usb to use vendor name 'lsi' instead of SoC name 'zevio'
Hi, On 05/12/2013, at 7:49 PM, Peter Chen wrote: > On Thu, Dec 05, 2013 at 04:44:13PM +1100, Daniel Tang wrote: >> Hi, >> >> On 05/12/2013, at 12:44 AM, Peter Chen wrote: >> >>> >>> lsi is vendor name, what are zevio and nspire? >>> Usually, the compatible string should be "vendor_name,soc_name-module_name" >>> >> >> Because this port uses documentation from reverse engineering, it's >> difficult to work out what is SoC specific and what is device specific. The >> SoC is Zevio but the driver is written for the TI-Nspire. >> > > Please wrap the line to 80 characters. > > The driver is written for the TI-Nspire, and you port this driver for > SoC Zevio platform? The TI-Nspire runs on the Zevio SoC. > Since you use chipidea ip, we don't care the usb > module name at your platform, we only care the soc name which you are > running, it can detect the SoC platform at runtime. > Yep, that's why the latest patch I sent in renames the device tree binding to "lsi,zevio-usb" since zevio is the name of the SoC that the TI-Nspire uses. > At your dts patch, it still uses nspire-usb. > http://marc.info/?l=linux-usb=138614886720024=2 I'll send a new one in right now. > > Peter Cheers, Daniel Tang-- 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] MAINTAINERS: Add entry for Samsung SoC clock drivers
Hi, On Saturday 09 of November 2013 03:17:34 Tomasz Figa wrote: > From: Tomasz Figa > > This patch adds an entry for Samsung SoC clock drivers located under > drivers/clk/samsung/ directory, with me taking the maintainer role. > > Signed-off-by: Tomasz Figa > Acked-by: Kyungmin Park > Acked-by: Mike Turquette > Acked-by: Sachin Kamat > Acked-by: Sylwester Nawrocki > Acked-by: Kukjin Kim > --- > MAINTAINERS | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 61b8757..df7e1bf 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -7319,6 +7319,12 @@ L: linux-me...@vger.kernel.org > S: Supported > F: drivers/media/i2c/s5c73m3/* > > +SAMSUNG SOC CLOCK DRIVERS > +M: Tomasz Figa > +S: Supported > +L: linux-samsung-...@vger.kernel.org (moderated for non-subscribers) > +F: drivers/clk/samsung/ > + > SERIAL DRIVERS > M: Greg Kroah-Hartman > L: linux-ser...@vger.kernel.org > I don't see this patch applied anywhere. Mike, should it go through your tree? Best regards, Tomasz -- 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.10] aio: restore locking of ioctx list on removal
Commit 36f5588905c10a8c4568a210d601fe8c3c27e0f0
"aio: refcounting cleanup" resulted in ioctx_lock not being held
during ctx removal, leaving the list susceptible to corruptions.
In mainline kernel the issue went away as a side effect of
db446a08c23d5475e6b08c87acca79ebb20f283c "aio: convert the ioctx list to
table lookup v3".
Fix the problem by restoring appropriate locking.
Signed-off-by: Mateusz Guzik
Reported-by: Eryu Guan
Cc: Jeff Moyer
Cc: Kent Overstreet
Cc: linux-...@kvack.org
Cc: linux-kernel@vger.kernel.org
---
fs/aio.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/fs/aio.c b/fs/aio.c
index 2bbcacf..ebd06fd 100644
--- a/fs/aio.c
+++ b/fs/aio.c
@@ -423,10 +423,12 @@ static void kill_ioctx_rcu(struct rcu_head *head)
* when the processes owning a context have all exited to encourage
* the rapid destruction of the kioctx.
*/
-static void kill_ioctx(struct kioctx *ctx)
+static void kill_ioctx(struct mm_struct *mm, struct kioctx *ctx)
{
if (!atomic_xchg(>dead, 1)) {
+ spin_lock(>ioctx_lock);
hlist_del_rcu(>list);
+ spin_unlock(>ioctx_lock);
/*
* It'd be more correct to do this in free_ioctx(), after all
@@ -494,7 +496,7 @@ void exit_aio(struct mm_struct *mm)
*/
ctx->mmap_size = 0;
- kill_ioctx(ctx);
+ kill_ioctx(mm, ctx);
}
}
@@ -852,7 +854,7 @@ SYSCALL_DEFINE2(io_setup, unsigned, nr_events,
aio_context_t __user *, ctxp)
if (!IS_ERR(ioctx)) {
ret = put_user(ioctx->user_id, ctxp);
if (ret)
- kill_ioctx(ioctx);
+ kill_ioctx(current->mm, ioctx);
put_ioctx(ioctx);
}
@@ -870,7 +872,7 @@ SYSCALL_DEFINE1(io_destroy, aio_context_t, ctx)
{
struct kioctx *ioctx = lookup_ioctx(ctx);
if (likely(NULL != ioctx)) {
- kill_ioctx(ioctx);
+ kill_ioctx(current->mm, ioctx);
put_ioctx(ioctx);
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/
Re: [GIT PULL 00/38] perf/core improvements and fixes
* Arnaldo Carvalho de Melo wrote: > From: Arnaldo Carvalho de Melo > > Hi Ingo, > > Please consider pulling, > > - Arnaldo > > The following changes since commit 89e3bbd58a6186b832fe2b9419ac2f9ab90e9089: > > Merge tag 'perf-core-for-mingo' of > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core > (2013-12-04 10:17:17 +0100) > > are available in the git repository at: > > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux > tags/perf-core-for-mingo Hm, I saw such a build failure: CC FPIC plugin_kmem.o BUILDPLUGIN plugin_jbd2.so plugin_jbd2.o: file not recognized: File truncated collect2: error: ld returned 1 exit status make[2]: *** [plugin_jbd2.so] Error 1 make[1]: *** [install-traceevent-plugins] Error 2 make[1]: *** Waiting for unfinished jobs CC FPIC plugin_kvm.o CC FPIC plugin_mac80211.o which suggests some sort of build race ... I was doing several 'make clean; make install' runs - and the second run failed. Unfortunately the failure was not reproducible after that point - and I tried dozens of times. The test system has 12 CPUs. The following loop attempts to build until a failure occurs: cd tools/perf/ while make install; do make clean; done Any ideas? Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/3] usb: ohci-at91: replace request_mem_region + ioremap by devm_request_and_ioremap
Replace the request_mem_region + ioremap calls by the
devm_request_and_ioremap call which does the same things but with device
managed resources.
Signed-off-by: Boris BREZILLON
Acked-by: Nicolas Ferre
Signed-off-by: Alan Stern
---
drivers/usb/host/ohci-at91.c | 24 +---
1 file changed, 5 insertions(+), 19 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 7aec6ca..8528895 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -157,24 +157,18 @@ static int usb_hcd_at91_probe(const struct hc_driver
*driver,
hcd->rsrc_start = mem_r->start;
hcd->rsrc_len = resource_size(mem_r);
- if (!request_mem_region(hcd->rsrc_start, hcd->rsrc_len, hcd_name)) {
- pr_debug("request_mem_region failed\n");
- retval = -EBUSY;
- goto err1;
- }
-
- hcd->regs = ioremap(hcd->rsrc_start, hcd->rsrc_len);
+ hcd->regs = devm_request_and_ioremap(dev, mem_r);
if (!hcd->regs) {
- pr_debug("ioremap failed\n");
+ dev_dbg(dev, "devm_request_and_ioremap failed\n");
retval = -EIO;
- goto err2;
+ goto err;
}
iclk = clk_get(>dev, "ohci_clk");
if (IS_ERR(iclk)) {
dev_err(>dev, "failed to get ohci_clk\n");
retval = PTR_ERR(iclk);
- goto err3;
+ goto err;
}
fclk = clk_get(>dev, "uhpck");
if (IS_ERR(fclk)) {
@@ -218,13 +212,7 @@ static int usb_hcd_at91_probe(const struct hc_driver
*driver,
err4:
clk_put(iclk);
- err3:
- iounmap(hcd->regs);
-
- err2:
- release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
-
- err1:
+ err:
usb_put_hcd(hcd);
return retval;
}
@@ -247,8 +235,6 @@ static void usb_hcd_at91_remove(struct usb_hcd *hcd,
{
usb_remove_hcd(hcd);
at91_stop_hc(pdev);
- iounmap(hcd->regs);
- release_mem_region(hcd->rsrc_start, hcd->rsrc_len);
usb_put_hcd(hcd);
if (IS_ENABLED(CONFIG_COMMON_CLK))
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] cpufreq_ at32ap-cpufreq.c: Fix section mismatch
The function at32_cpufreq_driver_init was marked as __init but will be
called from inside the cpufreq framework. This lead to the following a
section mismatch during compilation:
WARNING: drivers/built-in.o(.data+0x2448): Section mismatch in reference
from the variable at32_driver to the function
.init.text:at32_cpufreq_driver_init()
The variable at32_driver references
the function __init at32_cpufreq_driver_init()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the
variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console
Signed-off-by: Matthias Brugger
---
drivers/cpufreq/at32ap-cpufreq.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/cpufreq/at32ap-cpufreq.c b/drivers/cpufreq/at32ap-cpufreq.c
index e0c38d9..372c426 100644
--- a/drivers/cpufreq/at32ap-cpufreq.c
+++ b/drivers/cpufreq/at32ap-cpufreq.c
@@ -83,7 +83,7 @@ static int at32_set_target(struct cpufreq_policy *policy,
return 0;
}
-static int __init at32_cpufreq_driver_init(struct cpufreq_policy *policy)
+static int at32_cpufreq_driver_init(struct cpufreq_policy *policy)
{
if (policy->cpu != 0)
return -EINVAL;
--
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/
[PATCH v3 3/3] usb: ohci-at91: use device managed clk retrieval
Replace clk_get calls by devm_clk_get calls.
Signed-off-by: Boris BREZILLON
Acked-by: Nicolas Ferre
Signed-off-by: Alan Stern
---
drivers/usb/host/ohci-at91.c | 30 +++---
1 file changed, 7 insertions(+), 23 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 2a86e32..7b2ccd3 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -164,30 +164,30 @@ static int usb_hcd_at91_probe(const struct hc_driver
*driver,
goto err;
}
- iclk = clk_get(dev, "ohci_clk");
+ iclk = devm_clk_get(dev, "ohci_clk");
if (IS_ERR(iclk)) {
dev_err(dev, "failed to get ohci_clk\n");
retval = PTR_ERR(iclk);
goto err;
}
- fclk = clk_get(dev, "uhpck");
+ fclk = devm_clk_get(dev, "uhpck");
if (IS_ERR(fclk)) {
dev_err(dev, "failed to get uhpck\n");
retval = PTR_ERR(fclk);
- goto err4;
+ goto err;
}
- hclk = clk_get(dev, "hclk");
+ hclk = devm_clk_get(dev, "hclk");
if (IS_ERR(hclk)) {
dev_err(dev, "failed to get hclk\n");
retval = PTR_ERR(hclk);
- goto err5;
+ goto err;
}
if (IS_ENABLED(CONFIG_COMMON_CLK)) {
- uclk = clk_get(dev, "usb_clk");
+ uclk = devm_clk_get(dev, "usb_clk");
if (IS_ERR(uclk)) {
dev_err(dev, "failed to get uclk\n");
retval = PTR_ERR(uclk);
- goto err6;
+ goto err;
}
}
@@ -203,15 +203,6 @@ static int usb_hcd_at91_probe(const struct hc_driver
*driver,
/* Error handling */
at91_stop_hc(pdev);
- if (IS_ENABLED(CONFIG_COMMON_CLK))
- clk_put(uclk);
- err6:
- clk_put(hclk);
- err5:
- clk_put(fclk);
- err4:
- clk_put(iclk);
-
err:
usb_put_hcd(hcd);
return retval;
@@ -236,13 +227,6 @@ static void usb_hcd_at91_remove(struct usb_hcd *hcd,
usb_remove_hcd(hcd);
at91_stop_hc(pdev);
usb_put_hcd(hcd);
-
- if (IS_ENABLED(CONFIG_COMMON_CLK))
- clk_put(uclk);
- clk_put(hclk);
- clk_put(fclk);
- clk_put(iclk);
- fclk = iclk = hclk = NULL;
}
/*-*/
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 2/3] usb: ohci-at91: use dev variable instead of >dev
Make use of the dev variable instead of referencing the dev field of the
pdev struct.
Signed-off-by: Boris BREZILLON
Acked-by: Nicolas Ferre
Signed-off-by: Alan Stern
---
drivers/usb/host/ohci-at91.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 8528895..2a86e32 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -151,7 +151,7 @@ static int usb_hcd_at91_probe(const struct hc_driver
*driver,
return -ENODEV;
}
- hcd = usb_create_hcd(driver, >dev, "at91");
+ hcd = usb_create_hcd(driver, dev, "at91");
if (!hcd)
return -ENOMEM;
hcd->rsrc_start = mem_r->start;
@@ -164,28 +164,28 @@ static int usb_hcd_at91_probe(const struct hc_driver
*driver,
goto err;
}
- iclk = clk_get(>dev, "ohci_clk");
+ iclk = clk_get(dev, "ohci_clk");
if (IS_ERR(iclk)) {
- dev_err(>dev, "failed to get ohci_clk\n");
+ dev_err(dev, "failed to get ohci_clk\n");
retval = PTR_ERR(iclk);
goto err;
}
- fclk = clk_get(>dev, "uhpck");
+ fclk = clk_get(dev, "uhpck");
if (IS_ERR(fclk)) {
- dev_err(>dev, "failed to get uhpck\n");
+ dev_err(dev, "failed to get uhpck\n");
retval = PTR_ERR(fclk);
goto err4;
}
- hclk = clk_get(>dev, "hclk");
+ hclk = clk_get(dev, "hclk");
if (IS_ERR(hclk)) {
- dev_err(>dev, "failed to get hclk\n");
+ dev_err(dev, "failed to get hclk\n");
retval = PTR_ERR(hclk);
goto err5;
}
if (IS_ENABLED(CONFIG_COMMON_CLK)) {
- uclk = clk_get(>dev, "usb_clk");
+ uclk = clk_get(dev, "usb_clk");
if (IS_ERR(uclk)) {
- dev_err(>dev, "failed to get uclk\n");
+ dev_err(dev, "failed to get uclk\n");
retval = PTR_ERR(uclk);
goto err6;
}
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/3] usb: ohci-at91: various improvements
Hello, This patch series moves the different driver resources (clks and iomem) retrieval to the device managed versions (devm_ functions). Best Regards, Boris Changes since v2: - split urgent fix and resource retrieval improvements Boris BREZILLON (3): usb: ohci-at91: replace request_mem_region + ioremap by devm_request_and_ioremap usb: ohci-at91: use dev variable instead of >dev usb: ohci-at91: use device managed clk retrieval drivers/usb/host/ohci-at91.c | 64 +++--- 1 file changed, 17 insertions(+), 47 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/locking 4/4] Documentation/memory-barriers.txt: Document ACCESS_ONCE()
- Original Message -
> From: "Ingo Molnar"
> To: "Paul E. McKenney"
> Cc: linux-kernel@vger.kernel.org, la...@cn.fujitsu.com, dipan...@in.ibm.com,
> a...@linux-foundation.org, "mathieu
> desnoyers" , j...@joshtriplett.org,
> n...@us.ibm.com, t...@linutronix.de,
> pet...@infradead.org, rost...@goodmis.org, dhowe...@redhat.com,
> eduma...@google.com, dar...@dvhart.com,
> fweis...@gmail.com, s...@mit.edu, "Oleg Nesterov" ,
> "Jonathan Corbet" , "Rusty
> Russell"
> Sent: Thursday, December 5, 2013 10:33:34 AM
> Subject: Re: [PATCH tip/core/locking 4/4] Documentation/memory-barriers.txt:
> Document ACCESS_ONCE()
>
>
> * Paul E. McKenney wrote:
>
> > + (*) The compiler is within its rights to reorder memory accesses unless
> > + you tell it not to. For example, consider the following interaction
> > + between process-level code and an interrupt handler:
> > +
> > + void process_level(void)
> > + {
> > + msg = get_message();
> > + flag = true;
> > + }
> > +
> > + void interrupt_handler(void)
> > + {
> > + if (flag)
> > + process_message(msg);
> > + }
> > +
> > + There is nothing to prevent the the compiler from transforming
> > + process_level() to the following, in fact, this might well be a
> > + win for single-threaded code:
> > +
> > + void process_level(void)
> > + {
> > + flag = true;
> > + msg = get_message();
> > + }
> > +
> > + If the interrupt occurs between these two statement, then
> > + interrupt_handler() might be passed a garbled msg. Use ACCESS_ONCE()
> > + to prevent this as follows:
> > +
> > + void process_level(void)
> > + {
> > + ACCESS_ONCE(msg) = get_message();
> > + ACCESS_ONCE(flag) = true;
> > + }
> > +
> > + void interrupt_handler(void)
> > + {
> > + if (ACCESS_ONCE(flag))
> > + process_message(ACCESS_ONCE(msg));
> > + }
>
> Technically, if the interrupt handler is the innermost context, the
> ACCESS_ONCE() is not needed in the interrupt_handler() code.
>
> Since for the vast majority of Linux code IRQ handlers are the most
> atomic contexts (very few drivers deal with NMIs) I suspect we should
> either remove that ACCESS_ONCE() from the example or add a comment
> explaining that in many cases those are superfluous?
It might be worthwhile to state clearly those two different use-cases:
* no nesting (e.g. process vs process), where both sides of the access
need ACCESS_ONCE().
* nested access: the outer context needs ACCESS_ONCE(), but not the
inner context.
We don't actually care about IRQs being the "most atomic" context, and
we should not care about NMIs in this example. Only the relative nesting
of the execution contexts accessing the data matter.
Thanks,
Mathieu
>
> > + (*) For aligned memory locations whose size allows them to be accessed
> > + with a single memory-reference instruction, prevents "load tearing"
> > + and "store tearing," in which a single large access is replaced by
> > + multiple smaller accesses. For example, given an architecture having
> > + 16-bit store instructions with 7-bit immediate fields, the compiler
> > + might be tempted to use two 16-bit store-immediate instructions to
> > + implement the following 32-bit store:
> > +
> > + p = 0x00010002;
> > +
> > + Please note that GCC really does use this sort of optimization,
> > + which is not surprising given that it would likely take more
> > + than two instructions to build the constant and then store it.
> > + This optimization can therefore be a win in single-threaded code.
> > + In fact, a recent bug (since fixed) caused GCC to incorrectly use
> > + this optimization in a volatile store. In the absence of such bugs,
> > + use of ACCESS_ONCE() prevents store tearing:
> > +
> > + ACCESS_ONCE(p) = 0x00010002;
>
> I suspect the last sentence should read:
>
> > + In the absence of such bugs,
> > + use of ACCESS_ONCE() prevents store tearing in this example:
> > +
> > + ACCESS_ONCE(p) = 0x00010002;
>
> Otherwise it could be read as a more generic statement (leaving out
> 'load tearing')?
>
> Thanks,
>
> Ingo
>
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.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 v3] usb: ohci-at91: fix irq and iomem resource retrieval
Hi Boris,
On Thursday 05 of December 2013 10:50:13 Boris BREZILLON wrote:
> When using dt resources retrieval (interrupts and reg properties) there is
> no predefined order for these resources in the platform dev resources
> table.
>
> Retrieve resources using the platform_get_resource function instead of
> direct resource table entries to avoid resource type mismatch.
>
> Signed-off-by: Boris BREZILLON
> Acked-by: Nicolas Ferre
> Signed-off-by: Alan Stern
> ---
> Changes since v2:
> - split the patch series to isolate the urgent fix provided by this patch
>
> Changes since v1:
> - none
>
> drivers/usb/host/ohci-at91.c | 19 +++
> 1 file changed, 11 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
> index 418444e..7aec6ca 100644
> --- a/drivers/usb/host/ohci-at91.c
> +++ b/drivers/usb/host/ohci-at91.c
> @@ -136,23 +136,26 @@ static int usb_hcd_at91_probe(const struct hc_driver
> *driver,
> struct ohci_hcd *ohci;
> int retval;
> struct usb_hcd *hcd = NULL;
> + struct device *dev = >dev;
> + struct resource *mem_r, *irq_r;
>
> - if (pdev->num_resources != 2) {
> - pr_debug("hcd probe: invalid num_resources");
> + mem_r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!mem_r) {
> + dev_dbg(dev, "hcd probe: missing memory resource\n");
> return -ENODEV;
> }
>
> - if ((pdev->resource[0].flags != IORESOURCE_MEM)
> - || (pdev->resource[1].flags != IORESOURCE_IRQ)) {
> - pr_debug("hcd probe: invalid resource type\n");
> + irq_r = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
You could have simply used platform_get_irq() here, but I guess it's just
a matter of preference, so:
Reviewed-by: Tomasz Figa
Best regards,
Tomasz
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 1/2] mmc: sdhci-msm: Initial SDHCI MSM driver documentation
Hi,
Apologies for the late reply.
On Wed, Nov 06, 2013 at 03:56:44PM +, Georgi Djakov wrote:
> This patch adds documentation for Qualcomm SDHCI MSM driver.
> It contains the differences between the core properties in mmc.txt
> and the properties used by the sdhci-msm driver.
Nit, but this is documentation of the binding, not the driver.
>
> Signed-off-by: Georgi Djakov
> ---
> .../devicetree/bindings/mmc/sdhci-msm.txt | 92
>
> 1 file changed, 92 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/mmc/sdhci-msm.txt
>
> diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
> b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
> new file mode 100644
> index 000..8f1a52d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt
> @@ -0,0 +1,92 @@
> +* Qualcomm SDHCI controller (sdhci-msm)
> +
> +This file documents differences between the core properties in mmc.txt
> +and the properties used by the sdhci-msm driver.
> +
> +Required properties:
> +- compatible: should contain "qcom,sdhci-msm"
> +- reg: should contain SDHC, SD Core register map
As this seems to depend on reg-names, it would be nice to write this in
terms of reg-names (as with clocks and clock-names).
> +- reg-names: indicates various resources passed to driver (via reg proptery)
> by name
> + "reg-names" examples are "hc_mem" and "core_mem"
Either there are a fixed set of names you expect (and therefore these
aren't examples but rather a definition), or this property is useless.
Please either define the set of names or remove this property.
> +- interrupts: should contain SDHC interrupts
> +- interrupt-names: indicates interrupts passed to driver (via interrupts
> property) by name
> + "interrupt-names" examples are "hc_irq" and "pwr_irq"
Likewise for both points.
> +- vdd-supply: phandle to the regulator for the vdd (flash core voltage)
> supply.
> +- vddio-supply: phandle to the regulator for the vdd-io (i/o voltage) supply.
> +- pinctrl-names: Should contain only one value - "default".
> +- pinctrl-0: Should specify pin control groups used for this controller.
> +- clocks: A list of phandle + clock-specifier pairs for the clocks listed in
> clock-names
> +- clock-names: Should contain the following:
> + "iface" - Main peripheral bus clock (PCLK/HCLK - AHB Bus clock)
> (required)
> + "core" - SDC MMC clock (MCLK) (required)
> + "bus" - SDCC bus voter clock (optional)
This looks good :)
> +
> +Optional properties:
> +- qcom,bus-speed-mode: specifies the supported bus speed modes by host
> + The supported bus speed modes are:
> + "HS200_1p8v" - indicates that host can support HS200 at 1.8v
> + "HS200_1p2v" - indicates that host can support HS200 at 1.2v
> + "DDR_1p8v" - indicates that host can support DDR mode at 1.8v
> + "DDR_1p2v" - indicates that host can support DDR mode at 1.2v
Is this a list of strings, or does the unit only support one of these?
This could be a set of boolean properties instead, is this likely to
expand in future?
> +
> +- qcom,{vdd,vdd-io}-lpm-sup - specifies whether the supply can be kept in
> low power mode.
Boolean? Please specify types on properties.
Can you elaborate on what this means? When can a supply not be kept in
low power mode?
> +- qcom,{vdd,vdd-io}-voltage-level - specifies voltage levels for the supply.
> + Should be specified in pairs (min, max), units uV.
> +- qcom,{vdd,vdd-io}-current-level - specifies load levels for the supply in
> lpm
> + or high power mode (hpm). Should be specified in pairs (lpm, hpm),
> units uA.
Can you not query these from the regulator framework?
If these are configuration, why are they necessary?
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 tip/core/locking 4/4] Documentation/memory-barriers.txt: Document ACCESS_ONCE()
* Paul E. McKenney wrote: > + (*) The compiler is within its rights to reload a variable, for example, > + in cases where high register pressure prevents the compiler from > + keeping all data of interest in registers. The compiler might > + therefore optimize the variable tmp out of our previous example: > + > + while (tmp = a) > + do_something_with(tmp); > + > + This could result in the following code, which is perfectly safe in > + single-threaded code, but can be fatal in concurrent code: > + > + while (a) > + do_something_with(a); > + > + For example, the optimized version of this code could result in > + passing a zero to do_something_with() in the case where the variable > + a was modified by some other CPU between the "while" statement and > + the call to do_something_with(). Nit: I guess references to variable names such as 'a' should be quoted (same for 'tmp', 'b', etc): For example, the optimized version of this code could result in passing a zero to do_something_with() in the case where the variable 'a' was modified by some other CPU between the "while" statement and the call to do_something_with(). which makes reading it less ambiguous and more fluid IMO. This observation applies to the whole document as 'a' is used in many places. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3] usb: ohci-at91: fix irq and iomem resource retrieval
When using dt resources retrieval (interrupts and reg properties) there is
no predefined order for these resources in the platform dev resources
table.
Retrieve resources using the platform_get_resource function instead of
direct resource table entries to avoid resource type mismatch.
Signed-off-by: Boris BREZILLON
Acked-by: Nicolas Ferre
Signed-off-by: Alan Stern
---
Changes since v2:
- split the patch series to isolate the urgent fix provided by this patch
Changes since v1:
- none
drivers/usb/host/ohci-at91.c | 19 +++
1 file changed, 11 insertions(+), 8 deletions(-)
diff --git a/drivers/usb/host/ohci-at91.c b/drivers/usb/host/ohci-at91.c
index 418444e..7aec6ca 100644
--- a/drivers/usb/host/ohci-at91.c
+++ b/drivers/usb/host/ohci-at91.c
@@ -136,23 +136,26 @@ static int usb_hcd_at91_probe(const struct hc_driver
*driver,
struct ohci_hcd *ohci;
int retval;
struct usb_hcd *hcd = NULL;
+ struct device *dev = >dev;
+ struct resource *mem_r, *irq_r;
- if (pdev->num_resources != 2) {
- pr_debug("hcd probe: invalid num_resources");
+ mem_r = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+ if (!mem_r) {
+ dev_dbg(dev, "hcd probe: missing memory resource\n");
return -ENODEV;
}
- if ((pdev->resource[0].flags != IORESOURCE_MEM)
- || (pdev->resource[1].flags != IORESOURCE_IRQ)) {
- pr_debug("hcd probe: invalid resource type\n");
+ irq_r = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
+ if (!irq_r) {
+ dev_dbg(dev, "hcd probe: missing irq resource\n");
return -ENODEV;
}
hcd = usb_create_hcd(driver, >dev, "at91");
if (!hcd)
return -ENOMEM;
- hcd->rsrc_start = pdev->resource[0].start;
- hcd->rsrc_len = resource_size(>resource[0]);
+ hcd->rsrc_start = mem_r->start;
+ hcd->rsrc_len = resource_size(mem_r);
if (!request_mem_region(hcd->rsrc_start, hcd->rsrc_len, hcd_name)) {
pr_debug("request_mem_region failed\n");
@@ -199,7 +202,7 @@ static int usb_hcd_at91_probe(const struct hc_driver
*driver,
ohci->num_ports = board->ports;
at91_start_hc(pdev);
- retval = usb_add_hcd(hcd, pdev->resource[1].start, IRQF_SHARED);
+ retval = usb_add_hcd(hcd, irq_r->start, IRQF_SHARED);
if (retval == 0)
return retval;
--
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: ARM: gic_arch_extn (Was: [PATCH v3] irqchip: mmp: add dt support for wakeup)
On Thu, Dec 05, 2013 at 03:12:55AM +0100, Thomas Gleixner wrote: > Russell, > > On Thu, 5 Dec 2013, Russell King - ARM Linux wrote: > > On Thu, Dec 05, 2013 at 01:41:53AM +0100, Thomas Gleixner wrote: > > > @all who feel responsible for gic_arch_extn > > > > > > On Wed, 4 Dec 2013, Thomas Gleixner wrote: > > > > I'm going to reply in a separate mail on this, because you have > > > > brought this to my attention, but you are not responsible in the first > > > > place for this brainfart. > > > > > > Who came up with that gic_arch_extn concept in the first place? > > > > If you'd spend more time reviewing IRQ patches then maybe you'd catch > > this at review time. So please stop your rediculous whinging when > > most of the problem is your own lack of time. > > I'm not a native english speaker, so I want to make sure in the first > place that you meant: > > "ridiculous whingeing" > > Assumed that you meant that, let me ridicule you a bit. > > The gic_arch_extn concept got merged with: > > commit d7ed36a4ea84e3a850f9932e2058ceef987d1acd > Author: Santosh Shilimkar > Date: Wed Mar 2 08:03:22 2011 +0100 > > ARM: 6777/1: gic: Add hooks for architecture specific extensions > > > > Cc: Russell King > Signed-off-by: Santosh Shilimkar > Acked-by: Colin Cross > Tested-by: Colin Cross > Signed-off-by: Russell King > > --- > arch/arm/common/gic.c | 47 > arch/arm/include/asm/hardware/gic.h |1 > > The patch in question was never cc'ed to me and you merged it on your > own. > > So now you have the chuzpe to blame me for that, just because this > code moved to drivers/irqchip with > > commit 81243e444c6e9d1625073e4a3d3bc244c8a545f0 > Author: Rob Herring > Date: Tue Nov 20 21:21:40 2012 -0600 > > irqchip: Move ARM GIC to drivers/irqchip > > almost two years later? > > The code move neither exempts you from the responsibility of merging > it nor does it imply a retroactive responsibility for me to review all > patches which went into that code prior to the move. And neither does it give you permission to send such an idiotic and rediculous email. I'm not going to do anything about it because "Thomas Glexiner" has suddenly decided he doesn't like it. As for your definition of "hotpath", you're really screwed on that because you don't seem to understand what is or isn't the hotpath in this code. So there's not much point discussing this with you until you: (a) calm down (b) analyse it properly and work out the frequency under which each class of IRQ (those >= 32 and those < 32) call into these functions. To put it bluntly, you're wrong. -- 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 28/28] perf tools: Add udis86 disassembler feature check
On Thu, Dec 05, 2013 at 10:25:02AM +0100, Ingo Molnar wrote: > > * Jiri Olsa wrote: > > > On Wed, Dec 04, 2013 at 03:50:24PM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Tue, Dec 03, 2013 at 02:09:42PM +0100, Jiri Olsa escreveu: > > > > Adding udis86 disassembler feature check which support > > > > is needed for kvm:kvm_emulate_insn tracepoint. > > > > > > > > +$(call feature_check,udis86) > > > > +ifeq ($(feature-udis86), 1) > > > > + LIBTRACEEVENT_CFLAGS += -DHAVE_UDIS86 > > > > + EXTLIBS += -ludis86 > > > > +else > > > > + msg := $(warning No udis86 support.); > > > > +endif > > > > > > That is really an incomplete message, what package should I install? > > > Perhaps we should add this there then: > > > > > > http://bit.ly/1hyrN52 > > > > nice :-) > > > > > > > > Wow, that was easy, but yeah, could be made easier 8-) ;-P > > > > so something like: > > No udis86 found. Please install udis86-devel. > > > > or: > > No udis86 found, disabling kvm tracepoints instruction disassembly. Please > > install udis86-devel. > > 1) > > So, the first problem I can see is in the output: > > Auto-detecting system features: > ... backtrace: [ on ] > ... dwarf: [ on ] > ...fortify-source: [ on ] > ... glibc: [ on ] > ... gtk2: [ on ] > ... gtk2-infobar: [ on ] > ... libaudit: [ on ] > ...libbfd: [ on ] > ...libelf: [ on ] > ... libelf-getphdrnum: [ on ] > ... libelf-mmap: [ on ] > ... libnuma: [ on ] > ... libperl: [ on ] > ... libpython: [ on ] > ... libpython-version: [ on ] > ... libslang: [ on ] > ... libunwind: [ on ] > ... on-exit: [ on ] > ...stackprotector-all: [ on ] > ... timerfd: [ on ] > > config/Makefile:421: No udis86 support. > > such a 'no XYZ support' message should only occur if a feature test > failed. _If_ we decide that 'udis86' support is required for a full > perf build then there should be a new line saying something like: > > ...udis86: [ OFF ] hum, just sent v4 that added udis86 into above list ;-) So.. do we consider 'full perf build' to be build with all possible libraries linked in? then we need to cleanup above list and remove: on-exit timerfd libelf-getphdrnum libelf-mmap stackprotector-all fortify-source backtrace or maybe have verbose list where we display everything (for V=1 ?) and by default display only library checks > > 2) > > The other problem I see is that I think we should start adding the > install-suggestions to the feature-check lines themselves. > > On .deb based systems it should say something like: > > ... on-exit: [ on ] > ...stackprotector-all: [ on ] > ... timerfd: [ on ] > ...udis86: [ OFF ]# apt-get install udis86-dev > > On RPM based systems it should say something like: > > ... on-exit: [ on ] > ...stackprotector-all: [ on ] > ... timerfd: [ on ] > ...udis86: [ OFF ]# yum install udis86-devel > > Or so. I think we can maintain package suggestion strings for these > two main distro variants. > > The package install strings should probably be maintained together > with the list of feature names in some table/list format. Such lookup > tables can be implemented either in Make via: > > > http://www.gnu.org/savannah-checkouts/gnu/make/manual/html_node/Computed-Names.html > > Or via a shell command in the makefile, using Bash associative arrays > or such. sounds good jirka -- 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: Supporting 4 way connections in LKSCTP
> >> the configured addresses could be: > >> System A) 10.0.0.1 on Lan X, 10.10.0.1 on Lan Y > >> System B) 10.0.0.2 on Lan X, 10.10.0.2 on Lan Y > >> System C) 10.0.0.3 on Lan X, 10.10.0.2 on Lan Z > >> > >> Same problem will occur. ... > With that, Sys A talking to Sys C will get an abort > from Sys B when trying to talk to 10.10.0.2. With /8, it'll be > even worse since SysB and SysC will have duplicate addresses > within the subnet. :) > > The point is that you don't always know that the same private subnet > is in reality 2 different subnets with duplicate addresses. > > I've had to debug an actual production issue similar to this where > customer had a very similar configuration to above, and their > associations kept getting aborted. When I tried accessing the > system that kept sending aborts, I found it was some windows > server and not a Diameter station they were expecting. Does seem that the addresses listed in INIT and INIT_ACK chunks should be ignored until a valid HB response has been received. If an abort is received before a valid HB response then the address should be ignored rather than the connection aborted. Then it wouldn't matter anywhere near as much if addresses are advertised that are not reachable from the remote system. All this should have been thought about when the original RFC was written. 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] ARM: OMAP2+: omap_device: add fail hook for runtime_pm when bad data is detected
On 12/04/2013 07:07 PM, Nishanth Menon wrote: > On 18:14-20131204, Joel Fernandes wrote: >> On 12/04/2013 05:03 PM, Nishanth Menon wrote: >>> On 12/04/2013 02:08 AM, Joel Fernandes wrote: On 12/04/2013 07:09 AM, Nishanth Menon wrote: > Due to the cross dependencies between hwmod for automanaged device > information for OMAP and dts node definitions, we can run into scenarios > where the dts node is defined, however it's hwmod entry is yet to be > added. In these cases: > a) omap_device does not register a pm_domain (since it cannot find > hwmod entry). > b) driver does not know about (a), does a pm_runtime_get_sync which > never fails > c) It then tries to do some operation on the device (such as read the >revision register (as part of probe) without clock or adequate OMAP >generic PM operation performed for enabling the module. > > This causes a crash such as that reported in: > https://bugzilla.kernel.org/show_bug.cgi?id=66441 > > When 'ti,hwmod' is provided in dt node, it is expected that the device > will not function without the OMAP's power automanagement. Hence, when > we hit a fail condition (due to hwmod entries not present or other > similar scenario), fail at pm_domain level due to lack of data, provide > enough information for it to be fixed, however, it allows for the driver > to take appropriate measures to prevent crash. > > Reported-by: Tobias Jakobi > Signed-off-by: Nishanth Menon > --- > arch/arm/mach-omap2/omap_device.c | 24 > arch/arm/mach-omap2/omap_device.h |1 + > 2 files changed, 25 insertions(+) > > diff --git a/arch/arm/mach-omap2/omap_device.c > b/arch/arm/mach-omap2/omap_device.c > index 53f0735..e0a398c 100644 > --- a/arch/arm/mach-omap2/omap_device.c > +++ b/arch/arm/mach-omap2/omap_device.c > @@ -183,6 +183,10 @@ static int omap_device_build_from_dt(struct > platform_device *pdev) > odbfd_exit1: > kfree(hwmods); > odbfd_exit: > +/* if data/we are at fault.. load up a fail handler */ > +if (ret) > +pdev->dev.pm_domain = _device_fail_pm_domain; > + > return ret; > } > Just wondering, can't we just print the warning here instead of registering new pm_domain callbacks? >>> >>> I suggest you might want to read the commit message again.. but lets try >>> once >>> again: >> >> I know what your patch does and what the problem you're trying to solve is.. >> Was >> just trying to see if there's a better way of doing what you're trying to >> do.. > Thanks for clarifying. > >> > b) driver does not know about (a), does a pm_runtime_get_sync which > never fails" >>> >>> A device node stated it will have hwmod to adequately control it, but in >>> reality, as in this case, it does not. how does printing a warning alone >>> help >>> the driver which is not aware of these? The driver's attempt at >>> pm_runtime_sync >>> should fail, as that is what "ti,hwmod" property controls. >> >> Why not do the following? >> >> Assign pm_domain as omap_device_pm_domain always regardless of error or not. >> >> Then in the _od_runtime_resume, check if the od or hwmods exists. If not, >> print >> the warning. That way you don't need to register additional special callbacks >> just to print a warning and will prolly be fewer LoC fwiw. >> >> That may be harder to do and may require additional checks in >> omap_device_enable >> etc, not sure. In that case, your approach is certainly the next best way. >> Just >> thought its worth looking into :) > > fair enough, The moment we use the generic omap_device_pm_domain, the > remaining code which assumes od will be valid will need checking.. (so, > we got to do that for all functions where usage is present - fine, that > can be done too)[1] - and yes, it will take care of the pm_runtime handling > However, lets look at the side effect, omap_device_pm_domain also > registers generic suspend_noirq and resume_noirq, and _od_suspend_noirq will > also fail -> as a result device will fail to even attempt to suspend. > > That IMHO, is a wrong behavior, So, that explains why we'd need a > omap_device_fail_pm_domain. Keeps the error handling completely > seperated from regular code. Sorry for the late reply due to travel. Ok, in that case then your patch is OK method to fix it. If required for FWIW, Acked-by: Joel Fernandes regards, -Joel > > > [1] > diff --git a/arch/arm/mach-omap2/omap_device.c > b/arch/arm/mach-omap2/omap_device.c > index 53f0735..029f076 100644 > --- a/arch/arm/mach-omap2/omap_device.c > +++ b/arch/arm/mach-omap2/omap_device.c > @@ -173,7 +173,6 @@ static int omap_device_build_from_dt(struct > platform_device *pdev) > r->name = dev_name(>dev); > } > > - pdev->dev.pm_domain =
Re: [PATCH tip/core/locking 4/4] Documentation/memory-barriers.txt: Document ACCESS_ONCE()
* Paul E. McKenney wrote:
> + (*) The compiler is within its rights to reorder memory accesses unless
> + you tell it not to. For example, consider the following interaction
> + between process-level code and an interrupt handler:
> +
> + void process_level(void)
> + {
> + msg = get_message();
> + flag = true;
> + }
> +
> + void interrupt_handler(void)
> + {
> + if (flag)
> + process_message(msg);
> + }
> +
> + There is nothing to prevent the the compiler from transforming
> + process_level() to the following, in fact, this might well be a
> + win for single-threaded code:
> +
> + void process_level(void)
> + {
> + flag = true;
> + msg = get_message();
> + }
> +
> + If the interrupt occurs between these two statement, then
> + interrupt_handler() might be passed a garbled msg. Use ACCESS_ONCE()
> + to prevent this as follows:
> +
> + void process_level(void)
> + {
> + ACCESS_ONCE(msg) = get_message();
> + ACCESS_ONCE(flag) = true;
> + }
> +
> + void interrupt_handler(void)
> + {
> + if (ACCESS_ONCE(flag))
> + process_message(ACCESS_ONCE(msg));
> + }
Technically, if the interrupt handler is the innermost context, the
ACCESS_ONCE() is not needed in the interrupt_handler() code.
Since for the vast majority of Linux code IRQ handlers are the most
atomic contexts (very few drivers deal with NMIs) I suspect we should
either remove that ACCESS_ONCE() from the example or add a comment
explaining that in many cases those are superfluous?
> + (*) For aligned memory locations whose size allows them to be accessed
> + with a single memory-reference instruction, prevents "load tearing"
> + and "store tearing," in which a single large access is replaced by
> + multiple smaller accesses. For example, given an architecture having
> + 16-bit store instructions with 7-bit immediate fields, the compiler
> + might be tempted to use two 16-bit store-immediate instructions to
> + implement the following 32-bit store:
> +
> + p = 0x00010002;
> +
> + Please note that GCC really does use this sort of optimization,
> + which is not surprising given that it would likely take more
> + than two instructions to build the constant and then store it.
> + This optimization can therefore be a win in single-threaded code.
> + In fact, a recent bug (since fixed) caused GCC to incorrectly use
> + this optimization in a volatile store. In the absence of such bugs,
> + use of ACCESS_ONCE() prevents store tearing:
> +
> + ACCESS_ONCE(p) = 0x00010002;
I suspect the last sentence should read:
> + In the absence of such bugs,
> + use of ACCESS_ONCE() prevents store tearing in this example:
> +
> + ACCESS_ONCE(p) = 0x00010002;
Otherwise it could be read as a more generic statement (leaving out
'load tearing')?
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: [RFC 0/6] perf tools: Add perf_evlist errno
On Mon, Dec 02, 2013 at 05:19:18PM +0900, Namhyung Kim wrote:
> Hi Jiri,
>
> On Fri, 29 Nov 2013 12:45:04 +0100, Jiri Olsa wrote:
> > hi,
> > Andi reported wrong error message for :S modifier
> > on kernel without event ID ioctl support.
> >
> > The reason was that the ioctl failed, but the error was
> > printed like the mmap would:
> >
> > $ perf.old record -e '{cycles,cache-misses}:S' ls
> > failed to mmap with 25 (Inappropriate ioctl for device)
> > ls: Terminated
>
> I see same confusing error message..
>
> >
> > I experimentally added sort of 'libc errno' interface for
> > perf_evlist to be able to get proper error message, like:
> >
> > $ perf record -e '{cycles,cache-misses}:S' ls
> > Cannot read event group on this kernel.
> > Please consider kernel update (v3.12+).
> > ls: Terminated
> >
> > I'm not sure about this approach. Maybe it'd be better be more
> > global..? So before throwing this out, sending it as RFC ;-)
>
> I like it. :) We still need to improve this user-visible error handling.
>
> But what you mean by 'more global'? I think the evlist APIs are pretty
> global alreay. And we have same error handling in perf_target code too.
aah, missed the target object has that already.. I meant
to keep the same way of error handling globaly
>
> But I think it'd be better making it thread-safe even though it's not
> needed for now. The code is growing really fast.. ;-)
ok, will repost
thanks,
jirka
--
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 28/28] perf tools: Add udis86 disassembler feature check
* Jiri Olsa wrote: > On Wed, Dec 04, 2013 at 03:50:24PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Tue, Dec 03, 2013 at 02:09:42PM +0100, Jiri Olsa escreveu: > > > Adding udis86 disassembler feature check which support > > > is needed for kvm:kvm_emulate_insn tracepoint. > > > > > > +$(call feature_check,udis86) > > > +ifeq ($(feature-udis86), 1) > > > + LIBTRACEEVENT_CFLAGS += -DHAVE_UDIS86 > > > + EXTLIBS += -ludis86 > > > +else > > > + msg := $(warning No udis86 support.); > > > +endif > > > > That is really an incomplete message, what package should I install? > > Perhaps we should add this there then: > > > > http://bit.ly/1hyrN52 > > nice :-) > > > > > Wow, that was easy, but yeah, could be made easier 8-) ;-P > > so something like: > No udis86 found. Please install udis86-devel. > > or: > No udis86 found, disabling kvm tracepoints instruction disassembly. Please > install udis86-devel. 1) So, the first problem I can see is in the output: Auto-detecting system features: ... backtrace: [ on ] ... dwarf: [ on ] ...fortify-source: [ on ] ... glibc: [ on ] ... gtk2: [ on ] ... gtk2-infobar: [ on ] ... libaudit: [ on ] ...libbfd: [ on ] ...libelf: [ on ] ... libelf-getphdrnum: [ on ] ... libelf-mmap: [ on ] ... libnuma: [ on ] ... libperl: [ on ] ... libpython: [ on ] ... libpython-version: [ on ] ... libslang: [ on ] ... libunwind: [ on ] ... on-exit: [ on ] ...stackprotector-all: [ on ] ... timerfd: [ on ] config/Makefile:421: No udis86 support. such a 'no XYZ support' message should only occur if a feature test failed. _If_ we decide that 'udis86' support is required for a full perf build then there should be a new line saying something like: ...udis86: [ OFF ] 2) The other problem I see is that I think we should start adding the install-suggestions to the feature-check lines themselves. On .deb based systems it should say something like: ... on-exit: [ on ] ...stackprotector-all: [ on ] ... timerfd: [ on ] ...udis86: [ OFF ]# apt-get install udis86-dev On RPM based systems it should say something like: ... on-exit: [ on ] ...stackprotector-all: [ on ] ... timerfd: [ on ] ...udis86: [ OFF ]# yum install udis86-devel Or so. I think we can maintain package suggestion strings for these two main distro variants. The package install strings should probably be maintained together with the list of feature names in some table/list format. Such lookup tables can be implemented either in Make via: http://www.gnu.org/savannah-checkouts/gnu/make/manual/html_node/Computed-Names.html Or via a shell command in the makefile, using Bash associative arrays or such. Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 1/1] gpio: twl4030: Fix regression for twl gpio LED output
Commit 0b2aa8be introduced a regression that causes failure
in setting LED GPO direction to OUT.
This causes USB host probe failures for Beagleboard C4.
[2.075469] platform usb_phy_gen_xceiv.2: Driver usb_phy_gen_xceiv requests
probe deferral
[2.090454] hsusb2_vcc: Failed to request enable GPIO510: -22
[2.100982] reg-fixed-voltage reg-fixed-voltage.0.auto: Failed to register
regulator: -22
[2.109954] reg-fixed-voltage: probe of reg-fixed-voltage.0.auto failed with
error -22
direction_out/direction_in must return 0 if the operation succeeded.
Also, don't update direction flag and output data if
twl4030_set_gpio_direction()
failed inside twl_direction_out();
Signed-off-by: Roger Quadros
---
drivers/gpio/gpio-twl4030.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
index b97d6a6..f999689 100644
--- a/drivers/gpio/gpio-twl4030.c
+++ b/drivers/gpio/gpio-twl4030.c
@@ -300,7 +300,7 @@ static int twl_direction_in(struct gpio_chip *chip,
unsigned offset)
if (offset < TWL4030_GPIO_MAX)
ret = twl4030_set_gpio_direction(offset, 1);
else
- ret = -EINVAL;
+ ret = -EINVAL; /* LED outputs can't be set as input */
if (!ret)
priv->direction &= ~BIT(offset);
@@ -354,11 +354,20 @@ static void twl_set(struct gpio_chip *chip, unsigned
offset, int value)
static int twl_direction_out(struct gpio_chip *chip, unsigned offset, int
value)
{
struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
- int ret = -EINVAL;
+ int ret = 0;
mutex_lock(>mutex);
- if (offset < TWL4030_GPIO_MAX)
+ if (offset < TWL4030_GPIO_MAX) {
ret = twl4030_set_gpio_direction(offset, 0);
+ if (ret) {
+ mutex_unlock(>mutex);
+ return ret;
+ }
+ }
+
+ /*
+* LED gpios i.e. offset >= TWL4030_GPIO_MAX are always output
+*/
priv->direction |= BIT(offset);
mutex_unlock(>mutex);
--
1.8.3.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCHv4 28/28] perf tools: Add udis86 disassembler feature check
On Thu, Dec 05, 2013 at 09:05:13AM +0100, Jiri Olsa wrote: > On Wed, Dec 04, 2013 at 03:50:24PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Tue, Dec 03, 2013 at 02:09:42PM +0100, Jiri Olsa escreveu: > > > Adding udis86 disassembler feature check which support > > > is needed for kvm:kvm_emulate_insn tracepoint. > > > > > > +$(call feature_check,udis86) > > > +ifeq ($(feature-udis86), 1) > > > + LIBTRACEEVENT_CFLAGS += -DHAVE_UDIS86 > > > + EXTLIBS += -ludis86 > > > +else > > > + msg := $(warning No udis86 support.); > > > +endif > > > > That is really an incomplete message, what package should I install? > > Perhaps we should add this there then: > > > > http://bit.ly/1hyrN52 > > nice :-) > > > > > Wow, that was easy, but yeah, could be made easier 8-) ;-P > > so something like: > No udis86 found. Please install udis86-devel. > > or: > No udis86 found, disabling kvm tracepoints instruction disassembly. Please > install udis86-devel. took the first one, v4 attached, perf/core_plugins is updated thanks, jirka --- Adding udis86 disassembler feature check which support is needed for kvm:kvm_emulate_insn tracepoint. The diff of 'perf script' output generated by old and new code: (data was generated by 'perf record -e kvm:kvm_emulate_insn -a') --- script.kvm.old +++ script.kvm.new - qemu-system-x86 15519 [003] 5332.470049: kvm:kvm_emulate_insn: 0:8103c596:89 b7 00 80 5f ff (prot64) + qemu-system-x86 15519 [003] 5332.470049: kvm:kvm_emulate_insn: 0:8103c596: mov %esi, -0xa08000(%rdi) Signed-off-by: Jiri Olsa Cc: Corey Ashford Cc: Frederic Weisbecker Cc: Ingo Molnar Cc: Namhyung Kim Cc: Paul Mackerras Cc: Peter Zijlstra Cc: Arnaldo Carvalho de Melo Cc: Steven Rostedt Cc: David Ahern --- tools/perf/Makefile.perf | 4 ++-- tools/perf/config/Makefile | 11 ++- tools/perf/config/feature-checks/Makefile | 8 ++-- tools/perf/config/feature-checks/test-all.c| 5 + tools/perf/config/feature-checks/test-udis86.c | 11 +++ 5 files changed, 34 insertions(+), 5 deletions(-) create mode 100644 tools/perf/config/feature-checks/test-udis86.c diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf index ca3b87d..5c4c8bd 100644 --- a/tools/perf/Makefile.perf +++ b/tools/perf/Makefile.perf @@ -712,7 +712,7 @@ $(LIB_FILE): $(LIB_OBJS) TE_SOURCES = $(wildcard $(TRACE_EVENT_DIR)*.[ch]) LIBTRACEEVENT_FLAGS = $(QUIET_SUBDIR1) O=$(OUTPUT) -LIBTRACEEVENT_FLAGS += CFLAGS="-g -Wall $(EXTRA_CFLAGS)" +LIBTRACEEVENT_FLAGS += CFLAGS="-g -Wall $(EXTRA_CFLAGS) $(LIBTRACEEVENT_CFLAGS)" LIBTRACEEVENT_FLAGS += plugin_dir=$(plugindir_SQ) $(LIBTRACEEVENT): $(TE_SOURCES) $(OUTPUT)PERF-CFLAGS @@ -793,7 +793,7 @@ cscope: ### Detect prefix changes TRACK_CFLAGS = $(subst ','\'',$(CFLAGS)):\ - $(bindir_SQ):$(perfexecdir_SQ):$(template_dir_SQ):$(prefix_SQ):$(plugindir_SQ) + $(bindir_SQ):$(perfexecdir_SQ):$(template_dir_SQ):$(prefix_SQ):$(plugindir_SQ):$(LIBTRACEEVENT_CFLAGS) $(OUTPUT)PERF-CFLAGS: .FORCE-PERF-CFLAGS @FLAGS='$(TRACK_CFLAGS)'; \ diff --git a/tools/perf/config/Makefile b/tools/perf/config/Makefile index bae1072..ddae5c4 100644 --- a/tools/perf/config/Makefile +++ b/tools/perf/config/Makefile @@ -142,7 +142,8 @@ CORE_FEATURE_TESTS =\ libunwind \ on-exit \ stackprotector-all \ - timerfd + timerfd \ + udis86 # # So here we detect whether test-all was rebuilt, to be able @@ -413,6 +414,14 @@ else msg := $(warning No timerfd support. Disables 'perf kvm stat live'); endif +$(call feature_check,udis86) +ifeq ($(feature-udis86), 1) + LIBTRACEEVENT_CFLAGS += -DHAVE_UDIS86 + EXTLIBS += -ludis86 +else + msg := $(warning No udis86 found. Please install udis86-devel.) +endif + disable-python = $(eval $(disable-python_code)) define disable-python_code CFLAGS += -DNO_LIBPYTHON diff --git a/tools/perf/config/feature-checks/Makefile b/tools/perf/config/feature-checks/Makefile index b8bb749..3ed2667 100644 --- a/tools/perf/config/feature-checks/Makefile +++ b/tools/perf/config/feature-checks/Makefile @@ -26,7 +26,8 @@ FILES=\ test-libunwind-debug-frame \ test-on-exit\ test-stackprotector-all \ - test-timerfd + test-timerfd\ + test-udis86 CC := $(CC) -MD @@ -37,7 +38,7 @@ BUILD = $(CC) $(CFLAGS) $(LDFLAGS) -o $(OUTPUT)$@ $@.c ### test-all: - $(BUILD) -Werror -fstack-protector-all -O2 -Werror -D_FORTIFY_SOURCE=2 -ldw -lelf -lnuma $(LIBUNWIND_LIBS) -lelf -laudit -I/usr/include/slang -lslang $(shell pkg-config --libs --cflags gtk+-2.0 2>/dev/null) $(FLAGS_PERL_EMBED) $(FLAGS_PYTHON_EMBED) -DPACKAGE='"perf"' -lbfd -ldl +
Re: [PATCH 1/2] usb: chipidea: fix mistake in device tree binding of nspire-usb to use vendor name 'lsi' instead of SoC name 'zevio'
On Thu, Dec 05, 2013 at 04:44:13PM +1100, Daniel Tang wrote:
> Hi,
>
> On 05/12/2013, at 12:44 AM, Peter Chen wrote:
>
> >
> > lsi is vendor name, what are zevio and nspire?
> > Usually, the compatible string should be "vendor_name,soc_name-module_name"
> >
>
> Because this port uses documentation from reverse engineering, it's difficult
> to work out what is SoC specific and what is device specific. The SoC is
> Zevio but the driver is written for the TI-Nspire.
>
Please wrap the line to 80 characters.
The driver is written for the TI-Nspire, and you port this driver for
SoC Zevio platform? Since you use chipidea ip, we don't care the usb
module name at your platform, we only care the soc name which you are
running, it can detect the SoC platform at runtime.
At your dts patch, it still uses nspire-usb.
http://marc.info/?l=linux-usb=138614886720024=2
Peter
> If it's usually "vendor_name,soc_name-module_name", I'll fix up this patch
> with zevio instead of nspire (and it'll be more consistent with the other
> drivers).
>
> >> - reg: Should contain registers location and length
> >> - interrupts: Should contain controller interrupt
> >>
> >> @@ -11,7 +11,7 @@ Recommended properies:
> >> Examples:
> >>usb0: usb@B000 {
> >>reg = <0xB000 0x1000>;
> >> - compatible = "zevio,nspire-usb";
> >> + compatible = "lsi,nspire-usb";
> >>interrupts = <8>;
> >>vbus-supply = <_reg>;
> >>};
> >> diff --git a/drivers/usb/chipidea/ci_hdrc_nspire.c
> >> b/drivers/usb/chipidea/ci_hdrc_nspire.c
> >> index 517ce41..c5c2dde 100644
> >> --- a/drivers/usb/chipidea/ci_hdrc_nspire.c
> >> +++ b/drivers/usb/chipidea/ci_hdrc_nspire.c
> >> @@ -52,7 +52,7 @@ static int ci_hdrc_nspire_remove(struct platform_device
> >> *pdev)
> >> }
> >>
> >> static const struct of_device_id ci_hdrc_nspire_dt_ids[] = {
> >> - { .compatible = "zevio,nspire-usb", },
> >> + { .compatible = "lsi,nspire-usb", },
> >>{ /* sentinel */ }
> >> };
> >>
> >> --
> >> 1.7.10.4
> >>
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> >> the body of a message to majord...@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >>
> >
> > --
> >
> > Best Regards,
> > Peter Chen
> >
>
> Cheers,
> Daniel Tang
--
Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[f2fs-dev] [PATCH 2/5 V2] f2fs: add unlikely() macro for compiler optimization
As we know, some of our branch condition will rarely be true. So we could add
'unlikely' to let compiler optimize these code, by this way we could drop
unneeded 'jump' assemble code to improve performance.
change log:
o add *unlikely* as many as possible across the whole source files at once
suggested by Jaegeuk Kim.
Suggested-by: Jaegeuk Kim
Signed-off-by: Chao Yu
---
fs/f2fs/checkpoint.c | 10 +-
fs/f2fs/data.c |4 ++--
fs/f2fs/dir.c|4 ++--
fs/f2fs/f2fs.h |8
fs/f2fs/node.c | 16
fs/f2fs/segment.h|2 +-
6 files changed, 22 insertions(+), 22 deletions(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 38f4a224..6580808 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -82,8 +82,8 @@ static int f2fs_write_meta_page(struct page *page,
struct f2fs_sb_info *sbi = F2FS_SB(inode->i_sb);
/* Should not write any meta pages, if any IO error was occurred */
- if (wbc->for_reclaim || sbi->por_doing ||
- is_set_ckpt_flags(F2FS_CKPT(sbi), CP_ERROR_FLAG)) {
+ if (unlikely(wbc->for_reclaim || sbi->por_doing ||
+ is_set_ckpt_flags(F2FS_CKPT(sbi), CP_ERROR_FLAG))) {
dec_page_count(sbi, F2FS_DIRTY_META);
wbc->pages_skipped++;
set_page_dirty(page);
@@ -137,7 +137,7 @@ long sync_meta_pages(struct f2fs_sb_info *sbi, enum
page_type type,
nr_pages = pagevec_lookup_tag(, mapping, ,
PAGECACHE_TAG_DIRTY,
min(end - index, (pgoff_t)PAGEVEC_SIZE-1) + 1);
- if (nr_pages == 0)
+ if (unlikely(nr_pages == 0))
break;
for (i = 0; i < nr_pages; i++) {
@@ -150,7 +150,7 @@ long sync_meta_pages(struct f2fs_sb_info *sbi, enum
page_type type,
unlock_page(page);
break;
}
- if (nwritten++ >= nr_to_write)
+ if (unlikely(nwritten++ >= nr_to_write))
break;
}
pagevec_release();
@@ -200,7 +200,7 @@ int acquire_orphan_inode(struct f2fs_sb_info *sbi)
max_orphans = (sbi->blocks_per_seg - 2 - NR_CURSEG_TYPE)
* F2FS_ORPHANS_PER_BLOCK;
mutex_lock(>orphan_inode_mutex);
- if (sbi->n_orphans >= max_orphans)
+ if (unlikely(sbi->n_orphans >= max_orphans))
err = -ENOSPC;
else
sbi->n_orphans++;
diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 4e2fc09..2ce5a9e 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -251,7 +251,7 @@ int reserve_new_block(struct dnode_of_data *dn)
if (is_inode_flag_set(F2FS_I(dn->inode), FI_NO_ALLOC))
return -EPERM;
- if (!inc_valid_block_count(sbi, dn->inode, 1))
+ if (unlikely(!inc_valid_block_count(sbi, dn->inode, 1)))
return -ENOSPC;
trace_f2fs_reserve_new_block(dn->inode, dn->nid, dn->ofs_in_node);
@@ -711,7 +711,7 @@ static int f2fs_write_data_page(struct page *page,
zero_user_segment(page, offset, PAGE_CACHE_SIZE);
write:
- if (sbi->por_doing) {
+ if (unlikely(sbi->por_doing)) {
err = AOP_WRITEPAGE_ACTIVATE;
goto redirty_out;
}
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index 594fc1b..0cc26ba 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -190,7 +190,7 @@ struct f2fs_dir_entry *f2fs_find_entry(struct inode *dir,
unsigned int max_depth;
unsigned int level;
- if (namelen > F2FS_NAME_LEN)
+ if (unlikely(namelen > F2FS_NAME_LEN))
return NULL;
if (npages == 0)
@@ -461,7 +461,7 @@ int __f2fs_add_link(struct inode *dir, const struct qstr
*name, struct inode *in
}
start:
- if (current_depth == MAX_DIR_HASH_DEPTH)
+ if (unlikely(current_depth == MAX_DIR_HASH_DEPTH))
return -ENOSPC;
/* Increase the depth, if required */
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 10eca02..dca18b3 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -574,7 +574,7 @@ static inline void f2fs_unlock_all(struct f2fs_sb_info *sbi)
static inline int check_nid_range(struct f2fs_sb_info *sbi, nid_t nid)
{
WARN_ON((nid >= NM_I(sbi)->max_nid));
- if (nid >= NM_I(sbi)->max_nid)
+ if (unlikely(nid >= NM_I(sbi)->max_nid))
return -EINVAL;
return 0;
}
@@ -600,7 +600,7 @@ static inline bool inc_valid_block_count(struct
f2fs_sb_info *sbi,
spin_lock(>stat_lock);
valid_block_count =
sbi->total_valid_block_count + (block_t)count;
- if (valid_block_count > sbi->user_block_count) {
+ if (unlikely(valid_block_count > sbi->user_block_count)) {
Re: [PATCH 1/1] gpio: twl4030: Fix regression for twl gpio LED output
On 12/04/2013 07:37 PM, Tony Lindgren wrote:
> * Roger Quadros [131204 03:35]:
>> Commit 0b2aa8be introduced a regression that causes failure
>> in setting LED GPO direction to OUT.
>>
>> This causes USB host probe failures for Beagleboard C4.
>>
>> [2.075469] platform usb_phy_gen_xceiv.2: Driver usb_phy_gen_xceiv
>> requests probe deferral
>> [2.090454] hsusb2_vcc: Failed to request enable GPIO510: -22
>> [2.100982] reg-fixed-voltage reg-fixed-voltage.0.auto: Failed to
>> register regulator: -22
>> [2.109954] reg-fixed-voltage: probe of reg-fixed-voltage.0.auto failed
>> with error -22
>>
>> direction_out/direction_in must return 0 if the operation succeeded.
>
> Uh, OK, sorry that was an unexpected side effect. We still should keep the
> return values though instead of just ignoring them.
OK.
>
>> 1 file changed, 9 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpio/gpio-twl4030.c b/drivers/gpio/gpio-twl4030.c
>> index b97d6a6..0999ed1 100644
>> --- a/drivers/gpio/gpio-twl4030.c
>> +++ b/drivers/gpio/gpio-twl4030.c
>> @@ -294,13 +294,13 @@ out:
>> static int twl_direction_in(struct gpio_chip *chip, unsigned offset)
>> {
>> struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
>> -int ret;
>> +int ret = 0;
>>
>> mutex_lock(>mutex);
>> if (offset < TWL4030_GPIO_MAX)
>> -ret = twl4030_set_gpio_direction(offset, 1);
>> +twl4030_set_gpio_direction(offset, 1);
>> else
>> -ret = -EINVAL;
>> +ret = -EINVAL; /* LED outputs can't be set as input */
>>
>> if (!ret)
>> priv->direction &= ~BIT(offset);
>
> This looks OK to me.
>
>> @@ -354,18 +354,21 @@ static void twl_set(struct gpio_chip *chip, unsigned
>> offset, int value)
>> static int twl_direction_out(struct gpio_chip *chip, unsigned offset, int
>> value)
>> {
>> struct gpio_twl4030_priv *priv = to_gpio_twl4030(chip);
>> -int ret = -EINVAL;
>>
>
> Can't you just have:
>
> int ret = 0;
Yes, i'll add that.
>
>> mutex_lock(>mutex);
>> if (offset < TWL4030_GPIO_MAX)
>> -ret = twl4030_set_gpio_direction(offset, 0);
>> +twl4030_set_gpio_direction(offset, 0);
>> +
>> +/*
>> + * LED gpio's i.e. offset >= TWL4030_GPIO_MAX are always output
>> + */
>>
>> priv->direction |= BIT(offset);
>> mutex_unlock(>mutex);
>>
>> twl_set(chip, offset, value);
>>
>> -return ret;
>> +return 0;
>> }
>
> Then the rest of this change is not needed and we check the return value for
> twl4030_set_gpio_direction. Makes sense to keep the comment there though.
OK. Will post v2.
cheers,
-roger
--
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 34/39] vme: remove DEFINE_PCI_DEVICE_TABLE macro
On Tue, Dec 3, 2013 at 7:29 AM, Jingoo Han wrote:
> Don't use DEFINE_PCI_DEVICE_TABLE macro, because this macro
> is not preferred.
>
> Signed-off-by: Jingoo Han
> ---
Greg, this patch should be reverted. It do the opposite things.
> drivers/vme/boards/vme_vmivme7805.c |2 +-
> drivers/vme/bridges/vme_ca91cx42.c |2 +-
> drivers/vme/bridges/vme_tsi148.c|2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/vme/boards/vme_vmivme7805.c
> b/drivers/vme/boards/vme_vmivme7805.c
> index cf74aee..ac42212 100644
> --- a/drivers/vme/boards/vme_vmivme7805.c
> +++ b/drivers/vme/boards/vme_vmivme7805.c
> @@ -27,7 +27,7 @@ static void __iomem *vmic_base;
>
> static const char driver_name[] = "vmivme_7805";
>
> -static DEFINE_PCI_DEVICE_TABLE(vmic_ids) = {
> +static const struct pci_device_id vmic_ids[] = {
> { PCI_DEVICE(PCI_VENDOR_ID_VMIC, PCI_DEVICE_ID_VTIMR) },
> { },
> };
> diff --git a/drivers/vme/bridges/vme_ca91cx42.c
> b/drivers/vme/bridges/vme_ca91cx42.c
> index f844857..a06edbf 100644
> --- a/drivers/vme/bridges/vme_ca91cx42.c
> +++ b/drivers/vme/bridges/vme_ca91cx42.c
> @@ -42,7 +42,7 @@ static int geoid;
>
> static const char driver_name[] = "vme_ca91cx42";
>
> -static DEFINE_PCI_DEVICE_TABLE(ca91cx42_ids) = {
> +static const struct pci_device_id ca91cx42_ids[] = {
> { PCI_DEVICE(PCI_VENDOR_ID_TUNDRA, PCI_DEVICE_ID_TUNDRA_CA91C142) },
> { },
> };
> diff --git a/drivers/vme/bridges/vme_tsi148.c
> b/drivers/vme/bridges/vme_tsi148.c
> index 9cf8833..16830d8 100644
> --- a/drivers/vme/bridges/vme_tsi148.c
> +++ b/drivers/vme/bridges/vme_tsi148.c
> @@ -45,7 +45,7 @@ static int geoid;
>
> static const char driver_name[] = "vme_tsi148";
>
> -static DEFINE_PCI_DEVICE_TABLE(tsi148_ids) = {
> +static const struct pci_device_id tsi148_ids[] = {
> { PCI_DEVICE(PCI_VENDOR_ID_TUNDRA, PCI_DEVICE_ID_TUNDRA_TSI148) },
> { },
> };
> --
> 1.7.10.4
>
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
--
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] crypto: remove unnecessary includes
> If you can't work out why authenc.c needs slab.h I don't think > you should be submitting patches removing unnecessary header > files. [] You left out "kernel.h". I really hoped this would not be your answer. Yes, I'm an ignorant and yes, I ask questions. But if all you got is this type of answer, then maybe, just maybe, you should reconsider your ivory tower position. The point is, if it's such a simple and obvious explanation, you should have said it instead of making me feel small. If it is not, then you should fix the pool of missing comments in crypto API (or should I read the obvious code instead?). Even Linus pointed your mistakes when it was the case - or you never make mistakes? You tried but your answer doesn't raise to the level of "kernel-locking.tmpl" one (and yes, I do get the "why" there). For anyone else who cares, please lift me up from my ignorance. Cristian S. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm: compaction: Trace compaction begin and end v2
Changelog since V1
o Print output parameters in pfn order (vbabka)
This patch adds two tracepoints for compaction begin and end of a zone. Using
this it is possible to calculate how much time a workload is spending
within compaction and potentially debug problems related to cached pfns
for scanning. In combination with the direct reclaim and slab trace points
it should be possible to estimate most allocation-related overhead for
a workload.
Signed-off-by: Mel Gorman
---
include/trace/events/compaction.h | 42 +++
mm/compaction.c | 4
2 files changed, 46 insertions(+)
diff --git a/include/trace/events/compaction.h
b/include/trace/events/compaction.h
index fde1b3e..06f544e 100644
--- a/include/trace/events/compaction.h
+++ b/include/trace/events/compaction.h
@@ -67,6 +67,48 @@ TRACE_EVENT(mm_compaction_migratepages,
__entry->nr_failed)
);
+TRACE_EVENT(mm_compaction_begin,
+ TP_PROTO(unsigned long zone_start, unsigned long migrate_start,
+ unsigned long free_start, unsigned long zone_end),
+
+ TP_ARGS(zone_start, migrate_start, free_start, zone_end),
+
+ TP_STRUCT__entry(
+ __field(unsigned long, zone_start)
+ __field(unsigned long, migrate_start)
+ __field(unsigned long, free_start)
+ __field(unsigned long, zone_end)
+ ),
+
+ TP_fast_assign(
+ __entry->zone_start = zone_start;
+ __entry->migrate_start = migrate_start;
+ __entry->free_start = free_start;
+ __entry->zone_end = zone_end;
+ ),
+
+ TP_printk("zone_start=%lu migrate_start=%lu free_start=%lu
zone_end=%lu",
+ __entry->zone_start,
+ __entry->migrate_start,
+ __entry->free_start,
+ __entry->zone_end)
+);
+
+TRACE_EVENT(mm_compaction_end,
+ TP_PROTO(int status),
+
+ TP_ARGS(status),
+
+ TP_STRUCT__entry(
+ __field(int, status)
+ ),
+
+ TP_fast_assign(
+ __entry->status = status;
+ ),
+
+ TP_printk("status=%d", __entry->status)
+);
#endif /* _TRACE_COMPACTION_H */
diff --git a/mm/compaction.c b/mm/compaction.c
index 805165b..bb50fd3 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -966,6 +966,8 @@ static int compact_zone(struct zone *zone, struct
compact_control *cc)
if (compaction_restarting(zone, cc->order) && !current_is_kswapd())
__reset_isolation_suitable(zone);
+ trace_mm_compaction_begin(start_pfn, cc->migrate_pfn, cc->free_pfn,
end_pfn);
+
migrate_prep_local();
while ((ret = compact_finished(zone, cc)) == COMPACT_CONTINUE) {
@@ -1011,6 +1013,8 @@ out:
cc->nr_freepages -= release_freepages(>freepages);
VM_BUG_ON(cc->nr_freepages != 0);
+ trace_mm_compaction_end(ret);
+
return ret;
}
--
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/4] pciehp: Use link change notifications for hot-plug and removal
On 2013/12/4 6:32, Rajat Jain wrote:
> A lot of systems do not have the fancy buttons and LEDs, and instead
> want to rely only on the Link state change events to drive the hotplug
> and removal state machinery.
> (http://www.spinics.net/lists/hotplug/msg05802.html)
>
> This patch adds support for that functionality. Here are the details
> about the patch itself:
>
> * Define and use interrupt events for linkup / linkdown.
>
> * Introduce the functions to handle link-up and link-down events and
> queue the work in the slot->wq to be processed by pciehp_power_thread
>
> * The current code bails out from device removal, if an adapter is not
> detected. That is not right, because if an adapter is not present at
> all, it provides all the more reason to REMOVE the device. This is
> specially a problem for link state hot-plug, because some ports use
> in band mechanism to detect the presence detection. Thus when link
> goes down, presence detect also goes down. We _want_ that the devices
> should be removed in this case.
>
> * The current pciehp driver disabled the link in case of a hot-removal.
> Since for link change based hot-plug to work, we need that enabled,
> hence make sure to not disable the link permanently if link state
> based hot-plug is to be used. Also have to remove
> pciehp_link_disable() and pcie_wait_link_not_active() static functions
> since they are not being used anywhere else.
>
> * pciehp_reset_slot - reset of secondary bus may cause undesirable
> spurious link notifications. Thus disable these around the secondary
> bus reset.
>
> Signed-off-by: Rajat Jain
> Signed-off-by: Guenter Roeck
> ---
> v2: - drop the use_link_state_events module parameter as discussed here:
>http://marc.info/?t=13851396686=1=2
> - removed the static functions left unused after this patch.
> - make the pciehp_handle_linkstate_change() return void.
> - dropped the "RFC" from subject, and added Guenter's signature
>
> drivers/pci/hotplug/pciehp.h |3 +
> drivers/pci/hotplug/pciehp_ctrl.c | 130
> ++---
> drivers/pci/hotplug/pciehp_hpc.c | 56
> 3 files changed, 150 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/pci/hotplug/pciehp.h b/drivers/pci/hotplug/pciehp.h
> index fc322ed..353edda 100644
> --- a/drivers/pci/hotplug/pciehp.h
> +++ b/drivers/pci/hotplug/pciehp.h
> @@ -110,6 +110,8 @@ struct controller {
> #define INT_BUTTON_PRESS 7
> #define INT_BUTTON_RELEASE 8
> #define INT_BUTTON_CANCEL9
> +#define INT_LINK_UP 10
> +#define INT_LINK_DOWN11
>
> #define STATIC_STATE 0
> #define BLINKINGON_STATE 1
> @@ -133,6 +135,7 @@ u8 pciehp_handle_attention_button(struct slot *p_slot);
> u8 pciehp_handle_switch_change(struct slot *p_slot);
> u8 pciehp_handle_presence_change(struct slot *p_slot);
> u8 pciehp_handle_power_fault(struct slot *p_slot);
> +void pciehp_handle_linkstate_change(struct slot *p_slot);
> int pciehp_configure_device(struct slot *p_slot);
> int pciehp_unconfigure_device(struct slot *p_slot);
> void pciehp_queue_pushbutton_work(struct work_struct *work);
> diff --git a/drivers/pci/hotplug/pciehp_ctrl.c
> b/drivers/pci/hotplug/pciehp_ctrl.c
> index 38f0186..4c2544c 100644
> --- a/drivers/pci/hotplug/pciehp_ctrl.c
> +++ b/drivers/pci/hotplug/pciehp_ctrl.c
> @@ -150,6 +150,27 @@ u8 pciehp_handle_power_fault(struct slot *p_slot)
> return 1;
> }
>
> +void pciehp_handle_linkstate_change(struct slot *p_slot)
> +{
> + u32 event_type;
> + struct controller *ctrl = p_slot->ctrl;
> +
> + /* Link Status Change */
> + ctrl_dbg(ctrl, "Data Link Layer State change\n");
> +
> + if (pciehp_check_link_active(ctrl)) {
> + ctrl_info(ctrl, "slot(%s): Link Up event\n",
> + slot_name(p_slot));
> + event_type = INT_LINK_UP;
> + } else {
> + ctrl_info(ctrl, "slot(%s): Link Down event\n",
> + slot_name(p_slot));
> + event_type = INT_LINK_DOWN;
> + }
> +
> + queue_interrupt_event(p_slot, event_type);
> +}
> +
> /* The following routines constitute the bulk of the
> hotplug controller logic
> */
> @@ -442,6 +463,100 @@ static void handle_surprise_event(struct slot *p_slot)
> queue_work(p_slot->wq, >work);
> }
>
> +/*
> + * Note: This function must be called with slot->lock held
> + */
> +static void handle_link_up_event(struct slot *p_slot)
> +{
> + struct controller *ctrl = p_slot->ctrl;
> + struct power_work_info *info;
> +
> + info = kmalloc(sizeof(*info), GFP_KERNEL);
> + if (!info) {
> + ctrl_err(p_slot->ctrl, "%s: Cannot allocate memory\n",
> + __func__);
> + return;
> + }
> + info->p_slot = p_slot;
> + INIT_WORK(>work, pciehp_power_thread);
> +
> +
Re: [PATCH] mm: compaction: Trace compaction begin and end
On Wed, Dec 04, 2013 at 03:51:57PM +0100, Vlastimil Babka wrote: > On 12/04/2013 03:30 PM, Mel Gorman wrote: > >This patch adds two tracepoints for compaction begin and end of a zone. Using > >this it is possible to calculate how much time a workload is spending > >within compaction and potentially debug problems related to cached pfns > >for scanning. > > I guess for debugging pfns it would be also useful to print their > values also in mm_compaction_end. > What additional information would we get from it and what new conclusions could we draw? We could guess how much work the scanners did but the trace_mm_compaction_isolate_freepages and trace_mm_compaction_isolate_migratepages tracepoints already accurately tell us that. The scanner PFNs alone do not tell us if the cached pfns were updated and even if it did, the information can be changed by parallel resets so it would be hard to draw reasonable conclusions from the information. We could guess where compaction hotspots might be but without the skip information, we could not detect it accurately. If we wanted to detect that accurately, the mm_compaction_isolate* tracepoints would be the one to update. I was primarily concerned about compaction time so I might be looking at this the wrong way but it feels like having the PFNs at the end of a compaction cycle would be of marginal benefit. > >In combination with the direct reclaim and slab trace points > >it should be possible to estimate most allocation-related overhead for > >a workload. > > > >Signed-off-by: Mel Gorman > >--- > > include/trace/events/compaction.h | 42 > > +++ > > mm/compaction.c | 4 > > 2 files changed, 46 insertions(+) > > > >diff --git a/include/trace/events/compaction.h > >b/include/trace/events/compaction.h > >index fde1b3e..f4e115a 100644 > >--- a/include/trace/events/compaction.h > >+++ b/include/trace/events/compaction.h > >@@ -67,6 +67,48 @@ TRACE_EVENT(mm_compaction_migratepages, > > __entry->nr_failed) > > ); > > > >+TRACE_EVENT(mm_compaction_begin, > >+TP_PROTO(unsigned long zone_start, unsigned long migrate_start, > >+unsigned long zone_end, unsigned long free_start), > >+ > >+TP_ARGS(zone_start, migrate_start, zone_end, free_start), > > IMHO a better order would be: > zone_start, migrate_start, free_start, zone_end > (well especially in the TP_printk part anyway). > Ok, that would put them in PFN order which may be easier to visualise. I'll post a V2 with that change at least. -- Mel Gorman SUSE Labs -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 28/39] staging: remove DEFINE_PCI_DEVICE_TABLE macro
On Tue, Dec 3, 2013 at 7:26 AM, Jingoo Han wrote: > Don't use DEFINE_PCI_DEVICE_TABLE macro, because this macro > is not preferred. > > Signed-off-by: Jingoo Han > I think you misunderstood the checkpatch.pl warning, it tells you what to do, not what not to do. WARNING: Use DEFINE_PCI_DEVICE_TABLE for struct pci_device_id This means use DEFINE_PCI_DEVICE_TABLE to replace struct pci_device_id, not reverse. -- 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] cgroup: fix bug on cgroup_create() fail path
If cgroup_create() fails to online_css() we will get a bug:
BUG: unable to handle kernel NULL pointer dereference at 0008
IP: [] cgroup_destroy_locked+0x118/0x2f0
PGD a780a067 PUD aadbe067 PMD 0
Oops: [#1] SMP
Modules linked in:
CPU: 6 PID: 7360 Comm: mkdir Not tainted 3.13.0-rc2+ #69
Hardware name:
task: 8800b9dbec00 ti: 8800a781a000 task.ti: 8800a781a000
RIP: 0010:[] []
cgroup_destroy_locked+0x118/0x2f0
RSP: 0018:8800a781bd98 EFLAGS: 00010282
RAX: 880586903878 RBX: 880586903800 RCX: 880586903820
RDX: 880586903860 RSI: 8800a781bdb0 RDI: 880586903820
RBP: 8800a781bde8 R08: 88060e0b8048 R09: 811d7bc1
R10: 008c R11: 0001 R12: 8800a72286c0
R13: R14: 81cf7a40 R15: 0001
FS: 7f60ecda57a0() GS:8806272c() knlGS:
CS: 0010 DS: ES: CR0: 80050033
CR2: 0008 CR3: a7a03000 CR4: 07e0
Stack:
880586903860 880586903910 8800a72286c0 880586903820
81cf7a40 880586903800 88060e0b8018 81cf7a40
8800b9dbec00 8800b9dbf098 8800a781bec8 810ef5bf
Call Trace:
[] cgroup_mkdir+0x55f/0x5f0
[] vfs_mkdir+0xee/0x140
[] SyS_mkdirat+0x6e/0xf0
[] SyS_mkdir+0x19/0x20
[] system_call_fastpath+0x16/0x1b
The point is that cgroup_destroy_locked() that is called on the fail
path assumes all css's have already been assigned to the cgroup, which
is not true, and calls kill_css() to destroy them.
The patch makes css_online() proceed to assigning css to a cgroup even
if subsys-specific css_online method fails - it only skips setting
CSS_ONLINE flag then. Respectively, offline_css() should skip only
subsys-specific css_offline method if CSS_ONLINE is not set. Besides, it
makes cgroup_create() call online_css() for all css's before going to
cgroup_destroy_locked(). It is not that optimal, but it's only a fail
path.
Signed-off-by: Vladimir Davydov
Cc: Tejun Heo
Cc: Li Zefan
---
kernel/cgroup.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/kernel/cgroup.c b/kernel/cgroup.c
index 8b729c2..1846923 100644
--- a/kernel/cgroup.c
+++ b/kernel/cgroup.c
@@ -4296,11 +4296,10 @@ static int online_css(struct cgroup_subsys_state *css)
if (ss->css_online)
ret = ss->css_online(css);
- if (!ret) {
+ if (!ret)
css->flags |= CSS_ONLINE;
- css->cgroup->nr_css++;
- rcu_assign_pointer(css->cgroup->subsys[ss->subsys_id], css);
- }
+ css->cgroup->nr_css++;
+ rcu_assign_pointer(css->cgroup->subsys[ss->subsys_id], css);
return ret;
}
@@ -4311,10 +4310,7 @@ static void offline_css(struct cgroup_subsys_state *css)
lockdep_assert_held(_mutex);
- if (!(css->flags & CSS_ONLINE))
- return;
-
- if (ss->css_offline)
+ if ((css->flags & CSS_ONLINE) && ss->css_offline)
ss->css_offline(css);
css->flags &= ~CSS_ONLINE;
@@ -4437,13 +4433,20 @@ static long cgroup_create(struct cgroup *parent, struct
dentry *dentry,
/* hold a ref to the parent's dentry */
dget(parent->dentry);
+ err = 0;
+
/* creation succeeded, notify subsystems */
for_each_root_subsys(root, ss) {
struct cgroup_subsys_state *css = css_ar[ss->subsys_id];
+ int ret;
- err = online_css(css);
- if (err)
- goto err_destroy;
+ /* Continue assigning css's to this cgroup on failure so that
+* all css's will be killed by cgroup_destroy_locked(). */
+ ret = online_css(css);
+ if (ret) {
+ err = ret;
+ continue;
+ }
if (ss->broken_hierarchy && !ss->warned_broken_hierarchy &&
parent->parent) {
@@ -4455,6 +4458,9 @@ static long cgroup_create(struct cgroup *parent, struct
dentry *dentry,
}
}
+ if (err)
+ goto err_destroy;
+
idr_replace(>cgroup_idr, cgrp, cgrp->id);
err = cgroup_addrm_files(cgrp, cgroup_base_files, true);
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf tools: fix bug in usage of the basename() function
* Stephane Eranian wrote:
>
> The basename() implementation varies a lot between systems.
> The Linux man page says: "basename may modify the content of the path,
> so it may be desirable to pass a copy when calling the function".
> On some other systems, the returned address may come from an internal
> buffer which can be reused in subsequent calls, thus the results should
> also be copied.
>
> The dso__set_basename() function was not doing this causing problems
> on some systems with wrong library names being shown by perf report,
> such as on Android systems.
>
> This patch fixes the problem.
> Thanks to Ben Cheng for tracking down the problem.
>
> Patch relative to tip.git at commit 631d5ea.
>
> Reported-by: Ben Cheng
> Signed-off-by: Stephane Eranian
> ---
Just three nits:
> tools/perf/util/dso.c | 29 -
> 1 file changed, 28 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
> index af4c687c..d186ace 100644
> --- a/tools/perf/util/dso.c
> +++ b/tools/perf/util/dso.c
> @@ -404,7 +404,34 @@ void dso__set_short_name(struct dso *dso, const char
> *name)
>
> static void dso__set_basename(struct dso *dso)
> {
> - dso__set_short_name(dso, basename(dso->long_name));
> + char *lname, *base;
> +
> + /*
> + * basename may modify path buffer, so we must pass
> + * a copy.
s/basename may modify path buffer
/basename() may modify the path buffer
> + */
> + lname = strdup(dso->long_name);
> + if (!lname)
> + return;
> +
> + /*
> + * basename may return pointer to internal
> + * storage which is reused in subsequent calls
> + * so copy the result
> + */
s/basename may return pointer
/basename() may return a pointer
Makes for easier reading.
(Also please use consistent periods - the first comment has a period,
the second one doesn't. ':' works well too:)
> + base = strdup(basename(lname));
> +
> + free(lname);
> +
> + if (!base)
> + return;
> +
> + if (dso->sname_alloc)
> + free((char *)dso->short_name);
That cast is probably not needed.
> + else
> + dso->sname_alloc = 1;
> +
> + dso__set_short_name(dso, base);
> }
>
> int dso__name_len(const struct dso *dso)
Otherwise:
Acked-by: Ingo Molnar
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 1/5] Staging: bcm: DDRInit: Fixed coding style issue, replaced spaces w/ tabs.(patch set)
These five patches all do the same thing. It's ok to merge them into one patch. The subject lines are all the same and that's not ok. The subject lines are too long as well. On Wed, Dec 04, 2013 at 07:26:19PM -0500, Gary Rookard wrote: > This is the first patch of a series. Don't put this in the description. > Replaced spaces in margin w/ 1 tab for lines: > 11-15, 17-23, 25-58, 60, 62, 64 > No signed off by line. > On branch staging-next Put this between the --- and the diffstat. > --- <-- here. > drivers/staging/bcm/DDRInit.c | 98 > +-- > 1 file changed, 49 insertions(+), 49 deletions(-) regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/5] perf tools: Update the Document for perf kvm record for new behavior.
On 12/04/2013 09:27 AM, Arnaldo Carvalho de Melo wrote: Em Wed, Dec 04, 2013 at 05:56:41PM -0500, Dongsheng Yang escreveu: As we have changed the default behavior of perf kvm to --guest enabled, the document about perf kvm record is outdated. This patch update it to show the correct output with --host/--guest/neither/both of them. +++ b/tools/perf/Documentation/perf-kvm.txt @@ -24,10 +24,17 @@ There are a couple of variants of perf kvm: of an arbitrary workload. 'perf kvm record ' to record the performance counter profile - of an arbitrary workload and save it into a perf data file. If both - --host and --guest are input, the perf data file name is perf.data.kvm. - If there is no --host but --guest, the file name is perf.data.guest. - If there is no --guest but --host, the file name is perf.data.host. + of an arbitrary workload and save it into a perf data file. We set the + default behavior of perf kvm as --guest, so if neither --host nor --guest + is input, the perf data file name is perf.data.guest. If --host is input, + the perf data file name is perf.data.kvm. If you want to record data into + perf.data.host, please input --host --no-guest. The behaviors are shown as + following: Perhaps this is clearer: "Use 'perf kvm record ' to record the a profile of an arbitrary workload and save it into a perf.data file. The default is to record guest samples, use --host to ask for just host samples or both --guest and --host for both kinds of samples to be taken." Argh, then I wonder why do we have --guest if the only possibility, according to the text above, is for it to be used in the --no-guest variant, is that the case? Do we really, really need to have those .host or .guest or .kvm filename suffixes? Can't we have this somehow encoded in the perf.data file header and show it when doing a report? humm, it is already, and we can see it already in 'perf evlist': [root@ssdandy ~]# perf kvm record -a ^C[ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 1.489 MB perf.data.guest (~65058 samples) ] [root@ssdandy ~]# perf evlist raw_syscalls:sys_enter raw_syscalls:sys_exit [root@ssdandy ~]# perf evlist -v raw_syscalls:sys_enter: sample_freq=1, type: 2, config: 41, size: 96, sample_type: IP|TID|TIME|CALLCHAIN|ID|CPU|PERIOD|RAW, read_format: ID, disabled: 1, inherit: 1, mmap: 1, comm: 1, enable_on_exec: 1, sample_id_all: 1, exclude_guest: 1 raw_syscalls:sys_exit: sample_freq=1, type: 2, config: 40, size: 96, sample_type: IP|TID|TIME|CALLCHAIN|ID|CPU|PERIOD|RAW, read_format: ID, disabled: 1, inherit: 1, enable_on_exec: 1, sample_id_all: 1, exclude_guest: 1 [root@ssdandy ~]# Humm, strange, the exclude_guest bit is set, which doesn't look like it matches that text... Lemme try explicitely using --guest and --host: [root@ssdandy ~]# perf kvm --guest record sleep 2 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.012 MB perf.data.guest (~532 samples) ] [root@ssdandy ~]# perf evlist -v raw_syscalls:sys_enter: sample_freq=1, type: 2, config: 41, size: 96, sample_type: IP|TID|TIME|CALLCHAIN|ID|CPU|PERIOD|RAW, read_format: ID, disabled: 1, inherit: 1, mmap: 1, comm: 1, enable_on_exec: 1, sample_id_all: 1, exclude_guest: 1 raw_syscalls:sys_exit: sample_freq=1, type: 2, config: 40, size: 96, sample_type: IP|TID|TIME|CALLCHAIN|ID|CPU|PERIOD|RAW, read_format: ID, disabled: 1, inherit: 1, enable_on_exec: 1, sample_id_all: 1, exclude_guest: 1 [root@ssdandy ~]# exclude_guest still there... Then: [root@ssdandy ~]# perf kvm --host record sleep 2 [ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 0.012 MB perf.data.kvm (~544 samples) ] [root@ssdandy ~]# perf evlist -v raw_syscalls:sys_enter: sample_freq=1, type: 2, config: 41, size: 96, sample_type: IP|TID|TIME|CALLCHAIN|ID|CPU|PERIOD|RAW, read_format: ID, disabled: 1, inherit: 1, mmap: 1, comm: 1, enable_on_exec: 1, sample_id_all: 1, exclude_guest: 1 raw_syscalls:sys_exit: sample_freq=1, type: 2, config: 40, size: 96, sample_type: IP|TID|TIME|CALLCHAIN|ID|CPU|PERIOD|RAW, read_format: ID, disabled: 1, inherit: 1, enable_on_exec: 1, sample_id_all: 1, exclude_guest: 1 [root@ssdandy ~]# Still there... oops, I've been just bitten by this odd suffixes convention, as 'perf evlist', like all other tools, by default will look at 'perf.data', not the 'perf kvm' convention... ... So again: [root@ssdandy ~]# perf kvm --guest record -a ^C[ perf record: Woken up 1 times to write data ] [ perf record: Captured and wrote 1.060 MB perf.data.guest (~46303 samples) ] [root@ssdandy ~]# ls -lart perf.data* | tail -1 -rw---. 1 root root 1113684 Dec 4 11:11 perf.data.guest [root@ssdandy ~]# perf evlist -v -i perf.data.guest cycles: sample_freq=4000, size: 96, sample_type: IP|TID|TIME|CPU|PERIOD, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, sample_id_all: 1, exclude_host: 1 [root@ssdandy ~]# Matches the documentation, i.e.
Re: [RFC][PATCH 3/4] ima: display template format in meas. list if template name length is zero
On 12/04/2013 10:08 PM, Mimi Zohar wrote:
On Thu, 2013-11-07 at 15:00 +0100, Roberto Sassu wrote:
With the introduction of the 'ima_template_fmt' kernel cmdline parameter,
an user can define a new template descriptor with custom format. However,
in this case, userspace tools will be unable to parse the measurements
list because the new template is unknown. For this reason, this patch
modifies the current IMA behavior to display in the list the template
format instead of the name so that a tool can extract needed information
if it can handle listed fields.
Signed-off-by: Roberto Sassu
---
security/integrity/ima/ima_fs.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/security/integrity/ima/ima_fs.c b/security/integrity/ima/ima_fs.c
index d47a7c8..6db74ff 100644
--- a/security/integrity/ima/ima_fs.c
+++ b/security/integrity/ima/ima_fs.c
@@ -118,6 +118,7 @@ static int ima_measurements_show(struct seq_file *m, void
*v)
/* the list never shrinks, so we don't need a lock here */
struct ima_queue_entry *qe = v;
struct ima_template_entry *e;
+ char *template_name;
int namelen;
u32 pcr = CONFIG_IMA_MEASURE_PCR_IDX;
int i;
@@ -127,6 +128,10 @@ static int ima_measurements_show(struct seq_file *m, void
*v)
if (e == NULL)
return -1;
+ template_name = e->template_desc->name;
+ if (strlen(e->template_desc->name) == 0)
+ template_name = e->template_desc->fmt;
+
Hi Roberto,
The patch description unconditionally says, "this patch modifies the
current IMA behavior to display in the list the template format instead
of the name". The code only uses the 'fmt', if the name doesn't exist.
Please update the patch description accordingly.
Nothing is wrong with the above syntax, but template_name could be
assigned once using a ternary conditional expression(?:), like:
template_name = (strlen(e->template_desc->name) == 0) ?
e->template_desc->name : e->template_desc->fmt;
Ok, I will make the changes.
Thanks
Roberto Sassu
thanks,
Mimi
/*
* 1st: PCRIndex
* PCR used is always the same (config option) in
@@ -138,14 +143,14 @@ static int ima_measurements_show(struct seq_file *m, void
*v)
ima_putc(m, e->digest, TPM_DIGEST_SIZE);
/* 3rd: template name size */
- namelen = strlen(e->template_desc->name);
+ namelen = strlen(template_name);
ima_putc(m, , sizeof namelen);
/* 4th: template name */
- ima_putc(m, e->template_desc->name, namelen);
+ ima_putc(m, template_name, namelen);
/* 5th: template length (except for 'ima' template) */
- if (strcmp(e->template_desc->name, IMA_TEMPLATE_IMA_NAME) != 0)
+ if (strcmp(template_name, IMA_TEMPLATE_IMA_NAME) != 0)
ima_putc(m, >template_data_len,
sizeof(e->template_data_len));
@@ -190,6 +195,7 @@ static int ima_ascii_measurements_show(struct seq_file *m,
void *v)
/* the list never shrinks, so we don't need a lock here */
struct ima_queue_entry *qe = v;
struct ima_template_entry *e;
+ char *template_name;
int i;
/* get entry */
@@ -197,6 +203,10 @@ static int ima_ascii_measurements_show(struct seq_file *m,
void *v)
if (e == NULL)
return -1;
+ template_name = e->template_desc->name;
+ if (strlen(e->template_desc->name) == 0)
+ template_name = e->template_desc->fmt;
+
/* 1st: PCR used (config option) */
seq_printf(m, "%2d ", CONFIG_IMA_MEASURE_PCR_IDX);
@@ -204,7 +214,7 @@ static int ima_ascii_measurements_show(struct seq_file *m,
void *v)
ima_print_digest(m, e->digest, TPM_DIGEST_SIZE);
/* 3th: template name */
- seq_printf(m, " %s", e->template_desc->name);
+ seq_printf(m, " %s", template_name);
/* 4th: template specific data */
for (i = 0; i < e->template_desc->num_fields; i++) {
--
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/apic: Justification for disabling IO APIC before Local APIC
* Fenghua Yu wrote:
> From: Fenghua Yu
>
> Since erratum AVR31 in "Intel Atom Processor C2000 Product Family
> Specification Update" is published, I add a justification comment for
> disabling IO APIC before Local APIC (commit 522e6646).
>
> Signed-off-by: Fenghua Yu
> ---
> arch/x86/kernel/reboot.c | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
> index da3c599..c752cb4 100644
> --- a/arch/x86/kernel/reboot.c
> +++ b/arch/x86/kernel/reboot.c
> @@ -558,6 +558,17 @@ void native_machine_shutdown(void)
> {
> /* Stop the cpus and apics */
> #ifdef CONFIG_X86_IO_APIC
> + /*
> + * Disabling IO APIC before local APIC is a workaround for
> + * erratum AVR31 in "Intel Atom Processor C2000 Product Family
> + * Specification Update". In this situation, interrupts that target
> + * a Logical Processor whose Local APIC is either in the process of
> + * being hardware disabled or software disabled are neither delivered
> + * nor discarded. When this erratum occurs, the processor may hang.
> + *
> + * Even without the erratum, it still makes sense to quiet IO APIC
> + * before disabling Local APIC.
> + */
> disable_IO_APIC();
> #endif
Looks good to me, except that patch titles should start with verbs,
i.e. something like:
x86/apic/doc: Add justification for disabling IO APIC before Local APIC
Which makes for a much more fluid reading of shortlogs etc.
Unless you sentences without verbs.
^---like
;-)
Thanks,
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] mm: do_mincore() cleanup
Two cleanups:
1. remove redundant codes for hugetlb pages.
2. end = pmd_addr_end(addr, end) restricts [addr, end) within PMD_SIZE,
this may increase do_mincore() calls, remove it.
Signed-off-by: Jianguo Wu
---
mm/mincore.c |7 ---
1 files changed, 0 insertions(+), 7 deletions(-)
diff --git a/mm/mincore.c b/mm/mincore.c
index da2be56..1016233 100644
--- a/mm/mincore.c
+++ b/mm/mincore.c
@@ -225,13 +225,6 @@ static long do_mincore(unsigned long addr, unsigned long
pages, unsigned char *v
end = min(vma->vm_end, addr + (pages << PAGE_SHIFT));
- if (is_vm_hugetlb_page(vma)) {
- mincore_hugetlb_page_range(vma, addr, end, vec);
- return (end - addr) >> PAGE_SHIFT;
- }
-
- end = pmd_addr_end(addr, end);
-
if (is_vm_hugetlb_page(vma))
mincore_hugetlb_page_range(vma, addr, end, vec);
else
--
1.7.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] crash_dump: fix compilation error (on MIPS at least)
> -Original Message- > From: Vivek Goyal [mailto:vgo...@redhat.com] > Sent: 04 December 2013 21:30 > To: Qais Yousef > Cc: linux-kernel@vger.kernel.org; Andrew Morton; Michael Holzheu; linux- > m...@linux-mips.org; sta...@vger.kernel.org > Subject: Re: [PATCH] crash_dump: fix compilation error (on MIPS at least) > > On Wed, Dec 04, 2013 at 03:58:22PM +, Qais Yousef wrote: > > In file included from kernel/crash_dump.c:2:0: > > include/linux/crash_dump.h:22:27: error: unknown type name ‘pgprot_t’ > > > > when CONFIG_CRASH_DUMP=y > > > > The error was traced back to this commit: > > > > 9cb218131de1 vmcore: introduce remap_oldmem_pfn_range() > > > > include to get the missing definition > > pgprot_t definition for mips seems to be in asm/page.h. So why are you > including > asm/pgtable.h and not asm/page.h? For other architectures it seems to be in > other files. That means those arch will have broken compilation now. I didn't include asm/page.h because I didn't think it'll fix the problem for other arches. > > So question is, is there any arch specific file which one can include and be > covered > for pgprot_t definition for all the arches. I asked the same question and asm/pgtable.h was the answer. Thanks, Qais > > Thanks > Vivek > > > > > Cc: Andrew Morton > > Cc: Michael Holzheu > > Cc: Vivek Goyal > > Cc: > > Cc: # 3.12 > > Reviewed-by: James Hogan > > Signed-off-by: Qais Yousef > > --- > > I haven't tried any other architecture except mips. > > If OK this should be considered for stable 3.12 (CCed). > > > > include/linux/crash_dump.h |2 ++ > > 1 files changed, 2 insertions(+), 0 deletions(-) > > > > diff --git a/include/linux/crash_dump.h b/include/linux/crash_dump.h > > index fe68a5a..7032518 100644 > > --- a/include/linux/crash_dump.h > > +++ b/include/linux/crash_dump.h > > @@ -6,6 +6,8 @@ > > #include > > #include > > > > +#include /* for pgprot_t */ > > + > > #define ELFCORE_ADDR_MAX (-1ULL) > > #define ELFCORE_ADDR_ERR (-2ULL) > > > > -- > > 1.7.1 > >
Re: [RFC][PATCH 4/4] ima: added support for new kernel cmdline parameter ima_template_fmt
On 12/04/2013 10:05 PM, Mimi Zohar wrote:
On Thu, 2013-11-07 at 15:00 +0100, Roberto Sassu wrote:
This patch allows users to provide a custom template format through the
new kernel command line parameter 'ima_template_fmt'. If the supplied
format is not valid, IMA uses the default template descriptor.
Signed-off-by: Roberto Sassu
---
Documentation/kernel-parameters.txt | 4 +++
Documentation/security/IMA-templates.txt | 29 +-
security/integrity/ima/ima_template.c| 50
3 files changed, 68 insertions(+), 15 deletions(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 1e8761c..27b14b2 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1199,6 +1199,10 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
Formats: { "ima" | "ima-ng" }
Default: "ima-ng"
+ ima_template_fmt=
+ [IMA] Define a custom template format.
+ Format: { "field1|...|fieldN" }
+
init= [KNL]
Format:
Run specified binary instead of /sbin/init as init
diff --git a/Documentation/security/IMA-templates.txt
b/Documentation/security/IMA-templates.txt
index a777e5f..08ea2da 100644
--- a/Documentation/security/IMA-templates.txt
+++ b/Documentation/security/IMA-templates.txt
@@ -27,25 +27,22 @@ Managing templates with these structures is very simple. To
support
a new data type, developers define the field identifier and implement
two functions, init() and show(), respectively to generate and display
measurement entries. Defining a new template descriptor requires
-specifying the template format, a string of field identifiers separated
-by the '|' character. While in the current implementation it is possible
-to define new template descriptors only by adding their definition in the
-template specific code (ima_template.c), in a future version it will be
-possible to register a new template on a running kernel by supplying to IMA
-the desired format string. In this version, IMA initializes at boot time
-all defined template descriptors by translating the format into an array
-of template fields structures taken from the set of the supported ones.
+specifying the template format (a string of field identifiers separated
+by the '|' character) through the 'ima_template_fmt' kernel command line
+parameter. At boot time, IMA initializes all defined template descriptors
+by translating the format into an array of template fields structures taken
+from the set of the supported ones.
After the initialization step, IMA will call ima_alloc_init_template()
(new function defined within the patches for the new template management
mechanism) to generate a new measurement entry by using the template
descriptor chosen through the kernel configuration or through the newly
-introduced 'ima_template=' kernel command line parameter. It is during this
-phase that the advantages of the new architecture are clearly shown:
-the latter function will not contain specific code to handle a given template
-but, instead, it simply calls the init() method of the template fields
-associated to the chosen template descriptor and store the result (pointer
-to allocated data and data length) in the measurement entry structure.
+introduced 'ima_template' and 'ima_template_fmt' kernel command line
parameters.
+It is during this phase that the advantages of the new architecture are
+clearly shown: the latter function will not contain specific code to handle
+a given template but, instead, it simply calls the init() method of the
template
+fields associated to the chosen template descriptor and store the result
+(pointer to allocated data and data length) in the measurement entry structure.
The same mechanism is employed to display measurements entries.
The functions ima[_ascii]_measurements_show() retrieve, for each entry,
@@ -84,4 +81,6 @@ currently the following methods are supported:
- select a template descriptor among those supported in the kernel
configuration ('ima-ng' is the default choice);
- specify a template descriptor name from the kernel command line through
- the 'ima_template=' parameter.
+ the 'ima_template=' parameter;
+ - register a new template descriptor with custom format through the kernel
+ command line parameter 'ima_template_fmt='.
diff --git a/security/integrity/ima/ima_template.c
b/security/integrity/ima/ima_template.c
index bb33576..5a95d06 100644
--- a/security/integrity/ima/ima_template.c
+++ b/security/integrity/ima/ima_template.c
@@ -21,6 +21,7 @@ static struct ima_template_desc defined_templates[] = {
{.name = IMA_TEMPLATE_IMA_NAME, .fmt = IMA_TEMPLATE_IMA_FMT},
{.name = "ima-ng",.fmt = "d-ng|n-ng"},
{.name = "ima-sig",.fmt = "d-ng|n-ng|sig"},
+
Re: [PATCH v1 4/9] staging: android: binder: Add align_helper() macro
On Wed, Dec 04, 2013 at 06:09:36PM +, Serban Constantinescu wrote: > This patch adds align_helper() macro that will be used for enforcing > the desired alignment on 64bit systems where the alignment will differ > depending on the userspace used (32bit /64bit). > > This patch is a temporary patch that will be extended with 32bit compat > handling. > > Signed-off-by: Serban Constantinescu > --- > drivers/staging/android/binder.c |9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/drivers/staging/android/binder.c > b/drivers/staging/android/binder.c > index 16109cd..6719a53 100644 > --- a/drivers/staging/android/binder.c > +++ b/drivers/staging/android/binder.c > @@ -140,6 +140,8 @@ module_param_call(stop_on_user_error, > binder_set_stop_on_user_error, > binder_stop_on_user_error = 2; \ > } while (0) > > +#define align_helper(ptr)ALIGN(ptr, sizeof(void *)) > + This is a terrible name. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/2] fs: buffer: move allocation failure loop into the allocator
On Wed, Dec 04, 2013 at 04:33:43PM +, Christoph Lameter wrote: > On Thu, 5 Dec 2013, Joonsoo Kim wrote: > > > Now we have cpu partial slabs facility, so I think that slowpath isn't > > really > > slow. And it doesn't much increase the management overhead in the node > > partial lists, because of cpu partial slabs. > > Well yes that may address some of the issues here. > > > And larger frame may cause more slab_lock contention or cmpxchg contention > > if there are parallel freeings. > > > > But, I don't know which one is better. Is larger frame still better? :) > > Could you run some tests to figure this one out? There are also > some situations in which we disable the per cpu partial pages though. > F.e. for low latency/realtime. I posted in kernel synthetic > benchmarks for slab a while back. That maybe something to start with. I could try. But my trial would not figure this out, since my machine has just 4 cores which normally cannot produce heavy contention. Anyway, could you tell me where I can find your synthetic benchmarks for slab? Thanks. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv2] net: wireless: wcn36xx: fix potential NULL pointer dereference
> + if (msg_ind)
> + break;
> + /* FIXME: Do something smarter then just printing an error. */
> + wcn36xx_err("Run out of memory while handling SMD_EVENT
> (%d)\n",
I think code will look neater if error case will be handled in "else"
statement something like:
if (msg_ind) {
...
} else {
/*print message*/
}
/*unlock and break;*/
How about that?
On Mon, Dec 2, 2013 at 1:09 PM, Michal Nazarewicz wrote:
>
> If kmalloc fails wcn36xx_smd_rsp_process will attempt to dereference
> a NULL pointer. There might be a better error recovery then just
> printing an error, but printing an error message is better then the
> current behaviour.
>
> Signed-off-by: Michal Nazarewicz
> ---
> drivers/net/wireless/ath/wcn36xx/smd.c | 19 +--
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> On Sun, Dec 01 2013, Peter Stuge wrote:
>> Michal Nazarewicz wrote:
>>> +wcn36xx_err("Run out of memory while hnadling
>>> SMD_EVENT (%d)\n",
>>> +msg_header->msg_type);
>>
>> Typo hnadling.
>
> Fixed.
>
> diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c
> b/drivers/net/wireless/ath/wcn36xx/smd.c
> index de9eb2c..3663394 100644
> --- a/drivers/net/wireless/ath/wcn36xx/smd.c
> +++ b/drivers/net/wireless/ath/wcn36xx/smd.c
> @@ -2041,13 +2041,20 @@ static void wcn36xx_smd_rsp_process(struct wcn36xx
> *wcn, void *buf, size_t len)
> case WCN36XX_HAL_DELETE_STA_CONTEXT_IND:
> mutex_lock(>hal_ind_mutex);
> msg_ind = kmalloc(sizeof(*msg_ind), GFP_KERNEL);
> - msg_ind->msg_len = len;
> - msg_ind->msg = kmalloc(len, GFP_KERNEL);
> - memcpy(msg_ind->msg, buf, len);
> - list_add_tail(_ind->list, >hal_ind_queue);
> - queue_work(wcn->hal_ind_wq, >hal_ind_work);
> - wcn36xx_dbg(WCN36XX_DBG_HAL, "indication arrived\n");
> + if (msg_ind) {
> + msg_ind->msg_len = len;
> + msg_ind->msg = kmalloc(len, GFP_KERNEL);
> + memcpy(msg_ind->msg, buf, len);
> + list_add_tail(_ind->list, >hal_ind_queue);
> + queue_work(wcn->hal_ind_wq, >hal_ind_work);
> + wcn36xx_dbg(WCN36XX_DBG_HAL, "indication arrived\n");
> + }
> mutex_unlock(>hal_ind_mutex);
> + if (msg_ind)
> + break;
> + /* FIXME: Do something smarter then just printing an error. */
> + wcn36xx_err("Run out of memory while handling SMD_EVENT
> (%d)\n",
> + msg_header->msg_type);
> break;
> default:
> wcn36xx_err("SMD_EVENT (%d) not supported\n",
> --
> 1.8.4.1
>
> --
> Best regards, _ _
> .o. | Liege of Serenely Enlightened Majesty of o' \,=./ `o
> ..o | Computer Science, Michał “mina86” Nazarewicz(o o)
> ooo +--ooO--(_)--Ooo--
--
Best regards,
Eugene
--
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 v1 3/9] staging: android: binder: Add cmd == CMD_NAME handling
On Wed, Dec 04, 2013 at 06:09:35PM +, Serban Constantinescu wrote: > This patch modifies the functions that need to be passed the explicit > command to use a boolean flag. This way we can reuse the code for 64bit > compat commands. > I don't understand this at all. cmd seems like it should be 32 bits on both arches. regards, dan carpenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 2/9] staging: android: binder: Add binder_copy_to_user()
On Wed, Dec 04, 2013 at 06:09:34PM +, Serban Constantinescu wrote:
> This patch adds binder_copy_to_user() to be used for copying binder
> commands to user address space. This way we can abstract away the
> copy_to_user() calls and add separate handling for the compat layer.
>
> Signed-off-by: Serban Constantinescu
> ---
> drivers/staging/android/binder.c | 39
> --
> 1 file changed, 21 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/staging/android/binder.c
> b/drivers/staging/android/binder.c
> index 233889c..6fbb340 100644
> --- a/drivers/staging/android/binder.c
> +++ b/drivers/staging/android/binder.c
> @@ -2117,6 +2117,18 @@ static int binder_has_thread_work(struct binder_thread
> *thread)
> (thread->looper & BINDER_LOOPER_STATE_NEED_RETURN);
> }
>
> +static int binder_copy_to_user(uint32_t cmd, void *parcel,
> +void __user **ptr, size_t size)
> +{
Bike shedding: Put the **ptr as the first argument.
binder_copy_to_user(dest, cmd, src, size);
> + if (put_user(cmd, (uint32_t __user *)*ptr))
> + return -EFAULT;
> + *ptr += sizeof(uint32_t);
> + if (copy_to_user(*ptr, parcel, size))
> + return -EFAULT;
> + *ptr += size;
> + return 0;
> +}
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] MTD maintenance updates
On Wed, 2013-12-04 at 15:28 -0800, Brian Norris wrote: > BTW, I'd like to get David's "ack" for these patches, and it'd be nice > to hear > from Artem too, since he has previously been an unofficial maintainer > (and is > understandably distracted by non-MTD work these days). Acked-by: Artem Bityutskiy Thanks Brian for taking care of the MTD subsystem. -- Best Regards, Artem Bityutskiy -- 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] ARM: fix framepointer check in unwind_frame
This patch fixes corner case when (fp + 4) overflows unsigned long, for example: fp = 0x -> fp + 4 == 3. Signed-off-by: Konstantin Khlebnikov --- arch/arm/kernel/stacktrace.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c index 00f79e5..af4e8c8 100644 --- a/arch/arm/kernel/stacktrace.c +++ b/arch/arm/kernel/stacktrace.c @@ -31,7 +31,7 @@ int notrace unwind_frame(struct stackframe *frame) high = ALIGN(low, THREAD_SIZE); /* check current frame pointer is within bounds */ - if (fp < (low + 12) || fp + 4 >= high) + if (fp < low + 12 || fp > high - 4) return -EINVAL; /* restore the registers from the stack frame */ -- 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] ARM: check stack pointer in get_wchan
get_wchan() is lockless. Task may wakeup at any time and change its own stack,
thus each next stack frame may be overwritten and filled with random stuff.
/proc/$pid/stack interface had been disabled for non-current tasks, see [1]
But 'wchan' still allows to trigger stack frame unwinding on volatile stack.
This patch fixes oops in unwind_frame() by adding stack pointer validation on
each step (as x86 code do), unwind_frame() already checks frame pointer.
Also I've found another report of this oops on stackoverflow (irony).
Signed-off-by: Konstantin Khlebnikov
Link: http://www.spinics.net/lists/arm-kernel/msg110589.html [1]
Link:
http://stackoverflow.com/questions/18479894/unwind-frame-cause-a-kernel-paging-error
Acked-by: Will Deacon
---
arch/arm/kernel/process.c |7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/arm/kernel/process.c b/arch/arm/kernel/process.c
index 94f6b05..92f7b15 100644
--- a/arch/arm/kernel/process.c
+++ b/arch/arm/kernel/process.c
@@ -404,6 +404,7 @@ EXPORT_SYMBOL(dump_fpu);
unsigned long get_wchan(struct task_struct *p)
{
struct stackframe frame;
+ unsigned long stack_page;
int count = 0;
if (!p || p == current || p->state == TASK_RUNNING)
return 0;
@@ -412,9 +413,11 @@ unsigned long get_wchan(struct task_struct *p)
frame.sp = thread_saved_sp(p);
frame.lr = 0; /* recovered from the stack */
frame.pc = thread_saved_pc(p);
+ stack_page = (unsigned long)task_stack_page(p);
do {
- int ret = unwind_frame();
- if (ret < 0)
+ if (frame.sp < stack_page ||
+ frame.sp >= stack_page + THREAD_SIZE ||
+ unwind_frame() < 0)
return 0;
if (!in_sched_functions(frame.pc))
return frame.pc;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH?] uprobes: change uprobe_write_opcode() to modify the page directly
On Wed, 2013-12-04 at 09:15 -0800, Linus Torvalds wrote: > On Wed, Dec 4, 2013 at 8:54 AM, H. Peter Anvin wrote: > > > > That is why I talk about the atomic instruction word... most (but not > > *all*) architectures have a fundamental minimum unit of instructions > > which is aligned and can be atomically written. Typically this is 1, 2, > > or 4 bytes. > > Note that it's not just about the "atomically written", it's also > about the guarantee that it's atomically *read*. > > x86 can certainly atomically write a 4-byte instruction too, it's just > that there's no guarantee - even if the instruction is aligned etc - > that the actual instruction decoding always ends up reading it that > way. It might re-read an instruction after encountering a prefix byte > etc etc. So even if it's all properly aligned, the reading side might > do something odd. The ARM architecture has similar issues. Even though the instruction size is mostly fixed, the architecture specification itself only guarantees a very tiny subset of instructions are safe to modify whilst there may be concurrent execution of that instruction. I'm quoting a discussion from a while ago: http://lkml.org/lkml/2012/12/10/346 -- 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] crypto: remove unnecessary includes
On Thu, Dec 05, 2013 at 08:14:55AM +, Cristian Stoica wrote: > Hi Herbert, > > Your original response was terse and left me more puzzled. Do you have a > sensible explanation why some includes should be kept in the source even they > serve no purpose during the build? If you can't work out why authenc.c needs slab.h I don't think you should be submitting patches removing unnecessary header files. Cheers, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 1/9] staging: android: binder: Move some of the logic into subfunction
On Wed, Dec 04, 2013 at 06:09:33PM +, Serban Constantinescu wrote:
> +static void bc_increfs_done(struct binder_proc *proc,
> + struct binder_thread *thread, uint32_t cmd,
> + void __user *node_ptr, void __user *cookie)
> +{
> + struct binder_node *node;
> +
> + node = binder_get_node(proc, node_ptr);
> + if (node == NULL) {
> + binder_user_error("%d:%d %s u%p no match\n",
> + proc->pid, thread->pid,
> + cmd == BC_INCREFS_DONE ?
> + "BC_INCREFS_DONE" :
> + "BC_ACQUIRE_DONE",
> + node_ptr);
> + return;
> + }
> + if (cookie != node->cookie) {
> + binder_user_error("%d:%d %s u%p node %d cookie mismatch %p !=
> %p\n",
> + proc->pid, thread->pid,
> + cmd == BC_INCREFS_DONE ?
> + "BC_INCREFS_DONE" : "BC_ACQUIRE_DONE",
> + node_ptr, node->debug_id,
> + cookie, node->cookie);
> + return;
> + }
> + if (cmd == BC_ACQUIRE_DONE) {
> + if (node->pending_strong_ref == 0) {
> + binder_user_error("%d:%d BC_ACQUIRE_DONE node %d has no
> pending acquire request\n",
> + proc->pid, thread->pid,
> + node->debug_id);
> + return;
> + }
> + node->pending_strong_ref = 0;
> + } else {
> + if (node->pending_weak_ref == 0) {
> + binder_user_error("%d:%d BC_INCREFS_DONE node %d has no
> pending increfs request\n",
> + proc->pid, thread->pid,
> + node->debug_id);
> + return;
> + }
> + node->pending_weak_ref = 0;
> + }
> + binder_dec_node(node, cmd == BC_ACQUIRE_DONE, 0);
> + binder_debug(BINDER_DEBUG_USER_REFS,
> + "%d:%d %s node %d ls %d lw %d\n",
> + proc->pid, thread->pid,
> + cmd == BC_INCREFS_DONE ?
> + "BC_INCREFS_DONE" :
> + "BC_ACQUIRE_DONE",
> + node->debug_id, node->local_strong_refs,
> + node->local_weak_refs);
> + return;
> +}
This function is 52 lines long but at least 32 of those lines are
debug code.
Just extra of lines of code means you have increased the number of bugs
150%. But what I know is that from a static analysis perspective, debug
code has more defects per line then regular code it's worse than that.
Plus all the extra noise obscures the actual logic and makes the real
code annoying to look at so it's worse still.
If you want to move this stuff out of staging, then remove all the extra
crap so it doesn't look like barf.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/4] dt: exynos5250: Enable support for generic USB 3.0 phy
Hi,
On Wed, Dec 4, 2013 at 6:20 PM, Bartlomiej Zolnierkiewicz
wrote:
>
> Hi,
>
> Does the old phy-samsung-usb3 driver currently work on Exynos5250? If yes,
> then this patch should be merged with patch #1 to preserve bisectability.
Yes, the old phy-samsung-usb3 driver works well on Exynos5250 currently.
Ok, will merge it with patch #1
[PATCH v2 1/4] phy: Add new Exynos5 USB 3.0 PHY driver
Thanks for pointing out.
>
> Best regards,
> --
> Bartlomiej Zolnierkiewicz
> Samsung R Institute Poland
> Samsung Electronics
>
> On Wednesday, December 04, 2013 03:39:05 PM Vivek Gautam wrote:
>> Update device tree bindings for DWC3 controller and
>> USB 3.0 phy present on Exynos 5250 SoC, to start using
>> the phy driver based on generic phy framework.
>>
>> Signed-off-by: Vivek Gautam
>> ---
>> arch/arm/boot/dts/exynos5250.dtsi | 16 ++--
>> 1 files changed, 6 insertions(+), 10 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/exynos5250.dtsi
>> b/arch/arm/boot/dts/exynos5250.dtsi
>> index 9db5047..7444717 100644
>> --- a/arch/arm/boot/dts/exynos5250.dtsi
>> +++ b/arch/arm/boot/dts/exynos5250.dtsi
>> @@ -475,22 +475,18 @@
>> compatible = "synopsys,dwc3";
>> reg = <0x1200 0x1>;
>> interrupts = <0 72 0>;
>> - usb-phy = <_phy _phy>;
>> + phys = <_phy>;
>> + phy-names = "usb3-phy";
>> };
>> };
>>
>> usb3_phy: usbphy@1210 {
>> compatible = "samsung,exynos5250-usb3phy";
>> reg = <0x1210 0x100>;
>> - clocks = < 1>, < 286>;
>> - clock-names = "ext_xtal", "usbdrd30";
>> - #address-cells = <1>;
>> - #size-cells = <1>;
>> - ranges;
>> -
>> - usbphy-sys {
>> - reg = <0x10040704 0x8>;
>> - };
>> + clocks = < 286>, < 1>;
>> + clock-names = "phy", "usb3phy_refclk";
>> + samsung,syscon-phandle = <_syscon>;
>> + #phy-cells = <0>;
>> };
>>
>> usb@1211 {
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Best Regards
Vivek Gautam
Samsung R Institute, Bangalore
India
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH] crypto: remove unnecessary includes
Hi Herbert, Your original response was terse and left me more puzzled. Do you have a sensible explanation why some includes should be kept in the source even they serve no purpose during the build? Thanks, Cristian S. > > Just because it compiles it doesn't meant that the files you > > removed are unnecessary. > > > > The only file that is really unnecessary here is spinlock.h. > > > [] > OK then, but let's reverse the question. In a construct similar to > authenc.c, what would be the purpose of slab.h and kernel.h? > (That leads to the next question which is - what is the purpose of those > files in authenc.c?) -- 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/
