<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/include/linux, branch v2.6.25.14</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>cpufreq acpi: only call _PPC after cpufreq ACPI init funcs got called already</title>
<updated>2008-08-01T18:50:58+00:00</updated>
<author>
<name>Thomas Renninger</name>
<email>trenn@suse.de</email>
</author>
<published>2008-07-30T18:20:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=72ca61bf9daad9ad1ac867e6e041dc21a00fe8c6'/>
<id>72ca61bf9daad9ad1ac867e6e041dc21a00fe8c6</id>
<content type='text'>
commit a1531acd43310a7e4571d52e8846640667f4c74b upstream

Ingo Molnar provided a fix to not call _PPC at processor driver
initialization time in "[PATCH] ACPI: fix cpufreq regression" (git
commit e4233dec749a3519069d9390561b5636a75c7579)

But it can still happen that _PPC is called at processor driver
initialization time.

This patch should make sure that this is not possible anymore.

Signed-off-by: Thomas Renninger &lt;trenn@suse.de&gt;
Cc: Andi Kleen &lt;andi@firstfloor.org&gt;
Cc: Len Brown &lt;lenb@kernel.org&gt;
Cc: Dave Jones &lt;davej@codemonkey.org.uk&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: Venkatesh Pallipadi &lt;venkatesh.pallipadi@intel.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit a1531acd43310a7e4571d52e8846640667f4c74b upstream

Ingo Molnar provided a fix to not call _PPC at processor driver
initialization time in "[PATCH] ACPI: fix cpufreq regression" (git
commit e4233dec749a3519069d9390561b5636a75c7579)

But it can still happen that _PPC is called at processor driver
initialization time.

This patch should make sure that this is not possible anymore.

Signed-off-by: Thomas Renninger &lt;trenn@suse.de&gt;
Cc: Andi Kleen &lt;andi@firstfloor.org&gt;
Cc: Len Brown &lt;lenb@kernel.org&gt;
Cc: Dave Jones &lt;davej@codemonkey.org.uk&gt;
Cc: Ingo Molnar &lt;mingo@elte.hu&gt;
Cc: Venkatesh Pallipadi &lt;venkatesh.pallipadi@intel.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>udplite: Protection against coverage value wrap-around</title>
<updated>2008-07-28T17:58:18+00:00</updated>
<author>
<name>Gerrit Renker</name>
<email>gerrit@erg.abdn.ac.uk</email>
</author>
<published>2008-07-24T07:11:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5564d385e9b0cddc7c831af9f90a2f53aa472953'/>
<id>5564d385e9b0cddc7c831af9f90a2f53aa472953</id>
<content type='text'>
[ Upstream commit 47112e25da41d9059626033986dc3353e101f815 ]

This patch clamps the cscov setsockopt values to a maximum of 0xFFFF.

Setsockopt values greater than 0xffff can cause an unwanted
wrap-around.  Further, IPv6 jumbograms are not supported (RFC 3838,
3.5), so that values greater than 0xffff are not even useful.

Further changes: fixed a typo in the documentation.

[ Add USHORT_MAX from upstream to linux/kernel.h -DaveM ]

Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit 47112e25da41d9059626033986dc3353e101f815 ]

This patch clamps the cscov setsockopt values to a maximum of 0xFFFF.

Setsockopt values greater than 0xffff can cause an unwanted
wrap-around.  Further, IPv6 jumbograms are not supported (RFC 3838,
3.5), so that values greater than 0xffff are not even useful.

Further changes: fixed a typo in the documentation.

[ Add USHORT_MAX from upstream to linux/kernel.h -DaveM ]

Signed-off-by: Gerrit Renker &lt;gerrit@erg.abdn.ac.uk&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>ipv6: __KERNEL__ ifdef struct ipv6_devconf</title>
<updated>2008-07-28T17:58:16+00:00</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2008-07-24T06:49:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=debf2f2593b0244eb81a4b66beef956a73b4e84f'/>
<id>debf2f2593b0244eb81a4b66beef956a73b4e84f</id>
<content type='text'>
[ Upstream commit ebb36a978131810c98e7198b1187090c697cf99f ]

