)]}'
{
  "log": [
    {
      "commit": "fa890d586cc127ce72597ba0a909bfecf784e10c",
      "tree": "fa29dd1f6e0385b6193b11207f5bfd0a674d4979",
      "parents": [
        "5e41d0d60a534d2a5dc9772600a58f44c8d12506"
      ],
      "author": {
        "name": "Matthew Wilcox",
        "email": "matthew@wil.cx",
        "time": "Sun Sep 16 17:01:26 2007 -0600"
      },
      "committer": {
        "name": "Linus Torvalds",
        "email": "torvalds@woody.linux-foundation.org",
        "time": "Sun Sep 16 21:13:58 2007 -0700"
      },
      "message": "Fix non-ISA link error in drivers/scsi/advansys.c\n\nWhen CONFIG_ISA is disabled, the isa_driver support will not be compiled\nin.  Define stubs so that we don\u0027t get link-time errors.\n\nSigned-off-by: Matthew Wilcox \u003cmatthew@wil.cx\u003e\nSigned-off-by: Linus Torvalds \u003ctorvalds@linux-foundation.org\u003e\n"
    },
    {
      "commit": "a5117ba7da37deb09df5eb802dace229b3fb1e9f",
      "tree": "eec1e160cbc11a4a1dae107ed27d92c991f5fcf6",
      "parents": [
        "3e95637a48820ff8bedb33e6439def96ccff1de5"
      ],
      "author": {
        "name": "Rene Herman",
        "email": "rene.herman@keyaccess.nl",
        "time": "Tue Jun 06 23:54:02 2006 +0200"
      },
      "committer": {
        "name": "Greg Kroah-Hartman",
        "email": "gregkh@suse.de",
        "time": "Wed Jun 21 12:40:49 2006 -0700"
      },
      "message": "[PATCH] Driver model: add ISA bus\n\nDuring the recent \"isa drivers using platform devices\" discussion it was\npointed out that (ALSA) ISA drivers ran into the problem of not having\nthe option to fail driver load (device registration rather) upon not\nfinding their hardware due to a probe() error not being passed up\nthrough the driver model. In the course of that, I suggested a seperate\nISA bus might be best; Russell King agreed and suggested this bus could\nuse the .match() method for the actual device discovery.\n\nThe attached does this. For this old non (generically) discoverable ISA\nhardware only the driver itself can do discovery so as a difference with\nthe platform_bus, this isa_bus also distributes match() up to the driver.\n\nAs another difference: these devices only exist in the driver model due\nto the driver creating them because it might want to drive them, meaning\nthat all device creation has been made internal as well.\n\nThe usage model this provides is nice, and has been acked from the ALSA\nside by Takashi Iwai and Jaroslav Kysela. The ALSA driver module_init\u0027s\nnow (for oldisa-only drivers) become:\n\nstatic int __init alsa_card_foo_init(void)\n{\n\treturn isa_register_driver(\u0026snd_foo_isa_driver, SNDRV_CARDS);\n}\n\nstatic void __exit alsa_card_foo_exit(void)\n{\n\tisa_unregister_driver(\u0026snd_foo_isa_driver);\n}\n\nQuite like the other bus models therefore. This removes a lot of\nduplicated init code from the ALSA ISA drivers.\n\nThe passed in isa_driver struct is the regular driver struct embedding a\nstruct device_driver, the normal probe/remove/shutdown/suspend/resume\ncallbacks, and as indicated that .match callback.\n\nThe \"SNDRV_CARDS\" you see being passed in is a \"unsigned int ndev\"\nparameter, indicating how many devices to create and call our methods with.\n\nThe platform_driver callbacks are called with a platform_device param;\nthe isa_driver callbacks are being called with a \"struct device *dev,\nunsigned int id\" pair directly -- with the device creation completely\ninternal to the bus it\u0027s much cleaner to not leak isa_dev\u0027s by passing\nthem in at all. The id is the only thing we ever want other then the\nstruct device * anyways, and it makes for nicer code in the callbacks as\nwell.\n\nWith this additional .match() callback ISA drivers have all options. If\nALSA would want to keep the old non-load behaviour, it could stick all\nof the old .probe in .match, which would only keep them registered after\neverything was found to be present and accounted for. If it wanted the\nbehaviour of always loading as it inadvertently did for a bit after the\nchangeover to platform devices, it could just not provide a .match() and\ndo everything in .probe() as before.\n\nIf it, as Takashi Iwai already suggested earlier as a way of following\nthe model from saner buses more closely, wants to load when a later bind\ncould conceivably succeed, it could use .match() for the prerequisites\n(such as checking the user wants the card enabled and that port/irq/dma\nvalues have been passed in) and .probe() for everything else. This is\nthe nicest model.\n\nTo the code...\n\nThis exports only two functions; isa_{,un}register_driver().\n\nisa_register_driver() register\u0027s the struct device_driver, and then\nloops over the passed in ndev creating devices and registering them.\nThis causes the bus match method to be called for them, which is:\n\nint isa_bus_match(struct device *dev, struct device_driver *driver)\n{\n          struct isa_driver *isa_driver \u003d to_isa_driver(driver);\n\n          if (dev-\u003eplatform_data \u003d\u003d isa_driver) {\n                  if (!isa_driver-\u003ematch ||\n                          isa_driver-\u003ematch(dev, to_isa_dev(dev)-\u003eid))\n                          return 1;\n                  dev-\u003eplatform_data \u003d NULL;\n          }\n          return 0;\n}\n\nThe first thing this does is check if this device is in fact one of this\ndriver\u0027s devices by seeing if the device\u0027s platform_data pointer is set\nto this driver. Platform devices compare strings, but we don\u0027t need to\ndo that with everything being internal, so isa_register_driver() abuses\ndev-\u003eplatform_data as a isa_driver pointer which we can then check here.\nI believe platform_data is available for this, but if rather not, moving\nthe isa_driver pointer to the private struct isa_dev is ofcourse fine as\nwell.\n\nThen, if the the driver did not provide a .match, it matches. If it did,\nthe driver match() method is called to determine a match.\n\nIf it did _not_ match, dev-\u003eplatform_data is reset to indicate this to\nisa_register_driver which can then unregister the device again.\n\nIf during all this, there\u0027s any error, or no devices matched at all\neverything is backed out again and the error, or -ENODEV, is returned.\n\nisa_unregister_driver() just unregisters the matched devices and the\ndriver itself.\n\nMore global points/questions...\n\n- I\u0027m introducing include/linux/isa.h. It was available but is ofcourse\na somewhat generic name. Moving more isa stuff over to it in time is\nofcourse fine, so can I have it please? :)\n\n- I\u0027m using device_initcall() and added the isa.o (dependent on\nCONFIG_ISA) after the base driver model things in the Makefile. Will\nthis do, or I really need to stick it in drivers/base/init.c, inside\n#ifdef CONFIG_ISA? It\u0027s working fine.\n\nLastly -- I also looked, a bit, into integrating with PnP. \"Old ISA\"\ncould be another pnp_protocol, but this does not seem to be a good\nmatch, largely due to the same reason platform_devices weren\u0027t -- the\ndevices do not have a life of their own outside the driver, meaning the\npnp_protocol {get,set}_resources callbacks would need to callback into\ndriver -- which again means you first need to _have_ that driver. Even\nif there\u0027s clean way around that, you only end up inventing fake but\nvalid-form PnP IDs and generally catering to the PnP layer without any\npractical advantages over this very simple isa_bus. The thing I also\nsuggested earlier about the user echoing values into /sys to set up the\nhardware from userspace first is... well, cute, but a horrible idea from\na user standpoint.\n\nComments ofcourse appreciated. Hope it\u0027s okay. As said, the usage model\nis nice at least.\n\nSigned-off-by: Rene Herman \u003crene.herman@keyaccess.nl\u003e\n"
    }
  ]
}