Hello Mark
Thanks for your comments. This fix does not avoid the task being
killed (which is not an error). What it does is that IF the task is
killed or we are out of memory we will exit with all the resources
properly released and no locks helds, giving the user a chance to
reload/rebind the
On May 1, 2014 12:23:27 AM GMT+01:00, Doug Anderson
wrote:
>Jonathan,
>
>On Wed, Apr 30, 2014 at 1:49 PM, Jonathan Cameron
>wrote:
>> On 30/04/14 10:26, Naveen Krishna Chatradhi wrote:
>>>
>>> Add reinit_completion() before the wait_for_completion_timeout in
>>> raw_read() call.
>>>
>>>
To do something cross-arch putting it in memory and having something point to
it is probably easiest, but again, with an in-VM boot loader the command line
rather sucks. This then becomes a matter for device tree/ACPI with all that
entails.
In that sense it would be better to do something
lacklist was not aligned.
This was because per generated vmlinux.lds it was emitted right next
to .rodata with strings etc hence could be randomly unaligned.
Fix that by ensuring a word alignment. While 4 would suffice for 32bit
arches and problem at hand, it is probably better to put 8.
| P
$ file *
linux-3.15.0-0.rc3.git1.10.fc21.i686: directory
linux-3.15.0-0.rc3.git2.1.fc21.i686: directory
linux-3.15.0-0.rc3.git3.1.fc21.i686: directory
$
$ grep -R AZX_DCAPS_CORBRP_SELF_CLEAR
linux-3.15.0-0.rc3.git3.1.fc21.i686/sound/pci/hda/hda_intel.c:
AZX_DCAPS_CORBRP_SELF_CLEAR)
On Thu, May 1, 2014 at 2:53 PM, Alexandre Courbot wrote:
> On Mon, Apr 28, 2014 at 11:10 AM, Ben Skeggs wrote:
>> On Fri, Apr 25, 2014 at 5:19 PM, Alexandre Courbot
>> wrote:
>>> nvc0_graph_ctor() would only let the graphics engine be enabled if its
>>> oclass has a proper microcode linked to
On Friday 18 April 2014 05:47 AM, Max Schwarz wrote:
> I recently noticed this problem on the Radxa Rock board. I'm not
> sure how this has ever worked on other platforms, though. I can
> only receive broadcast packets without configuring the address.
>
> Running ifconfig eth0 hw ether XYZ or
On Mon, Apr 28, 2014 at 11:10 AM, Ben Skeggs wrote:
> On Fri, Apr 25, 2014 at 5:19 PM, Alexandre Courbot
> wrote:
>> nvc0_graph_ctor() would only let the graphics engine be enabled if its
>> oclass has a proper microcode linked to it. This prevents GR from being
>> enabled at all on chips that
On Mon, Apr 28, 2014 at 8:44 PM, Thierry Reding
wrote:
> On Wed, Apr 23, 2014 at 03:11:01PM +0900, Alexandre Courbot wrote:
>> On Wed, Apr 23, 2014 at 11:07 AM, Alexandre Courbot
>> wrote:
>> > On 04/22/2014 07:40 PM, Thierry Reding wrote:
>> >>
>> >> * PGP Signed by an unknown key
>> >>
>> >>
On Thu, May 01, 2014 at 02:37:26PM +1000, Stephen Rothwell wrote:
> Hi Greg,
>
> Today's linux-next merge of the staging tree got a conflict in
> drivers/iio/adc/Kconfig between commit bbc28134e915 ("iio: adc: Nothing
> in ADC should be a bool CONFIG") from the staging.current tree and commit
>
The following changes since commit 4d0fa8a0f01272d4de33704f20303dcecdb55df1:
Merge tag 'gpio-v3.15-2' of
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio (2014-04-22
09:28:02 -0700)
are available in the git repository at:
Hi Greg,
Today's linux-next merge of the staging tree got a conflict in
drivers/iio/adc/Kconfig between commit bbc28134e915 ("iio: adc: Nothing
in ADC should be a bool CONFIG") from the staging.current tree and commit
9ef080ec0c5e ("iio: adc: Fix exynos_adc dependencies") from the staging
tree.
On Wed, Apr 30, 2014 at 06:08:44PM +0300, Dan Carpenter wrote:
> There are sometimes where we know that we are doing an strcpy() into a
> fixed length buffer. In those cases, we could verify that the strcpy()
> doesn't overflow. This patch introduces DEBUG_STRICT_SLOW_STRCPY_CHECKS
> if you want
On Wed, Apr 30, 2014 at 1:26 AM, Philipp Zabel wrote:
> Am Dienstag, den 29.04.2014, 15:44 -0500 schrieb Rob Herring:
>> On Tue, Apr 29, 2014 at 11:37 AM, Philipp Zabel
>> wrote:
>> > Add Linear Technology Corporation to the list of device tree vendor
>> > prefixes.
>> >
>> > Signed-off-by:
On 05/01/2014 02:48 AM, Guenter Roeck wrote:
> On Wed, Apr 30, 2014 at 09:14:42AM +0800, Chen Gang wrote:
>> Hello Maintainers:
>>
>> - Toolchain information:
>>
>> root@gchen:/upstream/toolchain/binutils/gas#
>>
Qemu is using /dev/random because there is no point in emptily feeding one prng
from another.
Giving the guest a seed would be highly useful, though. There are a number of
ways to do that; changing the boot protocol is probably only useful if Qemu
itself bouts the kernel as opposed to an
On Tue, 29 Apr 2014 23:11:28 +0200, Jan Kara said:
> > 5dc90cb49691755faa ("printk: enable interrupts before calling
> > console_trylock_for_printk()") I get the following warning:
> Thanks for report. Attached patch should fix the problem I hope.
> Content-Disposition: attachment;
On Thu, 1 May 2014, Srivatsa S. Bhat wrote:
>
> I tried to recall the *exact* steps that I had carried out when I first
> hit the bug. I realized that I had actually used kexec to boot the new
> kernel. I had originally booted into a 3.7.7 kernel that happens to be
> on that machine, and then
On Tue, Apr 22, 2014 at 12:47:29PM +0200, Geert Uytterhoeven wrote:
> drivers/base/regmap/regmap.c: In function
> ‘_regmap_range_multi_paged_reg_write’:
> drivers/base/regmap/regmap.c:1665: warning: ‘this_page’ may be used
> uninitialized in this function
>
> Signed-off-by: Geert Uytterhoeven
On Thu, May 01, 2014 at 12:37:58AM +0400, Alexey Khoroshilov wrote:
> w1_process_callbacks() expects to be called with dev->list_mutex held,
> but it is the fact only in w1_process(). __w1_remove_master_device()
> calls w1_process_callbacks() after it releases list_mutex.
>
> The patch fixes
On Wed, Apr 30, 2014 at 11:25:00AM -0700, Mark Brown wrote:
> On Wed, Apr 30, 2014 at 09:10:12AM +0200, Richard Cochran wrote:
> > Shouldn't this go to the arm list and rmk for review, too?
>
> Is there any particular reason for including rmk? It's generally not
> helpful to spam people with
On 04/30/2014 03:05 PM, Vikas Sajjan wrote:
Hi Pankaj,
On Wed, Apr 30, 2014 at 10:47 AM, Pankaj Dubey wrote:
This patch modifies Exynos Power Management Unit (PMU) initialization
implementation in following way:
- Added platform_device support by registering static platform device.
- Added
On Wed, Apr 30, 2014 at 05:31:08PM +0800, Xiubo Li wrote:
> Since we cannot make sure the 'len = pair_size * num_regs' will always
> be none zero from the users, and then if 'num_regs' equals to zero by
> mistake or other reasons, the kzalloc() will return ZERO_SIZE_PTR, which
> equals to ((void
On Tue, Apr 29, 2014 at 07:18:26PM +0800, Xia Kaixu wrote:
> From: Arnd Bergmann
>
> The symbol "nuc900_ac97_data" is used by the nuc900_pcm driver,
> which may be a loadable module, so we should export it.
Applied, thanks.
signature.asc
Description: Digital signature
iovec should be reclaimed whenever caller of rw_copy_check_uvector() returns,
but it doesn't hold when failure happens right after aio_setup_vectored_rw().
Fix that in a such way to avoid hairy goto.
Signed-off-by: Leon Yu
---
fs/aio.c | 6 ++
1 file changed, 2 insertions(+), 4
On Tue, Apr 29, 2014 at 07:18:25PM +0800, Xia Kaixu wrote:
> From: Arnd Bergmann
>
> dma_addr_t may be 64 bit wide, which causes a build failure
> when doing a division on it. Here it is safe to cast to an
> u32 type, which avoids the problem.
Applied, thanks.
signature.asc
Description:
Hartley,
Yes, you raise very good points. In any case, I have added cover
letters to my submitting checklist so hopefully everything will be a
lot easier for everyone next go round.
Thanks,
Chase
On Wed, Apr 30, 2014 at 11:58 AM, Hartley Sweeten
wrote:
> On Wednesday, April 30, 2014 12:52 AM,
On Tue, Apr 29, 2014 at 07:18:24PM +0800, Xia Kaixu wrote:
> From: Arnd Bergmann
>
> This adds a missing dependency for SND_SOC_SMDK_WM8580_PCM to
> require REGMAP_I2C to be enabled, avoiding possible build
> erorrs.
Applied, thanks. As well as the Cc list thing please try to use subject
lines
On Tue, Apr 29, 2014 at 07:18:23PM +0800, Xia Kaixu wrote:
> From: Arnd Bergmann
>
> This codec requires I2C to be enabled, so any other option
> that selects it should also depend on I2C.
Applied, thanks.
signature.asc
Description: Digital signature
On Thu, May 01, 2014 at 02:16:27AM +, Austin, Brian wrote:
> Apparently not.
> I would like to come up with a better solution than making INPUT a
> requirement. I just need some time.
> In the meantime I suppose it’s OK to apply it?
Yeah. Realistically it's probably not going to ever be a
Since commit 6130f5315 ("switch vmsplice_to_user() to copy_page_to_iter()"),
rw_copy_check_uvector is used for sanity check, however, iov can be leaked if
that check failed.
So, fix it by handling this error path properly.
Signed-off-by: Leon Yu
---
fs/splice.c | 3 ++-
1 file changed, 2
We have reached the point where our mutexes are quite fine tuned
for a number of situations. This includes the use of heuristics
and optimistic spinning, based on MCS locking techniques.
Exclusive ownership of read-write semaphores are, conceptually,
just about the same as mutexes, making them
On Wed, Apr 30, 2014 at 07:59:43PM -0700, Linus Torvalds wrote:
> On Wed, Apr 30, 2014 at 7:51 PM, Al Viro wrote:
> >
> > Help with profiling is needed; the loads to watch are
> > the ones where dentry_kill() + dentry_free() are sufficiently high in
> > profiles
> > for the differences to
On Wed, Apr 30, 2014 at 7:51 PM, Al Viro wrote:
>
> Help with profiling is needed; the loads to watch are
> the ones where dentry_kill() + dentry_free() are sufficiently high in profiles
> for the differences to matter. Any takers?
I really hope there are no such loads, my "lock/unlock
On Wed, Apr 30, 2014 at 05:18:23PM -0700, Linus Torvalds wrote:
> and then suddenly it looks like we have a common exit sequence from
> that dentry_kill() function, no?
>
> (The earlier "unlock_on_failure" exit case is altogether a different case).
>
> I dunno. Maybe not a big deal, but one
[[ This patch depends on the previously posted:
[PATCH] SCHED: remove proliferation of wait_on_bit action functions.
This version is much smaller then the previous and better tested.
I'm hoping it too will go though the scheduler tree and the the
NFS changes won't cause too many
[[ get_maintainer.pl suggested 61 email address for this patch.
I've trimmed that list somewhat. Hope I didn't miss anyone
important...
I'm hoping it will go in through the scheduler tree, but would
particularly like an Acked-by for the fscache parts. Other acks
welcome.
]]
The
This patch adds 4 levels of translation tables implementation for both
HYP and stage2.
Both symmetric and asymmetric configurations for page size and translation
levels are are validated on Fast Models:
1) 4KB + 3 levels guest on 4KB + 3 levels host
2) 4KB + 4 levels guest on 4KB + 3
This patch implements 4 levels of translation tables since 3 levels
of page tables with 4KB pages cannot support 40-bit physical address
space described in [1] due to the following issue.
It is a restriction that kernel logical memory map with 4KB + 3 levels
This patch adds memory layout and translation lookup information
about 48-bit address space with 4K pages. The description is based
on 4 levels of translation tables.
Cc: Catalin Marinas
Cc: Steve Capper
Signed-off-by: Jungseok Lee
Reviewed-by: Sungjinn Chung
---
This patch adds hardware definition and types for 4 levels of
translation tables with 4KB pages.
Cc: Catalin Marinas
Cc: Steve Capper
Signed-off-by: Jungseok Lee
Reviewed-by: Sungjinn Chung
---
arch/arm64/include/asm/pgtable-4level-hwdef.h | 50 +
This patch adds virtual address space size and a level of translation
tables to kernel configuration. It facilicates introduction of
different MMU options, such as 4KB + 4 levels, 16KB + 4 levels and
64KB + 3 levels, easily.
The idea is based on the discussion with Catalin Marinas:
This patch fixed the following checkpatch complaint as using pr_*
instead of printk.
WARNING: printk() should include KERN_ facility level
Cc: Catalin Marinas
Signed-off-by: Jungseok Lee
Reviewed-by: Sungjinn Chung
---
arch/arm64/kernel/traps.c |8
1 file changed, 4
Hi All,
This v5 patchset supports 4 levels of tranlsation tables for ARM64.
Firstly, the patchset introduces virtual address space size and
translation level options as taking account into the comment from
Catalin Marinas:
http://www.spinics.net/linux/lists/arm-kernel/msg319552.html
Then, it
On Apr 30, 2014, at 8:54 PM, Austin, Brian wrote:
>
>
>> On Apr 30, 2014, at 20:31, "Mark Brown" wrote:
>>
>>> On Tue, Apr 29, 2014 at 09:31:30PM -0500, Brian Austin wrote:
>>>
>>> I assume you mean the CS42L52 instead of the L51. INPUT is used for a BEEP
>>> Generator but when I disable
> On Apr 30, 2014, at 20:31, "Mark Brown" wrote:
>
>> On Tue, Apr 29, 2014 at 09:31:30PM -0500, Brian Austin wrote:
>>
>> I assume you mean the CS42L52 instead of the L51. INPUT is used for a BEEP
>> Generator but when I disable CONFIG_INPUT I do not get an error. Is there
>> any information
Hi Rafael,
Today's linux-next merge of the pm tree got a conflict in
arch/mips/loongson/lemote-2f/clock.c between commit a68ce6507a45
("MIPS/loongson2_cpufreq: Fix CPU clock rate setting") from the mips tree
and commit 4966ee4037fe ("mips: lemote 2f: Use cpufreq_for_each_entry
macro for
On Wed, Apr 30, 2014 at 01:52:35PM -0700, Andy Lutomirski wrote:
>
> 1. It simply doesn't work on my system. In particular, it never returns
> entropy. It just blocks forever.
Why? Is this a bug in qemu? The host OS? The guest OS? It is qemu
trying to use /dev/random instead of
On Fri, Apr 25 2014, Joonsoo Kim wrote:
> Subject: [PATCH] mm-compaction-cleanup-isolate_freepages-fix3
>
> What I did here is taking end_pfn out of the loop and considering zone
> boundary once. After then, we can just set previous pfn to end_pfn on
> every iteration to move scanning window. With
On Wed, Apr 30, 2014 at 12:36:11PM +0200, Ricardo Ribalda Delgado wrote:
> Since "786235eeba0e1e85e5cbbb9f97d1087ad03dfa21 kthread:
> make kthread_create() killable" kthread_run can be killed by the user,
> ie, by killing modprobe.
> - flush_kthread_worker(>kworker);
> -
On Tue, Apr 29, 2014 at 09:31:30PM -0500, Brian Austin wrote:
> I assume you mean the CS42L52 instead of the L51. INPUT is used for a BEEP
> Generator but when I disable CONFIG_INPUT I do not get an error. Is there
> any information available on what the error is?
I suspect it's ASoC built in
On Tue, Apr 29, 2014 at 07:18:22PM +0800, Xia Kaixu wrote:
> From: Arnd Bergmann
>
> Building ARM randconfig got into a situation where CONFIG_INPUT
> is turned off and SND_SOC_ALL_CODECS is turned on, which failed
> for two codecs trying to use the input subsystem. Some other
Applied, but...
On Wed, Apr 30, 2014 at 11:56:08AM -0700, Doug Anderson wrote:
> I cornered Rob and Mark Rutland a little bit about this at ELC today
> (sorry!). Neither of them was a huge ran of adding a pseudo device.
> Rob suggested that Mark Brown might be the best person to give
> direction here. Mark
On Wed, Apr 30, 2014 at 11:06:29AM +0200, Arnd Bergmann wrote:
> 49101a25acd69c "ASoC: cq93vc: Remove the set_cache_io() entirely from
> ASoC probe" introduced the cq93vc_get_regmap function that has an
> obvious build error referring to the 'codec' variable that is not
> declared anywhere"
On Wed, Apr 30, 2014 at 09:10:12AM +0200, Richard Cochran wrote:
> Shouldn't this go to the arm list and rmk for review, too?
Is there any particular reason for including rmk? It's generally not
helpful to spam people with serieses without reason, we all get quite a
lot of mail already...
On Wed, Apr 30, 2014 at 11:06:09AM -0700, Maxime Ripard wrote:
> On Tue, Apr 29, 2014 at 11:37:58AM -0700, Mark Brown wrote:
> > Why can we not handle this by using sysfs to bind spidev to the
> > device?
> I just tried it, and apparently, you can't really use this, since spi
> devices are
Signed-off-by: Boris BREZILLON
---
drivers/of/of_mtd.c| 35 +++
include/linux/of_mtd.h | 6 ++
2 files changed, 41 insertions(+)
diff --git a/drivers/of/of_mtd.c b/drivers/of/of_mtd.c
index a862c08..f941a5e 100644
--- a/drivers/of/of_mtd.c
+++
This patch introduce a new layer in the NAND framework to support both HW
and SW randomizers.
This randomization is required on some MLC/TLC NAND chips which do not
support large islands of same patterns.
The randomizer layer defines a nand_rnd_ctrl struct which is intended to
be used by NAND
Add support for the HW randomizer available in the sunxi IP.
Signed-off-by: Boris BREZILLON
---
drivers/mtd/nand/sunxi_nand.c | 511 +-
1 file changed, 500 insertions(+), 11 deletions(-)
diff --git a/drivers/mtd/nand/sunxi_nand.c
Hello,
This series is a proposal to add support for randomizers (either software
or hardware) to NAND flash controller drivers.
The last patch is the sunxi HW randomizer implementation and is just given
as an example (it won't apply on the MTD tree, because it depends on other
stuff not yet
On Wednesday, April 30, 2014 10:12 PM, Catalin Marinas wrote:
> On Wed, Apr 30, 2014 at 07:41:40AM +0100, Jungseok Lee wrote:
> > On Tuesday, April 29, 2014 11:48 PM, Catalin Marinas wrote:
> > > On Tue, Apr 29, 2014 at 05:59:27AM +0100, Jungseok Lee wrote:
> > > > ---
3.12.15-rt26-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: "Steven Rostedt (Red Hat)"
---
localversion-rt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/localversion-rt b/localversion-rt
index c5b71f9..02556f4 100644
3.12.15-rt26-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: Steven Rostedt
The changes to move the migrate_disable() down in the trylocks()
caused race conditions to appear in the cpu hotplug code. The
migrate disables must be done before
3.12.15-rt26-rc1 stable review patch.
If anyone has any objections, please let me know.
--
From: "Steven Rostedt (Red Hat)"
The patch "net: gianfar: do not try to cleanup TX packets if they are
not done" for 3.12-rt left out the return value for gfar_clean_tx_ring().
This would
Dear RT Folks,
The 3.12-rt kernel is entering the stable phase. But instead of
just pulling the last development version into stable, there
were a few bugs that needed to be fixed first. The 3.12.15-rt26
will go through an rc phase before it is officially released as
stable.
This is the RT
From: Rob Herring
Commit d2fd6810a823bcd (tty/serial: convert 8250 to generic earlycon)
removed setup_early_serial8250_console, but there are still 2 callers
in:
arch/mips/mti-malta/malta-init.c
drivers/firmware/pcdp.c
Add back the function implemented as a wrapper to setup_earlycon.
From: Rob Herring
Commit 9aac5887595 (tty/serial: add generic serial earlycon) moved
console option parsing from 8250_early.c and converted to kstrto*
functions from simple_strtoul along the way. However, kstrto* functions
are not equivalent in that they do not allow non-convertible characters
Synchronous memory compaction can be very expensive: it can iterate an enormous
amount of memory without aborting and it can wait on page locks and writeback
to
complete if a pageblock cannot be defragmented.
Unfortunately, it's too expensive for pagefault for transparent hugepages and
it's
Memory migration uses a callback defined by the caller to determine how to
allocate destination pages. When migration fails for a source page, however,
it
frees the destination page back to the system.
This patch adds a memory migration callback defined by the caller to determine
how to free
Memory compaction works by having a "freeing scanner" scan from one end of a
zone which isolates pages as migration targets while another "migrating
scanner"
scans from the other end of the same zone which isolates pages for migration.
When page migration fails for an isolated page, the target
于 4/25/14, 0:20, Peter Zijlstra 写道:
OK, this series is a lot saner, with the exception of 3/8 and
dependents.
I do still worry a bit for loosing the longer term view for the big
domains though. Sadly I don't have any really big machines.
I think the entire series is equivalent to setting
On Wed, 30 Apr 2014 18:29:48 -0400
Sasha Levin wrote:
> Signed-off-by: Steven Rostedt
>
> Hi Steven,
>
> It seems that this patch is causing the following for me on -next kernel:
Really? This patch has been in the kernel since 3.12. Why would it
break something in linux-next. Perhaps
The HwSpinlock core allows requesting either a specific lock or an
available normal lock. The specific locks are usually reserved during
board init time, while the normal available locks are intended to be
assigned at runtime.
The HwSpinlock core has been enhanced to:
1. allow the platform
HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
base support for parsing the DT nodes, and removes the code
dealing with the traditional platform device instantiation.
Signed-off-by: Suman Anna
[t...@atomide.com: ack for
The various hwspin_lock_request* interfaces return a NULL pointer
on error, or a valid hwlock pointer on success. It is standard
practice to pass the error value back to the consumers on failure
cases, so change the functions to return an equivalent ERR_PTR()
value instead of NULL. The regular
Changed the return statements to return an ERR_PTR instead of NULL
in case of an error. This patch helps with deferred probing of any
client users if the corresponding hwspinlock bank is not yet registered
with the hwspinlock core.
Signed-off-by: Suman Anna
---
TODO: Collapse into Patch4,
Retrieve the number of reserved locks for OMAP by using the
of_hwspin_lock_get_num_reserved_locks() OF helper function
provided by the hwspinlock core. The range sanity check will
be performed by the hwspinlock core during the registration.
Signed-off-by: Suman Anna
---
The HwSpinlock core allows requesting either a specific lock or
an available normal lock. The specific locks are usually reserved
during board init time, while the normal available locks are
intended to be assigned at runtime.
This patch prepares the hwspinlock core to support this concept
of
The property 'hwlock-reserved-locks' will be used to represent
the number of locks to be reserved for clients that would need
to request/operate on specific locks. A new OF helper function,
of_hwspin_lock_get_num_reserved_locks(), is added to minimize
duplication in different platform
HwSpinlocks are supported on AM33xx, AM43xx and DRA7xx SoC
device families as well. The IPs are identical to that of
OMAP4/OMAP5, except for the number of locks.
Add a depends on to the above family of SoCs to enable the
build support for OMAP hwspinlock driver for any of the above
SoC configs.
The number of hwspinlocks are determined based on the value read
from the IP block's SYSSTATUS register. However, the module may
not be enabled and clocked, and the read may result in a bus error.
This particular issue is seen rather easily on AM33XX, since the
module wakeup is software
Rearrange the code between hwspin_lock_unregister() and the underlying
hwspin_lock_unregister_single() functions so that the semantics are
similar to the _register_ functions. This change prepares the hwspinlock
driver core to support unregistration of reserved locks better.
Signed-off-by: Suman
The HwSpinlock core requires a base id for registering a bank
of hwspinlocks. This base id needs to be unique across multiple
IP instances of a hwspinlock device, so that each hwlock can be
represented uniquely in a system.
Support has been added to represent this in DT through a common
property
HwSpinlock IP is present only on OMAP4 and other newer SoCs,
which are all device-tree boot only. This patch adds the
DT bindings information for OMAP hwspinlock module.
Cc: Rob Herring
Signed-off-by: Suman Anna
---
.../devicetree/bindings/hwlock/omap-hwspinlock.txt | 24 ++
The hwspinlock_device structure is used for registering a bank of
locks with the driver core. The structure already contains the
necessary members to identify the bank of locks. The core does not
maintain the hwspinlock_devices itself, but maintains only a radix
tree for all the registered locks.
This patch adds the generic common bindings used to represent
a hwlock device and use/request locks in a device-tree build.
All the platform-specific hwlock driver implementations need the
number of locks and associated base id for registering the locks
present within the device with the driver
Hi Ohad,
This is a refresh/update of the hwspinlock dt support series. The
series is rebased onto v3.15-rc3, and adds 8 new patches (RFC) to
handle various discussion points arised on v4.
Following are the main changes in v5:
- Base DT patches (Patches 1 to 7, except for 4) are identical to v4.
This patch adds three new OF helper functions to use/request
locks from a hwspinlock device instantiated through a
device-tree blob.
1. The of_hwspin_lock_get_num_locks() is a common helper
function to read the common 'hwlock-num-locks' property.
2. The of_hwspin_lock_simple_xlate() is a
On Mon, 2014-04-28 at 19:06 +0200, Denys Vlasenko wrote:
> Otherwise, instructions such as cmpxchg and div will be mishandled.
>
> Signed-off-by: Denys Vlasenko
> CC: Jim Keniston
> CC: Masami Hiramatsu
> CC: Srikar Dronamraju
> CC: Ingo Molnar
> CC: Oleg Nesterov
> ---
>
On Wed, Apr 30, 2014 at 4:43 PM, Al Viro wrote:
>
> OK, done and force-pushed. Should propagate in a few...
That made it more obvious how the DCACHE_MAY_FREE case ends up
working. And in particular, mind rewriting this:
if (dentry->d_flags & DCACHE_MAY_FREE) {
spin_unlock(>d_lock);
On Mon, 2014-04-28 at 19:06 +0200, Denys Vlasenko wrote:
> It is possible to replace rip-relative addressing mode
> with addressing mode of the same length: (reg+disp32).
> This eliminates the need to fix up immediate
> and correct for changing instruction length.
>
> v2: Rebased on top of Oleg's
On 04/30/2014 06:59 PM, Luis R. Rodriguez wrote:
> On Wed, Apr 30, 2014 at 04:04:34PM -0400, Vlad Yasevich wrote:
>> On 04/22/2014 03:43 PM, Luis R. Rodriguez wrote:
>>> diff --git a/net/bridge/br_if.c b/net/bridge/br_if.c
>>> index 54d207d..dcd9378 100644
>>> --- a/net/bridge/br_if.c
>>> +++
On Mon, 2014-04-28 at 12:05 +0530, Srikar Dronamraju wrote:
> * Oleg Nesterov [2014-04-27 18:52:27]:
>
> > default_pre_xol_op() passes >utask->autask to riprel_pre_xol()
> > and this is just ugly because it still needs to load current->utask to
> > read ->vaddr.
> >
> > Remove this argument,
On Mon, 2014-04-28 at 12:06 +0530, Srikar Dronamraju wrote:
> * Oleg Nesterov [2014-04-27 18:52:30]:
>
> > Ignoring the "correction" logic riprel_pre_xol() and riprel_post_xol()
> > are very similar but look quite differently.
> >
> > 1. Add the "UPROBE_FIX_RIP_AX | UPROBE_FIX_RIP_CX" check at
On Mon, 2014-04-28 at 12:04 +0530, Srikar Dronamraju wrote:
> * Oleg Nesterov [2014-04-27 18:52:23]:
>
> > handle_riprel_insn(), pre_xol_rip_insn() and handle_riprel_post_xol()
> > look confusing and inconsistent. Rename them into riprel_analyze(),
> > riprel_pre_xol(), and riprel_post_xol()
On Wed, Apr 30, 2014 at 02:33:21PM -0600, Bjorn Helgaas wrote:
> dma_declare_coherent_memory() takes two addresses for a region of memory: a
> "bus_addr" and a "device_addr". I think the intent is that "bus_addr" is
> the physical address a *CPU* would use to access the region, and
>
On Mon, Apr 14, 2014 at 03:28:35PM +0200, Alexander Gordeev wrote:
> There are no users of pci_enable_msi_block() function have
> left. Obsolete it in favor of pci_enable_msi_range() and
> pci_enable_msi_exact() functions.
I mistakenly assumed this would have to wait because I thought there were
On Wed, Apr 30, 2014 at 4:44 PM, Andy Lutomirski wrote:
> On Tue, Apr 29, 2014 at 9:52 PM, H. Peter Anvin wrote:
>> On 04/29/2014 04:39 PM, Andi Kleen wrote:
Case 3 is annoying. If nothing tries to change the user gs base, then
everything is okay because the user gs base and the
On Tue, Apr 29, 2014 at 9:52 PM, H. Peter Anvin wrote:
> On 04/29/2014 04:39 PM, Andi Kleen wrote:
>>> Case 3 is annoying. If nothing tries to change the user gs base, then
>>> everything is okay because the user gs base and the kernel gs bases are
>>> equal. But if something does try to change
On Wed, Apr 30, 2014 at 04:14:14PM -0700, Linus Torvalds wrote:
> On Wed, Apr 30, 2014 at 4:04 PM, Linus Torvalds
> wrote:
> >
> > Let me go talk to the paravirt people. Maybe they don't need this, and
> > I don't know exactly *how* they use that lock pointer after the unlock
> > in the "kick
1 - 100 of 1492 matches
Mail list logo
