Re: [PATCH v3 1/2] dgnc: Remove superfluous EXTRA_CFLAGS variable
On Mon, 2015-02-16 at 12:12 +0300, Dan Carpenter wrote: On Sun, Feb 15, 2015 at 11:40:17PM +, Cass May wrote: Clean up Makefile by removing unnecessary definition of DG_NAME. Signed-off-by: Cass May c...@cassm.net --- Having done some build tests, it seems that DG_NAME is not needed, but DG_PART is referenced in dgnc_mgmt.c. I have removed the former, and moved the latter into the appropriate header. Thanks! Don't resend; this patch is great. But next time just fold both patches together into one patch. It's all part of the same fix really so it falls into the one thing per patch rule. regards, dan carpenter Shall do! Thank you for the guidance. -cass -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.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 v11 19/19] kasan: enable instrumentation of global variables
Can a module be freed in an interrupt?
On Mon, Feb 16, 2015 at 5:44 PM, Andrey Ryabinin a.ryabi...@samsung.com wrote:
On 02/16/2015 05:58 AM, Rusty Russell wrote:
Andrey Ryabinin a.ryabi...@samsung.com writes:
This feature let us to detect accesses out of bounds of
global variables. This will work as for globals in kernel
image, so for globals in modules. Currently this won't work
for symbols in user-specified sections (e.g. __init, __read_mostly, ...)
The idea of this is simple. Compiler increases each global variable
by redzone size and add constructors invoking __asan_register_globals()
function. Information about global variable (address, size,
size with redzone ...) passed to __asan_register_globals() so we could
poison variable's redzone.
This patch also forces module_alloc() to return 8*PAGE_SIZE aligned
address making shadow memory handling (
kasan_module_alloc()/kasan_module_free() )
more simple. Such alignment guarantees that each shadow page backing
modules address space correspond to only one module_alloc() allocation.
Hmm, I understand why you only fixed x86, but it's weird.
I think MODULE_ALIGN belongs in linux/moduleloader.h, and every arch
should be fixed up to use it (though you could leave that for later).
Might as well fix the default implementation at least.
@@ -49,8 +49,15 @@ void kasan_krealloc(const void *object, size_t new_size);
void kasan_slab_alloc(struct kmem_cache *s, void *object);
void kasan_slab_free(struct kmem_cache *s, void *object);
+#define MODULE_ALIGN (PAGE_SIZE KASAN_SHADOW_SCALE_SHIFT)
+
+int kasan_module_alloc(void *addr, size_t size);
+void kasan_module_free(void *addr);
+
#else /* CONFIG_KASAN */
+#define MODULE_ALIGN 1
Hmm, that should be PAGE_SIZE (we assume that in several places).
@@ -1807,6 +1808,7 @@ static void unset_module_init_ro_nx(struct module
*mod) { }
void __weak module_memfree(void *module_region)
{
vfree(module_region);
+kasan_module_free(module_region);
}
This looks racy (memory reuse?). Perhaps try other order?
You are right, it's racy. Concurrent kasan_module_alloc() could fail because
kasan_module_free() wasn't called/finished yet, so whole module_alloc() will
fail
and module loading will fail.
However, I just find out that this race is not the worst problem here.
When vfree(addr) called in interrupt context, memory at addr will be reused
for
storing 'struct llist_node':
void vfree(const void *addr)
{
...
if (unlikely(in_interrupt())) {
struct vfree_deferred *p = this_cpu_ptr(vfree_deferred);
if (llist_add((struct llist_node *)addr, p-list))
schedule_work(p-wq);
In this case we have to free shadow *after* freeing 'module_region', because
'module_region'
is still used in llist_add() and in free_work() latter.
free_work() (in mm/vmalloc.c) processes list in LIFO order, so to free shadow
after freeing
'module_region' kasan_module_free(module_region); should be called before
vfree(module_region);
It will be racy still, but this is not so bad as potential crash that we have
now.
Honestly, I have no idea how to fix this race nicely. Any suggestions?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 6/6] irqchip: gicv3: skip ITS init when no ITS available
Hi Murzin,
On 2015/2/16 18:05, Vladimir Murzin wrote:
Hi Yun,
On 15/02/15 09:32, Yun Wu wrote:
There is one more condition that needs to be considered when judging
whether LPI feature is enabled or not, which is whether there is any
ITS available and correctly enabled.
This patch will fix this by caching ITS enabling status in the GIC
chip data structure.
I posted patch for that before [1] and it landed in Marc's tree
(irq/gic-fixes). It is not clear from the commit message what the one
more condition is, but I guess it is the same dts stuff. Do you see
issue without your patch applied?
Oh yes, your patch perfectly solved this problem, so this one is no longer
needed. And sorry for not noticing your patch. :)
Thanks,
Abel
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/314752.html
Thanks
Vladimir
Signed-off-by: Yun Wu wuyun...@huawei.com
---
drivers/irqchip/irq-gic-v3.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 1a146cc..e17faca 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -47,6 +47,7 @@ struct gic_chip_data {
u64 redist_stride;
u32 nr_redist_regions;
unsigned intirq_nr;
+int lpi_enabled;
};
static struct gic_chip_data gic_data __read_mostly;
@@ -390,11 +391,6 @@ static void gic_cpu_sys_reg_init(void)
gic_write_grpen1(1);
}
-static int gic_dist_supports_lpis(void)
-{
-return !!(readl_relaxed(gic_data.dist_base + GICD_TYPER)
GICD_TYPER_LPIS);
-}
-
static void gic_cpu_init(void)
{
void __iomem *rbase;
@@ -410,7 +406,7 @@ static void gic_cpu_init(void)
gic_cpu_config(rbase, gic_redist_wait_for_rwp);
/* Give LPIs a spin */
-if (IS_ENABLED(CONFIG_ARM_GIC_V3_ITS) gic_dist_supports_lpis())
+if (gic_data.lpi_enabled)
its_cpu_init();
/* initialise system registers */
@@ -629,7 +625,7 @@ static int gic_irq_domain_map(struct irq_domain *d,
unsigned int irq,
}
/* LPIs */
if (hw = 8192 hw GIC_ID_NR) {
-if (!gic_dist_supports_lpis())
+if (!gic_data.lpi_enabled)
return -EPERM;
irq_domain_set_info(d, irq, hw, gic_chip, d-host_data,
handle_fasteoi_irq, NULL, NULL);
@@ -785,8 +781,12 @@ static int __init gic_of_init(struct device_node *node,
struct device_node *pare
set_handle_irq(gic_handle_irq);
-if (IS_ENABLED(CONFIG_ARM_GIC_V3_ITS) gic_dist_supports_lpis())
-its_init(node, gic_data.rdists, gic_data.domain);
+if (IS_ENABLED(CONFIG_ARM_GIC_V3_ITS)
+!!(readl_relaxed(dist_base + GICD_TYPER) GICD_TYPER_LPIS)
+!its_init(node, gic_data.rdists, gic_data.domain))
+gic_data.lpi_enabled = 1;
+else
+gic_data.lpi_enabled = 0;
gic_smp_init();
gic_dist_init();
--
1.8.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] usb: dwc3: Moved PCI IDS to linux/pci_ids.h
On Sun, Feb 15, 2015 at 6:17 PM, Joseph Kogut joseph.ko...@gmail.com wrote:
Moved DWC3 PCI IDS to linux/pci_ids.h per the FIXME.
Signed-off-by: Joseph Kogut joseph.ko...@gmail.com
---
drivers/usb/dwc3/dwc3-pci.c | 10 +-
include/linux/pci_ids.h | 8
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
index 8d95056..19ca7f6 100644
--- a/drivers/usb/dwc3/dwc3-pci.c
+++ b/drivers/usb/dwc3/dwc3-pci.c
@@ -20,19 +20,11 @@
#include linux/module.h
#include linux/slab.h
#include linux/pci.h
+#include linux/pci_ids.h
#include linux/platform_device.h
#include platform_data.h
-/* FIXME define these in linux/pci_ids.h */
-#define PCI_VENDOR_ID_SYNOPSYS 0x16c3
-#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd
-#define PCI_DEVICE_ID_INTEL_BYT0x0f37
-#define PCI_DEVICE_ID_INTEL_MRFLD 0x119e
-#define PCI_DEVICE_ID_INTEL_BSW0x22B7
-#define PCI_DEVICE_ID_INTEL_SPTLP 0x9d30
-#define PCI_DEVICE_ID_INTEL_SPTH 0xa130
It looks like these constants are used only in this file. If that's
the case, the comment at the top of pci_ids.h applies, the definitions
can stay here, and you can just remove the FIXME comment.
static int dwc3_pci_quirks(struct pci_dev *pdev)
{
if (pdev-vendor == PCI_VENDOR_ID_AMD
diff --git a/include/linux/pci_ids.h b/include/linux/pci_ids.h
index e63c02a..6fc5cdd 100644
--- a/include/linux/pci_ids.h
+++ b/include/linux/pci_ids.h
@@ -2312,6 +2312,9 @@
#define PCI_VENDOR_ID_NETCELL 0x169c
#define PCI_DEVICE_ID_REVOLUTION 0x0044
+#define PCI_VENDOR_ID_SYNOPSYS 0x16c3
+#define PCI_DEVICE_ID_SYNOPSYS_HAPSUSB30xabcd
+
#define PCI_VENDOR_ID_CENATEK 0x16CA
#define PCI_DEVICE_ID_CENATEK_IDE 0x0001
@@ -2566,12 +2569,14 @@
#define PCI_DEVICE_ID_INTEL_QUARK_X1000_ILB0x095E
#define PCI_DEVICE_ID_INTEL_I960 0x0960
#define PCI_DEVICE_ID_INTEL_I960RM 0x0962
+#define PCI_DEVICE_ID_INTEL_BYT0x0f37
#define PCI_DEVICE_ID_INTEL_CENTERTON_ILB 0x0c60
#define PCI_DEVICE_ID_INTEL_8257X_SOL 0x1062
#define PCI_DEVICE_ID_INTEL_82573E_SOL 0x1085
#define PCI_DEVICE_ID_INTEL_82573L_SOL 0x108F
#define PCI_DEVICE_ID_INTEL_82815_MC 0x1130
#define PCI_DEVICE_ID_INTEL_82815_CGC 0x1132
+#define PCI_DEVICE_ID_INTEL_MRFLD 0x119e
#define PCI_DEVICE_ID_INTEL_82092AA_0 0x1221
#define PCI_DEVICE_ID_INTEL_7505_0 0x2550
#define PCI_DEVICE_ID_INTEL_7205_0 0x255d
@@ -2593,6 +2598,7 @@
#define PCI_DEVICE_ID_INTEL_PANTHERPOINT_XHCI 0x1e31
#define PCI_DEVICE_ID_INTEL_PANTHERPOINT_LPC_MIN 0x1e40
#define PCI_DEVICE_ID_INTEL_PANTHERPOINT_LPC_MAX 0x1e5f
+#define PCI_DEVICE_ID_INTEL_BSW0x22B7
#define PCI_DEVICE_ID_INTEL_DH89XXCC_LPC_MIN 0x2310
#define PCI_DEVICE_ID_INTEL_DH89XXCC_LPC_MAX 0x231f
#define PCI_DEVICE_ID_INTEL_82801AA_0 0x2410
@@ -2891,6 +2897,8 @@
#define PCI_DEVICE_ID_INTEL_84460GX0x84ea
#define PCI_DEVICE_ID_INTEL_IXP4XX 0x8500
#define PCI_DEVICE_ID_INTEL_IXP28000x9004
+#define PCI_DEVICE_ID_INTEL_SPTLP 0x9d30
+#define PCI_DEVICE_ID_INTEL_SPTH 0xa130
#define PCI_DEVICE_ID_INTEL_S21152BB 0xb152
#define PCI_VENDOR_ID_SCALEMP 0x8686
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] spi: spidev: only use up TX/RX bounce buffer space when needed
This patch changes the way space is reserved in spidev's pre-allocated
TX and RX bounce buffers to avoid wasting space in the buffers for an
SPI message consisting of multiple, half-duplex transfers in different
directions.
Background:
spidev data structures have separate, pre-allocated TX and RX bounce
buffers (`spidev-tx_buffer` and `spidev-rx_buffer`) of fixed size
(`bufsiz`). The `SPI_IOC_MESSAGE(N)` ioctl processing uses a kernel
copy of the N `struct spi_ioc_transfer` elements copied from the
userspace ioctl arg pointer. In these elements: `.len` is the length of
transfer in bytes; `.rx_buf` is either a userspace pointer to a buffer
to copy the RX data to or is set to 0 to discard the data; and `.tx_buf`
is either a userspace pointer to TX data supplied by the user or is set
to 0 to transmit zeros for this transfer.
`spidev_message()` uses the array of N `struct spi_ioc_transfer`
elements to construct a kernel SPI message consisting of a `struct
spi_message` containing a linked list (allocated as an array) of N
`struct spi_transfer` elements. This involves iterating through the
`struct spi_ioc_transfer` and `struct spi_transfer` elements (variables
`u_tmp` and `k_tmp` respectively). Before the first iteration,
variables `tx_buf` and `rx_buf` point to the start of the TX and RX
bounce buffers `spidev-tx_buffer` and `spidev-rx_buffer` and variable
`total` is set to 0. These variables keep track of the next available
space in the bounce buffers and the total length of the SPI message.
Each iteration checks that there is enough room left in the buffers for
the transfer. If `u_tmp-rx_buf` is non-zero, `k_tmp-rx_buf` is set to
`rx_buf`, otherwise it remains set to NULL. If `u_tmp-tx_buf` is
non-zero, `k_tmp-tx_buf` is set to `tx_buf` and the userspace TX data
copied there, otherwise it remains set to NULL. The variables `total`,
`rx_buf` and `tx_buf` are advanced by the length of the transfer.
The problem:
While iterating through the transfers, the local bounce buffer free
space pointer variables `tx_buf` and `rx_buf` are always advanced by
the length of the transfer. If `u_tmp-rx_buf` is 0 (so `k_tmp-rx_buf`
is NULL), then `rx_buf` is advanced unnecessarily and that part of
`spidev-rx_buffer` is wasted. Similarly, if `u_tmp-tx_buf` is 0 (so
`k_tmp-tx_buf` is NULL), part of `spidev-tx_buffer` is wasted.
What this patch does:
To avoid wasting space unnecessarily in the RX bounce buffer, only
advance `rx_buf` by the transfer length if `u_tmp-rx_buf` is non-zero.
Similarly, to avoid wasting space unnecessarily in the TX bounce buffer,
only advance `tx_buf` if `u_tmp-tx_buf is non-zero. To avoid pointer
subtraction, use new variables `rx_total` and `tx_total` to keep track
of the amount of space allocated in each of the bounce buffers. If
these exceed the available space, a `-EMSGSIZE` error will be returned.
Limit the total length of the transfers (tracked by variable `total`) to
`INT_MAX` instead of `bufsiz`, returning an `-EMSGSIZE` error if
exceeded. The total length is returned by `spidev_message()` on success
and we want that to be non-negative. The message size limits for the
`SPI_IOC_MESSAGE(N)` ioctl are now as follows:
(a) total length of transfers is = INTMAX;
(b) total length of transfers with non-NULL rx_buf is = bufsiz;
(c) total length of transfers with non-NULL tx_buf is = bufsiz.
Some transfers may have NULL rx_buf and NULL tx_buf.
If the transfer is completed successfully by the SPI core,
`spidev_message()` iterates through the transfers to copy any RX data
from the bounce buffer back to userspace on those transfers where
`u_tmp-rx_buf` is non-zero. The variable `rx_buf` is again used to
keep track of the corresponding positions in the bounce buffer. Now it
is only advanced for those transfers that use the RX bounce buffer.
Signed-off-by: Ian Abbott abbo...@mev.co.uk
---
v2: Add some comments. Redo the commit message.
---
drivers/spi/spidev.c | 28 +++-
1 file changed, 23 insertions(+), 5 deletions(-)
diff --git a/drivers/spi/spidev.c b/drivers/spi/spidev.c
index d1ccbfe..2cb5c57 100644
--- a/drivers/spi/spidev.c
+++ b/drivers/spi/spidev.c
@@ -227,7 +227,7 @@ static int spidev_message(struct spidev_data *spidev,
struct spi_transfer *k_xfers;
struct spi_transfer *k_tmp;
struct spi_ioc_transfer *u_tmp;
- unsignedn, total;
+ unsignedn, total, tx_total, rx_total;
u8 *tx_buf, *rx_buf;
int status = -EFAULT;
@@ -243,33 +243,51 @@ static int spidev_message(struct spidev_data *spidev,
tx_buf = spidev-tx_buffer;
rx_buf = spidev-rx_buffer;
total = 0;
+ tx_total = 0;
+ rx_total = 0;
for (n = n_xfers, k_tmp = k_xfers, u_tmp = u_xfers;
n;
n--, k_tmp++, u_tmp++) {
k_tmp-len = u_tmp-len;
total +=
Re: [PATCH v11 19/19] kasan: enable instrumentation of global variables
On 02/16/2015 05:47 PM, Dmitry Vyukov wrote: Can a module be freed in an interrupt? Since commit: c749637909ee (module: fix race in kallsyms resolution during module load success.) module's init section always freed rcu callback (rcu callbacks executed from softirq) Currently, with DEBUG_PAGEALLOC and KASAN module loading always causing kernel crash. It's harder to trigger this without DEBUG_PAGEALLOC because of lazy tlb flushing in vmalloc. BUG: unable to handle kernel paging request at fbfff4011000 IP: [811d8f7b] __asan_load8+0x2b/0xa0 PGD 7ffa3063 PUD 7ffa2063 PMD 484ea067 PTE 0 Oops: [#1] SMP DEBUG_PAGEALLOC KASAN Dumping ftrace buffer: (ftrace buffer empty) Modules linked in: ipv6 CPU: 0 PID: 30 Comm: kworker/0:1 Tainted: GW 3.19.0-rc7-next-20150209+ #209 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014 Workqueue: events free_work task: 88006c5a8870 ti: 88006c63 task.ti: 88006c63 RIP: 0010:[811d8f7b] [811d8f7b] __asan_load8+0x2b/0xa0 RSP: 0018:88006c637cd8 EFLAGS: 00010286 RAX: fbfff4011000 RBX: a0088000 RCX: ed000da000a9 RDX: dc00 RSI: 0001 RDI: a0088000 RBP: 88006c637d08 R08: R09: 88006d007840 R10: 88006d000540 R11: ed000da000a9 R12: a0088000 R13: 88006d61a5d8 R14: 88006d61a5d8 R15: 88006d61a5c0 FS: () GS:88006d60() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: fbfff4011000 CR3: 4d967000 CR4: 06b0 Stack: 88006c637ce8 fbfff4011000 a0088000 88006d61a5d8 88006d61a5d8 88006d61a5c0 88006c637d28 811bb1b8 88006c5bc618 88006d617b28 88006c637db8 8108e1b0 Call Trace: [811bb1b8] free_work+0x38/0x60 [8108e1b0] process_one_work+0x2a0/0x7d0 [8108f653] worker_thread+0x93/0x840 [8108f5c0] ? init_pwq.part.11+0x10/0x10 [81096f37] kthread+0x177/0x1a0 [81096dc0] ? kthread_worker_fn+0x290/0x290 [81096dc0] ? kthread_worker_fn+0x290/0x290 [8158cd7c] ret_from_fork+0x7c/0xb0 [81096dc0] ? kthread_worker_fn+0x290/0x290 Code: 48 b8 ff ff ff ff ff 7f ff ff 55 48 89 e5 48 83 ec 30 48 39 c7 76 59 48 ba 00 00 00 00 00 fc ff df 48 89 f8 48 c1 e8 03 48 01 d0 66 83 38 00 75 07 c9 c3 0f 1f 44 00 00 48 8d 4f 07 48 89 ce 48 RIP [811d8f7b] __asan_load8+0x2b/0xa0 RSP 88006c637cd8 CR2: fbfff4011000 ---[ end trace b9411d841784b6cf ]--- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [sched] BUG: kernel boot hang
On Sun, Feb 15, 2015 at 01:18:07PM -0500, Steven Rostedt wrote:
On Sun, 15 Feb 2015 16:46:22 +0100
Frederic Weisbecker fweis...@gmail.com wrote:
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index c017a5f..a6d4d6c 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -2879,7 +2879,7 @@ void __sched schedule_preempt_disabled(void)
preempt_disable();
}
-static void preempt_schedule_common(void)
+static void __sched notrace preempt_schedule_common(void)
{
do {
preempt_count_add(PREEMPT_ACTIVE);
Ah, since I added better recursion protection code in function tracer
this didn't break that. But unfortunately, function graph tracer
doesn't have that protection.
If it traces between preempt_schedule() and where it sets
PREEMPT_ACTIVE, it can indeed go into an infinite recursion. Yeah,
preempt_schedule_common() should be notrace, at least until we change
function_graph to have that recursion protection.
Acked-by: Steven Rostedt rost...@goodmis.org
Can someone shoot me a proper patch with Changelog and such?
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.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] mfd: Add support for COMe-cBL6 to Kontron PLD driver
On Tue, 27 Jan 2015, Michael Brunner wrote: This patch adds the DMI system ID of the Kontron COMe-cBL6 board to the Kontron PLD driver. The list of supported products in the module description is also updated. Signed-off-by: Michael Brunner michael.brun...@kontron.com Acked-by: Christian Rauch christian.ra...@kontron.com --- drivers/mfd/Kconfig | 1 + drivers/mfd/kempld-core.c | 11 +-- 2 files changed, 10 insertions(+), 2 deletions(-) Applied, thanks. -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] Documentation/robust-futex-API: remove alternative language
The man-pages as well as robust-futexes.txt use the word contend for a situation where two threads try to access the same futex at the same time. To avoid confusion robust-futex-API.txt should not use contest as alternative language. Signed-off-by: Heinrich Schuchardt xypron.g...@gmx.de --- Documentation/robust-futex-ABI.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/robust-futex-ABI.txt b/Documentation/robust-futex-ABI.txt index 16eb314..e6a5532 100644 --- a/Documentation/robust-futex-ABI.txt +++ b/Documentation/robust-futex-ABI.txt @@ -18,8 +18,8 @@ required for futexes is: by the exiting thread. The existing normal futexes already provide a Fast Userspace Locking -mechanism, which handles uncontested locking without needing a system -call, and handles contested locking by maintaining a list of waiting +mechanism, which handles uncontended locking without needing a system +call, and handles contended locking by maintaining a list of waiting threads in the kernel. Options on the sys_futex(2) system call support waiting on a particular futex, and waking up the next waiter on a particular futex. -- 2.1.4 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] thermal: exynos: Fix NULL pointer exception during kernel booting
Hi Chanwoo,
This patch fixes the NULL pointer exception during kernel booting.
The thermal_zone _of_sensor_register() registers a sensor to DT
thermal zone and then read the current temperature by '.get_temp'
callback. The callback function of exynos thermal driver is
exynos_get_temp() which must need the 'pdata' instance of exynos_tmu
_platform_data structure.
- exynos_get_temp() - code_to_temp() - Must need the 'pdata'
instance
But, exynos thermal driver is executed before getting the 'pdata'
instance. To avoid the kernel panic, have to get the platform data by
executing the exynos_map_dt_data() before calling
thermal_zone_of_sensor_register() .
I've already prepared patch for this (unfortunately it isn't yet
applied to mainline):
[PATCH] thermal: exynos: fix: Check if data-tmu_read callback is
present before read
http://www.spinics.net/lists/linux-samsung-soc/msg42245.html
Does applying this patch help?
BTW: How can I reproduce this error? Could you point me the SHA1 and
repository?
- kernel panic log
[ 4211.324346] PC is at 0x0
[ 4211.326867] LR is at exynos_get_temp+0x3c/0xe4
[ 4211.331289] pc : [] lr : [ffc0004df460]
[snip]
[ 4211.940625] [ (null)] (null)
[ 4211.945315] [ffc0004de6d8] of_thermal_get_temp+0x1c/0x30
[ 4211.951132] [ffc0004db86c] thermal_zone_get_temp+0x48/0x7c
[ 4211.957118] [ffc0004dd278]
thermal_zone_device_update+0x20/0x110 [ 4211.963627]
[ffc0004de9c8] of_thermal_set_mode+0x44/0x68 [ 4211.969443]
[ffc0004decb8] thermal_zone_of_sensor_register+0x15c/0x1d8
[ 4211.976475] [ffc0004dfbe4] exynos_tmu_probe+0x6c/0x814
[ 4211.982120] [ffc0003ef808] platform_drv_probe+0x48/0xb8
[ 4211.987846] [ffc0003edb28] driver_probe_device+0x8c/0x244
[ 4211.993747] [ffc0003eddcc] __driver_attach+0x98/0xa0
[ 4211.999216] [ffc0003ebea0] bus_for_each_dev+0x54/0x98
[ 4212.004771] [ffc0003ed66c] driver_attach+0x1c/0x28
[ 4212.010066] [ffc0003ed2e8] bus_add_driver+0x150/0x208
[ 4212.015622] [ffc0003ee6a4] driver_register+0x5c/0x11c
[ 4212.021178] [ffc0003ef73c]
__platform_driver_register+0x5c/0x68 [ 4212.027600]
[ffc000b64eb8] exynos_tmu_driver_init+0x14/0x20 [ 4212.033678]
[ffc828d4] do_one_initcall+0x88/0x1a0 [ 4212.039235]
[ffc000b34b34] kernel_init_freeable+0x1bc/0x260 [ 4212.045311]
[ffc0007e9fd4] kernel_init+0xc/0xd8
Cc: Zhang Rui rui.zh...@intel.com
Cc: Eduardo Valentin edubez...@gmail.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c index fbeedc0..b8846f1 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -1147,17 +1147,17 @@ static int exynos_tmu_probe(struct
platform_device *pdev) platform_set_drvdata(pdev, data);
mutex_init(data-lock);
+ ret = exynos_map_dt_data(pdev);
+ if (ret)
+ return ret;
+ pdata = data-pdata;
+
data-tzd = thermal_zone_of_sensor_register(pdev-dev, 0,
data, exynos_sensor_ops);
if (IS_ERR(data-tzd)) {
pr_err(thermal: tz: %p ERROR\n, data-tzd);
return PTR_ERR(data-tzd);
}
- ret = exynos_map_dt_data(pdev);
- if (ret)
- goto err_sensor;
-
- pdata = data-pdata;
INIT_WORK(data-irq_work, exynos_tmu_work);
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform 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/
Re: [PATCH 3/3] thermal: exynos: Clean-up code to use oneline entry for exynos compatible table
Hi Chanwoo,
This patch cleanup the code to use oneline for entry of exynos
compatible table.
Cc: Zhang Rui rui.zh...@intel.com
Cc: Eduardo Valentin edubez...@gmail.com
Signed-off-by: Chanwoo Choi cw00.c...@samsung.com
---
drivers/thermal/samsung/exynos_tmu.c | 38
++-- 1 file changed, 10
insertions(+), 28 deletions(-)
diff --git a/drivers/thermal/samsung/exynos_tmu.c
b/drivers/thermal/samsung/exynos_tmu.c index b199fff..7e6baf5 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -919,34 +919,16 @@ static irqreturn_t exynos_tmu_irq(int irq, void
*id) }
static const struct of_device_id exynos_tmu_match[] = {
- {
- .compatible = samsung,exynos3250-tmu,
- },
- {
- .compatible = samsung,exynos4210-tmu,
- },
- {
- .compatible = samsung,exynos4412-tmu,
- },
- {
- .compatible = samsung,exynos5250-tmu,
- },
- {
- .compatible = samsung,exynos5260-tmu,
- },
- {
- .compatible = samsung,exynos5420-tmu,
- },
- {
- .compatible = samsung,exynos5420-tmu-ext-triminfo,
- },
- {
- .compatible = samsung,exynos5440-tmu,
- },
- {
- .compatible = samsung,exynos7-tmu,
- },
- {},
+ { .compatible = samsung,exynos3250-tmu, },
+ { .compatible = samsung,exynos4210-tmu, },
+ { .compatible = samsung,exynos4412-tmu, },
+ { .compatible = samsung,exynos5250-tmu, },
+ { .compatible = samsung,exynos5260-tmu, },
+ { .compatible = samsung,exynos5420-tmu, },
+ { .compatible = samsung,exynos5420-tmu-ext-triminfo, },
+ { .compatible = samsung,exynos5440-tmu, },
+ { .compatible = samsung,exynos7-tmu, },
+ { /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, exynos_tmu_match);
Acked-by: Lukasz Majewski l.majew...@samsung.com
Thanks for clean up!
--
Best regards,
Lukasz Majewski
Samsung RD Institute Poland (SRPOL) | Linux Platform 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/
Re: [PATCH 2/2] INPUT/HID: add touch support for SiS touch driver
On Thu, 2015-02-12 at 15:24 +0800, 曾婷葳 (tammy_tseng) wrote:
Sorry. Re-send the code diff again.
Here is the hid touch driver for sis touch controller.
Thanks.
This driver does very strange things. It looks like you are
simulating a disconnect() to the usbhid driver currently driving
the device. This is unacceptable. Please add the device to the
generic blacklist and implement a clean open/close.
Regards
Oliver
Tammy
-
linux-3.18.5/drivers/hid/Kconfig | 14 ++
linux-3.18.5/drivers/hid/hid-ids.h | 1 +
linux-3.18.5/drivers/hid/hid-multitouch.c| 16 ++
linux-3.18.5/drivers/hid/hid-sis_ctrl.c | 360 +++
linux-3.18.5/drivers/hid/usbhid/hid-quirks.c | 1 +
5 files changed, 392 insertions(+)
-
diff --git a/linux-3.18.5/drivers/hid/Kconfig
b/linux-3.18.5/drivers/hid/Kconfig
index f42df4d..2235cfe 100644
--- a/linux-3.18.5/drivers/hid/Kconfig
+++ b/linux-3.18.5/drivers/hid/Kconfig
@@ -496,6 +496,20 @@ config HID_MULTITOUCH
To compile this driver as a module, choose M here: the
module will be called hid-multitouch.
+config HID_SIS_CTRL
+ bool SiS Touch Device Controller
+ depends on HID_MULTITOUCH
+ ---help---
+ Support for SiS Touch devices update FW.
+
+config DEBUG_HID_SIS_UPDATE_FW
+ bool SiS Touch device debug message(update firmware)
+ depends on HID_SIS_CTRL
+ default n
+ ---help---
+Say Y here if you want to enable debug message(update firmware) for
SiS Touch
+ devices. Must enable config HID_SIS_UPDATE_FW first.
+
config HID_NTRIG
tristate N-Trig touch screen
depends on USB_HID
diff --git a/linux-3.18.5/drivers/hid/hid-ids.h
b/linux-3.18.5/drivers/hid/hid-ids.h
index 0e28190..b9ca441 100644
--- a/linux-3.18.5/drivers/hid/hid-ids.h
+++ b/linux-3.18.5/drivers/hid/hid-ids.h
@@ -809,6 +809,7 @@
#define USB_VENDOR_ID_SIS_TOUCH0x0457
#define USB_DEVICE_ID_SIS9200_TOUCH 0x9200
#define USB_DEVICE_ID_SIS817_TOUCH0x0817
+#define USB_DEVICE_ID_SISF817_TOUCH 0xF817
#define USB_DEVICE_ID_SIS_TS 0x1013
#define USB_DEVICE_ID_SIS1030_TOUCH 0x1030
diff --git a/linux-3.18.5/drivers/hid/hid-multitouch.c
b/linux-3.18.5/drivers/hid/hid-multitouch.c
index 51e25b9..11d67bc 100644
--- a/linux-3.18.5/drivers/hid/hid-multitouch.c
+++ b/linux-3.18.5/drivers/hid/hid-multitouch.c
@@ -54,6 +54,10 @@ MODULE_LICENSE(GPL);
#include hid-ids.h
+#ifdef CONFIG_HID_SIS_CTRL
+#include hid-sis_ctrl.c
+#endif
+
/* quirks to control the device */
#define MT_QUIRK_NOT_SEEN_MEANS_UP (1 0)
#define MT_QUIRK_SLOT_IS_CONTACTID (1 1)
@@ -951,6 +955,14 @@ static int mt_probe(struct hid_device *hdev, const
struct hid_device_id *id)
}
}
+#ifdef CONFIG_HID_SIS_CTRL
+ if (hdev-vendor == USB_VENDOR_ID_SIS_TOUCH) {
+ ret = sis_setup_chardev(hdev);
+ if (ret)
+ dev_err(hdev-dev, sis_setup_chardev fail\n);
+ }
+#endif
+
/* This allows the driver to correctly support devices
* that emit events over several HID messages.
*/
@@ -1043,6 +1055,10 @@ static void mt_remove(struct hid_device *hdev) {
sysfs_remove_group(hdev-dev.kobj, mt_attribute_group);
hid_hw_stop(hdev);
+#ifdef CONFIG_HID_SIS_CTRL
+ if (hdev-vendor == USB_VENDOR_ID_SIS_TOUCH)
+ sis_deinit_chardev();
+#endif
}
/*
diff --git a/linux-3.18.5/drivers/hid/hid-sis_ctrl.c
b/linux-3.18.5/drivers/hid/hid-sis_ctrl.c
new file mode 100644
index 000..3a7b3df
--- /dev/null
+++ b/linux-3.18.5/drivers/hid/hid-sis_ctrl.c
@@ -0,0 +1,360 @@
+/*
+ * Character device driver for SIS multitouch panels control
+ *
+ * Copyright (c) 2009 SIS, Ltd.
+ *
+ */
+
+/*
+ * This program is free software; you can redistribute it and/or modify
+it
+ * under the terms of the GNU General Public License as published by
+the Free
+ * Software Foundation; either version 2 of the License, or (at your
+option)
+ * any later version.
+ */
+
+#include linux/hid.h
+#include linux/module.h
+#include linux/usb.h
+#include usbhid/usbhid.h
+#include linux/init.h
+
+/*update FW*/
+#include linux/fs.h
+#include linux/cdev.h
+/*#include asm/uaccess.h*/ /*copy_from_user() copy_to_user()*/
+#include linux/uaccess.h
+
+#include hid-ids.h
+
+#define SIS817_DEVICE_NAME sis_aegis_hid_touch_device
+#define SISF817_DEVICE_NAME sis_aegis_hid_bridge_touch_device
+
+#define CTRL 0
+#define ENDP_01 1
+#define ENDP_02 2
+#define DIR_IN 0x1
+
+#define SIS_ERR_ALLOCATE_KERNEL_MEM-12 /* Allocate memory fail */
+#define SIS_ERR_COPY_FROM_USER -14 /* Copy data from user fail */
+#define SIS_ERR_COPY_FROM_KERNEL -19 /* Copy data from kernel fail */
You _must_ use the symbolic names. You cannot use numbers.
+
+static const int
Re: [sched/deadline] kernel BUG at kernel/sched/deadline.c:805!
Hi, On 16/02/15 14:44, Peter Zijlstra wrote: On Mon, Feb 16, 2015 at 02:08:21PM +0100, Peter Zijlstra wrote: On Mon, Feb 16, 2015 at 03:38:34PM +0300, Kirill Tkhai wrote: We shouldn't enqueue migrating tasks. Please, try this one instead ;) Ha, we should amend that task-rq-lock loop for that. See below. I've not yet tested; going to try and reconstruct a .config that triggers the oops. OK, I had to remove -enable-kvm from Wu's script, otherwise the test would not hit the CBS limit, and then I had to remove the panic on softlockup because well, qemu is so slow you're going to hit that :-) But the good news is that I could reproduce and this patch does indeed seem to solve it. I also tested this on top of tip, with kvm actually. So, 1019a359d3dc seemed to reintroduce what aee38ea95419 sched/deadline: Fix races between rt_mutex_setprio() and dl_task_timer() fixed. But, this patch seems to fix it again :). Thanks, - Juri -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [LKP] [mutex] 871a6bb4916: -1.8% will-it-scale.per_process_ops, -98.3% will-it-scale.time.voluntary_context_switches, +209.6% will-it-scale.time.involuntary_context_switches
On Sun, Feb 15, 2015 at 03:46:54PM +0800, Huang Ying wrote: FYI, we noticed the below changes on git://git.kernel.org/pub/scm/linux/kernel/git/peterz/queue.git locking/core commit 871a6bb4916fef3123b6ff749b0dc82680fb0d2a (mutex: In mutex_spin_on_owner(), return true when owner changes) testbox/testcase/testparams: wsm/will-it-scale/performance-writeseek3 e07e0d4cb0c4bfe8 871a6bb4916fef3123b6ff749b -- %stddev %change %stddev \ |\ 24972759 ± 2% -98.3% 417134 ± 9% will-it-scale.time.voluntary_context_switches 2223 ± 49%+209.6% 6884 ± 10% will-it-scale.time.involuntary_context_switches 542 ± 32% +91.3% 1037 ± 0% will-it-scale.time.system_time 186 ± 30% +86.3%347 ± 0% will-it-scale.time.percent_of_cpu_this_job_got 26.11 ± 5% -22.7% 20.18 ± 2% will-it-scale.time.user_time 0.09 ± 1% -18.2% 0.07 ± 1% will-it-scale.scalability 783528 ± 0% -1.8% 769550 ± 0% will-it-scale.per_process_ops 12.27 ± 10%+492.7% 72.73 ± 1% perf-profile.cpu-cycles.mutex_optimistic_spin.__mutex_lock_slowpath.mutex_lock.generic_file_write_iter.new_sync_write 3.22 ± 26% +1718.0% 58.50 ± 1% perf-profile.cpu-cycles.osq_lock.mutex_optimistic_spin.__mutex_lock_slowpath.mutex_lock.generic_file_write_iter Do you have the results for more/different performance tests for this commit? Jason mentioned seeing +5% on one (fserver). So if, for multiple tests, we see an avg improvement, we might trade that for this one regression. If otoh we see a net negative, we'll have to go do something about 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/
Re: [PATCH 0/8] x86,fpu: various small FPU cleanups and optimizations
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/06/2015 03:01 PM, r...@redhat.com wrote: This includes the three patches by Oleg that are not in -tip yet, and five more by myself. I believe the changes to my patches address all the comments by reviewers on the previous version. Ingo, Borislav, Peter, what can I do to get these patches merged? kind regards, Rik - -- All rights reversed -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU4gwbAAoJEM553pKExN6DeccH/1W8AqviPWFRd0GTwU2BuswK YFoF6F/Hn/TGtAVUEkdB+7m3jJGDwPVj0UNC4osaP7mHtb8KY2snlzrUmPmreuw1 Y6lxCcx7y3CkD6UQJ4v7CJSAqdRwaQq+YB2llx/fprQkRmZIMuQQHTGGbYgg0uoG pOxEYn6LvuFQzZlnvbpJNf0xKjLQzGNUukzXTiSpvp1q2HG3QCJj3IbULhzxEB4g r+y9ePxej1ijiuqvaK/3rV3M7clUV5axZH+V0PH3Fk4mPgWk/8Zy5x4l1q8Al6YK Tk/hIkWySCHpAgQZvZATtVwc6ilZ79rzmZlenGUJ5sY7XjUz0cWeaCUxgh0jgrU= =yljP -END PGP SIGNATURE- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2] ARM: smp: Only expose /sys/.../cpuX/online if hotpluggable
On Fri, Feb 13, 2015 at 11:01:37PM +, Russell King - ARM Linux wrote: On Fri, Feb 13, 2015 at 09:44:50PM +, Magnus Damm wrote: Also, based on the comment in mcpm_cpu_can_disable() it looks like the PSCI hook may be executed once only with your change in place? Hopefully PSCI is OK not being invoked for every CPU shutdown. This is why I've said (in the parent thread) that I'm not happy to apply this patch. Mark Rutland has indicated that he has MCPM cases where the CPUs which can be disabled changes dynamically according to the secure firmware requirements, and ripping out todays infrastructure in light of that, only to have to add it back again later makes no sense. To clarify, PSCI and MCPM are unrelated. It was originally conceived that MCPM would use PSCI as a backend, but it turns out that they're effectively mutually exclusive, and are handled separately. I still want to add support for MIGRATE in the PSCI client code, but this is independent of MCPM. In some cases it's possible to determine at boot time that a CPU cannot be hotplugged (e.g. in PSCI if the TOS is non-migrateable), so having separate hooks for determining that static and dynamic ability to hotplug a CPU sounds reasonable to me. Thanks, Mark. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/3] lib/plist: Provide plist_add_head() for nodes with the same prio
On Mon, 16 Feb 2015 17:32:22 +0800
Xunlei Pang xlp...@126.com wrote:
From: Xunlei Pang pang.xun...@linaro.org
If there're multiple nodes with the same prio as @node, currently
plist_add() will add @node behind all of them. Now we need to add
@node before all of these nodes for SMP RT scheduler.
This patch adds a common __plist_add() for adding @node before or
behind existing nodes with the same prio, then adds plist_add_head()
and plist_add_tail() inline wrapper functions for convenient uses.
Finally, define plist_add() with plist_add_tail() which has the same
behaviour as before.
Signed-off-by: Xunlei Pang pang.xun...@linaro.org
---
include/linux/plist.h | 30 +-
lib/plist.c | 15 ---
2 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/include/linux/plist.h b/include/linux/plist.h
index 9788360..e17bb96 100644
--- a/include/linux/plist.h
+++ b/include/linux/plist.h
@@ -138,7 +138,35 @@ static inline void plist_node_init(struct plist_node
*node, int prio)
INIT_LIST_HEAD(node-node_list);
}
-extern void plist_add(struct plist_node *node, struct plist_head *head);
+extern void __plist_add(struct plist_node *node,
+ struct plist_head *head, bool is_head);
+
+/**
+ * plist_add_head - add @node to @head, before all existing same-prio nodes
+ *
+ * @node:struct plist_node pointer
+ * @head:struct plist_head pointer
+ */
+static inline
+void plist_add_head(struct plist_node *node, struct plist_head *head)
+{
+ __plist_add(node, head, 1);
is_head is boolean, shouldn't that be true instead of 1.
+}
+
+/**
+ * plist_add_tail - add @node to @head, after all existing same-prio nodes
+ *
+ * @node:struct plist_node pointer
+ * @head:struct plist_head pointer
+ */
+static inline
+void plist_add_tail(struct plist_node *node, struct plist_head *head)
+{
+ __plist_add(node, head, 0);
And false here.
+}
+
+#define plist_add plist_add_tail
+
extern void plist_del(struct plist_node *node, struct plist_head *head);
extern void plist_requeue(struct plist_node *node, struct plist_head *head);
diff --git a/lib/plist.c b/lib/plist.c
index d408e77..0e1f1b3 100644
--- a/lib/plist.c
+++ b/lib/plist.c
@@ -67,12 +67,16 @@ static void plist_check_head(struct plist_head *head)
#endif
/**
- * plist_add - add @node to @head
+ * __plist_add - add @node to @head
*
* @node:struct plist_node pointer
* @head:struct plist_head pointer
+ * @is_head: bool
+ *
+ * If there're any nodes with the same prio, add @node
+ * behind or before all of them according to @is_head.
*/
-void plist_add(struct plist_node *node, struct plist_head *head)
+void __plist_add(struct plist_node *node, struct plist_head *head, bool
is_head)
{
struct plist_node *first, *iter, *prev = NULL;
struct list_head *node_next = head-node_list;
@@ -97,8 +101,13 @@ void plist_add(struct plist_node *node, struct plist_head
*head)
struct plist_node, prio_list);
} while (iter != first);
- if (!prev || prev-prio != node-prio)
+ if (!prev || prev-prio != node-prio) {
list_add_tail(node-prio_list, iter-prio_list);
+ } else if (is_head) {
+ list_add(node-prio_list, prev-prio_list);
+ list_del_init(prev-prio_list);
+ node_next = prev-node_list;
The above could use some comments. I would say the entire plist code
could use more comments, but that's out of scope with this series. But
at least lets add comments when adding new code. Something like:
} else if (is_head) {
/*
* prev has the same priority as the node that is
* being added. It is also the first node for this
* priority, but the new node needs to be added ahead of
* it. To accomplish this, insert node right after prev
* in the prio_list and then remove prev from that list.
* Then set node_next to prev-node_list so that the
* new node gets added before prev and not iter.
*/
Something like that, because it took me some time to figure out how
plist works. It's one of those algorithms that seem to page fault out
quickly, and takes some time to page fault back into one's mind.
-- Steve
+ }
ins_node:
list_add_tail(node-node_list, node_next);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/3] sched/rt: Fix wrong SMP scheduler behavior for equal prio cases
On Mon, 16 Feb 2015 17:32:23 +0800 Xunlei Pang xlp...@126.com wrote: From: Xunlei Pang pang.xun...@linaro.org Currently, SMP RT scheduler has some trouble in dealing with equal prio cases. For example, in check_preempt_equal_prio(): When RT1(current task) gets preempted by RT2, if there is a migratable RT3 with same prio, RT3 will be pushed away instead of RT1 afterwards, because RT1 will be enqueued to the tail of the pushable list when going through succeeding put_prev_task_rt() triggered by resched. This broke FIFO. Furthermore, this is also problematic for normal preempted cases if there're some rt tasks queued with the same prio as current, because current will be put behind these tasks in the pushable queue. So, if a task is running and gets preempted by a higher priority task (or even with same priority for migrating), this patch ensures that it is put before any existing task with the same priority in the pushable queue. Signed-off-by: Xunlei Pang pang.xun...@linaro.org I'd love to review this now, but unfortunately I need to get ready for my trip to Linux Collab. I'll get back to this next week. Feel free to ping me then. If I have time, I might review this while at the conference, but don't place any bets that I will. -- Steve -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] INPUT/HID: add touch support for SiS touch driver
On Mon, Feb 16, 2015 at 10:10 AM, Oliver Neukum oneu...@suse.de wrote:
On Thu, 2015-02-12 at 15:24 +0800, 曾婷葳 (tammy_tseng) wrote:
Sorry. Re-send the code diff again.
Here is the hid touch driver for sis touch controller.
Thanks.
This driver does very strange things. It looks like you are
simulating a disconnect() to the usbhid driver currently driving
the device. This is unacceptable. Please add the device to the
generic blacklist and implement a clean open/close.
Indeed, this driver does very strange things.
At least you should explain in the commit messages why you need to
have a custom chardev in the hid tree and why using a plain HID
communication is not enough while discussing with the hardware.
Also, I am not especially happy with your way of quirking
hid-multitouch in such a specific way without external control (i.e.
not having put this in a MT_CLS).
Please split the 2 features (if I understand correctly enabling of the
multitouch mode and firmware update) in 2 separate patches.
How about not having a FW update capability in the kernel and just use
a plain hidraw user space application which would call the firmware
update?
Last, all HID drivers go through Jiri's tree, so you definitively
should add him in CC of your submissions.
Cheers,
Benjamin
Regards
Oliver
Tammy
-
linux-3.18.5/drivers/hid/Kconfig | 14 ++
linux-3.18.5/drivers/hid/hid-ids.h | 1 +
linux-3.18.5/drivers/hid/hid-multitouch.c| 16 ++
linux-3.18.5/drivers/hid/hid-sis_ctrl.c | 360
+++
linux-3.18.5/drivers/hid/usbhid/hid-quirks.c | 1 +
5 files changed, 392 insertions(+)
-
diff --git a/linux-3.18.5/drivers/hid/Kconfig
b/linux-3.18.5/drivers/hid/Kconfig
index f42df4d..2235cfe 100644
--- a/linux-3.18.5/drivers/hid/Kconfig
+++ b/linux-3.18.5/drivers/hid/Kconfig
@@ -496,6 +496,20 @@ config HID_MULTITOUCH
To compile this driver as a module, choose M here: the
module will be called hid-multitouch.
+config HID_SIS_CTRL
+ bool SiS Touch Device Controller
+ depends on HID_MULTITOUCH
+ ---help---
+ Support for SiS Touch devices update FW.
+
+config DEBUG_HID_SIS_UPDATE_FW
+ bool SiS Touch device debug message(update firmware)
+ depends on HID_SIS_CTRL
+ default n
+ ---help---
+Say Y here if you want to enable debug message(update firmware) for
SiS Touch
+ devices. Must enable config HID_SIS_UPDATE_FW first.
+
config HID_NTRIG
tristate N-Trig touch screen
depends on USB_HID
diff --git a/linux-3.18.5/drivers/hid/hid-ids.h
b/linux-3.18.5/drivers/hid/hid-ids.h
index 0e28190..b9ca441 100644
--- a/linux-3.18.5/drivers/hid/hid-ids.h
+++ b/linux-3.18.5/drivers/hid/hid-ids.h
@@ -809,6 +809,7 @@
#define USB_VENDOR_ID_SIS_TOUCH0x0457
#define USB_DEVICE_ID_SIS9200_TOUCH 0x9200
#define USB_DEVICE_ID_SIS817_TOUCH0x0817
+#define USB_DEVICE_ID_SISF817_TOUCH 0xF817
#define USB_DEVICE_ID_SIS_TS 0x1013
#define USB_DEVICE_ID_SIS1030_TOUCH 0x1030
diff --git a/linux-3.18.5/drivers/hid/hid-multitouch.c
b/linux-3.18.5/drivers/hid/hid-multitouch.c
index 51e25b9..11d67bc 100644
--- a/linux-3.18.5/drivers/hid/hid-multitouch.c
+++ b/linux-3.18.5/drivers/hid/hid-multitouch.c
@@ -54,6 +54,10 @@ MODULE_LICENSE(GPL);
#include hid-ids.h
+#ifdef CONFIG_HID_SIS_CTRL
+#include hid-sis_ctrl.c
+#endif
+
/* quirks to control the device */
#define MT_QUIRK_NOT_SEEN_MEANS_UP (1 0)
#define MT_QUIRK_SLOT_IS_CONTACTID (1 1)
@@ -951,6 +955,14 @@ static int mt_probe(struct hid_device *hdev, const
struct hid_device_id *id)
}
}
+#ifdef CONFIG_HID_SIS_CTRL
+ if (hdev-vendor == USB_VENDOR_ID_SIS_TOUCH) {
+ ret = sis_setup_chardev(hdev);
+ if (ret)
+ dev_err(hdev-dev, sis_setup_chardev fail\n);
+ }
+#endif
+
/* This allows the driver to correctly support devices
* that emit events over several HID messages.
*/
@@ -1043,6 +1055,10 @@ static void mt_remove(struct hid_device *hdev) {
sysfs_remove_group(hdev-dev.kobj, mt_attribute_group);
hid_hw_stop(hdev);
+#ifdef CONFIG_HID_SIS_CTRL
+ if (hdev-vendor == USB_VENDOR_ID_SIS_TOUCH)
+ sis_deinit_chardev();
+#endif
}
/*
diff --git a/linux-3.18.5/drivers/hid/hid-sis_ctrl.c
b/linux-3.18.5/drivers/hid/hid-sis_ctrl.c
new file mode 100644
index 000..3a7b3df
--- /dev/null
+++ b/linux-3.18.5/drivers/hid/hid-sis_ctrl.c
@@ -0,0 +1,360 @@
+/*
+ * Character device driver for SIS multitouch panels control
+ *
+ * Copyright (c) 2009 SIS, Ltd.
+ *
+ */
+
+/*
+ * 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
Re: linux-next: Tree for Jan 16 (mips build errors due to MIPSR6 patches)
On Fri, Jan 16, 2015 at 07:47:57PM +1100, Stephen Rothwell wrote:
Hi all,
Changes since 20150115:
The i2c tree gained a build failure so I used the version from
next-20150115.
The wireless-drivers-next tree gained a conflict against the
wireless-drivers tree.
The usb-gadget tree gained a conflict against the usb.current tree.
Non-merge commits (relative to Linus' tree): 3219
3111 files changed, 98486 insertions(+), 52594 deletions(-)
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use git pull
to do so as that will try to merge the new linux-next release with the
old one. You should use git fetch and checkout or reset to the new
master.
Today's tree has a number of new mips related build errors.
Building mips:defconfig ... failed
Building mips:allmodconfig ... failed
Error log:
In file included from ./arch/mips/include/asm/sgiarcs.h:16:0,
from ./arch/mips/include/asm/sgialib.h:15,
from arch/mips/sgi-ip22/ip22-mc.c:16:
./arch/mips/include/asm/fw/arc/types.h:18:15: error: expected identifier or '('
before '.' token
(more of those)
In file included from ./arch/mips/include/asm/sgialib.h:15:0,
from arch/mips/sgi-ip22/ip22-mc.c:16:
./arch/mips/include/asm/sgiarcs.h:89:2: error: unknown type name '_PULONG'
./arch/mips/include/asm/sgiarcs.h:188:2: error: expected
specifier-qualifier-list before '.' token
./arch/mips/include/asm/sgiarcs.h:252:2: error: unknown type name '_PLONG'
(more of those)
In file included from arch/mips/sgi-ip22/ip22-mc.c:16:0:
./arch/mips/include/asm/sgialib.h:20:8: error: expected identifier or '('
before '.' token
(more or those)
---
Bisect points to commit 9119e8276d (MIPS: asm: hazards: Add MIPSR6
definitions). Looking into the patch, I wonder if the following is correct.
-#if defined(CONFIG_CPU_MIPSR2) !defined(CONFIG_CPU_CAVIUM_OCTEON)
+#if defined(CONFIG_CPU_MIPSR2) || defined(CONFIG_CPU_MIPSR6)
!defined(CONFIG_CPU_CAVIUM_OCTEON)
This change appears to be missing a ( ) around the first two defined()
statements. Fixing that doesn't resolve the problem, though. Reverting
the patch doesn't fix the problem either, so something else must be wrong.
-
Building mips:cavium_octeon_defconfig ... failed
Error log:
arch/mips/kernel/branch.c: In function '__compute_return_epc_for_insn':
arch/mips/kernel/branch.c:785:2: error: duplicate case value
arch/mips/kernel/branch.c:753:2: error: previously used here
arch/mips/kernel/branch.c:808:2: error: duplicate case value
arch/mips/kernel/branch.c:769:2: error: previously used here
arch/mips/kernel/branch.c:818:2: error: duplicate case value
arch/mips/kernel/branch.c:761:2: error: previously used here
arch/mips/kernel/branch.c:826:2: error: duplicate case value
arch/mips/kernel/branch.c:776:2: error: previously used here
Bisect points to commit 2f1da3620ff2 (MIPS: Emulate the new MIPS R6 branch
compact (BC) instruction). Looking into the code, the patch quite obviously
conflicts with cavium support.
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] eeprom: at24: Add support for large EEPROMs connected to SMBus adapters
On 02/16/2015 04:09 AM, Wolfram Sang wrote: Hi Guenter, I wonder where we are with thisp patch; I don't recall a reply to my previous e-mail. Sorry for the late reply. I needed to recover from a HDD headcrash :( Do you need some more time to think about it ? Otherwise I'll publish an out-of-tree version of the at24 driver with the patch applied on github, for those who might need the functionality provided by this patch. Your last mail made me aware of why we were missing each other before. I see your point now, but yes, still need to think about it. My plan is to have a decision until the 3.21 merge window. Ok, fair enough. 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 04/11] ARM: davinci: davinci_cfg_reg cannot be init
On Friday 13 February 2015 01:12 AM, Arnd Bergmann wrote: davinci_cfg_reg gets called from a lot of locations that might get called after the init section has been discarded, so the function itself must not be marked __init either. The kernel build currently warns about this with lots of messages like: WARNING: vmlinux.o(.text.unlikely+0x24c): Section mismatch in reference from the function dm365evm_mmc_configure() to the function .init.text:davinci_cfg_reg() The function dm365evm_mmc_configure() references the function __init davinci_cfg_reg(). This is often because dm365evm_mmc_configure lacks a __init annotation or the annotation of davinci_cfg_reg is wrong. This removes the extraneous __init_or_module annotation. Signed-off-by: Arnd Bergmann a...@arndb.de Cc: Sekhar Nori nsek...@ti.com Cc: Kevin Hilman khil...@deeprootsystems.com Acked-by: Sekhar Nori nsek...@ti.com Thanks, Sekhar -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHv3 00/24] ILP32 support in ARM64
On Mon, Feb 16, 2015 at 03:40:54PM +0100, Arnd Bergmann wrote: On Friday 13 February 2015 13:37:07 Rich Felker wrote: On Fri, Feb 13, 2015 at 05:33:46PM +, Catalin Marinas wrote: The data structure definition is a little bit fragile, as it depends on user space not using the __BIT_ENDIAN symbol in a conflicting way. So far we have managed to keep that outside of general purpose headers, but it should at least blow up in an obvious way if it does, rather than breaking silently. I still think it's more practical to keep the zeroing in user space though. In that case, we keep defining __kernel_timespec64 with a 'typedef long long __kernel_snseconds_t', and it's up to the libc to either use __kernel_timespec64 as its timespec, or to define a C11-compliant timespec itself and zero out the bits before passing the data to the kernel. The problem with doing this in user space is syscall(2). If we don't allow it, then it's fine to do the padding in libc. It's already the case that callers have to tiptoe around syscall(2) usage on a per-arch basis for silly things like the convention for passing 64-bit arguments on 32-bit archs, different arg orders to work around 64-bit alignment and issues with too many args, and various legacy issues. Right. If one wants to use syscall(), they have to know exactly what the kernel's calling conventions are, including knowing what the timespec definition looks like, which could have a different size and padding compared to the user space one. I think there is another problem with sign-extending tv_nsec in libc. The prototype for functions like clock_settime(2) take a const struct timespec *. There isn't anything to prevent such structure being in a read-only section, even though it is unlikely. So libc would have to duplicate the structure rather than just sign-extending tv_nsec in place. Do we actually need sign-extend, or does zero-extend have the exact same effect? For all I can tell, all invalid nanoseconds values remain invalid, and the accepted values are unchanged regardless of which type extension gets used. I think it matters for futimensat which has some special negative codes you can store in tv_nsec, but perhaps there's an easy trick to distinguish them even with zero extending. Yes, we already have to do this for x32 in musl. I'd rather not have to do the same for aarch64-ILP32. This would of course be solved by using a 64-bit __kernel_snseconds_t or snseconds_t, and I suspect other libc implementations would just do that, when they are less strict about posix/c11 compliance compared to musl. I think they would be more strict if this were for a target that actually sees use and they were getting bug reports from C programmers annoyed that their code was not working correctly or not even compiling. AFAIK there are no distros based on x32 now and it's something of an alternate model on x86_64 distros that some people are playing around with. If you don't mind the (slight) distraction, can you describe what your plans are for handling 64-bit time_t on the existing 32-bit ABIs? I'm involved in both the efforts to do that and the ilp32 code on ARM, so it would be good for me to understand your plans for musl to get the bigger picture. Specifically, which of these do you plan to support (if you know already): It largely depends on if there's demand. If we have users who want to run 32-bit systems with an ABI that will survive Y2038, it will be supported, but as a new ABI for these targets. This will likely allow fixing other ABI issues at the same time -- for example, on i386 I would probably switch to mandating SSE2 for floating point, and possibly using regparm everywhere. There are a couple of different ways it could be done though: 1. On a per-arch basis, defining a new ABI variant for the arch. 2. With a new abstraction at the syscall boundary to get rid of all kernel-arch-specific structures in userspace and redefine all types to have plenty of room for growth. In regards to your specific questions about ways it could be done: - using 64-bit time_t on future arm32/i386/... kernels - using 64-bit time_t on existing arm32/i386/... kernels with native 32-bit time_t If the former is supported, I would think we'd want to support the latter too. An ABI that only works on very-new kernels is very restrictive in who can use it. Kernel support hardly matters (until Y2038 actually arrives); the point of 64-bit time_t is to have an ABI that's _ready_ for it so existing binaries can keep working. - using 32-bit time_t on future architectures that only support 64-bit time_t in the kernel Definitely will not be supported. Introducing a new ABI with 32-bit time_t is a huge mistake, and the only reason it's been done for some of the new targets musl supports is
Re: [PATCHv3 04/24] rmap: add argument to charge compound page
On Thu, Feb 12, 2015 at 04:10:21PM -0500, Rik van Riel wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 02/12/2015 11:18 AM, Kirill A. Shutemov wrote:
+++ b/include/linux/rmap.h @@ -168,16 +168,24 @@ static inline void
anon_vma_merge(struct vm_area_struct *vma,
struct anon_vma *page_get_anon_vma(struct page *page);
+/* flags for do_page_add_anon_rmap() */ +enum { + RMAP_EXCLUSIVE =
1, +RMAP_COMPOUND = 2, +};
Always a good idea to name things. However, exclusive is
not that clear to me. Given that the argument is supposed
to indicate whether we map a single or a compound page,
maybe the names in the enum could just be SINGLE and COMPOUND?
Naming the enum should make it clear enough what it does:
enum rmap_page {
SINGLE = 0,
COMPOUND
}
Okay, this is probably confusing: do_page_add_anon_rmap() already had one
of arguments called 'exclusive'. It indicates if the page is exclusively
owned by the current process. And I needed also to indicate if we need to
handle the page as a compound or not. I've reused the same argument and
converted it to set bit-flags: bit 0 is exclusive, bit 1 - compound.
+++ b/kernel/events/uprobes.c @@ -183,7 +183,7 @@ static int
__replace_page(struct vm_area_struct *vma, unsigned long addr, goto
unlock;
get_page(kpage); - page_add_new_anon_rmap(kpage, vma, addr); +
page_add_new_anon_rmap(kpage, vma, addr, false);
mem_cgroup_commit_charge(kpage, memcg, false);
lru_cache_add_active_or_unevictable(kpage, vma);
Would it make sense to use the name in the argument to that function,
too?
I often find it a lot easier to see what things do if they use symbolic
names, rather than by trying to remember what each boolean argument to
a function does.
I can convert these compound booleans to enums if you want. I'm personally
not sure that if will bring much value.
--
Kirill A. Shutemov
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] extcon: arizona: Deobfuscate arizona_extcon_do_magic
arizona_extcon_do_magic does not lend a lot of clarity to the purpose
of the function, and as all the registers used are described in the
datasheet there is no need to obfuscate the code. This patch renames the
function to arizona_extcon_hp_clamp, as it controls clamping on the
headphone output.
Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com
---
drivers/extcon/extcon-arizona.c | 36
include/linux/mfd/arizona/core.h |2 +-
sound/soc/codecs/arizona.c |4 ++--
3 files changed, 23 insertions(+), 19 deletions(-)
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index 63f01c4..95cf7f8 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -136,18 +136,22 @@ static const char *arizona_cable[] = {
static void arizona_start_hpdet_acc_id(struct arizona_extcon_info *info);
-static void arizona_extcon_do_magic(struct arizona_extcon_info *info,
- unsigned int magic)
+static void arizona_extcon_hp_clamp(struct arizona_extcon_info *info,
+ bool clamp)
{
struct arizona *arizona = info-arizona;
+ unsigned int val = 0;
int ret;
+ if (clamp)
+ val = ARIZONA_RMV_SHRT_HP1L;
+
mutex_lock(arizona-dapm-card-dapm_mutex);
- arizona-hpdet_magic = magic;
+ arizona-hpdet_clamp = clamp;
- /* Keep the HP output stages disabled while doing the magic */
- if (magic) {
+ /* Keep the HP output stages disabled while doing the clamp */
+ if (clamp) {
ret = regmap_update_bits(arizona-regmap,
ARIZONA_OUTPUT_ENABLES_1,
ARIZONA_OUT1L_ENA |
@@ -158,20 +162,20 @@ static void arizona_extcon_do_magic(struct
arizona_extcon_info *info,
ret);
}
- ret = regmap_update_bits(arizona-regmap, 0x225, 0x4000,
-magic);
+ ret = regmap_update_bits(arizona-regmap, ARIZONA_HP_CTRL_1L,
+ARIZONA_RMV_SHRT_HP1L, val);
if (ret != 0)
- dev_warn(arizona-dev, Failed to do magic: %d\n,
+ dev_warn(arizona-dev, Failed to do clamp: %d\n,
ret);
- ret = regmap_update_bits(arizona-regmap, 0x226, 0x4000,
-magic);
+ ret = regmap_update_bits(arizona-regmap, ARIZONA_HP_CTRL_1R,
+ARIZONA_RMV_SHRT_HP1R, val);
if (ret != 0)
- dev_warn(arizona-dev, Failed to do magic: %d\n,
+ dev_warn(arizona-dev, Failed to do clamp: %d\n,
ret);
- /* Restore the desired state while not doing the magic */
- if (!magic) {
+ /* Restore the desired state while not doing the clamp */
+ if (!clamp) {
ret = regmap_update_bits(arizona-regmap,
ARIZONA_OUTPUT_ENABLES_1,
ARIZONA_OUT1L_ENA |
@@ -603,7 +607,7 @@ done:
ARIZONA_HP_IMPEDANCE_RANGE_MASK | ARIZONA_HP_POLL,
0);
- arizona_extcon_do_magic(info, 0);
+ arizona_extcon_hp_clamp(info, false);
if (id_gpio)
gpio_set_value_cansleep(id_gpio, 0);
@@ -648,7 +652,7 @@ static void arizona_identify_headphone(struct
arizona_extcon_info *info)
if (info-mic)
arizona_stop_mic(info);
- arizona_extcon_do_magic(info, 0x4000);
+ arizona_extcon_hp_clamp(info, true);
ret = regmap_update_bits(arizona-regmap,
ARIZONA_ACCESSORY_DETECT_MODE_1,
@@ -699,7 +703,7 @@ static void arizona_start_hpdet_acc_id(struct
arizona_extcon_info *info)
info-hpdet_active = true;
- arizona_extcon_do_magic(info, 0x4000);
+ arizona_extcon_hp_clamp(info, true);
ret = regmap_update_bits(arizona-regmap,
ARIZONA_ACCESSORY_DETECT_MODE_1,
diff --git a/include/linux/mfd/arizona/core.h b/include/linux/mfd/arizona/core.h
index 910e3aa..4863548 100644
--- a/include/linux/mfd/arizona/core.h
+++ b/include/linux/mfd/arizona/core.h
@@ -126,7 +126,7 @@ struct arizona {
struct regmap_irq_chip_data *aod_irq_chip;
struct regmap_irq_chip_data *irq_chip;
- bool hpdet_magic;
+ bool hpdet_clamp;
unsigned int hp_ena;
struct mutex clk_lock;
diff --git a/sound/soc/codecs/arizona.c b/sound/soc/codecs/arizona.c
index 9550d74..a6e5c70 100644
--- a/sound/soc/codecs/arizona.c
+++ b/sound/soc/codecs/arizona.c
@@ -780,8 +780,8 @@ int arizona_hp_ev(struct snd_soc_dapm_widget *w,
priv-arizona-hp_ena = ~mask;
priv-arizona-hp_ena |= val;
- /* Force off if HPDET magic is active */
- if
[PATCH 2/2] extcon: arizona: Fix headphone clamping on wm5110
wm5110 requires slightly different configuration of the headphone
clamps to other Arizona devices. Otherwise headphone detection accuracy
will be way off. This patch adds the needed clamping.
Signed-off-by: Charles Keepax ckee...@opensource.wolfsonmicro.com
---
drivers/extcon/extcon-arizona.c | 23 ++-
1 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/drivers/extcon/extcon-arizona.c b/drivers/extcon/extcon-arizona.c
index 95cf7f8..d9e763c 100644
--- a/drivers/extcon/extcon-arizona.c
+++ b/drivers/extcon/extcon-arizona.c
@@ -140,11 +140,24 @@ static void arizona_extcon_hp_clamp(struct
arizona_extcon_info *info,
bool clamp)
{
struct arizona *arizona = info-arizona;
- unsigned int val = 0;
+ unsigned int mask = 0, val = 0;
int ret;
- if (clamp)
- val = ARIZONA_RMV_SHRT_HP1L;
+ switch (arizona-type) {
+ case WM5110:
+ mask = ARIZONA_HP1L_SHRTO | ARIZONA_HP1L_FLWR |
+ ARIZONA_HP1L_SHRTI;
+ if (clamp)
+ val = ARIZONA_HP1L_SHRTO;
+ else
+ val = ARIZONA_HP1L_FLWR | ARIZONA_HP1L_SHRTI;
+ break;
+ default:
+ mask = ARIZONA_RMV_SHRT_HP1L;
+ if (clamp)
+ val = ARIZONA_RMV_SHRT_HP1L;
+ break;
+ };
mutex_lock(arizona-dapm-card-dapm_mutex);
@@ -163,13 +176,13 @@ static void arizona_extcon_hp_clamp(struct
arizona_extcon_info *info,
}
ret = regmap_update_bits(arizona-regmap, ARIZONA_HP_CTRL_1L,
-ARIZONA_RMV_SHRT_HP1L, val);
+mask, val);
if (ret != 0)
dev_warn(arizona-dev, Failed to do clamp: %d\n,
ret);
ret = regmap_update_bits(arizona-regmap, ARIZONA_HP_CTRL_1R,
-ARIZONA_RMV_SHRT_HP1R, val);
+mask, val);
if (ret != 0)
dev_warn(arizona-dev, Failed to do clamp: %d\n,
ret);
--
1.7.2.5
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] usb: gadget: udc-core: independent registration of gadgets and gadget drivers
W dniu 15.02.2015 o 23:43, Ruslan Bilovol pisze: snip In my opinion all things which you have described are working out-of-box when you use configfs interface. It's mostly ready so you may create equivalent of most legacy gadgets (apart from printer and tcm) and just bind from one udc to another whenever you want. It's because legacy gadgets are easy to use and usually don't need any userspace-side configuration. Are there any plans to remove legacy drivers in the future? I'm not going to express strong opinions here, but their name implies that this can happen, some time in the future. And I also think it will not happen before the userspace part (libusbg, gt, gadgetd etc) is mature enough. My personal opinion in that matter is that it will take at least a couple of years to remove legacy gadgets entirely. AP -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.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 RFC 2/2] ARM: pxa: transition to dmaengine phase 1
On Saturday 14 February 2015 23:47:33 Robert Jarzmik wrote:
@@ -294,7 +294,8 @@ int pxa_request_dma (char *name, pxa_dma_prio prio,
/* try grabbing a DMA channel with the requested priority */
for (i = 0; i num_dma_channels; i++) {
if ((dma_channels[i].prio == prio)
- !dma_channels[i].name) {
+ !dma_channels[i].name
+ !mmp_pdma_toggle_reserved_channel(i)) {
found = 1;
break;
}
How is the order between the two enforced? I.e. can it be that the dmaengine
driver uses the same channel for a different slave before we get here?
If this is ensured to work, I'm fine with your approach.
Arnd
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [alsa-devel] [PATCH] ASoC: wm8731: let codec to manage clock by itself
On Thu, Feb 12, 2015 at 04:23:06PM +0800, Bo Shen wrote: Hi All, On 02/05/2015 03:35 PM, Bo Shen wrote: Let the wm8731 codec to manage clock by itself. Signed-off-by: Bo Shen voice.s...@atmel.com --- sound/soc/codecs/wm8731.c | 28 1 file changed, 28 insertions(+) Any comments for this patch (aka ping?) I preferred the idea of having the clock as optional and from the discussion on the last patch it didn't look too tricky to achieve. OTOH I think the Atmel system is the only one that uses both this CODEC and common clock so it doesn't look like this would cause any problems, but might be nice for this not to be one more thing for someone to fix up when moving a system to common clock. Thanks, Charles -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL] ARC fixes for 3.20-rc1
Hi Linus, ARC updates for 3.20. Please pull. Thx, -Vineet ---8 The following changes since commit 26bc420b59a38e4e6685a73345a0def461136dce: Linux 3.19-rc6 (2015-01-25 20:04:41 -0800) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc.git/ tags/arc-3.20-rc1 for you to fetch changes up to 06f34e1c28f3608b0ce5b310e41102d3fe7b65a1: ARC: fix page address calculation if PAGE_OFFSET != LINUX_LINK_BASE (2015-02-13 18:01:12 +0530) ARC updates for 3.20 Some fixes, nothing too exciting this time as well... Alexey Brodkin (1): ARC: fix page address calculation if PAGE_OFFSET != LINUX_LINK_BASE Peter Hurley (1): ARC: Fix earlycon build breakage Tobias Klauser (1): arc: Remove unused prepare_to_copy() Vineet Gupta (4): ARC: fix /proc/cpuinfo for offline cpus ARC: add some more comments to ret_from_fork ARC: use ACCESS_ONCE in cmpxchg loop ARC: Dynamically determine BASE_BAUD from DeviceTree arch/arc/include/asm/pgtable.h | 3 ++- arch/arc/include/asm/processor.h | 3 --- arch/arc/include/asm/serial.h| 23 +-- arch/arc/kernel/devtree.c| 24 arch/arc/kernel/entry.S | 14 +- arch/arc/kernel/setup.c | 7 ++- arch/arc/kernel/smp.c| 2 +- 7 files changed, 47 insertions(+), 29 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: General protection fault in iscsi_rx_thread_pre_handler
Hi Nicholas, On Thu, Feb 12, 2015 at 3:16 PM, Nicholas A. Bellinger n...@linux-iscsi.org wrote: Hi Gavin, On Tue, 2015-02-03 at 08:28 +0800, Gavin Guo wrote: Hi Nicholas, On Sun, Feb 1, 2015 at 11:47 AM, Gavin Guo gavin@canonical.com wrote: Hi Nicholas, On Sat, Jan 31, 2015 at 6:53 AM, Nicholas A. Bellinger n...@linux-iscsi.org wrote: On Fri, 2015-01-23 at 09:30 +0800, Gavin Guo wrote: Hi Nicholas, On Fri, Jan 23, 2015 at 1:35 AM, Nicholas A. Bellinger n...@linux-iscsi.org wrote: On Thu, 2015-01-22 at 23:56 +0800, Gavin Guo wrote: Hi Nicolas, On Thu, Jan 22, 2015 at 5:50 PM, Nicholas A. Bellinger SNIP At the time, a different set of iser-target related changes ended up avoiding this issue on his particular setup, so we thought it was likely a race triggered by login failures specific to iser-target code. There was a untested patch (included inline below) to drop the legacy active_ts_list usage all-together, but IIRC he was not able to reproduce further so the patch didn't get picked up for mainline. If your able to reliability reproduce, please try with the following patch and let us know your progress. Thanks for your time reading the mail. I'll let you know the result. Just curious, are you able to reliability reproduce this bug in a VM..? Thanks for your caring, the machine is on the customer side, I've asked and now waiting for their response. Hi Gavin, Just curious if there has been any update on this yet..? --nab Really thanks for your attention. I'm also currently waiting for the customer's reply and will send the email again to ask for the result. However, I think the symptom may be hard to replicate that's why the customer didn't reply me for a long time. Thanks for your time again. Thanks, Gavin Sorry for making you wait so long. I just got the response from the customer, they said the general protection fault happened just 2 times in the past and cannot be reliably reproduced. And I am now waiting for the verification test. Just a heads up that I'm planning to include this patch in the v3.20-rc1 PULL request. Please let me know if you have any objections. Thank you, --nab The bug -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: General protection fault in iscsi_rx_thread_pre_handler
Hi Nicholas, On Mon, Feb 16, 2015 at 6:52 PM, Gavin Guo gavin@canonical.com wrote: Hi Nicholas, On Thu, Feb 12, 2015 at 3:16 PM, Nicholas A. Bellinger n...@linux-iscsi.org wrote: Hi Gavin, On Tue, 2015-02-03 at 08:28 +0800, Gavin Guo wrote: Hi Nicholas, On Sun, Feb 1, 2015 at 11:47 AM, Gavin Guo gavin@canonical.com wrote: Hi Nicholas, On Sat, Jan 31, 2015 at 6:53 AM, Nicholas A. Bellinger n...@linux-iscsi.org wrote: On Fri, 2015-01-23 at 09:30 +0800, Gavin Guo wrote: Hi Nicholas, On Fri, Jan 23, 2015 at 1:35 AM, Nicholas A. Bellinger n...@linux-iscsi.org wrote: On Thu, 2015-01-22 at 23:56 +0800, Gavin Guo wrote: Hi Nicolas, On Thu, Jan 22, 2015 at 5:50 PM, Nicholas A. Bellinger SNIP At the time, a different set of iser-target related changes ended up avoiding this issue on his particular setup, so we thought it was likely a race triggered by login failures specific to iser-target code. There was a untested patch (included inline below) to drop the legacy active_ts_list usage all-together, but IIRC he was not able to reproduce further so the patch didn't get picked up for mainline. If your able to reliability reproduce, please try with the following patch and let us know your progress. Thanks for your time reading the mail. I'll let you know the result. Just curious, are you able to reliability reproduce this bug in a VM..? Thanks for your caring, the machine is on the customer side, I've asked and now waiting for their response. Hi Gavin, Just curious if there has been any update on this yet..? --nab Really thanks for your attention. I'm also currently waiting for the customer's reply and will send the email again to ask for the result. However, I think the symptom may be hard to replicate that's why the customer didn't reply me for a long time. Thanks for your time again. Thanks, Gavin Sorry for making you wait so long. I just got the response from the customer, they said the general protection fault happened just 2 times in the past and cannot be reliably reproduced. And I am now waiting for the verification test. Just a heads up that I'm planning to include this patch in the v3.20-rc1 PULL request. Please let me know if you have any objections. Thank you, --nab The bug Sorry, I mistakenly press the send button last time. The bug doesn't appear after the customer upgraded the kernel with the patch. Really thanks for your help. I'll keep you posted if the bug appears again. Thanks, Gavin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/4] powerpc: trivial unused functions cleanup
This series removes unused functions from powerpc tree that I've been able to discover. Arseny Solokha (4): powerpc/boot: drop planetcore_set_serial_speed kvm/ppc/mpic: drop unused IRQ_testbit powrepc/qe: drop unused ucc_slow_poll_transmitter_now powerpc/mpic: remove unused functions arch/powerpc/boot/planetcore.c| 33 - arch/powerpc/boot/planetcore.h| 3 --- arch/powerpc/include/asm/mpic.h | 16 arch/powerpc/include/asm/ucc_slow.h | 13 - arch/powerpc/kvm/mpic.c | 5 - arch/powerpc/sysdev/mpic.c| 35 --- arch/powerpc/sysdev/qe_lib/ucc_slow.c | 5 - 7 files changed, 110 deletions(-) -- 2.3.0 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] powrepc/qe: drop unused ucc_slow_poll_transmitter_now
Drop ucc_slow_poll_transmitter_now() which has no users.
Signed-off-by: Arseny Solokha asolo...@kb.kras.ru
---
arch/powerpc/include/asm/ucc_slow.h | 13 -
arch/powerpc/sysdev/qe_lib/ucc_slow.c | 5 -
2 files changed, 18 deletions(-)
diff --git a/arch/powerpc/include/asm/ucc_slow.h
b/arch/powerpc/include/asm/ucc_slow.h
index c44131e..233ef5f 100644
--- a/arch/powerpc/include/asm/ucc_slow.h
+++ b/arch/powerpc/include/asm/ucc_slow.h
@@ -251,19 +251,6 @@ void ucc_slow_enable(struct ucc_slow_private * uccs, enum
comm_dir mode);
*/
void ucc_slow_disable(struct ucc_slow_private * uccs, enum comm_dir mode);
-/* ucc_slow_poll_transmitter_now
- * Immediately forces a poll of the transmitter for data to be sent.
- * Typically, the hardware performs a periodic poll for data that the
- * transmit routine has set up to be transmitted. In cases where
- * this polling cycle is not soon enough, this optional routine can
- * be invoked to force a poll right away, instead. Proper use for
- * each transmission for which this functionality is desired is to
- * call the transmit routine and then this routine right after.
- *
- * uccs - (In) pointer to the slow UCC structure.
- */
-void ucc_slow_poll_transmitter_now(struct ucc_slow_private * uccs);
-
/* ucc_slow_graceful_stop_tx
* Smoothly stops transmission on a specified slow UCC.
*
diff --git a/arch/powerpc/sysdev/qe_lib/ucc_slow.c
b/arch/powerpc/sysdev/qe_lib/ucc_slow.c
index befaf11..5f91628 100644
--- a/arch/powerpc/sysdev/qe_lib/ucc_slow.c
+++ b/arch/powerpc/sysdev/qe_lib/ucc_slow.c
@@ -43,11 +43,6 @@ u32 ucc_slow_get_qe_cr_subblock(int uccs_num)
}
EXPORT_SYMBOL(ucc_slow_get_qe_cr_subblock);
-void ucc_slow_poll_transmitter_now(struct ucc_slow_private * uccs)
-{
- out_be16(uccs-us_regs-utodr, UCC_SLOW_TOD);
-}
-
void ucc_slow_graceful_stop_tx(struct ucc_slow_private * uccs)
{
struct ucc_slow_info *us_info = uccs-us_info;
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] kvm/ppc/mpic: drop unused IRQ_testbit
Drop unused static procedure which doesn't have callers within its
translation unit.
Signed-off-by: Arseny Solokha asolo...@kb.kras.ru
Cc: Alexander Graf ag...@suse.de
Cc: Gleb Natapov g...@kernel.org
Cc: Paolo Bonzini pbonz...@redhat.com
---
arch/powerpc/kvm/mpic.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/arch/powerpc/kvm/mpic.c b/arch/powerpc/kvm/mpic.c
index 39b3a8f..a480d99 100644
--- a/arch/powerpc/kvm/mpic.c
+++ b/arch/powerpc/kvm/mpic.c
@@ -289,11 +289,6 @@ static inline void IRQ_resetbit(struct irq_queue *q, int
n_IRQ)
clear_bit(n_IRQ, q-queue);
}
-static inline int IRQ_testbit(struct irq_queue *q, int n_IRQ)
-{
- return test_bit(n_IRQ, q-queue);
-}
-
static void IRQ_check(struct openpic *opp, struct irq_queue *q)
{
int irq = -1;
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] powerpc/mpic: remove unused functions
Drop unused fsl_mpic_primary_get_version(), mpic_set_clk_ratio(),
mpic_set_serial_int().
Signed-off-by: Arseny Solokha asolo...@kb.kras.ru
---
arch/powerpc/include/asm/mpic.h | 16
arch/powerpc/sysdev/mpic.c | 35 ---
2 files changed, 51 deletions(-)
diff --git a/arch/powerpc/include/asm/mpic.h b/arch/powerpc/include/asm/mpic.h
index 754f93d..3a2ab60 100644
--- a/arch/powerpc/include/asm/mpic.h
+++ b/arch/powerpc/include/asm/mpic.h
@@ -395,16 +395,6 @@ extern struct bus_type mpic_subsys;
#defineMPIC_REGSET_STANDARDMPIC_REGSET(0) /* Original
MPIC */
#defineMPIC_REGSET_TSI108 MPIC_REGSET(1) /* Tsi108/109
PIC */
-/* Get the version of primary MPIC */
-#ifdef CONFIG_MPIC
-extern u32 fsl_mpic_primary_get_version(void);
-#else
-static inline u32 fsl_mpic_primary_get_version(void)
-{
- return 0;
-}
-#endif
-
/* Allocate the controller structure and setup the linux irq descs
* for the range if interrupts passed in. No HW initialization is
* actually performed.
@@ -496,11 +486,5 @@ extern unsigned int mpic_get_coreint_irq(void);
/* Fetch Machine Check interrupt from primary mpic */
extern unsigned int mpic_get_mcirq(void);
-/* Set the EPIC clock ratio */
-void mpic_set_clk_ratio(struct mpic *mpic, u32 clock_ratio);
-
-/* Enable/Disable EPIC serial interrupt mode */
-void mpic_set_serial_int(struct mpic *mpic, int enable);
-
#endif /* __KERNEL__ */
#endif /* _ASM_POWERPC_MPIC_H */
diff --git a/arch/powerpc/sysdev/mpic.c b/arch/powerpc/sysdev/mpic.c
index bbfbbf2..f72b592 100644
--- a/arch/powerpc/sysdev/mpic.c
+++ b/arch/powerpc/sysdev/mpic.c
@@ -1219,16 +1219,6 @@ static u32 fsl_mpic_get_version(struct mpic *mpic)
* Exported functions
*/
-u32 fsl_mpic_primary_get_version(void)
-{
- struct mpic *mpic = mpic_primary;
-
- if (mpic)
- return fsl_mpic_get_version(mpic);
-
- return 0;
-}
-
struct mpic * __init mpic_alloc(struct device_node *node,
phys_addr_t phys_addr,
unsigned int flags,
@@ -1676,31 +1666,6 @@ void __init mpic_init(struct mpic *mpic)
mpic_err_int_init(mpic, MPIC_FSL_ERR_INT);
}
-void __init mpic_set_clk_ratio(struct mpic *mpic, u32 clock_ratio)
-{
- u32 v;
-
- v = mpic_read(mpic-gregs, MPIC_GREG_GLOBAL_CONF_1);
- v = ~MPIC_GREG_GLOBAL_CONF_1_CLK_RATIO_MASK;
- v |= MPIC_GREG_GLOBAL_CONF_1_CLK_RATIO(clock_ratio);
- mpic_write(mpic-gregs, MPIC_GREG_GLOBAL_CONF_1, v);
-}
-
-void __init mpic_set_serial_int(struct mpic *mpic, int enable)
-{
- unsigned long flags;
- u32 v;
-
- raw_spin_lock_irqsave(mpic_lock, flags);
- v = mpic_read(mpic-gregs, MPIC_GREG_GLOBAL_CONF_1);
- if (enable)
- v |= MPIC_GREG_GLOBAL_CONF_1_SIE;
- else
- v = ~MPIC_GREG_GLOBAL_CONF_1_SIE;
- mpic_write(mpic-gregs, MPIC_GREG_GLOBAL_CONF_1, v);
- raw_spin_unlock_irqrestore(mpic_lock, flags);
-}
-
void mpic_irq_set_priority(unsigned int irq, unsigned int pri)
{
struct mpic *mpic = mpic_find(irq);
--
2.3.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] powerpc/boot: drop planetcore_set_serial_speed
Drop planetcore_set_serial_speed() which had no users since its inception.
Signed-off-by: Arseny Solokha asolo...@kb.kras.ru
---
arch/powerpc/boot/planetcore.c | 33 -
arch/powerpc/boot/planetcore.h | 3 ---
2 files changed, 36 deletions(-)
diff --git a/arch/powerpc/boot/planetcore.c b/arch/powerpc/boot/planetcore.c
index 0d8558a..75117e6 100644
--- a/arch/powerpc/boot/planetcore.c
+++ b/arch/powerpc/boot/planetcore.c
@@ -131,36 +131,3 @@ void planetcore_set_stdout_path(const char *table)
setprop_str(chosen, linux,stdout-path, path);
}
-
-void planetcore_set_serial_speed(const char *table)
-{
- void *chosen, *stdout;
- u64 baud;
- u32 baud32;
- int len;
-
- chosen = finddevice(/chosen);
- if (!chosen)
- return;
-
- len = getprop(chosen, linux,stdout-path, prop_buf, MAX_PROP_LEN);
- if (len = 0)
- return;
-
- stdout = finddevice(prop_buf);
- if (!stdout) {
- printf(planetcore_set_serial_speed:
- Bad /chosen/linux,stdout-path.\r\n);
-
- return;
- }
-
- if (!planetcore_get_decimal(table, PLANETCORE_KEY_SERIAL_BAUD,
- baud)) {
- printf(planetcore_set_serial_speed: No SB tag.\r\n);
- return;
- }
-
- baud32 = baud;
- setprop(stdout, current-speed, baud32, 4);
-}
diff --git a/arch/powerpc/boot/planetcore.h b/arch/powerpc/boot/planetcore.h
index 0d4094f..d53c733 100644
--- a/arch/powerpc/boot/planetcore.h
+++ b/arch/powerpc/boot/planetcore.h
@@ -43,7 +43,4 @@ void planetcore_set_mac_addrs(const char *table);
*/
void planetcore_set_stdout_path(const char *table);
-/* Sets the current-speed property in the serial node. */
-void planetcore_set_serial_speed(const char *table);
-
#endif
--
2.3.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 0/7] ARM: berlin: refactor the clock
On 16.02.2015 04:37, Jisheng Zhang wrote: On Fri, 13 Feb 2015 08:42:54 -0800 Antoine Tenart antoine.ten...@free-electrons.com wrote: Marvell Berlin SoCs have a chip control register set providing several individual registers dealing with various controllers (pinctrl, reset, clk). This chip controller is described by a single DT node since the individual registers are spread among the chip control register bank. Marvell Berlin also have a system control register set providing several individual registers for pinctrl or adc. There's no chip control IP. The HW just put some HW registers into the so called chip control address space, the registers in this space are mostly used for control purpose, but some are not. Take the clk as an example, some clocks' registers are put into the system control register space, some clocks' are not. Jisheng, you are right, there is no specific IP for those registers. But as we don't want these registers to be spread among our SoC nodes, we chose to sum them all up into a single node. Back when the clk driver was proposed, Mike requested to not expose each of the clocks in DT - so we joined them basically into a single node and let the driver do the rest. Now, this patch set goes a little bit further and simply joins all of the chip ctrl registers into a single node and just adds sub-nodes where we need them (e.g. pinctrl). [...] In newer chips, there are no group clocks any more. So the driver code can be more simpler and clean. So I think we'd better to implement drivers without the chip control concept in mind. The previous clock patches reflect what the HW really does. I see no problem in what future SoCs do with register layout. It seems that it will be fundamentally different anyway, so we might consider to have a completely new driver for any SoC past BG2Q. The above is just my humble opinions and the current berlin clk driver is different with the previous one I dunno how can we handle this situation now. I really need help! We appreciate you share your opinion! How does having a single node (and basically a single reg property shared by regmap) block you from implementing support for your new SoC? Also, you don't need to follow the chip-ctrl node concept for the new SoC if it is too different. It is just that we kind of give up to chop this register set into functional pieces in DT and think it will be better dealt with in each of the drivers. Sebastian -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/2] e820: Fix handling of NvDIMM chips
Hi There is a deficiency in current e820.c handling where unknown new memory-chip types come up as a BUSY resource when some other driver (like pmem) tries to call request_mem_region_exclusive() on that resource. Even though, actually there is nothing using it. From inspecting the code and the history of e820.c it looks like a BUG. In any way this is a problem for the new type-12 NvDIMM memory chips that are circulating around. (It is estimated that there are already 100ds of thousands NvDIMM chips in active use) The patches below first fixes the above problem for any future type memory, so external drivers can access these mem chips. I then also add the NvDIMM type-12 memory constant so it comes up nice in dprints and at /proc/iomem Just as before all these chips are very much usable with the pmem driver. This lets us remove the hack for type-12 NvDIMMs that ignores the return code from request_mem_region_exclusive() in pmem.c. There is a 3rd patch just for reference to pmem.c which enables pmem to work also on Old Kernels which do not include these 2 patches. For all the pmem people. I maintain a tree with these patches and latest pmem code (Also including DAX) here: git://git.open-osd.org/pmem.git [web-view:http://git.open-osd.org/gitweb.cgi?p=pmem.git;a=summary] List of patches: [PATCH 1/2] e820: Don't let unknown DIMM type come out BUSY [RFC 2/2] e820: Add the NvDIMM Memory type (type-12) These are for submission [PATCH 3/3] pmem: Allow request_mem to fail (CONFIG_BLK_DEV_PMEM_IGNORE_REQUEST_MEM_RET) Just for reference Thanks Boaz -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.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 0/3] about data busy
Hello Jaehoon, On Mon, Feb 16, 2015 at 6:48 AM, Jaehoon Chung jh80.ch...@samsung.com wrote: On 02/15/2015 08:41 PM, Javier Martinez Canillas wrote: I modified [1] your patch #2 to do what Alim suggested and only with that patch on top of linux-next I have neither the the Timeout sending command error nor the uSD not getting detected errors. Linux mounts the rootfs from the uSD and the wifi SDIO device is enumerated and listed in /sys/bus/sdio/devices/ it needs to check when clock value only update. As Javier and Alim are mentioned, if check whether card is busy or not in setup_bus(), should be processed unnecessary checking. (According to TRM, before disabling clock, check whether card is busy or not.) if my thinking is right, chekcing is located more exactly before mci_writel(host, CLKENA, 0). And i recommend if CLK_GATE is enabled, clkgate_delay sets to the bigger value than 3. I'm not sure Javier's issue is same thing..I will check more this. Thanks for checking, do you have access to a Peach Pit or Pi Chromebook to reproduce the issue I reported? Please let me know if you need any help from me. Best Regards, Jaehoon Chung Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.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 RFC 2/2] ARM: pxa: transition to dmaengine phase 1
- Mail original -
De: Arnd Bergmann a...@arndb.de
À: linux-arm-ker...@lists.infradead.org
Cc: Robert Jarzmik robert.jarz...@free.fr, Vinod Koul
vinod.k...@intel.com, Olof Johansson o...@lixom.net, Daniel Mack
zon...@gmail.com, Haojian Zhuang haojian.zhu...@gmail.com,
dmaeng...@vger.kernel.org, linux-kernel@vger.kernel.org
Envoyé: Lundi 16 Février 2015 11:28:57
Objet: Re: [PATCH RFC 2/2] ARM: pxa: transition to dmaengine phase 1
On Saturday 14 February 2015 23:47:33 Robert Jarzmik wrote:
@@ -294,7 +294,8 @@ int pxa_request_dma (char *name, pxa_dma_prio prio,
/* try grabbing a DMA channel with the requested priority */
for (i = 0; i num_dma_channels; i++) {
if ((dma_channels[i].prio == prio)
- !dma_channels[i].name) {
+ !dma_channels[i].name
+ !mmp_pdma_toggle_reserved_channel(i)) {
found = 1;
break;
}
How is the order between the two enforced? I.e. can it be that the dmaengine
driver uses the same channel for a different slave before we get here?
If a request is made for a low prio channel, ie. channel 8, 9 or 10 if I
remember
correctly :
- suppose dmaengine has transactions underway, and channel 8 is busy
- this loop, for i == 8 : mmp_pdma_toggle_reserved_channel(8) - -EBUSY
- loop continues, i == 9 : mmp_pdma_toggle_reserved_channel(8) - 0
= pxa_request_dma reserves channel 9
From now on, mmp_pdma will skip channel 9 from its candidates to serve
requests.
If this is ensured to work, I'm fine with your approach.
Actually it does. Not exactly this version, as the mmp_pdma interrupt was a bit
amended to skip also reserved channels and not steal events from legacy code,
but that will be for official submission.
It's also designed to be race free, relying on the fact that there is only one
CPU on pxa{2,3}xx SocS (irq_save covers).
I'm testing it right now with 2 drivers :
- pxa3xx_nand, which is converted to dmaengine
- pxamci, which is not converted to dmaengine
In 3 variants :
- zylonite pxa3xx board booted with device-tree
- zylonite pxa3xx board booted in legacy
- mioa701 board booted in device-tree
So far so good. If the mmp_pdma patch is accepted for the transition, it will
open up my path towards dmaengine conversion of all pxa drivers (mmc, nand,
pxa_camera and pxa2xx-pcm-lib). As Daniel has already done most of the work,
and because I have kept it for 2 years, that part will be less a burden than
it would seem ... only the camera will give me a small headache.
Cheers.
--
Robert
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] e820: Don't let unknown DIMM type come out BUSY
There is something not very nice (Gentlemen nice) In current
e820.c code.
At Multiple place for example @ memblock_x86_fill(), it will
add the different memory resources *except the E820_RESERVED type*
Then at e820_reserve_resources() it will mark all !E820_RESERVED
as busy.
This is all fine when we have only the known types one of:
E820_RESERVED_KERN:
E820_RAM:
E820_ACPI:
E820_NVS:
E820_UNUSABLE:
E820_RESERVED:
But if the system encounters a brand new memory type it will
not add it to any memory list, But will proceed to mark it
BUSY. So now any other Driver in the system that does know
how to deal with this new type, is not able to call
request_mem_region_exclusive() on this new type because it is
hard coded BUSY even though nothing really uses it.
So make any unknown type behave like E820_RESERVED memory,
it will show up as available to first caller of
request_mem_region_exclusive().
I Also change the string representation of an unknown type
from reserved (So to not confuse with memmap reserved
region). And call it reserved-unknown
I wish I could return reserved-type-X But this is not possible
because one must return a constant, code-segment, string.
(NOTE: These unknown-types where called reserved in
/proc/iomem and in dmesg but behaved differently. What this
patch does is name them differently but let them behave
the same)
An example of such UNKNOWN type is the not Standard type-12
DDR3-NvDIMM which is used by multiple vendors for a while
now. (Estimated 100ds of thousands sold world wide)
A later patch adds type-12 to the list of KNOWN, types.
Signed-off-by: Boaz Harrosh b...@plexistor.com
---
arch/x86/kernel/e820.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git a/arch/x86/kernel/e820.c b/arch/x86/kernel/e820.c
index 46201de..8cfd25f 100644
--- a/arch/x86/kernel/e820.c
+++ b/arch/x86/kernel/e820.c
@@ -907,7 +907,23 @@ static inline const char *e820_type_to_string(int
e820_type)
case E820_ACPI: return ACPI Tables;
case E820_NVS: return ACPI Non-volatile Storage;
case E820_UNUSABLE: return Unusable memory;
- default:return reserved;
+ case E820_RESERVED: return reserved;
+ default:return reserved-unkown;
+ }
+}
+
+static bool _is_reserved_type(int e820_type)
+{
+ switch (e820_type) {
+ case E820_RESERVED_KERN:
+ case E820_RAM:
+ case E820_ACPI:
+ case E820_NVS:
+ case E820_UNUSABLE:
+ return false;
+ case E820_RESERVED:
+ default:
+ return true;
}
}
@@ -940,7 +956,7 @@ void __init e820_reserve_resources(void)
* pci device BAR resource and insert them later in
* pcibios_resource_survey()
*/
- if (e820.map[i].type != E820_RESERVED || res-start
(1ULL20)) {
+ if (!_is_reserved_type(e820.map[i].type) || res-start
(1ULL20)) {
res-flags |= IORESOURCE_BUSY;
insert_resource(iomem_resource, res);
}
--
1.9.3
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC 2/2] ARM: pxa: transition to dmaengine phase 1
On Sun, Feb 15, 2015 at 1:47 AM, Robert Jarzmik robert.jarz...@free.fr wrote: In order to slowly transition pxa to dmaengine, the legacy code will now rely on dmaengine to request a channel. Hi Robert, What about dropping old PXA DMA code completely? Daniel Mack did port for most of PXA drivers to dma engine, I've rebased his patches against 3.17 several months ago and fixed oopses in pxamci and asoc drivers, but I didn't resubmit whole series due to lack of time. My 3.17 tree is at [1], I've tested it on pxa270 machine (Zipit Z2), and everything works fine so far. I guess it won't be too much work to rebase it against linux-3.20. Regards, Vasily [1] https://github.com/anarsoul/linux-2.6/tree/v3.17-pxa-dmaengine-wip -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MIPS: CONFIG_MIPS_R6?
Leonid, On Sat, 2015-02-14 at 17:22 -0800, Leonid Yegoshin wrote: On 02/14/2015 09:21 AM, Paul Bolle wrote: Your commits 430857eae56c (MIPS: mm: Add MIPS R6 instruction encodings) and 90163242784b (MIPS: kernel: unaligned: Add support for the MIPS R6) are included in yesterday's linux-next (ie, next-20150213). I noticed because a script I use to check linux-next spotted a problem with it. These commits added three references to CONFIG_MIPS_R6, were probably CONFIG_CPU_MIPSR6 was intended. One reference is in a comment, which should be trivial to get fixed. The other two references are in (negative) preprocessor checks. It's not certain, at least not to me, how these should be fixed. Paul Bolle Yes, please. The obvious fix (ie, three times s/CONFIG_MIPS_R6/CONFIG_CPU_MIPSR6/) isn't trivial and requires run time testing, which I have no idea how to do, sorry. Paul Bolle -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [PATCH 0/6] Drivers: hv: vmbus
-Original Message- From: KY Srinivasan Sent: Monday, February 16, 2015 13:28 PM To: Dexuan Cui; gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com Subject: RE: [PATCH 0/6] Drivers: hv: vmbus -Original Message- From: Dexuan Cui Sent: Sunday, February 15, 2015 7:19 PM To: KY Srinivasan; gre...@linuxfoundation.org; linux- ker...@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com Subject: RE: [PATCH 0/6] Drivers: hv: vmbus -Original Message- From: devel [mailto:driverdev-devel-boun...@linuxdriverproject.org] On Behalf Of K. Y. Srinivasan Sent: Monday, February 16, 2015 4:11 AM To: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; de...@linuxdriverproject.org; o...@aepfle.de; a...@canonical.com; vkuzn...@redhat.com Subject: [PATCH 0/6] Drivers: hv: vmbus The host can rescind an offer any time after the offer has been made to the guest. This patch-set cleans up how we handle rescind messages from the host. K. Y. Srinivasan (6): Drivers: hv: vmbus: Properly handle child device remove Drivers: hv: vmbus: Introduce a function to remove a rescinded offer Drivers: hv: vmbus: Handle both rescind and offer messages in the same context Drivers: hv: vmbus: Remove the channel from the channel list(s) on failure Drivers: hv: util: On device remove, close the channel after de-initializing the service Drivers: hv: vmbus: Get rid of some unnecessary messages drivers/hv/channel.c |9 drivers/hv/channel_mgmt.c | 95 - --- drivers/hv/connection.c |7 +--- drivers/hv/hv_util.c |2 +- drivers/hv/vmbus_drv.c| 26 +--- include/linux/hyperv.h|1 + 6 files changed, 74 insertions(+), 66 deletions(-) -- The patchset seems good to me. Reviewed-by: Dexuan Cui de...@microsoft.com Dexuan, Thank you for the review. BTW, IMO we need one more patch to remove the queue_work() in free_channel() -- just make it an ordinary synchronous function call: vmbus_process_offer() can invoke free_channel() on error path, and vmbus_process_rescind() can invoke free_channel() too. We should exclude the possible race. I don't see the race; free_channel is only called after ensuring the channel KY, You're correct. Sorry for my misreading. cannot be discovered by any other context. Note that we are now executing both rescind and the offer message in the same work context. With this patch-set, there are only 3 call sites for free_channel: 1. hv_process_channel_removal() 2. vmbus_free_channels() 3. vmbus_process_offer() If vmbus_process_offer() calls free_channel, the channel cannot be discovered via its ID as we remove The chanel from the global as well as the per-cpu lists. In this case, the channel is destroyed and nobody can get a reference to it. Yeah, I got this now. -- Dexuan And now the controlwq and work fields of struct vmbus_channel are useless now. Yes; we can get rid of this now. I will have that in a separate patch. Regards, K. Y -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.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] mfd: stw481x: Remove unused fields from struct stw481x
On Fri, Feb 13, 2015 at 6:28 AM, Axel Lin axel@ingics.com wrote: The mutex lock is not used at all, remove it. The *vmmc_regulator is not necessary, use a local variable in stw481x_vmmc_regulator_probe() instead. Signed-off-by: Axel Lin axel@ingics.com Reviewed-by: Linus Walleij linus.wall...@linaro.org Thanks a lot Axel! Yours, Linus Walleij -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 3/5] irqchip: Add DT binding doc for the virtual irq demuxer chip
Guys, trim your emails, please! On Wed, Feb 11, 2015 at 04:51:36PM +0100, Rafael J. Wysocki wrote: On Wednesday, February 11, 2015 03:12:38 PM Mark Rutland wrote: I guess that would have to imply IRQF_SHARED, so we'd have something like: IRQF_SHARED_SUSPEND_OK - This handler is safe to call spuriously during suspend in the case the line is shared. The handler will not access unavailable hardware or kernel infrastructure during this period. #define __IRQF_SUSPEND_SPURIOUS 0x0004 #define IRQF_SHARED_SUSPEND_OK (IRQF_SHARED | __IRQF_SUSPEND_SPURIOUS) What about #define __IRQF_TIMER_SIBLING_OK 0x0004 #define IRQF_SHARED_TIMER_OK(IRQF_SHARED | __IRQF_TIMER_SIBLING_OK) The suspend part is kind of a distraction to me here, because that really only is about sharing an IRQ with a timer and the your interrupt handler may be called when the device is suspended part is just a consequence of that. So IMO it's better to have TIMER in the names to avoid encouraging people to abuse this for other purposes not related to timers. Sorry to be late to the bike-shed party, but what about: Documentation/power/suspend-and-interrupts.txt:the IRQ's users. For this reason, using IRQF_NO_SUSPEND and IRQF_SHARED at the arch/arm/mach-omap2/mux.c: omap_hwmod_mux_handle_irq, IRQF_SHARED | IRQF_NO_SUSPEND, arch/arm/mach-omap2/pm34xx.c: _prcm_int_handle_io, IRQF_SHARED | IRQF_NO_SUSPEND, pm_io, drivers/mfd/ab8500-debugfs.c: IRQF_SHARED | IRQF_NO_SUSPEND, drivers/mfd/ab8500-gpadc.c: IRQF_NO_SUSPEND | IRQF_SHARED, ab8500-gpadc-sw, drivers/mfd/ab8500-gpadc.c: IRQF_NO_SUSPEND | IRQF_SHARED, ab8500-gpadc-hw, drivers/pinctrl/pinctrl-single.c: IRQF_SHARED | IRQF_NO_SUSPEND, drivers/power/ab8500_btemp.c: IRQF_SHARED | IRQF_NO_SUSPEND, drivers/power/ab8500_charger.c: IRQF_SHARED | IRQF_NO_SUSPEND, drivers/power/ab8500_fg.c: IRQF_SHARED | IRQF_NO_SUSPEND, drivers/rtc/rtc-pl031.c:.irqflags = IRQF_SHARED | IRQF_NO_SUSPEND, drivers/usb/phy/phy-ab8500-usb.c: IRQF_NO_SUSPEND | IRQF_SHARED, drivers/usb/phy/phy-ab8500-usb.c: IRQF_NO_SUSPEND | IRQF_SHARED, drivers/usb/phy/phy-ab8500-usb.c: IRQF_NO_SUSPEND | IRQF_SHARED, drivers/watchdog/intel-mid_wdt.c: IRQF_SHARED | IRQF_NO_SUSPEND, watchdog, Is there a single legitimate user in that list? If so, the TIMER name might be misleading. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: MIPS: FP32XX_HYBRID_FPRS
On Sat, Feb 14, 2015 at 06:33:59PM +0100, Paul Bolle wrote: On Sat, 2015-02-14 at 17:57 +0100, Paul Bolle wrote: Your d8fb6537f1d4 (MIPS: kernel: elf: Improve the overall ABI and FPU mode checks) is included in yesterday's linux-next (ie, next-20150213). I noticed because a script I use to check linux-next spotted a minor problem with it. That commit removed the only user of Kconfig symbol FP32XX_HYBRID_FPRS. Setting FP32XX_HYBRID_FPRS is now pointless in linux-next. Is the trivial commit to its entry form arch/mips/Kconfig.debug queued [] to remove its entry from [...] somewhere? Paul Bolle Hi Paul, Thanks I will fix the original patch to drop this symbol -- markos -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.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] ARM: smp: Only expose /sys/.../cpuX/online if hotpluggable
On Sat, Feb 14, 2015 at 1:42 AM, Stephen Boyd sb...@codeaurora.org wrote:
--- a/arch/arm/include/asm/smp.h
+++ b/arch/arm/include/asm/smp.h
@@ -104,6 +104,7 @@ struct smp_operations {
#ifdef CONFIG_HOTPLUG_CPU
int (*cpu_kill)(unsigned int cpu);
void (*cpu_die)(unsigned int cpu);
+ int (*cpu_can_disable)(unsigned int cpu);
Perhaps this should be changed to return bool while you're adding the function?
That saves us from an atomic update later when someone does janitorial work.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] [media] mantis: Move jump label to activate dead code
On Sun, Feb 15, 2015 at 01:11:04PM +0100, Silvan Jegen wrote:
diff --git a/drivers/media/pci/mantis/mantis_cards.c
b/drivers/media/pci/mantis/mantis_cards.c
index 801fc55..e566061 100644
--- a/drivers/media/pci/mantis/mantis_cards.c
+++ b/drivers/media/pci/mantis/mantis_cards.c
@@ -215,10 +215,11 @@ static int mantis_pci_probe(struct pci_dev *pdev,
dprintk(MANTIS_ERROR, 1, ERROR: Mantis DVB initialization
failed %d, err);
goto fail4;
}
+
err = mantis_uart_init(mantis);
if (err 0) {
dprintk(MANTIS_ERROR, 1, ERROR: Mantis UART initialization
failed %d, err);
- goto fail6;
+ goto fail5;
}
devs++;
@@ -226,10 +227,10 @@ static int mantis_pci_probe(struct pci_dev *pdev,
return err;
+fail5:
dprintk(MANTIS_ERROR, 1, ERROR: Mantis UART exit! %d, err);
mantis_uart_exit(mantis);
-fail6:
fail4:
dprintk(MANTIS_ERROR, 1, ERROR: Mantis DMA exit! %d, err);
mantis_dma_exit(mantis);
This patch isn't right, I'm afraid. The person who wrote this driver
deliberately added some dead error handling code in case we change it
later and need to activate it. It's an ugly thing to do because it
causes static checker warnings, and confusion, and, in real life, then
we are not ever going to need to activate it. It's defensive
programming but we don't do defensive programming.
http://lwn.net/Articles/604813/ Just delete this dead code.
Also this code uses GW-BASIC style numbered gotos. So ugly! The label
names should be based on what the label location does. Eg
err_uart_exit, err_dma_exit. I have written an essay about label
names: https://plus.google.com/106378716002406849458/posts/dnanfhQ4mHQ
In theory, we should be calling mantis_dvb_exit() if mantis_uart_init()
fails. In reality, it can't fail but it's still wrong to leave that
out.
These patches would be easier to review if you just folded them into one
patch. Call it fix error error handling or something.
regards,
dan carpenter
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/2] dgnc: Remove superfluous EXTRA_CFLAGS variable
On Sun, Feb 15, 2015 at 11:40:17PM +, Cass May wrote: Clean up Makefile by removing unnecessary definition of DG_NAME. Signed-off-by: Cass May c...@cassm.net --- Having done some build tests, it seems that DG_NAME is not needed, but DG_PART is referenced in dgnc_mgmt.c. I have removed the former, and moved the latter into the appropriate header. Thanks! Don't resend; this patch is great. But next time just fold both patches together into one patch. It's all part of the same fix really so it falls into the one thing per patch rule. regards, dan carpenter -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/5] xhci: add a quirk for device disconnection errata for Synopsis Designware USB3 core
On 15.02.2015 16:29, Sneeker Yeh wrote:
hi Mathias:
thanks for reviewing these patch,
and sorry for replying lately~
+ status = readl(port_array[dev_port_num - 1]);
+
+ /* write 1 to clear */
+ if (!(status PORT_CONNECT) (status PORT_CSC))
+ writel(status PORT_CSC, port_array[0]);
Shouldn't this be writel(...,port_array[dev_port_num - 1]) ?
yes, thanks for correcting this,
and I also would like to add xhci_port_state_to_neutral() you mentioned.
what would you think if I modify it like this?
+ /* write 1 to clear */
+ if (!(status PORT_CONNECT) (status PORT_CSC)) {
+ status = xhci_port_state_to_neutral(status);
+ writel(status | PORT_CSC, port_array[dev_port_num - 1]);
+ }
Looks good to me
-Mathias
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 08/10] USB: f81232: fix read MSR strange value
When we use RS232 loopback, assume doing RTS change will cause
CTS change, DTR change will cause DCD/DSR change too.
Sometimes we got 7~4 bits of MSR changed but the 3~0 bits of
MSR(delta) maybe not changed when set get MCR fasterly.
So we add more check not only UART_MSR_ANY_DELTA but also with
comparing DCD/RI/DSR/CTS change with old value. Due to the state
bit is always correct, we direct save msr when read.
The following step to reproduce this problem with while loop step 1~4:
1. ioctl(fd, TIOCMSET, data) to set RTS or DTR
2. ioctl(fd, TIOCMGET, data) to read CTS or DCD/DSR state
3. ioctl(fd, TIOCMSET, data) to unset RTS or DTR
4. ioctl(fd, TIOCMGET, data) to read CTS or DCD/DSR state
Signed-off-by: Peter Hung hpeter+linux_ker...@gmail.com
---
drivers/usb/serial/f81232.c | 23 +--
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index c87a3eb..94c05d7 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -110,7 +110,8 @@ static void f81232_read_msr(struct usb_serial_port *port)
{
int status;
unsigned long flags;
- u8 current_msr;
+ u8 current_msr, prev_msr;
+ u8 msr_mask = ~UART_MSR_ANY_DELTA;
struct tty_struct *tty;
struct f81232_private *priv = usb_get_serial_port_data(port);
@@ -123,7 +124,21 @@ static void f81232_read_msr(struct usb_serial_port *port)
return;
}
- if (!(current_msr UART_MSR_ANY_DELTA))
+ /*
+ * The 7~4 bits of MSR will change but the 3~0 bits of MSR(delta)
+ * maybe not change when set get MCR fasterly.
+ *
+ * So we add more check with comparing DCD/RI/DSR/CTS
+ * change. and direct save msr when read.
+ */
+
+ spin_lock_irqsave(priv-lock, flags);
+ prev_msr = priv-modem_status;
+ priv-modem_status = current_msr;
+ spin_unlock_irqrestore(priv-lock, flags);
+
+ if (!(current_msr UART_MSR_ANY_DELTA)
+ !((prev_msr ^ current_msr) msr_mask))
return;
tty = tty_port_tty_get(port-port);
@@ -136,10 +151,6 @@ static void f81232_read_msr(struct usb_serial_port *port)
tty_kref_put(tty);
}
- spin_lock_irqsave(priv-lock, flags);
- priv-modem_status = current_msr;
- spin_unlock_irqrestore(priv-lock, flags);
-
wake_up_interruptible(port-port.delta_msr_wait);
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 10/10] USB: f81232: modify/add author
Add me to co-author and fix no '' in greg kh's email
Signed-off-by: Peter Hung hpeter+linux_ker...@gmail.com
---
drivers/usb/serial/f81232.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 5134a19..5e35859 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -632,5 +632,6 @@ static struct usb_serial_driver * const serial_drivers[] = {
module_usb_serial_driver(serial_drivers, id_table);
MODULE_DESCRIPTION(Fintek F81232 USB to serial adaptor driver);
-MODULE_AUTHOR(Greg Kroah-Hartman gre...@linuxfoundation.org);
+MODULE_AUTHOR(Greg Kroah-Hartman gre...@linuxfoundation.org);
+MODULE_AUTHOR(Peter Hong peter_h...@fintek.com.tw);
MODULE_LICENSE(GPL v2);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH RFC v3 0/7] epoll: Introduce new syscalls, epoll_ctl_batch and epoll_pwait1
Hi Seymour,
On Mon, 02/16 07:25, Seymour, Shane M wrote:
I found the manual pages really confusing so I had a go at rewriting
them - there were places in the manual page that didn't match the
functionality provided by your code as well as I could tell).
Could you point which places don't match the code?
My apologies for a few formatting issues though. I still don't like
parts of epoll_pwait1 but it's less confusing than it was.
Any other than the timespec question don't you like?
You are free to take some or all or none of the changes.
I did have a question I marked with below about what you
describe and what your code does.
snip
The timeout member specifies the minimum time that epoll_wait(2) will
block. The time spent waiting will be rounded up to the clock
granularity. Kernel scheduling delays mean that the blocking
interval may overrun by a small amount. Specifying a -1 for either
tv_sec or tv_nsec member of the struct timespec timeout will cause
causes epoll_pwait1(2) to block indefinitely. Specifying a timeout
equal to zero (both tv_sec or tv_nsec member of the struct timespec
timeout are zero) causes epoll_wait(2) to return immediately, even
if no events are available.
Are you really really sure about this for the -1 stuff? your code copies
in the timespec and just passes it to timespec_to_ktime:
+ if (copy_from_user(p, params, sizeof(p)))
+ return -EFAULT;
...
+ kt = timespec_to_ktime(p.timeout);
Compare that to something like the futex syscall which does this:
if (copy_from_user(ts, utime, sizeof(ts)) != 0)
return -EFAULT;
if (!timespec_valid(ts))
return -EINVAL;
t = timespec_to_ktime(ts);
If the timespec is not valid it returns -EINVAL back to user space. With your
settings of tv_sec and/or tv_usec to -1 are you relying on a side effect of
the conversion that could break your code in the future if in the unlikely
event someone changes timespec_to_ktime() and should it be:
+ if (copy_from_user(p, params, sizeof(p)))
+ return -EFAULT;
+ if ((p.timeout.tv_sec == -1) || (p.timeout.tv_nsec == -1)) {
+ /* this is off the top of my head no idea if it will compile */
+ p.timeout.tv_sec = KTIME_SEC_MAX;
+ p.timeout.tv_nsec = 0;
+ }
+ if (!timespec_valid(p.timeout))
+ return -EINVAL;
...
+ kt = timespec_to_ktime(p.timeout);
OK. timespec_valid() is clear about this: negative tv_sec is invalid, so I
don't think accepting -1 from user is the right thing to do.
We cannot do pointer check as ppoll already because the structure is embedded
in epoll_wait_params.
Maybe it's best to use a flags bit (#define EPOLL_PWAIT1_BLOCK 1). What do you
think?
Fam
snip
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/4] f2fs: remove unused inline_dentry_addr
inline_dentry_addr is introduced with inline dentry feature without being used,
now we do not need to keep it for any reason, so remove it.
Signed-off-by: Chao Yu chao2...@samsung.com
---
fs/f2fs/f2fs.h | 6 --
1 file changed, 6 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 7fa3313..a978b65 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1290,12 +1290,6 @@ static inline int f2fs_has_inline_dentry(struct inode
*inode)
return is_inode_flag_set(F2FS_I(inode), FI_INLINE_DENTRY);
}
-static inline void *inline_dentry_addr(struct page *page)
-{
- struct f2fs_inode *ri = F2FS_INODE(page);
- return (void *)(ri-i_addr[1]);
-}
-
static inline void f2fs_dentry_kunmap(struct inode *dir, struct page *page)
{
if (!f2fs_has_inline_dentry(dir))
--
2.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] f2fs: introduce f2fs_update_dentry to clean up duplicated codes
This patch introduces f2fs_update_dentry to remove redundant code in
f2fs_add_inline_entry and __f2fs_add_link.
Signed-off-by: Chao Yu chao2...@samsung.com
---
fs/f2fs/dir.c| 33 +++--
fs/f2fs/f2fs.h | 2 ++
fs/f2fs/inline.c | 18 ++
3 files changed, 31 insertions(+), 22 deletions(-)
diff --git a/fs/f2fs/dir.c b/fs/f2fs/dir.c
index b74097a..583896c 100644
--- a/fs/f2fs/dir.c
+++ b/fs/f2fs/dir.c
@@ -474,6 +474,24 @@ next:
goto next;
}
+void f2fs_update_dentry(struct inode *inode, struct f2fs_dentry_ptr *d,
+ const struct qstr *name, f2fs_hash_t name_hash,
+ unsigned int bit_pos)
+{
+ struct f2fs_dir_entry *de;
+ int slots = GET_DENTRY_SLOTS(name-len);
+ int i;
+
+ de = d-dentry[bit_pos];
+ de-hash_code = name_hash;
+ de-name_len = cpu_to_le16(name-len);
+ memcpy(d-filename[bit_pos], name-name, name-len);
+ de-ino = cpu_to_le32(inode-i_ino);
+ set_de_type(de, inode);
+ for (i = 0; i slots; i++)
+ test_and_set_bit_le(bit_pos + i, (void *)d-bitmap);
+}
+
/*
* Caller should grab and release a rwsem by calling f2fs_lock_op() and
* f2fs_unlock_op().
@@ -486,15 +504,14 @@ int __f2fs_add_link(struct inode *dir, const struct qstr
*name,
unsigned int current_depth;
unsigned long bidx, block;
f2fs_hash_t dentry_hash;
- struct f2fs_dir_entry *de;
unsigned int nbucket, nblock;
size_t namelen = name-len;
struct page *dentry_page = NULL;
struct f2fs_dentry_block *dentry_blk = NULL;
+ struct f2fs_dentry_ptr d;
int slots = GET_DENTRY_SLOTS(namelen);
struct page *page;
int err = 0;
- int i;
if (f2fs_has_inline_dentry(dir)) {
err = f2fs_add_inline_entry(dir, name, inode);
@@ -553,14 +570,10 @@ add_dentry:
err = PTR_ERR(page);
goto fail;
}
- de = dentry_blk-dentry[bit_pos];
- de-hash_code = dentry_hash;
- de-name_len = cpu_to_le16(namelen);
- memcpy(dentry_blk-filename[bit_pos], name-name, name-len);
- de-ino = cpu_to_le32(inode-i_ino);
- set_de_type(de, inode);
- for (i = 0; i slots; i++)
- test_and_set_bit_le(bit_pos + i, dentry_blk-dentry_bitmap);
+
+ make_dentry_ptr(d, (void *)dentry_blk, 1);
+ f2fs_update_dentry(inode, d, name, dentry_hash, bit_pos);
+
set_page_dirty(dentry_page);
/* we don't need to mark_inode_dirty now */
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index a978b65..f8da399 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1376,6 +1376,8 @@ ino_t f2fs_inode_by_name(struct inode *, struct qstr *);
void f2fs_set_link(struct inode *, struct f2fs_dir_entry *,
struct page *, struct inode *);
int update_dent_inode(struct inode *, const struct qstr *);
+void f2fs_update_dentry(struct inode *, struct f2fs_dentry_ptr *,
+ const struct qstr *, f2fs_hash_t , unsigned int);
int __f2fs_add_link(struct inode *, const struct qstr *, struct inode *);
void f2fs_delete_entry(struct f2fs_dir_entry *, struct page *, struct inode *,
struct inode *);
diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
index 1484c00..82b7441 100644
--- a/fs/f2fs/inline.c
+++ b/fs/f2fs/inline.c
@@ -386,15 +386,12 @@ int f2fs_add_inline_entry(struct inode *dir, const struct
qstr *name,
struct page *ipage;
unsigned int bit_pos;
f2fs_hash_t name_hash;
- struct f2fs_dir_entry *de;
size_t namelen = name-len;
struct f2fs_inline_dentry *dentry_blk = NULL;
+ struct f2fs_dentry_ptr d;
int slots = GET_DENTRY_SLOTS(namelen);
struct page *page;
int err = 0;
- int i;
-
- name_hash = f2fs_dentry_hash(name);
ipage = get_node_page(sbi, dir-i_ino);
if (IS_ERR(ipage))
@@ -418,14 +415,11 @@ int f2fs_add_inline_entry(struct inode *dir, const struct
qstr *name,
}
f2fs_wait_on_page_writeback(ipage, NODE);
- de = dentry_blk-dentry[bit_pos];
- de-hash_code = name_hash;
- de-name_len = cpu_to_le16(namelen);
- memcpy(dentry_blk-filename[bit_pos], name-name, name-len);
- de-ino = cpu_to_le32(inode-i_ino);
- set_de_type(de, inode);
- for (i = 0; i slots; i++)
- test_and_set_bit_le(bit_pos + i, dentry_blk-dentry_bitmap);
+
+ name_hash = f2fs_dentry_hash(name);
+ make_dentry_ptr(d, (void *)dentry_blk, 2);
+ f2fs_update_dentry(inode, d, name, name_hash, bit_pos);
+
set_page_dirty(ipage);
/* we don't need to mark_inode_dirty now */
--
2.2.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
Re: [PATCH v5 0/7] platform/chrome: Add user-space dev inferface support
Hello Olof, On 02/02/2015 12:26 PM, Javier Martinez Canillas wrote: Hello, The mainline ChromeOS Embedded Controller (EC) driver is still missing some features that are present in the downstream ChromiumOS tree. These are: - Low Pin Count (LPC) interface - User-space device interface - Access to vboot context stored on a block device - Access to vboot context stored on EC's nvram - Power Delivery Device - Support for multiple EC in a system This is a fifth version of a series that adds support for the first two of the missing features: the EC LPC and EC character device interfaces that are used by user-space to access the ChromeOS EC. The support patches were taken from the downstream ChromiumOS 3.14 tree with the fixes and cleanups squashed to have a minimal patch-set. Any comments on this series? The last version was posted a couple of weeks ago but the series have been in the list for months. Lee has already acked the mfd changes so you can merge all through your chrome-platform tree if you want. It wold be great if this series get in to have the EC user-space interface supported and to minimize the delta with the Chromemium OS kernel since it still has other features that needs to be upstreamed like multiple EC in a system and access to vboot context stored in block device or EC's nvram. Best regards, Javier -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 03/10] USB: f81232: implement RX bulk-in ep
The F81232 bulk-in is RX data + LSR channel, data format is
[LSR+Data][LSR+Data]. , We had reimplemented in this patch.
Signed-off-by: Peter Hung hpeter+linux_ker...@gmail.com
---
drivers/usb/serial/f81232.c | 68 +++--
1 file changed, 35 insertions(+), 33 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index ec4609d..9ea498a 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -185,44 +185,46 @@ exit:
static void f81232_process_read_urb(struct urb *urb)
{
struct usb_serial_port *port = urb-context;
- struct f81232_private *priv = usb_get_serial_port_data(port);
unsigned char *data = urb-transfer_buffer;
- char tty_flag = TTY_NORMAL;
- unsigned long flags;
- u8 line_status;
+ char tty_flag;
int i;
- /* update line status */
- spin_lock_irqsave(priv-lock, flags);
- line_status = priv-modem_status;
- priv-modem_status = ~UART_STATE_TRANSIENT_MASK;
- spin_unlock_irqrestore(priv-lock, flags);
-
- if (!urb-actual_length)
+ if (urb-actual_length 2)
return;
- /* break takes precedence over parity, */
- /* which takes precedence over framing errors */
- if (line_status UART_BREAK_ERROR)
- tty_flag = TTY_BREAK;
- else if (line_status UART_PARITY_ERROR)
- tty_flag = TTY_PARITY;
- else if (line_status UART_FRAME_ERROR)
- tty_flag = TTY_FRAME;
- dev_dbg(port-dev, %s - tty_flag = %d\n, __func__, tty_flag);
-
- /* overrun is special, not associated with a char */
- if (line_status UART_OVERRUN_ERROR)
- tty_insert_flip_char(port-port, 0, TTY_OVERRUN);
-
- if (port-port.console port-sysrq) {
- for (i = 0; i urb-actual_length; ++i)
- if (!usb_serial_handle_sysrq_char(port, data[i]))
- tty_insert_flip_char(port-port, data[i],
- tty_flag);
- } else {
- tty_insert_flip_string_fixed_flag(port-port, data, tty_flag,
- urb-actual_length);
+ /* bulk-in data: [LSR(1Byte)+DATA(1Byte)][LSR(1Byte)+DATA(1Byte)]... */
+
+ for (i = 0 ; i urb-actual_length ; i += 2) {
+ tty_flag = TTY_NORMAL;
+
+ if (unlikely(data[i+0] UART_LSR_BRK_ERROR_BITS)) {
+ if (data[i+0] UART_LSR_BI) {
+ tty_flag = TTY_BREAK;
+ port-icount.brk++;
+ usb_serial_handle_break(port);
+ } else if (data[i+0] UART_LSR_PE) {
+ tty_flag = TTY_PARITY;
+ port-icount.parity++;
+ } else if (data[i+0] UART_LSR_FE) {
+ tty_flag = TTY_FRAME;
+ port-icount.frame++;
+ }
+
+ if (data[0] UART_LSR_OE) {
+ port-icount.overrun++;
+ tty_insert_flip_char(port-port, 0,
+ TTY_OVERRUN);
+ }
+ }
+
+ if (port-port.console port-sysrq) {
+ if (!usb_serial_handle_sysrq_char(port, data[i+1]))
+ tty_insert_flip_char(port-port, data[i+1],
+ tty_flag);
+ } else {
+ tty_insert_flip_string_fixed_flag(port-port,
+ data[i+1], tty_flag, 1);
+ }
}
tty_flip_buffer_push(port-port);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sched/completion: completion_done() should serialize with complete()
On Thu, Feb 12, 2015 at 08:59:13PM +0100, Oleg Nesterov wrote:
Commit de30ec47302c Remove unnecessary -wait.lock serialization when
reading completion state was not correct, without lock/unlock the code
like stop_machine_from_inactive_cpu()
while (!completion_done())
cpu_relax();
can return before complete() finishes its spin_unlock() which writes to
this memory. And spin_unlock_wait().
While at it, change try_wait_for_completion() to use READ_ONCE().
So I share Davidlohrs concern if we should not simply revert that
change; but given we've now gone over it detail I suppose we should just
keep the optimized version.
I did add a comment to your patch; and queued the below for
sched/urgent.
---
Subject: sched/completion: completion_done() should serialize with complete()
From: Oleg Nesterov o...@redhat.com
Date: Thu, 12 Feb 2015 20:59:13 +0100
Commit de30ec47302c Remove unnecessary -wait.lock serialization when
reading completion state was not correct, without lock/unlock the code
like stop_machine_from_inactive_cpu()
while (!completion_done())
cpu_relax();
can return before complete() finishes its spin_unlock() which writes to
this memory. And spin_unlock_wait().
While at it, change try_wait_for_completion() to use READ_ONCE().
Fixes: de30ec47302c (sched/completion: Remove unnecessary -wait.lock
serialization when reading completion state)
Cc: waiman.l...@hp.com
Cc: raghavendra...@linux.vnet.ibm.com
Cc: d...@stgolabs.net
Cc: Nicholas Mc Guire der.h...@hofr.at
Cc: Linus Torvalds torva...@linux-foundation.org
Reported-by: Paul E. McKenney paul...@linux.vnet.ibm.com
Tested-by: Paul E. McKenney paul...@linux.vnet.ibm.com
Reported-by: Davidlohr Bueso d...@stgolabs.net
Signed-off-by: Oleg Nesterov o...@redhat.com
[peterz: Add a comment with the barrier]
Signed-off-by: Peter Zijlstra (Intel) pet...@infradead.org
Link: http://lkml.kernel.org/r/20150212195913.ga30...@redhat.com
---
kernel/sched/completion.c | 19 +--
1 file changed, 17 insertions(+), 2 deletions(-)
--- a/kernel/sched/completion.c
+++ b/kernel/sched/completion.c
@@ -274,7 +274,7 @@ bool try_wait_for_completion(struct comp
* first without taking the lock so we can
* return early in the blocking case.
*/
- if (!ACCESS_ONCE(x-done))
+ if (!READ_ONCE(x-done))
return 0;
spin_lock_irqsave(x-wait.lock, flags);
@@ -297,6 +297,21 @@ EXPORT_SYMBOL(try_wait_for_completion);
*/
bool completion_done(struct completion *x)
{
- return !!ACCESS_ONCE(x-done);
+ if (!READ_ONCE(x-done))
+ return false;
+
+ /*
+* If -done, we need to wait for complete() to release -wait.lock
+* otherwise we can end up freeing the completion before complete()
+* is done referencing it.
+*
+* The RMB pairs with complete()'s RELEASE of -wait.lock and orders
+* the loads of -done and -wait.lock such that we cannot observe
+* the lock before complete() acquires it while observing the -done
+* after it's acquired the lock.
+*/
+ smp_rmb();
+ spin_unlock_wait(x-wait.lock);
+ return true;
}
EXPORT_SYMBOL(completion_done);
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/4] f2fs: use -writepage in sync_meta_pages
This patch uses -writepage of meta mapping in sync_meta_pages instead of
f2fs_write_meta_page, by this way, in its caller we can ignore any changes
(e.g. changing name) of this registered function.
Signed-off-by: Chao Yu chao2...@samsung.com
---
fs/f2fs/checkpoint.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/f2fs/checkpoint.c b/fs/f2fs/checkpoint.c
index 7f794b7..6faffce 100644
--- a/fs/f2fs/checkpoint.c
+++ b/fs/f2fs/checkpoint.c
@@ -276,7 +276,7 @@ continue_unlock:
if (!clear_page_dirty_for_io(page))
goto continue_unlock;
- if (f2fs_write_meta_page(page, wbc)) {
+ if (mapping-a_ops-writepage(page, wbc)) {
unlock_page(page);
break;
}
--
2.2.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] b893e80e3147 breaks touchpad on Dell XPS13
Hi On 02/16/2015 09:14 AM, Chris Rorvick wrote: Hi, Commit b893e80e3147 (ACPI / LPSS: Remove non-existing clock control from Intel Lynxpoint I2C) is causing my touchpad to not load on my Dell XPS13. I do not see any errors in the Xorg log, just 20 or so lines missing where it would normally be loading the synaptics driver. Reverting this commit against Linus's tree (i.e., commit a9724125ad01) makes it happy again. Let me know if you need any further info. Your report is perfect reason for the revert. Even documentation doesn't state that clock gating control it's obviously needed in your machine. Probably some Lynxpoint versions have it and some don't. Anyway best is to revert since this clock gating haven't caused any harm on Lynxpoints which don't have it. I'll send a revert in a minute. -- Jarkko -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 09/10] USB: f81232: implement delta change for MSR count
We implement delta change for MSR counting. This patch is referenced
from ftdi_sio.c
Signed-off-by: Peter Hung hpeter+linux_ker...@gmail.com
---
drivers/usb/serial/f81232.c | 27 ++-
1 file changed, 22 insertions(+), 5 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index 94c05d7..5134a19 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -112,6 +112,7 @@ static void f81232_read_msr(struct usb_serial_port *port)
unsigned long flags;
u8 current_msr, prev_msr;
u8 msr_mask = ~UART_MSR_ANY_DELTA;
+ u8 msr_changed_bit;
struct tty_struct *tty;
struct f81232_private *priv = usb_get_serial_port_data(port);
@@ -141,14 +142,30 @@ static void f81232_read_msr(struct usb_serial_port *port)
!((prev_msr ^ current_msr) msr_mask))
return;
- tty = tty_port_tty_get(port-port);
- if (tty) {
- if (current_msr UART_MSR_DDCD) {
+ /* find checked delta bits set */
+ msr_changed_bit =
+ (current_msr UART_MSR_ANY_DELTA) 4;
+
+ /* append with not delta but changed bits */
+ msr_changed_bit |= (prev_msr ^ current_msr) msr_mask;
+
+ if (msr_changed_bit UART_MSR_CTS)
+ port-icount.cts++;
+ if (msr_changed_bit UART_MSR_DSR)
+ port-icount.dsr++;
+ if (msr_changed_bit UART_MSR_RI)
+ port-icount.rng++;
+ if (msr_changed_bit UART_MSR_DCD) {
+
+ port-icount.dcd++;
+ tty = tty_port_tty_get(port-port);
+ if (tty) {
+
usb_serial_handle_dcd_change(port, tty,
current_msr UART_MSR_DCD);
- }
- tty_kref_put(tty);
+ tty_kref_put(tty);
+ }
}
wake_up_interruptible(port-port.delta_msr_wait);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 06/10] USB: f81232: clarify f81232_ioctl and fix
We extract TIOCGSERIAL section in f81232_ioctl() to f81232_get_serial_info()
to make it clarify.
Also we fix device type from 16654 to 16550A, and set it's baud_base
to 115200 (1.8432MHz/16)
Signed-off-by: Peter Hung hpeter+linux_ker...@gmail.com
---
drivers/usb/serial/f81232.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index e1cdf42..e70ec62 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -516,24 +516,32 @@ static int f81232_carrier_raised(struct usb_serial_port
*port)
return 0;
}
+static int f81232_get_serial_info(struct usb_serial_port *port,
+ unsigned long arg)
+{
+ struct serial_struct ser;
+
+ memset(ser, 0, sizeof(ser));
+
+ ser.type = PORT_16550A;
+ ser.line = port-minor;
+ ser.port = port-port_number;
+ ser.baud_base = 115200;
+
+ if (copy_to_user((void __user *)arg, ser, sizeof(ser)))
+ return -EFAULT;
+
+ return 0;
+}
+
static int f81232_ioctl(struct tty_struct *tty,
unsigned int cmd, unsigned long arg)
{
- struct serial_struct ser;
struct usb_serial_port *port = tty-driver_data;
switch (cmd) {
case TIOCGSERIAL:
- memset(ser, 0, sizeof ser);
- ser.type = PORT_16654;
- ser.line = port-minor;
- ser.port = port-port_number;
- ser.baud_base = 460800;
-
- if (copy_to_user((void __user *)arg, ser, sizeof ser))
- return -EFAULT;
-
- return 0;
+ return f81232_get_serial_info(port, arg);
default:
break;
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH V6 07/10] USB: f81232: fix error in f81232_carrier_raised()
It's should compared with UART_MSR_DCD, not UART_DCD.
also we clean-up some non-used define to avoid impropriety use.
Signed-off-by: Peter Hung hpeter+linux_ker...@gmail.com
---
drivers/usb/serial/f81232.c | 16 +---
1 file changed, 1 insertion(+), 15 deletions(-)
diff --git a/drivers/usb/serial/f81232.c b/drivers/usb/serial/f81232.c
index e70ec62..c87a3eb 100644
--- a/drivers/usb/serial/f81232.c
+++ b/drivers/usb/serial/f81232.c
@@ -47,20 +47,6 @@ MODULE_DEVICE_TABLE(usb, id_table);
#define MODEM_CONTROL_REGISTER (0x04 + SERIAL_BASE_ADDRESS)
#define MODEM_STATUS_REGISTER (0x06 + SERIAL_BASE_ADDRESS)
-#define CONTROL_DTR0x01
-#define CONTROL_RTS0x02
-
-#define UART_STATE 0x08
-#define UART_STATE_TRANSIENT_MASK 0x74
-#define UART_DCD 0x01
-#define UART_DSR 0x02
-#define UART_BREAK_ERROR 0x04
-#define UART_RING 0x08
-#define UART_FRAME_ERROR 0x10
-#define UART_PARITY_ERROR 0x20
-#define UART_OVERRUN_ERROR 0x40
-#define UART_CTS 0x80
-
struct f81232_private {
spinlock_t lock;
u8 line_control;
@@ -511,7 +497,7 @@ static void f81232_dtr_rts(struct usb_serial_port *port,
int on)
static int f81232_carrier_raised(struct usb_serial_port *port)
{
struct f81232_private *priv = usb_get_serial_port_data(port);
- if (priv-modem_status UART_DCD)
+ if (priv-modem_status UART_MSR_DCD)
return 1;
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: [f2fs-dev] [PATCH v3 06/10] f2fs: add core functions for rb-tree extent cache
Ping.
Any comments on this patch now?
-Original Message-
From: Chao Yu [mailto:chao2...@samsung.com]
Sent: Thursday, February 05, 2015 5:55 PM
To: Jaegeuk Kim; Changman Lee
Cc: linux-kernel@vger.kernel.org; linux-f2fs-de...@lists.sourceforge.net
Subject: [f2fs-dev] [PATCH v3 06/10] f2fs: add core functions for rb-tree
extent cache
This patch adds core functions including slab cache init function and
init/lookup/update/shrink/destroy function for rb-tree based extent cache.
Thank Jaegeuk Kim and Changman Lee as they gave much suggestion about detail
design and implementation of extent cache.
Todo:
* register rb-based extent cache shrink with mm shrink interface.
v2:
o move set_extent_info and __is_{extent,back,front}_mergeable into f2fs.h.
o introduce __{attach,detach}_extent_node for code readability.
o add cond_resched() when fail to invoke kmem_cache_alloc/radix_tree_insert.
o fix some coding style and typo issues.
v3:
o fix oops due to using an unassigned pointer.
o use list_del to remove extent node in shrink list.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/1] pty: BREAK for pseudoterminals
This will greatly enhance the usefulness of QEMU virtual serial ports, because
the Linux kernel interprets a break on the serial console as a SysRq, but there
is currently no way to pass this signal over a pseudo-terminal. This patch will
work for transmitting BREAK from master to slave through pseudo-terminal.
Signed-off-by: Nan Li n...@suse.com
---
drivers/tty/pty.c | 19 +++
1 file changed, 19 insertions(+)
diff --git a/drivers/tty/pty.c b/drivers/tty/pty.c
index e72ee62..ac8893a 100644
--- a/drivers/tty/pty.c
+++ b/drivers/tty/pty.c
@@ -31,6 +31,7 @@
static struct tty_driver *ptm_driver;
static struct tty_driver *pts_driver;
static DEFINE_MUTEX(devpts_mutex);
+#define BREAK_STRING '\0'
#endif
static void pty_close(struct tty_struct *tty, struct file *filp)
@@ -674,6 +675,23 @@ static void pty_unix98_shutdown(struct tty_struct *tty)
devpts_kill_index(tty-driver_data, tty-index);
}
+static int pty_unix98_break_ctl(struct tty_struct *tty, int break_state)
+{
+ int c;
+ struct tty_struct *to = tty-link;
+
+ if (break_state) {
+ /* Stuff the break data into the input queue of the other end */
+ c = tty_insert_flip_char(to-port, BREAK_STRING, TTY_BREAK);
+ /* And shovel */
+ if (c)
+ tty_flip_buffer_push(to-port);
+ else
+ return -ENOMEM;
+ }
+ return 0;
+}
+
static const struct tty_operations ptm_unix98_ops = {
.lookup = ptm_unix98_lookup,
.install = pty_unix98_install,
@@ -686,6 +704,7 @@ static const struct tty_operations ptm_unix98_ops = {
.chars_in_buffer = pty_chars_in_buffer,
.unthrottle = pty_unthrottle,
.ioctl = pty_unix98_ioctl,
+ .break_ctl = pty_unix98_break_ctl,
.resize = pty_resize,
.shutdown = pty_unix98_shutdown,
.cleanup = pty_cleanup
--
1.7.12.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/
null pointer dereference error in mtk_timer.c
Hello. My name is Yongbae Park.
I would like to report a possible null pointer dereference error at
mtk_timer_interrupt() in drivers/clocksource/mtk_timer.c (version:
3.19-rc5). The null pointer dereference error occurs if the interrupt
handler mtk_timer_interrupt() accesses evt-dev.event_handler (line
146) when evt-dev.event_handler is null and not defined by
mtk_timer_init().
mtk_timer_init() first registers mtk_timer_interrupt() as the
interrupt handler at line 227, and then defines the clockevent handler
at line 246. As a consequence, the interrupt handler can be executed
before the clockevent handler definition when an interrupt occurs
between line 227 and line 246. The detail error scenario is the
following:
183: static void __init mtk_timer_init(struct device_node *node) {
...
227: if (request_irq(evt-dev.irq, mtk_timer_interrupt,
228: IRQF_TIMER | IRQF_IRQPOLL, mtk_timer, evt)) {
...
-- An interrupt is fired and the interrupt handler is called ---
140: static irqreturn_t mtk_timer_interrupt(int irq, void *dev_id)
141: {
142: struct mtk_clock_event_device *evt = dev_id;
143:
144: /* Acknowledge timer0 irq */
145: writel(GPT_IRQ_ACK(GPT_CLK_EVT), evt-gpt_base + GPT_IRQ_ACK_REG);
146: evt-dev.event_handler(evt-dev); //evt-dev.event_handler
is not defined
147:
148: return IRQ_HANDLED;
149: }
-- The execution of the interrupt handler is finished --
...
246: clockevents_config_and_register(evt-dev, rate, 0x3,
247: 0x);
To resolve the problem, I think that the interrupt handler should be
registered after the clock handler registration.
For your information, I give you the references to similar issues from
the previous bug reports:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6bab4a8a1888729f17f4923cc5867e4674f66333
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=da64c2a8dee66ca03f4f3e15d84be7bedf73db3d
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/
null pointer dereference error in time-efm32.c
Hello. My name is Yongbae Park.
I would like to report a possible null pointer dereference error at
efm32_clock_event_handler() in drivers/clocksource/time-efm32.c
(version: 3.19-rc5). The null pointer dereference error occurs if the
interrupt handler efm32_clock_event_handler() accesses
ddata-evtdev.event_handler (line 106) when
ddata-evtdev.event_handler is null and not defined by
efm32_clockevent_init().
efm32_clockevent_init() first registers efm32_clock_event_handler() as
the interrupt handler at line 228, and then defines the clockevent
handler at line 230. As a consequence, the interrupt handler can be
executed before the clockevent handler definition when an interrupt
occurs between line 228 and line 230. The detail error scenario is the
following:
186: static int __init efm32_clockevent_init(struct device_node *np) {
...
228: setup_irq(irq, efm32_clock_event_irq);
...
-- An interrupt is fired and the interrupt handler is called ---
100: static irqreturn_t efm32_clock_event_handler(int irq, void *dev_id)
101: {
102: struct efm32_clock_event_ddata *ddata = dev_id;
103:
104: writel_relaxed(TIMERn_IRQ_UF, ddata-base + TIMERn_IFC);
105:
106: ddata-evtdev.event_handler(ddata-evtdev); //
ddata-evtdev.event_handler is not defined
107:
108: return IRQ_HANDLED;
109: }
-- The execution of the interrupt handler is finished --
...
230: clockevents_config_and_register(clock_event_ddata.evtdev,
231: DIV_ROUND_CLOSEST(rate, 1024),
232: 0xf, 0x);
To resolve the problem, I think that the interrupt handler should be
registered after the clock handler registration.
For your information, I give you the references to similar issues from
the previous bug reports:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6bab4a8a1888729f17f4923cc5867e4674f66333
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=da64c2a8dee66ca03f4f3e15d84be7bedf73db3d
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/
null pointer dereference error in timer-sun5i.c
Hello. My name is Yongbae Park.
I would like to report a possible null pointer dereference error at
sun5i_timer_interrupt() in drivers/clocksource/timer-sun5i.c (version:
3.19-rc5). The null pointer dereference error occurs if the interrupt
handler sun5i_timer_interrupt() accesses evt-event_handler (line 128)
when evt-event_handler is null and not defined by sun5i_timer_init().
sun5i_timer_init() first registers sun5i_timer_interrupt() as the
interrupt handler at line 181, and then defines the clockevent handler
at line 192. As a consequence, the interrupt handler can be executed
before the clockevent handler definition when an interrupt occurs
between line 181 and line 192. The detail error scenario is the
following:
145: static void __init sun5i_timer_init(struct device_node *node) {
...
181: ret = setup_irq(irq, sun5i_timer_irq);d
...
-- An interrupt is fired and the interrupt handler is called ---
123: static irqreturn_t sun5i_timer_interrupt(int irq, void *dev_id)
124: {
125: struct clock_event_device *evt = (struct clock_event_device *)dev_id;
126:
127: writel(0x1, timer_base + TIMER_IRQ_ST_REG);
128: evt-event_handler(evt); // evt-event_handler is not defined
129:
130: return IRQ_HANDLED;
131: }
-- The execution of the interrupt handler is finished --
...
192: clockevents_config_and_register(sun5i_clockevent, rate,
193: TIMER_SYNC_TICKS, 0x);
To resolve the problem, I think that the interrupt handler should be
registered after the clock handler registration.
For your information, I give you the references to similar issues from
the previous bug reports:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6bab4a8a1888729f17f4923cc5867e4674f66333
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=da64c2a8dee66ca03f4f3e15d84be7bedf73db3d
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/
[PATCH 4/4] f2fs: fix incorrectly stat number of inline data inode
We should stat inline data information for temp file in f2fs_tmpfile if we enable inline_data feature. Otherwise, inline data stat number will be wrong after this temp file is evicted. Signed-off-by: Chao Yu chao2...@samsung.com --- fs/f2fs/namei.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c index e79639a9..1e2ae21 100644 --- a/fs/f2fs/namei.c +++ b/fs/f2fs/namei.c @@ -693,6 +693,8 @@ static int f2fs_tmpfile(struct inode *dir, struct dentry *dentry, umode_t mode) f2fs_unlock_op(sbi); alloc_nid_done(sbi, inode-i_ino); + + stat_inc_inline_inode(inode); d_tmpfile(dentry, inode); unlock_new_inode(inode); return 0; -- 2.2.1 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3] brcmfmac: avoid duplicated suspend/resume operation
On 02/16/15 08:34, Fu, Zhonghui wrote: On 2015/2/15 22:54, Kalle Valo wrote: Arend van Sprielar...@broadcom.com writes: On 02/15/15 04:27, Pat Erley wrote: On 02/14/2015 08:40 PM, Fu, Zhonghui wrote: Any comments to this patch? Can it be accepted? I assume that patches are queued up until after the merge window that we are currently in. That's right. In the future I will most likely apply patches also during the merge window, but as I'm still a greenhorn I'll be on the safe and wait for the merge window to end. I am very glad to see this. Could you please tell which release candidate this patch will be likely merged into now? For which tree are you asking this? When the merge window ends and linus' tree has moved to 3.20-rc1, the wireless-drivers-next will move to that -rc1 as well and pending/accepted patches will be applied for the next kernel release. If you are asking when they will be in linus' tree than the answer is 3.21-rc1. Now if you say this patch solves a real problem for you (providing usual proof like log with stack trace) you can request it to go on the wireless-drivers tree to be fixed for 3.20. Regards, Arend -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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/3] lib/plist: Provide plist_add_head() for nodes with the same prio
From: Xunlei Pang pang.xun...@linaro.org
If there're multiple nodes with the same prio as @node, currently
plist_add() will add @node behind all of them. Now we need to add
@node before all of these nodes for SMP RT scheduler.
This patch adds a common __plist_add() for adding @node before or
behind existing nodes with the same prio, then adds plist_add_head()
and plist_add_tail() inline wrapper functions for convenient uses.
Finally, define plist_add() with plist_add_tail() which has the same
behaviour as before.
Signed-off-by: Xunlei Pang pang.xun...@linaro.org
---
include/linux/plist.h | 30 +-
lib/plist.c | 15 ---
2 files changed, 41 insertions(+), 4 deletions(-)
diff --git a/include/linux/plist.h b/include/linux/plist.h
index 9788360..e17bb96 100644
--- a/include/linux/plist.h
+++ b/include/linux/plist.h
@@ -138,7 +138,35 @@ static inline void plist_node_init(struct plist_node
*node, int prio)
INIT_LIST_HEAD(node-node_list);
}
-extern void plist_add(struct plist_node *node, struct plist_head *head);
+extern void __plist_add(struct plist_node *node,
+ struct plist_head *head, bool is_head);
+
+/**
+ * plist_add_head - add @node to @head, before all existing same-prio nodes
+ *
+ * @node: struct plist_node pointer
+ * @head: struct plist_head pointer
+ */
+static inline
+void plist_add_head(struct plist_node *node, struct plist_head *head)
+{
+ __plist_add(node, head, 1);
+}
+
+/**
+ * plist_add_tail - add @node to @head, after all existing same-prio nodes
+ *
+ * @node: struct plist_node pointer
+ * @head: struct plist_head pointer
+ */
+static inline
+void plist_add_tail(struct plist_node *node, struct plist_head *head)
+{
+ __plist_add(node, head, 0);
+}
+
+#define plist_add plist_add_tail
+
extern void plist_del(struct plist_node *node, struct plist_head *head);
extern void plist_requeue(struct plist_node *node, struct plist_head *head);
diff --git a/lib/plist.c b/lib/plist.c
index d408e77..0e1f1b3 100644
--- a/lib/plist.c
+++ b/lib/plist.c
@@ -67,12 +67,16 @@ static void plist_check_head(struct plist_head *head)
#endif
/**
- * plist_add - add @node to @head
+ * __plist_add - add @node to @head
*
* @node: struct plist_node pointer
* @head: struct plist_head pointer
+ * @is_head: bool
+ *
+ * If there're any nodes with the same prio, add @node
+ * behind or before all of them according to @is_head.
*/
-void plist_add(struct plist_node *node, struct plist_head *head)
+void __plist_add(struct plist_node *node, struct plist_head *head, bool
is_head)
{
struct plist_node *first, *iter, *prev = NULL;
struct list_head *node_next = head-node_list;
@@ -97,8 +101,13 @@ void plist_add(struct plist_node *node, struct plist_head
*head)
struct plist_node, prio_list);
} while (iter != first);
- if (!prev || prev-prio != node-prio)
+ if (!prev || prev-prio != node-prio) {
list_add_tail(node-prio_list, iter-prio_list);
+ } else if (is_head) {
+ list_add(node-prio_list, prev-prio_list);
+ list_del_init(prev-prio_list);
+ node_next = prev-node_list;
+ }
ins_node:
list_add_tail(node-node_list, node_next);
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/3] sched/rt: Fix wrong SMP scheduler behavior for equal prio cases
From: Xunlei Pang pang.xun...@linaro.org
Currently, SMP RT scheduler has some trouble in dealing with
equal prio cases.
For example, in check_preempt_equal_prio():
When RT1(current task) gets preempted by RT2, if there is a
migratable RT3 with same prio, RT3 will be pushed away instead
of RT1 afterwards, because RT1 will be enqueued to the tail of
the pushable list when going through succeeding put_prev_task_rt()
triggered by resched. This broke FIFO.
Furthermore, this is also problematic for normal preempted cases
if there're some rt tasks queued with the same prio as current,
because current will be put behind these tasks in the pushable
queue.
So, if a task is running and gets preempted by a higher priority
task (or even with same priority for migrating), this patch ensures
that it is put before any existing task with the same priority in
the pushable queue.
Signed-off-by: Xunlei Pang pang.xun...@linaro.org
---
kernel/sched/rt.c | 23 ---
1 file changed, 16 insertions(+), 7 deletions(-)
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index f4d4b07..65de40e 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -347,11 +347,15 @@ static inline void set_post_schedule(struct rq *rq)
rq-post_schedule = has_pushable_tasks(rq);
}
-static void enqueue_pushable_task(struct rq *rq, struct task_struct *p)
+static void enqueue_pushable_task(struct rq *rq,
+ struct task_struct *p, bool head)
{
plist_del(p-pushable_tasks, rq-rt.pushable_tasks);
plist_node_init(p-pushable_tasks, p-prio);
- plist_add(p-pushable_tasks, rq-rt.pushable_tasks);
+ if (head)
+ plist_add_head(p-pushable_tasks, rq-rt.pushable_tasks);
+ else
+ plist_add_tail(p-pushable_tasks, rq-rt.pushable_tasks);
/* Update the highest prio pushable task */
if (p-prio rq-rt.highest_prio.next)
@@ -373,7 +377,8 @@ static void dequeue_pushable_task(struct rq *rq, struct
task_struct *p)
#else
-static inline void enqueue_pushable_task(struct rq *rq, struct task_struct *p)
+static inline void enqueue_pushable_task(struct rq *rq,
+ struct task_struct *p, bool head)
{
}
@@ -1248,7 +1253,7 @@ enqueue_task_rt(struct rq *rq, struct task_struct *p, int
flags)
enqueue_rt_entity(rt_se, flags ENQUEUE_HEAD);
if (!task_current(rq, p) p-nr_cpus_allowed 1)
- enqueue_pushable_task(rq, p);
+ enqueue_pushable_task(rq, p, 0);
}
static void dequeue_task_rt(struct rq *rq, struct task_struct *p, int flags)
@@ -1494,8 +1499,12 @@ static void put_prev_task_rt(struct rq *rq, struct
task_struct *p)
* The previous task needs to be made eligible for pushing
* if it is still active
*/
- if (on_rt_rq(p-rt) p-nr_cpus_allowed 1)
- enqueue_pushable_task(rq, p);
+ if (on_rt_rq(p-rt) p-nr_cpus_allowed 1) {
+ if (task_running(rq, p) (preempt_count() PREEMPT_ACTIVE))
+ enqueue_pushable_task(rq, p, 1);
+ else
+ enqueue_pushable_task(rq, p, 0);
+ }
}
#ifdef CONFIG_SMP
@@ -1914,7 +1923,7 @@ static void set_cpus_allowed_rt(struct task_struct *p,
rq-rt.rt_nr_migratory--;
} else {
if (!task_current(rq, p))
- enqueue_pushable_task(rq, p);
+ enqueue_pushable_task(rq, p, 0);
rq-rt.rt_nr_migratory++;
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fs: record task name which froze superblock
On Sat 14-02-15 21:55:24, Alexey Dobriyan wrote:
Freezing and thawing are separate system calls, task which is supposed
to thaw filesystem/superblock can disappear due to crash or not thaw
due to a bug. Record at least task name (we can't take task_struct
reference) to make support engineer's life easier.
Hopefully 16 bytes per superblock isn't much.
P.S.: Cc'ing GFS2 people just in case they want to correct
my understanding of GFS2 having async freeze code.
Signed-off-by: Alexey Dobriyan adobri...@gmail.com
Hum, and when do you show the task name? Or do you expect that customer
takes a crashdump and support just finds it in memory?
---
fs/ioctl.c | 22 --
fs/super.c |2 ++
include/linux/fs.h |2 ++
3 files changed, 20 insertions(+), 6 deletions(-)
--- a/fs/ioctl.c
+++ b/fs/ioctl.c
@@ -518,6 +518,7 @@ static int ioctl_fioasync(unsigned int fd, struct file
*filp,
static int ioctl_fsfreeze(struct file *filp)
{
struct super_block *sb = file_inode(filp)-i_sb;
+ int rv;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
@@ -527,22 +528,31 @@ static int ioctl_fsfreeze(struct file *filp)
return -EOPNOTSUPP;
/* Freeze */
- if (sb-s_op-freeze_super)
- return sb-s_op-freeze_super(sb);
- return freeze_super(sb);
+ if (sb-s_op-freeze_super) {
+ rv = sb-s_op-freeze_super(sb);
+ if (rv == 0)
+ get_task_comm(sb-s_writers.freeze_comm, current);
+ } else
+ rv = freeze_super(sb);
+ return rv;
Why don't you just set the name in ioctl_fsfreeze() in both cases?
Also you seem to be missing freezing / thawing in freeze/thaw_bdev()
functions.
}
static int ioctl_fsthaw(struct file *filp)
{
struct super_block *sb = file_inode(filp)-i_sb;
+ int rv;
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
/* Thaw */
- if (sb-s_op-thaw_super)
- return sb-s_op-thaw_super(sb);
- return thaw_super(sb);
+ if (sb-s_op-thaw_super) {
+ rv = sb-s_op-thaw_super(sb);
+ if (rv == 0)
+ memset(sb-s_writers.freeze_comm, 0, TASK_COMM_LEN);
+ } else
+ rv = thaw_super(sb);
+ return rv;
}
/*
--- a/fs/super.c
+++ b/fs/super.c
@@ -1355,6 +1355,7 @@ int freeze_super(struct super_block *sb)
* sees write activity when frozen is set to SB_FREEZE_COMPLETE.
*/
sb-s_writers.frozen = SB_FREEZE_COMPLETE;
+ get_task_comm(sb-s_writers.freeze_comm, current);
up_write(sb-s_umount);
return 0;
}
@@ -1391,6 +1392,7 @@ int thaw_super(struct super_block *sb)
out:
sb-s_writers.frozen = SB_UNFROZEN;
+ memset(sb-s_writers.freeze_comm, 0, TASK_COMM_LEN);
smp_wmb();
wake_up(sb-s_writers.wait_unfrozen);
deactivate_locked_super(sb);
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1221,6 +1221,8 @@ struct sb_writers {
int frozen; /* Is sb frozen? */
wait_queue_head_t wait_unfrozen; /* queue for waiting for
sb to be thawed */
+ /* who froze superblock */
+ charfreeze_comm[16];
Here should be TASK_COMM_LEN, shouldn't it?
Honza
--
Jan Kara j...@suse.cz
SUSE Labs, CR
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] staging: rtl8192e: remove unnecessary spaces
Removed checkpatch.pl error
ERROR: space prohibited before that ',' (ctx:WxE)
+433, 433, 477} } ,
Signed-off-by: Pushpendra Singh pushpendra.si...@smartplayin.com
---
drivers/staging/rtl8192e/rtl819x_HTProc.c | 4 ++--
drivers/staging/rtl8192e/rtllib_rx.c | 4 ++--
drivers/staging/rtl8192e/rtllib_softmac.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/staging/rtl8192e/rtl819x_HTProc.c
b/drivers/staging/rtl8192e/rtl819x_HTProc.c
index c7f4508..1ea426b 100644
--- a/drivers/staging/rtl8192e/rtl819x_HTProc.c
+++ b/drivers/staging/rtl8192e/rtl819x_HTProc.c
@@ -34,13 +34,13 @@ u16 MCS_DATA_RATE[2][2][77] = {
468, 520, 0, 78, 104, 130, 117, 156, 195, 104, 130, 130, 156, 182,
182, 208, 156, 195, 195, 234, 273, 273, 312, 130, 156, 181, 156,
181, 208, 234, 208, 234, 260, 260, 286, 195, 234, 273, 234, 273,
-312, 351, 312, 351, 390, 390, 429} ,
+312, 351, 312, 351, 390, 390, 429},
{14, 29, 43, 58, 87, 116, 130, 144, 29, 58, 87, 116, 173, 231, 260, 289,
43, 87, 130, 173, 260, 347, 390, 433, 58, 116, 173, 231, 347, 462, 520,
578, 0, 87, 116, 144, 130, 173, 217, 116, 144, 144, 173, 202, 202, 231,
173, 217, 217, 260, 303, 303, 347, 144, 173, 202, 173, 202, 231, 260,
231, 260, 289, 289, 318, 217, 260, 303, 260, 303, 347, 390, 347, 390,
-433, 433, 477} } ,
+433, 433, 477} },
{{27, 54, 81, 108, 162, 216, 243, 270, 54, 108, 162, 216, 324, 432, 486,
540, 81, 162, 243, 324, 486, 648, 729, 810, 108, 216, 324, 432, 648,
864, 972, 1080, 12, 162, 216, 270, 243, 324, 405, 216, 270, 270, 324,
diff --git a/drivers/staging/rtl8192e/rtllib_rx.c
b/drivers/staging/rtl8192e/rtllib_rx.c
index cf11b04..280baf2 100644
--- a/drivers/staging/rtl8192e/rtllib_rx.c
+++ b/drivers/staging/rtl8192e/rtllib_rx.c
@@ -472,7 +472,7 @@ static bool AddReorderEntry(struct rx_ts_record *pTS,
void rtllib_indicate_packets(struct rtllib_device *ieee, struct rtllib_rxb
**prxbIndicateArray, u8 index)
{
struct net_device_stats *stats = ieee-stats;
- u8 i = 0 , j = 0;
+ u8 i = 0, j = 0;
u16 ethertype;
for (j = 0; j index; j++) {
@@ -1211,7 +1211,7 @@ static void rtllib_rx_indicate_pkt_legacy(struct
rtllib_device *ieee,
if (rxb == NULL) {
printk(KERN_INFO %s: rxb is NULL!!\n, __func__);
- return ;
+ return;
}
for (i = 0; i rxb-nr_subframes; i++) {
diff --git a/drivers/staging/rtl8192e/rtllib_softmac.c
b/drivers/staging/rtl8192e/rtllib_softmac.c
index d992a75..6a44a6a 100644
--- a/drivers/staging/rtl8192e/rtllib_softmac.c
+++ b/drivers/staging/rtl8192e/rtllib_softmac.c
@@ -1474,7 +1474,7 @@ static void rtllib_associate_step1(struct rtllib_device
*ieee, u8 *daddr)
if (!skb)
rtllib_associate_abort(ieee);
else {
- ieee-state = RTLLIB_ASSOCIATING_AUTHENTICATING ;
+ ieee-state = RTLLIB_ASSOCIATING_AUTHENTICATING;
RTLLIB_DEBUG_MGMT(Sending authentication request\n);
softmac_mgmt_xmit(skb, ieee);
if (!timer_pending(ieee-associate_timer)) {
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] staging: rtl8192e: added parentheses in macros
Removed checkpatch.pl error
ERROR: Macros with complex values should be enclosed in parentheses
+#define MFIE_STRING(x) case MFIE_TYPE_ ##x: return #x
Signed-off-by: Pushpendra Singh pushpendra.si...@smartplayin.com
---
drivers/staging/rtl8192e/rtllib_rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/rtl8192e/rtllib_rx.c
b/drivers/staging/rtl8192e/rtllib_rx.c
index 280baf2..2917ce8 100644
--- a/drivers/staging/rtl8192e/rtllib_rx.c
+++ b/drivers/staging/rtl8192e/rtllib_rx.c
@@ -1685,7 +1685,7 @@ static int rtllib_parse_qos_info_param_IE(struct
rtllib_info_element
return rc;
}
-#define MFIE_STRING(x) case MFIE_TYPE_ ##x: return #x
+#define MFIE_STRING(x) (case MFIE_TYPE_ ##x: return #x)
static const char *get_info_element_string(u16 id)
{
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 05/16] clk: tegra: Add DFLL DVCO reset control for Tegra124
On Fri, Feb 13, 2015 at 12:39:03PM +0200, Mikko Perttunen wrote: On 02/12/2015 04:19 PM, Peter De Schrijver wrote: On Thu, Jan 08, 2015 at 03:22:08PM +0200, Mikko Perttunen wrote: From: Paul Walmsley pwalms...@nvidia.com The DVCO present in the DFLL IP block has a separate reset line, exposed via the CAR IP block. This reset line is asserted upon SoC reset. Unless something (such as the DFLL driver) deasserts this line, the DVCO will not oscillate, although reads and writes to the DFLL IP block will complete. Thanks to Aleksandr Frid af...@nvidia.com for identifying this and saving hours of debugging time. Should this be done as a reset driver? Probably through the already existing CAR reset driver. This reset doesn't fit well with the existing numbering scheme there, though. Perhaps a magic high-valued constant that represents it. Indeed. Just like only the lower part of the clock IDs map have a realtion with the hardware registers. The rest is just arbitrary numbers. Cheers, Peter. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.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] test-hexdump: test the return value of the hex_dump_to_buffer
On Sun, 2015-02-15 at 09:50 +, Wang Long wrote:
As the function hex_dump_to_buffer returns the amount of bytes placed
in the buffer without terminating NUL. the test-hexdump should test
the return value of it.
I don't think it's needed. When the prototype was changed the new test
case had been introduced to cover the overflow cases, i.e.
test_hexdump_overflow().
Signed-off-by: Wang Long long.wangl...@huawei.com
---
lib/test-hexdump.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/lib/test-hexdump.c b/lib/test-hexdump.c
index daf29a39..9243be7 100644
--- a/lib/test-hexdump.c
+++ b/lib/test-hexdump.c
@@ -52,8 +52,9 @@ static void __init test_hexdump(size_t len, int rowsize,
int groupsize,
size_t l = len;
int gs = groupsize, rs = rowsize;
unsigned int i;
+ int r;
- hex_dump_to_buffer(data_b, l, rs, gs, real, sizeof(real), ascii);
+ r = hex_dump_to_buffer(data_b, l, rs, gs, real, sizeof(real), ascii);
if (rs != 16 rs != 32)
rs = 16;
@@ -96,7 +97,7 @@ static void __init test_hexdump(size_t len, int rowsize,
int groupsize,
*p = '\0';
- if (strcmp(test, real)) {
+ if (strcmp(test, real) || r != strlen(real)) {
pr_err(Len: %zu row: %d group: %d\n, len, rowsize, groupsize);
pr_err(Result: '%s'\n, real);
pr_err(Expect: '%s'\n, test);
--
Andy Shevchenko andriy.shevche...@intel.com
Intel Finland Oy
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.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] staging: nvec: Make nvec_write_sync return result by parameter
Hi Even,
Am Freitag, 13. Februar 2015, 21:28:48 schrieb Evan Hauck:
As outlined in the TODO file, nvec_write_sync was modified to return an
error code instead of NULL on failure, and return the nvec_msg as a
parameter.
Signed-off-by: Evan Hauck echa...@mtu.edu
thanks for looking into this issue! I tested this and saw no issue. You
confused msg and result variables below. Can you re-send with this problem
fixed?
Marc
---
drivers/staging/nvec/TODO | 2 --
drivers/staging/nvec/nvec.c | 37 +
drivers/staging/nvec/nvec.h | 5 +++--
3 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/drivers/staging/nvec/TODO b/drivers/staging/nvec/TODO
index e5ae42a..e4d85d9 100644
--- a/drivers/staging/nvec/TODO
+++ b/drivers/staging/nvec/TODO
@@ -3,6 +3,4 @@ ToDo list (incomplete, unordered)
- move half of the nvec init stuff to i2c-tegra.c
- move event handling to nvec_events
- finish suspend/resume support
- - modifiy the sync_write method to return the received
- message in a variable (and return the error code).
- add support for more device implementations
diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 120b70d..47ef013 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -288,46 +288,53 @@ EXPORT_SYMBOL(nvec_write_async);
* @nvec: An struct nvec_chip
* @data: The data to write
* @size: The size of @data
+ * @result: The resulting message
s/result/msg/ (or vise versa)
*
* This is similar to nvec_write_async(), but waits for the
* request to be answered before returning. This function
* uses a mutex and can thus not be called from e.g.
* interrupt handlers.
*
- * Returns: A pointer to the response message on success,
+ * Returns in *result: A pointer to the response message on success,
* %NULL on failure. Free with nvec_msg_free() once no longer
* used.
+ *
+ * Returns: 0 on success, a negative error code on failure. If a failure
+ * occurred, the nvec driver may print an error.
*/
-struct nvec_msg *nvec_write_sync(struct nvec_chip *nvec,
- const unsigned char *data, short size)
+int nvec_write_sync(struct nvec_chip *nvec,
+ const unsigned char *data, short size,
+ struct nvec_msg **msg)
{
- struct nvec_msg *msg;
+ int err;
mutex_lock(nvec-sync_write_mutex);
nvec-sync_write_pending = (data[1] 8) + data[0];
- if (nvec_write_async(nvec, data, size) 0) {
+ err = nvec_write_async(nvec, data, size);
+ if (err 0) {
mutex_unlock(nvec-sync_write_mutex);
- return NULL;
+ return err;
}
dev_dbg(nvec-dev, nvec_sync_write: 0x%04x\n,
nvec-sync_write_pending);
- if (!(wait_for_completion_timeout(nvec-sync_write,
- msecs_to_jiffies(2000 {
+ err = wait_for_completion_timeout(nvec-sync_write,
+ msecs_to_jiffies(2000));
+ if (!err) {
dev_warn(nvec-dev, timeout waiting for sync write to
complete\n);
mutex_unlock(nvec-sync_write_mutex);
- return NULL;
+ return err;
}
dev_dbg(nvec-dev, nvec_sync_write: pong!\n);
- msg = nvec-last_sync_msg;
+ *msg = nvec-last_sync_msg;
mutex_unlock(nvec-sync_write_mutex);
- return msg;
+ return 0;
}
EXPORT_SYMBOL(nvec_write_sync);
@@ -879,9 +886,7 @@ static int tegra_nvec_probe(struct platform_device
*pdev) pm_power_off = nvec_power_off;
/* Get Firmware Version */
- msg = nvec_write_sync(nvec, get_firmware_version, 2);
-
- if (msg) {
+ if (!nvec_write_sync(nvec, get_firmware_version, 2, msg)) {
dev_warn(nvec-dev, ec firmware version %02x.%02x.%02x /
%02x\n,
msg-data[4], msg-data[5], msg-data[6], msg-data[7]);
@@ -935,8 +940,8 @@ static int nvec_suspend(struct device *dev)
/* keep these sync or you'll break suspend */
nvec_toggle_global_events(nvec, false);
- msg = nvec_write_sync(nvec, ap_suspend, sizeof(ap_suspend));
- nvec_msg_free(nvec, msg);
+ if (!nvec_write_sync(nvec, ap_suspend, sizeof(ap_suspend), msg))
+ nvec_msg_free(nvec, msg);
nvec_disable_i2c_slave(nvec);
diff --git a/drivers/staging/nvec/nvec.h b/drivers/staging/nvec/nvec.h
index e271375..00d099a 100644
--- a/drivers/staging/nvec/nvec.h
+++ b/drivers/staging/nvec/nvec.h
@@ -168,8 +168,9 @@ struct nvec_chip {
extern int nvec_write_async(struct nvec_chip *nvec, const unsigned char
*data, short size);
-extern struct nvec_msg *nvec_write_sync(struct nvec_chip *nvec,
- const unsigned char *data, short size);
+extern int nvec_write_sync(struct nvec_chip *nvec,
+const unsigned
Re: [PATCH v2 6/6] irqchip: gicv3: skip ITS init when no ITS available
Hi Yun,
On 15/02/15 09:32, Yun Wu wrote:
There is one more condition that needs to be considered when judging
whether LPI feature is enabled or not, which is whether there is any
ITS available and correctly enabled.
This patch will fix this by caching ITS enabling status in the GIC
chip data structure.
I posted patch for that before [1] and it landed in Marc's tree
(irq/gic-fixes). It is not clear from the commit message what the one
more condition is, but I guess it is the same dts stuff. Do you see
issue without your patch applied?
[1]
http://lists.infradead.org/pipermail/linux-arm-kernel/2015-January/314752.html
Thanks
Vladimir
Signed-off-by: Yun Wu wuyun...@huawei.com
---
drivers/irqchip/irq-gic-v3.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/irqchip/irq-gic-v3.c b/drivers/irqchip/irq-gic-v3.c
index 1a146cc..e17faca 100644
--- a/drivers/irqchip/irq-gic-v3.c
+++ b/drivers/irqchip/irq-gic-v3.c
@@ -47,6 +47,7 @@ struct gic_chip_data {
u64 redist_stride;
u32 nr_redist_regions;
unsigned intirq_nr;
+ int lpi_enabled;
};
static struct gic_chip_data gic_data __read_mostly;
@@ -390,11 +391,6 @@ static void gic_cpu_sys_reg_init(void)
gic_write_grpen1(1);
}
-static int gic_dist_supports_lpis(void)
-{
- return !!(readl_relaxed(gic_data.dist_base + GICD_TYPER)
GICD_TYPER_LPIS);
-}
-
static void gic_cpu_init(void)
{
void __iomem *rbase;
@@ -410,7 +406,7 @@ static void gic_cpu_init(void)
gic_cpu_config(rbase, gic_redist_wait_for_rwp);
/* Give LPIs a spin */
- if (IS_ENABLED(CONFIG_ARM_GIC_V3_ITS) gic_dist_supports_lpis())
+ if (gic_data.lpi_enabled)
its_cpu_init();
/* initialise system registers */
@@ -629,7 +625,7 @@ static int gic_irq_domain_map(struct irq_domain *d,
unsigned int irq,
}
/* LPIs */
if (hw = 8192 hw GIC_ID_NR) {
- if (!gic_dist_supports_lpis())
+ if (!gic_data.lpi_enabled)
return -EPERM;
irq_domain_set_info(d, irq, hw, gic_chip, d-host_data,
handle_fasteoi_irq, NULL, NULL);
@@ -785,8 +781,12 @@ static int __init gic_of_init(struct device_node *node,
struct device_node *pare
set_handle_irq(gic_handle_irq);
- if (IS_ENABLED(CONFIG_ARM_GIC_V3_ITS) gic_dist_supports_lpis())
- its_init(node, gic_data.rdists, gic_data.domain);
+ if (IS_ENABLED(CONFIG_ARM_GIC_V3_ITS)
+ !!(readl_relaxed(dist_base + GICD_TYPER) GICD_TYPER_LPIS)
+ !its_init(node, gic_data.rdists, gic_data.domain))
+ gic_data.lpi_enabled = 1;
+ else
+ gic_data.lpi_enabled = 0;
gic_smp_init();
gic_dist_init();
--
1.8.0
___
linux-arm-kernel mailing list
linux-arm-ker...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@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 21/28] powerpc/iommu: Split iommu_free_table into 2 helpers
The iommu_free_table helper release memory it is using (the TCE table and
@it_map) and release the iommu_table struct as well. We might not want
the very last step as we store iommu_table in parent structures.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/include/asm/iommu.h | 1 +
arch/powerpc/kernel/iommu.c | 57
2 files changed, 35 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index bf26d47..cc26eca 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -122,6 +122,7 @@ static inline void *get_iommu_table_base(struct device *dev)
extern struct iommu_table *iommu_table_alloc(int node);
/* Frees table for an individual device node */
+extern void iommu_reset_table(struct iommu_table *tbl, const char *node_name);
extern void iommu_free_table(struct iommu_table *tbl, const char *node_name);
/* Initializes an iommu_table based in values set in the passed-in
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index e4b89bf..c0d05ec 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -721,24 +721,46 @@ struct iommu_table *iommu_table_alloc(int node)
return iommu-tables[0];
}
+void iommu_reset_table(struct iommu_table *tbl, const char *node_name)
+{
+ if (!tbl)
+ return;
+
+ if (tbl-it_map) {
+ unsigned long bitmap_sz;
+ unsigned int order;
+
+ /*
+* In case we have reserved the first bit, we should not emit
+* the warning below.
+*/
+ if (tbl-it_offset == 0)
+ clear_bit(0, tbl-it_map);
+
+ /* verify that table contains no entries */
+ if (!bitmap_empty(tbl-it_map, tbl-it_size))
+ pr_warn(%s: Unexpected TCEs for %s\n, __func__,
+ node_name);
+
+ /* calculate bitmap size in bytes */
+ bitmap_sz = BITS_TO_LONGS(tbl-it_size) * sizeof(unsigned long);
+
+ /* free bitmap */
+ order = get_order(bitmap_sz);
+ free_pages((unsigned long) tbl-it_map, order);
+ }
+
+ memset(tbl, 0, sizeof(*tbl));
+}
+
void iommu_free_table(struct iommu_table *tbl, const char *node_name)
{
- unsigned long bitmap_sz;
- unsigned int order;
struct powerpc_iommu *iommu = tbl-it_iommu;
- if (!tbl || !tbl-it_map) {
- printk(KERN_ERR %s: expected TCE map for %s\n, __func__,
- node_name);
+ if (!tbl)
return;
- }
- /*
-* In case we have reserved the first bit, we should not emit
-* the warning below.
-*/
- if (tbl-it_offset == 0)
- clear_bit(0, tbl-it_map);
+ iommu_reset_table(tbl, node_name);
#ifdef CONFIG_IOMMU_API
if (iommu-group) {
@@ -747,17 +769,6 @@ void iommu_free_table(struct iommu_table *tbl, const char
*node_name)
}
#endif
- /* verify that table contains no entries */
- if (!bitmap_empty(tbl-it_map, tbl-it_size))
- pr_warn(%s: Unexpected TCEs for %s\n, __func__, node_name);
-
- /* calculate bitmap size in bytes */
- bitmap_sz = BITS_TO_LONGS(tbl-it_size) * sizeof(unsigned long);
-
- /* free bitmap */
- order = get_order(bitmap_sz);
- free_pages((unsigned long) tbl-it_map, order);
-
/* free table */
kfree(iommu);
}
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 26/28] vfio: powerpc/spapr: Rework an IOMMU group attach/detach
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
drivers/vfio/vfio_iommu_spapr_tce.c | 62 +++--
1 file changed, 38 insertions(+), 24 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c
b/drivers/vfio/vfio_iommu_spapr_tce.c
index fdcc04c..4ff8289 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -435,7 +435,7 @@ static void tce_iommu_release(void *iommu_data)
iommu = iommu_group_get_iommudata(container-grp);
tbl = iommu-tables[0];
tce_iommu_clear(container, tbl, tbl-it_offset, tbl-it_size);
-
+ iommu-ops-free_table(tbl);
tce_iommu_detach_group(iommu_data, container-grp);
}
@@ -796,6 +796,7 @@ static int tce_iommu_attach_group(void *iommu_data,
int ret = 0;
struct tce_container *container = iommu_data;
struct powerpc_iommu *iommu;
+ struct iommu_table tbltmp = { 0 }, *tbl = tbltmp;
mutex_lock(container-lock);
@@ -806,35 +807,44 @@ static int tce_iommu_attach_group(void *iommu_data,
iommu_group_id(container-grp),
iommu_group_id(iommu_group));
ret = -EBUSY;
- } else if (container-enabled) {
+ goto unlock_exit;
+ }
+
+ if (container-enabled) {
pr_err(tce_vfio: attaching group #%u to enabled container\n,
iommu_group_id(iommu_group));
ret = -EBUSY;
+ goto unlock_exit;
+ }
+
+ iommu = iommu_group_get_iommudata(iommu_group);
+ if (WARN_ON_ONCE(!iommu)) {
+ ret = -ENXIO;
+ goto unlock_exit;
+ }
+
+ /*
+* Disable iommu bypass, otherwise the user can DMA to all of
+* our physical memory via the bypass window instead of just
+* the pages that has been explicitly mapped into the iommu
+*/
+ if (iommu-ops iommu-ops-set_ownership) {
+ iommu-ops-set_ownership(iommu, true);
} else {
- iommu = iommu_group_get_iommudata(iommu_group);
- if (WARN_ON_ONCE(!iommu)) {
- ret = -ENXIO;
- } else if (iommu-ops iommu-ops-set_ownership) {
- /*
-* Disable iommu bypass, otherwise the user can DMA to
all of
-* our physical memory via the bypass window instead of
just
-* the pages that has been explicitly mapped into the
iommu
-*/
- struct iommu_table tbltmp = { 0 }, *tbl = tbltmp;
-
- iommu-ops-set_ownership(iommu, true);
- container-grp = iommu_group;
-
- ret = iommu-ops-create_table(iommu, 0,
- IOMMU_PAGE_SHIFT_4K,
- ilog2(iommu-tce32_size), 1, tbl);
- if (!ret)
- ret = iommu-ops-set_window(iommu, 0, tbl);
- } else {
- ret = -ENODEV;
- }
+ ret = -ENODEV;
+ goto unlock_exit;
}
+ container-grp = iommu_group;
+
+ /* Create the default window as only now we know the parameters */
+ ret = iommu-ops-create_table(iommu, 0,
+ IOMMU_PAGE_SHIFT_4K,
+ ilog2(iommu-tce32_size), 1, tbl);
+ if (!ret)
+ ret = iommu-ops-set_window(iommu, 0, tbl);
+
+unlock_exit:
mutex_unlock(container-lock);
return ret;
@@ -845,6 +855,7 @@ static void tce_iommu_detach_group(void *iommu_data,
{
struct tce_container *container = iommu_data;
struct powerpc_iommu *iommu;
+ long i;
mutex_lock(container-lock);
if (iommu_group != container-grp) {
@@ -865,6 +876,9 @@ static void tce_iommu_detach_group(void *iommu_data,
iommu = iommu_group_get_iommudata(iommu_group);
BUG_ON(!iommu);
+ for (i = 0; i POWERPC_IOMMU_MAX_TABLES; ++i)
+ iommu-ops-unset_window(iommu, i);
+
/* Kernel owns the device now, we can restore bypass */
if (iommu-ops iommu-ops-set_ownership)
iommu-ops-set_ownership(iommu, false);
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 23/28] powerpc/powernv: Change prototypes to receive iommu
This changes few functions to receive a powerpc_iommu pointer
rather than PE as they are going to be a part of upcoming
powerpc_iommu_ops callback set.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/platforms/powernv/pci-ioda.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index f542819..29bd7a4 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1360,10 +1360,12 @@ static __be64 *pnv_alloc_tce_table(int nid,
return addr;
}
-static long pnv_pci_ioda2_create_table(struct pnv_ioda_pe *pe,
+static long pnv_pci_ioda2_create_table(struct powerpc_iommu *iommu,
__u32 page_shift, __u32 window_shift, __u32 levels,
struct iommu_table *tbl)
{
+ struct pnv_ioda_pe *pe = container_of(iommu, struct pnv_ioda_pe,
+ iommu);
int nid = pe-phb-hose-node;
void *addr;
unsigned long tce_table_size, left;
@@ -1419,9 +1421,11 @@ static void pnv_pci_ioda2_free_table(struct iommu_table
*tbl)
iommu_reset_table(tbl, ioda2);
}
-static long pnv_pci_ioda2_set_window(struct pnv_ioda_pe *pe,
+static long pnv_pci_ioda2_set_window(struct powerpc_iommu *iommu,
struct iommu_table *tbl)
{
+ struct pnv_ioda_pe *pe = container_of(iommu, struct pnv_ioda_pe,
+ iommu);
struct pnv_phb *phb = pe-phb;
const __be64 *swinvp;
int64_t rc;
@@ -1554,12 +1558,11 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb
*phb,
/* The PE will reserve all possible 32-bits space */
pe-tce32_seg = 0;
-
end = (1 ilog2(phb-ioda.m32_pci_base));
pe_info(pe, Setting up 32-bit TCE table at 0..%08x\n,
end);
- rc = pnv_pci_ioda2_create_table(pe, IOMMU_PAGE_SHIFT_4K,
+ rc = pnv_pci_ioda2_create_table(pe-iommu, IOMMU_PAGE_SHIFT_4K,
ilog2(phb-ioda.m32_pci_base),
POWERPC_IOMMU_DEFAULT_LEVELS, tbl);
if (rc) {
@@ -1571,7 +1574,7 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb
*phb,
pe-iommu.tables[0].it_iommu = pe-iommu;
pe-iommu.ops = pnv_pci_ioda2_ops;
- rc = pnv_pci_ioda2_set_window(pe, tbl);
+ rc = pnv_pci_ioda2_set_window(pe-iommu, tbl);
if (rc) {
pe_err(pe, Failed to configure 32-bit TCE table,
err %ld\n, rc);
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 07/28] vfio: powerpc/spapr: Moving pinning/unpinning to helpers
This is a pretty mechanical patch to make next patches simpler.
New tce_iommu_unuse_page() helper does put_page() now but it might skip
that after the memory registering patch applied.
As we are here, this removes unnecessary checks for a value returned
by pfn_to_page() as it cannot possibly return NULL.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
drivers/vfio/vfio_iommu_spapr_tce.c | 59 +++--
1 file changed, 44 insertions(+), 15 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c
b/drivers/vfio/vfio_iommu_spapr_tce.c
index 67ea392..7fd60f9 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -217,25 +217,34 @@ static void tce_iommu_release(void *iommu_data)
kfree(container);
}
+static void tce_iommu_unuse_page(struct tce_container *container,
+ unsigned long oldtce)
+{
+ struct page *page;
+
+ if (!(oldtce (TCE_PCI_READ | TCE_PCI_WRITE)))
+ return;
+
+ page = pfn_to_page(__pa(oldtce) PAGE_SHIFT);
+
+ if (oldtce TCE_PCI_WRITE)
+ SetPageDirty(page);
+
+ put_page(page);
+}
+
static int tce_iommu_clear(struct tce_container *container,
struct iommu_table *tbl,
unsigned long entry, unsigned long pages)
{
unsigned long oldtce;
- struct page *page;
for ( ; pages; --pages, ++entry) {
oldtce = iommu_clear_tce(tbl, entry);
if (!oldtce)
continue;
- page = pfn_to_page(oldtce PAGE_SHIFT);
- WARN_ON(!page);
- if (page) {
- if (oldtce TCE_PCI_WRITE)
- SetPageDirty(page);
- put_page(page);
- }
+ tce_iommu_unuse_page(container, (unsigned long) __va(oldtce));
}
return 0;
@@ -253,34 +262,54 @@ static enum dma_data_direction
tce_iommu_direction(unsigned long tce)
return DMA_NONE;
}
+static unsigned long tce_get_hva(struct tce_container *container,
+ unsigned page_shift, unsigned long tce)
+{
+ long ret;
+ struct page *page = NULL;
+ unsigned long hva;
+ enum dma_data_direction direction = tce_iommu_direction(tce);
+
+ ret = get_user_pages_fast(tce PAGE_MASK, 1,
+ direction != DMA_TO_DEVICE, page);
+ if (unlikely(ret != 1))
+ return -1;
+
+ hva = (unsigned long) page_address(page);
+
+ return hva;
+}
+
static long tce_iommu_build(struct tce_container *container,
struct iommu_table *tbl,
unsigned long entry, unsigned long tce, unsigned long pages)
{
long i, ret = 0;
- struct page *page = NULL;
+ struct page *page;
unsigned long hva;
enum dma_data_direction direction = tce_iommu_direction(tce);
for (i = 0; i pages; ++i) {
- ret = get_user_pages_fast(tce PAGE_MASK, 1,
- direction != DMA_TO_DEVICE, page);
- if (unlikely(ret != 1)) {
+ hva = tce_get_hva(container, tbl-it_page_shift, tce);
+ if (hva == -1) {
ret = -EFAULT;
break;
}
+ page = pfn_to_page(__pa(hva) PAGE_SHIFT);
if (!tce_page_is_contained(page, tbl-it_page_shift)) {
ret = -EPERM;
break;
}
- hva = (unsigned long) page_address(page) +
- (tce IOMMU_PAGE_MASK(tbl) ~PAGE_MASK);
+ /* Preserve offset within IOMMU page */
+ hva |= tce IOMMU_PAGE_MASK(tbl) ~PAGE_MASK;
+ /* Preserve permission bits */
+ hva |= tce (TCE_PCI_READ | TCE_PCI_WRITE);
ret = iommu_tce_build(tbl, entry + i, hva, direction);
if (ret) {
- put_page(page);
+ tce_iommu_unuse_page(container, hva);
pr_err(iommu_tce: %s failed ioba=%lx, tce=%lx,
ret=%ld\n,
__func__, entry tbl-it_page_shift,
tce, ret);
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 24/28] powerpc/powernv/ioda: Define and implement DMA table/window management callbacks
This extends powerpc_iommu_ops by a set of callbacks to support dynamic
DMA windows management.
query() returns IOMMU capabilities such as default DMA window address and
supported number of DMA windows and TCE table levels.
create_table() creates a TCE table with specific parameters. For now
it receives powerpc_iommu to know nodeid in order to allocate TCE table
memory closer to the PHB. The exact format of allocated multi-level table
might be also specific to the PHB model (not the case now though).
set_window() sets the window at specified TVT index on PHB.
unset_window() unsets the window from specified TVT.
free_table() frees the memory occupied by a table.
The purpose of this separation is that we need to be able to create
one table and assign it to a set of PHB. This way we can support multiple
IOMMU groups in one VFIO container and make use of VFIO on SPAPR closer
to the way it works on x86.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/include/asm/iommu.h | 31 +
arch/powerpc/platforms/powernv/pci-ioda.c | 75 +--
2 files changed, 92 insertions(+), 14 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index 283f70f..8393822 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -147,12 +147,43 @@ struct powerpc_iommu_ops {
*/
void (*set_ownership)(struct powerpc_iommu *iommu,
bool enable);
+
+ long (*create_table)(struct powerpc_iommu *iommu,
+ int num,
+ __u32 page_shift,
+ __u32 window_shift,
+ __u32 levels,
+ struct iommu_table *tbl);
+ long (*set_window)(struct powerpc_iommu *iommu,
+ int num,
+ struct iommu_table *tblnew);
+ long (*unset_window)(struct powerpc_iommu *iommu,
+ int num);
+ void (*free_table)(struct iommu_table *tbl);
};
+/* Page size flags for ibm,query-pe-dma-window */
+#define DDW_PGSIZE_4K 0x01
+#define DDW_PGSIZE_64K 0x02
+#define DDW_PGSIZE_16M 0x04
+#define DDW_PGSIZE_32M 0x08
+#define DDW_PGSIZE_64M 0x10
+#define DDW_PGSIZE_128M 0x20
+#define DDW_PGSIZE_256M 0x40
+#define DDW_PGSIZE_16G 0x80
+#define DDW_PGSIZE_MASK 0xFF
+
struct powerpc_iommu {
#ifdef CONFIG_IOMMU_API
struct iommu_group *group;
#endif
+ /* Some key properties of IOMMU */
+ __u32 tce32_start;
+ __u32 tce32_size;
+ __u32 windows_supported;
+ __u32 levels;
+ __u32 flags;
+
struct iommu_table tables[POWERPC_IOMMU_MAX_TABLES];
struct powerpc_iommu_ops *ops;
};
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 29bd7a4..16ddaba 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1360,7 +1360,7 @@ static __be64 *pnv_alloc_tce_table(int nid,
return addr;
}
-static long pnv_pci_ioda2_create_table(struct powerpc_iommu *iommu,
+static long pnv_pci_ioda2_create_table(struct powerpc_iommu *iommu, int num,
__u32 page_shift, __u32 window_shift, __u32 levels,
struct iommu_table *tbl)
{
@@ -1388,8 +1388,8 @@ static long pnv_pci_ioda2_create_table(struct
powerpc_iommu *iommu,
shift = ROUND_UP(window_shift - page_shift, levels) / levels;
shift += 3;
shift = max_t(unsigned, shift, IOMMU_PAGE_SHIFT_4K);
- pr_info(Creating TCE table %08llx, %d levels, TCE table size = %lx\n,
- 1ULL window_shift, levels, 1UL shift);
+ pr_info(Creating TCE table #%d %08llx, %d levels, TCE table size =
%lx\n,
+ num, 1ULL window_shift, levels, 1UL shift);
tbl-it_level_size = 1ULL (shift - 3);
left = tce_table_size;
@@ -1400,11 +1400,10 @@ static long pnv_pci_ioda2_create_table(struct
powerpc_iommu *iommu,
tbl-it_indirect_levels = levels - 1;
/* Setup linux iommu table */
- pnv_pci_setup_iommu_table(tbl, addr, tce_table_size, 0,
- page_shift);
+ pnv_pci_setup_iommu_table(tbl, addr, tce_table_size,
+ num ? pe-tce_bypass_base : 0, page_shift);
tbl-it_ops = pnv_ioda2_iommu_ops;
- iommu_init_table(tbl, nid);
return 0;
}
@@ -1421,8 +1420,21 @@ static void pnv_pci_ioda2_free_table(struct iommu_table
*tbl)
iommu_reset_table(tbl, ioda2);
}
+static inline void pnv_pci_ioda2_tvt_invalidate(unsigned int pe_number,
+ unsigned long it_index)
+{
+ __be64 __iomem *invalidate = (__be64 __iomem *)it_index;
+ /* 01xb - invalidate TCEs that match the specified PE# */
+ unsigned long addr = (0x4ull 60) | (pe_number 0xFF);
+
+ if
[PATCH v4 20/28] powerpc/powernv/ioda2: Introduce pnv_pci_ioda2_set_window
This is a part of moving DMA window programming to an iommu_ops
callback.
This is a mechanical patch.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/platforms/powernv/pci-ioda.c | 84 ---
1 file changed, 56 insertions(+), 28 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index 95d9119..1f725d4 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1351,6 +1351,57 @@ static void pnv_pci_ioda2_free_table(struct iommu_table
*tbl)
memset(tbl, 0, sizeof(struct iommu_table));
}
+static long pnv_pci_ioda2_set_window(struct pnv_ioda_pe *pe,
+ struct iommu_table *tbl)
+{
+ struct pnv_phb *phb = pe-phb;
+ const __be64 *swinvp;
+ int64_t rc;
+ const __u64 start_addr = tbl-it_offset tbl-it_page_shift;
+ const __u64 win_size = tbl-it_size tbl-it_page_shift;
+
+ pe_info(pe, Setting up window at %llx..%llx pagesize=0x%x
tablesize=0x%lx\n,
+ start_addr, start_addr + win_size - 1,
+ 1UL tbl-it_page_shift, tbl-it_size 3);
+
+ pe-iommu.tables[0] = *tbl;
+ tbl = pe-iommu.tables[0];
+ tbl-it_iommu = pe-iommu;
+
+ /*
+* Map TCE table through TVT. The TVE index is the PE number
+* shifted by 1 bit for 32-bits DMA space.
+*/
+ rc = opal_pci_map_pe_dma_window(phb-opal_id, pe-pe_number,
+ pe-pe_number 1, 1, __pa(tbl-it_base),
+ tbl-it_size 3, 1ULL tbl-it_page_shift);
+ if (rc) {
+ pe_err(pe, Failed to configure TCE table, err %ld\n, rc);
+ goto fail;
+ }
+
+ /* OPAL variant of PHB3 invalidated TCEs */
+ swinvp = of_get_property(phb-hose-dn, ibm,opal-tce-kill, NULL);
+ if (swinvp) {
+ /* We need a couple more fields -- an address and a data
+* to or. Since the bus is only printed out on table free
+* errors, and on the first pass the data will be a relative
+* bus number, print that out instead.
+*/
+ pe-tce_inval_reg_phys = be64_to_cpup(swinvp);
+ tbl-it_index = (unsigned long)ioremap(pe-tce_inval_reg_phys,
+ 8);
+ tbl-it_type |= (TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE);
+ }
+
+ return 0;
+fail:
+ if (pe-tce32_seg = 0)
+ pe-tce32_seg = -1;
+
+ return rc;
+}
+
static void pnv_pci_ioda2_set_bypass(struct pnv_ioda_pe *pe, bool enable)
{
uint16_t window_id = (pe-pe_number 1 ) + 1;
@@ -1421,7 +1472,6 @@ static struct powerpc_iommu_ops pnv_pci_ioda2_ops = {
static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb,
struct pnv_ioda_pe *pe)
{
- const __be64 *swinvp;
unsigned int end;
struct iommu_table *tbl = pe-iommu.tables[0];
int64_t rc;
@@ -1448,31 +1498,14 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb
*phb,
pe-iommu.tables[0].it_iommu = pe-iommu;
pe-iommu.ops = pnv_pci_ioda2_ops;
- /*
-* Map TCE table through TVT. The TVE index is the PE number
-* shifted by 1 bit for 32-bits DMA space.
-*/
- rc = opal_pci_map_pe_dma_window(phb-opal_id, pe-pe_number,
- pe-pe_number 1, 1, __pa(tbl-it_base),
- tbl-it_size 3, 1ULL tbl-it_page_shift);
+ rc = pnv_pci_ioda2_set_window(pe, tbl);
if (rc) {
pe_err(pe, Failed to configure 32-bit TCE table,
err %ld\n, rc);
- goto fail;
- }
-
- /* OPAL variant of PHB3 invalidated TCEs */
- swinvp = of_get_property(phb-hose-dn, ibm,opal-tce-kill, NULL);
- if (swinvp) {
- /* We need a couple more fields -- an address and a data
-* to or. Since the bus is only printed out on table free
-* errors, and on the first pass the data will be a relative
-* bus number, print that out instead.
-*/
- pe-tce_inval_reg_phys = be64_to_cpup(swinvp);
- tbl-it_index = (unsigned long)ioremap(pe-tce_inval_reg_phys,
- 8);
- tbl-it_type |= (TCE_PCI_SWINV_CREATE | TCE_PCI_SWINV_FREE);
+ pnv_pci_ioda2_free_table(tbl);
+ if (pe-tce32_seg = 0)
+ pe-tce32_seg = -1;
+ return;
}
iommu_register_group(pe-iommu, phb-hose-global_number,
@@ -1486,11 +1519,6 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb
*phb,
/* Also create a bypass window */
pnv_pci_ioda2_setup_bypass_pe(phb, pe);
- return;
-fail:
- if (pe-tce32_seg = 0)
- pe-tce32_seg = -1;
-
[PATCH v4 12/28] powerpc/spapr: vfio: Switch from iommu_table to new powerpc_iommu
Modern IBM POWERPC systems support multiple (currently two) TCE tables
per IOMMU group (a.k.a. PE). This adds a powerpc_iommu container
for TCE tables. Right now just one table is supported.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/include/asm/iommu.h| 18 +++--
arch/powerpc/kernel/eeh.c | 2 +-
arch/powerpc/kernel/iommu.c | 34
arch/powerpc/platforms/powernv/pci-ioda.c | 37 +
arch/powerpc/platforms/powernv/pci-p5ioc2.c | 16 ++--
arch/powerpc/platforms/powernv/pci.c| 2 +-
arch/powerpc/platforms/powernv/pci.h| 4 +-
arch/powerpc/platforms/pseries/iommu.c | 9 ++-
drivers/vfio/vfio_iommu_spapr_tce.c | 117 +++-
9 files changed, 156 insertions(+), 83 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index 335e3d4..4fe 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -90,9 +90,7 @@ struct iommu_table {
struct iommu_pool pools[IOMMU_NR_POOLS];
unsigned long *it_map; /* A simple allocation bitmap for now */
unsigned long it_page_shift;/* table iommu page size */
-#ifdef CONFIG_IOMMU_API
- struct iommu_group *it_group;
-#endif
+ struct powerpc_iommu *it_iommu;
struct iommu_table_ops *it_ops;
void (*set_bypass)(struct iommu_table *tbl, bool enable);
};
@@ -126,13 +124,23 @@ extern void iommu_free_table(struct iommu_table *tbl,
const char *node_name);
*/
extern struct iommu_table *iommu_init_table(struct iommu_table * tbl,
int nid);
+
+#define POWERPC_IOMMU_MAX_TABLES 1
+
+struct powerpc_iommu {
#ifdef CONFIG_IOMMU_API
-extern void iommu_register_group(struct iommu_table *tbl,
+ struct iommu_group *group;
+#endif
+ struct iommu_table tables[POWERPC_IOMMU_MAX_TABLES];
+};
+
+#ifdef CONFIG_IOMMU_API
+extern void iommu_register_group(struct powerpc_iommu *iommu,
int pci_domain_number, unsigned long pe_num);
extern int iommu_add_device(struct device *dev);
extern void iommu_del_device(struct device *dev);
#else
-static inline void iommu_register_group(struct iommu_table *tbl,
+static inline void iommu_register_group(struct powerpc_iommu *iommu,
int pci_domain_number,
unsigned long pe_num)
{
diff --git a/arch/powerpc/kernel/eeh.c b/arch/powerpc/kernel/eeh.c
index e1b6d8e..319eae3 100644
--- a/arch/powerpc/kernel/eeh.c
+++ b/arch/powerpc/kernel/eeh.c
@@ -1360,7 +1360,7 @@ static int dev_has_iommu_table(struct device *dev, void
*data)
return 0;
tbl = get_iommu_table_base(dev);
- if (tbl tbl-it_group) {
+ if (tbl tbl-it_iommu) {
*ppdev = pdev;
return 1;
}
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 2f7e92b..952939f 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -712,17 +712,20 @@ struct iommu_table *iommu_init_table(struct iommu_table
*tbl, int nid)
struct iommu_table *iommu_table_alloc(int node)
{
- struct iommu_table *tbl;
+ struct powerpc_iommu *iommu;
- tbl = kzalloc_node(sizeof(struct iommu_table), GFP_KERNEL, node);
+ iommu = kzalloc_node(sizeof(struct powerpc_iommu), GFP_KERNEL,
+ node);
+ iommu-tables[0].it_iommu = iommu;
- return tbl;
+ return iommu-tables[0];
}
void iommu_free_table(struct iommu_table *tbl, const char *node_name)
{
unsigned long bitmap_sz;
unsigned int order;
+ struct powerpc_iommu *iommu = tbl-it_iommu;
if (!tbl || !tbl-it_map) {
printk(KERN_ERR %s: expected TCE map for %s\n, __func__,
@@ -738,9 +741,9 @@ void iommu_free_table(struct iommu_table *tbl, const char
*node_name)
clear_bit(0, tbl-it_map);
#ifdef CONFIG_IOMMU_API
- if (tbl-it_group) {
- iommu_group_put(tbl-it_group);
- BUG_ON(tbl-it_group);
+ if (iommu-group) {
+ iommu_group_put(iommu-group);
+ BUG_ON(iommu-group);
}
#endif
@@ -756,7 +759,7 @@ void iommu_free_table(struct iommu_table *tbl, const char
*node_name)
free_pages((unsigned long) tbl-it_map, order);
/* free table */
- kfree(tbl);
+ kfree(iommu);
}
/* Creates TCEs for a user provided buffer. The user buffer must be
@@ -888,11 +891,12 @@ void iommu_free_coherent(struct iommu_table *tbl, size_t
size,
*/
static void group_release(void *iommu_data)
{
- struct iommu_table *tbl = iommu_data;
- tbl-it_group = NULL;
+ struct powerpc_iommu *iommu = iommu_data;
+
+ iommu-group = NULL;
}
-void iommu_register_group(struct iommu_table *tbl,
+void
[PATCH v4 19/28] powerpc/powernv/ioda2: Introduce pnv_pci_ioda2_create_table
This is a part of moving TCE table allocation into an iommu_ops
callback to support multiple IOMMU groups per one VFIO container.
This is a mechanical patch.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/platforms/powernv/pci-ioda.c | 88 +++
1 file changed, 65 insertions(+), 23 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index ebfea0a..95d9119 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1295,6 +1295,62 @@ static void pnv_pci_ioda_setup_dma_pe(struct pnv_phb
*phb,
__free_pages(tce_mem, get_order(TCE32_TABLE_SIZE * segs));
}
+static long pnv_pci_ioda2_create_table(struct pnv_ioda_pe *pe,
+ __u32 page_shift, __u32 window_shift,
+ struct iommu_table *tbl)
+{
+ int nid = pe-phb-hose-node;
+ struct page *tce_mem = NULL;
+ void *addr;
+ unsigned long tce_table_size;
+ int64_t rc;
+ unsigned order;
+
+ if ((page_shift != 12) (page_shift != 16) (page_shift != 24))
+ return -EINVAL;
+
+ if ((1ULL window_shift) memory_hotplug_max())
+ return -EINVAL;
+
+ tce_table_size = (1ULL (window_shift - page_shift)) * 8;
+ tce_table_size = max(0x1000UL, tce_table_size);
+
+ /* Allocate TCE table */
+ order = get_order(tce_table_size);
+
+ tce_mem = alloc_pages_node(nid, GFP_KERNEL, order);
+ if (!tce_mem) {
+ pr_err(Failed to allocate a TCE memory, order=%d\n, order);
+ rc = -ENOMEM;
+ goto fail;
+ }
+ addr = page_address(tce_mem);
+ memset(addr, 0, tce_table_size);
+
+ /* Setup linux iommu table */
+ pnv_pci_setup_iommu_table(tbl, addr, tce_table_size, 0,
+ page_shift);
+
+ tbl-it_ops = pnv_ioda2_iommu_ops;
+ iommu_init_table(tbl, nid);
+
+ return 0;
+fail:
+ if (tce_mem)
+ __free_pages(tce_mem, get_order(tce_table_size));
+
+ return rc;
+}
+
+static void pnv_pci_ioda2_free_table(struct iommu_table *tbl)
+{
+ if (!tbl-it_size)
+ return;
+
+ free_pages(tbl-it_base, get_order(tbl-it_size 3));
+ memset(tbl, 0, sizeof(struct iommu_table));
+}
+
static void pnv_pci_ioda2_set_bypass(struct pnv_ioda_pe *pe, bool enable)
{
uint16_t window_id = (pe-pe_number 1 ) + 1;
@@ -1365,11 +1421,9 @@ static struct powerpc_iommu_ops pnv_pci_ioda2_ops = {
static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb *phb,
struct pnv_ioda_pe *pe)
{
- struct page *tce_mem = NULL;
- void *addr;
const __be64 *swinvp;
- struct iommu_table *tbl;
- unsigned int tce_table_size, end;
+ unsigned int end;
+ struct iommu_table *tbl = pe-iommu.tables[0];
int64_t rc;
/* We shouldn't already have a 32-bit DMA associated */
@@ -1378,31 +1432,20 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb
*phb,
/* The PE will reserve all possible 32-bits space */
pe-tce32_seg = 0;
+
end = (1 ilog2(phb-ioda.m32_pci_base));
- tce_table_size = (end / 0x1000) * 8;
pe_info(pe, Setting up 32-bit TCE table at 0..%08x\n,
end);
- /* Allocate TCE table */
- tce_mem = alloc_pages_node(phb-hose-node, GFP_KERNEL,
- get_order(tce_table_size));
- if (!tce_mem) {
- pe_err(pe, Failed to allocate a 32-bit TCE memory\n);
- goto fail;
+ rc = pnv_pci_ioda2_create_table(pe, IOMMU_PAGE_SHIFT_4K,
+ ilog2(phb-ioda.m32_pci_base), tbl);
+ if (rc) {
+ pe_err(pe, Failed to create 32-bit TCE table, err %ld, rc);
+ return;
}
- addr = page_address(tce_mem);
- memset(addr, 0, tce_table_size);
/* Setup iommu */
pe-iommu.tables[0].it_iommu = pe-iommu;
-
- /* Setup linux iommu table */
- tbl = pe-iommu.tables[0];
- pnv_pci_setup_iommu_table(tbl, addr, tce_table_size, 0,
- IOMMU_PAGE_SHIFT_4K);
-
- tbl-it_ops = pnv_ioda2_iommu_ops;
- iommu_init_table(tbl, phb-hose-node);
pe-iommu.ops = pnv_pci_ioda2_ops;
/*
@@ -1447,8 +1490,7 @@ static void pnv_pci_ioda2_setup_dma_pe(struct pnv_phb
*phb,
fail:
if (pe-tce32_seg = 0)
pe-tce32_seg = -1;
- if (tce_mem)
- __free_pages(tce_mem, get_order(tce_table_size));
+ pnv_pci_ioda2_free_table(tbl);
}
static void pnv_ioda_setup_dma(struct pnv_phb *phb)
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
[PATCH v4 28/28] vfio: powerpc/spapr: Support Dynamic DMA windows
This adds create/remove window ioctls to create and remove DMA windows.
sPAPR defines a Dynamic DMA windows capability which allows
para-virtualized guests to create additional DMA windows on a PCI bus.
The existing linux kernels use this new window to map the entire guest
memory and switch to the direct DMA operations saving time on map/unmap
requests which would normally happen in a big amounts.
This adds 2 ioctl handlers - VFIO_IOMMU_SPAPR_TCE_CREATE and
VFIO_IOMMU_SPAPR_TCE_REMOVE - to create and remove windows.
Up to 2 windows are supported now by the hardware and by this driver.
This changes VFIO_IOMMU_SPAPR_TCE_GET_INFO handler to return additional
information such as a number of supported windows and maximum number
levels of TCE tables.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v4:
* moved code to tce_iommu_create_window()/tce_iommu_remove_window()
helpers
* added docs
---
Documentation/vfio.txt | 6 ++
arch/powerpc/include/asm/iommu.h| 2 +-
drivers/vfio/vfio_iommu_spapr_tce.c | 156 +++-
include/uapi/linux/vfio.h | 24 +-
4 files changed, 185 insertions(+), 3 deletions(-)
diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
index 791e85c..11628f1 100644
--- a/Documentation/vfio.txt
+++ b/Documentation/vfio.txt
@@ -446,6 +446,12 @@ the memory block.
The user space is not expected to call these often and the block descriptors
are stored in a linked list in the kernel.
+6) sPAPR specification allows guests to have an ddditional DMA window(s) on
+a PCI bus with a variable page size. Two ioctls have been added to support
+this: VFIO_IOMMU_SPAPR_TCE_CREATE and VFIO_IOMMU_SPAPR_TCE_REMOVE.
+The platform has to support the functionality or error will be returned to
+the userspace.
+
---
[1] VFIO was originally an acronym for Virtual Function I/O in its
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index 8393822..6f34b82 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -133,7 +133,7 @@ extern void iommu_free_table(struct iommu_table *tbl, const
char *node_name);
extern struct iommu_table *iommu_init_table(struct iommu_table * tbl,
int nid);
-#define POWERPC_IOMMU_MAX_TABLES 1
+#define POWERPC_IOMMU_MAX_TABLES 2
#define POWERPC_IOMMU_DEFAULT_LEVELS 1
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c
b/drivers/vfio/vfio_iommu_spapr_tce.c
index ee91d51..d5de7c6 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -333,6 +333,20 @@ static struct iommu_table *spapr_tce_find_table(
return ret;
}
+static int spapr_tce_find_free_table(struct tce_container *container)
+{
+ int i;
+
+ for (i = 0; i POWERPC_IOMMU_MAX_TABLES; ++i) {
+ struct iommu_table *tbl = container-tables[i];
+
+ if (!tbl-it_size)
+ return i;
+ }
+
+ return -1;
+}
+
static int tce_iommu_enable(struct tce_container *container)
{
int ret = 0;
@@ -620,11 +634,85 @@ static long tce_iommu_build(struct tce_container
*container,
return ret;
}
+static long tce_iommu_create_window(struct tce_container *container,
+ __u32 page_shift, __u32 window_shift, __u32 levels,
+ __u64 *start_addr)
+{
+ struct powerpc_iommu *iommu;
+ struct tce_iommu_group *tcegrp;
+ int num;
+ long ret;
+
+ num = spapr_tce_find_free_table(container);
+ if (num 0)
+ return -ENOSYS;
+
+ tcegrp = list_first_entry(container-group_list,
+ struct tce_iommu_group, next);
+ iommu = iommu_group_get_iommudata(tcegrp-grp);
+
+ ret = iommu-ops-create_table(iommu, num,
+ page_shift, window_shift, levels,
+ container-tables[num]);
+ if (ret)
+ return ret;
+
+ list_for_each_entry(tcegrp, container-group_list, next) {
+ struct powerpc_iommu *iommutmp =
+ iommu_group_get_iommudata(tcegrp-grp);
+
+ if (WARN_ON_ONCE(iommutmp-ops != iommu-ops))
+ return -EFAULT;
+
+ ret = iommu-ops-set_window(iommutmp, num,
+ container-tables[num]);
+ if (ret)
+ return ret;
+ }
+
+ *start_addr = container-tables[num].it_offset
+ container-tables[num].it_page_shift;
+
+ return 0;
+}
+
+static long tce_iommu_remove_window(struct tce_container *container,
+ __u64 start_addr)
+{
+ struct powerpc_iommu *iommu = NULL;
+ struct iommu_table *tbl;
+ struct tce_iommu_group *tcegrp;
+ int num;
+
+ tbl = spapr_tce_find_table(container, start_addr);
+
[PATCH v4 08/28] vfio: powerpc/spapr: Register memory
The existing implementation accounts the whole DMA window in
the locked_vm counter which is going to be even worse with multiple
containers and huge DMA windows.
This introduces 2 ioctls to register/unregister DMA memory which
receive user space address and size of a memory region which
needs to be pinned/unpinned and counted in locked_vm.
If any memory region was registered, all subsequent DMA map requests
should address already pinned memory. If no memory was registered,
then the amount of memory required for a single default memory will be
accounted when the container is enabled and every map/unmap will pin/unpin
a page (with degraded performance).
Dynamic DMA window and in-kernel acceleration will require memory to
be preregistered in order to work.
The accounting is done per VFIO container. When the support of
multiple groups per container is added, we will have accurate locked_vm
accounting.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v4:
* updated docs
* s/kzmalloc/vzalloc/
* in tce_pin_pages()/tce_unpin_pages() removed @vaddr, @size and
replaced offset with index
* renamed vfio_iommu_type_register_memory to vfio_iommu_spapr_register_memory
and removed duplicating vfio_iommu_spapr_register_memory
---
Documentation/vfio.txt | 19 +++
drivers/vfio/vfio_iommu_spapr_tce.c | 274 +++-
include/uapi/linux/vfio.h | 25
3 files changed, 312 insertions(+), 6 deletions(-)
diff --git a/Documentation/vfio.txt b/Documentation/vfio.txt
index 96978ec..791e85c 100644
--- a/Documentation/vfio.txt
+++ b/Documentation/vfio.txt
@@ -427,6 +427,25 @@ The code flow from the example above should be slightly
changed:
+5) PPC64 paravirtualized guests may generate a lot of map/unmap requests,
+and the handling of those includes pinning/unpinning pages and updating
+mm::locked_vm counter to make sure we do not exceed the rlimit. Handling these
+in real-mode is quite expensive and may fail. In order to simplify in-kernel
+acceleration of map/unmap requests, two ioctls have been added to pre-register
+and unregister guest RAM pages where DMA can possibly happen to. Having these
+calles, the userspace and in-kernel handlers do not have to take care of
+pinning or accounting.
+
+The ioctls are VFIO_IOMMU_SPAPR_REGISTER_MEMORY and
+VFIO_IOMMU_SPAPR_UNREGISTER_MEMORY.
+These receive a user space address and size of the block to be pinned.
+Bisecting is not supported and VFIO_IOMMU_UNREGISTER_MEMORY is expected to
+be called with the exact address and size used for registering
+the memory block.
+
+The user space is not expected to call these often and the block descriptors
+are stored in a linked list in the kernel.
+
---
[1] VFIO was originally an acronym for Virtual Function I/O in its
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c
b/drivers/vfio/vfio_iommu_spapr_tce.c
index 7fd60f9..9b884e0 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -21,6 +21,7 @@
#include linux/uaccess.h
#include linux/err.h
#include linux/vfio.h
+#include linux/vmalloc.h
#include asm/iommu.h
#include asm/tce.h
@@ -93,8 +94,196 @@ struct tce_container {
struct iommu_table *tbl;
bool enabled;
unsigned long locked_pages;
+ struct list_head mem_list;
};
+struct tce_memory {
+ struct list_head next;
+ struct rcu_head rcu;
+ __u64 vaddr;
+ __u64 size;
+ __u64 hpas[];
+};
+
+static inline bool tce_preregistered(struct tce_container *container)
+{
+ return !list_empty(container-mem_list);
+}
+
+static struct tce_memory *tce_mem_alloc(struct tce_container *container,
+ __u64 vaddr, __u64 size)
+{
+ struct tce_memory *mem;
+ long ret;
+
+ ret = try_increment_locked_vm(size PAGE_SHIFT);
+ if (ret)
+ return NULL;
+
+ mem = vzalloc(sizeof(*mem) + (size (PAGE_SHIFT - 3)));
+ if (!mem) {
+ decrement_locked_vm(size PAGE_SHIFT);
+ return NULL;
+ }
+
+ mem-vaddr = vaddr;
+ mem-size = size;
+
+ list_add_rcu(mem-next, container-mem_list);
+
+ return mem;
+}
+
+static void release_tce_memory(struct rcu_head *head)
+{
+ struct tce_memory *mem = container_of(head, struct tce_memory, rcu);
+
+ vfree(mem);
+}
+
+static void tce_mem_free(struct tce_memory *mem)
+{
+ decrement_locked_vm(mem-size);
+ list_del_rcu(mem-next);
+ call_rcu(mem-rcu, release_tce_memory);
+}
+
+static struct tce_memory *tce_pinned_desc(struct tce_container *container,
+ __u64 vaddr, __u64 size)
+{
+ struct tce_memory *mem, *ret = NULL;
+
+ rcu_read_lock();
+ vaddr = ~(TCE_PCI_READ | TCE_PCI_WRITE);
+ list_for_each_entry_rcu(mem, container-mem_list, next) {
+ if ((mem-vaddr = vaddr)
+
[PATCH v4 15/28] powerpc/powernv/ioda/ioda2: Rework tce_build()/tce_free()
The pnv_pci_ioda_tce_invalidate() helper invalidates TCE cache. It is
supposed to be called on IODA1/2 and not called on p5ioc2. It receives
start and end host addresses of TCE table. This approach makes it possible
to get pnv_pci_ioda_tce_invalidate() unintentionally called on p5ioc2.
Another issue is that IODA2 needs PCI addresses to invalidate the cache
and those can be calculated from host addresses but since we are going
to implement multi-level TCE tables, calculating PCI address from
a host address might get either tricky or ugly as TCE table remains flat
on PCI bus but not in RAM.
This defines separate iommu_table_ops callbacks for p5ioc2 and IODA1/2
PHBs. They all call common pnv_tce_build/pnv_tce_free/pnv_tce_get helpers
but call PHB specific TCE invalidation helper (when needed).
This changes pnv_pci_ioda2_tce_invalidate() to receives TCE index and
number of pages which are PCI addresses shifted by IOMMU page shift.
The patch is pretty mechanical and behaviour is not expected to change.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/platforms/powernv/pci-ioda.c | 92 ++---
arch/powerpc/platforms/powernv/pci-p5ioc2.c | 8 ++-
arch/powerpc/platforms/powernv/pci.c| 76 +---
arch/powerpc/platforms/powernv/pci.h| 7 ++-
4 files changed, 110 insertions(+), 73 deletions(-)
diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c
b/arch/powerpc/platforms/powernv/pci-ioda.c
index a33a116..dfc56fc 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -1041,18 +1041,20 @@ static void pnv_ioda_setup_bus_dma(struct pnv_ioda_pe
*pe,
}
}
-static void pnv_pci_ioda1_tce_invalidate(struct pnv_ioda_pe *pe,
-struct iommu_table *tbl,
-__be64 *startp, __be64 *endp, bool rm)
+static void pnv_pci_ioda1_tce_invalidate(struct iommu_table *tbl,
+ unsigned long index, unsigned long npages, bool rm)
{
+ struct pnv_ioda_pe *pe = container_of(tbl-it_iommu,
+ struct pnv_ioda_pe, iommu);
__be64 __iomem *invalidate = rm ?
(__be64 __iomem *)pe-tce_inval_reg_phys :
(__be64 __iomem *)tbl-it_index;
unsigned long start, end, inc;
const unsigned shift = tbl-it_page_shift;
- start = __pa(startp);
- end = __pa(endp);
+ start = __pa((__be64 *)tbl-it_base + index - tbl-it_offset);
+ end = __pa((__be64 *)tbl-it_base + index - tbl-it_offset +
+ npages - 1);
/* BML uses this case for p6/p7/galaxy2: Shift addr and put in node */
if (tbl-it_busno) {
@@ -1088,10 +1090,40 @@ static void pnv_pci_ioda1_tce_invalidate(struct
pnv_ioda_pe *pe,
*/
}
-static void pnv_pci_ioda2_tce_invalidate(struct pnv_ioda_pe *pe,
-struct iommu_table *tbl,
-__be64 *startp, __be64 *endp, bool rm)
+static int pnv_ioda1_tce_build_vm(struct iommu_table *tbl, long index,
+ long npages, unsigned long uaddr,
+ enum dma_data_direction direction,
+ struct dma_attrs *attrs)
{
+ long ret = pnv_tce_build(tbl, index, npages, uaddr, direction,
+ attrs);
+
+ if (!ret (tbl-it_type TCE_PCI_SWINV_CREATE))
+ pnv_pci_ioda1_tce_invalidate(tbl, index, npages, false);
+
+ return ret;
+}
+
+static void pnv_ioda1_tce_free_vm(struct iommu_table *tbl, long index,
+ long npages)
+{
+ pnv_tce_free(tbl, index, npages);
+
+ if (tbl-it_type TCE_PCI_SWINV_FREE)
+ pnv_pci_ioda1_tce_invalidate(tbl, index, npages, false);
+}
+
+struct iommu_table_ops pnv_ioda1_iommu_ops = {
+ .set = pnv_ioda1_tce_build_vm,
+ .clear = pnv_ioda1_tce_free_vm,
+ .get = pnv_tce_get,
+};
+
+static void pnv_pci_ioda2_tce_invalidate(struct iommu_table *tbl,
+ unsigned long index, unsigned long npages, bool rm)
+{
+ struct pnv_ioda_pe *pe = container_of(tbl-it_iommu,
+ struct pnv_ioda_pe, iommu);
unsigned long start, end, inc;
__be64 __iomem *invalidate = rm ?
(__be64 __iomem *)pe-tce_inval_reg_phys :
@@ -1104,9 +1136,9 @@ static void pnv_pci_ioda2_tce_invalidate(struct
pnv_ioda_pe *pe,
end = start;
/* Figure out the start, end and step */
- inc = tbl-it_offset + (((u64)startp - tbl-it_base) / sizeof(u64));
+ inc = tbl-it_offset + index / sizeof(u64);
start |= (inc shift);
- inc = tbl-it_offset + (((u64)endp - tbl-it_base) / sizeof(u64));
+ inc = tbl-it_offset + (index + npages - 1) / sizeof(u64);
end |= (inc shift);
inc = (0x1ull shift);
mb();
@@ -1120,19 +1152,35 @@ static void pnv_pci_ioda2_tce_invalidate(struct
pnv_ioda_pe *pe,
[PATCH v4 00/28] powerpc/iommu/vfio: Enable Dynamic DMA windows
This enables PAPR defined feature called Dynamic DMA windows (DDW). Each Partitionable Endpoint (IOMMU group) has a separate DMA window on a PCI bus where devices are allows to perform DMA. By default there is 1 or 2GB window allocated at the host boot time and these windows are used when an IOMMU group is passed to the userspace (guest). These windows are mapped at zero offset on a PCI bus. Hi-speed devices may suffer from limited size of this window. On the host side a TCE bypass mode is enabled on POWER8 CPU which implements direct mapping of the host memory to a PCI bus at 159. For the guest, PAPR defines a DDW RTAS API which allows the pseries guest to query the hypervisor if it supports DDW and what are the parameters of possible windows. Currently POWER8 supports 2 DMA windows per PE - already mentioned and used small 32bit window and 64bit window which can only start from 159 and can support various page sizes. This patchset reworks PPC IOMMU code and adds necessary structures to extend it to support big windows. When the guest detectes the feature and the PE is capable of 64bit DMA, it does: 1. query to hypervisor about number of available windows and page masks; 2. creates a window with the biggest possible page size (current guests can do 64K or 16MB TCEs); 3. maps the entire guest RAM via H_PUT_TCE* hypercalls 4. switches dma_ops to direct_dma_ops on the selected PE. Once this is done, H_PUT_TCE is not called anymore and the guest gets maximum performance. Changes: v4: * moved patches around to have VFIO and PPC patches separated as much as possible; once I get Ack from any PPC maintainer about the whole approach, I'll start posting these in small chunks per maintainer * now works with the existing upstream QEMU v3: * redesigned the whole thing * multiple IOMMU groups per PHB - one PHB is needed for VFIO in the guest - no problems with locked_vm counting; also we save memory on actual tables * guest RAM preregistration is required for DDW * PEs (IOMMU groups) are passed to VFIO with no DMA windows at all so we do not bother with iommu_table::it_map anymore * added multilevel TCE tables support to support really huge guests v2: * added missing __pa() in powerpc/powernv: Release replaced TCE * reposted to make some noise Alexey Kardashevskiy (28): vfio: powerpc/spapr: Move page pinning from arch code to VFIO IOMMU driver vfio: powerpc/spapr: Do cleanup when releasing the group vfio: powerpc/spapr: Check that TCE page size is equal to it_page_size vfio: powerpc/spapr: Use it_page_size vfio: powerpc/spapr: Move locked_vm accounting to helpers vfio: powerpc/spapr: Disable DMA mappings on disabled container vfio: powerpc/spapr: Moving pinning/unpinning to helpers vfio: powerpc/spapr: Register memory powerpc/powernv: Do not set read flag if direction==DMA_NONE powerpc/iommu: Move tce_xxx callbacks from ppc_md to iommu_table powerpc/iommu: Introduce iommu_table_alloc() helper powerpc/spapr: vfio: Switch from iommu_table to new powerpc_iommu powerpc/iommu: Fix IOMMU ownership control functions vfio: powerpc/spapr: powerpc/powernv/ioda2: Rework IOMMU ownership control powerpc/powernv/ioda/ioda2: Rework tce_build()/tce_free() powerpc/iommu/powernv: Release replaced TCE powerpc/pseries/lpar: Enable VFIO poweppc/powernv/ioda2: Rework iommu_table creation powerpc/powernv/ioda2: Introduce pnv_pci_ioda2_create_table powerpc/powernv/ioda2: Introduce pnv_pci_ioda2_set_window powerpc/iommu: Split iommu_free_table into 2 helpers powerpc/powernv: Implement multilevel TCE tables powerpc/powernv: Change prototypes to receive iommu powerpc/powernv/ioda: Define and implement DMA table/window management callbacks vfio: powerpc/spapr: powerpc/powernv/ioda2: Rework ownership vfio: powerpc/spapr: Rework an IOMMU group attach/detach vfio: powerpc/spapr: Register memory vfio: powerpc/spapr: Support Dynamic DMA windows Documentation/vfio.txt | 25 + arch/powerpc/include/asm/iommu.h| 109 +++- arch/powerpc/include/asm/machdep.h | 25 - arch/powerpc/kernel/eeh.c | 2 +- arch/powerpc/kernel/iommu.c | 322 +- arch/powerpc/kernel/vio.c | 5 + arch/powerpc/platforms/cell/iommu.c | 8 +- arch/powerpc/platforms/pasemi/iommu.c | 7 +- arch/powerpc/platforms/powernv/pci-ioda.c | 473 +++--- arch/powerpc/platforms/powernv/pci-p5ioc2.c | 21 +- arch/powerpc/platforms/powernv/pci.c| 130 ++-- arch/powerpc/platforms/powernv/pci.h| 14 +- arch/powerpc/platforms/pseries/iommu.c | 99 ++- arch/powerpc/sysdev/dart_iommu.c| 12 +- drivers/vfio/vfio_iommu_spapr_tce.c | 944 +--- include/uapi/linux/vfio.h | 49 +- 16 files changed, 1756 insertions(+), 489 deletions(-) -- 2.0.0 -- To unsubscribe from this list: send the line unsubscribe
[PATCH v4 02/28] vfio: powerpc/spapr: Do cleanup when releasing the group
This clears the TCE table when a container is being closed as this is
a good thing to leave the table clean before passing the ownership
back to the host kernel.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
drivers/vfio/vfio_iommu_spapr_tce.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c
b/drivers/vfio/vfio_iommu_spapr_tce.c
index 1ef46c3..daf2e2c 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -134,16 +134,24 @@ static void *tce_iommu_open(unsigned long arg)
return container;
}
+static int tce_iommu_clear(struct tce_container *container,
+ struct iommu_table *tbl,
+ unsigned long entry, unsigned long pages);
+
static void tce_iommu_release(void *iommu_data)
{
struct tce_container *container = iommu_data;
+ struct iommu_table *tbl = container-tbl;
- WARN_ON(container-tbl !container-tbl-it_group);
+ WARN_ON(tbl !tbl-it_group);
tce_iommu_disable(container);
- if (container-tbl container-tbl-it_group)
- tce_iommu_detach_group(iommu_data, container-tbl-it_group);
+ if (tbl) {
+ tce_iommu_clear(container, tbl, tbl-it_offset, tbl-it_size);
+ if (tbl-it_group)
+ tce_iommu_detach_group(iommu_data, tbl-it_group);
+ }
mutex_destroy(container-lock);
kfree(container);
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 11/28] powerpc/iommu: Introduce iommu_table_alloc() helper
This replaces multiple calls of kzalloc_node() with a new
iommu_table_alloc() helper. Right now it calls kzalloc_node() but
later it will be modified to allocate a powerpc_iommu struct with
a single iommu_table in it.
Later the helper will allocate a powerpc_iommu struct which embeds
the iommu table(s).
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
arch/powerpc/include/asm/iommu.h | 1 +
arch/powerpc/kernel/iommu.c| 9 +
arch/powerpc/platforms/powernv/pci.c | 2 +-
arch/powerpc/platforms/pseries/iommu.c | 12
4 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/arch/powerpc/include/asm/iommu.h b/arch/powerpc/include/asm/iommu.h
index eb5822d..335e3d4 100644
--- a/arch/powerpc/include/asm/iommu.h
+++ b/arch/powerpc/include/asm/iommu.h
@@ -117,6 +117,7 @@ static inline void *get_iommu_table_base(struct device *dev)
return dev-archdata.dma_data.iommu_table_base;
}
+extern struct iommu_table *iommu_table_alloc(int node);
/* Frees table for an individual device node */
extern void iommu_free_table(struct iommu_table *tbl, const char *node_name);
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index c51ad3e..2f7e92b 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -710,6 +710,15 @@ struct iommu_table *iommu_init_table(struct iommu_table
*tbl, int nid)
return tbl;
}
+struct iommu_table *iommu_table_alloc(int node)
+{
+ struct iommu_table *tbl;
+
+ tbl = kzalloc_node(sizeof(struct iommu_table), GFP_KERNEL, node);
+
+ return tbl;
+}
+
void iommu_free_table(struct iommu_table *tbl, const char *node_name)
{
unsigned long bitmap_sz;
diff --git a/arch/powerpc/platforms/powernv/pci.c
b/arch/powerpc/platforms/powernv/pci.c
index c4782b1..bbe529b 100644
--- a/arch/powerpc/platforms/powernv/pci.c
+++ b/arch/powerpc/platforms/powernv/pci.c
@@ -693,7 +693,7 @@ static struct iommu_table *pnv_pci_setup_bml_iommu(struct
pci_controller *hose)
hose-dn-full_name);
return NULL;
}
- tbl = kzalloc_node(sizeof(struct iommu_table), GFP_KERNEL, hose-node);
+ tbl = iommu_table_alloc(hose-node);
if (WARN_ON(!tbl))
return NULL;
pnv_pci_setup_iommu_table(tbl, __va(be64_to_cpup(basep)),
diff --git a/arch/powerpc/platforms/pseries/iommu.c
b/arch/powerpc/platforms/pseries/iommu.c
index 1aa1815..bc14299 100644
--- a/arch/powerpc/platforms/pseries/iommu.c
+++ b/arch/powerpc/platforms/pseries/iommu.c
@@ -617,8 +617,7 @@ static void pci_dma_bus_setup_pSeries(struct pci_bus *bus)
pci-phb-dma_window_size = 0x800ul;
pci-phb-dma_window_base_cur = 0x800ul;
- tbl = kzalloc_node(sizeof(struct iommu_table), GFP_KERNEL,
- pci-phb-node);
+ tbl = iommu_table_alloc(pci-phb-node);
iommu_table_setparms(pci-phb, dn, tbl);
tbl-it_ops = iommu_table_pseries_ops;
@@ -669,8 +668,7 @@ static void pci_dma_bus_setup_pSeriesLP(struct pci_bus *bus)
pdn-full_name, ppci-iommu_table);
if (!ppci-iommu_table) {
- tbl = kzalloc_node(sizeof(struct iommu_table), GFP_KERNEL,
- ppci-phb-node);
+ tbl = iommu_table_alloc(ppci-phb-node);
iommu_table_setparms_lpar(ppci-phb, pdn, tbl, dma_window);
tbl-it_ops = iommu_table_lpar_multi_ops;
ppci-iommu_table = iommu_init_table(tbl, ppci-phb-node);
@@ -697,8 +695,7 @@ static void pci_dma_dev_setup_pSeries(struct pci_dev *dev)
struct pci_controller *phb = PCI_DN(dn)-phb;
pr_debug( -- first child, no bridge. Allocating iommu
table.\n);
- tbl = kzalloc_node(sizeof(struct iommu_table), GFP_KERNEL,
- phb-node);
+ tbl = iommu_table_alloc(phb-node);
iommu_table_setparms(phb, dn, tbl);
tbl-it_ops = iommu_table_pseries_ops;
PCI_DN(dn)-iommu_table = iommu_init_table(tbl, phb-node);
@@ -1120,8 +1117,7 @@ static void pci_dma_dev_setup_pSeriesLP(struct pci_dev
*dev)
pci = PCI_DN(pdn);
if (!pci-iommu_table) {
- tbl = kzalloc_node(sizeof(struct iommu_table), GFP_KERNEL,
- pci-phb-node);
+ tbl = iommu_table_alloc(pci-phb-node);
iommu_table_setparms_lpar(pci-phb, pdn, tbl, dma_window);
tbl-it_ops = iommu_table_lpar_multi_ops;
pci-iommu_table = iommu_init_table(tbl, pci-phb-node);
--
2.0.0
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 05/28] vfio: powerpc/spapr: Move locked_vm accounting to helpers
There moves locked pages accounting to helpers.
Later they will be reused for Dynamic DMA windows (DDW).
This reworks debug messages to show the current value and the limit.
This stores the locked pages number in the container so when unlocking
the iommu table pointer won't be needed. This does not have an effect
now but it will with the multiple tables per container as then we will
allow attaching/detaching groups on fly and we may end up having
a container with no group attached but with the counter incremented.
While we are here, update the comment explaining why RLIMIT_MEMLOCK
might be required to be bigger than the guest RAM. This also prints
pid of the current process in pr_warn/pr_debug.
Signed-off-by: Alexey Kardashevskiy a...@ozlabs.ru
---
Changes:
v4:
* new helpers do nothing if @npages == 0
* tce_iommu_disable() now can decrement the counter if the group was
detached (not possible now but will be in the future)
---
drivers/vfio/vfio_iommu_spapr_tce.c | 82 -
1 file changed, 63 insertions(+), 19 deletions(-)
diff --git a/drivers/vfio/vfio_iommu_spapr_tce.c
b/drivers/vfio/vfio_iommu_spapr_tce.c
index c2ca38f..2beeae5 100644
--- a/drivers/vfio/vfio_iommu_spapr_tce.c
+++ b/drivers/vfio/vfio_iommu_spapr_tce.c
@@ -31,6 +31,51 @@
static void tce_iommu_detach_group(void *iommu_data,
struct iommu_group *iommu_group);
+static long try_increment_locked_vm(long npages)
+{
+ long ret = 0, locked, lock_limit;
+
+ if (!current || !current-mm)
+ return -ESRCH; /* process exited */
+
+ if (!npages)
+ return 0;
+
+ down_write(current-mm-mmap_sem);
+ locked = current-mm-locked_vm + npages;
+ lock_limit = rlimit(RLIMIT_MEMLOCK) PAGE_SHIFT;
+ if (locked lock_limit !capable(CAP_IPC_LOCK))
+ ret = -ENOMEM;
+ else
+ current-mm-locked_vm += npages;
+
+ pr_debug([%d] RLIMIT_MEMLOCK +%ld %ld/%ld%s\n, current-pid,
+ npages PAGE_SHIFT,
+ current-mm-locked_vm PAGE_SHIFT,
+ rlimit(RLIMIT_MEMLOCK),
+ ret ? - exceeded : );
+
+ up_write(current-mm-mmap_sem);
+
+ return ret;
+}
+
+static void decrement_locked_vm(long npages)
+{
+ if (!current || !current-mm || !npages)
+ return; /* process exited */
+
+ down_write(current-mm-mmap_sem);
+ if (npages current-mm-locked_vm)
+ npages = current-mm-locked_vm;
+ current-mm-locked_vm -= npages;
+ pr_debug([%d] RLIMIT_MEMLOCK -%ld %ld/%ld\n, current-pid,
+ npages PAGE_SHIFT,
+ current-mm-locked_vm PAGE_SHIFT,
+ rlimit(RLIMIT_MEMLOCK));
+ up_write(current-mm-mmap_sem);
+}
+
/*
* VFIO IOMMU fd for SPAPR_TCE IOMMU implementation
*
@@ -47,6 +92,7 @@ struct tce_container {
struct mutex lock;
struct iommu_table *tbl;
bool enabled;
+ unsigned long locked_pages;
};
static bool tce_page_is_contained(struct page *page, unsigned page_shift)
@@ -68,7 +114,7 @@ static bool tce_page_is_contained(struct page *page,
unsigned page_shift)
static int tce_iommu_enable(struct tce_container *container)
{
int ret = 0;
- unsigned long locked, lock_limit, npages;
+ unsigned long locked;
struct iommu_table *tbl = container-tbl;
if (!container-tbl)
@@ -97,21 +143,22 @@ static int tce_iommu_enable(struct tce_container
*container)
* Also we don't have a nice way to fail on H_PUT_TCE due to ulimits,
* that would effectively kill the guest at random points, much better
* enforcing the limit based on the max that the guest can map.
+*
+* Unfortunately at the moment it counts whole tables, no matter how
+* much memory the guest has. I.e. for 4GB guest and 4 IOMMU groups
+* each with 2GB DMA window, 8GB will be counted here. The reason for
+* this is that we cannot tell here the amount of RAM used by the guest
+* as this information is only available from KVM and VFIO is
+* KVM agnostic.
*/
- down_write(current-mm-mmap_sem);
- npages = (tbl-it_size tbl-it_page_shift) PAGE_SHIFT;
- locked = current-mm-locked_vm + npages;
- lock_limit = rlimit(RLIMIT_MEMLOCK) PAGE_SHIFT;
- if (locked lock_limit !capable(CAP_IPC_LOCK)) {
- pr_warn(RLIMIT_MEMLOCK (%ld) exceeded\n,
- rlimit(RLIMIT_MEMLOCK));
- ret = -ENOMEM;
- } else {
+ locked = (tbl-it_size tbl-it_page_shift) PAGE_SHIFT;
+ ret = try_increment_locked_vm(locked);
+ if (ret)
+ return ret;
- current-mm-locked_vm += npages;
- container-enabled = true;
- }
- up_write(current-mm-mmap_sem);
+ container-locked_pages = locked;
+
+
Re: [PATCH] spi: spidev: only use up TX/RX bounce buffer space when needed
On 16/02/15 04:13, Mark Brown wrote: On Sun, Feb 15, 2015 at 10:30:22AM +, Ian Abbott wrote: On 14/02/15 04:49, Mark Brown wrote: This is a bit hard to parse. I think you're talking about buffers in spidev here but it's unclear and you've not described in what way you're changing the code and we do currently only seem to copy data when the user has asked for it. Yes, I was talking about spidev. I did tag it in the subject line of the commit message, though I'm sorry if the rest of it is difficult to parse. Right, but it's not clear if you mean that this is something to do with the device drivers for SPI controllers or spidev itself. Okay, how about if I used the term spidev device to distinguish it from the lower-level SPI device? Yes, the patch limits the total user-specified TX data and the total user-specified RX data to the pre-allocated buffer size individually rather than limiting the total sum of user RX and TX data. Your commit message needs to say this rather than requiring the user to reverse engineer it from the code - a key part of reviewing a code change is making sure that it does what the commit message says that it does to make sure that it is having the indended effect. I thought it said that (somewhat clumsily) in the first paragraph. The check against INT_MAX is there because a struct spi_ioc_transfer might have rx_buf==NULL, tx_buf==NULL and len!=0, in which case it would no longer use up space in either of the pre-allocated buffers so neither rx_total nor tx_total would increase. Checking the sum of the len fields against INT_MAX prevents arithmetic overflow in the return value of the function. If that's what the code is supposed to do then someone reading the code needs to be able to tell that without too much effort, I'd not expect that to be possible as things are. Maintainability is very important. There was a whole paragraph about that in the commit message, but maybe it was too concise. I'll have another attempt at the commit message to make it less concise and hopefully easier to follow! -- -=( Ian Abbott @ MEV Ltd.E-mail: abbo...@mev.co.uk )=- -=( Web: http://www.mev.co.uk/ )=- -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@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 3/3] sched/rt: Check to push the task when changing its affinity
From: Xunlei Pang pang.xun...@linaro.org
We may suffer from extra rt overload rq due to the affinity,
so when the affinity of any runnable rt task is changed, we
should check to trigger balancing, otherwise it will cause
some unnecessary delayed real-time response. Unfortunately,
current RT global scheduler doesn't trigger anything.
For example: a 2-cpu system with two runnable FIFO tasks(same
rt_priority) bound on CPU0, let's name them rt1(running) and
rt2(runnable) respectively; CPU1 has no RTs. Then, someone sets
the affinity of rt2 to 0x3(i.e. CPU0 and CPU1), but after this,
rt2 still can't be scheduled until rt1 enters schedule(), this
definitely causes some/big response latency for rt2.
So, when doing set_cpus_allowed_rt(), if detecting such cases,
check to trigger a push behaviour.
Signed-off-by: Xunlei Pang pang.xun...@linaro.org
---
kernel/sched/rt.c | 78 ---
1 file changed, 68 insertions(+), 10 deletions(-)
diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
index 65de40e..2637e23 100644
--- a/kernel/sched/rt.c
+++ b/kernel/sched/rt.c
@@ -1433,10 +1433,9 @@ static struct sched_rt_entity
*pick_next_rt_entity(struct rq *rq,
return next;
}
-static struct task_struct *_pick_next_task_rt(struct rq *rq)
+static struct task_struct *peek_next_task_rt(struct rq *rq)
{
struct sched_rt_entity *rt_se;
- struct task_struct *p;
struct rt_rq *rt_rq = rq-rt;
do {
@@ -1445,7 +1444,14 @@ static struct task_struct *_pick_next_task_rt(struct rq
*rq)
rt_rq = group_rt_rq(rt_se);
} while (rt_rq);
- p = rt_task_of(rt_se);
+ return rt_task_of(rt_se);
+}
+
+static inline struct task_struct *_pick_next_task_rt(struct rq *rq)
+{
+ struct task_struct *p;
+
+ p = peek_next_task_rt(rq);
p-se.exec_start = rq_clock_task(rq);
return p;
@@ -1895,28 +1901,74 @@ static void set_cpus_allowed_rt(struct task_struct *p,
const struct cpumask *new_mask)
{
struct rq *rq;
- int weight;
+ int old_weight, new_weight;
+ int preempt_push = 0, direct_push = 0;
BUG_ON(!rt_task(p));
if (!task_on_rq_queued(p))
return;
- weight = cpumask_weight(new_mask);
+ old_weight = p-nr_cpus_allowed;
+ new_weight = cpumask_weight(new_mask);
+
+ rq = task_rq(p);
+
+ if (new_weight 1
+ rt_task(rq-curr)
+ !test_tsk_need_resched(rq-curr)) {
+ /*
+* We own p-pi_lock and rq-lock. rq-lock might
+* get released when doing direct pushing, however
+* p-pi_lock is always held, so it's safe to assign
+* the new_mask and new_weight to p below.
+*/
+ if (!task_running(rq, p)) {
+ cpumask_copy(p-cpus_allowed, new_mask);
+ p-nr_cpus_allowed = new_weight;
+ direct_push = 1;
+ } else if (cpumask_test_cpu(task_cpu(p), new_mask)) {
+ cpumask_copy(p-cpus_allowed, new_mask);
+ p-nr_cpus_allowed = new_weight;
+ if (!cpupri_find(rq-rd-cpupri, p, NULL))
+ goto update;
+
+ /*
+* At this point, current task gets migratable most
+* likely due to the change of its affinity, let's
+* figure out if we can migrate it.
+*
+* Is there any task with the same priority as that
+* of current task? If found one, we should resched.
+* NOTE: The target may be unpushable.
+*/
+ if (p-prio == rq-rt.highest_prio.next) {
+ /* One target just in pushable_tasks list. */
+ requeue_task_rt(rq, p, 0);
+ preempt_push = 1;
+ } else if (rq-rt.rt_nr_total 1) {
+ struct task_struct *next;
+
+ requeue_task_rt(rq, p, 0);
+ next = peek_next_task_rt(rq);
+ if (next != p next-prio == p-prio)
+ preempt_push = 1;
+ }
+ }
+ }
+update:
/*
* Only update if the process changes its state from whether it
* can migrate or not.
*/
- if ((p-nr_cpus_allowed 1) == (weight 1))
- return;
-
- rq = task_rq(p);
+ if ((old_weight 1) == (new_weight 1))
+ goto out;
/*
* The process used to be able to migrate OR it can now migrate
*/
- if (weight = 1) {
+ if (new_weight = 1) {
Re: [PATCH v4 3/5] irqchip: Add DT binding doc for the virtual irq demuxer chip
Please change the Subject to start with [PATCH] again when including patches, otherwise its too easy for them to get lost. Esp. with excessive quoting on top. I nearly missed the patch here, seeing nothing in the first page of text. On Wed, Feb 11, 2015 at 05:13:13PM +, Mark Rutland wrote: --- include/linux/interrupt.h | 5 + kernel/irq/pm.c | 44 ++-- 2 files changed, 47 insertions(+), 2 deletions(-) diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h index d9b05b5..2b8ff50 100644 --- a/include/linux/interrupt.h +++ b/include/linux/interrupt.h @@ -57,6 +57,9 @@ * IRQF_NO_THREAD - Interrupt cannot be threaded * IRQF_EARLY_RESUME - Resume IRQ early during syscore instead of at device *resume time. + * IRQF_SHARED_TIMER_OK - Interrupt is safe to be shared with a timer. The + *handler may be called spuriously during suspend + *without issue. I feel we should do better documenting this; at the very least refer to Documentation/power/suspend-and-interrupts.txt and ideally put a scary note in telling people that if they use this as a bandaid to make the warn go away, they will end up with a broken system. Now ideally every driver that employs this should also have a comment next to it how it does indeed behave nicely, such that we can 'quickly' see people have indeed thought about things and not just slapped it on to make the WARN go away. diff --git a/kernel/irq/pm.c b/kernel/irq/pm.c index 3ca5325..e4ec91a 100644 --- a/kernel/irq/pm.c +++ b/kernel/irq/pm.c @@ -28,6 +28,47 @@ bool irq_pm_check_wakeup(struct irq_desc *desc) + for (action = desc-action; action; action = action-next) + if (!(action-flags safe_flags)) + return false; In general I prefer braces around the for loop even though C does not strictly require it. Its just too easy to confuse multi-line statements with multiple statements. Extra braces comfort the brain in this case. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3.18 04/57] vm: add VM_FAULT_SIGSEGV handling support
On Tue, Feb 10, 2015 at 12:22:41PM +0400, Konstantin Khlebnikov wrote:
I've found regression:
[ 257.139907]
[ 257.139909] [ BUG: lock held when returning to user space! ]
[ 257.139912] 3.18.6-debug+ #161 Tainted: G U
[ 257.139914]
[ 257.139916] python/22843 is leaving the kernel with locks still held!
[ 257.139918] 1 lock held by python/22843:
[ 257.139920] #0: (mm-mmap_sem){++}, at: [8104e4c2]
__do_page_fault+0x162/0x570
upstream commit 7fb08eca45270d0ae86e1ad9d39c40b7a55d0190 must be backported
too.
I guess the same regression can be found in the 3.16 kernel as it also
includes a backport of 33692f27597f (vm: add VM_FAULT_SIGSEGV
handling support). I'll queue 7fb08eca4527 (x86: mm: move mmap_sem
unlock from mm_fault_error() to caller) as well.
Cheers,
--
Luís
On Wed, Feb 4, 2015 at 2:13 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:
3.18-stable review patch. If anyone has any objections, please let me know.
--
From: Linus Torvalds torva...@linux-foundation.org
commit 33692f27597fcab536d7cbbcc8f52905133e4aa7 upstream.
The core VM already knows about VM_FAULT_SIGBUS, but cannot return a
you should SIGSEGV error, because the SIGSEGV case was generally
handled by the caller - usually the architecture fault handler.
That results in lots of duplication - all the architecture fault
handlers end up doing very similar look up vma, check permissions, do
retries etc - but it generally works. However, there are cases where
the VM actually wants to SIGSEGV, and applications _expect_ SIGSEGV.
In particular, when accessing the stack guard page, libsigsegv expects a
SIGSEGV. And it usually got one, because the stack growth is handled by
that duplicated architecture fault handler.
However, when the generic VM layer started propagating the error return
from the stack expansion in commit fee7e49d4514 (mm: propagate error
from stack expansion even for guard page), that now exposed the
existing VM_FAULT_SIGBUS result to user space. And user space really
expected SIGSEGV, not SIGBUS.
To fix that case, we need to add a VM_FAULT_SIGSEGV, and teach all those
duplicate architecture fault handlers about it. They all already have
the code to handle SIGSEGV, so it's about just tying that new return
value to the existing code, but it's all a bit annoying.
This is the mindless minimal patch to do this. A more extensive patch
would be to try to gather up the mostly shared fault handling logic into
one generic helper routine, and long-term we really should do that
cleanup.
Just from this patch, you can generally see that most architectures just
copied (directly or indirectly) the old x86 way of doing things, but in
the meantime that original x86 model has been improved to hold the VM
semaphore for shorter times etc and to handle VM_FAULT_RETRY and other
newer things, so it would be a good idea to bring all those
improvements to the generic case and teach other architectures about
them too.
Reported-and-tested-by: Takashi Iwai ti...@suse.de
Tested-by: Jan Engelhardt jeng...@inai.de
Acked-by: Heiko Carstens heiko.carst...@de.ibm.com # s390 still compiles
and boots
Cc: linux-a...@vger.kernel.org
Signed-off-by: Linus Torvalds torva...@linux-foundation.org
Signed-off-by: Greg Kroah-Hartman gre...@linuxfoundation.org
---
arch/alpha/mm/fault.c|2 ++
arch/arc/mm/fault.c |2 ++
arch/avr32/mm/fault.c|2 ++
arch/cris/mm/fault.c |2 ++
arch/frv/mm/fault.c |2 ++
arch/ia64/mm/fault.c |2 ++
arch/m32r/mm/fault.c |2 ++
arch/m68k/mm/fault.c |2 ++
arch/metag/mm/fault.c|2 ++
arch/microblaze/mm/fault.c |2 ++
arch/mips/mm/fault.c |2 ++
arch/mn10300/mm/fault.c |2 ++
arch/openrisc/mm/fault.c |2 ++
arch/parisc/mm/fault.c |2 ++
arch/powerpc/mm/copro_fault.c|2 +-
arch/powerpc/mm/fault.c |2 ++
arch/s390/mm/fault.c |6 ++
arch/score/mm/fault.c|2 ++
arch/sh/mm/fault.c |2 ++
arch/sparc/mm/fault_32.c |2 ++
arch/sparc/mm/fault_64.c |2 ++
arch/tile/mm/fault.c |2 ++
arch/um/kernel/trap.c|2 ++
arch/x86/mm/fault.c |2 ++
arch/xtensa/mm/fault.c |2 ++
