为什么某些SoC设备的内核支持似乎被从3.0内核更改为3.2内核破坏了呢？

Question

目前正在为带有S3C6410 CPU的SBC开发一个板支持包。董事会的供应商只提供了2.6内核的支持，我正在尝试迁移到一个更新的3.x内核。不幸的是，我经常遇到一些设备在后面的内核中不被正确支持的问题。例如，USB支持对于项目至关重要。我可以让它与3.0.x系列一起工作，但是3.2.x和更高版本并没有正确地出现。我已经搜索了补丁/更新，但没有结果，所以我卷起袖子，在内核源代码中变得又脏又脏。

我注意到内核树(arch/arm/plat-samsung)发生了重大变化，以前存在多个模块，每个受支持的设备都有一个，现在有一个单块模块，它包含对所有模块的支持。例如,

Linux3.0.80 arch/arm/plat-samsung/dev-usb-hsotg.c

#include <linux/kernel.h>
#include <linux/string.h>
#include <linux/platform_device.h>
#include <linux/dma-mapping.h>

#include <mach/irqs.h>
#include <mach/map.h>

#include <plat/devs.h>

static struct resource s3c_usb_hsotg_resources[] = {
        [0] = {
                .start  = S3C_PA_USB_HSOTG,
                .end    = S3C_PA_USB_HSOTG + 0x10000 - 1,
                .flags  = IORESOURCE_MEM,
        },
        [1] = {
                .start  = IRQ_OTG,
                .end    = IRQ_OTG,
                .flags  = IORESOURCE_IRQ,
        },
};

static u64 s3c_hsotg_dmamask = DMA_BIT_MASK(32);

struct platform_device s3c_device_usb_hsotg = {
        .name           = "s3c-hsotg",
        .id             = -1,
        .num_resources  = ARRAY_SIZE(s3c_usb_hsotg_resources),
        .resource       = s3c_usb_hsotg_resources,
        .dev            = {
                .dma_mask               = &s3c_hsotg_dmamask,
                .coherent_dma_mask      = DMA_BIT_MASK(32),
        },
};

此文件已被删除，支持已转移到arch/arm/plat-samsung/devs.c中。

但是，在将原始代码与更新的内核中的代码进行比较时.

Linux3.2.48 arch/arm/plat-samsung/devs.c

/* USB HSOTG */

#ifdef CONFIG_S3C_DEV_USB_HSOTG
static struct resource s3c_usb_hsotg_resources[] = {
        [0] = DEFINE_RES_MEM(S3C_PA_USB_HSOTG, SZ_16K),
        [1] = DEFINE_RES_IRQ(IRQ_OTG),
};

struct platform_device s3c_device_usb_hsotg = {
        .name           = "s3c-hsotg",
        .id             = -1,
        .num_resources  = ARRAY_SIZE(s3c_usb_hsotg_resources),
        .resource       = s3c_usb_hsotg_resources,
        .dev            = {
                .dma_mask               = &samsung_device_dma_mask,
                .coherent_dma_mask      = DMA_BIT_MASK(32),
        },
};
#endif /* CONFIG_S3C_DEV_USB_HSOTG */

..。在我天真的眼睛里，驱动程序发生了一些变化，看起来就像虫子：

• s3c_usb_hsotg_resources[0]的内存大小由64K变为16K。
• s3c_device_usb_hsotg.dev.dma_mask不再使用本地u64变量，而是使用对多个platform_device结构共享的变量的引用。

现在，尽管在两个月的大部分时间里，我一直在搜索内核代码，但在驱动程序开发方面，我仍然是个菜鸟。内存大小的更改很可能是合理的，并且是由目前支持该模块的人所做的部分更改，但我担心的是，使用单个共享u64变量的引用是否会导致我在这个特定设备上看到的一些问题，等等。在USB驱动程序的情况下，我看到当我打开板时它会加载，但是它从来不会检测到任何连接到它的设备。我已经证实，这不是一个硬件相关的问题，因为设备是正确识别的2.6和3.0内核。因此，这使我倾向于它是由较新的内核代码造成的。

所以,

1. 有人知道这个共享引用是否是问题的罪魁祸首吗？
2. 有人能解释一下为什么内核源代码会发生如此剧烈的变化吗？
3. 是否有一些简明的资源(链接、书籍等)涵盖了内核设备驱动程序从3.0系列到3.2+系列的变化？

Answer 1

我不能回答你的第一个问题，但我会尝试回答你的第二个和第三个问题。

实际上，您正在体验的是内核开发的一个非常正常的部分。Linux的开发速度非常快，厂商没有时间放慢脚步。内核不断得到改进，因此，代码可能会被洗牌，API会完全修改，函数会被添加、重命名或删除等等.如果没有做到这一点，那么试图保持向后兼容性就会浪费大量的精力。换句话说，主线内核的开发人员并不关心供应商的Linux分叉--他们只关心主线内核中的代码。

不幸的是，您可以避免这种情况的唯一方法是让您的供应商将您的平台支持发送到上游，以便在端口完成后立即将其导入主流，然后由其他编码人员维护它(而不是您现在所做的)。这样的话，当你的平台因为另一个程序员的改变而崩溃时，通常是由那个人来修复你的代码。

有关Linux开发为什么采用这种方式的更多信息，请阅读稳定API无意义。

为了回答您的第三个问题，Kernel新手对您可以查找的Linux的每个主要版本都进行了简短的更改。

3.2

3.1

3.0

对于更细粒度的内容，您必须在git提交日志中钓鱼。