MFC r281828, r289083, r289084, r289091, r289093, r289095, r289097, r289098,

MFC r281828, r289083, r289084, r289091, r289093, r289095, r289097, r289098,
    r289104, r289105, r289118:  various i2c fixes...

  Fix numerous issues in iic(4) and iicbus(4):
  --Allow multiple open iic fds by storing addressing state in cdevpriv
  --Fix, as much as possible, the baked-in race conditions in the iic
  ioctl interface by requesting bus ownership on I2CSTART, releasing it on
  I2CSTOP/I2CRSTCARD, and requiring bus ownership by the current cdevpriv
  to use the I/O ioctls
  --Reduce internal iic buffer size and remove 1K read/write limit by
  iteratively calling iicbus_read/iicbus_write
  --Eliminate dynamic allocation in I2CWRITE/I2CREAD
  --Move handling of I2CRDWR to separate function and improve error handling
  --Add new I2CSADDR ioctl to store address in current cdevpriv so that
  I2CSTART is not needed for read(2)/write(2) to work
  --Redesign iicbus_request_bus() and iicbus_release_bus():
      --iicbus_request_bus() no longer falls through if the bus is already
  owned by the requesting device.  Multiple threads on the same device may
  want exclusive access.  Also, iicbus_release_bus() was never
  device-recursive anyway.
      --Previously, if IICBUS_CALLBACK failed in iicbus_release_bus(), but
  the following iicbus_poll() call succeeded, IICBUS_CALLBACK would not be
  issued again
      --Do not hold iicbus mtx during IICBUS_CALLBACK call.  There are
  several drivers that may sleep in IICBUS_CALLBACK, if IIC_WAIT is passed.
      --Do not loop in iicbus_request_bus if IICBUS_CALLBACK returns
  EWOULDBLOCK; instead pass that to the caller so that it can retry if so
  desired.

  Bugfix: Exit the transfer loop if any read or write operation fails.  Also,
  perform a stop operation on the bus if there was an error, otherwise the
  bus will remain hung forever.  Consistantly use 'if (error != 0)' style in
  the function.

  Mostly rewrite the imx i2c driver.  This started out as an attempt to fix
  one specific problem: the driver didn't check for ACK/NAK after writing a
  slave address byte to the bus, and some slaves signal that they are busy
  (such as when completing an internal write to flash memory) by sending a
  NAK in response to being addressed.

  Use IIC_EBUSBSY and IIC_BUSERR status values consistantly across all drivers.
  Make it clearer what each one means in the comments that define them.

  Add iic2errno(), a helper function to translate IIC_Exxxxx status values to
  errno values that are at least vaguely equivelent.  Also add a new status
  value, IIC_ERESOURCE, to indicate a failure to acquire memory or other
  required resources to complete a transaction.

  Return only IIC_Exxxx status values from iicbus-layer functions.  Most of
  these functions are thin wrappers around calling the hardware-layer driver,
  but some of them do sanity checks and return an error.

  Add a short name, IIC_INTRWAIT, for the common case (IIC_INTR | IIC_WAIT).

  Replace a local sx lock that allowed only one client at a time to access
  an eeprom device with iicbus_request/release_bus(), which achieves the
  same effect and also keeps other i2c slave drivers from clashing on the bus.

git-svn-id: svn://svn.freebsd.org/base/stable/10@289666 ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f