[PATCH 0/2] Resume maintenance & development of arch/sh

[PATCH 0/2] Resume maintenance & development of arch/sh

[Rich Felker]

Yoshinori Sato and I would like to take over as co-maintainers for the
orphaned sh (SuperH) arch. Sato-san is the current H8/300 arch
maintainer and introduced the original sh2 support in Linux. I am
working on the software side of the J-Core project reviving the sh
arch as open hardware (see https://lwn.net/Articles/647636/), and am
also the maintainer of musl libc.

We plan to transition arch/sh from legacy board support files to
device tree, clean up infrastructure that was previously arch-specific
but which has since been replaced with arch-generic solutions
elsewhere in the kernel, and add support for new hardware,
specifically the J2 and future J-Core processors and SOC devices.

Rich

[PATCH 1/2] MAINTAINERS: return arch/sh to maintained state, with new maintainers

[Rich Felker]

From: Rich Felker <dalias@libc.org>

Add Yoshinori Sato and Rich Felker as maintainers for arch/sh
(SUPERH).

Signed-off-by: Rich Felker <dalias@libc.org>
Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
Acked-by: D. Jeff Dionne <jeff@uClinux.org>
Acked-by: Rob Landley <rob@landley.net>

---

diff --git a/MAINTAINERS b/MAINTAINERS
index 9bff63c..55e48b1 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -10274,9 +10274,11 @@ S:	Maintained
 F:	drivers/net/ethernet/dlink/sundance.c
 
 SUPERH
+M:	Yoshinori Sato <ysato@users.sourceforge.jp>
+M:	Rich Felker <dalias@libc.org>
 L:	linux-sh@vger.kernel.org
 Q:	http://patchwork.kernel.org/project/linux-sh/list/
-S:	Orphan
+S:	Maintained
 F:	Documentation/sh/
 F:	arch/sh/
 F:	drivers/sh/

Re: [PATCH 1/2] MAINTAINERS: return arch/sh to maintained state, with new maintainers

[Peter Zijlstra]

On Thu, Jan 07, 2016 at 11:39:59PM -0500, Rich Felker wrote:
> From: Rich Felker <dalias@libc.org>
> 
> Add Yoshinori Sato and Rich Felker as maintainers for arch/sh
> (SUPERH).
> 
> Signed-off-by: Rich Felker <dalias@libc.org>
> Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
> Acked-by: D. Jeff Dionne <jeff@uClinux.org>
> Acked-by: Rob Landley <rob@landley.net>

A much appreciated move,

Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>

> ---
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9bff63c..55e48b1 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10274,9 +10274,11 @@ S:	Maintained
>  F:	drivers/net/ethernet/dlink/sundance.c
>  
>  SUPERH
> +M:	Yoshinori Sato <ysato@users.sourceforge.jp>
> +M:	Rich Felker <dalias@libc.org>
>  L:	linux-sh@vger.kernel.org
>  Q:	http://patchwork.kernel.org/project/linux-sh/list/
> -S:	Orphan
> +S:	Maintained
>  F:	Documentation/sh/
>  F:	arch/sh/
>  F:	drivers/sh/

Re: [PATCH 1/2] MAINTAINERS: return arch/sh to maintained state, with new maintainers

[Simon Horman]

On Mon, Jan 11, 2016 at 06:53:07PM +0100, Peter Zijlstra wrote:
> On Thu, Jan 07, 2016 at 11:39:59PM -0500, Rich Felker wrote:
> > From: Rich Felker <dalias@libc.org>
> > 
> > Add Yoshinori Sato and Rich Felker as maintainers for arch/sh
> > (SUPERH).
> > 
> > Signed-off-by: Rich Felker <dalias@libc.org>
> > Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
> > Acked-by: D. Jeff Dionne <jeff@uClinux.org>
> > Acked-by: Rob Landley <rob@landley.net>
> 
> A much appreciated move,
> 
> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>

Likewise,

Acked-by: Simon Horman <horms+renesas@verge.net.au>

> > ---
> > 
> > diff --git a/MAINTAINERS b/MAINTAINERS
> > index 9bff63c..55e48b1 100644
> > --- a/MAINTAINERS
> > +++ b/MAINTAINERS
> > @@ -10274,9 +10274,11 @@ S:	Maintained
> >  F:	drivers/net/ethernet/dlink/sundance.c
> >  
> >  SUPERH
> > +M:	Yoshinori Sato <ysato@users.sourceforge.jp>
> > +M:	Rich Felker <dalias@libc.org>
> >  L:	linux-sh@vger.kernel.org
> >  Q:	http://patchwork.kernel.org/project/linux-sh/list/
> > -S:	Orphan
> > +S:	Maintained
> >  F:	Documentation/sh/
> >  F:	arch/sh/
> >  F:	drivers/sh/
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sh" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH 1/2] MAINTAINERS: return arch/sh to maintained state, with new maintainers

[Rich Felker]

On Wed, Jan 13, 2016 at 10:40:46AM +0900, Simon Horman wrote:
> On Mon, Jan 11, 2016 at 06:53:07PM +0100, Peter Zijlstra wrote:
> > On Thu, Jan 07, 2016 at 11:39:59PM -0500, Rich Felker wrote:
> > > From: Rich Felker <dalias@libc.org>
> > > 
> > > Add Yoshinori Sato and Rich Felker as maintainers for arch/sh
> > > (SUPERH).
> > > 
> > > Signed-off-by: Rich Felker <dalias@libc.org>
> > > Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
> > > Acked-by: D. Jeff Dionne <jeff@uClinux.org>
> > > Acked-by: Rob Landley <rob@landley.net>
> > 
> > A much appreciated move,
> > 
> > Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> 
> Likewise,
> 
> Acked-by: Simon Horman <horms+renesas@verge.net.au>

While patch 2/2 still seems to need discussion and resolution, I don't
think this part (1/2, adding us as maintainers) is controversial. Can
it be committed now? Geert? Andrew?

Rich

Re: [PATCH 1/2] MAINTAINERS: return arch/sh to maintained state, with new maintainers

[Geert Uytterhoeven]

Hi Rich, Sato-san,

On Fri, Jan 15, 2016 at 1:52 AM, Rich Felker <dalias@libc.org> wrote:
> On Wed, Jan 13, 2016 at 10:40:46AM +0900, Simon Horman wrote:
>> On Mon, Jan 11, 2016 at 06:53:07PM +0100, Peter Zijlstra wrote:
>> > On Thu, Jan 07, 2016 at 11:39:59PM -0500, Rich Felker wrote:
>> > > From: Rich Felker <dalias@libc.org>
>> > >
>> > > Add Yoshinori Sato and Rich Felker as maintainers for arch/sh
>> > > (SUPERH).
>> > >
>> > > Signed-off-by: Rich Felker <dalias@libc.org>
>> > > Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
>> > > Acked-by: D. Jeff Dionne <jeff@uClinux.org>
>> > > Acked-by: Rob Landley <rob@landley.net>
>> >
>> > A much appreciated move,
>> >
>> > Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
>>
>> Likewise,
>>
>> Acked-by: Simon Horman <horms+renesas@verge.net.au>

Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>

> While patch 2/2 still seems to need discussion and resolution, I don't
> think this part (1/2, adding us as maintainers) is controversial. Can
> it be committed now? Geert? Andrew?

I think it should go in either through Andrew, or through yourself, depending
on whether you already have other stuff ready for this merge window, and have
a git repo to pull from.

Do you have a git repository to ask Linus to pull from, and to provide a branch
for linux-next integration testing?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 1/2] MAINTAINERS: return arch/sh to maintained state, with new maintainers

[Rich Felker]

On Fri, Jan 15, 2016 at 10:31:13AM +0100, Geert Uytterhoeven wrote:
> Hi Rich, Sato-san,
> 
> On Fri, Jan 15, 2016 at 1:52 AM, Rich Felker <dalias@libc.org> wrote:
> > On Wed, Jan 13, 2016 at 10:40:46AM +0900, Simon Horman wrote:
> >> On Mon, Jan 11, 2016 at 06:53:07PM +0100, Peter Zijlstra wrote:
> >> > On Thu, Jan 07, 2016 at 11:39:59PM -0500, Rich Felker wrote:
> >> > > From: Rich Felker <dalias@libc.org>
> >> > >
> >> > > Add Yoshinori Sato and Rich Felker as maintainers for arch/sh
> >> > > (SUPERH).
> >> > >
> >> > > Signed-off-by: Rich Felker <dalias@libc.org>
> >> > > Signed-off-by: Yoshinori Sato <ysato@users.sourceforge.jp>
> >> > > Acked-by: D. Jeff Dionne <jeff@uClinux.org>
> >> > > Acked-by: Rob Landley <rob@landley.net>
> >> >
> >> > A much appreciated move,
> >> >
> >> > Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
> >>
> >> Likewise,
> >>
> >> Acked-by: Simon Horman <horms+renesas@verge.net.au>
> 
> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be>

