kernel/linux.git/drivers/thunderbolt, branch v4.11.5

Merge tag 'char-misc-4.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc

2016-12-13T20:11:01+00:00

Pull char/misc driver updates from Greg KH: "Here's the big char/misc driver patches for 4.10-rc1. Lots of tiny changes over lots of "minor" driver subsystems, the largest being some new FPGA drivers. Other than that, a few other new drivers, but no new driver subsystems added for this kernel cycle, a nice change. All of these have been in linux-next with no reported issues" * tag 'char-misc-4.10-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (107 commits) uio-hv-generic: store physical addresses instead of virtual Tools: hv: kvp: configurable external scripts path uio-hv-generic: new userspace i/o driver for VMBus vmbus: add support for dynamic device id's hv: change clockevents unbind tactics hv: acquire vmbus_connection.channel_mutex in vmbus_free_channels() hyperv: Fix spelling of HV_UNKOWN mei: bus: enable non-blocking RX mei: fix the back to back interrupt handling mei: synchronize irq before initiating a reset. VME: Remove shutdown entry from vme_driver auxdisplay: ht16k33: select framebuffer helper modules MAINTAINERS: add git url for fpga fpga: Clarify how write_init works streaming modes fpga zynq: Fix incorrect ISR state on bootup fpga zynq: Remove priv->dev fpga zynq: Add missing \n to messages fpga: Add COMPILE_TEST to all drivers uio: pruss: add clk_disable() char/pcmcia: add some error checking in scr24x_read() ...

thunderbolt: Compile on x86 only

2016-11-18T08:42:59+00:00

So far Thunderbolt is (unfortunately) an Intel proprietary technology that is only available on x86, so compiling on other arches is pointless except for testing purposes. Amend Kconfig accordingly. Suggested-by: Arnd Bergmann Signed-off-by: Lukas Wunner Acked-by: Arnd Bergmann Cc: Andreas Noever Cc: Ard Biesheuvel Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/7dfda728d3ee8a33c80c49b224da7359c6015eea.1479456179.git.lukas@wunner.de Signed-off-by: Ingo Molnar

thunderbolt, efi: Fix Kconfig dependencies harder

2016-11-18T08:42:53+00:00

Since commit c9cc3aaa0281 ("thunderbolt: Use Device ROM retrieved from EFI"), the THUNDERBOLT config option selects APPLE_PROPERTIES. This broke the build for certain configs because APPLE_PROPERTIES is located in a menu which depends on EFI: If EFI is not enabled, the prerequisites needed for APPLE_PROPERTIES are not selected: Those are EFI_DEV_PATH_PARSER and UCS2_STRING. Additionally EFI_DEV_PATH_PARSER won't compile unless ACPI is enabled. Commit 79f9cd35b05e ("thunderbolt, efi: Fix Kconfig dependencies") sought to fix the breakage by making THUNDERBOLT select APPLE_PROPERTIES only if EFI_STUB is enabled. On x86, EFI_STUB depends on EFI and EFI depends on ACPI, so this fixed the build at least on this architecture. However on arm and arm64, EFI_STUB does not depend on EFI, so once again the prerequisites needed for APPLE_PROPERTIES are not selected. Additionally ACPI is not available on arm and optional on arm64, therefore EFI_DEV_PATH_PARSER won't compile. Fix by selecting APPLE_PROPERTIES only on x86. Suggested-by: Arnd Bergmann Signed-off-by: Lukas Wunner Acked-by: Arnd Bergmann Cc: Andreas Noever Cc: Ard Biesheuvel Cc: Linus Torvalds Cc: Matt Fleming Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/5c241cf92eb1dc2421218c1204c6a9d22c9f847b.1479456179.git.lukas@wunner.de Signed-off-by: Ingo Molnar

thunderbolt, efi: Fix Kconfig dependencies

2016-11-15T07:33:22+00:00

Fix this EFI build failure on certain (rand)configs: drivers/firmware/efi/apple-properties.c:149:9: error: implicit declaration of function ???efi_get_device_by_path??? [-Werror=implicit-function-declaration] which is due to: warning: (THUNDERBOLT) selects APPLE_PROPERTIES which has unmet direct dependencies (EFI && EFI_STUB && X86) Signed-off-by: Lukas Wunner Cc: Andreas Noever Cc: Ard Biesheuvel Cc: Linus Torvalds Cc: Matt Fleming Cc: Pedro Vilaça Cc: Peter Jones Cc: Peter Zijlstra Cc: Pierre Moreau [MacBookPro11,3] Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20161114151033.GA10141@wunner.de Signed-off-by: Ingo Molnar

thunderbolt: Use Device ROM retrieved from EFI

2016-11-13T07:23:16+00:00

