From: "Dmitry Torokhov" <dmitry.torokhov@gmail.com>
To: Pavel Pisa <ppisa4lists@pikron.com>
Cc: linux-arm-kernel@lists.arm.linux.org.uk,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Sascha Hauer <s.hauer@pengutronix.de>,
linux-input <linux-input@atrey.karlin.mff.cuni.cz>
Subject: Re: [PATCH] Generic, platform independent matrix keyboard support
Date: Wed, 10 Oct 2007 09:48:47 -0400 [thread overview]
Message-ID: <d120d5000710100648w24ca7fe8g6bbedf5502a6df75@mail.gmail.com> (raw)
In-Reply-To: <200710100332.35807.ppisa4lists@pikron.com>
On 10/9/07, Pavel Pisa <ppisa4lists@pikron.com> wrote:
>
> Name of corresponding platform and PCI methods is probe.
> But name can be changed if new one is seen as more logical.
>
There you indeed probing devices for supported functionality. But here
you just register a new object with the system (note that all such
methods have 'register' in them - device_register(),
input_register_device() , etc).
> > > +
> > > + input_dev = input_allocate_device();
> > > + if (!input_dev)
> > > + goto fail_arr_alloc;
> > > +
> > > + kbd->input = input_dev;
> > > + kbd->hw_dev = dev;
> > > + dev_set_drvdata(dev, kbd);
> >
> > Does not belong here.
>
> Where I can store pointer to specialized part.
>
I mean setting up kbd does not belong here. You set it up (by setting
hw_dev and calling dev_set_drvdadat) before calling
genmatrix_register().
> > > +
> > > + /* Setup input device */
> > > + input_dev->name = "GenMatrix Keyboard";
> > > + input_dev->phys = kbd->phys;
> > > + input_dev->dev.parent = dev;
> >
> > Make this input_dev->dev.parent = kbd->dev; and get rid of dev argument.
>
> I am not fully sure what it would cause in device model hierarchy,
> but I try to learn and check that.
>
I meant input_dev->dev.parent = kbd->hw_dev;
> > > +
> > > + input_dev->id.bustype = BUS_HOST;
> > > + input_dev->id.vendor = 0x0001;
> > > + input_dev->id.product = 0x0001;
> > > + input_dev->id.version = 0x0100;
> > > +
> > > + input_dev->evbit[0] = BIT(EV_KEY) | BIT(EV_REP); /* BIT(EV_PWR) |
> > > BIT(EV_SW); */ + input_dev->keycode = kbd->keycode;
> > > + input_dev->keycodesize = sizeof(*kbd->keycode);
> > > + input_dev->keycodemax = kbd->keycode_cnt;
> > > +
> > > + for (i = 0; i < kbd->keycode_cnt; i++)
> > > + set_bit(kbd->keycode[i], input_dev->keybit);
> > > + clear_bit(0, input_dev->keybit);
> > > + /*
> > > + set_bit(SW_LID, input_dev->swbit);
> > > + set_bit(SW_TABLET_MODE, input_dev->swbit);
> > > + set_bit(SW_HEADPHONE_INSERT, input_dev->swbit);
> > > + */
> > > +
> > > + err = kbd->setup(kbd->hw_dev);
> > > + if (err) {
> > > + dev_err(kbd->hw_dev, "low-level hardware setup
> > > failed\n"); + goto fail;
> > > + }
> > > +
> > > + err = input_register_device(input_dev);
> > > + if (err) {
> > > + dev_err(kbd->hw_dev, "input device registration\n");
> > > + goto fail_to_register;
> > > + }
> > > +
> > > + mod_timer(&kbd->timer, jiffies + 1);
> >
> > Do not start timer/IRQs until there are users. Implement
> > inptu_dev->open() abd ->close() and do it from there.
>
> OK, that is right solution. I look at that.
>
> > > +static int genmatrix_remove(struct device *dev)
> > > +{
> > > ..........
> > > + dev_set_drvdata(dev, NULL);
> > > +
> > > + kfree(kbd->phys);
> > > + kfree(kbd->down_arr);
> > > + kfree(kbd->chng_arr);
> > > + kfree(kbd->keycode);
> >
> > I don't see you allocate kbd->keycode, why are you freeing it?
>
> Somebody has to remove it. May it be, that free calls could/should
> be distributed different way between genmatrix_plat_remove()
> and genmatrix_remove().
>
> > > +
> > > + kfree(kbd);
> >
> > Actually, why are you freeing kbd? If it was not allocated in probe(),
> > it should not be freed in remove().
>
> Somebody has to free it. The genmatrix_remove() may be more
> appropriate, but I would be happy to not teach that how pointer to
> kbd is stored in dev hierarchy. But move could be right thing to do.
>
But kbd may be a part of a bigger structure and not allocated
separately. I prefer the following rule - if a layer did not allocate
a resource it should not try to free it.
--
Dmitry
next prev parent reply other threads:[~2007-10-10 13:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200709021228.58354.ppisa4lists@pikron.com>
[not found] ` <200710090218.27964.ppisa4lists@pikron.com>
[not found] ` <20071009074020.GA14231@flint.arm.linux.org.uk>
[not found] ` <200710091222.10677.ppisa4lists@pikron.com>
2007-10-09 16:22 ` [PATCH] Generic, platform independent matrix keyboard support Dmitry Torokhov
2007-10-10 1:32 ` Pavel Pisa
2007-10-10 2:05 ` David Brownell
2007-10-10 13:10 ` Dmitry Torokhov
2007-10-14 20:57 ` Pavel Pisa
2007-10-15 0:18 ` David Brownell
2007-10-10 13:48 ` Dmitry Torokhov [this message]
2007-08-26 18:48 Pavel Pisa
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=d120d5000710100648w24ca7fe8g6bbedf5502a6df75@mail.gmail.com \
--to=dmitry.torokhov@gmail.com \
--cc=linux-arm-kernel@lists.arm.linux.org.uk \
--cc=linux-input@atrey.karlin.mff.cuni.cz \
--cc=linux@arm.linux.org.uk \
--cc=ppisa4lists@pikron.com \
--cc=s.hauer@pengutronix.de \
/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 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).