Re: crypto/xor.ko fails to build with CONFIG_KERNEL_MODE_NEON=y
On 7 sep. 2013, at 04:44, Josh Boyer wrote: > We enabled CONFIG_KERNEL_MODE_NEON on the armv7hl builds we're doing. > It builds for a while, but eventually fails when running modpost on > the xor.ko module: > > ERROR: "xor_block_neon_inner" [crypto/xor.ko] undefined! > make[1]: *** [__modpost] Error 1 > make: *** [modules] Error 2 > Clearly a bug, thanks for spotting this. I will submit a fix asap. In the mean time, building the xor code into the zImage will help you complete the build. > I tried adding an EXPORT_SYMBOL_GPL(xor_block_neon_inner); after the > structure definition in arch/arm/lib/xor-neon.c but that doesn't seem > to have done anything. > I would expected that to have done the trick, but perhaps it is better to merge the neon code into the main arm/xor source file. > Before I go chasing this further, I'm curious if anyone else has run into > this. > Cheers, Ard. > josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] m68k: remove deprecated IRQF_DISABLED
This patch proposes to remove the IRQF_DISABLED flag from m68k architecture
code. It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/m68k/include/asm/floppy.h | 2 +-
arch/m68k/include/asm/sun3xflop.h | 2 +-
arch/m68k/platform/68000/timers.c | 2 +-
arch/m68k/platform/68360/config.c | 2 +-
arch/m68k/platform/coldfire/pit.c | 2 +-
arch/m68k/platform/coldfire/sltimers.c | 4 ++--
arch/m68k/platform/coldfire/timers.c | 4 ++--
7 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/m68k/include/asm/floppy.h b/arch/m68k/include/asm/floppy.h
index 697d503..47365b1 100644
--- a/arch/m68k/include/asm/floppy.h
+++ b/arch/m68k/include/asm/floppy.h
@@ -85,7 +85,7 @@ static int fd_request_irq(void)
{
if(MACH_IS_Q40)
return request_irq(FLOPPY_IRQ, floppy_hardint,
- IRQF_DISABLED, "floppy", floppy_hardint);
+ 0, "floppy", floppy_hardint);
else if(MACH_IS_SUN3X)
return sun3xflop_request_irq();
return -ENXIO;
diff --git a/arch/m68k/include/asm/sun3xflop.h
b/arch/m68k/include/asm/sun3xflop.h
index 95231e2..a02ea3a 100644
--- a/arch/m68k/include/asm/sun3xflop.h
+++ b/arch/m68k/include/asm/sun3xflop.h
@@ -207,7 +207,7 @@ static int sun3xflop_request_irq(void)
if(!once) {
once = 1;
error = request_irq(FLOPPY_IRQ, sun3xflop_hardint,
- IRQF_DISABLED, "floppy", NULL);
+ 0, "floppy", NULL);
return ((error == 0) ? 0 : -1);
} else return 0;
}
diff --git a/arch/m68k/platform/68000/timers.c
b/arch/m68k/platform/68000/timers.c
index ec30acb..99a9869 100644
--- a/arch/m68k/platform/68000/timers.c
+++ b/arch/m68k/platform/68000/timers.c
@@ -70,7 +70,7 @@ static irqreturn_t hw_tick(int irq, void *dummy)
static struct irqaction m68328_timer_irq = {
.name= "timer",
- .flags = IRQF_DISABLED | IRQF_TIMER,
+ .flags = IRQF_TIMER,
.handler = hw_tick,
};
diff --git a/arch/m68k/platform/68360/config.c
b/arch/m68k/platform/68360/config.c
index 9877cef..fae263e 100644
--- a/arch/m68k/platform/68360/config.c
+++ b/arch/m68k/platform/68360/config.c
@@ -58,7 +58,7 @@ static irqreturn_t hw_tick(int irq, void *dummy)
static struct irqaction m68360_timer_irq = {
.name= "timer",
- .flags = IRQF_DISABLED | IRQF_TIMER,
+ .flags = IRQF_TIMER,
.handler = hw_tick,
};
diff --git a/arch/m68k/platform/coldfire/pit.c
b/arch/m68k/platform/coldfire/pit.c
index e8f3b97..493b311 100644
--- a/arch/m68k/platform/coldfire/pit.c
+++ b/arch/m68k/platform/coldfire/pit.c
@@ -118,7 +118,7 @@ static irqreturn_t pit_tick(int irq, void *dummy)
static struct irqaction pit_irq = {
.name= "timer",
- .flags = IRQF_DISABLED | IRQF_TIMER,
+ .flags = IRQF_TIMER,
.handler = pit_tick,
};
diff --git a/arch/m68k/platform/coldfire/sltimers.c
b/arch/m68k/platform/coldfire/sltimers.c
index bb5a25a..831a08c 100644
--- a/arch/m68k/platform/coldfire/sltimers.c
+++ b/arch/m68k/platform/coldfire/sltimers.c
@@ -51,7 +51,7 @@ irqreturn_t mcfslt_profile_tick(int irq, void *dummy)
static struct irqaction mcfslt_profile_irq = {
.name= "profile timer",
- .flags = IRQF_DISABLED | IRQF_TIMER,
+ .flags = IRQF_TIMER,
.handler = mcfslt_profile_tick,
};
@@ -93,7 +93,7 @@ static irqreturn_t mcfslt_tick(int irq, void *dummy)
static struct irqaction mcfslt_timer_irq = {
.name= "timer",
- .flags = IRQF_DISABLED | IRQF_TIMER,
+ .flags = IRQF_TIMER,
.handler = mcfslt_tick,
};
diff --git a/arch/m68k/platform/coldfire/timers.c
b/arch/m68k/platform/coldfire/timers.c
index d06068e..cd496a2 100644
--- a/arch/m68k/platform/coldfire/timers.c
+++ b/arch/m68k/platform/coldfire/timers.c
@@ -83,7 +83,7 @@ static irqreturn_t mcftmr_tick(int irq, void *dummy)
static struct irqaction mcftmr_timer_irq = {
.name= "timer",
- .flags = IRQF_DISABLED | IRQF_TIMER,
+ .flags = IRQF_TIMER,
.handler = mcftmr_tick,
};
@@ -171,7 +171,7 @@ irqreturn_t coldfire_profile_tick(int irq, void *dummy)
static struct irqaction coldfire_profile_irq = {
.name= "profile timer",
- .flags = IRQF_DISABLED | IRQF_TIMER,
+ .flags = IRQF_TIMER,
.handler = coldfire_profile_tick,
};
--
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] frv: remove deprecated IRQF_DISABLED
This patch proposes to remove the IRQF_DISABLED flag from FRV architecture
code. It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
arch/frv/kernel/irq-mb93091.c | 8
arch/frv/kernel/irq-mb93093.c | 2 +-
arch/frv/kernel/irq-mb93493.c | 4 ++--
arch/frv/kernel/time.c| 2 +-
4 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/arch/frv/kernel/irq-mb93091.c b/arch/frv/kernel/irq-mb93091.c
index 2cc327a..091b283 100644
--- a/arch/frv/kernel/irq-mb93091.c
+++ b/arch/frv/kernel/irq-mb93091.c
@@ -107,25 +107,25 @@ static irqreturn_t fpga_interrupt(int irq, void *_mask)
static struct irqaction fpga_irq[4] = {
[0] = {
.handler= fpga_interrupt,
- .flags = IRQF_DISABLED | IRQF_SHARED,
+ .flags = IRQF_SHARED,
.name = "fpga.0",
.dev_id = (void *) 0x0028UL,
},
[1] = {
.handler= fpga_interrupt,
- .flags = IRQF_DISABLED | IRQF_SHARED,
+ .flags = IRQF_SHARED,
.name = "fpga.1",
.dev_id = (void *) 0x0050UL,
},
[2] = {
.handler= fpga_interrupt,
- .flags = IRQF_DISABLED | IRQF_SHARED,
+ .flags = IRQF_SHARED,
.name = "fpga.2",
.dev_id = (void *) 0x1c00UL,
},
[3] = {
.handler= fpga_interrupt,
- .flags = IRQF_DISABLED | IRQF_SHARED,
+ .flags = IRQF_SHARED,
.name = "fpga.3",
.dev_id = (void *) 0x6386UL,
}
diff --git a/arch/frv/kernel/irq-mb93093.c b/arch/frv/kernel/irq-mb93093.c
index 95e4eb4..cde55cf 100644
--- a/arch/frv/kernel/irq-mb93093.c
+++ b/arch/frv/kernel/irq-mb93093.c
@@ -105,7 +105,7 @@ static irqreturn_t fpga_interrupt(int irq, void *_mask)
static struct irqaction fpga_irq[1] = {
[0] = {
.handler= fpga_interrupt,
- .flags = IRQF_DISABLED,
+ .flags = 0,
.name = "fpga.0",
.dev_id = (void *) 0x0700UL,
}
diff --git a/arch/frv/kernel/irq-mb93493.c b/arch/frv/kernel/irq-mb93493.c
index ba648da..8ca5aa4 100644
--- a/arch/frv/kernel/irq-mb93493.c
+++ b/arch/frv/kernel/irq-mb93493.c
@@ -118,13 +118,13 @@ static irqreturn_t mb93493_interrupt(int irq, void
*_piqsr)
static struct irqaction mb93493_irq[2] = {
[0] = {
.handler= mb93493_interrupt,
- .flags = IRQF_DISABLED | IRQF_SHARED,
+ .flags = IRQF_SHARED,
.name = "mb93493.0",
.dev_id = (void *) __addr_MB93493_IQSR(0),
},
[1] = {
.handler= mb93493_interrupt,
- .flags = IRQF_DISABLED | IRQF_SHARED,
+ .flags = IRQF_SHARED,
.name = "mb93493.1",
.dev_id = (void *) __addr_MB93493_IQSR(1),
}
diff --git a/arch/frv/kernel/time.c b/arch/frv/kernel/time.c
index b457de4..94ced29 100644
--- a/arch/frv/kernel/time.c
+++ b/arch/frv/kernel/time.c
@@ -44,7 +44,7 @@ static irqreturn_t timer_interrupt(int irq, void *dummy);
static struct irqaction timer_irq = {
.handler = timer_interrupt,
- .flags = IRQF_DISABLED,
+ .flags = 0,
.name = "timer",
};
--
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] net: korina: remove deprecated IRQF_DISABLED
This patch proposes to remove the IRQF_DISABLED flag from
drivers/net/ethernet/korina.c
It's a NOOP since 2.6.35 and it will be removed one day.
Signed-off-by: Michael Opdenacker
---
drivers/net/ethernet/korina.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/korina.c b/drivers/net/ethernet/korina.c
index 270e65f..a36fa80 100644
--- a/drivers/net/ethernet/korina.c
+++ b/drivers/net/ethernet/korina.c
@@ -996,14 +996,14 @@ static int korina_open(struct net_device *dev)
* that handles the Done Finished
* Ovr and Und Events */
ret = request_irq(lp->rx_irq, korina_rx_dma_interrupt,
- IRQF_DISABLED, "Korina ethernet Rx", dev);
+ 0, "Korina ethernet Rx", dev);
if (ret < 0) {
printk(KERN_ERR "%s: unable to get Rx DMA IRQ %d\n",
dev->name, lp->rx_irq);
goto err_release;
}
ret = request_irq(lp->tx_irq, korina_tx_dma_interrupt,
- IRQF_DISABLED, "Korina ethernet Tx", dev);
+ 0, "Korina ethernet Tx", dev);
if (ret < 0) {
printk(KERN_ERR "%s: unable to get Tx DMA IRQ %d\n",
dev->name, lp->tx_irq);
@@ -1012,7 +1012,7 @@ static int korina_open(struct net_device *dev)
/* Install handler for overrun error. */
ret = request_irq(lp->ovr_irq, korina_ovr_interrupt,
- IRQF_DISABLED, "Ethernet Overflow", dev);
+ 0, "Ethernet Overflow", dev);
if (ret < 0) {
printk(KERN_ERR "%s: unable to get OVR IRQ %d\n",
dev->name, lp->ovr_irq);
@@ -1021,7 +1021,7 @@ static int korina_open(struct net_device *dev)
/* Install handler for underflow error. */
ret = request_irq(lp->und_irq, korina_und_interrupt,
- IRQF_DISABLED, "Ethernet Underflow", dev);
+ 0, "Ethernet Underflow", dev);
if (ret < 0) {
printk(KERN_ERR "%s: unable to get UND IRQ %d\n",
dev->name, lp->und_irq);
--
1.8.1.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFC Block Layer Extensions to Support NV-DIMMs
Rob Gittins, on 09/04/2013 02:54 PM wrote: > Non-volatile DIMMs have started to become available. A NVDIMMs is a > DIMM that does not lose data across power interruptions. Some of the > NVDIMMs act like memory, while others are more like a block device > on the memory bus. Application uses vary from being used to cache > critical data, to being a boot device. > > There are two access classes of NVDIMMs, block mode and > “load/store” mode DIMMs which are referred to as Direct Memory > Mappable. > > The block mode is where the DIMM provides IO ports for read or write > of data. These DIMMs reside on the memory bus but do not appear in the > application address space. Block mode DIMMs do not require any changes > to the current infrastructure, since they provide IO type of interface. > > Direct Memory Mappable DIMMs (DMMD) appear in the system address space > and are accessed via load and store instructions. These NVDIMMs > are part of the system physical address space (SPA) as memory with > the attribute that data survives a power interruption. As such this > memory is managed by the kernel which can assign virtual addresses and > mapped into application’s address space as well as being accessible > by the kernel. The area mapped into the system address space is > being referred to as persistent memory (PMEM). > > PMEM introduces the need for new operations in the > block_device_operations to support the specific characteristics of > the media. > > First data may not propagate all the way through the memory pipeline > when store instructions are executed. Data may stay in the CPU cache > or in other buffers in the processor and memory complex. In order to > ensure the durability of data there needs to be a driver entry point > to force a byte range out to media. The methods of doing this are > specific to the PMEM technology and need to be handled by the driver > that is supporting the DMMDs. To provide a way to ensure that data is > durable adding a commit function to the block_device_operations vector. > >void (*commitpmem)(struct block_device *bdev, void *addr); Why to glue to the block concept for apparently not block class of devices? By pushing NVDIMMs into the block model you both limiting them to block devices capabilities as well as have to expand block devices by alien to them properties. NVDIMMs are, apparently, a new class of devices, so better to have a new class of kernel devices for them. If you then need to put file systems on top of them, just write one-fit-all blk_nvmem driver, which can create a block device for all types of NVDIMM devices and drivers. This way you will clearly and gracefully get the best from NVDIMM devices as well as won't soil block devices. Vlad -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] arm: LLVMLinux: use current_stack_pointer for percpu
On Fri, 6 Sep 2013, beh...@converseincode.com wrote:
> From: Behan Webster
>
> The existing code uses named registers to get the value of the stack pointer.
> The new current_stack_pointer macro is more readable and allows for a central
> portable implementation of how to get the stack pointer with ASM. This change
> supports being able to compile the kernel with both gcc and Clang.
>
> Signed-off-by: Mark Charlebois
> Signed-off-by: Behan Webster
> Reviewed-by: Jan-Simon Möller
> ---
> arch/arm/include/asm/percpu.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/percpu.h b/arch/arm/include/asm/percpu.h
> index 209e650..629a975 100644
> --- a/arch/arm/include/asm/percpu.h
> +++ b/arch/arm/include/asm/percpu.h
> @@ -30,14 +30,14 @@ static inline void set_my_cpu_offset(unsigned long off)
> static inline unsigned long __my_cpu_offset(void)
> {
> unsigned long off;
> - register unsigned long *sp asm ("sp");
> + unsigned long sp = current_stack_pointer;
>
> /*
>* Read TPIDRPRW.
>* We want to allow caching the value, so avoid using volatile and
>* instead use a fake stack read to hazard against barrier().
>*/
> - asm("mrc p15, 0, %0, c13, c0, 4" : "=r" (off) : "Q" (*sp));
> + asm("mrc p15, 0, %0, c13, c0, 4" : "=r" (off) : "Q" (sp));
This change doesn't look to be equivalent. Previously the *sp implied a
memory location which doesn't appear to be the case anymore.
this sp trickery was introduced in commit 509eb76ebf97 to solve bad code
generation (the commit log has the details). It would be good if Will
Deacon could confirm that his test case still works fine with your
change.
Nicolas
[PATCH] gdrom: remove deprecated IRQF_DISABLED
This patch proposes to remove the IRQF_DISABLED flag from drivers/cdrom/gdrom.c. It's a NOOP since 2.6.35 and it will be removed one day. Signed-off-by: Michael Opdenacker --- drivers/cdrom/gdrom.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/cdrom/gdrom.c b/drivers/cdrom/gdrom.c index 5980cb9..51e75ad 100644 --- a/drivers/cdrom/gdrom.c +++ b/drivers/cdrom/gdrom.c @@ -561,11 +561,11 @@ static int gdrom_set_interrupt_handlers(void) int err; err = request_irq(HW_EVENT_GDROM_CMD, gdrom_command_interrupt, - IRQF_DISABLED, "gdrom_command", ); + 0, "gdrom_command", ); if (err) return err; err = request_irq(HW_EVENT_GDROM_DMA, gdrom_dma_interrupt, - IRQF_DISABLED, "gdrom_dma", ); + 0, "gdrom_dma", ); if (err) free_irq(HW_EVENT_GDROM_CMD, ); return err; -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] Keyrings patches
On Fri, 6 Sep 2013, David Howells wrote: > James Morris wrote: > > > > Could you pull these patches into the security tree? They're based on > > > your > > > next branch. > > > > This missed the merge for 3.12. Do you want me to queue the changes up, > > or do you want to send a pull request again after -rc1 ? > > Can you queue them up now in your 'next' branch? Nope, new patches can't go into -next until -rc1. -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 3/5] clk: dt: binding for basic multiplexer clock
On 09/06/2013 12:01 PM, Stephen Warren wrote: On 09/06/2013 12:53 AM, Tero Kristo wrote: On 09/05/2013 11:30 PM, Stephen Warren wrote: ... 1) At least for large SoCs (rather than e.g. a simple clock generator chip/crystal with 1 or 2 outputs), clock drivers need a *lot* of data. We can either: a) Put that data into the clock driver, so it's "just there" for the clock driver to use. b) Represent that data in DT, and write code in the clock driver to parse DT when the driver probe()s. Option (a) is very simple. How can you claim option (a) to be very simple compared to (b)? I think both are as easy / or hard to implement. Well, the work required for (b) is a pure super-set of the work require for (a), so clearly (a) is less work (perhaps the issue you're debating is harder/easier rather than more/less work?) Option (b) entails writing (and executing) a whole bunch of DT parsing code.It's a lot of effort to define the DT binding for the data, convert the data into DT format, and write the parsing code. It wastes execution time at boot. In the end, the result of the parsing is exactly the same data structures that could have been embedded into DT in the first place. This seems like a futile effort. Not really, consider a new SoC where you don't have any kind of data at all. You need to write the data tables anyway, whether they are under DT or some kernel data struct. Yes. But beyond writing the data tables, you also don't/do have to write all the DT parsing code based on choosing (a) or (b), etc. The execution time remain in place for parsing DT data though, but I wouldn't think this to be a problem. Also, you should consider multiarch ARM kernel, where same kernel binary should support multiple SoCs, this would entail having clock data for all built in to the kernel, which can be a problem also. There's no reason that the clock data has to be built into the kernel at all; we should support even SoC clock drivers as modules in an initrd. Alternatively, drop the unused data from the kernel after boot via __init or similar. Alternatively, "pre-link" the clock driver module into the kernel in a way that allows it to be unloaded after boot even though it was built-in. ... You can just as easily claim that anything internal to SoC should be left out from DT, as this is cast in stone (or rather, silicon) also. We should only use it to describe board layout. Everything else, the kernel can 'know' by compile time. I did, immediately below:-) And then I went on to explain why that's necessary in many cases. ... I can turn this around, as you went to this road. Why have DT at all? I believe (at least for ARM) the idea was to avoid churn to the kernel for supporting the numerous different *boards*. The kernel needs and contains drivers for HW blocks, and so since they're there, they may as well encode everything about the HW block. However, in most cases, the kernel shouldn't contain drivers for boards; boards are built from various common components which have drivers. DT is used to describe how those components are inter-connected. Hence, we can hopefully remove all board-related churn from the kernel (once the DT files are moved out of the kernel). Personally I hate the whole idea of a devicetree, however am forced to use it as somebody decided it is a good idea to have one. It doesn't really solve any problems, it just creates new ones in a way of political BS where everybody claims they know how DT should be used, and this just prevents people from actually using it at all. Also, it creates just one new unnecessary dependency for boot, previously we had bootloader and kernel images which had to be in sync, now we have bootloader + DT + kernel. What next? Maybe we should move the clock data into a firmware file of its own? Well, I can sympathize, but I think the time is past for debating that. Why do you care so much what actually goes into the devicetree? To get DT right. Even if we went back to board files and mach-xxx specific code rather than cleanly separated drivers, it would still be beneficial to have much more oversight of board/mach-xxx code than there was previously. Board files made it very easy to do SoC-specific hacks. To avoid that, in either DT or board files, we're trying to impose standards so that we pick correct, generic, appropriate solutions, rather than letting everyone run of with isolated ad-hoc solutions. Shouldn't people be let use it how they see fit? For the clock bindings business this is the same, even if the bindings are there, you are free to use them if you like, and if you don't like them, you can do things differently. We'd be better of creating as much standardization as possible, so that all SoCs/boards/.. work as similarly as possible, and we achieve maximal code reuse, design-reuse, and allow people to understand everything rather than just one particular SoC's/board's solution. If we don't get some re-use and standardization
Re: [AIO] aio-next changes for 3.12
On Fri, 6 Sep 2013 14:39:23 -0400 Benjamin LaHaise wrote: > Please consider pulling the following changes from my aio-next tree at: > > git://git.kvack.org/~bcrl/aio-next.git > > which covers changes since commit 47188d39b5deeebf41f87a02af1b3935866364cf. I don't do git pulls ;) Please send this to Linus for 3.12-rc1 inclusion. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Crypto Update for 3.12
Hi Linus: Here is the crypto update for 3.12: * Added MODULE_SOFTDEP to allow pre-loading of modules. * Reinstated crct10dif driver using the module softdep feature. * Allow via rng driver to be auto-loaded. * Split large input data when necessary in nx. * Handle zero length messages correctly for GCM/XCBC in nx. * Handle SHA-2 chunks bigger than block size properly in nx. * Handle unaligned lengths in omap-aes. * Added SHA384/SHA512 to omap-sham. * Added OMAP5/AM43XX SHAM support. * Added OMAP4 TRNG support. * Misc fixes. Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git Alex Porosanu (2): crypto: caam - replace xstr macro with __stringify crypto: caam - add option for enabling DEBUG mode Andi Kleen (1): crypto: make tables used from assembler __visible Andreas Robinson (1): modules: add support for soft module dependencies Ben Hutchings (1): hwrng: via - Add MODULE_DEVICE_TABLE Chen Gang (1): padata - share code between CPU_ONLINE and CPU_DOWN_FAILED, same to CPU_DOWN_PREPARE and CPU_UP_CANCELED Cristian Stoica (1): crypto: testmgr - remove double execution of the same test suite Dan Carpenter (2): crypto: sahara - checking the wrong variable crypto: tegra-aes - bitwise vs logical and Fabio Estevam (1): hwrng: mxc-rnga - Check the return value from clk_prepare_enable() Fionnuala Gunter (3): crypto: nx - saves chaining value from co-processor crypto: nx - fix limits to sg lists for AES-XCBC crypto: nx - fix limits to sg lists for AES-CCM Herbert Xu (2): Merge git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux Reinstate "crypto: crct10dif - Wrap crc_t10dif function all to use crypto transform framework" Jan-Simon Möller (1): crypto: fcrypt - Fix bitoperation for compilation with clang Jingoo Han (3): hwrng: pixocel - Staticize 'rng_dev' crypto: sahara - Staticize local symbol crypto: crypto4xx - Staticize local symbols Joe Perches (1): crypto: ux500 - Fix logging, make arrays const, neatening Joel Fernandes (14): crypto: scatterwalk - Add support for calculating number of SG elements crypto: omap-aes - Add useful debug macros crypto: omap-aes - Populate number of SG elements crypto: omap-aes - Simplify DMA usage by using direct SGs crypto: omap-aes - Sync SG before DMA operation crypto: omap-aes - Remove previously used intermediate buffers crypto: omap-aes - Add IRQ info and helper macros crypto: omap-aes - PIO mode: Add IRQ handler and walk SGs crypto: omap-aes - PIO mode: platform data for OMAP4/AM437x and trigger crypto: omap-aes - Switch to PIO mode during probe crypto: omap-aes - Add support for cases of unaligned lengths crypto: omap-aes - Convert kzalloc to devm_kzalloc crypto: omap-aes - Convert request_irq to devm_request_irq crypto: omap-aes - Kconfig: Add build support for AM437x John Haxby (1): crypto: xor - Check for osxsave as well as avx in crypto/xor Julia Lawall (3): hwrng: tx4939 - simplify use of devm_ioremap_resource crypto: camellia-x86-64 - replace commas by semicolons and adjust code alignment crypto: camellia_generic - replace commas by semicolons and adjust code alignment Lokesh Vutla (12): crypto: omap-sham - Add SHA384 and SHA512 Support crypto: omap-sham - Add OMAP5/AM43XX SHAM Support crypto: omap-sham - Convert to devm_request_irq() crypto: omap-sham - Convert to devm_kzalloc() hwrng: omap - Use module_platform_driver macro hwrng: omap - Convert to devm_kzalloc() hwrng: omap - Remove duplicated function call hwrng: omap - Add device tree support ARM: OMAP2+: Only manually add hwmod data when DT not used. hwrng: omap - Add OMAP4 TRNG support crypto: omap-sham - Enable Polling mode if DMA fails crypto: omap-sham - correct dma burst size Marcelo Cerri (11): crypto: nx - fix physical addresses added to sg lists crypto: nx - fix limits to sg lists for SHA-2 crypto: nx - fix concurrency issue crypto: nx - add offset to nx_build_sg_lists() crypto: nx - fix limits to sg lists for AES-ECB crypto: nx - fix limits to sg lists for AES-CBC crypto: nx - fix limits to sg lists for AES-CTR crypto: nx - fix limits to sg lists for AES-GCM crypto: nx - fix XCBC for zero length messages crypto: nx - fix GCM for zero length messages crypto: nx - fix SHA-2 for chunks bigger than block size Olof Johansson (1): hwrng: omap - reorder OMAP TRNG driver code Richard Weinberger (1): padata - Register hotcpu notifier after initialization Ruchika Gupta (2): crypto: caam - RNG instantiation by directly programming DECO crypto: caam - Remove unused functions from Job Ring Vakul Garg (1): crypto: caam - Moved macro DESC_JOB_IO_LEN to
[PATCH] ARM: OMAP4 SMP: Corrected a typo fucntions to functions
Corrected the functions spelling mistake in the OMAP4 SMP source file. Signed-off-by: Anoop Thomas Mathew --- arch/arm/mach-omap2/omap-smp.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/mach-omap2/omap-smp.c b/arch/arm/mach-omap2/omap-smp.c index 8708b2a..8912110 100644 --- a/arch/arm/mach-omap2/omap-smp.c +++ b/arch/arm/mach-omap2/omap-smp.c @@ -1,5 +1,5 @@ /* - * OMAP4 SMP source file. It contains platform specific fucntions + * OMAP4 SMP source file. It contains platform specific functions * needed for the linux smp kernel. * * Copyright (C) 2009 Texas Instruments, Inc. -- 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: linux-next: Tree for Sep 3 (x86_init.c)
On 09/03/2013 11:58 AM, Randy Dunlap wrote: > On 09/03/13 01:29, Stephen Rothwell wrote: >> Hi all, >> >> Changes since 20130902: >> > > on i386, when > CONFIG_SMP is not enabled > CONFIG_X86_UP_APIC is not enabled > > arch/x86/built-in.o:(.data+0x540): undefined reference to > `native_setup_msi_irqs' > arch/x86/built-in.o:(.data+0x548): undefined reference to > `native_teardown_msi_irq' > > Looks like recent changes for CONFIG_PCI_MSI should not be built for the > config > that is listed above. > > Full randconfig file is attached. > Specifically, CONFIG_PCI_MSI probably needs to depend on APIC support, which is compiled out in the above case. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] Input updates for 3.12-rc0
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git for-linus or master.kernel.org:/pub/scm/linux/kernel/git/dtor/input.git for-linus to receive updates for the input subsystem. You will get a new driver for slidebar on Ideapad laptops and a bunch of assorted driver fixes. Changelog: - Andrey Moiseev (1): Input: add driver for slidebar on Lenovo IdeaPad laptops Bo Shen (1): Input: qt1070 - add power management ops David Herrmann (1): Input: add SYN_MAX and SYN_CNT constants Fabio Estevam (2): Input: egalax-ts - fix typo and improve text Input: max11801_ts - convert to devm Geert Uytterhoeven (1): Input: cyttsp4 - kill 'defined but not used' compiler warnings Illia Smyrnov (5): Input: omap-keypad - use bitfiled instead of hardcoded values Input: omap-keypad - convert to threaded IRQ Input: omap-keypad - clear interrupts on open Input: omap-keypad - enable wakeup capability for keypad. Input: omap-keypad - set up irq type from DT Javier Martinez Canillas (1): Input: MAINTAINERS - change maintainer for cyttsp driver Jingoo Han (5): Input: max7359 - add CONFIG_PM_SLEEP to suspend/resume Input: cy8ctmg110_ts - add CONFIG_PM_SLEEP to suspend/resume Input: eeti_ts - add CONFIG_PM_SLEEP to suspend/resume Input: pwm-beeper - add CONFIG_PM_SLEEP to suspend/resume Input: joysticks - use dev_get_platdata() Julia Lawall (2): Input: tegra-kbc - simplify use of devm_ioremap_resource Input: keyboard, serio - simplify use of devm_ioremap_resource Mathieu J. Poirier (1): Input: sysrq - DT binding for key sequence Peter Ujfalusi (1): Input: twl6040-vibra - remove support for legacy (pdata) mode Ping Cheng (1): Input: wacom - integrate resolution calculation Sachin Kamat (4): Input: wistron_btns - fix incorrect placement of __initconst Input: lifebook - fix incorrect placement of __initconst Input: synaptics - fix incorrect placement of __initconst Input: htcpen - fix incorrect placement of __initdata Stefan Lippers-Hollmann (3): Input: wistron_btns - drop bogus MODULE_VERSION macro Input: wistron_btns - mark the Medion MD96500 keymap as tested Input: wistron_btns - add MODULE_DEVICE_TABLE Wei Yongjun (3): Input: as5011 - fix error return code in as5011_probe() Input: wacom - fix error return code in wacom_probe() Input: cyttsp4 - remove useless NULL test from cyttsp4_watchdog_timer() Diffstat: .../devicetree/bindings/input/input-reset.txt | 33 ++ .../bindings/input/touchscreen/egalax-ts.txt | 2 +- MAINTAINERS| 11 +- drivers/input/joystick/as5011.c| 3 +- drivers/input/joystick/maplecontrol.c | 4 +- drivers/input/keyboard/imx_keypad.c| 7 +- drivers/input/keyboard/max7359_keypad.c| 2 +- drivers/input/keyboard/nspire-keypad.c | 7 +- drivers/input/keyboard/omap4-keypad.c | 95 -- drivers/input/keyboard/qt1070.c| 27 ++ drivers/input/keyboard/spear-keyboard.c| 7 +- drivers/input/keyboard/tegra-kbc.c | 7 +- drivers/input/misc/Kconfig | 10 + drivers/input/misc/Makefile| 1 + drivers/input/misc/ideapad_slidebar.c | 358 + drivers/input/misc/pwm-beeper.c| 2 +- drivers/input/misc/twl6040-vibra.c | 41 +-- drivers/input/misc/wistron_btns.c | 6 +- drivers/input/mouse/lifebook.c | 2 +- drivers/input/mouse/synaptics.c| 4 +- drivers/input/serio/arc_ps2.c | 7 +- drivers/input/serio/i8042.h| 24 -- drivers/input/serio/olpc_apsp.c| 3 - drivers/input/tablet/wacom_sys.c | 87 +++-- drivers/input/tablet/wacom_wac.c | 19 +- drivers/input/touchscreen/cy8ctmg110_ts.c | 6 +- drivers/input/touchscreen/cyttsp4_core.c | 203 ++-- drivers/input/touchscreen/eeti_ts.c| 6 +- drivers/input/touchscreen/htcpen.c | 2 +- drivers/input/touchscreen/max11801_ts.c| 37 +-- drivers/tty/sysrq.c| 42 +++ include/linux/i8042.h | 24 ++ include/uapi/linux/input.h | 2 + 33 files changed, 770 insertions(+), 321 deletions(-) create mode 100644 Documentation/devicetree/bindings/input/input-reset.txt create mode 100644 drivers/input/misc/ideapad_slidebar.c -- Dmitry pgppeSflV7xWb.pgp Description: PGP signature
Re: [GIT] HID for 3.12 merge window
On Fri, Sep 06, 2013 at 06:00:29PM -0700, Linus Torvalds wrote: > On Fri, Sep 6, 2013 at 5:58 PM, Dmitry Torokhov > wrote: > > > > The patch still had problems so I'd revert it and wii bits and try again > > later. > > Ok. Mind giving me a list of commits, so that I don't have to do a > trial-and-error thing? I know the primary commit that causes problems, > but there are commits that seem to depend on it.. Sorry for the delay. I believe you need to revert: 73f8645 HID: wiimote: add support for Guitar-Hero drums 61e0065 Input: introduce BTN/ABS bits for drums and guitars Hmm... there also was "HID: wiimote: add support for Guitar-Hero guitars" but I do not see it... Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git pull] vfs pile 2 (of many)
Mostly Miklos' series this time. Please, pull from git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus Shortlog: Al Viro (1): constify dcache.c inlined helpers where possible Anand Avati (1): fuse: drop dentry on failed revalidate Miklos Szeredi (10): vfs: restructure d_genocide() vfs: add d_walk() vfs: check submounts and drop atomically vfs: check unlinked ancestors before mount afs: use check_submounts_and_drop() gfs2: use check_submounts_and_drop() nfs: use check_submounts_and_drop() sysfs: use check_submounts_and_drop() fuse: use d_materialise_unique() fuse: clean up return in fuse_dentry_revalidate() Diffstat: fs/afs/dir.c | 10 +- fs/dcache.c| 411 +--- fs/fuse/dir.c | 97 ++-- fs/gfs2/dentry.c |9 +- fs/internal.h |1 + fs/namespace.c | 11 +- fs/nfs/dir.c |9 +- fs/sysfs/dir.c | 20 +-- include/linux/dcache.h | 13 +- 9 files changed, 323 insertions(+), 258 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/1] dcache: Translating dentry into pathname without taking rename_lock
On Fri, Sep 06, 2013 at 05:58:51PM -0700, Linus Torvalds wrote: > On Fri, Sep 6, 2013 at 5:19 PM, Linus Torvalds > wrote: > > > > (We're bounded in practice by PATH_MAX, so you can't make getcwd() > > traverse more than about 2000 parents (single character filename plus > > the slash for each level), and for all I know filesystems might cap it > > before that, so it's not unbounded, but the difference between "1" and > > "2000" is pretty damn big) > > .. in particular, it's big enough that one is pretty much guaranteed > to fit in any reasonable L1 cache (if we have dentry hash chains so > long that that becomes a problem for traversing a single chain, we're > screwed anyway), while the other can most likely be a case of "not a > single L1 cache hit because by the time you fail and go back to the > start, you've flushed the L1 cache". > > Now, whether 2000 L2 cache misses is long enough to give people a > chance to run the whole rename system call path in a loop a few times, > I don't know, but it sure as heck sounds likely. > > Of course, you might still ask "why should we even care?" At least > without preemption, you might be able to trigger some really excessive > latencies and possibly a watchdog screaming at you as a result. But > that said, maybe we wouldn't care. I just think that the solution is > so simple (what, five extra lines or so) that it's worth avoiding even > the worry. We already have that kind of logics - see select_parent() et.al. in mainline or d_walk() in vfs.git#for-linus (pull request will go in a few minutes). With this patch we get * plain seqretry loop (d_lookup(), is_subdir(), autofs4_getpath(), ceph_misc_build_path(), [cifs] build_path_from_dentry(), nfs_path(), [audit] handle_path()) * try seqretry once, then switch to write_seqlock() (the things that got unified into d_walk()) * try seqretry three times, then switch to write_seqlock() (d_path() and friends) * several pure write_seqlock() users (d_move(), d_set_mounted(), d_materialize_unique()) The last class is not a problem - these we want as writers. I really don't like the way the rest is distributed - if nothing else, nfs_path() and friends are in exactly the same situation as d_path(). Moreover, why the distinction between "try once" and "try thrice"? _If_ we fold the second and the third groups together (and probably have a bunch from the first one join that), we at least get something understandable, but the I really wonder if seqlock has the right calling conventions for that (and at least I'd like to fold the "already got writelock" flag into seq - we do have a spare bit there). Comments? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
crypto/xor.ko fails to build with CONFIG_KERNEL_MODE_NEON=y
Hi, We enabled CONFIG_KERNEL_MODE_NEON on the armv7hl builds we're doing. It builds for a while, but eventually fails when running modpost on the xor.ko module: ERROR: "xor_block_neon_inner" [crypto/xor.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 I tried adding an EXPORT_SYMBOL_GPL(xor_block_neon_inner); after the structure definition in arch/arm/lib/xor-neon.c but that doesn't seem to have done anything. Before I go chasing this further, I'm curious if anyone else has run into this. josh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 3.11.0-next-20130905: kernel BUG at include/linux/pagemap.h:343
On 09/06/2013 07:09 PM, Artem Savkov wrote: > On Fri, Sep 06, 2013 at 03:26:18PM +0800, Baoquan He wrote: >> [ 30.438555] [ cut here ] >> [ 30.443385] kernel BUG at include/linux/pagemap.h:343! > Seems to be the same one I reported here: > http://www.spinics.net/lists/kernel/msg1597973.html > Yeah, thanks for your information. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/1] dcache: Translating dentry into pathname without taking rename_lock
On 09/06/2013 04:52 PM, Linus Torvalds wrote:
On Fri, Sep 6, 2013 at 9:08 AM, Waiman Long wrote:
This patch will replace the writer's write_seqlock/write_sequnlock
sequence of the rename_lock of the callers of the prepend_path() and
__dentry_path() functions with the reader's read_seqbegin/read_seqretry
sequence within these 2 functions.
Ok, this actually looks really good.
I do have one comment, from just reading the patch:
I would really like the stuff inside the
restart:
bptr = *buffer;
blen = *buflen;
if (retry_cnt) {
seq = read_seqbegin(_lock);
rcu_read_lock();
} else
write_seqlock(_lock);
... guts of path generation ...
if (retry_cnt) {
retry_cnt--;
rcu_read_unlock();
if (read_seqretry(_lock, seq))
goto restart;
} else
write_sequnlock(_lock);
could possible be done as a separate function?
Alternatively (or perhaps additionally), maybe the locking could be
done as an inline function too (taking the retry count as an argument)
to make things a bit more easy to understand.
I would prefer putting the begin and end blocks into 2 helper inlined
helper functions to make code easier to look at. I will work on this
over the weekend.
-Longman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86, ACPI: Increase override tables number limit
Current acpi tables in initrd is limited to 10, that is too small.
64 should be good enough as we have 35 sigs and could have several
SSDT.
Two problems in current code prevent us from increasing limit:
1. that cpio file info array is put in stack, as every element is 32
bytes, could run out of stack if we have that array size to 64.
We can move it out from stack, and make it as global and put it in
__initdata section.
2. early_ioremap only can remap 256k one time. Current code is mapping
10 tables one time. If we increase that limit, whole size could be
more than 256k, early_ioremap will fail with that.
We can map chunks one by one during copying, instead of mapping
all them one time.
-v2: According to tj, split it out to separated patch, also
rename array name to acpi_initrd_files.
-v3: Add some comments about mapping table one by one during copying
per tj.
-v4: copy one by one chunk instead as one single DSDT/SSDT could be
more than 256k.
-v5: fix compiling err when !CONFIG_SMP, found by Fengguang's robot
Signed-off-by: Yinghai
Cc: Rafael J. Wysocki
Cc: linux-a...@vger.kernel.org
Acked-by: Tejun Heo
Tested-by: Thomas Renninger
Reviewed-by: Tang Chen
Tested-by: Tang Chen
Acked-by: Toshi Kani
---
arch/x86/include/asm/acpi.h |1 +
drivers/acpi/osl.c | 44
2 files changed, 33 insertions(+), 12 deletions(-)
Index: linux-2.6/drivers/acpi/osl.c
===
--- linux-2.6.orig/drivers/acpi/osl.c
+++ linux-2.6/drivers/acpi/osl.c
@@ -569,8 +569,10 @@ static const char * const table_sigs[] =
#define ACPI_HEADER_SIZE sizeof(struct acpi_table_header)
-/* Must not increase 10 or needs code modification below */
-#define ACPI_OVERRIDE_TABLES 10
+#define ACPI_OVERRIDE_TABLES 64
+static struct cpio_data __initdata acpi_initrd_files[ACPI_OVERRIDE_TABLES];
+
+#define MAP_CHUNK_SIZE (NR_FIX_BTMAPS << PAGE_SHIFT)
void __init acpi_initrd_override(void *data, size_t size)
{
@@ -579,8 +581,6 @@ void __init acpi_initrd_override(void *d
struct acpi_table_header *table;
char cpio_path[32] = "kernel/firmware/acpi/";
struct cpio_data file;
- struct cpio_data early_initrd_files[ACPI_OVERRIDE_TABLES];
- char *p;
if (data == NULL || size == 0)
return;
@@ -625,8 +625,8 @@ void __init acpi_initrd_override(void *d
table->signature, cpio_path, file.name, table->length);
all_tables_size += table->length;
- early_initrd_files[table_nr].data = file.data;
- early_initrd_files[table_nr].size = file.size;
+ acpi_initrd_files[table_nr].data = file.data;
+ acpi_initrd_files[table_nr].size = file.size;
table_nr++;
}
if (table_nr == 0)
@@ -652,14 +652,34 @@ void __init acpi_initrd_override(void *d
memblock_reserve(acpi_tables_addr, all_tables_size);
arch_reserve_mem_area(acpi_tables_addr, all_tables_size);
- p = early_ioremap(acpi_tables_addr, all_tables_size);
-
+ /*
+* early_ioremap only can remap 256k one time. If we map all
+* tables one time, we will hit the limit. Need to map chunks
+* one by one during copying the same as that in relocate_initrd().
+*/
for (no = 0; no < table_nr; no++) {
- memcpy(p + total_offset, early_initrd_files[no].data,
- early_initrd_files[no].size);
- total_offset += early_initrd_files[no].size;
+ unsigned char *src_p = acpi_initrd_files[no].data;
+ phys_addr_t size = acpi_initrd_files[no].size;
+ phys_addr_t dest_addr = acpi_tables_addr + total_offset;
+ phys_addr_t slop, clen;
+ char *dest_p;
+
+ total_offset += size;
+
+ while (size) {
+ slop = dest_addr & ~PAGE_MASK;
+ clen = size;
+ if (clen > MAP_CHUNK_SIZE - slop)
+ clen = MAP_CHUNK_SIZE - slop;
+ dest_p = early_ioremap(dest_addr & PAGE_MASK,
+clen + slop);
+ memcpy(dest_p + slop, src_p, clen);
+ early_iounmap(dest_p, clen + slop);
+ src_p += clen;
+ dest_addr += clen;
+ size -= clen;
+ }
}
- early_iounmap(p, all_tables_size);
}
#endif /* CONFIG_ACPI_INITRD_TABLE_OVERRIDE */
Index: linux-2.6/arch/x86/include/asm/acpi.h
===
--- linux-2.6.orig/arch/x86/include/asm/acpi.h
+++ linux-2.6/arch/x86/include/asm/acpi.h
@@ -26,6 +26,7 @@
#include
#include
+#include
#include
#include
#include
--
To unsubscribe from this
[PATCH] x86, mm: Add comments for step_size
Current code use MACRO to have shift to set to 5, but there is not
explanation about selection.
Add comment about why we are using 5.
Also add explanation that we don't need to worry about overflow
on 32bit.
-v3: According to Ingo, update changelog and comments.
Signed-off-by: Yinghai Lu
---
arch/x86/mm/init.c | 20 +---
1 file changed, 17 insertions(+), 3 deletions(-)
Index: linux-2.6/arch/x86/mm/init.c
===
--- linux-2.6.orig/arch/x86/mm/init.c
+++ linux-2.6/arch/x86/mm/init.c
@@ -399,8 +399,22 @@ static unsigned long __init init_range_m
return mapped_ram_size;
}
-/* (PUD_SHIFT-PMD_SHIFT)/2 */
-#define STEP_SIZE_SHIFT 5
+static unsigned long __init get_new_step_size(unsigned long step_size)
+{
+ /*
+* initial mapped size is PMD_SIZE (2M).
+* We can not set step_size to be PUD_SIZE (1G) yet.
+* In worse case, when we cross the 1G boundary, and
+* PG_LEVEL_2M is not set, we will need 1+1+512 pages (2M + 8k)
+* to map 1G range with PTE. Use 5 as shift for now.
+*
+* Don't need to worry about overflow,
+* on 32bit, when step_size is 0, round_down() return 0 for
+* start, and that make that 0 just like 0x1ULL.
+*/
+ return step_size << 5;
+}
+
void __init init_mem_mapping(void)
{
unsigned long end, real_end, start, last_start;
@@ -449,7 +463,7 @@ void __init init_mem_mapping(void)
min_pfn_mapped = last_start >> PAGE_SHIFT;
/* only increase step_size after big range get mapped */
if (new_mapped_ram_size > mapped_ram_size)
- step_size <<= STEP_SIZE_SHIFT;
+ step_size = get_new_step_size(step_size);
mapped_ram_size += new_mapped_ram_size;
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] rcu: Is it safe to enter an RCU read-side critical section?
* Paul E. McKenney (paul...@linux.vnet.ibm.com) wrote:
> On Fri, Sep 06, 2013 at 02:21:35PM -0400, Steven Rostedt wrote:
> > On Fri, 6 Sep 2013 10:52:38 -0700
> > "Paul E. McKenney" wrote:
> >
> > > > What exactly does "extended quiescent state" mean? (Note, that's a
> > > > rhetorical question)
> > >
> > > In which case my rhetorical (and therefore useless) answer has to be
> > > "it is a quiescent state that is extended". ;-)
> > >
> > > Sorry, couldn't resist...
> >
> > Of course you couldn't ;)
> >
> > >
> > > > I wonder if we should change "rcu_cpu_ignore()" for "rcu_eqs_enter()"
> > > > and "rcu_cpu_heed()" for "rcu_eqs_exit()", as IMHO that's much more
> > > > straight forward to understand than trying to wrap you head around what
> > > > a quiescent state is, and why we are entering it or exiting it.
> > > >
> > > > It also flat out explains to people that rcu is not processing that
> > > > current CPU, and things like rcu_read_lock() should not be used.
> > > >
> > > > Then we can say "rcu_cpu_is_ignored()" for things like
> > > > "rcu_is_cpu_eqs()".
> > >
> > > Currently, none of RCU's _eqs functions are exported, so they have
> > > the potential to confuse only people working on the RCU implementation
> > > itself, who had better understand what "eqs" means.
> >
> > Yeah, that's what I thought, and never cared about the "eqs" meaning.
> >
> > >
> > > But I do count your vote against "eqs" appearing in the name of any
> > > function exported by RCU.
> >
> > Right, their shouldn't be any "eqs" functions that are global to users
> > outside of the RCU infrastructure.
> >
> > >
> > > How about if I made rcu_is_cpu_idle() be as follows?
> > >
> > > int rcu_is_cpu_idle(void)
> > > {
> > > int ret;
> > >
> > > ret = (atomic_read(_cpu(rcu_dynticks.dynticks,
> > > raw_smp_processor_id())) & 0x1) == 0;
> > > return ret;
> > > }
> > >
> > > This should allow existing uses to function properly and should allow
> > > you to use it as well.
> > >
> >
> > You already said it wont work, but I still would have been against
> > using it, because I wouldn't be checking if rcu thinks the CPU is idle,
> > as NO_HZ_FULL has nothing to do with idle.
>
> OK then, how about the following?
>
> Thanx, Paul
>
>
>
> rcu: Is it safe to enter an RCU read-side critical section?
>
> There is currently no way for kernel code to determine whether it
> is safe to enter an RCU read-side critical section, in other words,
> whether or not RCU is paying attention to the currently running CPU.
> Given the large and increasing quantity of code shared by the idle loop
> and non-idle code, the this shortcoming is becoming increasingly painful.
>
> This commit therefore adds rcu_watching_this_cpu(), which returns true
> if it is safe to enter an RCU read-side critical section on the currently
> running CPU. This function is quite fast, using only a __this_cpu_read().
> However, the caller must disable preemption.
Hi Paul,
Hopefully I won't be redundant with other prior comments, but how about
the following:
static inline __rcu_read_check(void):
- checks if it is safe to enter a RCU read-side critical section in
the current context.
- requires that the caller disable preemption.
static inline rcu_read_check(void):
- disables preemption and inlines __rcu_read_check().
I don't think it is semantically a good thing to bury the
implementation-specific detail (whether is RCU watched on this
particular CPU) into the API naming. Also, I think the generic version
of this check should require no "special knowledge" from the user, hence
my double-underscores proposal for the optimized version.
Thoughts ?
Thanks,
Mathieu
>
> Reported-by: Steven Rostedt
> Signed-off-by: Paul E. McKenney
>
> diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
> index 5b444e0..a41eb35 100644
> --- a/include/linux/rcupdate.h
> +++ b/include/linux/rcupdate.h
> @@ -261,6 +261,10 @@ static inline void rcu_user_hooks_switch(struct
> task_struct *prev,
> rcu_irq_exit(); \
> } while (0)
>
> +#if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE) ||
> defined(CONFIG_SMP)
> +extern int rcu_is_cpu_idle(void);
> +#endif /* #if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE)
> || defined(CONFIG_SMP) */
> +
> /*
> * Infrastructure to implement the synchronize_() primitives in
> * TREE_RCU and rcu_barrier_() primitives in TINY_RCU.
> @@ -297,10 +301,6 @@ static inline void destroy_rcu_head_on_stack(struct
> rcu_head *head)
> }
> #endif /* #else !CONFIG_DEBUG_OBJECTS_RCU_HEAD */
>
> -#if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_SMP)
> -extern int rcu_is_cpu_idle(void);
> -#endif /* #if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_SMP) */
> -
> #if defined(CONFIG_HOTPLUG_CPU) &&
Re: [GIT] HID for 3.12 merge window
On Fri, Sep 6, 2013 at 5:58 PM, Dmitry Torokhov wrote: > > The patch still had problems so I'd revert it and wii bits and try again > later. Ok. Mind giving me a list of commits, so that I don't have to do a trial-and-error thing? I know the primary commit that causes problems, but there are commits that seem to depend on it.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/1] dcache: Translating dentry into pathname without taking rename_lock
On Fri, Sep 6, 2013 at 5:19 PM, Linus Torvalds wrote: > > (We're bounded in practice by PATH_MAX, so you can't make getcwd() > traverse more than about 2000 parents (single character filename plus > the slash for each level), and for all I know filesystems might cap it > before that, so it's not unbounded, but the difference between "1" and > "2000" is pretty damn big) .. in particular, it's big enough that one is pretty much guaranteed to fit in any reasonable L1 cache (if we have dentry hash chains so long that that becomes a problem for traversing a single chain, we're screwed anyway), while the other can most likely be a case of "not a single L1 cache hit because by the time you fail and go back to the start, you've flushed the L1 cache". Now, whether 2000 L2 cache misses is long enough to give people a chance to run the whole rename system call path in a loop a few times, I don't know, but it sure as heck sounds likely. Of course, you might still ask "why should we even care?" At least without preemption, you might be able to trigger some really excessive latencies and possibly a watchdog screaming at you as a result. But that said, maybe we wouldn't care. I just think that the solution is so simple (what, five extra lines or so) that it's worth avoiding even the worry. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] HID for 3.12 merge window
Linus Torvalds wrote: >On Fri, Sep 6, 2013 at 2:50 PM, David Herrmann >wrote: >> Hi >> >> On Fri, Sep 6, 2013 at 10:20 PM, Markus Trippelsdorf >>> >>> commit 61e00655e9cb82e034eb72b95a51072e718d14a7 >>> Author: David Herrmann >>> Date: Mon Aug 26 19:14:46 2013 +0200 >>> >>> Input: introduce BTN/ABS bits for drums and guitars >>> >>> The commit above breaks my Logitech mouse. The mouse cursor just >sits in >>> the middle of the screen and doesn't react to movements. dmesg is >>> normal, but Xorg.0.log says: >> >> Ok, the issue is the kernel assumes ABS_MAX to be a power-of-2 minus >1 >> (used as mask). That wasn't really obvious to me. Attached is a patch >> which should fix that. Could you apply it on top of linus/master and >> give it a try? > >Gah. I just wasted too much time bisecting down my logitech wireless >keyboard not working to within a few commits of this, and decided to >just try your patch. > >And yes, it makes my keyboard work. > >Dmitry, should I just apply the patch, or should we revert and use >other bits? Please, this needs to be resolved, I stopped merging when >I noticed this problem.. The patch still had problems so I'd revert it and wii bits and try again later. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] rcu: Is it safe to enter an RCU read-side critical section?
On Fri, Sep 06, 2013 at 02:21:35PM -0400, Steven Rostedt wrote:
> On Fri, 6 Sep 2013 10:52:38 -0700
> "Paul E. McKenney" wrote:
>
> > > What exactly does "extended quiescent state" mean? (Note, that's a
> > > rhetorical question)
> >
> > In which case my rhetorical (and therefore useless) answer has to be
> > "it is a quiescent state that is extended". ;-)
> >
> > Sorry, couldn't resist...
>
> Of course you couldn't ;)
>
> >
> > > I wonder if we should change "rcu_cpu_ignore()" for "rcu_eqs_enter()"
> > > and "rcu_cpu_heed()" for "rcu_eqs_exit()", as IMHO that's much more
> > > straight forward to understand than trying to wrap you head around what
> > > a quiescent state is, and why we are entering it or exiting it.
> > >
> > > It also flat out explains to people that rcu is not processing that
> > > current CPU, and things like rcu_read_lock() should not be used.
> > >
> > > Then we can say "rcu_cpu_is_ignored()" for things like
> > > "rcu_is_cpu_eqs()".
> >
> > Currently, none of RCU's _eqs functions are exported, so they have
> > the potential to confuse only people working on the RCU implementation
> > itself, who had better understand what "eqs" means.
>
> Yeah, that's what I thought, and never cared about the "eqs" meaning.
>
> >
> > But I do count your vote against "eqs" appearing in the name of any
> > function exported by RCU.
>
> Right, their shouldn't be any "eqs" functions that are global to users
> outside of the RCU infrastructure.
>
> >
> > How about if I made rcu_is_cpu_idle() be as follows?
> >
> > int rcu_is_cpu_idle(void)
> > {
> > int ret;
> >
> > ret = (atomic_read(_cpu(rcu_dynticks.dynticks,
> > raw_smp_processor_id())) & 0x1) == 0;
> > return ret;
> > }
> >
> > This should allow existing uses to function properly and should allow
> > you to use it as well.
> >
>
> You already said it wont work, but I still would have been against
> using it, because I wouldn't be checking if rcu thinks the CPU is idle,
> as NO_HZ_FULL has nothing to do with idle.
OK then, how about the following?
Thanx, Paul
rcu: Is it safe to enter an RCU read-side critical section?
There is currently no way for kernel code to determine whether it
is safe to enter an RCU read-side critical section, in other words,
whether or not RCU is paying attention to the currently running CPU.
Given the large and increasing quantity of code shared by the idle loop
and non-idle code, the this shortcoming is becoming increasingly painful.
This commit therefore adds rcu_watching_this_cpu(), which returns true
if it is safe to enter an RCU read-side critical section on the currently
running CPU. This function is quite fast, using only a __this_cpu_read().
However, the caller must disable preemption.
Reported-by: Steven Rostedt
Signed-off-by: Paul E. McKenney
diff --git a/include/linux/rcupdate.h b/include/linux/rcupdate.h
index 5b444e0..a41eb35 100644
--- a/include/linux/rcupdate.h
+++ b/include/linux/rcupdate.h
@@ -261,6 +261,10 @@ static inline void rcu_user_hooks_switch(struct
task_struct *prev,
rcu_irq_exit(); \
} while (0)
+#if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE) ||
defined(CONFIG_SMP)
+extern int rcu_is_cpu_idle(void);
+#endif /* #if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_RCU_TRACE) ||
defined(CONFIG_SMP) */
+
/*
* Infrastructure to implement the synchronize_() primitives in
* TREE_RCU and rcu_barrier_() primitives in TINY_RCU.
@@ -297,10 +301,6 @@ static inline void destroy_rcu_head_on_stack(struct
rcu_head *head)
}
#endif /* #else !CONFIG_DEBUG_OBJECTS_RCU_HEAD */
-#if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_SMP)
-extern int rcu_is_cpu_idle(void);
-#endif /* #if defined(CONFIG_DEBUG_LOCK_ALLOC) || defined(CONFIG_SMP) */
-
#if defined(CONFIG_HOTPLUG_CPU) && defined(CONFIG_PROVE_RCU)
bool rcu_lockdep_current_cpu_online(void);
#else /* #if defined(CONFIG_HOTPLUG_CPU) && defined(CONFIG_PROVE_RCU) */
diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h
index e31005e..67fe672 100644
--- a/include/linux/rcutiny.h
+++ b/include/linux/rcutiny.h
@@ -132,4 +132,13 @@ static inline void rcu_scheduler_starting(void)
}
#endif /* #else #ifdef CONFIG_DEBUG_LOCK_ALLOC */
+#ifdef CONFIG_RCU_TRACE
+
+static inline bool rcu_watching_this_cpu(void)
+{
+ return !rcu_is_cpu_idle();
+}
+
+#endif /* #ifdef CONFIG_RCU_TRACE */
+
#endif /* __LINUX_RCUTINY_H */
diff --git a/include/linux/rcutree.h b/include/linux/rcutree.h
index 226169d..c605b41 100644
--- a/include/linux/rcutree.h
+++ b/include/linux/rcutree.h
@@ -90,4 +90,6 @@ extern void exit_rcu(void);
extern void rcu_scheduler_starting(void);
extern int rcu_scheduler_active __read_mostly;
+extern bool rcu_watching_this_cpu(void);
+
#endif /* __LINUX_RCUTREE_H */
diff --git
Re: [PATCH] ecryptfs: avoid ctx initialization race
On Fri, Sep 6, 2013 at 5:30 PM, Tyler Hicks wrote:
> On 2013-08-13 15:02:27, Kees Cook wrote:
>> It might be possible for two callers to race the mutex lock after the
>> NULL ctx check. Instead, move the lock above the check so there isn't
>> the possibility of leaking a crypto ctx. Additionally, report the full
>> algo name when failing.
>>
>> Signed-off-by: Kees Cook
>
> Thanks, Kees!
>
> I've pushed this to my next branch and it'll be included in a pull
> request early next week.
>
> I made one small change to this patch. See below.
>
>> ---
>> fs/ecryptfs/crypto.c | 11 ++-
>> 1 file changed, 6 insertions(+), 5 deletions(-)
>>
>> diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
>> index d107576..c134346 100644
>> --- a/fs/ecryptfs/crypto.c
>> +++ b/fs/ecryptfs/crypto.c
>> @@ -618,27 +618,28 @@ int ecryptfs_init_crypt_ctx(struct ecryptfs_crypt_stat
>> *crypt_stat)
>> "key_size_bits = [%zd]\n",
>> crypt_stat->cipher, (int)strlen(crypt_stat->cipher),
>> crypt_stat->key_size << 3);
>> + mutex_lock(_stat->cs_tfm_mutex);
>> if (crypt_stat->tfm) {
>> rc = 0;
>> - goto out;
>> + goto out_unlock;
>> }
>> - mutex_lock(_stat->cs_tfm_mutex);
>> rc = ecryptfs_crypto_api_algify_cipher_name(_alg_name,
>> crypt_stat->cipher, "cbc");
>> if (rc)
>> goto out_unlock;
>> crypt_stat->tfm = crypto_alloc_ablkcipher(full_alg_name, 0, 0);
>> - kfree(full_alg_name);
>> if (IS_ERR(crypt_stat->tfm)) {
>> rc = PTR_ERR(crypt_stat->tfm);
>> crypt_stat->tfm = NULL;
>> ecryptfs_printk(KERN_ERR, "cryptfs: init_crypt_ctx(): "
>> "Error initializing cipher [%s]\n",
>> - crypt_stat->cipher);
>> - goto out_unlock;
>> + full_alg_name);
>> + goto out_free;
>> }
>> crypto_ablkcipher_set_flags(crypt_stat->tfm, CRYPTO_TFM_REQ_WEAK_KEY);
>> rc = 0;
>> +out_free:
>> + kfree(full_alg_name);
>> out_unlock:
>> mutex_unlock(_stat->cs_tfm_mutex);
>> out:
>
> The out label is no longer used. I removed it when I committed this
> patch.
Ah! Yes, good call. Thanks,
-Kees
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ecryptfs: avoid ctx initialization race
On 2013-08-13 15:02:27, Kees Cook wrote:
> It might be possible for two callers to race the mutex lock after the
> NULL ctx check. Instead, move the lock above the check so there isn't
> the possibility of leaking a crypto ctx. Additionally, report the full
> algo name when failing.
>
> Signed-off-by: Kees Cook
Thanks, Kees!
I've pushed this to my next branch and it'll be included in a pull
request early next week.
I made one small change to this patch. See below.
> ---
> fs/ecryptfs/crypto.c | 11 ++-
> 1 file changed, 6 insertions(+), 5 deletions(-)
>
> diff --git a/fs/ecryptfs/crypto.c b/fs/ecryptfs/crypto.c
> index d107576..c134346 100644
> --- a/fs/ecryptfs/crypto.c
> +++ b/fs/ecryptfs/crypto.c
> @@ -618,27 +618,28 @@ int ecryptfs_init_crypt_ctx(struct ecryptfs_crypt_stat
> *crypt_stat)
> "key_size_bits = [%zd]\n",
> crypt_stat->cipher, (int)strlen(crypt_stat->cipher),
> crypt_stat->key_size << 3);
> + mutex_lock(_stat->cs_tfm_mutex);
> if (crypt_stat->tfm) {
> rc = 0;
> - goto out;
> + goto out_unlock;
> }
> - mutex_lock(_stat->cs_tfm_mutex);
> rc = ecryptfs_crypto_api_algify_cipher_name(_alg_name,
> crypt_stat->cipher, "cbc");
> if (rc)
> goto out_unlock;
> crypt_stat->tfm = crypto_alloc_ablkcipher(full_alg_name, 0, 0);
> - kfree(full_alg_name);
> if (IS_ERR(crypt_stat->tfm)) {
> rc = PTR_ERR(crypt_stat->tfm);
> crypt_stat->tfm = NULL;
> ecryptfs_printk(KERN_ERR, "cryptfs: init_crypt_ctx(): "
> "Error initializing cipher [%s]\n",
> - crypt_stat->cipher);
> - goto out_unlock;
> + full_alg_name);
> + goto out_free;
> }
> crypto_ablkcipher_set_flags(crypt_stat->tfm, CRYPTO_TFM_REQ_WEAK_KEY);
> rc = 0;
> +out_free:
> + kfree(full_alg_name);
> out_unlock:
> mutex_unlock(_stat->cs_tfm_mutex);
> out:
The out label is no longer used. I removed it when I committed this
patch.
Tyler
signature.asc
Description: Digital signature
Re: Unusually high system CPU usage with recent kernels
On Tue, Sep 03, 2013 at 03:16:07PM -0700, Paul E. McKenney wrote: > On Tue, Sep 03, 2013 at 11:11:01PM +0200, Tibor Billes wrote: > > > From: Paul E. McKenney Sent: 08/30/13 03:24 AM > > > On Tue, Aug 27, 2013 at 10:05:42PM +0200, Tibor Billes wrote: > > > > From: Paul E. McKenney Sent: 08/26/13 06:28 AM > > > > > Here is a patch that is more likely to help. I am testing it in > > > > > parallel, > > > > > but figured I should send you a sneak preview. > > > > > > > > I tried it, but I don't see any difference in overall performance. The > > > > dstat > > > > also shows the same as before. > > > > > > > > But I did notice something. Occasionally there is an increase in > > > > userspace > > > > CPU usage, interrupts and context switches are dropping, and it really > > > > gets > > > > more work done (scons printed commands more frequently). I checked that > > > > this behaviour is present without your patch, I just didn't notice this > > > > before. Maybe you can make some sense out of it. > > > > > > > > system total-cpu-usage -dsk/total- -net/total- > > > > ---paging-- ---system-- swap--- --memory-usage- > > > > -virtual-memory > > > > time |usr sys idl wai hiq siq| read writ| recv send| in > > > > out | int csw | used free| used buff cach free|majpf minpf alloc > > > > free > > > > 27-08 20:51:53| 23 62 5 0 11 0| 0 0 | 0 0 | 0 > > > > 0 |1274 3102k| 0 7934M| 549M 56.0M 491M 6698M| 0 28 156 > > > > 159 > > > > 27-08 20:51:54| 24 64 1 0 11 0| 0 0 | 0 0 | 0 > > > > 0 |1317 3165k| 0 7934M| 549M 56.0M 491M 6698M| 0 53 189 > > > > 182 > > > > 27-08 20:51:55| 33 50 6 2 9 0| 192k 1832k| 0 0 | 0 > > > > 0 |1371 2442k| 0 7934M| 544M 56.0M 492M 6702M| 0 30k 17k > > > > 17k > > > > 27-08 20:51:56| 24 64 0 0 12 0| 0 0 | 0 0 | 0 > > > > 0 |1313 3220k| 0 7934M| 544M 56.0M 492M 6701M| 0 21 272 > > > > 232 > > > > 27-08 20:51:57| 24 64 0 0 12 0| 0 0 | 0 0 | 0 > > > > 0 |1319 3226k| 0 7934M| 544M 56.0M 492M 6701M| 0 8 96 > > > > 112 > > > > 27-08 20:51:58| 25 63 0 0 12 0| 0 0 | 0 0 | 0 > > > > 0 |1317 3224k| 0 7934M| 544M 56.0M 492M 6701M| 0 12 145 > > > > 141 > > > > 27-08 20:51:59| 24 64 0 0 12 0| 0 0 | 0 0 | 0 > > > > 0 |1317 3223k| 0 7934M| 544M 56.0M 492M 6701M| 0 54 193 > > > > 191 > > > > 27-08 20:52:00| 25 63 0 0 12 0| 0 24k| 0 0 | 0 > > > > 0 |1336 3216k| 0 7934M| 544M 56.0M 492M 6701M| 0 36 161 > > > > 172 > > > > 27-08 20:52:01| 24 64 0 0 12 0| 0 0 | 0 0 | 0 > > > > 0 |1313 3225k| 0 7934M| 544M 56.0M 492M 6701M| 0 9 107 > > > > 107 > > > > 27-08 20:52:02| 24 64 0 0 12 0| 0 0 | 0 0 | 0 > > > > 0 |1327 3224k| 0 7934M| 545M 56.0M 492M 6701M| 0 13 193 > > > > 200 > > > > 27-08 20:52:03| 24 64 0 0 12 0| 0 0 | 0 0 | 0 > > > > 0 |1311 3226k| 0 7934M| 545M 56.0M 492M 6701M| 0 13 114 > > > > 114 > > > > 27-08 20:52:04| 25 63 0 0 12 0| 0 0 | 0 0 | 0 > > > > 0 |1331 3223k| 0 7934M| 544M 56.0M 492M 6701M| 0 41 190 > > > > 178 > > > > 27-08 20:52:05| 24 64 0 0 12 0| 0 8192B| 0 0 | 0 > > > > 0 |1315 3222k| 0 7934M| 544M 56.0M 492M 6701M| 0 30 123 > > > > 122 > > > > 27-08 20:52:06| 24 64 0 0 12 0| 0 0 | 0 0 | 0 > > > > 0 |1314 3223k| 0 7934M| 544M 56.0M 492M 6701M| 0 16 187 > > > > 195 > > > > 27-08 20:52:07| 25 63 1 0 12 0|2212k 192k| 0 0 | 0 > > > > 0 |1637 3194k| 0 7934M| 544M 56.2M 494M 6699M| 0 1363 2590 > > > > 1947 > > > > 27-08 20:52:08| 17 33 18 26 6 0|3208k 0 | 0 0 | 0 > > > > 0 |1351 1766k| 0 7934M| 561M 56.3M 499M 6678M| 4 10k 7620 > > > > 2055 > > > > 27-08 20:52:09| 47 21 16 13 4 0|4332k 628k| 0 0 | 0 > > > > 0 |1400 1081k| 0 7934M| 647M 56.3M 504M 6587M| 10 24k 25k > > > > 1151 > > > > 27-08 20:52:10| 36 34 13 11 6 0|2636k 2820k| 0 0 | 0 > > > > 0 |1451 1737k| 0 7934M| 598M 56.3M 507M 6632M| 5 19k 16k > > > > 28k > > > > 27-08 20:52:11| 46 17 10 25 3 0|4288k 536k| 0 0 | 0 > > > > 0 |1386 868k| 0 7934M| 613M 56.3M 513M 6611M| 24 13k 8908 > > > > 3616 > > > > 27-08 20:52:12| 53 33 5 4 5 0|4740k 3992k| 0 0 | 0 > > > > 0 |1773 1464k| 0 7934M| 562M 56.6M 521M 6654M| 0 36k 29k > > > > 40k > > > > 27-08 20:52:13| 60 34 0 1 6 0|4228k 1416k| 0 0 | 0 > > > > 0 |1642 1670k| 0 7934M| 593M 56.6M 526M 6618M| 0 36k 26k > > > > 17k
Re: [RFC PATCH 02/14] drivers: thermal: introduce device tree parser
Hi Mark, Stephen and Pawel, On 03-09-2013 09:15, Mark Rutland wrote: > On Fri, Aug 30, 2013 at 12:19:43AM +0100, Eduardo Valentin wrote: > I think that the above can describe that, but I'd like to see a binding > document so we can consider it in more detail. Find below another proposal. It is the updated binding document, with the your comments applied (at least those I agree :-) ). It is obviously an work in progress, but I think it is getting closer to what we are trying to achieve, I believe. And of course, much better after using your suggestions. As I stated before, I believe it is crucial to first agree on the bindings, then I can go ahead and update the corresponding code. The change from the last binding examples I sent is basically on sensors and cooling devices. This time, as suggested by Mark, I am adding cooling device nodes (or at least properties to be embedded into existing nodes). At some point, I remember that Pawel was not so in favor on this type of node, but lets discuss on top of the document below. I also added the #cells properties, as needed. Hopefully we may end with an agreement. :-) So, the document would look like this: --- * Thermal Framework Device Tree descriptor Generic binding to provide a way of defining hardware thermal structure using device tree. A thermal structure includes thermal zones and their components, such as trip points, polling intervals, sensors and cooling devices binding descriptors. The target of device tree thermal descriptors is to describe only the hardware thermal aspects, not how the system must control or which algorithm or policy must be taken in place. There are five types of nodes involved to describe thermal bindings: - sensors: used to describe the device source of temperature sensing; - cooling devices: used to describe devices source of power dissipation control; - trip points: used to describe points in temperature domain defined to make the system aware of hardware limits; - cooling attachments: used to describe links between trip points and cooling devices; - thermal zones: used to describe thermal data within the hardware; It follows a description of each type of these device tree nodes. * Sensor devices Sensor devices are nodes providing temperature sensing capabilities on thermal zones. Typical devices are I2C ADC converters and bandgaps. Theses are nodes providing temperature data to thermal zones. Temperature sensor devices may control one or more internal sensors. Required property: - #sensor-cells:Used to provide sensor device specific information while referring to it. Must be at least 1, in order to identify uniquely the sensor instances within the IC. See thermal zone binding for more details on how consumers refer to sensor devices. * Cooling device nodes Cooling devices are nodes providing control on power dissipation. There are essentially two ways to provide control on power dissipation. First is by means of regulating device performance, which is known as passive cooling. Second is by means of activating devices in order to remove the dissipated heat, which is known as active cooling, e.g. regulating fan speeds. In both cases, cooling devices shall have a way to determine the level of cooling. Required property: - cooling-min-level:A unsigned integer indicating the smallest cooling level accepted. Typically 0. - cooling-max-level:An unsigned integer indicating the largest cooling level accepted. - #cooling-cells: Used to provide cooling device specific information while referring to it. Must be at least 2, in order to specify minimum and maximum cooling level used in the reference. See Cooling device attachments section below for more details on how consumers refer to cooling devices. * Trip points The trip node is a node to describe a point in the temperature domain in which the system takes an action. This node describes just the point, not the action. Required properties: - temperature: the trip temperature level, in milliCelsius. - hysteresis: a (low) hysteresis value on 'temperature'. This is a relative value, in milliCelsius. - type: the trip type. Here is the type mapping: THERMAL_TRIP_ACTIVE 0: A trip point to enable active cooling THERMAL_TRIP_PASSIVE1: A trip point to enable passive cooling THERMAL_TRIP_HOT2: A trip point to notify emergency THERMAL_TRIP_CRITICAL 3: Hardware not reliable. Refer to include/dt-bindings/thermal/thermal.h for definition of these consts. * Cooling device attachments The cooling device
Re: [PATCH v3 1/1] dcache: Translating dentry into pathname without taking rename_lock
On Fri, Sep 6, 2013 at 5:00 PM, Al Viro wrote: > > Er... what will happen if you have done just what you've described and have > a process call d_lookup()? Umm. Yes? What part of "one single path component" did you not get? To repeat: d_lookup() NEVER LOOKS UP A WHOLE PATHNAME. It looks up just a single path component. It matters not one whit whether you look up a filename that is 1500 components deep, d_lookup() only ever works on one single component. It's a single short hash chain lookup. Sure, it can fail, but people really have to work at it. You're not going to be able to make it fail by just calling "rename()" in a loop. You're going to have to do multiple threads at least, and now you need to do it on multiple different filesystems, since otherwise those multiple threads are going to be serialized by the (outer) per-filesystem vfs-layer rename semaphores. In other words, it sounds impossible to trigger, wouldn't you say? Or if you try, you're going to stand out for using a *lot* of resources. In contrast, doing the getcwd() lookup really is following potentially quite long chains. So it's quite possible that just a single thread doing rename() in a loop (on, say, /tmp, so that there isn't any IO) can trigger the sequence write-lock frequently enough that traversing 1500 d_parent entries might never complete. Have I tried it? No. But think about the two different scenarios. There really is a *big* difference between looking up one single dentry from its parent using our hash tables, and traversing a potentially almost unbounded parenthood chain. (We're bounded in practice by PATH_MAX, so you can't make getcwd() traverse more than about 2000 parents (single character filename plus the slash for each level), and for all I know filesystems might cap it before that, so it's not unbounded, but the difference between "1" and "2000" is pretty damn big) Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 4/4] X86/PCI/ACPI: Rework setup_resource() via functions ACPI resource functions
On Friday, September 06, 2013 10:24:46 AM Lan Tianyu wrote:
> Using ACPI resource functions to convert ACPI resource to generic resource
> instead of resource_to_addr(). Remove resource_to_addr().
Apart from the Bjorn's comment that this should be done for ia64 too,
it looks OK to me.
Thanks,
Rafael
> Signed-off-by: Lan Tianyu
> ---
> arch/x86/pci/acpi.c | 81
> -
> 1 file changed, 12 insertions(+), 69 deletions(-)
>
> diff --git a/arch/x86/pci/acpi.c b/arch/x86/pci/acpi.c
> index d641897..d4f85a1 100644
> --- a/arch/x86/pci/acpi.c
> +++ b/arch/x86/pci/acpi.c
> @@ -219,62 +219,15 @@ static void teardown_mcfg_map(struct pci_root_info
> *info)
> #endif
>
> static acpi_status
> -resource_to_addr(struct acpi_resource *resource,
> - struct acpi_resource_address64 *addr)
> -{
> - acpi_status status;
> - struct acpi_resource_memory24 *memory24;
> - struct acpi_resource_memory32 *memory32;
> - struct acpi_resource_fixed_memory32 *fixed_memory32;
> -
> - memset(addr, 0, sizeof(*addr));
> - switch (resource->type) {
> - case ACPI_RESOURCE_TYPE_MEMORY24:
> - memory24 = >data.memory24;
> - addr->resource_type = ACPI_MEMORY_RANGE;
> - addr->minimum = memory24->minimum;
> - addr->address_length = memory24->address_length;
> - addr->maximum = addr->minimum + addr->address_length - 1;
> - return AE_OK;
> - case ACPI_RESOURCE_TYPE_MEMORY32:
> - memory32 = >data.memory32;
> - addr->resource_type = ACPI_MEMORY_RANGE;
> - addr->minimum = memory32->minimum;
> - addr->address_length = memory32->address_length;
> - addr->maximum = addr->minimum + addr->address_length - 1;
> - return AE_OK;
> - case ACPI_RESOURCE_TYPE_FIXED_MEMORY32:
> - fixed_memory32 = >data.fixed_memory32;
> - addr->resource_type = ACPI_MEMORY_RANGE;
> - addr->minimum = fixed_memory32->address;
> - addr->address_length = fixed_memory32->address_length;
> - addr->maximum = addr->minimum + addr->address_length - 1;
> - return AE_OK;
> - case ACPI_RESOURCE_TYPE_ADDRESS16:
> - case ACPI_RESOURCE_TYPE_ADDRESS32:
> - case ACPI_RESOURCE_TYPE_ADDRESS64:
> - status = acpi_resource_to_address64(resource, addr);
> - if (ACPI_SUCCESS(status) &&
> - (addr->resource_type == ACPI_MEMORY_RANGE ||
> - addr->resource_type == ACPI_IO_RANGE) &&
> - addr->address_length > 0) {
> - return AE_OK;
> - }
> - break;
> - }
> - return AE_ERROR;
> -}
> -
> -static acpi_status
> count_resource(struct acpi_resource *acpi_res, void *data)
> {
> struct pci_root_info *info = data;
> - struct acpi_resource_address64 addr;
> - acpi_status status;
> + struct resource res;
>
> - status = resource_to_addr(acpi_res, );
> - if (ACPI_SUCCESS(status))
> + if (acpi_dev_resource_address_space(acpi_res, )
> + || acpi_dev_resource_memory(acpi_res, ))
> info->res_num++;
> +
> return AE_OK;
> }
>
> @@ -282,27 +235,18 @@ static acpi_status
> setup_resource(struct acpi_resource *acpi_res, void *data)
> {
> struct pci_root_info *info = data;
> - struct resource *res;
> + struct resource *res = >res[info->res_num];
> struct acpi_resource_address64 addr;
> - acpi_status status;
> - unsigned long flags;
> u64 start, orig_end, end;
>
> - status = resource_to_addr(acpi_res, );
> - if (!ACPI_SUCCESS(status))
> - return AE_OK;
> + memset(, 0x00, sizeof(addr));
>
> - if (addr.resource_type == ACPI_MEMORY_RANGE) {
> - flags = IORESOURCE_MEM;
> - if (addr.info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
> - flags |= IORESOURCE_PREFETCH;
> - } else if (addr.resource_type == ACPI_IO_RANGE) {
> - flags = IORESOURCE_IO;
> - } else
> + if (!(acpi_dev_resource_address_space_with_addr(acpi_res, , res)
> + || acpi_dev_resource_memory(acpi_res, res)))
> return AE_OK;
>
> - start = addr.minimum + addr.translation_offset;
> - orig_end = end = addr.maximum + addr.translation_offset;
> + start = res->start;
> + orig_end = end = res->end;
>
> /* Exclude non-addressable range or non-addressable portion of range */
> end = min(end, (u64)iomem_resource.end);
> @@ -310,6 +254,7 @@ setup_resource(struct acpi_resource *acpi_res, void *data)
> dev_info(>bridge->dev,
> "host bridge window [%#llx-%#llx] "
> "(ignored, not CPU addressable)\n", start, orig_end);
> + memset(>res[info->res_num], 0x00, sizeof(*res));
> return AE_OK;
> } else if
Re: [RFC PATCH 3/4] ACPI: Add new acpi_dev_resource_address_space_with_addr() function
On Friday, September 06, 2013 10:24:45 AM Lan Tianyu wrote:
> Make acpi_dev_resource_address_space() to accept struct
> acpi_resource_address64 as param and rename it to *_with_addr.
I'd prefer acpi_dev_resource_address_space_full() or something like this.
Apart from this it is fine by me.
Thanks,
Rafael
> This is for some cases that acpi address info is also needed
> after convert from acpi resouce to generic resource.
>
> Add acpi_devi_resource_addres_space() again as a wrapper of new
> function for original users.
>
> Signed-off-by: Lan Tianyu
> ---
> drivers/acpi/resource.c | 53
> ++---
> include/linux/acpi.h| 3 +++
> 2 files changed, 40 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 84bc3db..76da28b 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -162,19 +162,21 @@ bool acpi_dev_resource_io(struct acpi_resource *ares,
> struct resource *res)
> EXPORT_SYMBOL_GPL(acpi_dev_resource_io);
>
> /**
> - * acpi_dev_resource_address_space - Extract ACPI address space information.
> + * acpi_dev_resource_address_space_with_addr - Extract ACPI address space
> information.
> * @ares: Input ACPI resource object.
> + * @addr: Output ACPI resource address64 space object.
> * @res: Output generic resource object.
> *
> * Check if the given ACPI resource object represents an address space
> resource
> - * and if that's the case, use the information in it to populate the generic
> - * resource object pointed to by @res.
> + * and if that's the case, convert it to ACPI resource address64 space object
> + * pointed to by @addr and use the information to populate the generic
> resource
> + * object pointed to by @re.
> */
> -bool acpi_dev_resource_address_space(struct acpi_resource *ares,
> +bool acpi_dev_resource_address_space_with_addr(struct acpi_resource *ares,
> + struct acpi_resource_address64 *addr,
>struct resource *res)
> {
> acpi_status status;
> - struct acpi_resource_address64 addr;
> bool window;
> u64 len;
> u8 io_decode;
> @@ -188,29 +190,29 @@ bool acpi_dev_resource_address_space(struct
> acpi_resource *ares,
> return false;
> }
>
> - status = acpi_resource_to_address64(ares, );
> + status = acpi_resource_to_address64(ares, addr);
> if (ACPI_FAILURE(status))
> return true;
>
> - res->start = addr.minimum + addr.translation_offset;
> - res->end = addr.maximum + addr.translation_offset;
> - window = addr.producer_consumer == ACPI_PRODUCER;
> + res->start = addr->minimum + addr->translation_offset;
> + res->end = addr->maximum + addr->translation_offset;
> + window = addr->producer_consumer == ACPI_PRODUCER;
>
> - switch(addr.resource_type) {
> + switch (addr->resource_type) {
> case ACPI_MEMORY_RANGE:
> - len = addr.maximum - addr.minimum + 1;
> + len = addr->maximum - addr->minimum + 1;
> res->flags = acpi_dev_memresource_flags(len,
> - addr.info.mem.write_protect,
> + addr->info.mem.write_protect,
> window);
>
> - if (addr.info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
> + if (addr->info.mem.caching == ACPI_PREFETCHABLE_MEMORY)
> res->flags |= IORESOURCE_PREFETCH;
> break;
> case ACPI_IO_RANGE:
> - io_decode = addr.granularity == 0xfff ?
> + io_decode = addr->granularity == 0xfff ?
> ACPI_DECODE_10 : ACPI_DECODE_16;
> - res->flags = acpi_dev_ioresource_flags(addr.minimum,
> -addr.maximum,
> + res->flags = acpi_dev_ioresource_flags(addr->minimum,
> +addr->maximum,
> io_decode, window);
> break;
> case ACPI_BUS_NUMBER_RANGE:
> @@ -222,6 +224,25 @@ bool acpi_dev_resource_address_space(struct
> acpi_resource *ares,
>
> return true;
> }
> +EXPORT_SYMBOL_GPL(acpi_dev_resource_address_space_with_addr);
> +
> +/**
> + * acpi_dev_resource_address_space - Extract ACPI address space information.
> + * @ares: Input ACPI resource object.
> + * @res: Output generic resource object.
> + *
> + * Check if the given ACPI resource object represents an address space
> resource
> + * and if that's the case, use the information in it to populate the generic
> + * resource object pointed to by @res.
> + */
> +bool acpi_dev_resource_address_space(struct acpi_resource *ares,
> + struct resource *res)
> +{
> + struct acpi_resource_address64 addr;
>
Re: [RFC PATCH 2/4] ACPI/Resource: Add address translation support
On Friday, September 06, 2013 10:24:44 AM Lan Tianyu wrote:
> According ACPI 5.0 spec Section 19.1.8
> "For bridges, translate addresses across the bridge, this is the
> offset that must be added to the address on the secondary side
> to obtain the address on the primary side. Non-bridge devices
> must list 0."
Can you please have a look into the previous versions of the spec and double
check that this change won't confuse systems that implement them?
Otherwise it looks OK to me.
Thanks,
Rafael
> This patch is to add address translation offset to the start/end
> of struct resource in the acpi_dev_resource_address_space().
> Further more, non-bridge device's translation_offset should 0.
> So this change will affect other devices.
>
>
> Signed-off-by: Lan Tianyu
> ---
> drivers/acpi/resource.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c
> index 929f416..84bc3db 100644
> --- a/drivers/acpi/resource.c
> +++ b/drivers/acpi/resource.c
> @@ -192,8 +192,8 @@ bool acpi_dev_resource_address_space(struct acpi_resource
> *ares,
> if (ACPI_FAILURE(status))
> return true;
>
> - res->start = addr.minimum;
> - res->end = addr.maximum;
> + res->start = addr.minimum + addr.translation_offset;
> + res->end = addr.maximum + addr.translation_offset;
> window = addr.producer_consumer == ACPI_PRODUCER;
>
> switch(addr.resource_type) {
>
--
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 1/4] ACPI/Resource: Add memory prefetch check support
On Friday, September 06, 2013 10:24:43 AM Lan Tianyu wrote: > This patch is to check mem address space's acpi resource caching ability > and set prefetch flag of struct resource if it's prefetchable. > > Signed-off-by: Lan Tianyu Looks good to me. Thanks, Rafael > --- > drivers/acpi/resource.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/drivers/acpi/resource.c b/drivers/acpi/resource.c > index b7201fc..929f416 100644 > --- a/drivers/acpi/resource.c > +++ b/drivers/acpi/resource.c > @@ -202,6 +202,9 @@ bool acpi_dev_resource_address_space(struct acpi_resource > *ares, > res->flags = acpi_dev_memresource_flags(len, > addr.info.mem.write_protect, > window); > + > + if (addr.info.mem.caching == ACPI_PREFETCHABLE_MEMORY) > + res->flags |= IORESOURCE_PREFETCH; > break; > case ACPI_IO_RANGE: > io_decode = addr.granularity == 0xfff ? > -- I speak only for myself. Rafael J. Wysocki, Intel Open Source Technology Center. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/1] dcache: Translating dentry into pathname without taking rename_lock
On Fri, Sep 06, 2013 at 02:48:32PM -0700, Linus Torvalds wrote: > On Fri, Sep 6, 2013 at 2:05 PM, Al Viro wrote: > > > > I can take that, but I'm really not convinced that we need writer lock > > there at all. After all, if we really can get livelocks on that one, > > we would be getting them on d_lookup()... > > d_lookup() does a _single_ path component. That's a *big* difference. > > Sure, the hash chain that d_lookup() (well, __d_lookup()) ends up > walking is a bit more complicated than just following the dentry > parent pointer, but that's much harder to trigger than just creating a > really deep directory structure of single-letter nested directories, > and then doing a "getcwd()" that walks 1024+ parents, while another > thread is looping renaming things.. > > So I personally do feel a lot safer with the fallback to write locking here. > > Especially since it's pretty simple, so there isn't really much downside. Er... what will happen if you have done just what you've described and have a process call d_lookup()? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] HID for 3.12 merge window
On Fri, Sep 6, 2013 at 2:50 PM, David Herrmann wrote: > Hi > > On Fri, Sep 6, 2013 at 10:20 PM, Markus Trippelsdorf >> >> commit 61e00655e9cb82e034eb72b95a51072e718d14a7 >> Author: David Herrmann >> Date: Mon Aug 26 19:14:46 2013 +0200 >> >> Input: introduce BTN/ABS bits for drums and guitars >> >> The commit above breaks my Logitech mouse. The mouse cursor just sits in >> the middle of the screen and doesn't react to movements. dmesg is >> normal, but Xorg.0.log says: > > Ok, the issue is the kernel assumes ABS_MAX to be a power-of-2 minus 1 > (used as mask). That wasn't really obvious to me. Attached is a patch > which should fix that. Could you apply it on top of linus/master and > give it a try? Gah. I just wasted too much time bisecting down my logitech wireless keyboard not working to within a few commits of this, and decided to just try your patch. And yes, it makes my keyboard work. Dmitry, should I just apply the patch, or should we revert and use other bits? Please, this needs to be resolved, I stopped merging when I noticed this problem.. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/2] Re: Excess dmesg output from ACPIPHP on boot
On Friday, September 06, 2013 09:36:08 AM Alex Williamson wrote: > On Fri, 2013-09-06 at 15:42 +0200, Rafael J. Wysocki wrote: > > On Friday, September 06, 2013 01:36:28 AM Rafael J. Wysocki wrote: > > > On Thursday, September 05, 2013 05:08:03 PM Alex Williamson wrote: > > > > On Fri, 2013-09-06 at 00:40 +0200, Rafael J. Wysocki wrote: > > > > > On Thursday, September 05, 2013 04:17:25 PM Alex Williamson wrote: > > > > > > On Thu, 2013-09-05 at 23:39 +0200, Rafael J. Wysocki wrote: > > > > > > > On Thursday, September 05, 2013 09:44:26 PM Rafael J. Wysocki > > > > > > > wrote: > > > > > > > > On Thursday, September 05, 2013 08:21:41 AM Alex Williamson > > > > > > > > wrote: > > > > > > > > > > > > > > [...] > > > > > > > > > > > > > > > > > > > > > > > > > > > [ 18.288122] pci :00:00.0: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288127] pcieport :00:01.0: no hotplug settings > > > > > > > > > > from platform > > > > > > > > > > [ 18.288142] pci :01:00.0: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288157] pci :01:00.1: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288162] pcieport :00:03.0: no hotplug settings > > > > > > > > > > from platform > > > > > > > > > > [ 18.288176] pci :02:00.0: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288190] pci :02:00.1: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288195] pcieport :00:07.0: no hotplug settings > > > > > > > > > > from platform > > > > > > > > > > [ 18.288209] pci :03:00.0: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288224] pci :03:00.1: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288228] pci :00:14.0: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288233] pci :00:14.1: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288237] pci :00:14.2: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288242] pci :00:16.0: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288247] pci :00:16.1: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288251] pci :00:16.2: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288256] pci :00:16.3: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288260] pci :00:16.4: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288265] pci :00:16.5: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288269] pci :00:16.6: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288274] pci :00:16.7: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288278] pci :00:1a.0: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288279] pci :00:1a.0: using default PCI settings > > > > > > > > > > [ 18.288292] pci :00:1a.1: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288293] pci :00:1a.1: using default PCI settings > > > > > > > > > > [ 18.288307] ehci-pci :00:1a.7: no hotplug settings > > > > > > > > > > from platform > > > > > > > > > > [ 18.288308] ehci-pci :00:1a.7: using default PCI > > > > > > > > > > settings > > > > > > > > > > [ 18.288322] pci :00:1b.0: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288327] pcieport :00:1c.0: no hotplug settings > > > > > > > > > > from platform > > > > > > > > > > [ 18.288332] pcieport :00:1c.4: no hotplug settings > > > > > > > > > > from platform > > > > > > > > > > [ 18.288344] pci :05:00.0: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288349] pci :00:1d.0: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288350] pci :00:1d.0: using default PCI settings > > > > > > > > > > [ 18.288360] pci :00:1d.1: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288361] pci :00:1d.1: using default PCI settings > > > > > > > > > > [ 18.288374] pci :00:1d.2: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288374] pci :00:1d.2: using default PCI settings > > > > > > > > > > [ 18.288387] pci :00:1d.3: no hotplug settings from > > > > > > > > > > platform > > > > > > > > > > [ 18.288387] pci :00:1d.3: using default PCI settings > > > > > > > > > > > > > > > > > > > > The boot is noticeably slower. What's going to happen on > > > > > > > > > > systems that > > > > > > > > > > actually have a
Re: [PATCH 1/2] ACPI / hotplug / PCI: Avoid doing too much for spurious notifies
On Friday, September 06, 2013 08:46:28 AM Yinghai Lu wrote:
> On Fri, Sep 6, 2013 at 6:43 AM, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > Sometimes we may get a spurious device check or bus check notify for
> > a hotplug device and in those cases we should avoid doing all of the
> > configuration work needed when something actually changes. To that
> > end, check the return value of pci_scan_slot() in enable_slot() and
> > bail out early if it is 0.
> >
> > This turns out to help reduce the amount of diagnostic output from
> > the ACPIPHP subsystem and speed up boot on at least one system that
> > generates multiple device check notifies for PCIe ports during
> > boot.
> >
> > Reported-by: Alex Williamson
> > Signed-off-by: Rafael J. Wysocki
> > ---
> > drivers/pci/hotplug/acpiphp_glue.c | 35
> > +++
> > 1 file changed, 27 insertions(+), 8 deletions(-)
> >
> > Index: linux-pm/drivers/pci/hotplug/acpiphp_glue.c
> > ===
> > --- linux-pm.orig/drivers/pci/hotplug/acpiphp_glue.c
> > +++ linux-pm/drivers/pci/hotplug/acpiphp_glue.c
> > @@ -542,12 +542,12 @@ static void __ref enable_slot(struct acp
> > struct acpiphp_func *func;
> > int max, pass;
> > LIST_HEAD(add_list);
> > + int nr_found;
> >
> > list_for_each_entry(func, >funcs, sibling)
> > acpiphp_bus_add(func_to_handle(func));
> >
> > - pci_scan_slot(bus, PCI_DEVFN(slot->device, 0));
> > -
> > + nr_found = pci_scan_slot(bus, PCI_DEVFN(slot->device, 0));
> > max = acpiphp_max_busnr(bus);
> > for (pass = 0; pass < 2; pass++) {
> > list_for_each_entry(dev, >devices, bus_list) {
> > @@ -566,8 +566,11 @@ static void __ref enable_slot(struct acp
> > }
> > }
> > }
> > -
> > __pci_bus_assign_resources(bus, _list, NULL);
> > + /* Nothing more to do here if there are no new devices on this bus.
> > */
> > + if (!nr_found && (slot->flags & SLOT_ENABLED))
> > + return;
> > +
> > acpiphp_sanitize_bus(bus);
> > acpiphp_set_hpp_values(bus);
> > acpiphp_set_acpi_region(slot);
> >
>
> why not just returning early before size bridges and assign unassign
> resources?
Because we still need to do that even if pci_scan_slot() returns 0.
There may be new devices down in the hierarchy and we need to look for them.
Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
race condition in crypto larval handling
Hi,
I've tracked down a race condition and ref counting problem in the
crypto API internals. We've been seeing it under Chrome OS, but it
seems it's not isolated to just us:
https://code.google.com/p/chromium/issues/detail?id=244581
http://marc.info/?l=linux-crypto-vger=135429403609373=2
https://bugzilla.redhat.com/show_bug.cgi?id=983682
http://www.mail-archive.com/linux-cifs@vger.kernel.org/msg07933.html
I think I've found the basic origin of the problem.
crypto_larval_add() has synchronization to make sure only a single
larval can ever be created. That logic seems totally fine. However,
this means that crypto_larval_lookup() from two threads can return the
same larval, which means that crypto_alg_mod_lookup() runs the risk of
calling crypto_larval_kill() on the same larval twice, which does not
appear to be handled sanely.
I can easily crash the kernel by forcing a synchronization point just
before the "return crypt_larval_add(...)" call in
crypto_larval_lookup(). Basically, I added this sloppy sync code (I
feel like there must be a better way to do this):
+static atomic_t global_sync = ATOMIC_INIT(0);
...
struct crypto_alg *crypto_larval_lookup(const char *name, u32 type, u32 mask)
...
+ if (strncmp(name, "asdf", 4) == 0) {
+ int value;
+
+ value = atomic_add_return(1, _sync);
+ if (value == 1) {
+ /* I was first to stall here, wait for inc. */
+ while (atomic_read(_sync) != 2)
+ cpu_relax();
+ } else if (value == 2) {
+ /* I was second to stall here, wait for dec. */
+ while (atomic_read(_sync) != 1)
+ cpu_relax();
+ } else {
+ BUG();
+ }
+ atomic_dec(_sync);
+ }
return crypto_larval_add(name, type, mask);
}
And then ran code from userspace that did, effectively:
struct sockaddr_alg sa = {
.salg_family = AF_ALG,
.salg_type = "hash",
};
strcpy(sa.salg_name, argv[1]);
fork();
...
sds[0] = socket(AF_ALG, SOCK_SEQPACKET, 0);
bind(sds[0], (struct sockaddr *) , sizeof(sa));
And ran this as "./tickle asdf1" to generate the two threads trying to
find an invalid alg. The race looks possible even with valid algs, but
this was the fastest path I could see to tickle the issue.
With added printks to the kernel, it was clear that crypto_larval_kill
was being called twice on the same larval, and the list_del() call was
doing bad things. When I fixed that, the refcnt bug became very
obvious. Here's the change I made for crypto_larval_kill:
@@ -161,7 +166,8 @@ void crypto_larval_kill(struct crypto_alg *alg)
struct crypto_larval *larval = (void *)alg;
down_write(_alg_sem);
- list_del(>cra_list);
+ if (!list_empty(>cra_list))
+ list_del_init(>cra_list);
up_write(_alg_sem);
complete_all(>completion);
crypto_alg_put(alg);
It seems that there are too many "put" calls (mixed between
crypto_alg_put() and crypto_mod_put(), which also calls
crypto_alg_put()). See this annotated portion of
crypto_alg_mod_lookup:
/* This can (correctly) return the same larval for two threads. */
larval = crypto_larval_lookup(name, type, mask);
if (IS_ERR(larval) || !crypto_is_larval(larval))
return larval;
ok = crypto_probing_notify(CRYPTO_MSG_ALG_REQUEST, larval);
if (ok == NOTIFY_STOP)
/* This calls crypto_mod_put(), but sometimes also get?? */
alg = crypto_larval_wait(larval);
else {
/* This directly calls crypto_mod_put */
crypto_mod_put(larval);
alg = ERR_PTR(-ENOENT);
}
/* This calls crypto_alg_put */
crypto_larval_kill(larval);
return alg;
In the two-thread situation, the first thread gets a larval with
refcnt 2 via crypto_larval_add. (Why 2?) The next thread finds the
larval via crypto_larval_add's call to __crypto_alg_lookup() and sees
the ref bump to 3. While exiting crypto_alg_mod_lookup, each thread
decrements the ref count twice.
It seems to me like either each call to crypto_larval_lookup() should
result in a refcount bumped by two, or crypto_alg_mod_lookup() should
decrement only once, and the initial refcount should be 1 not 2 from
crypto_larval_add. But it's not clear to me which is sensible here.
What's the right solution here?
Thanks,
-Kees
--
Kees Cook
Chrome OS Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] Input: add driver for Neonode zForce based touchscreens
This adds a driver for touchscreens using the zforce infrared
technology from Neonode connected via i2c to the host system.
It supports multitouch with up to two fingers and tracking of the
contacts in hardware.
Signed-off-by: Heiko Stuebner
---
changes since v1:
- address comments from Dmitry Torokhov
but I kept the access_mutex due to the possible race I described in the mail:
- touch -> interrupt
- isr reads first packet
- user closes device -> stop command sent
- isr reads payload
- address comments from Henrik Rydberg, letting the input system collect
singletouch from the multitouch data using the appropriate functions
drivers/input/touchscreen/Kconfig | 13 +
drivers/input/touchscreen/Makefile |1 +
drivers/input/touchscreen/zforce_ts.c | 826 +++
include/linux/platform_data/zforce_ts.h | 26 +
4 files changed, 866 insertions(+)
create mode 100644 drivers/input/touchscreen/zforce_ts.c
create mode 100644 include/linux/platform_data/zforce_ts.h
diff --git a/drivers/input/touchscreen/Kconfig
b/drivers/input/touchscreen/Kconfig
index 3b9758b..ade11b7 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -919,4 +919,17 @@ config TOUCHSCREEN_TPS6507X
To compile this driver as a module, choose M here: the
module will be called tps6507x_ts.
+config TOUCHSCREEN_ZFORCE
+ tristate "Neonode zForce infrared touchscreens"
+ depends on I2C
+ depends on GPIOLIB
+ help
+ Say Y here if you have a touchscreen using the zforce
+ infraread technology from Neonode.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called zforce_ts.
+
endif
diff --git a/drivers/input/touchscreen/Makefile
b/drivers/input/touchscreen/Makefile
index f5216c1..7587883 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -75,3 +75,4 @@ obj-$(CONFIG_TOUCHSCREEN_WM97XX_MAINSTONE)+=
mainstone-wm97xx.o
obj-$(CONFIG_TOUCHSCREEN_WM97XX_ZYLONITE) += zylonite-wm97xx.o
obj-$(CONFIG_TOUCHSCREEN_W90X900) += w90p910_ts.o
obj-$(CONFIG_TOUCHSCREEN_TPS6507X) += tps6507x-ts.o
+obj-$(CONFIG_TOUCHSCREEN_ZFORCE) += zforce_ts.o
diff --git a/drivers/input/touchscreen/zforce_ts.c
b/drivers/input/touchscreen/zforce_ts.c
new file mode 100644
index 000..f4cfd4d
--- /dev/null
+++ b/drivers/input/touchscreen/zforce_ts.c
@@ -0,0 +1,826 @@
+/*
+ * Copyright (C) 2012-2013 MundoReader S.L.
+ * Author: Heiko Stuebner
+ *
+ * based in parts on Nook zforce driver
+ *
+ * Copyright (C) 2010 Barnes & Noble, Inc.
+ * Author: Pieter Truter
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define WAIT_TIMEOUT msecs_to_jiffies(1000)
+
+#define FRAME_START0xee
+
+/* Offsets of the different parts of the payload the controller sends */
+#define PAYLOAD_HEADER 0
+#define PAYLOAD_LENGTH 1
+#define PAYLOAD_BODY 2
+
+/* Response offsets */
+#define RESPONSE_ID0
+#define RESPONSE_DATA 1
+
+/* Commands */
+#define COMMAND_DEACTIVATE 0x00
+#define COMMAND_INITIALIZE 0x01
+#define COMMAND_RESOLUTION 0x02
+#define COMMAND_SETCONFIG 0x03
+#define COMMAND_DATAREQUEST0x04
+#define COMMAND_SCANFREQ 0x08
+#define COMMAND_STATUS 0X1e
+
+/*
+ * Responses the controller sends as a result of
+ * command requests
+ */
+#define RESPONSE_DEACTIVATE0x00
+#define RESPONSE_INITIALIZE0x01
+#define RESPONSE_RESOLUTION0x02
+#define RESPONSE_SETCONFIG 0x03
+#define RESPONSE_SCANFREQ 0x08
+#define RESPONSE_STATUS0X1e
+
+/*
+ * Notifications are send by the touch controller without
+ * being requested by the driver and include for example
+ * touch indications
+ */
+#define NOTIFICATION_TOUCH 0x04
+#define NOTIFICATION_BOOTCOMPLETE 0x07
+#define NOTIFICATION_OVERRUN 0x25
+#define NOTIFICATION_PROXIMITY 0x26
+#define NOTIFICATION_INVALID_COMMAND 0xfe
+
+#define ZFORCE_REPORT_POINTS 2
+#define ZFORCE_MAX_AREA0xff
+
+#define STATE_DOWN 0
+#define STATE_MOVE 1
+#define STATE_UP 2
+
+#define SETCONFIG_DUALTOUCH(1 << 0)
+
+struct zforce_point {
+ int coord_x;
+ int
Re: [GIT] HID for 3.12 merge window
On Sat, Sep 07, 2013 at 12:51:27AM +0200, David Herrmann wrote: > Hi > > On Fri, Sep 6, 2013 at 11:59 PM, Markus Trippelsdorf > wrote: > > On 2013.09.06 at 23:50 +0200, David Herrmann wrote: > >> Hi > >> > >> On Fri, Sep 6, 2013 at 10:20 PM, Markus Trippelsdorf > >> wrote: > >> > On 2013.09.06 at 14:00 +0200, Jiri Kosina wrote: > >> >> > >> >> David Herrmann (12): > >> > ... > >> >> HID: wiimote: add support for Guitar-Hero drums > >> > > >> > commit 61e00655e9cb82e034eb72b95a51072e718d14a7 > >> > Author: David Herrmann > >> > Date: Mon Aug 26 19:14:46 2013 +0200 > >> > > >> > Input: introduce BTN/ABS bits for drums and guitars > >> > > >> > The commit above breaks my Logitech mouse. The mouse cursor just sits in > >> > the middle of the screen and doesn't react to movements. dmesg is > >> > normal, but Xorg.0.log says: > >> > >> Ok, the issue is the kernel assumes ABS_MAX to be a power-of-2 minus 1 > >> (used as mask). That wasn't really obvious to me. Attached is a patch > >> which should fix that. Could you apply it on top of linus/master and > >> give it a try? > > > > Your patch fixes the issue. Thanks. > > Thanks a lot for reporting+testing! > > I am still not sure how to solve the EVIOCSABS thingy. Problem is, > it's defined as: > #define EVIOCSABS(_abs) ...0xc0 + (_abs)... > But if (_abs > 0x3f) this will be bigger than 0xff. Unfortunately, the > upper part of the ioctl is defined as 'E' which is 0x45 in hex and > thus sets the LSB. That means we cannot extend the _IOC_TYPE field to > the upper region (which would cause endian-issues, anyway). I guess > we're screwed here and need to revert that... > > Dmitry, any comment on this? Or am I missing something? We have gaps below ABS_MT constants, I think for 3.12 you could move your whammy there and revert ABS_MAX change, but we need to plan for expanding it in the future. Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] mfd: tps6586x: implement irq_set_wake
From: Stephen Warren
rtc-tps6586x calls enable/disable_irq_wake() during suspend/resume. Since
the main tps6586x irq_chip doesn't implement .irq_set_wake, this causes
the RTC's enable_irq_wake() to fail, and the disable_irq_wake() to spew a
WARN about unbalanced wake disable. Solve this by implementing
.irq_set_wake.
Also, I assume that enable_irq_wake() shouldn't be called unconditionally
in tps6586x_irq_init(), since this is now triggered by IRQ children
setting up their cascaded IRQs for wake. So, remove that.
Signed-off-by: Stephen Warren
---
I'm tempted to Cc stable here, since this bug is certainly present in
older kernel releases. However, the only user-visible aspect is the WARN
on resume, so I'm not sure if it's worth it?
---
drivers/mfd/tps6586x.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/mfd/tps6586x.c b/drivers/mfd/tps6586x.c
index f54fe4d..68906b1 100644
--- a/drivers/mfd/tps6586x.c
+++ b/drivers/mfd/tps6586x.c
@@ -124,6 +124,7 @@ struct tps6586x {
struct i2c_client *client;
struct regmap *regmap;
+ int irq;
struct irq_chip irq_chip;
struct mutexirq_lock;
int irq_base;
@@ -261,12 +262,23 @@ static void tps6586x_irq_sync_unlock(struct irq_data
*data)
mutex_unlock(>irq_lock);
}
+#ifdef CONFIG_PM_SLEEP
+static int tps6586x_irq_set_wake(struct irq_data *irq_data, unsigned int on)
+{
+ struct tps6586x *tps6586x = irq_data_get_irq_chip_data(irq_data);
+ return irq_set_irq_wake(tps6586x->irq, on);
+}
+#else
+#define tps6586x_irq_set_wake NULL
+#endif
+
static struct irq_chip tps6586x_irq_chip = {
.name = "tps6586x",
.irq_bus_lock = tps6586x_irq_lock,
.irq_bus_sync_unlock = tps6586x_irq_sync_unlock,
.irq_disable = tps6586x_irq_disable,
.irq_enable = tps6586x_irq_enable,
+ .irq_set_wake = tps6586x_irq_set_wake,
};
static int tps6586x_irq_map(struct irq_domain *h, unsigned int virq,
@@ -331,6 +343,8 @@ static int tps6586x_irq_init(struct tps6586x *tps6586x, int
irq,
int new_irq_base;
int irq_num = ARRAY_SIZE(tps6586x_irqs);
+ tps6586x->irq = irq;
+
mutex_init(>irq_lock);
for (i = 0; i < 5; i++) {
tps6586x->mask_reg[i] = 0xff;
@@ -360,10 +374,8 @@ static int tps6586x_irq_init(struct tps6586x *tps6586x,
int irq,
ret = request_threaded_irq(irq, NULL, tps6586x_irq, IRQF_ONESHOT,
"tps6586x", tps6586x);
- if (!ret) {
+ if (!ret)
device_init_wakeup(tps6586x->dev, 1);
- enable_irq_wake(irq);
- }
return ret;
}
--
1.8.1.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: [ 00/14] 3.4.61-stable review
On 09/06/2013 05:11 PM, Greg Kroah-Hartman wrote: On Fri, Sep 06, 2013 at 04:23:16PM -0600, Shuah Khan wrote: On 09/06/2013 12:46 PM, Greg Kroah-Hartman wrote: On Fri, Sep 06, 2013 at 11:47:01AM -0600, Shuah Khan wrote: On 09/05/2013 02:28 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.4.61 release. There are 14 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Sep 7 20:25:41 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.61-rc1.gz and the diffstat can be found below. thanks, greg k-h - 3.4.61-rc1 applied cleanly to 3.4.60 Compiled and booted on the following systems: Samsung Series 9 900X4C Intel Corei5 HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics dmesgs look good. No regressions compared to the previous dmesgs for this release. dmesg emerg, crit, alert, err are clean. No regressions in warn. Thanks for testing and letting me know. Compile tested on Samsung Chromebook Exynos5 (ARMv7): 3.4.60 compile fail - it is not a regression. Existing issue in 3.4.y It has to do with missing config selections in arch/arm/mach-exynos/Kconfig for this system. Debugging now using the Kconfig selections from 3.10.y for this file. Is there a patch I can backport for this to work properly? I'd like to get some type of ARM coverage if possible. thanks, greg k-h Greg, I did some debugging and found 3.4 needs several patches to that made exynos4 support common for exynos4 and exynos5. It appears some changes made it into 3.4, at least changing the directory name from mach-exynos4 to mach-exynos, however the rest of the support is not in 3.4. I identified the following commits: 6f9e95e6ed34ceff090ec1a1d27dfc85828d1dbd 60e49ca654eea42e04912b259fa36bad2c3e56ef 20ef9e08d27b3f5e09c32d4d371fa97f610a3069 Those three are "reasonable". Cool. I will pull just these 3 patches and see if that works and let you know if it works. b1b3f49ce4606452279b58b17f2bbe2ba00304b That just reorders the config options, is that really needed? So, with those first 3 patches, does the kernel now work on that platform for you? thanks, greg k-h Yes the last one b1b3f49ce4606452279b58b17f2bbe2ba00304b, is a reordering patch. -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 00/14] 3.4.61-stable review
On Fri, Sep 06, 2013 at 04:23:16PM -0600, Shuah Khan wrote: > On 09/06/2013 12:46 PM, Greg Kroah-Hartman wrote: > >On Fri, Sep 06, 2013 at 11:47:01AM -0600, Shuah Khan wrote: > >>On 09/05/2013 02:28 PM, Greg Kroah-Hartman wrote: > >>>This is the start of the stable review cycle for the 3.4.61 release. > >>>There are 14 patches in this series, all will be posted as a response > >>>to this one. If anyone has any issues with these being applied, please > >>>let me know. > >>> > >>>Responses should be made by Sat Sep 7 20:25:41 UTC 2013. > >>>Anything received after that time might be too late. > >>> > >>>The whole patch series can be found in one patch at: > >>> kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.61-rc1.gz > >>>and the diffstat can be found below. > >>> > >>>thanks, > >>> > >>>greg k-h > >>> > >>>- > >> > >> > >>3.4.61-rc1 applied cleanly to 3.4.60 > >> > >>Compiled and booted on the following systems: > >> > >>Samsung Series 9 900X4C Intel Corei5 > >>HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics > >> > >>dmesgs look good. No regressions compared to the previous dmesgs for > >>this release. dmesg emerg, crit, alert, err are clean. No > >>regressions in warn. > > > >Thanks for testing and letting me know. > > > >>Compile tested on Samsung Chromebook Exynos5 (ARMv7): > >>3.4.60 compile fail - it is not a regression. Existing issue in > >>3.4.y It has to do with missing config selections in > >>arch/arm/mach-exynos/Kconfig for this system. Debugging now using > >>the Kconfig selections from 3.10.y for this file. > > > >Is there a patch I can backport for this to work properly? I'd like to > >get some type of ARM coverage if possible. > > > >thanks, > > > >greg k-h > > > > Greg, > > I did some debugging and found 3.4 needs several patches to that > made exynos4 support common for exynos4 and exynos5. It appears some > changes made it into 3.4, at least changing the directory name from > mach-exynos4 to mach-exynos, however the rest of the support is not > in 3.4. I identified the following commits: > > 6f9e95e6ed34ceff090ec1a1d27dfc85828d1dbd > 60e49ca654eea42e04912b259fa36bad2c3e56ef > 20ef9e08d27b3f5e09c32d4d371fa97f610a3069 Those three are "reasonable". > b1b3f49ce4606452279b58b17f2bbe2ba00304b That just reorders the config options, is that really needed? So, with those first 3 patches, does the kernel now work on that platform for you? thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/6] PCI/MSI: Factor out pci_get_msi_cap() interface
On Fri, Sep 06, 2013 at 12:06:21PM -0400, Tejun Heo wrote: > Hello, Bjorn. > > On Fri, Sep 06, 2013 at 10:01:38AM -0600, Bjorn Helgaas wrote: > > Sorry, I haven't jumped in here yet because I saw your discussion and > > was hoping you guys would figure something out without my help. It > > will take me a few hours to look into this and come up with anything > > constructive to say. > > > > I do remember disliking the complicated interface of > > pci_enable_msi_block() (return negative errno, return positive "we > > might be able to do this" values, or zero), but I'll have to do some > > more research before I can say much more than that. > > According to Alexander, it doesn't even seem like we have any actual > use case for the positive return numbers. I say just rip it out and > do the regular 0/-errno all the way through. I agree, that would be much simpler. I propose that you rework it that way, and at least find out what (if anything) would break if we do that. Or maybe we just give up some optimization; it would be nice to quantify that, too. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] HID for 3.12 merge window
Hi On Fri, Sep 6, 2013 at 11:59 PM, Markus Trippelsdorf wrote: > On 2013.09.06 at 23:50 +0200, David Herrmann wrote: >> Hi >> >> On Fri, Sep 6, 2013 at 10:20 PM, Markus Trippelsdorf >> wrote: >> > On 2013.09.06 at 14:00 +0200, Jiri Kosina wrote: >> >> >> >> David Herrmann (12): >> > ... >> >> HID: wiimote: add support for Guitar-Hero drums >> > >> > commit 61e00655e9cb82e034eb72b95a51072e718d14a7 >> > Author: David Herrmann >> > Date: Mon Aug 26 19:14:46 2013 +0200 >> > >> > Input: introduce BTN/ABS bits for drums and guitars >> > >> > The commit above breaks my Logitech mouse. The mouse cursor just sits in >> > the middle of the screen and doesn't react to movements. dmesg is >> > normal, but Xorg.0.log says: >> >> Ok, the issue is the kernel assumes ABS_MAX to be a power-of-2 minus 1 >> (used as mask). That wasn't really obvious to me. Attached is a patch >> which should fix that. Could you apply it on top of linus/master and >> give it a try? > > Your patch fixes the issue. Thanks. Thanks a lot for reporting+testing! I am still not sure how to solve the EVIOCSABS thingy. Problem is, it's defined as: #define EVIOCSABS(_abs) ...0xc0 + (_abs)... But if (_abs > 0x3f) this will be bigger than 0xff. Unfortunately, the upper part of the ioctl is defined as 'E' which is 0x45 in hex and thus sets the LSB. That means we cannot extend the _IOC_TYPE field to the upper region (which would cause endian-issues, anyway). I guess we're screwed here and need to revert that... Dmitry, any comment on this? Or am I missing something? Regards 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] PCI: add quirk for 3ware 9650SE controller
On Fri, Sep 6, 2013 at 3:51 AM, Jiri Kosina wrote:
> On Wed, 28 Aug 2013, Bjorn Helgaas wrote:
>
>> [+cc another email addr for Adam from git logs]
>
> Thanks. Adam, would you happen to have any possible explanation /
> background?
>
>> >> > Commit d5dea7d95 ("PCI: msi: Disable msi interrupts when we initialize a
>> >> > pci device") makes MSIs be forcibly disabled at boot time.
>> >> >
>> >> > It turns out that this breaks 3ware controller -- if MSIs are disabled
>> >> > during PCI discovery of this controller, the device doesn't work
>> >> > properly
>> >> > (it doesn't respond to any commands that are being sent to it after
>> >> > initialization).
Is there a bug report for this issue? It's nice to have a pointer to,
e.g., a bugzilla.kernel.org bug report with info such as dmesg logs,
lspci output, etc., for future reference. Maybe somebody will figure
out a more generic change that could make this quirk unnecessary, and
details will help in figuring that out.
I assume the actual PCI discovery done in the PCI core works fine;
it's just that the driver doesn't work if MSIs are disabled on the
device. If that's the case, can this be fixed by some driver change?
Maybe the driver needs to enable MSI before it sends commands to the
device?
Any description of what this failure looks like to a user? How can a
user or a distro connect a symptom (driver timeout, console message,
or whatever) to this patch?
>> >> > Reverting d5dea7d95 or not force-disabling MSIs in
>> >> > pci_msi_init_pci_dev()
>> >> > makes the device work properly again.
>> >> >
>> >> > Signed-off-by: Jiri Kosina
>> >> >
>> >> > ---
>> >> >
>> >> > I am adding Adam Radford as a recepient as well, to see whether he is
>> >> > able
>> >> > to provide some more explanation why this device would expose this
>> >> > behavior.
>> >
>> > OK, so Adam Radford's lsi.com address is bouncing, hence I guess we can't
>> > expect any feedback from him.
>> >
>> > Bjorn, Jesse, any word on this please?
>>
>> It's on my list to look at. It's too late to put it in for v3.11, and
>> it's doubtful that it will even make the v3.12 merge window (though
>> possibly it could go in post-merge window). d5dea7d95 is several
>> years old, so hopefully this issue isn't super-urgent. Let me know if
>> otherwise.
>
> I agree that this should be applicable to 3.12-rcX as well, as it's very
> device-specific.
>
> Thanks.
>
>>
>> Bjorn
>>
>> >> > drivers/pci/msi.c|3 +++
>> >> > drivers/pci/quirks.c | 10 ++
>> >> > include/linux/pci.h |1 +
>> >> > 3 files changed, 14 insertions(+), 0 deletions(-)
>> >> >
>> >> > diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
>> >> > index aca7578..4f36b8b 100644
>> >> > --- a/drivers/pci/msi.c
>> >> > +++ b/drivers/pci/msi.c
>> >> > @@ -1040,6 +1040,9 @@ void pci_msi_init_pci_dev(struct pci_dev *dev)
>> >> > {
>> >> > INIT_LIST_HEAD(>msi_list);
>> >> >
>> >> > + if (dev->broken_msi_disable)
>> >> > + return;
>> >> > +
>> >> > /* Disable the msi hardware to avoid screaming interrupts
>> >> > * during boot. This is the power on reset default so
>> >> > * usually this should be a noop.
>> >> > diff --git a/drivers/pci/quirks.c b/drivers/pci/quirks.c
>> >> > index e85d230..4ba3400 100644
>> >> > --- a/drivers/pci/quirks.c
>> >> > +++ b/drivers/pci/quirks.c
>> >> > @@ -2890,6 +2890,16 @@ static void quirk_intel_ntb(struct pci_dev *dev)
>> >> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0e08, quirk_intel_ntb);
>> >> > DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x0e0d, quirk_intel_ntb);
>> >> >
>> >> > +/*
>> >> > + * 3ware 9650SE controller doesn't properly initialize if MSI are
>> >> > + * disabled on it during PCI device discovery
>> >> > + */
>> >> > +static void quirk_broken_msi_disable(struct pci_dev *dev)
>> >> > +{
>> >> > + dev->broken_msi_disable = 1;
>> >> > +}
>> >> > +DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_3WARE, 0x1004,
>> >> > quirk_broken_msi_disable);
>> >> > +
>> >> > static ktime_t fixup_debug_start(struct pci_dev *dev,
>> >> > void (*fn)(struct pci_dev *dev))
>> >> > {
>> >> > diff --git a/include/linux/pci.h b/include/linux/pci.h
>> >> > index 0fd1f15..c327d74 100644
>> >> > --- a/include/linux/pci.h
>> >> > +++ b/include/linux/pci.h
>> >> > @@ -341,6 +341,7 @@ struct pci_dev {
>> >> > #ifdef CONFIG_PCI_MSI
>> >> > struct list_head msi_list;
>> >> > struct kset *msi_kset;
>> >> > + unsigned intbroken_msi_disable:1;
>> >> > #endif
>> >> > struct pci_vpd *vpd;
>> >> > #ifdef CONFIG_PCI_ATS
>> >> >
>> >> > --
>> >> > Jiri Kosina
>> >> > SUSE Labs
>> >> >
>> >>
>> >> --
>> >> Jiri Kosina
>> >> SUSE Labs
>> >>
>> >
>> > --
>> > Jiri Kosina
>> > SUSE Labs
>>
>
> --
> Jiri Kosina
> 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
Re: [PATCH 2/5] arm: LLVMLinux: use current_stack_pointer for percpu
beh...@converseincode.com writes:
> From: Behan Webster
>
> The existing code uses named registers to get the value of the stack pointer.
> The new current_stack_pointer macro is more readable and allows for a central
> portable implementation of how to get the stack pointer with ASM. This change
> supports being able to compile the kernel with both gcc and Clang.
>
> Signed-off-by: Mark Charlebois
> Signed-off-by: Behan Webster
> Reviewed-by: Jan-Simon Möller
> ---
> arch/arm/include/asm/percpu.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/percpu.h b/arch/arm/include/asm/percpu.h
> index 209e650..629a975 100644
> --- a/arch/arm/include/asm/percpu.h
> +++ b/arch/arm/include/asm/percpu.h
> @@ -30,14 +30,14 @@ static inline void set_my_cpu_offset(unsigned long off)
> static inline unsigned long __my_cpu_offset(void)
> {
> unsigned long off;
> - register unsigned long *sp asm ("sp");
> + unsigned long sp = current_stack_pointer;
>
> /*
>* Read TPIDRPRW.
>* We want to allow caching the value, so avoid using volatile and
>* instead use a fake stack read to hazard against barrier().
>*/
> - asm("mrc p15, 0, %0, c13, c0, 4" : "=r" (off) : "Q" (*sp));
> + asm("mrc p15, 0, %0, c13, c0, 4" : "=r" (off) : "Q" (sp));
This doesn't do quite the same thing. The existing code pretends to
read something from the stack in order to create a barrier of some
sort. Your new code stores the value of the stack pointer to a location
on the stack for consumption by the "Q" memory constraint. This store
is not necessary and should preferably be avoided.
--
Måns Rullgård
m...@mansr.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 2/5] arm: LLVMLinux: use current_stack_pointer for percpu
On Fri, Sep 06, 2013 at 05:28:08PM -0400, beh...@converseincode.com wrote:
> From: Behan Webster
>
> The existing code uses named registers to get the value of the stack pointer.
> The new current_stack_pointer macro is more readable and allows for a central
> portable implementation of how to get the stack pointer with ASM. This change
> supports being able to compile the kernel with both gcc and Clang.
>
> Signed-off-by: Mark Charlebois
> Signed-off-by: Behan Webster
> Reviewed-by: Jan-Simon Möller
> ---
> arch/arm/include/asm/percpu.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/include/asm/percpu.h b/arch/arm/include/asm/percpu.h
> index 209e650..629a975 100644
> --- a/arch/arm/include/asm/percpu.h
> +++ b/arch/arm/include/asm/percpu.h
> @@ -30,14 +30,14 @@ static inline void set_my_cpu_offset(unsigned long off)
> static inline unsigned long __my_cpu_offset(void)
> {
> unsigned long off;
> - register unsigned long *sp asm ("sp");
> + unsigned long sp = current_stack_pointer;
>
> /*
>* Read TPIDRPRW.
>* We want to allow caching the value, so avoid using volatile and
>* instead use a fake stack read to hazard against barrier().
>*/
> - asm("mrc p15, 0, %0, c13, c0, 4" : "=r" (off) : "Q" (*sp));
> + asm("mrc p15, 0, %0, c13, c0, 4" : "=r" (off) : "Q" (sp));
This looks like it's breaking what's going on here. With the original
code, we're passing the contents of the word at the stack pointer into
the assembly via a "Q" constraint. After this change, we're passing
the _value_ of the stack pointer.
Also, if you read the comment, it's certainly 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 1/5] arm: LLVMLinux: Add current_stack_pointer macro for ARM
On Fri, Sep 06, 2013 at 05:28:07PM -0400, beh...@converseincode.com wrote: > From: Behan Webster > > A macro to get the current stack pointer which allows for a single place in > which to do so with ASM. Before this named registers (a gcc extension) was > used > to get the stack pointer. Using ASM is a more portable way of getting the > stack > pointer which works with both gcc and clang. This macro is of the same name > used in the X86 arch. This will result in less optimal code - rather than the compiler being able to mask directly with 'sp', it's going to have to use this bit of assembly to first move it into another register. Why do we want this change? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 1/6] scsi/bfa: use pcie_set/get_readrq to simplify code
On Thu, Sep 05, 2013 at 03:55:25PM +0800, Yijing Wang wrote:
> v1->v2: use pcie_get/set_readrq to simplify code
> a lot suggestd by Bjorn.
>
> Use pcie_get_readrq()/pcie_set_readrq() to simplify
> code.
>
> Signed-off-by: Yijing Wang
> Cc: Jiang Liu
> Cc: Anil Gurumurthy
> Cc: Vijaya Mohan Guvva
> Cc: "James E.J. Bottomley"
> Cc: linux-s...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> drivers/scsi/bfa/bfad.c | 48 +-
> 1 files changed, 6 insertions(+), 42 deletions(-)
I applied all these with some tweaks to my pci/yijing-pci_is_pcie-v2
branch [1]. This will be rebased after v3.12-rc1, and may be amended
if any patches are picked up by others.
Hints (not just for you; I hope other people pay attention, too,
because I'm obsessive and I pay attention to these details):
- Include a "[PATCH v2 0/6]" email. That's a good place for you to
put an overall description of the series, and a good place for
responses like this one that apply to the whole series.
- Pay attention to the order of your patches. Yours seemed random,
and I reordered them so the core PCI ones are first and the arch
and driver ones are later. That way I can easily drop the later
ones if they are picked up by other maintainers.
- Don't put "v1->v2" comments in your changelogs. Those are fine
in the "[0/6]" email, but they're useless in the git changelog, and
I strip them out when I see them. Or you can put them after the
"---" line, in which case they get stripped out automatically.
- Run "git log --oneline" on the files you touch. You should follow
the existing convention, including spacing, brackets, capitalization,
etc. I changed most of your subject lines for this reason.
- Write titles that are sentences, starting with a verb, as suggested
by Ingo [2]. You did this already; I just made changes for
consistency of capitalization and the like.
- Use real function names, not things like "pcie_capability_xxx".
That makes it easier to search logs.
- Be consistent about writing function names. Some of your logs
included, e.g., both "pci_bus_set_ops" and "dev_info()". I prefer
to always include the parentheses when writing a function name,
but at least be consistent.
- Don't put "Cc: " in your changelog. That tag is
useful to show that a *person* has had the opportunity to comment
on a patch but declined to do so. I don't think it's meaningful
for mailing lists. If it were, every single commit would have
that tag, since every single commit should appear on the relevant
list. I suspect you probably do this so that something like
"git send-email --signed-off-by-cc" will automatically send mail
to the right lists. But that's a one-time convenience at the
cost of useless info in the changelog that's there forever.
- Put Signed-off-by, Acked-by, etc., tags in this order as suggested
by Ingo [2]:
Reported-by:
Tested-by:
Signed-off-by:
Acked-by:
Reviewed-by:
Cc: sta...@vger.kernel.org # v3.11+
Cc: others
[1]
http://git.kernel.org/cgit/linux/kernel/git/helgaas/pci.git/log/?h=pci/yijing-pci_is_pcie-v2
[2] http://lkml.kernel.org/r/20120711080446.ga17...@gmail.com
> diff --git a/drivers/scsi/bfa/bfad.c b/drivers/scsi/bfa/bfad.c
> index f8ca7be..0a458db 100644
> --- a/drivers/scsi/bfa/bfad.c
> +++ b/drivers/scsi/bfa/bfad.c
> @@ -766,50 +766,14 @@ bfad_pci_init(struct pci_dev *pdev, struct bfad_s *bfad)
> bfad->pcidev = pdev;
>
> /* Adjust PCIe Maximum Read Request Size */
> - if (pcie_max_read_reqsz > 0) {
> - int pcie_cap_reg;
> - u16 pcie_dev_ctl;
> - u16 mask = 0x;
> -
> - switch (pcie_max_read_reqsz) {
> - case 128:
> - mask = 0x0;
> - break;
> - case 256:
> - mask = 0x1000;
> - break;
> - case 512:
> - mask = 0x2000;
> - break;
> - case 1024:
> - mask = 0x3000;
> - break;
> - case 2048:
> - mask = 0x4000;
> - break;
> - case 4096:
> - mask = 0x5000;
> - break;
> - default:
> - break;
> - }
> -
> - pcie_cap_reg = pci_find_capability(pdev, PCI_CAP_ID_EXP);
> - if (mask != 0x && pcie_cap_reg) {
> - pcie_cap_reg += 0x08;
> - pci_read_config_word(pdev, pcie_cap_reg, _dev_ctl);
> - if ((pcie_dev_ctl & 0x7000) != mask) {
> - printk(KERN_WARNING "BFA[%s]: "
> + if (pcie_max_read_reqsz > 0 && pci_is_pcie(pdev)) {
> + int max_rq = pcie_get_readrq(pdev);
> +
Re: [ 00/14] 3.4.61-stable review
On 09/06/2013 12:46 PM, Greg Kroah-Hartman wrote: On Fri, Sep 06, 2013 at 11:47:01AM -0600, Shuah Khan wrote: On 09/05/2013 02:28 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.4.61 release. There are 14 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sat Sep 7 20:25:41 UTC 2013. Anything received after that time might be too late. The whole patch series can be found in one patch at: kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.4.61-rc1.gz and the diffstat can be found below. thanks, greg k-h - 3.4.61-rc1 applied cleanly to 3.4.60 Compiled and booted on the following systems: Samsung Series 9 900X4C Intel Corei5 HP ProBook 6475b AMD A10-4600M APU with Radeon(tm) HD Graphics dmesgs look good. No regressions compared to the previous dmesgs for this release. dmesg emerg, crit, alert, err are clean. No regressions in warn. Thanks for testing and letting me know. Compile tested on Samsung Chromebook Exynos5 (ARMv7): 3.4.60 compile fail - it is not a regression. Existing issue in 3.4.y It has to do with missing config selections in arch/arm/mach-exynos/Kconfig for this system. Debugging now using the Kconfig selections from 3.10.y for this file. Is there a patch I can backport for this to work properly? I'd like to get some type of ARM coverage if possible. thanks, greg k-h Greg, I did some debugging and found 3.4 needs several patches to that made exynos4 support common for exynos4 and exynos5. It appears some changes made it into 3.4, at least changing the directory name from mach-exynos4 to mach-exynos, however the rest of the support is not in 3.4. I identified the following commits: 6f9e95e6ed34ceff090ec1a1d27dfc85828d1dbd 60e49ca654eea42e04912b259fa36bad2c3e56ef 20ef9e08d27b3f5e09c32d4d371fa97f610a3069 b1b3f49ce4606452279b58b17f2bbe2ba00304b Essentially every single commit that adds support for these config options: diff --git a/arch/arm/mach-exynos/Kconfig b/arch/arm/mach-exynos/Kconfig index b8df521..3be8f7c 100644 --- a/arch/arm/mach-exynos/Kconfig +++ b/arch/arm/mach-exynos/Kconfig @@ -61,6 +61,11 @@ config SOC_EXYNOS5250 bool "SAMSUNG EXYNOS5250" default y depends on ARCH_EXYNOS5 + select PM_GENERIC_DOMAINS if PM + select S5P_PM if PM +select S5P_SLEEP if PM +select S5P_DEV_MFC + select SAMSUNG_DMADEV help Enable EXYNOS5250 SoC support I am guessing you wouldn't want to make such extensive changes to 3.4 to add full support for Chromebook. 3.10.y has full support for all of the above. Thoughts. Agree with my assessment? -- Shuah -- Shuah Khan Senior Linux Kernel Developer - Open Source Group Samsung Research America(Silicon Valley) shuah...@samsung.com | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] arm: LLVMLinux: Add current_stack_pointer macro for ARM
beh...@converseincode.com writes:
> +#define current_stack_pointer ({ \
> + unsigned long current_sp; \
> + asm ("mov %0, r13" : "=r" (current_sp)); \
> + current_sp; \
> +})
Why do you use 'r13' rather than the more common 'sp' alias?
--
Måns Rullgård
m...@mansr.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] arm: LLVMLinux: Calculate pt_regs address from fp
On Fri, Sep 06, 2013 at 05:42:41PM -0400, beh...@converseincode.com wrote: > From: Behan Webster > > Use the frame pointer to calculate the end of the stack for current_pt_regs() > The existing code uses the stack pointer to do this calculation. > Using the frame pointer yeilds the same value in a more portable way. > This change supports being able to compile the kernel with gcc and clang. What happens when frame pointers are disabled on gcc? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 1/2] ARM: msm: Add support for APQ8074 Dragonboard
Hi,
Some comments below.
On Fri, Sep 06, 2013 at 12:32:22PM -0700, Rohit Vaswani wrote:
> This patch adds basic board support for APQ8074 Dragonboard
> which belongs to the Snapdragon 800 family.
> For now, just support a basic machine with device tree.
>
> Signed-off-by: Rohit Vaswani
> ---
> arch/arm/boot/dts/Makefile| 3 ++-
> arch/arm/boot/dts/apq8074-dragonboard.dts | 6 ++
> arch/arm/boot/dts/msm8974.dtsi| 35
> +++
> arch/arm/mach-msm/Kconfig | 20 --
> arch/arm/mach-msm/Makefile| 1 +
> arch/arm/mach-msm/board-dt-8974.c | 24 +
> 6 files changed, 86 insertions(+), 3 deletions(-)
> create mode 100644 arch/arm/boot/dts/apq8074-dragonboard.dts
> create mode 100644 arch/arm/boot/dts/msm8974.dtsi
> create mode 100644 arch/arm/mach-msm/board-dt-8974.c
>
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 641b3c9a..bea54a7 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -97,7 +97,8 @@ dtb-$(CONFIG_ARCH_KIRKWOOD) += kirkwood-cloudbox.dtb \
> kirkwood-openblocks_a6.dtb
> dtb-$(CONFIG_ARCH_MARCO) += marco-evb.dtb
> dtb-$(CONFIG_ARCH_MSM) += msm8660-surf.dtb \
> - msm8960-cdp.dtb
> + msm8960-cdp.dtb \
> + apq8074-dragonboard.dtb
Please add boards alphabetically.
> dtb-$(CONFIG_ARCH_MVEBU) += armada-370-db.dtb \
> armada-370-mirabox.dtb \
> armada-370-rd.dtb \
> diff --git a/arch/arm/boot/dts/apq8074-dragonboard.dts
> b/arch/arm/boot/dts/apq8074-dragonboard.dts
> new file mode 100644
> index 000..5b7b6a0
> --- /dev/null
> +++ b/arch/arm/boot/dts/apq8074-dragonboard.dts
arch/arm/boot/dts/ is getting really crowded. It's been working best if the SoC
family or vendor is used as a prefix to keep things a bit more organized. In
that spirit, prefixing these with msm- makes sense. Can you please do so?
> @@ -0,0 +1,6 @@
> +/include/ "msm8974.dtsi"
> +
> +/ {
> + model = "Qualcomm APQ8074 Dragonboard";
> + compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
> +};
Ok, I'm all for merging a early minimal dts file, but things like memory and
a default bootargs tend to make sense.
> diff --git a/arch/arm/boot/dts/msm8974.dtsi b/arch/arm/boot/dts/msm8974.dtsi
> new file mode 100644
> index 000..f04b643
> --- /dev/null
> +++ b/arch/arm/boot/dts/msm8974.dtsi
> @@ -0,0 +1,35 @@
> +/dts-v1/;
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> + model = "Qualcomm MSM8974";
> + compatible = "qcom,msm8974";
the board uses "qcom,apq8074" and this overrides this. Which way is it?
> + interrupt-parent = <>;
> +
> + soc: soc { };
For files that include this it's ok to use the syntax, but in this
base dtsi, please use proper structure. In other words, move the contents of
the soc node up above instead.
> +};
> +
> + {
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + compatible = "simple-bus";
> +
> + intc: interrupt-controller@f900 {
> + compatible = "qcom,msm-qgic2";
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + reg = <0xf900 0x1000>,
> + <0xf9002000 0x1000>;
> + };
> +
> + timer {
> + compatible = "arm,armv7-timer";
> + interrupts = <1 2 0xf08>,
> + <1 3 0xf08>,
> + <1 4 0xf08>,
> + <1 1 0xf08>;
> + clock-frequency = <1920>;
> + };
> +};
It'd make a lot of sense to include at least cpu nodes here as well, and
ideally basics for the drivers you have already merged, such as uarts.
> diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
> index 905efc8..499e8fe 100644
> --- a/arch/arm/mach-msm/Kconfig
> +++ b/arch/arm/mach-msm/Kconfig
> @@ -1,12 +1,12 @@
> if ARCH_MSM
>
> comment "Qualcomm MSM SoC Type"
> - depends on (ARCH_MSM8X60 || ARCH_MSM8960)
> + depends on ARCH_MSM_DT
>
> choice
> prompt "Qualcomm MSM SoC Type"
> default ARCH_MSM7X00A
> - depends on !(ARCH_MSM8X60 || ARCH_MSM8960)
> + depends on !ARCH_MSM_DT
This has nothing to do with adding support for dragonboard. Please break
out the cleanup separately.
I'm not sure what the purpose of ARCH_MSM_DT is either, it just looks to
complicate matter here?
> +config ARCH_MSM8974
> + bool "MSM8974"
> + select ARM_GIC
> + select CPU_V7
> + select HAVE_ARM_ARCH_TIMER
> + select HAVE_SMP
> + select MSM_SCM if SMP
> + select USE_OF
> +
> +config ARCH_MSM_DT
> + def_bool y
> + depends on (ARCH_MSM8X60 || ARCH_MSM8960 || ARCH_MSM8974)
> +
> config MSM_HAS_DEBUG_UART_HS
> bool
>
> @@ -68,6 +81,7 @@ config MSM_SOC_REV_A
>
> config ARCH_MSM_ARM11
> bool
> +
> config ARCH_MSM_SCORPION
> bool
>
> @@ -75,6 +89,7 @@ config MSM_VIC
> bool
>
>
Re: [PATCH RESEND v3 3/7] Intel MIC Host Driver, card OS state management.
On Fri, 2013-09-06 at 12:04 -0700, Greg Kroah-Hartman wrote: > On Fri, Sep 06, 2013 at 11:41:03AM -0700, Sudeep Dutt wrote: > > On Thu, 2013-09-05 at 22:01 -0700, Greg Kroah-Hartman wrote: > > > On Thu, Sep 05, 2013 at 04:41:55PM -0700, Sudeep Dutt wrote: > > > > +What: /sys/class/mic/mic(x)/firmware > > > > +Date: August 2013 > > > > +KernelVersion: 3.11 > > > > +Contact: Sudeep Dutt > > > > +Description: > > > > + When read, this sysfs entry provides the path name under > > > > + /lib/firmware/ where the firmware image to be booted on > > > > the > > > > + card can be found. The entry can be written to change > > > > the > > > > + firmware image location under /lib/firmware/. > > > > > > I don't understand, is the path under the HOST device, or the Client > > > device's disk? Why do you need to change the path on the HOST? What's > > > wrong with the existing firmware path selection we have in the kernel? > > > > > > > The path is on the host. The card does not have a physical persistent > > disk device. Our customers like the flexibility of changing the card > > firmware/ramdisk contents and file names for individual MIC cards. This > > flexibility is not possible with a static set of firmware file names in > > the kernel for all cards. > > > > Once the firmware/ramdisk path under /lib/firmware/ is set up via sysfs, > > card boot is initiated via the "state" sysfs entry. The host driver then > > obtains the contents of the firmware and ramdisk via the standard > > request_firmware(..) interface, copies the contents to card memory and > > interrupts the card BIOS to initiate boot. > > So this is really a "filename" that might contain some directories as > well, right? The fact you used "path" confused me, as that doesn't > usually imply a filename. > Yes, it is a filename that might contain some directories. We will fix up the documentation here to read filename in future patches. > And is the "firmware" just the initramfs image for the kernel to boot? > The firmware is usually a Linux kernel. The ramdisk is usually an initramfs image. We have separate sysfs entries for firmware and ramdisk filenames. Thanks, Sudeep Dutt > thanks, > > greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ 00/36] 3.10.11-stable review
On Thu, Sep 5, 2013 at 1:27 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.10.11 release. > There are 36 patches in this series, all will be posted as a response > to this one. If anyone has any issues with these being applied, please > let me know. > > Responses should be made by Sat Sep 7 20:26:25 UTC 2013. > Anything received after that time might be too late. > > The whole patch series can be found in one patch at: > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.11-rc1.gz > and the diffstat can be found below. FYI; I've started tracking the 3.10+ queues on my builder/booter for arm-soc platforms. I don't plan on posting the logs but will keep an eye on them and report (new) failures that aren't seen on the baseline. I poll for new patches a few times an hour. -Olof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] HID for 3.12 merge window
On 2013.09.06 at 23:50 +0200, David Herrmann wrote: > Hi > > On Fri, Sep 6, 2013 at 10:20 PM, Markus Trippelsdorf > wrote: > > On 2013.09.06 at 14:00 +0200, Jiri Kosina wrote: > >> > >> David Herrmann (12): > > ... > >> HID: wiimote: add support for Guitar-Hero drums > > > > commit 61e00655e9cb82e034eb72b95a51072e718d14a7 > > Author: David Herrmann > > Date: Mon Aug 26 19:14:46 2013 +0200 > > > > Input: introduce BTN/ABS bits for drums and guitars > > > > The commit above breaks my Logitech mouse. The mouse cursor just sits in > > the middle of the screen and doesn't react to movements. dmesg is > > normal, but Xorg.0.log says: > > Ok, the issue is the kernel assumes ABS_MAX to be a power-of-2 minus 1 > (used as mask). That wasn't really obvious to me. Attached is a patch > which should fix that. Could you apply it on top of linus/master and > give it a try? Your patch fixes the issue. Thanks. -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[BUG kernel 3.11+] i915: pipe state doesn't match
Someone might be interested ... kernel 2e032852245b3dcfe5461d7353e34eb6da095ccf. [0.00] Linux version 3.11.0-main+ (k...@linux-ktth.site) (gcc version 4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux) ) #34 PREEMPT Fri Sep 6 09:46:35 CEST 2013 [2.258908] Linux agpgart interface v0.103 [2.259082] agpgart-intel :00:00.0: Intel 915GM Chipset [2.259258] agpgart-intel :00:00.0: detected gtt size: 262144K total, 262144K mappable [2.259949] agpgart-intel :00:00.0: detected 8192K stolen memory [2.260466] agpgart-intel :00:00.0: AGP aperture is 256M @ 0xc000 [2.260608] [drm] Initialized drm 1.1.0 20060810 [2.265158] [drm] Memory usable by graphics device = 256M [2.265301] i915 :00:02.0: setting latency timer to 64 [2.266465] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [2.266471] [drm] Driver supports precise vblank timestamp query. [2.267197] [drm:i915_stolen_to_physical] *ERROR* conflict detected with stolen region: [0x7f80 - 0x8000] [2.267876] vgaarb: device changed decodes: PCI::00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem [2.268246] [drm] Skipping LVDS initialization for AOpen i915GMm-HFS [3.132208] tsc: Refined TSC clocksource calibration: 1199.999 MHz [3.169857] [drm] initialized overlay support [3.651142] [drm:intel_pipe_config_compare] *ERROR* mismatch in adjusted_mode.flags(DRM_MODE_FLAG_NHSYNC) (expected 2, found 0) [3.651221] [ cut here ] [3.651237] WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/i915/intel_display.c:8746 check_crtc_state+0x6c5/0x6f9() [3.651242] pipe state doesn't match! [3.651246] Modules linked in: [3.651256] CPU: 0 PID: 1 Comm: swapper Not tainted 3.11.0-main+ #34 [3.651262] Hardware name:/i915GMm-HFS, BIOS 6.00 PG 11/04/2005 [3.651267] c07019fb f60798a0 c053b1c2 f60798b8 c012a8f0 c03c578b [3.651288] f6377000 f636cc48 f60798d0 c012a97a 0009 f60798c8 c07019fb f60798e4 [3.651308] f6079b38 c03c578b c07008c1 222a c07019fb f606a4f8 f6376e44 f606a4fc [3.651329] Call Trace: [3.651342] [] dump_stack+0x16/0x18 [3.651354] [] warn_slowpath_common+0x5f/0x76 [3.651363] [] ? check_crtc_state+0x6c5/0x6f9 [3.651373] [] warn_slowpath_fmt+0x2b/0x2f [3.651383] [] check_crtc_state+0x6c5/0x6f9 [3.651411] [] intel_modeset_check_state+0x30c/0x57b [3.651422] [] intel_set_mode+0x26/0x2f [3.651431] [] intel_get_load_detect_pipe+0x2b4/0x308 [3.651447] [] intel_tv_detect+0x108/0x444 [3.651466] [] drm_helper_probe_single_connector_modes+0xa0/0x270 [3.651477] [] drm_fb_helper_probe_connector_modes+0x39/0x4c [3.651487] [] drm_fb_helper_initial_config+0x143/0x3ac [3.651497] [] ? _raw_spin_unlock_irqrestore+0x38/0x5b [3.651506] [] ? _raw_spin_unlock_irqrestore+0x44/0x5b [3.651516] [] ? _raw_spin_unlock_irqrestore+0x44/0x5b [3.651527] [] intel_fbdev_initial_config+0x1e/0x20 [3.651536] [] i915_driver_load+0xb48/0xd23 [3.651551] [] drm_get_pci_dev+0x172/0x266 [3.651560] [] ? _raw_spin_unlock_irqrestore+0x44/0x5b [3.651572] [] i915_pci_probe+0x46/0x4f [3.651582] [] pci_device_probe+0x5e/0x96 [3.651594] [] driver_probe_device+0x8c/0x186 [3.651604] [] __driver_attach+0x58/0x76 [3.651614] [] bus_for_each_dev+0x43/0x6d [3.651624] [] driver_attach+0x19/0x1b [3.651633] [] ? driver_probe_device+0x186/0x186 [3.651642] [] bus_add_driver+0xcc/0x1f7 [3.651652] [] driver_register+0x73/0xa5 [3.651661] [] __pci_register_driver+0x4a/0x4d [3.651673] [] ? ftrace_define_fields_drm_vblank_event+0x45/0x45 [3.651682] [] drm_pci_init+0x6d/0xc5 [3.651692] [] ? ftrace_define_fields_drm_vblank_event+0x45/0x45 [3.651701] [] i915_init+0x5e/0x60 [3.651710] [] do_one_initcall+0x6f/0xea [3.651722] [] ? repair_env_string+0x12/0x51 [3.651731] [] ? do_early_param+0x5f/0x75 [3.651741] [] ? parse_args+0x16b/0x209 [3.651752] [] kernel_init_freeable+0xce/0x153 [3.651762] [] kernel_init+0xd/0xb9 [3.651771] [] ret_from_kernel_thread+0x1b/0x28 [3.651779] [] ? rest_init+0xa5/0xa5 [3.651958] ---[ end trace deefedea51430d57 ]--- [3.824510] fbcon: inteldrmfb (fb0) is primary device [3.943377] Console: switching to colour frame buffer device 160x64 [3.957788] i915 :00:02.0: fb0: inteldrmfb frame buffer device [3.957795] i915 :00:02.0: registered panic notifier [3.957864] [drm] Initialized i915 1.6.0 20080730 for :00:02.0 on minor 0 cu, Knut -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [ 00/36] 3.10.11-stable review
On Fri, Sep 06, 2013 at 03:08:06PM -0700, Olof Johansson wrote: > On Thu, Sep 5, 2013 at 1:27 PM, Greg Kroah-Hartman > wrote: > > This is the start of the stable review cycle for the 3.10.11 release. > > There are 36 patches in this series, all will be posted as a response > > to this one. If anyone has any issues with these being applied, please > > let me know. > > > > Responses should be made by Sat Sep 7 20:26:25 UTC 2013. > > Anything received after that time might be too late. > > > > The whole patch series can be found in one patch at: > > kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.10.11-rc1.gz > > and the diffstat can be found below. > > FYI; I've started tracking the 3.10+ queues on my builder/booter for > arm-soc platforms. > > I don't plan on posting the logs but will keep an eye on them and > report (new) failures that aren't seen on the baseline. I poll for new > patches a few times an hour. That would be great to know, thanks for doing this. greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] HID for 3.12 merge window
Hi
On Fri, Sep 6, 2013 at 10:20 PM, Markus Trippelsdorf
wrote:
> On 2013.09.06 at 14:00 +0200, Jiri Kosina wrote:
>>
>> David Herrmann (12):
> ...
>> HID: wiimote: add support for Guitar-Hero drums
>
> commit 61e00655e9cb82e034eb72b95a51072e718d14a7
> Author: David Herrmann
> Date: Mon Aug 26 19:14:46 2013 +0200
>
> Input: introduce BTN/ABS bits for drums and guitars
>
> The commit above breaks my Logitech mouse. The mouse cursor just sits in
> the middle of the screen and doesn't react to movements. dmesg is
> normal, but Xorg.0.log says:
Ok, the issue is the kernel assumes ABS_MAX to be a power-of-2 minus 1
(used as mask). That wasn't really obvious to me. Attached is a patch
which should fix that. Could you apply it on top of linus/master and
give it a try?
@Dmitry: The IOC_NR part of the definition of EVIOCSABS() is now
bigger than 1-byte. I need to check how that affects the 'E' part. Any
idea what to do here?
Thanks
David
Patch is also attached as I doubt that inlining it works in that
stupid web-client:
>From 653fe4d46ad368cdbf9b56a559a8468bd6f5cb3c Mon Sep 17 00:00:00 2001
From: David Herrmann
Date: Fri, 6 Sep 2013 23:46:08 +0200
Subject: [PATCH] Input: evdev: don't assume ABS_MAX to be a power-of-2 minus 1
ABS_MAX is no longer a full mask. Hence, don't use it directly to get any
parameter for ioctls. Furthermore, the parameter-region and
ioctl-definition overlap, so even bumping ABS_MAX to 0x7f wouldn't help.
Reported-by: Markus Trippelsdorf
Signed-off-by: David Herrmann
---
drivers/input/evdev.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/input/evdev.c b/drivers/input/evdev.c
index d2b34fb..82e0073 100644
--- a/drivers/input/evdev.c
+++ b/drivers/input/evdev.c
@@ -939,12 +939,13 @@ static long evdev_do_ioctl(struct file *file,
unsigned int cmd,
_IOC_NR(cmd) & EV_MAX, size,
p, compat_mode);
- if ((_IOC_NR(cmd) & ~ABS_MAX) == _IOC_NR(EVIOCGABS(0))) {
+ if (_IOC_NR(cmd) >= _IOC_NR(EVIOCGABS(0)) &&
+_IOC_NR(cmd) <= _IOC_NR(EVIOCGABS(ABS_MAX))) {
if (!dev->absinfo)
return -EINVAL;
- t = _IOC_NR(cmd) & ABS_MAX;
+ t = _IOC_NR(cmd) - _IOC_NR(EVIOCGABS(0));
abs = dev->absinfo[t];
if (copy_to_user(p, , min_t(size_t,
@@ -957,12 +958,13 @@ static long evdev_do_ioctl(struct file *file,
unsigned int cmd,
if (_IOC_DIR(cmd) == _IOC_WRITE) {
- if ((_IOC_NR(cmd) & ~ABS_MAX) == _IOC_NR(EVIOCSABS(0))) {
+ if (_IOC_NR(cmd) >= _IOC_NR(EVIOCSABS(0)) &&
+_IOC_NR(cmd) <= _IOC_NR(EVIOCSABS(ABS_MAX))) {
if (!dev->absinfo)
return -EINVAL;
- t = _IOC_NR(cmd) & ABS_MAX;
+ t = _IOC_NR(cmd) - _IOC_NR(EVIOCSABS(0));
if (copy_from_user(, p, min_t(size_t,
size, sizeof(struct input_absinfo
--
1.8.4
0001-Input-evdev-don-t-assume-ABS_MAX-to-be-a-power-of-2-.patch
Description: Binary data
Re: [PATCH v3 1/1] dcache: Translating dentry into pathname without taking rename_lock
On Fri, Sep 6, 2013 at 2:05 PM, Al Viro wrote: > > I can take that, but I'm really not convinced that we need writer lock > there at all. After all, if we really can get livelocks on that one, > we would be getting them on d_lookup()... d_lookup() does a _single_ path component. That's a *big* difference. Sure, the hash chain that d_lookup() (well, __d_lookup()) ends up walking is a bit more complicated than just following the dentry parent pointer, but that's much harder to trigger than just creating a really deep directory structure of single-letter nested directories, and then doing a "getcwd()" that walks 1024+ parents, while another thread is looping renaming things.. So I personally do feel a lot safer with the fallback to write locking here. Especially since it's pretty simple, so there isn't really much downside. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] arm: LLVMLinux: Calculate current_thread_info from fp
From: Behan Webster
Use the frame pointer to calculate the start of the stack for
current_thread_info()
The existing code uses the stack pointer to do this calculation.
Using the frame pointer yeilds the same value in a portable way.
This change supports being able to compile the kernel with gcc and Clang.
Signed-off-by: Mark Charlebois
Signed-off-by: Behan Webster
Reviewed-by: Jan-Simon Möller
---
arch/arm/include/asm/thread_info.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/thread_info.h
b/arch/arm/include/asm/thread_info.h
index df5e13d..cb50933 100644
--- a/arch/arm/include/asm/thread_info.h
+++ b/arch/arm/include/asm/thread_info.h
@@ -106,8 +106,9 @@ static inline struct thread_info *current_thread_info(void)
__attribute_const__;
static inline struct thread_info *current_thread_info(void)
{
- register unsigned long sp asm ("sp");
- return (struct thread_info *)(sp & ~(THREAD_SIZE - 1));
+ return (struct thread_info *)
+ ((u32)(__builtin_frame_address(0))
+ & ~(THREAD_SIZE - 1));
}
#define thread_saved_pc(tsk) \
--
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] arm: LLVMLinux: Use __builtin_frame_address to get thread info
From: Behan Webster The LLVMLinux Project is working to be able to build the Linux kernel with clang/LLVM. With the release of LLVM 3.3 clang is now able to compile the Linux kernel with a number of small patches (available from the LLVMLinux git repo). Use the frame pointer to calculate the start of the stack for current_thread_info() The existing code uses the stack pointer to do this calculation. Using the frame pointer yeilds the same value in a portable way. This change supports being able to compile the kernel with gcc and Clang. Behan Webster (1): arm: LLVMLinux: Calculate current_thread_info from fp arch/arm/include/asm/thread_info.h | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) -- 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] arm: LLVMLinux: Calculate pt_regs address from fp
From: Behan Webster
Use the frame pointer to calculate the end of the stack for current_pt_regs()
The existing code uses the stack pointer to do this calculation.
Using the frame pointer yeilds the same value in a more portable way.
This change supports being able to compile the kernel with gcc and clang.
Signed-off-by: Mark Charlebois
Signed-off-by: Behan Webster
Reviewed-by: Jan-Simon Möller
---
arch/arm/include/asm/ptrace.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/arm/include/asm/ptrace.h b/arch/arm/include/asm/ptrace.h
index 04c99f3..8aec2db 100644
--- a/arch/arm/include/asm/ptrace.h
+++ b/arch/arm/include/asm/ptrace.h
@@ -138,9 +138,9 @@ static inline unsigned long user_stack_pointer(struct
pt_regs *regs)
return regs->ARM_sp;
}
-#define current_pt_regs(void) ({ \
- register unsigned long sp asm ("sp"); \
- (struct pt_regs *)((sp | (THREAD_SIZE - 1)) - 7) - 1; \
+#define current_pt_regs(void) ({ \
+ (struct pt_regs *)(((unsigned long)(__builtin_frame_address(0)) \
+ | (THREAD_SIZE - 1)) - 7) - 1; \
})
#endif /* __ASSEMBLY__ */
--
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] arm: LLVMLinux: Use __builtin_frame_address instead of named registers
From: Behan Webster The LLVMLinux Project is working to be able to build the Linux kernel with clang/LLVM. With the release of LLVM 3.3 clang is now able to compile the Linux kernel with a number of small patches (available from the LLVMLinux git repo). Use the frame pointer to calculate the end of the stack for current_pt_regs() The existing code uses the stack pointer to do this calculation. Using the frame pointer yeilds the same value in a more portable way. This change supports being able to compile the kernel with gcc and clang. Behan Webster (1): arm: LLVMLinux: Calculate pt_regs address from fp arch/arm/include/asm/ptrace.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 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 1/5] arm: LLVMLinux: Add current_stack_pointer macro for ARM
From: Behan Webster
A macro to get the current stack pointer which allows for a single place in
which to do so with ASM. Before this named registers (a gcc extension) was used
to get the stack pointer. Using ASM is a more portable way of getting the stack
pointer which works with both gcc and clang. This macro is of the same name
used in the X86 arch.
Author: Behan Webster
Signed-off-by: Behan Webster
Reviewed-by: Jan-Simon Möller
---
arch/arm/include/asm/thread_info.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/arch/arm/include/asm/thread_info.h
b/arch/arm/include/asm/thread_info.h
index df5e13d..94283f8 100644
--- a/arch/arm/include/asm/thread_info.h
+++ b/arch/arm/include/asm/thread_info.h
@@ -100,6 +100,15 @@ struct thread_info {
#define init_stack (init_thread_union.stack)
/*
+ * how to get the current stack pointer from C
+ */
+#define current_stack_pointer ({ \
+ unsigned long current_sp; \
+ asm ("mov %0, r13" : "=r" (current_sp)); \
+ current_sp; \
+})
+
+/*
* how to get the thread information struct from C
*/
static inline struct thread_info *current_thread_info(void)
__attribute_const__;
--
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 5/5] arm: LLVMLinux: Use current_stack_pointer in unwind_backtrace
From: Behan Webster
The existing code uses named registers to get the value of the stack pointer.
The new current_stack_pointer macro is more readable and allows for a central
portable implementation of how to get the stack pointer with ASM. This change
supports being able to compile the kernel with both gcc and Clang.
Signed-off-by: Mark Charlebois
Signed-off-by: Behan Webster
Reviewed-by: Jan-Simon Möller
---
arch/arm/kernel/unwind.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/kernel/unwind.c b/arch/arm/kernel/unwind.c
index 00df012..e7f1eec 100644
--- a/arch/arm/kernel/unwind.c
+++ b/arch/arm/kernel/unwind.c
@@ -408,7 +408,6 @@ int unwind_frame(struct stackframe *frame)
void unwind_backtrace(struct pt_regs *regs, struct task_struct *tsk)
{
struct stackframe frame;
- register unsigned long current_sp asm ("sp");
pr_debug("%s(regs = %p tsk = %p)\n", __func__, regs, tsk);
@@ -424,7 +423,7 @@ void unwind_backtrace(struct pt_regs *regs, struct
task_struct *tsk)
? regs->ARM_pc : regs->ARM_lr;
} else if (tsk == current) {
frame.fp = (unsigned long)__builtin_frame_address(0);
- frame.sp = current_sp;
+ frame.sp = current_stack_pointer;
frame.lr = (unsigned long)__builtin_return_address(0);
frame.pc = (unsigned long)unwind_backtrace;
} else {
--
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 4/5] arm: LLVMLinux: Use current_stack_pointer in save_stack_trace_tsk
From: Behan Webster
The existing code uses named registers to get the value of the stack pointer.
The new current_stack_pointer macro is more readable and allows for a central
portable implementation of how to get the stack pointer with ASM. This change
supports being able to compile the kernel with both gcc and Clang.
Signed-off-by: Mark Charlebois
Signed-off-by: Behan Webster
Reviewed-by: Jan-Simon Möller
---
arch/arm/kernel/stacktrace.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/arch/arm/kernel/stacktrace.c b/arch/arm/kernel/stacktrace.c
index 00f79e5..8c23310 100644
--- a/arch/arm/kernel/stacktrace.c
+++ b/arch/arm/kernel/stacktrace.c
@@ -109,11 +109,9 @@ void save_stack_trace_tsk(struct task_struct *tsk, struct
stack_trace *trace)
frame.pc = thread_saved_pc(tsk);
#endif
} else {
- register unsigned long current_sp asm ("sp");
-
data.no_sched_functions = 0;
frame.fp = (unsigned long)__builtin_frame_address(0);
- frame.sp = current_sp;
+ frame.sp = current_stack_pointer;
frame.lr = (unsigned long)__builtin_return_address(0);
frame.pc = (unsigned long)save_stack_trace_tsk;
}
--
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 2/5] arm: LLVMLinux: use current_stack_pointer for percpu
From: Behan Webster
The existing code uses named registers to get the value of the stack pointer.
The new current_stack_pointer macro is more readable and allows for a central
portable implementation of how to get the stack pointer with ASM. This change
supports being able to compile the kernel with both gcc and Clang.
Signed-off-by: Mark Charlebois
Signed-off-by: Behan Webster
Reviewed-by: Jan-Simon Möller
---
arch/arm/include/asm/percpu.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/arm/include/asm/percpu.h b/arch/arm/include/asm/percpu.h
index 209e650..629a975 100644
--- a/arch/arm/include/asm/percpu.h
+++ b/arch/arm/include/asm/percpu.h
@@ -30,14 +30,14 @@ static inline void set_my_cpu_offset(unsigned long off)
static inline unsigned long __my_cpu_offset(void)
{
unsigned long off;
- register unsigned long *sp asm ("sp");
+ unsigned long sp = current_stack_pointer;
/*
* Read TPIDRPRW.
* We want to allow caching the value, so avoid using volatile and
* instead use a fake stack read to hazard against barrier().
*/
- asm("mrc p15, 0, %0, c13, c0, 4" : "=r" (off) : "Q" (*sp));
+ asm("mrc p15, 0, %0, c13, c0, 4" : "=r" (off) : "Q" (sp));
return off;
}
--
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 3/5] arm: LLVMLinux: Use current_stack_pointer for return_address
From: Behan Webster
The existing code uses named registers to get the value of the stack pointer.
The new current_stack_pointer macro is more readable and allows for a central
portable implementation of how to get the stack pointer with ASM. This change
supports being able to compile the kernel with both gcc and Clang.
Signed-off-by: Mark Charlebois
Signed-off-by: Behan Webster
Reviewed-by: Jan-Simon Möller
---
arch/arm/kernel/return_address.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/arm/kernel/return_address.c b/arch/arm/kernel/return_address.c
index fafedd8..5bceaef 100644
--- a/arch/arm/kernel/return_address.c
+++ b/arch/arm/kernel/return_address.c
@@ -39,13 +39,12 @@ void *return_address(unsigned int level)
{
struct return_address_data data;
struct stackframe frame;
- register unsigned long current_sp asm ("sp");
data.level = level + 2;
data.addr = NULL;
frame.fp = (unsigned long)__builtin_frame_address(0);
- frame.sp = current_sp;
+ frame.sp = current_stack_pointer;
frame.lr = (unsigned long)__builtin_return_address(0);
frame.pc = (unsigned long)return_address;
--
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 0/5] arm: LLVMLinux: Add current_stack_pointer
From: Behan Webster The LLVMLinux Project is working to be able to build the Linux kernel with clang/LLVM. With the release of LLVM 3.3 clang is now able to compile the Linux kernel with a number of small patches (available from the LLVMLinux git repo). These patches add a macro to get the current stack pointer which allows for a single place in which to do so with ASM. Before this named registers (a gcc extension) was used to get the stack pointer. Using ASM is a more portable way of getting the stack pointer which works with both gcc and clang. This macro is of the same name used in the X86 arch. Behan Webster (5): arm: LLVMLinux: Add current_stack_pointer macro for ARM arm: LLVMLinux: use current_stack_pointer for percpu arm: LLVMLinux: Use current_stack_pointer for return_address arm: LLVMLinux: Use current_stack_pointer in save_stack_trace_tsk arm: LLVMLinux: Use current_stack_pointer in unwind_backtrace arch/arm/include/asm/percpu.h | 4 ++-- arch/arm/include/asm/thread_info.h | 9 + arch/arm/kernel/return_address.c | 3 +-- arch/arm/kernel/stacktrace.c | 4 +--- arch/arm/kernel/unwind.c | 3 +-- 5 files changed, 14 insertions(+), 9 deletions(-) -- 1.8.1.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ARM: msm: Remove irqs-*.h files for DT based targets
On Fri, Sep 06, 2013 at 01:31:57PM -0700, Stephen Boyd wrote: > We don't want or need the irqs.h files from the DT based MSM > targets. Remove these header files and select sparse irq so that > we don't try to include the mach/irqs.h file. > > Signed-off-by: Stephen Boyd > --- > > On 09/06, Josh Cartwright wrote: > > > > Selecting _only_ ARCH_MSM8974 with these changes breaks the build with: > > I've been meaning to fix this. Perhaps you can use this patch as a base > and then push the SPARSE_IRQ selection into the DT config? Sounds sane to me. AFAICT, we didn't yet have any users of these defines upstream. Using SPARSE_IRQ puts on the path of multiplatform support anyway. FWIW, I tested this by applying this change under Rohit's and squashing the following with patch 1/2: diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig index fe35acf..f4a0aaa 100644 --- a/arch/arm/mach-msm/Kconfig +++ b/arch/arm/mach-msm/Kconfig @@ -50,7 +50,6 @@ config ARCH_MSM8X60 select HAVE_SMP select MSM_SCM if SMP select USE_OF - select SPARSE_IRQ config ARCH_MSM8960 bool "MSM8960" @@ -60,7 +59,6 @@ config ARCH_MSM8960 select GPIO_MSM_V2 select MSM_SCM if SMP select USE_OF - select SPARSE_IRQ config ARCH_MSM8974 bool "MSM8974" @@ -74,6 +72,7 @@ config ARCH_MSM8974 config ARCH_MSM_DT def_bool y depends on (ARCH_MSM8X60 || ARCH_MSM8960 || ARCH_MSM8974) + select SPARSE_IRQ config MSM_HAS_DEBUG_UART_HS bool -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/1] dcache: Translating dentry into pathname without taking rename_lock
On Fri, Sep 6, 2013 at 9:08 AM, Waiman Long wrote:
>
> This patch will replace the writer's write_seqlock/write_sequnlock
> sequence of the rename_lock of the callers of the prepend_path() and
> __dentry_path() functions with the reader's read_seqbegin/read_seqretry
> sequence within these 2 functions.
Ok, this actually looks really good.
I do have one comment, from just reading the patch:
I would really like the stuff inside the
restart:
bptr = *buffer;
blen = *buflen;
if (retry_cnt) {
seq = read_seqbegin(_lock);
rcu_read_lock();
} else
write_seqlock(_lock);
... guts of path generation ...
if (retry_cnt) {
retry_cnt--;
rcu_read_unlock();
if (read_seqretry(_lock, seq))
goto restart;
} else
write_sequnlock(_lock);
could possible be done as a separate function?
Alternatively (or perhaps additionally), maybe the locking could be
done as an inline function too (taking the retry count as an argument)
to make things a bit more easy to understand.
Right now there is a lot of fairly subtle things going on in that
__dentry_path() function. It's not a huge function, but I think that
"while()" loop inside that locking could be done as its own function
and make it even more readable.
But I could already apply this as-is, so it's not a big deal.
Al - do you have comments? Do you want to take this through your tree,
or are you working on other things? I can take this directly too..
Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT PULL] (xen) stable/for-jens-3.12 for Jens Axboe
On Fri, Sep 06, 2013 at 02:26:34PM -0600, Jens Axboe wrote: > On 09/06/2013 02:25 PM, Konrad Rzeszutek Wilk wrote: > > Hey Jens, > > > > I sent you a git pull a couple of weeks ago but I am not sure if > > you pulled it. It does not look like it, so here it is again along > > with an extra bug-fix. > > > > Please git pull: > > > > git pull git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git > > stable/for-jens-3.12 > > > > which will give you bug-fixes to Xen blkfront and backend driver: > > Thanks, I'll get the 3.12 branch set up and pulled in. I'm behind on a > lot of other drivers, too. Thank you! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/1] dcache: Translating dentry into pathname without taking rename_lock
On Fri, Sep 06, 2013 at 01:52:49PM -0700, Linus Torvalds wrote: > Al - do you have comments? Do you want to take this through your tree, > or are you working on other things? I can take this directly too.. I can take that, but I'm really not convinced that we need writer lock there at all. After all, if we really can get livelocks on that one, we would be getting them on d_lookup()... Let's not complicate the things without need; if we ever run into loads where livelock start to happen, we can look into dealing with them. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: msm: Remove irqs-*.h files for DT based targets
On 09/06/13 13:31, Stephen Boyd wrote: > diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig > index 905efc8..30b3342 100644 > --- a/arch/arm/mach-msm/Kconfig > +++ b/arch/arm/mach-msm/Kconfig > @@ -50,6 +50,7 @@ config ARCH_MSM8X60 > select HAVE_SMP > select MSM_SCM if SMP > select USE_OF > + select SPARSE_IRQ > > config ARCH_MSM8960 > bool "MSM8960" > @@ -59,6 +60,7 @@ config ARCH_MSM8960 > select GPIO_MSM_V2 > select MSM_SCM if SMP > select USE_OF > + select SPARSE_IRQ Gah, I guess this needs to be sorted alphabetically. -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V4] regulator: palmas: add support for external control of rails
On Wed, Aug 21, 2013 at 04:18:16PM +0530, Laxman Dewangan wrote: > Palmas rails like LDOs, SMPSs, REGENs, SYSENs can be enable and disable > by register programming through I2C communication as well as it can be > enable/disable with the external control input ENABLE1, ENABLE2 and NSLEEP. Applied, thanks. signature.asc Description: Digital signature
[PULL REQUEST] NVM Express updates
Hi Linus, Please pull the NVMe tree. The following changes since commit a2648ebb7ed69ef209d9c8a76fadeb3252d9a023: Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs (2013-06-13 22:34:14 -0700) are available in the git repository at: git://git.infradead.org/users/willy/linux-nvme.git master for you to fetch changes up to d82e8bfdef9afae83b894be49af4644d9ac3c359: NVMe: Merge issue on character device bring-up (2013-09-06 16:26:58 -0400) Keith Busch (12): NVMe: Disk IO statistics NVMe: Update nvme_id_power_state with latest spec NVMe: Fix checkpatch issues NVMe: Bring up cdev on set feature failure NVMe: Disk stats for read/write commands only NVMe: Group pci related actions in functions NVMe: Separate queue alloc/free from create/delete NVMe: Separate controller init from disk discovery NVMe: Use normal shutdown NVMe: Add pci suspend/resume driver callbacks NVMe: Handle ioremap failure NVMe: Merge issue on character device bring-up Matthew Wilcox (6): NVMe: Restructure MSI / MSI-X setup NVMe: Return correct value from interrupt handler NVMe: Remove "process_cq did something" message NVMe: Call nvme_process_cq from submission path NVMe: Split header file into user-visible and kernel-visible pieces NVMe: Namespace IDs are unsigned Tushar Behera (1): NVMe: Use kzalloc instead of kmalloc+memset drivers/block/nvme-core.c | 585 +++--- drivers/block/nvme-scsi.c | 24 +- include/linux/nvme.h | 466 +--- include/uapi/linux/Kbuild | 1 + include/uapi/linux/nvme.h | 477 + 5 files changed, 895 insertions(+), 658 deletions(-) create mode 100644 include/uapi/linux/nvme.h -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] Camera drivers for Nokia RX-51
On Thursday 04 April 2013 15:11:27 Laurent Pinchart wrote: > Hi Sakari, > > On Thursday 04 April 2013 01:22:28 Sakari Ailus wrote: > > On Tue, Mar 26, 2013 at 12:07:01AM +0100, Laurent Pinchart wrote: > > > On Sunday 24 March 2013 23:46:01 Sakari Ailus wrote: > > > > Pali Rohár wrote: > > > > > On Thursday 07 March 2013 23:18:27 Sakari Ailus wrote: > > > > >> On Wed, Mar 06, 2013 at 10:44:41PM +0100, Sebastian Reichel wrote: > > > > >>> On Wed, Mar 06, 2013 at 09:20:16PM +0100, Pali Rohár wrote: > > > > On Wednesday 06 March 2013 21:12:06 Pali Rohár wrote: > > > > > On Sunday 17 February 2013 20:03:03 Aaro Koskinen wrote: > > > > >> On Sun, Feb 17, 2013 at 04:16:49PM +0100, Pali Rohár wrote: > > > > >>> +/* > > > > >>> + * arch/arm/mach-omap2/board-rx51-camera.c > > > > >>> + * > > > > >>> + * Copyright (C) 2008 Nokia Corporation > > > > >>> + * > > > > >>> + * Contact: Sakari Ailus > > > > >>> + * Tuukka > > > > >>> Toivonen > > > > >> > > > > >> You should put these people to CC... Just to see > > > > >> if the addresses are still valid (which I > > > > >> doubt). > > > > > > > > > > Ok, trying :-) > > > > > > > > I got "Delivery Status Notification (Failure)" for > > > > both addresses. > > > > >> > > > > >> This is expected. > > > > >> > > > > >>> Sakari Ailus hosts some code on github [0], which > > > > >>> has the following email address: > > > > >>> sakari.ailus+gitori...@retiisi.org.uk > > > > >>> > > > > >>> I added it to this mail's CC. > > > > >>> > > > > >>> [0] https://gitorious.org/~sailus > > > > >> > > > > >> Nice to hear people are interested in this. ;-) > > > > >> > > > > >> The primary reason I haven't tried submitting this to > > > > >> mainline is that ARM board code has a bad reputation > > > > >> these days. The N900 does not have yet support for > > > > >> device tree (AFAIK), which also would require a few > > > > >> bits and pieces on the flash driver to work. > > > > >> > > > > >> Also the sensor and lens drivers would need at least > > > > >> some work before being ready for submission to > > > > >> mainline for camera to be usable. Unfortunately I > > > > >> haven't had recently time to work on this. N9(50) > > > > >> support has higher priority for myself. That, too, > > > > >> is pending the DT support for the device. > > > > >> > > > > >> There's indeed more up-to-date code in my repository. > > > > >> Even if it's not too close to mainline anymore it > > > > >> should be a better starting point than the old > > > > >> kernel from MeeGo. > > > > >> > > > > >> https://gitorious.org/omap3camera/pages/Home> > > > > > > > > > > Hi, > > > > > > > > > > this board code is same in your git repository and on > > > > > meego obs. > > > > > > > > > > Patch only adding support for adp1653 driver which is > > > > > already in upstream kernel. > > > > > > > > > > Are there any other problems with this patch to go for > > > > > upstream? > > > > > > > > A few more things comes to mind. We depend a little bit > > > > on actual board code; it's not only static data. That's > > > > the configuration of the external clock from the ISP to > > > > the sensor. That should move to the common clock > > > > framework so that the ISP registers the clock and the > > > > sensor driver can then use it. AFAIR Laurent has done > > > > some work on that. > > > > > > Yes. I hope to get the patches in v3.10. > > > > Cool! :) > > The patches have been posted to the linux-media mailing list. > If the dependencies make it to v3.10 the OMAP3 ISP patches > should get there too. > > > > > The peculiar detail of the rx51 is that there's a switch > > > > on the camera CCP2 bus that selects either sensor > > > > (primary or secondary). Both sensors are connected to > > > > the same receiver. That isn't properly modelled > > > > currently at all, so that's why we have > > > > rx51_camera_set_xshutdown(). I guess it'd still work if > > > > you only power (i.e. open) either of the devices at a > > > > time, though. > > > > > > Have you thought about how we could model that ? > > > > Well, the two dependent gpios could be modelled as two > > independent ones ( for sensor drivers), but setting the > > state of those gpios could fail, gpio_set_value() still > > returns void. This isn't pretty perhaps but as a result the > > initialisation of the secondary sensor to be powered up at > > the same time will fail since it's in reset: the xshutdown > > of both sensors is controlled by the same gpio as is the > > mux (AFAIR). > > > > So one N900 camera specific gpio driver would be needed. > > It'd be a very simple driver. What do you think? > > I think I'll need to see how the GPIOs are wired up on the > board. Hello, after months, what is state of drivers now? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH] rcu: Is it safe to enter an RCU read-side critical section?
On Fri, Sep 06, 2013 at 08:59:29PM +0200, Frederic Weisbecker wrote:
> On Fri, Sep 06, 2013 at 10:41:17AM -0700, Paul E. McKenney wrote:
> > On Fri, Sep 06, 2013 at 10:21:28AM -0700, Eric Dumazet wrote:
> > > On Fri, 2013-09-06 at 08:18 -0700, Paul E. McKenney wrote:
> > >
> > > > int rcu_is_cpu_idle(void)
> > > > {
> > > > int ret;
> > > >
> > > > preempt_disable();
> > > > ret = (atomic_read(&__get_cpu_var(rcu_dynticks).dynticks) &
> > > > 0x1) == 0;
> > > > preempt_enable();
> > > > return ret;
> > > > }
> > >
> > > Paul I find this very confusing.
> > >
> > > If caller doesn't have preemption disabled, what could be the meaning of
> > > this rcu_is_cpu_idle() call ?
> > >
> > > Its result is meaningless if suddenly thread is preempted, so what is
> > > the point ?
> > >
> > > Sorry if this is obvious to you.
> >
> > It is a completely fair question. In fact, this might well now be
> > pointing to a bug given NO_HZ_FULL.
> >
> > The assumption is that if you don't have preemption disabled, you had
> > better be running on a CPU that RCU is paying attention to. The rationale
> > involves preemptible RCU.
> >
> > Suppose that you just did rcu_read_lock() on a CPU that RCU is paying
> > attention to. All is well, and rcu_is_cpu_idle() will return false, as
> > expected. Suppose now that it is possible to be preempted and suddenly
> > find yourself running on a CPU that RCU is not paying attention to.
> > This would have the effect of making your RCU read-side critical section
> > be ignored. Therefore, it had better not be possible to be preempted
> > from a CPU to which RCU is paying attention to a CPU that RCU is ignoring.
> >
> > So if rcu_is_cpu_idle() returns false, you had better be guaranteed
> > that whatever CPU you are running on (which might well be a different
> > one than the rcu_is_cpu_idle() was running on) is being watched by RCU.
> >
> > So, Frederic, does this still work with NO_HZ_FULL? If not, I believe
> > we have a bigger problem than the preempt_disable() in rcu_is_cpu_idle()!
>
> Sure it works well, because the scheduler task entrypoints exit those RCU
> extended quiescent states.
>
> Imagine that you're running on an rcu read side critical section on CPU 0,
> which
> is not in extended quiescent state. Now you get preempted in the middle of
> your
> RCU read side critical section (you called rcu_read_lock() but not yet
> rcu_read_unlock()).
>
> Later on, the task is woken up to be scheduled in CPU 1. If CPU 1 is in
> extended
> quiescent state because it runs is userspace, it receives a scheduler IPI,
> then schedule_user() is called by the end of the interrupt and in turns calls
> rcu_user_exit()
> before the task is resumed to the code it was running on CPU 0, in the middle
> of
> the rcu read side extended quiescent state.
>
> See, the key here is the rcu_user_exit() that restore the CPU on RCU's state
> machine.
> There are other possible scheduler entrypoints when a CPU runs in user
> extended quiescent
> state: exception and syscall entries or even preempt_schedule_irq() in case
> we receive an irq
> in the kernel while we haven't yet reached the call to rcu_user_exit()... All
> of these should
> be covered, otherwise you bet RCU would be prompt to warn.
>
> That's why when we call rcu_is_cpu_idle() from an RCU read side critical
> section, it's legit even
> if we can be preempted anytime around it.
> And preempt_disable() is probably not even necessary, except perhaps if
> __get_cpu_var() itself
> relies on non-preemptibility for its own correctness on the address
> calculation.
Whew!!! ;-)
But the problem for rcu_is_cpu_idle() was not the calls from the scheduler,
but rather those from lockdep. If the overhead is a concern, you could
switch to the primitives I will be supplying for Steven.
Thanx, Paul
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ADP1653 board code for Nokia RX-51
On Wednesday 06 March 2013 21:12:06 Pali Rohár wrote:
> On Sunday 17 February 2013 20:03:03 Aaro Koskinen wrote:
> > Hi,
> >
> > On Sun, Feb 17, 2013 at 04:16:49PM +0100, Pali Rohár wrote:
> > > I'm sending ADP1653 flash torch board code for Nokia
> > > RX-51. Kernel driver ADP1653 is already in upstream
> > > kernel. Board code was extracted from this big camera
> > > meego patch:
> > >
> > > https://api.pub.meego.com/public/source/CE:Adaptation:N900
> > > /k
> > > ernel-adaptation-n900/linux-2.6-Camera-for-Meego-N900-Ada
> > > pta tion-kernel-2.6.37-patch.patch
> >
> > You need to sign-off the patch.
>
> Signed-off-by: Pali Rohár
>
> > > --- /dev/null
> > > +++ b/arch/arm/mach-omap2/board-rx51-camera.c
> >
> > I'm not sure if adding a new file is sensible. There are
> > already 3 board files for RX-51, which I think is overkill.
>
> You can see that camera board code is big, so code was moved
> to separate file. Because not all camera drivers are
> upstreamed yet there is no camera support in RX-51 board
> code. Current peripheral file for RX-51 is big too and split
> camera code into separate file can be usefull...
>
> > > @@ -0,0 +1,177 @@
> > > +/*
> > > + * arch/arm/mach-omap2/board-rx51-camera.c
> > > + *
> > > + * Copyright (C) 2008 Nokia Corporation
> > > + *
> > > + * Contact: Sakari Ailus
> > > + * Tuukka Toivonen
> >
> > You should put these people to CC... Just to see if the
> > addresses are still valid (which I doubt).
>
> Ok, trying :-)
>
> > > +static int __init rx51_adp1653_init(void)
> > > +{
> > > + int err;
> > > +
> > > + err = gpio_request(ADP1653_GPIO_ENABLE, "adp1653
> > > enable"); + if (err) {
> > > + printk(KERN_ERR ADP1653_NAME
> > > +" Failed to request EN gpio\n");
> > > + err = -ENODEV;
> > > + goto err_omap_request_gpio;
> > > + }
> > > +
> > > + err = gpio_request(ADP1653_GPIO_INT, "adp1653
> > > interrupt"); +if (err) {
> > > + printk(KERN_ERR ADP1653_NAME " Failed to request IRQ
> > > gpio\n"); + err = -ENODEV;
> > > + goto err_omap_request_gpio_2;
> > > + }
> > > +
> > > + err = gpio_request(ADP1653_GPIO_STROBE, "adp1653
> > > strobe"); + if (err) {
> > > + printk(KERN_ERR ADP1653_NAME
> > > +" Failed to request STROBE gpio\n");
> > > + err = -ENODEV;
> > > + goto err_omap_request_gpio_3;
> > > + }
> > > +
> > > + gpio_direction_output(ADP1653_GPIO_ENABLE, 0);
> > > + gpio_direction_input(ADP1653_GPIO_INT);
> > > + gpio_direction_output(ADP1653_GPIO_STROBE, 0);
> >
> > gpio_request_array() should be used.
>
> Ok, fixing this.
>
> > > +void __init rx51_camera_init(void)
> > > +{
> > > + if (rx51_camera_hw_init()) {
> > > + printk(KERN_WARNING "%s: Unable to initialize
> > > camera\n", + __func__);
> > > + return;
> > > + }
> > > +
> > > + if (omap3_init_camera(_isp_platform_data) < 0)
> > > + printk(KERN_WARNING "%s: Unable to register camera
> > > platform " + "device\n", __func__);
> >
> > pr_warn() should be used.
> >
> > A.
>
> Fixed too.
>
> Here is new version v2 of this patch:
>
> diff --git a/arch/arm/mach-omap2/Kconfig
> b/arch/arm/mach-omap2/Kconfig index 41b581f..268fa57 100644
> --- a/arch/arm/mach-omap2/Kconfig
> +++ b/arch/arm/mach-omap2/Kconfig
> @@ -287,6 +287,7 @@ config MACH_NOKIA_RX51
> depends on ARCH_OMAP3
> default y
> select OMAP_PACKAGE_CBB
> + select VIDEO_ADP1653 if VIDEO_OMAP3 &&
> VIDEO_HELPER_CHIPS_AUTO
>
> config MACH_OMAP_ZOOM2
> bool "OMAP3 Zoom2 board"
> diff --git a/arch/arm/mach-omap2/Makefile
> b/arch/arm/mach-omap2/Makefile index 947cafe..f20f693 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -236,6 +236,7 @@ obj-$(CONFIG_MACH_NOKIA_RM680)+=
> board-rm680.o sdram-nokia.o obj-$(CONFIG_MACH_NOKIA_RX51) +=
> board-rx51.o sdram-nokia.o obj-$(CONFIG_MACH_NOKIA_RX51)
+=
> board-rx51-peripherals.o obj-$(CONFIG_MACH_NOKIA_RX51)+=
> board-rx51-video.o +obj-$(CONFIG_MACH_NOKIA_RX51) +=
> board-rx51-camera.o obj-$(CONFIG_MACH_OMAP_ZOOM2) +=
> board-zoom.o board-zoom-peripherals.o
> obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom-display.o
> obj-$(CONFIG_MACH_OMAP_ZOOM2) += board-zoom-debugboard.o
> diff --git a/arch/arm/mach-omap2/board-rx51-camera.c
> b/arch/arm/mach-omap2/board-rx51-camera.c new file mode
> 100644
> index 000..80057ab
> --- /dev/null
> +++ b/arch/arm/mach-omap2/board-rx51-camera.c
> @@ -0,0 +1,152 @@
> +/*
> + * arch/arm/mach-omap2/board-rx51-camera.c
> + *
> + * Copyright (C) 2008 Nokia Corporation
> + *
> + * Contact: Sakari Ailus
> + * Tuukka Toivonen
> + *
> + * This program is free software; you can redistribute it
> and/or + * modify it under the terms of the GNU General
> Public License + * version 2 as published by the Free
>
[PATCH] ARM: msm: Remove irqs-*.h files for DT based targets
We don't want or need the irqs.h files from the DT based MSM targets. Remove these header files and select sparse irq so that we don't try to include the mach/irqs.h file. Signed-off-by: Stephen Boyd --- On 09/06, Josh Cartwright wrote: > > Selecting _only_ ARCH_MSM8974 with these changes breaks the build with: I've been meaning to fix this. Perhaps you can use this patch as a base and then push the SPARSE_IRQ selection into the DT config? arch/arm/mach-msm/Kconfig | 2 + arch/arm/mach-msm/include/mach/irqs-8960.h | 277 - arch/arm/mach-msm/include/mach/irqs-8x60.h | 258 --- arch/arm/mach-msm/include/mach/irqs.h | 5 - 4 files changed, 2 insertions(+), 540 deletions(-) delete mode 100644 arch/arm/mach-msm/include/mach/irqs-8960.h delete mode 100644 arch/arm/mach-msm/include/mach/irqs-8x60.h diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig index 905efc8..30b3342 100644 --- a/arch/arm/mach-msm/Kconfig +++ b/arch/arm/mach-msm/Kconfig @@ -50,6 +50,7 @@ config ARCH_MSM8X60 select HAVE_SMP select MSM_SCM if SMP select USE_OF + select SPARSE_IRQ config ARCH_MSM8960 bool "MSM8960" @@ -59,6 +60,7 @@ config ARCH_MSM8960 select GPIO_MSM_V2 select MSM_SCM if SMP select USE_OF + select SPARSE_IRQ config MSM_HAS_DEBUG_UART_HS bool diff --git a/arch/arm/mach-msm/include/mach/irqs-8960.h b/arch/arm/mach-msm/include/mach/irqs-8960.h deleted file mode 100644 index 81ab2a6..000 --- a/arch/arm/mach-msm/include/mach/irqs-8960.h +++ /dev/null @@ -1,277 +0,0 @@ -/* Copyright (c) 2011 Code Aurora Forum. All rights reserved. - * - * This program is free software; you can redistribute it and/or modify - * it under the terms of the GNU General Public License version 2 and - * only version 2 as published by the Free Software Foundation. - * - * This program is distributed in the hope that it will be useful, - * but WITHOUT ANY WARRANTY; without even the implied warranty of - * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the - * GNU General Public License for more details. - */ - -#ifndef __ASM_ARCH_MSM_IRQS_8960_H -#define __ASM_ARCH_MSM_IRQS_8960_H - -/* MSM ACPU Interrupt Numbers */ - -/* 0-15: STI/SGI (software triggered/generated interrupts) - 16-31: PPI (private peripheral interrupts) - 32+: SPI (shared peripheral interrupts) */ - -#define GIC_PPI_START 16 -#define GIC_SPI_START 32 - -#define INT_VGIC (GIC_PPI_START + 0) -#define INT_DEBUG_TIMER_EXP(GIC_PPI_START + 1) -#define INT_GP_TIMER_EXP (GIC_PPI_START + 2) -#define INT_GP_TIMER2_EXP (GIC_PPI_START + 3) -#define WDT0_ACCSCSSNBARK_INT (GIC_PPI_START + 4) -#define WDT1_ACCSCSSNBARK_INT (GIC_PPI_START + 5) -#define AVS_SVICINT(GIC_PPI_START + 6) -#define AVS_SVICINTSWDONE (GIC_PPI_START + 7) -#define CPU_DBGCPUXCOMMRXFULL (GIC_PPI_START + 8) -#define CPU_DBGCPUXCOMMTXEMPTY (GIC_PPI_START + 9) -#define CPU_SICCPUXPERFMONIRPTREQ (GIC_PPI_START + 10) -#define SC_AVSCPUXDOWN (GIC_PPI_START + 11) -#define SC_AVSCPUXUP (GIC_PPI_START + 12) -#define SC_SICCPUXACGIRPTREQ (GIC_PPI_START + 13) -#define SC_SICCPUXEXTFAULTIRPTREQ (GIC_PPI_START + 14) -/* PPI 15 is unused */ - -#define SC_SICMPUIRPTREQ (GIC_SPI_START + 0) -#define SC_SICL2IRPTREQ(GIC_SPI_START + 1) -#define SC_SICL2PERFMONIRPTREQ (GIC_SPI_START + 2) -#define SC_SICAGCIRPTREQ (GIC_SPI_START + 3) -#define TLMM_APCC_DIR_CONN_IRQ_0 (GIC_SPI_START + 4) -#define TLMM_APCC_DIR_CONN_IRQ_1 (GIC_SPI_START + 5) -#define TLMM_APCC_DIR_CONN_IRQ_2 (GIC_SPI_START + 6) -#define TLMM_APCC_DIR_CONN_IRQ_3 (GIC_SPI_START + 7) -#define TLMM_APCC_DIR_CONN_IRQ_4 (GIC_SPI_START + 8) -#define TLMM_APCC_DIR_CONN_IRQ_5 (GIC_SPI_START + 9) -#define TLMM_APCC_DIR_CONN_IRQ_6 (GIC_SPI_START + 10) -#define TLMM_APCC_DIR_CONN_IRQ_7 (GIC_SPI_START + 11) -#define TLMM_APCC_DIR_CONN_IRQ_8 (GIC_SPI_START + 12) -#define TLMM_APCC_DIR_CONN_IRQ_9 (GIC_SPI_START + 13) -#define PM8921_SEC_IRQ_103 (GIC_SPI_START + 14) -#define PM8018_SEC_IRQ_106 (GIC_SPI_START + 15) -#define TLMM_APCC_SUMMARY_IRQ (GIC_SPI_START + 16) -#define SPDM_RT_1_IRQ (GIC_SPI_START + 17) -#define SPDM_DIAG_IRQ (GIC_SPI_START + 18) -#define RPM_APCC_CPU0_GP_HIGH_IRQ (GIC_SPI_START + 19) -#define RPM_APCC_CPU0_GP_MEDIUM_IRQ
Re: [PATCH v2 3/6] powerpc/pci: use pci_is_pcie() to simplify code
On Thu, Sep 05, 2013 at 03:55:27PM +0800, Yijing Wang wrote:
> Use pci_is_pcie() to simplify code.
>
> Acked-by: Kumar Gala
> Reviewed-by: Gavin Shan
> Signed-off-by: Yijing Wang
> Cc: Gavin Shan
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: linux-kernel@vger.kernel.org
> ---
> arch/powerpc/kernel/eeh.c |3 +--
> arch/powerpc/sysdev/fsl_pci.c |2 +-
> 2 files changed, 2 insertions(+), 3 deletions(-)
Ben, Paul, this has no dependencies on anything new to PCI or any
other patches in this series, so you can take it through the POWERPC
tree. If you don't want to do that, let me know and I can take it.
If you want it:
Acked-by: Bjorn Helgaas
> diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
> index 55593ee..6ebbe54 100644
> --- a/arch/powerpc/kernel/eeh.c
> +++ b/arch/powerpc/kernel/eeh.c
> @@ -189,8 +189,7 @@ static size_t eeh_gather_pci_data(struct eeh_dev *edev,
> char * buf, size_t len)
> }
>
> /* If PCI-E capable, dump PCI-E cap 10, and the AER */
> - cap = pci_find_capability(dev, PCI_CAP_ID_EXP);
> - if (cap) {
> + if (pci_is_pcie(dev)) {
> n += scnprintf(buf+n, len-n, "pci-e cap10:\n");
> printk(KERN_WARNING
> "EEH: PCI-E capabilities and status follow:\n");
> diff --git a/arch/powerpc/sysdev/fsl_pci.c b/arch/powerpc/sysdev/fsl_pci.c
> index 46ac1dd..5402a1d 100644
> --- a/arch/powerpc/sysdev/fsl_pci.c
> +++ b/arch/powerpc/sysdev/fsl_pci.c
> @@ -41,7 +41,7 @@ static void quirk_fsl_pcie_header(struct pci_dev *dev)
> u8 hdr_type;
>
> /* if we aren't a PCIe don't bother */
> - if (!pci_find_capability(dev, PCI_CAP_ID_EXP))
> + if (!pci_is_pcie(dev))
> return;
>
> /* if we aren't in host mode don't bother */
> --
> 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/
[GIT] kbuild misc updates for v3.12-rc1
Hi Linus, in the kbuild misc branch, I have: - make rpm-pkg updates, most importantly the rpm package now calls /sbin/installkernel - make deb-pkg: debuginfo split, correct kernel image path for parisc, mips and powerpc and a couple more minor fixes - New coccinelle check Thanks, Michal The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092: Linux 3.11-rc1 (2013-07-14 15:18:27 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild.git misc Anisse Astier (4): deb-pkg: use KCONFIG_CONFIG instead of .config file directly deb-pkg: split debug symbols in their own package deb-pkg: fix installed image path on parisc, mips and powerpc deb-pkg: add a hook argument to match debian hooks parameters Heinrich Schuchardt (1): Provide version number for Debian firmware package Max Filippov (1): scripts/checkkconfigsymbols.sh: replace echo -e with printf Mike Marciniszyn (3): rpm-pkg: add %post section to create initramfs and grub hooks rpm-pkg: install firmware files in kernel relative directory rpm-pkg: add generation of kernel-devel Rasmus Villemoes (1): coccinelle: replace 0/1 with false/true in functions returning bool scripts/checkkconfigsymbols.sh |4 +- scripts/coccinelle/misc/boolreturn.cocci | 58 ++ scripts/package/builddeb | 94 +- scripts/package/mkspec | 46 +-- 4 files changed, 178 insertions(+), 24 deletions(-) create mode 100644 scripts/coccinelle/misc/boolreturn.cocci -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/5] cpufreq: Synchronize the cpufreq store_*() routines with CPU hotplug
The functions that are used to write to cpufreq sysfs files (such as store_scaling_max_freq()) are not hotplug safe. They can race with CPU hotplug tasks and lead to problems such as trying to acquire an already destroyed timer-mutex etc. Eg: __cpufreq_remove_dev() __cpufreq_governor(policy, CPUFREQ_GOV_STOP); policy->governor->governor(policy, CPUFREQ_GOV_STOP); cpufreq_governor_dbs() case CPUFREQ_GOV_STOP: mutex_destroy(_cdbs->timer_mutex) cpu_cdbs->cur_policy = NULL; store() __cpufreq_set_policy() __cpufreq_governor(policy, CPUFREQ_GOV_LIMITS); policy->governor->governor(policy, CPUFREQ_GOV_LIMITS); case CPUFREQ_GOV_LIMITS: mutex_lock(_cdbs->timer_mutex); <-- Warning (destroyed mutex) if (policy->max < cpu_cdbs->cur_policy->cur) <- cur_policy == NULL So use get_online_cpus()/put_online_cpus() in the store_*() functions, to synchronize with CPU hotplug. However, there is an additional point to note here: some parts of the CPU teardown in the cpufreq subsystem are done in the CPU_POST_DEAD stage, with cpu_hotplug.lock *released*. So, using the get/put_online_cpus() functions alone is insufficient; we should also ensure that we don't race with those latter steps in the hotplug sequence. We can easily achieve this by checking if the CPU is online before proceeding with the store, since the CPU would have been marked offline by the time the CPU_POST_DEAD notifiers are executed. Reported-by: Stephen Boyd Signed-off-by: Srivatsa S. Bhat --- drivers/cpufreq/cpufreq.c | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c index a6fe3fd..c2eb413 100644 --- a/drivers/cpufreq/cpufreq.c +++ b/drivers/cpufreq/cpufreq.c @@ -717,8 +717,13 @@ static ssize_t store(struct kobject *kobj, struct attribute *attr, struct freq_attr *fattr = to_attr(attr); ssize_t ret = -EINVAL; + get_online_cpus(); + + if (!cpu_online(policy->cpu)) + goto unlock; + if (!down_read_trylock(_rwsem)) - goto exit; + goto unlock; if (lock_policy_rwsem_write(policy->cpu) < 0) goto up_read; @@ -732,7 +737,9 @@ static ssize_t store(struct kobject *kobj, struct attribute *attr, up_read: up_read(_rwsem); -exit: +unlock: + put_online_cpus(); + 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: [PATCHv3 1/2] ARM: msm: Add support for APQ8074 Dragonboard
On Fri, Sep 06, 2013 at 12:32:22PM -0700, Rohit Vaswani wrote:
> This patch adds basic board support for APQ8074 Dragonboard
> which belongs to the Snapdragon 800 family.
> For now, just support a basic machine with device tree.
>
> Signed-off-by: Rohit Vaswani
> ---
[..]
> index 000..5b7b6a0
> --- /dev/null
> +++ b/arch/arm/boot/dts/apq8074-dragonboard.dts
> @@ -0,0 +1,6 @@
> +/include/ "msm8974.dtsi"
> +
> +/ {
> + model = "Qualcomm APQ8074 Dragonboard";
> + compatible = "qcom,apq8074-dragonboard", "qcom,apq8074";
> +};
> diff --git a/arch/arm/boot/dts/msm8974.dtsi b/arch/arm/boot/dts/msm8974.dtsi
> new file mode 100644
> index 000..f04b643
> --- /dev/null
> +++ b/arch/arm/boot/dts/msm8974.dtsi
> @@ -0,0 +1,35 @@
> +/dts-v1/;
> +
> +/include/ "skeleton.dtsi"
> +
> +/ {
> + model = "Qualcomm MSM8974";
> + compatible = "qcom,msm8974";
> + interrupt-parent = <>;
> +
> + soc: soc { };
> +};
> +
> + {
Breaking these up seems a little odd to me, but okay.
> + #address-cells = <1>;
> + #size-cells = <1>;
> + ranges;
> + compatible = "simple-bus";
> +
> + intc: interrupt-controller@f900 {
> + compatible = "qcom,msm-qgic2";
> + interrupt-controller;
> + #interrupt-cells = <3>;
> + reg = <0xf900 0x1000>,
> + <0xf9002000 0x1000>;
> + };
> +
> + timer {
> + compatible = "arm,armv7-timer";
> + interrupts = <1 2 0xf08>,
> + <1 3 0xf08>,
> + <1 4 0xf08>,
> + <1 1 0xf08>;
> + clock-frequency = <1920>;
> + };
> +};
> diff --git a/arch/arm/mach-msm/Kconfig b/arch/arm/mach-msm/Kconfig
> index 905efc8..499e8fe 100644
> --- a/arch/arm/mach-msm/Kconfig
> +++ b/arch/arm/mach-msm/Kconfig
[..]
> +config ARCH_MSM8974
> + bool "MSM8974"
> + select ARM_GIC
> + select CPU_V7
> + select HAVE_ARM_ARCH_TIMER
> + select HAVE_SMP
> + select MSM_SCM if SMP
> + select USE_OF
> +
> +config ARCH_MSM_DT
> + def_bool y
> + depends on (ARCH_MSM8X60 || ARCH_MSM8960 || ARCH_MSM8974)
> +
Selecting _only_ ARCH_MSM8974 with these changes breaks the build with:
scripts/kconfig/conf --silentoldconfig Kconfig
#
# configuration written to .config
#
CHK include/generated/uapi/linux/version.h
CHK include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
CC arch/arm/kernel/asm-offsets.s
GEN include/generated/asm-offsets.h
CALLscripts/checksyscalls.sh
CC init/main.o
In file included from arch/arm/include/asm/irq.h:7:0,
from arch/arm/include/asm/hardirq.h:6,
from include/linux/hardirq.h:8,
from include/linux/ftrace_event.h:7,
from include/trace/syscall.h:6,
from include/linux/syscalls.h:79,
from init/main.c:18:
arch/arm/mach-msm/include/mach/irqs.h:35:2: error: #error "Unknown architecture
specification"
#error "Unknown architecture specification"
^
arch/arm/mach-msm/include/mach/irqs.h:38:18: error: 'NR_MSM_IRQS' undeclared
here (not in a function)
#define NR_IRQS (NR_MSM_IRQS + NR_GPIO_IRQS + NR_BOARD_IRQS)
^
include/linux/irqdesc.h:76:33: note: in expansion of macro 'NR_IRQS'
extern struct irq_desc irq_desc[NR_IRQS];
^
arch/arm/mach-msm/include/mach/irqs.h:38:32: error: 'NR_GPIO_IRQS' undeclared
here (not in a function)
#define NR_IRQS (NR_MSM_IRQS + NR_GPIO_IRQS + NR_BOARD_IRQS)
^
include/linux/irqdesc.h:76:33: note: in expansion of macro 'NR_IRQS'
extern struct irq_desc irq_desc[NR_IRQS];
^
arch/arm/mach-msm/include/mach/irqs.h:38:47: error: 'NR_BOARD_IRQS' undeclared
here (not in a function)
#define NR_IRQS (NR_MSM_IRQS + NR_GPIO_IRQS + NR_BOARD_IRQS)
^
include/linux/irqdesc.h:76:33: note: in expansion of macro 'NR_IRQS'
extern struct irq_desc irq_desc[NR_IRQS];
^
make[1]: *** [init/main.o] Error 1
make: *** [init] Error 2
Josh
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [GIT] HID for 3.12 merge window
On 2013.09.06 at 14:00 +0200, Jiri Kosina wrote: > > David Herrmann (12): ... > HID: wiimote: add support for Guitar-Hero drums commit 61e00655e9cb82e034eb72b95a51072e718d14a7 Author: David Herrmann Date: Mon Aug 26 19:14:46 2013 +0200 Input: introduce BTN/ABS bits for drums and guitars The commit above breaks my Logitech mouse. The mouse cursor just sits in the middle of the screen and doesn't react to movements. dmesg is normal, but Xorg.0.log says: [ 5.717] (II) config/udev: Adding input device Logitech Unifying Device. Wireless PID:4026 (/dev/input/event0) [ 5.717] (**) Logitech Unifying Device. Wireless PID:4026: Applying InputClass "evdev pointer catchall" [ 5.717] (**) Logitech Unifying Device. Wireless PID:4026: Applying InputClass "evdev keyboard catchall" [ 5.717] (II) Using input driver 'evdev' for 'Logitech Unifying Device. Wireless PID:4026' [ 5.717] (**) Logitech Unifying Device. Wireless PID:4026: always reports core events [ 5.717] (**) evdev: Logitech Unifying Device. Wireless PID:4026: Device: "/dev/input/event0" [ 5.717] (EE) evdev: Logitech Unifying Device. Wireless PID:4026: ioctl EVIOCGABSi(32) failed: Invalid argument [ 5.763] (EE) PreInit returned 8 for "Logitech Unifying Device. Wireless PID:4026" [ 5.763] (II) UnloadModule: "evdev" [ 5.763] (II) config/udev: Adding input device Logitech Unifying Device. Wireless PID:4026 (/dev/input/mouse0) [ 5.763] (II) No input driver specified, ignoring this device. [ 5.763] (II) This device may have been added with another device file. I've double-checked the bisection by reverting the commit on top of current tree and this fixes the issue... >From dmesg: [1.551437] XFS (sda): Mounting Filesystem [1.555823] tsc: Refined TSC clocksource calibration: 3210.826 MHz [1.729233] usb 4-2: new full-speed USB device number 2 using ohci-pci [1.857691] XFS (sda): Ending clean mount [1.915581] logitech-djreceiver 0003:046D:C52B.0003: hiddev0,hidraw0: USB HID v1.11 Device [Logitech USB Receiver] on usb-:00:12.1-2/input2 [1.920263] input: Logitech Unifying Device. Wireless PID:4026 as /devices/pci:00/:00:12.1/usb4/4-2/4-2:1.2/0003:046D:C52B.0003/input/input0 [1.920479] logitech-djdevice 0003:046D:C52B.0004: input,hidraw1: USB HID v1.11 Keyboard [Logitech Unifying Device. Wireless PID:4026] on usb-:00:12.1-2:1 [2.042641] usb 3-1: new low-speed USB device number 2 using ohci-pci [2.204791] input: HID 046a:0011 as /devices/pci:00/:00:12.0/usb3/3-1/3-1:1.0/input/input1 [2.204975] hid-generic 0003:046A:0011.0005: input,hidraw2: USB HID v1.10 Keyboard [HID 046a:0011] on usb-:00:12.0-1/input0 [2.341424] udevd[98]: starting eudev version 1.0 [2.556172] Switched to clocksource tsc [2.791794] ATL1E :02:00.0 eth0: NIC Link is Up <1000 Mbps Full Duplex> [3.945433] Adding 3071996k swap on /var/cache/swapfile.img. Priority:-1 extents:1 across:3071996k -- Markus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] cpufreq: Split __cpufreq_remove_dev() into 2 parts (kobj cleanup & the rest)
During CPU offline, the cpufreq core invokes __cpufreq_remove_dev() to
perform work such as stopping the cpufreq governor, clearing the CPU from
the policy structure etc, and finally cleaning up the kobject.
There are certain subtle issues related to the kobject cleanup, and it would
be much easier to deal with them if we separate that part from the rest of
the cleanup-work in the CPU offline phase. So split the __cpufreq_remove_dev()
function into 2 parts: one that handles the kobject cleanup, and the other
that handles the rest of the work.
Reported-by: Stephen Boyd
Signed-off-by: Srivatsa S. Bhat
---
drivers/cpufreq/cpufreq.c | 65 +
1 file changed, 53 insertions(+), 12 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index ecc55d1..3e5aeb6 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1164,22 +1164,14 @@ static int cpufreq_nominate_new_policy_cpu(struct
cpufreq_policy *policy,
return cpu_dev->id;
}
-/**
- * __cpufreq_remove_dev - remove a CPU device
- *
- * Removes the cpufreq interface for a CPU device.
- * Caller should already have policy_rwsem in write mode for this CPU.
- * This routine frees the rwsem before returning.
- */
-static int __cpufreq_remove_dev(struct device *dev,
- struct subsys_interface *sif, bool frozen)
+static int __cpufreq_remove_dev_prepare(struct device *dev,
+ struct subsys_interface *sif,
+ bool frozen)
{
unsigned int cpu = dev->id, cpus;
int new_cpu, ret;
unsigned long flags;
struct cpufreq_policy *policy;
- struct kobject *kobj;
- struct completion *cmp;
pr_debug("%s: unregistering CPU %u\n", __func__, cpu);
@@ -1236,6 +1228,33 @@ static int __cpufreq_remove_dev(struct device *dev,
}
}
+ return 0;
+}
+
+static int __cpufreq_remove_dev_finish(struct device *dev,
+ struct subsys_interface *sif,
+ bool frozen)
+{
+ unsigned int cpu = dev->id, cpus;
+ int ret;
+ unsigned long flags;
+ struct cpufreq_policy *policy;
+ struct kobject *kobj;
+ struct completion *cmp;
+
+ read_lock_irqsave(_driver_lock, flags);
+ policy = per_cpu(cpufreq_cpu_data, cpu);
+ read_unlock_irqrestore(_driver_lock, flags);
+
+ if (!policy) {
+ pr_debug("%s: No cpu_data found\n", __func__);
+ return -EINVAL;
+ }
+
+ lock_policy_rwsem_read(cpu);
+ cpus = cpumask_weight(policy->cpus);
+ unlock_policy_rwsem_read(cpu);
+
/* If cpu is last user of policy, free policy */
if (cpus == 1) {
if (cpufreq_driver->target) {
@@ -1295,6 +1314,27 @@ static int __cpufreq_remove_dev(struct device *dev,
return 0;
}
+/**
+ * __cpufreq_remove_dev - remove a CPU device
+ *
+ * Removes the cpufreq interface for a CPU device.
+ * Caller should already have policy_rwsem in write mode for this CPU.
+ * This routine frees the rwsem before returning.
+ */
+static inline int __cpufreq_remove_dev(struct device *dev,
+ struct subsys_interface *sif,
+ bool frozen)
+{
+ int ret;
+
+ ret = __cpufreq_remove_dev_prepare(dev, sif, frozen);
+
+ if (!ret)
+ ret = __cpufreq_remove_dev_finish(dev, sif, frozen);
+
+ return ret;
+}
+
static int cpufreq_remove_dev(struct device *dev, struct subsys_interface *sif)
{
unsigned int cpu = dev->id;
@@ -2044,7 +2084,8 @@ static int cpufreq_cpu_callback(struct notifier_block
*nfb,
break;
case CPU_DOWN_PREPARE:
- __cpufreq_remove_dev(dev, NULL, frozen);
+ __cpufreq_remove_dev_prepare(dev, NULL, frozen);
+ __cpufreq_remove_dev_finish(dev, NULL, frozen);
break;
case CPU_DOWN_FAILED:
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] Ceph updates for 3.12 (take 2)
Hi Linus, Please pull the following Ceph updates from git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus This includes both the first pile of Ceph patches (which I sent to torvalds@vger, sigh) and a few new patches that add support for fscache for Ceph. That includes a few fscache core fixes that David Howells asked go through the Ceph tree. (Thanks go to Milosz Tanski for putting this feature together.) This first batch of patches (included here) had (has) several important RBD bug fixes, hole punch support, several different cleanups in the page cache interactions, improvements in the truncate code (new truncate mutex to avoid shenanigans with i_mutex), and a series of fixes in the synchronous striping read/write code. On top of that is a random collection of small fixes all across the tree (error code checks and error path cleanup, obsolete wq flags, etc.). Thanks! sage Dan Carpenter (4): ceph: cleanup types in striped_read() libceph: fix error handling in handle_reply() libceph: potential NULL dereference in ceph_osdc_handle_map() libceph: create_singlethread_workqueue() doesn't return ERR_PTRs David Howells (3): FS-Cache: Add interface to check consistency of a cached object CacheFiles: Implement interface to check cache consistency FS-Cache: Fix heading in documentation Jingoo Han (1): block: rbd: use NULL instead of 0 Josh Durgin (3): rbd: fix I/O error propagation for reads rbd: fix buffer size for writes to images with snapshots rbd: fix null dereference in dout Li Wang (2): ceph: punch hole support ceph: remove useless variable revoked_rdcache Milosz Tanski (10): ceph: Remove bogus check in invalidatepage ceph: cleanup the logic in ceph_invalidatepage fscache: Netfs function for cleanup post readpages Merge tag 'fscache-fixes-for-ceph' into wip-fscache ceph: use fscache as a local presisent cache ceph: clean PgPrivate2 on returning from readpages ceph: ceph_readpage_to_fscache didn't check if marked ceph: page still marked private_2 ceph: Do not do invalidate if the filesystem is mounted nofsc ceph: trivial buildbot warnings fix Nathaniel Yazdani (1): ceph: fix null pointer dereference Sage Weil (4): ceph: replace hold_mutex flag with goto Merge remote-tracking branch 'linus/master' into testing ceph: fix fallocate division libceph: use pg_num_mask instead of pgp_num_mask for pg.seed calc Sha Zhengju (1): ceph: use vfs __set_page_dirty_nobuffers interface instead of doing it inside filesystem Tejun Heo (1): ceph: WQ_NON_REENTRANT is meaningless and going away Yan, Zheng (8): ceph: drop CAP_LINK_SHARED when sending "link" request to MDS ceph: wake up writer if vmtruncate work get blocked ceph: trim deleted inode ceph: fix freeing inode vs removing session caps race ceph: introduce i_truncate_mutex ceph: fix request max size ceph: remove ceph_lookup_inode() ceph: use d_invalidate() to invalidate aliases majianpeng (7): ceph: Don't forget the 'up_read(>map_sem)' if met error. libceph: unregister request in __map_request failed and nofail == false ceph: Don't use ceph-sync-mode for synchronous-fs. ceph: Add check returned value on func ceph_calc_ceph_pg. ceph: Move the place for EOLDSNAPC handle in ceph_aio_write to easily understand ceph: fix bugs about handling short-read for sync read mode. ceph: allow sync_read/write return partial successed size of read/write. Documentation/filesystems/caching/backend-api.txt | 9 + Documentation/filesystems/caching/netfs-api.txt | 37 +- drivers/block/rbd.c | 36 +- fs/cachefiles/interface.c | 26 ++ fs/cachefiles/internal.h | 1 + fs/cachefiles/xattr.c | 36 ++ fs/ceph/Kconfig | 9 + fs/ceph/Makefile | 1 + fs/ceph/addr.c| 116 --- fs/ceph/cache.c | 398 ++ fs/ceph/cache.h | 159 + fs/ceph/caps.c| 87 - fs/ceph/dir.c | 2 + fs/ceph/file.c| 299 +--- fs/ceph/inode.c | 46 ++- fs/ceph/ioctl.c | 12 +- fs/ceph/mds_client.c | 34 ++ fs/ceph/super.c | 35 +- fs/ceph/super.h | 17 + fs/fscache/cookie.c | 71 fs/fscache/internal.h
[GIT PULL] (xen) stable/for-jens-3.12 for Jens Axboe
Hey Jens, I sent you a git pull a couple of weeks ago but I am not sure if you pulled it. It does not look like it, so here it is again along with an extra bug-fix. Please git pull: git pull git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git stable/for-jens-3.12 which will give you bug-fixes to Xen blkfront and backend driver: drivers/block/xen-blkback/blkback.c |3 +- drivers/block/xen-blkfront.c| 44 -- 2 files changed, 38 insertions(+), 9 deletions(-) Roger Pau Monne (2): xen-blkfront: revoke foreign access for grants not mapped by the backend xen-blkfront: improve aproximation of required grants per request Vegard Nossum (1): xen/blkback: fix reference counting Please pull! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 4/5] cpufreq: Remove temporary fix for race between CPU hotplug and sysfs-writes
Commit "cpufreq: serialize calls to __cpufreq_governor()" had been a temporary
and partial solution to the race condition between writing to a cpufreq sysfs
file and taking a CPU offline. Now that we have a proper and complete solution
to that problem, remove the temporary fix.
Signed-off-by: Srivatsa S. Bhat
---
drivers/cpufreq/cpufreq.c |7 +--
include/linux/cpufreq.h |1 -
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index c2eb413..9909789 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -1783,15 +1783,13 @@ static int __cpufreq_governor(struct cpufreq_policy
*policy,
policy->cpu, event);
mutex_lock(_governor_lock);
- if (policy->governor_busy
- || (policy->governor_enabled && event == CPUFREQ_GOV_START)
+ if ((policy->governor_enabled && event == CPUFREQ_GOV_START)
|| (!policy->governor_enabled
&& (event == CPUFREQ_GOV_LIMITS || event == CPUFREQ_GOV_STOP))) {
mutex_unlock(_governor_lock);
return -EBUSY;
}
- policy->governor_busy = true;
if (event == CPUFREQ_GOV_STOP)
policy->governor_enabled = false;
else if (event == CPUFREQ_GOV_START)
@@ -1820,9 +1818,6 @@ static int __cpufreq_governor(struct cpufreq_policy
*policy,
((event == CPUFREQ_GOV_POLICY_EXIT) && !ret))
module_put(policy->governor->owner);
- mutex_lock(_governor_lock);
- policy->governor_busy = false;
- mutex_unlock(_governor_lock);
return ret;
}
diff --git a/include/linux/cpufreq.h b/include/linux/cpufreq.h
index cca885d..d568f39 100644
--- a/include/linux/cpufreq.h
+++ b/include/linux/cpufreq.h
@@ -76,7 +76,6 @@ struct cpufreq_policy {
struct cpufreq_governor *governor; /* see below */
void*governor_data;
boolgovernor_enabled; /* governor start/stop flag */
- boolgovernor_busy;
struct work_struct update; /* if update_policy() needs to be
* called, but you're in IRQ context */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: EDMA: Fix clearing of unused list for DT DMA resources
On 09/06/2013 02:15 PM, Mark Jackson wrote:
> On 06/09/13 20:13, Mark Jackson wrote:
>> On 23/08/13 20:53, Joel Fernandes wrote:
>>> HWMOD removal for MMC and Crypto is breaking edma_start as the events are
>>> being manually triggered due to unused channel list not being clear. Atleast
>>> breakage has been seen on these peripherals, but it is expected Audio
>>> (McASP)
>>> maybe breaking too.
>>>
>>> This patch fixes the issue, by reading the "dmas" property from the DT node
>>> if
>>> it exists and clearing the bits in the unused channel list so that these
>>> channels
>>> are not manually triggered.
>>>
>>> v2 changes:
>>> Reduced indendation by returning from if block.
>>>
>>> Reviewed-by: Sekhar Nori
>>> Reported-by: Balaji T K
>>> Cc: Pantel Antoniou
>>> Signed-off-by: Joel Fernandes
>>> ---
>>> Note:
>>> Patch should go in for -rc cycle as it fixes existing crypto drivers.
>>>
>>> arch/arm/common/edma.c | 22 +++---
>>> 1 file changed, 19 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/arch/arm/common/edma.c b/arch/arm/common/edma.c
>>> index 39ad030..3867e7e 100644
>>> --- a/arch/arm/common/edma.c
>>> +++ b/arch/arm/common/edma.c
>>> @@ -560,14 +560,30 @@ static int reserve_contiguous_slots(int ctlr,
>>> unsigned int id,
>>> static int prepare_unused_channel_list(struct device *dev, void *data)
>>> {
>>> struct platform_device *pdev = to_platform_device(dev);
>>> - int i, ctlr;
>>> + int i = 0, ctlr;
>>> + u32 dma_chan;
>>> + const __be32 *dma_chan_p;
>>> + struct property *prop;
>>> +
>>> + if (dev->of_node) {
>>> + of_property_for_each_u32(dev->of_node, "dmas", prop,
>>> +dma_chan_p, dma_chan) {
>>> + if (i++ & 1) {
>>> + ctlr = EDMA_CTLR(dma_chan);
>>> + clear_bit(EDMA_CHAN_SLOT(dma_chan),
>>> + edma_cc[ctlr]->edma_unused);
>>> + }
>>> + }
>>> + return;
>>
>> This should return something here, otherwise we get:-
>>
>> arch/arm/common/edma.c: In function 'prepare_unused_channel_list':
>> arch/arm/common/edma.c:577:3: warning: 'return' with no value, in function
>> returning non-void [-Wreturn-type]
>
> Other than that I can confirm it fixes the issue for me ...
Thanks for pointing that out. Will fix it in the next revision.
Regards,
-Joel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] (xen) stable/for-jens-3.12 for Jens Axboe
On 09/06/2013 02:25 PM, Konrad Rzeszutek Wilk wrote: > Hey Jens, > > I sent you a git pull a couple of weeks ago but I am not sure if > you pulled it. It does not look like it, so here it is again along > with an extra bug-fix. > > Please git pull: > > git pull git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip.git > stable/for-jens-3.12 > > which will give you bug-fixes to Xen blkfront and backend driver: Thanks, I'll get the 3.12 branch set up and pulled in. I'm behind on a lot of other drivers, too. -- Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] cpufreq: Use signed type for 'ret' variable, to store negative error values
There are places where the variable 'ret' is declared as unsigned int
and then used to store negative return values such as -EINVAL. Fix them
by declaring the variable as a signed quantity.
Signed-off-by: Srivatsa S. Bhat
---
drivers/cpufreq/cpufreq.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/cpufreq/cpufreq.c b/drivers/cpufreq/cpufreq.c
index 9909789..9cc5609 100644
--- a/drivers/cpufreq/cpufreq.c
+++ b/drivers/cpufreq/cpufreq.c
@@ -460,7 +460,7 @@ static int __cpufreq_set_policy(struct cpufreq_policy
*policy,
static ssize_t store_##file_name \
(struct cpufreq_policy *policy, const char *buf, size_t count) \
{ \
- unsigned int ret; \
+ int ret;\
struct cpufreq_policy new_policy; \
\
ret = cpufreq_get_policy(_policy, policy->cpu); \
@@ -513,7 +513,7 @@ static ssize_t show_scaling_governor(struct cpufreq_policy
*policy, char *buf)
static ssize_t store_scaling_governor(struct cpufreq_policy *policy,
const char *buf, size_t count)
{
- unsigned int ret;
+ int ret;
charstr_governor[16];
struct cpufreq_policy new_policy;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/8] ceph: fscache support & upstream changes
On Fri, 6 Sep 2013, Milosz Tanski wrote: > Sage, > > I've taken David's latest changes and per his request merged his > 'fscache-fixes-for-ceph' tag then applied my changes on top of that. > In addition to the pervious changes I also added a fix for the > warnings the linux-next build bot found. > > I've given the results a quick test to make sure it builds, boots and > runs okay. The code is located in my repository: > > https://ad...@bitbucket.org/adfin/linux-fs.git in the wip-fscache-v2 branch > > I hope that this is the final go for now and thanks for everyone's patience. Looks good; I'll send this to Linus along with the other ceph patches shortly. Thanks, everyone! sage > > - Milosz > > On Fri, Sep 6, 2013 at 11:59 AM, David Howells wrote: > > Milosz Tanski wrote: > > > >> After running this for a day on some loaded machines I ran into what > >> looks like an old issue with the new code. I remember you saw an issue > >> that manifested it self in a similar way a while back. > >> > >> [13837253.462779] FS-Cache: Assertion failed > >> [13837253.462782] 3 == 5 is false > >> [13837253.462807] [ cut here ] > >> [13837253.462811] kernel BUG at fs/fscache/operation.c:414! > > > > Bah. > > > > I forgot to call fscache_op_complete(). Patch updated and repushed. > > > > Btw, I've reordered the patches to put the CIFS patch last. Can you merge > > the > > patches prior to the CIFS commit from my branch rather than cherry picking > > them so that if they go via two different routes, GIT will handle the merge > > correctly? I've stuck a tag on it (fscache-fixes-for-ceph) to make that > > easier for you. > > > > I've also asked another RH engineer to try doing some basic testing on the > > CIFS stuff - which may validate the fscache_readpages_cancel patch. > > > > David > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] Cpufreq fixes related to cpu hotplug/sysfs-writes
Hi, This patchset solves the cpufreq synchronization problems related to CPU hotplug and writes to cpufreq sysfs files. The problem was reported and described by Stephen Boyd here: https://lkml.org/lkml/2013/8/27/643 https://lkml.org/lkml/2013/8/30/597 All the patches apply on Rafael's bleeding-edge branch on linux-pm git tree[1]. [1]. git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git bleeding-edge Srivatsa S. Bhat (5): cpufreq: Split __cpufreq_remove_dev() into 2 parts (kobj cleanup & the rest) cpufreq: Invoke __cpufreq_remove_dev_finish() after releasing cpu_hotplug.lock cpufreq: Synchronize the cpufreq store_*() routines with CPU hotplug cpufreq: Remove temporary fix for race between CPU hotplug and sysfs-writes cpufreq: Use signed type for 'ret' variable, to store negative error values drivers/cpufreq/cpufreq.c | 90 ++--- include/linux/cpufreq.h |1 - 2 files changed, 68 insertions(+), 23 deletions(-) Thanks, Srivatsa S. Bhat IBM Linux 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/
[GIT] kbuild updates for v3.12-rc1
Hi Linus, only these two commits are in the kbuild branch this time: - Using filechk for include/config/kernel.release - Cleanup in scripts/sortextable.c Thanks, Michal The following changes since commit ad81f0545ef01ea651886dddac4bef6cec930092: Linux 3.11-rc1 (2013-07-14 15:18:27 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild.git kbuild Michal Marek (1): kbuild: Do not overwrite include/config/kernel.release needlessly Ramkumar Ramachandra (1): scripts: remove unused function in sortextable.c Makefile |7 +-- scripts/sortextable.c |8 2 files changed, 5 insertions(+), 10 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
