twitter: linux.kernel - 26 new messages in 16 topics

linux.kernel
http://groups.google.com/group/linux.kernel?hl=en

Today's topics:

* Staging:IIO: New ABI - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/67848cebe4d912bf?hl=en
* kgdb,clocksource: Prevent kernel hang in kernel debugger - 3 messages, 1
author
http://groups.google.com/group/linux.kernel/t/9346e7852bd8475c?hl=en
* gpio_keys and how PXA27x sets gpio_set_wake() (was Re: sharp c-3000 aka
spitz: fix warn_on introduced in 2.6.32-rc1) - 3 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/337ac495cfb9a0e2?hl=en
* Hyperthreading on Core i7s: To use or not to use? - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/185addf08bbc650e?hl=en
* OOM-Killer kills too much with 2.6.32.2 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/3f7afc452c078f22?hl=en
* twl4030 threaded_irq support - 2 messages, 2 authors
http://groups.google.com/group/linux.kernel/t/dad470d391a03375?hl=en
* regulator: support max8649 - 4 messages, 3 authors
http://groups.google.com/group/linux.kernel/t/0c21f2834789c0db?hl=en
* HID: ignore afatech 9016 - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/d852f364010c4872?hl=en
* ftrace: unify arch_syscall_addr() implementations - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f483b618b805fe50?hl=en
* Status of Andigilog asc7621 driver submitted by George Joseph on 2008-05-29 -
1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/90f1e5771291fdb0?hl=en
* tty: usb_serial_mos7720: Fix get_lsr_info - 2 messages, 1 author
http://groups.google.com/group/linux.kernel/t/6c6f1d1e04acc542?hl=en
* HDA Intel Audio hang on boot - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/a0ad5b25d979d11d?hl=en
* : Sparc build fix - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/5b7df0e906019615?hl=en
* regulator: Add WM8994 regulator support - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/41e093ee84ce44c6?hl=en
* regulator: trivial: fix typos in user-visible Kconfig text - 1 messages, 1
author
http://groups.google.com/group/linux.kernel/t/395977c92c91343c?hl=en
* : Sparc - 1 messages, 1 author
http://groups.google.com/group/linux.kernel/t/f43dd9e158765728?hl=en

==============================================================================
TOPIC: Staging:IIO: New ABI
http://groups.google.com/group/linux.kernel/t/67848cebe4d912bf?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 26 2010 2:30 am
From: "Hennerich, Michael"

>From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
>On Tue, Jan 26, 2010 at 09:55:45AM +0000, Hennerich, Michael wrote:
>>
>>
>> >From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
>> >
>> >On Fri, Jan 22, 2010 at 04:31:12PM -0800, Greg KH wrote:
>> >> On Fri, Jan 22, 2010 at 04:14:15PM -0800, Dmitry Torokhov wrote:
>> >> > On Fri, Jan 22, 2010 at 12:47:18PM -0800, Greg KH wrote:
>> >> > > On Wed, Jan 20, 2010 at 04:53:21PM +0000, Jonathan Cameron
wrote:
>> >> > > > I am not aware of these. Could you direct me to the current
api? Also note that these
>> >> > > > aren't the actual alarms, merely a means of enabling the
relevant event on the related
>> >> > > > event character device.
>> >> > >
>> >> > > Hm, I thought we had an accelerator interface somewhere...
>> >> > >
>> >> >
>> >> > Nope. And I am also interested in this since I am sittign on a
bunch of
>> >> > accelerometers, magnetometers, etc drivers that are trying to
plug into
>> >> > input sysbsystem and quite unsure what to do with them.
>> >> >
>> >> > It was OK whch HDAPS and friends when they were using input for
>> >> > secondary, toyish purposes, but these new drivers trying to use
input
>> >> > devnts as primary API and I am unsure if it is the best
solution.
>> >> > Accelerometer might be used as an input device but not always an
input
>> >> > device.
>> >>
>> >> Yeah, I see it using a joystick interface, which might be
acceptable for
>> >> "toy" devices like you say.
>> >>
>> >> But for "real" ones, we should do something else.
>> >>
>> >> Maybe, for devices that are going to be used by x.org, like the
"toy"
>> >> ones, we stick with the current input interface, but for others,
we use
>> >> a "real" interface, probably through hwmon, so that users can get
the
>> >> real data out in a consistant manner.
>> >>
>> >
>> >I'd rather have all of them use real interface and then have a
bridge
>> >to input module to enable toyish mode (unless the device in question
>> >is really truly an input device).
>> >
>> >--
>> >Dmitry
>>
>
>> I really don't see that hwmon provides facilities like input/evdev
>> does. Queuing of events with time stamping and multiple reader
>> support.
>
>I understand that using evdev might be very convenient but I still
>believe that input should be used for human interfaces, not for generic
>data acquisition. The idea is that userpsace consumers should be able
to
>query device's capabilities and based on those capabilities be able to
>classify and properly handle the device. Now it all breaks when we get
>random hardware using EV_ABS/ABS_* for delivering some datastream that
>has nothing to do with coordinates.

Acceleration in X,Y,Z translates pretty well in what joysticks deliver.

>
>> The adxl34x accelerometer driver for example is really
>> intended to be a input device. Send EV_KEY for x,y,z_TAP detections,
>> send EV_KEY for 3D orientation sensing, and EV_ABS for acceleration.
>> With very minor platform data customization you can use this device
>> for game controls or GUI interaction. A few examples include digital
>> picture frames, ebook readers, etc.
>>
>
>I see. However, can it be reasonably used for other purposes?

Well - it depends. Some applications for Accelerometers also include:
Personal navigation devices
Hard disk drive (HDD) protection
Safety

I agree with you that for these three mentioned above - Input is the
wrong place.

>If yes
>than maybe input is not the best primary subsystem the driver should
>belong to. Having said that I need to look at the driver again...
>
>--
>Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Tues, Jan 26 2010 3:10 am
From: Jonathan Cameron

On 01/26/10 10:25, Hennerich, Michael wrote:
>> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
>> On Tue, Jan 26, 2010 at 09:55:45AM +0000, Hennerich, Michael wrote:
>>>
>>>
>>>> From: Dmitry Torokhov [mailto:dmitry.torokhov@gmail.com]
>>>>
>>>> On Fri, Jan 22, 2010 at 04:31:12PM -0800, Greg KH wrote:
>>>>> On Fri, Jan 22, 2010 at 04:14:15PM -0800, Dmitry Torokhov wrote:
>>>>>> On Fri, Jan 22, 2010 at 12:47:18PM -0800, Greg KH wrote:
>>>>>>> On Wed, Jan 20, 2010 at 04:53:21PM +0000, Jonathan Cameron
> wrote:
>>>>>>>> I am not aware of these. Could you direct me to the current
> api? Also note that these
>>>>>>>> aren't the actual alarms, merely a means of enabling the
> relevant event on the related
>>>>>>>> event character device.
>>>>>>>
>>>>>>> Hm, I thought we had an accelerator interface somewhere...
>>>>>>>
>>>>>>
>>>>>> Nope. And I am also interested in this since I am sittign on a
> bunch of
>>>>>> accelerometers, magnetometers, etc drivers that are trying to
> plug into
>>>>>> input sysbsystem and quite unsure what to do with them.
>>>>>>
>>>>>> It was OK whch HDAPS and friends when they were using input for
>>>>>> secondary, toyish purposes, but these new drivers trying to use
> input
>>>>>> devnts as primary API and I am unsure if it is the best
> solution.
>>>>>> Accelerometer might be used as an input device but not always an
> input
>>>>>> device.
>>>>>
>>>>> Yeah, I see it using a joystick interface, which might be
> acceptable for
>>>>> "toy" devices like you say.
>>>>>
>>>>> But for "real" ones, we should do something else.
>>>>>
>>>>> Maybe, for devices that are going to be used by x.org, like the
> "toy"
>>>>> ones, we stick with the current input interface, but for others,
> we use
>>>>> a "real" interface, probably through hwmon, so that users can get
> the
>>>>> real data out in a consistant manner.
>>>>>
>>>>
>>>> I'd rather have all of them use real interface and then have a
> bridge
>>>> to input module to enable toyish mode (unless the device in question
>>>> is really truly an input device).
>>>>
>>>> --
>>>> Dmitry
>>>
>>
>>> I really don't see that hwmon provides facilities like input/evdev
>>> does. Queuing of events with time stamping and multiple reader
>>> support.
>>
>> I understand that using evdev might be very convenient but I still
>> believe that input should be used for human interfaces, not for generic
>> data acquisition. The idea is that userpsace consumers should be able
> to
>> query device's capabilities and based on those capabilities be able to
>> classify and properly handle the device. Now it all breaks when we get
>> random hardware using EV_ABS/ABS_* for delivering some datastream that
>> has nothing to do with coordinates.
>
> Acceleration in X,Y,Z translates pretty well in what joysticks deliver.
>
>>
>>> The adxl34x accelerometer driver for example is really
>>> intended to be a input device. Send EV_KEY for x,y,z_TAP detections,
>>> send EV_KEY for 3D orientation sensing, and EV_ABS for acceleration.
>>> With very minor platform data customization you can use this device
>>> for game controls or GUI interaction. A few examples include digital
>>> picture frames, ebook readers, etc.
>>>
>>
>> I see. However, can it be reasonably used for other purposes?
>
> Well - it depends. Some applications for Accelerometers also include:
> Personal navigation devices
> Hard disk drive (HDD) protection
> Safety
Just to add the apps I tend see these in (including that particular chip).
Sports performance monitoring (including live feedback and logging situations),
equine gait and I know at least one group who use these cheap 'input' sensors
for UAV navigation and packages instrumenting birds in flight (not sure exactly
which chip they are using right now but I know they were trying to obtain samples
of the adxl345 a while back.)