Based upon a report by Olaf Hering.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
[ Upstream commit ebb36a978131810c98e7198b1187090c697cf99f ]

Based upon a report by Olaf Hering.

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>block: Properly notify block layer of sync writes</title>
<updated>2008-07-24T16:14:03+00:00</updated>
<author>
<name>Jens Axboe</name>
<email>jens.axboe@oracle.com</email>
</author>
<published>2008-07-01T07:07:34+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=58a60dff37be85dbb58371f360958a82c0c4d8d0'/>
<id>58a60dff37be85dbb58371f360958a82c0c4d8d0</id>
<content type='text'>
commit 18ce3751ccd488c78d3827e9f6bf54e6322676fb upstream

fsync_buffers_list() and sync_dirty_buffer() both issue async writes and
then immediately wait on them. Conceptually, that makes them sync writes
and we should treat them as such so that the IO schedulers can handle
them appropriately.

This patch fixes a write starvation issue that Lin Ming reported, where
xx is stuck for more than 2 minutes because of a large number of
synchronous IO in the system:

INFO: task kjournald:20558 blocked for more than 120 seconds.
"echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
kjournald     D ffff810010820978  6712 20558      2
ffff81022ddb1d10 0000000000000046 ffff81022e7baa10 ffffffff803ba6f2
ffff81022ecd0000 ffff8101e6dc9160 ffff81022ecd0348 000000008048b6cb
0000000000000086 ffff81022c4e8d30 0000000000000000 ffffffff80247537
Call Trace:
[&lt;ffffffff803ba6f2&gt;] kobject_get+0x12/0x17
[&lt;ffffffff80247537&gt;] getnstimeofday+0x2f/0x83
[&lt;ffffffff8029c1ac&gt;] sync_buffer+0x0/0x3f
[&lt;ffffffff8066d195&gt;] io_schedule+0x5d/0x9f
[&lt;ffffffff8029c1e7&gt;] sync_buffer+0x3b/0x3f
[&lt;ffffffff8066d3f0&gt;] __wait_on_bit+0x40/0x6f
[&lt;ffffffff8029c1ac&gt;] sync_buffer+0x0/0x3f
[&lt;ffffffff8066d48b&gt;] out_of_line_wait_on_bit+0x6c/0x78
[&lt;ffffffff80243909&gt;] wake_bit_function+0x0/0x23
[&lt;ffffffff8029e3ad&gt;] sync_dirty_buffer+0x98/0xcb
[&lt;ffffffff8030056b&gt;] journal_commit_transaction+0x97d/0xcb6
[&lt;ffffffff8023a676&gt;] lock_timer_base+0x26/0x4b
[&lt;ffffffff8030300a&gt;] kjournald+0xc1/0x1fb
[&lt;ffffffff802438db&gt;] autoremove_wake_function+0x0/0x2e
[&lt;ffffffff80302f49&gt;] kjournald+0x0/0x1fb
[&lt;ffffffff802437bb&gt;] kthread+0x47/0x74
[&lt;ffffffff8022de51&gt;] schedule_tail+0x28/0x5d
[&lt;ffffffff8020cac8&gt;] child_rip+0xa/0x12
[&lt;ffffffff80243774&gt;] kthread+0x0/0x74
[&lt;ffffffff8020cabe&gt;] child_rip+0x0/0x12

Lin Ming confirms that this patch fixes the issue. I've run tests with
it for the past week and no ill effects have been observed, so I'm
proposing it for inclusion into 2.6.26.

Signed-off-by: Jens Axboe &lt;jens.axboe@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 18ce3751ccd488c78d3827e9f6bf54e6322676fb upstream

fsync_buffers_list() and sync_dirty_buffer() both issue async writes and
then immediately wait on them. Conceptually, that makes them sync writes
and we should treat them as such so that the IO schedulers can handle
them appropriately.

This patch fixes a write starvation issue that Lin Ming reported, where
xx is stuck for more than 2 minutes because of a large number of
synchronous IO in the system:

