- kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

arm64 Kernel build for qemu-system-aarch64 ?
by Pintu Agarwal Feb. 22, 2019

Feb. 22, 2019

Hi All, I want to build Linux Kernel 4.20 for arm64 and use it on qemu-arm64. I see that there is a defconfig available in arch/arm64/configs/defconfig But I am not sure whether it will work for qemu-arm64, and by default which machine type is supported. I already have working setup for qemu-arm for both versatile and vexpress machine. There is already a defconfig available for these under arch/arm. So I can build the kernel for it. But, whether these defconfig are supported for arm64 ? If anybody have setup for qemu-arm64 kernel, please share the steps. About rootfs, I am planning to use the arm32 version of busybox itself. Thanks, Pintu

2 2

Add IIO example to the kernelnewbies wiki
by Gaston Gonzalez Feb. 21, 2019

Feb. 21, 2019

Hi, I'm testing an AD7746 eval board using a Diolan DLN-2 adapter. I wrote some basic notes about the installation an instanciation process for my own use. But then I thought it could be useful for someone else. So maybe I could put this in the kernel newbies page under the IIO section? If you think is worth it, I would be glad to add it to the wiki page. Best regards, Gaston Notes: The setup ========= AD7746-EVAL BOARD --> Diolan DLN-2 Adapter --> Thinkpad T430 The connection between the AD7746 eval board and adapter is as detailed in [2] I2C Interface Configuration Options, External connection (pag 4). The connection between Diolan DLN-2 and the T430 is USB straighforward. Drivers ======= Both in mainline kernel: - Diolan DLN-2 driver: I2C_DLN2 (prompt Diolan DLN-2 USB I2C adapter) Loc: drivers/i2c/busses/ - AD7746: AD7746 Loc: drivers/staging/iio/cdc/ Bus of interest =============== $ sudo i2cdetect -l We get something like: ... i2c-10 i2c dln2-i2c-1-1.2:1.0-0 I2C adapter ... So our bus is the number 10. Getting the address =================== $ sudo i2cdetect -y -r 10 We get something like: 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- 48 -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- 3. Device instantiation: # echo add7746 0x48 > /sys/bus/i2c/devices/i2c-10/new_device We must see something like: $ cd /sys/bus/i2c/devices/i2c-10/10-0048/ $ ls driver iio:device0 modalias name power subsystem uevent $ cd iio:device0 $ ls dev in_capacitance-capacitance_calibbias in_capacitance0_calibbias_calibration in_capacitance-capacitance_sampling_frequency in_capacitance0_calibscale in_capacitance-capacitance_scale in_capacitance0_calibscale_calibration in_capacitance_sampling_frequency in_capacitance0-capacitance2_calibscale in_capacitance_sampling_frequency_available in_capacitance0-capacitance2_offset in_capacitance_scale in_capacitance0-capacitance2_raw in_temp0_input in_capacitance0_offset in_temp1_input in_capacitance0_raw in_voltage0_calibscale_calibration in_capacitance1_calibbias_calibration in_voltage0_raw in_capacitance1_calibscale in_voltage1_supply_raw in_capacitance1_calibscale_calibration in_voltage_sampling_frequency in_capacitance1-capacitance3_calibscale in_voltage_sampling_frequency_available in_capacitance1-capacitance3_offset in_voltage_scale in_capacitance1-capacitance3_raw name in_capacitance1_offset power in_capacitance1_raw subsystem in_capacitance_calibbias uevent Checking the permits: $ ll -r--r--r-- 1 root root 4096 mar 31 09:57 dev --w------- 1 root root 4096 mar 31 09:57 in_capacitance0_calibbias_calibration -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance0_calibscale --w------- 1 root root 4096 mar 31 09:57 in_capacitance0_calibscale_calibration -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance0-capacitance2_calibscale -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance0-capacitance2_offset -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance0-capacitance2_raw -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance0_offset -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance0_raw --w------- 1 root root 4096 mar 31 09:57 in_capacitance1_calibbias_calibration -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance1_calibscale --w------- 1 root root 4096 mar 31 09:57 in_capacitance1_calibscale_calibration -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance1-capacitance3_calibscale -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance1-capacitance3_offset -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance1-capacitance3_raw -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance1_offset -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance1_raw -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance_calibbias -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance-capacitance_calibbias -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance-capacitance_sampling_frequency -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance-capacitance_scale -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance_sampling_frequency -r--r--r-- 1 root root 4096 mar 31 09:57 in_capacitance_sampling_frequency_available -rw-r--r-- 1 root root 4096 mar 31 09:57 in_capacitance_scale -rw-r--r-- 1 root root 4096 mar 31 09:57 in_temp0_input -rw-r--r-- 1 root root 4096 mar 31 09:57 in_temp1_input --w------- 1 root root 4096 mar 31 09:57 in_voltage0_calibscale_calibration -rw-r--r-- 1 root root 4096 mar 31 09:57 in_voltage0_raw -rw-r--r-- 1 root root 4096 mar 31 09:57 in_voltage1_supply_raw -rw-r--r-- 1 root root 4096 mar 31 09:57 in_voltage_sampling_frequency -r--r--r-- 1 root root 4096 mar 31 09:57 in_voltage_sampling_frequency_available -rw-r--r-- 1 root root 4096 mar 31 09:57 in_voltage_scale -r--r--r-- 1 root root 4096 mar 31 09:57 name drwxr-xr-x 2 root root 0 mar 31 09:57 power lrwxrwxrwx 1 root root 0 mar 31 09:57 subsystem -> ../../../../../../../../../../../bus/iio -rw-r--r-- 1 root root 4096 mar 31 09:57 uevent 4. Capacitance According to [2], the capacitive length sensor is connected to CIN2+ and CIN2-. In the driver, the values are mapped to capacitance0. Raw values vs sensor length: Note: (+) values means the sensor was moved to the left, (-) values means the sensor was moved to the right. I.e. +1 cm means the rule was moved 1 to the left, while -1 means the rule was moved 1 cm to the right. Note2: note the raw value for -10 is 8224733, while +10 is -8224726, the difference is because when the rule is moved 10 cm to the left, the is still 2 o 3 cm of dielectric between the plates. The design is obviously thought to move the rule to the right. Length (cm) | Raw Value Cap0 ------------------------------ -10 -8224733 -9 -8224730 -8 -8224728 -7 -8224725 -6 -8224724 -5 -8224722 -4 -8224720 -3 -8224718 -2 -8224716 -1 -8224714 +0 -8224711 +1 -8224711 +2 -8224711 +3 -8224711 +4 -8224713 +5 -8224715 +6 -8224717 +7 -8224719 +8 -8224721 +9 -8224723 +10 -8224726 References ========== [1] http://www.analog.com/media/en/technical-documentation/data-sheets/AD7745_7… [2] http://www.analog.com/media/en/technical-documentation/evaluation-documenta… [3] https://i2c.wiki.kernel.org/index.php/Main_Page [4] https://kernelsense.wordpress.com/2016/01/22/achievement-unlocked-first-iio…

