- kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

where can I find the explanations for pin-ctrl or #clock-cells in the dts file? (device tree)
by ckim＠etri.re.kr Sept. 25, 2021

Sept. 25, 2021

Hi I've downloaded device tree spec from https://www.devicetree.org/specifications/ but it doesn't tell me anything about #clock-cells or pin-ctrl properties. (the spec is the newst 2020 version) Isnt there any full specification somewhere? Thanks, Chan Kim

2 1

Accessing a pdev or its members
by Drew Abbott Sept. 25, 2021

Sept. 25, 2021

Hello all, A third party driver has a probe function foo_probe(struct platform_device) that ends up allocating and initializing a list of various device structs: struct device *dev = &pdev->dev; struct ucsi_dev *udev; udev = devm_kzalloc(dev, sizeof(*udev), GFP_KERNEL); /* initialize udev to important data */ platform_set_drvdata(pdev, udev); I have my own driver that I would like to use to access the *udev that is created when the other device is probed. How would I access a pdev? Or is there a way I can add a function to this driver to expose a *udev? I can't seem to get to it without having a pointer to the pdev, the udev, or some other device struct related to the hardware. Thanks for the help, Drew

2 1

efivars
by Ruben Safir Sept. 23, 2021

Sept. 23, 2021

What is this for? efivarfs on /sys/firmware/efi/efivars type efivarfs why would the OS need to know anything about the UEFI boot loader once it is up and running? -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www2.mrbrklyn.com/resources - Unpublished Archive http://www.coinhangout.com - coins! http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and extermination camps, but incompatible with living as a free human being. -RI Safir 2013

6 33

Re: efivars
by Ruben Safir Sept. 22, 2021

Sept. 22, 2021

On 9/22/21 4:41 AM, FMDF wrote: > What is this for? > > efivarfs on /sys/firmware/efi/efivars type efivarfs > > why would the OS need to know anything about the UEFI > boot loader once it is up and running? > > > Not from the boot loader, but the OS needs system information from the UEFI. Please send your answer to the LIST and never directly to me. -- So many immigrant groups have swept through our town that Brooklyn, like Atlantis, reaches mythological proportions in the mind of the world - RI Safir 1998 http://www.mrbrklyn.com DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002 http://www.nylxs.com - Leadership Development in Free Software http://www.brooklyn-living.com Being so tracked is for FARM ANIMALS and extermination camps, but incompatible with living as a free human being. -RI Safir 2013

1 0

How to print __u128_t in kernel?
by Dongliang Mu Sept. 21, 2021

Sept. 21, 2021

Hello everyone, I encounter one object with __uint128_t type in the following code. But I am not sure how to print the content of __uint128_t. struct user_fpsimd_state { __uint128_t vregs[32]; __u32 fpsr; __u32 fpcr; __u32 __reserved[2]; }; At first, I would like to use: pr_alert("0x%lx %lx\n", i, (uint64_t)(fpreg.vregs[i] >> 64), (uint64_t)(fpreg.vregs[i])); However, gcc reports error with "-Werror" enabled: In function ‘print_fpregs_in_coredump’: error: iteration 32 invokes undefined behavior [-Werror=aggressive-loop-optimizations] 89 | pr_alert("V%d 0x%lx %lx\n", i, (uint64_t)(fpreg.vregs[i] >> 64), Any idea to eliminate this error? -- My best regards to you. No System Is Safe! Dongliang Mu

3 2

Fwd: Commit messages in a series of patches
by FMDF Sept. 20, 2021

Sept. 20, 2021

I'm sorry but, for some reason, the address of kernelnewbies list was missing in my reply to Valdis. So I had to resend it. ---------- Forwarded message --------- From: FMDF <fmdefrancesco(a)gmail.com> Date: Mon, 20 Sep 2021, 11:13 Subject: Re: Commit messages in a series of patches To: Valdis Klētnieks <valdis.kletnieks(a)vt.edu> On Fri, 17 Sep 2021, 23:58 Valdis Klētnieks, <valdis.kletnieks(a)vt.edu> wrote: > On Fri, 17 Sep 2021 11:12:45 +0200, FMDF said: > > > My question is: why "This patch is preparation for _io_ops [future] > > structure removal." is good while "Eventually this function will be > > deleted but some of the code will be reused later." is not. > My fault. I should have provided more context to you: here I copy-paste the relevant part of the commit message... >"Clean up usbctrl_vendoreq () in usb_ops_linux.c. Eventually this function > will be deleted but some of the code will be reused later. This cleanup > makes code reuse easier.". The first is specific about what is being changed This is about what is being changed: "Clean up usbctrl_vendoreq () in usb_ops_linux.c". and why, "This cleanup makes code reuse easier.". and tells the > reviewer what to watch for. "Eventually this function [it is clear we're still talking about usbctrl_vendorreq()] will be deleted but some of the code will be reused later.". Also, the reviewer now knows where to look for > justification - there is hopefully a 0/N patch that explains why and how > this > structure is being removed. > Yes, patch 14/19 delete that _io_ops structure and explains why . In the same way, 18/19 has the deletion of usbctrl_vendorreq() and the commit message explains why. That should provide the "why and how this structure is being removed" (obviously, replace "structure" with "function"). The second doesn't say which "this function" is being removed, Again, usbctrl_vendorreq(). Please re-read the commit message I pasted here if you have doubts. why this is > being done, Again, this is explained later in 18/19, exactly how (later) in 14/19 is also explained why _io_ops structure is removed. I can't see any conceptual difference, can you? or whether the changes were internal to the function, or in other > functions. It is pretty clear that, when we write ""Eventually this function [it is clear we're still talking about usbctrl_vendorreq()] will be deleted but some of the code will be reused later.", we make it clear that the cleaned-up code cannot be reused in the original function because it is going to be deleted. Anyway this is not the point: the Reviewer writes that "[he] is not interested in our future plans", so he asks for the removal of the phrase "Eventually this function will be deleted...". Why didn't he ask also for the removal of "This patch is in preparation of the _io_ops removal"? That is the question: why didn't he say that he is not also interested in [future] plans about _io_ops? It also doesn't explain why or how code will be re-used. > Do you mean that I should have mentioned the names of the two new functions that we create in later patches? I mean those functions that reuse part of the code of the deleted usbctrl_vendorreq? If so, what about "we are not interested in your future plans"? The distinction matters, because the biggest point of reviewing is "Does > this > commit do what was intended?" Answering that question is a lot easier when > it's clear what was intended. > I'm sorry but, after all that has already been said, I am not able to understand the comment above. Thanks, Fabio