Thanks!

> > While patch 2/2 still seems to need discussion and resolution, I don't
> > think this part (1/2, adding us as maintainers) is controversial. Can
> > it be committed now? Geert? Andrew?
> 
> I think it should go in either through Andrew, or through yourself, depending
> on whether you already have other stuff ready for this merge window, and have
> a git repo to pull from.
> 
> Do you have a git repository to ask Linus to pull from, and to provide a branch
> for linux-next integration testing?

Not quite yet. If it can be done in this merge window, I think it
makes sense for Andrew to do it to make it official that arch/sh isn't
abandoned, and Sato-san and I can have the repo setup well ahead of
the next window. How does that sound?

I'd love it if we could get some of the actual code changes in for
this merge window too but I'm not clear whether there's still time.

Rich

Re: [PATCH 1/2] MAINTAINERS: return arch/sh to maintained state, with new maintainers

[Geert Uytterhoeven]

Hi Rich,

On Sun, Jan 17, 2016 at 3:32 AM, Rich Felker <dalias@libc.org> wrote:
> On Fri, Jan 15, 2016 at 10:31:13AM +0100, Geert Uytterhoeven wrote:
>> On Fri, Jan 15, 2016 at 1:52 AM, Rich Felker <dalias@libc.org> wrote:
>> > On Wed, Jan 13, 2016 at 10:40:46AM +0900, Simon Horman wrote:
>> >> On Mon, Jan 11, 2016 at 06:53:07PM +0100, Peter Zijlstra wrote:
>> >> > On Thu, Jan 07, 2016 at 11:39:59PM -0500, Rich Felker wrote:
>> >> > > From: Rich Felker <dalias@libc.org>
>> >> > >
>> >> > > Add Yoshinori Sato and Rich Felker as maintainers for arch/sh
>> >> > > (SUPERH).

>> > While patch 2/2 still seems to need discussion and resolution, I don't
>> > think this part (1/2, adding us as maintainers) is controversial. Can
>> > it be committed now? Geert? Andrew?
>>
>> I think it should go in either through Andrew, or through yourself, depending
>> on whether you already have other stuff ready for this merge window, and have
>> a git repo to pull from.
>>
>> Do you have a git repository to ask Linus to pull from, and to provide a branch
>> for linux-next integration testing?
>
> Not quite yet. If it can be done in this merge window, I think it
> makes sense for Andrew to do it to make it official that arch/sh isn't
> abandoned, and Sato-san and I can have the repo setup well ahead of
> the next window. How does that sound?

That sounds fine to me.

> I'd love it if we could get some of the actual code changes in for
> this merge window too but I'm not clear whether there's still time.

I don't think there's a reason to hurry.
People can start using your tree as soon as it becomes public.

Thanks!

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[PATCH 2/2] MAINTAINERS: remove linux-sh list from non-arch/sh sections

[Rich Felker]

From: Rich Felker <dalias@libc.org>

Recently the bulk of traffic on the linux-sh list has been unrelated
to arch/sh but instead focused on Renesas hardware for their ARM-based
SoCs. As part of resuming maintenance of arch/sh, remove the linux-sh
list from the MAINTAINERS file sections for these other components so
that new arch/sh development is not drowned out by unrelated
cross-postings.

Signed-off-by: Rich Felker <dalias@libc.org>
Acked-by: D. Jeff Dionne <jeff@uClinux.org>
Acked-by: Rob Landley <rob@landley.net>

---

diff --git a/MAINTAINERS b/MAINTAINERS
index 9bff63c..8f5f953 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1516,9 +1516,7 @@ F:	drivers/media/platform/s5p-jpeg/
 ARM/SHMOBILE ARM ARCHITECTURE
 M:	Simon Horman <horms@verge.net.au>
 M:	Magnus Damm <magnus.damm@gmail.com>
-L:	linux-sh@vger.kernel.org
 W:	http://oss.renesas.com
-Q:	http://patchwork.kernel.org/project/linux-sh/list/
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/horms/renesas.git next
 S:	Supported
 F:	arch/arm/boot/dts/emev2*
@@ -3721,7 +3719,6 @@ F:	Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.txt
 DRM DRIVERS FOR RENESAS
 M:	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
 L:	dri-devel@lists.freedesktop.org
-L:	linux-sh@vger.kernel.org
 T:	git git://people.freedesktop.org/~airlied/linux
 S:	Supported
 F:	drivers/gpu/drm/rcar-du/
@@ -6829,7 +6826,6 @@ F:	drivers/iio/potentiometer/mcp4531.c
 MEDIA DRIVERS FOR RENESAS - VSP1
 M:	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
 L:	linux-media@vger.kernel.org
-L:	linux-sh@vger.kernel.org
 T:	git git://linuxtv.org/media_tree.git
 S:	Supported
 F:	Documentation/devicetree/bindings/media/renesas,vsp1.txt
@@ -8192,7 +8188,6 @@ F:	drivers/pci/host/pci-dra7xx.c
 PCI DRIVER FOR RENESAS R-CAR
 M:	Simon Horman <horms@verge.net.au>
 L:	linux-pci@vger.kernel.org
