I'm trying to write descriptor-based GPIO interface in x86 from linux driver development book by john madieu i came to know

" With the descriptor-based interface, prior to allocating and taking the ownership of GPIOs, those GPIOs must have been mapped somewhere. By mapped, I mean they should be assigned to your device, whereas, with the legacy integer-based interface, you just have to fetch a number anywhere and request it as a GPIO. Actually, there are three kinds of mapping in the kernel "

i decided to choose "Platform data mapping" method to mapping to kernel, for that i have gone through document https://djwong.org/docs/kdoc/driver-api/gpio/board.html

it mentioned gpiod_lookup_table gpios_table() can used to update lookup table for that following hedder should included

include

in my code i included the above header while compiling i got error

fatal error: linux/gpio/machine.h: No such file or directory

can anyone please help to figure it out

i'm using kernel version 3.10

My requirement is to handle interrupt which mapped to cpu GPIO

For that I'm following "descriptor-based GPIO interface" based approach"

I came to know with the descriptor-based interface, prior to allocating and taking the ownership of GPIOs, those GPIOs must have been mapped somewhere. By mapped, I mean they should be assigned to your device, whereas, with the legacy integer-based interface, you just have to fetch a number anywhere and request it as a GPIO. Actually, there are three kinds of mapping in the kernel

Platform data mapping: The mapping is done in the board file.

Device tree: The mapping is done in DT style, as discussed in the preceding sections. This is the mapping we will discuss in this book.

Advanced Configuration and Power Interface mapping (ACPI): The mapping is done in ACPI style. Generally used on x86-based systems.

can anyone please guide me how to map using "Advanced Configuration and Power Interface mapping (ACPI)" method form kernel

I'm creating a character device module that plays a game of Tic-tac-toe. I'm trying to program it so it sets it's /dev/ticactoe mode to 666, instead of having a user use the chmod command.

My main.c contains the following with implementations of tictactoe's init and exit (redacted for conciseness):

static dev_t device_number;static struct cdev our_cdev;static struct class* my_class = NULL;static struct file_operations fops = {.owner = THIS_MODULE,.read = tictactoe_read,.write = tictactoe_write,.open = tictactoe_open,.release = tictactoe_release,};

I have a tictactoe.h containing the following:

#define MODULE_NAME "tictactoe"int tictactoe_open(struct inode *pinode, struct file *pfile);ssize_t tictactoe_read(struct file *pfile, char __user *buffer, size_t length, loff_t *offset);ssize_t tictactoe_write(struct file *pfile, const char __user *buffer, size_t length, loff_t *offset);int tictactoe_release(struct inode *pinode, struct file *pfile);

I read about umode_t, but I'm not sure how I might use that for this module. Can anyone lead me in the right direction or explain how to implement the umode_t variable? Any help is appreciated.

So if I set a process's CPU affinity using:

sched_setaffinity()

and then perform some other system call using that process, is that system call ALSO guaranteed to execute on the same CPU enforced by sched_setaffinity?

Essentially, I'm trying to enforce that a process, and the system calls it makes, are executed on the same core. Obviously I can use sched_setaffinity() to enforce userspace code will execute on only one CPU, but does that same system call enforce kernel-space code in that process context will execute on the same core as well?

Thanks!

I am writing a driver and I need to know what disk/partition contains the root filesystem. This can be viewed from userspace using:

cat /proc/cmdline root=/dev/mmcblk0p1

How can I get the value of root in kernel space?

I am analyzing a kdump on crash utility on RHEL for the first time. The default syntax with disassembe is Intel style. How to change that to AT&T syntax?

I tried searching the internet as well as reading the documentation (here) but could not find a way.

I am currently refactoring a driver for the AMD Sensor Fusion Hub.The original driver can be found here.When sending commands to the device, the chip takes some time to process the request. I wasusing a hack using msleep to wait for the device to respond. However I'd like to cleanly implement IRQ handling. As a template I looked into the implementation of drivers/i2c/busses/i2c-amd-mp2-pci.c and came up with the following stub interrupt handling.

