On Thu, Nov 3, 2022, at 17:37, Jarzmik Robert wrote: > I'm sorry Arnd, my mailer messed up again, and instead of using my > normal robert.jarzmik@xxxxxxx, it used my ISP mail ... >> > > The reason you're not seeing the AC97_BUS_NEW used is because this > becomes visible only in device-tree files, which were posted (for > mioa701 for example) but never properly reviewed nor merged. > > As from memory, at least mioa701, zylonite, em_x270 are DT ported, ie. > there is a DT file which makes them boot. For the mioa701, the DT file > offers the same functionnality, ie. all drivers in mioa701.c legacy > file are working as well in a DT variant (not using mioa701.c > obviously). Ok, I see. I need a little clarification here, so I can adapt my patch series to keep the necessary files in place: - Zylonite has both PXA300 and PXA320 variants. I removed the PXA320 code because nothing selected it any more and it is not hooked up to the MACH_PXA3XX_DT Kconfig symbol. Should I undo this and keep all three PXA3xx variant, removing only PXA930 but selecting CPU_PXA310/320 from MACH_PXA3XX_DT? - The em_x270 board file was already removed as part of 9d3239147d6d ("ARM: pxa: remove Compulab pxa2xx boards"), which already removed the associated drivers. Is it correct to assume that the DT support for it has also become unusable at that point, or would you expect it to still have some use? I now remove the related CM-X300 machine as well, but it sounds like you did not have DT support for that, right? - I'm not sure how the probing of the ASoC drivers works in the DT case. Do I only need to make SND_PXA2XX_SOC_AC97 user-visible to let everything get probed automatically from DT, or do we need to also keep SND_PXA2XX_SOC_MIOA701 and SND_SOC_ZYLONITE? >> Any idea where I went wrong here? Did I make a mistake in following the Kconfig dependencies, or are some parts of this > incorrectly annotated? > > I don't think you did a mistake, I think I did. When I saw the patch of > "deprecation" of mioa701 and all the other pxa files, I took it that > the platform-device was deprecated, and was to be removed. This is the > right thing to do in my opinion. I wouldn't mind if all board file go > actually (expect the QEMU one), as this would leave only the boards > with proper DT support, and would remove some clutter from the kernel. Right, this is the plan: the only board files I left in place are 'gumstix' family that is supported by qemu and has the largest amount of RAM in there, and the 'spitz' family that is also supported by qemu and apparently had at least one user that was interested in working on DT (I can't find a record of who that was now). > I also thought the drivers won't get touched by the purge, exception > made of "platform similar ones", such as in the sound tree > (sound/soc/pxa) where we have some of them, and maybe mfd tree. I made two lists of drivers here: the first list is for those that become invisible in Kconfig and can no longer even be compile tested. My reasoning here was that these are likely already dead and will only get worse without compile testing. If anyone ends up doing a new DT conversion of a removed board later on, these can obviously get resurrected. The current state of the patches is in [1], I'll go through them again based on your feedback, but let me know if you see anything else that I'm removing that you think should be kept. The second list of drivers is for those that have no DT support and are impossible to get used without anyone declaring a (platform, spi, i2c, ...) device in source code somewhere. The list is still incomplete because this is hard to check automatically. I have included a few patches to remove drivers that have been obviously unused for a long time, or never had an in-tree user at all, but I left the majority of these drivers for a later series. Arnd [1] https://git.kernel.org/pub/scm/linux/kernel/git/soc/soc.git/log/?h=boardfile-remove&id=73c4b7cfbc2b2ef0