Eric Lee / smarc-ti-linux-kernel

16 Jun, 2009

2 commits

22 Apr, 2009

1 commit

  • d4d5291c8   driver synchronization: make scsi_wait_scan more advanced ... Browse Code »

    There is currently only one way for userspace to say "wait for my storage
    device to get ready for the modules I just loaded": to load the
    scsi_wait_scan module. Expectations of userspace are that once this
    module is loaded, all the (storage) devices for which the drivers
    were loaded before the module load are present.

    Now, there are some issues with the implementation, and the async
    stuff got caught in the middle of this: The existing code only
    waits for the scsy async probing to finish, but it did not take
    into account at all that probing might not have begun yet.
    (Russell ran into this problem on his computer and the fix works for him)

    This patch fixes this more thoroughly than the previous "fix", which
    had some bad side effects (namely, for kernel code that wanted to wait for
    the scsi scan it would also do an async sync, which would deadlock if you did
    it from async context already.. there's a report about that on lkml):
    The patch makes the module first wait for all device driver probes, and then it
    will wait for the scsi parallel scan to finish.

    Signed-off-by: Arjan van de Ven
    Tested-by: Russell King
    Signed-off-by: Linus Torvalds

    Arjan van de Ven
     

25 Mar, 2009

3 commits

  • 8940b4f31   driver core: move knode_driver into private structure ... Browse Code »

    Nothing outside of the driver core should ever touch knode_driver, so
    move it out of the public eye.

    Cc: Kay Sievers
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     
  • b23530ebc   driver core: remove polling for driver_probe_done(v5) ... Browse Code »

    This patch removes 100ms polling for driver_probe_done in
    wait_for_device_probe(), and uses wait_event() instead.
    Removing polling in fs initialization may lead to
    a faster boot.

    This patch also changes the return type of wait_for_device_done()
    from int to void.

    This patch is against Arjan's patch in linux-next tree.

    Signed-off-by: Ming Lei
    Acked-by: Cornelia Huck
    Reviewed-by: Arjan van de Ven
    Signed-off-by: Greg Kroah-Hartman

    Ming Lei
     
  • 49b420a13   driver core: check bus->match without holding device lock ... Browse Code »

    This patch moves bus->match out from driver_probe_device and
    does not hold device lock to check the match between a device
    and a driver.

    The idea has been verified by the commit 6cd495860901,
    which leads to a faster boot. But the commit 6cd495860901 has
    the following drawbacks: 1),only does the quick check in
    the path of __driver_attach->driver_probe_device, not in other
    paths; 2),for a matched device and driver, check the same match
    twice. It is a waste of cpu ,especially for some drivers with long
    device id table (eg. usb-storage driver).

    This patch adds a helper of driver_match_device to check the match
    in all paths, and testes the match only once.

    Signed-off-by: Ming Lei
    Acked-by: Cornelia Huck
    Signed-off-by: Greg Kroah-Hartman

    Ming Lei
     

22 Feb, 2009

1 commit

10 Jan, 2009

1 commit

07 Jan, 2009

3 commits

17 Oct, 2008

1 commit

  • 6cd495860   device model: Do a quickcheck for driver binding before doing an expensive check ... Browse Code »

    This patch adds a quick check for the driverdevice match before
    taking the locks and doin gthe expensive checks. Taking the lock hurts
    in asynchronous boot context where the device lock gets hit; one of the
    init functions takes the lock and goes to do an expensive hardware init;
    the other init functions walk the same PCI list and get stuck on the
    lock as a result.

    For the common case, we can know there's no chance whatsoever of a match
    if the device isn't in the drivers ID table... so this patch does that
    check as a best-effort-avoid-the-lock approach.

    Bootcharts for before and after can be seen at
    http://www.fenrus.org/before.svg
    http://www.fenrus.org/after.svg

    Note the long time "agp_ali_init" takes in the first graph; my laptop
    doesn't even have an ALI chip in it! (the bootgraphs look a bit
    dissimilar, but that's the point, the first one has a bunch of arbitrary
    delays in it that cause it to look very different)

    This reduces my kernel boot time by about 20%

    Signed-off-by: Arjan van de Ven
    Cc: Alan Stern
    Signed-off-by: Greg Kroah-Hartman

    Arjan van de Ven
     

