ARM: SoC: add a new platform, UniPhier (arch/arm/mach-uniphier)

This is an initial series for supporting Socionext UniPhier SoCs, based on ARM Cortex-A9, mainly used for digital TVs, video recorders, etc.

Masahiro Yamada (4):
ARM: UniPhier: add basic support for UniPhier architecture
ARM: multi_v7_defconfig: enable UniPhier SoC family
ARM: dts: UniPhier: add support for UniPhier SoCs and boards
MAINTAINERS: add myself as ARM/UniPhier maintainer

Quoted 4 lines

This is an initial series for supporting Socionext UniPhier SoCs, based on ARM Cortex-A9, mainly used for digital TVs, video recorders, etc.

Quoted 5 lines

Masahiro Yamada (4):
ARM: UniPhier: add basic support for UniPhier architecture
ARM: multi_v7_defconfig: enable UniPhier SoC family
ARM: dts: UniPhier: add support for UniPhier SoCs and boards
MAINTAINERS: add myself as ARM/UniPhier maintainer

Applied all four patches, to the next/soc, next/defconfig, next/dt and next/soc branches respectively.

Welcome as our latest new maintainer. In the future, please send any follow-up patches for the architecture specific code to arm at kernel.org in addition to the normal recipients, once you consider them ready to be applied.

2015-05-13 0:00 GMT+09:00 Arnd Bergmann <[email protected]>:

Quoted 5 lines · On Friday 08 May 2015 13:07:10 Masahiro Yamada wrote:

Welcome as our latest new maintainer. In the future, please send any follow-up patches for the architecture specific code to arm at kernel.org in addition to the normal recipients, once you consider them ready to be applied.

Please teach me a little more because I am not experienced enough in this community.

I checked MAINTAINERS, but I could not find arm at kernel.org. Is it documented somewhere?

I found ARM SUB-ARCHITECTURES entry in that file, but it does not mention the responsible individuals.
(I assume, you and Olof are the ones.)

I have one more question.

Are you receiving pull requests from each sub-arch maintainer? Or should every patch be submitted to arm at kernel.org and applied by you (or other ARM-SoC maintainers)?

I have not earned enough reputations in this ML, so I know it is too early for me to handle pull-reqs.

I understand the general development process of Linux, but the maintainership of the ARM-SoC subsystem looks more hierarchized, so I just want to know its development process correctly.

For sending pull requests, it would be good to have a gpg key that is signed by other well-known kernel developers. If you have such a key, you can also request a kernel.org account to host a git tree there, or you can host a git tree somewhere on your company's domain. A public hosting service like github is not as good for us, but we can deal with it when you are still ramping up your infrastructure. Let me know if you need help finding kernel developers to sign your key.

Hi Arnd,

Quoted 7 lines · Arnd Bergmann

For sending pull requests, it would be good to have a gpg key that is signed by other well-known kernel developers. If you have such a key, you can also request a kernel.org account to host a git tree there, or you can host a git tree somewhere on your company's domain. A public hosting service like github is not as good for us, but we can deal with it when you are still ramping up your infrastructure. Let me know if you need help finding kernel developers to sign your key.

Is a pull request from a kernel.org repo trusted more than the key itself? In other words, if I sign my pull request with a trusted key, why would the git repo location make any difference?

Quoted 15 lines

2015-05-13 0:00 GMT+09:00 Arnd Bergmann <[email protected]>:

Quoted 5 lines · On Friday 08 May 2015 13:07:10 Masahiro Yamada wrote:

Welcome as our latest new maintainer. In the future, please send any follow-up patches for the architecture specific code to arm at kernel.org in addition to the normal recipients, once you consider them ready to be applied.

Please teach me a little more because I am not experienced enough in this community.

I checked MAINTAINERS, but I could not find arm at kernel.org. Is it documented somewhere?

Quoted 4 lines

I found ARM SUB-ARCHITECTURES entry in that file, but it does not mention the responsible individuals.
(I assume, you and Olof are the ones.)

We normally only take patches from subarch maintainers that know who we are and how it works, but we don't want to be Cc'd on every single patch, so we don't have an entry in MAINTAINERS directly.

Quoted 6 lines

I have one more question.

Are you receiving pull requests from each sub-arch maintainer? Or should every patch be submitted to arm at kernel.org and applied by you (or other ARM-SoC maintainers)?

Quoted 6 lines

