| Message ID | 20160108044054.GA7130@brightrain.aerifal.cx (mailing list archive) |
|---|---|
| State | Superseded |
| Delegated to: | Simon Horman |
| Headers | show |
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. -- 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
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 -- 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
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 -- 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
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 -- 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
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 -- 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
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).
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 -- 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
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 -- 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
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 -- 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
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 -- 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
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... -- 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
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.
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 -- 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
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 -- 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
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 -- 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
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?-- 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
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/