20 Apr, 2008

1 commit

25 Jan, 2008

5 commits

  • 4a3ad20cc   Driver core: coding style fixes ... Browse Code »

    Fix up a number of coding style issues in the drivers/base/ directory
    that have annoyed me over the years. checkpatch.pl is now very happy.

    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     
  • ef2c51746   Driver core: fix race in __device_release_driver ... Browse Code »

    This patch (as1013) was suggested by David Woodhouse; it fixes a race
    in the driver core. If a device is unregistered at the same time as
    its driver is unloaded, the driver's code pages may be unmapped while
    the remove method is still running. The calls to get_driver() and
    put_driver() were intended to prevent this, but they don't work if the
    driver's module count has already dropped to 0.

    Instead, the patch keeps the device on the driver's list until after
    the remove method has returned. This forces the necessary
    synchronization to occur.

    Signed-off-by: Alan Stern
    Signed-off-by: David Woodhouse
    Signed-off-by: Greg Kroah-Hartman

    Alan Stern
     
  • 7dc72b284   Driver core: clean up debugging messages ... Browse Code »

    The driver core debugging messages are a mess. This provides a unified
    message that makes them actually useful.

    The format for new kobject debug messages should be:
    driver/bus/class: 'OBJECT_NAME': FUNCTION_NAME: message.\n

    Note, the class code is not changed in this patch due to pending patches
    in my queue that this would conflict with. A later patch will clean
    them up.

    Cc: Kay Sievers
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     
  • e5dd12784   Driver core: move the static kobject out of struct driver ... Browse Code »

    This patch removes the kobject, and a few other driver-core-only fields
    out of struct driver and into the driver core only. Now drivers can be
    safely create on the stack or statically (like they currently are.)

    Cc: Kay Sievers
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     
  • c6f7e72a3   driver core: remove fields from struct bus_type ... Browse Code »

    struct bus_type is static everywhere in the kernel. This moves the
    kobject in the structure out of it, and a bunch of other private only to
    the driver core fields are now moved to a private structure. This lets
    us dynamically create the backing kobject properly and gives us the
    chance to be able to document to users exactly how to use the struct
    bus_type as there are no fields they can improperly access.

    Thanks to Kay for the build fixes on this patch.

    Cc: Kay Sievers
    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     

12 Jul, 2007

2 commits

09 Jun, 2007

1 commit

03 May, 2007

1 commit

28 Apr, 2007

2 commits

  • c6a46696f   driver core: don't fail attaching the device if it cannot be bound ... Browse Code »

    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: Cornelia Huck
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Cornelia Huck
     
  • 21c7f30b1   driver core: per-subsystem multithreaded probing ... Browse Code »

    Make multithreaded probing work per subsystem instead of per driver.

    It doesn't make much sense to probe the same device for multiple drivers in
    parallel (after all, only one driver can bind to the device). Instead, create
    a probing thread for each device that probes the drivers one after another.
    Also make the decision to use multi-threaded probe per bus instead of per
    device and adapt the pci code.

    Signed-off-by: Cornelia Huck
    Cc: Benjamin Herrenschmidt
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Cornelia Huck
     

10 Feb, 2007

1 commit

  • 9ac7849e3   devres: device resource management ... Browse Code »
    13

    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
    supported.

    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
    ports).

    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(),
    dmam_pool_destroy()
    * 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: Tejun Heo
    Signed-off-by: Jeff Garzik

    Tejun Heo
     

08 Feb, 2007

2 commits

02 Dec, 2006

2 commits

  • 1901fb260   Driver core: fix "driver" symlink timing ... Browse Code »

    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: Kay Sievers
    Signed-off-by: Greg Kroah-Hartman

    Kay Sievers
     
  • 116af3782   Driver core: add notification of bus events ... Browse Code »

    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: Benjamin Herrenschmidt
    Signed-off-by: Greg Kroah-Hartman

    Benjamin Herrenschmidt
     

28 Oct, 2006

1 commit

  • 735a7ffb7   [PATCH] drivers: wait for threaded probes between initcall levels ... Browse Code »

    The multithreaded-probing code has a problem: after one initcall level (eg,
    core_initcall) has been processed, we will then start processing the next
    level (postcore_initcall) while the kernel threads which are handling
    core_initcall are still executing. This breaks the guarantees which the
    layered initcalls previously gave us.

    IOW, we want to be multithreaded _within_ an initcall level, but not between
    different levels.

    Fix that up by causing the probing code to wait for all outstanding probes at
    one level to complete before we start processing the next level.

    Cc: Greg KH
    Signed-off-by: Andrew Morton
    Signed-off-by: Linus Torvalds

    Andrew Morton
     

19 Oct, 2006

2 commits

26 Sep, 2006

3 commits

  • f2eaae197   Driver core: Fix potential deadlock in driver core ... Browse Code »

    There is a potential deadlock in the driver core. It boils down to
    the fact that bus_remove_device() calls klist_remove() instead of
    klist_del(), thereby waiting until the reference count of the
    klist_node in the bus's klist of devices drops to 0. The refcount
    can't reach 0 so long as a modprobe process is trying to bind a new
    driver to the device being removed, by calling __driver_attach(). The
    problem is that __driver_attach() tries to acquire the device's
    parent's semaphore, but the caller of bus_remove_device() is quite
    likely to own that semaphore already.

    It isn't sufficient just to replace klist_remove() with klist_del().
    Doing so runs the risk that the device would remain on the bus's klist
    of devices for some time, and so could be bound to another driver even
    after it was unregistered. What's needed is a new way to distinguish
    whether or not a device is registered, based on a criterion other than
    whether its klist_node is linked into the bus's klist of devices. That
    way driver binding can fail when the device is unregistered, even if
    it is still linked into the klist.

    This patch (as782) implements the solution, by adding a new bitflag to
    indiate when a struct device is registered, by testing the flag before
    allowing a driver to bind a device, and by changing the definition of
    the device_is_registered() inline.

    Signed-off-by: Alan Stern
    Signed-off-by: Greg Kroah-Hartman

    Alan Stern
     
  • d779249ed   Driver Core: add ability for drivers to do a threaded probe ... Browse Code »

    This adds the infrastructure for drivers to do a threaded probe, and
    waits at init time for all currently outstanding probes to complete.

    A new kernel thread will be created when the probe() function for the
    driver is called, if the multithread_probe bit is set in the driver
    saying it can support this kind of operation.

    I have tested this with USB and PCI, and it works, and shaves off a lot
    of time in the boot process, but there are issues with finding root boot
    disks, and some USB drivers assume that this can never happen, so it is
    currently not enabled for any bus type. Individual drivers can enable
    this right now if they wish, and bus authors can selectivly turn it on
    as well, once they determine that their subsystem will work properly
    with it.

    Signed-off-by: Greg Kroah-Hartman

    Greg Kroah-Hartman
     
  • f86db396f   drivers/base: check errors ... Browse Code »

    Add lots of return-value checking.

    : fix bus_rescan_devices()]
    Cc: "Randy.Dunlap"
    Signed-off-by: Cornelia Huck
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman

    Andrew Morton
     

15 Apr, 2006

1 commit

14 Jan, 2006

1 commit

  • 594c8281f   [PATCH] Add bus_type probe, remove, shutdown methods. ... Browse Code »

    Add bus_type probe, remove and shutdown methods to replace the
    corresponding methods in struct device_driver. This matches
    the way we handle the suspend/resume methods.

    Since the bus methods override the device_driver methods, warn
    if a device driver is registered whose methods will not be
    called.

    The long-term idea is to remove the device_driver methods entirely.

    Signed-off-by: Russell King
    Signed-off-by: Greg Kroah-Hartman

    Russell King
     

05 Jan, 2006

