Dragon 410c Mainline Kernel Support?


I wanted to ask if all the “patches” applied to the Linaro build have been submitted to the mainline kernel?

This link: https://builds.96boards.org/releases/dragonboard410c/linaro/ubuntu/15.06/ describes various aspects of the Linaro build which suggests the Dragon Board 410c is not supported by the Mainline Kernel, these are:

  1. It is based on proprietary firmware available on Qualcomm Developer Network.
  2. Wifi and Bluetooth using integrated WCN3620, using proprietary firmware and wcn36xx driver



the support in mainline kernel is improving over time. It is not fully supported yet, but clearly between June 2015 (and 15.06) and now, a lot of patches have been merged.

The firmware ‘blob’ that are mentioned in the release notes are firmware, not proprietary (user space) components. The blob are s/w program that don’t run on the main ARM CPUs, but on the various IP block (wlan core, GPU, DSP, …). The current license for these blobs do not allow us to include them in the linux-firmware package that all distro usually ship. But to some extends, the blobs have nothing to do with the ‘upstreaming’ efforts.

For the Debian/Ubuntu/OE release there is no proprietary software in our builds beyond these blobs. In other words, on the main ARM CPUs all the s/w is open source (including the GPU driver which comes from mesa).

For the Android builds, there are user space proprietary components (libs) which are released on Qualcomm Dev Net as object files.

Hi Ndec,

Thanks for the explanation and for all the efforts getting patches merged. For now I’ll grab a copy of the Linaro “release/qcomlt-4.2” and have a go building an image.


@ndec, If someone wants to contribute patches to mainline kernel for DragonBoard 410c then he should use landing-team repo or mainline/next repo.

mainline development should be done against mainline/next repo, for sure. Most likely on this mailing list:


@ndec, Thank you for your reply.
I think developing againts mainline/next is reinventing the wheel. So, do landing-team accepts patches?
If yes then mailing list?
I think people will use landing-team repo or Linaro builds for the time being.

Probably, scripts/get_maintainer.pl is the answer.
Last but not least, there is an error in the previous post,
does landing-team accept patches?

so first of all, I don’t believe that developing against mainline is reinventing the wheel at all… in fact, it’s probably quite the opposite. Not developing against mainline in the first place forces everyone to reinvent the wheel for every new product …

to answer your question, we can take patches, but it depends on what it is…

  • for bug fixes that only apply to our tree (e.g. in code not yet in mainline), then yes, of course we can take them.
  • for defconfig patches, new features (e.g. please enable my USB device), then yes, we take them. In fact this is a distro config, so it won’t go into mainline anyways
  • for bigger driver/dev, that needs to be discussed on a case by case. In most cases, we don’t want to take the responsibility of maintaining extra out of tree (non upstream) code (we have enough of that already!). So we can take patches if you commit to support them throughout the time, and we would remove the code in case you do not support the patches in the future…

if you have any contribution that you want to submit I would recommend to start a discussion on http://bugs.96boards.org/ first.

I was saying that,

  1. If someone develops againt mainline/next, he will create all those patches residing in the landing-team repo to be submitted to mainline.
  2. If someone develops against landing-team repo, he does not need to do (1) and he will add some new patches.
  3. Last but not least, landing-team patches are going to land in mainline ultimately.

I agree “Not developing against mainline in the first place forces everyone to reinvent the wheel for every new product”.

If any thing is wrong with my thought, please correct me because I’m a kernel newbie.