On 13 June 2013 11:10, Xiaoguang Chen wrote:
> 2013/6/12 Viresh Kumar :
>> On 12 June 2013 14:39, Xiaoguang Chen wrote:
>>
>>> ret = policy->governor->governor(policy, event);
>>
>> We again reached to the same problem. We shouldn't call
>> this between taking locks, otherwise recursive
On Thu, 2013-06-13 at 12:21 +0800, Jason Wang wrote:
> This patch silents the following sparse warnings:
>
> dr
> Signed-off-by: Jason Wang
> ---
> drivers/net/macvtap.c |2 +-
> include/linux/if_macvlan.h |2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git
On Wed, 12 Jun 2013 20:54:32 -0700 Kent Overstreet
wrote:
> On Wed, Jun 12, 2013 at 08:03:11PM -0700, Andrew Morton wrote:
> > On Wed, 12 Jun 2013 19:05:36 -0700 Kent Overstreet
> > wrote:
> >
> > > ...
> > >
> > > > Why can't we use ida_get_new_above()?
> > > >
> > > >If it is "speed"
On Wed, Jun 12, 2013 at 8:50 PM, Bjorn Helgaas wrote:
> On Wed, Jun 12, 2013 at 1:41 PM, Yinghai Lu wrote:
>
> I think you're saying that in systems that support both acpiphp and
> pciehp, we should be using pciehp, but we currently use acpiphp. If
> so, that's certainly a bug. How serious is
On 13 June 2013 11:00, Tushar Behera wrote:
> On 06/10/2013 05:05 PM, Tushar Behera wrote:
>> Commit 75096579c3ac ("lib: devres: Introduce devm_ioremap_resource()")
>> introduced devm_ioremap_resource() and deprecated the use of
>> devm_request_and_ioremap().
>>
>> Signed-off-by: Tushar Behera
2013/6/12 Viresh Kumar :
> On 12 June 2013 14:39, Xiaoguang Chen wrote:
>
>> ret = policy->governor->governor(policy, event);
>
> We again reached to the same problem. We shouldn't call
> this between taking locks, otherwise recursive locks problems
> would be seen again.
But this is not
On Thu, 2013-06-13 at 09:35 +1000, Dave Wiltshire wrote:
> Firstly, from my cover letter: "Perhaps I don't understand something,
> but I thought it best to generate the change and then ask. So is this
> correct?".
Sure I have no problems with that.
> But secondly, I understand that the only
On Wednesday, June 12, 2013 7:56 PM, Arnd Bergmann wrote:
>
> Thanks for the update! A few comments again:
>
> On Wednesday 12 June 2013 19:20:00 Jingoo Han wrote:
> >
> > diff --git a/arch/arm/boot/dts/exynos5440-ssdk5440.dts
> > b/arch/arm/boot/dts/exynos5440-ssdk5440.dts
> > index
On 06/10/2013 05:05 PM, Tushar Behera wrote:
> Commit 75096579c3ac ("lib: devres: Introduce devm_ioremap_resource()")
> introduced devm_ioremap_resource() and deprecated the use of
> devm_request_and_ioremap().
>
> Signed-off-by: Tushar Behera
> CC: net...@vger.kernel.org
> CC:
On 13 June 2013 03:01, Marc Kleine-Budde wrote:
> Commit 75096579c3ac ("lib: devres: Introduce devm_ioremap_resource()")
> introduced devm_ioremap_resource() and encourage to check its return value
> with
> IS_ERR(). This however leads to the following sparse warnings, as
>
On 06/12/2013 10:16 PM, Sören Brinkmann wrote:
> On Wed, Jun 12, 2013 at 09:33:58PM +0200, Steffen Trumtrar wrote:
>> On Wed, Jun 12, 2013 at 11:26:34AM -0700, Sören Brinkmann wrote:
>>> On Wed, Jun 12, 2013 at 08:23:45PM +0200, Steffen Trumtrar wrote:
On Wed, Jun 12, 2013 at 09:41:08AM
> -Original Message-
> From: linux-pm-ow...@vger.kernel.org [mailto:linux-pm-
> ow...@vger.kernel.org] On Behalf Of Eduardo Valentin
> Sent: Thursday, May 30, 2013 3:07 AM
> To: Zhang, Rui
> Cc: Eduardo Valentin; Amit Daniel Kachhap; R, Durgadoss; linux-
> p...@vger.kernel.org;
On 6/12/2013 11:04 AM, Santosh Y wrote:
/**
+ * ufshcd_query_request() - API for issuing query request to the device.
+ * @hba: ufs driver context
+ * @query: params for query request
+ * @descriptor: buffer for sending/receiving descriptor
+ * @retries: number of times to try executing
Hi,
On 06/11/2013 06:20 AM, Rafael J. Wysocki wrote:
>
> OK, so let's try to take one step more and think about what part should belong
> to the scheduler and what part should be taken care of by the "idle" driver.
>
> Do you have any specific view on that?
I gave it some thought and went
On 6/12/2013 11:00 AM, Santosh Y wrote:
+/*
+ * ufshcd_wait_for_register - wait for register value to change
+ * @hba - per-adapter interface
+ * @reg - mmio register offset
+ * @mask - mask to apply to read register value
+ * @val - wait condition
+ * @interval_us - polling interval in
Return -EINVAL on illegal flag instead of uninitialized value. This fixes the
kbuild test warning.
Signed-off-by: Jason Wang
---
drivers/net/macvtap.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index acf55ba..9f03ce3
This patch silents the following sparse warnings:
drivers/net/macvtap.c:98:9: warning: incorrect type in assignment (different
address spaces)
drivers/net/macvtap.c:98:9:expected struct macvtap_queue *
drivers/net/macvtap.c:98:9:got struct macvtap_queue [noderef]
*
This patch adds Palmas MFD node and the regulator nodes for OMAP5.
The node definitions are based on: https://lkml.org/lkml/2013/6/6/25
Boot tested on omap5-uevm board.
Signed-off-by: Graeme Gregory
Signed-off-by: J Keerthy
Reviewed-by: Stephen Warren
---
V6:
Changed the order of properties.
Good day, I Am Chi Pui;Do not be surprised! I got your email contact via the
World Email On-line Directory" I am crediting officer at Sino Pac Bank Plc
in Hong Kong and i have a deal of $17.3M to discuss with you urgently.
Regards,
Mr.Chi Pui
--
To unsubscribe from this list: send the line
On 12 June 2013 21:20, Stephen Warren wrote:
> On 06/12/2013 02:15 AM, Viresh Kumar wrote:
>> ARCH_TEGRA selects ARCH_HAS_CPUFREQ, so CPUFREQ will be enabled for all
>> variants
>> of TEGRA. CPUFreq driver for tegra is enabled if ARCH_TEGRA is selected.
>> Driver
>> uses APIs from freq_table.c
On 6/12/2013 6:40 AM, Tomasz Stanislawski wrote:
> Hi Casey,
> Thank you for your review.
> Please refer to comments below.
>
> On 06/12/2013 07:11 AM, Casey Schaufler wrote:
>> On 6/11/2013 5:55 AM, Tomasz Stanislawski wrote:
>>> This patch adds a hash table to quicken searching of a smack label
Hi Bjorn,
I'm working on several acpiphp related bugfixes, and feel some
are materials for 3.10 too. Actually we have identified four bugs
related to dock station support on Sony VAIO VPCZ23A4R laptop.
I will try to send out patchset to address these bugs tonight.
Seems we really need to
Hi Stephen,
> -Original Message-
> From: Stephen Warren [mailto:swar...@wwwdotorg.org]
> Sent: Wednesday, June 12, 2013 9:22 PM
> To: J, KEERTHY
> Cc: Cousson, Benoit; devicetree-disc...@lists.ozlabs.org; linux-
> o...@vger.kernel.org; linux-kernel@vger.kernel.org;
> ldewan...@nvidia.com;
Signed-off-by: Tejun Heo
---
include/linux/cgroup.h | 1 -
kernel/cgroup.c| 12
2 files changed, 13 deletions(-)
diff --git a/include/linux/cgroup.h b/include/linux/cgroup.h
index d0ad379..5830592 100644
--- a/include/linux/cgroup.h
+++ b/include/linux/cgroup.h
@@ -848,7
Hello,
The changes from the last take[L] are,
* Rebased on top of further percpu-refcount updates.
* 0003: Broken patch description updated.
* 0004: Stupid list_del_init() conversions from the last decade
dropped.
* 0005: Typo fix.
* 0011: percpu_ref_init() error handling fixed.
cgroup.c uses @cg for most struct css_set variables, which in itself
could be a bit confusing, but made much worse by the fact that there
are places which use @cg for struct cgroup variables.
compare_css_sets() epitomizes this confusion - @[old_]cg are struct
css_set while @cg[12] are struct
cgroups and css_sets are mapped M:N and this M:N mapping is
represented by struct cg_cgroup_link which forms linked lists on both
sides. The naming around this mapping is already confusing and struct
cg_cgroup_link exacerbates the situation quite a bit.
>From cgroup side, it starts off
We will add another flag indicating that the cgroup is in the process
of being killed. REMOVING / REMOVED is more difficult to distinguish
and cgroup_is_removing()/cgroup_is_removed() are a bit awkward. Also,
later percpu_ref usage will involve "kill"ing the refcnt.
s/CGRP_REMOVED/CGRP_DEAD/
There's no point in using kmalloc() instead of the clearing variant
for trivial stuff. We can live dangerously elsewhere. Use kzalloc()
instead and drop 0 inits.
While at it, do trivial code reorganization in cgroup_file_open().
This patch doesn't introduce any functional changes.
v2: I was
__put_css_set() does RCU read access on @cgrp across dropping
@cgrp->count so that it can continue accessing @cgrp even if the count
reached zero and destruction of the cgroup commenced. Given that both
sides - __css_put() and cgroup_destroy_locked() - are cold paths, this
is unnecessary. Just
This patch reorders the operations in cgroup_destroy_locked() such
that the userland visible parts happen before css offlining and
removal from the ->sibling list. This will be used to make css use
percpu refcnt.
While at it, split out CGRP_DEAD related comment from the refcnt
deactivation one
Split cgroup_destroy_locked() into two steps and put the latter half
into cgroup_offline_fn() which is executed from a work item. The
latter half is responsible for offlining the css's, removing the
cgroup from internal lists, and propagating release notification to
the parent. The separation is
A css (cgroup_subsys_state) is how each cgroup is represented to a
controller. As such, it can be used in hot paths across the various
subsystems different controllers are associated with.
One of the common operations is reference counting, which up until now
has been implemented using a global
cgroup->count tracks the number of css_sets associated with the cgroup
and used only to verify that no css_set is associated when the cgroup
is being destroyed. It's superflous as the destruction path can
simply check whether cgroup->cset_links is empty instead.
Drop cgroup->count and check
* __css_get() isn't used by anyone. Fold it into css_get().
* Add proper function comments to all css reference functions.
This patch is purely cosmetic.
v2: Typo fix as per Li.
Signed-off-by: Tejun Heo
Cc: Li Zefan
---
include/linux/cgroup.h | 48
(2013/06/12 18:13), Michael Holzheu wrote:
On Tue, 11 Jun 2013 21:42:15 +0900
HATAYAMA Daisuke wrote:
2013/6/11 Michael Holzheu :
On Mon, 10 Jun 2013 22:40:24 +0900
HATAYAMA Daisuke wrote:
2013/6/8 Michael Holzheu :
Thanks for that hint! So together with your other comment regarding
On Wed, Jun 12, 2013 at 08:58:31PM -0700, Tejun Heo wrote:
> At first I named it percpu_ref_free() but it looked too symmetric to
> init, more so than kill, so I was worried that people might get
> confused that this is the normal interface to shutdown a percpu
> refcnt, so the weird cancel_init
On Wed, Jun 12, 2013 at 08:56:36PM -0700, Kent Overstreet wrote:
> On Wed, Jun 12, 2013 at 08:52:35PM -0700, Tejun Heo wrote:
> > Normally, percpu_ref_init() initializes and percpu_ref_kill*()
> > initiates destruction which completes asynchronously. The
> > asynchronous destruction can be
On Wed, Jun 12, 2013 at 08:52:35PM -0700, Tejun Heo wrote:
> Normally, percpu_ref_init() initializes and percpu_ref_kill*()
> initiates destruction which completes asynchronously. The
> asynchronous destruction can be problematic in init failure path where
> the caller wants to destroy
On Wed, Jun 12, 2013 at 08:03:11PM -0700, Andrew Morton wrote:
> On Wed, 12 Jun 2013 19:05:36 -0700 Kent Overstreet
> wrote:
>
> > ...
> >
> > > Why can't we use ida_get_new_above()?
> > >
> > >If it is "speed" then how bad is the problem and what efforts have
> > >been made to address
Normally, percpu_ref_init() initializes and percpu_ref_kill*()
initiates destruction which completes asynchronously. The
asynchronous destruction can be problematic in init failure path where
the caller wants to destroy half-constructed object - distinguishing
half-constructed objects from the
Two small changes.
* Unlike most init functions, percpu_ref_init() allocates memory and
may fail. Let's mark it with __must_check in case the caller
forgets.
* percpu_ref_kill_rcu() is unnecessarily using ACCESS_ONCE() to
dereference @ref->pcpu_count, which can be misleading. The pointer
On Wed, Jun 12, 2013 at 1:41 PM, Yinghai Lu wrote:
> On Wed, Jun 12, 2013 at 10:05 AM, Bjorn Helgaas wrote:
>>> current code from acpi_pci_root_add we have
>>> 1. pci_acpi_scan_root
>>> ==> pci devices enumeration and bus scanning.
>>> ==> pci_alloc_child_bus
>>>
Implement percpu_tryget() which stops giving out references once the
percpu_ref is visible as killed. Because the refcnt is per-cpu,
different CPUs will start to see a refcnt as killed at different
points in time and tryget() may continue to succeed on subset of cpus
for a while after
On Wed, Jun 12, 2013 at 01:45:32PM -0700, Tejun Heo wrote:
> From 49d1e1a6561f1e4b190695f36d2594c7c04b8e76 Mon Sep 17 00:00:00 2001
> From: Tejun Heo
> Date: Wed, 12 Jun 2013 13:37:42 -0700
>
> * s/percpu_ref_release/percpu_ref_func_t/ as it's customary to have _t
> postfix for types and the
On Wed, Jun 12, 2013 at 01:40:32PM -0700, Tejun Heo wrote:
> From e96262150a513ce3d54ff221d4ace8aeec96e0bf Mon Sep 17 00:00:00 2001
> From: Tejun Heo
> Date: Wed, 12 Jun 2013 13:37:42 -0700
>
> percpu_ref_get/put() are using preempt_disable/enable() while
> percpu_ref_kill() is using plain
Not sure who takes this, but please pull these 2 changes for pstore for
3.11. These are necessary to get pstore to work with on-chip RAM on
Calxeda highbank platform.
I dropped the write-combine change from this series. While write-combine
is technically the correct mapping needed for ARM, it
On Wed, Jun 12, 2013 at 8:44 PM, Takao Indoh wrote:
> (2013/06/12 13:45), Bjorn Helgaas wrote:
>> [+cc Vivek, Haren; sorry I didn't think to add you earlier]
>>
>> On Tue, Jun 11, 2013 at 12:08 AM, Takao Indoh
>> wrote:
>>> (2013/06/11 11:20), Bjorn Helgaas wrote:
>>
I'm not sure you need
Sorry for replying late during these days, firstly.
On 06/10/2013 10:12 PM, Thomas Gleixner wrote:
> On Sun, 9 Jun 2013, Chen Gang wrote:
>
>> >
>> > According to __internal_add_timer(), in _next_timer_interrupt(), when
>> > 'tv1.vec' find one, but need 'cascade bucket(s)', we still need find
On Fri, 2013-06-07 at 15:14 +0200, Lotfi Manseur wrote:
> Handle null termios in ftdi_set_termios(), introduced in
> commit 552f6bf1bb0eda0011c0525dd587aa9e7ba5b846
> This has been corrected in the mainline by
> commits c515598e0f5769916c31c00392cc2bfe6af74e55 and
>
(2013/06/12 22:19), Don Dutile wrote:
> On 06/11/2013 07:19 PM, Sumner, William wrote:
>>
>>> (2013/06/11 11:20), Bjorn Helgaas wrote:
On Fri, Jun 7, 2013 at 2:46 AM, Takao Indoh
wrote:
> (2013/06/07 13:14), Bjorn Helgaas wrote:
>> One thing I'm not sure about is that you
On Thu, 13 Jun 2013, Samuel Ortiz wrote:
> > +static struct vexpress_spc_drvdata *info;
> > +static u32 *vexpress_spc_config_data;
> > +static struct vexpress_config_bridge *vexpress_spc_config_bridge;
> > +static struct vexpress_config_func *opp_func, *perf_func;
> > +
> > +static int
On Wed, Jun 12, 2013 at 12:32:11PM -0700, Zach Brown wrote:
> >fs/btrfs/delayed-inode.c: In function 'get_ins_del_root':
> > >> fs/btrfs/delayed-inode.c:393:1: warning: control reaches end of non-void
> > >> function [-Wreturn-type]
> >
> > vim +393 fs/btrfs/delayed-inode.c
> >
> >385
On 2013/6/13 10:38, Kent Overstreet wrote:
> On Thu, Jun 13, 2013 at 10:36:40AM +0800, Li Zefan wrote:
>> On 2013/6/13 5:03, Tejun Heo wrote:
>>> There's no point in using kmalloc() and list_del() instead of the
>>> clearing variants for trivial stuff. We can live dangerously
>>> elsewhere. Use
Hi, Peter
Would you like to give some comments on this approach? or may be just
some hint on what's the concern? the damage on pgbench is still there...
Regards,
Michael Wang
On 05/28/2013 01:05 PM, Michael Wang wrote:
> wake-affine stuff is always trying to pull wakee close to waker, by
On Wed, Jun 12, 2013 at 07:56:23PM -0700, Tejun Heo wrote:
> poison. Maybe it was something which got stuck in my brain from
> before the git history or I'm just hallucinating. Anyways, yeap,
Just checked 2.4. It didn't poison then. Somehow I never got that
out of my brain all these years.
On Fri, 2013-06-07 at 17:20 +0800, Li Zefan wrote:
> On 2013/5/31 21:06, Ben Hutchings wrote:
> > I'm announcing the release of the 3.2.46 kernel.
> >
> > All users of the 3.2 kernel series should upgrade.
> >
> > The updated 3.2.y git tree can be found at:
> >
> >
On Wed, 12 Jun 2013 19:05:36 -0700 Kent Overstreet
wrote:
> ...
>
> > Why can't we use ida_get_new_above()?
> >
> >If it is "speed" then how bad is the problem and what efforts have
> >been made to address them within the idr code? (A per-cpu magazine
> >frontend to
On Wed, Jun 12, 2013 at 07:52:02PM -0700, Kent Overstreet wrote:
> On Wed, Jun 12, 2013 at 07:48:59PM -0700, Tejun Heo wrote:
> > On Wed, Jun 12, 2013 at 07:43:10PM -0700, Kent Overstreet wrote:
> > > list_del() does do poisoning - and list debugging is cheaper to enable
> > > than full slab
On 06/12/2013 11:40 PM, Paul E. McKenney wrote:
> Breaking up locks is better than implementing high-contention locks, but
> if we must have high-contention locks, why not make them automatically
> switch between light-weight ticket locks at low contention and queued
> locks at high contention?
On Wed, Jun 12, 2013 at 07:48:59PM -0700, Tejun Heo wrote:
> On Wed, Jun 12, 2013 at 07:43:10PM -0700, Kent Overstreet wrote:
> > list_del() does do poisoning - and list debugging is cheaper to enable
> > than full slab debugging.
>
> Ah, right, now we have DEBUG_LIST. Completely forgot about
On Wed, Jun 12, 2013 at 07:43:10PM -0700, Kent Overstreet wrote:
> list_del() does do poisoning - and list debugging is cheaper to enable
> than full slab debugging.
Ah, right, now we have DEBUG_LIST. Completely forgot about that. I
don't think the cost difference matters that much as long as
hi, Dmitry
What are the status for these patches? Thanks.
On Wed, May 15, 2013 at 2:40 PM, Dmitry Torokhov
wrote:
> Hi Chao,
>
> On Mon, May 13, 2013 at 04:02:07PM +0800, Chao Xie wrote:
>> hi, dmitry
>> What is your idea about these patches?
>> Do i need add someone else to review them?
>>
>
>
(2013/06/12 13:45), Bjorn Helgaas wrote:
> [+cc Vivek, Haren; sorry I didn't think to add you earlier]
>
> On Tue, Jun 11, 2013 at 12:08 AM, Takao Indoh
> wrote:
>> (2013/06/11 11:20), Bjorn Helgaas wrote:
>
>>> I'm not sure you need to reset legacy devices (or non-PCI devices)
>>> yet, but the
On Mon, 2013-06-03 at 08:02 -0400, Konrad Rzeszutek Wilk wrote:
> Hey Greg,
>
> I hadn't (by mistake) put the CC: sta...@vger.kernel.org on said patch
> (Which is in the Linux kernel).
>
> If possible please back-port said patch to the existing stable trees.
> Attached is a version that applies
On Wed, Jun 12, 2013 at 07:34:43PM -0700, James Bottomley wrote:
> On Thu, 2013-06-13 at 09:30 +0800, Fengguang Wu wrote:
> > Greetings,
> >
> > I got the below dmesg and the first bad commit is
> >
> > commit a256ba092ec57213f96059d41ac5473ff92f5e7c
> > Author: Nicholas Bellinger
> > Date:
On 06/11/2013 03:32 PM, Geert Uytterhoeven wrote:
> On Tue, Jun 11, 2013 at 12:26 AM, Tony Luck wrote:
>> > On Sat, Jun 8, 2013 at 3:08 AM, Chen Gang wrote:
>>> >> using 'unsigned int *', implicitly:
>>> >> ./ia64/include/asm/bitops.h:63:__set_bit (int nr, volatile void *addr)
>> >
>> > There
On Wed, Jun 12, 2013 at 07:41:15PM -0700, Tejun Heo wrote:
> Hello,
>
> On Wed, Jun 12, 2013 at 7:38 PM, Kent Overstreet
> wrote:
> > IMO, list_del() is preferred when the object shouldn't be reused (i.e.
> > it gets taken off a list and then it's freed). list_del_init() could
> > hide bugs.
>
Quoting Heiko Stübner (2013-06-03 15:18:32)
> Am Montag, 3. Juni 2013, 19:53:10 schrieb Mike Turquette:
> > Devicetree binding for the basic clock divider, plus the setup function
> > to register the clock. Based on the existing fixed-clock binding.
> >
> > Signed-off-by: Mike Turquette
> > ---
Hello,
On Wed, Jun 12, 2013 at 7:38 PM, Kent Overstreet wrote:
> IMO, list_del() is preferred when the object shouldn't be reused (i.e.
> it gets taken off a list and then it's freed). list_del_init() could
> hide bugs.
Nah... use-after-frees are detected much more reliably by poisoning
anyway.
Hello,
On Wed, Jun 12, 2013 at 7:36 PM, Li Zefan wrote:
> Do you mean we prefer list_del_init() than list_del() in general? Then
Yes.
> in which cases do we prefer list_del()?
Nowadays, I don't think we ever prefer list_del(). Maybe if it can be
shown that the extra init part is noticeably
On Thu, Jun 13, 2013 at 10:36:40AM +0800, Li Zefan wrote:
> On 2013/6/13 5:03, Tejun Heo wrote:
> > There's no point in using kmalloc() and list_del() instead of the
> > clearing variants for trivial stuff. We can live dangerously
> > elsewhere. Use kzalloc() and list_del_init() instead and drop
On 2013/6/13 5:03, Tejun Heo wrote:
> * __css_get() isn't used by anyone. Fold it into css_get().
>
> * Add proper function comments to all css reference functions.
>
> This patch is purely cosmetic.
>
> Signed-off-by: Tejun Heo
> ---
> include/linux/cgroup.h | 48
On 2013/6/13 5:03, Tejun Heo wrote:
> There's no point in using kmalloc() and list_del() instead of the
> clearing variants for trivial stuff. We can live dangerously
> elsewhere. Use kzalloc() and list_del_init() instead and drop 0
> inits.
>
Do you mean we prefer list_del_init() than
My aboriginal linux project builds tiny linux systems to run under
qemu, producing as close to the same system as possible across a bunch
of different architectures. The above change broke the mips r4k build
I've been running under qemu.
Here's a toolchain and reproduction sequence:
On 2013/6/13 5:03, Tejun Heo wrote:
> cgroups and css_sets are mapped M:N and this M:N mapping is
> represented by struct cg_cgroup_link which points to forms linked
> lists on both sides. The naming around this already confusing struct
> is pretty bad.
>
>>From cgroup side, it starts off
On Thu, 2013-06-13 at 09:30 +0800, Fengguang Wu wrote:
> Greetings,
>
> I got the below dmesg and the first bad commit is
>
> commit a256ba092ec57213f96059d41ac5473ff92f5e7c
> Author: Nicholas Bellinger
> Date: Sat May 18 02:40:43 2013 -0700
>
> scsi: Split scsi_dispatch_cmd into
On Sat, 2013-06-01 at 00:55 -0400, David Dillow wrote:
> On Tue, 2013-05-28 at 15:45 +0200, Jiri Kosina wrote:
> > I'd be glad if you could provide your Tested-by: for the patch below.
> > Thanks a lot.
>
> I tried to test this tonight, but was thwarted by Fedora 16 on the only
> readily
On 06/08/2013 06:08 PM, Chen Gang wrote:
> Several architectures have different __set_bit() API to others, in
> standard API, 2nd param of __set_bit() is 'unsigned long *', but:
>
> in 'min10300', it is 'unsigned char *',
Oh, it is my fault, for 'mn10300' it is no issue, it is not 'unsigned
On Wed, 2013-05-29 at 17:37 -0400, Eduardo Valentin wrote:
> In case emulated temperature is in use, using the trend
> provided by driver layer can lead to bogus situation.
> In this case, debugger user would set a temperature value,
> but the trend would be from driver computation.
>
> To avoid
I forget change final_start/final_end to start/end. The old code add empty
range in following case:
Before mtrr cleanup:
1. got initial MTRR range: 0-3G.
2. MTRR code try to merge 0-1M
3. result is 0-0, 0-3G, total 2 range count
After cleanup:
1. got final MTRR range: 0-3G, total 1 range
On Wed, 2013-05-29 at 11:07 -0400, Eduardo Valentin wrote:
> Hello Rui,
>
> Here is a patch set for your consideration on ti-soc-thermal driver.
>
the whole patch set has been applied.
thanks,
rui
> This patch set is mix of:
>
> (a) patches that were added to the staging tree post 3.10-rc1
On 13/06/2013 05:01, Stephen Hemminger wrote:
On Wed, 12 Jun 2013 15:12:05 -0700 (PDT)
David Miller wrote:
From: Eliezer Tamir
Date: Tue, 11 Jun 2013 17:24:28 +0300
depends on X86_TSC
Wait a second, I didn't notice this before. There needs to be a better
way to test for the
On ARM max_pfn and max_low_pfn have always been relative to the
first valid PFN, apparently due to ancient kernels being unable
to properly handle physical memory at addresses other than 0.
A comment was added:
Note: max_low_pfn and max_pfn reflect the number of _pages_ in
the system, not
On Wed, Jun 12, 2013 at 04:43:44PM +0900, Yoshihiro YUNOMAE wrote:
> Add a tracepoint write_tsc_offset for tracing TSC offset change.
> We want to merge ftrace's trace data of guest OSs and the host OS using
> TSC for timestamp in chronological order. We need "TSC offset" values for
> each guest
On 06/10/2013 10:15 PM, Thomas Gleixner wrote:
> On Sun, 9 Jun 2013, Chen Gang wrote:
>> > After finish the internal 'while', need not test TASKLET_STATE_SCHED
>> > again, so looping back to outside 'while' is only for set_bit().
>> >
>> > When use 'if' and set_bit() instead of 'while', it will
On 06/10/2013 08:25 PM, Paul E. McKenney wrote:
> On Sun, Jun 09, 2013 at 08:30:19PM +0800, Chen Gang wrote:
>> >
>> > After finish the internal 'while', need not test TASKLET_STATE_SCHED
>> > again, so looping back to outside 'while' is only for set_bit().
>> >
>> > When use 'if' and set_bit()
On Wed, Jun 12, 2013 at 04:38:54PM -0700, Andrew Morton wrote:
> On Tue, 11 Jun 2013 21:03:24 -0700 Kent Overstreet
> wrote:
>
> > Allocates integers out of a predefined range
>
> 0..n, I assume. Not n..m.
Yes (though n..m would be trivial if anyone wanted it)... and
percpu_tag_pool_init()
Commit da12c90e099789a63073fc82a19542ce54d4efb9
"netlink: Add compare function for netlink_table"
only set compare at the time we create kernel netlink,
and reset compare to NULL at the time we finially
release netlink socket, but netlink_lookup wants
the compare exist always.
So we should set
On Fri, Jun 07, 2013 at 05:14:52PM +0100, Al Viro wrote:
> On Fri, Jun 07, 2013 at 11:09:05AM -0500, Dave Chiluk wrote:
> > Can't you just use the patch from my original e-mail? Anyhow I attached
> > it an already signed-off patch.
> >
> > Al Viro Can you integrate it now?
>
> Applied... FWIW,
On Wed, 12 Jun 2013 15:12:05 -0700 (PDT)
David Miller wrote:
> From: Eliezer Tamir
> Date: Tue, 11 Jun 2013 17:24:28 +0300
>
> > depends on X86_TSC
>
> Wait a second, I didn't notice this before. There needs to be a better
> way to test for the accuracy you need, or if the issue is lack
On Wed, Jun 12, 2013 at 10:29:17AM -0700, Yinghai Lu wrote:
> On Wed, Jun 12, 2013 at 9:08 AM, Wang YanQing wrote:
> >
> > This patch convert __init to __init_memblock
> > for functions which make reference to memblock variable
> > with attribute __meminitdata.
>
> for which arch?
I just think
Some of Qualcomm's clocks can change their parent and rate at the
same time with a single register write. Add support for this
hardware to the common clock framework by adding a new
set_rate_and_parent() op. When the clock framework determines
that both the parent and the rate are going to change
Export this symbol so that modules can register fixed rate
clocks.
Signed-off-by: Stephen Boyd
---
drivers/clk/clk-fixed-rate.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/clk/clk-fixed-rate.c b/drivers/clk/clk-fixed-rate.c
index dc58fbd..1ed591a 100644
---
Consolidate DT parsing for the common bits of a clock binding in
one place to simplify clock drivers. This also has the added
benefit of standardizing how the clock names used by the common
clock framework are generated from the DT bindings. We always use
the first clock-output-names string if it
Add a clock driver that registers clocks from a DT node's
'clocks' child. Each new SoC will add a file describing the
software interface and frequency plan to drivers/clk/msm/ and
then hook that into the msm_cc_match_table by means of a
compatible string and an msm_clk_match table.
Signed-off-by:
Add support for MSM's PLLs (phase locked loops). This is
sufficient enough to be able to determine the rate the PLL is
running at.
Cc: devicetree-disc...@lists.ozlabs.org
Signed-off-by: Stephen Boyd
---
Documentation/devicetree/bindings/clock/msm.txt | 40
drivers/clk/Kconfig
Posting as an RFC because I haven't gone through and generated all
the data needed yet. This is just a few clocks for now to give a general
idea of where things are headed.
The first 4 patches are generic clock framework patches. They add support
for finding clocks in DT and parsing them
Add the necessary DT data to probe the global clock controller
on MSM8960 devices.
Signed-off-by: Stephen Boyd
---
arch/arm/boot/dts/msm8960-cdp.dts | 72 +++
1 file changed, 72 insertions(+)
diff --git a/arch/arm/boot/dts/msm8960-cdp.dts
Add the necessary DT data to probe the multimedia clock controller
on MSM8960 devices.
Signed-off-by: Stephen Boyd
---
arch/arm/boot/dts/msm8960-cdp.dts | 37 +
1 file changed, 37 insertions(+)
diff --git a/arch/arm/boot/dts/msm8960-cdp.dts
1 - 100 of 1296 matches
Mail list logo
