1. 17 10月, 2008 2 次提交
  2. 23 4月, 2008 1 次提交
  3. 20 4月, 2008 2 次提交
  4. 22 2月, 2008 1 次提交
  5. 28 1月, 2008 1 次提交
  6. 25 1月, 2008 13 次提交
  7. 13 10月, 2007 8 次提交
  8. 12 7月, 2007 3 次提交
    • T
      sysfs: kill unnecessary attribute->owner · 7b595756
      Tejun Heo 提交于
      sysfs is now completely out of driver/module lifetime game.  After
      deletion, a sysfs node doesn't access anything outside sysfs proper,
      so there's no reason to hold onto the attribute owners.  Note that
      often the wrong modules were accounted for as owners leading to
      accessing removed modules.
      
      This patch kills now unnecessary attribute->owner.  Note that with
      this change, userland holding a sysfs node does not prevent the
      backing module from being unloaded.
      
      For more info regarding lifetime rule cleanup, please read the
      following message.
      
        http://article.gmane.org/gmane.linux.kernel/510293
      
      (tweaked by Greg to not delete the field just yet, to make it easier to
      merge things properly.)
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      Cc: Cornelia Huck <cornelia.huck@de.ibm.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      7b595756
    • C
      Driver core: coding style cleanup · dc0afa83
      Cornelia Huck 提交于
      This converts code of the form
      
      	if ((error = some_func()))
      		goto fixup;
      to
      	error = some_func();
      	if (error)
      		goto fixup;
      Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      dc0afa83
    • K
      Driver core: add missing kset uevent · 80f03e34
      Kay Sievers 提交于
      We get uevents for a bus/class going away, but not one registering.
      Add the missing uevent in kset_register(), which will send an
      event for a new bus/class. Suppress all unwanted uevents for bus
      subdirectories like /bus/*/devices/, /bus/*/drivers/.
      
      Now we get for module usbcore:
        add      /module/usbcore (module)
        add      /bus/usb (bus)
        add      /class/usb_host (class)
        add      /bus/usb/drivers/hub (drivers)
        add      /bus/usb/drivers/usb (drivers)
        remove   /bus/usb/drivers/usb (drivers)
        remove   /bus/usb/drivers/hub (drivers)
        remove   /class/usb_host (class)
        remove   /bus/usb (bus)
        remove   /module/usbcore (module)
      
      instead of:
        add      /module/usbcore (module)
        add      /bus/usb/drivers/hub (drivers)
        add      /bus/usb/drivers/usb (drivers)
        remove   /bus/usb/drivers/usb (drivers)
        remove   /bus/usb/drivers/hub (drivers)
        remove   /class/usb_host (class)
        remove   /bus/usb/drivers (bus)
        remove   /bus/usb/devices (bus)
        remove   /bus/usb (bus)
        remove   /module/usbcore (module)
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      80f03e34
  9. 03 5月, 2007 1 次提交
  10. 28 4月, 2007 4 次提交
    • G
      driver core: bus_add_driver should return an error if no bus · 4f6e1945
      Greg Kroah-Hartman 提交于
      As pointed out by Dave Jones.
      
      Cc: Dave Jones <davej@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      4f6e1945
    • G
      Driver core: remove unneeded completion from driver release path · 74e9f5fa
      Greg Kroah-Hartman 提交于
      The completion in the driver release path is due to ancient history in
      the _very_ early 2.5 days when we were not tracking the module reference
      count of attributes.  It is not needed at all and can be removed.
      
      Note, we now have an empty release function for the driver structure.
      This is due to the fact that drivers are statically allocated in the
      system at this point in time, something which I want to change in the
      future.  But remember, drivers are really code, which is reference
      counted by the module, unlike devices, which are data and _must_ be
      reference counted properly in order to work correctly.
      
      
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      74e9f5fa
    • C
      driver core: don't fail attaching the device if it cannot be bound · c6a46696
      Cornelia Huck 提交于
      Don't fail bus_attach_device() if the device cannot be bound.
      
      If dev->driver has been specified, reset it to NULL if device_bind_driver()
      failed and add the device as an unbound device.  As a result,
      bus_attach_device() now cannot fail, and we can remove some checking from
      device_add().
      
      Also remove an unneeded check in bus_rescan_devices_helper().
      Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      c6a46696
    • K
      Driver core: udev triggered device-<>driver binding · b8c5cec2
      Kay Sievers 提交于
      We get two per-bus sysfs files:
        ls-l /sys/subsystem/usb
        drwxr-xr-x 2 root root    0 2007-02-16 16:42 devices
        drwxr-xr-x 7 root root    0 2007-02-16 14:55 drivers
        -rw-r--r-- 1 root root 4096 2007-02-16 16:42 drivers_autoprobe
        --w------- 1 root root 4096 2007-02-16 16:42 drivers_probe
      
      The flag "drivers_autoprobe" controls the behavior of the bus to bind
      devices by default, or just initialize the device and leave it alone.
      
      The command "drivers_probe" accepts a bus_id and the bus tries to bind a
      driver to this device.
      
      Systems who want to control the driver binding with udev, switch off the
      bus initiated probing:
        echo 0 > /sys/subsystem/usb/drivers_autoprobe
        echo 0 > /sys/subsystem/pcmcia/drivers_autoprobe
        ...
      
      and initiate the probing with udev rules like:
        ACTION=="add", SUBSYSTEM=="usb", ATTR{subsystem/drivers_probe}="$kernel"
        ACTION=="add", SUBSYSTEM=="pcmcia", ATTR{subsystem/drivers_probe}="$kernel"
        ...
      
      Custom driver binding can happen in earlier rules by something like:
        ACTION=="add", SUBSYSTEM=="usb", \
        ATTRS{idVendor}=="1234", ATTRS{idProduct}=="5678" \
        ATTR{subsystem/drivers/<custom-driver>/bind}="$kernel"
      
      This is intended to solve the modprobe.conf mess with "install-rules", custom
      bind/unbind-scripts and all the weird things people invented over the years.
      It should also provide the functionality "libusual" was supposed to do.
      
      With udev, one can just write a udev rule to drive all USB-disks at the
      third port of USB-hub by the "ub" driver, and everything else by
      usb-storage. One can also instruct udev to bind different wireless
      drivers to identical cards - just selected by the pcmcia slot-number, and
      whatever ...
      
      To use the mentioned rules, it needs udev version 106, to be able to
      write ATTR{}="$kernel" to sysfs files.
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b8c5cec2
  11. 17 2月, 2007 1 次提交
  12. 02 12月, 2006 2 次提交
    • K
      CONFIG_SYSFS_DEPRECATED - bus symlinks · b9cafc7d
      Kay Sievers 提交于
      Turn off the bus symlinks if CONFIG_SYSFS_DEPRECATED is enabled
      Signed-off-by: NKay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      b9cafc7d
    • B
      Driver core: add notification of bus events · 116af378
      Benjamin Herrenschmidt 提交于
      I finally did as you suggested and added the notifier to the struct
      bus_type itself. There are still problems to be expected is something
      attaches to a bus type where the code can hook in different struct
      device sub-classes (which is imho a big bogosity but I won't even try to
      argue that case now) but it will solve nicely a number of issues I've
      had so far.
      
      That also means that clients interested in registering for such
      notifications have to do it before devices are added and after bus types
      are registered. Fortunately, most bus types that matter for the various
      usage scenarios I have in mind are registerd at postcore_initcall time,
      which means I have a really nice spot at arch_initcall time to add my
      notifiers.
      
      There are 4 notifications provided. Device being added (before hooked to
      the bus) and removed (failure of previous case or after being unhooked
      from the bus), along with driver being bound to a device and about to be
      unbound.
      
      The usage I have for these are:
      
       - The 2 first ones are used to maintain a struct device_ext that is
      hooked to struct device.firmware_data. This structure contains for now a
      pointer to the Open Firmware node related to the device (if any), the
      NUMA node ID (for quick access to it) and the DMA operations pointers &
      iommu table instance for DMA to/from this device. For bus types I own
      (like IBM VIO or EBUS), I just maintain that structure directly from the
      bus code when creating the devices. But for bus types managed by generic
      code like PCI or platform (actually, of_platform which is a variation of
      platform linked to Open Firmware device-tree), I need this notifier.
      
       - The other two ones have a completely different usage scenario. I have
      cases where multiple devices and their drivers depend on each other. For
      example, the IBM EMAC network driver needs to attach to a MAL DMA engine
      which is a separate device, and a PHY interface which is also a separate
      device. They are all of_platform_device's (well, about to be with my
      upcoming patches) but there is no say in what precise order the core
      will "probe" them and instanciate the various modules. The solution I
      found for that is to have the drivers for emac to use multithread_probe,
      and wait for a driver to be bound to the target MAL and PHY control
      devices (the device-tree contains reference to the MAL and PHY interface
      nodes, which I can then match to of_platform_devices). Right now, I've
      been polling, but with that notifier, I can more cleanly wait (with a
      timeout of course).
      Signed-off-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      116af378
  13. 19 10月, 2006 1 次提交