linux.git/drivers/pci/hotplug, branch v4.14-rc4

Merge branch 'pci/misc' into next

2017-09-07T18:24:16+00:00

* pci/misc:
  PCI: Fix PCIe capability sizes
  PCI: Convert to using %pOF instead of full_name()
  PCI: Constify endpoint pci_epf_type device_type
  PCI: Constify bin_attribute structures
  PCI: Constify hotplug pci_device_id structures
  PCI: Constify hotplug attribute_group structures
  PCI: Constify label attribute_group structures
  PCI: Constify sysfs attribute_group structures

PCI: Convert to using %pOF instead of full_name()

2017-08-24T16:24:59+00:00

Now that we have a custom printf format specifier, convert users of
full_name() to use %pOF instead.  This is preparation for removing storing
of the full path string for each node.

Signed-off-by: Rob Herring 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Tyrel Datwyler 
Cc: Thomas Petazzoni 
Cc: Jason Cooper 
Cc: Thierry Reding 
Cc: Jonathan Hunter 
Cc: Benjamin Herrenschmidt 
Cc: Paul Mackerras 
Cc: Michael Ellerman

PCI: pciehp: Report power fault only once until we clear it

2017-08-15T18:46:31+00:00

When a power fault occurs, the power controller sets Power Fault Detected
in the Slot Status register, and pciehp_isr() queues an INT_POWER_FAULT
event to handle it.

It also clears Power Fault Detected, but since nothing has yet changed to
correct the power fault, the power controller will likely set it again
immediately, which may cause an infinite loop when pcie_isr() rechecks
Slot Status.

Fix that by masking off Power Fault Detected from new events if the driver
hasn't seen the power fault clear from the previous handling attempt.

Fixes: fad214b0aa72 ("PCI: pciehp: Process all hotplug events before looking for new ones")
Signed-off-by: Keith Busch 
[bhelgaas: changelog, pull test out and add comment]
Signed-off-by: Bjorn Helgaas 
Cc: Mayurkumar Patel 
Cc: stable@vger.kernel.org	# 4.9+

PCI: Constify hotplug pci_device_id structures

2017-08-10T20:21:42+00:00

pci_device_id are not supposed to change at runtime. All functions working
with pci_device_id provided by  work with const pci_device_id.
So mark the non-const structs as const.

Signed-off-by: Arvind Yadav 
[bhelgaas: squash shpchp, ibmphp, bmphp_ebda, cpcihp_zt5550, cpqphp]
Signed-off-by: Bjorn Helgaas

PCI: Constify hotplug attribute_group structures

2017-08-10T20:21:41+00:00

attribute_groups are not supposed to change at runtime.  All functions
working with attribute_groups provided by  work with const
attribute_group.  So mark the non-const structs as const.

File size before:
   text	   data	    bss	    dec	    hex	filename
    418	    160	      8	    586	    24a	drivers/pci/hotplug/rpadlpar_sysfs.o

File size After adding 'const':
   text	   data	    bss	    dec	    hex	filename
    482	     96	      8	    586	    232	drivers/pci/hotplug/rpadlpar_sysfs.o

Signed-off-by: Arvind Yadav 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Tyrel Datwyler

PCI: shpchp: Enable bridge bus mastering if MSI is enabled

2017-08-02T21:54:50+00:00

An SHPC may generate MSIs to notify software about slot or controller
events (SHPC spec r1.0, sec 4.7).  A PCI device can only generate an MSI if
it has bus mastering enabled.

Enable bus mastering if the bridge contains an SHPC that uses MSI for event
notifications.

Signed-off-by: Aleksandr Bezzubikov 
[bhelgaas: changelog]
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Marcel Apfelbaum 
Acked-by: Michael S. Tsirkin 
Cc: stable@vger.kernel.org

Merge tag 'hwparam-20170420' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs

2017-05-11T02:13:03+00:00