/* * AMD Sensor Fusion Hub (SFH) PCIe driver * * Authors: Shyam Sundar S K <Shyam-sundar.S-k@amd.com> *          Nehal Bakulchandra Shah <Nehal-bakulchandra.Shah@amd.com> *          Richard Neumann <mail@richard-neumann.de> */#include <linux/bitops.h>#include <linux/dma-mapping.h>#include <linux/interrupt.h>#include <linux/io-64-nonatomic-lo-hi.h>#include <linux/module.h>#include <linux/pci.h>#include <linux/pm_runtime.h>#include <linux/types.h>#include "amd-sfh-pci.h"/** * amd_sfh_get_sensor_mask - Returns the sensors mask. * @pci_dev:    The Sensor Fusion Hub PCI device * * Returns an unsigned integer representing the bitmask to match * the sensors connected to the Sensor Fusion Hub. */int amd_sfh_get_sensor_mask(struct pci_dev *pci_dev){    int sensor_mask;    struct amd_sfh_dev *sfh_dev = pci_get_drvdata(pci_dev);    sensor_mask = readl(sfh_dev->mmio + AMD_SFH_SENSOR_MASK);    /* Correct bit shift in firmware register */    sensor_mask = sensor_mask >> 4;    if (!sensor_mask)        dev_err(&pci_dev->dev, "no sensors marked active on device\n");    return sensor_mask;}EXPORT_SYMBOL_GPL(amd_sfh_get_sensor_mask);/** * amd_sfh_start_sensor- Starts the respective sensor. * @pci_dev:    The Sensor Fusion Hub PCI device * @sensor_idx: The sensor's index * @dma_handle: The DMA handle */void amd_sfh_start_sensor(struct pci_dev *pci_dev, enum sensor_idx sensor_idx,                          dma_addr_t dma_handle){    struct amd_sfh_dev *sfh_dev = pci_get_drvdata(pci_dev);    union amd_sfh_cmd command;    union amd_sfh_parm parameter;    command.ul = 0;    command.s.cmd_id = enable_sensor;    command.s.period = PERIOD;    command.s.sensor_id = sensor_idx;    parameter.ul = 0;    parameter.s.buffer_layout = 1;    parameter.s.buffer_length = 16;    writeq(dma_handle, sfh_dev->mmio + AMD_SFH_ADDR);    writel(parameter.ul, sfh_dev->mmio + AMD_SFH_PARM);    writel(command.ul, sfh_dev->mmio + AMD_SFH_CMD);}EXPORT_SYMBOL_GPL(amd_sfh_start_sensor);/** * amd_sfh_stop_sensor- Stops the respective sensor. * @pci_dev:    The Sensor Fusion Hub PCI device * @sensor_idx: The sensor's index */void amd_sfh_stop_sensor(struct pci_dev *pci_dev, enum sensor_idx sensor_idx){    struct amd_sfh_dev *sfh_dev = pci_get_drvdata(pci_dev);    union amd_sfh_cmd command;    command.ul = 0;    command.s.cmd_id = disable_sensor;    command.s.period = 0;    command.s.sensor_id = sensor_idx;    writeq(0x0, sfh_dev->mmio + AMD_SFH_ADDR);    writel(command.ul, sfh_dev->mmio + AMD_SFH_CMD);}EXPORT_SYMBOL_GPL(amd_sfh_stop_sensor);/** * amd_sfh_stop_all_sensors- Stops all sensors on the SFH. * @pci_dev:    The Sensor Fusion Hub PCI device */static void amd_sfh_stop_all_sensors(struct pci_dev *pci_dev){    struct amd_sfh_dev *sfh_dev = pci_get_drvdata(pci_dev);    union amd_sfh_cmd command;    command.ul = 0;    command.s.cmd_id = stop_all_sensors;    command.s.period = 0;    command.s.sensor_id = 0;    writel(command.ul, sfh_dev->mmio + AMD_SFH_CMD);}/** * amd_sfh_irq_isr - IRQ handler * @irq:    The IRQ number received * @dev:    The underlying device */static irqreturn_t amd_sfh_irq_isr(int irq, void *dev){    struct amd_sfh_dev *sfh_dev = dev;    dev_info(&sfh_dev->pci_dev->dev, "got IRQ: %d\n", irq);    return IRQ_NONE;}/** * amd_sfh_pci_init - Initializes the PCI device * @sfh_dev:    The device data * @pci_dev:    The PCI device */static int amd_sfh_pci_init(struct amd_sfh_dev *sfh_dev,                            struct pci_dev *pci_dev){    int rc;    pci_set_drvdata(pci_dev, sfh_dev);    rc = pcim_enable_device(pci_dev);    if (rc)        goto err_pci_enable;    rc = pcim_iomap_regions(pci_dev, BIT(2), pci_name(pci_dev));    if (rc)        goto err_pci_enable;    sfh_dev->pci_dev = pci_dev;    sfh_dev->mmio = pcim_iomap_table(pci_dev)[2];    pci_set_master(pci_dev);    rc = pci_set_dma_mask(pci_dev, DMA_BIT_MASK(64));    if (rc) {        rc = pci_set_dma_mask(pci_dev, DMA_BIT_MASK(32));        if (rc)            goto err_dma_mask;    }    /* Set up intx irq */    writel(0, sfh_dev->mmio + AMD_P2C_MSG_INTEN);    pci_intx(pci_dev, 1);    dev_info(&pci_dev->dev, "available interrupt: %d\n", pci_dev->irq);    rc = devm_request_irq(&pci_dev->dev, pci_dev->irq, amd_sfh_irq_isr,                  0, dev_name(&pci_dev->dev), sfh_dev);    if (rc)        dev_err(&pci_dev->dev, "Failure requesting irq %i: %d\n",            pci_dev->irq, rc);    return rc;err_dma_mask:    pci_clear_master(pci_dev);err_pci_enable:    return rc;}static int amd_sfh_pci_probe(struct pci_dev *pci_dev,                 const struct pci_device_id *id){    int rc;    struct amd_sfh_dev *sfh_dev;    sfh_dev = devm_kzalloc(&pci_dev->dev, sizeof(*sfh_dev), GFP_KERNEL);    if (!sfh_dev)        return -ENOMEM;    rc = amd_sfh_pci_init(sfh_dev, pci_dev);    if (rc)        return rc;    pm_runtime_set_autosuspend_delay(&pci_dev->dev, 1000);    pm_runtime_use_autosuspend(&pci_dev->dev);    pm_runtime_put_autosuspend(&pci_dev->dev);    pm_runtime_allow(&pci_dev->dev);    dev_info(&pci_dev->dev, "SFH device registered.\n");    return 0;}static void amd_sfh_pci_remove(struct pci_dev *pci_dev){    struct amd_sfh_dev *sfh_dev = pci_get_drvdata(pci_dev);    amd_sfh_stop_all_sensors(sfh_dev->pci_dev);    pm_runtime_forbid(&pci_dev->dev);    pm_runtime_get_noresume(&pci_dev->dev);    pci_intx(pci_dev, 0);    pci_clear_master(pci_dev);}static const struct pci_device_id amd_sfh_pci_tbl[] = {    {PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_SFH)},    {0}};MODULE_DEVICE_TABLE(pci, amd_sfh_pci_tbl);static struct pci_driver amd_sfh_pci_driver = {    .name       = "amd-sfh-pci",    .id_table   = amd_sfh_pci_tbl,    .probe      = amd_sfh_pci_probe,    .remove     = amd_sfh_pci_remove,};module_pci_driver(amd_sfh_pci_driver);/** * amd_sfh_find_device - Returns the first best AMD SFH device. */struct amd_sfh_dev *amd_sfh_find_device(void){    struct device *dev;    struct pci_dev *pci_dev;    dev = driver_find_next_device(&amd_sfh_pci_driver.driver, NULL);    if (!dev)        return NULL;    pci_dev = to_pci_dev(dev);    return pci_get_drvdata(pci_dev);}EXPORT_SYMBOL_GPL(amd_sfh_find_device);MODULE_DESCRIPTION("AMD(R) Sensor Fusion Hub PCI driver");MODULE_AUTHOR("Shyam Sundar S K <Shyam-sundar.S-k@amd.com>");MODULE_AUTHOR("Nehal Bakulchandra Shah <Nehal-bakulchandra.Shah@amd.com>");MODULE_AUTHOR("Richard Neumann <mail@richard-neumann.de>");MODULE_LICENSE("Dual BSD/GPL");

However the dev_info from amd_sfh_irq_isr is never logged, so I suspect that the IRQ is never triggered when writing to the device registers. What can be the reason for that and what can I do to correctly implement the IRQ handling?

PSdmesg output:

[ 2272.642762] amd-sfh-pci 0000:04:00.7: available interrupt: 56[ 2272.642840] amd-sfh-pci 0000:04:00.7: SFH device registered.

I am just starting to learn linux kernel driver programming and I have the task of transferring a data stream from android to Linux via bluetooth. I already made an android application that opens a bluetooth socket and searches for devices.

Now I need to make a kernel driver that opens the server socket with a specific UUID and which will write the received data to a file (in my case, the date will be four values ​​of type int).

My questions:

1. How to open a bluetooth server socket with specific UUID?

2. How to accept the connection?

3. How to get the received data?

