struct net_device has no member named pm_qos_req.
Where can I find the relevant API structure?
SHORT ANSWER
pm_qos_req field in struct net_device was using only for e1000e driver, therefore it was decided to move this field to e1000e driver structure, so that rest of drivers that use struct net_device will not waste a few bytes of memory when allocating struct net_device. See e2c6544829 commit for details.
If you are developing e1000e driver and having issues, you can back-port e2c6544829 commit to your kernel baseline.
Otherwise, if you are maintaining some driver which is not upstreamed and is using pm_qos_req, use e2c6544829 commit as reference to rework your driver. Basically you need to add pm_qos_req field to your driver struct and use it from that struct instead of struct net_device.
THE WHOLE INVESTIGATION
Here is how you can figure this out:
Download mainline kernel:
$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Checkout to corresponding tag (well, in your case you can skip this step):
$ git checkout v4.1-rc3
(v4.1-rc3 is a tag; all tags can be listed by git tag command)
Search for pm_qos_req text changed in include/linux/netdevice.h file, using git:
$ git log -S'pm_qos_req' --oneline -- include/linux/netdevice.h
It will give you next commits:
01d460d net: Remove remaining remnants of pm_qos from netdevice.h
e2c6544 e1000e: Move pm_qos_req to e1000e adapter
536721b net: kernel-doc compliant documentation for net_device
ed77134 PM QOS update
Top commit in that list is the last one (was added most recently).
Check out interested commits with git show command. You are particularly interested in e2c6544 commit (it's where .pm_qos_req was removed from struct net_device):
$ git show e2c6544
Pay attention to commit message:
e1000e is the only driver requiring pm_qos_req, instead of causing
every device to waste up to 240 bytes. Allocate it for the specific
driver.
Now we can checkout to previous kernel versions and check which drivers are using this pm_qos_req field.
$ git grep -n '\bpm_qos_req\b' v3.0 -- drivers/
From grep output we can see that only e1000e driver is using this field.
Related
As the title: Since which version did Linux kernel start to support V4L2 subdev model?
I am trying to look for some similar camera driver to start with, for developing our OV9282 camera driver. Since different Linux kernels have different driver models, we need to know it in advance.
In addition, who can tell me what's the difference between soc-camera (such as kernel/drivers/media/i2c/soc-camera/*.c) and non-soc-camera drivers (such as kernel/drivers/media/i2c/*.c)
Short answer
Using a few git log on random files, it looks like it was included un v3.6-rc1-292-g5bc3cb7.
More detailed answer
First, find v4l2 related files: find -name v4l2\*
Pick some of them, and find out when they were introduced, using git log.
Finally, use git describe with the commit ID to get the tag you're looking for.
✔ ~/src/linux $ git --no-pager log --pretty=oneline --reverse ./include/media/v4l2-clk.h
ff5430de70e8137daccecfa1211509f95fcc8d25 [media] V4L2: add temporary clock helpers
cf326dfebe612bf56c83d8fca7a7c1d1584c061f [media] V4L2: add v4l2-clock helpers to register and unregister a fixed-rate clock
774cc4c289152bfb77806ccae722a9ae2d29dd02 [media] V4L2: add a v4l2-clk helper macro to produce an I2C device ID
a37462b919e1368ea3cf4bb0cbdb00ca8e76959c [media] V4L: remove clock name from v4l2_clk API
4f528afcfbcac540c8690b41307cac5c22088ff1 [media] V4L: add CCF support to the v4l2_clk API
ac2841f3b80170415b63ae5ca8ea417f65244604 [media] v4l2-clk: add new macro for v4l2_clk_name_of()
3d83078a081a2bac7639d09404d85085368c8b66 [media] v4l2-clk: add new definition: V4L2_CLK_NAME_SIZE
68d9c47b1679ec8d55a005d39fc7a958ece82095 media: Convert to using %pOF instead of full_name
✔ ~/src/linux $ git describe ff5430de70e8137daccecfa1211509f95fcc8d25
v3.10-rc6-391-gff5430d
Any improvement for that solution is welcome!
Footnote: I couldn't manage to use git only commands to extract the first commit, in reversed order, see this question.
I am building my SLES 12 driver (block device driver) with 3.x kernel on SLES 12 SP2 which has kernel version 4.4.2 . Now I am facing problem with few things:
struct bvec_merge_data
is not available in kernel 4.3.0 onwards in include/linux/blkdev.h
struct bvec_merge_data {
struct block_device *bi_bdev;
sector_t bi_sector;
unsigned bi_size;
unsigned long bi_rw;
};
from 4.2.8 onward this funtion pointer is not present. What might be the alternative method is provided in 4.3 or higher versions.
typedef int (merge_bvec_fn) (struct request_queue *, struct
bvec_merge_data *,
struct bio_vec *);
In the request_queue structure the below structure elements are removed form 4.2.8 where these elemments are handled
struct request_queue {
unprep_rq_fn *unprep_rq_fn;
merge_bvec_fn *merge_bvec_fn;
Any idea where can I look for these changes and and any alternative for those?
Best place for such answers is git log of kernel source. Supplying -S switch will search within the diff content. Supplying -G will do same but with regular expressions.
In this case running git log -S "bvec_merge_data" shows information on changes related to this struct and, by association, merge_bvec_fn method. Here's snapshot of the top message which talks about complete removal of struct bvec_merge_data:
commit 8ae126660fddbeebb9251a174e6fa45b6ad8f932 Author: Kent
Overstreet Date: Mon Apr 27 23:48:34
2015 -0700
block: kill merge_bvec_fn() completely
As generic_make_request() is now able to handle arbitrarily sized bios,
it's no longer necessary for each individual block driver to define its
own ->merge_bvec_fn() callback. Remove every invocation completely.
Other commit message preceding this one show the build up to it, which can be a good step-by-step explanation to your question.
Hope it helps :)
In a linux device driver, creating sysfs attributes in probe is way too racy--specifically, it experiences a race condition with userspace. The recommended workaround is to add your attributes to various default attribute groups so they can be automatically created before probe. For a device driver, struct device_driver contains const struct attribute_group **groups for this purpose.
However, struct attribute_group only got a field for binary attributes in Linux 3.11. With older kernels (specifically, 3.4), how should a device driver create sysfs binary attributes before probe?
Quoting (emphasis mine) Greg Kroah-Hartman from his comment to a merge request (that was merged by Linus as a part of 3.11 development cycle):
Here are some driver core patches for 3.11-rc2. They aren't really
bugfixes, but a bunch of new helper macros for drivers to properly
create attribute groups, which drivers and subsystems need to fix up a
ton of race issues with incorrectly creating sysfs files (binary and
normal) after userspace has been told that the device is present.
Also here is the ability to create binary files as attribute groups, to solve that race condition, which was impossible to do before this, so that's my fault the drivers were broken.
So it looks like there really is no way to solve this problem on old kernels.
I am having troubles with gpio interrupt issue.
According documentation for ep93xx ports A, B, F can be configured to generate interrupts.
quote:
Any of the 19 GPIO lines maybe configured to generate interrupts
However arch/arm/march-ep93xx/gpio.c is handling only interrupts from port A. And doesn't react to port B and F.
static void ep93xx_gpio_ab_irq_handler(unsigned int irq, struct irq_desc *desc)
{
unsigned char status;
int i;
printk(KERN_INFO "ep93xx_gpio_ab_irq_handler: irq=%u", irq);
I know printk is terrible in irq_handlers.
I am configuring iterrupts via sysfs.
GPIO 0,8 are wired with Port F if it is important to issue.
Also when enabling interrupts on port B without having configured port A i get following warning:
------------[ cut here ]------------
WARNING: at drivers/gpio/gpiolib.c:103 gpio_ensure_requested+0x54/0x118()
autorequest GPIO-1
Modules linked in:
[<c002696c>] (unwind_backtrace+0x0/0xf0) from [<c00399d4>] (warn_slowpath_fmt+0x54/0x78)
[<c00399d4>] (warn_slowpath_fmt+0x54/0x78) from [<c019dd90>] (gpio_ensure_requested+0x54/0x118)
[<c019dd90>] (gpio_ensure_requested+0x54/0x118) from [<c019e05c>] (gpio_direction_input+0xb0/0x150)
[<c019e05c>] (gpio_direction_input+0xb0/0x150) from [<c002c9a8>] (ep93xx_gpio_irq_type+0x3c/0x1d8)
[<c002c9a8>] (ep93xx_gpio_irq_type+0x3c/0x1d8) from [<c0066ad8>] (__irq_set_trigger+0x38/0x9c)
[<c0066ad8>] (__irq_set_trigger+0x38/0x9c) from [<c0066e14>] (__setup_irq+0x2d8/0x354)
[<c0066e14>] (__setup_irq+0x2d8/0x354) from [<c0066f38>] (request_threaded_irq+0xa8/0x140)
[<c0066f38>] (request_threaded_irq+0xa8/0x140) from [<c019e784>] (gpio_setup_irq+0x14c/0x260)
[<c019e784>] (gpio_setup_irq+0x14c/0x260) from [<c019ec1c>] (gpio_edge_store+0x90/0xac)
[<c019ec1c>] (gpio_edge_store+0x90/0xac) from [<c01be8fc>] (dev_attr_store+0x1c/0x28)
[<c01be8fc>] (dev_attr_store+0x1c/0x28) from [<c00e8b2c>] (sysfs_write_file+0x168/0x19c)
[<c00e8b2c>] (sysfs_write_file+0x168/0x19c) from [<c009a3d4>] (vfs_write+0xa4/0x160)
[<c009a3d4>] (vfs_write+0xa4/0x160) from [<c009a6a4>] (sys_write+0x3c/0x7c)
[<c009a6a4>] (sys_write+0x3c/0x7c) from [<c0020e40>] (ret_fast_syscall+0x0/0x2c)
---[ end trace ff56c09a294dbe68 ]---
I am using kernel version 2.6.34.14 with linux-2.6.34-ts7200_matt-6.tar.gz patch (hovewer it doesn't seem contain patches for gpio.c or gpiolib.c)
cross version:
binutils-2.23.1
gcc-4.7.3
glibc-2.17
Also i crawled through change history of gpio.c and gpiolib.c and didn't find anything that can be related to this issue.
Can someone give me and advice regarding this issue? I want interrupts on all ports (A,B,F) not just A.
There are a lot of question on this issue (and ARM irq OR interrupt). Please look at them.
We can see many changes by looking at more recent Linux 3.0 gpio.c change logs versus the 2.6.34 logs and the current version. You should be able to get the current Linux stable tree and extract these patches and back port them to your kernel. For instance, there is a bug where port C and F are swapped; I don't know if this is in your ts7200_matt variant.
Some important change sets to look at,
arm: Fold irq_set_chip/irq_set_handler
arm: Cleanup the irq namespace
arm: ep93xx: Use proper irq accessor functions
arm: ep93xx: Add basic interrupt info
ARM: ep93xx: irq_data conversion.
ARM: 5954/1: ep93xx: move gpio interrupt support to gpio.c
[ARM] 5243/1: ep93xx: bugfix, GPIO ports C and F are swapped
You may have #6, but it is worth looking at as it is basically the interrupt implementation for your controller. After about linux-3.0, your SOC's GPIO controller was moved to drivers/gpio/gpio-ep93xx.c. You may wish to look at these changes, but none seem to be related to your issue. You should be aware of structural changes to Linux. Ie, overall changes to interrupt handling and/or the generic GPIO infrastructure. A good guess is that Thomas Gleixner or Russell King will make these changes.
The patches can be extracted from a particular Linux stable tree with git format-patch b685004.. b0ec5cf1 gpio.c. This will create several patch files. Move them to your tree and apply with either git am or patch -p1. You may have to massage these files to get them to apply cleanly to your tree; if you take them all, even though they are not related to interrupt handling, you will have better luck doing this automatically. You can also look at the patch set and try to manually patch the file with a text editor.
None of this addresses your specific questions. However, it gives a path to merge changes from the latest Linux versions. Also, the previous stack overflow questions give details on the structure of the GPIO interrupt handling. Coupled with your data sheet, the Linux GPIO document, and the given change sets, you should be able to fix your own problem. Otherwise, you need someone familiar with the EP93xx and the question is fairly localized.
Note: The stack trace indicates that a GPIO is being used without a corresponding gpio_request()
. This is either a bug in the machine file or in the EP93xx GPIO interrupt handling code.
I had the same warning:
------------[ cut here ]------------
WARNING: at drivers/gpio/gpiolib.c:103 gpio_ensure_requested
From my research we have to call gpio_request_one / gpio_request, before gpio_direction_input.
It fixed the problem for me.
http://www.avrfreaks.net/index.php?name=PNphpBB2&file=viewtopic&t=99789
http://e2e.ti.com/support/embedded/linux/f/354/p/119946/427889.aspx
It appears that some time between these two kernels a lot of data structures were changed, and it breaks my driver in several places.
First, in 2.6.21 the struct uart_port had a field "struct uart_info *info" which I relied on in several places. I test several places to make sure it is non-null, and if non-null I additionally test if it's sub-field (struct tty_struct *tty) is non-null, and I uses these to check if flow control is enabled and if we are stopped transmitting.
In 2.6.36 the info back pointer has been removed and I'm not sure how to get at it, or if the semantics of what I am trying to do are even valid any more, as the only serial driver that even uses this appears to have ifdef'ed out the code dealing with it, and additionally holds all this data in its own structures (how does that work to even correctly maintain state with the kernel)???
Additionally, save_and_cli() and restore_flags() are missing. I see new functions local_irq_save() and local_irq_restore(), can I just switch to using those, or are there any gotchas?
Finally, __ioremap is missing. Looks like maybe ioremap_noncache is the replacement, but again I'm not sure if there are any semantic differences or gotchas. I would assume I don't want ioremap() since I am talking directly to hardware, but some other drivers appear to do so and I don't know why that would work.
Looking at how an in-tree driver that uses the same functionality has changed between the two versions is usually the best way to go. For example, the ioc4_serial driver uses the info member of struct uart_port in kernel 2.6.21, but has switched to using the struct uart_state *state member by kernel 2.6.36.
That driver obtains the tty_struct with:
state = the_port->state;
tty = state->port.tty;