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
