1. 17 Jun, 2016 2 commits
  2. 02 May, 2016 2 commits
  3. 01 May, 2016 1 commit
  4. 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>
  5. 16 Sep, 2007 1 commit
  6. 21 Jun, 2006 1 commit
    • 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>