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

Groups > linux.kernel > #1227055 > unrolled thread

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

Back to article view | Back to linux.kernel

Contents

  [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP Lee Jones <lee.jones@linaro.org> - 2015-09-17 15:50 +0200
    Re: [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP Herbert Xu <herbert@gondor.apana.org.au> - 2015-09-18 16:10 +0200
      Re: [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP Lee Jones <lee.jones@linaro.org> - 2015-09-18 17:00 +0200
        Re: [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP Herbert Xu <herbert@gondor.apana.org.au> - 2015-09-18 17:20 +0200
          Re: [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP Lee Jones <lee.jones@linaro.org> - 2015-09-18 18:00 +0200
            Re: [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP Herbert Xu <herbert@gondor.apana.org.au> - 2015-09-19 01:20 +0200
              Re: [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP Lee Jones <lee.jones@linaro.org> - 2015-09-19 11:30 +0200
                Re: [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP Herbert Xu <herbert@gondor.apana.org.au> - 2015-09-20 03:30 +0200
                  Re: [PATCH v2 0/7] hwrng: Add support for STMicroelectronics' RNG IP Lee Jones <lee.jones@linaro.org> - 2015-09-20 06:40 +0200

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

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

The main aim of this set is to allow users to access ST's hardware
random number generator.  It's a simple device, which only requires
a simple driver.

We're also taking the liberty to update some out of date HWRNG
documentation and making the sysfs interface a little easier to
use by ignoring any '\n' which may have been inadvertently passed.

Lee Jones (7):
  Documentation: hw_random: Fix device node name reference
    /dev/hw_random => /dev/hwrng
  hwrng: Kconfig: Fix device node name reference /dev/hw_random =>
    /dev/hwrng
  hwrng: core: Simplify RNG switching from sysfs
  hwrng: st: Provide DT bindings for ST's Random Number Generator
  hwrng: st: Add support for ST's HW Random Number Generator
  ARM: STi: STiH407: Enable the 2 HW Random Number Generators for
    STiH4{07,10}
  MAINTAINERS: Add ST's Random Number Generator to the ST entry

 Documentation/devicetree/bindings/rng/st,rng.txt |  15 +++
 Documentation/hw_random.txt                      |   8 +-
 MAINTAINERS                                      |   1 +
 arch/arm/boot/dts/stih407-family.dtsi            |  14 +++
 drivers/char/hw_random/Kconfig                   |  12 +-
 drivers/char/hw_random/Makefile                  |   1 +
 drivers/char/hw_random/core.c                    |   2 +-
 drivers/char/hw_random/st-rng.c                  | 144 +++++++++++++++++++++++
 8 files changed, 191 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/rng/st,rng.txt
 create mode 100644 drivers/char/hw_random/st-rng.c

-- 
1.9.1

--
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]

#1227895

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.
-- 
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]

#1227958

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?

> --
> 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

-- 
Lee Jones
Linaro ST 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]

#1228029

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.

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]

#1228102

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.

-- 
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]

#1228341

On Fri, Sep 18, 2015 at 04:51:12PM +0100, Lee Jones wrote:
>
> 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.

In future please don't send me patches that you don't want me to
merge in the series.

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]

#1228411

On Sat, 19 Sep 2015, Herbert Xu wrote:
> On Fri, Sep 18, 2015 at 04:51:12PM +0100, Lee Jones wrote:
> >
> > 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.
> 
> In future please don't send me patches that you don't want me to
> merge in the series.

That's not how it works.  It's helpful, more often than not, to submit
the entire set to each maintainer concerned so they can keep up with
the general conversation.  By only sending specific patches to
maintainers you essentially blinker them to the bigger picture.

As a maintainer you should _know_ that you can't apply patches from
other subsystems without appropriate Acks.  I'm sure you'd take
exception to another maintainer who started accepting patches for
subsystems you are responsible for.  This works both ways.

-- 
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]

#1228808

On Sat, Sep 19, 2015 at 10:21:45AM +0100, Lee Jones wrote:
>
> That's not how it works.  It's helpful, more often than not, to submit
> the entire set to each maintainer concerned so they can keep up with
> the general conversation.  By only sending specific patches to
> maintainers you essentially blinker them to the bigger picture.
> 
> As a maintainer you should _know_ that you can't apply patches from
> other subsystems without appropriate Acks.  I'm sure you'd take
> exception to another maintainer who started accepting patches for
> subsystems you are responsible for.  This works both ways.

No you are mistaken.  You should only put patches which have
dependencies on each other in a series.  If the patches can be
applied independently of each other there is no need to have
them in a single series.

Obviously if they can go into different trees then they cannot
have dependencies.

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]

#1228838

On Sun, 20 Sep 2015, Herbert Xu wrote:

> On Sat, Sep 19, 2015 at 10:21:45AM +0100, Lee Jones wrote:
> >
> > That's not how it works.  It's helpful, more often than not, to submit
> > the entire set to each maintainer concerned so they can keep up with
> > the general conversation.  By only sending specific patches to
> > maintainers you essentially blinker them to the bigger picture.
> > 
> > As a maintainer you should _know_ that you can't apply patches from
> > other subsystems without appropriate Acks.  I'm sure you'd take
> > exception to another maintainer who started accepting patches for
> > subsystems you are responsible for.  This works both ways.
> 
> No you are mistaken.  You should only put patches which have
> dependencies on each other in a series.  If the patches can be
> applied independently of each other there is no need to have
> them in a single series.

That's just not true.  I've explained why it's important for everyone
involved to see the bigger picture.  Let me use this set in an
example.  The patches can (and should) be applied separately, but they
are heavily entwined.  Let's say I only sent the ARM patch to Maxime
(the STi Maintainer) and only sent you the driver and the binding
document.  There's a chance Maxime could apply the DTS changes prior
to a proper review of the bindings.  Granted, one way round this would
be to place the DTS changes into a holding-pen until the binding has
been accepted, but this method is highly impractical and puts
unnecessary burden on the contributor.

There are 1000's of examples where all parties need to see reviews on
other, related but not dependant, parts of a set.  For many of the
sets I review it's critical for me what else is going on in related
diffs.  I guess for the subsystems you maintain it's less of an issue,
but still, it _is_ how people tend to submit code and there is no good
reason for you to dictate otherwise.

> Obviously if they can go into different trees then they cannot
> have dependencies.
> 
> Cheers,

-- 
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