* Re: [PATCH v3] PM / QoS: Introduce new classes: DMA-Throughput and DVFS-Latency
From: MyungJoo Ham @ 2012-03-26 12:06 UTC (permalink / raw)
To: markgross
Cc: Rafael J. Wysocki, Stephen Rothwell, Dave Jones, linux-pm,
linux-next@vger.kernel.org, Len Brown, Pavel Machek, Kevin Hilman,
Jean Pihet, kyungmin.park, linux-kernel
In-Reply-To: <20120318170659.GC12163@envy17>
On Mon, Mar 19, 2012 at 2:06 AM, mark gross <markgross@thegnar.org> wrote:
> On Fri, Mar 16, 2012 at 05:30:33PM +0900, MyungJoo Ham wrote:
>> On Sun, Mar 11, 2012 at 7:53 AM, Rafael J. Wysocki <rjw@sisk.pl> wrote:
>> > On Friday, March 09, 2012, MyungJoo Ham wrote:
>> >> On Thu, Mar 8, 2012 at 12:47 PM, mark gross <markgross@thegnar.org> wrote:
>> >> > On Wed, Mar 07, 2012 at 02:02:01PM +0900, MyungJoo Ham wrote:
>> >> >> 1. CPU_DMA_THROUGHPUT
>> >> ...
>> >> >> 2. DVFS_LATENCY
>> >> >
>> >> > The cpu_dma_throughput looks ok to me. I do however; wonder about the
>> >> > dvfs_lat_pm_qos. Should that knob be exposed to user mode? Does that
>> >> > matter so much? why can't dvfs_lat use the cpu_dma_lat?
>> >> >
>> >> > BTW I'll be out of town for the next 10 days and probably will not get
>> >> > to this email account until I get home.
>> >> >
>> >> > --mark
>> >> >
>> >>
>> >> 1. Should DVFS Latency be exposed to user mode?
>> >>
>> >> It would depend on the policy of the given system; however, yes, there
>> >> are systems that require a user interface for DVFS Latency.
>> >> With the example of user input response (response to user click,
>> >> typing, touching, and etc), a user program (probably platform s/w or
>> >> middleware) may input QoS requests. Besides, when a new "application"
>> >> is starting, such "middleware" may want faster responses from DVFS
>> >> mechanisms.
>> >
>> > But this is a global knob, isn't it? And it seems that a per-device one
>> > is needed rather than that?
>> >
>> > It also applies to your CPU_DMA_THROUGHPUT thing, doesn't it?
>>
>>
>> Yes, the two are global knobs. And both the two control multiple
>> devices simultaneously, not just a single device. I suppose per-device
>> QoS is appropriate for QoS requests directed to a single device. Am I
>> right about this one?
>>
>>
>> Let's assume that, in an example system, we have devfreq on GPU,
>> memory-Interface, and main bus and CPUfreq (Exynos5 will have them all
>> seperated).
>>
>> If we use per-device QoS for DVFS LATENCY, in order to control the
>> DVFS response latency, we will need to make QoS requests to all the
>> four devices independently, not to the global DVFS LATENCY QOS CLASS.
>> There, we could have a shared single QoS request list for these four
>> DVFS devices, saying that the DVFS response should be done in "50ms"
>> after a sudden utilization increase.
>>
>> We may be able to use "dev_pm_qos_add_notifier()" for a virtual device
>> representing "DVFS Latency" or "DMA Throughput" and let the GPU, CPU,
>> main-bus, and memory-interface listen to the events from the virtual
>> device. Hmm..., do you recommend this approach? creating a device
>> representing "DVFS" as a whole (both CPUFreq and device drivers of
>> devfreq).
>>
>> CPU_DMA_THROUGHPUT is quite similar as CPU_DMA_LATENCY. However, we
>> think it is addtionally needed because many IPs (in-SoC devices) need
>> to specify its DMA usage in "kbytes/sec", not "usecs/ops". For
>> example, a video-decoding chip device driver may say it requires
>> "750000kbytes/sec" for 1080p60, "300000kbytes/sec" for 720p60, and so
>> on, which affects CPUfreq, memory-interface, and main-bus at the same
>> time.
> I have an example of a need for cpu_dma_throughput for x86 soc's as
> well. Mostly my example comes down to on-demand thinking the work load
> is low (gpu is doing all the work) yet the work load needs a higher
> clock rates between frame times to avoid buffer under running the gfx
> pipe).
>
> My version of the patch didn't fly too well because it failed to offer a
> scalable definition of the units of cpu_dma_throughput. I tried using
> KHZ as the unit (the units used in cpufreq). However; Applications
> written to assume HZ units on one system would need to re-written on the
> next. Perhaps using bandwidth would be better than throughput?
>
>
The unit itself won't change whether we use bandwidth or throughput
here; i.e., throughput is often referred as "effective bandwidth". For
applications and middleware, throughput is more attractive than
bandwidth because they will prefer to express what they want
(throughput or "effective" bandwidth), not what the devices should do
(bandwidth). For example, the bandwidth of a 100MHz-128bit bus is
12.8Gbps; however, if this bus is considered to be saturated at 30% of
its bandwidth, the throughput will be around 3.84Gbps. The QoS users
will prefer the latter because it can be expressed independently from
the architecture; it doesn't matter if it is saturated at 30% or 50%.
Besides, such variables should be known to the bus device driver
(i.e., "exynos4-bus" devfreq driver, which assumes 30% or 40%
depending on architectures).
Anyway, we've been using kHz with a test version of this (driven by
GPUs like your example), which has to be changed even between Exynos4
series. :)
>
>> >
>> >> 2. Does DVFS Latency matter?
>> >>
>> >> Yes, in our experimental sets w/ Exynos4210 (those slapped in Galaxy
>> >> S2 equivalent; not exactly as I'm not conducted in Android systems,
>> >> but Tizen), we could see noticable difference w/ bare eyes for
>> >> user-input responses. When we shortened DVFS polling interval with
>> >> touches, the touch responses were greatly improved; e.g., losing 10
>> >> frames into losing 0 or 1 frame for a sudden input rush.
>> >
>> > Well, this basically means PM QoS matters, which is kind of obvious.
>> > It doesn't mean that it can't be implemented in a better way, though.
>>
>> For DVFS-Latency and DMA-Throughput, I think a normal pm-qos-dev (one
>> device per one qos knob) isn't appropriate because there are multiple
>> devices that are required to react simultaneously.
>>
>> It is possible to let multiple devices react by adding notifiers with
>> dev_pm_qos_add_notifier(). However, I felt that it wasn't the purpose
>> of this one and it might get things ugly. Anyway, was allowing
>> multiple devices to change their frequencies/voltages for a single
>> per-device QoS list the purpose of dev_pm_qos_add_notifier()?
>>
>>
>> Just throwing an idea and suggestion if it was the purpose,
>> I speculate that If we are going to do this (supporting multiple
>> devices per one qos knob without adding QoS class), we'd better create
>> "qos class device" in /drivers/qos/ and let those qos class handle
>> multiple devices depending on a single "qos class". Probably, this
>> will transform "global PM-QoS class" that notifies related devices
>> into "QoS class device" that notifies related devices.
>>
>> >
>> >> 3. Why not replace DVFS Latency w/ CPU-DMA-Latency/Throughput?
>> >>
>> >> When we implement the user-input response enhancement with CPU-DMA QoS
>> >> requests, the PM-QoS will unconditionally increase CPU and BUS
>> >> frequencies/voltages with user inputs. However, with many cases it is
>> >> unnecessary; i.e., a user input means that there will be unexpected
>> >> changes soon; however, the change does not mean that the load will
>> >> increase. Thus, allowing DVFS mechanism to evolve faster was enough to
>> >> shorten the response time and not to increase frequencies and voltages
>> >> when not needed. There were significant difference in power
>> >> consumption with this changes if the user inputs were not involving
>> >> drastic graphics jobs; e.g., typing a text message.
>> >
>> > Again, you're arguing for having PM QoS rather than not having it. You don't
>> > have to do that. :-)
>> >
>> > Generally speaking, I don't think we should add any more PM QoS "classes"
>> > as defined in pm_qos.h, since they are global and there's only one
>> > list of requests per class. While that may be good for CPU power
>> > management (in an SMP system all CPUs are identical, so the same list of
>> > requests may be applied to all of them), it generally isn't for I/O
>> > devices (some of them work in different time scales, for example).
>> >
>> > So, for example, most likely, a list of PM QoS requests for storage devices
>> > shouldn't be applied to input devices (keyboards and mice to be precise) and
>> > vice versa.
>> >
>> > On the other hand, I don't think that applications should access PM QoS
>> > interfaces associated with individual devices directly, because they may
>> > not have enough information about the relationships between devices in the
>> > system. So, perhaps, there needs to be an interface allowing applications
>> > to specify their PM QoS expectations in a general way (e.g. "I want <number>
>> > disk I/O throughput") and a code layer between that interface and device
>> > drivers translating those expecataions into PM QoS requests for specific
>> > devices.
>>
>> With DVFS Latency PM QoS Class, we can say "I want the system to react
>> in 50ms for any sudden utilization increases.". Without it, we should
>> say, for example, "CPUFreq/Ondemand should set interval at 25ms,
>> Devfreq/Bus should set interval at 25ms, and Devfreq/GPU should set
>> interval at 10ms."
>>
>> And with CPU Throughput PM QoS Class, we can say "I want 1000000
>> kbytes/sec DMA transfer". Without it, we should say "Memory-Interface
>> at 1000000 kbytes/sec, Exynos4412 core should be at least 500MHz, and
>> Bus should be at least 166MHz".
>>
>
> What things are coming down to is we need to see if we can identify good
> abstractions that can be portable / scalable across ISA's and boards,
> such that applications would not need to be changed to work correctly
> across all of them.
>
> One issue I have with adding a single DVFS latency and throughput pm-qos
> parameter is that what Device the DVFS *really* means changes from one
> board to the next. Thus making it impossible to abstract to user mode.
>
> --mark
Does "what QoS/DVFS really means changes from one board to the next"
mean that the specific behavior with the same QoS request changes from
one board to the next?
In other words, for a 10MByte/sec CPU_DMA_THROUGHPUT QoS request,
- In board A, it means setting CPU at least at 200MHz,
Memory-interface at 166MHz, Bus at 166MHz.
- In board B, it means seeting Bus at least at 200MHz.
Or, for a 50ms DVFS_LATENCY QoS request,
- In board A, it means setting cpufreq interval at 30ms
- In board B, it means setting cpufreq interval at 30ms,
devfreq-memory at 30ms, devfreq-GPU at 20ms.
Is the issue you've mentioned the difference between board A and B
above? or something else I'm missing?
My understanding is that (global) PM-QoS is abstracting (hiding) what
PM-QoS really does to hardware from userspace or other QoS user device
drivers by allowing to express the requirement in the user side (what
users want, not the h/w or device drivers do).
What userspace needs to know (or to express) is:
NETWORK_THROUGHPUT: how many kbytes per sec can we send? (abstracting
how bus, NIC react to such requests; e.g., some NIC does 100MHz for
10Mbps, some other NICs do 33MHz for 10Mbps, and such)
CPU_DMA_THROUGHPUT: how many kbytes per sec can we send? (abstracting
how bus device driver and memory-interface driver does; e.g., for
100Mbps, bus: 100MHz, mif: 100MHz in machine A, for 100Mbps, bus:
133MHz, mif: 200MHz in machine B, and such)
DVFS_LATENCY: how long may we wait for DVFS mechanisms to react?
(abstracting how each devfreq/cpufreq driver behave). An FPS game
might want 10ms, a web browser may want 20ms, and a touch screen event
might want 10ms, and a menuscreen (home screen) manager may want 50ms.
Based on this QoS value, the polling interval of cpufreq/devfreq
devices may be changed. If there were only cpufreq for DVFS
mechanisms, I won't bother with this issue. However, there may be
multiple DVFS devices with independent polling intervals; thus,
without some interfaces like DVFS_LATENCY, userspace or QoS-requesting
device drivers need to know and control every DVFS device's polling
interval making them dependent on specific boards/devices.
ps. For the example Rafael wanted for CPU_DMA_THROUGHPUT, I'll create
one when the corresponding (Qos-requesting) device drivers are ready
to be upstreamed. The device driver is with KHz of memory-interface,
yet.
Cheers!
MyungJoo.
--
MyungJoo Ham, Ph.D.
System S/W Lab, S/W Center, Samsung Electronics
^ permalink raw reply
* [PATCH] ASoC: dmaengine_pcm: use dmaengine cyclic wrapper
From: Vinod Koul @ 2012-03-26 11:58 UTC (permalink / raw)
To: alsa-devel, linux-next
Cc: broonie, paul.gortmaker, fabio.estevam, Alexandre.Bounine,
Vinod Koul
commit 4a163c82 added extra parameter to device_prep_dma_cyclic
this is not required if we use the wrapper over cyclic API.
This is split from Alexedre's patch
Signed-off-by: Vinod Koul <vinod.koul@linux.intel.com>
---
sound/soc/soc-dmaengine-pcm.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/soc-dmaengine-pcm.c b/sound/soc/soc-dmaengine-pcm.c
index 76c038b..4756952 100644
--- a/sound/soc/soc-dmaengine-pcm.c
+++ b/sound/soc/soc-dmaengine-pcm.c
@@ -143,10 +143,10 @@ static int dmaengine_pcm_prepare_and_submit(struct snd_pcm_substream *substream)
direction = snd_pcm_substream_to_dma_direction(substream);
prtd->pos = 0;
- desc = chan->device->device_prep_dma_cyclic(chan,
+ desc = dmaengine_prep_dma_cyclic(chan,
substream->runtime->dma_addr,
snd_pcm_lib_buffer_bytes(substream),
- snd_pcm_lib_period_bytes(substream), direction, NULL);
+ snd_pcm_lib_period_bytes(substream), direction);
if (!desc)
return -ENOMEM;
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH linux-next] dmaengine: add context parameter fixups
From: Vinod Koul @ 2012-03-26 11:07 UTC (permalink / raw)
To: Mark Brown
Cc: fabio.estevam, alsa-devel, samuel, paul.gortmaker, tiwai, netdev,
linux-kernel, Alexandre Bounine, linux-next, dan.j.williams,
Fabio Estevam, lrg
In-Reply-To: <20120326110149.GL3098@opensource.wolfsonmicro.com>
On Mon, 2012-03-26 at 12:01 +0100, Mark Brown wrote:
> On Mon, Mar 26, 2012 at 04:18:26PM +0530, Vinod Koul wrote:
>
> > But we don't want the clients to use this additional parameter or be
> > exposed to it if not required. Every client is expected to use the
> > dmaengine wrappers for prepare and not invoke .device_ callbacks.
>
> Are those wrappers present in what's gone to Linus' tree, and can
> someone please send a patch to convert to using them?
Yes that are already there :-)
I will send sound specific update now
--
~Vinod
^ permalink raw reply
* Re: [PATCH linux-next] dmaengine: add context parameter fixups
From: Mark Brown @ 2012-03-26 11:01 UTC (permalink / raw)
To: Vinod Koul
Cc: fabio.estevam, alsa-devel, samuel, paul.gortmaker, tiwai, netdev,
linux-kernel, Alexandre Bounine, linux-next, dan.j.williams,
Fabio Estevam, lrg
In-Reply-To: <1332758906.19804.97.camel@vkoul-udesk3>
[-- Attachment #1.1: Type: text/plain, Size: 390 bytes --]
On Mon, Mar 26, 2012 at 04:18:26PM +0530, Vinod Koul wrote:
> But we don't want the clients to use this additional parameter or be
> exposed to it if not required. Every client is expected to use the
> dmaengine wrappers for prepare and not invoke .device_ callbacks.
Are those wrappers present in what's gone to Linus' tree, and can
someone please send a patch to convert to using them?
[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
^ permalink raw reply
* Re: [PATCH linux-next] dmaengine: add context parameter fixups
From: Vinod Koul @ 2012-03-26 10:48 UTC (permalink / raw)
To: Mark Brown
Cc: fabio.estevam, alsa-devel, samuel, paul.gortmaker, tiwai, netdev,
linux-kernel, Alexandre Bounine, linux-next, dan.j.williams,
Fabio Estevam, lrg
In-Reply-To: <20120326103354.GD3098@opensource.wolfsonmicro.com>
On Mon, 2012-03-26 at 11:33 +0100, Mark Brown wrote:
> On Mon, Mar 26, 2012 at 03:24:30PM +0530, Vinod Koul wrote:
>
> > Now either I drop these from 3.4 or merge Linus's tree and apply
> > Alexandre's fix (as that is the right fix rather than one in asoc tree)
> > And since this was required for RIO patches which are still WIP, I think
> > I am leaning towards former.
>
> Gah, WTF is going on here? Has this API change not been sent to Linus
> already, and what is wrong with the changes which Fabio sent? I've
> already applied Fabio's change on the understanding that this API change
> done and dusted.
>
> It seems better to do a minimal fix at this point rather than churning
> things again...
The change is technically correct, so don't worry it wont break
anything, and API is frozen and not changing.
But we don't want the clients to use this additional parameter or be
exposed to it if not required. Every client is expected to use the
dmaengine wrappers for prepare and not invoke .device_ callbacks.
--
~Vinod
^ permalink raw reply
* Re: [PATCH linux-next] dmaengine: add context parameter fixups
From: Mark Brown @ 2012-03-26 10:33 UTC (permalink / raw)
To: Vinod Koul
Cc: Fabio Estevam, Alexandre Bounine, paul.gortmaker, dan.j.williams,
samuel, lrg, perex, tiwai, linux-kernel, linux-next, netdev,
fabio.estevam, alsa-devel
In-Reply-To: <1332755670.19804.91.camel@vkoul-udesk3>
[-- Attachment #1: Type: text/plain, Size: 626 bytes --]
On Mon, Mar 26, 2012 at 03:24:30PM +0530, Vinod Koul wrote:
> Now either I drop these from 3.4 or merge Linus's tree and apply
> Alexandre's fix (as that is the right fix rather than one in asoc tree)
> And since this was required for RIO patches which are still WIP, I think
> I am leaning towards former.
Gah, WTF is going on here? Has this API change not been sent to Linus
already, and what is wrong with the changes which Fabio sent? I've
already applied Fabio's change on the understanding that this API change
done and dusted.
It seems better to do a minimal fix at this point rather than churning
things again...
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH linux-next] dmaengine: add context parameter fixups
From: Vinod Koul @ 2012-03-26 9:54 UTC (permalink / raw)
To: Mark Brown
Cc: Fabio Estevam, Alexandre Bounine, paul.gortmaker, dan.j.williams,
samuel, lrg, perex, tiwai, linux-kernel, linux-next, netdev,
fabio.estevam, alsa-devel
In-Reply-To: <20120326094200.GA3098@opensource.wolfsonmicro.com>
On Mon, 2012-03-26 at 10:42 +0100, Mark Brown wrote:
> On Mon, Mar 26, 2012 at 11:04:42AM +0530, Vinod Koul wrote:
> > On Sat, 2012-03-24 at 12:23 -0300, Fabio Estevam wrote:
>
> > > http://permalink.gmane.org/gmane.linux.alsa.devel/96215
>
> > And this seems to be linux-next.
>
> > Mark, Is this part of the sound updates that went to Linus?
>
> No, not yet - it was only sent after the merge window. Quite why nobody
> managed to notice it before then I don't know. It'll go to him soon, or
> at least to Takashi, but don't know if it'll make -rc1 or not.
I should have noticed that sound needs update as well :(
Now either I drop these from 3.4 or merge Linus's tree and apply
Alexandre's fix (as that is the right fix rather than one in asoc tree)
And since this was required for RIO patches which are still WIP, I think
I am leaning towards former.
--
~Vinod
^ permalink raw reply
* Re: [PATCH linux-next] dmaengine: add context parameter fixups
From: Mark Brown @ 2012-03-26 9:42 UTC (permalink / raw)
To: Vinod Koul
Cc: Fabio Estevam, Alexandre Bounine, paul.gortmaker, dan.j.williams,
samuel, lrg, perex, tiwai, linux-kernel, linux-next, netdev,
fabio.estevam, alsa-devel
In-Reply-To: <1332740082.19804.15.camel@vkoul-udesk3>
[-- Attachment #1: Type: text/plain, Size: 488 bytes --]
On Mon, Mar 26, 2012 at 11:04:42AM +0530, Vinod Koul wrote:
> On Sat, 2012-03-24 at 12:23 -0300, Fabio Estevam wrote:
> > http://permalink.gmane.org/gmane.linux.alsa.devel/96215
> And this seems to be linux-next.
> Mark, Is this part of the sound updates that went to Linus?
No, not yet - it was only sent after the merge window. Quite why nobody
managed to notice it before then I don't know. It'll go to him soon, or
at least to Takashi, but don't know if it'll make -rc1 or not.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Inconsistent kallsyms data on ARM.
From: Arnd Bergmann @ 2012-03-26 8:39 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Russell King - ARM Linux, Jon Masters, Paul Gortmaker, linux-next,
linux-arm-kernel, linux-kbuild
In-Reply-To: <20120326074533.GL15647@pengutronix.de>
On Monday 26 March 2012, Uwe Kleine-König wrote:
> On Mon, Mar 26, 2012 at 08:37:04AM +0100, Russell King - ARM Linux wrote:
> > On Sun, Mar 25, 2012 at 07:59:44PM -0400, Jon Masters wrote:
> > > As to longer term, I am happy to work up something that will spot this
> > > particular kind of failure (symbol changes type) and output something
> > > more useful during the kallsyms generation if you would like.
> > >
> > > Are you planning to pull in either of the fixes you mention?
> >
> > I'm not, because those are all sub-optimal - I don't see why we should
> > bloat the kernel image just for the sake of working around kallsyms.
> >
> > The best I've come up with so far which avoids that is to force
> > KALLSYMS_EXTRA_PASS to always be set on ARM.
> Just to let you know: I even saw failures with KALLSYMS_EXTRA_PASS set.
> Not so in the recent past and sometimes not even reproducible IIRC.
> I will save the build results next time it happens now that I saw what
> to look for.
Yes, I saw these too in my randconfig builds some time ago. Maybe a handful
of builds among 50000 configurations.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Commit "watchdog: coh901327_wdt.c: fix timeout" breaks linux-next
From: Wim Van Sebroeck @ 2012-03-26 8:27 UTC (permalink / raw)
To: Paul Gortmaker; +Cc: linus.walleij, linux-watchdog, linux-next
In-Reply-To: <CAP=VYLr4MfkBpgg-QeMRw9oDswtrySBEb6ZUKa8_CLOHh+pF2A@mail.gmail.com>
Hi Paul,
Will fix it.
Kind regards,
wim.
> Hi Wim,
>
> Can you please re-check this commit? It has two instances of
> the typo "timout" and one of them is causing a build failure
> in linux-next.
>
> Thanks,
> Paul.
> --
>
> drivers/watchdog/coh901327_wdt.c:358:15: error: 'struct
> watchdog_device' has no member named 'timout'
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/5940810/
>
> commit 884f1a12c8b39721452f0dfedf1f82de3d696cf1
> Author: Wim Van Sebroeck <wim@iguana.be>
> Date: Thu Mar 22 20:42:16 2012 +0100
>
> watchdog: coh901327_wdt.c: fix timeout
>
> Set the timeout value properly so that we don't get faulty values
> for the WDIOC_GETTIMEOUT iotcl. 'margin' should be an unsigned int.
> Also add a check to see if margin is a valid parameter after it is
> loaded as a module.
^ permalink raw reply
* Re: linux-next: manual merge of the mfd tree with Linus' tree
From: Samuel Ortiz @ 2012-03-26 8:25 UTC (permalink / raw)
To: Grant Likely
Cc: Stephen Rothwell, linux-next, linux-kernel, Benoit Cousson,
Felipe Balbi
In-Reply-To: <20120324173152.494DA3E0A26@localhost>
On Sat, Mar 24, 2012 at 05:31:52PM +0000, Grant Likely wrote:
> On Fri, 23 Mar 2012 10:41:39 +0100, Samuel Ortiz <sameo@linux.intel.com> wrote:
> > Hi Stephen,
> >
> > On Fri, Mar 23, 2012 at 02:32:37PM +1100, Stephen Rothwell wrote:
> > > Hi Samuel,
> > >
> > > Today's linux-next merge of the mfd tree got a conflict in
> > > drivers/mfd/twl-core.c between commits 5769089ac725 ("mfd: twl-core.c:
> > > Fix the number of interrupts managed by twl4030"), 75294957be1d
> > > ("irq_domain: Remove 'new' irq_domain in favour of the ppc one") and
> > > 964dba283439 ("devicetree: Add empty of_platform_populate() for !
> > > CONFIG_OF_ADDRESS (sparc)") from Linus' tree and commits 9e1786202704
> > > ("mfd: Make twl-core not depend on pdata->irq_base/end") and 78518ffa08fc
> > > ("mfd: Move twl-core IRQ allocation into twl[4030|6030]-irq files") from
> > > the mfd tree.
> > >
> > > I *think* that the right thing to do is to use the version from the mfd
> > > tree ...
> > That's correct.
> > I have a for-next-merge branch where I usually have the merge conflicts with
> > Linus tree fixed, in case you're interested.
> >
> >
> > > I do wonder why I only got this now (in the merge window) ...
> > I got a pull request from Benoit a couple days before the merge window opened.
> > Then I realized part of the pull request contained a merge of one of Grant's
> > branch. So I wanted to wait for Grant's code to get in before picking the mfd
> > work on top of it. I didn't want to send a pull request to Linus with a merge
> > point for something that would have been already merged. Maybe I was wrong,
> > you tell me.
>
> It should have gone into linux-next before then. Waiting for my tree
> to hit linus' tree defeats the purpose of linux-next. Now you're
> branch hasn't had any testing and therefore is a risky merge.
The branch has been tested by TI folks, on 3 different TI platforms. And the
patches we're talking about are all TI's twl related ones.
Cheers,
Samuel.
--
Intel Open Source Technology Centre
http://oss.intel.com/
^ permalink raw reply
* Re: linux-next: build failure after merge of the scsi tree
From: James Bottomley @ 2012-03-26 7:57 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linux-next, linux-kernel, Alexey Dobriyan, Greg KH
In-Reply-To: <20120326121719.dc4c2b1faca5cf12c8d76d93@canb.auug.org.au>
On Mon, 2012-03-26 at 12:17 +1100, Stephen Rothwell wrote:
> Hi James,
>
> After merging the scsi tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/staging/keucr/scsiglue.c:349:2: error: unknown field 'proc_info' specified in initializer
> drivers/staging/rts_pstor/rtsx.c:258:2: error: unknown field 'proc_info' specified in initializer
> drivers/staging/rts5139/rts51x_scsi.c:2190:2: error: unknown field 'proc_info' specified in initializer
>
> Caused by commit 104c4fe25dc9 ("[SCSI] remove scsi_host_template::proc_info").
>
> Since this is a staging driver, I applied these following patches:
Yes, that looks about right, thanks. We haven't seen anything about
these drivers on the SCSI list, so I've no idea where they are in
development.
James
^ permalink raw reply
* Re: Inconsistent kallsyms data on ARM.
From: Uwe Kleine-König @ 2012-03-26 7:45 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Jon Masters, Paul Gortmaker, linux-next, linux-arm-kernel,
Arnd Bergmann, linux-kbuild
In-Reply-To: <20120326073704.GH5611@n2100.arm.linux.org.uk>
Hello,
On Mon, Mar 26, 2012 at 08:37:04AM +0100, Russell King - ARM Linux wrote:
> On Sun, Mar 25, 2012 at 07:59:44PM -0400, Jon Masters wrote:
> > As to longer term, I am happy to work up something that will spot this
> > particular kind of failure (symbol changes type) and output something
> > more useful during the kallsyms generation if you would like.
> >
> > Are you planning to pull in either of the fixes you mention?
>
> I'm not, because those are all sub-optimal - I don't see why we should
> bloat the kernel image just for the sake of working around kallsyms.
>
> The best I've come up with so far which avoids that is to force
> KALLSYMS_EXTRA_PASS to always be set on ARM.
Just to let you know: I even saw failures with KALLSYMS_EXTRA_PASS set.
Not so in the recent past and sometimes not even reproducible IIRC.
I will save the build results next time it happens now that I saw what
to look for.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Inconsistent kallsyms data on ARM.
From: Russell King - ARM Linux @ 2012-03-26 7:37 UTC (permalink / raw)
To: Jon Masters
Cc: Arnd Bergmann, Paul Gortmaker, linux-next, linux-arm-kernel,
linux-kbuild
In-Reply-To: <4F6FB170.1040109@jonmasters.org>
On Sun, Mar 25, 2012 at 07:59:44PM -0400, Jon Masters wrote:
> As to longer term, I am happy to work up something that will spot this
> particular kind of failure (symbol changes type) and output something
> more useful during the kallsyms generation if you would like.
>
> Are you planning to pull in either of the fixes you mention?
I'm not, because those are all sub-optimal - I don't see why we should
bloat the kernel image just for the sake of working around kallsyms.
The best I've come up with so far which avoids that is to force
KALLSYMS_EXTRA_PASS to always be set on ARM.
^ permalink raw reply
* Re: linux-next: manual merge of the slave-dma tree with the sound tree
From: Vinod Koul @ 2012-03-26 6:17 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Alexandre Bounine, Lars-Peter Clausen,
Mark Brown, Takashi Iwai
In-Reply-To: <20120322134101.e2342db0ae13a4ed79cfebfd@canb.auug.org.au>
On Thu, 2012-03-22 at 13:41 +1100, Stephen Rothwell wrote:
> On Thu, 22 Mar 2012 13:39:30 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Today's linux-next merge of the slave-dma tree got a conflict in
> > sound/soc/imx/imx-pcm-dma-mx2.c between commit c307e8e32e11 ("ASoC:
> > imx-pcm-dma: Use dmaengine PCM helper functions") from the sound tree and
> > commit 16052827d98f ("dmaengine/dma_slave: introduce inline wrappers")
> > from the slave-dma tree.
> >
> > I just use dthe version from the sound tree.
>
> The same with sound/soc/mxs/mxs-pcm.c .
Thanks Stephan, and sorry for delay in responding was away for the
weekend.
This should be fixed now with MArk applying the fix from Fabio Estevam.
I see this is in asoc-next.
--
~Vinod
^ permalink raw reply
* Re: linux-next: manual merge of the l2-mtd tree with the slave-dma tree
From: Vinod Koul @ 2012-03-26 6:18 UTC (permalink / raw)
To: dedekind1
Cc: Stephen Rothwell, linux-next, linux-kernel, Alexandre Bounine,
Huang Shijie
In-Reply-To: <1332408753.18717.1.camel@sauron.fi.intel.com>
On Thu, 2012-03-22 at 11:32 +0200, Artem Bityutskiy wrote:
> On Thu, 2012-03-22 at 14:04 +1100, Stephen Rothwell wrote:
> > Hi Artem,
> >
> > Today's linux-next merge of the l2-mtd tree got a conflict in
> > drivers/mtd/nand/gpmi-nand/gpmi-lib.c between commit 16052827d98f
> > ("dmaengine/dma_slave: introduce inline wrappers") from the slave-dma
> > tree and commit c790d78c631f ("mxs-dma : rewrite the last parameter of
> > mxs_dma_prep_slave_sg()") from the l2-mtd tree.
> >
> > I fixed it up (see below) and can carry the fix as necessary.
>
> Looks like Vinod merged a lot of changes recently. Thanks for fixing
> this up in linux-next!
Thanks Again, loks right to me too.
Yes i had a pending series which I applied just before I went for
weekend.
--
~Vinod
^ permalink raw reply
* Re: [PATCH linux-next] dmaengine: add context parameter fixups
From: Vinod Koul @ 2012-03-26 5:34 UTC (permalink / raw)
To: Fabio Estevam, Mark Brown
Cc: Alexandre Bounine, paul.gortmaker, dan.j.williams, samuel, lrg,
perex, tiwai, linux-kernel, linux-next, netdev, fabio.estevam,
alsa-devel
In-Reply-To: <CAOMZO5B-Zutv-xwqLCAgNMO8A3Kyg4uWqS41koo-yoS4mGB1TQ@mail.gmail.com>
On Sat, 2012-03-24 at 12:23 -0300, Fabio Estevam wrote:
> On Fri, Mar 23, 2012 at 11:00 AM, Alexandre Bounine
> <alexandre.bounine@idt.com> wrote:
> > This patch fixes drivers that use device_prep_slave_sg() and
> > device_prep_dma_cyclic() interfaces and have been missed during the initial
> > release of interface changing patches.
> >
> > This patch is based on linux-next-20120322 code tree.
> > See https://lkml.org/lkml/2012/3/22/339 for build failure report.
> >
> > Signed-off-by: Alexandre Bounine <alexandre.bounine@idt.com>
> > Reported-by: Paul Gortmaker <paul.gortmaker@windriver.com>
> > ---
> > drivers/dma/sa11x0-dma.c | 2 +-
> > drivers/net/irda/sa1100_ir.c | 2 +-
> > sound/soc/sh/fsi.c | 7 +++----
> > sound/soc/soc-dmaengine-pcm.c | 2 +-
>
> I have already taken care of sound/soc/soc-dmaengine-pcm.c:
> http://permalink.gmane.org/gmane.linux.alsa.devel/96215
And this seems to be linux-next.
Mark, Is this part of the sound updates that went to Linus?
--
~Vinod
^ permalink raw reply
* Re: linux-next: manual merge of the akpm tree with the tip tree
From: Alex Shi @ 2012-03-26 5:20 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Andrew Morton, linux-next, linux-kernel, Thomas Gleixner,
Ingo Molnar, H. Peter Anvin, Peter Zijlstra, Suresh Siddha
In-Reply-To: <20120326150107.392bc3a7e0175b5009bcfeff@canb.auug.org.au>
On 03/26/2012 12:01 PM, Stephen Rothwell wrote:
> Hi all,
>
> Today's linux-next merge of the akpm tree got a conflict in between
> commit a6fca40f1d7f ("x86, tlb: Switch cr3 in leave_mm() only when
> needed") from the tip tree and commit "x86: use this_cpu_xxx to replace
> percpu_xxx funcs" from the akpm tree.
>
> I fixed it up (see below) and can carry the fix as necessary.
Thanks!
^ permalink raw reply
* linux-next: Tree for Mar 26
From: Stephen Rothwell @ 2012-03-26 4:28 UTC (permalink / raw)
To: linux-next; +Cc: LKML
[-- Attachment #1: Type: text/plain, Size: 32433 bytes --]
Hi all,
Reminder: please do not add stuff destined for v3.5 to linux-next
included trees/branches until after v3.4-rc1 has been released.
Changes since 20120323:
Lots of conflicts move between trees and disappear as things are merged
into Linus' tree.
The arm tree gained a conflict against Linus' tree.
The ia64 tree lost its conflict.
The s390 tree lost its conflict.
The xfs tree lost its conflicts.
The pci tree lost its conflicts.
The scsi tree lost its build failure but gained some more for which I
disabled some staging drivers.
The isci tree lost its build failure.
The cpufreq tree lost its conflicts.
The battery tree still had its build failure so I used the version from
next-20120314.
The device-mapper tree lost its conflict.
The fbdev tree lost its conflict.
The sysctl tree lost its conflict/
The moduleh tree lost its build failures and conflicts.
The arm-soc tree lost several conflicts.
The akpm tree lost lots of patches that turned up elsewhere (mostly in
Linus' tree) and gained conflict against the tip tree.
----------------------------------------------------------------------------
I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one. You should use "git fetch" as mentioned in the FAQ on the wiki
(see below).
You can see which trees have been included by looking in the Next/Trees
file in the source. There are also quilt-import.log and merge.log files
in the Next directory. Between each merge, the tree was built with
a ppc64_defconfig for powerpc and an allmodconfig for x86_64. After the
final fixups (if any), it is also built with powerpc allnoconfig (32 and
64 bit), ppc44x_defconfig and allyesconfig (minus
CONFIG_PROFILE_ALL_BRANCHES - this fails its final link) and i386, sparc
and sparc64 defconfig. These builds also have
CONFIG_ENABLE_WARN_DEPRECATED, CONFIG_ENABLE_MUST_CHECK and
CONFIG_DEBUG_INFO disabled when necessary.
Below is a summary of the state of the merge.
We are up to 187 trees (counting Linus' and 25 trees of patches pending
for Linus' tree), more are welcome (even if they are currently empty).
Thanks to those who have contributed, and to those who haven't, please do.
Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next . If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.
Thanks to Randy Dunlap for doing many randconfig builds.
There is a wiki covering stuff to do with linux-next at
http://linux.f-seidel.de/linux-next/pmwiki/ . Thanks to Frank Seidel.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
$ git checkout master
$ git reset --hard stable
Merging origin/master (e22057c Merge tag 'stable/for-linus-3.4-tag-two' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen)
Merging fixes/master (88ebdda Merge tag 'for-3.3' of git://openrisc.net/jonas/linux)
Merging kbuild-current/rc-fixes (42f1c01 coccicheck: change handling of C={1,2} when M= is set)
Merging arm-current/fixes (a0feb6d ARM: 7358/1: perf: add PMU hotplug notifier)
Merging m68k-current/for-linus (2a35350 m68k: Fix assembler constraint to prevent overeager gcc optimisation)
Merging powerpc-merge/merge (c2ea377 Merge remote-tracking branch 'origin/master' into merge)
Merging sparc/master (e0adb99 sparc32: Add -Av8 to assembler command line.)
Merging scsi-rc-fixes/master (41f8ad7 [SCSI] osd_uld: Bump MAX_OSD_DEVICES from 64 to 1,048,576)
Merging net/master (50269e1 net: add a truesize parameter to skb_add_rx_frag())
Merging sound-current/for-linus (6681bc0 Merge tag 'asoc-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (4949be1 PCI: ignore pre-1.1 ASPM quirking when ASPM is disabled)
Merging wireless/master (c16fa4f Linux 3.3)
Merging driver-core.current/driver-core-linus (fde7d90 Linux 3.3-rc7)
Merging tty.current/tty-linus (fde7d90 Linux 3.3-rc7)
Merging usb.current/usb-linus (fde7d90 Linux 3.3-rc7)
Merging staging.current/staging-linus (fde7d90 Linux 3.3-rc7)
Merging char-misc.current/char-misc-linus (c16fa4f Linux 3.3)
Merging cpufreq-current/fixes (6139b65 Merge branch 'for_3.4/cpufreq' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into fixes)
Merging input-current/for-linus (10ce3cc Merge branch 'next' into for-linus)
Merging md-current/for-linus (ecb178b md: Add judgement bb->unacked_exist in function md_ack_all_badblocks().)
Merging audit-current/for-linus (c158a35 audit: no leading space in audit_log_d_path prefix)
Merging crypto-current/master (ff0a70f crypto: twofish-x86_64-3way - module init/exit functions should be static)
Merging ide/master (0ab3d8b cy82c693: fix PCI device selection)
Merging dwmw2/master (244dc4e Merge git://git.infradead.org/users/dwmw2/random-2.6)
Merging devicetree-current/devicetree/merge (29f141f Merge branch 'fixes-for-grant' of git://sources.calxeda.com/kernel/linux into devicetree/merge)
Merging spi-current/spi/merge (a5ab629 Fix section mismatch in spi-pl022.c)
Merging gpio-current/gpio/merge (7e3a70f gpio: Add missing spin_lock_init in gpio-ml-ioh driver)
Merging arm/for-next (467fa4e Merge branch 'acorn' into for-next)
CONFLICT (content): Merge conflict in arch/powerpc/Kconfig
CONFLICT (content): Merge conflict in arch/c6x/Kconfig
CONFLICT (content): Merge conflict in arch/arm/kernel/process.c
CONFLICT (content): Merge conflict in arch/arm/common/gic.c
Merging arm-perf/for-next/perf (c16fa4f Linux 3.3)
Merging davinci/davinci-next (fe0d422 Linux 3.0-rc6)
Merging samsung/next-samsung (9edb240 ARM: H1940/RX1950: Change default LED triggers)
Merging s5p/for-next (d782c13 Merge branch 'next/soc-exynos5250-gpio' into for-next)
Merging tegra/for-next (e8ce8f9 Merge branch 'for-3.4/cleanup-and-fixes' into for-next)
CONFLICT (content): Merge conflict in arch/arm/mach-tegra/fuse.c
Merging xilinx/arm-next (b85a3ef ARM: Xilinx: Adding Xilinx board support)
Merging blackfin/for-linus (1762275 blackfin: clean up string bfin_dma_5xx after rename.)
Merging c6x/for-linux-next (fde7d90 Linux 3.3-rc7)
Merging cris/for-next (ea78f5b CRIS: Update documentation)
Merging quilt/hexagon (110b372 Remove unneeded include of version.h from arch/hexagon/include/asm/spinlock_types.h)
CONFLICT (content): Merge conflict in arch/hexagon/Kconfig
Merging ia64/next (5cd288c Merge branch 'pstore' into next)
Merging m68k/for-next (2a35350 m68k: Fix assembler constraint to prevent overeager gcc optimisation)
Merging m68knommu/for-next (ae909ea m68knommu: factor more common ColdFire cpu reset code)
Merging microblaze/next (e02db0a microblaze: Handle TLB skip size dynamically)
Merging mips/mips-for-linux-next (2fea377 Merge branch 'fixes-for-linus' into mips-for-linux-next)
Merging openrisc/for-upstream (fa8d9d7 OpenRISC: Remove memory_start/end prototypes)
Merging parisc/for-next (c60dc74 Merge branch 'fixes' into for-next)
Merging powerpc/next (dfbc2d7 powerpc/ps3: Do not adjust the wrapper load address)
Merging 4xx/next (b5594a7 powerpc/44x: Add additional device support for APM821xx SoC and Bluestone board)
Merging mpc5xxx/next (7b6bb64 powerpc/5200: convert mpc5200 to use of_platform_populate())
Merging galak/next (5a0acea powerpc/qe: Update the SNUM table for MPC8569 Rev2.0)
Merging s390/features (5d3b56f [S390] register cpu devices for SMP=n)
Merging sparc-next/master (e9b57cc sparc: Use vsprintf extention %pf with builtin_return_address)
Merging tile/master (48b25c4 [PATCH v3] ipc: provide generic compat versions of IPC syscalls)
Merging unicore32/unicore32 (0994695 Merge branch 'akpm' (aka "Andrew's patch-bomb, take two"))
Merging ceph/master (c666601 rbd: move snap_rwsem to the device, rename to header_rwsem)
Merging cifs/master (934e18b Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/net)
Merging configfs/linux-next (b930c26 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs)
Merging ecryptfs/next (6cfd4b4 ecryptfs: remove the second argument of k[un]map_atomic())
CONFLICT (content): Merge conflict in fs/ecryptfs/ecryptfs_kernel.h
Merging ext3/for_next (e703c20 ext3: fix start and len arguments handling in ext3_trim_fs())
Merging ext4/dev (9d547c3 vfs: remove unused superblock helpers)
Merging fuse/for-next (4273b79 fuse: O_DIRECT support for files)
Merging gfs2/master (220cca2 GFS2: Change truncate page allocation to be GFP_NOFS)
Merging logfs/master (e22057c Merge tag 'stable/for-linus-3.4-tag-two' of git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen)
Merging nfs/linux-next (250f671 Merge tag 'device-for-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/paulg/linux)
Merging nfsd/nfsd-next (ab4684d NFSD: Fix nfs4_verifier memory alignment)
Merging ocfs2/linux-next (9392557 ocfs2: avoid unaligned access to dqc_bitmap)
Merging omfs/for-next (976d167 Linux 3.1-rc9)
Merging squashfs/master (4b0180a Squashfs: add mount time sanity check for block_size and block_log match)
Merging v9fs/for-next (5bdad93 9p: statfs should not override server f_type)
Merging ubifs/linux-next (5a1f36c UBIFS: improve error messages)
Merging xfs/for-next (f074211 xfs: fallback to vmalloc for large buffers in xfs_getbmap)
Merging vfs/for-next (07c0c5d ext4: initialization of ext4_li_mtx needs to be done earlier)
Merging pci/linux-next (1488d51 PCI: Bjorn gets PCI hotplug too)
Merging hid/for-next (d464c92 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid)
Merging quilt/i2c (6e5318e i2c-algo-bit: Don't resched on clock stretching)
Merging bjdooks-i2c/next-i2c (fc84fe1 Merge branch 'for_3.3/i2c/misc' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap-pm into for-33/i2c/omap)
CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-omap.c
Merging i2c-embedded/i2c-embedded/for-next (bbceeee i2c-eg20t: Remove write-only variables)
Merging quilt/jdelvare-hwmon (e3a9568 hwmon: Add MCP3021 ADC driver)
Merging hwmon-staging/hwmon-next (28c85aa hwmon: (sht15) Fix Kconfig dependencies)
Merging quilt/kernel-doc (719a4df Documentation/kernel-parameters: remove inttest parameter)
Merging docs/docs-move (5c24d8b Merge branch 'docs/docbook/drm' of git://github.com/mfwitten/linux into docs-move)
Merging v4l-dvb/master (153fb4d Merge /home/v4l/v4l/patchwork)
Merging kbuild/for-next (21ea2bf Merge branch 'kbuild/kconfig' into kbuild/for-next)
Merging kconfig/for-next (eae1c36 Merge branch 'kconfig/for-linus-2' into kconfig/for-next)
Merging libata/NEXT (b8cec3c pata_cmd64x: implement sff_irq_check() method)
Merging infiniband/for-next (5ad19b0 Merge branches 'cma', 'cxgb3', 'cxgb4', 'ehca', 'iser', 'mad', 'nes', 'qib', 'srp' and 'srpt' into for-next)
Merging acpi/next (be6fb23 Merge branch 'acpica' into next)
CONFLICT (content): Merge conflict in drivers/cpuidle/cpuidle.c
Merging cpupowerutils/master (f166033 cpupower tools: add install target to the debug tools' makefiles)
Merging ieee1394/for-next (19f8399 Merge branch 'iso-flush' into for-next)
Merging ubi/linux-next (cc83146 UBI: rename MOVE_CANCEL_BITFLIPS to MOVE_TARGET_BITFLIPS)
Merging dlm/next (1b189b8 dlm: last element of dlm_local_addr[] never used)
Merging scsi/master (7ef79ae [SCSI] vmw_pvscsi: Try setting host->max_id as suggested by the device.)
Applying: scsi: disable broken staging driver
Applying: scsi: disable more staging drivers due to scsi breakage
Merging target-updates/for-next (187e70a ib_srpt: Fix srpt_handle_cmd send_ioctx->ioctx_kref leak on exception)
Merging target-merge/for-next-merge (06de5ee tcm_qla2xxx: Add >= 24xx series fabric module for target-core)
Merging ibft/linux-next (935a9fe ibft: Fix finding IBFT ACPI table on UEFI)
Merging isci/all (efb1224 Merge branches 'devel' and 'rnc-devel' into all)
Merging slave-dma/next (beeaa10 dmaengine: at_hdmac: add slave config operation)
CONFLICT (content): Merge conflict in sound/soc/mxs/mxs-pcm.c
CONFLICT (content): Merge conflict in sound/soc/imx/imx-pcm-dma-mx2.c
CONFLICT (content): Merge conflict in sound/soc/ep93xx/ep93xx-pcm.c
CONFLICT (content): Merge conflict in drivers/mmc/host/atmel-mci.c
CONFLICT (modify/delete): arch/arm/include/asm/hardware/pl330.h deleted in slave-dma/next and modified in HEAD. Version HEAD of arch/arm/include/asm/hardware/pl330.h left in tree.
CONFLICT (modify/delete): arch/arm/common/pl330.c deleted in slave-dma/next and modified in HEAD. Version HEAD of arch/arm/common/pl330.c left in tree.
$ git rm -f arch/arm/common/pl330.c arch/arm/include/asm/hardware/pl330.h
Applying: DMA: PL330: update for code movement
Merging dmaengine/next (d07a74a dmaengine: fix missing 'cnt' in ?: in dmatest)
Merging net-next/master (3556485 Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/linux-security)
Merging wireless-next/master (3775265 libertas: remove dump_survey implementation)
Merging bluetooth/master (1c3b31a Bluetooth: Remove sk parameter from l2cap_chan_create())
Merging mtd/master (3c3e51d Merge ../linux-2.6 to bring in 3.3-rc fixes already merged)
Merging l2-mtd/master (b118591 mtd: docg3 add protection against concurrency)
CONFLICT (content): Merge conflict in sound/soc/mxs/mxs-pcm.h
CONFLICT (content): Merge conflict in fs/jffs2/fs.c
CONFLICT (content): Merge conflict in fs/jffs2/compr.c
CONFLICT (content): Merge conflict in drivers/mtd/nand/gpmi-nand/gpmi-lib.c
CONFLICT (content): Merge conflict in drivers/mtd/chips/cfi_cmdset_0002.c
CONFLICT (content): Merge conflict in drivers/mmc/host/mxs-mmc.c
CONFLICT (content): Merge conflict in drivers/dma/mxs-dma.c
Merging crypto/master (2dc9b5d padata: Fix race on sequence number wrap)
Merging sound/for-next (6a0d4b2 Merge branch 'topic/hda' into for-next)
Merging sound-asoc/for-next (4a163c8 ASoC: Add extra parameter to device_prep_dma_cyclic)
Merging cpufreq/next (a7b422c provide disable_cpufreq() function to disable the API.)
Merging quilt/rr (2a22b63 cpumask: remove old cpu_*_map.)
CONFLICT (content): Merge conflict in arch/arm/kernel/kprobes.c
Merging input/next (d8ee4a1 Input: gpio_keys - add support for interrupt only keys)
Merging input-mt/for-next (7491f3d bcm5974: Add pointer and buttonpad properties)
Merging block/for-next (bc67f63 cciss: Fix scsi tape io with more than 255 scatter gather elements)
Merging quilt/device-mapper (b911e14 This device-mapper target creates a read-only device that transparently validates the data on one underlying device against a pre-generated tree of cryptographic checksums stored on a second device.)
Merging embedded/master (4744b43 embedded: fix vc_translate operator precedence)
Merging firmware/master (6e03a20 firmware: speed up request_firmware(), v3)
Merging pcmcia/master (80af9e6 pcmcia at91_cf: fix raw gpio number usage)
CONFLICT (content): Merge conflict in drivers/pcmcia/soc_common.c
Merging battery/master (d6a047c max17042_battery: Fix CHARGE_FULL representation.)
$ git reset --hard HEAD^
Merging refs/next/20120314/battery
Merging mmc/mmc-next (7e9d684 mmc: sh_mmcif: simplify bitmask macros)
CONFLICT (content): Merge conflict in include/linux/mmc/host.h
CONFLICT (content): Merge conflict in drivers/mmc/host/tmio_mmc_pio.c
CONFLICT (content): Merge conflict in drivers/mmc/host/sh_mmcif.c
CONFLICT (content): Merge conflict in drivers/mmc/host/sdhci-s3c.c
CONFLICT (content): Merge conflict in drivers/mmc/host/atmel-mci.c
CONFLICT (content): Merge conflict in drivers/mmc/core/host.h
CONFLICT (content): Merge conflict in drivers/mmc/core/core.c
Merging kgdb/kgdb-next (53c40f5 kdb: Add message about CONFIG_DEBUG_RODATA on failure to install breakpoint)
Merging slab/for-next (b80b6c0 Merge branch 'slab/next' into for-next)
Merging uclinux/for-next (5e442a4 Revert "proc: fix races against execve() of /proc/PID/fd**")
Merging md/for-next (ecb178b md: Add judgement bb->unacked_exist in function md_ack_all_badblocks().)
Merging mfd/for-next (b8589e2 gpio/twl: Add DT support to gpio-twl4030 driver)
CONFLICT (content): Merge conflict in include/linux/mfd/abx500/ab8500.h
CONFLICT (content): Merge conflict in drivers/mfd/twl-core.c
CONFLICT (content): Merge conflict in drivers/mfd/ab8500-core.c
Merging drm/drm-next (5466c7b drm/i915: use DDC_ADDR instead of hard-coding it)
Merging fbdev/fbdev-next (6bff98b Revert "video:uvesafb: Fix oops that uvesafb try to execute NX-protected page")
Merging viafb/viafb-next (838ac78 viafb: avoid refresh and mode lookup in set_par)
Merging omap_dss2/for-next (df01d53 OMAPDSS: APPLY: fix clearing shadow dirty flag with manual update)
Merging regulator/for-next (4992fa1 Merge tag 'topic/twl' into regulator-next)
Merging security/next (09f61cd Merge branch 'for-security' of git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor into next)
Merging selinux/master (ecf093d SELinux: add default_type statements)
Merging lblnet/master (7e27d6e Linux 2.6.35-rc3)
Merging watchdog/master (072cbb7 watchdog: txx9wdt: fix timeout)
Merging dwmw2-iommu/master (c3b92c8 Linux 3.1)
Merging iommu/next (7de4730 Merge branches 'iommu/fixes', 'arm/tegra' and 'x86/amd' into next)
Merging osd/linux-next (72749a2 exofs: Cap on the memcpy() size)
Merging jc_docs/docs-next (5c050fb docs: update the development process document)
Merging trivial/for-next (f1f996b kcore: fix spelling in read_kcore() comment)
Merging audit/for-next (dcd6c92 Linux 3.3-rc1)
Merging pm/linux-next (30d73f3 Merge tag 'dlm-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/teigland/linux-dlm)
Merging apm/for-next (b4a133d Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/apm)
Merging fsnotify/for-next (ef9bf3b fanotify: only destroy a mark if both its mask and its ignored_mask are cleared)
Merging edac/linux_next (a4b4be3 edac: rename channel_info to rank_info)
Merging edac-amd/for-next (305f1c3 Merge branch '3.3-pci_device_id' into edac-for-next)
Merging devicetree/devicetree/next (0f22dd3 of: Only compile OF_DYNAMIC on PowerPC pseries and iseries)
Merging spi/spi/next (87bf5ab spi/fsl-espi: Make sure pm is within 2..32)
Merging tip/auto-latest (268dd65 Merge branch 'linus')
CONFLICT (content): Merge conflict in arch/x86/Kconfig
Merging rcu/rcu/next (1cc8596 rcu: Stop spurious warnings from synchronize_sched_expedited)
Merging cputime/cputime (c3e0ef9 [S390] fix cputime overflow in uptime_proc_show)
Merging uprobes/for-next (0326f5a uprobes/core: Handle breakpoint and singlestep exceptions)
Merging cgroup/for-next (3ce3230 cgroup: Walk task list under tasklist_lock in cgroup_enable_task_cg_list)
Merging kmemleak/kmemleak (d65b4e9 Linux 3.3-rc3)
Merging kvm/linux-next (f8753c5 KVM: Convert intx_mask_lock to spin lock)
Merging oprofile/for-next (c16fa4f Linux 3.3)
Merging xen/upstream/xen (59e9a6b Merge branch 'upstream/ticketlock-cleanup' into upstream/xen)
CONFLICT (content): Merge conflict in arch/x86/include/asm/cmpxchg.h
Merging xen-two/linux-next (2faaa4d Merge branch 'stable/for-linus-3.4' into linux-next)
Merging xen-pvhvm/linux-next (b056b6a xen: suspend: remove xen_hvm_suspend)
Merging percpu/for-next (adb7950 percpu: fix __this_cpu_{sub,inc,dec}_return() definition)
Merging workqueues/for-next (e06ffa1 workqueue: use percpu allocator for cwq on UP)
Merging drivers-x86/linux-next (27aef97 thinkpad-acpi: recognize Lenovo as version string in newer V-series BIOS)
CONFLICT (content): Merge conflict in arch/x86/platform/mrst/mrst.c
CONFLICT (content): Merge conflict in arch/x86/platform/geode/Makefile
CONFLICT (content): Merge conflict in arch/x86/Kconfig
Merging hwpoison/hwpoison (46e387b Merge branch 'hwpoison-hugepages' into hwpoison)
Merging sysctl/master (4e474a0 sysctl: protect poll() in entries that may go away)
Merging regmap/for-next (7d680ba Merge remote-tracking branch 'regmap/topic/introspection' into regmap-next)
Merging hsi/for-next (43139a6 HSI: hsi_char: Update ioctl-number.txt)
Merging driver-core/driver-core-next (adc80ae Tools: hv: Support enumeration from all the pools)
Merging tty/tty-next (fb8ebec serial: pxa: add clk_prepare/clk_unprepare calls)
Merging usb/usb-next (11207b6 net: qmi_wwan: add support for ZTE MF820D)
Merging staging/staging-next (bc01caf staging/zmem: Use lockdep_assert_held instead of spin_is_locked)
Merging char-misc/char-misc-next (b222258 misc: bmp085: Use unsigned long to store jiffies)
Merging tmem/linux-next (16c0cfa Merge branch 'stable/cleancache.v13' into linux-next)
Merging writeback/writeback-for-next (697e6fe writeback: Remove outdated comment)
Merging arm-dt/devicetree/arm-next (ede338f dt: add documentation of ARM dt boot interface)
Merging hwspinlock/linux-next (8b37fcf hwspinlock: add MAINTAINERS entries)
Merging pinctrl/for-next (51dddfe ARM: u300: configure some pins as an example)
Merging moduleh/for-sfr (de2272c Merge branch 'device-3.4' into for-sfr)
CONFLICT (content): Merge conflict in lib/string.c
Merging vhost/linux-next (1e05b62 sh: use the the PCI channels's io_map_base)
Merging kmap_atomic/kmap_atomic (317b6e1 feature-removal-schedule.txt: schedule the deprecated form of kmap_atomic() for removal)
Merging modem-shm/for-next (3cff1cc caif_shm: Add CAIF driver for Shared memory for M7400)
Merging memblock/memblock-kill-early_node_map (7bd0b0f memblock: Reimplement memblock allocation using reverse free area iterator)
Merging remoteproc/for-next (e12bc14 remoteproc: s/big switch/lookup table/)
CONFLICT (content): Merge conflict in include/linux/virtio_ids.h
Merging irqdomain/irqdomain/next (409a6f6 Merge branch 'irqdomain-for-grant' of git://sources.calxeda.com/kernel/linux into irqdomain/next)
CONFLICT (content): Merge conflict in arch/arm/Kconfig
Merging gpio/gpio/next (8194c7c gpio/sodaville: Mark broken due to core irqdomain migration)
CONFLICT (content): Merge conflict in include/linux/mfd/tps65910.h
Merging arm-soc/for-next (61689b8 Merge branch 'next/cleanup' into for-next)
CONFLICT (content): Merge conflict in drivers/watchdog/ep93xx_wdt.c
CONFLICT (content): Merge conflict in drivers/mtd/nand/atmel_nand.c
CONFLICT (content): Merge conflict in drivers/i2c/busses/i2c-gpio.c
CONFLICT (modify/delete): arch/arm/mach-vexpress/include/mach/io.h deleted in arm-soc/for-next and modified in HEAD. Version HEAD of arch/arm/mach-vexpress/include/mach/io.h left in tree.
CONFLICT (content): Merge conflict in arch/arm/mach-tegra/Makefile
CONFLICT (content): Merge conflict in arch/arm/mach-shmobile/setup-sh7377.c
CONFLICT (content): Merge conflict in arch/arm/mach-shmobile/setup-sh7367.c
CONFLICT (content): Merge conflict in arch/arm/mach-shmobile/setup-r8a7740.c
CONFLICT (modify/delete): arch/arm/mach-s3c24xx/common.h deleted in arm-soc/for-next and modified in HEAD. Version HEAD of arch/arm/mach-s3c24xx/common.h left in tree.
CONFLICT (content): Merge conflict in arch/arm/mach-msm/timer.c
CONFLICT (content): Merge conflict in arch/arm/mach-ep93xx/include/mach/ep93xx-regs.h
CONFLICT (content): Merge conflict in arch/arm/mach-at91/cpuidle.c
CONFLICT (content): Merge conflict in arch/arm/Kconfig
$ git rm -f arch/arm/mach-vexpress/include/mach/io.h
Merging kvmtool/master (20082f5 kvm tools: Fix realpath() error checking)
Merging dma-mapping/dma-mapping-next (e749a9f common: DMA-mapping: add NON-CONSISTENT attribute)
Merging dma-buf/for-next (0ee4332 dma-buf: document fd flags and O_CLOEXEC requirement)
Merging ktest/for-next (648a182 ktest: Allow a test to override REBOOT_ON_SUCCESS)
Merging cpuidle-cons/cpuidle_consol_pull (203b52e SH: shmobile: Consolidate time keeping and irq enable)
CONFLICT (content): Merge conflict in drivers/cpuidle/cpuidle.c
CONFLICT (content): Merge conflict in arch/arm/mach-davinci/cpuidle.c
CONFLICT (content): Merge conflict in arch/arm/mach-at91/cpuidle.c
CONFLICT (add/add): Merge conflict in arch/arm/include/asm/cpuidle.h
Merging scsi-post-merge/merge-base:master ()
$ git checkout akpm
Applying: net/netfilter/nf_conntrack_netlink.c: fix Oops on container destroy
Applying: acerhdf: add support for Aspire 1410 BIOS v1.3314
Applying: acerhdf: add support for new hardware
Applying: acerhdf: lowered default temp fanon/fanoff values
Applying: arch/x86/platform/iris/iris.c: register a platform device and a platform driver
Applying: intel_mid_powerbtn: mark irq as IRQF_NO_SUSPEND
Applying: x86, olpc: add debugfs interface for EC commands
Applying: x86-olpc-add-debugfs-interface-for-ec-commands v3
Applying: arch/arm/mach-ux500/mbox-db5500.c: world-writable sysfs fifo file
Applying: avr32: don't mask signals in the error path
Applying: avr32: use set_current_blocked() in handle_signal/sys_rt_sigreturn
Applying: avr32: use block_sigmask()
Applying: x86: use this_cpu_xxx to replace percpu_xxx funcs
CONFLICT (content): Merge conflict in arch/x86/mm/tlb.c
Applying: x86: change percpu_read_stable() to this_cpu_read_stable()
Applying: net: use this_cpu_xxx replace percpu_xxx funcs
Applying: percpu: remove percpu_xxx() functions
Applying: percpu-remove-percpu_xxx-functions-fix
Applying: ia64: use set_current_blocked() and block_sigmask()
Applying: headers_check: recursively search for linux/types.h inclusion
Applying: microblaze: don't reimplement force_sigsegv()
Applying: microblaze: no need to reset handler if SA_ONESHOT
Applying: microblaze: fix signal masking
Applying: microblaze: use set_current_blocked() and block_sigmask()
Applying: MIPS: use set_current_blocked() and block_sigmask()
Applying: score: don't mask signals if we fail to setup signal stack
Applying: score: use set_current_blocked() and block_sigmask()
Applying: unicore32: use block_sigmask()
Applying: net/netfilter/nfnetlink_acct.c: use linux/atomic.h
Applying: blackfin: use set_current_blocked() and block_sigmask()
Applying: ocfs2: use find_last_bit()
Applying: ocfs2: use bitmap_weight()
Applying: parisc: use set_current_blocked() and block_sigmask()
Applying: vfs: increment iversion when a file is truncated
Applying: brlocks/lglocks: cleanups
Applying: vfs: fix dup_mnt_ns
Applying: hugetlbfs: lockdep annotate root inode properly
Applying: libfs: add simple_open()
Applying: scripts/coccinelle/api/simple_open.cocci: semantic patch for simple_open()
Applying: simple_open: automatically convert to simple_open()
Applying: simple_open-automatically-convert-to-simple_open-checkpatch-fixes
Applying: fs: symlink restrictions on sticky directories
Applying: fs-symlink-restrictions-on-sticky-directories-fix-2
Applying: fs: hardlink creation restrictions
Applying: fs-hardlink-creation-restrictions-fix
Applying: fs: hardlink creation restriction cleanup
Applying: mm: fix page-faults detection in swap-token logic
Applying: mm: add extra free kbytes tunable
Applying: mm-add-extra-free-kbytes-tunable-update
Applying: mm-add-extra-free-kbytes-tunable-update-checkpatch-fixes
Applying: frv: use set_current_blocked() and block_sigmask()
Applying: sh: no need to reset handler if SA_ONESHOT
Applying: sh: use set_current_blocked() and block_sigmask()
Applying: h8300: use set_current_blocked() and block_sigmask()
Applying: alpha: use set_current_blocked() and block_sigmask()
Applying: m32r: use set_current_blocked() and block_sigmask()
Applying: m68k: use set_current_blocked() and block_sigmask()
Applying: mn10300: use set_current_blocked() and block_sigmask()
Applying: C6X: use set_current_blocked() and block_sigmask()
Applying: cpuidle: add a sysfs entry to disable specific C state for debug purpose.
Applying: cpuidle-add-a-sysfs-entry-to-disable-specific-c-state-for-debug-purpose-fix
Applying: cris: use set_current_blocked() and block_sigmask()
Applying: cris: select GENERIC_ATOMIC64
Applying: um/kernel/trap.c: port OOM changes to handle_page_fault()
Applying: ceph, cifs, nfs, fuse: boolean and / or confusion
Applying: powerpc/eeh: remove eeh_event_handler()->daemonize()
Applying: arch/powerpc/platforms/pseries/eeh_event.c: slightly fix set_current_state() wart
Applying: MAINTAINERS: fix REMOTEPROC F: typo
Applying: checkpatch: suggest pr_<level> over printk(KERN_<LEVEL>
Applying: init/do_mounts.c: create /root if it does not exist
Applying: kmod: avoid deadlock from recursive kmod call
Applying: kmod-avoid-deadlock-by-recursive-kmod-call-fix
Applying: proc: clean up /proc/<pid>/environ handling
Applying: smp: introduce a generic on_each_cpu_mask() function
Applying: arm: move arm over to generic on_each_cpu_mask
Applying: tile: move tile to use generic on_each_cpu_mask
Applying: smp: add func to IPI cpus based on parameter func
Applying: smp-add-func-to-ipi-cpus-based-on-parameter-func-fix
Applying: smp-add-func-to-ipi-cpus-based-on-parameter-func-update
Applying: smp-add-func-to-ipi-cpus-based-on-parameter-func-update-fix
Applying: smp: add func to IPI cpus based on parameter func
Applying: smp-add-func-to-ipi-cpus-based-on-parameter-func-v9-fix
Applying: slub: only IPI CPUs that have per cpu obj to flush
Applying: fs: only send IPI to invalidate LRU BH when needed
Applying: mm: only IPI CPUs to drain local pages if they exist
Applying: mm-only-ipi-cpus-to-drain-local-pages-if-they-exist-update
Applying: mm-only-ipi-cpus-to-drain-local-pages-if-they-exist-v9
Applying: lib/cpumask.c: remove __any_online_cpu()
Applying: arch/ia64: remove references to cpu_*_map
Applying: kexec: crash: don't save swapper_pg_dir for !CONFIG_MMU configurations
Applying: kexec: add further check to crashkernel
Applying: kdump x86: fix total mem size calculation for reservation
Applying: ipc/sem.c: alternatives to preempt_disable()
Applying: ipmi: decrease the IPMI message transaction time in interrupt mode
Applying: ipmi: increase KCS timeouts
Applying: ipmi: use a tasklet for handling received messages
Applying: ipmi: fix message handling during panics
Applying: ipmi: simplify locking
Applying: ipmi: use locks on watchdog timeout set on reboot
Applying: sysctl: use bitmap library functions
Applying: pidns: add reboot_pid_ns() to handle the reboot syscall
Applying: pidns-add-reboot_pid_ns-to-handle-the-reboot-syscall-fix
Applying: pidns-add-reboot_pid_ns-to-handle-the-reboot-syscall-checkpatch-fixes
Applying: nbd: rename the nbd_device variable from lo to nbd
Applying: fs/proc/namespaces.c: prevent crash when ns_entries[] is empty
Applying: radix-tree: introduce bit-optimized iterator
Applying: radix-tree-introduce-bit-optimized-iterator-v3
Applying: radix-tree-introduce-bit-optimized-iterator-v3-fix
Applying: radix-tree: rewrite gang lookup using iterator
Applying: radix-tree: use iterators in find_get_pages* functions
Applying: selftests: launch individual selftests from the main Makefile
Applying: selftests/Makefile: make `run_tests' depend on `all'
Applying: mm: move page-types.c from Documentation to tools/vm
Applying: mm: move slabinfo.c to tools/vm
Applying: mm: move hugepage test examples to tools/testing/selftests/vm
Applying: move-hugepage-test-examples-to-tools-testing-selftests-vm-fix
Applying: move-hugepage-test-examples-to-tools-testing-selftests-vm-fix-fix
Applying: sysctl: make kernel.ns_last_pid control dependent on CHECKPOINT_RESTORE
Applying: fs, proc: introduce /proc/<pid>/task/<tid>/children entry
Applying: syscalls, x86: add __NR_kcmp syscall
Applying: syscalls-x86-add-__nr_kcmp-syscall-v8-fix
Applying: syscalls-x86-add-__nr_kcmp-syscall-v8-fix-2
Applying: c/r: procfs: add arg_start/end, env_start/end and exit_code members to /proc/$pid/stat
Applying: c/r: prctl: extend PR_SET_MM to set up more mm_struct entries
Applying: c/r: prctl: add ability to set new mm_struct::exe_file
Applying: c-r-prctl-add-ability-to-set-new-mm_struct-exe_file-v2
Applying: c/r: prctl: add ability to get clear_tid_address
Applying: c-r-prctl-add-ability-to-get-clear_tid_address-fix
Applying: ramoops: use pstore interface
Applying: ramoops: fix printk format warnings
Applying: notify_change(): check that i_mutex is held
Merging akpm (37bf584 notify_change(): check that i_mutex is held)
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: build warning after merge of the final tree
From: Stephen Rothwell @ 2012-03-26 4:11 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-next, linux-kernel, Dan Williams
[-- Attachment #1: Type: text/plain, Size: 573 bytes --]
Hi all,
After merging the final tree, today's linux-next build (sparc32 defconfig)
produced these warnings (and many similar):
In file included from drivers/scsi/hosts.c:41:0:
drivers/scsi/scsi_priv.h:166:1: warning: "__enabled_CONFIG_PM" is not defined [-Wundef]
drivers/scsi/scsi_priv.h:166:1: warning: "__enabled_CONFIG_PM_MODULE" is not defined [-Wundef]
Introduced by commit a6a95fad44f1 ("scsi, sd: limit the scope of the
async probe domain").
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: manual merge of the akpm tree with the tip tree
From: Stephen Rothwell @ 2012-03-26 4:01 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-next, linux-kernel, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, Peter Zijlstra, Suresh Siddha, Alex Shi
[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]
Hi all,
Today's linux-next merge of the akpm tree got a conflict in between
commit a6fca40f1d7f ("x86, tlb: Switch cr3 in leave_mm() only when
needed") from the tip tree and commit "x86: use this_cpu_xxx to replace
percpu_xxx funcs" from the akpm tree.
I fixed it up (see below) and can carry the fix as necessary.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
diff --cc arch/x86/mm/tlb.c
index 125bcad,e931db0..0000000
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@@ -61,13 -61,11 +61,13 @@@ static DEFINE_PER_CPU_READ_MOSTLY(int,
*/
void leave_mm(int cpu)
{
- struct mm_struct *active_mm = percpu_read(cpu_tlbstate.active_mm);
- if (percpu_read(cpu_tlbstate.state) == TLBSTATE_OK)
++ struct mm_struct *active_mm = __this_cpu_read(cpu_tlbstate.active_mm);
+ if (__this_cpu_read(cpu_tlbstate.state) == TLBSTATE_OK)
BUG();
- cpumask_clear_cpu(cpu,
- mm_cpumask(__this_cpu_read(cpu_tlbstate.active_mm)));
- load_cr3(swapper_pg_dir);
+ if (cpumask_test_cpu(cpu, mm_cpumask(active_mm))) {
+ cpumask_clear_cpu(cpu, mm_cpumask(active_mm));
+ load_cr3(swapper_pg_dir);
+ }
}
EXPORT_SYMBOL_GPL(leave_mm);
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] -mm/linux-next: procfs: Mark thread stack correctly in proc/<pid>/maps
From: Stephen Rothwell @ 2012-03-26 3:21 UTC (permalink / raw)
To: Siddhesh Poyarekar
Cc: Paul Gortmaker, Andrew Morton, linux-kernel, linux-next,
Alexander Viro, Alexey Dobriyan, Jamie Lokier, KOSAKI Motohiro,
Matt Mackall, Mike Frysinger, Oleg Nesterov, Mark Salter
In-Reply-To: <CAAHN_R1_DordNLDjBfWMHyMJ1yhgwiuQfPvtwQzUKpGMkrJ0jw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 864 bytes --]
Hi Siddhesh,
On Mon, 26 Mar 2012 08:32:35 +0530 Siddhesh Poyarekar <siddhesh.poyarekar@gmail.com> wrote:
>
> On Sun, Mar 25, 2012 at 11:35 PM, Paul Gortmaker
> <paul.gortmaker@windriver.com> wrote:
> > Now it is:
> >
> > mm/nommu.o: In function `vm_is_stack':
> > nommu.c:(.text+0x2178): multiple definition of `vm_is_stack'
> > mm/util.o:util.c:(.text+0x2bc): first defined here
> > make[2]: *** [mm/built-in.o] Error 1
> >
> > http://kisskb.ellerman.id.au/kisskb/buildresult/5941188/
>
> Looks like the problem is because this patch got included in
> linux-next 2 days ago:
>
> http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=47d1ab583408e5b8e900c5080aec9bbcf210df22
I will remove that patch today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH] -mm/linux-next: procfs: Mark thread stack correctly in proc/<pid>/maps
From: Siddhesh Poyarekar @ 2012-03-26 3:02 UTC (permalink / raw)
To: Paul Gortmaker
Cc: Andrew Morton, linux-kernel, linux-next, Alexander Viro,
Alexey Dobriyan, Jamie Lokier, KOSAKI Motohiro, Matt Mackall,
Mike Frysinger, Oleg Nesterov, Mark Salter
In-Reply-To: <CAP=VYLpUzuom-HUS-LYSuQmMZSRvC_Qjgyy9hnKqBowh-95YPQ@mail.gmail.com>
On Sun, Mar 25, 2012 at 11:35 PM, Paul Gortmaker
<paul.gortmaker@windriver.com> wrote:
> Now it is:
>
> mm/nommu.o: In function `vm_is_stack':
> nommu.c:(.text+0x2178): multiple definition of `vm_is_stack'
> mm/util.o:util.c:(.text+0x2bc): first defined here
> make[2]: *** [mm/built-in.o] Error 1
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/5941188/
Looks like the problem is because this patch got included in
linux-next 2 days ago:
http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=47d1ab583408e5b8e900c5080aec9bbcf210df22
When I had consolidated all of these changes into what Andrew got the
v3 patch from, this patch should have been removed since I moved this
function definition from memory.c and nommu.c into util.c, but it
looks like the patch got merged in once again, causing the build error
above. Dropping this patch should be sufficient to fix the build
problem. This is also the reason why the March 22 build was successful
(with my final changes) and the March 24 build wasn't (with this
additional patch).
--
Siddhesh Poyarekar
http://siddhesh.in
^ permalink raw reply
* Re: linux-next: build failure after merge of the battery tree
From: Stephen Rothwell @ 2012-03-26 2:13 UTC (permalink / raw)
To: Anton Vorontsov; +Cc: linux-next, linux-kernel, Arun Murthy, Linus Walleij
In-Reply-To: <20120320153912.b97107ca4128d0692de17799@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 2200 bytes --]
Hi Anton,
On Tue, 20 Mar 2012 15:39:12 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Thu, 15 Mar 2012 13:56:09 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the battery tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/power/ab8500_btemp.c: In function 'ab8500_btemp_batctrl_volt_to_res':
> > drivers/power/ab8500_btemp.c:142:2: error: implicit declaration of function 'is_ab8500_1p1_or_earlier' [-Werror=implicit-function-declaration]
> > drivers/power/ab8500_btemp.c: In function 'ab8500_btemp_templow_handler':
> > drivers/power/ab8500_btemp.c:619:2: error: implicit declaration of function 'is_ab8500_2p0_or_earlier' [-Werror=implicit-function-declaration]
> > drivers/power/ab8500_charger.c: In function 'ab8500_charger_ac_en':
> > drivers/power/ab8500_charger.c:1126:3: error: implicit declaration of function 'is_ab8500_1p1_or_earlier' [-Werror=implicit-function-declaration]
> > drivers/power/ab8500_charger.c: In function 'ab8500_charger_remove':
> > drivers/power/ab8500_charger.c:2519:2: error: implicit declaration of function 'usb_unregister_notifier' [-Werror=implicit-function-declaration]
> > drivers/power/ab8500_charger.c:2520:2: error: implicit declaration of function 'usb_put_transceiver' [-Werror=implicit-function-declaration]
> > drivers/power/ab8500_charger.c: In function 'ab8500_charger_probe':
> > drivers/power/ab8500_charger.c:2688:2: error: implicit declaration of function 'usb_get_transceiver' [-Werror=implicit-function-declaration]
> > drivers/power/ab8500_charger.c:2688:14: warning: assignment makes pointer from integer without a cast [enabled by default]
> > drivers/power/ab8500_charger.c:2695:2: error: implicit declaration of function 'usb_register_notifier' [-Werror=implicit-function-declaration]
> >
> > Caused by commits 89449ac8d6d2 ("ab8500-charger: AB8500 charger driver")
> > and 20ac1aed6206 ("ab8500-btemp: AB8500 battery temperature driver").
> >
> > I have used the battery tree form next-20120314 for today.
>
> Still getting this build failure.
Ping?
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* linux-next: build failure after merge of the scsi tree
From: Stephen Rothwell @ 2012-03-26 1:17 UTC (permalink / raw)
To: James Bottomley; +Cc: linux-next, linux-kernel, Alexey Dobriyan, Greg KH
[-- Attachment #1: Type: text/plain, Size: 2892 bytes --]
Hi James,
After merging the scsi tree, today's linux-next build (x86_64 allmodconfig)
failed like this:
drivers/staging/keucr/scsiglue.c:349:2: error: unknown field 'proc_info' specified in initializer
drivers/staging/rts_pstor/rtsx.c:258:2: error: unknown field 'proc_info' specified in initializer
drivers/staging/rts5139/rts51x_scsi.c:2190:2: error: unknown field 'proc_info' specified in initializer
Caused by commit 104c4fe25dc9 ("[SCSI] remove scsi_host_template::proc_info").
Since this is a staging driver, I applied these following patches:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 26 Mar 2012 12:07:35 +1100
Subject: [PATCH] scsi: disable broken staging driver
This driver is broken by commit 104c4fe25dc9 ("[SCSI] remove
scsi_host_template::proc_info") from the scsi tree.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/staging/keucr/Kconfig | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/staging/keucr/Kconfig b/drivers/staging/keucr/Kconfig
index ba756bf..aef4858 100644
--- a/drivers/staging/keucr/Kconfig
+++ b/drivers/staging/keucr/Kconfig
@@ -1,6 +1,6 @@
config USB_ENESTORAGE
tristate "USB ENE SM card reader support"
- depends on USB && SCSI && m
+ depends on USB && SCSI && m && BROKEN
---help---
Say Y here if you wish to control a ENE SM Card reader.
To use SD/MS card, please build driver/usb/storage/ums-eneub6250.ko
--
1.7.9.1
From 4c836f9935ea1d2b2bc365aa1af70afbb2545311 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Mon, 26 Mar 2012 12:13:34 +1100
Subject: [PATCH] scsi: disable more staging drivers due to scsi breakage
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/staging/rts5139/Kconfig | 2 +-
drivers/staging/rts_pstor/Kconfig | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/staging/rts5139/Kconfig b/drivers/staging/rts5139/Kconfig
index afd526b..56bff83 100644
--- a/drivers/staging/rts5139/Kconfig
+++ b/drivers/staging/rts5139/Kconfig
@@ -1,6 +1,6 @@
config RTS5139
tristate "Realtek RTS5139 USB card reader support"
- depends on USB && SCSI
+ depends on USB && SCSI && BROKEN
help
Say Y here to include driver code to support the Realtek
RTS5139 USB card readers.
diff --git a/drivers/staging/rts_pstor/Kconfig b/drivers/staging/rts_pstor/Kconfig
index 4d66a99..1980a49 100644
--- a/drivers/staging/rts_pstor/Kconfig
+++ b/drivers/staging/rts_pstor/Kconfig
@@ -1,6 +1,6 @@
config RTS_PSTOR
tristate "RealTek PCI-E Card Reader support"
- depends on PCI && SCSI
+ depends on PCI && SCSI && BROKEN
help
Say Y here to include driver code to support the Realtek
PCI-E card readers.
--
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
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