* Re: linux-next: manual merge of the powerpc tree with the arm tree
From: Benjamin Herrenschmidt @ 2012-03-09 3:13 UTC (permalink / raw)
To: Russell King
Cc: Stephen Rothwell, Michael Neuling, Paul Mackerras, linuxppc-dev,
linux-next, linux-kernel, Rob Herring
In-Reply-To: <20120309003937.GC8680@flint.arm.linux.org.uk>
On Fri, 2012-03-09 at 00:39 +0000, Russell King wrote:
> On Fri, Mar 09, 2012 at 10:35:46AM +1100, Benjamin Herrenschmidt wrote:
> > Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
> > I remove it, then I get Kconfig warnings:
> >
> > warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies
> > (HAVE_GENERIC_HARDIRQS && HAVE_SPARSE_IRQ)
>
> Do you have commit 2ed86b16eabe4efbf80cc725a8cbb5310746a2fc ?
Nope, Grant patch didn't mention a dependency.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH] ARM: pxa: fix regulator related build fail in magician_defconfig
From: Paul Parsons @ 2012-03-09 2:47 UTC (permalink / raw)
To: broonie, haojian.zhuang; +Cc: linux-arm-kernel, linux-next, Paul Gortmaker
In-Reply-To: <1331242494-3157-1-git-send-email-paul.gortmaker@windriver.com>
Thanks Paul.
The hx4700 patch works for me on linux-3.3.0-rc6.
I'm not able to test the magician patch.
Tested-by: Paul Parsons <lost.distance@yahoo.com>
--- On Thu, 8/3/12, Paul Gortmaker <paul.gortmaker@windriver.com> wrote:
> commit
> 737f360d5bef5e01c6cfa755dca0b449a154c1e0 (linux-next)
>
> "regulator: Remove support for supplies specified by
> struct device"
>
> deletes the field from the struct, but this platform was
> still trying
> to set those fields. Convert them to use the
> REGULATOR_SUPPLY macro.
>
> arch/arm/mach-pxa/magician.c:581: error: unknown field 'dev'
> specified in initializer
> arch/arm/mach-pxa/magician.c:581: warning: initialization
> from incompatible pointer type
> arch/arm/mach-pxa/magician.c:585: error: unknown field 'dev'
> specified in initializer
> arch/arm/mach-pxa/magician.c:585: warning: initialization
> from incompatible pointer type
>
> arch/arm/mach-pxa/hx4700.c:683: error: unknown field 'dev'
> specified in initializer
> arch/arm/mach-pxa/hx4700.c:683: warning: initialization from
> incompatible pointer type
> arch/arm/mach-pxa/hx4700.c:687: error: unknown field 'dev'
> specified in initializer
> arch/arm/mach-pxa/hx4700.c:687: warning: initialization from
> incompatible pointer type
>
> Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> ---
>
> [v3: fix arg2 in REGULATOR_SUPPLY to have correct names ]
>
> diff --git a/arch/arm/mach-pxa/hx4700.c
> b/arch/arm/mach-pxa/hx4700.c
> index f2c23ea..b6a338b 100644
> --- a/arch/arm/mach-pxa/hx4700.c
> +++ b/arch/arm/mach-pxa/hx4700.c
> @@ -679,14 +679,8 @@ static struct platform_device
> power_supply = {
> */
>
> static struct regulator_consumer_supply bq24022_consumers[]
> = {
> - {
> - .dev =
> &gpio_vbus.dev,
> - .supply =
> "vbus_draw",
> - },
> - {
> - .dev =
> &power_supply.dev,
> - .supply = "ac_draw",
> - },
> + REGULATOR_SUPPLY("vbus_draw",
> "gpio-vbus"),
> + REGULATOR_SUPPLY("ac_draw",
> "pda-power"),
> };
>
> static struct regulator_init_data bq24022_init_data = {
> diff --git a/arch/arm/mach-pxa/magician.c
> b/arch/arm/mach-pxa/magician.c
> index 3d6baf9..1a18e63 100644
> --- a/arch/arm/mach-pxa/magician.c
> +++ b/arch/arm/mach-pxa/magician.c
> @@ -577,14 +577,8 @@ static struct platform_device
> power_supply = {
> */
>
> static struct regulator_consumer_supply bq24022_consumers[]
> = {
> - {
> - .dev =
> &gpio_vbus.dev,
> - .supply =
> "vbus_draw",
> - },
> - {
> - .dev =
> &power_supply.dev,
> - .supply = "ac_draw",
> - },
> + REGULATOR_SUPPLY("vbus_draw",
> "gpio-vbus"),
> + REGULATOR_SUPPLY("ac_draw",
> "pda-power"),
> };
>
> static struct regulator_init_data bq24022_init_data = {
> --
> 1.7.9.1
>
>
^ permalink raw reply
* linux-next: manual merge of the net-next tree with the powerpc tree
From: Stephen Rothwell @ 2012-03-09 2:36 UTC (permalink / raw)
To: David Miller, netdev
Cc: linux-next, linux-kernel, Benjamin Herrenschmidt, Paul Mackerras,
linuxppc-dev, Joe Perches
[-- Attachment #1: Type: text/plain, Size: 432 bytes --]
Hi all,
Today's linux-next merge of the net-next tree got a conflict in
drivers/net/ethernet/ibm/iseries_veth.c between commit e92a665949f6
("net: powerpc: remove the legacy iSeries ethernet driver") from the
powerpc tree and commit 41de8d4cff21 ("drivers/net: Remove alloc_etherdev
error messages") from the net-next tree.
I just removed the file.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* slave-dma/next - please drop "drivers/dma: linux/module.h included twice"
From: Paul Gortmaker @ 2012-03-09 2:36 UTC (permalink / raw)
To: vinod.koul; +Cc: linux-next
Hi Vinod,
Please drop commit 865d9438eb1f7670d2e88849f059db551b320887 from your
tree. There is a commit to delete all the duplicate module.h includes
tree-wide, and since your commit deletes one, and my commit deletes
the other, the final tree has no module.h which causes this fail:
http://kisskb.ellerman.id.au/kisskb/buildresult/5819464/
Thanks,
Paul.
^ permalink raw reply
* linux-next: manual merge of the slave-dma tree with Linus' tree
From: Stephen Rothwell @ 2012-03-09 2:25 UTC (permalink / raw)
To: Vinod Koul
Cc: linux-next, linux-kernel, Javi Merino, Russell King, Boojin Kim,
Kukjin Kim
[-- Attachment #1: Type: text/plain, Size: 1907 bytes --]
Hi Vinod,
Today's linux-next merge of the slave-dma tree got conflicts in
arch/arm/include/asm/hardware/pl330.h and arch/arm/common/pl330.c between
commits 4272f98a1ae8 ("ARM: 7164/3: PL330: Fix the size of the
dst_cache_ctrl field") and 46e33c606af8 ("ARM: 7326/2: PL330: fix null
pointer dereference in pl330_chan_ctrl()") from Linus' tree and commit
b7d861d93945 ("DMA: PL330: Merge PL330 driver into drivers/dma/") from
the slave-dma tree.
I removed the files and then applied changes from the patchs in Linus'
tree to drivers/dma/pl330.c.
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 9 Mar 2012 13:21:55 +1100
Subject: [PATCH] DMA: PL330: update for code movement
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/dma/pl330.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
index 7253d17..41ec06d 100644
--- a/drivers/dma/pl330.c
+++ b/drivers/dma/pl330.c
@@ -48,7 +48,7 @@ enum pl330_dstcachectrl {
DCCTRL1, /* Bufferable only */
DCCTRL2, /* Cacheable, but do not allocate */
DCCTRL3, /* Cacheable and bufferable, but do not allocate */
- DINVALID1 = 8,
+ DINVALID1, /* AWCACHE = 0x1000 */
DINVALID2,
DCCTRL6, /* Cacheable write-through, allocate on writes only */
DCCTRL7, /* Cacheable write-back, allocate on writes only */
@@ -1799,12 +1799,13 @@ static int pl330_chan_ctrl(void *ch_id, enum pl330_chan_op op)
struct pl330_thread *thrd = ch_id;
struct pl330_dmac *pl330;
unsigned long flags;
- int ret = 0, active = thrd->req_running;
+ int ret = 0, active;
if (!thrd || thrd->free || thrd->dmac->state == DYING)
return -EINVAL;
pl330 = thrd->dmac;
+ active = thrd->req_running;
spin_lock_irqsave(&pl330->lock, flags);
--
1.7.9.1
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply related
* linux-next: manual merge of the pci tree with the powerpc tree
From: Stephen Rothwell @ 2012-03-09 1:32 UTC (permalink / raw)
To: Jesse Barnes
Cc: linux-next, linux-kernel, Bjorn Helgaas, Benjamin Herrenschmidt,
Paul Mackerras, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 440 bytes --]
Hi Jesse,
Today's linux-next merge of the pci tree got a conflict in
arch/powerpc/platforms/iseries/pci.c between commit 8ee3e0d69623
("powerpc: Remove the main legacy iSerie platform code") from the powerpc
tree and commit 673c97562489 ("powerpc/PCI: replace pci_probe_only with
pci_flags") from the pci tree.
The former removed the file, so I did that.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the powerpc tree with the arm tree
From: Russell King @ 2012-03-09 0:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Stephen Rothwell, Michael Neuling, Paul Mackerras, linuxppc-dev,
linux-next, linux-kernel, Rob Herring
In-Reply-To: <1331249746.3105.40.camel@pasglop>
On Fri, Mar 09, 2012 at 10:35:46AM +1100, Benjamin Herrenschmidt wrote:
> Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
> I remove it, then I get Kconfig warnings:
>
> warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies
> (HAVE_GENERIC_HARDIRQS && HAVE_SPARSE_IRQ)
Do you have commit 2ed86b16eabe4efbf80cc725a8cbb5310746a2fc ?
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply
* Re: for-next inclusion request: dma-buf buffer sharing framework
From: Stephen Rothwell @ 2012-03-08 23:45 UTC (permalink / raw)
To: Sumit Semwal
Cc: linux-kernel, linux-next, linux-media, linaro-mm-sig,
DRI mailing list
In-Reply-To: <CAO_48GHdCfyqoytN-8Vki9u6VCgn3R=T8LUR0Xs0B7KWEMzxWw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1868 bytes --]
Hi,
On Thu, 8 Mar 2012 14:28:39 +0530 Sumit Semwal <sumit.semwal@linaro.org> wrote:
>
> May I request you to please add the dma-buf buffer sharing framework
> tree to linux-next?
>
> It is hosted here
> git://git.linaro.org/people/sumitsemwal/linux-dma-buf.git
> branch: for-next
I have added that from today.
Thanks for adding your subsystem tree as a participant of linux-next. As
you may know, this is not a judgment of your code. The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.
You will need to ensure that the patches/commits in your tree/series have
been:
* submitted under GPL v2 (or later) and include the Contributor's
Signed-off-by,
* posted to the relevant mailing list,
* reviewed by you (or another maintainer of your subsystem tree),
* successfully unit tested, and
* destined for the current or next Linux merge window.
Basically, this should be just what you would send to Linus (or ask him
to fetch). It is allowed to be rebased if you deem it necessary.
--
Cheers,
Stephen Rothwell
sfr@canb.auug.org.au
Legal Stuff:
By participating in linux-next, your subsystem tree contributions are
public and will be included in the linux-next trees. You may be sent
e-mail messages indicating errors or other issues when the
patches/commits from your subsystem tree are merged and tested in
linux-next. These messages may also be cross-posted to the linux-next
mailing list, the linux-kernel mailing list, etc. The linux-next tree
project and IBM (my employer) make no warranties regarding the linux-next
project, the testing procedures, the results, the e-mails, etc. If you
don't agree to these ground rules, let me know and I'll remove your tree
from participation in linux-next.
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: manual merge of the akpm tree with Linus' tree
From: Linus Torvalds @ 2012-03-08 23:42 UTC (permalink / raw)
To: Andrew Morton; +Cc: Xiao Guangrong, Stephen Rothwell, linux-next, linux-kernel
In-Reply-To: <20120308132415.15359fc7.akpm@linux-foundation.org>
On Thu, Mar 8, 2012 at 1:24 PM, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> How does this look?
Looks good to me.
Linus
^ permalink raw reply
* Re: linux-next: manual merge of the powerpc tree with the arm tree
From: Benjamin Herrenschmidt @ 2012-03-08 23:35 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Michael Neuling, Paul Mackerras, linuxppc-dev, Russell King,
linux-next, linux-kernel, Rob Herring
In-Reply-To: <1331185951.3105.29.camel@pasglop>
On Thu, 2012-03-08 at 16:52 +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2012-03-08 at 14:51 +1100, Stephen Rothwell wrote:
> > Hi Mikey,
> >
> > On Thu, 08 Mar 2012 13:33:56 +1100 Michael Neuling <mikey@neuling.org> wrote:
> > >
> > > Surely we only need SPARSE_IRQ now and not MAY_HAVE_SPARSE_IRQ.
> > >
> > > In fact, keeping MAY_HAVE_SPARSE_IRQ seems to make SPARSE_IRQ user
> > > selectable, which we don't want anymore since ad5b7f1350c2.
> >
> > Yes, indeed. I will fix up the merge resolution for tomorrow.
>
> This is my fault. Grant's patch had a collision and I manually fixed it
> up. While doing that, I put back MAY_HAVE_SPARSE_IRQ which the patch
> originally took out.
Actually, I didn't keep MAY_HAVE_SPARSE_IRQ, I kept HAVE_SPARSE_IRQ. If
I remove it, then I get Kconfig warnings:
warning: (PPC) selects SPARSE_IRQ which has unmet direct dependencies (HAVE_GENERIC_HARDIRQS && HAVE_SPARSE_IRQ)
Cheers,
Ben.
^ permalink raw reply
* [PATCH] ARM: pxa: fix build failure for regulator consumer in em-x270.c
From: Paul Gortmaker @ 2012-03-08 22:06 UTC (permalink / raw)
To: broonie, haojian.zhuang
Cc: linux-arm-kernel, linux-next, grinberg, Paul Gortmaker
In-Reply-To: <CAP=VYLp-weNj35OHtmZ6pf5-t7OUxWREeu8r5sSOLhFYu0CppQ@mail.gmail.com>
Commit 737f360d5bef5e01c6cfa755dca0b449a154c1e0 (linux-next)
"regulator: Remove support for supplies specified by struct device"
caused this file to break, since it was still relying on the
device field to be present. Update them to use the new dev_name
entries instead.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
CC: Mark Brown <broonie@opensource.wolfsonmicro.com>
---
[v2: replace dev with dev_name instead of just deleting dev.
Note however there is dev_name overlap; not sure if that matters? ]
diff --git a/arch/arm/mach-pxa/em-x270.c b/arch/arm/mach-pxa/em-x270.c
index c1b65da..0ffc100 100644
--- a/arch/arm/mach-pxa/em-x270.c
+++ b/arch/arm/mach-pxa/em-x270.c
@@ -1083,19 +1083,19 @@ static void __init em_x270_userspace_consumers_init(void)
}
/* DA9030 related initializations */
-#define REGULATOR_CONSUMER(_name, _dev, _supply) \
+#define REGULATOR_CONSUMER(_name, _dev_name, _supply) \
static struct regulator_consumer_supply _name##_consumers[] = { \
{ \
- .dev = _dev, \
+ .dev_name = _dev_name, \
.supply = _supply, \
}, \
}
-REGULATOR_CONSUMER(ldo3, &em_x270_gps_userspace_consumer.dev, "vcc gps");
+REGULATOR_CONSUMER(ldo3, "reg-userspace-consumer", "vcc gps");
REGULATOR_CONSUMER(ldo5, NULL, "vcc cam");
-REGULATOR_CONSUMER(ldo10, &pxa_device_mci.dev, "vcc sdio");
+REGULATOR_CONSUMER(ldo10, "pxa2xx-mci", "vcc sdio");
REGULATOR_CONSUMER(ldo12, NULL, "vcc usb");
-REGULATOR_CONSUMER(ldo19, &em_x270_gprs_userspace_consumer.dev, "vcc gprs");
+REGULATOR_CONSUMER(ldo19, "reg-userspace-consumer", "vcc gprs");
REGULATOR_CONSUMER(buck2, NULL, "vcc_core");
#define REGULATOR_INIT(_ldo, _min_uV, _max_uV, _ops_mask) \
--
1.7.9.1
^ permalink raw reply related
* [PATCH] ARM: pxa: fix regulator related build fail in magician_defconfig
From: Paul Gortmaker @ 2012-03-08 21:34 UTC (permalink / raw)
To: broonie, haojian.zhuang, lost.distance
Cc: linux-arm-kernel, linux-next, Paul Gortmaker
In-Reply-To: <1331084814.11802.YahooMailClassic@web29012.mail.ird.yahoo.com>
commit 737f360d5bef5e01c6cfa755dca0b449a154c1e0 (linux-next)
"regulator: Remove support for supplies specified by struct device"
deletes the field from the struct, but this platform was still trying
to set those fields. Convert them to use the REGULATOR_SUPPLY macro.
arch/arm/mach-pxa/magician.c:581: error: unknown field 'dev' specified in initializer
arch/arm/mach-pxa/magician.c:581: warning: initialization from incompatible pointer type
arch/arm/mach-pxa/magician.c:585: error: unknown field 'dev' specified in initializer
arch/arm/mach-pxa/magician.c:585: warning: initialization from incompatible pointer type
arch/arm/mach-pxa/hx4700.c:683: error: unknown field 'dev' specified in initializer
arch/arm/mach-pxa/hx4700.c:683: warning: initialization from incompatible pointer type
arch/arm/mach-pxa/hx4700.c:687: error: unknown field 'dev' specified in initializer
arch/arm/mach-pxa/hx4700.c:687: warning: initialization from incompatible pointer type
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
[v3: fix arg2 in REGULATOR_SUPPLY to have correct names ]
diff --git a/arch/arm/mach-pxa/hx4700.c b/arch/arm/mach-pxa/hx4700.c
index f2c23ea..b6a338b 100644
--- a/arch/arm/mach-pxa/hx4700.c
+++ b/arch/arm/mach-pxa/hx4700.c
@@ -679,14 +679,8 @@ static struct platform_device power_supply = {
*/
static struct regulator_consumer_supply bq24022_consumers[] = {
- {
- .dev = &gpio_vbus.dev,
- .supply = "vbus_draw",
- },
- {
- .dev = &power_supply.dev,
- .supply = "ac_draw",
- },
+ REGULATOR_SUPPLY("vbus_draw", "gpio-vbus"),
+ REGULATOR_SUPPLY("ac_draw", "pda-power"),
};
static struct regulator_init_data bq24022_init_data = {
diff --git a/arch/arm/mach-pxa/magician.c b/arch/arm/mach-pxa/magician.c
index 3d6baf9..1a18e63 100644
--- a/arch/arm/mach-pxa/magician.c
+++ b/arch/arm/mach-pxa/magician.c
@@ -577,14 +577,8 @@ static struct platform_device power_supply = {
*/
static struct regulator_consumer_supply bq24022_consumers[] = {
- {
- .dev = &gpio_vbus.dev,
- .supply = "vbus_draw",
- },
- {
- .dev = &power_supply.dev,
- .supply = "ac_draw",
- },
+ REGULATOR_SUPPLY("vbus_draw", "gpio-vbus"),
+ REGULATOR_SUPPLY("ac_draw", "pda-power"),
};
static struct regulator_init_data bq24022_init_data = {
--
1.7.9.1
^ permalink raw reply related
* Re: linux-next: manual merge of the akpm tree with Linus' tree
From: Andrew Morton @ 2012-03-08 21:24 UTC (permalink / raw)
To: Xiao Guangrong; +Cc: Stephen Rothwell, linux-next, linux-kernel, Linus
In-Reply-To: <4F5882E6.8080202@linux.vnet.ibm.com>
On Thu, 08 Mar 2012 17:59:02 +0800
Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com> wrote:
> Andrew, the patch has been reworked.
>
> Subject: [PATCH] hugetlb: drop prev_vma in hugetlb_get_unmapped_area_topdown()
>
> After the call find_vma_prev(mm, addr, &prev_vma), the following condition
> is always true:
>
> !prev_vma || (addr >= prev_vma->vm_end)
>
> it can happily drop prev_vma and use find_vma() instead of find_vma_prev().
>
Well OK, but the changelog is wrong - we don't call find_vma_prev()
here any more.
How does this look?
From: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Subject: hugetlb: remove prev_vma from hugetlb_get_unmapped_area_topdown()
After looking up the vma which covers or follows the cached search
address, the following condition is always true:
!prev_vma || (addr >= prev_vma->vm_end)
so we can stop checking the previous VMA altogether.
Signed-off-by: Xiao Guangrong <xiaoguangrong@linux.vnet.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
---
arch/x86/mm/hugetlbpage.c | 18 +++++-------------
1 file changed, 5 insertions(+), 13 deletions(-)
diff -puN arch/x86/mm/hugetlbpage.c~hugetlb-drop-prev_vma-in-hugetlb_get_unmapped_area_topdown arch/x86/mm/hugetlbpage.c
--- a/arch/x86/mm/hugetlbpage.c~hugetlb-drop-prev_vma-in-hugetlb_get_unmapped_area_topdown
+++ a/arch/x86/mm/hugetlbpage.c
@@ -308,7 +308,7 @@ static unsigned long hugetlb_get_unmappe
{
struct hstate *h = hstate_file(file);
struct mm_struct *mm = current->mm;
- struct vm_area_struct *vma, *prev_vma;
+ struct vm_area_struct *vma;
unsigned long base = mm->mmap_base;
unsigned long addr = addr0;
unsigned long largest_hole = mm->cached_hole_size;
@@ -340,22 +340,14 @@ try_again:
if (!vma)
return addr;
- /*
- * new region fits between prev_vma->vm_end and
- * vma->vm_start, use it:
- */
- prev_vma = vma->vm_prev;
- if (addr + len <= vma->vm_start &&
- (!prev_vma || (addr >= prev_vma->vm_end))) {
+ if (addr + len <= vma->vm_start) {
/* remember the address as a hint for next time */
mm->cached_hole_size = largest_hole;
return (mm->free_area_cache = addr);
- } else {
+ } else if (mm->free_area_cache == vma->vm_end) {
/* pull free_area_cache down to the first hole */
- if (mm->free_area_cache == vma->vm_end) {
- mm->free_area_cache = vma->vm_start;
- mm->cached_hole_size = largest_hole;
- }
+ mm->free_area_cache = vma->vm_start;
+ mm->cached_hole_size = largest_hole;
}
/* remember the largest hole we saw so far */
_
^ permalink raw reply
* Re: linux-next broken by "ARM: S3C2440: move mach-s3c2440/* into mach-s3c24xx/"
From: Heiko Stübner @ 2012-03-08 20:44 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: Mark Brown, kgene.kim, ben-linux, tiwai, linux-next
In-Reply-To: <4F590F74.2030007@windriver.com>
Am Donnerstag 08 März 2012, 20:58:44 schrieb Paul Gortmaker:
> On 12-03-08 02:12 PM, Mark Brown wrote:
> > On Thu, Mar 08, 2012 at 11:23:26AM -0500, Paul Gortmaker wrote:
> >> Something bad happened in this commit (dd6f01b5cc). It looks like
> >> the moved file is truncated, causing this failure:
> >>
> >> http://kisskb.ellerman.id.au/kisskb/buildresult/5818815/
> >>
> >> I believe it came in via the fix/asoc tree.
> >
> > Hrm? What is "it" in this context, and what was your analysis here?
> > Nothing in the page you're linking to above suggests something audio
> > related...
>
> The "it" was the commit in the subject, and the ID in the above text.
> That was the last commit to have touched this file (via moving it).
>
> What I took as a relation to fix/asoc was shown in the text you've
> gone and deleted here in the follow up.
>
> In any case, it does appear the file was broken before it was moved.
> The offending commit is actually c1ba544f81544ed9613ad5d058968533dbcef4b2
>
> "ARM: S3C24XX: Fix restart on S3C2442"
>
> It appears that a closing brace was dropped when it was integrated.
kgene wrote in "[PATCH] ARM: S3C2440: Fixed build error for s3c244x":
> This happened when I applied Heiko's 'Fix restart on S3C2442'.
> It was my fault :( and this should be sent before release v3.3.
and was applied by Olof today.
Heiko
^ permalink raw reply
* Re: linux-next broken by "ARM: S3C2440: move mach-s3c2440/* into mach-s3c24xx/"
From: Paul Gortmaker @ 2012-03-08 19:58 UTC (permalink / raw)
To: Mark Brown, kgene.kim, heiko; +Cc: ben-linux, tiwai, linux-next
In-Reply-To: <20120308191207.GC7557@sirena.org.uk>
On 12-03-08 02:12 PM, Mark Brown wrote:
> On Thu, Mar 08, 2012 at 11:23:26AM -0500, Paul Gortmaker wrote:
>> Something bad happened in this commit (dd6f01b5cc). It looks like
>> the moved file is truncated, causing this failure:
>
>> http://kisskb.ellerman.id.au/kisskb/buildresult/5818815/
>
>> I believe it came in via the fix/asoc tree.
>
> Hrm? What is "it" in this context, and what was your analysis here?
> Nothing in the page you're linking to above suggests something audio
> related...
The "it" was the commit in the subject, and the ID in the above text.
That was the last commit to have touched this file (via moving it).
What I took as a relation to fix/asoc was shown in the text you've
gone and deleted here in the follow up.
In any case, it does appear the file was broken before it was moved.
The offending commit is actually c1ba544f81544ed9613ad5d058968533dbcef4b2
"ARM: S3C24XX: Fix restart on S3C2442"
It appears that a closing brace was dropped when it was integrated.
Paul.
^ permalink raw reply
* Re: linux-next broken by "ARM: S3C2440: move mach-s3c2440/* into mach-s3c24xx/"
From: Mark Brown @ 2012-03-08 19:12 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: kgene.kim, ben-linux, tiwai, linux-next
In-Reply-To: <20120308162326.GA30941@windriver.com>
On Thu, Mar 08, 2012 at 11:23:26AM -0500, Paul Gortmaker wrote:
> Something bad happened in this commit (dd6f01b5cc). It looks like
> the moved file is truncated, causing this failure:
> http://kisskb.ellerman.id.au/kisskb/buildresult/5818815/
> I believe it came in via the fix/asoc tree.
Hrm? What is "it" in this context, and what was your analysis here?
Nothing in the page you're linking to above suggests something audio
related...
^ permalink raw reply
* Re: [PATCH 2/2] mm/linux-next: Fix rcu locking in vm_is_stack
From: Siddhesh Poyarekar @ 2012-03-08 18:35 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Mark Salter, linux-next, linux-kernel, Andrew Morton,
Paul Gortmaker
In-Reply-To: <20120308174023.GA13424@redhat.com>
On Thu, Mar 8, 2012 at 11:10 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> Not in this case. see __unhash_process(p)->list_del_rcu(p->thread_group).
>
> You missed the fact that ->thread_group differs from the "usual" rcu
> protected list. The _head_ of the list can be list_del_rcu'd. Not the
> first/last/any entry, even the head.
>
> Or IOW, we do not really have the head. Every task is the list entry,
> but it also can be be used as a head by while_each_thread().
Ahh ok, I did not notice this. That's an interesting quirk. The more I
think I understand rcu the more I realize there are gaps in my
understanding.
>> In that case too, before this
>> happens, the proc entry is removed
>
> I guess you meant proc_flush_task()... Not sure I really understand,
> it can't "remove" the opened entry. This is just optimization which
> tries to shrink the cache.
Yes, and I was obviously wrong, now that I read the whole thing again,
including the unmounting of the namespace. I misread the unmounting of
proc as being an unmount of the thread/thread group namespace (the nr
== 1 check).
> Yes, yes, yes, but this "next element" can exit too before you take
> rcu_read_lock, and in this case the deleted entry won't be updated.
> That is the problem.
I will post the entire, consolidated patch once again next week with
changes for this as well as some other things (*not* marking the
process stack with the TID to maintain backward compatibility and some
code cleanup). Thanks for not giving up trying to explain the same
thing over and over again ;)
--
Siddhesh Poyarekar
http://siddhesh.in
^ permalink raw reply
* Re: linux-next: build failure after merge of the tip tree
From: Greg KH @ 2012-03-08 18:00 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
linux-next, linux-kernel, Alan Cox, Andrew Morton
In-Reply-To: <20120308152110.12c805f59c45251d79bcb24b@canb.auug.org.au>
On Thu, Mar 08, 2012 at 03:21:10PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/staging/sep/sep_driver.c:55:32: fatal error: linux/rar_register.h: No such file or directory
>
> Caused by commit 33e9970add94 ("x86/mid: Kill off Moorestown").
>
> Following previous instructions, I have disabled the staging tree driver
> using this patch (pending a fix in the tip tree):
Looks good to me. Alan, care to send me an update that fixes this
driver for real?
thanks,
greg k-h
^ permalink raw reply
* linux-next: triage for March 8, 2012
From: Paul Gortmaker @ 2012-03-08 17:59 UTC (permalink / raw)
To: linux-next; +Cc: linux-kernel
Builds that are fixed since last report:
ARM:orion5x_defconfig
ia64:defconfig
m68k:defconfig
m68k:sun3_defconfig
sparc:allmodconfig
sparc64:allmodconfig
New breakage since last report:
ARM:s3c2410_defconfig (truncated file)
i386:randconfig (gpio merge issue)
powerpc:allmodconfig (kernel finally too big?)
powerpc:mpc885_ads_defconfig (odd, UFO?)
Still broken, but broken differently:
i386:allmodconfig (rtl2830 64bit math)
Latest results at:
http://kisskb.ellerman.id.au/kisskb/branch/9/
Failures as of March 8th, 2012:
===============================
ARM:arm-allnoconfig
when: forever
why: not supported
status: nothing pending, but patches accepted
fix: n/a
ref: https://lkml.org/lkml/2009/4/30/105
ref: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/081218.html
ARM:cam60_defconfig
when: Feb 23, 16:47
why: trace_entries.h: 'perf_ftrace_event_register' undeclared
status: S. Rostedt has a patch somewhere.
fix:
ref: irc (#linux-rt)
ARM:collie_defconfig
when: Feb 14, 19:10
why: locomolcd.c: error: 'sa1100fb_lcd_power' undeclared
status: fixed (PaulG) - pending integration
fix: http://marc.info/?l=linux-next&m=133105157730749&w=2
ref:
ARM:iop32x_defconfig,iop33x_defconfig
when: Nov 23, 13:42
why: restart.c: implicit declaration of function 'soft_restart'
status: fixed (PaulG) - pending integration
fix: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-January/081461.html
ref:
ARM:ixp4xx_defconfig
when: Oct 26, 01:40
why: gpio.h: implicit declaration of function '__gpio_get_value'
status: fixed (Imre Kaloz) - but possibly needs rework?
fix: https://lkml.org/lkml/2012/2/8/288
ref: https://lkml.org/lkml/2012/2/8/287
ARM:magician_defconfig
when: Feb 13, 19:10
why: magician.c: unknown field 'dev' specified in initializer
status: WIP (PaulG) - may need rework, or pending integration
fix:
ref: http://marc.info/?l=linux-next&m=133106325903524&w=2
ARM:em_x270_defconfig
when: Feb 14, 01:15
why: em-x270.c: unknown field 'dev' specified in initializer
status: WIP (PaulG) - I think initial patch needs rework
fix:
ref: http://www.spinics.net/lists/arm-kernel/msg163135.html
ARM:raumfeld_defconfig
when: Nov 23, 09:36
why: eeti_ts.c: implicit declaration of function 'irq_to_gpio'
status: perhaps broken since 2010? See ref below.
fix:
ref: http://www.gossamer-threads.com/lists/linux/kernel/1291618?do=post_view_threaded#1291618
ARM:omap2plus_defconfig
when: Feb 16, 00:23
why: control.c:238: error: 'OMAP343X_CTRL_BASE' undeclared
status: PaulG did hack-n-slash, but at best a WIP, needs additonal reverts
fix: http://www.spinics.net/lists/arm-kernel/msg163120.html
ref: http://www.spinics.net/lists/arm-kernel/msg163262.html
ARM:at91x40_defconfig
when: Feb 28, 07:38
why: super.c:(.text+0x3ffd8): undefined reference to `vm_is_stack'
status: WIP, fix from PaulG + follow on from
fix: http://marc.info/?l=linux-next&m=133096554131691&w=2
ref: http://marc.info/?l=linux-next&m=133104723928617&w=2
ARM:s3c2410_defconfig
when: Mar 7, 22:59
why: s3c244x.c: expected declaration or statement at end of input
status: bad commit introduces truncated file; reported by PaulG
fix:
ref: http://marc.info/?l=linux-next&m=133122388231509&w=2
----------------
AVR32:allnoconfig
when: May 26 2010, 20:49
why: at32_map_usart: undefined reference to `atmel_default_console_device'
status:
fix:
ref:
---------------
bfin:***all-builds***
when: Jan 20, 22:13
why: undefined reference to `vm_is_stack'
status: WIP, fix from PaulG + follow on from Siddhesh Poyarekar
fix: http://marc.info/?l=linux-next&m=133096554131691&w=2
ref: http://marc.info/?l=linux-next&m=133104723928617&w=2
---------------
cris:***all-builds***
when: Mar 25, 22:05
why: include/linux/types.h:25: error expected ... before 'ino_t'
status:
fix:
ref:
----------------
crisv32:***all-builds***
when: Mar 25, 22:05
why: include/linux/types.h:25: error expected ... before 'ino_t'
status:
fix:
ref:
----------------
i386:allmodconfig
when: Mar 8, 20:41
why: ERROR: "__udivdi3" [drivers/media/dvb/frontends/rtl2830.ko] undefined!
status: looks fixed, pending integration
fix:
ref: http://www.spinics.net/lists/linux-media/msg45093.html
----------------
i386:randconfig
when: Mar 9, 00:27
why: gpio-sodaville.c:130: error: unknown field 'dt_translate' specified in initializer
status: GrantL working on a merge fixup
fix:
ref: http://marc.info/?l=linux-next&m=133122564032275&w=2
----------------
m68k:allmodconfig
when: Mar 9, 00:38
why: ERROR: "__udivdi3" [drivers/media/dvb/frontends/rtl2830.ko] undefined!
status: looks fixed, pending integration
fix:
ref: http://www.spinics.net/lists/linux-media/msg45093.html
----------------
mips:cavium-octeon_defconfig
when: forever
why: "Error: Bad value (octeon) for -march" -- WTF? bad toolchain?
status:
fix:
ref: http://kisskb.ellerman.id.au/kisskb/buildresult/5807171/
mips:allmodconfig
when:
why: driver_pci_host.c: implicit declaration of function 'pcibios_enable_device'
status:
fix:
ref: http://kisskb.ellerman.id.au/kisskb/buildresult/5807000/
----------------
parisc:***all-builds***
when: Mar 7, 00:04
why: lib/bitmap.c: implicit declaration of function 'current_thread_info'
status: fixed
fix: PaulG - needs to include thread_info in the module-3.4 branch
ref: http://marc.info/?l=linux-next&m=133108471012536&w=2
-----------------
parisc64:a500_defconfig
when:
why: include/linux/log2.h: implicit declaration of function 'fls'
status: reported by PaulG, WIP by David Howells
fix:
ref: https://lkml.org/lkml/2012/2/29/409
ref: https://lkml.org/lkml/2012/3/6/228
------------------
powerpc:allyesconfig
when: May 18 2009, 22:11
why: fat ass kernel with everything simply won't link
status: need to fix build config to ignore the final link
fix:
ref: http://kisskb.ellerman.id.au/kisskb/buildresult/5806793/
powerpc:allmodconfig
when: Mar 8, 22:28
why: section .text overlaps section .kernel.dtb
status: need to fix build config to ignore the final link
fix:
ref: http://kisskb.ellerman.id.au/kisskb/buildresult/5818877/
powerpc:mpc885_ads_defconfig
when: Mar 8, 19:45
why: fs/nfs/inode.c:1063: undefined reference to `crc32_le'
status: odd - PaulG tried to reproduce it but failed.
fix:
ref:
------------------
sh4:***all-builds***
when: Feb 24, 17:38
why: include/linux/log2.h: implicit declaration of function 'fls'
status: reported by PaulG, WIP by David Howells
fix:
ref: https://lkml.org/lkml/2012/2/29/409
ref: https://lkml.org/lkml/2012/3/6/228
------------------
um:um-defconfig
when: Sep 16 2010, 01:28
why: os-Linux/start_up.c: error: 'PTRACE_SETOPTIONS' undeclared
status: clearly broken forever, so does anyone care?
fix:
ref: http://kisskb.ellerman.id.au/kisskb/target/2979/
^ permalink raw reply
* Re: [PATCH 2/2] mm/linux-next: Fix rcu locking in vm_is_stack
From: Oleg Nesterov @ 2012-03-08 17:40 UTC (permalink / raw)
To: Siddhesh Poyarekar
Cc: Mark Salter, linux-next, linux-kernel, Andrew Morton,
Paul Gortmaker
In-Reply-To: <CAAHN_R3JW=7VUSOEkiZMctz8zq_njAdJgngMoRF_EDZ4krVbTg@mail.gmail.com>
On 03/08, Siddhesh Poyarekar wrote:
>
> On Wed, Mar 7, 2012 at 9:08 PM, Oleg Nesterov <oleg@redhat.com> wrote:
> > rcu_read_lock() can not help without the additional checks. By the
> > time you take it, task->thread_group->next can point to nowhere.
>
> I thought I understood this the second time, but I think I haven't.
>
> > Once again. You have the task_struct *task. It exits,
> > but task->thread_group->next still points to another thread T. Now suppose
> > that T exits too. But task->thread_group->next was not changed, it still
> > points to T. RCU grace period passes, T is freed.
>
> This is the point I haven't understood. From what I understand about
> rcu, the rcu update will first update task->thread_group->next
Not in this case. see __unhash_process(p)->list_del_rcu(p->thread_group).
You missed the fact that ->thread_group differs from the "usual" rcu
protected list. The _head_ of the list can be list_del_rcu'd. Not the
first/last/any entry, even the head.
Or IOW, we do not really have the head. Every task is the list entry,
but it also can be be used as a head by while_each_thread().
> and
> then reclaim the struct it pointed to and not the other way around. So
> with:
>
> >> rcu_read_lock();
> >> - while_each_thread(task, t) {
> >> + t = list_first_entry_rcu(&task->thread_group,
> >> + struct task_struct, thread_group);
>
> since I have the rcu_read_lock when I'm touching the rcu protected
> list,
It is not rcu-protected if this task has already exited, that is why
you need (say) pid_alive() check.
> I guess there is a corner case where the current task is released and
> thread_group is rcu_list_del()'d.
Yes, assuming that "current" means this "task",
> In that case too, before this
> happens, the proc entry is removed
I guess you meant proc_flush_task()... Not sure I really understand,
it can't "remove" the opened entry. This is just optimization which
tries to shrink the cache.
But this doesn't matter, it can exit right after get_pid_task() succeeds.
(OK, and after mm_for_maps() in this particular case, otherwise m_start()
fails).
> and the task namespace is unmounted
> from /proc.
Again, this doesn't matter, but note the nr == 1 check. This is only
called when init exits and this simply does kern_unmount().
> Also, the thread_group being deleted from list is merely
> an update of references and we should get the next element
Yes, yes, yes, but this "next element" can exit too before you take
rcu_read_lock, and in this case the deleted entry won't be updated.
That is the problem.
Oleg.
^ permalink raw reply
* Re: linux-next: drivers/gpio/gpio-sodaville.c breaks build
From: Grant Likely @ 2012-03-08 16:52 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: bigeasy, linux-next, hjk, torbenh
In-Reply-To: <20120308164724.GA31129@windriver.com>
On Thu, Mar 8, 2012 at 9:47 AM, Paul Gortmaker
<paul.gortmaker@windriver.com> wrote:
> The addition of this driver has caused a build failur in the
> i386 randconfig. Perhaps it needs more Kconfig depends additions to
> limit it to the platforms where hardware exists?
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/5819098/
>
> Paul.
No, it's a merge conflict due to an API change. I'm working on the fix.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* linux-next: drivers/gpio/gpio-sodaville.c breaks build
From: Paul Gortmaker @ 2012-03-08 16:47 UTC (permalink / raw)
To: bigeasy; +Cc: linux-next, grant.likely, hjk, torbenh
The addition of this driver has caused a build failur in the
i386 randconfig. Perhaps it needs more Kconfig depends additions to
limit it to the platforms where hardware exists?
http://kisskb.ellerman.id.au/kisskb/buildresult/5819098/
Paul.
^ permalink raw reply
* linux-next broken by "ARM: S3C2440: move mach-s3c2440/* into mach-s3c24xx/"
From: Paul Gortmaker @ 2012-03-08 16:23 UTC (permalink / raw)
To: kgene.kim; +Cc: ben-linux, tiwai, linux-next
Something bad happened in this commit (dd6f01b5cc). It looks like
the moved file is truncated, causing this failure:
http://kisskb.ellerman.id.au/kisskb/buildresult/5818815/
I believe it came in via the fix/asoc tree.
Paul.
--
paul@yow-lpgnfs-02:~/git/linux-head$ git show `git rev-list --merges dd6f01b5cc..mar8|tail -n1`
commit 79ad0a5e9210b165c62e269eb48ade9361c630f3
Merge: 94a8d5c 539d3d8
Author: Takashi Iwai <tiwai@suse.de>
Date: Thu Sep 24 09:16:15 2009 +0200
Merge branch 'fix/asoc' into for-next
paul@yow-lpgnfs-02:~/git/linux-head$
^ permalink raw reply
* Re: linux-next: manual merge of the arm-soc tree with the omap_dss2 tree
From: Arnd Bergmann @ 2012-03-08 16:16 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Olof Johansson, linux-arm-kernel, linux-next, linux-kernel,
Tomi Valkeinen, Tony Lindgren
In-Reply-To: <20120308170048.f1a992bca2ca2d93fa9747bf@canb.auug.org.au>
On Thursday 08 March 2012, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the arm-soc tree got a conflict in
> arch/arm/mach-omap1/board-palmtt.c between commit ddba6c7f7ec6 ("OMAP1:
> pass LCD config with omapfb_set_lcd_config()") from the omap_dss2 tree
> and commit 2e3ee9f45b3c ("ARM: OMAP1: Move most of plat/io.h into local
> iomap.h") from the arm-soc tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
Hi Stephen,
Thanks for fixing up all the conflicts between arm-soc and omap_dss2.
I think we should make sure they are resolved in one of the trees before
the merge window.
Tomi, what are your plans for the omap_dss2 branch to get merged?
Do you think you should send it to Linus first and we merge it into
arm-soc to resolve the conflicts?
Or do you want to merge it through the arm-soc tree?
Or should we go first and you fix up the conflicts by pulling in the
necessary topic branches from arm-soc into your tree?
Arnd
^ permalink raw reply
* Re: linux-next: Tree for Mar 7 (kvm)
From: Avi Kivity @ 2012-03-08 11:53 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML, kvm
In-Reply-To: <4F57E791.6070205@xenotime.net>
On 03/08/2012 12:56 AM, Randy Dunlap wrote:
> On 03/06/2012 11:10 PM, Stephen Rothwell wrote:
>
> > Hi all,
> >
> > Changes since 20120306:
> >
> > The kvm tree lost its build failure.
>
>
> I'm getting this build error on X86_32 (i386):
>
> arch/x86/kvm/x86.c:1042: Error: no instruction mnemonic suffix given and no register operands; can't size instruction
>
>
Patch to follow.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox