1. 17 Jun, 2016 1 commit
    • William Breathitt Gray's avatar
      isa: Allow ISA-style drivers on modern systems · 3a495511
      William Breathitt Gray authored
      Several modern devices, such as PC/104 cards, are expected to run on
      modern systems via an ISA bus interface. Since ISA is a legacy interface
      for most modern architectures, ISA support should remain disabled in
      general. Support for ISA-style drivers should be enabled on a per driver
      To allow ISA-style drivers on modern systems, this patch introduces the
      ISA_BUS_API and ISA_BUS Kconfig options. The ISA bus driver will now
      build conditionally on the ISA_BUS_API Kconfig option, which defaults to
      the legacy ISA Kconfig option. The ISA_BUS Kconfig option allows the
      ISA_BUS_API Kconfig option to be selected on architectures which do not
      enable ISA (e.g. X86_64).
      The ISA_BUS Kconfig option is currently only implemented for X86
      architectures. Other architectures may have their own ISA_BUS Kconfig
      options added as required.
      Reviewed-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarWilliam Breathitt Gray <vilhelm.gray@gmail.com>
      Acked-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  2. 01 May, 2016 1 commit
  3. 29 Mar, 2016 1 commit
    • William Breathitt Gray's avatar
      base: isa: Remove X86_32 dependency · b3c1be1b
      William Breathitt Gray authored
      Many motherboards utilize a LPC to ISA bridge in order to decode
      ISA-style port-mapped I/O addresses. This is particularly true for
      embedded motherboards supporting the PC/104 bus (a bus specification
      derived from ISA).
      These motherboards are now commonly running 64-bit x86 processors. The
      X86_32 dependency should be removed from the ISA bus configuration
      option in order to support these newer motherboards.
      A new config option, CONFIG_ISA_BUS, is introduced to allow for the
      compilation of the ISA bus driver independent of the CONFIG_ISA option.
      Devices which communicate via ISA-compatible buses can now be supported
      independent of the dependencies of the CONFIG_ISA option.
      Signed-off-by: default avatarWilliam Breathitt Gray <vilhelm.gray@gmail.com>
      Reviewed-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  4. 29 Jul, 2015 1 commit
    • Marc Zyngier's avatar
      drivers/base: Add MSI domain support for non-PCI devices · c09fcc4b
      Marc Zyngier authored
      With the msi_list and the msi_domain properties now being at the
      generic device level, it is starting to be relatively easy to offer
      a generic way of providing non-PCI MSIs.
      The two major hurdles with this idea are:
      - Lack of global ID that identifies a device: this is worked around by
        having a global ID allocator for each device that gets enrolled in
        the platform MSI subsystem
      - Lack of standard way to write the message in the generating device.
        This is solved by mandating driver code to provide a write_msg
        callback, so that everyone can have their own square wheel
      Apart from that, the API is fairly straightforward:
      - platform_msi_create_irq_domain creates an MSI domain that gets
        tagged with DOMAIN_BUS_PLATFORM_MSI
      - platform_msi_domain_alloc_irqs allocate MSIs for a given device,
        populating the msi_list
      - platform_msi_domain_free_irqs does what is written on the tin
      [ tglx: Created a seperate struct platform_msi_desc and added
        	kerneldoc entries ]
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Cc: <linux-arm-kernel@lists.infradead.org>
      Cc: Yijing Wang <wangyijing@huawei.com>
      Cc: Ma Jun <majun258@huawei.com>
      Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Cc: Duc Dang <dhdang@apm.com>
      Cc: Hanjun Guo <hanjun.guo@linaro.org>
      Cc: Bjorn Helgaas <bhelgaas@google.com>
      Cc: Jiang Liu <jiang.liu@linux.intel.com>
      Cc: Jason Cooper <jason@lakedaemon.net>
      Link: http://lkml.kernel.org/r/1438091186-10244-10-git-send-email-marc.zyngier@arm.com
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
  5. 07 Nov, 2014 1 commit
    • Sudeep Holla's avatar
      drivers: base: support cpu cache information interface to userspace via sysfs · 246246cb
      Sudeep Holla authored
      This patch adds initial support for providing processor cache information
      to userspace through sysfs interface. This is based on already existing
      implementations(x86, ia64, s390 and powerpc) and hence the interface is
      intended to be fully compatible.
      The main purpose of this generic support is to avoid further code
      duplication to support new architectures and also to unify all the existing
      different implementations.
      This implementation maintains the hierarchy of cache objects which reflects
      the system's cache topology. Cache devices are instantiated as needed as
      CPUs come online. The cache information is replicated per-cpu even if they are
      shared. A per-cpu array of cache information maintained is used mainly for
      sysfs-related book keeping.
      It also implements the shared_cpu_map attribute, which is essential for
      enabling both kernel and user-space to discover the system's overall cache
      This patch also add the missing ABI documentation for the cacheinfo sysfs
      interface already, which is well defined and widely used.
      Signed-off-by: default avatarSudeep Holla <sudeep.holla@arm.com>
      Reviewed-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Tested-by: default avatarStephen Boyd <sboyd@codeaurora.org>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: linux-api@vger.kernel.org
      Cc: linux390@de.ibm.com
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: linux-ia64@vger.kernel.org
      Cc: linuxppc-dev@lists.ozlabs.org
      Cc: linux-s390@vger.kernel.org
      Cc: x86@kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  6. 04 Nov, 2014 1 commit
    • Rafael J. Wysocki's avatar
      Driver core: Unified device properties interface for platform firmware · b31384fa
      Rafael J. Wysocki authored
      Add a uniform interface by which device drivers can request device
      properties from the platform firmware by providing a property name
      and the corresponding data type.  The purpose of it is to help to
      write portable code that won't depend on any particular platform
      firmware interface.
      The following general helper functions are added:
      The first one allows the caller to check if the given property is
      present.  The next 5 of them allow single-valued properties of
      various types to be retrieved in a uniform way.  The remaining 5 are
      for reading properties with multiple values (arrays of either numbers
      or strings).
      The interface covers both ACPI and Device Trees.
      This change set includes material from Mika Westerberg and Aaron Lu.
      Signed-off-by: default avatarAaron Lu <aaron.lu@intel.com>
      Signed-off-by: default avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Acked-by: default avatarGrant Likely <grant.likely@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
  7. 23 Sep, 2014 1 commit
    • Johannes Berg's avatar
      device coredump: add new device coredump class · 833c9545
      Johannes Berg authored
      Many devices run firmware and/or complex hardware, and most of that
      can have bugs. When it misbehaves, however, it is often much harder
      to debug than software running on the host.
      Introduce a "device coredump" mechanism to allow dumping internal
      device/firmware state through a generalized mechanism. As devices
      are different and information needed can vary accordingly, this
      doesn't prescribe a file format - it just provides mechanism to
      get data to be able to capture it in a generalized way (e.g. in
      The dumped data will be readable in sysfs in the virtual device's
      data file under /sys/class/devcoredump/devcd*/. Writing to it will
      free the data and remove the device, as does a 5-minute timeout.
      Note that generalized capturing of such data may result in privacy
      issues, so users generally need to be involved. In order to allow
      certain users/system integrators/... to disable the feature at all,
      introduce a Kconfig option to override the drivers that would like
      to have the feature.
      For now, this provides two ways of dumping data:
       1) with a vmalloc'ed area, that is then given to the subsystem
          and freed after retrieval or timeout
       2) with a generalized reader/free function method
      We could/should add more options, e.g. a list of pages, since the
      vmalloc area is very limited on some architectures.
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  8. 08 Jul, 2014 1 commit
  9. 10 Jan, 2014 1 commit
    • Russell King's avatar
      drivers/base: provide an infrastructure for componentised subsystems · 2a41e607
      Russell King authored
      Subsystems such as ALSA, DRM and others require a single card-level
      device structure to represent a subsystem.  However, firmware tends to
      describe the individual devices and the connections between them.
      Therefore, we need a way to gather up the individual component devices
      together, and indicate when we have all the component devices.
      We do this in DT by providing a "superdevice" node which specifies
      the components, eg:
      	imx-drm {
      		compatible = "fsl,drm";
      		crtcs = <&ipu1>;
      		connectors = <&hdmi>;
      The superdevice is declared into the component support, along with the
      subcomponents.  The superdevice receives callbacks to locate the
      subcomponents, and identify when all components are present.  At this
      point, we bind the superdevice, which causes the appropriate subsystem
      to be initialised in the conventional way.
      When any of the components or superdevice are removed from the system,
      we unbind the superdevice, thereby taking the subsystem down.
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  10. 29 Dec, 2013 1 commit
    • Rafael J. Wysocki's avatar
      ACPI / hotplug / driver core: Handle containers in a special way · caa73ea1
      Rafael J. Wysocki authored
      ACPI container devices require special hotplug handling, at least
      on some systems, since generally user space needs to carry out
      system-specific cleanup before it makes sense to offline devices in
      the container.  However, the current ACPI hotplug code for containers
      first attempts to offline devices in the container and only then it
      notifies user space of the container offline.
      Moreover, after commit 202317a5
       (ACPI / scan: Add acpi_device
      objects for all device nodes in the namespace), ACPI device objects
      representing containers are present as long as the ACPI namespace
      nodes corresponding to them are present, which may be forever, even
      if the container devices are physically detached from the system (the
      return values of the corresponding _STA methods change in those
      cases, but generally the namespace nodes themselves are still there).
      Thus it is useful to introduce entities representing containers that
      will go away during container hot-unplug.
      The goal of this change is to address both the above issues.
      The idea is to create a "companion" container system device for each
      of the ACPI container device objects during the initial namespace
      scan or on a hotplug event making the container present.  That system
      device will be unregistered on container removal.  A new bus type
      for container devices is added for this purpose, because device
      offline and online operations need to be defined for them.  The
      online operation is a trivial function that is always successful
      and the offline uses a callback pointed to by the container device's
      offline member.
      For ACPI containers that callback simply walks the list of ACPI
      device objects right below the container object (its children) and
      checks if all of their physical companion devices are offline.  If
      that's not the case, it returns -EBUSY and the container system
      devivce cannot be put offline.  Consequently, to put the container
      system device offline, it is necessary to put all of the physical
      devices depending on its ACPI companion object offline beforehand.
      Container system devices created for ACPI container objects are
      initially online.  They are created by the container ACPI scan
      handler whose hotplug.demand_offline flag is set.  That causes
      acpi_scan_hot_remove() to check if the companion container system
      device is offline before attempting to remove an ACPI container or
      any devices below it.  If the check fails, a KOBJ_CHANGE uevent is
      emitted for the container system device in question and user space
      is expected to offline all devices below the container and the
      container itself in response to it.  Then, user space can finalize
      the removal of the container with the help of its ACPI device
      object's eject attribute in sysfs.
      Tested-by: default avatarYasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  11. 02 Jul, 2013 1 commit
  12. 27 Jun, 2013 1 commit
    • Maarten Lankhorst's avatar
      reservation: cross-device reservation support, v4 · 786d7257
      Maarten Lankhorst authored
      This adds support for a generic reservations framework that can be
      hooked up to ttm and dma-buf and allows easy sharing of reservations
      across devices.
      The idea is that a dma-buf and ttm object both will get a pointer
      to a struct reservation_object, which has to be reserved before
      anything is done with the contents of the dma-buf.
      Changes since v1:
       - Fix locking issue in ticket_reserve, which could cause mutex_unlock
         to be called too many times.
      Changes since v2:
       - All fence related calls and members have been taken out for now,
         what's left is the bare minimum to be useful for ttm locking conversion.
      Changes since v3:
       - Removed helper functions too. The documentation has an example
         implementation for locking. With the move to ww_mutex there is no
         need to have much logic any more.
      Signed-off-by: default avatarMaarten Lankhorst <maarten.lankhorst@canonical.com>
      Reviewed-by: default avatarJerome Glisse <jglisse@redhat.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
  13. 23 Jan, 2013 1 commit
    • Linus Walleij's avatar
      drivers/pinctrl: grab default handles from device core · ab78029e
      Linus Walleij authored
      This makes the device core auto-grab the pinctrl handle and set
      the "default" (PINCTRL_STATE_DEFAULT) state for every device
      that is present in the device model right before probe. This will
      account for the lion's share of embedded silicon devcies.
      A modification of the semantics for pinctrl_get() is also done:
      previously if the pinctrl handle for a certain device was already
      taken, the pinctrl core would return an error. Now, since the
      core may have already default-grabbed the handle and set its
      state to "default", if the handle was already taken, this will
      be disregarded and the located, previously instanitated handle
      will be returned to the caller.
      This way all code in drivers explicitly requesting their pinctrl
      handlers will still be functional, and drivers that want to
      explicitly retrieve and switch their handles can still do that.
      But if the desired functionality is just boilerplate of this
      type in the probe() function:
      struct pinctrl  *p;
      p = devm_pinctrl_get_select_default(&dev);
      if (IS_ERR(p)) {
         if (PTR_ERR(p) == -EPROBE_DEFER)
              return -EPROBE_DEFER;
              dev_warn(&dev, "no pinctrl handle\n");
      The discussion began with the addition of such boilerplate
      to the omap4 keypad driver:
      A previous approach using notifiers was discussed:
      This failed because it could not handle deferred probes.
      This patch alone does not solve the entire dilemma faced:
      whether code should be distributed into the drivers or
      if it should be centralized to e.g. a PM domain. But it
      solves the immediate issue of the addition of boilerplate
      to a lot of drivers that just want to grab the default
      state. As mentioned, they can later explicitly retrieve
      the handle and set different states, and this could as
      well be done by e.g. PM domains as it is only related
      to a certain struct device * pointer.
      ChangeLog v4->v5 (Stephen):
      - Simplified the devicecore grab code.
      - Deleted a piece of documentation recommending that pins
        be mapped to a device rather than hogged.
      ChangeLog v3->v4 (Linus):
      - Drop overzealous NULL checks.
      - Move kref initialization to pinctrl_create().
      - Seeking Tested-by from Stephen Warren so we do not disturb
        the Tegra platform.
      - Seeking ACK on this from Greg (and others who like it) so I
        can merge it through the pinctrl subsystem.
      ChangeLog v2->v3 (Linus):
      - Abstain from using IS_ERR_OR_NULL() in the driver core,
        Russell recently sent a patch to remove it. Handle the
        NULL case explicitly even though it's a bogus case.
      - Make sure we handle probe deferral correctly in the device
        core file. devm_kfree() the container on error so we don't
        waste memory for devices without pinctrl handles.
      - Introduce reference counting into the pinctrl core using
        <linux/kref.h> so that we don't release pinctrl handles
        that have been obtained for two or more places.
      ChangeLog v1->v2 (Linus):
      - Only store a pointer in the device struct, and only allocate
        this if it's really used by the device.
      Cc: Felipe Balbi <balbi@ti.com>
      Cc: Benoit Cousson <b-cousson@ti.com>
      Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
      Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Cc: Mitch Bradley <wmb@firmworks.com>
      Cc: Ulf Hansson <ulf.hansson@linaro.org>
      Cc: Rafael J. Wysocki <rjw@sisk.pl>
      Cc: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
      Cc: Rickard Andersson <rickard.andersson@stericsson.com>
      Cc: Russell King <linux@arm.linux.org.uk>
      Reviewed-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      [swarren: fixed and simplified error-handling in pinctrl_bind_pins(), to
      correctly handle deferred probe. Removed admonition from docs not to use
      pinctrl hogs for devices]
      Signed-off-by: default avatarStephen Warren <swarren@nvidia.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
  14. 21 May, 2012 1 commit
  15. 10 Feb, 2012 1 commit
    • Lee Jones's avatar
      drivers/base: add bus for System-on-Chip devices · 74d1d82c
      Lee Jones authored
      Traditionally, any System-on-Chip based platform creates a flat list
      of platform_devices directly under /sys/devices/platform.
      In order to give these some better structure, this introduces a new
      bus type for soc_devices that are registered with the new
      soc_device_register() function.  All devices that are on the same
      chip should then be registered as child devices of the soc device.
      The soc bus also exports a few standardised device attributes which
      allow user space to query the specific type of soc.
      Signed-off-by: default avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
  16. 22 Jan, 2012 1 commit
  17. 06 Jan, 2012 1 commit
    • Sumit Semwal's avatar
      dma-buf: Introduce dma buffer sharing mechanism · d15bd7ee
      Sumit Semwal authored
      This is the first step in defining a dma buffer sharing mechanism.
      A new buffer object dma_buf is added, with operations and API to allow easy
      sharing of this buffer object across devices.
      The framework allows:
      - creation of a buffer object, its association with a file pointer, and
         associated allocator-defined operations on that buffer. This operation is
         called the 'export' operation.
      - different devices to 'attach' themselves to this exported buffer object, to
        facilitate backing storage negotiation, using dma_buf_attach() API.
      - the exported buffer object to be shared with the other entity by asking for
         its 'file-descriptor (fd)', and sharing the fd across.
      - a received fd to get the buffer object back, where it can be accessed using
         the associated exporter-defined operations.
      - the exporter and user to share the scatterlist associated with this buffer
         object using map_dma_buf and unmap_dma_buf operations.
      Atleast one 'attach()' call is required to be made prior to calling the
      map_dma_buf() operation.
      Couple of building blocks in map_dma_buf() are added to ease introduction
      of sync'ing across exporter and users, and late allocation by the exporter.
      For this first version, this framework will work with certain conditions:
      - *ONLY* exporter will be allowed to mmap to userspace (outside of this
         framework - mmap is not a buffer object operation),
      - currently, *ONLY* users that do not need CPU access to the buffer are
      More details are there in the documentation patch.
      This is based on design suggestions from many people at the mini-summits[1],
      most notably from Arnd Bergmann <arnd@arndb.de>, Rob Clark <rob@ti.com> and
      Daniel Vetter <daniel@ffwll.ch>.
      The implementation is inspired from proof-of-concept patch-set from
      Tomasz Stanislawski <t.stanislaws@samsung.com>, who demonstrated buffer sharing
      between two v4l2 devices. [2]
      [1]: https://wiki.linaro.org/OfficeofCTO/MemoryManagement
      [2]: http://lwn.net/Articles/454389
      Signed-off-by: default avatarSumit Semwal <sumit.semwal@linaro.org>
      Signed-off-by: default avatarSumit Semwal <sumit.semwal@ti.com>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Reviewed-by: default avatarDave Airlie <airlied@redhat.com>
      Reviewed-and-Tested-by: default avatarRob Clark <rob.clark@linaro.org>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
  18. 26 Nov, 2011 1 commit
  19. 23 Jul, 2011 1 commit
    • Mark Brown's avatar
      regmap: Add generic non-memory mapped register access API · b83a313b
      Mark Brown authored
      There are many places in the tree where we implement register access for
      devices on non-memory mapped buses, especially I2C and SPI. Since hardware
      designers seem to have settled on a relatively consistent set of register
      interfaces this can be effectively factored out into shared code.  There
      are a standard set of formats for marshalling data for exchange with the
      device, with the actual I/O mechanisms generally being simple byte
      We create an abstraction for marshaling data into formats which can be
      sent on the control interfaces, and create a standard method for
      plugging in actual transport underneath that.
      This is mostly a refactoring and renaming of the bottom level of the
      existing code for sharing register I/O which we have in ASoC. A
      subsequent patch in this series converts ASoC to use this.  The main
      difference in interface is that reads return values by writing to a
      location provided by a pointer rather than in the return value, ensuring
      we can use the full range of the type for register data.  We also use
      unsigned types rather than ints for the same reason.
      As some of the devices can have very large register maps the existing
      ASoC code also contains infrastructure for managing register caches.
      This cache work will be moved over in a future stage to allow for
      separate review, the current patch only deals with the physical I/O.
      Signed-off-by: default avatarMark Brown <broonie@opensource.wolfsonmicro.com>
      Acked-by: default avatarLiam Girdwood <lrg@ti.com>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      Acked-by: default avatarWolfram Sang <w.sang@pengutronix.de>
      Acked-by: default avatarGrant Likely <grant.likely@secretlab.ca>
  20. 14 Jun, 2011 1 commit
  21. 14 Mar, 2011 1 commit
    • Rafael J. Wysocki's avatar
      PM / Core: Introduce struct syscore_ops for core subsystems PM · 40dc166c
      Rafael J. Wysocki authored
      Some subsystems need to carry out suspend/resume and shutdown
      operations with one CPU on-line and interrupts disabled.  The only
      way to register such operations is to define a sysdev class and
      a sysdev specifically for this purpose which is cumbersome and
      inefficient.  Moreover, the arguments taken by sysdev suspend,
      resume and shutdown callbacks are practically never necessary.
      For this reason, introduce a simpler interface allowing subsystems
      to register operations to be executed very late during system suspend
      and shutdown and very early during resume in the form of
      strcut syscore_ops objects.
      Signed-off-by: default avatarRafael J. Wysocki <rjw@sisk.pl>
      Acked-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  22. 22 Oct, 2010 1 commit
  23. 15 Sep, 2009 2 commits
    • Kay Sievers's avatar
      Driver Core: devtmpfs - kernel-maintained tmpfs-based /dev · 2b2af54a
      Kay Sievers authored
      Devtmpfs lets the kernel create a tmpfs instance called devtmpfs
      very early at kernel initialization, before any driver-core device
      is registered. Every device with a major/minor will provide a
      device node in devtmpfs.
      Devtmpfs can be changed and altered by userspace at any time,
      and in any way needed - just like today's udev-mounted tmpfs.
      Unmodified udev versions will run just fine on top of it, and will
      recognize an already existing kernel-created device node and use it.
      The default node permissions are root:root 0600. Proper permissions
      and user/group ownership, meaningful symlinks, all other policy still
      needs to be applied by userspace.
      If a node is created by devtmps, devtmpfs will remove the device node
      when the device goes away. If the device node was created by
      userspace, or the devtmpfs created node was replaced by userspace, it
      will no longer be removed by devtmpfs.
      If it is requested to auto-mount it, it makes init=/bin/sh work
      without any further userspace support. /dev will be fully populated
      and dynamic, and always reflect the current device state of the kernel.
      With the commonly used dynamic device numbers, it solves the problem
      where static devices nodes may point to the wrong devices.
      It is intended to make the initial bootup logic simpler and more robust,
      by de-coupling the creation of the inital environment, to reliably run
      userspace processes, from a complex userspace bootstrap logic to provide
      a working /dev.
      Signed-off-by: default avatarKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: default avatarJan Blunck <jblunck@suse.de>
      Tested-By: default avatarHarald Hoyer <harald@redhat.com>
      Tested-By: default avatarScott James Remnant <scott@ubuntu.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
    • Ming Lei's avatar
      driver-core: move dma-coherent.c from kernel to driver/base · a56af876
      Ming Lei authored
      Placing dma-coherent.c in driver/base is better than in kernel,
      since it contains code to do per-device coherent dma memory
      Signed-off-by: default avatarMing Lei <tom.leiming@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  24. 03 Jan, 2009 1 commit
  25. 24 Jan, 2008 2 commits
  26. 04 Dec, 2007 1 commit
  27. 07 May, 2007 1 commit
    • Heiko Carstens's avatar
      Introduce CONFIG_HAS_DMA · 411f0f3e
      Heiko Carstens authored
      Architectures that don't support DMA can say so by adding a config NO_DMA
      to their Kconfig file.  This will prevent compilation of some dma specific
      driver code.  Also dma-mapping-broken.h isn't needed anymore on at least
      s390.  This avoids compilation and linking of otherwise dead/broken code.
      Other architectures that include dma-mapping-broken.h are arm26, h8300,
      m68k, m68knommu and v850.  If these could be converted as well we could get
      rid of the header file.
      Signed-off-by: default avatarHeiko Carstens <heiko.carstens@de.ibm.com>
      "John W. Linville" <linville@tuxdriver.com>
      Cc: Kyle McMartin <kyle@parisc-linux.org>
      Cc: <James.Bottomley@SteelEye.com>
      Cc: Tejun Heo <htejun@gmail.com>
      Cc: Jeff Garzik <jeff@garzik.org>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Cc: <geert@linux-m68k.org>
      Cc: <zippel@linux-m68k.org>
      Cc: <spyro@f2s.com>
      Cc: <uclinux-v850@lsi.nec.co.jp>
      Cc: <ysato@users.sourceforge.jp>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
  28. 09 Feb, 2007 1 commit
    • Tejun Heo's avatar
      devres: device resource management · 9ac7849e
      Tejun Heo authored
      Implement device resource management, in short, devres.  A device
      driver can allocate arbirary size of devres data which is associated
      with a release function.  On driver detach, release function is
      invoked on the devres data, then, devres data is freed.
      devreses are typed by associated release functions.  Some devreses are
      better represented by single instance of the type while others need
      multiple instances sharing the same release function.  Both usages are
      devreses can be grouped using devres group such that a device driver
      can easily release acquired resources halfway through initialization
      or selectively release resources (e.g. resources for port 1 out of 4
      This patch adds devres core including documentation and the following
      managed interfaces.
      * alloc/free	: devm_kzalloc(), devm_kzfree()
      * IO region	: devm_request_region(), devm_release_region()
      * IRQ		: devm_request_irq(), devm_free_irq()
      * DMA		: dmam_alloc_coherent(), dmam_free_coherent(),
      		  dmam_declare_coherent_memory(), dmam_pool_create(),
      * PCI		: pcim_enable_device(), pcim_pin_device(), pci_is_managed()
      * iomap		: devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
      		  devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
      		  pcim_iomap(), pcim_iounmap()
      Signed-off-by: default avatarTejun Heo <htejun@gmail.com>
      Signed-off-by: default avatarJeff Garzik <jeff@garzik.org>
  29. 01 Oct, 2006 1 commit
  30. 21 Jun, 2006 2 commits
    • Rene Herman's avatar
      [PATCH] Driver model: add ISA bus · a5117ba7
      Rene Herman authored
      During the recent "isa drivers using platform devices" discussion it was
      pointed out that (ALSA) ISA drivers ran into the problem of not having
      the option to fail driver load (device registration rather) upon not
      finding their hardware due to a probe() error not being passed up
      through the driver model. In the course of that, I suggested a seperate
      ISA bus might be best; Russell King agreed and suggested this bus could
      use the .match() method for the actual device discovery.
      The attached does this. For this old non (generically) discoverable ISA
      hardware only the driver itself can do discovery so as a difference with
      the platform_bus, this isa_bus also distributes match() up to the driver.
      As another difference: these devices only exist in the driver model due
      to the driver creating them because it might want to drive them, meaning
      that all device creation has been made internal as well.
      The usage model this provides is nice, and has been acked from the ALSA
      side by Takashi Iwai and Jaroslav Kysela. The ALSA driver module_init's
      now (for oldisa-only drivers) become:
      static int __init alsa_card_foo_init(void)
      	return isa_register_driver(&snd_foo_isa_driver, SNDRV_CARDS);
      static void __exit alsa_card_foo_exit(void)
      Quite like the other bus models therefore. This removes a lot of
      duplicated init code from the ALSA ISA drivers.
      The passed in isa_driver struct is the regular driver struct embedding a
      struct device_driver, the normal probe/remove/shutdown/suspend/resume
      callbacks, and as indicated that .match callback.
      The "SNDRV_CARDS" you see being passed in is a "unsigned int ndev"
      parameter, indicating how many devices to create and call our methods with.
      The platform_driver callbacks are called with a platform_device param;
      the isa_driver callbacks are being called with a "struct device *dev,
      unsigned int id" pair directly -- with the device creation completely
      internal to the bus it's much cleaner to not leak isa_dev's by passing
      them in at all. The id is the only thing we ever want other then the
      struct device * anyways, and it makes for nicer code in the callbacks as
      With this additional .match() callback ISA drivers have all options. If
      ALSA would want to keep the old non-load behaviour, it could stick all
      of the old .probe in .match, which would only keep them registered after
      everything was found to be present and accounted for. If it wanted the
      behaviour of always loading as it inadvertently did for a bit after the
      changeover to platform devices, it could just not provide a .match() and
      do everything in .probe() as before.
      If it, as Takashi Iwai already suggested earlier as a way of following
      the model from saner buses more closely, wants to load when a later bind
      could conceivably succeed, it could use .match() for the prerequisites
      (such as checking the user wants the card enabled and that port/irq/dma
      values have been passed in) and .probe() for everything else. This is
      the nicest model.
      To the code...
      This exports only two functions; isa_{,un}register_driver().
      isa_register_driver() register's the struct device_driver, and then
      loops over the passed in ndev creating devices and registering them.
      This causes the bus match method to be called for them, which is:
      int isa_bus_match(struct device *dev, struct device_driver *driver)
                struct isa_driver *isa_driver = to_isa_driver(driver);
                if (dev->platform_data == isa_driver) {
                        if (!isa_driver->match ||
                                isa_driver->match(dev, to_isa_dev(dev)->id))
                                return 1;
                        dev->platform_data = NULL;
                return 0;
      The first thing this does is check if this device is in fact one of this
      driver's devices by seeing if the device's platform_data pointer is set
      to this driver. Platform devices compare strings, but we don't need to
      do that with everything being internal, so isa_register_driver() abuses
      dev->platform_data as a isa_driver pointer which we can then check here.
      I believe platform_data is available for this, but if rather not, moving
      the isa_driver pointer to the private struct isa_dev is ofcourse fine as
      Then, if the the driver did not provide a .match, it matches. If it did,
      the driver match() method is called to determine a match.
      If it did _not_ match, dev->platform_data is reset to indicate this to
      isa_register_driver which can then unregister the device again.
      If during all this, there's any error, or no devices matched at all
      everything is backed out again and the error, or -ENODEV, is returned.
      isa_unregister_driver() just unregisters the matched devices and the
      driver itself.
      More global points/questions...
      - I'm introducing include/linux/isa.h. It was available but is ofcourse
      a somewhat generic name. Moving more isa stuff over to it in time is
      ofcourse fine, so can I have it please? :)
      - I'm using device_initcall() and added the isa.o (dependent on
      CONFIG_ISA) after the base driver model things in the Makefile. Will
      this do, or I really need to stick it in drivers/base/init.c, inside
      #ifdef CONFIG_ISA? It's working fine.
      Lastly -- I also looked, a bit, into integrating with PnP. "Old ISA"
      could be another pnp_protocol, but this does not seem to be a good
      match, largely due to the same reason platform_devices weren't -- the
      devices do not have a life of their own outside the driver, meaning the
      pnp_protocol {get,set}_resources callbacks would need to callback into
      driver -- which again means you first need to _have_ that driver. Even
      if there's clean way around that, you only end up inventing fake but
      valid-form PnP IDs and generally catering to the PnP layer without any
      practical advantages over this very simple isa_bus. The thing I also
      suggested earlier about the user echoing values into /sys to set up the
      hardware from userspace first is... well, cute, but a horrible idea from
      a user standpoint.
      Comments ofcourse appreciated. Hope it's okay. As said, the usage model
      is nice at least.
      Signed-off-by: default avatarRene Herman <rene.herman@keyaccess.nl>
    • Michael Holzheu's avatar
      [PATCH] Driver Core: Add /sys/hypervisor when needed · 4039483f
      Michael Holzheu authored
      To have a home for all hypervisors, this patch creates /sys/hypervisor.
      A new config option SYS_HYPERVISOR is introduced, which should to be set
      by architecture dependent hypervisors (e.g. s390 or Xen).
      Acked-by: default avatarMartin Schwidefsky <schwidefsky@de.ibm.com>
      Signed-off-by: default avatarMichael Holzheu <holzheu@de.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  31. 03 Feb, 2006 1 commit
    • Zhang, Yanmin's avatar
      [PATCH] Export cpu topology in sysfs · 69dcc991
      Zhang, Yanmin authored
      The patch implements cpu topology exportation by sysfs.
      Items (attributes) are similar to /proc/cpuinfo.
      1) /sys/devices/system/cpu/cpuX/topology/physical_package_id:
      	represent the physical package id of  cpu X;
      2) /sys/devices/system/cpu/cpuX/topology/core_id:
      	represent the cpu core id to cpu X;
      3) /sys/devices/system/cpu/cpuX/topology/thread_siblings:
      	represent the thread siblings to cpu X in the same core;
      4) /sys/devices/system/cpu/cpuX/topology/core_siblings:
      	represent the thread siblings to cpu X in the same physical package;
      To implement it in an architecture-neutral way, a new source file,
      driver/base/topology.c, is to export the 5 attributes.
      If one architecture wants to support this feature, it just needs to
      implement 4 defines, typically in file include/asm-XXX/topology.h.
      The 4 defines are:
      #define topology_physical_package_id(cpu)
      #define topology_core_id(cpu)
      #define topology_thread_siblings(cpu)
      #define topology_core_siblings(cpu)
      The type of **_id is int.
      The type of siblings is cpumask_t.
      To be consistent on all architectures, the 4 attributes should have
      deafult values if their values are unavailable. Below is the rule.
      1) physical_package_id: If cpu has no physical package id, -1 is the
      default value.
      2) core_id: If cpu doesn't support multi-core, its core id is 0.
      3) thread_siblings: Just include itself, if the cpu doesn't support
      4) core_siblings: Just include itself, if the cpu doesn't support
      multi-core and HT/Multi-thread.
      So be careful when declaring the 4 defines in include/asm-XXX/topology.h.
      If an attribute isn't defined on an architecture, it won't be exported.
      Thank Nathan, Greg, Andi, Paul and Venki.
      The patch provides defines for i386/x86_64/ia64.
      Signed-off-by: default avatarZhang, Yanmin <yanmin.zhang@intel.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Nick Piggin <nickpiggin@yahoo.com.au>
      Cc: Greg KH <greg@kroah.com>
      Signed-off-by: default avatarAndrew Morton <akpm@osdl.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@osdl.org>
  32. 29 Oct, 2005 1 commit
  33. 20 Jun, 2005 2 commits
  34. 17 May, 2005 1 commit
    • David Brownell's avatar
      [PATCH] Driver Core: remove driver model detach_state · 0b405a0f
      David Brownell authored
      The driver model has a "detach_state" mechanism that:
       - Has never been used by any in-kernel drive;
       - Is superfluous, since driver remove() methods can do the same thing;
       - Became buggy when the suspend() parameter changed semantics and type;
       - Could self-deadlock when called from certain suspend contexts;
       - Is effectively wasted documentation, object code, and headspace.
      This removes that "detach_state" mechanism; net code shrink, as well
      as a per-device saving in the driver model and sysfs.
      Signed-off-by: default avatarDavid Brownell <dbrownell@users.sourceforge.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
  35. 16 Apr, 2005 1 commit
    • Linus Torvalds's avatar
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds authored
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      Let it rip!