(I understand that it`s better to do in the form of a regular program, but I need to do this precisely in the form of a kernel driver)

Thanks in advance for any help!

I am working on custom board part of that, we are changing DDR controller presented in the Board imx6ull boardQuestion1. what are all changes to make new DDR controller up2. What are other controllers depend DDR controller in u-boot code.3. What is meant by DDR calibration in SoC 4. What is DDR controller IC name used in existing board

I have gone through u-boot code,DDR init is present with .c file as spl_ddr_init() --> mx6ul_dram_iocfg() & mx6_dram_cfg()

Board name: imx6ul_14x14_evk board

Can you please provide information with doc.s/links to understand the same.

Thanks in advance.

RegardsSatish G

My probe function is not invoked, when I added unit address and reg property in device tree. I have a module prototype:

#include <linux/init.h>#include <linux/module.h>#include <linux/kernel.h>#include <linux/miscdevice.h>#include <linux/platform_device.h>#ifdef CONFIG_OF#include <linux/of.h>#include <linux/of_platform.h>#endifstatic int ect_probe(struct platform_device *pdev) {    struct device *dev = &pdev->dev;    struct device_node *np = dev->of_node;    pr_info("We 're in probe function\n");    pr_info("Reading device tree values\n");    u32 parameter_address;    if (of_property_read_u32(np, "parameter_address", &parameter_address)) {            return -EINVAL;    }    pr_info("parameter_address is: %d\n", parameter_address);    return 0;}static int ect_remove(struct platform_device *pdev){    return -EBUSY;}static struct of_device_id ect_of_device_ids[] = {    {.compatible = "exynos", },    {},};static struct platform_device_id ect_plat_device_ids[] = {    {.name = "ect"},    {},};static struct platform_driver ect_parser = {        .probe = ect_probe,        .remove = ect_remove,        .id_table = ect_plat_device_ids,        .driver = {                .name = "ect",                .owner = THIS_MODULE,                .of_match_table = ect_of_device_ids,        },};static int __init ect_init(void){    printk(KERN_INFO "Init ECT module\n");    return platform_driver_register(&ect_parser);}static void ect_exit(void) {    printk(KERN_INFO "Exit ECT module\n");}module_init(ect_init)module_exit(ect_exit)MODULE_LICENSE("GPL");MODULE_AUTHOR("Unknown samsung developer");MODULE_DESCRIPTION("Samsung Exynos calibration table parser module.");MODULE_VERSION("0.01");

And corresponding entry in device tree root:

ect@67FEB000 {        compatible = "exynos,ect";        reg = <0x00 0x67FEB000 0x00 0x14000>;        parameter_address = <0x67FEB000>;        parameter_size = <0x14000>;    };

When booting, I can see, that ect_init function is called, so I assume, that driver is registered. But probe function is NOT called for some reason.

At the same time, probe function IS called with this device tree entry

ect {        compatible = "exynos,ect";        parameter_address = <0x67FEB000>;        parameter_size = <0x14000>;    };

I thought upon match of compatible property in device and driver linux should execute a probe function.

Why does unit address and reg property broke device-driver matching?

Full device tree:

/dts-v1/;/ {    interrupt-parent = < 0x8001 >;    #size-cells = < 0x02 >;    #address-cells = < 0x02 >;    compatible = "linux,dummy-virt";    psci {        migrate = < 0xc4000005 >;        cpu_on = < 0xc4000003 >;        cpu_off = < 0x84000002 >;        cpu_suspend = < 0xc4000001 >;        method = "hvc";        compatible = "arm,psci-0.2\0arm,psci";    };    ect@67FEB000 {            compatible = "exynos,ect";            reg = <0x00 0x67FEB000 0x00 0x14000>;            parameter_address = <0x67FEB000>;            parameter_size = <0x14000>;        };    memory@40000000 {        reg = < 0x00 0x40000000 0x00 0x10000000 >;        device_type = "memory";    };    platform@c000000 {        interrupt-parent = < 0x8001 >;        ranges = < 0x00 0x00 0xc000000 0x2000000 >;        #address-cells = < 0x01 >;        #size-cells = < 0x01 >;        compatible = "qemu,platform\0simple-bus";    };    fw-cfg@9020000 {        dma-coherent;        reg = < 0x00 0x9020000 0x00 0x18 >;        compatible = "qemu,fw-cfg-mmio";    };    virtio_mmio@a000000 {        dma-coherent;        interrupts = < 0x00 0x10 0x01 >;        reg = < 0x00 0xa000000 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a000200 {        dma-coherent;        interrupts = < 0x00 0x11 0x01 >;        reg = < 0x00 0xa000200 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a000400 {        dma-coherent;        interrupts = < 0x00 0x12 0x01 >;        reg = < 0x00 0xa000400 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a000600 {        dma-coherent;        interrupts = < 0x00 0x13 0x01 >;        reg = < 0x00 0xa000600 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a000800 {        dma-coherent;        interrupts = < 0x00 0x14 0x01 >;        reg = < 0x00 0xa000800 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a000a00 {        dma-coherent;        interrupts = < 0x00 0x15 0x01 >;        reg = < 0x00 0xa000a00 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a000c00 {        dma-coherent;        interrupts = < 0x00 0x16 0x01 >;        reg = < 0x00 0xa000c00 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a000e00 {        dma-coherent;        interrupts = < 0x00 0x17 0x01 >;        reg = < 0x00 0xa000e00 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a001000 {        dma-coherent;        interrupts = < 0x00 0x18 0x01 >;        reg = < 0x00 0xa001000 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a001200 {        dma-coherent;        interrupts = < 0x00 0x19 0x01 >;        reg = < 0x00 0xa001200 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a001400 {        dma-coherent;        interrupts = < 0x00 0x1a 0x01 >;        reg = < 0x00 0xa001400 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a001600 {        dma-coherent;        interrupts = < 0x00 0x1b 0x01 >;        reg = < 0x00 0xa001600 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a001800 {        dma-coherent;        interrupts = < 0x00 0x1c 0x01 >;        reg = < 0x00 0xa001800 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a001a00 {        dma-coherent;        interrupts = < 0x00 0x1d 0x01 >;        reg = < 0x00 0xa001a00 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a001c00 {        dma-coherent;        interrupts = < 0x00 0x1e 0x01 >;        reg = < 0x00 0xa001c00 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a001e00 {        dma-coherent;        interrupts = < 0x00 0x1f 0x01 >;        reg = < 0x00 0xa001e00 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a002000 {        dma-coherent;        interrupts = < 0x00 0x20 0x01 >;        reg = < 0x00 0xa002000 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a002200 {        dma-coherent;        interrupts = < 0x00 0x21 0x01 >;        reg = < 0x00 0xa002200 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a002400 {        dma-coherent;        interrupts = < 0x00 0x22 0x01 >;        reg = < 0x00 0xa002400 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a002600 {        dma-coherent;        interrupts = < 0x00 0x23 0x01 >;        reg = < 0x00 0xa002600 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a002800 {        dma-coherent;        interrupts = < 0x00 0x24 0x01 >;        reg = < 0x00 0xa002800 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a002a00 {        dma-coherent;        interrupts = < 0x00 0x25 0x01 >;        reg = < 0x00 0xa002a00 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a002c00 {        dma-coherent;        interrupts = < 0x00 0x26 0x01 >;        reg = < 0x00 0xa002c00 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a002e00 {        dma-coherent;        interrupts = < 0x00 0x27 0x01 >;        reg = < 0x00 0xa002e00 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a003000 {        dma-coherent;        interrupts = < 0x00 0x28 0x01 >;        reg = < 0x00 0xa003000 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a003200 {        dma-coherent;        interrupts = < 0x00 0x29 0x01 >;        reg = < 0x00 0xa003200 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a003400 {        dma-coherent;        interrupts = < 0x00 0x2a 0x01 >;        reg = < 0x00 0xa003400 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a003600 {        dma-coherent;        interrupts = < 0x00 0x2b 0x01 >;        reg = < 0x00 0xa003600 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a003800 {        dma-coherent;        interrupts = < 0x00 0x2c 0x01 >;        reg = < 0x00 0xa003800 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a003a00 {        dma-coherent;        interrupts = < 0x00 0x2d 0x01 >;        reg = < 0x00 0xa003a00 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a003c00 {        dma-coherent;        interrupts = < 0x00 0x2e 0x01 >;        reg = < 0x00 0xa003c00 0x00 0x200 >;        compatible = "virtio,mmio";    };    virtio_mmio@a003e00 {        dma-coherent;        interrupts = < 0x00 0x2f 0x01 >;        reg = < 0x00 0xa003e00 0x00 0x200 >;        compatible = "virtio,mmio";    };    gpio-keys {        #address-cells = < 0x01 >;        #size-cells = < 0x00 >;        compatible = "gpio-keys";        poweroff {            gpios = < 0x8003 0x03 0x00 >;            linux,code = < 0x74 >;            label = "GPIO Key Poweroff";        };    };    pl061@9030000 {        phandle = < 0x8003 >;        clock-names = "apb_pclk";        clocks = < 0x8000 >;        interrupts = < 0x00 0x07 0x04 >;        gpio-controller;        #gpio-cells = < 0x02 >;        compatible = "arm,pl061\0arm,primecell";        reg = < 0x00 0x9030000 0x00 0x1000 >;    };    pcie@10000000 {        interrupt-map-mask = < 0x1800 0x00 0x00 0x07 >;        interrupt-map = < 0x00 0x00 0x00 0x01 0x8001 0x00 0x00 0x00 0x03 0x04 0x00 0x00 0x00 0x02 0x8001 0x00 0x00 0x00 0x04 0x04 0x00 0x00 0x00 0x03 0x8001 0x00 0x00 0x00 0x05 0x04 0x00 0x00 0x00 0x04 0x8001 0x00 0x00 0x00 0x06 0x04 0x800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00 0x04 0x04 0x800 0x00 0x00 0x02 0x8001 0x00 0x00 0x00 0x05 0x04 0x800 0x00 0x00 0x03 0x8001 0x00 0x00 0x00 0x06 0x04 0x800 0x00 0x00 0x04 0x8001 0x00 0x00 0x00 0x03 0x04 0x1000 0x00 0x00 0x01 0x8001 0x00 0x00 0x00 0x05 0x04 0x1000 0x00 0x00 0x02 0x8001 0x00 0x00 0x00 0x06 0x04 0x1000 0x00 0x00 0x03 0x8001 0x00 0x00 0x00 0x03 0x04 0x1000 0x00 0x00 0x04 0x8001 0x00 0x00 0x00 0x04 0x04 0x1800 0x00 0x00 0x01 0x8001 0x00 0x00 0x00 0x06 0x04 0x1800 0x00 0x00 0x02 0x8001 0x00 0x00 0x00 0x03 0x04 0x1800 0x00 0x00 0x03 0x8001 0x00 0x00 0x00 0x04 0x04 0x1800 0x00 0x00 0x04 0x8001 0x00 0x00 0x00 0x05 0x04 >;        #interrupt-cells = < 0x01 >;        ranges = < 0x1000000 0x00 0x00 0x00 0x3eff0000 0x00 0x10000 0x2000000 0x00 0x10000000 0x00 0x10000000 0x00 0x2eff0000 0x3000000 0x80 0x00 0x80 0x00 0x80 0x00 >;        reg = < 0x40 0x10000000 0x00 0x10000000 >;        msi-parent = < 0x8002 >;        dma-coherent;        bus-range = < 0x00 0xff >;        linux,pci-domain = < 0x00 >;        #size-cells = < 0x02 >;        #address-cells = < 0x03 >;        device_type = "pci";        compatible = "pci-host-ecam-generic";    };    pl031@9010000 {        clock-names = "apb_pclk";        clocks = < 0x8000 >;        interrupts = < 0x00 0x02 0x04 >;        reg = < 0x00 0x9010000 0x00 0x1000 >;        compatible = "arm,pl031\0arm,primecell";    };    pl011@9000000 {        clock-names = "uartclk\0apb_pclk";        clocks = < 0x8000 0x8000 >;        interrupts = < 0x00 0x01 0x04 >;        reg = < 0x00 0x9000000 0x00 0x1000 >;        compatible = "arm,pl011\0arm,primecell";    };    pmu {        interrupts = < 0x01 0x07 0x104 >;        compatible = "arm,armv8-pmuv3";    };    intc@8000000 {        phandle = < 0x8001 >;        reg = < 0x00 0x8000000 0x00 0x10000 0x00 0x8010000 0x00 0x10000 >;        compatible = "arm,cortex-a15-gic";        ranges;        #size-cells = < 0x02 >;        #address-cells = < 0x02 >;        interrupt-controller;        #interrupt-cells = < 0x03 >;        v2m@8020000 {            phandle = < 0x8002 >;            reg = < 0x00 0x8020000 0x00 0x1000 >;            msi-controller;            compatible = "arm,gic-v2m-frame";        };    };    flash@0 {        bank-width = < 0x04 >;        reg = < 0x00 0x00 0x00 0x4000000 0x00 0x4000000 0x00 0x4000000 >;        compatible = "cfi-flash";    };    cpus {        #size-cells = < 0x00 >;        #address-cells = < 0x01 >;        cpu@0 {            reg = < 0x00 >;            compatible = "arm,cortex-a57";            device_type = "cpu";        };    };    timer {        interrupts = < 0x01 0x0d 0x104 0x01 0x0e 0x104 0x01 0x0b 0x104 0x01 0x0a 0x104 >;        always-on;        compatible = "arm,armv8-timer\0arm,armv7-timer";    };    apb-pclk {        phandle = < 0x8000 >;        clock-output-names = "clk24mhz";        clock-frequency = < 0x16e3600 >;        #clock-cells = < 0x00 >;        compatible = "fixed-clock";    };    chosen {        bootargs = "ect root=/dev/vda console_msg_format=syslog nokaslr norandmaps panic=-1 printk.devkmsg=on printk.time=y rw console=ttyAMA0 - lkmc_home=/lkmc";        stdout-path = "/pl011@9000000";    };};

I have recently been reading about Linux Driver and Device Model. I wanted to understand how the following works in linux in the driver subsystem. So lets say my device tree looks as follows

To be concrete lets assume Bus1 is a PCI bus, Bus2 is ISA and Bus3 is USB. Buses are connected with each other using bridges.

Linux will identify this device tree through the enumeration process and through enumeration and probing mechanism suitable usb driver for terminal device would be identified.

Now lets assume a Tx operation to this terminal device. The terminal device usb driver would end up doing a urb_submit(dev, write_buffer).

My question is in order for the URB to reach the terminal device, theoretically it would have to be enveloped in Bus2 and Bus1 envelopes. So theoretically speaking the outgoing packet has to look something like this

So at some after the urb_submit happens in the driver, does some kernel code walk up the device tree structure and invoke the bus drivers in order (bus 2 driver and then bus 1 driver) to create this envelope structure.

Can anyone point me to the code in the linux kernel where this happens? I tried to follow urb_submit but could not figure this out.

Thanks a bunch!

I am trying to enable vrf in Linux kernel 4.9.135 version and have enabled IP_MULTIPLE_TABLES, NET_L3_MASTER_DEV and NET_VRF in kernel and build the kernel.

bash-4.3# zgrep "CONFIG_NET_VRF" /proc/config.gz  CONFIG_NET_VRF=mbash-4.3# zgrep "IP_MULTIPLE_TABLES" /proc/config.gz  CONFIG_IP_MULTIPLE_TABLES=ybash-4.3# zgrep "NET_L3_MASTER_DEV" /proc/config.gz  CONFIG_NET_L3_MASTER_DEV=y

I am using iproute2 version iproute2-4.9.0-r0.0.x86_64.rpm also which supports vrf.

But when I am trying to instantiate a VRF device and associate it with a table, I am getting RTNETLINK answers: operation not supported.

I checked through the strace and see RTNETLINK messages:

sendmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"H\0\0\0\20\0\5\6(\20\271\\\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 72}], msg_controllen=0, msg_flags=0}, 0) = 72recvmsg(3, {msg_name(12)={sa_family=AF_NETLINK, pid=0, groups=00000000}, msg_iov(1)=[{"\\\0\0\0\2\0\0\0(\20\271\\\302i\0\0\241\377\377\377H\0\0\0\20\0\5\6(\20\271\\"..., 32768}], msg_controllen=0, msg_flags=0}, 0) = 92write(2, "RTNETLINK answers: Operation not"..., 43RTNETLINK answers: Operation not supported

How to debug/resolve this problem?

I saw from this SO post that /proc/kallsyms should have the symbols of dynamically loaded modules as well as static code whereas System.map contains only the symbols of static code. However, when I cat /proc/kallsyms I seem to only have symbols in the text section of the kernel (T and t flags), save one or two symbols like

0000000000000000 D irq_stack_union0000000000000000 D __per_cpu_start

On the other hand, in System.map I have symbols from many sections - essentially everything from /proc/kallsyms except loaded kernel module symbols.

To show the magnitude of this difference I used the wc command.

user@debian:~/$ cat /boot/System.map-3.2.0-4-amd64 | wc  51256  153768 2117121user@debian:~/$ cat /proc/kallsyms | wc  29336   92637 1161409

What is the reason for this difference? Where are all of the data section related symbols in my /proc/kallsyms file?

Migrating from Buildroot 2015.08.03 with GCC 4.9.3/Make 3.81/gblibc 2.20 to a Buildroot 2020.02 setup to support GCC > 8.x/Make 4.1/glibc 2.30.
Encountered an issue with GCC 8.3 compiler when building a Linux 3.14.17 ARM Cortex-A9 kernel. Using GCC 7.5, the file in question builds (other issues debugging). Also builds fine with the GCC 4.9.3 compiler.Details below - more can be provided.Seems to be an issue with intermediate GCC generation, causing ASM to generate incorrect code?? Has anyone encountered this?
Tried different Kernel build options, no changes.

Thanks for your expertise and wisdom.Stephen Beckwith

Host System: VMWare Fusion setup on MAC OSX Mojave (10.14.6) on a 2014 vintage 15” Macbook Pro with a Core i7, 16GB RAM, 512GB SSD.
VM gets 4 cores (HT enabled) and 8GB RAMSources located on an external USB-3 HDD, where the VM is booted from and it’s Filesystems is located.VM is Ubuntu 18.04.01 - updated in Mid-March

sbeckwit@ubuntu:~$ uname -aLinux ubuntu 5.3.0-42-generic #34~18.04.1-Ubuntu SMP Fri Feb 28 13:42:26 UTC 2020 x86_64 x86_64 x86_64 GNU/Linuxsbeckwit@ubuntu:~$ gcc --versiongcc (Ubuntu 7.4.0-1ubuntu1~18.04.1) 7.4.0Copyright (C) 2017 Free Software Foundation, Inc.This is free software; see the source for copying conditions.  There is NOwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.sbeckwit@ubuntu:/lib32$ ldd --versionldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27Copyright (C) 2018 Free Software Foundation, Inc.This is free software; see the source for copying conditions.  There is NOwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.Written by Roland McGrath and Ulrich Drepper.

The setup:Our previous setup is a Buildroot 2015.08.03 setup.Using the original Buildroot setup - we use a Buildroot Built Compiler, version 4.9.3, glibc 2.20, Make 3.81. - This system builds our Embedded Linux setup, including kernel/uboot/busybox/utilites/applications.
- In this setup, everything builds just fine. - This system runs in a server environment on older RHEL 5.x based system.

The Linux Kernel we are building is a 3.14.17 kernel, with some 3rd party patches for specific SOC (EMULEX PIlot4 BMC, now owned by ASPEED - this is a dual-core ARM Cortex-A9 ARM SoC) - Build options are “stock” with the exception of the adding the -save-temps flag to get the .s output files.

New Setup:We are migrating to a newer Buildroot setup in order to mitigate recent CVE issues related to GLIBC and GCC. Therefore, we have put into place new buildroot setup:Buildroot 2020.02: - This supports building the following: GCC 7.5, GCC 8.3, GCC 9.2 Glibc 2.30 (the one we’ve chosen for now) Uses Make 4.1

Initially we built a GCC 9.2 Compiler and ran into the following error:

/tmp/ccxaGNai.s: Assembler messages:/tmp/ccxaGNai.s:2262: Error: .err encounteredarm-buildroot-linux-gnueabi-gcc.br_real: warning: /home/sbeckwit/sp_dev/bowie_dev/src/include: linker input file unused because linking not done  CC      security/keys/key.oscripts/Makefile.build:309: recipe for target 'kernel/fork.o' failed

• similar messages for kernel/exit.o and fs/fat/dir.o

Built a GCC 8.3 Compiler and ran into the exact same errors.

Built a GCC 7.5 Compiler and this error no longer exists (though we have other issues)

It was determined that in order to comply with Corporate Security policy, we are required to have GCC 8.x or above.

Therefore: - I re-setup the GCC 7.5 and obtained the .i/.s output files (using the -save-temps switch in the Kernel Makefile) - I then switched to the GCC 8.3 and obtained the same files.

GCC 8.3 Information:

sbeckwit@ubuntu:~/sp_dev/sp_archives/toolchains/arm8.x-toolchain/bin$ ./arm-arm-linux-gnueabi-gcc-8.3.0 --versionarm-arm-linux-gnueabi-gcc-8.3.0.br_real (Buildroot 2020.02) 8.3.0Copyright (C) 2019 Free Software Foundation, Inc.This is free software; see the source for copying conditions.  There is NOwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Error:

fork.s: Assembler messages:fork.s:2277: Error: .err encounteredscripts/Makefile.build:308: recipe for target 'kernel/fork.o' failed

This is in the function: mm_release()

.LBB1932:    .loc 8 110 35 is_stmt 0 view .LVU654    mov r2, sp    bic r2, r2, #8128    bic r2, r2, #63.LBE1932:.LBE1933:    .loc 1 784 278 view .LVU655    mov r0, r5.LVL102:    .loc 1 784 303 is_stmt 1 view .LVU656    .loc 1 784 39 is_stmt 0 view .LVU657    ldr r1, [r2, #8].LVL103:    .loc 1 784 326 view .LVU658    sub r1, r1, #1.LVL104:    .loc 1 784 351 is_stmt 1 view .LVU659    .loc 1 784 379 view .LVU660    .loc 1 784 947 view .LVU661    .syntax divided@ 784 "kernel/fork.c" 1    .ifnc r0,r0 ; .err ; .endif    **.ifnc r3,r2 ; .err ; .endif**    .ifnc r1,r1 ; .err ; .endif    bl  __put_user_4@ 0 "" 2.LVL105:

highlighted line is line 2277 from the error message

When I grep’d through the .s files generated for the 8.3 build, looking for the “.ifnc” in the current files. Yet, this file is the only file where this .ifnc has “different” registers: all other instances show the same register. Why is this one different.

From the fork.i file for this function:

# 747 "kernel/fork.c"void mm_release(struct task_struct *tsk, struct mm_struct *mm){ if (__builtin_expect(!!(tsk->robust_list), 0)) {  exit_robust_list(tsk);  tsk->robust_list = ((void *)0); } if (__builtin_expect(!!(!list_empty(&tsk->pi_state_list)), 0))  exit_pi_state_list(tsk); uprobe_free_utask(tsk); do { } while (0);# 777 "kernel/fork.c" if (tsk->clear_child_tid) {  if (!(tsk->flags & 0x00000400) &&      (*(volatile int *)&(&mm->mm_users)->counter) > 1) {   ({ might_fault(); ({ unsigned long __limit = current_thread_info()->addr_limit - 1; const typeof(*(tsk->clear_child_tid)) *__tmp_p = (tsk->clear_child_tid); register const typeof(*(tsk->clear_child_tid)) __r2 asm("r2") = (0); register const typeof(*(tsk->clear_child_tid)) *__p asm("r0") = __tmp_p; register unsigned long __l asm("r1") = __limit; register int __e asm("r0"); switch (sizeof(*(__p))) { case 1: __asm__ __volatile__ ( ".ifnc ""%0"",""r0"" ; .err ; .endif\n\t"".ifnc ""%2"",""r2"" ; .err ; .endif\n\t"".ifnc ""%3"",""r1"" ; .err ; .endif\n\t""bl    __put_user_""1" : "=&r" (__e) : "0" (__p), "r" (__r2), "r" (__l) : "ip", "lr", "cc"); break; case 2: __asm__ __volatile__ ( ".ifnc ""%0"",""r0"" ; .err ; .endif\n\t"".ifnc ""%2"",""r2"" ; .err ; .endif\n\t"".ifnc ""%3"",""r1"" ; .err ; .endif\n\t""bl  __put_user_""2" : "=&r" (__e) : "0" (__p), "r" (__r2), "r" (__l) : "ip", "lr", "cc"); break; case 4: __asm__ __volatile__ ( ".ifnc ""%0"",""r0"" ; .err ; .endif\n\t"".ifnc ""%2"",""r2"" ; .err ; .endif\n\t"".ifnc ""%3"",""r1"" ; .err ; .endif\n\t""bl  __put_user_""4" : "=&r" (__e) : "0" (__p), "r" (__r2), "r" (__l) : "ip", "lr", "cc"); break; case 8: __asm__ __volatile__ ( ".ifnc ""%0"",""r0"" ; .err ; .endif\n\t"".ifnc ""%2"",""r2"" ; .err ; .endif\n\t"".ifnc ""%3"",""r1"" ; .err ; .endif\n\t""bl  __put_user_""8" : "=&r" (__e) : "0" (__p), "r" (__r2), "r" (__l) : "ip", "lr", "cc"); break; default: __e = __put_user_bad(); break; } __e; }); });   sys_futex(tsk->clear_child_tid, 1,     1, ((void *)0), ((void *)0), 0);  }  tsk->clear_child_tid = ((void *)0); } if (tsk->vfork_done)  complete_vfork_done(tsk);}

ASSUME: - Given that the GCC 9.2.0 produces the same error, we are assuming that the same issue exists in this compiler as well.

GCC 7.5 Information:

sbeckwit@ubuntu:~/sp_dev/sp_archives/toolchains/arm7.5-toolchain/bin$ ./arm-buildroot-linux-gnueabi-gcc --versionarm-buildroot-linux-gnueabi-gcc.br_real (Buildroot 2020.02) 7.5.0Copyright (C) 2017 Free Software Foundation, Inc.This is free software; see the source for copying conditions.  There is NOwarranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

using the same generated error for reference:

fork.s: Assembler messages:fork.s:2277: Error: .err encounteredscripts/Makefile.build:308: recipe for target 'kernel/fork.o' failed

This is in the function: mm_release()

.LBE1879:    .loc 1 784 0    mov r2, r3.LVL102:    mov r0, r5.LVL103:    ldr r1, [r1, #8]    sub r1, r1, #1.LVL104:    .syntax divided@ 784 "kernel/fork.c" 1    .ifnc r0,r0 ; .err ; .endif    **.ifnc r2,r2 ; .err ; .endif**    .ifnc r1,r1 ; .err ; .endif    bl  __put_user_4@ 0 "" 2.LVL105:    .arm    .syntax unified

highlighted line correlates to the error above in the 8.3.0 compiler

From the fork.i file for this function:

# 747 "kernel/fork.c"void mm_release(struct task_struct *tsk, struct mm_struct *mm){ if (__builtin_expect(!!(tsk->robust_list), 0)) {  exit_robust_list(tsk);  tsk->robust_list = ((void *)0); } if (__builtin_expect(!!(!list_empty(&tsk->pi_state_list)), 0))  exit_pi_state_list(tsk); uprobe_free_utask(tsk); do { } while (0);# 777 "kernel/fork.c" if (tsk->clear_child_tid) {  if (!(tsk->flags & 0x00000400) &&      (*(volatile int *)&(&mm->mm_users)->counter) > 1) {   ({ might_fault(); ({ unsigned long __limit = current_thread_info()->addr_limit - 1; const typeof(*(tsk->clear_child_tid)) *__tmp_p = (tsk->clear_child_tid); register const typeof(*(tsk->clear_child_tid)) __r2 asm("r2") = (0); register const typeof(*(tsk->clear_child_tid)) *__p asm("r0") = __tmp_p; register unsigned long __l asm("r1") = __limit; register int __e asm("r0"); switch (sizeof(*(__p))) { case 1: __asm__ __volatile__ ( ".ifnc ""%0"",""r0"" ; .err ; .endif\n\t"".ifnc ""%2"",""r2"" ; .err ; .endif\n\t"".ifnc ""%3"",""r1"" ; .err ; .endif\n\t""bl    __put_user_""1" : "=&r" (__e) : "0" (__p), "r" (__r2), "r" (__l) : "ip", "lr", "cc"); break; case 2: __asm__ __volatile__ ( ".ifnc ""%0"",""r0"" ; .err ; .endif\n\t"".ifnc ""%2"",""r2"" ; .err ; .endif\n\t"".ifnc ""%3"",""r1"" ; .err ; .endif\n\t""bl  __put_user_""2" : "=&r" (__e) : "0" (__p), "r" (__r2), "r" (__l) : "ip", "lr", "cc"); break; case 4: __asm__ __volatile__ ( ".ifnc ""%0"",""r0"" ; .err ; .endif\n\t"".ifnc ""%2"",""r2"" ; .err ; .endif\n\t"".ifnc ""%3"",""r1"" ; .err ; .endif\n\t""bl  __put_user_""4" : "=&r" (__e) : "0" (__p), "r" (__r2), "r" (__l) : "ip", "lr", "cc"); break; case 8: __asm__ __volatile__ ( ".ifnc ""%0"",""r0"" ; .err ; .endif\n\t"".ifnc ""%2"",""r2"" ; .err ; .endif\n\t"".ifnc ""%3"",""r1"" ; .err ; .endif\n\t""bl  __put_user_""8" : "=&r" (__e) : "0" (__p), "r" (__r2), "r" (__l) : "ip", "lr", "cc"); break; default: __e = __put_user_bad(); break; } __e; }); });   sys_futex(tsk->clear_child_tid, 1,     1, ((void *)0), ((void *)0), 0);  }  tsk->clear_child_tid = ((void *)0); } if (tsk->vfork_done)  complete_vfork_done(tsk);}

The kernel code is the same. The Build options are the same.Difference is the compiler used, all other infrastructure utilities (i.e. Make 4.1) are the same.

If I have forgotten to include any information please let me know and I will provide it.

I am using this repo-branch for a RTL8188-EU wifi chip on my hardware that I am going to use an access point. https://github.com/lwfinger/rtl8188eu/tree/v4.1.8_9499

This branch is specifically being used as it builds with bitbake and incorporates into my yocto build. I know that it works because I can see the ssid broadcasting, and I can connect to it for a short time. However if two or more connections are made to it, or if my application requests too much data I get this in my syslog.

Mar  4 16:54:04 picozed dhcpd: DHCPACK on 10.10.0.151 to cc:2f:71:6a:73:18 (user) via wlan0Mar  4 16:54:37 picozed kernel: R8188EU: nolinked power save enterMar  4 16:54:38 picozed kernel: ==> rtl8188e_iol_efuse_patchMar  4 16:54:38 picozed kernel: R8188EU: nolinked power save leaveMar  4 16:54:38 picozed kernel: R8188EU: set group key to hw: alg:4(WEP40-1 WEP104-5 TKIP-2 AES-4) keyid:1Mar  4 16:54:38 picozed kernel: R8188EU: set pairwise key to hw: alg:4(WEP40-1 WEP104-5 TKIP-2 AES-4) camid:4Mar  4 16:54:38 picozed kernel: R8188EU: set pairwise key to hw: alg:4(WEP40-1 WEP104-5 TKIP-2 AES-4) camid:4

The hostapd that I am using is build also from the git repo there. I have added a few patches to disable bluetooth, and forcibly bypass the power save as well as limiting the MTU ( though I am not really sure what that does exactly ). However, even with that patch, you can still see that it attempts to go into the power save, do a efuse_patch process called by nothing apparently, and then leave power save. This correlates directly to each and every drop in the wifi connectivity. I am kind of at my wits end here as this is out of my depth.

I have attempted to disable power save using the modprobe.d/8188eu.conf options. These are what they are set as to attempt and disable the power management. I just need this thing to run constantly with at least 5 connected clients and not drop the connection or enter power save.

options 8188eu rtw_power_mgnt=0 rtw_enusbss=0

Below is my hostapd.conf (without the ssid and password, both are just lowercase words)

#Custom APD conf file. interface=wlan0driver=nl80211hw_mode=gchannel=1macaddr_acl=0auth_algs=1ignore_broadcast_ssid=0ieee80211n=1wpa=2wpa_key_mgmt=WPA-PSKwpa_pairwise=CCMPrsn_pairwise=CCMP

This is the patch that I am applying.

diff --git a/hostapd-0.8/src/drivers/driver_hostap.c b/hostapd-0.8/src/drivers/driver_hostap.cindex e855c1b..47d7610 100644--- a/hostapd-0.8/src/drivers/driver_hostap.c+++ b/hostapd-0.8/src/drivers/driver_hostap.c@@ -37,7 +37,7 @@ /* MTU to be set for the wlan#ap device; this is mainly needed for IEEE 802.1X  * frames that might be longer than normal default MTU and they are not  * fragmented */-#define HOSTAPD_MTU 2290+#define HOSTAPD_MTU 1000 static const u8 rfc1042_header[6] = { 0xaa, 0xaa, 0x03, 0x00, 0x00, 0x00 };diff --git a/os_dep/os_intfs.c b/os_dep/os_intfs.cindex e9ed317..f3874b0 100644--- a/os_dep/os_intfs.c+++ b/os_dep/os_intfs.c@@ -42,6 +42,11 @@ MODULE_DESCRIPTION("Realtek Wireless Lan Driver"); MODULE_AUTHOR("Realtek Semiconductor Corp."); MODULE_VERSION(DRIVERVERSION);+//Make sure bt is disabled.+#ifdef CONFIG_BT_COEXIST+  #undef CONFIG_BT_COEXIST+#endif+ /* module param defaults */ static int rtw_rfintfs = HWPI; static int rtw_lbkmode = 0;/* RTL8712_AIR_TRX; */@@ -59,14 +64,10 @@ static int rtw_preamble = PREAMBLE_LONG;/* long, short, auto */ static int rtw_scan_mode = 1;/* active, passive */ static int rtw_adhoc_tx_pwr = 1; static int rtw_soft_ap = 0;-/* int smart_ps = 1; */-#ifdef CONFIG_POWER_SAVING-static int rtw_power_mgnt = 1;-static int rtw_ips_mode = IPS_NORMAL;-#else++// sseppala : 12mar2020 turn off power saving on boot static int rtw_power_mgnt = PS_MODE_ACTIVE; static int rtw_ips_mode = IPS_NONE;-#endif static int rtw_smart_ps = 2;@@ -96,7 +97,8 @@ static int rtw_uapsd_acvi_en = 0; static int rtw_uapsd_acvo_en = 0; int rtw_ht_enable = 1;-int rtw_cbw40_enable = 3; /*  0 :diable, bit(0): enable 2.4g, bit(1): enable 5g */+// disable 5G for now. 12mar2020 -- sseppala+int rtw_cbw40_enable = 1; /*  0 :diable, bit(0): enable 2.4g, bit(1): enable 5g */ int rtw_ampdu_enable = 1;/* for enable tx_ampdu */ static int rtw_rx_stbc = 1;/*  0: disable, bit(0):enable 2.4g, bit(1):enable 5g, default is set to enable 2.4GHZ for IOT issue with bufflao's AP at 5GHZ */ static int rtw_ampdu_amsdu = 0;/*  0: disabled, 1:enabled, 2:auto */@@ -121,12 +123,8 @@ static int rtw_AcceptAddbaReq = true;/*  0:Reject AP's Add BA req, 1:Accept AP's static int rtw_antdiv_cfg = 2; /*  0:OFF , 1:ON, 2:decide by Efuse config */ static int rtw_antdiv_type = 0 ; /* 0:decide by efuse  1: for 88EE, 1Tx and 1RxCG are diversity.(2 Ant with SPDT), 2:  for 88EE, 1Tx and 2Rx are diversity.( 2 Ant, Tx and RxCG are both on aux port, RxCS is on main port ), 3: for 88EE, 1Tx and 1RxCG are fixed.(1Ant, Tx and RxCG are both on aux port) */--#ifdef CONFIG_USB_AUTOSUSPEND-static int rtw_enusbss = 1;/* 0:disable,1:enable */-#else+// sseppala 12mar2020 : disable enubss no matter what static int rtw_enusbss = 0;/* 0:disable,1:enable */-#endif static int rtw_hwpdn_mode=2;/* 0:disable,1:enable,2: by EFUSE config */

I am trying to build an array of type "struct scatterlist", from a buffer pointed by a virtual kernel address (I know the byte size of the buffer, but it may be large). Ideally I would like to have function like init_sg_array_from_buf:

void my_function(void *buffer, int buffer_length){    struct scatterlist *sg;    int sg_count;    sg_count = init_sg_array_from_buf(buffer, buffer_length, sg);}

Which function in the scatterlist api, does something similar? Currently the only possibility I see, is to manually determine the amount of pages, spanned by the buffer. Windows has a kernel macro called "ADDRESS_AND_SIZE_TO_SPAN_PAGES", but I didn't even manage to find something like this in the linux kernel.

I am trying to debug a linux kernel issue where I see too much slab_unreclaimable memory was allocated. How to find which process did that?

          active_anon:17389 inactive_anon:1921 isolated_anon:0           active_file:27246 inactive_file:20294 isolated_file:0           unevictable:16957 dirty:26 writeback:0 unstable:0           slab_reclaimable:139427 slab_unreclaimable:24565499           mapped:13342 shmem:11812 pagetables:5996 bounce:0           free:339932 free_pcp:2125 free_cma:0

I've been building a RTDM UART driver by using the Linux version as an example. The UART base address is supposed to be 0x80070000, and when using the linux driver there is no problem as dmesg show:

80070000.serial: ttyAPP3 at MMIO 0x80070000 (irq = 234, base_baud = 1500000) is a 80070000.serialmxs-auart 80070000.serial: Found APPUART 3.1.0

However, when I'm using the driver I'm builing I get a different adress each time I'm loading the module (such as 0xc8df6000) and none of them are correct.

Here's the probe function I'm using:

static int rt_mxs_auart_probe(struct platform_device *pdev){    const struct of_device_id *of_id =            of_match_device(mxs_auart_dt_ids, &pdev->dev);    int ret;    struct resource *r;    struct rtdm_device *dev;    struct rt_mxs_auart_port *s;    //allocate managed kernel memory    s = devm_kzalloc(&pdev->dev, sizeof(*s), GFP_KERNEL);    if (!s)        return -ENOMEM;    ret = rt_serial_mxs_probe_dt(s, pdev);    if (ret < 0){        return ret;        }    if (of_id) {        pdev->id_entry = of_id->data;        s->devtype = pdev->id_entry->driver_data;    }    r = platform_get_resource(pdev, IORESOURCE_MEM, 0);    if (!r)        return -ENXIO;    //get irq line    s->irq = platform_get_irq(pdev, 0);    if (s->irq < 0)        return -ENODEV;    //base memory    s->membase = ioremap(r->start, resource_size(r));    if (IS_ERR(s->membase))        return PTR_ERR(s->membase);    /*define the rtdm_device*/    dev = &s->rtdm_dev;    dev->driver = &ida_driver;    dev->label = "xeno_ida";    dev->device_data = s;    ret = mxs_get_clks(s, pdev); //activate clocks    if (ret)        return ret;    s->uartclk = clk_get_rate(s->clk);    s->fifosize = MXS_AUART_FIFO_SIZE;    mxs_init_regs(s);    ret = rtdm_dev_register(dev); //register driver in RTDM space    if (ret)        return ret;    platform_set_drvdata(pdev, s); //add device-related data to device struct    pr_info("Probe: Successful\n");    pr_info("%s on IMX UART%d: membase=0x%p irq=%d uartclk=%d\n",           dev->name, pdev->id, s->membase, s->irq, s->uartclk);    return 0;}

which is based on mxs-auart.c and rt_imx_uart.c.

For membase I'm using the same code as mxs-auart.c which is why I don't understand why I'm having this issue. My driver also freezes after some time when I try to rmmod it so I wonder if it is caused by this.

Would appreciate any help!

I'm try to make simple kernel module with multithreading.So I'm using linux/kthread.h, kernel v. 5.2.11

Problem: I can't passing the char array into thread: Segmentation fault.

That's what I'm doing:

typedef struct {    int num;     char origin[MAXSTR]; //part of input for current thread    struct completion wait_for_thread;      //completion struct} kthread_arg;

Then:

struct task_struct *task;static kthread_arg kta_first_thread;kta_first_thread.num = 1;strncpy(kta_first_thread.origin, dat1, MAXSTR );//Here I have normal char array 'origin'init_completion(&kta_first_thread.wait_for_thread);task = kthread_run(&thread_function, (void*)&kta_first_thread, "one");

And after that I have the error. Moreover, if you remove the array from struct, then everything works.I'm sure doing something wrong?

I'm new to the development of kernel module. I want my module to perform a task like signature verification, so I add my own self-signed certificate path to CONFIG_SYSTEM_TRUSTED_KEYS and compile to kernel. The key can be seen through cat /proc/keys like (the last entry):

040268c0 I------     1 perm 1f0b0000     0     0 keyring   .builtin_regdb_keys: 1152aaaa3 I------     1 perm 1f030000     0     0 keyring   .id_resolver: empty1eede733 I--Q---     1 perm 1f3f0000     0 65534 keyring   _uid_ses.0: 1249059d2 I------     1 perm 1f030000     0     0 asymmetri sforshee: 00b28ddf47aef9cea7: X509.rsa []299b6a42 I--Q---     2 perm 1f3f0000     0 65534 keyring   _uid.0: empty3bce6f1c I------     1 perm 1f030000     0     0 keyring   .dns_resolver: empty3d6c305b I------     1 perm 1f0b0000     0     0 keyring   .builtin_trusted_keys: 13d9c2543 I------     1 perm 1f030000     0     0 asymmetri <...>: <...>: <...>: X509.rsa 4c9c3ec4 []

Since this works fine, I want to get this key in my kernel module code. I have read some docs and used the following API to get key:

struct key *request_key(const struct key_type *type,                        const char *description,                        const char *callout_string);

My code is like:

struct key *key;key = request_key(&key_type_asymmetric, "<...>: <...>: <...>", NULL);

In <...> is my personal information.

I have debug at other place and I believe I have passed a correct description string. But I always get a ENOKEY. Can anybody tells me if there is any mistake? Or there is a better way to get a key? Thx.

Also, I have tried other keys in the list, and I can only get the key with description _uid_ses.0 and _uid.0.