-L:	linux-sh@vger.kernel.org
 S:	Maintained
 F:	drivers/pci/host/*rcar*
 
@@ -8369,7 +8364,6 @@ F:	drivers/pinctrl/intel/
 
 PIN CONTROLLER - RENESAS
 M:	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
-L:	linux-sh@vger.kernel.org
 S:	Maintained
 F:	drivers/pinctrl/sh-pfc/
 

Re: [PATCH 2/2] MAINTAINERS: remove linux-sh list from non-arch/sh sections

[Simon Horman]

On Thu, Jan 07, 2016 at 11:40:54PM -0500, Rich Felker wrote:
> From: Rich Felker <dalias@libc.org>
> 
> Recently the bulk of traffic on the linux-sh list has been unrelated
> to arch/sh but instead focused on Renesas hardware for their ARM-based
> SoCs. As part of resuming maintenance of arch/sh, remove the linux-sh
> list from the MAINTAINERS file sections for these other components so
> that new arch/sh development is not drowned out by unrelated
> cross-postings.

The use of the linux-sh mailing list has evolved somewhat over time,
from SH related to ARM related. Its name (obviously) has not evolved.

Dropping linux-sh@vger.kernel.org from portions of the MAINTAINERS file as
you suggest would essentially leave the Renesas ARM work without a mailing
list or patchwork instance. Both of which are actively used for that work.

Off-hand I can think of three solutions to this problem:

1. Live with the noise
2. Establish a new list (and possibly patchwork instance) for the SH work.
3. Establish a new list and patchwork instance for the ARM work.

Re: [PATCH 2/2] MAINTAINERS: remove linux-sh list from non-arch/sh sections

[Geert Uytterhoeven]

First, I'd like to welcome the adoption of the arch/sh/ architecture.

On Fri, Jan 8, 2016 at 7:56 AM, Simon Horman <horms@verge.net.au> wrote:
> On Thu, Jan 07, 2016 at 11:40:54PM -0500, Rich Felker wrote:
>> From: Rich Felker <dalias@libc.org>
>>
>> Recently the bulk of traffic on the linux-sh list has been unrelated
>> to arch/sh but instead focused on Renesas hardware for their ARM-based
>> SoCs. As part of resuming maintenance of arch/sh, remove the linux-sh
>> list from the MAINTAINERS file sections for these other components so
>> that new arch/sh development is not drowned out by unrelated
>> cross-postings.
>
> The use of the linux-sh mailing list has evolved somewhat over time,
> from SH related to ARM related. Its name (obviously) has not evolved.

Indeed, following the evolution of the SoC hardware, cfr. below.
It meaning has shifted more to the "Linux Renesas mailing list".

> Dropping linux-sh@vger.kernel.org from portions of the MAINTAINERS file as
> you suggest would essentially leave the Renesas ARM work without a mailing
> list or patchwork instance. Both of which are actively used for that work.
>
> Off-hand I can think of three solutions to this problem:
>
> 1. Live with the noise
> 2. Establish a new list (and possibly patchwork instance) for the SH work.
> 3. Establish a new list and patchwork instance for the ARM work.

Personally, I'd go for option 1.
I would even like to propose H8/300 to join, as they share IP cores, too
(m32r doesn't, AFAIK).

Many old ARM/SH-Mobile SoCs look like SH SoCs with an ARM CPU core bolted on.
Recent Renesas ARM SoCs still share many IP cores with older SH SoCs; most of
them even have a secondary SH4 CPU core. Using the SH4 CPU core could be useful
for doing SH4 work, until J4 becomes mainstream (cfr. old prototype in
http://www.spinics.net/lists/linux-sh/msg07188.html).
Probably the Jx series won't share IP cores with SH/ARM, but as arch/sh/
maintainers you have to care about older Renesas SH platforms, too.

For patchwork, that would mean some more delegation needs to be put in place.

So far my 0.05€...

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 2/2] MAINTAINERS: remove linux-sh list from non-arch/sh sections

[Rich Felker]

On Fri, Jan 08, 2016 at 10:01:25AM +0100, Geert Uytterhoeven wrote:
> > Dropping linux-sh@vger.kernel.org from portions of the MAINTAINERS file as
> > you suggest would essentially leave the Renesas ARM work without a mailing
> > list or patchwork instance. Both of which are actively used for that work..
> >
> > Off-hand I can think of three solutions to this problem:
> >
> > 1. Live with the noise
> > 2. Establish a new list (and possibly patchwork instance) for the SH work..
> > 3. Establish a new list and patchwork instance for the ARM work.
> 
> Personally, I'd go for option 1.
> I would even like to propose H8/300 to join, as they share IP cores, too
> (m32r doesn't, AFAIK).
> 
> Many old ARM/SH-Mobile SoCs look like SH SoCs with an ARM CPU core bolted on.
> Recent Renesas ARM SoCs still share many IP cores with older SH SoCs; most of
> them even have a secondary SH4 CPU core. Using the SH4 CPU core could be useful
> for doing SH4 work, until J4 becomes mainstream (cfr. old prototype in
> http://www.spinics.net/lists/linux-sh/msg07188.html).
> Probably the Jx series won't share IP cores with SH/ARM, but as arch/sh/
> maintainers you have to care about older Renesas SH platforms, too.
> 
> For patchwork, that would mean some more delegation needs to be put in place.
> 
> So far my 0.05€...

Is that actually the case? I can't find any current support in the
kernel for running on these SH4 cores, and I was under the impression
that they were being phased out, if not already gone. And the bulk of
the driver-related discussion I've seen on linux-sh over the past year
does not seem to be related to hardware that's present/usable on
boards where you can run Linux/SH. If this is incorrect, I'd like to
hear some views on how/why such hardware is relevant to arch/sh.

Rich

Re: [PATCH 2/2] MAINTAINERS: remove linux-sh list from non-arch/sh sections

[Geert Uytterhoeven]

Hi Rich,

On Fri, Jan 8, 2016 at 7:21 PM, Rich Felker <dalias@libc.org> wrote:
> On Fri, Jan 08, 2016 at 10:01:25AM +0100, Geert Uytterhoeven wrote:
>> Many old ARM/SH-Mobile SoCs look like SH SoCs with an ARM CPU core bolted on.
>> Recent Renesas ARM SoCs still share many IP cores with older SH SoCs; most of
>> them even have a secondary SH4 CPU core. Using the SH4 CPU core could be useful
>> for doing SH4 work, until J4 becomes mainstream (cfr. old prototype in
>> http://www.spinics.net/lists/linux-sh/msg07188.html).
>> Probably the Jx series won't share IP cores with SH/ARM, but as arch/sh/
>> maintainers you have to care about older Renesas SH platforms, too.
>>
>> For patchwork, that would mean some more delegation needs to be put in place.
>>
>> So far my 0.05€...
>
> Is that actually the case? I can't find any current support in the
> kernel for running on these SH4 cores, and I was under the impression
> that they were being phased out, if not already gone. And the bulk of

There's no in-kernel support for these SH4 cores yet, just the prototype.

> the driver-related discussion I've seen on linux-sh over the past year
> does not seem to be related to hardware that's present/usable on
> boards where you can run Linux/SH. If this is incorrect, I'd like to
> hear some views on how/why such hardware is relevant to arch/sh.

At least the following drivers are shared between ARM and SH:

hspi
rspi
sh-cmt
sh_fsi
sh-mtu2
sh-sci (covering sci, scif, scifa, scifb, hscif)
sh-tmu
tpu

and of course the sh-pfc pinctrl subsystem.

Probably I'm forgetting a few that haven't been converted to DT on ARM yet,
and where the ARM side thus could benefit from a DT conversion on SH.

Note that you can find "shmobile" SoCs under both arch/sh/
(sh7723/sh7724/sh7343/sh7722/sh7366) and arch/arm/mach-shmobile/.
Some of these used to share even more code (e.g. drivers/sh/clk/), until the
ARM ones were converted to the Common Clock Framework.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 2/2] MAINTAINERS: remove linux-sh list from non-arch/sh sections

[Rich Felker]

On Fri, Jan 08, 2016 at 09:35:11PM +0100, Geert Uytterhoeven wrote:
> Hi Rich,
> 
> On Fri, Jan 8, 2016 at 7:21 PM, Rich Felker <dalias@libc.org> wrote:
> > On Fri, Jan 08, 2016 at 10:01:25AM +0100, Geert Uytterhoeven wrote:
> >> Many old ARM/SH-Mobile SoCs look like SH SoCs with an ARM CPU core bolted on.
> >> Recent Renesas ARM SoCs still share many IP cores with older SH SoCs; most of
> >> them even have a secondary SH4 CPU core. Using the SH4 CPU core could be useful
> >> for doing SH4 work, until J4 becomes mainstream (cfr. old prototype in
> >> http://www.spinics.net/lists/linux-sh/msg07188.html).
> >> Probably the Jx series won't share IP cores with SH/ARM, but as arch/sh/
> >> maintainers you have to care about older Renesas SH platforms, too.
> >>
> >> For patchwork, that would mean some more delegation needs to be put in place.
> >>
> >> So far my 0.05€...
> >
> > Is that actually the case? I can't find any current support in the
> > kernel for running on these SH4 cores, and I was under the impression
> > that they were being phased out, if not already gone. And the bulk of
> 
> There's no in-kernel support for these SH4 cores yet, just the prototype.

OK. Are they presently just running (non-Linux) firmware provided with
the boards? Or not being used at all? Also, is it correct that they're
all SH4, not SH5? I know on the gcc side there's interest in removing
SH5 support, and I'd probably like to do the same in the kernel if
it's not being used.

> > the driver-related discussion I've seen on linux-sh over the past year
> > does not seem to be related to hardware that's present/usable on
> > boards where you can run Linux/SH. If this is incorrect, I'd like to
> > hear some views on how/why such hardware is relevant to arch/sh.
> 
> At least the following drivers are shared between ARM and SH:
> 
> hspi
> rspi
> sh-cmt
> sh_fsi
> sh-mtu2
> sh-sci (covering sci, scif, scifa, scifb, hscif)
> sh-tmu
> tpu
> 
> and of course the sh-pfc pinctrl subsystem.

Thanks for making this list.

> Probably I'm forgetting a few that haven't been converted to DT on ARM yet,
> and where the ARM side thus could benefit from a DT conversion on SH.

That would be nice.

> Note that you can find "shmobile" SoCs under both arch/sh/
> (sh7723/sh7724/sh7343/sh7722/sh7366) and arch/arm/mach-shmobile/.
> Some of these used to share even more code (e.g. drivers/sh/clk/), until the
> ARM ones were converted to the Common Clock Framework.

Do you know how much is involved in converting the SH ones over to
Common Clock Framework? That seems to be one obstacle for full DT
conversion that supports the old boards.

Rich

Re: [PATCH 2/2] MAINTAINERS: remove linux-sh list from non-arch/sh sections

[Geert Uytterhoeven]

Hi Rich,

On Fri, Jan 8, 2016 at 9:52 PM, Rich Felker <dalias@libc.org> wrote:
> On Fri, Jan 08, 2016 at 09:35:11PM +0100, Geert Uytterhoeven wrote:
>> On Fri, Jan 8, 2016 at 7:21 PM, Rich Felker <dalias@libc.org> wrote:
>> > On Fri, Jan 08, 2016 at 10:01:25AM +0100, Geert Uytterhoeven wrote:
>> >> Many old ARM/SH-Mobile SoCs look like SH SoCs with an ARM CPU core bolted on.
>> >> Recent Renesas ARM SoCs still share many IP cores with older SH SoCs; most of
>> >> them even have a secondary SH4 CPU core. Using the SH4 CPU core could be useful
>> >> for doing SH4 work, until J4 becomes mainstream (cfr. old prototype in
>> >> http://www.spinics.net/lists/linux-sh/msg07188.html).
>> >> Probably the Jx series won't share IP cores with SH/ARM, but as arch/sh/
>> >> maintainers you have to care about older Renesas SH platforms, too.
>> >>
>> >> For patchwork, that would mean some more delegation needs to be put in place.
>> >>
>> >> So far my 0.05€...
>> >
>> > Is that actually the case? I can't find any current support in the
>> > kernel for running on these SH4 cores, and I was under the impression
>> > that they were being phased out, if not already gone. And the bulk of
>>
>> There's no in-kernel support for these SH4 cores yet, just the prototype.
>
> OK. Are they presently just running (non-Linux) firmware provided with
> the boards? Or not being used at all? Also, is it correct that they're

I don't know whether they're used in products.

> all SH4, not SH5? I know on the gcc side there's interest in removing
> SH5 support, and I'd probably like to do the same in the kernel if
> it's not being used.

The ones on the boards I have are either SH-4A or SH4AL-DSP.

>> Note that you can find "shmobile" SoCs under both arch/sh/
>> (sh7723/sh7724/sh7343/sh7722/sh7366) and arch/arm/mach-shmobile/.
>> Some of these used to share even more code (e.g. drivers/sh/clk/), until the
>> ARM ones were converted to the Common Clock Framework.
>
> Do you know how much is involved in converting the SH ones over to
> Common Clock Framework? That seems to be one obstacle for full DT
> conversion that supports the old boards.

The clock drivers for SH SoCs with module clocks ("MSTP") look very similar
to e.g. the old non-CCF clock driver for (ARM) SH-Mobile AG5 (sh73a0)
(cfr. arch/arm/mach-shmobile/clock-sh73a0.c in v4.2 and earlier).

With DT/CCF, sh73a0 is handled by clk-sh73a0.c, clk-mstp.c, clk-div6.c under
drivers/clk/shmobile/, and by generic "fixed-clock" and "fixed-factor-clock".
Only the first one is SoC-specific, the other two drivers should be reusable
for SH. This could be a good starting point to get something working.

However, a few years of experience with CCF has taught us that trying to
describe as many clocks as possible in DT has its disadvantages.
Hence for r8a7795 we started moving all clock definitions into the driver
again, cfr. renesas-cpg-mssr.c (core) and r8a7795-cpg-mssr.c in -next.
While I haven't converted sh73a0 yet, I believe a cpg-mssr based clock driver
can easily be written for SH SoCs that are sufficiently similar to sh73a0,
based on the existing SH clock drivers.

Older SH SoCs have even simpler clock drivers.

Disclaimer: I don't have any "pure" SH boards, nor did any (significant)
development for them.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 2/2] MAINTAINERS: remove linux-sh list from non-arch/sh sections

[Rob Landley]

On 01/08/2016 12:56 AM, Simon Horman wrote:
> On Thu, Jan 07, 2016 at 11:40:54PM -0500, Rich Felker wrote:
>> From: Rich Felker <dalias@libc.org>
>>
>> Recently the bulk of traffic on the linux-sh list has been unrelated
>> to arch/sh but instead focused on Renesas hardware for their ARM-based
>> SoCs. As part of resuming maintenance of arch/sh, remove the linux-sh
>> list from the MAINTAINERS file sections for these other components so
>> that new arch/sh development is not drowned out by unrelated
>> cross-postings.
> 
> The use of the linux-sh mailing list has evolved somewhat over time,
> from SH related to ARM related. Its name (obviously) has not evolved.

According to http://vger.kernel.org/vger-lists.html#linux-sh

  This is the development discussion and bug reporting mailing list
  for the Linux port to the SuperH architecture.

By "evolved" you mean "acquired a bunch of off-topic traffic because the
architecture's original owner abandoned it and moved on to other things
that already _have_ lists, but treated this list as their own personal
scratch pad".

Those people let the architecture this list was created for become
unmaintained for a year and a half. DURING that year and a half they
posted unrelated content to the list because they think it belongs to
them personally rather than to Linux.

Now that the architecture is becoming maintained again (on the hardware
side as well, because the patents have expired and other people are
taking an interest), we would like to reclaim this list to develop the
Linux arch/sh directory.

This is a kernel list, not a Renesas list.

> Dropping linux-sh@vger.kernel.org from portions of the MAINTAINERS file as
> you suggest would essentially leave the Renesas ARM work without a mailing
> list or patchwork instance.

Here's a half-dozen arm lists already:

  http://www.arm.linux.org.uk/mailinglists/lists.php

And that's not even a complete list of them all:

  http://vger.kernel.org/vger-lists.html#linux-tegra

> Both of which are actively used for that work.

Off-topic traffic exists, therefore it should exist? Its volume is its
justification? Why do we have spam filters then?

> Off-hand I can think of three solutions to this problem:
> 
> 1. Live with the noise
> 2. Establish a new list (and possibly patchwork instance) for the SH work.

So... squatter's rights?

Renesas calling its new arm stuff "shmobile" is as relevant as Intel
designating itanic "ia64" as the successor to "ia32". The superh
architecture's only been officially unmaintained for a year and change
(presumably because the patents were expiring so they saw no more profit
in it for themselves).

Meanwhile there was active superh-compatible work off-list during that
time (the j-core stuff) that's just now coming to fruition, building off
20 years of history and a decade and change of previous Linux development.

> 3. Establish a new list and patchwork instance for the ARM work.

Now that people are interested in superh again, the correct answer
seemed to be #3, which is what we were suggesting.

A similar situation occurred when buildroot didn't have its own mailing
list for several years and used the uClibc list: uClibc development
suffered greatly. I eventually got sick of it and created a new
buildroot list and politely kicked the traffic off, which is why the
first message in the buildroot mailing list archive is:

  http://lists.busybox.net/pipermail/buildroot/2006-July/012219.html

The corresponding "please move the buildroot traffic off the uClibc
list" thread started at:

  http://lists.busybox.net/pipermail/uclibc/2006-July/036836.html

The current list is not a Renesas list, it is a Linux list for the
SuperH architecture port. Says so on the tin, and that was its history
until pretty recently. Renesas moving away from the SuperH architecture
doesn't change that this is the Linux arch/sh list.

We aren't proposing to rename the arch/sh directory to "jcore", so
"linux-sh@vger.kernel.org" remains the logical name for this list. The
new stuff is intentionally backwards compatible with the old stuff, and
we are happy to maintain compatibility with the old stuff, and have
current plans to move it to device tree. (We just need a lot more legacy
test hardware...)

Rob

Re: [PATCH 2/2] MAINTAINERS: remove linux-sh list from non-arch/sh sections

[Laurent Pinchart]

Hi Rob,

On Friday 08 January 2016 11:35:37 Rob Landley wrote:
> On 01/08/2016 12:56 AM, Simon Horman wrote:
> > On Thu, Jan 07, 2016 at 11:40:54PM -0500, Rich Felker wrote:
> >> From: Rich Felker <dalias@libc.org>
> >> 
> >> Recently the bulk of traffic on the linux-sh list has been unrelated
> >> to arch/sh but instead focused on Renesas hardware for their ARM-based
> >> SoCs. As part of resuming maintenance of arch/sh, remove the linux-sh
> >> list from the MAINTAINERS file sections for these other components so
> >> that new arch/sh development is not drowned out by unrelated
> >> cross-postings.
> > 
> > The use of the linux-sh mailing list has evolved somewhat over time,
> > from SH related to ARM related. Its name (obviously) has not evolved.
> 
> According to http://vger.kernel.org/vger-lists.html#linux-sh
> 
>   This is the development discussion and bug reporting mailing list
>   for the Linux port to the SuperH architecture.
> 
> By "evolved" you mean "acquired a bunch of off-topic traffic because the
> architecture's original owner abandoned it and moved on to other things
> that already _have_ lists, but treated this list as their own personal
> scratch pad".
>
> Those people let the architecture this list was created for become
> unmaintained for a year and a half.

A year and a half since the architecture was officially marked as orphan, at 
least one more year since the maintainer stopped handling patches.

> DURING that year and a half they posted unrelated content to the list
> because they think it belongs to them personally rather than to Linux.

I would hardly call upstream Linux R-Mobile and R-Car development "personal 
stuff". The decision to keep using the linux-sh mailing list comes from the 
overlap between the SH-based and ARM-based chips. It sure doesn't match the 
mailing list description anymore, but jumping to the conclusion that the 
description is the only authoritative source of information is a bit too 
hasty.

> Now that the architecture is becoming maintained again (on the hardware
> side as well, because the patents have expired and other people are
> taking an interest), we would like to reclaim this list to develop the
> Linux arch/sh directory.

How about asking nicely instead of claiming ? It usually helps.

> This is a kernel list, not a Renesas list.

It has never become a Renesas list. We have private mailing lists for that.

> > Dropping linux-sh@vger.kernel.org from portions of the MAINTAINERS file as
> > you suggest would essentially leave the Renesas ARM work without a mailing
> > list or patchwork instance.
> 
> Here's a half-dozen arm lists already:
> 
>   http://www.arm.linux.org.uk/mailinglists/lists.php
> 
> And that's not even a complete list of them all:
> 
>   http://vger.kernel.org/vger-lists.html#linux-tegra
> 
> > Both of which are actively used for that work.
> 
> Off-topic traffic exists, therefore it should exist? Its volume is its
> justification? Why do we have spam filters then?
> 
> > Off-hand I can think of three solutions to this problem:
> > 
> > 1. Live with the noise
> > 2. Establish a new list (and possibly patchwork instance) for the SH work.
> 
> So... squatter's rights?
>
> Renesas calling its new arm stuff "shmobile" is as relevant as Intel
> designating itanic "ia64" as the successor to "ia32". The superh
> architecture's only been officially unmaintained for a year and change
> (presumably because the patents were expiring so they saw no more profit
> in it for themselves).
> 
> Meanwhile there was active superh-compatible work off-list during that
> time (the j-core stuff) that's just now coming to fruition, building off
> 20 years of history and a decade and change of previous Linux development.
> 
> > 3. Establish a new list and patchwork instance for the ARM work.
> 
> Now that people are interested in superh again, the correct answer
> seemed to be #3, which is what we were suggesting.

Now I like the suggesting better than the claiming :-)

> A similar situation occurred when buildroot didn't have its own mailing
> list for several years and used the uClibc list: uClibc development
> suffered greatly. I eventually got sick of it and created a new
> buildroot list and politely kicked the traffic off, which is why the
> first message in the buildroot mailing list archive is:
> 
>   http://lists.busybox.net/pipermail/buildroot/2006-July/012219.html
> 
> The corresponding "please move the buildroot traffic off the uClibc
> list" thread started at:
> 
>   http://lists.busybox.net/pipermail/uclibc/2006-July/036836.html
> 
> The current list is not a Renesas list, it is a Linux list for the
> SuperH architecture port. Says so on the tin, and that was its history
> until pretty recently. Renesas moving away from the SuperH architecture
> doesn't change that this is the Linux arch/sh list.
> 
> We aren't proposing to rename the arch/sh directory to "jcore", so
> "linux-sh@vger.kernel.org" remains the logical name for this list. The
> new stuff is intentionally backwards compatible with the old stuff,

How about IP cores around the CPU, do you plan to develop cores compatible 
with the Renesas implementations, or go for something else ? If we end up 
sharing the same peripherals between multiple architectures we will need to 
decide on how to coordinate the work.

> and we are happy to maintain compatibility with the old stuff, and have
> current plans to move it to device tree. (We just need a lot more legacy
> test hardware...)

I personally don't think that's worth it given that most of the legacy 
hardware is buried under a thick layer of dust (when not used as coasters or 
door stoppers).

-- 
Regards,

Laurent Pinchart

Re: [PATCH 2/2] MAINTAINERS: remove linux-sh list from non-arch/sh sections

[Rich Felker]

On Fri, Jan 08, 2016 at 08:28:51PM +0200, Laurent Pinchart wrote:
> > The current list is not a Renesas list, it is a Linux list for the
> > SuperH architecture port. Says so on the tin, and that was its history
> > until pretty recently. Renesas moving away from the SuperH architecture
> > doesn't change that this is the Linux arch/sh list.
> > 
> > We aren't proposing to rename the arch/sh directory to "jcore", so
> > "linux-sh@vger.kernel.org" remains the logical name for this list. The
> > new stuff is intentionally backwards compatible with the old stuff,
> 
> How about IP cores around the CPU, do you plan to develop cores compatible 
> with the Renesas implementations, or go for something else ? If we end up 
> sharing the same peripherals between multiple architectures we will need to 
> decide on how to coordinate the work.

To my knowledge, aside from the cpu which is of course ISA-compatible,
none of the current J-Core SOC components ("IP") are
interface-compatible with Renesas ones. I'm aiming to put as much as
possible in drivers/ rather than arch/sh/ because it should all be
shareable with other open-hardware cpus. We're already using uartlite
from drivers/ and I have some patches for it I still need to send
upstream, including SMP fixes and earlycon support.

> > and we are happy to maintain compatibility with the old stuff, and have
> > current plans to move it to device tree. (We just need a lot more legacy
> > test hardware...)
> 
> I personally don't think that's worth it given that most of the legacy 
> hardware is buried under a thick layer of dust (when not used as coasters or 
> door stoppers).

We probably need to gauge the level of interest in preserving support
for legacy hardware. I don't want to gratuitously drop anything, and I
think the device tree conversion will help us avoid that to some
extent by moving the bulk of hardware/board support from code to data,
but I will need to find a way to get my hands on some of the old
hardware if we want to verify that I'm not breaking it.

Another consideration is what qemu emulates, which right now is the
legacy hardware. After J2 support, my first sh kernel priority is
getting to the point where it can boot in qemu-system-sh4 using device
tree, and where qemu can be configured based on a device tree, so that
we can actually provide a reasonable amount of ram to run a modern
system. I know Rob is interested in this to be able to test full
system builds, native compiling, etc.

Rich

Re: [PATCH 2/2] MAINTAINERS: remove linux-sh list from non-arch/sh sections

[Laurent Pinchart]

Hi Rich,

On Friday 08 January 2016 14:40:09 Rich Felker wrote:
> On Fri, Jan 08, 2016 at 08:28:51PM +0200, Laurent Pinchart wrote:
> >> The current list is not a Renesas list, it is a Linux list for the
> >> SuperH architecture port. Says so on the tin, and that was its history
> >> until pretty recently. Renesas moving away from the SuperH architecture
> >> doesn't change that this is the Linux arch/sh list.
> >> 
> >> We aren't proposing to rename the arch/sh directory to "jcore", so
> >> "linux-sh@vger.kernel.org" remains the logical name for this list. The
> >> new stuff is intentionally backwards compatible with the old stuff,
> > 
> > How about IP cores around the CPU, do you plan to develop cores compatible
> > with the Renesas implementations, or go for something else ? If we end up
> > sharing the same peripherals between multiple architectures we will need
> > to decide on how to coordinate the work.
> 
> To my knowledge, aside from the cpu which is of course ISA-compatible,
> none of the current J-Core SOC components ("IP") are
> interface-compatible with Renesas ones.

OK, that answers my question. It won't be difficult to setup collaboration on 
drivers if we don't need to collaborate :-)

> I'm aiming to put as much as possible in drivers/ rather than arch/sh/
> because it should all be shareable with other open-hardware cpus.

Absolutely, that's the right way to do it I believe.

> We're already using uartlite from drivers/ and I have some patches for it I
> still need to send upstream, including SMP fixes and earlycon support.
> 
> > > and we are happy to maintain compatibility with the old stuff, and have
> > > current plans to move it to device tree. (We just need a lot more legacy
> > > test hardware...)
> > 
> > I personally don't think that's worth it given that most of the legacy
> > hardware is buried under a thick layer of dust (when not used as coasters
> > or door stoppers).
> 
> We probably need to gauge the level of interest in preserving support
> for legacy hardware. I don't want to gratuitously drop anything, and I
> think the device tree conversion will help us avoid that to some
> extent by moving the bulk of hardware/board support from code to data,
> but I will need to find a way to get my hands on some of the old
> hardware if we want to verify that I'm not breaking it.

I don't think there's much interest on Renesas' side. If nobody had stepped up 
to maintain arch/sh a patch to drop it completely would have been sent this 
year I believe. Anything that can be done without too much effort is fine 
(assuming you can get your hands on test hardware), just don't feel pressured.

And if it all means that we can remove platform data support at some point 
from drivers that kept it for arch/sh only, I'll be happy with that.

> Another consideration is what qemu emulates, which right now is the
> legacy hardware. After J2 support, my first sh kernel priority is
> getting to the point where it can boot in qemu-system-sh4 using device
> tree, and where qemu can be configured based on a device tree, so that
> we can actually provide a reasonable amount of ram to run a modern
> system. I know Rob is interested in this to be able to test full
> system builds, native compiling, etc.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 2/2] MAINTAINERS: remove linux-sh list from non-arch/sh sections

[Rob Landley]

On 01/08/2016 12:28 PM, Laurent Pinchart wrote:
> Hi Rob,
> 
> On Friday 08 January 2016 11:35:37 Rob Landley wrote:
>> On 01/08/2016 12:56 AM, Simon Horman wrote:
>>> On Thu, Jan 07, 2016 at 11:40:54PM -0500, Rich Felker wrote:
>>>> From: Rich Felker <dalias@libc.org>
>>>>
>>>> Recently the bulk of traffic on the linux-sh list has been unrelated
>>>> to arch/sh but instead focused on Renesas hardware for their ARM-based
>>>> SoCs. As part of resuming maintenance of arch/sh, remove the linux-sh
>>>> list from the MAINTAINERS file sections for these other components so
>>>> that new arch/sh development is not drowned out by unrelated
>>>> cross-postings.
>>>
>>> The use of the linux-sh mailing list has evolved somewhat over time,
>>> from SH related to ARM related. Its name (obviously) has not evolved.
>>
>> According to http://vger.kernel.org/vger-lists.html#linux-sh
>>
>>   This is the development discussion and bug reporting mailing list
>>   for the Linux port to the SuperH architecture.
>>
>> By "evolved" you mean "acquired a bunch of off-topic traffic because the
>> architecture's original owner abandoned it and moved on to other things
>> that already _have_ lists, but treated this list as their own personal
>> scratch pad".
>>
>> Those people let the architecture this list was created for become
>> unmaintained for a year and a half.
> 
> A year and a half since the architecture was officially marked as orphan, at 
> least one more year since the maintainer stopped handling patches.

At and least 5 since Paul Mundt wasn't confused by the concept of people
trying to use sh without being Renesas customers.

>> DURING that year and a half they posted unrelated content to the list
>> because they think it belongs to them personally rather than to Linux.
> 
> I would hardly call upstream Linux R-Mobile and R-Car development "personal 
> stuff". The decision to keep using the linux-sh mailing list comes from the 
> overlap between the SH-based and ARM-based chips. It sure doesn't match the 
> mailing list description anymore, but jumping to the conclusion that the 
> description is the only authoritative source of information is a bit too 
> hasty.

If this is _not_ a superh mailing list, there's still the option to move
the superh traffic to a dedicated superh mailing list.

I've been doing making the aboriginal linux superh stuff work on
aboriginal's mailing list for several years. (Alas Dreamhost has a nasty
habit of deleting mailing list archives. Last christmas they deleted
about 3 weeks, this christmas they deleted the past 11 months, so that's
not really my first choice of lists anymore.)

There's been an internal engineering mailing list at se-instruments for
a few years now. I made an earlier effort to move some of the traffic to
a mailing list on nommu.org but it kept mostly happening in private
email (even from people outside the company). I was hoping the kernel
list would be the logical place for it, but apparently wanting linux-sh
to be dedicated to linux superh is controversial.

Finding a _different_ list for the traffic and letting this one being
Renesas' personal scratch pad is, of course, an option. It seems kind of
silly, but if that's what vger.kernel.org wants...

If this list is the place to discuss things that have nothing to do with
superh, and the maintainer of superh has no say in changing that, then
this probably _isn't_ the superh discussion list.

>> Now that the architecture is becoming maintained again (on the hardware
>> side as well, because the patents have expired and other people are
>> taking an interest), we would like to reclaim this list to develop the
>> Linux arch/sh directory.
> 
> How about asking nicely instead of claiming ? It usually helps.

You're reading "we would like to do X" as "you can't stop us from doing X"?

>> This is a kernel list, not a Renesas list.
> 
> It has never become a Renesas list. We have private mailing lists for that.

Geert's previous message:

> Indeed, following the evolution of the SoC hardware, cfr. below.
> It meaning has shifted more to the "Linux Renesas mailing list".

I personally think "in the absence of a maintainer, this place got
filled with off-topic traffic" was the abberation, and that a new
maintainer (who is NOT me) has the right to request it not be so filled.
But I'm clearly a minority here.

>>> 3. Establish a new list and patchwork instance for the ARM work.
>>
>> Now that people are interested in superh again, the correct answer
>> seemed to be #3, which is what we were suggesting.
> 
> Now I like the suggesting better than the claiming :-)

You seem to consider this a change in tone. I don't understand why.

>> A similar situation occurred when buildroot didn't have its own mailing
>> list for several years and used the uClibc list: uClibc development
>> suffered greatly. I eventually got sick of it and created a new
>> buildroot list and politely kicked the traffic off, which is why the
>> first message in the buildroot mailing list archive is:
>>
>>   http://lists.busybox.net/pipermail/buildroot/2006-July/012219.html
>>
>> The corresponding "please move the buildroot traffic off the uClibc
>> list" thread started at:
>>
>>   http://lists.busybox.net/pipermail/uclibc/2006-July/036836.html
>>
>> The current list is not a Renesas list, it is a Linux list for the
>> SuperH architecture port. Says so on the tin, and that was its history
>> until pretty recently. Renesas moving away from the SuperH architecture
>> doesn't change that this is the Linux arch/sh list.
>>
>> We aren't proposing to rename the arch/sh directory to "jcore", so
>> "linux-sh@vger.kernel.org" remains the logical name for this list. The
>> new stuff is intentionally backwards compatible with the old stuff,
> 
> How about IP cores around the CPU, do you plan to develop cores compatible 
> with the Renesas implementations, or go for something else ?

Not that I know of, but the people to ask are either Jeff Dionne or
Geoff Salmon (or Martin, or Niishi-san, or... As I said, I'm trying to
migrate that discussion _off_ of various private email channels and get
it onto open lists where it's archived. I'm also bothering people to
WRITE DOWN the roadmap. Right now it's in Jeff's head...)

That said, it's an open source project, anybody can implement what they
want. The full VHDL history would already be on github if we weren't
understaffed. (There's a tarball of the VHDL up from something like
June, but converting the history from mercurial in several different
repos to one git repository with a sane unified history is not something
there's an existing tool for; I got very far along doing it by hand
before realizing that "hg export" without telling it "--git" doesn't
export any file it thinks of as "binary", such as the openoffice
spreadsheet containing the instruction definitions, which is a kinda
important input into the build process. Wound up having to start over
and my todo list runneth over. If you'd like a giant pile of "hg export"
patches that don't connect up with each other, feel free to email me...)

> If we end up 
> sharing the same peripherals between multiple architectures we will need to 
> decide on how to coordinate the work.

I'm pretty sure we can stick arbitrary stuff into it, but right now
they're redoing the design of some I/O engine as a prerequisite for
adding USB2 (the FPGA isn't clocked fast enough for USB3, I think?) and
that was never in the old renesas stuff that I know of...

Actually, I think Russell Lait is probably the guy you want to talk
about for roadmap stuff because he's the guy trying to put together the
series of kickstarter campaigns for various open hardware stuff.
(They're currently designing a raspberry-pi compatible LX45 board,
because the Numato LX9 boards don't have enough gates to do the SMP and
DSP stuff we want to release. And as long as they're doing raspberry pi
they want to do all the peripherals THAT has, which is where USB and
hdmi and so on come into it. Again, I'm a software guy, barely started
to learn VHDL yet...)

Anyway, getting all this traffic onto public list was kind of what I was
hoping to do. (Not necessarily all on this one, but at least getting
kernel stuff upstream is good...)

>> and we are happy to maintain compatibility with the old stuff, and have
>> current plans to move it to device tree. (We just need a lot more legacy
>> test hardware...)
> 
> I personally don't think that's worth it given that most of the legacy 
> hardware is buried under a thick layer of dust (when not used as coasters or 
> door stoppers).

I am regression testing sh4 in qemu, but people keep objecting that qemu
is not "real".

I'm all for ignoring sh3 since it only shipped for about a year before
being replaced by sh4, but it's not really my call. There's continuing
interest in nommu (thus sh2) going forward because A) hard realtime
constraints in products we're shipping so eliminating page fault latency
actually helps, B) Jeff Dionne founded uclinux before wandering back
into hardware (and moving to Japan) in 2003, and now that he's
resurfaced into the Linux world and noticed that uclinux died in his
absence, he wants to fix that. (Which means the new nommu.org website
needs to grow cortex-m support and we should dig up coldfire and h8300
shoudl go there...)

It would be nice if there was a nommu@vger.kernel.org list, but that
should not be THIS list.

(Then there's more current sh4a stuff that won't have its patents expire
for a while yet, so is uninteresting to jcore for the forseeable future...)

I'm sad that the presentation we gave at Linuxcon Japan (along with the
original SuperH architect, Kawasaki-san) wasn't recorded, but apparently
somebody stole all the Linux Foundation's cameras one year so they
decided to stop recording anything ever. (Tim Bird still records the
stuff he's involved in, so CELF posts videos, but the Linux Foundation
doesn't for stuff like Linuxcon...)

Rob

Also, Jeff gave a talk at ELC Europe, but he let himself get talked into
having it upgraded from normal talk to "keynote", which meant it wasn't
recorded because they dumped him in the "our sponsors are giving
infomercials" section. So THAT apparently wasn't recorded either...

https://lceeu2015.sched.org/event/3xSV/keynote-building-the-j-core-cpu-as-open-hardware-disruptive-open-source-principles-applied-to-hardware-and-software-jeff-dionne-smart-energy-instruments

Really, we keep answering the same questions, the results just don't get
collected in one place. Clearly, this isn't that place either...

Re: [PATCH 2/2] MAINTAINERS: remove linux-sh list from non-arch/sh sections

[Geert Uytterhoeven]

Hi Rob,

On Fri, Jan 8, 2016 at 11:50 PM, Rob Landley <rob@landley.net> wrote:
> On 01/08/2016 12:28 PM, Laurent Pinchart wrote:
>> On Friday 08 January 2016 11:35:37 Rob Landley wrote:
>>> On 01/08/2016 12:56 AM, Simon Horman wrote:
>>>> On Thu, Jan 07, 2016 at 11:40:54PM -0500, Rich Felker wrote:
>>>>> From: Rich Felker <dalias@libc.org>
>>>>>
>>>>> Recently the bulk of traffic on the linux-sh list has been unrelated
>>>>> to arch/sh but instead focused on Renesas hardware for their ARM-based
>>>>> SoCs. As part of resuming maintenance of arch/sh, remove the linux-sh
>>>>> list from the MAINTAINERS file sections for these other components so
>>>>> that new arch/sh development is not drowned out by unrelated
>>>>> cross-postings.
>>>>
>>>> The use of the linux-sh mailing list has evolved somewhat over time,
>>>> from SH related to ARM related. Its name (obviously) has not evolved.
>>>
>>> According to http://vger.kernel.org/vger-lists.html#linux-sh
>>>
>>>   This is the development discussion and bug reporting mailing list
>>>   for the Linux port to the SuperH architecture.
>>>
>>> By "evolved" you mean "acquired a bunch of off-topic traffic because the
>>> architecture's original owner abandoned it and moved on to other things
>>> that already _have_ lists, but treated this list as their own personal
>>> scratch pad".
>>>
>>> Those people let the architecture this list was created for become
>>> unmaintained for a year and a half.
>>
>> A year and a half since the architecture was officially marked as orphan, at
>> least one more year since the maintainer stopped handling patches.
>
> At and least 5 since Paul Mundt wasn't confused by the concept of people
> trying to use sh without being Renesas customers.
>
>>> DURING that year and a half they posted unrelated content to the list
>>> because they think it belongs to them personally rather than to Linux.
>>
>> I would hardly call upstream Linux R-Mobile and R-Car development "personal
>> stuff". The decision to keep using the linux-sh mailing list comes from the
>> overlap between the SH-based and ARM-based chips. It sure doesn't match the
>> mailing list description anymore, but jumping to the conclusion that the
>> description is the only authoritative source of information is a bit too
>> hasty.
>
> If this is _not_ a superh mailing list, there's still the option to move
> the superh traffic to a dedicated superh mailing list.
>
> I've been doing making the aboriginal linux superh stuff work on
> aboriginal's mailing list for several years. (Alas Dreamhost has a nasty
> habit of deleting mailing list archives. Last christmas they deleted
> about 3 weeks, this christmas they deleted the past 11 months, so that's
> not really my first choice of lists anymore.)
>
> There's been an internal engineering mailing list at se-instruments for
> a few years now. I made an earlier effort to move some of the traffic to
> a mailing list on nommu.org but it kept mostly happening in private
> email (even from people outside the company). I was hoping the kernel
> list would be the logical place for it, but apparently wanting linux-sh
> to be dedicated to linux superh is controversial.
>
> Finding a _different_ list for the traffic and letting this one being
> Renesas' personal scratch pad is, of course, an option. It seems kind of
> silly, but if that's what vger.kernel.org wants...
>
> If this list is the place to discuss things that have nothing to do with
> superh, and the maintainer of superh has no say in changing that, then
> this probably _isn't_ the superh discussion list.
>
>>> Now that the architecture is becoming maintained again (on the hardware
>>> side as well, because the patents have expired and other people are
>>> taking an interest), we would like to reclaim this list to develop the
>>> Linux arch/sh directory.
>>
>> How about asking nicely instead of claiming ? It usually helps.
>
> You're reading "we would like to do X" as "you can't stop us from doing X"?
>
>>> This is a kernel list, not a Renesas list.
>>
>> It has never become a Renesas list. We have private mailing lists for that.
>
> Geert's previous message:
>
>> Indeed, following the evolution of the SoC hardware, cfr. below.
>> It meaning has shifted more to the "Linux Renesas mailing list".

What I mean is that this is still a public mailing list for the Linux kernel
community, to discuss and develop for Renesas SoCs, which are evolutions from
the old SuperH SoCs.

> I personally think "in the absence of a maintainer, this place got
> filled with off-topic traffic" was the abberation, and that a new
> maintainer (who is NOT me) has the right to request it not be so filled.
> But I'm clearly a minority here.

Unfortunately it's not that black and white. The ARM "shmobile" SoCs did
evolve from SH SoCs, and are still related, hardware-wise (the only exception
is EMEV2).

I know it's not a perfect comparison (CPU cores vs. SoCs containing not only
CPU cores, but also support hardware called "IP cores"), but assume the
original x86 Linux mailing list was called "linux-i386". The mailing list
name's would stay unchanged, but Linux gains support for i486, i586, and so on.
Now imagine someone created a free i386 clone, and demanded "all off-topic
amd64 traffic" to be removed...

Also, IMHO the comparison to Apple moving from ppc to x86 doesn't fly well,
as the Apple machines with x86 CPUs are (almost?) PCs, and have, besides the
OS, little resemblance with their PPC ancestors.

> I'm sad that the presentation we gave at Linuxcon Japan (along with the
> original SuperH architect, Kawasaki-san) wasn't recorded, but apparently
> somebody stole all the Linux Foundation's cameras one year so they
> decided to stop recording anything ever. (Tim Bird still records the
> stuff he's involved in, so CELF posts videos, but the Linux Foundation
> doesn't for stuff like Linuxcon...)

At least the slides are available on the net.

> Also, Jeff gave a talk at ELC Europe, but he let himself get talked into
> having it upgraded from normal talk to "keynote", which meant it wasn't
> recorded because they dumped him in the "our sponsors are giving
> infomercials" section. So THAT apparently wasn't recorded either...
>
> https://lceeu2015.sched.org/event/3xSV/keynote-building-the-j-core-cpu-as-open-hardware-disruptive-open-source-principles-applied-to-hardware-and-software-jeff-dionne-smart-energy-instruments

That's a real pity (I've attended it).

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: [PATCH 2/2] MAINTAINERS: remove linux-sh list from non-arch/sh sections

[Rob Landley]

On 01/10/2016 02:05 PM, Geert Uytterhoeven wrote:
>>>> This is a kernel list, not a Renesas list.
>>>
>>> It has never become a Renesas list. We have private mailing lists for that.
>>
>> Geert's previous message:
>>
>>> Indeed, following the evolution of the SoC hardware, cfr. below.
>>> It meaning has shifted more to the "Linux Renesas mailing list".
> 
> What I mean is that this is still a public mailing list for the Linux kernel
> community, to discuss and develop for Renesas SoCs, which are evolutions from
> the old SuperH SoCs.

There is a lot of unrelated traffic on here which is just noise for the
original purpose of maintaining arch/sh, yes. That's what I"m
complaining about.

The reason I recounted the earlier stuff about other lists is that there
is active traffic in this architecture. The fact Renesas itself isn't
doing doesn't mean that other people haven't been.

I wanted to direct that traffic here, but I'm not going to if there are
multiple dozens of unrelated messages in the amount of time we've been
having this conversation.

Clearly the kernel no longer has a dedicated arch/sh list. I see that as
a problem to be fixed.

>> I personally think "in the absence of a maintainer, this place got
>> filled with off-topic traffic" was the abberation, and that a new
>> maintainer (who is NOT me) has the right to request it not be so filled.
>> But I'm clearly a minority here.
> 
> Unfortunately it's not that black and white. The ARM "shmobile" SoCs did
> evolve from SH SoCs, and are still related, hardware-wise (the only exception
> is EMEV2).

And x86-64 plugged into the Alpha EV6 bus because AMD hired the Alpha
development team away from the corpse of DEC when Compaq bought them.
The only difference between the original x86-64 boards and an Alpha
board was the type of assembly flashed into the boot ROM.

Are you suggesting x86-64 should have done all its development on
linux-alpha? Or that if they did for a year and a half and then Alpha
guys came back and complained, the Alpha guys were the ones who should
move to a new list?

> I know it's not a perfect comparison (CPU cores vs. SoCs containing not only
> CPU cores, but also support hardware called "IP cores"), but assume the
> original x86 Linux mailing list was called "linux-i386".

It was called "comp.os.minix". They got kicked off it for being
off-topic, and founded linux-activists. (Then moved to
linux-kernel@vger.rutgers.edu, then moved to
linux-kernel@vger.kernel.org...)

> The mailing list
> name's would stay unchanged, but Linux gains support for i486, i586, and so on.
> Now imagine someone created a free i386 clone, and demanded "all off-topic
> amd64 traffic" to be removed...

Except amd64 is backwards compatible with x86, muddying the issue.
linux-alpha was the first incompatible port. It has its own list.

> Also, IMHO the comparison to Apple moving from ppc to x86 doesn't fly well,
> as the Apple machines with x86 CPUs are (almost?) PCs, and have, besides the
> OS, little resemblance with their PPC ancestors.

A) And therefore staying on the ppc list would have been appropriate?
(We're arguing _for_ a move. Could you give me an example of "We would
like to continue using this list for its intended and stated original
purpose, but it's being overwhelmed by off-topic traffic" was resolved
in _favor_ of the new topic?)

B) Was the m68k->powerpc switch from the same company similar enough
hardware for... whatever point you're making?

Rob

Re: [PATCH 2/2] MAINTAINERS: remove linux-sh list from non-arch/sh sections

[uClinux.org]

On Jan 11, 2016, at 11:02, Rob Landley <rob@landley.net> wrote:

>>>> meaning has shifted more to the "Linux Renesas mailing list".
>> 
>> What I mean is that this is still a public mailing list for the Linux kernel community, to discuss and develop for Renesas SoCs, which are evolutions from the old SuperH SoCs.
> 
> There is a lot of unrelated traffic on here which is just noise for the original purpose of maintaining arch/sh, yes.

And -this- is the point.  SH is an ISA, which is no longer controller by Renensas, nee Hitachi Semiconductor.  We now have (and employ as their day job) some of the original architects of that ISA in the J-Core project.  Renesas has abandoned the ISA, now that the patents have expired.

We aim to build community support, in the Linux community, for this ISA.  That means 'public mailing list... old SuperH SoCs' is not only the wrong way to look at it, it's actually counter productive to building that support.  Who wants old SoCs?

Re: [PATCH 2/2] MAINTAINERS: remove linux-sh list from non-arch/sh sections

[Rich Felker]

On Fri, Jan 08, 2016 at 11:35:37AM -0600, Rob Landley wrote:
> On 01/08/2016 12:56 AM, Simon Horman wrote:
> > On Thu, Jan 07, 2016 at 11:40:54PM -0500, Rich Felker wrote:
> >> From: Rich Felker <dalias@libc.org>
> >>
> >> Recently the bulk of traffic on the linux-sh list has been unrelated
> >> to arch/sh but instead focused on Renesas hardware for their ARM-based
> >> SoCs. As part of resuming maintenance of arch/sh, remove the linux-sh
> >> list from the MAINTAINERS file sections for these other components so
> >> that new arch/sh development is not drowned out by unrelated
> >> cross-postings.
> > 
> > The use of the linux-sh mailing list has evolved somewhat over time,
> > from SH related to ARM related. Its name (obviously) has not evolved.
> 
> According to http://vger.kernel.org/vger-lists.html#linux-sh
> 
>   This is the development discussion and bug reporting mailing list
>   for the Linux port to the SuperH architecture.
> 
> By "evolved" you mean "acquired a bunch of off-topic traffic because the
> architecture's original owner abandoned it and moved on to other things
> that already _have_ lists, but treated this list as their own personal
> scratch pad".
> 
> Those people let the architecture this list was created for become
> unmaintained for a year and a half. DURING that year and a half they
> posted unrelated content to the list because they think it belongs to
> them personally rather than to Linux.
> 
> Now that the architecture is becoming maintained again (on the hardware
> side as well, because the patents have expired and other people are
> taking an interest), we would like to reclaim this list to develop the
> Linux arch/sh directory.
> 
> This is a kernel list, not a Renesas list.
> 
> > Dropping linux-sh@vger.kernel.org from portions of the MAINTAINERS file as
> > you suggest would essentially leave the Renesas ARM work without a mailing
> > list or patchwork instance.
> 
> Here's a half-dozen arm lists already:
> 
>   http://www.arm.linux.org.uk/mailinglists/lists.php
> 
> And that's not even a complete list of them all:
> 
>   http://vger.kernel.org/vger-lists.html#linux-tegra
> 
> > Both of which are actively used for that work.
> 
> Off-topic traffic exists, therefore it should exist? Its volume is its
> justification? Why do we have spam filters then?
> 
> > Off-hand I can think of three solutions to this problem:
> > 
> > 1. Live with the noise
> > 2. Establish a new list (and possibly patchwork instance) for the SH work.
> 
> So... squatter's rights?
> 
> Renesas calling its new arm stuff "shmobile" is as relevant as Intel
> designating itanic "ia64" as the successor to "ia32". The superh
> architecture's only been officially unmaintained for a year and change
> (presumably because the patents were expiring so they saw no more profit
> in it for themselves).
> 
> Meanwhile there was active superh-compatible work off-list during that
> time (the j-core stuff) that's just now coming to fruition, building off
> 20 years of history and a decade and change of previous Linux development.

I'm not here to place blame or argue over who's "fault" it is that
this happened, but it is inappropriate for a kernel arch list to be
used as a development list for hardware that's no longer related to
the arch and just happens to be produced/used by the same company.
Another decent analogy might be if the linuxppc list had been deluged
with driver traffic for Apple-specific x86 hardware after Apple
dropped PPC and switched to x86. As far as I know, no such thing
happened, but I don't think it would have gone over well.

> [...]
> We aren't proposing to rename the arch/sh directory to "jcore", so
> "linux-sh@vger.kernel.org" remains the logical name for this list. The
> new stuff is intentionally backwards compatible with the old stuff, and
> we are happy to maintain compatibility with the old stuff, and have
> current plans to move it to device tree. (We just need a lot more legacy
> test hardware...)

Indeed. SH is a nice arch with a very long history on Linux, and I'm
happy to be carrying forward its legacy. I believe doing this within
the framework that's already there (and thereby preserving and
improving support for the legacy hardware), rather than starting over
as if it were a new arch, is the right way to go, having the list
overrun with mostly-unrelated traffic is an unfortunate situation to
be in, and one that I'd like to see corrected.

Rich

Re: [PATCH 2/2] MAINTAINERS: remove linux-sh list from non-arch/sh sections

[Sergei Shtylyov]

Hello.

On 01/08/2016 07:40 AM, Rich Felker wrote:

> From: Rich Felker <dalias@libc.org>
>
> Recently the bulk of traffic on the linux-sh list has been unrelated
> to arch/sh but instead focused on Renesas hardware for their ARM-based
> SoCs. As part of resuming maintenance of arch/sh, remove the linux-sh
> list from the MAINTAINERS file sections for these other components so
> that new arch/sh development is not drowned out by unrelated
> cross-postings.
>
> Signed-off-by: Rich Felker <dalias@libc.org>
> Acked-by: D. Jeff Dionne <jeff@uClinux.org>
> Acked-by: Rob Landley <rob@landley.net>
>
> ---
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 9bff63c..8f5f953 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS

[...]
> @@ -8369,7 +8364,6 @@ F:	drivers/pinctrl/intel/
>
>   PIN CONTROLLER - RENESAS
>   M:	Laurent Pinchart <laurent.pinchart@ideasonboard.com>
> -L:	linux-sh@vger.kernel.org
>   S:	Maintained
>   F:	drivers/pinctrl/sh-pfc/

    Wait, this directory also contains the SuperH PFC drivers.

MBR, Sergei