On Wed, May 9, 2012 at 2:17 PM, Arnd Bergmann <[email protected]> wrote:
> On Wednesday 09 May 2012, Andreas WESTIN wrote:
>> On 2012-05-09 10:36, Linus Walleij wrote:
>> >> This needs an explanation! Why do you export an internal data structure
>> >> to non-GPL modules?
>> >
>> > This does not look like it's needed at all, none of the other two patches
>> > use
>> > it. Andreas can you just drop this hunk of the patch?
>>
>> It is needed if you compile the drivers as modules, but it should be a
>> GPL export. I will change it.
>
> How about using distinct identification strings for each version of the
> crypto hardware? The driver should really only care about what kind
> of device it is talking to, not which SoC it is built into.
Do you mean like this (from a recent pinctrl driver):
static int __devinit nmk_pinctrl_probe(struct platform_device *pdev)
{
const struct platform_device_id *platid = platform_get_device_id(pdev);
....
(Here we use that ID to control runtime codepath)
}
static const struct platform_device_id nmk_pinctrl_id[] = {
{ "pinctrl-stn8815", PINCTRL_NMK_STN8815 },
{ "pinctrl-db8500", PINCTRL_NMK_DB8500 },
};
static struct platform_driver nmk_pinctrl_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "pinctrl-nomadik",
},
.probe = nmk_pinctrl_probe,
.id_table = nmk_pinctrl_id,
};
Here one version of ASIC registers the "pinctrl-db8500" device.
And so on.
So instead of registering "cryp1" and "hash1", register
"db8500-cryp-v1", "db8500-cryp-v2" etc for the versions,
then use the ID to control code path.
Is that what you were thinking of?
That might be a good idea, however it requires some changes to patches
earlier in the series (but can be done as an incremental add-on of
course).
Yours,
Linus Walleij
--
To unsubscribe from this list: send the line "unsubscribe linux-crypto" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
