I have already read that page. That page only refers to Cypress' releases of the backports sources. There is another repository in which there is a gentree.py script which is used to generate the "backports sources" that are provided by Cypress. As far as I can tell, this git repository is not public, but I asked this question in hopes that someone would prove me wrong and provide a link or Cypress would consider opening access to this git repository.
As an example of what this git repository looks like, please look at kernel/git/backports/backports.git - Automatically backports the Linux kernel which is likely the upstream repository of the Cypress backports git repository.
1 of 1 people found this helpful
I took sometime and looked into the issue you posted.
In fact, what you concerned is not a big deal. Actually, the backports released at cypress.com can be generated from the standard Linux kernel backports package you mentioned.
I've done some digging and let me prove it to you.
First, we 'cd' to the directory of the untarred backports from cypress.com (like the one you posted). The dir could be 'v4.14.77-backports'. then 'cat versions' and we will see:
Above lines show that this backports is actually generated by backports package of version v4.14-rc2-1, using kernel source of version v4.14.77 as kernel source input. (So this backports provides backport compiling services to older kernel from 3.10 to 4.14, to help these older kernel to get the new brcmfmac driver of kernel v4.14.77).
For convenience, let's see the files structure of this backports by 'ls -l' in the beginning:
Then we can try to generate a repo that is almost the same as the one above using official 'gentree.py', to see what are the differences between the official backports and the backports from CY.
Assuming a linux kernel git repository (e.g., https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git) was pulled down to '~/linux-stable'. First reset backports package to v4.14-rc2-1. Then we can type './gentree.py --clean --git-revision v4.14.77 ~/linux-stable/ ~/generated-backports/' to generate the backports we would like to look into. See the screenshot below:
Then 'cat versions' and 'ls -l' at the generated-backports and we will see:
Please note that the files are not listed in the same order but they look the same. And the versions show that the two backports are basically generated with the same BACKPORTS_VERSION and BACKPORTED_KERNEL_VERSION.
So we have successfully generated a backports that looks very much alike with the one provided by CY!
Now we move to see the differences of the two backports.
Type 'make defconfig-help' in the backports from CY:
We can see that it only contains one pre-defined defconfig. And the option "defconfig-brcmfmac" is what we exactly want.
Type 'make defconfig-help' in the backports we just generated:
We can find that it contains multiple pre-defined defconfig! And the option "defconfig-brcmfmac" that we exactly want is also can be found in the list!
If you then type 'make defconfig-brcmfmac && make' at both backports (sometimes addtional 'KLIB' and other variables are needed), you will find the same modules and .ko files are compiled and linked.
There is one more thing you should know. You can find the official release of backports here (not the "Linux kernel backports package" itself). This link is officially provided because it is linked to https://backports.wiki.kernel.org/index.php/Main_Page (under the "Resources" tab).
For example, download https://cdn.kernel.org/pub/linux/kernel/projects/backports/stable/v4.14-rc2/backports-4.14-rc2-1.tar.gz and untar it and 'cat versions' at the untarred dir, we will see that:
As supplement, type 'ls -l' to see:
We can now know that this release of backports is basically the same as the two backports above (the one from CY and the one we generated). A fun fact is that this release of backports provided officially has the same file counts as the one we generated, though we use a slightly different kernel source of slightly different BACKPORTED_KERNEL_VERSION.
From the observation mentioned above, I think we can have these conclusions (at least I think we can, though they are not so seriously proved):
- The backports from CY is actually nothing visibly different from the officially released backports or the self-generated one. We can even say the backports from CY is also generated using official backporting sources and following official backporting workflow, plus only some trimming. Because they are all generated with nearly the same BACKPORTS_VERSION and BACKPORTED_KERNEL_VERSION, which indicates the backports from CY website can't have other unpublished code according to the workflow of backporting. And they all contain the option "defconfig-brcmfmac", which means they will all behave the same and CY is not tending to provide some other options or solutions that the official releases can't do while having such backports released.
- CY provide this backports in the driver's package only for convenience and integrity, by trimming and gather it at CY website. In case someone don't know how to generate the backported code or to help someone get it quickly.
- In fact, CY can't hide any source code because the brcmfmac drivers are built-in drivers existing in almost every version of Linux kernel source, i.e., this exact backports from CY that we do the experiments with (FMAC 2019.10.31), does nothing but provides backport compiling services to older kernel from 3.10 to 4.14, to help these older kernel to get the new brcmfmac driver of kernel v4.14.77. So the backported code can exactly be found in the official kernel v4.14.77. CY doesn't and can't have the "upstream git repository" which is not public due to the workflow.
Hope that my answer solves some of your questions.
Thanks for the information. As a result of the information in this post, I was able to generate a working backports tree from a 4.14.77 kernel and the patches directory in the brcmfmac release.
Great! I'm glad to assist you in this circumstance!
Have hun in community if you need anything.