I have not earned enough reputations in this ML, so I know it is too early for me to handle pull-reqs.

I understand the general development process of Linux, but the maintainership of the ARM-SoC subsystem looks more hierarchized, so I just want to know its development process correctly.

No worries, if you are unsure you can always ask us on the mailing list or on the #armlinux channel on irc.freenode.net.

If you have more than a few patches at once, we'd always appreciate a pull request, for a couple of patches, emails to arm at kernel.org plus linux-arm-kernel are fine as well.

When you do pull requests, please split them up according to larger topics, e.g. send dts changes separately from code changes, and separate bug fixes, cleanups and new feature support.

Often when you add a new driver, that will require sending the driver code to a subsystem maintainer, and the dts changes to us. If everything goes well, your DT bindings are both forward and backward compatible, so they can get merged independently. If you ever have interdependencies between them, talk to us first so we can find a solution.

For sending pull requests, it would be good to have a gpg key that is signed by other well-known kernel developers. If you have such a key, you can also request a kernel.org account to host a git tree there, or you can host a git tree somewhere on your company's domain. A public hosting service like github is not as good for us, but we can deal with it when you are still ramping up your infrastructure. Let me know if you need help finding kernel developers to sign your key.

Quoted 12 lines

2015-05-13 0:00 GMT+09:00 Arnd Bergmann <[email protected]>:

Quoted 5 lines · On Friday 08 May 2015 13:07:10 Masahiro Yamada wrote:

Welcome as our latest new maintainer. In the future, please send any follow-up patches for the architecture specific code to arm at kernel.org in addition to the normal recipients, once you consider them ready to be applied.

Please teach me a little more because I am not experienced enough in this community.

Quoted 7 lines

I checked MAINTAINERS, but I could not find arm at kernel.org. Is it documented somewhere?

I found ARM SUB-ARCHITECTURES entry in that file, but it does not mention the responsible individuals.
(I assume, you and Olof are the ones.)

We normally only take patches from subarch maintainers that know who we are and how it works, but we don't want to be Cc'd on every single patch, so we don't have an entry in MAINTAINERS directly.

Quoted 6 lines

I have one more question.

Are you receiving pull requests from each sub-arch maintainer? Or should every patch be submitted to arm at kernel.org and applied by you (or other ARM-SoC maintainers)?

Quoted 6 lines

I have not earned enough reputations in this ML, so I know it is too early for me to handle pull-reqs.

I understand the general development process of Linux, but the maintainership of the ARM-SoC subsystem looks more hierarchized, so I just want to know its development process correctly.

No worries, if you are unsure you can always ask us on the mailing list or on the #armlinux channel on irc.freenode.net.

If you have more than a few patches at once, we'd always appreciate a pull request, for a couple of patches, emails to arm at kernel.org plus linux-arm-kernel are fine as well.

When you do pull requests, please split them up according to larger topics, e.g. send dts changes separately from code changes, and separate bug fixes, cleanups and new feature support.

Often when you add a new driver, that will require sending the driver code to a subsystem maintainer, and the dts changes to us. If everything goes well, your DT bindings are both forward and backward compatible, so they can get merged independently. If you ever have interdependencies between them, talk to us first so we can find a solution.

For sending pull requests, it would be good to have a gpg key that is signed by other well-known kernel developers. If you have such a key, you can also request a kernel.org account to host a git tree there, or you can host a git tree somewhere on your company's domain. A public hosting service like github is not as good for us, but we can deal with it when you are still ramping up your infrastructure. Let me know if you need help finding kernel developers to sign your key.

Arnd

2015-05-13 16:48 GMT+09:00 Arnd Bergmann <[email protected]>:

Quoted 19 lines · On Wednesday 13 May 2015 16:00:21 Masahiro Yamada wrote:

No worries, if you are unsure you can always ask us on the mailing list or on the #armlinux channel on irc.freenode.net.

If you have more than a few patches at once, we'd always appreciate a pull request, for a couple of patches, emails to arm at kernel.org plus linux-arm-kernel are fine as well.

When you do pull requests, please split them up according to larger topics, e.g. send dts changes separately from code changes, and separate bug fixes, cleanups and new feature support.

Often when you add a new driver, that will require sending the driver code to a subsystem maintainer, and the dts changes to us. If everything goes well, your DT bindings are both forward and backward compatible, so they can get merged independently. If you ever have interdependencies between them, talk to us first so we can find a solution.

