From: Tapio Vihuri <tapio.vihuri@nokia.com>
To: ext Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: randy.dunlap@oracle.com, alsa-devel@alsa-project.org,
ilkka.koskinen@nokia.com, linux-kernel@vger.kernel.org,
samu.p.onkalo@nokia.com
Subject: Re: [PATCH v2 1/3] ECI: input: introduce ECI accessory input driver
Date: Tue, 04 Jan 2011 16:01:44 +0200 [thread overview]
Message-ID: <1294149704.2389.82.camel@dell> (raw)
In-Reply-To: <20110102081922.GD5429@core.coreip.homeip.net>
On Sun, 2011-01-02 at 00:19 -0800, ext Dmitry Torokhov wrote:
> Hi Tapio,
>
Hi Dmitry
Thank you for good comments. I sent v3 patch set right after this email.
--------8<-------
> Please keep Makefile and Kconfig sorted alphabetically.
>
Corrected in patch set.
--------8<-------
> Consider switching to sparse keymap library. You won't be needing ugly
> KEY_MAX + SW_XXX hacks and it will also support remapping keys from
> userspace.
>
Much nicer solution, thank you.
--------8<-------
> Do not break strings on 80 column boundaries, wither align the arguments
> differently or just go past 80 columns, like this:
>
> dev_err(eci->dev,
> "Unable to control headset microphone\n");
>
Corrected in patch set.
--------8<-------
> > +#define eci_initialize_debugfs(eci) 1
>
> Should be 0 I think, and not have a parameter, preferably
>
> static inline int eci_initialize_debugfs(void)
> {
> return 0;
> }
>
I take this static inline solution, but I needed the parameter.
--------8<-------
> > + struct eci_mem_block *ekey = (void *)buf;
> > + int ret;
> > +
> > + /* Read always four bytes */
> > + ret = eci->eci_hw_ops->acc_read_direct(0, buf);
> > +
> > + if (ret)
> > + return ret;
> > +
> > + if (ekey->id != ECI_EKEY_BLOCK_ID)
> > + return -ENODEV;
> > +
> > + *key = cpu_to_be16(ekey->size);
>
> cpu_to_be16()??? This looks really wierd.
>
The ECI specification says that data in ECI accessory's memory is in big
endian order. This simply get 16-bit size parameter right in any
endianes machine.
--------8<-------
> > +static ssize_t show_cable_plugged(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + struct eci_data *eci = dev_get_drvdata(dev);
> > +
> > + return snprintf(buf, sizeof(buf), "Cable plugged %s\n",
> > + eci->plugged ? "in" : "out");
>
> Should it be dsimple 0/1? How is this attribute supposed to be used?
>
> > +static ssize_t store_cable_plugged(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf, size_t len)
> > +{
--------8<-------
> Same here. Should it be in debugfs probably?
>
I made it now as 0/1. It's in sysfs as this is user space's interface
for ECI acessories inserting.
The other way is via ALSA sound driver providing jack detection, but
it's not there yet.
--------8<-------
> > + /*
> > + * Configure ECI buttons now as we have after parsed
> > + * enchancement features table
> > + */
>
> I do not understand this comment.
>
I have loose some word somewhere... Now it goes:
/*
* Configure ECI buttons now as we know how after
* enchancement features table has been parsed
*/
--------8<-------
> > + set_bit(EV_KEY, eci->acc_input->evbit);
> > + set_bit(EV_SW, eci->acc_input->evbit);
> > + set_bit(EV_REP, eci->acc_input->evbit);
>
> __set_bit(), no neded to lock bus.
>
Corrected in patch set.
--------8<-------
> > +
> > +static struct miscdevice eci_device = {
> > + .minor = MISC_DYNAMIC_MINOR,
> > + .name = ECI_DRIVERNAME,
> > +};
>
> What does this device do?
>
Nothing, and I can't even remember why I have put it there first place.
Removed now.
--------8<-------
> Thank you.
>
> --
> Dmitry
Thank you, now driver is better.
--
Tapsa
WARNING: multiple messages have this Message-ID (diff)
From: Tapio Vihuri <tapio.vihuri@nokia.com>
To: ext Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: randy.dunlap@oracle.com, linux-kernel@vger.kernel.org,
alsa-devel@alsa-project.org, ilkka.koskinen@nokia.com,
samu.p.onkalo@nokia.com
Subject: Re: [PATCH v2 1/3] ECI: input: introduce ECI accessory input driver
Date: Tue, 04 Jan 2011 16:01:44 +0200 [thread overview]
Message-ID: <1294149704.2389.82.camel@dell> (raw)
In-Reply-To: <20110102081922.GD5429@core.coreip.homeip.net>
On Sun, 2011-01-02 at 00:19 -0800, ext Dmitry Torokhov wrote:
> Hi Tapio,
>
Hi Dmitry
Thank you for good comments. I sent v3 patch set right after this email.
--------8<-------
> Please keep Makefile and Kconfig sorted alphabetically.
>
Corrected in patch set.
--------8<-------
> Consider switching to sparse keymap library. You won't be needing ugly
> KEY_MAX + SW_XXX hacks and it will also support remapping keys from
> userspace.
>
Much nicer solution, thank you.
--------8<-------
> Do not break strings on 80 column boundaries, wither align the arguments
> differently or just go past 80 columns, like this:
>
> dev_err(eci->dev,
> "Unable to control headset microphone\n");
>
Corrected in patch set.
--------8<-------
> > +#define eci_initialize_debugfs(eci) 1
>
> Should be 0 I think, and not have a parameter, preferably
>
> static inline int eci_initialize_debugfs(void)
> {
> return 0;
> }
>
I take this static inline solution, but I needed the parameter.
--------8<-------
> > + struct eci_mem_block *ekey = (void *)buf;
> > + int ret;
> > +
> > + /* Read always four bytes */
> > + ret = eci->eci_hw_ops->acc_read_direct(0, buf);
> > +
> > + if (ret)
> > + return ret;
> > +
> > + if (ekey->id != ECI_EKEY_BLOCK_ID)
> > + return -ENODEV;
> > +
> > + *key = cpu_to_be16(ekey->size);
>
> cpu_to_be16()??? This looks really wierd.
>
The ECI specification says that data in ECI accessory's memory is in big
endian order. This simply get 16-bit size parameter right in any
endianes machine.
--------8<-------
> > +static ssize_t show_cable_plugged(struct device *dev,
> > + struct device_attribute *attr, char *buf)
> > +{
> > + struct eci_data *eci = dev_get_drvdata(dev);
> > +
> > + return snprintf(buf, sizeof(buf), "Cable plugged %s\n",
> > + eci->plugged ? "in" : "out");
>
> Should it be dsimple 0/1? How is this attribute supposed to be used?
>
> > +static ssize_t store_cable_plugged(struct device *dev,
> > + struct device_attribute *attr,
> > + const char *buf, size_t len)
> > +{
--------8<-------
> Same here. Should it be in debugfs probably?
>
I made it now as 0/1. It's in sysfs as this is user space's interface
for ECI acessories inserting.
The other way is via ALSA sound driver providing jack detection, but
it's not there yet.
--------8<-------
> > + /*
> > + * Configure ECI buttons now as we have after parsed
> > + * enchancement features table
> > + */
>
> I do not understand this comment.
>
I have loose some word somewhere... Now it goes:
/*
* Configure ECI buttons now as we know how after
* enchancement features table has been parsed
*/
--------8<-------
> > + set_bit(EV_KEY, eci->acc_input->evbit);
> > + set_bit(EV_SW, eci->acc_input->evbit);
> > + set_bit(EV_REP, eci->acc_input->evbit);
>
> __set_bit(), no neded to lock bus.
>
Corrected in patch set.
--------8<-------
> > +
> > +static struct miscdevice eci_device = {
> > + .minor = MISC_DYNAMIC_MINOR,
> > + .name = ECI_DRIVERNAME,
> > +};
>
> What does this device do?
>
Nothing, and I can't even remember why I have put it there first place.
Removed now.
--------8<-------
> Thank you.
>
> --
> Dmitry
Thank you, now driver is better.
--
Tapsa
next prev parent reply other threads:[~2011-01-04 14:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-30 13:36 [PATCH v2 0/3] input: Add support for ECI (multimedia) accessories tapio.vihuri
2010-12-30 13:36 ` tapio.vihuri
2010-12-30 13:36 ` [PATCH v2 1/3] ECI: input: introduce ECI accessory input driver tapio.vihuri
2010-12-30 13:36 ` [PATCH v2 2/3] ECI: introducing ECI bus driver tapio.vihuri
2010-12-30 13:36 ` [PATCH v2 3/3] ECI: adding platform data for ECI driver tapio.vihuri
2011-01-03 8:42 ` [PATCH v2 2/3] ECI: introducing ECI bus driver Peter Ujfalusi
2011-01-03 8:42 ` [alsa-devel] " Peter Ujfalusi
2011-01-02 8:19 ` [PATCH v2 1/3] ECI: input: introduce ECI accessory input driver Dmitry Torokhov
2011-01-02 8:19 ` Dmitry Torokhov
2011-01-04 14:01 ` Tapio Vihuri [this message]
2011-01-04 14:01 ` Tapio Vihuri
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=1294149704.2389.82.camel@dell \
--to=tapio.vihuri@nokia.com \
--cc=alsa-devel@alsa-project.org \
--cc=dmitry.torokhov@gmail.com \
--cc=ilkka.koskinen@nokia.com \
--cc=linux-kernel@vger.kernel.org \
--cc=randy.dunlap@oracle.com \
--cc=samu.p.onkalo@nokia.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.