[U-Boot] [PATCH] RSA depends on DM

[Simon Glass]

Hi Chris,

On 3 February 2015 at 17:57, Chris Kuethe <chris.kuethe at gmail.com> wrote:
> On Tue, Feb 3, 2015 at 4:38 PM, Simon Glass <sjg at chromium.org> wrote:
>> +Masahiro
>>
>> Hi Chris,
>>
>> On 3 February 2015 at 00:42, Chris Kuethe <chris.kuethe at gmail.com> wrote:
>>> Discovered while experimenting with signature checking on vexpress
>>> which doesn't typically use DM. Rather than complaining about unmet
>>> dependencies it might be better to enable those them.
>>>
>>> ---
>>>  lib/rsa/Kconfig | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>> diff --git a/lib/rsa/Kconfig b/lib/rsa/Kconfig
>>> index 1268a1b..4db5da4 100644
>>> --- a/lib/rsa/Kconfig
>>> +++ b/lib/rsa/Kconfig
>>> @@ -2,6 +2,7 @@ config RSA
>>>   bool "Use RSA Library"
>>>   select RSA_FREESCALE_EXP if FSL_CAAM
>>>   select RSA_SOFTWARE_EXP if !RSA_FREESCALE_EXP
>>> + select DM
>>>   help
>>>    RSA support. This enables the RSA algorithm used for FIT image
>>>    verification in U-Boot.
>>
>> I wonder whether 'depends on DM' might be better? It seems odd to have
>> the tail wagging the dog.
>>
>> Regards,
>> Simon
>
> No, that would not be better because a few lines down,
> RSA_SOFTWARE_EXP and RSA_FREESCALE_EXP both say "depends on DM" but
> they don't actually enable it if they need it.
>
> As a user, my expectation is that when I turn on some high level
> feature, that will enable all of its lower level dependencies. Would
> it be less strange to make FIT_SIGNATURE turn on DM instead of RSA?

We certainly must avoid the build break.

My concern is that CONFIG_DM may introduce a run-time break. For
example if you don't have pre-relocation malloc() available the board
may not boot. Driver model is a fundamental core feature, and we are
working to move everything over to it, but I'm not quite comfortable
with forcing it on when someone changes a feature. It feel it would be
better to not offer it.

I'm interested to hear other viewpoints though.

Perhaps soon we can enable CONFIG_DM globally but we are not there yet.

Regards,
Simon