Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revisionBoth sides next revision
playground:company_interaction [2016/10/18 22:03] haukeplayground:company_interaction [2018/05/16 02:07] – [Adding driver] spelling billingd
Line 3: Line 3:
 **[This is currently in draft status and work in progress]** **[This is currently in draft status and work in progress]**
  
-This guide is targeted at chip vendors, board manufacturers, OEMs and similar companies that want to provide upstream LEDE support for their SoC or board. This will probably also be helpful when selecting a board or SoCs with good LEDE support. The LEDE development model and contribution guidelines are similar to the guidelines of the upstream Linux kernel. (See [[docs:guide-developer:the-source-code|The Source Code]] for more technical details)+This guide is targeted at chip vendors, board manufacturers, OEMs and similar companies that want to provide upstream LEDE support for their SoC or board. This will probably also be helpful when selecting a board or SoCs with good LEDE support. The LEDE development model and contribution guidelines are similar to the guidelines of the upstream Linux kernel. (See [[docs:guide-developer:source-code:start|The Source Code]] for more technical details)
  
 LEDE is a community project run by a group of people and not by a single company. The advantage is that LEDE is not tied to one specific board, SoC or vendor and supports SoCs and boards from different vendors and is easily to be ported to other platforms. LEDE is a community project run by a group of people and not by a single company. The advantage is that LEDE is not tied to one specific board, SoC or vendor and supports SoCs and boards from different vendors and is easily to be ported to other platforms.
Line 30: Line 30:
 ==== Adding driver ==== ==== Adding driver ====
  
-There are different ways to contribute support for a new device by adding a new driver or extending an existing driver. In general LEDE prefers if the driver also gets send for inclusion into the upstream Linux kernel. This has the advantage that the driver automatically gets adapted to changes in kernel APIs which are often done by the same author that did the changes to the API. This reduces the effort needed to upgrade LEDE to a new major kernel version. If the driver is included in upstream Linux kernel the code will be available in LEDE soon, because LEDE updates to the most recent major version of the Linux kernel pretty soon. If a change for the Linux kernel was accepted by the Linux upstream community, it is normally no problem to get a backpoted version of this change accepted for integration in LEDE, normally no changes are requested in the LEDE code review for such backpoteds. It is also possible to submit a driver to be included into LEDE directly without it being include into the upstream Linux kernel. LEDE still prefers if this driver meets the quality requirements of the upstream Linux kernel.+There are different ways to contribute support for a new device by adding a new driver or extending an existing driver. In general LEDE prefers if the driver also gets send for inclusion into the upstream Linux kernel. This has the advantage that the driver automatically gets adapted to changes in kernel APIs which are often done by the same author that did the changes to the API. This reduces the effort needed to upgrade LEDE to a new major kernel version. If the driver is included in upstream Linux kernel the code will be available in LEDE soon, because LEDE updates to the most recent major version of the Linux kernel pretty soon. If a change for the Linux kernel was accepted by the Linux upstream community, it is normally no problem to get a backported version of this change accepted for integration in LEDE, normally no changes are requested in the LEDE code review for such backporteds. It is also possible to submit a driver to be included into LEDE directly without it being include into the upstream Linux kernel. LEDE still prefers if this driver meets the quality requirements of the upstream Linux kernel.
  
 Having a operating system abstraction layer around the driver and not directly using the in kernel API will not allow it to be integrated into the upstream Linux kernel and will also cause problems when integration into OpenWrt. Also when having an own implementations of common features like firmware loading from userspace into the driver instead of using the framework provided by the Linux kernel will cause problems in the code review for LEDE inclusion and has to be changed when it should be added to mainline Linux kernel. The driver should not have build time options to work with either the one chip or the other. Whenever possible it should automatically probe for the hardware and detect if the hardware it supports is there and which chip this is at runtime. If it is possible to have more than one instance of this device connected to a SoC like it is the case on a PCIe card the driver should work with multiple devices and the number should be detected at runtime. Runtime detection could be done based on PCI IDs, device tree and so on. it has to be possible to run the same binary kernel on all boards using the same SoC, it is preferred if the same binary can also be used for different SoCs, which is the case for most SoCs supported by LEDE. Having a operating system abstraction layer around the driver and not directly using the in kernel API will not allow it to be integrated into the upstream Linux kernel and will also cause problems when integration into OpenWrt. Also when having an own implementations of common features like firmware loading from userspace into the driver instead of using the framework provided by the Linux kernel will cause problems in the code review for LEDE inclusion and has to be changed when it should be added to mainline Linux kernel. The driver should not have build time options to work with either the one chip or the other. Whenever possible it should automatically probe for the hardware and detect if the hardware it supports is there and which chip this is at runtime. If it is possible to have more than one instance of this device connected to a SoC like it is the case on a PCIe card the driver should work with multiple devices and the number should be detected at runtime. Runtime detection could be done based on PCI IDs, device tree and so on. it has to be possible to run the same binary kernel on all boards using the same SoC, it is preferred if the same binary can also be used for different SoCs, which is the case for most SoCs supported by LEDE.
  • Last modified: 2018/05/28 09:19
  • by bobafetthotmail