Macs with Thunderbolt 1 do not have a unit-specific DROM: The DROM is empty with uid 0x1000000000000. (Apple started factory-burning a unit- specific DROM with Thunderbolt 2.) Instead, the NHI EFI driver supplies a DROM in a device property. Use it if available. It's only available when booting with the efistub. If it's not available, silently fall back to our hardcoded DROM. The size of the DROM is always 256 bytes. The number is hardcoded into the NHI EFI driver. This commit can deal with an arbitrary size however, just in case they ever change that. Background information: The EFI firmware volume contains ROM files for the NHI, GMUX and several other chips as well as key material. This strategy allows Apple to deploy ROM or key updates by simply publishing an EFI firmware update on their website. Drivers do not access those files directly but rather through a file server via EFI protocol AC5E4829-A8FD-440B-AF33-9FFE013B12D8. Files are identified by GUID, the NHI DROM has 339370BD-CFC6-4454-8EF7-704653120818. The NHI EFI driver amends that file with a unit-specific uid. The uid has 64 bit but its entropy is much lower: 24 bit represent the model, 24 bit are taken from a serial number, 16 bit are fixed. The NHI EFI driver obtains the serial number via the DataHub protocol, copies it into the DROM, calculates the CRC and submits the result as a device property. A modification is needed in the resume code where we currently read the uid of all switches in the hierarchy to detect plug events that occurred during sleep. On Thunderbolt 1 root switches this will now lead to a mismatch between the uid of the empty DROM and the EFI DROM. Exempt the root switch from this check: It's built in, so the uid should never change. However we continue to *read* the uid of the root switch, this seems like a good way to test its reachability after resume. Tested-by: Lukas Wunner [MacBookPro9,1] Tested-by: Pierre Moreau [MacBookPro11,3] Signed-off-by: Lukas Wunner Signed-off-by: Matt Fleming Acked-by: Andreas Noever Cc: Ard Biesheuvel Cc: Linus Torvalds Cc: Pedro Vilaça Cc: Peter Jones Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-efi@vger.kernel.org Link: http://lkml.kernel.org/r/20161112213237.8804-10-matt@codeblueprint.co.uk Signed-off-by: Ingo Molnar

thunderbolt: Macro rename

2016-11-09T15:54:31+00:00

This first patch updates the NHI Thunderbolt controller registers file to reflect that it is not only for Cactus Ridge. No functional change intended. Signed-off-by: Amir Levy Signed-off-by: Andreas Noever Signed-off-by: Greg Kroah-Hartman

thunderbolt: Don't declare Falcon Ridge unsupported

2016-08-31T11:25:02+00:00

Falcon Ridge 4C has been supported by the driver from the beginning, Falcon Ridge 2C support was just added. Don't irritate users with a warning declaring the opposite. Signed-off-by: Lukas Wunner Signed-off-by: Andreas Noever Signed-off-by: Greg Kroah-Hartman

thunderbolt: Add support for INTEL_FALCON_RIDGE_2C controller.

2016-08-31T11:25:02+00:00

From: Xavier Gnata Add support to INTEL_FALCON_RIDGE_2C controller and corresponding quirk to support suspend/resume. Tested against 4.7 master on a MacBook Air 11" 2015. Signed-off-by: Andreas Noever Reviewed-by: Lukas Wunner Signed-off-by: Greg Kroah-Hartman

thunderbolt: Fix double free of drom buffer

2016-05-02T17:09:22+00:00

If tb_drom_read() fails, sw->drom is freed but not set to NULL. sw->drom is then freed again in the error path of tb_switch_alloc(). The bug can be triggered by unplugging a thunderbolt device shortly after it is detected by the thunderbolt driver. Clear sw->drom if tb_drom_read() fails. [bhelgaas: add Fixes:, stable versions of interest] Fixes: 343fcb8c70d7 ("thunderbolt: Fix nontrivial endpoint devices.") Signed-off-by: Andreas Noever Signed-off-by: Bjorn Helgaas CC: stable@vger.kernel.org # v3.17+ CC: Lukas Wunner

thunderbolt: Support 1st gen Light Ridge controller

2016-04-08T16:13:40+00:00

Add support for the 1st gen Light Ridge controller, which is built into these systems: iMac12,1 2011 21.5" iMac12,2 2011 27" Macmini5,1 2011 i5 2.3 GHz Macmini5,2 2011 i5 2.5 GHz Macmini5,3 2011 i7 2.0 GHz MacBookPro8,1 2011 13" MacBookPro8,2 2011 15" MacBookPro8,3 2011 17" MacBookPro9,1 2012 15" MacBookPro9,2 2012 13" Light Ridge (CV82524) was the very first copper Thunderbolt controller, introduced 2010 alongside its fiber-optic cousin Light Peak (CVL2510). Consequently the chip suffers from some teething troubles: - MSI is broken for hotplug signaling on the downstream bridges: The chip just never sends an interrupt. It requests 32 MSIs for each of its six bridges and the pcieport driver only allocates one per bridge. However I've verified that even if 32 MSIs are allocated there's no interrupt on hotplug. The only option is thus to disable MSI, which is also what OS X does. Apparently all Thunderbolt chips up to revision 1 of Cactus Ridge 4C are plagued by this issue so quirk those as well. - The chip supports a maximum hop_count of 32, unlike its successors which support only 12. Fixup ring_interrupt_active() to cope with values >= 32. - Another peculiarity is that the chip supports a maximum of 13 ports whereas its successors support 12. However the additional port (#5) seems to be unusable as reading its TB_CFG_PORT config space results in TB_CFG_ERROR_INVALID_CONFIG_SPACE. Add a quirk to mark the port disabled on the root switch, assuming that's necessary on all Macs using this chip. Tested-by: Lukas Wunner [MacBookPro9,1] Tested-by: William Brown [MacBookPro8,2] Signed-off-by: Lukas Wunner Signed-off-by: Bjorn Helgaas Acked-by: Andreas Noever