Re: Armadaxp GPIO interrupts
Hi Andrew, My platform/board is ATCA carrier card which is getting interface to I/O card. The I/O card is hot-pluggable or Jack-in or Jack out. Also I/O card consists of hot-plugable SFP interface. These events are triggered using GPIO's So the events the carrier card recieves are 1) If I/O card is either Jacked-in or Jacked-out ,respective GPIO pin-x triggers an event 2) If SFP is pushed into I/O card the respective GPIO pin-y triggers an event. Another observation about "irq: Cannot allocate irq_descs @ IRQ47/79/111". This is warning & irq_descs are already allocated , the overall initialization/probe function doesn't get effected. mvebu_gpio_irq_handler is only called if I register a another handler at irq=82/83/84/85/87/88/89/90/92. I am registering this handler using minimal kernel module. My understanding of Linux IRQ/interrupt mechanism is limited to request_irq, but registering domain & then IRQ is bit not clear. Regards Raghu On Wed, Aug 5, 2015 at 9:51 PM, Andrew Lunn wrote: > On Wed, Aug 05, 2015 at 08:31:27PM +0530, raghu MG wrote: >> Hi Andrew, >> >> The issue I found was irq_alloc_descs is called twice >> 1st time inside mvebu_gpio_probe & 2nd time inside irq_domain_add_simple. > > So i'm somewhat confused. I just tested on my Kirkwood and 370 > platforms, and an Armada XP WRT1900AC using 4.2.0-rc5, all which use > the same gpio driver. > > They boot fine, the gpio driver is loaded, and the interrupt for the > gpio connected to a button are listed in /proc/interrupts. The > gpio-key driver is also able to use the gpio and the input-events > program does show events when i press the button. > > So what is different with your platform? > >Andrew -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 Thu, Aug 6, 2015 at 1:46 PM, Scott Wood wrote: On Thu, 2015-08-06 at 12:20 +0800, Chenhui Zhao wrote: On Thu, Aug 6, 2015 at 10:57 AM, Scott Wood wrote: > On Wed, 2015-08-05 at 18:11 +0800, Chenhui Zhao wrote: > > On Tue, Aug 4, 2015 at 4:26 AM, Scott Wood > > wrote: > > > 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? > > > > Setting these bits can mask interrupts signalled to RCPM from MPIC > > as a > > means of > > waking up from a lower power state. So, cores will not be waked up > > unexpectedly. > > Why would the MPIC be signalling those interrupts if they've been > masked at > the MPIC? > > -Scott > The interrupts to RCPM from MPIC are IRQ, Machine Check, NMI and Critical interrupts. Some of them didn't be masked in MPIC. What interrupt could actually happen to a sleeping cpu that this protects against? -Scott Not sure. Maybe spurious interrupts or hardware exceptions. However, setting them make sure dead cpus can not be waked up unexpectedly. -Chenhui -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] virtio-input: reset device and detach unused during remove
Spec requires a device reset during cleanup, so do it and avoid warn
in virtio core. And detach unused buffers to avoid memory leak.
Signed-off-by: Jason Wang
---
Changes from V1: detach unused buffers for sts queue.
---
drivers/virtio/virtio_input.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/virtio/virtio_input.c b/drivers/virtio/virtio_input.c
index 60e2a16..c96944b 100644
--- a/drivers/virtio/virtio_input.c
+++ b/drivers/virtio/virtio_input.c
@@ -313,6 +313,7 @@ err_init_vq:
static void virtinput_remove(struct virtio_device *vdev)
{
struct virtio_input *vi = vdev->priv;
+ void *buf;
unsigned long flags;
spin_lock_irqsave(>lock, flags);
@@ -320,6 +321,9 @@ static void virtinput_remove(struct virtio_device *vdev)
spin_unlock_irqrestore(>lock, flags);
input_unregister_device(vi->idev);
+ vdev->config->reset(vdev);
+ while ((buf = virtqueue_detach_unused_buf(vi->sts)) != NULL)
+ kfree(buf);
vdev->config->del_vqs(vdev);
kfree(vi);
}
--
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/
[V3 PATCH 1/4] panic/x86: Fix re-entrance problem due to panic on NMI
If panic on NMI happens just after panic() on the same CPU, panic()
is recursively called. As the result, it stalls after failing to
acquire panic_lock.
To avoid this problem, don't call panic() in NMI context if
we've already entered panic().
V3:
- Introduce nmi_panic() macro to reduce code duplication
- In the case of panic on NMI, don't return from NMI handlers
if another cpu already panicked
V2:
- Use atomic_cmpxchg() instead of current spin_trylock() to
exclude concurrent accesses to the panic routines
- Don't introduce no-lock version of panic()
Signed-off-by: Hidehiro Kawai
Cc: Andrew Morton
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Peter Zijlstra
Cc: Michal Hocko
---
arch/x86/kernel/nmi.c | 15 +++
include/linux/kernel.h | 13 +
kernel/panic.c | 13 ++---
kernel/watchdog.c |2 +-
4 files changed, 35 insertions(+), 8 deletions(-)
diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
index d05bd2e..dcd4038 100644
--- a/arch/x86/kernel/nmi.c
+++ b/arch/x86/kernel/nmi.c
@@ -231,7 +231,7 @@ void unregister_nmi_handler(unsigned int type, const char
*name)
#endif
if (panic_on_unrecovered_nmi)
- panic("NMI: Not continuing");
+ nmi_panic("NMI: Not continuing");
pr_emerg("Dazed and confused, but trying to continue\n");
@@ -255,8 +255,15 @@ void unregister_nmi_handler(unsigned int type, const char
*name)
reason, smp_processor_id());
show_regs(regs);
- if (panic_on_io_nmi)
- panic("NMI IOCK error: Not continuing");
+ if (panic_on_io_nmi) {
+ nmi_panic("NMI IOCK error: Not continuing");
+
+ /*
+* If we return from here, we've already being in panic.
+* So, simply return without a delay and re-enabling NMI
+*/
+ return;
+ }
/* Re-enable the IOCK line, wait for a few seconds */
reason = (reason & NMI_REASON_CLEAR_MASK) | NMI_REASON_CLEAR_IOCHK;
@@ -297,7 +304,7 @@ void unregister_nmi_handler(unsigned int type, const char
*name)
pr_emerg("Do you have a strange power saving mode enabled?\n");
if (unknown_nmi_panic || panic_on_unrecovered_nmi)
- panic("NMI: Not continuing");
+ nmi_panic("NMI: Not continuing");
pr_emerg("Dazed and confused, but trying to continue\n");
}
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 5582410..57c33da 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -443,6 +443,19 @@ extern __scanf(2, 0)
extern bool crash_kexec_post_notifiers;
+extern atomic_t panic_cpu;
+
+/*
+ * A variant of panic() called from NMI context.
+ * If we've already panicked on this cpu, return from here.
+ */
+#define nmi_panic(fmt, ...)\
+ do {\
+ int this_cpu = raw_smp_processor_id(); \
+ if (atomic_cmpxchg(_cpu, -1, this_cpu) != this_cpu) \
+ panic(fmt, ##__VA_ARGS__); \
+ } while (0)
+
/*
* Only to be used by arch init code. If the user over-wrote the default
* CONFIG_PANIC_TIMEOUT, honor it.
diff --git a/kernel/panic.c b/kernel/panic.c
index 04e91ff..3d4bc73 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -60,6 +60,8 @@ void __weak panic_smp_self_stop(void)
cpu_relax();
}
+atomic_t panic_cpu = ATOMIC_INIT(-1);
+
/**
* panic - halt the system
* @fmt: The text string to print
@@ -70,17 +72,17 @@ void __weak panic_smp_self_stop(void)
*/
void panic(const char *fmt, ...)
{
- static DEFINE_SPINLOCK(panic_lock);
static char buf[1024];
va_list args;
long i, i_next = 0;
int state = 0;
+ int old_cpu, this_cpu;
/*
* Disable local interrupts. This will prevent panic_smp_self_stop
* from deadlocking the first cpu that invokes the panic, since
* there is nothing to prevent an interrupt handler (that runs
-* after the panic_lock is acquired) from invoking panic again.
+* after setting panic_cpu) from invoking panic again.
*/
local_irq_disable();
@@ -93,8 +95,13 @@ void panic(const char *fmt, ...)
* multiple parallel invocations of panic, all other CPUs either
* stop themself or will wait until they are stopped by the 1st CPU
* with smp_send_stop().
+*
+* `old_cpu == -1' means we are the first comer.
+* `old_cpu == this_cpu' means we came here due to panic on NMI.
*/
- if (!spin_trylock(_lock))
+ this_cpu = raw_smp_processor_id();
+ old_cpu = atomic_cmpxchg(_cpu, -1, this_cpu);
+ if (old_cpu != -1 && old_cpu != this_cpu)
panic_smp_self_stop();
[V3 PATCH 0/4] Fix race issues among panic, NMI and crash_kexec
When an HA cluster software or administrator detects non-response of a host, they issue an NMI to the host to completely stop current works and take a crash dump. If the kernel has already panicked or is capturing a crash dump at that time, further NMI can cause a crash dump failure. Also, crash_kexec() called from oops context and panic() can cause race conditions. To solve these issue, this patch set does following things: - Don't panic on NMI if the kernel has already panicked - Extend exclusion control currently done by panic_lock to crash_kexec - Introduce "noextnmi" boot option which masks external NMI at the boot time (supported only for x86) V3: - Introduce nmi_panic() macro to reduce code duplication - In the case of panic on NMI, don't return from NMI handlers if another cpu already panicked V2: - Use atomic_cmpxchg() instead of current spin_trylock() to exclude concurrent accesses to panic() and crash_kexec() - Don't introduce no-lock version of panic() and crash_kexec() --- Hidehiro Kawai (4): panic/x86: Fix re-entrance problem due to panic on NMI panic/x86: Allow cpus to save registers even if they are looping in NMI context kexec: Fix race between panic() and crash_kexec() called directly x86/apic: Introduce noextnmi boot option Documentation/kernel-parameters.txt |4 arch/x86/kernel/apic/apic.c | 17 - arch/x86/kernel/nmi.c | 15 +++ arch/x86/kernel/reboot.c| 11 +++ include/linux/kernel.h | 21 + kernel/kexec.c | 20 kernel/panic.c | 23 --- kernel/watchdog.c |5 +++-- 8 files changed, 106 insertions(+), 10 deletions(-) -- Hidehiro Kawai Hitachi, Ltd. Research & Development Group -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[V3 PATCH 3/4] kexec: Fix race between panic() and crash_kexec() called directly
Currently, panic() and crash_kexec() can be called at the same time.
For example (x86 case):
CPU 0:
oops_end()
crash_kexec()
mutex_trylock() // acquired
nmi_shootdown_cpus() // stop other cpus
CPU 1:
panic()
crash_kexec()
mutex_trylock() // failed to acquire
smp_send_stop() // stop other cpus
infinite loop
If CPU 1 calls smp_send_stop() before nmi_shootdown_cpus(), kdump
fails.
In another case:
CPU 0:
oops_end()
crash_kexec()
mutex_trylock() // acquired
io_check_error()
panic()
crash_kexec()
mutex_trylock() // failed to acquire
infinite loop
Clearly, this is an undesirable result.
To fix this problem, this patch changes crash_kexec() to exclude
others by using atomic_t panicking_cpu.
V2:
- Use atomic_cmpxchg() instead of spin_trylock() on panic_lock
to exclude concurrent accesses
- Don't introduce no-lock version of crash_kexec()
Signed-off-by: Hidehiro Kawai
Cc: Eric Biederman
Cc: Vivek Goyal
Cc: Andrew Morton
Cc: Michal Hocko
---
kernel/kexec.c | 20
1 file changed, 20 insertions(+)
diff --git a/kernel/kexec.c b/kernel/kexec.c
index a785c10..ed75a8b 100644
--- a/kernel/kexec.c
+++ b/kernel/kexec.c
@@ -1472,6 +1472,18 @@ void __weak crash_unmap_reserved_pages(void)
void crash_kexec(struct pt_regs *regs)
{
+ int old_cpu, this_cpu;
+
+ /*
+* `old_cpu == -1' means we are the first comer and crash_kexec()
+* was called without entering panic().
+* `old_cpu == this_cpu' means crash_kexec() was called from panic().
+*/
+ this_cpu = raw_smp_processor_id();
+ old_cpu = atomic_cmpxchg(_cpu, -1, this_cpu);
+ if (old_cpu != -1 && old_cpu != this_cpu)
+ return;
+
/* Take the kexec_mutex here to prevent sys_kexec_load
* running on one cpu from replacing the crash kernel
* we are using after a panic on a different cpu.
@@ -1491,6 +1503,14 @@ void crash_kexec(struct pt_regs *regs)
}
mutex_unlock(_mutex);
}
+
+ /*
+* If we came here from panic(), we have to keep panic_cpu
+* to prevent other cpus from entering panic(). Otherwise,
+* resetting it so that other cpus can enter panic()/crash_kexec().
+*/
+ if (old_cpu == -1)
+ atomic_xchg(_cpu, -1);
}
size_t crash_get_memory_size(void)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next v2 1/7] net: switchdev: change fdb addr for a byte array
The address in the switchdev_obj_fdb structure is currently represented
as a pointer. Replacing it for a 6-byte array allows switchdev to carry
addresses directly read from hardware registers, not stored by the
switch chip driver (as in Rocker).
Signed-off-by: Vivien Didelot
---
drivers/net/ethernet/rocker/rocker.c | 2 +-
include/net/switchdev.h | 2 +-
net/bridge/br_fdb.c | 2 +-
net/switchdev/switchdev.c| 5 +++--
4 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/rocker/rocker.c
b/drivers/net/ethernet/rocker/rocker.c
index 4cd5a71..a5bf809 100644
--- a/drivers/net/ethernet/rocker/rocker.c
+++ b/drivers/net/ethernet/rocker/rocker.c
@@ -4543,7 +4543,7 @@ static int rocker_port_fdb_dump(const struct rocker_port
*rocker_port,
hash_for_each_safe(rocker->fdb_tbl, bkt, tmp, found, entry) {
if (found->key.pport != rocker_port->pport)
continue;
- fdb->addr = found->key.addr;
+ ether_addr_copy(fdb->addr, found->key.addr);
fdb->vid = rocker_port_vlan_to_vid(rocker_port,
found->key.vlan_id);
err = obj->cb(rocker_port->dev, obj);
diff --git a/include/net/switchdev.h b/include/net/switchdev.h
index 89da893..e90e1a0 100644
--- a/include/net/switchdev.h
+++ b/include/net/switchdev.h
@@ -70,7 +70,7 @@ struct switchdev_obj {
u32 tb_id;
} ipv4_fib;
struct switchdev_obj_fdb { /* PORT_FDB */
- const unsigned char *addr;
+ u8 addr[ETH_ALEN];
u16 vid;
} fdb;
} u;
diff --git a/net/bridge/br_fdb.c b/net/bridge/br_fdb.c
index 9e9875d..5656b44 100644
--- a/net/bridge/br_fdb.c
+++ b/net/bridge/br_fdb.c
@@ -136,11 +136,11 @@ static void fdb_del_external_learn(struct
net_bridge_fdb_entry *f)
struct switchdev_obj obj = {
.id = SWITCHDEV_OBJ_PORT_FDB,
.u.fdb = {
- .addr = f->addr.addr,
.vid = f->vlan_id,
},
};
+ ether_addr_copy(obj.u.fdb.addr, f->addr.addr);
switchdev_port_obj_del(f->dst->dev, );
}
diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
index 33bafa2..9db87a3 100644
--- a/net/switchdev/switchdev.c
+++ b/net/switchdev/switchdev.c
@@ -15,6 +15,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -742,11 +743,11 @@ int switchdev_port_fdb_add(struct ndmsg *ndm, struct
nlattr *tb[],
struct switchdev_obj obj = {
.id = SWITCHDEV_OBJ_PORT_FDB,
.u.fdb = {
- .addr = addr,
.vid = vid,
},
};
+ ether_addr_copy(obj.u.fdb.addr, addr);
return switchdev_port_obj_add(dev, );
}
EXPORT_SYMBOL_GPL(switchdev_port_fdb_add);
@@ -769,11 +770,11 @@ int switchdev_port_fdb_del(struct ndmsg *ndm, struct
nlattr *tb[],
struct switchdev_obj obj = {
.id = SWITCHDEV_OBJ_PORT_FDB,
.u.fdb = {
- .addr = addr,
.vid = vid,
},
};
+ ether_addr_copy(obj.u.fdb.addr, addr);
return switchdev_port_obj_del(dev, );
}
EXPORT_SYMBOL_GPL(switchdev_port_fdb_del);
--
2.4.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[V3 PATCH 2/4] panic/x86: Allow cpus to save registers even if they are looping in NMI context
When cpu-A panics on NMI just after cpu-B has panicked, cpu-A loops
infinitely in NMI context. Especially for x86, cpu-B issues NMI IPI
to other cpus to save their register states and do some cleanups if
kdump is enabled, but cpu-A can't handle the NMI and fails to save
register states.
To solve thie issue, we wait for the timing of the NMI IPI, then
call the NMI handler which saves register states.
V3:
- Newly introduced
Signed-off-by: Hidehiro Kawai
Cc: Andrew Morton
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Peter Zijlstra
Cc: Eric Biederman
Cc: Vivek Goyal
Cc: Michal Hocko
---
arch/x86/kernel/nmi.c|6 +++---
arch/x86/kernel/reboot.c | 11 +++
include/linux/kernel.h | 12 ++--
kernel/panic.c | 10 ++
kernel/watchdog.c|5 +++--
5 files changed, 37 insertions(+), 7 deletions(-)
diff --git a/arch/x86/kernel/nmi.c b/arch/x86/kernel/nmi.c
index dcd4038..fbb1877 100644
--- a/arch/x86/kernel/nmi.c
+++ b/arch/x86/kernel/nmi.c
@@ -231,7 +231,7 @@ void unregister_nmi_handler(unsigned int type, const char
*name)
#endif
if (panic_on_unrecovered_nmi)
- nmi_panic("NMI: Not continuing");
+ nmi_panic(regs, "NMI: Not continuing");
pr_emerg("Dazed and confused, but trying to continue\n");
@@ -256,7 +256,7 @@ void unregister_nmi_handler(unsigned int type, const char
*name)
show_regs(regs);
if (panic_on_io_nmi) {
- nmi_panic("NMI IOCK error: Not continuing");
+ nmi_panic(regs, "NMI IOCK error: Not continuing");
/*
* If we return from here, we've already being in panic.
@@ -304,7 +304,7 @@ void unregister_nmi_handler(unsigned int type, const char
*name)
pr_emerg("Do you have a strange power saving mode enabled?\n");
if (unknown_nmi_panic || panic_on_unrecovered_nmi)
- nmi_panic("NMI: Not continuing");
+ nmi_panic(regs, "NMI: Not continuing");
pr_emerg("Dazed and confused, but trying to continue\n");
}
diff --git a/arch/x86/kernel/reboot.c b/arch/x86/kernel/reboot.c
index 86db4bc..299b4b7 100644
--- a/arch/x86/kernel/reboot.c
+++ b/arch/x86/kernel/reboot.c
@@ -718,6 +718,7 @@ void machine_crash_shutdown(struct pt_regs *regs)
static nmi_shootdown_cb shootdown_callback;
static atomic_t waiting_for_crash_ipi;
+static int crash_ipi_done;
static int crash_nmi_callback(unsigned int val, struct pt_regs *regs)
{
@@ -779,6 +780,7 @@ void nmi_shootdown_cpus(nmi_shootdown_cb callback)
wmb();
smp_send_nmi_allbutself();
+ crash_ipi_done = 1; /* Kick cpus looping in nmi context */
msecs = 1000; /* Wait at most a second for the other cpus to stop */
while ((atomic_read(_for_crash_ipi) > 0) && msecs) {
@@ -788,6 +790,15 @@ void nmi_shootdown_cpus(nmi_shootdown_cb callback)
/* Leave the nmi callback set */
}
+
+void nmi_panic_self_stop(struct pt_regs *regs)
+{
+ while (crash_ipi_done == 0)
+ cpu_relax();
+
+ crash_nmi_callback(0, regs); /* Shouldn't return */
+}
+
#else /* !CONFIG_SMP */
void nmi_shootdown_cpus(nmi_shootdown_cb callback)
{
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 57c33da..9fe9961 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -255,6 +255,7 @@ static inline void might_fault(void) { }
__printf(1, 2)
void panic(const char *fmt, ...)
__noreturn __cold;
+void nmi_panic_self_stop(struct pt_regs *);
extern void oops_enter(void);
extern void oops_exit(void);
void print_oops_end_marker(void);
@@ -448,12 +449,19 @@ extern __scanf(2, 0)
/*
* A variant of panic() called from NMI context.
* If we've already panicked on this cpu, return from here.
+ * If another cpu already panicked, loop in nmi_panic_self_stop() which
+ * can provide architecture dependent code such as saving register states
+ * for crash dump.
*/
-#define nmi_panic(fmt, ...)\
+#define nmi_panic(regs, fmt, ...) \
do {\
+ int old_cpu;\
int this_cpu = raw_smp_processor_id(); \
- if (atomic_cmpxchg(_cpu, -1, this_cpu) != this_cpu) \
+ old_cpu = atomic_cmpxchg(_cpu, -1, this_cpu); \
+ if (old_cpu == -1) \
panic(fmt, ##__VA_ARGS__); \
+ else if (old_cpu != this_cpu) \
+ nmi_panic_self_stop(regs); \
} while (0)
/*
diff --git a/kernel/panic.c b/kernel/panic.c
index 3d4bc73..415c4e7 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -60,6 +60,16 @@ void __weak panic_smp_self_stop(void)
[V3 PATCH 4/4] x86/apic: Introduce noextnmi boot option
This patch introduces new boot option "noextnmi" which disables
external NMI. This option is useful for the dump capture kernel
so that an HA application or administrator wouldn't mistakenly
shoot down the kernel by NMI.
Currently, only x86 supports this option.
Signed-off-by: Hidehiro Kawai
Cc: Thomas Gleixner
Cc: Ingo Molnar
Cc: "H. Peter Anvin"
Cc: Jonathan Corbet
---
Documentation/kernel-parameters.txt |4
arch/x86/kernel/apic/apic.c | 17 -
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/Documentation/kernel-parameters.txt
b/Documentation/kernel-parameters.txt
index 1d6f045..2cbd40b 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -2364,6 +2364,10 @@ bytes respectively. Such letter suffixes can also be
entirely omitted.
noexec=on: enable non-executable mappings (default)
noexec=off: disable non-executable mappings
+ noextnmi[X86]
+ Mask external NMI. This option is useful for a
+ dump capture kernel to be shot down by NMI.
+
nosmap [X86]
Disable SMAP (Supervisor Mode Access Prevention)
even if it is supported by processor.
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index dcb5285..a140410 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -82,6 +82,12 @@
static unsigned int disabled_cpu_apicid __read_mostly = BAD_APICID;
/*
+ * Don't enable external NMI via LINT1 on BSP. This is useful for
+ * the dump capture kernel.
+ */
+static bool apic_noextnmi;
+
+/*
* Map cpu index to physical APIC ID
*/
DEFINE_EARLY_PER_CPU_READ_MOSTLY(u16, x86_cpu_to_apicid, BAD_APICID);
@@ -1150,6 +1156,8 @@ void __init init_bsp_APIC(void)
value = APIC_DM_NMI;
if (!lapic_is_integrated()) /* 82489DX */
value |= APIC_LVT_LEVEL_TRIGGER;
+ if (apic_noextnmi)
+ value |= APIC_LVT_MASKED;
apic_write(APIC_LVT1, value);
}
@@ -1369,7 +1377,7 @@ void setup_local_APIC(void)
/*
* only the BP should see the LINT1 NMI signal, obviously.
*/
- if (!cpu)
+ if (!cpu && !apic_noextnmi)
value = APIC_DM_NMI;
else
value = APIC_DM_NMI | APIC_LVT_MASKED;
@@ -2537,3 +2545,10 @@ static int __init apic_set_disabled_cpu_apicid(char *arg)
return 0;
}
early_param("disable_cpu_apicid", apic_set_disabled_cpu_apicid);
+
+static int __init apic_set_noextnmi(char *arg)
+{
+ apic_noextnmi = true;
+ return 0;
+}
+early_param("noextnmi", apic_set_noextnmi);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 Thu, 2015-08-06 at 12:20 +0800, Chenhui Zhao wrote: > On Thu, Aug 6, 2015 at 10:57 AM, Scott Wood > wrote: > > On Wed, 2015-08-05 at 18:11 +0800, Chenhui Zhao wrote: > > > On Tue, Aug 4, 2015 at 4:26 AM, Scott Wood > > > wrote: > > > > 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? > > > > > > Setting these bits can mask interrupts signalled to RCPM from MPIC > > > as a > > > means of > > > waking up from a lower power state. So, cores will not be waked up > > > unexpectedly. > > > > Why would the MPIC be signalling those interrupts if they've been > > masked at > > the MPIC? > > > > -Scott > > > > The interrupts to RCPM from MPIC are IRQ, Machine Check, NMI and > Critical interrupts. Some of them didn't be masked in MPIC. What interrupt could actually happen to a sleeping cpu that this protects against? -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-v5 5/5] i2c: pxa: Add ILCR (tLow & tHigh) configuration support
On Thursday 06 August 2015 12:41 AM, Robert Jarzmik wrote: My next slot is probably this comming Sunday. I'll do the test and report Thanks a lot. Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next v2 4/7] net: dsa: mv88e6xxx: extend fid mask
The driver currently manages one FID per port (or bridge group), with a
mask of DSA_MAX_PORTS bits, where 0 means that the FID is in use.
The Marvell 88E6xxx switches support up to 4094 FIDs (from 1 to 0xfff;
FID 0 means that multiple address databases are not being used).
This patch changes the fid_mask for an fid_bitmap of 4096 bits.
>From now on, FIDs 1 to num_ports are reserved for non-bridged ports and
bridge groups (a bridge group gets the FID of its first member). The
remaining bits will be reserved for VLAN entries.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx.c | 20 +---
drivers/net/dsa/mv88e6xxx.h | 8 +---
2 files changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 438c73e..b051576 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -1091,7 +1091,7 @@ int mv88e6xxx_join_bridge(struct dsa_switch *ds, int
port, u32 br_port_mask)
ps->bridge_mask[fid] = br_port_mask;
if (fid != ps->fid[port]) {
- ps->fid_mask |= 1 << ps->fid[port];
+ clear_bit(ps->fid[port], ps->fid_bitmap);
ps->fid[port] = fid;
ret = _mv88e6xxx_update_bridge_config(ds, fid);
}
@@ -1125,9 +1125,16 @@ int mv88e6xxx_leave_bridge(struct dsa_switch *ds, int
port, u32 br_port_mask)
mutex_lock(>smi_mutex);
- newfid = __ffs(ps->fid_mask);
+ newfid = find_next_zero_bit(ps->fid_bitmap, VLAN_N_VID, 1);
+ if (unlikely(newfid > ps->num_ports)) {
+ netdev_err(ds->ports[port], "all first %d FIDs are used\n",
+ ps->num_ports);
+ ret = -ENOSPC;
+ goto unlock;
+ }
+
ps->fid[port] = newfid;
- ps->fid_mask &= ~(1 << newfid);
+ set_bit(newfid, ps->fid_bitmap);
ps->bridge_mask[fid] &= ~(1 << port);
ps->bridge_mask[newfid] = 1 << port;
@@ -1135,6 +1142,7 @@ int mv88e6xxx_leave_bridge(struct dsa_switch *ds, int
port, u32 br_port_mask)
if (!ret)
ret = _mv88e6xxx_update_bridge_config(ds, newfid);
+unlock:
mutex_unlock(>smi_mutex);
return ret;
@@ -1554,9 +1562,9 @@ static int mv88e6xxx_setup_port(struct dsa_switch *ds,
int port)
* ports, and allow each of the 'real' ports to only talk to
* the upstream port.
*/
- fid = __ffs(ps->fid_mask);
+ fid = port + 1;
ps->fid[port] = fid;
- ps->fid_mask &= ~(1 << fid);
+ set_bit(fid, ps->fid_bitmap);
if (!dsa_is_cpu_port(ds, port))
ps->bridge_mask[fid] = 1 << port;
@@ -1855,8 +1863,6 @@ int mv88e6xxx_setup_common(struct dsa_switch *ds)
ps->id = REG_READ(REG_PORT(0), PORT_SWITCH_ID) & 0xfff0;
- ps->fid_mask = (1 << DSA_MAX_PORTS) - 1;
-
INIT_WORK(>bridge_work, mv88e6xxx_bridge_work);
name = kasprintf(GFP_KERNEL, "dsa%d", ds->index);
diff --git a/drivers/net/dsa/mv88e6xxx.h b/drivers/net/dsa/mv88e6xxx.h
index 6a66b4b..6d65b99 100644
--- a/drivers/net/dsa/mv88e6xxx.h
+++ b/drivers/net/dsa/mv88e6xxx.h
@@ -11,6 +11,8 @@
#ifndef __MV88E6XXX_H
#define __MV88E6XXX_H
+#include
+
#ifndef UINT64_MAX
#define UINT64_MAX (u64)(~((u64)0))
#endif
@@ -348,9 +350,9 @@ struct mv88e6xxx_priv_state {
/* hw bridging */
- u32 fid_mask;
- u8 fid[DSA_MAX_PORTS];
- u16 bridge_mask[DSA_MAX_PORTS];
+ DECLARE_BITMAP(fid_bitmap, VLAN_N_VID); /* FIDs 1 to 4095 available */
+ u16 fid[DSA_MAX_PORTS]; /* per (non-bridged) port FID */
+ u16 bridge_mask[DSA_MAX_PORTS]; /* br groups (indexed by FID) */
unsigned long port_state_update_mask;
u8 port_state[DSA_MAX_PORTS];
--
2.4.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next v2 2/7] net: switchdev: support static FDB addresses
This patch adds a is_static boolean to the switchdev_obj_fdb structure,
in order to set the ndm_state to either NUD_NOARP or NUD_REACHABLE.
Signed-off-by: Vivien Didelot
---
include/net/switchdev.h | 1 +
net/switchdev/switchdev.c | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/net/switchdev.h b/include/net/switchdev.h
index e90e1a0..0e296b8 100644
--- a/include/net/switchdev.h
+++ b/include/net/switchdev.h
@@ -72,6 +72,7 @@ struct switchdev_obj {
struct switchdev_obj_fdb { /* PORT_FDB */
u8 addr[ETH_ALEN];
u16 vid;
+ bool is_static;
} fdb;
} u;
};
diff --git a/net/switchdev/switchdev.c b/net/switchdev/switchdev.c
index 9db87a3..e9d1cac 100644
--- a/net/switchdev/switchdev.c
+++ b/net/switchdev/switchdev.c
@@ -811,7 +811,7 @@ static int switchdev_port_fdb_dump_cb(struct net_device
*dev,
ndm->ndm_flags = NTF_SELF;
ndm->ndm_type= 0;
ndm->ndm_ifindex = dev->ifindex;
- ndm->ndm_state = NUD_REACHABLE;
+ ndm->ndm_state = obj->u.fdb.is_static ? NUD_NOARP : NUD_REACHABLE;
if (nla_put(dump->skb, NDA_LLADDR, ETH_ALEN, obj->u.fdb.addr))
goto nla_put_failure;
--
2.4.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next v2 5/7] net: dsa: mv88e6xxx: rename ATU MAC accessors
Rename the __mv88e6xxx_{read,write}_addr functions to more explicit
_mv88e6xxx_atu_mac_{read,write} functions, which also respect the single
underscore convention used in the file (meaning SMI lock must be held).
In the meantime, define their MAC address parameters as an array of
ETH_ALEN bytes instead of a char pointer.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6xxx.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index b051576..9dad0a7 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -1182,8 +1182,8 @@ int mv88e6xxx_port_stp_update(struct dsa_switch *ds, int
port, u8 state)
return 0;
}
-static int __mv88e6xxx_write_addr(struct dsa_switch *ds,
- const unsigned char *addr)
+static int _mv88e6xxx_atu_mac_write(struct dsa_switch *ds,
+ const u8 addr[ETH_ALEN])
{
int i, ret;
@@ -1198,7 +1198,7 @@ static int __mv88e6xxx_write_addr(struct dsa_switch *ds,
return 0;
}
-static int __mv88e6xxx_read_addr(struct dsa_switch *ds, unsigned char *addr)
+static int _mv88e6xxx_atu_mac_read(struct dsa_switch *ds, u8 addr[ETH_ALEN])
{
int i, ret;
@@ -1225,7 +1225,7 @@ static int __mv88e6xxx_port_fdb_cmd(struct dsa_switch
*ds, int port,
if (ret < 0)
return ret;
- ret = __mv88e6xxx_write_addr(ds, addr);
+ ret = _mv88e6xxx_atu_mac_write(ds, addr);
if (ret < 0)
return ret;
@@ -1280,7 +1280,7 @@ static int __mv88e6xxx_port_getnext(struct dsa_switch
*ds, int port,
if (ret < 0)
return ret;
- ret = __mv88e6xxx_write_addr(ds, addr);
+ ret = _mv88e6xxx_atu_mac_write(ds, addr);
if (ret < 0)
return ret;
@@ -1297,7 +1297,7 @@ static int __mv88e6xxx_port_getnext(struct dsa_switch
*ds, int port,
return -ENOENT;
} while (!(((ret >> 4) & 0xff) & (1 << port)));
- ret = __mv88e6xxx_read_addr(ds, addr);
+ ret = _mv88e6xxx_atu_mac_read(ds, addr);
if (ret < 0)
return ret;
@@ -1661,7 +1661,7 @@ static int mv88e6xxx_atu_show_db(struct seq_file *s,
struct dsa_switch *ds,
unsigned char addr[6];
int ret, data, state;
- ret = __mv88e6xxx_write_addr(ds, bcast);
+ ret = _mv88e6xxx_atu_mac_write(ds, bcast);
if (ret < 0)
return ret;
@@ -1676,7 +1676,7 @@ static int mv88e6xxx_atu_show_db(struct seq_file *s,
struct dsa_switch *ds,
state = data & GLOBAL_ATU_DATA_STATE_MASK;
if (state == GLOBAL_ATU_DATA_STATE_UNUSED)
break;
- ret = __mv88e6xxx_read_addr(ds, addr);
+ ret = _mv88e6xxx_atu_mac_read(ds, addr);
if (ret < 0)
return ret;
mv88e6xxx_atu_show_entry(s, dbnum, addr, data);
--
2.4.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH net-next v2 3/7] net: dsa: add support for switchdev FDB objects
Remove the fdb_{add,del,getnext} function pointer in favor of new
port_fdb_{add,del,getnext}.
Implement the switchdev_port_obj_{add,del,dump} functions in DSA to
support the SWITCHDEV_OBJ_PORT_FDB objects.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6171.c | 3 -
drivers/net/dsa/mv88e6352.c | 3 -
include/net/dsa.h | 16 ++--
net/dsa/slave.c | 218 +++-
4 files changed, 126 insertions(+), 114 deletions(-)
diff --git a/drivers/net/dsa/mv88e6171.c b/drivers/net/dsa/mv88e6171.c
index 1c78084..cfa21ed 100644
--- a/drivers/net/dsa/mv88e6171.c
+++ b/drivers/net/dsa/mv88e6171.c
@@ -116,9 +116,6 @@ struct dsa_switch_driver mv88e6171_switch_driver = {
.port_join_bridge = mv88e6xxx_join_bridge,
.port_leave_bridge = mv88e6xxx_leave_bridge,
.port_stp_update= mv88e6xxx_port_stp_update,
- .fdb_add= mv88e6xxx_port_fdb_add,
- .fdb_del= mv88e6xxx_port_fdb_del,
- .fdb_getnext= mv88e6xxx_port_fdb_getnext,
};
MODULE_ALIAS("platform:mv88e6171");
diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index af210ef..eb4630f 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -341,9 +341,6 @@ struct dsa_switch_driver mv88e6352_switch_driver = {
.port_join_bridge = mv88e6xxx_join_bridge,
.port_leave_bridge = mv88e6xxx_leave_bridge,
.port_stp_update= mv88e6xxx_port_stp_update,
- .fdb_add= mv88e6xxx_port_fdb_add,
- .fdb_del= mv88e6xxx_port_fdb_del,
- .fdb_getnext= mv88e6xxx_port_fdb_getnext,
};
MODULE_ALIAS("platform:mv88e6172");
diff --git a/include/net/dsa.h b/include/net/dsa.h
index fbca63b..091d35f 100644
--- a/include/net/dsa.h
+++ b/include/net/dsa.h
@@ -296,12 +296,16 @@ struct dsa_switch_driver {
u32 br_port_mask);
int (*port_stp_update)(struct dsa_switch *ds, int port,
u8 state);
- int (*fdb_add)(struct dsa_switch *ds, int port,
- const unsigned char *addr, u16 vid);
- int (*fdb_del)(struct dsa_switch *ds, int port,
- const unsigned char *addr, u16 vid);
- int (*fdb_getnext)(struct dsa_switch *ds, int port,
- unsigned char *addr, bool *is_static);
+
+ /*
+* Forwarding database
+*/
+ int (*port_fdb_add)(struct dsa_switch *ds, int port, u16 vid,
+ const u8 addr[ETH_ALEN]);
+ int (*port_fdb_del)(struct dsa_switch *ds, int port, u16 vid,
+ const u8 addr[ETH_ALEN]);
+ int (*port_fdb_getnext)(struct dsa_switch *ds, int port, u16 *vid,
+ u8 addr[ETH_ALEN], bool *is_static);
};
void register_switch_driver(struct dsa_switch_driver *type);
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 0010c69..1dbdeaa 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include "dsa_priv.h"
/* slave mii_bus handling ***/
@@ -200,105 +201,6 @@ out:
return 0;
}
-static int dsa_slave_fdb_add(struct ndmsg *ndm, struct nlattr *tb[],
-struct net_device *dev,
-const unsigned char *addr, u16 vid, u16 nlm_flags)
-{
- struct dsa_slave_priv *p = netdev_priv(dev);
- struct dsa_switch *ds = p->parent;
- int ret = -EOPNOTSUPP;
-
- if (ds->drv->fdb_add)
- ret = ds->drv->fdb_add(ds, p->port, addr, vid);
-
- return ret;
-}
-
-static int dsa_slave_fdb_del(struct ndmsg *ndm, struct nlattr *tb[],
-struct net_device *dev,
-const unsigned char *addr, u16 vid)
-{
- struct dsa_slave_priv *p = netdev_priv(dev);
- struct dsa_switch *ds = p->parent;
- int ret = -EOPNOTSUPP;
-
- if (ds->drv->fdb_del)
- ret = ds->drv->fdb_del(ds, p->port, addr, vid);
-
- return ret;
-}
-
-static int dsa_slave_fill_info(struct net_device *dev, struct sk_buff *skb,
- const unsigned char *addr, u16 vid,
- bool is_static,
- u32 portid, u32 seq, int type,
- unsigned int flags)
-{
- struct nlmsghdr *nlh;
- struct ndmsg *ndm;
-
- nlh = nlmsg_put(skb, portid, seq, type, sizeof(*ndm), flags);
- if (!nlh)
- return -EMSGSIZE;
-
- ndm = nlmsg_data(nlh);
- ndm->ndm_family = AF_BRIDGE;
- ndm->ndm_pad1= 0;
- ndm->ndm_pad2= 0;
- ndm->ndm_flags = NTF_EXT_LEARNED;
- ndm->ndm_type= 0;
- ndm->ndm_ifindex =
Re: [PATCH 3/3] PowerPC/mpc85xx: Add hotplug support on E6500 cores
On Thu, 2015-08-06 at 12:32 +0800, Chenhui Zhao wrote:
> On Thu, Aug 6, 2015 at 11:16 AM, Scott Wood
> wrote:
> > On Wed, 2015-08-05 at 19:08 +0800, Chenhui Zhao wrote:
> > > On Sat, Aug 1, 2015 at 8:22 AM, Scott Wood
> > > wrote:
> > > > On Fri, 2015-07-31 at 17:20 +0800, b29983@freescale.comwrote:
> > > > > + /*
> > > > > + * If both threads are offline, reset core to
> > > start.
> > > > > + * When core is up, Thread 0 always gets up
> > > first,
> > > > > + * so bind the current logical cpu with Thread 0.
> > > > > + */
> > > > > + if (hw_cpu != cpu_first_thread_sibling(hw_cpu)) {
> > > > > + int hw_cpu1, hw_cpu2;
> > > > > +
> > > > > + hw_cpu1 =
> > > get_hard_smp_processor_id(primary);
> > > > > + hw_cpu2 =
> > > get_hard_smp_processor_id(primary +
> > > > > 1);
> > > > > + set_hard_smp_processor_id(primary,
> > > hw_cpu2);
> > > > > + set_hard_smp_processor_id(primary + 1,
> > > > > hw_cpu1);
> > > > > + /* get new physical cpu id */
> > > > > + hw_cpu = get_hard_smp_processor_id(nr);
> > > >
> > > > NACK as discussed in http://patchwork.ozlabs.org/patch/454944/
> > > >
> > > > -Scott
> > >
> > > You said,
> > >
> > > There's no need for this. I have booting from a thread1, and
> > > having
> > > it
> > > kick its thread0, working locally without messing with the
> > > hwid/cpu
> > > mapping.
> > >
> > > I still have questions here. After a core reset, how can you boot
> > > Thread1
> > > of the core first. As I know, Thread0 boots up first by default.
> >
> > So the issue isn't that thread1 comes up first, but that you *want*
> > thread1
> > to come up first and it won't. I don't think this remapping is an
> > acceptable
> > answer, though. Instead, if you need only thread1 to come up, start
> > the
> > core, have thread0 start thread1, and then send thread0 into whatever
> > waiting
> > state it would be in if thread1 had never been offlined.
> >
> > -Scott
>
> Remapping is a concise solution. what's the harm of it?
> Keeping things simple is good in my opinion.
Remapping is not simple. Remapping will make debugging more complicated (I
see an oops on CPU , which CPU's registers do I dump in the debugger?),
could expose bugs where smp_processor_id() is used where
hard_smp_processor_id() is needed, etc.
Having thread0 start thread1 and then go wherever it would have gone if
thread1 were up the whole time is much more straightforward.
-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/
[PATCH net-next v2 7/7] net: dsa: mv88e6xxx: rework FDB add/del operations
Add a low level function for the ATU Load operation, and provide FDB add
and delete wrappers functions.
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6171.c | 2 +
drivers/net/dsa/mv88e6352.c | 2 +
drivers/net/dsa/mv88e6xxx.c | 110 +---
drivers/net/dsa/mv88e6xxx.h | 8 ++--
4 files changed, 80 insertions(+), 42 deletions(-)
diff --git a/drivers/net/dsa/mv88e6171.c b/drivers/net/dsa/mv88e6171.c
index b99fa50..735f04c 100644
--- a/drivers/net/dsa/mv88e6171.c
+++ b/drivers/net/dsa/mv88e6171.c
@@ -116,6 +116,8 @@ struct dsa_switch_driver mv88e6171_switch_driver = {
.port_join_bridge = mv88e6xxx_join_bridge,
.port_leave_bridge = mv88e6xxx_leave_bridge,
.port_stp_update= mv88e6xxx_port_stp_update,
+ .port_fdb_add = mv88e6xxx_port_fdb_add,
+ .port_fdb_del = mv88e6xxx_port_fdb_del,
.port_fdb_getnext = mv88e6xxx_port_fdb_getnext,
};
diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index 0a77135..191fb25 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -341,6 +341,8 @@ struct dsa_switch_driver mv88e6352_switch_driver = {
.port_join_bridge = mv88e6xxx_join_bridge,
.port_leave_bridge = mv88e6xxx_leave_bridge,
.port_stp_update= mv88e6xxx_port_stp_update,
+ .port_fdb_add = mv88e6xxx_port_fdb_add,
+ .port_fdb_del = mv88e6xxx_port_fdb_del,
.port_fdb_getnext = mv88e6xxx_port_fdb_getnext,
};
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 6cad168..39203bb 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -1214,59 +1214,42 @@ static int _mv88e6xxx_atu_mac_read(struct dsa_switch
*ds, u8 addr[ETH_ALEN])
return 0;
}
-static int __mv88e6xxx_port_fdb_cmd(struct dsa_switch *ds, int port,
- const unsigned char *addr, int state)
+static int _mv88e6xxx_atu_load(struct dsa_switch *ds,
+ struct mv88e6xxx_atu_entry *entry)
{
- struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
- u8 fid = ps->fid[port];
+ u16 reg = 0;
int ret;
ret = _mv88e6xxx_atu_wait(ds);
if (ret < 0)
return ret;
- ret = _mv88e6xxx_atu_mac_write(ds, addr);
+ ret = _mv88e6xxx_atu_mac_write(ds, entry->mac);
if (ret < 0)
return ret;
- ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_DATA,
- (0x10 << port) | state);
- if (ret)
- return ret;
+ if (entry->state != GLOBAL_ATU_DATA_STATE_UNUSED) {
+ unsigned int mask, shift;
- ret = _mv88e6xxx_atu_cmd(ds, fid, GLOBAL_ATU_OP_LOAD_DB);
+ if (entry->trunk) {
+ reg |= GLOBAL_ATU_DATA_TRUNK;
+ mask = GLOBAL_ATU_DATA_TRUNK_ID_MASK;
+ shift = GLOBAL_ATU_DATA_TRUNK_ID_SHIFT;
+ } else {
+ mask = GLOBAL_ATU_DATA_PORT_VECTOR_MASK;
+ shift = GLOBAL_ATU_DATA_PORT_VECTOR_SHIFT;
+ }
- return ret;
-}
+ reg |= (entry->portv_trunkid << shift) & mask;
+ }
-int mv88e6xxx_port_fdb_add(struct dsa_switch *ds, int port,
- const unsigned char *addr, u16 vid)
-{
- int state = is_multicast_ether_addr(addr) ?
- GLOBAL_ATU_DATA_STATE_MC_STATIC :
- GLOBAL_ATU_DATA_STATE_UC_STATIC;
- struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
- int ret;
+ reg |= entry->state & GLOBAL_ATU_DATA_STATE_MASK;
- mutex_lock(>smi_mutex);
- ret = __mv88e6xxx_port_fdb_cmd(ds, port, addr, state);
- mutex_unlock(>smi_mutex);
+ ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_DATA, reg);
+ if (ret < 0)
+ return ret;
- return ret;
-}
-
-int mv88e6xxx_port_fdb_del(struct dsa_switch *ds, int port,
- const unsigned char *addr, u16 vid)
-{
- struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
- int ret;
-
- mutex_lock(>smi_mutex);
- ret = __mv88e6xxx_port_fdb_cmd(ds, port, addr,
- GLOBAL_ATU_DATA_STATE_UNUSED);
- mutex_unlock(>smi_mutex);
-
- return ret;
+ return _mv88e6xxx_atu_cmd(ds, entry->fid, GLOBAL_ATU_OP_LOAD_DB);
}
static int _mv88e6xxx_atu_getnext(struct dsa_switch *ds, u16 fid,
@@ -1329,6 +1312,57 @@ static int _mv88e6xxx_port_vid_to_fid(struct dsa_switch
*ds, int port, u16 vid)
return -ENOENT;
}
+static int _mv88e6xxx_port_fdb_load(struct dsa_switch *ds, int port, u16 vid,
+ const u8 addr[ETH_ALEN], u8 state)
+{
+ struct mv88e6xxx_atu_entry entry = { 0 };
+ int ret;
+
+ ret =
[PATCH net-next v2 6/7] net: dsa: mv88e6xxx: rework FDB getnext operation
This commit adds a low level _mv88e6xxx_atu_getnext function and helpers
to rewrite the mv88e6xxx_port_fdb_getnext operation.
A mv88e6xxx_atu_entry structure is added for convenient access to the
hardware, and GLOBAL_ATU_FID is defined instead of the raw 0x01 value.
The previous implementation did not handle the eventual trunk mapping.
If the related bit is set, then the ATU data register would contain the
trunk ID, and not the port vector.
Check this in the FDB getnext operation and do not handle it (yet).
Signed-off-by: Vivien Didelot
---
drivers/net/dsa/mv88e6171.c | 1 +
drivers/net/dsa/mv88e6352.c | 1 +
drivers/net/dsa/mv88e6xxx.c | 97 +
drivers/net/dsa/mv88e6xxx.h | 15 ++-
4 files changed, 87 insertions(+), 27 deletions(-)
diff --git a/drivers/net/dsa/mv88e6171.c b/drivers/net/dsa/mv88e6171.c
index cfa21ed..b99fa50 100644
--- a/drivers/net/dsa/mv88e6171.c
+++ b/drivers/net/dsa/mv88e6171.c
@@ -116,6 +116,7 @@ struct dsa_switch_driver mv88e6171_switch_driver = {
.port_join_bridge = mv88e6xxx_join_bridge,
.port_leave_bridge = mv88e6xxx_leave_bridge,
.port_stp_update= mv88e6xxx_port_stp_update,
+ .port_fdb_getnext = mv88e6xxx_port_fdb_getnext,
};
MODULE_ALIAS("platform:mv88e6171");
diff --git a/drivers/net/dsa/mv88e6352.c b/drivers/net/dsa/mv88e6352.c
index eb4630f..0a77135 100644
--- a/drivers/net/dsa/mv88e6352.c
+++ b/drivers/net/dsa/mv88e6352.c
@@ -341,6 +341,7 @@ struct dsa_switch_driver mv88e6352_switch_driver = {
.port_join_bridge = mv88e6xxx_join_bridge,
.port_leave_bridge = mv88e6xxx_leave_bridge,
.port_stp_update= mv88e6xxx_port_stp_update,
+ .port_fdb_getnext = mv88e6xxx_port_fdb_getnext,
};
MODULE_ALIAS("platform:mv88e6172");
diff --git a/drivers/net/dsa/mv88e6xxx.c b/drivers/net/dsa/mv88e6xxx.c
index 9dad0a7..6cad168 100644
--- a/drivers/net/dsa/mv88e6xxx.c
+++ b/drivers/net/dsa/mv88e6xxx.c
@@ -964,7 +964,7 @@ static int _mv88e6xxx_atu_cmd(struct dsa_switch *ds, int
fid, u16 cmd)
{
int ret;
- ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, 0x01, fid);
+ ret = _mv88e6xxx_reg_write(ds, REG_GLOBAL, GLOBAL_ATU_FID, fid);
if (ret < 0)
return ret;
@@ -1269,12 +1269,14 @@ int mv88e6xxx_port_fdb_del(struct dsa_switch *ds, int
port,
return ret;
}
-static int __mv88e6xxx_port_getnext(struct dsa_switch *ds, int port,
- unsigned char *addr, bool *is_static)
+static int _mv88e6xxx_atu_getnext(struct dsa_switch *ds, u16 fid,
+ const u8 addr[ETH_ALEN],
+ struct mv88e6xxx_atu_entry *entry)
{
- struct mv88e6xxx_priv_state *ps = ds_to_priv(ds);
- u8 fid = ps->fid[port];
- int ret, state;
+ struct mv88e6xxx_atu_entry next = { 0 };
+ int ret;
+
+ next.fid = fid;
ret = _mv88e6xxx_atu_wait(ds);
if (ret < 0)
@@ -1284,39 +1286,84 @@ static int __mv88e6xxx_port_getnext(struct dsa_switch
*ds, int port,
if (ret < 0)
return ret;
- do {
- ret = _mv88e6xxx_atu_cmd(ds, fid, GLOBAL_ATU_OP_GET_NEXT_DB);
- if (ret < 0)
- return ret;
+ ret = _mv88e6xxx_atu_cmd(ds, fid, GLOBAL_ATU_OP_GET_NEXT_DB);
+ if (ret < 0)
+ return ret;
- ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, GLOBAL_ATU_DATA);
- if (ret < 0)
- return ret;
- state = ret & GLOBAL_ATU_DATA_STATE_MASK;
- if (state == GLOBAL_ATU_DATA_STATE_UNUSED)
- return -ENOENT;
- } while (!(((ret >> 4) & 0xff) & (1 << port)));
+ ret = _mv88e6xxx_atu_mac_read(ds, next.mac);
+ if (ret < 0)
+ return ret;
- ret = _mv88e6xxx_atu_mac_read(ds, addr);
+ ret = _mv88e6xxx_reg_read(ds, REG_GLOBAL, GLOBAL_ATU_DATA);
if (ret < 0)
return ret;
- *is_static = state == (is_multicast_ether_addr(addr) ?
- GLOBAL_ATU_DATA_STATE_MC_STATIC :
- GLOBAL_ATU_DATA_STATE_UC_STATIC);
+ next.state = ret & GLOBAL_ATU_DATA_STATE_MASK;
+ if (next.state != GLOBAL_ATU_DATA_STATE_UNUSED) {
+ unsigned int mask, shift;
+
+ if (ret & GLOBAL_ATU_DATA_TRUNK) {
+ next.trunk = true;
+ mask = GLOBAL_ATU_DATA_TRUNK_ID_MASK;
+ shift = GLOBAL_ATU_DATA_TRUNK_ID_SHIFT;
+ } else {
+ next.trunk = false;
+ mask = GLOBAL_ATU_DATA_PORT_VECTOR_MASK;
+ shift = GLOBAL_ATU_DATA_PORT_VECTOR_SHIFT;
+ }
+
+ next.portv_trunkid = (ret & mask) >> shift;
+ }
+ *entry = next;
return 0;
}
-/*
[PATCH net-next v2 0/7] net: dsa: mv88e6xxx: support switchdev FDB objects
This patchset refactors the DSA and mv88e6xxx code to use the switchdev FDB
objects.
The first two patches add minor but necessary changes to switchdev, the third
one implements the switchdev glue in DSA for FDB routines, and the remaining
ones refactor the FDB access functions in the mv88e6xxx code.
Below is an usage example (ports 0-2 belongs to br0, ports 3-4 belongs to br1):
# bridge fdb add 3c:97:0e:11:30:6e dev swp2
# bridge fdb add 3c:97:0e:11:40:78 dev swp3
# bridge fdb add 3c:97:0e:11:50:86 dev swp4
# bridge fdb del 3c:97:0e:11:40:78 dev swp3
# bridge fdb
01:00:5e:00:00:01 dev eth0 self permanent
01:00:5e:00:00:01 dev eth1 self permanent
00:50:d2:10:78:15 dev swp0 master br0 permanent
3c:97:0e:11:30:6e dev swp2 self static
00:50:d2:10:78:15 dev swp3 master br1 permanent
3c:97:0e:11:50:86 dev swp4 self static
# cat /sys/kernel/debug/dsa0/atu
# DB T/P Vec State Addr
# 001 Port 004 e 3c:97:0e:11:30:6e
# 004 Port 010 e 3c:97:0e:11:50:86
For the 88E6xxx switches, FIDs 1 to num_ports will be reserved for non-bridged
ports and bridge groups, and the remaining will be later used by VLANs.
This change is necessary to welcome the support for hardware VLANs (which will
follow soon).
Changes in v2:
- remove ndo_bridge_{get,set,del}link from switchdev/DSA glue code
- use ether_addr_copy instead of memcpy for MAC addresses
- constify MAC address in port_fdb_{add,del}
- split the mv88e6xxx code refactoring into several patches
Vivien Didelot (7):
net: switchdev: change fdb addr for a byte array
net: switchdev: support static FDB addresses
net: dsa: add support for switchdev FDB objects
net: dsa: mv88e6xxx: extend fid mask
net: dsa: mv88e6xxx: rename ATU MAC accessors
net: dsa: mv88e6xxx: rework FDB getnext operation
net: dsa: mv88e6xxx: rework FDB add/del operations
drivers/net/dsa/mv88e6171.c | 6 +-
drivers/net/dsa/mv88e6352.c | 6 +-
drivers/net/dsa/mv88e6xxx.c | 223 ---
drivers/net/dsa/mv88e6xxx.h | 31 +++--
drivers/net/ethernet/rocker/rocker.c | 2 +-
include/net/dsa.h| 16 ++-
include/net/switchdev.h | 3 +-
net/bridge/br_fdb.c | 2 +-
net/dsa/slave.c | 218 ++
net/switchdev/switchdev.c| 7 +-
10 files changed, 317 insertions(+), 197 deletions(-)
--
2.4.6
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] perf/script: segfault on simple command
On Wed, Aug 05, 2015 at 03:40:32PM -0700, Stephane Eranian wrote: > Hi Arnaldo, Jiri > > Running this simple command from tip.git tree, I get: > > > $ perf record ls > > [ perf record: Woken up 1 times to write data ] > [ perf record: Captured and wrote 0.011 MB perf.data (9 samples) ] > > $ perf script > Segmentation fault (core dumped) > > $ gdb perf > (gdb) r script > > Program received signal SIGSEGV, Segmentation fault. > 0x0050f98b in pevent_set_function_resolver (pevent=0x0, > func=0x4b2f50 , priv=0x180bf98) at > event-parse.c:464 > 464 free(pevent->func_resolver); > (gdb) bt > #0 0x0050f98b in pevent_set_function_resolver (pevent=0x0, > func=0x4b2f50 , priv=0x180bf98) at > event-parse.c:464 > #1 0x0043cf2a in cmd_script (argc=0, argv=0x7fffe320, > prefix=) at builtin-script.c:1864 > #2 0x00474025 in run_builtin (p=p@entry=0x77a810 > , argc=argc@entry=1, argv=argv@entry=0x7fffe320) at > perf.c:370 > #3 0x0041cb50 in handle_internal_command > (argv=0x7fffe320, argc=1) at perf.c:429 > #4 run_argv (argv=0x7fffe0a0, argcp=0x7fffe0ac) at perf.c:473 > #5 main (argc=1, argv=0x7fffe320) at perf.c:588 > > Looks like something is fundamentally broken here. > Do you know what? hi, yep, it should be already taken care of: http://marc.info/?l=linux-kernel=143863009413104=2 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/
[PATCH] mmc: Kconfig: Add dependency on GPIOLIB for MMC_SDHCI
Add GPIOLIB dependency for MMC_SDHCI. Problem was observed after adding the patch "mmc: sdhci-of-arasan: Call OF parsing for MMC" (sha1: 16b23787fc709fe60c5d2bd05927b1a3da33d4e9) which calls mmc_of_parse() -> mmc_gpiod_request_cd() (slot-gpio.c) which calls devm_gpiod_get_index() which returns -ENOSYS. Error log: sdhci-arasan ff16.sdhci: parsing dt failed (4294967258) sdhci-arasan: probe of ff16.sdhci failed with error -38 Signed-off-by: Michal Simek --- After RFC here https://lkml.org/lkml/2015/7/24/371 adding dependency on MMC_SDHCI. --- drivers/mmc/host/Kconfig | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mmc/host/Kconfig b/drivers/mmc/host/Kconfig index fd9a58e216a5..5519803c124b 100644 --- a/drivers/mmc/host/Kconfig +++ b/drivers/mmc/host/Kconfig @@ -38,6 +38,7 @@ config MMC_PXA config MMC_SDHCI tristate "Secure Digital Host Controller Interface support" depends on HAS_DMA + depends on GPIOLIB help This selects the generic Secure Digital Host Controller Interface. It is used by manufacturers such as Texas Instruments(R), Ricoh(R) -- 2.3.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: about the time consuming kvm_vcpu_ioctl issue in rhel kernel
The synchronize_rcu() is a time consuming operation, the unpstream kernel still have some issue, the KVM_RUN ioctl will take more then 10ms when resume the VM after migration. Liang > -Original Message- > From: Li, Liang Z > Sent: Thursday, August 06, 2015 11:47 AM > To: 'Paolo Bonzini'; 'Juan Quintela'; linux-kernel@vger.kernel.org > Cc: Zhang, Yang Z; k...@vger.kernel.org > Subject: about the time consuming kvm_vcpu_ioctl issue in rhel kernel > > Hi Paolo & Juan, > > I found some of the kvm_vcpu_ioctl operation takes about more than 10ms > with the 3.10.0-229.el7.x86_64 kernel, which prolong the VM service > downtime when doing live migration about 20~30ms. > This happened when doing the KVM_KVMCLOCK_CTRL ioctl. It's worse if > more VCPUs used by guest(4VPUs in my test). The upstream kernel does not > have this issue because of the patch 7a72f7a140bfd3, maybe this patch > should be backported to the el7 kernel. > > Liang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] ASN.1: Fix handling of CHOICE in ASN.1 compiler
James Morris wrote: > What are the security implications of these bugs? I've fed them various bits of butchered ASN.1 and observed the effects as well as checking what happens in the code. I don't think there are any security implications. I've outlined my reasoning in each patch description. David -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] surface pro 3: Add support driver for Surface Pro 3 buttons
On Thu, 2015-08-06 at 13:16 +0800, Chen Yu wrote:
> Since Surface Pro 3 does not follow the specs of "Windows ACPI Design
> Guide for SoC Platform", code in drivers/input/misc/soc_array.c can
> not detect these buttons on it.
style trivia:
> diff --git a/drivers/platform/x86/surfacepro3_button.c
> b/drivers/platform/x86/surfacepro3_button.c
[]
> +static void surface_button_notify(struct acpi_device *device, u32 event)
> +{
[]
> + switch (event) {
> + case SURFACE_BUTTON_NOTIFY_PRESS_POWER:
> + pressed = true;
> + /*go through*/
/* fall through */ is more common
> + case SURFACE_BUTTON_NOTIFY_PRESS_HOME:
> + pressed = true;
> + case SURFACE_BUTTON_NOTIFY_RELEASE_HOME:
> + key_code = KEY_LEFTMETA;
> + break;
It may be better to add a comment about the style or
maybe add a macro like
#define HANDLE_SURFACE_BUTTON_NOTIFY(type, code)\
case SURFACE_BUTTON_NOTIFY_PRESS_##type:\
pressed = true; /* and fall-through */ \
case SURFACE_BUTTON_NOTIFY_RELEASE_##type: \
key_code = code;\
break;
> + case SURFACE_BUTTON_NOTIFY_PRESS_VOLUME_UP:
> + pressed = true;
> + case SURFACE_BUTTON_NOTIFY_RELEASE_VOLUME_UP:
> + key_code = KEY_VOLUMEUP;
> + break;
> + case SURFACE_BUTTON_NOTIFY_PRESS_VOLUME_DOWN:
> + pressed = true;
> + case SURFACE_BUTTON_NOTIFY_RELEASE_VOLUME_DOWN:
> + key_code = KEY_VOLUMEDOWN;
> + break;
> + default:
> + dev_info(>dev,
> + "Unsupported event [0x%x]\n", event);
It might be useful to ratelimit this
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] surface pro 3: Add support driver for Surface Pro 3 buttons
Since Surface Pro 3 does not follow the specs of "Windows ACPI Design
Guide for SoC Platform", code in drivers/input/misc/soc_array.c can
not detect these buttons on it. According to bios implementation,
Surface Pro 3 encapsulates these buttons in a device named "VGBI",
with _HID "MSHW0028". When any of the buttons is pressed, a specify
ACPI notification code for this button will be delivered to "VGBI". For
example, if power button is pressed down, ACPI notification code of 0xc6
will be sent by Notify(VGBI, 0xc6).
This patch leverages "VGBI" to distinguish different ACPI notification
code from Power button, Home button, Volume button, then dispatches these
code to input layer. Lid is already covered by acpi button driver, so
there's no need to rewrite.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=84651
Tested-by: Ethan Schoonover
Tested-by: Peter Amidon
Tested-by: Donavan Lance
Signed-off-by: Chen Yu
---
MAINTAINERS | 5 +
drivers/platform/x86/Kconfig | 5 +
drivers/platform/x86/Makefile | 1 +
drivers/platform/x86/surfacepro3_button.c | 203 ++
4 files changed, 214 insertions(+)
create mode 100644 drivers/platform/x86/surfacepro3_button.c
diff --git a/MAINTAINERS b/MAINTAINERS
index a9ae6c1..687b0dd 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -6712,6 +6712,11 @@ T: git git://git.monstr.eu/linux-2.6-microblaze.git
S: Supported
F: arch/microblaze/
+MICROSOFT SURFACE PRO 3 BUTTON DRIVER
+M:Chen Yu
+S:Supported
+F:drivers/platform/x86/surfacepro3_button.c
+
MICROTEK X6 SCANNER
M: Oliver Neukum
S: Maintained
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index 6dc13e4..c69bb70 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -919,4 +919,9 @@ config INTEL_PMC_IPC
The PMC is an ARC processor which defines IPC commands for communication
with other entities in the CPU.
+config SURFACE_PRO3_BUTTON
+ tristate "Power/home/volume buttons driver for Microsoft Surface Pro 3
tablet"
+ depends on ACPI && INPUT
+ ---help---
+ This driver handles the power/home/volume buttons on the Microsoft
Surface Pro 3 tablet.
endif # X86_PLATFORM_DEVICES
diff --git a/drivers/platform/x86/Makefile b/drivers/platform/x86/Makefile
index dda95a9..ada5128 100644
--- a/drivers/platform/x86/Makefile
+++ b/drivers/platform/x86/Makefile
@@ -60,3 +60,4 @@ obj-$(CONFIG_INTEL_SMARTCONNECT) += intel-smartconnect.o
obj-$(CONFIG_PVPANIC) += pvpanic.o
obj-$(CONFIG_ALIENWARE_WMI)+= alienware-wmi.o
obj-$(CONFIG_INTEL_PMC_IPC)+= intel_pmc_ipc.o
+obj-$(CONFIG_SURFACE_PRO3_BUTTON) += surfacepro3_button.o
diff --git a/drivers/platform/x86/surfacepro3_button.c
b/drivers/platform/x86/surfacepro3_button.c
new file mode 100644
index 000..8e47af6
--- /dev/null
+++ b/drivers/platform/x86/surfacepro3_button.c
@@ -0,0 +1,203 @@
+/*
+ * power/home/volume button support for
+ * Microsoft Surface Pro 3 tablet.
+ *
+ * (C) Copyright 2015 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2
+ * of the License.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define SURFACE_BUTTON_HID "MSHW0028"
+#define SURFACE_BUTTON_DEVICE_NAME "Surface Pro 3 Buttons"
+
+#define SURFACE_BUTTON_NOTIFY_PRESS_POWER 0xc6
+#define SURFACE_BUTTON_NOTIFY_RELEASE_POWER0xc7
+
+#define SURFACE_BUTTON_NOTIFY_PRESS_HOME 0xc4
+#define SURFACE_BUTTON_NOTIFY_RELEASE_HOME 0xc5
+
+#define SURFACE_BUTTON_NOTIFY_PRESS_VOLUME_UP 0xc0
+#define SURFACE_BUTTON_NOTIFY_RELEASE_VOLUME_UP0xc1
+
+#define SURFACE_BUTTON_NOTIFY_PRESS_VOLUME_DOWN0xc2
+#define SURFACE_BUTTON_NOTIFY_RELEASE_VOLUME_DOWN 0xc3
+
+ACPI_MODULE_NAME("surface pro 3 button");
+
+MODULE_AUTHOR("Chen Yu");
+MODULE_DESCRIPTION("Surface Pro3 Button Driver");
+MODULE_LICENSE("GPL v2");
+
+/*
+ * Power button, Home button, Volume buttons support is supposed to
+ * be covered by drivers/input/misc/soc_button_array.c, which is implemented
+ * according to "Windows ACPI Design Guide for SoC Platforms".
+ * However surface pro3 seems not to obey the specs, instead it uses
+ * device VGBI(MSHW0028) for dispatching the events.
+ * We choose acpi_driver rather than platform_driver/i2c_driver because
+ * although VGBI has an i2c resource connected to i2c controller, it
+ * is not embedded in any i2c controller's scope, thus neither platform_device
+ * will be created, nor i2c_client will be enumerated, we have to use
+ * acpi_driver.
+ */
+static const struct acpi_device_id surface_button_device_ids[] = {
+ {SURFACE_BUTTON_HID,0},
+ {"", 0},
+};
+MODULE_DEVICE_TABLE(acpi, surface_button_device_ids);
+
RE: [PATCH V4 4/7] Drivers: hv: vmbus: add APIs to register callbacks to process hvsock connection
> From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf > Of Dexuan Cui > Sent: Thursday, July 30, 2015 18:20 > To: David Miller ; KY Srinivasan > Cc: o...@aepfle.de; gre...@linuxfoundation.org; jasow...@redhat.com; > driverdev-de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; > step...@networkplumber.org; stefa...@redhat.com; net...@vger.kernel.org; > a...@canonical.com; pebo...@tiscali.nl; dan.carpen...@oracle.com > Subject: RE: [PATCH V4 4/7] Drivers: hv: vmbus: add APIs to register > callbacks to > process hvsock connection > > > From: David Miller > > Sent: Thursday, July 30, 2015 6:27 > > > > From: Dexuan Cui > > Date: Tue, 28 Jul 2015 05:35:11 -0700 > > > > > With the 2 APIs supplied by the VMBus driver, the coming net/hvsock driver > > > can register 2 callbacks and can know when a new hvsock connection is > > > offered by the host, and when a hvsock connection is being closed by the > > > host. > > > > > This is an extremely terrible interface. > > > > It's an opaque hook that allows on registry, and it's solve purpose > > is to allow a backdoor call into a foreign driver in another module. > > > > These are exactly the things we try to avoid. > > Hi David, > Thanks a lot for your reviewing and the suggestion! > > > Why not create a real abstraction where clients register an object, > > that can be contained as a sub-member inside of their own driver > > private, that provides the callback registry mechanism. Hi David, Can you please have a look at my below questions? I like your idea of a real abstraction. Your answer would definitely help me to implement that correctly. > Please pardon me for my inexperience. > Can you please be a bit more specific? > I guess maybe you're referencing a common design pattern in the driver > code, so an example in some existing driver would be the best. :-) > > "clients register an object " -- > does the "clients" mean the hvsock driver? > and the "object" means the 2 callbacks? > > IMHO, here the vmbus driver has to synchronously pass the 2 events > to the hvsock driver, so a "backdoor call into the hvsock driver" is > inevitable anyway? > > e.g., in the path vmbus_process_offer() -> hvsock_process_offer(), the > return value of the latter is important to the former, because on error > the former needs to clean up some internal states of the vmbus driver (that > is, the "goto err_deq_chan"). > > > > That way you can register multiple clients, do things like allow > > AF_PACKET capturing of vmbus traffic, etc. > > I thought AF_PACKET can only capture IP packets or Ethernet frames. > Can it be used to capture AF_UNIX packet? > If yes, I suppose we can consider making it work for AF_HYPERV too, > if people ask for that. > > -- Dexuan Thanks, -- Dexuan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/2] Documentation: dt: binding: atmel-sama5d4-wdt: for SAMA5D4 watchdog driver
The compatible "atmel,sama5d4-wdt" supports the SAMA5D4 watchdog driver
and the watchdog's WDT_MR register can be written more than once.
Signed-off-by: Wenyou Yang
---
.../bindings/watchdog/atmel-sama5d4-wdt.txt| 35
1 file changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/watchdog/atmel-sama5d4-wdt.txt
diff --git a/Documentation/devicetree/bindings/watchdog/atmel-sama5d4-wdt.txt
b/Documentation/devicetree/bindings/watchdog/atmel-sama5d4-wdt.txt
new file mode 100644
index 000..f7cc7c0
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/atmel-sama5d4-wdt.txt
@@ -0,0 +1,35 @@
+* Atmel SAMA5D4 Watchdog Timer (WDT) Controller
+
+Required properties:
+- compatible: "atmel,sama5d4-wdt"
+- reg: base physical address and length of memory mapped region.
+
+Optional properties:
+- timeout-sec: watchdog timeout value (in seconds).
+- interrupts: interrupt number to the CPU.
+- atmel,watchdog-type: should be "hardware" or "software".
+ "hardware": enable watchdog fault reset. A watchdog fault triggers
+ watchdog reset.
+ "software": enable watchdog fault interrupt. A watchdog fault asserts
+ watchdog interrupt.
+- atmel,idle-halt: present if you want to stop the watchdog when the CPU is
+ in idle state.
+ CAUTION: This property should be used with care, it actually makes the
+ watchdog not counting when the CPU is in idle state, therefore the
+ watchdog reset time depends on mean CPU usage and will not reset at all
+ if the CPU stop working while it is in idle state, which is probably
+ not what you want.
+- atmel,dbg-halt: present if you want to stop the watchdog when the CPU is
+ in debug state.
+
+Example:
+ watchdog@fc068640 {
+ compatible = "atmel,sama5d4-wdt";
+ reg = <0xfc068640 0x10>;
+ interrupts = <4 IRQ_TYPE_LEVEL_HIGH 5>;
+ timeout-sec = <10>;
+ atmel,watchdog-type = "hardware";
+ atmel,dbg-halt;
+ atmel,idle-halt;
+ status = "okay";
+ };
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/2] drivers: watchdog: add a driver to support SAMA5D4 watchdog timer
>From SAMA5D4, the watchdog timer is upgrated with a new feature,
which is describled as in the datasheet, "WDT_MR can be written
until a LOCKMR command is issued in WDT_CR".
That is to say, as long as the bootstrap and u-boot don't issue
a LOCKMR command, WDT_MR can be written more than once in the driver.
So the SAMA5D4 watchdog driver's implementation is different from
the at91sam9260 watchdog driver implemented in file at91sam9_wdt.c.
The user application open the device file to enable the watchdog timer
hardware, and close to disable it, and set the watchdog timer timeout
by seting WDV and WDD fields of WDT_MR register, and ping the watchdog
by issuing WDRSTT command to WDT_CR register with hard-coded key.
Signed-off-by: Wenyou Yang
---
drivers/watchdog/Kconfig|9 ++
drivers/watchdog/Makefile |1 +
drivers/watchdog/at91sam9_wdt.h |2 +
drivers/watchdog/sama5d4_wdt.c | 279 +++
4 files changed, 291 insertions(+)
create mode 100644 drivers/watchdog/sama5d4_wdt.c
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index e5e7c55..47ad39a 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -167,6 +167,15 @@ config AT91SAM9X_WATCHDOG
Watchdog timer embedded into AT91SAM9X and AT91CAP9 chips. This will
reboot your system when the timeout is reached.
+config SAMA5D4_WATCHDOG
+ tristate "Atmel SAMA5D4 Watchdog Timer"
+ depends on ARCH_AT91
+ select WATCHDOG_CORE
+ help
+ Atmel SAMA5D4 watchdog timer is embedded into SAMA5D4 chips.
+ Its Watchdog Timer Mode Register can be written more than once.
+ This will reboot your system when the timeout is reached.
+
config CADENCE_WATCHDOG
tristate "Cadence Watchdog Timer"
select WATCHDOG_CORE
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index 5c19294..f24b820 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -41,6 +41,7 @@ obj-$(CONFIG_IXP4XX_WATCHDOG) += ixp4xx_wdt.o
obj-$(CONFIG_KS8695_WATCHDOG) += ks8695_wdt.o
obj-$(CONFIG_S3C2410_WATCHDOG) += s3c2410_wdt.o
obj-$(CONFIG_SA1100_WATCHDOG) += sa1100_wdt.o
+obj-$(CONFIG_SAMA5D4_WATCHDOG) += sama5d4_wdt.o
obj-$(CONFIG_DW_WATCHDOG) += dw_wdt.o
obj-$(CONFIG_EP93XX_WATCHDOG) += ep93xx_wdt.o
obj-$(CONFIG_PNX4008_WATCHDOG) += pnx4008_wdt.o
diff --git a/drivers/watchdog/at91sam9_wdt.h b/drivers/watchdog/at91sam9_wdt.h
index c6fbb2e6..b79a83b 100644
--- a/drivers/watchdog/at91sam9_wdt.h
+++ b/drivers/watchdog/at91sam9_wdt.h
@@ -22,11 +22,13 @@
#define AT91_WDT_MR0x04/* Watchdog Mode
Register */
#defineAT91_WDT_WDV(0xfff << 0)/*
Counter Value */
+#defineAT91_WDT_SET_WDV(x) ((x) & AT91_WDT_WDV)
#defineAT91_WDT_WDFIEN (1 << 12) /*
Fault Interrupt Enable */
#defineAT91_WDT_WDRSTEN(1 << 13) /*
Reset Processor */
#defineAT91_WDT_WDRPROC(1 << 14) /*
Timer Restart */
#defineAT91_WDT_WDDIS (1 << 15) /*
Watchdog Disable */
#defineAT91_WDT_WDD(0xfff << 16) /*
Delta Value */
+#defineAT91_WDT_SET_WDD(x) (((x) << 16) &
AT91_WDT_WDD)
#defineAT91_WDT_WDDBGHLT (1 << 28) /*
Debug Halt */
#defineAT91_WDT_WDIDLEHLT (1 << 29) /* Idle
Halt */
diff --git a/drivers/watchdog/sama5d4_wdt.c b/drivers/watchdog/sama5d4_wdt.c
new file mode 100644
index 000..db67c7e
--- /dev/null
+++ b/drivers/watchdog/sama5d4_wdt.c
@@ -0,0 +1,279 @@
+/*
+ * Driver for Atmel SAMA5D4 Watchdog Timer
+ *
+ * Copyright (C) 2015 Atmel Corporation
+ *
+ * Licensed under GPLv2.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "at91sam9_wdt.h"
+
+/* minimum and maximum watchdog timeout, in seconds */
+#defineMIN_WDT_TIMEOUT 1
+#defineMAX_WDT_TIMEOUT 16
+#defineWDT_DEFAULT_TIMEOUT MAX_WDT_TIMEOUT
+
+#defineWDT_SEC2TICKS(s)((s) ? (((s) << 8) - 1) : 0)
+
+struct sama5d4_wdt {
+ struct watchdog_device wdd;
+ void __iomem*reg_base;
+ u32 config;
+};
+
+static int wdt_timeout = WDT_DEFAULT_TIMEOUT;
+static bool nowayout = WATCHDOG_NOWAYOUT;
+
+module_param(wdt_timeout, int, 0);
+MODULE_PARM_DESC(wdt_timeout,
+ "Watchdog timeout in seconds. (default = "
+ __MODULE_STRING(WDT_DEFAULT_TIMEOUT) ")");
+
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout,
+ "Watchdog cannot be stopped once started (default="
+ __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+#define wdt_read(wdt, field) \
+ readl_relaxed((wdt)->reg_base + (field))
+
+#define
[PATCH v4 0/2] add a new driver to support SAMA5D4 watchdog timer
Hello, Because the watchdog WDT_MR register can be written more than once, its work mechanism is different from the at91sam9260 watchdog driver. Open the device file to enable the watchdog hardware, close to disable it, and ping it from the user space directly to keep it alive. Changes from v3.0 1./ Change the driver name to 'sama5d4_wdt' for more acceptable. 2./ Change the prefix of function name and struct name from 'atmel_' to 'sama5d4_', and others. Changes from v2.0 1./ Use a specific driver name, at91_sama5d4_wdt.c. 2./ Remove '-' at the end of macro name and unnecessary check. 3./ Use alphabetic order for include files. Wenyou Yang (2): drivers: watchdog: add a driver to support SAMA5D4 watchdog timer Documentation: dt: binding: atmel-sama5d4-wdt: for SAMA5D4 watchdog driver .../bindings/watchdog/atmel-sama5d4-wdt.txt| 35 +++ drivers/watchdog/Kconfig |9 + drivers/watchdog/Makefile |1 + drivers/watchdog/at91sam9_wdt.h|2 + drivers/watchdog/sama5d4_wdt.c | 279 5 files changed, 326 insertions(+) create mode 100644 Documentation/devicetree/bindings/watchdog/atmel-sama5d4-wdt.txt create mode 100644 drivers/watchdog/sama5d4_wdt.c -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFCv3 1/4] docs: dts: Added documentation for Xilinx Zynq Reset Controller bindings.
On 08/05/2015 09:43 PM, Moritz Fischer wrote: > Michal, > > On Tue, Aug 4, 2015 at 8:10 AM, Philipp Zabel wrote: >> Hi Moritz, >> >> Am Dienstag, den 04.08.2015, 08:05 -0700 schrieb Moritz Fischer: >>> Hi Philip, >>> >>> On Tue, Aug 4, 2015 at 1:09 AM, Philipp Zabel >>> wrote: Hi Moritz, Am Donnerstag, den 30.07.2015, 18:13 -0700 schrieb Moritz Fischer: >> [...] > +Required properties: > +- compatible: "xlnx,zynq-reset" > +- reg: SLCR offset and size taken via syscon <0x200 0x48> > +- syscon: <> > + This should be a phandle to the Zynq's SLCR register. ^ register singular? >>> Do you want me to resend the entire set, or are you cool with just git >>> amending the 's' for registers? >> >> Amended and applied, thanks. > > Will you take 4/4 and 2/4 via your tree? Applied to zynq/dt and zynq/soc. Thanks, Michal -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] PCI: Only enable IO window if supported
On 08/05/2015 09:25 PM, Yinghai Lu wrote:
On Wed, Aug 5, 2015 at 7:22 PM, Guenter Roeck wrote:
On 08/05/2015 06:38 PM, Yinghai Lu wrote:
On Wed, Aug 5, 2015 at 6:14 PM, Yinghai Lu wrote:
It only can avoid warning with bridge, and still have warning on
devices under the bridge.
also would have problem on transparent bridges, like
BRIDGE_A BRIDGE_AADEVICE_AA
|
\-- BRIDGE_AB ---DEVICE_AB
if only BRIDGE_A and BRIDGE_AA are transparent, and BRIDGE_AB is not.
and if pci_bridge_supports_io() return false for BRIDGE_A.
We will have all three bridges have PCI_BUS_FLAGS_SUPPORTS_IO cleared.
so all will not been sized and will not get assigned io port resource.
later DEVICE_AA could root bus io port as parent, and get io resource
assigned.
but DEVICE_AB will not get assigned.
so we should get rid of pci_bridge_supports_io(), and just check root
resource IO port.
I would suggest this version instead:
Subject: [PATCH] PCI: Only try to assign io port only if root bus support
that
Bjorn had asked me to move the IO support check out of
pci_bridge_check_ranges().
It looks like you want to keep it there.
Can you explain your reasons ? Sorry, I just don't understand.
in pci_alloc_child_bus(), child bus's bus_flags will be assigned with
parent's bus_flags.
so if one parent bus has bridge's io bar can not changed, then all
children bus will also
have same bus_flags, and their bridge io bar will not used.
then if BRIDGE_AB is not transparent, we do need to use it's bridge io bar.
If I understand you correctly, we might need to change the code
in pci_read_bridge_io() as follows.
From
if (!(child->bus_flags & PCI_BUS_FLAGS_SUPPORTS_IO))
return;
to something like
if (!(child->bus_flags & PCI_BUS_FLAGS_SUPPORTS_IO)) {
if (dev->transparent)
return;
child->bus_flags |= PCI_BUS_FLAGS_SUPPORTS_IO;
}
Would that solve the problem you are concerned about ?
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 7/7] Drivers: hv: vmbus: disable local interrupt when hvsock's callback is running
> -Original Message- > From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf > Of Dexuan Cui > Sent: Thursday, July 30, 2015 18:18 > To: David Miller ; KY Srinivasan > Cc: o...@aepfle.de; gre...@linuxfoundation.org; jasow...@redhat.com; > driverdev-de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; > step...@networkplumber.org; stefa...@redhat.com; net...@vger.kernel.org; > a...@canonical.com; pebo...@tiscali.nl; dan.carpen...@oracle.com > Subject: RE: [PATCH V4 7/7] Drivers: hv: vmbus: disable local interrupt when > hvsock's callback is running > > > From: David Miller > > Sent: Thursday, July 30, 2015 6:28 > > > From: Dexuan Cui > > > Date: Tue, 28 Jul 2015 05:35:30 -0700 > > > > > > In the SMP guest case, when the per-channel callback hvsock_events() is > > > running on virtual CPU A, if the guest tries to close the connection on > > > virtual CPU B: we invoke vmbus_close() -> vmbus_close_internal(), > > > then we can have trouble: on B, vmbus_close_internal() will send IPI > > > reset_channel_cb() to A, trying to set channel->onchannel_callbackto NULL; > > > on A, if the IPI handler happens between > > > "if (channel->onchannel_callback != NULL)" and invoking > > > channel->onchannel_callback, we'll invoke a function pointer of NULL. > > > > > > This is why the patch is necessary. > > > > > Sorry, I do not accept that you must use conditional locking and/or > > IRQ disabling. > > > > Boil it down to what is necessary for the least common denominator, > > and use that unconditionally. > > Hi David, > Thanks for the comment! > > I agree with you it's not clean to use conditional IRQ disabling. > > Here I didn't use unconditionally IRQ disabling because the Hyper-V netvsc > and storvsc driver's vmbus event callbacks (i.e. netvsc_channel_cb() and > storvsc_on_channel_callback()) may take relatively long time (e.g., netvsc can > operate at a speed of 10Gb) and I think it's bad to disable IRQ for long time > when the callbacks are running in a tasklet context, e.g., the Hyper-V timer > can be affected: see vmbus_isr() -> hv_process_timer_expiration(). > > To resolve the race condition between vmbus_close_internal() and > process_chn_event() in SMP case, now I propose a new method: > > we can serialize the 2 paths by adding > tasklet_disable(hv_context.event_dpc[channel->target_cpu]) and > tasklet_enable(...) in vmbus_close_internal(). > > In this way, we need the least change and we can drop this patch. > > Please let me know your opinion. > > -- Dexuan Hi David, KY and all, May I know your opinion about my idea of adding tasklet_disable/enbable() in vmbus_close_internal() and dropping this patch? Thanks, -- Dexuan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] powerpc32: optimise csum_partial() loop
On Wed, Aug 05, 2015 at 09:31:41PM -0500, Scott Wood wrote: > On Wed, 2015-08-05 at 19:30 -0500, Segher Boessenkool wrote: > > On Wed, Aug 05, 2015 at 03:29:35PM +0200, Christophe Leroy wrote: > > > On the 8xx, load latency is 2 cycles and taking branches also takes > > > 2 cycles. So let's unroll the loop. > > > > This is not true for most other 32-bit PowerPC; this patch makes > > performance worse on e.g. 6xx/7xx/7xxx. Let's not! > > Chips with a load latency greater than 2 cycles should also benefit from the > unrolling. Have you benchmarked this somewhere and seen it reduce > performance? Do you know of any 32-bit PPC chips with a load latency less > than 2 cycles? The original loop was already optimal, as the comment said. The new code adds extra instructions and a mispredicted branch. You also might get less overlap between the loads and adde (I didn't check if there is any originally): those instructions are no longer interleaved. I think it is a stupid idea to optimise code for all 32-bit PowerPC CPUs based on solely what is best for a particularly simple, slow implementation; and that is what this patch is doing. Segher -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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: correct fpu emulation access to ldt
On Aug 5, 2015 8:35 PM, "Juergen Gross" wrote:
>
> On 08/05/2015 08:24 PM, Andy Lutomirski wrote:
>>
>> On Wed, Aug 5, 2015 at 2:11 AM, Juergen Gross wrote:
>>>
>>> On 08/04/2015 08:01 PM, Andy Lutomirski wrote:
On Tue, Aug 4, 2015 at 8:02 AM, Juergen Gross wrote:
>
>
> Commit 14805442532c ("x86/ldt: Make modify_ldt synchronous") introduced
> a new struct ldt_struct anchored at mm->context.ldt.
>
> Adapt the x86 fpu emulation to use that new structure.
>
> Signed-off-by: Juergen Gross
Whoops!
Does this need to Cc: stable?
>>>
>>>
>>>
>>> Probably.
>>>
Also, want to make it slightly fancier so we can drop the dependency
on CONFIG_MODIFY_LDT_SYSCALL?
>>>
>>>
>>>
>>> Something like:
>>>
>>> -#define LDT_DESCRIPTOR(s) (((struct desc_struct
>>> *)current->mm->context.ldt)[(s) >> 3])
>>> +#ifdef CONFIG_MODIFY_LDT_SYSCALL
>>> +#define LDT_DESCRIPTOR(s) (current->mm->context.ldt->entries[(s) >> 3])
>>> +#else
>>> +#define LDT_DESCRIPTOR(s) ((struct desc_struct){{{ .a = 0, .b = 0, }}})
>>
>>
>> Careful! I think that akpm uses some ancient gcc version that can't
>> compile that. Maybe have a global empty segment somewhere that this
>> returns, or just ifdef out the two call sites.
>>
>> Also, I don't believe this for a second:
>>
>> /* s is always from a cpu register, and the cpu does bounds checking
>> * during register load --> no further bounds checks needed */
>> #define LDT_DESCRIPTOR(s)(((struct desc_struct
>> *)current->mm->context.ldt)[(s) >> 3])
>>
>> "What the comment means is that s always came from a cpu register at
>> some point in the recent past (assuming that no lazy segment save
>> logic is in effect) and we cross our fingers and hope that we never
>> end up accessing out of bounds if the LDT isn't the same as it was at
>> the time of the fault we're handling."
>>
>> Sigh.
>>
>> Maybe the best approach would be to replace LDT_DESCRIPTOR with an
>> actual function that returns a struct desc_struct. If it's out of
>> bounds or !CONFIG_MODIFY_LDT_SYSCALL, return zeros. Otherwise return
>> the descriptor.
>
>
> Yeah, seems to be the better approach.
>
>
>>
>>> +#endif
>>>
>>> I'd need to specify the corresponding patch as a prerequisite for stable
>>> I guess? How to do this before it is picked by Linus?
>>
>>
>> Send a v2 with Cc: sta...@vger.kernel.org # [commit hash you depend
>> on]. Presumably Ingo will pick it up, not Linus.
>
>
> I know how to specify a prerequisite. I just wasn't sure which commit
> hash to use, as up to now I've only one from your tree and I guessed
> that wouldn't do it.
Gotcha. I thought it was a strange question, and I obviously misunderstood.
Use:
https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=x86/urgent=37868fe113ff2ba814b3b4eb12df214df555f8dc
if you haven't spotted it yet.
--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: [llvm-dev] [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event
On 2015/8/6 11:22, Alexei Starovoitov wrote:
On Wed, Aug 05, 2015 at 04:28:13PM +0800, Wangnan (F) wrote:
It doesn't work for me at first since in my llvm there's only
llvm.bpf.load.*.
I think llvm.bpf.store.* belone to some patches you haven't posted yet?
nope. only loads have special instructions ld_abs/ld_ind
which are represented by these intrinsics.
stores, so far, are done via single bpf_store_bytes() helper function.
the typeid changing ids with order is surprising.
I think the assertion in ExtractTypeInfo() is not hard.
Just there were no such use cases. May be we can do something
similar to what LowerIntrinsicCall() does and lower it differently
in the backend.
But in backend can we still get type information? I thought type is
meaningful in frontend only, and backend behaviors is unable to affect
DWARF generation, right?
why do we need to affect type generation? we just need to know dwarf
type id in the backend, so we can emit it as a constant.
I still think lowering eh_typeid_for differently may work.
Like instead of doing
GV = ExtractTypeInfo(I.getArgOperand(0)) followed by
getMachineFunction().getMMI().getTypeIDFor(GV)
we can get dwarf type id from I.getArgOperand(0) if it's
any pointer to struct type.
I have a bad news to tell:
#include
struct my_str {
int x;
int y;
} __gv_my_str;
struct my_str __gv_my_str_;
struct my_str2 {
int x;
int y;
} __gv_my_str2;
int typeid(void *p) asm("llvm.eh.typeid.for");
int main()
{
printf("%d\n", typeid(&__gv_my_str));
printf("%d\n", typeid(&__gv_my_str_));
printf("%d\n", typeid(&__gv_my_str2));
return 0;
}
Compiled with clang into x86 executable, then:
$ ./a.out
3
2
1
See? I have two types but reported 3 IDs.
And here is the implementation of getTypeIDFor, in
lib/CodeGen/MachineModuleInfo.cpp:
unsigned MachineModuleInfo::getTypeIDFor(const GlobalValue *TI) {
for (unsigned i = 0, N = TypeInfos.size(); i != N; ++i)
if (TypeInfos[i] == TI) return i + 1;
TypeInfos.push_back(TI);
return TypeInfos.size();
}
It only checks value in a stupid way.
Now the dwarf side becomes clear (see my other response), but the
frontend may require
totally reconsidering.
Do you know someone in LLVM-dev who can help us?
Thank you.
I'm not familiar with dwarf handling part of llvm, but feels possible.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] PowerPC/mpc85xx: Add hotplug support on E6500 cores
On Thu, Aug 6, 2015 at 11:16 AM, Scott Wood
wrote:
On Wed, 2015-08-05 at 19:08 +0800, Chenhui Zhao wrote:
On Sat, Aug 1, 2015 at 8:22 AM, Scott Wood
wrote:
> On Fri, 2015-07-31 at 17:20 +0800, b29983@freescale.comwrote:
> > + /*
> > + * If both threads are offline, reset core to
start.
> > + * When core is up, Thread 0 always gets up
first,
> > + * so bind the current logical cpu with Thread 0.
> > + */
> > + if (hw_cpu != cpu_first_thread_sibling(hw_cpu)) {
> > + int hw_cpu1, hw_cpu2;
> > +
> > + hw_cpu1 =
get_hard_smp_processor_id(primary);
> > + hw_cpu2 =
get_hard_smp_processor_id(primary +
> > 1);
> > + set_hard_smp_processor_id(primary,
hw_cpu2);
> > + set_hard_smp_processor_id(primary + 1,
> > hw_cpu1);
> > + /* get new physical cpu id */
> > + hw_cpu = get_hard_smp_processor_id(nr);
>
> NACK as discussed in http://patchwork.ozlabs.org/patch/454944/
>
> -Scott
You said,
There's no need for this. I have booting from a thread1, and
having
it
kick its thread0, working locally without messing with the
hwid/cpu
mapping.
I still have questions here. After a core reset, how can you boot
Thread1
of the core first. As I know, Thread0 boots up first by default.
So the issue isn't that thread1 comes up first, but that you *want*
thread1
to come up first and it won't. I don't think this remapping is an
acceptable
answer, though. Instead, if you need only thread1 to come up, start
the
core, have thread0 start thread1, and then send thread0 into whatever
waiting
state it would be in if thread1 had never been offlined.
-Scott
Remapping is a concise solution. what's the harm of it?
Keeping things simple is good in my opinion.
-Chenhui
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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-dev] [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event
On 2015/8/6 11:41, Alexei Starovoitov wrote: On Wed, Aug 05, 2015 at 04:59:01PM +0800, He Kuang wrote: Hi, Alexei On 2015/7/30 1:13, Alexei Starovoitov wrote: On 7/29/15 2:38 AM, He Kuang wrote: Hi, Alexei On 2015/7/28 10:18, Alexei Starovoitov wrote: On 7/25/15 3:04 AM, He Kuang wrote: I noticed that for 64-bit elf format, the reloc sections have 'Addend' in the entry, but there's no 'Addend' info in bpf elf file(64bit). I think there must be something wrong in the process of .s -> .o, which related to 64bit/32bit. Anyway, we can parse out the AT_name now, DW_AT_LOCATION still missed and need your help. Another thing about DW_AT_name, we've already found that the name string is stored indirectly and needs relocation which is architecture specific, while the e_machine info in bpf obj file is "unknown", both objdump and libdw cannot parse DW_AT_name correctly. Should we just use a known architeture for bpf object file instead of "unknown"? If so, we can use the existing relocation codes in libdw and get DIE name by simply invoking dwarf_diename(). The drawback of this method is that, e.g. we use "x86-64" instead, is hard to distinguish bpf obj file with x86-64 elf file. Do you think this is ok? The only clean way would be to register bpf as an architecture with elf standards committee. I have no idea who is doing that and how much such new e_machine registration may cost. So far using EM_NONE is a hack to avoid bureaucracy. Are dwarf relocation processor specific? Then simple hack to elfutils/libdw to treat EM_NONE as X64 should do the trick, right? If that indeed works, we can tweak bpf backend to use EM_X86_64, but then the danger that such .o file will be wrongly recognized by elf utils. imo it's safer to keep it as EM_NONE until real number is assigned, but even after it's assigned it will take time to propagate that value. So for now I would try to find a solution keeping EM_NONE hack. What about hacking ELF binary in memory? 1. load the object into memory; 2. twist the machine code to EM_X86_64; 3. load it using elf_begin; 4. return the twested elf memory image using libdwfl's find_elf callback. Then libdw will recognise BPF's object file as a X86_64 object file. If required, relocation sections can also be twisted in this way. Should not very hard since we can only consider one relocation type. Then let's start thinking how to introduce EM_BPF. We can rely on the hacking until EM_BPF symbol reaches elfutils in perf. What do you think? Thank you. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH 2/2] mtd: nand: use nand_check_erased_ecc_chunk in default ECC read functions
Il 04/08/2015 09:21, Richard Weinberger ha scritto: Andrea, Am 04.08.2015 um 09:02 schrieb Andrea Scian: 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 can enable the feature only for MLC, AFAIK it has not been required for old SLC ;-) I think this needs more discussion. Boris, Brian, will you be at Embedded Linux Conference Europe in Dublin? Maybe we can discuss these issues (data retention, ff-checks, etc...) in person and > figure out where to address them. I really want to avoid ad-hoc solutions. :) Maybe I'll be at ELCE this year too I'll be glad to meet all of you in person and participate to this discussion. :) It will be nice if also some silicon vendor would like to participate. I know that someone from micron is actively following us on this ML, but I don't really know if there's someone here in Europe. :) Thanks. In your opinion, enabling chk_io is correct to rough estimate the overhead >> or does it enable too much checks? You mean the other checks bedside of self_check_write()? You can comment them out > for your tests. Thanks, //richard Kind Regards, -- Andrea SCIAN DAVE Embedded Systems -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] PCI: Only enable IO window if supported
On Wed, Aug 5, 2015 at 7:22 PM, Guenter Roeck wrote: > On 08/05/2015 06:38 PM, Yinghai Lu wrote: >> >> On Wed, Aug 5, 2015 at 6:14 PM, Yinghai Lu wrote: >>> >>> >>> It only can avoid warning with bridge, and still have warning on >>> devices under the bridge. >>> >>> also would have problem on transparent bridges, like >>> >>> BRIDGE_A BRIDGE_AADEVICE_AA >>> | >>> \-- BRIDGE_AB ---DEVICE_AB >>> >>> if only BRIDGE_A and BRIDGE_AA are transparent, and BRIDGE_AB is not. >>> >>> and if pci_bridge_supports_io() return false for BRIDGE_A. >>> >>> We will have all three bridges have PCI_BUS_FLAGS_SUPPORTS_IO cleared. >>> so all will not been sized and will not get assigned io port resource. >>> >>> later DEVICE_AA could root bus io port as parent, and get io resource >>> assigned. >>> but DEVICE_AB will not get assigned. >>> >>> so we should get rid of pci_bridge_supports_io(), and just check root >>> resource IO port. >> >> >> I would suggest this version instead: >> >> Subject: [PATCH] PCI: Only try to assign io port only if root bus support >> that >> > > Bjorn had asked me to move the IO support check out of > pci_bridge_check_ranges(). > It looks like you want to keep it there. > > Can you explain your reasons ? Sorry, I just don't understand. in pci_alloc_child_bus(), child bus's bus_flags will be assigned with parent's bus_flags. so if one parent bus has bridge's io bar can not changed, then all children bus will also have same bus_flags, and their bridge io bar will not used. then if BRIDGE_AB is not transparent, we do need to use it's bridge io bar. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 Thu, Aug 6, 2015 at 10:57 AM, Scott Wood wrote: On Wed, 2015-08-05 at 18:11 +0800, Chenhui Zhao wrote: On Tue, Aug 4, 2015 at 4:26 AM, Scott Wood wrote: > 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? Setting these bits can mask interrupts signalled to RCPM from MPIC as a means of waking up from a lower power state. So, cores will not be waked up unexpectedly. Why would the MPIC be signalling those interrupts if they've been masked at the MPIC? -Scott The interrupts to RCPM from MPIC are IRQ, Machine Check, NMI and Critical interrupts. Some of them didn't be masked in MPIC. -Chenhui -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
page-flags behavior on compound pages: a worry
Hi Kirill,
I had a nasty thought this morning.
Andrew had prodded me gently to re-examine my concerns with your
page-flags rework in mmotm. I still dislike the bloat (my mm/built-in.o
text goes up from 478513 to 490183 bytes on a non-DEBUG_VM build); but I
was hoping to set that aside, to let us move forward.
But looking into the bloat led me to what seems a more serious issue
with it. I'd tacked a little function on to the end of mm/filemap.c:
bool page_is_locked(struct page *page)
{
return !!PageLocked(page);
}
which came out as:
3a60 :
3a60: 48 8b 07mov(%rdi),%rax
3a63: 55 push %rbp
3a64: 48 89 e5mov%rsp,%rbp
[instructions above same as without your patches; those below added by them]
3a67: f6 c4 80test $0x80,%ah
3a6a: 74 10 je 3a7c
3a6c: 48 8b 47 30 mov0x30(%rdi),%rax
3a70: 48 8b 17mov(%rdi),%rdx
3a73: 80 e6 80and$0x80,%dh
3a76: 48 0f 44 c7 cmove %rdi,%rax
3a7a: eb 03 jmp3a7f
3a7c: 48 89 f8mov%rdi,%rax
3a7f: 48 8b 00mov(%rax),%rax
[instructions above added by your patches; those below same as before]
3a82: 5d pop%rbp
3a83: 83 e0 01and$0x1,%eax
3a86: c3 retq
The "and $0x80,%dh" looked superfluous at first, but of course it isn't:
it's from the smp_rmb() in David's 668f9abbd433 "mm: close PageTail race"
(a later commit refactors compound_head() but doesn't change the story).
And it's that race, or a worse race of that kind, that now worries me.
Relying on smp_wmb() and smp_rmb() may be all that was needed in the
case that David was fixing; and (I dare not look at them to audit!)
all uses of compound_head() in our current v4.2-rc tree may well be
safe, for this or that contingent reason in each place that it's used.
But there is no locking within compound_head(page) to make it safe
everywhere, yet your page-flags rework is changing a large number
of PageWhatever()s and SetPageWhatever()s and ClearPageWhatever()s
now to do a hidden compound_head(page) beneath the covers.
To be more specific: if preemption, or an interrupt, or entry to SMM
mode, or whatever, delays this thread somewhere in that compound_head()
sequence of instructions, how can we be sure that the "head" returned
by compound_head() is good? We know the page was PageTail just before
looking up page->first_page, and we know it was PageTail just after,
but we don't know that it was PageTail throughout, and we don't know
whether page->first_page is even a good page pointer, or something
else from the private/ptl/slab_cache union.
Of course it would be very rare for it to go wrong; and most callsites
will obviously be safe for this or that reason; though, sadly, none of
them safe from holding a reference to the tail page in question, since
its count is frozen at 0 and cannot be grabbed by get_page_unless_zero.
But I don't see how it can be safe to rely on compound_head() inside
a general purpose page-flag function, that we're all accustomed to
think of as a simple bitop, that can be applied without great care.
Hugh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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.2-rc5 rcu stalls.
On Wed, Aug 05, 2015 at 02:37:59PM +0200, Frederic Weisbecker wrote: > On Tue, Aug 04, 2015 at 08:12:50PM -0400, Dave Jones wrote: > > On Tue, Aug 04, 2015 at 12:54:35AM -0400, Sasha Levin wrote: > > > On 08/03/2015 06:03 PM, Paul E. McKenney wrote: > > > >> > Ugh, that doesn't revert cleanly. Got something handy ? > > > > I do not, but perhaps either Sasha or Frederic do. > > > > > > I've attached a revert courtesy of Peter. > > > > Thanks. At first I thought this was doing the trick, but then I hit this > > again. > > > > > > [23643.545873] INFO: rcu_preempt detected stalls on CPUs/tasks: > > [23643.546031] Tasks blocked on level-0 rcu_node (CPUs 0-3): P31722 > > [23643.546173] (detected by 3, t=65002 jiffies, g=2256887, c=2256886, > > q=0) > > [23643.546326] trinity-watchdo R running task14336 31722 31721 > > 0x0008 > > [23643.546488] 8804fcfe7cc8 ded0 0002 > > 8804f58bb680 > > [23643.546661] 8800ce4951c0 8804fcfe7cb8 8804fcfe8000 > > 8804f6552608 > > [23643.546830] 0009 8804fcfe7e88 0009 > > 8804fcfe7ce8 > > [23643.547001] Call Trace: > > [23643.547058] [] preempt_schedule_common+0x22/0x40 > > [23643.547201] [] preempt_schedule+0x1f/0x30 > > [23643.547329] [] ___preempt_schedule+0x12/0x14 > > [23643.547465] [] ? do_send_sig_info+0x5d/0x80 > > [23643.547599] [] ? > > _raw_spin_unlock_irqrestore+0x42/0x70 > > [23643.547753] [] ? > > _raw_spin_unlock_irqrestore+0x60/0x70 > > [23643.547910] [] do_send_sig_info+0x5d/0x80 > > [23643.548039] [] group_send_sig_info+0xb2/0x120 > > [23643.548175] [] ? group_send_sig_info+0x5/0x120 > > [23643.548314] [] ? rcu_read_lock_held+0x4f/0x60 > > [23643.548451] [] kill_pid_info+0x7f/0x150 > > [23643.548576] [] ? kill_pid_info+0x20/0x150 > > [23643.548705] [] SYSC_kill+0xf4/0x2b0 > > [23643.548821] [] ? SYSC_kill+0x9d/0x2b0 > > [23643.548942] [] ? trace_hardirqs_on_caller+0x14b/0x1e0 > > [23643.549097] [] ? trace_hardirqs_on+0xd/0x10 > > [23643.549231] [] ? context_tracking_user_exit+0x13/0x20 > > [23643.549387] [] ? > > syscall_trace_enter_phase1+0xf7/0x150 > > [23643.549540] [] ? trace_hardirqs_on_thunk+0x17/0x19 > > [23643.549687] [] SyS_kill+0xe/0x10 > > [23643.549799] [] entry_SYSCALL_64_fastpath+0x12/0x6f > > If it still happens after Sasha's revert, which basically revert all the > offending > patches related to preempt lately, then the reason might be elsewhere. > > How hard was it to reproduce? I see 23000 secs in your dmesg logs which is > around 6 hours. Interestingly, it happened again, but only after 7 hours. I've yet to trigger it in a shorter timeframe. Frustrating. [28190.798758] INFO: rcu_preempt detected stalls on CPUs/tasks: [28190.798914] Tasks blocked on level-0 rcu_node (CPUs 0-3): P32189 [28190.799054] (detected by 1, t=65002 jiffies, g=2137396, c=2137395, q=0) [28190.799203] trinity-c224R running task13856 32189 31964 0x0008 [28190.799362] 8804f2323da8 a67fa4d1 8804fe17 8804b66db680 [28190.799531] 8804fe17 8804f2323d98 8804f2324000 [28190.799699] 0002 8804f2323dc8 [28190.799866] Call Trace: [28190.799921] [] ? preempt_schedule_irq+0x41/0xa0 [28190.800058] [] preempt_schedule_irq+0x47/0xa0 [28190.800191] [] retint_kernel+0x1b/0x2d [28190.800312] [] ? lock_acquire+0xd9/0x260 [28190.800438] [] ? __task_pid_nr_ns+0x5/0x190 [28190.800568] [] ? retint_kernel+0x2d/0x2d [28190.800691] [] __task_pid_nr_ns+0x42/0x190 [28190.800820] [] ? __task_pid_nr_ns+0x5/0x190 [28190.800950] [] sys_gettid+0x1b/0x20 [28190.801064] [] entry_SYSCALL_64_fastpath+0x12/0x6f [28190.801208] trinity-c224R running task13856 32189 31964 0x0008 [28190.801365] 8804f2323da8 a67fa4d1 8804fe17 8804b66db680 [28190.801533] 8804fe17 8804f2323d98 8804f2324000 [28190.801702] 0002 8804f2323dc8 [28190.801870] Call Trace: [28190.801923] [] ? preempt_schedule_irq+0x41/0xa0 [28190.802060] [] preempt_schedule_irq+0x47/0xa0 [28190.802193] [] retint_kernel+0x1b/0x2d [28190.802313] [] ? lock_acquire+0xd9/0x260 [28190.802436] [] ? __task_pid_nr_ns+0x5/0x190 [28190.802565] [] ? retint_kernel+0x2d/0x2d [28190.802688] [] __task_pid_nr_ns+0x42/0x190 [28190.802815] [] ? __task_pid_nr_ns+0x5/0x190 [28190.802945] [] sys_gettid+0x1b/0x20 [28190.803058] [] entry_SYSCALL_64_fastpath+0x12/0x6f [29929.492752] INFO: rcu_preempt detected stalls on CPUs/tasks: [29929.492906] Tasks blocked on level-0 rcu_node (CPUs 0-3): P289 [29929.493039] (detected by 0, t=65002 jiffies, g=2141006, c=2141005, q=0) [29929.493188] systemd-journal R running task12464 289 1 0x0008 [29929.493347] 8804ff2bbae8 a67fa4d1 880501f81b40
[PATCH] [trivial] net:wimax: Fix doucble word "the the" in networking.xml
This patch fix a double word "the the" in Documentation/DocBook/networking.xml and Documentation/DocBook/networking/API-Wimax-report-rfkill-sw.html. These files are generated from comment in source, so I had to fix the typo in net/wimax/io-rfkill.c Signed-off-by: Masanari Iida --- net/wimax/op-rfkill.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/net/wimax/op-rfkill.c b/net/wimax/op-rfkill.c index 7d73054..477364a 100644 --- a/net/wimax/op-rfkill.c +++ b/net/wimax/op-rfkill.c @@ -135,8 +135,7 @@ EXPORT_SYMBOL_GPL(wimax_report_rfkill_hw); * @state: New state of the RF kill switch. %WIMAX_RF_ON radio on, * %WIMAX_RF_OFF radio off. * - * Reports changes in the software RF switch state to the the WiMAX - * stack. + * Reports changes in the software RF switch state to the WiMAX stack. * * The main use is during initialization, so the driver can query the * device for its current software radio kill switch state and feed it -- 2.5.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] checkpatch: Don't complain about long "Fixes:" lines
On Thu, 2015-08-06 at 13:44 +1000, Michael Ellerman wrote: > We encourage people to mention the commit they are fixing, if any, using > a Fixes line, see SubmittingPatches. https://lkml.org/lkml/2015/7/31/1271 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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 V5] audit: use macros for unset inode and device values
Clean up a number of places were casted magic numbers are used to represent
unset inode and device numbers in preparation for the audit by executable path
patch set.
Signed-off-by: Richard Guy Briggs
---
v6: Change dev macro cast from unsigned int to dev_t.
v5: Move macros from include/uapi/linux/audit.h to include/linux/audit.h
Use "unsigned int" rather than bare "unsigned".
include/linux/audit.h |3 +++
kernel/audit.c|2 +-
kernel/audit_watch.c |8
kernel/auditsc.c |6 +++---
4 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/include/linux/audit.h b/include/linux/audit.h
index c2e7e3a..1514412 100644
--- a/include/linux/audit.h
+++ b/include/linux/audit.h
@@ -27,6 +27,9 @@
#include
#include
+#define AUDIT_INO_UNSET (unsigned long)-1
+#define AUDIT_DEV_UNSET (dev_t)-1
+
struct audit_sig_info {
uid_t uid;
pid_t pid;
diff --git a/kernel/audit.c b/kernel/audit.c
index 1c13e42..d546003 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1761,7 +1761,7 @@ void audit_log_name(struct audit_context *context, struct
audit_names *n,
} else
audit_log_format(ab, " name=(null)");
- if (n->ino != (unsigned long)-1)
+ if (n->ino != AUDIT_INO_UNSET)
audit_log_format(ab, " inode=%lu"
" dev=%02x:%02x mode=%#ho"
" ouid=%u ogid=%u rdev=%02x:%02x",
diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index 8f123d7..c668bfc 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -138,7 +138,7 @@ char *audit_watch_path(struct audit_watch *watch)
int audit_watch_compare(struct audit_watch *watch, unsigned long ino, dev_t
dev)
{
- return (watch->ino != (unsigned long)-1) &&
+ return (watch->ino != AUDIT_INO_UNSET) &&
(watch->ino == ino) &&
(watch->dev == dev);
}
@@ -179,8 +179,8 @@ static struct audit_watch *audit_init_watch(char *path)
INIT_LIST_HEAD(>rules);
atomic_set(>count, 1);
watch->path = path;
- watch->dev = (dev_t)-1;
- watch->ino = (unsigned long)-1;
+ watch->dev = AUDIT_DEV_UNSET;
+ watch->ino = AUDIT_INO_UNSET;
return watch;
}
@@ -493,7 +493,7 @@ static int audit_watch_handle_event(struct fsnotify_group
*group,
if (mask & (FS_CREATE|FS_MOVED_TO) && inode)
audit_update_watch(parent, dname, inode->i_sb->s_dev,
inode->i_ino, 0);
else if (mask & (FS_DELETE|FS_MOVED_FROM))
- audit_update_watch(parent, dname, (dev_t)-1, (unsigned long)-1,
1);
+ audit_update_watch(parent, dname, AUDIT_DEV_UNSET,
AUDIT_INO_UNSET, 1);
else if (mask & (FS_DELETE_SELF|FS_UNMOUNT|FS_MOVE_SELF))
audit_remove_parent_watches(parent);
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index 9fb9d1c..701ea5c 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -180,7 +180,7 @@ static int audit_match_filetype(struct audit_context *ctx,
int val)
return 0;
list_for_each_entry(n, >names_list, list) {
- if ((n->ino != -1) &&
+ if ((n->ino != AUDIT_INO_UNSET) &&
((n->mode & S_IFMT) == mode))
return 1;
}
@@ -1683,7 +1683,7 @@ static struct audit_names *audit_alloc_name(struct
audit_context *context,
aname->should_free = true;
}
- aname->ino = (unsigned long)-1;
+ aname->ino = AUDIT_INO_UNSET;
aname->type = type;
list_add_tail(>list, >names_list);
@@ -1925,7 +1925,7 @@ void __audit_inode_child(const struct inode *parent,
if (inode)
audit_copy_inode(found_child, dentry, inode);
else
- found_child->ino = (unsigned long)-1;
+ found_child->ino = AUDIT_INO_UNSET;
}
EXPORT_SYMBOL_GPL(__audit_inode_child);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
about the time consuming kvm_vcpu_ioctl issue in rhel kernel
Hi Paolo & Juan, I found some of the kvm_vcpu_ioctl operation takes about more than 10ms with the 3.10.0-229.el7.x86_64 kernel, which prolong the VM service downtime when doing live migration about 20~30ms. This happened when doing the KVM_KVMCLOCK_CTRL ioctl. It's worse if more VCPUs used by guest(4VPUs in my test). The upstream kernel does not have this issue because of the patch 7a72f7a140bfd3, maybe this patch should be backported to the el7 kernel. Liang -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@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] checkpatch: Don't complain about long "Fixes:" lines
We encourage people to mention the commit they are fixing, if any, using
a Fixes line, see SubmittingPatches.
Although it's not mentioned explicitly, it's preferable if the Fixes
line is not wrapped, so skip Fixes lines when checking for overlength
lines.
Signed-off-by: Michael Ellerman
---
scripts/checkpatch.pl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index d5c8e9a3a73c..b3139cb1bf9d 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -2310,7 +2310,7 @@ sub process {
# Check for line lengths > 75 in commit log, warn once
if ($in_commit_log && !$commit_log_long_line &&
- length($line) > 75) {
+ length($line) > 75 && $line !~ /^\s*Fixes: [0-9a-f]+/i) {
WARN("COMMIT_LOG_LONG_LINE",
"Possible unwrapped commit description (prefer a
maximum 75 chars per line)\n" . $herecurr);
$commit_log_long_line = 1;
--
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: [llvm-dev] [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event
On Wed, Aug 05, 2015 at 04:59:01PM +0800, He Kuang wrote: > Hi, Alexei > > On 2015/7/30 1:13, Alexei Starovoitov wrote: > >On 7/29/15 2:38 AM, He Kuang wrote: > >>Hi, Alexei > >> > >>On 2015/7/28 10:18, Alexei Starovoitov wrote: > >>>On 7/25/15 3:04 AM, He Kuang wrote: > I noticed that for 64-bit elf format, the reloc sections have > 'Addend' in the entry, but there's no 'Addend' info in bpf elf > file(64bit). I think there must be something wrong in the process > of .s -> .o, which related to 64bit/32bit. Anyway, we can parse out the > AT_name now, DW_AT_LOCATION still missed and need your help. > >>> > > Another thing about DW_AT_name, we've already found that the name > string is stored indirectly and needs relocation which is > architecture specific, while the e_machine info in bpf obj file > is "unknown", both objdump and libdw cannot parse DW_AT_name > correctly. > > Should we just use a known architeture for bpf object file > instead of "unknown"? If so, we can use the existing relocation > codes in libdw and get DIE name by simply invoking > dwarf_diename(). The drawback of this method is that, e.g. we > use "x86-64" instead, is hard to distinguish bpf obj file with > x86-64 elf file. Do you think this is ok? The only clean way would be to register bpf as an architecture with elf standards committee. I have no idea who is doing that and how much such new e_machine registration may cost. So far using EM_NONE is a hack to avoid bureaucracy. Are dwarf relocation processor specific? Then simple hack to elfutils/libdw to treat EM_NONE as X64 should do the trick, right? If that indeed works, we can tweak bpf backend to use EM_X86_64, but then the danger that such .o file will be wrongly recognized by elf utils. imo it's safer to keep it as EM_NONE until real number is assigned, but even after it's assigned it will take time to propagate that value. So for now I would try to find a solution keeping EM_NONE hack. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] audit: use macros for unset inode and device values
On 15/08/05, Paul Moore wrote: > On Wednesday, August 05, 2015 04:19:09 PM Richard Guy Briggs wrote: > > Clean up a number of places were casted magic numbers are used to represent > > unset inode and device numbers in preparation for the audit by executable > > path patch set. > > > > Signed-off-by: Richard Guy Briggs > > --- > > v5: Move macros from include/uapi/linux/audit.h to include/linux/audit.h > > Use "unsigned int" rather than bare "unsigned". > > > > include/linux/audit.h |3 +++ > > kernel/audit.c|2 +- > > kernel/audit_watch.c |8 > > kernel/auditsc.c |6 +++--- > > 4 files changed, 11 insertions(+), 8 deletions(-) > > > > diff --git a/include/linux/audit.h b/include/linux/audit.h > > index c2e7e3a..48ae90c 100644 > > --- a/include/linux/audit.h > > +++ b/include/linux/audit.h > > @@ -27,6 +27,9 @@ > > #include > > #include > > > > +#define AUDIT_INO_UNSET (unsigned long)-1 > > +#define AUDIT_DEV_UNSET (unsigned int)-1 > > I suspect it was lost in the noise when I mentioned it on v4, but how about > changing AUDIT_DEV_UNSET to "(dev_t)-1"? I saw your comment only after resubmitting. I'm fine either way. If it is needed for uapi later it can be changed then. Is it easy to change in your workflow, or should I resubmit? I know you routinely change the patch description, but could not remember if you have actually changed the patch itself... > paul moore - RGB -- Richard Guy Briggs Senior Software Engineer, Kernel Security, AMER ENG Base Operating Systems, Red Hat Remote, Ottawa, Canada Voice: +1.647.777.2635, Internal: (81) 32635, Alt: +1.613.693.0684x3545 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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: correct fpu emulation access to ldt
On 08/05/2015 08:24 PM, Andy Lutomirski wrote:
On Wed, Aug 5, 2015 at 2:11 AM, Juergen Gross wrote:
On 08/04/2015 08:01 PM, Andy Lutomirski wrote:
On Tue, Aug 4, 2015 at 8:02 AM, Juergen Gross wrote:
Commit 14805442532c ("x86/ldt: Make modify_ldt synchronous") introduced
a new struct ldt_struct anchored at mm->context.ldt.
Adapt the x86 fpu emulation to use that new structure.
Signed-off-by: Juergen Gross
Whoops!
Does this need to Cc: stable?
Probably.
Also, want to make it slightly fancier so we can drop the dependency
on CONFIG_MODIFY_LDT_SYSCALL?
Something like:
-#define LDT_DESCRIPTOR(s) (((struct desc_struct
*)current->mm->context.ldt)[(s) >> 3])
+#ifdef CONFIG_MODIFY_LDT_SYSCALL
+#define LDT_DESCRIPTOR(s) (current->mm->context.ldt->entries[(s) >> 3])
+#else
+#define LDT_DESCRIPTOR(s) ((struct desc_struct){{{ .a = 0, .b = 0, }}})
Careful! I think that akpm uses some ancient gcc version that can't
compile that. Maybe have a global empty segment somewhere that this
returns, or just ifdef out the two call sites.
Also, I don't believe this for a second:
/* s is always from a cpu register, and the cpu does bounds checking
* during register load --> no further bounds checks needed */
#define LDT_DESCRIPTOR(s)(((struct desc_struct
*)current->mm->context.ldt)[(s) >> 3])
"What the comment means is that s always came from a cpu register at
some point in the recent past (assuming that no lazy segment save
logic is in effect) and we cross our fingers and hope that we never
end up accessing out of bounds if the LDT isn't the same as it was at
the time of the fault we're handling."
Sigh.
Maybe the best approach would be to replace LDT_DESCRIPTOR with an
actual function that returns a struct desc_struct. If it's out of
bounds or !CONFIG_MODIFY_LDT_SYSCALL, return zeros. Otherwise return
the descriptor.
Yeah, seems to be the better approach.
+#endif
I'd need to specify the corresponding patch as a prerequisite for stable
I guess? How to do this before it is picked by Linus?
Send a v2 with Cc: sta...@vger.kernel.org # [commit hash you depend
on]. Presumably Ingo will pick it up, not Linus.
I know how to specify a prerequisite. I just wasn't sure which commit
hash to use, as up to now I've only one from your tree and I guessed
that wouldn't do it.
Juergen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 2/2] firmware: qcom: scm: Add support for ARM64 SoCs
On Wed, Aug 05, 2015 at 06:27:24PM -0700, Stephen Boyd wrote:
> On 04/28/2015 12:23 PM, Kumar Gala wrote:
> >+
> >+int __qcom_scm_call_armv8_64(u64 x0, u64 x1, u64 x2, u64 x3, u64 x4, u64 x5,
> >+u64 *ret1, u64 *ret2, u64 *ret3)
> >+{
> >+register u64 r0 asm("r0") = x0;
> >+register u64 r1 asm("r1") = x1;
> >+register u64 r2 asm("r2") = x2;
> >+register u64 r3 asm("r3") = x3;
> >+register u64 r4 asm("r4") = x4;
> >+register u64 r5 asm("r5") = x5;
>
> This should set x6 to 0.
>
> register u32 r6 asm("r6") = 0;
>
> for example.
>
> >+
> >+do {
> >+asm volatile(
> >+__asmeq("%0", "x0")
> >+__asmeq("%1", "x1")
> >+__asmeq("%2", "x2")
> >+__asmeq("%3", "x3")
> >+__asmeq("%4", "x0")
> >+__asmeq("%5", "x1")
> >+__asmeq("%6", "x2")
> >+__asmeq("%7", "x3")
> >+__asmeq("%8", "x4")
> >+__asmeq("%9", "x5")
>
> And then the asmeq thing here for x6.
>
> >+#ifdef REQUIRES_SEC
> >+".arch_extension sec\n"
> >+#endif
> >+"smc#0\n"
> >+: "=r" (r0), "=r" (r1), "=r" (r2), "=r" (r3)
> >+: "r" (r0), "r" (r1), "r" (r2), "r" (r3), "r" (r4),
> >+ "r" (r5)
>
> And add x6 as an input here.
>
> >+: "x6", "x7", "x8", "x9", "x10", "x11", "x12", "x13",
>
> and remove x6 as a clobber.
>
> >+ "x14", "x15", "x16", "x17");
> >+} while (r0 == QCOM_SCM_INTERRUPTED);
> >+
> >+if (ret1)
> >+*ret1 = r1;
> >+if (ret2)
> >+*ret2 = r2;
> >+if (ret3)
> >+*ret3 = r3;
> >+
> >+return r0;
> >+}
> >+
> >+int __qcom_scm_call_armv8_32(u32 w0, u32 w1, u32 w2, u32 w3, u32 w4, u32 w5,
> >+u64 *ret1, u64 *ret2, u64 *ret3)
> >+{
> >+register u32 r0 asm("r0") = w0;
> >+register u32 r1 asm("r1") = w1;
> >+register u32 r2 asm("r2") = w2;
> >+register u32 r3 asm("r3") = w3;
> >+register u32 r4 asm("r4") = w4;
> >+register u32 r5 asm("r5") = w5;
>
> This needs to set r6 to 0 as well
>
> register u32 r6 asm("r6") = 0;
>
> for example.
>
> >+
> >+do {
> >+asm volatile(
> >+__asmeq("%0", "x0")
> >+__asmeq("%1", "x1")
> >+__asmeq("%2", "x2")
> >+__asmeq("%3", "x3")
> >+__asmeq("%4", "x0")
> >+__asmeq("%5", "x1")
> >+__asmeq("%6", "x2")
> >+__asmeq("%7", "x3")
> >+__asmeq("%8", "x4")
> >+__asmeq("%9", "x5")
>
> And then another asmeq thing here for x6.
>
> >+#ifdef REQUIRES_SEC
> >+".arch_extension sec\n"
> >+#endif
> >+"smc#0\n"
> >+: "=r" (r0), "=r" (r1), "=r" (r2), "=r" (r3)
> >+: "r" (r0), "r" (r1), "r" (r2), "r" (r3), "r" (r4),
> >+ "r" (r5)
>
> And then add r6 here as an input
>
> >+: "x6", "x7", "x8", "x9", "x10", "x11", "x12", "x13",
>
> And remove r6 from the clobber.
>
> >+"x14", "x15", "x16", "x17");
> >+
> >+} while (r0 == QCOM_SCM_INTERRUPTED);
> >+
> >+if (ret1)
> >+*ret1 = r1;
> >+if (ret2)
> >+*ret2 = r2;
> >+if (ret3)
> >+*ret3 = r3;
> >+
> >+return r0;
> >+}
> >+
> >
>
> Here's a totally untested patch for that.
>
> Signed-off-by: Stephen Boyd
> 8<-
>
> diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
> index a95fd9b5d576..8f7e65ff524c 100644
> --- a/drivers/firmware/qcom_scm-64.c
> +++ b/drivers/firmware/qcom_scm-64.c
> @@ -114,6 +114,7 @@ int __qcom_scm_call_armv8_64(u64 x0, u64 x1, u64 x2, u64
> x3, u64 x4, u64 x5,
> register u64 r3 asm("r3") = x3;
> register u64 r4 asm("r4") = x4;
> register u64 r5 asm("r5") = x5;
> + register u64 r6 asm("r5") = 0;
> do {
> asm volatile(
> @@ -127,14 +128,15 @@ int __qcom_scm_call_armv8_64(u64 x0, u64 x1, u64 x2,
> u64 x3, u64 x4, u64 x5,
> __asmeq("%7", "x3")
> __asmeq("%8", "x4")
> __asmeq("%9", "x5")
> + __asmeq("%10", "x6")
> #ifdef REQUIRES_SEC
> ".arch_extension sec\n"
> #endif
> "smc#0\n"
> : "=r" (r0), "=r" (r1), "=r" (r2), "=r" (r3)
> : "r" (r0), "r" (r1), "r" (r2), "r" (r3), "r" (r4),
> - "r" (r5)
> - : "x6", "x7", "x8", "x9", "x10", "x11", "x12", "x13",
> + "r" (r5), "r" (r6)
> + : "x7", "x8", "x9", "x10", "x11",
Re: regression introduced by "block: Add support for DAX reads/writes to block devices"
On Wed, Aug 05, 2015 at 09:42:54PM -0400, Linda Knippers wrote: > On 08/05/2015 06:01 PM, Dave Chinner wrote: > > On Wed, Aug 05, 2015 at 04:19:08PM -0400, Jeff Moyer wrote: > >> Hi, Matthew, > >> > >> Linda Knippers noticed that commit (bbab37ddc20b) breaks mkfs.xfs: > >> > >> # mkfs -t xfs -f /dev/pmem0 > >> meta-data=/dev/pmem0 isize=256agcount=4, agsize=524288 blks > >> = sectsz=512 attr=2, projid32bit=1 > >> = crc=0finobt=0 > >> data = bsize=4096 blocks=2097152, imaxpct=25 > >> = sunit=0 swidth=0 blks > >> naming =version 2 bsize=4096 ascii-ci=0 ftype=0 > >> log =internal log bsize=4096 blocks=2560, version=2 > >> = sectsz=512 sunit=0 blks, lazy-count=1 > >> realtime =none extsz=4096 blocks=0, rtextents=0 > >> mkfs.xfs: read failed: Numerical result out of range > >> > >> I sat down with Linda to look into it, and the problem is that mkfs.xfs > >> sets the blocksize of the device to 512 (via BLKBSZSET), and then reads > >> from the last sector of the device. This results in dax_io trying to do > >> a page-sized I/O at 512 bytes from the end of the device. > > > > Right - we have to be able to do IO to that last sector, so this is > > a sanity check to tell if the block dev is large enough. The XFS > > kernel code does the same end-of-device sector read when the > > filesystem is mounted, too. > > > >> bdev_direct_access, receiving this bogus pos/size combo, returns > >> -ERANGE: > >> > >>if ((sector + DIV_ROUND_UP(size, 512)) > > >>part_nr_sects_read(bdev->bd_part)) > >>return -ERANGE; > >> > >> Given that file systems supporting dax refuse to mount with a blocksize > >> != page size, I'm guessing this is sort of expected behavior. However, > >> we really shouldn't be breaking direct I/O on pmem devices. > > > > If the device is advertising 512 byte sector size support, then this > > needs to work, especially as DAX is completely transparent on the > > block device. Remember that DAX through a filesystem works on > > filesystem data block size boundaries, so a 512 byte sector/4k block > > size filesystem will be able to use DAX for mmapped files just fine. > > > >> So, what do you want to do? We could make the pmem device's logical > >> block size fixed at the sytem page size. Or, we could modify the dax > >> code to work with blocksize < pagesize. Or, we could continue using the > >> direct I/O codepath for direct block device access. What do you think? > > > > I don't know how the pmem device sets up it's limits. Can you post > > the output of: > > > > /sys/block/pmem0/queue/logical_block_size > 512 > > > /sys/block/pmem0/queue/physical_block_size > 512 > > > /sys/block/pmem0/queue/hw_sector_size > 512 > > > /sys/block/pmem0/queue/minimum_io_size > 512 > > > /sys/block/pmem0/queue/optimal_io_size > 0 Ok, so the pmem device is advertising 512 bytes for both physical and logical sector sizes. That means mkfs.xfs is not doing anything wrong. i.e. ERANGE on w read of the last sector of the block device is a bug in the block device code. It is not at all obvious from these sector sizes that the block device is DAX enabled. I'd suggest that you probably want to make the physical sector size 4k on x86-64 to indicate to filesystem utilities that 4k alignment of the filesystem is preferred, even if 512 byte IO can be supported in a less efficient manner (i.e. equivalent of a 512e hard drive) You can't really make the logical sector size = PAGE_SIZE, because on 64k page size machines that will make the sector size larger than many filesystems support. e.g. XFS only supports sector sizes up to 32k at the moment... Cheers, Dave. -- Dave Chinner da...@fromorbit.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: [llvm-dev] [LLVMdev] Cc llvmdev: Re: llvm bpf debug info. Re: [RFC PATCH v4 3/3] bpf: Introduce function for outputing data to perf event
On Wed, Aug 05, 2015 at 04:28:13PM +0800, Wangnan (F) wrote: > > It doesn't work for me at first since in my llvm there's only > llvm.bpf.load.*. > > I think llvm.bpf.store.* belone to some patches you haven't posted yet? nope. only loads have special instructions ld_abs/ld_ind which are represented by these intrinsics. stores, so far, are done via single bpf_store_bytes() helper function. > >the typeid changing ids with order is surprising. > >I think the assertion in ExtractTypeInfo() is not hard. > >Just there were no such use cases. May be we can do something > >similar to what LowerIntrinsicCall() does and lower it differently > >in the backend. > > > But in backend can we still get type information? I thought type is > meaningful in frontend only, and backend behaviors is unable to affect > DWARF generation, right? why do we need to affect type generation? we just need to know dwarf type id in the backend, so we can emit it as a constant. I still think lowering eh_typeid_for differently may work. Like instead of doing GV = ExtractTypeInfo(I.getArgOperand(0)) followed by getMachineFunction().getMMI().getTypeIDFor(GV) we can get dwarf type id from I.getArgOperand(0) if it's any pointer to struct type. I'm not familiar with dwarf handling part of llvm, but feels possible. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/2] dma: Add Xilinx zynqmp dma engine driver support
Added the basic driver for zynqmp dma engine used in Zynq UltraScale+ MPSoC. The initial release of this driver supports only memory to memory transfers. Signed-off-by: Punnaiah Choudary Kalluri --- Changes in v4: - Modified the defines to start with ZYNQMP_DMA perfix - Changed the zynqmp_dma_alloc_chan_resources to return number of allocated descriptors - Changed the zynqmp_dma_device variable name - Released the locks before calling user callback - freeup irq in zynqmp_dma_chan_remove function. Changes in v3: - Modified the zynqmp_dma_chan_is_idle function return type to bool Changes in v2: - Corrected the function header documentation - Framework expects bus-width value in bytes. so, fixed it - Removed magic numbers for bus-width --- drivers/dma/Kconfig |6 + drivers/dma/xilinx/Makefile |1 + drivers/dma/xilinx/zynqmp_dma.c | 1247 +++ 3 files changed, 1254 insertions(+), 0 deletions(-) create mode 100644 drivers/dma/xilinx/zynqmp_dma.c diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig index 88d474b..e0bd309 100644 --- a/drivers/dma/Kconfig +++ b/drivers/dma/Kconfig @@ -425,6 +425,12 @@ config XILINX_VDMA channels, Memory Mapped to Stream (MM2S) and Stream to Memory Mapped (S2MM) for the data transfers. +config XILINX_ZYNQMP_DMA + tristate "Xilinx ZynqMP DMA Engine" + select DMA_ENGINE + help + Enable support for Xilinx ZynqMP DMA engine in Zynq UltraScale+ MPSoC. + config DMA_SUN6I tristate "Allwinner A31 SoCs DMA support" depends on MACH_SUN6I || MACH_SUN8I || COMPILE_TEST diff --git a/drivers/dma/xilinx/Makefile b/drivers/dma/xilinx/Makefile index 3c4e9f2..95469dc 100644 --- a/drivers/dma/xilinx/Makefile +++ b/drivers/dma/xilinx/Makefile @@ -1 +1,2 @@ obj-$(CONFIG_XILINX_VDMA) += xilinx_vdma.o +obj-$(CONFIG_XILINX_ZYNQMP_DMA) += zynqmp_dma.o diff --git a/drivers/dma/xilinx/zynqmp_dma.c b/drivers/dma/xilinx/zynqmp_dma.c new file mode 100644 index 000..93c51ac --- /dev/null +++ b/drivers/dma/xilinx/zynqmp_dma.c @@ -0,0 +1,1247 @@ +/* + * DMA driver for Xilinx ZynqMP DMA Engine + * + * Copyright (C) 2015 Xilinx, Inc. All rights reserved. + * + * This program is free software: you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation, either version 2 of the License, or + * (at your option) any later version. + */ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include "../dmaengine.h" + +/* Register Offsets */ +#define ZYNQMP_DMA_ISR 0x100 +#define ZYNQMP_DMA_IMR 0x104 +#define ZYNQMP_DMA_IER 0x108 +#define ZYNQMP_DMA_IDS 0x10C +#define ZYNQMP_DMA_CTRL0 0x110 +#define ZYNQMP_DMA_CTRL1 0x114 +#define ZYNQMP_DMA_STATUS 0x11C +#define ZYNQMP_DMA_DATA_ATTR 0x120 +#define ZYNQMP_DMA_DSCR_ATTR 0x124 +#define ZYNQMP_DMA_SRC_DSCR_WRD0 0x128 +#define ZYNQMP_DMA_SRC_DSCR_WRD1 0x12C +#define ZYNQMP_DMA_SRC_DSCR_WRD2 0x130 +#define ZYNQMP_DMA_SRC_DSCR_WRD3 0x134 +#define ZYNQMP_DMA_DST_DSCR_WRD0 0x138 +#define ZYNQMP_DMA_DST_DSCR_WRD1 0x13C +#define ZYNQMP_DMA_DST_DSCR_WRD2 0x140 +#define ZYNQMP_DMA_DST_DSCR_WRD3 0x144 +#define ZYNQMP_DMA_SRC_START_LSB 0x158 +#define ZYNQMP_DMA_SRC_START_MSB 0x15C +#define ZYNQMP_DMA_DST_START_LSB 0x160 +#define ZYNQMP_DMA_DST_START_MSB 0x164 +#define ZYNQMP_DMA_TOTAL_BYTE 0x188 +#define ZYNQMP_DMA_RATE_CTRL 0x18C +#define ZYNQMP_DMA_IRQ_SRC_ACCT0x190 +#define ZYNQMP_DMA_IRQ_DST_ACCT0x194 +#define ZYNQMP_DMA_CTRL2 0x200 + +/* Interrupt registers bit field definitions */ +#define ZYNQMP_DMA_DONEBIT(10) +#define ZYNQMP_DMA_AXI_WR_DATA BIT(9) +#define ZYNQMP_DMA_AXI_RD_DATA BIT(8) +#define ZYNQMP_DMA_AXI_RD_DST_DSCR BIT(7) +#define ZYNQMP_DMA_AXI_RD_SRC_DSCR BIT(6) +#define ZYNQMP_DMA_IRQ_DST_ACCT_ERRBIT(5) +#define ZYNQMP_DMA_IRQ_SRC_ACCT_ERRBIT(4) +#define ZYNQMP_DMA_BYTE_CNT_OVRFL BIT(3) +#define ZYNQMP_DMA_DST_DSCR_DONE BIT(2) +#define ZYNQMP_DMA_INV_APB BIT(0) + +/* Control 0 register bit field definitions */ +#define ZYNQMP_DMA_OVR_FETCH BIT(7) +#define ZYNQMP_DMA_POINT_TYPE_SG BIT(6) +#define ZYNQMP_DMA_RATE_CTRL_ENBIT(3) + +/* Control 1 register bit field definitions */ +#define ZYNQMP_DMA_SRC_ISSUE GENMASK(4, 0) + +/* Channel status register bit field definitions */ +#define ZYNQMP_DMA_STATUS_BUSY 0x2 + +/* Data Attribute register bit field definitions */ +#define ZYNQMP_DMA_ARBURST GENMASK(27, 26) +#define ZYNQMP_DMA_ARCACHE GENMASK(25, 22)
[PATCH v4 1/2] Documentation: dt: Add Xilinx zynqmp dma device tree binding documentation
Device-tree binding documentation for Xilinx zynqmp dma engine used in
Zynq UltraScale+ MPSoC.
Signed-off-by: Punnaiah Choudary Kalluri
---
Changes in v4:
- None
Changes in v3:
- None
Changes in v2:
- None
---
.../devicetree/bindings/dma/xilinx/zynqmp_dma.txt | 61
1 files changed, 61 insertions(+), 0 deletions(-)
create mode 100644 Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
new file mode 100644
index 000..e4f92b9
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt
@@ -0,0 +1,61 @@
+Xilinx ZynqMP DMA engine, it does support memory to memory transfers,
+memory to device and device to memory transfers. It also has flow
+control and rate control support for slave/peripheral dma access.
+
+Required properties:
+- compatible: Should be "xlnx,zynqmp-dma-1.0"
+- #dma-cells: Should be <1>, a single cell holding a line request number
+- reg: Memory map for module access
+- interrupt-parent: Interrupt controller the interrupt is routed through
+- interrupts: Should contain DMA channel interrupt
+- xlnx,bus-width: AXI buswidth in bits. Should contain 128 or 64
+
+Optional properties:
+- xlnx,include-sg: Indicates the controller to operate in simple or scatter
+ gather dma mode
+- xlnx,ratectrl: Scheduling interval in terms of clock cycles for
+source AXI transaction
+- xlnx,overfetch: Tells whether the channel is allowed to over fetch the data
+- xlnx,src-issue: Number of AXI outstanding transactions on source side
+- xlnx,desc-axi-cohrnt: Tells whether the AXI transactions generated for the
+ descriptor read are marked Non-coherent
+- xlnx,src-axi-cohrnt: Tells whether the AXI transactions generated for the
+ source descriptor payload are marked Non-coherent
+- xlnx,dst-axi-cohrnt: Tells whether the AXI transactions generated for the
+ dst descriptor payload are marked Non-coherent
+- xlnx,desc-axi-qos: AXI QOS bits to be used for descriptor fetch
+- xlnx,src-axi-qos: AXI QOS bits to be used for data read
+- xlnx,dst-axi-qos: AXI QOS bits to be used for data write
+- xlnx,desc-axi-cache: AXI cache bits to be used for descriptor fetch.
+- xlnx,desc-axi-cache: AXI cache bits to be used for data read
+- xlnx,desc-axi-cache: AXI cache bits to be used for data write
+- xlnx,src-burst-len: AXI length for data read. Support only power of 2 values
+ i.e 1,2,4,8 and 16
+- xlnx,dst-burst-len: AXI length for data write. Support only power of 2 values
+ i.e 1,2,4,8 and 16
+
+Example:
+
+fpd_dma_chan1: dma@FD50 {
+ compatible = "xlnx,zynqmp-dma-1.0";
+ reg = <0x0 0xFD50 0x1000>;
+ #dma_cells = <1>;
+ interrupt-parent = <>;
+ interrupts = <0 117 4>;
+ xlnx,bus-width = <128>;
+ xlnx,include-sg;
+ xlnx,overfetch;
+ xlnx,ratectrl = <0>;
+ xlnx,src-issue = <16>;
+ xlnx,desc-axi-cohrnt;
+ xlnx,src-axi-cohrnt;
+ xlnx,dst-axi-cohrnt;
+ xlnx,desc-axi-qos = <0>;
+ xlnx,desc-axi-cache = <0>;
+ xlnx,src-axi-qos = <0>;
+ xlnx,src-axi-cache = <2>;
+ xlnx,dst-axi-qos = <0>;
+ xlnx,dst-axi-cache = <2>;
+ xlnx,src-burst-len = <4>;
+ xlnx,dst-burst-len = <4>;
+};
--
1.7.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 3/3] PowerPC/mpc85xx: Add hotplug support on E6500 cores
On Wed, 2015-08-05 at 19:08 +0800, Chenhui Zhao wrote:
> On Sat, Aug 1, 2015 at 8:22 AM, Scott Wood
> wrote:
> > On Fri, 2015-07-31 at 17:20 +0800, b29983@freescale.comwrote:
> > > + /*
> > > + * If both threads are offline, reset core to start.
> > > + * When core is up, Thread 0 always gets up first,
> > > + * so bind the current logical cpu with Thread 0.
> > > + */
> > > + if (hw_cpu != cpu_first_thread_sibling(hw_cpu)) {
> > > + int hw_cpu1, hw_cpu2;
> > > +
> > > + hw_cpu1 = get_hard_smp_processor_id(primary);
> > > + hw_cpu2 = get_hard_smp_processor_id(primary +
> > > 1);
> > > + set_hard_smp_processor_id(primary, hw_cpu2);
> > > + set_hard_smp_processor_id(primary + 1,
> > > hw_cpu1);
> > > + /* get new physical cpu id */
> > > + hw_cpu = get_hard_smp_processor_id(nr);
> >
> > NACK as discussed in http://patchwork.ozlabs.org/patch/454944/
> >
> > -Scott
>
> You said,
>
> There's no need for this. I have booting from a thread1, and having
> it
> kick its thread0, working locally without messing with the hwid/cpu
> mapping.
>
> I still have questions here. After a core reset, how can you boot
> Thread1
> of the core first. As I know, Thread0 boots up first by default.
So the issue isn't that thread1 comes up first, but that you *want* thread1
to come up first and it won't. I don't think this remapping is an acceptable
answer, though. Instead, if you need only thread1 to come up, start the
core, have thread0 start thread1, and then send thread0 into whatever waiting
state it would be in if thread1 had never been offlined.
-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: [RFC v4] genalloc:support memory-allocation with bytes-alignment to genalloc
On Wed, 2015-08-05 at 14:50 +0800, Zhao Qiang wrote: > Bytes alignment is required to manage some special RAM, > so add gen_pool_first_fit_align to genalloc, > meanwhile add gen_pool_alloc_data to pass data to > gen_pool_first_fit_align(modify gen_pool_alloc as a wrapper) > > Signed-off-by: Zhao Qiang > --- > *v2: > changes: > title has been modified, original patch link: > http://patchwork.ozlabs.org/patch/493297/ > > original patch add a func gen_pool_alloc_align, > then pass alignment to it as an parameter. > after discussing with lauraa and scott, they recommend > to pass alignment as part of data based on > commit message for ca279cf1065fb689abea1dc7d8c11787729bb185 which adds > "data": > > "As I can't predict all the possible requirements/needs for all allocation > > uses cases, I add a "free" field 'void *data' to pass any needed > information to the allocation function. For example 'data' could be used > > to handle a structure where you store the alignment, the expected memory > bank, the requester device, or any information that could influence the > allocation algorithm." > > *v3: > changes: > title has been modified, original patch link: > http://patchwork.ozlabs.org/patch/500317/ > > according to the comments, add gen_pool_alloc_data, > modify gen_pool_alloc as a wrapper, define struct data_align > for gen_pool_first_fit_align algorithm. add parameter > pointer pool to algorithm. > > *v4: > changes: > v3 link: > http://patchwork.ozlabs.org/patch/500317/ > There are comments for v3, according to the comments, > modify the patch for v4. such as modifying annotations, > removing unnecessary chek, removing unnecessary cast and so on. > > include/linux/genalloc.h | 23 +++ > lib/genalloc.c | 58 +++-- > --- > 2 files changed, 72 insertions(+), 9 deletions(-) > Looks good to me (except a minor change to the comments described below); send a non-RFC patch with the patches that use it. > @@ -500,15 +518,42 @@ EXPORT_SYMBOL(gen_pool_set_algo); > * @start: The bitnumber to start searching at > * @nr: The number of zeroed bits we're looking for > * @data: additional data - unused > + * @pool: unused, but the algorithm functions have same format. > */ Describe what pool actually is. Whether it's used is irrelevant (and you can assume the reader knows that all algorithm functions have the same signature). @data is different because it's defined per-algorithm and thus unused means no definition. In other words, the purpose of these headers is to be a guide to the caller of the function, describing the API, not the function internals. -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 v3 3/8] soc: Mediatek: Add SCPSYS CPU power domain driver
On Wed, 2015-08-05 at 10:50 +0200, Sascha Hauer wrote:
> On Tue, Aug 04, 2015 at 09:54:19PM +0800, Scott Shu wrote:
> > This adds a CPU power domain driver for the Mediatek SCPSYS unit on
> > MT6580.
> >
> > Signed-off-by: Scott Shu
> > ---
> > drivers/soc/mediatek/mtk-scpsys.c | 250
> > +++
> > include/linux/soc/mediatek/scpsys.h |9 ++
> > 2 files changed, 259 insertions(+)
> > create mode 100644 include/linux/soc/mediatek/scpsys.h
> >
> > diff --git a/drivers/soc/mediatek/mtk-scpsys.c
> > b/drivers/soc/mediatek/mtk-scpsys.c
> > index 43a79ed..ca0f2dd 100644
> > --- a/drivers/soc/mediatek/mtk-scpsys.c
> > +++ b/drivers/soc/mediatek/mtk-scpsys.c
> > @@ -15,18 +15,30 @@
> > #include
> > #include
> > #include
> > +#include
> > #include
> > +#include
> > #include
> > #include
> > #include
> > #include
> > +#include
> > #include
> >
> > +#define SPM_POWERON_CONFIG_SET 0x
> > +#define SPM_CA7_CPU0_PWR_CON 0x0200
> > #define SPM_VDE_PWR_CON0x0210
> > #define SPM_MFG_PWR_CON0x0214
> > +#define SPM_CA7_CPU1_PWR_CON 0x0218
> > +#define SPM_CA7_CPU2_PWR_CON 0x021c
> > +#define SPM_CA7_CPU3_PWR_CON 0x0220
> > #define SPM_VEN_PWR_CON0x0230
> > #define SPM_ISP_PWR_CON0x0238
> > #define SPM_DIS_PWR_CON0x023c
> > +#define SPM_CA7_CPU0_L1_PDN0x025c
> > +#define SPM_CA7_CPU1_L1_PDN0x0264
> > +#define SPM_CA7_CPU2_L1_PDN0x026c
> > +#define SPM_CA7_CPU3_L1_PDN0x0274
> > #define SPM_VEN2_PWR_CON 0x0298
> > #define SPM_AUDIO_PWR_CON 0x029c
> > #define SPM_MFG_2D_PWR_CON 0x02c0
> > @@ -34,12 +46,20 @@
> > #define SPM_USB_PWR_CON0x02cc
> > #define SPM_PWR_STATUS 0x060c
> > #define SPM_PWR_STATUS_2ND 0x0610
> > +#define SPM_SLEEP_TIMER_STA0x0720
> >
> > +/* bit definition in SPM_CA7_CPUx_PWR_CON */
> > #define PWR_RST_B_BIT BIT(0)
> > #define PWR_ISO_BITBIT(1)
> > #define PWR_ON_BIT BIT(2)
> > #define PWR_ON_2ND_BIT BIT(3)
> > #define PWR_CLK_DIS_BITBIT(4)
> > +#define SRAM_CKISO_BIT BIT(5)
> > +#define SRAM_ISOINT_B_BIT BIT(6)
> > +
> > +/* bit definition in SPM_CA7_CPUx_L1_PDN */
> > +#define L1_PDN BIT(0)
> > +#define L1_PDN_ACK BIT(8)
> >
> > #define PWR_STATUS_DISPBIT(3)
> > #define PWR_STATUS_MFG BIT(4)
> > @@ -52,6 +72,28 @@
> > #define PWR_STATUS_AUDIO BIT(24)
> > #define PWR_STATUS_USB BIT(25)
> >
> > +#define MT6580_MAX_CPUS4
> > +
> > +#ifdef CONFIG_SMP
> > +static DEFINE_SPINLOCK(spm_cpu_lock);
> > +
> > +static void __iomem *spm_cpu_base;
> > +
> > +static const u32 spm_cpu_pwr_con[MT6580_MAX_CPUS] = {
> > + SPM_CA7_CPU0_PWR_CON,
> > + SPM_CA7_CPU1_PWR_CON,
> > + SPM_CA7_CPU2_PWR_CON,
> > + SPM_CA7_CPU3_PWR_CON,
> > +};
> > +
> > +static const u32 spm_cpu_l1_pdn[MT6580_MAX_CPUS] = {
> > + SPM_CA7_CPU0_L1_PDN,
> > + SPM_CA7_CPU1_L1_PDN,
> > + SPM_CA7_CPU2_L1_PDN,
> > + SPM_CA7_CPU3_L1_PDN,
> > +};
> > +#endif
> > +
> > enum clk_id {
> > MT8173_CLK_MM,
> > MT8173_CLK_MFG,
> > @@ -485,3 +527,211 @@ static struct platform_driver scpsys_drv = {
> > };
> >
> > module_platform_driver_probe(scpsys_drv, scpsys_probe);
> > +
> > +#define SPM_REGWR_EN BIT(0)
> > +#define SPM_PROJECT_CODE 0x0B16
> > +
> > +#ifdef CONFIG_SMP
> > +int spm_cpu_mtcmos_on(int cpu)
>
> The idea was that the code that the current driver has in
> scpsys_power_on/scpsys_power_off is shared with this function. If we
> don't do this then it indeed doesn't make much sense to put it into the
> same file.
>
> From what I see we would need to change the prototype to something like
>
> static int __scpsys_power_on(struct scp_domain_data *)
>
> (maybe with some additional base addresses and stuff)
>
> struct scp_domain_data would additionally need sram_isoint_b and sram_ckiso
> members.
>
> Sascha
>
Hi Sascha,
The CPU power sequence is quite different with the others, as
described below.
* Non-CPU
1) Set PWR_ON_BIT, PWR_ON_2ND_BIT
2) Wait PWR_ACK
3) Clear PWR_CLK_DIS_BIT
4) Clear PWR_ISO_BIT
5) Set PWR_RST_B_BIT
6) Clear SRAM_PDN
7) Wait SRAM_PDN_ACK
* CPU
1) Set PWR_ON_BIT, PWR_ON_2ND_BIT
2) Wait PWR_ACK
3) Clear PWR_ISO_BIT
4) Clear L1_PDN to power on L1
5) Wait L1_PDN_ACK
6) Set SRAM_ISOINT_B
7) Clear SRAM_CKISO
8) Clear PWR_CLK_DIS
9) Set PWR_RST_B
For multi-cluster SoC, the cluster power sequence is also different.
Please think if this is a good idea if we integrate the CPU
Re: [PATCH v2 8/9] KVM: MMU: fully check zero bits for sptes
On 08/05/2015 06:12 PM, Paolo Bonzini wrote:
On 05/08/2015 06:04, Xiao Guangrong wrote:
- for_each_shadow_entry_lockless(vcpu, addr, iterator, spte)
+ for_each_shadow_entry_lockless(vcpu, addr, iterator, spte) {
+ leaf = iterator.level;
+
+ if (!root)
+ root = leaf;
+
+ sptes[leaf - 1] = spte;
+
I'm a bit undecided between this and open-coding the macro:
for (shadow_walk_init(, vcpu, addr), root = iterator.level;
shadow_walk_okay();
__shadow_walk_next(, spte)) {
leaf = iterator.level;
spte = mmu_spte_get_lockless(iterator.sptep);
Any second opinions?
Your adjustment is good to me, i do not 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: linux-next: build failure after merge of the slave-dma tree
On Thu, Aug 06, 2015 at 12:22:03PM +1000, Stephen Rothwell wrote:
> Hi Vinod,
>
> After merging the slave-dma tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/dma/at_hdmac.c: In function 'atc_prep_dma_memset':
> drivers/dma/at_hdmac.c:960:6: error: 'struct at_desc' has no member named
> 'tx_width'
> desc->tx_width = 2;
> ^
>
> Caused by commit
>
> 25fed8c2fff1 ("dmaengine: hdmac: Add memset capabilities")
>
> interacting with commit
>
> 93dce3a6434f ("dmaengine: at_hdmac: fix residue computation")
Thanks Stephen,
I am dropping this commit now, it need to be fixed to take into account
Cyrille work on remove tx_width and this patch should be updated to reflect
that
--
~Vinod
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] Powerpc: mpc85xx: refactor the PM operations
On Wed, 2015-08-05 at 18:11 +0800, Chenhui Zhao wrote: > On Tue, Aug 4, 2015 at 4:26 AM, Scott Wood > wrote: > > 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? > > Setting these bits can mask interrupts signalled to RCPM from MPIC as a > means of > waking up from a lower power state. So, cores will not be waked up > unexpectedly. Why would the MPIC be signalling those interrupts if they've been masked at the MPIC? -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] Documentation: add new description of path-name lookup.
On 08/05/15 19:54, NeilBrown wrote: > On Sun, 26 Jul 2015 20:41:52 -0700 Randy Dunlap > wrote: > >> On 07/24/15 17:28, NeilBrown wrote: >>> >> >> Hi Neil, >> >> Some edits for you to consider. > > Wow, thanks. I think I agree with all ... had to do some research for > "neither is" though. > >> >>> +However, there is a little bit more to seqlocks than that. If >>> +RCU-walk accesses two different fields in a seqlock-protected >>> +structure, or accesses the same field twice, there is no a-priori >> >> no hyphen: ^ > > Do you have an opinion on where I should but "a priori" in italics? > I feel there needs to be something to make it clear the "a" is not an > English "a". I don't think that italics are needed for that. > Jon: do you want an incremental patch, or a resend? -- ~Randy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] Documentation: add new description of path-name lookup.
On Sun, 26 Jul 2015 20:41:52 -0700 Randy Dunlap wrote: > On 07/24/15 17:28, NeilBrown wrote: > > > > Hi Neil, > > Some edits for you to consider. Wow, thanks. I think I agree with all ... had to do some research for "neither is" though. > > > +However, there is a little bit more to seqlocks than that. If > > +RCU-walk accesses two different fields in a seqlock-protected > > +structure, or accesses the same field twice, there is no a-priori > > no hyphen: ^ Do you have an opinion on where I should but "a priori" in italics? I feel there needs to be something to make it clear the "a" is not an English "a". Jon: do you want an incremental patch, or a resend? Thanks, NeilBrown -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 v6 3/4] bpf: Implement function bpf_perf_event_read() that get the selected hardware PMU conuter
于 2015/8/5 21:53, Peter Zijlstra 写道:
> On Wed, Aug 05, 2015 at 12:04:25PM +0200, Peter Zijlstra wrote:
>> Also, you probably want a WARN_ON(in_nmi()) there, this function is
>> _NOT_ NMI safe.
>
> I had a wee think about that, and I think the below is safe.
>
> (with the obvious problem that WARN from NMI context is not safe)
>
> It does not give you up-to-date overcommit times but your version didn't
> either so I'm assuming you don't need those, if you do need those it
> needs more but we can do that too.
>
> ---
> include/linux/perf_event.h | 1 +
> kernel/events/core.c | 53
> ++
> 2 files changed, 54 insertions(+)
>
> diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
> index 2027809433b3..64e821dd64f0 100644
> --- a/include/linux/perf_event.h
> +++ b/include/linux/perf_event.h
> @@ -659,6 +659,7 @@ perf_event_create_kernel_counter(struct perf_event_attr
> *attr,
> void *context);
> extern void perf_pmu_migrate_context(struct pmu *pmu,
> int src_cpu, int dst_cpu);
> +extern u64 perf_event_read_local(struct perf_event *event);
> extern u64 perf_event_read_value(struct perf_event *event,
>u64 *enabled, u64 *running);
>
> diff --git a/kernel/events/core.c b/kernel/events/core.c
> index 39753bfd9520..7105d37763c1 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -3222,6 +3222,59 @@ static inline u64 perf_event_count(struct perf_event
> *event)
> return __perf_event_count(event);
> }
>
> +/*
> + * NMI-safe method to read a local event, that is an event that
> + * is:
> + * - either for the current task, or for this CPU
> + * - does not have inherit set, for inherited task events
> + * will not be local and we cannot read them atomically
> + * - must not have a pmu::count method
> + */
> +u64 perf_event_read_local(struct perf_event *event)
> +{
> + unsigned long flags;
> + u64 val;
> +
> + /*
> + * Disabling interrupts avoids all counter scheduling (context
> + * switches, timer based rotation and IPIs).
> + */
> + local_irq_safe(flags);
s/local_irq_safe/local_irq_save, and I have compiled and tested this function
and it is fine. Will use it in the next set.
Thanks.
> +
> + /* If this is a per-task event, it must be for current */
> + WARN_ON_ONCE((event->attach_state & PERF_ATTACH_TASK) &&
> + event->hw.target != current);
> +
> + /* If this is a per-CPU event, it must be for this CPU */
> + WARN_ON_ONCE(!(event->attach_state & PERF_ATTACH_TASK) &&
> + event->cpu != smp_processor_id());
> +
> + /*
> + * It must not be an event with inherit set, we cannot read
> + * all child counters from atomic context.
> + */
> + WARN_ON_ONCE(event->attr.inherit);
> +
> + /*
> + * It must not have a pmu::count method, those are not
> + * NMI safe.
> + */
> + WARN_ON_ONCE(event->pmu->count);
> +
> + /*
> + * If the event is currently on this CPU, its either a per-task event,
> + * or local to this CPU. Furthermore it means its ACTIVE (otherwise
> + * oncpu == -1).
> + */
> + if (event->oncpu == smp_processor_id())
> + event->pmu->read(event);
> +
> + val = local64_read(>count);
> + local_irq_restore(flags);
> +
> + return val;
> +}
> +
> static u64 perf_event_read(struct perf_event *event)
> {
> /*
>
> .
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] Re: [PATCH] Input: axp20x-pek: Add module alias
On Wed, Aug 5, 2015 at 1:46 AM, Dmitry Torokhov
wrote:
> On Tue, Aug 04, 2015 at 05:04:55PM +0800, Chen-Yu Tsai wrote:
>> On Tue, Aug 4, 2015 at 4:42 PM, Paul Bolle wrote:
>> > On ma, 2015-08-03 at 15:48 +0800, 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
>> >
>> >> --- a/drivers/input/misc/axp20x-pek.c
>> >> +++ b/drivers/input/misc/axp20x-pek.c
>> >
>> >> +MODULE_ALIAS("platform:axp20x-pek");
>> >
>> > Should this eventually go into stable?
>> >
>> > The AXP20x Power Enable Key driver was added in v4.0, so this patch
>> > could currently be relevant for the v4.1.y tree. (In that tree a "parent
>> > MFD driver" appears to be present too.)
>>
>> (Since I forgot to add the stable tag,) I can submit it for inclusion
>> into stable after it's merged into Linus' tree.
>
> OTOH do we have many general users needing this driver as a
> automatically loaded module? If not that many then it is OK to just
> merge it in mainline and skip stable.
This is a driver for the power button found on most sunxi devices.
I assume distros would build this as a module, and most normal users
would want the power button to work out of the box.
ChenYu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH RESEND] regmap: debugfs: Fix misuse of IS_ENABLED
IS_ENABLED should only be used for CONFIG_* symbols.
I have done a small test:
#define REGMAP_ALLOW_WRITE_DEBUGFS
IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS) returns 0.
#define REGMAP_ALLOW_WRITE_DEBUGFS 0
IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS) returns 0.
#define REGMAP_ALLOW_WRITE_DEBUGFS 1
IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS) returns 1.
#define REGMAP_ALLOW_WRITE_DEBUGFS 2
IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS) returns 0.
So fix the misuse of IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS) and switch to
use #if defined(REGMAP_ALLOW_WRITE_DEBUGFS) instead.
Signed-off-by: Axel Lin
---
Sorry, just found a typo in subject line immediately after sent the path.
s/regamp/regmap/ So here is a resend.
drivers/base/regmap/regmap-debugfs.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/base/regmap/regmap-debugfs.c
b/drivers/base/regmap/regmap-debugfs.c
index 6a61e4f..f42f2ba 100644
--- a/drivers/base/regmap/regmap-debugfs.c
+++ b/drivers/base/regmap/regmap-debugfs.c
@@ -599,10 +599,11 @@ void regmap_debugfs_init(struct regmap *map, const char
*name)
if (map->max_register || regmap_readable(map, 0)) {
umode_t registers_mode;
- if (IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS))
- registers_mode = 0600;
- else
- registers_mode = 0400;
+#if defined(REGMAP_ALLOW_WRITE_DEBUGFS)
+ registers_mode = 0600;
+#else
+ registers_mode = 0400;
+#endif
debugfs_create_file("registers", registers_mode, map->debugfs,
map, _map_fops);
--
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/
Re: [PATCH v2 2/2] powerpc32: optimise csum_partial() loop
On Wed, 2015-08-05 at 19:30 -0500, Segher Boessenkool wrote: > On Wed, Aug 05, 2015 at 03:29:35PM +0200, Christophe Leroy wrote: > > On the 8xx, load latency is 2 cycles and taking branches also takes > > 2 cycles. So let's unroll the loop. > > This is not true for most other 32-bit PowerPC; this patch makes > performance worse on e.g. 6xx/7xx/7xxx. Let's not! Chips with a load latency greater than 2 cycles should also benefit from the unrolling. Have you benchmarked this somewhere and seen it reduce performance? Do you know of any 32-bit PPC chips with a load latency less than 2 cycles? -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/
[PATCH] regamp: debugfs: Fix misuse of IS_ENABLED
IS_ENABLED should only be used for CONFIG_* symbols.
I have done a small test:
#define REGMAP_ALLOW_WRITE_DEBUGFS
IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS) returns 0.
#define REGMAP_ALLOW_WRITE_DEBUGFS 0
IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS) returns 0.
#define REGMAP_ALLOW_WRITE_DEBUGFS 1
IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS) returns 1.
#define REGMAP_ALLOW_WRITE_DEBUGFS 2
IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS) returns 0.
So fix the misuse of IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS) and switch to
use #if defined(REGMAP_ALLOW_WRITE_DEBUGFS) instead.
Signed-off-by: Axel Lin
---
drivers/base/regmap/regmap-debugfs.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/base/regmap/regmap-debugfs.c
b/drivers/base/regmap/regmap-debugfs.c
index 6a61e4f..f42f2ba 100644
--- a/drivers/base/regmap/regmap-debugfs.c
+++ b/drivers/base/regmap/regmap-debugfs.c
@@ -599,10 +599,11 @@ void regmap_debugfs_init(struct regmap *map, const char
*name)
if (map->max_register || regmap_readable(map, 0)) {
umode_t registers_mode;
- if (IS_ENABLED(REGMAP_ALLOW_WRITE_DEBUGFS))
- registers_mode = 0600;
- else
- registers_mode = 0400;
+#if defined(REGMAP_ALLOW_WRITE_DEBUGFS)
+ registers_mode = 0600;
+#else
+ registers_mode = 0400;
+#endif
debugfs_create_file("registers", registers_mode, map->debugfs,
map, _map_fops);
--
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/
Re: [PATCH v2 1/3] cgroup: define controller file conventions
On 2015/08/05 16:47, Michal Hocko wrote: On Wed 05-08-15 09:39:40, KAMEZAWA Hiroyuki wrote: [...] so, for memory controller, we'll have We currently have only current, low, high, max and events currently. All other knobs are either deprecated or waiting for a usecase to emerge before they get added. Sure. I think following has users. - *.stat - for chekcing health of cgroup ,or for debug - *.pressure_level - for notifying memory pressure - *.swappiness - for adjusting LRU activity per application type. - *.oom_control - for surviving/notifiyng out of memory memcg's oom can be recovered if limit goes up rather than kill. But I know people says this knob is not useful. This will require discussion. Hm. If we don't want to increase files, NETLINK or systemcall is an another choice of subsystem specific interface ? -Kame (in alphabet order) memory.failcnt memory.force_empty (<= should this be removed ?) memory.kmem.failcnt memory.kmem.max memory.kmem.max_usage memory.kmem.slabinfo memory.kmem.tcp.failcnt memory.kmem.tcp.max memory.kmem.tcp.max_usage memory.kmem.tcp.usage memory.kmem.usage memory.max memory.max_usage memory.move_charge_at_immigrate memory.numa_stat memory.oom_control memory.pressure_level memory.high memory.swapiness memory.usage memory.use_hierarchy (<= removed) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] PCI: Only enable IO window if supported
On 08/05/2015 06:38 PM, Yinghai Lu wrote: On Wed, Aug 5, 2015 at 6:14 PM, Yinghai Lu wrote: It only can avoid warning with bridge, and still have warning on devices under the bridge. also would have problem on transparent bridges, like BRIDGE_A BRIDGE_AADEVICE_AA | \-- BRIDGE_AB ---DEVICE_AB if only BRIDGE_A and BRIDGE_AA are transparent, and BRIDGE_AB is not. and if pci_bridge_supports_io() return false for BRIDGE_A. We will have all three bridges have PCI_BUS_FLAGS_SUPPORTS_IO cleared. so all will not been sized and will not get assigned io port resource. later DEVICE_AA could root bus io port as parent, and get io resource assigned. but DEVICE_AB will not get assigned. so we should get rid of pci_bridge_supports_io(), and just check root resource IO port. I would suggest this version instead: Subject: [PATCH] PCI: Only try to assign io port only if root bus support that Bjorn had asked me to move the IO support check out of pci_bridge_check_ranges(). It looks like you want to keep it there. Can you explain your reasons ? Sorry, I just don't understand. Guenter -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
linux-next: build failure after merge of the slave-dma tree
Hi Vinod,
After merging the slave-dma tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/dma/at_hdmac.c: In function 'atc_prep_dma_memset':
drivers/dma/at_hdmac.c:960:6: error: 'struct at_desc' has no member named
'tx_width'
desc->tx_width = 2;
^
Caused by commit
25fed8c2fff1 ("dmaengine: hdmac: Add memset capabilities")
interacting with commit
93dce3a6434f ("dmaengine: at_hdmac: fix residue computation")
>From Linus' tree (v4.2-rc5). This should have been fixed up in commit
fa362949e874 ("Merge branch 'for-linus' into next")
I have used the slave-dma tree from next-20150805 for today.
--
Cheers,
Stephen Rothwells...@canb.auug.org.au
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] smaps: fill missing fields for vma(VM_HUGETLB)
On Tue, 4 Aug 2015, Jörn Engel wrote: > > From: Naoya Horiguchi > > Subject: [PATCH] smaps: fill missing fields for vma(VM_HUGETLB) > > > > Currently smaps reports many zero fields for vma(VM_HUGETLB), which is > > inconvenient when we want to know per-task or per-vma base hugetlb usage. > > This patch enables these fields by introducing smaps_hugetlb_range(). > > > > before patch: > > > > Size: 20480 kB > > Rss: 0 kB > > Pss: 0 kB > > Shared_Clean: 0 kB > > Shared_Dirty: 0 kB > > Private_Clean: 0 kB > > Private_Dirty: 0 kB > > Referenced:0 kB > > Anonymous: 0 kB > > AnonHugePages: 0 kB > > Swap: 0 kB > > KernelPageSize: 2048 kB > > MMUPageSize:2048 kB > > Locked:0 kB > > VmFlags: rd wr mr mw me de ht > > > > after patch: > > > > Size: 20480 kB > > Rss: 18432 kB > > Pss: 18432 kB > > Shared_Clean: 0 kB > > Shared_Dirty: 0 kB > > Private_Clean: 0 kB > > Private_Dirty: 18432 kB > > Referenced:18432 kB > > Anonymous: 18432 kB > > AnonHugePages: 0 kB > > Swap: 0 kB > > KernelPageSize: 2048 kB > > MMUPageSize:2048 kB > > Locked:0 kB > > VmFlags: rd wr mr mw me de ht > > Nice! > Hmm, wouldn't this be confusing since VmRSS in /proc/pid/status doesn't match the rss shown in smaps, since hugetlb mappings aren't accounted in get_mm_rss()? Not sure this is a good idea, I think consistency amongst rss values would be more important.
RE: [PATCH v3] virt: IRQ bypass manager
> -Original Message- > From: Alex Williamson [mailto:alex.william...@redhat.com] > Sent: Thursday, August 06, 2015 6:08 AM > To: linux-kernel@vger.kernel.org; k...@vger.kernel.org > Cc: eric.au...@st.com; eric.au...@linaro.org; j...@8bytes.org; > avi.kiv...@gmail.com; pbonz...@redhat.com; Wu, Feng > Subject: [PATCH v3] virt: IRQ bypass manager > > When a physical I/O device is assigned to a virtual machine through > facilities like VFIO and KVM, the interrupt for the device generally > bounces through the host system before being injected into the VM. > However, hardware technologies exist that often allow the host to be > bypassed for some of these scenarios. Intel Posted Interrupts allow > the specified physical edge interrupts to be directly injected into a > guest when delivered to a physical processor while the vCPU is > running. ARM IRQ Forwarding allows forwarded physical interrupts to > be directly deactivated by the guest. > > The IRQ bypass manager here is meant to provide the shim to connect > interrupt producers, generally the host physical device driver, with > interrupt consumers, generally the hypervisor, in order to configure > these bypass mechanism. To do this, we base the connection on a > shared, opaque token. For KVM-VFIO this is expected to be an > eventfd_ctx since this is the connection we already use to connect an > eventfd to an irqfd on the in-kernel path. When a producer and > consumer with matching tokens is found, callbacks via both registered > participants allow the bypass facilities to be automatically enabled. > > Signed-off-by: Alex Williamson > --- > > v3: Fix list_for_each_entry issue noted by Eric > > Do we want to revisit whether add and del are required callbacks? > Maybe they should only be required for the consumer? If Feng already > doesn't require them for Intel PI, let's not impose stub callback > requirements. Since both irq_bypass_register_producer() and irq_bypass_register_consumer() call __connect(), which then calls add_consumer() and add_producer(), only providing the add/del callbacks for 'struct irq_bypass_consumer' is fine to me. Thanks! BTW, could you please have a look at the common part patches v4 sent by Eric: [PATCH v4 0/5] KVM: irqfd consumer based on IRQ bypass manager If it looks fine to your guys, we can continue for the arch specific work, thank you! Thanks, Feng > > MAINTAINERS |7 + > include/linux/irqbypass.h | 90 > virt/lib/Kconfig |2 > virt/lib/Makefile |1 > virt/lib/irqbypass.c | 256 > + > 5 files changed, 356 insertions(+) > create mode 100644 include/linux/irqbypass.h > create mode 100644 virt/lib/Kconfig > create mode 100644 virt/lib/Makefile > create mode 100644 virt/lib/irqbypass.c > > diff --git a/MAINTAINERS b/MAINTAINERS > index a9ae6c1..10c8b2f 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -10963,6 +10963,13 @@ L: net...@vger.kernel.org > S: Maintained > F: drivers/net/ethernet/via/via-velocity.* > > +VIRT LIB > +M: Alex Williamson > +M: Paolo Bonzini > +L: k...@vger.kernel.org > +S: Supported > +F: virt/lib/ > + > VIVID VIRTUAL VIDEO DRIVER > M: Hans Verkuil > L: linux-me...@vger.kernel.org > diff --git a/include/linux/irqbypass.h b/include/linux/irqbypass.h > new file mode 100644 > index 000..fde7b64 > --- /dev/null > +++ b/include/linux/irqbypass.h > @@ -0,0 +1,90 @@ > +/* > + * IRQ offload/bypass manager > + * > + * Copyright (C) 2015 Red Hat, Inc. > + * Copyright (c) 2015 Linaro Ltd. > + * > + * This program is free software; you can redistribute it and/or modify > + * it under the terms of the GNU General Public License version 2 as > + * published by the Free Software Foundation. > + */ > +#ifndef IRQBYPASS_H > +#define IRQBYPASS_H > + > +#include > + > +struct irq_bypass_consumer; > + > +/* > + * Theory of operation > + * > + * The IRQ bypass manager is a simple set of lists and callbacks that allows > + * IRQ producers (ex. physical interrupt sources) to be matched to IRQ > + * consumers (ex. virtualization hardware that allows IRQ bypass or offload) > + * via a shared token (ex. eventfd_ctx). Producers and consumers register > + * independently. When a token match is found, the optional @stop callback > + * will be called for each participant. The pair will then be connected via > + * the @add_* callbacks, and finally the optional @start callback will allow > + * any final coordination. When either participant is unregistered, the > + * process is repeated using the @del_* callbacks in place of the @add_* > + * callbacks. Match tokens must be unique per producer/consumer, 1:N > pairings > + * are not supported. > + */ > + > +/** > + * struct irq_bypass_producer - IRQ bypass producer definition > + * @node: IRQ bypass manager private list management > + * @token: opaque token to match between producer and consumer > + * @irq:
RE: [PATCH v3 1/2] drivers: watchdog: add a driver to support SAMA5D4 watchdog timer
Hi Guenter,
Thank you for your review.
> -Original Message-
> From: Guenter Roeck [mailto:li...@roeck-us.net]
> Sent: 2015年8月5日 23:05
> To: Yang, Wenyou; w...@iguana.be; robh...@kernel.org; pawel.m...@arm.com;
> mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org
> Cc: sylvain.roc...@finsecur.com; Ferre, Nicolas; boris.brezillon@free-
> electrons.com; devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-
> watch...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v3 1/2] drivers: watchdog: add a driver to support SAMA5D4
> watchdog timer
>
> On 08/05/2015 01:57 AM, Wenyou Yang wrote:
> >>From SAMA5D4, the watchdog timer is upgrated with a new feature,
> > which is describled as in the datasheet, "WDT_MR can be written until
> > a LOCKMR command is issued in WDT_CR".
> > That is to say, as long as the bootstrap and u-boot don't issue a
> > LOCKMR command, WDT_MR can be written more than once in the driver.
> >
> > So the SAMA5D4 watchdog driver's implementation is different from the
> > at91sam9260 watchdog driver implemented in file at91sam9_wdt.c.
> > The user application open the device file to enable the watchdog timer
> > hardware, and close to disable it, and set the watchdog timer timeout
> > by seting WDV and WDD fields of WDT_MR register, and ping the watchdog
> > by issuing WDRSTT command to WDT_CR register with hard-coded key.
> >
> > Signed-off-by: Wenyou Yang
> > ---
> > drivers/watchdog/Kconfig|9 ++
> > drivers/watchdog/Makefile |1 +
> > drivers/watchdog/at91_sama5d4_wdt.c | 279
> +++
> > drivers/watchdog/at91sam9_wdt.h |2 +
> > 4 files changed, 291 insertions(+)
> > create mode 100644 drivers/watchdog/at91_sama5d4_wdt.c
> >
> > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index
> > e5e7c55..4ce8346 100644
> > --- a/drivers/watchdog/Kconfig
> > +++ b/drivers/watchdog/Kconfig
> > @@ -152,6 +152,15 @@ config ARM_SP805_WATCHDOG
> > ARM Primecell SP805 Watchdog timer. This will reboot your system
> when
> > the timeout is reached.
> >
> > +config AT91_SAMA5D4_WATCHDOG
>
> Looking into the chip ordering documentation. The chip goes by ATSAMA5D4,
> while the other chips go by AT91SAM9xxx.
>
> So I think ATSAMA5D4 would be better (same for the driver name).
Use SAMA5D4 directly, the chip name.
>
> Couple of additional nitpicks below.
I will change it in the next version, thanks.
>
> Thanks,
> Guenter
>
> > + tristate "Atmel SAMA5D4 Watchdog Timer"
> > + depends on ARCH_AT91
> > + select WATCHDOG_CORE
> > + help
> > + Atmel SAMA5D4 watchdog timer is embedded into SAMA5D4 chips.
> > + Its Watchdog Timer Mode Register can be written more than once.
> > + This will reboot your system when the timeout is reached.
> > +
> > config AT91RM9200_WATCHDOG
> > tristate "AT91RM9200 watchdog"
> > depends on SOC_AT91RM9200 && MFD_SYSCON diff --git
> > a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index
> > 5c19294..c57569c 100644
> > --- a/drivers/watchdog/Makefile
> > +++ b/drivers/watchdog/Makefile
> > @@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
> >
> > # ARM Architecture
> > obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
> > +obj-$(CONFIG_AT91_SAMA5D4_WATCHDOG) += at91_sama5d4_wdt.o
> > obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.o
> > obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
> > obj-$(CONFIG_CADENCE_WATCHDOG) += cadence_wdt.o diff --git
> > a/drivers/watchdog/at91_sama5d4_wdt.c
> > b/drivers/watchdog/at91_sama5d4_wdt.c
> > new file mode 100644
> > index 000..f2e1995
> > --- /dev/null
> > +++ b/drivers/watchdog/at91_sama5d4_wdt.c
> > @@ -0,0 +1,279 @@
> > +/*
> > + * Driver for Atmel SAMA5D4 Watchdog Timer
> > + *
> > + * Copyright (C) 2015 Atmel Corporation
> > + *
> > + * Licensed under GPLv2.
> > + */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#include "at91sam9_wdt.h"
> > +
> > +/* minimum and maximum watchdog timeout, in seconds */
> > +#define MIN_WDT_TIMEOUT1
> > +#define MAX_WDT_TIMEOUT16
> > +#define WDT_DEFAULT_TIMEOUTMAX_WDT_TIMEOUT
> > +
> > +#define WDT_SEC2TICKS(s) ((s) ? (((s) << 8) - 1) : 0)
> > +
> > +struct atmel_wdt {
>
> If you don't mind, please use "sama5d4" as prefix here and for function names.
>
> > + struct watchdog_device wdd;
> > + void __iomem*reg_base;
> > + u32 config;
> > +};
> > +
> > +static int wdt_timeout = WDT_DEFAULT_TIMEOUT; static bool nowayout =
> > +WATCHDOG_NOWAYOUT;
> > +
> > +module_param(wdt_timeout, int, 0);
> > +MODULE_PARM_DESC(wdt_timeout,
> > + "Watchdog wdt_timeout in seconds. (default = "
> > + __MODULE_STRING(WDT_DEFAULT_TIMEOUT) ")");
> > +
> > +module_param(nowayout, bool, 0);
> >
RE: [PATCH v3 1/2] drivers: watchdog: add a driver to support SAMA5D4 watchdog timer
Hi Lothar,
Thank you for your review.
> -Original Message-
> From: Lothar Waßmann [mailto:l...@karo-electronics.de]
> Sent: 2015年8月5日 18:41
> To: Yang, Wenyou
> Cc: w...@iguana.be; robh...@kernel.org; pawel.m...@arm.com;
> mark.rutl...@arm.com; ijc+devicet...@hellion.org.uk; ga...@codeaurora.org;
> boris.brezil...@free-electrons.com; linux-watch...@vger.kernel.org;
> devicet...@vger.kernel.org; sylvain.roc...@finsecur.com; Ferre, Nicolas;
> linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org
> Subject: Re: [PATCH v3 1/2] drivers: watchdog: add a driver to support SAMA5D4
> watchdog timer
>
> Hi,
>
> > From SAMA5D4, the watchdog timer is upgrated with a new feature, which
> > is describled as in the datasheet, "WDT_MR can be written until a
> > LOCKMR command is issued in WDT_CR".
> > That is to say, as long as the bootstrap and u-boot don't issue a
> > LOCKMR command, WDT_MR can be written more than once in the driver.
> >
> > So the SAMA5D4 watchdog driver's implementation is different from the
> > at91sam9260 watchdog driver implemented in file at91sam9_wdt.c.
> > The user application open the device file to enable the watchdog timer
> > hardware, and close to disable it, and set the watchdog timer timeout
> > by seting WDV and WDD fields of WDT_MR register, and ping the watchdog
> > by issuing WDRSTT command to WDT_CR register with hard-coded key.
> >
> > Signed-off-by: Wenyou Yang
> > ---
> > drivers/watchdog/Kconfig|9 ++
> > drivers/watchdog/Makefile |1 +
> > drivers/watchdog/at91_sama5d4_wdt.c | 279
> +++
> > drivers/watchdog/at91sam9_wdt.h |2 +
> > 4 files changed, 291 insertions(+)
> > create mode 100644 drivers/watchdog/at91_sama5d4_wdt.c
> >
> > diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig index
> > e5e7c55..4ce8346 100644
> > --- a/drivers/watchdog/Kconfig
> > +++ b/drivers/watchdog/Kconfig
> > @@ -152,6 +152,15 @@ config ARM_SP805_WATCHDOG
> > ARM Primecell SP805 Watchdog timer. This will reboot your system
> when
> > the timeout is reached.
> >
> > +config AT91_SAMA5D4_WATCHDOG
> > + tristate "Atmel SAMA5D4 Watchdog Timer"
> > + depends on ARCH_AT91
> > + select WATCHDOG_CORE
> > + help
> > + Atmel SAMA5D4 watchdog timer is embedded into SAMA5D4 chips.
> > + Its Watchdog Timer Mode Register can be written more than once.
> > + This will reboot your system when the timeout is reached.
> > +
> > config AT91RM9200_WATCHDOG
> > tristate "AT91RM9200 watchdog"
> > depends on SOC_AT91RM9200 && MFD_SYSCON diff --git
> > a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile index
> > 5c19294..c57569c 100644
> > --- a/drivers/watchdog/Makefile
> > +++ b/drivers/watchdog/Makefile
> > @@ -30,6 +30,7 @@ obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
> >
> > # ARM Architecture
> > obj-$(CONFIG_ARM_SP805_WATCHDOG) += sp805_wdt.o
> > +obj-$(CONFIG_AT91_SAMA5D4_WATCHDOG) += at91_sama5d4_wdt.o
> consistency? Other AT91 entries don't have an '_' between 'AT91' and the
> remainder of the Kconfig name.
Accept, Remove the prefix AT91_ , use the chip name directly, SAMA5D4 in next
verison.
>
> > obj-$(CONFIG_AT91RM9200_WATCHDOG) += at91rm9200_wdt.ovi
> > obj-$(CONFIG_AT91SAM9X_WATCHDOG) += at91sam9_wdt.o
> [...]
> > +static irqreturn_t atmel_wdt_irq_handler(int irq, void *dev_id) {
> > + struct atmel_wdt *wdt = platform_get_drvdata(dev_id);
> > +
> > + if (wdt_read(wdt, AT91_WDT_SR)) {
> > + pr_crit("Atmel Watchdog Software Reset\n");
> > + emergency_restart();
> > + pr_crit("Reboot didn't ?\n");
> >
> Reboot didn't what? 'succeed' perhaps?
Replace it with 'succeed' in next version.
>
> > +static const struct of_device_id atmel_wdt_of_match[] = {
> > + { .compatible = "atmel,sama5d4-wdt", },
> > + { },
> The empty initializer must always be the last element of the array, so there
> is no
> point in having a trailing ',' (whose purpose is to facilitate adding more
> entries after
> the last one).
> Without the comma there will be a compile error if (e.g. due to a badly
> resolved
> merge conflict) an additional entry would be added after the stop marker.
> With the
> comma after the stop marker any trailing entries would silently be ignored.
Remove this comma in next version.
>
>
> Lothar Waßmann
> --
> ___
>
> Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen
> Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10
> Geschäftsführer: Matthias Kaussen
> Handelsregistereintrag: Amtsgericht Aachen, HRB 4996
>
> www.karo-electronics.de | i...@karo-electronics.de
> ___
Best Regards,
Wenyou
Re: perf eBPF patch ordering. was: Re: perf test LLVM was: Re: [GIT PULL 00/39] perf tools: filtering events using eBPF programs
Hi Arnaldo, Have you tried 'perf test BPF'? Is that okay on your environment? Thank you. On 2015/8/5 0:11, Arnaldo Carvalho de Melo wrote: Em Tue, Aug 04, 2015 at 12:55:57PM -0300, Arnaldo Carvalho de Melo escreveu: Em Tue, Aug 04, 2015 at 06:39:39PM +0800, Wangnan (F) escreveu: https://github.com/WangNan0/linux.git ebpf Ok, but I am checking patch by patch to see if the changes I made are kept, and for the first one, it wasn't (the second one is the cset in ouch, you now use a branch named "ebpf" whereas before you used "perf/ebpf-for-acme" before, that was what I was looking at now :-\ After I realised that, yes, you kept my changes in the "ebpf" branch, looking there now. - 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 v2] mmc: dw_mmc: Fix coding style issues
Hi, Shawn.
Applied this patch at my dw-mmc tree.
I will request pull on this weekend.
Thanks a lot!
Best Regards,
Jaehoon Chung
On 08/03/2015 04:07 PM, Shawn Lin wrote:
> This patch fixes the following issues reported by checkpatch.pl:
> - use -EINVAL instead of -ENOSYS, to fix warning message:
>"ENOSYS means 'invalid syscall nr' and nothing else"
> - split lines whose length is greater than 80 characters
> - avoid quoted string split across lines
> - use min_t instead of min, to fix warning message:
>"min() should probably be min_t(int, cnt, host->part_buf_count)"
> - fix missing a blank line after declarations
>
> Signed-off-by: Shawn Lin
>
> ---
>
> Changes in v2:
> - Keep consistency of comments
> - Rebase on https://patchwork.kernel.org/patch/6672581
>
> drivers/mmc/host/dw_mmc.c | 90
> +--
> 1 file changed, 56 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index e41fb74..3f070d9 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -238,8 +238,8 @@ static u32 dw_mci_prepare_command(struct mmc_host *mmc,
> struct mmc_command *cmd)
> struct dw_mci *host = slot->host;
> const struct dw_mci_drv_data *drv_data = slot->host->drv_data;
> u32 cmdr;
> - cmd->error = -EINPROGRESS;
>
> + cmd->error = -EINPROGRESS;
> cmdr = cmd->opcode;
>
> if (cmd->opcode == MMC_STOP_TRANSMISSION ||
> @@ -374,7 +374,7 @@ static void dw_mci_start_command(struct dw_mci *host,
>cmd->arg, cmd_flags);
>
> mci_writel(host, CMDARG, cmd->arg);
> - wmb();
> + wmb(); /* drain writebuffer */
> dw_mci_wait_while_busy(host, cmd_flags);
>
> mci_writel(host, CMD, cmd_flags | SDMMC_CMD_START);
> @@ -383,6 +383,7 @@ static void dw_mci_start_command(struct dw_mci *host,
> static inline void send_stop_abort(struct dw_mci *host, struct mmc_data
> *data)
> {
> struct mmc_command *stop = data->stop ? data->stop : >stop_abort;
> +
> dw_mci_start_command(host, stop, host->stop_cmdr);
> }
>
> @@ -467,6 +468,7 @@ static void dw_mci_translate_sglist(struct dw_mci *host,
> struct mmc_data *data,
> {
> unsigned int desc_len;
> int i;
> +
> if (host->dma_64bit_address == 1) {
> struct idmac_desc_64addr *desc_first, *desc_last, *desc;
>
> @@ -474,6 +476,7 @@ static void dw_mci_translate_sglist(struct dw_mci *host,
> struct mmc_data *data,
>
> for (i = 0; i < sg_len; i++) {
> unsigned int length = sg_dma_len(>sg[i]);
> +
> u64 mem_addr = sg_dma_address(>sg[i]);
>
> for ( ; length ; desc++) {
> @@ -518,6 +521,7 @@ static void dw_mci_translate_sglist(struct dw_mci *host,
> struct mmc_data *data,
>
> for (i = 0; i < sg_len; i++) {
> unsigned int length = sg_dma_len(>sg[i]);
> +
> u32 mem_addr = sg_dma_address(>sg[i]);
>
> for ( ; length ; desc++) {
> @@ -557,7 +561,7 @@ static void dw_mci_translate_sglist(struct dw_mci *host,
> struct mmc_data *data,
> desc_last->des0 |= cpu_to_le32(IDMAC_DES0_LD);
> }
>
> - wmb();
> + wmb(); /* drain writebuffer */
> }
>
> static void dw_mci_idmac_start_dma(struct dw_mci *host, unsigned int sg_len)
> @@ -575,6 +579,7 @@ static void dw_mci_idmac_start_dma(struct dw_mci *host,
> unsigned int sg_len)
> temp |= SDMMC_CTRL_USE_IDMAC;
> mci_writel(host, CTRL, temp);
>
> + /* drain writebuffer */
> wmb();
>
> /* Enable the IDMAC */
> @@ -622,7 +627,9 @@ static int dw_mci_idmac_init(struct dw_mci *host)
> host->ring_size = PAGE_SIZE / sizeof(struct idmac_desc);
>
> /* Forward link the descriptor list */
> - for (i = 0, p = host->sg_cpu; i < host->ring_size - 1; i++,
> p++) {
> + for (i = 0, p = host->sg_cpu;
> + i < host->ring_size - 1;
> + i++, p++) {
> p->des3 = cpu_to_le32(host->sg_dma +
> (sizeof(struct idmac_desc) * (i + 1)));
> p->des1 = 0;
> @@ -751,7 +758,7 @@ static void dw_mci_adjust_fifoth(struct dw_mci *host,
> struct mmc_data *data)
> u32 fifo_width = 1 << host->data_shift;
> u32 blksz_depth = blksz / fifo_width, fifoth_val;
> u32 msize = 0, rx_wmark = 1, tx_wmark, tx_wmark_invers;
> - int idx = (sizeof(mszs) / sizeof(mszs[0])) - 1;
> + int idx = ARRAY_SIZE(mszs) - 1;
>
> tx_wmark = (host->fifo_depth) / 2;
> tx_wmark_invers = host->fifo_depth - tx_wmark;
> @@ -876,6 +883,7 @@ static int dw_mci_submit_data_dma(struct dw_mci *host,
> struct mmc_data *data)
> static void dw_mci_submit_data(struct dw_mci *host, struct mmc_data *data)
> {
> unsigned long irqflags;
> + int flags =
Re: [PATCH] mmc: dw_mmc: fix pio mode when internal dmac is enabled
Hi, Heiko.
Applied this patch at my dw-mmc tree.
I will request pull on this weekend.
Thanks a lot!
Best Regards,
Jaehoon Chung
On 08/04/2015 12:04 AM, Heiko Stübner wrote:
> The dw_mci_init_dma() may decide to not use dma, but pio instead, caused
> by things like wrong dma settings in the system.
>
> Till now the code dw_mci_init_slot() always assumed that dma is available
> when CONFIG_MMC_DW_IDMAC was defined, ignoring the host->use_dma var
> set during dma init.
>
> So when now the dma init failed for whatever reason, the transfer sizes
> would still be set for dma transfers, especially including the maximum
> block-count calculated from host->ring_size and resulting in a
>
> [4.991109] [ cut here ]
> [4.99] kernel BUG at drivers/mmc/core/core.c:256!
> [4.991113] Internal error: Oops - BUG: 0 [#1] SMP ARM
>
> because host->ring_size is 0 in this case and the slot init code uses
> the wrong code to calculate the values.
>
> Fix this by selecting the correct calculations using the host->use_dma
> variable instead of the CONFIG_MMC_DW_IDMAC config option.
>
> Signed-off-by: Heiko Stuebner
> ---
> drivers/mmc/host/dw_mmc.c | 27 ++-
> 1 file changed, 14 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
> index 40e9d8e..9ec3521 100644
> --- a/drivers/mmc/host/dw_mmc.c
> +++ b/drivers/mmc/host/dw_mmc.c
> @@ -2391,19 +2391,20 @@ static int dw_mci_init_slot(struct dw_mci *host,
> unsigned int id)
> mmc->max_seg_size = host->pdata->blk_settings->max_seg_size;
> } else {
> /* Useful defaults if platform data is unset. */
> -#ifdef CONFIG_MMC_DW_IDMAC
> - mmc->max_segs = host->ring_size;
> - mmc->max_blk_size = 65536;
> - mmc->max_seg_size = 0x1000;
> - mmc->max_req_size = mmc->max_seg_size * host->ring_size;
> - mmc->max_blk_count = mmc->max_req_size / 512;
> -#else
> - mmc->max_segs = 64;
> - mmc->max_blk_size = 65536; /* BLKSIZ is 16 bits */
> - mmc->max_blk_count = 512;
> - mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count;
> - mmc->max_seg_size = mmc->max_req_size;
> -#endif /* CONFIG_MMC_DW_IDMAC */
> + if (host->use_dma) {
> + mmc->max_segs = host->ring_size;
> + mmc->max_blk_size = 65536;
> + mmc->max_seg_size = 0x1000;
> + mmc->max_req_size = mmc->max_seg_size * host->ring_size;
> + mmc->max_blk_count = mmc->max_req_size / 512;
> + } else {
> + mmc->max_segs = 64;
> + mmc->max_blk_size = 65536; /* BLKSIZ is 16 bits */
> + mmc->max_blk_count = 512;
> + mmc->max_req_size = mmc->max_blk_size *
> + mmc->max_blk_count;
> + mmc->max_seg_size = mmc->max_req_size;
> + }
> }
>
> if (dw_mci_get_cd(mmc))
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/4] ASN.1: Fix handling of CHOICE in ASN.1 compiler
On Wed, 5 Aug 2015, David Howells wrote: > Fix the handling of CHOICE types in the ASN.1 compiler to make SEQUENCE and > SET elements in a CHOICE be correctly rendered as skippable and conditional > as appropriate. What are the security implications of these bugs? It's pretty late in the -rc cycle. -- James Morris -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/3] dt-binding: spi: Mediatek: Document devicetree bindings for spi bus
On Tue, 2015-08-04 at 18:42 +0100, Mark Brown wrote: > On Wed, Jul 29, 2015 at 07:04:32PM +0800, Leilk Liu wrote: > > Signed-off-by: Leilk Liu > > Please use subject lines reflecting the style for the subsystem so > people can spot if patches are relevant to them. > OK, I will change the title to "spi: Mediatek: Document devicetree bindings for spi bus". > > +- clocks: phandles to input clocks. > > + > > +- clock-names: tuple listing input clock names. > > + Required elements: "main" > > ...and there are no optional values? > clock tree provides some source clocks, CLK_PERI_SPI0 is the default one. I will support optional values on the next version. > > +- pad-select: should specify spi pad used, only required for MT8173. > > +This value should be 0~3. > > What do the values 0-3 mean? I guess it's the value for some register > or other part of the device, the binding should say so people can go and > check the datasheet, schematic or whatever to figure out what to set. > > This property should be optional, not required OK, I will explain what the values 0-3 mean. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] PCI: Only enable IO window if supported
On 08/05/2015 06:14 PM, Yinghai Lu wrote:
On Thu, Jul 30, 2015 at 7:15 PM, Guenter Roeck wrote:
The PCI subsystem always assumes that I/O is supported on PCIe bridges
and tries to assign an I/O window to each child bus even if that is not
the case.
This may result in messages such as:
pcieport :02:00.0: res[7]=[io 0x1000-0x0fff] get_res_add_size add_size
1000
pcieport :02:00.0: BAR 7: no space for [io size 0x1000]
pcieport :02:00.0: BAR 7: failed to assign [io size 0x1000]
for each bridge port, even if a bus or its parent does not support I/O in
the first place.
To avoid this message, check if a bus supports I/O before trying to enable
it. Also check if the root bus has an IO window assigned; if not, it does
not make sense to try to assign one to any of its child busses.
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index cefd636681b6..d9e02ba34035 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -332,6 +332,24 @@ static void pci_read_bases(struct pci_dev *dev, unsigned
int howmany, int rom)
}
}
+static int pci_bridge_supports_io(struct pci_dev *bridge)
+{
+ u16 io;
+
+ pci_read_config_word(bridge, PCI_IO_BASE, );
+ if (io)
+ return 1;
+
+ /* IO_BASE/LIMIT is either hard-wired to zero or programmed to zero */
+ pci_write_config_word(bridge, PCI_IO_BASE, 0xe0f0);
+ pci_read_config_word(bridge, PCI_IO_BASE, );
+ pci_write_config_word(bridge, PCI_IO_BASE, 0x0);
+ if (io)
+ return 1;
+
+ return 0;
+}
+
static void pci_read_bridge_io(struct pci_bus *child)
{
struct pci_dev *dev = child->self;
@@ -340,6 +358,15 @@ static void pci_read_bridge_io(struct pci_bus *child)
struct pci_bus_region region;
struct resource *res;
+ if (!(child->bus_flags & PCI_BUS_FLAGS_SUPPORTS_IO))
+ return;
+
+ if (!pci_bridge_supports_io(dev)) {
+ dev_printk(KERN_DEBUG, >dev, " no I/O window\n");
+ child->bus_flags &= ~PCI_BUS_FLAGS_SUPPORTS_IO;
+ return;
+ }
+
It only can avoid warning with bridge, and still have warning on
devices under the bridge.
Not really, because children inherit bus_flags.
also would have problem on transparent bridges, like
BRIDGE_A BRIDGE_AADEVICE_AA
|
\-- BRIDGE_AB ---DEVICE_AB
if only BRIDGE_A and BRIDGE_AA are transparent, and BRIDGE_AB is not.
and if pci_bridge_supports_io() return false for BRIDGE_A.
We will have all three bridges have PCI_BUS_FLAGS_SUPPORTS_IO cleared.
so all will not been sized and will not get assigned io port resource.
What is wrong with that ? Doesn't it reflect reality ?
later DEVICE_AA could root bus io port as parent, and get io resource assigned.
but DEVICE_AB will not get assigned.
so we should get rid of pci_bridge_supports_io(), and just check root
resource IO port.
You lost me here. That would mean that we would not clear the flag
and claim that a bridge supports IO even if it doesn't, and all ports
and bridges connected to that bridge would try (and fail) to get
IO address assignments.
That does not make much sense to me. What do you expect to do in this case ?
I must admit I have no idea how non-transparent bridges fit
into this picture. However, if Bridge A doesn't support IO,
I don't see how we can get IO anywhere, transparent or not.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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 introduced by "block: Add support for DAX reads/writes to block devices"
On 08/05/2015 06:01 PM, Dave Chinner wrote: > On Wed, Aug 05, 2015 at 04:19:08PM -0400, Jeff Moyer wrote: >> Hi, Matthew, >> >> Linda Knippers noticed that commit (bbab37ddc20b) breaks mkfs.xfs: >> >> # mkfs -t xfs -f /dev/pmem0 >> meta-data=/dev/pmem0 isize=256agcount=4, agsize=524288 blks >> = sectsz=512 attr=2, projid32bit=1 >> = crc=0finobt=0 >> data = bsize=4096 blocks=2097152, imaxpct=25 >> = sunit=0 swidth=0 blks >> naming =version 2 bsize=4096 ascii-ci=0 ftype=0 >> log =internal log bsize=4096 blocks=2560, version=2 >> = sectsz=512 sunit=0 blks, lazy-count=1 >> realtime =none extsz=4096 blocks=0, rtextents=0 >> mkfs.xfs: read failed: Numerical result out of range >> >> I sat down with Linda to look into it, and the problem is that mkfs.xfs >> sets the blocksize of the device to 512 (via BLKBSZSET), and then reads >> from the last sector of the device. This results in dax_io trying to do >> a page-sized I/O at 512 bytes from the end of the device. > > Right - we have to be able to do IO to that last sector, so this is > a sanity check to tell if the block dev is large enough. The XFS > kernel code does the same end-of-device sector read when the > filesystem is mounted, too. > >> bdev_direct_access, receiving this bogus pos/size combo, returns >> -ERANGE: >> >> if ((sector + DIV_ROUND_UP(size, 512)) > >> part_nr_sects_read(bdev->bd_part)) >> return -ERANGE; >> >> Given that file systems supporting dax refuse to mount with a blocksize >> != page size, I'm guessing this is sort of expected behavior. However, >> we really shouldn't be breaking direct I/O on pmem devices. > > If the device is advertising 512 byte sector size support, then this > needs to work, especially as DAX is completely transparent on the > block device. Remember that DAX through a filesystem works on > filesystem data block size boundaries, so a 512 byte sector/4k block > size filesystem will be able to use DAX for mmapped files just fine. > >> So, what do you want to do? We could make the pmem device's logical >> block size fixed at the sytem page size. Or, we could modify the dax >> code to work with blocksize < pagesize. Or, we could continue using the >> direct I/O codepath for direct block device access. What do you think? > > I don't know how the pmem device sets up it's limits. Can you post > the output of: > > /sys/block/pmem0/queue/logical_block_size 512 > /sys/block/pmem0/queue/physical_block_size 512 > /sys/block/pmem0/queue/hw_sector_size 512 > /sys/block/pmem0/queue/minimum_io_size 512 > /sys/block/pmem0/queue/optimal_io_size 0 Let me know if you need anything else. -- ljk > As these all affect how mkfs.xfs configures the filesystem being > made and so influences the size and alignment of the IO is does > > Cheers, > > Dave. > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] regulator: Fix recursive mutex lockdep warning
2015-08-06 1:02 GMT+09:00 Srinivas Kandagatla :
> A recursive lockdep warning occurs if you call regulator_set_voltage()
> on a load switches that are modelled as regulators with a parent supply as
> there is no nesting annotation for the rdev->mutex.
> To avoid this warning, use the unlocked version of the get_voltage().
>
> wiithout this patch kernel throws up below warning:
>
> =
> [ INFO: possible recursive locking detected ]
> 4.2.0-rc5-dirty #132 Not tainted
> -
> swapper/0/1 is trying to acquire lock:
> (>mutex){+.+.+.}, at: [] regulator_get_voltage+0x44/0x68
>
> but task is already holding lock:
> (>mutex){+.+.+.}, at: [] regulator_set_voltage+0x50/0x168
>
> other info that might help us debug this:
> Possible unsafe locking scenario:
>
> CPU0
>
>lock(>mutex);
>lock(>mutex);
>
> *** DEADLOCK ***
>
> May be due to missing lock nesting notation
>
> 3 locks held by swapper/0/1:
> #0: (>mutex){..}, at: [] __driver_attach+0x58/0xa8
> #1: (>mutex){..}, at: [] __driver_attach+0x68/0xa8
> #2: (>mutex){+.+.+.}, at: []
> regulator_set_voltage+0x50/0x168
>
> stack backtrace:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.2.0-rc5-dirty #132
> Hardware name: Qualcomm (Flattened Device Tree)
> [] (unwind_backtrace) from [] (show_stack+0x20/0x24)
> [] (show_stack) from [] (dump_stack+0x8c/0xc0)
> [] (dump_stack) from [] (__lock_acquire+0x1bf4/0x1ec0)
> [] (__lock_acquire) from [] (lock_acquire+0xe0/0x300)
> [] (lock_acquire) from [] (mutex_lock_nested+0x88/0x45c)
> [] (mutex_lock_nested) from []
> (regulator_get_voltage+0x44/0x68)
> [] (regulator_get_voltage) from []
> (_regulator_get_voltage+0xb8/0x190)
> [] (_regulator_get_voltage) from []
> (regulator_set_voltage+0x12c/0x168)
> [] (regulator_set_voltage) from []
> (mmci_sig_volt_switch+0x6c/0x110)
> [] (mmci_sig_volt_switch) from []
> (mmc_power_up+0x78/0x114)
> [] (mmc_power_up) from [] (mmc_start_host+0x54/0x7c)
> [] (mmc_start_host) from [] (mmc_add_host+0x6c/0x90)
> [] (mmc_add_host) from [] (mmci_probe+0x5ac/0x854)
> [] (mmci_probe) from [] (amba_probe+0xdc/0x158)
> [] (amba_probe) from [] (driver_probe_device+0x1dc/0x280)
> [] (driver_probe_device) from []
> (__driver_attach+0xa4/0xa8)
> [] (__driver_attach) from [] (bus_for_each_dev+0x64/0x98)
> [] (bus_for_each_dev) from [] (driver_attach+0x2c/0x30)
> [] (driver_attach) from [] (bus_add_driver+0xf8/0x204)
> [] (bus_add_driver) from [] (driver_register+0x88/0x104)
> [] (driver_register) from []
> (amba_driver_register+0x50/0x64)
> [] (amba_driver_register) from []
> (mmci_driver_init+0x14/0x1c)
> [] (mmci_driver_init) from []
> (do_one_initcall+0x90/0x1e4)
> [] (do_one_initcall) from []
> (kernel_init_freeable+0x12c/0x1f4)
> [] (kernel_init_freeable) from [] (kernel_init+0x1c/0xfc)
> [] (kernel_init) from [] (ret_from_fork+0x14/0x3c)
>
> Reported-by: Nicolas Dechesne
> Signed-off-by: Srinivas Kandagatla
> ---
> drivers/regulator/core.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/regulator/core.c b/drivers/regulator/core.c
> index 3c3137a..7717b04 100644
> --- a/drivers/regulator/core.c
> +++ b/drivers/regulator/core.c
> @@ -2919,7 +2919,7 @@ static int _regulator_get_voltage(struct regulator_dev
> *rdev)
> } else if (rdev->desc->fixed_uV && (rdev->desc->n_voltages == 1)) {
> ret = rdev->desc->fixed_uV;
> } else if (rdev->supply) {
> - ret = regulator_get_voltage(rdev->supply);
> + ret = _regulator_get_voltage(rdev->supply->rdev);
Is the 'rdev' and 'rdev->supply' same regulators? If not then you are
just hiding false warning by removing locks thus introducing real
issue...
Best regards,
Krzysztof
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.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] PCI: Only enable IO window if supported
On Wed, Aug 5, 2015 at 6:14 PM, Yinghai Lu wrote:
>
> It only can avoid warning with bridge, and still have warning on
> devices under the bridge.
>
> also would have problem on transparent bridges, like
>
> BRIDGE_A BRIDGE_AADEVICE_AA
>|
>\-- BRIDGE_AB ---DEVICE_AB
>
> if only BRIDGE_A and BRIDGE_AA are transparent, and BRIDGE_AB is not.
>
> and if pci_bridge_supports_io() return false for BRIDGE_A.
>
> We will have all three bridges have PCI_BUS_FLAGS_SUPPORTS_IO cleared.
> so all will not been sized and will not get assigned io port resource.
>
> later DEVICE_AA could root bus io port as parent, and get io resource
> assigned.
> but DEVICE_AB will not get assigned.
>
> so we should get rid of pci_bridge_supports_io(), and just check root
> resource IO port.
I would suggest this version instead:
Subject: [PATCH] PCI: Only try to assign io port only if root bus support that
The PCI subsystem always assumes that I/O is supported on root bus and
tries to assign an I/O window to each child bus even if that is not the
case.
This may result in messages such as:
pcieport :02:00.0: res[7]=[io 0x1000-0x0fff] get_res_add_size
add_size 1000
pcieport :02:00.0: BAR 7: no space for [io size 0x1000]
pcieport :02:00.0: BAR 7: failed to assign [io size 0x1000]
for each bridge port, even if root does not support I/O in the first place.
To avoid this message, check if root bus supports I/O, then child bus
will inherit the setting from parent bus, and later during sizing and
assigning, check that bus flags and skip those resources.
[bhelgaas: reverse sense of new pci_bus_flags_t value]
[yinghai: only check root bus io port, and use flag on sizing and assigning]
Cc: Guenter Roeck
Cc: Bjorn Helgaas
CC: Lorenzo Pieralisi
---
drivers/pci/probe.c |5 +
drivers/pci/setup-bus.c |6 +-
include/linux/pci.h |1 +
3 files changed, 11 insertions(+), 1 deletion(-)
Index: linux-2.6/drivers/pci/probe.c
===
--- linux-2.6.orig/drivers/pci/probe.c
+++ linux-2.6/drivers/pci/probe.c
@@ -340,6 +340,9 @@ static void pci_read_bridge_io(struct pc
struct pci_bus_region region;
struct resource *res;
+if (!(child->bus_flags & PCI_BUS_FLAGS_ROOT_SUPPORTS_IO))
+return;
+
io_mask = PCI_IO_RANGE_MASK;
io_granularity = 0x1000;
if (dev->io_window_1k) {
@@ -2070,6 +2073,8 @@ struct pci_bus *pci_create_root_bus(stru
} else
bus_addr[0] = '\0';
dev_info(>dev, "root bus resource %pR%s\n", res, bus_addr);
+if (resource_type(res) == IORESOURCE_IO)
+b->bus_flags |= PCI_BUS_FLAGS_ROOT_SUPPORTS_IO;
}
down_write(_bus_sem);
Index: linux-2.6/drivers/pci/setup-bus.c
===
--- linux-2.6.orig/drivers/pci/setup-bus.c
+++ linux-2.6/drivers/pci/setup-bus.c
@@ -156,6 +156,10 @@ static void pdev_sort_resources(struct p
if (r->flags & IORESOURCE_PCI_FIXED)
continue;
+if ((r->flags & IORESOURCE_IO) &&
+!(dev->bus->bus_flags & PCI_BUS_FLAGS_ROOT_SUPPORTS_IO))
+continue;
+
if (!(r->flags) || r->parent)
continue;
@@ -909,7 +913,7 @@ static void pbus_size_io(struct pci_bus
resource_size_t children_add_size = 0;
resource_size_t min_align, align;
-if (!b_res)
+if (!b_res || !(bus->bus_flags & PCI_BUS_FLAGS_ROOT_SUPPORTS_IO))
return;
min_align = window_alignment(bus, IORESOURCE_IO);
Index: linux-2.6/include/linux/pci.h
===
--- linux-2.6.orig/include/linux/pci.h
+++ linux-2.6/include/linux/pci.h
@@ -193,6 +193,7 @@ typedef unsigned short __bitwise pci_bus
enum pci_bus_flags {
PCI_BUS_FLAGS_NO_MSI = (__force pci_bus_flags_t) 1,
PCI_BUS_FLAGS_NO_MMRBC = (__force pci_bus_flags_t) 2,
+PCI_BUS_FLAGS_ROOT_SUPPORTS_IO = (__force pci_bus_flags_t) 4,
};
/* These values come from the PCI Express Spec */
Subject: [PATCH] PCI: Only try to assign io port only if root bus support that
The PCI subsystem always assumes that I/O is supported on root bus and
tries to assign an I/O window to each child bus even if that is not the
case.
This may result in messages such as:
pcieport :02:00.0: res[7]=[io 0x1000-0x0fff] get_res_add_size add_size 1000
pcieport :02:00.0: BAR 7: no space for [io size 0x1000]
pcieport :02:00.0: BAR 7: failed to assign [io size 0x1000]
for each bridge port, even if root does not support I/O in the first place.
To avoid this message, check if root bus supports I/O, then child bus
will inherit the setting from parent bus, and later during sizing and
assigning, check that bus flags and skip those resources.
[bhelgaas: reverse sense of new pci_bus_flags_t value]
[yinghai: only check root bus io port, and use flag on sizing and
Re: [PATCH v1 4/7] ARM: dts: apq8064: Add MDP support
On 07/28/2015 05:54 AM, Srinivas Kandagatla wrote:
@@ -618,5 +633,77 @@
compatible = "qcom,tcsr-apq8064", "syscon";
reg = <0x1a40 0x100>;
};
+
+ hdmi: qcom,hdmi-tx@4a0 {
+ compatible = "qcom,hdmi-tx-8960";
+ reg-names = "core_physical";
+ reg = <0x04a0 0x1000>;
+ interrupts = ;
+ clock-names =
+ "core_clk",
+ "master_iface_clk",
+ "slave_iface_clk";
+ clocks =
+ < HDMI_APP_CLK>,
+ < HDMI_M_AHB_CLK>,
+ < HDMI_S_AHB_CLK>;
+ qcom,hdmi-tx-ddc-clk = <_pinmux 70
GPIO_ACTIVE_HIGH>;
+ qcom,hdmi-tx-ddc-data = <_pinmux 71
GPIO_ACTIVE_HIGH>;
+ qcom,hdmi-tx-hpd = <_pinmux 72 GPIO_ACTIVE_HIGH>;
These should use standard "-gpios" syntax. Please fix the binding/driver.
+ pinctrl-names = "default";
+ pinctrl-0 = <_pinctrl>;
+ };
+
+ gpu: qcom,adreno-3xx@430 {
+ compatible = "qcom,adreno-3xx";
+ reg = <0x0430 0x2>;
+ reg-names = "kgsl_3d0_reg_memory";
+ interrupts = ;
+ interrupt-names = "kgsl_3d0_irq";
+ clock-names =
+ "core_clk",
+ "iface_clk",
+ "mem_clk",
+ "mem_iface_clk";
Please drop "_clk" and fix driver code as we've done for all other drivers.
+ clocks =
+ < GFX3D_CLK>,
+ < GFX3D_AHB_CLK>,
+ < GFX3D_AXI_CLK>,
+ < MMSS_IMEM_AHB_CLK>;
+ qcom,chipid = <0x03020002>;
+ qcom,gpu-pwrlevels {
+ compatible = "qcom,gpu-pwrlevels";
+ qcom,gpu-pwrlevel@0 {
+ qcom,gpu-freq = <45000>;
+ };
+ qcom,gpu-pwrlevel@1 {
+ qcom,gpu-freq = <2700>;
+ };
+ };
These should be OPPs. I see in the cover-letter we're asking to ignore
this part of the binding. When is the binding and driver going to be
fixed? The dts has been out of tree for quite some time and I assume
work has been progressing on the driver even without this dts being in
mainline so it doesn't make sense how pushing half-baked dts upstream is
going to help. In fact, it's going to make things worse if someone
complains that we're not maintaining backwards compatibility and then
have to hack up driver code to work both ways. At which point there's
practically zero incentive to change anything in the binding or driver.
It's better to fix the driver now and avoid these sorts of problems
entirely.
--
Qualcomm Innovation Center, Inc. is a member of 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 v5 2/2] firmware: qcom: scm: Add support for ARM64 SoCs
On 04/28/2015 12:23 PM, Kumar Gala wrote:
+
+int __qcom_scm_call_armv8_64(u64 x0, u64 x1, u64 x2, u64 x3, u64 x4, u64 x5,
+ u64 *ret1, u64 *ret2, u64 *ret3)
+{
+ register u64 r0 asm("r0") = x0;
+ register u64 r1 asm("r1") = x1;
+ register u64 r2 asm("r2") = x2;
+ register u64 r3 asm("r3") = x3;
+ register u64 r4 asm("r4") = x4;
+ register u64 r5 asm("r5") = x5;
This should set x6 to 0.
register u32 r6 asm("r6") = 0;
for example.
+
+ do {
+ asm volatile(
+ __asmeq("%0", "x0")
+ __asmeq("%1", "x1")
+ __asmeq("%2", "x2")
+ __asmeq("%3", "x3")
+ __asmeq("%4", "x0")
+ __asmeq("%5", "x1")
+ __asmeq("%6", "x2")
+ __asmeq("%7", "x3")
+ __asmeq("%8", "x4")
+ __asmeq("%9", "x5")
And then the asmeq thing here for x6.
+#ifdef REQUIRES_SEC
+ ".arch_extension sec\n"
+#endif
+ "smc #0\n"
+ : "=r" (r0), "=r" (r1), "=r" (r2), "=r" (r3)
+ : "r" (r0), "r" (r1), "r" (r2), "r" (r3), "r" (r4),
+ "r" (r5)
And add x6 as an input here.
+ : "x6", "x7", "x8", "x9", "x10", "x11", "x12", "x13",
and remove x6 as a clobber.
+ "x14", "x15", "x16", "x17");
+ } while (r0 == QCOM_SCM_INTERRUPTED);
+
+ if (ret1)
+ *ret1 = r1;
+ if (ret2)
+ *ret2 = r2;
+ if (ret3)
+ *ret3 = r3;
+
+ return r0;
+}
+
+int __qcom_scm_call_armv8_32(u32 w0, u32 w1, u32 w2, u32 w3, u32 w4, u32 w5,
+ u64 *ret1, u64 *ret2, u64 *ret3)
+{
+ register u32 r0 asm("r0") = w0;
+ register u32 r1 asm("r1") = w1;
+ register u32 r2 asm("r2") = w2;
+ register u32 r3 asm("r3") = w3;
+ register u32 r4 asm("r4") = w4;
+ register u32 r5 asm("r5") = w5;
This needs to set r6 to 0 as well
register u32 r6 asm("r6") = 0;
for example.
+
+ do {
+ asm volatile(
+ __asmeq("%0", "x0")
+ __asmeq("%1", "x1")
+ __asmeq("%2", "x2")
+ __asmeq("%3", "x3")
+ __asmeq("%4", "x0")
+ __asmeq("%5", "x1")
+ __asmeq("%6", "x2")
+ __asmeq("%7", "x3")
+ __asmeq("%8", "x4")
+ __asmeq("%9", "x5")
And then another asmeq thing here for x6.
+#ifdef REQUIRES_SEC
+ ".arch_extension sec\n"
+#endif
+ "smc #0\n"
+ : "=r" (r0), "=r" (r1), "=r" (r2), "=r" (r3)
+ : "r" (r0), "r" (r1), "r" (r2), "r" (r3), "r" (r4),
+ "r" (r5)
And then add r6 here as an input
+ : "x6", "x7", "x8", "x9", "x10", "x11", "x12", "x13",
And remove r6 from the clobber.
+ "x14", "x15", "x16", "x17");
+
+ } while (r0 == QCOM_SCM_INTERRUPTED);
+
+ if (ret1)
+ *ret1 = r1;
+ if (ret2)
+ *ret2 = r2;
+ if (ret3)
+ *ret3 = r3;
+
+ return r0;
+}
+
Here's a totally untested patch for that.
Signed-off-by: Stephen Boyd
8<-
diff --git a/drivers/firmware/qcom_scm-64.c b/drivers/firmware/qcom_scm-64.c
index a95fd9b5d576..8f7e65ff524c 100644
--- a/drivers/firmware/qcom_scm-64.c
+++ b/drivers/firmware/qcom_scm-64.c
@@ -114,6 +114,7 @@ int __qcom_scm_call_armv8_64(u64 x0, u64 x1, u64 x2, u64
x3, u64 x4, u64 x5,
register u64 r3 asm("r3") = x3;
register u64 r4 asm("r4") = x4;
register u64 r5 asm("r5") = x5;
+ register u64 r6 asm("r5") = 0;
do {
asm volatile(
@@ -127,14 +128,15 @@ int __qcom_scm_call_armv8_64(u64 x0, u64 x1, u64 x2, u64
x3, u64 x4, u64 x5,
__asmeq("%7", "x3")
__asmeq("%8", "x4")
__asmeq("%9", "x5")
+ __asmeq("%10", "x6")
#ifdef REQUIRES_SEC
".arch_extension sec\n"
#endif
"smc #0\n"
: "=r" (r0), "=r" (r1), "=r" (r2), "=r" (r3)
: "r" (r0), "r" (r1), "r" (r2), "r" (r3), "r" (r4),
- "r" (r5)
- : "x6", "x7", "x8", "x9", "x10", "x11", "x12", "x13",
+ "r" (r5), "r" (r6)
+ : "x7", "x8", "x9", "x10", "x11", "x12", "x13",
"x14", "x15", "x16", "x17");
} while (r0 == QCOM_SCM_INTERRUPTED);
@@ -157,6 +159,7 @@ int __qcom_scm_call_armv8_32(u32 w0, u32 w1, u32 w2, u32 w3,
Re: [PATCH v3] PCI: Only enable IO window if supported
On Thu, Jul 30, 2015 at 7:15 PM, Guenter Roeck wrote:
> The PCI subsystem always assumes that I/O is supported on PCIe bridges
> and tries to assign an I/O window to each child bus even if that is not
> the case.
>
> This may result in messages such as:
>
> pcieport :02:00.0: res[7]=[io 0x1000-0x0fff] get_res_add_size add_size
> 1000
> pcieport :02:00.0: BAR 7: no space for [io size 0x1000]
> pcieport :02:00.0: BAR 7: failed to assign [io size 0x1000]
>
> for each bridge port, even if a bus or its parent does not support I/O in
> the first place.
>
> To avoid this message, check if a bus supports I/O before trying to enable
> it. Also check if the root bus has an IO window assigned; if not, it does
> not make sense to try to assign one to any of its child busses.
>
>
> diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
> index cefd636681b6..d9e02ba34035 100644
> --- a/drivers/pci/probe.c
> +++ b/drivers/pci/probe.c
> @@ -332,6 +332,24 @@ static void pci_read_bases(struct pci_dev *dev, unsigned
> int howmany, int rom)
> }
> }
>
> +static int pci_bridge_supports_io(struct pci_dev *bridge)
> +{
> + u16 io;
> +
> + pci_read_config_word(bridge, PCI_IO_BASE, );
> + if (io)
> + return 1;
> +
> + /* IO_BASE/LIMIT is either hard-wired to zero or programmed to zero */
> + pci_write_config_word(bridge, PCI_IO_BASE, 0xe0f0);
> + pci_read_config_word(bridge, PCI_IO_BASE, );
> + pci_write_config_word(bridge, PCI_IO_BASE, 0x0);
> + if (io)
> + return 1;
> +
> + return 0;
> +}
> +
> static void pci_read_bridge_io(struct pci_bus *child)
> {
> struct pci_dev *dev = child->self;
> @@ -340,6 +358,15 @@ static void pci_read_bridge_io(struct pci_bus *child)
> struct pci_bus_region region;
> struct resource *res;
>
> + if (!(child->bus_flags & PCI_BUS_FLAGS_SUPPORTS_IO))
> + return;
> +
> + if (!pci_bridge_supports_io(dev)) {
> + dev_printk(KERN_DEBUG, >dev, " no I/O window\n");
> + child->bus_flags &= ~PCI_BUS_FLAGS_SUPPORTS_IO;
> + return;
> + }
> +
It only can avoid warning with bridge, and still have warning on
devices under the bridge.
also would have problem on transparent bridges, like
BRIDGE_A BRIDGE_AADEVICE_AA
|
\-- BRIDGE_AB ---DEVICE_AB
if only BRIDGE_A and BRIDGE_AA are transparent, and BRIDGE_AB is not.
and if pci_bridge_supports_io() return false for BRIDGE_A.
We will have all three bridges have PCI_BUS_FLAGS_SUPPORTS_IO cleared.
so all will not been sized and will not get assigned io port resource.
later DEVICE_AA could root bus io port as parent, and get io resource assigned.
but DEVICE_AB will not get assigned.
so we should get rid of pci_bridge_supports_io(), and just check root
resource IO port.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/3] Add the efuse driver on rockchip platform
On 2015年08月05日 00:11, Srinivas Kandagatla wrote:
Hi Shunqian,
Sorry for delay in reply, I was on Holidays..
Thanks for testing.
On 31/07/15 10:27, Shunqian Zheng wrote:
1. Without the following diff, `hexdump
/sys/bus/nvmem/devices/rockchip-efuse0/nvmem` is wrong with "INVALID
ARGUMENT":
+++ b/drivers/nvmem/core.c
@@ -67,7 +67,7 @@ static ssize_t bin_attr_nvmem_read(struct file *filp,
struct kobject *kobj,
int rc;
/* Stop the user from reading */
- if (pos > nvmem->size)
+ if (pos > nvmem->size - 1)
return 0;
Yes, this should have been something like this
- if (pos > nvmem->size)
+ if (pos >= nvmem->size)
return 0;
We can send a fix on top of v9 once its merged.
if (pos + count > nvmem->size)
RK3288-efuse has 32 x 8bit regs, in dts "reg = <0xffb4 0x20>;"
Here is the message dump from nvmem_device:
[2.158314] nvmem:
[2.158314] name (null)
[2.158314] stride 1
[2.158314] word_size 1
[2.158314] ncells 0
[2.158314] id 0
[2.158314] users 0
[2.158314] size 32
[2.158314] read_only 0
Do you think there is a leak or I'm messing up ?
2. About the read operation, eFuse data can be read during device
probe() and cached, OR,
read from eFuse when needed every time. I prefer the second one but
then, the clock of eFuse may be
gated. So before/after reading I have to enable/disable clk like :
devm_clk_get(dev, "hclk_efuse256");
The trouble is I can't find a way to get the "dev" hander in :
static int rockchip_efuse_read(void *context, const void
*reg, size_t reg_size, void *val, size_t val_size)
I am appreciated if you can give some advice.
May be you should use regmap_init_mmio_clk() instead of
regmap_init_mmio() it will take care of clks.
Thank you for you reply.
Although the regmap_init_mmio_clk() and it's series interface deal with
the clks, but
MMIO uses its own regmap_bus{}, while the eFuse of RK3X need special
read/write
callback functions.
I still can't find a good way to resolve this. Can you help?
Shunqian
Or, do you think it's reasonable to add hooks before/after read in
nvmem/core.c like :
+ before_read(dev, ...);
rc = regmap_raw_read(nvmem->regmap, pos, buf,
count);
+ after_read(dev, ...);
3. In the /sys/bus/nvmem/devices/rockchip-efuse0/, there are files:
/sys/devices/platform/ffb4.efuse/rockchip-efuse0 # ls
nvmem of_nodepower subsystem uevent
Do you have a plan to add the nvmem consumers to /sys/ in nvmem
framework?
yes, Am waiting for the framework to be merged, I have plans to add
this feature.
For example, in dts defined the "cpu_leakage":
efuse: efuse@ffb4 {
compatible = "rockchip,rk3x-efuse";
reg = <0xffb4 0x20>;
#address-cells = <1>;
#size-cells = <1>;
clocks = < PCLK_EFUSE256>;
clock-names = "pclk_efuse_256";
cpu_leakage: cpu_leakage {
reg = <0x17 0x1>;
};
};
Then nvmem exposes the "cpu_leakage" file in /sys which can be
read/write.
--srini
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/3] MIPS: set stack/data protection as non-executable
On 08/05/2015 05:46 PM, Leonid Yegoshin wrote: On 08/05/2015 05:37 PM, David Daney wrote: This just means that your userspace is broken. If GLibC cannot do the right thing then it should be fixed. Let's skip this until you explain how to create a fully non-executable-stack process. Build almost any program with a gcc/glibc from a recent Cavium SDK toolchain. Something like this: mips64-octeon-linux-gnu-gcc -o myprogram myprogram.c You cannot change the default setting for executable stack just because you have created a broken userspace. Please give me at least one example, one existing application which would suffer. Anything compiled with gcj that uses java.lang.reflect.Method.invoke() Anything that uses gcc nested functions. Anything that uses libffi Where an older toolchain that doesn't set PT_GNU_STACK was used. I remember that people already wrote here that this kind of apps (which is based on eXecutable stack and doesn't announce it in PT_GNU_STACK) need to be eliminated. The ability of legacy userspace to continue functioning cannot be sacrificed. Not at any price. However, this switch is a separate patch from others. It can be not applied or it can be applied, depending from prevailing mind - what is more significant, some (unknown) app or non-executable stack protection. - Leonid. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 00/16] ARM: shmobile: Add CPG/MSTP Clock Domain
On Wed, Aug 05, 2015 at 08:58:29AM +0200, Geert Uytterhoeven wrote: > Hi Simon, > > On Wed, Aug 5, 2015 at 2:55 AM, Simon Horman wrote: > > On Tue, Aug 04, 2015 at 10:48:28PM +0900, Simon Horman wrote: > >> I have tentatively queued this up in its own branch, > >> cpg-mstp-clock-domain-for-v4.3. > > > > Where possible I prefer not to apply non-DTS/DTSI patches on top of > > DTS/DTSI patches, I believe this is in keeping with how the ARM SoC > > maintainers like things handled. With this in mind I have shuffled things > > around a little, the result is: > > > > 1. The following are (still) queued up for v4.3 in their own > >cpg-mstp-clock-domain-for-v4.3 branch: > > > >clk: shmobile: Add CPG/MSTP Clock Domain support > >clk: shmobile: r8a7778: Add CPG/MSTP Clock Domain support > >clk: shmobile: r8a7779: Add CPG/MSTP Clock Domain support > >clk: shmobile: rcar-gen2: Add CPG/MSTP Clock Domain support > >clk: shmobile: rz: Add CPG/MSTP Clock Domain support > >ARM: shmobile: r7s72100 dtsi: Add CPG/MSTP Clock Domain > >ARM: shmobile: r8a7778 dtsi: Add CPG/MSTP Clock Domain > >ARM: shmobile: r8a7779 dtsi: Add CPG/MSTP Clock Domain > >ARM: shmobile: r8a7790 dtsi: Add CPG/MSTP Clock Domain > >ARM: shmobile: r8a7791 dtsi: Add CPG/MSTP Clock Domain > >ARM: shmobile: r8a7793 dtsi: Add CPG/MSTP Clock Domain > >ARM: shmobile: r8a7794 dtsi: Add CPG/MSTP Clock Domain > > OK. > > > 2. The following are now queued up for v4.3 in a separate > >sh-drivers-for-v4.3 branch. That branch is on top of the > >cpg-mstp-clock-domain-for-v4.3 branch and I intend to send it directly > >to Linus if/when a v4.3-rc has been released with the patches > >listed in 1. present. > > > >drivers: sh: Disable legacy default PM Domain on emev2 > >drivers: sh: Disable PM runtime for multi-platform ARM with genpd > > OK > > > 3. I have deferred the remaining two patches, listed below, for v4.4. > >they currently reside in cpg-mstp-clock-domain-for-v4.4. That > >branch is based on the sh-drivers-for-v4.3 branch. > > > >clk: shmobile: mstp: Consider "zb_clk" suitable for power management > >ARM: shmobile: R-Mobile: Use CPG/MSTP Clock Domain attach/detach helpers > > > > This means that the last two patches will disappear from next until > > after v4.3-rc1 is released but they, along with all the other patches, > > will be present in the renesas devel branch. > > OK. > > Note that as the last two depend on patch 1 only, you could e.g. queue > them up in group 1, between the clk and dtsi patches. > But it's up to you to reconsider. > I'm happy as-is, as the last two patches are just a code duplication clean up. Thanks, and sorry for not realising that. For now I will keep things as-is because I would like to stabilise my branches. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/3] MIPS: set stack/data protection as non-executable
On 08/05/2015 05:37 PM, David Daney wrote: This just means that your userspace is broken. If GLibC cannot do the right thing then it should be fixed. Let's skip this until you explain how to create a fully non-executable-stack process. GLIBC people is ready to do something but after we remove emulation from stack. You cannot change the default setting for executable stack just because you have created a broken userspace. Please give me at least one example, one existing application which would suffer. I remember that people already wrote here that this kind of apps (which is based on eXecutable stack and doesn't announce it in PT_GNU_STACK) need to be eliminated. The ability of legacy userspace to continue functioning cannot be sacrificed. Not at any price. However, this switch is a separate patch from others. It can be not applied or it can be applied, depending from prevailing mind - what is more significant, some (unknown) app or non-executable stack protection. - Leonid. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/3] MIPS: set stack/data protection as non-executable
On Wed, Aug 05, 2015 at 05:23:55PM -0700, Leonid Yegoshin wrote: > It is actually any application which requests non-executable stack > protection and needs some emulation BEFORE GLIBC cancels that non-executable > stack protection due to libraries. > > If you build all libraries with PT_GNU_STACK 'non-executable' and use > application with the same protection then you can't emulate even a single > instruction - it crashes immediately. So, it is not a bad application, it is > a bad choice for emulation space in past. ...snip... > Create a buildroot FS with PT_GNU_STACK 'non-executable' libraries. Then run > ssh_keygen on CPU without FPU and look. > > You also may try to run MIPS R2 Debian on MIPS R6 CPU, and see a spectacular > failure of ssh_keygen (it tries to emulate MIPS R2 instruction before first > library is loaded and that fails due to non-executable stack protection. All of that sounds like perfectly valid reasons to move the FP branch delay emulation away from using the stack, which we absolutely do need to do. They do not however justify changing the default flags & breaking backwards compatibility. Thanks, Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/3] MIPS: set stack/data protection as non-executable
On 08/05/2015 05:23 PM, Leonid Yegoshin wrote: On 08/05/2015 05:14 PM, David Daney wrote: On 08/05/2015 05:06 PM, Leonid Yegoshin wrote: On 08/05/2015 04:55 PM, Paul Burton wrote: As was pointed out last time you posted this, it breaks backwards compatibility with userland & thus cannot be applied. Never observed since first version. In other side, the problem with apps like ssh_keygen is observed in absence of executable stack protection. You cannot change the default. If your ssh_keygen is broken, get a working version. It is actually any application which requests non-executable stack protection and needs some emulation BEFORE GLIBC cancels that non-executable stack protection due to libraries. If you build all libraries with PT_GNU_STACK 'non-executable' and use application with the same protection then you can't emulate even a single instruction - it crashes immediately. So, it is not a bad application, it is a bad choice for emulation space in past. This just means that your userspace is broken. If GLibC cannot do the right thing then it should be fixed. The very first thing that is executed is ld.so, you need to make your ld.so do the right thing before transferring control to your program's entry point. You cannot change the default setting for executable stack just because you have created a broken userspace. The ability of legacy userspace to continue functioning cannot be sacrificed. David Daney -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] sky2: Add module parameter for passing the MAC address
On 05/08/15 16:16, Stephen Hemminger wrote:
> Something like this:
>
> Subject: [PATCH net-next] sky2: use random address if EEPROM is bad
>
> On some embedded systems the EEPROM does not contain a valid MAC address.
> In that case it is better to fallback to a generated mac address and
> let init scripts fix the value later.
>
> Reported-by: Liviu Dudau
> Signed-off-by: Stephen Hemminger
>
>
> --- a/drivers/net/ethernet/marvell/sky2.c 2015-05-21 15:13:03.621126050
> -0700
> +++ b/drivers/net/ethernet/marvell/sky2.c 2015-08-05 16:12:38.734534467
> -0700
> @@ -4819,6 +4819,16 @@ static struct net_device *sky2_init_netd
> memcpy_fromio(dev->dev_addr, hw->regs + B2_MAC_1 + port * 8,
> ETH_ALEN);
>
> + /* if the address is invalid, use a random value */
> + if (!is_valid_ether_addr(dev->dev_addr)) {
> + struct sockaddr sa = { AF_UNSPEC };
> +
> + netdev_warn(dev,
> + "Invalid MAC address defaulting to random\n");
> + sky2_set_mac_address(dev, );
> + dev->addr_assign_type |= NET_ADDR_RANDOM;
There is a helper for that: eth_hw_addr_random() which sets the
addr_assign_type for you and copies the address to dev->dev_addr.
--
Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 2/2] powerpc32: optimise csum_partial() loop
On Wed, Aug 05, 2015 at 03:29:35PM +0200, Christophe Leroy wrote: > On the 8xx, load latency is 2 cycles and taking branches also takes > 2 cycles. So let's unroll the loop. This is not true for most other 32-bit PowerPC; this patch makes performance worse on e.g. 6xx/7xx/7xxx. Let's not! Segher -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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 13/24] visorbus: switch from ioremap_cache to memremap
On Thu, Jul 30, 2015 at 12:54:51PM -0400, Dan Williams wrote: > In preparation for deprecating ioremap_cache() convert its usage in > visorbus to memremap. > > Cc: Benjamin Romer > Cc: David Kershner > Signed-off-by: Dan Williams > --- > drivers/staging/unisys/visorbus/visorchannel.c | 16 +--- > drivers/staging/unisys/visorbus/visorchipset.c | 17 + > 2 files changed, 18 insertions(+), 15 deletions(-) > Acked-by: Greg Kroah-Hartman -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 5/9] x86/intel_rdt: Add new cgroup and Class of service management
On Wed, Aug 05, 2015 at 01:22:57PM +0100, Matt Fleming wrote:
> On Sun, 02 Aug, at 12:31:57PM, Tejun Heo wrote:
> >
> > But we're doing it the wrong way around. You can do most of what
> > cgroup interface can do with systemcall-like interface with some
> > inconvenience. The other way doesn't really work. As I wrote in the
> > other reply, cgroups is a horrible programmable interface and we don't
> > want individual applications to interact with it directly and CAT's
> > use cases most definitely include each application programming its own
> > cache mask.
>
> I wager that this assertion is wrong. Having individual applications
> program their own cache mask is not going to be the most common
> scenario.
What i like about the syscall interface is that it moves the knowledge
of cache behaviour close to the application launching (or inside it),
which allows the following common scenario, say on a multi purpose
desktop:
Event: launch high performance application: use cache reservation, finish
quickly.
Event: cache hog application: do not thrash the cache.
The two cache reservations are logically unrelated in terms of
configuration, and configured separately do not affect each other.
They should be configured separately.
Also, data/code reservation is specific to the application, so it
should its specification should be close to the application (its just
cumbersome to maintain that data somewhere else).
> Only in very specific situations would you trust an
> application to do that.
Perhaps ulimit can be used to allow a certain limit on applications.
> A much more likely use case is having the sysadmin carve up the cache
> for a workload which may include multiple, uncooperating applications.
Sorry, what cooperating means in this context?
> Yes, a programmable interface would be useful, but only for a limited
> set of workloads. I don't think it's how most people are going to want
> to use this hardware technology.
It seems syscall interface handles all usecases which the cgroup
interface handles.
> --
> Matt Fleming, Intel Open Source Technology Center
Tentative interface, please comment.
The "return key/use key" scheme would allow COSid sharing similarly to
shmget. Intra-application, that is functional, but i am not experienced
with shmget to judge whether there is a better alternative. Would have
to think how cross-application setup would work,
and in the simple "cacheset" configuration.
Also, the interface should work for other architectures (TODO item, PPC
at least has similar functionality).
enum cache_rsvt_flags {
CACHE_RSVT_ROUND_UP = (1 << 0),/* round "bytes" up */
CACHE_RSVT_ROUND_DOWN = (1 << 1),/* round "bytes" down */
CACHE_RSVT_EXTAGENTS = (1 << 2),/* allow usage of area common with
external agents */
};
enum cache_rsvt_type {
CACHE_RSVT_TYPE_CODE = 0, /* cache reservation is for code */
CACHE_RSVT_TYPE_DATA, /* cache reservation is for data */
CACHE_RSVT_TYPE_BOTH, /* cache reservation is for code and data */
};
struct cache_reservation {
size_t kbytes;
u32 type;
u32 flags;
};
int sys_cache_reservation(struct cache_reservation *cv);
returns -ENOMEM if not enough space, -EPERM if no permission.
returns keyid > 0 if reservation has been successful, copying actual
number of kbytes reserved to "kbytes".
-
int sys_use_cache_reservation_key(struct cache_reservation *cv, int
key);
returns -EPERM if no permission.
returns -EINVAL if no such key exists.
returns 0 if instantiation of reservation has been successful,
copying actual reservation to cv.
Backward compatibility for processors with no support for code/data
differentiation: by default code and data cache allocation types
fallback to CACHE_RSVT_TYPE_BOTH on older processors (and return the
information that they done so via "flags").
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/3] MIPS: set stack/data protection as non-executable
On 08/05/2015 05:14 PM, David Daney wrote: On 08/05/2015 05:06 PM, Leonid Yegoshin wrote: On 08/05/2015 04:55 PM, Paul Burton wrote: As was pointed out last time you posted this, it breaks backwards compatibility with userland & thus cannot be applied. Never observed since first version. In other side, the problem with apps like ssh_keygen is observed in absence of executable stack protection. You cannot change the default. If your ssh_keygen is broken, get a working version. It is actually any application which requests non-executable stack protection and needs some emulation BEFORE GLIBC cancels that non-executable stack protection due to libraries. If you build all libraries with PT_GNU_STACK 'non-executable' and use application with the same protection then you can't emulate even a single instruction - it crashes immediately. So, it is not a bad application, it is a bad choice for emulation space in past. I have never had a problem running ssh_keygen (on platforms requiring emulation). Create a buildroot FS with PT_GNU_STACK 'non-executable' libraries. Then run ssh_keygen on CPU without FPU and look. You also may try to run MIPS R2 Debian on MIPS R6 CPU, and see a spectacular failure of ssh_keygen (it tries to emulate MIPS R2 instruction before first library is loaded and that fails due to non-executable stack protection. - Leonid. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.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] sky2: Add module parameter for passing the MAC address
From: Liviu Dudau Date: Wed, 5 Aug 2015 16:50:54 +0100 > For designs where EEPROMs are not connected to PCI Yukon2 > chips we need to get the MAC address from the firmware. > Add a module parameter called 'mac_address' for this. It > will be used if no DT node can be found and the B2_MAC > register holds an invalid value. > > Signed-off-by: Liviu Dudau Sorry, such module options are absolutely not allowed. If an invalid MAC is present, it should be set to a random one via eth_random_addr(). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 REPOST 2/8] staging: rtl8712: simplify size calculation
replace item-by-item size calculation of a struct
with the size of the struct.
This gets rid of a use of typedef NDIS_802_11_RATES_EX
Signed-off-by: Joshua Clayton
---
drivers/staging/rtl8712/rtl871x_cmd.c | 11 +--
1 file changed, 1 insertion(+), 10 deletions(-)
diff --git a/drivers/staging/rtl8712/rtl871x_cmd.c
b/drivers/staging/rtl8712/rtl871x_cmd.c
index e35854d..f07050d 100644
--- a/drivers/staging/rtl8712/rtl871x_cmd.c
+++ b/drivers/staging/rtl8712/rtl871x_cmd.c
@@ -471,7 +471,6 @@ u8 r8712_createbss_cmd(struct _adapter *padapter)
u8 r8712_joinbss_cmd(struct _adapter *padapter, struct wlan_network *pnetwork)
{
- uint t_len = 0;
struct ndis_wlan_bssid_ex *psecnetwork;
struct cmd_obj *pcmd;
struct cmd_priv *pcmdpriv = >cmdpriv;
@@ -486,14 +485,6 @@ u8 r8712_joinbss_cmd(struct _adapter *padapter, struct
wlan_network *pnetwork)
pcmd = kmalloc(sizeof(*pcmd), GFP_ATOMIC);
if (pcmd == NULL)
return _FAIL;
- t_len = sizeof(u32) + 6 * sizeof(unsigned char) + 2 +
- sizeof(struct ndis_802_11_ssid) + sizeof(u32) +
- sizeof(s32) +
- sizeof(enum NDIS_802_11_NETWORK_TYPE) +
- sizeof(struct NDIS_802_11_CONFIGURATION) +
- sizeof(enum NDIS_802_11_NETWORK_INFRASTRUCTURE) +
- sizeof(NDIS_802_11_RATES_EX) +
- sizeof(u32) + MAX_IE_SZ;
/* for hidden ap to set fw_state here */
if (check_fwstate(pmlmepriv, WIFI_STATION_STATE|WIFI_ADHOC_STATE) !=
@@ -516,7 +507,7 @@ u8 r8712_joinbss_cmd(struct _adapter *padapter, struct
wlan_network *pnetwork)
kfree(pcmd);
return _FAIL;
}
- memcpy(psecnetwork, >network, t_len);
+ memcpy(psecnetwork, >network, sizeof(*psecnetwork));
psecuritypriv->authenticator_ie[0] = (unsigned char)
psecnetwork->IELength;
if ((psecnetwork->IELength-12) < (256 - 1))
--
2.5.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/