Pull hw lockdown support from David Howells:
 "Annotation of module parameters that configure hardware resources
  including ioports, iomem addresses, irq lines and dma channels.

  This allows a future patch to prohibit the use of such module
  parameters to prevent that hardware from being abused to gain access
  to the running kernel image as part of locking the kernel down under
  UEFI secure boot conditions.

  Annotations are made by changing:

        module_param(n, t, p)
        module_param_named(n, v, t, p)
        module_param_array(n, t, m, p)

  to:

        module_param_hw(n, t, hwtype, p)
        module_param_hw_named(n, v, t, hwtype, p)
        module_param_hw_array(n, t, hwtype, m, p)

  where the module parameter refers to a hardware setting

  hwtype specifies the type of the resource being configured. This can
  be one of:

        ioport          Module parameter configures an I/O port
        iomem           Module parameter configures an I/O mem address
        ioport_or_iomem Module parameter could be either (runtime set)
        irq             Module parameter configures an I/O port
        dma             Module parameter configures a DMA channel
        dma_addr        Module parameter configures a DMA buffer address
        other           Module parameter configures some other value

  Note that the hwtype is compile checked, but not currently stored (the
  lockdown code probably won't require it). It is, however, there for
  future use.

  A bonus is that the hwtype can also be used for grepping.

  The intention is for the kernel to ignore or reject attempts to set
  annotated module parameters if lockdown is enabled. This applies to
  options passed on the boot command line, passed to insmod/modprobe or
  direct twiddling in /sys/module/ parameter files.

  The module initialisation then needs to handle the parameter not being
  set, by (1) giving an error, (2) probing for a value or (3) using a
  reasonable default.

  What I can't do is just reject a module out of hand because it may
  take a hardware setting in the module parameters. Some important
  modules, some ipmi stuff for instance, both probe for hardware and
  allow hardware to be manually specified; if the driver is aborts with
  any error, you don't get any ipmi hardware.

  Further, trying to do this entirely in the module initialisation code
  doesn't protect against sysfs twiddling.

  [!] Note that in and of itself, this series of patches should have no
      effect on the the size of the kernel or code execution - that is
      left to a patch in the next series to effect. It does mark
      annotated kernel parameters with a KERNEL_PARAM_FL_HWPARAM flag in
      an already existing field"

* tag 'hwparam-20170420' of git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs: (38 commits)
  Annotate hardware config module parameters in sound/pci/
  Annotate hardware config module parameters in sound/oss/
  Annotate hardware config module parameters in sound/isa/
  Annotate hardware config module parameters in sound/drivers/
  Annotate hardware config module parameters in fs/pstore/
  Annotate hardware config module parameters in drivers/watchdog/
  Annotate hardware config module parameters in drivers/video/
  Annotate hardware config module parameters in drivers/tty/
  Annotate hardware config module parameters in drivers/staging/vme/
  Annotate hardware config module parameters in drivers/staging/speakup/
  Annotate hardware config module parameters in drivers/staging/media/
  Annotate hardware config module parameters in drivers/scsi/
  Annotate hardware config module parameters in drivers/pcmcia/
  Annotate hardware config module parameters in drivers/pci/hotplug/
  Annotate hardware config module parameters in drivers/parport/
  Annotate hardware config module parameters in drivers/net/wireless/
  Annotate hardware config module parameters in drivers/net/wan/
  Annotate hardware config module parameters in drivers/net/irda/
  Annotate hardware config module parameters in drivers/net/hamradio/
  Annotate hardware config module parameters in drivers/net/ethernet/
  ...

Annotate hardware config module parameters in drivers/pci/hotplug/

2017-04-20T11:02:32+00:00

When the kernel is running in secure boot mode, we lock down the kernel to
prevent userspace from modifying the running kernel image.  Whilst this
includes prohibiting access to things like /dev/mem, it must also prevent
access by means of configuring driver modules in such a way as to cause a
device to access or modify the kernel image.

To this end, annotate module_param* statements that refer to hardware
configuration and indicate for future reference what type of parameter they
specify.  The parameter parser in the core sees this information and can
skip such parameters with an error message if the kernel is locked down.
The module initialisation then runs as normal, but just sees whatever the
default values for those parameters is.

Note that we do still need to do the module initialisation because some
drivers have viable defaults set in case parameters aren't specified and
some drivers support automatic configuration (e.g. PNP or PCI) in addition
to manually coded parameters.

This patch annotates drivers in drivers/pci/hotplug/.

Suggested-by: Alan Cox 
Signed-off-by: David Howells 
Acked-by: Bjorn Helgaas 
cc: Scott Murray 
cc: linux-pci@vger.kernel.org

PCI: Add device disconnected state

2017-03-30T03:54:46+00:00

Add a new state to pci_dev to be set when it is unexpectedly disconnected.
The PCI driver tear down functions can observe this new device state so
they may skip operations that will fail.

The pciehp and pcie-dpc drivers are aware when the link is down, so these
set the flag when their handlers detect the device is disconnected.

Tested-by: Krishna Dhulipala 
Signed-off-by: Keith Busch 
Signed-off-by: Bjorn Helgaas 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Wei Zhang

sched/headers: Prepare to move signal wakeup & sigpending methods from into

2017-03-02T07:42:32+00:00

Fix up affected files that include this signal functionality via sched.h.

Acked-by: Linus Torvalds 
Cc: Mike Galbraith 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Ingo Molnar