On 05/13/2014 09:27 PM, Frederic Weisbecker wrote:
> On Tue, May 13, 2014 at 02:32:00PM +0530, Srivatsa S. Bhat wrote:
>>
>> kernel/stop_machine.c | 39 ++-
>> 1 file changed, 34 insertions(+), 5 deletions(-)
>>
>> diff --git a/kernel/stop_machine.c b/kernel/s
On 05/15/2014 06:41 AM, Mike Turquette wrote:
> Quoting Sebastian Hesselbarth (2014-05-14 16:17:52)
>> On 05/15/2014 12:32 AM, Mike Turquette wrote:
>>> Quoting Sebastian Hesselbarth (2014-05-11 13:24:35)
+avpll: pll@ea0040 {
+ compatible = "marvell,berlin2-avpll";
+ #clo
Hi Scott,
After merging the fsl tree, today's linux-next build (powerpc
allyesconfig) produced this warning:
arch/powerpc/kernel/epapr_paravirt.c:33:13: warning: 'epapr_has_idle' defined
but not used [-Wunused-variable]
static bool epapr_has_idle;
^
Introduced by commit f9eb581c63
Hi, all,
Currently, PNP bus is used as the default bus for for enumerating ACPI
devices with _HID/_CID.
For a device that needs to be enumerated to platform bus, we need to add
its id string to the platform scan handler white list explicitly.
This becomes a problem as more and more _HID devices n
Quoting Fabio Estevam (2014-05-08 20:01:50)
> From: Fabio Estevam
>
> Remove the 'gpios' property from the documentation as this is something that
> the
> current fixed clock driver does not handle.
>
> Signed-off-by: Fabio Estevam
Good catch. Taken into clk-next.
Regards,
Mike
> ---
> Doc
The acpi pnp scan handler id list just copies all the ids from all the
struct pnp_device_id instances, but some of them do not
comply with the ACPI PNP id rule (3 Alpha Charactors + 4 Hex numbers).
For those ids, the coressponding devices will never be enumerated
via ACPI, so it is safe to remove
A couple of suggestions:
1)
* Thomas Gleixner wrote:
> + if (requeue) {
> + if (waiter == rt_mutex_top_waiter(lock)) {
So we have a 'top_waiter' local variable already at this point, and we
use it here:
> + /* Boost the owner */
> + rt
Hi all,
After merging the net-next tree, today's linux-next build (powerpc
allnoconfig) produced this warning:
include/net/ip.h:211:5: warning: "CONFIG_SYSCTL" is not defined [-Wundef]
#if CONFIG_SYSCTL
^
Introduced by commit 122ff243f5f1 ("ipv4: make ip_local_reserved_ports
per netns").
Hi,
On Thursday 15 May 2014 12:12 AM, Sebastian Hesselbarth wrote:
> On 05/14/2014 08:12 PM, Arnd Bergmann wrote:
>> On Wednesday 14 May 2014 19:57:46 Sebastian Hesselbarth wrote:
>>> On 05/14/2014 06:57 PM, Antoine Ténart wrote:
On Wed, May 14, 2014 at 06:11:24PM +0200, Arnd Bergmann wrote:
The new ACPI device enumeration mechanism, which will be introduced
in a later patch, will enumerate the _HID devices w/o any scan
handler attached to platform bus.
This means that, for the devices that are attached to a configurable
scan handler, we should make sure no platform devices would be
cr
Because of the growing demand for enumerating ACPI devices to
platform bus, this patch changes the code to enumerate ACPI
devices to platform bus by default, if the device
1. has _HID.
2. does not have a scan handler attached.
3. will not be enumerated by its parent.
Signed-off-by: Zhang Rui
---
The "serial" pnp driver supports some unknown PNP modems (PNPCXXX/PNPDXXX)
by matching magic strings in the pnp device name or the pnp device card name.
ACPI enumerated PNP device neither supports pnp card, nor supports those magic
strings in its device name, which means this mechamism never works
Only certain kind of ACPI device objects can be enumerated to platform bus.
These ACPI device objects include
1. ACPI device objects that have _HID control method.
2. some ACPI device objects that have Linux specified HID strings.
In order to distinguish those device objects from the others, a new
The new ACPI device enumeration mechanism, which will be introduced
in a later patch, will enumerate the _HID devices w/o any scan
handler attached to platform bus.
This means that, for the devices that are attached to a configurable
scan handler, we should make sure no platform devices would be
cr
For ACPI PIC (PNP), Timer (PNP0100) and DMA controller (PNP0200)
device objects, although they have _HID control method, but they
should not be enumerated to platform bus, because there will never be
any platform drivers for them.
Thus an exclude id list is introduced in this patch to prevent
For some ACPI device objects, they represent master devices,
and their children devices are enumerated by bus controller drivers
for the buses they are on.
In this case, we do not want to enumerate their children devices to
platform bus explicitly in acpi scan code.
Thus a new flag .is_master_dev
Currently, ACPI scan handler uses strcmp() to match device ids
and scan handler ids.
When converting PNPACPI enumeration into a scan handler, which I will do
later in this patch set, the current code becomes not flexible enough
because ACPI pnp scan handler requires wildcase and case insensitive s
ACPI can be used to enumerate PNP devices, but the code does not
handle this in a good manner.
Currently, if an ACPI device
1. has _CRS method,
2. has an identifications of
"three capital charactors followed by four hex numbers",
3. is not in the excluded id list,
it is enumerated to PNP bus.
The new ACPI device enumeration mechanism, which will be introduced
in a later patch, will enumerate the _HID devices w/o any scan
handler attached to platform bus.
This means that, for the devices that are attached to a configurable
scan handler, we should make sure no platform devices would be
cr
On 05/13/2014 09:08 PM, Frederic Weisbecker wrote:
> On Mon, May 12, 2014 at 02:06:49AM +0530, Srivatsa S. Bhat wrote:
>> Today the smp-call-function code just prints a warning if we get an IPI on
>> an offline CPU. This info is sufficient to let us know that something went
>> wrong, but often it i
Static vm area boundary check:
paddr1 --->| |
| |
|---| <-\--- svm->vm->addr(is page aligned)
paddr2 --->| ||
| --| <--|-- svm->vm->phys_addr
| ||
paddr3 --->| ||
On Tue, May 13, 2014 at 02:02:01PM +0200, Greg KH wrote:
> On Wed, May 14, 2014 at 02:56:42AM +0300, Artem Fetishev wrote:
> > Use the more common kernel coding style.
> >
> > Signed-off-by: Artem Fetishev
> > ---
> > drivers/staging/line6/capture.c |4
> > drivers/staging/line6/midi.c
Quoting Arnd Bergmann (2014-05-08 07:56:16)
> The impd1 code on mach-integrator can be a loadable module,
> so we have to export icst_clk_register, integrator_impd1_clk_init
> and integrator_impd1_clk_exit.
>
> Signed-off-by: Arnd Bergmann
> Cc: Mike Turquette
> Cc: Linus Walleij
Taken into cl
On Wed, May 14, 2014 at 11:16:36AM -0500, Christoph Lameter wrote:
> On Tue, 13 May 2014, Vladimir Davydov wrote:
>
> > Currently full slabs are only kept on per-node lists for debugging, but
> > we need this feature to reparent per memcg caches, so let's enable it
> > for them too.
>
> That will
Quoting Stephen Rothwell (2014-05-14 23:11:21)
> Hi Mike,
>
> Today's linux-next merge of the clk tree got a conflict in
> Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt
> between commit b557deadc5cc ("ARM: shmobile: r7s72100: document MSTP
> clock support") from the renesas t
On Thu, 2014-05-15 at 02:05 -0400, Tejun Heo wrote:
> I'm not sure how much weight I can put on the specific use case. Even
> with the direct control that the user thought to have previously, the
> use case was ripe with possibilities of breakage from any number of
> reasons. For example, there
Hi Bin,
On 5/14/2014 10:13 PM, Bin Liu wrote:
George,
On Wed, May 14, 2014 at 9:34 AM, Bin Liu wrote:
George,
On Wed, May 14, 2014 at 12:37 AM, George Cherian wrote:
On 5/14/2014 12:07 AM, Bin Liu wrote:
Hi,
On Tue, May 13, 2014 at 8:24 AM, George Cherian
wrote:
Hi Daniel,
On 5/13/20
Hi,
On Wednesday 14 May 2014 03:51 PM, Antoine Ténart wrote:
> Hi,
>
> On Wed, May 14, 2014 at 03:43:03PM +0530, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Wednesday 14 May 2014 03:18 PM, Antoine Ténart wrote:
>
> […]
>
>>> +#define to_berlin_sata_phy_priv(desc) \
>>> + container_of((
On Wed, May 14, 2014 at 09:31:10AM -0700, Randy Dunlap wrote:
> On 05/14/2014 01:26 AM, Stephen Rothwell wrote:
> > Hi all,
> >
> > Changes since 20140513:
> >
>
> on x86_64:
>
> CONFIG_SERIAL_CORE=m
> but SERIAL_MEN_Z135=y.
>
> drivers/built-in.o: In function `men_z135_remove':
> men_z135_uart.c:(
Hello, Fengguang.
On Thu, May 15, 2014 at 02:00:26PM +0800, Fengguang Wu wrote:
> > > 2074b6e38668e62 a0f9ec1f181534694cb5bf40b
> > > --- -
>
> 2074b6e38668e62 is the base of comparison. So "-4.3%
> will-it-scale.per_thread_ops"
> in the below line means a0f
From: LeyFoon Tan
Try to delete the timer only if it was init/used.
Signed-off-by: LeyFoon Tan
Signed-off-by: Jassi Brar
---
drivers/mailbox/mailbox.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/mailbox/mailbox.c b/drivers/mailbox/mailbox.c
index befb256..d83
On 15 May 2014 04:00, Soren Brinkmann wrote:
> I have one or two problems with cpufreq and the CCF, which are caused by
> rounding/different frequency resolutions.
>
> cpufreq works with kHz, while the CCF uses Hz. On Zynq our default frequency
> is
> 6 Hz which the CCF, due to rounding,
On 14 May 2014 03:20, Doug Anderson wrote:
> ...but then I found the true problem shows up when we transition
> between very low frequencies on exynos, like between 200MHz and
> 300MHz. While transitioning between frequencies the system
> temporarily bumps over to the "switcher" PLL running at 80
From: LeyFoon Tan
For fast TX the complete could be called before being initialized as follows
mbox_send_message --> poll_txdone --> tx_tick --> complete(&chan->tx_complete)
Init the completion early enough to fix the race.
Signed-off-by: LeyFoon Tan
Signed-off-by: Jassi Brar
---
drivers/ma
Introduce common framework for client/protocol drivers and
controller drivers of Inter-Processor-Communication (IPC).
Client driver developers should have a look at
include/linux/mailbox_client.h to understand the part of
the API exposed to client drivers.
Similarly controller driver developers s
Hi Mike,
Today's linux-next merge of the clk tree got a conflict in
Documentation/devicetree/bindings/clock/renesas,cpg-mstp-clocks.txt
between commit b557deadc5cc ("ARM: shmobile: r7s72100: document MSTP
clock support") from the renesas tree and commit 5483bf698f42 ("clk:
shmobile: r8a7779: Add M
From: Suman Anna
The patch 30058677 "ARM / highbank: add support for pl320 IPC"
added a pl320 IPC specific header file as a generic mailbox.h.
This file has been renamed appropriately to allow the
introduction of the generic mailbox API framework.
Acked-by: Mark Langsdorf
Cc: Rafael J. Wysocki
On Thu, May 15, 2014 at 11:31 AM, Viresh Kumar wrote:
> On 15 May 2014 11:16, Inderpal Singh wrote:
>> I think I did not make myself clear.
>
> Probably I was the one who got confused :)
>
>> Devfreq will have its own opp table associated with its own device. It
>> does not uses the opp table of
Hi Tony,
On 5/15/2014 3:20 AM, Tony Lindgren wrote:
* George Cherian [140508 23:34]:
Re arrange the USB dt for AM33xx to take it a bit closer
to the hardware configuration.
The USBSS is designed as follows
USB control Module 0x44e10_0620
USBSS 0x4740_
USB0
Hi,
Here is the next revision of Mailbox framwork.
Changes since v4:
o Common DT binding for Controller and Client drivers
As a result, discard string based channel matching
o Provide for an atomic 'peek' api, that a client could
call to trigger the controller driver push data upwards.
On 15 May 2014 02:45, Mimi Zohar wrote:
> On Wed, 2014-04-23 at 16:30 +0300, Dmitry Kasatkin wrote:
>> This patch provides functionality to replace the IMA policy at runtime.
>>
>> By default, the IMA policy can be successfully updated only once,
>> but with this patch when the kernel configuratio
On Wed 2014-05-14 20:32:25, George Spelvin wrote:
> Pavel Machek wrote;
> > On Sun 2014-05-11 05:16:07, George Spelvin wrote:
> >> To do it properly, I have to rename all of:
> >>
> >> crc7_syndrome_table[]
> >> crc7_byte()
> >> crc7()
> >>
> >> even though the third is the only (in-tree) user of
Hello, Mike.
On Thu, May 15, 2014 at 07:32:29AM +0200, Mike Galbraith wrote:
> On Thu, 2014-05-15 at 01:09 -0400, Tejun Heo wrote:
> > > Soft/hard irq threads and anything having to do with IO mostly, which
> > > including workqueues. I had to give the user a rather fugly global
> > > prioritiza
On 15 May 2014 11:16, Inderpal Singh wrote:
> I think I did not make myself clear.
Probably I was the one who got confused :)
> Devfreq will have its own opp table associated with its own device. It
> does not uses the opp table of cpus.
> Hence there may be need to free the table if driver (at
Hi Tejun,
On Thu, May 15, 2014 at 12:55:17AM -0400, Tejun Heo wrote:
> Hello,
>
> On Thu, May 15, 2014 at 12:50:39PM +0800, Jet Chen wrote:
> > FYI, we noticed the below changes on
> >
> > git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git
> > review-kill-tree_mutex
> > commit a0f9ec1f
Douglas Anderson, recently pointed out an interesting problem due to which his
udelay() was expiring earlier than it should:
https://lkml.org/lkml/2014/5/13/766
While transitioning between frequencies few platforms may temporarily switch to
a stable frequency, waiting for the main PLL to stabilize
Add error message when fail to enable cache
Signed-off-by: Gioh Kim
---
arch/arm/mm/cache-l2x0.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mm/cache-l2x0.c b/arch/arm/mm/cache-l2x0.c
index 7abde2c..5102c62 100644
--- a/arch/arm/mm/cache-l2x0.c
+++ b/arch
Tegra has implemented an unnecessary wrapper over tegra_update_cpu_speed(), i.e.
tegra_target(), which wasn't doing anything apart of calling
tegra_update_cpu_speed(). Get rid of that and use tegra_target() directly.
Signed-off-by: Viresh Kumar
---
drivers/cpufreq/tegra-cpufreq.c | 9 ++---
On Thu, May 15, 2014 at 11:07 AM, Viresh Kumar wrote:
> On 15 May 2014 11:00, Inderpal Singh wrote:
>> On Thu, May 15, 2014 at 10:34 AM, Viresh Kumar
>> wrote:
>>> On 15 May 2014 10:22, Inderpal Singh wrote:
>>>
What i am saying that "what if we are not going to re-use again ? "
>>>
>>> T
Hi,
My board is using Trustzone and running kernel is non-secure mode.
But setup function of PL310 driver is only for secure mode kernel.
What about adding an entry for non-secure mode setup function?
I'm sorry for my poor code but I just wanna say what I need .
--
On 15 May 2014 11:00, Inderpal Singh wrote:
> On Thu, May 15, 2014 at 10:34 AM, Viresh Kumar
> wrote:
>> On 15 May 2014 10:22, Inderpal Singh wrote:
>>
>>> What i am saying that "what if we are not going to re-use again ? "
>>
>> That's what I said:
>>
>> Yes, it will keep occupying some space
Signed-off-by: Stephen Rothwell
---
drivers/char/hw_random/virtio-rng.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
Based on the current virtio tree in linux-next.
diff --git a/drivers/char/hw_random/virtio-rng.c
b/drivers/char/hw_random/virtio-rng.c
index 12e242bbb0f5..6319b1
Include slab.h for kmalloc/kfree declaration and check the actual
allocations succeed.
Signed-off-by: Stephen Rothwell
---
drivers/char/hw_random/virtio-rng.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/char/hw_random/virtio-rng.c
b/drivers/char/hw_random/virtio-rng.c
ind
On Thu, 2014-05-15 at 01:09 -0400, Tejun Heo wrote:
> Hello, Mike.
>
> On Thu, May 15, 2014 at 07:04:22AM +0200, Mike Galbraith wrote:
> > On Thu, 2014-05-15 at 00:50 -0400, Tejun Heo wrote:
> > > Do we know specific kthreads which need to be exposed with this way?
> >
> > Soft/hard irq threads
On Thu, May 15, 2014 at 10:34 AM, Viresh Kumar wrote:
> On 15 May 2014 10:22, Inderpal Singh wrote:
>
>> What i am saying that "what if we are not going to re-use again ? "
>
> That's what I said:
>
> Yes, it will keep occupying some space but there is only one instance
> of that per 'cluster' an
On Thu, 15 May 2014, Cyrill Gorcunov wrote:
> So I'm experiencing the same problem on latest -tip + my patches applied.
glad it's not just me.
I find the problem to be reproducible and so in theory it might be
possible to generate a small reproducing test case.
I meant to do that already but
On Fri, May 9, 2014 at 6:15 PM, Eric Auger wrote:
> This patch enables irqfd and irq routing on ARM.
>
> It turns on CONFIG_HAVE_KVM_EVENTFD and CONFIG_HAVE_KVM_IRQ_ROUTING
>
> irqfd framework enables to assign physical IRQs to guests.
>
> 1) user-side uses KVM_IRQFD VM ioctl to pass KVM a kvm_irq
Hi James,
we're past -rc5 and no SCSI patches have been collected for 3.16 yet,
despite a lot of patches including a lot of reviewed ones pending on the
list.
I'd really love to get at least some testing for all the work that
sometimes has been pending for months in linux-next and would offer to
On 5/14/14, 17:18, "H. Peter Anvin" wrote:
>On 05/14/2014 09:18 AM, Darren Hart wrote:
>>
>> However, unless I'm sorely mistaken, the larger problem is that glibc
>> removed the futex() call entirely, so these man pages don't describe
>> something users even have access to anymore. I had to reve
Hi Thierry,
On 15 May 2014 03:44, Thierry Reding wrote:
> On Thu, May 15, 2014 at 12:47:21AM +0530, Rahul Sharma wrote:
> [...]
>> diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt
>> b/Documentation/devicetree/bindings/phy/samsung-phy.txt
> [...]
>> +For "samsung,exynos4210-sim
On Tue, May 13, 2014 at 10:09 PM, Ingo Molnar wrote:
>
> * Alexei Starovoitov wrote:
>
>> On Tue, May 13, 2014 at 8:17 PM, Steven Rostedt wrote:
>> > On Tue, 13 May 2014 19:55:11 -0700
>> > Alexei Starovoitov wrote:
>> >
>> >> Tracing filters are parsing user supplied character string and
>> >
Hello, Mike.
On Thu, May 15, 2014 at 07:04:22AM +0200, Mike Galbraith wrote:
> On Thu, 2014-05-15 at 00:50 -0400, Tejun Heo wrote:
> > Do we know specific kthreads which need to be exposed with this way?
>
> Soft/hard irq threads and anything having to do with IO mostly, which
> including workqu
On Thu, 24 Apr 2014, Vince Weaver wrote:
> On Wed, 23 Apr 2014, Peter Zijlstra wrote:
> >
> > Something like so should do I suppose.
> >
> > ---
> > Subject: perf: Fix perf_event_open(.flags) test
> >
> > Vince noticed that we test the (unsigned long) flags field against an
> > (unsigned int) c
On Thu, 2014-05-15 at 00:50 -0400, Tejun Heo wrote:
> Hello, Mike.
>
> On Thu, May 15, 2014 at 06:46:18AM +0200, Mike Galbraith wrote:
> > > I think it'd be healthier to identify the use cases and then provide
> > > proper interface for it. Note that workqueue can now expose interface
> > > to m
Hello Heesub,
On Thu, May 15, 2014 at 11:45:31AM +0900, Heesub Shin wrote:
> Hello,
>
> On 05/15/2014 10:53 AM, Joonsoo Kim wrote:
> >On Tue, May 13, 2014 at 12:00:57PM +0900, Minchan Kim wrote:
> >>Hey Joonsoo,
> >>
> >>On Thu, May 08, 2014 at 09:32:23AM +0900, Joonsoo Kim wrote:
> >>>CMA is int
On 15 May 2014 10:22, Inderpal Singh wrote:
> What i am saying that "what if we are not going to re-use again ? "
That's what I said:
Yes, it will keep occupying some space but there is only one instance
of that per 'cluster' and is very much affordable instead of building it again..
So, we ma
Hello,
On Thu, May 15, 2014 at 12:50:39PM +0800, Jet Chen wrote:
> FYI, we noticed the below changes on
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git
> review-kill-tree_mutex
> commit a0f9ec1f181534694cb5bf40b7b56515b8cabef9 ("cgroup: use
> cgroup_kn_lock_live() in other cgrou
Hi Thomas,
On Thu, May 15, 2014 at 1:34 AM, Thomas Gleixner wrote:
> On Wed, 14 May 2014, Carlos O'Donell wrote:
>
>> On 05/14/2014 03:03 PM, Michael Kerrisk (man-pages) wrote:
>> >> However, unless I'm sorely mistaken, the larger problem is that glibc
>> >> removed the futex() call entirely, so
On Thu, May 15, 2014 at 10:06 AM, Viresh Kumar wrote:
> On 15 May 2014 10:02, Inderpal Singh wrote:
>> I feel freeing of opps are needed at least at the driver unregistration
>> time, like we free cpufreq_table.
>> Otherwise it amounts to memory leak unless we assume that the same driver is
>> go
On 05/15/2014 05:12 AM, Carlos O'Donell wrote:
> On 05/14/2014 07:34 PM, Thomas Gleixner wrote:
>> On Wed, 14 May 2014, Carlos O'Donell wrote:
>>
>>> On 05/14/2014 03:03 PM, Michael Kerrisk (man-pages) wrote:
> However, unless I'm sorely mistaken, the larger problem is that glibc
> removed
Hi Tejun,
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup.git
review-kill-tree_mutex
commit a0f9ec1f181534694cb5bf40b7b56515b8cabef9 ("cgroup: use
cgroup_kn_lock_live() in other cgroup kernfs methods")
Test case : lkp-nex05/will-it-scale/writeseek
Hello, Mike.
On Thu, May 15, 2014 at 06:46:18AM +0200, Mike Galbraith wrote:
> > I think it'd be healthier to identify the use cases and then provide
> > proper interface for it. Note that workqueue can now expose interface
> > to modify concurrency, priority and cpumask to userland which
> > wri
On Thu, 2014-05-15 at 00:06 -0400, Tejun Heo wrote:
> Hey, Mike.
>
> On Thu, May 15, 2014 at 05:53:57AM +0200, Mike Galbraith wrote:
> > Hm. The user would need to be able to identify and prioritize the
>
> I suppose you mean userland by "the user"?
Yeah.
> > things, and have his settings sti
On 14 May 2014 19:54, Mikulas Patocka wrote:
> Hi Viresh
>
> Some times ago, I sent these two cpufreq patches to fix frequency
> transition problem on speedstep-smi, but you didn't put them to the
> upstream kernel. I am resending the patches. If you would like a different
> solution to this probl
Make the CONFIG_OF=n prototpe of of_node_full_name() mateh the CONFIG_OF=y
version.
Fixes compile warnings like this:
sound/soc/soc-core.c: In function 'soc_check_aux_dev':
sound/soc/soc-core.c:1667:3: warning: passing argument 1 of 'of_node_full_name'
discards 'const' qualifier from pointer tar
On 14 May 2014 23:35, Stratos Karafotis wrote:
> Many drivers keep frequencies in frequency table in ascending
> or descending order. When governor tries to change to policy->min
> or policy->max respectively then the cpufreq_frequency_table_target
> could return on first iteration. This will save
On 15 May 2014 10:02, Inderpal Singh wrote:
> I feel freeing of opps are needed at least at the driver unregistration
> time, like we free cpufreq_table.
> Otherwise it amounts to memory leak unless we assume that the same driver is
> going to re-register and re-use the same opps.
Its memory leak
Dear Kukjin,
Could you please pick following patches?
- [PATCHv5 1/5] ARM: EXYNOS: Add Exynos3250 SoC ID
- [PATCHv5 2/5] ARM: EXYNOS: Support secondary CPU boot of Exynos3250
Best Regards,
Chanwoo Choi
On 05/13/2014 10:05 PM, Chanwoo Choi wrote:
> This patchset support new Exynos3250 Samsung SoC
Hi Andrew,
On 05/15/2014 12:30 AM, Andrew Morton wrote:
On Wed, 14 May 2014 07:52:38 -0700 Davidlohr Bueso wrote:
- semcnt = 0;
+ BUG_ON(sop->sem_flg & IPC_NOWAIT);
+ BUG_ON(sop->sem_op > 0);
Hmm in light of Linus' recent criticism about randomly sprinkling
BUG_ONs in the k
Hi Davidlohr,
On 05/14/2014 09:50 PM, Davidlohr Bueso wrote:
Do you have any preferences? I can cook up a patch if you think that
this merits Linux having MSGTQL.
MSGTQL means a global counter - therefore zero scalability. That's why I
didn't implement it when I noticed the issue with 0-byte me
On Thu, May 15, 2014 at 11:38 AM, Andrew Morton
wrote:
>
> We could easily change the interface so that pages==NULL means "no
> pages" but that isn't the way it works at present.
>
Yeah, thanks /Hillf
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messa
Hi Steven,
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace.git
ftrace/core
commit b1169cc69ba96b124df820904a6d3eb775491d7f ("tracing: Remove mock up poll
wait function")
f4874261049e3ab b1169cc69ba96b124df820904
--- -
Hey, Mike.
On Thu, May 15, 2014 at 05:53:57AM +0200, Mike Galbraith wrote:
> Hm. The user would need to be able to identify and prioritize the
I suppose you mean userland by "the user"?
> things, and have his settings stick. Any dynamic pool business doing
> allocations and/or munging prioriti
Thanks Tomasz,
On 15 May 2014 01:31, Tomasz Figa wrote:
> Hi Rahul, Tomasz,
[snip]
>> + simplephys: simple-phys@1004 {
>> + compatible = "samsung,exynos5250-simple-phy";
>
> Missing reg property or unnecessary @unit-address suffix in node name.
I should have removed "@unit-ad
On Wed, May 14, 2014 at 10:15:27PM -0500, Seth Forshee wrote:
> On Wed, May 14, 2014 at 10:17:31PM -0400, Michael H. Warfield wrote:
> > > > Using devtmpfs is one possible
> > > > solution, and it would have the added benefit of making container setup
> > > > simpler. But simply letting containers
On 14 May 2014 20:32, Pavel Machek wrote:
> Hmm. Would it be better to actually delete stale OPPs?
I wouldn't call them stale as dtb isn't going to change after boot
and we will always get the same list again, unless some arch has
added few more after boot.
So, there is no point freeing opp's on
Hi Oleg,
we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
commit 8ad8e9d3fd64f101eed6652964670672d699e563 ("uprobes/x86: Introduce
uprobe_xol_ops and arch_uprobe->ops")
Test case: lkp-snb01/aim7/signal_test
34e7317d6ae8f61 8ad8e9d3fd64f1
On Wed, 2014-05-14 at 12:32 -0400, Tejun Heo wrote:
> Hello, Jiri, Vojtech.
>
> On Wed, May 14, 2014 at 05:15:01PM +0200, Vojtech Pavlik wrote:
> > On Wed, May 14, 2014 at 04:59:05PM +0200, Jiri Slaby wrote:
> > > I see the worst case scenario. (For curious readers, it is for example
> > > this k
On 05/14/2014 05:44 PM, Peter Zijlstra wrote:
[snip]
>> and then:
>> echo $$ > /sys/fs/cgroup/cpu/A/tasks ; ./my_tool -l
>> echo $$ > /sys/fs/cgroup/cpu/B/tasks ; ./my_tool -l
>> echo $$ > /sys/fs/cgroup/cpu/C/tasks ; ./my_tool 50
>>
>> the results in top is around:
>>
>>
On Thu, May 15, 2014 at 12:06 AM, Rob Herring wrote:
> Adding Nico...
>
> On Wed, May 14, 2014 at 3:18 AM, Richard Lee wrote:
>> For the IO mapping, the same physical address space maybe
>> mapped more than one time, for example, in some SoCs:
>> - 0x20001000 ~ 0x20001400 --> 1KB for Dev1
>>
From: Julia Lawall
Netdev_priv is an accessor function, and has no purpose if its result is
not used.
A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@ local idexpression x; @@
-x = netdev_priv(...);
... when != x
//
Signed-o
From: Julia Lawall
Netdev_priv is an accessor function, and has no purpose if its result is
not used.
A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@ local idexpression x; @@
-x = netdev_priv(...);
... when != x
//
Signed-o
From: Julia Lawall
Netdev_priv is an accessor function, and has no purpose if its result is
not used.
A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@ local idexpression x; @@
-x = netdev_priv(...);
... when != x
//
Signed-o
From: Julia Lawall
Netdev_priv is an accessor function, and has no purpose if its result is
not used.
A simplified version of the semantic match that fixes this problem is as
follows: (http://coccinelle.lip6.fr/)
//
@@ local idexpression x; @@
-x = netdev_priv(...);
... when != x
//
Signed-o
On Thu, 15 May 2014 11:18:29 +0800 Hillf Danton wrote:
> > --- a/arch/x86/vdso/vma.c
> > +++ b/arch/x86/vdso/vma.c
> > @@ -90,6 +90,7 @@ static int map_vdso(const struct vdso_image *image, bool
> > calculate_addr)
> > struct vm_area_struct *vma;
> > unsigned long addr;
> >
在 2014-05-14三的 11:21 -0400，Naoya Horiguchi写道：
> When a memory error happens on an in-use page or (free and in-use) hugepage,
> the victim page is isolated with its refcount set to one. When you try to
> unpoison it later, unpoison_memory() calls put_page() for it twice in order to
> bring the page
On Wed, 14 May 2014, H. Peter Anvin wrote:
> On 05/14/2014 02:33 PM, John Stultz wrote:
> >
> > We can do some tricks for internal optimizations here if these are
> > critical. I'd be more concerned about userland divisions where moving
> > to a 64bit time_t would cause performance issues that w
On Wed, 2014-05-14 at 08:44 -0700, Paul E. McKenney wrote:
> In practice, not sure how much testing CONFIG_NO_HZ_FULL=y has received
> for -rt kernels in production environments.
I took 3.14-rt out for a quick spin on my 64 core box, it didn't work at
all with 60 cores isolated. I didn't have ti
Hi Andy,
On Thu, May 15, 2014 at 7:46 AM, Andy Lutomirski wrote:
> The oops can be triggered in qemu using -no-hpet (but not nohpet) by
> reading a couple of pages past the end of the vdso text. This
> should send SIGBUS instead of OOPSing.
>
> The bug was introduced by:
>
> commit 7a59ed415f5b5
On Wed, May 14, 2014 at 10:17:31PM -0400, Michael H. Warfield wrote:
> > > Using devtmpfs is one possible
> > > solution, and it would have the added benefit of making container setup
> > > simpler. But simply letting containers mount devtmpfs isn't sufficient
> > > since the container may need to
1 - 100 of 936 matches
Mail list logo
