On Sat, Mar 30, 2013 at 02:05:43AM +0530, Vinod Koul wrote:
> On Wed, Mar 27, 2013 at 10:57:57AM +0200, Andy Shevchenko wrote:
> > + * @dev: struct device to get DMA request from
> > + * @index: index of FixedDMA descriptor for @dev
> > + *
> > + * Returns pointer to appropriate dma channel on su
On Sat, Mar 09, 2013 at 07:16:46PM +0100, Lars-Peter Clausen wrote:
> i2c_del_adapter() always returns 0. So all checks testing whether it will be
> non zero will always evaluate to false and the conditional code is dead code.
> This patch updates all callers of i2c_del_mux_adapter() to ignore the
On Sat, Mar 09, 2013 at 07:16:43PM +0100, Lars-Peter Clausen wrote:
> Currently i2c_del_adapter() returns 0 on success and potentially an error code
> on failure. Unfortunately this doesn't mix too well with the Linux device
> driver
> model. An i2c_adapter is usually registered in a drivers probe
Hi all,
i am a newer. I am eager to know whether Hard Disk Driver use Device Model?
I will appreciate any help.
--
Sincerely,
Ren Zhen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http:/
Hi Tejun,
On 03/30/2013 08:54 AM, Tejun Heo wrote:
> show_regs() is inherently arch-dependent but it does make sense to
> print generic debug information and some archs already do albeit in
> slightly different forms. This patch introduces a generic function to
> print debug information from show
On Sat, Mar 30, 2013 at 12:10 PM, Linus Torvalds
wrote:
>> Another shot in
>> the dark, I had this weird message when trying to build gcc:
>> semop(2): encountered an error: Identifier removed
>
> This came from the gcc build?
yes, very early in the build process, IIRC this line was repeated a
fe
Make v6_voltages_uv to be const unsigned int.
Signed-off-by: Axel Lin
---
drivers/regulator/max1586.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/regulator/max1586.c b/drivers/regulator/max1586.c
index 8c5a54f..dac0490 100644
--- a/drivers/regulator/max1586.c
+
On 03/29/2013 02:02 AM, Ivan Djelic wrote:
On Thu, Mar 28, 2013 at 10:23:01PM +, Aaron Williams wrote:
Hi all,
I am trying to clean up our OCTEON NAND flash driver in the Linux kernel
and enable support for multi-bit ECC using BCH and am having some
issues. I am able to successfully work wi
The logic to check return value of clk_enable() is reversed, thus
when clk_enable() passes PWMCR_PWM_ENABLE bit is not set. Fix it.
Signed-off-by: Axel Lin
---
drivers/pwm/pwm-spear.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/pwm/pwm-spear.c b/drivers/pwm
On 03/30/2013 07:57 AM, Tejun Heo wrote:
> Both dump_stack() and show_stack() are currently implemented by each
> architecture. show_stack(NULL, NULL) dumps the backtrace for the
> current task as does dump_stack(). On some archs, dump_stack() prints
> extra information - pid, utsname and so on -
On Fri, Mar 29, 2013 at 9:33 PM, Emmanuel Benisty wrote:
>
> I just tried the 7 original patches + the 2 one liners from -next +
> modified Linus' patch (attached)
.. that patch looks fine.
> on the top of 3.9-rc4 using
> PREEMPT_NONE and after moving sem_lock(sma, NULL, -1) as explained
> above
On Sat, Mar 30, 2013 at 10:46 AM, Linus Torvalds
wrote:
> On Fri, Mar 29, 2013 at 8:02 PM, Emmanuel Benisty wrote:
>>
>> Then I start building a random package and the problems start. They
>> may also happen without compiling but this seems to trigger the bug
>> quite quickly.
>
> I suspect it's
On 30 March 2013 09:16, Axel Lin wrote:
> The logic to check return value of clk_enable() is reversed, thus
> when clek_enable() success PWMCR_PWM_ENABLE bit is never set. Fix it.
s/clek/clk
And write it as:
The logic to check return value of clk_enable() is reversed, thus
when clk_enable() pas
The logic to check return value of clk_enable() is reversed, thus
when clek_enable() success PWMCR_PWM_ENABLE bit is never set. Fix it.
Signed-off-by: Axel Lin
---
drivers/pwm/pwm-spear.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/pwm/pwm-spear.c b/drivers/pwm
On Fri, Mar 29, 2013 at 8:02 PM, Emmanuel Benisty wrote:
>
> Then I start building a random package and the problems start. They
> may also happen without compiling but this seems to trigger the bug
> quite quickly.
I suspect it's about preemption, and the build just results in enough
scheduling
On 30 March 2013 07:47, Rafael J. Wysocki wrote:
> On Wednesday, March 27, 2013 09:28:56 PM Viresh Kumar wrote:
>> To test these over linux-next you need to revert following first:
>> db9baec cpufreq: Get rid of "struct global_attr"
>> 86bd6f0 cpufreq: governor: Implement per policy instances of
From: Tejun Heo
Date: Fri, 29 Mar 2013 20:24:45 -0700
> show_regs() is inherently arch-dependent but it does make sense to
> print generic debug information and some archs already do albeit in
> slightly different forms. This patch introduces a generic function to
> print debug information from
On 29 March 2013 23:10, Tejun Heo wrote:
> So the scheduler does know what it's doing after all, which is a nice
> news. Given the result, the best thing to do would be somehow marking
> these workqueues as unbound for powersaving?
Yes. I am going to do it soon.
--
To unsubscribe from this list:
From: Tejun Heo
Date: Fri, 29 Mar 2013 19:27:06 -0700
> Both dump_stack() and show_stack() are currently implemented by each
> architecture. show_stack(NULL, NULL) dumps the backtrace for the
> current task as does dump_stack(). On some archs, dump_stack() prints
> extra information - pid, utsn
From: Tejun Heo
Date: Fri, 29 Mar 2013 19:27:05 -0700
> show_stack(current or NULL, NULL) is used by arch-independent code to
> dump backtrace of the current task; however, sparc32 show_stack()
> doesn't implement it and wouldn't print any backtrace when NULL @_ksp
> is specfied.
>
> Make show_s
show_regs() is inherently arch-dependent but it does make sense to
print generic debug information and some archs already do albeit in
slightly different forms. This patch introduces a generic function to
print debug information from show_regs() so that different archs print
out the same informati
Hi Davidlohr,
On Sat, Mar 30, 2013 at 9:08 AM, Davidlohr Bueso wrote:
> Not sure which one liner you refer to, but, if you haven't already done
> so, please try with these fixes (queued in linux-next):
>
> http://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=a9cead0347283f3e
Writeback has been recently converted to use workqueue instead of its
private thread pool implementation. One negative side effect of this
conversion is that there's no easy to tell which backing device a
writeback work item was working on at the time of task dump, be it
sysrq-t, BUG, WARN or what
One of the problems that arise when converting dedicated custom
threadpool to workqueue is that the shared worker pool used by
workqueue anonimizes each worker making it more difficult to identify
what the worker was doing on which target from the output of sysrq-t
or debug dump from oops, BUG() an
Implement probe_kthread_data() which returns kthread_data if
accessible. The function is equivalent to kthread_data() except that
the specified @task may not be a kthread or its vfork_done is already
cleared rendering struct kthread inaccessible. In the former case,
probe_kthread_data() may retur
Hello,
One of the problems that arise when converting dedicated custom
threadpool to workqueue is that the shared worker pool used by
workqueue anonimizes each worker making it more difficult to identify
what the worker was doing on which target from the output of sysrq-t
or debug dump from oops,
On 2013年03月29日 21:51, Corey Minyard wrote:
> Yes, this is correct, I've pulled it into my tree.
thanks.
:-)
--
Chen Gang
Asianux Corporation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info
On Fri, 2013-03-29 at 19:09 -0700, Linus Torvalds wrote:
> On Fri, Mar 29, 2013 at 6:36 PM, Emmanuel Benisty wrote:
> >
> > I had to slightly modify the patch since it wouldn't match the changes
> > introduced by 7-7-ipc-sem-fine-grained-locking-for-semtimedop.patch,
> > hope that was the right th
platform_device_alloc could failed and return NULL,
we should check this before call platform_device_put.
Signed-off-by: Wang YanQing
---
drivers/video/uvesafb.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/video/uvesafb.c b/drivers/video/uvesafb.c
index 2f8f82d.
Both dump_stack() and show_stack() are currently implemented by each
architecture. show_stack(NULL, NULL) dumps the backtrace for the
current task as does dump_stack(). On some archs, dump_stack() prints
extra information - pid, utsname and so on - in addition to the
backtrace while the two are i
show_stack(current or NULL, NULL) is used to print the backtrace of
the current task. As trace beyond the function itself isn't of much
interest to anyone, don't show it by determining sp and bp in
show_stack()'s frame and passing them to show_stack_log_lvl().
This brings show_stack(NULL, NULL)'s
show_regs() is inherently arch-dependent but it does make sense to
print generic debug information and some archs already do albeit in
slightly different forms. This patch introduces a generic function to
print debug information from show_regs() so that different archs print
out the same informati
x86 and ia64 can acquire extra hardware identification information
from DMI and print it along with task dumps; however, the usage isn't
consistent.
* x86 show_regs() collects vendor, product and board strings and print
them out with PID, comm and utsname. Some of the information is
printed a
show_stack(current or NULL, NULL) is used by arch-independent code to
dump backtrace of the current task; however, sparc32 show_stack()
doesn't implement it and wouldn't print any backtrace when NULL @_ksp
is specfied.
Make show_stack() acquire and use %fp if @tsk is NULL or current and
@_ksp is N
Hello,
There are multiple ways a task can be dumped - explicit call to
dump_stack(), triggering WARN() or BUG(), through sysrq-t and so on.
Most of what gets printed is upto each architecture and the current
state is not particularly pretty. Different pieces of information are
presented different
On Wednesday, March 27, 2013 09:28:56 PM Viresh Kumar wrote:
> Hi Guys,
>
> All patches are pushed here for others to apply (you can apply from mail to):
> http://git.linaro.org/gitweb?p=people/vireshk/linux.git;a=shortlog;h=refs/heads/governor-per-policy-v4
>
> Currently, there can't be multiple
On Fri, Mar 29, 2013 at 6:36 PM, Emmanuel Benisty wrote:
>
> I had to slightly modify the patch since it wouldn't match the changes
> introduced by 7-7-ipc-sem-fine-grained-locking-for-semtimedop.patch,
> hope that was the right thing to do. So, what I tried was: original 7
> patches + the one lin
On Sat, 2013-03-30 at 08:36 +0700, Emmanuel Benisty wrote:
> Hi Linus,
>
> On Sat, Mar 30, 2013 at 6:16 AM, Linus Torvalds
> wrote:
> > Emmanuel, can you try the attached patch? I think it applies cleanly
> > on top of the scalability series too without any changes, but I didn't
> > check if the
Hi Linus,
On Sat, Mar 30, 2013 at 6:16 AM, Linus Torvalds
wrote:
> Emmanuel, can you try the attached patch? I think it applies cleanly
> on top of the scalability series too without any changes, but I didn't
> check if the patches perhaps changed some of the naming or something.
I had to slight
On Fri, 29 Mar 2013, Geoff Levand wrote:
> Hi Alan,
>
> > Actually, I think this is not necessary. Instead those three glue
> > files ought to be changed. They should not need to call
> > ehci_shutdown() directly.
>
> I sent out a separate patch that removes the ehci_shutdown()
> call in ps3_e
On Fri, Mar 29, 2013 at 09:03:44PM +, Mark Brown wrote:
> For code clarity after implementing block writes split out the raw and
> non-raw I/O sync implementations.
>
> Signed-off-by: Mark Brown
Reviewed-by: Dimitris Papastamos
--
To unsubscribe from this list: send the line "unsubscribe li
On Fri, Mar 29, 2013 at 09:03:45PM +, Mark Brown wrote:
> When syncing blocks of data using raw writes combine the writes into a
> single block write, saving us bus overhead for setup, addressing and
> teardown.
>
> Currently the block write is done unconditionally as it is expected that
> har
On Fri, Mar 29, 2013 at 09:03:43PM +, Mark Brown wrote:
> The idea of holding blocks of registers in device format is shared between
> at least rbtree and lzo cache formats so split out the loop that does the
> sync from the rbtree code so optimisations on it can be reused.
>
> Signed-off-by:
On Fri, Mar 29, 2013 at 09:03:42PM +, Mark Brown wrote:
> The idea of maintaining a bitmap of present registers is something that
> can usefully be used by other cache types that maintain blocks of cached
> registers so move the code out of the rbtree cache and into the generic
> regcache code.
On Fri, Mar 29, 2013 at 6:12 PM, Rafael J. Wysocki wrote:
> On Friday, March 29, 2013 06:02:45 PM Yinghai Lu wrote:
>> On Fri, Mar 29, 2013 at 5:36 PM, Rafael J. Wysocki wrote:
>> >> - /* Run _OSC query for all possible controls. */
>> >> - capbuf[OSC_CONTROL_TYPE] = OSC_P
On Friday, March 29, 2013 06:02:45 PM Yinghai Lu wrote:
> On Fri, Mar 29, 2013 at 5:36 PM, Rafael J. Wysocki wrote:
> >> - /* Run _OSC query for all possible controls. */
> >> - capbuf[OSC_CONTROL_TYPE] = OSC_PCI_CONTROL_MASKS;
> >> + /* Run _OSC query only with
On Fri, Mar 29, 2013 at 5:36 PM, Rafael J. Wysocki wrote:
>> - /* Run _OSC query for all possible controls. */
>> - capbuf[OSC_CONTROL_TYPE] = OSC_PCI_CONTROL_MASKS;
>> + /* Run _OSC query only with existing controls. */
>> + capbuf[OSC_CONTROL_TYPE]
On 2013/3/29 18:48, Glauber Costa wrote:
> On 03/29/2013 02:28 PM, Li Zefan wrote:
>> The memcg is not referenced, so it can be destroyed at anytime right
>> after we exit rcu read section, so it's not safe to access it.
>>
>> To fix this, we call css_tryget() to get a reference while we're still
>
Hi Alan,
> Actually, I think this is not necessary. Instead those three glue
> files ought to be changed. They should not need to call
> ehci_shutdown() directly.
I sent out a separate patch that removes the ehci_shutdown()
call in ps3_ehci_remove(). I tested it by removing and
installing the
On Wednesday, March 27, 2013 09:28:58 PM Yinghai Lu wrote:
> Found problem on system that firmware that could handle pci aer.
> Firmware get error reporting after pci injecting error, before os boots.
> But after os boots, firmware can not get report anymore, even pci=noaer
> is passed.
>
> Root c
On Fri, Mar 29, 2013 at 3:22 PM, Bjorn Helgaas wrote:
> [+cc Rafael, just FYI since it involves PNP resources]
>
> On Wed, Mar 27, 2013 at 10:28 PM, Yinghai Lu wrote:
>> Mathhew reported kernels fail the pci_eisa probe and are later successful
>> with the virtual_eisa_root_init force probe withou
On 03/27/2013 01:03 AM, Minchan Kim wrote:
On Tue, Mar 26, 2013 at 05:26:04PM -0700, John Stultz wrote:
Sorting out how to handle vrange() calls that cross both anonymous
and file vmas will be interesting, and may have some of the
drawbacks of the vma based approach, but I think it will still be
Some pins on the i.mx23 and i.mx28 are missing pull-ups, document that
oddity because it was difficult to know the expected behaviour.
Signed-off-by: Alexandre Belloni
---
I don't think it is necessary to list the pins with the missing pull ups in
that file but we may want to explicitly direct t
I'm surprised that patch would have much effect in either direction;
it changes the amortization of accounting, but not the actual numbers
-- especially for a persistent load. We'll take a look.
On Fri, Mar 29, 2013 at 4:20 PM, Tim Chen wrote:
> During our testings of 3.8 kernel, we noticed th
On Mon, Mar 25, 2013 at 02:24:22PM +0100, Lars-Peter Clausen wrote:
> list_for_each_entry is able to handle empty lists just fine, there is no need
> to make sure that the list is non empty.
>
> Signed-off-by: Lars-Peter Clausen
Applied thanks
> ---
> drivers/dma/of-dma.c | 5 -
> 1 file cha
On Fri, Mar 29, 2013 at 08:34:43PM +, Ken Moffat wrote:
> On Fri, Mar 29, 2013 at 06:31:03PM +, Ken Moffat wrote:
> I've no idea about the details, but it looks to me as if smartd is
> still getting different values returned to it. The capability check
> normally was ok (silent), the aut
During our testings of 3.8 kernel, we noticed that after the patch
Revert "sched: Update_cfs_shares at period edge" (commit 17bc14b7),
the load between the sockets or larger system can have
large imbalance. For example, for a 4 socket Westmere-EX
(10 cores/socket), we notice the loadings betw
On Fri, Mar 29, 2013 at 2:12 PM, Linus Torvalds
wrote:
>
> I dunno. I'm still not sure this is triggerable, but it looks bad. But
> both the semaphore case and the msg cases seem to be solvable by
> moving the unlock down, and shm seem to have no getref/putref users to
> race with, so this (whites
On Mon, Mar 25, 2013 at 01:23:52PM +0100, Lars-Peter Clausen wrote:
> The 'mask' parameter is not modified in __dma_request_channel and really
> shouldn't be. Make this explicit by making the parameter const.
>
> Signed-off-by: Lars-Peter Clausen
Applied thanks.
I manually fixed a conflict in dm
Commit a07613a54d700a974f3a4a657da78ef5d097315d ("Merge branch
'samsung/dt' into samsung/cleanup") added this line to
arch/arm/mach-s3c64xx/Makefile:
obj-$(CONFIG_S3C64XX_DEV_SPI) += dev-spi.o
But at that time CONFIG_S3C64XX_DEV_SPI wasn't a valid Kconfig macro
anymore and arch/arm/mach-
>From e4bc30ced68420e89d264a26e10d450765a747ed Mon Sep 17 00:00:00 2001
From: Tejun Heo
Date: Fri, 29 Mar 2013 15:42:27 -0700
Currently, an unbound workqueue has single current, or first, pwq
(pool_workqueue) to which all new work items are queued. This often
isn't optimal on NUMA machines as wo
Hi!
> >> This takes care of the "make dtbs" case (or just "make" case), but not
> >> when you build a specific target.
> >
> > I guess to really solve this, we need the following changes:
> >
> > In the all kernels:
> >
> > For both arch/*/boot and arch/*/boot/dts: clean removes *.dtb
> >
> > In k
Hi Mike,
On Tue, Mar 26, 2013 at 07:18:44PM -0700, Mike Turquette wrote:
> Quoting Sören Brinkmann (2013-03-25 17:03:24)
> > On Mon, Mar 25, 2013 at 05:33:10PM -0600, Stephen Warren wrote:
> > > On 03/25/2013 12:27 PM, Sören Brinkmann wrote:
> > > > Hi Stephen,
> > > >
> > > > On Mon, Mar 25, 201
On Saturday, March 30, 2013 12:27:34 AM Stratos Karafotis wrote:
> On 02/22/2013 03:56 AM, Viresh Kumar wrote:
> > On 21 February 2013 23:09, Stratos Karafotis wrote:
> >
> >> Signed-off-by: Stratos Karafotis
> >
> > Acked-by: Viresh Kumar
> >
>
> Hi Rafael,
>
> In case you are interested in
On Fri, Mar 29, 2013 at 12:10:37PM -0700, Yinghai Lu wrote:
> On Fri, Mar 29, 2013 at 11:10 AM, Bjorn Helgaas wrote:
> > On Wed, Mar 27, 2013 at 10:28 PM, Yinghai Lu wrote:
> >> Matthem found that 3.8.3 is having problems with an old (ancient)
> >> PCI-to-EISA bridge, the Intel 82375. It worked w
On 02/22/2013 03:56 AM, Viresh Kumar wrote:
> On 21 February 2013 23:09, Stratos Karafotis wrote:
>
>> Signed-off-by: Stratos Karafotis
>
> Acked-by: Viresh Kumar
>
Hi Rafael,
In case you are interested in this patch I rebased it to the latest
linux-pm/bleeding-edge.
Thanks,
Stratos
-
[+cc Rafael, just FYI since it involves PNP resources]
On Wed, Mar 27, 2013 at 10:28 PM, Yinghai Lu wrote:
> Mathhew reported kernels fail the pci_eisa probe and are later successful
> with the virtual_eisa_root_init force probe without slot0.
>
> The reason for that is: pnp probing is early than
> From: Dan Magenheimer
> Sent: Wednesday, March 27, 2013 3:42 PM
> To: Seth Jennings; Konrad Wilk; Minchan Kim; Bob Liu; Robert Jennings; Nitin
> Gupta; Wanpeng Li; Andrew
> Morton; Mel Gorman
> Cc: linux...@kvack.org; linux-kernel@vger.kernel.org
> Subject: zsmalloc/lzo compressibility vs entrop
On Wednesday, March 27, 2013 10:58:02 AM Andy Shevchenko wrote:
> In Lynxpoint we have to enable clock per each LPSS device. That's why we have
> to enumerate them from drivers/acpi/acpi_lpss.c. The DMA controller is one of
> such devices.
We'll do that after we've sorted out [5/6].
Thanks,
Rafae
On Wednesday, March 27, 2013 10:58:01 AM Andy Shevchenko wrote:
> When device uses the fixed clock and has no private space of LTR, we have to
> create main LPSS clock and register platform device. This is normally a case
> for LPSS DMA controller.
>
> Signed-off-by: Andy Shevchenko
> ---
> driv
On Mon, Mar 25, 2013 at 02:16:51PM +0100, Lars-Peter Clausen wrote:
> This patch adds a new generic of dma xlate callback function which will match
> a
> channel by its id.
how will the client know which "id" to request?
>
> Signed-off-by: Lars-Peter Clausen
> ---
> drivers/dma/of-dma.c | 4
Add MCE decoder to MCE decode chain in probe routine instead
of in init routine so that handler is not called unless the
driver is indeed running on SandyBridge.
Signed-off-by: Khalid Aziz
---
drivers/edac/sb_edac.c |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/dri
Commit 650e3f0d66ade2a614d854765dae3bbc9a87f58d ("ARM: msm: Consolidate
and move DEBUG_LL to DEBUG_LL choice") renamed the Kconfig symbols
MSM_DEBUG_UART1, MSM_DEBUG_UART2, and MSM_DEBUG_UART3 to
DEBUG_MSM_UART1, etc. It also added some references to
CONFIG_DEBUG_MSM_UART1, etc. It did not, however
On Wed, Mar 27, 2013 at 10:57:59AM +0200, Andy Shevchenko wrote:
> Since we have CSRT only to get additional DMA controller resources, let's get
> rid of drivers/acpi/csrt.c and move its logic inside ACPI DMA helpers code.
>
> Signed-off-by: Andy Shevchenko
> Signed-off-by: Mika Westerberg
> Ack
From: Rafael J. Wysocki
The Adam Belay's e-mail address in MAINTAINERS under PNP SUPPORT
is not valid any more and I started to maintain that code in the
meantime as a matter of fact, so list myself as a maintainer of it
along with Bjorn and remove the Adam's entry from it.
Signed-off-by: Rafael
hfs_find_init() may fail with ENOMEM, but there are places,
where the returned value is not checked. The consequences can be
very unpleasant, e.g. kfree uninitialized pointer and
inappropriate mutex unlocking.
The patch adds checks for errors in hfs_find_init().
Found by Linux Driver Verification
Hello Florian,
On Tue, 26 Mar 2013 19:06:14 +0100
Florian Fainelli wrote:
...
> diff --git a/arch/powerpc/platforms/52xx/Kconfig
> b/arch/powerpc/platforms/52xx/Kconfig
> index 90f4496..65232cb 100644
> --- a/arch/powerpc/platforms/52xx/Kconfig
> +++ b/arch/powerpc/platforms/52xx/Kconfig
> @@ -3
On Fri, Mar 29, 2013 at 1:46 PM, Davidlohr Bueso wrote:
> Signed-off-by: Davidlohr Bueso
Reviewed-by: Michel Lespinasse
--
Michel "Walken" Lespinasse
A program is never fully debugged until the last user dies.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the b
On Friday, March 29, 2013 09:05:35 AM Sarah Sharp wrote:
> On Fri, Mar 29, 2013 at 04:05:54PM +0100, Martin Mokrejs wrote:
> > [ 36.594171] xhci_hcd :0b:00.0: xhci_suspend: stopping port polling.
> > [ 36.594202] xhci_hcd :0b:00.0: // Setting command ring address to
> > 0xd6007001
> >
On Fri, Mar 29, 2013 at 1:46 PM, Davidlohr Bueso wrote:
> Account for the rbtree having 2**bh(v)-1 internal nodes.
>
> While this can be seen as a consequence of other checks, Michel states
> that it nicely sums up what the other properties are for.
>
> Signed-off-by: Davidlohr Bueso
Reviewed-b
On Friday, March 29, 2013 04:05:54 PM Martin Mokrejs wrote:
> Hi,
> I applied this patches over 3.8.3 hoping it will fix my issue under
> thread: "Re: 3.8.2: xhci port is dead until pcieport PME# goes to disabled"
> but unfortunately, it is even worse! Now, although lsusb -v nor lsusb -vv do
> wa
On Fri, Mar 29, 2013 at 1:41 PM, Linus Torvalds
wrote:
>
> The alternative would be to make sure the thing is always locked (and
> in a rcu-read-safe region) before putref/getref. The only place (apart
> from the initial allocation, which doesn't matter, because nothing can
> see if itf that path
For code clarity after implementing block writes split out the raw and
non-raw I/O sync implementations.
Signed-off-by: Mark Brown
---
drivers/base/regmap/regcache.c | 64 +---
1 file changed, 53 insertions(+), 11 deletions(-)
diff --git a/drivers/base/regm
The idea of maintaining a bitmap of present registers is something that
can usefully be used by other cache types that maintain blocks of cached
registers so move the code out of the rbtree cache and into the generic
regcache code.
Refactor the interface slightly as we go to wrap the set bit and e
The idea of holding blocks of registers in device format is shared between
at least rbtree and lzo cache formats so split out the loop that does the
sync from the rbtree code so optimisations on it can be reused.
Signed-off-by: Mark Brown
---
drivers/base/regmap/internal.h|3 +++
dri
When syncing blocks of data using raw writes combine the writes into a
single block write, saving us bus overhead for setup, addressing and
teardown.
Currently the block write is done unconditionally as it is expected that
hardware which has a register format which can support raw writes will
supp
On Wed, Mar 27, 2013 at 10:57:57AM +0200, Andy Shevchenko wrote:
> + * @dev: struct device to get DMA request from
> + * @index: index of FixedDMA descriptor for @dev
> + *
> + * Returns pointer to appropriate dma channel on success or NULL on error.
> + */
> +struct dma_chan *acpi_dma_reques
Signed-off-by: Paul Bolle
---
Untested. As this typo was introduced in v3.3, with commit
9d670280908013004f173b2b86414d9b6918511b ("powerpc: Split ICSWX ACOP and
PID processing"), which actually added PPC_ICSWX_PID, this surely needs
testing.
arch/powerpc/mm/icswx.c | 2 +-
1 file changed, 1 ins
As part of updating the vmbus protocol, the function hv_need_to_signal()
was introduced. This functions helps optimize signalling from guest to
host. The newly added memory barrier is needed to ensure that we correctly
decide when to signal the host.
Signed-off-by: K. Y. Srinivasan
Reviewed-by: H
Account for the rbtree having 2**bh(v)-1 internal nodes.
While this can be seen as a consequence of other checks, Michel states
that it nicely sums up what the other properties are for.
Signed-off-by: Davidlohr Bueso
---
lib/rbtree_test.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions
Signed-off-by: Davidlohr Bueso
---
lib/rbtree_test.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lib/rbtree_test.c b/lib/rbtree_test.c
index 9951503..122f02f 100644
--- a/lib/rbtree_test.c
+++ b/lib/rbtree_test.c
@@ -149,7 +149,7 @@ static void check_augmented(int nr_n
On Fri, Mar 29, 2013 at 9:17 AM, Dave Jones wrote:
>
> Now that I have that reverted, I'm not seeing msgrcv traces any more, but
> I've started seeing this..
>
> general protection fault: [#1] PREEMPT SMP DEBUG_PAGEALLOC
> RIP: 0010:[] [] free_msg+0x2b/0x40
> Call Trace:
> [] freeque+0xcf/0
Signed-off-by: Paul Bolle
---
Untested. I'm far from sure what the comment tries to say, even after
applying this patch. At least it now uses an actual Kconfig macro! But
perhaps just dropping the CONFIG_ prefix makes more sense.
arch/arm/mach-omap2/pm44xx.c | 4 ++--
1 file changed, 2 insertion
On Fri, Mar 29, 2013 at 06:31:03PM +, Ken Moffat wrote:
> On Thu, Mar 28, 2013 at 10:56:49PM -0700, Gwendal Grignou wrote:
>
> Hmm, not sure. Smartd started and was happy to monitor the disk,
> but I got two new messages between 'found in smartd database' and
> 'is SMART capable. Adding to "
Add generic cpu_idle support
sparc32:
- replace call to cpu_idle() with cpu_startup_entry()
- add arch_cpu_idle()
sparc64:
- smp_callin() includes cpu_startup_entry() call so we can
skip calling cpu_idle from assembler
- add arch_cpu_idle_enter() and arch_cpu_idle_dead()
Signed-off-by: Sam Rav
On Thu, 28 Mar 2013, Arnd Bergmann wrote:
> Like the EHCI driver, OHCI supports a large number of different platform
> glue drivers by directly including them, which causes problems with
> conflicting macro definitions in some cases. As more ARM architecture
> specific back-ends are required to co
Occassionaly on a DL380 G4 the guest would crash quite early with this:
(XEN) d244:v0: unhandled page fault (ec=0003)
(XEN) Pagetable walk from 84dc7000:
(XEN) L4[0x1ff] = c3f18067 1789
(XEN) L3[0x1fe] = c3f14067 178d
(XEN) L2[0x026] = dc8
On Thu, 28 Mar 2013, Arnd Bergmann wrote:
> From: Manjunath Goudar
>
> Separate the Qualcomm QSD/MSM on-chip host controller driver from
> ehci-hcd host code so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM;
> however, note that
On Thu, 28 Mar 2013, Arnd Bergmann wrote:
> From: Manjunath Goudar
>
> Separate the Atmel host controller driver from ehci-hcd host code
> so that it can be built as a separate driver module.
> This work is part of enabling multi-platform kernels on ARM;
> however, note that other changes are st
On Fri, 29 Mar 2013, Minchan Kim wrote:
> On Thu, Mar 28, 2013 at 11:19:12AM -0700, Dan Magenheimer wrote:
> > > From: Minchan Kim [mailto:minc...@kernel.org]
> > > On Wed, Mar 27, 2013 at 03:24:00PM -0700, Dan Magenheimer wrote:
> > > > > From: Hugh Dickins [mailto:hu...@google.com]
> > > > > Subj
1 - 100 of 357 matches
Mail list logo
