I have come across a show stopping problem when developing an interface application for a USB to RS422 converter module.
I need to retrieve the UART error counters for framing, overrun, parity and break errors. But the call to ioctl always returns -1 and the counter values from the retrieved struct are jumping to very big numbers.
The code i am using to retrieve the counters is the following:
struct serial_icounter_struct counters;
int ret = ioctl(portDescriptor, TIOCGICOUNT, &counters);
To set the portDescriptor i am using a similar code to:
int portDescriptor = open("/dev/ttyUSB0", O_RDWR | O_NOCTTY | O_NDELAY);
struct termios new_port_settings;
//clear the new struct
memset(&new_port_settings, 0, sizeof(new_port_settings));
//set port settings
new_port_settings.c_cflag = B57600 | CS8 | CLOCAL | CREAD;
new_port_settings.c_oflag = 0;
new_port_settings.c_lflag = 0;
new_port_settings.c_cc[VMIN] = 0;
new_port_settings.c_cc[VTIME] = 0;
int error = tcsetattr(portDescriptor, TCSANOW, &new_port_settings)
Sometimes we also need to enable flow control or parity e.g.
new_port_settings.c_cflag = new_port_settings.c_cflag | CRTSCTS;
I have tried the code on a Ubuntu 11.10 32bit and on a SLES11 SP1 64bit, both with the FTDI_SIO kernel module.
Is anybody aware of any kind of issue regarding the usage of TIOCGICOUNT or am I doing something wrong?
Related
I am writing a remote control driver for an embedded system with Linux 3.X. It's using an GUI which reads keyboard input from /dev/tty0. Related source codes of this GUI about opening a keyboard device are as follows.
static int TTY_Open (const char *unused)
{
if (geteuid() == 0) /* is a super user, try to open the active console */
tty_dev = "/dev/tty0";
else /* not a super user, so try to open the control terminal */
tty_dev = "/dev/tty";
kbd_fd = open(tty_dev, O_RDONLY | O_NOCTTY);
if (kbd_fd < 0)
return -1;
if (tcgetattr(kbd_fd, &startup_termios) < 0)
goto err;
work_termios = startup_termios;
work_termios.c_lflag &= ~(ICANON | ECHO | ISIG);
work_termios.c_iflag &= ~(ISTRIP | IGNCR | ICRNL | INLCR | IXOFF | IXON);
work_termios.c_iflag |= IGNBRK;
work_termios.c_cc[VMIN] = 0;
work_termios.c_cc[VTIME] = 0;
if(tcsetattr(kbd_fd, TCSAFLUSH, &work_termios) < 0)
goto err;
/* Put the keyboard into MEDIUMRAW mode. Despite the name, this
* is really "mostly raw", with the kernel just folding long
* scancode sequences (e.g. E0 XX) onto single keycodes.
*/
ioctl (kbd_fd, KDGKBMODE, &startup_kbdmode);
if (ioctl(kbd_fd, KDSKBMODE, K_MEDIUMRAW) < 0)
goto err;
return kbd_fd;
err:
close(kbd_fd);
kbd_fd = 0;
return -1;
}
My driver was implemented with Linux input subsystem. In its interrupt handler, input_report_key is used to report key event.
Then I find it surprising that the GUI can read both inputs from an USB keyboard and the remote driver! But the devices corresponding to the keyboard and remote control are /dev/input/eventX. How could it read those inputs from /dev/tty0???
I find it quite confusing and can not get answers from Google. Can someone explain it?
I'm playing with some driver code for a special kind of keyboard. And this keyboard does have special modes. According to the specification those modes could only be enabled by sending and getting feature reports.
I'm using 'hid.c' file and user mode to send HID reports. But both 'hid_read' and 'hid_get_feature_report' failed with error number -1.
I already tried detaching keyboard from kernel drivers using libusb, but when I do that, 'hid_open' fails. I guess this is due to that HID interface already using by 'input' or some driver by the kernel. So I may not need to unbind kernel hidraw driver, instead I should try unbinding the keyboard ('input') driver top of 'hidraw' driver. Am I correct?
And any idea how I could do that? And how to find what are drivers using which drivers and which low level driver bind to which driver?
I found the answer to this myself.
The answer is to dig this project and find it's hid implementation on libusb.
Or you could directly receive the report.
int HID_API_EXPORT hid_get_feature_report(hid_device *dev, unsigned char *data, size_t length)
{
int res = -1;
int skipped_report_id = 0;
int report_number = data[0];
if (report_number == 0x0) {
/* Offset the return buffer by 1, so that the report ID
will remain in byte 0. */
data++;
length--;
skipped_report_id = 1;
}
res = libusb_control_transfer(dev->device_handle,
LIBUSB_REQUEST_TYPE_CLASS|LIBUSB_RECIPIENT_INTERFACE|LIBUSB_ENDPOINT_IN,
0x01/*HID get_report*/,
(3/*HID feature*/ << 8) | report_number,
dev->interface,
(unsigned char *)data, length,
1000/*timeout millis*/);
if (res < 0)
return -1;
if (skipped_report_id)
res++;
return res;
}
I'm sorry I can't post my actual code due to some legal reasons. However the above code is from hidapi implementation.
So even you work with an old kernel , you still have the chance to make your driver working.
This answers to this question too: https://stackoverflow.com/questions/30565999/kernel-version-2-6-32-does-not-support-hidiocgfeature
I have some machines running on the same network. One node is the control node which distributes traffic coming to it to the other nodes. The thing is that I want to have a custom protocol header between MAC header and IP(or whatever) payload incoming to the control node.
Control node receives this any packet like this:
------------------------------------------------
| Layer 2 | IP(or whatever protocol) | Payload |
------------------------------------------------
This packet should be distributed like this to other nodes
----------------------------------------------------------------
| Layer 2 | Custom Header | IP(or whatever protocol) | Payload |
----------------------------------------------------------------
I want some directions to do such a thing, Is there any current solution which I can use and I have to hack kernel for it from the scratch. A similar approach is to use L2TP but that runs over IP layer so I dont want that.
I also want this communication to be appeared as a seperate interface in linux like tun0 apart from physical eth0 interface.
Any help or ideas would be highly appreciated.
I dont know in what stack-exchange website this question belongs to so directions to correct website are also appreciated.
Your case is very similar to VLAN, where VLAN header also sits between L2 header and IP header. You can take a look at VLAN code, especially net/8021q/vlan_dev.c.
The key here is you need to construct your own L2 header, so you need to register your own header_ops like what VLAN does:
static const struct header_ops vlan_header_ops = {
.create = vlan_dev_hard_header,
.rebuild = vlan_dev_rebuild_header,
.parse = eth_header_parse,
};
and register it during initialization:
dev->header_ops = &vlan_header_ops;
dev->hard_header_len = real_dev->hard_header_len + VLAN_HLEN;
The ->create() function pointer here is used to create the custom header:
static int vlan_dev_hard_header(struct sk_buff *skb, struct net_device *dev,
unsigned short type,
const void *daddr, const void *saddr,
unsigned int len)
{
struct vlan_hdr *vhdr;
unsigned int vhdrlen = 0;
u16 vlan_tci = 0;
int rc;
if (!(vlan_dev_priv(dev)->flags & VLAN_FLAG_REORDER_HDR)) {
vhdr = (struct vlan_hdr *) skb_push(skb, VLAN_HLEN);
vlan_tci = vlan_dev_priv(dev)->vlan_id;
vlan_tci |= vlan_dev_get_egress_qos_mask(dev, skb);
vhdr->h_vlan_TCI = htons(vlan_tci);
/*
* Set the protocol type. For a packet of type ETH_P_802_3/2 we
* put the length in here instead.
*/
if (type != ETH_P_802_3 && type != ETH_P_802_2)
vhdr->h_vlan_encapsulated_proto = htons(type);
else
vhdr->h_vlan_encapsulated_proto = htons(len);
skb->protocol = htons(ETH_P_8021Q);
type = ETH_P_8021Q;
vhdrlen = VLAN_HLEN;
}
/* Before delegating work to the lower layer, enter our MAC-address */
if (saddr == NULL)
saddr = dev->dev_addr;
/* Now make the underlying real hard header */
dev = vlan_dev_priv(dev)->real_dev;
rc = dev_hard_header(skb, dev, type, daddr, saddr, len + vhdrlen);
if (rc > 0)
rc += vhdrlen;
return rc;
}
I am developing for an ARM device running Linux 2.6.37. I am trying to toggle an IO pin as fast as possible. I made a little kernel module and a user space application. I tried two things :
Manipulate the GPIO control registers directly from the kernel space using ioremap.
mmap() the GPIO control registers without caching and using them from user space.
Both methods work, but the second is about 3 times slower than the first (observed on oscilloscope). I think I disabled all caching mechanisms.
Of course I'd like to get the best of the two worlds : flexibility and ease of development from user space with the speed of kernel space.
Does anybody know why the mmap() could be slower than the ioremap() ?
Here's my code :
Kernel module code
static int ti81xx_usmap_mmap(struct file* pFile, struct vm_area_struct* pVma)
{
pVma->vm_flags |= VM_RESERVED;
pVma->vm_page_prot = pgprot_noncached(pVma->vm_page_prot);
if (io_remap_pfn_range(pVma, pVma->vm_start, pVma->vm_pgoff,
pVma->vm_end - pVma->vm_start, pVma->vm_page_prot))
return -EAGAIN;
pVma->vm_ops = &ti81xx_usmap_vm_ops;
return 0;
}
static void ti81xx_usmap_test_gpio(void)
{
u32* pGpIoRegisters = ioremap_nocache(TI81XX_GPIO0_BASE, 0x400);
const u32 pin = 1 << 24;
int i;
/* I should use IO read/write functions instead of pointer deferencing,
* but portability isn't the issue here */
pGpIoRegisters[OMAP4_GPIO_OE >> 2] &= ~pin; /* Set pin as output*/
for (i = 0; i < 200000000; ++i)
{
pGpIoRegisters[OMAP4_GPIO_SETDATAOUT >> 2] = pin;
pGpIoRegisters[OMAP4_GPIO_CLEARDATAOUT >> 2] = pin;
}
pGpIoRegisters[OMAP4_GPIO_OE >> 2] |= pin; /* Set pin as input*/
iounmap(pGpIoRegisters);
}
User space application code
int main(int argc, char** argv)
{
int file, i;
ulong* pGpIoRegisters = NULL;
ulong pin = 1 << 24;
file = open("/dev/ti81xx-usmap", O_RDWR | O_SYNC);
if (file < 0)
{
printf("open failed (%d)\n", errno);
return 1;
}
printf("Toggle from kernel space...");
fflush(stdout);
ioctl(file, TI81XX_USMAP_IOCTL_TEST_GPIO);
printf(" done\n");
pGpIoRegisters = mmap(NULL, 0x400, PROT_READ | PROT_WRITE, MAP_SHARED, file, TI81XX_GPIO0_BASE);
printf("Toggle from user space...");
fflush(stdout);
pGpIoRegisters[OMAP4_GPIO_OE >> 2] &= ~pin;
for (i = 0; i < 30000000; ++i)
{
pGpIoRegisters[OMAP4_GPIO_SETDATAOUT >> 2] = pin;
pGpIoRegisters[OMAP4_GPIO_CLEARDATAOUT >> 2] = pin;
}
pGpIoRegisters[OMAP4_GPIO_OE >> 2] |= pin;
printf(" done\n");
fflush(stdout);
munmap(pGpIoRegisters, 0x400);
close(file);
return 0;
}
This is because ioremap_nocache() still enables the CPU write buffer in your VM mapping whereas pgprot_noncached() disables both bufferability and cacheability.
Apples to apples comparison would be to use ioremap_strongly_ordered() instead.
My guess would be that since mmap has to check to make sure you're writing to memory you're allowed to write to, it's going to be slower than the kernel version (which I believe/assume doesn't do that kind of checking--with a kernel module you're responsible for testing until you're very sure you're not breaking things).
Try using do_mmap (I believe that's the one) to use mmap from kernel space, and see how that compares. If it's comparably faster, then I'm right. If it's not, it's something else.
I have a big problem. At present I am accessing a serial port via the following hooks:
fd = open( "/dev/ttyS1", O_RDWR | O_NOCTTY )
then I read from it using the following chunk of code
i = select( fd + 1, &rfds, NULL, NULL, &tv )
...
iLen = read( fd, buf, MAX_PACKET_LEN )
the problem is that before I read, I need to detect if there were any buffer overruns. Both at the serial port level and the internal tty flip buffers.
We tried cat /proc/tty/driver/serial but it doesn't seem to list the overruns (see output below)
1: uart:16550A port:000002F8 irq:3 tx:70774 rx:862484 fe:44443 pe:270023 brk:30301 RTS|CTS|DTR
According to the kernel sources, you should use the TIOCGICOUNT ioctl. The third ioctl argument should be a pointer to the following struct, defined in <linux/serial.h> :
/*
* Serial input interrupt line counters -- external structure
* Four lines can interrupt: CTS, DSR, RI, DCD
*/
struct serial_icounter_struct {
int cts, dsr, rng, dcd;
int rx, tx;
int frame, overrun, parity, brk;
int buf_overrun;
int reserved[9];
};
I don't know if every driver detect all conditions however.
Dark Templer,
Your serial driver should update the icount.frame/overrun errors.
struct uart_port in serial_core.h has member struct uart_icount, which should be updated in platform serial device driver as per interrupts received.