2 2

building .lst files for a subdirectory
by Nicholas Mc Guire Feb. 20, 2019

Feb. 20, 2019

Hi ! Probably I´m just overlooking something obvious but trying to build .lst files in directories that have no Makefile is causing problems. For "normal" files its simply $ make path/file.lst but that seems to assume that there always is a Makefile in each directory. For some drivers this is not the case e.g. drivers/staging/rtlwifi/Makefile covers all the subdirectories directly and there are no Makefiles or Kbuild files in the respective subdirs. So building .lst fails: hofrat@threadripper:~/git/linux-next$ make drivers/staging/rtlwifi/phydm/rtl_phydm.lst CALL scripts/checksyscalls.sh CALL scripts/atomic/check-atomics.sh DESCEND objtool scripts/Makefile.build:42: drivers/staging/rtlwifi/phydm/Makefile: No such file or directory And not too surprising the build instructions from Documentation/kbuild/modules.txt will not do the trick either: hofrat@threadripper:~/git/linux-next/drivers/staging/rtlwifi/phydm$ make -C ~/git/linux-next M=$PWD rtl_phydm.lst make: Entering directory '/home/hofrat/git/linux-next' scripts/Makefile.build:42: /home/hofrat/git/linux-next/drivers/staging/rtlwifi/phydm/Makefile: No such file or directory make[1]: *** No rule to make target '/home/hofrat/git/linux-next/drivers/staging/rtlwifi/phydm/Makefile'. Stop. Makefile:1704: recipe for target 'rtl_phydm.lst' failed make: *** [rtl_phydm.lst] Error 2 make: Leaving directory '/home/hofrat/git/linux-next' Any hint how to build those .lst files ? thx! hofrat

