-
Saravana Kannan authored
The uevents generated for an amba device need PID and CID information that's available only when the amba device is powered on, clocked and out of reset. So, if those resources aren't available, the information can't be read to generate the uevents. To workaround this requirement, if the resources weren't available, the device addition was deferred and retried periodically. However, this deferred addition retry isn't based on resources becoming available. Instead, it's retried every 5 seconds and causes arbitrary probe delays for amba devices and their consumers. Also, maintaining a separate deferred-probe like mechanism is maintenance headache. With this commit, instead of deferring the device addition, we simply defer the generation of uevents for the device and probing of the device (because drivers needs PID and CID to match) until the PID and CID information can be read. This allows us to delete all the amba specific deferring code and also avoid the arbitrary probing delays. Cc: Rob Herring <robh@kernel.org> Cc: Ulf Hansson <ulf.hansson@linaro.org> Cc: Saravana Kannan <saravanak@google.com> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Nicolas Saenz Julienne <nsaenz@kernel.org> Cc: Geert Uytterhoeven <geert+renesas@glider.be> Cc: Marek Szyprowski <m.szyprowski@samsung.com> Cc: Kefeng Wang <wangkefeng.wang@huawei.com> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: patches@armlinux.org.uk Signed-off-by: Saravana Kannan <saravanak@google.com> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Tested-by: Kefeng Wang <wangkefeng.wang@huawei.com> Tested-by: Sudeep Holla <sudeep.holla@arm.com> Signed-off-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
f2d3b9a4