All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa@the-dreams.de>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
	linux-input@vger.kernel.org,
	"Sébastien SZYMANSKI" <sebastien.szymanski@armadeus.com>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	linux-i2c@vger.kernel.org, "Rob Herring" <robh@kernel.org>
Subject: Re: Bug in i2c-core?
Date: Sun, 8 Mar 2015 09:26:17 +0100	[thread overview]
Message-ID: <20150308082617.GA1904@katana> (raw)
In-Reply-To: <20150304082237.GA2955@katana>

[-- Attachment #1: Type: text/plain, Size: 2466 bytes --]

On Wed, Mar 04, 2015 at 09:22:37AM +0100, Wolfram Sang wrote:
> 
> > > > I am writing an I2C touchscreen driver for an i.MX6 based board. I
> > > > compiled it as a module and when I unload it, I get the following warning:
> > > > 
> > > > # modprobe sx8654
> > > > [   46.261494] input: SX8654 I2C Touchscreen as
> > > > /devices/soc0/soc/2100000.aips-bus/21a0000.i2c/i2c-0/0-0048/input/input1
> > > > # rmmod sx8654
> > > > [   76.435223] ------------[ cut here ]------------
> > > > [   76.439909] WARNING: CPU: 0 PID: 134 at fs/proc/generic.c:552
> > > > remove_proc_entry+0x148/0x164()
> > > > [   76.448582] remove_proc_entry: removing non-empty directory
> > > > 'irq/208', leaking at least 'sx8654'
> > > 
> > > ...
> > > 
> > > > When I revert commit e4df3a0 (i2c: core: Dispose OF IRQ mapping at
> > > > client removal time) I don't get the warning.
> > > > 
> > > > Is this a bug in the i2c-core or am I doing something wrong in my driver?
> > > 
> > > Yes, this commit breaks all drivers using devm* for IRQ management on
> > > OF-based systemsi because devm* cleanup happens in device code, after
> > > bus's remove() method returns. I'd recommend reverting and finding a
> > > better way (making cleanup a custom devm action as well?).
> > 
> > Ouch, my bad.
> > 
> > Wolfram, any opinion ? The original patch fixes a real bug, so we shouldn't 
> > just revert it.
> 
> Looking at it some more: What bug does it fix? Anything you experienced?
> 
> I wonder if we really need e4df3a0 because I can't see where
> platform_get_irq, the major user of of_irq_get, disposes the mapping.
> irq_create_of_mapping() will return an already assigned mapping if
> called twice. I don't know yet, though, if mappings are static or if a
> mapping can be routed to another irq controller over some time because
> theoretically they can be dynamically added/removed.
> 
> Adding Rob to CC as he wrote of_irq_get and put it into
> platform_get_irq. Rob, we use of_irq_get() in the I2C core and the
> question is now if we need to dispose the mapping and if so what would
> be a good place for it so managed devices will not have their mappings
> removed before the managed irq is removed.

Ping. Just so you know: Without further information, I will revert the
patch in question around rc4/rc5. I'd still like to know if the
non-disposing of the mapping in platform_get_irq() is intentional.

Thanks,

   Wolfram


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: wsa@the-dreams.de (Wolfram Sang)
To: linux-arm-kernel@lists.infradead.org
Subject: Bug in i2c-core?
Date: Sun, 8 Mar 2015 09:26:17 +0100	[thread overview]
Message-ID: <20150308082617.GA1904@katana> (raw)
In-Reply-To: <20150304082237.GA2955@katana>

On Wed, Mar 04, 2015 at 09:22:37AM +0100, Wolfram Sang wrote:
> 
> > > > I am writing an I2C touchscreen driver for an i.MX6 based board. I
> > > > compiled it as a module and when I unload it, I get the following warning:
> > > > 
> > > > # modprobe sx8654
> > > > [   46.261494] input: SX8654 I2C Touchscreen as
> > > > /devices/soc0/soc/2100000.aips-bus/21a0000.i2c/i2c-0/0-0048/input/input1
> > > > # rmmod sx8654
> > > > [   76.435223] ------------[ cut here ]------------
> > > > [   76.439909] WARNING: CPU: 0 PID: 134 at fs/proc/generic.c:552
> > > > remove_proc_entry+0x148/0x164()
> > > > [   76.448582] remove_proc_entry: removing non-empty directory
> > > > 'irq/208', leaking at least 'sx8654'
> > > 
> > > ...
> > > 
> > > > When I revert commit e4df3a0 (i2c: core: Dispose OF IRQ mapping at
> > > > client removal time) I don't get the warning.
> > > > 
> > > > Is this a bug in the i2c-core or am I doing something wrong in my driver?
> > > 
> > > Yes, this commit breaks all drivers using devm* for IRQ management on
> > > OF-based systemsi because devm* cleanup happens in device code, after
> > > bus's remove() method returns. I'd recommend reverting and finding a
> > > better way (making cleanup a custom devm action as well?).
> > 
> > Ouch, my bad.
> > 
> > Wolfram, any opinion ? The original patch fixes a real bug, so we shouldn't 
> > just revert it.
> 
> Looking at it some more: What bug does it fix? Anything you experienced?
> 
> I wonder if we really need e4df3a0 because I can't see where
> platform_get_irq, the major user of of_irq_get, disposes the mapping.
> irq_create_of_mapping() will return an already assigned mapping if
> called twice. I don't know yet, though, if mappings are static or if a
> mapping can be routed to another irq controller over some time because
> theoretically they can be dynamically added/removed.
> 
> Adding Rob to CC as he wrote of_irq_get and put it into
> platform_get_irq. Rob, we use of_irq_get() in the I2C core and the
> question is now if we need to dispose the mapping and if so what would
> be a good place for it so managed devices will not have their mappings
> removed before the managed irq is removed.

Ping. Just so you know: Without further information, I will revert the
patch in question around rc4/rc5. I'd still like to know if the
non-disposing of the mapping in platform_get_irq() is intentional.

Thanks,

   Wolfram

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20150308/b1c806dc/attachment-0001.sig>

  reply	other threads:[~2015-03-08  8:26 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-02-27 11:09 Bug in i2c-core? Sébastien SZYMANSKI
2015-02-27 11:09 ` Sébastien SZYMANSKI
2015-02-27 14:37 ` Thomas Petazzoni
2015-02-27 14:37   ` Thomas Petazzoni
2015-02-27 15:29   ` Dmitry Torokhov
2015-02-27 15:29     ` Dmitry Torokhov
2015-02-27 17:05     ` Uwe Kleine-König
2015-02-27 17:05       ` Uwe Kleine-König
2015-02-27 17:46       ` Dmitry Torokhov
2015-02-27 17:46         ` Dmitry Torokhov
2015-02-27 18:39         ` Uwe Kleine-König
2015-02-27 18:39           ` Uwe Kleine-König
2015-02-28 10:00           ` Thomas Petazzoni
2015-02-28 10:00             ` Thomas Petazzoni
     [not found] ` <54F0507F.6030804-d2DlULPkwbNWk0Htik3J/w@public.gmane.org>
2015-02-27 16:59   ` Dmitry Torokhov
2015-02-27 16:59     ` Dmitry Torokhov
2015-02-27 17:01     ` Dmitry Torokhov
2015-02-27 17:01       ` Dmitry Torokhov
2015-03-03 22:03     ` Laurent Pinchart
2015-03-03 22:03       ` Laurent Pinchart
2015-03-04  6:47       ` Wolfram Sang
2015-03-04  6:47         ` Wolfram Sang
2015-03-04  8:22       ` Wolfram Sang
2015-03-04  8:22         ` Wolfram Sang
2015-03-08  8:26         ` Wolfram Sang [this message]
2015-03-08  8:26           ` Wolfram Sang
2015-03-10  0:21           ` Laurent Pinchart
2015-03-10  0:21             ` Laurent Pinchart
2015-03-12  9:35             ` Wolfram Sang
2015-03-12  9:35               ` Wolfram Sang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20150308082617.GA1904@katana \
    --to=wsa@the-dreams.de \
    --cc=dmitry.torokhov@gmail.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-input@vger.kernel.org \
    --cc=robh@kernel.org \
    --cc=sebastien.szymanski@armadeus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.