Skip to content

L
linux-davinci
Switch branch/tag
  1. 01 Dec, 2006 9 commits
    • Kay Sievers's avatar
      CONFIG_SYSFS_DEPRECATED - class symlinks · 805fab47
      Kay Sievers authored 
      Turn off class symlinks CONFIG_SYSFS_DEPRECATED is enabled.
Signed-off-by: default avatarKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      805fab47
    • Kay Sievers's avatar
      CONFIG_SYSFS_DEPRECATED - PHYSDEV* uevent variables · a87cb2ac
      Kay Sievers authored 
      Disable the PHYSDEV* uevent variables if CONFIG_SYSFS_DEPRECATED is
enabled.
Signed-off-by: default avatarKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      a87cb2ac
    • Kay Sievers's avatar
      CONFIG_SYSFS_DEPRECATED - device symlinks · 99ef3ef8
      Kay Sievers authored 
      Turn off device symlinks CONFIG_SYSFS_DEPRECATED is enabled.
Signed-off-by: default avatarKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      99ef3ef8
    • Kay Sievers's avatar
      CONFIG_SYSFS_DEPRECATED - bus symlinks · b9cafc7d
      Kay Sievers authored 
      Turn off the bus symlinks if CONFIG_SYSFS_DEPRECATED is enabled
Signed-off-by: default avatarKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      b9cafc7d
    • Greg Kroah-Hartman's avatar
      Driver core: make old versions of udev work properly · 40fa5422
      Greg Kroah-Hartman authored 
      If CONFIG_SYSFS_DEPRECATED is enabled, old versions of udev will work
properly with devices that are associated with a class.

Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      40fa5422
    • Kay Sievers's avatar
      CONFIG_SYSFS_DEPRECATED · 88a22c98
      Kay Sievers authored 
      Provide a way to support older versions of udev that are shipped in
older distros.  If this option is disabled, it will also turn off the
compatible symlinks in sysfs that older programs might rely on.

When in doubt, or if running a distro older than 2006, say Yes here.
Signed-off-by: default avatarKay Sievers <kay.sievers@vrfy.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      88a22c98
    • Greg Kroah-Hartman's avatar
      Driver Core: Move virtual_device_parent() to core.c · f0ee61a6
      Greg Kroah-Hartman authored 
      It doesn't need to be global or in device.h


Cc: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      f0ee61a6
    • Kay Sievers's avatar
      Driver core: fix "driver" symlink timing · 1901fb26
      Kay Sievers authored 
      Create the "driver" link before the child device may be created by
the probing logic. This makes it possible for userspace (udev), to
determine the driver property of the parent device, at the time the
child device is created.
Signed-off-by: default avatarKay Sievers <kay.sievers@novell.com>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      1901fb26
    • Benjamin Herrenschmidt's avatar
      Driver core: add notification of bus events · 116af378
      Benjamin Herrenschmidt authored 
      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: default avatarBenjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@suse.de>
      116af378
  3. 29 Nov, 2006 22 commits
  5. 28 Nov, 2006 9 commits