February 2019 - kernelnewbies@kernelnewbies.org

make modules_install install is failing
by Bharath Vedartham March 5, 2019

March 5, 2019

Hi all, I am unable to execute make modules_install install. I get the following error: ln: target 'linux-00096-gd1aa1a8/source' is not a directory Makefile:1281: recipe for target '_modinst_' failed make[1]: *** [_modinst_] Error 1 Makefile:296: recipe for target '__build_one_by_one' failed make: *** [__build_one_by_one] Error 2 I made a change to a driver and did not commit the changes. I then built the kernel and two weird looking files appeared in my root directory: linux-00095-g94832d9-dirty linux-00096-gd1aa1a8 Since then , I have commited my changes and made the kernel again. The dirs still exist. I have tried manually removing them but they reappear whenever I make the kernel again. I am running the version: 5.0.0-rc2+ I am not able to make the kernel modules because of this. Is this a common problem? Any answers? Thank you

2 1

Question regarding clock-provider and m41t80.c
by Patrick Schneider Feb. 28, 2019

Feb. 28, 2019

Hi everyone, I recently went mainline with our embedded device and so far I am happy that I've done it. Coming from a quite old kernel (4.1.15) there are some new features and changes I need to get my head around and one is bugging me for quite some time now. We are using an RTC which depends on the m41t80 kernel driver. This RTC has a CLK-OUT feature which is per default to ON and 32kHz. We have another chip wired and depending to that clock signal. On kernel version 4.1.15 there was no feature to enable/disable square wave output for this rtc driver, so it was always on per default. In newer kernel versions is a change which is adding clock-provider feature to use and enable/disable that CLK-OUT feature. Which results in the clock output signal being turned of as default option. Now I am totally lost on how to activate that feature in - I think the device tree? I read through all documentation regarding the matter and tried adding clock attributes in the dts but with no luck so far. My entry is: /* external real time clock */ i2c_rtc: rtc@68 { pinctrl-names = "default"; pinctrl-0 = <&pinctrl_rtc_int>; compatible = "st,rv4162", "fixed-clock", "microcrystal,rv4162"; reg = <0x68>; interrupt-parent = <&gpio5>; interrupts = <1 IRQ_TYPE_LEVEL_LOW>; status = "okay"; #clock-cells = <1>; clock-frequency = <32678>; clock-output-names = "rtcosc"; }; Any help is appreciated! Best regards, Patrick

1 0

Could we use jprobe to skip kprboed function
by wuzhouhui Feb. 26, 2019

Feb. 26, 2019

Hi, The documentation of jprobe says that we must call jprobe_return() before return. I'm wondering what if we don't call jprobe_return, and could we use it to skip probed function? Thanks.

2 1

where is headers_install in KBUILD
by YU Bo Feb. 26, 2019

Feb. 26, 2019

Hello, Now i want to compile kernel and test userspace program fastly and i find a good guide link: https://vincent.bernat.ch/en/blog/2014-eudyptula-boot In the article, author compile kernel with KBUILD(custom install vmlinux...) 1. export KBUILD_OPTPUT=$HOME/src/kernel-build Is this generate a copy of linux kernel source, right? 2. edit .config and make 3. sudo make modules_install install {INSTALL_MOD_PATH,INSTALL_PATH}=$HOME/src/kernel-dev Ok, I did it and booted a VM with qemu, it is cool. But, my "question" is: when i test some program which needs kernel headers, where to install those headers file? In Documention/kbuild/headers_install.rst, i learn it : make headers_install INSTALL_HDR_PATH=/usr In my case, Is it ok to do that?I do not think it will work. May i: make headers_install INSTALL_HDR_PATH=$HOME/src/kernel-headers is it Ok? Thank you very much! Bo

3 2

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