[PATCH 2/6] CRIS: add dt-bindings symlink
Add a dt-bindings symlink to get DT include files, as on other
architectures. See c58299a ("kbuild: create an "include chroot" for DT
bindings") for the details.
Signed-off-by: Rabin Vincent
---
arch/cris/boot/dts/include/dt-bindings | 1 +
1 file changed, 1 insertion(+)
create mode 12 arch/cris/boot/dts/include/dt-bindings
diff --git a/arch/cris/boot/dts/include/dt-bindings
b/arch/cris/boot/dts/include/dt-bindings
new file mode 12
index 000..08c00e4
--- /dev/null
+++ b/arch/cris/boot/dts/include/dt-bindings
@@ -0,0 +1 @@
+../../../../../include/dt-bindings
\ No newline at end of file
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/8] atomics: add acquire/release/relaxed variants of some atomic operations
On Mon, Aug 03, 2015 at 06:26:58PM +0100, Peter Zijlstra wrote:
> On Mon, Aug 03, 2015 at 06:02:24PM +0100, Will Deacon wrote:
> > +/*
> > + * The idea here is to build acquire/release variants by adding explicit
> > + * barriers on top of the relaxed variant. In the case where the relaxed
> > + * variant is already fully ordered, no additional barriers are needed.
> > + */
> > +#define __atomic_op_acquire(ret_t, op, ...)
> > \
> > +({ \
> > + ret_t __ret = op##_relaxed(__VA_ARGS__);\
>
> Do you really need ret_t? Can't we use typeof() on the expression?
*gulp*! I was slightly worried about this from the GNU docs:
`The operand of typeof is evaluated for its side effects if and only if
it is an expression of variably modified type or the name of such a
type.'
but since none of our atomic functions return "variably modified types",
then there shouldn't be anything to worry about. It also means I can
slightly simplify the xchg/cmpxchg wrappers where we were previously
passing through the typeof(*ptr).
Incremental diff below (I'll post a v5 when the build testing comes back
clean).
Will
--->8
diff --git a/include/linux/atomic.h b/include/linux/atomic.h
index d2515c05e7c8..41ea776052be 100644
--- a/include/linux/atomic.h
+++ b/include/linux/atomic.h
@@ -35,26 +35,24 @@
* barriers on top of the relaxed variant. In the case where the relaxed
* variant is already fully ordered, no additional barriers are needed.
*/
-#define __atomic_op_acquire(ret_t, op, ...)\
+#define __atomic_op_acquire(op, args...) \
({ \
- ret_t __ret = op##_relaxed(__VA_ARGS__);\
+ typeof(op##_relaxed(args)) __ret = op##_relaxed(args); \
smp_mb__after_atomic(); \
__ret; \
})
-#define __atomic_op_release(ret_t, op, ...)\
+#define __atomic_op_release(op, args...) \
({ \
- ret_t __ret;\
smp_mb__before_atomic();\
- __ret = op##_relaxed(__VA_ARGS__); \
- __ret; \
+ op##_relaxed(args); \
})
-#define __atomic_op_fence(ret_t, op, ...) \
+#define __atomic_op_fence(op, args...) \
({ \
- ret_t __ret;\
+ typeof(op##_relaxed(args)) __ret; \
smp_mb__before_atomic();\
- __ret = op##_relaxed(__VA_ARGS__); \
+ __ret = op##_relaxed(args); \
smp_mb__after_atomic(); \
__ret; \
})
@@ -69,17 +67,17 @@
#ifndef atomic_add_return_acquire
#define atomic_add_return_acquire(...)
\
- __atomic_op_acquire(int, atomic_add_return, __VA_ARGS__)
+ __atomic_op_acquire(atomic_add_return, __VA_ARGS__)
#endif
#ifndef atomic_add_return_release
#define atomic_add_return_release(...)
\
- __atomic_op_release(int, atomic_add_return, __VA_ARGS__)
+ __atomic_op_release(atomic_add_return, __VA_ARGS__)
#endif
#ifndef atomic_add_return
#define atomic_add_return(...)
\
- __atomic_op_fence(int, atomic_add_return, __VA_ARGS__)
+ __atomic_op_fence(atomic_add_return, __VA_ARGS__)
#endif
#endif /* atomic_add_return_relaxed */
@@ -93,17 +91,17 @@
#ifndef atomic_sub_return_acquire
#define atomic_sub_return_acquire(...)
\
- __atomic_op_acquire(int, atomic_sub_return, __VA_ARGS__)
+ __atomic_op_acquire(atomic_sub_return, __VA_ARGS__)
#endif
#ifndef atomic_sub_return_release
#define atomic_sub_return_release(...)
\
- __atomic_op_release(int, atomic_sub_return, __VA_ARGS__)
+ __atomic_op_release(atomic_sub_return, __VA_ARGS__)
#endif
#ifndef atomic_sub_return
#define atomic_sub_return(...)
\
- __atomic_op_fence(int, atomic_sub_return, __VA_ARGS__)
+ __atomic_op_fence(atomic_sub_return, __VA_A
[PATCH 5/6] CRIS v32: remove I2C bitbanging driver
Now that we have a gpiolib GPIO driver, the generic i2c-gpio driver provides this functionality. Signed-off-by: Rabin Vincent --- arch/cris/arch-v32/drivers/Kconfig | 18 - arch/cris/arch-v32/drivers/Makefile | 1 - arch/cris/arch-v32/drivers/i2c.c| 751 arch/cris/arch-v32/drivers/i2c.h| 16 - 4 files changed, 786 deletions(-) delete mode 100644 arch/cris/arch-v32/drivers/i2c.c delete mode 100644 arch/cris/arch-v32/drivers/i2c.h diff --git a/arch/cris/arch-v32/drivers/Kconfig b/arch/cris/arch-v32/drivers/Kconfig index 4fc16b4..bebb718 100644 --- a/arch/cris/arch-v32/drivers/Kconfig +++ b/arch/cris/arch-v32/drivers/Kconfig @@ -149,24 +149,6 @@ config ETRAX_NANDBOOT Say Y if your boot code, kernel and root file system is in NAND flash. Say N if they are in NOR flash. -config ETRAX_I2C - bool "I2C driver" - depends on ETRAX_ARCH_V32 - help - This option enables the I2C driver used by e.g. the RTC driver. - -config ETRAX_V32_I2C_DATA_PORT - string "I2C data pin" - depends on ETRAX_I2C - help - The pin to use for I2C data. - -config ETRAX_V32_I2C_CLK_PORT - string "I2C clock pin" - depends on ETRAX_I2C - help - The pin to use for I2C clock. - config ETRAX_GPIO bool "GPIO support" depends on ETRAX_ARCH_V32 diff --git a/arch/cris/arch-v32/drivers/Makefile b/arch/cris/arch-v32/drivers/Makefile index 15fbfef..b5a75fd 100644 --- a/arch/cris/arch-v32/drivers/Makefile +++ b/arch/cris/arch-v32/drivers/Makefile @@ -7,6 +7,5 @@ obj-$(CONFIG_ETRAX_AXISFLASHMAP)+= axisflashmap.o obj-$(CONFIG_ETRAXFS) += mach-fs/ obj-$(CONFIG_CRIS_MACH_ARTPEC3) += mach-a3/ obj-$(CONFIG_ETRAX_IOP_FW_LOAD) += iop_fw_load.o -obj-$(CONFIG_ETRAX_I2C)+= i2c.o obj-$(CONFIG_ETRAX_SYNCHRONOUS_SERIAL) += sync_serial.o obj-$(CONFIG_PCI) += pci/ diff --git a/arch/cris/arch-v32/drivers/i2c.c b/arch/cris/arch-v32/drivers/i2c.c deleted file mode 100644 index 3b2c82c..000 --- a/arch/cris/arch-v32/drivers/i2c.c +++ /dev/null @@ -1,751 +0,0 @@ -/*!*** -*! -*! FILE NAME : i2c.c -*! -*! DESCRIPTION: implements an interface for IIC/I2C, both directly from other -*! kernel modules (i2c_writereg/readreg) and from userspace using -*! ioctl()'s -*! -*! Nov 30 1998 Torbjorn Eliasson Initial version. -*! Bjorn WesenElinux kernel version. -*! Jan 14 2000 Johan AdolfssonFixed PB shadow register stuff - -*! don't use PB_I2C if DS1302 uses same bits, -*! use PB. -*| June 23 2003 Pieter Grimmerink Added 'i2c_sendnack'. i2c_readreg now -*| generates nack on last received byte, -*| instead of ack. -*| i2c_getack changed data level while clock -*| was high, causing DS75 to see a stop condition -*! -*! --- -*! -*! (C) Copyright 1999-2007 Axis Communications AB, LUND, SWEDEN -*! -*!***/ - -/** INCLUDE FILES SECTION ***/ - -#include -#include -#include -#include -#include -#include -#include -#include - -#include - -#include -#include - -#include "i2c.h" - -/** I2C DEFINITION SECTION */ - -#define D(x) - -#define I2C_MAJOR 123 /* LOCAL/EXPERIMENTAL */ -static DEFINE_MUTEX(i2c_mutex); -static const char i2c_name[] = "i2c"; - -#define CLOCK_LOW_TIME8 -#define CLOCK_HIGH_TIME 8 -#define START_CONDITION_HOLD_TIME 8 -#define STOP_CONDITION_HOLD_TIME 8 -#define ENABLE_OUTPUT 0x01 -#define ENABLE_INPUT 0x00 -#define I2C_CLOCK_HIGH 1 -#define I2C_CLOCK_LOW 0 -#define I2C_DATA_HIGH 1 -#define I2C_DATA_LOW 0 - -#define i2c_enable() -#define i2c_disable() - -/* enable or disable output-enable, to select output or input on the i2c bus */ - -#define i2c_dir_out() crisv32_io_set_dir(&cris_i2c_data, crisv32_io_dir_out) -#define i2c_dir_in() crisv32_io_set_dir(&cris_i2c_data, crisv32_io_dir_in) - -/* control the i2c clock and data signals */ - -#define i2c_clk(x) crisv32_io_set(&cris_i2c_clk, x) -#define i2c_data(x) crisv32_io_set(&cris_i2c_data, x) - -/* read a bit from the i2c interface */ - -#define i2c_getbit() crisv32_io_rd(&cris_i2c_data) - -#define i2c_delay(usecs) udelay(usecs) - -static DEFINE_SPINLOCK(i2c_lock); /* Protect directions etc */ - -/** VARIABLE SECTION / - -static struct crisv32_iopin cris_i2c_clk; -static struct crisv32_iopin cris_i2c_data; - -/** FUNCTION DEFI
Re: [PATCH v4 1/7] locking/pvqspinlock: Unconditional PV kick with _Q_SLOW_VAL
On Sun, 2015-08-02 at 00:29 +0200, Peter Zijlstra wrote: > That's just gibberish, even in the same cacheline stuff can get > reordered. true dat > > So either we insert > > +* memory barrier here and in the corresponding pv_wait_head() > > +* function or we do an unconditional kick which is what is done here. > > why, why why ? You've added words, but you've not actually described > what the problem is you're trying to fix. > > AFAICT the only thing we really care about here is that the load in > question happens _after_ we observe SLOW, and that is still true. > > The order against the unlock is irrelevant. > > So we set ->state before we hash and before we set SLOW. Given that > we've seen SLOW, we must therefore also see ->state. > > If ->state == halted, this means the CPU in question is blocked and the > pv_node will not get re-used -- if it does get re-used, it wasn't > blocked and we don't care either. Right, if it does get re-used, we were burning SPIN_THRESHOLD and racing only wastes a few spins, afaict. In fact this is explicitly stated: /* * The unlocker should have freed the lock before kicking the * CPU. So if the lock is still not free, it is a spurious * wakeup and so the vCPU should wait again after spinning for * a while. */ The thing I like about this patch is that it simplifies the pv_kick/pv_wait flow, not having to depend on minutia like ->state checking. But the condition about spurious wakeups is already there, so really nothing changes. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/9] x86/intel_rdt: Cache Allocation documentation and cgroup usage guide
Hello Marcelo/Martin, Like I mentioned let me modify the documentation to better help understand the usage. Things like updating each package bitmask is already in the patches. Lets discuss offline and come up a well defined proposal for change if any and then update that in next series. We seem to be just looping over same items. Thanks, Vikas On Mon, 3 Aug 2015, Marcelo Tosatti wrote: On Sun, Aug 02, 2015 at 05:48:07PM +0200, Martin Kletzander wrote: On Thu, Jul 30, 2015 at 05:08:13PM -0300, Marcelo Tosatti wrote: On Thu, Jul 30, 2015 at 10:47:23AM -0700, Vikas Shivappa wrote: Marcello, On Wed, 29 Jul 2015, Marcelo Tosatti wrote: How about this: desiredclos (closid p1 p2 p3 p4) 1 1 0 0 0 2 0 0 0 1 3 0 1 1 0 #1 Currently in the rdt cgroup , the root cgroup always has all the bits set and cant be changed (because the cgroup hierarchy would by default make this to have all bits as all the children need to have a subset of the root's bitmask). So if the user creates a cgroup and not put any task in it , the tasks in the root cgroup could be still using that part of the cache. Thats the reason i say we can have really 'exclusive' masks. Or in other words - there is always a desired clos (0) which has all parts set which acts like a default pool. Also the parts can overlap. Please apply this for all the below comments which will change the way they work. p means part. I am assuming p = (a contiguous cache capacity bit mask) Yes. closid 1 is a exclusive cgroup. closid 2 is a "cache hog" class. closid 3 is "default closid". Desiredclos is what user has specified. Transition 1: desiredclos --> effectiveclos Clean all bits of unused closid's (that must be updated whenever a closid1 cgroup goes from empty->nonempty and vice-versa). effectiveclos (closid p1 p2 p3 p4) 1 0 0 0 0 2 0 0 0 1 3 0 1 1 0 Transition 2: effectiveclos --> expandedclos expandedclos (closid p1 p2 p3 p4) 1 0 0 0 0 2 0 0 0 1 3 1 1 1 0 Then you have different inplacecos for each CPU (see pseudo-code below): On the following events. - task migration to new pCPU: - task creation: id = smp_processor_id(); for (part = desiredclos.p1; ...; part++) /* if my cosid is set and any other cosid is clear, for the part, synchronize desiredclos --> inplacecos */ if (part[mycosid] == 1 && part[any_othercosid] == 0) wrmsr(part, desiredclos); Currently the root cgroup would have all the bits set which will act like a default cgroup where all the otherwise unused parts (assuming they are a set of contiguous cache capacity bits) will be used. Otherwise the question is in the expandedclos - who decides to expand the closx parts to include some of the unused parts.. - that could just be a default root always ? Right, so the problem is for certain closid's you might never want to expand (because doing so would cause data to be cached in a cache way which might have high eviction rate in the future). See the example from Will. But for the default cache (that is "unclassified applications" i suppose it is beneficial to expand in most cases, that is, use maximum amount of cache irrespective of eviction rate, which is the behaviour that exists now without CAT). So perhaps a new flag "expand=y/n" can be added to the cgroup directories... What do you say? Userspace representation of CAT --- Usage model: 1) measure application performance without L3 cache reservation. 2) measure application perf with L3 cache reservation and X number of cache ways until desired performance is attained. Requirements: 1) Persistency of CLOS configuration across hardware. On migration of operating system or application between different hardware systems we'd like the following to be maintained: - exclusive number of bytes (*) reserved to a certain CLOSid. - shared number of bytes (*) reserved between a certain group of CLOSid's. For both code and data, rounded down or up in cache way size. 2) Reasoning: Different CBM masks in different hardware platforms might be necessary to specify the same CLOS configuration, in terms of exclusive number of bytes and shared number of bytes. (cache-way rounded number of bytes). For example, due to L3 allocation by other hardware entities in certain parts of the cache it might be necessary to relocate CBM mask to achieve the same CLOS configuration. 3) Proposed format: Few questions from a random listener, I apologise if some of them are in a wrong place due to me missing some information from past threads. I'm not sure whether the following proposal to the format is the internal structure or
Re: [PATCH 1/2] ARM: dts: keystone: fix the clock node for mdio
On 08/03/2015 02:11 PM, Murali Karicheri wrote: Currently the MDIO clock is pointing to clkpa instead of clkcpgmac. MDIO is part of the ethss and the clock should be clkcpgmac. Signed-off-by: Murali Karicheri --- arch/arm/boot/dts/keystone.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi index e7a6f6d..6245a17 100644 --- a/arch/arm/boot/dts/keystone.dtsi +++ b/arch/arm/boot/dts/keystone.dtsi @@ -273,7 +273,7 @@ #size-cells = <0>; reg = <0x02090300 0x100>; status = "disabled"; - clocks = <&clkpa>; + clocks = <&clkcpgmac>; clock-names = "fck"; bus_freq= <250>; }; Santosh, This is a big fix and needs to go in v4.2-rc. So please review and apply asap. v4.2 is the first release that has netcp driver fully functional and I want to fix as many known bugs as possible. Thanks. -- Murali Karicheri Linux Kernel, Keystone -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] MIPS: ath79: Add the reset controller to the AR9132 dtsi
On Mon, Aug 03, 2015 at 07:23:53PM +0200, Alban Bedel wrote: Acked-by: Ralf Baechle Philipp, Feel free to take this through the reset tree. Or I can carry this in the MIPS tree which is probably better for testing. Just lemme know. Ralf -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Nokia N900 - audio TPA6130A2 problems
Hi
On 08/01/2015 01:18 PM, Pali Rohár wrote:
> On Saturday 25 July 2015 15:17:13 Lars-Peter Clausen wrote:
>> On 07/25/2015 12:28 PM, Pali Rohár wrote:
>>> Hello,
>>>
>>> sometimes after rebooting Nokia N900 initializing alsa audio fails.
>>> Here output from dmesg log when it happen:
>>>
>>> [6.925140] tpa6130a2 2-0060: Write failed
>>> [6.929534] tpa6130a2 2-0060: Failed to initialize chip
>>> [6.935272] tpa6130a2: probe of 2-0060 failed with error -121
>>> [7.624237] rx51-audio n900-audio: Failed to add TPA6130A2
>>> controls [7.635101] rx51-audio n900-audio: ASoC: failed to
>>> init TLV320AIC34: -19 [7.645874] rx51-audio n900-audio: ASoC:
>>> failed to instantiate card -19 [7.665740] rx51-audio
>>> n900-audio: snd_soc_register_card failed (-19) [8.063049] ALSA
>>> device list:
>>> [8.070343] No soundcards found.
>>>
>>> Any idea what to do?
>>
>> Looks like the chip is not responding. Try to add a small delay after
>> powerup to give the device to be fully ready, something like the
>> following:
>>
>> --- a/sound/soc/codecs/tpa6130a2.c
>> +++ b/sound/soc/codecs/tpa6130a2.c
>> @@ -152,6 +152,8 @@ static int tpa6130a2_power(u8 power)
>> if (data->power_gpio >= 0)
>> gpio_set_value(data->power_gpio, 1);
>>
>> +msleep(5);
>> +
>> data->power_state = 1;
>> ret = tpa6130a2_initialize();
>> if (ret < 0) {
>
>
> Hello, your patch did not helped. Problem is still there...
>
For me v4.2-rc5 works, i.e. TPA6130A2 can still play loudly to
headphones. Don't know were there any i2c etc regression before it or
how easy it would be to reproduce.
Logs below made me thinking can it be a HW issue? Although if it is an
HW issue it shouldn't work sometimes I guess. Do you have any earlier
well known configuration you could try is it an SW regression or
something else?
> [5.962585] tpa6130a2 2-0060: Write failed
> [5.962707] tpa6130a2 2-0060: Failed to initialize chip
> [5.962860] tpa6130a2: probe of 2-0060 failed with error -121
-121 == EREMOTEIO which is returned from i2c-omap.c when there is no ACK
from the chip.
> [ 28.102233] omap_i2c 48072000.i2c: controller timed out
> [ 29.463653] lp5523x 2-0032: lp5523 Programmable led chip found
> [ 30.734191] omap_i2c 48072000.i2c: controller timed out waiting for start
> condition to finish
> [ 32.142333] i2c i2c-2: SCL is stuck low, exit recovery
If SCL is really stuck it also explains why chip doesn't acknowledge.
--
Jarkko
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] x86/ldt: allow to disable modify_ldt at runtime
For distros who prefer not to take the risk of completely disabling the
modify_ldt syscall using CONFIG_MODIFY_LDT_SYSCALL, this patch adds a
sysctl to enable, temporarily disable, or permanently disable it at
runtime, and proposes to temporarily disable it by default. This can be
a safe alternative. A message is logged if an attempt was stopped so that
it's easy to spot if/when it is needed.
Cc: Andy Lutomirski
Cc: Kees Cook
Signed-off-by: Willy Tarreau
---
Documentation/sysctl/kernel.txt | 16
arch/x86/Kconfig| 17 +
arch/x86/kernel/ldt.c | 15 +++
kernel/sysctl.c | 14 ++
4 files changed, 62 insertions(+)
diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 6fccb69..55648b9 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -41,6 +41,7 @@ show up in /proc/sys/kernel:
- kptr_restrict
- kstack_depth_to_print [ X86 only ]
- l2cr[ PPC only ]
+- modify_ldt [ X86 only ]
- modprobe==> Documentation/debugging-modules.txt
- modules_disabled
- msg_next_id[ sysv ipc ]
@@ -391,6 +392,21 @@ This flag controls the L2 cache of G3 processor boards. If
==
+modify_ldt: (X86 only)
+
+Enables (1), disables (0) or permanently disables (-1) the modify_ldt syscall.
+Modifying the LDT (Local Descriptor Table) may be needed to run a 16-bit or
+segmented code such as Dosemu or Wine. This is done via a system call which is
+not needed to run portable applications, and which can sometimes be abused to
+exploit some weaknesses of the architecture, opening new vulnerabilities.
+
+This sysctl allows one to increase the system's security by disabling the
+system call, or to restore compatibility with specific applications when it
+was already disabled. When permanently disabled, it is not possible to change
+the value anymore until the next system reboot.
+
+==
+
modules_disabled:
A toggle value indicating if modules are allowed to be loaded
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index beabf30..88d10a0 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2069,6 +2069,23 @@ config MODIFY_LDT_SYSCALL
surface. Disabling it removes the modify_ldt(2) system call.
Saying 'N' here may make sense for embedded or server kernels.
+ If really unsure, say 'Y', you'll be able to disable it at runtime.
+
+config DEFAULT_MODIFY_LDT_SYSCALL
+ bool "Allow userspace to modify the LDT by default"
+ depends on MODIFY_LDT_SYSCALL
+ default y
+ ---help---
+ Modifying the LDT (Local Descriptor Table) may be needed to run a
+ 16-bit or segmented code such as Dosemu or Wine. This is done via
+ a system call which is not needed to run portable applications,
+ and which can sometimes be abused to exploit some weaknesses of
+ the architecture, opening new vulnerabilities.
+
+ For this reason this option allows one to enable or disable the
+ feature at runtime. It is recommended to say 'N' here to leave
+ the system protected, and to enable it at runtime only if needed
+ by setting the sys.kernel.modify_ldt sysctl.
source "kernel/livepatch/Kconfig"
diff --git a/arch/x86/kernel/ldt.c b/arch/x86/kernel/ldt.c
index 2bcc052..420fc8f 100644
--- a/arch/x86/kernel/ldt.c
+++ b/arch/x86/kernel/ldt.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -21,6 +22,11 @@
#include
#include
+#ifdef CONFIG_MODIFY_LDT_SYSCALL
+int sysctl_modify_ldt __read_mostly =
+ IS_ENABLED(CONFIG_DEFAULT_MODIFY_LDT_SYSCALL);
+#endif
+
/* context.lock is held for us, so we don't need any locking. */
static void flush_ldt(void *current_mm)
{
@@ -276,6 +282,15 @@ asmlinkage int sys_modify_ldt(int func, void __user *ptr,
{
int ret = -ENOSYS;
+ if (sysctl_modify_ldt <= 0) {
+ printk_ratelimited(KERN_INFO
+ "Denied a call to modify_ldt() from %s[%d] (uid: %d)."
+ " Adjust sysctl if this was not an exploit attempt.\n",
+ current->comm, task_pid_nr(current),
+ from_kuid_munged(current_user_ns(), current_uid()));
+ return ret;
+ }
+
switch (func) {
case 0:
ret = read_ldt(ptr, bytecount);
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 86c95a8..ec1170d 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -111,6 +111,9 @@ extern int sysctl_nr_open_min, sysctl_nr_open_max;
#ifndef CONFIG_MMU
extern int sysctl_nr_trim_pages;
#endif
+#ifdef CONFIG_MODIFY_LDT_SYSCALL
+extern int sysctl_modify_ldt;
+#endif
/* Constants used for minimum and max
[PATCH 1/2] sysctl: add a new generic strategy to make permanent changes on negative values
The new function is proc_dointvec_minmax_negperm(), it refuses to change
the value if the current one is already negative. This will be used to
lock down some settings such as sensitive system calls.
Signed-off-by: Willy Tarreau
---
kernel/sysctl.c | 36
1 file changed, 36 insertions(+)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 19b62b5..86c95a8 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -185,6 +185,9 @@ static int proc_dointvec_minmax_sysadmin(struct ctl_table
*table, int write,
void __user *buffer, size_t *lenp, loff_t
*ppos);
#endif
+static int proc_dointvec_minmax_negperm(struct ctl_table *table, int write,
+ void __user *buffer, size_t *lenp, loff_t *ppos);
+
static int proc_dointvec_minmax_coredump(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp, loff_t *ppos);
#ifdef CONFIG_COREDUMP
@@ -2249,6 +2252,33 @@ static void validate_coredump_safety(void)
#endif
}
+/* Like minmax except that it refuses any change if the value was already
+ * negative. It silently ignores overrides with the same negative value.
+ */
+static int do_proc_dointvec_negperm_conv(bool *negp, unsigned long *lvalp,
+int *valp,
+int write, void *data)
+{
+ if (write && *valp < 0 && (!*negp || *valp != (int)*lvalp))
+ return -EINVAL;
+
+ return do_proc_dointvec_minmax_conv(negp, lvalp, valp, write, data);
+}
+
+/* Like proc_dointvec_minmax() except that it refuses any change once
+ * the destination is negative. Used to permanently disable some settings.
+ */
+static int proc_dointvec_minmax_negperm(struct ctl_table *table, int write,
+ void __user *buffer, size_t *lenp, loff_t *ppos)
+{
+ struct do_proc_dointvec_minmax_conv_param param = {
+ .min = (int *) table->extra1,
+ .max = (int *) table->extra2,
+ };
+ return do_proc_dointvec(table, write, buffer, lenp, ppos,
+ do_proc_dointvec_negperm_conv, ¶m);
+}
+
static int proc_dointvec_minmax_coredump(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp, loff_t *ppos)
{
@@ -2751,6 +2781,12 @@ int proc_dointvec_minmax(struct ctl_table *table, int
write,
return -ENOSYS;
}
+static int proc_dointvec_minmax_negperm(struct ctl_table *table, int write,
+ void __user *buffer, size_t *lenp, loff_t *ppos)
+{
+ return -ENOSYS;
+}
+
int proc_dointvec_jiffies(struct ctl_table *table, int write,
void __user *buffer, size_t *lenp, loff_t *ppos)
{
--
1.7.12.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/6] CRIS v32: increase NR_IRQS
Increase NR_IQRS so we can fit in GPIO interrupts.
Signed-off-by: Rabin Vincent
---
arch/cris/arch-v32/kernel/irq.c | 4 ++--
arch/cris/include/arch-v32/arch/irq.h | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/cris/arch-v32/kernel/irq.c b/arch/cris/arch-v32/kernel/irq.c
index 6a881e0..b566a03 100644
--- a/arch/cris/arch-v32/kernel/irq.c
+++ b/arch/cris/arch-v32/kernel/irq.c
@@ -464,14 +464,14 @@ init_IRQ(void)
etrax_irv->v[i] = weird_irq;
np = of_find_compatible_node(NULL, NULL, "axis,crisv32-intc");
- domain = irq_domain_add_legacy(np, NR_IRQS - FIRST_IRQ,
+ domain = irq_domain_add_legacy(np, NBR_INTR_VECT - FIRST_IRQ,
FIRST_IRQ, FIRST_IRQ,
&crisv32_irq_ops, NULL);
BUG_ON(!domain);
irq_set_default_host(domain);
of_node_put(np);
- for (i = FIRST_IRQ, j = 0; j < NR_IRQS; i++, j++) {
+ for (i = FIRST_IRQ, j = 0; j < NBR_INTR_VECT; i++, j++) {
set_exception_vector(i, interrupt[j]);
}
diff --git a/arch/cris/include/arch-v32/arch/irq.h
b/arch/cris/include/arch-v32/arch/irq.h
index 0c1b4d3..8270a1b 100644
--- a/arch/cris/include/arch-v32/arch/irq.h
+++ b/arch/cris/include/arch-v32/arch/irq.h
@@ -4,7 +4,7 @@
#include
/* Number of non-cpu interrupts. */
-#define NR_IRQS NBR_INTR_VECT /* Exceptions + IRQs */
+#define NR_IRQS (NBR_INTR_VECT + 256) /* Exceptions + IRQs */
#define FIRST_IRQ 0x31 /* Exception number for first IRQ */
#define NR_REAL_IRQS (NBR_INTR_VECT - FIRST_IRQ) /* IRQs */
#if NR_REAL_IRQS > 32
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/6] CRIS v32: add ARTPEC-3 and P1343 device trees
Add a device tree for the Axis P1343 with the ARTPEC-3 SoC and on-board
LEDs and RTC.
Signed-off-by: Rabin Vincent
---
arch/cris/boot/dts/artpec3.dtsi | 46 +
arch/cris/boot/dts/p1343.dts| 76 +
2 files changed, 122 insertions(+)
create mode 100644 arch/cris/boot/dts/artpec3.dtsi
create mode 100644 arch/cris/boot/dts/p1343.dts
diff --git a/arch/cris/boot/dts/artpec3.dtsi b/arch/cris/boot/dts/artpec3.dtsi
new file mode 100644
index 000..be15be6
--- /dev/null
+++ b/arch/cris/boot/dts/artpec3.dtsi
@@ -0,0 +1,46 @@
+/ {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ interrupt-parent = <&intc>;
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu@0 {
+ device_type = "cpu";
+ model = "axis,crisv32";
+ reg = <0>;
+ };
+ };
+
+ soc {
+ compatible = "simple-bus";
+ model = "artpec3";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges;
+
+ intc: interrupt-controller {
+ compatible = "axis,crisv32-intc";
+ reg = <0xb002a000 0x1000>;
+ interrupt-controller;
+ #interrupt-cells = <1>;
+ };
+
+ gio: gpio@b002 {
+ compatible = "axis,artpec3-gio";
+ reg = <0xb002 0x1000>;
+ interrupts = <61>;
+ gpio-controller;
+ #gpio-cells = <3>;
+ };
+
+ serial@b003e000 {
+ compatible = "axis,etraxfs-uart";
+ reg = <0xb003e000 0x1000>;
+ interrupts = <64>;
+ status = "disabled";
+ };
+ };
+};
diff --git a/arch/cris/boot/dts/p1343.dts b/arch/cris/boot/dts/p1343.dts
new file mode 100644
index 000..fab7bdb
--- /dev/null
+++ b/arch/cris/boot/dts/p1343.dts
@@ -0,0 +1,76 @@
+/dts-v1/;
+
+#include
+#include
+
+/include/ "artpec3.dtsi"
+
+/ {
+ model = "Axis P1343 Network Camera";
+ compatible = "axis,p1343";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ soc {
+ uart0: serial@b003e000 {
+ status = "okay";
+ };
+ };
+
+ i2c {
+ compatible = "i2c-gpio";
+ gpios = <&gio 3 0 0xa>, <&gio 2 0 0xa>;
+ i2c-gpio,delay-us = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ rtc@51 {
+ compatible = "nxp,pcf8563";
+ reg = <0x51>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ status_green {
+ label = "status:green";
+ gpios = <&gio 0 GPIO_ACTIVE_LOW 0xc>;
+ linux,default-trigger = "heartbeat";
+ };
+
+ status_red {
+ label = "status:red";
+ gpios = <&gio 1 GPIO_ACTIVE_LOW 0xc>;
+ };
+
+ network_green {
+ label = "network:green";
+ gpios = <&gio 2 GPIO_ACTIVE_LOW 0xc>;
+ };
+
+ network_red {
+ label = "network:red";
+ gpios = <&gio 3 GPIO_ACTIVE_LOW 0xc>;
+ };
+
+ power_red {
+ label = "power:red";
+ gpios = <&gio 4 GPIO_ACTIVE_LOW 0xc>;
+ };
+ };
+
+ gpio_keys {
+ compatible = "gpio-keys";
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ activity-button@0 {
+ label = "Activity Button";
+ linux,code = ;
+ gpios = <&gio 13 GPIO_ACTIVE_LOW 0xd>;
+ };
+ };
+};
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] x86, acpi: Handle lapic/x2apic entries in MADT
Hi Marc, > You haven't ever tried compiling this, have you? I *thought* I tried, but obviously I did it wrong. This time I made sure it compiles. Thanks for poiting this out. Sending v2 of the patch with fixed arm64 compilation. Cheers, Lukasz -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: Handle lapic/x2apic entries in MADT
v2: Fixed ARM64 syntax error
>From the ACPI spec:
"Logical processors with APIC ID values less than 0xFF
(whether in XAPIC or X2APIC mode) must use the Processor LAPIC
structure [...]. Logical processors with APIC ID values 0xFF and
greater must use the Processor Local x2APIC structure."
Because of above, BIOS is first enumerating cores with HT with
LAPIC values (<0xFF) and then rest with X2APIC values (>=0xFF).
With current kernel code, where enumeration is in order:
BSP, X2APIC, LAPIC
enumeration on machine with more than 255 CPUs (each core with 4 HT)
first X2APIC IDs get low logical CPU IDs (1..x) and then LAPIC IDs
get higher logical CPU IDs (50..y), as in example below:
Core LCpu ApicId LCpu ApicId LCpu ApicId LCpu ApicId
00 970001 145 0002193 0003
1 50 0004 980005 146 0006194 0007
2 51 0010 990011 147 0012195 0013
3 52 00141000015 148 0016196 0017
4 53 00181010019 149 001a197 001b
5 54 001c102001d 150 001e198 001f
...
62 95 00f814300f9 191 00fa239 00fb
63 37 00ff 9600fc 144 00fd192 00fe
64 1 0100 130101 250102 38 0103
65 2 0104 140105 260106 39 0107
...
(Core - physical core, LCpu - logical CPU, ApicId - ID assigned
by BIOS).
This is wrong for the following reasons:
() it's hard to predict how cores and threads will be enumerated
() when it's hard to predict, s/w threads cannot be properly affinitized
causing significant performance impact due to e.g. inproper cache
sharing
() enumeration is inconsistent with how threads are enumerated on
other Intel Xeon processors
To fix this, each LAPIC/X2APIC entry from MADT table needs to be
handled at the same time when processing it, thus adding
acpi_subtable_proc structure which stores
() ACPI table id
() handler that processes table
() counter how many items has been processed
and passing it to acpi_table_parse_entries().
Also, order in which MADT LAPIC/X2APIC handlers are passed is
reversed to achieve correct CPU enumeration.
In scenario when someone boots kernel with options 'maxcpus=72 nox2apic',
in result less cores may be booted, since some of the CPUs the kernel
will try to use will have APIC ID >= 0xFF. In such case, one
should not pass 'nox2apic'.
Disclimer: code parsing MADT LAPIC/X2APIC has not been touched since 2009,
when X2APIC support was initially added. I do not know why MADT parsing
code was added in the reversed order in the first place.
I guess it didn't matter at that time since nobody cared about cores
with APIC IDs >= 0xFF, right?
This patch is based on work of "Yinghai Lu "
previously published at https://lkml.org/lkml/2013/1/21/563,
thus putting Yinghai Lu as 'Signed-off-by', as well.
Signed-off-by: Yinghai Lu
Signed-off-by: Lukasz Anaczkowski
---
arch/x86/kernel/acpi/boot.c | 29 +-
drivers/acpi/numa.c | 28 -
drivers/acpi/tables.c | 75 -
drivers/irqchip/irq-gic.c | 15 ++---
include/linux/acpi.h| 13 ++--
5 files changed, 111 insertions(+), 49 deletions(-)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index e49ee24..fb4a9d6 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -981,6 +981,7 @@ static int __init acpi_parse_madt_lapic_entries(void)
{
int count;
int x2count = 0;
+ struct acpi_subtable_proc madt_proc[2];
if (!cpu_has_apic)
return -ENODEV;
@@ -1004,10 +1005,16 @@ static int __init acpi_parse_madt_lapic_entries(void)
acpi_parse_sapic, MAX_LOCAL_APIC);
if (!count) {
- x2count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_X2APIC,
- acpi_parse_x2apic, MAX_LOCAL_APIC);
- count = acpi_table_parse_madt(ACPI_MADT_TYPE_LOCAL_APIC,
- acpi_parse_lapic, MAX_LOCAL_APIC);
+ memset(madt_proc, 0, sizeof(madt_proc));
+ madt_proc[0].id = ACPI_MADT_TYPE_LOCAL_APIC;
+ madt_proc[0].handler = acpi_parse_lapic;
+ madt_proc[1].id = ACPI_MADT_TYPE_LOCAL_X2APIC;
+ madt_proc[1].handler = acpi_parse_x2apic;
+ acpi_table_parse_entries_array(ACPI_SIG_MADT,
+ sizeof(struct acpi_table_madt),
+ madt_proc, ARRAY_SIZE(madt_proc), MAX_LOCAL_APIC);
+ count = madt_proc[0].count;
+ x2count = madt_proc[1].count;
}
if (!count && !x2count) {
printk(KERN_ERR PREFIX "No LAPIC entries present\n");
@@ -1019,10 +1026,16 @@ static int __init acpi_parse_madt_lapic_entries(void)
return count;
}
-
Re: [PATCH 3.10 00/89] 3.10.85-stable review
On 07/31/2015 01:40 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.10.85 release. > There are 89 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 Sun Aug 2 19:40:13 UTC 2015. > 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.x/stable-review/patch-3.10.85-rc1.gz > and the diffstat can be found below. > Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 000/125] 3.14.49-stable review
On 07/31/2015 01:40 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 3.14.49 release. > There are 125 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 Sun Aug 2 19:40:05 UTC 2015. > 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.x/stable-review/patch-3.14.49-rc1.gz > and the diffstat can be found below. > Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: dts: keystone: fix the clock node for mdio
On 8/3/15 11:22 AM, Murali Karicheri wrote: On 08/03/2015 02:11 PM, Murali Karicheri wrote: Currently the MDIO clock is pointing to clkpa instead of clkcpgmac. MDIO is part of the ethss and the clock should be clkcpgmac. Signed-off-by: Murali Karicheri --- arch/arm/boot/dts/keystone.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi index e7a6f6d..6245a17 100644 --- a/arch/arm/boot/dts/keystone.dtsi +++ b/arch/arm/boot/dts/keystone.dtsi @@ -273,7 +273,7 @@ #size-cells = <0>; reg= <0x02090300 0x100>; status = "disabled"; -clocks = <&clkpa>; +clocks = <&clkcpgmac>; clock-names = "fck"; bus_freq= <250>; }; Santosh, This is a big fix and needs to go in v4.2-rc. So please review and apply asap. v4.2 is the first release that has netcp driver fully functional and I want to fix as many known bugs as possible. Do you have more fixes ? If yes, please post them so that I can include them along with these two. I will try to send them up next week. Thanks !! Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4.1 000/267] 4.1.4-stable review
On 07/31/2015 01:37 PM, Greg Kroah-Hartman wrote: > This is the start of the stable review cycle for the 4.1.4 release. > There are 267 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 Sun Aug 2 19:39:27 UTC 2015. > 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/v4.x/stable-review/patch-4.1.4-rc1.gz > and the diffstat can be found below. > Compiled and booted on my test system. No dmesg regressions. thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 09/14] ring_buffer: Initialize completions statically in the benchmark
On Tue, 28 Jul 2015 16:39:26 +0200 Petr Mladek wrote: > It looks strange to initialize the completions repeatedly. > > This patch uses static initialization. It simplifies the code > and even helps to get rid of two memory barriers. There was a reason I did it this way and did not use static initializers. But I can't recall why I did that. :-/ I'll have to think about this some more. -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC][PATCH] ecryptfs: Allow only one instance per lower path
Tyler, Am 03.08.2015 um 07:27 schrieb Tyler Hicks: >> So ecryptfs definitely supports mounting the same lower path multiple times? >> What is the benefit of that behavior? > > No, it doesn't support that in a way that provides consistency among all > of the eCryptfs mounts. Okay, then I'd argument to give my patch a try although it is not the solution to the problem I've reported. :-) If you don't mind I'll resend with a proper changelog. > However, multiple mounts on the same lower path is not the cause of this > bug. The real issue is a stale dcache entry when the lower filesystem > has been modified without eCryptfs' knowing. I can trigger the same > warnings with only a single eCryptfs mount. Interesting, that renders the whole issue into a user triggerable kernel bug. :-( Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] x86: allow to enable/disable modify_ldt at run time
This is the second version. It adds a strategy for the sysctls so that we can reject any change to a value that was already negative. This way it's possible to disable modify_ldt temporarily or permanently (eg: lock down a server) as suggested by Kees. Willy Tarreau (2): sysctl: add a new generic strategy to make permanent changes on negative values x86/ldt: allow to disable modify_ldt at runtime Documentation/sysctl/kernel.txt | 16 + arch/x86/Kconfig| 17 ++ arch/x86/kernel/ldt.c | 15 + kernel/sysctl.c | 50 + 4 files changed, 98 insertions(+) -- 1.7.12.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 10/14] ring_buffer: Fix more races when terminating the producer in the benchmark
On Tue, 28 Jul 2015 16:39:27 +0200
Petr Mladek wrote:
> @@ -384,7 +389,7 @@ static int ring_buffer_consumer_thread(void *arg)
>
> static int ring_buffer_producer_thread(void *arg)
> {
> - while (!kthread_should_stop() && !kill_test) {
> + while (!break_test()) {
> ring_buffer_reset(buffer);
>
> if (consumer) {
> @@ -393,11 +398,15 @@ static int ring_buffer_producer_thread(void *arg)
> }
>
> ring_buffer_producer();
> - if (kill_test)
> + if (break_test())
> goto out_kill;
>
> trace_printk("Sleeping for 10 secs\n");
> set_current_state(TASK_INTERRUPTIBLE);
> + if (break_test()) {
> + __set_current_state(TASK_RUNNING);
Move the setting of the current state to after the out_kill label.
-- Steve
> + goto out_kill;
> + }
> schedule_timeout(HZ * SLEEP_TIME);
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] sysctl: add a new generic strategy to make permanent changes on negative values
On Mon, Aug 3, 2015 at 11:23 AM, Willy Tarreau wrote:
> The new function is proc_dointvec_minmax_negperm(), it refuses to change
> the value if the current one is already negative. This will be used to
> lock down some settings such as sensitive system calls.
>
> Signed-off-by: Willy Tarreau
> ---
> kernel/sysctl.c | 36
> 1 file changed, 36 insertions(+)
>
> diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> index 19b62b5..86c95a8 100644
> --- a/kernel/sysctl.c
> +++ b/kernel/sysctl.c
> @@ -185,6 +185,9 @@ static int proc_dointvec_minmax_sysadmin(struct ctl_table
> *table, int write,
> void __user *buffer, size_t *lenp, loff_t
> *ppos);
> #endif
>
> +static int proc_dointvec_minmax_negperm(struct ctl_table *table, int write,
> + void __user *buffer, size_t *lenp, loff_t *ppos);
> +
> static int proc_dointvec_minmax_coredump(struct ctl_table *table, int write,
> void __user *buffer, size_t *lenp, loff_t *ppos);
> #ifdef CONFIG_COREDUMP
> @@ -2249,6 +2252,33 @@ static void validate_coredump_safety(void)
> #endif
> }
>
> +/* Like minmax except that it refuses any change if the value was already
> + * negative. It silently ignores overrides with the same negative value.
> + */
> +static int do_proc_dointvec_negperm_conv(bool *negp, unsigned long *lvalp,
> +int *valp,
> +int write, void *data)
> +{
> + if (write && *valp < 0 && (!*negp || *valp != (int)*lvalp))
I could easily have failed to follow the bizarre negative sign
convention, but shouldn't that be "*valp != -(int)*lvalp" or similar?
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 -next] staging: most: fix aim-sound build errors
From: Randy Dunlap Fix build errors: driver uses snd_pcm*() interfaces, so select SND_PCM. drivers/built-in.o: In function `audio_rx_completion': sound.c:(.text+0x3cd376): undefined reference to `snd_pcm_period_elapsed' drivers/built-in.o: In function `pcm_prepare': sound.c:(.text+0x3cd3b0): undefined reference to `snd_pcm_format_physical_width' sound.c:(.text+0x3cd3ce): undefined reference to `snd_pcm_format_big_endian' sound.c:(.text+0x3cd42c): undefined reference to `snd_pcm_format_big_endian' drivers/built-in.o: In function `pcm_hw_free': sound.c:(.text+0x3cd50a): undefined reference to `snd_pcm_lib_free_vmalloc_buffer' drivers/built-in.o: In function `pcm_hw_params': sound.c:(.text+0x3cd54c): undefined reference to `_snd_pcm_lib_alloc_vmalloc_buffer' drivers/built-in.o: In function `playback_thread': sound.c:(.text+0x3cd6a0): undefined reference to `snd_pcm_period_elapsed' drivers/built-in.o: In function `audio_probe_channel': sound.c:(.text+0x3cdc0b): undefined reference to `snd_pcm_new' sound.c:(.text+0x3cdc2b): undefined reference to `snd_pcm_set_ops' drivers/built-in.o:(.data+0x952d0): undefined reference to `snd_pcm_lib_ioctl' drivers/built-in.o:(.data+0x95318): undefined reference to `snd_pcm_lib_get_vmalloc_page' Signed-off-by: Randy Dunlap Cc: Christian Gromm --- drivers/staging/most/aim-sound/Kconfig |1 + 1 file changed, 1 insertion(+) --- linux-next-20150803.orig/drivers/staging/most/aim-sound/Kconfig +++ linux-next-20150803/drivers/staging/most/aim-sound/Kconfig @@ -5,6 +5,7 @@ config AIM_SOUND tristate "ALSA AIM" depends on SND + select SND_PCM ---help--- Say Y here if you want to commumicate via ALSA/sound devices. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 -next] staging: most: fix hdm-dim2 build error
From: Randy Dunlap Fix build of hdm-dim2. Since it calls a function that is provided by AIM_NETWORK, make it depend on that symbol. Also fix a misspelling in the Kconfig file. drivers/built-in.o: In function `deliver_netinfo_thread': dim2_hdm.c:(.text+0x3a9563): undefined reference to `most_deliver_netinfo' Signed-off-by: Randy Dunlap Cc: Jain Roy Ambi Cc: Andrey Shvetsov --- drivers/staging/most/hdm-dim2/Kconfig |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) --- linux-next-20150803.orig/drivers/staging/most/hdm-dim2/Kconfig +++ linux-next-20150803/drivers/staging/most/hdm-dim2/Kconfig @@ -4,9 +4,10 @@ config HDM_DIM2 tristate "DIM2 HDM" + depends on AIM_NETWORK ---help--- - Say Y here if you want to connect via MediaLB to network tranceiver. + Say Y here if you want to connect via MediaLB to network transceiver. This device driver is platform dependent and needs an addtional platform driver to be installed. For more information contact maintainer of this driver. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/7] locking/pvqspinlock: Add pending bit support
On Fri, 2015-07-31 at 22:21 -0400, Waiman Long wrote: > /* > + * Try to acquire the lock and wait using the pending bit > + */ > +static int pv_pending_lock(struct qspinlock *lock, u32 val) Sorry but, why did yo not rewrite the function as we had previously discussed. This is very confusing to read, the one I suggested follows a much nicer flow and purposely illustrates the intention. You also failed to address my loop semantics concerns altogether. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/7] locking/pvqspinlock: Unconditional PV kick with _Q_SLOW_VAL
On Mon, Aug 03, 2015 at 11:22:09AM -0700, Davidlohr Bueso wrote: > On Sun, 2015-08-02 at 00:29 +0200, Peter Zijlstra wrote: > > That's just gibberish, even in the same cacheline stuff can get > > reordered. > > true dat > > > > > So either we insert > > > + * memory barrier here and in the corresponding pv_wait_head() > > > + * function or we do an unconditional kick which is what is done here. > > > > why, why why ? You've added words, but you've not actually described > > what the problem is you're trying to fix. > > > > AFAICT the only thing we really care about here is that the load in > > question happens _after_ we observe SLOW, and that is still true. > > > > The order against the unlock is irrelevant. > > > > So we set ->state before we hash and before we set SLOW. Given that > > we've seen SLOW, we must therefore also see ->state. > > > > If ->state == halted, this means the CPU in question is blocked and the > > pv_node will not get re-used -- if it does get re-used, it wasn't > > blocked and we don't care either. > > Right, if it does get re-used, we were burning SPIN_THRESHOLD and racing > only wastes a few spins, afaict. In fact this is explicitly stated: > > /* >* The unlocker should have freed the lock before kicking the >* CPU. So if the lock is still not free, it is a spurious >* wakeup and so the vCPU should wait again after spinning for >* a while. >*/ > > The thing I like about this patch is that it simplifies the > pv_kick/pv_wait flow, not having to depend on minutia like ->state > checking. But the condition about spurious wakeups is already there, so > really nothing changes. OK, so there's no 'fix'? The patch claims we can loose a wakeup and I just don't see how that is true. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] sched: Trace point sched_stat_sleep should cover iowait case
On Mon, Aug 03, 2015 at 01:35:28PM -0400, Steven Rostedt wrote:
> On Mon, 27 Jul 2015 09:11:52 -0400
> yangoliver wrote:
>
> > Per sched_stat_sleep definition in sched.h, it should include
> > iowait case. This can also relect the design of sum_sleep_runtime
> > statistic, as this counter also includes the io_wait.
> >
> > Signed-off-by: Yong Yang
> > ---
> > kernel/sched/fair.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> > index d113c3b..85677bf 100644
> > --- a/kernel/sched/fair.c
> > +++ b/kernel/sched/fair.c
> > @@ -3018,6 +3018,8 @@ static void enqueue_sleeper(struct cfs_rq *cfs_rq,
> > struct sched_entity *se)
> > se->statistics.sum_sleep_runtime += delta;
> >
> > if (tsk) {
> > + trace_sched_stat_sleep(tsk, delta);
> > +
> > if (tsk->in_iowait) {
> > se->statistics.iowait_sum += delta;
> > se->statistics.iowait_count++;
>
No, that's broken in two ways. Firstly you don't change semantics of
stuff just because of a comment and secondly iowait has nothing what all
to do with INTERRUPTIBLE/sleep vs UNINTERRUPTIBLE/blocked.
And wtf are you doing sending sched patches and not Cc maintainers.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -next] staging: most: fix aim-sound build errors
On Mon, 3 Aug 2015 11:35:47 -0700 Randy Dunlap wrote: > From: Randy Dunlap > > Fix build errors: driver uses snd_pcm*() interfaces, so select > SND_PCM. > > drivers/built-in.o: In function `audio_rx_completion': > sound.c:(.text+0x3cd376): undefined reference to `snd_pcm_period_elapsed' > drivers/built-in.o: In function `pcm_prepare': > sound.c:(.text+0x3cd3b0): undefined reference to > `snd_pcm_format_physical_width' > sound.c:(.text+0x3cd3ce): undefined reference to `snd_pcm_format_big_endian' > sound.c:(.text+0x3cd42c): undefined reference to `snd_pcm_format_big_endian' > drivers/built-in.o: In function `pcm_hw_free': > sound.c:(.text+0x3cd50a): undefined reference to > `snd_pcm_lib_free_vmalloc_buffer' > drivers/built-in.o: In function `pcm_hw_params': > sound.c:(.text+0x3cd54c): undefined reference to > `_snd_pcm_lib_alloc_vmalloc_buffer' > drivers/built-in.o: In function `playback_thread': > sound.c:(.text+0x3cd6a0): undefined reference to `snd_pcm_period_elapsed' > drivers/built-in.o: In function `audio_probe_channel': > sound.c:(.text+0x3cdc0b): undefined reference to `snd_pcm_new' > sound.c:(.text+0x3cdc2b): undefined reference to `snd_pcm_set_ops' > drivers/built-in.o:(.data+0x952d0): undefined reference to `snd_pcm_lib_ioctl' > drivers/built-in.o:(.data+0x95318): undefined reference to > `snd_pcm_lib_get_vmalloc_page' > > Signed-off-by: Randy Dunlap Acked-by: Christian Gromm > Cc: Christian Gromm > --- > drivers/staging/most/aim-sound/Kconfig |1 + > 1 file changed, 1 insertion(+) > > --- linux-next-20150803.orig/drivers/staging/most/aim-sound/Kconfig > +++ linux-next-20150803/drivers/staging/most/aim-sound/Kconfig > @@ -5,6 +5,7 @@ > config AIM_SOUND > tristate "ALSA AIM" > depends on SND > + select SND_PCM > ---help--- > Say Y here if you want to commumicate via ALSA/sound devices. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Ksummit-discuss] Kernel Summit 2015: Call for Proposals
The Kernel Summit call for proposals/topics was sent out a month ago: http://lists.linuxfoundation.org/pipermail/ksummit-discuss/2015-July/001242.html In that call, I asked that people send nominations (including self nominations) and topic suggestions by the end of July since the program committee would start considering people who should be issued invites. The mechnically generated list of people to be considered, plus people that have been added due to nominations, being called out as useful participants for various discussions, etc., can be found here: https://goo.gl/m62WpI As favor to me, if you could take a look at the spreadsheet and let me know if there are any e-mail addresses which have are incorrect or shoud be updated, please let me know. Also, if there are any last minute nominations that you'd like to suggest for the list, please let me know by the end of day on Wednesday, August 5th. Many thanks!! - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] x86/ldt: allow to disable modify_ldt at runtime
On Mon, Aug 3, 2015 at 11:23 AM, Willy Tarreau wrote: > For distros who prefer not to take the risk of completely disabling the > modify_ldt syscall using CONFIG_MODIFY_LDT_SYSCALL, this patch adds a > sysctl to enable, temporarily disable, or permanently disable it at > runtime, and proposes to temporarily disable it by default. This can be > a safe alternative. A message is logged if an attempt was stopped so that > it's easy to spot if/when it is needed. > > Cc: Andy Lutomirski > Cc: Kees Cook > Signed-off-by: Willy Tarreau > --- > Documentation/sysctl/kernel.txt | 16 > arch/x86/Kconfig| 17 + > arch/x86/kernel/ldt.c | 15 +++ > kernel/sysctl.c | 14 ++ > 4 files changed, 62 insertions(+) > > diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt > index 6fccb69..55648b9 100644 > --- a/Documentation/sysctl/kernel.txt > +++ b/Documentation/sysctl/kernel.txt > @@ -41,6 +41,7 @@ show up in /proc/sys/kernel: > - kptr_restrict > - kstack_depth_to_print [ X86 only ] > - l2cr[ PPC only ] > +- modify_ldt [ X86 only ] > - modprobe==> Documentation/debugging-modules.txt > - modules_disabled > - msg_next_id[ sysv ipc ] > @@ -391,6 +392,21 @@ This flag controls the L2 cache of G3 processor boards. > If > > == > > +modify_ldt: (X86 only) > + > +Enables (1), disables (0) or permanently disables (-1) the modify_ldt > syscall. > +Modifying the LDT (Local Descriptor Table) may be needed to run a 16-bit or > +segmented code such as Dosemu or Wine. This is done via a system call which > is > +not needed to run portable applications, and which can sometimes be abused to > +exploit some weaknesses of the architecture, opening new vulnerabilities. > + I'm not entirely convinced that the lock bit should work this way. At some point, we might want a setting for "32-bit only" or even "32-bit, present, not non-conforming only" (like we do unconditionally for set_thread_area). When we do that, having -1 act like 0 might be confusing. I'd actually favor rigging it up to support enumerated values and/or the word "locked" somewhere in the text. So we could have "0", "1 locked", "1" or even "enabled" "enabled locked", "disabled", "disabled locked", "safe 32-bit", "safe 32-bit locked", etc. I'll add an explicit 16-bit check to my infinite todo list for the asm part. Now that the synchronous modify_ldt code is merged, it won't be racy, and it would make a 32-bit only mode actually be useful (except maybe on AMD -- someone needs to test just how badly broken IRET is on AMD systems -- I know that AMD has IRET-to-16-bit differently broken from Intel, and that causes test-cast failures. Grump.) P.S. Hey CPU vendors: please consider stopping your utter suckage when it comes to critical system instructions. Intel and AMD both terminally screwed up IRET in multiple ways that clearly took actual effort. Intel screwed up SYSRET pretty badly (AFAIK every single 64-bit OS has had at least one root hole as a result), and AMD screwed SYSRET up differently (userspace crash bug that requires a performance hit to mitigate because no one at AMD realized that one might preempt a process during a syscall). P.P.S. You know what would be *way* better than allowing IRET to fault? Just allow IRET to continue executing the next instruction on failure (I'm talking about #GP, #NP, and #SS here, not page faults). P.P.P.S. Who thought that IRET faults unmasking NMIs made any sense whatsoever when NMIs run on an IST stack? Seriously, people? --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 tip] locking/static_keys: verify_keys() can be static
Signed-off-by: Fengguang Wu
---
test_static_keys.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lib/test_static_keys.c b/lib/test_static_keys.c
index 81d8105..c61b299 100644
--- a/lib/test_static_keys.c
+++ b/lib/test_static_keys.c
@@ -70,7 +70,7 @@ static void invert_keys(struct test_key *keys, int size)
}
}
-int verify_keys(struct test_key *keys, int size, bool invert)
+static int verify_keys(struct test_key *keys, int size, bool invert)
{
int i;
bool ret, init;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[tip:locking/core 19/20] lib/test_static_keys.c:23:19: sparse: symbol 'old_true_key' was not declared. Should it be static?
tree: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core head: 412758cb26704e5087ca2976ec3b28fb2bdbfad4 commit: 2bf9e0ab08c64ac56067555911a1ae81ebff5f96 [19/20] locking/static_keys: Provide a selftest reproduce: # apt-get install sparse git checkout 2bf9e0ab08c64ac56067555911a1ae81ebff5f96 make ARCH=x86_64 allmodconfig make C=1 CF=-D__CHECK_ENDIAN__ sparse warnings: (new ones prefixed by >>) >> lib/test_static_keys.c:23:19: sparse: symbol 'old_true_key' was not >> declared. Should it be static? >> lib/test_static_keys.c:24:19: sparse: symbol 'old_false_key' was not >> declared. Should it be static? >> lib/test_static_keys.c:27:1: sparse: symbol 'true_key' was not declared. >> Should it be static? >> lib/test_static_keys.c:28:1: sparse: symbol 'false_key' was not declared. >> Should it be static? >> lib/test_static_keys.c:73:5: sparse: symbol 'verify_keys' was not declared. >> Should it be static? Please review and possibly fold the followup patch. --- 0-DAY kernel test infrastructureOpen Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sata_sx4: Check return code from pdc20621_i2c_read()
The variable spd0 might be used uninitialized when pdc20621_i2c_read()
fails.
This also generates a compilation warning with gcc 5.1.
Signed-off-by: Tomer Barletz
---
drivers/ata/sata_sx4.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/sata_sx4.c b/drivers/ata/sata_sx4.c
index 3a18a8a..e1c1423 100644
--- a/drivers/ata/sata_sx4.c
+++ b/drivers/ata/sata_sx4.c
@@ -1238,8 +1238,12 @@ static unsigned int pdc20621_prog_dimm_global(struct
ata_host *host)
readl(mmio + PDC_SDRAM_CONTROL);
/* Turn on for ECC */
- pdc20621_i2c_read(host, PDC_DIMM0_SPD_DEV_ADDRESS,
- PDC_DIMM_SPD_TYPE, &spd0);
+ if (!pdc20621_i2c_read(host, PDC_DIMM0_SPD_DEV_ADDRESS,
+ PDC_DIMM_SPD_TYPE, &spd0)) {
+ printk(KERN_ERR "Failed in i2c read: device=%#x, subaddr=%#x\n",
+ PDC_DIMM0_SPD_DEV_ADDRESS, PDC_DIMM_SPD_TYPE);
+ return 1;
+ }
if (spd0 == 0x02) {
data |= (0x01 << 16);
writel(data, mmio + PDC_SDRAM_CONTROL);
@@ -1380,8 +1384,12 @@ static unsigned int pdc20621_dimm_init(struct ata_host
*host)
/* ECC initiliazation. */
- pdc20621_i2c_read(host, PDC_DIMM0_SPD_DEV_ADDRESS,
- PDC_DIMM_SPD_TYPE, &spd0);
+ if (!pdc20621_i2c_read(host, PDC_DIMM0_SPD_DEV_ADDRESS,
+ PDC_DIMM_SPD_TYPE, &spd0)) {
+ printk(KERN_ERR "Failed in i2c read: device=%#x, subaddr=%#x\n",
+ PDC_DIMM0_SPD_DEV_ADDRESS, PDC_DIMM_SPD_TYPE);
+ return 1;
+ }
if (spd0 == 0x02) {
void *buf;
VPRINTK("Start ECC initialization\n");
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Nokia N900 - audio TPA6130A2 problems
On 08/03/2015 09:17 PM, Pali Rohár wrote: > On Monday 03 August 2015 20:03:16 Jarkko Nikula wrote: >> Hi >> >> On 08/01/2015 01:18 PM, Pali Rohár wrote: >>> On Saturday 25 July 2015 15:17:13 Lars-Peter Clausen wrote: >>> Hello, your patch did not helped. Problem is still there... >> >> For me v4.2-rc5 works, i.e. TPA6130A2 can still play loudly to >> headphones. Don't know were there any i2c etc regression before it or >> how easy it would be to reproduce. >> > > Did you tested it on Nokia N900? Or other device? > N900. Seems to be only user of TPA6130A2 in mainline :-) >> Logs below made me thinking can it be a HW issue? Although if it is >> an HW issue it shouldn't work sometimes I guess. Do you have any >> earlier well known configuration you could try is it an SW >> regression or something else? >> > > Stock Nokia's 2.6.28 kernel works always. With that kernel I have never > seen this problem. So I do not think this is HW problem. > > This problem is there in more kernel versions, maybe in some older (like > v3.5) is was there not so often. But do not remember correctly... > It is well possible that some regression got introduced to TPA6130A2 I2C communication over the years without nobody than you now notices. We used to do QA back in Meego N900 days but that was pre 3.x kernels. > Maybe some power management problem? Something is not always initialized > correctly? > > I remember that there is some problem (maybe in NoLo - Nokia bootloader) > that sometimes chainloaded U-Boot (booted via NoLo) is not able to > initialize mmc chip (all read operation fails). In U-Boot I added some > code to enable some parts in twl4030 regulator and after that mmc is > working always... > > So maybe something similar? Kernel expects that some PM or regulator > parts are initialized, but they are only sometimes? Just speculation... > I'm thinking the same. I could figure SCL could be stuck low if TPA or some other chip connected to the same I2C bus is without power and is pulling I2C signals down. -- Jarkko -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION] Re: i915 driver crashes on T540p if docking station attached
On Mon, Aug 03, 2015 at 10:24:53AM -0700, Linus Torvalds wrote: > On Mon, Aug 3, 2015 at 9:25 AM, Theodore Ts'o wrote: > > > > I've just tried pulling in your updated fixes-stuff, and it avoids the > > oops and allows external the monitor to work correctly. > > Good. Have either of you tested the suspend/resume behavior? Is that fixed > too? No, I haven't had a chance to test the suspend/resume behavior, because that requires suspending at work, going home, and connecting to a dock which has a different monitor attached to it, and resuming (or vice versa of suspending at home and then resuming at work). So it's a bit trickier for me to test. It's also not a regression, and the workaround of rebooting is annoying, but I've lived with it for several releases now, but I'll try the two patches/changes that folks had suggested hopefully later this week. - Ted -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] sysctl: add a new generic strategy to make permanent changes on negative values
On Mon, Aug 03, 2015 at 11:33:30AM -0700, Andy Lutomirski wrote:
> On Mon, Aug 3, 2015 at 11:23 AM, Willy Tarreau wrote:
> > The new function is proc_dointvec_minmax_negperm(), it refuses to change
> > the value if the current one is already negative. This will be used to
> > lock down some settings such as sensitive system calls.
> >
> > Signed-off-by: Willy Tarreau
> > ---
> > kernel/sysctl.c | 36
> > 1 file changed, 36 insertions(+)
> >
> > diff --git a/kernel/sysctl.c b/kernel/sysctl.c
> > index 19b62b5..86c95a8 100644
> > --- a/kernel/sysctl.c
> > +++ b/kernel/sysctl.c
> > @@ -185,6 +185,9 @@ static int proc_dointvec_minmax_sysadmin(struct
> > ctl_table *table, int write,
> > void __user *buffer, size_t *lenp, loff_t
> > *ppos);
> > #endif
> >
> > +static int proc_dointvec_minmax_negperm(struct ctl_table *table, int write,
> > + void __user *buffer, size_t *lenp, loff_t *ppos);
> > +
> > static int proc_dointvec_minmax_coredump(struct ctl_table *table, int
> > write,
> > void __user *buffer, size_t *lenp, loff_t *ppos);
> > #ifdef CONFIG_COREDUMP
> > @@ -2249,6 +2252,33 @@ static void validate_coredump_safety(void)
> > #endif
> > }
> >
> > +/* Like minmax except that it refuses any change if the value was already
> > + * negative. It silently ignores overrides with the same negative value.
> > + */
> > +static int do_proc_dointvec_negperm_conv(bool *negp, unsigned long *lvalp,
> > +int *valp,
> > +int write, void *data)
> > +{
> > + if (write && *valp < 0 && (!*negp || *valp != (int)*lvalp))
>
> I could easily have failed to follow the bizarre negative sign
> convention, but shouldn't that be "*valp != -(int)*lvalp" or similar?
Not exactly since the sign is passed via negp apparently. There
is an expression in the called function which first assigns lvalp
or -lvalp to val depending on val, then uses the resulting value.
The code above is the (simplified for me) equivalent of :
int val = *negp ? -*lvalp : *lvalp;
if (write && *valp < 0 && *valp != val)
return -EINVAL;
Maybe you find it more readable in which case I can redo it this way ?
In my case it was the opposite in fact, I want to reject non-negative
values as well as the negative ones not equal to *valp.
Note that we could have decided to make it even simpler and always
reject writes once *valp is < 0 but I find that it would be annoying
for hardening scripts which would not be idempotent anymore.
Willy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: 4.0.8->4.1.3 : after resume from s2ram both internal and external display of a docked ThinkPad ate black
On 08/03/2015 11:53 AM, Toralf Förster wrote: > A quick look at the latest 4.1.3+hardened just shows that the power button at > the docking station does not produce an ACPI event. This is fixed between 4.1.3 and 4.1.4 - would be helpful to know the commit id for the following bisecting of the blackmonitor issue (still an issue in 4.1.4 and 4.2-rc5) -- Toralf, pgp key: 872AE508 0076E94E -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: dts: keystone: fix the clock node for mdio
On 08/03/2015 02:30 PM, santosh.shilim...@oracle.com wrote: On 8/3/15 11:22 AM, Murali Karicheri wrote: On 08/03/2015 02:11 PM, Murali Karicheri wrote: Currently the MDIO clock is pointing to clkpa instead of clkcpgmac. MDIO is part of the ethss and the clock should be clkcpgmac. Signed-off-by: Murali Karicheri --- arch/arm/boot/dts/keystone.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi index e7a6f6d..6245a17 100644 --- a/arch/arm/boot/dts/keystone.dtsi +++ b/arch/arm/boot/dts/keystone.dtsi @@ -273,7 +273,7 @@ #size-cells = <0>; reg= <0x02090300 0x100>; status = "disabled"; -clocks = <&clkpa>; +clocks = <&clkcpgmac>; clock-names = "fck"; bus_freq= <250>; }; Santosh, This is a big fix and needs to go in v4.2-rc. So please review and apply asap. v4.2 is the first release that has netcp driver fully functional and I want to fix as many known bugs as possible. Do you have more fixes ? If yes, please post them so that I can include them along with these two. I will try to send them up next week. I think we have got most of the know issues fixed in the netcp driver and dts for v4.2-rc. Another lingering issue is the one with multiple clock handling not supported in run time pm API causing us to use the work around 'clk_ignore_unused'. Probably this needs to be addressed in the future as fixing this is not trivial. Generic PD support would partially solve the issue for Keystone, but also needs to handle multiple clocks for keystone. Another option is to fix the NetCP and QMSS/KNAV driver for now in v4.0-rc using explicit clock APIs so that we don't have to use 'clk_ignore_unused'. And then migrate all of the drivers to run time PM API later when proper framework is implemented along with K2G support. Does this make sense? Anyways, please submit these patches at your earliest opportunity. Thanks Murali Thanks !! Regards, Santosh -- Murali Karicheri Linux Kernel, Keystone -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] mfd: s2mps11: Add manual shutdown method for Odroid XU3
Hi Krzysztof,
On 3 August 2015 at 18:07, Krzysztof Kozlowski wrote:
> On Odroid XU3 board (with S2MPS11 PMIC) the PWRHOLD bit in CTRL1
> register must be manually set to 0 before initiating power off sequence.
>
> One of usual power down methods for Exynos based devices looks like:
> 1. PWRHOLD pin of PMIC is connected to PSHOLD of Exynos.
> 2. Exynos holds up this pin during system operation.
> 3. ACOKB pin of PMIC is pulled up to VBATT and optionally to pin in
>other device.
> 4. When PWRHOLD/PSHOLD goes low, the PMIC will turn off the power if
>ACOKB goes high.
>
> On Odroid XU3 family the difference is in (3) - the ACOKB is grounded.
> This means that PMIC must manually set PWRHOLD field to low and then
> wait for signal from Application Processor (the usual change in
> PWRHOLD/PSHOLD pin will actually cut off the power).
>
> The patch adds respective binding allowing Odroid XU3 device to be
> powered off.
>
> Signed-off-by: Krzysztof Kozlowski
> Reported-by: Anand Moon
>
> ---
>
> Patch is losely based on patch in Hardkernel repository [0] and previous
> work of Anand Moon [1].
>
> [0]
> https://github.com/hardkernel/linux/commit/6897e62ba328bd1c8c095d918101863250cd73e7
> [1] http://www.spinics.net/lists/linux-samsung-soc/msg45959.html
> ---
> Documentation/devicetree/bindings/mfd/s2mps11.txt | 4 +++
> drivers/mfd/sec-core.c| 31
> +++
> include/linux/mfd/samsung/core.h | 2 ++
> include/linux/mfd/samsung/s2mps11.h | 1 +
> 4 files changed, 38 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mfd/s2mps11.txt
> b/Documentation/devicetree/bindings/mfd/s2mps11.txt
> index 57a045016fca..90eaef393325 100644
> --- a/Documentation/devicetree/bindings/mfd/s2mps11.txt
> +++ b/Documentation/devicetree/bindings/mfd/s2mps11.txt
> @@ -15,6 +15,10 @@ Optional properties:
> - interrupt-parent: Specifies the phandle of the interrupt controller to
> which
>the interrupts from s2mps11 are delivered to.
> - interrupts: Interrupt specifiers for interrupt sources.
> +- samsung,s2mps11-acokb-ground: Indicates that ACOKB pin of S2MPS11 PMIC is
> + connected to the ground so the PMIC must manually set PWRHOLD bit in CTRL1
> + register to turn off the power. Usually the ACOKB is pulled up to VBATT so
> + when PWRHOLD pin goes low, the rising ACOKB will trigger power off.
>
> Optional nodes:
> - clocks: s2mps11, s2mps13 and s5m8767 provide three(AP/CP/BT) buffered
> 32.768
> diff --git a/drivers/mfd/sec-core.c b/drivers/mfd/sec-core.c
> index d206a3e8fe87..a56ab2102a32 100644
> --- a/drivers/mfd/sec-core.c
> +++ b/drivers/mfd/sec-core.c
> @@ -278,6 +278,8 @@ static struct sec_platform_data
> *sec_pmic_i2c_parse_dt_pdata(
> * not parsed here.
> */
>
> + pd->manual_poweroff = of_property_read_bool(dev->of_node,
> +
> "samsung,s2mps11-acokb-ground");
> return pd;
> }
> #else
> @@ -440,6 +442,34 @@ static int sec_pmic_remove(struct i2c_client *i2c)
> return 0;
> }
>
> +static void sec_pmic_shutdown(struct i2c_client *i2c)
> +{
> + struct sec_pmic_dev *sec_pmic = i2c_get_clientdata(i2c);
> + unsigned int reg, mask;
> +
> + if (!sec_pmic->pdata->manual_poweroff)
> + return;
> +
> + switch (sec_pmic->device_type) {
> + case S2MPS11X:
> + reg = S2MPS11_REG_CTRL1;
> + mask = S2MPS11_CTRL1_PWRHOLD_MASK;
> + break;
> + default:
> + /*
> +* Currently only one board with S2MPS11 needs this, so just
> +* ignore the rest.
> +*/
> + dev_warn(sec_pmic->dev,
> + "Unsupported device %lu for manual power off\n",
> + sec_pmic->device_type);
> + return;
> + }
> +
> + regmap_update_bits(sec_pmic->regmap_pmic, reg, mask, 0);
> +}
> +
> +
> #ifdef CONFIG_PM_SLEEP
> static int sec_pmic_suspend(struct device *dev)
> {
> @@ -491,6 +521,7 @@ static struct i2c_driver sec_pmic_driver = {
> },
> .probe = sec_pmic_probe,
> .remove = sec_pmic_remove,
> + .shutdown = sec_pmic_shutdown,
> .id_table = sec_pmic_id,
> };
>
> diff --git a/include/linux/mfd/samsung/core.h
> b/include/linux/mfd/samsung/core.h
> index 75115384f3fc..aa78957e092f 100644
> --- a/include/linux/mfd/samsung/core.h
> +++ b/include/linux/mfd/samsung/core.h
> @@ -132,6 +132,8 @@ struct sec_platform_data {
> int buck2_init;
> int buck3_init;
> int buck4_init;
> + /* Whether or not manually set PWRHOLD to low during shutdown. */
> + boolmanual_poweroff;
> };
>
> /**
> diff --git a/include/linux/mfd/samsung/s2mps11.h
> b/include/linux/mfd/samsung/s2mps11.h
> i
Re: [Ksummit-discuss] Kernel Summit 2015: Call for Proposals
On Mon, Aug 3, 2015 at 2:44 PM, Theodore Ts'o wrote: > The Kernel Summit call for proposals/topics was sent out a month ago: > > http://lists.linuxfoundation.org/pipermail/ksummit-discuss/2015-July/001242.html > > In that call, I asked that people send nominations (including self > nominations) and topic suggestions by the end of July since the > program committee would start considering people who should be issued > invites. > > The mechnically generated list of people to be considered, plus people > that have been added due to nominations, being called out as useful > participants for various discussions, etc., can be found here: > > https://goo.gl/m62WpI > > As favor to me, if you could take a look at the spreadsheet and let me > know if there are any e-mail addresses which have are incorrect or > shoud be updated, please let me know. Also, if there are any last > minute nominations that you'd like to suggest for the list, please let > me know by the end of day on Wednesday, August 5th. You have me as Tagged for Live Patching. While that is indeed interesting to me, I don't think you have the correct Josh there. It should be Josh Poimboeuf . As a separate item, David Howells brought up the firmware discussion but you do not have the current linux-firmware maintainer on your list. Kyle McMartin has been performing that task for several months now. 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: [PATCH] sata_sx4: Check return code from pdc20621_i2c_read()
On 08/03/2015 09:46 PM, Tomer Barletz wrote:
The variable spd0 might be used uninitialized when pdc20621_i2c_read()
fails.
This also generates a compilation warning with gcc 5.1.
Signed-off-by: Tomer Barletz
---
drivers/ata/sata_sx4.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/sata_sx4.c b/drivers/ata/sata_sx4.c
index 3a18a8a..e1c1423 100644
--- a/drivers/ata/sata_sx4.c
+++ b/drivers/ata/sata_sx4.c
@@ -1238,8 +1238,12 @@ static unsigned int pdc20621_prog_dimm_global(struct
ata_host *host)
readl(mmio + PDC_SDRAM_CONTROL);
/* Turn on for ECC */
- pdc20621_i2c_read(host, PDC_DIMM0_SPD_DEV_ADDRESS,
- PDC_DIMM_SPD_TYPE, &spd0);
+ if (!pdc20621_i2c_read(host, PDC_DIMM0_SPD_DEV_ADDRESS,
+ PDC_DIMM_SPD_TYPE, &spd0)) {
That won't do, you didn't fix the indentation here.
+ printk(KERN_ERR "Failed in i2c read: device=%#x, subaddr=%#x\n",
+ PDC_DIMM0_SPD_DEV_ADDRESS, PDC_DIMM_SPD_TYPE);
+ return 1;
+ }
if (spd0 == 0x02) {
data |= (0x01 << 16);
writel(data, mmio + PDC_SDRAM_CONTROL);
@@ -1380,8 +1384,12 @@ static unsigned int pdc20621_dimm_init(struct ata_host
*host)
/* ECC initiliazation. */
- pdc20621_i2c_read(host, PDC_DIMM0_SPD_DEV_ADDRESS,
- PDC_DIMM_SPD_TYPE, &spd0);
+ if (!pdc20621_i2c_read(host, PDC_DIMM0_SPD_DEV_ADDRESS,
+ PDC_DIMM_SPD_TYPE, &spd0)) {
And here.
+ printk(KERN_ERR "Failed in i2c read: device=%#x, subaddr=%#x\n",
+ PDC_DIMM0_SPD_DEV_ADDRESS, PDC_DIMM_SPD_TYPE);
+ return 1;
+ }
if (spd0 == 0x02) {
void *buf;
VPRINTK("Start ECC initialization\n");
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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: Nokia N900 - audio TPA6130A2 problems
On Monday 03 August 2015 20:48:28 Jarkko Nikula wrote: > On 08/03/2015 09:17 PM, Pali Rohár wrote: > > On Monday 03 August 2015 20:03:16 Jarkko Nikula wrote: > >> Hi > >> > >> On 08/01/2015 01:18 PM, Pali Rohár wrote: > >>> On Saturday 25 July 2015 15:17:13 Lars-Peter Clausen wrote: > >>> Hello, your patch did not helped. Problem is still there... > >> > >> For me v4.2-rc5 works, i.e. TPA6130A2 can still play loudly to > >> headphones. Don't know were there any i2c etc regression before it > >> or how easy it would be to reproduce. > > > > Did you tested it on Nokia N900? Or other device? > > N900. Seems to be only user of TPA6130A2 in mainline :-) > Great, can you do more tests? I get this error often after I reboot N900 (without power off) more times. But no idea if this is just "sometimes". > >> Logs below made me thinking can it be a HW issue? Although if it > >> is an HW issue it shouldn't work sometimes I guess. Do you have > >> any earlier well known configuration you could try is it an SW > >> regression or something else? > > > > Stock Nokia's 2.6.28 kernel works always. With that kernel I have > > never seen this problem. So I do not think this is HW problem. > > > > This problem is there in more kernel versions, maybe in some older > > (like v3.5) is was there not so often. But do not remember > > correctly... > > It is well possible that some regression got introduced to TPA6130A2 > I2C communication over the years without nobody than you now > notices. We used to do QA back in Meego N900 days but that was pre > 3.x kernels. > Do you still have these pre 3.x kernels? This could be good starting point as 2.6.28 kernel is tooo old and heavily patches... > > Maybe some power management problem? Something is not always > > initialized correctly? > > > > I remember that there is some problem (maybe in NoLo - Nokia > > bootloader) that sometimes chainloaded U-Boot (booted via NoLo) is > > not able to initialize mmc chip (all read operation fails). In > > U-Boot I added some code to enable some parts in twl4030 regulator > > and after that mmc is working always... > > > > So maybe something similar? Kernel expects that some PM or > > regulator parts are initialized, but they are only sometimes? Just > > speculation... > > I'm thinking the same. I could figure SCL could be stuck low if TPA > or some other chip connected to the same I2C bus is without power > and is pulling I2C signals down. We should know which devices are connected to which i2c bus. So maybe detecting which i2c device is incorrectly initialized? -- Pali Rohár pali.ro...@gmail.com signature.asc Description: This is a digitally signed message part.
Re: [PATCH 11/18] perf script: Switch from perf.data's kallsyms to perf's symbol resolver
Em Mon, Aug 03, 2015 at 07:41:13PM +0200, Jiri Olsa escreveu: > Missing separate debuginfos, use: dnf debuginfo-install > glibc-2.21-7.fc22.x86_64 > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib64/libthread_db.so.1". > Detaching after fork from child process 11230. > > Program received signal SIGSEGV, Segmentation fault. > 0x004eeace in pevent_set_function_resolver (pevent=0x0, > func=0x4a3197 , priv=0x18e1f48) at > event-parse.c:464 > 464 free(pevent->func_resolver); > Missing separate debuginfos, use: dnf debuginfo-install > audit-libs-2.4.3-1.fc22.x86_64 bzip2-libs-1.0.6-14.fc22.x86_64 > elfutils-libelf-0.163-1.fc22.x86_64 elfutils-libs-0.163-1.fc22.x86_64 > libunwind-1.1-10.fc22.x86_64 nss-softokn-freebl-3.19.2-1.0.fc22.x86_64 > numactl-libs-2.0.10-2.fc22.x86_64 perl-libs-5.20.2-326.fc22.x86_64 > python-libs-2.7.10-4.fc22.x86_64 slang-2.3.0-2.fc22.x86_64 > xz-libs-5.2.0-2.fc22.x86_64 zlib-1.2.8-7.fc22.x86_64 > (gdb) > I think 'session->tevent.pevent' gets initialized only for tracepoint, right? Reproduced, checking. - Arnaldo -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] ARM: dts: keystone: fix the clock node for mdio
On 8/3/15 11:50 AM, Murali Karicheri wrote: On 08/03/2015 02:30 PM, santosh.shilim...@oracle.com wrote: On 8/3/15 11:22 AM, Murali Karicheri wrote: On 08/03/2015 02:11 PM, Murali Karicheri wrote: Currently the MDIO clock is pointing to clkpa instead of clkcpgmac. MDIO is part of the ethss and the clock should be clkcpgmac. Signed-off-by: Murali Karicheri --- arch/arm/boot/dts/keystone.dtsi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm/boot/dts/keystone.dtsi b/arch/arm/boot/dts/keystone.dtsi index e7a6f6d..6245a17 100644 --- a/arch/arm/boot/dts/keystone.dtsi +++ b/arch/arm/boot/dts/keystone.dtsi @@ -273,7 +273,7 @@ #size-cells = <0>; reg= <0x02090300 0x100>; status = "disabled"; -clocks = <&clkpa>; +clocks = <&clkcpgmac>; clock-names = "fck"; bus_freq= <250>; }; Santosh, This is a big fix and needs to go in v4.2-rc. So please review and apply asap. v4.2 is the first release that has netcp driver fully functional and I want to fix as many known bugs as possible. Do you have more fixes ? If yes, please post them so that I can include them along with these two. I will try to send them up next week. I think we have got most of the know issues fixed in the netcp driver and dts for v4.2-rc. Another lingering issue is the one with multiple clock handling not supported in run time pm API causing us to use the work around 'clk_ignore_unused'. Probably this needs to be addressed in the future as fixing this is not trivial. Generic PD support would partially solve the issue for Keystone, but also needs to handle multiple clocks for keystone. Yeah. I was also wondering on what happened to that work which was active at some point of time. Another option is to fix the NetCP and QMSS/KNAV driver for now in v4.0-rc using explicit clock APIs so that we don't have to use 'clk_ignore_unused'. And then migrate all of the drivers to run time PM API later when proper framework is implemented along with K2G support. Does this make sense? Multiple clock node support work which was started needs to be revived. Direct clock isn't the way to go about it. Anyways, please submit these patches at your earliest opportunity. Sure. Regards, Santosh -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] x86/ldt: allow to disable modify_ldt at runtime
On Mon, Aug 03, 2015 at 11:45:24AM -0700, Andy Lutomirski wrote: > I'm not entirely convinced that the lock bit should work this way. At > some point, we might want a setting for "32-bit only" or even "32-bit, > present, not non-conforming only" (like we do unconditionally for > set_thread_area). When we do that, having -1 act like 0 might be > confusing. > > I'd actually favor rigging it up to support enumerated values and/or > the word "locked" somewhere in the text. So we could have "0", "1 > locked", "1" or even "enabled" "enabled locked", "disabled", "disabled > locked", "safe 32-bit", "safe 32-bit locked", etc. Got it, that makes sense indeed. I asked myself whether we'd use more than these 3 values, and estimated that "locked on" didn't make much sense here, and I thought that nobody would like to manipulate such things using bitmaps. But with words like this it can indeed make sense. I feel like it's probably part of a larger project then. Do you think we should step back and only support 0/1 for now ? I also have the patch available. > I'll add an explicit 16-bit check to my infinite todo list for the asm > part. Now that the synchronous modify_ldt code is merged, it won't be > racy, and it would make a 32-bit only mode actually be useful (except > maybe on AMD -- someone needs to test just how badly broken IRET is on > AMD systems -- I know that AMD has IRET-to-16-bit differently broken > from Intel, and that causes test-cast failures. Grump.) > > P.S. Hey CPU vendors: please consider stopping your utter suckage when > it comes to critical system instructions. Intel and AMD both > terminally screwed up IRET in multiple ways that clearly took actual > effort. Intel screwed up SYSRET pretty badly (AFAIK every single > 64-bit OS has had at least one root hole as a result), and AMD screwed > SYSRET up differently (userspace crash bug that requires a performance > hit to mitigate because no one at AMD realized that one might preempt > a process during a syscall). Well the good thing is that SYSRET reused the LOADALL opcode so at least this one cannot be screwed on 64-bit :-) It would have helped us to emulate IRET though. > P.P.S. You know what would be *way* better than allowing IRET to > fault? Just allow IRET to continue executing the next instruction on > failure (I'm talking about #GP, #NP, and #SS here, not page faults). > > P.P.P.S. Who thought that IRET faults unmasking NMIs made any sense > whatsoever when NMIs run on an IST stack? Seriously, people? A dedicated flag "don't clear NMI yet" would have been nice in EFLAGS so that the software stack could set it in fault handlers. It would be one-shot and always cleared by IRET. That would have been very handy. Willy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.14 000/125] 3.14.49-stable review
On 08/03/2015 10:17 AM, Greg Kroah-Hartman wrote: > On Sat, Aug 01, 2015 at 12:42:02PM +0530, Sudip Mukherjee wrote: >> On Sat, Aug 01, 2015 at 12:39:25PM +0530, Sudip Mukherjee wrote: >>> On Fri, Jul 31, 2015 at 12:40:00PM -0700, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.14.49 release. There are 125 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 Sun Aug 2 19:40:05 UTC 2015. Anything received after that time might be too late. >>> Compiled and booted on x86_32. >>> >>> While kselftest got a report of segmentation fault and in dmesg: >>> psock_fanout[2509]: segfault at 401fd000 ip 080492ab sp bfc40cd0 error 4 >>> in psock_fanout[8048000+2000] >> >> Missed a clarification, kselftest is not there. ran the tests with: kselftest target isn't in 3.14. It was added to 3.17 or 3.18. >> sudo make -C tools/testing/selftests run_tests > > Is this something new that shows up in 3.14.49-rc1 and is not in .48? > This is a known issue, fixed in 3.19?? - the following is the commit. Adding Dave Miller to the thread. commit fbf8e7211ac7858d3df4a4203c18da7a58560784 Author: Shuah Khan Date: Tue Nov 11 10:04:13 2014 -0700 selftests/net: psock_fanout seg faults in sock_fanout_read_ring() The while loop in sock_fanout_read_ring() checks mmap region bounds after access, causing it to segfault. Fix it to check count before accessing header->tp_status. This problem can be reproduced consistently when the test in run as follows: make -C tools/testing/selftests TARGETS=net run_tests or make run_tests from tools/testing/selftests or make run_test from tools/testing/selftests/net Signed-off-by: Shuah Khan Signed-off-by: David S. Miller thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 6/8] jump_label: Add a new static_key interface
On Wed, 29 Jul 2015 10:49:06 +0200
Peter Zijlstra wrote:
> On Wed, Jul 29, 2015 at 09:19:22AM +0200, Vlastimil Babka wrote:
>
> > How would one define a static key that's e.g. expected to be mostly false,
> > but
> > with initial value of true, e.g. during boot?
>
> DEFINE_STATIC_KEY_TRUE(blah);
>
> will get you the true at boot time.
>
> You'll then want to use:
>
> if (static_branch_unlikely(&blah)) {
> /* code that mostly doesn't happen */
> }
>
> To indicate you expect it to be false most of the time. And you'll flip
> it to false at runtime using:
>
> static_branch_disable(&blah);
I wonder if static_branch_set_false(&blah) would be a better name to
understand. What does "disable" / "enable" mean?
If we declare it "TRUE" when defining it, it only makes sense to change
it to "false" later on.
-- Steve
>
> If GCC co-operates, the body of the branch will be placed out-of-line,
> we'll emit a jump to it by default, but once you disable it, we'll nop
> the jump and fall straight through.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sata_sx4: Check return code from pdc20621_i2c_read()
I see how it makes sense to add a tab to align with the previous line
of code, as it will always look similar in all editors, no matter how
their tab character is set up to be.
However, adding more tabs will just mess up editors that are not set
up with 8-space width tabs.
Is this a bug in checkpatch.pl, or are we saying everyone should have
their editor set to 8-spaces width tabs?
--Tomer
On Mon, Aug 3, 2015 at 11:52 AM, Sergei Shtylyov
wrote:
> On 08/03/2015 09:46 PM, Tomer Barletz wrote:
>
>> The variable spd0 might be used uninitialized when pdc20621_i2c_read()
>> fails.
>> This also generates a compilation warning with gcc 5.1.
>
>
>> Signed-off-by: Tomer Barletz
>> ---
>> drivers/ata/sata_sx4.c | 16
>> 1 file changed, 12 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/ata/sata_sx4.c b/drivers/ata/sata_sx4.c
>> index 3a18a8a..e1c1423 100644
>> --- a/drivers/ata/sata_sx4.c
>> +++ b/drivers/ata/sata_sx4.c
>> @@ -1238,8 +1238,12 @@ static unsigned int
>> pdc20621_prog_dimm_global(struct ata_host *host)
>> readl(mmio + PDC_SDRAM_CONTROL);
>>
>> /* Turn on for ECC */
>> - pdc20621_i2c_read(host, PDC_DIMM0_SPD_DEV_ADDRESS,
>> - PDC_DIMM_SPD_TYPE, &spd0);
>> + if (!pdc20621_i2c_read(host, PDC_DIMM0_SPD_DEV_ADDRESS,
>> + PDC_DIMM_SPD_TYPE, &spd0)) {
>
>
>That won't do, you didn't fix the indentation here.
>
>> + printk(KERN_ERR "Failed in i2c read: device=%#x,
>> subaddr=%#x\n",
>> + PDC_DIMM0_SPD_DEV_ADDRESS, PDC_DIMM_SPD_TYPE);
>> + return 1;
>> + }
>> if (spd0 == 0x02) {
>> data |= (0x01 << 16);
>> writel(data, mmio + PDC_SDRAM_CONTROL);
>> @@ -1380,8 +1384,12 @@ static unsigned int pdc20621_dimm_init(struct
>> ata_host *host)
>>
>> /* ECC initiliazation. */
>>
>> - pdc20621_i2c_read(host, PDC_DIMM0_SPD_DEV_ADDRESS,
>> - PDC_DIMM_SPD_TYPE, &spd0);
>> + if (!pdc20621_i2c_read(host, PDC_DIMM0_SPD_DEV_ADDRESS,
>> + PDC_DIMM_SPD_TYPE, &spd0)) {
>
>
>And here.
>
>> + printk(KERN_ERR "Failed in i2c read: device=%#x,
>> subaddr=%#x\n",
>> + PDC_DIMM0_SPD_DEV_ADDRESS, PDC_DIMM_SPD_TYPE);
>> + return 1;
>> + }
>> if (spd0 == 0x02) {
>> void *buf;
>> VPRINTK("Start ECC initialization\n");
>
>
> MBR, Sergei
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] x86/ldt: allow to disable modify_ldt at runtime
On Mon, Aug 3, 2015 at 12:01 PM, Willy Tarreau wrote: > On Mon, Aug 03, 2015 at 11:45:24AM -0700, Andy Lutomirski wrote: >> I'm not entirely convinced that the lock bit should work this way. At >> some point, we might want a setting for "32-bit only" or even "32-bit, >> present, not non-conforming only" (like we do unconditionally for >> set_thread_area). When we do that, having -1 act like 0 might be >> confusing. >> >> I'd actually favor rigging it up to support enumerated values and/or >> the word "locked" somewhere in the text. So we could have "0", "1 >> locked", "1" or even "enabled" "enabled locked", "disabled", "disabled >> locked", "safe 32-bit", "safe 32-bit locked", etc. > > Got it, that makes sense indeed. I asked myself whether we'd use more > than these 3 values, and estimated that "locked on" didn't make much > sense here, and I thought that nobody would like to manipulate such > things using bitmaps. But with words like this it can indeed make > sense. > > I feel like it's probably part of a larger project then. Do you think > we should step back and only support 0/1 for now ? I also have the > patch available. Sounds good to me. > >> I'll add an explicit 16-bit check to my infinite todo list for the asm >> part. Now that the synchronous modify_ldt code is merged, it won't be >> racy, and it would make a 32-bit only mode actually be useful (except >> maybe on AMD -- someone needs to test just how badly broken IRET is on >> AMD systems -- I know that AMD has IRET-to-16-bit differently broken >> from Intel, and that causes test-cast failures. Grump.) >> >> P.S. Hey CPU vendors: please consider stopping your utter suckage when >> it comes to critical system instructions. Intel and AMD both >> terminally screwed up IRET in multiple ways that clearly took actual >> effort. Intel screwed up SYSRET pretty badly (AFAIK every single >> 64-bit OS has had at least one root hole as a result), and AMD screwed >> SYSRET up differently (userspace crash bug that requires a performance >> hit to mitigate because no one at AMD realized that one might preempt >> a process during a syscall). > > Well the good thing is that SYSRET reused the LOADALL opcode so at > least this one cannot be screwed on 64-bit :-) It would have helped us > to emulate IRET though. You sure? I'm reasonably confident that Athlon 64 and newer support SYSRET in legacy and long mode. Of course, I think that SYSCALL is totally worthless in legacy mode (SYSCALL_MASK isn't available, so I suspect that the lack of sensible TF handling would be a show-stopper). > >> P.P.S. You know what would be *way* better than allowing IRET to >> fault? Just allow IRET to continue executing the next instruction on >> failure (I'm talking about #GP, #NP, and #SS here, not page faults). >> >> P.P.P.S. Who thought that IRET faults unmasking NMIs made any sense >> whatsoever when NMIs run on an IST stack? Seriously, people? > > A dedicated flag "don't clear NMI yet" would have been nice in EFLAGS > so that the software stack could set it in fault handlers. It would be > one-shot and always cleared by IRET. That would have been very handy. > How about a dedicated "NMI masked" flag in EFLAGS? That would be straightforward and dead simple to handle. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 08/10] posix-cpu-timers: Migrate to use new tick dependency mask model
On Mon, Aug 03, 2015 at 07:39:37PM +0200, Frederic Weisbecker wrote:
> On Mon, Aug 03, 2015 at 07:12:43PM +0200, Peter Zijlstra wrote:
> > On Fri, Jul 31, 2015 at 04:49:55PM +0200, Frederic Weisbecker wrote:
> > > Instead of doing a per signal dependency, I'm going to use a per task
> > > one.
> >
> > Urgh, does this mean you'll keep the horrid tick_nohz_task_switch()
> > thing?
>
> I thought I would drop it, but now that I think about it more, I think I
> need to keep it because if we enqueue a posix timer to a sleeping task
> and that task later wakes up, we must restart the tick, and that is only
> possible with a check on context switch :-(
>
> This current patchset removed the need for that with a global dependency
> for posix timers: as long as there is one enqueued we keep the tick. But
> Chris and Luiz fear that Tilera users have posix timers on housekeepers.
> They also suggested we offline the posix timers. I fear it's going to be
> a high overhead as it means polling on the target task context of execution.
> Unless we move the task itself to housekeepers...
At least do something like the below, that irq save/restore is expensive
and can be trivially avoided.
Also, tick_nohz_full_kick() checks that tick_nohz_full_cpu() thing
again.
---
kernel/sched/core.c | 2 +-
kernel/time/tick-sched.c | 9 +
2 files changed, 2 insertions(+), 9 deletions(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 4d34035bb3ee..57d1af7c0660 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2471,6 +2471,7 @@ static struct rq *finish_task_switch(struct task_struct
*prev)
vtime_task_switch(prev);
finish_arch_switch(prev);
perf_event_task_sched_in(prev, current);
+ tick_nohz_task_switch();
finish_lock_switch(rq, prev);
finish_arch_post_lock_switch();
@@ -2489,7 +2490,6 @@ static struct rq *finish_task_switch(struct task_struct
*prev)
put_task_struct(prev);
}
- tick_nohz_task_switch();
return rq;
}
diff --git a/kernel/time/tick-sched.c b/kernel/time/tick-sched.c
index 3319e16f31e5..9f2225ef230c 100644
--- a/kernel/time/tick-sched.c
+++ b/kernel/time/tick-sched.c
@@ -260,18 +260,11 @@ void tick_nohz_full_kick_all(void)
*/
void __tick_nohz_task_switch(void)
{
- unsigned long flags;
-
- local_irq_save(flags);
-
if (!tick_nohz_full_cpu(smp_processor_id()))
- goto out;
+ return;
if (tick_nohz_tick_stopped() && !can_stop_full_tick())
tick_nohz_full_kick();
-
-out:
- local_irq_restore(flags);
}
/* Parse the boot-time nohz CPU list from the kernel parameters. */
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/7] locking/pvqspinlock: Unconditional PV kick with _Q_SLOW_VAL
On Mon, 2015-08-03 at 20:37 +0200, Peter Zijlstra wrote: > OK, so there's no 'fix'? The patch claims we can loose a wakeup and I > just don't see how that is true. Taking another look, I think you could hit something like this: CPU0 (lock):CPU1 (unlock): pv_wait_head__pv_queued_spin_unlock state> [bogus ->state != halted] smp_store_release(&l->locked, 0); WRITE_ONCE(pn->state, vcpu_halted); pv_wait(&l->locked, _Q_SLOW_VAL); if (->state == vcpu_halted) pv_kick(node->cpu); <-- missing wakeup, never called So basically you can miss a wakeup if node->state load is done while the locking thread is spinning and hasn't gotten a chance to update the state to halted. That would also imply that it occurs right when the threshold limit is about to be reached. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sata_sx4: Check return code from pdc20621_i2c_read()
On Mon, 2015-08-03 at 12:04 -0700, Tomer Barletz wrote: > I see how it makes sense to add a tab to align with the previous line > of code, as it will always look similar in all editors, no matter how > their tab character is set up to be. > However, adding more tabs will just mess up editors that are not set > up with 8-space width tabs. > > Is this a bug in checkpatch.pl, or are we saying everyone should have > their editor set to 8-spaces width tabs? from Documentation/CodingStyle: Chapter 1: Indentation Tabs are 8 characters, and thus indentations are also 8 characters. There are heretic movements that try to make indentations 4 (or even 2!) characters deep, and that is akin to trying to define the value of PI to be 3. Rationale: The whole idea behind indentation is to clearly define where a block of control starts and ends. Especially when you've been looking at your screen for 20 straight hours, you'll find it a lot easier to see how the indentation works if you have large indentations. Now, some people will claim that having 8-character indentations makes the code move too far to the right, and makes it hard to read on a 80-character terminal screen. The answer to that is that if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program. In short, 8-char indents make things easier to read, and have the added benefit of warning you when you're nesting your functions too deep. Heed that warning. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 06/27] misc: eeprom: Export I2C module alias information in missing drivers
Hello Jean,
On 08/03/2015 06:50 PM, Jean Delvare wrote:
> Le Monday 03 August 2015 à 16:07 +0200, Javier Martinez Canillas a
> écrit :
>> Hello Jean,
>>
>> On 08/03/2015 01:05 PM, Jean Delvare wrote:
>>> Hi Javier,
>>>
>>> On Thu, 30 Jul 2015 18:18:31 +0200, Javier Martinez Canillas wrote:
The I2C core always reports the MODALIAS uevent as "i2c:>>> regardless if the driver was matched using the I2C id_table or the
of_match_table. So the driver needs to export the I2C table and this
be built into the module or udev won't have the necessary information
to auto load the correct module when the device is added.
Signed-off-by: Javier Martinez Canillas
---
drivers/misc/eeprom/eeprom.c | 1 +
drivers/misc/eeprom/max6875.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/drivers/misc/eeprom/eeprom.c b/drivers/misc/eeprom/eeprom.c
index b432873def96..4bb54e1c40a7 100644
--- a/drivers/misc/eeprom/eeprom.c
+++ b/drivers/misc/eeprom/eeprom.c
@@ -203,6 +203,7 @@ static const struct i2c_device_id eeprom_id[] = {
{ "eeprom", 0 },
{ }
};
+MODULE_DEVICE_TABLE(i2c, eeprom_id);
static struct i2c_driver eeprom_driver = {
.driver = {
>>>
>>> I seem to recall this one is missing on purpose. The legacy eeprom
>>> driver is deprecated in favor of the at24 driver, so no one should
>>> declare "eeprom" i2c devices and thus the module alias is useless. So I
>>> would leave the legacy eeprom driver alone.
>>>
>>> The only feature the at24 driver is missing is device auto-detection as
>>> far as I know. Maybe it should be added to ease the transition. Or
>>> maybe not, I admit I'm not sure.
>>>
>>
>> It's up to you but since the driver is still in mainline and it has an
>> i2c_device_id table, an "eeprom" I2C device can be registered and matched
>> by the I2C core but if built as a module, it won't be autoloaded.
>
> The eeprom driver instantiates its own devices, so auto-loading is not
> needed. "eeprom" devices should not be found in device trees, that would
> be a bug. Adding an alias is an invitation to introduce such bugs thus
> my request to not add such an alias.
>
OK.
>> I'm not familiar with the at24 platform so feel free to discard the patch
>> if you think that it is not needed and no one is really using this driver
>> (although in that case I think we the driver should just be removed).
>
> I'm really talking about the at24 eeprom driver
> (drivers/misc/eeprom/at24.c) which has nothing to to with the at91
> platform, if that's what you are confusing with.
>
err, I didn't mention at91 but at24 and that was only because you mentioned
it before :-)
> Yes, the long-term plan is to get rid of the legacy eeprom driver. But
> we need a transition path for users. Either the at24 driver should be
> able to instantiate SPD and EDID devices as the eeprom driver does, or
> we need a user-space helper to do that kind of detection, so that
> consumer scripts such as decode-dimms keep working. The former is a
> smaller change, I just hope it won't have any drawback.
>
I'm in fact not familiar with any Atmel SoC. I just noticed that the I2C
core always repots MODALIAS uevents as i2c:name> issue and so
wrote a script to find all the drivers that could be affected by this.
But I'll just blacklist drivers/misc/eeprom/eeprom.c as a false positive.
Best regards,
--
Javier Martinez Canillas
Open Source Group
Samsung Research America
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: ehci-platform: Fix using multiple controllers from OF
When using OF defined controllers the platform data struct is shared
between all devices, so it can't be used for device specific settings.
However it is currently used for the OF properties
needs-reset-on-resume and has-transaction-translator.
To fix this issue move setting hcd->has_tt to the probe and
move pdata->reset_on_resume to the private data.
Signed-off-by: Alban Bedel
---
drivers/usb/host/ehci-platform.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index 2593def..40d029e 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -45,6 +45,7 @@ struct ehci_platform_priv {
struct reset_control *rst;
struct phy **phys;
int num_phys;
+ bool reset_on_resume;
};
static const char hcd_name[] = "ehci-platform";
@@ -56,7 +57,6 @@ static int ehci_platform_reset(struct usb_hcd *hcd)
struct ehci_hcd *ehci = hcd_to_ehci(hcd);
int retval;
- hcd->has_tt = pdata->has_tt;
ehci->has_synopsys_hc_bug = pdata->has_synopsys_hc_bug;
if (pdata->pre_setup) {
@@ -193,11 +193,11 @@ static int ehci_platform_probe(struct platform_device
*dev)
if (of_property_read_bool(dev->dev.of_node,
"needs-reset-on-resume"))
- pdata->reset_on_resume = 1;
+ priv->reset_on_resume = 1;
if (of_property_read_bool(dev->dev.of_node,
"has-transaction-translator"))
- pdata->has_tt = 1;
+ hcd->has_tt = 1;
priv->num_phys = of_count_phandle_with_args(dev->dev.of_node,
"phys", "#phy-cells");
@@ -247,6 +247,10 @@ static int ehci_platform_probe(struct platform_device *dev)
ehci->big_endian_desc = 1;
if (pdata->big_endian_mmio)
ehci->big_endian_mmio = 1;
+ if (pdata->has_tt)
+ hcd->has_tt = 1;
+ if (pdata->reset_on_resume)
+ priv->reset_on_resume = true;
#ifndef CONFIG_USB_EHCI_BIG_ENDIAN_MMIO
if (ehci->big_endian_mmio) {
@@ -359,6 +363,7 @@ static int ehci_platform_resume(struct device *dev)
struct usb_ehci_pdata *pdata = dev_get_platdata(dev);
struct platform_device *pdev =
container_of(dev, struct platform_device, dev);
+ struct ehci_platform_priv *priv = hcd_to_ehci_priv(hcd);
if (pdata->power_on) {
int err = pdata->power_on(pdev);
@@ -366,7 +371,7 @@ static int ehci_platform_resume(struct device *dev)
return err;
}
- ehci_resume(hcd, pdata->reset_on_resume);
+ ehci_resume(hcd, priv->reset_on_resume);
return 0;
}
#endif /* CONFIG_PM_SLEEP */
--
2.0.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/PCI: set MPS before pci_bus_add_devices()
On Tue, Jul 21, 2015 at 05:35:19PM -0400, Murali Karicheri wrote:
> The MPS configuration should be done *before* pci_bus_add_devices().
> After pci_bus_add_devices(), drivers may be bound to devices, and
> the PCI core shouldn't touch device configuration while a driver
> owns the device.
>
> Signed-off-by: Murali Karicheri
> Reported-by: Bjorn Helgaas
> ---
> arch/arm/kernel/bios32.c | 19 +--
> 1 file changed, 5 insertions(+), 14 deletions(-)
>
> diff --git a/arch/arm/kernel/bios32.c b/arch/arm/kernel/bios32.c
> index fc1..17efde7 100644
> --- a/arch/arm/kernel/bios32.c
> +++ b/arch/arm/kernel/bios32.c
> @@ -520,7 +520,8 @@ void pci_common_init_dev(struct device *parent, struct
> hw_pci *hw)
> list_for_each_entry(sys, &head, node) {
> struct pci_bus *bus = sys->bus;
>
> - if (!pci_has_flag(PCI_PROBE_ONLY)) {
> + if (bus && !pci_has_flag(PCI_PROBE_ONLY)) {
Let's get rid of that useless check. bus can't be NULL here.
In the original code (below) if bus was NULL, then we would've already
oopsed before we got here. As we don't oops here, no one is ever
seeing it being NULL, so the test is redundant.
> - list_for_each_entry(sys, &head, node) {
> - struct pci_bus *bus = sys->bus;
> -
> - /* Configure PCI Express settings */
> - if (bus && !pci_has_flag(PCI_PROBE_ONLY)) {
Thanks.
--
FTTC broadband for 0.8mile line: currently at 10.5Mbps down 400kbps up
according to speedtest.net.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] sata_sx4: Check return code from pdc20621_i2c_read()
The variable spd0 might be used uninitialized when pdc20621_i2c_read()
fails.
This also generates a compilation warning with gcc 5.1.
Signed-off-by: Tomer Barletz
---
drivers/ata/sata_sx4.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/ata/sata_sx4.c b/drivers/ata/sata_sx4.c
index 3a18a8a..b482c25 100644
--- a/drivers/ata/sata_sx4.c
+++ b/drivers/ata/sata_sx4.c
@@ -1238,8 +1238,12 @@ static unsigned int pdc20621_prog_dimm_global(struct
ata_host *host)
readl(mmio + PDC_SDRAM_CONTROL);
/* Turn on for ECC */
- pdc20621_i2c_read(host, PDC_DIMM0_SPD_DEV_ADDRESS,
- PDC_DIMM_SPD_TYPE, &spd0);
+ if (!pdc20621_i2c_read(host, PDC_DIMM0_SPD_DEV_ADDRESS,
+ PDC_DIMM_SPD_TYPE, &spd0)) {
+ printk(KERN_ERR "Failed in i2c read: device=%#x, subaddr=%#x\n",
+ PDC_DIMM0_SPD_DEV_ADDRESS, PDC_DIMM_SPD_TYPE);
+ return 1;
+ }
if (spd0 == 0x02) {
data |= (0x01 << 16);
writel(data, mmio + PDC_SDRAM_CONTROL);
@@ -1380,8 +1384,12 @@ static unsigned int pdc20621_dimm_init(struct ata_host
*host)
/* ECC initiliazation. */
- pdc20621_i2c_read(host, PDC_DIMM0_SPD_DEV_ADDRESS,
- PDC_DIMM_SPD_TYPE, &spd0);
+ if (!pdc20621_i2c_read(host, PDC_DIMM0_SPD_DEV_ADDRESS,
+ PDC_DIMM_SPD_TYPE, &spd0)) {
+ printk(KERN_ERR "Failed in i2c read: device=%#x, subaddr=%#x\n",
+ PDC_DIMM0_SPD_DEV_ADDRESS, PDC_DIMM_SPD_TYPE);
+ return 1;
+ }
if (spd0 == 0x02) {
void *buf;
VPRINTK("Start ECC initialization\n");
--
2.4.3
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v2 6/8] jump_label: Add a new static_key interface
On Mon, Aug 03, 2015 at 03:03:59PM -0400, Steven Rostedt wrote: > I wonder if static_branch_set_false(&blah) would be a better name to > understand. What does "disable" / "enable" mean? "make false" / "make true" ? Check a local dictionary. http://lmgtfy.com/?q=enable "2. computing: make (a device or system) operational; active" A value can be true/false, an action that makes true/false is enable/disable. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] pinctrl/mediatek: fix spelling mistake in dev_err error message
On Mon, 2015-08-03 at 00:10 +0100, Colin King wrote:
> From: Colin Ian King
>
> Trivial change, fix spelling mistake 'invaild' -> 'invalid' in
> dev_err message.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/pinctrl/mediatek/pinctrl-mtk-common.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> index ad1ea16..5af5441 100644
> --- a/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> +++ b/drivers/pinctrl/mediatek/pinctrl-mtk-common.c
> @@ -702,7 +702,7 @@ static int mtk_pmx_set_mux(struct pinctrl_dev *pctldev,
>
> ret = mtk_pctrl_is_function_valid(pctl, g->pin, function);
> if (!ret) {
> - dev_err(pctl->dev, "invaild function %d on group %d .\n",
> + dev_err(pctl->dev, "invalid function %d on group %d .\n",
> function, group);
> return -EINVAL;
> }
Hi Colin,
Thank you very much.
Acked-by: Hongzhou Yang
Hongzhou
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] x86/ldt: allow to disable modify_ldt at runtime
On Mon, Aug 03, 2015 at 12:06:12PM -0700, Andy Lutomirski wrote: > On Mon, Aug 3, 2015 at 12:01 PM, Willy Tarreau wrote: (...) > > I feel like it's probably part of a larger project then. Do you think > > we should step back and only support 0/1 for now ? I also have the > > patch available. > > Sounds good to me. OK I'll send the other one instead once I unpack my PC. > > Well the good thing is that SYSRET reused the LOADALL opcode so at > > least this one cannot be screwed on 64-bit :-) It would have helped us > > to emulate IRET though. > > You sure? I'm reasonably confident that Athlon 64 and newer support > SYSRET in legacy and long mode. Of course, I think that SYSCALL is > totally worthless in legacy mode (SYSCALL_MASK isn't available, so I > suspect that the lack of sensible TF handling would be a > show-stopper). I meant loadall cannot be screwed since it was replaced. > >> P.P.S. You know what would be *way* better than allowing IRET to > >> fault? Just allow IRET to continue executing the next instruction on > >> failure (I'm talking about #GP, #NP, and #SS here, not page faults). > >> > >> P.P.P.S. Who thought that IRET faults unmasking NMIs made any sense > >> whatsoever when NMIs run on an IST stack? Seriously, people? > > > > A dedicated flag "don't clear NMI yet" would have been nice in EFLAGS > > so that the software stack could set it in fault handlers. It would be > > one-shot and always cleared by IRET. That would have been very handy. > > > > How about a dedicated "NMI masked" flag in EFLAGS? That would be > straightforward and dead simple to handle. Sounds like an oxymoron. But such a flag should be atomically manipulated so that you don't re-arm queued NMIs before calling iret. With two flags, a read-only one for "NMI masked" and a modifiable one "keep NMI masked", you can provide an atomic behaviour where you have this latch executed on iret : NMI_MASKED &= KEEP_NMI_MASKED; KEEP_NMI_MASKED = 0; But anyway we're discussing in the void, this CPU doesn't exist so unless intel/AMD designers want to improve their design (and start by talking together to reach the exact same behavior), we'll never see anything like this :-/ Willy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] sata_sx4: Check return code from pdc20621_i2c_read()
On 08/03/2015 10:04 PM, Tomer Barletz wrote: Please don't top-post. I see how it makes sense to add a tab to align with the previous line of code, as it will always look similar in all editors, no matter how their tab character is set up to be. However, adding more tabs will just mess up editors that are not set up with 8-space width tabs. Is this a bug in checkpatch.pl, or are we saying everyone should have their editor set to 8-spaces width tabs? The latter. :-) MBR, Sergei -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4/4] drivers:pci:hv: New paravirtual PCI front-end for Hyper-V VMs
> -Original Message-
> From: Thomas Gleixner [mailto:t...@linutronix.de]
> Sent: Sunday, August 2, 2015 1:47 AM
> To: Jake Oshins
> Cc: gre...@linuxfoundation.org; KY Srinivasan ; LKML
> ; de...@linuxdriverproject.org;
> o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com; linux-
> p...@vger.kernel.org; bhelg...@google.com; x...@kernel.org; Jiang Liu
>
> Subject: Re: [PATCH 4/4] drivers:pci:hv: New paravirtual PCI front-end for
> Hyper-V VMs
>
> > +static int hv_msi_domain_ops_prepare(struct irq_domain *domain,
> > +struct device *dev, int nvec,
> > +msi_alloc_info_t *arg)
> > +{
> > + struct pci_dev *pdev = to_pci_dev(dev);
> > + struct msi_desc *desc = first_pci_msi_entry(pdev);
> > +
> > + memset(arg, 0, sizeof(*arg));
> > + arg->msi_dev = pdev;
> > + if (desc->msi_attrib.is_msix) {
> > + arg->type = X86_IRQ_ALLOC_TYPE_MSIX;
> > + } else {
> > + arg->type = X86_IRQ_ALLOC_TYPE_MSI;
> > + arg->flags |= X86_IRQ_ALLOC_CONTIGUOUS_VECTORS;
> > + }
> > +
> > + return 0;
> > +}
>
> Pretty much a copy of the x86 code, right?
>
> I wonder whether this MSI infrastructure code would be better
> seperated out and moved to arch/x86/hyperv/msi.c or
> arch/x86/kernel/apic/hvmsi.c. It's small enough to be built in. So all
> you'd need to export is hv_pcie_init_irq_domain and
> hv_pcie_free_irq_domain.
>
> Thanks,
>
> tglx
Thanks for your review. I'll respond to all of your feedback and resend.
I do have a question about your last point, though. If I build this into the
kernel, it will need to depend on sending and receiving messages through the
hv_vmbus driver, which isn't built in. It seemed like the indirection and glue
code necessary to make that work would be almost as big as this entire
implementation (which admittedly isn't very big.) If you prefer that, I'll do
it. But it would make more sense to me to refactor this a bit more so that
functions like the one above are exported rather than putting
hv_pcie_init_irq_domain and hv_pcie_free_irq_domain into the kernel itself.
Would that work?
Thanks,
Jake Oshins
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
You have been approved by Kushi Aole-UK the sum of 850000.00 GBP
You have been approved by Kushi Aole-UK the sum of 85.00 GBP with draw number: 22330KHO577345 and Serial number 675345. Reply for more details Contact us via claimsdpt2...@outlook.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] usb: ehci-platform: Fix using multiple controllers from OF
On 08/03/2015 10:12 PM, Alban Bedel wrote:
When using OF defined controllers the platform data struct is shared
between all devices, so it can't be used for device specific settings.
However it is currently used for the OF properties
needs-reset-on-resume and has-transaction-translator.
To fix this issue move setting hcd->has_tt to the probe and
move pdata->reset_on_resume to the private data.
Signed-off-by: Alban Bedel
---
drivers/usb/host/ehci-platform.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/usb/host/ehci-platform.c b/drivers/usb/host/ehci-platform.c
index 2593def..40d029e 100644
--- a/drivers/usb/host/ehci-platform.c
+++ b/drivers/usb/host/ehci-platform.c
@@ -45,6 +45,7 @@ struct ehci_platform_priv {
struct reset_control *rst;
struct phy **phys;
int num_phys;
+ bool reset_on_resume;
};
static const char hcd_name[] = "ehci-platform";
[...]
@@ -193,11 +193,11 @@ static int ehci_platform_probe(struct platform_device
*dev)
if (of_property_read_bool(dev->dev.of_node,
"needs-reset-on-resume"))
- pdata->reset_on_resume = 1;
+ priv->reset_on_resume = 1;
'true' since the typi is 'bool'.
[...]
MBR, Sergei
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] arm64: Enable Marvell Berlin SoC family in defconfig
From: Jisheng Zhang Enable Marvell Berlin SoC family in arm64 defconfig. Signed-off-by: Jisheng Zhang Signed-off-by: Sebastian Hesselbarth --- Also discussed with Olof on IRC, this is the defconfig changes singled out from Jisheng's original patch. Sebastian --- arch/arm64/configs/defconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig index f38c94f1d898..9e8978c35772 100644 --- a/arch/arm64/configs/defconfig +++ b/arch/arm64/configs/defconfig @@ -31,6 +31,7 @@ CONFIG_MODULES=y CONFIG_MODULE_UNLOAD=y # CONFIG_BLK_DEV_BSG is not set # CONFIG_IOSCHED_DEADLINE is not set +CONFIG_ARCH_BERLIN=y CONFIG_ARCH_EXYNOS7=y CONFIG_ARCH_FSL_LS2085A=y CONFIG_ARCH_HISI=y -- 2.1.0 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] arm64: Enable Marvell Berlin SoC family in Kconfig
From: Jisheng Zhang
This patch introduces ARCH_BERLIN to enable Marvell Berlin SoC family in
Kconfig.
Signed-off-by: Jisheng Zhang
Signed-off-by: Sebastian Hesselbarth
---
As discussed with Olof on IRC, this is Jisheng's Kconfig patch for
ARM64 Berlin. Olof agreed to rework this to finally land in
Kconfig.platforms, i.e. after
eed6b3eb20b9 ("arm64: Split out platform options to separate Kconfig")
Sebastian
---
arch/arm64/Kconfig | 6 ++
1 file changed, 6 insertions(+)
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 0f6edb14b7e4..d5c615312d87 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -162,6 +162,12 @@ source "kernel/Kconfig.freezer"
menu "Platform selection"
+config ARCH_BERLIN
+ bool "Marvell Berlin SoC Family"
+ select DW_APB_ICTL
+ help
+ This enables support for Marvell Berlin SoC Family
+
config ARCH_EXYNOS
bool
help
--
2.1.0
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] ARM: berlin: Initial Marvell Berlin ARM64 support
Hi Arnd, Kevin, Olof, this is initial Marvell Berlin4CT ARM64 support for v4.3. It contains minimum SoC dtsi and basic dts for the development board. The patches have been posted by Marvell's Jisheng Zhang a while ago on the lists. Please pull. The following changes since commit d770e558e21961ad6cfdf0ff7df0eb5d7d4f0754: Linux 4.2-rc1 (2015-07-05 11:01:52 -0700) are available in the git repository at: git://git.infradead.org/users/hesselba/linux-berlin.git tags/berlin64-for-v4.3-1 for you to fetch changes up to d93ac74ad150c89f2d0a3b90754cbccdc6ab102c: arm64: dts: Add dts files for Marvell Berlin4CT SoC (2015-08-03 20:45:54 +0200) Initial support for Marvell Berlin4CT ARM64 SoC Jisheng Zhang (1): arm64: dts: Add dts files for Marvell Berlin4CT SoC arch/arm64/boot/dts/Makefile | 1 + arch/arm64/boot/dts/marvell/Makefile | 5 + arch/arm64/boot/dts/marvell/berlin4ct-dmp.dts | 66 +++ arch/arm64/boot/dts/marvell/berlin4ct.dtsi| 164 ++ 4 files changed, 236 insertions(+) create mode 100644 arch/arm64/boot/dts/marvell/Makefile create mode 100644 arch/arm64/boot/dts/marvell/berlin4ct-dmp.dts create mode 100644 arch/arm64/boot/dts/marvell/berlin4ct.dtsi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RT] oops in 4.1.3-rt3
Sebastian, Below is a traceback I hit while running 4.1.3-rt3 on my Lenovo T530. I was doing my normal, play music, copy files over the lan, do compiles, do email, etc., so I I can't really point you at a reproducer. The graphics system stayed up somewhat but the actual trace I hit scrolled off. This was extracted from the syslog with 'journalctl'. If I encounter it again, I'll see if I can force a kdump. Clark Jul 28 20:29:07 sluggy systemd-udevd[831]: worker [13548] did not accept message -111 (Connection refused), kill it Jul 28 20:29:07 sluggy kernel: general protection fault: [#1] PREEMPT SMP Jul 28 20:29:07 sluggy kernel: Modules linked in: hidp cmac rfcomm fuse xt_CHECKSUM ipt_MASQUERADE nf_nat_masquerade_ipv4 tun Jul 28 20:29:07 sluggy kernel: snd_hda_codec snd_usbmidi_lib snd_rawmidi snd_hda_core videodev iwlwifi btusb snd_hwdep btbcm Jul 28 20:29:07 sluggy kernel: CPU: 4 PID: 13548 Comm: systemd-udevd Not tainted 4.1.3-rt3 #3 Jul 28 20:29:07 sluggy kernel: Hardware name: LENOVO 24293E8/24293E8, BIOS G4ET94WW (2.54 ) 05/23/2013 Jul 28 20:29:07 sluggy kernel: task: 8802ffb0aa40 ti: 88007871c000 task.ti: 88007871c000 Jul 28 20:29:07 sluggy kernel: RIP: 0010:[] [] sock_prot_inuse_add+0x2d/0x50 Jul 28 20:29:07 sluggy kernel: RSP: 0018:88007871fb68 EFLAGS: 00010296 Jul 28 20:29:07 sluggy kernel: RAX: 0004 RBX: RCX: Jul 28 20:29:07 sluggy kernel: RDX: 81810428 RSI: 81ae0d87 RDI: 81a7f8c0 Jul 28 20:29:07 sluggy kernel: RBP: 88007871fb88 R08: 0001 R09: Jul 28 20:29:07 sluggy kernel: R10: 880088ebb390 R11: 0001 R12: 20303d6469752031 Jul 28 20:29:08 sluggy kernel: R13: 81cea7a0 R14: R15: 0018 Jul 28 20:29:08 sluggy kernel: FS: () GS:88041e30() knlGS: Jul 28 20:29:08 sluggy kernel: CS: 0010 DS: ES: CR0: 80050033 Jul 28 20:29:08 sluggy kernel: CR2: 55da9fd30060 CR3: 01c0e000 CR4: 001407e0 Jul 28 20:29:08 sluggy kernel: Stack: Jul 28 20:29:08 sluggy kernel: 88031abe42d8 88031abe42d8 88031abe4000 88031abe45d8 Jul 28 20:29:08 sluggy kernel: 88007871fbf8 816db0b6 880407f06400 88040afbd1d0 Jul 28 20:29:08 sluggy kernel: 0001 20303d6469752031 000fef45 fa86c4d0 Jul 28 20:29:08 sluggy kernel: Call Trace: Jul 28 20:29:08 sluggy kernel: [] netlink_release+0x316/0x540 Jul 28 20:29:08 sluggy kernel: [] sock_release+0x1f/0x90 Jul 28 20:29:08 sluggy kernel: [] sock_close+0x12/0x20 Jul 28 20:29:08 sluggy kernel: [] __fput+0xcb/0x1e0 Jul 28 20:29:08 sluggy kernel: [] fput+0xe/0x10 Jul 28 20:29:08 sluggy kernel: [] task_work_run+0xd4/0xf0 Jul 28 20:29:08 sluggy kernel: [] do_exit+0x3f7/0xbe0 Jul 28 20:29:08 sluggy kernel: [] do_group_exit+0x50/0xd0 Jul 28 20:29:08 sluggy kernel: [] get_signal+0x29b/0x6e0 Jul 28 20:29:08 sluggy kernel: [] do_signal+0x37/0x7c0 Jul 28 20:29:08 sluggy kernel: [] ? ep_poll+0x3b3/0x460 Jul 28 20:29:08 sluggy kernel: [] ? __audit_syscall_exit+0x1f6/0x290 Jul 28 20:29:08 sluggy kernel: [] do_notify_resume+0xa8/0x100 Jul 28 20:29:08 sluggy kernel: [] int_signal+0x12/0x17 Jul 28 20:29:08 sluggy kernel: Code: 44 00 00 55 48 89 e5 41 55 41 54 53 49 89 fc 49 89 f5 48 c7 c7 87 0d ae 81 89 d3 48 83 ec Jul 28 20:29:08 sluggy kernel: RIP [] sock_prot_inuse_add+0x2d/0x50 Jul 28 20:29:08 sluggy kernel: RSP Jul 28 20:29:08 sluggy kernel: ---[ end trace 0002 ]--- -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: [Ksummit-discuss] Kernel Summit 2015: Call for Proposals
On Mon, Aug 03, 2015 at 02:52:58PM -0400, Josh Boyer wrote: > On Mon, Aug 3, 2015 at 2:44 PM, Theodore Ts'o wrote: > > The Kernel Summit call for proposals/topics was sent out a month ago: > > > > http://lists.linuxfoundation.org/pipermail/ksummit-discuss/2015-July/001242.html > > > > In that call, I asked that people send nominations (including self > > nominations) and topic suggestions by the end of July since the > > program committee would start considering people who should be issued > > invites. > > > > The mechnically generated list of people to be considered, plus people > > that have been added due to nominations, being called out as useful > > participants for various discussions, etc., can be found here: > > > > https://goo.gl/m62WpI > > > > As favor to me, if you could take a look at the spreadsheet and let me > > know if there are any e-mail addresses which have are incorrect or > > shoud be updated, please let me know. Also, if there are any last > > minute nominations that you'd like to suggest for the list, please let > > me know by the end of day on Wednesday, August 5th. > > You have me as Tagged for Live Patching. While that is indeed > interesting to me, I don't think you have the correct Josh there. It > should be Josh Poimboeuf . Thanks Josh. For the Live Patching topic I would also nominate the other maintainers: Jiri Kosina (already on the list) Vojtech Pavlik Seth Jennings -- 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: [PATCH -v2 6/8] jump_label: Add a new static_key interface
On Mon, 3 Aug 2015 21:18:16 +0200 Peter Zijlstra wrote: > On Mon, Aug 03, 2015 at 03:03:59PM -0400, Steven Rostedt wrote: > > > I wonder if static_branch_set_false(&blah) would be a better name to > > understand. What does "disable" / "enable" mean? > > "make false" / "make true" ? Check a local dictionary. > > http://lmgtfy.com/?q=enable I know the definition on enable :-p > > "2. computing: make (a device or system) operational; active" > > A value can be true/false, an action that makes true/false is > enable/disable. enable is more "activate" and disable is more "deactivate" not "make true" and "make false". It's subtle, but there is a difference. Try switching it around in other contexts. One could "disable networking" but saying "make networking false" doesn't make sense. Technically, one can think: "activate the branch", but we are activating not the branch, but the jump label itself. It's not as clear as setting it to "true" or "false". What the static_branch does is already confusing enough, we should try to use the terminology that is as clear as possible. "set_true" is more understandable than "enable" when one can question, what exactly are we "enabling"? -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 11/18] perf script: Switch from perf.data's kallsyms to perf's symbol resolver
Em Mon, Aug 03, 2015 at 04:00:09PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Mon, Aug 03, 2015 at 07:41:13PM +0200, Jiri Olsa escreveu:
> > Missing separate debuginfos, use: dnf debuginfo-install
> > glibc-2.21-7.fc22.x86_64
> > [Thread debugging using libthread_db enabled]
> > Using host libthread_db library "/lib64/libthread_db.so.1".
> > Detaching after fork from child process 11230.
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x004eeace in pevent_set_function_resolver (pevent=0x0,
> > func=0x4a3197 , priv=0x18e1f48) at
> > event-parse.c:464
> > 464 free(pevent->func_resolver);
> > Missing separate debuginfos, use: dnf debuginfo-install
> > audit-libs-2.4.3-1.fc22.x86_64 bzip2-libs-1.0.6-14.fc22.x86_64
> > elfutils-libelf-0.163-1.fc22.x86_64 elfutils-libs-0.163-1.fc22.x86_64
> > libunwind-1.1-10.fc22.x86_64 nss-softokn-freebl-3.19.2-1.0.fc22.x86_64
> > numactl-libs-2.0.10-2.fc22.x86_64 perl-libs-5.20.2-326.fc22.x86_64
> > python-libs-2.7.10-4.fc22.x86_64 slang-2.3.0-2.fc22.x86_64
> > xz-libs-5.2.0-2.fc22.x86_64 zlib-1.2.8-7.fc22.x86_64
> > (gdb)
>
> > I think 'session->tevent.pevent' gets initialized only for tracepoint,
> > right?
>
> Reproduced, checking.
Yeah, I think we only need to set libtraceevent's function resolver if
there are tracepoints, i.e. if libtraceevent is being used. Following
patch should be enough, right?
- Arnaldo
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index bd31380122f9..7912feb9a024 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -1861,7 +1861,8 @@ int cmd_script(int argc, const char **argv, const char
*prefix __maybe_unused)
else
symbol_conf.use_callchain = false;
- if (pevent_set_function_resolver(session->tevent.pevent,
+ if (session->tevent.pevent &&
+ pevent_set_function_resolver(session->tevent.pevent,
machine__resolve_kernel_addr,
&session->machines.host) < 0) {
pr_err("%s: failed to set libtraceevent function resolver\n",
__func__);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] thermal/cpu_cooling: remove local cooling state variable
On Mon, 3 Aug 2015 08:43:25 +0530 Viresh Kumar wrote: > On 01-08-15, 17:04, Viresh Kumar wrote: > > On 31-07-15, 08:30, Radivoje Jovanovic wrote: > > > > I agree with you that this patch is trivial for the current > > > implementation since the notifier, as it is currently, will > > > enforce cpu_cooling policy change at every CPUFREQ_ADJUST which > > > would cause problems in our current implementation. In our > > > implementation there is a cpufreq driver that will also change > > > policies during CPUFREQ_ADJUST, once the request comes from the > > > underlying FW so there would be a fight who gets there first > > > since cpu_cooling will change the policy in CPUFREQ_ADJUST > > > notifier_chain and the driver would do the same thing. > > Okay, I had a detailed look this morning. cpufreq-notifier is designed > this way that policy->max can be updated by drivers.. So, that's fine. > > Now coming to your problem. So, there are two users: fw and thermal, > which can affect policy->max. Now, both of them need to respect the > limits set by others and only decrease policy->max from the notifier > if it doesn't suit them. > > I think it should work pretty well, unless you know you have triggered > a corner case somewhere, that I am not able to imagine. > > Please let me know in case I am wrong. > I will port the upstream driver to our platfrom, test for all corner cases and update this thread once I have the data Thank you for all the help -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] serial: 8250: omap: restore registers on shutdown
On 08/03/2015 12:54 PM, Sebastian Andrzej Siewior wrote:
> On 08/03/2015 06:34 PM, Peter Hurley wrote:
>> Hi Sebastian,
>
> Hi Peter,
>
>>> struct old_serial_port {
>>> diff --git a/drivers/tty/serial/8250/8250_omap.c
>>> b/drivers/tty/serial/8250/8250_omap.c
>>> index d9a37191a1ae..12249125a218 100644
>>> --- a/drivers/tty/serial/8250/8250_omap.c
>>> +++ b/drivers/tty/serial/8250/8250_omap.c
>>> @@ -100,9 +100,9 @@ struct omap8250_priv {
>>> u8 wer;
>>> u8 xon;
>>> u8 xoff;
>>> - u8 delayed_restore;
>>> u16 quot;
>>>
>>> + wait_queue_head_t termios_wait;
>>> bool is_suspending;
>>> int wakeirq;
>>> int wakeups_enabled;
>>> @@ -256,18 +256,6 @@ static void omap8250_update_mdr1(struct uart_8250_port
>>> *up,
>>> static void omap8250_restore_regs(struct uart_8250_port *up)
>>> {
>>> struct omap8250_priv *priv = up->port.private_data;
>>> - struct uart_8250_dma*dma = up->dma;
>>> -
>>> - if (dma && dma->tx_running) {
>>> - /*
>>> -* TCSANOW requests the change to occur immediately however if
>>> -* we have a TX-DMA operation in progress then it has been
>>> -* observed that it might stall and never complete. Therefore we
>>> -* delay DMA completes to prevent this hang from happen.
>>> -*/
>>> - priv->delayed_restore = 1;
>>> - return;
>>> - }
>>>
>>> serial_out(up, UART_LCR, UART_LCR_CONF_MODE_B);
>>> serial_out(up, UART_EFR, UART_EFR_ECB);
>>> @@ -309,6 +297,7 @@ static void omap8250_restore_regs(struct uart_8250_port
>>> *up)
>>> up->port.ops->set_mctrl(&up->port, up->port.mctrl);
>>> }
>>>
>>> +static void omap_8250_dma_tx_complete(void *param);
>>> /*
>>> * OMAP can use "CLK / (16 or 13) / div" for baud rate. And then we have
>>> have
>>> * some differences in how we want to handle flow control.
>>> @@ -322,6 +311,7 @@ static void omap_8250_set_termios(struct uart_port
>>> *port,
>>> struct omap8250_priv *priv = up->port.private_data;
>>> unsigned char cval = 0;
>>> unsigned int baud;
>>> + unsigned int complete_dma = 0;
>>>
>>> switch (termios->c_cflag & CSIZE) {
>>> case CS5:
>>> @@ -473,6 +463,25 @@ static void omap_8250_set_termios(struct uart_port
>>> *port,
>>> if (termios->c_iflag & IXANY)
>>> up->mcr |= UART_MCR_XONANY;
>>> }
>>> +
>>> + if (up->dma && up->dma->tx_running) {
>>> + struct uart_8250_dma*dma = up->dma;
>>> +
>>> + /*
>>> +* TCSANOW requests the change to occur immediately however if
>>> +* we have a TX-DMA operation in progress then it has been
>>> +* observed that it might stall and never complete. Therefore we
>>> +* wait until DMA completes to prevent this hang from happen.
>>> +*/
>>> +
>>> + dma->tx_running = 2;
>>> +
>>> + spin_unlock_irq(&up->port.lock);
>>> + wait_event(priv->termios_wait,
>>> + dma->tx_running == 3);
>>
>> Doesn't the dmaengine api offer a race-free way to wait for pending tx dma
>> to complete?
>
> Not that I know of. You still need to ensure that once that DMA
> completed, nobody triggers another TX transfer before you do what you
> planned. This is ensures by the tx_running != 0 and the spin lock.
>
>> Maybe we could wrap that in the 8250 dma api?
>
> You mean a function in 8250-dma API which does what I did just here
> with the wait_event() and the wake_up in the callback? That way I could
> move the termios_wait into the dma struct instead of keeping in the
> omap specific part. I am also not sure if OMAP is the only one that may
> hang here or the other people just didn't notice it yet.
Exactly; and we need to fix DMA wrt x_char anyway.
Going back to the dmaengine api, I think something like this might work
(as a first approximation):
dma_sync_wait(dma->txchan, dma->tx_cookie);
dmaengine_pause(dma->txchan);
/* remainder of set_termios */
dmaengine_resume(dma->txchan);
We could require 8250 core dma to support pause/resume.
>>> + spin_lock_irq(&up->port.lock);
>>> + complete_dma = 1;
>>> + }
>>> omap8250_restore_regs(up);
>>>
>>> spin_unlock_irq(&up->port.lock);
>>> @@ -488,6 +497,8 @@ static void omap_8250_set_termios(struct uart_port
>>> *port,
>>> /* Don't rewrite B0 */
>>> if (tty_termios_baud_rate(termios))
>>> tty_termios_encode_baud_rate(termios, baud, baud);
>>> + if (complete_dma)
>>> + omap_8250_dma_tx_complete(up);
>>> }
>>>
>>> /* same as 8250 except that we may have extra flow bits set in EFR */
>>> @@ -869,17 +880,18 @@ static void omap_8250_dma_tx_complete(void *param)
>>>
>>> spin_lock_irqsave(&p->port.lock, flags);
>>>
>>> + if (dma->tx_running == 2) {
>>> + dma->tx_running = 3;
>>> + wake_up(&priv->termios_wait);
>>> + goto o
Re: [RFC PATCH 2/2] mtd: nand: use nand_check_erased_ecc_chunk in default ECC read functions
Am 03.08.2015 um 15:39 schrieb Andrea Scian: >>> I think I can find some time to do some performance tests on real hardware. >>> Can you please help me in finding: >>> - which benchmark to use (currently I'm using bonnie++ on UBIFS, maybe I >>> can you just mtd_speedtest) >>> - where to implement those read >> >> I think the test should be done at the UBI layer if we want to check >> the real impact of the additional read sequence, but given the answer I >> gave to your other question I'm not sure this is relevant anymore ;-). I'm not sure whether introducing a read-before-write check is the best solution. At least we need hard numbers for slow/old SLC NANDs too. We has such checks already and got rid of them. commit 657f28f8811c92724db10d18bbbec70d540147d6 Author: Huang Shijie Date: Tue Aug 14 22:38:45 2012 -0400 mtd: kill MTD_NAND_VERIFY_WRITE Although the goal of 657f28f8 was something else. In general I don't think putting much MTD/ECC logic into UBI is the way to go. UBI is a layer above MTD and MTD should do as much as possible wrt. ECC. >>> >>> For the second point I think we can implement it a UBI or MTD level. >>> I think the former will allow us to easily schedule scrubbing and choose >>> another block to issue the write to. However I don't really know how to >>> implement it (I don't really know so much about the UBI code). Implementing this is not much work. I've done such hacks for various customers to hunt down hardware issues. >> I didn't check before suggesting that, but it seems that the UBI layer >> is already doing this check for you [1], so if you're using UBI/UBIFS >> you shouldn't worry about bitflips in erased pages: if there is any, >> and their presence impact the write result, they should be detected. >> AFAICT, the only thing that is not checked is whether the number of >> bitflips after a write exceed the bitflips threshold or not, and I >> guess this can be added. > > IIUC this is a runtime debug check > > if (!ubi_dbg_chk_io(ubi)) > > > And thus is disabled by default. That's correct. Thanks, //richard -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 5/5] arm: qcom: dts: Enable NAND node on IPQ8064 AP148 platform
On Mon, Aug 03, 2015 at 10:38:18AM +0530, Archit Taneja wrote:
> Enable the NAND controller node on the AP148 platform. Provide pinmux
> information.
>
> Cc: devicet...@vger.kernel.org
>
> Signed-off-by: Archit Taneja
> ---
> arch/arm/boot/dts/qcom-ipq8064-ap148.dts | 36
>
> 1 file changed, 36 insertions(+)
>
> diff --git a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
> b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
> index 7f9ea50..2e88eff 100644
> --- a/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
> +++ b/arch/arm/boot/dts/qcom-ipq8064-ap148.dts
> @@ -30,6 +30,28 @@
> bias-none;
> };
> };
> + nand_pins: nand_pins {
> + mux {
> + pins = "gpio34", "gpio35", "gpio36",
> +"gpio37", "gpio38", "gpio39",
> +"gpio40", "gpio41", "gpio42",
> +"gpio43", "gpio44", "gpio45",
> +"gpio46", "gpio47";
> + function = "nand";
> + drive-strength = <10>;
> + bias-disable;
> + };
> + pullups {
> + pins = "gpio39";
> + bias-pull-up;
> + };
> + hold {
> + pins = "gpio40", "gpio41", "gpio42",
> +"gpio43", "gpio44", "gpio45",
> +"gpio46", "gpio47";
> + bias-bus-hold;
Maybe split out the bias-disable into a separate set and remove that property
from the mux.
> + };
> + };
> };
>
> gsbi@1630 {
> @@ -93,5 +115,19 @@
> sata@2900 {
> status = "ok";
> };
> +
> + nand@1ac0 {
> + status = "ok";
> +
> + pinctrl-0 = <&nand_pins>;
> + pinctrl-names = "default";
> +
> + nand-ecc-strength = <4>;
> + nand-bus-width = <8>;
> + };
> };
> };
> +
> +&adm_dma {
> + status = "ok";
> +};
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
--
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: ehci-platform: Fix using multiple controllers from OF
On Mon, 3 Aug 2015, Alban Bedel wrote: > When using OF defined controllers the platform data struct is shared > between all devices, so it can't be used for device specific settings. > However it is currently used for the OF properties > needs-reset-on-resume and has-transaction-translator. > > To fix this issue move setting hcd->has_tt to the probe and > move pdata->reset_on_resume to the private data. > > Signed-off-by: Alban Bedel That's a subtle problem and a good call on your part. Acked-by: Alan Stern Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [4.2 fix] x86, mpx: do not set ->vm_ops on mpx VMAs
On Mon, Aug 03, 2015 at 09:19:14AM -0700, Greg KH wrote: > On Mon, Aug 03, 2015 at 01:34:28PM +0300, Kirill A. Shutemov wrote: > > Greg KH wrote: > > > On Mon, Jul 20, 2015 at 02:29:58PM -0700, Dave Hansen wrote: > > > > > > > > (sorry for the spam, I screwed up the stable@ address). > > > > > > > > BTW, thanks to Kirill for doing this patch! He posted it to LKML > > > > but we need to ensure it is picked up for 4.2 and any -stable > > > > kernels where this commit is applied: > > > > > > > > 6b7339f4: mm: avoid setting up anonymous pages into file mapping > > > > > > > > That broke MPX support because MPX sets a vma->vm_ops on an > > > > anonymous VMA. We need this patch to make it work again, > > > > basically removing MPX's use of ->vm_ops. Kirill made me aware > > > > of this long ago, but I didn't double-check that his fix got > > > > submitted and merged. > > > > > > > > I (Dave) fixed up a minor merge conflict and added the > > > > try_unmap_single_bt() use of is_mpx_vma() (which were added > > > > post-4.1). > > > > > > > > Note for -stable: The first hunk may not apply cleanly because of > > > > other activity in arch/x86/mm/mmap.c, but should be trivial to > > > > apply by hand. Hunk #5 on mpx.c is only present on 4.2-rc kernels. > > > > > > Can someone send a version that is known to apply, you don't want to > > > rely on me to get it right :) > > > > Here it is. > > > > MPX support was introduced in 3.19, so it only need to be applied to > > 4.1-stable. > > Thanks, now applied. Just to make clear: we don't need MPX patch for older stables, but we *do* need 6b7339f4 (mm: avoid setting up anonymous pages into file mapping) to be ported into all stables. -- Kirill A. Shutemov -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 4/4] drivers:pci:hv: New paravirtual PCI front-end for Hyper-V VMs
On Mon, 3 Aug 2015, Jake Oshins wrote: > I do have a question about your last point, though. If I build this > into the kernel, it will need to depend on sending and receiving > messages through the hv_vmbus driver, which isn't built in. It Fair enough. I missed that detail. > seemed like the indirection and glue code necessary to make that > work would be almost as big as this entire implementation (which > admittedly isn't very big.) If you prefer that, I'll do it. But it > would make more sense to me to refactor this a bit more so that > functions like the one above are exported rather than putting > hv_pcie_init_irq_domain and hv_pcie_free_irq_domain into the kernel > itself. Would that work? Yes. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event
On 7/31/15 3:18 AM, Wangnan (F) wrote:
However with the newest llvm + clang the DWARF info is still incorrect:
$ objdump --dwarf=info ./out.o
...
<1><3f>: Abbrev Number: 3 (DW_TAG_structure_type)
<40> DW_AT_name: (indirect string, offset: 0x0): clang
version 3.8.0 (http://llvm.org/git/clang.git
f0fcd3432cbed83500df70c18f275d8affb89e5e) (http://llvm.org/git/llvm.git
c8ccd78d31d4949fa1c14e954ccb06253e18cf37)
<44> DW_AT_byte_size : 8
<45> DW_AT_decl_file : 1
<46> DW_AT_decl_line : 4
<2><47>: Abbrev Number: 4 (DW_TAG_member)
<48> DW_AT_name: (indirect string, offset: 0x0): clang
version 3.8.0 (http://llvm.org/git/clang.git
f0fcd3432cbed83500df70c18f275d8affb89e5e) (http://llvm.org/git/llvm.git
c8ccd78d31d4949fa1c14e954ccb06253e18cf37)
<4c> DW_AT_type: <0x60>
<50> DW_AT_decl_file : 1
<51> DW_AT_decl_line : 5
<52> DW_AT_data_member_location: 0
<2><53>: Abbrev Number: 4 (DW_TAG_member)
<54> DW_AT_name: (indirect string, offset: 0x0): clang
version 3.8.0 (http://llvm.org/git/clang.git
f0fcd3432cbed83500df70c18f275d8affb89e5e) (http://llvm.org/git/llvm.git
c8ccd78d31d4949fa1c14e954ccb06253e18cf37)
<58> DW_AT_type: <0x60>
<5c> DW_AT_decl_file : 1
<5d> DW_AT_decl_line : 6
<5e> DW_AT_data_member_location: 4
...
The DW_AT_name is missing.
didn't have time to look at it.
from your llvm patches looks like you've got quite experienced
with it already :)
I'll post 2 LLVM patches by replying this mail. Please have a look and
help me
send them to LLVM if you think my code is correct.
patch 1:
I don't quite understand the purpose of builtin_dwarf_cfa
returning R11. It's a special register seen inside llvm codegen
only. It doesn't have kernel meaning.
patch 2:
do we really need to hack clang?
Can you just define a function that aliases to intrinsic,
like we do for ld_abs/ld_ind ?
void bpf_store_half(void *skb, u64 off, u64 val) asm("llvm.bpf.store.half");
then no extra patches necessary.
struct my_str {
int x;
int y;
};
struct my_str __str_my_str;
struct my_str2 {
int x;
int y;
int z;
};
struct my_str2 __str_my_str2;
test_func(__builtin_bpf_typeid(&__str_my_str));
test_func(__builtin_bpf_typeid(&__str_my_str2));
mov r1, 1
call4660
mov r1, 2
call4660
this part looks good. I think it's usable.
> 1. llvm.eh_typeid_for can be used on global variables only. So for each
> output
> structure we have to define a global varable.
why? I think it should work with local pointers as well.
> 2. We still need to find a way to connect the fetchd typeid with DWARF
> info.
> Inserting that ID into DWARF may workable?
hmm, that id should be the same id we're seeing in dwarf, right?
I think it's used in exception handling which is reusing some of
the dwarf stuff for this, so the must be a way to connect that id
to actual type info. Though last time I looked at EH was
during g++ hacking days. No idea how llvm does it exactly, but
I'm assuming the logic for rtti should be similar.
btw, for any deep llvm stuff you may need to move the thread to llvmdev.
May be folks there will have other ideas.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] trace-cmd: annotate function durations like the kernel
On Wed, 29 Jul 2015 10:20:15 -0700
Omar Sandoval wrote:
> On Mon, Jul 13, 2015 at 02:43:19PM -0400, Steven Rostedt wrote:
> > On Wed, 24 Jun 2015 11:36:54 -0700
> > Omar Sandoval wrote:
> >
> > > Since kernel commit, 8e1e1df29d83 ("tracing: Add additional marks to
> > > signal very large time deltas") the kernel annotates durations longer
> > > than 1000 usecs with # and longer than 1 sec with $. Update trace-cmd
> > > report to be consistent with it.
> >
> >
> > Thanks, applied.
> >
> > (sorry for the late notice). I'll be pushing this up later today.
> >
> > -- Steve
>
> Hey, Steve,
>
> I just built the latest master and noticed that this wasn't included.
> Did I miss something or did the patch get abducted by aliens sometime
> between this email and git.kernel.org? :)
>
>
I found bugs in the queue I wanted to push out, and since I was going
on vacation, I didn't have time to finish debugging it, and push out
the final result. Your patch is still in that queue.
I wont get to it today, as I'm only on Wednesday in my INBOX (i've been
working on it all day so far).
Sorry for the delay.
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drm/amdgpu: increment queue when iterating on this variable.
On Sat, Aug 1, 2015 at 9:55 AM, Nicolas Iooss
wrote:
> gfx_v7_0_print_status contains a for loop on variable queue which does
> not update this variable between each iteration. This is bug is
> reported by clang while building allmodconfig LLVMLinux on x86_64:
>
> drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c:5126:19: error: variable
> 'queue' used in loop condition not modified in loop body
> [-Werror,-Wloop-analysis]
> for (queue = 0; queue < 8; i++) {
> ^
>
> Fix this by incrementing variable queue instead of i in this loop.
>
> Signed-off-by: Nicolas Iooss
Applied. thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> index 2db6ab0a543d..5c03420ca5dc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> @@ -5122,7 +5122,7 @@ static void gfx_v7_0_print_status(void *handle)
> dev_info(adev->dev, " CP_HPD_EOP_CONTROL=0x%08X\n",
> RREG32(mmCP_HPD_EOP_CONTROL));
>
> - for (queue = 0; queue < 8; i++) {
> + for (queue = 0; queue < 8; queue++) {
> cik_srbm_select(adev, me, pipe, queue, 0);
> dev_info(adev->dev, " queue: %d\n", queue);
> dev_info(adev->dev, " CP_PQ_WPTR_POLL_CNTL=0x%08X\n",
> --
> 2.5.0
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: perf eBPF patch ordering. was: Re: perf test LLVM was: Re: [GIT PULL 00/39] perf tools: filtering events using eBPF programs
Em Mon, Aug 03, 2015 at 01:11:16PM -0300, Arnaldo Carvalho de Melo escreveu:
> > > ERROR:unable to compile ./foo.c
> > > Hint:Check error message shown above.
> > > LLVM 3.7 or newer is required. Which can be found from
> > > http://llvm.org
> > > You may want to try git trunk:
> > > git clone http://llvm.org/git/llvm.git
> > > and
> > > or: perf record [] -- []
> > > -e, --eventevent selector. use 'perf list' to list
> > > available events
> > > [root@felicio ~]#
> > > Now to find a hello.c BPF scriptlet...
So, we do not need to provide all this LLVM environment installation
hints when we get to any error, i.e. the one above was just becasuse
"./foo.c" doesn't exist, clang ran successfully, so no need for telling
the user how to install it.
The following error also shouldn't emit those hints:
[root@felicio ~]# perf record -e ./lock_page.bpf.c sleep 1
/root/./lock_page.bpf.c:1:5: error: expected parameter declarator
SEC("lock_page=__lock_page page->flags")
^
/root/./lock_page.bpf.c:1:5: error: expected ')'
/root/./lock_page.bpf.c:1:4: note: to match this '('
SEC("lock_page=__lock_page page->flags")
^
/root/./lock_page.bpf.c:1:1: warning: type specifier missing, defaults to
'int' [-Wimplicit-int]
SEC("lock_page=__lock_page page->flags")
^
/root/./lock_page.bpf.c:1:41: error: expected ';' after top level declarator
SEC("lock_page=__lock_page page->flags")
^
;
/root/./lock_page.bpf.c:2:22: warning: declaration of 'struct pt_regs' will
not be visible outside of this function [-Wvisibility]
int lock_page(struct pt_regs *ctx, int err, unsigned long flags)
^
2 warnings and 3 errors generated.
ERROR:unable to compile ./lock_page.bpf.c
Hint: Check error message shown above.
LLVM 3.7 or newer is required. Which can be found from http://llvm.org
You may want to try git trunk:
git clone http://llvm.org/git/llvm.git
and
git clone http://llvm.org/git/clang.git
Or fetch the latest clang/llvm 3.7 from pre-built llvm packages for
debian/ubuntu:
http://llvm.org/apt
If you are using old version of clang, change 'clang-bpf-cmd-template'
option in [llvm] section of ~/.perfconfig to:
"$CLANG_EXEC $CLANG_OPTIONS $KERNEL_INC_OPTIONS \
-working-directory $WORKING_DIR -c $CLANG_SOURCE \
-emit-llvm -o - | /path/to/llc -march=bpf -filetype=obj -o -"
(Replace /path/to/llc with path to your llc)
Hint: You can also pre-compile it into .o
invalid or unsupported event: './lock_page.bpf.c'
Run 'perf list' for a list of valid events
usage: perf record [] []
or: perf record [] -- []
-e, --eventevent selector. use 'perf list' to list available
events
[root@felicio ~]#
And I am interested in that "Hint: You can also pre-compile it into .o", seems
like a useful one, if it was on the screen, i.e. how can I pre-compile this
into a .o, its some random piece of eBPF "scriptlet" I found in one of your
csets, after this cset in your patchkit:
[root@felicio ~]# cat lock_page.bpf.c
SEC("lock_page=__lock_page page->flags")
int lock_page(struct pt_regs *ctx, int err, unsigned long flags)
{
return 1;
}
[root@felicio ~]#
Also it would be nice to tell the user, when compilation fails, where to look
for a eBPF scriptlet primer, i.e. where can I find some documentation on how
to write such scriptlets?
At this point I expect it to build the .c into a .o, then, as the wiring up is
not there, tell the user that all went well, but more infrastructure is needed,
apply the following patches from Wang Nan! 8-)
- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] checkpatch: Emit an error on formats with 0x%
Using 0x%d is wrong. Emit a message when it happens.
Miscellanea:
improve the %Lu warning to match formats like %16Lu
Signed-off-by: Joe Perches
---
Resend with better email client
scripts/checkpatch.pl | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 50693f5..e367eab 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -4816,16 +4816,20 @@ sub process {
"Consecutive strings are generally better as a
single string\n" . $herecurr);
}
-# check for %L{u,d,i} in strings
+# check for %L{u,d,i} and 0x%[udi] in strings
my $string;
while ($line =~ /(?:^|")([X\t]*)(?:"|$)/g) {
$string = substr($rawline, $-[1], $+[1] - $-[1]);
$string =~ s/%%/__/g;
- if ($string =~ /(?http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/7] locking/pvqspinlock: Unconditional PV kick with _Q_SLOW_VAL
On Mon, Aug 03, 2015 at 12:09:42PM -0700, Davidlohr Bueso wrote: > On Mon, 2015-08-03 at 20:37 +0200, Peter Zijlstra wrote: > > OK, so there's no 'fix'? The patch claims we can loose a wakeup and I > > just don't see how that is true. > > Taking another look, I think you could hit something like this: > > CPU0 (lock): CPU1 (unlock): > pv_wait_head > __pv_queued_spin_unlock > state> [bogus > ->state != halted] I don't think this can happen, see below, IF you take the slow path, you _must_ see halted. > > smp_store_release(&l->locked, 0); > > WRITE_ONCE(pn->state, vcpu_halted); > pv_wait(&l->locked, _Q_SLOW_VAL); if (->state == vcpu_halted) > pv_kick(node->cpu); <-- > missing wakeup, never called > > So basically you can miss a wakeup if node->state load is done while the > locking thread is spinning and hasn't gotten a chance to update the > state to halted. That would also imply that it occurs right when the > threshold limit is about to be reached. pv_wait_head() __pv_queued_spin_unlock() [S] node->state = halted [S] hash(lock, node) MB [S] ->locked = SLOW MB [L] ->locked == SLOW RMB [L] node = unhash(lock) [L] node->state == halted RELEASE [S] ->locked = 0 kick(node->cpu) CLI [L] ->locked If we don't see SLOW, nothing to be done. If we do, we _must_ then also see ->state == halted and will kick. And note that the load of node->state _cannot_ be pushed up further, it depends on the load of node, which in turn depends on the load of ->locked. So I'm still not seeing it. You cannot miss a kick. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 1/2] clk: rockchip: add pclk_pd_pmu to the list of rk3288 critical clocks
hl, On Sun, Aug 2, 2015 at 8:56 PM, huang lin wrote: > pclk_pd_pmu needs to keep running and with the upcoming gpio clock > handling this is not always the case anymore. So add it to the list > of critical clocks for now. > > Signed-off-by: Heiko Stuebner > > Signed-off-by: huang lin > --- > drivers/clk/rockchip/clk-rk3288.c | 1 + > 1 file changed, 1 insertion(+) Probably should get rid of the blank line between the two SoBs. ...and probably should fix your name to be capitalized? ...but I assume the maintainer can fix that when landing? Otherwise: Reviewed-by: Douglas Anderson -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 6/8] jump_label: Add a new static_key interface
On Mon, Aug 03, 2015 at 03:28:10PM -0400, Steven Rostedt wrote: > Technically, one can think: "activate the branch", but we are > activating not the branch, but the jump label itself. No you are enabling the branch, you're making the branch body active. There is no enable/disable/true/false for the jump label, only NOP or JUMP, and either can result in an active branch body. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] clk: pxa: pxa3xx: fix CKEN register access
Clocks 0 to 31 are on CKENA, and not CKENB. The clock register names
were inadequately inverted. As a consequence, all clock operations were
happening on CKENB, because almost all but 2 clocks are on CKENA.
As the clocks were activated by the bootloader in the former tests, it
escaped the testing that the wrong clock gate was manipulated. The error
was revealed by changing the pxa3xx-and driver to a module, where tupon
unloading the wrong clock was disabled in CKENB.
Signed-off-by: Robert Jarzmik
---
drivers/clk/pxa/clk-pxa3xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/pxa/clk-pxa3xx.c b/drivers/clk/pxa/clk-pxa3xx.c
index c677b9ab5367..4af4eed5f89f 100644
--- a/drivers/clk/pxa/clk-pxa3xx.c
+++ b/drivers/clk/pxa/clk-pxa3xx.c
@@ -126,7 +126,7 @@ PARENTS(pxa3xx_ac97_bus) = { "ring_osc_60mhz", "ac97" };
PARENTS(pxa3xx_sbus) = { "ring_osc_60mhz", "system_bus" };
PARENTS(pxa3xx_smemcbus) = { "ring_osc_60mhz", "smemc" };
-#define CKEN_AB(bit) ((CKEN_ ## bit > 31) ? &CKENA : &CKENB)
+#define CKEN_AB(bit) ((CKEN_ ## bit > 31) ? &CKENB : &CKENA)
#define PXA3XX_CKEN(dev_id, con_id, parents, mult_lp, div_lp, mult_hp, \
div_hp, bit, is_lp, flags) \
PXA_CKEN(dev_id, con_id, bit, parents, mult_lp, div_lp, \
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] i2c: allow specifying separate wakeup interrupt in device tree
Hi Tony,
On Mon, Aug 03, 2015 at 03:21:21AM -0700, Tony Lindgren wrote:
> * Vignesh R [150731 04:00]:
> > On 07/31/2015 01:44 AM, Dmitry Torokhov wrote:
> > > Instead of having each i2c driver individually parse device tree data in
> > > case it or platform supports separate wakeup interrupt, and handle
> > > enabling and disabling wakeup interrupts in their power management
> > > routines, let's have i2c core do that for us.
>
> Good idea, yes the dedicated wake-up interrupts can be handled
> at the bus level to keep device drivers generic.
>
> One question below though..
>
> > > @@ -639,11 +640,13 @@ static int i2c_device_probe(struct device *dev)
> > > if (!client->irq) {
> > > int irq = -ENOENT;
> > >
> > > - if (dev->of_node)
> > > - irq = of_irq_get(dev->of_node, 0);
> > > - else if (ACPI_COMPANION(dev))
> > > + if (dev->of_node) {
> > > + irq = of_irq_get_byname(dev->of_node, "irq");
> > > + if (irq == -EINVAL || irq == -ENODATA)
> > > + irq = of_irq_get(dev->of_node, 0);
> > > + } else if (ACPI_COMPANION(dev)) {
> > > irq = acpi_dev_gpio_irq_get(ACPI_COMPANION(dev), 0);
> > > -
> > > + }
> > > if (irq == -EPROBE_DEFER)
> > > return irq;
> > > if (irq < 0)
> > > @@ -659,20 +662,47 @@ static int i2c_device_probe(struct device *dev)
> > > if (!device_can_wakeup(&client->dev))
> > > device_init_wakeup(&client->dev,
> > > client->flags & I2C_CLIENT_WAKE);
> > > +
> > > + if (device_can_wakeup(&client->dev)) {
> > > + int wakeirq = -ENOENT;
> > > +
> > > + if (dev->of_node) {
> > > + wakeirq = of_irq_get_byname(dev->of_node, "wakeup");
> > > + if (wakeirq == -EPROBE_DEFER)
> > > + return wakeirq;
> > > + }
> > > +
> > > + if (wakeirq > 0 && wakeirq != client->irq)
> > > + status = dev_pm_set_dedicated_wake_irq(dev, wakeirq);
> > > + else if (client->irq > 0)
> > > + status = dev_pm_set_wake_irq(dev, wakeirq);
> > > + else
> > > + status = 0;
>
> Hmm why do we need the check for if (device_can_wakeup(&client->dev)))?
Because of the code in device_wakeup_attach_irq():
ws = dev->power.wakeup;
if (!ws) {
dev_err(dev, "forgot to call call device_init_wakeup?\n");
return -EINVAL;
}
>
> Also wondering about the dev vs &client->dev usage here.. But I take
> you have checked that we end up calling the runtime PM calls of the
> client instead of the i2c bus controller :)
dev *is* clent->dev in this context:
struct i2c_client *client = i2c_verify_client(dev);
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 tip/core/rcu 19/19] rcu: Add fastpath bypassing funnel locking
On Thu, 30 Jul 2015 17:40:01 +0200 Peter Zijlstra wrote: > On Thu, Jul 30, 2015 at 08:34:52AM -0700, Paul E. McKenney wrote: > > > If the extra read before the cmpxchg() does not hurt, we should do the > > > same for mutex and make the above redundant. > > > > I am pretty sure that different hardware wants it done differently. :-/ > > So I agree that hard data would be good. > > > > I could probably further optimize the RCU code by checking for a > > single-node tree, but I am not convinced that this is worthwhile. > > However, skipping three cache misses in the uncontended case is > > definitely worthwhile, hence this patch. ;-) > > I was mostly talking about the !mutex_is_locked() && mutex_try_lock() > thing. The fast path thing makes sense. Note, mutex does do this for the optimistic spin. See mutex_try_to_aquire(). -- Steve -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH tip/core/rcu 19/19] rcu: Add fastpath bypassing funnel locking
On Mon, Aug 03, 2015 at 04:05:33PM -0400, Steven Rostedt wrote: > On Thu, 30 Jul 2015 17:40:01 +0200 > Peter Zijlstra wrote: > > > On Thu, Jul 30, 2015 at 08:34:52AM -0700, Paul E. McKenney wrote: > > > > If the extra read before the cmpxchg() does not hurt, we should do the > > > > same for mutex and make the above redundant. > > > > > > I am pretty sure that different hardware wants it done differently. :-/ > > > So I agree that hard data would be good. > > > > > > I could probably further optimize the RCU code by checking for a > > > single-node tree, but I am not convinced that this is worthwhile. > > > However, skipping three cache misses in the uncontended case is > > > definitely worthwhile, hence this patch. ;-) > > > > I was mostly talking about the !mutex_is_locked() && mutex_try_lock() > > thing. The fast path thing makes sense. > > Note, mutex does do this for the optimistic spin. See > mutex_try_to_aquire(). Right but that's mutex_lock(). mutex_trylock() does not. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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/3] clocksource: atmel-st: Remove irq handler when clock event is unused
On Mon, 3 Aug 2015 16:36:29 +0200 (CEST)
Thomas Gleixner wrote:
> On Mon, 3 Aug 2015, Boris Brezillon wrote:
> > On Sun, 2 Aug 2015 11:40:28 +0200
> > Peter Zijlstra wrote:
> >
> > > On Sun, Aug 02, 2015 at 11:10:21AM +0200, Thomas Gleixner wrote:
> > > > I think Boris Brezillon had implemented it at some point, but it was
> > > > shot down for reasons I can't remember.
> > >
> > > You weren't around at the time.. DT people didn't like it, said they
> > > didn't like having to make up fake hardware in their DT crap.
> >
> > I don't know who was right, but the fact is they won't be inclined to
> > take such an approach unless the virtual demuxer is not exposed in the
> > DT, which is almost impossible since irq users are identifying their
> > irq lines with a phandle to the interrupt controller and an interrupt
> > id (usually extracted from the datasheet).
>
> I really have no idea why DT folks think that virtual devices are not
> suitable for DT entries. Marks working assumption from the old thread:
>
> > This sounds like a DT-workaround for a Linux implementation problem,
> > and I don't think this the right way to solve your problem.
>
> is simply wrong. This has nothing to do with a Linux implementation
> problem. It's a sensible workaround for braindamaged hardware at the
> proper abstraction level.
>
> > Anyway, below is a solution providing a way to disable specific
> > handlers without reworking the way we are modeling shared interrupts.
> > Thomas, I know you were not in favor of the proposed approach, but,
> > AFAICT, it does not add any conditional path to the interrupt handling
> > path (which, IIRC, was one of your requirements), and is simple enough
> > to be used by people really needing it.
> >
> > There's probably other drawback I haven't noticed, so please don't
> > hesitate to share your thoughts.
>
> Yes, aside of the bloat, it needs special handling in free_irq() as
> well.
Right. Below is a patch fixing the __setup_irq()/__free_irq() functions.
Anyway, I won't insist on this approach unless you want me to go
further, and I don't plan to spend more time on convincing DT folks that
the virtual demux is what we need (I already spent more time than I
wanted arguing on this feature :-/).
Best Regards,
Boris
--- >8 ---
>From 96448d56b202f2140e7008a3ca291b133696b4c8 Mon Sep 17 00:00:00 2001
From: Boris Brezillon
Date: Mon, 3 Aug 2015 21:59:29 +0200
Subject: [PATCH] irq: add disable_irq_handler()/enable_irq_handler() functions
Sometime we need to disable a specific handler on a shared irq line.
Currently, the only way this can be achieved is by freeing the irq handler
when we want to disable the irq and creating a new one when we want to
enable.
This is not only adding some overhead to the disable/enable operations, but
the request_irq function cannot be called in atomic context, which means
it prevents disabling the interrupt in such situation.
This patch introduces three new functions: disable_irq_handler(),
disable_irq_handler_nosync() and enable_irq_handler() to allow disabling
a specific handler on a shared irq line.
Signed-off-by: Boris Brezillon
---
include/linux/irqdesc.h | 1 +
kernel/irq/manage.c | 143 ++--
2 files changed, 126 insertions(+), 18 deletions(-)
diff --git a/include/linux/irqdesc.h b/include/linux/irqdesc.h
index fcea4e4..c8bd055 100644
--- a/include/linux/irqdesc.h
+++ b/include/linux/irqdesc.h
@@ -52,6 +52,7 @@ struct irq_desc {
irq_preflow_handler_t preflow_handler;
#endif
struct irqaction*action;/* IRQ action list */
+ struct irqaction*disabled_actions; /* IRQ disabled action
list */
unsigned intstatus_use_accessors;
unsigned intcore_internal_state__do_not_mess_with_it;
unsigned intdepth; /* nested irq disables */
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index f974485..0e7432b 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -458,6 +458,47 @@ void disable_irq_nosync(unsigned int irq)
}
EXPORT_SYMBOL(disable_irq_nosync);
+static int __disable_irq_handler_nosync(unsigned int irq, void *dev_id)
+{
+ unsigned long flags;
+ struct irqaction *action, **prev;
+ struct irq_desc *desc = irq_get_desc_buslock(irq, &flags,
IRQ_GET_DESC_CHECK_GLOBAL);
+ int ret = 0;
+
+ if (!desc)
+ return -EINVAL;
+
+ for (action = desc->action, prev = &desc->action; action; action =
action->next) {
+ if (action->dev_id == dev_id)
+ break;
+
+ prev = &action->next;
+ }
+
+ if (!action)
+ goto out;
+
+ *prev = action->next;
+
+ action->next = desc->disabled_actions;
+ desc->disabled_actions = action;
+ if (!desc->action) {
+ __disable_irq(desc, irq);
+ ret = 1;
+ }
+
+out:
+ ir
Re: [PATCH 11/18] perf script: Switch from perf.data's kallsyms to perf's symbol resolver
On Mon, Aug 03, 2015 at 04:27:59PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Mon, Aug 03, 2015 at 04:00:09PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Mon, Aug 03, 2015 at 07:41:13PM +0200, Jiri Olsa escreveu:
> > > Missing separate debuginfos, use: dnf debuginfo-install
> > > glibc-2.21-7.fc22.x86_64
> > > [Thread debugging using libthread_db enabled]
> > > Using host libthread_db library "/lib64/libthread_db.so.1".
> > > Detaching after fork from child process 11230.
> > >
> > > Program received signal SIGSEGV, Segmentation fault.
> > > 0x004eeace in pevent_set_function_resolver (pevent=0x0,
> > > func=0x4a3197 , priv=0x18e1f48) at
> > > event-parse.c:464
> > > 464 free(pevent->func_resolver);
> > > Missing separate debuginfos, use: dnf debuginfo-install
> > > audit-libs-2.4.3-1.fc22.x86_64 bzip2-libs-1.0.6-14.fc22.x86_64
> > > elfutils-libelf-0.163-1.fc22.x86_64 elfutils-libs-0.163-1.fc22.x86_64
> > > libunwind-1.1-10.fc22.x86_64 nss-softokn-freebl-3.19.2-1.0.fc22.x86_64
> > > numactl-libs-2.0.10-2.fc22.x86_64 perl-libs-5.20.2-326.fc22.x86_64
> > > python-libs-2.7.10-4.fc22.x86_64 slang-2.3.0-2.fc22.x86_64
> > > xz-libs-5.2.0-2.fc22.x86_64 zlib-1.2.8-7.fc22.x86_64
> > > (gdb)
> >
> > > I think 'session->tevent.pevent' gets initialized only for tracepoint,
> > > right?
> >
> > Reproduced, checking.
>
> Yeah, I think we only need to set libtraceevent's function resolver if
> there are tracepoints, i.e. if libtraceevent is being used. Following
> patch should be enough, right?
>
> - Arnaldo
>
> diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
> index bd31380122f9..7912feb9a024 100644
> --- a/tools/perf/builtin-script.c
> +++ b/tools/perf/builtin-script.c
> @@ -1861,7 +1861,8 @@ int cmd_script(int argc, const char **argv, const char
> *prefix __maybe_unused)
> else
> symbol_conf.use_callchain = false;
>
> - if (pevent_set_function_resolver(session->tevent.pevent,
> + if (session->tevent.pevent &&
> + pevent_set_function_resolver(session->tevent.pevent,
>machine__resolve_kernel_addr,
>&session->machines.host) < 0) {
> pr_err("%s: failed to set libtraceevent function resolver\n",
> __func__);
yep, works nicely
thanks,
jirka
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] iio: adc: xilinx-xadc: Push interrupts into threaded context
On 7/24/2015 7:38 AM, Lars-Peter Clausen wrote: Hi, Sorry, but I don't think this patch has been sufficiently tested against a mainline kernel. The driver wont even probe the way it is right now. Thanks for your responses. I'm not sure why it doesn't probe for you since I was able to do a fair amount of tests with it on our device. I'll get to work on your suggestions and hopefully having a v4 out sometime next week. -- Xander Huff Staff Software Engineer National Instruments -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] video: fbdev: pxa3xx_gcu: prepare the clocks
The clocks need to be prepared before being enabled. Without it a
warning appears in the drivers probe path :
WARNING: CPU: 0 PID: 1 at drivers/clk/clk.c:707 clk_core_enable+0x84/0xa0()
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.2.0-rc3-cm-x300+ #804
Hardware name: CM-X300 module
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (warn_slowpath_common+0x7c/0xb4)
[] (warn_slowpath_common) from []
(warn_slowpath_null+0x1c/0x24)
[] (warn_slowpath_null) from [] (clk_core_enable+0x84/0xa0)
[] (clk_core_enable) from [] (clk_enable+0x20/0x34)
[] (clk_enable) from [] (pxa3xx_gcu_probe+0x148/0x338)
[] (pxa3xx_gcu_probe) from
[] (platform_drv_probe+0x30/0x94)
Signed-off-by: Robert Jarzmik
---
drivers/video/fbdev/pxa3xx-gcu.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/video/fbdev/pxa3xx-gcu.c b/drivers/video/fbdev/pxa3xx-gcu.c
index 86bd457d039d..50bce45e7f3d 100644
--- a/drivers/video/fbdev/pxa3xx-gcu.c
+++ b/drivers/video/fbdev/pxa3xx-gcu.c
@@ -653,7 +653,7 @@ static int pxa3xx_gcu_probe(struct platform_device *pdev)
goto err_free_dma;
}
- ret = clk_enable(priv->clk);
+ ret = clk_prepare_enable(priv->clk);
if (ret < 0) {
dev_err(dev, "failed to enable clock\n");
goto err_misc_deregister;
@@ -685,7 +685,7 @@ err_misc_deregister:
misc_deregister(&priv->misc_dev);
err_disable_clk:
- clk_disable(priv->clk);
+ clk_disable_unprepare(priv->clk);
return ret;
}
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v1 2/2] pinctrl: rockchip: only enable gpio clock when it setting
hl
On Sun, Aug 2, 2015 at 8:56 PM, huang lin wrote:
> gpio can keep state even the clock disable, for save power
> consumption, only enable gpio clock when it setting
>
> Signed-off-by: Heiko Stuebner
> Signed-off-by: huang lin
>
> Signed-off-by: huang lin
Your "Signed-off-by"s are a little wonky here... Can you fix up?
> ---
> drivers/pinctrl/pinctrl-rockchip.c | 60
> ++
> 1 file changed, 54 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/pinctrl/pinctrl-rockchip.c
> b/drivers/pinctrl/pinctrl-rockchip.c
> index cc2843a..445829f 100644
> --- a/drivers/pinctrl/pinctrl-rockchip.c
> +++ b/drivers/pinctrl/pinctrl-rockchip.c
> @@ -945,17 +945,20 @@ static int _rockchip_pmx_gpio_set_direction(struct
> gpio_chip *chip,
> if (ret < 0)
> return ret;
>
> + clk_enable(bank->clk);
> spin_lock_irqsave(&bank->slock, flags);
>
> - data = readl_relaxed(bank->reg_base + GPIO_SWPORT_DDR);
> + data = readl(bank->reg_base + GPIO_SWPORT_DDR);
I am a little curious why you need to change the readl_relaxed() to a
read(). Are you trying to ensure that the clock was on before the
read happened? If so, I think this won't help. I see:
#define readl(c) ({ u32 __v = readl_relaxed(c); __iormb(); __v; })
...so that means that the iormb() is _after_ the readl.
...but I would believe that the clk_enable() call itself would be
guaranteeing that the clock was enabled in time. ...and if not then
grabbing the spinlock is another barrier, right? I think you do this
in a few places...
Other than that this patch looks good to me
-Doug
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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] usb: devio: remove assignment from if condition
On Mon, Aug 03, 2015 at 01:08:26PM -0400, Kris Borer wrote:
> else
> + switch (ctl->ioctl_code) {
This else statement isn't indented. It looks weird and it will cause
static checker warnings (hopefully).
Maybe leave that one out and send the rest. Do complicated one in a
different patch.
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5] powerpc/rcpm: add RCPM driver
On Mon, 2015-08-03 at 19:14 +0800, Chenhui Zhao wrote:
> On Sat, Aug 1, 2015 at 8:45 AM, Scott Wood
> wrote:
> > On Fri, 2015-06-26 at 15:44 +0800, Yuantian.Tang@freescale.comwrote:
> > > +static void rcpm_v1_set_ip_power(bool enable, u32 *mask)
> > > +{
> > > + if (enable)
> > > + setbits32(&rcpm_v1_regs->ippdexpcr, *mask);
> > > + else
> > > + clrbits32(&rcpm_v1_regs->ippdexpcr, *mask);
> > > +}
> > > +
> > > +static void rcpm_v2_set_ip_power(bool enable, u32 *mask)
> > > +{
> > > + if (enable)
> > > + setbits32(&rcpm_v2_regs->ippdexpcr[0], *mask);
> > > + else
> > > + clrbits32(&rcpm_v2_regs->ippdexpcr[0], *mask);
> > > +}
> >
> > Why do these take "u32 *mask" instead of "u32 mask"?
> >
> > -Scott
>
> I think it can be used in the case where there are several mask values.
When would that be?
-Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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/3] Powerpc: mpc85xx: refactor the PM operations
On Mon, 2015-08-03 at 19:32 +0800, Chenhui Zhao wrote:
> >
> On Sat, Aug 1, 2015 at 7:59 AM, Scott Wood
> wrote:
> >
> > Could you explain irq_mask()? Why would there still be IRQs destined
> > for
> > this CPU at this point?
>
> This function just masks irq by setting the registers in RCPM (for
> example, RCPM_CPMIMR, RCPM_CPMCIMR). Actually, all irqs to this CPU
> have been migrated to other CPUs.
So why do we need to set those bits in RCPM? Is it just caution?
> > @@ -431,21 +415,9 @@ void __init mpc85xx_smp_init(void)
> > >smp_85xx_ops.probe = NULL;
> > >}
> > >
> > > - np = of_find_matching_node(NULL, mpc85xx_smp_guts_ids);
> > > - if (np) {
> > > - guts = of_iomap(np, 0);
> > > - of_node_put(np);
> > > - if (!guts) {
> > > - pr_err("%s: Could not map guts node
> > > address\n",
> > > -
> > > __func__);
> > > - return;
> > > - }
> > > - smp_85xx_ops.give_timebase = mpc85xx_give_timebase;
> > > - smp_85xx_ops.take_timebase = mpc85xx_take_timebase;
> > > #ifdef CONFIG_HOTPLUG_CPU
> > > - ppc_md.cpu_die = smp_85xx_mach_cpu_die;
> > > + ppc_md.cpu_die = qoriq_cpu_dying;
> > > #endif
> >
> > Shouldn't you make sure there's a valid qoriq_pm_ops before setting
> > cpu_die()? Or make sure that qoriq_cpu_dying() works regardless.
> >
> > -Scott
>
> This patch is just for e500v2. The following patches will handle the
> case of e500mc, e5500 and e6500.
What stops a user from trying to use cpu hotplug on unsupported cpus, or in a
virtualized environment, and crashing here?
-Scott
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@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 0/6] Staging: most: several warnings fix reported by sparse
On Mon, Aug 03, 2015 at 11:30:18AM +0300, Dan Carpenter wrote: > The subjects still are not unique. Greg said this earlier. > > If you want just do it in two patches. > > [patch 1] add static > [patch 2] use NULL instead of zero > > regards, > dan carpenter > Yes, sorry. I totally messed it up. I thought Greg was referring just to the cover letter. Thanks for the hints Regards, Adrian -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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-sunxi] [PATCH] Input: axp20x-pek: Add module alias
On Mon, Aug 03, 2015 at 09:56:09AM +0200, Carlo Caione wrote: > On Mon, Aug 3, 2015 at 9:48 AM, Chen-Yu Tsai wrote: > > Add a proper module alias so the driver can be autoloaded when the > > parent axp20x mfd driver registers its cells. > > > > Signed-off-by: Chen-Yu Tsai > > Acked-by: Carlo Caione Applied, thank you. -- 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/
