All of lore.kernel.org
 help / color / mirror / Atom feed
From: Christopher Heiny <cheiny@synaptics.com>
To: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Jean Delvare <khali@linux-fr.org>,
	Linux Kernel <linux-kernel@vger.kernel.org>,
	Linux Input <linux-input@vger.kernel.org>,
	Joerie de Gram <j.de.gram@gmail.com>,
	Linus Walleij <linus.walleij@stericsson.com>,
	Naveen Kumar Gaddipati <naveen.gaddipati@stericsson.com>
Subject: Re: [RFC PATCH 1/11] input: RMI4 public header file and documentation.
Date: Mon, 9 Jan 2012 12:31:19 -0800	[thread overview]
Message-ID: <4F0B4E97.4000107@synaptics.com> (raw)
In-Reply-To: <20120106063546.GA10447@core.coreip.homeip.net>

On 01/05/2012 10:35 PM, Dmitry Torokhov wrote:
> On Wed, Dec 21, 2011 at 06:09:52PM -0800, Christopher Heiny wrote:
>> +
>> +/* Helper fn to convert a byte array representing a short in the RMI
>> + * endian-ness to a short in the native processor's specific endianness.
>> + * We don't use ntohs/htons here because, well, we're not dealing with
>> + * a pair of shorts. And casting dest to short* wouldn't work, because
>> + * that would imply knowing the byte order of short in the first place.
>> + */
>> +static inline void batohs(unsigned short *dest, unsigned char *src)
>> +{
>> +	*dest = src[1] * 0x100 + src[0];
>> +}
>> +
>> +/* Helper function to convert a short (in host processor endianess) to
>> + * a byte array in the RMI endianess for shorts.  See above comment for
>> + * why we dont us htons or something like that.
>> + */
>> +static inline void hstoba(unsigned char *dest, unsigned short src)
>> +{
>> +	dest[0] = src % 0x100;
>> +	dest[1] = src / 0x100;
>> +}
>
> We have nice set of be/le16_to_cpu and cpu_to_be/le16 helpers that do
> just that and in much more efficient way.

Yay!  We'll switch to those.

>
>> +
>> +/* Utility routine to handle writes to read-only attributes.  Hopefully
>> + * this will never happen, but if the user does something stupid, we don't
>> + * want to accept it quietly (which is what can happen if you just put NULL
>> + * for the attribute's store function).
>> + */
>> +static inline ssize_t rmi_store_error(struct device *dev,
>> +			struct device_attribute *attr,
>> +			const char *buf, size_t count)
>> +{
>> +	dev_warn(dev,
>> +		 "RMI4 WARNING: Attempt to write %d characters to read-only "
>> +		 "attribute %s.", count, attr->attr.name);
>> +	return -EPERM;
>> +}
>> +
>> +/* Utility routine to handle reads of write-only attributes.  Hopefully
>> + * this will never happen, but if the user does something stupid, we don't
>> + * want to accept it quietly (which is what can happen if you just put NULL
>> + * for the attribute's show function).
>> + */
>> +static inline ssize_t rmi_show_error(struct device *dev,
>> +		       struct device_attribute *attr,
>> +		       char *buf)
>> +{
>> +	dev_warn(dev,
>> +		 "RMI4 WARNING: Attempt to read from write-only attribute %s.",
>> +		 attr->attr.name);
>> +	return -EPERM;
>> +}
>
> Although these methods are not needed, a general comment nonetheless: do
> not put in header files and mark inline functions which address is taken
> and used elsewhere.

OK.

  reply	other threads:[~2012-01-09 20:31 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-22  2:09 [RFC PATCH 00/11] input: Synaptics RMI4 Touchscreen Driver Christopher Heiny
2011-12-22  2:09 ` [RFC PATCH 1/11] input: RMI4 public header file and documentation Christopher Heiny
2012-01-06  6:35   ` Dmitry Torokhov
2012-01-09 20:31     ` Christopher Heiny [this message]
2011-12-22  2:09 ` [RFC PATCH 2/11] input: RMI4 core bus and sensor drivers Christopher Heiny
2012-01-02  6:38   ` Shubhrajyoti
2012-01-05 20:49     ` Christopher Heiny
2012-01-05 21:58       ` Lars-Peter Clausen
2012-01-06  1:56     ` Christopher Heiny
2012-01-06  2:34   ` Dmitry Torokhov
2012-01-07  3:26     ` Christopher Heiny
2011-12-22  2:09 ` [RFC PATCH 3/11] input: RMI4 physical layer drivers for I2C and SPI Christopher Heiny
2011-12-22  2:09 ` [RFC PATCH 4/11] input: RMI4 KConfigs and Makefiles Christopher Heiny
2011-12-22  2:09 ` [RFC PATCH 5/11] input: rmidev character driver for RMI4 sensors Christopher Heiny
2011-12-22  2:09 ` [RFC PATCH 6/11] input: RMI4 F09 - self test Christopher Heiny
2011-12-22  2:09 ` [RFC PATCH 7/11] input: RMI4 F01 - device control Christopher Heiny
2011-12-22  2:09 ` [RFC PATCH 8/11] input: RMI4 F54 - analog data reporting Christopher Heiny
2011-12-22  2:10 ` [RFC PATCH 9/11] input: RMI F34 - firmware reflash Christopher Heiny
2011-12-22  2:10 ` [RFC PATCH 10/11] input: RMI4 F19 - capacitive buttons Christopher Heiny
2012-01-05  7:53   ` Dmitry Torokhov
2012-01-06  0:05     ` Christopher Heiny
2012-01-06  2:50       ` Dmitry Torokhov
2012-01-09 21:02         ` Christopher Heiny
2011-12-22  2:10 ` [RFC PATCH 11/11] input: RMI4 F11 - multifinger pointing Christopher Heiny
2012-01-01 13:51 ` [RFC PATCH 00/11] input: Synaptics RMI4 Touchscreen Driver Linus Walleij
2012-01-04  1:51   ` Christopher Heiny
2012-01-05  7:58 ` Dmitry Torokhov
2012-01-05 20:09   ` Christopher Heiny

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=4F0B4E97.4000107@synaptics.com \
    --to=cheiny@synaptics.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=j.de.gram@gmail.com \
    --cc=khali@linux-fr.org \
    --cc=linus.walleij@stericsson.com \
    --cc=linux-input@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=naveen.gaddipati@stericsson.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.