[U-Boot] is it worth contributing a SATA SIL3512 driver to u-boot?
on current project, someone handed me a patch containing (among other thigns) source and header files for support for SATA SIL3512 -- copyright shows they're under GPL. rather than carrying around that part of the patch, is it worth simply handing that over to u-boot to add under drivers/block/?
rday
On Thu, Dec 10, 2015 at 4:14 PM, Robert P. J. Day rpjday@crashcourse.ca wrote:
on current project, someone handed me a patch containing (among other thigns) source and header files for support for SATA SIL3512 -- copyright shows they're under GPL. rather than carrying around that part of the patch, is it worth simply handing that over to u-boot to add under drivers/block/?
Yes, feel free to submit it, but please make sure there is an user for this driver as well.
Regards,
Fabio Estevam
On Thu, 10 Dec 2015, Fabio Estevam wrote:
On Thu, Dec 10, 2015 at 4:14 PM, Robert P. J. Day rpjday@crashcourse.ca wrote:
on current project, someone handed me a patch containing (among other thigns) source and header files for support for SATA SIL3512 -- copyright shows they're under GPL. rather than carrying around that part of the patch, is it worth simply handing that over to u-boot to add under drivers/block/?
Yes, feel free to submit it, but please make sure there is an user for this driver as well.
well, the contract i'm working on will be using it for porting linux to a *lot* of older platforms so, technically, i'm that user. :-)
rday
On Thu, Dec 10, 2015 at 6:19 PM, Robert P. J. Day rpjday@crashcourse.ca wrote:
well, the contract i'm working on will be using it for porting linux to a *lot* of older platforms so, technically, i'm that user. :-)
What I meant was: if you submit the SATA SIL3512 driver to U-boot, you should also add the U-boot support for at least one board that makes use of this driver.
On Thu, 10 Dec 2015, Fabio Estevam wrote:
On Thu, Dec 10, 2015 at 6:19 PM, Robert P. J. Day rpjday@crashcourse.ca wrote:
well, the contract i'm working on will be using it for porting linux to a *lot* of older platforms so, technically, i'm that user. :-)
What I meant was: if you submit the SATA SIL3512 driver to U-boot, you should also add the U-boot support for at least one board that makes use of this driver.
ah, gotcha. i *think* i can do that, based on legalities.
rday
On Thu, 10 Dec 2015, Fabio Estevam wrote:
On Thu, Dec 10, 2015 at 6:19 PM, Robert P. J. Day rpjday@crashcourse.ca wrote:
well, the contract i'm working on will be using it for porting linux to a *lot* of older platforms so, technically, i'm that user. :-)
What I meant was: if you submit the SATA SIL3512 driver to U-boot, you should also add the U-boot support for at least one board that makes use of this driver.
short and possibly stupid question -- the fact that there is no support for this SATA device in u-boot suggests it's not terribly popular. i know little about it, can anyone comment on whether it's just obsolete or deprecated or superseded by a newer driver or something? i'm just starting to dig through the code now.
rday
On 11 December 2015 at 13:16, Robert P. J. Day rpjday@crashcourse.ca wrote:
On Thu, 10 Dec 2015, Fabio Estevam wrote:
On Thu, Dec 10, 2015 at 6:19 PM, Robert P. J. Day rpjday@crashcourse.ca wrote:
well, the contract i'm working on will be using it for porting linux to a *lot* of older platforms so, technically, i'm that user. :-)
What I meant was: if you submit the SATA SIL3512 driver to U-boot, you should also add the U-boot support for at least one board that makes use of this driver.
short and possibly stupid question -- the fact that there is no support for this SATA device in u-boot suggests it's not terribly popular. i know little about it, can anyone comment on whether it's just obsolete or deprecated or superseded by a newer driver or something? i'm just starting to dig through the code now.
It seems to be a PCI SATA addon chip. Booting directly from an addon chip is not immensely useful so long as your main chipset/SoC has any usable storage to boot from - eg USB or native AHCI. It might be nice if your main chipset is not well supported or you want to add support for many chipsets that all have similar PCI subsystem so you can easily get at storage using single driver.
Thanks
Michal
On Thu, 10 Dec 2015, Fabio Estevam wrote:
On Thu, Dec 10, 2015 at 6:19 PM, Robert P. J. Day rpjday@crashcourse.ca wrote:
well, the contract i'm working on will be using it for porting linux to a *lot* of older platforms so, technically, i'm that user. :-)
What I meant was: if you submit the SATA SIL3512 driver to U-boot, you should also add the U-boot support for at least one board that makes use of this driver.
ok, let me describe in whatever detail i'm allowed to what the situation is (without mentioning any names due to NDA), and i'm interested in guidance.
working on project to port linux (using yocto project) to quite a number of (admittedly old) freescale MPC8360e-based systems. we do, in fact, have a working BSP, which includes a usable u-boot of a couple different versions -- one a patched u-boot-1.2.0, the other a patched 2015.10.
2015.10 patch is about 5,000 lines long, but quite a lot of it appears to be pretty generic stuff that i doubt anyone would care about publishing, so there's a good chance i'd be allowed to submit a patch to u-boot for support for at least *generic* MPC8360e support. (i see there is already arch/powerpc/cpu/mpc83xx/, which some of the patch applies to.)
i can check with the higher-ups about their willingness to contribute a new board definition and, if they have no objection, would that be sufficient to submit a patch to add a new board so that we don't have to carry all this patch material around?
am i thinking about this the right way?
rday
On Sun, Dec 13, 2015 at 11:37 AM, Robert P. J. Day rpjday@crashcourse.ca wrote:
i can check with the higher-ups about their willingness to contribute a new board definition and, if they have no objection, would that be sufficient to submit a patch to add a new board so that we don't have to carry all this patch material around?
am i thinking about this the right way?
I don't see any problems with this approach.
Just submit the patches to the list and maintainer when you can and it will go through the standard review process.
participants (3)
-
Fabio Estevam -
Michal Suchanek -
Robert P. J. Day