Re: remove arch/sh
Hi Steve! On Mon, 2023-02-06 at 10:08 +1100, Stephen Rothwell wrote: > Hi, > > On Fri, 3 Feb 2023 09:30:37 +0100 Christoph Hellwig wrote: > > > > On Fri, Feb 03, 2023 at 09:24:46AM +0100, John Paul Adrian Glaubitz wrote: > > > Since this is my very first time stepping up as a kernel maintainer, I > > > was hoping > > > to get some pointers on what to do to make this happen. > > > > > > So far, we have set up a new kernel tree and I have set up a local > > > development and > > > test environment for SH kernels using my SH7785LCR board as the target > > > platform. > > > > > > Do I just need to send a patch asking to change the corresponding entry > > > in the > > > MAINTAINERS file? > > > > I'm not sure a there is a document, but: > > > > - add the MAINTAINERS change to your tree > > - ask Stephen to get your tree included in linux-next > > And by "Stephen", Christoph means me. When you are ready, please send > me a request to include your tree/branch in linux-next (usually the > branch is called something like "for-next" or just "next") telling me > the git URL, and the contacts I should send email to if there are > conflicts/build issues with the branch. I will then fetch the branch > every time I create a new linux-next release (most work days), so all > you need to do is update that branch each time you are ready to publish > more commits. I'm in the MAINTAINERS now in Linus' tree. I have requested a kernel.org account now and will hopefully have my trees set up later this week. I'll let you know about the URLs as soon as possible. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
On Wed, 2023-02-08 at 21:09 -0600, Rob Landley wrote: > > Geert has suggested to wait with adding a tree source to the entry until I > > get my > > own kernel.org account. I have enough GPG signatures from multiple kernel > > developers > > on my GPG key, so I think it shouldn't be too difficult to qualify for an > > account. > > So you're not planning to use https://lk.j-core.org/J-Core-Developers/sh-linux > but push to kernel.org and ask Linus to pull from there? Yes, that's what Geert recommended. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
On 2/8/23 06:13, John Paul Adrian Glaubitz wrote: > Hi Randy! > > On Tue, 2023-02-07 at 17:31 -0800, Randy Dunlap wrote: >> >> On 2/7/23 01:06, John Paul Adrian Glaubitz wrote: >> > Hello Christoph! >> > >> > On Fri, 2023-02-03 at 08:14 +0100, Christoph Hellwig wrote: >> > > On Mon, Jan 16, 2023 at 09:52:10AM +0100, John Paul Adrian Glaubitz >> > > wrote: >> > > > We have had a discussion between multiple people invested in the >> > > > SuperH port and >> > > > I have decided to volunteer as a co-maintainer of the port to support >> > > > Rich Felker >> > > > when he isn't available. >> > > >> > > So, this still isn't reflected in MAINTAINERS in linux-next. When >> > > do you plan to take over? What platforms will remain supported and >> > > what can we start dropping due to being unused and unmaintained? >> > >> > I'm getting everything ready now with Geert's help and I have a probably >> > dumb >> > question regarding the MAINTAINERS file change: Shall I just add myself as >> > an >> > additional maintainer first or shall I also drop Yoshinori Sato? >> > >> > Also, is it desirable to add a "T:" entry for the kernel tree? >> >> Yes, definitely. > > Geert has suggested to wait with adding a tree source to the entry until I > get my > own kernel.org account. I have enough GPG signatures from multiple kernel > developers > on my GPG key, so I think it shouldn't be too difficult to qualify for an > account. So you're not planning to use https://lk.j-core.org/J-Core-Developers/sh-linux but push to kernel.org and ask Linus to pull from there? > Adrian Rob
Re: remove arch/sh
On 2/3/23 09:57, Randy Dunlap wrote: > Hi-- > > On 2/3/23 02:33, Geert Uytterhoeven wrote: >> Hi Adrian, >> >> On Fri, Feb 3, 2023 at 11:29 AM John Paul Adrian Glaubitz >> wrote: >>> On Fri, 2023-02-03 at 09:30 +0100, Christoph Hellwig wrote: On Fri, Feb 03, 2023 at 09:24:46AM +0100, John Paul Adrian Glaubitz wrote: > Since this is my very first time stepping up as a kernel maintainer, I > was hoping > to get some pointers on what to do to make this happen. > > So far, we have set up a new kernel tree and I have set up a local > development and > test environment for SH kernels using my SH7785LCR board as the target > platform. > > Do I just need to send a patch asking to change the corresponding entry > in the > MAINTAINERS file? I'm not sure a there is a document, but: - add the MAINTAINERS change to your tree - ask Stephen to get your tree included in linux-next then eventually send a pull request to Linus with all of that. Make sure it's been in linux-next for a while. >>> >>> OK, thanks for the pointers! Will try to get this done by next week. >>> >>> We're still discussing among SuperH developer community whether there will >>> be a second >>> maintainer, so please bear with us a few more days. I will collect patches >>> in the >>> meantime. >> >> Thanks a lot! >> >> If you need any help with process, setup, ... don't hesitate to ask >> (on e.g. #renesas-soc on Libera). > > While Adrian and Geert are reading this, I have a question: > > Is this "sh64" still accurate and applicable? I hadn't noticed it was there... Randy Dunlap added that in 2018 (commit 09b1565324cba). I wonder why? > from Documentation/kbuild/kbuild.rst: There isn't an active 64 bit superh architecture for the moment: sh5 was a prototype that never shipped in volume, and support was removed in commit 37744feebc08. From the j-core side j64 hasn't shipped yet either (still planned last I heard, but j-core went downmarket first instead due to customer demand, and multi-issue is on the roadmap before 64 bit address space). The general trend in linux kernel architectures has been to merge 32 and 64 bit anyway, and just have the .config set CONFIG_64BIT to distinguish: arch/x86 was created by merging arch/i386 and arch/x86_64 in 2007, arch/powerpc merged the 32 and 64 bit directories in 2005, arch/s390 and s390x are in the same dir, arch/mips... (For some reason arm and arm64 are still split, but that might be fallout from Arm Ltd trying to distinguish aarrcchh6644 from "arm" for some reason? Dunno.) I wonder why is this going the other way? I thought $ARCH mostly just specified the subdirectory under arch/ with a few historical aliases in the top level Makefile: # Additional ARCH settings for x86 ifeq ($(ARCH),i386) SRCARCH := x86 endif ifeq ($(ARCH),x86_64) SRCARCH := x86 endif # Additional ARCH settings for sparc ifeq ($(ARCH),sparc32) SRCARCH := sparc endif ifeq ($(ARCH),sparc64) SRCARCH := sparc endif # Additional ARCH settings for parisc ifeq ($(ARCH),parisc64) SRCARCH := parisc endif But you could always just specify the correct ARCH directory directly and it would work. (Always did when I tried it, although I haven't built sparc in years because there's no musl-libc support, and never built parisc64 because I couldn't get it to work with uClibc even before musl. I _am_ still building both 32 bit and 64 bit x86 with ARCH=x86 both times...) > But some architectures such as x86 and sparc have aliases. > > - x86: i386 for 32 bit, x86_64 for 64 bit > - sh: sh for 32 bit, sh64 for 64 bit <<< > - sparc: sparc32 for 32 bit, sparc64 for 64 bit Randy also added the sparc alias in commit 5ba800962a80. That at least exists in the top level Makefile. Did he mean parisc64 and typoed sh64? Because that's the only other alias in the top level Makefile... In any case, these are historical aliases for old builds, which can probably get yanked because it should be a trivial fix to use the right ARCH= value for modern builds? (I'd think?) You'd even be able to build a 64 bit version of ARCH=i386 just fine if it wasn't for the ONE place in arch/x86/Kconfig that actually checks: config 64BIT bool "64-bit kernel" if "$(ARCH)" = "x86" default "$(ARCH)" != "i386" Same for arch/sparc/Kconfig: config 64BIT bool "64-bit kernel" if "$(ARCH)" = "sparc" default "$(ARCH)" = "sparc64" Nothing else anywhere seems to care... > Thanks. Rob
Re: remove arch/sh
> Yes, that's the plan. We're collecting the various patches people have sent > in for arch/sh, review and test them and apply them. > > My test board is running the latest kernel now, so I can test new patches, > too. I am just witnessing this development, but I want to say thanks for your effort and congrats on your progress. Looks like you do the right things correctly, cool! Kudos also to Geert and others for their assistance. signature.asc Description: PGP signature
Re: remove arch/sh
Hi Huacei! On Wed, 2023-02-08 at 20:24 +0800, Huacai Chen wrote: > Emm, maybe this patch has its chance to be merged now. :) > > https://lore.kernel.org/linux-sh/caahv-h6siotvkzpks4aabejgzcqtwp3tiha0+0hgz1+mu3x...@mail.gmail.com/T/#u Yes, that's the plan. We're collecting the various patches people have sent in for arch/sh, review and test them and apply them. My test board is running the latest kernel now, so I can test new patches, too. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
Emm, maybe this patch has its chance to be merged now. :) https://lore.kernel.org/linux-sh/caahv-h6siotvkzpks4aabejgzcqtwp3tiha0+0hgz1+mu3x...@mail.gmail.com/T/#u Huacai On Wed, Feb 8, 2023 at 8:14 PM John Paul Adrian Glaubitz wrote: > > Hi Randy! > > On Tue, 2023-02-07 at 17:31 -0800, Randy Dunlap wrote: > > > > On 2/7/23 01:06, John Paul Adrian Glaubitz wrote: > > > Hello Christoph! > > > > > > On Fri, 2023-02-03 at 08:14 +0100, Christoph Hellwig wrote: > > > > On Mon, Jan 16, 2023 at 09:52:10AM +0100, John Paul Adrian Glaubitz > > > > wrote: > > > > > We have had a discussion between multiple people invested in the > > > > > SuperH port and > > > > > I have decided to volunteer as a co-maintainer of the port to support > > > > > Rich Felker > > > > > when he isn't available. > > > > > > > > So, this still isn't reflected in MAINTAINERS in linux-next. When > > > > do you plan to take over? What platforms will remain supported and > > > > what can we start dropping due to being unused and unmaintained? > > > > > > I'm getting everything ready now with Geert's help and I have a probably > > > dumb > > > question regarding the MAINTAINERS file change: Shall I just add myself > > > as an > > > additional maintainer first or shall I also drop Yoshinori Sato? > > > > > > Also, is it desirable to add a "T:" entry for the kernel tree? > > > > Yes, definitely. > > Geert has suggested to wait with adding a tree source to the entry until I > get my > own kernel.org account. I have enough GPG signatures from multiple kernel > developers > on my GPG key, so I think it shouldn't be too difficult to qualify for an > account. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer > `. `' Physicist > `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
Hi Randy! On Tue, 2023-02-07 at 17:31 -0800, Randy Dunlap wrote: > > On 2/7/23 01:06, John Paul Adrian Glaubitz wrote: > > Hello Christoph! > > > > On Fri, 2023-02-03 at 08:14 +0100, Christoph Hellwig wrote: > > > On Mon, Jan 16, 2023 at 09:52:10AM +0100, John Paul Adrian Glaubitz wrote: > > > > We have had a discussion between multiple people invested in the SuperH > > > > port and > > > > I have decided to volunteer as a co-maintainer of the port to support > > > > Rich Felker > > > > when he isn't available. > > > > > > So, this still isn't reflected in MAINTAINERS in linux-next. When > > > do you plan to take over? What platforms will remain supported and > > > what can we start dropping due to being unused and unmaintained? > > > > I'm getting everything ready now with Geert's help and I have a probably > > dumb > > question regarding the MAINTAINERS file change: Shall I just add myself as > > an > > additional maintainer first or shall I also drop Yoshinori Sato? > > > > Also, is it desirable to add a "T:" entry for the kernel tree? > > Yes, definitely. Geert has suggested to wait with adding a tree source to the entry until I get my own kernel.org account. I have enough GPG signatures from multiple kernel developers on my GPG key, so I think it shouldn't be too difficult to qualify for an account. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
On 2/7/23 01:06, John Paul Adrian Glaubitz wrote: > Hello Christoph! > > On Fri, 2023-02-03 at 08:14 +0100, Christoph Hellwig wrote: >> On Mon, Jan 16, 2023 at 09:52:10AM +0100, John Paul Adrian Glaubitz wrote: >>> We have had a discussion between multiple people invested in the SuperH >>> port and >>> I have decided to volunteer as a co-maintainer of the port to support Rich >>> Felker >>> when he isn't available. >> >> So, this still isn't reflected in MAINTAINERS in linux-next. When >> do you plan to take over? What platforms will remain supported and >> what can we start dropping due to being unused and unmaintained? > > I'm getting everything ready now with Geert's help and I have a probably dumb > question regarding the MAINTAINERS file change: Shall I just add myself as an > additional maintainer first or shall I also drop Yoshinori Sato? > > Also, is it desirable to add a "T:" entry for the kernel tree? Yes, definitely. thanks. -- ~Randy
Re: remove arch/sh
Hello Christoph! On Fri, 2023-02-03 at 08:14 +0100, Christoph Hellwig wrote: > On Mon, Jan 16, 2023 at 09:52:10AM +0100, John Paul Adrian Glaubitz wrote: > > We have had a discussion between multiple people invested in the SuperH > > port and > > I have decided to volunteer as a co-maintainer of the port to support Rich > > Felker > > when he isn't available. > > So, this still isn't reflected in MAINTAINERS in linux-next. When > do you plan to take over? What platforms will remain supported and > what can we start dropping due to being unused and unmaintained? I'm getting everything ready now with Geert's help and I have a probably dumb question regarding the MAINTAINERS file change: Shall I just add myself as an additional maintainer first or shall I also drop Yoshinori Sato? Also, is it desirable to add a "T:" entry for the kernel tree? Thanks, Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
Hi Stephen! On Mon, 2023-02-06 at 10:08 +1100, Stephen Rothwell wrote: > Hi, > > On Fri, 3 Feb 2023 09:30:37 +0100 Christoph Hellwig wrote: > > > > On Fri, Feb 03, 2023 at 09:24:46AM +0100, John Paul Adrian Glaubitz wrote: > > > Since this is my very first time stepping up as a kernel maintainer, I > > > was hoping > > > to get some pointers on what to do to make this happen. > > > > > > So far, we have set up a new kernel tree and I have set up a local > > > development and > > > test environment for SH kernels using my SH7785LCR board as the target > > > platform. > > > > > > Do I just need to send a patch asking to change the corresponding entry > > > in the > > > MAINTAINERS file? > > > > I'm not sure a there is a document, but: > > > > - add the MAINTAINERS change to your tree > > - ask Stephen to get your tree included in linux-next > > And by "Stephen", Christoph means me. When you are ready, please send > me a request to include your tree/branch in linux-next (usually the > branch is called something like "for-next" or just "next") telling me > the git URL, and the contacts I should send email to if there are > conflicts/build issues with the branch. I will then fetch the branch > every time I create a new linux-next release (most work days), so all > you need to do is update that branch each time you are ready to publish > more commits. Thanks a lot! I will start with that tomorrow with Geert giving me some guidance. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
Hi, On Fri, 3 Feb 2023 09:30:37 +0100 Christoph Hellwig wrote: > > On Fri, Feb 03, 2023 at 09:24:46AM +0100, John Paul Adrian Glaubitz wrote: > > Since this is my very first time stepping up as a kernel maintainer, I was > > hoping > > to get some pointers on what to do to make this happen. > > > > So far, we have set up a new kernel tree and I have set up a local > > development and > > test environment for SH kernels using my SH7785LCR board as the target > > platform. > > > > Do I just need to send a patch asking to change the corresponding entry in > > the > > MAINTAINERS file? > > I'm not sure a there is a document, but: > > - add the MAINTAINERS change to your tree > - ask Stephen to get your tree included in linux-next And by "Stephen", Christoph means me. When you are ready, please send me a request to include your tree/branch in linux-next (usually the branch is called something like "for-next" or just "next") telling me the git URL, and the contacts I should send email to if there are conflicts/build issues with the branch. I will then fetch the branch every time I create a new linux-next release (most work days), so all you need to do is update that branch each time you are ready to publish more commits. -- Cheers, Stephen Rothwell pgpMJEDRfhR5G.pgp Description: OpenPGP digital signature
Re: remove arch/sh
Hi Randy,
On Fri, Feb 3, 2023 at 4:57 PM Randy Dunlap wrote:
> Is this "sh64" still accurate and applicable? from
> Documentation/kbuild/kbuild.rst:
>
> But some architectures such as x86 and sparc have aliases.
>
> - x86: i386 for 32 bit, x86_64 for 64 bit
> - sh: sh for 32 bit, sh64 for 64 bit <<<
> - sparc: sparc32 for 32 bit, sparc64 for 64 bit
No, support for sh64 was removed in commit 37744feebc086908
("sh: remove sh5 support") in v5.8.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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: remove arch/sh
Hi-- On 2/3/23 02:33, Geert Uytterhoeven wrote: > Hi Adrian, > > On Fri, Feb 3, 2023 at 11:29 AM John Paul Adrian Glaubitz > wrote: >> On Fri, 2023-02-03 at 09:30 +0100, Christoph Hellwig wrote: >>> On Fri, Feb 03, 2023 at 09:24:46AM +0100, John Paul Adrian Glaubitz wrote: Since this is my very first time stepping up as a kernel maintainer, I was hoping to get some pointers on what to do to make this happen. So far, we have set up a new kernel tree and I have set up a local development and test environment for SH kernels using my SH7785LCR board as the target platform. Do I just need to send a patch asking to change the corresponding entry in the MAINTAINERS file? >>> >>> I'm not sure a there is a document, but: >>> >>> - add the MAINTAINERS change to your tree >>> - ask Stephen to get your tree included in linux-next >>> >>> then eventually send a pull request to Linus with all of that. Make >>> sure it's been in linux-next for a while. >> >> OK, thanks for the pointers! Will try to get this done by next week. >> >> We're still discussing among SuperH developer community whether there will >> be a second >> maintainer, so please bear with us a few more days. I will collect patches >> in the >> meantime. > > Thanks a lot! > > If you need any help with process, setup, ... don't hesitate to ask > (on e.g. #renesas-soc on Libera). While Adrian and Geert are reading this, I have a question: Is this "sh64" still accurate and applicable? from Documentation/kbuild/kbuild.rst: But some architectures such as x86 and sparc have aliases. - x86: i386 for 32 bit, x86_64 for 64 bit - sh: sh for 32 bit, sh64 for 64 bit <<< - sparc: sparc32 for 32 bit, sparc64 for 64 bit Thanks. -- ~Randy
Re: remove arch/sh
Hi Geert! On Fri, 2023-02-03 at 11:33 +0100, Geert Uytterhoeven wrote: > Hi Adrian, > > On Fri, Feb 3, 2023 at 11:29 AM John Paul Adrian Glaubitz > wrote: > > On Fri, 2023-02-03 at 09:30 +0100, Christoph Hellwig wrote: > > > On Fri, Feb 03, 2023 at 09:24:46AM +0100, John Paul Adrian Glaubitz wrote: > > > > Since this is my very first time stepping up as a kernel maintainer, I > > > > was hoping > > > > to get some pointers on what to do to make this happen. > > > > > > > > So far, we have set up a new kernel tree and I have set up a local > > > > development and > > > > test environment for SH kernels using my SH7785LCR board as the target > > > > platform. > > > > > > > > Do I just need to send a patch asking to change the corresponding entry > > > > in the > > > > MAINTAINERS file? > > > > > > I'm not sure a there is a document, but: > > > > > > - add the MAINTAINERS change to your tree > > > - ask Stephen to get your tree included in linux-next > > > > > > then eventually send a pull request to Linus with all of that. Make > > > sure it's been in linux-next for a while. > > > > OK, thanks for the pointers! Will try to get this done by next week. > > > > We're still discussing among SuperH developer community whether there will > > be a second > > maintainer, so please bear with us a few more days. I will collect patches > > in the > > meantime. > > Thanks a lot! > > If you need any help with process, setup, ... don't hesitate to ask > (on e.g. #renesas-soc on Libera). Thanks a lot! I've got some real-life tasks to do today, but I will join later today. And I will ask questions ;-). Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
Hi Adrian,
On Fri, Feb 3, 2023 at 11:29 AM John Paul Adrian Glaubitz
wrote:
> On Fri, 2023-02-03 at 09:30 +0100, Christoph Hellwig wrote:
> > On Fri, Feb 03, 2023 at 09:24:46AM +0100, John Paul Adrian Glaubitz wrote:
> > > Since this is my very first time stepping up as a kernel maintainer, I
> > > was hoping
> > > to get some pointers on what to do to make this happen.
> > >
> > > So far, we have set up a new kernel tree and I have set up a local
> > > development and
> > > test environment for SH kernels using my SH7785LCR board as the target
> > > platform.
> > >
> > > Do I just need to send a patch asking to change the corresponding entry
> > > in the
> > > MAINTAINERS file?
> >
> > I'm not sure a there is a document, but:
> >
> > - add the MAINTAINERS change to your tree
> > - ask Stephen to get your tree included in linux-next
> >
> > then eventually send a pull request to Linus with all of that. Make
> > sure it's been in linux-next for a while.
>
> OK, thanks for the pointers! Will try to get this done by next week.
>
> We're still discussing among SuperH developer community whether there will be
> a second
> maintainer, so please bear with us a few more days. I will collect patches in
> the
> meantime.
Thanks a lot!
If you need any help with process, setup, ... don't hesitate to ask
(on e.g. #renesas-soc on Libera).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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: remove arch/sh
Hi Christoph! On Fri, 2023-02-03 at 09:30 +0100, Christoph Hellwig wrote: > On Fri, Feb 03, 2023 at 09:24:46AM +0100, John Paul Adrian Glaubitz wrote: > > Since this is my very first time stepping up as a kernel maintainer, I was > > hoping > > to get some pointers on what to do to make this happen. > > > > So far, we have set up a new kernel tree and I have set up a local > > development and > > test environment for SH kernels using my SH7785LCR board as the target > > platform. > > > > Do I just need to send a patch asking to change the corresponding entry in > > the > > MAINTAINERS file? > > I'm not sure a there is a document, but: > > - add the MAINTAINERS change to your tree > - ask Stephen to get your tree included in linux-next > > then eventually send a pull request to Linus with all of that. Make > sure it's been in linux-next for a while. OK, thanks for the pointers! Will try to get this done by next week. We're still discussing among SuperH developer community whether there will be a second maintainer, so please bear with us a few more days. I will collect patches in the meantime. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
Hello Christoph! On Fri, 2023-02-03 at 08:14 +0100, Christoph Hellwig wrote: > On Mon, Jan 16, 2023 at 09:52:10AM +0100, John Paul Adrian Glaubitz wrote: > > We have had a discussion between multiple people invested in the SuperH > > port and > > I have decided to volunteer as a co-maintainer of the port to support Rich > > Felker > > when he isn't available. > > So, this still isn't reflected in MAINTAINERS in linux-next. When > do you plan to take over? Since this is my very first time stepping up as a kernel maintainer, I was hoping to get some pointers on what to do to make this happen. So far, we have set up a new kernel tree and I have set up a local development and test environment for SH kernels using my SH7785LCR board as the target platform. Do I just need to send a patch asking to change the corresponding entry in the MAINTAINERS file? > What platforms will remain supported and what can we start dropping due to > being unused and unmaintained? This has not been sorted out yet. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
On 1/18/23 01:46, Geert Uytterhoeven wrote: > Again, I think you're talking about something different. > Does kexec work for you? Sorry, got woken up several hours early by sirens and flashy lights this morning (duplex on the corner caught fire, Austin has a LOT of emergency vehicles), been a bit underclocked all day. No, I haven't tried kexec on sh4. I'll add it to the todo heap. >> > I tried working my way up from 2.6.22, but gave up around 2.6.29. >> > Probably I should do this with r2d and qemu instead ;-) >> >> I have current running there. I've had current running there for years. >> Config >> attached... >> >> > Both r2d and landisk are SH7751. >> >> Cool. Shouldn't be hard to get landisk running current then. > > Current kernels work fine on landisk with an old Debian userspace > on CF. The 8139cp driver is a bit flaky: last time I tried nfsroot, > that didn't work well. I've never had luck with NFS, I was using NBD. Hadn't noticed the flake but haven't stress tested it too hard either? Mostly new userspace is what I'm testing... Rob
Re: remove arch/sh
> Since there are people around with real hardware is sh in big endian mode > (sheb) real ? Its qemu support is quite limited; most PCI devices don't work > due to endianness issues. It would be interesting to know if this works better > with real hardware. Hi Guenter, SH big endian works very well, and is in use on J-Core J2 SMP (hardware w/FPGA, simulation and ASIC this year) as well as some of the Hitachi / Renesas IoT chips e.g. SH7619. It’s the base of the real new line of development (as opposed to backward looking support of older SH chips). New chipsets will be based on the same RTL. But does it actually work? Yes, we have (new) devices such as a USB Wireguard based VPN hardware dongle, that are J2 (SH2 2 core SMP) that are in use with Linux sheb, nommu and fdpic. MMU chips will be little endian. Cheers, J. > Thanks, > Guenter >
Re: remove arch/sh
Hi Rob,
On Wed, Jan 18, 2023 at 5:50 AM Rob Landley wrote:
> On 1/17/23 14:26, Geert Uytterhoeven wrote:
> > On Tue, Jan 17, 2023 at 8:01 PM Rob Landley wrote:
> >> I'm lazy and mostly test each new sh4 build under qemu -M r2d because it's
> >> really convenient: neither of my physical boards boot from SD card so
> >> replacing
> >> the kernel requires reflashing soldered in flash. (They'll net mount
> >> userspace
> >> but I haven't gotten either bootloader to net-boot a kernel.)
> >
> > On my landisk (with boots from CompactFLASH), I boot the original 2.6.22
> > kernel, and use kexec to boot-test each and every renesas-drivers
> > release. Note that this requires both the original 2.6.22 kernel
> > and matching kexec-tools.
>
> I make it a point to run _current_ kernels in all my mkroot systems, including
> sh4. What I shipped was 6.1 is:
>
> # cat /proc/version
> Linux version 6.1.0 (landley@driftwood) (sh4-linux-musl-cc (GCC) 9.4.0, GNU ld
> (GNU Binutils) 2.33.1) #1 Tue Jan 10 16:32:07 CST 2023
I think you misunderstood: renesas-drivers releases[1] are current
kernels.
Linux version 6.2.0-rc3-landisk-01864-g0c6453b3e5f6 (geert@rox)
(sh4-linux-gnu-gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0, GNU ld (GNU
Binutils for Ubuntu) 2.38) #125 Tue Jan 10 14:29:01 CET 2023
I use 2.6.22 and kexec as a boot loader for newer kernels, to avoid
juggling CF cards. I cannot install a newer base kernel on the CF,
as kexec is broken upstream.
> > Apparently both upstreamed kernel and
> > kexec-tools support for SH are different, and incompatible with each
> > other, so you cannot kexec from a contemporary kernel.
>
> Sure you can. Using toybox's insmod and modprobe, anyway. (That's the target I
> tested those on... :)
>
> Haven't messed with signing or compression or anything yet, my insmod is just
> doing syscall(SYS_finit_module) and then falling back to SYS_init_module if
> that
> fails and either fd was 0 or errno was ENOSYS. (Don't ask me why
> SYS_finit_module doesn't work on stdin...)
>
> https://github.com/landley/toybox/blob/master/toys/other/insmod.c#L31
>
> https://landley.net/toybox/downloads/binaries/0.8.9/toybox-sh4
Again, I think you're talking about something different.
Does kexec work for you?
> > I tried working my way up from 2.6.22, but gave up around 2.6.29.
> > Probably I should do this with r2d and qemu instead ;-)
>
> I have current running there. I've had current running there for years. Config
> attached...
>
> > Both r2d and landisk are SH7751.
>
> Cool. Shouldn't be hard to get landisk running current then.
Current kernels work fine on landisk with an old Debian userspace
on CF. The 8139cp driver is a bit flaky: last time I tried nfsroot,
that didn't work well.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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: remove arch/sh
On 1/17/23 14:26, Geert Uytterhoeven wrote: > Hi Rob, > > On Tue, Jan 17, 2023 at 8:01 PM Rob Landley wrote: >> On 1/16/23 01:13, Christoph Hellwig wrote: >> > On Fri, Jan 13, 2023 at 09:09:52AM +0100, John Paul Adrian Glaubitz wrote: >> >> I'm still maintaining and using this port in Debian. >> >> >> >> It's a bit disappointing that people keep hammering on it. It works fine >> >> for me. >> > >> > What platforms do you (or your users) use it on? >> >> 3 j-core boards, two sh4 boards (the sh7760 one I patched the kernel of), >> and an >> sh4 emulator. >> >> I have multiple j-core systems (sh2 compatible with extensions, nommu, 3 >> different kinds of boards running it here). There's an existing mmu version >> of >> j-core that's sh3 flavored but they want to redo it so it hasn't been >> publicly >> released yet, I have yet to get that to run Linux because the mmu code would >> need adapting, but the most recent customer projects were on the existing >> nommu >> SOC, as was last year's ASIC work via sky130. > > J4 still vaporware? The 'existing mmu version' is the theoretical basis for J4 (the move from J3 to J4 is tiny from an instruction set perspective, it was more about internal chip architecture, primarily multi-issue with tomasulo). It exists, but we haven't had a product that uses it and the engineer who was tasked to work on it got reassigned during the pandemic. The real problem is the existing implementation is a branch off of an older SOC version so repotting it to the current tree (which among other things builds under a different VHDL toolchain) is some work. The "conflict requiring actual staring at" isn't the MMU, it's the instruction cancellation logic that backs out half-finished instructions when the MMU complains partway through an instruction that's multiple steps of microcode, so we have to back _out_ what it's already done so it can be cleanly restarted after handling the fault. That's got merge conflicts all over the place with the current stuff... Not actually _hard_, but not something we've sat down and done. We spent those cycles last year working on an ASIC implementation through Google's Sky130 OpenLane/OpenRoad stuff (see https://github.com/j-core/openlane-vhdl-build for our in-house toolchain build for that; Google passes around a magic docker that most people use, we trimmed off most of the dependencies and build it in a clean debootstrap). And that was trying to make an ASIC out of the small simple version, because Google's entire asic/skywater partnership was... fraught? We also tried to get the previous generation of ASIC tools to work before giving up and trying to get what Google was working on to work: https://landley.net/notes-2022.html#26-01-2022 https://landley.net/notes-2022.html#28-01-2022 We targeted "known working SOC that we've been using a long time" to try to make a physical silicon chip out of (and the first version isn't even the J2 2xSMP SOC with all the cache and peripherals, it was a derivative of the ICE40 port that's single processor running straight from SRAM with no DRAM controller), on the theory we can always do a more complicated one later an what we were really trying to establish here is that Google's ASIC development tools and process could be made to work. (Which is kind of a heavy lift, they burned two shuttles full of mostly dead chips that we know of before admitting "those timing annotations we were talking about actually DO need to go all the way through"... Jeff has the URLs to the bug reports in OpenLane/Road's github...) (Sorry, one of OpenLane/OpenRoad is the DARPA project out of Sandia National Laboratory, and the other is Google doing a large extremely complicated thing analogous to the AOSP build on top of Darpa's work using a lot different programming languages and FOREST of build and runtime package dependencies, and I can never remember which is which. The Google thing is the one distributed in a docker because it's considered impossible to build rom source by everybody except us, because we're funny that way. And added VHDL support instead of just Verilog so needed to rebuild from source anyway to do that.) >> My physical sh4 boards are a Johnson Controls N40 (sh7760 chipset) and the >> little blue one is... sh4a I think? (It can run the same userspace, I haven't >> replaced that board's kernel since I got it, I think it's the type Glaubitz >> is >> using? It's mostly in case he had an issue I couldn't reproduce on different >> hardware, or if I spill something on my N40.) >> >> I also have a physical sh2 board on the shelf which I haven't touched in >> years >> (used to comparison test during j2 development, and then the j2 boards >> replaced it). >> >> I'm lazy and mostly test each new sh4 build under qemu -M r2d because it's >> really convenient: neither of my physical boards boot from SD card so >> replacing >> the kernel requires reflashing soldered in flash. (They'll net mount >> userspace >>
Re: remove arch/sh
On 1/17/23 12:26, Geert Uytterhoeven wrote: Hi Rob, On Tue, Jan 17, 2023 at 8:01 PM Rob Landley wrote: On 1/16/23 01:13, Christoph Hellwig wrote: On Fri, Jan 13, 2023 at 09:09:52AM +0100, John Paul Adrian Glaubitz wrote: I'm still maintaining and using this port in Debian. It's a bit disappointing that people keep hammering on it. It works fine for me. What platforms do you (or your users) use it on? 3 j-core boards, two sh4 boards (the sh7760 one I patched the kernel of), and an sh4 emulator. I have multiple j-core systems (sh2 compatible with extensions, nommu, 3 different kinds of boards running it here). There's an existing mmu version of j-core that's sh3 flavored but they want to redo it so it hasn't been publicly released yet, I have yet to get that to run Linux because the mmu code would need adapting, but the most recent customer projects were on the existing nommu SOC, as was last year's ASIC work via sky130. J4 still vaporware? My physical sh4 boards are a Johnson Controls N40 (sh7760 chipset) and the little blue one is... sh4a I think? (It can run the same userspace, I haven't replaced that board's kernel since I got it, I think it's the type Glaubitz is using? It's mostly in case he had an issue I couldn't reproduce on different hardware, or if I spill something on my N40.) I also have a physical sh2 board on the shelf which I haven't touched in years (used to comparison test during j2 development, and then the j2 boards replaced it). I'm lazy and mostly test each new sh4 build under qemu -M r2d because it's really convenient: neither of my physical boards boot from SD card so replacing the kernel requires reflashing soldered in flash. (They'll net mount userspace but I haven't gotten either bootloader to net-boot a kernel.) On my landisk (with boots from CompactFLASH), I boot the original 2.6.22 kernel, and use kexec to boot-test each and every renesas-drivers release. Note that this requires both the original 2.6.22 kernel and matching kexec-tools. Apparently both upstreamed kernel and kexec-tools support for SH are different, and incompatible with each other, so you cannot kexec from a contemporary kernel. I tried working my way up from 2.6.22, but gave up around 2.6.29. Probably I should do this with r2d and qemu instead ;-) Both r2d and landisk are SH7751. Probably SH7722/'23'24 (e.g. Migo-R and Ecovec boards) are also worth keeping. Most on-SoC blocks have drivers with DT support, as they are shared with ARM. So the hardest part is clock and interrupt-controller support. Unfortunately I no longer have access to the (remote) Migo-R. Since there are people around with real hardware is sh in big endian mode (sheb) real ? Its qemu support is quite limited; most PCI devices don't work due to endianness issues. It would be interesting to know if this works better with real hardware. Thanks, Guenter
Re: remove arch/sh
Hi Rob,
On Tue, Jan 17, 2023 at 8:01 PM Rob Landley wrote:
> On 1/16/23 01:13, Christoph Hellwig wrote:
> > On Fri, Jan 13, 2023 at 09:09:52AM +0100, John Paul Adrian Glaubitz wrote:
> >> I'm still maintaining and using this port in Debian.
> >>
> >> It's a bit disappointing that people keep hammering on it. It works fine
> >> for me.
> >
> > What platforms do you (or your users) use it on?
>
> 3 j-core boards, two sh4 boards (the sh7760 one I patched the kernel of), and
> an
> sh4 emulator.
>
> I have multiple j-core systems (sh2 compatible with extensions, nommu, 3
> different kinds of boards running it here). There's an existing mmu version of
> j-core that's sh3 flavored but they want to redo it so it hasn't been publicly
> released yet, I have yet to get that to run Linux because the mmu code would
> need adapting, but the most recent customer projects were on the existing
> nommu
> SOC, as was last year's ASIC work via sky130.
J4 still vaporware?
> My physical sh4 boards are a Johnson Controls N40 (sh7760 chipset) and the
> little blue one is... sh4a I think? (It can run the same userspace, I haven't
> replaced that board's kernel since I got it, I think it's the type Glaubitz is
> using? It's mostly in case he had an issue I couldn't reproduce on different
> hardware, or if I spill something on my N40.)
>
> I also have a physical sh2 board on the shelf which I haven't touched in years
> (used to comparison test during j2 development, and then the j2 boards
> replaced it).
>
> I'm lazy and mostly test each new sh4 build under qemu -M r2d because it's
> really convenient: neither of my physical boards boot from SD card so
> replacing
> the kernel requires reflashing soldered in flash. (They'll net mount userspace
> but I haven't gotten either bootloader to net-boot a kernel.)
On my landisk (with boots from CompactFLASH), I boot the original 2.6.22
kernel, and use kexec to boot-test each and every renesas-drivers
release. Note that this requires both the original 2.6.22 kernel
and matching kexec-tools. Apparently both upstreamed kernel and
kexec-tools support for SH are different, and incompatible with each
other, so you cannot kexec from a contemporary kernel.
I tried working my way up from 2.6.22, but gave up around 2.6.29.
Probably I should do this with r2d and qemu instead ;-)
Both r2d and landisk are SH7751.
Probably SH7722/'23'24 (e.g. Migo-R and Ecovec boards) are also
worth keeping. Most on-SoC blocks have drivers with DT support,
as they are shared with ARM. So the hardest part is clock and
interrupt-controller support.
Unfortunately I no longer have access to the (remote) Migo-R.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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: remove arch/sh
On 1/16/23 01:13, Christoph Hellwig wrote: > On Fri, Jan 13, 2023 at 09:09:52AM +0100, John Paul Adrian Glaubitz wrote: >> I'm still maintaining and using this port in Debian. >> >> It's a bit disappointing that people keep hammering on it. It works fine for >> me. > > What platforms do you (or your users) use it on? 3 j-core boards, two sh4 boards (the sh7760 one I patched the kernel of), and an sh4 emulator. I have multiple j-core systems (sh2 compatible with extensions, nommu, 3 different kinds of boards running it here). There's an existing mmu version of j-core that's sh3 flavored but they want to redo it so it hasn't been publicly released yet, I have yet to get that to run Linux because the mmu code would need adapting, but the most recent customer projects were on the existing nommu SOC, as was last year's ASIC work via sky130. My physical sh4 boards are a Johnson Controls N40 (sh7760 chipset) and the little blue one is... sh4a I think? (It can run the same userspace, I haven't replaced that board's kernel since I got it, I think it's the type Glaubitz is using? It's mostly in case he had an issue I couldn't reproduce on different hardware, or if I spill something on my N40.) I also have a physical sh2 board on the shelf which I haven't touched in years (used to comparison test during j2 development, and then the j2 boards replaced it). I'm lazy and mostly test each new sh4 build under qemu -M r2d because it's really convenient: neither of my physical boards boot from SD card so replacing the kernel requires reflashing soldered in flash. (They'll net mount userspace but I haven't gotten either bootloader to net-boot a kernel.) I include sh4 in the my mkroot builds each toybox release, I have a ~300 line bash script that builds bootable toybox systems for a dozen-ish architectures, including building a kernel configured to run under qemu: https://github.com/landley/toybox/blob/master/scripts/mkroot.sh And I ship the resulting bootable system images, most recent release is at: https://landley.net/toybox/downloads/binaries/mkroot/0.8.9/ As described at: http://landley.net/toybox/faq.html#mkroot Various people in Japan have more hardware, but I haven't made it physically back there since 2020. (My residency card expired during the pandemic.) Rob
Re: remove arch/sh
Hello Christoph! On 1/16/23 08:13, Christoph Hellwig wrote: On Fri, Jan 13, 2023 at 09:09:52AM +0100, John Paul Adrian Glaubitz wrote: I'm still maintaining and using this port in Debian. It's a bit disappointing that people keep hammering on it. It works fine for me. What platforms do you (or your users) use it on? We have had a discussion between multiple people invested in the SuperH port and I have decided to volunteer as a co-maintainer of the port to support Rich Felker when he isn't available. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
On 1/13/23 13:05, John Paul Adrian Glaubitz wrote: > Hi Rob! > > On 1/13/23 20:11, Rob Landley wrote: >> There is definitely interest in this architecture. I'm aware Rich hasn't been >> the most responsive maintainer. (I'm told he's on vacation with his family at >> the moment, according to the text I got about this issue from the J-core >> hardware guys in Japan.) > > Well, maybe we can just give it a try together ... Jeff Dionne said he'd make himself available to answer hardware questions. (He said he maintained some Linux ports 20 years ago, but isn't current with Linux plumbing. Last month he was digging through the guts of vxworks, and the project before that was some sort of BSD I think?) I _do_ maintain Linux patches, I just generally don't bother to repost them endlessly. Here's my "on top of 6.1" stack for example, each of which links to at least one time it was posted to linux-kernel: https://landley.net/toybox/downloads/binaries/mkroot/0.8.9/linux-patches/ >> The main reason we haven't converted everything to device tree is we only >> have >> access to test hardware for a subset of the boards. Pruning the list of >> supported boards and converting the rest to device tree might make sense. We >> can >> always add/convert boards back later... > > There is a patch by Yoshinori Sato which adds device tree support to SH. > Maybe we > can revive it. The turtle board is device tree and has been since it was merged. The infrastructure is there, the question is converting over boards and testing them, or deciding to prune them. Did Sato-san convert many boards? (I'm not finding his patch via google...) > Adrian Rob
Re: remove arch/sh
On 1/13/23 02:52, John Paul Adrian Glaubitz wrote: > Hi Geert! > > On 1/13/23 09:26, Geert Uytterhoeven wrote: >> Indeed. The main issue is not the lack of people sending patches and >> fixes, but those patches never being applied by the maintainers. >> Perhaps someone is willing to stand up to take over maintainership? > > I actually would be willing to do it but I'm a bit hesitant as I'm not 100% > sure my skills are sufficient. Maybe if someone can assist me? My skills aren't sufficient and I dunno how much time I have, but I can certainly assist. I test sh4 regularlyish and it's in the list of architectures I ship binaries and tiny VM images for, just refreshed tuesday: https://landley.net/toybox/downloads/binaries/0.8.9/ https://landley.net/toybox/downloads/binaries/mkroot/0.8.9/ (The sh2eb isn't a VM, it's a physical board I have here...) There is definitely interest in this architecture. I'm aware Rich hasn't been the most responsive maintainer. (I'm told he's on vacation with his family at the moment, according to the text I got about this issue from the J-core hardware guys in Japan.) The main reason we haven't converted everything to device tree is we only have access to test hardware for a subset of the boards. Pruning the list of supported boards and converting the rest to device tree might make sense. We can always add/convert boards back later... Rob
Re: remove arch/sh
Hi Rob! On 1/13/23 20:11, Rob Landley wrote: I actually would be willing to do it but I'm a bit hesitant as I'm not 100% sure my skills are sufficient. Maybe if someone can assist me? My skills aren't sufficient and I dunno how much time I have, but I can certainly assist. I test sh4 regularlyish and it's in the list of architectures I ship binaries and tiny VM images for, just refreshed tuesday: https://landley.net/toybox/downloads/binaries/0.8.9/ https://landley.net/toybox/downloads/binaries/mkroot/0.8.9/ (The sh2eb isn't a VM, it's a physical board I have here...) There is definitely interest in this architecture. I'm aware Rich hasn't been the most responsive maintainer. (I'm told he's on vacation with his family at the moment, according to the text I got about this issue from the J-core hardware guys in Japan.) Well, maybe we can just give it a try together ... The main reason we haven't converted everything to device tree is we only have access to test hardware for a subset of the boards. Pruning the list of supported boards and converting the rest to device tree might make sense. We can always add/convert boards back later... There is a patch by Yoshinori Sato which adds device tree support to SH. Maybe we can revive it. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
On Fri, Jan 13, 2023 at 07:23:17AM +0100, Christoph Hellwig wrote: > Hi all, > > arch/sh has been a long drag because it supports a lot of SOCs, and most > of them haven't even been converted to device tree infrastructure. These > SOCs are generally obsolete as well, and all of the support has been barely > maintained for almost 10 years, and not at all for more than 1 year. > > Drop arch/sh and everything that depends on it. > > Diffstat: > Documentation/sh/booting.rst | 12 > Documentation/sh/features.rst|3 > Documentation/sh/index.rst | 56 > Documentation/sh/new-machine.rst | 277 - > Documentation/sh/register-banks.rst | 40 Can you please also remove: Documentation/devicetree/bindings/mtd/flctl-nand.txt Documentation/devicetree/bindings/interrupt-controller/jcore,aic.txt Documentation/devicetree/bindings/spi/jcore,spi.txt Documentation/devicetree/bindings/timer/jcore,pit.txt Rob
Re: remove arch/sh
Hi Geert! On 1/13/23 09:26, Geert Uytterhoeven wrote: Indeed. The main issue is not the lack of people sending patches and fixes, but those patches never being applied by the maintainers. Perhaps someone is willing to stand up to take over maintainership? I actually would be willing to do it but I'm a bit hesitant as I'm not 100% sure my skills are sufficient. Maybe if someone can assist me? Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
Re: remove arch/sh
On Fri, Jan 13, 2023 at 9:10 AM John Paul Adrian Glaubitz
wrote:
> On 1/13/23 07:23, Christoph Hellwig wrote:
> > arch/sh has been a long drag because it supports a lot of SOCs, and most
> > of them haven't even been converted to device tree infrastructure. These
> > SOCs are generally obsolete as well, and all of the support has been barely
> > maintained for almost 10 years, and not at all for more than 1 year.
> >
> > Drop arch/sh and everything that depends on it.
>
> I'm still maintaining and using this port in Debian.
>
> It's a bit disappointing that people keep hammering on it. It works fine for
> me.
Indeed. The main issue is not the lack of people sending patches and
fixes, but those patches never being applied by the maintainers.
Perhaps someone is willing to stand up to take over maintainership?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@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: remove arch/sh
Hello! On 1/13/23 07:23, Christoph Hellwig wrote: arch/sh has been a long drag because it supports a lot of SOCs, and most of them haven't even been converted to device tree infrastructure. These SOCs are generally obsolete as well, and all of the support has been barely maintained for almost 10 years, and not at all for more than 1 year. Drop arch/sh and everything that depends on it. I'm still maintaining and using this port in Debian. It's a bit disappointing that people keep hammering on it. It works fine for me. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer `. `' Physicist `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
