* Some comments became stale. Updated.
* percpu_ref_tryget() unnecessarily initializes @ret. Removed.
* A blank line removed from percpu_ref_kill_rcu().
* Explicit function name in a WARN format string replaced with __func__.
* WARN_ON() in percpu_ref_reinit() converted to WARN_ON_ONCE().
Hello,
Over the past several months, percpu_ref grew use cases where it's
used as a persistent on/off switch which may be cycled multiple times
using percpu_ref_reinit(). One of such use cases is blk-mq's
mq_usage_counter which tracks the number of in-flight commands and is
used to drain them.
percpu_ref will be restructured so that percpu/atomic mode switching
and reference killing are dedoupled. In preparation, do the following
renames.
* percpu_ref->confirm_kill -> percpu_ref->confirm_switch
* __PERCPU_REF_DEAD -> __PERCPU_REF_ATOMIC
* __percpu_ref_alive()
percpu_ref is gonna go through restructuring. Move
percpu_ref_reinit() after percpu_ref_kill_and_confirm(). This will
make later changes easier to follow and result in cleaner
organization.
Signed-off-by: Tejun Heo
Cc: Kent Overstreet
---
include/linux/percpu-refcount.h | 2 +-
* Ingo Molnar wrote:
> * Ingo Molnar wrote:
>
> >
> > * Linus Torvalds wrote:
> >
> > > On Fri, Sep 19, 2014 at 3:40 AM, Ingo Molnar wrote:
> > > >
> > > > Please pull the latest x86-urgent-for-linus git tree from:
> > >
> > > I only just noticed, but this pull request causes my Sony
On Tue, Sep 23, 2014 at 01:56:48AM -0400, Tejun Heo wrote:
> On Tue, Sep 23, 2014 at 07:55:54AM +0200, Christoph Hellwig wrote:
> > Jens,
> >
> > can we simply get these commits reverted from now if there's no better
> > fix? I'd hate to have this boot stall in the first kernel with blk-mq
> >
percpu_ref will be restructured so that percpu/atomic mode switching
and reference killing are dedoupled. In preparation, add
PCPU_REF_DEAD and PCPU_REF_ATOMIC_DEAD which is OR of ATOMIC and DEAD.
For now, ATOMIC and DEAD are changed together and all PCPU_REF_ATOMIC
uses are converted to
On Mon, Sep 22, 2014 at 02:40:15PM -0400, Douglas Gilbert wrote:
> With these patches applied (actually a resync an hour
> ago with the for-linus tree which includes them), the
> freeze-during-boot-up problem that I have been seeing
> with an old SATA boot disk (perhaps 1.5 Gbps) for
> the last
On Tue, Sep 23, 2014 at 07:55:54AM +0200, Christoph Hellwig wrote:
> Jens,
>
> can we simply get these commits reverted from now if there's no better
> fix? I'd hate to have this boot stall in the first kernel with blk-mq
> support for scsi.
Patches going out right now.
Thanks.
--
tejun
--
Currently, a percpu_ref which is initialized with
PERPCU_REF_INIT_ATOMIC or switched to atomic mode via
switch_to_atomic() automatically reverts to percpu mode on the first
percpu_ref_reinit(). This makes the atomic mode difficult to use for
cases where a percpu_ref is used as a persistent on/off
percpu_ref has treated the dropping of the base reference and
switching to atomic mode as an integral operation; however, there's
nothing inherent tying the two together.
The use cases for percpu_ref have been expanding continuously. While
the current init/kill/reinit/exit model can cover a lot,
Jens,
can we simply get these commits reverted from now if there's no better
fix? I'd hate to have this boot stall in the first kernel with blk-mq
support for scsi.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
With the recent addition of percpu_ref_reinit(), percpu_ref now can be
used as a persistent switch which can be turned on and off repeatedly
where turning off maps to killing the ref and waiting for it to drain;
however, there currently isn't a way to initialize a percpu_ref in its
off (killed and
percpu_ref uses pcpu_ prefix for internal stuff and percpu_ for
externally visible ones. This is the same convention used in the
percpu allocator implementation. It works fine there but percpu_ref
doesn't have too much internal-only stuff and scattered usages of
pcpu_ prefix are confusing than
percpu_ref has treated the dropping of the base reference and
switching to atomic mode as an integral operation; however, there's
nothing inherent tying the two together.
The use cases for percpu_ref have been expanding continuously. While
the current init/kill/reinit/exit model can cover a lot,
Be similar with commit (ata: Disabling the async PM for JMicron chip 363/361),
Barto found the similar issue for JMicron chip 368, that 363/368 has no
parent-children relationship, but they have the power dependency.
So here we can exclude the JMicron chips out of pm_async method directly,
to
On Tue, Sep 23, 2014 at 03:40:58PM +1000, NeilBrown wrote:
> > Oh, I meant the buffer seqfile read op writes to, so it depends on the
> > fact that the allocation is only on the first read? That seems
> > extremely brittle to me, especially for an issue which tends to be
> > difficult to
On 9/22/2014 8:40 PM, Joe Perches wrote:
> No caller or macro uses the return value so make it void.
>
> Signed-off-by: Joe Perches
> ---
> This change is associated to a desire to eventually
> change printk to return void.
>
> drivers/net/ethernet/mellanox/mlx4/en_main.c | 17
On 09/17/2014 09:48 PM, Toshi Kani wrote:
This patch sets WT to the PA7 slot in the PAT MSR when the processor
is not affected by the PAT errata. The PA7 slot is chosen to further
minimize the risk of using the PAT bit as the PA3 slot is UC and is
not currently used.
The following Intel
That would be my guess, too.
On September 22, 2014 10:37:11 PM PDT, Ingo Molnar wrote:
>
>* Ingo Molnar wrote:
>
>>
>> * Linus Torvalds wrote:
>>
>> > On Fri, Sep 19, 2014 at 3:40 AM, Ingo Molnar
>wrote:
>> > >
>> > > Please pull the latest x86-urgent-for-linus git tree from:
>> >
>> > I
* Stephen Rothwell wrote:
> Hi Josh,
>
> Today's linux-next merge of the tiny tree got conflicts in
> arch/x86/kernel/process_32.c and arch/x86/kernel/process_64.c between
> commits dc56c0f9b870 ("x86, fpu: Shift "fpu_counter = 0" from
> copy_thread() to arch_dup_task_struct()") and
On Tue, 23 Sep 2014 00:55:49 -0400 Tejun Heo wrote:
> Hello, Neil.
>
> On Tue, Sep 23, 2014 at 02:46:50PM +1000, NeilBrown wrote:
> > seqfile is only safe for reads. sysfs via kernfs uses seq_read(), so there
> > is only a single allocation on the first read.
> >
> > It doesn't really related
> Sorry for later response due to sickness. I can't write this patch in
> time. Sorry again. I will test it soon.
Oh, get well soon! Please say so next time, so I know.
signature.asc
Description: Digital signature
* Ingo Molnar wrote:
>
> * Linus Torvalds wrote:
>
> > On Fri, Sep 19, 2014 at 3:40 AM, Ingo Molnar wrote:
> > >
> > > Please pull the latest x86-urgent-for-linus git tree from:
> >
> > I only just noticed, but this pull request causes my Sony Vaio
> > laptop to immediately reboot at
* Linus Torvalds wrote:
> On Fri, Sep 19, 2014 at 3:40 AM, Ingo Molnar wrote:
> >
> > Please pull the latest x86-urgent-for-linus git tree from:
>
> I only just noticed, but this pull request causes my Sony Vaio
> laptop to immediately reboot at startup.
>
> I'm assuming it's one of the efi
Hi,
any chance to have this in 3.18?
Juergen
On 09/12/2014 12:35 PM, Juergen Gross wrote:
The x86 architecture offers via the PAT (Page Attribute Table) a way to
specify different caching modes in page table entries. The PAT MSR contains
8 entries each specifying one of 6 possible cache
Hi Chao,
I fixed that. :)
Thanks,
On Mon, Sep 22, 2014 at 05:22:27PM +0800, Chao Yu wrote:
> > -Original Message-
> > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > Sent: Monday, September 15, 2014 6:14 AM
> > To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> >
On 06/03/2014 09:26 PM, Davidlohr Bueso wrote:
> On Fri, 2014-05-02 at 15:16 +0200, Michael Kerrisk (man-pages) wrote:
>> Hi Manfred,
>>
>> On Mon, Apr 21, 2014 at 4:26 PM, Manfred Spraul
>> wrote:
>>> Hi all,
>>>
>>> the increase of SHMMAX/SHMALL is now a 4 patch series.
>>> I don't have ideas
* Paul E. McKenney wrote:
> Hello, Ingo,
>
> The changes in this series include:
>
> 1.Update RCU documentation. These were posted to LKML at
> https://lkml.org/lkml/2014/8/28/378.
>
> 2.Miscellaneous fixes. These were posted to LKML at
>
On Fri, Sep 19, 2014 at 3:40 AM, Ingo Molnar wrote:
>
> Please pull the latest x86-urgent-for-linus git tree from:
I only just noticed, but this pull request causes my Sony Vaio laptop
to immediately reboot at startup.
I'm assuming it's one of the efi changes, but I'm bisecting now to say
2014-09-22 22:03 GMT-07:00 Olof Johansson :
> On Fri, Sep 19, 2014 at 11:17:11AM -0700, Florian Fainelli wrote:
>> Hi all,
>>
>> As some of you may have seen in the news, Broadcom has recently stopped
>> its mobile SoC activities. Upstream support for Broadcom's Mobile SoCs
>> was an effort
On 09/23/2014 04:44 AM, Chanwoo Choi wrote:
On 09/22/2014 06:51 PM, George Cherian wrote:
On 09/22/2014 01:37 PM, Chanwoo Choi wrote:
Hi George,
This patch removes 'gpio_active_low' field of struct gpio_extcon_data.
But, include/linux/extcon-gpio.h has the description of 'gpio_active_low'
Hello:
I am facing an issue wherein kernel 3.17 crashes while loading IPoIB module. I
guess the issue discussed in this thread
(https://www.mail-archive.com/linux-rdma@vger.kernel.org/msg20963.html) is
similar.
We were able to reproduce the issue with RC6 also. Here are the steps I
followed:
Hi Arnd,
On Mon, 22 Sep 2014 21:45:40 +0200
Arnd Bergmann wrote:
> On Monday 22 September 2014 21:37:55 Boris BREZILLON wrote:
> > dma_mask and dma_parms are already inherited from the parent device but
> > dma_coherent_mask was left uninitialized (set to zero thanks to kzalloc).
> > Set
On Fri, Sep 19, 2014 at 11:17:11AM -0700, Florian Fainelli wrote:
> Hi all,
>
> As some of you may have seen in the news, Broadcom has recently stopped
> its mobile SoC activities. Upstream support for Broadcom's Mobile SoCs
> was an effort initially started by Christian Daudt and his team, and
On 09/22/2014 07:27 PM, Zefan Li wrote:
From: Zefan Li
This is the start of the stable review cycle for the 3.4.104 release.
There are 45 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses
Hi Josh,
After merging the tiny tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
mm/built-in.o: In function `.isolate_migratepages_range':
(.text+0x2fbd8): undefined reference to `.balloon_page_isolate'
mm/built-in.o: In function `.putback_movable_pages':
On Mon, Sep 22, 2014 at 02:17:33PM -0700, Andrew Morton wrote:
> On Mon, 22 Sep 2014 09:03:11 +0900 Minchan Kim wrote:
>
> > Some zram usecase could want lower fullness than default 80 to
> > avoid unnecessary swapout-and-fail-recover overhead.
> >
> > A typical example is that mutliple swap
Hello, Neil.
On Tue, Sep 23, 2014 at 02:46:50PM +1000, NeilBrown wrote:
> seqfile is only safe for reads. sysfs via kernfs uses seq_read(), so there
> is only a single allocation on the first read.
>
> It doesn't really related to fixing writes, except to point out that only
> writes need to be
Hi Li,
At Tue, 23 Sep 2014 10:27:39 +0800,
Zefan Li wrote:
>
> From: Zefan Li
>
> This is the start of the stable review cycle for the 3.4.104 release.
> There are 45 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied,
On Mon, Sep 22, 2014 at 02:11:18PM -0700, Andrew Morton wrote:
> On Mon, 22 Sep 2014 09:03:10 +0900 Minchan Kim wrote:
>
> > This patch implement SWAP_FULL handler in zram so that VM can
> > know whether zram is full or not and use it to stop anonymous
> > page reclaim.
> >
> > How to judge
Previously, f2fs tries to reorganize the dirty nat entries into multiple sets
according to its nid ranges. This can improve the flushing nat pages, however,
if there are a lot of cached nat entries, it becomes a bottleneck.
This patch introduces a new set management flow by removing dirty nat
This patch introduces FITRIM in f2fs_ioctl.
In this case, f2fs will issue small discards and prefree discards as many as
possible for the given area.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/checkpoint.c| 4 +-
fs/f2fs/f2fs.h | 9 +++-
fs/f2fs/file.c | 29
This patch add a new data structure to control checkpoint parameters.
Currently, it presents the reason of checkpoint such as is_umount and normal
sync.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/checkpoint.c| 16
fs/f2fs/f2fs.h | 11 ++-
fs/f2fs/gc.c
On Mon, Sep 22, 2014 at 05:20:19PM +0800, Chao Yu wrote:
> > -Original Message-
> > From: Huang Ying [mailto:ying.hu...@intel.com]
> > Sent: Monday, September 22, 2014 3:39 PM
> > To: Chao Yu
> > Cc: 'Jaegeuk Kim'; linux-kernel@vger.kernel.org;
> > linux-fsde...@vger.kernel.org;
> >
On 09/23/14 12:18, Greg KH wrote:
> On Tue, Sep 23, 2014 at 10:57:09AM +0800, Hui Zhu wrote:
>> The cause of this issue is when free memroy size is low and a lot of task is
>> trying to shrink the memory, the task that is killed by lowmemkiller cannot
>> get
>> CPU to exit itself.
>>
>> Fix
From: Behan Webster
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by:
From: Behan Webster
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by:
(2014/09/17 16:17), Wanpeng Li wrote:
> BUG: unable to handle kernel NULL pointer dereference at 0004
> IP: [..] find_busiest_group
> PGD 5a9d5067 PUD 13067 PMD 0
> Oops: [#3] SMP
> [...]
> Call Trace:
> load_balance
> ? _raw_spin_unlock_irqrestore
> idle_balance
> __schedule
>
Hi Chao,
On Mon, Sep 22, 2014 at 10:36:25AM +0800, Chao Yu wrote:
> Hi Jaegeuk,
>
> > -Original Message-
> > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > Sent: Monday, September 15, 2014 6:14 AM
> > To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> >
From: Behan Webster
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by:
From: Vinícius Tinti
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch instead allocates the appropriate amount of
memory using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
From: Jan-Simon Möller
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
On Tue, 23 Sep 2014 00:18:17 -0400 Tejun Heo wrote:
> On Tue, Sep 23, 2014 at 02:06:33PM +1000, NeilBrown wrote:
> ...
> > Note that reads from a sysfs file are already safe due to the use for
> > seqfile. The first read will allocate a buffer (m->buf) which will
> > be used for all subsequent
From: Behan Webster
Add a macro which replaces the use of a Variable Length Array In Struct (VLAIS)
with a C99 compliant equivalent. This macro instead allocates the appropriate
amount of memory using an char array.
The new code can be compiled with both gcc and clang.
struct shash_desc
From: Jan-Simon Möller
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
On Mon, Sep 22, 2014 at 01:45:22PM -0700, Andrew Morton wrote:
> On Mon, 22 Sep 2014 09:03:08 +0900 Minchan Kim wrote:
>
> > Now, swap leans on !p->highest_bit to indicate a swap is full.
> > It works well for normal swap because every slot on swap device
> > is used up when the swap is full but
From: Jan-Simon Möller
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
From: Jan-Simon Möller
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Hi Andrew,
On Mon, Sep 22, 2014 at 01:41:09PM -0700, Andrew Morton wrote:
> On Mon, 22 Sep 2014 09:03:07 +0900 Minchan Kim wrote:
>
> > Currently, swap_slot_free_notify is used for zram to free
> > duplicated copy page for memory efficiency when it knows
> > there is no reference to the swap
From: Behan Webster
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by:
From: Behan Webster
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. These patches allocate the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
There are places in the kernel whose maintainers have previously
From: Jan-Simon Möller
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
From: Behan Webster
Replaced the use of a Variable Length Array In Struct (VLAIS) with a C99
compliant equivalent. This patch allocates the appropriate amount of memory
using a char array using the SHASH_DESC_ON_STACK macro.
The new code can be compiled with both gcc and clang.
Signed-off-by:
Hi Josh,
Today's linux-next merge of the tiny tree got conflicts in
arch/x86/kernel/process_32.c and arch/x86/kernel/process_64.c between
commits dc56c0f9b870 ("x86, fpu: Shift "fpu_counter = 0" from
copy_thread() to arch_dup_task_struct()") and 6f46b3aef003 ("x86:
copy_thread: Don't nullify
Hi Josh,
Today's linux-next merge of the tiny tree got a conflict in
arch/x86/kernel/cpu/common.c between commit ce4b1b16502b ("x86/smpboot:
Initialize secondary CPU only if master CPU will wait for it") from the
tip tree and commit e4a191d1e05b ("x86: Support compiling out userspace
I/O (iopl
Joe Perches writes:
> The return values are not used by callers of these functions
> so change the functions to return void.
>
> Other miscellanea:
>
> o add __printf verification to wil6210 logging functions
> No format/argument mismatches found
>
> Signed-off-by: Joe Perches
> ---
> This
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Dexuan Cui
> Sent: Tuesday, September 23, 2014 13:01 PM
> To: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; driverdev-
> de...@linuxdriverproject.org;
> On Sep 22, 2014, at 8:49 PM, Dave Jones wrote:
>
> Just got this when removing a USB memory stick.
>
> BUG: sleeping function called from invalid context at block/genhd.c:448
Fixed in for-linus, it's going out tomorrow.
--
To unsubscribe from this list: send the line "unsubscribe
On Tue, Sep 23, 2014 at 10:57:09AM +0800, Hui Zhu wrote:
> The cause of this issue is when free memroy size is low and a lot of task is
> trying to shrink the memory, the task that is killed by lowmemkiller cannot
> get
> CPU to exit itself.
>
> Fix this issue with change the scheduling policy
On Tue, Sep 23, 2014 at 02:06:33PM +1000, NeilBrown wrote:
...
> Note that reads from a sysfs file are already safe due to the use for
> seqfile. The first read will allocate a buffer (m->buf) which will
> be used for all subsequent reads.
Hmmm? How is seqfile safe? Where would the seq op
Hello, Neil.
On Tue, Sep 23, 2014 at 02:06:33PM +1000, NeilBrown wrote:
> When mdmon needs to update metadata after a device failure in an array
> there are two 'kmalloc' sources that can trigger deadlock if memory is tight
> and needs to be written to the array (which cannot be allowed until
For a write <= 128 characters, don't use kmalloc.
mdmon, part of mdadm, will sometimes need to write
to a sysfs file in order to allow writes to the array
to continue. This is important to support RAID metadata
types that the kernel doesn't know about.
It is important that this write doesn't
Several other variants of the cap11xx device exists with a varying
number of capacitance detection channels. Add support for creating
the channels dynamically.
Signed-off-by: Matt Ranostay
---
drivers/input/keyboard/cap1106.c | 64 +++-
1 file changed, 44
Changes from v1:
* Reworked various devices support to check product id for
respective device.
* Added check for invalid zero channels.
* Renamed active-high option to more clear irq-active-high
* Use regmap_update_bits() instead of regmap_write_bits()
Matt Ranostay (2):
cap1106: Add
Some applications need to use the irq-active-high push-pull option.
This allows it be enabled in the device tree child node.
Signed-off-by: Matt Ranostay
---
Documentation/devicetree/bindings/input/cap1106.txt | 4
drivers/input/keyboard/cap1106.c| 8
2 files
> -Original Message-
> From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
> ow...@vger.kernel.org] On Behalf Of Dexuan Cui
> Sent: Tuesday, September 23, 2014 2:02 AM
> To: gre...@linuxfoundation.org; linux-kernel@vger.kernel.org; driverdev-
> de...@linuxdriverproject.org;
On 09/17/2014 04:59 PM, Juergen Gross wrote:
Direct Xen to place the initial P->M table outside of the initial
mapping, as otherwise the 1G (implementation) / 2G (theoretical)
restriction on the size of the initial mapping limits the amount
of memory a domain can be handed initially.
As the
v2: I added "errno = 0;" in the ioctl()
Signed-off-by: Dexuan Cui
Reviewed-by: K. Y. Srinivasan
---
tools/hv/hv_vss_daemon.c | 28
1 file changed, 28 insertions(+)
diff --git a/tools/hv/hv_vss_daemon.c b/tools/hv/hv_vss_daemon.c
index 6a213b8..c1af658 100644
---
Dear Sir,
I am requesting for your help, to assist me in getting £42,000,000.00 to your
account. please do indicate your interest for more information's.
REPLY ( klimowi...@yahoo.com.hk )
Yours Truly,
>From Daniel Klimowicz
--
To unsubscribe from this list: send the line "unsubscribe
On 09/23/2014 10:55 AM, jinkun.hong wrote:
From: "jinkun.hong"
Any summary for rk3288 power controller?
Maybe you can say something about how rk3288 TRM described this module.
Signed-off-by: Jack Dai
Signed-off-by: Wang Caesar
Signed-off-by: jinkun.hong
---
Hans,
Do you have any more comment on this patch?
Best regards,
Fancy Fang
-Original Message-
From: Fang Chen-B47543
Sent: Wednesday, September 10, 2014 3:29 PM
To: 'Hans Verkuil'; m.che...@samsung.com; v...@zeniv.linux.org.uk
Cc: Guo Shawn-R65073; linux-me...@vger.kernel.org;
This checks that the TCE table page size is not bigger that the size of
a page we just pinned and going to put its physical address to the table.
Otherwise the hardware gets unwanted access to physical memory between
the end of the actual page and the end of the aligned up TCE page.
At the moment pnv_pci_ioda_tce_invalidate() gets the PE pointer via
container_of(tbl). Since we are going to have to add Dynamic DMA windows
and that means having 2 IOMMU tables per PE, this is not going to work.
This implements pnv_pci_ioda(1|2)_tce_invalidate as a pnv_ioda_pe callback.
This
Modern IBM POWERPC systems support multiple IOMMU tables per PE
so we need a more reliable way (compared to container_of()) to get
a PE pointer from the iommu_table struct pointer used in IOMMU functions.
At the moment IOMMU group data points to an iommu_table struct. This
introduces a
At the moment the iommu_table struct has a set_bypass() which enables/
disables DMA bypass on IODA2 PHB. This is exposed to POWERPC IOMMU code
which calls this callback when external IOMMU users such as VFIO are
about to get over a PHB.
Since the set_bypass() is not really an iommu_table function
SPAPR defines an interface to create additional DMA windows dynamically.
"Dynamically" means that the window is not allocated before the guest
even started, the guest can request it later. In practice, existing linux
guests check for the capability and if it is there, they create and map
a DMA
The cause of this issue is when free memroy size is low and a lot of task is
trying to shrink the memory, the task that is killed by lowmemkiller cannot get
CPU to exit itself.
Fix this issue with change the scheduling policy to SCHED_FIFO if a task's flag
is TIF_MEMDIE in lowmemkiller.
Normally a bitmap from the iommu_table is used to track what TCE entry
is in use. Since we are going to use iommu_table without its locks and
do xchg() instead, it becomes essential not to put bits which are not
implied in the direction flag.
Signed-off-by: Alexey Kardashevskiy
---
This defines and implements VFIO IOMMU API which lets the userspace
create and remove DMA windows.
This updates VFIO_IOMMU_SPAPR_TCE_GET_INFO to return the number of
available windows and page mask.
This adds VFIO_IOMMU_SPAPR_TCE_CREATE and VFIO_IOMMU_SPAPR_TCE_REMOVE
to allow the user space to
The previous patch introduced iommu_table_ops::exchange() callback
which effectively disabled VFIO on pseries. This implements exchange()
for pseries/lpar so VFIO can work in nested guests.
Since exchaange() callback returns an old TCE, it has to call H_GET_TCE
for every TCE being put to the
At the moment writing new TCE value to the IOMMU table fails with EBUSY
if there is a valid entry already. However PAPR specification allows
the guest to write new TCE value without clearing it first.
Another problem this patch is addressing is the use of pool locks for
external IOMMU users such
There moves locked pages accounting to helpers.
Later they will be reused for Dynamic DMA windows (DDW).
While we are here, update the comment explaining why RLIMIT_MEMLOCK
might be required to be bigger than the guest RAM.
Signed-off-by: Alexey Kardashevskiy
---
This adds missing locks in iommu_take_ownership()/
iommu_release_ownership().
This marks all pages busy in iommu_table::it_map in order to catch
errors if there is an attempt to use this table while ownership over it
is taken.
This only clears TCE content if there is no page marked busy in
This makes use of the it_page_size from the iommu_table struct
as page size can differ.
This replaces missing IOMMU_PAGE_SHIFT macro in commented debug code
as recently introduced IOMMU_PAGE_XXX macros do not include
IOMMU_PAGE_SHIFT.
Signed-off-by: Alexey Kardashevskiy
---
This adds a iommu_table_ops struct and puts pointer to it into
the iommu_table struct. This moves tce_build/tce_free/tce_get/tce_flush
callbacks from ppc_md to the new struct where they really belong to.
This adds an extra @ops parameter to iommu_init_table() to make sure
that we do not leave any
This enables PAPR defined feature called Dynamic DMA windows (DDW).
Each Partitionable Endpoint (IOMMU group) has a separate DMA window on
a PCI bus where devices are allows to perform DMA. By default there is
1 or 2GB window allocated at the host boot time and these windows are
used when an
On 09/22/2014 07:42 PM, Guenter Roeck wrote:
On 09/22/2014 07:27 PM, Zefan Li wrote:
From: Zefan Li
This is the start of the stable review cycle for the 3.4.104 release.
There are 45 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these
This is the combined patch for 3.4.104-rc1 relative to 3.4.103.
---
diff --git a/Documentation/stable_kernel_rules.txt
b/Documentation/stable_kernel_rules.txt
index b0714d8..8dfb6a5 100644
--- a/Documentation/stable_kernel_rules.txt
+++ b/Documentation/stable_kernel_rules.txt
@@ -29,6 +29,9 @@
From: "jinkun.hong"
Signed-off-by: Jack Dai
Signed-off-by: Caesar Wang
Signed-off-by: jinkun.hong
---
.../bindings/arm/rockchip/power_domain.txt | 48
1 file changed, 48 insertions(+)
create mode 100644
1 - 100 of 1818 matches
Mail list logo
