Message ID | 9a6b730fc6c8e70ff034e2e3665478ec31858c29.camel@physik.fu-berlin.de (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Series | [GIT,PULL] sh updates for v6.5 | expand |
The pull request you sent on Wed, 05 Jul 2023 23:43:44 +0200:
> git://git.kernel.org/pub/scm/linux/kernel/git/glaubitz/sh-linux.git tags/sh-for-v6.5-tag1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/c17414a273b81fe4e34e11d69fc30cc8b1431614
Thank you!
On 7/5/23 14:43, John Paul Adrian Glaubitz wrote: > Hi Linus! > > I am being a little late this merge window since it took me a little longer > to thoroughly review the changes which address important issues in the DMA > and IRQ code in arch/sh. > > The pull request includes a patch by me to fix a compiler warning in the J2 > probing code and a fix by Sergey Shtylyov to avoid using IRQ0 on SH3 and SH4 > targets. Masahiro Yamada made some clean-up in the build system to address > reports by the 0day bot. > > The most notable changes come from Artur Rojek who addressed a number of issues > in the DMA code, in particular a fix for the DMA channel offset calculation that > was introduced in in 7f47c7189b3e ("sh: dma: More legacy cpu dma chainsawing.") > in 2012! Together with another change to correct the number of DMA channels for > each SuperH SoC according to specification, Artur's series unbreaks the kernel > on the SH7709 SoC allowing Linux to boot on the HP Jornada 680 handheld again. > > Last but not least, Guenter Roeck sent in a patch to fix a build regression that > was recently introduced in 99b619b37ae1 ("mips: provide unxlate_dev_mem_ptr() in > asm/io.h"). > > The following changes since commit ac9a78681b921877518763ba0e89202254349d1b: > > Linux 6.4-rc1 (2023-05-07 13:34:35 -0700) > > are available in the Git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/glaubitz/sh-linux.git tags/sh-for-v6.5-tag1 > > for you to fetch changes up to 7497840d462c8f54c4888c22ab3726a8cde4b9a2: > > sh: Provide unxlate_dev_mem_ptr() in asm/io.h (2023-07-05 19:04:51 +0200) > > Thanks for pulling! > > Adrian > > ---------------------------------------------------------------- > sh updates for v6.5 > > - sh: Provide unxlate_dev_mem_ptr() in asm/io.h > - sh: dma: Correct the number of DMA channels for SH7709 > - sh: dma: Drop incorrect SH_DMAC_BASE1 definition for SH4 > - sh: dma: Fix DMA channel offset calculation > - sh: Remove compiler flag duplication > - sh: Refactor header include path addition > - sh: Move build rule for cchips/hd6446x/ to arch/sh/Kbuild > - sh: Fix -Wmissing-include-dirs warnings for various platforms > - sh: Avoid using IRQ0 on SH3 and SH4 > - sh: j2: Use ioremap() to translate device tree address into kernel memory > > ---------------------------------------------------------------- > Artur Rojek (3): > sh: dma: Fix DMA channel offset calculation > sh: dma: Drop incorrect SH_DMAC_BASE1 definition for SH4 > sh: dma: Correct the number of DMA channels for SH7709 > > Guenter Roeck (1): > sh: Provide unxlate_dev_mem_ptr() in asm/io.h > Perfect example why it is a bad idea to let build failures linger around. The build failure fixed by this patch ... > John Paul Adrian Glaubitz (1): > sh: j2: Use ioremap() to translate device tree address into kernel memory > > Masahiro Yamada (4): > sh: Fix -Wmissing-include-dirs warnings for various platforms > sh: Move build rule for cchips/hd6446x/ to arch/sh/Kbuild > sh: Refactor header include path addition > sh: Remove compiler flag duplication > > Sergey Shtylyov (1): > sh: Avoid using IRQ0 on SH3 and SH4 > ... was hiding boot failures with all my qemu emulations caused by this patch. Guenter
On Thu, 2023-07-06 at 07:01 -0700, Guenter Roeck wrote: > Perfect example why it is a bad idea to let build failures linger around. > The build failure fixed by this patch ... How was that lingered around? Your patch was merged within less than a week. > > John Paul Adrian Glaubitz (1): > > sh: j2: Use ioremap() to translate device tree address into kernel memory > > > > Masahiro Yamada (4): > > sh: Fix -Wmissing-include-dirs warnings for various platforms > > sh: Move build rule for cchips/hd6446x/ to arch/sh/Kbuild > > sh: Refactor header include path addition > > sh: Remove compiler flag duplication > > > > Sergey Shtylyov (1): > > sh: Avoid using IRQ0 on SH3 and SH4 > > > ... was hiding boot failures with all my qemu emulations caused by > this patch. But Sergey's patch had been in my for-next tree since June 11 [1]. Adrian > [1] https://git.kernel.org/pub/scm/linux/kernel/git/glaubitz/sh-linux.git/log/?h=for-next
On 7/6/23 07:04, John Paul Adrian Glaubitz wrote: > On Thu, 2023-07-06 at 07:01 -0700, Guenter Roeck wrote: >> Perfect example why it is a bad idea to let build failures linger around. >> The build failure fixed by this patch ... > > How was that lingered around? Your patch was merged within less than a week. > The _build failure_ was lingering around, not my fix for it. >>> John Paul Adrian Glaubitz (1): >>> sh: j2: Use ioremap() to translate device tree address into kernel memory >>> >>> Masahiro Yamada (4): >>> sh: Fix -Wmissing-include-dirs warnings for various platforms >>> sh: Move build rule for cchips/hd6446x/ to arch/sh/Kbuild >>> sh: Refactor header include path addition >>> sh: Remove compiler flag duplication >>> >>> Sergey Shtylyov (1): >>> sh: Avoid using IRQ0 on SH3 and SH4 >>> >> ... was hiding boot failures with all my qemu emulations caused by >> this patch. > > But Sergey's patch had been in my for-next tree since June 11 [1]. > The build failure was introduced into linux-next with commit 99b619b37ae1. According to the commit log, that happened around June 9. Ever since then all sh builds in linux-next failed. Guenter
Hi John, thanks for taking up the sh maintainership! Any chance you could do an inventoy on which arch/sh/ platforms are currently working and maintained and which are just bitrot? sh still has a lot of platform specific code that feels іt is rotting, but some of that might just have been due to the lack of active maintainance. Once platform that I'm particulary interested in is dreamcast, which has a rather oddball block driver (gdrom) and some very odd interaction with the dma-mapping code.
On Thu, 2023-07-06 at 08:08 -0700, Guenter Roeck wrote: > The build failure was introduced into linux-next with commit 99b619b37ae1. > According to the commit log, that happened around June 9. Ever since then > all sh builds in linux-next failed. OK, then I need to subscribe to the CI notifications so I get notified about this error. I didn't get any notification and my for-next tree is always based on the last rc1. Adrian
Hi Christoph! On Thu, 2023-07-06 at 08:16 -0700, Christoph Hellwig wrote: > thanks for taking up the sh maintainership! You're welcome. > Any chance you could do an inventoy on which arch/sh/ platforms are > currently working and maintained and which are just bitrot? > > sh still has a lot of platform specific code that feels іt is rotting, > but some of that might just have been due to the lack of active > maintainance. I am slowly working towards getting everything back into shape. In particular, there is a patch set by Yoshinori Sato to convert arch/sh to device tree which I would like to eventually get upstreamed. However, since I am still new to kernel development, it will certainly take me a little more time until we're there. However, there is some interest in the community such as the J-Core people and Artur Rojek, so there are people who are willing to help me. > Once platform that I'm particulary interested in is dreamcast, which has > a rather oddball block driver (gdrom) and some very odd interaction with > the dma-mapping code. OK, thanks for the heads-up. I cannot comment on this yet, but I have a Dreamcast myself which I can use for testing in this case. Adrian
On 7/6/23 6:23 PM, John Paul Adrian Glaubitz wrote: [...] >> Any chance you could do an inventoy on which arch/sh/ platforms are >> currently working and maintained and which are just bitrot? >> >> sh still has a lot of platform specific code that feels іt is rotting, >> but some of that might just have been due to the lack of active >> maintainance. > > I am slowly working towards getting everything back into shape. In particular, > there is a patch set by Yoshinori Sato to convert arch/sh to device tree which > I would like to eventually get upstreamed. > > However, since I am still new to kernel development, it will certainly take > me a little more time until we're there. However, there is some interest > in the community such as the J-Core people and Artur Rojek, so there are people > who are willing to help me. Maybe we could start using the #linux-sh channel (again?) -- it's there, on Libera.chat, with couple persons hanging around... :-) [...] > Adrian MBR, Sergey
Hi! On Sun, 2023-07-09 at 00:25 +0300, Sergey Shtylyov wrote: > > However, since I am still new to kernel development, it will certainly take > > me a little more time until we're there. However, there is some interest > > in the community such as the J-Core people and Artur Rojek, so there are people > > who are willing to help me. > > Maybe we could start using the #linux-sh channel (again?) -- it's there, on > Libera.chat, with couple persons hanging around... :-) Most SuperH/J-Core people meet in #jcore on libera these days. Adrian
On 2023-07-08 23:49, John Paul Adrian Glaubitz wrote: > Hi! > > On Sun, 2023-07-09 at 00:25 +0300, Sergey Shtylyov wrote: >> > However, since I am still new to kernel development, it will certainly take >> > me a little more time until we're there. However, there is some interest >> > in the community such as the J-Core people and Artur Rojek, so there are people >> > who are willing to help me. >> >> Maybe we could start using the #linux-sh channel (again?) -- it's >> there, on >> Libera.chat, with couple persons hanging around... :-) > > Most SuperH/J-Core people meet in #jcore on libera these days. > > Adrian I am not sure if they welcome generic SuperH chat there, but I'm lurking in both channels already. Cheers, Artur