All of lore.kernel.org
 help / color / mirror / Atom feed
From: greg@kroah.com (Greg KH)
To: sensors@stimpy.netroedge.com
Cc: linux-kernel@vger.kernel.org, hunold@convergence.de
Subject: [RFC][2.6] Additional i2c adapter flags for i2c client isolation
Date: Thu, 19 May 2005 06:24:48 +0000	[thread overview]
Message-ID: <20040317231135.GA4970@kroah.com> (raw)
In-Reply-To: <20040317210504.34eb192f.khali@linux-fr.org>

On Wed, Mar 17, 2004 at 09:05:04PM +0100, Jean Delvare wrote:
> > > How would we export the value though? Numerical, with user-space
> > > headers to be included by user-space applications? Or converted to
> > > some explicit text strings so that no headers are needed?
> > 
> > A text string would be simple enough to use.
> 
> I'm not sure.  What about a chip driver that would belong to more than
> one class?  What about the eeprom driver which will belong to all
> classes?  With a numeric value, a simple binary operation handles all
> the cases.  With text strings we would end having to parse a possibly
> multi-valued string, and do string comparisons, with at least one
> exception to handle.  This is likely to require much more resources,
> don't you think?

Ok, I wasn't really awake when writing that, you are correct.  Other
devices export "values" that have to be looked up in tables in userspace
(think device ids).  We can just export a hex number that matches the
ones in i2c.h

Anyone want to write a patch?  :)

thanks,

greg k-h

WARNING: multiple messages have this Message-ID (diff)
From: Greg KH <greg@kroah.com>
To: sensors@stimpy.netroedge.com
Cc: linux-kernel@vger.kernel.org, hunold@convergence.de
Subject: Re: [RFC][2.6] Additional i2c adapter flags for i2c client isolation
Date: Wed, 17 Mar 2004 15:11:35 -0800	[thread overview]
Message-ID: <20040317231135.GA4970@kroah.com> (raw)
In-Reply-To: <20040317210504.34eb192f.khali@linux-fr.org>

On Wed, Mar 17, 2004 at 09:05:04PM +0100, Jean Delvare wrote:
> > > How would we export the value though? Numerical, with user-space
> > > headers to be included by user-space applications? Or converted to
> > > some explicit text strings so that no headers are needed?
> > 
> > A text string would be simple enough to use.
> 
> I'm not sure.  What about a chip driver that would belong to more than
> one class?  What about the eeprom driver which will belong to all
> classes?  With a numeric value, a simple binary operation handles all
> the cases.  With text strings we would end having to parse a possibly
> multi-valued string, and do string comparisons, with at least one
> exception to handle.  This is likely to require much more resources,
> don't you think?

Ok, I wasn't really awake when writing that, you are correct.  Other
devices export "values" that have to be looked up in tables in userspace
(think device ids).  We can just export a hex number that matches the
ones in i2c.h

Anyone want to write a patch?  :)

thanks,

greg k-h

  reply	other threads:[~2005-05-19  6:24 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-16  9:25 [RFC][2.6] Additional i2c adapter flags for i2c client isolation Michael Hunold
2004-03-16 13:26 ` Adrian Cox
2004-03-16 14:23   ` Michael Hunold
2004-03-16 15:44 ` Greg KH
2005-05-19  6:24   ` Greg KH
2004-03-16 19:14   ` Jean Delvare
2005-05-19  6:24     ` [RFC][2.6] Additional i2c adapter flags for i2c client Jean Delvare
2004-03-16 19:53     ` [RFC][2.6] Additional i2c adapter flags for i2c client isolation Greg KH
2005-05-19  6:24       ` Greg KH
2004-03-17  9:17       ` Jean Delvare
2005-05-19  6:24         ` Jean Delvare
2004-03-17 17:42         ` Greg KH
2005-05-19  6:24           ` Greg KH
2004-03-17 20:05           ` Jean Delvare
2005-05-19  6:24             ` [RFC][2.6] Additional i2c adapter flags for i2c client Jean Delvare
2004-03-17 23:11             ` Greg KH [this message]
2005-05-19  6:24               ` [RFC][2.6] Additional i2c adapter flags for i2c client isolation Greg KH
2004-03-18 15:56   ` Michael Hunold
2005-05-19  6:24     ` Michael Hunold
2005-05-19  6:24   ` [RFC][2.6] Additional i2c adapter flags for i2c client Jean Delvare

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=20040317231135.GA4970@kroah.com \
    --to=greg@kroah.com \
    --cc=hunold@convergence.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sensors@stimpy.netroedge.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.