lkml.org 
[lkml]   [2022]   [Jul]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5] amba: Remove deferred device addition
On Wed, Jul 27, 2022 at 09:43:32AM +0200, Greg Kroah-Hartman wrote:
> On Thu, Jul 21, 2022 at 02:58:27PM -0700, Saravana Kannan wrote:
> > On Thu, Jul 21, 2022 at 1:50 AM Russell King (Oracle)
> > <linux@armlinux.org.uk> wrote:
> > >
> > > On Wed, Jul 20, 2022 at 02:12:21PM +0100, Sudeep Holla wrote:
> > > > On Tue, Jul 19, 2022 at 11:20:10AM -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.
> > > > >
> > > > > 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>
> > > >
> > > > Tested-by: Sudeep Holla <sudeep.holla@arm.com>
> > > >
> > > > on Juno with linux-next(which had the reported issue [1]) + this patch(which
> > > > fixes the issue)
> > >
> > > Ok, but this patch needs to end up in the patch system for me to apply
> > > it. Can someone please add "KernelVersion: 5.19-rc7" or whatever version
> >
> > Where am I supposed to add that? Just somewhere in the email body?
> >
> > The patch you are replying to was based on your linu-arm/for-next the
> > day I sent it. Do you still need me to rebase it on Linus's tree?
> >
> > > the patch was generated against (just the tagged version is sufficient)
> > > somewhere in the email, and send it to patches@armlinu.org.uk.
> >
> > I'll send out the same patch as is to that email. Wait, is there a
> > typo in the domain name? Did you leave out the x by accident or is it
> > really armlinu? I'm also getting a DNS failure for either one of those
> > domains.
> >
> > I'll wait to hear from you before I send another email.
>
> Odd, I don't see the requirement for the arm patch-bot for the amba bus
> code anywhere in the documentation, am I missing it?

The requirement for the arm patch-bot is "patches that I apply", and
since I'm listed as maintainer for that code...

Sorry I missed the original reply highlighting the typo. Yes, it's a
typo (my X key was being a bit dodgy last week) and in any case,
"armlinu.org.uk" doesn't exist in the DNS, so sending to it would fail.
Also, every email I've sent over the last decade or more contains a
signature that gives a URL to the patch system, and the email address
is mentioned in its "Help" page (although there's other stuff on the
help page that needs to be updated to current practices.)

--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

\
 
 \ /
  Last update: 2022-07-27 09:54    [W:0.054 / U:0.224 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site