All of lore.kernel.org
 help / color / mirror / Atom feed
From: swarren@wwwdotorg.org (Stephen Warren)
To: linux-arm-kernel@lists.infradead.org
Subject: 3.9-rc1 regression in arm dtb build
Date: Fri, 29 Mar 2013 11:05:10 -0600	[thread overview]
Message-ID: <5155C9C6.4070702@wwwdotorg.org> (raw)
In-Reply-To: <20130328195456.GA22527@quad.lixom.net>

On 03/28/2013 01:54 PM, Olof Johansson wrote:
> On Thu, Mar 28, 2013 at 08:33:23PM +0100, Pavel Machek wrote:
>> On Thu 2013-03-28 08:49:20, Stephen Warren wrote:
>>> On 03/28/2013 03:29 AM, Pavel Machek wrote:
>>> ...
>>>> There's change that makes it pretty much impossible to build dtbs
>>>> reliably between different kernel versions, because it leaves old dtbs
>>>> around, and they survive even make clean.
>>>
>>> One question here: Presumably the dtbs don't survive "make clean" if you
>>> run that right after building the dtbs, but only if you check out a new
>>> kernel version before running clean? Or is that not the case?
>>
>> That was the case I seen, yes.
>>
>> Have old kernel running, dtbs building. Apply a patch. It starts
>> behaving weird. You do make clean... but you still get old dtbs.
>>
>> (It would be nice if make socfpga_cyclone5.dtb would magically remove
>> all the dtbs from old location; make dtbs does that if I understand
>> stuff correctly).
> 
> 
> 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 kernels that build *.dtb in the new location:

make dtbs and make foo.dtb both rm ../*.dtb

In kernels that build *.dtb in the old location:

make dtbs and make foo.dtb both rm dts/*.dtb

Is that too much to retrofit into all the stable kernels?

WARNING: multiple messages have this Message-ID (diff)
From: Stephen Warren <swarren@wwwdotorg.org>
To: Olof Johansson <olof@lixom.net>
Cc: Pavel Machek <pavel@ucw.cz>,
	Grant Likely <grant.likely@secretlab.ca>,
	kernel list <linux-kernel@vger.kernel.org>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Russell King - ARM Linux <linux@arm.linux.org.uk>,
	Arnd Bergmann <arnd@arndb.de>,
	"linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	Rob Herring <rob.herring@calxeda.com>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: 3.9-rc1 regression in arm dtb build
Date: Fri, 29 Mar 2013 11:05:10 -0600	[thread overview]
Message-ID: <5155C9C6.4070702@wwwdotorg.org> (raw)
In-Reply-To: <20130328195456.GA22527@quad.lixom.net>

On 03/28/2013 01:54 PM, Olof Johansson wrote:
> On Thu, Mar 28, 2013 at 08:33:23PM +0100, Pavel Machek wrote:
>> On Thu 2013-03-28 08:49:20, Stephen Warren wrote:
>>> On 03/28/2013 03:29 AM, Pavel Machek wrote:
>>> ...
>>>> There's change that makes it pretty much impossible to build dtbs
>>>> reliably between different kernel versions, because it leaves old dtbs
>>>> around, and they survive even make clean.
>>>
>>> One question here: Presumably the dtbs don't survive "make clean" if you
>>> run that right after building the dtbs, but only if you check out a new
>>> kernel version before running clean? Or is that not the case?
>>
>> That was the case I seen, yes.
>>
>> Have old kernel running, dtbs building. Apply a patch. It starts
>> behaving weird. You do make clean... but you still get old dtbs.
>>
>> (It would be nice if make socfpga_cyclone5.dtb would magically remove
>> all the dtbs from old location; make dtbs does that if I understand
>> stuff correctly).
> 
> 
> 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 kernels that build *.dtb in the new location:

make dtbs and make foo.dtb both rm ../*.dtb

In kernels that build *.dtb in the old location:

make dtbs and make foo.dtb both rm dts/*.dtb

Is that too much to retrofit into all the stable kernels?

  reply	other threads:[~2013-03-29 17:05 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-06 19:33 3.9-rc1 regression in arm dtb build Pavel Machek
2013-03-06 19:33 ` Pavel Machek
2013-03-06 19:45 ` Thomas Petazzoni
2013-03-06 19:45   ` Thomas Petazzoni
2013-03-07 14:39   ` Pavel Machek
2013-03-07 14:39     ` Pavel Machek
2013-03-06 22:32 ` Stephen Warren
2013-03-06 22:32   ` Stephen Warren
2013-03-07 14:45   ` Pavel Machek
2013-03-07 14:45     ` Pavel Machek
2013-03-07 20:50     ` Stephen Warren
2013-03-07 20:50       ` Stephen Warren
2013-03-11  5:05       ` Olof Johansson
2013-03-11  5:05         ` Olof Johansson
2013-03-11 10:56         ` Pavel Machek
2013-03-11 10:56           ` Pavel Machek
2013-03-11 11:00         ` Grant Likely
2013-03-11 11:00           ` Grant Likely
2013-03-28  9:29           ` Pavel Machek
2013-03-28  9:29             ` Pavel Machek
2013-03-28 14:49             ` Stephen Warren
2013-03-28 14:49               ` Stephen Warren
2013-03-28 19:33               ` Pavel Machek
2013-03-28 19:33                 ` Pavel Machek
2013-03-28 19:54                 ` Olof Johansson
2013-03-28 19:54                   ` Olof Johansson
2013-03-29 17:05                   ` Stephen Warren [this message]
2013-03-29 17:05                     ` Stephen Warren
2013-03-29 18:47                     ` Pavel Machek
2013-03-29 18:47                       ` Pavel Machek
2013-03-29 19:41                     ` Olof Johansson
2013-03-29 19:41                       ` Olof Johansson
2013-03-29 22:18                       ` Pavel Machek
2013-03-29 22:18                         ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5155C9C6.4070702@wwwdotorg.org \
    --to=swarren@wwwdotorg.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.