* Re: [alsa-devel] [PATCH] ASoC: wm8962: Convert to devm_input_allocate_device() [not found] ` <20130429101959.GE5019@opensource.wolfsonmicro.com> @ 2013-04-29 17:47 ` Leon Romanovsky 2013-04-29 18:07 ` Dmitry Torokhov 0 siblings, 1 reply; 5+ messages in thread From: Leon Romanovsky @ 2013-04-29 17:47 UTC (permalink / raw) To: Mark Brown, Dmitry Torokhov Cc: alsa-devel@alsa-project.org, patches, linux-input On Mon, Apr 29, 2013 at 1:19 PM, Mark Brown <broonie@kernel.org> wrote: > On Sun, Apr 28, 2013 at 09:32:18PM +0300, Leon Romanovsky wrote: > >> I think the reason of our misunderstanding is due to the name of >> input_free_device call. From the code, it is device destroy function, >> and the freeing itself done as an error handling of >> input_register_device >> (http://lxr.free-electrons.com/source/drivers/input/input.c#L2114). > >> How do you think we need to proceed? Do I need to send patches with >> explicit call to input_free_device function? > > I really think the input API needs to be looked at here, this is all way > too error prone. Calling input_free_device() on something allocated > using devm_ looks like an error itself... In general, I agree with you, but I think we both agree that the current patch is not working as expected. The problem is that you allocated device with devm_ and later at the code you tried to register it, but failed. In this case no one will call to devres_destroy, because it is done at unregister stage only. I see two possible solutions: 1. short one - fix your patches 2. long one - add input_free_device code into input_register_device call (http://lxr.free-electrons.com/source/drivers/input/input.c#L2114). -- Leon Romanovsky | Independent Linux Consultant www.leon.nu | leon@leon.nu ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [alsa-devel] [PATCH] ASoC: wm8962: Convert to devm_input_allocate_device() 2013-04-29 17:47 ` [alsa-devel] [PATCH] ASoC: wm8962: Convert to devm_input_allocate_device() Leon Romanovsky @ 2013-04-29 18:07 ` Dmitry Torokhov 2013-04-29 18:19 ` Dmitry Torokhov 0 siblings, 1 reply; 5+ messages in thread From: Dmitry Torokhov @ 2013-04-29 18:07 UTC (permalink / raw) To: Leon Romanovsky Cc: Mark Brown, alsa-devel@alsa-project.org, patches, linux-input On Mon, Apr 29, 2013 at 08:47:37PM +0300, Leon Romanovsky wrote: > On Mon, Apr 29, 2013 at 1:19 PM, Mark Brown <broonie@kernel.org> wrote: > > On Sun, Apr 28, 2013 at 09:32:18PM +0300, Leon Romanovsky wrote: > > > >> I think the reason of our misunderstanding is due to the name of > >> input_free_device call. From the code, it is device destroy function, > >> and the freeing itself done as an error handling of > >> input_register_device > >> (http://lxr.free-electrons.com/source/drivers/input/input.c#L2114). > > > >> How do you think we need to proceed? Do I need to send patches with > >> explicit call to input_free_device function? > > > > I really think the input API needs to be looked at here, this is all way > > too error prone. Calling input_free_device() on something allocated > > using devm_ looks like an error itself... > In general, I agree with you, but I think we both agree that the > current patch is not working as expected. > The problem is that you allocated device with devm_ and later at the > code you tried to register it, but failed. In this case no one will > call to devres_destroy, because it is done at unregister stage only. > > I see two possible solutions: > 1. short one - fix your patches > 2. long one - add input_free_device code into input_register_device > call (http://lxr.free-electrons.com/source/drivers/input/input.c#L2114). > The rules are pretty straightforward: 1. If you are using devm_input_allocate_device() you do not need to call input_free_device() nor input_unregister_device() - the core will create a devres structure for freeing the device and if input_register_device() succeeds it will also add a 2nd devres for unregistering. This way the "normal" unwind is a 2-step process with device is "half alive" and being able to survive input_event() calls from IRQ handlers if they are still alive. IOW it should all "just work". 2. If you are using input_allocate_device() then you need to call input_free_device() until you called input_register_device(), afterward input_unregister_device() should be called. Thanks. -- Dmitry ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [alsa-devel] [PATCH] ASoC: wm8962: Convert to devm_input_allocate_device() 2013-04-29 18:07 ` Dmitry Torokhov @ 2013-04-29 18:19 ` Dmitry Torokhov 2013-04-29 18:52 ` Leon Romanovsky 0 siblings, 1 reply; 5+ messages in thread From: Dmitry Torokhov @ 2013-04-29 18:19 UTC (permalink / raw) To: Leon Romanovsky Cc: Mark Brown, alsa-devel@alsa-project.org, patches, linux-input On Mon, Apr 29, 2013 at 11:07:28AM -0700, Dmitry Torokhov wrote: > On Mon, Apr 29, 2013 at 08:47:37PM +0300, Leon Romanovsky wrote: > > On Mon, Apr 29, 2013 at 1:19 PM, Mark Brown <broonie@kernel.org> wrote: > > > On Sun, Apr 28, 2013 at 09:32:18PM +0300, Leon Romanovsky wrote: > > > > > >> I think the reason of our misunderstanding is due to the name of > > >> input_free_device call. From the code, it is device destroy function, > > >> and the freeing itself done as an error handling of > > >> input_register_device > > >> (http://lxr.free-electrons.com/source/drivers/input/input.c#L2114). > > > > > >> How do you think we need to proceed? Do I need to send patches with > > >> explicit call to input_free_device function? > > > > > > I really think the input API needs to be looked at here, this is all way > > > too error prone. Calling input_free_device() on something allocated > > > using devm_ looks like an error itself... > > In general, I agree with you, but I think we both agree that the > > current patch is not working as expected. > > The problem is that you allocated device with devm_ and later at the > > code you tried to register it, but failed. In this case no one will > > call to devres_destroy, because it is done at unregister stage only. > > > > I see two possible solutions: > > 1. short one - fix your patches > > 2. long one - add input_free_device code into input_register_device > > call (http://lxr.free-electrons.com/source/drivers/input/input.c#L2114). > > > > The rules are pretty straightforward: > > 1. If you are using devm_input_allocate_device() you do not need to call > input_free_device() nor input_unregister_device() - the core will > create a devres structure for freeing the device and if > input_register_device() succeeds it will also add a 2nd devres for > unregistering. This way the "normal" unwind is a 2-step process with > device is "half alive" and being able to survive input_event() calls > from IRQ handlers if they are still alive. > > IOW it should all "just work". > > 2. If you are using input_allocate_device() then you need to call > input_free_device() until you called input_register_device(), afterward > input_unregister_device() should be called. > BTW, looking at Marks patch it looks good to me. -- Dmitry ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [alsa-devel] [PATCH] ASoC: wm8962: Convert to devm_input_allocate_device() 2013-04-29 18:19 ` Dmitry Torokhov @ 2013-04-29 18:52 ` Leon Romanovsky 2013-04-29 20:01 ` Mark Brown 0 siblings, 1 reply; 5+ messages in thread From: Leon Romanovsky @ 2013-04-29 18:52 UTC (permalink / raw) To: Dmitry Torokhov Cc: Mark Brown, alsa-devel@alsa-project.org, patches, linux-input On Mon, Apr 29, 2013 at 9:19 PM, Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote: > On Mon, Apr 29, 2013 at 11:07:28AM -0700, Dmitry Torokhov wrote: >> On Mon, Apr 29, 2013 at 08:47:37PM +0300, Leon Romanovsky wrote: >> > On Mon, Apr 29, 2013 at 1:19 PM, Mark Brown <broonie@kernel.org> wrote: >> > > On Sun, Apr 28, 2013 at 09:32:18PM +0300, Leon Romanovsky wrote: >> > > >> > >> I think the reason of our misunderstanding is due to the name of >> > >> input_free_device call. From the code, it is device destroy function, >> > >> and the freeing itself done as an error handling of >> > >> input_register_device >> > >> (http://lxr.free-electrons.com/source/drivers/input/input.c#L2114). >> > > >> > >> How do you think we need to proceed? Do I need to send patches with >> > >> explicit call to input_free_device function? >> > > >> > > I really think the input API needs to be looked at here, this is all way >> > > too error prone. Calling input_free_device() on something allocated >> > > using devm_ looks like an error itself... >> > In general, I agree with you, but I think we both agree that the >> > current patch is not working as expected. >> > The problem is that you allocated device with devm_ and later at the >> > code you tried to register it, but failed. In this case no one will >> > call to devres_destroy, because it is done at unregister stage only. >> > >> > I see two possible solutions: >> > 1. short one - fix your patches >> > 2. long one - add input_free_device code into input_register_device >> > call (http://lxr.free-electrons.com/source/drivers/input/input.c#L2114). >> > >> >> The rules are pretty straightforward: >> >> 1. If you are using devm_input_allocate_device() you do not need to call >> input_free_device() nor input_unregister_device() - the core will >> create a devres structure for freeing the device and if >> input_register_device() succeeds it will also add a 2nd devres for >> unregistering. This way the "normal" unwind is a 2-step process with >> device is "half alive" and being able to survive input_event() calls >> from IRQ handlers if they are still alive. >> >> IOW it should all "just work". >> >> 2. If you are using input_allocate_device() then you need to call >> input_free_device() until you called input_register_device(), afterward >> input_unregister_device() should be called. >> > > BTW, looking at Marks patch it looks good to me. Dmitry, thanks for the explanation. Mark, please take my apologies, I was mislead by the following comment on the code: http://lxr.free-electrons.com/source/drivers/input/input.c#L1825 1822 * input_free_device - free memory occupied by input_dev structure 1823 * @dev: input device to free 1824 * 1825 * This function should only be used if input_register_device() 1826 * was not called yet or if it failed. > > -- > Dmitry -- Leon Romanovsky | Independent Linux Consultant www.leon.nu | leon@leon.nu ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] ASoC: wm8962: Convert to devm_input_allocate_device() 2013-04-29 18:52 ` Leon Romanovsky @ 2013-04-29 20:01 ` Mark Brown 0 siblings, 0 replies; 5+ messages in thread From: Mark Brown @ 2013-04-29 20:01 UTC (permalink / raw) To: Leon Romanovsky Cc: alsa-devel@alsa-project.org, Dmitry Torokhov, patches, linux-input [-- Attachment #1.1: Type: text/plain, Size: 214 bytes --] On Mon, Apr 29, 2013 at 09:52:34PM +0300, Leon Romanovsky wrote: > Mark, please take my apologies, I was mislead by the following comment > on the code: No problem, thanks for taking the time to check into this. [-- Attachment #1.2: Digital signature --] [-- Type: application/pgp-signature, Size: 836 bytes --] [-- Attachment #2: Type: text/plain, Size: 0 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-04-29 20:01 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <1356009506-4766-1-git-send-email-broonie@opensource.wolfsonmicro.com>
[not found] ` <CALq1K=+sJUZ++_sMkU1Sg9+aE-HpF1tnfPHGCEJ789hj19Yp9A@mail.gmail.com>
[not found] ` <20130425125234.GV5019@opensource.wolfsonmicro.com>
[not found] ` <CALq1K=+ViDvsCZDR5KndX-T1Dt6tghPjiP7F6wm+npYOw2DE1A@mail.gmail.com>
[not found] ` <20130428094745.GA5877@sirena.org.uk>
[not found] ` <CALq1K=+=J9oPGvbrXuhS=Bgqj+viC5EAkTHKkNuHxBadExpXdA@mail.gmail.com>
[not found] ` <20130429101959.GE5019@opensource.wolfsonmicro.com>
2013-04-29 17:47 ` [alsa-devel] [PATCH] ASoC: wm8962: Convert to devm_input_allocate_device() Leon Romanovsky
2013-04-29 18:07 ` Dmitry Torokhov
2013-04-29 18:19 ` Dmitry Torokhov
2013-04-29 18:52 ` Leon Romanovsky
2013-04-29 20:01 ` Mark Brown
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).