All of lore.kernel.org
 help / color / mirror / Atom feed
From: khali@linux-fr.org (Jean Delvare)
To: Simon Vogl <simon@voxel.at>, Daniel Smolik <marvin@sitour.cz>
Cc: Greg KH <greg@kroah.com>,
	sensors@stimpy.netroedge.com, linux-kernel@vger.kernel.org
Subject: I2C parallel port adapters drivers
Date: Thu, 19 May 2005 06:24:23 +0000	[thread overview]
Message-ID: <20031102132342.79920c6f.khali@linux-fr.org> (raw)


Hi all,

I have been playing with I2C parallel port adapters drivers for the last
few days and I believe that some cleanups would be welcome. I will
expose the facts as I gathered and understood them, and then do some
proposals about what I think should be made.

There are four different drivers that let you use the parallel port as
an I2C bus.

i2c-philips-par
i2c-elv
i2c-velleman
i2c-pport

The first three are already present in Linux 2.4 and have also been
ported to Linux 2.6. The fourth is obviously newer (admittedly derived
from i2c-velleman) and only present in i2c CVS.

The last three drivers are very, very similar. Take a look at them, and
you'll see that they only differ in which pins are used for the I2C bus'
SCL and SDA lines. They access the parallel port directly, without using
the parport module.

The first one, i2c-philips-par, is different, since it relies on the
parport module. That said, it is similar to the other ones in spirit,
using the parallel port pins as an I2C bus. Only the access method
differ.

My point is that we don't need four different modules for the very same
purpose. We'd better have one single module, supporting all adapter
types through a parameter. The i2c-philips-par module already has such a
mechanism, allowing for two different pins configuration trough its type
parameter.

I know have to understand why one module is using the parport module,
while the other ones are bypassing it. Do we have a reason to prefer one
method to the other? Using the hardware I have, I could check that both
methods are working (at least for me), but I might be missing something
the original modules authors had to mind when writing them. I guess that
the kernel has policies about how drivers should rely on each other, I
would want to learn about that.

I think we should merge the four drivers into a single one, or at least
(if there is one good reason to access the parallel port using two
different methods) the last three drivers into a single one. I volunteer
to do so, but I want to ear opinions about the idea before going on.

Comments welcome (requested, even).

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

WARNING: multiple messages have this Message-ID (diff)
From: Jean Delvare <khali@linux-fr.org>
To: Simon Vogl <simon@voxel.at>, Daniel Smolik <marvin@sitour.cz>
Cc: Greg KH <greg@kroah.com>,
	sensors@stimpy.netroedge.com, linux-kernel@vger.kernel.org
Subject: I2C parallel port adapters drivers
Date: Sun, 2 Nov 2003 13:23:42 +0100	[thread overview]
Message-ID: <20031102132342.79920c6f.khali@linux-fr.org> (raw)


Hi all,

I have been playing with I2C parallel port adapters drivers for the last
few days and I believe that some cleanups would be welcome. I will
expose the facts as I gathered and understood them, and then do some
proposals about what I think should be made.

There are four different drivers that let you use the parallel port as
an I2C bus.

i2c-philips-par
i2c-elv
i2c-velleman
i2c-pport

The first three are already present in Linux 2.4 and have also been
ported to Linux 2.6. The fourth is obviously newer (admittedly derived
from i2c-velleman) and only present in i2c CVS.

The last three drivers are very, very similar. Take a look at them, and
you'll see that they only differ in which pins are used for the I2C bus'
SCL and SDA lines. They access the parallel port directly, without using
the parport module.

The first one, i2c-philips-par, is different, since it relies on the
parport module. That said, it is similar to the other ones in spirit,
using the parallel port pins as an I2C bus. Only the access method
differ.

My point is that we don't need four different modules for the very same
purpose. We'd better have one single module, supporting all adapter
types through a parameter. The i2c-philips-par module already has such a
mechanism, allowing for two different pins configuration trough its type
parameter.

I know have to understand why one module is using the parport module,
while the other ones are bypassing it. Do we have a reason to prefer one
method to the other? Using the hardware I have, I could check that both
methods are working (at least for me), but I might be missing something
the original modules authors had to mind when writing them. I guess that
the kernel has policies about how drivers should rely on each other, I
would want to learn about that.

I think we should merge the four drivers into a single one, or at least
(if there is one good reason to access the parallel port using two
different methods) the last three drivers into a single one. I volunteer
to do so, but I want to ear opinions about the idea before going on.

Comments welcome (requested, even).

-- 
Jean Delvare
http://www.ensicaen.ismra.fr/~delvare/

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

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-02 12:23 Jean Delvare [this message]
2005-05-19  6:24 ` I2C parallel port adapters drivers Jean Delvare
2003-11-07  9:49 ` DI Dr Simon Vogl
2005-05-19  6:24   ` DI Dr Simon Vogl
2003-11-07 21:36   ` Jean Delvare
2005-05-19  6:24     ` Jean Delvare
2003-11-09 17:38     ` Dr. Simon Vogl
2005-05-19  6:24       ` Dr. Simon Vogl
2003-11-09 21:23       ` Jean Delvare
2005-05-19  6:24         ` Jean Delvare
2003-11-14  1:11 ` Greg KH
2005-05-19  6:24   ` Greg KH
2005-05-19  6:24 ` Mark Studebaker

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=20031102132342.79920c6f.khali@linux-fr.org \
    --to=khali@linux-fr.org \
    --cc=greg@kroah.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marvin@sitour.cz \
    --cc=sensors@stimpy.netroedge.com \
    --cc=simon@voxel.at \
    /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.