* Bug in i2c-core?
@ 2015-02-27 11:09 Sébastien SZYMANSKI
2015-02-27 14:37 ` Thomas Petazzoni
2015-02-27 16:59 ` Dmitry Torokhov
0 siblings, 2 replies; 15+ messages in thread
From: Sébastien SZYMANSKI @ 2015-02-27 11:09 UTC (permalink / raw)
To: linux-arm-kernel
Hi,
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'
[ 76.457445] Modules linked in: sx8654(-)
[ 76.461452] CPU: 0 PID: 134 Comm: rmmod Not tainted
4.0.0-rc1-00002-g30f95ab-dirty #6
[ 76.469380] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 76.475977] Backtrace:
[ 76.478504] [<80012638>] (dump_backtrace) from [<80012854>]
(show_stack+0x18/0x1c)
[ 76.486164] r7:80151e04 r6:809dd4b0 r5:00000000 r4:00000000
[ 76.491990] [<8001283c>] (show_stack) from [<806ea6cc>]
(dump_stack+0x8c/0xa4)
[ 76.499340] [<806ea640>] (dump_stack) from [<8002add4>]
(warn_slowpath_common+0x7c/0xb8)
[ 76.507509] r7:80151e04 r6:00000228 r5:00000009 r4:bdacbdb8
[ 76.513311] [<8002ad58>] (warn_slowpath_common) from [<8002ae48>]
(warn_slowpath_fmt+0x38/0x40)
[ 76.522110] r8:8000ee04 r7:809d1360 r6:be038e80 r5:be038ef5 r4:80898a18
[ 76.529027] [<8002ae14>] (warn_slowpath_fmt) from [<80151e04>]
(remove_proc_entry+0x148/0x164)
[ 76.537728] r3:806fa800 r2:80898a18
[ 76.541385] r4:bda01e80
[ 76.543983] [<80151cbc>] (remove_proc_entry) from [<80076390>]
(unregister_irq_proc+0x94/0xb8)
[ 76.552715] r6:000000d0 r5:8120edb8 r4:be0c1100
[ 76.557485] [<800762fc>] (unregister_irq_proc) from [<8006ee50>]
(free_desc+0x34/0x6c)
[ 76.565450] r6:000000d0 r5:809d1354 r4:be0c1100
[ 76.570127] [<8006ee1c>] (free_desc) from [<8006eed0>]
(irq_free_descs+0x48/0x84)
[ 76.577636] r7:00000001 r6:000000d0 r5:000000d1 r4:000000d1
[ 76.583383] [<8006ee88>] (irq_free_descs) from [<80075308>]
(irq_dispose_mapping+0x40/0x5c)
[ 76.591761] r7:00000081 r6:be1cb454 r5:be1cb420 r4:000000d0
[ 76.597519] [<800752c8>] (irq_dispose_mapping) from [<804b18b4>]
(i2c_device_remove+0x68/0x88)
[ 76.606178] r5:be1cb420 r4:00000000
[ 76.609806] [<804b184c>] (i2c_device_remove) from [<8039ecf0>]
(__device_release_driver+0x78/0xcc)
[ 76.618810] r5:7f000784 r4:be1cb420
[ 76.622432] [<8039ec78>] (__device_release_driver) from [<8039f468>]
(driver_detach+0xbc/0xc0)
[ 76.631068] r5:7f000784 r4:be1cb420
[ 76.634720] [<8039f3ac>] (driver_detach) from [<8039ea18>]
(bus_remove_driver+0x54/0xa8)
[ 76.642814] r7:00000081 r6:00003435 r5:7ee68a78 r4:7f000784
[ 76.648570] [<8039e9c4>] (bus_remove_driver) from [<8039fac8>]
(driver_unregister+0x30/0x50)
[ 76.657056] r5:7ee68a78 r4:7f000784
[ 76.660679] [<8039fa98>] (driver_unregister) from [<804b2aa0>]
(i2c_del_driver+0x20/0x28)
[ 76.668893] r5:7ee68a78 r4:7f000768
[ 76.672522] [<804b2a80>] (i2c_del_driver) from [<7f000448>]
(sx8654_driver_exit+0x14/0x1c [sx8654])
[ 76.681593] r5:7ee68a78 r4:7f0007d4
[ 76.685257] [<7f000434>] (sx8654_driver_exit [sx8654]) from
[<800967e8>] (SyS_delete_module+0x120/0x1c4)
[ 76.694773] [<800966c8>] (SyS_delete_module) from [<8000ec40>]
(ret_fast_syscall+0x0/0x4c)
[ 76.703058] r5:36387873 r4:00025014
[ 76.706691] ---[ end trace c92a3e03b1c63abc ]---
My driver is similar to other touchscreen drivers, i.e. ar1021_i2c.c.
/*
* drivers/input/touchscreen/sx8654.c
*
* Copyright (c) 2015 Armadeus Systems
* S?bastien Szymanski <sebastien.szymanski@armadeus.com>
*
* Using code from:
* - sx865x.c
* Copyright (c) 2013 U-MoBo Srl
* Pierluigi Passaro <p.passaro@u-mobo.com>
* - sx8650.c
* Copyright (c) 2009 Wayne Roberts
* - tsc2007.c
* Copyright (c) 2008 Kwangwoo Lee
* - ads7846.c
* Copyright (c) 2005 David Brownell
* Copyright (c) 2006 Nokia Corporation
* - corgi_ts.c
* Copyright (C) 2004-2005 Richard Purdie
* - omap_ts.[hc], ads7846.h, ts_osk.c
* Copyright (C) 2002 MontaVista Software
* Copyright (C) 2004 Texas Instruments
* Copyright (C) 2005 Dirk Behme
*
* 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 <linux/module.h>
#include <linux/input.h>
#include <linux/of.h>
#include <linux/i2c.h>
#include <linux/irq.h>
#include <linux/interrupt.h>
/* register addresses */
#define I2C_REG_TOUCH0 0x00
#define I2C_REG_TOUCH1 0x01
#define I2C_REG_CHANMASK 0x04
#define I2C_REG_IRQMASK 0x22
#define I2C_REG_IRQSRC 0x23
#define I2C_REG_SOFTRESET 0x3f
/* commands */
#define CMD_READ_REGISTER 0x40
#define CMD_MANUAL 0xc0
#define CMD_PENTRG 0xe0
/* value for I2C_REG_SOFTRESET */
#define SOFTRESET_VALUE 0xde
/* bits for I2C_REG_IRQSRC */
#define IRQ_PENTOUCH_TOUCHCONVDONE 0x08
#define IRQ_PENRELEASE 0x04
/* bits for RegTouch1 */
#define CONDIRQ 0x20
#define FILT_7SA 0x03
/* bits for I2C_REG_CHANMASK */
#define CONV_X 0x80
#define CONV_Y 0x40
/* coordinates rate: higher nibble of CTRL0 register */
#define RATE_MANUAL 0x00
#define RATE_5000CPS 0xf0
/* power delay: lower nibble of CTRL0 register */
#define POWDLY_IMMEDIATE 0x00
#define POWDLY_1_1MS 0x0b
#define MAX_12BIT ((1 << 12) - 1)
struct sx8654 {
struct input_dev *input;
struct i2c_client *client;
};
static irqreturn_t sx8654_irq(int irq, void *handle)
{
struct sx8654 *sx8654 = handle;
u8 irqsrc;
u8 data[4];
unsigned int x, y;
int retval;
irqsrc = i2c_smbus_read_byte_data(sx8654->client,
(CMD_READ_REGISTER |
I2C_REG_IRQSRC));
dev_dbg(&sx8654->client->dev, "irqsrc = 0x%x", irqsrc);
if (irqsrc < 0)
goto out;
if (irqsrc & IRQ_PENRELEASE) {
dev_dbg(&sx8654->client->dev, "pen release interrupt");
input_report_key(sx8654->input, BTN_TOUCH, 0);
input_sync(sx8654->input);
}
if (irqsrc & IRQ_PENTOUCH_TOUCHCONVDONE) {
dev_dbg(&sx8654->client->dev, "pen touch interrupt");
retval = i2c_master_recv(sx8654->client, data,
sizeof(data));
if (retval != sizeof(data))
goto out;
/* invalid data */
if (unlikely(data[0] & 0x80 || data[2] & 0x80))
goto out;
x = ((data[0] & 0xf) << 8) | (data[1]);
y = ((data[2] & 0xf) << 8) | (data[3]);
input_report_abs(sx8654->input, ABS_X, x);
input_report_abs(sx8654->input, ABS_Y, y);
input_report_key(sx8654->input, BTN_TOUCH, 1);
input_sync(sx8654->input);
dev_dbg(&sx8654->client->dev, "point(%4d,%4d)\n", x, y);
}
out:
return IRQ_HANDLED;
}
static int sx8654_open(struct input_dev *dev)
{
struct sx8654 *sx8654 = input_get_drvdata(dev);
struct i2c_client *client = sx8654->client;
int error;
/* enable pen trigger mode */
error = i2c_smbus_write_byte_data(client, I2C_REG_TOUCH0,
(RATE_5000CPS | POWDLY_1_1MS));
if (error < 0) {
dev_err(&client->dev, "writing to I2C_REG_TOUCH0 failed");
return -EIO;
}
error = i2c_smbus_write_byte(client, CMD_PENTRG);
if (error < 0) {
dev_err(&client->dev, "writing command CMD_PENTRG failed");
return -EIO;
}
enable_irq(client->irq);
return 0;
}
static void sx8654_close(struct input_dev *dev)
{
struct sx8654 *sx8654 = input_get_drvdata(dev);
struct i2c_client *client = sx8654->client;
int error;
disable_irq(client->irq);
/* enable manual mode mode */
error = i2c_smbus_write_byte(client, CMD_MANUAL);
if (error < 0) {
dev_err(&client->dev, "writing command CMD_MANUAL failed");
return;
}
error = i2c_smbus_write_byte_data(client, I2C_REG_TOUCH0, 0);
if (error < 0) {
dev_err(&client->dev, "writing to I2C_REG_TOUCH0 failed");
return;
}
}
static int sx8654_probe(struct i2c_client *client,
const struct i2c_device_id *id)
{
struct sx8654 *sx8654;
struct input_dev *input;
int error;
if (!i2c_check_functionality(client->adapter,
I2C_FUNC_SMBUS_READ_WORD_DATA))
return -ENXIO;
sx8654 = devm_kzalloc(&client->dev, sizeof(*sx8654), GFP_KERNEL);
if (!sx8654)
return -ENOMEM;
input = devm_input_allocate_device(&client->dev);
if (!sx8654)
return -ENOMEM;
input->name = "SX8654 I2C Touchscreen";
input->id.bustype = BUS_I2C;
input->dev.parent = &client->dev;
input->open = sx8654_open;
input->close = sx8654_close;
__set_bit(INPUT_PROP_DIRECT, input->propbit);
input_set_capability(input, EV_KEY, BTN_TOUCH);
input_set_abs_params(input, ABS_X, 0, MAX_12BIT, 0, 0);
input_set_abs_params(input, ABS_Y, 0, MAX_12BIT, 0, 0);
sx8654->client = client;
sx8654->input = input;
input_set_drvdata(sx8654->input, sx8654);
error = i2c_smbus_write_byte_data(client, I2C_REG_SOFTRESET,
SOFTRESET_VALUE);
if (error < 0) {
dev_err(&client->dev, "writing softreset value failed");
return -EIO;
}
error = i2c_smbus_write_byte_data(client, I2C_REG_CHANMASK,
(CONV_X | CONV_Y));
if (error < 0) {
dev_err(&client->dev, "writing to I2C_REG_CHANMASK failed");
return -EIO;
}
error = i2c_smbus_write_byte_data(client, I2C_REG_IRQMASK,
(IRQ_PENTOUCH_TOUCHCONVDONE |
IRQ_PENRELEASE));
if (error < 0) {
dev_err(&client->dev, "writing to I2C_REG_IRQMASK failed");
return -EIO;
}
error = i2c_smbus_write_byte_data(client, I2C_REG_TOUCH1,
(CONDIRQ | FILT_7SA));
if (error < 0) {
dev_err(&client->dev, "writing to I2C_REG_TOUCH1 failed");
return -EIO;
}
error = devm_request_threaded_irq(&client->dev, client->irq,
NULL, sx8654_irq,
IRQF_TRIGGER_FALLING |
IRQF_ONESHOT,
client->name, sx8654);
if (error) {
dev_err(&client->dev,
"Failed to enable IRQ %d, error: %d\n",
client->irq, error);
return error;
}
/* Disable the IRQ, we'll enable it in sx8654_open() */
disable_irq(client->irq);
error = input_register_device(sx8654->input);
if (error)
return error;
i2c_set_clientdata(client, sx8654);
return 0;
}
static const struct of_device_id sx8654_of_match[] = {
{ .compatible = "semtech,sx8654", },
{ },
};
MODULE_DEVICE_TABLE(of, sx8654_of_match);
static const struct i2c_device_id sx8654_id_table[] = {
{ "semtech_sx8654", 0 },
{ },
};
MODULE_DEVICE_TABLE(i2c, sx8654_id_table);
static struct i2c_driver sx8654_driver = {
.driver = {
.name = "sx8654",
.owner = THIS_MODULE,
.of_match_table = sx8654_of_match,
},
.id_table = sx8654_id_table,
.probe = sx8654_probe,
};
module_i2c_driver(sx8654_driver);
MODULE_AUTHOR("S?bastien Szymanski <sebastien.szymanski@armadeus.com>");
MODULE_DESCRIPTION("Semtech SX8654 I2C Touchscreen Driver");
MODULE_LICENSE("GPL");
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?
--
S?bastien SZYMANSKI
^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug in i2c-core?
2015-02-27 11:09 Bug in i2c-core? Sébastien SZYMANSKI
@ 2015-02-27 14:37 ` Thomas Petazzoni
2015-02-27 15:29 ` Dmitry Torokhov
2015-02-27 16:59 ` Dmitry Torokhov
1 sibling, 1 reply; 15+ messages in thread
From: Thomas Petazzoni @ 2015-02-27 14:37 UTC (permalink / raw)
To: linux-arm-kernel
Dear S?bastien SZYMANSKI,
On Fri, 27 Feb 2015 12:09:51 +0100, S?bastien SZYMANSKI wrote:
> error = input_register_device(sx8654->input);
> if (error)
> return error;
Where is your ->remove() function that unregisters the input device?
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug in i2c-core?
2015-02-27 14:37 ` Thomas Petazzoni
@ 2015-02-27 15:29 ` Dmitry Torokhov
2015-02-27 17:05 ` Uwe Kleine-König
0 siblings, 1 reply; 15+ messages in thread
From: Dmitry Torokhov @ 2015-02-27 15:29 UTC (permalink / raw)
To: linux-arm-kernel
On February 27, 2015 6:37:25 AM PST, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
>Dear S?bastien SZYMANSKI,
>
>On Fri, 27 Feb 2015 12:09:51 +0100, S?bastien SZYMANSKI wrote:
>
>> error = input_register_device(sx8654->input);
>> if (error)
>> return error;
>
>Where is your ->remove() function that unregisters the input device?
Everything seems to be allocated with devm so remove is not needed.
Thanks.
--
Dmitry
^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug in i2c-core?
2015-02-27 11:09 Bug in i2c-core? Sébastien SZYMANSKI
2015-02-27 14:37 ` Thomas Petazzoni
@ 2015-02-27 16:59 ` Dmitry Torokhov
2015-02-27 17:01 ` Dmitry Torokhov
2015-03-03 22:03 ` Laurent Pinchart
1 sibling, 2 replies; 15+ messages in thread
From: Dmitry Torokhov @ 2015-02-27 16:59 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Feb 27, 2015 at 12:09:51PM +0100, S?bastien SZYMANSKI wrote:
> Hi,
>
> 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?).
Thanks.
--
Dmitry
^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug in i2c-core?
2015-02-27 16:59 ` Dmitry Torokhov
@ 2015-02-27 17:01 ` Dmitry Torokhov
2015-03-03 22:03 ` Laurent Pinchart
1 sibling, 0 replies; 15+ messages in thread
From: Dmitry Torokhov @ 2015-02-27 17:01 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Feb 27, 2015 at 08:59:44AM -0800, Dmitry Torokhov wrote:
> On Fri, Feb 27, 2015 at 12:09:51PM +0100, S?bastien SZYMANSKI wrote:
> > Hi,
> >
> > 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?).
>
Also it seems that the original patch is incomplete as I do not see us
disposing the mapping when probe fails...
--
Dmitry
^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug in i2c-core?
2015-02-27 15:29 ` Dmitry Torokhov
@ 2015-02-27 17:05 ` Uwe Kleine-König
2015-02-27 17:46 ` Dmitry Torokhov
0 siblings, 1 reply; 15+ messages in thread
From: Uwe Kleine-König @ 2015-02-27 17:05 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Feb 27, 2015 at 07:29:30AM -0800, Dmitry Torokhov wrote:
> On February 27, 2015 6:37:25 AM PST, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> >Dear S?bastien SZYMANSKI,
> >
> >On Fri, 27 Feb 2015 12:09:51 +0100, S?bastien SZYMANSKI wrote:
> >
> >> error = input_register_device(sx8654->input);
> >> if (error)
> >> return error;
> >
> >Where is your ->remove() function that unregisters the input device?
>
> Everything seems to be allocated with devm so remove is not needed.
Everything is devm_* but input_register_device, right?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug in i2c-core?
2015-02-27 17:05 ` Uwe Kleine-König
@ 2015-02-27 17:46 ` Dmitry Torokhov
2015-02-27 18:39 ` Uwe Kleine-König
0 siblings, 1 reply; 15+ messages in thread
From: Dmitry Torokhov @ 2015-02-27 17:46 UTC (permalink / raw)
To: linux-arm-kernel
On Fri, Feb 27, 2015 at 06:05:45PM +0100, Uwe Kleine-K?nig wrote:
> On Fri, Feb 27, 2015 at 07:29:30AM -0800, Dmitry Torokhov wrote:
> > On February 27, 2015 6:37:25 AM PST, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> > >Dear S?bastien SZYMANSKI,
> > >
> > >On Fri, 27 Feb 2015 12:09:51 +0100, S?bastien SZYMANSKI wrote:
> > >
> > >> error = input_register_device(sx8654->input);
> > >> if (error)
> > >> return error;
> > >
> > >Where is your ->remove() function that unregisters the input device?
> >
> > Everything seems to be allocated with devm so remove is not needed.
> Everything is devm_* but input_register_device, right?
Input is allocated with devm_* and input_register_device knows how to
deal with that:
/**
* devm_input_allocate_device - allocate managed input device
* @dev: device owning the input device being created
*
* Returns prepared struct input_dev or %NULL.
*
* Managed input devices do not need to be explicitly unregistered or
* freed as it will be done automatically when owner device unbinds from
* its driver (or binding fails). Once managed input device is
* allocated,
* it is ready to be set up and registered in the same fashion as
* regular
* input device. There are no special devm_input_device_[un]register()
* variants, regular ones work with both managed and unmanaged devices,
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
* should you need them. In most cases however, managed input device
* need
* not be explicitly unregistered or freed.
*
* NOTE: the owner device is set up as parent of input device and users
* should not override it.
*/
Thanks.
--
Dmitry
^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug in i2c-core?
2015-02-27 17:46 ` Dmitry Torokhov
@ 2015-02-27 18:39 ` Uwe Kleine-König
2015-02-28 10:00 ` Thomas Petazzoni
0 siblings, 1 reply; 15+ messages in thread
From: Uwe Kleine-König @ 2015-02-27 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Hello,
On Fri, Feb 27, 2015 at 09:46:11AM -0800, Dmitry Torokhov wrote:
> On Fri, Feb 27, 2015 at 06:05:45PM +0100, Uwe Kleine-K?nig wrote:
> > On Fri, Feb 27, 2015 at 07:29:30AM -0800, Dmitry Torokhov wrote:
> > > On February 27, 2015 6:37:25 AM PST, Thomas Petazzoni <thomas.petazzoni@free-electrons.com> wrote:
> > > >Dear S?bastien SZYMANSKI,
> > > >
> > > >On Fri, 27 Feb 2015 12:09:51 +0100, S?bastien SZYMANSKI wrote:
> > > >
> > > >> error = input_register_device(sx8654->input);
> > > >> if (error)
> > > >> return error;
> > > >
> > > >Where is your ->remove() function that unregisters the input device?
> > >
> > > Everything seems to be allocated with devm so remove is not needed.
> > Everything is devm_* but input_register_device, right?
>
> Input is allocated with devm_* and input_register_device knows how to
> deal with that:
ah, something new each day. Thanks for teaching me.
Uwe
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug in i2c-core?
2015-02-27 18:39 ` Uwe Kleine-König
@ 2015-02-28 10:00 ` Thomas Petazzoni
0 siblings, 0 replies; 15+ messages in thread
From: Thomas Petazzoni @ 2015-02-28 10:00 UTC (permalink / raw)
To: linux-arm-kernel
Dmitry, Uwe,
On Fri, 27 Feb 2015 19:39:49 +0100, Uwe Kleine-K?nig wrote:
> > Input is allocated with devm_* and input_register_device knows how to
> > deal with that:
> ah, something new each day. Thanks for teaching me.
Thanks as well, I also discovered that thanks to this discussion.
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug in i2c-core?
2015-02-27 16:59 ` Dmitry Torokhov
2015-02-27 17:01 ` Dmitry Torokhov
@ 2015-03-03 22:03 ` Laurent Pinchart
2015-03-04 6:47 ` Wolfram Sang
2015-03-04 8:22 ` Wolfram Sang
1 sibling, 2 replies; 15+ messages in thread
From: Laurent Pinchart @ 2015-03-03 22:03 UTC (permalink / raw)
To: linux-arm-kernel
Hi Dmitry,
On Friday 27 February 2015 08:59:44 Dmitry Torokhov wrote:
> On Fri, Feb 27, 2015 at 12:09:51PM +0100, S?bastien SZYMANSKI wrote:
> > Hi,
> >
> > 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.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug in i2c-core?
2015-03-03 22:03 ` Laurent Pinchart
@ 2015-03-04 6:47 ` Wolfram Sang
2015-03-04 8:22 ` Wolfram Sang
1 sibling, 0 replies; 15+ messages in thread
From: Wolfram Sang @ 2015-03-04 6:47 UTC (permalink / raw)
To: linux-arm-kernel
> > 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.
I guess the usual rules apply. Let's try to fix it for v4.0, otherwise I
have to revert it.
-------------- 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/20150304/3ee92e4f/attachment.sig>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug in i2c-core?
2015-03-03 22:03 ` Laurent Pinchart
2015-03-04 6:47 ` Wolfram Sang
@ 2015-03-04 8:22 ` Wolfram Sang
2015-03-08 8:26 ` Wolfram Sang
1 sibling, 1 reply; 15+ messages in thread
From: Wolfram Sang @ 2015-03-04 8:22 UTC (permalink / raw)
To: linux-arm-kernel
> > > 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.
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/20150304/dd0ff6fd/attachment-0001.sig>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug in i2c-core?
2015-03-04 8:22 ` Wolfram Sang
@ 2015-03-08 8:26 ` Wolfram Sang
2015-03-10 0:21 ` Laurent Pinchart
0 siblings, 1 reply; 15+ messages in thread
From: Wolfram Sang @ 2015-03-08 8:26 UTC (permalink / raw)
To: linux-arm-kernel
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>
^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug in i2c-core?
2015-03-08 8:26 ` Wolfram Sang
@ 2015-03-10 0:21 ` Laurent Pinchart
2015-03-12 9:35 ` Wolfram Sang
0 siblings, 1 reply; 15+ messages in thread
From: Laurent Pinchart @ 2015-03-10 0:21 UTC (permalink / raw)
To: linux-arm-kernel
Hi Wolfram,
On Sunday 08 March 2015 09:26:17 Wolfram Sang wrote:
> 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/in
> >>>> put1
> >>>> # 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?
Good question, and I have to confess that I don't really remember :-/
> > 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've reached the same conclusion after reading the code. I was concerned about
resource leakage, but that doesn't seem to be an issue.
> > 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.
I'll defer that to Rob. I'm fine with the revert at the moment.
--
Regards,
Laurent Pinchart
^ permalink raw reply [flat|nested] 15+ messages in thread
* Bug in i2c-core?
2015-03-10 0:21 ` Laurent Pinchart
@ 2015-03-12 9:35 ` Wolfram Sang
0 siblings, 0 replies; 15+ messages in thread
From: Wolfram Sang @ 2015-03-12 9:35 UTC (permalink / raw)
To: linux-arm-kernel
> > > 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.
>
> I'll defer that to Rob. I'm fine with the revert at the moment.
Added the revert to for-current now with your and Dmitry's ack.
-------------- 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/20150312/dc8cd6eb/attachment.sig>
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2015-03-12 9:35 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-27 11:09 Bug in i2c-core? Sébastien SZYMANSKI
2015-02-27 14:37 ` Thomas Petazzoni
2015-02-27 15:29 ` Dmitry Torokhov
2015-02-27 17:05 ` Uwe Kleine-König
2015-02-27 17:46 ` Dmitry Torokhov
2015-02-27 18:39 ` Uwe Kleine-König
2015-02-28 10:00 ` Thomas Petazzoni
2015-02-27 16:59 ` Dmitry Torokhov
2015-02-27 17:01 ` Dmitry Torokhov
2015-03-03 22:03 ` Laurent Pinchart
2015-03-04 6:47 ` Wolfram Sang
2015-03-04 8:22 ` Wolfram Sang
2015-03-08 8:26 ` Wolfram Sang
2015-03-10 0:21 ` Laurent Pinchart
2015-03-12 9:35 ` Wolfram Sang
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).