From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Saravana Kannan <saravanak@google.com>
Cc: Philipp Zabel <p.zabel@pengutronix.de>,
Rob Herring <robh@kernel.org>,
Ulf Hansson <ulf.hansson@linaro.org>,
Linus Walleij <linus.walleij@linaro.org>,
Sudeep Holla <sudeep.holla@arm.com>,
Nicolas Saenz Julienne <nsaenz@kernel.org>,
Geert Uytterhoeven <geert+renesas@glider.be>,
Marek Szyprowski <m.szyprowski@samsung.com>,
Kefeng Wang <wangkefeng.wang@huawei.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
patches@armlinux.org.uk, kernel-team@android.com,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v6] amba: Remove deferred device addition
Date: Wed, 27 Jul 2022 23:16:08 +0100 [thread overview]
Message-ID: <YuG5KCksLWzThSmF@shell.armlinux.org.uk> (raw)
In-Reply-To: <20220727181936.3250466-1-saravanak@google.com>
On Wed, Jul 27, 2022 at 11:19:35AM -0700, Saravana Kannan wrote:
> 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.
Oh, this is absolutely horrible. I can apply it cleanly to my "misc"
branch, but it then conflicts when I re-merge my tree for the for-next
thing (which is only supposed to be for sfr - the hint is in the name!)
for-next is basically my "fixes" plus "misc" branch and anything else I
want sfr to pick up for the -next tree.
Applying this has to be on top of that merge commit, otherwise the
conflicts are horrid, but that then means I need to send Linus the
for-next merge commit (which I don't normally do.)
Gah, we have too many changes to drivers/bus/amba.c in this cycle,
some of them which have been submitted for 5.19 as fixes (and thus
are not in 5.18-rc1 which the misc branch is based upon for other
patch dependency reasons) and others in the misc branch for the next
cycle - and now your patch wants both, which I can't do without
rebasing the misc branch.
Sadly, getting these changes into GregKH's tree will just create a
conflict between Greg's tree and my tree.
Can we postpone this please?
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!
next prev parent reply other threads:[~2022-07-27 22:18 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-27 18:19 [PATCH v6] amba: Remove deferred device addition Saravana Kannan
2022-07-27 22:16 ` Russell King (Oracle) [this message]
2022-07-28 0:10 ` Saravana Kannan
2022-07-28 14:16 ` Russell King (Oracle)
2022-07-28 18:29 ` Saravana Kannan
2022-08-09 10:30 ` Guenter Roeck
2022-08-10 0:42 ` Saravana Kannan
2022-08-10 1:34 ` Guenter Roeck
2022-08-10 3:33 ` Saravana Kannan
2022-08-10 12:58 ` Guenter Roeck
2022-08-10 21:47 ` Isaac Manjarres
2022-08-11 2:03 ` Guenter Roeck
2022-08-11 2:28 ` Saravana Kannan
2022-08-11 4:09 ` Guenter Roeck
2022-08-11 16:51 ` Isaac Manjarres
2022-08-11 19:18 ` Isaac Manjarres
2022-08-11 19:55 ` Guenter Roeck
2022-08-12 5:12 ` Isaac Manjarres
2022-08-12 15:19 ` Guenter Roeck
2022-08-12 15:30 ` Guenter Roeck
2022-08-15 18:43 ` Isaac Manjarres
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YuG5KCksLWzThSmF@shell.armlinux.org.uk \
--to=linux@armlinux.org.uk \
--cc=geert+renesas@glider.be \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-team@android.com \
--cc=linus.walleij@linaro.org \
--cc=linux-kernel@vger.kernel.org \
--cc=m.szyprowski@samsung.com \
--cc=nsaenz@kernel.org \
--cc=p.zabel@pengutronix.de \
--cc=patches@armlinux.org.uk \
--cc=robh@kernel.org \
--cc=saravanak@google.com \
--cc=sudeep.holla@arm.com \
--cc=ulf.hansson@linaro.org \
--cc=wangkefeng.wang@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.