From: Olof Johansson <email@example.com>
To: Borislav Petkov <firstname.lastname@example.org>
Cc: Michal Simek <email@example.com>,
Arnd Bergmann <firstname.lastname@example.org>,
email@example.com, Rob Herring <firstname.lastname@example.org>,
Mark Rutland <email@example.com>,
Mauro Carvalho Chehab <firstname.lastname@example.org>,
Amit Kucheria <email@example.com>,
Sudeep Holla <firstname.lastname@example.org>, Li Yang <email@example.com>,
Linux Kernel Mailing List <firstname.lastname@example.org>,
Linux ARM Mailing List <email@example.com>,
Subject: Re: [PATCH v10 5/6] arm64: zynqmp: Add DDRC node
Date: Mon, 5 Nov 2018 06:51:26 -0800 [thread overview]
Message-ID: <CAOesGMj=EbWgcYF2Mhh6TFMCdn1ub1Ze6fbXJnFFdsttWByXYg@mail.gmail.com> (raw)
On Mon, Nov 5, 2018 at 5:42 AM Borislav Petkov <firstname.lastname@example.org> wrote:
> On Mon, Nov 05, 2018 at 02:32:55PM +0100, Michal Simek wrote:
> > you don't have that HW anyway.
> Grrr, I'm not talking about me - I'm talking about people testing
> linux-next. And perhaps in this particular case it won't matter because
> this hw is not shipping yet or whatever but the question is about the
> principle of the whole thing.
> > I looked at v10 and I can't see your ack there. Can you please give me
> > a link?
> I'm talking about *other* patches for another driver.
> Please note that I'm replying to this thread as an example - the
> procedural question I have is not only related to the synopsys changes
> but the synopsys changes are a good example for the problem of EDAC
> changes being sent to me along with DT additions.
> As such, the question was aimed more at arm-soc people - that's why they
> were in To: - not at you.
In general, for new functionality where needing both the driver change
and a DT change to enable it (or a driver change and a config change
to enable it), we have been merging the changes separately between
driver trees and arm-soc. I.e. things will be in place, but not
enabled, until both sides land. Main reason for doing so is to cut
down on arbitrary dependencies between the trees, since there can
sometimes end up being a lot of them.
Since DT should strive for being backwards compatible (i.e, a driver
change shouldn't require a DT change for the kernel to not regress
functionally), this has been working pretty well.
However, if there's some other reason to share a base between the two
trees, we can do that. For most cases we've found that it's not needed
though. So let us know what you prefer here.
next prev parent reply other threads:[~2018-11-05 14:51 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-10-25 6:06 [PATCH v10 0/6] EDAC: Enhancements to Synopsys EDAC driver Manish Narani
2018-10-25 6:06 ` [PATCH v10 1/6] edac: synopsys: Add error handling for NULL in probe() Manish Narani
2018-10-25 6:06 ` [PATCH v10 2/6] dt: bindings: Document ZynqMP DDRC in Synopsys documentation Manish Narani
2018-10-25 6:06 ` [PATCH v10 3/6] edac: synopsys: Add macro defines for ZynqMP DDRC Manish Narani
2018-10-25 6:06 ` [PATCH v10 4/6] edac: synopsys: Add EDAC ECC support " Manish Narani
2018-10-25 6:07 ` [PATCH v10 5/6] arm64: zynqmp: Add DDRC node Manish Narani
2018-11-05 12:56 ` Borislav Petkov
2018-11-05 13:06 ` Michal Simek
2018-11-05 13:20 ` Borislav Petkov
2018-11-05 13:32 ` Michal Simek
2018-11-05 13:42 ` Borislav Petkov
2018-11-05 13:45 ` Michal Simek
2018-11-05 14:51 ` Olof Johansson [this message]
2018-11-05 19:47 ` Borislav Petkov
2018-11-05 20:38 ` Olof Johansson
2018-11-05 20:43 ` Borislav Petkov
2018-11-06 6:46 ` Michal Simek
2018-11-06 9:22 ` Borislav Petkov
2018-11-06 11:54 ` Michal Simek
2018-10-25 6:07 ` [PATCH v10 6/6] edac: synopsys: Add Error Injection support for ZynqMP DDRC Manish Narani
2018-11-02 8:38 ` [PATCH v10 0/6] EDAC: Enhancements to Synopsys EDAC driver Manish Narani
2018-11-02 8:58 ` Borislav Petkov
2018-11-06 10:03 ` Borislav Petkov
2018-11-06 10:42 ` Manish Narani
2018-11-06 10:58 ` Borislav Petkov
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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).