[PATCH] net: fix psock_fanout selftest bind error message
Signed-off-by: Daniel Baluta
---
.../testing/selftests/net-afpacket/psock_fanout.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/testing/selftests/net-afpacket/psock_fanout.c
b/tools/testing/selftests/net-afpacket/psock_fanout.c
index f765f09..226e5e3 100644
--- a/tools/testing/selftests/net-afpacket/psock_fanout.c
+++ b/tools/testing/selftests/net-afpacket/psock_fanout.c
@@ -97,7 +97,7 @@ static void pair_udp_open(int fds[], uint16_t port)
exit(1);
}
if (connect(fds[0], (void *) &daddr, sizeof(daddr))) {
- perror("bind");
+ perror("connect");
exit(1);
}
}
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: fix psock_fanout selftest bind error message
On Wed, Mar 20, 2013 at 7:43 PM, David Miller wrote: > > Please, in the future, post networking patches to net...@vger.kernel.org > rather than lkml. Sure, I was convinced that I did that. get_maintainer.pl is playing tricks on me :) $ ./scripts/get_maintainer.pl 0001-net-fix-psock_fanout-selftest-bind-error-message.patch "David S. Miller" (commit_signer:4/4=100%) Willem de Bruijn (commit_signer:2/4=50%) Daniel Baluta (commit_signer:1/4=25%) Eric Dumazet (commit_signer:1/4=25%) linux-kernel@vger.kernel.org (open list) thanks, Daniel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf/hwbp: Fix cleanup in case of kzalloc failure
Obviously this is a typo and could result in memory leaks
if kzalloc fails on a given cpu.
Signed-off-by: Daniel Baluta
---
kernel/events/hw_breakpoint.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c
index fe8a916..a64f8ae 100644
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -676,7 +676,7 @@ int __init init_hw_breakpoint(void)
err_alloc:
for_each_possible_cpu(err_cpu) {
for (i = 0; i < TYPE_MAX; i++)
- kfree(per_cpu(nr_task_bp_pinned[i], cpu));
+ kfree(per_cpu(nr_task_bp_pinned[i], err_cpu));
if (err_cpu == cpu)
break;
}
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] ndisc: bool initializations should use true and false
Signed-off-by: Daniel Baluta
---
net/ipv6/ndisc.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/ndisc.c b/net/ipv6/ndisc.c
index b3b5730..24c03396 100644
--- a/net/ipv6/ndisc.c
+++ b/net/ipv6/ndisc.c
@@ -479,7 +479,7 @@ static void ndisc_send_na(struct net_device *dev, struct
neighbour *neigh,
if (ifp) {
src_addr = solicited_addr;
if (ifp->flags & IFA_F_OPTIMISTIC)
- override = 0;
+ override = false;
inc_opt |= ifp->idev->cnf.force_tllao;
in6_ifa_put(ifp);
} else {
@@ -557,7 +557,7 @@ void ndisc_send_ns(struct net_device *dev, struct neighbour
*neigh,
}
if (ipv6_addr_any(saddr))
- inc_opt = 0;
+ inc_opt = false;
if (inc_opt)
optlen += ndisc_opt_addr_space(dev);
@@ -790,7 +790,7 @@ static void ndisc_recv_ns(struct sk_buff *skb)
(is_router = pndisc_is_router(&msg->target, dev)) >= 0)) {
if (!(NEIGH_CB(skb)->flags & LOCALLY_ENQUEUED) &&
skb->pkt_type != PACKET_HOST &&
- inc != 0 &&
+ inc &&
idev->nd_parms->proxy_delay != 0) {
/*
* for anycast or proxy,
--
1.7.10.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mm: fix overflow in alloc_vmap_area
On Thu, Jun 20, 2013 at 7:59 PM, Zhang Yanfei wrote:
> On 06/20/2013 11:12 PM, Ghennadi Procopciuc wrote:
>> Inserting the following kernel module:
>>
>>
>>
>> static int simple_test_init(void)
>> {
>> size_t i, j;
>> void *address;
>>
>> for (i = 0 * MB; i< 60 * MB; i += 1 * MB) {
>> for (j = i; j< i + 1 * MB; j += KB) {
>> address = vmalloc(j);
>> vfree(address);
>> }
>> }
>>
>> return 0;
>> }
>>
>>
>>
>> triggers BUG at mm/vmalloc.c:310 on a x86 machine:
>>
>> [ 95.218283] Kernel BUG at c1126cdb [verbose debug info unavailable]
>> [ 95.218306] invalid opcode: [#1] SMP
>> [ 95.218324] Modules linked in: lkma_test(OF+)> modules>
>> [ 95.218559] Pid: 2419, comm: insmod Tainted: GF O 3.9.0+ #57
>> Hewlett-Packard HP Compaq 8200 Elite CMT PC/1494
>> [ 95.218597] EIP: 0060:[] EFLAGS: 00010207 CPU: 3
>> [ 95.218617] EIP is at __insert_vmap_area+0xfb/0x100
>> [ 95.218635] EAX: f85dc000 EBX: ef05cac0 ECX: f7be08c4 EDX: 0007
>> [ 95.218657] ESI: f2ed044c EDI: c1a220b8 EBP: f027bd34 ESP: f027bd14
>> [ 95.218680] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
>> [ 95.218699] CR0: 80050033 CR2: b5995118 CR3: 30364000 CR4: 000407f0
>> [ 95.218721] DR0: DR1: DR2: DR3:
>> [ 95.218743] DR6: 0ff0 DR7: 0400
>> [ 95.218758] Process insmod (pid: 2419, ti=f027a000 task=efe64010
>> task.ti=f027a000)
>> [ 95.218784] Stack:
>> [ 95.218792] c177b964 fecfb000 f85e2000 f85dc000 ffbfe000
>> f02da1c0 0007f000
>> [ 95.218829] f027bd7c c112802d c177b9b0 fecfb000 01305000 ffbfe000
>> 0001 ef05cac0
>> [ 95.218866] f83fe000 01304fff f83fe000
>> 01305000 ef05c500
>> [ 95.218903] Call Trace:
>> [ 95.218915] [] ? 0xf85e1fff
>> [ 95.218930] [] ? 0xf85dbfff
>> [ 95.218945] [] alloc_vmap_area.isra.16+0x1bd/0x2f0
>> [ 95.218967] [] __get_vm_area_node.isra.17+0x8f/0x130
>> [ 95.218988] [] __vmalloc_node_range+0x57/0x200
>> [ 95.219009] [] ? lkma_test_init+0x45/0x70 [lkma_test]
>> [ 95.219031] [] __vmalloc_node+0x62/0x70
>> [ 95.219049] [] ? lkma_test_init+0x45/0x70 [lkma_test]
>> [ 95.219071] [] vmalloc+0x38/0x40
>> [ 95.219087] [] ? lkma_test_init+0x45/0x70 [lkma_test]
>> [ 95.219109] [] lkma_test_init+0x45/0x70 [lkma_test]
>> [ 95.219131] [] ? kzalloc+0x10/0x10 [lkma_test]
>> [ 95.219151] [] do_one_initcall+0x112/0x160
>> [ 95.219171] [] ? set_section_ro_nx+0x54/0x59
>> [ 95.219190] [] load_module+0x1d79/0x2660
>> [ 95.219209] [] ? create_object+0x19d/0x280
>> [ 95.219230] [] sys_init_module+0x78/0xb0
>> [ 95.219250] [] sysenter_do_call+0x12/0x22
>> [ 95.219268] Code: 39 03 73 0c 8b 3f 89 f0 83 c7 08 e9 3d ff ff ff 8b 46
>> f4 39 43 04 76 13 8b 3f 89 f0 83 c7 04 e9 29 ff ff ff e8 fb 1b 4a 00 eb
>> ab<0f> 0b 8d 76 00 55 89 e5 56 53 66 66 66 66 90 83 60 0c df 89 c6
>> [ 95.219415] EIP: [] __insert_vmap_area+0xfb/0x100 SS:ESP
>> 0068:f027bd14
>> [ 95.228313] ---[ end trace e0a1efb2acb97c98 ]---
>>
>> A printk placed in __insert_vmap_area will show:
>>
>> [ 95.218256] va->va_start=0xfecfb000 tmp_va->va_end=0xf85e2000
>> va->va_end=0 tmp_va->va_start=0xf85dc000
>>
>> and another one, before sum operation in alloc_vmap_area:
>>
>> [ 95.218204] addr = 0xfecfb000 size = 19943424 vend = 0xffbfe000
>>
>> If after addition the result is smaller than one of the arguments,
>> then an overflow occurred. In our case there is an obvious overflow.
>>
>> Signed-off-by: Ghennadi Procopciuc
>> Cc: Daniel Baluta
>>
>> ---
>> Don't know if this is the right solution, but the bug happens for me in
>> 3.10-rc6 and 3.9.
>
> Hello Ghennadi,
>
> Could you please try the below patch to see if it is ok? The patch is based
> on today's linus' tree.
Hi Zhang,
I have applied your patch and the bug seems to be fixed.
Commit 89699605fe (mm: vmap area cache) suggests to use
"addr + size < addr" instead of "addr + size - 1 < addr" so I guess
this is the correct fix.
thanks,
Daniel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] net: fix build warning in trans_rdma.c
On Tue, Jul 30, 2013 at 12:15 PM, Xishi Qiu wrote:
> When building v3.11-rc3, I get the following warning:
> ...
> net/9p/trans_rdma.c:594: warning: ‘rdma_cancelled’ defined but not used
> ...
> As the function is not be used, so remove it.
>
> Signed-off-by: Xishi Qiu
> ---
> net/9p/trans_rdma.c | 11 ---
> 1 files changed, 0 insertions(+), 11 deletions(-)
>
> diff --git a/net/9p/trans_rdma.c b/net/9p/trans_rdma.c
> index 928f2bb..8f68df5 100644
> --- a/net/9p/trans_rdma.c
> +++ b/net/9p/trans_rdma.c
> @@ -588,17 +588,6 @@ static int rdma_cancel(struct p9_client *client, struct
> p9_req_t *req)
> return 1;
> }
>
> -/* A request has been fully flushed without a reply.
> - * That means we have posted one buffer in excess.
> - */
> -static int rdma_cancelled(struct p9_client *client, struct p9_req_t *req)
> -{
> - struct p9_trans_rdma *rdma = client->trans;
> -
> - atomic_inc(&rdma->excess_rc);
> - return 0;
> -}
> -
> /**
> * trans_create_rdma - Transport method for creating atransport instance
> * @client: client instance
Hi,
This is wrong.
Please check http://comments.gmane.org/gmane.linux.network/276261.
thanks,
Daniel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] lustre:libcfs: remove redundant code.
On Fri, Jul 19, 2013 at 6:46 PM, Greg Kroah-Hartman wrote: > On Fri, Jul 19, 2013 at 06:29:34PM +0300, Alexandru Juncu wrote: >> On 19 July 2013 18:21, Pekka Enberg wrote: >> > On Fri, Jul 19, 2013 at 6:13 PM, Alexandru Juncu wrote: >> >> I was thinking the same thing, but I hesitated because I didn't know >> >> how used it was and I didn't want to break something. >> > >> > "git grep cfs_strdup" suggests that nobody uses it so you could just >> > remove it completely... >> >> Did a grep on the tree and yes, it's not used. But It's in a staging >> directory so maybe the rest of the code has not been pushed in yet. > > Doesn't matter, if there are no users, please just remove it. Hi Greg, There is already a similar patch for this https://lkml.org/lkml/2013/7/17/742, already reviewed by Andreas Dilger. thanks, Daniel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] lguest: rename i386_head.S
Since commit 9a163ed8e0 (i386: move kernel) kernel/i386_head.S
was renamed to kernel/head_32.S. We do the same for lguest/i386_head.S.
Signed-off-by: Daniel Baluta
---
arch/x86/lguest/{i386_head.S => head_32.S} |0
1 files changed, 0 insertions(+), 0 deletions(-)
rename arch/x86/lguest/{i386_head.S => head_32.S} (100%)
diff --git a/arch/x86/lguest/i386_head.S b/arch/x86/lguest/head_32.S
similarity index 100%
rename from arch/x86/lguest/i386_head.S
rename to arch/x86/lguest/head_32.S
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] lguest: rename i386_head.S
Since commit 9a163ed8e0 (i386: move kernel) kernel/i386_head.S
was renamed to kernel/head_32.S. We do the same for lguest/i386_head.S.
Signed-off-by: Daniel Baluta
---
Changes since v1:
* use head_32.o in Makefile
arch/x86/lguest/Makefile |2 +-
arch/x86/lguest/{i386_head.S => head_32.S} |0
2 files changed, 1 insertions(+), 1 deletions(-)
rename arch/x86/lguest/{i386_head.S => head_32.S} (100%)
diff --git a/arch/x86/lguest/Makefile b/arch/x86/lguest/Makefile
index 94e0e54..8f38d57 100644
--- a/arch/x86/lguest/Makefile
+++ b/arch/x86/lguest/Makefile
@@ -1,2 +1,2 @@
-obj-y := i386_head.o boot.o
+obj-y := head_32.o boot.o
CFLAGS_boot.o := $(call cc-option, -fno-stack-protector)
diff --git a/arch/x86/lguest/i386_head.S b/arch/x86/lguest/head_32.S
similarity index 100%
rename from arch/x86/lguest/i386_head.S
rename to arch/x86/lguest/head_32.S
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] hugetlb: fix sparse warning for hugetlb_register_node
On Mon, Mar 4, 2013 at 12:46 PM, Claudiu Ghioc wrote:
> Removed the following sparse warnings:
> * mm/hugetlb.c:1764:6: warning: symbol
> 'hugetlb_unregister_node' was not declared.
> Should it be static?
> * mm/hugetlb.c:1808:6: warning: symbol
> 'hugetlb_register_node' was not declared.
> Should it be static?
>
> Signed-off-by: Claudiu Ghioc
> ---
> mm/hugetlb.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index 0a0be33..c65a8a5 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -1761,7 +1761,7 @@ static struct hstate *kobj_to_node_hstate(struct
> kobject *kobj, int *nidp)
> * Unregister hstate attributes from a single node device.
> * No-op if no hstate attributes attached.
> */
> -void hugetlb_unregister_node(struct node *node)
> +static void hugetlb_unregister_node(struct node *node)
> {
> struct hstate *h;
> struct node_hstate *nhs = &node_hstates[node->dev.id];
> @@ -1805,7 +1805,7 @@ static void hugetlb_unregister_all_nodes(void)
> * Register hstate attributes for a single node device.
> * No-op if attributes already registered.
> */
> -void hugetlb_register_node(struct node *node)
> +static void hugetlb_register_node(struct node *node)
> {
> struct hstate *h;
> struct node_hstate *nhs = &node_hstates[node->dev.id];
> --
> 1.7.9.5
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Hi Jiri,
Can you pick this up via trivial tree?
thanks,
Daniel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] kgdb: Removed kmalloc returned value cast
On Sun, Mar 10, 2013 at 4:10 PM, Pekka Enberg wrote: > On Sun, Mar 10, 2013 at 3:06 PM, Alex Grad wrote: >> Signed-off-by: Alex Grad >> --- >> arch/powerpc/kernel/kgdb.c |2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/powerpc/kernel/kgdb.c b/arch/powerpc/kernel/kgdb.c >> index 5ca82cd..c1eef24 100644 >> --- a/arch/powerpc/kernel/kgdb.c >> +++ b/arch/powerpc/kernel/kgdb.c >> @@ -159,7 +159,7 @@ static int kgdb_singlestep(struct pt_regs *regs) >> if (user_mode(regs)) >> return 0; >> >> - backup_current_thread_info = (struct thread_info >> *)kmalloc(sizeof(struct thread_info), GFP_KERNEL); >> + backup_current_thread_info = kmalloc(sizeof(struct thread_info), >> GFP_KERNEL); > > Looks good to me. > > There's two additional problems in the kgdb_singlestep() function: it > doesn't check if the kmalloc() call fails nor does it kfree() the > allocated memory. Hi Pekka, Indeed there is no check if kmalloc() fails. This should be fixed. Anyhow, commit fefd9e6f powerpc: kernel/kgdb.c: Fix memory leakage fixed the problem with kfree. thanks, Daniel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] block: replace kmalloc and then memcpy with kmemdup
Hi Konrad, The performance is the same using kmemdup, but we have the following advantages: * code is cleaner * kmemdup adds additional debugging info useful for tracking the real place where memory was allocated [1] [2]. thanks, Daniel. [1] http://lxr.linux.no/#linux+v3.8.2/mm/util.c#L61 [2] http://lxr.linux.no/#linux+v3.8.2/include/linux/slab.h#L363 On Mon, Mar 11, 2013 at 4:54 PM, Konrad Rzeszutek Wilk wrote: > On Mon, Mar 11, 2013 at 01:23:36PM +0200, Mihnea Dobrescu-Balaur wrote: > > Are there performance improvements to doing it this way? > >> Signed-off-by: Mihnea Dobrescu-Balaur >> --- >> drivers/block/xen-blkfront.c |3 +-- >> 1 file changed, 1 insertion(+), 2 deletions(-) >> >> diff --git a/drivers/block/xen-blkfront.c b/drivers/block/xen-blkfront.c >> index c3dae2e..9620644 100644 >> --- a/drivers/block/xen-blkfront.c >> +++ b/drivers/block/xen-blkfront.c >> @@ -1203,11 +1203,10 @@ static int blkif_recover(struct blkfront_info *info) >> int j; >> >> /* Stage 1: Make a safe copy of the shadow state. */ >> - copy = kmalloc(sizeof(info->shadow), >> + copy = kmemdup(info->shadow, sizeof(info->shadow), >> GFP_NOIO | __GFP_REPEAT | __GFP_HIGH); >> if (!copy) >> return -ENOMEM; >> - memcpy(copy, info->shadow, sizeof(info->shadow)); >> >> /* Stage 2: Set up free list. */ >> memset(&info->shadow, 0, sizeof(info->shadow)); >> -- >> 1.7.10.4 >> > ___ > Virtualization mailing list > virtualizat...@lists.linux-foundation.org > https://lists.linuxfoundation.org/mailman/listinfo/virtualization -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Arch: x86: kernel: smpboot.c: Remove unused variable
On Mon, Mar 11, 2013 at 9:23 PM, Valentin Ilie wrote: > Remove unused variable 'c' > > Signed-off-by: Valentin Ilie > --- > arch/x86/kernel/smpboot.c |1 - > 1 file changed, 1 deletion(-) > > diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c > index a6ceaed..7bc998a 100644 > --- a/arch/x86/kernel/smpboot.c > +++ b/arch/x86/kernel/smpboot.c > @@ -1367,7 +1367,6 @@ static inline void mwait_play_dead(void) > unsigned int highest_subcstate = 0; > int i; > void *mwait_ptr; > - struct cpuinfo_x86 *c = __this_cpu_ptr(&cpu_info); > > if (!this_cpu_has(X86_FEATURE_MWAIT)) > return; > -- > 1.7.10.4 Hi Valentin, I guess a better subject for this patch should be x86, smpboot: Remove unused variable Use git log arch/x86/kernel/smpboot.c to check previous commits. thanks, Daniel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio: suppress kmemleak false positive
On Fri, Jan 11, 2013 at 4:32 PM, Daniel Baluta wrote: > > > On Fri, Jan 11, 2013 at 4:02 PM, Catalin Marinas > wrote: >> >> On Fri, Jan 11, 2013 at 01:51:43PM +, Alexandru Copot wrote: >> > While doing simple IPv6 tests in KVM virtual machines, >> > (add an IPv6 address to eth0) kmemleak complains about >> > an unreferenced object: >> > >> > unreferenced object 0x88001e804120 (size 32): >> > comm "softirq", pid 0, jiffies 4294900928 (age 631.544s) >> > hex dump (first 32 bytes): >> > 28 cb fd 1d 00 00 00 00 0c 00 00 00 01 00 01 00 (... >> > 02 d0 83 1d 00 00 00 00 6e 00 00 00 00 00 00 00 n... >> > backtrace: >> > [] kmemleak_alloc+0x21/0x50 >> > [] __kmalloc+0xe0/0x160 >> > [] virtqueue_add_buf+0x1fc/0x3d0 >> > [] start_xmit+0x153/0x3a0 >> > [] dev_hard_start_xmit+0x21e/0x470 >> > [] sch_direct_xmit+0xfe/0x280 >> > [] dev_queue_xmit+0x1f4/0x5d0 >> > [] ip6_finish_output2+0x101/0x450 >> > [] ip6_finish_output+0x98/0x200 >> > [] ip6_output+0x51/0x1b0 >> > [] mld_sendpack+0x19f/0x360 >> > [] mld_ifc_timer_expire+0x194/0x290 >> > [] call_timer_fn+0x74/0xf0 >> > [] run_timer_softirq+0x18b/0x220 >> > [] __do_softirq+0xe1/0x1c0 >> > [] call_softirq+0x1c/0x30 >> > >> > Seems the function vring_add_indirect stores an array of >> > struct vring_desc by using virt_to_phys and kmemleak >> > doesn't track the pointer. >> > >> > The following patch can fix this. >> > >> > Signed-off-by: Alexandru Copot >> > CC: Daniel Baluta >> > --- >> > drivers/virtio/virtio_ring.c | 2 ++ >> > 1 file changed, 2 insertions(+) >> > >> > diff --git a/drivers/virtio/virtio_ring.c >> > b/drivers/virtio/virtio_ring.c >> > index ffd7e7d..e0b591b 100644 >> > --- a/drivers/virtio/virtio_ring.c >> > +++ b/drivers/virtio/virtio_ring.c >> > @@ -23,6 +23,7 @@ >> > #include >> > #include >> > #include >> > +#include >> > >> > /* virtio guest is communicating with a virtual "device" that actually >> > runs on >> > * a host processor. Memory barriers are used to control SMP effects. >> > */ >> > @@ -140,6 +141,7 @@ static int vring_add_indirect(struct >> > vring_virtqueue >> > *vq, >> > desc = kmalloc((out + in) * sizeof(struct vring_desc), gfp); >> > if (!desc) >> > return -ENOMEM; >> > + kmemleak_not_leak(desc); >> >> Please add a comment above this call in case people later wonder why >> this annotation is needed. >> > > Thanks Cătălin. > > So, kememleak cannot handle this kind of pointer aliases? > Also, I wonder if phys_to_virt(virt_to_phys(x)) == x holds true all the > time. Sending this again as it seems that linux-kernel rejected it because of HTML format. Sorry for the noise. thanks, Daniel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] tools/lguest: Don't bork the terminal in case of wrong args
On Tue, Dec 8, 2015 at 4:35 PM, Daniel Baluta wrote: > Running lguest without arguments or with a wrong argument name > borks the terminal, because the cleanup handler is set up too late > in the initialization process. > > Signed-off-by: Daniel Baluta Hi Rusty, Any chance to pick this up?
Re: [PATCH] iio: Move IIO Dummy Driver out of staging
>> +static unsigned instances = 1; >> +module_param(instances, uint, 0); One concern about this. We will still create a default number of 'instances' when using configuration via configfs? I'm not sure we can remove this parameter once the module is moved out of staging, since we break the ABI (?) The rest looks good to me. I'm pretty sure that moving this out of staging will make the module more visible and people will jump with enhancements. thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 1/5] configfs: Allow dynamic group creation
On Thu, Oct 22, 2015 at 11:40 AM, Christoph Hellwig wrote: > On Tue, Oct 20, 2015 at 01:53:42PM +0300, Daniel Baluta wrote: >> We don't want to hardcode default groups at subsystem >> creation time. We export: >> * configfs_register_group >> * configfs_unregister_group >> to allow drivers to programatically create/destroy groups >> later, after module init time. >> >> This is needed for IIO configfs support. > > This looks like a good start, and maybe we should merge it as is given > that merge window is about to end. But I have two requests, one trivial > and one not so: > > a) please provide kerneldoc comments for the new functions > b) just pass the name and item type and dynamically allocate the > actua group. With that we can avoid a lot of boilerplate code and > could also replace the horrible static sized defaults_groups array > in current users with your new function. Will try to see how quick I can do this. Eventually we can introduce the new function + use it in IIO and fix current users later. Thanks Christoph! Daniel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v1 4/4] iio: chemical: add SGX VZ89x VOC sensor support
On Sat, Sep 5, 2015 at 8:53 AM, Matt Ranostay wrote:
> Add support for VZ89X sensors VOC and CO2 reporting channels in
> ppm/ppb units.
Adding more info on this would be great.
s/VOC/VOC(volatile organic compound)
Also, link to datasheet?
>
> Signed-off-by: Matt Ranostay
> ---
> .../devicetree/bindings/i2c/trivial-devices.txt| 1 +
> drivers/iio/Kconfig| 1 +
> drivers/iio/Makefile | 1 +
> drivers/iio/chemical/Makefile | 6 +
> drivers/iio/chemical/vz89x.c | 237
> +
Do you have a real part number for vz89x.c. Sometime ago, we agree to
avoid using generic part
numbers in files. So vz890 (if exists) is preferred over vz89x.c.
Is vz89x a family of devices? :)
> 5 files changed, 246 insertions(+)
> create mode 100644 drivers/iio/chemical/Makefile
> create mode 100644 drivers/iio/chemical/vz89x.c
>
> diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> index d77d412..a550216 100644
> --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt
> @@ -88,6 +88,7 @@ ricoh,rs5c372bI2C bus SERIAL INTERFACE
> REAL-TIME CLOCK IC
> ricoh,rv5c386 I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
> ricoh,rv5c387a I2C bus SERIAL INTERFACE REAL-TIME CLOCK IC
> samsung,24ad0xd1 S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power)
> +sgx,vz89x SGX Sensortech VZ89X Sensors
You should also CC devicetree people for this.
> sii,s35390a2-wire CMOS real-time clock
> skyworks,sky81452 Skyworks SKY81452: Six-Channel White LED Driver with
> Touch Panel Bias Supply
> st-micro,24c256i2c serial eeprom (24cxx)
> diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
> index 4011eff..9664e9c 100644
> --- a/drivers/iio/Kconfig
> +++ b/drivers/iio/Kconfig
> @@ -61,6 +61,7 @@ config IIO_CONSUMERS_PER_TRIGGER
> source "drivers/iio/accel/Kconfig"
> source "drivers/iio/adc/Kconfig"
> source "drivers/iio/amplifiers/Kconfig"
> +source "drivers/iio/chemical/Kconfig"
> source "drivers/iio/common/Kconfig"
> source "drivers/iio/dac/Kconfig"
> source "drivers/iio/frequency/Kconfig"
> diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
> index 698afc2..2288684 100644
> --- a/drivers/iio/Makefile
> +++ b/drivers/iio/Makefile
> @@ -14,6 +14,7 @@ obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
> obj-y += accel/
> obj-y += adc/
> obj-y += amplifiers/
> +obj-y += chemical/
> obj-y += common/
> obj-y += dac/
> obj-y += gyro/
> diff --git a/drivers/iio/chemical/Makefile b/drivers/iio/chemical/Makefile
> new file mode 100644
> index 000..7292f2d
> --- /dev/null
> +++ b/drivers/iio/chemical/Makefile
> @@ -0,0 +1,6 @@
> +#
> +# Makefile for IIO chemical sensors
> +#
> +
> +# When adding new entries keep the list in alphabetical order
> +obj-$(CONFIG_VZ89X)+= vz89x.o
> diff --git a/drivers/iio/chemical/vz89x.c b/drivers/iio/chemical/vz89x.c
> new file mode 100644
> index 000..a596a22
> --- /dev/null
> +++ b/drivers/iio/chemical/vz89x.c
> @@ -0,0 +1,237 @@
> +/*
> + * vz89x.c - Support for SGX Sensortech MiCS VZ89X VOC sensors
> + *
> + * Copyright (C) 2015 Matt Ranostay
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +
> +#include
> +#include
> +
> +#define VZ89X_REG_MEASUREMENT 0x09
> +#define VZ89X_REG_MEASUREMENT_SIZE 6
> +
> +#define VZ89X_VOC_CO2_IDX 0
> +#define VZ89X_VOC_SHORT_IDX1
> +#define VZ89X_VOC_TVOC_IDX 2
> +#define VZ89X_RESISTANCE_IDX 3
> +
> +struct vz89x_data {
> + struct i2c_client *client;
> + struct mutex lock;
> + unsigned long last_update;
> +
> + u8 buffer[VZ89X_REG_MEASUREMENT_SIZE];
> +};
> +
> +static const struct iio_chan_spec vz89x_channels[] = {
> + {
> + .type = IIO_CONCENTRATION,
> + .channel2 = IIO_MOD_PPM,
> + .modified = 1,
> + .info_mask_separate = BIT(IIO_CHAN_INFO_OFFSET) |
> + BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE),
> + .address = VZ89X_VOC_CO2_IDX,
> + .extend_name = "CO2",
> + },
> + {
> + .type = IIO_CONCENTRATION,
> + .info_mask_separate =
>
Re: [RFC v1 3/4] devicetree: add SGX Sensortech vendor id
don't forget to cc devicetree people. On Sat, Sep 5, 2015 at 8:53 AM, Matt Ranostay wrote: > Signed-off-by: Matt Ranostay > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt > b/Documentation/devicetree/bindings/vendor-prefixes.txt > index ac5f0c3..281e8f0 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -191,6 +191,7 @@ sbs Smart Battery System > schindler Schindler > seagateSeagate Technology PLC > semtechSemtech Corporation > +sgxSGX Sensortech > sharp Sharp Corporation > silSilicon Image > silabs Silicon Laboratories > -- > 1.9.1 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-iio" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v1 0/4] iio: new chemical sensor framework and channel types
On Sat, Sep 5, 2015 at 8:53 AM, Matt Ranostay wrote: > Initial RFC for new chemical sensor framework, IIO_CONCENTRATION, > and IIO_RESISTANCE channel types. > > Important notes: > * Not been tested on real hardware yet but that isn't the main RFC reason and > once hardware is in hand it will be verified > * Reason the IIO_CONCENTRATION type isn't in percent but has modifiers for ppm > and ppb is the scale value for the latter would cause a integer overflow > using IIO_VAL_FRACTIONAL Please add this details also in the commit message introducing IIO_CONCENTRATION. Readers will faster find commit messages than cover letter. Interesting patches Matt! :) thanks, Daniel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] staging: iio: select IRQ_WORK for IIO_DUMMY_EVGEN
On Sat, Oct 17, 2015 at 1:29 AM, Arnd Bergmann wrote:
> The iio dummy code was recently changed to use irq_work_queue, but
> that code is compiled into the kernel only if IRQ_WORK is set, so
> we can get a link error here:
>
> drivers/built-in.o: In function `iio_evgen_poke':
> (.text+0x208a04): undefined reference to `irq_work_queue'
>
> This changes the Kconfig file to match what other drivers do.
>
> Signed-off-by: Arnd Bergmann
> Fixes: fd2bb310ca3d ("Staging: iio: Move evgen interrupt generation to
> irq_work")
Acked-by: Daniel Baluta
> ---
> Found on ARM randconfig tests
>
> diff --git a/drivers/staging/iio/Kconfig b/drivers/staging/iio/Kconfig
> index 6d5b38d69578..9d7f0004d2d7 100644
> --- a/drivers/staging/iio/Kconfig
> +++ b/drivers/staging/iio/Kconfig
> @@ -18,7 +18,8 @@ source "drivers/staging/iio/resolver/Kconfig"
> source "drivers/staging/iio/trigger/Kconfig"
>
> config IIO_DUMMY_EVGEN
> - tristate
> + tristate
> + select IRQ_WORK
>
> config IIO_SIMPLE_DUMMY
> tristate "An example driver with no hardware requirements"
>
> --
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 3/5] iio: core: Introduce IIO software triggers
A software trigger associates an IIO device trigger with a software
interrupt source (e.g: timer, sysfs). This patch adds the generic
infrastructure for handling software triggers.
Software interrupts sources are kept in a iio_trigger_types_list and
registered separately when the associated kernel module is loaded.
Software triggers can be created directly from drivers or from user
space via configfs interface.
Signed-off-by: Daniel Baluta
---
drivers/iio/Kconfig | 7 ++
drivers/iio/Makefile | 1 +
drivers/iio/industrialio-configfs.c | 37 -
drivers/iio/industrialio-sw-trigger.c | 137 ++
include/linux/iio/sw_trigger.h| 120 +
5 files changed, 301 insertions(+), 1 deletion(-)
create mode 100644 drivers/iio/industrialio-sw-trigger.c
create mode 100644 include/linux/iio/sw_trigger.h
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 7a4815a..293593e 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -46,6 +46,13 @@ config IIO_CONSUMERS_PER_TRIGGER
This value controls the maximum number of consumers that a
given trigger may handle. Default is 2.
+config IIO_SW_TRIGGER
+ bool "Enable software triggers support"
+ help
+Provides IIO core support for software triggers. A software
+trigger can be created via configfs or directly by a driver
+using the API provided.
+
config IIO_TRIGGERED_EVENT
tristate
select IIO_TRIGGER
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index e109f95..3524636 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -7,6 +7,7 @@ industrialio-y := industrialio-core.o industrialio-event.o
inkern.o
industrialio-$(CONFIG_IIO_BUFFER) += industrialio-buffer.o
industrialio-$(CONFIG_IIO_CONFIGFS) += industrialio-configfs.o
industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
+industrialio-$(CONFIG_IIO_SW_TRIGGER) += industrialio-sw-trigger.o
obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
diff --git a/drivers/iio/industrialio-configfs.c
b/drivers/iio/industrialio-configfs.c
index 211b52e..9a9f8bc 100644
--- a/drivers/iio/industrialio-configfs.c
+++ b/drivers/iio/industrialio-configfs.c
@@ -15,8 +15,43 @@
#include
#include
+#include
-static struct config_item_type iio_triggers_group_type = {
+static struct config_group *trigger_make_group(struct config_group *group,
+ const char *name)
+{
+ struct iio_sw_trigger *t;
+
+ t = iio_sw_trigger_create(group->cg_item.ci_name, name);
+ if (IS_ERR(t))
+ return ERR_CAST(t);
+
+ config_item_set_name(&t->group.cg_item, "%s", name);
+
+ return &t->group;
+}
+
+static void trigger_drop_group(struct config_group *group,
+ struct config_item *item)
+{
+ struct iio_sw_trigger *t = to_iio_sw_trigger(item);
+
+ iio_sw_trigger_destroy(t);
+ config_item_put(item);
+}
+
+static struct configfs_group_operations trigger_ops = {
+ .make_group = &trigger_make_group,
+ .drop_item = &trigger_drop_group,
+};
+
+struct config_item_type iio_trigger_type_group_type = {
+ .ct_group_ops = &trigger_ops,
+ .ct_owner = THIS_MODULE,
+};
+EXPORT_SYMBOL(iio_trigger_type_group_type);
+
+struct config_item_type iio_triggers_group_type = {
.ct_owner = THIS_MODULE,
};
diff --git a/drivers/iio/industrialio-sw-trigger.c
b/drivers/iio/industrialio-sw-trigger.c
new file mode 100644
index 000..bdff360
--- /dev/null
+++ b/drivers/iio/industrialio-sw-trigger.c
@@ -0,0 +1,137 @@
+/*
+ * The Industrial I/O core, software trigger functions
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static LIST_HEAD(iio_trigger_types_list);
+static DEFINE_MUTEX(iio_trigger_types_lock);
+
+static
+struct iio_sw_trigger_type *__iio_find_sw_trigger_type(const char *name,
+ unsigned len)
+{
+ struct iio_sw_trigger_type *t = NULL, *iter;
+
+ list_for_each_entry(iter, &iio_trigger_types_list, list)
+ if (!strcmp(iter->name, name)) {
+ t = iter;
+ break;
+ }
+
+ return t;
+}
+
+int iio_register_sw_trigger_type(struct iio_sw_trigger_type *t)
+{
+ struct iio_sw_trigger_type *iter;
+ int ret = 0;
+
+ mutex_lock(&iio_trigger_types_lock);
+ iter = __iio_find_sw_trigger_type(t->name, strlen(t->name));
+ if (iter)
+ ret = -EBUSY;
+ el
[PATCH v8 1/5] configfs: Allow dynamic group creation
We don't want to hardcode default groups at subsystem
creation time. We export:
* configfs_register_group
* configfs_unregister_group
to allow drivers to programatically create/destroy groups
later, after module init time.
This is needed for IIO configfs support.
Suggested-by: Lars-Peter Clausen
Signed-off-by: Daniel Baluta
---
fs/configfs/dir.c| 50
include/linux/configfs.h | 4
2 files changed, 54 insertions(+)
diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
index c81ce7f..1f5337c 100644
--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -1636,6 +1636,56 @@ const struct file_operations configfs_dir_operations = {
.iterate= configfs_readdir,
};
+int configfs_register_group(struct config_group *parent_group,
+ struct config_group *group)
+{
+ struct configfs_subsystem *subsys = parent_group->cg_subsys;
+ struct dentry *parent;
+ int ret;
+
+ mutex_lock(&subsys->su_mutex);
+ link_group(parent_group, group);
+ mutex_unlock(&subsys->su_mutex);
+
+ parent = parent_group->cg_item.ci_dentry;
+
+ mutex_lock_nested(&d_inode(parent)->i_mutex, I_MUTEX_PARENT);
+ ret = create_default_group(parent_group, group);
+ if (!ret) {
+ spin_lock(&configfs_dirent_lock);
+ configfs_dir_set_ready(group->cg_item.ci_dentry->d_fsdata);
+ spin_unlock(&configfs_dirent_lock);
+ }
+ mutex_unlock(&d_inode(parent)->i_mutex);
+ return ret;
+}
+EXPORT_SYMBOL(configfs_register_group);
+
+void configfs_unregister_group(struct config_group *group)
+{
+ struct configfs_subsystem *subsys = group->cg_subsys;
+ struct dentry *dentry = group->cg_item.ci_dentry;
+ struct dentry *parent = group->cg_item.ci_parent->ci_dentry;
+
+ mutex_lock_nested(&d_inode(parent)->i_mutex, I_MUTEX_PARENT);
+ spin_lock(&configfs_dirent_lock);
+ configfs_detach_prep(dentry, NULL);
+ spin_unlock(&configfs_dirent_lock);
+
+ configfs_detach_group(&group->cg_item);
+ d_inode(dentry)->i_flags |= S_DEAD;
+ dont_mount(dentry);
+ d_delete(dentry);
+ mutex_unlock(&d_inode(parent)->i_mutex);
+
+ dput(dentry);
+
+ mutex_lock(&subsys->su_mutex);
+ unlink_group(group);
+ mutex_unlock(&subsys->su_mutex);
+}
+EXPORT_SYMBOL(configfs_unregister_group);
+
int configfs_register_subsystem(struct configfs_subsystem *subsys)
{
int err;
diff --git a/include/linux/configfs.h b/include/linux/configfs.h
index 63a36e8..c40b8143 100644
--- a/include/linux/configfs.h
+++ b/include/linux/configfs.h
@@ -252,6 +252,10 @@ static inline struct configfs_subsystem
*to_configfs_subsystem(struct config_gro
int configfs_register_subsystem(struct configfs_subsystem *subsys);
void configfs_unregister_subsystem(struct configfs_subsystem *subsys);
+int configfs_register_group(struct config_group *parent_group,
+ struct config_group *group);
+void configfs_unregister_group(struct config_group *group);
+
/* These functions can sleep and can alloc with GFP_KERNEL */
/* WARNING: These cannot be called underneath configfs callbacks!! */
int configfs_depend_item(struct configfs_subsystem *subsys, struct config_item
*target);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 0/5] Add initial configfs support for IIO
This patchset introduces IIO software triggers, offers a way of configuring them via configfs and adds the IIO hrtimer based interrupt source to be used with software triggers. The arhitecture is now split in 3 parts, to remove all IIO trigger specific parts from IIO configfs core: (1) IIO configfs - offers a generic way of creating IIO objects. So far there is one default group for triggers. (2) IIO software triggers - software trigger implementation. (3) IIO hrtimer trigger - is the first interrupt source for software triggers (with syfs to follow). Each trigger type can implement its own set of attributes. Lockdep seems to be happy with the locking in configfs patch. Changes since v7: * patch 1/5 * do not add dentry parameter for create_default_group, we can retrieve it from group. * call configfs_detach_prep before configfs_detach_group in configfs_unregister_group. * call link_group/unlink_group under su_mutex lock * take configfs_dirent_lock when calling configfs_dir_set_ready * patch 2/5 * export iio_triggers_group, this will be later used by sw triggers * patch 3/5 * make iio_sw_trigger part of industrialio core * fix compilation problem reported by Vladimir and Lars. Things didn't get well when having IIO_SW_TRIGGER enabled and IIO_CONFIGFS disabled. * use format string in config_item_set_name * make iio_unregister_sw_trigger_type return type void. * patch 4/5 * none * patch 5/5 * include a small trigger type sample example. Changes since v6: * implemented Lars-Peter's idea (https://lkml.org/lkml/2015/5/13/302) to switch from /config/iio/triggers/hrtimer-instance1 to /config/iio/triggers/instance1. Changes since v5: (after Lars comments) * the most important change is that we moved sampling_frequency attribute from configfs to trigger's directory in /sys. * couple of const added to strings * documentation to public API in sw_trigger.h * replace pr_err with WARN_ONCE in trigger_make_group to avoid spamming kernel log, but without leaving user clueless in case of errors. * we still need to decide if we get a real gain by adding min/max limits for sampling frequency in /config dir. Anyhow, this can be done in a later patch. * fix race in hrtimer_remove Changes since v4: * patch 1/4 - fixed "new line" nit in industrialio-sw-trigger.c - added license header in sw_trigger.h o * patch 2/4 - none * patch 3/4 - none * patch 4/4 - removed "Further work" chapter in iio_configfs.txt - added configfs-iio file in Documentation/ABI/testing Daniel Baluta (5): configfs: Allow dynamic group creation iio: core: Introduce IIO configfs support iio: core: Introduce IIO software triggers iio: trigger: Introduce IIO hrtimer based trigger iio: Documentation: Add IIO configfs documentation Documentation/ABI/testing/configfs-iio | 21 Documentation/iio/iio_configfs.txt | 93 drivers/iio/Kconfig| 15 +++ drivers/iio/Makefile | 2 + drivers/iio/industrialio-configfs.c| 103 ++ drivers/iio/industrialio-sw-trigger.c | 137 +++ drivers/iio/trigger/Kconfig| 10 ++ drivers/iio/trigger/Makefile | 2 + drivers/iio/trigger/iio-trig-hrtimer.c | 193 + fs/configfs/dir.c | 50 + include/linux/configfs.h | 4 + include/linux/iio/sw_trigger.h | 120 12 files changed, 750 insertions(+) create mode 100644 Documentation/ABI/testing/configfs-iio create mode 100644 Documentation/iio/iio_configfs.txt create mode 100644 drivers/iio/industrialio-configfs.c create mode 100644 drivers/iio/industrialio-sw-trigger.c create mode 100644 drivers/iio/trigger/iio-trig-hrtimer.c create mode 100644 include/linux/iio/sw_trigger.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 4/5] iio: trigger: Introduce IIO hrtimer based trigger
This patch registers a new IIO software trigger interrupt source
based on high resolution timers.
Notice that if configfs is enabled we create sampling_frequency
attribute allowing users to change hrtimer period (1/sampling_frequency).
The IIO hrtimer trigger has a long history, this patch is based on
an older version from Marten and Lars-Peter.
Signed-off-by: Marten Svanfeldt
Signed-off-by: Lars-Peter Clausen
Signed-off-by: Daniel Baluta
---
drivers/iio/trigger/Kconfig| 10 ++
drivers/iio/trigger/Makefile | 2 +
drivers/iio/trigger/iio-trig-hrtimer.c | 193 +
3 files changed, 205 insertions(+)
create mode 100644 drivers/iio/trigger/iio-trig-hrtimer.c
diff --git a/drivers/iio/trigger/Kconfig b/drivers/iio/trigger/Kconfig
index 7999612..4505281 100644
--- a/drivers/iio/trigger/Kconfig
+++ b/drivers/iio/trigger/Kconfig
@@ -5,6 +5,16 @@
menu "Triggers - standalone"
+config IIO_HRTIMER_TRIGGER
+ tristate "High resolution timer trigger"
+ select IIO_SW_TRIGGER
+ help
+ Provides a frequency based IIO trigger using high resolution
+ timers as interrupt source.
+
+ To compile this driver as a module, choose M here: the
+ module will be called iio-trig-hrtimer.
+
config IIO_INTERRUPT_TRIGGER
tristate "Generic interrupt trigger"
help
diff --git a/drivers/iio/trigger/Makefile b/drivers/iio/trigger/Makefile
index 0694dae..fe06eb5 100644
--- a/drivers/iio/trigger/Makefile
+++ b/drivers/iio/trigger/Makefile
@@ -3,5 +3,7 @@
#
# When adding new entries keep the list in alphabetical order
+
+obj-$(CONFIG_IIO_HRTIMER_TRIGGER) += iio-trig-hrtimer.o
obj-$(CONFIG_IIO_INTERRUPT_TRIGGER) += iio-trig-interrupt.o
obj-$(CONFIG_IIO_SYSFS_TRIGGER) += iio-trig-sysfs.o
diff --git a/drivers/iio/trigger/iio-trig-hrtimer.c
b/drivers/iio/trigger/iio-trig-hrtimer.c
new file mode 100644
index 000..5e6d451
--- /dev/null
+++ b/drivers/iio/trigger/iio-trig-hrtimer.c
@@ -0,0 +1,193 @@
+/**
+ * The industrial I/O periodic hrtimer trigger driver
+ *
+ * Copyright (C) Intuitive Aerial AB
+ * Written by Marten Svanfeldt, mar...@intuitiveaerial.com
+ * Copyright (C) 2012, Analog Device Inc.
+ * Author: Lars-Peter Clausen
+ * Copyright (C) 2015, Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ */
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+/* default sampling frequency - 100Hz */
+#define HRTIMER_DEFAULT_SAMPLING_FREQUENCY 100
+
+struct iio_hrtimer_info {
+ struct iio_sw_trigger swt;
+ struct hrtimer timer;
+ unsigned long sampling_frequency;
+ ktime_t period;
+};
+
+static struct config_item_type iio_hrtimer_type = {
+ .ct_owner = THIS_MODULE,
+};
+
+static
+ssize_t iio_hrtimer_show_sampling_frequency(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct iio_trigger *trig = to_iio_trigger(dev);
+ struct iio_hrtimer_info *info = iio_trigger_get_drvdata(trig);
+
+ return snprintf(buf, PAGE_SIZE, "%lu\n", info->sampling_frequency);
+}
+
+static
+ssize_t iio_hrtimer_store_sampling_frequency(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t len)
+{
+ struct iio_trigger *trig = to_iio_trigger(dev);
+ struct iio_hrtimer_info *info = iio_trigger_get_drvdata(trig);
+ unsigned long val;
+ int ret;
+
+ ret = kstrtoul(buf, 10, &val);
+ if (ret)
+ return ret;
+
+ if (!val || val > NSEC_PER_SEC)
+ return -EINVAL;
+
+ info->sampling_frequency = val;
+ info->period = ktime_set(0, NSEC_PER_SEC / val);
+
+ return len;
+}
+
+static DEVICE_ATTR(sampling_frequency, S_IRUGO | S_IWUSR,
+ iio_hrtimer_show_sampling_frequency,
+ iio_hrtimer_store_sampling_frequency);
+
+static struct attribute *iio_hrtimer_attrs[] = {
+ &dev_attr_sampling_frequency.attr,
+ NULL
+};
+
+static const struct attribute_group iio_hrtimer_attr_group = {
+ .attrs = iio_hrtimer_attrs,
+};
+
+static const struct attribute_group *iio_hrtimer_attr_groups[] = {
+ &iio_hrtimer_attr_group,
+ NULL
+};
+
+static enum hrtimer_restart iio_hrtimer_trig_handler(struct hrtimer *timer)
+{
+ struct iio_hrtimer_info *info;
+
+ info = container_of(timer, struct iio_hrtimer_info, timer);
+
+ hrtimer_forward_now(timer, info->period);
+ iio_trigger_poll(info->swt.trigger);
+
+ return HRTIMER_RESTART;
+}
+
+static int iio_trig_hrtimer_set_state(struct iio_tr
[PATCH v8 5/5] iio: Documentation: Add IIO configfs documentation
Signed-off-by: Daniel Baluta
---
Documentation/ABI/testing/configfs-iio | 21
Documentation/iio/iio_configfs.txt | 93 ++
2 files changed, 114 insertions(+)
create mode 100644 Documentation/ABI/testing/configfs-iio
create mode 100644 Documentation/iio/iio_configfs.txt
diff --git a/Documentation/ABI/testing/configfs-iio
b/Documentation/ABI/testing/configfs-iio
new file mode 100644
index 000..2483756
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-iio
@@ -0,0 +1,21 @@
+What: /config/iio
+Date: October 2015
+KernelVersion: 4.4
+Contact: linux-...@vger.kernel.org
+Description:
+ This represents Industrial IO configuration entry point
+ directory. It contains sub-groups corresponding to IIO
+ objects.
+
+What: /config/iio/triggers
+Date: October 2015
+KernelVersion: 4.4
+Description:
+ Industrial IO software triggers directory.
+
+What: /config/iio/triggers/hrtimers
+Date: October 2015
+KernelVersion: 4.4
+Description:
+ High resolution timers directory. Creating a directory here
+ will result in creating a hrtimer trigger in the IIO subsystem.
diff --git a/Documentation/iio/iio_configfs.txt
b/Documentation/iio/iio_configfs.txt
new file mode 100644
index 000..f0add35
--- /dev/null
+++ b/Documentation/iio/iio_configfs.txt
@@ -0,0 +1,93 @@
+Industrial IIO configfs support
+
+1. Overview
+
+Configfs is a filesystem-based manager of kernel objects. IIO uses some
+objects that could be easily configured using configfs (e.g.: devices,
+triggers).
+
+See Documentation/filesystems/configfs/configfs.txt for more information
+about how configfs works.
+
+2. Usage
+
+In order to use configfs support in IIO we need to select it at compile
+time via CONFIG_IIO_CONFIGFS config option.
+
+Then, mount the configfs filesystem (usually under /config directory):
+
+$ mkdir /config
+$ mount -t configfs none /config
+
+At this point, all default IIO groups will be created and can be accessed
+under /config/iio. Next chapters will describe available IIO configuration
+objects.
+
+3. Software triggers
+
+One of the IIO default configfs groups is the "triggers" group. It is
+automagically accessible when the configfs is mounted and can be found
+under /config/iio/triggers.
+
+IIO software triggers implementation offers support for creating multiple
+trigger types. A new trigger type is usually implemented as a separate
+kernel module following the interface in include/linux/iio/sw_trigger.h:
+
+/*
+ * drivers/iio/trigger/iio-trig-sample.c
+ * sample kernel module implementing a new trigger type
+ */
+#include
+
+
+static struct iio_sw_trigger *iio_trig_sample_probe(const char *name)
+{
+ /*
+* This allocates and registers an IIO trigger plus other
+* trigger type specific initialization.
+*/
+}
+
+static int iio_trig_hrtimer_remove(struct iio_sw_trigger *swt)
+{
+ /*
+* This undoes the actions in iio_trig_sample_probe
+*/
+}
+
+static const struct iio_sw_trigger_ops iio_trig_sample_ops = {
+ .probe = iio_trig_sample_probe,
+ .remove = iio_trig_sample_remove,
+};
+
+static struct iio_sw_trigger_type iio_trig_sample = {
+ .name = "trig-sample",
+ .owner = THIS_MODULE,
+ .ops = &iio_trig_sample_ops,
+};
+
+module_iio_sw_trigger_driver(iio_trig_sample);
+
+Each trigger type has its own directory under /config/iio/triggers. Loading
+iio-trig-sample module will create 'trig-sample' trigger type directory
+/config/iio/triggers/trig-sample.
+
+We support the following interrupt sources (trigger types):
+ * hrtimer, uses high resolution timers as interrupt source
+
+3.1 Hrtimer triggers creation and destruction
+
+Loading iio-trig-hrtimer module will register hrtimer trigger types allowing
+users to create hrtimer triggers under /config/iio/triggers/hrtimer.
+
+e.g:
+
+$ mkdir /config/triggers/hrtimer/instance1
+$ rmdir /config/triggers/hrtimer/instance1
+
+Each trigger can have one or more attributes specific to the trigger type.
+
+3.2 "hrtimer" trigger types attributes
+
+"hrtimer" trigger type doesn't have any configurable attribute from /config
dir.
+It does introduce the sampling_frequency attribute to trigger directory.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v8 2/5] iio: core: Introduce IIO configfs support
This creates an IIO configfs subystem named "iio", with a default
"triggers" group. Next patches will add trigger types support,
allowing new triggers creation using configfs.
Signed-off-by: Daniel Baluta
---
drivers/iio/Kconfig | 8 +
drivers/iio/Makefile| 1 +
drivers/iio/industrialio-configfs.c | 68 +
3 files changed, 77 insertions(+)
create mode 100644 drivers/iio/industrialio-configfs.c
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 66792e7..7a4815a 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -22,6 +22,14 @@ if IIO_BUFFER
source "drivers/iio/buffer/Kconfig"
endif # IIO_BUFFER
+config IIO_CONFIGFS
+ bool "Enable IIO configuration via configfs"
+ select CONFIGFS_FS
+ help
+ This allows configuring various IIO bits through configfs
+ (e.g. software triggers). For more info see
+ Documentation/iio/iio_configfs.txt.
+
config IIO_TRIGGER
bool "Enable triggered sampling support"
help
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index aeca726..e109f95 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -5,6 +5,7 @@
obj-$(CONFIG_IIO) += industrialio.o
industrialio-y := industrialio-core.o industrialio-event.o inkern.o
industrialio-$(CONFIG_IIO_BUFFER) += industrialio-buffer.o
+industrialio-$(CONFIG_IIO_CONFIGFS) += industrialio-configfs.o
industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
diff --git a/drivers/iio/industrialio-configfs.c
b/drivers/iio/industrialio-configfs.c
new file mode 100644
index 000..211b52e
--- /dev/null
+++ b/drivers/iio/industrialio-configfs.c
@@ -0,0 +1,68 @@
+/*
+ * Industrial I/O configfs bits
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static struct config_item_type iio_triggers_group_type = {
+ .ct_owner = THIS_MODULE,
+};
+
+struct config_group iio_triggers_group = {
+ .cg_item = {
+ .ci_namebuf = "triggers",
+ .ci_type = &iio_triggers_group_type,
+ },
+};
+EXPORT_SYMBOL(iio_triggers_group);
+
+static struct config_group *iio_root_default_groups[] = {
+ &iio_triggers_group,
+ NULL
+};
+
+static struct config_item_type iio_root_group_type = {
+ .ct_owner = THIS_MODULE,
+};
+
+static struct configfs_subsystem iio_configfs_subsys = {
+ .su_group = {
+ .cg_item = {
+ .ci_namebuf = "iio",
+ .ci_type = &iio_root_group_type,
+ },
+ .default_groups = iio_root_default_groups,
+ },
+ .su_mutex = __MUTEX_INITIALIZER(iio_configfs_subsys.su_mutex),
+};
+
+static int __init iio_configfs_init(void)
+{
+ config_group_init(&iio_triggers_group);
+ config_group_init(&iio_configfs_subsys.su_group);
+
+ return configfs_register_subsystem(&iio_configfs_subsys);
+}
+module_init(iio_configfs_init);
+
+static void __exit iio_configfs_exit(void)
+{
+ configfs_unregister_subsystem(&iio_configfs_subsys);
+}
+module_exit(iio_configfs_exit);
+
+MODULE_AUTHOR("Daniel Baluta ");
+MODULE_DESCRIPTION("Industrial I/O configfs support");
+MODULE_LICENSE("GPL v2");
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v8 5/5] iio: Documentation: Add IIO configfs documentation
On Tue, Oct 20, 2015 at 2:50 PM, Crt Mori wrote:
> On 20 October 2015 at 12:53, Daniel Baluta wrote:
>> Signed-off-by: Daniel Baluta
>> ---
>> Documentation/ABI/testing/configfs-iio | 21
>> Documentation/iio/iio_configfs.txt | 93
>> ++
>> 2 files changed, 114 insertions(+)
>> create mode 100644 Documentation/ABI/testing/configfs-iio
>> create mode 100644 Documentation/iio/iio_configfs.txt
>>
>> diff --git a/Documentation/ABI/testing/configfs-iio
>> b/Documentation/ABI/testing/configfs-iio
>> new file mode 100644
>> index 000..2483756
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/configfs-iio
>> @@ -0,0 +1,21 @@
>> +What: /config/iio
>> +Date: October 2015
>> +KernelVersion: 4.4
>> +Contact: linux-...@vger.kernel.org
>> +Description:
>> + This represents Industrial IO configuration entry point
>> + directory. It contains sub-groups corresponding to IIO
>> + objects.
>> +
>> +What: /config/iio/triggers
>> +Date: October 2015
>> +KernelVersion: 4.4
>> +Description:
>> + Industrial IO software triggers directory.
>> +
>> +What: /config/iio/triggers/hrtimers
>> +Date: October 2015
>> +KernelVersion: 4.4
>> +Description:
>> + High resolution timers directory. Creating a directory here
>> + will result in creating a hrtimer trigger in the IIO
>> subsystem.
>> diff --git a/Documentation/iio/iio_configfs.txt
>> b/Documentation/iio/iio_configfs.txt
>> new file mode 100644
>> index 000..f0add35
>> --- /dev/null
>> +++ b/Documentation/iio/iio_configfs.txt
>> @@ -0,0 +1,93 @@
>> +Industrial IIO configfs support
>> +
>> +1. Overview
>> +
>> +Configfs is a filesystem-based manager of kernel objects. IIO uses some
>> +objects that could be easily configured using configfs (e.g.: devices,
>> +triggers).
>> +
>> +See Documentation/filesystems/configfs/configfs.txt for more information
>> +about how configfs works.
>> +
>> +2. Usage
>> +
>> +In order to use configfs support in IIO we need to select it at compile
>> +time via CONFIG_IIO_CONFIGFS config option.
>> +
>> +Then, mount the configfs filesystem (usually under /config directory):
>> +
>> +$ mkdir /config
>> +$ mount -t configfs none /config
>> +
>> +At this point, all default IIO groups will be created and can be accessed
>> +under /config/iio. Next chapters will describe available IIO configuration
>> +objects.
>> +
>> +3. Software triggers
>> +
>> +One of the IIO default configfs groups is the "triggers" group. It is
>> +automagically accessible when the configfs is mounted and can be found
> automagically is probably automatically?
Automagically is more fun :).
http://www.urbandictionary.com/define.php?term=automagically
>> +under /config/iio/triggers.
>> +
>> +IIO software triggers implementation offers support for creating multiple
>> +trigger types. A new trigger type is usually implemented as a separate
>> +kernel module following the interface in include/linux/iio/sw_trigger.h:
>> +
>> +/*
>> + * drivers/iio/trigger/iio-trig-sample.c
>> + * sample kernel module implementing a new trigger type
>> + */
>> +#include
>> +
>> +
>> +static struct iio_sw_trigger *iio_trig_sample_probe(const char *name)
>> +{
>> + /*
>> +* This allocates and registers an IIO trigger plus other
>> +* trigger type specific initialization.
>> +*/
>> +}
>> +
>> +static int iio_trig_hrtimer_remove(struct iio_sw_trigger *swt)
>> +{
>> + /*
>> +* This undoes the actions in iio_trig_sample_probe
>> +*/
>> +}
>> +
>> +static const struct iio_sw_trigger_ops iio_trig_sample_ops = {
>> + .probe = iio_trig_sample_probe,
>> + .remove = iio_trig_sample_remove,
>> +};
>> +
>> +static struct iio_sw_trigger_type iio_trig_sample = {
>> + .name = "trig-sample",
>> + .owner = THIS_MODULE,
>> + .ops = &iio_trig_sample_ops,
>> +};
>> +
>> +module_iio_sw_trigger_driver(iio_trig_sample);
>> +
>> +Each trigger type has its own directory under /config/iio/triggers. Loading
>> +iio-trig-sample module will create 'trig-sample' trigger type directory
>> +/co
[PATCH v9 0/5] Add initial configfs support for IIO
This patchset introduces IIO software triggers, offers a way of configuring them via configfs and adds the IIO hrtimer based interrupt source to be used with software triggers. The arhitecture is now split in 3 parts, to remove all IIO trigger specific parts from IIO configfs core: (1) IIO configfs - creates the root of the IIO configfs subsys. (2) IIO software triggers - software trigger implementation, dynamically creating /config/iio/triggers group. (3) IIO hrtimer trigger - is the first interrupt source for software triggers (with syfs to follow). Each trigger type can implement its own set of attributes. Lockdep seems to be happy with the locking in configfs patch. Changes since v8: * patch 1/5 * dynamically allocate groups as suggested by Christoph * add kernel-doc documentation to the newly introduced functions * patch 2/5 * better isolation, here we only create the root of the IIO configfs subys, and let the other modules (e.g software triggers) to create their group. * patch 3/5 * dynamically create triggers/ group to better isolate the code * fixes 0-day build warnings and compilation errors. * patch 4/5 * none * patch 5/5 * none Changes since v7: * patch 1/5 * do not add dentry parameter for create_default_group, we can retrieve it from group. * call configfs_detach_prep before configfs_detach_group in configfs_unregister_group. * call link_group/unlink_group under su_mutex lock * take configfs_dirent_lock when calling configfs_dir_set_ready * patch 2/5 * export iio_triggers_group, this will be later used by sw triggers * patch 3/5 * make iio_sw_trigger part of industrialio core * fix compilation problem reported by Vladimir and Lars. Things didn't get well when having IIO_SW_TRIGGER enabled and IIO_CONFIGFS disabled. * use format string in config_item_set_name * make iio_unregister_sw_trigger_type return type void. * patch 4/5 * none * patch 5/5 * include a small trigger type sample example. Changes since v6: * implemented Lars-Peter's idea (https://lkml.org/lkml/2015/5/13/302) to switch from /config/iio/triggers/hrtimer-instance1 to /config/iio/triggers/instance1. Changes since v5: (after Lars comments) * the most important change is that we moved sampling_frequency attribute from configfs to trigger's directory in /sys. * couple of const added to strings * documentation to public API in sw_trigger.h * replace pr_err with WARN_ONCE in trigger_make_group to avoid spamming kernel log, but without leaving user clueless in case of errors. * we still need to decide if we get a real gain by adding min/max limits for sampling frequency in /config dir. Anyhow, this can be done in a later patch. * fix race in hrtimer_remove Changes since v4: * patch 1/4 - fixed "new line" nit in industrialio-sw-trigger.c - added license header in sw_trigger.h o * patch 2/4 - none * patch 3/4 - none * patch 4/4 - removed "Further work" chapter in iio_configfs.txt - added configfs-iio file in Documentation/ABI/testing Daniel Baluta (5): configfs: Allow dynamic group creation iio: core: Introduce IIO configfs support iio: core: Introduce IIO software triggers iio: trigger: Introduce IIO hrtimer based trigger iio: Documentation: Add IIO configfs documentation Documentation/ABI/testing/configfs-iio | 21 Documentation/iio/iio_configfs.txt | 93 +++ drivers/iio/Kconfig| 16 +++ drivers/iio/Makefile | 2 + drivers/iio/industrialio-configfs.c| 50 drivers/iio/industrialio-sw-trigger.c | 206 + drivers/iio/trigger/Kconfig| 10 ++ drivers/iio/trigger/Makefile | 2 + drivers/iio/trigger/iio-trig-hrtimer.c | 193 ++ fs/configfs/dir.c | 102 include/linux/configfs.h | 8 ++ include/linux/iio/sw_trigger.h | 71 12 files changed, 774 insertions(+) create mode 100644 Documentation/ABI/testing/configfs-iio create mode 100644 Documentation/iio/iio_configfs.txt create mode 100644 drivers/iio/industrialio-configfs.c create mode 100644 drivers/iio/industrialio-sw-trigger.c create mode 100644 drivers/iio/trigger/iio-trig-hrtimer.c create mode 100644 include/linux/iio/sw_trigger.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/maj
[PATCH v9 2/5] iio: core: Introduce IIO configfs support
This patch creates the IIO configfs root group. The group
will appear under /iio/, usually /config/iio.
We introduce configfs support in IIO in order to be able to easily
create IIO objects from userspace. The first supported IIO objects
are triggers introduced with next patches.
Signed-off-by: Daniel Baluta
---
drivers/iio/Kconfig | 8 ++
drivers/iio/Makefile| 1 +
drivers/iio/industrialio-configfs.c | 50 +
3 files changed, 59 insertions(+)
create mode 100644 drivers/iio/industrialio-configfs.c
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 66792e7..d0f1ddb 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -22,6 +22,14 @@ if IIO_BUFFER
source "drivers/iio/buffer/Kconfig"
endif # IIO_BUFFER
+config IIO_CONFIGFS
+ tristate "Enable IIO configuration via configfs"
+ select CONFIGFS_FS
+ help
+ This allows configuring various IIO bits through configfs
+ (e.g. software triggers). For more info see
+ Documentation/iio/iio_configfs.txt.
+
config IIO_TRIGGER
bool "Enable triggered sampling support"
help
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index aeca726..4e8ac82 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -7,6 +7,7 @@ industrialio-y := industrialio-core.o industrialio-event.o
inkern.o
industrialio-$(CONFIG_IIO_BUFFER) += industrialio-buffer.o
industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
+obj-$(CONFIG_IIO_CONFIGFS) += industrialio-configfs.o
obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
obj-y += accel/
diff --git a/drivers/iio/industrialio-configfs.c
b/drivers/iio/industrialio-configfs.c
new file mode 100644
index 000..83563dd
--- /dev/null
+++ b/drivers/iio/industrialio-configfs.c
@@ -0,0 +1,50 @@
+/*
+ * Industrial I/O configfs bits
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static struct config_item_type iio_root_group_type = {
+ .ct_owner = THIS_MODULE,
+};
+
+struct configfs_subsystem iio_configfs_subsys = {
+ .su_group = {
+ .cg_item = {
+ .ci_namebuf = "iio",
+ .ci_type = &iio_root_group_type,
+ },
+ },
+ .su_mutex = __MUTEX_INITIALIZER(iio_configfs_subsys.su_mutex),
+};
+EXPORT_SYMBOL(iio_configfs_subsys);
+
+static int __init iio_configfs_init(void)
+{
+ config_group_init(&iio_configfs_subsys.su_group);
+
+ return configfs_register_subsystem(&iio_configfs_subsys);
+}
+module_init(iio_configfs_init);
+
+static void __exit iio_configfs_exit(void)
+{
+ configfs_unregister_subsystem(&iio_configfs_subsys);
+}
+module_exit(iio_configfs_exit);
+
+MODULE_AUTHOR("Daniel Baluta ");
+MODULE_DESCRIPTION("Industrial I/O configfs support");
+MODULE_LICENSE("GPL v2");
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 5/5] iio: Documentation: Add IIO configfs documentation
Signed-off-by: Daniel Baluta
---
Documentation/ABI/testing/configfs-iio | 21
Documentation/iio/iio_configfs.txt | 93 ++
2 files changed, 114 insertions(+)
create mode 100644 Documentation/ABI/testing/configfs-iio
create mode 100644 Documentation/iio/iio_configfs.txt
diff --git a/Documentation/ABI/testing/configfs-iio
b/Documentation/ABI/testing/configfs-iio
new file mode 100644
index 000..2483756
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-iio
@@ -0,0 +1,21 @@
+What: /config/iio
+Date: October 2015
+KernelVersion: 4.4
+Contact: linux-...@vger.kernel.org
+Description:
+ This represents Industrial IO configuration entry point
+ directory. It contains sub-groups corresponding to IIO
+ objects.
+
+What: /config/iio/triggers
+Date: October 2015
+KernelVersion: 4.4
+Description:
+ Industrial IO software triggers directory.
+
+What: /config/iio/triggers/hrtimers
+Date: October 2015
+KernelVersion: 4.4
+Description:
+ High resolution timers directory. Creating a directory here
+ will result in creating a hrtimer trigger in the IIO subsystem.
diff --git a/Documentation/iio/iio_configfs.txt
b/Documentation/iio/iio_configfs.txt
new file mode 100644
index 000..f0add35
--- /dev/null
+++ b/Documentation/iio/iio_configfs.txt
@@ -0,0 +1,93 @@
+Industrial IIO configfs support
+
+1. Overview
+
+Configfs is a filesystem-based manager of kernel objects. IIO uses some
+objects that could be easily configured using configfs (e.g.: devices,
+triggers).
+
+See Documentation/filesystems/configfs/configfs.txt for more information
+about how configfs works.
+
+2. Usage
+
+In order to use configfs support in IIO we need to select it at compile
+time via CONFIG_IIO_CONFIGFS config option.
+
+Then, mount the configfs filesystem (usually under /config directory):
+
+$ mkdir /config
+$ mount -t configfs none /config
+
+At this point, all default IIO groups will be created and can be accessed
+under /config/iio. Next chapters will describe available IIO configuration
+objects.
+
+3. Software triggers
+
+One of the IIO default configfs groups is the "triggers" group. It is
+automagically accessible when the configfs is mounted and can be found
+under /config/iio/triggers.
+
+IIO software triggers implementation offers support for creating multiple
+trigger types. A new trigger type is usually implemented as a separate
+kernel module following the interface in include/linux/iio/sw_trigger.h:
+
+/*
+ * drivers/iio/trigger/iio-trig-sample.c
+ * sample kernel module implementing a new trigger type
+ */
+#include
+
+
+static struct iio_sw_trigger *iio_trig_sample_probe(const char *name)
+{
+ /*
+* This allocates and registers an IIO trigger plus other
+* trigger type specific initialization.
+*/
+}
+
+static int iio_trig_hrtimer_remove(struct iio_sw_trigger *swt)
+{
+ /*
+* This undoes the actions in iio_trig_sample_probe
+*/
+}
+
+static const struct iio_sw_trigger_ops iio_trig_sample_ops = {
+ .probe = iio_trig_sample_probe,
+ .remove = iio_trig_sample_remove,
+};
+
+static struct iio_sw_trigger_type iio_trig_sample = {
+ .name = "trig-sample",
+ .owner = THIS_MODULE,
+ .ops = &iio_trig_sample_ops,
+};
+
+module_iio_sw_trigger_driver(iio_trig_sample);
+
+Each trigger type has its own directory under /config/iio/triggers. Loading
+iio-trig-sample module will create 'trig-sample' trigger type directory
+/config/iio/triggers/trig-sample.
+
+We support the following interrupt sources (trigger types):
+ * hrtimer, uses high resolution timers as interrupt source
+
+3.1 Hrtimer triggers creation and destruction
+
+Loading iio-trig-hrtimer module will register hrtimer trigger types allowing
+users to create hrtimer triggers under /config/iio/triggers/hrtimer.
+
+e.g:
+
+$ mkdir /config/triggers/hrtimer/instance1
+$ rmdir /config/triggers/hrtimer/instance1
+
+Each trigger can have one or more attributes specific to the trigger type.
+
+3.2 "hrtimer" trigger types attributes
+
+"hrtimer" trigger type doesn't have any configurable attribute from /config
dir.
+It does introduce the sampling_frequency attribute to trigger directory.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v9 3/5] iio: core: Introduce IIO software triggers
A software trigger associates an IIO device trigger with a software
interrupt source (e.g: timer, sysfs). This patch adds the generic
infrastructure for handling software triggers.
Software interrupts sources are kept in a iio_trigger_types_list and
registered separately when the associated kernel module is loaded.
Software triggers can be created directly from drivers or from user
space via configfs interface.
To sum up, this dynamically creates "triggers" group to be found under
/config/iio/triggers and offers the possibility of dynamically
creating trigger types group. The first support trigger type is
"hrtimer" found under /config/iio/triggers/hrtimer.
Signed-off-by: Daniel Baluta
---
drivers/iio/Kconfig | 8 ++
drivers/iio/Makefile | 1 +
drivers/iio/industrialio-sw-trigger.c | 206 ++
include/linux/iio/sw_trigger.h| 71
4 files changed, 286 insertions(+)
create mode 100644 drivers/iio/industrialio-sw-trigger.c
create mode 100644 include/linux/iio/sw_trigger.h
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index d0f1ddb..5dfb4f1 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -46,6 +46,14 @@ config IIO_CONSUMERS_PER_TRIGGER
This value controls the maximum number of consumers that a
given trigger may handle. Default is 2.
+config IIO_SW_TRIGGER
+ tristate "Enable software triggers support"
+ select IIO_CONFIGFS
+ help
+Provides IIO core support for software triggers. A software
+trigger can be created via configfs or directly by a driver
+using the API provided.
+
config IIO_TRIGGERED_EVENT
tristate
select IIO_TRIGGER
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 4e8ac82..dc73c1f 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -8,6 +8,7 @@ industrialio-$(CONFIG_IIO_BUFFER) += industrialio-buffer.o
industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
obj-$(CONFIG_IIO_CONFIGFS) += industrialio-configfs.o
+obj-$(CONFIG_IIO_SW_TRIGGER) += industrialio-sw-trigger.o
obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
obj-y += accel/
diff --git a/drivers/iio/industrialio-sw-trigger.c
b/drivers/iio/industrialio-sw-trigger.c
new file mode 100644
index 000..8911f22
--- /dev/null
+++ b/drivers/iio/industrialio-sw-trigger.c
@@ -0,0 +1,206 @@
+/*
+ * The Industrial I/O core, software trigger functions
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+static struct config_group *iio_triggers_group;
+static struct config_item_type iio_triggers_group_type = {
+ .ct_owner = THIS_MODULE,
+};
+
+static LIST_HEAD(iio_trigger_types_list);
+static DEFINE_MUTEX(iio_trigger_types_lock);
+
+static
+struct iio_sw_trigger_type *__iio_find_sw_trigger_type(const char *name,
+ unsigned len)
+{
+ struct iio_sw_trigger_type *t = NULL, *iter;
+
+ list_for_each_entry(iter, &iio_trigger_types_list, list)
+ if (!strcmp(iter->name, name)) {
+ t = iter;
+ break;
+ }
+
+ return t;
+}
+
+int iio_register_sw_trigger_type(struct iio_sw_trigger_type *t)
+{
+ struct iio_sw_trigger_type *iter;
+ int ret = 0;
+
+ mutex_lock(&iio_trigger_types_lock);
+ iter = __iio_find_sw_trigger_type(t->name, strlen(t->name));
+ if (iter)
+ ret = -EBUSY;
+ else
+ list_add_tail(&t->list, &iio_trigger_types_list);
+ mutex_unlock(&iio_trigger_types_lock);
+
+ if (!ret)
+ iio_sw_trigger_type_configfs_register(t);
+
+ return ret;
+}
+EXPORT_SYMBOL(iio_register_sw_trigger_type);
+
+void iio_unregister_sw_trigger_type(struct iio_sw_trigger_type *t)
+{
+ struct iio_sw_trigger_type *iter;
+
+ mutex_lock(&iio_trigger_types_lock);
+ iter = __iio_find_sw_trigger_type(t->name, strlen(t->name));
+ if (iter)
+ list_del(&t->list);
+ mutex_unlock(&iio_trigger_types_lock);
+
+ iio_sw_trigger_type_configfs_unregister(t);
+}
+EXPORT_SYMBOL(iio_unregister_sw_trigger_type);
+
+static
+struct iio_sw_trigger_type *iio_get_sw_trigger_type(const char *name)
+{
+ struct iio_sw_trigger_type *t;
+
+ mutex_lock(&iio_trigger_types_lock);
+ t = __iio_find_sw_trigger_type(name, strlen(name));
+ if (t && !try_module_get(t->owner))
+ t = NULL;
+ mutex_unlock(&iio_trigger_types_lock);
+
+ return t;
+}
+
+struct iio_sw_t
[PATCH v9 1/5] configfs: Allow dynamic group creation
We don't want to hardcode default groups at subsystem
creation time. We export:
* configfs_register_group
* configfs_unregister_group
to allow drivers to programatically create/destroy groups
later, after module init time.
This is needed for IIO configfs support.
Suggested-by: Lars-Peter Clausen
Signed-off-by: Daniel Baluta
---
fs/configfs/dir.c| 102 +++
include/linux/configfs.h | 8
2 files changed, 110 insertions(+)
diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
index c81ce7f..bf76795 100644
--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -1636,6 +1636,108 @@ const struct file_operations configfs_dir_operations = {
.iterate= configfs_readdir,
};
+/**
+ * configfs_alloc_group() - allocate a configfs group
+ * @name: group name
+ * @item_type: config_item associated with the allocated group
+ *
+ * Dynamically allocates and initialize a group specified by name and
+ * config_item_type. We need kzalloc'ed memory because default_group
+ * is empty.
+ *
+ * Return: allocated config group or ERR_PTR() on error
+ */
+struct config_group *
+configfs_alloc_group(const char *name, struct config_item_type *item_type)
+{
+ struct config_group *group;
+
+ group = kzalloc(sizeof(*group), GFP_KERNEL);
+ if (!group)
+ return ERR_PTR(-ENOMEM);
+ config_group_init_type_name(group, name, item_type);
+
+ return group;
+}
+EXPORT_SYMBOL(configfs_alloc_group);
+
+/**
+ * configfs_free_group() - frees memory for a configfs group
+ * @group: group to be 'eliberated'
+ */
+void configfs_free_group(struct config_group *group)
+{
+ kfree(group);
+}
+EXPORT_SYMBOL(configfs_free_group);
+
+/**
+ * configfs_register_group - creates a parent-child relation between two groups
+ * @parent_group: parent group
+ * @group: child group
+ *
+ * link groups, creates dentry for the child and attaches it to the
+ * parent dentry.
+ *
+ * Return: 0 on success, negative errno code on error
+ */
+int configfs_register_group(struct config_group *parent_group,
+ struct config_group *group)
+{
+ struct configfs_subsystem *subsys = parent_group->cg_subsys;
+ struct dentry *parent;
+ int ret;
+
+ mutex_lock(&subsys->su_mutex);
+ link_group(parent_group, group);
+ mutex_unlock(&subsys->su_mutex);
+
+ parent = parent_group->cg_item.ci_dentry;
+
+ mutex_lock_nested(&d_inode(parent)->i_mutex, I_MUTEX_PARENT);
+ ret = create_default_group(parent_group, group);
+ if (!ret) {
+ spin_lock(&configfs_dirent_lock);
+ configfs_dir_set_ready(group->cg_item.ci_dentry->d_fsdata);
+ spin_unlock(&configfs_dirent_lock);
+ }
+ mutex_unlock(&d_inode(parent)->i_mutex);
+ return ret;
+}
+EXPORT_SYMBOL(configfs_register_group);
+
+/**
+ * configfs_unregister_group() - unregisters a child group from its parent
+ *
+ * @group: parent group to be unregistered
+ *
+ * Undoes condigfs_register_group()
+ */
+void configfs_unregister_group(struct config_group *group)
+{
+ struct configfs_subsystem *subsys = group->cg_subsys;
+ struct dentry *dentry = group->cg_item.ci_dentry;
+ struct dentry *parent = group->cg_item.ci_parent->ci_dentry;
+
+ mutex_lock_nested(&d_inode(parent)->i_mutex, I_MUTEX_PARENT);
+ spin_lock(&configfs_dirent_lock);
+ configfs_detach_prep(dentry, NULL);
+ spin_unlock(&configfs_dirent_lock);
+
+ configfs_detach_group(&group->cg_item);
+ d_inode(dentry)->i_flags |= S_DEAD;
+ dont_mount(dentry);
+ d_delete(dentry);
+ mutex_unlock(&d_inode(parent)->i_mutex);
+
+ dput(dentry);
+
+ mutex_lock(&subsys->su_mutex);
+ unlink_group(group);
+ mutex_unlock(&subsys->su_mutex);
+}
+EXPORT_SYMBOL(configfs_unregister_group);
+
int configfs_register_subsystem(struct configfs_subsystem *subsys)
{
int err;
diff --git a/include/linux/configfs.h b/include/linux/configfs.h
index 63a36e8..c522a5e 100644
--- a/include/linux/configfs.h
+++ b/include/linux/configfs.h
@@ -252,6 +252,14 @@ static inline struct configfs_subsystem
*to_configfs_subsystem(struct config_gro
int configfs_register_subsystem(struct configfs_subsystem *subsys);
void configfs_unregister_subsystem(struct configfs_subsystem *subsys);
+struct config_group *
+configfs_alloc_group(const char *name, struct config_item_type *item_type);
+void configfs_free_group(struct config_group *group);
+
+int configfs_register_group(struct config_group *parent_group,
+ struct config_group *group);
+void configfs_unregister_group(struct config_group *group);
+
/* These functions can sleep and can alloc with GFP_KERNEL */
/* WARNING: These canno
[PATCH v9 4/5] iio: trigger: Introduce IIO hrtimer based trigger
This patch registers a new IIO software trigger interrupt source
based on high resolution timers.
Notice that if configfs is enabled we create sampling_frequency
attribute allowing users to change hrtimer period (1/sampling_frequency).
The IIO hrtimer trigger has a long history, this patch is based on
an older version from Marten and Lars-Peter.
Signed-off-by: Marten Svanfeldt
Signed-off-by: Lars-Peter Clausen
Signed-off-by: Daniel Baluta
---
drivers/iio/trigger/Kconfig| 10 ++
drivers/iio/trigger/Makefile | 2 +
drivers/iio/trigger/iio-trig-hrtimer.c | 193 +
3 files changed, 205 insertions(+)
create mode 100644 drivers/iio/trigger/iio-trig-hrtimer.c
diff --git a/drivers/iio/trigger/Kconfig b/drivers/iio/trigger/Kconfig
index 7999612..519e677 100644
--- a/drivers/iio/trigger/Kconfig
+++ b/drivers/iio/trigger/Kconfig
@@ -5,6 +5,16 @@
menu "Triggers - standalone"
+config IIO_HRTIMER_TRIGGER
+ tristate "High resolution timer trigger"
+ depends on IIO_SW_TRIGGER
+ help
+ Provides a frequency based IIO trigger using high resolution
+ timers as interrupt source.
+
+ To compile this driver as a module, choose M here: the
+ module will be called iio-trig-hrtimer.
+
config IIO_INTERRUPT_TRIGGER
tristate "Generic interrupt trigger"
help
diff --git a/drivers/iio/trigger/Makefile b/drivers/iio/trigger/Makefile
index 0694dae..fe06eb5 100644
--- a/drivers/iio/trigger/Makefile
+++ b/drivers/iio/trigger/Makefile
@@ -3,5 +3,7 @@
#
# When adding new entries keep the list in alphabetical order
+
+obj-$(CONFIG_IIO_HRTIMER_TRIGGER) += iio-trig-hrtimer.o
obj-$(CONFIG_IIO_INTERRUPT_TRIGGER) += iio-trig-interrupt.o
obj-$(CONFIG_IIO_SYSFS_TRIGGER) += iio-trig-sysfs.o
diff --git a/drivers/iio/trigger/iio-trig-hrtimer.c
b/drivers/iio/trigger/iio-trig-hrtimer.c
new file mode 100644
index 000..5e6d451
--- /dev/null
+++ b/drivers/iio/trigger/iio-trig-hrtimer.c
@@ -0,0 +1,193 @@
+/**
+ * The industrial I/O periodic hrtimer trigger driver
+ *
+ * Copyright (C) Intuitive Aerial AB
+ * Written by Marten Svanfeldt, mar...@intuitiveaerial.com
+ * Copyright (C) 2012, Analog Device Inc.
+ * Author: Lars-Peter Clausen
+ * Copyright (C) 2015, Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ */
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+/* default sampling frequency - 100Hz */
+#define HRTIMER_DEFAULT_SAMPLING_FREQUENCY 100
+
+struct iio_hrtimer_info {
+ struct iio_sw_trigger swt;
+ struct hrtimer timer;
+ unsigned long sampling_frequency;
+ ktime_t period;
+};
+
+static struct config_item_type iio_hrtimer_type = {
+ .ct_owner = THIS_MODULE,
+};
+
+static
+ssize_t iio_hrtimer_show_sampling_frequency(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct iio_trigger *trig = to_iio_trigger(dev);
+ struct iio_hrtimer_info *info = iio_trigger_get_drvdata(trig);
+
+ return snprintf(buf, PAGE_SIZE, "%lu\n", info->sampling_frequency);
+}
+
+static
+ssize_t iio_hrtimer_store_sampling_frequency(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t len)
+{
+ struct iio_trigger *trig = to_iio_trigger(dev);
+ struct iio_hrtimer_info *info = iio_trigger_get_drvdata(trig);
+ unsigned long val;
+ int ret;
+
+ ret = kstrtoul(buf, 10, &val);
+ if (ret)
+ return ret;
+
+ if (!val || val > NSEC_PER_SEC)
+ return -EINVAL;
+
+ info->sampling_frequency = val;
+ info->period = ktime_set(0, NSEC_PER_SEC / val);
+
+ return len;
+}
+
+static DEVICE_ATTR(sampling_frequency, S_IRUGO | S_IWUSR,
+ iio_hrtimer_show_sampling_frequency,
+ iio_hrtimer_store_sampling_frequency);
+
+static struct attribute *iio_hrtimer_attrs[] = {
+ &dev_attr_sampling_frequency.attr,
+ NULL
+};
+
+static const struct attribute_group iio_hrtimer_attr_group = {
+ .attrs = iio_hrtimer_attrs,
+};
+
+static const struct attribute_group *iio_hrtimer_attr_groups[] = {
+ &iio_hrtimer_attr_group,
+ NULL
+};
+
+static enum hrtimer_restart iio_hrtimer_trig_handler(struct hrtimer *timer)
+{
+ struct iio_hrtimer_info *info;
+
+ info = container_of(timer, struct iio_hrtimer_info, timer);
+
+ hrtimer_forward_now(timer, info->period);
+ iio_trigger_poll(info->swt.trigger);
+
+ return HRTIMER_RESTART;
+}
+
+static int iio_trig_hrtimer_set_state(struct iio_tr
Re: [PATCH v9 1/5] configfs: Allow dynamic group creation
On Fri, Oct 23, 2015 at 3:48 PM, Christoph Hellwig wrote:
> Hi Daniel,
>
> all these functions look great, but can you also move your new
> iio_sw_trigger_type_configfs_register/unregister functions to the
> core code as those are the wrappers that everyone would have to write,
> e.g. something like:
>
> int configfs_register_default_group(struct config_group *parent_group,
> const char *name, struct config_item_type *item_type)
> {
> struct config_group *group;
>
> group = kzalloc(sizeof(*group), GFP_KERNEL);
> if (!group)
> return -ENOMEM;
> config_group_init_type_name(group, name, item_type);
>
> ret = configfs_register_group(parent_group, group);
> if (ret)
> kfree(group);
> return ret;
> }
>
> and the same on the unregister side?
Yes, this is a good idea. Will do!
>
> With that:
>
> Reviewed-by: Christoph Hellwig
thanks,
Daniel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v9 1/5] configfs: Allow dynamic group creation
Christoph, one question. See below.
On Fri, Oct 23, 2015 at 3:48 PM, Christoph Hellwig wrote:
> Hi Daniel,
>
> all these functions look great, but can you also move your new
> iio_sw_trigger_type_configfs_register/unregister functions to the
> core code as those are the wrappers that everyone would have to write,
> e.g. something like:
>
> int configfs_register_default_group(struct config_group *parent_group,
> const char *name, struct config_item_type *item_type)
> {
> struct config_group *group;
>
> group = kzalloc(sizeof(*group), GFP_KERNEL);
> if (!group)
> return -ENOMEM;
> config_group_init_type_name(group, name, item_type);
Until this point this is the implementation of configfs_alloc_group.
We have two options:
1) Remove configfs_alloc_group/configfs_free_group as people will directly
use our new configfs_register_default_group that does the allocation.
2) Keep configfs_alloc/group/configfs_gree_group and use it here.
I'm in favour of 1) variant, as it makes little sense to have a wrapper over
kmalloc + config_group_init_type_name.
thanks,
Daniel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 0/5] Add initial configfs support for IIO
This patchset introduces IIO software triggers, offers a way of configuring
them via configfs and adds the IIO hrtimer based interrupt source to be used
with software triggers.
The arhitecture is now split in 3 parts, to remove all IIO trigger specific
parts from IIO configfs core:
(1) IIO configfs - creates the root of the IIO configfs subsys.
(2) IIO software triggers - software trigger implementation, dynamically
creating /config/iio/triggers group.
(3) IIO hrtimer trigger - is the first interrupt source for software triggers
(with syfs to follow). Each trigger type can implement its own set of
attributes.
Lockdep seems to be happy with the locking in configfs patch.
Changes since v9:
* introduce configfs_{un}register_default_group boilerplate code, that
does group allocation and registration
* remove configfs_alloc_group/configfs_free_group as we can directly
code them in.
Changes since v8:
* patch 1/5
* dynamically allocate groups as suggested by Christoph
* add kernel-doc documentation to the newly introduced functions
* patch 2/5
* better isolation, here we only create the root of the IIO configfs
subys, and let the other modules (e.g software triggers) to create their
group.
* patch 3/5
* dynamically create triggers/ group to better isolate the code
* fixes 0-day build warnings and compilation errors.
* patch 4/5
* none
* patch 5/5
* none
Changes since v7:
* patch 1/5
* do not add dentry parameter for create_default_group, we can
retrieve it from group.
* call configfs_detach_prep before configfs_detach_group in
configfs_unregister_group.
* call link_group/unlink_group under su_mutex lock
* take configfs_dirent_lock when calling configfs_dir_set_ready
* patch 2/5
* export iio_triggers_group, this will be later used by sw triggers
* patch 3/5
* make iio_sw_trigger part of industrialio core
* fix compilation problem reported by Vladimir and Lars. Things didn't
get well when having IIO_SW_TRIGGER enabled and IIO_CONFIGFS disabled.
* use format string in config_item_set_name
* make iio_unregister_sw_trigger_type return type void.
* patch 4/5
* none
* patch 5/5
* include a small trigger type sample example.
Changes since v6:
* implemented Lars-Peter's idea (https://lkml.org/lkml/2015/5/13/302)
to switch from /config/iio/triggers/hrtimer-instance1 to
/config/iio/triggers/instance1.
Changes since v5: (after Lars comments)
* the most important change is that we moved sampling_frequency
attribute
from configfs to trigger's directory in /sys.
* couple of const added to strings
* documentation to public API in sw_trigger.h
* replace pr_err with WARN_ONCE in trigger_make_group to avoid spamming
kernel log, but without leaving user clueless in case of errors.
* we still need to decide if we get a real gain by adding min/max limits
for sampling frequency in /config dir. Anyhow, this can be done in a
later
patch.
* fix race in hrtimer_remove
Changes since v4:
* patch 1/4
- fixed "new line" nit in industrialio-sw-trigger.c
- added license header in sw_trigger.h o
* patch 2/4
- none
* patch 3/4
- none
* patch 4/4
- removed "Further work" chapter in iio_configfs.txt
- added configfs-iio file in Documentation/ABI/testing
Daniel Baluta (5):
configfs: Allow dynamic group creation
iio: core: Introduce IIO configfs support
iio: core: Introduce IIO software triggers
iio: trigger: Introduce IIO hrtimer based trigger
iio: Documentation: Add IIO configfs documentation
Documentation/ABI/testing/configfs-iio | 21
Documentation/iio/iio_configfs.txt | 93
drivers/iio/Kconfig| 16 +++
drivers/iio/Makefile | 2 +
drivers/iio/industrialio-configfs.c| 50 +
drivers/iio/industrialio-sw-trigger.c | 183 +++
drivers/iio/trigger/Kconfig| 10 ++
drivers/iio/trigger/Makefile | 2 +
drivers/iio/trigger/iio-trig-hrtimer.c | 193 +
fs/configfs/dir.c | 110 +++
include/linux/configfs.h | 10 ++
include/linux/iio/sw_trigger.h | 71
12 files changed, 761 insertions(+)
create mode 100644 Documentation/ABI/testing/configfs-iio
create mode 100644 Documentation/iio/iio_configfs.txt
create mode 100644 drivers/iio/industrialio-configfs.c
create mode 100644 drivers/iio/industrialio-sw-trigger.c
create mode 100644 drivers/iio/trigger/iio-trig-hrtimer.c
c
[PATCH v10 2/5] iio: core: Introduce IIO configfs support
This patch creates the IIO configfs root group. The group
will appear under /iio/, usually /config/iio.
We introduce configfs support in IIO in order to be able to easily
create IIO objects from userspace. The first supported IIO objects
are triggers introduced with next patches.
Signed-off-by: Daniel Baluta
---
drivers/iio/Kconfig | 8 ++
drivers/iio/Makefile| 1 +
drivers/iio/industrialio-configfs.c | 50 +
3 files changed, 59 insertions(+)
create mode 100644 drivers/iio/industrialio-configfs.c
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 66792e7..d0f1ddb 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -22,6 +22,14 @@ if IIO_BUFFER
source "drivers/iio/buffer/Kconfig"
endif # IIO_BUFFER
+config IIO_CONFIGFS
+ tristate "Enable IIO configuration via configfs"
+ select CONFIGFS_FS
+ help
+ This allows configuring various IIO bits through configfs
+ (e.g. software triggers). For more info see
+ Documentation/iio/iio_configfs.txt.
+
config IIO_TRIGGER
bool "Enable triggered sampling support"
help
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index aeca726..4e8ac82 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -7,6 +7,7 @@ industrialio-y := industrialio-core.o industrialio-event.o
inkern.o
industrialio-$(CONFIG_IIO_BUFFER) += industrialio-buffer.o
industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
+obj-$(CONFIG_IIO_CONFIGFS) += industrialio-configfs.o
obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
obj-y += accel/
diff --git a/drivers/iio/industrialio-configfs.c
b/drivers/iio/industrialio-configfs.c
new file mode 100644
index 000..83563dd
--- /dev/null
+++ b/drivers/iio/industrialio-configfs.c
@@ -0,0 +1,50 @@
+/*
+ * Industrial I/O configfs bits
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+
+static struct config_item_type iio_root_group_type = {
+ .ct_owner = THIS_MODULE,
+};
+
+struct configfs_subsystem iio_configfs_subsys = {
+ .su_group = {
+ .cg_item = {
+ .ci_namebuf = "iio",
+ .ci_type = &iio_root_group_type,
+ },
+ },
+ .su_mutex = __MUTEX_INITIALIZER(iio_configfs_subsys.su_mutex),
+};
+EXPORT_SYMBOL(iio_configfs_subsys);
+
+static int __init iio_configfs_init(void)
+{
+ config_group_init(&iio_configfs_subsys.su_group);
+
+ return configfs_register_subsystem(&iio_configfs_subsys);
+}
+module_init(iio_configfs_init);
+
+static void __exit iio_configfs_exit(void)
+{
+ configfs_unregister_subsystem(&iio_configfs_subsys);
+}
+module_exit(iio_configfs_exit);
+
+MODULE_AUTHOR("Daniel Baluta ");
+MODULE_DESCRIPTION("Industrial I/O configfs support");
+MODULE_LICENSE("GPL v2");
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 5/5] iio: Documentation: Add IIO configfs documentation
Signed-off-by: Daniel Baluta
---
Documentation/ABI/testing/configfs-iio | 21
Documentation/iio/iio_configfs.txt | 93 ++
2 files changed, 114 insertions(+)
create mode 100644 Documentation/ABI/testing/configfs-iio
create mode 100644 Documentation/iio/iio_configfs.txt
diff --git a/Documentation/ABI/testing/configfs-iio
b/Documentation/ABI/testing/configfs-iio
new file mode 100644
index 000..2483756
--- /dev/null
+++ b/Documentation/ABI/testing/configfs-iio
@@ -0,0 +1,21 @@
+What: /config/iio
+Date: October 2015
+KernelVersion: 4.4
+Contact: linux-...@vger.kernel.org
+Description:
+ This represents Industrial IO configuration entry point
+ directory. It contains sub-groups corresponding to IIO
+ objects.
+
+What: /config/iio/triggers
+Date: October 2015
+KernelVersion: 4.4
+Description:
+ Industrial IO software triggers directory.
+
+What: /config/iio/triggers/hrtimers
+Date: October 2015
+KernelVersion: 4.4
+Description:
+ High resolution timers directory. Creating a directory here
+ will result in creating a hrtimer trigger in the IIO subsystem.
diff --git a/Documentation/iio/iio_configfs.txt
b/Documentation/iio/iio_configfs.txt
new file mode 100644
index 000..f0add35
--- /dev/null
+++ b/Documentation/iio/iio_configfs.txt
@@ -0,0 +1,93 @@
+Industrial IIO configfs support
+
+1. Overview
+
+Configfs is a filesystem-based manager of kernel objects. IIO uses some
+objects that could be easily configured using configfs (e.g.: devices,
+triggers).
+
+See Documentation/filesystems/configfs/configfs.txt for more information
+about how configfs works.
+
+2. Usage
+
+In order to use configfs support in IIO we need to select it at compile
+time via CONFIG_IIO_CONFIGFS config option.
+
+Then, mount the configfs filesystem (usually under /config directory):
+
+$ mkdir /config
+$ mount -t configfs none /config
+
+At this point, all default IIO groups will be created and can be accessed
+under /config/iio. Next chapters will describe available IIO configuration
+objects.
+
+3. Software triggers
+
+One of the IIO default configfs groups is the "triggers" group. It is
+automagically accessible when the configfs is mounted and can be found
+under /config/iio/triggers.
+
+IIO software triggers implementation offers support for creating multiple
+trigger types. A new trigger type is usually implemented as a separate
+kernel module following the interface in include/linux/iio/sw_trigger.h:
+
+/*
+ * drivers/iio/trigger/iio-trig-sample.c
+ * sample kernel module implementing a new trigger type
+ */
+#include
+
+
+static struct iio_sw_trigger *iio_trig_sample_probe(const char *name)
+{
+ /*
+* This allocates and registers an IIO trigger plus other
+* trigger type specific initialization.
+*/
+}
+
+static int iio_trig_hrtimer_remove(struct iio_sw_trigger *swt)
+{
+ /*
+* This undoes the actions in iio_trig_sample_probe
+*/
+}
+
+static const struct iio_sw_trigger_ops iio_trig_sample_ops = {
+ .probe = iio_trig_sample_probe,
+ .remove = iio_trig_sample_remove,
+};
+
+static struct iio_sw_trigger_type iio_trig_sample = {
+ .name = "trig-sample",
+ .owner = THIS_MODULE,
+ .ops = &iio_trig_sample_ops,
+};
+
+module_iio_sw_trigger_driver(iio_trig_sample);
+
+Each trigger type has its own directory under /config/iio/triggers. Loading
+iio-trig-sample module will create 'trig-sample' trigger type directory
+/config/iio/triggers/trig-sample.
+
+We support the following interrupt sources (trigger types):
+ * hrtimer, uses high resolution timers as interrupt source
+
+3.1 Hrtimer triggers creation and destruction
+
+Loading iio-trig-hrtimer module will register hrtimer trigger types allowing
+users to create hrtimer triggers under /config/iio/triggers/hrtimer.
+
+e.g:
+
+$ mkdir /config/triggers/hrtimer/instance1
+$ rmdir /config/triggers/hrtimer/instance1
+
+Each trigger can have one or more attributes specific to the trigger type.
+
+3.2 "hrtimer" trigger types attributes
+
+"hrtimer" trigger type doesn't have any configurable attribute from /config
dir.
+It does introduce the sampling_frequency attribute to trigger directory.
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v10 4/5] iio: trigger: Introduce IIO hrtimer based trigger
This patch registers a new IIO software trigger interrupt source
based on high resolution timers.
Notice that if configfs is enabled we create sampling_frequency
attribute allowing users to change hrtimer period (1/sampling_frequency).
The IIO hrtimer trigger has a long history, this patch is based on
an older version from Marten and Lars-Peter.
Signed-off-by: Marten Svanfeldt
Signed-off-by: Lars-Peter Clausen
Signed-off-by: Daniel Baluta
---
drivers/iio/trigger/Kconfig| 10 ++
drivers/iio/trigger/Makefile | 2 +
drivers/iio/trigger/iio-trig-hrtimer.c | 193 +
3 files changed, 205 insertions(+)
create mode 100644 drivers/iio/trigger/iio-trig-hrtimer.c
diff --git a/drivers/iio/trigger/Kconfig b/drivers/iio/trigger/Kconfig
index 7999612..519e677 100644
--- a/drivers/iio/trigger/Kconfig
+++ b/drivers/iio/trigger/Kconfig
@@ -5,6 +5,16 @@
menu "Triggers - standalone"
+config IIO_HRTIMER_TRIGGER
+ tristate "High resolution timer trigger"
+ depends on IIO_SW_TRIGGER
+ help
+ Provides a frequency based IIO trigger using high resolution
+ timers as interrupt source.
+
+ To compile this driver as a module, choose M here: the
+ module will be called iio-trig-hrtimer.
+
config IIO_INTERRUPT_TRIGGER
tristate "Generic interrupt trigger"
help
diff --git a/drivers/iio/trigger/Makefile b/drivers/iio/trigger/Makefile
index 0694dae..fe06eb5 100644
--- a/drivers/iio/trigger/Makefile
+++ b/drivers/iio/trigger/Makefile
@@ -3,5 +3,7 @@
#
# When adding new entries keep the list in alphabetical order
+
+obj-$(CONFIG_IIO_HRTIMER_TRIGGER) += iio-trig-hrtimer.o
obj-$(CONFIG_IIO_INTERRUPT_TRIGGER) += iio-trig-interrupt.o
obj-$(CONFIG_IIO_SYSFS_TRIGGER) += iio-trig-sysfs.o
diff --git a/drivers/iio/trigger/iio-trig-hrtimer.c
b/drivers/iio/trigger/iio-trig-hrtimer.c
new file mode 100644
index 000..5e6d451
--- /dev/null
+++ b/drivers/iio/trigger/iio-trig-hrtimer.c
@@ -0,0 +1,193 @@
+/**
+ * The industrial I/O periodic hrtimer trigger driver
+ *
+ * Copyright (C) Intuitive Aerial AB
+ * Written by Marten Svanfeldt, mar...@intuitiveaerial.com
+ * Copyright (C) 2012, Analog Device Inc.
+ * Author: Lars-Peter Clausen
+ * Copyright (C) 2015, Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ */
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+/* default sampling frequency - 100Hz */
+#define HRTIMER_DEFAULT_SAMPLING_FREQUENCY 100
+
+struct iio_hrtimer_info {
+ struct iio_sw_trigger swt;
+ struct hrtimer timer;
+ unsigned long sampling_frequency;
+ ktime_t period;
+};
+
+static struct config_item_type iio_hrtimer_type = {
+ .ct_owner = THIS_MODULE,
+};
+
+static
+ssize_t iio_hrtimer_show_sampling_frequency(struct device *dev,
+ struct device_attribute *attr,
+ char *buf)
+{
+ struct iio_trigger *trig = to_iio_trigger(dev);
+ struct iio_hrtimer_info *info = iio_trigger_get_drvdata(trig);
+
+ return snprintf(buf, PAGE_SIZE, "%lu\n", info->sampling_frequency);
+}
+
+static
+ssize_t iio_hrtimer_store_sampling_frequency(struct device *dev,
+struct device_attribute *attr,
+const char *buf, size_t len)
+{
+ struct iio_trigger *trig = to_iio_trigger(dev);
+ struct iio_hrtimer_info *info = iio_trigger_get_drvdata(trig);
+ unsigned long val;
+ int ret;
+
+ ret = kstrtoul(buf, 10, &val);
+ if (ret)
+ return ret;
+
+ if (!val || val > NSEC_PER_SEC)
+ return -EINVAL;
+
+ info->sampling_frequency = val;
+ info->period = ktime_set(0, NSEC_PER_SEC / val);
+
+ return len;
+}
+
+static DEVICE_ATTR(sampling_frequency, S_IRUGO | S_IWUSR,
+ iio_hrtimer_show_sampling_frequency,
+ iio_hrtimer_store_sampling_frequency);
+
+static struct attribute *iio_hrtimer_attrs[] = {
+ &dev_attr_sampling_frequency.attr,
+ NULL
+};
+
+static const struct attribute_group iio_hrtimer_attr_group = {
+ .attrs = iio_hrtimer_attrs,
+};
+
+static const struct attribute_group *iio_hrtimer_attr_groups[] = {
+ &iio_hrtimer_attr_group,
+ NULL
+};
+
+static enum hrtimer_restart iio_hrtimer_trig_handler(struct hrtimer *timer)
+{
+ struct iio_hrtimer_info *info;
+
+ info = container_of(timer, struct iio_hrtimer_info, timer);
+
+ hrtimer_forward_now(timer, info->period);
+ iio_trigger_poll(info->swt.trigger);
+
+ return HRTIMER_RESTART;
+}
+
+static int iio_trig_hrtimer_set_state(struct iio_tr
[PATCH v10 1/5] configfs: Allow dynamic group creation
We don't want to hardcode default groups at subsystem
creation time. We export:
* configfs_register_group
* configfs_unregister_group
to allow drivers to programatically create/destroy groups
later, after module init time.
This is needed for IIO configfs support.
Suggested-by: Lars-Peter Clausen
Signed-off-by: Daniel Baluta
---
fs/configfs/dir.c| 110 +++
include/linux/configfs.h | 10 +
2 files changed, 120 insertions(+)
diff --git a/fs/configfs/dir.c b/fs/configfs/dir.c
index c81ce7f..a7a1b21 100644
--- a/fs/configfs/dir.c
+++ b/fs/configfs/dir.c
@@ -1636,6 +1636,116 @@ const struct file_operations configfs_dir_operations = {
.iterate= configfs_readdir,
};
+/**
+ * configfs_register_group - creates a parent-child relation between two groups
+ * @parent_group: parent group
+ * @group: child group
+ *
+ * link groups, creates dentry for the child and attaches it to the
+ * parent dentry.
+ *
+ * Return: 0 on success, negative errno code on error
+ */
+int configfs_register_group(struct config_group *parent_group,
+ struct config_group *group)
+{
+ struct configfs_subsystem *subsys = parent_group->cg_subsys;
+ struct dentry *parent;
+ int ret;
+
+ mutex_lock(&subsys->su_mutex);
+ link_group(parent_group, group);
+ mutex_unlock(&subsys->su_mutex);
+
+ parent = parent_group->cg_item.ci_dentry;
+
+ mutex_lock_nested(&d_inode(parent)->i_mutex, I_MUTEX_PARENT);
+ ret = create_default_group(parent_group, group);
+ if (!ret) {
+ spin_lock(&configfs_dirent_lock);
+ configfs_dir_set_ready(group->cg_item.ci_dentry->d_fsdata);
+ spin_unlock(&configfs_dirent_lock);
+ }
+ mutex_unlock(&d_inode(parent)->i_mutex);
+ return ret;
+}
+EXPORT_SYMBOL(configfs_register_group);
+
+/**
+ * configfs_unregister_group() - unregisters a child group from its parent
+ * @group: parent group to be unregistered
+ *
+ * Undoes configfs_register_group()
+ */
+void configfs_unregister_group(struct config_group *group)
+{
+ struct configfs_subsystem *subsys = group->cg_subsys;
+ struct dentry *dentry = group->cg_item.ci_dentry;
+ struct dentry *parent = group->cg_item.ci_parent->ci_dentry;
+
+ mutex_lock_nested(&d_inode(parent)->i_mutex, I_MUTEX_PARENT);
+ spin_lock(&configfs_dirent_lock);
+ configfs_detach_prep(dentry, NULL);
+ spin_unlock(&configfs_dirent_lock);
+
+ configfs_detach_group(&group->cg_item);
+ d_inode(dentry)->i_flags |= S_DEAD;
+ dont_mount(dentry);
+ d_delete(dentry);
+ mutex_unlock(&d_inode(parent)->i_mutex);
+
+ dput(dentry);
+
+ mutex_lock(&subsys->su_mutex);
+ unlink_group(group);
+ mutex_unlock(&subsys->su_mutex);
+}
+EXPORT_SYMBOL(configfs_unregister_group);
+
+/**
+ * configfs_register_default_group() - allocates and registers a child group
+ * @parent_group: parent group
+ * @name: child group name
+ * @item_type: child item type description
+ *
+ * boilerplate to allocate and register a child group with its parent. We need
+ * kzalloc'ed memory because child's default_group is initially empty.
+ *
+ * Return: allocated config group or ERR_PTR() on error
+ */
+struct config_group *
+configfs_register_default_group(struct config_group *parent_group,
+ const char *name,
+ struct config_item_type *item_type)
+{
+ int ret;
+ struct config_group *group;
+
+ group = kzalloc(sizeof(*group), GFP_KERNEL);
+ if (!group)
+ return ERR_PTR(-ENOMEM);
+ config_group_init_type_name(group, name, item_type);
+
+ ret = configfs_register_group(parent_group, group);
+ if (ret) {
+ kfree(group);
+ return ERR_PTR(ret);
+ }
+ return group;
+}
+EXPORT_SYMBOL(configfs_register_default_group);
+
+/**
+ * configfs_unregister_default_group() - unregisters and frees a child group
+ * @group: the group to act on
+ */
+void configfs_unregister_default_group(struct config_group *group)
+{
+ configfs_unregister_group(group);
+ kfree(group);
+}
+EXPORT_SYMBOL(configfs_unregister_default_group);
+
int configfs_register_subsystem(struct configfs_subsystem *subsys)
{
int err;
diff --git a/include/linux/configfs.h b/include/linux/configfs.h
index 63a36e8..931ca25 100644
--- a/include/linux/configfs.h
+++ b/include/linux/configfs.h
@@ -252,6 +252,16 @@ static inline struct configfs_subsystem
*to_configfs_subsystem(struct config_gro
int configfs_register_subsystem(struct configfs_subsystem *subsys);
void configfs_unregister_subsystem(struct configfs_subsystem *subsys);
+int
[PATCH v10 3/5] iio: core: Introduce IIO software triggers
A software trigger associates an IIO device trigger with a software
interrupt source (e.g: timer, sysfs). This patch adds the generic
infrastructure for handling software triggers.
Software interrupts sources are kept in a iio_trigger_types_list and
registered separately when the associated kernel module is loaded.
Software triggers can be created directly from drivers or from user
space via configfs interface.
To sum up, this dynamically creates "triggers" group to be found under
/config/iio/triggers and offers the possibility of dynamically
creating trigger types groups. The first supported trigger type is
"hrtimer" found under /config/iio/triggers/hrtimer.
Signed-off-by: Daniel Baluta
---
drivers/iio/Kconfig | 8 ++
drivers/iio/Makefile | 1 +
drivers/iio/industrialio-sw-trigger.c | 183 ++
include/linux/iio/sw_trigger.h| 71 +
4 files changed, 263 insertions(+)
create mode 100644 drivers/iio/industrialio-sw-trigger.c
create mode 100644 include/linux/iio/sw_trigger.h
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index d0f1ddb..5dfb4f1 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -46,6 +46,14 @@ config IIO_CONSUMERS_PER_TRIGGER
This value controls the maximum number of consumers that a
given trigger may handle. Default is 2.
+config IIO_SW_TRIGGER
+ tristate "Enable software triggers support"
+ select IIO_CONFIGFS
+ help
+Provides IIO core support for software triggers. A software
+trigger can be created via configfs or directly by a driver
+using the API provided.
+
config IIO_TRIGGERED_EVENT
tristate
select IIO_TRIGGER
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 4e8ac82..dc73c1f 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -8,6 +8,7 @@ industrialio-$(CONFIG_IIO_BUFFER) += industrialio-buffer.o
industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
obj-$(CONFIG_IIO_CONFIGFS) += industrialio-configfs.o
+obj-$(CONFIG_IIO_SW_TRIGGER) += industrialio-sw-trigger.o
obj-$(CONFIG_IIO_TRIGGERED_EVENT) += industrialio-triggered-event.o
obj-y += accel/
diff --git a/drivers/iio/industrialio-sw-trigger.c
b/drivers/iio/industrialio-sw-trigger.c
new file mode 100644
index 000..4825cfd
--- /dev/null
+++ b/drivers/iio/industrialio-sw-trigger.c
@@ -0,0 +1,183 @@
+/*
+ * The Industrial I/O core, software trigger functions
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+static struct config_group *iio_triggers_group;
+static struct config_item_type iio_trigger_type_group_type;
+
+static struct config_item_type iio_triggers_group_type = {
+ .ct_owner = THIS_MODULE,
+};
+
+static LIST_HEAD(iio_trigger_types_list);
+static DEFINE_MUTEX(iio_trigger_types_lock);
+
+static
+struct iio_sw_trigger_type *__iio_find_sw_trigger_type(const char *name,
+ unsigned len)
+{
+ struct iio_sw_trigger_type *t = NULL, *iter;
+
+ list_for_each_entry(iter, &iio_trigger_types_list, list)
+ if (!strcmp(iter->name, name)) {
+ t = iter;
+ break;
+ }
+
+ return t;
+}
+
+int iio_register_sw_trigger_type(struct iio_sw_trigger_type *t)
+{
+ struct iio_sw_trigger_type *iter;
+ int ret = 0;
+
+ mutex_lock(&iio_trigger_types_lock);
+ iter = __iio_find_sw_trigger_type(t->name, strlen(t->name));
+ if (iter)
+ ret = -EBUSY;
+ else
+ list_add_tail(&t->list, &iio_trigger_types_list);
+ mutex_unlock(&iio_trigger_types_lock);
+
+ if (ret)
+ return ret;
+
+ t->group = configfs_register_default_group(iio_triggers_group, t->name,
+ &iio_trigger_type_group_type);
+ if (IS_ERR(t->group))
+ ret = PTR_ERR(t->group);
+
+ return ret;
+}
+EXPORT_SYMBOL(iio_register_sw_trigger_type);
+
+void iio_unregister_sw_trigger_type(struct iio_sw_trigger_type *t)
+{
+ struct iio_sw_trigger_type *iter;
+
+ mutex_lock(&iio_trigger_types_lock);
+ iter = __iio_find_sw_trigger_type(t->name, strlen(t->name));
+ if (iter)
+ list_del(&t->list);
+ mutex_unlock(&iio_trigger_types_lock);
+
+ configfs_unregister_default_group(t->group);
+}
+EXPORT_SYMBOL(iio_unregister_sw_trigger_type);
+
+static
+struct iio_sw_trigger_type *iio_get_sw_trigger_type(const char *name)
+{
+ struct iio_sw_trigger_type
Re: [PATCH v4] iio: chemical: Add support for Bosch BME680 sensor
On Sat, Jul 21, 2018 at 6:43 PM, Andy Shevchenko
wrote:
> On Sat, Jul 21, 2018 at 6:36 PM, Himanshu Jha
> wrote:
>
>>> > + /* Look up table 1 for the possible gas range values */
>>> > + u32 lookupTable1[16] = {2147483647u, 2147483647u, 2147483647u,
>>> > + 2147483647u, 2147483647u, 2126008810u,
>>> > + 2147483647u, 2130303777u, 2147483647u,
>>> > + 2147483647u, 2143188679u, 2136746228u,
>>> > + 2147483647u, 2126008810u, 2147483647u,
>>> > + 2147483647u};
>
> This one needs perhaps a bit of though, but...
>
>>> > + /* Look up table 2 for the possible gas range values */
>>> > + u32 lookupTable2[16] = {409600u, 204800u, 102400u,
>>> > + 51200u, 255744255u, 127110228u, 6400u,
>>> > + 32258064u, 16016016u, 800u, 400u,
>>> > + 200u, 100u, 50u, 25u,
>>> > 125000u};
>
> ...this one obviously just a not needed one. You may replace it with a
> one constant and simple calculation to get either value (index from
> value, or value from index).
Indeed this can be reduce to:
125.000 << (15 - idx).
The real question here is if we approximate 255.744.255u to 256.00.00u how
much different is the result. Being a gas sensor I think it is very
hard to appreciate.
We can go with this formula + adding a comment with the table with the
exact coefficients.
thanks,
Daniel.
[PATCH] ASoC: codecs: Add support for AK5558 ADC driver
AK5558 is a 32-bit, 768 kHZ sampling, differential input ADC
for digital audio systems.
Datasheet is available at:
https://www.akm.com/akm/en/file/datasheet/AK5558VN.pdf
Initial patch includes support for normal and TDM modes.
Signed-off-by: Junichi Wakasugi
Signed-off-by: Mihai Serban
Signed-off-by: Shengjiu Wang
Signed-off-by: Daniel Baluta
---
Documentation/devicetree/bindings/sound/ak5558.txt | 20 +
sound/soc/codecs/Kconfig | 6 +
sound/soc/codecs/Makefile | 2 +
sound/soc/codecs/ak5558.c | 754 +
sound/soc/codecs/ak5558.h | 60 ++
5 files changed, 842 insertions(+)
create mode 100644 Documentation/devicetree/bindings/sound/ak5558.txt
create mode 100644 sound/soc/codecs/ak5558.c
create mode 100644 sound/soc/codecs/ak5558.h
diff --git a/Documentation/devicetree/bindings/sound/ak5558.txt
b/Documentation/devicetree/bindings/sound/ak5558.txt
new file mode 100644
index 000..c6c71af
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/ak5558.txt
@@ -0,0 +1,20 @@
+AK5558 8 channel differential 32-bit delta-sigma ADC
+
+This device supports I2C mode only.
+
+Required properties:
+
+- compatible : "asahi-kasei,ak5558"
+- reg : The I2C address of the device for I2C.
+- asahi-kasei,pdn-gpios: A GPIO specifier for the GPIO controlling
+ the power down & reset pin.
+
+Example:
+
+&i2c {
+ ak5558: ak5558@10 {
+ compatible = "asahi-kasei,ak5558";
+ reg = <0x10>;
+ asahi-kasei,pdn-gpios = <&gpio1 10 GPIO_ACTIVE_HIGH>;
+ };
+};
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index c367d11..84a15d4 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -42,6 +42,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_AK4642 if I2C
select SND_SOC_AK4671 if I2C
select SND_SOC_AK5386
+ select SND_SOC_AK5558 if I2C
select SND_SOC_ALC5623 if I2C
select SND_SOC_ALC5632 if I2C
select SND_SOC_BT_SCO
@@ -394,6 +395,11 @@ config SND_SOC_AK4671
config SND_SOC_AK5386
tristate "AKM AK5638 CODEC"
+config SND_SOC_AK5558
+ tristate "AKM AK5558 CODEC"
+ depends on I2C
+ select REGMAP_I2C
+
config SND_SOC_ALC5623
tristate "Realtek ALC5623 CODEC"
depends on I2C
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 77c1818..3a3d8b1 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -33,6 +33,7 @@ snd-soc-ak4641-objs := ak4641.o
snd-soc-ak4642-objs := ak4642.o
snd-soc-ak4671-objs := ak4671.o
snd-soc-ak5386-objs := ak5386.o
+snd-soc-ak5558-objs := ak5558.o
snd-soc-arizona-objs := arizona.o
snd-soc-bt-sco-objs := bt-sco.o
snd-soc-cq93vc-objs := cq93vc.o
@@ -271,6 +272,7 @@ obj-$(CONFIG_SND_SOC_AK4641)+= snd-soc-ak4641.o
obj-$(CONFIG_SND_SOC_AK4642) += snd-soc-ak4642.o
obj-$(CONFIG_SND_SOC_AK4671) += snd-soc-ak4671.o
obj-$(CONFIG_SND_SOC_AK5386) += snd-soc-ak5386.o
+obj-$(CONFIG_SND_SOC_AK5558) += snd-soc-ak5558.o
obj-$(CONFIG_SND_SOC_ALC5623)+= snd-soc-alc5623.o
obj-$(CONFIG_SND_SOC_ALC5632) += snd-soc-alc5632.o
obj-$(CONFIG_SND_SOC_ARIZONA) += snd-soc-arizona.o
diff --git a/sound/soc/codecs/ak5558.c b/sound/soc/codecs/ak5558.c
new file mode 100644
index 000..eeaeea9
--- /dev/null
+++ b/sound/soc/codecs/ak5558.c
@@ -0,0 +1,754 @@
+/*
+ * ak5558.c -- audio driver for AK5558 ADC
+ *
+ * Copyright (C) 2015 Asahi Kasei Microdevices Corporation
+ * Copyright 2018 NXP
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "ak5558.h"
+
+#define AK5558_SLAVE_CKS_AUTO
+
+/* AK5558 Codec Private Data */
+struct ak5558_priv {
+ struct snd_soc_codec codec;
+ struct regmap *regmap;
+ struct i2c_client *i2c;
+ int fs; /* Sampling Frequency */
+ int rclk; /* Master Clock */
+ int pdn_gpio; /* Power on / Reset GPIO */
+ int slots;
+ int slot_width;
+};
+
+/* ak5558 register cache & default register settings */
+static const struct reg_default ak5558_reg[] = {
+ { 0x0, 0xFF }, /* 0x00AK5558_00_POWER_MANAGEMENT1 */
+ { 0x1, 0x01 }, /* 0x01AK5558_01_POWER_MANAGEMENT2 */
+
Re: [PATCH] ASoC: codecs: Add support for AK5558 ADC driver
Hi Fabio, Andy,
Thanks a lot for your comments. I will address them and send v2.
Few comments inline.
On Mi, 2018-01-31 at 18:12 +0200, Andy Shevchenko wrote:
> On Wed, Jan 31, 2018 at 2:57 PM, Daniel Baluta wrote:
> >
> > AK5558 is a 32-bit, 768 kHZ sampling, differential input ADC
> > for digital audio systems.
> >
> > Signed-off-by: Junichi Wakasugi
> > Signed-off-by: Mihai Serban
> > Signed-off-by: Shengjiu Wang
> > Signed-off-by: Daniel Baluta
> 4 authors of the code?!
The code has a very long history. I will add under each SoB the specific
contribution.
Mihai got the code from Junichi and reworked it for 4.9. Then Shengjiu and
me added various features and cleanups.
According to DCO [1] all SoB are valid and required.
> > +MODULE_AUTHOR("Junichi Wakasugi ");
> > +MODULE_AUTHOR("Mihai Serban ");
> 4 SoBs, 2 Authors. Please, fix accordingly.
Here I would prefer to list Junichi and Mihai because they were the main
contributors.
Any other suggestion?
thanks,
Daniel.
[1] [1] https://developercertificate.org/
Re: [alsa-devel] [PATCH v3 1/5] ALSA: soc-compress: add support to snd_compr_set_runtime_buffer()
Hi Srinivas, One minor comment: > struct snd_compr_ops *ops; > + struct snd_dma_buffer *dma_buffer_p; I don't think it is necessary to encode the type inside the name variable So, dma_buffer would sounds better to me then dma_buffer_p; > void *buffer; It is also consistent with this ^ > +static inline void snd_compr_set_runtime_buffer( > + struct snd_compr_stream *substream, > + struct snd_dma_buffer *bufp) Also buf instead of bufp here. thanks, Daniel.
Re: [PATCH] clk: imx: Make the i.MX8MQ CCM clock driver CLK_IMX8MQ dependant
> --- a/drivers/clk/imx/Makefile > +++ b/drivers/clk/imx/Makefile > @@ -34,5 +34,6 @@ obj-$(CONFIG_SOC_IMX6SX) += clk-imx6sx.o > obj-$(CONFIG_SOC_IMX6UL) += clk-imx6ul.o > obj-$(CONFIG_SOC_IMX7D) += clk-imx7d.o > obj-$(CONFIG_SOC_IMX7ULP) += clk-imx7ulp.o > -obj-$(CONFIG_SOC_IMX8MQ) += clk-imx8mq.o > obj-$(CONFIG_SOC_VF610) += clk-vf610.o > + > +obj-$(CONFIG_CLK_IMX8MQ) += clk-imx8mq.o Nit: Do we want to keep CONFIG_ sorted?
Re: [REGRESSION] imx_v6_v7_defconfig: undefined reference to `__hyp_stub_vectors'
On Wed, 2018-12-19 at 12:42 +, Marcel Ziswiler wrote: > Hi there > > I noticed that at least today's and yesterdays -next won't build with > the imx_v6_v7_defconfig giving the following error: > > LD arch/arm/boot/compressed/vmlinux > arch/arm/boot/compressed/head.o: In function `restart': > (.text+0xa8): undefined reference to `__hyp_stub_vectors' > (.text+0xac): undefined reference to `__hyp_stub_vectors' > > Has anybody seen that as well and knows what is going on? Hmm, works for me. Using linux-next, master branch. HEAD commit: commit 02fc169594e96f7c51c4f23114e12b7a18e85a0a (HEAD -> master, tag: next-20181219, origin/master, origin/HEAD) Author: Stephen Rothwell Date: Wed Dec 19 18:42:46 2018 +1100 Add linux-next specific files for 20181219 Signed-off-by: Stephen Rothwell Using gcc version 7.3.0 (GCC).
Re: [REGRESSION] imx_v6_v7_defconfig: undefined reference to `__hyp_stub_vectors'
On Wed, Dec 19, 2018 at 3:17 PM Daniel Baluta wrote: > > > On Wed, 2018-12-19 at 12:42 +, Marcel Ziswiler wrote: > > Hi there > > > > I noticed that at least today's and yesterdays -next won't build with > > the imx_v6_v7_defconfig giving the following error: > > > > LD arch/arm/boot/compressed/vmlinux > > arch/arm/boot/compressed/head.o: In function `restart': > > (.text+0xa8): undefined reference to `__hyp_stub_vectors' > > (.text+0xac): undefined reference to `__hyp_stub_vectors' > > > > Has anybody seen that as well and knows what is going on? > > Hmm, works for me. > > Using linux-next, master branch. HEAD commit: > > commit 02fc169594e96f7c51c4f23114e12b7a18e85a0a (HEAD -> master, tag: > next-20181219, origin/master, origin/HEAD) > Author: Stephen Rothwell > Date: Wed Dec 19 18:42:46 2018 +1100 > > Add linux-next specific files for 20181219 > > Signed-off-by: Stephen Rothwell > > > Using gcc version 7.3.0 (GCC). On the other hand I'm getting this warning: arch/arm/boot/dts/vfxxx.dtsi:550.24-563.6: Warning (spi_bus_bridge): /soc/aips-bus@4008/spi@400ad000: incorrect #address-cells for SPI bus also defined at arch/arm/boot/dts/vf610-bk4.dts:107.8-119.3 arch/arm/boot/dts/vf610-bk4.dtb: Warning (spi_bus_reg): Failed prerequisite 'spi_bus_bridge' Maybe Rob can jump in? thanks, Daniel.
Re: [PATCH] clk: imx: Make the i.MX8MQ CCM clock driver CLK_IMX8MQ dependant
On Fri, Dec 14, 2018 at 3:02 AM Shawn Guo wrote: > > On Thu, Dec 13, 2018 at 04:51:18PM +, Aisheng Dong wrote: > > [...] > > > > > > --- a/drivers/clk/imx/Makefile > > > > +++ b/drivers/clk/imx/Makefile > > > > @@ -34,5 +34,6 @@ obj-$(CONFIG_SOC_IMX6SX) += clk-imx6sx.o > > > > obj-$(CONFIG_SOC_IMX6UL) += clk-imx6ul.o > > > > obj-$(CONFIG_SOC_IMX7D) += clk-imx7d.o > > > > obj-$(CONFIG_SOC_IMX7ULP) += clk-imx7ulp.o > > > > -obj-$(CONFIG_SOC_IMX8MQ) += clk-imx8mq.o > > > > obj-$(CONFIG_SOC_VF610) += clk-vf610.o > > > > + > > > > +obj-$(CONFIG_CLK_IMX8MQ) += clk-imx8mq.o > > > > > > Nit: Do we want to keep CONFIG_ sorted? > > > > IMHO It might be okay to make MX8 (ARM64) a new group to start > > To get a clear separation. (Slightly not sorted due to VF610) > > Anyway, it leaves to Stephen to make the judge. > > I think Daniel is suggesting that we put CONFIG_CLK_IMX8MQ prior to > CONFIG_SOC_IMX1, so that all CONFIG_CLK_xxx options go before > CONFIG_SOC_xxx and the list is still naturally alphabetically sorted. Yes, that's correct.
[PATCH 2/2] ASoC: dt-bindings: Document support for ak4497
ak4458 driver supports also ak4497 codec. Signed-off-by: Daniel Baluta --- Documentation/devicetree/bindings/sound/ak4458.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/sound/ak4458.txt b/Documentation/devicetree/bindings/sound/ak4458.txt index 7839be78448d..e5820235e0d5 100644 --- a/Documentation/devicetree/bindings/sound/ak4458.txt +++ b/Documentation/devicetree/bindings/sound/ak4458.txt @@ -4,7 +4,7 @@ This device supports I2C mode. Required properties: -- compatible : "asahi-kasei,ak4458" +- compatible : "asahi-kasei,ak4458" or "asahi-kasei,ak4497" - reg : The I2C address of the device for I2C Optional properties: -- 2.17.1
[PATCH 0/2] Add support for AK4497 codec
AK4497 is almost register compatible with AK4458. Almost means that AK4497 has an extra "debug" register that we currently do not use. Daniel Baluta (2): ASoC: ak4458: Add support for AK4497 ASoC: dt-bindings: Document support for ak4497 .../devicetree/bindings/sound/ak4458.txt | 2 +- sound/soc/codecs/ak4458.c | 79 ++- 2 files changed, 77 insertions(+), 4 deletions(-) -- 2.17.1
[PATCH 1/2] ASoC: ak4458: Add support for AK4497
AK4497 is a 32-bit 2ch DAC and has the same register
map as AK4458 with few exceptions:
* AK4497 has one more register at the end of register space
DFS_READ which is a read only register that allows users
to read FS Auto Detection mode. We currently do not use
this register so we use the same regmap structure as for ak4458.
* Because AK4458 is an 8ch DAC there are some fields that are
only used by AK4458 and marked as reserved for AK4497, so for
this reason we need to have a distinct set of controls, widgets
and routes.
Datasheet for AK4497 is at:
https://www.akm.com/akm/en/file/ev-board-manual/AK4497EQ.pdf
Datasheet for AK4458 is at:
https://www.akm.com/akm/en/file/datasheet/AK4458VN.pdf
Signed-off-by: Daniel Baluta
---
sound/soc/codecs/ak4458.c | 79 +--
1 file changed, 76 insertions(+), 3 deletions(-)
diff --git a/sound/soc/codecs/ak4458.c b/sound/soc/codecs/ak4458.c
index 70d4c89bd6fc..eab7c76cfcd9 100644
--- a/sound/soc/codecs/ak4458.c
+++ b/sound/soc/codecs/ak4458.c
@@ -21,6 +21,11 @@
#include "ak4458.h"
+struct ak4458_drvdata {
+ struct snd_soc_dai_driver *dai_drv;
+ const struct snd_soc_component_driver *comp_drv;
+};
+
/* AK4458 Codec Private Data */
struct ak4458_priv {
struct device *dev;
@@ -258,6 +263,33 @@ static const struct snd_soc_dapm_route ak4458_intercon[] =
{
{"AK4458 AOUTD",NULL, "AK4458 DAC4"},
};
+/* ak4497 controls */
+static const struct snd_kcontrol_new ak4497_snd_controls[] = {
+ SOC_DOUBLE_R_TLV("DAC Playback Volume", AK4458_03_LCHATT,
+AK4458_04_RCHATT, 0, 0xFF, 0, dac_tlv),
+ SOC_ENUM("AK4497 De-emphasis Response DAC", ak4458_dac1_dem_enum),
+ SOC_ENUM_EXT("AK4497 Digital Filter Setting", ak4458_digfil_enum,
+get_digfil, set_digfil),
+ SOC_ENUM("AK4497 Inverting Enable of DZFB", ak4458_dzfb_enum),
+ SOC_ENUM("AK4497 Sound Mode", ak4458_sm_enum),
+ SOC_ENUM("AK4497 Attenuation transition Time Setting",
+ak4458_ats_enum),
+};
+
+/* ak4497 dapm widgets */
+static const struct snd_soc_dapm_widget ak4497_dapm_widgets[] = {
+ SND_SOC_DAPM_DAC("AK4497 DAC", NULL, AK4458_0A_CONTROL6, 2, 0),
+ SND_SOC_DAPM_AIF_IN("AK4497 SDTI", "Playback", 0, SND_SOC_NOPM, 0, 0),
+ SND_SOC_DAPM_OUTPUT("AK4497 AOUT"),
+};
+
+/* ak4497 dapm routes */
+static const struct snd_soc_dapm_route ak4497_intercon[] = {
+ {"AK4497 DAC", NULL, "AK4497 SDTI"},
+ {"AK4497 AOUT", NULL, "AK4497 DAC"},
+
+};
+
static int ak4458_rstn_control(struct snd_soc_component *component, int bit)
{
int ret;
@@ -476,6 +508,18 @@ static struct snd_soc_dai_driver ak4458_dai = {
.ops = &ak4458_dai_ops,
};
+static struct snd_soc_dai_driver ak4497_dai = {
+ .name = "ak4497-aif",
+ .playback = {
+ .stream_name = "Playback",
+ .channels_min = 1,
+ .channels_max = 2,
+ .rates = SNDRV_PCM_RATE_KNOT,
+ .formats = AK4458_FORMATS,
+ },
+ .ops = &ak4458_dai_ops,
+};
+
static void ak4458_power_off(struct ak4458_priv *ak4458)
{
if (ak4458->reset_gpiod) {
@@ -573,6 +617,21 @@ static const struct snd_soc_component_driver
soc_codec_dev_ak4458 = {
.non_legacy_dai_naming = 1,
};
+static const struct snd_soc_component_driver soc_codec_dev_ak4497 = {
+ .probe = ak4458_probe,
+ .remove = ak4458_remove,
+ .controls = ak4497_snd_controls,
+ .num_controls = ARRAY_SIZE(ak4497_snd_controls),
+ .dapm_widgets = ak4497_dapm_widgets,
+ .num_dapm_widgets = ARRAY_SIZE(ak4497_dapm_widgets),
+ .dapm_routes= ak4497_intercon,
+ .num_dapm_routes= ARRAY_SIZE(ak4497_intercon),
+ .idle_bias_on = 1,
+ .use_pmdown_time= 1,
+ .endianness = 1,
+ .non_legacy_dai_naming = 1,
+};
+
static const struct regmap_config ak4458_regmap = {
.reg_bits = 8,
.val_bits = 8,
@@ -583,6 +642,16 @@ static const struct regmap_config ak4458_regmap = {
.cache_type = REGCACHE_RBTREE,
};
+static const struct ak4458_drvdata ak4458_drvdata = {
+ .dai_drv = &ak4458_dai,
+ .comp_drv = &soc_codec_dev_ak4458,
+};
+
+static const struct ak4458_drvdata ak4497_drvdata = {
+ .dai_drv = &ak4497_dai,
+ .comp_drv = &soc_codec_dev_ak4497,
+};
+
static const struct dev_pm_ops ak4458_pm = {
SET_RUNTIME_PM_OPS(ak4458_runtime_suspend, ak4458_runtime_resume, NULL)
SET_SYSTEM_SLEEP_PM_OPS(pm_runtime_force_suspend,
@@ -592,6 +661,7 @@ static const struct dev_
Re: [PATCH v2 0/5] PM: domains: Add helpers for multi PM domains to avoid open-coding
On Fri, Jan 5, 2024 at 6:02 PM Ulf Hansson wrote: > > Updates in v2: > - Ccing Daniel Baluta and Iuliana Prodan the NXP remoteproc patches to > requests help with testing. > - Fixed NULL pointer bug in patch1, pointed out by Nikunj. > - Added some tested/reviewed-by tags. Thanks for doing this Ulf. I remember that I've tried introducing the helpers some time ago but got side tracked by other tasks. https://lore.kernel.org/linux-pm/20200624103247.7115-1-daniel.bal...@oss.nxp.com/t/ Will review the series and test the remoteproc part this week. Daniel.
Re: [PATCH v2 0/4] remoteproc: imx_rproc: various patches for misc
On Fri, Jul 19, 2024 at 11:27 AM Peng Fan (OSS) wrote: > > This patchset is to upstream a few patches that in NXP downstream for > quite sometime. For patches directly cherry-picked from NXP downstream, > I keep the R-b tags. > > Patch 1 is a minor fix to DDR alias. > Patch 2 was sent out before, > https://patchwork.kernel.org/project/linux-remoteproc/patch/2022011103.403448-1-peng@oss.nxp.com/#25144792 > this is just a resend > Patch 3 is to avoid mu interrupt trigger earlier. > Patch 4 is merge small area to support elf that has large section > > Signed-off-by: Peng Fan Neat and clean. Reviewed-by: Daniel Baluta Thanks Peng!
Re: [PATCH v2 0/2] remoteproc: imx_rproc: support non-blocking tx for i.MX7ULP
On Fri, Jul 19, 2024 at 11:40 AM Peng Fan (OSS) wrote: > > The i.MX7ULP Cortex-A7 is under control of Cortex-M4. The i.MX7ULP Linux > poweroff and restart rely on rpmsg driver to send a message to Cortex-M4 > firmware. Then Cortex-A7 could poweroff or restart by Cortex-M4 to > configure the i.MX7ULP power controller properly. > > However the reboot and restart kernel common code use atomic notifier, > so with blocking tx mailbox will trigger kernel dump, because of > blocking mailbox will use wait_for_completion_timeout. In such case, > linux no need to wait for completion. > > patch 1 is to support non-blocking tx mailbox channel > patch 2 is to switch to non-blocking tx for system poweroff or restart. > > Based on patchset: > https://lore.kernel.org/all/20240719-imx_rproc-v2-0-10d0268c7...@nxp.com/ > > Signed-off-by: Peng Fan Series looks good to me. Reviewed-by: Daniel Baluta
Re: [PATCH v2 2/2] remoteproc: imx_rproc: handle system off for i.MX7ULP
Hello Mathieu,
I've talked to Peng and if my understanding is correct I think the patch is OK.
Maybe we can split the patch in two:
* first, adding the power off callback with explanations.
* second, adding the restart callback with explanations.
And also add a more detailed explanation.
Power off and restart are totally different operations and are not complementary
as I thought in the beginning. There are not like suspend/resume for example.
> > static int imx_rproc_probe(struct platform_device *pdev)
> > {
> > struct device *dev = &pdev->dev;
> > @@ -1104,6 +1122,24 @@ static int imx_rproc_probe(struct platform_device
> > *pdev)
> > if (rproc->state != RPROC_DETACHED)
> > rproc->auto_boot = of_property_read_bool(np, "fsl,auto-boot");
> >
> > + if (of_device_is_compatible(dev->of_node, "fsl,imx7ulp-cm4")) {
> > + ret = devm_register_sys_off_handler(dev,
> > SYS_OFF_MODE_POWER_OFF_PREPARE,
> > + SYS_OFF_PRIO_DEFAULT,
> > +
> > imx_rproc_sys_off_handler, rproc);
>
> Why does the mailbox needs to be set up again when the system is going down...
Scenario: We call Linux *shutdown -P * command to power off the machine.
At this point mailbox TX operation is configured as *blocking*. Power
off is done via
an atomic notifier call which doesn't allow blocking. If we do so we
will endup in a kernel crash.
So, at this moment we setup again the mailboxes configuring them with
*non-blocking* option.
>
> > + if (ret) {
> > + dev_err(dev, "register power off handler failure\n");
> > + goto err_put_clk;
> > + }
> > +
> > + ret = devm_register_sys_off_handler(dev,
> > SYS_OFF_MODE_RESTART_PREPARE,
> > + SYS_OFF_PRIO_DEFAULT,
> > +
> > imx_rproc_sys_off_handler, rproc);
>
> ... and why does it need to be free'd when the system is going up?
System is not going up here. System is running and we do a reboot.
Scenario: We call Linux *shutdown -r* command to reboot the machine.
Similarly, mailboxes are already set and configured as *blocking*. We
cannot use the mailboxes
as they are because reboot is done via an atomic notifier which if we
call a blocking function it will endup in crash.
So, we need to free the existing mailbox and create new ones with the
*non-blocking* options.
I think this is really fair to me. The one thing, I admit we must work
on, create a better commit message.
What do you say? Does this work for you?
Thanks a lot for your help!
Re: [PATCH v3 1/2] remoteproc: imx_rproc: Allow setting of the mailbox transmit mode
On Thu, Aug 22, 2024 at 4:40 PM Peng Fan (OSS) wrote: > > From: Peng Fan > > Current mailbox is blocking by default, but there are cases where we don't > need to wait for a response. > > Linux just needs to send data to the remote processor, so let's > allow tx_block mode to be set (true/false) depending on usecase. > > No functional changes. > > Signed-off-by: Peng Fan Reviewed-by: Daniel Baluta
Re: [PATCH v3 2/2] remoteproc: imx_rproc: Add support for poweroff and reboot
On Thu, Aug 22, 2024 at 4:40 PM Peng Fan (OSS) wrote: > > From: Peng Fan > > On some NXP platforms (e.g i.MX7ULP) the poweroff and reboot operations > are done via a separate remote core. > > Typically Linux needs to send a message to the remote core and requests > for poweroff or reboot. > > By default the communication between Linux core and the remote core is > is done via a blocking mailbox mechanism but Linux doesn't allow blocking > operations in the system off (reboot, power off) handlers. > > So, we need to make sure the mailbox message send operations do not block > for this specific operations. Fortunately, Linux allows us to register > handlers that are called in preparation of the system off operations. > > Thus, before carrying the power off or reboot preparations, just destroy > the existing mailboxes and create them as non-blocking. > > Note that power off and restart are totally different operations and are > not complementary. > > We introduce a new flag in the imx remoteproc per device data which tells > us when a device needs this special setup. For now, only imx7ulp needs it. > > Signed-off-by: Peng Fan Reviewed-by: Daniel Baluta
Re: [PATCH 2/2] arm64: dts: imx8mp: add reserve-memory nodes for DSP
On Tue, Sep 12, 2023 at 12:54 PM Iuliana Prodan wrote:
>
> On 9/12/2023 11:26 AM, Krzysztof Kozlowski wrote:
> > On 12/09/2023 10:13, Iuliana Prodan wrote:
> >> On 9/12/2023 10:07 AM, Krzysztof Kozlowski wrote:
> >>> On 12/09/2023 00:44, Iuliana Prodan (OSS) wrote:
> From: Iuliana Prodan
>
> Add the reserve-memory nodes used by DSP when the rpmsg
> feature is enabled.
> These can be later used in a dsp node, like:
> dsp: dsp@3b6e8000 {
> compatible = "fsl,imx8mp-dsp";
> reg = <0x3b6e8000 0x88000>;
> mbox-names = "tx0", "rx0", "rxdb0";
> mboxes = <&mu2 2 0>, <&mu2 2 1>,
> <&mu2 3 0>, <&mu2 3 1>;
> memory-region = <&dsp_vdev0buffer>, <&dsp_vdev0vring0>,
> <&dsp_vdev0vring1>, <&dsp_reserved>;
> status = "okay";
> >>> Drop this example from commit msg, useless and not really correct.
> >> Ok, will drop it. But this is a correct example, is just incomplete.
> > No, status=okay is redundant, thus it is not a correct example.
> ok
> };
>
> Signed-off-by: Iuliana Prodan
> ---
> arch/arm64/boot/dts/freescale/imx8mp.dtsi | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> index cc406bb338fe..eedc1921af62 100644
> --- a/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> +++ b/arch/arm64/boot/dts/freescale/imx8mp.dtsi
> @@ -210,6 +210,18 @@
> dsp_reserved: dsp@9240 {
> reg = <0 0x9240 0 0x200>;
> no-map;
> >>> Please test the patches before sending. This does not build.
> >> I've tested on remoteproc tree, but it seems I missed a bracket when
> >> sending upstream. Sorry abut this, will fix it in v2.
> > No, this is not how testing works. You must test this patch. This means
> > you tested something, then ported patch to entirely different tree,
> > resolved conflicts in buggy way and send it without testing. Nope.
> >
> >> Should I test this on other tree(s)?
> > You test the patch on the tree you send it. What is the point to test it
> > on some old code, cherry-pick with bugs and then send?
> >
> > If you have cross-tree dependencies between subsystem, isn't linux-next
> > for this?
linux-next tree is the tree we want.
Re: [PATCH 03/10] iio: imu: kmx61: Enhance error handling
On 01/04/2015 12:45 PM, Jonathan Cameron wrote: On 01/01/15 13:47, Hartmut Knaack wrote: Daniel Baluta schrieb am 23.12.2014 um 14:22: This fixes parts of kmx61 error handling to make code easier to read and to be more consistent with IIO coding conventions: * prefer as single point for error handling instead of duplicating code for each function * directly return a value from a case branch instead of breaking * fix error message for writing REG_CTRL1 Also, add separate error paths for kmx61_trigger_setup/iio_triggered_buffer_setup calls. Some issues remain in this one, please see inline. Otherwise looking good. Fixed up and applied. Thanks for doing this Jonathan. Daniel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] iio: imu: kmx61: Drop odr_bits from kmx61_samp_freq_table
odr_bits values are between 0 and 11, so we can use the index
in kmx61_samp_freq_table instead of odr_bits structure member.
Signed-off-by: Daniel Baluta
---
Changes since v1:
* use ARRAY_SIZE instead of an hardcoded value
* review is at: https://lkml.org/lkml/2015/1/1/46
drivers/iio/imu/kmx61.c | 64 -
1 file changed, 26 insertions(+), 38 deletions(-)
diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
index b60b22d..a32ddbb 100644
--- a/drivers/iio/imu/kmx61.c
+++ b/drivers/iio/imu/kmx61.c
@@ -169,19 +169,18 @@ static const u16 kmx61_uscale_table[] = {9582, 19163,
38326};
static const struct {
int val;
int val2;
- u8 odr_bits;
-} kmx61_samp_freq_table[] = { {12, 50, 0x00},
- {25, 0, 0x01},
- {50, 0, 0x02},
- {100, 0, 0x03},
- {200, 0, 0x04},
- {400, 0, 0x05},
- {800, 0, 0x06},
- {1600, 0, 0x07},
- {0, 781000, 0x08},
- {1, 563000, 0x09},
- {3, 125000, 0x0A},
- {6, 25, 0x0B} };
+} kmx61_samp_freq_table[] = { {12, 50},
+ {25, 0},
+ {50, 0},
+ {100, 0},
+ {200, 0},
+ {400, 0},
+ {800, 0},
+ {1600, 0},
+ {0, 781000},
+ {1, 563000},
+ {3, 125000},
+ {6, 25} };
static const struct {
int val;
@@ -302,24 +301,10 @@ static int kmx61_convert_freq_to_bit(int val, int val2)
for (i = 0; i < ARRAY_SIZE(kmx61_samp_freq_table); i++)
if (val == kmx61_samp_freq_table[i].val &&
val2 == kmx61_samp_freq_table[i].val2)
- return kmx61_samp_freq_table[i].odr_bits;
- return -EINVAL;
-}
-
-static int kmx61_convert_bit_to_freq(u8 odr_bits, int *val, int *val2)
-{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(kmx61_samp_freq_table); i++)
- if (odr_bits == kmx61_samp_freq_table[i].odr_bits) {
- *val = kmx61_samp_freq_table[i].val;
- *val2 = kmx61_samp_freq_table[i].val2;
- return 0;
- }
+ return i;
return -EINVAL;
}
-
static int kmx61_convert_wake_up_odr_to_bit(int val, int val2)
{
int i;
@@ -478,7 +463,7 @@ static int kmx61_set_odr(struct kmx61_data *data, int val,
int val2, u8 device)
static int kmx61_get_odr(struct kmx61_data *data, int *val, int *val2,
u8 device)
-{ int i;
+{
u8 lodr_bits;
if (device & KMX61_ACC)
@@ -490,13 +475,13 @@ static int kmx61_get_odr(struct kmx61_data *data, int
*val, int *val2,
else
return -EINVAL;
- for (i = 0; i < ARRAY_SIZE(kmx61_samp_freq_table); i++)
- if (lodr_bits == kmx61_samp_freq_table[i].odr_bits) {
- *val = kmx61_samp_freq_table[i].val;
- *val2 = kmx61_samp_freq_table[i].val2;
- return 0;
- }
- return -EINVAL;
+ if (lodr_bits >= ARRAY_SIZE(kmx61_samp_freq_table))
+ return -EINVAL;
+
+ *val = kmx61_samp_freq_table[lodr_bits].val;
+ *val2 = kmx61_samp_freq_table[lodr_bits].val2;
+
+ return 0;
}
static int kmx61_set_range(struct kmx61_data *data, u8 range)
@@ -580,8 +565,11 @@ static int kmx61_chip_init(struct kmx61_data *data)
}
data->odr_bits = ret;
- /* set output data rate for wake up (motion detection) function */
- ret = kmx61_convert_bit_to_freq(data->odr_bits, &val, &val2);
+ /*
+* set output data rate for wake up (motion detection) function
+* to match data rate for accelerometer sampling
+*/
+ ret = kmx61_get_odr(data, &val, &val2, KMX61_ACC);
if (ret < 0)
return ret;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V1 1/1] iio: Added Capella cm3232 ambient light sensor driver.
On Thu, Jan 1, 2015 at 2:10 AM, Kevin Tsai wrote: > CM3232 is an advanced ambient light sensor with I2C protocol interface. > The I2C slave address is internally hardwired as 0x10 (7-bit). Writing > to configure register is byte mode, but reading ALS register requests to > use word mode for 16-bit resolution. This looks good to me. Few comments inline. > > Signed-off-by: Kevin Tsai > --- > .../devicetree/bindings/i2c/trivial-devices.txt| 1 + > MAINTAINERS| 6 + > drivers/iio/light/Kconfig | 11 + > drivers/iio/light/Makefile | 1 + > drivers/iio/light/cm3232.c | 403 > + > 5 files changed, 422 insertions(+) > create mode 100644 drivers/iio/light/cm3232.c > > diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt > b/Documentation/devicetree/bindings/i2c/trivial-devices.txt > index 9f4e382..572a7c4 100644 > --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt > +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt > @@ -34,6 +34,7 @@ atmel,24c512 i2c serial eeprom (24cxx) > atmel,24c1024 i2c serial eeprom (24cxx) > atmel,at97sc3204t i2c trusted platform module (TPM) > capella,cm32181CM32181: Ambient Light Sensor > +capella,cm3232 CM3232: Ambient Light Sensor > catalyst,24c32 i2c serial eeprom > cirrus,cs42l51 Cirrus Logic CS42L51 audio codec > dallas,ds1307 64 x 8, Serial, I2C Real-Time Clock > diff --git a/MAINTAINERS b/MAINTAINERS > index ddb9ac8..06a613a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2378,6 +2378,12 @@ F: security/capability.c > F: security/commoncap.c > F: kernel/capability.c > > +CAPELLA MICROSYSTEMS LIGHT SENSOR DRIVER > +M: Kevin Tsai > +S: Maintained > +F: drivers/iio/light/cm* > +F: Documentation/devicetree/bindings/i2c/trivial-devices.txt > + > CC2520 IEEE-802.15.4 RADIO DRIVER > M: Varka Bhadram > L: linux-w...@vger.kernel.org > diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig > index 5bea821..d2318e2 100644 > --- a/drivers/iio/light/Kconfig > +++ b/drivers/iio/light/Kconfig > @@ -48,6 +48,17 @@ config CM32181 > To compile this driver as a module, choose M here: > the module will be called cm32181. > > +config CM3232 > + depends on I2C > + tristate "CM3232 driver" Better name this: "CM3232 ambient light sensor". > + help > +Say Y here if you use cm3232. > +This option enables ambient light sensor using > +Capella Microsystems cm3232 device driver. > + > +To compile this driver as a module, choose M here: > +the module will be called cm3232. > + > config CM36651 > depends on I2C > tristate "CM36651 driver" > diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile > index 47877a3..f2c8d55 100644 > --- a/drivers/iio/light/Makefile > +++ b/drivers/iio/light/Makefile > @@ -7,6 +7,7 @@ obj-$(CONFIG_ADJD_S311) += adjd_s311.o > obj-$(CONFIG_AL3320A) += al3320a.o > obj-$(CONFIG_APDS9300) += apds9300.o > obj-$(CONFIG_CM32181) += cm32181.o > +obj-$(CONFIG_CM3232) += cm3232.o > obj-$(CONFIG_CM36651) += cm36651.o > obj-$(CONFIG_GP2AP020A00F) += gp2ap020a00f.o > obj-$(CONFIG_HID_SENSOR_ALS) += hid-sensor-als.o > diff --git a/drivers/iio/light/cm3232.c b/drivers/iio/light/cm3232.c > new file mode 100644 > index 000..fd98eeb > --- /dev/null > +++ b/drivers/iio/light/cm3232.c > @@ -0,0 +1,403 @@ > +/* > + * Copyright (C) 2014 Capella Microsystems Inc. > + * Author: Kevin Tsai > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2, as published > + * by the Free Software Foundation. > + * Usually, here is the place to mention the I2C slave address. > + */ > + > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > +#include > + > +/* Registers Address */ > +#define CM3232_REG_ADDR_CMD0x00 > +#define CM3232_REG_ADDR_ALS0x50 > +#define CM3232_REG_ADDR_ID 0x53 > + > +/* CMD register */ > +#define CM3232_CMD_ALS_DISABLE BIT(0) > +#defineCM3232_CMD_ALS_HS BIT(1) > + > +#define CM3232_CMD_ALS_IT_SHIFT 2 > +#define CM3232_CMD_ALS_IT_MASK (0x07 << CM3232_CMD_ALS_IT_SHIFT) > +#define CM3232_CMD_ALS_IT_DEFAULT (0x01 << CM3232_CMD_ALS_IT_SHIFT) > + > +#defineCM3232_CMD_ALS_RESETBIT(6) > + > +#define CM3232_CMD_DEFAULT CM3232_CMD_ALS_IT_DEFAULT > + > +#define CM3232_CALIBSCALE_DEFAULT 10 > +#define CM3232_CALIBSCALE_RESOLUTION 10 > +#define CM3232_MLUX_PER_LUX1000 > + > +#define CM323
Re: [PATCH V1 1/1] iio: Added Capella cm3232 ambient light sensor driver.
On Mon, Jan 5, 2015 at 3:09 PM, Joe Perches wrote:
> On Mon, 2015-01-05 at 12:51 +0200, Daniel Baluta wrote:
>> On Thu, Jan 1, 2015 at 2:10 AM, Kevin Tsai wrote:
>> > CM3232 is an advanced ambient light sensor with I2C protocol interface.
>> > The I2C slave address is internally hardwired as 0x10 (7-bit). Writing
>> > to configure register is byte mode, but reading ALS register requests to
>> > use word mode for 16-bit resolution.
>>
>> This looks good to me. Few comments inline.
> []
>> > diff --git a/drivers/iio/light/cm3232.c b/drivers/iio/light/cm3232.c
> []
>> > +/**
>> > + * cm3232_reg_init() - Initialize CM3232 registers
>> > + * @chip: pointer of struct cm3232.
>> > + *
>> > + * Initialize CM3232 ambient light sensor register to default values.
>> > + *
>> > + Return: 0 for success; otherwise for error code.
>> > + */
>> > +static int cm3232_reg_init(struct cm3232_chip *chip)
>> > +{
>> > + struct i2c_client *client = chip->client;
>> > + struct cm3232_als_info *als_info;
>> > + s32 ret;
>> > +
>> > + /* Identify device */
>> > + ret = i2c_smbus_read_word_data(client, CM3232_REG_ADDR_ID);
>> > + if (ret < 0)
>> > + return ret;
>> > + if ((ret & 0xFF) != 0x32)
>> > + return -ENODEV;
>> > +
>> > + /* Disable and reset device */
>> > + chip->regs_cmd = CM3232_CMD_ALS_DISABLE | CM3232_CMD_ALS_RESET;
>> > + ret = i2c_smbus_write_byte_data(client, CM3232_REG_ADDR_CMD,
>> > + chip->regs_cmd);
>> > + if (ret < 0)
>> > + return ret;
>> > +
>> > + /* Initialization */
>> > + als_info = chip->als_info = &cm3232_als_info_default;
>> > + chip->regs_cmd = CM3232_CMD_DEFAULT;
>> > +
>> > + /* Configure register */
>> > + ret = i2c_smbus_write_byte_data(client, CM3232_REG_ADDR_CMD,
>> > + chip->regs_cmd);
>>
>> You could directly return i2c_smbus_write_byte_data(..).
>
> Sometimes it's better to return a specific value
> for the error instead of depending on correctness
> of all the indirect functions in the call chain.
>
> In this case, all the smbus_xfer functions must
> return 0 on success. Do they?
Yes.
http://lxr.free-electrons.com/source/drivers/i2c/i2c-core.c#L2845
>
> Inspecting the codebase for correctness or not
> depending on that correctness is sometimes better
> to avoid doing.
You have a valid point. Anyhow, AFAIK the code from IIO
prefers a direct return.
Also, I guess kbuild test robot will complain about it, like here:
http://marc.info/?l=linux-kernel&m=141963536230419&w=2
thanks,
Daniel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V1 1/1] iio: Added Capella cm3232 ambient light sensor driver.
On Mon, Jan 5, 2015 at 6:42 PM, Joe Perches wrote: > On Mon, 2015-01-05 at 16:20 +0200, Daniel Baluta wrote: >> On Mon, Jan 5, 2015 at 3:09 PM, Joe Perches wrote: >> > On Mon, 2015-01-05 at 12:51 +0200, Daniel Baluta wrote: >> >> On Thu, Jan 1, 2015 at 2:10 AM, Kevin Tsai wrote: >> >> > CM3232 is an advanced ambient light sensor with I2C protocol interface. >> >> > The I2C slave address is internally hardwired as 0x10 (7-bit). Writing >> >> > to configure register is byte mode, but reading ALS register requests to >> >> > use word mode for 16-bit resolution. > [] >> >> You could directly return i2c_smbus_write_byte_data(..). >> > >> > Sometimes it's better to return a specific value >> > for the error instead of depending on correctness >> > of all the indirect functions in the call chain. >> > >> > In this case, all the smbus_xfer functions must >> > return 0 on success. Do they? >> >> Yes. >> >> http://lxr.free-electrons.com/source/drivers/i2c/i2c-core.c#L2845 > > This doesn't show that adapter->algo->smbus_xfer() > returns 0, you have to look at the code for that > indirectly called function. I based my answer on the comment at the top of the function: 2845 * This executes an SMBus protocol operation, and returns a negative 2846 * errno code else zero on success. > >> Also, I guess kbuild test robot will complain about it, like here: >> >> http://marc.info/?l=linux-kernel&m=141963536230419&w=2 > > Is the kbuild test robot now submitting patches for all > possible coccinelle simplifications? I don't think so. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 00/10] iio: KMX61 fixes
This is a series of cleanups after Hartmut's review: * http://marc.info/?l=linux-iio&m=141859700810393&w=2 * http://marc.info/?l=linux-iio&m=141859774010580&w=2 * http://marc.info/?l=linux-iio&m=141859828910703&w=2 * http://marc.info/?l=linux-kernel&m=141868557909385&w=2 Daniel Baluta (10): iio: imu: kmx61: Save odr_bits for later use iio: imu: kmx61: Don't ignore kmx61_set_power_state errors iio: imu: kmx61: Enhance error handling iio: imu: kmx61: Fixup parameters alignment iio: imu: kmx61: Drop unused device parameter iio: imu: kmx61: Use false instead of 0 for ev_enable_state iio: imu: kmx61: Fix device initialization when setting trigger state iio: imu: kmx61: Remove unnecessary REG_INS1 read iio: imu: kmx61: Drop odr_bits from kmx61_samp_freq_table iio: imu: kmx61: Use correct base when reading data drivers/iio/imu/kmx61.c | 216 ++-- 1 file changed, 101 insertions(+), 115 deletions(-) -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 07/10] iio: imu: kmx61: Fix device initialization when setting trigger state
Signed-off-by: Daniel Baluta --- drivers/iio/imu/kmx61.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c index 30825cf..5b5be2b 100644 --- a/drivers/iio/imu/kmx61.c +++ b/drivers/iio/imu/kmx61.c @@ -1057,8 +1057,7 @@ static int kmx61_data_rdy_trigger_set_state(struct iio_trigger *trig, goto err_unlock; } - - if (data->acc_dready_trig == trig || data->motion_trig) + if (data->acc_dready_trig == trig || data->motion_trig == trig) device = KMX61_ACC; else device = KMX61_MAG; -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 10/10] iio: imu: kmx61: Use correct base when reading data
We have two IIO devices and we need to adjust the base
when reading data.
Signed-off-by: Daniel Baluta
---
drivers/iio/imu/kmx61.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
index 98369eb..6178cea 100644
--- a/drivers/iio/imu/kmx61.c
+++ b/drivers/iio/imu/kmx61.c
@@ -1210,12 +1210,18 @@ static irqreturn_t kmx61_trigger_handler(int irq, void
*p)
struct iio_dev *indio_dev = pf->indio_dev;
struct kmx61_data *data = kmx61_get_data(indio_dev);
int bit, ret, i = 0;
+ u8 base;
s16 buffer[8];
+ if (indio_dev == data->acc_indio_dev)
+ base = KMX61_ACC_XOUT_L;
+ else
+ base = KMX61_MAG_XOUT_L;
+
mutex_lock(&data->lock);
for_each_set_bit(bit, indio_dev->buffer->scan_mask,
indio_dev->masklength) {
- ret = kmx61_read_measurement(data, KMX61_ACC_XOUT_L, bit);
+ ret = kmx61_read_measurement(data, base, bit);
if (ret < 0) {
mutex_unlock(&data->lock);
goto err;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 04/10] iio: imu: kmx61: Fixup parameters alignment
Signed-off-by: Daniel Baluta
---
drivers/iio/imu/kmx61.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
index 4fc4f63..2652179 100644
--- a/drivers/iio/imu/kmx61.c
+++ b/drivers/iio/imu/kmx61.c
@@ -926,11 +926,11 @@ static int kmx61_read_event(struct iio_dev *indio_dev,
}
static int kmx61_write_event(struct iio_dev *indio_dev,
- const struct iio_chan_spec *chan,
- enum iio_event_type type,
- enum iio_event_direction dir,
- enum iio_event_info info,
- int val, int val2)
+const struct iio_chan_spec *chan,
+enum iio_event_type type,
+enum iio_event_direction dir,
+enum iio_event_info info,
+int val, int val2)
{
struct kmx61_data *data = kmx61_get_data(indio_dev);
@@ -962,10 +962,10 @@ static int kmx61_read_event_config(struct iio_dev
*indio_dev,
}
static int kmx61_write_event_config(struct iio_dev *indio_dev,
- const struct iio_chan_spec *chan,
- enum iio_event_type type,
- enum iio_event_direction dir,
- int state)
+ const struct iio_chan_spec *chan,
+ enum iio_event_type type,
+ enum iio_event_direction dir,
+ int state)
{
struct kmx61_data *data = kmx61_get_data(indio_dev);
int ret = 0;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 09/10] iio: imu: kmx61: Drop odr_bits from kmx61_samp_freq_table
odr_bits values are between 0 and 11, so we can use the index
in kmx61_samp_freq_table instead of odr_bits structure member.
Signed-off-by: Daniel Baluta
---
drivers/iio/imu/kmx61.c | 64 -
1 file changed, 26 insertions(+), 38 deletions(-)
diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
index eb3900e..98369eb 100644
--- a/drivers/iio/imu/kmx61.c
+++ b/drivers/iio/imu/kmx61.c
@@ -169,19 +169,18 @@ u16 kmx61_uscale_table[] = {9582, 19163, 38326};
static const struct {
int val;
int val2;
- u8 odr_bits;
-} kmx61_samp_freq_table[] = { {12, 50, 0x00},
- {25, 0, 0x01},
- {50, 0, 0x02},
- {100, 0, 0x03},
- {200, 0, 0x04},
- {400, 0, 0x05},
- {800, 0, 0x06},
- {1600, 0, 0x07},
- {0, 781000, 0x08},
- {1, 563000, 0x09},
- {3, 125000, 0x0A},
- {6, 25, 0x0B} };
+} kmx61_samp_freq_table[] = { {12, 50},
+ {25, 0},
+ {50, 0},
+ {100, 0},
+ {200, 0},
+ {400, 0},
+ {800, 0},
+ {1600, 0},
+ {0, 781000},
+ {1, 563000},
+ {3, 125000},
+ {6, 25} };
static const struct {
int val;
@@ -302,24 +301,10 @@ static int kmx61_convert_freq_to_bit(int val, int val2)
for (i = 0; i < ARRAY_SIZE(kmx61_samp_freq_table); i++)
if (val == kmx61_samp_freq_table[i].val &&
val2 == kmx61_samp_freq_table[i].val2)
- return kmx61_samp_freq_table[i].odr_bits;
- return -EINVAL;
-}
-
-static int kmx61_convert_bit_to_freq(u8 odr_bits, int *val, int *val2)
-{
- int i;
-
- for (i = 0; i < ARRAY_SIZE(kmx61_samp_freq_table); i++)
- if (odr_bits == kmx61_samp_freq_table[i].odr_bits) {
- *val = kmx61_samp_freq_table[i].val;
- *val2 = kmx61_samp_freq_table[i].val2;
- return 0;
- }
+ return i;
return -EINVAL;
}
-
static int kmx61_convert_wake_up_odr_to_bit(int val, int val2)
{
int i;
@@ -478,7 +463,7 @@ static int kmx61_set_odr(struct kmx61_data *data, int val,
int val2, u8 device)
static int kmx61_get_odr(struct kmx61_data *data, int *val, int *val2,
u8 device)
-{ int i;
+{
u8 lodr_bits;
if (device & KMX61_ACC)
@@ -490,13 +475,13 @@ static int kmx61_get_odr(struct kmx61_data *data, int
*val, int *val2,
else
return -EINVAL;
- for (i = 0; i < ARRAY_SIZE(kmx61_samp_freq_table); i++)
- if (lodr_bits == kmx61_samp_freq_table[i].odr_bits) {
- *val = kmx61_samp_freq_table[i].val;
- *val2 = kmx61_samp_freq_table[i].val2;
- return 0;
- }
- return -EINVAL;
+ if (lodr_bits > 0xB)
+ return -EINVAL;
+
+ *val = kmx61_samp_freq_table[lodr_bits].val;
+ *val2 = kmx61_samp_freq_table[lodr_bits].val2;
+
+ return 0;
}
static int kmx61_set_range(struct kmx61_data *data, u8 range)
@@ -580,8 +565,11 @@ static int kmx61_chip_init(struct kmx61_data *data)
}
data->odr_bits = ret;
- /* set output data rate for wake up (motion detection) function */
- ret = kmx61_convert_bit_to_freq(data->odr_bits, &val, &val2);
+ /*
+* set output data rate for wake up (motion detection) function
+* to match data rate for accelerometer sampling
+*/
+ ret = kmx61_get_odr(data, &val, &val2, KMX61_ACC);
if (ret < 0)
return ret;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 08/10] iio: imu: kmx61: Remove unnecessary REG_INS1 read
Useful in the debugging phase, not needed now. Signed-off-by: Daniel Baluta --- drivers/iio/imu/kmx61.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c index 5b5be2b..eb3900e 100644 --- a/drivers/iio/imu/kmx61.c +++ b/drivers/iio/imu/kmx61.c @@ -1196,8 +1196,6 @@ ack_intr: if (ret < 0) dev_err(&data->client->dev, "Error reading reg_inl\n"); - ret = i2c_smbus_read_byte_data(data->client, KMX61_REG_INS1); - return IRQ_HANDLED; } -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 06/10] iio: imu: kmx61: Use false instead of 0 for ev_enable_state
Signed-off-by: Daniel Baluta
---
drivers/iio/imu/kmx61.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
index 332ee67..30825cf 100644
--- a/drivers/iio/imu/kmx61.c
+++ b/drivers/iio/imu/kmx61.c
@@ -976,7 +976,7 @@ static int kmx61_write_event_config(struct iio_dev
*indio_dev,
mutex_lock(&data->lock);
if (!state && data->motion_trig_on) {
- data->ev_enable_state = 0;
+ data->ev_enable_state = false;
goto err_unlock;
}
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 03/10] iio: imu: kmx61: Enhance error handling
This fixes parts of kmx61 error handling to make code easier to read and to be
more consistent with IIO coding conventions:
* prefer as single point for error handling instead of duplicating code
for each function
* directly return a value from a case branch instead of breaking
* fix error message for writing REG_CTRL1
Also, add separate error paths for
kmx61_trigger_setup/iio_triggered_buffer_setup
calls.
Signed-off-by: Daniel Baluta
---
drivers/iio/imu/kmx61.c | 100 +---
1 file changed, 43 insertions(+), 57 deletions(-)
diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
index e9cbd91..4fc4f63 100644
--- a/drivers/iio/imu/kmx61.c
+++ b/drivers/iio/imu/kmx61.c
@@ -656,11 +656,7 @@ static int kmx61_setup_new_data_interrupt(struct
kmx61_data *data,
return ret;
}
- ret = kmx61_set_mode(data, mode, KMX61_ACC | KMX61_MAG, true);
- if (ret)
- return ret;
-
- return 0;
+ return kmx61_set_mode(data, mode, KMX61_ACC | KMX61_MAG, true);
}
static int kmx61_chip_update_thresholds(struct kmx61_data *data)
@@ -678,12 +674,10 @@ static int kmx61_chip_update_thresholds(struct kmx61_data
*data)
ret = i2c_smbus_write_byte_data(data->client,
KMX61_REG_WUF_THRESH,
data->wake_thresh);
- if (ret < 0) {
+ if (ret < 0)
dev_err(&data->client->dev, "Error writing reg_wuf_thresh\n");
- return ret;
- }
- return 0;
+ return ret;
}
static int kmx61_setup_any_motion_interrupt(struct kmx61_data *data,
@@ -737,11 +731,7 @@ static int kmx61_setup_any_motion_interrupt(struct
kmx61_data *data,
return ret;
}
mode |= KMX61_ACT_STBY_BIT;
- ret = kmx61_set_mode(data, mode, KMX61_ACC | KMX61_MAG, true);
- if (ret)
- return ret;
-
- return 0;
+ return kmx61_set_mode(data, mode, KMX61_ACC | KMX61_MAG, true);
}
/**
@@ -924,10 +914,10 @@ static int kmx61_read_event(struct iio_dev *indio_dev,
switch (info) {
case IIO_EV_INFO_VALUE:
*val = data->wake_thresh;
- break;
+ return IIO_VAL_INT;
case IIO_EV_INFO_PERIOD:
*val = data->wake_duration;
- break;
+ return IIO_VAL_INT;
default:
return -EINVAL;
}
@@ -950,10 +940,10 @@ static int kmx61_write_event(struct iio_dev *indio_dev,
switch (info) {
case IIO_EV_INFO_VALUE:
data->wake_thresh = val;
- break;
+ return IIO_VAL_INT;
case IIO_EV_INFO_PERIOD:
data->wake_duration = val;
- break;
+ return IIO_VAL_INT;
default:
return -EINVAL;
}
@@ -978,7 +968,7 @@ static int kmx61_write_event_config(struct iio_dev
*indio_dev,
int state)
{
struct kmx61_data *data = kmx61_get_data(indio_dev);
- int ret;
+ int ret = 0;
if (state && data->ev_enable_state)
return 0;
@@ -987,27 +977,25 @@ static int kmx61_write_event_config(struct iio_dev
*indio_dev,
if (!state && data->motion_trig_on) {
data->ev_enable_state = 0;
- mutex_unlock(&data->lock);
- return 0;
+ goto err_unlock;
}
ret = kmx61_set_power_state(data, state, KMX61_ACC);
- if (ret < 0) {
- mutex_unlock(&data->lock);
- return ret;
- }
+ if (ret < 0)
+ goto err_unlock;
ret = kmx61_setup_any_motion_interrupt(data, state, KMX61_ACC);
if (ret < 0) {
kmx61_set_power_state(data, false, KMX61_ACC);
- mutex_unlock(&data->lock);
- return ret;
+ goto err_unlock;
}
data->ev_enable_state = state;
+
+err_unlock:
mutex_unlock(&data->lock);
- return 0;
+ return ret;
}
static int kmx61_acc_validate_trigger(struct iio_dev *indio_dev,
@@ -1066,8 +1054,7 @@ static int kmx61_data_rdy_trigger_set_state(struct
iio_trigger *trig,
if (!state && data->ev_enable_state && data->motion_trig_on) {
data->motion_trig_on = false;
- mutex_unlock(&data->lock);
- return 0;
+ goto err_unlock;
}
@@ -1077,10 +1064,8 @@ static int kmx61_data_rdy_trigger_set_state(struct
iio_trigger *trig,
device = KMX61_MAG;
ret = kmx61_set_power_state(data, state, device);
- if (ret < 0) {
- mutex_unlock(&data->lock);
- r
[PATCH 05/10] iio: imu: kmx61: Drop unused device parameter
Signed-off-by: Daniel Baluta
---
drivers/iio/imu/kmx61.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
index 2652179..332ee67 100644
--- a/drivers/iio/imu/kmx61.c
+++ b/drivers/iio/imu/kmx61.c
@@ -681,7 +681,7 @@ static int kmx61_chip_update_thresholds(struct kmx61_data
*data)
}
static int kmx61_setup_any_motion_interrupt(struct kmx61_data *data,
- bool status, u8 device)
+ bool status)
{
u8 mode;
int ret;
@@ -984,7 +984,7 @@ static int kmx61_write_event_config(struct iio_dev
*indio_dev,
if (ret < 0)
goto err_unlock;
- ret = kmx61_setup_any_motion_interrupt(data, state, KMX61_ACC);
+ ret = kmx61_setup_any_motion_interrupt(data, state);
if (ret < 0) {
kmx61_set_power_state(data, false, KMX61_ACC);
goto err_unlock;
@@ -1070,7 +1070,7 @@ static int kmx61_data_rdy_trigger_set_state(struct
iio_trigger *trig,
if (data->acc_dready_trig == trig || data->mag_dready_trig == trig)
ret = kmx61_setup_new_data_interrupt(data, state, device);
else
- ret = kmx61_setup_any_motion_interrupt(data, state, KMX61_ACC);
+ ret = kmx61_setup_any_motion_interrupt(data, state);
if (ret < 0) {
kmx61_set_power_state(data, false, device);
goto err_unlock;
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 02/10] iio: imu: kmx61: Don't ignore kmx61_set_power_state errors
..except while in an error handler, where there is nothing
to be done anyway.
Signed-off-by: Daniel Baluta
---
drivers/iio/imu/kmx61.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
index fe0cee7..e9cbd91 100644
--- a/drivers/iio/imu/kmx61.c
+++ b/drivers/iio/imu/kmx61.c
@@ -830,7 +830,12 @@ static int kmx61_read_raw(struct iio_dev *indio_dev,
}
mutex_lock(&data->lock);
- kmx61_set_power_state(data, true, chan->address);
+ ret = kmx61_set_power_state(data, true, chan->address);
+ if (ret) {
+ mutex_unlock(&data->lock);
+ return ret;
+ }
+
ret = kmx61_read_measurement(data, base_reg, chan->scan_index);
if (ret < 0) {
kmx61_set_power_state(data, false, chan->address);
@@ -839,9 +844,11 @@ static int kmx61_read_raw(struct iio_dev *indio_dev,
}
*val = sign_extend32(ret >> chan->scan_type.shift,
chan->scan_type.realbits - 1);
- kmx61_set_power_state(data, false, chan->address);
+ ret = kmx61_set_power_state(data, false, chan->address);
mutex_unlock(&data->lock);
+ if (ret)
+ return ret;
return IIO_VAL_INT;
case IIO_CHAN_INFO_SCALE:
switch (chan->type) {
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 01/10] iio: imu: kmx61: Save odr_bits for later use
Signed-off-by: Daniel Baluta
---
drivers/iio/imu/kmx61.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
index 972424b..fe0cee7 100644
--- a/drivers/iio/imu/kmx61.c
+++ b/drivers/iio/imu/kmx61.c
@@ -465,6 +465,8 @@ static int kmx61_set_odr(struct kmx61_data *data, int val,
int val2, u8 device)
if (ret < 0)
return ret;
+ data->odr_bits = odr_bits;
+
if (device & KMX61_ACC) {
ret = kmx61_set_wake_up_odr(data, val, val2);
if (ret)
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iio: imu: kmx61: fix simple_return.cocci warnings
On Sat, Dec 27, 2014 at 1:07 AM, kbuild test robot wrote: > drivers/iio/imu/kmx61.c:543:1-4: WARNING: end returns can be simpified > drivers/iio/imu/kmx61.c:480:1-4: WARNING: end returns can be simpified if > negative or 0 value > > Simplify a trivial if-return sequence. Possibly combine with a > preceding function call. > Generated by: scripts/coccinelle/misc/simple_return.cocci > > CC: Daniel Baluta > Signed-off-by: Fengguang Wu > --- > > kmx61.c |6 +- > 1 file changed, 1 insertion(+), 5 deletions(-) > > --- a/drivers/iio/imu/kmx61.c > +++ b/drivers/iio/imu/kmx61.c > @@ -540,11 +540,7 @@ static int kmx61_setup_new_data_interrup > return ret; > } > > - ret = kmx61_set_mode(data, mode, KMX61_ACC | KMX61_MAG, true); > - if (ret) > - return ret; > - > - return 0; > + return kmx61_set_mode(data, mode, KMX61_ACC | KMX61_MAG, true); > } > > /** Fixed with this patch: http://marc.info/?l=linux-iio&m=141934100614777&w=2 Daniel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] nfc: NXP PN544 ACPI support
On Fri, Jan 9, 2015 at 2:02 PM, Robert Dolca wrote:
> Device id: NXP5440
> Pin mapping:
> - 0 IRQ pin
> - 1 enable pin
> - 2 firmware pin
>
> Signed-off-by: Robert Dolca
> ---
> drivers/nfc/Kconfig | 1 +
> drivers/nfc/pn544/i2c.c | 115
> ++--
> net/nfc/core.c | 1 +
> 3 files changed, 114 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/nfc/Kconfig b/drivers/nfc/Kconfig
> index 7929fac..a25e712 100644
> --- a/drivers/nfc/Kconfig
> +++ b/drivers/nfc/Kconfig
> @@ -68,6 +68,7 @@ config NFC_PORT100
>
> If unsure, say N.
>
> +source "drivers/nfc/pn547/Kconfig"
I think this line shouldn't be here :).
> source "drivers/nfc/pn544/Kconfig"
> source "drivers/nfc/microread/Kconfig"
> source "drivers/nfc/nfcmrvl/Kconfig"
> diff --git a/drivers/nfc/pn544/i2c.c b/drivers/nfc/pn544/i2c.c
> index 5f4b9c1..58b9029 100644
> --- a/drivers/nfc/pn544/i2c.c
> +++ b/drivers/nfc/pn544/i2c.c
> @@ -24,6 +24,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -41,6 +42,11 @@
> #define PN544_I2C_FRAME_HEADROOM 1
> #define PN544_I2C_FRAME_TAILROOM 2
>
> +/* GPIO names */
> +#define PN544_GPIO_NAME_IRQ "pn544_irq"
> +#define PN544_GPIO_NAME_FW "pn544_fw"
> +#define PN544_GPIO_NAME_EN "pn544_en"
> +
> /* framing in HCI mode */
> #define PN544_HCI_I2C_LLC_LEN 1
> #define PN544_HCI_I2C_LLC_CRC 2
> @@ -58,6 +64,13 @@ static struct i2c_device_id pn544_hci_i2c_id_table[] = {
>
> MODULE_DEVICE_TABLE(i2c, pn544_hci_i2c_id_table);
>
> +static const struct acpi_device_id pn544_hci_i2c_acpi_match[] = {
> + {"NXP5440", 0},
> + {}
> +};
> +
> +MODULE_DEVICE_TABLE(acpi, pn544_hci_i2c_acpi_match);
> +
> #define PN544_HCI_I2C_DRIVER_NAME "pn544_hci_i2c"
>
> /*
> @@ -859,6 +872,90 @@ exit_state_wait_secure_write_answer:
> }
> }
>
> +static int pn544_hci_i2c_acpi_request_resources(struct i2c_client *client)
> +{
> + struct pn544_i2c_phy *phy = i2c_get_clientdata(client);
> + const struct acpi_device_id *id;
> + struct gpio_desc *gpiod_en, *gpiod_irq, *gpiod_fw;
> + struct device *dev;
> + int ret;
> +
> + if (!client)
> + return -EINVAL;
> +
> + dev = &client->dev;
> +
> + /* Match the struct device against a given list of ACPI IDs */
> + id = acpi_match_device(dev->driver->acpi_match_table, dev);
> +
> + if (!id)
> + return -ENODEV;
> +
> + /* Get EN GPIO from ACPI */
> + gpiod_en = devm_gpiod_get_index(dev, PN544_GPIO_NAME_EN, 1);
> + if (IS_ERR(gpiod_en)) {
> + nfc_err(dev,
> + "Unable to get EN GPIO\n");
> + return -ENODEV;
> + }
> +
> + phy->gpio_en = desc_to_gpio(gpiod_en);
> +
> + /* Configuration EN GPIO */
> + ret = gpiod_direction_output(gpiod_en, 0);
> + if (ret) {
> + nfc_err(dev, "Fail EN pin direction\n");
> + return ret;
> + }
> +
> + /* Get FW GPIO from ACPI */
> + gpiod_fw = devm_gpiod_get_index(dev, PN544_GPIO_NAME_FW, 2);
> + if (IS_ERR(gpiod_fw)) {
> + nfc_err(dev,
> + "Unable to get FW GPIO\n");
> + return -ENODEV;
> + }
> +
> + phy->gpio_fw = desc_to_gpio(gpiod_fw);
> +
> + /* Configuration FW GPIO */
> + ret = gpiod_direction_output(gpiod_fw, 0);
> + if (ret) {
> + nfc_err(dev, "Fail FW pin direction\n");
> + return ret;
> + }
> +
> + /* Get IRQ GPIO */
> + gpiod_irq = devm_gpiod_get_index(dev, PN544_GPIO_NAME_IRQ, 0);
> + if (IS_ERR(gpiod_irq)) {
> + nfc_err(dev,
> + "Unable to get IRQ GPIO\n");
> + return -ENODEV;
> + }
> +
> + phy->gpio_irq = desc_to_gpio(gpiod_irq);
> +
> + /* Configure IRQ GPIO */
> + ret = gpiod_direction_input(gpiod_irq);
> + if (ret) {
> + nfc_err(dev, "Fail IRQ pin direction\n");
> + return ret;
> + }
> +
> + /* Map the pin to an IRQ */
> + ret = gpiod_to_irq(gpiod_irq);
> + if (ret < 0) {
> + nfc_err(dev, "Fail pin IRQ mapping\n");
> + return ret;
> + }
> +
> + nfc_info(dev, "GPIO resource, no:%d irq:%d\n",
> + desc_to_gpio(gpiod_irq), ret);
> + client->irq = ret;
> +
> + return 0;
> +}
> +
> #ifdef CONFIG_OF
>
> static int pn544_hci_i2c_of_request_resources(struct i2c_client *client)
> @@ -884,7 +981,7 @@ static int pn544_hci_i2c_of_request_resources(struct
> i2c_client *client)
> phy->gpio_en = ret;
>
> /* Configuration of EN GPIO */
> - ret = gpio_request(phy->gpio_en, "pn544_en");
> + ret = gpio_request(phy->gpio_en, PN544_GPIO_NAME_EN);
> if (ret) {
> nfc_err(&client->dev, "Fail EN pin\n");
>
Re: [PATCH] iio: light: Add support for Capella CM3323 color/light sensor
On Sun, Jan 25, 2015 at 12:27 PM, Jonathan Cameron wrote:
> On 22/01/15 10:10, Daniel Baluta wrote:
>> Minimal implementation providing raw light intensity and illuminance
>> readings. For illuminance user can compute lux values using raw readings
>> and scale.
>>
>> This driver also supports CM3323E sensor chip.
>>
>> Cc: Kevin Tsai
>> Signed-off-by: Daniel Baluta
>
> Hi Daniel,
>
> My only real question on this one is whether using the 'green' channel
> and pretending it is a measure of illuminance is a good idea or whether
> we are better leaving that decision to userspace...
>
> I'm guessing the reason it is green rather than clear is that
> the clear is letting infrared through and we don't have an additional
> infrared sensor available to allow that component to be removed?
Hi Jonathan,
>> +#define CM3323_COLOR_CHANNEL(_color, _addr) {\
>> + .type = IIO_INTENSITY, \
>> + .modified = 1, \
>> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW), \
>> + .info_mask_shared_by_all = BIT(IIO_CHAN_INFO_INT_TIME), \
>> + .channel2 = IIO_MOD_LIGHT_##_color, \
>> + .address = _addr, \
>> +}
>> +
>> +/*
>> + * CM3323's GREEN channel is used for reading illuminance
> That's impressively random and unlikely to be anywhere near correct
> pretty much all the time!
>
> I'd personally prefer just not providing an illuminance channel
> and leaving it up to userspace to make the decision on whether the
> green channel is good enough...
Datasheet says that the GREEN channel should be used
for getting illuminance readings. I'm not sure if this is
totally random.
I understand your worries, perhaps Kevin could 'enlighten' us here.
I would prefer to have the illuminance channel exported from
IIO because there are already userspace applications/frameworks
written and tested for ALS that use IIO illuminance channel.
We want to use this driver without modifying user space.
Of course, one option for the moment would be to only export
the INTENSITY channels as per your recommendation and
to decide later what to do for the LIGHT channel.
Thanks for review!
Daniel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 07/10] iio: core: Introduce IIO_CHAN_INFO_FILTER_OUTLIERS_THRESH and _PERIOD
On Mon, Jan 26, 2015 at 1:07 AM, Jonathan Cameron wrote:
> On 11/01/15 19:10, Irina Tirdea wrote:
>> The pedometer needs to filter out false steps that might be generated by
>> tapping the foot, sitting, etc. To do that it computes the number of
>> steps that occur in a given time and decides the user is moving only
>> if this value is over a threshold. E.g.: the user starts moving only
>> if he takes 4 steps in 3 seconds. This filter is applied only when
>> the user starts moving.
>>
>> A device that has such pedometer functionality is Freescale's MMA9553L:
>> http://www.freescale.com/files/sensors/doc/ref_manual/MMA9553LSWRM.pdf.
>>
>> To export this feature, this patch introduces
>> IIO_CHAN_INFO_FILTER_OUTLIERS_THRESH and
>> IIO_CHAN_INFO_FILTER_OUTLIERS_PERIOD.
>> For the pedometer, in_steps_filter_outlier_thresh will specify the number of
>> steps that need to occur in in_steps_filter_outlier_period seconds so that
>> the pedometer decides the user is moving.
>>
>> Signed-off-by: Irina Tirdea
> I wonder if the naming here is infact too generic. They aren't what
> people would normally think of as outliers. That would be removing
> missidentified steps mid way through grabbing data (to my mind).
>
> These are almost a 'debounce' of the transition from stationary to
> walking... Maybe there is another better term. All suggestions welcome!
What about:
in_steps_debounce_count instead of in_steps_filter_outlier_thresh
and
in_steps_debounce_delay instead of in_steps_filter_outlier_period.
Also in_steps_debounce_time could work for in_steps_filter_outlier_period.
>
>> ---
>> Documentation/ABI/testing/sysfs-bus-iio | 21 +
>> drivers/iio/industrialio-core.c | 2 ++
>> include/linux/iio/iio.h | 2 ++
>> 3 files changed, 25 insertions(+)
>>
>> diff --git a/Documentation/ABI/testing/sysfs-bus-iio
>> b/Documentation/ABI/testing/sysfs-bus-iio
>> index c03a140..e009f49 100644
>> --- a/Documentation/ABI/testing/sysfs-bus-iio
>> +++ b/Documentation/ABI/testing/sysfs-bus-iio
>> @@ -1193,3 +1193,24 @@ Description:
>> This attribute is used to read the current speed value of the
>> user (which is the norm or magnitude of the velocity vector).
>> Units after application of scale are m/s.
>> +
>> +What:/sys/.../iio:deviceX/in_steps_filter_outliers_period
>> +KernelVersion: 3.20
>> +Contact: linux-...@vger.kernel.org
>> +Description:
>> + Specifies the number of seconds in which we compute the
>> + values so we can decide if they are outlier values and
>> + need to be filter out. These computed values are then
>> + compared with in_steps_filter_outliers_thresh. E.g. for steps:
>> + specifies number of seconds in which we compute the steps
>> + that occur in order to decide if the consumer is making steps.
>> +
>> +What:/sys/.../iio:deviceX/in_steps_filter_outliers_thresh
>> +KernelVersion: 3.20
>> +Contact: linux-...@vger.kernel.org
>> +Description:
>> + Specifies a threshold for filtering outlier values: if value
>> + measured in in_steps_filter_outliers_period seconds is below
>> + threshold, we filter it out. E.g. for steps: specifies number
>> + of steps that must occur within in_steps_filter_outliers_period
>> + for the pedometer to decide the consumer is making steps.
>> diff --git a/drivers/iio/industrialio-core.c
>> b/drivers/iio/industrialio-core.c
>> index 4ee6fdf..81678b3 100644
>> --- a/drivers/iio/industrialio-core.c
>> +++ b/drivers/iio/industrialio-core.c
>> @@ -126,6 +126,8 @@ static const char * const iio_chan_info_postfix[] = {
>> [IIO_CHAN_INFO_ENABLE] = "en",
>> [IIO_CHAN_INFO_CALIBHEIGHT] = "calibheight",
>> [IIO_CHAN_INFO_CALIBWEIGHT] = "calibweight",
>> + [IIO_CHAN_INFO_FILTER_OUTLIERS_THRESH] = "filter_outliers_thresh",
>> + [IIO_CHAN_INFO_FILTER_OUTLIERS_PERIOD] = "filter_outliers_period",
>> };
>>
>> /**
>> diff --git a/include/linux/iio/iio.h b/include/linux/iio/iio.h
>> index 752a929..b6b12ac 100644
>> --- a/include/linux/iio/iio.h
>> +++ b/include/linux/iio/iio.h
>> @@ -41,6 +41,8 @@ enum iio_chan_info_enum {
>> IIO_CHAN_INFO_ENABLE,
>> IIO_CHAN_INFO_CALIBHEIGHT,
>> IIO_CHAN_INFO_CALIBWEIGHT,
>> + IIO_CHAN_INFO_FILTER_OUTLIERS_THRESH,
>> + IIO_CHAN_INFO_FILTER_OUTLIERS_PERIOD,
>> };
>>
>> enum iio_shared_by {
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
checkpatch wrong error message
Hi Joe,
Running ./scripts/checkpatch on the attached [1] patch i get the
following error:
ERROR: Please use 12 or more chars for the git commit ID like: 'commit
01234567890ab ("commit description")'
#6:
After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
total: 1 errors, 0 warnings, 16 lines checked
0001-iio-kmx61-PM-Replace-CONFIG_PM_RUNTIME-with-CONFIG_P.patch has
style problems, please review.
As you can see b2b49ccbdd54 is exactly 12 chars so there shouldn't be
an error report.
Also example git ID is wrong 01234567890ab (13 chars) should be
0123456789ab (12 chars).
thanks,
Daniel.
[1] http://marc.info/?l=linux-iio&m=142079625602634&w=2
From 0f9fb78211d73484a4e919d3696f2358d20e9c2c Mon Sep 17 00:00:00 2001
From: Daniel Baluta
Date: Fri, 9 Jan 2015 11:17:27 +0200
Subject: [PATCH] iio kmx61 / PM: Replace CONFIG_PM_RUNTIME with CONFIG_PM
After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
selected) PM_RUNTIME is always set if PM is set, so #ifdef blocks
depending on CONFIG_PM_RUNTIME may now be changed to depend on
CONFIG_PM.
Replace CONFIG_PM_RUNTIME with CONFIG_PM everywhere under
drivers/iio/imu/kmx61.c
Signed-off-by: Daniel Baluta
---
drivers/iio/imu/kmx61.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/iio/imu/kmx61.c b/drivers/iio/imu/kmx61.c
index 6178cea..a682dd1 100644
--- a/drivers/iio/imu/kmx61.c
+++ b/drivers/iio/imu/kmx61.c
@@ -735,7 +735,7 @@ static int kmx61_setup_any_motion_interrupt(struct kmx61_data *data,
*/
static int kmx61_set_power_state(struct kmx61_data *data, bool on, u8 device)
{
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
int ret;
if (device & KMX61_ACC) {
@@ -1523,7 +1523,7 @@ static int kmx61_resume(struct device *dev)
}
#endif
-#ifdef CONFIG_PM_RUNTIME
+#ifdef CONFIG_PM
static int kmx61_runtime_suspend(struct device *dev)
{
struct kmx61_data *data = i2c_get_clientdata(to_i2c_client(dev));
--
1.9.1
Re: checkpatch wrong error message
On Fri, Jan 9, 2015 at 3:31 PM, Joe Perches wrote:
> On Fri, 2015-01-09 at 13:57 +0200, Daniel Baluta wrote:
>> Hi Joe,
>>
>> Running ./scripts/checkpatch on the attached [1] patch i get the
>> following error:
>>
>> ERROR: Please use 12 or more chars for the git commit ID like: 'commit
>> 01234567890ab ("commit description")'
>> #6:
>> After commit b2b49ccbdd54 (PM: Kconfig: Set PM_RUNTIME if PM_SLEEP is
>
> checkpatch uses the same message for multiple forms.
>
> There were some patches around to make this clearer.
> https://lkml.org/lkml/2014/10/20/630
>
> Your commit message does not have quotes around the text.
>
> It should be:
>
> After commit <2b49ccbdd54 ("PM: Kconfig: Set ...")
:) I see, thanks!
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH V2 1/1] iio: Added Capella cm3232 ambient light sensor driver.
On Wed, Jan 7, 2015 at 12:09 AM, Kevin Tsai wrote: > CM3232 is an advanced ambient light sensor with I2C protocol interface. > The I2C slave address is internally hardwired as 0x10 (7-bit). Writing > to configure register is byte mode, but reading ALS register requests to > use word mode for 16-bit resolution. > > v2: > Removed unused CM3232_CMD_ALS_HS. > Modified cm3232_als_info structure. Removed id field. > Modified cm3232_chip structure. > Merged CM3232_als_it_bits and CM3232_als_it_values to cm3232_it_scale. > Removed mutex lock. > Renamed als_raw to regs_als. Moved it to cm3232_chip structure. > Modified cm3232_read_als_it() and cm3232_write_als_it() to support val2. > > Thanks comments from Jeremiah Mahler, Peter Meerwald, Daniel Baluta, > and Joe Perches. > > v1: > Added cm3232.c to support Capella Microsystems CM3232 Ambient Light > Sensor. > Usually, we keep history out of the commit message - below the scissor line. > Signed-off-by: Kevin Tsai > --- > .../devicetree/bindings/i2c/trivial-devices.txt| 1 + > MAINTAINERS| 6 + > drivers/iio/light/Kconfig | 11 + > drivers/iio/light/Makefile | 1 + > drivers/iio/light/cm3232.c | 411 > + > 5 files changed, 430 insertions(+) > create mode 100644 drivers/iio/light/cm3232.c > > diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt > b/Documentation/devicetree/bindings/i2c/trivial-devices.txt > index 9f4e382..572a7c4 100644 > --- a/Documentation/devicetree/bindings/i2c/trivial-devices.txt > +++ b/Documentation/devicetree/bindings/i2c/trivial-devices.txt > @@ -34,6 +34,7 @@ atmel,24c512 i2c serial eeprom (24cxx) > atmel,24c1024 i2c serial eeprom (24cxx) > atmel,at97sc3204t i2c trusted platform module (TPM) > capella,cm32181CM32181: Ambient Light Sensor > +capella,cm3232 CM3232: Ambient Light Sensor > catalyst,24c32 i2c serial eeprom > cirrus,cs42l51 Cirrus Logic CS42L51 audio codec > dallas,ds1307 64 x 8, Serial, I2C Real-Time Clock > diff --git a/MAINTAINERS b/MAINTAINERS > index ddb9ac8..06a613a 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -2378,6 +2378,12 @@ F: security/capability.c > F: security/commoncap.c > F: kernel/capability.c > > +CAPELLA MICROSYSTEMS LIGHT SENSOR DRIVER > +M: Kevin Tsai > +S: Maintained > +F: drivers/iio/light/cm* > +F: Documentation/devicetree/bindings/i2c/trivial-devices.txt > + > CC2520 IEEE-802.15.4 RADIO DRIVER > M: Varka Bhadram > L: linux-w...@vger.kernel.org > diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig > index 5bea821..cd5028e 100644 > --- a/drivers/iio/light/Kconfig > +++ b/drivers/iio/light/Kconfig > @@ -48,6 +48,17 @@ config CM32181 > To compile this driver as a module, choose M here: > the module will be called cm32181. > > +config CM3232 > + depends on I2C > + tristate "CM3232 ambient light sensor" > + help > +Say Y here if you use cm3232. > +This option enables ambient light sensor using > +Capella Microsystems cm3232 device driver. > + > +To compile this driver as a module, choose M here: > +the module will be called cm3232. > + > config CM36651 > depends on I2C > tristate "CM36651 driver" > diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile > index 47877a3..f2c8d55 100644 > --- a/drivers/iio/light/Makefile > +++ b/drivers/iio/light/Makefile > @@ -7,6 +7,7 @@ obj-$(CONFIG_ADJD_S311) += adjd_s311.o > obj-$(CONFIG_AL3320A) += al3320a.o > obj-$(CONFIG_APDS9300) += apds9300.o > obj-$(CONFIG_CM32181) += cm32181.o > +obj-$(CONFIG_CM3232) += cm3232.o > obj-$(CONFIG_CM36651) += cm36651.o > obj-$(CONFIG_GP2AP020A00F) += gp2ap020a00f.o > obj-$(CONFIG_HID_SENSOR_ALS) += hid-sensor-als.o > diff --git a/drivers/iio/light/cm3232.c b/drivers/iio/light/cm3232.c > new file mode 100644 > index 000..b4b7d1b > --- /dev/null > +++ b/drivers/iio/light/cm3232.c > @@ -0,0 +1,411 @@ > +/* > + * CM3232 Ambient Light Sensor > + * > + * Copyright (C) 2014-2015 Capella Microsystems Inc. > + * Author: Kevin Tsai > + * > + * This program is free software; you can redistribute it and/or modify it > + * under the terms of the GNU General Public License version 2, as published > + * by the Free Software Foundation. > + * > + * IIO driver for CM3232 (7-bit I2C slave address 0x10). &
Re: [PATCH V3 1/1] iio: Added Capella cm3232 ambient light sensor driver.
On Fri, Jan 16, 2015 at 3:41 AM, Kevin Tsai wrote: > CM3232 is an advanced ambient light sensor with I2C protocol interface. > The I2C slave address is internally hardwired as 0x10 (7-bit). Writing > to configure register is byte mode, but reading ALS register requests to > use word mode for 16-bit resolution. IIO part looks good to me. Would be nice to see some comments from Peter and Hartmut. thanks, Daniel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] iio: ak8975: Make sure chipset is always initialized
Hello, On Sat, Dec 20, 2014 at 11:29 PM, Pandruvada, Srinivas wrote: > +Mika > > On Sat, 2014-12-20 at 13:26 -0800, Srinivas Pandruvada wrote: >> On Sat, 2014-12-20 at 00:25 +0200, Daniel Baluta wrote: >> > On Sat, Dec 20, 2014 at 12:16 AM, Hartmut Knaack wrote: >> > > Daniel Baluta schrieb am 18.12.2014 um 18:16: >> > >> When using ACPI, if acpi_match_device fails then chipset enum will be >> > >> uninitialized and &ak_def_array[chipset] will point to some bad address. >> > >> >> I am missing something. You are enumerated over i2c device, which was >> created from ACPI PNP resource. There is a valid handle or and the >> device has an ACPI companion at the least. If this failing, I have to >> check the code for acpi i2c. >> Can you check why this check failed? We may have bug in i2c handling. You are right about this. Under normal circumstances, if probe is called then acpi_match_device will not fail. I even tried to remove the device after probe but before acpi_match_device, anyhow acpi_match_device was still successful :) This is more a matter of code correctness. In ak8975_match_acpi_device we have: » const struct acpi_device_id *id; » id = acpi_match_device(dev->driver->acpi_match_table, dev); » if (!id) » » return NULL; » *chipset = (int)id->driver_data; Compiler complains on the fact that chipset might be uninitialized if this returns NULL, and we shouldn't ignore this warning even this case will never happen. We could use some code injection techniques to force acpi_match_device to return NULL tough. >> > >> This fixes the following compilation warning: >> > >> >> > >> drivers/iio/magnetometer/ak8975.c: In function ‘ak8975_probe’: >> > >> drivers/iio/magnetometer/ak8975.c:788:14: warning: ‘chipset’ may be used >> > >> uninitialized in this function [-Wmaybe-uninitialized] >> > >> data->def =ak_def_array[chipset]; >> > >> >> > >> Reported-by: Octavian Purdila >> > >> Signed-off-by: Daniel Baluta >> > >> --- >> > >> This is a RFC because while I'm pretty sure that chipset should be >> > >> initialized >> > >> with AK_MAX_TYPE in ak8975_match_acpi_device, I am not sure if we can >> > >> live with >> > >> a NULL return value of ak8975_match_acpi_device. Current implementation >> > >> ignores >> > >> return value of ak8975_match_acpi_device. >> > > This seems to be the actual problem: these _match_acpi_device functions >> > > return >> > > NULL on failure, and this should be checked for. >> > >> > Ok, so this would acceptable? >> > >> > diff --git a/drivers/iio/magnetometer/ak8975.c >> > b/drivers/iio/magnetometer/ak8975.c >> > index 0d10a4b..68d99e9 100644 >> > --- a/drivers/iio/magnetometer/ak8975.c >> > +++ b/drivers/iio/magnetometer/ak8975.c >> > @@ -776,8 +776,9 @@ static int ak8975_probe(struct i2c_client *client, >> > name = id->name; >> > } else if (ACPI_HANDLE(&client->dev)) >> > name = ak8975_match_acpi_device(&client->dev, &chipset); >> > - else >> > - return -ENOSYS; >> > + >> > + if (!name) >> > + return -ENODEV; >> > >> > >> > I still have some doubts about return code in case of error. >> > >> > For ak8975 we use -ENOSYS, but for kxcjk-1013 we use -ENODEV. >> > >> > I will send a patch after we clear this out. >> > >> > thanks, >> > Daniel. >> > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH] iio: ak8975: Make sure chipset is always initialized
On Mon, Jan 19, 2015 at 6:44 PM, Pandruvada, Srinivas wrote: > On Mon, 2015-01-19 at 16:40 +0200, Daniel Baluta wrote: >> Hello, >> >> On Sat, Dec 20, 2014 at 11:29 PM, Pandruvada, Srinivas >> wrote: >> > +Mika >> > >> > On Sat, 2014-12-20 at 13:26 -0800, Srinivas Pandruvada wrote: >> >> On Sat, 2014-12-20 at 00:25 +0200, Daniel Baluta wrote: >> >> > On Sat, Dec 20, 2014 at 12:16 AM, Hartmut Knaack >> >> > wrote: >> >> > > Daniel Baluta schrieb am 18.12.2014 um 18:16: >> >> > >> When using ACPI, if acpi_match_device fails then chipset enum will be >> >> > >> uninitialized and &ak_def_array[chipset] will point to some bad >> >> > >> address. >> >> > >> >> >> I am missing something. You are enumerated over i2c device, which was >> >> created from ACPI PNP resource. There is a valid handle or and the >> >> device has an ACPI companion at the least. If this failing, I have to >> >> check the code for acpi i2c. >> >> Can you check why this check failed? We may have bug in i2c handling. >> >> You are right about this. Under normal circumstances, if probe is called >> then acpi_match_device will not fail. I even tried to remove the >> device after probe >> but before acpi_match_device, anyhow acpi_match_device was still successful >> :) >> >> This is more a matter of code correctness. >> >> In ak8975_match_acpi_device we have: >> >> » const struct acpi_device_id *id; >> >> » id = acpi_match_device(dev->driver->acpi_match_table, dev); >> » if (!id) >> » » return NULL; >> » *chipset = (int)id->driver_data; >> >> Compiler complains on the fact that chipset might be uninitialized >> if this returns NULL, and we shouldn't ignore this warning even this case >> will never happen. >> > Will this fix? > data->chipset = AK8975; > before > ak8975_match_acpi_device(&client->dev, &data->chipset); > Yes, this is done in the original patch: + *chipset = AK_MAX_TYPE; .. and fixes the warning. Daniel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RESEND PATCH] configfs: init configfs module earlier at boot time
On Wed, Mar 18, 2015 at 9:56 PM, Daniel Baluta wrote:
> We need this earlier in the boot process to allow various subsystems
> to use configfs (e.g Industrial IIO).
>
> Also, debugfs is at core_initcall level and configfs should be on
> the same level from infrastructure point of view.
>
> Suggested-by: Lars-Peter Clausen
> Signed-off-by: Daniel Baluta
> ---
> First time I miscopied Joel's email address.
>
> fs/configfs/mount.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/fs/configfs/mount.c b/fs/configfs/mount.c
> index da94e41..5373567 100644
> --- a/fs/configfs/mount.c
> +++ b/fs/configfs/mount.c
> @@ -173,5 +173,5 @@ MODULE_LICENSE("GPL");
> MODULE_VERSION("0.0.2");
> MODULE_DESCRIPTION("Simple RAM filesystem for user driven kernel subsystem
> configuration.");
>
> -module_init(configfs_init);
> +core_initcall(configfs_init);
> module_exit(configfs_exit);
> --
Hi Joel,
Did you get any chance to look into this? I am not sure
exactly who should take this, so I'm adding Greg.
The original patch can also be found here:
https://lkml.org/lkml/2015/3/18/751
Daniel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/3] Add initial configfs support for IIO
This patchset adds initial support for configfs in IIO. Patch 1: * adds configfs infrastructure creating an "iio" configfs subystem + an initial "triggers" group. Patch 2: * adds the first "real" trigger type - hrtimer. Patch 3: * adds Documentation Changes since v1 are listed in each individual patch. Daniel Baluta (3): iio: configfs: Add configfs support to IIO iio: trigger: Add support for highres timer trigger type iio: Documentation: Add documentation for IIO configfs Documentation/iio/iio_configfs.txt | 82 + drivers/iio/Kconfig | 8 + drivers/iio/Makefile | 1 + drivers/iio/industrialio-configfs.c | 291 +++ drivers/iio/trigger/Kconfig | 9 + drivers/iio/trigger/Makefile | 2 + drivers/iio/trigger/iio-trig-hrtimer.c | 154 include/linux/iio/iio_configfs_trigger.h | 41 + 8 files changed, 588 insertions(+) create mode 100644 Documentation/iio/iio_configfs.txt create mode 100644 drivers/iio/industrialio-configfs.c create mode 100644 drivers/iio/trigger/iio-trig-hrtimer.c create mode 100644 include/linux/iio/iio_configfs_trigger.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] iio: Documentation: Add documentation for IIO configfs
Signed-off-by: Daniel Baluta --- Changes since v1: * addressed feedback for v1: * https://lkml.org/lkml/2015/3/25/648 * adapted to match the changes in patches 1 and 2 * fixed some typos and clarified further work Documentation/iio/iio_configfs.txt | 82 ++ 1 file changed, 82 insertions(+) create mode 100644 Documentation/iio/iio_configfs.txt diff --git a/Documentation/iio/iio_configfs.txt b/Documentation/iio/iio_configfs.txt new file mode 100644 index 000..a49d5a1 --- /dev/null +++ b/Documentation/iio/iio_configfs.txt @@ -0,0 +1,82 @@ +Industrial IIO configfs support + +1. Overview + +Configfs is a filesystem-based manager of kernel objects. IIO uses some +objects that could be easily configured using configfs (e.g.: devices, +triggers). + +See Documentation/filesystems/configfs/configfs.txt for more information +about how configfs works. + +2. Usage + +In order to use configfs support in IIO we need to select it at compile +time via CONFIG_IIO_CONFIGFS config option. + +Then, mount the configfs filesystem (usually under /config directory): + +$ mkdir /config $ mount -t configfs none /config + +At this point, all default IIO groups will be created and can be accessed +under /config/iio. Next chapters will describe available IIO configuration +objects. + +3. Software triggers + +One of the IIO default configfs groups is the "triggers" groups. It is +automagically accessible when the configfs is mounted and can be found +under /config/iio/triggers. + +Under /config/iio/triggers we will create trigger types. For the moment +we have "hrtimer" trigger time and we plan to add at least one more +"sysfs" trigger type. + +3.1 Trigger types + +Represent a specific type of trigger. For now we have an implementation +for "hrtimer" trigger type. + +3.2. Trigger creation and destruction + +As simply as: + +$ mkdir /config/triggers/hrtimer/my_trigger + +Creating my_trigger directory will result in creation of "my_trigger" +trigger of "hrtimer" type. Destruction happens when my_trigger directory +is removed. + +Each trigger can have one or more attributes specific to the trigger type. + +3.3 "hrtimer" trigger types attributes + +"hrtimer" trigger type has only one attribute: + +$ ls /config/triggers/hrtimer/my_trigger delay + +delay - represents the amount of time in nanoseconds between two +consecutive iio_trigger_poll calls. By default it is set to 1, +that is the equivalent of a 100Hz frequency. + +3.4. Adding a new trigger type + +In order to add a new trigger type, one needs to: + +* [iio_configfs_trigger.h] + ** add a new IIO_TRIGGER_TYPE +* [iio-trig-.c] + ** declare and initialize a structure of type + iio_configfs_trigger_type + ** implement needed iio_configfs_trigger_ops + ** register/unregister the new trigger + type with the IIO configfs core +* [industrialiio-configfs.c] + ** create a new group type and add it in the default group of + trigger types. + ** create new attributes and them to the IIO configfs core. + +4. Further work + +* add "sysfs" trigger type + -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 2/3] iio: trigger: Add support for highres timer trigger type
This patch adds a new trigger type - the high resoluton timer ("hrtimer")
under /config/iio/triggers/ and also creates a module that implements hrtimer
trigger type functionality.
A new IIO trigger is allocated when a new directory is created under
/config/iio/triggers/. The name of the trigger is the same as the dir
name. Each trigger will have a "delay" attribute representing the delay
between two successive IIO trigger_poll calls.
Signed-off-by: Marten Svanfeldt
Signed-off-by: Lars-Peter Clausen
Signed-off-by: Daniel Baluta
---
Changes since v2:
* replaced sampling_frequency with delay to make the in kernel
processing easier
* implemented hrtimer driver using the new API proposed in patch 1
drivers/iio/industrialio-configfs.c | 164 +++
drivers/iio/trigger/Kconfig | 9 ++
drivers/iio/trigger/Makefile | 2 +
drivers/iio/trigger/iio-trig-hrtimer.c | 154 +
include/linux/iio/iio_configfs_trigger.h | 1 +
5 files changed, 330 insertions(+)
create mode 100644 drivers/iio/trigger/iio-trig-hrtimer.c
diff --git a/drivers/iio/industrialio-configfs.c
b/drivers/iio/industrialio-configfs.c
index d8ffd76..a0e5d24 100644
--- a/drivers/iio/industrialio-configfs.c
+++ b/drivers/iio/industrialio-configfs.c
@@ -71,7 +71,170 @@ struct iio_configfs_trigger_type
*iio_get_configfs_trigger_type(int type)
return t;
}
+struct iio_trigger_item {
+ struct config_item item;
+ struct iio_configfs_trigger_info *trigger_info;
+};
+
+static
+inline struct iio_trigger_item *to_iio_trigger_item(struct config_item *item)
+{
+ if (!item)
+ return NULL;
+ return container_of(item, struct iio_trigger_item, item);
+}
+
+CONFIGFS_ATTR_STRUCT(iio_trigger_item);
+
+#define IIO_TRIGGER_ITEM_ATTR(_name, _mode, _show, _store) \
+struct iio_trigger_item_attribute iio_trigger_item_attr_##_name = \
+ __CONFIGFS_ATTR(_name, _mode, _show, _store)
+
+static
+ssize_t iio_trigger_item_get_delay(struct iio_trigger_item *item, char *page)
+{
+ unsigned long delay;
+ int ret;
+
+ struct iio_configfs_trigger_type *t = item->trigger_info->trigger_type;
+
+ ret = t->trigger_ops->get_delay(item->trigger_info, &delay);
+ if (ret < 0)
+ return ret;
+
+ return snprintf(page, PAGE_SIZE, "%lu\n", delay);
+}
+
+static
+ssize_t iio_trigger_item_set_delay(struct iio_trigger_item *item,
+ const char *page,
+ size_t count)
+{
+ int ret;
+ unsigned long delay;
+ struct iio_configfs_trigger_type *t = item->trigger_info->trigger_type;
+
+ ret = kstrtoul(page, 10, &delay);
+ if (ret < 0)
+ return ret;
+
+ ret = t->trigger_ops->set_delay(item->trigger_info, delay);
+ if (ret < 0)
+ return ret;
+
+ return count;
+}
+
+IIO_TRIGGER_ITEM_ATTR(delay, S_IRUGO | S_IWUSR,
+ iio_trigger_item_get_delay,
+ iio_trigger_item_set_delay);
+
+static struct configfs_attribute *iio_trigger_item_attrs[] = {
+ &iio_trigger_item_attr_delay.attr,
+ NULL
+};
+
+CONFIGFS_ATTR_OPS(iio_trigger_item);
+
+static struct configfs_item_operations iio_trigger_item_ops = {
+ .show_attribute = iio_trigger_item_attr_show,
+ .store_attribute = iio_trigger_item_attr_store,
+};
+
+static struct config_item_type iio_trigger_item_type;
+
+static struct config_item *iio_hrtimer_make_item(struct config_group *group,
+const char *name)
+{
+ struct iio_trigger_item *trigger_item;
+ struct iio_configfs_trigger_info *trigger_info;
+ struct iio_configfs_trigger_type *trigger_type;
+ int ret;
+
+ trigger_item = kzalloc(sizeof(*trigger_item), GFP_KERNEL);
+ if (!trigger_item)
+ return ERR_PTR(-ENOMEM);
+ trigger_info = kzalloc(sizeof(*trigger_info), GFP_KERNEL);
+ if (!trigger_info) {
+ ret = -ENOMEM;
+ goto out_free_trigger_item;
+ }
+
+ trigger_info->name = kstrdup(name, GFP_KERNEL);
+ if (!trigger_info->name) {
+ ret = -ENOMEM;
+ goto out_free_trigger_info;
+ }
+
+ trigger_type = iio_get_configfs_trigger_type(IIO_TRIGGER_TYPE_HRTIMER);
+ if (!trigger_type) {
+ pr_err("Unable to get hrtimer trigger!\n");
+ ret = -ENODEV;
+ goto out_free_trigger_name;
+ }
+ ret = trigger_type->trigger_ops->probe(trigger_info);
+ if (ret < 0)
+ goto out_error_module_put;
+
+ trigger_info->trigger_type = trigger_type;
+ trigger_item->trigger_info = trigger_info;
+
+ config_item_init_type_name(&trigge
[PATCH v2 1/3] iio: configfs: Add configfs support to IIO
This module is the core of IIO configfs. It creates the "iio" subsystem under
configfs mount point root, with one default group for "triggers".
It offers basic interface for registering software trigger types. Next patches
will add "hrtimer" and "sysfs" trigger types. To add a new trigger type we must
create a new kernel module which implements iio_configfs_trigger.h interface.
See Documentation/iio/iio_configfs.txt for more details on how configfs
support for IIO works.
Signed-off-by: Daniel Baluta
---
Changes since v1:
* addressed feedback from v1:
* https://lkml.org/lkml/2015/3/25/647
* create a directory per trigger type
* removed activate and type attributes
drivers/iio/Kconfig | 8 ++
drivers/iio/Makefile | 1 +
drivers/iio/industrialio-configfs.c | 127 +++
include/linux/iio/iio_configfs_trigger.h | 40 ++
4 files changed, 176 insertions(+)
create mode 100644 drivers/iio/industrialio-configfs.c
create mode 100644 include/linux/iio/iio_configfs_trigger.h
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 4011eff..41d5863 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -18,6 +18,14 @@ config IIO_BUFFER
Provide core support for various buffer based data
acquisition methods.
+config IIO_CONFIGFS
+ tristate "Enable IIO configuration via configfs"
+ select CONFIGFS_FS
+ help
+ This allows configuring various IIO bits through configfs
+ (e.g. software triggers). For more info see
+ Documentation/iio/iio_configfs.txt.
+
if IIO_BUFFER
config IIO_BUFFER_CB
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 698afc2..90cc407 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -5,6 +5,7 @@
obj-$(CONFIG_IIO) += industrialio.o
industrialio-y := industrialio-core.o industrialio-event.o inkern.o
industrialio-$(CONFIG_IIO_BUFFER) += industrialio-buffer.o
+industrialio-$(CONFIG_IIO_CONFIGFS) += industrialio-configfs.o
industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
diff --git a/drivers/iio/industrialio-configfs.c
b/drivers/iio/industrialio-configfs.c
new file mode 100644
index 000..d8ffd76
--- /dev/null
+++ b/drivers/iio/industrialio-configfs.c
@@ -0,0 +1,127 @@
+/*
+ * Industrial I/O configfs bits
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+static struct iio_configfs_trigger_type *trigger_types[IIO_TRIGGER_TYPE_MAX];
+static DEFINE_RWLOCK(trigger_types_lock);
+
+int register_configfs_trigger(struct iio_configfs_trigger_type *t)
+{
+ int index = t->type;
+ int ret = 0;
+
+ if (index < 0 || index >= IIO_TRIGGER_TYPE_MAX)
+ return -EINVAL;
+
+ write_lock(&trigger_types_lock);
+ if (trigger_types[index])
+ ret = -EBUSY;
+ else
+ trigger_types[index] = t;
+ write_unlock(&trigger_types_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL(register_configfs_trigger);
+
+int unregister_configfs_trigger(struct iio_configfs_trigger_type *t)
+{
+ int index = t->type;
+
+ if (index < 0 || index >= IIO_TRIGGER_TYPE_MAX)
+ return -EINVAL;
+
+ write_lock(&trigger_types_lock);
+ trigger_types[index] = NULL;
+ write_unlock(&trigger_types_lock);
+
+ return 0;
+}
+EXPORT_SYMBOL(unregister_configfs_trigger);
+
+static
+struct iio_configfs_trigger_type *iio_get_configfs_trigger_type(int type)
+{
+ struct iio_configfs_trigger_type *t;
+
+ if (type < 0 || type >= IIO_TRIGGER_TYPE_MAX)
+ return ERR_PTR(-EINVAL);
+
+ read_lock(&trigger_types_lock);
+ t = trigger_types[type];
+ if (t && !try_module_get(t->owner))
+ t = NULL;
+ read_unlock(&trigger_types_lock);
+
+ return t;
+}
+
+static struct config_group *iio_triggers_default_groups[] = {
+ NULL
+};
+
+static struct config_item_type iio_triggers_group_type = {
+ .ct_owner = THIS_MODULE,
+};
+
+static struct config_group iio_triggers_group = {
+ .cg_item = {
+ .ci_namebuf = "triggers",
+ .ci_type = &iio_triggers_group_type,
+ },
+ .default_groups = iio_triggers_default_groups,
+};
+
+static struct config_group *iio_root_default_groups[] = {
+ &iio_triggers_group,
+ NULL
+};
+
+static struct config_item_type iio_root_group_type = {
+ .ct_owner = THIS_MODULE,
+};
+
+static struct co
Re: [PATCH v2 1/3] iio: configfs: Add configfs support to IIO
On Sat, Apr 4, 2015 at 9:26 PM, Paul Bolle wrote: > On Fri, 2015-04-03 at 18:57 +0300, Daniel Baluta wrote: >> --- a/drivers/iio/Kconfig >> +++ b/drivers/iio/Kconfig >> +config IIO_CONFIGFS >> + tristate "Enable IIO configuration via configfs" >> + select CONFIGFS_FS >> + help >> + This allows configuring various IIO bits through configfs >> + (e.g. software triggers). For more info see >> + Documentation/iio/iio_configfs.txt. > >> --- a/drivers/iio/Makefile >> +++ b/drivers/iio/Makefile >> @@ -5,6 +5,7 @@ >> obj-$(CONFIG_IIO) += industrialio.o >> industrialio-y := industrialio-core.o industrialio-event.o inkern.o >> industrialio-$(CONFIG_IIO_BUFFER) += industrialio-buffer.o >> +industrialio-$(CONFIG_IIO_CONFIGFS) += industrialio-configfs.o >> industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o >> industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o > > It seems I didn't pay attention to this Makefile the first time I looked > at this series. And actually reading it I noticed that > industrialio-configfs.o can only be part of the industrial.ko module, > can't it? So this Makefile doesn't allow to build a separate > industrialio-configfs.ko module, right? If so, my previous review, in > which I claimed to spot a nit, was a waste of our time. > > Because I now experienced that if this gets build with CONFIG_IIO=m and > CONFIG_IIO_CONFIGFS=y one gets: > $ make -C ../.. CONFIG_IIO_CONFIGFS=y M=$PWD industrialio.ko > make: Entering directory `[...]' > CC [M] [...]/drivers/iio/industrialio-core.o > CC [M] [...]/linux/drivers/iio/industrialio-event.o > CC [M] [...]drivers/iio/inkern.o > CC [M] [...]/drivers/iio/industrialio-buffer.o > CC [M] [...]/drivers/iio/industrialio-configfs.o > CC [M] [...]/drivers/iio/industrialio-trigger.o > CC [M] [...]/drivers/iio/buffer_cb.o > LD [M] [...]/drivers/iio/industrialio.o > [...]/drivers/iio/industrialio-configfs.o: In function > `iio_configfs_init': > industrialio-configfs.c:(.init.text+0x0): multiple definition of > `init_module' > > [...]/drivers/iio/industrialio-core.o:industrialio-core.c:(.init.text+0x0): > first defined here > [...]/drivers/iio/industrialio-configfs.o: In function > `iio_configfs_exit': > industrialio-configfs.c:(.exit.text+0x0): multiple definition of > `cleanup_module' > > [...]/drivers/iio/industrialio-core.o:industrialio-core.c:(.exit.text+0x0): > first defined here > make[1]: *** [[...]/drivers/iio/industrialio.o] Error 1 > make: *** [industrialio.ko] Error 2 > make: Leaving directory `[...]' > > (I didn't yet test other configurations.) > > So before I waste even more of your time: were you trying to make > configfs support a part of the industrialio module or were you trying to > make configfs support available as a separate module? Hi Paul, Thanks a lot for review. I seee the problem now :). I want to build a separate industrialio-configs.ko module, I will fix this and resend asap. thanks, Daniel. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 0/3] Add initial configfs support for IIO
This patchset adds initial support for configfs in IIO. Patch 1: * adds configfs infrastructure creating an "iio" configfs subystem + an initial "triggers" group. Patch 2: * adds the first "real" trigger type - hrtimer. Patch 3: * adds Documentation Changes since last version are listed in each individual patch. Daniel Baluta (3): iio: configfs: Add configfs support to IIO iio: trigger: Add support for highres timer trigger type iio: Documentation: Add documentation for IIO configfs Documentation/iio/iio_configfs.txt | 83 + drivers/iio/Kconfig | 8 + drivers/iio/Makefile | 1 + drivers/iio/industrialio-configfs.c | 291 +++ drivers/iio/trigger/Kconfig | 9 + drivers/iio/trigger/Makefile | 2 + drivers/iio/trigger/iio-trig-hrtimer.c | 154 include/linux/iio/iio_configfs_trigger.h | 41 + 8 files changed, 589 insertions(+) create mode 100644 Documentation/iio/iio_configfs.txt create mode 100644 drivers/iio/industrialio-configfs.c create mode 100644 drivers/iio/trigger/iio-trig-hrtimer.c create mode 100644 include/linux/iio/iio_configfs_trigger.h -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 3/3] iio: Documentation: Add documentation for IIO configfs
Signed-off-by: Daniel Baluta --- Changes since v2: * fix some whitespace issues reported by Paul Changes since v1: * addressed feedback for v1: * https://lkml.org/lkml/2015/3/25/648 * adapted to match the changes in patches 1 and 2 * fixed some typos and clarified further work Documentation/iio/iio_configfs.txt | 83 ++ 1 file changed, 83 insertions(+) create mode 100644 Documentation/iio/iio_configfs.txt diff --git a/Documentation/iio/iio_configfs.txt b/Documentation/iio/iio_configfs.txt new file mode 100644 index 000..ace7b54 --- /dev/null +++ b/Documentation/iio/iio_configfs.txt @@ -0,0 +1,83 @@ +Industrial IIO configfs support + +1. Overview + +Configfs is a filesystem-based manager of kernel objects. IIO uses some +objects that could be easily configured using configfs (e.g.: devices, +triggers). + +See Documentation/filesystems/configfs/configfs.txt for more information +about how configfs works. + +2. Usage + +In order to use configfs support in IIO we need to select it at compile +time via CONFIG_IIO_CONFIGFS config option. + +Then, mount the configfs filesystem (usually under /config directory): + +$ mkdir /config +$ mount -t configfs none /config + +At this point, all default IIO groups will be created and can be accessed +under /config/iio. Next chapters will describe available IIO configuration +objects. + +3. Software triggers + +One of the IIO default configfs groups is the "triggers" groups. It is +automagically accessible when the configfs is mounted and can be found +under /config/iio/triggers. + +Under /config/iio/triggers we will create trigger types. For the moment +we have "hrtimer" trigger type and we plan to add at least one more type, +the "sysfs" trigger type. + +3.1 Trigger types + +Represent a specific type of trigger. For now we have an implementation +for "hrtimer" trigger type. + +3.2. Trigger creation and destruction + +As simply as: + +$ mkdir /config/triggers/hrtimer/my_trigger + +Creating my_trigger directory will result in creation of "my_trigger" +trigger of "hrtimer" type. Destruction happens when my_trigger directory +is removed. + +Each trigger can have one or more attributes specific to the trigger type. + +3.3 "hrtimer" trigger types attributes + +"hrtimer" trigger type has only one attribute: + +$ ls /config/triggers/hrtimer/my_trigger +delay + +delay - represents the amount of time in nanoseconds between two +consecutive iio_trigger_poll calls. By default it is set to 1, +that is the equivalent of a 100Hz frequency. + +3.4. Adding a new trigger type + +In order to add a new trigger type, one needs to: + +* [iio_configfs_trigger.h] + ** add a new IIO_TRIGGER_TYPE +* [iio-trig-.c] + ** declare and initialize a structure of type + iio_configfs_trigger_type + ** implement needed iio_configfs_trigger_ops + ** register/unregister the new trigger + type with the IIO configfs core +* [industrialiio-configfs.c] + ** create a new group type and add it in the default group of + trigger types. + ** create new attributes and them to the IIO configfs core. + +4. Further work + +* add "sysfs" trigger type -- 1.9.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/3] iio: configfs: Add configfs support to IIO
This module is the core of IIO configfs. It creates the "iio" subsystem under
configfs mount point root, with one default group for "triggers".
It offers basic interface for registering software trigger types. Next patches
will add "hrtimer" and "sysfs" trigger types. To add a new trigger type we must
create a new kernel module which implements iio_configfs_trigger.h interface.
See Documentation/iio/iio_configfs.txt for more details on how configfs
support for IIO works.
Signed-off-by: Daniel Baluta
---
Changes since v2:
* Fix build errors by compiling industrialio-configfs.ko
as a separate module, as reported by Paul.
Changes since v1:
* addressed feedback from v1:
* https://lkml.org/lkml/2015/3/25/647
* create a directory per trigger type
* removed activate and type attributes
drivers/iio/Kconfig | 8 ++
drivers/iio/Makefile | 1 +
drivers/iio/industrialio-configfs.c | 127 +++
include/linux/iio/iio_configfs_trigger.h | 40 ++
4 files changed, 176 insertions(+)
create mode 100644 drivers/iio/industrialio-configfs.c
create mode 100644 include/linux/iio/iio_configfs_trigger.h
diff --git a/drivers/iio/Kconfig b/drivers/iio/Kconfig
index 4011eff..41d5863 100644
--- a/drivers/iio/Kconfig
+++ b/drivers/iio/Kconfig
@@ -18,6 +18,14 @@ config IIO_BUFFER
Provide core support for various buffer based data
acquisition methods.
+config IIO_CONFIGFS
+ tristate "Enable IIO configuration via configfs"
+ select CONFIGFS_FS
+ help
+ This allows configuring various IIO bits through configfs
+ (e.g. software triggers). For more info see
+ Documentation/iio/iio_configfs.txt.
+
if IIO_BUFFER
config IIO_BUFFER_CB
diff --git a/drivers/iio/Makefile b/drivers/iio/Makefile
index 698afc2..72e85c42 100644
--- a/drivers/iio/Makefile
+++ b/drivers/iio/Makefile
@@ -8,6 +8,7 @@ industrialio-$(CONFIG_IIO_BUFFER) += industrialio-buffer.o
industrialio-$(CONFIG_IIO_TRIGGER) += industrialio-trigger.o
industrialio-$(CONFIG_IIO_BUFFER_CB) += buffer_cb.o
+obj-$(CONFIG_IIO_CONFIGFS) += industrialio-configfs.o
obj-$(CONFIG_IIO_TRIGGERED_BUFFER) += industrialio-triggered-buffer.o
obj-$(CONFIG_IIO_KFIFO_BUF) += kfifo_buf.o
diff --git a/drivers/iio/industrialio-configfs.c
b/drivers/iio/industrialio-configfs.c
new file mode 100644
index 000..d8ffd76
--- /dev/null
+++ b/drivers/iio/industrialio-configfs.c
@@ -0,0 +1,127 @@
+/*
+ * Industrial I/O configfs bits
+ *
+ * Copyright (c) 2015 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+static struct iio_configfs_trigger_type *trigger_types[IIO_TRIGGER_TYPE_MAX];
+static DEFINE_RWLOCK(trigger_types_lock);
+
+int register_configfs_trigger(struct iio_configfs_trigger_type *t)
+{
+ int index = t->type;
+ int ret = 0;
+
+ if (index < 0 || index >= IIO_TRIGGER_TYPE_MAX)
+ return -EINVAL;
+
+ write_lock(&trigger_types_lock);
+ if (trigger_types[index])
+ ret = -EBUSY;
+ else
+ trigger_types[index] = t;
+ write_unlock(&trigger_types_lock);
+
+ return ret;
+}
+EXPORT_SYMBOL(register_configfs_trigger);
+
+int unregister_configfs_trigger(struct iio_configfs_trigger_type *t)
+{
+ int index = t->type;
+
+ if (index < 0 || index >= IIO_TRIGGER_TYPE_MAX)
+ return -EINVAL;
+
+ write_lock(&trigger_types_lock);
+ trigger_types[index] = NULL;
+ write_unlock(&trigger_types_lock);
+
+ return 0;
+}
+EXPORT_SYMBOL(unregister_configfs_trigger);
+
+static
+struct iio_configfs_trigger_type *iio_get_configfs_trigger_type(int type)
+{
+ struct iio_configfs_trigger_type *t;
+
+ if (type < 0 || type >= IIO_TRIGGER_TYPE_MAX)
+ return ERR_PTR(-EINVAL);
+
+ read_lock(&trigger_types_lock);
+ t = trigger_types[type];
+ if (t && !try_module_get(t->owner))
+ t = NULL;
+ read_unlock(&trigger_types_lock);
+
+ return t;
+}
+
+static struct config_group *iio_triggers_default_groups[] = {
+ NULL
+};
+
+static struct config_item_type iio_triggers_group_type = {
+ .ct_owner = THIS_MODULE,
+};
+
+static struct config_group iio_triggers_group = {
+ .cg_item = {
+ .ci_namebuf = "triggers",
+ .ci_type = &iio_triggers_group_type,
+ },
+ .default_groups = iio_triggers_default_groups,
+};
+
+static struct config_group *iio_root_default_groups[] = {
+ &iio_t
[PATCH v3 2/3] iio: trigger: Add support for highres timer trigger type
This patch adds a new trigger type - the high resoluton timer ("hrtimer")
under /config/iio/triggers/ and also creates a module that implements hrtimer
trigger type functionality.
A new IIO trigger is allocated when a new directory is created under
/config/iio/triggers/. The name of the trigger is the same as the dir
name. Each trigger will have a "delay" attribute representing the delay
between two successive IIO trigger_poll calls.
Signed-off-by: Marten Svanfeldt
Signed-off-by: Lars-Peter Clausen
Signed-off-by: Daniel Baluta
---
Changes since v2:
* none
Changes since v1:
* replaced sampling_frequency with delay to make the in kernel
processing easier
* implemented hrtimer driver using the new API proposed in patch 1
drivers/iio/industrialio-configfs.c | 164 +++
drivers/iio/trigger/Kconfig | 9 ++
drivers/iio/trigger/Makefile | 2 +
drivers/iio/trigger/iio-trig-hrtimer.c | 154 +
include/linux/iio/iio_configfs_trigger.h | 1 +
5 files changed, 330 insertions(+)
create mode 100644 drivers/iio/trigger/iio-trig-hrtimer.c
diff --git a/drivers/iio/industrialio-configfs.c
b/drivers/iio/industrialio-configfs.c
index d8ffd76..a0e5d24 100644
--- a/drivers/iio/industrialio-configfs.c
+++ b/drivers/iio/industrialio-configfs.c
@@ -71,7 +71,170 @@ struct iio_configfs_trigger_type
*iio_get_configfs_trigger_type(int type)
return t;
}
+struct iio_trigger_item {
+ struct config_item item;
+ struct iio_configfs_trigger_info *trigger_info;
+};
+
+static
+inline struct iio_trigger_item *to_iio_trigger_item(struct config_item *item)
+{
+ if (!item)
+ return NULL;
+ return container_of(item, struct iio_trigger_item, item);
+}
+
+CONFIGFS_ATTR_STRUCT(iio_trigger_item);
+
+#define IIO_TRIGGER_ITEM_ATTR(_name, _mode, _show, _store) \
+struct iio_trigger_item_attribute iio_trigger_item_attr_##_name = \
+ __CONFIGFS_ATTR(_name, _mode, _show, _store)
+
+static
+ssize_t iio_trigger_item_get_delay(struct iio_trigger_item *item, char *page)
+{
+ unsigned long delay;
+ int ret;
+
+ struct iio_configfs_trigger_type *t = item->trigger_info->trigger_type;
+
+ ret = t->trigger_ops->get_delay(item->trigger_info, &delay);
+ if (ret < 0)
+ return ret;
+
+ return snprintf(page, PAGE_SIZE, "%lu\n", delay);
+}
+
+static
+ssize_t iio_trigger_item_set_delay(struct iio_trigger_item *item,
+ const char *page,
+ size_t count)
+{
+ int ret;
+ unsigned long delay;
+ struct iio_configfs_trigger_type *t = item->trigger_info->trigger_type;
+
+ ret = kstrtoul(page, 10, &delay);
+ if (ret < 0)
+ return ret;
+
+ ret = t->trigger_ops->set_delay(item->trigger_info, delay);
+ if (ret < 0)
+ return ret;
+
+ return count;
+}
+
+IIO_TRIGGER_ITEM_ATTR(delay, S_IRUGO | S_IWUSR,
+ iio_trigger_item_get_delay,
+ iio_trigger_item_set_delay);
+
+static struct configfs_attribute *iio_trigger_item_attrs[] = {
+ &iio_trigger_item_attr_delay.attr,
+ NULL
+};
+
+CONFIGFS_ATTR_OPS(iio_trigger_item);
+
+static struct configfs_item_operations iio_trigger_item_ops = {
+ .show_attribute = iio_trigger_item_attr_show,
+ .store_attribute = iio_trigger_item_attr_store,
+};
+
+static struct config_item_type iio_trigger_item_type;
+
+static struct config_item *iio_hrtimer_make_item(struct config_group *group,
+const char *name)
+{
+ struct iio_trigger_item *trigger_item;
+ struct iio_configfs_trigger_info *trigger_info;
+ struct iio_configfs_trigger_type *trigger_type;
+ int ret;
+
+ trigger_item = kzalloc(sizeof(*trigger_item), GFP_KERNEL);
+ if (!trigger_item)
+ return ERR_PTR(-ENOMEM);
+ trigger_info = kzalloc(sizeof(*trigger_info), GFP_KERNEL);
+ if (!trigger_info) {
+ ret = -ENOMEM;
+ goto out_free_trigger_item;
+ }
+
+ trigger_info->name = kstrdup(name, GFP_KERNEL);
+ if (!trigger_info->name) {
+ ret = -ENOMEM;
+ goto out_free_trigger_info;
+ }
+
+ trigger_type = iio_get_configfs_trigger_type(IIO_TRIGGER_TYPE_HRTIMER);
+ if (!trigger_type) {
+ pr_err("Unable to get hrtimer trigger!\n");
+ ret = -ENODEV;
+ goto out_free_trigger_name;
+ }
+ ret = trigger_type->trigger_ops->probe(trigger_info);
+ if (ret < 0)
+ goto out_error_module_put;
+
+ trigger_info->trigger_type = trigger_type;
+ trigger_item->trigger_info = trigger_info;
+
+
Re: [PATCH] lguest: explicitly setup /dev/lguest private_data
On Tue, Apr 7, 2015 at 11:18 AM, Tom Van Braeckel
wrote:
> The private_data member of the /dev/lguest device file is used to hold
> the current struct lguest and needs to be set to NULL to signify that
> no initialization has taken place.
>
> We explicitly set it to NULL to be independent of whatever value the
> misc subsystem initializes it to.
>
> Signed-off-by: Tom Van Braeckel
> ---
> Backstory:
> ==
> The misc subsystem used to initialize a file's private_data to point to
> the misc device when a driver had registered a custom open file
> operation and initialized it to NULL when a custom open file operation
> had *not* been provided.
>
> This subtle quirk was confusing, to the point where kernel code
> registered *empty* file open operations to have private_data point to
> the misc device structure.
>
> And it lead to bugs, where the addition or removal of a custom open
> file operation surprisingly changed the initial contents of a file's
> private_data structure.
>
> The misc subsystem is currently underdoing changes to *always* set
> private_data to point to the misc device instead of only doing this
> when a custom open file operation has been registered.
>
> Intel's 0day kernel testing robot discovered that the lguest driver
> depended on it implicitly being initialized to NULL, as Fengguang Wu
> reported. Thanks a lot for all the hard work!
>
> drivers/lguest/lguest_user.c | 14 +-
> 1 file changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/lguest/lguest_user.c b/drivers/lguest/lguest_user.c
> index c4c6113..054bf70 100644
> --- a/drivers/lguest/lguest_user.c
> +++ b/drivers/lguest/lguest_user.c
> @@ -98,6 +98,17 @@ static int trap(struct lg_cpu *cpu, const unsigned long
> __user *input)
> return 0;
> }
>
> +/*
> + * Set up the /dev/lguest file structure
> + * The file's private_data will hold the "struct lguest" after
> + * initialization and is used to check whether it is already initialized.
> + */
> +static int open(struct inode *inode, struct file *file)
> +{
> + file->private_data = NULL;
> + return 0;
> +}
> +
> /*L:040
> * Once our Guest is initialized, the Launcher makes it run by reading
> * from /dev/lguest.
> @@ -405,10 +416,11 @@ static int close(struct inode *inode, struct file *file)
> *
> * We begin our understanding with the Host kernel interface which the
> Launcher
> * uses: reading and writing a character device called /dev/lguest. All the
> - * work happens in the read(), write() and close() routines:
> + * work happens in the open(), read(), write() and close() routines:
> */
> static const struct file_operations lguest_fops = {
> .owner = THIS_MODULE,
> + .open= open,
> .release = close,
> .write = write,
> .read= read,
Hmm, isn't this already fixed?
https://lkml.org/lkml/2015/3/23/319
thanks,
Daniel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] iio: light: add support for ROHM BH1710/BH1715/BH1721/BH1750/BH1751 ambient light sensors
On Tue, Apr 21, 2015 at 9:43 PM, Tomasz Duszynski wrote:
> Add support for ROHM BH1710/BH1715/BH1721/BH1750/BH1751 ambient light
> sensors.
>
> Signed-off-by: Tomasz Duszynski
> ---
> drivers/iio/light/Kconfig | 10 ++
> drivers/iio/light/Makefile | 1 +
> drivers/iio/light/bh1750.c | 322
> +
> 3 files changed, 333 insertions(+)
> create mode 100644 drivers/iio/light/bh1750.c
>
> diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
> index 5a3237b..9fb79ca 100644
> --- a/drivers/iio/light/Kconfig
> +++ b/drivers/iio/light/Kconfig
> @@ -37,6 +37,16 @@ config APDS9300
> To compile this driver as a module, choose M here: the
> module will be called apds9300.
>
> +config BH1750
> + tristate "BH1750 ambient light sensor"
Better use ROHM BH1750 .. here.
> +static const struct iio_chan_spec bh1750_channels[] = {
> + {
> + .type = IIO_INTENSITY,
Shouldn't this be IIO_LIGHT channel type?
Users will get illuminance after multiplying raw value with scale.
> + .info_mask_separate = BIT(IIO_CHAN_INFO_RAW) |
> + BIT(IIO_CHAN_INFO_SCALE) |
> + BIT(IIO_CHAN_INFO_INT_TIME)
> + }
> +};
> +
> +static int bh1750_probe(struct i2c_client *client,
> + const struct i2c_device_id *id)
> +{
> + int ret, usec;
> + struct bh1750_data *data;
> + struct iio_dev *indio_dev;
> +
> + if (!i2c_check_functionality(client->adapter, I2C_FUNC_I2C |
> + I2C_FUNC_SMBUS_WRITE_BYTE))
> + return -ENODEV;
> +
> + indio_dev = devm_iio_device_alloc(&client->dev, sizeof(*data));
> + if (!indio_dev)
> + return -ENOMEM;
> +
> + data = iio_priv(indio_dev);
> + i2c_set_clientdata(client, indio_dev);
> + data->client = client;
> + data->chip_info = &chip_info_tbl[id->driver_data];
> +
> + usec = data->chip_info->mtreg_to_usec *
> data->chip_info->mtreg_default;
> + ret = bh1750_change_int_time(data, usec);
> + if (ret < 0)
> + return ret;
> +
> + mutex_init(&data->lock);
> + indio_dev->dev.parent = &client->dev;
> + indio_dev->info = &bh1750_info;
> + indio_dev->name = id->name;
> + indio_dev->channels = bh1750_channels;
> + indio_dev->num_channels = ARRAY_SIZE(bh1750_channels);
> + indio_dev->modes = INDIO_DIRECT_MODE;
> +
> + return devm_iio_device_register(&client->dev, indio_dev);
You need also to add a remove function where the chip is powered down. Then
you shouldn't use devm_iio_device_register here, because you need to control
the order of chip powerdown/ device unregister operations at remove.
thanks,
Daniel.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RESEND PATCH] configfs: init configfs module earlier at boot time
We need this earlier in the boot process to allow various subsystems
to use configfs (e.g Industrial IIO).
Also, debugfs is at core_initcall level and configfs should be on
the same level from infrastructure point of view.
Suggested-by: Lars-Peter Clausen
Signed-off-by: Daniel Baluta
Reviewed-by: Christoph Hellwig
---
* third resend, adding Andrew
fs/configfs/mount.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/configfs/mount.c b/fs/configfs/mount.c
index da94e41..5373567 100644
--- a/fs/configfs/mount.c
+++ b/fs/configfs/mount.c
@@ -173,5 +173,5 @@ MODULE_LICENSE("GPL");
MODULE_VERSION("0.0.2");
MODULE_DESCRIPTION("Simple RAM filesystem for user driven kernel subsystem
configuration.");
-module_init(configfs_init);
+core_initcall(configfs_init);
module_exit(configfs_exit);
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 3/3] iio: magnetometer: Add ACPI support for MMC35240
We assume that ACPI device tables use MMC35240 to
identify MEMSIC's 3 axis magnetic sensor.
Signed-off-by: Daniel Baluta
---
drivers/iio/magnetometer/mmc35240.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/iio/magnetometer/mmc35240.c
b/drivers/iio/magnetometer/mmc35240.c
index 7a52c3e..3282862 100644
--- a/drivers/iio/magnetometer/mmc35240.c
+++ b/drivers/iio/magnetometer/mmc35240.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
@@ -481,6 +482,12 @@ static const struct dev_pm_ops mmc35240_pm_ops = {
SET_SYSTEM_SLEEP_PM_OPS(mmc35240_suspend, mmc35240_resume)
};
+static const struct acpi_device_id mmc35240_acpi_match[] = {
+ {"MMC35240", 0},
+ { },
+};
+MODULE_DEVICE_TABLE(acpi, mmc35240_acpi_match);
+
static const struct i2c_device_id mmc35240_id[] = {
{"MMC35240", 0},
{}
@@ -491,6 +498,7 @@ static struct i2c_driver mmc35240_driver = {
.driver = {
.name = MMC35240_DRV_NAME,
.pm = &mmc35240_pm_ops,
+ .acpi_match_table = ACPI_PTR(mmc35240_acpi_match),
},
.probe = mmc35240_probe,
.id_table = mmc35240_id,
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
