1. 03 8月, 2017 4 次提交
  2. 02 8月, 2017 4 次提交
    • N
      ravb: add workaround for clock when resuming with WoL enabled · fbf3d034
      Niklas Söderlund 提交于
      The renesas-cpg-mssr clock driver are not yet aware of PSCI sleep where
      power is cut to the SoC. When resuming from this state with WoL enabled
      the enable count of the ravb clock is 1 and the clock driver thinks the
      clock is already on when PM core enables the clock and increments the
      enable count to 2. This will result in the ravb driver failing to talk
      to the hardware since the module clock is off. Work around this by
      forcing the enable count to 0 and then back to 2 when resuming with WoL
      enabled.
      
      This workaround should be reverted once the renesas-cpg-mssr clock
      driver becomes aware of this PSCI sleep behavior.
      Signed-off-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
      Acked-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fbf3d034
    • N
      ravb: add wake-on-lan support via magic packet · 3e3d6477
      Niklas Söderlund 提交于
      WoL is enabled in the suspend callback by setting MagicPacket detection
      and disabling all interrupts expect MagicPacket. In the resume path the
      driver needs to reset the hardware to rearm the WoL logic, this prevents
      the driver from simply restoring the registers and to take advantage of
      that ravb was not suspended to reduce resume time. To reset the
      hardware the driver closes the device, sets it in reset mode and reopens
      the device just like it would do in a normal suspend/resume scenario
      without WoL enabled, but it both closes and opens the device in the
      resume callback since the device needs to be reset for WoL to work.
      
      One quirk needed for WoL is that the module clock needs to be prevented
      from being switched off by Runtime PM. To keep the clock alive the
      suspend callback need to call clk_enable() directly to increase the
      usage count of the clock. Then when Runtime PM decreases the clock usage
      count it won't reach 0 and be switched off.
      Signed-off-by: NNiklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
      Acked-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3e3d6477
    • S
      net-next: mediatek: add support for MediaTek MT7622 SoC · 42c03844
      Sean Wang 提交于
      This patch adds the driver for ethernet controller on MT7622 SoC. It has
      the similar handling logic as the previously MT7623 does, but there are
      additions against with MT7623 SoC, the shared SGMII given for the dual
      GMACs and including 5-ports 10/100 embedded switch support (ESW) as the
      GMAC1 option, thus more clocks consumers for the extra feature are
      introduced here. So for ease portability and maintenance, those
      differences all are being kept inside the platform data as other drivers
      usually do. Currently testing successfully is done with those patches for
      the conditions such as GMAC2 with IP1001 PHY via RGMII and GMAC1/2 with
      RTL8211F PHY via SGMII.
      Signed-off-by: NSean Wang <sean.wang@mediatek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      42c03844
    • S
      net-next: mediatek: add platform data to adapt into various hardware · 2ec50f57
      Sean Wang 提交于
      This patch is the preparation patch in order to adapt into various
      hardware through adding platform data which holds specific characteristics
      among MediaTek SoCs and introducing the unified clock handler for those
      distinct clock requirements depending on different features such as
      TRGMII and SGMII getting support on the target SoC. And finally, add
      enhancement with given the generic description for Kconfig and remove the
      unnecessary machine type dependency in Makefile.
      Signed-off-by: NSean Wang <sean.wang@mediatek.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2ec50f57
  3. 01 8月, 2017 15 次提交
  4. 31 7月, 2017 2 次提交
    • A
      net: fec: Allow reception of frames bigger than 1522 bytes · fbbeefdd
      Andrew Lunn 提交于
      The FEC Receive Control Register has a 14 bit field indicating the
      longest frame that may be received. It is being set to 1522. Frames
      longer than this are discarded, but counted as being in error.
      
      When using DSA, frames from the switch has an additional header,
      either 4 or 8 bytes if a Marvell switch is used. Thus a full MTU frame
      of 1522 bytes received by the switch on a port becomes 1530 bytes when
      passed to the host via the FEC interface.
      
      Change the maximum receive size to 2048 - 64, where 64 is the maximum
      rx_alignment applied on the receive buffer for AVB capable FEC
      cores. Use this value also for the maximum receive buffer size. The
      driver is already allocating a receive SKB of 2048 bytes, so this
      change should not have any significant effects.
      
      Tested on imx51, imx6, vf610.
      Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fbbeefdd
    • A
      net: fec: Issue error for missing but expected PHY · 9558df3a
      Andrew Lunn 提交于
      If the PHY is missing but expected, e.g. because of a typ0 in the dt
      file, it is not possible to open the interface. ip link returns:
      
      RTNETLINK answers: No such device
      
      It is not very obvious what the problem is. Add a netdev_err() in this
      case to make it easier to debug the issue.
      
      [   21.409385] fec 2188000.ethernet eth0: Unable to connect to phy
      RTNETLINK answers: No such device
      Signed-off-by: NAndrew Lunn <andrew@lunn.ch>
      Acked-by: NFugang Duan <fugang.duan@nxp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9558df3a
  5. 30 7月, 2017 11 次提交
  6. 28 7月, 2017 4 次提交