Thread: [Ocf-linux-users] OCF for Marvell Kirkwood; probe function not called; does not init CESA
Brought to you by:
david-m
From: <ana...@wi...> - 2011-10-25 07:33:00
|
Hi, I'm trying to use OCF for Marvell's CESA. I have built ocf.ko, cryptodev.ko and mv_cesa.ko. I've used insmod to load them and all the loading works fine except for mv_cesa.ko. The function mv_cesa_ocf_init() does not get called. In the following code from OCF kirkwood's cesa_ocf_drv.c, static struct platform_driver marvell_cesa = { .probe = mv_cesa_ocf_init, .remove = mv_cesa_ocf_exit, .driver = { .owner = THIS_MODULE, .name = "mv_crypto", }, }; MODULE_ALIAS("platform:mv_crypto"); static int __init mv_cesa_init(void) { return platform_driver_register(&marvell_cesa); } module_init(mv_cesa_init); With insmod, the mv_cesa_init() is called but the debug in mv_cesa_ocf_init() is not printed. Is platform_driver_register() internally supposed to call the .probe function? Or when is the probe function supposed to be called? What can be done to call the probe function of marvell_cesa? Thanks Ananth |
From: David M. <dav...@mc...> - 2011-10-26 01:27:11
|
Jivin ana...@wi... lays it down ... > Hi, > > I'm trying to use OCF for Marvell's CESA. I have built ocf.ko, cryptodev.ko and mv_cesa.ko. I've used insmod to load them and all the loading works fine except for mv_cesa.ko. The function mv_cesa_ocf_init() does not get called. In the following code from OCF kirkwood's cesa_ocf_drv.c, > > static struct platform_driver marvell_cesa = { > .probe = mv_cesa_ocf_init, > .remove = mv_cesa_ocf_exit, > .driver = { > .owner = THIS_MODULE, > .name = "mv_crypto", > }, > }; > > MODULE_ALIAS("platform:mv_crypto"); > > static int __init mv_cesa_init(void) > { > return platform_driver_register(&marvell_cesa); > } > > module_init(mv_cesa_init); > > With insmod, the mv_cesa_init() is called but the debug in mv_cesa_ocf_init() is not printed. Is platform_driver_register() internally supposed to call the .probe function? Or when is the probe function supposed to be called? What can be done to call the probe function of marvell_cesa? I am not sure, what kernel version are you using and what platform are you building for ? Have you created a custom platform of your own ? I had a look at our marvel based platform where I know this was working (haven't used it for quite a while) and it all looks similar. You may just need to work though the platform driver code until you figure out why it isn't called :-( Cheers, Davidm -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
From: <ana...@wi...> - 2011-10-26 08:55:49
|
Hi David, I'm using 2.6.31.8 kernel on Marvell Prestera platform. The machine architecture chosen for the platform in /arch/arm is mach-feroceon-kw (/arch/arm/mach-feroceon-kw). I suppose this was provided by Marvell. Like in /arch/arm/Kirkwood/common.c where "mv_crypto" device is defined and registered, it is not done for mach-feroceon-kw. I copied the mv_crypto device from Kirkwood (not the best thing to do) and installed the mv_cesa.ko and mv_cesa_ocf_init() was called but also crashed. Have to figure out the correct device registers, sram and IRQ now. Thanks Ananth -----Original Message----- From: David McCullough [mailto:dav...@mc...] Sent: Wednesday, October 26, 2011 6:57 AM To: Anantharam V (WT01 - GMT-Telecom Equipment) Cc: ocf...@li... Subject: Re: [Ocf-linux-users] OCF for Marvell Kirkwood; probe function not called; does not init CESA Jivin ana...@wi... lays it down ... > Hi, > > I'm trying to use OCF for Marvell's CESA. I have built ocf.ko, cryptodev.ko and mv_cesa.ko. I've used insmod to load them and all the loading works fine except for mv_cesa.ko. The function mv_cesa_ocf_init() does not get called. In the following code from OCF kirkwood's cesa_ocf_drv.c, > > static struct platform_driver marvell_cesa = { > .probe = mv_cesa_ocf_init, > .remove = mv_cesa_ocf_exit, > .driver = { > .owner = THIS_MODULE, > .name = "mv_crypto", > }, > }; > > MODULE_ALIAS("platform:mv_crypto"); > > static int __init mv_cesa_init(void) > { > return platform_driver_register(&marvell_cesa); > } > > module_init(mv_cesa_init); > > With insmod, the mv_cesa_init() is called but the debug in mv_cesa_ocf_init() is not printed. Is platform_driver_register() internally supposed to call the .probe function? Or when is the probe function supposed to be called? What can be done to call the probe function of marvell_cesa? I am not sure, what kernel version are you using and what platform are you building for ? Have you created a custom platform of your own ? I had a look at our marvel based platform where I know this was working (haven't used it for quite a while) and it all looks similar. You may just need to work though the platform driver code until you figure out why it isn't called :-( Cheers, Davidm -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
From: David M. <dav...@mc...> - 2011-10-26 10:48:28
|
Jivin ana...@wi... lays it down ... > Hi David, > > I'm using 2.6.31.8 kernel on Marvell Prestera platform. > > The machine architecture chosen for the platform in /arch/arm is > mach-feroceon-kw (/arch/arm/mach-feroceon-kw). I suppose this was > provided by Marvell. Like in /arch/arm/Kirkwood/common.c where > "mv_crypto" device is defined and registered, it is not done for > mach-feroceon-kw. I copied the mv_crypto device from Kirkwood (not the > best thing to do) and installed the mv_cesa.ko and mv_cesa_ocf_init() > was called but also crashed. Have to figure out the correct device > registers, sram and IRQ now. Sounds like you are making progress. Once you get the correct parameters in there you should be looking much better :-) Cheers, Davidm > -----Original Message----- > From: David McCullough [mailto:dav...@mc...] > Sent: Wednesday, October 26, 2011 6:57 AM > To: Anantharam V (WT01 - GMT-Telecom Equipment) > Cc: ocf...@li... > Subject: Re: [Ocf-linux-users] OCF for Marvell Kirkwood; probe function > not called; does not init CESA > > > Jivin ana...@wi... lays it down ... > > Hi, > > > > I'm trying to use OCF for Marvell's CESA. I have built ocf.ko, > cryptodev.ko and mv_cesa.ko. I've used insmod to load them and all the > loading works fine except for mv_cesa.ko. The function > mv_cesa_ocf_init() does not get called. In the following code from OCF > kirkwood's cesa_ocf_drv.c, > > > > static struct platform_driver marvell_cesa = { > > .probe = mv_cesa_ocf_init, > > .remove = mv_cesa_ocf_exit, > > .driver = { > > .owner = THIS_MODULE, > > .name = "mv_crypto", > > }, > > }; > > > > MODULE_ALIAS("platform:mv_crypto"); > > > > static int __init mv_cesa_init(void) > > { > > return platform_driver_register(&marvell_cesa); > > } > > > > module_init(mv_cesa_init); > > > > With insmod, the mv_cesa_init() is called but the debug in > mv_cesa_ocf_init() is not printed. Is platform_driver_register() > internally supposed to call the .probe function? Or when is the probe > function supposed to be called? What can be done to call the probe > function of marvell_cesa? > > I am not sure, what kernel version are you using and what platform are > you > building for ? > > Have you created a custom platform of your own ? > > I had a look at our marvel based platform where I know this was working > (haven't used it for quite a while) and it all looks similar. > > You may just need to work though the platform driver code until you > figure > out why it isn't called :-( > > Cheers, > Davidm > > -- > David McCullough, dav...@mc..., Ph:+61 734352815 > McAfee - SnapGear http://www.mcafee.com > http://www.uCdot.org > > Please do not print this email unless it is absolutely necessary. > > The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. > > www.wipro.com > > -- David McCullough, dav...@mc..., Ph:+61 734352815 McAfee - SnapGear http://www.mcafee.com http://www.uCdot.org |
From: <ana...@wi...> - 2011-11-18 14:22:26
|
Hi, In OCF-linux file cesa_ocf_drv.c, there is the following code in function mv_cesa_ocf_init() line 1179. cesa_device.plat_data = pdev->dev.platform_data; I was not able to find where platform_data was set. I suppose it should've been done in Linux architecture files (specifically one of the files in /arch/arm/mach-kirkwood), probably where kirkwood_crypto_device is defined. But I could not find it in code for kernel 2.6.31.8. In later version, i.e 3.1.1, this has been changed to refer orion_crypto structures. Again, can't find where platform_data is set for CESA. Could you please help me understand? Regards Ananth |
From: 张绪峰 <sea...@12...> - 2011-11-22 05:09:24
|
At 2011-11-18 22:22:14,ana...@wi... wrote: >Hi, > >In OCF-linux file cesa_ocf_drv.c, there is the following code in >function mv_cesa_ocf_init() line 1179. > > cesa_device.plat_data = pdev->dev.platform_data; > >I was not able to find where platform_data was set. I suppose it >should've been done in Linux architecture files (specifically one of the >files in /arch/arm/mach-kirkwood), probably where kirkwood_crypto_device >is defined. > >But I could not find it in code for kernel 2.6.31.8. In later version, >i.e 3.1.1, this has been changed to refer orion_crypto structures. >Again, can't find where platform_data is set for CESA. This should be the platform_data register for CESA in 3.1.1: plat-orion/common.c +945: void __init orion_crypto_init(unsigned long mapbase, unsigned long srambase, unsigned long sram_size, unsigned long irq) { fill_resources(&orion_crypto, orion_crypto_resources, mapbase, 0xffff, irq); orion_crypto.num_resources = 3; orion_crypto_resources[2].start = srambase; orion_crypto_resources[2].end = srambase + sram_size - 1; platform_device_register(&orion_crypto); } Best Regards, Xufeng Zhang > >Could you please help me understand? > >Regards >Ananth > >------------------------------------------------------------------------------ >All the data continuously generated in your IT infrastructure >contains a definitive record of customers, application performance, >security threats, fraudulent activity, and more. Splunk takes this >data and makes sense of it. IT sense. And common sense. >http://p.sf.net/sfu/splunk-novd2d >_______________________________________________ >Ocf-linux-users mailing list >Ocf...@li... >https://lists.sourceforge.net/lists/listinfo/ocf-linux-users |
From: <ana...@wi...> - 2011-11-22 05:55:18
|
Thanks for the reply. orion_crypto_init() has no code to initialize platform_data in orion_crypto device. I would think it should be done one of the ways as follows (as examples). static struct platform_device orion_ge11_shared = { .name = MV643XX_ETH_SHARED_NAME, .id = 1, .dev = { .platform_data = &orion_ge11_shared_data, }, }; OR void __init orion_ge00_switch_init(struct dsa_platform_data *d, int irq) { int i; if (irq != NO_IRQ) { orion_switch_resources[0].start = irq; orion_switch_resources[0].end = irq; orion_switch_device.num_resources = 1; } d->netdev = &orion_ge00.dev; for (i = 0; i < d->nr_chips; i++) d->chip[i].mii_bus = &orion_ge00_shared.dev; orion_switch_device.dev.platform_data = d; platform_device_register(&orion_switch_device); } The same is not done for crypto device. Or am I missing something? Regards Ananth From: 张绪峰 [mailto:sea...@12...] Sent: Tuesday, November 22, 2011 10:39 AM To: Anantharam V (WT01 - GMT-Telecom Equipment) Cc: ocf...@li... Subject: Re:[Ocf-linux-users] Marvell CESA: platform_data At 2011-11-18 22:22:14,ana...@wi... wrote: >Hi, > >In OCF-linux file cesa_ocf_drv.c, there is the following code in >function mv_cesa_ocf_init() line 1179. > > cesa_device.plat_data = pdev->dev.platform_data; > >I was not able to find where platform_data was set. I suppose it >should've been done in Linux architecture files (specifically one of the >files in /arch/arm/mach-kirkwood), probably where kirkwood_crypto_device >is defined. > >But I could not find it in code for kernel 2.6.31.8. In later version, >i.e 3.1.1, this has been changed to refer orion_crypto structures. >Again, can't find where platform_data is set for CESA. This should be the platform_data register for CESA in 3.1.1: plat-orion/common.c +945: void __init orion_crypto_init(unsigned long mapbase, unsigned long srambase, unsigned long sram_size, unsigned long irq) { fill_resources(&orion_crypto, orion_crypto_resources, mapbase, 0xffff, irq); orion_crypto.num_resources = 3; orion_crypto_resources[2].start = srambase; orion_crypto_resources[2].end = srambase + sram_size - 1; platform_device_register(&orion_crypto); } Best Regards, Xufeng Zhang > >Could you please help me understand? > >Regards >Ananth > >------------------------------------------------------------------------------ >All the data continuously generated in your IT infrastructure >contains a definitive record of customers, application performance, >security threats, fraudulent activity, and more. Splunk takes this >data and makes sense of it. IT sense. And common sense. >http://p.sf.net/sfu/splunk-novd2d >_______________________________________________ >Ocf-linux-users mailing list >Ocf...@li... >https://lists.sourceforge.net/lists/listinfo/ocf-linux-users |