Obviously not all of the above are under Linux, but given the ease of development
and increasingly good low power and crucially small embedded boards it is
becoming more common.

Round here the smallest end is still bare metal code, but a lot of the initial
prototypes are Linux based.

Jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: kgdb,clocksource: Prevent kernel hang in kernel debugger
http://groups.google.com/group/linux.kernel/t/9346e7852bd8475c?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Jan 26 2010 2:40 am
From: Thomas Gleixner

On Tue, 26 Jan 2010, Dongdong Deng wrote:
> On Tue, Jan 26, 2010 at 4:50 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
> > On Tue, 26 Jan 2010, Martin Schwidefsky wrote:
> >> On Mon, 25 Jan 2010 22:26:39 -0600
> >> Jason Wessel <jason.wessel@windriver.com> wrote:
> >>
> >> > This is a regression fix against: 0f8e8ef7c204988246da5a42d576b7fa5277a8e4
> >> >
> >> > Spin locks were added to the clocksource_resume_watchdog() which cause
> >> > the kernel debugger to deadlock on an SMP system frequently.
> >> >
> >> > The kernel debugger can try for the lock, but if it fails it should
> >> > continue to touch the clocksource watchdog anyway, else it will trip
> >> > if the general kernel execution has been paused for too long.
> >> >
> >> > This introduces an possible race condition where the kernel debugger
> >> > might not process the list correctly if a clocksource is being added
> >> > or removed at the time of this call. This race is sufficiently rare vs
> >> > having the kernel debugger hang the kernel
> >> >
> >> > CC: Thomas Gleixner <tglx@linutronix.de>
> >> > CC: Martin Schwidefsky <schwidefsky@de.ibm.com>
> >> > CC: John Stultz <johnstul@us.ibm.com>
> >> > CC: Andrew Morton <akpm@linux-foundation.org>
> >> > CC: Magnus Damm <damm@igel.co.jp>
> >> > Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
> >>
> >> The first question I would ask is why does the kernel deadlock? Can we
> >> have a backchain of a deadlock please?
> >
> > The problem arises when the kernel is stopped inside the watchdog code
> > with watchdog_lock held. When kgdb restarts execution then it touches
> > the watchdog to avoid that TSC gets marked unstable.
> >
> >> Hmm, there are all kinds of races if the watchdog code gets interrupted
> >> by the kernel debugger. Wouldn't it be better to just disable the
> >> watchdog while the kernel debugger is active?
> >
> > No, we can keep it and in most cases it clocksource_touch_watchdog()
> > helps to keep TSC alive. A simple "if (!trylock) return;" should solve
> > the deadlock problem for kgdb without opening a can of worms.
>
> Is it possible that we reset the clocksource watchdog during in
> clocksource_watchdog() ?
>
> >From the code view, The action of reset clocksource watchdog is just
> set the CLOCK_SOURCE_WATCHDOG flag.
> thus if we reset it before using, I think the logic will be right.

No, it's not. It just brings back the old flag based logic which we
removed.

The correct way to solve this is a documented

if (!trylock())
return;

in clocksource_touch_watchdog(). And that's what I'm going to push
linuswards.

There is no sane way to reliably prevent TSC from becoming unstable
when kgdb stops the kernel inside the watchdog code. And I do not care
about that at all.

I'm not going to clutter code with crazy workarounds just because some
people believe that using a kernel debugger is a good idea. If people
insist on using kgdb then the possible "TSC becomes unstable" side
effect is the least of their problems.

Thanks,

tglx

== 2 of 3 ==
Date: Tues, Jan 26 2010 2:50 am
From: Thomas Gleixner