1 commit

  • bf74ad5bc   [PATCH] Hold the device's parent's lock during probe and remove ... Browse Code »

    This patch (as604) makes the driver core hold a device's parent's lock
    as well as the device's lock during calls to the probe and remove
    methods in a driver. This facility is needed by USB device drivers,
    owing to the peculiar way USB devices work:

    A device provides multiple interfaces, and drivers are bound
    to interfaces rather than to devices;

    Nevertheless a reset, reset-configuration, suspend, or resume
    affects the entire device and requires the caller to hold the
    lock for the device, not just a lock for one of the interfaces.

    Since a USB driver's probe method is always called with the interface
    lock held, the locking order rules (always lock parent before child)
    prevent these methods from acquiring the device lock. The solution
    provided here is to call all probe and remove methods, for all devices
    (not just USB), with the parent lock already acquired.

    Although currently only the USB subsystem requires these changes, people
    have mentioned in prior discussion that the overhead of acquiring an
    extra semaphore in all the prove/remove sequences is not overly large.

    Up to now, the USB core has been using its own set of private
    semaphores. A followup patch will remove them, relying entirely on the
    device semaphores provided by the driver core.

    The code paths affected by this patch are:

    device_add and device_del: The USB core already holds the parent
    lock, so no actual change is needed.

    driver_register and driver_unregister: The driver core will now
    lock both the parent and the device before probing or removing.

    driver_bind and driver_unbind (in sysfs): These routines will
    now lock both the parent and the device before binding or
    unbinding.

    bus_rescan_devices: The helper routine will lock the parent
    before probing a device.

    I have not tested this patch for conflicts with other subsystems. As
    far as I can see, the only possibility of conflict would lie in the
    bus_rescan_devices pathway, and it seems pretty remote. Nevertheless,
    it would be good for this to get a lot of testing in -mm.

    Signed-off-by: Alan Stern
    Signed-off-by: Greg Kroah-Hartman

    Alan Stern
     

24 Nov, 2005

1 commit

  • 2b08c8d04   [PATCH] Small fixes to driver core ... Browse Code »

    This patch (as603) makes a few small fixes to the driver core:

    Change spin_lock_irq for a klist lock to spin_lock;

    Fix reference count leaks;

    Minor spelling and formatting changes.

    Signed-off-by: Alan Stern
    Acked-by Patrick Mochel
    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: Linus Torvalds

    Alan Stern
     

22 Sep, 2005

1 commit

  • 4c898c7f2   [PATCH] Driver Core: fis bus rescan devices race ... Browse Code »

    bus_rescan_devices_helper() does not hold the dev->sem when it checks for
    !dev->driver(). device_attach() holds the sem, but calls again
    device_bind_driver() even when dev->driver is set.

    What happens is that a first device_attach() call (module insertion time)
    is on the way binding the device to a driver. Another thread calls
    bus_rescan_devices(). Now when bus_rescan_devices_helper() checks for
    dev->driver it is still NULL 'cos the the prior device_attach() is not yet
    finished. But as soon as the first one releases the dev->sem the second
    device_attach() tries to rebind the already bound device again.
    device_bind_driver() does this blindly which leads to a corrupt
    driver->klist_devices list (the device links itself, the head points to the
    device). Later a call to device_release_driver() sets dev->driver to NULL
    and breaks the link it has to itself on knode_driver. Rmmoding the driver
    later calls driver_detach() which leads to an endless loop 'cos the list
    head in klist_devices still points to the device. And since dev->driver is
    NULL it's stuck with the same device forever. Boom. And rmmod hangs.

    Very easy to reproduce with new-style pcmcia and a 16bit card. Just loop
    modprobe ;cardctl eject; rmmod .

    Easiest fix is to check if the device is already bound to a driver in
    device_bind_driver(). This avoids the double binding.

    Signed-off-by: Daniel Ritz
    Signed-off-by: Andrew Morton
    Signed-off-by: Greg Kroah-Hartman
    Signed-off-by: Linus Torvalds

    Daniel Ritz