Re: [PATCH] mm, thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings
Hello, whlie using this path i got another stall - which i never saw under kernel 4.4. Here is the trace: [305111.932698] INFO: task ksmtuned:1399 blocked for more than 120 seconds. [305111.933612] Tainted: G 4.12.0+105-ph #1 [305111.934456] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [305111.935323] ksmtunedD0 1399 1 0x0008 [305111.936207] Call Trace: [305111.937118] ? __schedule+0x3bc/0x830 [305111.937991] schedule+0x32/0x80 [305111.938837] schedule_preempt_disabled+0xa/0x10 [305111.939687] __mutex_lock.isra.4+0x287/0x4c0 [305111.940550] ? run_store+0x47/0x2b0 [305111.941416] run_store+0x47/0x2b0 [305111.942284] ? __kmalloc+0x157/0x1d0 [305111.943138] kernfs_fop_write+0x102/0x180 [305111.943988] __vfs_write+0x26/0x140 [305111.944827] ? __alloc_fd+0x44/0x170 [305111.945669] ? set_close_on_exec+0x30/0x60 [305111.946519] vfs_write+0xb1/0x1e0 [305111.947359] SyS_write+0x42/0x90 [305111.948193] do_syscall_64+0x74/0x150 [305111.949014] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [305111.949854] RIP: 0033:0x7fe7cde93730 [305111.950678] RSP: 002b:7fffab0d5e88 EFLAGS: 0246 ORIG_RAX: 0001 [305111.951525] RAX: ffda RBX: 0002 RCX: 7fe7cde93730 [305111.952358] RDX: 0002 RSI: 011b1c08 RDI: 0001 [305111.953170] RBP: 011b1c08 R08: 7fe7ce153760 R09: 7fe7ce797b40 [305111.953979] R10: 0073 R11: 0246 R12: 0002 [305111.954790] R13: 0001 R14: 7fe7ce152600 R15: 0002 [305146.987742] khugepaged: page allocation stalls for 224236ms, order:9, mode:0x4740ca(__GFP_HIGHMEM|__GFP_IO|__GFP_FS|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_THISNODE|__GFP_MOVABLE|__GFP_DIRECT_RECLAIM), nodemask=(null) [305146.989652] khugepaged cpuset=/ mems_allowed=0-1 [305146.990582] CPU: 1 PID: 405 Comm: khugepaged Tainted: G 4.12.0+105-ph #1 SLE15 (unreleased) [305146.991536] Hardware name: Supermicro X9DRW-3LN4F+/X9DRW-3TF+/X9DRW-3LN4F+/X9DRW-3TF+, BIOS 3.00 07/05/2013 [305146.992524] Call Trace: [305146.993493] dump_stack+0x5c/0x84 [305146.994499] warn_alloc+0xe0/0x180 [305146.995469] __alloc_pages_slowpath+0x820/0xc90 [305146.996456] ? get_vtime_delta+0x13/0xb0 [305146.997424] ? sched_clock+0x5/0x10 [305146.998394] ? del_timer_sync+0x35/0x40 [305146.999370] __alloc_pages_nodemask+0x1cc/0x210 [305147.000369] khugepaged_alloc_page+0x39/0x70 [305147.001326] khugepaged+0xc0c/0x20c0 [305147.002214] ? remove_wait_queue+0x60/0x60 [305147.003226] kthread+0xff/0x130 [305147.004219] ? collapse_shmem+0xba0/0xba0 [305147.005131] ? kthread_create_on_node+0x40/0x40 [305147.005971] ret_from_fork+0x35/0x40 [305147.006835] Mem-Info: [305147.007681] active_anon:51674768 inactive_anon:69112 isolated_anon:21 active_file:47818 inactive_file:51708 isolated_file:0 unevictable:15710 dirty:187 writeback:0 unstable:0 slab_reclaimable:62499 slab_unreclaimable:1284920 mapped:66765 shmem:47623 pagetables:185294 bounce:0 free:44265934 free_pcp:23646 free_cma:0 [305147.012664] Node 0 active_anon:116919912kB inactive_anon:238824kB active_file:157296kB inactive_file:112820kB unevictable:58364kB isolated(anon):80kB isolated(file):0kB mapped:221548kB dirty:548kB writeback:0kB shmem:153196kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 14430208kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no [305147.015437] Node 1 active_anon:89781496kB inactive_anon:37624kB active_file:33976kB inactive_file:94012kB unevictable:4476kB isolated(anon):4kB isolated(file):0kB mapped:45512kB dirty:200kB writeback:0kB shmem:37296kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 9279488kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no [305147.018550] Node 0 DMA free:15816kB min:12kB low:24kB high:36kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15988kB managed:15816kB mlocked:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [305147.022085] lowmem_reserve[]: 0 1922 193381 193381 193381 [305147.023208] Node 0 DMA32 free:769020kB min:1964kB low:3944kB high:5924kB active_anon:1204144kB inactive_anon:0kB active_file:4kB inactive_file:0kB unevictable:0kB writepending:0kB present:2046368kB managed:1980800kB mlocked:0kB slab_reclaimable:32kB slab_unreclaimable:5376kB kernel_stack:0kB pagetables:1560kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [305147.026768] lowmem_reserve[]: 0 0 191458 191458 191458 [305147.028044] Node 0 Normal free:71769584kB min:194564kB low:390620kB high:586676kB active_anon:115715084kB inactive_anon:238824kB active_file:157292kB inactive_file:112820kB unevictable:58364kB writepending:548kB present:199229440kB managed:196058772kB mlocked:58364kB slab_reclaimable:146536kB
Re: [PATCH] mm, thp: relax __GFP_THISNODE for MADV_HUGEPAGE mappings
Hello, whlie using this path i got another stall - which i never saw under kernel 4.4. Here is the trace: [305111.932698] INFO: task ksmtuned:1399 blocked for more than 120 seconds. [305111.933612] Tainted: G 4.12.0+105-ph #1 [305111.934456] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [305111.935323] ksmtunedD0 1399 1 0x0008 [305111.936207] Call Trace: [305111.937118] ? __schedule+0x3bc/0x830 [305111.937991] schedule+0x32/0x80 [305111.938837] schedule_preempt_disabled+0xa/0x10 [305111.939687] __mutex_lock.isra.4+0x287/0x4c0 [305111.940550] ? run_store+0x47/0x2b0 [305111.941416] run_store+0x47/0x2b0 [305111.942284] ? __kmalloc+0x157/0x1d0 [305111.943138] kernfs_fop_write+0x102/0x180 [305111.943988] __vfs_write+0x26/0x140 [305111.944827] ? __alloc_fd+0x44/0x170 [305111.945669] ? set_close_on_exec+0x30/0x60 [305111.946519] vfs_write+0xb1/0x1e0 [305111.947359] SyS_write+0x42/0x90 [305111.948193] do_syscall_64+0x74/0x150 [305111.949014] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [305111.949854] RIP: 0033:0x7fe7cde93730 [305111.950678] RSP: 002b:7fffab0d5e88 EFLAGS: 0246 ORIG_RAX: 0001 [305111.951525] RAX: ffda RBX: 0002 RCX: 7fe7cde93730 [305111.952358] RDX: 0002 RSI: 011b1c08 RDI: 0001 [305111.953170] RBP: 011b1c08 R08: 7fe7ce153760 R09: 7fe7ce797b40 [305111.953979] R10: 0073 R11: 0246 R12: 0002 [305111.954790] R13: 0001 R14: 7fe7ce152600 R15: 0002 [305146.987742] khugepaged: page allocation stalls for 224236ms, order:9, mode:0x4740ca(__GFP_HIGHMEM|__GFP_IO|__GFP_FS|__GFP_COMP|__GFP_NOMEMALLOC|__GFP_HARDWALL|__GFP_THISNODE|__GFP_MOVABLE|__GFP_DIRECT_RECLAIM), nodemask=(null) [305146.989652] khugepaged cpuset=/ mems_allowed=0-1 [305146.990582] CPU: 1 PID: 405 Comm: khugepaged Tainted: G 4.12.0+105-ph #1 SLE15 (unreleased) [305146.991536] Hardware name: Supermicro X9DRW-3LN4F+/X9DRW-3TF+/X9DRW-3LN4F+/X9DRW-3TF+, BIOS 3.00 07/05/2013 [305146.992524] Call Trace: [305146.993493] dump_stack+0x5c/0x84 [305146.994499] warn_alloc+0xe0/0x180 [305146.995469] __alloc_pages_slowpath+0x820/0xc90 [305146.996456] ? get_vtime_delta+0x13/0xb0 [305146.997424] ? sched_clock+0x5/0x10 [305146.998394] ? del_timer_sync+0x35/0x40 [305146.999370] __alloc_pages_nodemask+0x1cc/0x210 [305147.000369] khugepaged_alloc_page+0x39/0x70 [305147.001326] khugepaged+0xc0c/0x20c0 [305147.002214] ? remove_wait_queue+0x60/0x60 [305147.003226] kthread+0xff/0x130 [305147.004219] ? collapse_shmem+0xba0/0xba0 [305147.005131] ? kthread_create_on_node+0x40/0x40 [305147.005971] ret_from_fork+0x35/0x40 [305147.006835] Mem-Info: [305147.007681] active_anon:51674768 inactive_anon:69112 isolated_anon:21 active_file:47818 inactive_file:51708 isolated_file:0 unevictable:15710 dirty:187 writeback:0 unstable:0 slab_reclaimable:62499 slab_unreclaimable:1284920 mapped:66765 shmem:47623 pagetables:185294 bounce:0 free:44265934 free_pcp:23646 free_cma:0 [305147.012664] Node 0 active_anon:116919912kB inactive_anon:238824kB active_file:157296kB inactive_file:112820kB unevictable:58364kB isolated(anon):80kB isolated(file):0kB mapped:221548kB dirty:548kB writeback:0kB shmem:153196kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 14430208kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no [305147.015437] Node 1 active_anon:89781496kB inactive_anon:37624kB active_file:33976kB inactive_file:94012kB unevictable:4476kB isolated(anon):4kB isolated(file):0kB mapped:45512kB dirty:200kB writeback:0kB shmem:37296kB shmem_thp: 0kB shmem_pmdmapped: 0kB anon_thp: 9279488kB writeback_tmp:0kB unstable:0kB all_unreclaimable? no [305147.018550] Node 0 DMA free:15816kB min:12kB low:24kB high:36kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB writepending:0kB present:15988kB managed:15816kB mlocked:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [305147.022085] lowmem_reserve[]: 0 1922 193381 193381 193381 [305147.023208] Node 0 DMA32 free:769020kB min:1964kB low:3944kB high:5924kB active_anon:1204144kB inactive_anon:0kB active_file:4kB inactive_file:0kB unevictable:0kB writepending:0kB present:2046368kB managed:1980800kB mlocked:0kB slab_reclaimable:32kB slab_unreclaimable:5376kB kernel_stack:0kB pagetables:1560kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB [305147.026768] lowmem_reserve[]: 0 0 191458 191458 191458 [305147.028044] Node 0 Normal free:71769584kB min:194564kB low:390620kB high:586676kB active_anon:115715084kB inactive_anon:238824kB active_file:157292kB inactive_file:112820kB unevictable:58364kB writepending:548kB present:199229440kB managed:196058772kB mlocked:58364kB slab_reclaimable:146536kB
Re: [PATCH] iio: light: bh1750: simplify setting PM ops
On Sun, 2 Sep 2018 15:29:23 +0200
Tomasz Duszynski wrote:
> Relying on CONFIG_PM_SLEEP to set PM ops is not necessary
> since core will handle everything internally. One have to only make sure
> that functions that can go unused are marked with __maybe_unused.
>
> Signed-off-by: Tomasz Duszynski
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/light/bh1750.c | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iio/light/bh1750.c b/drivers/iio/light/bh1750.c
> index 493ca7420602..c3a481452b67 100644
> --- a/drivers/iio/light/bh1750.c
> +++ b/drivers/iio/light/bh1750.c
> @@ -278,8 +278,7 @@ static int bh1750_remove(struct i2c_client *client)
> return 0;
> }
>
> -#ifdef CONFIG_PM_SLEEP
> -static int bh1750_suspend(struct device *dev)
> +static int __maybe_unused bh1750_suspend(struct device *dev)
> {
> int ret;
> struct bh1750_data *data =
> @@ -297,10 +296,6 @@ static int bh1750_suspend(struct device *dev)
> }
>
> static SIMPLE_DEV_PM_OPS(bh1750_pm_ops, bh1750_suspend, NULL);
> -#define BH1750_PM_OPS (_pm_ops)
> -#else
> -#define BH1750_PM_OPS NULL
> -#endif
>
> static const struct i2c_device_id bh1750_id[] = {
> { "bh1710", BH1710 },
> @@ -315,7 +310,7 @@ MODULE_DEVICE_TABLE(i2c, bh1750_id);
> static struct i2c_driver bh1750_driver = {
> .driver = {
> .name = "bh1750",
> - .pm = BH1750_PM_OPS,
> + .pm = _pm_ops,
> },
> .probe = bh1750_probe,
> .remove = bh1750_remove,
> --
> 2.18.0
>
Re: [PATCH] iio: light: bh1750: simplify setting PM ops
On Sun, 2 Sep 2018 15:29:23 +0200
Tomasz Duszynski wrote:
> Relying on CONFIG_PM_SLEEP to set PM ops is not necessary
> since core will handle everything internally. One have to only make sure
> that functions that can go unused are marked with __maybe_unused.
>
> Signed-off-by: Tomasz Duszynski
Applied to the togreg branch of iio.git and pushed out as testing
for the autobuilders to play with it.
Thanks,
Jonathan
> ---
> drivers/iio/light/bh1750.c | 9 ++---
> 1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/iio/light/bh1750.c b/drivers/iio/light/bh1750.c
> index 493ca7420602..c3a481452b67 100644
> --- a/drivers/iio/light/bh1750.c
> +++ b/drivers/iio/light/bh1750.c
> @@ -278,8 +278,7 @@ static int bh1750_remove(struct i2c_client *client)
> return 0;
> }
>
> -#ifdef CONFIG_PM_SLEEP
> -static int bh1750_suspend(struct device *dev)
> +static int __maybe_unused bh1750_suspend(struct device *dev)
> {
> int ret;
> struct bh1750_data *data =
> @@ -297,10 +296,6 @@ static int bh1750_suspend(struct device *dev)
> }
>
> static SIMPLE_DEV_PM_OPS(bh1750_pm_ops, bh1750_suspend, NULL);
> -#define BH1750_PM_OPS (_pm_ops)
> -#else
> -#define BH1750_PM_OPS NULL
> -#endif
>
> static const struct i2c_device_id bh1750_id[] = {
> { "bh1710", BH1710 },
> @@ -315,7 +310,7 @@ MODULE_DEVICE_TABLE(i2c, bh1750_id);
> static struct i2c_driver bh1750_driver = {
> .driver = {
> .name = "bh1750",
> - .pm = BH1750_PM_OPS,
> + .pm = _pm_ops,
> },
> .probe = bh1750_probe,
> .remove = bh1750_remove,
> --
> 2.18.0
>
[PATCH v3 2/2] irq/matrix: Spread managed interrupts on allocation
From: Dou Liyang
Linux has spread out the non managed interrupt across the possible
target CPUs to avoid vector space exhaustion.
But, the same situation may happen on the managed interrupts.
Spread managed interrupt on allocation as well.
Note: also change the return value for the empty search mask case
from EINVAL to ENOSPC.
Signed-off-by: Dou Liyang
---
Changelog v3 --> v2
- Mention the changes in the changelog suggested by tglx
- Use the new matrix_find_best_cpu（) helper
arch/x86/kernel/apic/vector.c | 8 +++-
include/linux/irq.h | 3 ++-
kernel/irq/matrix.c | 14 +++---
3 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 9f148e3d45b4..b7fc290b4b98 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -313,14 +313,12 @@ assign_managed_vector(struct irq_data *irqd, const struct
cpumask *dest)
struct apic_chip_data *apicd = apic_chip_data(irqd);
int vector, cpu;
- cpumask_and(vector_searchmask, vector_searchmask, affmsk);
- cpu = cpumask_first(vector_searchmask);
- if (cpu >= nr_cpu_ids)
- return -EINVAL;
+ cpumask_and(vector_searchmask, dest, affmsk);
+
/* set_affinity might call here for nothing */
if (apicd->vector && cpumask_test_cpu(apicd->cpu, vector_searchmask))
return 0;
- vector = irq_matrix_alloc_managed(vector_matrix, cpu);
+ vector = irq_matrix_alloc_managed(vector_matrix, vector_searchmask,
);
trace_vector_alloc_managed(irqd->irq, vector, vector);
if (vector < 0)
return vector;
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 201de12a9957..c9bffda04a45 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -1151,7 +1151,8 @@ void irq_matrix_offline(struct irq_matrix *m);
void irq_matrix_assign_system(struct irq_matrix *m, unsigned int bit, bool
replace);
int irq_matrix_reserve_managed(struct irq_matrix *m, const struct cpumask
*msk);
void irq_matrix_remove_managed(struct irq_matrix *m, const struct cpumask
*msk);
-int irq_matrix_alloc_managed(struct irq_matrix *m, unsigned int cpu);
+int irq_matrix_alloc_managed(struct irq_matrix *m, const struct cpumask *msk,
+ unsigned int *mapped_cpu);
void irq_matrix_reserve(struct irq_matrix *m);
void irq_matrix_remove_reserved(struct irq_matrix *m);
int irq_matrix_alloc(struct irq_matrix *m, const struct cpumask *msk,
diff --git a/kernel/irq/matrix.c b/kernel/irq/matrix.c
index 67768bbe736e..34f97c4f10d7 100644
--- a/kernel/irq/matrix.c
+++ b/kernel/irq/matrix.c
@@ -260,11 +260,18 @@ void irq_matrix_remove_managed(struct irq_matrix *m,
const struct cpumask *msk)
* @m: Matrix pointer
* @cpu: On which CPU the interrupt should be allocated
*/
-int irq_matrix_alloc_managed(struct irq_matrix *m, unsigned int cpu)
+int irq_matrix_alloc_managed(struct irq_matrix *m, const struct cpumask *msk,
+ unsigned int *mapped_cpu)
{
- struct cpumap *cm = per_cpu_ptr(m->maps, cpu);
- unsigned int bit, end = m->alloc_end;
+ unsigned int bit, cpu, end = m->alloc_end;
+ struct cpumap *cm;
+
+ cpu = matrix_find_best_cpu(m, msk);
+ if (cpu == UINT_MAX)
+ return -ENOSPC;
+ cm = per_cpu_ptr(m->maps, cpu);
+ end = m->alloc_end;
/* Get managed bit which are not allocated */
bitmap_andnot(m->scratch_map, cm->managed_map, cm->alloc_map, end);
bit = find_first_bit(m->scratch_map, end);
@@ -273,6 +280,7 @@ int irq_matrix_alloc_managed(struct irq_matrix *m, unsigned
int cpu)
set_bit(bit, cm->alloc_map);
cm->allocated++;
m->total_allocated++;
+ *mapped_cpu = cpu;
trace_irq_matrix_alloc_managed(bit, cpu, m, cm);
return bit;
}
--
2.14.3
[PATCH v3 1/2] irq/matrix: Split out the CPU finding code into a helper
From: Dou Liyang
Linux finds the CPU which has the lowest vector allocation count to spread
out the non managed interrupt across the possible target CPUs.
This common CPU finding code will also be used in managed case,
So Split it out into a helper for preparation.
Signed-off-by: Dou Liyang
---
Changelog v3 --> v2
- Make the matrix_find_best_cpu() simple and obvious suggested by tglx
- Remove the indentation totally suggested by tglx
kernel/irq/matrix.c | 65 +++--
1 file changed, 38 insertions(+), 27 deletions(-)
diff --git a/kernel/irq/matrix.c b/kernel/irq/matrix.c
index 5092494bf261..67768bbe736e 100644
--- a/kernel/irq/matrix.c
+++ b/kernel/irq/matrix.c
@@ -124,6 +124,27 @@ static unsigned int matrix_alloc_area(struct irq_matrix
*m, struct cpumap *cm,
return area;
}
+/* Find the best CPU which has the lowest vector allocation count */
+static unsigned int matrix_find_best_cpu(struct irq_matrix *m,
+ const struct cpumask *msk)
+{
+ unsigned int cpu, best_cpu, maxavl = 0;
+ struct cpumap *cm;
+
+ best_cpu = UINT_MAX;
+
+ for_each_cpu(cpu, msk) {
+ cm = per_cpu_ptr(m->maps, cpu);
+
+ if (!cm->online || cm->available <= maxavl)
+ continue;
+
+ best_cpu = cpu;
+ maxavl = cm->available;
+ }
+ return best_cpu;
+}
+
/**
* irq_matrix_assign_system - Assign system wide entry in the matrix
* @m: Matrix pointer
@@ -322,37 +343,27 @@ void irq_matrix_remove_reserved(struct irq_matrix *m)
int irq_matrix_alloc(struct irq_matrix *m, const struct cpumask *msk,
bool reserved, unsigned int *mapped_cpu)
{
- unsigned int cpu, best_cpu, maxavl = 0;
+ unsigned int cpu, bit;
struct cpumap *cm;
- unsigned int bit;
- best_cpu = UINT_MAX;
- for_each_cpu(cpu, msk) {
- cm = per_cpu_ptr(m->maps, cpu);
-
- if (!cm->online || cm->available <= maxavl)
- continue;
+ cpu = matrix_find_best_cpu(m, msk);
+ if (cpu == UINT_MAX)
+ return -ENOSPC;
- best_cpu = cpu;
- maxavl = cm->available;
- }
+ cm = per_cpu_ptr(m->maps, cpu);
+ bit = matrix_alloc_area(m, cm, 1, false);
+ if (bit >= m->alloc_end)
+ return -ENOSPC;
+ cm->allocated++;
+ cm->available--;
+ m->total_allocated++;
+ m->global_available--;
+ if (reserved)
+ m->global_reserved--;
+ *mapped_cpu = cpu;
+ trace_irq_matrix_alloc(bit, cpu, m, cm);
+ return bit;
- if (maxavl) {
- cm = per_cpu_ptr(m->maps, best_cpu);
- bit = matrix_alloc_area(m, cm, 1, false);
- if (bit < m->alloc_end) {
- cm->allocated++;
- cm->available--;
- m->total_allocated++;
- m->global_available--;
- if (reserved)
- m->global_reserved--;
- *mapped_cpu = best_cpu;
- trace_irq_matrix_alloc(bit, best_cpu, m, cm);
- return bit;
- }
- }
- return -ENOSPC;
}
/**
--
2.14.3
[PATCH v3 2/2] irq/matrix: Spread managed interrupts on allocation
From: Dou Liyang
Linux has spread out the non managed interrupt across the possible
target CPUs to avoid vector space exhaustion.
But, the same situation may happen on the managed interrupts.
Spread managed interrupt on allocation as well.
Note: also change the return value for the empty search mask case
from EINVAL to ENOSPC.
Signed-off-by: Dou Liyang
---
Changelog v3 --> v2
- Mention the changes in the changelog suggested by tglx
- Use the new matrix_find_best_cpu（) helper
arch/x86/kernel/apic/vector.c | 8 +++-
include/linux/irq.h | 3 ++-
kernel/irq/matrix.c | 14 +++---
3 files changed, 16 insertions(+), 9 deletions(-)
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 9f148e3d45b4..b7fc290b4b98 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -313,14 +313,12 @@ assign_managed_vector(struct irq_data *irqd, const struct
cpumask *dest)
struct apic_chip_data *apicd = apic_chip_data(irqd);
int vector, cpu;
- cpumask_and(vector_searchmask, vector_searchmask, affmsk);
- cpu = cpumask_first(vector_searchmask);
- if (cpu >= nr_cpu_ids)
- return -EINVAL;
+ cpumask_and(vector_searchmask, dest, affmsk);
+
/* set_affinity might call here for nothing */
if (apicd->vector && cpumask_test_cpu(apicd->cpu, vector_searchmask))
return 0;
- vector = irq_matrix_alloc_managed(vector_matrix, cpu);
+ vector = irq_matrix_alloc_managed(vector_matrix, vector_searchmask,
);
trace_vector_alloc_managed(irqd->irq, vector, vector);
if (vector < 0)
return vector;
diff --git a/include/linux/irq.h b/include/linux/irq.h
index 201de12a9957..c9bffda04a45 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -1151,7 +1151,8 @@ void irq_matrix_offline(struct irq_matrix *m);
void irq_matrix_assign_system(struct irq_matrix *m, unsigned int bit, bool
replace);
int irq_matrix_reserve_managed(struct irq_matrix *m, const struct cpumask
*msk);
void irq_matrix_remove_managed(struct irq_matrix *m, const struct cpumask
*msk);
-int irq_matrix_alloc_managed(struct irq_matrix *m, unsigned int cpu);
+int irq_matrix_alloc_managed(struct irq_matrix *m, const struct cpumask *msk,
+ unsigned int *mapped_cpu);
void irq_matrix_reserve(struct irq_matrix *m);
void irq_matrix_remove_reserved(struct irq_matrix *m);
int irq_matrix_alloc(struct irq_matrix *m, const struct cpumask *msk,
diff --git a/kernel/irq/matrix.c b/kernel/irq/matrix.c
index 67768bbe736e..34f97c4f10d7 100644
--- a/kernel/irq/matrix.c
+++ b/kernel/irq/matrix.c
@@ -260,11 +260,18 @@ void irq_matrix_remove_managed(struct irq_matrix *m,
const struct cpumask *msk)
* @m: Matrix pointer
* @cpu: On which CPU the interrupt should be allocated
*/
-int irq_matrix_alloc_managed(struct irq_matrix *m, unsigned int cpu)
+int irq_matrix_alloc_managed(struct irq_matrix *m, const struct cpumask *msk,
+ unsigned int *mapped_cpu)
{
- struct cpumap *cm = per_cpu_ptr(m->maps, cpu);
- unsigned int bit, end = m->alloc_end;
+ unsigned int bit, cpu, end = m->alloc_end;
+ struct cpumap *cm;
+
+ cpu = matrix_find_best_cpu(m, msk);
+ if (cpu == UINT_MAX)
+ return -ENOSPC;
+ cm = per_cpu_ptr(m->maps, cpu);
+ end = m->alloc_end;
/* Get managed bit which are not allocated */
bitmap_andnot(m->scratch_map, cm->managed_map, cm->alloc_map, end);
bit = find_first_bit(m->scratch_map, end);
@@ -273,6 +280,7 @@ int irq_matrix_alloc_managed(struct irq_matrix *m, unsigned
int cpu)
set_bit(bit, cm->alloc_map);
cm->allocated++;
m->total_allocated++;
+ *mapped_cpu = cpu;
trace_irq_matrix_alloc_managed(bit, cpu, m, cm);
return bit;
}
--
2.14.3
[PATCH v3 1/2] irq/matrix: Split out the CPU finding code into a helper
From: Dou Liyang
Linux finds the CPU which has the lowest vector allocation count to spread
out the non managed interrupt across the possible target CPUs.
This common CPU finding code will also be used in managed case,
So Split it out into a helper for preparation.
Signed-off-by: Dou Liyang
---
Changelog v3 --> v2
- Make the matrix_find_best_cpu() simple and obvious suggested by tglx
- Remove the indentation totally suggested by tglx
kernel/irq/matrix.c | 65 +++--
1 file changed, 38 insertions(+), 27 deletions(-)
diff --git a/kernel/irq/matrix.c b/kernel/irq/matrix.c
index 5092494bf261..67768bbe736e 100644
--- a/kernel/irq/matrix.c
+++ b/kernel/irq/matrix.c
@@ -124,6 +124,27 @@ static unsigned int matrix_alloc_area(struct irq_matrix
*m, struct cpumap *cm,
return area;
}
+/* Find the best CPU which has the lowest vector allocation count */
+static unsigned int matrix_find_best_cpu(struct irq_matrix *m,
+ const struct cpumask *msk)
+{
+ unsigned int cpu, best_cpu, maxavl = 0;
+ struct cpumap *cm;
+
+ best_cpu = UINT_MAX;
+
+ for_each_cpu(cpu, msk) {
+ cm = per_cpu_ptr(m->maps, cpu);
+
+ if (!cm->online || cm->available <= maxavl)
+ continue;
+
+ best_cpu = cpu;
+ maxavl = cm->available;
+ }
+ return best_cpu;
+}
+
/**
* irq_matrix_assign_system - Assign system wide entry in the matrix
* @m: Matrix pointer
@@ -322,37 +343,27 @@ void irq_matrix_remove_reserved(struct irq_matrix *m)
int irq_matrix_alloc(struct irq_matrix *m, const struct cpumask *msk,
bool reserved, unsigned int *mapped_cpu)
{
- unsigned int cpu, best_cpu, maxavl = 0;
+ unsigned int cpu, bit;
struct cpumap *cm;
- unsigned int bit;
- best_cpu = UINT_MAX;
- for_each_cpu(cpu, msk) {
- cm = per_cpu_ptr(m->maps, cpu);
-
- if (!cm->online || cm->available <= maxavl)
- continue;
+ cpu = matrix_find_best_cpu(m, msk);
+ if (cpu == UINT_MAX)
+ return -ENOSPC;
- best_cpu = cpu;
- maxavl = cm->available;
- }
+ cm = per_cpu_ptr(m->maps, cpu);
+ bit = matrix_alloc_area(m, cm, 1, false);
+ if (bit >= m->alloc_end)
+ return -ENOSPC;
+ cm->allocated++;
+ cm->available--;
+ m->total_allocated++;
+ m->global_available--;
+ if (reserved)
+ m->global_reserved--;
+ *mapped_cpu = cpu;
+ trace_irq_matrix_alloc(bit, cpu, m, cm);
+ return bit;
- if (maxavl) {
- cm = per_cpu_ptr(m->maps, best_cpu);
- bit = matrix_alloc_area(m, cm, 1, false);
- if (bit < m->alloc_end) {
- cm->allocated++;
- cm->available--;
- m->total_allocated++;
- m->global_available--;
- if (reserved)
- m->global_reserved--;
- *mapped_cpu = best_cpu;
- trace_irq_matrix_alloc(bit, best_cpu, m, cm);
- return bit;
- }
- }
- return -ENOSPC;
}
/**
--
2.14.3
Re: [PATCH 00/29] staging: bcm2835-audio: Cleanups and fixes
On Sat, 08 Sep 2018 19:00:34 +0200,
Stefan Wahren wrote:
>
> Hi,
>
> > Takashi Iwai hat am 8. September 2018 um 18:21 geschrieben:
> >
> >
> > On Sat, 08 Sep 2018 15:18:10 +0200,
> > Stefan Wahren wrote:
> > >
> > > Hi Takashi,
> > >
> > > > Takashi Iwai hat am 4. September 2018 um 17:58
> > > > geschrieben:
> > > >
> > > >
> > > > Hi,
> > > >
> > > > since I had an opportunity to play with RPi3B+ recently, I took a look
> > > > at the existing bcm2835-audio driver code and was amused very much :)
> > > >
> > > > So here is the result, a cleanup and fix patch series.
> > > >
> > > > Most of the patches are trivial cleanups, just brushing up, removing
> > > > many redundant and buggy codes, as well as code simplifications.
> > > >
> > > > A big functional change is that now it uses non-atomic PCM ops, so
> > > > that we can kill the ugly workqueue usages. Also, the resource
> > > > management was simplified.
> > >
> > > first of all, thank you very much for this series.
> > >
> > > Eric has no time as maintainer, so i will try to give you some feedback
> > > (beware of very little audio driver knowledge).
> > >
> > > I functionally tested your patch series on a Raspberry Pi 1 B
> > > (bcm2835_defconfig), so this whole series is at least:
> > >
> > > Tested-by: Stefan Wahren
> >
> > OK, thanks, I'll put to my series in case of resubmission.
> > Meanwhile I'll keep the series in topic/vc04 branch of sound.git
> > tree.
>
> does it mean this series should go through your tree instead of Greg's?
I don't mind either way. I just wanted to expose the latest patchset
in git tree in case anyone needing more reviews.
The merge route can be decided later.
> > > Unfortunately there is still an corruption issue with underlying vchiq
> > > and multi_v7_defconfig, so no wider tests.
> >
> > What is this corruption issue?
>
> Actual there are two of them.
>
> First one are incompatibilities of older VC4 firmware with commit
> 14dd37fc7b65 ("staging: vc04_services: Remove cache-line-size property
> (v3)"). There is a pull request for the Foundation kernel which hasn't been
> upstreamed yet [1].
>
> The second is documented here [2].
>
> [1] - https://github.com/raspberrypi/linux/pull/2666
> [2] - https://github.com/lategoodbye/rpi-zero/issues/23
OK, thanks.
> > > I don't know if you tested this series on a Raspberry Pi. Maybe you have
> > > some specific scenarios, which should be tested.
> >
> > I have only a RPi3B+, and that's all what I've tested.
>
> Great, just of curiosity which config did you use?
It's SLE / openSUSE. The kernel is almost vanilla 4.18.5 with my
patches.
> > It'd be great if the patch series could be tested in a wider range of
> > models, of course.
> >
> > The patches are only about cleanups. They corrected the bad usages of
> > audio APIs and its design, but basically I haven't touched the basic
> > functionality intentionally at all. So the behavior should be kept as
> > before.
> >
> > (Actually it'd be better to revisit the design later, especially about
> > the multi-cards option and the PCM route mixer control, but I left as
> > is for compatibility reason for now.)
> >
> > > As a reviewer i have some suggestions, but only trivia. I don't know if
> > > it's a problem that this series hasn't been send to
> > > de...@driverdev.osuosl.org
> >
> > No, it's just because that address isn't found in MAINTAINERS file.
> > If it should go through it, please correct the entry at first :)
>
> No, this is the mailing list for all staging driver. It is reported by
> get_maintainers.pl
Ah, I see.
thanks,
Takashi
Re: [PATCH 00/29] staging: bcm2835-audio: Cleanups and fixes
On Sat, 08 Sep 2018 19:00:34 +0200,
Stefan Wahren wrote:
>
> Hi,
>
> > Takashi Iwai hat am 8. September 2018 um 18:21 geschrieben:
> >
> >
> > On Sat, 08 Sep 2018 15:18:10 +0200,
> > Stefan Wahren wrote:
> > >
> > > Hi Takashi,
> > >
> > > > Takashi Iwai hat am 4. September 2018 um 17:58
> > > > geschrieben:
> > > >
> > > >
> > > > Hi,
> > > >
> > > > since I had an opportunity to play with RPi3B+ recently, I took a look
> > > > at the existing bcm2835-audio driver code and was amused very much :)
> > > >
> > > > So here is the result, a cleanup and fix patch series.
> > > >
> > > > Most of the patches are trivial cleanups, just brushing up, removing
> > > > many redundant and buggy codes, as well as code simplifications.
> > > >
> > > > A big functional change is that now it uses non-atomic PCM ops, so
> > > > that we can kill the ugly workqueue usages. Also, the resource
> > > > management was simplified.
> > >
> > > first of all, thank you very much for this series.
> > >
> > > Eric has no time as maintainer, so i will try to give you some feedback
> > > (beware of very little audio driver knowledge).
> > >
> > > I functionally tested your patch series on a Raspberry Pi 1 B
> > > (bcm2835_defconfig), so this whole series is at least:
> > >
> > > Tested-by: Stefan Wahren
> >
> > OK, thanks, I'll put to my series in case of resubmission.
> > Meanwhile I'll keep the series in topic/vc04 branch of sound.git
> > tree.
>
> does it mean this series should go through your tree instead of Greg's?
I don't mind either way. I just wanted to expose the latest patchset
in git tree in case anyone needing more reviews.
The merge route can be decided later.
> > > Unfortunately there is still an corruption issue with underlying vchiq
> > > and multi_v7_defconfig, so no wider tests.
> >
> > What is this corruption issue?
>
> Actual there are two of them.
>
> First one are incompatibilities of older VC4 firmware with commit
> 14dd37fc7b65 ("staging: vc04_services: Remove cache-line-size property
> (v3)"). There is a pull request for the Foundation kernel which hasn't been
> upstreamed yet [1].
>
> The second is documented here [2].
>
> [1] - https://github.com/raspberrypi/linux/pull/2666
> [2] - https://github.com/lategoodbye/rpi-zero/issues/23
OK, thanks.
> > > I don't know if you tested this series on a Raspberry Pi. Maybe you have
> > > some specific scenarios, which should be tested.
> >
> > I have only a RPi3B+, and that's all what I've tested.
>
> Great, just of curiosity which config did you use?
It's SLE / openSUSE. The kernel is almost vanilla 4.18.5 with my
patches.
> > It'd be great if the patch series could be tested in a wider range of
> > models, of course.
> >
> > The patches are only about cleanups. They corrected the bad usages of
> > audio APIs and its design, but basically I haven't touched the basic
> > functionality intentionally at all. So the behavior should be kept as
> > before.
> >
> > (Actually it'd be better to revisit the design later, especially about
> > the multi-cards option and the PCM route mixer control, but I left as
> > is for compatibility reason for now.)
> >
> > > As a reviewer i have some suggestions, but only trivia. I don't know if
> > > it's a problem that this series hasn't been send to
> > > de...@driverdev.osuosl.org
> >
> > No, it's just because that address isn't found in MAINTAINERS file.
> > If it should go through it, please correct the entry at first :)
>
> No, this is the mailing list for all staging driver. It is reported by
> get_maintainers.pl
Ah, I see.
thanks,
Takashi
[GIT PULL] ARM: SoC fixes
Hi Linus,
The following changes since commit a72b44a871c218e2a0580e68affa1d3528c0587a:
Merge tag 'omap-for-v4.19/fixes-v2-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
(2018-09-01 18:22:19 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
tags/armsoc-fixes
for you to fetch changes up to a132bb90414bfad4f8ee23cb45fe6946a89b167d:
Merge tag 'sunxi-fixes-for-4.19' of
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into fixes
(2018-09-08 10:04:37 -0700)
ARM: SoC fixes
A few more fixes who have trickled in:
- MMC bus width fixup for some Allwinner platforms
- Fix for NULL deref in ti-aemif when no platform data is passed in
- Fix div by 0 in SCMI code
- Add a missing module alias in a new RPi driver
Bartosz Golaszewski (1):
memory: ti-aemif: fix a potential NULL-pointer dereference
Icenowy Zheng (1):
arm64: allwinner: dts: h6: fix Pine H64 MMC bus width
Olof Johansson (2):
Merge tag 'arm-soc/for-4.19/drivers-fixes' of
https://github.com/Broadcom/stblinux into fixes
Merge tag 'sunxi-fixes-for-4.19' of
https://git.kernel.org/.../sunxi/linux into fixes
Peter Robinson (1):
hwmon: rpi: add module alias to raspberrypi-hwmon
Sudeep Holla (1):
firmware: arm_scmi: fix divide by zero when sustained_perf_level is zero
arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts | 2 ++
drivers/firmware/arm_scmi/perf.c | 8 +++-
drivers/hwmon/raspberrypi-hwmon.c| 1 +
drivers/memory/ti-aemif.c| 2 +-
4 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
index ceffc40810ee..48daec7f78ba 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
@@ -46,6 +46,7 @@
pinctrl-0 = <_pins>;
vmmc-supply = <_cldo1>;
cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;
+ bus-width = <4>;
status = "okay";
};
@@ -56,6 +57,7 @@
vqmmc-supply = <_bldo2>;
non-removable;
cap-mmc-hw-reset;
+ bus-width = <8>;
status = "okay";
};
diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c
index 721e6c57beae..64342944d917 100644
--- a/drivers/firmware/arm_scmi/perf.c
+++ b/drivers/firmware/arm_scmi/perf.c
@@ -166,7 +166,13 @@ scmi_perf_domain_attributes_get(const struct scmi_handle
*handle, u32 domain,
le32_to_cpu(attr->sustained_freq_khz);
dom_info->sustained_perf_level =
le32_to_cpu(attr->sustained_perf_level);
- dom_info->mult_factor = (dom_info->sustained_freq_khz * 1000) /
+ if (!dom_info->sustained_freq_khz ||
+ !dom_info->sustained_perf_level)
+ /* CPUFreq converts to kHz, hence default 1000 */
+ dom_info->mult_factor = 1000;
+ else
+ dom_info->mult_factor =
+ (dom_info->sustained_freq_khz * 1000) /
dom_info->sustained_perf_level;
memcpy(dom_info->name, attr->name, SCMI_MAX_STR_SIZE);
}
diff --git a/drivers/hwmon/raspberrypi-hwmon.c
b/drivers/hwmon/raspberrypi-hwmon.c
index fb4e4a6bb1f6..be5ba4690895 100644
--- a/drivers/hwmon/raspberrypi-hwmon.c
+++ b/drivers/hwmon/raspberrypi-hwmon.c
@@ -164,3 +164,4 @@ module_platform_driver(rpi_hwmon_driver);
MODULE_AUTHOR("Stefan Wahren ");
MODULE_DESCRIPTION("Raspberry Pi voltage sensor driver");
MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:raspberrypi-hwmon");
diff --git a/drivers/memory/ti-aemif.c b/drivers/memory/ti-aemif.c
index 31112f622b88..475e5b3790ed 100644
--- a/drivers/memory/ti-aemif.c
+++ b/drivers/memory/ti-aemif.c
@@ -411,7 +411,7 @@ static int aemif_probe(struct platform_device *pdev)
if (ret < 0)
goto error;
}
- } else {
+ } else if (pdata) {
for (i = 0; i < pdata->num_sub_devices; i++) {
pdata->sub_devices[i].dev.parent = dev;
ret = platform_device_register(>sub_devices[i]);
[GIT PULL] ARM: SoC fixes
Hi Linus,
The following changes since commit a72b44a871c218e2a0580e68affa1d3528c0587a:
Merge tag 'omap-for-v4.19/fixes-v2-signed' of
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes
(2018-09-01 18:22:19 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git
tags/armsoc-fixes
for you to fetch changes up to a132bb90414bfad4f8ee23cb45fe6946a89b167d:
Merge tag 'sunxi-fixes-for-4.19' of
https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux into fixes
(2018-09-08 10:04:37 -0700)
ARM: SoC fixes
A few more fixes who have trickled in:
- MMC bus width fixup for some Allwinner platforms
- Fix for NULL deref in ti-aemif when no platform data is passed in
- Fix div by 0 in SCMI code
- Add a missing module alias in a new RPi driver
Bartosz Golaszewski (1):
memory: ti-aemif: fix a potential NULL-pointer dereference
Icenowy Zheng (1):
arm64: allwinner: dts: h6: fix Pine H64 MMC bus width
Olof Johansson (2):
Merge tag 'arm-soc/for-4.19/drivers-fixes' of
https://github.com/Broadcom/stblinux into fixes
Merge tag 'sunxi-fixes-for-4.19' of
https://git.kernel.org/.../sunxi/linux into fixes
Peter Robinson (1):
hwmon: rpi: add module alias to raspberrypi-hwmon
Sudeep Holla (1):
firmware: arm_scmi: fix divide by zero when sustained_perf_level is zero
arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts | 2 ++
drivers/firmware/arm_scmi/perf.c | 8 +++-
drivers/hwmon/raspberrypi-hwmon.c| 1 +
drivers/memory/ti-aemif.c| 2 +-
4 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
index ceffc40810ee..48daec7f78ba 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-h6-pine-h64.dts
@@ -46,6 +46,7 @@
pinctrl-0 = <_pins>;
vmmc-supply = <_cldo1>;
cd-gpios = < 5 6 GPIO_ACTIVE_LOW>;
+ bus-width = <4>;
status = "okay";
};
@@ -56,6 +57,7 @@
vqmmc-supply = <_bldo2>;
non-removable;
cap-mmc-hw-reset;
+ bus-width = <8>;
status = "okay";
};
diff --git a/drivers/firmware/arm_scmi/perf.c b/drivers/firmware/arm_scmi/perf.c
index 721e6c57beae..64342944d917 100644
--- a/drivers/firmware/arm_scmi/perf.c
+++ b/drivers/firmware/arm_scmi/perf.c
@@ -166,7 +166,13 @@ scmi_perf_domain_attributes_get(const struct scmi_handle
*handle, u32 domain,
le32_to_cpu(attr->sustained_freq_khz);
dom_info->sustained_perf_level =
le32_to_cpu(attr->sustained_perf_level);
- dom_info->mult_factor = (dom_info->sustained_freq_khz * 1000) /
+ if (!dom_info->sustained_freq_khz ||
+ !dom_info->sustained_perf_level)
+ /* CPUFreq converts to kHz, hence default 1000 */
+ dom_info->mult_factor = 1000;
+ else
+ dom_info->mult_factor =
+ (dom_info->sustained_freq_khz * 1000) /
dom_info->sustained_perf_level;
memcpy(dom_info->name, attr->name, SCMI_MAX_STR_SIZE);
}
diff --git a/drivers/hwmon/raspberrypi-hwmon.c
b/drivers/hwmon/raspberrypi-hwmon.c
index fb4e4a6bb1f6..be5ba4690895 100644
--- a/drivers/hwmon/raspberrypi-hwmon.c
+++ b/drivers/hwmon/raspberrypi-hwmon.c
@@ -164,3 +164,4 @@ module_platform_driver(rpi_hwmon_driver);
MODULE_AUTHOR("Stefan Wahren ");
MODULE_DESCRIPTION("Raspberry Pi voltage sensor driver");
MODULE_LICENSE("GPL v2");
+MODULE_ALIAS("platform:raspberrypi-hwmon");
diff --git a/drivers/memory/ti-aemif.c b/drivers/memory/ti-aemif.c
index 31112f622b88..475e5b3790ed 100644
--- a/drivers/memory/ti-aemif.c
+++ b/drivers/memory/ti-aemif.c
@@ -411,7 +411,7 @@ static int aemif_probe(struct platform_device *pdev)
if (ret < 0)
goto error;
}
- } else {
+ } else if (pdata) {
for (i = 0; i < pdata->num_sub_devices; i++) {
pdata->sub_devices[i].dev.parent = dev;
ret = platform_device_register(>sub_devices[i]);
Re: [PATCH 00/29] staging: bcm2835-audio: Cleanups and fixes
Hi,
> Takashi Iwai hat am 8. September 2018 um 18:21 geschrieben:
>
>
> On Sat, 08 Sep 2018 15:18:10 +0200,
> Stefan Wahren wrote:
> >
> > Hi Takashi,
> >
> > > Takashi Iwai hat am 4. September 2018 um 17:58
> > > geschrieben:
> > >
> > >
> > > Hi,
> > >
> > > since I had an opportunity to play with RPi3B+ recently, I took a look
> > > at the existing bcm2835-audio driver code and was amused very much :)
> > >
> > > So here is the result, a cleanup and fix patch series.
> > >
> > > Most of the patches are trivial cleanups, just brushing up, removing
> > > many redundant and buggy codes, as well as code simplifications.
> > >
> > > A big functional change is that now it uses non-atomic PCM ops, so
> > > that we can kill the ugly workqueue usages. Also, the resource
> > > management was simplified.
> >
> > first of all, thank you very much for this series.
> >
> > Eric has no time as maintainer, so i will try to give you some feedback
> > (beware of very little audio driver knowledge).
> >
> > I functionally tested your patch series on a Raspberry Pi 1 B
> > (bcm2835_defconfig), so this whole series is at least:
> >
> > Tested-by: Stefan Wahren
>
> OK, thanks, I'll put to my series in case of resubmission.
> Meanwhile I'll keep the series in topic/vc04 branch of sound.git
> tree.
does it mean this series should go through your tree instead of Greg's?
>
> > Unfortunately there is still an corruption issue with underlying vchiq and
> > multi_v7_defconfig, so no wider tests.
>
> What is this corruption issue?
Actual there are two of them.
First one are incompatibilities of older VC4 firmware with commit 14dd37fc7b65
("staging: vc04_services: Remove cache-line-size property (v3)"). There is a
pull request for the Foundation kernel which hasn't been upstreamed yet [1].
The second is documented here [2].
[1] - https://github.com/raspberrypi/linux/pull/2666
[2] - https://github.com/lategoodbye/rpi-zero/issues/23
>
> > I don't know if you tested this series on a Raspberry Pi. Maybe you have
> > some specific scenarios, which should be tested.
>
> I have only a RPi3B+, and that's all what I've tested.
Great, just of curiosity which config did you use?
> It'd be great if the patch series could be tested in a wider range of
> models, of course.
>
> The patches are only about cleanups. They corrected the bad usages of
> audio APIs and its design, but basically I haven't touched the basic
> functionality intentionally at all. So the behavior should be kept as
> before.
>
> (Actually it'd be better to revisit the design later, especially about
> the multi-cards option and the PCM route mixer control, but I left as
> is for compatibility reason for now.)
>
> > As a reviewer i have some suggestions, but only trivia. I don't know if
> > it's a problem that this series hasn't been send to
> > de...@driverdev.osuosl.org
>
> No, it's just because that address isn't found in MAINTAINERS file.
> If it should go through it, please correct the entry at first :)
No, this is the mailing list for all staging driver. It is reported by
get_maintainers.pl
Stefan
>
>
> Thanks!
>
> Takashi
Re: [PATCH 00/29] staging: bcm2835-audio: Cleanups and fixes
Hi,
> Takashi Iwai hat am 8. September 2018 um 18:21 geschrieben:
>
>
> On Sat, 08 Sep 2018 15:18:10 +0200,
> Stefan Wahren wrote:
> >
> > Hi Takashi,
> >
> > > Takashi Iwai hat am 4. September 2018 um 17:58
> > > geschrieben:
> > >
> > >
> > > Hi,
> > >
> > > since I had an opportunity to play with RPi3B+ recently, I took a look
> > > at the existing bcm2835-audio driver code and was amused very much :)
> > >
> > > So here is the result, a cleanup and fix patch series.
> > >
> > > Most of the patches are trivial cleanups, just brushing up, removing
> > > many redundant and buggy codes, as well as code simplifications.
> > >
> > > A big functional change is that now it uses non-atomic PCM ops, so
> > > that we can kill the ugly workqueue usages. Also, the resource
> > > management was simplified.
> >
> > first of all, thank you very much for this series.
> >
> > Eric has no time as maintainer, so i will try to give you some feedback
> > (beware of very little audio driver knowledge).
> >
> > I functionally tested your patch series on a Raspberry Pi 1 B
> > (bcm2835_defconfig), so this whole series is at least:
> >
> > Tested-by: Stefan Wahren
>
> OK, thanks, I'll put to my series in case of resubmission.
> Meanwhile I'll keep the series in topic/vc04 branch of sound.git
> tree.
does it mean this series should go through your tree instead of Greg's?
>
> > Unfortunately there is still an corruption issue with underlying vchiq and
> > multi_v7_defconfig, so no wider tests.
>
> What is this corruption issue?
Actual there are two of them.
First one are incompatibilities of older VC4 firmware with commit 14dd37fc7b65
("staging: vc04_services: Remove cache-line-size property (v3)"). There is a
pull request for the Foundation kernel which hasn't been upstreamed yet [1].
The second is documented here [2].
[1] - https://github.com/raspberrypi/linux/pull/2666
[2] - https://github.com/lategoodbye/rpi-zero/issues/23
>
> > I don't know if you tested this series on a Raspberry Pi. Maybe you have
> > some specific scenarios, which should be tested.
>
> I have only a RPi3B+, and that's all what I've tested.
Great, just of curiosity which config did you use?
> It'd be great if the patch series could be tested in a wider range of
> models, of course.
>
> The patches are only about cleanups. They corrected the bad usages of
> audio APIs and its design, but basically I haven't touched the basic
> functionality intentionally at all. So the behavior should be kept as
> before.
>
> (Actually it'd be better to revisit the design later, especially about
> the multi-cards option and the PCM route mixer control, but I left as
> is for compatibility reason for now.)
>
> > As a reviewer i have some suggestions, but only trivia. I don't know if
> > it's a problem that this series hasn't been send to
> > de...@driverdev.osuosl.org
>
> No, it's just because that address isn't found in MAINTAINERS file.
> If it should go through it, please correct the entry at first :)
No, this is the mailing list for all staging driver. It is reported by
get_maintainers.pl
Stefan
>
>
> Thanks!
>
> Takashi
Re: [PATCH] [trivial] treewide: Fix typos in printk
On 09/08/2018 06:43 AM, Masanari Iida wrote: > This patch fixes some spelling typos found in printk messages. > > Signed-off-by: Masanari Iida Acked-by: Randy Dunlap Thanks. > --- > drivers/dma/ep93xx_dma.c | 6 +++--- > drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 2 +- > drivers/gpu/drm/drm_kms_helper_common.c| 2 +- > drivers/gpu/drm/selftests/test-drm_mm.c| 2 +- > drivers/media/v4l2-core/videobuf-core.c| 2 +- > drivers/net/ethernet/mellanox/mlxsw/spectrum_dcb.c | 2 +- > drivers/net/wireless/marvell/libertas/if_usb.c | 2 +- > drivers/net/wireless/marvell/libertas_tf/if_usb.c | 4 ++-- > drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 2 +- > drivers/soc/imx/gpcv2.c| 2 +- > fs/gfs2/super.c| 2 +- > 11 files changed, 14 insertions(+), 14 deletions(-) -- ~Randy
Re: [PATCH] [trivial] treewide: Fix typos in printk
On 09/08/2018 06:43 AM, Masanari Iida wrote: > This patch fixes some spelling typos found in printk messages. > > Signed-off-by: Masanari Iida Acked-by: Randy Dunlap Thanks. > --- > drivers/dma/ep93xx_dma.c | 6 +++--- > drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 2 +- > drivers/gpu/drm/drm_kms_helper_common.c| 2 +- > drivers/gpu/drm/selftests/test-drm_mm.c| 2 +- > drivers/media/v4l2-core/videobuf-core.c| 2 +- > drivers/net/ethernet/mellanox/mlxsw/spectrum_dcb.c | 2 +- > drivers/net/wireless/marvell/libertas/if_usb.c | 2 +- > drivers/net/wireless/marvell/libertas_tf/if_usb.c | 4 ++-- > drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 2 +- > drivers/soc/imx/gpcv2.c| 2 +- > fs/gfs2/super.c| 2 +- > 11 files changed, 14 insertions(+), 14 deletions(-) -- ~Randy
Re: [PATCH 00/29] staging: bcm2835-audio: Cleanups and fixes
On Sat, 08 Sep 2018 15:18:10 +0200, Stefan Wahren wrote: > > Hi Takashi, > > > Takashi Iwai hat am 4. September 2018 um 17:58 geschrieben: > > > > > > Hi, > > > > since I had an opportunity to play with RPi3B+ recently, I took a look > > at the existing bcm2835-audio driver code and was amused very much :) > > > > So here is the result, a cleanup and fix patch series. > > > > Most of the patches are trivial cleanups, just brushing up, removing > > many redundant and buggy codes, as well as code simplifications. > > > > A big functional change is that now it uses non-atomic PCM ops, so > > that we can kill the ugly workqueue usages. Also, the resource > > management was simplified. > > first of all, thank you very much for this series. > > Eric has no time as maintainer, so i will try to give you some feedback > (beware of very little audio driver knowledge). > > I functionally tested your patch series on a Raspberry Pi 1 B > (bcm2835_defconfig), so this whole series is at least: > > Tested-by: Stefan Wahren OK, thanks, I'll put to my series in case of resubmission. Meanwhile I'll keep the series in topic/vc04 branch of sound.git tree. > Unfortunately there is still an corruption issue with underlying vchiq and > multi_v7_defconfig, so no wider tests. What is this corruption issue? > I don't know if you tested this series on a Raspberry Pi. Maybe you have some > specific scenarios, which should be tested. I have only a RPi3B+, and that's all what I've tested. It'd be great if the patch series could be tested in a wider range of models, of course. The patches are only about cleanups. They corrected the bad usages of audio APIs and its design, but basically I haven't touched the basic functionality intentionally at all. So the behavior should be kept as before. (Actually it'd be better to revisit the design later, especially about the multi-cards option and the PCM route mixer control, but I left as is for compatibility reason for now.) > As a reviewer i have some suggestions, but only trivia. I don't know if it's > a problem that this series hasn't been send to de...@driverdev.osuosl.org No, it's just because that address isn't found in MAINTAINERS file. If it should go through it, please correct the entry at first :) Thanks! Takashi
Re: [PATCH 00/29] staging: bcm2835-audio: Cleanups and fixes
On Sat, 08 Sep 2018 15:18:10 +0200, Stefan Wahren wrote: > > Hi Takashi, > > > Takashi Iwai hat am 4. September 2018 um 17:58 geschrieben: > > > > > > Hi, > > > > since I had an opportunity to play with RPi3B+ recently, I took a look > > at the existing bcm2835-audio driver code and was amused very much :) > > > > So here is the result, a cleanup and fix patch series. > > > > Most of the patches are trivial cleanups, just brushing up, removing > > many redundant and buggy codes, as well as code simplifications. > > > > A big functional change is that now it uses non-atomic PCM ops, so > > that we can kill the ugly workqueue usages. Also, the resource > > management was simplified. > > first of all, thank you very much for this series. > > Eric has no time as maintainer, so i will try to give you some feedback > (beware of very little audio driver knowledge). > > I functionally tested your patch series on a Raspberry Pi 1 B > (bcm2835_defconfig), so this whole series is at least: > > Tested-by: Stefan Wahren OK, thanks, I'll put to my series in case of resubmission. Meanwhile I'll keep the series in topic/vc04 branch of sound.git tree. > Unfortunately there is still an corruption issue with underlying vchiq and > multi_v7_defconfig, so no wider tests. What is this corruption issue? > I don't know if you tested this series on a Raspberry Pi. Maybe you have some > specific scenarios, which should be tested. I have only a RPi3B+, and that's all what I've tested. It'd be great if the patch series could be tested in a wider range of models, of course. The patches are only about cleanups. They corrected the bad usages of audio APIs and its design, but basically I haven't touched the basic functionality intentionally at all. So the behavior should be kept as before. (Actually it'd be better to revisit the design later, especially about the multi-cards option and the PCM route mixer control, but I left as is for compatibility reason for now.) > As a reviewer i have some suggestions, but only trivia. I don't know if it's > a problem that this series hasn't been send to de...@driverdev.osuosl.org No, it's just because that address isn't found in MAINTAINERS file. If it should go through it, please correct the entry at first :) Thanks! Takashi
Re: [PATCH 03/29] staging: bcm2835-audio: Clean up include files in bcm2835-ctl.c
On Sat, 08 Sep 2018 15:25:14 +0200, Stefan Wahren wrote: > > Hi, > > > Takashi Iwai hat am 4. September 2018 um 17:58 geschrieben: > > > > > > Only a few of them are really needed. > > > > Signed-off-by: Takashi Iwai > > --- > > .../vc04_services/bcm2835-audio/bcm2835-ctl.c | 15 --- > > I think this patch and patch #23 could be merge in case a new series is > required. OK, will do. thanks, Takashi
Re: [PATCH 03/29] staging: bcm2835-audio: Clean up include files in bcm2835-ctl.c
On Sat, 08 Sep 2018 15:25:14 +0200, Stefan Wahren wrote: > > Hi, > > > Takashi Iwai hat am 4. September 2018 um 17:58 geschrieben: > > > > > > Only a few of them are really needed. > > > > Signed-off-by: Takashi Iwai > > --- > > .../vc04_services/bcm2835-audio/bcm2835-ctl.c | 15 --- > > I think this patch and patch #23 could be merge in case a new series is > required. OK, will do. thanks, Takashi
Re: [PATCH 16/29] staging: bcm2835-audio: Drop superfluous mutex lock during prepare
On Sat, 08 Sep 2018 15:40:41 +0200, Stefan Wahren wrote: > > Hi, > > > Takashi Iwai hat am 4. September 2018 um 17:58 geschrieben: > > > > > > The chip->audio_mutex is used basically for protecting the opened > > stream assignment, and the prepare callback is irrelevant with it. > > > > Signed-off-by: Takashi Iwai > > --- > > drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c | 8 ++-- > > 1 file changed, 2 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c > > b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c > > index 1f9c940f1cc3..9659c25b9f9d 100644 > > --- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c > > +++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c > > @@ -218,8 +218,6 @@ static int snd_bcm2835_pcm_prepare(struct > > snd_pcm_substream *substream) > > int channels; > > int err; > > > > - mutex_lock(>audio_mutex); > > - > > /* notify the vchiq that it should enter spdif passthrough mode by > > * setting channels=0 (see > > * https://github.com/raspberrypi/linux/issues/528) > > @@ -233,7 +231,7 @@ static int snd_bcm2835_pcm_prepare(struct > > snd_pcm_substream *substream) > >runtime->rate, > >snd_pcm_format_width(runtime->format)); > > if (err < 0) > > - goto out; > > + return err; > > > > memset(_stream->pcm_indirect, 0, > > sizeof(alsa_stream->pcm_indirect)); > > > > @@ -246,9 +244,7 @@ static int snd_bcm2835_pcm_prepare(struct > > snd_pcm_substream *substream) > > alsa_stream->pos = 0; > > alsa_stream->draining = false; > > > > - out: > > - mutex_unlock(>audio_mutex); > > - return err; > > + return 0; > > looks like your are removing code which has been added in patch #14 ? No, the patch #14 corrects the missing error path. Without patch 14, the error from prepare is ignored. And this patch gets rid of the superfluous mutex lock. thanks, Takashi
Re: [PATCH 16/29] staging: bcm2835-audio: Drop superfluous mutex lock during prepare
On Sat, 08 Sep 2018 15:40:41 +0200, Stefan Wahren wrote: > > Hi, > > > Takashi Iwai hat am 4. September 2018 um 17:58 geschrieben: > > > > > > The chip->audio_mutex is used basically for protecting the opened > > stream assignment, and the prepare callback is irrelevant with it. > > > > Signed-off-by: Takashi Iwai > > --- > > drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c | 8 ++-- > > 1 file changed, 2 insertions(+), 6 deletions(-) > > > > diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c > > b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c > > index 1f9c940f1cc3..9659c25b9f9d 100644 > > --- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c > > +++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c > > @@ -218,8 +218,6 @@ static int snd_bcm2835_pcm_prepare(struct > > snd_pcm_substream *substream) > > int channels; > > int err; > > > > - mutex_lock(>audio_mutex); > > - > > /* notify the vchiq that it should enter spdif passthrough mode by > > * setting channels=0 (see > > * https://github.com/raspberrypi/linux/issues/528) > > @@ -233,7 +231,7 @@ static int snd_bcm2835_pcm_prepare(struct > > snd_pcm_substream *substream) > >runtime->rate, > >snd_pcm_format_width(runtime->format)); > > if (err < 0) > > - goto out; > > + return err; > > > > memset(_stream->pcm_indirect, 0, > > sizeof(alsa_stream->pcm_indirect)); > > > > @@ -246,9 +244,7 @@ static int snd_bcm2835_pcm_prepare(struct > > snd_pcm_substream *substream) > > alsa_stream->pos = 0; > > alsa_stream->draining = false; > > > > - out: > > - mutex_unlock(>audio_mutex); > > - return err; > > + return 0; > > looks like your are removing code which has been added in patch #14 ? No, the patch #14 corrects the missing error path. Without patch 14, the error from prepare is ignored. And this patch gets rid of the superfluous mutex lock. thanks, Takashi
Re: + mm-slab-shorten-kmalloc-cache-names-for-large-sizes.patch added to -mm tree
On 09/08/2018 08:54 AM, Matthew Wilcox wrote:
> On Sat, Sep 08, 2018 at 10:03:06AM -0400, Johannes Weiner wrote:
>> On Fri, Sep 07, 2018 at 10:58:16PM +0300, Alexey Dobriyan wrote:
>>> On Thu, Sep 06, 2018 at 03:48:49PM -0700, a...@linux-foundation.org wrote:
- {"kmalloc-1024", 1024}, {"kmalloc-2048", 2048},
- {"kmalloc-4096", 4096}, {"kmalloc-8192", 8192},
- {"kmalloc-16384", 16384}, {"kmalloc-32768", 32768},
- {"kmalloc-65536", 65536}, {"kmalloc-131072", 131072},
- {"kmalloc-262144", 262144}, {"kmalloc-524288", 524288},
- {"kmalloc-1048576", 1048576}, {"kmalloc-2097152", 2097152},
- {"kmalloc-4194304", 4194304}, {"kmalloc-8388608", 8388608},
- {"kmalloc-16777216", 16777216}, {"kmalloc-33554432", 33554432},
- {"kmalloc-67108864", 67108864}
+ {"kmalloc-1k", 1024}, {"kmalloc-2k", 2048},
+ {"kmalloc-4k", 4096}, {"kmalloc-8k", 8192},
+ {"kmalloc-16k", 16384}, {"kmalloc-32k", 32768},
+ {"kmalloc-64k", 65536}, {"kmalloc-128k", 131072},
+ {"kmalloc-256k", 262144}, {"kmalloc-512k", 524288},
+ {"kmalloc-1M",1048576}, {"kmalloc-2M",2097152},
+ {"kmalloc-4M",4194304}, {"kmalloc-8M",8388608},
+ {"kmalloc-16M", 16777216}, {"kmalloc-32M", 33554432},
+ {"kmalloc-64M", 67108864}
>>>
>>> I'd rather use KB and MB suffixes or at least capital 'K'.
>>
>> I like k and M better.
>
> k and M work for me too. It we were going to be anal then we should
> go with the IEC standard of KiB and MiB, but we're trying to make
But ^K and ^M.
Small 'k' .. I don't know what that is.
> /proc/slabinfo a little less ugly, and so we have 16 characters to work
> with. "dma-kmalloc-256KiB" is 18 characters. The obvious place to lose
> two characters is the "iB" which are implicit; we know we're measuring
> bytes and the binary nature is assumed in this context of memory bytes
> (not storage bytes). "dma-kmalloc-256k" is better.
>
--
~Randy
Re: + mm-slab-shorten-kmalloc-cache-names-for-large-sizes.patch added to -mm tree
On 09/08/2018 08:54 AM, Matthew Wilcox wrote:
> On Sat, Sep 08, 2018 at 10:03:06AM -0400, Johannes Weiner wrote:
>> On Fri, Sep 07, 2018 at 10:58:16PM +0300, Alexey Dobriyan wrote:
>>> On Thu, Sep 06, 2018 at 03:48:49PM -0700, a...@linux-foundation.org wrote:
- {"kmalloc-1024", 1024}, {"kmalloc-2048", 2048},
- {"kmalloc-4096", 4096}, {"kmalloc-8192", 8192},
- {"kmalloc-16384", 16384}, {"kmalloc-32768", 32768},
- {"kmalloc-65536", 65536}, {"kmalloc-131072", 131072},
- {"kmalloc-262144", 262144}, {"kmalloc-524288", 524288},
- {"kmalloc-1048576", 1048576}, {"kmalloc-2097152", 2097152},
- {"kmalloc-4194304", 4194304}, {"kmalloc-8388608", 8388608},
- {"kmalloc-16777216", 16777216}, {"kmalloc-33554432", 33554432},
- {"kmalloc-67108864", 67108864}
+ {"kmalloc-1k", 1024}, {"kmalloc-2k", 2048},
+ {"kmalloc-4k", 4096}, {"kmalloc-8k", 8192},
+ {"kmalloc-16k", 16384}, {"kmalloc-32k", 32768},
+ {"kmalloc-64k", 65536}, {"kmalloc-128k", 131072},
+ {"kmalloc-256k", 262144}, {"kmalloc-512k", 524288},
+ {"kmalloc-1M",1048576}, {"kmalloc-2M",2097152},
+ {"kmalloc-4M",4194304}, {"kmalloc-8M",8388608},
+ {"kmalloc-16M", 16777216}, {"kmalloc-32M", 33554432},
+ {"kmalloc-64M", 67108864}
>>>
>>> I'd rather use KB and MB suffixes or at least capital 'K'.
>>
>> I like k and M better.
>
> k and M work for me too. It we were going to be anal then we should
> go with the IEC standard of KiB and MiB, but we're trying to make
But ^K and ^M.
Small 'k' .. I don't know what that is.
> /proc/slabinfo a little less ugly, and so we have 16 characters to work
> with. "dma-kmalloc-256KiB" is 18 characters. The obvious place to lose
> two characters is the "iB" which are implicit; we know we're measuring
> bytes and the binary nature is assumed in this context of memory bytes
> (not storage bytes). "dma-kmalloc-256k" is better.
>
--
~Randy
Re: + mm-slab-shorten-kmalloc-cache-names-for-large-sizes.patch added to -mm tree
On Sat, Sep 08, 2018 at 10:03:06AM -0400, Johannes Weiner wrote:
> On Fri, Sep 07, 2018 at 10:58:16PM +0300, Alexey Dobriyan wrote:
> > On Thu, Sep 06, 2018 at 03:48:49PM -0700, a...@linux-foundation.org wrote:
> > > - {"kmalloc-1024", 1024}, {"kmalloc-2048", 2048},
> > > - {"kmalloc-4096", 4096}, {"kmalloc-8192", 8192},
> > > - {"kmalloc-16384", 16384}, {"kmalloc-32768", 32768},
> > > - {"kmalloc-65536", 65536}, {"kmalloc-131072", 131072},
> > > - {"kmalloc-262144", 262144}, {"kmalloc-524288", 524288},
> > > - {"kmalloc-1048576", 1048576}, {"kmalloc-2097152", 2097152},
> > > - {"kmalloc-4194304", 4194304}, {"kmalloc-8388608", 8388608},
> > > - {"kmalloc-16777216", 16777216}, {"kmalloc-33554432", 33554432},
> > > - {"kmalloc-67108864", 67108864}
> > > + {"kmalloc-1k", 1024}, {"kmalloc-2k", 2048},
> > > + {"kmalloc-4k", 4096}, {"kmalloc-8k", 8192},
> > > + {"kmalloc-16k", 16384}, {"kmalloc-32k", 32768},
> > > + {"kmalloc-64k", 65536}, {"kmalloc-128k", 131072},
> > > + {"kmalloc-256k", 262144}, {"kmalloc-512k", 524288},
> > > + {"kmalloc-1M",1048576}, {"kmalloc-2M",2097152},
> > > + {"kmalloc-4M",4194304}, {"kmalloc-8M",8388608},
> > > + {"kmalloc-16M", 16777216}, {"kmalloc-32M", 33554432},
> > > + {"kmalloc-64M", 67108864}
> >
> > I'd rather use KB and MB suffixes or at least capital 'K'.
>
> I like k and M better.
k and M work for me too. It we were going to be anal then we should
go with the IEC standard of KiB and MiB, but we're trying to make
/proc/slabinfo a little less ugly, and so we have 16 characters to work
with. "dma-kmalloc-256KiB" is 18 characters. The obvious place to lose
two characters is the "iB" which are implicit; we know we're measuring
bytes and the binary nature is assumed in this context of memory bytes
(not storage bytes). "dma-kmalloc-256k" is better.
Re: + mm-slab-shorten-kmalloc-cache-names-for-large-sizes.patch added to -mm tree
On Sat, Sep 08, 2018 at 10:03:06AM -0400, Johannes Weiner wrote:
> On Fri, Sep 07, 2018 at 10:58:16PM +0300, Alexey Dobriyan wrote:
> > On Thu, Sep 06, 2018 at 03:48:49PM -0700, a...@linux-foundation.org wrote:
> > > - {"kmalloc-1024", 1024}, {"kmalloc-2048", 2048},
> > > - {"kmalloc-4096", 4096}, {"kmalloc-8192", 8192},
> > > - {"kmalloc-16384", 16384}, {"kmalloc-32768", 32768},
> > > - {"kmalloc-65536", 65536}, {"kmalloc-131072", 131072},
> > > - {"kmalloc-262144", 262144}, {"kmalloc-524288", 524288},
> > > - {"kmalloc-1048576", 1048576}, {"kmalloc-2097152", 2097152},
> > > - {"kmalloc-4194304", 4194304}, {"kmalloc-8388608", 8388608},
> > > - {"kmalloc-16777216", 16777216}, {"kmalloc-33554432", 33554432},
> > > - {"kmalloc-67108864", 67108864}
> > > + {"kmalloc-1k", 1024}, {"kmalloc-2k", 2048},
> > > + {"kmalloc-4k", 4096}, {"kmalloc-8k", 8192},
> > > + {"kmalloc-16k", 16384}, {"kmalloc-32k", 32768},
> > > + {"kmalloc-64k", 65536}, {"kmalloc-128k", 131072},
> > > + {"kmalloc-256k", 262144}, {"kmalloc-512k", 524288},
> > > + {"kmalloc-1M",1048576}, {"kmalloc-2M",2097152},
> > > + {"kmalloc-4M",4194304}, {"kmalloc-8M",8388608},
> > > + {"kmalloc-16M", 16777216}, {"kmalloc-32M", 33554432},
> > > + {"kmalloc-64M", 67108864}
> >
> > I'd rather use KB and MB suffixes or at least capital 'K'.
>
> I like k and M better.
k and M work for me too. It we were going to be anal then we should
go with the IEC standard of KiB and MiB, but we're trying to make
/proc/slabinfo a little less ugly, and so we have 16 characters to work
with. "dma-kmalloc-256KiB" is 18 characters. The obvious place to lose
two characters is the "iB" which are implicit; we know we're measuring
bytes and the binary nature is assumed in this context of memory bytes
(not storage bytes). "dma-kmalloc-256k" is better.
Re: INFO: task hung in __blkdev_get (2)
This report contains "getblk(): executed=9 bh_count=0 bh_state=0" lines. Thus, #syz dup: INFO: task hung in generic_file_write_iter
Re: INFO: task hung in __blkdev_get (2)
This report contains "getblk(): executed=9 bh_count=0 bh_state=0" lines. Thus, #syz dup: INFO: task hung in generic_file_write_iter
INFO: task hung in __blkdev_get (2)
Hello,
syzbot found the following crash on:
HEAD commit:b50694381cfc Merge branch 'stable/for-linus-4.17' of git:/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=166708d780
kernel config: https://syzkaller.appspot.com/x/.config?x=982e2df1b9e60b02
dashboard link: https://syzkaller.appspot.com/bug?extid=2a732b5a87000875c1f3
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2a732b5a87000875c...@syzkaller.appspotmail.com
binder: 17633:17652 ioctl c0306201 20007000 returned -22
INFO: task syz-executor0:17586 blocked for more than 120 seconds.
Not tainted 4.17.0-rc6+ #66
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor0 D22720 17586 16831 0x0004
Call Trace:
context_switch kernel/sched/core.c:2859 [inline]
__schedule+0x801/0x1e30 kernel/sched/core.c:3501
schedule+0xef/0x430 kernel/sched/core.c:3545
schedule_preempt_disabled+0x10/0x20 kernel/sched/core.c:3603
__mutex_lock_common kernel/locking/mutex.c:833 [inline]
__mutex_lock+0xe38/0x17f0 kernel/locking/mutex.c:893
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
__blkdev_get+0x193/0x13a0 fs/block_dev.c:1460
blkdev_get+0xb9/0xb30 fs/block_dev.c:1611
blkdev_get_by_dev+0x3f/0x80 fs/block_dev.c:1733
journal_init_dev fs/reiserfs/journal.c:2625 [inline]
journal_init+0xcad/0x6a20 fs/reiserfs/journal.c:2772
reiserfs_fill_super+0xd59/0x3900 fs/reiserfs/super.c:2034
mount_bdev+0x30c/0x3e0 fs/super.c:1174
get_super_block+0x34/0x40 fs/reiserfs/super.c:2605
mount_fs+0xae/0x328 fs/super.c:1277
vfs_kern_mount.part.34+0xd4/0x4d0 fs/namespace.c:1037
vfs_kern_mount fs/namespace.c:1027 [inline]
do_new_mount fs/namespace.c:2518 [inline]
do_mount+0x564/0x3070 fs/namespace.c:2848
ksys_mount+0x12d/0x140 fs/namespace.c:3064
__do_sys_mount fs/namespace.c:3078 [inline]
__se_sys_mount fs/namespace.c:3075 [inline]
__x64_sys_mount+0xbe/0x150 fs/namespace.c:3075
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x45843a
RSP: 002b:7fc481e97ba8 EFLAGS: 0202 ORIG_RAX: 00a5
RAX: ffda RBX: 2000 RCX: 0045843a
RDX: 2000 RSI: 2100 RDI: 7fc481e97bf0
RBP: 0001 R08: 20013900 R09: 2000
R10: R11: 0202 R12: 0019
R13: 0001 R14: 006fed68 R15:
Showing all locks held in the system:
2 locks held by khungtaskd/894:
#0: 555ac416 (rcu_read_lock){}, at:
check_hung_uninterruptible_tasks kernel/hung_task.c:175 [inline]
#0: 555ac416 (rcu_read_lock){}, at: watchdog+0x1ff/0xf60
kernel/hung_task.c:249
#1: dd73bdbb (tasklist_lock){.+.+}, at:
debug_show_all_locks+0xde/0x34a kernel/locking/lockdep.c:4470
1 lock held by rsyslogd/4380:
#0: ca6266dd (>f_pos_lock){+.+.}, at: __fdget_pos+0x1a9/0x1e0
fs/file.c:766
2 locks held by getty/4470:
#0: 1d015e21 (>ldisc_sem){}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 0d332adb (>atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4471:
#0: 48bf8be6 (>ldisc_sem){}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 23f3c5d7 (>atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4472:
#0: 6b8ddf0c (>ldisc_sem){}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 61b8fb1b (>atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4473:
#0: 7a3e9951 (>ldisc_sem){}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: cc33e1ac (>atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4474:
#0: d4d7bced (>ldisc_sem){}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: cea9fd89 (>atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4475:
#0: c455607f (>ldisc_sem){}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 74a85a34 (>atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4476:
#0: 0dda4794 (>ldisc_sem){}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 96899971 (>atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by syz-executor0/17586:
#0: a67274d0 (>s_umount_key#20/1){+.+.}, at: alloc_super
fs/super.c:223 [inline]
#0: a67274d0 (>s_umount_key#20/1){+.+.}, at:
sget_userns+0x2dd/0xf00
INFO: task hung in __blkdev_get (2)
Hello,
syzbot found the following crash on:
HEAD commit:b50694381cfc Merge branch 'stable/for-linus-4.17' of git:/..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=166708d780
kernel config: https://syzkaller.appspot.com/x/.config?x=982e2df1b9e60b02
dashboard link: https://syzkaller.appspot.com/bug?extid=2a732b5a87000875c1f3
compiler: gcc (GCC) 8.0.1 20180413 (experimental)
Unfortunately, I don't have any reproducer for this crash yet.
IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+2a732b5a87000875c...@syzkaller.appspotmail.com
binder: 17633:17652 ioctl c0306201 20007000 returned -22
INFO: task syz-executor0:17586 blocked for more than 120 seconds.
Not tainted 4.17.0-rc6+ #66
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
syz-executor0 D22720 17586 16831 0x0004
Call Trace:
context_switch kernel/sched/core.c:2859 [inline]
__schedule+0x801/0x1e30 kernel/sched/core.c:3501
schedule+0xef/0x430 kernel/sched/core.c:3545
schedule_preempt_disabled+0x10/0x20 kernel/sched/core.c:3603
__mutex_lock_common kernel/locking/mutex.c:833 [inline]
__mutex_lock+0xe38/0x17f0 kernel/locking/mutex.c:893
mutex_lock_nested+0x16/0x20 kernel/locking/mutex.c:908
__blkdev_get+0x193/0x13a0 fs/block_dev.c:1460
blkdev_get+0xb9/0xb30 fs/block_dev.c:1611
blkdev_get_by_dev+0x3f/0x80 fs/block_dev.c:1733
journal_init_dev fs/reiserfs/journal.c:2625 [inline]
journal_init+0xcad/0x6a20 fs/reiserfs/journal.c:2772
reiserfs_fill_super+0xd59/0x3900 fs/reiserfs/super.c:2034
mount_bdev+0x30c/0x3e0 fs/super.c:1174
get_super_block+0x34/0x40 fs/reiserfs/super.c:2605
mount_fs+0xae/0x328 fs/super.c:1277
vfs_kern_mount.part.34+0xd4/0x4d0 fs/namespace.c:1037
vfs_kern_mount fs/namespace.c:1027 [inline]
do_new_mount fs/namespace.c:2518 [inline]
do_mount+0x564/0x3070 fs/namespace.c:2848
ksys_mount+0x12d/0x140 fs/namespace.c:3064
__do_sys_mount fs/namespace.c:3078 [inline]
__se_sys_mount fs/namespace.c:3075 [inline]
__x64_sys_mount+0xbe/0x150 fs/namespace.c:3075
do_syscall_64+0x1b1/0x800 arch/x86/entry/common.c:287
entry_SYSCALL_64_after_hwframe+0x49/0xbe
RIP: 0033:0x45843a
RSP: 002b:7fc481e97ba8 EFLAGS: 0202 ORIG_RAX: 00a5
RAX: ffda RBX: 2000 RCX: 0045843a
RDX: 2000 RSI: 2100 RDI: 7fc481e97bf0
RBP: 0001 R08: 20013900 R09: 2000
R10: R11: 0202 R12: 0019
R13: 0001 R14: 006fed68 R15:
Showing all locks held in the system:
2 locks held by khungtaskd/894:
#0: 555ac416 (rcu_read_lock){}, at:
check_hung_uninterruptible_tasks kernel/hung_task.c:175 [inline]
#0: 555ac416 (rcu_read_lock){}, at: watchdog+0x1ff/0xf60
kernel/hung_task.c:249
#1: dd73bdbb (tasklist_lock){.+.+}, at:
debug_show_all_locks+0xde/0x34a kernel/locking/lockdep.c:4470
1 lock held by rsyslogd/4380:
#0: ca6266dd (>f_pos_lock){+.+.}, at: __fdget_pos+0x1a9/0x1e0
fs/file.c:766
2 locks held by getty/4470:
#0: 1d015e21 (>ldisc_sem){}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 0d332adb (>atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4471:
#0: 48bf8be6 (>ldisc_sem){}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 23f3c5d7 (>atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4472:
#0: 6b8ddf0c (>ldisc_sem){}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 61b8fb1b (>atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4473:
#0: 7a3e9951 (>ldisc_sem){}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: cc33e1ac (>atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4474:
#0: d4d7bced (>ldisc_sem){}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: cea9fd89 (>atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4475:
#0: c455607f (>ldisc_sem){}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 74a85a34 (>atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by getty/4476:
#0: 0dda4794 (>ldisc_sem){}, at:
ldsem_down_read+0x37/0x40 drivers/tty/tty_ldsem.c:365
#1: 96899971 (>atomic_read_lock){+.+.}, at:
n_tty_read+0x321/0x1cc0 drivers/tty/n_tty.c:2131
2 locks held by syz-executor0/17586:
#0: a67274d0 (>s_umount_key#20/1){+.+.}, at: alloc_super
fs/super.c:223 [inline]
#0: a67274d0 (>s_umount_key#20/1){+.+.}, at:
sget_userns+0x2dd/0xf00
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Marcel Holtmann wrote: > so I have reviewed and tested this code. In addition, we have test cases for > it in ELL (embedded linux library). I wonder if there's any practical way to add a test for this to the keyutils test suite. I'm guessing it's quite tricky, given the extra bits you need to emulate the TPM. David
Re: [PATCH 00/22] KEYS: Support TPM-wrapped key and crypto ops
Marcel Holtmann wrote: > so I have reviewed and tested this code. In addition, we have test cases for > it in ELL (embedded linux library). I wonder if there's any practical way to add a test for this to the keyutils test suite. I'm guessing it's quite tricky, given the extra bits you need to emulate the TPM. David
Re: Regression in next with filesystem context concept
Tony Lindgren wrote:
> > > Looks like next-20180906 now has a regression where mounting
> > > root won't work with commit fd0002870b45 ("vfs: Implement a
> > > filesystem superblock creation/configuration context").
> >
> > Am I right in thinking you're not using any of the LSMs?
>
> Assuming LSM as in Documentation/lsm.txt, right not using any.
The default return value for security_fs_context_parse_param() should be
-ENOPARAM, both in security.h and security.c.
I've fixed my tree and Al has pulled it, but we're now waiting on Stephen
Rothwell to refresh linux/next.
David
Re: Regression in next with filesystem context concept
Tony Lindgren wrote:
> > > Looks like next-20180906 now has a regression where mounting
> > > root won't work with commit fd0002870b45 ("vfs: Implement a
> > > filesystem superblock creation/configuration context").
> >
> > Am I right in thinking you're not using any of the LSMs?
>
> Assuming LSM as in Documentation/lsm.txt, right not using any.
The default return value for security_fs_context_parse_param() should be
-ENOPARAM, both in security.h and security.c.
I've fixed my tree and Al has pulled it, but we're now waiting on Stephen
Rothwell to refresh linux/next.
David
Re: BUG: bad usercopy in __check_object_size (2)
On Fri, Sep 7, 2018 at 9:57 PM, Kees Cook wrote: > On Fri, Sep 7, 2018 at 9:17 AM, Tetsuo Handa > wrote: >> On 2018/09/08 0:29, syzbot wrote: >>> syzbot has found a reproducer for the following crash on: >>> >>> HEAD commit:28619527b8a7 Merge git://git.kernel.org/pub/scm/linux/kern.. >>> git tree: bpf >>> console output: https://syzkaller.appspot.com/x/log.txt?x=124e64d140 >>> kernel config: https://syzkaller.appspot.com/x/.config?x=62e9b447c16085cf >>> dashboard link: https://syzkaller.appspot.com/bug?extid=a3c9d2673837ccc0f22b >>> compiler: gcc (GCC) 8.0.1 20180413 (experimental) >>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=179f9cd140 >>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11b3e8be40 >>> >>> IMPORTANT: if you fix the bug, please add the following tag to the commit: >>> Reported-by: syzbot+a3c9d2673837ccc0f...@syzkaller.appspotmail.com >>> >>> entry_SYSCALL_64_after_hwframe+0x49/0xbe >>> RIP: 0033:0x440479 >>> usercopy: Kernel memory overwrite attempt detected to spans multiple pages >>> (offset 0, size 64)! >> >> Kees, is this because check_page_span() is failing to allow on-stack variable >> >>u8 opcodes[OPCODE_BUFSIZE]; >> >> which by chance crossed PAGE_SIZE boundary? > > There are a lot of failure conditions for the PAGESPAN check. This > might be one (and one that I'm hoping to solve separately). Disabled CONFIG_HARDENED_USERCOPY_PAGESPAN on syzbot: https://github.com/google/syzkaller/commit/be20da425029ecd45b18e99fa5f09691ba0658ea #syz invalid
Re: BUG: bad usercopy in __check_object_size (2)
On Fri, Sep 7, 2018 at 9:57 PM, Kees Cook wrote: > On Fri, Sep 7, 2018 at 9:17 AM, Tetsuo Handa > wrote: >> On 2018/09/08 0:29, syzbot wrote: >>> syzbot has found a reproducer for the following crash on: >>> >>> HEAD commit:28619527b8a7 Merge git://git.kernel.org/pub/scm/linux/kern.. >>> git tree: bpf >>> console output: https://syzkaller.appspot.com/x/log.txt?x=124e64d140 >>> kernel config: https://syzkaller.appspot.com/x/.config?x=62e9b447c16085cf >>> dashboard link: https://syzkaller.appspot.com/bug?extid=a3c9d2673837ccc0f22b >>> compiler: gcc (GCC) 8.0.1 20180413 (experimental) >>> syz repro: https://syzkaller.appspot.com/x/repro.syz?x=179f9cd140 >>> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=11b3e8be40 >>> >>> IMPORTANT: if you fix the bug, please add the following tag to the commit: >>> Reported-by: syzbot+a3c9d2673837ccc0f...@syzkaller.appspotmail.com >>> >>> entry_SYSCALL_64_after_hwframe+0x49/0xbe >>> RIP: 0033:0x440479 >>> usercopy: Kernel memory overwrite attempt detected to spans multiple pages >>> (offset 0, size 64)! >> >> Kees, is this because check_page_span() is failing to allow on-stack variable >> >>u8 opcodes[OPCODE_BUFSIZE]; >> >> which by chance crossed PAGE_SIZE boundary? > > There are a lot of failure conditions for the PAGESPAN check. This > might be one (and one that I'm hoping to solve separately). Disabled CONFIG_HARDENED_USERCOPY_PAGESPAN on syzbot: https://github.com/google/syzkaller/commit/be20da425029ecd45b18e99fa5f09691ba0658ea #syz invalid
Re: [PATCH] rtc: abx80x: add basic watchdog support
Hi,
Please Cc the watchdog maintainers. Else, I have very few comments.
On 07/09/2018 09:17:43-0600, Jeremy Gebben wrote:
> The abx804 and abx805 chips have support for a simple watchdog
> function that can trigger an external reset.
>
> Signed-off-by: Jeremy Gebben
> ---
> drivers/rtc/Kconfig | 11 +++
> drivers/rtc/rtc-abx80x.c | 160 ---
> 2 files changed, 159 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 7d7be60a2413..4771e3a89721 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -195,6 +195,17 @@ config RTC_DRV_ABX80X
> This driver can also be built as a module. If so, the module
> will be called rtc-abx80x.
>
> +config RTC_DRV_ABX80X_WDT
> + bool "Abracon ABx80x Watchdog"
> + default y
> + depends on RTC_DRV_ABX80X
> + help
> + If you say yes here you get watchdog support for Abracon ABX804 and
> ABX805
> + clock chips. This watchdog supports timeouts up to 31 seconds with 1
> second
> + granularity.
> +
> + This watchdog device is part of the rtc-abx80x module.
> +
I'm not sure it is worth having a separate config option for that. You
may as well just always include the watchdog support code. However,
doesn't it need to depend on CONFIG_WATCHDOG?
> config RTC_DRV_AC100
> tristate "X-Powers AC100"
> depends on MFD_AC100
> diff --git a/drivers/rtc/rtc-abx80x.c b/drivers/rtc/rtc-abx80x.c
> index 2cefa67a1132..fa558939e944 100644
> --- a/drivers/rtc/rtc-abx80x.c
> +++ b/drivers/rtc/rtc-abx80x.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
>
> #define ABX8XX_REG_HTH 0x00
> #define ABX8XX_REG_SC0x01
> @@ -37,6 +38,7 @@
>
> #define ABX8XX_REG_STATUS0x0f
> #define ABX8XX_STATUS_AF BIT(2)
> +#define ABX8XX_STATUS_WDTBIT(6)
>
> #define ABX8XX_REG_CTRL1 0x10
> #define ABX8XX_CTRL_WRITEBIT(0)
> @@ -61,6 +63,14 @@
> #define ABX8XX_OSS_OFBIT(1)
> #define ABX8XX_OSS_OMODE BIT(4)
>
> +#define ABX8XX_REG_WDT 0x1b
> +#define ABX8XX_WDT_WDS BIT(7)
> +#define ABX8XX_WDT_BMB_MASK 0x7c
> +#define ABX8XX_WDT_BMB_SHIFT 2
> +#define ABX8XX_WDT_MAX_TIME (ABX8XX_WDT_BMB_MASK >> ABX8XX_WDT_BMB_SHIFT)
> +#define ABX8XX_WDT_WRB_MASK 0x03
> +#define ABX8XX_WDT_WRB_1HZ 0x02
> +
> #define ABX8XX_REG_CFG_KEY 0x1f
> #define ABX8XX_CFG_KEY_OSC 0xa1
> #define ABX8XX_CFG_KEY_MISC 0x9d
> @@ -80,20 +90,27 @@ enum abx80x_chip {AB0801, AB0803, AB0804, AB0805,
> struct abx80x_cap {
> u16 pn;
> bool has_tc;
> + bool has_wdog;
> };
>
> static struct abx80x_cap abx80x_caps[] = {
> [AB0801] = {.pn = 0x0801},
> [AB0803] = {.pn = 0x0803},
> - [AB0804] = {.pn = 0x0804, .has_tc = true},
> - [AB0805] = {.pn = 0x0805, .has_tc = true},
> + [AB0804] = {.pn = 0x0804, .has_tc = true, .has_wdog = true},
> + [AB0805] = {.pn = 0x0805, .has_tc = true, .has_wdog = true},
> [AB1801] = {.pn = 0x1801},
> [AB1803] = {.pn = 0x1803},
> - [AB1804] = {.pn = 0x1804, .has_tc = true},
> - [AB1805] = {.pn = 0x1805, .has_tc = true},
> + [AB1804] = {.pn = 0x1804, .has_tc = true, .has_wdog = true},
> + [AB1805] = {.pn = 0x1805, .has_tc = true, .has_wdog = true},
> [ABX80X] = {.pn = 0}
> };
>
> +struct abx80x_priv {
> + struct rtc_device *rtc;
> + struct i2c_client *client;
> + struct watchdog_device wdog;
> +};
> +
To make the watchdog part easier to review, you could separate the
introduction of abx80x_priv in a preliminary patch and then introduce
the watchdog code.
> static int abx80x_is_rc_mode(struct i2c_client *client)
> {
> int flags = 0;
> @@ -218,7 +235,8 @@ static int abx80x_rtc_set_time(struct device *dev, struct
> rtc_time *tm)
> static irqreturn_t abx80x_handle_irq(int irq, void *dev_id)
> {
> struct i2c_client *client = dev_id;
> - struct rtc_device *rtc = i2c_get_clientdata(client);
> + struct abx80x_priv *priv = i2c_get_clientdata(client);
> + struct rtc_device *rtc = priv->rtc;
> int status;
>
> status = i2c_smbus_read_byte_data(client, ABX8XX_REG_STATUS);
> @@ -228,6 +246,13 @@ static irqreturn_t abx80x_handle_irq(int irq, void
> *dev_id)
> if (status & ABX8XX_STATUS_AF)
> rtc_update_irq(rtc, 1, RTC_AF | RTC_IRQF);
>
> + /*
> + * It is unclear if we'll get an interrupt before the external
> + * reset kicks in.
> + */
> + if (status & ABX8XX_STATUS_WDT)
> + dev_err(>dev, "watchdog timeout interrupt!\n");
> +
dev_alert maybe?
> i2c_smbus_write_byte_data(client, ABX8XX_REG_STATUS, 0);
>
> return IRQ_HANDLED;
> @@ -529,11 +554,110 @@ static void rtc_calib_remove_sysfs_group(void *_dev)
> sysfs_remove_group(>kobj, _calib_attr_group);
> }
>
> +#ifdef CONFIG_RTC_DRV_ABX80X_WDT
> +
> +static inline
Re: [PATCH] rtc: abx80x: add basic watchdog support
Hi,
Please Cc the watchdog maintainers. Else, I have very few comments.
On 07/09/2018 09:17:43-0600, Jeremy Gebben wrote:
> The abx804 and abx805 chips have support for a simple watchdog
> function that can trigger an external reset.
>
> Signed-off-by: Jeremy Gebben
> ---
> drivers/rtc/Kconfig | 11 +++
> drivers/rtc/rtc-abx80x.c | 160 ---
> 2 files changed, 159 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 7d7be60a2413..4771e3a89721 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -195,6 +195,17 @@ config RTC_DRV_ABX80X
> This driver can also be built as a module. If so, the module
> will be called rtc-abx80x.
>
> +config RTC_DRV_ABX80X_WDT
> + bool "Abracon ABx80x Watchdog"
> + default y
> + depends on RTC_DRV_ABX80X
> + help
> + If you say yes here you get watchdog support for Abracon ABX804 and
> ABX805
> + clock chips. This watchdog supports timeouts up to 31 seconds with 1
> second
> + granularity.
> +
> + This watchdog device is part of the rtc-abx80x module.
> +
I'm not sure it is worth having a separate config option for that. You
may as well just always include the watchdog support code. However,
doesn't it need to depend on CONFIG_WATCHDOG?
> config RTC_DRV_AC100
> tristate "X-Powers AC100"
> depends on MFD_AC100
> diff --git a/drivers/rtc/rtc-abx80x.c b/drivers/rtc/rtc-abx80x.c
> index 2cefa67a1132..fa558939e944 100644
> --- a/drivers/rtc/rtc-abx80x.c
> +++ b/drivers/rtc/rtc-abx80x.c
> @@ -17,6 +17,7 @@
> #include
> #include
> #include
> +#include
>
> #define ABX8XX_REG_HTH 0x00
> #define ABX8XX_REG_SC0x01
> @@ -37,6 +38,7 @@
>
> #define ABX8XX_REG_STATUS0x0f
> #define ABX8XX_STATUS_AF BIT(2)
> +#define ABX8XX_STATUS_WDTBIT(6)
>
> #define ABX8XX_REG_CTRL1 0x10
> #define ABX8XX_CTRL_WRITEBIT(0)
> @@ -61,6 +63,14 @@
> #define ABX8XX_OSS_OFBIT(1)
> #define ABX8XX_OSS_OMODE BIT(4)
>
> +#define ABX8XX_REG_WDT 0x1b
> +#define ABX8XX_WDT_WDS BIT(7)
> +#define ABX8XX_WDT_BMB_MASK 0x7c
> +#define ABX8XX_WDT_BMB_SHIFT 2
> +#define ABX8XX_WDT_MAX_TIME (ABX8XX_WDT_BMB_MASK >> ABX8XX_WDT_BMB_SHIFT)
> +#define ABX8XX_WDT_WRB_MASK 0x03
> +#define ABX8XX_WDT_WRB_1HZ 0x02
> +
> #define ABX8XX_REG_CFG_KEY 0x1f
> #define ABX8XX_CFG_KEY_OSC 0xa1
> #define ABX8XX_CFG_KEY_MISC 0x9d
> @@ -80,20 +90,27 @@ enum abx80x_chip {AB0801, AB0803, AB0804, AB0805,
> struct abx80x_cap {
> u16 pn;
> bool has_tc;
> + bool has_wdog;
> };
>
> static struct abx80x_cap abx80x_caps[] = {
> [AB0801] = {.pn = 0x0801},
> [AB0803] = {.pn = 0x0803},
> - [AB0804] = {.pn = 0x0804, .has_tc = true},
> - [AB0805] = {.pn = 0x0805, .has_tc = true},
> + [AB0804] = {.pn = 0x0804, .has_tc = true, .has_wdog = true},
> + [AB0805] = {.pn = 0x0805, .has_tc = true, .has_wdog = true},
> [AB1801] = {.pn = 0x1801},
> [AB1803] = {.pn = 0x1803},
> - [AB1804] = {.pn = 0x1804, .has_tc = true},
> - [AB1805] = {.pn = 0x1805, .has_tc = true},
> + [AB1804] = {.pn = 0x1804, .has_tc = true, .has_wdog = true},
> + [AB1805] = {.pn = 0x1805, .has_tc = true, .has_wdog = true},
> [ABX80X] = {.pn = 0}
> };
>
> +struct abx80x_priv {
> + struct rtc_device *rtc;
> + struct i2c_client *client;
> + struct watchdog_device wdog;
> +};
> +
To make the watchdog part easier to review, you could separate the
introduction of abx80x_priv in a preliminary patch and then introduce
the watchdog code.
> static int abx80x_is_rc_mode(struct i2c_client *client)
> {
> int flags = 0;
> @@ -218,7 +235,8 @@ static int abx80x_rtc_set_time(struct device *dev, struct
> rtc_time *tm)
> static irqreturn_t abx80x_handle_irq(int irq, void *dev_id)
> {
> struct i2c_client *client = dev_id;
> - struct rtc_device *rtc = i2c_get_clientdata(client);
> + struct abx80x_priv *priv = i2c_get_clientdata(client);
> + struct rtc_device *rtc = priv->rtc;
> int status;
>
> status = i2c_smbus_read_byte_data(client, ABX8XX_REG_STATUS);
> @@ -228,6 +246,13 @@ static irqreturn_t abx80x_handle_irq(int irq, void
> *dev_id)
> if (status & ABX8XX_STATUS_AF)
> rtc_update_irq(rtc, 1, RTC_AF | RTC_IRQF);
>
> + /*
> + * It is unclear if we'll get an interrupt before the external
> + * reset kicks in.
> + */
> + if (status & ABX8XX_STATUS_WDT)
> + dev_err(>dev, "watchdog timeout interrupt!\n");
> +
dev_alert maybe?
> i2c_smbus_write_byte_data(client, ABX8XX_REG_STATUS, 0);
>
> return IRQ_HANDLED;
> @@ -529,11 +554,110 @@ static void rtc_calib_remove_sysfs_group(void *_dev)
> sysfs_remove_group(>kobj, _calib_attr_group);
> }
>
> +#ifdef CONFIG_RTC_DRV_ABX80X_WDT
> +
> +static inline
[PATCH 08/11] compat_ioctl: remove PCI ioctl translation
The /proc/pci/ implementation already handles these just fine, so the entries in the table are not needed any more. Signed-off-by: Arnd Bergmann --- fs/compat_ioctl.c | 5 - 1 file changed, 5 deletions(-) diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c index 23c0406d8b30..28ebff2d1799 100644 --- a/fs/compat_ioctl.c +++ b/fs/compat_ioctl.c @@ -44,7 +44,6 @@ #include #include #include -#include #include #include #include @@ -640,10 +639,6 @@ COMPATIBLE_IOCTL(HIDPGETCONNINFO) /* Misc. */ COMPATIBLE_IOCTL(0x41545900) /* ATYIO_CLKR */ COMPATIBLE_IOCTL(0x41545901) /* ATYIO_CLKW */ -COMPATIBLE_IOCTL(PCIIOC_CONTROLLER) -COMPATIBLE_IOCTL(PCIIOC_MMAP_IS_IO) -COMPATIBLE_IOCTL(PCIIOC_MMAP_IS_MEM) -COMPATIBLE_IOCTL(PCIIOC_WRITE_COMBINE) #ifdef TIOCGLTC COMPATIBLE_IOCTL(TIOCGLTC) COMPATIBLE_IOCTL(TIOCSLTC) -- 2.18.0
[PATCH 09/11] compat_ioctl: remove /dev/raw ioctl translation
The /dev/rawX implementation already handles these just fine, so the entries in the table are not needed any more. Signed-off-by: Arnd Bergmann --- fs/compat_ioctl.c | 4 1 file changed, 4 deletions(-) diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c index 28ebff2d1799..e755802cd887 100644 --- a/fs/compat_ioctl.c +++ b/fs/compat_ioctl.c @@ -41,7 +41,6 @@ #include #include #include -#include #include #include #include @@ -577,9 +576,6 @@ COMPATIBLE_IOCTL(SG_GET_KEEP_ORPHAN) /* PPP stuff */ COMPATIBLE_IOCTL(PPPIOCGUNIT) COMPATIBLE_IOCTL(PPPIOCGCHAN) -/* Raw devices */ -COMPATIBLE_IOCTL(RAW_SETBIND) -COMPATIBLE_IOCTL(RAW_GETBIND) /* Watchdog */ COMPATIBLE_IOCTL(WDIOC_GETSUPPORT) COMPATIBLE_IOCTL(WDIOC_GETSTATUS) -- 2.18.0
[PATCH 08/11] compat_ioctl: remove PCI ioctl translation
The /proc/pci/ implementation already handles these just fine, so the entries in the table are not needed any more. Signed-off-by: Arnd Bergmann --- fs/compat_ioctl.c | 5 - 1 file changed, 5 deletions(-) diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c index 23c0406d8b30..28ebff2d1799 100644 --- a/fs/compat_ioctl.c +++ b/fs/compat_ioctl.c @@ -44,7 +44,6 @@ #include #include #include -#include #include #include #include @@ -640,10 +639,6 @@ COMPATIBLE_IOCTL(HIDPGETCONNINFO) /* Misc. */ COMPATIBLE_IOCTL(0x41545900) /* ATYIO_CLKR */ COMPATIBLE_IOCTL(0x41545901) /* ATYIO_CLKW */ -COMPATIBLE_IOCTL(PCIIOC_CONTROLLER) -COMPATIBLE_IOCTL(PCIIOC_MMAP_IS_IO) -COMPATIBLE_IOCTL(PCIIOC_MMAP_IS_MEM) -COMPATIBLE_IOCTL(PCIIOC_WRITE_COMBINE) #ifdef TIOCGLTC COMPATIBLE_IOCTL(TIOCGLTC) COMPATIBLE_IOCTL(TIOCSLTC) -- 2.18.0
[PATCH 09/11] compat_ioctl: remove /dev/raw ioctl translation
The /dev/rawX implementation already handles these just fine, so the entries in the table are not needed any more. Signed-off-by: Arnd Bergmann --- fs/compat_ioctl.c | 4 1 file changed, 4 deletions(-) diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c index 28ebff2d1799..e755802cd887 100644 --- a/fs/compat_ioctl.c +++ b/fs/compat_ioctl.c @@ -41,7 +41,6 @@ #include #include #include -#include #include #include #include @@ -577,9 +576,6 @@ COMPATIBLE_IOCTL(SG_GET_KEEP_ORPHAN) /* PPP stuff */ COMPATIBLE_IOCTL(PPPIOCGUNIT) COMPATIBLE_IOCTL(PPPIOCGCHAN) -/* Raw devices */ -COMPATIBLE_IOCTL(RAW_SETBIND) -COMPATIBLE_IOCTL(RAW_GETBIND) /* Watchdog */ COMPATIBLE_IOCTL(WDIOC_GETSUPPORT) COMPATIBLE_IOCTL(WDIOC_GETSTATUS) -- 2.18.0
[PATCH 10/11] compat_ioctl: remove last RAID handling code
Commit aa98aa31987a ("md: move compat_ioctl handling into md.c")
already removed the COMPATIBLE_IOCTL() table entries and added
a complete implementation, but a few lines got left behind and
should also be removed here.
Signed-off-by: Arnd Bergmann
---
fs/compat_ioctl.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index e755802cd887..bb73d52f02a2 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -676,11 +676,6 @@ static long do_ioctl_trans(unsigned int cmd,
case TCSBRKP:
case TIOCMIWAIT:
case TIOCSCTTY:
- /* RAID */
- case HOT_REMOVE_DISK:
- case HOT_ADD_DISK:
- case SET_DISK_FAULTY:
- case SET_BITMAP_FILE:
return vfs_ioctl(file, cmd, arg);
}
--
2.18.0
[PATCH 10/11] compat_ioctl: remove last RAID handling code
Commit aa98aa31987a ("md: move compat_ioctl handling into md.c")
already removed the COMPATIBLE_IOCTL() table entries and added
a complete implementation, but a few lines got left behind and
should also be removed here.
Signed-off-by: Arnd Bergmann
---
fs/compat_ioctl.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index e755802cd887..bb73d52f02a2 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -676,11 +676,6 @@ static long do_ioctl_trans(unsigned int cmd,
case TCSBRKP:
case TIOCMIWAIT:
case TIOCSCTTY:
- /* RAID */
- case HOT_REMOVE_DISK:
- case HOT_ADD_DISK:
- case SET_DISK_FAULTY:
- case SET_BITMAP_FILE:
return vfs_ioctl(file, cmd, arg);
}
--
2.18.0
[PATCH 07/11] compat_ioctl: remove joystick ioctl translation
The joystick driver already handles these just fine, so the entries in the table are not needed any more. Signed-off-by: Arnd Bergmann --- fs/compat_ioctl.c | 8 1 file changed, 8 deletions(-) diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c index eb29188d1dbb..23c0406d8b30 100644 --- a/fs/compat_ioctl.c +++ b/fs/compat_ioctl.c @@ -11,8 +11,6 @@ * ioctls. */ -#include - #include #include #include @@ -646,12 +644,6 @@ COMPATIBLE_IOCTL(PCIIOC_CONTROLLER) COMPATIBLE_IOCTL(PCIIOC_MMAP_IS_IO) COMPATIBLE_IOCTL(PCIIOC_MMAP_IS_MEM) COMPATIBLE_IOCTL(PCIIOC_WRITE_COMBINE) -/* joystick */ -COMPATIBLE_IOCTL(JSIOCGVERSION) -COMPATIBLE_IOCTL(JSIOCGAXES) -COMPATIBLE_IOCTL(JSIOCGBUTTONS) -COMPATIBLE_IOCTL(JSIOCGNAME(0)) - #ifdef TIOCGLTC COMPATIBLE_IOCTL(TIOCGLTC) COMPATIBLE_IOCTL(TIOCSLTC) -- 2.18.0
[PATCH 07/11] compat_ioctl: remove joystick ioctl translation
The joystick driver already handles these just fine, so the entries in the table are not needed any more. Signed-off-by: Arnd Bergmann --- fs/compat_ioctl.c | 8 1 file changed, 8 deletions(-) diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c index eb29188d1dbb..23c0406d8b30 100644 --- a/fs/compat_ioctl.c +++ b/fs/compat_ioctl.c @@ -11,8 +11,6 @@ * ioctls. */ -#include - #include #include #include @@ -646,12 +644,6 @@ COMPATIBLE_IOCTL(PCIIOC_CONTROLLER) COMPATIBLE_IOCTL(PCIIOC_MMAP_IS_IO) COMPATIBLE_IOCTL(PCIIOC_MMAP_IS_MEM) COMPATIBLE_IOCTL(PCIIOC_WRITE_COMBINE) -/* joystick */ -COMPATIBLE_IOCTL(JSIOCGVERSION) -COMPATIBLE_IOCTL(JSIOCGAXES) -COMPATIBLE_IOCTL(JSIOCGBUTTONS) -COMPATIBLE_IOCTL(JSIOCGNAME(0)) - #ifdef TIOCGLTC COMPATIBLE_IOCTL(TIOCGLTC) COMPATIBLE_IOCTL(TIOCSLTC) -- 2.18.0
[PATCH 06/11] compat_ioctl: remove /dev/random commands
These are all handled by the random driver, so instead of listing
each ioctl, we can just use the same function to deal with both
native and compat commands.
Signed-off-by: Arnd Bergmann
---
drivers/char/random.c | 1 +
fs/compat_ioctl.c | 7 ---
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index bf5f99fc36f1..103abf82444a 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -2021,6 +2021,7 @@ const struct file_operations random_fops = {
.write = random_write,
.poll = random_poll,
.unlocked_ioctl = random_ioctl,
+ .compat_ioctl = random_ioctl,
.fasync = random_fasync,
.llseek = noop_llseek,
};
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index b56a3842d61d..eb29188d1dbb 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -594,13 +594,6 @@ COMPATIBLE_IOCTL(WDIOC_SETTIMEOUT)
COMPATIBLE_IOCTL(WDIOC_GETTIMEOUT)
COMPATIBLE_IOCTL(WDIOC_SETPRETIMEOUT)
COMPATIBLE_IOCTL(WDIOC_GETPRETIMEOUT)
-/* Big R */
-COMPATIBLE_IOCTL(RNDGETENTCNT)
-COMPATIBLE_IOCTL(RNDADDTOENTCNT)
-COMPATIBLE_IOCTL(RNDGETPOOL)
-COMPATIBLE_IOCTL(RNDADDENTROPY)
-COMPATIBLE_IOCTL(RNDZAPENTCNT)
-COMPATIBLE_IOCTL(RNDCLEARPOOL)
/* Bluetooth */
COMPATIBLE_IOCTL(HCIDEVUP)
COMPATIBLE_IOCTL(HCIDEVDOWN)
--
2.18.0
Re: [PATCH 3/3] dt-bindings: adxl372: Document the adxl372 I2C bindings
On Tue, 4 Sep 2018 17:13:14 +0300
Stefan Popa wrote:
> The adxl372 is designed to communicate in either SPI or I2C protocol.
> This patch adds the documentation of device tree bindings for adxl372
> I2C.
>
> Signed-off-by: Stefan Popa
Applied.
Thanks,
Jonathan
> ---
> Documentation/devicetree/bindings/iio/accel/adxl372.txt | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/accel/adxl372.txt
> b/Documentation/devicetree/bindings/iio/accel/adxl372.txt
> index 9409984..a289964 100644
> --- a/Documentation/devicetree/bindings/iio/accel/adxl372.txt
> +++ b/Documentation/devicetree/bindings/iio/accel/adxl372.txt
> @@ -4,14 +4,25 @@
> http://www.analog.com/media/en/technical-documentation/data-sheets/adxl372.pdf
>
> Required properties:
> - compatible : should be "adi,adxl372"
> - - reg: SPI chip select number for the device
> + - reg: the I2C address or SPI chip select number for the device
> +
> +Required properties for SPI bus usage:
> - spi-max-frequency: Max SPI frequency to use
>
> Optional properties:
> - interrupts: interrupt mapping for IRQ as documented in
> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
>
> -Example:
> +Example for a I2C device node:
> +
> + accelerometer@53 {
> + compatible = "adi,adxl372";
> + reg = <0x53>;
> + interrupt-parent = <>;
> + interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> + };
> +
> +Example for a SPI device node:
>
> accelerometer@0 {
> compatible = "adi,adxl372";
Re: [PATCH 3/3] dt-bindings: adxl372: Document the adxl372 I2C bindings
On Tue, 4 Sep 2018 17:13:14 +0300
Stefan Popa wrote:
> The adxl372 is designed to communicate in either SPI or I2C protocol.
> This patch adds the documentation of device tree bindings for adxl372
> I2C.
>
> Signed-off-by: Stefan Popa
Applied.
Thanks,
Jonathan
> ---
> Documentation/devicetree/bindings/iio/accel/adxl372.txt | 15 +--
> 1 file changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/accel/adxl372.txt
> b/Documentation/devicetree/bindings/iio/accel/adxl372.txt
> index 9409984..a289964 100644
> --- a/Documentation/devicetree/bindings/iio/accel/adxl372.txt
> +++ b/Documentation/devicetree/bindings/iio/accel/adxl372.txt
> @@ -4,14 +4,25 @@
> http://www.analog.com/media/en/technical-documentation/data-sheets/adxl372.pdf
>
> Required properties:
> - compatible : should be "adi,adxl372"
> - - reg: SPI chip select number for the device
> + - reg: the I2C address or SPI chip select number for the device
> +
> +Required properties for SPI bus usage:
> - spi-max-frequency: Max SPI frequency to use
>
> Optional properties:
> - interrupts: interrupt mapping for IRQ as documented in
> Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
>
> -Example:
> +Example for a I2C device node:
> +
> + accelerometer@53 {
> + compatible = "adi,adxl372";
> + reg = <0x53>;
> + interrupt-parent = <>;
> + interrupts = <25 IRQ_TYPE_EDGE_FALLING>;
> + };
> +
> +Example for a SPI device node:
>
> accelerometer@0 {
> compatible = "adi,adxl372";
[PATCH 06/11] compat_ioctl: remove /dev/random commands
These are all handled by the random driver, so instead of listing
each ioctl, we can just use the same function to deal with both
native and compat commands.
Signed-off-by: Arnd Bergmann
---
drivers/char/random.c | 1 +
fs/compat_ioctl.c | 7 ---
2 files changed, 1 insertion(+), 7 deletions(-)
diff --git a/drivers/char/random.c b/drivers/char/random.c
index bf5f99fc36f1..103abf82444a 100644
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -2021,6 +2021,7 @@ const struct file_operations random_fops = {
.write = random_write,
.poll = random_poll,
.unlocked_ioctl = random_ioctl,
+ .compat_ioctl = random_ioctl,
.fasync = random_fasync,
.llseek = noop_llseek,
};
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index b56a3842d61d..eb29188d1dbb 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -594,13 +594,6 @@ COMPATIBLE_IOCTL(WDIOC_SETTIMEOUT)
COMPATIBLE_IOCTL(WDIOC_GETTIMEOUT)
COMPATIBLE_IOCTL(WDIOC_SETPRETIMEOUT)
COMPATIBLE_IOCTL(WDIOC_GETPRETIMEOUT)
-/* Big R */
-COMPATIBLE_IOCTL(RNDGETENTCNT)
-COMPATIBLE_IOCTL(RNDADDTOENTCNT)
-COMPATIBLE_IOCTL(RNDGETPOOL)
-COMPATIBLE_IOCTL(RNDADDENTROPY)
-COMPATIBLE_IOCTL(RNDZAPENTCNT)
-COMPATIBLE_IOCTL(RNDCLEARPOOL)
/* Bluetooth */
COMPATIBLE_IOCTL(HCIDEVUP)
COMPATIBLE_IOCTL(HCIDEVDOWN)
--
2.18.0
[PATCH 05/11] compat_ioctl: remove IGNORE_IOCTL()
Since commit 07d106d0a33d ("vfs: fix up ENOIOCTLCMD error handling"),
we don't warn about unhandled compat-ioctl command code any more, but
just return the same error that a native file descriptor returns when
there is no handler.
This means the IGNORE_IOCTL() annotations are completely useless and
can all be removed. TIOCSTART/TIOCSTOP and KDGHWCLK/KDSHWCLK fall into
the same category, but for some reason were listed as COMPATIBLE_IOCTL().
Signed-off-by: Arnd Bergmann
---
fs/compat_ioctl.c | 56 ---
1 file changed, 56 deletions(-)
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index 7d8c5722fd0a..b56a3842d61d 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -463,20 +463,7 @@ static int compat_ioctl_preallocate(struct file *file,
#define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0x)
#define COMPATIBLE_IOCTL(cmd) XFORM((u32)cmd),
-/* ioctl should not be warned about even if it's not implemented.
- Valid reasons to use this:
- - It is implemented with ->compat_ioctl on some device, but programs
- call it on others too.
- - The ioctl is not implemented in the native kernel, but programs
- call it commonly anyways.
- Most other reasons are not valid. */
-#define IGNORE_IOCTL(cmd) COMPATIBLE_IOCTL(cmd)
-
static unsigned int ioctl_pointer[] = {
-/* compatible ioctls first */
-COMPATIBLE_IOCTL(0x4B50) /* KDGHWCLK - not in the kernel, but don't complain
*/
-COMPATIBLE_IOCTL(0x4B51) /* KDSHWCLK - not in the kernel, but don't complain
*/
-
/* Big T */
COMPATIBLE_IOCTL(TCGETA)
COMPATIBLE_IOCTL(TCSETA)
@@ -553,9 +540,6 @@ COMPATIBLE_IOCTL(SCSI_IOCTL_SEND_COMMAND)
COMPATIBLE_IOCTL(SCSI_IOCTL_PROBE_HOST)
COMPATIBLE_IOCTL(SCSI_IOCTL_GET_PCI)
#endif
-/* Big V (don't complain on serial console) */
-IGNORE_IOCTL(VT_OPENQRY)
-IGNORE_IOCTL(VT_GETMODE)
/*
* These two are only for the sbus rtc driver, but
* hwclock tries them on every rtc device first when
@@ -569,11 +553,6 @@ COMPATIBLE_IOCTL(MTIOCTOP)
/* Socket level stuff */
COMPATIBLE_IOCTL(FIOQSIZE)
#ifdef CONFIG_BLOCK
-/* md calls this on random blockdevs */
-IGNORE_IOCTL(RAID_VERSION)
-/* qemu/qemu-img might call these two on plain files for probing */
-IGNORE_IOCTL(CDROM_DRIVE_STATUS)
-IGNORE_IOCTL(FDGETPRM32)
/* SG stuff */
COMPATIBLE_IOCTL(SG_SET_TIMEOUT)
COMPATIBLE_IOCTL(SG_GET_TIMEOUT)
@@ -684,41 +663,6 @@ COMPATIBLE_IOCTL(JSIOCGNAME(0))
COMPATIBLE_IOCTL(TIOCGLTC)
COMPATIBLE_IOCTL(TIOCSLTC)
#endif
-#ifdef TIOCSTART
-/*
- * For these two we have definitions in ioctls.h and/or termios.h on
- * some architectures but no actual implemention. Some applications
- * like bash call them if they are defined in the headers, so we provide
- * entries here to avoid syslog message spew.
- */
-COMPATIBLE_IOCTL(TIOCSTART)
-COMPATIBLE_IOCTL(TIOCSTOP)
-#endif
-
-/* fat 'r' ioctls. These are handled by fat with ->compat_ioctl,
- but we don't want warnings on other file systems. So declare
- them as compatible here. */
-#define VFAT_IOCTL_READDIR_BOTH32 _IOR('r', 1, struct compat_dirent[2])
-#define VFAT_IOCTL_READDIR_SHORT32 _IOR('r', 2, struct compat_dirent[2])
-
-IGNORE_IOCTL(VFAT_IOCTL_READDIR_BOTH32)
-IGNORE_IOCTL(VFAT_IOCTL_READDIR_SHORT32)
-
-#ifdef CONFIG_SPARC
-/* Sparc framebuffers, handled in sbusfb_compat_ioctl() */
-IGNORE_IOCTL(FBIOGTYPE)
-IGNORE_IOCTL(FBIOSATTR)
-IGNORE_IOCTL(FBIOGATTR)
-IGNORE_IOCTL(FBIOSVIDEO)
-IGNORE_IOCTL(FBIOGVIDEO)
-IGNORE_IOCTL(FBIOSCURPOS)
-IGNORE_IOCTL(FBIOGCURPOS)
-IGNORE_IOCTL(FBIOGCURMAX)
-IGNORE_IOCTL(FBIOPUTCMAP32)
-IGNORE_IOCTL(FBIOGETCMAP32)
-IGNORE_IOCTL(FBIOSCURSOR32)
-IGNORE_IOCTL(FBIOGCURSOR32)
-#endif
};
/*
--
2.18.0
[PATCH 05/11] compat_ioctl: remove IGNORE_IOCTL()
Since commit 07d106d0a33d ("vfs: fix up ENOIOCTLCMD error handling"),
we don't warn about unhandled compat-ioctl command code any more, but
just return the same error that a native file descriptor returns when
there is no handler.
This means the IGNORE_IOCTL() annotations are completely useless and
can all be removed. TIOCSTART/TIOCSTOP and KDGHWCLK/KDSHWCLK fall into
the same category, but for some reason were listed as COMPATIBLE_IOCTL().
Signed-off-by: Arnd Bergmann
---
fs/compat_ioctl.c | 56 ---
1 file changed, 56 deletions(-)
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index 7d8c5722fd0a..b56a3842d61d 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -463,20 +463,7 @@ static int compat_ioctl_preallocate(struct file *file,
#define XFORM(i) (((i) ^ ((i) << 27) ^ ((i) << 17)) & 0x)
#define COMPATIBLE_IOCTL(cmd) XFORM((u32)cmd),
-/* ioctl should not be warned about even if it's not implemented.
- Valid reasons to use this:
- - It is implemented with ->compat_ioctl on some device, but programs
- call it on others too.
- - The ioctl is not implemented in the native kernel, but programs
- call it commonly anyways.
- Most other reasons are not valid. */
-#define IGNORE_IOCTL(cmd) COMPATIBLE_IOCTL(cmd)
-
static unsigned int ioctl_pointer[] = {
-/* compatible ioctls first */
-COMPATIBLE_IOCTL(0x4B50) /* KDGHWCLK - not in the kernel, but don't complain
*/
-COMPATIBLE_IOCTL(0x4B51) /* KDSHWCLK - not in the kernel, but don't complain
*/
-
/* Big T */
COMPATIBLE_IOCTL(TCGETA)
COMPATIBLE_IOCTL(TCSETA)
@@ -553,9 +540,6 @@ COMPATIBLE_IOCTL(SCSI_IOCTL_SEND_COMMAND)
COMPATIBLE_IOCTL(SCSI_IOCTL_PROBE_HOST)
COMPATIBLE_IOCTL(SCSI_IOCTL_GET_PCI)
#endif
-/* Big V (don't complain on serial console) */
-IGNORE_IOCTL(VT_OPENQRY)
-IGNORE_IOCTL(VT_GETMODE)
/*
* These two are only for the sbus rtc driver, but
* hwclock tries them on every rtc device first when
@@ -569,11 +553,6 @@ COMPATIBLE_IOCTL(MTIOCTOP)
/* Socket level stuff */
COMPATIBLE_IOCTL(FIOQSIZE)
#ifdef CONFIG_BLOCK
-/* md calls this on random blockdevs */
-IGNORE_IOCTL(RAID_VERSION)
-/* qemu/qemu-img might call these two on plain files for probing */
-IGNORE_IOCTL(CDROM_DRIVE_STATUS)
-IGNORE_IOCTL(FDGETPRM32)
/* SG stuff */
COMPATIBLE_IOCTL(SG_SET_TIMEOUT)
COMPATIBLE_IOCTL(SG_GET_TIMEOUT)
@@ -684,41 +663,6 @@ COMPATIBLE_IOCTL(JSIOCGNAME(0))
COMPATIBLE_IOCTL(TIOCGLTC)
COMPATIBLE_IOCTL(TIOCSLTC)
#endif
-#ifdef TIOCSTART
-/*
- * For these two we have definitions in ioctls.h and/or termios.h on
- * some architectures but no actual implemention. Some applications
- * like bash call them if they are defined in the headers, so we provide
- * entries here to avoid syslog message spew.
- */
-COMPATIBLE_IOCTL(TIOCSTART)
-COMPATIBLE_IOCTL(TIOCSTOP)
-#endif
-
-/* fat 'r' ioctls. These are handled by fat with ->compat_ioctl,
- but we don't want warnings on other file systems. So declare
- them as compatible here. */
-#define VFAT_IOCTL_READDIR_BOTH32 _IOR('r', 1, struct compat_dirent[2])
-#define VFAT_IOCTL_READDIR_SHORT32 _IOR('r', 2, struct compat_dirent[2])
-
-IGNORE_IOCTL(VFAT_IOCTL_READDIR_BOTH32)
-IGNORE_IOCTL(VFAT_IOCTL_READDIR_SHORT32)
-
-#ifdef CONFIG_SPARC
-/* Sparc framebuffers, handled in sbusfb_compat_ioctl() */
-IGNORE_IOCTL(FBIOGTYPE)
-IGNORE_IOCTL(FBIOSATTR)
-IGNORE_IOCTL(FBIOGATTR)
-IGNORE_IOCTL(FBIOSVIDEO)
-IGNORE_IOCTL(FBIOGVIDEO)
-IGNORE_IOCTL(FBIOSCURPOS)
-IGNORE_IOCTL(FBIOGCURPOS)
-IGNORE_IOCTL(FBIOGCURMAX)
-IGNORE_IOCTL(FBIOPUTCMAP32)
-IGNORE_IOCTL(FBIOGETCMAP32)
-IGNORE_IOCTL(FBIOSCURSOR32)
-IGNORE_IOCTL(FBIOGCURSOR32)
-#endif
};
/*
--
2.18.0
[PATCH 03/11] compat_ioctl: remove translation for sound ioctls
The SNDCTL_* and SOUND_* commands are the old OSS user interface.
I checked all the sound ioctl commands listed in fs/compat_ioctl.c
to see if we still need the translation handlers. Here is what I
found:
- sound/oss/ is (almost) gone from the kernel, this is what actually
needed all the translations
- The ALSA emulation for OSS correctly handles all compat_ioctl
commands already.
- sound/oss/dmasound/ is the last holdout of the original OSS code,
this is only used on arch/m68k, which has no 64-bit mode and
hence needs no compat handlers
- arch/um/drivers/hostaudio_kern.c may run in 64-bit mode with
32-bit x86 user space underneath it. This rare corner case is
the only one that still needs the compat handlers.
By adding a simple redirect of .compat_ioctl to .unlocked_ioctl in the
UML driver, we can remove all the COMPATIBLE_IOCTL() annotations without
a change in functionality. For completeness, I'm adding the same thing
to the dmasound file, knowing that it makes no difference.
The compat_ioctl list contains one comment about SNDCTL_DSP_MAPINBUF and
SNDCTL_DSP_MAPOUTBUF, which actually would need a translation handler
if implemented. However, the native implementation just returns -EINVAL,
so we don't care.
Signed-off-by: Arnd Bergmann
---
arch/um/drivers/hostaudio_kern.c | 1 +
fs/compat_ioctl.c | 157 -
sound/core/oss/pcm_oss.c | 4 +
sound/oss/dmasound/dmasound_core.c | 2 +
4 files changed, 7 insertions(+), 157 deletions(-)
diff --git a/arch/um/drivers/hostaudio_kern.c b/arch/um/drivers/hostaudio_kern.c
index 7f9dbdbc4eb7..0278a642a622 100644
--- a/arch/um/drivers/hostaudio_kern.c
+++ b/arch/um/drivers/hostaudio_kern.c
@@ -298,6 +298,7 @@ static const struct file_operations hostaudio_fops = {
.write = hostaudio_write,
.poll = hostaudio_poll,
.unlocked_ioctl = hostaudio_ioctl,
+ .compat_ioctl = hostaudio_ioctl,
.mmap = NULL,
.open = hostaudio_open,
.release= hostaudio_release,
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index c2c73b802fb3..875516658c39 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -78,7 +78,6 @@
#include
#include
-#include
#include
#include
@@ -605,162 +604,6 @@ COMPATIBLE_IOCTL(SG_GET_KEEP_ORPHAN)
/* PPP stuff */
COMPATIBLE_IOCTL(PPPIOCGUNIT)
COMPATIBLE_IOCTL(PPPIOCGCHAN)
-/* Big A */
-/* sparc only */
-/* Big Q for sound/OSS */
-COMPATIBLE_IOCTL(SNDCTL_SEQ_RESET)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_SYNC)
-COMPATIBLE_IOCTL(SNDCTL_SYNTH_INFO)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_CTRLRATE)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_GETOUTCOUNT)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_GETINCOUNT)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_PERCMODE)
-COMPATIBLE_IOCTL(SNDCTL_FM_LOAD_INSTR)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_TESTMIDI)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_RESETSAMPLES)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_NRSYNTHS)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_NRMIDIS)
-COMPATIBLE_IOCTL(SNDCTL_MIDI_INFO)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_THRESHOLD)
-COMPATIBLE_IOCTL(SNDCTL_SYNTH_MEMAVL)
-COMPATIBLE_IOCTL(SNDCTL_FM_4OP_ENABLE)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_PANIC)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_OUTOFBAND)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_GETTIME)
-COMPATIBLE_IOCTL(SNDCTL_SYNTH_ID)
-COMPATIBLE_IOCTL(SNDCTL_SYNTH_CONTROL)
-COMPATIBLE_IOCTL(SNDCTL_SYNTH_REMOVESAMPLE)
-/* Big T for sound/OSS */
-COMPATIBLE_IOCTL(SNDCTL_TMR_TIMEBASE)
-COMPATIBLE_IOCTL(SNDCTL_TMR_START)
-COMPATIBLE_IOCTL(SNDCTL_TMR_STOP)
-COMPATIBLE_IOCTL(SNDCTL_TMR_CONTINUE)
-COMPATIBLE_IOCTL(SNDCTL_TMR_TEMPO)
-COMPATIBLE_IOCTL(SNDCTL_TMR_SOURCE)
-COMPATIBLE_IOCTL(SNDCTL_TMR_METRONOME)
-COMPATIBLE_IOCTL(SNDCTL_TMR_SELECT)
-/* Little m for sound/OSS */
-COMPATIBLE_IOCTL(SNDCTL_MIDI_PRETIME)
-COMPATIBLE_IOCTL(SNDCTL_MIDI_MPUMODE)
-COMPATIBLE_IOCTL(SNDCTL_MIDI_MPUCMD)
-/* Big P for sound/OSS */
-COMPATIBLE_IOCTL(SNDCTL_DSP_RESET)
-COMPATIBLE_IOCTL(SNDCTL_DSP_SYNC)
-COMPATIBLE_IOCTL(SNDCTL_DSP_SPEED)
-COMPATIBLE_IOCTL(SNDCTL_DSP_STEREO)
-COMPATIBLE_IOCTL(SNDCTL_DSP_GETBLKSIZE)
-COMPATIBLE_IOCTL(SNDCTL_DSP_CHANNELS)
-COMPATIBLE_IOCTL(SOUND_PCM_WRITE_FILTER)
-COMPATIBLE_IOCTL(SNDCTL_DSP_POST)
-COMPATIBLE_IOCTL(SNDCTL_DSP_SUBDIVIDE)
-COMPATIBLE_IOCTL(SNDCTL_DSP_SETFRAGMENT)
-COMPATIBLE_IOCTL(SNDCTL_DSP_GETFMTS)
-COMPATIBLE_IOCTL(SNDCTL_DSP_SETFMT)
-COMPATIBLE_IOCTL(SNDCTL_DSP_GETOSPACE)
-COMPATIBLE_IOCTL(SNDCTL_DSP_GETISPACE)
-COMPATIBLE_IOCTL(SNDCTL_DSP_NONBLOCK)
-COMPATIBLE_IOCTL(SNDCTL_DSP_GETCAPS)
-COMPATIBLE_IOCTL(SNDCTL_DSP_GETTRIGGER)
-COMPATIBLE_IOCTL(SNDCTL_DSP_SETTRIGGER)
-COMPATIBLE_IOCTL(SNDCTL_DSP_GETIPTR)
-COMPATIBLE_IOCTL(SNDCTL_DSP_GETOPTR)
-/* SNDCTL_DSP_MAPINBUF, XXX needs translation */
-/* SNDCTL_DSP_MAPOUTBUF, XXX needs translation */
-COMPATIBLE_IOCTL(SNDCTL_DSP_SETSYNCRO)
-COMPATIBLE_IOCTL(SNDCTL_DSP_SETDUPLEX)
-COMPATIBLE_IOCTL(SNDCTL_DSP_GETODELAY)
-COMPATIBLE_IOCTL(SNDCTL_DSP_PROFILE)
-COMPATIBLE_IOCTL(SOUND_PCM_READ_RATE)
-COMPATIBLE_IOCTL(SOUND_PCM_READ_CHANNELS)
Re: [PATCH 2/3] iio: adxl372: Add support for I2C communication
On Tue, 4 Sep 2018 17:12:32 +0300
Stefan Popa wrote:
> The adxl372 is designed to communicate in either SPI or I2C protocol. It
> autodetects the format being used, requiring no configuration control to
> select the format.
>
> Signed-off-by: Stefan Popa
Applied.
Thanks,
Jonathan
> ---
> MAINTAINERS | 1 +
> drivers/iio/accel/Kconfig | 11
> drivers/iio/accel/Makefile | 1 +
> drivers/iio/accel/adxl372.c | 1 -
> drivers/iio/accel/adxl372.h | 2 ++
> drivers/iio/accel/adxl372_i2c.c | 61
> +
> 6 files changed, 76 insertions(+), 1 deletion(-)
> create mode 100644 drivers/iio/accel/adxl372_i2c.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2938632..2b9a364 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -549,6 +549,7 @@ W:
> http://ez.analog.com/community/linux-device-drivers
> S: Supported
> F: drivers/iio/accel/adxl372.c
> F: drivers/iio/accel/adxl372_spi.c
> +F: drivers/iio/accel/adxl372_i2c.c
> F: Documentation/devicetree/bindings/iio/accel/adxl372.txt
>
> AF9013 MEDIA DRIVER
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index bed5da8..7993a67 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -76,6 +76,17 @@ config ADXL372_SPI
> To compile this driver as a module, choose M here: the
> module will be called adxl372_spi.
>
> +config ADXL372_I2C
> + tristate "Analog Devices ADXL372 3-Axis Accelerometer I2C Driver"
> + depends on I2C
> + select ADXL372
> + select REGMAP_I2C
> + help
> + Say yes here to add support for the Analog Devices ADXL372 triaxial
> + acceleration sensor.
> + To compile this driver as a module, choose M here: the
> + module will be called adxl372_i2c.
> +
> config BMA180
> tristate "Bosch BMA180/BMA250 3-Axis Accelerometer Driver"
> depends on I2C
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index c9c5db9..56bd021 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_ADXL345) += adxl345_core.o
> obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o
> obj-$(CONFIG_ADXL345_SPI) += adxl345_spi.o
> obj-$(CONFIG_ADXL372) += adxl372.o
> +obj-$(CONFIG_ADXL372_I2C) += adxl372_i2c.o
> obj-$(CONFIG_ADXL372_SPI) += adxl372_spi.o
> obj-$(CONFIG_BMA180) += bma180.o
> obj-$(CONFIG_BMA220) += bma220_spi.o
> diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
> index f1df89d..3b84cb2 100644
> --- a/drivers/iio/accel/adxl372.c
> +++ b/drivers/iio/accel/adxl372.c
> @@ -26,7 +26,6 @@
> #define ADXL372_DEVID0x00
> #define ADXL372_DEVID_MST0x01
> #define ADXL372_PARTID 0x02
> -#define ADXL372_REVID0x03
> #define ADXL372_STATUS_1 0x04
> #define ADXL372_STATUS_2 0x05
> #define ADXL372_FIFO_ENTRIES_2 0x06
> diff --git a/drivers/iio/accel/adxl372.h b/drivers/iio/accel/adxl372.h
> index 5da89b1..80a0aa9 100644
> --- a/drivers/iio/accel/adxl372.h
> +++ b/drivers/iio/accel/adxl372.h
> @@ -8,6 +8,8 @@
> #ifndef _ADXL372_H_
> #define _ADXL372_H_
>
> +#define ADXL372_REVID0x03
> +
> int adxl372_probe(struct device *dev, struct regmap *regmap,
> int irq, const char *name);
> bool adxl372_readable_noinc_reg(struct device *dev, unsigned int reg);
> diff --git a/drivers/iio/accel/adxl372_i2c.c b/drivers/iio/accel/adxl372_i2c.c
> new file mode 100644
> index 000..e1affe4
> --- /dev/null
> +++ b/drivers/iio/accel/adxl372_i2c.c
> @@ -0,0 +1,61 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * ADXL372 3-Axis Digital Accelerometer I2C driver
> + *
> + * Copyright 2018 Analog Devices Inc.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include "adxl372.h"
> +
> +static const struct regmap_config adxl372_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .readable_noinc_reg = adxl372_readable_noinc_reg,
> +};
> +
> +static int adxl372_i2c_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct regmap *regmap;
> + unsigned int regval;
> + int ret;
> +
> + regmap = devm_regmap_init_i2c(client, _regmap_config);
> + if (IS_ERR(regmap))
> + return PTR_ERR(regmap);
> +
> + ret = regmap_read(regmap, ADXL372_REVID, );
> + if (ret < 0)
> + return ret;
> +
> + /* Starting with the 3rd revision an I2C chip bug was fixed */
> + if (regval < 3)
> + dev_warn(>dev,
> + "I2C might not work properly with other devices on the bus");
> +
> + return adxl372_probe(>dev, regmap, client->irq, id->name);
> +}
> +
> +static const struct i2c_device_id adxl372_i2c_id[] = {
> + { "adxl372", 0 },
> + {}
> +};
> +MODULE_DEVICE_TABLE(i2c, adxl372_i2c_id);
> +
[PATCH 03/11] compat_ioctl: remove translation for sound ioctls
The SNDCTL_* and SOUND_* commands are the old OSS user interface.
I checked all the sound ioctl commands listed in fs/compat_ioctl.c
to see if we still need the translation handlers. Here is what I
found:
- sound/oss/ is (almost) gone from the kernel, this is what actually
needed all the translations
- The ALSA emulation for OSS correctly handles all compat_ioctl
commands already.
- sound/oss/dmasound/ is the last holdout of the original OSS code,
this is only used on arch/m68k, which has no 64-bit mode and
hence needs no compat handlers
- arch/um/drivers/hostaudio_kern.c may run in 64-bit mode with
32-bit x86 user space underneath it. This rare corner case is
the only one that still needs the compat handlers.
By adding a simple redirect of .compat_ioctl to .unlocked_ioctl in the
UML driver, we can remove all the COMPATIBLE_IOCTL() annotations without
a change in functionality. For completeness, I'm adding the same thing
to the dmasound file, knowing that it makes no difference.
The compat_ioctl list contains one comment about SNDCTL_DSP_MAPINBUF and
SNDCTL_DSP_MAPOUTBUF, which actually would need a translation handler
if implemented. However, the native implementation just returns -EINVAL,
so we don't care.
Signed-off-by: Arnd Bergmann
---
arch/um/drivers/hostaudio_kern.c | 1 +
fs/compat_ioctl.c | 157 -
sound/core/oss/pcm_oss.c | 4 +
sound/oss/dmasound/dmasound_core.c | 2 +
4 files changed, 7 insertions(+), 157 deletions(-)
diff --git a/arch/um/drivers/hostaudio_kern.c b/arch/um/drivers/hostaudio_kern.c
index 7f9dbdbc4eb7..0278a642a622 100644
--- a/arch/um/drivers/hostaudio_kern.c
+++ b/arch/um/drivers/hostaudio_kern.c
@@ -298,6 +298,7 @@ static const struct file_operations hostaudio_fops = {
.write = hostaudio_write,
.poll = hostaudio_poll,
.unlocked_ioctl = hostaudio_ioctl,
+ .compat_ioctl = hostaudio_ioctl,
.mmap = NULL,
.open = hostaudio_open,
.release= hostaudio_release,
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index c2c73b802fb3..875516658c39 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -78,7 +78,6 @@
#include
#include
-#include
#include
#include
@@ -605,162 +604,6 @@ COMPATIBLE_IOCTL(SG_GET_KEEP_ORPHAN)
/* PPP stuff */
COMPATIBLE_IOCTL(PPPIOCGUNIT)
COMPATIBLE_IOCTL(PPPIOCGCHAN)
-/* Big A */
-/* sparc only */
-/* Big Q for sound/OSS */
-COMPATIBLE_IOCTL(SNDCTL_SEQ_RESET)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_SYNC)
-COMPATIBLE_IOCTL(SNDCTL_SYNTH_INFO)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_CTRLRATE)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_GETOUTCOUNT)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_GETINCOUNT)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_PERCMODE)
-COMPATIBLE_IOCTL(SNDCTL_FM_LOAD_INSTR)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_TESTMIDI)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_RESETSAMPLES)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_NRSYNTHS)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_NRMIDIS)
-COMPATIBLE_IOCTL(SNDCTL_MIDI_INFO)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_THRESHOLD)
-COMPATIBLE_IOCTL(SNDCTL_SYNTH_MEMAVL)
-COMPATIBLE_IOCTL(SNDCTL_FM_4OP_ENABLE)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_PANIC)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_OUTOFBAND)
-COMPATIBLE_IOCTL(SNDCTL_SEQ_GETTIME)
-COMPATIBLE_IOCTL(SNDCTL_SYNTH_ID)
-COMPATIBLE_IOCTL(SNDCTL_SYNTH_CONTROL)
-COMPATIBLE_IOCTL(SNDCTL_SYNTH_REMOVESAMPLE)
-/* Big T for sound/OSS */
-COMPATIBLE_IOCTL(SNDCTL_TMR_TIMEBASE)
-COMPATIBLE_IOCTL(SNDCTL_TMR_START)
-COMPATIBLE_IOCTL(SNDCTL_TMR_STOP)
-COMPATIBLE_IOCTL(SNDCTL_TMR_CONTINUE)
-COMPATIBLE_IOCTL(SNDCTL_TMR_TEMPO)
-COMPATIBLE_IOCTL(SNDCTL_TMR_SOURCE)
-COMPATIBLE_IOCTL(SNDCTL_TMR_METRONOME)
-COMPATIBLE_IOCTL(SNDCTL_TMR_SELECT)
-/* Little m for sound/OSS */
-COMPATIBLE_IOCTL(SNDCTL_MIDI_PRETIME)
-COMPATIBLE_IOCTL(SNDCTL_MIDI_MPUMODE)
-COMPATIBLE_IOCTL(SNDCTL_MIDI_MPUCMD)
-/* Big P for sound/OSS */
-COMPATIBLE_IOCTL(SNDCTL_DSP_RESET)
-COMPATIBLE_IOCTL(SNDCTL_DSP_SYNC)
-COMPATIBLE_IOCTL(SNDCTL_DSP_SPEED)
-COMPATIBLE_IOCTL(SNDCTL_DSP_STEREO)
-COMPATIBLE_IOCTL(SNDCTL_DSP_GETBLKSIZE)
-COMPATIBLE_IOCTL(SNDCTL_DSP_CHANNELS)
-COMPATIBLE_IOCTL(SOUND_PCM_WRITE_FILTER)
-COMPATIBLE_IOCTL(SNDCTL_DSP_POST)
-COMPATIBLE_IOCTL(SNDCTL_DSP_SUBDIVIDE)
-COMPATIBLE_IOCTL(SNDCTL_DSP_SETFRAGMENT)
-COMPATIBLE_IOCTL(SNDCTL_DSP_GETFMTS)
-COMPATIBLE_IOCTL(SNDCTL_DSP_SETFMT)
-COMPATIBLE_IOCTL(SNDCTL_DSP_GETOSPACE)
-COMPATIBLE_IOCTL(SNDCTL_DSP_GETISPACE)
-COMPATIBLE_IOCTL(SNDCTL_DSP_NONBLOCK)
-COMPATIBLE_IOCTL(SNDCTL_DSP_GETCAPS)
-COMPATIBLE_IOCTL(SNDCTL_DSP_GETTRIGGER)
-COMPATIBLE_IOCTL(SNDCTL_DSP_SETTRIGGER)
-COMPATIBLE_IOCTL(SNDCTL_DSP_GETIPTR)
-COMPATIBLE_IOCTL(SNDCTL_DSP_GETOPTR)
-/* SNDCTL_DSP_MAPINBUF, XXX needs translation */
-/* SNDCTL_DSP_MAPOUTBUF, XXX needs translation */
-COMPATIBLE_IOCTL(SNDCTL_DSP_SETSYNCRO)
-COMPATIBLE_IOCTL(SNDCTL_DSP_SETDUPLEX)
-COMPATIBLE_IOCTL(SNDCTL_DSP_GETODELAY)
-COMPATIBLE_IOCTL(SNDCTL_DSP_PROFILE)
-COMPATIBLE_IOCTL(SOUND_PCM_READ_RATE)
-COMPATIBLE_IOCTL(SOUND_PCM_READ_CHANNELS)
Re: [PATCH 2/3] iio: adxl372: Add support for I2C communication
On Tue, 4 Sep 2018 17:12:32 +0300
Stefan Popa wrote:
> The adxl372 is designed to communicate in either SPI or I2C protocol. It
> autodetects the format being used, requiring no configuration control to
> select the format.
>
> Signed-off-by: Stefan Popa
Applied.
Thanks,
Jonathan
> ---
> MAINTAINERS | 1 +
> drivers/iio/accel/Kconfig | 11
> drivers/iio/accel/Makefile | 1 +
> drivers/iio/accel/adxl372.c | 1 -
> drivers/iio/accel/adxl372.h | 2 ++
> drivers/iio/accel/adxl372_i2c.c | 61
> +
> 6 files changed, 76 insertions(+), 1 deletion(-)
> create mode 100644 drivers/iio/accel/adxl372_i2c.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2938632..2b9a364 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -549,6 +549,7 @@ W:
> http://ez.analog.com/community/linux-device-drivers
> S: Supported
> F: drivers/iio/accel/adxl372.c
> F: drivers/iio/accel/adxl372_spi.c
> +F: drivers/iio/accel/adxl372_i2c.c
> F: Documentation/devicetree/bindings/iio/accel/adxl372.txt
>
> AF9013 MEDIA DRIVER
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index bed5da8..7993a67 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -76,6 +76,17 @@ config ADXL372_SPI
> To compile this driver as a module, choose M here: the
> module will be called adxl372_spi.
>
> +config ADXL372_I2C
> + tristate "Analog Devices ADXL372 3-Axis Accelerometer I2C Driver"
> + depends on I2C
> + select ADXL372
> + select REGMAP_I2C
> + help
> + Say yes here to add support for the Analog Devices ADXL372 triaxial
> + acceleration sensor.
> + To compile this driver as a module, choose M here: the
> + module will be called adxl372_i2c.
> +
> config BMA180
> tristate "Bosch BMA180/BMA250 3-Axis Accelerometer Driver"
> depends on I2C
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index c9c5db9..56bd021 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_ADXL345) += adxl345_core.o
> obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o
> obj-$(CONFIG_ADXL345_SPI) += adxl345_spi.o
> obj-$(CONFIG_ADXL372) += adxl372.o
> +obj-$(CONFIG_ADXL372_I2C) += adxl372_i2c.o
> obj-$(CONFIG_ADXL372_SPI) += adxl372_spi.o
> obj-$(CONFIG_BMA180) += bma180.o
> obj-$(CONFIG_BMA220) += bma220_spi.o
> diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
> index f1df89d..3b84cb2 100644
> --- a/drivers/iio/accel/adxl372.c
> +++ b/drivers/iio/accel/adxl372.c
> @@ -26,7 +26,6 @@
> #define ADXL372_DEVID0x00
> #define ADXL372_DEVID_MST0x01
> #define ADXL372_PARTID 0x02
> -#define ADXL372_REVID0x03
> #define ADXL372_STATUS_1 0x04
> #define ADXL372_STATUS_2 0x05
> #define ADXL372_FIFO_ENTRIES_2 0x06
> diff --git a/drivers/iio/accel/adxl372.h b/drivers/iio/accel/adxl372.h
> index 5da89b1..80a0aa9 100644
> --- a/drivers/iio/accel/adxl372.h
> +++ b/drivers/iio/accel/adxl372.h
> @@ -8,6 +8,8 @@
> #ifndef _ADXL372_H_
> #define _ADXL372_H_
>
> +#define ADXL372_REVID0x03
> +
> int adxl372_probe(struct device *dev, struct regmap *regmap,
> int irq, const char *name);
> bool adxl372_readable_noinc_reg(struct device *dev, unsigned int reg);
> diff --git a/drivers/iio/accel/adxl372_i2c.c b/drivers/iio/accel/adxl372_i2c.c
> new file mode 100644
> index 000..e1affe4
> --- /dev/null
> +++ b/drivers/iio/accel/adxl372_i2c.c
> @@ -0,0 +1,61 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/*
> + * ADXL372 3-Axis Digital Accelerometer I2C driver
> + *
> + * Copyright 2018 Analog Devices Inc.
> + */
> +
> +#include
> +#include
> +#include
> +
> +#include "adxl372.h"
> +
> +static const struct regmap_config adxl372_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .readable_noinc_reg = adxl372_readable_noinc_reg,
> +};
> +
> +static int adxl372_i2c_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + struct regmap *regmap;
> + unsigned int regval;
> + int ret;
> +
> + regmap = devm_regmap_init_i2c(client, _regmap_config);
> + if (IS_ERR(regmap))
> + return PTR_ERR(regmap);
> +
> + ret = regmap_read(regmap, ADXL372_REVID, );
> + if (ret < 0)
> + return ret;
> +
> + /* Starting with the 3rd revision an I2C chip bug was fixed */
> + if (regval < 3)
> + dev_warn(>dev,
> + "I2C might not work properly with other devices on the bus");
> +
> + return adxl372_probe(>dev, regmap, client->irq, id->name);
> +}
> +
> +static const struct i2c_device_id adxl372_i2c_id[] = {
> + { "adxl372", 0 },
> + {}
> +};
> +MODULE_DEVICE_TABLE(i2c, adxl372_i2c_id);
> +
Re: [PATCH 1/3] iio: adxl372: Refactor the driver
On Tue, 4 Sep 2018 17:11:31 +0300
Stefan Popa wrote:
> This patch restructures the existing adxl372 driver by adding a module for
> SPI and a header file, while the baseline module deals with the chip-logic.
>
> This is a necessary step, as this driver should support in the future
> a similar device which differs only in the type of interface used (I2C
> instead of SPI).
>
> Signed-off-by: Stefan Popa
One comment inline on an area where we haven't been that consistent...
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to play with it.
Thanks,
Jonathan
> ---
> MAINTAINERS | 1 +
> drivers/iio/accel/Kconfig | 11 +--
> drivers/iio/accel/Makefile | 1 +
> drivers/iio/accel/adxl372.c | 73
> ++---
> drivers/iio/accel/adxl372.h | 15 +
> drivers/iio/accel/adxl372_spi.c | 52 +
> 6 files changed, 102 insertions(+), 51 deletions(-)
> create mode 100644 drivers/iio/accel/adxl372.h
> create mode 100644 drivers/iio/accel/adxl372_spi.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2bfc9b0..2938632 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -548,6 +548,7 @@ M:Stefan Popa
> W: http://ez.analog.com/community/linux-device-drivers
> S: Supported
> F: drivers/iio/accel/adxl372.c
> +F: drivers/iio/accel/adxl372_spi.c
> F: Documentation/devicetree/bindings/iio/accel/adxl372.txt
>
> AF9013 MEDIA DRIVER
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index eae23d6..bed5da8 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -61,15 +61,20 @@ config ADXL345_SPI
> for the core module.
>
> config ADXL372
> - tristate "Analog Devices ADXL372 3-Axis Accelerometer Driver"
> - depends on SPI
> + tristate
> select IIO_BUFFER
> select IIO_TRIGGERED_BUFFER
Hmm. I'm in too minds about this (and it's come up quite a few times before).
The issue is trading off configuration complexity against flexibility to
configure a minimum build.
So either:
1. Two config options for the user to select.
2. One option that will build the i2c / spi dependent on their being support
for these busses built.
This second is what for example the bmc150 does in this same file. The
It leads to a cleaner menuconfig.
The first is done by mma7455.
At somepoint we should probably decide to clean this up but for now there
is a mix so I'm not going to block this patch on making that decision.
> +
> +config ADXL372_SPI
> + tristate "Analog Devices ADXL372 3-Axis Accelerometer SPI Driver"
> + depends on SPI
> + select ADXL372
> + select REGMAP_SPI
> help
> Say yes here to add support for the Analog Devices ADXL372 triaxial
> acceleration sensor.
> To compile this driver as a module, choose M here: the
> - module will be called adxl372.
> + module will be called adxl372_spi.
>
> config BMA180
> tristate "Bosch BMA180/BMA250 3-Axis Accelerometer Driver"
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index 5758ffc..c9c5db9 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_ADXL345) += adxl345_core.o
> obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o
> obj-$(CONFIG_ADXL345_SPI) += adxl345_spi.o
> obj-$(CONFIG_ADXL372) += adxl372.o
> +obj-$(CONFIG_ADXL372_SPI) += adxl372_spi.o
> obj-$(CONFIG_BMA180) += bma180.o
> obj-$(CONFIG_BMA220) += bma220_spi.o
> obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel-core.o
> diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
> index fdaaa58..f1df89d 100644
> --- a/drivers/iio/accel/adxl372.c
> +++ b/drivers/iio/accel/adxl372.c
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> - * ADXL372 3-Axis Digital Accelerometer SPI driver
> + * ADXL372 3-Axis Digital Accelerometer core driver
> *
> * Copyright 2018 Analog Devices Inc.
> */
> @@ -20,6 +20,8 @@
> #include
> #include
>
> +#include "adxl372.h"
> +
> /* ADXL372 registers definition */
> #define ADXL372_DEVID0x00
> #define ADXL372_DEVID_MST0x01
> @@ -246,7 +248,8 @@ static const struct iio_chan_spec adxl372_channels[] = {
> };
>
> struct adxl372_state {
> - struct spi_device *spi;
> + int irq;
> + struct device *dev;
> struct regmap *regmap;
> struct iio_trigger *dready_trig;
> enum adxl372_fifo_mode fifo_mode;
> @@ -565,7 +568,7 @@ static int adxl372_setup(struct adxl372_state *st)
> return ret;
>
> if (regval != ADXL372_DEVID_VAL) {
> - dev_err(>spi->dev, "Invalid chip id %x\n", regval);
> + dev_err(st->dev, "Invalid chip id %x\n", regval);
> return -ENODEV;
> }
>
>
[PATCH 01/11] compat_ioctl: remove keyboard ioctl translation
The KD* family of ioctls is implemented in two drivers:
drivers/tty/vt and drivers/s390/char/tty3270.c. Both of them
have compat handlers for all their ioctl commands, so translation
in fs/compat_ioctl.c is never used.
Commit fb07a5f857ac ("compat_ioctl: remove all VT ioctl handling")
removed the compat handling for all the other VT ioctls back in
2009, but it seems I missed the keyboard ones back then.
Signed-off-by: Arnd Bergmann
---
fs/compat_ioctl.c | 26 --
1 file changed, 26 deletions(-)
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index 9237076bdcf5..4c2f83a386a2 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -546,23 +546,6 @@ COMPATIBLE_IOCTL(FIGETBSZ)
COMPATIBLE_IOCTL(FIFREEZE)
COMPATIBLE_IOCTL(FITHAW)
COMPATIBLE_IOCTL(FITRIM)
-COMPATIBLE_IOCTL(KDGETKEYCODE)
-COMPATIBLE_IOCTL(KDSETKEYCODE)
-COMPATIBLE_IOCTL(KDGKBTYPE)
-COMPATIBLE_IOCTL(KDGETMODE)
-COMPATIBLE_IOCTL(KDGKBMODE)
-COMPATIBLE_IOCTL(KDGKBMETA)
-COMPATIBLE_IOCTL(KDGKBENT)
-COMPATIBLE_IOCTL(KDSKBENT)
-COMPATIBLE_IOCTL(KDGKBSENT)
-COMPATIBLE_IOCTL(KDSKBSENT)
-COMPATIBLE_IOCTL(KDGKBDIACR)
-COMPATIBLE_IOCTL(KDSKBDIACR)
-COMPATIBLE_IOCTL(KDGKBDIACRUC)
-COMPATIBLE_IOCTL(KDSKBDIACRUC)
-COMPATIBLE_IOCTL(KDKBDREP)
-COMPATIBLE_IOCTL(KDGKBLED)
-COMPATIBLE_IOCTL(KDGETLED)
#ifdef CONFIG_BLOCK
/* Big S */
COMPATIBLE_IOCTL(SCSI_IOCTL_GET_IDLUN)
@@ -974,15 +957,6 @@ static long do_ioctl_trans(unsigned int cmd,
case HOT_ADD_DISK:
case SET_DISK_FAULTY:
case SET_BITMAP_FILE:
- /* Big K */
- case KDSIGACCEPT:
- case KIOCSOUND:
- case KDMKTONE:
- case KDSETMODE:
- case KDSKBMODE:
- case KDSKBMETA:
- case KDSKBLED:
- case KDSETLED:
return vfs_ioctl(file, cmd, arg);
}
--
2.18.0
[PATCH 01/11] compat_ioctl: remove keyboard ioctl translation
The KD* family of ioctls is implemented in two drivers:
drivers/tty/vt and drivers/s390/char/tty3270.c. Both of them
have compat handlers for all their ioctl commands, so translation
in fs/compat_ioctl.c is never used.
Commit fb07a5f857ac ("compat_ioctl: remove all VT ioctl handling")
removed the compat handling for all the other VT ioctls back in
2009, but it seems I missed the keyboard ones back then.
Signed-off-by: Arnd Bergmann
---
fs/compat_ioctl.c | 26 --
1 file changed, 26 deletions(-)
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index 9237076bdcf5..4c2f83a386a2 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -546,23 +546,6 @@ COMPATIBLE_IOCTL(FIGETBSZ)
COMPATIBLE_IOCTL(FIFREEZE)
COMPATIBLE_IOCTL(FITHAW)
COMPATIBLE_IOCTL(FITRIM)
-COMPATIBLE_IOCTL(KDGETKEYCODE)
-COMPATIBLE_IOCTL(KDSETKEYCODE)
-COMPATIBLE_IOCTL(KDGKBTYPE)
-COMPATIBLE_IOCTL(KDGETMODE)
-COMPATIBLE_IOCTL(KDGKBMODE)
-COMPATIBLE_IOCTL(KDGKBMETA)
-COMPATIBLE_IOCTL(KDGKBENT)
-COMPATIBLE_IOCTL(KDSKBENT)
-COMPATIBLE_IOCTL(KDGKBSENT)
-COMPATIBLE_IOCTL(KDSKBSENT)
-COMPATIBLE_IOCTL(KDGKBDIACR)
-COMPATIBLE_IOCTL(KDSKBDIACR)
-COMPATIBLE_IOCTL(KDGKBDIACRUC)
-COMPATIBLE_IOCTL(KDSKBDIACRUC)
-COMPATIBLE_IOCTL(KDKBDREP)
-COMPATIBLE_IOCTL(KDGKBLED)
-COMPATIBLE_IOCTL(KDGETLED)
#ifdef CONFIG_BLOCK
/* Big S */
COMPATIBLE_IOCTL(SCSI_IOCTL_GET_IDLUN)
@@ -974,15 +957,6 @@ static long do_ioctl_trans(unsigned int cmd,
case HOT_ADD_DISK:
case SET_DISK_FAULTY:
case SET_BITMAP_FILE:
- /* Big K */
- case KDSIGACCEPT:
- case KIOCSOUND:
- case KDMKTONE:
- case KDSETMODE:
- case KDSKBMODE:
- case KDSKBMETA:
- case KDSKBLED:
- case KDSETLED:
return vfs_ioctl(file, cmd, arg);
}
--
2.18.0
Re: [PATCH 1/3] iio: adxl372: Refactor the driver
On Tue, 4 Sep 2018 17:11:31 +0300
Stefan Popa wrote:
> This patch restructures the existing adxl372 driver by adding a module for
> SPI and a header file, while the baseline module deals with the chip-logic.
>
> This is a necessary step, as this driver should support in the future
> a similar device which differs only in the type of interface used (I2C
> instead of SPI).
>
> Signed-off-by: Stefan Popa
One comment inline on an area where we haven't been that consistent...
Applied to the togreg branch of iio.git and pushed out as testing for the
autobuilders to play with it.
Thanks,
Jonathan
> ---
> MAINTAINERS | 1 +
> drivers/iio/accel/Kconfig | 11 +--
> drivers/iio/accel/Makefile | 1 +
> drivers/iio/accel/adxl372.c | 73
> ++---
> drivers/iio/accel/adxl372.h | 15 +
> drivers/iio/accel/adxl372_spi.c | 52 +
> 6 files changed, 102 insertions(+), 51 deletions(-)
> create mode 100644 drivers/iio/accel/adxl372.h
> create mode 100644 drivers/iio/accel/adxl372_spi.c
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2bfc9b0..2938632 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -548,6 +548,7 @@ M:Stefan Popa
> W: http://ez.analog.com/community/linux-device-drivers
> S: Supported
> F: drivers/iio/accel/adxl372.c
> +F: drivers/iio/accel/adxl372_spi.c
> F: Documentation/devicetree/bindings/iio/accel/adxl372.txt
>
> AF9013 MEDIA DRIVER
> diff --git a/drivers/iio/accel/Kconfig b/drivers/iio/accel/Kconfig
> index eae23d6..bed5da8 100644
> --- a/drivers/iio/accel/Kconfig
> +++ b/drivers/iio/accel/Kconfig
> @@ -61,15 +61,20 @@ config ADXL345_SPI
> for the core module.
>
> config ADXL372
> - tristate "Analog Devices ADXL372 3-Axis Accelerometer Driver"
> - depends on SPI
> + tristate
> select IIO_BUFFER
> select IIO_TRIGGERED_BUFFER
Hmm. I'm in too minds about this (and it's come up quite a few times before).
The issue is trading off configuration complexity against flexibility to
configure a minimum build.
So either:
1. Two config options for the user to select.
2. One option that will build the i2c / spi dependent on their being support
for these busses built.
This second is what for example the bmc150 does in this same file. The
It leads to a cleaner menuconfig.
The first is done by mma7455.
At somepoint we should probably decide to clean this up but for now there
is a mix so I'm not going to block this patch on making that decision.
> +
> +config ADXL372_SPI
> + tristate "Analog Devices ADXL372 3-Axis Accelerometer SPI Driver"
> + depends on SPI
> + select ADXL372
> + select REGMAP_SPI
> help
> Say yes here to add support for the Analog Devices ADXL372 triaxial
> acceleration sensor.
> To compile this driver as a module, choose M here: the
> - module will be called adxl372.
> + module will be called adxl372_spi.
>
> config BMA180
> tristate "Bosch BMA180/BMA250 3-Axis Accelerometer Driver"
> diff --git a/drivers/iio/accel/Makefile b/drivers/iio/accel/Makefile
> index 5758ffc..c9c5db9 100644
> --- a/drivers/iio/accel/Makefile
> +++ b/drivers/iio/accel/Makefile
> @@ -10,6 +10,7 @@ obj-$(CONFIG_ADXL345) += adxl345_core.o
> obj-$(CONFIG_ADXL345_I2C) += adxl345_i2c.o
> obj-$(CONFIG_ADXL345_SPI) += adxl345_spi.o
> obj-$(CONFIG_ADXL372) += adxl372.o
> +obj-$(CONFIG_ADXL372_SPI) += adxl372_spi.o
> obj-$(CONFIG_BMA180) += bma180.o
> obj-$(CONFIG_BMA220) += bma220_spi.o
> obj-$(CONFIG_BMC150_ACCEL) += bmc150-accel-core.o
> diff --git a/drivers/iio/accel/adxl372.c b/drivers/iio/accel/adxl372.c
> index fdaaa58..f1df89d 100644
> --- a/drivers/iio/accel/adxl372.c
> +++ b/drivers/iio/accel/adxl372.c
> @@ -1,6 +1,6 @@
> // SPDX-License-Identifier: GPL-2.0+
> /*
> - * ADXL372 3-Axis Digital Accelerometer SPI driver
> + * ADXL372 3-Axis Digital Accelerometer core driver
> *
> * Copyright 2018 Analog Devices Inc.
> */
> @@ -20,6 +20,8 @@
> #include
> #include
>
> +#include "adxl372.h"
> +
> /* ADXL372 registers definition */
> #define ADXL372_DEVID0x00
> #define ADXL372_DEVID_MST0x01
> @@ -246,7 +248,8 @@ static const struct iio_chan_spec adxl372_channels[] = {
> };
>
> struct adxl372_state {
> - struct spi_device *spi;
> + int irq;
> + struct device *dev;
> struct regmap *regmap;
> struct iio_trigger *dready_trig;
> enum adxl372_fifo_mode fifo_mode;
> @@ -565,7 +568,7 @@ static int adxl372_setup(struct adxl372_state *st)
> return ret;
>
> if (regval != ADXL372_DEVID_VAL) {
> - dev_err(>spi->dev, "Invalid chip id %x\n", regval);
> + dev_err(st->dev, "Invalid chip id %x\n", regval);
> return -ENODEV;
> }
>
>
[PATCH 02/11] compat_ioctl: remove HIDIO translation
The two drivers implementing these both gained proper compat_ioctl()
handlers a long time ago with commits bb6c8d8fa9b5 ("HID: hiddev:
Add 32bit ioctl compatibilty") and ae5e49c79c05 ("HID: hidraw: add
compatibility ioctl() for 32-bit applications."), so the lists in
fs/compat_ioctl.c are no longer used.
It appears that the lists were also incomplete, so the translation
didn't actually work correctly when it was still in use.
Remove them as cleanup.
Signed-off-by: Arnd Bergmann
---
fs/compat_ioctl.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index 4c2f83a386a2..c2c73b802fb3 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -853,23 +853,6 @@ COMPATIBLE_IOCTL(PCIIOC_CONTROLLER)
COMPATIBLE_IOCTL(PCIIOC_MMAP_IS_IO)
COMPATIBLE_IOCTL(PCIIOC_MMAP_IS_MEM)
COMPATIBLE_IOCTL(PCIIOC_WRITE_COMBINE)
-/* hiddev */
-COMPATIBLE_IOCTL(HIDIOCGVERSION)
-COMPATIBLE_IOCTL(HIDIOCAPPLICATION)
-COMPATIBLE_IOCTL(HIDIOCGDEVINFO)
-COMPATIBLE_IOCTL(HIDIOCGSTRING)
-COMPATIBLE_IOCTL(HIDIOCINITREPORT)
-COMPATIBLE_IOCTL(HIDIOCGREPORT)
-COMPATIBLE_IOCTL(HIDIOCSREPORT)
-COMPATIBLE_IOCTL(HIDIOCGREPORTINFO)
-COMPATIBLE_IOCTL(HIDIOCGFIELDINFO)
-COMPATIBLE_IOCTL(HIDIOCGUSAGE)
-COMPATIBLE_IOCTL(HIDIOCSUSAGE)
-COMPATIBLE_IOCTL(HIDIOCGUCODE)
-COMPATIBLE_IOCTL(HIDIOCGFLAG)
-COMPATIBLE_IOCTL(HIDIOCSFLAG)
-COMPATIBLE_IOCTL(HIDIOCGCOLLECTIONINDEX)
-COMPATIBLE_IOCTL(HIDIOCGCOLLECTIONINFO)
/* joystick */
COMPATIBLE_IOCTL(JSIOCGVERSION)
COMPATIBLE_IOCTL(JSIOCGAXES)
--
2.18.0
[PATCH 02/11] compat_ioctl: remove HIDIO translation
The two drivers implementing these both gained proper compat_ioctl()
handlers a long time ago with commits bb6c8d8fa9b5 ("HID: hiddev:
Add 32bit ioctl compatibilty") and ae5e49c79c05 ("HID: hidraw: add
compatibility ioctl() for 32-bit applications."), so the lists in
fs/compat_ioctl.c are no longer used.
It appears that the lists were also incomplete, so the translation
didn't actually work correctly when it was still in use.
Remove them as cleanup.
Signed-off-by: Arnd Bergmann
---
fs/compat_ioctl.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c
index 4c2f83a386a2..c2c73b802fb3 100644
--- a/fs/compat_ioctl.c
+++ b/fs/compat_ioctl.c
@@ -853,23 +853,6 @@ COMPATIBLE_IOCTL(PCIIOC_CONTROLLER)
COMPATIBLE_IOCTL(PCIIOC_MMAP_IS_IO)
COMPATIBLE_IOCTL(PCIIOC_MMAP_IS_MEM)
COMPATIBLE_IOCTL(PCIIOC_WRITE_COMBINE)
-/* hiddev */
-COMPATIBLE_IOCTL(HIDIOCGVERSION)
-COMPATIBLE_IOCTL(HIDIOCAPPLICATION)
-COMPATIBLE_IOCTL(HIDIOCGDEVINFO)
-COMPATIBLE_IOCTL(HIDIOCGSTRING)
-COMPATIBLE_IOCTL(HIDIOCINITREPORT)
-COMPATIBLE_IOCTL(HIDIOCGREPORT)
-COMPATIBLE_IOCTL(HIDIOCSREPORT)
-COMPATIBLE_IOCTL(HIDIOCGREPORTINFO)
-COMPATIBLE_IOCTL(HIDIOCGFIELDINFO)
-COMPATIBLE_IOCTL(HIDIOCGUSAGE)
-COMPATIBLE_IOCTL(HIDIOCSUSAGE)
-COMPATIBLE_IOCTL(HIDIOCGUCODE)
-COMPATIBLE_IOCTL(HIDIOCGFLAG)
-COMPATIBLE_IOCTL(HIDIOCSFLAG)
-COMPATIBLE_IOCTL(HIDIOCGCOLLECTIONINDEX)
-COMPATIBLE_IOCTL(HIDIOCGCOLLECTIONINFO)
/* joystick */
COMPATIBLE_IOCTL(JSIOCGVERSION)
COMPATIBLE_IOCTL(JSIOCGAXES)
--
2.18.0
Re: [PATCH] iio: remove unnecessary condition judgment in am2315_trigger_handler
On Sat, 8 Sep 2018 17:59:13 +0530
Himanshu Jha wrote:
> On Sat, Sep 08, 2018 at 06:57:36PM +0800, zhong jiang wrote:
> > The iterator in for_each_set_bit is never null, therefore, remove
> > the redundant conditional judgment.
> >
> > Signed-off-by: zhong jiang
> > ---
> > drivers/iio/humidity/am2315.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/iio/humidity/am2315.c b/drivers/iio/humidity/am2315.c
> > index 7d8669d..dc12e37 100644
> > --- a/drivers/iio/humidity/am2315.c
> > +++ b/drivers/iio/humidity/am2315.c
> > @@ -176,8 +176,7 @@ static irqreturn_t am2315_trigger_handler(int irq, void
> > *p)
> > i = 0;
> > for_each_set_bit(bit, indio_dev->active_scan_mask,
> > indio_dev->masklength) {
> > - data->buffer[i] = (bit ? sensor_data.temp_data :
> > -sensor_data.hum_data);
> > + data->buffer[i] = sensor_data.temp_data;
>
> No, this seems wrong!
>
> We have buffer support to either take both readings(temp & humid)
> simultaneously, or only single channel using specified scan mask.
Key think is that bit most definitely can be 0 if the 0th bit is set.
This isn't a null check at all.
I'm curious, was this a by inspection case or did some script throw
this one up?
Thanks,
Jonathan
>
> Patch title should be:
>
> "iio: humidity: am2315: .. "
>
>
> Thanks
Re: [PATCH] iio: remove unnecessary condition judgment in am2315_trigger_handler
On Sat, 8 Sep 2018 17:59:13 +0530
Himanshu Jha wrote:
> On Sat, Sep 08, 2018 at 06:57:36PM +0800, zhong jiang wrote:
> > The iterator in for_each_set_bit is never null, therefore, remove
> > the redundant conditional judgment.
> >
> > Signed-off-by: zhong jiang
> > ---
> > drivers/iio/humidity/am2315.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/iio/humidity/am2315.c b/drivers/iio/humidity/am2315.c
> > index 7d8669d..dc12e37 100644
> > --- a/drivers/iio/humidity/am2315.c
> > +++ b/drivers/iio/humidity/am2315.c
> > @@ -176,8 +176,7 @@ static irqreturn_t am2315_trigger_handler(int irq, void
> > *p)
> > i = 0;
> > for_each_set_bit(bit, indio_dev->active_scan_mask,
> > indio_dev->masklength) {
> > - data->buffer[i] = (bit ? sensor_data.temp_data :
> > -sensor_data.hum_data);
> > + data->buffer[i] = sensor_data.temp_data;
>
> No, this seems wrong!
>
> We have buffer support to either take both readings(temp & humid)
> simultaneously, or only single channel using specified scan mask.
Key think is that bit most definitely can be 0 if the 0th bit is set.
This isn't a null check at all.
I'm curious, was this a by inspection case or did some script throw
this one up?
Thanks,
Jonathan
>
> Patch title should be:
>
> "iio: humidity: am2315: .. "
>
>
> Thanks
Re: [PATCH] mm: memcontrol: print proper OOM header when no eligible victim left
On 2018/09/08 22:57, Johannes Weiner wrote:
> On Sat, Sep 08, 2018 at 10:36:06PM +0900, Tetsuo Handa wrote:
>> Due to commit d75da004c708c9fc ("oom: improve oom disable handling") and
>> commit 3100dab2aa09dc6e ("mm: memcontrol: print proper OOM header when
>> no eligible victim left"), all
>>
>> kworker/0:1 invoked oom-killer: gfp_mask=0x6000c0(GFP_KERNEL),
>> nodemask=(null), order=-1, oom_score_adj=0
>> (...snipped...)
>> Out of memory and no killable processes...
>> OOM request ignored. No task eligible
>>
>> lines are printed.
>
> This doesn't explain the context, what you were trying to do here, and
> what you expected to happen. Plus, you (...snipped...) the important
> part to understand why it failed in the first place.
I expect:
When SysRq-f did not find killable processes, it does not emit
message other than "OOM request ignored. No task eligible".
There is no point with emitting memory information etc.
>
>> Let's not emit "invoked oom-killer" lines when SysRq-f failed.
>
> I disagree. If the user asked for an OOM kill, it makes perfect sense
> to dump the memory context and the outcome of the operation - even if
> the outcome is "I didn't find anything to kill". I'd argue that the
> failure case *in particular* is where I want to know about and have
> all the information that could help me understand why it failed.
How emitting memory information etc. helps you understand why it failed?
"No task eligible" is sufficient for you to understand why, isn't it?
>
> So NAK on the inferred patch premise, but please include way more
> rationale, reproduction scenario etc. in future patches. It's not at
> all clear *why* you think it should work the way you propose here.
>
Re: [PATCH] mm: memcontrol: print proper OOM header when no eligible victim left
On 2018/09/08 22:57, Johannes Weiner wrote:
> On Sat, Sep 08, 2018 at 10:36:06PM +0900, Tetsuo Handa wrote:
>> Due to commit d75da004c708c9fc ("oom: improve oom disable handling") and
>> commit 3100dab2aa09dc6e ("mm: memcontrol: print proper OOM header when
>> no eligible victim left"), all
>>
>> kworker/0:1 invoked oom-killer: gfp_mask=0x6000c0(GFP_KERNEL),
>> nodemask=(null), order=-1, oom_score_adj=0
>> (...snipped...)
>> Out of memory and no killable processes...
>> OOM request ignored. No task eligible
>>
>> lines are printed.
>
> This doesn't explain the context, what you were trying to do here, and
> what you expected to happen. Plus, you (...snipped...) the important
> part to understand why it failed in the first place.
I expect:
When SysRq-f did not find killable processes, it does not emit
message other than "OOM request ignored. No task eligible".
There is no point with emitting memory information etc.
>
>> Let's not emit "invoked oom-killer" lines when SysRq-f failed.
>
> I disagree. If the user asked for an OOM kill, it makes perfect sense
> to dump the memory context and the outcome of the operation - even if
> the outcome is "I didn't find anything to kill". I'd argue that the
> failure case *in particular* is where I want to know about and have
> all the information that could help me understand why it failed.
How emitting memory information etc. helps you understand why it failed?
"No task eligible" is sufficient for you to understand why, isn't it?
>
> So NAK on the inferred patch premise, but please include way more
> rationale, reproduction scenario etc. in future patches. It's not at
> all clear *why* you think it should work the way you propose here.
>
Re: [PATCH v2 3/3] arm64: dts: qcom: pm8998: Add die temperature channel node to the ADC
On Thu, 6 Sep 2018 14:22:06 -0700 Matthias Kaehlcke wrote: > On Thu, Sep 06, 2018 at 02:10:43PM -0700, Doug Anderson wrote: > > Hi, > > > > On Thu, Sep 6, 2018 at 2:04 PM, Matthias Kaehlcke > > wrote: > > > Add a channel node for the die temperature to the ADC. > > > > > > Signed-off-by: Matthias Kaehlcke > > > Reviewed-by: Douglas Anderson > > > Signed-off-by: Matthias Kaehlcke > > > > Double-SoB? > > I must have run 'amend' with '-s' out of habit, which wasn't the right > thing to do in this case :/ > > > ...presumably Andy can remove that when he lands and doesn't need a > > re-post... > > Andy, in case you need me to repost let me know. Slightly worse than that (as was patch 1). You accidentally used -- rather than --- to separate the change log. So I ended up with Signed-off-by: M.. Reviewed-by: .. Signed-off-by: M.. -- Changelog Signed-off-by: J Good think the double signed off was raised as chances are I wouldn't have notice it. Jonathan > > Thanks > > Matthias
Re: [PATCH v2 3/3] arm64: dts: qcom: pm8998: Add die temperature channel node to the ADC
On Thu, 6 Sep 2018 14:22:06 -0700 Matthias Kaehlcke wrote: > On Thu, Sep 06, 2018 at 02:10:43PM -0700, Doug Anderson wrote: > > Hi, > > > > On Thu, Sep 6, 2018 at 2:04 PM, Matthias Kaehlcke > > wrote: > > > Add a channel node for the die temperature to the ADC. > > > > > > Signed-off-by: Matthias Kaehlcke > > > Reviewed-by: Douglas Anderson > > > Signed-off-by: Matthias Kaehlcke > > > > Double-SoB? > > I must have run 'amend' with '-s' out of habit, which wasn't the right > thing to do in this case :/ > > > ...presumably Andy can remove that when he lands and doesn't need a > > re-post... > > Andy, in case you need me to repost let me know. Slightly worse than that (as was patch 1). You accidentally used -- rather than --- to separate the change log. So I ended up with Signed-off-by: M.. Reviewed-by: .. Signed-off-by: M.. -- Changelog Signed-off-by: J Good think the double signed off was raised as chances are I wouldn't have notice it. Jonathan > > Thanks > > Matthias
Re: [PATCH v2 1/3] dt-bindings: iio: vadc: Fix documentation of 'reg'
On Thu, 6 Sep 2018 14:04:52 -0700
Matthias Kaehlcke wrote:
> The documentation of Qualcomm's SPMI PMIC voltage ADC claims that the
> 'reg' property consists of two values, the SPMI address and the length
> of the controller's registers. However the SPMI bus to which it is added
> specifies "#size-cells = <0>;". Remove the controller register length
> from the documentation of the field and the example.
>
> Signed-off-by: Matthias Kaehlcke
> Reviewed-by: Douglas Anderson
> Reviewed-by: Rob Herring
> Signed-off-by: Matthias Kaehlcke
Applied to the togreg branch of iio.git.
Thanks,
Jonathan
> --
> Changes in v2:
> - none
> ---
> Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
> b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
> index 0fb46137f936..d0c188e5c922 100644
> --- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
> @@ -13,7 +13,7 @@ VADC node:
> - reg:
> Usage: required
> Value type:
> -Definition: VADC base address and length in the SPMI PMIC register map.
> +Definition: VADC base address in the SPMI PMIC register map.
>
> - #address-cells:
> Usage: required
> @@ -104,7 +104,7 @@ Example:
> /* VADC node */
> pmic_vadc: vadc@3100 {
> compatible = "qcom,spmi-vadc";
> - reg = <0x3100 0x100>;
> + reg = <0x3100>;
> interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
> #address-cells = <1>;
> #size-cells = <0>;
Re: [PATCH v2 1/3] dt-bindings: iio: vadc: Fix documentation of 'reg'
On Thu, 6 Sep 2018 14:04:52 -0700
Matthias Kaehlcke wrote:
> The documentation of Qualcomm's SPMI PMIC voltage ADC claims that the
> 'reg' property consists of two values, the SPMI address and the length
> of the controller's registers. However the SPMI bus to which it is added
> specifies "#size-cells = <0>;". Remove the controller register length
> from the documentation of the field and the example.
>
> Signed-off-by: Matthias Kaehlcke
> Reviewed-by: Douglas Anderson
> Reviewed-by: Rob Herring
> Signed-off-by: Matthias Kaehlcke
Applied to the togreg branch of iio.git.
Thanks,
Jonathan
> --
> Changes in v2:
> - none
> ---
> Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
> b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
> index 0fb46137f936..d0c188e5c922 100644
> --- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
> +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-vadc.txt
> @@ -13,7 +13,7 @@ VADC node:
> - reg:
> Usage: required
> Value type:
> -Definition: VADC base address and length in the SPMI PMIC register map.
> +Definition: VADC base address in the SPMI PMIC register map.
>
> - #address-cells:
> Usage: required
> @@ -104,7 +104,7 @@ Example:
> /* VADC node */
> pmic_vadc: vadc@3100 {
> compatible = "qcom,spmi-vadc";
> - reg = <0x3100 0x100>;
> + reg = <0x3100>;
> interrupts = <0x0 0x31 0x0 IRQ_TYPE_EDGE_RISING>;
> #address-cells = <1>;
> #size-cells = <0>;
Re: [PATCH v2 1/4] iio: gyro: add support for fxas21002c
On Tue, 04 Sep 2018 20:23:57 +0100 Afonso Bordado wrote: > On Fri, 2018-08-31 at 17:35 +0200, Tomasz Duszynski wrote: > > On Thu, Aug 30, 2018 at 10:18:22PM +0100, Afonso Bordado wrote: > > > FXAS21002C is a 3 axis gyroscope with integrated temperature sensor Just a quick hint to make my life easier (as I tend to try and keep up with all these threads). Also helps the person you are responding to. If you are just going to agree with a suggestion in a review, either don't reply at all (the next version with it fixed does that job :) or cut out all the rest of the patch just leaving the relevant section. I'm having a moan about this today though it's not really a big thing. Jonathan > > > > > > Signed-off-by: Afonso Bordado > > > --- > > > Changes in v2 > > >- Use ANSI C Comments > > >- Minor cleanups > > >- More dscriptive devicetree bindings > > > > > > drivers/iio/gyro/Kconfig | 11 + > > > drivers/iio/gyro/Makefile | 1 + > > > drivers/iio/gyro/fxas21002c.c | 367 > > > ++ > > > 3 files changed, 379 insertions(+) > > > create mode 100644 drivers/iio/gyro/fxas21002c.c > > > > > > diff --git a/drivers/iio/gyro/Kconfig b/drivers/iio/gyro/Kconfig > > > index 3126cf05e6b9..d71e33ea9fa4 100644 > > > --- a/drivers/iio/gyro/Kconfig > > > +++ b/drivers/iio/gyro/Kconfig > > > @@ -73,6 +73,17 @@ config BMG160_SPI > > > tristate > > > select REGMAP_SPI > > > > > > +config FXAS21002C > > > + tristate "Freescale FXAS21002C Gyroscope" > > > + depends on I2C > > > + select REGMAP_I2C > > > + help > > > + Say yes here to build support for the Freescale FXAS21002C > > > Gyroscope > > > + driver connected via I2C. > > > + > > > + This driver can also be built as a module. If so, the module > > > + will be called fxas21002c. > > > + > > > config HID_SENSOR_GYRO_3D > > > depends on HID_SENSOR_HUB > > > select IIO_BUFFER > > > diff --git a/drivers/iio/gyro/Makefile b/drivers/iio/gyro/Makefile > > > index 295ec780c4eb..ec3e2aeae92a 100644 > > > --- a/drivers/iio/gyro/Makefile > > > +++ b/drivers/iio/gyro/Makefile > > > @@ -12,6 +12,7 @@ obj-$(CONFIG_ADXRS450) += adxrs450.o > > > obj-$(CONFIG_BMG160) += bmg160_core.o > > > obj-$(CONFIG_BMG160_I2C) += bmg160_i2c.o > > > obj-$(CONFIG_BMG160_SPI) += bmg160_spi.o > > > +obj-$(CONFIG_FXAS21002C) += fxas21002c.o > > > > > > obj-$(CONFIG_HID_SENSOR_GYRO_3D) += hid-sensor-gyro-3d.o > > > > > > diff --git a/drivers/iio/gyro/fxas21002c.c > > > b/drivers/iio/gyro/fxas21002c.c > > > new file mode 100644 > > > index ..261b73629544 > > > --- /dev/null > > > +++ b/drivers/iio/gyro/fxas21002c.c > > > @@ -0,0 +1,367 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +/* > > > + * FXAS21002C - Digital Angular Rate Gyroscope driver > > > + * > > > + * Copyright (c) 2018, Afonso Bordado > > > + * > > > + * IIO driver for FXAS21002C (7-bit I2C slave address 0x20 or > > > 0x21). > > > + * Datasheet: https://www.nxp.com/docs/en/data-sheet/FXAS21002.pdf > > > + * TODO: > > > + *ODR / Scale Support > > > + *Devicetree > > > + *Power management > > > + *LowPass/HighPass Filters > > > + *Buffers > > > + *Interrupts > > > + *Alarms > > > + */ > > > + > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > + > > > +#define FXAS21002C_DRV_NAME "fxas21002c" > > > + > > > +#define FXAS21002C_MAX_TRANSITION_TIME_MS 61 > > > + > > > +#define FXAS21002C_CHIP_ID 0xD7 > > > + > > > +#define FXAS21002C_REG_STATUS 0x00 > > > +#define FXAS21002C_REG_OUT_X_MSB 0x01 > > > +#define FXAS21002C_REG_OUT_X_LSB 0x02 > > > +#define FXAS21002C_REG_OUT_Y_MSB 0x03 > > > +#define FXAS21002C_REG_OUT_Y_LSB 0x04 > > > +#define FXAS21002C_REG_OUT_Z_MSB 0x05 > > > +#define FXAS21002C_REG_OUT_Z_LSB 0x06 > > > +#define FXAS21002C_REG_DR_STATUS 0x07 > > > +#define FXAS21002C_REG_F_STATUS0x08 > > > +#define FXAS21002C_REG_F_SETUP 0x09 > > > +#define FXAS21002C_REG_F_EVENT 0x0A > > > +#define FXAS21002C_REG_INT_SRC_FLAG0x0B > > > +#define FXAS21002C_REG_WHO_AM_I0x0C > > > +#define FXAS21002C_REG_CTRL_REG0 0x0D > > > +#define FXAS21002C_REG_RT_CFG 0x0E > > > +#define FXAS21002C_REG_RT_SRC 0x0F > > > +#define FXAS21002C_REG_RT_THS 0x10 > > > +#define FXAS21002C_REG_RT_COUNT0x11 > > > +#define FXAS21002C_REG_TEMP0x12 > > > + > > > +#define FXAS21002C_REG_CTRL_REG1 0x13 > > > +#define FXAS21002C_RST_BIT BIT(6) > > > +#define FXAS21002C_ACTIVE_BIT BIT(1) > > > +#define FXAS21002C_READY_BIT BIT(0) > > > + > > > +#define FXAS21002C_REG_CTRL_REG2 0x14 > > > +#define FXAS21002C_REG_CTRL_REG3 0x15 > > > + > > > +#define FXAS21002C_DEFAULT_ODR_HZ 800 > > > + > > > +/* 0.0625 deg/s */ > > > +#define FXAS21002C_DEFAULT_SENSITIVITY
Re: [PATCH v2 1/4] iio: gyro: add support for fxas21002c
On Tue, 04 Sep 2018 20:23:57 +0100 Afonso Bordado wrote: > On Fri, 2018-08-31 at 17:35 +0200, Tomasz Duszynski wrote: > > On Thu, Aug 30, 2018 at 10:18:22PM +0100, Afonso Bordado wrote: > > > FXAS21002C is a 3 axis gyroscope with integrated temperature sensor Just a quick hint to make my life easier (as I tend to try and keep up with all these threads). Also helps the person you are responding to. If you are just going to agree with a suggestion in a review, either don't reply at all (the next version with it fixed does that job :) or cut out all the rest of the patch just leaving the relevant section. I'm having a moan about this today though it's not really a big thing. Jonathan > > > > > > Signed-off-by: Afonso Bordado > > > --- > > > Changes in v2 > > >- Use ANSI C Comments > > >- Minor cleanups > > >- More dscriptive devicetree bindings > > > > > > drivers/iio/gyro/Kconfig | 11 + > > > drivers/iio/gyro/Makefile | 1 + > > > drivers/iio/gyro/fxas21002c.c | 367 > > > ++ > > > 3 files changed, 379 insertions(+) > > > create mode 100644 drivers/iio/gyro/fxas21002c.c > > > > > > diff --git a/drivers/iio/gyro/Kconfig b/drivers/iio/gyro/Kconfig > > > index 3126cf05e6b9..d71e33ea9fa4 100644 > > > --- a/drivers/iio/gyro/Kconfig > > > +++ b/drivers/iio/gyro/Kconfig > > > @@ -73,6 +73,17 @@ config BMG160_SPI > > > tristate > > > select REGMAP_SPI > > > > > > +config FXAS21002C > > > + tristate "Freescale FXAS21002C Gyroscope" > > > + depends on I2C > > > + select REGMAP_I2C > > > + help > > > + Say yes here to build support for the Freescale FXAS21002C > > > Gyroscope > > > + driver connected via I2C. > > > + > > > + This driver can also be built as a module. If so, the module > > > + will be called fxas21002c. > > > + > > > config HID_SENSOR_GYRO_3D > > > depends on HID_SENSOR_HUB > > > select IIO_BUFFER > > > diff --git a/drivers/iio/gyro/Makefile b/drivers/iio/gyro/Makefile > > > index 295ec780c4eb..ec3e2aeae92a 100644 > > > --- a/drivers/iio/gyro/Makefile > > > +++ b/drivers/iio/gyro/Makefile > > > @@ -12,6 +12,7 @@ obj-$(CONFIG_ADXRS450) += adxrs450.o > > > obj-$(CONFIG_BMG160) += bmg160_core.o > > > obj-$(CONFIG_BMG160_I2C) += bmg160_i2c.o > > > obj-$(CONFIG_BMG160_SPI) += bmg160_spi.o > > > +obj-$(CONFIG_FXAS21002C) += fxas21002c.o > > > > > > obj-$(CONFIG_HID_SENSOR_GYRO_3D) += hid-sensor-gyro-3d.o > > > > > > diff --git a/drivers/iio/gyro/fxas21002c.c > > > b/drivers/iio/gyro/fxas21002c.c > > > new file mode 100644 > > > index ..261b73629544 > > > --- /dev/null > > > +++ b/drivers/iio/gyro/fxas21002c.c > > > @@ -0,0 +1,367 @@ > > > +// SPDX-License-Identifier: GPL-2.0 > > > +/* > > > + * FXAS21002C - Digital Angular Rate Gyroscope driver > > > + * > > > + * Copyright (c) 2018, Afonso Bordado > > > + * > > > + * IIO driver for FXAS21002C (7-bit I2C slave address 0x20 or > > > 0x21). > > > + * Datasheet: https://www.nxp.com/docs/en/data-sheet/FXAS21002.pdf > > > + * TODO: > > > + *ODR / Scale Support > > > + *Devicetree > > > + *Power management > > > + *LowPass/HighPass Filters > > > + *Buffers > > > + *Interrupts > > > + *Alarms > > > + */ > > > + > > > +#include > > > +#include > > > +#include > > > +#include > > > +#include > > > + > > > +#define FXAS21002C_DRV_NAME "fxas21002c" > > > + > > > +#define FXAS21002C_MAX_TRANSITION_TIME_MS 61 > > > + > > > +#define FXAS21002C_CHIP_ID 0xD7 > > > + > > > +#define FXAS21002C_REG_STATUS 0x00 > > > +#define FXAS21002C_REG_OUT_X_MSB 0x01 > > > +#define FXAS21002C_REG_OUT_X_LSB 0x02 > > > +#define FXAS21002C_REG_OUT_Y_MSB 0x03 > > > +#define FXAS21002C_REG_OUT_Y_LSB 0x04 > > > +#define FXAS21002C_REG_OUT_Z_MSB 0x05 > > > +#define FXAS21002C_REG_OUT_Z_LSB 0x06 > > > +#define FXAS21002C_REG_DR_STATUS 0x07 > > > +#define FXAS21002C_REG_F_STATUS0x08 > > > +#define FXAS21002C_REG_F_SETUP 0x09 > > > +#define FXAS21002C_REG_F_EVENT 0x0A > > > +#define FXAS21002C_REG_INT_SRC_FLAG0x0B > > > +#define FXAS21002C_REG_WHO_AM_I0x0C > > > +#define FXAS21002C_REG_CTRL_REG0 0x0D > > > +#define FXAS21002C_REG_RT_CFG 0x0E > > > +#define FXAS21002C_REG_RT_SRC 0x0F > > > +#define FXAS21002C_REG_RT_THS 0x10 > > > +#define FXAS21002C_REG_RT_COUNT0x11 > > > +#define FXAS21002C_REG_TEMP0x12 > > > + > > > +#define FXAS21002C_REG_CTRL_REG1 0x13 > > > +#define FXAS21002C_RST_BIT BIT(6) > > > +#define FXAS21002C_ACTIVE_BIT BIT(1) > > > +#define FXAS21002C_READY_BIT BIT(0) > > > + > > > +#define FXAS21002C_REG_CTRL_REG2 0x14 > > > +#define FXAS21002C_REG_CTRL_REG3 0x15 > > > + > > > +#define FXAS21002C_DEFAULT_ODR_HZ 800 > > > + > > > +/* 0.0625 deg/s */ > > > +#define FXAS21002C_DEFAULT_SENSITIVITY
Re: + mm-slab-shorten-kmalloc-cache-names-for-large-sizes.patch added to -mm tree
On Fri, Sep 07, 2018 at 10:58:16PM +0300, Alexey Dobriyan wrote:
> On Thu, Sep 06, 2018 at 03:48:49PM -0700, a...@linux-foundation.org wrote:
> > - {"kmalloc-1024", 1024}, {"kmalloc-2048", 2048},
> > - {"kmalloc-4096", 4096}, {"kmalloc-8192", 8192},
> > - {"kmalloc-16384", 16384}, {"kmalloc-32768", 32768},
> > - {"kmalloc-65536", 65536}, {"kmalloc-131072", 131072},
> > - {"kmalloc-262144", 262144}, {"kmalloc-524288", 524288},
> > - {"kmalloc-1048576", 1048576}, {"kmalloc-2097152", 2097152},
> > - {"kmalloc-4194304", 4194304}, {"kmalloc-8388608", 8388608},
> > - {"kmalloc-16777216", 16777216}, {"kmalloc-33554432", 33554432},
> > - {"kmalloc-67108864", 67108864}
> > + {"kmalloc-1k", 1024}, {"kmalloc-2k", 2048},
> > + {"kmalloc-4k", 4096}, {"kmalloc-8k", 8192},
> > + {"kmalloc-16k", 16384}, {"kmalloc-32k", 32768},
> > + {"kmalloc-64k", 65536}, {"kmalloc-128k", 131072},
> > + {"kmalloc-256k", 262144}, {"kmalloc-512k", 524288},
> > + {"kmalloc-1M",1048576}, {"kmalloc-2M",2097152},
> > + {"kmalloc-4M",4194304}, {"kmalloc-8M",8388608},
> > + {"kmalloc-16M", 16777216}, {"kmalloc-32M", 33554432},
> > + {"kmalloc-64M", 67108864}
>
> I'd rather use KB and MB suffixes or at least capital 'K'.
I like k and M better.
Re: + mm-slab-shorten-kmalloc-cache-names-for-large-sizes.patch added to -mm tree
On Fri, Sep 07, 2018 at 10:58:16PM +0300, Alexey Dobriyan wrote:
> On Thu, Sep 06, 2018 at 03:48:49PM -0700, a...@linux-foundation.org wrote:
> > - {"kmalloc-1024", 1024}, {"kmalloc-2048", 2048},
> > - {"kmalloc-4096", 4096}, {"kmalloc-8192", 8192},
> > - {"kmalloc-16384", 16384}, {"kmalloc-32768", 32768},
> > - {"kmalloc-65536", 65536}, {"kmalloc-131072", 131072},
> > - {"kmalloc-262144", 262144}, {"kmalloc-524288", 524288},
> > - {"kmalloc-1048576", 1048576}, {"kmalloc-2097152", 2097152},
> > - {"kmalloc-4194304", 4194304}, {"kmalloc-8388608", 8388608},
> > - {"kmalloc-16777216", 16777216}, {"kmalloc-33554432", 33554432},
> > - {"kmalloc-67108864", 67108864}
> > + {"kmalloc-1k", 1024}, {"kmalloc-2k", 2048},
> > + {"kmalloc-4k", 4096}, {"kmalloc-8k", 8192},
> > + {"kmalloc-16k", 16384}, {"kmalloc-32k", 32768},
> > + {"kmalloc-64k", 65536}, {"kmalloc-128k", 131072},
> > + {"kmalloc-256k", 262144}, {"kmalloc-512k", 524288},
> > + {"kmalloc-1M",1048576}, {"kmalloc-2M",2097152},
> > + {"kmalloc-4M",4194304}, {"kmalloc-8M",8388608},
> > + {"kmalloc-16M", 16777216}, {"kmalloc-32M", 33554432},
> > + {"kmalloc-64M", 67108864}
>
> I'd rather use KB and MB suffixes or at least capital 'K'.
I like k and M better.
Re: [PATCH 3.18 00/29] 3.18.122-stable review
On 09/07/2018 02:10 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.18.122 release. There are 29 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Sep 9 21:08:52 UTC 2018. Anything received after that time might be too late. Affects at least 3.18, 4.4, 4.9: Building powerpc:allmodconfig ... failed -- Error log: arch/powerpc/kernel/fadump.c: In function 'free_crash_memory_ranges': arch/powerpc/kernel/fadump.c:733:2: error: implicit declaration of function 'kfree' arch/powerpc/kernel/fadump.c: In function 'allocate_crash_memory_ranges': arch/powerpc/kernel/fadump.c:752:2: error: implicit declaration of function 'krealloc' Affects at least 4.9 (on top of the above): Building powerpc:defconfig ... failed Building powerpc:allmodconfig ... failed -- arch/powerpc/platforms/powernv/pci-ioda.c: In function 'pnv_pci_enable_bridge': arch/powerpc/platforms/powernv/pci-ioda.c:3145:4: error: implicit declaration of function 'pci_err' 4.14, 4,18 unknown. Very preliminary; the builds will take a while to complete. My builders are struggling with stability problems when running 4.18.6 kernels. Guenter
Re: [PATCH 3.18 00/29] 3.18.122-stable review
On 09/07/2018 02:10 PM, Greg Kroah-Hartman wrote: This is the start of the stable review cycle for the 3.18.122 release. There are 29 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Sun Sep 9 21:08:52 UTC 2018. Anything received after that time might be too late. Affects at least 3.18, 4.4, 4.9: Building powerpc:allmodconfig ... failed -- Error log: arch/powerpc/kernel/fadump.c: In function 'free_crash_memory_ranges': arch/powerpc/kernel/fadump.c:733:2: error: implicit declaration of function 'kfree' arch/powerpc/kernel/fadump.c: In function 'allocate_crash_memory_ranges': arch/powerpc/kernel/fadump.c:752:2: error: implicit declaration of function 'krealloc' Affects at least 4.9 (on top of the above): Building powerpc:defconfig ... failed Building powerpc:allmodconfig ... failed -- arch/powerpc/platforms/powernv/pci-ioda.c: In function 'pnv_pci_enable_bridge': arch/powerpc/platforms/powernv/pci-ioda.c:3145:4: error: implicit declaration of function 'pci_err' 4.14, 4,18 unknown. Very preliminary; the builds will take a while to complete. My builders are struggling with stability problems when running 4.18.6 kernels. Guenter
[PATCH] infiniband: remove redundant condition check before debugfs_remove
debugfs_remove has taken the IS_ERR_OR_NULL into account. Just
remove the unnecessary condition.
Signed-off-by: zhong jiang
---
drivers/infiniband/hw/usnic/usnic_debugfs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/usnic/usnic_debugfs.c
b/drivers/infiniband/hw/usnic/usnic_debugfs.c
index 92dc66c..a311570 100644
--- a/drivers/infiniband/hw/usnic/usnic_debugfs.c
+++ b/drivers/infiniband/hw/usnic/usnic_debugfs.c
@@ -165,6 +165,5 @@ void usnic_debugfs_flow_add(struct usnic_ib_qp_grp_flow
*qp_flow)
void usnic_debugfs_flow_remove(struct usnic_ib_qp_grp_flow *qp_flow)
{
- if (!IS_ERR_OR_NULL(qp_flow->dbgfs_dentry))
- debugfs_remove(qp_flow->dbgfs_dentry);
+ debugfs_remove(qp_flow->dbgfs_dentry);
}
--
1.7.12.4
[PATCH] infiniband: remove redundant condition check before debugfs_remove
debugfs_remove has taken the IS_ERR_OR_NULL into account. Just
remove the unnecessary condition.
Signed-off-by: zhong jiang
---
drivers/infiniband/hw/usnic/usnic_debugfs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/infiniband/hw/usnic/usnic_debugfs.c
b/drivers/infiniband/hw/usnic/usnic_debugfs.c
index 92dc66c..a311570 100644
--- a/drivers/infiniband/hw/usnic/usnic_debugfs.c
+++ b/drivers/infiniband/hw/usnic/usnic_debugfs.c
@@ -165,6 +165,5 @@ void usnic_debugfs_flow_add(struct usnic_ib_qp_grp_flow
*qp_flow)
void usnic_debugfs_flow_remove(struct usnic_ib_qp_grp_flow *qp_flow)
{
- if (!IS_ERR_OR_NULL(qp_flow->dbgfs_dentry))
- debugfs_remove(qp_flow->dbgfs_dentry);
+ debugfs_remove(qp_flow->dbgfs_dentry);
}
--
1.7.12.4
Re: [PATCH] mm: memcontrol: print proper OOM header when no eligible victim left
On Sat, Sep 08, 2018 at 10:36:06PM +0900, Tetsuo Handa wrote:
> On 2018/08/22 1:04, Johannes Weiner wrote:
> > When the memcg OOM killer runs out of killable tasks, it currently
> > prints a WARN with no further OOM context. This has caused some user
> > confusion.
> >
> > Warnings indicate a kernel problem. In a reported case, however, the
> > situation was triggered by a non-sensical memcg configuration (hard
> > limit set to 0). But without any VM context this wasn't obvious from
> > the report, and it took some back and forth on the mailing list to
> > identify what is actually a trivial issue.
> >
> > Handle this OOM condition like we handle it in the global OOM killer:
> > dump the full OOM context and tell the user we ran out of tasks.
> >
> > This way the user can identify misconfigurations easily by themselves
> > and rectify the problem - without having to go through the hassle of
> > running into an obscure but unsettling warning, finding the
> > appropriate kernel mailing list and waiting for a kernel developer to
> > remote-analyze that the memcg configuration caused this.
> >
> > If users cannot make sense of why the OOM killer was triggered or why
> > it failed, they will still report it to the mailing list, we know that
> > from experience. So in case there is an actual kernel bug causing
> > this, kernel developers will very likely hear about it.
> >
> > Signed-off-by: Johannes Weiner
> > Acked-by: Michal Hocko
> > ---
> > mm/memcontrol.c | 2 --
> > mm/oom_kill.c | 13 ++---
> > 2 files changed, 10 insertions(+), 5 deletions(-)
> >
>
> Now that above patch went to 4.19-rc3, please apply below one.
>
> From eb2bff2ed308da04785bcf541dd3f748286bfa23 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Sat, 8 Sep 2018 22:26:28 +0900
> Subject: [PATCH] mm, oom: Don't emit noises for failed SysRq-f.
>
> Due to commit d75da004c708c9fc ("oom: improve oom disable handling") and
> commit 3100dab2aa09dc6e ("mm: memcontrol: print proper OOM header when
> no eligible victim left"), all
>
> kworker/0:1 invoked oom-killer: gfp_mask=0x6000c0(GFP_KERNEL),
> nodemask=(null), order=-1, oom_score_adj=0
> (...snipped...)
> Out of memory and no killable processes...
> OOM request ignored. No task eligible
>
> lines are printed.
This doesn't explain the context, what you were trying to do here, and
what you expected to happen. Plus, you (...snipped...) the important
part to understand why it failed in the first place.
> Let's not emit "invoked oom-killer" lines when SysRq-f failed.
I disagree. If the user asked for an OOM kill, it makes perfect sense
to dump the memory context and the outcome of the operation - even if
the outcome is "I didn't find anything to kill". I'd argue that the
failure case *in particular* is where I want to know about and have
all the information that could help me understand why it failed.
So NAK on the inferred patch premise, but please include way more
rationale, reproduction scenario etc. in future patches. It's not at
all clear *why* you think it should work the way you propose here.
Re: [PATCH] mm: memcontrol: print proper OOM header when no eligible victim left
On Sat, Sep 08, 2018 at 10:36:06PM +0900, Tetsuo Handa wrote:
> On 2018/08/22 1:04, Johannes Weiner wrote:
> > When the memcg OOM killer runs out of killable tasks, it currently
> > prints a WARN with no further OOM context. This has caused some user
> > confusion.
> >
> > Warnings indicate a kernel problem. In a reported case, however, the
> > situation was triggered by a non-sensical memcg configuration (hard
> > limit set to 0). But without any VM context this wasn't obvious from
> > the report, and it took some back and forth on the mailing list to
> > identify what is actually a trivial issue.
> >
> > Handle this OOM condition like we handle it in the global OOM killer:
> > dump the full OOM context and tell the user we ran out of tasks.
> >
> > This way the user can identify misconfigurations easily by themselves
> > and rectify the problem - without having to go through the hassle of
> > running into an obscure but unsettling warning, finding the
> > appropriate kernel mailing list and waiting for a kernel developer to
> > remote-analyze that the memcg configuration caused this.
> >
> > If users cannot make sense of why the OOM killer was triggered or why
> > it failed, they will still report it to the mailing list, we know that
> > from experience. So in case there is an actual kernel bug causing
> > this, kernel developers will very likely hear about it.
> >
> > Signed-off-by: Johannes Weiner
> > Acked-by: Michal Hocko
> > ---
> > mm/memcontrol.c | 2 --
> > mm/oom_kill.c | 13 ++---
> > 2 files changed, 10 insertions(+), 5 deletions(-)
> >
>
> Now that above patch went to 4.19-rc3, please apply below one.
>
> From eb2bff2ed308da04785bcf541dd3f748286bfa23 Mon Sep 17 00:00:00 2001
> From: Tetsuo Handa
> Date: Sat, 8 Sep 2018 22:26:28 +0900
> Subject: [PATCH] mm, oom: Don't emit noises for failed SysRq-f.
>
> Due to commit d75da004c708c9fc ("oom: improve oom disable handling") and
> commit 3100dab2aa09dc6e ("mm: memcontrol: print proper OOM header when
> no eligible victim left"), all
>
> kworker/0:1 invoked oom-killer: gfp_mask=0x6000c0(GFP_KERNEL),
> nodemask=(null), order=-1, oom_score_adj=0
> (...snipped...)
> Out of memory and no killable processes...
> OOM request ignored. No task eligible
>
> lines are printed.
This doesn't explain the context, what you were trying to do here, and
what you expected to happen. Plus, you (...snipped...) the important
part to understand why it failed in the first place.
> Let's not emit "invoked oom-killer" lines when SysRq-f failed.
I disagree. If the user asked for an OOM kill, it makes perfect sense
to dump the memory context and the outcome of the operation - even if
the outcome is "I didn't find anything to kill". I'd argue that the
failure case *in particular* is where I want to know about and have
all the information that could help me understand why it failed.
So NAK on the inferred patch premise, but please include way more
rationale, reproduction scenario etc. in future patches. It's not at
all clear *why* you think it should work the way you propose here.
Charity Donation!!!
I, Mikhail Fridman have selected you specifically as one of my beneficiaries for my Charitable Donation, Check the link below for confirmation: https://www.rt.com/business/343781-mikhail-fridman-will-charity/ I await your earliest response. Best Regards, Mikhail Fridman. This message was sent using IMP, the Internet Messaging Program.
Charity Donation!!!
I, Mikhail Fridman have selected you specifically as one of my beneficiaries for my Charitable Donation, Check the link below for confirmation: https://www.rt.com/business/343781-mikhail-fridman-will-charity/ I await your earliest response. Best Regards, Mikhail Fridman. This message was sent using IMP, the Internet Messaging Program.
Re: [PATCH 2/3] iio: adc: Add Xilinx AMS driver
On Thu, 6 Sep 2018 15:19:29 + Manish Narani wrote: > Hi Jonathan, > > Thanks a lot for the review. Please see my response inline. Hi Manish, Just one thing to think about. (and I'm not that great about this myself :) Please look to crop out irrelevant text. It saves time when people are checking to see if there are discussion points ongoing. If you are replying to a review and agree with the suggestion then feel free to cut that chunk out too. If you agree entirely don't bother replying at all. I'll assume it will all be fixed in the next version. I know this may seem impolite, but it's better to save everyone time! I'm lazy and like to minimize the time it takes me to look through responses to reviews ;) Thanks, Jonathan > > > -Original Message- > > From: Jonathan Cameron [mailto:ji...@kernel.org] > > Sent: Monday, September 3, 2018 1:27 AM > > To: Manish Narani > > Cc: knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net; > > robh...@kernel.org; mark.rutl...@arm.com; Michal Simek > > ; leoyang...@nxp.com; sudeep.ho...@arm.com; > > amit.kuche...@linaro.org; broo...@kernel.org; arnaud.pouliq...@st.com; > > ge...@linux-m68k.org; eugen.hris...@microchip.com; rdun...@infradead.org; > > lu...@wunner.de; freeman@spreadtrum.com; vilhelm.g...@gmail.com; > > t...@linutronix.de; baolin.w...@linaro.org; gre...@linuxfoundation.org; > > Srinivas Goud ; Anirudha Sarangi ; > > linux-...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm- > > ker...@lists.infradead.org; linux-kernel@vger.kernel.org > > Subject: Re: [PATCH 2/3] iio: adc: Add Xilinx AMS driver > > > > On Thu, 30 Aug 2018 15:52:18 +0530 > > Manish Narani wrote: > > > > > The AMS includes an ADC as well as on-chip sensors that can be used to > > > sample external voltages and monitor on-die operating conditions, such > > > as temperature and supply voltage levels. The AMS has two SYSMON blocks. > > > PL-SYSMON block is capable of monitoring off chip voltage and > > > temperature. > > > PL-SYSMON block has DRP, JTAG and I2C interface to enable monitoring > > > from external master. Out of these interface currently only DRP is > > > supported. > > > Other block PS-SYSMON is memory mapped to PS. > > > The AMS can use internal channels to monitor voltage and temperature > > > as well as one primary and up to 16 auxiliary channels for measuring > > > external voltages. > > > The voltage and temperature monitoring channels also have event > > > capability which allows to generate an interrupt when their value > > > falls below or raises above a set threshold. > > > > > > Signed-off-by: Manish Narani > > > > Given the use of extended_name in here, there is a whole lot of undocumented > > userspace ABI. Please add to > > > > Documentation/ABI/testing/sysfs-bus-iio-xilinx-ams or similar. > > Okay sure. > > > > > I am a little concerned at introducing quite so many of these. > > Perhaps we need to revisit how we represent this sort of information... > > > > Otherwise, a few minor things inline but looking fairly good overall. > > > > Thanks, > > > > Jonathan > > > > > --- > > > drivers/iio/adc/Kconfig | 10 + > > > drivers/iio/adc/Makefile |1 + > > > drivers/iio/adc/xilinx-ams.c | 1081 > > > ++ > > > drivers/iio/adc/xilinx-ams.h | 281 +++ > > > 4 files changed, 1373 insertions(+) > > > create mode 100644 drivers/iio/adc/xilinx-ams.c create mode 100644 > > > drivers/iio/adc/xilinx-ams.h > > > > > > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index > > > 4a75492..405ea00 100644 > > > --- a/drivers/iio/adc/Kconfig > > > +++ b/drivers/iio/adc/Kconfig > > > @@ -941,4 +941,14 @@ config XILINX_XADC > > > The driver can also be build as a module. If so, the module will be > > called > > > xilinx-xadc. > > > > > > +config XILINX_AMS > > > + tristate "Xilinx AMS driver" > > > + depends on ARCH_ZYNQMP || COMPILE_TEST > > > + depends on HAS_IOMEM > > > + help > > > + Say yes here to have support for the Xilinx AMS. > > > + > > > + The driver can also be build as a module. If so, the module will be > > called > > > + xilinx-ams. > > > + > > > endmenu > > > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index > > > 03db7b5..fbfcc45 100644 > > > --- a/drivers/iio/adc/Makefile > > > +++ b/drivers/iio/adc/Makefile > > > @@ -85,4 +85,5 @@ obj-$(CONFIG_VF610_ADC) += vf610_adc.o > > > obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o xilinx-xadc-y := > > > xilinx-xadc-core.o xilinx-xadc-events.o > > > obj-$(CONFIG_XILINX_XADC) += xilinx-xadc.o > > > +obj-$(CONFIG_XILINX_AMS) += xilinx-ams.o > > > obj-$(CONFIG_SD_ADC_MODULATOR) += sd_adc_modulator.o diff --git > > > a/drivers/iio/adc/xilinx-ams.c b/drivers/iio/adc/xilinx-ams.c new file > > > mode 100644 index 000..10bcc52 > > > --- /dev/null > > > +++ b/drivers/iio/adc/xilinx-ams.c > > > @@ -0,0 +1,1081 @@ > > > +// SPDX-License-Identifier:
Re: [PATCH 2/3] iio: adc: Add Xilinx AMS driver
On Thu, 6 Sep 2018 15:19:29 + Manish Narani wrote: > Hi Jonathan, > > Thanks a lot for the review. Please see my response inline. Hi Manish, Just one thing to think about. (and I'm not that great about this myself :) Please look to crop out irrelevant text. It saves time when people are checking to see if there are discussion points ongoing. If you are replying to a review and agree with the suggestion then feel free to cut that chunk out too. If you agree entirely don't bother replying at all. I'll assume it will all be fixed in the next version. I know this may seem impolite, but it's better to save everyone time! I'm lazy and like to minimize the time it takes me to look through responses to reviews ;) Thanks, Jonathan > > > -Original Message- > > From: Jonathan Cameron [mailto:ji...@kernel.org] > > Sent: Monday, September 3, 2018 1:27 AM > > To: Manish Narani > > Cc: knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net; > > robh...@kernel.org; mark.rutl...@arm.com; Michal Simek > > ; leoyang...@nxp.com; sudeep.ho...@arm.com; > > amit.kuche...@linaro.org; broo...@kernel.org; arnaud.pouliq...@st.com; > > ge...@linux-m68k.org; eugen.hris...@microchip.com; rdun...@infradead.org; > > lu...@wunner.de; freeman@spreadtrum.com; vilhelm.g...@gmail.com; > > t...@linutronix.de; baolin.w...@linaro.org; gre...@linuxfoundation.org; > > Srinivas Goud ; Anirudha Sarangi ; > > linux-...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm- > > ker...@lists.infradead.org; linux-kernel@vger.kernel.org > > Subject: Re: [PATCH 2/3] iio: adc: Add Xilinx AMS driver > > > > On Thu, 30 Aug 2018 15:52:18 +0530 > > Manish Narani wrote: > > > > > The AMS includes an ADC as well as on-chip sensors that can be used to > > > sample external voltages and monitor on-die operating conditions, such > > > as temperature and supply voltage levels. The AMS has two SYSMON blocks. > > > PL-SYSMON block is capable of monitoring off chip voltage and > > > temperature. > > > PL-SYSMON block has DRP, JTAG and I2C interface to enable monitoring > > > from external master. Out of these interface currently only DRP is > > > supported. > > > Other block PS-SYSMON is memory mapped to PS. > > > The AMS can use internal channels to monitor voltage and temperature > > > as well as one primary and up to 16 auxiliary channels for measuring > > > external voltages. > > > The voltage and temperature monitoring channels also have event > > > capability which allows to generate an interrupt when their value > > > falls below or raises above a set threshold. > > > > > > Signed-off-by: Manish Narani > > > > Given the use of extended_name in here, there is a whole lot of undocumented > > userspace ABI. Please add to > > > > Documentation/ABI/testing/sysfs-bus-iio-xilinx-ams or similar. > > Okay sure. > > > > > I am a little concerned at introducing quite so many of these. > > Perhaps we need to revisit how we represent this sort of information... > > > > Otherwise, a few minor things inline but looking fairly good overall. > > > > Thanks, > > > > Jonathan > > > > > --- > > > drivers/iio/adc/Kconfig | 10 + > > > drivers/iio/adc/Makefile |1 + > > > drivers/iio/adc/xilinx-ams.c | 1081 > > > ++ > > > drivers/iio/adc/xilinx-ams.h | 281 +++ > > > 4 files changed, 1373 insertions(+) > > > create mode 100644 drivers/iio/adc/xilinx-ams.c create mode 100644 > > > drivers/iio/adc/xilinx-ams.h > > > > > > diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig index > > > 4a75492..405ea00 100644 > > > --- a/drivers/iio/adc/Kconfig > > > +++ b/drivers/iio/adc/Kconfig > > > @@ -941,4 +941,14 @@ config XILINX_XADC > > > The driver can also be build as a module. If so, the module will be > > called > > > xilinx-xadc. > > > > > > +config XILINX_AMS > > > + tristate "Xilinx AMS driver" > > > + depends on ARCH_ZYNQMP || COMPILE_TEST > > > + depends on HAS_IOMEM > > > + help > > > + Say yes here to have support for the Xilinx AMS. > > > + > > > + The driver can also be build as a module. If so, the module will be > > called > > > + xilinx-ams. > > > + > > > endmenu > > > diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile index > > > 03db7b5..fbfcc45 100644 > > > --- a/drivers/iio/adc/Makefile > > > +++ b/drivers/iio/adc/Makefile > > > @@ -85,4 +85,5 @@ obj-$(CONFIG_VF610_ADC) += vf610_adc.o > > > obj-$(CONFIG_VIPERBOARD_ADC) += viperboard_adc.o xilinx-xadc-y := > > > xilinx-xadc-core.o xilinx-xadc-events.o > > > obj-$(CONFIG_XILINX_XADC) += xilinx-xadc.o > > > +obj-$(CONFIG_XILINX_AMS) += xilinx-ams.o > > > obj-$(CONFIG_SD_ADC_MODULATOR) += sd_adc_modulator.o diff --git > > > a/drivers/iio/adc/xilinx-ams.c b/drivers/iio/adc/xilinx-ams.c new file > > > mode 100644 index 000..10bcc52 > > > --- /dev/null > > > +++ b/drivers/iio/adc/xilinx-ams.c > > > @@ -0,0 +1,1081 @@ > > > +// SPDX-License-Identifier:
[PATCH] [trivial] treewide: Fix typos in printk
This patch fixes some spelling typos found in printk messages.
Signed-off-by: Masanari Iida
---
drivers/dma/ep93xx_dma.c | 6 +++---
drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 2 +-
drivers/gpu/drm/drm_kms_helper_common.c| 2 +-
drivers/gpu/drm/selftests/test-drm_mm.c| 2 +-
drivers/media/v4l2-core/videobuf-core.c| 2 +-
drivers/net/ethernet/mellanox/mlxsw/spectrum_dcb.c | 2 +-
drivers/net/wireless/marvell/libertas/if_usb.c | 2 +-
drivers/net/wireless/marvell/libertas_tf/if_usb.c | 4 ++--
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 2 +-
drivers/soc/imx/gpcv2.c| 2 +-
fs/gfs2/super.c| 2 +-
11 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/dma/ep93xx_dma.c b/drivers/dma/ep93xx_dma.c
index a15592383d4e..7997e9bb7e10 100644
--- a/drivers/dma/ep93xx_dma.c
+++ b/drivers/dma/ep93xx_dma.c
@@ -993,7 +993,7 @@ ep93xx_dma_prep_dma_memcpy(struct dma_chan *chan,
dma_addr_t dest,
for (offset = 0; offset < len; offset += bytes) {
desc = ep93xx_dma_desc_get(edmac);
if (!desc) {
- dev_warn(chan2dev(edmac), "couln't get descriptor\n");
+ dev_warn(chan2dev(edmac), "couldn't get descriptor\n");
goto fail;
}
@@ -1063,7 +1063,7 @@ ep93xx_dma_prep_slave_sg(struct dma_chan *chan, struct
scatterlist *sgl,
desc = ep93xx_dma_desc_get(edmac);
if (!desc) {
- dev_warn(chan2dev(edmac), "couln't get descriptor\n");
+ dev_warn(chan2dev(edmac), "couldn't get descriptor\n");
goto fail;
}
@@ -1141,7 +1141,7 @@ ep93xx_dma_prep_dma_cyclic(struct dma_chan *chan,
dma_addr_t dma_addr,
for (offset = 0; offset < buf_len; offset += period_len) {
desc = ep93xx_dma_desc_get(edmac);
if (!desc) {
- dev_warn(chan2dev(edmac), "couln't get descriptor\n");
+ dev_warn(chan2dev(edmac), "couldn't get descriptor\n");
goto fail;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
index 9fc1c37344ce..8300c735c9c6 100644
--- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
@@ -516,7 +516,7 @@ static void xgpu_vi_mailbox_flr_work(struct work_struct
*work)
/* wait until RCV_MSG become 3 */
if (xgpu_vi_poll_msg(adev, IDH_FLR_NOTIFICATION_CMPL)) {
- pr_err("failed to recieve FLR_CMPL\n");
+ pr_err("failed to receive FLR_CMPL\n");
return;
}
diff --git a/drivers/gpu/drm/drm_kms_helper_common.c
b/drivers/gpu/drm/drm_kms_helper_common.c
index 93e2b30fe1a5..9c5ae825c507 100644
--- a/drivers/gpu/drm/drm_kms_helper_common.c
+++ b/drivers/gpu/drm/drm_kms_helper_common.c
@@ -39,7 +39,7 @@ MODULE_LICENSE("GPL and additional rights");
/* Backward compatibility for drm_kms_helper.edid_firmware */
static int edid_firmware_set(const char *val, const struct kernel_param *kp)
{
- DRM_NOTE("drm_kms_firmware.edid_firmware is deprecated, please use
drm.edid_firmware intead.\n");
+ DRM_NOTE("drm_kms_firmware.edid_firmware is deprecated, please use
drm.edid_firmware instead.\n");
return __drm_set_edid_firmware_path(val);
}
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c
b/drivers/gpu/drm/selftests/test-drm_mm.c
index fbed2c90fd51..880bf92bb524 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -2360,7 +2360,7 @@ static int __init test_drm_mm_init(void)
while (!random_seed)
random_seed = get_random_int();
- pr_info("Testing DRM range manger (struct drm_mm), with
random_seed=0x%x max_iterations=%u max_prime=%u\n",
+ pr_info("Testing DRM range manager (struct drm_mm), with
random_seed=0x%x max_iterations=%u max_prime=%u\n",
random_seed, max_iterations, max_prime);
err = run_selftests(selftests, ARRAY_SIZE(selftests), NULL);
diff --git a/drivers/media/v4l2-core/videobuf-core.c
b/drivers/media/v4l2-core/videobuf-core.c
index 7491b337002c..67c5dbbe3802 100644
--- a/drivers/media/v4l2-core/videobuf-core.c
+++ b/drivers/media/v4l2-core/videobuf-core.c
@@ -214,7 +214,7 @@ int videobuf_queue_is_busy(struct videobuf_queue *q)
return 1;
}
if (q->bufs[i]->state == VIDEOBUF_ACTIVE) {
- dprintk(1, "busy: buffer #%d avtive\n", i);
+ dprintk(1, "busy: buffer #%d active\n", i);
return 1;
}
}
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_dcb.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_dcb.c
index
[PATCH] [trivial] treewide: Fix typos in printk
This patch fixes some spelling typos found in printk messages.
Signed-off-by: Masanari Iida
---
drivers/dma/ep93xx_dma.c | 6 +++---
drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c | 2 +-
drivers/gpu/drm/drm_kms_helper_common.c| 2 +-
drivers/gpu/drm/selftests/test-drm_mm.c| 2 +-
drivers/media/v4l2-core/videobuf-core.c| 2 +-
drivers/net/ethernet/mellanox/mlxsw/spectrum_dcb.c | 2 +-
drivers/net/wireless/marvell/libertas/if_usb.c | 2 +-
drivers/net/wireless/marvell/libertas_tf/if_usb.c | 4 ++--
drivers/scsi/cxgbi/cxgb4i/cxgb4i.c | 2 +-
drivers/soc/imx/gpcv2.c| 2 +-
fs/gfs2/super.c| 2 +-
11 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/dma/ep93xx_dma.c b/drivers/dma/ep93xx_dma.c
index a15592383d4e..7997e9bb7e10 100644
--- a/drivers/dma/ep93xx_dma.c
+++ b/drivers/dma/ep93xx_dma.c
@@ -993,7 +993,7 @@ ep93xx_dma_prep_dma_memcpy(struct dma_chan *chan,
dma_addr_t dest,
for (offset = 0; offset < len; offset += bytes) {
desc = ep93xx_dma_desc_get(edmac);
if (!desc) {
- dev_warn(chan2dev(edmac), "couln't get descriptor\n");
+ dev_warn(chan2dev(edmac), "couldn't get descriptor\n");
goto fail;
}
@@ -1063,7 +1063,7 @@ ep93xx_dma_prep_slave_sg(struct dma_chan *chan, struct
scatterlist *sgl,
desc = ep93xx_dma_desc_get(edmac);
if (!desc) {
- dev_warn(chan2dev(edmac), "couln't get descriptor\n");
+ dev_warn(chan2dev(edmac), "couldn't get descriptor\n");
goto fail;
}
@@ -1141,7 +1141,7 @@ ep93xx_dma_prep_dma_cyclic(struct dma_chan *chan,
dma_addr_t dma_addr,
for (offset = 0; offset < buf_len; offset += period_len) {
desc = ep93xx_dma_desc_get(edmac);
if (!desc) {
- dev_warn(chan2dev(edmac), "couln't get descriptor\n");
+ dev_warn(chan2dev(edmac), "couldn't get descriptor\n");
goto fail;
}
diff --git a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
index 9fc1c37344ce..8300c735c9c6 100644
--- a/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
+++ b/drivers/gpu/drm/amd/amdgpu/mxgpu_vi.c
@@ -516,7 +516,7 @@ static void xgpu_vi_mailbox_flr_work(struct work_struct
*work)
/* wait until RCV_MSG become 3 */
if (xgpu_vi_poll_msg(adev, IDH_FLR_NOTIFICATION_CMPL)) {
- pr_err("failed to recieve FLR_CMPL\n");
+ pr_err("failed to receive FLR_CMPL\n");
return;
}
diff --git a/drivers/gpu/drm/drm_kms_helper_common.c
b/drivers/gpu/drm/drm_kms_helper_common.c
index 93e2b30fe1a5..9c5ae825c507 100644
--- a/drivers/gpu/drm/drm_kms_helper_common.c
+++ b/drivers/gpu/drm/drm_kms_helper_common.c
@@ -39,7 +39,7 @@ MODULE_LICENSE("GPL and additional rights");
/* Backward compatibility for drm_kms_helper.edid_firmware */
static int edid_firmware_set(const char *val, const struct kernel_param *kp)
{
- DRM_NOTE("drm_kms_firmware.edid_firmware is deprecated, please use
drm.edid_firmware intead.\n");
+ DRM_NOTE("drm_kms_firmware.edid_firmware is deprecated, please use
drm.edid_firmware instead.\n");
return __drm_set_edid_firmware_path(val);
}
diff --git a/drivers/gpu/drm/selftests/test-drm_mm.c
b/drivers/gpu/drm/selftests/test-drm_mm.c
index fbed2c90fd51..880bf92bb524 100644
--- a/drivers/gpu/drm/selftests/test-drm_mm.c
+++ b/drivers/gpu/drm/selftests/test-drm_mm.c
@@ -2360,7 +2360,7 @@ static int __init test_drm_mm_init(void)
while (!random_seed)
random_seed = get_random_int();
- pr_info("Testing DRM range manger (struct drm_mm), with
random_seed=0x%x max_iterations=%u max_prime=%u\n",
+ pr_info("Testing DRM range manager (struct drm_mm), with
random_seed=0x%x max_iterations=%u max_prime=%u\n",
random_seed, max_iterations, max_prime);
err = run_selftests(selftests, ARRAY_SIZE(selftests), NULL);
diff --git a/drivers/media/v4l2-core/videobuf-core.c
b/drivers/media/v4l2-core/videobuf-core.c
index 7491b337002c..67c5dbbe3802 100644
--- a/drivers/media/v4l2-core/videobuf-core.c
+++ b/drivers/media/v4l2-core/videobuf-core.c
@@ -214,7 +214,7 @@ int videobuf_queue_is_busy(struct videobuf_queue *q)
return 1;
}
if (q->bufs[i]->state == VIDEOBUF_ACTIVE) {
- dprintk(1, "busy: buffer #%d avtive\n", i);
+ dprintk(1, "busy: buffer #%d active\n", i);
return 1;
}
}
diff --git a/drivers/net/ethernet/mellanox/mlxsw/spectrum_dcb.c
b/drivers/net/ethernet/mellanox/mlxsw/spectrum_dcb.c
index
Re: [PATCH 1/3] dt-bindings: iio: adc: Add Xilinx AMS binding documentation
On Thu, 6 Sep 2018 13:27:34 + Manish Narani wrote: > Hi Jonathan, > > Thanks for the review! > > > -Original Message- > > From: Jonathan Cameron [mailto:ji...@kernel.org] > > Sent: Sunday, September 2, 2018 11:45 PM > > To: Manish Narani > > Cc: knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net; > > robh...@kernel.org; mark.rutl...@arm.com; Michal Simek > > ; leoyang...@nxp.com; sudeep.ho...@arm.com; > > amit.kuche...@linaro.org; broo...@kernel.org; arnaud.pouliq...@st.com; > > ge...@linux-m68k.org; eugen.hris...@microchip.com; rdun...@infradead.org; > > lu...@wunner.de; freeman@spreadtrum.com; vilhelm.g...@gmail.com; > > t...@linutronix.de; baolin.w...@linaro.org; gre...@linuxfoundation.org; > > Srinivas Goud ; Anirudha Sarangi ; > > linux-...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm- > > ker...@lists.infradead.org; linux-kernel@vger.kernel.org > > Subject: Re: [PATCH 1/3] dt-bindings: iio: adc: Add Xilinx AMS binding > > documentation > > > > On Thu, 30 Aug 2018 15:52:17 +0530 > > Manish Narani wrote: > > > > > Xilinx AMS have several ADC channels that can be used for measurement > > > of different voltages and temperatures. Document the same in the bindings. > > > > > > Signed-off-by: Manish Narani > > > --- > > > .../devicetree/bindings/iio/adc/xilinx-ams.txt | 159 > > + > > > 1 file changed, 159 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/iio/adc/xilinx-ams.txt > > > > > > diff --git a/Documentation/devicetree/bindings/iio/adc/xilinx-ams.txt > > > b/Documentation/devicetree/bindings/iio/adc/xilinx-ams.txt > > > new file mode 100644 > > > index 000..8cc96f0 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/iio/adc/xilinx-ams.txt > > > @@ -0,0 +1,159 @@ > > > +Xilinx AMS controller > > > + > > > +The AMS includes an ADC as well as on-chip sensors that can be used > > > +to sample external voltages and monitor on-die operating conditions, > > > +such as temperature and supply voltage levels. The AMS has two SYSMON > > blocks. > > > +PL-SYSMON block is capable of monitoring off chip voltage and > > temperature. > > > +PL-SYSMON block has DRP, JTAG and I2C interface to enable monitoring > > > +from external master. Out of this interface currently only DRP is > > > supported. > > > +Other block PS-SYSMON is memory mapped to PS. Both of block has > > > +built-in alarm generation logic that is used to interrupt the > > > +processor based on condition set. > > > > I guess anyone reading this because they have the hardware would know what > > PS and PL are, but it would still be nice to define those acronyms! > > Okay, I will rectify this in v2. > > > > > Google suggest, Programmable Logic (FPGA bit I guess) and Process Space > > (Arm core bit?) As I read this, from a driver point of view it doesn't > > really > > matter - these are just blocks of channels that are there? > > Yes, these are just blocks of channels, which are enabled/disabled > via devicetree child nodes "xlnx,zynqmp-ams-ps" and > "xlnx,zynqmp-ams-pl". Great, put please expand in here on the naming. This may not matter for people using this particular driver, but having clear human readable descriptions is useful when we are looking for similarities between this an future drivers etc. > > > > > This binding is complex enough I definitely want some DT binding > > review. > > Sure! > > > > > > > > > > + > > > +All designs should have AMS registers, but PS and PL are > > > optional. +The AMS controller can work with only PS, only PL and > > > both PS and PL +configurations. Please specify registers > > > according to your design. +Devicetree should always have AMS > > > module property. Providing PS & PL > > module is optional. > > > + > > > +Required properties: > > > + - compatible: Should be "xlnx,zynqmp-ams" > > > + - reg: Should specify AMS register space > > > + - interrupts: Interrupt number for the AMS control > > > interface > > > + - interrupt-names: Interrupt name, must be "ams-irq" > > > + - clocks: Should contain a clock specifier for the device > > > + - ranges: keep the property empty to map child address > > > space > > > + (for PS and/or PL) nodes 1:1 onto the parent > > > address > > > + space > > > + > > > +AMS device tree subnode: > > > + - compatible: Should be "xlnx,zynqmp-ams-ps" or > > > "xlnx,zynqmp-ams-pl" > > > + - reg: Register space for PS or PL > > > + > > > +Optional properties: > > > + > > > +Following optional property only valid for PL. > > > + - xlnx,ext-channels: List of external channels that are > > > connected to the > > > + AMS PL module. > > > + > > > + The child nodes of this node represent the external > > > channels which > > are > > > + connected to the AMS Module. If the property is not > > > present > > > + no external channels will be assumed to be connected. > > > + > > > + Each
Re: [PATCH 1/3] dt-bindings: iio: adc: Add Xilinx AMS binding documentation
On Thu, 6 Sep 2018 13:27:34 + Manish Narani wrote: > Hi Jonathan, > > Thanks for the review! > > > -Original Message- > > From: Jonathan Cameron [mailto:ji...@kernel.org] > > Sent: Sunday, September 2, 2018 11:45 PM > > To: Manish Narani > > Cc: knaac...@gmx.de; l...@metafoo.de; pme...@pmeerw.net; > > robh...@kernel.org; mark.rutl...@arm.com; Michal Simek > > ; leoyang...@nxp.com; sudeep.ho...@arm.com; > > amit.kuche...@linaro.org; broo...@kernel.org; arnaud.pouliq...@st.com; > > ge...@linux-m68k.org; eugen.hris...@microchip.com; rdun...@infradead.org; > > lu...@wunner.de; freeman@spreadtrum.com; vilhelm.g...@gmail.com; > > t...@linutronix.de; baolin.w...@linaro.org; gre...@linuxfoundation.org; > > Srinivas Goud ; Anirudha Sarangi ; > > linux-...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm- > > ker...@lists.infradead.org; linux-kernel@vger.kernel.org > > Subject: Re: [PATCH 1/3] dt-bindings: iio: adc: Add Xilinx AMS binding > > documentation > > > > On Thu, 30 Aug 2018 15:52:17 +0530 > > Manish Narani wrote: > > > > > Xilinx AMS have several ADC channels that can be used for measurement > > > of different voltages and temperatures. Document the same in the bindings. > > > > > > Signed-off-by: Manish Narani > > > --- > > > .../devicetree/bindings/iio/adc/xilinx-ams.txt | 159 > > + > > > 1 file changed, 159 insertions(+) > > > create mode 100644 > > > Documentation/devicetree/bindings/iio/adc/xilinx-ams.txt > > > > > > diff --git a/Documentation/devicetree/bindings/iio/adc/xilinx-ams.txt > > > b/Documentation/devicetree/bindings/iio/adc/xilinx-ams.txt > > > new file mode 100644 > > > index 000..8cc96f0 > > > --- /dev/null > > > +++ b/Documentation/devicetree/bindings/iio/adc/xilinx-ams.txt > > > @@ -0,0 +1,159 @@ > > > +Xilinx AMS controller > > > + > > > +The AMS includes an ADC as well as on-chip sensors that can be used > > > +to sample external voltages and monitor on-die operating conditions, > > > +such as temperature and supply voltage levels. The AMS has two SYSMON > > blocks. > > > +PL-SYSMON block is capable of monitoring off chip voltage and > > temperature. > > > +PL-SYSMON block has DRP, JTAG and I2C interface to enable monitoring > > > +from external master. Out of this interface currently only DRP is > > > supported. > > > +Other block PS-SYSMON is memory mapped to PS. Both of block has > > > +built-in alarm generation logic that is used to interrupt the > > > +processor based on condition set. > > > > I guess anyone reading this because they have the hardware would know what > > PS and PL are, but it would still be nice to define those acronyms! > > Okay, I will rectify this in v2. > > > > > Google suggest, Programmable Logic (FPGA bit I guess) and Process Space > > (Arm core bit?) As I read this, from a driver point of view it doesn't > > really > > matter - these are just blocks of channels that are there? > > Yes, these are just blocks of channels, which are enabled/disabled > via devicetree child nodes "xlnx,zynqmp-ams-ps" and > "xlnx,zynqmp-ams-pl". Great, put please expand in here on the naming. This may not matter for people using this particular driver, but having clear human readable descriptions is useful when we are looking for similarities between this an future drivers etc. > > > > > This binding is complex enough I definitely want some DT binding > > review. > > Sure! > > > > > > > > > > + > > > +All designs should have AMS registers, but PS and PL are > > > optional. +The AMS controller can work with only PS, only PL and > > > both PS and PL +configurations. Please specify registers > > > according to your design. +Devicetree should always have AMS > > > module property. Providing PS & PL > > module is optional. > > > + > > > +Required properties: > > > + - compatible: Should be "xlnx,zynqmp-ams" > > > + - reg: Should specify AMS register space > > > + - interrupts: Interrupt number for the AMS control > > > interface > > > + - interrupt-names: Interrupt name, must be "ams-irq" > > > + - clocks: Should contain a clock specifier for the device > > > + - ranges: keep the property empty to map child address > > > space > > > + (for PS and/or PL) nodes 1:1 onto the parent > > > address > > > + space > > > + > > > +AMS device tree subnode: > > > + - compatible: Should be "xlnx,zynqmp-ams-ps" or > > > "xlnx,zynqmp-ams-pl" > > > + - reg: Register space for PS or PL > > > + > > > +Optional properties: > > > + > > > +Following optional property only valid for PL. > > > + - xlnx,ext-channels: List of external channels that are > > > connected to the > > > + AMS PL module. > > > + > > > + The child nodes of this node represent the external > > > channels which > > are > > > + connected to the AMS Module. If the property is not > > > present > > > + no external channels will be assumed to be connected. > > > + > > > + Each
[PATCH] bcache: remove unecessary condition check before debugfs_remove_recursive
debugfs_remove_recursive has taken IS_ERR_OR_NULL into account. So just
remove the condition check before debugfs_remove_recursive.
Signed-off-by: zhong jiang
---
drivers/md/bcache/debug.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/md/bcache/debug.c b/drivers/md/bcache/debug.c
index 06da66b..8c53d87 100644
--- a/drivers/md/bcache/debug.c
+++ b/drivers/md/bcache/debug.c
@@ -249,8 +249,7 @@ void bch_debug_init_cache_set(struct cache_set *c)
void bch_debug_exit(void)
{
- if (!IS_ERR_OR_NULL(bcache_debug))
- debugfs_remove_recursive(bcache_debug);
+ debugfs_remove_recursive(bcache_debug);
}
void __init bch_debug_init(struct kobject *kobj)
--
1.7.12.4
[PATCH] bcache: remove unecessary condition check before debugfs_remove_recursive
debugfs_remove_recursive has taken IS_ERR_OR_NULL into account. So just
remove the condition check before debugfs_remove_recursive.
Signed-off-by: zhong jiang
---
drivers/md/bcache/debug.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/md/bcache/debug.c b/drivers/md/bcache/debug.c
index 06da66b..8c53d87 100644
--- a/drivers/md/bcache/debug.c
+++ b/drivers/md/bcache/debug.c
@@ -249,8 +249,7 @@ void bch_debug_init_cache_set(struct cache_set *c)
void bch_debug_exit(void)
{
- if (!IS_ERR_OR_NULL(bcache_debug))
- debugfs_remove_recursive(bcache_debug);
+ debugfs_remove_recursive(bcache_debug);
}
void __init bch_debug_init(struct kobject *kobj)
--
1.7.12.4
Re: [PATCH 16/29] staging: bcm2835-audio: Drop superfluous mutex lock during prepare
Hi, > Takashi Iwai hat am 4. September 2018 um 17:58 geschrieben: > > > The chip->audio_mutex is used basically for protecting the opened > stream assignment, and the prepare callback is irrelevant with it. > > Signed-off-by: Takashi Iwai > --- > drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c | 8 ++-- > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c > b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c > index 1f9c940f1cc3..9659c25b9f9d 100644 > --- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c > +++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c > @@ -218,8 +218,6 @@ static int snd_bcm2835_pcm_prepare(struct > snd_pcm_substream *substream) > int channels; > int err; > > - mutex_lock(>audio_mutex); > - > /* notify the vchiq that it should enter spdif passthrough mode by >* setting channels=0 (see >* https://github.com/raspberrypi/linux/issues/528) > @@ -233,7 +231,7 @@ static int snd_bcm2835_pcm_prepare(struct > snd_pcm_substream *substream) > runtime->rate, > snd_pcm_format_width(runtime->format)); > if (err < 0) > - goto out; > + return err; > > memset(_stream->pcm_indirect, 0, > sizeof(alsa_stream->pcm_indirect)); > > @@ -246,9 +244,7 @@ static int snd_bcm2835_pcm_prepare(struct > snd_pcm_substream *substream) > alsa_stream->pos = 0; > alsa_stream->draining = false; > > - out: > - mutex_unlock(>audio_mutex); > - return err; > + return 0; looks like your are removing code which has been added in patch #14 ? > } > > static void snd_bcm2835_pcm_transfer(struct snd_pcm_substream *substream, > -- > 2.18.0 >
Re: [PATCH 16/29] staging: bcm2835-audio: Drop superfluous mutex lock during prepare
Hi, > Takashi Iwai hat am 4. September 2018 um 17:58 geschrieben: > > > The chip->audio_mutex is used basically for protecting the opened > stream assignment, and the prepare callback is irrelevant with it. > > Signed-off-by: Takashi Iwai > --- > drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c | 8 ++-- > 1 file changed, 2 insertions(+), 6 deletions(-) > > diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c > b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c > index 1f9c940f1cc3..9659c25b9f9d 100644 > --- a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c > +++ b/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c > @@ -218,8 +218,6 @@ static int snd_bcm2835_pcm_prepare(struct > snd_pcm_substream *substream) > int channels; > int err; > > - mutex_lock(>audio_mutex); > - > /* notify the vchiq that it should enter spdif passthrough mode by >* setting channels=0 (see >* https://github.com/raspberrypi/linux/issues/528) > @@ -233,7 +231,7 @@ static int snd_bcm2835_pcm_prepare(struct > snd_pcm_substream *substream) > runtime->rate, > snd_pcm_format_width(runtime->format)); > if (err < 0) > - goto out; > + return err; > > memset(_stream->pcm_indirect, 0, > sizeof(alsa_stream->pcm_indirect)); > > @@ -246,9 +244,7 @@ static int snd_bcm2835_pcm_prepare(struct > snd_pcm_substream *substream) > alsa_stream->pos = 0; > alsa_stream->draining = false; > > - out: > - mutex_unlock(>audio_mutex); > - return err; > + return 0; looks like your are removing code which has been added in patch #14 ? > } > > static void snd_bcm2835_pcm_transfer(struct snd_pcm_substream *substream, > -- > 2.18.0 >
Re: [PATCH] mm: memcontrol: print proper OOM header when no eligible victim left
On 2018/08/22 1:04, Johannes Weiner wrote:
> When the memcg OOM killer runs out of killable tasks, it currently
> prints a WARN with no further OOM context. This has caused some user
> confusion.
>
> Warnings indicate a kernel problem. In a reported case, however, the
> situation was triggered by a non-sensical memcg configuration (hard
> limit set to 0). But without any VM context this wasn't obvious from
> the report, and it took some back and forth on the mailing list to
> identify what is actually a trivial issue.
>
> Handle this OOM condition like we handle it in the global OOM killer:
> dump the full OOM context and tell the user we ran out of tasks.
>
> This way the user can identify misconfigurations easily by themselves
> and rectify the problem - without having to go through the hassle of
> running into an obscure but unsettling warning, finding the
> appropriate kernel mailing list and waiting for a kernel developer to
> remote-analyze that the memcg configuration caused this.
>
> If users cannot make sense of why the OOM killer was triggered or why
> it failed, they will still report it to the mailing list, we know that
> from experience. So in case there is an actual kernel bug causing
> this, kernel developers will very likely hear about it.
>
> Signed-off-by: Johannes Weiner
> Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 2 --
> mm/oom_kill.c | 13 ++---
> 2 files changed, 10 insertions(+), 5 deletions(-)
>
Now that above patch went to 4.19-rc3, please apply below one.
>From eb2bff2ed308da04785bcf541dd3f748286bfa23 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Sat, 8 Sep 2018 22:26:28 +0900
Subject: [PATCH] mm, oom: Don't emit noises for failed SysRq-f.
Due to commit d75da004c708c9fc ("oom: improve oom disable handling") and
commit 3100dab2aa09dc6e ("mm: memcontrol: print proper OOM header when
no eligible victim left"), all
kworker/0:1 invoked oom-killer: gfp_mask=0x6000c0(GFP_KERNEL),
nodemask=(null), order=-1, oom_score_adj=0
(...snipped...)
Out of memory and no killable processes...
OOM request ignored. No task eligible
lines are printed.
Let's not emit "invoked oom-killer" lines when SysRq-f failed.
Signed-off-by: Tetsuo Handa
---
mm/oom_kill.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index f10aa53..92122ef 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -1106,8 +1106,10 @@ bool out_of_memory(struct oom_control *oc)
select_bad_process(oc);
/* Found nothing?!?! */
if (!oc->chosen) {
- dump_header(oc, NULL);
- pr_warn("Out of memory and no killable processes...\n");
+ if (!is_sysrq_oom(oc)) {
+ dump_header(oc, NULL);
+ pr_warn("Out of memory and no killable processes...\n");
+ }
/*
* If we got here due to an actual allocation at the
* system level, we cannot survive this and will enter
--
1.8.3.1
Re: [PATCH] mm: memcontrol: print proper OOM header when no eligible victim left
On 2018/08/22 1:04, Johannes Weiner wrote:
> When the memcg OOM killer runs out of killable tasks, it currently
> prints a WARN with no further OOM context. This has caused some user
> confusion.
>
> Warnings indicate a kernel problem. In a reported case, however, the
> situation was triggered by a non-sensical memcg configuration (hard
> limit set to 0). But without any VM context this wasn't obvious from
> the report, and it took some back and forth on the mailing list to
> identify what is actually a trivial issue.
>
> Handle this OOM condition like we handle it in the global OOM killer:
> dump the full OOM context and tell the user we ran out of tasks.
>
> This way the user can identify misconfigurations easily by themselves
> and rectify the problem - without having to go through the hassle of
> running into an obscure but unsettling warning, finding the
> appropriate kernel mailing list and waiting for a kernel developer to
> remote-analyze that the memcg configuration caused this.
>
> If users cannot make sense of why the OOM killer was triggered or why
> it failed, they will still report it to the mailing list, we know that
> from experience. So in case there is an actual kernel bug causing
> this, kernel developers will very likely hear about it.
>
> Signed-off-by: Johannes Weiner
> Acked-by: Michal Hocko
> ---
> mm/memcontrol.c | 2 --
> mm/oom_kill.c | 13 ++---
> 2 files changed, 10 insertions(+), 5 deletions(-)
>
Now that above patch went to 4.19-rc3, please apply below one.
>From eb2bff2ed308da04785bcf541dd3f748286bfa23 Mon Sep 17 00:00:00 2001
From: Tetsuo Handa
Date: Sat, 8 Sep 2018 22:26:28 +0900
Subject: [PATCH] mm, oom: Don't emit noises for failed SysRq-f.
Due to commit d75da004c708c9fc ("oom: improve oom disable handling") and
commit 3100dab2aa09dc6e ("mm: memcontrol: print proper OOM header when
no eligible victim left"), all
kworker/0:1 invoked oom-killer: gfp_mask=0x6000c0(GFP_KERNEL),
nodemask=(null), order=-1, oom_score_adj=0
(...snipped...)
Out of memory and no killable processes...
OOM request ignored. No task eligible
lines are printed.
Let's not emit "invoked oom-killer" lines when SysRq-f failed.
Signed-off-by: Tetsuo Handa
---
mm/oom_kill.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index f10aa53..92122ef 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -1106,8 +1106,10 @@ bool out_of_memory(struct oom_control *oc)
select_bad_process(oc);
/* Found nothing?!?! */
if (!oc->chosen) {
- dump_header(oc, NULL);
- pr_warn("Out of memory and no killable processes...\n");
+ if (!is_sysrq_oom(oc)) {
+ dump_header(oc, NULL);
+ pr_warn("Out of memory and no killable processes...\n");
+ }
/*
* If we got here due to an actual allocation at the
* system level, we cannot survive this and will enter
--
1.8.3.1
Re: [PATCH 1/2] x86/mm/KASLR: Fix the wrong calculation of kalsr region initial size
On 09/08/18 at 02:10pm, Thomas Gleixner wrote:
> On Wed, 29 Aug 2018, Baoquan He wrote:
>
> > In memory KASLR, __PHYSICAL_MASK_SHIFT is taken to calculate the
> > initial size of the direct mapping region. This is right in the
> > old code where __PHYSICAL_MASK_SHIFT was equal to MAX_PHYSMEM_BITS,
> > 46bit, and only 4-level mode was supported.
> >
> > Later, in commit:
> > b83ce5ee91471d ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52"),
> > __PHYSICAL_MASK_SHIFT was changed to be 52 always, no matter it's
> > 5-level or 4-level. This is wrong for 4-level paging. Then when
> > adapt phyiscal memory region size based on available memory, it
> > will overflow if the amount of system RAM and the padding is bigger
> > than 64TB.
> >
> > In fact, here MAX_PHYSMEM_BITS should be used instead. Fix it by
> > by replacing __PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS.
> >
> > Signed-off-by: Baoquan He
>
> This lacks a fixes tag .
Sure, I will add fix tag in this patch, and arrange a new patchset
according to discussion with Kirill after test.
Thanks
Baoquan
Re: [PATCH 1/2] x86/mm/KASLR: Fix the wrong calculation of kalsr region initial size
On 09/08/18 at 02:10pm, Thomas Gleixner wrote:
> On Wed, 29 Aug 2018, Baoquan He wrote:
>
> > In memory KASLR, __PHYSICAL_MASK_SHIFT is taken to calculate the
> > initial size of the direct mapping region. This is right in the
> > old code where __PHYSICAL_MASK_SHIFT was equal to MAX_PHYSMEM_BITS,
> > 46bit, and only 4-level mode was supported.
> >
> > Later, in commit:
> > b83ce5ee91471d ("x86/mm/64: Make __PHYSICAL_MASK_SHIFT always 52"),
> > __PHYSICAL_MASK_SHIFT was changed to be 52 always, no matter it's
> > 5-level or 4-level. This is wrong for 4-level paging. Then when
> > adapt phyiscal memory region size based on available memory, it
> > will overflow if the amount of system RAM and the padding is bigger
> > than 64TB.
> >
> > In fact, here MAX_PHYSMEM_BITS should be used instead. Fix it by
> > by replacing __PHYSICAL_MASK_SHIFT with MAX_PHYSMEM_BITS.
> >
> > Signed-off-by: Baoquan He
>
> This lacks a fixes tag .
Sure, I will add fix tag in this patch, and arrange a new patchset
according to discussion with Kirill after test.
Thanks
Baoquan
Re: [PATCH 03/29] staging: bcm2835-audio: Clean up include files in bcm2835-ctl.c
Hi, > Takashi Iwai hat am 4. September 2018 um 17:58 geschrieben: > > > Only a few of them are really needed. > > Signed-off-by: Takashi Iwai > --- > .../vc04_services/bcm2835-audio/bcm2835-ctl.c | 15 --- I think this patch and patch #23 could be merge in case a new series is required. Stefan
Re: [PATCH 03/29] staging: bcm2835-audio: Clean up include files in bcm2835-ctl.c
Hi, > Takashi Iwai hat am 4. September 2018 um 17:58 geschrieben: > > > Only a few of them are really needed. > > Signed-off-by: Takashi Iwai > --- > .../vc04_services/bcm2835-audio/bcm2835-ctl.c | 15 --- I think this patch and patch #23 could be merge in case a new series is required. Stefan
[PATCH v3 3/3] mtd: mtdconcat: add dt driver for concat devices
Some mtd drivers like physmap variants have support for concatenating
multiple mtd devices, but there is no generic way to define such a
concat device from within the device tree.
This is useful for some SoC boards that use multiple flash chips as
memory banks of a single mtd device, with partitions spanning chip
borders.
This commit adds a driver for creating virtual mtd-concat devices. They
must have a compatible = "mtd-concat" line, and define a list of devices
to concat in the 'devices' property, for example:
flash {
compatible = "mtd-concat";
devices = < >;
partitions {
...
};
};
The driver is added to the very end of the mtd Makefile to increase the
likelyhood of all child devices already being loaded at the time of
probing, preventing unnecessary deferred probes.
Signed-off-by: Bernhard Frauendienst
---
drivers/mtd/Kconfig | 2 +
drivers/mtd/Makefile| 3 +
drivers/mtd/composite/Kconfig | 12 +++
drivers/mtd/composite/Makefile | 7 ++
drivers/mtd/composite/virt_concat.c | 128
5 files changed, 152 insertions(+)
create mode 100644 drivers/mtd/composite/Kconfig
create mode 100644 drivers/mtd/composite/Makefile
create mode 100644 drivers/mtd/composite/virt_concat.c
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index c77f537323ec..6345d886d458 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -339,4 +339,6 @@ source "drivers/mtd/spi-nor/Kconfig"
source "drivers/mtd/ubi/Kconfig"
+source "drivers/mtd/composite/Kconfig"
+
endif # MTD
diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 93473d215a38..57af7190b063 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -36,3 +36,6 @@ obj-y += chips/ lpddr/ maps/ devices/ nand/ tests/
obj-$(CONFIG_MTD_SPI_NOR) += spi-nor/
obj-$(CONFIG_MTD_UBI) += ubi/
+
+# Composite drivers must be loaded last
+obj-y += composite/
diff --git a/drivers/mtd/composite/Kconfig b/drivers/mtd/composite/Kconfig
new file mode 100644
index ..0490fc0284bb
--- /dev/null
+++ b/drivers/mtd/composite/Kconfig
@@ -0,0 +1,12 @@
+menu "Composite MTD device drivers"
+ depends on MTD!=n
+
+config MTD_VIRT_CONCAT
+ tristate "Virtual concat MTD device"
+ help
+ This driver allows creation of a virtual MTD concat device, which
+ concatenates multiple underlying MTD devices to a single device.
+ This is required by some SoC boards where multiple memory banks are
+ used as one device with partitions spanning across device boundaries.
+
+endmenu
diff --git a/drivers/mtd/composite/Makefile b/drivers/mtd/composite/Makefile
new file mode 100644
index ..8421a0a30606
--- /dev/null
+++ b/drivers/mtd/composite/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# linux/drivers/mtd/composite/Makefile
+#
+
+obj-$(CONFIG_MTD_VIRT_CONCAT) += virt_concat.o
diff --git a/drivers/mtd/composite/virt_concat.c
b/drivers/mtd/composite/virt_concat.c
new file mode 100644
index ..76918d4ef07f
--- /dev/null
+++ b/drivers/mtd/composite/virt_concat.c
@@ -0,0 +1,128 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Virtual concat MTD device driver
+ *
+ * Copyright (C) 2018 Bernhard Frauendienst
+ * Author: Bernhard Frauendienst, ker...@nospam.obeliks.de
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * struct of_virt_concat - platform device driver data.
+ * @cmtd the final mtd_concat device
+ * @num_devices the number of devices in @devices
+ * @devices points to an array of devices already loaded
+ */
+struct of_virt_concat {
+ struct mtd_info *cmtd;
+ int num_devices;
+ struct mtd_info **devices;
+};
+
+static int virt_concat_remove(struct platform_device *pdev)
+{
+ struct of_virt_concat *info;
+ int i;
+
+ info = platform_get_drvdata(pdev);
+ if (!info)
+ return 0;
+
+ // unset data for when this is called after a probe error
+ platform_set_drvdata(pdev, NULL);
+
+ if (info->cmtd) {
+ mtd_device_unregister(info->cmtd);
+ mtd_concat_destroy(info->cmtd);
+ }
+
+ if (info->devices) {
+ for (i = 0; i < info->num_devices; i++)
+ put_mtd_device(info->devices[i]);
+ }
+
+ return 0;
+}
+
+static int virt_concat_probe(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct of_phandle_iterator it;
+ struct of_virt_concat *info;
+ struct mtd_info *mtd;
+ int err = 0, count;
+
+ count = of_count_phandle_with_args(node, "devices", NULL);
+ if (count <= 0)
+ return -EINVAL;
+
+ info = devm_kzalloc(>dev, sizeof(*info), GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+ info->devices = devm_kcalloc(>dev, count,
+
[PATCH v3 3/3] mtd: mtdconcat: add dt driver for concat devices
Some mtd drivers like physmap variants have support for concatenating
multiple mtd devices, but there is no generic way to define such a
concat device from within the device tree.
This is useful for some SoC boards that use multiple flash chips as
memory banks of a single mtd device, with partitions spanning chip
borders.
This commit adds a driver for creating virtual mtd-concat devices. They
must have a compatible = "mtd-concat" line, and define a list of devices
to concat in the 'devices' property, for example:
flash {
compatible = "mtd-concat";
devices = < >;
partitions {
...
};
};
The driver is added to the very end of the mtd Makefile to increase the
likelyhood of all child devices already being loaded at the time of
probing, preventing unnecessary deferred probes.
Signed-off-by: Bernhard Frauendienst
---
drivers/mtd/Kconfig | 2 +
drivers/mtd/Makefile| 3 +
drivers/mtd/composite/Kconfig | 12 +++
drivers/mtd/composite/Makefile | 7 ++
drivers/mtd/composite/virt_concat.c | 128
5 files changed, 152 insertions(+)
create mode 100644 drivers/mtd/composite/Kconfig
create mode 100644 drivers/mtd/composite/Makefile
create mode 100644 drivers/mtd/composite/virt_concat.c
diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig
index c77f537323ec..6345d886d458 100644
--- a/drivers/mtd/Kconfig
+++ b/drivers/mtd/Kconfig
@@ -339,4 +339,6 @@ source "drivers/mtd/spi-nor/Kconfig"
source "drivers/mtd/ubi/Kconfig"
+source "drivers/mtd/composite/Kconfig"
+
endif # MTD
diff --git a/drivers/mtd/Makefile b/drivers/mtd/Makefile
index 93473d215a38..57af7190b063 100644
--- a/drivers/mtd/Makefile
+++ b/drivers/mtd/Makefile
@@ -36,3 +36,6 @@ obj-y += chips/ lpddr/ maps/ devices/ nand/ tests/
obj-$(CONFIG_MTD_SPI_NOR) += spi-nor/
obj-$(CONFIG_MTD_UBI) += ubi/
+
+# Composite drivers must be loaded last
+obj-y += composite/
diff --git a/drivers/mtd/composite/Kconfig b/drivers/mtd/composite/Kconfig
new file mode 100644
index ..0490fc0284bb
--- /dev/null
+++ b/drivers/mtd/composite/Kconfig
@@ -0,0 +1,12 @@
+menu "Composite MTD device drivers"
+ depends on MTD!=n
+
+config MTD_VIRT_CONCAT
+ tristate "Virtual concat MTD device"
+ help
+ This driver allows creation of a virtual MTD concat device, which
+ concatenates multiple underlying MTD devices to a single device.
+ This is required by some SoC boards where multiple memory banks are
+ used as one device with partitions spanning across device boundaries.
+
+endmenu
diff --git a/drivers/mtd/composite/Makefile b/drivers/mtd/composite/Makefile
new file mode 100644
index ..8421a0a30606
--- /dev/null
+++ b/drivers/mtd/composite/Makefile
@@ -0,0 +1,6 @@
+# SPDX-License-Identifier: GPL-2.0
+#
+# linux/drivers/mtd/composite/Makefile
+#
+
+obj-$(CONFIG_MTD_VIRT_CONCAT) += virt_concat.o
diff --git a/drivers/mtd/composite/virt_concat.c
b/drivers/mtd/composite/virt_concat.c
new file mode 100644
index ..76918d4ef07f
--- /dev/null
+++ b/drivers/mtd/composite/virt_concat.c
@@ -0,0 +1,128 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Virtual concat MTD device driver
+ *
+ * Copyright (C) 2018 Bernhard Frauendienst
+ * Author: Bernhard Frauendienst, ker...@nospam.obeliks.de
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/*
+ * struct of_virt_concat - platform device driver data.
+ * @cmtd the final mtd_concat device
+ * @num_devices the number of devices in @devices
+ * @devices points to an array of devices already loaded
+ */
+struct of_virt_concat {
+ struct mtd_info *cmtd;
+ int num_devices;
+ struct mtd_info **devices;
+};
+
+static int virt_concat_remove(struct platform_device *pdev)
+{
+ struct of_virt_concat *info;
+ int i;
+
+ info = platform_get_drvdata(pdev);
+ if (!info)
+ return 0;
+
+ // unset data for when this is called after a probe error
+ platform_set_drvdata(pdev, NULL);
+
+ if (info->cmtd) {
+ mtd_device_unregister(info->cmtd);
+ mtd_concat_destroy(info->cmtd);
+ }
+
+ if (info->devices) {
+ for (i = 0; i < info->num_devices; i++)
+ put_mtd_device(info->devices[i]);
+ }
+
+ return 0;
+}
+
+static int virt_concat_probe(struct platform_device *pdev)
+{
+ struct device_node *node = pdev->dev.of_node;
+ struct of_phandle_iterator it;
+ struct of_virt_concat *info;
+ struct mtd_info *mtd;
+ int err = 0, count;
+
+ count = of_count_phandle_with_args(node, "devices", NULL);
+ if (count <= 0)
+ return -EINVAL;
+
+ info = devm_kzalloc(>dev, sizeof(*info), GFP_KERNEL);
+ if (!info)
+ return -ENOMEM;
+ info->devices = devm_kcalloc(>dev, count,
+
