Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1670655 > unrolled thread

Re: [PATCH 0/5] irq: generic-chip: resource management improvements

Started byBartosz Golaszewski <brgl@bgdev.pl>
First post2017-06-20 12:40 +0200
Last post2017-06-20 12:50 +0200
Articles 5 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH 0/5] irq: generic-chip: resource management improvements Bartosz Golaszewski <brgl@bgdev.pl> - 2017-06-20 12:40 +0200
    Re: [PATCH 0/5] irq: generic-chip: resource management improvements Bartosz Golaszewski <brgl@bgdev.pl> - 2017-06-20 12:50 +0200
      Re: [PATCH 0/5] irq: generic-chip: resource management  improvements Thomas Gleixner <tglx@linutronix.de> - 2017-06-20 16:20 +0200
        Re: [PATCH 0/5] irq: generic-chip: resource management improvements Bartosz Golaszewski <brgl@bgdev.pl> - 2017-06-21 12:40 +0200
    Re: [PATCH 0/5] irq: generic-chip: resource management improvements Marc Zyngier <marc.zyngier@arm.com> - 2017-06-20 12:50 +0200

#1670655 — Re: [PATCH 0/5] irq: generic-chip: resource management improvements

FromBartosz Golaszewski <brgl@bgdev.pl>
Date2017-06-20 12:40 +0200
SubjectRe: [PATCH 0/5] irq: generic-chip: resource management improvements
Message-ID<tUoJI-7ry-23@gated-at.bofh.it>
2017-05-31 18:06 GMT+02:00 Bartosz Golaszewski <brgl@bgdev.pl>:
> This series is a follow-up to [1].
>
> Some users of irq_alloc_generic_chip() are modules which can be
> removed (e.g. gpio-ml-ioh) but have no means of freeing the allocated
> generic chip.
>
> Last time it was suggested to provide irq_destroy_generic_chip() which
> would undo both irq_remove_generic_chip() and irq_alloc_generic_chip().
>
> This functionality is provided by patch 2/5 with 1/5 adding the option
> to only free the allocated memory.
>
> Patch 3/5 exports a function that will be used in the devres variant
> of irq_alloc_generic_chip().
>
> Patches 4/5 and 5/5 add resource managed versions of
> irq_alloc_generic_chip() & irq_setup_generic_chip(). They will be used
> in drivers where applicable. Device resources are released in reverse
> order so it's ok to call devm_irq_alloc_generic_chip() and then
> devm_irq_setup_generic_chip().
>
> [1] https://lkml.org/lkml/2017/3/8/550
>
> Bartosz Golaszewski (5):
>   irq: generic-chip: provide irq_free_generic_chip()
>   irq: generic-chip: provide irq_destroy_generic_chip()
>   irq: generic-chip: export irq_init_generic_chip() locally
>   irq: generic-chip: provide devm_irq_alloc_generic_chip()
>   irq: generic-chip: provide devm_irq_setup_generic_chip()
>
>  Documentation/driver-model/devres.txt |  2 +
>  include/linux/irq.h                   | 22 +++++++++
>  kernel/irq/devres.c                   | 86 +++++++++++++++++++++++++++++++++++
>  kernel/irq/generic-chip.c             |  7 ++-
>  kernel/irq/internals.h                | 11 +++++
>  5 files changed, 124 insertions(+), 4 deletions(-)
>
> --
> 2.9.3
>

Ping for v4.13.

Is there any reason not to merge it?

Thanks,
Bartosz

[toc] | [next] | [standalone]


#1670661

