Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1235155 > unrolled thread

Re: [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP Lee Jones <lee.jones@linaro.org> - 2015-09-29 16:30 +0200
    Re: [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP Herbert Xu <herbert@gondor.apana.org.au> - 2015-09-30 15:50 +0200
      Re: [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP Lee Jones <lee.jones@linaro.org> - 2015-09-30 16:20 +0200
        Re: [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP Herbert Xu <herbert@gondor.apana.org.au> - 2015-09-30 16:30 +0200
          Re: [STLinux Kernel] [PATCH v2 0/7] hwrng: Add support for  STMicroelectronics' RNG IP Maxime Coquelin <maxime.coquelin@st.com> - 2015-09-30 17:00 +0200
          Re: [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP Lee Jones <lee.jones@linaro.org> - 2015-09-30 17:00 +0200

#1235155 — Re: [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP

On Fri, 18 Sep 2015, Lee Jones wrote:
> On Fri, 18 Sep 2015, Herbert Xu wrote:
> > On Fri, Sep 18, 2015 at 03:53:50PM +0100, Lee Jones wrote:
> > > On 18 September 2015 at 15:07, Herbert Xu <herbert@gondor.apana.org.au> wrote:
> > > > On Thu, Sep 17, 2015 at 02:45:50PM +0100, Lee Jones wrote:
> > > >> v1 => v2:
> > > >>  - New patch: Also fixing /dev/hw_random => /dev/hwrng in Kconfig
> > > >>  - Fix 2099 => 2009 typo in commit log
> > > >>  - Fix 'number of random numbers sourced' return value
> > > >>  - Treat devm_clk_get()'s return value correctly
> > > >>  - Check return value of clk_prepare_enable()
> > > >>  - Use sysfs_streq() instead of manually stripping '\n' from sysfs
> > > >
> > > > All applied.  Thanks.
> > > 
> > > Just to be clear.  Which patches have you applied?
> > 
> > All of your patches.
> 
> I think it's okay for you to take all but patch 6.
> 
> Patch 6 is an ARM patch and needs to go into ARM SoC via
> STMicroelectronics STi tree.

Hi Herbert,

I see that your tree is 8 days old, so this may have been resolved
already, but would you be kind enough to ensure you remove the 6th
(ARM) patch from your repo please?  I wouldn't want it to cause
conflicts and for Maxime and yourself to get shouted at by Linus.

Much appreciated.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1236303

On Tue, Sep 29, 2015 at 03:29:32PM +0100, Lee Jones wrote:
> 
> I see that your tree is 8 days old, so this may have been resolved
> already, but would you be kind enough to ensure you remove the 6th
> (ARM) patch from your repo please?  I wouldn't want it to cause
> conflicts and for Maxime and yourself to get shouted at by Linus.

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.

Of course if Linus wants me to revert patch 6 in case of any
potential conflicts with Maxime's tree I'll do that.  Linus?

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1236364

On Wed, 30 Sep 2015, Herbert Xu wrote:
> On Tue, Sep 29, 2015 at 03:29:32PM +0100, Lee Jones wrote:
> > 
> > I see that your tree is 8 days old, so this may have been resolved
> > already, but would you be kind enough to ensure you remove the 6th
> > (ARM) patch from your repo please?  I wouldn't want it to cause
> > conflicts and for Maxime and yourself to get shouted at by Linus.
> 
> 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".

> Of course if Linus wants me to revert patch 6 in case of any
> potential conflicts with Maxime's tree I'll do that.  Linus?

Why bother Linus?  The whole purpose of this is to _not_ pi$$ him
off.  This stuff is common sense.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1236382

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.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1236420 — Re: [STLinux Kernel] [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP

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 linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1236423

On Wed, 30 Sep 2015, 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.

Who is going to checkout the HWRNG tree and run-test it on it's own on
all of the required hardware?  No one.  Agreed, subsystem trees should
be bisectably (new word? :D) buildable as per my first rule above, but
that's it.  Per-subsystem repos are not designed to be tested for
full-functionality orthogonally, that's the point of Stephen's -next
tree.

Please take my other points into consideration too.  The kernel would
be unmainatinable if we all stuck to your rule.  No-one else has that
rule, and for good reason.

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web