1. Mar 26, 2020
  2. Mar 25, 2020
    • Damien Le Moal's avatar
      zonfs: Fix handling of read-only zones · ccf4ad7d
      Damien Le Moal authored
      
      
      The write pointer of zones in the read-only consition is defined as
      invalid by the SCSI ZBC and ATA ZAC specifications. It is thus not
      possible to determine the correct size of a read-only zone file on
      mount. Fix this by handling read-only zones in the same manner as
      offline zones by disabling all accesses to the zone (read and write)
      and initializing the inode size of the read-only zone to 0).
      
      For zones found to be in the read-only condition at runtime, only
      disable write access to the zone and keep the size of the zone file to
      its last updated value to allow the user to recover previously written
      data.
      
      Also fix zonefs documentation file to reflect this change.
      
      Signed-off-by: default avatarDamien Le Moal <damien.lemoal@wdc.com>
      Reviewed-by: default avatarJohannes Thumshirn <johannes.thumshirn@wdc.com>
      ccf4ad7d
    • David S. Miller's avatar
      Merge git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf · 6f000f98
      David S. Miller authored
      Pablo Neira Ayuso says:
      
      ====================
      Netfilter fixes for net
      
      The following patchset contains Netfilter fixes for net:
      
      1) A new selftest for nf_queue, from Florian Westphal. This test
         covers two recent fixes: 07f8e4d0 ("tcp: also NULL skb->dev
         when copy was needed") and b738a185
      
       ("tcp: ensure skb->dev is
         NULL before leaving TCP stack").
      
      2) The fwd action breaks with ifb. For safety in next extensions,
         make sure the fwd action only runs from ingress until it is extended
         to be used from a different hook.
      
      3) The pipapo set type now reports EEXIST in case of subrange overlaps.
         Update the rbtree set to validate range overlaps, so far this
         validation is only done only from userspace. From Stefano Brivio.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6f000f98
    • David S. Miller's avatar
      Merge tag 'mlx5-fixes-2020-03-24' of git://git.kernel.org/pub/scm/linux/kernel/git/saeed/linux · 7e566df6
      David S. Miller authored
      
      
      Saeed Mahameed says:
      
      ====================
      Mellanox, mlx5 fixes 2020-03-24
      
      This series introduces some fixes to mlx5 driver.
      
      From Aya, Fixes to the RX error recovery flows
      From Leon, Fix IB capability mask
      
      Please pull and let me know if there is any problem.
      
      For -stable v5.5
       ('net/mlx5_core: Set IB capability mask1 to fix ib_srpt connection failure')
      
      For -stable v5.4
       ('net/mlx5e: Fix ICOSQ recovery flow with Striding RQ')
       ('net/mlx5e: Do not recover from a non-fatal syndrome')
       ('net/mlx5e: Fix missing reset of SW metadata in Striding RQ reset')
       ('net/mlx5e: Enhance ICOSQ WQE info fields')
      
      The above patch ('net/mlx5e: Enhance ICOSQ WQE info fields')
      will fail to apply cleanly on v5.4 due to a trivial contextual conflict,
      but it is an important fix, do I need to do something about it or just
      assume Greg will know how to handle this ?
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      7e566df6
    • Heiner Kallweit's avatar
      r8169: re-enable MSI on RTL8168c · f13bc681
      Heiner Kallweit authored
      The original change fixed an issue on RTL8168b by mimicking the vendor
      driver behavior to disable MSI on chip versions before RTL8168d.
      This however now caused an issue on a system with RTL8168c, see [0].
      Therefore leave MSI disabled on RTL8168b, but re-enable it on RTL8168c.
      
      [0] https://bugzilla.redhat.com/show_bug.cgi?id=1792839
      
      Fixes: 003bd5b4
      
       ("r8169: don't use MSI before RTL8168d")
      Signed-off-by: default avatarHeiner Kallweit <hkallweit1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f13bc681
    • Jakub Kicinski's avatar
      devlink: expand the devlink-info documentation · cd556e40
      Jakub Kicinski authored
      
      
      We are having multiple review cycles with all vendors trying
      to implement devlink-info. Let's expand the documentation with
      more information about what's implemented and motivation behind
      this interface in an attempt to make the implementations easier.
      
      Describe what each info section is supposed to contain, and make
      some references to other HW interfaces (PCI caps).
      
      Document how firmware management is expected to look, to make
      it clear how devlink-info and devlink-flash work in concert.
      
      Name some future work.
      
      v2: - improve wording
      v3: - improve wording
      
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Reviewed-by: default avatarRandy Dunlap <rdunlap@infradead.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      cd556e40
    • Andre Przywara's avatar
      net: phy: mdio-bcm-unimac: Fix clock handling · c312c781
      Andre Przywara authored
      The DT binding for this PHY describes an *optional* clock property.
      Due to a bug in the error handling logic, we are actually ignoring this
      clock *all* of the time so far.
      
      Fix this by using devm_clk_get_optional() to handle this clock properly.
      
      Fixes: b78ac6ec
      
       ("net: phy: mdio-bcm-unimac: Allow configuring MDIO clock divider")
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Acked-by: default avatarFlorian Fainelli <f.fainelli@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      c312c781
    • Vladimir Oltean's avatar
      net: phy: mscc: consolidate a common RGMII delay implementation · 2283a02b
      Vladimir Oltean authored
      
      
      It looks like the VSC8584 PHY driver is rolling its own RGMII delay
      configuration code, despite the fact that the logic is mostly the same.
      
      In fact only the register layout and position for the RGMII controls has
      changed. So we need to adapt and parameterize the PHY-dependent bit
      fields when calling the new generic function.
      
      Signed-off-by: default avatarVladimir Oltean <vladimir.oltean@nxp.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Tested-by: default avatarAntoine Tenart <antoine.tenart@bootlin.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2283a02b
    • David S. Miller's avatar
      Merge branch 'axienet-Update-error-handling-and-add-64-bit-DMA-support' · 148aa2a8
      David S. Miller authored
      Andre Przywara says:
      
      ====================
      net: axienet: Update error handling and add 64-bit DMA support
      
      a minor update, fixing the 32-bit build breakage, and brightening up
      Dave's christmas tree. Rebased against latest net-next/master.
      
      This series is based on net-next as of today (9970de8b), which
      includes Russell's fixes [1], solving the SGMII issues I have had.
      
      [1] https://lore.kernel.org/netdev/E1j6trA-0003GY-N1@rmk-PC.armlinux.org.uk/
      
      
      
      Changelog v2 .. v3:
      - Use two "left-shifts by 16" to fix builds with 32-bit phys_addr_t
      - reorder variable declarations
      
      Changelog v1 .. v2:
      - Add Reviewed-by: tags from Radhey
      - Extend kerndoc documentation
      - Convert DMA error handler tasklet to work queue
      - log DMA mapping errors
      - mark DMA mapping error checks as unlikely (in "hot" paths)
      - return NETDEV_TX_OK on TX DMA mapping error (increasing TX drop counter)
      - Request eth IRQ as an optional IRQ
      - Remove no longer needed MDIO IRQ register names
      - Drop DT propery check for address width, assume full 64 bit
      
      This series updates the Xilinx Axienet driver to work on our board
      here. One big issue was broken SGMII support, which Russell fixed already
      (in net-next).
      While debugging and understanding the driver, I found several problems
      in the error handling and cleanup paths, which patches 2-7 address.
      Patch 8 removes a annoying error message, patch 9 paves the way for newer
      revisions of the IP. The next patch adds mii-tool support, just for good
      measure.
      
      The next four patches add support for 64-bit DMA. This is an integration
      option on newer IP revisions (>= v7.1), and expects MSB bits in formerly
      reserved registers. Without writing to those MSB registers, the state
      machine won't trigger, so it's mandatory to access them, even if they
      are zero. Patches 11 and 12 prepare the code by adding accessors, to
      wrap this properly and keep it working on older IP revisions.
      Patch 13 enables access to the MSB registers, by trying to write a
      non-zero value to them and checking if that sticks. Older IP revisions
      always read those registers as zero.
      Patch 14 then adjusts the DMA mask, based on the autodetected MSB
      feature. It uses the full 64 bits in this case, the rest of the system
      (actual physical addresses in use) should provide a natural limit if the
      chip has connected fewer address lines. If not, the parent DT node can
      use a dma-range property.
      
      The Xilinx PG138 and PG021 documents (in versions 7.1 in both cases)
      were used for this series.
      ====================
      
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      148aa2a8
    • Andre Przywara's avatar
      net: axienet: Allow DMA to beyond 4GB · 5fff0151
      Andre Przywara authored
      
      
      With all DMA address accesses wrapped, we can actually support 64-bit
      DMA if this option was chosen at IP integration time.
      If the IP has been configured for an address width greater than 32 bits,
      we assume the full 64 bit DMA width is working. In practise this will be
      limited by the actual system address bus width, which will ideally be the
      same as the DMA IP address width.
      If this is not the case, the actual width can still be configured using a
      dma-ranges property in the parent of the MAC node.
      
      This increases the DMA mask on those systems to let the kernel choose
      buffers from memory at higher addresses.
      
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5fff0151
    • Andre Przywara's avatar
      net: axienet: Autodetect 64-bit DMA capability · f735c40e
      Andre Przywara authored
      
      
      When newer revisions of the Axienet IP are configured for a 64-bit bus,
      we *need* to write to the MSB part of the an address registers,
      otherwise the IP won't recognise this as a DMA start condition.
      This is even true when the actual DMA address comes from the lower 4 GB.
      
      To autodetect this configuration, at probe time we write all 1's to such
      an MSB register, and see if any bits stick. If this is configured for a
      32-bit bus, those MSB registers are RES0, so reading back 0 indicates
      that no MSB writes are necessary.
      On the other hands reading anything other than 0 indicated the need to
      write the MSB registers, so we set the respective flag.
      
      The actual DMA mask stays at 32-bit for now. To help bisecting, a
      separate patch will enable allocations from higher addresses.
      
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      f735c40e
    • Andre Przywara's avatar
      net: axienet: Upgrade descriptors to hold 64-bit addresses · 4e958f33
      Andre Przywara authored
      
      
      Newer revisions of the AXI DMA IP (>= v7.1) support 64-bit addresses,
      both for the descriptors itself, as well as for the buffers they are
      pointing to.
      This is realised by adding "MSB" words for the next and phys pointer
      right behind the existing address word, now named "LSB". These MSB words
      live in formerly reserved areas of the descriptor.
      
      If the hardware supports it, write both words when setting an address.
      The buffer address is handled by two wrapper functions, the two
      occasions where we set the next pointers are open coded.
      
      For now this is guarded by a flag which we don't set yet.
      
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4e958f33
    • Andre Przywara's avatar
      net: axienet: Wrap DMA pointer writes to prepare for 64 bit · 6a00d0dd
      Andre Przywara authored
      
      
      Newer versions of the Xilink DMA IP support busses with more than 32
      address bits, by introducing an MSB word for the registers holding DMA
      pointers (tail/current, RX/TX descriptor addresses).
      On IP configured for more than 32 bits, it is also *required* to write
      both words, to let the IP recognise this as a start condition for an
      MM2S request, for instance.
      
      Wrap the DMA pointer writes with a separate function, to add this
      functionality later. For now we stick to the lower 32 bits.
      
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6a00d0dd
    • Andre Przywara's avatar
      net: axienet: Add mii-tool support · 2a9b65ea
      Andre Przywara authored
      
      
      mii-tool is useful for debugging, and all it requires to work is to wire
      up the ioctl ops function pointer.
      Add this to the axienet driver to enable mii-tool.
      
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Reviewed-by: default avatarAndrew Lunn <andrew@lunn.ch>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      2a9b65ea