0

目前正在为带有 S3C6410 CPU 的 SBC 开发板支持包。该板的供应商只提供了对 2.6 内核的支持，我正在尝试迁移到更新的 3.x 内核。不幸的是，我一直遇到一些问题，因为后者的内核没有正确支持许多设备。例如，USB 支持对项目至关重要。我可以让它与 3.0.x 系列一起使用，但 3.2.x 及更高版本无法正常运行。我搜索了补丁/更新无济于事，所以我卷起袖子，在内核源代码中弄脏了。

我注意到内核树arch/arm/plat-samsung（例如，

Linux 3.0.80arch/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

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

Linux 3.2.48arch/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+ 系列的变化？
4

1 回答 1

3

我无法回答您的第一个问题，但我会尝试回答您的第二个和第三个问题。

您所经历的实际上是内核开发的一个非常正常的部分。Linux 的开发速度非常快，没有时间放慢速度让供应商赶上。内核不断被改进，因此，代码可能会被改组，API 完全修改，函数添加、重命名或删除等......如果没有发生，那么试图保持向后兼容性就会浪费很多精力. 换句话说，主线内核的开发人员并不关心供应商的 Linux 分支——他们只关心主线内核中的代码。

不幸的是，您可以避免这种情况的唯一方法是让您的供应商将您的平台支持发送到上游，以便在端口完成后立即将其放入主线，并由其他编码人员维护（而不是像您正在做的那样）现在）。这样，当您的平台由于其他编码人员所做的某些更改而出现问题时，通常由该人来修复您的代码。

阅读Stable API Nonsense以了解更多关于 Linux 开发以这种方式工作的原因。

为了回答您的第三个问题，Kernel Newbies 维护了您可以查找的每个主要 Linux 版本的简短变更日志。

http://kernelnewbies.org/Linux_3.2

http://kernelnewbies.org/Linux_3.1

http://kernelnewbies.org/Linux_3.0

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

于 2013-07-10T01:48:54.647 回答