From: Maxime Coquelin <maxime.coquelin-qxv4g6HH51o@public.gmane.org>
To: Herbert Xu
<herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>,
Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Peter Korsgaard <peter-+2lRwdCCLRT2eFz/2MeuCQ@public.gmane.org>,
"kernel-F5mvAk5X5gdBDgjK7y7TUQ@public.gmane.org"
<kernel-F5mvAk5X5gdBDgjK7y7TUQ@public.gmane.org>,
Kieran Bingham
<kieranbingham-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
<linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [STLinux Kernel] [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP
Date: Wed, 30 Sep 2015 16:49:55 +0200 [thread overview]
Message-ID: <560BF693.2090405@st.com> (raw)
In-Reply-To: <20150930142812.GA19039-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
On 09/30/2015 04:28 PM, Herbert Xu wrote:
> On Wed, Sep 30, 2015 at 03:15:39PM +0100, Lee Jones wrote:
>>> I prefer not to merge patches that cannot be tested. Without
>>> the DT bits in patch 6 the other five patches are useless. So
>>> I think patch 6 should be applied together with the other five
>>> which add the driver.
>> That's crazy talk. If all subsystem maintainers abide by this rule
>> there would be chaos. We'd either need to send pull-requests to each
>> other for every set which crossed a subsystems boundary, or 1000's of
>> merge conflicts would ensue at merge time.
>>
>> The (sensible) rule we normally stick to is; as long as there isn't
>> a _build_ dependency, then the patches should filter though their
>> respective trees; _functional_ dependencies have nothing to do with
>> us as maintainers. Another chaos preventing rule we abide by is; thou
>> shalt not apply patches belonging to other maintainer's subsystems
>> without the appropriate Ack-by and a subsequent "you may take this
>> though your tree" and/or "please send me an immutable pull-request".
> So you want the series to be merged in two parts via two different
> trees where neither can be tested? That sounds crazy to me.
>
Yes, that's what we want, and that's how people work usually.
I will repeat what Lee was saying, what we have to ensure as maintainer
is that our tree is building.
We will be able to test it with linux-next.
Regards,
Maxime
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: maxime.coquelin@st.com (Maxime Coquelin)
To: linux-arm-kernel@lists.infradead.org
Subject: [STLinux Kernel] [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP
Date: Wed, 30 Sep 2015 16:49:55 +0200 [thread overview]
Message-ID: <560BF693.2090405@st.com> (raw)
In-Reply-To: <20150930142812.GA19039@gondor.apana.org.au>
On 09/30/2015 04:28 PM, Herbert Xu wrote:
> On Wed, Sep 30, 2015 at 03:15:39PM +0100, Lee Jones wrote:
>>> I prefer not to merge patches that cannot be tested. Without
>>> the DT bits in patch 6 the other five patches are useless. So
>>> I think patch 6 should be applied together with the other five
>>> which add the driver.
>> That's crazy talk. If all subsystem maintainers abide by this rule
>> there would be chaos. We'd either need to send pull-requests to each
>> other for every set which crossed a subsystems boundary, or 1000's of
>> merge conflicts would ensue at merge time.
>>
>> The (sensible) rule we normally stick to is; as long as there isn't
>> a _build_ dependency, then the patches should filter though their
>> respective trees; _functional_ dependencies have nothing to do with
>> us as maintainers. Another chaos preventing rule we abide by is; thou
>> shalt not apply patches belonging to other maintainer's subsystems
>> without the appropriate Ack-by and a subsequent "you may take this
>> though your tree" and/or "please send me an immutable pull-request".
> So you want the series to be merged in two parts via two different
> trees where neither can be tested? That sounds crazy to me.
>
Yes, that's what we want, and that's how people work usually.
I will repeat what Lee was saying, what we have to ensure as maintainer
is that our tree is building.
We will be able to test it with linux-next.
Regards,
Maxime
WARNING: multiple messages have this Message-ID (diff)
From: Maxime Coquelin <maxime.coquelin-qxv4g6HH51o@public.gmane.org>
To: Herbert Xu
<herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>,
Lee Jones <lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: "devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Peter Korsgaard <peter-+2lRwdCCLRT2eFz/2MeuCQ@public.gmane.org>,
"kernel-F5mvAk5X5gdBDgjK7y7TUQ@public.gmane.org"
<kernel-F5mvAk5X5gdBDgjK7y7TUQ@public.gmane.org>,
Kieran Bingham
<kieranbingham-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
Linus Torvalds
<torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org>,
linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Fabio Estevam <festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>,
"linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org"
<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>
Subject: Re: [STLinux Kernel] [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP
Date: Wed, 30 Sep 2015 16:49:55 +0200 [thread overview]
Message-ID: <560BF693.2090405@st.com> (raw)
In-Reply-To: <20150930142812.GA19039-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
On 09/30/2015 04:28 PM, Herbert Xu wrote:
> On Wed, Sep 30, 2015 at 03:15:39PM +0100, Lee Jones wrote:
>>> I prefer not to merge patches that cannot be tested. Without
>>> the DT bits in patch 6 the other five patches are useless. So
>>> I think patch 6 should be applied together with the other five
>>> which add the driver.
>> That's crazy talk. If all subsystem maintainers abide by this rule
>> there would be chaos. We'd either need to send pull-requests to each
>> other for every set which crossed a subsystems boundary, or 1000's of
>> merge conflicts would ensue at merge time.
>>
>> The (sensible) rule we normally stick to is; as long as there isn't
>> a _build_ dependency, then the patches should filter though their
>> respective trees; _functional_ dependencies have nothing to do with
>> us as maintainers. Another chaos preventing rule we abide by is; thou
>> shalt not apply patches belonging to other maintainer's subsystems
>> without the appropriate Ack-by and a subsequent "you may take this
>> though your tree" and/or "please send me an immutable pull-request".
> So you want the series to be merged in two parts via two different
> trees where neither can be tested? That sounds crazy to me.
>
Yes, that's what we want, and that's how people work usually.
I will repeat what Lee was saying, what we have to ensure as maintainer
is that our tree is building.
We will be able to test it with linux-next.
Regards,
Maxime
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WARNING: multiple messages have this Message-ID (diff)
From: Maxime Coquelin <maxime.coquelin@st.com>
To: Herbert Xu <herbert@gondor.apana.org.au>,
Lee Jones <lee.jones@linaro.org>
Cc: "devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
Peter Korsgaard <peter@korsgaard.com>,
"kernel@stlinux.com" <kernel@stlinux.com>,
Kieran Bingham <kieranbingham@gmail.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
<linux-crypto@vger.kernel.org>,
Fabio Estevam <festevam@gmail.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [STLinux Kernel] [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP
Date: Wed, 30 Sep 2015 16:49:55 +0200 [thread overview]
Message-ID: <560BF693.2090405@st.com> (raw)
In-Reply-To: <20150930142812.GA19039@gondor.apana.org.au>
On 09/30/2015 04:28 PM, Herbert Xu wrote:
> On Wed, Sep 30, 2015 at 03:15:39PM +0100, Lee Jones wrote:
>>> I prefer not to merge patches that cannot be tested. Without
>>> the DT bits in patch 6 the other five patches are useless. So
>>> I think patch 6 should be applied together with the other five
>>> which add the driver.
>> That's crazy talk. If all subsystem maintainers abide by this rule
>> there would be chaos. We'd either need to send pull-requests to each
>> other for every set which crossed a subsystems boundary, or 1000's of
>> merge conflicts would ensue at merge time.
>>
>> The (sensible) rule we normally stick to is; as long as there isn't
>> a _build_ dependency, then the patches should filter though their
>> respective trees; _functional_ dependencies have nothing to do with
>> us as maintainers. Another chaos preventing rule we abide by is; thou
>> shalt not apply patches belonging to other maintainer's subsystems
>> without the appropriate Ack-by and a subsequent "you may take this
>> though your tree" and/or "please send me an immutable pull-request".
> So you want the series to be merged in two parts via two different
> trees where neither can be tested? That sounds crazy to me.
>
Yes, that's what we want, and that's how people work usually.
I will repeat what Lee was saying, what we have to ensure as maintainer
is that our tree is building.
We will be able to test it with linux-next.
Regards,
Maxime
next prev parent reply other threads:[~2015-09-30 14:49 UTC|newest]
Thread overview: 80+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-17 13:45 [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP Lee Jones
2015-09-17 13:45 ` Lee Jones
2015-09-17 13:45 ` [PATCH v2 1/7] Documentation: hw_random: Fix device node name reference /dev/hw_random => /dev/hwrng Lee Jones
2015-09-17 13:45 ` Lee Jones
2015-09-17 13:45 ` Lee Jones
[not found] ` <1442497557-9271-2-git-send-email-lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-09-18 10:18 ` Kieran Bingham
2015-09-18 10:18 ` Kieran Bingham
2015-09-18 10:18 ` Kieran Bingham
2015-09-17 13:45 ` [PATCH v2 2/7] hwrng: Kconfig: " Lee Jones
2015-09-17 13:45 ` Lee Jones
2015-09-18 10:19 ` Kieran Bingham
2015-09-18 10:19 ` Kieran Bingham
2015-09-17 13:45 ` [PATCH v2 3/7] hwrng: core: Simplify RNG switching from sysfs Lee Jones
2015-09-17 13:45 ` Lee Jones
2015-09-17 13:45 ` Lee Jones
2015-09-17 14:08 ` Peter Korsgaard
2015-09-17 14:08 ` Peter Korsgaard
[not found] ` <1442497557-9271-1-git-send-email-lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-09-17 13:45 ` [PATCH v2 4/7] hwrng: st: Provide DT bindings for ST's Random Number Generator Lee Jones
2015-09-17 13:45 ` Lee Jones
2015-09-17 13:45 ` Lee Jones
[not found] ` <1442497557-9271-5-git-send-email-lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
2015-09-18 16:21 ` Stephen Boyd
2015-09-18 16:21 ` Stephen Boyd
2015-09-18 16:21 ` Stephen Boyd
2015-09-18 16:23 ` Lee Jones
2015-09-18 16:23 ` Lee Jones
2015-09-18 14:07 ` [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP Herbert Xu
2015-09-18 14:07 ` Herbert Xu
2015-09-18 14:07 ` Herbert Xu
2015-09-18 14:53 ` Lee Jones
2015-09-18 14:53 ` Lee Jones
2015-09-18 15:11 ` Herbert Xu
2015-09-18 15:11 ` Herbert Xu
2015-09-18 15:51 ` Lee Jones
2015-09-18 15:51 ` Lee Jones
2015-09-18 23:12 ` Herbert Xu
2015-09-18 23:12 ` Herbert Xu
2015-09-19 9:21 ` Lee Jones
2015-09-19 9:21 ` Lee Jones
2015-09-20 1:23 ` Herbert Xu
2015-09-20 1:23 ` Herbert Xu
2015-09-20 4:39 ` Lee Jones
2015-09-20 4:39 ` Lee Jones
2015-09-29 14:29 ` Lee Jones
2015-09-29 14:29 ` Lee Jones
2015-09-30 13:47 ` Herbert Xu
2015-09-30 13:47 ` Herbert Xu
2015-09-30 14:15 ` Lee Jones
2015-09-30 14:15 ` Lee Jones
2015-09-30 14:28 ` Herbert Xu
2015-09-30 14:28 ` Herbert Xu
[not found] ` <20150930142812.GA19039-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
2015-09-30 14:49 ` Maxime Coquelin [this message]
2015-09-30 14:49 ` [STLinux Kernel] " Maxime Coquelin
2015-09-30 14:49 ` Maxime Coquelin
2015-09-30 14:49 ` Maxime Coquelin
2015-09-30 14:50 ` Lee Jones
2015-09-30 14:50 ` Lee Jones
2015-09-17 13:45 ` [PATCH v2 5/7] hwrng: st: Add support for ST's HW Random Number Generator Lee Jones
2015-09-17 13:45 ` Lee Jones
2015-09-18 10:44 ` Kieran Bingham
2015-09-18 10:44 ` Kieran Bingham
2015-10-05 10:44 ` Daniel Thompson
2015-10-05 10:44 ` Daniel Thompson
2015-10-05 12:11 ` Lee Jones
2015-10-05 12:11 ` Lee Jones
2015-10-05 12:54 ` Daniel Thompson
2015-10-05 12:54 ` Daniel Thompson
2015-10-05 14:52 ` Lee Jones
2015-10-05 14:52 ` Lee Jones
2015-10-05 14:52 ` Lee Jones
2015-09-17 13:45 ` [PATCH v2 6/7] ARM: STi: STiH407: Enable the 2 HW Random Number Generators for STiH4{07,10} Lee Jones
2015-09-17 13:45 ` [PATCH v2 6/7] ARM: STi: STiH407: Enable the 2 HW Random Number Generators for STiH4{07, 10} Lee Jones
2015-10-01 10:57 ` [STLinux Kernel] " Maxime Coquelin
2015-10-01 10:57 ` Maxime Coquelin
2015-10-01 10:57 ` Maxime Coquelin
2015-09-17 13:45 ` [PATCH v2 7/7] MAINTAINERS: Add ST's Random Number Generator to the ST entry Lee Jones
2015-09-17 13:45 ` Lee Jones
2015-09-29 9:20 ` [STLinux Kernel] [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP Peter Griffin
2015-09-29 9:20 ` Peter Griffin
2015-09-29 10:42 ` Lee Jones
2015-09-29 10:42 ` Lee Jones
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=560BF693.2090405@st.com \
--to=maxime.coquelin-qxv4g6hh51o@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=festevam-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org \
--cc=kernel-F5mvAk5X5gdBDgjK7y7TUQ@public.gmane.org \
--cc=kieranbingham-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=lee.jones-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
--cc=linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org \
--cc=linux-crypto-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=peter-+2lRwdCCLRT2eFz/2MeuCQ@public.gmane.org \
--cc=torvalds-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.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 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.