INFO: task kjournald:20558 blocked for more than 120 seconds.
"echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs" disables this
message.
kjournald     D ffff810010820978  6712 20558      2
ffff81022ddb1d10 0000000000000046 ffff81022e7baa10 ffffffff803ba6f2
ffff81022ecd0000 ffff8101e6dc9160 ffff81022ecd0348 000000008048b6cb
0000000000000086 ffff81022c4e8d30 0000000000000000 ffffffff80247537
Call Trace:
[&lt;ffffffff803ba6f2&gt;] kobject_get+0x12/0x17
[&lt;ffffffff80247537&gt;] getnstimeofday+0x2f/0x83
[&lt;ffffffff8029c1ac&gt;] sync_buffer+0x0/0x3f
[&lt;ffffffff8066d195&gt;] io_schedule+0x5d/0x9f
[&lt;ffffffff8029c1e7&gt;] sync_buffer+0x3b/0x3f
[&lt;ffffffff8066d3f0&gt;] __wait_on_bit+0x40/0x6f
[&lt;ffffffff8029c1ac&gt;] sync_buffer+0x0/0x3f
[&lt;ffffffff8066d48b&gt;] out_of_line_wait_on_bit+0x6c/0x78
[&lt;ffffffff80243909&gt;] wake_bit_function+0x0/0x23
[&lt;ffffffff8029e3ad&gt;] sync_dirty_buffer+0x98/0xcb
[&lt;ffffffff8030056b&gt;] journal_commit_transaction+0x97d/0xcb6
[&lt;ffffffff8023a676&gt;] lock_timer_base+0x26/0x4b
[&lt;ffffffff8030300a&gt;] kjournald+0xc1/0x1fb
[&lt;ffffffff802438db&gt;] autoremove_wake_function+0x0/0x2e
[&lt;ffffffff80302f49&gt;] kjournald+0x0/0x1fb
[&lt;ffffffff802437bb&gt;] kthread+0x47/0x74
[&lt;ffffffff8022de51&gt;] schedule_tail+0x28/0x5d
[&lt;ffffffff8020cac8&gt;] child_rip+0xa/0x12
[&lt;ffffffff80243774&gt;] kthread+0x0/0x74
[&lt;ffffffff8020cabe&gt;] child_rip+0x0/0x12

Lin Ming confirms that this patch fixes the issue. I've run tests with
it for the past week and no ill effects have been observed, so I'm
proposing it for inclusion into 2.6.26.

Signed-off-by: Jens Axboe &lt;jens.axboe@oracle.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>Add return value to reserve_bootmem_node()</title>
<updated>2008-06-24T21:08:29+00:00</updated>
<author>
<name>Bernhard Walle</name>
<email>bwalle@suse.de</email>
</author>
<published>2008-06-21T17:01:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8c3a10753bfb7ba66b024398cc9bad9eea82a99f'/>
<id>8c3a10753bfb7ba66b024398cc9bad9eea82a99f</id>
<content type='text'>
commit 71c2742f5e6348d76ee62085cf0a13e5eff0f00e upstream

This patch changes the function reserve_bootmem_node() from void to int,
returning -ENOMEM if the allocation fails.

This fixes a build problem on x86 with CONFIG_KEXEC=y and
CONFIG_NEED_MULTIPLE_NODES=y

Signed-off-by: Bernhard Walle &lt;bwalle@suse.de&gt;
Reported-by: Adrian Bunk &lt;bunk@kernel.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 71c2742f5e6348d76ee62085cf0a13e5eff0f00e upstream

This patch changes the function reserve_bootmem_node() from void to int,
returning -ENOMEM if the allocation fails.

This fixes a build problem on x86 with CONFIG_KEXEC=y and
CONFIG_NEED_MULTIPLE_NODES=y

