I am developing a smartcard UMDF windows driver. I would like to achieve following behaviour:
When listing all connected readers by using API call SCardListReaders I want to retrieve the correct friendly names for each attached reader. So for example if I have two readers of same brand I want this to be returned by the driver:
SmartcardBrand USBReader 0
SmartcardBrand USBReader 1
I know that the friendly name is composed of the attributes SCARD_ATTR_VENDOR_NAME, SCARD_ATTR_VENDOR_IFD_TYPE and SCARD_ATTR_DEVICE_UNIT the driver returns.
My question is, in my driver, how can I distinguish between SmartcardBrand USBReader 0 and SmartcardBrand USBReader 1?
What shall I return to the OS when SCARD_ATTR_DEVICE_UNIT is requested. I cannot use and increment a global static variable in my driver because every time a new reader gets connected a new UMDF host process is launched (I can see it in the task manager) resulting in a separate new memory area.
What is the proper way of counting device instances in a UMDF driver?
I solved the problem by using memory-mapped files. Basically each UMDF process of my driver creates a memory-mapped file with name of the reader's friendly name. When an other process tries to create a file with the same name it indicates that a driver is already running.
However, there is inconsistency when I connect a reader which uses my driver and afterwards connect a reader which uses Windows native driver. The Windows driver will not see my memory-mapped file I created and apply index 0 for its device.
I found out that, when the Windows driver is loaded it queries SCARD_ATTR_VENDOR_IFD_TYPE, SCARD_ATTR_VENDOR_IFD_TYPE and SCARD_ATTR_DEVICE_UNIT from my driver (and from all other drivers currently loaded). I guess this way the Windows driver can know which device units are taken and apply a free one to its reader.
Related
What is the difference between "Inbox driver" and "Direct Memory Mapped driver"? My basic LED blink remote application worked only after selecting Direct Memory mapped driver. What is the unique things associated with this driver?
The Direct Memory Mapped Driver(DMAP) is an in-developement driver that provides GPIO performance improvements over the default inbox driver. If you use Lighting Driver in your application, you should set the controller driver as Direct Memory Mapped Driver,or there will be exception thrown.As far as i know,there is no more official statement about the detailed difference.
1) Is it possible to access a physical address which is not defined in /proc/iomem?
2) If the physical address range of a device does not appear in /proc/iomem, does it mean that the device has not been utilized/initialized yet?
1) Is it possible to access a physical address which is not defined in /proc/iomem?
Yes.
Assuming an ARM processor which memory maps all directly-connected periperals, the driver could perform an ioremap() operation to map the physical memory to virtual memory for access.
But a properly written driver would first call request_mem_region() to ensure that it can use (and lay claim to) that physical address space.
The information in /proc/iomem comes from drivers calling request_mem_region().
2) If the physical address range of a device does not appear in /proc/iomem, does it mean that the device has not been utilized/initialized yet?
You would have to inspect the driver code to determine how well written the driver is.
Is there a request_mem_region() before the ioremap()?
Check the system log using the dmesg command; perhaps driver initialization failed.
Assuming that this is a statically-linked driver rather than a loadable module, then as each kernel device driver has its init() routine called you can get trace output by having added the option "initcall_debug" on the kernel command line. If you are using U-Boot, then this option should be added to the "bootargs" variable (which is used for the kernel command line).
I want to understand the performance of one device driver module in linux kernel. In this case I use carl9170 device driver in linux.
If I use two physical interfaces, how can the single module carl9170 handle 2 different physical interfaces?
Because so far, I have known that these 2 physical interfaces will make 2 instances and use different packet buffers for each but just using single carl9170 module. So it's confusing me.
And which file in linux kernel source code can I find about this handling method (relates to carl9170 device driver)?
Thank you very much for your help
For 2, take a look at the folder:
drivers/net/wireless/ath/carl9170/
This folder is located under your kernel source directory. It contains all the sources of the driver.
For 1:
It is pretty much how classes works on oriented object programming: how does an object know which instance of the data it must work with? The this pointer references the correct in memory data.
Take a look at the file drivers/net/wireless/ath/carl9170/carl9170.h. Every function exported by the driver is declared at this file. Note that every function has at its first parameter a reference to the struct ar9170 data type. This is exactly the data set that the driver must work with. It specifies everything the driver need to know about the device and its sates, since the USB buses address where the device is connected, to the state of the device, like its power, connection state and any other data the driver itself need in order to keep the device working properly.
Note that this is driver internal data thought. The kernel has its own set of data to keep both the driver, the device and the kernel itself working.
Take a look at the 546 line of carl9170.h. It is where the function declarations starts. This file is as of the kernel 3.8.8.
Just like in Object Oriented Programming you would allocate as many instances of a class as you need, the kernel will allocate as many ar9170 structures a it needs, one referencing each device.
The device ids can be obtained under the /sys/class/net directory. There will be a soft link for each of the network devices attached to your computer. This link will point the device to something like the following:
$ ls -l eth0
../../devices/pci0000:00/0000:00:04.0/0000:02:00.0/net/eth0
The pci0000:00 is the bus. The 0000:00:04.0 I believe is the bus address. Finally, the 0000:02:00.0 is the device id. Afaik, every registered device follows the same logic.
Finally, if you have two carl9170 devices, both will be under the directory /sys/class/net but probably one of them will be named wifi0 and the other wifi1. Also, each of them will point to different devices (check it with the command ls -l /sys/class/net).
I just would like to note that in the explanation I haven't used any wireless card. So I'm not sure whether wireless cards are shown under /sys/class/net or not. Anyway, it will be something very similar, like /sys/class/wireless.
I have written a driver, that extracts a value from IRP buffer. Now based on this keyword I have to pass or discard the IRP. So I need to communicate with the database which is not easy from kernel mode driver. So I am using an application or exe for doing this which will result in true or false based on which I will pass or discard the IRP.
I want to link the driver with the application that I get the data in the client application.
I thought about using temp file that can act as a pipe.
Please suggest something.
I would go with IOCTLs.
The application communicating with database starts with sending one or more IOCTLs to the driver. Let's call IOCTLs of this type IOCTL-1.
The completion of IOCTL-1 idicates a request from driver to the database. The request details can be passed in IOCTL output buffer.
The application detects IOCTL-1 completion, retrieves the request details, runs the query and passes results to the driver using a different IOCTL (IOCTL-2). Then it re-sends IOCTL-1 so that the driver can issue another request.
I have a Wi-Fi driver from a manufacturer. That driver has Plug and Play support. After the adapter has been inserted or removed, Windows CE has recognized it successfully. But at boot time, if the adapter is "inserted state", CE OS does not load it so I must remove then insert it.
I want to load the driver automatically during boot time. Is it possible?
Before, I've written a simple stream interface driver. I have edited project.reg to create a sub-key under HKLM\Devices\BuiltIn so that Device Manager can load automatically during boot time. And it was successfully loaded. But Wi-Fi driver is a non-stream driver. Can Device Manager load Wi-Fi driver automatically with the same way?
Are "all of drivers under HKLM\Drivers\BuiltIn" stream interface drivers? What differences are there between stream interface drivers and NDIS Wi-Fi drivers from the point of loading automatically during boot-time? I will very happy if you can explain it a little.
I want to load the driver automatically during boot time. Is it
possible?
Yes, it is definitely possible. That was the main purpose of plug and play devices. The WinCE device automatically loads a driver appropriate to the Plug 'n' Play device. There would not be any need for doing it manually. If so, then there is no need for a Plug 'n' Play functionality.
As this is not happening in your case, you could try the following
Have you checked with any other Plug-n-Play devices to the WinCE device?
Each time you plug-out and plug-in, is it installing the drivers or is it just loading? You can verify the debug logs to confirm this.
Are "all of drivers under HKLM\Drivers\BuiltIn" stream interface drivers? What differences are there between stream interface drivers and NDIS Wi-Fi drivers from the point of loading automatically during boot-time?
Actually, the block devices can also be loaded automatically, as similar to stream interface drivers. The HKEY_LOCAL_MACHINE\Drivers\BuiltIn registry key recognizes built-in block devices also.
You can refer this msdn link for further information regarding loading the block devices.