I am beginner in linux drivers,im trying to develop a driver for an interrupt controller.
this block is implemented on FPGA , running under linux with RiscV architecture.
I would need help with the following questions:
Can I make this linux driver as a "char driver" or else, it must be a "platform driver" or even (IRQChip driver!: Arm) ;
I saw the driver of Xilinx AXI controler , what is the type of the driver? https://github.com/Xilinx/linux-xlnx/blob/master/drivers/irqchip/irq-xilinx-intc.c
where the interrupt handling functions should be implemented if it is a char driver: in the functions (file_operations e.g. Open)
or it's IOCTL, same question for a driver platform;
Do you have a skeleton to follow for developing the driver of this interrupt controller or steps .
Related
I want to read data from CAN bus and for that I am using MPC2515 (as a CAN Conroller) via SPI.
Working on Up Board 2 based on Ubilinux (Linux kernel version is 4.9.45), its architecture x86 doesn't use device-tree entries like ARM for example. So how can I define SPI device settings?
So I was wondering: Since libusb provides userspace access to USB, is it possible to port already existing kernel drivers to libusb?
I do understand it might need rewriting of the driver, but do you think it is possible to write a "virtual kernel" that relies on libusb for access to devices and link already existing drivers to that? Essentially writing a layer between libusb and kernel modules that translates kernel USB commands to libusb commands.
Why bother? If you want to run a kernel driver on Android for example, you need to make sure it was compiled for a particular kernel version/device model. So an app will not be able to run on all devices. On the other hand libusb is fully compatible with most of the latest Android devcices.
AFAIK, libusb is a library that communicates with the higher level of the USB layer of the kernel. The lowest parts of the USB subsystem have to be written in kernel space, because they need to have access to the physical address space of the USB host controller and uses interrupts, and other low-level functions that are not possible to implement in user space.
So I don't think that it is possible to port low-level parts of the USB subsystem in user-space.
I am using mcp3021.c file for Microchip MCP3021 IC. My module's init and exit functions are replaced with module_i2c_driver(mcp3021_driver), But I don't see the driver register print in my Kernel log when I ran the code. Can anybody please help me with this ?
First thing which kernel version you are using ? because this macro is introduced in Linux kernel after version 3.3 .
So if your are using kernel version below this you should actually get error while compiling the kernel.
You have verify are few things to make it work,
Ensure that I2C device is properly mounted in hardware.
Confirm that your device is not in reset state.
Ensure that in your device tree you are using the appropriate I2C bus and driver id is properly configured.
Check your kernel configuration(.config) that your driver is enabled.
I2C Probe will be called only if above all conditions are met.
I've not clear what is the difference between drivers that can be "embedded" inside a monolithic kernel and drivers available only as external modules.
What kind of effort is requested to "port" some driver (provided as "external module" only) to a monolithic kernel?
I would like to be able to run Vmware Tools disabling loadable modules support and getting rid of the initrd bazaar.
Though the driver more or less remains the same(in both cases),there are definitely benefits for using "drivers" embedded in monolithic kernel.
I'll try to explain the "effort in porting" the driver part which you've asked.
Depending on the kind of driver you've, essentially you've to figure out how it will fit in the current kernel source tree, its compilation(include your .ko in the uImage) and loading of it while kernel booting. Let's illustrate each step a bit:
a.) Locate the folder (in the kernel source tree) where you think it is best suited to keep your driver code.
b.) Work on to make sure your driver code is getting compiled.[i.e ultimately it will be part of monolithic kernel image(uImage or whatever you call it)]. In this context, You've to work on your Makefile for your driver. You might have to introduce some CONFIG flags to compile your driver code. There are tons of Makefiles' and driver code lying in the source tree. Roam around and you will get a good reference of how it is being done.
c.) Make sure that your driver code is independent of any other
loadable kernel module(i.e such modules which are not part of the
"monolithic" kernel image). Because if you invoke your driver
code(which is monolithic now and is in memory) which depends on
loadable module code then it may cause some kernel
panic/segmentation fault kind of error.
d.) Make sure that your driver is registered with a higher level of
subsystem which will be initializing all the registered drivers
during boot-up time.(for example: an i2c driver once registered
with i2c driver framework will be loaded automatically when i2c subsystem is initialized during system startup). This step might not be really required if you can figure out another way of invoking your driver's __init and __exit functions.
e.) Now, Your Driver _init and (_exit sections) "should" be called
if it is getting loaded by any device driver framework or directly(i.e. while
kernel is booting up ).
f.) In case of h/w drivers, we have .probe implementation in driver
which will be invoked once the kernel finds a corresponding device.
In case of s/w drivers, I guess __init and __exit is all you have.
g.) Once it is loaded, you can use it like you were using it earlier as a loadable kernel module
h.) I'll recommend reading source code of similar device drivers in the linux kernel tree and see how they are operating.
Hope this helps.
I want to port libUSB driver to the windows driver using WDK (In Kernel Mode).
I found that libUSB internally uses the winUSB ( From libUSB Sources).
This is what I do in the libusb,
I get the handle using, libusb_open_device_with_vid_pid
or libusb internally uses pSetupDiGetClassDevsA and other pSetupDi*** functions
I send the data using libusb_control_transfer or internally WinUSB's WinUsb_WritePipe
What are the equivalent functions of this in WDK in Kernel mode?
Is there any sample that I can use?
NOTE:
The reason I am asking for kernel mode is, I need to take this data and re-route it as HID Mini Driver.
You should read about WDM drivers. It is a totally different story doing this in kernel mode. There is a sample in winddk called usbsamp. I suggest you to start there.
for easier approches, you may want to look at KMDF : read this http://msdn.microsoft.com/en-us/library/windows/hardware/gg463311.aspx