Andrew,
is this simple addition something you could still send on to Linus
for this merge window? I would make my life easier to have it in
so I could start using it in patches for various trees in the next
merge window.
Thanks,
Christoph
On Fri, Oct 23, 2015 at 06:33:27PM +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.
>
> Suggested-by: Lars-Peter Clausen <[email protected]>
> Signed-off-by: Daniel Baluta <[email protected]>
> ---
> 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 configfs_register_group(struct config_group *parent_group,
> + struct config_group *group);
> +void configfs_unregister_group(struct config_group *group);
> +
> +struct config_group *
> +configfs_register_default_group(struct config_group *parent_group,
> + const char *name,
> + struct config_item_type *item_type);
> +void configfs_unregister_default_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
---end quoted text---
On Tue, 10 Nov 2015 07:51:26 +0100 Christoph Hellwig <[email protected]> wrote:
> is this simple addition something you could still send on to Linus
> for this merge window? I would make my life easier to have it in
> so I could start using it in patches for various trees in the next
> merge window.
It's super late, but the configfs changes are obviously safe to
existing code.
What about the IIO changes? Will someone be merging them for 4.5-rc1,
or something else?
On 10 November 2015 21:12:37 GMT+00:00, Andrew Morton <[email protected]> wrote:
>On Tue, 10 Nov 2015 07:51:26 +0100 Christoph Hellwig <[email protected]>
>wrote:
>
>> is this simple addition something you could still send on to Linus
>> for this merge window? I would make my life easier to have it in
>> so I could start using it in patches for various trees in the next
>> merge window.
>
>It's super late, but the configfs changes are obviously safe to
>existing code.
>
>What about the IIO changes? Will someone be merging them for 4.5-rc1,
>or something else?
Yes. I'll take the IIO bits and ultimately they'll go through Greg KH for the 4.5
merge window.
Jonathan
>
>--
>To unsubscribe from this list: send the line "unsubscribe linux-iio" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
On Tue, Nov 10, 2015 at 01:12:37PM -0800, Andrew Morton wrote:
> On Tue, 10 Nov 2015 07:51:26 +0100 Christoph Hellwig <[email protected]> wrote:
>
> > is this simple addition something you could still send on to Linus
> > for this merge window? I would make my life easier to have it in
> > so I could start using it in patches for various trees in the next
> > merge window.
>
> It's super late, but the configfs changes are obviously safe to
> existing code.
Loving this change, even if this is merely a drive-by:
Acked-by: Joel Becker <[email protected]>
>
> What about the IIO changes? Will someone be merging them for 4.5-rc1,
> or something else?
>
--
"Copy from one, it's plagiarism; copy from two, it's research."
- Wilson Mizner
http://www.jlbec.org/
[email protected]
On 11/11/15 06:43, Jonathan Cameron wrote:
>
>
> On 10 November 2015 21:12:37 GMT+00:00, Andrew Morton <[email protected]> wrote:
>> On Tue, 10 Nov 2015 07:51:26 +0100 Christoph Hellwig <[email protected]>
>> wrote:
>>
>>> is this simple addition something you could still send on to Linus
>>> for this merge window? I would make my life easier to have it in
>>> so I could start using it in patches for various trees in the next
>>> merge window.
>>
>> It's super late, but the configfs changes are obviously safe to
>> existing code.
>>
>> What about the IIO changes? Will someone be merging them for 4.5-rc1,
>> or something else?
> Yes. I'll take the IIO bits and ultimately they'll go through Greg KH for the 4.5
> merge window.
>
Hi Andrew,
Just taken a quick look at your mmotm list and see this ended up in the
mainline later group (fair enough given the timing!).
As such shall we fall back to plan b) a special git branch pulled into the trees
of anyone who cares?
I'll base such a tree on some obvious point in Linus' tree (either 4.4 or 4.5-rc1)
That way I can get the IIO stuff queued up asap and we can build on that going
forward during this cycle.
Thanks,
Jonathan
On Sun, 15 Nov 2015 10:39:08 +0000 Jonathan Cameron <[email protected]> wrote:
> On 11/11/15 06:43, Jonathan Cameron wrote:
> >
> >
> > On 10 November 2015 21:12:37 GMT+00:00, Andrew Morton <[email protected]> wrote:
> >> On Tue, 10 Nov 2015 07:51:26 +0100 Christoph Hellwig <[email protected]>
> >> wrote:
> >>
> >>> is this simple addition something you could still send on to Linus
> >>> for this merge window? I would make my life easier to have it in
> >>> so I could start using it in patches for various trees in the next
> >>> merge window.
> >>
> >> It's super late, but the configfs changes are obviously safe to
> >> existing code.
> >>
> >> What about the IIO changes? Will someone be merging them for 4.5-rc1,
> >> or something else?
> > Yes. I'll take the IIO bits and ultimately they'll go through Greg KH for the 4.5
> > merge window.
> >
> Hi Andrew,
>
> Just taken a quick look at your mmotm list and see this ended up in the
> mainline later group (fair enough given the timing!).
> As such shall we fall back to plan b) a special git branch pulled into the trees
> of anyone who cares?
>
> I'll base such a tree on some obvious point in Linus' tree (either 4.4 or 4.5-rc1)
> That way I can get the IIO stuff queued up asap and we can build on that going
> forward during this cycle.
I plan to send configfs-allow-dynamic-group-creation.patch to Linus
this week. I'll retain
iio-core-introduce-iio-configfs-support.patch
iio-core-introduce-iio-software-triggers.patch
iio-core-introduce-iio-software-triggers-fix.patch
iio-trigger-introduce-iio-hrtimer-based-trigger.patch
iio-documentation-add-iio-configfs-documentation.patch
with a view to dropping them once I see them turn up in linux-next.
On 17 November 2015 23:47:16 GMT+00:00, Andrew Morton <[email protected]> wrote:
>On Sun, 15 Nov 2015 10:39:08 +0000 Jonathan Cameron <[email protected]>
>wrote:
>
>> On 11/11/15 06:43, Jonathan Cameron wrote:
>> >
>> >
>> > On 10 November 2015 21:12:37 GMT+00:00, Andrew Morton
><[email protected]> wrote:
>> >> On Tue, 10 Nov 2015 07:51:26 +0100 Christoph Hellwig <[email protected]>
>> >> wrote:
>> >>
>> >>> is this simple addition something you could still send on to
>Linus
>> >>> for this merge window? I would make my life easier to have it in
>> >>> so I could start using it in patches for various trees in the
>next
>> >>> merge window.
>> >>
>> >> It's super late, but the configfs changes are obviously safe to
>> >> existing code.
>> >>
>> >> What about the IIO changes? Will someone be merging them for
>4.5-rc1,
>> >> or something else?
>> > Yes. I'll take the IIO bits and ultimately they'll go through Greg
>KH for the 4.5
>> > merge window.
>> >
>> Hi Andrew,
>>
>> Just taken a quick look at your mmotm list and see this ended up in
>the
>> mainline later group (fair enough given the timing!).
>> As such shall we fall back to plan b) a special git branch pulled
>into the trees
>> of anyone who cares?
>>
>> I'll base such a tree on some obvious point in Linus' tree (either
>4.4 or 4.5-rc1)
>> That way I can get the IIO stuff queued up asap and we can build on
>that going
>> forward during this cycle.
>
>I plan to send configfs-allow-dynamic-group-creation.patch to Linus
>this week. I'll retain
>
>iio-core-introduce-iio-configfs-support.patch
>iio-core-introduce-iio-software-triggers.patch
>iio-core-introduce-iio-software-triggers-fix.patch
>iio-trigger-introduce-iio-hrtimer-based-trigger.patch
>iio-documentation-add-iio-configfs-documentation.patch
>
>with a view to dropping them once I see them turn up in linux-next.
That's great. Thanks.
Jonathan
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
On 18/11/15 07:33, Jonathan Cameron wrote:
>
>
> On 17 November 2015 23:47:16 GMT+00:00, Andrew Morton <[email protected]> wrote:
>> On Sun, 15 Nov 2015 10:39:08 +0000 Jonathan Cameron <[email protected]>
>> wrote:
>>
>>> On 11/11/15 06:43, Jonathan Cameron wrote:
>>>>
>>>>
>>>> On 10 November 2015 21:12:37 GMT+00:00, Andrew Morton
>> <[email protected]> wrote:
>>>>> On Tue, 10 Nov 2015 07:51:26 +0100 Christoph Hellwig <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> is this simple addition something you could still send on to
>> Linus
>>>>>> for this merge window? I would make my life easier to have it in
>>>>>> so I could start using it in patches for various trees in the
>> next
>>>>>> merge window.
>>>>>
>>>>> It's super late, but the configfs changes are obviously safe to
>>>>> existing code.
>>>>>
>>>>> What about the IIO changes? Will someone be merging them for
>> 4.5-rc1,
>>>>> or something else?
>>>> Yes. I'll take the IIO bits and ultimately they'll go through Greg
>> KH for the 4.5
>>>> merge window.
>>>>
>>> Hi Andrew,
>>>
>>> Just taken a quick look at your mmotm list and see this ended up in
>> the
>>> mainline later group (fair enough given the timing!).
>>> As such shall we fall back to plan b) a special git branch pulled
>> into the trees
>>> of anyone who cares?
>>>
>>> I'll base such a tree on some obvious point in Linus' tree (either
>> 4.4 or 4.5-rc1)
>>> That way I can get the IIO stuff queued up asap and we can build on
>> that going
>>> forward during this cycle.
>>
>> I plan to send configfs-allow-dynamic-group-creation.patch to Linus
>> this week. I'll retain
>>
>> iio-core-introduce-iio-configfs-support.patch
>> iio-core-introduce-iio-software-triggers.patch
>> iio-core-introduce-iio-software-triggers-fix.patch
>> iio-trigger-introduce-iio-hrtimer-based-trigger.patch
>> iio-documentation-add-iio-configfs-documentation.patch
>>
>> with a view to dropping them once I see them turn up in linux-next.
>
> That's great. Thanks.
I've now applied the rest of the series to my local togreg branch and pushed
out as testing for the autobuilders to play with them.
This branch will get rebased once Greg has picked up the previous PULL request.
Thanks,
Jonathan
>
> Jonathan
>
On 29/11/15 17:27, Jonathan Cameron wrote:
> On 18/11/15 07:33, Jonathan Cameron wrote:
>>
>>
>> On 17 November 2015 23:47:16 GMT+00:00, Andrew Morton <[email protected]> wrote:
>>> On Sun, 15 Nov 2015 10:39:08 +0000 Jonathan Cameron <[email protected]>
>>> wrote:
>>>
>>>> On 11/11/15 06:43, Jonathan Cameron wrote:
>>>>>
>>>>>
>>>>> On 10 November 2015 21:12:37 GMT+00:00, Andrew Morton
>>> <[email protected]> wrote:
>>>>>> On Tue, 10 Nov 2015 07:51:26 +0100 Christoph Hellwig <[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> is this simple addition something you could still send on to
>>> Linus
>>>>>>> for this merge window? I would make my life easier to have it in
>>>>>>> so I could start using it in patches for various trees in the
>>> next
>>>>>>> merge window.
>>>>>>
>>>>>> It's super late, but the configfs changes are obviously safe to
>>>>>> existing code.
>>>>>>
>>>>>> What about the IIO changes? Will someone be merging them for
>>> 4.5-rc1,
>>>>>> or something else?
>>>>> Yes. I'll take the IIO bits and ultimately they'll go through Greg
>>> KH for the 4.5
>>>>> merge window.
>>>>>
>>>> Hi Andrew,
>>>>
>>>> Just taken a quick look at your mmotm list and see this ended up in
>>> the
>>>> mainline later group (fair enough given the timing!).
>>>> As such shall we fall back to plan b) a special git branch pulled
>>> into the trees
>>>> of anyone who cares?
>>>>
>>>> I'll base such a tree on some obvious point in Linus' tree (either
>>> 4.4 or 4.5-rc1)
>>>> That way I can get the IIO stuff queued up asap and we can build on
>>> that going
>>>> forward during this cycle.
>>>
>>> I plan to send configfs-allow-dynamic-group-creation.patch to Linus
>>> this week. I'll retain
>>>
>>> iio-core-introduce-iio-configfs-support.patch
>>> iio-core-introduce-iio-software-triggers.patch
>>> iio-core-introduce-iio-software-triggers-fix.patch
>>> iio-trigger-introduce-iio-hrtimer-based-trigger.patch
>>> iio-documentation-add-iio-configfs-documentation.patch
>>>
>>> with a view to dropping them once I see them turn up in linux-next.
>>
>> That's great. Thanks.
> I've now applied the rest of the series to my local togreg branch and pushed
> out as testing for the autobuilders to play with them.
>
> This branch will get rebased once Greg has picked up the previous PULL request.
Now rebased - I also made a tiny change to take the iio_configfs_subsys
structure static in response to a sparse warning - shout if I've done
anything silly.
>
> Thanks,
>
> Jonathan
>>
>> Jonathan
>>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-iio" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>