[PATCH 1/2] DM_USB: allow building without OF_CONTROL

[Marek Vasut]

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.