Quoted 7 lines

For sending pull requests, it would be good to have a gpg key that is signed by other well-known kernel developers. If you have such a key, you can also request a kernel.org account to host a git tree there, or you can host a git tree somewhere on your company's domain. A public hosting service like github is not as good for us, but we can deal with it when you are still ramping up your infrastructure. Let me know if you need help finding kernel developers to sign your key.

About 7 months have passed since I became a sub-arch maintainer (ARM/UniPhier), and I am hoping now I deserve to have the gpg key thing you mentioned.

Could you help me get a key and a kernel.org account to host a git tree?

It would make it easier to get SoC-specific things in without loading you and Olof.

Quoted 29 lines

2015-05-13 16:48 GMT+09:00 Arnd Bergmann <[email protected]>:

Quoted 19 lines · On Wednesday 13 May 2015 16:00:21 Masahiro Yamada wrote:

No worries, if you are unsure you can always ask us on the mailing list or on the #armlinux channel on irc.freenode.net.

If you have more than a few patches at once, we'd always appreciate a pull request, for a couple of patches, emails to [email protected] plus linux-arm-kernel are fine as well.

When you do pull requests, please split them up according to larger topics, e.g. send dts changes separately from code changes, and separate bug fixes, cleanups and new feature support.

Often when you add a new driver, that will require sending the driver code to a subsystem maintainer, and the dts changes to us. If everything goes well, your DT bindings are both forward and backward compatible, so they can get merged independently. If you ever have interdependencies between them, talk to us first so we can find a solution.

Quoted 7 lines

For sending pull requests, it would be good to have a gpg key that is signed by other well-known kernel developers. If you have such a key, you can also request a kernel.org account to host a git tree there, or you can host a git tree somewhere on your company's domain. A public hosting service like github is not as good for us, but we can deal with it when you are still ramping up your infrastructure. Let me know if you need help finding kernel developers to sign your key.

Quoted 7 lines

About 7 months have passed since I became a sub-arch maintainer (ARM/UniPhier), and I am hoping now I deserve to have the gpg key thing you mentioned.

Could you help me get a key and a kernel.org account to host a git tree?

It would make it easier to get SoC-specific things in without loading you and Olof.

Getting the kernel.org account should be straightforward once you have a signed gpg key, see the description in https://www.kernel.org/category/faq.html

If you don't have a gpg key yet, please generate one with 4096 bits keylength now. It's good to get as many signatures as possible from people that already have signatures by other kernel contributors. The complication is that you anyone who signs your key needs to verify your identity, otherwise the signature method would not be helpful.

I have added three people to Cc that might be able you here: I understand that you live in Osaka, so Simon Horman would be physically the closest in Kobe. Takahiro Akashi works at Socionext in Tokyo, and I think you already know Akira Tsukamoto.

If you happen to be in the same place with one of them, or maybe they have already signed the key of someone close by.

Arnd

From this development cycle (for v4.9-rc1),

Quoted 3 lines

Quoted 3 lines

When you do pull requests, please split them up according to larger topics, e.g. send dts changes separately from code changes, and separate bug fixes, cleanups and new feature support.

2016-01-18 22:49 GMT+09:00 Arnd Bergmann <[email protected]>:

Quoted 1 line · On Monday 18 January 2016 19:54:08 Masahiro Yamada wrote:

I collected a couple of GPG signatures and
finally, I managed to host my git tree in the kernel.org site.

From this development cycle (for v4.9-rc1),
I'd like to send a few pull requests instead of
asking you to pick up separate patches.

If it is OK with you,
could you apply the following patch?
https://patchwork.kernel.org/patch/9286311/

If it is applied, I will regard it as your acknowledgment for my pull requests.

Could you teach me some good practice about PRs?

Quoted 3 lines

Quoted 3 lines

Quoted 3 lines

When you do pull requests, please split them up according to larger topics, e.g. send dts changes separately from code changes, and separate bug fixes, cleanups and new feature support.

I will make sure to do this.
Mostly, I will send pull requests for device tree updates for UniPhier SoC family.

Also, I will split them into ARM32 DTS and ARM64 DTS as others do.

What else?

- On which tag should I base my PRs? -rc1 or -rc2?
Or do you want it based on some branch?

- Do you require a tag with GPG signature for accepting a pull-request? (Greg KH and I signed GPG keys with each other.
Perhaps, are we connected with web of trust?)