1. 21 Dec, 2004 3 commits
  2. 17 Dec, 2004 2 commits
  3. 15 Dec, 2004 5 commits
    • Domen Puncer's avatar
      [PATCH] it87: /proc/ioports fix · 2e3c2c1b
      Domen Puncer authored
      When request_region is called name is set to "", use module name.
      Signed-off-by: default avatarDomen Puncer <domen@coderock.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      2e3c2c1b
    • Jean Delvare's avatar
      [PATCH] I2C: i2c-algo-bit should support I2C_FUNC_I2C · 6c452565
      Jean Delvare authored
      > Very few drivers seem to support the I2C_FUNC_I2C functionality, is
      > there a reason for that?
      
      Yes, most bus drivers are for SMBus, not I2C, masters. SMBus is a subset
      of I2C. These SMBus master are fully I2C-capable, although in most cases
      it doesn't matter. Most chip drivers are for SMBus clients as well.
      Almost all hardware monitoring chips are SMBus devices. So it's not
      surprising not to see I2C_FUNC_I2C widely used.
      
      > I have an I2C bus on my platform constructed from a couple of GPIO lines
      > using the i2c-algo-bit driver. The device on the bus is a DS1307 I2C RTC
      > and the driver for that currently checks for
      > 	I2C_FUNC_SMBUS_WORD_DATA | I2C_FUNC_SMBUS_WRITE_BYTE
      > however the datasheet suggests it is a simple i2c device with none of
      > this smbus stuff, Russell King queried this here
      > http://www.arm.linux.org.uk/developer/patches/viewpatch.php?id=2021/1
      
      First, note that all SMBus commands are valid I2C transfers. In fact,
      the SMBus specification doesn't do much except put names on specific I2C
      transfers, and sometimes give meanings to the data being transfered. As
      a result, "I2C" clients, although not specifically SMBus-compatible, may
      enjoy SMBus commands such as SMBUS_READ_BYTE, SMBUS_READ_BYTE_DATA and
      SMBUS_WRITE_BYTE_DATA. One typical example of that are EEPROMs and the
      eeprom driver. It relies on i2c_smbus_write_byte and i2c_smbus_read_byte
      (BTW I just noticed that it doesn't properly check for these
      functionalities... have to fix that) because it's so much easier to call
      these standard functions than rewrite I2C code manually. Also, this let
      us access the EEPROMs on SMBus (non-I2C) busses.
      
      Now, note that Russell is not quite correct in is assertion: "Do we
      really require SMBUS functionality, or is i2c functionality sufficient?"
      It's actually the other way around. SMBus puts restrictions on what a
      valid I2C transfer is. "Do we need the full I2C functionality or is the
      SMBus subset sufficient?" would make more sense.
      
      As for the exact functionality you need to check, let's just see how you
      access the bus. As far as I can see (providing that the code below
      Russell's comments is still valid), you rely on:
       * i2c_smbus_write_byte_data
       * i2c_smbus_read_byte_data
       * i2c_transfer
      
      So yo *need* to check for the availability of I2C_FUNC_SMBUS_BYTE_DATA
      on the adapter (which is part of I2C_FUNC_SMBUS_EMUL so any bus driver
      using that, including any relying on i2c-algo-bit, will work with your
      client driver) for the first two. And you also need to check for
      I2C_FUNC_I2C for the third one.
      
      Of course, any adapter with I2C_FUNC_I2C will be able to do SMBus byte
      data transfers, but since you do not use i2c_transfer to do them, you
      need to check the functionality separately (I think).
      
      Also, I think that what you do with i2c_transfer is similar to
      I2C_FUNC_SMBUS_READ_I2C_BLOCK, which is supported by some SMBus
      (non-I2C) masters. If you convert your code to use
      i2c_smbus_read_i2c_block_data, then you don't rely on the full I2C
      capatbilities of the bus, which means that your chip driver will be
      useable on more plateforms. That said, note that this feature is
      unimplemented on most SMBus master drivers as of now, and broken on a
      number of others (but I guess we would start paying more attention to
      them if there were more users for this function).
      
      > If I change it to a check for I2C_FUNC_I2C and change the algo-bit
      > driver to declare I2C_FUNC_I2C then the driver continues to work fine.
      
      You are right that i2c-algo-bit should declare itself I2C_FUNC_I2C
      capable. I even think that every bus being I2C_FUNC_SMBUS_EMUL capable
      is very likely to be I2C_FUNC_I2C capable. This means that other
      algorithms (ite, pcf, maybe pca) could most probably be declared
      I2C_FUNC_I2C capable as well. Can anyone confirm?
      
      > Given the above, is the following patch appropriate, or is there
      > something about the relationship between i2c and smbus that I don't
      > understand.
      
      I admit that the relationship between I2C and SMBus is somewhat tricky,
      it took me some time to get it and even then I am sometimes not sure to
      understand exactly what implies what ;) So we cannot blame you for not
      getting it at first. I hope I helped make things a little clearer. If
      not I welcome questions.
      
      Whether or not you change your code to use SMBus only in your driver to
      make it more widely useable, your patch to i2c-algo-bit is valid, I am
      signing it too and will apply it to the 2.4 version of the driver as
      well.
      Signed-off-by: default avatarIan Campbell <icampbell@arcom.com>
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      6c452565
    • Ian Campbell's avatar
    • Jean Delvare's avatar
      [PATCH] I2C: use chip driver name to request regions · ed6579b1
      Jean Delvare authored
      > Trivial patch against 2.6.10-rc3-bk2.
      > When request_region is called name is set to "", use module name.
      
      Correct. I even think we should do the same for other chip drivers. For
      now they all use an arbitrary string. Using the driver's name would be
      both more consistent and more efficient (spares some bytes of memory).
      Signed-off-by: default avatarJean Delvare <khali@linux-fr.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      ed6579b1
    • Evgeniy Polyakov's avatar
      [PATCH] w1: Documentation bits for generic w1 behaviour. · 6237b3b3
      Evgeniy Polyakov authored
      Documentation bits for generic w1 behaviour.
      Signed-off-by: default avatarEvgeniy Polyakov <johnpol@2ka.mipt.ru>
      Signed-off-by: default avatarGreg Kroah-Hartman <greg@kroah.com>
      6237b3b3
  4. 14 Dec, 2004 8 commits
  5. 13 Dec, 2004 22 commits