On Mon, 25 Jan 2010, Jason Wessel wrote:
> This is a regression fix against: 0f8e8ef7c204988246da5a42d576b7fa5277a8e4
>
> Spin locks were added to the clocksource_resume_watchdog() which cause
> the kernel debugger to deadlock on an SMP system frequently.
>
> The kernel debugger can try for the lock, but if it fails it should
> continue to touch the clocksource watchdog anyway, else it will trip
> if the general kernel execution has been paused for too long.
>
> This introduces an possible race condition where the kernel debugger
> might not process the list correctly if a clocksource is being added
> or removed at the time of this call. This race is sufficiently rare vs
> having the kernel debugger hang the kernel
>
> CC: Thomas Gleixner <tglx@linutronix.de>
> CC: Martin Schwidefsky <schwidefsky@de.ibm.com>
> CC: John Stultz <johnstul@us.ibm.com>
> CC: Andrew Morton <akpm@linux-foundation.org>
> CC: Magnus Damm <damm@igel.co.jp>
> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
> ---
> kernel/time/clocksource.c | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
> diff --git a/kernel/time/clocksource.c b/kernel/time/clocksource.c
> index e85c234..74f9ba6 100644
> --- a/kernel/time/clocksource.c
> +++ b/kernel/time/clocksource.c
> @@ -463,7 +463,12 @@ void clocksource_resume(void)
> */
> void clocksource_touch_watchdog(void)
> {
> - clocksource_resume_watchdog();
> + unsigned long flags;
> +
> + int got_lock = spin_trylock_irqsave(&watchdog_lock, flags);
> + clocksource_reset_watchdog();
> + if (got_lock)
> + spin_unlock_irqrestore(&watchdog_lock, flags);

Just for the record. This patch would not compile on any platform
which has CONFIG_CLOCKSOURCE_WATCHDOG=n

Thanks,

tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 3 of 3 ==
Date: Tues, Jan 26 2010 3:20 am
From: Thomas Gleixner

On Tue, 26 Jan 2010, Thomas Gleixner wrote:
> There is no sane way to reliably prevent TSC from becoming unstable
> when kgdb stops the kernel inside the watchdog code. And I do not care
> about that at all.
>
> I'm not going to clutter code with crazy workarounds just because some
> people believe that using a kernel debugger is a good idea. If people
> insist on using kgdb then the possible "TSC becomes unstable" side
> effect is the least of their problems.

Btw, if the kernel uses tick based timekeeping or a clock source which
wraps in rather short intervals (e.g. pm-timer wraps after ~4.6
seconds), stopping the kernel with kgdb will inevitably screw up time
keeping anyway.

So there is really no reason to worry about TSC becoming unstable.

There is only one real sensible solution for this:

Do _not_ use kgdb - which is the modus operandi of every sane kernel
developer on the planet.

Thanks,

==============================================================================
TOPIC: gpio_keys and how PXA27x sets gpio_set_wake() (was Re: sharp c-3000 aka
spitz: fix warn_on introduced in 2.6.32-rc1)
http://groups.google.com/group/linux.kernel/t/337ac495cfb9a0e2?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Jan 26 2010 2:50 am
From: Stanislav Brabec

Eric Miao wrote:
> 2010/1/26 Stanislav Brabec <utx@penguin.cz>:

> > Handling platform specific edge/level wake setup would only complicate
> > the code. (In fact, even the PXA270 platform code does not exist yet -
> > arch/arm/mach-pxa/mfp-pxa2xx.c:__mfp_config_gpio() is not capable to
> > configure Power Manager Keyboard Wake-Up Enable Register (PKWR).)
> That's why WAKEUP_ON_EDGE_* is introduced, no need for gpio-keys
> to know this.

But WAKEUP_ON_EDGE_* is impossible for GPIO 95,
enable_irq_wake()/gpio_set_wake() returns EINVAL and disable_irq_wake()
complains on "Unbalanced IRQ 191".

In case of Zaurus, gpio_keys.c have to live with wakeup on level (PKWR)
when using enable/disable_irq_wake().

> > The problem affects gpio_keys: It is a driver implementing "one key per
> > gpio". It now handles On/Off and lid switches on Zaurus. Lid switches
> > are on "normal" GPIOs, On/Off switch is wired to PKWR capable GPIO.
> Ain't On/Off switch one of the matrix key? And so SPITZ_GPIO_KEY_INT
> could be used to handle that?

No. On/Off is connected directly to GPIO 95. Other keys use strobe/sense
matrix keypad.

SPITZ_GPIO_KEY_INT is a bit unspecific. I think it means: Charger was
inserted or key was pressed or On/Off was pressed.

________________________________________________________________________
Stanislav Brabec
http://www.penguin.cz/~utx/zaurus

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 3 ==
Date: Tues, Jan 26 2010 3:40 am
From: Dmitry Eremin-Solenikov

Hello,

2010/1/26 Stanislav Brabec <utx@penguin.cz>:
> Eric Miao wrote:
>> > The problem affects gpio_keys: It is a driver implementing "one key per
>> > gpio". It now handles On/Off and lid switches on Zaurus. Lid switches
>> > are on "normal" GPIOs, On/Off switch is wired to PKWR capable GPIO.
>> Ain't On/Off switch one of the matrix key? And so SPITZ_GPIO_KEY_INT
>> could be used to handle that?
>
> No. On/Off is connected directly to GPIO 95. Other keys use strobe/sense
> matrix keypad.
>
> SPITZ_GPIO_KEY_INT is a bit unspecific. I think it means: Charger was
> inserted or key was pressed or On/Off was pressed.

This seems to be true. At least they used the same design on tosa and other
zaurii.

--
With best wishes
Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 3 of 3 ==
Date: Tues, Jan 26 2010 3:50 am
From: Eric Miao

2010/1/26 Stanislav Brabec <utx@penguin.cz>:
> Eric Miao wrote:
>> 2010/1/26 Stanislav Brabec <utx@penguin.cz>:
>
>> > Handling platform specific edge/level wake setup would only complicate
>> > the code. (In fact, even the PXA270 platform code does not exist yet -
>> > arch/arm/mach-pxa/mfp-pxa2xx.c:__mfp_config_gpio() is not capable to
>> > configure Power Manager Keyboard Wake-Up Enable Register (PKWR).)
>> That's why WAKEUP_ON_EDGE_* is introduced, no need for gpio-keys
>> to know this.
>
> But WAKEUP_ON_EDGE_* is impossible for GPIO 95,
> enable_irq_wake()/gpio_set_wake() returns EINVAL and disable_irq_wake()
> complains on "Unbalanced IRQ 191".
>

Now I see, but I don't know why disable_irq_wake() will complains about
unbalance since it should really manage it well.

A quick dirty solution would be the platform to call keypad_set_wake()
directly somewhere. Otherwise we have to let gpio_set_wake() to handle
those keypad GPIOs and to live together with keypad_set_wake() happily,
which is really difficult.

> In case of Zaurus, gpio_keys.c have to live with wakeup on level (PKWR)
> when using enable/disable_irq_wake().
>
>> > The problem affects gpio_keys: It is a driver implementing "one key per
>> > gpio". It now handles On/Off and lid switches on Zaurus. Lid switches
>> > are on "normal" GPIOs, On/Off switch is wired to PKWR capable GPIO.
>> Ain't On/Off switch one of the matrix key? And so SPITZ_GPIO_KEY_INT
>> could be used to handle that?
>
> No. On/Off is connected directly to GPIO 95. Other keys use strobe/sense
> matrix keypad.
>
> SPITZ_GPIO_KEY_INT is a bit unspecific. I think it means: Charger was
> inserted or key was pressed or On/Off was pressed.
>
>
>
> ________________________________________________________________________
> Stanislav Brabec
> http://www.penguin.cz/~utx/zaurus
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Hyperthreading on Core i7s: To use or not to use?
http://groups.google.com/group/linux.kernel/t/185addf08bbc650e?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 3:00 am
From: Daniel J Blueman

On Jan 26, 10:10 am, Justin Piszcz <jpiszcz@lucidpixels.com> wrote:
> Hello,
>
> Should the 'correct' kernel [CPU] configuration for a core i7 860/870..?
>
> - Multi-core support
> - Cores: 8
> - SMT: Enabled/ON
>
> From CONFIG_SCHED_SMT:
>
> . SMT scheduler support improves the CPU scheduler's decision making .
> . when dealing with Intel Pentium 4 chips with HyperThreading at a .
> . cost of slightly increased overhead in some places. If unsure say .
> . N here. .
>
> Does this also 'help' and/or 'apply' as much when dealing with Core i7s?
>
> --
>
> Quick little benchmark (pbzip2 -9 linux kernel source), the benchmark is
> really within the noise (8 on/off)
> - Multicore(8)/HT(Off) = 73.72user 0.33system 0:09.50elapsed 779%CPU (0avgtext+0avgdata 458528maxresident
> - Multicore(8)/HT(On) = 74.28user 0.40system 0:09.67elapsed 772%CPU (0avgtext+0avgdata 428304maxresident
> - Multicore(4)/HT(On) = 68.76user 0.30system 0:17.44elapsed 396%CPU (0avgtext+0avgdata 213616maxresident)k
>
> --
>
> Has anyone done any in-depth benchmarking for the core i7s that have multiple
> cores and HT disabled/enabled?

With my Dell Studio 15 (model 1557) laptop, there is no option to
disable HT in the current BIOS, so booting with maxcpus=4 (since the
kernel enumerates non-sibling cores first) gave me a 5-15% speedup on
some large image processing (convolution, FFTs, conversion) on all
available cores, presumably due to better cache efficiency.

Booting with maxcpus=4 prevents any of the cores sitting in C6, needed
for turbo-boost and a lower thermal profile, though I did find
scheduling latency and responsiveness better under load booting with
maxcpus=4, so favour this when plugged in.

Clearly, having the BIOS option allows benefit to certain applications
- Dell should give their users the choice!

Perhaps the 'noht' boot option should be reintroduced to initialise
all cores, but only expose non-sibling cores to the OS (thus allowing
C6)?

Daniel

tip: modprobe msr and use turbostat to monitor turbo-boost and C-state
residency: http://bugzilla.kernel.org/attachment.cgi?id=24673
--
Daniel J Blueman
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: OOM-Killer kills too much with 2.6.32.2
http://groups.google.com/group/linux.kernel/t/3f7afc452c078f22?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 3:10 am
From: KOSAKI Motohiro

(Restore all cc and add Hugh and Chris)

> > Hi all,
> >
> > Strangely, all reproduce machine are x86_64 with Intel i915. but I don't
> > have any solid evidence.
> > Can anyone please apply following debug patch and reproduce this issue?
> >
> > this patch write some debug message into /var/log/messages.
> >
>
> Here it is
>
> Jan 26 09:34:32 kedge kernel: ->fault OOM shmem_fault 1 1
> Jan 26 09:34:32 kedge kernel: X invoked oom-killer: gfp_mask=0x0, order=0,
> oom_adj=0
> Jan 26 09:34:32 kedge kernel: Pid: 1927, comm: X Not tainted 2.6.33-rc5 #3

Very thank you!!

Current status and analysis are
- OOM is invoked by VM_FAULT_OOM in page fault
- GEM use lots shmem internally. i915 use GEM.
- VM_FAULT_OOM is created by shmem.
- shmem allocate some memory by using mapping_gfp_mask(inode->i_mapping).
and if allocation failed, it can return -ENOMEM and -ENOMEM generate VM_FAULT_OOM.
- But, GEM have following code.

drm_gem.c drm_gem_object_alloc()
--------------------
obj->filp = shmem_file_setup("drm mm object", size, VM_NORESERVE);
(snip)
/* Basically we want to disable the OOM killer and handle ENOMEM
* ourselves by sacrificing pages from cached buffers.
* XXX shmem_file_[gs]et_gfp_mask()
*/
mapping_set_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping,
GFP_HIGHUSER |
__GFP_COLD |
__GFP_FS |
__GFP_RECLAIMABLE |
__GFP_NORETRY |
__GFP_NOWARN |
__GFP_NOMEMALLOC);

This comment is lie. __GFP_NORETY cause ENOMEM to shmem, not GEM itself.
GEM can't handle nor recover it. I suspect following commit is wrong.

----------------------------------------------------
commit 07f73f6912667621276b002e33844ef283d98203
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Mon Sep 14 16:50:30 2009 +0100

drm/i915: Improve behaviour under memory pressure

Due to the necessity of having to take the struct_mutex, the i915
shrinker can not free the inactive lists if we fail to allocate memory
whilst processing a batch buffer, triggering an OOM and an ENOMEM that
is reported back to userspace. In order to fare better under such
circumstances we need to manually retry a failed allocation after
evicting inactive buffers.

To do so involves 3 steps:
1. Marking the backing shm pages as NORETRY.
2. Updating the get_pages() callers to evict something on failure and then
retry.
3. Revamping the evict something logic to be smarter about the required
buffer size and prefer to use volatile or clean inactive pages.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
----------------------------------------------------

but unfortunatelly it can't revert easily.
So, Can you please try following partial revert patch?

From a27115f93d4f3ff6538860e69a7b444761cef91b Mon Sep 17 00:00:00 2001
From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Date: Tue, 26 Jan 2010 19:51:57 +0900
Subject: [PATCH] Revert NORETRY

---
drivers/gpu/drm/drm_gem.c | 13 -------------
1 files changed, 0 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index e9dbb48..8bf3770 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -142,19 +142,6 @@ drm_gem_object_alloc(struct drm_device *dev, size_t size)
if (IS_ERR(obj->filp))
goto free;

- /* Basically we want to disable the OOM killer and handle ENOMEM
- * ourselves by sacrificing pages from cached buffers.
- * XXX shmem_file_[gs]et_gfp_mask()
- */
- mapping_set_gfp_mask(obj->filp->f_path.dentry->d_inode->i_mapping,
- GFP_HIGHUSER |
- __GFP_COLD |
- __GFP_FS |
- __GFP_RECLAIMABLE |
- __GFP_NORETRY |
- __GFP_NOWARN |
- __GFP_NOMEMALLOC);
-
kref_init(&obj->refcount);
kref_init(&obj->handlecount);
obj->size = size;
--
1.6.5.2

==============================================================================
TOPIC: twl4030 threaded_irq support
http://groups.google.com/group/linux.kernel/t/dad470d391a03375?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 26 2010 3:10 am
From: Felipe Balbi

On Tue, Jan 26, 2010 at 08:06:55AM +0100, ext David Brownell wrote:
>On Monday 14 December 2009, Felipe Balbi wrote:
>> move twl4030 children to threaded irq.
>>
>> Felipe Balbi (4):
>> input: keyboard: twl4030: move to request_threaded_irq
>> input: misc: twl4030: move to request_threaded_irq
>> rtc: twl4030: move to request_threaded_irq
>> usb: otg: twl4030: move to request_threaded_irq
>
>But nothing in drivers/mfd ... the entry to the whole stack?
>
>Did the threaded IRQ stuff ever get set up so that the top
>level IRQ thread didn't have to hand off to another thread
>each time? (That's how the current stuff works. One thread
>calling out to each handler.)
>
>If so, I'd like to see that be used here, rather than needlessly
>spend all those pages on mostly-unused stacks.

correct, that's still missing. I tried to play with it for a while, but
had to give up due to other musb tasks. So if someone wants to step up
and code that part, I'd be glad

--
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 2 of 2 ==
Date: Tues, Jan 26 2010 4:20 am
From: David Brownell

On Friday 11 December 2009, Felipe Balbi wrote:
> The notifier will be used to communicate usb events
> to other drivers like the charger chip.

Good idea ... but not OTG-specific. It doesn't seem to me
that charging hookups belong in that header at all.

In fact, usb_gadget_vbus_draw() might better be implemented
as such a notifier call, removing that configuration mess
from the usb gadget drivers ("how can I know what charger
to use??"). That would be the most common situation: a
peripheral-only device.

And in fact, OTG can be treated as a trivial superset of
peripheral-only USB. (In terms of charger support, only!!)

I'd vote to convert all the USB-to-charger interfaces so
they use notifiers. After fixing the events ... see
comments below. :)

> This can be used as source of information to kick
> usb charger detection as described by the USB
> Battery Charging Specification 1.1 and/or to
> pass bMaxPower field of selected usb_configuration
> to charger chip in order to use that information
> as input current on the charging profile
> setup.
>
> Signed-off-by: Felipe Balbi <felipe.balbi@nokia.com>
> ---
> include/linux/usb/otg.h | 25 +++++++++++++++++++++++++
> 1 files changed, 25 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
> index 52bb917..6c0b676 100644
> --- a/include/linux/usb/otg.h
> +++ b/include/linux/usb/otg.h
> @@ -9,6 +9,8 @@
> #ifndef __LINUX_USB_OTG_H
> #define __LINUX_USB_OTG_H
>
> +#include <linux/notifier.h>
> +
> /* OTG defines lots of enumeration states before device reset */
> enum usb_otg_state {
> OTG_STATE_UNDEFINED = 0,
> @@ -33,6 +35,14 @@ enum usb_otg_state {
> OTG_STATE_A_VBUS_ERR,
> };
>
> +enum usb_xceiv_events {

Let's keep charger events separate from anything else,
like "enter host mode" or "enter peripheral mode" (or
even "disconnect"). The audiences for any other types
of event would be entirely different.

Right now there's a mess in terms of charger hookup,
so getting that straight is IMO a priority over any
other type of event. Using events will decouple a
bunch of drivers, and simplify driver configuration.

> + USB_EVENT_NONE, /* no events or cable disconnected */
> + USB_EVENT_VBUS, /* vbus valid event */
> + USB_EVENT_ID, /* id was grounded */
> + USB_EVENT_CHARGER, /* usb dedicated charger */
> + USB_EVENT_ENUMERATED, /* gadget driver enumerated */

Those seem like the wrong events. The right events for a charger
would be more along the lines of:

- For peripheral: "you may use N milliAmperes now".
- General: "Don't Charge" (a.k.a. "use 0 mA").

I don't see how "N" would be passed with those events ...

Haven't looked at the details of the charger spec, but
those two events are the *basics* from the USB 2.0 spec,
so "official" charger hardware wouldn't be less capable.

Thing like different levels of VBUS validity, ID grounding,
and so forth ... wouldn't be very relevant. An OTG driver
will do various things, internally, when ID grounds; but
anything else is a function of what role eventually gets
negotiated. And for the charger, they all add up to "Don't
Charge" (since ID grounded means A-role, sourcing power).

A host *might* want to be able to say things like "supply
up to N milliAmperes now", e.g. to let a regulator choose
the most efficient mode.

> +};
> +
> #define USB_OTG_PULLUP_ID (1 << 0)
> #define USB_OTG_PULLDOWN_DP (1 << 1)
> #define USB_OTG_PULLDOWN_DM (1 << 2)
> @@ -70,6 +80,9 @@ struct otg_transceiver {
> struct otg_io_access_ops *io_ops;
> void __iomem *io_priv;
>
> + /* for notification of usb_xceiv_events */
> + struct blocking_notifier_head notifier;

Why "blocking"? That seems kind of unnatural; for example,
the main users -- like usb_gadget_vbus_draw() -- would be
called in IRQ context (blocking not allowed).

> +
> /* to pass extra port status to the root hub */
> u16 port_status;
> u16 port_change;
> @@ -203,6 +216,18 @@ otg_start_srp(struct otg_transceiver *otg)
> return otg->start_srp(otg);
> }
>
> +/* notifiers */
> +static inline int
> +otg_register_notifier(struct otg_transceiver *otg, struct notifier_block *nb)
> +{
> + return blocking_notifier_chain_register(&otg->notifier, nb);
> +}
> +
> +static inline void
> +otg_unregister_notifier(struct otg_transceiver *otg, struct notifier_block *nb)
> +{
> + blocking_notifier_chain_unregister(&otg->notifier, nb);
> +}
>
> /* for OTG controller drivers (and maybe other stuff) */
> extern int usb_bus_start_enum(struct usb_bus *bus, unsigned port_num);
>

==============================================================================
TOPIC: regulator: support max8649
http://groups.google.com/group/linux.kernel/t/0c21f2834789c0db?hl=en
==============================================================================

== 1 of 4 ==
Date: Tues, Jan 26 2010 3:10 am
From: Liam Girdwood

On Tue, 2010-01-26 at 01:26 -0500, Haojian Zhuang wrote:
> From 2b5a73c336d2b5dc48c8cf1f2a804b6968659f78 Mon Sep 17 00:00:00 2001
> From: Haojian Zhuang <haojian.zhuang@marvell.com>
> Date: Mon, 25 Jan 2010 10:24:09 -0500
> Subject: [PATCH] regulator: enable max8649 regulator driver
>
> Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>

Can you confirm all the changes compared to the last version.

> +static int max8649_get_voltage(struct regulator_dev *rdev)
> +{
> + struct max8649_regulator_info *info = rdev_get_drvdata(rdev);
> + unsigned char data;
> + int ret;
> +
> + ret = max8649_reg_read(info->i2c, info->vol_reg);
> + if (ret < 0)
> + return ret;
> + data = (unsigned char)ret & MAX8649_VOL_MASK;
> + return (max8649_list_voltage(rdev, data));

Any reason why we have extra () here ?

Thanks

Liam

== 2 of 4 ==
Date: Tues, Jan 26 2010 3:10 am
From: Mark Brown

On Tue, Jan 26, 2010 at 01:26:08AM -0500, Haojian Zhuang wrote:

This all looks good except...

> +static int max8649_enable_time(struct regulator_dev *rdev)
> +{

...

> + return (voltage / step);

I'd expect the time taken to enable to be the voltage multipled by the
step size rather than divided by the step size?

> +static int max8649_set_mode(struct regulator_dev *rdev, unsigned int mode)
> +{
> + struct max8649_regulator_info *info = rdev_get_drvdata(rdev);
> +
> + switch (mode) {
> + case REGULATOR_MODE_FAST:
> + max8649_set_bits(info->i2c, info->vol_reg, MAX8649_FORCE_PWM,
> + MAX8649_FORCE_PWM);
> + break;
> + case REGULATOR_MODE_NORMAL:
> + max8649_set_bits(info->i2c, info->vol_reg,
> + MAX8649_FORCE_PWM, 0);
> + break;

This should really have a default case which rejects other modes.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 3 of 4 ==
Date: Tues, Jan 26 2010 4:00 am
From: Haojian Zhuang

On Tue, Jan 26, 2010 at 6:01 AM, Liam Girdwood <lrg@slimlogic.co.uk> wrote:
> On Tue, 2010-01-26 at 01:26 -0500, Haojian Zhuang wrote:
>> From 2b5a73c336d2b5dc48c8cf1f2a804b6968659f78 Mon Sep 17 00:00:00 2001
>> From: Haojian Zhuang <haojian.zhuang@marvell.com>
>> Date: Mon, 25 Jan 2010 10:24:09 -0500
>> Subject: [PATCH] regulator: enable max8649 regulator driver
>>
>> Signed-off-by: Haojian Zhuang <haojian.zhuang@marvell.com>
>
> Can you confirm all the changes compared to the last version.
>
Yes, exactly.

>> +static int max8649_get_voltage(struct regulator_dev *rdev)
>> +{
>> + � � � struct max8649_regulator_info *info = rdev_get_drvdata(rdev);
>> + � � � unsigned char data;
>> + � � � int ret;
>> +
>> + � � � ret = max8649_reg_read(info->i2c, info->vol_reg);
>> + � � � if (ret < 0)
>> + � � � � � � � return ret;
>> + � � � data = (unsigned char)ret & MAX8649_VOL_MASK;
>> + � � � return (max8649_list_voltage(rdev, data));
>
> Any reason why we have extra () here ?
>
Fixed.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

== 4 of 4 ==
Date: Tues, Jan 26 2010 4:10 am
From: Mark Brown

On Tue, Jan 26, 2010 at 06:54:48AM -0500, Haojian Zhuang wrote:
> On Tue, Jan 26, 2010 at 6:04 AM, Mark Brown

> > I'd expect the time taken to enable to be the voltage multipled by the
> > step size rather than divided by the step size?

> I don't agree at this point. The unit of step is uV/uSec. The function
> should return uSec. So voltage divided by the step is more reasonable.

Ah, then the variable step is confusingly named since it's actually a
rate of change rather than a step size - I'd suggest rate or something
like that instead.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: HID: ignore afatech 9016
http://groups.google.com/group/linux.kernel/t/d852f364010c4872?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 3:20 am
From: Pekka Sarnila

Well, as I said I use now different TV-stick. But I have the old one
somewhere. I'll try to find it and check it.

Pekka

Jiri Kosina wrote:
> On Wed, 13 Jan 2010, Jiri Slaby wrote:
>
>
>>Let's ignore the device altogether by the HID layer. It's handled
>>by dvb-usb-remote driver already.
>>
>>By now, FULLSPEED_INTERVAL quirk was used. It probably made things
>>better, but the remote controller was still a perfect X killer.
>>This was the last user of the particular quirk. So remove the quirk
>>as well.
>>
>>With input going through dvb-usb-remote, the remote works
>>perfectly.
>>
>>The device is 15a4:9016.
>
>
> Pekka, did you have chance to verify whether it works fine also with your
> version of the remote, or you still need the FULLSPEED_INTERVAL quirk on
> your side?
>
> Thanks.
>
>
>>Signed-off-by: Jiri Slaby <jslaby@suse.cz>
>>Cc: Jiri Kosina <jkosina@suse.cz>
>>Cc: Pekka Sarnila <sarnila@adit.fi>
>>---
>> drivers/hid/hid-core.c | 1 +
>> drivers/hid/usbhid/hid-core.c | 8 --------
>> drivers/hid/usbhid/hid-quirks.c | 2 --
>> include/linux/hid.h | 1 -
>> 4 files changed, 1 insertions(+), 11 deletions(-)
>>
>>diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
>>index 08f8f23..0ae0bfd 100644
>>--- a/drivers/hid/hid-core.c
>>+++ b/drivers/hid/hid-core.c
>>@@ -1534,6 +1534,7 @@ static const struct hid_device_id hid_ignore_list[] = {
>> { HID_USB_DEVICE(USB_VENDOR_ID_ACECAD, USB_DEVICE_ID_ACECAD_FLAIR) },
>> { HID_USB_DEVICE(USB_VENDOR_ID_ACECAD, USB_DEVICE_ID_ACECAD_302) },
>> { HID_USB_DEVICE(USB_VENDOR_ID_ADS_TECH, USB_DEVICE_ID_ADS_TECH_RADIO_SI470X) },
>>+ { HID_USB_DEVICE(USB_VENDOR_ID_AFATECH, USB_DEVICE_ID_AFATECH_AF9016) },
>> { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_01) },
>> { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_10) },
>> { HID_USB_DEVICE(USB_VENDOR_ID_AIPTEK, USB_DEVICE_ID_AIPTEK_20) },
>>diff --git a/drivers/hid/usbhid/hid-core.c b/drivers/hid/usbhid/hid-core.c
>>index e2997a8..36a1561 100644
>>--- a/drivers/hid/usbhid/hid-core.c
>>+++ b/drivers/hid/usbhid/hid-core.c
>>@@ -938,14 +938,6 @@ static int usbhid_start(struct hid_device *hid)
>>
>> interval = endpoint->bInterval;
>>
>>- /* Some vendors give fullspeed interval on highspeed devides */
>>- if (hid->quirks & HID_QUIRK_FULLSPEED_INTERVAL &&
>>- dev->speed == USB_SPEED_HIGH) {
>>- interval = fls(endpoint->bInterval*8);
>>- printk(KERN_INFO "%s: Fixing fullspeed to highspeed interval: %d -> %d\n",
>>- hid->name, endpoint->bInterval, interval);
>>- }
>>-
>> /* Change the polling interval of mice. */
>> if (hid->collection->usage == HID_GD_MOUSE && hid_mousepoll_interval > 0)
>> interval = hid_mousepoll_interval;
>>diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
>>index 38773dc..f2ae8a7 100644
>>--- a/drivers/hid/usbhid/hid-quirks.c
>>+++ b/drivers/hid/usbhid/hid-quirks.c
>>@@ -41,8 +41,6 @@ static const struct hid_blacklist {
>> { USB_VENDOR_ID_SAITEK, USB_DEVICE_ID_SAITEK_RUMBLEPAD, HID_QUIRK_BADPAD },
>> { USB_VENDOR_ID_TOPMAX, USB_DEVICE_ID_TOPMAX_COBRAPAD, HID_QUIRK_BADPAD },
>>
>>- { USB_VENDOR_ID_AFATECH, USB_DEVICE_ID_AFATECH_AF9016, HID_QUIRK_FULLSPEED_INTERVAL },
>>-
>> { USB_VENDOR_ID_PANTHERLORD, USB_DEVICE_ID_PANTHERLORD_TWIN_USB_JOYSTICK, HID_QUIRK_MULTI_INPUT | HID_QUIRK_SKIP_OUTPUT_REPORTS },
>> { USB_VENDOR_ID_PLAYDOTCOM, USB_DEVICE_ID_PLAYDOTCOM_EMS_USBII, HID_QUIRK_MULTI_INPUT },
>>
>>diff --git a/include/linux/hid.h b/include/linux/hid.h
>>index 8709365..4a33e16 100644
>>--- a/include/linux/hid.h
>>+++ b/include/linux/hid.h
>>@@ -311,7 +311,6 @@ struct hid_item {
>> #define HID_QUIRK_BADPAD 0x00000020
>> #define HID_QUIRK_MULTI_INPUT 0x00000040
>> #define HID_QUIRK_SKIP_OUTPUT_REPORTS 0x00010000
>>-#define HID_QUIRK_FULLSPEED_INTERVAL 0x10000000
>> #define HID_QUIRK_NO_INIT_REPORTS 0x20000000
>>
>> /*
>>--
>>1.6.5.7
>>
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: ftrace: unify arch_syscall_addr() implementations
http://groups.google.com/group/linux.kernel/t/f483b618b805fe50?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 3:30 am
From: Heiko Carstens

On Tue, Jan 26, 2010 at 04:40:03AM -0500, Mike Frysinger wrote:
> Most implementations of arch_syscall_addr() are the same, so create a
> default version in common code and move the one piece that differs (the
> syscall table) to asm/syscall.h. New arch ports don't have to waste
> time copying & pasting this simple function.
>
> The s390/sparc versions need to be different, so document why.
>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> Acked-by: David S. Miller <davem@davemloft.net>
> Acked-by: Paul Mundt <lethal@linux-sh.org>
> ---
> v3
> - move sys_call_table[] decl to asm/syscall.h
> - unify everyone's arch_syscall_addr() again
> - mention right tracehook requirements
>
> Documentation/trace/ftrace-design.txt | 5 ++---
> arch/s390/include/asm/syscall.h | 7 +++++++
> arch/s390/kernel/ftrace.c | 10 ----------

Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: Status of Andigilog asc7621 driver submitted by George Joseph on 2008-
05-29
http://groups.google.com/group/linux.kernel/t/90f1e5771291fdb0?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 4:00 am
From: Hans de Goede

On 01/24/2010 06:05 AM, Jaswinder Singh Rajput wrote:
> Hello Hans,
>
> On Sat, Jan 23, 2010 at 11:28 PM, Hans de Goede<j.w.r.degoede@hhs.nl> wrote:
>> Hi,
>>
>> I just checked my Drafts folder, and I still have my unfinished review
>> in there. So if there is interest I can send that, note that it is
>> not a complete review though (there is a note in there which part
>> of the code is reviewed and which still needs to be reviewed).
>>
>
> Please provide your review so that we can discuss about this driver
> and make relevant changes to accept it.
>

Ok, here is the partly review I've done:

---begin---
Hi Joseph,

george.joseph@peakin.com wrote:
> Here's the c file by itself.
>
> Hans, will you have any time to review the driver in the near future?
>

I believe I said I would make time for this some time ago. Given that the 2.6.29 merge window has already opened, I've now done so (made time). So that this hopefully / maybe can make 2.6.29's merge window.

I must say that this driver deviates a lot from the standard way all other hwmon drivers are written making the review somewhat cumbersome and this might also be a problem if you step down and someone else becomes the maintainer.

I've split me review in 2 parts, first some comments about how you've implemented the sysfs API:

I notice that you have added foo_label sysfs entries, while you have nothing usefull to put in them, please do not _label entries are only for when the driver knows / can provide a label in the prefered format for a human reader of the sensors output, so not "in1", but something like "ATX 12V", so please remove all _label sysfs entries and remove the corresponding "char *label" member from the asc7621_param struct.

Likewise you've added tempX_type entries, but these always return the same value, in this case they can (and should be omitted) there is only the need to know (and more importantly be able to set) the type of the sensor, if it can be of different types, as in this case the BIOS might have set it wrong, when you remove these sysfs entries, you can also remove the corresponding "value" member from the asc7621_param struct.

And second, some feedback on the code itself.

First of all in *ALL* your store functions you need to store the result of strtol in a long and strtoul in an unsigned long, storing in smaller types can cause an overflow before you do any checking / clamping when the user gives a really large value as input.

Also in *ALL* store functions please use strict_strtol (and strtoul) instead of simple.

Last in some functions you need to clamp the input from the user to the valid input range before doing further calculations to avoid overflows during the calculation. Often clamping after calculations can be too late.

Example:

Instead of:

static ssize_t store_u8(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
SETUP_STORE_data_param(dev, attr);

u8 reqval = simple_strtoul(buf, NULL, 10);

mutex_lock(&data->update_lock);
data->reg[param->msb[0]] = reqval;
write_byte(param->msb[0], reqval);
mutex_unlock(&data->update_lock);
return count;
}

Write:

static ssize_t store_u8(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
SETUP_STORE_data_param(dev, attr);
long reqval;

if (strict_strtoul(buf, 10, &reqval))
return -EINVAL;

reqval = SENSORS_LIMIT(v, 0, 255);

mutex_lock(&data->update_lock);
data->reg[param->msb[0]] = reqval;
write_byte(param->msb[0], reqval);
mutex_unlock(&data->update_lock);
return count;
}

Note that in this example all 3 described changes were made (use long, use strict_strtol, clamp before further use). *ALL* your store functions need the first 2 changes (use long, use strict_strtol), so I'm not going to make that comment for each and every store functions in the detailed comments below.

Where a store function needs earlier / different clamping I will make a comment in the detailed feedback given below.

Below are pieces of code from the driver with detailed feedback below them.

###

* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*

I notice there is no "or at your option any later version" language here, this
is fine, but I wonder if this is on purpose, if not please add "or at your
option any later version", so that if the kernel ever (not likely) wants to
move to GPL v3 this is one less file to worry about.

###

/*
* The "chips" enum created by I2C_CLIENT_INSMOD_2 has "any_chip" as
* the first element in the enum, so it must also be first in our array.
*/
static struct asc7621_chip asc7621_chips[] = {
{
.name = "any",.chip_type = any_chip,
},
{
.name = "asc7621",.chip_type = asc7621,
.company_reg = 0x3e,.company_id = 0x61,
.verstep_reg = 0x3f,.verstep_id = 0x6c,
.addresses = normal_i2c,
},
{
.name = "asc7621a",.chip_type = asc7621a,
.company_reg = 0x3e,.company_id = 0x61,
.verstep_reg = 0x3f,.verstep_id = 0x6d,
.addresses = normal_i2c,
},
};

Your driver still uses old style i2c driver binding, please update it too the
new style. See for example:
http://lists.lm-sensors.org/pipermail/lm-sensors/2008-July/023773.html

You will probably want to remove using this when you do this, as this overlaps
with the i2c_device_id array you need to declare then.

###

static ssize_t store_u8(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{
SETUP_STORE_data_param(dev, attr);

u8 reqval = simple_strtoul(buf, NULL, 10);

mutex_lock(&data->update_lock);
data->reg[param->msb[0]] = reqval;
write_byte(param->msb[0], reqval);
mutex_unlock(&data->update_lock);
return count;
}

Clamp large input values instead of allowing large values to cause overflows, see above for how this function should look (IMHO)

###

static ssize_t store_bitmask(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{
SETUP_STORE_data_param(dev, attr);

u8 reqval = simple_strtoul(buf, NULL, 10);

Same as for store_u8, except the values between which to clamp depend on the mask.

###

static ssize_t show_fan16(struct device *dev,
struct device_attribute *attr, char *buf)
{
SETUP_SHOW_data_param(dev, attr);

u16 regval = (data->reg[param->msb[0]] << 8) | data->reg[param->lsb[0]]

You are using multiple values from data here, this might race with device update resulting in using an old msb with a new lsb or vica versa, so you need locking around this.

###

static ssize_t show_in10(struct device *dev, struct device_attribute *attr,
char *buf)
{

You are using multiple values from data here, you need locking around this.

###

static ssize_t store_in8(struct device *dev, struct device_attribute *attr,
const char *buf, size_t count)
{

u8 nr;
s32 reqval;

SETUP_STORE_data_param(dev, attr);

nr = sda->index;
reqval = simple_strtoul(buf, NULL, 10);
reqval *= asc7621_in_scaling_div[nr];
reqval /= asc7621_in_scaling_mul[nr];
reqval = SENSORS_LIMIT(reqval, 0, 255);

do SENSORS_LIMIT before calculations, the multiple might cause an overflow
otherwise (and ofcourse, reqval should be a long, use strict_strtol).

###
static ssize_t show_temp10(struct device *dev,
struct device_attribute *attr, char *buf)
{

You are using multiple values from data here, you need locking around this.

###

static ssize_t show_ap2_temp(struct device *dev,
struct device_attribute *attr, char *buf)
{

You are using multiple values from data here, you need locking around this.

###

static ssize_t store_ap2_temp(struct device *dev,
struct device_attribute *attr,
const char *buf, size_t count)
{

you need to take the lock earlier, before reading auto_point1 from the cached
register array (and ofcourse, reqval should be a long, use strict_strtol).

###

static ssize_t show_pwm_enable(struct device *dev,
struct device_attribute *attr, char *buf)
{

You are using multiple values from data here, you need locking around this.

###

In store store_pwm_freq() / store_pwm_ast() / store_temp_st() the following:
if (newval == 255)
return count;

Should return -EINVAL, as you are rejecting the value (not making any changes)

###

Note to self all store / show functions are reviewed

---end---

Regards,

Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: tty: usb_serial_mos7720: Fix get_lsr_info
http://groups.google.com/group/linux.kernel/t/6c6f1d1e04acc542?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 26 2010 4:10 am
From: Kees Schoenmakers

Gentlemen,

As of version 2.6.32.5 this patch has not made it into the kernel sources.
Any reason for this? It is a pity for people who knowingly or unknowingly run
into this effect in the driver.

kind regards

Kees

On Saturday 19 September 2009 23:36:29 Greg Kroah-Hartman wrote:
> From: Kees Schoenmakers <k.schoenmakers@sigmae.nl>
>
> I made a correction for get_lsr_info, now it returns some meaningful
> information. I tested it with two simultaneous simplex modem channels.
>
> it is attached
>
> Signed-off-by: Kees Schoenmakers <k.schoenmakers@sigmae.nl>
> Signed-off-by: Alan Cox <alan@linux.intel.com>
> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
> ---
> drivers/usb/serial/mos7720.c | 19 +++++++++++++++----
> 1 files changed, 15 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/usb/serial/mos7720.c b/drivers/usb/serial/mos7720.c
> index 759cdd5..4342a8a 100644
> --- a/drivers/usb/serial/mos7720.c
> +++ b/drivers/usb/serial/mos7720.c
> @@ -378,10 +378,14 @@ static int mos7720_open(struct tty_struct *tty,
> /* Initialize MCS7720 -- Write Init values to corresponding Registers
> *
> * Register Index
> + * 0 : THR/RHR
> * 1 : IER
> * 2 : FCR
> * 3 : LCR
> * 4 : MCR
> + * 5 : LSR
> + * 6 : MSR
> + * 7 : SPR
> *
> * 0x08 : SP1/2 Control Reg
> */
> @@ -1250,15 +1254,22 @@ static void mos7720_set_termios(struct tty_struct
> *tty, static int get_lsr_info(struct tty_struct *tty,
> struct moschip_port *mos7720_port, unsigned int __user *value)
> {
> - int count;
> + struct usb_serial_port *port = tty->driver_data;
> unsigned int result = 0;
> + unsigned char data = 0;
> + int port_number = port->number - port->serial->minor;
> + int count;
>
> count = mos7720_chars_in_buffer(tty);
> if (count == 0) {
> - dbg("%s -- Empty", __func__);
> - result = TIOCSER_TEMT;
> + send_mos_cmd(port->serial, MOS_READ, port_number,
> + UART_LSR, &data);
> + if ((data & (UART_LSR_TEMT | UART_LSR_THRE))
> + == (UART_LSR_TEMT | UART_LSR_THRE)) {
> + dbg("%s -- Empty", __func__);
> + result = TIOCSER_TEMT;
> + }
> }
> -
> if (copy_to_user(value, &result, sizeof(int)))
> return -EFAULT;
> return 0;

== 2 of 2 ==
Date: Tues, Jan 26 2010 4:10 am
From: Kees Schoenmakers

Gentlemen,

Drop my previous email, it has the wrong subject

kind regards

Kees

==============================================================================
TOPIC: HDA Intel Audio hang on boot
http://groups.google.com/group/linux.kernel/t/a0ad5b25d979d11d?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 4:10 am
From: Sid Boyce

On 26/01/10 06:58, Takashi Iwai wrote:
> At Tue, 26 Jan 2010 07:40:03 +0100,
> I wrote:
>>
>> At Tue, 26 Jan 2010 00:59:15 +0000,
>> Sid Boyce wrote:
>>>
>>> On 25/01/10 21:55, Takashi Iwai wrote:
>>>> At Mon, 25 Jan 2010 22:54:23 +0100,
>>>> I wrote:
>>>>>
>>>>> At Mon, 25 Jan 2010 22:39:02 +0100,
>>>>> Rafael J. Wysocki wrote:
>>>>>>
>>>>>> On Monday 25 January 2010, Sid Boyce wrote:
>>>>>>> On 15/01/10 01:24, Sid Boyce wrote:
>>>>>>> This is the only outstanding bug. No problems up 2.6.32-git1, but I get
>>>>>>> a solid lock-up on 2.6.32-git2 through 2.6.33-rc5 if the on-board audio
>>>>>>> is not disabled in the BIOS.
>>>>>>
>>>>>> I guess we should let Takashi know.
>>>>>
>>>>> Thanks.
>>>>>
>>>>>>>> tindog:~ # uname -r
>>>>>>>> 2.6.33-rc4-smp
>>>>>>>> On 2.6.32-git1 which boots, hwinfo shows:-
>>>>>>>> oss.card_id = 'HDA NVidia'
>>>>>>>> oss.card_id = 'HDA NVidia'
>>>>>>>> oss.card_id = 'HDA NVidia'
>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>> info.product = 'HDA NVidia ALSA hardware specific Device'
>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>> info.product = 'HDA NVidia ALSA Control Device'
>>>>>>>> alsa.card_id = 'HDA NVidia'
>>>>>>>> info.product = 'HDA NVidia Sound Card'
>>>>>>>> sound.card_id = 'HDA NVidia'
>>>>>>>> info.linux.driver = 'HDA Intel'
>>>>>>>> 22: 489835 578 IO-APIC-fasteoi sata_nv, HDA Intel
>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
>>>>>>>> HDA Intel: module = snd_hda_intel
>>>>>>>> irq:0 22 ( 490413) "sata_nv" "HDA Intel"
>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
>>>>>>>> HDA Intel: module = snd_hda_intel
>>>>>>>> HDA Intel: /devices/pci0000:00/0000:00:0e.1
>>>>>>>> HDA Intel: module = snd_hda_intel
>>>>>>>> E: DRIVER=HDA Intel
>>>>>>>> <6>HDA Intel 0000:00:0e.1: PCI INT B -> Link[AAZA] -> GSI 22 (level,
>>>>>>>> low) -> IRQ 22
>>>>>>>> <7>HDA Intel 0000:00:0e.1: setting latency timer to 64
>>>>>>>> Driver: "HDA Intel"
>>>>>
>>>>> What I'd try first is to pass enable_msi=0 option.
>>>>
>>>> Just to be sure -- it's an option for snd-hda-intel module.
>>>>
>>>>
>>>> Takashi
>>>>
>>>
>>> I passed "modprobe snd-hda-intel enable_msi=0" on the kernel command
>>> line,
>
> Oh, I overlooked this text. Of course, this can't work :)
>
> "modprobe..." isn't for the kernel command line but for modprobe
> configs, usually specified in /etc/modprobe.d/* file.
>
I had already tried that... it locks up at the same point also with
"enable_msi=1".
tindog:/etc/modprobe.d # less 50-sound.conf

options snd slots=snd-hda-intel,enable_msi=0
# mDsH.vLXC8EvZgR7:MCP55 High Definition Audio
alias snd-card-0 snd-hda-intel

> And... is this report for 2.6.32 or for 2.6.33?
> If it's with 2.6.32, enable_msi=1 may help instead.
>
>
The motherboard giving the problem is the Asus M2N32-SLI deluxe.
00:0e.1 Audio device: nVidia Corporation MCP55 High Definition Audio
(rev a2)

No such problem with the Asus CROSSHAIR II FORMULA motherboard which
also has the
00:07.0 Audio device: nVidia Corporation MCP72XE/MCP72P/MCP78U/MCP78S
High Definition Audio (rev a1)

For any kernel >2.6.32-git1 it hangs, i.e 2.6.32-git2 to 2.6.33-rc5.
Disabling the sound chip in the BIOS, they all boot.
tindog:/etc/modprobe.d # uname -r
2.6.32-git1-smp
tindog:/etc/modprobe.d # l /dev/dsp*
crw-rw-rw- 1 root audio 14, 3 Jan 26 11:46 /dev/dsp
crw-rw-rw- 1 root audio 14, 35 Jan 26 11:46 /dev/dsp2

> Takashi
>
Regards
Sid.
--
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

==============================================================================
TOPIC: : Sparc build fix
http://groups.google.com/group/linux.kernel/t/5b7df0e906019615?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 4:20 am
From: David Miller

Please pull to get this sparc64 UP build fix.

Thanks!

The following changes since commit 9a3cbe3265c7714e8ee423feb6e27a080af79608:
Linus Torvalds (1):
Merge branch 'for_linus' of git://git.kernel.org/.../tytso/ext4

are available in the git repository at:

master.kernel.org:/pub/scm/linux/kernel/git/davem/sparc-2.6.git master

David S. Miller (1):
sparc64: Fix UP build.

arch/sparc/kernel/irq_64.c | 6 ++----
1 files changed, 2 insertions(+), 4 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

==============================================================================
TOPIC: regulator: Add WM8994 regulator support
http://groups.google.com/group/linux.kernel/t/41e093ee84ce44c6?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 4:20 am
From: Liam Girdwood

On Mon, 2010-01-25 at 19:41 +0000, Mark Brown wrote:
> The WM8994 contains two LDOs with mixed hardware/software control to
> minimise the number of external supplies required while delivering
> optimal voltages to minimise power consumption.
>
> Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>

Applied to for-2.6.34

Will move to next when mfd parts are in next.

Thanks

Liam

==============================================================================
TOPIC: regulator: trivial: fix typos in user-visible Kconfig text
http://groups.google.com/group/linux.kernel/t/395977c92c91343c?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 4:20 am
From: Liam Girdwood

On Mon, 2010-01-25 at 21:14 -0700, Alex Chiang wrote:
> Fix Kconfig text for some Wolfson Micro devices.
>
> Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>
> Signed-off-by: Alex Chiang <achiang@hp.com>

Applied.

Thanks.

Liam

==============================================================================
TOPIC: : Sparc
http://groups.google.com/group/linux.kernel/t/f43dd9e158765728?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 4:20 am
From: David Miller

From: Alexander Beregalov <a.beregalov@gmail.com>
Date: Tue, 26 Jan 2010 12:23:06 +0300

> Hi David
>
>> 7) IRQ ->set_affinity() using wrong cpu mask, thanks to Ben H. for
>> noticing.
>> sparc64: Fix IRQ ->set_affinity() methods.
>
> This commit breaks UP build

Sorry, I'll fix this, thanks for the report.

sparc64: Fix UP build.

Can't reference irq_desc[].affinity when !SMP.

Reported-by: Alexander Beregalov <a.beregalov@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/arch/sparc/kernel/irq_64.c b/arch/sparc/kernel/irq_64.c
index f2179cc..e1cbdb9 100644
--- a/arch/sparc/kernel/irq_64.c
+++ b/arch/sparc/kernel/irq_64.c
@@ -268,10 +268,8 @@ static int irq_choose_cpu(unsigned int virt_irq, const struct cpumask *affinity)
return cpuid;
}
#else
-static int irq_choose_cpu(unsigned int virt_irq, const struct cpumask *affinity)
-{
- return real_hard_smp_processor_id();
-}
+#define irq_choose_cpu(virt_irq, affinity) \
+ real_hard_smp_processor_id()

twitter

Tuesday, January 26, 2010

linux.kernel - 26 new messages in 16 topics - digest

0 Comments:

Post a Comment

About Me

Previous Posts