On 19.06.21 г. 22:38 ч., Marek Vasut wrote:
On 6/19/21 9:33 PM, Ivaylo Dimitrov wrote:
Hi,
Hi,
Currently DM_USB requires OF_CONTROL to be enabled, otherwise
link errors
occur. On the other hand OF_CONTROL requires board code to be
migrated to
DT, which is not always possible or required.
Fix that by conditionally compiling OF_CONTROL specific sections
in USB
related drivers code in the same way like it is done in the other
drivers.
Also, auto select OF_LIBFDT if DM_USB is selected but OF_CONTROL
is not.
Introduce a new Kconfig option OF_NODE used to compile of_node.c
in case
OF_CONTROL is not enabled. Fix deprecation warning condition as
well.
So, what is the use case of this? Why not just enable DM_USB and
OF_CONTROL ?
OF_CONTROL requires migration to device-tree.
That's where the supported platforms are heading anyway. Or is there
some issue with switching the platform you use over to DT ?
OK, let me elaborate: It is about enabling DM_USB on N900 (Nokia rx-51
board). For various reasons I am not going to discuss (1), migration
to DM was delayed to the point where we saw "[PATCH] arm: Remove
nokia_rx51 board" with a commit message "This board has not been
converted to CONFIG_DM_USB by the deadline. Remove it." posted. The
missing pieces were WDT (a patch is already merged in -next) and
DM_USB. The board itself does not support host mode, but USB TTY is
very useful for debugging purposes. The particular task I am after is
USB DM migration and the $subject patch allows this to be achieved
with relatively little effort (a couple of defconfig changes),
incomparable with the effort needed for migration to DT. As we are
already past the DM migration deadline I think it makes sense to
fulfil its requirements before undertaking such a big task like
migration to DT.
This sounds like a workaround though. Can you instead do the full
conversion of the board? I am sure the board removal patch can be
postponed if there is plan to convert it.
Hard to say if migration to device-tree is even possible on N900 ATM,
enabling OF_CONTROL increases the size of the produced binary with some
100k (.dtb not included), making the size of the binary way above our
budget of ~256k. Sure, board config does not enable -mthumb, but omap3
in rx-51 suffers from ARM errata 430973 and noone can guarantee we're
not going to see SIGILL faults if we enable it. Which it seems we are
forced to do even with DM_USB migration only.
Re workaround - I took examples of #ifdef's from the current u-boot code
(mmc, i2c, etc.) so workaround or not, it is no different to what the
other drivers are doing.
I don't really understand where this requirement to convert to DTS comes
from - will boards that are not converted be removed at some point? When
is that deadline if exists? If there is no such deadline, why shall we
spend who knows how many hours just because "you know, it sounds like a
good idea to convert to DTS"? You understand this is not a trivial task
and given the pace rx-51 patches were reviewed lately, it will easily
take 2 years to do that conversion.
To sum it up - maybe I can do a full DTS migration, but I don't see a
point in doing it ATM. The $subject patch allows rx-51 to be fully
migrated to DM and does nothing different to what already is done all
over the place.
Regards,
Ivo
