The s2mpa01 regulator driver can be safely removed since it was merged
into s2mps11 driver.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/mfd/s2mpa01.txt | 90
drivers/regulator/Kconfig | 7 -
drivers/regulator/Makefile
Add S2MPA01 support to the s2mps11 regulator driver. This obsoletes the
s2mpa01 regulator driver.
Signed-off-by: Krzysztof Kozlowski
---
Documentation/devicetree/bindings/mfd/s2mps11.txt | 106
drivers/regulator/Kconfig | 4 +-
drivers/regulator/s2mps11.c
Hi,
The patchset merges s2mpa01 regulator driver into s2mps11. As a result
the s2mps11 supports:
- S2MPA01
- S2MPS11
- S2MPS14
These PMIC-s are very similar to each other and they are often used
along with Samsung's Exynos SoCs. Merging this into one driver has
two benefits:
- less code
On Wed, May 14, 2014 at 12:35:18PM -0700, Mike Turquette wrote:
> Quoting Thierry Reding (2014-05-14 07:27:40)
[...]
> > As for shared clocks I'm only aware of one use-case, namely EMC scaling.
> > Using clocks for that doesn't seem like the best option to me. While it
> > can probably fix the
Il 26/05/2014 05:44, Zhang, Yang Z ha scritto:
Paolo Bonzini wrote on 2014-05-23:
When Hyper-V enlightenments are in effect, Windows prefers to issue an
Hyper-V MSR write to issue an EOI rather than an x2apic MSR write.
The Hyper-V MSR write is not handled by the processor, and besides
being
On 23 May 2014 14:52, wrote:
> From: Srinivas Kandagatla
>
> This patch adds specifics of clk and datactrl register on Qualcomm SD
> Card controller. This patch also populates the Qcom variant data with
> these new values specific to Qualcomm SD Card Controller.
>
> Signed-off-by: Srinivas
On Mon, May 26, 2014 at 02:40:58PM +0200, Rafael J. Wysocki wrote:
> On Monday, May 26, 2014 02:52:35 PM Mika Westerberg wrote:
> > On Mon, May 26, 2014 at 01:53:39PM +0200, Rafael J. Wysocki wrote:
> > > > I'm wondering whether it is worth the ugliness to get platform bus
> > > > enumeration the
On Sun, May 25, 2014 at 6:22 PM, Hani Benhabiles wrote:
> Len field is already set to zero, but not the from field which is sent as
> 0xfe00. This makes no sense, and may cause confuse server
> implementations doing sanity checks (qemu-nbd is an example.)
>
> Signed-off-by: Hani
Il 26/05/2014 00:58, Wei Huang ha scritto:
If so , my question: is there other special cases similar to task switch
which can break patch 4?
I don't think so. CPL can only change when SS is loaded, i.e. for
inter-privilege transfers that aren't far calls or far jumps to a
conforming code
On Fri, 2014-05-23 at 13:42 -0500, Kumar Gala wrote:
> Ivan T. Ivanov (1):
>ARM: debug: qcom: make UART address selection configuration option
This one just landed in linux-next (next-20140526).
It removed the Kconfig options DEBUG_MSM_UART1, DEBUG_MSM_UART3, and
DEBUG_MSM_UART3.
Hi Lv,
There was a merge conflict with the new ACPICA material queued up for 3.16
related to this.
Can you please have a look at the linux-next branch in my tree and see if
the ACPICA material in there is in a good shape?
Rafael
On Tuesday, May 13, 2014 04:50:30 PM Lv Zheng wrote:
> We need
On Friday, May 23, 2014 04:15:09 PM Heikki Krogerus wrote:
> A power domain where we save the context of the additional
> LPSS registers. We need to do this or all LPSS devices are
> left in reset state when resuming from D3 on some Baytrails.
> The devices with the fractional clock divider also
On Mon, 26 May 2014, Amir Vadai wrote:
> On 5/26/2014 2:34 PM, Thomas Gleixner wrote:
> > You are not describing what needs to be notified and why. Please
> > explain the details of that and how the RFS (whatever that is) and the
> > network driver are connected
> The goal of RFS is to increase
Il 26/05/2014 01:21, Wei Huang ha scritto:
CS.RPL is not equal to the CPL in the few instructions between
setting CR0.PE and reloading CS. And CS.DPL is also not equal
to the CPL for conforming code segments.
Out of my curiousity, could you elaborate the problem of this
CPL gap window, such
On Wednesday, May 21, 2014 04:22:58 PM Aaron Lu wrote:
> On 05/21/2014 01:57 PM, Kui Zhang wrote:
> > Hello,
> >
> > I get following error when rmmod thermal.
> >
> > rmmod thermal
> > Killed
>
> Thanks for the report. Here is a fix patch that should solve this
> problem.
>
> From: Aaron Lu
On Monday, May 26, 2014 02:52:35 PM Mika Westerberg wrote:
> On Mon, May 26, 2014 at 01:53:39PM +0200, Rafael J. Wysocki wrote:
> > > I'm wondering whether it is worth the ugliness to get platform bus
> > > enumeration the default?
> > >
> > > Since you already have the PNP whitelist, can't we
On 26.05.2014 09:02, Malte Schröder wrote:
> On 25.05.2014 14:56, Woody Suwalski wrote:
>> Malte Schröder wrote:
>>> Hi,
>>> I just tried 3.15-rc6. I encountered a pretty nasty problem, which is
>>> after suspending to RAM the system doesn't wake up properly. v3.14 is
>>> fine.
>>> On wakeup all
Il 25/05/2014 22:05, Nadav Amit ha scritto:
MOV CR/DR instructions ignore the mod field (in the ModR/M byte). As the SDM
states: "The 2 bits in the mod field are ignored". Accordingly, the second
operand of these instructions is always a general purpose register.
The current emulator
On 2014/5/26 13:11, Mike Galbraith wrote:
> On Mon, 2014-05-26 at 11:04 +0800, Libo Chen wrote:
>> hi,
>> my box has 16 cpu (E5-2658,8 core, 2 thread per core), i did a test on
>> 3.4.24stable, startup 50 same process, every process is sample:
>>
>> #include
>>
>> int main()
>>
Rejecting unsupported values of spi-tx-bus-width and spi-rx-bus-width
may break compatibility with future DTs. Just ignore them, falling back
to Single SPI Transfers.
Signed-off-by: Geert Uytterhoeven
---
I thought I sent this before, but I can't find any evidence
drivers/spi/spi.c | 18
On 5/26/2014 2:34 PM, Thomas Gleixner wrote:
On Mon, 26 May 2014, Amir Vadai wrote:
On 5/26/2014 2:15 PM, Thomas Gleixner wrote:
On Sun, 25 May 2014, Amir Vadai wrote:
In order to do that, I need to add a new irq affinity notification
callback (In addition to the existing cpu_rmap
audit_filter_syscall uses the syscall number to reference into a
bitmask (e->rule.mask[word]). Not removing the x32 bit before passing
the number to this architecture independent codepath will fail to
lookup the proper audit bit. Furthermore it will cause an invalid memory
access in the kernel if
Hi Grant,
On May 26, 2014, at 2:23 PM, Grant Likely wrote:
> On Mon, 26 May 2014 12:57:32 +0200, Geert Uytterhoeven
> wrote:
>> Hi Grant,
>>
>> On Mon, May 26, 2014 at 12:48 PM, Grant Likely
>> wrote:
>>> On Tue, 20 May 2014 09:38:49 +0200, Geert Uytterhoeven
>>> wrote:
On Tue, May
In the end of the cascading code of flush_workqueue(), the current
first-flusher will hand over the cascading-responsibility to the next
flusher and make the next flusher to be the new first-flusher.
But when the current first-flusher finds out that the color of the next
flusher is already done,
Since the current first-flusher always passes the cascading responsibility
to the next flusher, the body of "while(true)" loop is running exactly once,
"while(true)" loop is unneeded. So we remove the "while(true)" loop and
adjust the indent.
Note, there is no "continue" inside the "while(true)"
On Mon, May 26, 2014 at 01:53:39PM +0200, Rafael J. Wysocki wrote:
> > I'm wondering whether it is worth the ugliness to get platform bus
> > enumeration the default?
> >
> > Since you already have the PNP whitelist, can't we just use that for PNP
> > and keep these files as they are? In other
On 2014/5/26 15:56, Mike Galbraith wrote:
> On Mon, 2014-05-26 at 11:04 +0800, Libo Chen wrote:
>> hi,
>> my box has 16 cpu (E5-2658,8 core, 2 thread per core), i did a test on
>> 3.4.24stable, startup 50 same process, every process is sample:
>>
>> #include
>>
>> int main()
>>
(2014/05/26 20:25), Suzuki K. Poulose wrote:
> On 05/07/2014 05:25 PM, Masami Hiramatsu wrote:
>> On ia64 and ppc64, the function pointer does not point the
>> entry address of the function, but the address of function
>> discriptor (which contains the entry address and misc
>> data.) Since the
Tetsuo Handa wrote:
> Dave, if you are OK with this updated patch, please let me know commit ID of
> your patch.
I overlooked that too_many_isolated() in mm/vmscan.c already has
if (current_is_kswapd())
return 0;
lines. Therefore, it turned out that my patch is irrelevant to XFS issue.
Hi
(CC migrate.c committers)
On Tue, May 20, 2014 at 12:11 AM, Hugh Dickins wrote:
> On Mon, 19 May 2014, Jan Kara wrote:
>> On Mon 19-05-14 13:44:25, David Herrmann wrote:
>> > On Thu, May 15, 2014 at 12:35 AM, Hugh Dickins wrote:
>> > > The aspect which really worries me is this: the
Hi,
the following set of patches implements the deterministic random bit generator
(DRBG) specified by SP800-90A.
The DRBG implementation offers the following:
* All three DRBG types are implemented with a derivation function.
* All DRBG types are available with and without
On Monday, May 26, 2014 01:56:36 PM Mika Westerberg wrote:
> On Fri, May 23, 2014 at 02:02:30AM +0800, Zhang Rui 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.
>
The header file includes the definition of:
* DRBG data structures with
- struct drbg_state as main structure
- struct drbg_core referencing the backend ciphers
- struct drbg_state_ops callbach handlers for specific code
supporting the Hash, HMAC, CTR DRBG
On Mon, Feb 10, 2014 at 02:42:08PM -0800, a...@linux-foundation.org wrote:
> diff -puN include/linux/mm.h~pagewalk-update-page-table-walker-core
> include/linux/mm.h
> --- a/include/linux/mm.h~pagewalk-update-page-table-walker-core
> +++ a/include/linux/mm.h
> @@ -1075,10 +1075,18 @@ void
The different DRBG types of CTR, Hash, HMAC can be enabled or disabled
at compile time. At least one DRBG type shall be selected.
The default is the HMAC DRBG as its code base is smallest.
Signed-off-by: Stephan Mueller
---
crypto/Kconfig | 36 +++-
1 file
On Mon, 26 May 2014, Amir Vadai wrote:
> On 5/26/2014 2:15 PM, Thomas Gleixner wrote:
> > On Sun, 25 May 2014, Amir Vadai wrote:
> > > In order to do that, I need to add a new irq affinity notification
> > > callback (In addition to the existing cpu_rmap notification). For
> > > that I would like
Signed-off-by: Stephan Mueller
---
crypto/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/Makefile b/crypto/Makefile
index 38e64231..bfa94fa 100644
--- a/crypto/Makefile
+++ b/crypto/Makefile
@@ -92,6 +92,7 @@ obj-$(CONFIG_CRYPTO_842) += 842.o
obj-$(CONFIG_CRYPTO_RNG2) +=
All types of the DRBG (CTR, HMAC, Hash) are covered with test vectors.
In addition, all permutations of use cases of the DRBG are covered:
* with and without predition resistance
* with and without additional information string
* with and without personalization string
As
lThe DRBG test code implements the CAVS test approach.
As discussed for the test vectors, all DRBG types are covered with
testing. However, not every backend cipher is covered with testing. To
prevent the testmgr from logging missing testing, the NULL test is
registered for all backend ciphers
On Monday, May 26, 2014 04:37:13 PM Viresh Kumar wrote:
> On 26 May 2014 16:52, Rafael J. Wysocki wrote:
> > I agree as far as the 64-bit thing goes, but is switching to Hz really
> > necessary?
>
> Don't really know that.. It seems that there will always be problems with
> close enough
The drbg.stdrng kernel command line flag allows the selection of the
DRBG used as stdrng.
Signed-off-by: Stephan Mueller
---
Documentation/kernel-parameters.txt | 10 ++
1 file changed, 10 insertions(+)
diff --git a/Documentation/kernel-parameters.txt
On 05/07/2014 05:25 PM, Masami Hiramatsu wrote:
> On ia64 and ppc64, the function pointer does not point the
> entry address of the function, but the address of function
> discriptor (which contains the entry address and misc
> data.) Since the kprobes passes the function pointer stored
> by
On Mon, 26 May 2014 12:57:32 +0200, Geert Uytterhoeven
wrote:
> Hi Grant,
>
> On Mon, May 26, 2014 at 12:48 PM, Grant Likely
> wrote:
> > On Tue, 20 May 2014 09:38:49 +0200, Geert Uytterhoeven
> > wrote:
> >> On Tue, May 20, 2014 at 7:50 AM, Grant Likely
> >> wrote:
> >> >> Why has the
On 5/26/2014 2:15 PM, Thomas Gleixner wrote:
On Sun, 25 May 2014, Amir Vadai wrote:
In order to do that, I need to add a new irq affinity notification
callback (In addition to the existing cpu_rmap notification). For
that I would like to extend irq_set_affinity_notifier() to have a
notifier
On Fri, May 23, 2014 at 03:23:10PM +1000, Stephen Rothwell wrote:
> Hi Chris,
>
> Today's linux-next merge of the mmc tree got a conflict in
> include/linux/omap-dma.h between commit a8246fedacad ("dmaengine: omap:
> hide filter_fn for built-in drivers") from the slave-dma tree and
> commit
Hi Matthew,
Sorry for asking this again.
Just realize previous email was blocked by mailling list rule.
May I know when the platform driver tree will be pulled next time?
Thanks,
Shuduo
On 2014年05月06日 20:27, Shuduo Sang wrote:
Hi Matthew,
>
> I see Linus tree version continue to increase
On Sun, 25 May 2014, Amir Vadai wrote:
> In order to do that, I need to add a new irq affinity notification
> callback (In addition to the existing cpu_rmap notification). For
> that I would like to extend irq_set_affinity_notifier() to have a
> notifier call-chain instead of a single notifier
On Sat, May 24, 2014 at 12:24:32AM +0200, Saravana Kannan wrote:
> On 05/23/2014 03:59 AM, Peter De Schrijver wrote:
> > This patch flattens the clk tree in CCF debugfs. Instead of representing the
> > clocks and their hierarchy as a directory structure under
> > /sys/kernel/debug/clk, each clock
Hi,
On 26.05.2014 05:23, Tarek Dakhran wrote:
> The series of patches represent support of Exynos 5410 SoC
>
> The Exynos 5410 is the first Samsung SoC based on big.LITTLE architecture
>
> Patches add new platform description, support of clock controller and device
> tree for Exynos 5410.
>
>
During CPU offline, in stop-machine, we don't enforce any rule in the
_DISABLE_IRQ stage, regarding the order in which the outgoing CPU and the other
CPUs disable their local interrupts. Hence, we can encounter a scenario as
depicted below, in which IPIs are sent by the other CPUs to the CPU going
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 is very hard to debug exactly who sent the IPI and why,
from this info alone.
In most cases, we get the warning about the IPI
Hi,
There is a long-standing problem related to CPU hotplug which causes IPIs to
be delivered to offline CPUs, and the smp-call-function IPI handler code
prints out a warning whenever this is detected. Every once in a while this
(usually harmless) warning gets reported on LKML, but so far it has
On Mon, May 26, 2014 at 12:05 PM, Chen Hanxiao
wrote:
> We need a direct method of getting the pid inside containers.
> If some issues occurred inside a container guest, host user
> could not know which process is in trouble just by guest pid:
> the users of container guest only knew the pid
Hi Geert,
On May 26, 2014, at 1:57 PM, Geert Uytterhoeven wrote:
> Hi Grant,
>
> On Mon, May 26, 2014 at 12:48 PM, Grant Likely
> wrote:
>> On Tue, 20 May 2014 09:38:49 +0200, Geert Uytterhoeven
>> wrote:
>>> On Tue, May 20, 2014 at 7:50 AM, Grant Likely
>>> wrote:
> Why has the
On 26 May 2014 16:52, Rafael J. Wysocki wrote:
> I agree as far as the 64-bit thing goes, but is switching to Hz really
> necessary?
Don't really know that.. It seems that there will always be problems with
close enough frequencies whenever rounding is done.
More can be elaborated by Soren.
--
On Mon, May 26, 2014 at 12:51:10PM +0200, Jiri Kosina wrote:
> I think the comment is still not explaining the big part of what the
> discussion was about -- i.e. if it was in kernel context, we always
> panic.
I thought the pointer to mce_severity was enough? People should open an
editor and
On Monday, May 26, 2014 11:59:09 AM Viresh Kumar wrote:
> On 23 May 2014 21:44, Sören Brinkmann wrote:
> > Viresh: Could you imagine something similar for cpufreq? You suggested
> > migrating to Hz resolution. I guess that would ideally mean to follow
> > the CCF to a 64-bit type for frequencies
On 05/26/2014 04:30 PM, Rafael J. Wysocki wrote:
> On Monday, May 26, 2014 02:01:14 PM Srivatsa S. Bhat wrote:
>> On 05/23/2014 06:33 PM, Rafael J. Wysocki wrote:
>>> From: Rafael J. Wysocki
>>>
>>> On some systems the platform doesn't support neither
>>> PM_SUSPEND_MEM nor PM_SUSPEND_STANDBY, so
Hi Grant,
On Mon, May 26, 2014 at 12:48 PM, Grant Likely
wrote:
> On Tue, 20 May 2014 09:38:49 +0200, Geert Uytterhoeven
> wrote:
>> On Tue, May 20, 2014 at 7:50 AM, Grant Likely
>> wrote:
>> >> Why has the overlay system been designed for plugging and unpluging whole
>> >> overlays?
>> >>
On Fri, May 23, 2014 at 02:02:30AM +0800, Zhang Rui 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
On Mon, May 26, 2014 at 01:27:55PM +0800, Lai Jiangshan wrote:
> changing pwq:
> install pwq
> lock(pool->lock)
> put_pwq();
> unlock(pool->lock)
>
> __queue_work():
> lock(pool->lock)
> test ref and find it zero;
> see the installation here;
> it
On Mon, 19 May 2014, Roland Dreier wrote:
> > Roland, we're soon on -rc6 and there's no reason for this to miss
> > 3.16, could you please comment whether you want it to go through your
> > tree or net-next?
>
> I will pick it up.
Thanks Roland.
Sorry for being a bit persistent, but another
On Mon, 26 May 2014, Borislav Petkov wrote:
> On Wed, May 21, 2014 at 03:13:54PM -0700, H. Peter Anvin wrote:
> > Seems like a comment would be in order, though.
>
> ---
> From: Borislav Petkov
> Subject: [PATCH] x86, MCE: Flesh out when to panic comment
>
> Recent discussion (link below)
On Mon, May 26, 2014 at 07:23:47PM +0900, Daeseok Youn wrote:
> When dgap_tty_init() and dgap_tty_register_ports() are failed,
> these are needed to free some memory properly.
>
> It can be handled by calling dgap_tty_uninit() and dgap_cleanup_board().
> But tty's ports are not registered yet
On Tue, 20 May 2014 09:38:49 +0200, Geert Uytterhoeven
wrote:
> Hi Grant,
>
> On Tue, May 20, 2014 at 7:50 AM, Grant Likely
> wrote:
> >> Why has the overlay system been designed for plugging and unpluging whole
> >> overlays?
> >> That means the kernel has to remember the full stack, causing
On Monday, May 26, 2014 02:01:14 PM Srivatsa S. Bhat wrote:
> On 05/23/2014 06:33 PM, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > On some systems the platform doesn't support neither
> > PM_SUSPEND_MEM nor PM_SUSPEND_STANDBY, so PM_SUSPEND_FREEZE is the
> > only available system
On Mon, May 26, 2014 at 07:04:53PM +0900, Heesub Shin wrote:
> @@ -124,7 +122,6 @@ static struct page_info *alloc_largest_available(struct
> ion_system_heap *heap,
>
> info->page = page;
> info->order = orders[i];
> - INIT_LIST_HEAD(>list);
>
Hi Chander,
On 16.05.2014 10:03, Chander Kashyap wrote:
> Exynos5420 is a big-little Soc from Samsung. It has 4 A15 and 4 A7 cores.
>
> This patchset adds cpuidle support for Exynos5420 SoC based on
> generic big.little cpuidle driver.
>
> Tested on SMDK5420.
>
> This patch set depends on:
>
If printer_ports which is allocated after serial_ports is failed
to allocate, tty_port_init for serial_ports doesn't need anymore.
So move this after allocating memory for printer_ports.
Signed-off-by: Daeseok Youn
---
drivers/staging/dgap/dgap.c |6 +++---
1 files changed, 3 insertions(+),
When it failed to allocate for printer_ports, serial_ports
can be freed in dgap_tty_uninit().
Signed-off-by: Daeseok Youn
---
drivers/staging/dgap/dgap.c |5 ++---
1 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index
When dgap_tty_init() and dgap_tty_register_ports() are failed,
these are needed to free some memory properly.
It can be handled by calling dgap_tty_uninit() and dgap_cleanup_board().
But tty's ports are not registered yet when these function are failed,
so brd->nasync set to zero.
Signed-off-by:
In destruct_tty_driver() from put_tty_driver() will free the
ttys in tty_driver.
Signed-off-by: Daeseok Youn
---
drivers/staging/dgap/dgap.c |4
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index
On Fri, May 23, 2014 at 02:02:32AM +0800, Zhang Rui wrote:
> 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.
>
On Wed, May 21, 2014 at 03:13:54PM -0700, H. Peter Anvin wrote:
> Seems like a comment would be in order, though.
---
From: Borislav Petkov
Subject: [PATCH] x86, MCE: Flesh out when to panic comment
Recent discussion (link below) showed that it is not really clear what
appropriate recovery
On 26 May 2014 11:16, Preeti U Murthy wrote:
> On 05/26/2014 01:19 PM, Vincent Guittot wrote:
>> On 25 May 2014 12:33, Preeti U Murthy wrote:
>>> Hi Vincent,
>>>
>>> On 05/23/2014 09:22 PM, Vincent Guittot wrote:
The imbalance flag can stay set whereas there is no imbalance.
Let
ION system heap uses an internal data structure, struct page_info, for
tracking down the meta information of the pages allocated from the pool.
Now that the pool returns compound pages, we don't need to store page
order in struct page_info.
Signed-off-by: Heesub Shin
---
ION system heap uses a temporary list holding meta data on pages
allocated to build scatter/gather table. Now that the pages are compound
pages, we do not need to introduce a new data type redundantly.
Signed-off-by: Heesub Shin
---
drivers/staging/android/ion/ion_system_heap.c | 47
Using compound pages relieves burden on tracking the meta information
which are currently stored in page_info.
Signed-off-by: Heesub Shin
---
drivers/staging/android/ion/ion_page_pool.c | 4 +++-
drivers/staging/android/ion/ion_system_heap.c | 2 +-
2 files changed, 4 insertions(+), 2
Now that the order information is held on struct page itself, we do not
need to use extra data structure. This commit reduces unnecessary slab
usage for allocating small objects.
Signed-off-by: Heesub Shin
---
drivers/staging/android/ion/ion_page_pool.c | 27 +--
1 file
struct ion_system_heap has an array for storing pointers to page pools
and it is allocated separately from the containing structure. There is
no point in allocating those two small objects individually, bothering
slab allocator. Using a variable length array simplifies code lines and
reduces
On 23 May 2014 14:52, wrote:
> From: Srinivas Kandagatla
>
> This patch adds 8bit bus enable to variant structure giving more flexibility
> to the driver to support more SOCs which have different clock register layout.
>
> Without this patch other new SOCs like Qcom will have to add more code
>
ION system heap keeps pages in its pool for better performance. When the
system is under memory pressure, slab shrinker calls the callback
registered and then the pages pooled get freed.
When the shrinker is called, it checks gfp_mask and determines whether
the pages from highmem need to be freed
Not that the pages returned from the pool are compound pages, we do not
need to pass the order information to free_buffer_page().
Signed-off-by: Heesub Shin
---
drivers/staging/android/ion/ion_system_heap.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git
ion_page_pool_total() returns the total number of pages in the pool.
Depending on the argument passed, it counts pages from highmem zone in
or not. This commit simplifies the code lines for better readability.
Signed-off-by: Heesub Shin
---
drivers/staging/android/ion/ion_page_pool.c | 10
For aesthetics and readability, rename goto labels, remove
useless code lines, and clarify function return type.
Signed-off-by: Heesub Shin
---
drivers/staging/android/ion/ion_page_pool.c | 2 +-
drivers/staging/android/ion/ion_priv.h| 2 +-
On 26 May 2014 11:44, Preeti U Murthy wrote:
> Hi Vincent,
>
> I conducted test runs of ebizzy on a Power8 box which had 48 cpus.
> 6 cores with SMT-8 to be precise. Its a single socket box. The results
> are as below.
>
> On 05/23/2014 09:22 PM, Vincent Guittot wrote:
>> Part of this patchset
We need a direct method of getting the pid inside containers.
If some issues occurred inside a container guest, host user
could not know which process is in trouble just by guest pid:
the users of container guest only knew the pid inside containers.
This will bring obstacle for trouble shooting.
Add DT bindings for tps65917 PMIC.
Signed-off-by: Keerthy
---
Documentation/devicetree/bindings/mfd/palmas.txt |2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/mfd/palmas.txt
b/Documentation/devicetree/bindings/mfd/palmas.txt
index e5f0f83..eda8989
Add TPS65917 Bindings.
Signed-off-by: Keerthy
---
.../bindings/regulator/tps65917-pmic.txt | 67
1 file changed, 67 insertions(+)
create mode 100644
Documentation/devicetree/bindings/regulator/tps65917-pmic.txt
diff --git
On Fri, May 23, 2014 at 6:24 PM, Lucas Stach wrote:
>> The best way to solve this issue would be to not use the BAR at all
>> since the memory behind these objects can be directly accessed by the
>> CPU. As such it would better be mapped using ttm_bo_kmap_ttm()
>> instead. But right now this is
Add tps65917 specific definitions and enums.
Signed-off-by: Keerthy
---
include/linux/mfd/palmas.h | 793
1 file changed, 793 insertions(+)
diff --git a/include/linux/mfd/palmas.h b/include/linux/mfd/palmas.h
index ccbb21f..52a24a9 100644
---
Add tps65917 PMIC support. tps65917 is a subset of palmas PMIC.
Some of the register definitions and the interrupt mappings
are different.
Signed-off-by: Keerthy
---
drivers/mfd/palmas.c | 177 --
1 file changed, 172 insertions(+), 5 deletions(-)
This patch adds support for TPS65917 PMIC regulators.
The regulators set consists of 5 SMPSs and 5 LDOs. The output
voltages are configurable and are meant to supply power to the
main processor and other components.
Signed-off-by: Keerthy
---
drivers/regulator/Kconfig | 12 +
The TPS65917 chip is a power management IC for Portable Navigation Systems
and Tablet Computing devices. It contains the following components:
- Regulators.
- GPADC.
- Over Temperature warning and Shut down.
This patch series adds support for TPS65917 mfd device. At this time only
the
On Thu, May 15, 2014 at 11:04:51AM -0500, ttha...@altera.com wrote:
> From: Thor Thayer
>
> v2: Use the SDRAM controller registers to calculate memory size
> instead of the Device Tree. Update To & Cc list. Add maintainer
> information.
>
> v3: EDAC driver cleanup based on comments from
Current code has .enable_reg and .enable_mask settings, but the implementation
for corresponding callbacks are missing. Fix it.
Signed-off-by: Axel Lin
---
Hi Robin,
Can you review and test this patch?
Thanks,
Axel
drivers/regulator/pfuze100-regulator.c | 3 +++
1 file changed, 3 insertions(+)
On 23 May 2014 14:51, wrote:
> From: Srinivas Kandagatla
>
> This patch adds ddrmode mask to variant structure giving more flexibility
> to the driver to support more SOCs which have different datactrl register
> layout.
>
> Without this patch datactrl register is updated with wrong ddrmode
On 05/26/2014 11:45 AM, Stephen Rothwell wrote:
Hi all,
On Fri, 23 May 2014 12:22:04 +0200 Daniel Lezcano
wrote:
clocksource: sun5i: Add support for reset controller
This commit caused a build failure on arm in linux-next today ...
Thanks Stephen.
Maxime ?
--
Hi Vincent,
I conducted test runs of ebizzy on a Power8 box which had 48 cpus.
6 cores with SMT-8 to be precise. Its a single socket box. The results
are as below.
On 05/23/2014 09:22 PM, Vincent Guittot wrote:
> Part of this patchset was previously part of the larger tasks packing patchset
>
hI,
On Saturday 24 May 2014 03:20 AM, Gregory CLEMENT wrote:
> On 23/05/2014 11:20, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Friday 16 May 2014 09:52 PM, Gregory CLEMENT wrote:
>>> The Armada 375 SoC comes with an USB2 host and device controller and
>>> an USB3 controller. The USB cluster
501 - 600 of 1404 matches
Mail list logo