FromBartosz Golaszewski <brgl@bgdev.pl>
Date2017-06-20 12:50 +0200
Message-ID<tUoTn-7v0-1@gated-at.bofh.it>
In reply to#1670655
2017-06-20 12:41 GMT+02:00 Marc Zyngier <marc.zyngier@arm.com>:
> On 20/06/17 11:31, Bartosz Golaszewski wrote:
>> 2017-05-31 18:06 GMT+02:00 Bartosz Golaszewski <brgl@bgdev.pl>:
>>> This series is a follow-up to [1].
>>>
>>> Some users of irq_alloc_generic_chip() are modules which can be
>>> removed (e.g. gpio-ml-ioh) but have no means of freeing the allocated
>>> generic chip.
>>>
>>> Last time it was suggested to provide irq_destroy_generic_chip() which
>>> would undo both irq_remove_generic_chip() and irq_alloc_generic_chip().
>>>
>>> This functionality is provided by patch 2/5 with 1/5 adding the option
>>> to only free the allocated memory.
>>>
>>> Patch 3/5 exports a function that will be used in the devres variant
>>> of irq_alloc_generic_chip().
>>>
>>> Patches 4/5 and 5/5 add resource managed versions of
>>> irq_alloc_generic_chip() & irq_setup_generic_chip(). They will be used
>>> in drivers where applicable. Device resources are released in reverse
>>> order so it's ok to call devm_irq_alloc_generic_chip() and then
>>> devm_irq_setup_generic_chip().
>>>
>>> [1] https://lkml.org/lkml/2017/3/8/550
>>>
>>> Bartosz Golaszewski (5):
>>>   irq: generic-chip: provide irq_free_generic_chip()
>>>   irq: generic-chip: provide irq_destroy_generic_chip()
>>>   irq: generic-chip: export irq_init_generic_chip() locally
>>>   irq: generic-chip: provide devm_irq_alloc_generic_chip()
>>>   irq: generic-chip: provide devm_irq_setup_generic_chip()
>>>
>>>  Documentation/driver-model/devres.txt |  2 +
>>>  include/linux/irq.h                   | 22 +++++++++
>>>  kernel/irq/devres.c                   | 86 +++++++++++++++++++++++++++++++++++
>>>  kernel/irq/generic-chip.c             |  7 ++-
>>>  kernel/irq/internals.h                | 11 +++++
>>>  5 files changed, 124 insertions(+), 4 deletions(-)
>>>
>>> --
>>> 2.9.3
>>>
>>
>> Ping for v4.13.
>>
>> Is there any reason not to merge it?
>
> There was a kbuild report from June 1st with worrying warnings on x86_64
> (though I couldn't see how that was related to these patches). What's
> the status of that?
>
> Thanks,
>
>         M.
> --
> Jazz is not dead. It just smells funny...

Snap, I looked at it, determined that it was just a header included in
include/linux/irq.h (unrelated to the patch) and forgot to comment
about it.

I've never seen this warning on my setup and don't see it now with rc6.

Thanks,
Bartosz

[toc] | [prev] | [next] | [standalone]


#1670815 — Re: [PATCH 0/5] irq: generic-chip: resource management improvements

FromThomas Gleixner <tglx@linutronix.de>
Date2017-06-20 16:20 +0200
SubjectRe: [PATCH 0/5] irq: generic-chip: resource management improvements
Message-ID<tUsaC-1fq-15@gated-at.bofh.it>
In reply to#1670661
On Tue, 20 Jun 2017, Bartosz Golaszewski wrote:
> 2017-06-20 12:41 GMT+02:00 Marc Zyngier <marc.zyngier@arm.com>:
> > There was a kbuild report from June 1st with worrying warnings on x86_64
> > (though I couldn't see how that was related to these patches). What's
> > the status of that?
> >
> > Thanks,
> >
> >         M.
> > --
> > Jazz is not dead. It just smells funny...
> 
> Snap, I looked at it, determined that it was just a header included in
> include/linux/irq.h (unrelated to the patch) and forgot to comment
> about it.
> 
> I've never seen this warning on my setup and don't see it now with rc6.

Yep, that's a genuine x86 snafu. No idea how that got attributed to your
patch.

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]


#1671601

FromBartosz Golaszewski <brgl@bgdev.pl>
Date2017-06-21 12:40 +0200
Message-ID<tULdg-4VV-21@gated-at.bofh.it>
In reply to#1670815
2017-06-20 16:14 GMT+02:00 Thomas Gleixner <tglx@linutronix.de>:
> On Tue, 20 Jun 2017, Bartosz Golaszewski wrote:
>> 2017-06-20 12:41 GMT+02:00 Marc Zyngier <marc.zyngier@arm.com>:
>> > There was a kbuild report from June 1st with worrying warnings on x86_64
>> > (though I couldn't see how that was related to these patches). What's
>> > the status of that?
>> >
>> > Thanks,
>> >
>> >         M.
>> > --
>> > Jazz is not dead. It just smells funny...
>>
>> Snap, I looked at it, determined that it was just a header included in
>> include/linux/irq.h (unrelated to the patch) and forgot to comment
>> about it.
>>
>> I've never seen this warning on my setup and don't see it now with rc6.
>
> Yep, that's a genuine x86 snafu. No idea how that got attributed to your
> patch.

So are the patches ok and can be merged for 4.13?

Thanks,
Bartosz

[toc] | [prev] | [next] | [standalone]


#1670663

FromMarc Zyngier <marc.zyngier@arm.com>
Date2017-06-20 12:50 +0200
Message-ID<tUoTn-7v0-3@gated-at.bofh.it>
In reply to#1670655
On 20/06/17 11:31, Bartosz Golaszewski wrote:
> 2017-05-31 18:06 GMT+02:00 Bartosz Golaszewski <brgl@bgdev.pl>:
>> This series is a follow-up to [1].
>>
>> Some users of irq_alloc_generic_chip() are modules which can be
>> removed (e.g. gpio-ml-ioh) but have no means of freeing the allocated
>> generic chip.
>>
>> Last time it was suggested to provide irq_destroy_generic_chip() which
>> would undo both irq_remove_generic_chip() and irq_alloc_generic_chip().
>>
>> This functionality is provided by patch 2/5 with 1/5 adding the option
>> to only free the allocated memory.
>>
>> Patch 3/5 exports a function that will be used in the devres variant
>> of irq_alloc_generic_chip().
>>
>> Patches 4/5 and 5/5 add resource managed versions of
>> irq_alloc_generic_chip() & irq_setup_generic_chip(). They will be used
>> in drivers where applicable. Device resources are released in reverse
>> order so it's ok to call devm_irq_alloc_generic_chip() and then
>> devm_irq_setup_generic_chip().
>>
>> [1] https://lkml.org/lkml/2017/3/8/550
>>
>> Bartosz Golaszewski (5):
>>   irq: generic-chip: provide irq_free_generic_chip()
>>   irq: generic-chip: provide irq_destroy_generic_chip()
>>   irq: generic-chip: export irq_init_generic_chip() locally
>>   irq: generic-chip: provide devm_irq_alloc_generic_chip()
>>   irq: generic-chip: provide devm_irq_setup_generic_chip()
>>
>>  Documentation/driver-model/devres.txt |  2 +
>>  include/linux/irq.h                   | 22 +++++++++
>>  kernel/irq/devres.c                   | 86 +++++++++++++++++++++++++++++++++++
>>  kernel/irq/generic-chip.c             |  7 ++-
>>  kernel/irq/internals.h                | 11 +++++
>>  5 files changed, 124 insertions(+), 4 deletions(-)
>>
>> --
>> 2.9.3
>>
> 
> Ping for v4.13.
> 
> Is there any reason not to merge it?

There was a kbuild report from June 1st with worrying warnings on x86_64
(though I couldn't see how that was related to these patches). What's
the status of that?

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web