Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revisionLast revisionBoth sides next revision | ||
| playground:company_interaction [2016/10/18 22:03] – hauke | inbox:company_interaction [2018/05/28 05:57] – ↷ Page moved from playground:company_interaction to inbox:company_interaction tmomas | ||
|---|---|---|---|
| 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, | + | This guide is targeted at chip vendors, board manufacturers, |
| 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 | + | 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 |
| 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. | ||