1 0

[Clarification] writes to kernel addresses that came from userspace
by Len Baker Sept. 18, 2021

Sept. 18, 2021

Hi, I am taking a look to the issues in the Kernel Self Protection Project [1] and this one [2] (perform taint-tracking of writes to kernel addresses that came from userspace) take my attention. Reading the explanation does not make it clear to me where the flaw is. [extracted from the KSPP] It should be possible to perform taint tracking of addresses in the kernel to avoid flaws of the form: copy_from_user(object, src, ...); ... memcpy(object.address, something, ...); [end of extracted] My question is: Why is this scenario a flaw? If I understand correctly, the copy_from_user() function copies n bytes of src (in user space address) to object (in kernel space address). I think that it is the correct way to act. Then, in kernel space the object is modified. So, I don't see the problem. Sorry if it is a trivial question but I can not figure it out on my own. [1] https://github.com/KSPP/linux/issues [2] https://github.com/KSPP/linux/issues/126 Thanks in advance. Regards, Len

5 6

Commit messages in a series of patches
by FMDF Sept. 17, 2021

Sept. 17, 2021

Hi all, I've sent a series of 19 patches (co-developed by Pavel Skripkin). Now it is v7 and we hope it is the latest revision. :) Few days ago, when it was still at v5, Dan Carpenter reviewed the whole series and asked us to remove "irrelevant" information from the commit message of 15/19: [1] "This relates to the discussion we had about reviewing patches one at a time in the order they arrive. Every patch should be self contained. It should not refer to the past except in the case of explaining the Fixes tag and it should not refer to the future except in the case where it needs to excuse adding unused infrastructure. Reviewing is stateless. We don't want to know about your plans.". I decided that he was right and so I removed that extra information (they were about plans to remove the function that I'm cleaning up in the next patch 18/19. The clean-ups were somewhat necessary because part of the code of the old function is re-used in new functions introduced in 17/19 and 18/19 and it is then deleted forever, with a strange side effect that at least one reviewer (David Laight) thought that we were renaming variables and that renamings should go to separate patches. However they were _not_ renamings (as I explain above). I thought that preventive real renaming of the variables that I reuse in the next patches within _new_ functions would have helped other developers to review the patches 16-19/19 while avoiding that at a quick read they could appear as renaming. Actually then David wrote that now the patches are more easily readable. In the meantime, Dan C. granted his "Reviewed-by" tag to the first 14 patches of 19. All patches from 2/19 to 12/19 have the following phrase in the commit messages: "This patch is in preparation for the _io_ops structure removal.". [2] My question is: why "This patch is preparation for _io_ops [future] structure removal." is good while "Eventually this function will be deleted but some of the code will be reused later." is not. I'm not really interested in this specific case. I'd like to have general guidelines that I can understand and use for my future patches. Sorry for this long email, I wasn't able to make it shorter :( Thanks in advance to whoever has more experience than I have and wants to make this topic clearer to me. Fabio [1] https://lore.kernel.org/lkml/20210915135301.GF2088@kadam/ [2] https://lore.kernel.org/lkml/20210915124149.27543-3-fmdefrancesco@gmail.com/

2 1

Mainlining MSM8960 Device - Initramfs Issue
by logicalerzor Sept. 17, 2021

Sept. 17, 2021

Hello all, I'm trying to learn about Linux by mainlining my device, the Samsung Galaxy S3 SGH-I437. It has a MSM8960 SoC (quite old). I'm trying to get postmarketOS's initramfs to show (I bundle it up with the kernel), but unlike the downstream kernel, nothing appears in the UART console. I know the initramfs is fine (since it works with other devices, including my own device with its downstream kernel). My next step would be to open a debug-console so I can interact with the device, and make it easier to debug further mainlining attempts. However, the last thing it always outputs is "random: crng init done" instead of "### postmarketOS initramfs ###". I'm guessing the problem might have something to do with the kernel itself. Here are my logs. I booted my phone twice to see if there was any difference (delineated with "ÿ[1390] AST_POWERON"): https://pastebin.com/cAERbhp3 My device's DTS is the following (Based on the mainlined MSM8960 DTS): https://pastebin.com/eQnFxLeq Here's the commands I use for making and flashing my kernel (It's annotated for your convenience): https://pastebin.com/uRftqKfS Here are the CONFIG_* options I changed (after doing "make qcom_defconfig"): https://pastebin.com/qQW7UKeR And finally, here is the downstream kernel for my phone (which properly outputs the postmarketOS initramfs output): https://github.com/CyanogenMod/android_kernel_samsung_d2/tree/0dbe2b56847b3… I'm not sure what you would need to help me (I'm guessing the logs and maybe downstream kernel will help, but you guys are pros, while I'm a noob :P), so I basically sent the entire process I have done so far. Who knows, I probably missed something silly, like a CONFIG_* option :P. I'm sorry if this isn't the right place to ask for this type of help. I asked in postmarketOS's Matrix room several times, but it seems like nobody knew what the problem was. I'm hoping that after several weeks of head scratching that someone can point me in a direction that can help me get mainline Linux working on this old device. Thank you, LogicalErzor

1 0

thrashing on format %u vs size_t arg
by jim.cromie＠gmail.com Sept. 15, 2021

Sept. 15, 2021

wrt: + v2pr_info("read %u bytes from userspace <\n%s>\n", len, tmpbuf); Im getting what appears to be conflicting warnings about %u vs unsigned int (sometimes unsigned long int) depending upon platform ?? Ive now tried both %lu and %u What have I missed ? [jimc:dd-drm-next 3/16] lib/dynamic_debug.c:786:53: warning: format specifies type 'unsigned int' but the argument has type 'size_t' (aka 'unsigned long') head: bf8f0832d11f09c546179ca6a2c5432706ea3d32 [kbuild-all] [jimc:dd-drm-next 3/16] include/linux/kern_levels.h:5:25: warning: format '%u' expects argument of type 'unsigned int', but argument 2 has type 'size_t' {aka 'long unsigned int'} Inbox Linux/kbuild-all to-me kernel test robot via lists.01.org Mon, Sep 13, 9:08 PM (11 hours ago) to me, kbuild-all tree: https://github.com/jimc/linux.git dd-drm-next head: bf8f0832d11f09c546179ca6a2c5432706ea3d32 commit: 221a341c10ebb8545beac6ee3937859d26ddcc60 [3/16] dyndbg: rationalize verbosity config: alpha-allyesconfig (attached as .config) kernel test robot Sep 13, 2021, 5:45 AM (1 day ago) to me tree/branch: https://github.com/jimc/linux.git dd-drm-next branch HEAD: 02a6c357b6a5eb02cc6b2ceb5a7a93c809388ae0 nouveau: fold multiple DRM_DEBUG_DRIVERs together Error/Warning in current branch: lib/dynamic_debug.c:786:54: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat] lib/dynamic_debug.c:864:54: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat] lib/dynamic_debug.c:876:54: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') [-Wformat] [jimc:dd-drm-next 3/16] lib/dynamic_debug.c:786:54: warning: format specifies type 'unsigned long' but the argument has type 'size_t' (aka 'unsigned int') Inbox Linux/kbuild-all to-me kernel test robot Sep 11, 2021, 5:17 PM (3 days ago) to me, kbuild-all tree: https://github.com/jimc/linux.git dd-drm-next head: 02a6c357b6a5eb02cc6b2ceb5a7a93c809388ae0 commit: 74992de06222ed51caed07800e291e68eb4a627e [3/16] dyndbg: rationalize verbosity config: hexagon-randconfig-r034-20210911 (attached as .config) compiler: clang version 14.0.0 (https://github.com/llvm/llvm-project 261cbe98c38f8c1ee1a482fe76511110e790f58a)

3 5