1. 01 Mar, 2017 1 commit
  2. 03 Feb, 2017 1 commit
    • Ard Biesheuvel's avatar
      kbuild: modversions: add infrastructure for emitting relative CRCs · 56067812
      Ard Biesheuvel authored
      This add the kbuild infrastructure that will allow architectures to emit
      vmlinux symbol CRCs as 32-bit offsets to another location in the kernel
      where the actual value is stored. This works around problems with CRCs
      being mistaken for relocatable symbols on kernels that self relocate at
      runtime (i.e., powerpc with CONFIG_RELOCATABLE=y)
      
      For the kbuild side of things, this comes down to the following:
      
       - introducing a Kconfig symbol MODULE_REL_CRCS
      
       - adding a -R switch to genksyms to instruct it to emit the CRC symbols
         as references into the .rodata section
      
       - making modpost distinguish such references from absolute CRC symbols
         by the section index (SHN_ABS)
      
       - making kallsyms disregard non-absolute symbols with a __crc_ prefix
      Signed-off-by: default avatarArd Biesheuvel <ard.biesheuvel@linaro.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      56067812
  3. 29 Nov, 2016 1 commit
    • Nicholas Piggin's avatar
      kbuild: modpost warn if export version crc is missing · d8c1eb86
      Nicholas Piggin authored
      This catches the failing ceph CRC on with:
      
          LD      vmlinux.o
          MODPOST vmlinux.o
        WARNING: EXPORT symbol "ceph_monc_do_statfs" [vmlinux] version
        generation failed, symbol will not be versioned.
      
      When the modules referring to exported symbols are built, there is an
      existing warning for missing CRC, but it's not always the case such
      any such module will be built, and in any case it is useful to get a
      warning at the source.
      
      This gets a little verbose with CONFIG_DEBUG_SECTION_MISMATCH,
      producing a warning with each object linked, but I didn't think
      that warranted extra complexity to avoid.
      Signed-off-by: default avatarNicholas Piggin <npiggin@gmail.com>
      Signed-off-by: default avatarMichal Marek <mmarek@suse.com>
      d8c1eb86
  4. 26 Nov, 2016 1 commit
  5. 08 Oct, 2016 1 commit
  6. 27 Jun, 2016 1 commit
  7. 08 Jun, 2016 1 commit
  8. 06 May, 2016 1 commit
    • Philipp Zabel's avatar
      modpost: fix module autoloading for OF devices with generic compatible property · acbef7b7
      Philipp Zabel authored
      Since the wildcard at the end of OF module aliases is gone, autoloading
      of modules that don't match a device's last (most generic) compatible
      value fails.
      
      For example the CODA960 VPU on i.MX6Q has the SoC specific compatible
      "fsl,imx6q-vpu" and the generic compatible "cnm,coda960".  Since the
      driver currently only works with knowledge about the SoC specific
      integration, it doesn't list "cnm,cod960" in the module device table.
      
      This results in the device compatible
      "of:NvpuT<NULL>Cfsl,imx6q-vpuCcnm,coda960" not matching the module alias
      "of:N*T*Cfsl,imx6q-vpu" anymore, whereas before commit 2f632369
      ("modpost: don't add a trailing wildcard for OF module aliases") it
      matched the module alias "of:N*T*Cfsl,imx6q-vpu*".
      
      This patch adds two module aliases for each compatible, one without the
      wildcard and one with "C*" appended.
      
        $ modinfo coda | grep imx6q
        alias:          of:N*T*Cfsl,imx6q-vpuC*
        alias:          of:N*T*Cfsl,imx6q-vpu
      
      Fixes: 2f632369 ("modpost: don't add a trailing wildcard for OF module aliases")
      Link: http://lkml.kernel.org/r/1462203339-15340-1-git-send-email-p.zabel@pengutronix.deSigned-off-by: default avatarPhilipp Zabel <p.zabel@pengutronix.de>
      Cc: Javier Martinez Canillas <javier@osg.samsung.com>
      Cc: Brian Norris <computersforpeace@gmail.com>
      Cc: Sjoerd Simons <sjoerd.simons@collabora.co.uk>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: <stable@vger.kernel.org>	[4.5+]
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      acbef7b7
  9. 29 Feb, 2016 1 commit
    • Josh Poimboeuf's avatar
      objtool: Mark non-standard object files and directories · c0dd6716
      Josh Poimboeuf authored
      Code which runs outside the kernel's normal mode of operation often does
      unusual things which can cause a static analysis tool like objtool to
      emit false positive warnings:
      
       - boot image
       - vdso image
       - relocation
       - realmode
       - efi
       - head
       - purgatory
       - modpost
      
      Set OBJECT_FILES_NON_STANDARD for their related files and directories,
      which will tell objtool to skip checking them.  It's ok to skip them
      because they don't affect runtime stack traces.
      
      Also skip the following code which does the right thing with respect to
      frame pointers, but is too "special" to be validated by a tool:
      
       - entry
       - mcount
      
      Also skip the test_nx module because it modifies its exception handling
      table at runtime, which objtool can't understand.  Fortunately it's
      just a test module so it doesn't matter much.
      
      Currently objtool is the only user of OBJECT_FILES_NON_STANDARD, but it
      might eventually be useful for other tools.
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Bernd Petrovitsch <bernd@petrovitsch.priv.at>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Chris J Arges <chris.j.arges@canonical.com>
      Cc: Jiri Slaby <jslaby@suse.cz>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Michal Marek <mmarek@suse.cz>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Pedro Alves <palves@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: live-patching@vger.kernel.org
      Link: http://lkml.kernel.org/r/366c080e3844e8a5b6a0327dc7e8c2b90ca3baeb.1456719558.git.jpoimboe@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      c0dd6716
  10. 21 Jan, 2016 1 commit
    • Alan Modra's avatar
      powerpc: Simplify module TOC handling · c153693d
      Alan Modra authored
      PowerPC64 uses the symbol .TOC. much as other targets use
      _GLOBAL_OFFSET_TABLE_. It identifies the value of the GOT pointer (or in
      powerpc parlance, the TOC pointer). Global offset tables are generally
      local to an executable or shared library, or in the kernel, module. Thus
      it does not make sense for a module to resolve a relocation against
      .TOC. to the kernel's .TOC. value. A module has its own .TOC., and
      indeed the powerpc64 module relocation processing ignores the kernel
      value of .TOC. and instead calculates a module-local value.
      
      This patch removes code involved in exporting the kernel .TOC., tweaks
      modpost to ignore an undefined .TOC., and the module loader to twiddle
      the section symbol so that .TOC. isn't seen as undefined.
      
      Note that if the kernel was compiled with -msingle-pic-base then ELFv2
      would not have function global entry code setting up r2. In that case
      the module call stubs would need to be modified to set up r2 using the
      kernel .TOC. value, requiring some of this code to be reinstated.
      
      mpe: Furthermore a change in binutils master (not yet released) causes
      the current way we handle the TOC to no longer work when building with
      MODVERSIONS=y and RELOCATABLE=n. The symptom is that modules can not be
      loaded due to there being no version found for TOC.
      
      Cc: stable@vger.kernel.org # 3.16+
      Signed-off-by: default avatarAlan Modra <amodra@gmail.com>
      Signed-off-by: Michael Ellerman's avatarMichael Ellerman <mpe@ellerman.id.au>
      c153693d
  11. 15 Jan, 2016 1 commit
  12. 15 Dec, 2015 1 commit
  13. 26 Oct, 2015 1 commit
  14. 20 Oct, 2015 1 commit
  15. 06 Oct, 2015 1 commit
  16. 21 Sep, 2015 2 commits
  17. 20 Aug, 2015 1 commit
  18. 08 Aug, 2015 1 commit
    • Takashi Iwai's avatar
      modpost: abort if a module symbol is too long · 5cfb203a
      Takashi Iwai authored
      Module symbols have a limited length, but currently the build system
      allows the build finishing even if the driver code contains a too long
      symbol name, which eventually overflows the modversion_info[] item.
      The compiler may catch at compiling *.mod.c like
        CC      xxx.mod.o
        xxx.mod.c:18:16: warning: initializer-string for array of chars is too long
      but it's merely a warning.
      
      This patch adds the check of the symbol length in modpost and stops
      the build properly.
      
      Currently MODULE_NAME_LEN is defined in modpost.c instead of referring
      to the definition in kernel header because including linux/module.h is
      messy and we must cover cross-compilation.
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      5cfb203a
  19. 08 Jul, 2015 1 commit
    • Chris Metcalf's avatar
      modpost: work correctly with tile coldtext sections · 673c2c34
      Chris Metcalf authored
      The tilegx and tilepro compilers use .coldtext for their unlikely
      executed text section name, so an __attribute__((cold)) function
      will (when compiled with higher optimization levels) land in
      the .coldtext section.
      
      Modify modpost to add .coldtext to the set of OTHER_TEXT_SECTIONS
      so we don't get warnings about referencing such a section in an
      __ex_table block, and then also modify arch/tile/lib/memcpy_user_64.c
      so that it uses plain ".coldtext" instead of ".coldtext.memcpy".
      The latter naming is a relic of an earlier use of -ffunction-sections,
      which we no longer use by default.
      Signed-off-by: default avatarChris Metcalf <cmetcalf@ezchip.com>
      Acked-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      673c2c34
  20. 06 Jul, 2015 1 commit
    • Suthikulpanit, Suravee's avatar
      ACPI / scan: Add support for ACPI _CLS device matching · 26095a01
      Suthikulpanit, Suravee authored
      Device drivers typically use ACPI _HIDs/_CIDs listed in struct device_driver
      acpi_match_table to match devices. However, for generic drivers, we do not
      want to list _HID for all supported devices. Also, certain classes of devices
      do not have _CID (e.g. SATA, USB). Instead, we can leverage ACPI _CLS,
      which specifies PCI-defined class code (i.e. base-class, subclass and
      programming interface). This patch adds support for matching ACPI devices using
      the _CLS method.
      
      To support loadable module, current design uses _HID or _CID to match device's
      modalias. With the new way of matching with _CLS this would requires modification
      to the current ACPI modalias key to include _CLS. This patch appends PCI-defined
      class-code to the existing ACPI modalias as following.
      
          acpi:<HID>:<CID1>:<CID2>:..:<CIDn>:<bbsspp>:
      E.g:
          # cat /sys/devices/platform/AMDI0600:00/modalias
          acpi:AMDI0600:010601:
      
      where bb is th base-class code, ss is te sub-class code, and pp is the
      programming interface code
      
      Since there would not be _HID/_CID in the ACPI matching table of the driver,
      this patch adds a field to acpi_device_id to specify the matching _CLS.
      
          static const struct acpi_device_id ahci_acpi_match[] = {
              { ACPI_DEVICE_CLASS(PCI_CLASS_STORAGE_SATA_AHCI, 0xffffff) },
              {},
          };
      
      In this case, the corresponded entry in modules.alias file would be:
      
          alias acpi*:010601:* ahci_platform
      Acked-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Reviewed-by: default avatarHanjun Guo <hanjun.guo@linaro.org>
      Signed-off-by: default avatarSuravee Suthikulpanit <Suravee.Suthikulpanit@amd.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      26095a01
  21. 31 May, 2015 1 commit
  22. 24 May, 2015 1 commit
  23. 13 May, 2015 1 commit
    • Heikki Krogerus's avatar
      usb: add bus type for USB ULPI · 289fcff4
      Heikki Krogerus authored
      UTMI+ Low Pin Interface (ULPI) is a commonly used PHY
      interface for USB 2.0. The ULPI specification describes a
      standard set of registers which the vendors can extend for
      their specific needs. ULPI PHYs provide often functions
      such as charger detection and ADP sensing and probing.
      
      There are two major issues that the bus type is meant to
      tackle:
      
      Firstly, ULPI registers are accessed from the controller.
      The bus provides convenient method for the controller
      drivers to share that access with the actual PHY drivers.
      
      Secondly, there are already platforms that assume ULPI PHYs
      are runtime detected, such as many Intel Baytrail based
      platforms. They do not provide any kind of hardware
      description for the ULPI PHYs like separate ACPI device
      object that could be used to enumerate a device from.
      Signed-off-by: default avatarHeikki Krogerus <heikki.krogerus@linux.intel.com>
      Acked-by: default avatarDavid Cohen <david.a.cohen@linux.intel.com>
      Signed-off-by: default avatarFelipe Balbi <balbi@ti.com>
      289fcff4
  24. 22 Apr, 2015 7 commits
  25. 13 Apr, 2015 7 commits
  26. 31 Mar, 2015 1 commit
    • James Hogan's avatar
      MIPS: Add CDMM bus support · 8286ae03
      James Hogan authored
      Add MIPS Common Device Memory Map (CDMM) support in the form of a bus in
      the standard Linux device model. Each device attached via CDMM is
      discoverable via an 8-bit type identifier and may contain a number of
      blocks of memory mapped registers in the CDMM region. IRQs are expected
      to be handled separately.
      
      Due to the per-cpu (per-VPE for MT cores) nature of the CDMM devices,
      all the driver callbacks take place from workqueues which are run on the
      right CPU for the device in question, so that the driver doesn't need to
      be as concerned about which CPU it is running on. Callbacks also exist
      for when CPUs are taken offline, so that any per-CPU resources used by
      the driver can be disabled so they don't get forcefully migrated. CDMM
      devices are created as children of the CPU device they are attached to.
      
      Any existing CDMM configuration by the bootloader will be inherited,
      however platforms wishing to enable CDMM should implement the weak
      mips_cdmm_phys_base() function (see asm/cdmm.h) so that the bus driver
      knows where it should put the CDMM region in the physical address space
      if the bootloader hasn't already enabled it.
      
      A mips_cdmm_early_probe() function is also provided to allow early boot
      or particularly low level code to set up the CDMM region and probe for a
      specific device type, for example early console or KGDB IO drivers for
      the EJTAG Fast Debug Channel (FDC) CDMM device.
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: linux-mips@linux-mips.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/9599/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      8286ae03
  27. 02 Oct, 2014 1 commit
    • Kyle McMartin's avatar
      aarch64: filter $x from kallsyms · 6c34f1f5
      Kyle McMartin authored
      Similar to ARM, AArch64 is generating $x and $d syms... which isn't
      terribly helpful when looking at %pF output and the like. Filter those
      out in kallsyms, modpost and when looking at module symbols.
      
      Seems simplest since none of these check EM_ARM anyway, to just add it
      to the strchr used, rather than trying to make things overly
      complicated.
      
      initcall_debug improves:
      dmesg_before.txt: initcall $x+0x0/0x154 [sg] returned 0 after 26331 usecs
      dmesg_after.txt: initcall init_sg+0x0/0x154 [sg] returned 0 after 15461 usecs
      Signed-off-by: default avatarKyle McMartin <kyle@redhat.com>
      Acked-by: default avatarRusty Russell <rusty@rustcorp.com.au>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      6c34f1f5