All of lore.kernel.org
 help / color / mirror / Atom feed
From: ac9410@attbi.com (Albert Cranford)
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org, sensors@stimpy.netroedge.com
Subject: [PATCH] More i2c driver changes for 2.5.66
Date: Thu, 19 May 2005 06:23:52 +0000	[thread overview]
Message-ID: <3E8C31BE.5060000@attbi.com> (raw)
In-Reply-To: 20030403063359.GA1536@kroah.com

Your right, nobody outside of sensors uses i2c-proc, but
why not create a new i2c-sysfs.h in drivers/i2c locally
and and adjust the couple of existing drivers.
We all know the application library is not going to have
access to include/linux/include/i2c-xxxx.h anyhow.

Later we can completely remove linux/include/linux/i2c-proc.h
which the existing application library relies upon.
ALbert

Greg KH wrote:
> On Thu, Apr 03, 2003 at 01:21:13AM -0500, Albert Cranford wrote:
> 
>>I read the thread concerning the removal of proc.c & proc.h
>>but hope that this does not go to Linus until the interface
>>between i2c & sensors to application is somewhat defined.
>>
>>At the moment we have a sysctl API used by sensors, video and
>>other i2c kernel applications that is working.
> 
> 
> The only in-kernel drivers that were using the sysctl/proc interface was
> the lm75 and adm1021 drivers.  The video and other i2c kernel drivers do
> not use this interface at all.
> 
> Those two drivers, and the two other chip drivers that I added to the
> kernel in this set of patches were converted over to the sysfs interface
> (well one of the new ones were, the other one will build and run, but
> doesn't export any sysfs files yet, that will change soon.)
> 
> 
>>Our desire to switch the sensors to sysfs interface should not
>>break other applications.  At least until we have a model/api
>>to propose to these other drivers.
> 
> 
> Yes, any applications that used the sysctl interface to get data from
> those two driver will break.  However we have to switch at some point in
> time, and the userspace library can't be worked on very well if the
> kernel can't support it yet :)
> 
> So I'm choosing to update the kernel first, and will be working on the
> library in the coming weeks.  As there is no real sensors support
> besides those two drivers in the main kernel, I didn't break much :)
> 
> 
>>In my personal home systems I use it87 driver and have been
>>somewhat successful in switching to sysfs.  A big blocking
>>point is there is no application to read/set/monitor the
>>driver, so it is basically unverified.
> 
> 
> I tested the changes I did by using echo and cat, no library or other
> applications are needed just yet.
> 
> thanks,
> 
> greg k-h
> 
> 


WARNING: multiple messages have this Message-ID (diff)
From: Albert Cranford <ac9410@attbi.com>
To: Greg KH <greg@kroah.com>
Cc: linux-kernel@vger.kernel.org, sensors@stimpy.netroedge.com
Subject: Re: [PATCH] More i2c driver changes for 2.5.66
Date: Thu, 03 Apr 2003 08:06:06 -0500	[thread overview]
Message-ID: <3E8C31BE.5060000@attbi.com> (raw)
In-Reply-To: 20030403063359.GA1536@kroah.com

Your right, nobody outside of sensors uses i2c-proc, but
why not create a new i2c-sysfs.h in drivers/i2c locally
and and adjust the couple of existing drivers.
We all know the application library is not going to have
access to include/linux/include/i2c-xxxx.h anyhow.

Later we can completely remove linux/include/linux/i2c-proc.h
which the existing application library relies upon.
ALbert

Greg KH wrote:
> On Thu, Apr 03, 2003 at 01:21:13AM -0500, Albert Cranford wrote:
> 
>>I read the thread concerning the removal of proc.c & proc.h
>>but hope that this does not go to Linus until the interface
>>between i2c & sensors to application is somewhat defined.
>>
>>At the moment we have a sysctl API used by sensors, video and
>>other i2c kernel applications that is working.
> 
> 
> The only in-kernel drivers that were using the sysctl/proc interface was
> the lm75 and adm1021 drivers.  The video and other i2c kernel drivers do
> not use this interface at all.
> 
> Those two drivers, and the two other chip drivers that I added to the
> kernel in this set of patches were converted over to the sysfs interface
> (well one of the new ones were, the other one will build and run, but
> doesn't export any sysfs files yet, that will change soon.)
> 
> 
>>Our desire to switch the sensors to sysfs interface should not
>>break other applications.  At least until we have a model/api
>>to propose to these other drivers.
> 
> 
> Yes, any applications that used the sysctl interface to get data from
> those two driver will break.  However we have to switch at some point in
> time, and the userspace library can't be worked on very well if the
> kernel can't support it yet :)
> 
> So I'm choosing to update the kernel first, and will be working on the
> library in the coming weeks.  As there is no real sensors support
> besides those two drivers in the main kernel, I didn't break much :)
> 
> 
>>In my personal home systems I use it87 driver and have been
>>somewhat successful in switching to sysfs.  A big blocking
>>point is there is no application to read/set/monitor the
>>driver, so it is basically unverified.
> 
> 
> I tested the changes I did by using echo and cat, no library or other
> applications are needed just yet.
> 
> thanks,
> 
> greg k-h
> 
> 



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

Thread overview: 92+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-03  0:14 [BK PATCH] More i2c driver changes for 2.5.66 Greg KH
2003-04-03  0:15 ` [PATCH] " Greg KH
2003-04-03  0:15   ` Greg KH
2003-04-03  0:15     ` Greg KH
2003-04-03  0:15       ` Greg KH
2003-04-03  0:15         ` Greg KH
2003-04-03  0:15           ` Greg KH
2005-05-19  6:23             ` Greg KH
2003-04-03  0:15             ` Greg KH
2003-04-03  0:15               ` Greg KH
2005-05-19  6:23                 ` Greg KH
2003-04-03  0:15                 ` Greg KH
2003-04-03  0:15                   ` Greg KH
2003-04-03  0:15                     ` Greg KH
2003-04-03  0:15                       ` Greg KH
2003-04-03  0:15                         ` Greg KH
2003-04-03  0:15                           ` Greg KH
2003-04-03  0:15                             ` Greg KH
2003-04-03  6:21                 ` Albert Cranford
2005-05-19  6:23                   ` Albert Cranford
2003-04-03  6:33                   ` Greg KH
2005-05-19  6:23                     ` Greg KH
2003-04-03 13:06                     ` Albert Cranford [this message]
2005-05-19  6:23                       ` Albert Cranford
2003-04-03 16:37                       ` Greg KH
2005-05-19  6:23                         ` Greg KH
  -- strict thread matches above, loose matches on Subject: below --
2003-06-11 20:35 [BK PATCH] More i2c driver changes for 2.5.70 Greg KH
2005-05-19  6:23 ` Greg KH
2003-06-11 20:36 ` [PATCH] " Greg KH
2005-05-19  6:23   ` Greg KH
2003-06-11 20:36   ` Greg KH
2005-05-19  6:23     ` Greg KH
2003-06-11 20:36     ` Greg KH
2005-05-19  6:23       ` Greg KH
2003-06-11 20:36       ` Greg KH
2005-05-19  6:23         ` Greg KH
2003-06-11 20:36         ` Greg KH
2005-05-19  6:23           ` Greg KH
2003-06-11 20:36           ` Greg KH
2005-05-19  6:23             ` Greg KH
2003-06-12  2:40   ` Philip Pokorny
2005-05-19  6:23     ` Philip Pokorny
2003-05-09 23:55 [BK PATCH] More i2c driver changes for 2.5.69 Greg KH
2005-05-19  6:23 ` Greg KH
2003-05-09 23:56 ` [PATCH] " Greg KH
2005-05-19  6:23   ` Greg KH
2003-05-09 23:56   ` Greg KH
2005-05-19  6:23     ` Greg KH
2003-05-09 23:56     ` Greg KH
2005-05-19  6:23       ` Greg KH
2003-05-09 23:56       ` Greg KH
2005-05-19  6:23         ` Greg KH
2003-05-09 23:56         ` Greg KH
2005-05-19  6:23           ` Greg KH
2003-05-09 23:56           ` Greg KH
2005-05-19  6:23             ` Greg KH
2003-03-22  1:04 [BK PATCH] More i2c driver changes for 2.5.65 Greg KH
2005-05-19  6:23 ` Greg KH
2003-03-22  1:04 ` [PATCH] " Greg KH
2005-05-19  6:23   ` Greg KH
2003-03-22  1:04   ` Greg KH
2005-05-19  6:23     ` Greg KH
2003-03-22  1:04     ` Greg KH
2005-05-19  6:23       ` Greg KH
2003-03-22  1:04       ` Greg KH
2005-05-19  6:23         ` Greg KH
2003-03-22  1:04         ` Greg KH
2005-05-19  6:23           ` Greg KH
2003-03-22  1:04           ` Greg KH
2005-05-19  6:23             ` Greg KH
2003-03-22  1:04             ` Greg KH
2005-05-19  6:23               ` Greg KH
2003-03-22  1:04               ` Greg KH
2005-05-19  6:23                 ` Greg KH
2003-03-22  1:04                 ` Greg KH
2005-05-19  6:23                   ` Greg KH
2003-03-25  9:35                 ` Pavel Machek
2005-05-19  6:23                   ` Pavel Machek
2003-03-25  1:29                   ` Greg KH
2005-05-19  6:23                     ` Greg KH
2003-03-25  2:04                     ` Dave Jones
2005-05-19  6:23                       ` Dave Jones
2003-03-25  3:34                       ` Greg KH
2005-05-19  6:23                         ` Greg KH
2005-05-19  6:23         ` [PATCH] More i2c driver changes for 2.5.66 Greg KH
2005-05-19  6:23         ` Mark M. Hoffman
2005-05-19  6:23         ` Albert Cranford
2005-05-19  6:23         ` [PATCH] More i2c driver changes for 2.5.69 Philip Pokorny
2003-03-22  2:33     ` [PATCH] More i2c driver changes for 2.5.65 Petr Vandrovec
2005-05-19  6:23       ` Petr Vandrovec
2003-03-23  8:49       ` Greg KH
2005-05-19  6:23         ` Greg KH

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=3E8C31BE.5060000@attbi.com \
    --to=ac9410@attbi.com \
    --cc=greg@kroah.com \
    --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.