1. 08 4月, 2017 3 次提交
  2. 22 3月, 2017 1 次提交
    • C
      drivers/misc: Aspeed LPC control fix compile error and warning · 132c93d4
      Cyril Bur 提交于
      pgprot_dmachoerent() is not defined on every architecture. Having
      COMPILE_TEST set for the driver causes it to be compiled on
      architectures which do not have pgprot_dmachoerent():
          drivers/misc/aspeed-lpc-ctrl.c: In function 'aspeed_lpc_ctrl_mmap':
          drivers/misc/aspeed-lpc-ctrl.c:51:9: error: implicit declaration of
              function 'pgprot_dmacoherent' [-Werror=implicit-function-declaration]
              prot = pgprot_dmacoherent(prot);
      
      There are two possible solutions:
          1. Remove COMPILE_TEST to ensure the driver is only compiled on ARM
          2. Use pgprot_noncached() instead of pgprot_dmachoerent()
      
      The first option results in less compile testing of the LPC control
      driver which is undesirable.
      The second option uses a function that is declared on all architectures
      and therefore should always build. Currently there is no practical
      difference between pgprot_noncached() and pgprot_dmachoerent() for the
      aspeed chips that this driver is compatible with. The reason for
      pgprot_dmachoerent() was that there may be chips made at some point in
      the future that could include hardware that pgprot_dmachoerent() could
      optimise for. As none of this hardware has even been announced there
      isn't really a need for pgprot_dmachoerent().
      
      Using pgprot_noncached() is completely correct and optimal for all
      existing hardware on which the LPC control driver will run.
      
      This commit also addresses that phys_addr_t should be printed using %pap
      rather than %x:
          In file included from include/linux/miscdevice.h:6:0,
                           from drivers/misc/aspeed-lpc-ctrl.c:11:
          drivers/misc/aspeed-lpc-ctrl.c: In function 'aspeed_lpc_ctrl_probe':
          drivers/misc/aspeed-lpc-ctrl.c:232:17: warning: format '%x' expects
              argument of type 'unsigned int', but argument 3 has type 'phys_addr_t
              {aka long long unsigned int}' [-Wformat=]
              dev_info(dev, "Loaded at 0x%08x (0x%08x)\n",
      Signed-off-by: NCyril Bur <cyrilbur@gmail.com>
      Reported-by: Nkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      132c93d4
  3. 20 3月, 2017 1 次提交
  4. 17 3月, 2017 2 次提交
    • G
      auxdisplay: charlcd: Extract character LCD core from misc/panel · 39f8ea46
      Geert Uytterhoeven 提交于
      Extract the character LCD core from the Parallel port LCD/Keypad Panel
      driver in the misc subsystem, and convert it into a subdriver in the
      auxdisplay subsystem.  This allows the character LCD core to be used by
      other drivers later.
      
      Compilation is controlled by its own Kconfig symbol CHARLCD, which is to
      be selected by its users, but can be enabled manually for
      compile-testing.
      
      All functions changed their prefix from "lcd_" to "charlcd_", and gained
      a "struct charlcd *" parameter to operate on a specific instance.
      While the driver API thus is ready to support multiple instances, the
      current limitation of a single display (/dev/lcd has a single misc minor
      assigned) is retained.
      
      No functional changes intended.
      Signed-off-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      39f8ea46
    • C
      drivers/misc: Add Aspeed LPC control driver · 6c4e9767
      Cyril Bur 提交于
      In order to manage server systems, there is typically another processor
      known as a BMC (Baseboard Management Controller) which is responsible
      for powering the server and other various elements, sometimes fans,
      often the system flash.
      
      The Aspeed BMC family which is what is used on OpenPOWER machines and a
      number of x86 as well is typically connected to the host via an LPC
      (Low Pin Count) bus (among others).
      
      The LPC bus is an ISA bus on steroids. It's generally used by the
      BMC chip to provide the host with access to the system flash (via MEM/FW
      cycles) that contains the BIOS or other host firmware along with a
      number of SuperIO-style IOs (via IO space) such as UARTs, IPMI
      controllers.
      
      On the BMC chip side, this is all configured via a bunch of registers
      whose content is related to a given policy of what devices are exposed
      at a per system level, which is system/vendor specific, so we don't want
      to bolt that into the BMC kernel. This started with a need to provide
      something nicer than /dev/mem for user space to configure these things.
      
      One important aspect of the configuration is how the MEM/FW space is
      exposed to the host (ie, the x86 or POWER). Some registers in that
      bridge can define a window remapping all or portion of the LPC MEM/FW
      space to a portion of the BMC internal bus, with no specific limits
      imposed in HW.
      
      I think it makes sense to ensure that this window is configured by a
      kernel driver that can apply some serious sanity checks on what it is
      configured to map.
      
      In practice, user space wants to control this by flipping the mapping
      between essentially two types of portions of the BMC address space:
      
         - The flash space. This is a region of the BMC MMIO space that
      more/less directly maps the system flash (at least for reads, writes
      are somewhat more complicated).
      
         - One (or more) reserved area(s) of the BMC physical memory.
      
      The latter is needed for a number of things, such as avoiding letting
      the host manipulate the innards of the BMC flash controller via some
      evil backdoor, we want to do flash updates by routing the window to a
      portion of memory (under control of a mailbox protocol via some
      separate set of registers) which the host can use to write new data in
      bulk and then request the BMC to flash it. There are other uses, such
      as allowing the host to boot from an in-memory flash image rather than
      the one in flash (very handy for continuous integration and test, the
      BMC can just download new images).
      
      It is important to note that due to the way the Aspeed chip lets the
      kernel configure the mapping between host LPC addresses and BMC ram
      addresses the offset within the window must be a multiple of size.
      Not doing so will fragment the accessible space rather than simply
      moving 'zero' upwards. This is caused by the nature of HICR8 being a
      mask and the way host LPC addresses are translated.
      Signed-off-by: NCyril Bur <cyrilbur@gmail.com>
      Reviewed-by: NJoel Stanley <joel@jms.id.au>
      Reviewed-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6c4e9767
  5. 16 3月, 2017 3 次提交
  6. 10 3月, 2017 1 次提交
  7. 02 3月, 2017 10 次提交
  8. 28 2月, 2017 3 次提交
  9. 25 2月, 2017 1 次提交
  10. 21 2月, 2017 1 次提交
    • A
      cxl: fix nested locking hang during EEH hotplug · 171ed0fc
      Andrew Donnellan 提交于
      Commit 14a3ae34 ("cxl: Prevent read/write to AFU config space while AFU
      not configured") introduced a rwsem to fix an invalid memory access that
      occurred when someone attempts to access the config space of an AFU on a
      vPHB whilst the AFU is deconfigured, such as during EEH recovery.
      
      It turns out that it's possible to run into a nested locking issue when EEH
      recovery fails and a full device hotplug is required.
      cxl_pci_error_detected() deconfigures the AFU, taking a writer lock on
      configured_rwsem. When EEH recovery fails, the EEH code calls
      pci_hp_remove_devices() to remove the device, which in turn calls
      cxl_remove() -> cxl_pci_remove_afu() -> pci_deconfigure_afu(), which tries
      to grab the writer lock that's already held.
      
      Standard rwsem semantics don't express what we really want to do here and
      don't allow for nested locking. Fix this by replacing the rwsem with an
      atomic_t which we can control more finely. Allow the AFU to be locked
      multiple times so long as there are no readers.
      
      Fixes: 14a3ae34 ("cxl: Prevent read/write to AFU config space while AFU not configured")
      Cc: stable@vger.kernel.org # v4.9+
      Signed-off-by: NAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Acked-by: NFrederic Barrat <fbarrat@linux.vnet.ibm.com>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      171ed0fc
  11. 12 2月, 2017 1 次提交
    • B
      misc: eeprom: at24: use device_property_*() functions instead of of_get_property() · dd905a61
      Ben Gardner 提交于
      Allow the at24 driver to get configuration information from both OF and
      ACPI by using the more generic device_property functions.
      This change was inspired by the at25.c driver.
      
      I have a custom board with a ST M24C02 EEPROM attached to an I2C bus.
      With the following ACPI construct, this patch instantiates a working
      instance of the driver.
      
      Device (EEP0) {
       Name (_HID, "PRP0001")
       Name (_DSD, Package () {
        ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
        Package () {
         Package () {"compatible", Package () {"st,24c02"}},
         Package () {"pagesize", 16},
        },
       })
       Name (_CRS, ResourceTemplate () {
        I2cSerialBus (
         0x0057, ControllerInitiated, 400000,
         AddressingMode7Bit, "\\_SB.PCI0.I2C3", 0x00,
         ResourceConsumer,,)
       })
      }
      Signed-off-by: NBen Gardner <gardner.ben@gmail.com>
      Reviewed-by: NAndy Shevchenko <andy.shevchenko@gmail.com>
      Signed-off-by: NWolfram Sang <wsa@the-dreams.de>
      dd905a61
  12. 10 2月, 2017 11 次提交
  13. 03 2月, 2017 2 次提交