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
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
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
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: [PATCH 02/22] usb: remove the dead USB_OHCI_SH option
On 1/13/23 01:12, Greg Kroah-Hartman wrote: > On Fri, Jan 13, 2023 at 07:23:19AM +0100, Christoph Hellwig wrote: >> USB_OHCI_SH is a dummy option that never builds any code, remove it. >> >> Signed-off-by: Christoph Hellwig >> --- >> drivers/usb/host/Kconfig | 11 --- >> 1 file changed, 11 deletions(-) >> >> diff --git a/drivers/usb/host/Kconfig b/drivers/usb/host/Kconfig >> index 8d799d23c476e1..ca5f657c092cf4 100644 >> --- a/drivers/usb/host/Kconfig >> +++ b/drivers/usb/host/Kconfig >> @@ -548,17 +548,6 @@ config USB_OHCI_HCD_SSB >> >>If unsure, say N. >> >> -config USB_OHCI_SH >> -bool "OHCI support for SuperH USB controller (DEPRECATED)" >> -depends on SUPERH || COMPILE_TEST >> -select USB_OHCI_HCD_PLATFORM >> -help >> - This option is deprecated now and the driver was removed, use >> - USB_OHCI_HCD_PLATFORM instead. >> - >> - Enables support for the on-chip OHCI controller on the SuperH. >> - If you use the PCI OHCI controller, this option is not necessary. >> - >> config USB_OHCI_EXYNOS >> tristate "OHCI support for Samsung S5P/Exynos SoC Series" >> depends on ARCH_S5PV210 || ARCH_EXYNOS || COMPILE_TEST >> -- >> 2.39.0 >> > > Do you want all of these to go through a single tree, or can they go > through the different driver subsystem trees? Neither please. Multiple people are objecting. Rob
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: [PATCH] drm: fix new kernel-doc warnings
On 03/05/2013 11:08:16 AM, Randy Dunlap wrote: From: Randy Dunlap rdun...@infradead.org Fix new kernel-doc warnings in drm_edid.c: convert doxygen(?) to kernel-doc to match the rest of the file's documentation. I've been feeding this stuff through triv...@kernel.org. (I just got my kernel.org account re-enabled yesterday, and hope to set up a tree to feed into linux-next this weekend, but this is probably still trivial@ material anyway since it's scattered around the tree outside of the documentation directory.) Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: fix new kernel-doc warnings
On 03/05/2013 11:08:16 AM, Randy Dunlap wrote: > From: Randy Dunlap > > Fix new kernel-doc warnings in drm_edid.c: convert doxygen(?) to > kernel-doc to match the rest of the file's documentation. I've been feeding this stuff through trivial at kernel.org. (I just got my kernel.org account re-enabled yesterday, and hope to set up a tree to feed into linux-next this weekend, but this is probably still trivial@ material anyway since it's scattered around the tree outside of the documentation directory.) Rob
Re: [PATCHv5 00/13] Integration of videobuf2 with dmabuf
On 04/20/2012 09:45 AM, Tomasz Stanislawski wrote: Hello everyone, This patchset adds support for DMABUF [2] importing to V4L2 stack. The support for DMABUF exporting was moved to separate patchset due to dependency on patches for DMA mapping redesign by Marek Szyprowski [4]. Would it be an an option to _not_ cc: all 14 patches to the linux-doc list when 12 of them have nothing to do with documentation? (Or do the tools not allow for that?) Just wondering... Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's mere aggregation, or a license violation. Pick one. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCHv5 00/13] Integration of videobuf2 with dmabuf
On 04/20/2012 09:45 AM, Tomasz Stanislawski wrote: > Hello everyone, > This patchset adds support for DMABUF [2] importing to V4L2 stack. > The support for DMABUF exporting was moved to separate patchset > due to dependency on patches for DMA mapping redesign by > Marek Szyprowski [4]. Would it be an an option to _not_ cc: all 14 patches to the linux-doc list when 12 of them have nothing to do with documentation? (Or do the tools not allow for that?) Just wondering... Rob -- GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code. Either it's "mere aggregation", or a license violation. Pick one.
