January 2012 - kernelnewbies@kernelnewbies.org

How to shutdown console redirection
by hz hanks Jan. 25, 2012

Jan. 25, 2012

Hi, all~ I'm studying in an embedded Linux board with only one uart, which is set default as the console display. Now as I try to develop uart driver, I want to shutdown this console redirection temporarily. But I don't know how? I search the Internet, but there's only the tutorial for setting this redirection rather than shutdown it. Is there anyone can help? Thank you very much.

2 2

what is the "+" sigh in the modules folder name?
by Christopher Harvey Jan. 24, 2012

Jan. 24, 2012

I have a path on system called: '/lib/modules/2.6.37+/' It used to be called: '/lib/modules/2.6.37/' where did the plus come from? I'm asking because I have a /lib directory and the kernel sources for it. the problem is there is a closed source driver in the /lib directory and I want to compile a new kernel image, but can't re-compile the closed source modules. I'm guessing my new kernel isn't working because it's looking in the path with the + after being recompiled. thanks, Chris

7 12

git question
by chromaticwt zac Jan. 24, 2012

Jan. 24, 2012

I have a git question regarding the linux kernel. I have cloned linux-stable. I want to merge fs/btrfs from another tree into my linux-stable repo. how can I do this?

2 1

elf core dump - reading NT_PRPSINFO
by Fredrick Jan. 24, 2012

Jan. 24, 2012

Hi, $ readelf -n core Notes at offset 0x00000274 with length 0x000004c0: Owner Data size Description CORE 0x00000090 NT_PRSTATUS (prstatus structure) CORE 0x0000007c NT_PRPSINFO (prpsinfo structure) CORE 0x000000a0 NT_AUXV (auxiliary vector) CORE 0x0000006c NT_FPREGSET (floating point registers) LINUX 0x00000200 NT_PRXFPREG (user_xfpregs structure) LINUX 0x00000030 Unknown note type: (0x00000200) Does anyone know how to read this NT_PRPSINFO ? Is hexdump the only way to decode this? Are there any tools to dump this data ? Thanks, Fredrick

2 3

altinstructions and non-core texts
by Dannie Stanley Jan. 23, 2012

Jan. 23, 2012

Regarding the source code for kernel version 2.6.38. Alternative instructions are extracted from the module's ELF section .altinstructions. The struct alt_instr has a member instr which seems to correspond to an offset in the text in the cases that I have seen. My question: Q1: Do .altinstructions get applied to sections other than .text? Q2: If yes to Q1, how do I know when an alt_instr applies to another section? (by the way, a similar question may apply in the case of jump_labels and smp_locks, so feel free to comment on those as well) Thanks! Dannie -- Dannie M. Stanley

1 0

Re: what is the "+" sigh in the modules folder name?
by Graeme Russ Jan. 23, 2012

Jan. 23, 2012

Hi Robert, On Tue, Jan 24, 2012 at 8:53 AM, Robert P. J. Day <rpjday(a)crashcourse.ca> wrote: > On Tue, 24 Jan 2012, Graeme Russ wrote: > >> It would be worth testing if a checkout of a tag (say 3.2.0) plus a >> local commit causes '+' and 'dirty' > > i think "dirty" only shows up if you have local, uncommitted > changes. but i should probably verify that. Hmm, if that is the case, I wonder if there is a way in git to tell if there are local commits that are not upstream Regards, Graeme

1 0

Re: GPIO driver module for Jetway NF98 board
by Joan Pau Beltran Jan. 23, 2012

Jan. 23, 2012

