1. 11 8月, 2018 1 次提交
  2. 09 8月, 2018 1 次提交
    • H
      platform/x86: Add ACPI i2c-multi-instantiate pseudo driver · e64e8498
      Hans de Goede 提交于
      On systems with ACPI instantiated i2c-clients, normally there is 1 fw_node
      per i2c-device and that fw-node contains 1 I2cSerialBus resource for that 1
      i2c-device.
      
      But in some rare cases the manufacturer has decided to describe multiple
      i2c-devices in a single ACPI fwnode with multiple I2cSerialBus resources.
      
      An earlier attempt to fix this in the i2c-core resulted in a lot of extra
      code to support this corner-case.
      
      This commit introduces a new i2c-multi-instantiate driver which fixes this
      in a different way. This new driver can be built as a module which will
      only loaded on affected systems.
      
      This driver will instantiate a new i2c-client per I2cSerialBus resource,
      using the driver_data from the acpi_device_id it is binding to to tell it
      which chip-type (and optional irq-resource) to use when instantiating.
      
      Note this driver depends on a platform device being instantiated for the
      ACPI fwnode, see the i2c_multi_instantiate_ids list of ACPI device-ids in
      drivers/acpi/scan.c: acpi_device_enumeration_by_parent().
      Acked-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: NWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e64e8498
  3. 08 8月, 2018 1 次提交
  4. 03 8月, 2018 1 次提交
  5. 02 8月, 2018 2 次提交
  6. 01 8月, 2018 1 次提交
  7. 30 7月, 2018 1 次提交
  8. 28 7月, 2018 2 次提交
  9. 26 7月, 2018 3 次提交
  10. 25 7月, 2018 3 次提交
  11. 24 7月, 2018 1 次提交
  12. 22 7月, 2018 1 次提交
  13. 20 7月, 2018 2 次提交
  14. 19 7月, 2018 1 次提交
  15. 18 7月, 2018 1 次提交
    • L
      net: dsa: realtek-smi: Add Realtek SMI driver · d8652956
      Linus Walleij 提交于
      This adds a driver core for the Realtek SMI chips and a
      subdriver for the RTL8366RB. I just added this chip simply
      because it is all I can test.
      
      The code is a massaged variant of the code that has been
      sitting out-of-tree in OpenWRT for years in the absence of
      a proper switch subsystem. This creates a DSA driver for it.
      I have tried to credit the original authors wherever
      possible.
      
      The main changes I've done from the OpenWRT code:
      
      - Added an IRQ chip inside the RTL8366RB switch to demux and
        handle the line state IRQs.
      
      - Distributed the phy handling out to the PHY driver.
      
      - Added some RTL8366RB code that was missing in the driver at
        the time, such as setting up "green ethernet" with a funny
        jam table and forcing MAC5 (the CPU port) into 1 GBit.
      
      - Select jam table and add the default jam table from the
        vendor driver, also for ASIC "version 0" if need be.
      
      - Do not store jam tables in the device tree, store them
        in the driver.
      
      - Pick in the "initvals" jam tables from OpenWRT's driver
        and make those get selected per compatible for the
        whole system. It's apparently about electrical settings
        for this system and whatnot, not really configuration
        from device tree.
      
      - Implemented LED control: beware of bugs because there are
        no LEDs on the device I am using!
      
      We do not implement custom DSA tags. This is explained in
      a comment in the driver as well: this "tagging protocol" is
      not simply a few extra bytes tagged on to the ethernet
      frame as DSA is used to. Instead, enabling the CPU tags
      will make the switch start talking Realtek RRCP internally.
      For example a simple ping will make this kind of packets
      appear inside the switch:
      
      0000   ff ff ff ff ff ff bc ae c5 6b a8 3d 88 99 a2 00
      0010   08 06 00 01 08 00 06 04 00 01 bc ae c5 6b a8 3d
      0020   a9 fe 01 01 00 00 00 00 00 00 a9 fe 01 02 00 00
      0030   00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      
      As you can see a custom "8899" tagged packet using the
      protocol 0xa2. Norm RRCP appears to always have this
      protocol set to 0x01 according to OpenRRCP. You can also
      see that this is not a ping packet at all, instead the
      switch is starting to talk network management issues
      with the CPU port.
      
      So for now custom "tagging" is disabled.
      
      This was tested on the D-Link DIR-685 with initramfs and
      OpenWRT userspaces and works fine on all the LAN ports
      (lan0 .. lan3). The WAN port is yet not working.
      
      Cc: Antti Seppälä <a.seppala@gmail.com>
      Cc: Roman Yeryomin <roman@advem.lv>
      Cc: Colin Leitner <colin.leitner@googlemail.com>
      Cc: Gabor Juhos <juhosg@openwrt.org>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d8652956
  16. 17 7月, 2018 2 次提交
  17. 13 7月, 2018 2 次提交
  18. 10 7月, 2018 2 次提交
  19. 09 7月, 2018 2 次提交
  20. 06 7月, 2018 1 次提交
  21. 05 7月, 2018 1 次提交
  22. 04 7月, 2018 2 次提交
  23. 03 7月, 2018 1 次提交
  24. 02 7月, 2018 1 次提交
  25. 30 6月, 2018 1 次提交
  26. 29 6月, 2018 1 次提交
  27. 28 6月, 2018 2 次提交