This driver parse the reboot commands like "reboot loader"
and "reboot recovery" to get a boot mode described in the
device tree , then call the corresponding write interfae
to store the boot mode in some place like special register
or ram , which can be read by the bootloader after system
reboot
Let's improve the check with -EPROBE_DEFER, otherwise
we may pass on null pointer to PTR_ERR. That causes the
static checker warning: passing zero to 'PTR_ERR'.
Reported-by: Dan Carpenter
Cc: Doug Anderson
Cc: Dan Carpenter
Signed-off-by: Shawn Lin
---
drivers/spi/spi-rockchip.c | 10 +++
add device tree bindings document for reboot-mode driver
Signed-off-by: Andy Yan
Acked-by: Rob Herring
binding
---
Changes in v6:
- fix a typo with "property"
- describe property "mask" more clear
Changes in v5:
- delete a unnecessary blank line in syscon-reboot-mode.txt
- rename mode-fastob
This driver parse the reboot commands like "reboot loader"
and "reboot recovery" to get a boot mode described in the
device tree , then call the write interfae to store the boot
mode in some place like special register or sram , which can
be read by the bootloader after system reboot, then the boot
Rockchip platform use a SYSCON mapped register store
the reboot mode magic value for bootloader to use when
system reboot. So add syscon-reboot-mode driver DT node
for rk3xxx/rk3036/rk3288 based platform
Reviewed-by: Matthias Brugger
Signed-off-by: Andy Yan
---
Changes in v6: None
Changes in v
Add syscon-reboot-mode driver DT node for rk3368 platform
Tested-by: Caesar Wang
Signed-off-by: Andy Yan
---
Changes in v6: None
Changes in v5: None
Changes in v4: None
Changes in v3:
- descirbe all reboot mode as properity instead of subnode
Changes in v2:
- make this node as a subnode of pm
Static checkers complain that we can use "tmp" without initializing it.
Signed-off-by: Dan Carpenter
diff --git a/fs/ufs/util.h b/fs/ufs/util.h
index 9541759..8aa8812 100644
--- a/fs/ufs/util.h
+++ b/fs/ufs/util.h
@@ -88,7 +88,7 @@ ufs_get_fs_npsect(struct super_block *sb, struct
ufs_super_bloc
On Tue, Mar 22, 2016 at 11:21:53AM +0100, Peter Zijlstra wrote:
> On Mon, Mar 21, 2016 at 11:16:22AM -0700, Davidlohr Bueso wrote:
>
> > +/*
> > + * Helpers for modifying the state of either the current task, or a foreign
> > + * task. Each of these calls come in both full barrier and weak flavors
> -Original Message-
> From: Colin King [mailto:colin.k...@canonical.com]
> Sent: Sunday, March 20, 2016 10:34 PM
> To: Kashyap Desai; Sumit Saxena; James Bottomley; Martin K . Petersen;
> megaraidlinux@avagotech.com; linux-s...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Subje
On Thu, 2016-03-17 at 13:29 +0100, Arnd Bergmann wrote:
> A recent change to ufshcd introduced a call to utf16s_to_utf8s,
> a function that is provided by the NLS module, so we get a link
> error when that is not present:
>
> drivers/scsi/built-in.o: In function `ufshcd_read_string_desc':
> :(.tex
On Thu, Mar 17, 2016 at 4:28 PM, Marc Zyngier wrote:
> On 17/03/16 15:13, Jon Hunter wrote:
struct irq_chip {
+ struct device *parent;
>>>
>>> Nit: Please don't call this just "parent". We have parent fields in
>>> irq_data and irq_domain structures, and they always are a pointer t
Am 22.03.2016 um 09:05 schrieb Jacek Anaszewski:
> On 03/21/2016 06:34 PM, Heiner Kallweit wrote:
>> Am 21.03.2016 um 16:35 schrieb Jacek Anaszewski:
>>> On 03/19/2016 08:11 PM, Heiner Kallweit wrote:
Am 18.03.2016 um 14:10 schrieb Jacek Anaszewski:
> On 03/17/2016 08:53 PM, Heiner Kallwei
On Thu, Mar 17, 2016 at 3:19 PM, Jon Hunter wrote:
> There are only 3 differences (not including the name) in the definitions
> of the gic_chip and gic_eoimode1_chip structures. Instead of statically
> defining the gic_eoimode1_chip structure, remove it and populate the
> eoimode1 functions dynam
Try #1 to bring the post up again. Due to the traffic, maybe my
question is ignored :(
Regards,
Mahmood
On Tue, Mar 22, 2016 at 1:09 PM, Mahmood Naderan wrote:
> Hi,
> There is a question about CPU usage limitation and I found no place
> for my question other than here.
>
> There are 32 cores
On Tuesday 22 March 2016 02:55:22 Tina Ruchandani wrote:
> Truly fixing this would
> require changing the debug print to print more than 8 digits and using
> a different specifier from %li.
Why not just change it to %lli, and a cast to s64? I don't think the
format string or the number of digits
On 22.03.2016 07:19, Rajesh Bhagat wrote:
-Original Message-
From: Mathias Nyman [mailto:mathias.ny...@intel.com]
Sent: Monday, March 21, 2016 2:46 PM
To: Rajesh Bhagat ; Mathias Nyman
; linux-...@vger.kernel.org; linux-
ker...@vger.kernel.org
Cc: gre...@linuxfoundation.org; Sriram Das
This driver will directly use cpufreq-dt driver as backend.
As there is not a generic devicetree board file(rockchip.c)
on ARM64 architecture, so remove platform_device_register_simple
in rockchip.c and add a new cpufreq driver to support Rockchip
SoCs.
Signed-off-by: Feng Xiao
---
change in v1:
Dear Markus,
sorry - missed your reply last year.
The patch seems to work.
Kind regards,
Ingo Flaschberger
On Fri, Apr 10, 2015 at 12:22 PM, Markus Pargmann wrote:
> Hi,
>
> On Mon, Mar 09, 2015 at 11:18:58AM +0100, Markus Pargmann wrote:
>> pdev->dev.platform_data should not be overwritten
On Mon, Mar 21, 2016 at 04:33:32PM -0700, Doug Anderson wrote:
> Presumably Dan would be happy if you just add this right after the dev_warn():
> rs->dma_tx.ch = NULL;
>
Yes. Thanks.
> Presumably from Dan's email it would also be wise to make sure you
> don't pass NULL to PTR_ERR, which you c
Hi Neil,
On 22/03/16 09:21, Neil Armstrong wrote:
On 03/17/2016 08:21 PM, Robin Murphy wrote:
On 17/03/16 19:00, Rob Herring wrote:
On Thu, Mar 17, 2016 at 1:06 PM, Robin Murphy wrote:
Hi Rob,
On 17/03/16 17:09, Rob Herring wrote:
That would not be an SP804 nor would the vendor be ARM in t
Hi Graeme,
On 22/03/16 11:27, Graeme Gregory wrote:
On Tue, Mar 08, 2016 at 11:29:30AM +, Julien Grall wrote:
@@ -1020,6 +1060,13 @@ gic_acpi_parse_madt_gicc(struct acpi_subtable_header
*header,
return -ENOMEM;
gic_acpi_register_redist(gicc->gicr_base_address, redi
Within the copying loop in mpi_write_sgl(), we have
if (lzeros) {
mpi_limb_t *limb1 = (void *)p - sizeof(alimb);
mpi_limb_t *limb2 = (void *)p - sizeof(alimb)
+ lzeros;
*limb1 = *limb2;
...
}
where p points past the end of alimb2 which lives on t
that is [1-7,9-14/14], go unchanged and have got a
Tested-by: Tadeusz Struk
already.
Applicable to linux-next-20160322.
Changes to v2:
- [8/14] ("lib/mpi: mpi_read_buffer(): fix buffer overflow")
+ Fix the pointer arithmetic issue found by Tadeusz Struk
Changes to v1:
- [
Currently, the endian conversion from CPU order to BE is open coded in
mpi_write_sgl().
Replace this by the centrally provided cpu_to_be*() macros.
Signed-off-by: Nicolai Stange
---
lib/mpi/mpicoder.c | 27 +++
1 file changed, 11 insertions(+), 16 deletions(-)
diff --gi
Within the copying loop in mpi_write_sgl(), we have
if (lzeros) {
...
p -= lzeros;
y = lzeros;
}
p = p - (sizeof(alimb) - y);
If lzeros == 0, then y == 0, too. Thus, lzeros gets subtracted and added
back again to p.
Purge this redundancy.
Signed-off-by: Nicolai Stange
---
li
Currently, the endian conversion from CPU order to BE is open coded in
mpi_read_buffer().
Replace this by the centrally provided cpu_to_be*() macros.
Copy from the temporary storage on stack to the destination buffer
by means of memcpy().
Signed-off-by: Nicolai Stange
---
lib/mpi/mpicoder.c | 2
Currently, if the number of leading zeros is greater than fits into a
complete limb, mpi_read_buffer() skips them by iterating over them
limb-wise.
Instead of skipping the high order zero limbs within the loop as shown
above, adjust the copying loop's bounds.
Signed-off-by: Nicolai Stange
---
l
Currently, if the number of leading zeros is greater than fits into a
complete limb, mpi_write_sgl() skips them by iterating over them limb-wise.
However, it fails to adjust its internal leading zeros tracking variable,
lzeros, accordingly: it does a
p -= sizeof(alimb);
continue;
which shoul
Currently, mpi_read_buffer() writes full limbs to the output buffer
and moves memory around to purge leading zero limbs afterwards.
However, with
commit 9cbe21d8f89d ("lib/mpi: only require buffers as big as needed for
the integer")
the caller is only required to provid
In mpi_read_raw_from_sgl(), unsigned nbits is calculated as follows:
nbits = nbytes * 8;
and redundantly cleared later on if nbytes == 0:
if (nbytes > 0)
...
else
nbits = 0;
Purge this redundant clearing for the sake of clarity.
Signed-off-by: Nicolai Stange
---
lib/mpi/mpicode
At the very beginning of mpi_read_raw_from_sgl(), the leading zeros of
the input scatterlist are counted:
lzeros = 0;
for_each_sg(sgl, sg, ents, i) {
...
if (/* sg contains nonzero bytes */)
break;
/* sg contains nothing but zeros here */
ents--;
lzeros = 0;
}
Lat
Within the copying loop in mpi_write_sgl(), we have
if (lzeros > 0) {
...
lzeros -= sizeof(alimb);
}
However, at this point, lzeros < sizeof(alimb) holds. Make this fact
explicit by rewriting the above to
if (lzeros) {
...
lzeros = 0;
}
Signed-off-by: Nicolai Stange
---
Currently, the nbytes local variable is calculated from the len argument
as follows:
... mpi_read_raw_from_sgl(..., unsigned int len)
{
unsigned nbytes;
...
if (!ents)
nbytes = 0;
else
nbytes = len - lzeros;
...
}
Given that nbytes is derived from len in a tr
The number of bits, nbits, is calculated in mpi_read_raw_from_sgl() as
follows:
nbits = nbytes * 8;
Afterwards, the number of leading zero bits of the first byte get
subtracted:
nbits -= count_leading_zeros(*(u8 *)(sg_virt(sgl) + lzeros));
However, count_leading_zeros() takes an unsigned lo
Within the byte reading loop in mpi_read_raw_sgl(), there are two
housekeeping indices used, z and x.
At all times, the index z represents the number of output bytes covered
by the input SGEs for which processing has completed so far. This includes
any leading zero bytes within the most significan
Within the copying loop in mpi_read_raw_from_sgl(), the last input SGE's
byte count gets artificially extended as follows:
if (sg_is_last(sg) && (len % BYTES_PER_MPI_LIMB))
len += BYTES_PER_MPI_LIMB - (len % BYTES_PER_MPI_LIMB);
Within the following byte copying loop, this causes reads beyo
On Tue, Mar 22, 2016 at 12:32:21PM +0100, Heiko Carstens wrote:
> On Tue, Mar 22, 2016 at 11:21:53AM +0100, Peter Zijlstra wrote:
> > And s390 does something entirely vile, no idea what.
>
> For the two s390 usages tsk equals current. So it could be easily replaced
> with set_current_state().
Hm
>> I don't think you should focus too much on alsamixer, there's other
>> tools to modify the configuration.
> The expectation is that most users will use something like UCM and only
> system integrators will see the full control set in normal operation.
This presumes the "system integrator" (whic
You have send this patch before, right ?
then it is a good custom to have something like: [Patch V2] in the
subject line. In the comment you should write somethink like
v2: fix withspace damage
v1: fix issue
Otherwise none of the reviewer maintainer will see what was changes.
Sometimes patch r
On Tue, Mar 22, 2016 at 12:00:18PM +0100, Michal Hocko wrote:
> extern signed long schedule_timeout_interruptible(signed long timeout);
> extern signed long schedule_timeout_killable(signed long timeout);
> extern signed long schedule_timeout_uninterruptible(signed long timeout);
> +extern sign
On Tue, Mar 22, 2016 at 01:46:30PM +0300, Aleksey Makarov wrote:
> 'ARM Server Base Boot Requiremets' [1] mentions SPCR (Serial Port
> Console Redirection Table) [2] as a mandatory ACPI table that
> specifies the configuration of serial console.
>
> Parse this table, setup earlycon and enable the
Alex Deucher writes:
> On Mon, Mar 21, 2016 at 8:10 AM, Nicolai Stange wrote:
>> The values of all but the RADEON_HPD_NONE members of the radeon_hpd_id
>> enum transform 1:1 into bit positions within the 'enabled' bitset as
>> assembled by evergreen_hpd_init():
>>
>> enabled |= 1 << radeon_con
Hi Leif,
[auto build test ERROR on next-20160322]
[also build test ERROR on v4.5]
[cannot apply to pm/linux-next v4.5-rc7 v4.5-rc6 v4.5-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help
improving the system]
url:
https://github.com/0day-ci/linux/commits
On Tue, Mar 22, 2016 at 9:09 AM, Jiri Slaby wrote:
> On 03/21/2016, 04:58 PM, Jiri Slaby wrote:
>> Hello,
>>
>> On 03/18/2016, 09:52 PM, Tejun Heo wrote:
>>> On Thu, Mar 17, 2016 at 01:00:13PM +0100, Jiri Slaby wrote:
>> I have not done that yet, but today, I see:
>> destroy_workqueue: nam
On Tue 22-03-16 13:23:45, Peter Zijlstra wrote:
> On Tue, Mar 22, 2016 at 12:00:18PM +0100, Michal Hocko wrote:
>
> > extern signed long schedule_timeout_interruptible(signed long timeout);
> > extern signed long schedule_timeout_killable(signed long timeout);
> > extern signed long schedule_ti
On Tue, Mar 22, 2016 at 03:53:02PM +0530, Sodagudi Prasad wrote:
>
> Hi All,
>
> Would like to check whether the dma_map_single_attrs() API, can accept ptr
> variable from high memory or not?
It can't. Direct mapped, lowmem only.
No pointers allowed from dma_alloc_coherent(), dma_alloc_writeco
There are several places where the English in the document is syntactically
invalid, or unclear. There are also one or two factual errors.
---
Documentation/thermal/sysfs-api.txt | 44 ++---
1 file changed, 22 insertions(+), 22 deletions(-)
diff --git a/Documentat
On Mon, Mar 21, 2016 at 11:00 PM, Alexandre Courbot wrote:
> On 03/22/2016 10:41 AM, Rob Herring wrote:
>>
>> On Sun, Mar 20, 2016 at 1:55 AM, Alexandre Courbot
>> wrote:
>>>
>>> On Sat, Mar 19, 2016 at 5:47 AM, Rob Herring wrote:
On Tue, Mar 15, 2016 at 11:58:42AM +0900, Alexandre Cou
On Tue, 22 Mar 2016 08:10:10 +0100
Jiri Olsa wrote:
> On Mon, Mar 21, 2016 at 05:40:30PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Mar 21, 2016 at 09:08:52AM +0100, Jiri Olsa escreveu:
> > > On Fri, Mar 18, 2016 at 02:38:52PM -0300, Arnaldo Carvalho de Melo wrote:
> > >
> > > > Em F
On Tue, Mar 22, 2016 at 01:33:14PM +0100, Michal Hocko wrote:
> On Tue 22-03-16 13:23:45, Peter Zijlstra wrote:
> > On Tue, Mar 22, 2016 at 12:00:18PM +0100, Michal Hocko wrote:
> >
> > > extern signed long schedule_timeout_interruptible(signed long timeout);
> > > extern signed long schedule_ti
On Tue, 22 Mar 2016 10:09:30 +0100
Peter Zijlstra wrote:
> On Mon, Mar 21, 2016 at 11:23:39AM -0400, Steven Rostedt wrote:
> >
> > Signed-off-by: Steven Rostedt
>
> What tree is this against? It does not apply.
Hmm, my tree which is based on 4.5-rc7.
-- Steve
A softlockup in shrink_dentry_list when called from shrink_dcache_sb
was observed on a very busy server. It's possible that the list
passed to shrink_dentry_list is so big that it takes a while to
dispose of all entries. Adding a simple cond_resched would give
the cpu a chance to do some other usef
Using comparison to false and true is error prone. Fixed multiple warnings as
per checkpatch guidelines.
Signed-off-by: Parth Sane
---
drivers/staging/vt6656/wcmd.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/vt6656/wcmd.c b/drivers/staging/vt6656
Hi Shawn,
On 22.03.2016 13:36, Shawn Lin wrote:
> Let's improve the check with -EPROBE_DEFER, otherwise
> we may pass on null pointer to PTR_ERR. That causes the
> static checker warning: passing zero to 'PTR_ERR'.
>
> Reported-by: Dan Carpenter
> Cc: Doug Anderson
> Cc: Dan Carpenter
> Signed
On Fri, Mar 04, 2016 at 03:59:19PM +0530, Kishon Vijay Abraham I wrote:
> From: Sekhar Nori
>
> This reverts commit <5c3b99d057525fe2befe6a7db9b1309035d93eee>
> ("PCI: dra7xx: Mark driver as broken").
>
> With support to de-assert PCIe reset present in kernel,
> DRA7x PCIe is not broken anymore.
On 22.03.2016 14:56, Vladimir Zapolskiy wrote:
> Hi Shawn,
>
> On 22.03.2016 13:36, Shawn Lin wrote:
>> Let's improve the check with -EPROBE_DEFER, otherwise
>> we may pass on null pointer to PTR_ERR. That causes the
>> static checker warning: passing zero to 'PTR_ERR'.
>>
>> Reported-by: Dan Carp
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git for-linus
This contains direct I/O fixes.
Thanks,
Miklos
---
Ashish Samant (1):
fuse: return patrial success from fuse_direct_io()
Robert Doebbelin (1):
fuse: do not use iocb after it may
On Mon, Mar 21, 2016 at 01:42:01PM +0100, Rafael J. Wysocki wrote:
> On Mon, Mar 21, 2016 at 12:12 PM, Lorenzo Pieralisi
> wrote:
> > The [0 - 64k] ACPI PCI IO port resource boundary check in:
> >
> > acpi_dev_ioresource_flags()
> >
> > is currently applied blindly in the ACPI resource parsing to
On 03/21/2016 10:01 PM, Shuah Khan wrote:
> On 03/19/2016 07:31 AM, Shuah Khan wrote:
>> On 03/19/2016 06:10 AM, Mauro Carvalho Chehab wrote:
>>> Em Fri, 18 Mar 2016 20:50:31 -0600
>>> Shuah Khan escreveu:
>>>
Fix to release stream resources from media_snd_device_delete() before
media de
On Tue, Mar 22, 2016 at 04:40:24PM +0900, DaeSeok Youn wrote:
> 2016-03-22 6:05 GMT+09:00 Greg KH :
> > On Mon, Mar 14, 2016 at 01:29:00PM +0900, Daeseok Youn wrote:
> >> the tty_alloc_driver() can allocate memory for ttys and termios.
> >> And also it can release allocated memory easly with using
On 03/21/2016 10:04 PM, Shuah Khan wrote:
> au0828_v4l2_close() check for dev_state == DEV_DISCONNECTED will fail to
> detect the device disconnected state correctly, if au0828_v4l2_open() runs
> to set the DEV_INITIALIZED bit. A loop test of bind/unbind found this bug
> by increasing the likelihoo
>> My theory is the following:
>>
>> As soon as ttyS0 is detected and installed as the console, there are two
>> console drivers active on the serial port at the same time: early0 and
>> ttyS0. I suspect that the hang occurs when the primitive early0
>> implementation prom_putchar_ar71xx waits inde
On Tue 22-03-16 13:51:13, Peter Zijlstra wrote:
> On Tue, Mar 22, 2016 at 01:33:14PM +0100, Michal Hocko wrote:
> > On Tue 22-03-16 13:23:45, Peter Zijlstra wrote:
> > > On Tue, Mar 22, 2016 at 12:00:18PM +0100, Michal Hocko wrote:
> > >
> > > > extern signed long schedule_timeout_interruptible(s
Hi Linus,
Please pull from:
git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs.git overlayfs-linus
This contains various fixes and tweaks.
Thanks,
Miklos
---
David Howells (1):
ovl: Warn on copy up if a process has a R/O fd open to the lower file
Konstantin Khlebnikov (1):
On Tue 2016-03-22 02:25:29, Sergey Senozhatsky wrote:
> From: Jan Kara
>
> This patch makes printk() completely asynchronous (similar to what
> printk_deferred() did until now). It appends message to the kernel
> printk buffer and wake_up()s a special dedicated kthread to do the
> printing to con
Hi Greg,
this series' v6 is meant to replace the v4 currently sitting in your
driver-core tree's driver-core-testing branch.
All the three fixup patches to v4 (not applied anywhere) have been
incorporated into this v6. I'll explicitly mark them as "please drop".
Former v5 thread can be found he
Currently, the struct file_operations associated with the integer attribute
style files created through the debugfs_create_*() helpers are not file
lifetime aware as they are defined by means of DEFINE_SIMPLE_ATTRIBUTE().
Thus, a lifetime managing proxy is created around the original fops each
tim
On Thu, Mar 17, 2016 at 4:34 PM, Vishnu Patekar
wrote:
> On Thu, Mar 17, 2016 at 10:51 PM, Linus Walleij
>> I think I already merged this?
>
> AFAIK, this one is not yet merged. At least, you did not say it's merged. :)
Sorry, confused it with the plain A83T controller...
Yours,
Linus Walleij
Nothing prevents a dentry found by path lookup before a return of
__debugfs_remove() to actually get opened after that return. Now, after
the return of __debugfs_remove(), there are no guarantees whatsoever
regarding the memory the corresponding inode's file_operations object
had been kept in.
Sin
In order to protect against file removal races, debugfs files created via
debugfs_create_file() now get wrapped by a struct file_operations at their
opening.
If the original struct file_operations are known to be safe against removal
races by themselves already, the proxy creation may be bypassed
The struct file_operations u32_array_fops associated with files created
through debugfs_create_u32_array() has been lifetime aware already:
everything needed for subsequent operation is copied to a ->f_private
buffer at file opening time in u32_array_open(). Now, ->open() is always
protected agains
Hi Doug,
On 22.03.2016 05:33, Doug Anderson wrote:
> Shawn,
>
> On Mon, Mar 21, 2016 at 7:53 PM, Shawn Lin wrote:
>> + Vinod
>>
>>
>> On 2016/3/22 10:33, Doug Anderson wrote:
>>>
>>> Shawn,
>>>
>>> On Mon, Mar 21, 2016 at 7:03 PM, Shawn Lin
>>> wrote:
>
> ...but, looking at this, presum
Currently, the struct file_operations fops_blob associated with files
created through the debugfs_create_blob() helpers are not file
lifetime aware.
Thus, a lifetime managing proxy is created around fops_blob each time such
a file is opened which is an unnecessary waste of resources.
Implement fi
In order to protect them against file removal issues, debugfs_create_file()
creates a lifetime managing proxy around each struct file_operations
handed in.
In cases where this struct file_operations is able to manage file lifetime
by itself already, the proxy created by debugfs is a waste of resou
Currently, the struct file_operations fops_bool associated with files
created through the debugfs_create_bool() helpers are not file
lifetime aware.
Thus, a lifetime managing proxy is created around fops_bool each time such
a file is opened which is an unnecessary waste of resources.
Implement fi
Upon return of debugfs_remove()/debugfs_remove_recursive(), it might
still be attempted to access associated private file data through
previously opened struct file objects. If that data has been freed by
the caller of debugfs_remove*() in the meanwhile, the reading/writing
process would either enc
Please drop as this has been fixed in the current v6 of the offending
series to be found here:
http://lkml.kernel.org/g/1458652280-19785-1-git-send-email-nicsta...@gmail.com
Thank you!
Nicolai
On Tue, Mar 22, 2016 at 2:12 PM, Linus Walleij wrote:
> On Thu, Mar 17, 2016 at 4:34 PM, Vishnu Patekar
> wrote:
>> On Thu, Mar 17, 2016 at 10:51 PM, Linus Walleij
>
>>> I think I already merged this?
>>
>> AFAIK, this one is not yet merged. At least, you did not say it's merged. :)
>
> Sorry, co
If a file is renamed to a hardlink of itself POSIX specifies that rename(2)
should do nothing and return success.
This condition is checked in vfs_rename(). However it won't detect hard
links on overlayfs where these are given separate inodes on the overlayfs
layer.
Overlayfs itself detects this
Hi,
On 21 March 2016 at 19:23, Gustavo Padovan wrote:
> @@ -96,6 +98,11 @@ static void virtio_gpu_plane_atomic_update(struct
> drm_plane *plane,
> plane->state->crtc_y,
> plane->state->crtc_w,
>
Please drop as this has been fixed in the current v6 of the offending
series to be found here:
http://lkml.kernel.org/g/1458652280-19785-1-git-send-email-nicsta...@gmail.com
Thank you!
Nicolai
On Tue, 22 Mar 2016 09:14:14 -0400
Peter Xu wrote:
> This line is useless since we will get more verbose info in
> do_connection(). Another problem is, we will get this "connected!" line
> everytime after we hit "ctrl-c" for "trace-cmd listen". We possibly do
> not want that.
>
> Signed-off-by:
On Wed, Mar 16, 2016 at 1:48 AM, Kuninori Morimoto
wrote:
> From: Kuninori Morimoto
>
> Gen2 / Gen3 datasheet will have below note in next version.
> This patch follows this note.
>
> IPSRx and MOD_SELx registers shall be set before setting GPSRx
> registers in case that they need to be configur
On Tue, 22 Mar 2016, Nicolai Stange wrote:
> In order to protect against file removal races, debugfs files created via
> debugfs_create_file() now get wrapped by a struct file_operations at their
> opening.
>
> If the original struct file_operations are known to be safe against removal
> races b
Overlayfs needs lookup without inode_permission() and already has the name
hash (in form of dentry->d_name on overlayfs dentry). It also doesn't
support filesystems with d_op->d_hash() so basically it only needs
__lookup_hash() from lookup_one_len().
Rename __lookup_hash() to lookup_hash() and ex
On Tue, 22 Mar 2016 09:14:33 -0400
Peter Xu wrote:
> Currently we have two ways to copy data, one is splice, one is read +
> write. For both, dump more information when we got errors during the
> copy. Also, when we update_fd(), we should make sure all bytes written,
> and update written bytes on
Generally permission checking is not necessary when overlayfs looks up a
dentry on one of the underlying layers, since search permission on base
directory was already checked in ovl_permission().
More specifically using lookup_one_len() causes a problem when the lower
directory lacks search permis
On Tue, Mar 22, 2016 at 02:08:23PM +0100, Michal Hocko wrote:
> On Tue 22-03-16 13:51:13, Peter Zijlstra wrote:
> If that sounds like a more appropriate plan I won't object. I can simply
> change my patch to do __set_current_state and schedule_timeout.
I dunno, I just think these wrappers are sill
>-Original Message-
>From: Andy Champ [mailto:andyc...@amazon.com]
>Sent: Tuesday, March 22, 2016 6:07 PM
>To: edubez...@gmail.com
>Cc: cor...@lwn.net; javi.mer...@arm.com; R, Durgadoss ;
>leo@linaro.org; kapileshwar.si...@arm.com; w...@nvidia.com;
>linux-...@vger.kernel.org; linux-
>k
On Tue, Mar 22, 2016 at 01:20:50PM +0100, Peter Zijlstra wrote:
> On Tue, Mar 22, 2016 at 12:32:21PM +0100, Heiko Carstens wrote:
> > On Tue, Mar 22, 2016 at 11:21:53AM +0100, Peter Zijlstra wrote:
>
> > > And s390 does something entirely vile, no idea what.
> >
> > For the two s390 usages tsk eq
On Tue, Mar 22, 2016 at 03:02:00PM +0200, Claudiu Beznea wrote:
> I was guided by the principle that every instruction counts, no matter the
> execution context.
But you have to be able to actually measure the difference, and here you
can't.
thanks,
greg k-h
Create sysfs attributes to export throttle information in
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats directory. The
newly added sysfs files are as follows:
1)/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/turbo_stat
2)/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/sub-turbo_stat
Hi Paolo,
Paolo Bonzini writes:
>
> Please test this instead:
This patch works for me. Please feel free to add:
Tested-by: Pranith Kumar
>
> diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
> index 7f7b6d86ac73..eba0bea6e032 100644
> --- a/arch/powerpc/kvm/Makefile
> +++ b/
> Wow, that is a comprehensive explanation. In principle the patch looks
> good, but I wonder whether the heuristics you have developed for button
> detection needs wider testing.
This is indeed my primary concern.
> I can test on my S7020 but only in a few
> days time (this week is a very busy
On Tue, Mar 22, 2016 at 02:26:00PM +0100, Heiko Carstens wrote:
> > Clearly something magical is going on and its not clear.
>
> The mechanism of our pfault code: if Linux is running as guest, runs a user
> space process and the user space process accesses a page that the host has
> paged out we g
[root@localhost c_test]# cat /proc/3948/smaps | grep Rss
Rss: 4 kB
Rss: 4 kB
Rss: 4 kB
Rss: 796 kB
Rss: 0 kB
Rss: 16 kB
Rss: 8 kB
Rss: 12 kB
Rss:
Hello Krzysztof,
On 03/21/2016 11:00 PM, Krzysztof Kozlowski wrote:
> Add Security SubSystem (SSS) node to Exynos4 which provides hardware
> acceleration of AES operations.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
Reviewed-by: Javier Martinez Canillas
Best regards,
--
Javier Martinez Can
Hello Krzysztof,
On 03/21/2016 11:00 PM, Krzysztof Kozlowski wrote:
> Enable the Security SubSystem (SSS) on Trats2 (Exynos4412) board which
> allows usage of its hardware accelerated AES operations.
>
> Signed-off-by: Krzysztof Kozlowski
> ---
Reviewed-by: Javier Martinez Canillas
Best regar
On Sat, 19 Mar 2016 11:05:18 +0100,
Jiri Slaby wrote:
>
> Both vhci_get_user and vhci_release race with open_timeout work. They
> both contain cancel_delayed_work_sync, but do not test whether the
> work actually created hdev or not. Since the work can be in progress
> and _sync will wait for fini
KY Srinivasan writes:
>> -Original Message-
>> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
>> Sent: Monday, March 21, 2016 12:52 AM
>> To: KY Srinivasan
>> Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; Haiyang
>> Zhang ; Alex Ng (LIS) ;
>> Radim Krcmar ; Cathy A
301 - 400 of 880 matches
Mail list logo
