The Linux Kernel Module Programming Guide
1–10 of 32 posts
Re: The Linux Kernel Module Programming Guide
#2Re: The Linux Kernel Module Programming Guide
#3Just a warning if you do embedded work with Linux (RPi, Beaglebone, etc)... this guide doesn't cover the Devicetree APIs. Doesn't even acknowledge their existence.
Re: The Linux Kernel Module Programming Guide
#4Just a warning if you do embedded work with Linux (RPi, Beaglebone, etc)... this guide doesn't cover the Devicetree APIs. Doesn't even acknowledge their existence.
The author is pretty open to any kind of criticisms and suggestions. It would be great if you open an issue to inform him the missing contents.
Re: The Linux Kernel Module Programming Guide
#5Just a warning if you do embedded work with Linux (RPi, Beaglebone, etc)... this guide doesn't cover the Devicetree APIs. Doesn't even acknowledge their existence.
Re: The Linux Kernel Module Programming Guide
#6Just a warning if you do embedded work with Linux (RPi, Beaglebone, etc)... this guide doesn't cover the Devicetree APIs. Doesn't even acknowledge their existence.
Re: The Linux Kernel Module Programming Guide
#7Like let's say I wanted to instantiate an I2C with a custom driver in my device-tree. Can I put the controller's driver in a kernel module that lives in /lib/modules? Or do I need to compile it into the kernel?
Re: The Linux Kernel Module Programming Guide
#8Just a warning if you do embedded work with Linux (RPi, Beaglebone, etc)... this guide doesn't cover the Devicetree APIs. Doesn't even acknowledge their existence.
RPi is barely embedded work. It's almost always micro-desktop Linux.
Anyone working with a SOM, for example, will want to customize the DT for their carrier board. And then your EE finds a cheaper controller chip somewhere. And then your display supplier switches captouch parts on you mid-production.
Sorry, was I venting there?
(And just a tip, don't break bad on the Pi here. For many people this is the only ARM platform worth working with. And definitely don't make fun of the lack of peripherals on the thing)