1. 17 7月, 2018 3 次提交
  2. 13 7月, 2018 1 次提交
  3. 22 5月, 2018 1 次提交
    • B
      i2c: Retain info->of_node in i2c_new_device() · 04782265
      Boris Brezillon 提交于
      Currently, of_i2c_register_devices() is responsible for retaining
      info->of_node, but we're about to expose a function to parse I2C board
      info without registering the I2C device.
      
      We could possibly let this function retain ->of_node, but this approach
      is prone to reference leak since people will have to remember to call
      of_node_put() if something goes wrong between the OF node parsing and
      the registration step.
      Let's just retain the ->of_node in i2c_new_register() instead.
      Signed-off-by: NBoris Brezillon <boris.brezillon@bootlin.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      04782265
  4. 15 5月, 2018 2 次提交
  5. 12 4月, 2018 1 次提交
  6. 04 4月, 2018 1 次提交
  7. 03 4月, 2018 1 次提交
  8. 24 3月, 2018 1 次提交
  9. 06 3月, 2018 1 次提交
  10. 05 3月, 2018 1 次提交
    • J
      i2c: core: report OF style module alias for devices registered via OF · af503716
      Javier Martinez Canillas 提交于
      The buses should honor the firmware interface used to register the device,
      but the I2C core reports a MODALIAS of the form i2c:<device> even for I2C
      devices registered via OF.
      
      This means that user-space will never get an OF stype uevent MODALIAS even
      when the drivers modules contain aliases exported from both the I2C and OF
      device ID tables. For example, an Atmel maXTouch Touchscreen registered by
      a DT node with compatible "atmel,maxtouch" has the following module alias:
      
      $ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
      i2c:maxtouch
      
      So udev won't be able to auto-load a module for an OF-only device driver.
      Many OF-only drivers duplicate the OF device ID table entries in an I2C ID
      table only has a workaround for how the I2C core reports the module alias.
      
      This patch changes the I2C core to report an OF related MODALIAS uevent if
      the device was registered via OF. So for the previous example, after this
      patch, the reported MODALIAS for the Atmel maXTouch will be the following:
      
      $ cat /sys/class/i2c-adapter/i2c-8/8-004b/modalias
      of:NtrackpadT<NULL>Catmel,maxtouch
      
      NOTE: This patch may break out-of-tree drivers that were relying on this
            behavior, and only had an I2C device ID table even when the device
            was registered via OF. There are no remaining drivers in mainline
            that do this, but out-of-tree drivers have to be fixed and define
            a proper OF device ID table to have module auto-loading working.
      Signed-off-by: NJavier Martinez Canillas <javierm@redhat.com>
      Tested-by: NDmitry Mastykin <mastichi@gmail.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      af503716
  11. 17 1月, 2018 1 次提交
  12. 16 1月, 2018 3 次提交
  13. 04 12月, 2017 2 次提交
  14. 28 11月, 2017 3 次提交
  15. 02 11月, 2017 1 次提交
  16. 29 10月, 2017 2 次提交
  17. 27 10月, 2017 1 次提交
    • H
      i2c: Allow overriding dev_name through board_info · 728fe6ce
      Hans de Goede 提交于
      For devices not instantiated through ACPI the i2c-client's device-name
      gets set to <busnr>-<addr> by default, e.g. "0-0022" this means that
      the device-name is dependent on the order in which the i2c-busses are
      enumerated.
      
      In some cases having a predictable constant device-name is desirable,
      for example on non device-tree platforms the link between a regulator
      and its consumers is specified by the platform code by setting
      regulator_init_data.consumers. This array identifies the regulator's
      consumers by dev_name and supply(-name). Which requires a constant
      dev_name.
      
      This commit adds a dev_name field to i2c_board_info allowing
      platform code to set a contstant dev_name so that the device can
      be identified by its dev_name in other platform code.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Acked-by: Mark Brown <broonie@kernel.org> (live at ELCE17)
      Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> (live at ELCE17)
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      728fe6ce
  18. 15 8月, 2017 1 次提交
  19. 31 7月, 2017 1 次提交
  20. 01 6月, 2017 7 次提交
  21. 17 4月, 2017 3 次提交
    • H
      i2c: core: Allow drivers to disable i2c-core irq mapping · d1d84bb9
      Hans de Goede 提交于
      By default the i2c-core will try to get an irq with index 0 on ACPI / of
      instantiated devices. This is troublesome on some ACPI systems where the
      irq info at index 0 in the CRS table may contain nonsense and/or point
      to an irqchip for which there is no Linux driver.
      
      If this happens then before this commit the driver's probe method would
      never get called because i2c_device_probe will try to get an irq by
      calling acpi_dev_gpio_irq_get which will always return -EPROBE in this
      case, as it waits for a matching irqchip driver to load. Thus causing
      the driver to not get a chance to bind.
      
      This commit adds a new disable_i2c_core_irq_mapping flag to struct
      i2c_driver which a driver can set to tell the core to skip irq mapping.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      d1d84bb9
    • H
      i2c: core: Add new i2c_acpi_new_device helper function · 605f8fc2
      Hans de Goede 提交于
      By default the i2c subsys creates an i2c-client for the first I2cSerialBus
      resource of an acpi_device, but some acpi_devices have multiple
      I2cSerialBus resources and we may want to instantiate i2c-clients for
      the others.
      
      This commit adds a new i2c_acpi_new_device function which can be used to
      create an i2c-client for any I2cSerialBus resource of an acpi_device.
      
      Note that the other resources may even be on a different i2c bus, so just
      retrieving the client address is not enough.
      
      Here is an example DSDT excerpt from such a device:
      
      Device (WIDR)
      {
          Name (_HID, "INT33FE" /* XPOWER Battery Device */)
          Name (_CID, "INT33FE" /* XPOWER Battery Device */)
          Name (_DDN, "WC PMIC Battery Device")
      <snip>
          Name (RBUF, ResourceTemplate ()
          {
              I2cSerialBusV2 (0x005E, ControllerInitiated, 0x000186A0,
                  AddressingMode7Bit, "\\_SB.PCI0.I2C7",
                  0x00, ResourceConsumer, , Exclusive,
                  )
              I2cSerialBusV2 (0x0036, ControllerInitiated, 0x000186A0,
                  AddressingMode7Bit, "\\_SB.PCI0.I2C1",
                  0x00, ResourceConsumer, , Exclusive,
                  )
              I2cSerialBusV2 (0x0022, ControllerInitiated, 0x00061A80,
                  AddressingMode7Bit, "\\_SB.PCI0.I2C1",
                  0x00, ResourceConsumer, , Exclusive,
                  )
              I2cSerialBusV2 (0x0054, ControllerInitiated, 0x00061A80,
                  AddressingMode7Bit, "\\_SB.PCI0.I2C1",
                  0x00, ResourceConsumer, , Exclusive,
                  )
              GpioInt (Level, ActiveLow, Exclusive, PullNone, 0x0000,
                  "\\_SB.PCI0.I2C7.PMI5", 0x00, ResourceConsumer, ,
                  )
                  {   // Pin list
              0x0012
                  }
              GpioInt (Edge, ActiveLow, ExclusiveAndWake, PullNone, 0x0000,
                  "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                  )
                  {   // Pin list
              0x0005
                  }
              GpioInt (Level, ActiveLow, Exclusive, PullNone, 0x0000,
                  "\\_SB.PCI0.I2C7.PMI5", 0x00, ResourceConsumer, ,
                  )
                  {   // Pin list
              0x0013
                  }
          })
          Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
          {
              Return (RBUF) /* \_SB_.PCI0.I2C7.WIDR.RBUF */
          }
      <snip>
      }
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      605f8fc2
    • H
      i2c: core: Allow getting ACPI info by index · 417f7843
      Hans de Goede 提交于
      Modify struct i2c_acpi_lookup and i2c_acpi_fill_info() to allow
      using them to get the info from a certain index in the ACPI-resource
      list rather then taking the first I2cSerialBus resource.
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      417f7843
  22. 02 4月, 2017 2 次提交