Clean up comments in pvrusb2-eeprom.c

From: Mike Isely <isely@pobox.com>



Signed-off-by: Mike Isely <isely@pobox.com>

1 files changed, 2 insertions, 70 deletions

diff --git a/linux/drivers/media/video/pvrusb2/pvrusb2-eeprom.c b/linux/drivers/media/video/pvrusb2/pvrusb2-eeprom.c
index 634095efc..78bc968c0 100644
--- a/linux/drivers/media/video/pvrusb2/pvrusb2-eeprom.c
+++ b/linux/drivers/media/video/pvrusb2/pvrusb2-eeprom.c
@@ -27,57 +27,8 @@
 
 #define trace_eeprom(...) pvr2_trace(PVR2_TRACE_EEPROM,__VA_ARGS__)
 
-/*
-
-  isely@pobox.com 16-Oct-2005 - There are two method by which we can
-  theoretically retrieve information from the device's eeprom:
-
-  Method #1: We expect tveeprom to attach to our I2C adapter as a
-      client, in which case we send it a command to tell us what it
-      knows about the device.  This is the "indirect" method.
-
-  Method #2: We retrieve the eeprom contents ourselves and call into
-      tveeprom_hauppauge_analog() to parse the data and tell us what
-      it knows about the device.  This is the "direct" method.
-
-  Unfortunately it isn't perfectly clear which method is the best.
-  They each have pros and cons:
-
-  #1 is simpler & more portable and has an API which is more stable.
-
-  #1 doesn't provide as much information as #2 does.  For example, we
-     can't retrieve the device's serial number with method #1.
-
-  #1 requires that tveeprom.ko autonomously detect the eeprom chip on
-     its own; we can't help it out here.  Worse still, it seems that
-     the eeprom in some PVR USB2 devices (like mine) can't be detected
-     correctly (I don't see an ack on a zero length write which is
-     what the I2C core attempts).
-
-  #2 uses an unstable API.  Current the ivtv implementation of #2 uses
-     a completely different tveeprom struct than the v4l
-     implementation of #2.  This causes a usability nightmare.
-
-  Since I can't decide, both methods are implemented below.  Method #2
-  (direct) is the default choice, but if you want to try method #1,
-  then define PVR2_EEPROM_INDIRECT and cross your fingers...
-
-  If you use method #1, please be aware that you won't have a serial
-  number for the device and thus the sysfs interface may be a little
-  different.  In addition, if tveeprom.ko fails to detect the eeprom
-  you may have to force it using standard i2c module options (try
-  force=-1,80).  FINALLY (and this may foreclose this option for you
-  completely), the PVR USB2 eeprom seems to have valid data only in
-  the upper 128 bytes - the lower 128 bytes causes tveeprom.ko to
-  abort.  In method #2 we only read the upper 128 bytes...
-
- */
-
 
 
-
-/* Stuff common to direct approach of operation tveeprom */
-
 /*
 
    Read and analyze data in the eeprom.  Use tveeprom to figure out
@@ -121,7 +72,7 @@ static u8 *pvr2_eeprom_fetch(struct pvr2_hdw *hdw)
 
 	/* FX2 documentation states that a 16bit-addressed eeprom is
 	   expected if the I2C address is an odd number (yeah, this is
-	   strange bit it's what they do) */
+	   strange but it's what they do) */
 	mode16 = (addr & 1);
 	eepromSize = (mode16 ? 4096 : 256);
 	trace_eeprom("Examining %d byte eeprom at location 0x%x"
@@ -165,15 +116,7 @@ static u8 *pvr2_eeprom_fetch(struct pvr2_hdw *hdw)
 }
 
 
-/*VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV*/
-/* BEGIN DIRECT METHOD, V4L ONLY */
-
-
-/* Directly call eeprom analysis function within tveeprom.  This
-   version directly assumes it is talking to the V4L version of
-   tveeprom.ko and does not attempt anything ugly to maintain
-   backwards compatibility. */
-
+/* Directly call eeprom analysis function within tveeprom. */
 int pvr2_eeprom_analyze(struct pvr2_hdw *hdw)
 {
 	u8 *eeprom;
@@ -211,17 +154,6 @@ int pvr2_eeprom_analyze(struct pvr2_hdw *hdw)
 	return 0;
 }
 
-
-
-/* END DIRECT METHOD, V4L ONLY */
-/*^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^*/
-
-
-
-
-
-
-
 /*
   Stuff for Emacs to see, in order to encourage consistent editing style:
   *** Local Variables: ***