1 0

Re: writes to /dev/kmsg
by Lev Olshvang Feb. 20, 2019

Feb. 20, 2019

1 0

writes to /dev/kmsg
by Lev Olshvang Feb. 19, 2019

Feb. 19, 2019

2 1

Platform driver probe() not being called when device-tree overlaid
by Laurence Rochfort Feb. 16, 2019

Feb. 16, 2019

Hi all, I'm attempting to write a platform device driver that gets loaded when a compatible device-tree overlay is loaded by dtoverlay. This is just a learning exercise at the moment, so I'm trying to write the simplest platform device I can, rather than extending one of the device drivers that extend platform device (terminology?). I'm trying to get just enough to get the driver's probe() function called when the device-tree overlay is applied, and then create a misc device. My module seems to init just fine, and the device-tree overlay seems to also load without issue, but for some reason probe() is never called. Am I correct in using probe() with platform devices? I understand platform devices can't be enumerated/detected, but I thought that probe() would be called when there was a compatibility match between the driver and the device-tree overlay. Any pointers would be much appreciated. Cheers, Laurence. Here's what /sys shows: $ cat /sys/devices/platform/gde060f3/uevent OF_NAME=gde060f3 OF_FULLNAME=/gde060f3 OF_COMPATIBLE_0=gde060f3 OF_COMPATIBLE_N=1 MODALIAS=of:Ngde060f3T<NULL>Cgde060f3 $ cat /sys/firmware/devicetree/base/gde060f3/compatible gde060f3 $ cat /sys/firmware/devicetree/base/gde060f3/name gde060f3 $ cat /sys/firmware/devicetree/base/gde060f3/status okay Here's the loaded device-tree: $ dtc -I fs /proc/device-tree /dts-v1/; / { compatible = "raspberrypi,3-model-b-plus", "brcm,bcm2837"; serial-number = "00000000427625f0"; model = "Raspberry Pi 3 Model B Plus Rev 1.3"; memreserve = <0x3b400000 0x4c00000>; interrupt-parent = <0x1>; #address-cells = <0x1>; #size-cells = <0x1>; clocks { *** SNIPPED *** }; __overrides__ { *** SNIPPED *** }; gde060f3 { compatible = "gde060f3"; status = "okay"; phandle = <0x7b>; linux,phandle = <0x7b>; }; system { linux,serial = <0x0 0x427625f0>; linux,revision = <0xa020d3>; }; *** SNIPPED *** }; module file: #define DEBUG #include <linux/kernel.h> #include <linux/module.h> #include <linux/platform_device.h> #include <linux/miscdevice.h> #include <linux/fs.h> #include <linux/uaccess.h> #include <linux/slab.h> struct gde060f3_struct { struct platform_device *pdev; struct miscdevice mdev; }; static inline struct gde060f3_struct *to_gde060f3_struct(struct file *file) { struct miscdevice *miscdev = file->private_data; return container_of(miscdev, struct gde060f3_struct, mdev); } static ssize_t gde060f3_read(struct file *file, char __user *buf, size_t count, loff_t *pos) { struct gde060f3_struct *gde060f3 = to_gde060f3_struct(file); /* just for example */ (void)gde060f3; /* unused */ return simple_read_from_buffer(buf, count, pos, "gde060f3 text", 14); } static const struct file_operations gde060f3_fops = { .owner = THIS_MODULE, .read = gde060f3_read, }; static const struct of_device_id gde060f3_match[] = { { .compatible = "gde060f3" }, {}, }; MODULE_DEVICE_TABLE(of, gde060f3_match); static int gde060f3_probe(struct platform_device *pdev) { struct gde060f3_struct *gde060f3; int ret; pr_info("gde060f3_probe()\n"); gde060f3 = kmalloc(sizeof(*gde060f3), GFP_KERNEL); if (!gde060f3) return -ENOMEM; platform_set_drvdata(pdev, gde060f3); gde060f3->pdev = pdev; gde060f3->mdev.minor = MISC_DYNAMIC_MINOR; gde060f3->mdev.name = "gde060f3"; gde060f3->mdev.fops = &gde060f3_fops; gde060f3->mdev.parent = NULL; ret = misc_register(&gde060f3->mdev); if (ret) { dev_err(&pdev->dev, "Failed to register miscdev\n"); return ret; } dev_info(&pdev->dev, "Registered\n"); pr_info("Registered\n"); return 0; } static int gde060f3_remove(struct platform_device *pdev) { struct gde060f3_struct *gde060f3 = platform_get_drvdata(pdev); misc_deregister(&gde060f3->mdev); kfree(gde060f3); dev_info(&pdev->dev, "Unregistered\n"); pr_info("Unregistered\n"); return 0; } static struct platform_driver gde060f3_driver = { .probe = gde060f3_probe, .remove = gde060f3_remove, .driver = { .name = "gde060f3", .of_match_table = gde060f3_match, }, }; module_platform_driver_probe(gde060f3_driver, gde060f3_probe); MODULE_AUTHOR("Laurence Rochfort <laurence.rochfort(a)gmail.com>"); MODULE_DESCRIPTION("GPIO driver for Good Display GDE060F3 ePaper Display"); MODULE_LICENSE("GPL"); overlay file: /dts-v1/; /plugin/; / { compatible = "brcm,bcm2708"; fragment@0 { // target or target-path? target-path = "/"; __overlay__ { gde060f3: gde060f3 { compatible = "gde060f3"; status = "okay"; }; }; }; };

