The explanation in struct device says
Associated device tree node.
But, I didn't clearly understand this.
Can anyone provide an example?
of_node is related to Open Firmware it holds the information of a device tree.
Device Tree is like config file (named nodes and properties) which describes hardware in detail.
The main advantage of device tree is you don't have to keep modifying kernel for specific hardware. All you have to do is define your h/w in device tree fmt and feed it to bootloader. Boot loader, for example uboot, passes the device tree information to kernel and kernel initializes the devices based on those information it received from boot-loader.
the below is example of device tree.
{
compatible = "acme,coyotes-revenge";
cpus {
cpu#0 {
compatible = "arm,cortex-a9";
};
cpu#1 {
compatible = "arm,cortex-a9";
};
};
serial#101F0000 {
compatible = "arm,pl011";
};
serial#101F2000 {
compatible = "arm,pl011";
};
interrupt-controller#10140000 {
compatible = "arm,pl190";
};
external-bus {
ethernet#0,0 {
compatible = "smc,smc91c111";
};
i2c#1,0 {
compatible = "acme,a1234-i2c-bus";
rtc#58 {
compatible = "maxim,ds1338";
};
};
flash#2,0 {
compatible = "samsung,k8f1315ebm", "cfi-flash";
};
};
};
struct device_node (type of of_node) contains struct property which contains all properties of device tree node. It also has pointer to other properties and other node (siblings and parent) and a name variable which is name of the property (eg, register). So that's how we can have diffrent data like address from device tree in our driver code.
Related
I am trying to instantiate this sensor in ACPI using device specific data, i.e., with Name (_DSD, ...) and with a compatible string, e.g., with the following ASL excerpt:
Device (TOF1) {
Name (_HID, "PRP0001")
Name (_DDN, "STMicroelectronics VL53L0X laser rangefinder")
Name (_CRS, ResourceTemplate () {
I2cSerialBus (
0x29,
ControllerInitiated,
I2C_SPEED,
AddressingMode7Bit,
"\\_SB.PCI0.I2C1.MUX2.CH01",
0x00,
ResourceConsumer,,)
})
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"compatible", "st,vl53l0x"},
}
})
}
I was under the impression that if I specify my devices as I have in the above ASL, I would not need to modify the driver (e.g., by adding an ACPI match tables) and could match the device using the existing OF match table in the driver. However, this only seems partly true. The sensor fails to probe due to this check in the kernel in i2c-core-base.c:
if (!driver->id_table &&
!i2c_acpi_match_device(dev->driver->acpi_match_table, client) &&
!i2c_of_match_device(dev->driver->of_match_table, client))
return -ENODEV;
My interpretation of this statement is that the device driver must either have (i) an ID table or (ii) a matching ACPI ID table or (iii) a matching OF ID table. The VL53L0X does not have an ID table nor a ACPI match table, so I am relying on matching using the OF table.
Now, there are two things that I am confused about here. Firstly, I can printk(KERN_ERR "%s", dev->driver->driver.name) and see that I am indeed already looking at the correct driver, so why exactly are we checking if the driver matches again?
Secondly, if i2c_of_match_device(dev->driver->of_match_table, client) is failing to match, what exactly was matched in the first place that resulted in being able to printk(KERN_ERR "%s", dev->driver->driver.name) and see the correct name of the driver?
Not really an answer to the question above, but one hack/work around for this problem is to just add the ID table to the driver.
static const struct i2c_device_id vl53l0x_id[] = {
{ "vl53l0x", 0 },
{ }
};
MODULE_DEVICE_TABLE(i2c, vl53l0x_id);
static struct i2c_driver vl53l0x_driver = {
.driver = {
.name = "vl53l0x-i2c",
.of_match_table = st_vl53l0x_dt_match,
},
.probe_new = vl53l0x_probe,
.id_table = vl53l0x_id,
};
module_i2c_driver(vl53l0x_driver);
This results in the check in the question being skipped over. This isn't a great solution since the I2C ID table is not passed to probe_new, however, it does work for this driver since there is no further configuration to be done.
It seems however that matching i2c devices like this is being deprecated as per the comments and patches around the introduction of probe_new.
I'm writing a device driver (for Linux kernel 2.6.x) that interacts directly with physical RAM using physical addresses. For my device's memory layout (according to the output of cat /proc/iomem), System RAM begins at physical address 0x80000000; however, this code may run on other devices with different memory layouts so I don't want to hard-code that offset.
Is there a function, macro, or constant which I can use from within my device driver that gives me the physical address of the first byte of System RAM?
Is there a function, macro, or constant which I can use from within my device driver that gives me the physical address of the first byte of System RAM?
It doesn't matter, because you're asking an XY question.
You should not be looking for or trying to use the "first byte of System RAM" in a device driver.
The driver only needs knowledge of the address (and length) of its register block (that is what this "memory" is for, isn't it?).
In 2.6 kernels (i.e. before Device Tree), this information was typically passed to drivers through struct resource and struct platform_device definitions in a board_devices.c file.
The IORESOURCE_MEM property in the struct resource is the mechanism to pass the device's memory block start and end addresses to the device driver.
The start address is typically hardcoded, and taken straight from the SoC datasheet or the board's memory map.
If you change the SoC, then you need new board file(s).
As an example, here's code from arch/arm/mach-at91/at91rm9200_devices.c to configure and setup the MMC devices for a eval board (AT91RM9200_BASE_MCI is the physical memory address of this device's register block):
#if defined(CONFIG_MMC_AT91) || defined(CONFIG_MMC_AT91_MODULE)
static u64 mmc_dmamask = DMA_BIT_MASK(32);
static struct at91_mmc_data mmc_data;
static struct resource mmc_resources[] = {
[0] = {
.start = AT91RM9200_BASE_MCI,
.end = AT91RM9200_BASE_MCI + SZ_16K - 1,
.flags = IORESOURCE_MEM,
},
[1] = {
.start = AT91RM9200_ID_MCI,
.end = AT91RM9200_ID_MCI,
.flags = IORESOURCE_IRQ,
},
};
static struct platform_device at91rm9200_mmc_device = {
.name = "at91_mci",
.id = -1,
.dev = {
.dma_mask = &mmc_dmamask,
.coherent_dma_mask = DMA_BIT_MASK(32),
.platform_data = &mmc_data,
},
.resource = mmc_resources,
.num_resources = ARRAY_SIZE(mmc_resources),
};
void __init at91_add_device_mmc(short mmc_id, struct at91_mmc_data *data)
{
if (!data)
return;
/* input/irq */
if (data->det_pin) {
at91_set_gpio_input(data->det_pin, 1);
at91_set_deglitch(data->det_pin, 1);
}
if (data->wp_pin)
at91_set_gpio_input(data->wp_pin, 1);
if (data->vcc_pin)
at91_set_gpio_output(data->vcc_pin, 0);
/* CLK */
at91_set_A_periph(AT91_PIN_PA27, 0);
if (data->slot_b) {
/* CMD */
at91_set_B_periph(AT91_PIN_PA8, 1);
/* DAT0, maybe DAT1..DAT3 */
at91_set_B_periph(AT91_PIN_PA9, 1);
if (data->wire4) {
at91_set_B_periph(AT91_PIN_PA10, 1);
at91_set_B_periph(AT91_PIN_PA11, 1);
at91_set_B_periph(AT91_PIN_PA12, 1);
}
} else {
/* CMD */
at91_set_A_periph(AT91_PIN_PA28, 1);
/* DAT0, maybe DAT1..DAT3 */
at91_set_A_periph(AT91_PIN_PA29, 1);
if (data->wire4) {
at91_set_B_periph(AT91_PIN_PB3, 1);
at91_set_B_periph(AT91_PIN_PB4, 1);
at91_set_B_periph(AT91_PIN_PB5, 1);
}
}
mmc_data = *data;
platform_device_register(&at91rm9200_mmc_device);
}
#else
void __init at91_add_device_mmc(short mmc_id, struct at91_mmc_data *data) {}
#endif
ADDENDUM
i'm still not seeing how this is an xy question.
I consider it an XY question because:
You conflate "System RAM" with physical memory address space.
"RAM" would be actual (readable/writable) memory that exists in the address space.
"System memory" is the RAM that the Linux kernel manages (refer to your previous question).
Peripherals can have registers and/or device memory in (physical) memory address space, but this should not be called "System RAM".
You have not provided any background on how or why your driver "interacts directly with physical RAM using physical addresses." in a manner that is different from other Linux drivers.
You presume that a certain function is the solution for your driver, but you don't know the name of that function. That's a prototype for an XY question.
can't i call a function like get_platform_device (which i just made up) to get the struct platform_device and then find the struct resource that represents System RAM?
The device driver would call platform_get_resource() (in its probe function) to retrieve its struct resource that was defined in the board file.
To continue the example started above, the driver's probe routune has:
static int __init at91_mci_probe(struct platform_device *pdev)
{
struct mmc_host *mmc;
struct at91mci_host *host;
struct resource *res;
int ret;
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
return -ENXIO;
if (!request_mem_region(res->start, resource_size(res), DRIVER_NAME))
return -EBUSY;
...
/*
* Map I/O region
*/
host->baseaddr = ioremap(res->start, resource_size(res));
if (!host->baseaddr) {
ret = -ENOMEM;
goto fail1;
}
that would allow me to write code that can always access the nth byte of RAM, without assumptions of how RAM is arranged in relation to other parts of memory.
That reads like a security hole or a potential bug.
I challenge you to to find a driver in the mainline Linux kernel that uses the "physical address of the first byte of System RAM".
Your title is "Kernel API to get Physical RAM Offset".
The API you are looking would seem to be the struct resource.
What you want to do seems to fly in the face of Linux kernel conventions. For the integrity and security of the system, drivers do not try to access any/every part of memory.
The driver will request and can be given exclusive access to the address space of its registers and/or device memory.
All RAM under kernel management is only accessed through well-defined conventions, such as buffer addresses for copy_to_user() or the DMA API.
A device driver simply does not have free reign to access any part of memory it chooses.
Once a driver is started by the kernel, there is absolutely no way it can disregard "assumptions of how RAM is arranged".
RAM memory mapping is based identical to each SOC or processor. Vendor usually provide their memory mapping related documents to the user.
Probably you need to refer your processor datasheet related document.
As you said memory is hard-coded. In most cases memory mapping is hard-coded over device-tree or in SDRAM driver itself.
Maybe you could look into memblock struct and memblock_start_of_DRAM().
/sys/kernel/debug/memblock/memory represent memory banks.
0: 0x0000000940000000..0x0000000957bb5fff
RAM bank 0: 0x0000000940000000 0x0000000017bb6000
1: 0x0000000980000000..0x00000009ffffffff
RAM bank 1: 0x0000000980000000 0x0000000080000000
I was trying to understand a codec driver code on Linux kernel 4.4. The codec is connected to sound card using i2c bus and the codec driver code is written as I2C client. Client's struct i2c_driver contains both i2c_device_id information and of_device_id information.
Now as per my understanding client's probe function will be called when compatible string of struct of_device_id matches with compatible string of device node information. Then what is the use of struct i2c_device_id?
NOTE: Codec driver is using device tree.
Your i2c_device_id structure is referenced by the i2c_driver structure; the I²C framework uses it to find the driver that is to be attached to a specific I²C device. This is similar to how the of_device_id information is used to find the driver for a specific device described in the device tree.
As the driver writer, you do not really know how the codec will actually be enumerated later (I²C or OF), so you should provide both pieces of information.
When you are using MODULE_DEVICE_TABLE(), the values in the i2c_device_id structure are used to find the module to load. (This is unlikely to happen in an embedded system that has neither hotplugging nor modules, but if the codec is ever used in a modular system (e.g., for testing), the autoloading might not work.)
Furthermore, the information provided by MODULE_DEVICE_TABLE() can be used to determine which kernel configuration options are needed for some specific hardware.
Say you have the following i2c driver structures:
static const struct i2c_device_id lm75_ids[] = {
{ "adt75", adt75, },
{ }
};
MODULE_DEVICE_TABLE(i2c, lm75_ids);
static const struct of_device_id lm75_of_match[] = {
{ .compatible = "adi,adt75" },
{ },
};
MODULE_DEVICE_TABLE(of, lm75_of_match);
static struct i2c_driver lm75_driver = {
.driver = {
.name = "lm75",
.of_match_table = of_match_ptr(lm75_of_match),
},
.probe = lm75_probe,
.id_table = lm75_ids,
};
module_i2c_driver(lm75_driver);
When an I2C device is instantiated via userland:
echo adt75 0x50 > /sys/bus/i2c/devices/i2c-3/new_device
The i2c-core matches the name "adt75" to the name in the struct i2c_device_id array, and it passes that element to lm75_probe.
When an I2C device is instantiated via OF device tree, its compatible property is matched (format: "manufacturer,model") and the "model" component is matched against the struct i2c_device_id array - which also passed that element to lm75_probe. Pretty neat!
struct of_device_id also has a .data property, which you can access via a different mechanism.
I have some code which looks like:
static int devname_read(struct cdev *dev, struct uio *uio, int ioflag)
{
int error = modify_state();
return (error);
}
The issue here is that modify_state() operates on global state when it really should be operating on is per open(2). In other words no reader should conflict with each other, and nothing persist when the device is close(2)ed.
How can I associate state with the file-descriptor or related identifier?
You probably want to use cdevpriv; see http://www.freebsd.org/cgi/man.cgi?devfs_set_cdevpriv.
I need to read certain statistics from iw_statistics structure, here's the code:
struct net_device *dev;
struct iw_statistics *wi_stats;
dev = first_net_device(&init_net);
while (dev)
{
if (strncmp(dev->name , "wlan",4)==0 )
{
if (dev->wireless_handlers->get_wireless_stats(dev) !=NULL ) // <--- here's where the code crashes.
{
wi_stats = dev-wireless_handlers->get_wireless_stats(dev);
printk(KERN_INFO "wi_stats = dev-wireless_handlers->get_wireless_stats(dev); worked!!! :D\n");
}
}
}
I'm working on linux kernel 2.6.35 and I'm writing a kernel module. What am I doing wrong here?
Looks like wireless_handlers struct is Null ... Just because a net device has it's name field filled doesn't mean it's configured.
This is where wireless_handlers gets set:
#ifdef CONFIG_WIRELESS_EXT
/* List of functions to handle Wireless Extensions (instead of ioctl).
* See <net/iw_handler.h> for details. Jean II */
const struct iw_handler_def * wireless_handlers;
/* Instance data managed by the core of Wireless Extensions. */
struct iw_public_data * wireless_data;
#endif
You should check the value called CONFIG_WIRELESS_EXT if it's not set , the wireless_handler struct is not set and thus you''ll be pointing to a Null and your module will get stuck
You should check that dev->wireless_handlers is not null. Can you paste the actual code snippet? What is the error you get?