Re: [linux-yocto] Back-porting a new driver to Yocto kernel(s)..and device firmware
-Original Message- From: Bruce Ashfield [mailto:bruce.ashfi...@windriver.com] Sent: Wednesday, June 18, 2014 7:51 PM To: Kamble, Nitin A; Allan, Bruce W; linux-yocto@yoctoproject.org Subject: Re: [linux-yocto] Back-porting a new driver to Yocto kernel(s)..and device firmware On 2014-06-18, 9:51 PM, Kamble, Nitin A wrote: On 6/18/2014 4:24 PM, Allan, Bruce W wrote: We have a new hardware crypto device driver currently out for RFC on the linux-crypto mailing list and would like to back-port it to the Yocto Linux kernels once it is committed upstream. What is the process for getting it into the current dev kernel as well as linux-yocto-3.10 and linux-yocto-3.14? I've already done the back-port to the three Yocto Linux kernels and found that just 1 or 2 (depending on the kernel) other patches would also be needed. Is back-porting these patches also allowed as long as they do no harm to anything else? Hi Bruce, The right way is to push these backported patches in the respective stable kernel trees. If that is not working, then the patches can be pushed in the linux-yocto kernel repositories as features. Actually no .. not for the normal kernel.org -stable trees. From the description, these are new features, not stable patches. So they aren't something that can go to the korg stable. Shooting for LTSI is an option, but the cycle time for that to propagate to linux-yocto is really quite long. I'm happy to take the commits when they are Ack'd and headed to mainline, or even soak them on a feature branch (like I did with EDF before it merged). As long as the commits are upstream quality, we won't have any trouble, and I'll merge the RFC/staged changes when the cycle around through other trees. Bruce The device also requires a firmware component which has already been committed to the upstream linux-firmware repository. How does this get into Yocto? Then there may not be any thing done for the linux-firmware, as we always try to be up to date with upstream. If you need automatic loading of some modules, then you nay need to add configuration for that to BSPs. Which hardware is this feature for? Possibly we already has a BSP for that hardware, otherwise a new BSP can be created. Nitin Thanks, Bruce Allan. Excellent! Thanks for the info. Will probably push the patches in the next few weeks. Bruce Allan. -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
[linux-yocto] Back-porting a new driver to Yocto kernel(s)..and device firmware
We have a new hardware crypto device driver currently out for RFC on the linux-crypto mailing list and would like to back-port it to the Yocto Linux kernels once it is committed upstream. What is the process for getting it into the current dev kernel as well as linux-yocto-3.10 and linux-yocto-3.14? I've already done the back-port to the three Yocto Linux kernels and found that just 1 or 2 (depending on the kernel) other patches would also be needed. Is back-porting these patches also allowed as long as they do no harm to anything else? The device also requires a firmware component which has already been committed to the upstream linux-firmware repository. How does this get into Yocto? Thanks, Bruce Allan. -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] Back-porting a new driver to Yocto kernel(s)..and device firmware
On 6/18/2014 4:24 PM, Allan, Bruce W wrote: We have a new hardware crypto device driver currently out for RFC on the linux-crypto mailing list and would like to back-port it to the Yocto Linux kernels once it is committed upstream. What is the process for getting it into the current dev kernel as well as linux-yocto-3.10 and linux-yocto-3.14? I’ve already done the back-port to the three Yocto Linux kernels and found that just 1 or 2 (depending on the kernel) other patches would also be needed. Is back-porting these patches also allowed as long as they do no harm to anything else? Hi Bruce, The right way is to push these backported patches in the respective stable kernel trees. If that is not working, then the patches can be pushed in the linux-yocto kernel repositories as features. The device also requires a firmware component which has already been committed to the upstream linux-firmware repository. How does this get into Yocto? Then there may not be any thing done for the linux-firmware, as we always try to be up to date with upstream. If you need automatic loading of some modules, then you nay need to add configuration for that to BSPs. Which hardware is this feature for? Possibly we already has a BSP for that hardware, otherwise a new BSP can be created. Nitin Thanks, Bruce Allan. -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
Re: [linux-yocto] Back-porting a new driver to Yocto kernel(s)..and device firmware
On 2014-06-18, 9:51 PM, Kamble, Nitin A wrote: On 6/18/2014 4:24 PM, Allan, Bruce W wrote: We have a new hardware crypto device driver currently out for RFC on the linux-crypto mailing list and would like to back-port it to the Yocto Linux kernels once it is committed upstream. What is the process for getting it into the current dev kernel as well as linux-yocto-3.10 and linux-yocto-3.14? I’ve already done the back-port to the three Yocto Linux kernels and found that just 1 or 2 (depending on the kernel) other patches would also be needed. Is back-porting these patches also allowed as long as they do no harm to anything else? Hi Bruce, The right way is to push these backported patches in the respective stable kernel trees. If that is not working, then the patches can be pushed in the linux-yocto kernel repositories as features. Actually no .. not for the normal kernel.org -stable trees. From the description, these are new features, not stable patches. So they aren't something that can go to the korg stable. Shooting for LTSI is an option, but the cycle time for that to propagate to linux-yocto is really quite long. I'm happy to take the commits when they are Ack'd and headed to mainline, or even soak them on a feature branch (like I did with EDF before it merged). As long as the commits are upstream quality, we won't have any trouble, and I'll merge the RFC/staged changes when the cycle around through other trees. Bruce The device also requires a firmware component which has already been committed to the upstream linux-firmware repository. How does this get into Yocto? Then there may not be any thing done for the linux-firmware, as we always try to be up to date with upstream. If you need automatic loading of some modules, then you nay need to add configuration for that to BSPs. Which hardware is this feature for? Possibly we already has a BSP for that hardware, otherwise a new BSP can be created. Nitin Thanks, Bruce Allan. -- ___ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto
