Re: Appropriate method of io remapping a single memory location?
On Tue, May 5, 2015 at 3:29 PM, maitysancha...@gmail.com wrote: Thanks for the reply. Hmm... I did not think of a DT entry as it is a single location and not part of any particular peripheral. Not even mentioned in the memory map. That's why I suggested to use a syscon device. I tried grepping for ioremap functions instead of devm ones and saw one instance and I wrote mine like this rom_rev = ioremap(ROM_REVISION_REGISTER, SZ_1); if (rom_rev) soc_dev_attr-revision = kasprintf(GFP_KERNEL, %08x, readl(rom_rev)); Is something like this valid? Or use of devm_* functions is recommeneded? Since this ioremap is gonna be called from a function which is bound to the .init_machine entry of DT_MACHINE_START any harm in doing this ioremap directly or the DT method would be recommended? I guess that DT is always recommended. I would use something like of_find_compatible_node() + of_iomap() on the syscon device for that (after of_platform_populate()). Probably you could use also directly the physical location or a iotable but it is definitely uglier IMO. -- Carlo Caione ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Preferred userspace IPC mechanism for new drivers?
Hello, I’m writing a driver that needs to communicate with userspace applications. Userspace needs to be able to send commands and associated data to the driver, so the ioctl interface seems pretty straightforward. However, LDD3 states that new ioctls in the kernel are a no-no. If that’s the case, then what is the preferred interface to userspace for new drivers? ProcFS seems to be discouraged. Sysfs seems to be more for exporting device model information rather than passing binary blobs back and forth. DebugFS seems to be intended only for debug. Generic Netlink seems like the most viable candidate that I’ve investigated so far. Is that what most people are using these days? Any advice would be greatly appreciated. Thanks! Sincerely, Jesse Larrew Senior Software Engineer AMD Security Architecture RD jesse.lar...@amd.com O: +(1) 512-602-0092 (x50092) M: +(1) 512-791-4852 ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
About head of kernel linked list structure
In my understanding, the head initialised using LIST_HEAD_INIT or defined by LIST_HEAD corresponds to no *real* data field. But it *does* have its own _next_ and _prev_ pointers. The _next_ pointer points to the first real node in the doubly linked list, and the _prev_ pointer points to the last real node. I'm wondering if the picture shown at the very bottom of http://kernelnewbies.org/FAQ/LinkedLists is wrong about this. Because I believe head's _prev_ should point to the last node, which is at the very right. And the last node's _next_ should point to the head. Just as shown like the red line. Am I right? -- Best Regards Huaicheng Li ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Re: About head of kernel linked list structure
On Wed, 6 May 2015, Huaicheng Li wrote: In my understanding, the head initialised using LIST_HEAD_INIT or defined by LIST_HEAD corresponds to no *real* data field. correct. a better way to describe it would be that it corresponds to no real enclosing payload, so it should never be dereferenced to get to said payload. But it *does* have its own _next_ and _prev_ pointers. The _next_ pointer points to the first real node in the doubly linked list, and the _prev_ pointer points to the last real node. so far, so good -- by real, you mean list heads that actually correspond to an enclosing payload. I'm wondering if the picture shown at the very bottom of http://kernelnewbies.org/FAQ/LinkedLists is wrong about this. Because I believe head's _prev_ should point to the last node, which is at the very right. And the last node's _next_ should point to the head. Just as shown like the red line. Am I right? it looks fine to me, although my standard is to show next pointers going to the right, and prev to the left, but this way looks fine. maybe i'm misunderstanding your objection. i once wrote a tutorial on LLs: http://www.crashcourse.ca/introduction-linux-kernel-programming/intermission-lets-talk-about-linked-lists-and-containerof-free rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Map syscall nr to syscall name
Hi all I am looking for an efficient way to convert syscall number to syscall name. I can get syscall number by enabling profiling using perf_event_open(), but cant find way to convert it to actual syscall name. Thanks --sahil ___ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
