From: Saravana Kannan <saravanak@google.com>
To: Rob Herring <robh+dt@kernel.org>
Cc: Frank Rowand <frowand.list@gmail.com>,
Mark Rutland <mark.rutland@arm.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
David Collins <collinsd@codeaurora.org>,
Android Kernel Team <kernel-team@android.com>
Subject: Re: [PATCH v3 2/4] of/platform: Add functional dependency link from DT bindings
Date: Tue, 16 Jul 2019 16:49:38 -0700 [thread overview]
Message-ID: <CAGETcx8FN6E3dgUrK6uk0W1g_FBk1wzohjf3W9eeVeRds0zrAg@mail.gmail.com> (raw)
In-Reply-To: <CAL_JsqLySLMLanBJvyWqFGhVzXrEaUP-3t9MDmpnAXhQA_7y=g@mail.gmail.com>
Resending again due to HTML. Sorry about it, the darn thing keeps
getting turned on for some reason!
On Tue, Jul 16, 2019 at 3:57 PM Rob Herring <robh+dt@kernel.org> wrote:
>
> On Mon, Jul 15, 2019 at 7:05 PM Frank Rowand <frowand.list@gmail.com> wrote:
> >
> > On 7/15/19 11:40 AM, Saravana Kannan wrote:
> > > Replying again because the previous email accidentally included HTML.
> > >
> > > Thanks for taking the time to reconsider the wording Frank. Your
> > > intention was clear to me in the first email too.
> > >
> > > A kernel command line option can also completely disable this
> > > functionality easily and cleanly. Can we pick that as an option? I've
> > > an implementation of that in the v5 series I sent out last week.
> >
> > Yes, Rob suggested a command line option for debugging, and I am fine with
> > that. But even with that, I would like a lot of testing so that we have a
> > chance of finding systems that have trouble with the changes and could
> > potentially be fixed before impacting a large number of users.
>
> Leaving it in -next for more than a cycle will not help. There's some
> number of users who test linux-next. Then there's more that test -rc
> kernels. Then there's more that test final releases and/or stable
> kernels. Probably, the more stable the h/w, the more it tends to be
> latter groups. (I don't get reports of breaking PowerMacs with the
> changes sitting in linux-next.)
>
> My main worry about this being off by default is it won't get tested.
> I'm not sure there's enough interest to drive folks to turn it on and
> test. Maybe it needs to be on until we see breakage.
Android will start using this. So there's definitely going to be a lot
of motivation for people to start using this and testing this.
I'm also thinking we should start rejecting late_initcall_sync() level
clean up code in device drivers in the future and start asking them to
move to sync_state(). If this feature isn't turned on, the behavior
will default to a late_initcall_sync() level execution. But when this
is on, it'll actually work nicely with modules. So that's another way
to drive folks to it and improve things over time.
Maybe we can have this on by default in linux-next and -rc. Fix any
issues that show up and can be fixed without breaking the goal of this
series (make things work with modules). And finally turn it off by
default before it gets pulled into mainline? That way, we get the
maximum test coverage we can get, but not accidentally break anything
that wasn't tested?
Thanks,
Saravana
next prev parent reply other threads:[~2019-07-16 23:49 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-02 0:48 [PATCH v3 0/4] Solve postboot supplier cleanup and optimize probe ordering Saravana Kannan
2019-07-02 0:48 ` [PATCH v3 1/4] driver core: Add support for linking devices during device addition Saravana Kannan
2019-07-02 0:48 ` [PATCH v3 2/4] of/platform: Add functional dependency link from DT bindings Saravana Kannan
2019-07-02 1:31 ` Rob Herring
2019-07-02 3:25 ` Saravana Kannan
2019-07-02 13:27 ` Rob Herring
2019-07-15 14:26 ` Frank Rowand
2019-07-15 14:38 ` Frank Rowand
2019-07-15 14:47 ` Saravana Kannan
2019-07-15 18:40 ` Saravana Kannan
2019-07-16 1:05 ` Frank Rowand
2019-07-16 22:56 ` Rob Herring
2019-07-16 23:45 ` Saravana Kannan
2019-07-16 23:49 ` Saravana Kannan [this message]
2019-07-19 2:49 ` Frank Rowand
2019-07-16 22:41 ` Rob Herring
2019-07-02 0:48 ` [PATCH v3 3/4] driver core: Add sync_state driver/bus callback Saravana Kannan
2019-07-02 0:48 ` [PATCH v3 4/4] driver core: Add edit_links() callback for drivers Saravana Kannan
2019-07-02 1:46 ` Rob Herring
2019-07-02 3:40 ` Saravana Kannan
2019-07-03 0:03 ` [PATCH v3 0/4] Solve postboot supplier cleanup and optimize probe ordering David Collins
2019-07-03 0:59 ` Saravana Kannan
2019-07-03 22:26 ` Saravana Kannan
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=CAGETcx8FN6E3dgUrK6uk0W1g_FBk1wzohjf3W9eeVeRds0zrAg@mail.gmail.com \
--to=saravanak@google.com \
--cc=collinsd@codeaurora.org \
--cc=devicetree@vger.kernel.org \
--cc=frowand.list@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=rafael@kernel.org \
--cc=robh+dt@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).