November 2018 - kernelnewbies@kernelnewbies.org

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

When kernel deletes unused kernel module from RAM?
by Lev Olshvang Nov. 30, 2018

Nov. 30, 2018

2 1

which functions are used for dynamically allocating memory in the kernel?
by Carter Cheng Nov. 28, 2018

Nov. 28, 2018

Hello, I am curious which sets of functions return pointers for the purpose of dynamic allocating memory in the kernel? I am aware of get_free_pages family, kmalloc, vmalloc, the slab allocator and mempools are there any others? Thanks in advance, Carter.

1 0

Kernel default security configuration - how it affects LSM policy?
by Lev Olshvang Nov. 26, 2018

Nov. 26, 2018

2 2

HOW CONFIG_DEFAULT_SECURITY affect precedence of decisions between LSM and Linux DAC ?
by Lev Olshvang Nov. 24, 2018

Nov. 24, 2018

1 0

missing /sys/class/drm/*
by jim.cromie＠gmail.com Nov. 24, 2018

Nov. 24, 2018

I just upgraded an old box to fedora 29 model name : Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz when booted, none of these kernels has /sys/class/drm/* populated and all have trouble with graphical mode, I am causally linking these 2 facts, does that make sense? If so, it makes sense to file a bugzilla report, what else should it include ? lightdm/kde work the best, setting screen resolution at minimal VGA gdm fell over, never replaced the splash screen I built an rc3+ kernel, copied f29 config, make localmodconfig, It has /sys/class/drm/* and sets right resolution on boot.

1 0

question: frag_max_size not checked in ip_finish_output
by Wenxin Wang Nov. 21, 2018

Nov. 21, 2018

Dear developers, It seems that with defragmentation enabled, `ip_finish_output` doesn't honor `IPCB(skb)->frag_max_size`, while `ip6_finish_output` checks `IP6CB(skb)->frag_max_size`. (Sorry for the reposting, I found that I need to subscribe to the mailing list, and I also add results of my experiment) The relevant code is here https://elixir.bootlin.com/linux/latest/source/net/ipv4/ip_output.c#L310 https://elixir.bootlin.com/linux/latest/source/net/ipv6/ip6_output.c#L151 As far as I know, `frag_max_size` prevents the forwarding routine from sending packets longer than the maximum fragment received. I'm wondering why `ip_finish_output` doesn't do the same as `ip6_finish_output`, especially when `ip_fragment` and `ip_do_fragment`, called (indirectly) by `ip_finish_output` itself, both cap the output mtu by this `frag_max_size`. I did some experiement with two connected machines, one as a router with ipv4/ipv6 NAT and 1500 mtu, the other as a client behind NAT and 1280 mtu. Since NAT was enabled on the router it will do defragmentation. Using `traceroute`, the client sent udp packets with length 1500, which were fragmented by itself. I captured packets on the ingress and egress port of the NAT router, and here's the output: --- IPv4 with NAT (and defrag) ingress: 09:26:39.030436 IP 192.168.1.2.44654 > 223.5.5.5.33434: UDP, bad length 1472 > 1248 09:26:39.030451 IP 192.168.1.2 > 223.5.5.5: ip-proto-17 egress: 09:26:39.030543 IP 202.38.101.2.58599 > 223.5.5.5.33437: UDP, length 1472 --- IPv6 with NAT (and defrag) ingress: 09:18:26.947246 IP6 fdff::2 > 2001:250:3::1: frag (0|1232) 57242 > 33434: UDP, bad length 1452 > 1224 09:18:26.947262 IP6 fdff::2 > 2001:250:3::1: frag (1232|228) egress: 09:18:26.947362 IP6 2001:da8:c4c6:2::2 > 2001:250:3::1: frag (0|1232) 49616 > 33437: UDP, bad length 1452 > 1224 09:18:26.947365 IP6 2001:da8:c4c6:2::2 > 2001:250:3::1: frag (1232|228) - It can be seen that with defragmentation, IPv6 keeps the fragments below `frag_max_size`, while IPv4 doesn't. I understand that IPv6 routers are not allowed to meddle with fragmentation, while IPv4 routes can at least further fragment packets; but judging from the behavior of `ip_fragment`, I think the IPv4 code is also trying to honor `frag_max_size`, but didn't check it when deciding to do fragmentation or not. Many thanks in advance! If I'm sending to the wrong person, or wrong mailing list, please let me know. It's my first time trying to ask questions to Linux developers, and sorry for the disturbance. Thank you for making Linux great ;) Sincerely, Wenxin Wang

1 0

[ARM64] Printing IRQ stack usage information
by Pintu Agarwal Nov. 20, 2018

Nov. 20, 2018

Hi All, I have a requirement in printing irq stack usage information for each cpu. I am using the following: Linux Kernel: 4.9.x Board: hikey620 (arm64, armv8 with 8 cores) Platform: Ubuntu 14 debian As a vague idea, I tried to implement like this: ------------------------------------------------------------- static int dump_irq_stack_info(void) { int cpu, actual; unsigned long irq_stack_ptr; //unsigned long sp, sp1; unsigned long stack_start; unsigned long used; actual = IRQ_STACK_SIZE; used = 0; pr_info("CPU UNUSED-STACK ACTUAL-STACK\n"); //seq_printf(m, "CPU UNUSED-STACK ACTUAL-STACK\n"); for_each_present_cpu(cpu) { irq_stack_ptr = IRQ_STACK_PTR(cpu); //sp1 = current_stack_pointer; //sp = IRQ_STACK_TO_TASK_STACK(irq_stack_ptr); stack_start = (unsigned long)per_cpu(irq_stack, cpu); used = irq_stack_ptr - stack_start; pr_info("%2d %10lu %10d\n", cpu, used, actual); //seq_printf(m, "%2d %10lu %10d\n", cpu, used, actual); } return 0; } ------------------------------------------------------------- Currently, when I tested this (as a proc interface), I got the below output: CPU UNUSED-STACK ACTUAL-STACK 0 16368 16384 1 16368 16384 2 16368 16384 3 16368 16384 4 16368 16384 5 16368 16384 6 16368 16384 7 16368 16384 ------------------------------------------------------------- But, I have some doubts: 1) I am not sure if my implementation is in right direction, or the logic is totally wrong. 2) Is there better way to perform the similar objective? 3) How should I test it to get the different usage values for unused stack ? Can I get these values by implementing a sample interrupt handler, and printing information from there? If this works, then I want to use it as part of dump_backtrace() function. If anybody have done a similar thing in past, or have some ideas to share, please help me. Note: This is required only for our internal debugging purpose. Regards, Pintu

2 10

question: frag_max_size not checked in ip_finish_output
by Wenxin Wang Nov. 20, 2018

Nov. 20, 2018

Dear developers, I'm trying to understand the different behavior between `ip_finish_output` and `ip6_finish_output`, when deciding whether to do fragmentation or not. `ip_finish_output` calls `ip_fragment` when `skb->len` exceeds the destination mtu; In addition to this mtu check, `ip6_finish_output` also checks if `skb->len > IP6CB(skb)->frag_max_size`. The relevant code is here https://elixir.bootlin.com/linux/latest/source/net/ipv4/ip_output.c#L310 https://elixir.bootlin.com/linux/latest/source/net/ipv6/ip6_output.c#L151 As far as I know, `frag_max_size` prevents the forwarding routine from sending packets longer than the maximum fragment received after defragmentation. I'm wondering why `ip_finish_output` doesn't check similarily for `IPCB(skb)->frag_max_size`, especially when `ip_fragment` and `ip_do_fragment`, called (indirectly) by `ip_finish_output`, both cap the output mtu by this frag_max_size. Many thanks in advance! If I'm sending to the wrong person, or wrong mailing list, please let me know. It's my first time trying to ask questions to Linux developers, and sorry for the disturbance. Currently I'm not subscribed to any mailing list, but I will if necessary. Thank you for making Linux great ;) Sincerely, Wenxin Wang

1 0

deferred pages
by Damian Tometzki Nov. 20, 2018

Nov. 20, 2018

Hello together, can anyone me short explain what is deferred page(s) ? Many thanks Best regards Damian

4 4