Signed-off-by: Bernhard Walle &lt;bwalle@suse.de&gt;
Reported-by: Adrian Bunk &lt;bunk@kernel.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>cciss: add new hardware support</title>
<updated>2008-06-16T20:20:01+00:00</updated>
<author>
<name>Mike Miller</name>
<email>mike.miller@hp.com</email>
</author>
<published>2008-06-13T02:40:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=5f500e6d8fdce3de036859ee45c92ce8dd5b5b04'/>
<id>5f500e6d8fdce3de036859ee45c92ce8dd5b5b04</id>
<content type='text'>
commit 24aac480e76c6f5d1391ac05c5e9c0eb9b0cd302 upstream
Date: Thu, 12 Jun 2008 15:21:34 -0700
Subject: cciss: add new hardware support

Add support for the next generation of HP Smart Array SAS/SATA
controllers.  Shipping date is late Fall 2008.

Bump the driver version to 3.6.20 to reflect the new hardware support from
patch 1 of this set.

Signed-off-by: Mike Miller &lt;mike.miller@hp.com&gt;
Cc: Jens Axboe &lt;jens.axboe@oracle.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit 24aac480e76c6f5d1391ac05c5e9c0eb9b0cd302 upstream
Date: Thu, 12 Jun 2008 15:21:34 -0700
Subject: cciss: add new hardware support

Add support for the next generation of HP Smart Array SAS/SATA
controllers.  Shipping date is late Fall 2008.

Bump the driver version to 3.6.20 to reflect the new hardware support from
patch 1 of this set.

Signed-off-by: Mike Miller &lt;mike.miller@hp.com&gt;
Cc: Jens Axboe &lt;jens.axboe@oracle.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>capabilities: remain source compatible with 32-bit raw legacy capability support.</title>
<updated>2008-06-09T18:27:06+00:00</updated>
<author>
<name>Andrew G. Morgan</name>
<email>morgan@kernel.org</email>
</author>
<published>2008-06-06T18:44:08+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=52491a6bd397c868a0e8b0282548e8527f26e705'/>
<id>52491a6bd397c868a0e8b0282548e8527f26e705</id>
<content type='text'>
upstream commit: ca05a99a54db1db5bca72eccb5866d2a86f8517f

Source code out there hard-codes a notion of what the
_LINUX_CAPABILITY_VERSION #define means in terms of the semantics of the
raw capability system calls capget() and capset().  Its unfortunate, but
true.

Since the confusing header file has been in a released kernel, there is
software that is erroneously using 64-bit capabilities with the semantics
of 32-bit compatibilities.  These recently compiled programs may suffer
corruption of their memory when sys_getcap() overwrites more memory than
they are coded to expect, and the raising of added capabilities when using
sys_capset().

As such, this patch does a number of things to clean up the situation
for all. It

  1. forces the _LINUX_CAPABILITY_VERSION define to always retain its
     legacy value.

  2. adopts a new #define strategy for the kernel's internal
     implementation of the preferred magic.

  3. deprecates v2 capability magic in favor of a new (v3) magic
     number. The functionality of v3 is entirely equivalent to v2,
     the only difference being that the v2 magic causes the kernel
     to log a "deprecated" warning so the admin can find applications
     that may be using v2 inappropriately.

[User space code continues to be encouraged to use the libcap API which
protects the application from details like this.  libcap-2.10 is the first
to support v3 capabilities.]

Fixes issue reported in https://bugzilla.redhat.com/show_bug.cgi?id=447518.
Thanks to Bojan Smojver for the report.

[akpm@linux-foundation.org: s/depreciate/deprecate/g]
[akpm@linux-foundation.org: be robust about put_user size]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Andrew G. Morgan &lt;morgan@kernel.org&gt;
Cc: Serge E. Hallyn &lt;serue@us.ibm.com&gt;
Cc: Bojan Smojver &lt;bojan@rexursive.com&gt;
Cc: stable@kernel.org
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
upstream commit: ca05a99a54db1db5bca72eccb5866d2a86f8517f

Source code out there hard-codes a notion of what the
_LINUX_CAPABILITY_VERSION #define means in terms of the semantics of the
raw capability system calls capget() and capset().  Its unfortunate, but
true.

