What's The Config_Of in Linux

What's the CONFIG_OF in linux?

Open Firmware. This was invented long time ago when Apple was producing laptops based on PowerPC CPUs and Sun Microsystems workstations were still popular. Open Firmware provides a good description of the devices connected to the platform. In Linux kernel the part that works with device data is called Device Tree (DT). More details in the Usage model.

what is the use of of_match_ptr() in device drivers

of_match_ptr() is a preprocessor macro defined in include/linux/of.h:

#ifdef CONFIG_OF
#define of_match_ptr(_ptr) (_ptr)
#else /* CONFIG_OF */
#define of_match_ptr(_ptr) NULL
#endif /* CONFIG_OF */

When the kernel is compiled with Device Tree and Open Firmware support, i.e. CONFIG_OF=y it will result in the passed pointer. Otherwise it will yield NULL.

Using the macro instead of directly passing the pointer, is to guard the of_match_table member. There are bus drivers which check of_match_table for NULL to not dereference an invalid pointer.

However, many drivers are compiled in-tree with a compile switch defined in their corresponding Kconfig that already depends on CONFIG_OF. For example, the compile switch of a driver for analog device ADV748X video decoder has this dependency:

config VIDEO_ADV748X
tristate "Analog Devices ADV748x decoder"
depends on VIDEO_V4L2 && I2C
depends on OF
select MEDIA_CONTROLLER
select VIDEO_V4L2_SUBDEV_API
select REGMAP_I2C
select V4L2_FWNODE
help
V4L2 subdevice driver for the Analog Devices
ADV7481 and ADV7482 HDMI/Analog video decoders.

To compile this driver as a module, choose M here: the
module will be called adv748x.

and omits the macro in drivers/media/i2c/adv748x/adv748x-core.c:

static struct i2c_driver adv748x_driver = {
.driver = {
.name = "adv748x",
.of_match_table = adv748x_of_table,
.pm = &adv748x_pm_ops,
},
.probe_new = adv748x_probe,
.remove = adv748x_remove,
};

What's the usage of blk_queue_segment_boundary()

Some controllers (particulary IDE) can not handle DMA requests that cross memory regions at 4MB. Think of it as segment:index addressing where index can not be larger that the set boundary.

There is also a blk_queue_max_segment_size. Both are used to construct correct requests to the device - requests get reordered and merged.

There are other uses. For example, from xen-blkfront.c:

/* Each segment in a request is up to an aligned page in size. */
blk_queue_segment_boundary(rq, PAGE_SIZE - 1);
blk_queue_max_segment_size(rq, PAGE_SIZE);

Requests are limited to PAGE_SIZE for better performance.

Board files for x86 based systems

Most devices are discoverable through PCI and ACPI.
(Even though most x86 CPUs are not SoCs, they have many built-in PCI devices.)

The few remaining devices (mostly legacy stuff going back to IBM PCs) are hardcoded in the x86 arch code.

Any 'new' devices that aren't PCI must be described by the BIOS in some ACPI table.

Linux device driver: probe function not called for compatible device with an address

The .compatible = "exynos" entry in ect_of_device_ids[] does not match the compatible = "exynos,ect"; entry in the device tree. If you change it to "exynos,ect" your probe function should get called:

static struct of_device_id ect_of_device_ids[] = {
{.compatible = "exynos,ect", },
{},
}

Also, if you want to support auto-loading of external kernel modules by a hotplug handler in userspace, you need to use the MODULE_DEVICE_TABLE macro to include the necessary information in the module:

#ifdef CONFIG_OF
MODULE_DEVICE_TABLE(of, ect_of_device_ids);
#endif
MODULE_DEVICE_TABLE(platform, ect_plat_device_ids);


Related Topics



Leave a reply



Submit