driver core fixes for 2.6.34-git
Subsystems (3)
PATCH 1/1 driver core fixes for 2.6.34-git
Here are 3 patches for your 2.6.34-git tree.
Two documentation updates, and one fix for the sysfs attribute warning that people have reported.
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/gregkh/driver-core-2.6.git/
All of these patches have been in the linux-next and mm trees.
The patches will be sent as a follow-on to this message to lkml for people to see.
thanks,
greg k-h
------------
Documentation/HOWTO | 2 +- Documentation/stable_kernel_rules.txt | 9 ++++----- drivers/hwmon/asus_atk0110.c | 4 ++++ 3 files changed, 9 insertions(+), 6 deletions(-)
---------------
Jiri Kosina (1):
sysfs: use sysfs_attr_init in ASUS atk0110 driver
Randy Dunlap (1):
Documentation/HOWTO: update git home URL
Stefan Richter (1):
Documentation: -stable rules: upstream commit ID requirement reworded
PATCH 1/3 Documentation: -stable rules: upstream commit ID requirement reworded
From: Stefan Richter <[email protected]>
It is a hard requirement to include the upstream commit ID in the changelog of a -stable submission, not just a courtesy to the stable team. This concerns only mail submission though, which is no longer the only way into stable. (Also, fix a double "the".)
--- Documentation/stable_kernel_rules.txt | 9 ++++----- 1 files changed, 4 insertions(+), 5 deletions(-)
Documentation/stable_kernel_rules.txt +4 -5
@@ -18,16 +18,15 @@ Rules on what kind of patches are accepted, and which ones are not, into the - It cannot contain any "trivial" fixes in it (spelling changes, whitespace cleanups, etc). - It must follow the Documentation/SubmittingPatches rules. - - It or an equivalent fix must already exist in Linus' tree. Quote the - respective commit ID in Linus' tree in your patch submission to -stable. + - It or an equivalent fix must already exist in Linus' tree (upstream). Procedure for submitting patches to the -stable tree: - Send the patch, after verifying that it follows the above rules, to - [email protected]. - - To have the patch automatically included in the stable tree, add the - the tag + [email protected]. You must note the upstream commit ID in the changelog + of your submission. + - To have the patch automatically included in the stable tree, add the tag Cc: [email protected] in the sign-off area. Once the patch is merged it will be applied to the stable tree without anything else needing to be done by the author
Signature · 1 line
1.7.0.4
PATCH 2/3 Documentation/HOWTO: update git home URL
In reply to Greg KHFrom: Randy Dunlap <[email protected]>
Update git home page info.
--- Documentation/HOWTO | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
Documentation/HOWTO +1 -1
@@ -234,7 +234,7 @@ process is as follows: Linus, usually the patches that have already been included in the -next kernel for a few weeks. The preferred way to submit big changes is using git (the kernel's source management tool, more information - can be found at http://git.or.cz/) but plain patches are also just + can be found at http://git-scm.com/) but plain patches are also just fine. - After two weeks a -rc1 kernel is released it is now possible to push only patches that do not include new features that could affect the
Signature · 1 line
1.7.0.4
PATCH 3/3 sysfs: use sysfs_attr_init in ASUS atk0110 driver
In reply to Greg KHFrom: Jiri Kosina <[email protected]>
Annotate dynamic sysfs attribute in atk_create_files(). This gets rid of the following lockdep warning:
BUG: key ffff8800379ca670 not in .data! ------------[ cut here ]------------ WARNING: at kernel/lockdep.c:2696 lockdep_init_map+0xd2/0x108() Hardware name: P5K PRO Modules linked in: asus_atk0110(+) pata_acpi firewire_ohci ata_generic dm_multipath firewire_core crc_itu_t pata_marvell floppy Pid: 599, comm: modprobe Not tainted 2.6.34-rc4 #27 Call Trace: [<ffffffff8104cdb0>] warn_slowpath_common+0x7c/0x94 [<ffffffff8104cddc>] warn_slowpath_null+0x14/0x16 [<ffffffff81077c4d>] lockdep_init_map+0xd2/0x108 [<ffffffff81165873>] sysfs_add_file_mode+0x66/0xa2 [<ffffffff811658c0>] sysfs_add_file+0x11/0x13 [<ffffffff8116594b>] sysfs_create_file+0x2a/0x2c [<ffffffff812c1f9c>] device_create_file+0x19/0x1b [<ffffffffa005b4fd>] atk_add+0x58b/0x72e [asus_atk0110] [<ffffffff812572a1>] acpi_device_probe+0x50/0x122 [<ffffffff812c46af>] driver_probe_device+0xa2/0x127 [<ffffffff812c4783>] __driver_attach+0x4f/0x6b [<ffffffff812c4734>] ? __driver_attach+0x0/0x6b [<ffffffff812c3c94>] bus_for_each_dev+0x59/0x8e [<ffffffff812c4519>] driver_attach+0x1e/0x20 [<ffffffff812c4152>] bus_add_driver+0xb9/0x207 [<ffffffff812c4a5f>] driver_register+0x9d/0x10e [<ffffffffa005f000>] ? atk0110_init+0x0/0x31 [asus_atk0110] [<ffffffff81257c7c>] acpi_bus_register_driver+0x43/0x45 [<ffffffffa005f015>] atk0110_init+0x15/0x31 [asus_atk0110] [<ffffffffa005f000>] ? atk0110_init+0x0/0x31 [asus_atk0110] [<ffffffff81002069>] do_one_initcall+0x5e/0x15e [<ffffffff81085075>] sys_init_module+0xd8/0x239 [<ffffffff81009cf2>] system_call_fastpath+0x16/0x1b ---[ end trace 4d0c84007055efb9 ]--- BUG: key ffff8800379ca638 not in .data! BUG: key ffff8800379ca6a8 not in .data! BUG: key ffff8800379ca6e0 not in .data! BUG: key ffff880036f73670 not in .data! BUG: key ffff880036f73638 not in .data! BUG: key ffff880036f736a8 not in .data! BUG: key ffff880036f736e0 not in .data! BUG: key ffff880036f76c70 not in .data! BUG: key ffff880036f76c38 not in .data! BUG: key ffff880036f76ca8 not in .data! BUG: key ffff880036f76ce0 not in .data! BUG: key ffff8800368e7670 not in .data! BUG: key ffff8800368e7638 not in .data! BUG: key ffff8800368e76a8 not in .data! BUG: key ffff8800368e76e0 not in .data! BUG: key ffff880036ef7670 not in .data! BUG: key ffff880036ef7638 not in .data! BUG: key ffff880036ef76a8 not in .data! BUG: key ffff880036ef76e0 not in .data! BUG: key ffff8800373ccc70 not in .data! BUG: key ffff8800373ccc38 not in .data! BUG: key ffff8800373ccca8 not in .data! BUG: key ffff8800373ccce0 not in .data! BUG: key ffff880037a60870 not in .data! BUG: key ffff880037a60838 not in .data! BUG: key ffff880037a608a8 not in .data! BUG: key ffff880037a608e0 not in .data! BUG: key ffff880037355070 not in .data! BUG: key ffff880037355038 not in .data! BUG: key ffff8800373550a8 not in .data! BUG: key ffff8800373550e0 not in .data! BUG: key ffff8800378c2670 not in .data! BUG: key ffff8800378c2638 not in .data! BUG: key ffff8800378c26a8 not in .data! BUG: key ffff8800378c26e0 not in .data! BUG: key ffff880036ef7e70 not in .data! BUG: key ffff880036ef7e38 not in .data! BUG: key ffff880036ef7ea8 not in .data! BUG: key ffff880036ef7ee0 not in .data!
--- drivers/hwmon/asus_atk0110.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-)
drivers/hwmon/asus_atk0110.c +4 -0
@@ -1169,15 +1169,19 @@ static int atk_create_files(struct atk_data *data)int err;list_for_each_entry (s, &data->sensor_list, list) { +sysfs_attr_init (&s->input_attr.attr); err =device_create_file (data->hwmon_dev, &s->input_attr);if (err)return err; +sysfs_attr_init (&s->label_attr.attr); err =device_create_file (data->hwmon_dev, &s->label_attr);if (err)return err; +sysfs_attr_init (&s->limit1_attr.attr); err =device_create_file (data->hwmon_dev, &s->limit1_attr);if (err)return err; +sysfs_attr_init (&s->limit2_attr.attr); err =device_create_file (data->hwmon_dev, &s->limit2_attr);if (err)return err;
Signature · 1 line
1.7.0.4
Re: [PATCH 1/3] Documentation: -stable rules: upstream commit ID requirement reworded
In reply to Greg Kroah-HartmanQuoted 6 lines · Greg Kroah-Hartman
From: Stefan Richter <[email protected]>
It is a hard requirement to include the upstream commit ID in the changelog of a -stable submission, not just a courtesy to the stable team. This concerns only mail submission though, which is no longer the only way into stable. (Also, fix a double "the".)
I find the upstream commit ID to be highly useful when looking at commits in the stable tree. So it would be nice IMHO if we could enforce this requirement regardless of whether the submission path is via e-mail or git.
- Ted
Re: [PATCH 1/3] Documentation: -stable rules: upstream commit ID requirement reworded
Quoted 8 lines · [email protected] wrote:
Quoted 6 lines · Greg Kroah-Hartman
From: Stefan Richter <[email protected]>
It is a hard requirement to include the upstream commit ID in the changelog of a -stable submission, not just a courtesy to the stable team. This concerns only mail submission though, which is no longer the only way into stable. (Also, fix a double "the".)
Quoted 4 lines
I find the upstream commit ID to be highly useful when looking at commits in the stable tree. So it would be nice IMHO if we could enforce this requirement regardless of whether the submission path is via e-mail or git.
In the semi-automatic submission path via git --- i.e. of commits which feature a Cc: [email protected] line in the changelog when they show up in Linus' tree --- the upstream commit ID is not known to the submitter at the time of submission. Apparently Greg's scripts modify the changelogs respectively when he cherry-picks from linux-2.6.git, so the requirement is also always fulfilled with this alternative submission path.
E.g. as in http://lkml.org/lkml/2010/4/22/294 which was apparently submitted the semi-automatic way, via
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=44fef22416886a04d432043f741a6faf2c6ffefd
Signature · 3 lines
Stefan Richter -=====-==-=- -=-- ==--- http://arcgraph.de/sr/
Re: [PATCH 1/3] Documentation: -stable rules: upstream commit ID requirement reworded
Quoted 5 lines · Stefan Richter
Quoted 4 lines · [email protected] wrote:
I find the upstream commit ID to be highly useful when looking at commits in the stable tree. So it would be nice IMHO if we could enforce this requirement regardless of whether the submission path is via e-mail or git.
...
Quoted 3 lines
Apparently Greg's scripts modify the
changelogs respectively when he cherry-picks from linux-2.6.git, so the requirement is also always fulfilled with this alternative submission path.
Or do you mean submission directly from a developer's git tree to stable via git pull by Greg? Is this been done? If yes, I suppose this comes only from people who know very well how a stable patch is meant to look like. Nevertheless I could send another adjustment for Documentation/stable_kernel_rules.txt if this is another actual submission path.
Signature · 3 lines
Stefan Richter -=====-==-=- -=-- ==--- http://arcgraph.de/sr/
Re: [PATCH 1/3] Documentation: -stable rules: upstream commit ID requirement reworded
Quoted 11 lines · Stefan Richter
Quoted 5 lines · Stefan Richter
Quoted 4 lines · [email protected] wrote:
I find the upstream commit ID to be highly useful when looking at commits in the stable tree. So it would be nice IMHO if we could enforce this requirement regardless of whether the submission path is via e-mail or git.
...
Quoted 3 lines
Apparently Greg's scripts modify the
changelogs respectively when he cherry-picks from linux-2.6.git, so the requirement is also always fulfilled with this alternative submission path.
Quoted 6 lines
Or do you mean submission directly from a developer's git tree to stable via git pull by Greg? Is this been done? If yes, I suppose this comes only from people who know very well how a stable patch is meant to look like. Nevertheless I could send another adjustment for
Documentation/stable_kernel_rules.txtif this is another actual submission path.
No, it's not a real submission patch, and yes, I always require a git commit id in the patch. If I don't have it, it is explained in the patch why it is not in Linus's tree.
Don't worry, I think the current wording is fine.
thanks,
greg k-h
Re: [PATCH 1/3] Documentation: -stable rules: upstream commit ID requirement reworded
Quoted 10 lines · Greg KH
Quoted 4 lines
Quoted 4 lines
Apparently Greg's scripts modify the
changelogs respectively when he cherry-picks from linux-2.6.git, so the requirement is also always fulfilled with this alternative submission path.No, it's not a real submission patch, and yes, I always require a git commit id in the patch. If I don't have it, it is explained in the patch why it is not in Linus's tree.
Don't worry, I think the current wording is fine.
Thanks for clarifying, I didn't realize the wording was referring to the cc: stable@ path, where the stable team adds the commit id reference themselves once it's available.
-- Ted