1. 18 1月, 2018 10 次提交
    • M
      bnxt_en: Add the new firmware API to query hardware resources. · be0dd9c4
      Michael Chan 提交于
      The new API HWRM_FUNC_RESOURCE_QCAPS provides min and max hardware
      resources.  Use the new API when it is supported by firmware.
      Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      be0dd9c4
    • M
      bnxt_en: Refactor hardware resource data structures. · 6a4f2947
      Michael Chan 提交于
      In preparation for new firmware APIs to allocate hardware resources,
      add a new struct bnxt_hw_resc to hold various min, max and reserved
      resources.  This new structure is common for PFs and VFs.
      Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6a4f2947
    • M
      bnxt_en: Restore MSIX after disabling SRIOV. · 80fcaf46
      Michael Chan 提交于
      After SRIOV has been enabled and disabled, the MSIX vectors assigned to
      the VFs have to be re-initialized.  Otherwise they cannot be re-used by
      the PF.  For example, increasing the number of PF rings after disabling
      SRIOV may fail if the PF uses MSIX vectors previously assigned to the VFs.
      
      To fix this, we add logic in bnxt_restore_pf_fw_resources() to close the
      NIC, clear and re-init MSIX, and re-open the NIC.
      Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      80fcaf46
    • M
      bnxt_en: Refactor bnxt_close_nic(). · 86e953db
      Michael Chan 提交于
      Add a new __bnxt_close_nic() function to do all the work previously done
      in bnxt_close_nic() except waiting for SRIOV configuration.  The new
      function will be used in the next patch as part of SRIOV cleanup.
      Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      86e953db
    • M
      bnxt_en: Update firmware interface to 1.9.0. · 894aa69a
      Michael Chan 提交于
      The version has new firmware APIs to allocate PF/VF resources more
      flexibly.
      
      New toolchains were used to generate this file, resulting in a one-time
      large diffstat.
      Signed-off-by: NMichael Chan <michael.chan@broadcom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      894aa69a
    • M
      net: stmmac: dwmac-meson8b: propagate rate changes to the parent clock · fb7d38a7
      Martin Blumenstingl 提交于
      On Meson8b the only valid input clock is MPLL2. The bootloader
      configures that to run at 500002394Hz which cannot be divided evenly
      down to 125MHz using the m250_div clock. Currently the common clock
      framework chooses a m250_div of 2 - with the internal fixed
      "divide by 10" this results in a RGMII TX clock of 125001197Hz (120Hz
      above the requested 125MHz).
      
      Letting the common clock framework propagate the rate changes up to the
      parent of m250_mux allows us to get the best possible clock rate. With
      this patch the common clock framework calculates a rate of
      very-close-to-250MHz (249999701Hz to be exact) for the MPLL2 clock
      (which is the mux input). Dividing that by 2 (which is an internal,
      fixed divider for the RGMII TX clock) gives us an RGMII TX clock of
      124999850Hz (which is only 150Hz off the requested 125MHz, compared to
      1197Hz based on the MPLL2 rate set by u-boot and the Amlogic GPL kernel
      sources).
      
      SoCs from the Meson GX series are not affected by this change because
      the input clock is FCLK_DIV2 whose rate cannot be changed (which is fine
      since it's running at 1GHz, so it's already a multiple of 250MHz and
      125MHz).
      
      Fixes: 566e8251 ("net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC")
      Suggested-by: NJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Reviewed-by: NJerome Brunet <jbrunet@baylibre.com>
      Tested-by: NJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fb7d38a7
    • M
      net: stmmac: dwmac-meson8b: fix setting the RGMII TX clock on Meson8b · 433c6cab
      Martin Blumenstingl 提交于
      Meson8b only supports MPLL2 as clock input. The rate of the MPLL2 clock
      set by Odroid-C1's u-boot is close to (but not exactly) 500MHz. The
      exact rate is 500002394Hz, which is calculated in
      drivers/clk/meson/clk-mpll.c using the following formula:
      DIV_ROUND_UP_ULL((u64)parent_rate * SDM_DEN, (SDM_DEN * n2) + sdm)
      Odroid-C1's u-boot configures MPLL2 with the following values:
      - SDM_DEN = 16384
      - SDM = 1638
      - N2 = 5
      
      The 250MHz clock (m250_div) inside dwmac-meson8b driver is derived from
      the MPLL2 clock. Due to MPLL2 running slightly faster than 500MHz the
      common clock framework chooses a divider which is too big to generate
      the 250MHz clock (a divider of 2 would be needed, but this is rounded up
      to a divider of 3). This breaks the RTL8211F RGMII PHY on Odroid-C1
      because it requires a (close to) 125MHz RGMII TX clock (on Gbit speeds,
      the IP block internally divides that down to 25MHz on 100Mbit/s
      connections and 2.5MHz on 10Mbit/s connections - we don't need any
      special configuration for that).
      
      Round the divider to the closest value to prevent this issue on Meson8b.
      This means we'll now end up with a clock rate for the RGMII TX clock of
      125001197Hz (= 125MHz plus 1197Hz), which is close-enough to 125MHz.
      This has no effect on the Meson GX SoCs since there fclk_div2 is used as
      input clock, which has a rate of 1000MHz (and thus is divisible cleanly
      to 250MHz and 125MHz).
      
      Fixes: 566e8251 ("net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC")
      Reported-by: NEmiliano Ingrassia <ingrassia@epigenesys.com>
      Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Reviewed-by: NJerome Brunet <jbrunet@baylibre.com>
      Tested-by: NJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      433c6cab
    • M
      net: stmmac: dwmac-meson8b: fix internal RGMII clock configuration · 4f6a71b8
      Martin Blumenstingl 提交于
      Tests (using an oscilloscope and an Odroid-C1 board with a RTL8211F
      RGMII PHY) have shown that the PRG_ETH0 register behaves as follows:
      - bit 4 is a mux to choose between two parent clocks. according to the
        public S805 datasheet the only supported parent clock is MPLL2 (this
        was not verified using the oscilloscope).
        The public S805/S905 datasheet claims that this bit is reserved.
      - bits 9:7 control a one-based divider (register value 1 means "divide
        by 1", etc.) for the input clock. we call this clock the "m250_div"
        clock because it's value is always supposed to be (close to) 250MHz
        (see below for an explanation).
        The description in the public S805/S905 datasheet is a bit cryptic,
        but it comes down to "input clock = 250MHz * value" (which could also
        be expressed as "250MHz = input clock / value")
      - there seems to be an internal fixed divide-by-2 clock which takes the
        output from the m250_div and divides it by 2. This is not unusual on
        Amlogic SoCs, since the SDIO (MMC) driver also uses an internal fixed
        divide-by-2 clock.
        This is not documented in the public S805/S905 datasheet
      - bit 10 controls a gate clock which enables or disables the RGMII TX
        clock (which is an output on the MAC/SoC and an input in the PHY). we
        call this the "rgmii_tx_en" clock. if this bit is set to "0" the RGMII
        TX clock output is close to 0
        The description for this bit in the public S805/S905 datasheet is
        "Generate 25MHz clock for PHY". Based on these tests it's believed
        that this is wrong, and should probably read "Generate the 125MHz
        RGMII TX clock for the PHY"
      - the RGMII TX clock has to be set to 125MHz - the IP block adjusts the
        output (automatically) depending on the line speed (RGMII specifies
        that Gbit connections use a 125MHz clock, 100Mbit/s connections use a
        25MHz clock and 10Mbit/s connections use a 2.5MHz clock. only Gbit and
        100Mbit/s were tested with an oscilloscope). Due to the requirement
        that this clock always has to be set to 125MHz and due to the fixed
        divide-by-2 parent clock this means that m250_div will always end up
        with a rate of (close to) 250MHz.
      - bits 6:5 are the TX delay, which is also named "clock phase" in some
        of Amlogic's older GPL kernel sources.
      
      The PHY also has an XTAL_IN pin where a 25MHz clock has to be provided.
      Tests with the oscilloscope have shown that this is routed to a crystal
      right next to the RTL8211F PHY. The same seems to be true on the Khadas
      VIM2 (which uses a GXM SoC) board - however the 25MHz crystal is on the
      other side of the PCB there.
      
      This updates the clocks in the dwmac-meson8b driver by replacing the
      "m25_div" with the "rgmii_tx_en" clock and additionally introducing a
      fixed divide-by-2 clock between "m250_div" and "rgmii_tx_en".
      Now we also need to set a frequency of 125MHz on the RGMII clock
      (opposed to the 25MHz we set before, with that non-existing
      divide-by-5-or-10 divider).
      
      Special thanks go to Linus Lüssing for testing the various bits and
      checking the results with an oscilloscope on his Odroid-C1!
      
      Fixes: 566e8251 ("net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC")
      Reported-by: NEmiliano Ingrassia <ingrassia@epigenesys.com>
      Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Acked-by: NJerome Brunet <jbrunet@baylibre.com>
      Tested-by: NJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4f6a71b8
    • M
      net: stmmac: dwmac-meson8b: only configure the clocks in RGMII mode · 37512b42
      Martin Blumenstingl 提交于
      Neither the m25_div_clk nor the m250_div_clk or m250_mux_clk are used in
      RMII mode. The m25_div_clk output is routed to the RGMII PHY's "RGMII
      clock".
      This means that we don't need to configure the clocks in RMII mode. The
      driver however did this - with no effect since the clocks are not routed
      to the PHY in RMII mode.
      
      While here also rename meson8b_init_clk to meson8b_init_rgmii_tx_clk to
      make it easier to understand the code.
      
      Fixes: 566e8251 ("net: stmmac: add a glue driver for the Amlogic Meson 8b / GXBB DWMAC")
      Signed-off-by: NMartin Blumenstingl <martin.blumenstingl@googlemail.com>
      Tested-by: NJerome Brunet <jbrunet@baylibre.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      37512b42
    • J
      net: sched: red: don't reset the backlog on every stat dump · 416ef9b1
      Jakub Kicinski 提交于
      Commit 0dfb33a0 ("sch_red: report backlog information") copied
      child's backlog into RED's backlog.  Back then RED did not maintain
      its own backlog counts.  This has changed after commit 2ccccf5f
      ("net_sched: update hierarchical backlog too") and commit d7f4f332
      ("sch_red: update backlog as well").  Copying is no longer necessary.
      
      Tested:
      
      $ tc -s qdisc show dev veth0
      qdisc red 1: root refcnt 2 limit 400000b min 30000b max 30000b ecn
       Sent 20942 bytes 221 pkt (dropped 0, overlimits 0 requeues 0)
       backlog 1260b 14p requeues 14
        marked 0 early 0 pdrop 0 other 0
      qdisc tbf 2: parent 1: rate 1Kbit burst 15000b lat 3585.0s
       Sent 20942 bytes 221 pkt (dropped 0, overlimits 138 requeues 0)
       backlog 1260b 14p requeues 14
      
      Recently RED offload was added.  We need to make sure drivers don't
      depend on resetting the stats.  This means backlog should be treated
      like any other statistic:
      
        total_stat = new_hw_stat - prev_hw_stat;
      
      Adjust mlxsw.
      Signed-off-by: NJakub Kicinski <jakub.kicinski@netronome.com>
      Acked-by: NNogah Frankel <nogahf@mellanox.com>
      Acked-by: NJiri Pirko <jiri@mellanox.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      416ef9b1
  2. 17 1月, 2018 28 次提交
  3. 16 1月, 2018 2 次提交
    • L
      RDMA/mlx5: Fix out-of-bound access while querying AH · ae59c3f0
      Leon Romanovsky 提交于
      The rdma_ah_find_type() accesses the port array based on an index
      controlled by userspace. The existing bounds check is after the first use
      of the index, so userspace can generate an out of bounds access, as shown
      by the KASN report below.
      
      ==================================================================
      BUG: KASAN: slab-out-of-bounds in to_rdma_ah_attr+0xa8/0x3b0
      Read of size 4 at addr ffff880019ae2268 by task ibv_rc_pingpong/409
      
      CPU: 0 PID: 409 Comm: ibv_rc_pingpong Not tainted 4.15.0-rc2-00031-gb60a3faf5b83-dirty #3
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.7.5-0-ge51488c-20140602_164612-nilsson.home.kraxel.org 04/01/2014
      Call Trace:
       dump_stack+0xe9/0x18f
       print_address_description+0xa2/0x350
       kasan_report+0x3a5/0x400
       to_rdma_ah_attr+0xa8/0x3b0
       mlx5_ib_query_qp+0xd35/0x1330
       ib_query_qp+0x8a/0xb0
       ib_uverbs_query_qp+0x237/0x7f0
       ib_uverbs_write+0x617/0xd80
       __vfs_write+0xf7/0x500
       vfs_write+0x149/0x310
       SyS_write+0xca/0x190
       entry_SYSCALL_64_fastpath+0x18/0x85
      RIP: 0033:0x7fe9c7a275a0
      RSP: 002b:00007ffee5498738 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
      RAX: ffffffffffffffda RBX: 00007fe9c7ce4b00 RCX: 00007fe9c7a275a0
      RDX: 0000000000000018 RSI: 00007ffee5498800 RDI: 0000000000000003
      RBP: 000055d0c8d3f010 R08: 00007ffee5498800 R09: 0000000000000018
      R10: 00000000000000ba R11: 0000000000000246 R12: 0000000000008000
      R13: 0000000000004fb0 R14: 000055d0c8d3f050 R15: 00007ffee5498560
      
      Allocated by task 1:
       __kmalloc+0x3f9/0x430
       alloc_mad_private+0x25/0x50
       ib_mad_post_receive_mads+0x204/0xa60
       ib_mad_init_device+0xa59/0x1020
       ib_register_device+0x83a/0xbc0
       mlx5_ib_add+0x50e/0x5c0
       mlx5_add_device+0x142/0x410
       mlx5_register_interface+0x18f/0x210
       mlx5_ib_init+0x56/0x63
       do_one_initcall+0x15b/0x270
       kernel_init_freeable+0x2d8/0x3d0
       kernel_init+0x14/0x190
       ret_from_fork+0x24/0x30
      
      Freed by task 0:
      (stack is not available)
      
      The buggy address belongs to the object at ffff880019ae2000
       which belongs to the cache kmalloc-512 of size 512
      The buggy address is located 104 bytes to the right of
       512-byte region [ffff880019ae2000, ffff880019ae2200)
      The buggy address belongs to the page:
      page:000000005d674e18 count:1 mapcount:0 mapping:          (null) index:0x0 compound_mapcount: 0
      flags: 0x4000000000008100(slab|head)
      raw: 4000000000008100 0000000000000000 0000000000000000 00000001000c000c
      raw: dead000000000100 dead000000000200 ffff88001a402000 0000000000000000
      page dumped because: kasan: bad access detected
      
      Memory state around the buggy address:
       ffff880019ae2100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       ffff880019ae2180: 00 00 00 00 00 00 00 00 00 00 00 00 00 fc fc fc
      >ffff880019ae2200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                                                ^
       ffff880019ae2280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
       ffff880019ae2300: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
      ==================================================================
      Disabling lock debugging due to kernel taint
      
      Cc: <stable@vger.kernel.org>
      Fixes: 44c58487 ("IB/core: Define 'ib' and 'roce' rdma_ah_attr types")
      Signed-off-by: NLeon Romanovsky <leonro@mellanox.com>
      Signed-off-by: NJason Gunthorpe <jgg@mellanox.com>
      ae59c3f0
    • S
      sh_eth: get Ether port # only when needed · 9662ec19
      Sergei Shtylyov 提交于
      The dual-port Ether configurations always have a shared TSU to e.g. pass
      the packets between those  ports.  With the  TSU init. code gathered under
      the single *if*, we now can only get the port # from 'platform_device::id'
      only when we actually  need it  (and not recalculate it each time)...
      Signed-off-by: NSergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Reviewed-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      9662ec19