1. 26 6月, 2020 1 次提交
    • A
      net: phy: mscc: avoid skcipher API for single block AES encryption · 5a3235e5
      Ard Biesheuvel 提交于
      The skcipher API dynamically instantiates the transformation object
      on request that implements the requested algorithm optimally on the
      given platform. This notion of optimality only matters for cases like
      bulk network or disk encryption, where performance can be a bottleneck,
      or in cases where the algorithm itself is not known at compile time.
      
      In the mscc case, we are dealing with AES encryption of a single
      block, and so neither concern applies, and we are better off using
      the AES library interface, which is lightweight and safe for this
      kind of use.
      
      Note that the scatterlist API does not permit references to buffers
      that are located on the stack, so the existing code is incorrect in
      any case, but avoiding the skcipher and scatterlist APIs entirely is
      the most straight-forward approach to fixing this.
      
      Cc: Antoine Tenart <antoine.tenart@bootlin.com>
      Cc: Andrew Lunn <andrew@lunn.ch>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Heiner Kallweit <hkallweit1@gmail.com>
      Cc: "David S. Miller" <davem@davemloft.net>
      Cc: Jakub Kicinski <kuba@kernel.org>
      Fixes: 28c5107a ("net: phy: mscc: macsec support")
      Reviewed-by: NEric Biggers <ebiggers@google.com>
      Signed-off-by: NArd Biesheuvel <ardb@kernel.org>
      Tested-by: NAntoine Tenart <antoine.tenart@bootlin.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      5a3235e5
  2. 14 6月, 2020 1 次提交
    • M
      treewide: replace '---help---' in Kconfig files with 'help' · a7f7f624
      Masahiro Yamada 提交于
      Since commit 84af7a61 ("checkpatch: kconfig: prefer 'help' over
      '---help---'"), the number of '---help---' has been gradually
      decreasing, but there are still more than 2400 instances.
      
      This commit finishes the conversion. While I touched the lines,
      I also fixed the indentation.
      
      There are a variety of indentation styles found.
      
        a) 4 spaces + '---help---'
        b) 7 spaces + '---help---'
        c) 8 spaces + '---help---'
        d) 1 space + 1 tab + '---help---'
        e) 1 tab + '---help---'    (correct indentation)
        f) 1 tab + 1 space + '---help---'
        g) 1 tab + 2 spaces + '---help---'
      
      In order to convert all of them to 1 tab + 'help', I ran the
      following commend:
      
        $ find . -name 'Kconfig*' | xargs sed -i 's/^[[:space:]]*---help---/\thelp/'
      Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      a7f7f624
  3. 27 5月, 2020 1 次提交
  4. 01 5月, 2020 1 次提交
  5. 23 4月, 2020 2 次提交
  6. 27 3月, 2020 1 次提交
  7. 10 3月, 2020 1 次提交
  8. 07 3月, 2020 1 次提交
  9. 18 2月, 2020 1 次提交
  10. 28 1月, 2020 1 次提交
  11. 24 1月, 2020 2 次提交
  12. 15 1月, 2020 1 次提交
  13. 11 1月, 2020 2 次提交
  14. 12 12月, 2019 1 次提交
  15. 15 11月, 2019 1 次提交
  16. 08 11月, 2019 1 次提交
    • M
      net: phy: at803x: add missing dependency on CONFIG_REGULATOR · dddb318b
      Madalin Bucur 提交于
      Compilation fails on PPC targets as CONFIG_REGULATOR is not set and
      drivers/regulator/devres.c is not compiled in while functions exported
      there are used by drivers/net/phy/at803x.c. Here's the error log:
      
        LD      .tmp_vmlinux1
      drivers/net/phy/at803x.o: In function `at803x_rgmii_reg_set_voltage_sel':
      drivers/net/phy/at803x.c:294: undefined reference to `.rdev_get_drvdata'
      drivers/net/phy/at803x.o: In function `at803x_rgmii_reg_get_voltage_sel':
      drivers/net/phy/at803x.c:306: undefined reference to `.rdev_get_drvdata'
      drivers/net/phy/at803x.o: In function `at8031_register_regulators':
      drivers/net/phy/at803x.c:359: undefined reference to `.devm_regulator_register'
      drivers/net/phy/at803x.c:365: undefined reference to `.devm_regulator_register'
      drivers/net/phy/at803x.o:(.data.rel+0x0): undefined reference to `regulator_list_voltage_table'
      linux/Makefile:1074: recipe for target 'vmlinux' failed
      make[1]: *** [vmlinux] Error 1
      
      Fixes: 2f664823 ("net: phy: at803x: add device tree binding")
      Signed-off-by: NMadalin Bucur <madalin.bucur@nxp.com>
      Reviewed-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      dddb318b
  17. 07 11月, 2019 2 次提交
  18. 26 9月, 2019 1 次提交
  19. 17 8月, 2019 1 次提交
  20. 07 8月, 2019 1 次提交
    • N
      net: mdio-octeon: Fix Kconfig warnings and build errors · b8fb6406
      Nathan Chancellor 提交于
      After commit 171a9bae ("staging/octeon: Allow test build on
      !MIPS"), the following combination of configs cause a few Kconfig
      warnings and build errors (distilled from arm allyesconfig and Randy's
      randconfig builds):
      
          CONFIG_NETDEVICES=y
          CONFIG_STAGING=y
          CONFIG_COMPILE_TEST=y
      
      and CONFIG_OCTEON_ETHERNET as either a module or built-in.
      
      WARNING: unmet direct dependencies detected for MDIO_OCTEON
        Depends on [n]: NETDEVICES [=y] && MDIO_DEVICE [=y] && MDIO_BUS [=y]
      && 64BIT [=n] && HAS_IOMEM [=y] && OF_MDIO [=n]
        Selected by [y]:
        - OCTEON_ETHERNET [=y] && STAGING [=y] && (CAVIUM_OCTEON_SOC ||
      COMPILE_TEST [=y]) && NETDEVICES [=y]
      
      In file included from ../drivers/net/phy/mdio-octeon.c:14:
      ../drivers/net/phy/mdio-cavium.h:111:36: error: implicit declaration of
      function ‘writeq’; did you mean ‘writel’?
      [-Werror=implicit-function-declaration]
        111 | #define oct_mdio_writeq(val, addr) writeq(val, (void *)addr)
            |                                    ^~~~~~
      
      CONFIG_64BIT is not strictly necessary if the proper readq/writeq
      definitions are included from io-64-nonatomic-lo-hi.h.
      
      CONFIG_OF_MDIO is not needed when CONFIG_COMPILE_TEST is enabled because
      of commit f9dc9ac5 ("of/mdio: Add dummy functions in of_mdio.h.").
      
      Fixes: 171a9bae ("staging/octeon: Allow test build on !MIPS")
      Reported-by: Nkbuild test robot <lkp@intel.com>
      Reported-by: NMark Brown <broonie@kernel.org>
      Reported-by: NRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: NNathan Chancellor <natechancellor@gmail.com>
      Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b8fb6406
  21. 03 8月, 2019 1 次提交
    • A
      net: phy: Add mdio-aspeed · f160e994
      Andrew Jeffery 提交于
      The AST2600 design separates the MDIO controllers from the MAC, which is
      where they were placed in the AST2400 and AST2500. Further, the register
      interface is reworked again, so now we have three possible different
      interface implementations, however this driver only supports the
      interface provided by the AST2600. The AST2400 and AST2500 will continue
      to be supported by the MDIO support embedded in the FTGMAC100 driver.
      
      The hardware supports both C22 and C45 mode, but for the moment only C22
      support is implemented.
      Signed-off-by: NAndrew Jeffery <andrew@aj.id.au>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f160e994
  22. 10 6月, 2019 1 次提交
  23. 27 5月, 2019 1 次提交
  24. 21 5月, 2019 1 次提交
  25. 24 4月, 2019 1 次提交
    • K
      net: phy: mscc: add support for VSC8514 PHY. · e4f9ba64
      Kavya Sree Kotagiri 提交于
      The VSC8514 PHY is a 4-ports PHY that is 10/100/1000BASE-T, 100BASE-FX,
      1000BASE-X, can communicate with the MAC via QSGMII.
      The MAC interface protocol for each port within QSGMII can
      be either 1000BASE-X or SGMII, if the QSGMII MAC that the VSC8514 is
      connecting to supports this functionality.
      VSC8514 also supports SGMII MAC-side autonegotiation on each individual
      port, downshifting, can set the blinking pattern of each of its 4 LEDs,
      SyncE, 1000BASE-T Ring Resiliency as well as HP Auto-MDIX detection.
      
      This adds support for 10BASE-T, 100BASE-TX, and 1000BASE-T,
      QSGMII link with the MAC, downshifting, HP Auto-MDIX detection
      and blinking pattern for its 4 LEDs.
      
      The GPIO register bank is a set of registers that are common to all PHYs
      in the package. So any modification in any register of this bank affects
      all PHYs of the package.
      
      If the PHYs haven't been reset before booting the Linux kernel and were
      configured to use interrupts for e.g. link status updates, it is
      required to clear the interrupts mask register of all PHYs before being
      able to use interrupts with any PHY. The first PHY of the package that
      will be init will take care of clearing all PHYs interrupts mask
      registers. Thus, we need to keep track of the init sequence in the
      package, if it's already been done or if it's to be done.
      
      Most of the init sequence of a PHY of the package is common to all PHYs
      in the package, thus we use the SMI broadcast feature which enables us
      to propagate a write in one register of one PHY to all PHYs in the same
      package.
      Signed-off-by: NKavya Sree Kotagiri <kavyasree.kotagiri@microchip.com>
      Signed-off-by: NQuentin Schulz <quentin.schulz@bootlin.com>
      Co-developed-by: NQuentin Schulz <quentin.schulz@bootlin.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e4f9ba64
  26. 07 4月, 2019 1 次提交
  27. 24 3月, 2019 2 次提交
  28. 22 3月, 2019 1 次提交
  29. 05 3月, 2019 1 次提交
  30. 28 2月, 2019 1 次提交
  31. 13 9月, 2018 1 次提交
  32. 22 7月, 2018 1 次提交
    • G
      net: phy: sfp: Do not use "imply HWMON" · b5293443
      Guenter Roeck 提交于
      "imply HWMON" was supposed to ensure that the SFP phy code can be built
      with HWMON enabled or disabled while at the same time ensuring that
      HWMON is not built as module if SFP is built into the kernel.
      Unfortunately, that does not work as intended. With "allmodconfig", it
      results in several unrelated HWMON drivers to be disabled instead of
      being built as module as expected.
      
      Let's use the old "depends on HWMON || HWMON=n" instead. This is slightly
      different (it enforces SFP to be built as module if HWMON is built as
      module), but it is better than the alternative of using "IS_REACHABLE()"
      in the driver since that would disable sensor support if HWMON is built
      as module and SFP is built into the kernel.
      
      Fixes: 1323061a ("net: phy: sfp: Add HWMON support for module sensors")
      Cc: Andrew Lunn <andrew@lunn.ch>
      Signed-off-by: NGuenter Roeck <linux@roeck-us.net>
      Reviewed-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      b5293443
  33. 19 7月, 2018 1 次提交
  34. 18 7月, 2018 1 次提交
    • A
      net: phy: sfp: Add HWMON support for module sensors · 1323061a
      Andrew Lunn 提交于
      SFP modules can contain a number of sensors. The EEPROM also contains
      recommended alarm and critical values for each sensor, and indications
      of if these have been exceeded. Export this information via
      HWMON. Currently temperature, VCC, bias current, transmit power, and
      possibly receiver power is supported.
      
      The sensors in the modules can either return calibrate or uncalibrated
      values. Uncalibrated values need to be manipulated, using coefficients
      provided in the SFP EEPROM. Uncalibrated receive power values require
      floating point maths in order to calibrate them. Performing this in
      the kernel is hard. So if the SFP module indicates it uses
      uncalibrated values, RX power is not made available.
      
      With this hwmon device, it is possible to view the sensor values using
      lm-sensors programs:
      
      in0:          +3.29 V  (crit min =  +2.90 V, min =  +3.00 V)
                             (max =  +3.60 V, crit max =  +3.70 V)
      temp1:        +33.0°C  (low  =  -5.0°C, high = +80.0°C)
                             (crit low = -10.0°C, crit = +85.0°C)
      power1:      1000.00 nW (max = 794.00 uW, min =  50.00 uW)  ALARM (LCRIT)
                             (lcrit =  40.00 uW, crit = 1000.00 uW)
      curr1:        +0.00 A  (crit min =  +0.00 A, min =  +0.00 A)  ALARM (LCRIT, MIN)
                             (max =  +0.01 A, crit max =  +0.01 A)
      
      The scaling sensors performs on the bias current is not particularly
      good. The raw values are more useful:
      
      curr1:
        curr1_input: 0.000
        curr1_min: 0.002
        curr1_max: 0.010
        curr1_lcrit: 0.000
        curr1_crit: 0.011
        curr1_min_alarm: 1.000
        curr1_max_alarm: 0.000
        curr1_lcrit_alarm: 1.000
        curr1_crit_alarm: 0.000
      
      In order to keep the I2C overhead to a minimum, the constant values,
      such as limits and calibration coefficients are read once at module
      insertion time. Thus only reading *_input and *_alarm properties
      requires i2c read operations.
      Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      Acked-by: NGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1323061a
  35. 23 6月, 2018 1 次提交