1. 03 Oct, 2018 1 commit
  2. 26 Sep, 2018 1 commit
  3. 09 Sep, 2018 1 commit
    • Henrik Austad's avatar
      Drop all 00-INDEX files from Documentation/ · a7ddcea5
      Henrik Austad authored
      This is a respin with a wider audience (all that get_maintainer returned)
      and I know this spams a *lot* of people. Not sure what would be the correct
      way, so my apologies for ruining your inbox.
      
      The 00-INDEX files are supposed to give a summary of all files present
      in a directory, but these files are horribly out of date and their
      usefulness is brought into question. Often a simple "ls" would reveal
      the same information as the filenames are generally quite descriptive as
      a short introduction to what the file covers (it should not surprise
      anyone what Documentation/sched/sched-design-CFS.txt covers)
      
      A few years back it was mentioned that these files were no longer really
      needed, and they have since then grown further out of date, so perhaps
      it is time to just throw them out.
      
      A short status yields the following _outdated_ 00-INDEX files, first
      counter is files listed in 00-INDEX but missing in the directory, last
      is files present but not listed in 00-INDEX.
      
      List of outdated 00-INDEX:
      Documentation: (4/10)
      Documentation/sysctl: (0/1)
      Documentation/timers: (1/0)
      Documentation/blockdev: (3/1)
      Documentation/w1/slaves: (0/1)
      Documentation/locking: (0/1)
      Documentation/devicetree: (0/5)
      Documentation/power: (1/1)
      Documentation/powerpc: (0/5)
      Documentation/arm: (1/0)
      Documentation/x86: (0/9)
      Documentation/x86/x86_64: (1/1)
      Documentation/scsi: (4/4)
      Documentation/filesystems: (2/9)
      Documentation/filesystems/nfs: (0/2)
      Documentation/cgroup-v1: (0/2)
      Documentation/kbuild: (0/4)
      Documentation/spi: (1/0)
      Documentation/virtual/kvm: (1/0)
      Documentation/scheduler: (0/2)
      Documentation/fb: (0/1)
      Documentation/block: (0/1)
      Documentation/networking: (6/37)
      Documentation/vm: (1/3)
      
      Then there are 364 subdirectories in Documentation/ with several files that
      are missing 00-INDEX alltogether (and another 120 with a single file and no
      00-INDEX).
      
      I don't really have an opinion to whether or not we /should/ have 00-INDEX,
      but the above 00-INDEX should either be removed or be kept up to date. If
      we should keep the files, I can try to keep them updated, but I rather not
      if we just want to delete them anyway.
      
      As a starting point, remove all index-files and references to 00-INDEX and
      see where the discussion is going.
      Signed-off-by: default avatarHenrik Austad <henrik@austad.us>
      Acked-by: default avatar"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Just-do-it-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Reviewed-by: default avatarJens Axboe <axboe@kernel.dk>
      Acked-by: default avatarPaul Moore <paul@paul-moore.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: default avatarMark Brown <broonie@kernel.org>
      Acked-by: default avatarMike Rapoport <rppt@linux.vnet.ibm.com>
      Cc: [Almost everybody else]
      Signed-off-by: default avatarJonathan Corbet <corbet@lwn.net>
      a7ddcea5
  4. 27 Jul, 2018 1 commit
  5. 19 Jul, 2018 5 commits
  6. 17 May, 2018 1 commit
    • Oza Pawandeep's avatar
      PCI/AER: Handle ERR_FATAL with removal and re-enumeration of devices · 7e9084b3
      Oza Pawandeep authored
      PCIe ERR_FATAL errors mean the Link is unreliable.  Components on the Link
      may need to be reset to return to reliable operation (PCIe r4.0, sec
      6.2.2).  We previously handled these errors much differently depending on
      whether the platform supports Downstream Port Containment (DPC) (PCIe r4.0,
      sec 6.2.10) or not.
      
      The AER driver has historically logged the error details, called
      driver-supplied pci_error_handlers callbacks, and reset the Link.  This
      reset downstream devices, but did not remove them from the PCI subsystem,
      re-enumerate them, or call their driver .remove() or .probe() methods.
      
      DPC is different because the hardware automatically disables the Link when
      it detects ERR_FATAL, which resets downstream devices.  There's no
      opportunity for pci_error_handlers callbacks before resetting the Link.
      The DPC driver removes affected devices (which calls their driver .remove()
      methods), brings the Link back up, and re-enumerates (which calls driver
      .probe() methods).
      
      Align AER ERR_FATAL handling with DPC by resetting the Link in software,
      skipping the driver pci_error_handlers callbacks, removing the devices from
      the PCI subsystem, and re-enumerating.  The idea is that drivers and
      devices should see the same behavior for ERR_FATAL events, regardless of
      whether they're handled by AER or DPC.
      
      Here are the basic ERR_FATAL recovery steps, showing the previous AER
      behavior, the AER behavior after this patch, and the DPC behavior:
      
                                AER        AER      DPC
                                previous   new      behavior
                                --------   ---      --------
        Log error               yes        yes      yes (minimal)
        drv.error_detected()    yes        no       no
        Reset Link              yes        yes      yes
        drv.mmio_enabled()      yes        no       no
        drv.slot_reset()        yes        no       no
        drv.resume()            yes        no       no
        Remove PCI devices      no         yes      yes
          (calls drv.remove())
        Re-enumerate            no         yes      yes
          (calls drv.probe())
      
      N.B. With DPC, the Link reset happens before the driver .remove() calls,
      while with AER, the reset happens *after* the .remove() calls.  The goal is
      to eventually do the reset before .remove() for AER as well.
      Signed-off-by: default avatarOza Pawandeep <poza@codeaurora.org>
      [bhelgaas: changelog, squash doc patch into this, remove unused
      "result_data"]
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: Keith Busch's avatarKeith Busch <keith.busch@intel.com>
      7e9084b3
  7. 22 Feb, 2018 1 commit
  8. 16 May, 2017 1 commit
  9. 28 Apr, 2017 2 commits
  10. 20 Apr, 2017 1 commit
  11. 11 Apr, 2017 3 commits
  12. 29 Mar, 2017 1 commit
  13. 03 Mar, 2017 1 commit
  14. 15 Feb, 2017 2 commits
  15. 09 Feb, 2017 1 commit
  16. 13 Jan, 2017 1 commit
  17. 14 Sep, 2016 2 commits
    • Bjorn Helgaas's avatar
      PCI/AER: Remove aerdriver.forceload kernel parameter · 7ece1417
      Bjorn Helgaas authored
      Per the PCI Firmware spec, r3.0, sec 4.5.1, on ACPI systems, the OS must
      not use AER unless _OSC is present and _OSC grants AER control to the OS.
      The aerdriver.forceload kernel parameter was a way to enable Linux AER
      support on ACPI systems that lack _OSC or fail to grant control the the OS.
      
      Enabling Linux AER support when the firmware doesn't want us to is a recipe
      for problems, e.g., the firmware might be handling AER itself.
      
      Remove the aerdriver.forceload kernel parameter and related supporting
      code.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      7ece1417
    • Bjorn Helgaas's avatar
      PCI/AER: Remove aerdriver.nosourceid kernel parameter · 9ff25e6b
      Bjorn Helgaas authored
      The aerdriver.nosourceid kernel parameter was intended for working around
      broken chipsets don't supply the source ID for AER events.  We recently
      added PCI_BUS_FLAGS_NO_AERSID, which can be set by quirks for the same
      purpose.
      
      Remove the aerdriver.nosourceid kernel parameter.  For anything other than
      debugging, asking users to find and use kernel parameters is a poor user
      experience.  Instead, we should add PCI_BUS_FLAGS_NO_AERSID quirks for any
      hardware that needs it.
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      9ff25e6b
  18. 02 Sep, 2016 1 commit
  19. 16 Aug, 2016 1 commit
    • Christoph Hellwig's avatar
      PCI: Use positive flags in pci_alloc_irq_vectors() · 4fe0d154
      Christoph Hellwig authored
      Instead of passing negative flags like PCI_IRQ_NOMSI to prevent use of
      certain interrupt types, pass positive flags like PCI_IRQ_LEGACY,
      PCI_IRQ_MSI, etc., to specify the acceptable interrupt types.
      
      This is based on a number of pending driver conversions that just happend
      to be a whole more obvious to read this way, and given that we have no
      users in the tree yet it can still easily be done.
      
      I've also added a PCI_IRQ_ALL_TYPES catchall to keep the case of accepting
      all interrupt types very simple.
      
      [bhelgaas: changelog, fix PCI_IRQ_AFFINITY doc typo, remove mention of
      PCI_IRQ_NOLEGACY]
      Signed-off-by: default avatarChristoph Hellwig <hch@lst.de>
      Signed-off-by: default avatarBjorn Helgaas <bhelgaas@google.com>
      Reviewed-by: default avatarAlexander Gordeev <agordeev@redhat.com>
      4fe0d154
  20. 21 Jul, 2016 2 commits
  21. 09 Apr, 2015 1 commit
  22. 20 Mar, 2015 2 commits
  23. 19 Jun, 2014 1 commit
  24. 19 Feb, 2014 1 commit
  25. 13 Feb, 2014 5 commits