Hi Anton,
Anton Blanchard writes:
> Hi Nikunj,
>
>> From: Nikunj A Dadhania
>>
>> powerpc/numa: initialize distance lookup table from drconf path
>>
>> In some situations, a NUMA guest that supports
>> ibm,dynamic-memory-reconfiguration node will end up having flat NUMA
>> distances between n
> [Adding Rob]
Rob is not the only DT Maintainer, there are many of them. The DT
list was CC'ed, which they are all part of. Adding them all
separately is not required IMO.
> On 22-06-15, 16:43, Lee Jones wrote:
>
> At least some description was required here on why you need additional
> bindi
Hi Baptiste, Alex,
On 06/23/2015 08:56 AM, Baptiste Reynal wrote:
> On Mon, Jun 22, 2015 at 6:26 PM, Alex Williamson
> wrote:
>> On Mon, 2015-06-22 at 17:56 +0200, Eric Auger wrote:
>>> Hi Baptiste,
>>>
>>> No unfortunately I don't have any HW to test this currently. I just
>>> test-compiled this.
On Tue, 23 Jun 2015, Viresh Kumar wrote:
> On 22-06-15, 16:43, Lee Jones wrote:
> > This also incorporates the STiH410.
>
> Any explanation to why this patch is part of this series ?
Because the CPUFreq regulator is controlled with PWM and CPUFreq will
fail on STiH410 (my main development platfor
On Tue, 23 Jun 2015, Viresh Kumar wrote:
> [Ccing Rob]
Rob is already Cc'ed.
> On 22-06-15, 16:43, Lee Jones wrote:
> > Signed-off-by: Lee Jones
> > ---
> > arch/arm/boot/dts/stih407-family.dtsi | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/boot/dts/stih407-fami
In data martedì 23 giugno 2015 08:39:47, Daniel Vetter ha scritto:
> On Mon, Jun 22, 2015 at 04:04:20PM +0200, Fabio Coatti wrote:
> > Hi All,
> >
> > just compiled 4.1 and just got this warning, twice, in my dmesg:
> >
> >
> > [lun giu 22 11:43:18 2015] [ cut here ]
> >
Hi Rafael,
On Tue, Jun 23, 2015 at 1:41 AM, Rafael J. Wysocki wrote:
> On Monday, June 22, 2015 09:31:22 AM Geert Uytterhoeven wrote:
>> If pm_genpd_{add,remove}_device() keeps on failing with -EAGAIN, we end
>> up with an infinite loop in genpd_dev_pm_{at,de}tach().
>>
>> This may happen due to
Thanks for your timely review Viresh.
On Tue, 23 Jun 2015, Viresh Kumar wrote:
> On 22-06-15, 16:43, Lee Jones wrote:
> > +config ARM_ST_CPUFREQ
> > + bool "ST CPUFreq support"
>
> Isn't using ST just too generic? There are multiple SoCs ST has been
> involved with, I have worked on a completel
On Tue, Jun 23, 2015 at 12:57:39AM +0200, Oleg Nesterov wrote:
> > +
> > + lock_map_acquire_read(&cpu_hotplug.rwsem.rw_sem.dep_map);
> > + _percpu_down_read(&cpu_hotplug.rwsem);
> > }
>
> Confused... Why do we need _percpu_down_read()? Can't get_online_cpus()
> just use percpu_down_read() ?
>
From: Mahesh Bandewar
Date: Mon, 22 Jun 2015 10:45:15 -0700
> On Tue, Jun 16, 2015 at 7:35 AM, Noam Camus wrote:
>> @@ -0,0 +1,27 @@
>> +#
>> +# EZchip network device configuration
>> +#
>> +
>> +config NET_VENDOR_EZCHIP
>> + bool "EZchip devices"
>> + default y
>>
> Why this has to
On Mon, 22 Jun 2015, Daniel Vetter wrote:
> On Mon, Jun 22, 2015 at 04:33:22PM +0530, Varka Bhadram wrote:
> > Hi Shobhit Kumar,
> >
> > On 06/22/2015 04:24 PM, Shobhit Kumar wrote:
> >
> > >On some BYT PLatform the PWM is controlled using CRC PMIC. Add a lookup
> > >entry for the same to be use
On Mon, Jun 22, 2015 at 08:06:00PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Tue, Jun 23, 2015 at 12:36:01AM +0200, Jiri Olsa escreveu:
> > hi,
> > adding the possibility to display stat data per thread.
> >
> > Allowing following commands and output:
> >
> > $ perf stat -e cycles,instructio
On Tue, Jun 23, 2015 at 8:41 AM, Greg KH wrote:
>> The current state of uncertainty is problematic, I think. The kdbus
>> team is spending a lot of time making things compatible with kdbus,
>> and the latest systemd release makes kdbus userspace support
>> mandatory.
>
> I stopped here in this em
Hi,
On 23 June 2015 at 07:39, Daniel Vetter wrote:
> Which drm driver are you using? I didn't spot anything in your module list
> but might have missed it. Booting with drm.debug=0xe and grabbing dmesg
> will tell us for sure.
That'd be vgem.
Cheers,
Daniel
--
To unsubscribe from this list: sen
On Fri, 19 Jun 2015, Greg Kroah-Hartman wrote:
> 4.0-stable review patch. If anyone has any objections, please let me know.
The commit to be backported is already reverted in upstream, and I just
got an email from you backporting the revert as well... would be best to
*not* backport either of th
A bit off-topic probably
but maybe this should not be in kernel/locking/percpu-rwsem.c but in a
generic percpu location as this construct is present in the core a few times
atleast in:
kernel/irq/irqdesc.c:kstat_irqs
kernel/fork.c:nr_processes
mm/memcontrol.c:mem_cgroup_read_events
mm/memcontr
On 06/23/2015 09:16 AM, Lee Jones wrote:
Thanks for your timely review Viresh.
On Tue, 23 Jun 2015, Viresh Kumar wrote:
On 22-06-15, 16:43, Lee Jones wrote:
+config ARM_ST_CPUFREQ
+ bool "ST CPUFreq support"
Isn't using ST just too generic? There are multiple SoCs ST has been
involved
* Jiang Liu wrote:
> The data type resource_size_t may be 32 bits or 64 bits depending on
> CONFIG_PHYS_ADDR_T_64BIT. So reject ACPI resource descriptors which
> will cause resource_size_t overflow with 32bit kernel
>
> This issue was triggered on a platform running 32bit kernel with an
> ACPI
* Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> On built-in kernels this will always splat. Fix that.
>
> Reported-by: Fengguang Wu [0-day test robot]
> Signed-off-by: Luis R. Rodriguez
> ---
> drivers/media/pci/ivtv/ivtvfb.c | 6 --
> 1 file changed, 4 insertions(+), 2 dele
* Luis R. Rodriguez wrote:
> From: "Luis R. Rodriguez"
>
> On built-in kernels this will always splat. Fix that.
>
> Reported-by: Fengguang Wu [0-day test robot]
> Signed-off-by: Luis R. Rodriguez
> ---
> drivers/infiniband/hw/ipath/ipath_driver.c | 6 --
> 1 file changed, 4 insertions
Hi Russell,
On Mon, Jun 22, 2015 at 11:18 PM, Russell King - ARM Linux
wrote:
> On Mon, Jun 22, 2015 at 10:52:13PM +0200, Geert Uytterhoeven wrote:
>> On Mon, Jun 22, 2015 at 10:48 PM, Geert Uytterhoeven
>> wrote:
>> > JFYI, when comparing v4.1[1] to v4.1-rc8[3], the summaries are:
>> > - buil
When dumping events with 'perf report -D' the event print
always starts with a newline (see dump_event()). Do the
same with the "Aggregated stats" print so that it is not
jammed up against the last event print.
Signed-off-by: Adrian Hunter
---
tools/perf/util/session.c | 2 +-
1 file changed, 1
On 23-06-15, 08:06, Lee Jones wrote:
> > [Adding Rob]
>
> Rob is not the only DT Maintainer, there are many of them. The DT
> list was CC'ed, which they are all part of. Adding them all
> separately is not required IMO.
I didn't Cc him because you missed him, but because we have been
discussing
On 23-06-15, 08:08, Lee Jones wrote:
> Because the CPUFreq regulator is controlled with PWM and CPUFreq will
> fail on STiH410 (my main development platform) without it.
I see, probably this should find a place in the cover-letter :)
> It's safe for you to ignore it though.
Thanks :)
--
viresh
With 'perf report -D' the PERF_RECORD_FINISHED_ROUND
event was printed without a newline, resulting in:
0x91a18 [0x8]: PERF_RECORD_FINISHED_ROUNDAggregated stats
Other events print their details, but PERF_RECORD_FINISHED_ROUND
doesn't have any so just add a print for a newline.
Signed-of
On Thu, Jun 04, K. Y. Srinivasan wrote:
> +++ b/arch/x86/kernel/cpu/mshyperv.c
> @@ -18,6 +18,9 @@
> #include
> #include
> #include
> +#ifdef CONFIG_KEXEC
> +#include
> +#endif
Is this #ifdef required?
Olaf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Mam vzajemne mit prospech podnik pro nas oba. pokud mate zajem, muzete mi
dostat na e-mailovou adresu a pro detaily a vysvetlení.
E-mail: jgg.c...@gmail.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More maj
On 23-06-15, 08:10, Lee Jones wrote:
> > These virtual nodes aren't allowed in DT and you have added them
> > before the bindings patch :).
>
> This isn't a virtual node, but you bring up a good point.
Hmm, wrong choice of words. Sorry..
So, its a node for a virtual device :). The device is CPU
ARCv2 based HS38 cores are weakly ordered and thus explicit barriers for
kernel proper.
SMP barrier is provided by DMB instruction which also guarantees local
barrier hence used as backend of smp_*mb() as well as *mb() APIs
Also hookup barriers into MMIO accessors to avoid ordering issues in IO
A quad core SMP build could get into hardware livelock with concurrent
LLOCK/SCOND. Workaround that by adding a PREFETCHW which is serialized by
SCU (System Coherency Unit). It brings the cache line in Exclusive state
and makes others invalidate their lines. This gives enough time for
winner to com
The idea of runnable load average (let runnable time contribute to weight)
was proposed by Paul Turner, and it is still followed by this rewrite. This
rewrite aims to solve the following issues:
1. cfs_rq's load average (namely runnable_load_avg and blocked_load_avg) is
updated at the granulari
Hi Peter and Ingo,
The 9th version has the following changes, would you please give it a look?
1) util_avg fix
2) update_tg_load_avg() in update_blocked_averages(), because
cfs_rq's load_avg is updated
3) Add some debug print
Thanks to Boqun for his tests and thoughts. Thanks to Dietmar for t
On 23/06/2015 04:29, Xiao Guangrong wrote:
>>>
>>>
>>> If so, can you look at kvm/queue and see if it is okay for you (so that
>>> we can get the series in 4.2)?
>>
>> Ping?
>>
>> If I don't get testing results before Wednesday, I'll drop this series
>> from the 4.2 pull request.
>
> Paolo, sorr
On Mon, 2015-06-22 at 16:43 +0100, Lee Jones wrote:
> --- a/drivers/cpufreq/Kconfig.arm
> +++ b/drivers/cpufreq/Kconfig.arm
> +config ARM_ST_CPUFREQ
> +>> bool "ST CPUFreq support"
> +>> depends on SOC_STIH407
> +>> help
> +>> OPP list for cpufreq-dt driver can be provided throu
The runnable load and utilization averages of cfs_rq's sched_entity
were not initiated. Like done to a task, give new cfs_rq' sched_entity
start values to heavy its load in infant time.
Signed-off-by: Yuyang Du
---
kernel/sched/core.c | 2 +-
kernel/sched/fair.c | 11 ++-
kernel/sched
When task exits or group is destroyed, the entity's load should be
removed from its parent cfs_rq's load. Otherwise, it will take time
for the parent cfs_rq to decay the dead entity's load to 0, which
is not desired.
Signed-off-by: Yuyang Du
---
kernel/sched/fair.c | 11 ++-
1 file chang
The per-rq runnable averages (rq->avg) was introduced by Ben with this commit:
commit 18bf2805d9b30cb823d4919b42cd230f59c7ce1f
Author: Ben Segall
Date: Thu Oct 4 12:51:20 2012 +0200
sched: Maintain per-rq runnable averages
Since runqueues do not have a corresponding sched_entity we in
On Mon, Jun 22, 2015 at 06:25:11AM -0500, Greg Donald wrote:
> Umm.. you have to fix more than one error if there's more than one
> error on or very near the same line you are already fixing, else
> checkpatch.pl complains that your patch has errors. Not to mention
> Greg KH has never complained:
Lukasz Stelmach wrote:
> A bit, suddenly by desktop PC started to fail to resume. [...]
> The failing code is somewhere around line 2400 of
> drivers/firewire/ohci.c (the latest mainline).
>0x003f <+31>: callq 0xb037
>0x0044 <+36>: mov0x898(%rbx),%
On Monday 22 June 2015 07:06 PM, Will Deacon wrote:
>> OK, so given that regular/mmio is also weakly ordered, it would seem that we
>> need
>> > full mb() *before* and *after* the IO access in the non relaxed API. ARM
>> > code
>> > seems to put a rmb() after the readl and wmb() before the writel
On 23-06-15, 08:16, Lee Jones wrote:
> Thanks for your timely review Viresh.
Your welcome Lee :)
> On Tue, 23 Jun 2015, Viresh Kumar wrote:
> > On 22-06-15, 16:43, Lee Jones wrote:
> > > +config ARM_ST_CPUFREQ
> > > + bool "ST CPUFreq support"
> >
> > Isn't using ST just too generic? There are m
On Tue, Jun 23, 2015 at 11:03:34AM +0530, Sudip Mukherjee wrote:
> On Mon, Jun 22, 2015 at 07:06:49PM +0530, Sudip Mukherjee wrote:
> > On Mon, Jun 22, 2015 at 03:02:37PM +0200, Peter Karlsson wrote:
> > > On 2015-06-22 06:29, Sudip Mukherjee wrote:
> > > > which tree have you been using?
> > > > G
* Srikar Dronamraju wrote:
> * Rik van Riel [2015-06-16 10:39:13]:
>
> > On 06/16/2015 07:56 AM, Srikar Dronamraju wrote:
> > > This is consistent with all other load balancing instances where we
> > > absorb unfairness upto env->imbalance_pct. Absorbing unfairness upto
> > > env->imbalance_pc
From: Tang Yuantian
There is a RCPM (Run Control/Power Management) in Freescale QorIQ
series processors. The device performs tasks associated with device
run control and power management.
The driver implements some features: mask/unmask irq, enter/exit low
power states, freeze time base, etc.
S
On Tue, Jun 23, 2015 at 11:05:47AM +0300, Dan Carpenter wrote:
> On Tue, Jun 23, 2015 at 11:03:34AM +0530, Sudip Mukherjee wrote:
> > On Mon, Jun 22, 2015 at 07:06:49PM +0530, Sudip Mukherjee wrote:
> > > On Mon, Jun 22, 2015 at 03:02:37PM +0200, Peter Karlsson wrote:
> > > > On 2015-06-22 06:29, S
This commit fix kernel crash when probing for rfkill devices in dell-laptop
driver failed. Function free_page() was incorrectly used on struct page *
instead of virtual address of SMI buffer.
This commit also simplify allocating page for SMI buffer by using
__get_free_page() function instead of se
Hello everybody,
with Linux 4.0.5 everything was perfectly fine, Linux 4.0.6 breaks the setup
on one of my systems: Only three of my logical volumes are available, systemd
reports:
lvm2-pvscan@254:3.service: State 'stop-sigterm' timed out. Killing.
Followed by a lot of failed dependencies. The s
Linus,
please pull the latest sched-locking-for-linus git tree from:
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
sched-locking-for-linus
These locking updates depend on the alreay merged sched/core branch:
- Lockless top waiter wakeup for rtmutex (Davidlohr)
Hi all,
Changes since 20150622:
The drm-exynos tree gained a build failure so I used the version from
next-20150622.
Non-merge commits (relative to Linus' tree): 11719
9842 files changed, 1023630 insertions(+), 237137 deletions(-)
---
From: Nicolas Ferre
Date: Thu, 18 Jun 2015 16:27:19 +0200
> This series is basically the support for another flavor of the GEM IP
> configuration. It ended up being a series because of some little fixes made to
> the binding documentation before adding the new compatibility string.
...
> v2: - f
On 22/06/15 23:48, Stephen Boyd wrote:
On 06/10, Daniel Thompson wrote:
This patchset implements a clock driver for STM32F42xxx and STM32F43xxx
series devices. It supports decoding the state configured by the
bootloader (PLL, clock select, bus dividers) and all the gates clocks.
It does not curr
On 2015/06/20, 10:58 AM, "Julia Lawall" wrote:
>!x is more normal for kzalloc failure in the kernel.
While "!x" might be more normal for kzalloc(), I don't see that as an
improvement over explicitly checking against NULL, which is what kzalloc()
and other memory-allocating functions return on er
On Mon, 22 Jun 2015, Ankit Gupta wrote:
> Add chip name and hw-irq number to the trace_irq_handler_entry()
> tracepoint. When tracing interrupt events the chip-name and hw-irq
> numbers are stable and known in advance. This makes them a better
> choice as a filtering criteria for the trace buffer
On 23/06/15 00:21, Stephen Boyd wrote:
On 06/10, Daniel Thompson wrote:
The driver supports decoding and statically modelling PLL state (i.e.
we inherit state from bootloader) and provides support for all
peripherals that support simple one-bit gated clocks. The covers all
peripherals whose cloc
On Tue, 23 Jun 2015, Viresh Kumar wrote:
> On 23-06-15, 08:16, Lee Jones wrote:
> > Thanks for your timely review Viresh.
>
> Your welcome Lee :)
>
> > On Tue, 23 Jun 2015, Viresh Kumar wrote:
> > > On 22-06-15, 16:43, Lee Jones wrote:
> > > > +config ARM_ST_CPUFREQ
> > > > + bool "ST CPUF
On Tue, 23 Jun 2015, Paul Bolle wrote:
> On Mon, 2015-06-22 at 16:43 +0100, Lee Jones wrote:
> > --- a/drivers/cpufreq/Kconfig.arm
> > +++ b/drivers/cpufreq/Kconfig.arm
>
> > +config ARM_ST_CPUFREQ
> > +> > bool "ST CPUFreq support"
> > +> > depends on SOC_STIH407
> > +> > help
> > +> > OP
On Jun 23, 2015, at 2:23 AM, Julia Lawall wrote:
> It seems that libcfs_kvzalloc doesn't use any particular threshold or
> switchingbetween kzalloc and vmalloc, so can be replaced by ths function
> too?
If you mean to replace all instances of LIBCFS_ALLOC with libcfs_kvzalloc (and
all frees w
On 23-06-15, 09:27, Lee Jones wrote:
> Okay, but the reasoning is the same. I consider the function to have
> failed, but the over-all failure culminates in just a warning that
> voltage scaling has indeed failed, but we can still go on with
> frequency scaling.
Ahh, I thought that the other opp-
On 06/23/2015 04:00 PM, Paolo Bonzini wrote:
On 23/06/2015 04:29, Xiao Guangrong wrote:
If so, can you look at kvm/queue and see if it is okay for you (so that
we can get the series in 4.2)?
Ping?
If I don't get testing results before Wednesday, I'll drop this series
from the 4.2 pull r
On Tue, Jun 23, 2015 at 03:57:48AM +0100, Waiman Long wrote:
> On 06/22/2015 12:21 PM, Will Deacon wrote:
> > On Fri, Jun 19, 2015 at 04:50:02PM +0100, Waiman Long wrote:
> >> The current cmpxchg() loop in setting the _QW_WAITING flag for writers
> >> in queue_write_lock_slowpath() will contend wit
On Tue, 23 Jun 2015, Viresh Kumar wrote:
> On 23-06-15, 08:06, Lee Jones wrote:
> > > [Adding Rob]
> >
> > Rob is not the only DT Maintainer, there are many of them. The DT
> > list was CC'ed, which they are all part of. Adding them all
> > separately is not required IMO.
>
> I didn't Cc him be
From: Noam Camus
Simple LAN device for debug or management purposes.
Device supports interrupts for RX and TX(completion).
Device does not have DMA ability.
Signed-off-by: Noam Camus
Signed-off-by: Tal Zilcer
Acked-by: Alexey Brodkin
---
Change log for v7:
1) Update nps_enet_open() comment h
Hi Vineet,
On Tue, Jun 23, 2015 at 08:58:03AM +0100, Vineet Gupta wrote:
> ARCv2 based HS38 cores are weakly ordered and thus explicit barriers for
> kernel proper.
>
> SMP barrier is provided by DMB instruction which also guarantees local
> barrier hence used as backend of smp_*mb() as well as *
Hello Lee and Viresh,
On Tue, Jun 23, 2015 at 10:38 AM, Lee Jones wrote:
> On Tue, 23 Jun 2015, Viresh Kumar wrote:
>> On 23-06-15, 08:06, Lee Jones wrote:
>> >
>> > > Over that, this patch should have been present before any other
>> > > patches using these bindings.
>> >
>> > I've never heard t
Hi!
My eyes just discovered this mis-alignment for x86_64 machines:
---
# cat /proc/meminfo
MemTotal: 81366016 kB
MemFree:36484504 kB
Buffers: 1018764 kB
Cached: 38230264 kB
[...]
VmallocTotal: 34359738367 kB
VmallocUsed: 92792 kB
VmallocChunk: 34359544432
* Borislav Petkov wrote:
> On Mon, Jun 22, 2015 at 09:26:13AM -0700, Andy Lutomirski wrote:
>
> > notify_die is misnamed and has little to do with death. It's really just
> > notifying about an exception, and we might end up oopsing, sending a
> > signal,
> > or neither.
>
> But if we oops a
On Sat, Jun 20, 2015 at 12:54:02PM +0530, Sudip Mukherjee wrote:
> On Fri, Jun 19, 2015 at 12:48:19PM -0700, Isaac Assegai wrote:
> > Place braces on previous lines in ddk750_sii164.c to
> > rectify the following checkpatch errors:
> > ERROR: that open brace { should be on the previous line
> >
>
On Tue, Jun 23, 2015 at 12:39 AM, Ingo Molnar wrote:
> Same observation as for the other patch: please only warn if the hardware is
> present and the driver tries to activate. No need to annoy others.
Will fix, and respin.
Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-
This patch adds DEV_TO_DEV support for i.MX SDMA driver to support data
transfer between two peripheral FIFOs.
The per_2_per script requires two peripheral addresses and two DMA
requests, and it need to check the src addr and dst addr is in the SPBA
bus space or in the AIPS bus space.
Signed-off-b
On Tue, 23 Jun 2015, Javier Martinez Canillas wrote:
> Hello Lee and Viresh,
>
> On Tue, Jun 23, 2015 at 10:38 AM, Lee Jones wrote:
> > On Tue, 23 Jun 2015, Viresh Kumar wrote:
> >> On 23-06-15, 08:06, Lee Jones wrote:
> >> >
> >> > > Over that, this patch should have been present before any oth
Hi Mike,
On Mon, Jun 22, 2015 at 10:46 PM, Michael Turquette
wrote:
>> The MSTP block provides two functions:
>> 1. Module Standby: "Clock supply to specified modules is stopped by
>> setting the module stop control register bits."
>> However, the clock supply to a module is not stopp
On 23-06-15, 09:38, Lee Jones wrote:
> Do you always write your documentation before implementing a
> feature?
>
> Surely it goes;
> Requirements Gathering
> Plan and Prepare
> Implement
> Test
> Document
> Deliver
>
> ;)
DT bindings aren't just simple documentation of how things are
On Tue, 23 Jun 2015, Viresh Kumar wrote:
> On 23-06-15, 09:27, Lee Jones wrote:
> > Okay, but the reasoning is the same. I consider the function to have
> > failed, but the over-all failure culminates in just a warning that
> > voltage scaling has indeed failed, but we can still go on with
> > fr
* Mike Travis wrote:
> <<<
> We have a large university system in the UK that is experiencing
> very long delays modprobing the driver for a specific I/O device.
> The delay is from 8-10 minutes per device and there are 31 devices
> in the system. This 4 to 5 hour delay in starting up those I/O
Hi Linus,
please pull from the 'for-linus' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus
to receive the following updates:
Pretty boring for a merge window pull.
One change in behaviour is the patch for dasd driver, the module which
provides the diagn
Hi Will,
On Tuesday 23 June 2015 02:19 PM, Will Deacon wrote:
>> +/*
>> > + * MMIO can also get buffered/optimized in micro-arch, so barriers needed
>> > + * Based on ARM model for the typical use case
>> > + *
>> > + *
>> > + *
>> > + * or:
>> > + *
>> > + *
> Th
在 2015/6/19 7:52, Thomas Gleixner 写道:
> On Mon, 15 Jun 2015, majun (F) wrote:
>> 在 2015/6/12 18:48, Thomas Gleixner 写道:
>>> Can you please provide a proper description of this mbigen chip and
>>> explain WHY you think that it needs all this special hackery?
>
> You carefully avoided to provide a
Hi Neil,
Am 01.06.2015 um 23:37 schrieb NeilBrown :
> On Mon, 1 Jun 2015 19:06:52 +0530 Kishon Vijay Abraham I
> wrote:
>
>> Hi,
>>
>> On Thursday 16 April 2015 01:33 PM, NeilBrown wrote:
>>> From: NeilBrown
>>>
>>> The twl4030 phy can measure, with low precision, the
>>> resistance-to-groun
On Mon, Jun 22, 2015 at 11:41:40PM -0700, Greg KH wrote:
> On Mon, Jun 22, 2015 at 11:06:09PM -0700, Andy Lutomirski wrote:
> > Hi Linus,
> >
> > Can you opine as to whether you think that kdbus should be merged?
>
> Ah, a preemptive pull request denial, how nice.
I think you're misunderstanding
On Tue, Jun 9, 2015 at 6:31 AM, Guenter Roeck wrote:
> On 06/08/2015 07:08 PM, Stephan Mueller wrote:
>> ---8<---
>> Replace the global -O0 compiler flag from the Makefile with GCC
>> pragmas to mark only the functions required to be compiled without
>> optimizations.
>>
>> This patch also adds a
On Tue, Jun 23, 2015 at 11:17:23AM +0200, Geert Uytterhoeven wrote:
>
> I get that too with m68k-linux-gcc-4.6.3 and m68k-linux-gcc-4.9.0.
>
> With m68k-linux-gnu-gcc-4.1, which is still my default cross-compiler due
> to the good unused warning reporting, I get:
>
> crypto/jitterentropy.c:235:
From: Stas Sergeev
Date: Thu, 18 Jun 2015 18:36:03 +0300
>
> The commit 898b2970e2c9 ("mvneta: implement SGMII-based in-band link state
> signaling")
> changed mvneta_adjust_link() so that it does not clear the auto-negotiation
> bits in MVNETA_GMAC_AUTONEG_CONFIG register. This was necessary fo
On Tue, Jun 23, 2015 at 08:25:05AM +, Dilger, Andreas wrote:
> I've found in the past that developers can introduce bugs when they treat
> return values as boolean when they really aren't.
I can imagine a bug like that where a function can return 0-2 and people
do:
if (ret)
instead o
On Mon, Jun 22, 2015 at 10:11:35PM +0200, Stefan Agner wrote:
> On 2015-06-22 19:26, Johan Hovold wrote:
> > Instead, hang the gpio chip directly off the usb interface (not the
> > port), add a new config option, and keep the gpio implementation under
> > drivers/usb/serial (possibly in its own fi
2015-06-23 10:22 GMT+02:00 Daniel Thompson :
> On 22/06/15 23:48, Stephen Boyd wrote:
>>
>> On 06/10, Daniel Thompson wrote:
>>>
>>> This patchset implements a clock driver for STM32F42xxx and STM32F43xxx
>>> series devices. It supports decoding the state configured by the
>>> bootloader (PLL, cloc
Hi Linus,
The IOMMU changes have conflicts this time with IRQ related patches
coming from the tip tree. Some of the IRQ patches there also touch the
Intel and AMD interrupt remapping code in drivers/iommu, which conflicts
with the Intel VT-d kdump fixes.
I attached my resolution of the conflicts
On Tue, Jun 23, 2015 at 01:28:03PM +0530, Vineet Gupta wrote:
> +/*
> + * MMIO can also get buffered/optimized in micro-arch, so barriers needed
> + * Based on ARM model for the typical use case
> + *
> + *
> + *
> + * or:
> + *
> + *
> + *
> + * http://www.spinics.net
[]..
+Example:
+
+ qfprom: qfprom@0070 {
+ compatible = "qcom,qfprom";
+ reg = <0x0070 0x8000>;
+ ...
+ /* Data cells */
+ tsens_calibration: calib@404 {
+ reg = <0x4404 0x1
On Tue, Jun 23, 2015 at 10:03:25AM +0100, Vineet Gupta wrote:
> On Tuesday 23 June 2015 02:19 PM, Will Deacon wrote:
> >> +/*
> >> > + * MMIO can also get buffered/optimized in micro-arch, so barriers
> >> > needed
> >> > + * Based on ARM model for the typical use case
> >> > + *
> >> > + *
Am Dienstag, 23. Juni 2015, 09:22:40 schrieb Richard Weinberger:
> On Tue, Jun 23, 2015 at 8:41 AM, Greg KH
wrote:
> >> The current state of uncertainty is problematic, I think. The kdbus
> >> team is spending a lot of time making things compatible with kdbus,
> >> and the latest systemd release
Hi Joe,
> On Jun 23, 2015, at 05:52 , Joe Perches wrote:
>
> On Tue, 2015-06-23 at 00:08 +0100, Srinivas Kandagatla wrote:
>> This patch adds just providers part of the framework just to enable easy
>> review.
> []
>> include/linux/nvmem-provider.h | 54 ++
>
> Unless there are going to be
On Tue, 23 Jun 2015, majun (F) wrote:
> 在 2015/6/19 7:52, Thomas Gleixner 写道:
> > On Mon, 15 Jun 2015, majun (F) wrote:
> >> 在 2015/6/12 18:48, Thomas Gleixner 写道:
> >>> Can you please provide a proper description of this mbigen chip and
> >>> explain WHY you think that it needs all this special ha
On 06/22/2015 09:05 PM, Peter Zijlstra wrote:
> On Mon, Jun 22, 2015 at 08:11:14PM +0200, Daniel Wagner wrote:
>> On 06/22/2015 02:16 PM, Peter Zijlstra wrote:
>>> Also, since Linus thinks lglocks is a failed locking primitive (which I
>>> whole
>>> heartedly agree with, its preempt-disable latenc
On Tue, 23 Jun 2015, Dan Carpenter wrote:
> On Tue, Jun 23, 2015 at 08:25:05AM +, Dilger, Andreas wrote:
> > I've found in the past that developers can introduce bugs when they treat
> > return values as boolean when they really aren't.
>
> I can imagine a bug like that where a function can re
Am Dienstag, 23. Juni 2015, 11:25:49 schrieb Martin Steigerwald:
> Am Dienstag, 23. Juni 2015, 09:22:40 schrieb Richard Weinberger:
> > On Tue, Jun 23, 2015 at 8:41 AM, Greg KH
>
> wrote:
> > >> The current state of uncertainty is problematic, I think. The kdbus
> > >> team is spending a lot of
In the (not so unlikely) case that the mmc controller timeout budget is
enough for exactly one erase-group, the simplification of allowing one
sector has an enormous performance penalty. We optimize this special case
by introducing a flag that prohibits erase-group boundary crossing, so
that we can
Am Dienstag, 23. Juni 2015, 17:21:06 schrieb Herbert Xu:
Hi Herbert,
>On Tue, Jun 23, 2015 at 11:17:23AM +0200, Geert Uytterhoeven wrote:
>> I get that too with m68k-linux-gcc-4.6.3 and m68k-linux-gcc-4.9.0.
>>
>> With m68k-linux-gnu-gcc-4.1, which is still my default cross-compiler due
>> to th
On Tue, Jun 23, 2015 at 08:27:13AM +0100, Daniel Stone wrote:
> Hi,
>
> On 23 June 2015 at 07:39, Daniel Vetter wrote:
> > Which drm driver are you using? I didn't spot anything in your module list
> > but might have missed it. Booting with drm.debug=0xe and grabbing dmesg
> > will tell us for su
On Mon, 22 Jun, at 06:11:31AM, Matt Fleming wrote:
>
> Right, but see my previous comment about x86 discarding a bunch of
> attributes for memory regions because the kernel "knows better".
>
> And in most places, yes, the kernel really does know better. But this
> APEI case is special because irr
ext4_free_blocks is looping around the allocation request and mimics
__GFP_NOFAIL behavior without any allocation fallback strategy. Let's
remove the open coded loop and replace it with __GFP_NOFAIL. Without
the flag the allocator has no way to find out never-fail requirement
and cannot help in any
1 - 100 of 764 matches
Mail list logo