Since the confusing header file has been in a released kernel, there is
software that is erroneously using 64-bit capabilities with the semantics
of 32-bit compatibilities.  These recently compiled programs may suffer
corruption of their memory when sys_getcap() overwrites more memory than
they are coded to expect, and the raising of added capabilities when using
sys_capset().

As such, this patch does a number of things to clean up the situation
for all. It

  1. forces the _LINUX_CAPABILITY_VERSION define to always retain its
     legacy value.

  2. adopts a new #define strategy for the kernel's internal
     implementation of the preferred magic.

  3. deprecates v2 capability magic in favor of a new (v3) magic
     number. The functionality of v3 is entirely equivalent to v2,
     the only difference being that the v2 magic causes the kernel
     to log a "deprecated" warning so the admin can find applications
     that may be using v2 inappropriately.

[User space code continues to be encouraged to use the libcap API which
protects the application from details like this.  libcap-2.10 is the first
to support v3 capabilities.]

Fixes issue reported in https://bugzilla.redhat.com/show_bug.cgi?id=447518.
Thanks to Bojan Smojver for the report.

[akpm@linux-foundation.org: s/depreciate/deprecate/g]
[akpm@linux-foundation.org: be robust about put_user size]
[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: Andrew G. Morgan &lt;morgan@kernel.org&gt;
Cc: Serge E. Hallyn &lt;serue@us.ibm.com&gt;
Cc: Bojan Smojver &lt;bojan@rexursive.com&gt;
Cc: stable@kernel.org
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>HID: split Numlock emulation quirk from HID_QUIRK_APPLE_HAS_FN.</title>
<updated>2008-06-09T18:27:03+00:00</updated>
<author>
<name>Diego 'Flameeyes' Petteno</name>
<email>flameeyes@gmail.com</email>
</author>
<published>2008-05-28T10:49:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=582e7ebaa207504f23927bcf57ec56da42451846'/>
<id>582e7ebaa207504f23927bcf57ec56da42451846</id>
<content type='text'>
upstream commit: 6e7045990f35ef9250804b3fd85e855b8c2aaeb6.

[jkosina@suse.cz: Needed to fix apple aluminium keyboard regression]

Since 2.6.25 the HID_QUIRK_APPLE_HAS_FN quirk is enabled even for
non-laptop Apple keyboards of the Aluminium series. The USB version of
these don't need Numlock emulation, like the laptop (and Aluminium
Wireless) do, as they have a proper keypad.

This patch splits the Numlock emulation for Apple keyboards in a
different quirk flag, so that it can be enabled for all the keyboards
but the Aluminium USB ones.

If the Numlock emulation is enabled for Aluminium USB keyboards, the
JKL and UIO keys become the numeric pad, and the rest of the keyboard
is disabled, included the key used to disable Numlock.

Additionally, these keyboard should not have a Numlock at all, as the
Numlock key is instead replaced by the 'Clear' key as usual for Apple
USB keyboards.

Signed-off-by: Diego 'Flameeyes' Petteno &lt;flameeyes@gmail.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
upstream commit: 6e7045990f35ef9250804b3fd85e855b8c2aaeb6.

[jkosina@suse.cz: Needed to fix apple aluminium keyboard regression]

Since 2.6.25 the HID_QUIRK_APPLE_HAS_FN quirk is enabled even for
non-laptop Apple keyboards of the Aluminium series. The USB version of
these don't need Numlock emulation, like the laptop (and Aluminium
Wireless) do, as they have a proper keypad.

This patch splits the Numlock emulation for Apple keyboards in a
different quirk flag, so that it can be enabled for all the keyboards
but the Aluminium USB ones.

If the Numlock emulation is enabled for Aluminium USB keyboards, the
JKL and UIO keys become the numeric pad, and the rest of the keyboard
is disabled, included the key used to disable Numlock.

Additionally, these keyboard should not have a Numlock at all, as the
Numlock key is instead replaced by the 'Clear' key as usual for Apple
USB keyboards.

Signed-off-by: Diego 'Flameeyes' Petteno &lt;flameeyes@gmail.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;

