Control: reassign -1 src:linux 6.5.3-1 Control: severity -1 wishlist On Tuesday, 26 September 2023 04:06:15 CEST Macpaul Lin wrote: > I am currently working on enabling Debian on MediaTek platforms. The > target SoCs include MT8365, MT8195/MT8395, and MT8188/MT8390. > > Upon examining the kernel configurations, I noticed that none of the > MediaTek-related kernel configurations are enabled by default. As a > result, I plan to submit patches and file issues with the Debian > community. I think the very beginning configration will be > "CONFIG_ARCH_MEDIATEK=y" and other necessary peripherals like > power/clock/uart, etc. > > I still have some questions about submitting patches for SoC enablement on > Debian. I have registered for the kernel mailing list and created a GitLab > account for sending merge requests.
Did you create an account on Salsa, Debian's GitLab instance or on gitlab.com? The former would be needed for sending MRs; the latter is irrelevant. > Here are my questions: > > 1. What is the best way to file issues with patches? Should I file one > issue per patch or per single configuration change? It's a bit arbitrary. We _could_ do it all in this bug report, but it's probably more useful to file a bug report per platform for which you want to add support. This is assuming that they can be handled separately. > 2. Should I send a series of patches for platform enablement as a single > issue via GitLab, or should I send patches through the mailing list (bug > report system)? You could (and probably should) list the needed kernel modules per platform when you file a bug for support for that platform. I'd recommend to then file a MR in which you add support for a particular platform and with that you'd close the bug report you filed for that. IOW: Do a 1-on-1 mapping between bug report and MR. > 3. Should I submit bugs for enabling kernel configurations to multiple > kernel versions? (6.1, 6.4, 6.5) This might cause same issues for > different kernel versions show up in bug tracking system. I don't know *IF* it's possible to still add hardware support to the 6.1 kernel which is used in Stable/Bookworm. Assuming the platforms were properly supported in the upstream 6.1 kernel, then there still has been zero testing with it on a Debian system, which does not sound ideal for Stable. One of the Debian kernel maintainers would have to answer whether it is possible at all for 6.1/Stable/Bookworm. It is not a problem for Unstable, which if all goes well would mean it'll end up in Testing/Trixie and I'd recommend to file it against version 6.5.3-1, just like this bug. > 4. Should I send patches for different branches separately? For > instance, I have cloned > "https://salsa.debian.org/kernel-team/linux.git";. Should I send patches > or merge requests for different branches like bookworm and trixie to > keep the setting in future releases? Until a Debian kernel maintainer has given the green light for inclusion in Stable/Bookworm, I'd leave that aside for the time being. You could target your MR to either the 'sid' or the 'master' branch; I usually target the 'master' branch. > 5. Is there a verification method for kernel configurations on Debian? Sort of. When you submit a MR you are expected to have verified that it actually works, which means you need to build a kernel with the changes of your MR included and tested that on real hardware. The Salsa CI pipeline also does some verifications, but that alone is not sufficient before sending the MR. You need to build and test an actual kernel. > I currently have a running Ubuntu on MediaTek platforms and can debug > kernel configurations on Ubuntu. I'm not sure what you mean by 'debugging' kernel configuration. Can you explain what you mean by that? > However, I don't have a bootable Debian on these boards. Should I use > debootstrap "https://wiki.debian.org/Debootstrap"; on Ubuntu boards to > install Debian and build the Debian kernel at the initial stage? I _think_, and you probably should, build and test it on a (pure) Debian system. If you have *a*(nother) arm64 board which runs Debian, that would work too. Otherwise, debootstrap is indeed an excellent tool to create an initial Debian system (and AFAIK the host system/OS is not important). I don't know if you could combine running `debootstrap` with building the kernel and I'm inclined to think that's probably not a good idea (other then 'academic/enthusiastic' curiosity). I'd go for: 1) Make a Debian system for an arm64 device 2) Boot into that and install all the needed packages for building a kernel 3) Build the kernel 4) Debootstrap a system for your target platform with a suitable bootloader and install the kernel debs resulting from 3) onto that 5) Verify your Debian kernel work on that target platform > I appreciate your guidance on these matters. I am eager to contribute to > kernel configurations on Debian for MediaTek platforms. HTH, Diederik PS: I removed the debian-arm/debian-kernel ML as this is a kernel matter and this bug report already ensures it ends up on the debian-kernel ML. I've kept the DDs as I don't know if they requested to be CC-ed explicitly.
signature.asc
Description: This is a digitally signed message part.