Thank you very much for your response. It brings up a lot of useful information. Al 22/12/11 01:15, En/na Josh Cartwright ha escrit: > On Wed, Dec 21, 2011 at 06:34:58PM +0100, Joan Pau Beltran wrote: >> Hi everyone, >> >> I did not find any existing driver for the GPIO port of the Jetway >> NF98 mini-itx board, so I would like to write a module for that, >> using the gpiolib interface. >> >> Since the board documentation does not include any information about >> the GPIOs, I contacted the Jetway support team. However, the only >> answer was the attached code for Windows (NF98GPIO.c). >> As you can see, it seems clear how to set the pin states for output, >> but not how to read them in input mode. I asked again and the >> response was (literally): >>> input sample code: >>> { >>> data= ISA_RW(GPIO_BASE[pin]+0x2,highlow<<pin,1,~(1<<pin)); >>> } >>> //final exit SIO >>> outp(INDEX_PORT,0xaa); >>> return data; >> It makes no sense, and it is very upsetting. >> I would try to read from the same address used for output, but this >> is just an idea to be tested. > I think you're on the right track. In researching this board a little > more, I was able to uncover some information. For the sake of > learning, I've included my steps to discovery here: > > From Jetway's website (http://www.jetwaycomputer.com/NF98.html) I found > that the chipset used in the board is an Intel QM57. > > Searching for datasheets for the Intel QM57 brought me to Intel's site > (http://www.intel.com/content/www/us/en/chipsets/5-chipset-3400-chipset-data…) > Searching the document for GPIO, I found section 5.15.4, "GPIO Registers > Lockdown". The content of the text portion of the section didn't seem > all that relevant, but there is a description of a register set that > seems to match up with the values in your attached example: > Relevant information also appears in sections: 13.1.14 GPIOBASE—GPIO Base Address Register (LPC I/F—D31:F0) 13.1.15 GC—GPIO Control Register (LPC I/F—D31:F0) 13.10 General Purpose I/O Registers Where the functionality of each register is described in detail. > Searching for the symbolic names brings up this document, which looks > like it may describe in more detail how to use this GPIO interface: > > http://download.intel.com/embedded/chipsets/appnote/322174.pdf > After looking at both documents, can you please confirm these ideas: 1.- The GPIO functionality of the jwnf98 comes from a hardware device in the chipset called LPC (Low Pin Cout) controller managed through the LPC Interface Bridge registers (section 9.1 page 366). This LPC controller provides other functionalities, too. 2.- The LPC resides in a PCI bus. 3.- GPIO is managed accessing the registers of the LPC. We should read from and write to these registers according to the notes in 13.10 (GPIO_USE_SEL, GPIO_IO_SEL and GPIO_LVL). Not all the GPIOs are available, only the ones given in the Jetway code. 4.- The GPIO registers of the LPC are mapped to some I/O port, starting at the address specified in the GPIOBASE register. From the first paragraph in section 13.10, page 546: > The control for the general purpose I/O signals is handled through a > 128-byte I/O > space. The base offset for this space is selected by the GPIOBASE > register. 5.- From Jetway code, it seems that the base address in the GPIOBASE register described in 13.1.14 is set by the manufacturer to 0x500. Conversely, the Intel code gets that base address reading the GPIOBASE register. Note that specific pci functions are used for that. If Tech Support info is ok, I do not need to do that, and can simply request the needed i/o ports taking as base offset 0x500. If the above points are ok, I have some doubts related with my previous questions: >> 1. How should I request/release the ports mentioned in the attached >> file? Should I use the request_region/release_region functions from >> linux/ioport.h? In such case, what should I do with the returned >> struct resource? I think I should userequest_region/release_region from linux/ioport.h, and simply ignore the returned resource, is it ok? >> 3. Should/could I use the test_bit, set_bit, clear_bit functions to >> get, set the bit in the needed read/write functions I am writing? Or >> should I use the sequence 'inb - mask the value properly - outb' ? > Nope, as far as I know these bitops only work with memory operands. Is this because we use port-based i/o instead of memory-mapped i/o? Here it goes the code again. The main question is, should the gpio_chip be statically allocated, or it should be created in the init function and destroyed in the exit function? If the latter, how to do that? Thank you very much! #include <linux/module.h> #include <linux/types.h> #include <asm-generic/io.h> #define GPIO_BASE 0x500; /* pin 0 (GPIO 21) is controlled by an specific bit of a different set of ports: */ #define PIN0_FUNCTION GPIO_BASE + 0x2; #define PIN0_DIRECTION GPIO_BASE + 0x6; #define PIN0_STATUS GPIO_BASE + 0xE; #define PIN0_BIT 5; /* pins 1 to 7 (GPIO 33 to 39) correspond to the respective bit on these ports */ #define PINX_FUNCTION GPIO_BASE + 0x30; #define PINX_DIRECTION GPIO_BASE + 0x34; #define PINX_STATUS GPIO_BASE + 0x38; static int jwnf98_gpio_direction_input(struct gpio_chip *gc, unsigned off) { unsigned long dir_add; unsigned bit_off; u8 byte; if (off) { dir_add = PINX_DIRECTION; bit_off = off; } else { dir_add = PIN0_DIRECTION; bit_off = PIN0_BIT; } byte = inb(dir_add); byte |= (1 << bit_off); outb(byte, dir_add); } static int jwnf98_gpio_direction_output(struct gpio_chip *gc, unsigned off, int val) { unsigned long dir_add; unsigned long val_add; unsigned bit_off; u8 byte; if (off) { dir_add = PINX_DIRECTION; val_add = PINX_STATUS; bit_off = off; } else { dir_add = PIN0_DIRECTION; val_add = PIN0_STATUS; bit_off = PIN0_BIT; } byte = inb(dir_add); byte &= ~(1 << bit_off); outb(byte, dir_add); if (val) { byte = inb(val_add); byte |= (1 << bit_off); outb(byte, val_add); } else { byte = inb(val_add); byte &= ~(1 << bit_off); outb(byte, val_add); } } static int jwnf98_gpio_get(struct gpio_chip *gc, unsigned off) { unsigned long add; unsigned bit; u8 byte; if (off) { add = PINX_STATUS; bit = off; } else { add = PIN0_STATUS; bit = PIN0_BIT; } byte = inb(add); byte &= (1 << bit); return !!byte; /* Is the double negation !! needed? */ } static void jwnf98_gpio_set(struct gpio_chip *gc, unsigned off, int val) { unsigned long add; unsigned bit; u8 byte; if (off) { add = PINX_STATUS; bit = off; } else { add = PIN0_STATUS; bit = PIN0_BIT; } byte = inb(add); if (val) byte |= (1 << bit); else byte &= ~(1 << bit); outb(byte, add); } static struct gpio_chip gpio_pins = { .label = "jwnf98", .owner = THIS_MODULE, .direction_input = jwnf98_gpio_direction_input, .get = jwnf98_gpio_get, .direction_output = jwnf98_gpio_direction_output, .set = jwnf98_gpio_set, .dbg_show = jwnf98_gpio_dbg_show, .can_sleep = 0, }; static int __init jwnf98_gpio_init(void) { /* Do preliminar work here: - Request ports? - Create the chip here instead of let it be static? How? - Enable gpio function for each pin? - Something else? */ } static void __exit jwnf98_gpio_exit(void) { /* Do cleanup work here: - Release ports? - Delete the chip if it was created on init function instead of being static? How? - Disable gpio function for each pin? - Something else? */ } module_init(jwnf98_gpio_init); module_exit(jwnf98_gpio_exit); MODULE_DESCRIPTION("Jetway NF98 GPIO driver"); MODULE_LICENSE("GPL"); -- Joan Pau Beltran Grup de Sistemes, Robòtica i Visió - DMI Universitat de les Illes Balears Ctra. Valldemossa, km 7.5 07122 Palma Campus Universitari, edifici Anselm Turmeda Telf (+34) 971 17 28 13 Fax (+34) 971 17 30 03

2 4

using sizeof operator
by Sukrit Sangwan Jan. 23, 2012

Jan. 23, 2012

There are instances in the code where sizeof(*ptr) is used. e.g. in net/802/garp.c const struct garp_msg_hdr *gm; if (!pskb_may_pull(skb, sizeof(*gm))) return -1; i want to ask is there any sense in using sizeof(struct garp_msg_hdr) instead of sizeof(*gm) in the above example. Thanks -- Sukrit Sangwan IIT Roorkee

4 4

Re: using sizeof operator
by Daniel Baluta Jan. 22, 2012

Jan. 22, 2012

On Sun, Jan 22, 2012 at 10:17 PM, Sukrit Sangwan <sukritsangwan(a)gmail.com> wrote: > I found an instance where sizeof(struct xyz) is used instead of > sizeof(variablename). > I want to ask if it would be appropriate to contact the author about the > same. Well, this doesn't really matter, but the recommended practice is to use sizeof(*pointer); Please keep intact Cc's list. thanks, Daniel.

1 0

USB Device Driver
by prathamesh deshpande Jan. 22, 2012

Jan. 22, 2012

I am experimenting with a USB device and studied the steps given in Linux Device Drivers book. I have just started kernel programming and am new in this area. This is what I tried to do: I "make" it, then install the module: # insmod trial.ko. Connect the pendrive. I checked the /var/log/messages...seemed fine: Jan 21 00:30:10 prathamesh-laptop kernel: [10508.290016] usbcore:registered new interface driver prathamesh driver Jan 21 00:31:57 prathamesh-laptop kernel: [10615.120142] usb 1-1:newhigh speed USB device using ehci_hcd and address 11 Jan 21 00:31:57 prathamesh-laptop kernel: [10615.273792] usb 1-1:configuration #1 chosen from 1 choice The USB device gets detected and also the individual bulk_in and bulk_out endpoints show no error. But when we AND both endpoints, error occurs (line no. 354 trial.c ) on the terminal :- if (!(dev->bulk_in_endpointAddr && dev->bulk_out_endpointAddr)) { printk(KERN_ALERT "\nTHIS IS THE POINT OF ERROR\n"); err("Could not find both bulk-in and bulk-out endpoints"); goto error; } I see my files created in /sys/bus/usb/drivers.. and a file /dev/prathamesh driver which i can access i guess. Do I need to read/write to this file so that the data gets reflected in the USB using cp command ( however it didn't happen though ) ? I also chmod 777 ( read write and execute permissions ) to /dev/prathamesh driver already. I also tried echo "1" > /dev/prathamesh driver but nothing happened. I am not able to figure out what to do next. I also see a file /sys/bus/usb/drivers/prathamesh\ driver/module/ initstate which contains "live" when my driver is loaded. Also, /sys/bus/usb/drivers/prathamesh driver/6-1:1.2 which has ep_04 ( out_endpoint ) and ep_84 ( in_endpoint )directories which contains information about endpoints. I've attached the folder containing code ( 'trial.c' ) and 'Makefile' and the error messages ( dmseg | tail -n 50 ). Can someone please help and tell me what to do next ? I mean how do I transfer data to my driver so that it gets reflected in my USB ? Thank you and regards, Prathamesh

2 1