</pre>
</div>
</content>
</entry>
<entry>
<title>types.h: don't expose struct ustat to userspace</title>
<updated>2008-06-09T18:27:01+00:00</updated>
<author>
<name>maximilian attems</name>
<email>max@stro.at</email>
</author>
<published>2008-05-24T17:40:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=bbd8ceb5e10bfcf6e235eba1a8b1c5d00f0c5137'/>
<id>bbd8ceb5e10bfcf6e235eba1a8b1c5d00f0c5137</id>
<content type='text'>
upstream commit: 6c7c6afbb8c0e60d32a563cae7c6889211e9d9d8

&lt;linux/types.h&gt; can't be used together with &lt;sys/ustat.h&gt; because they
both define struct ustat:

    $ cat test.c
    #include &lt;sys/ustat.h&gt;
    #include &lt;linux/types.h&gt;
    $ gcc -c test.c
    In file included from test.c:2:
    /usr/include/linux/types.h:165: error: redefinition of 'struct ustat'

has been reported a while ago to debian, but seems to have been
lost in cat fighting: http://bugs.debian.org/429064

Signed-off-by: maximilian attems &lt;max@stro.at&gt;
Cc: &lt;stable@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
upstream commit: 6c7c6afbb8c0e60d32a563cae7c6889211e9d9d8

&lt;linux/types.h&gt; can't be used together with &lt;sys/ustat.h&gt; because they
both define struct ustat:

    $ cat test.c
    #include &lt;sys/ustat.h&gt;
    #include &lt;linux/types.h&gt;
    $ gcc -c test.c
    In file included from test.c:2:
    /usr/include/linux/types.h:165: error: redefinition of 'struct ustat'

has been reported a while ago to debian, but seems to have been
lost in cat fighting: http://bugs.debian.org/429064

Signed-off-by: maximilian attems &lt;max@stro.at&gt;
Cc: &lt;stable@kernel.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Chris Wright &lt;chrisw@sous-sol.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>reiserfs: Unpack tails on quota files</title>
<updated>2008-05-10T04:40:46+00:00</updated>
<author>
<name>Jan Kara</name>
<email>jack@suse.cz</email>
</author>
<published>2008-05-05T11:42:12+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=d5d70ec0dca55f84071354c10fbb1162023fab0a'/>
<id>d5d70ec0dca55f84071354c10fbb1162023fab0a</id>
<content type='text'>
commit d5dee5c395062a55236318ac4eec1f4ebb9de6db upstream

Quota files cannot have tails because quota_write and quota_read functions do
not support them. So far when quota files did have tail, we just refused to
turn quotas on it. Sadly this check has been wrong and so there are now plenty
installations where quota files don't have NOTAIL flag set and so now after
fixing the check, they suddently fail to turn quotas on. Since it's easy to
unpack the tail from kernel, do this from reiserfs_quota_on() which solves the
problem and is generally nicer to users anyway.

Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Reported-by: &lt;urhausen@urifabi.net&gt;
Cc: Jeff Mahoney &lt;jeffm@suse.com&gt;
Cc: Chris Mason &lt;chris.mason@oracle.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
commit d5dee5c395062a55236318ac4eec1f4ebb9de6db upstream

Quota files cannot have tails because quota_write and quota_read functions do
not support them. So far when quota files did have tail, we just refused to
turn quotas on it. Sadly this check has been wrong and so there are now plenty
installations where quota files don't have NOTAIL flag set and so now after
fixing the check, they suddently fail to turn quotas on. Since it's easy to
unpack the tail from kernel, do this from reiserfs_quota_on() which solves the
problem and is generally nicer to users anyway.

Signed-off-by: Jan Kara &lt;jack@suse.cz&gt;
Reported-by: &lt;urhausen@urifabi.net&gt;
Cc: Jeff Mahoney &lt;jeffm@suse.com&gt;
Cc: Chris Mason &lt;chris.mason@oracle.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@suse.de&gt;

</pre>
</div>
</content>
</entry>
</feed>