1 1

How to dealwith mmap for a filesystem filter driver?
by kipade Feb. 16, 2019

Feb. 16, 2019

Hello all, I created a filter driver for the vfs, for some special file read, I want to replace its data got from the disk and return to the new data to user space, eg. decryption. my hooked read entry like this: int my_hooked_read(struct file* filp, char* buffer, size_t count, loff_t* pos) { int ret = orig_read(filp, buffer, count, pos); if(ret > 0) { //do something } return ret; } the code works file for normal read, but take no sense for read via mmap operations. so, I want to know what should I do to resolve such issue? Thanks.

1 0

Configuring a Conexant USB modem
by Jeffrey Walton Feb. 15, 2019

Feb. 15, 2019

Hi Everyone, I'm having trouble using a USB modem. It is a Conexant modem but it is not responding to AT commands. Sample code is at https://pastebin.com/84YUn9ey . I think the first thing I need to do is verify the kernel configuration for the device. For that: $ sudo setserial -a /dev/ttyACM0 /dev/ttyACM0, Line 0, UART: unknown, Port: 0x0000, IRQ: 0 Baud_base: 115200, close_delay: 12, divisor: 0 closing_wait: 750 Flags: spd_normal At this point I think I need to read some kernel docs. I'm not sure if I should be in https://www.kernel.org/doc/Documentation/serial or https://www.kernel.org/doc/Documentation/usb . Looking through the pages nothing jumps out as specific to the Conexant. Can someone suggest what my next steps are to verify the modem's configuration with respect to the kernel and driver? Thanks in advance.

2 1

Want to improve wiki document
by Bo YU Feb. 14, 2019

Feb. 14, 2019

Hi, I want to improve the page: https://kernelnewbies.org/KernelJanitors/Todo For example, 1. Fix sparse warnings. Read section "Where to get sparse" in Documentation/sparse.txt... As we all know, it has been moved into Documentation/dev-tools/, right? Please consider add me into editor list, thanks!

3 6

how to find out IRQ end user
by Matwey V. Kornilov Feb. 14, 2019

Feb. 14, 2019

Hello, >From /sys/kernel/debug/tracing I see the following points: <idle>-0 [000] d.h1 2388.136032: irq_handler_entry: irq=16 name=gp_timer Is there a simple way to figure out what is the exact final function called to handle this IRQ?

2 3