Skip to content

L
linux
An error occurred fetching the project authors.
Switch branch/tag
  1. 24 Aug, 2018 1 commit
  3. 17 Aug, 2018 2 commits
  5. 14 Aug, 2018 1 commit
  7. 11 Aug, 2018 1 commit
  9. 09 Aug, 2018 1 commit
    • Hans de Goede's avatar
      platform/x86: Add ACPI i2c-multi-instantiate pseudo driver · e64e8498
      Hans de Goede authored 
      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: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: default avatarWolfram Sang <wsa@the-dreams.de>
Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      e64e8498
  11. 08 Aug, 2018 1 commit
  13. 07 Aug, 2018 1 commit
  15. 02 Aug, 2018 4 commits
  17. 01 Aug, 2018 2 commits
  19. 31 Jul, 2018 1 commit
  21. 30 Jul, 2018 1 commit
  23. 27 Jul, 2018 3 commits
  25. 26 Jul, 2018 1 commit
  27. 25 Jul, 2018 5 commits
  29. 24 Jul, 2018 3 commits
  31. 23 Jul, 2018 2 commits
  33. 21 Jul, 2018 1 commit
  35. 20 Jul, 2018 3 commits
  37. 19 Jul, 2018 1 commit
  39. 18 Jul, 2018 5 commits
    • Krzysztof Kozlowski's avatar
      MAINTAINERS: Drop inactive Vitaly Bordug's email · a2ec9d14
      Krzysztof Kozlowski authored 
      The Vitaly Bordug's email bounces ("ru.mvista.com: Name or service not
known") and there was no activity (ack, review, sign) since 2009.

Cc: Vitaly Bordug <vitb@kernel.crashing.org>
Cc: Pantelis Antoniou <pantelis.antoniou@gmail.com>
Cc: "David S. Miller" <davem@davemloft.net>
Signed-off-by: default avatarKrzysztof Kozlowski <krzk@kernel.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      a2ec9d14
    • Nishanth Menon's avatar
      arm64: dts: ti: Add support for AM654 EVM base board · d0a064be
      Nishanth Menon authored 
      The EValuation Module(EVM) platform for AM654 consists of a
common Base board + one or more of daughter cards, which include:
a) "Personality Modules", which can be specific to a profile, such as
 ICSSG enabled or Multi-media (including audio).
b) SERDES modules, which may be 2 lane PCIe or two port PCIe + USB2
c) Camera daughter card
d) various display panels

Among other options. There are two basic configurations defined which
include an "EVM" configuration and "IDK" (Industrial development kit)
which differ in the specific combination of daughter cards that are
used.

To simplify support, we choose to support just the base board as the
core device tree file and all daughter cards would be expected to be
device tree overlays.
Reviewed-by: default avatarTony Lindgren <tony@atomide.com>
Signed-off-by: default avatarLokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: default avatarNishanth Menon <nm@ti.com>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      d0a064be
    • Nishanth Menon's avatar
      arm64: dts: ti: Add Support for AM654 SoC · ea47eed3
      Nishanth Menon authored 
      The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.

Some highlights of this SoC are:
* Quad ARMv8 A53 cores split over two clusters
* GICv3 compliant GIC500
* Configurable L3 Cache and IO-coherent architecture
* Dual lock-step capable R5F uC for safety-critical applications
* High data throughput capable distributed DMA architecture under NAVSS
* Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
  PRUs and dual RTUs
* Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
* Centralized System Controller for Security, Power, and Resource
  management.
* Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
* Flash subsystem with OSPI and Hyperbus interfaces
* Multimedia capability with CAL, DSS7-UL, SGX544, McASP
* Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
  GPIO

See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7

NOTE:
1. AM654 is the first of the device variants, hence we introduce a
   generic am65.dtsi.
2. We indicate the proper bus topology, the ranges are elaborated in
   each bus segment instead of using the top level ranges to make sure
   that peripherals in each segment use the address space accurately.
3. Peripherals in each bus segment is maintained in a separate dtsi
   allowing for reuse in different bus segment representation from a
   different core such as R5. This is also the reason for maintaining a
   1-1 address map in the ranges.
4. Cache descriptions follow the ARM64 standard description.

Further tweaks may be necessary as we introduce more complex devices,
but can be introduced in context of the device introduction.
Reviewed-by: default avatarTony Lindgren <tony@atomide.com>
Signed-off-by: default avatarBenjamin Fair <b-fair@ti.com>
Signed-off-by: default avatarNishanth Menon <nm@ti.com>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      ea47eed3
    • Nishanth Menon's avatar
      dt-bindings: arm: ti: Add bindings for AM654 SoC · ad527a91
      Nishanth Menon authored 
      The AM654 SoC is a lead device of the K3 Multicore SoC architecture
platform, targeted for broad market and industrial control with aim to
meet the complex processing needs of modern embedded products.

Some highlights of this SoC are:
* Quad ARMv8 A53 cores split over two clusters
* GICv3 compliant GIC500
* Configurable L3 Cache and IO-coherent architecture
* Dual lock-step capable R5F uC for safety-critical applications
* High data throughput capable distributed DMA architecture under NAVSS
* Three Gigabit Industrial Communication Subsystems (ICSSG), each with dual
  PRUs and dual RTUs
* Hardware accelerator block containing AES/DES/SHA/MD5 called SA2UL
* Centralized System Controller for Security, Power, and Resource
  management.
* Dual ADCSS, eQEP/eCAP, eHRPWM, dual CAN-FD
* Flash subsystem with OSPI and Hyperbus interfaces
* Multimedia capability with CAL, DSS7-UL, SGX544, McASP
* Peripheral connectivity including USB3, PCIE, MMC/SD, GPMC, I2C, SPI,
  GPIO

See AM65x Technical Reference Manual (SPRUID7, April 2018)
for further details: http://www.ti.com/lit/pdf/spruid7Reviewed-by: default avatarTony Lindgren <tony@atomide.com>
Signed-off-by: default avatarNishanth Menon <nm@ti.com>
Reviewed-by: default avatarRob Herring <robh@kernel.org>
Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      ad527a91
    • Linus Walleij's avatar
      net: dsa: realtek-smi: Add Realtek SMI driver · d8652956
      Linus Walleij authored 
      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: default avatarLinus Walleij <linus.walleij@linaro.org>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d8652956
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7