node generation has to be stored on disk.
AFAICS we won't be able to manage it on AFFS.
This patch removes relevant check in affs_nfs_get_inode()
Signed-off-by: Fabian Frederick
---
fs/affs/namei.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/fs/affs/namei.c b/fs/affs/namei.c
index b0
AFFS symbolic links were broken since kernel 2.6.29
Problem was bisected to the following
commit ebd09abbd969 ("vfs: ensure page symlinks are NUL-terminated")
commit 035146851cfa ("vfs: introduce helper function to safely
NUL-terminate symlinks")
AFFS wasn't setting inode size when reading symbo
Have that file in global include/linux is not needed.
Signed-off-by: Fabian Frederick
---
fs/affs/affs.h| 2 +-
{include/linux => fs/affs}/amigaffs.h | 0
2 files changed, 1 insertion(+), 1 deletion(-)
rename {include/linux => fs/affs}/amigaffs.h (100%)
diff --git a/fs/
Hi surenderpolsani,
[auto build test ERROR on v4.9-rc8]
[also build test ERROR on next-20170413]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/surenderpolsani/remove-return-statement/20170415-1
On Thu, 13 Apr 2017 16:49:23 -0700, Dmitry Torokhov wrote:
> We should not be forcing edge triggered interrupt, but rather let platform
> decide the kind of trigger it needs to use. Also, the driver is not quite
> safe with regard to edge-triggered interrupts as it does not try to kick
> the contro
On Thu, 13 Apr 2017 16:32:25 -0700, Dmitry Torokhov wrote:
> The name field in structure i2c_device_id is 20 characters, and we expect
> it to be NULL-terminated, however we are trying to stuff it with 21 bytes
> and thus NULL-terminator is lost. This causes issues when one creates
> device with na
On 9 April 2017 at 07:40, Al Viro wrote:
>
> The following changes since commit a71c9a1c779f2499fb2afc0553e543f18aff6edf:
>
> Linux 4.11-rc5 (2017-04-02 17:23:54 -0700)
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus
>
> for
kernel coding style doesn't allow the return statement
in void function.
Signed-off-by: surenderpolsani
---
Changes for v2:
corrected subject line as suggested
---
drivers/staging/rtl8188eu/hal/rtl8188e_dm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/hal/rtl8188
Avoid long variable name in discard_cmd_control structure, no logic
change.
Signed-off-by: Chao Yu
---
fs/f2fs/f2fs.h| 8
fs/f2fs/segment.c | 24
2 files changed, 16 insertions(+), 16 deletions(-)
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 476e9459
Keep issuing big size discard in prior instead of the one with random
size, so that we expect that it will help to:
- be quick to recycle unused large space in flash storage device.
- give a chance for
a) wait to merge small piece discards into bigger one, or
b) avoid issuing discards while the
Add an even class f2fs_discard for introducing f2fs_queue_discard, then
use f2fs_{queue,issue}_discard to trace __{queue,submit}_discard_cmd.
Signed-off-by: Chao Yu
---
fs/f2fs/segment.c | 4 +++-
include/trace/events/f2fs.h | 16 +++-
2 files changed, 18 insertions(+), 2
Thomas Gleixner wrote:
> > Btw, is it possible to use IRQ grants to prevent a device that has limited
> > IRQ options from being drivable?
>
> What do you mean with 'IRQ grants' ?
request_irq().
David
On Fri, 14 Apr 2017, David Howells wrote:
> Thomas Gleixner wrote:
>
> > > -module_param_named(irq, timer_irq, int, 0644);
> > > +module_param_hw_named(irq, timer_irq, int, irq, 0644);
> > > MODULE_PARM_DESC(irq, "Which IRQ to use for the clock source MFGPT
> > > ticks.");
> >
> > I'm not sure
On Sat, 15 Apr 2017, kbuild test robot wrote:
> tree: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/cpu
> head: 64e8ed3d4a6dcd6139a869a3e760e625cb0d3022
> commit: 05b93417ce5b924c6652de19fdcc27439ab37c90 [8/12] x86/intel_rdt/mba:
> Add primary support for Memory Bandwidth Al
On Sat, 2017-04-15 at 10:35 +0530, surenderpolsani wrote:
> staging : rtl8188e : remove return in void function
Your patch subject isn't correct.
It should be something like:
Subject: [PATCH] staging: rtl8188e: Remove void function return
> kernel coding style doesn't allow the return statement
staging : rtl8188e : remove return in void function
kernel coding style doesn't allow the return statement
in void function.
Signed-off-by: surenderpolsani
---
drivers/staging/rtl8188eu/hal/rtl8188e_dm.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/rtl8188eu/hal/rtl8188e_d
On Fri, Apr 14, 2017 at 3:35 AM, Logan Gunthorpe wrote:
> The get_page in this area looks *highly* suspect due to there being no
> corresponding put_page. However, I've left that as is to avoid breaking
> things.
chcr driver will post the request to LLD driver cxgb4 and put_page is
implemented the
s/rollove/rollover/
Signed-off-by: Rahul Bedarkar
---
Documentation/devicetree/bindings/input/rotary-encoder.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt
b/Documentation/devicetree/bindings/input/rotary-encode
Hi Matthias,
On Tue, Apr 11, 2017 at 12:17 PM, Matthias Kaehlcke wrote:
> Besides reusing existing code this removes the special case handling
> for 64-bit masks, which causes clang to raise a shift count overflow
> warning due to https://bugs.llvm.org//show_bug.cgi?id=10030.
>
> Suggested-by: Dm
Adding Stephen.
On 04/14/17 20:55, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> checkpatch whined about using S_IRUGO instead of octal equivalent
> when adding phandle sysfs code, so used octal in that patch.
> Change other instances of the S_* constants in the same file to
> the octal
Adding Stephen.
On 04/14/17 20:55, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> Overlays are not allowed to modify phandle values of previously existing
> nodes because there is no information available to allow fixup up
> properties that use the previously existing phandle.
>
> Signe
Adding Stephen.
On 04/14/17 20:55, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> __of_attach_node() is not used outside of drivers/of/dynamic.c. Make
> it static and remove it from drivers/of/of_private.h.
>
> Signed-off-by: Frank Rowand
> ---
> drivers/of/dynamic.c| 2 +-
> dri
Adding Stephen.
On 04/14/17 20:55, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> Remove "phandle" and "linux,phandle" properties from the internal
> device tree. The phandle will still be in the struct device_node
> phandle field.
>
> This is to resolve the issue found by Stephen Boyd
Hi Stephen,
I left you off the distribution list, sorry...
On 04/14/17 20:55, frowand.l...@gmail.com wrote:
> From: Frank Rowand
>
> Remove "phandle" and "linux,phandle" properties from the internal
> device tree. The phandle will still be in the struct device_node
> phandle field.
>
> This i
From: Frank Rowand
Remove "phandle" and "linux,phandle" properties from the internal
device tree. The phandle will still be in the struct device_node
phandle field.
This is to resolve the issue found by Stephen Boyd [1] when he changed
the type of struct property.value from void * to const void
From: Frank Rowand
Remove "phandle" and "linux,phandle" properties from the internal
device tree. The phandle will still be in the struct device_node
phandle field.
This is to resolve the issue found by Stephen Boyd [1] when he changed
the type of struct property.value from void * to const void
From: Frank Rowand
__of_attach_node() is not used outside of drivers/of/dynamic.c. Make
it static and remove it from drivers/of/of_private.h.
Signed-off-by: Frank Rowand
---
drivers/of/dynamic.c| 2 +-
drivers/of/of_private.h | 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --
From: Frank Rowand
Overlays are not allowed to modify phandle values of previously existing
nodes because there is no information available to allow fixup up
properties that use the previously existing phandle.
Signed-off-by: Frank Rowand
---
drivers/of/overlay.c | 4
1 file changed, 4 in
From: Frank Rowand
checkpatch whined about using S_IRUGO instead of octal equivalent
when adding phandle sysfs code, so used octal in that patch.
Change other instances of the S_* constants in the same file to
the octal form.
Signed-off-by: Frank Rowand
---
drivers/of/base.c | 2 +-
1 file cha
On Friday 14 April 2017 11:48 PM, Eduardo Valentin wrote:
> Hey,
>
> On Fri, Apr 14, 2017 at 08:42:20AM -0700, Eduardo Valentin wrote:
>> Hello again,
>>
>> On Fri, Apr 14, 2017 at 08:38:40AM -0700, Eduardo Valentin wrote:
>>> Hey,
>>>
>>> On Fri, Apr 14, 2017 at 02:22:13PM +0530, Keerthy wrote:
orderly_poweroff is triggered when a graceful shutdown
of system is desired. This may be used in many critical states of the
kernel such as when subsystems detects conditions such as critical
temperature conditions. However, in certain conditions in system
boot up sequences like those in the middle
thermal_zone_device_check --> thermal_zone_device_update -->
handle_thermal_trip --> handle_critical_trips --> orderly_poweroff
The above sequence happens every 250/500 mS based on the configuration.
The orderly_poweroff function is getting called every 250/500 mS.
With a full fledged file system
We want dax capable drivers to be able to publish a set of dax
operations [1]. However, we do not want to further abuse block_devices
to advertise these operations. Instead we will attach these operations
to a dax device and add a lookup mechanism to go from block device path
to a dax device. A dax
Allocate a dax_device to represent the capacity of a device-mapper
instance. Provide a ->direct_access() method via the new dax_operations
indirection that mirrors the functionality of the current direct_access
support via block_device_operations. Once fs/dax.c has been converted
to use dax_operat
Setup a dax_inode to have the same lifetime as the brd block device and
add a ->direct_access() method that is equivalent to
brd_direct_access(). Once fs/dax.c has been converted to use
dax_operations the old brd_direct_access() will be removed.
Signed-off-by: Dan Williams
---
drivers/block/Kcon
Arrange for dm to lookup the dax services available from member devices.
Update the dax-capable targets, linear and stripe, to route dax
operations to the underlying device. Changes the target-internal
->direct_access() method to more closely align with the dax_operations
->direct_access() calling
Now that all possible providers of the dax_operations copy_from_iter
method are implemented, switch filesytem-dax to call the driver rather
than copy_to_iter_pmem.
Signed-off-by: Dan Williams
---
arch/x86/include/asm/pmem.h | 50 ---
fs/dax.c
Now that all the producers and consumers of dax interfaces have been
converted to using dax_operations on a dax_device, remove the block
device direct_access enabling.
Signed-off-by: Dan Williams
---
arch/powerpc/sysdev/axonram.c | 23 -
drivers/block/brd.c | 15
Filesystem-DAX flushes caches whenever it writes to the address returned
through dax_direct_access() and when writing back dirty radix entries.
That flushing is only required in the pmem case, so add a dax operation
to allow pmem to take this extra action, but skip it for other dax
capable devices
memcpy_from_pmem() maps directly to memcpy_mcsafe(). The wrapper
serves no real benefit aside from affording a more generic function name
than the x86-specific 'mcsafe'. However this would not be the first time
that x86 terminology leaked into the global namespace. For lack of
better name, just use
With all calls to this routine re-directed through the pmem driver, we
can kill the pmem api indirection. arch_wb_cache_pmem() is now
optionally supplied by an arch specific extension to libnvdimm. Same as
before, pmem flushing is only defined for x86_64, but it is
straightforward to add other arc
The clear_pmem() helper simply combines a memset() plus a cache flush.
Now that the flush routine is optionally provided by the dax device
driver we can avoid unnecessary cache management on dax devices fronting
volatile memory.
With clear_pmem() gone we can follow on with a patch to make pmem cac
The pmem and nd_blk drivers both have need to copy data through the cpu
cache to persistent memory. To date they have been abusing
__copy_user_nocache through the memcpy_to_pmem abstraction, but this has
several problems:
* __copy_user_nocache does not guarantee that it will always avoid the
cac
Kill this globally defined wrapper and move to libnvdimm so that we can
ultimately remove the public pmem api.
Cc:
Cc: Jan Kara
Cc: Jeff Moyer
Cc: Ingo Molnar
Cc: Christoph Hellwig
Cc: "H. Peter Anvin"
Cc: Thomas Gleixner
Cc: Matthew Wilcox
Cc: Ross Zwisler
Signed-off-by: Dan Williams
--
The pmem driver assumes if platform firmware describes the memory
devices associated with a persistent memory range and
CONFIG_ARCH_HAS_PMEM_API=y that it has all the mechanism necessary to
flush data to a power-fail safe zone. We warn if the firmware does not
describe memory devices, but we also n
Allow volatile nfit ranges to participate in all the same infrastructure
provided for persistent memory regions. A resulting resulting namespace
device will still be called "pmem", but the parent region type will be
"nd_volatile". This is in preparation for disabling the dax ->flush()
operation in
Some platforms arrange for cpu caches to be flushed on power-fail. On
those platforms there is no requirement that the kernel track and flush
potentially dirty cache lines. Given that we still insert entries into
the radix for locking purposes this patch only disables the cache flush
loop, not the
The pmem driver attaches to both persistent and volatile memory ranges
advertised by the ACPI NFIT. When the region is volatile it is redundant
to spend cycles flushing caches at fsync(). Check if the hosting region
is volatile and do not set QUEUE_FLAG_WC if it is.
Cc: Jan Kara
Cc: Jeff Moyer
C
Introduce copy_from_iter_ops() to enable passing custom sub-routines to
iterate_and_advance(). Define pmem operations that guarantee cache
bypass to supplement the existing usage of __copy_from_iter_nocache()
backed by arch_wb_cache_pmem().
Cc: Jan Kara
Cc: Jeff Moyer
Cc: Christoph Hellwig
Cc:
Filesystem-DAX flushes caches whenever it writes to the address returned
through dax_direct_access() and when writing back dirty radix entries.
That flushing is only required in the pmem case, so the dax_flush()
helper skips cache management work when the underlying driver does not
specify a flush
Allow device-mapper to route copy_from_iter operations to the
per-target implementation. In order for the device stacking to work we
need a dax_dev and a pgoff relative to that device. This gives each
layer of the stack the information it needs to look up the operation
pointer for the next level.
The direct-I/O write path for a pmem device must ensure that data is
flushed to a power-fail safe zone when the operation is complete.
However, other dax capable block devices, like brd, do not have this
requirement. Introduce a 'copy_from_iter' dax operation so that pmem
can inject cache manageme
Allow device-mapper to route flush operations to the
per-target implementation. In order for the device stacking to work we
need a dax_dev and a pgoff relative to that device. This gives each
layer of the stack the information it needs to look up the operation
pointer for the next level.
This conc
Kill of the final user of bdev_direct_access() and struct blk_dax_ctl.
Signed-off-by: Dan Williams
---
fs/block_dev.c | 48
1 file changed, 28 insertions(+), 20 deletions(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 2f7885712575..ecbdc
Now that a dax_device is plumbed through all dax-capable drivers we can
switch from block_device_operations to dax_operations for invoking
->direct_access.
This also lets us kill off some usages of struct blk_dax_ctl on the way
to its eventual removal.
Suggested-by: Christoph Hellwig
Signed-off-
commit d1a5f2b4d8a1 ("block: use DAX for partition table reads") was
part of a stalled effort to allow dax mappings of block devices. Since
then the device-dax mechanism has filled the role of dax-mapping static
device ranges.
Now that we are moving ->direct_access() from a block_device operation
In preparation for converting fs/dax.c to use dax_direct_access()
instead of bdev_direct_access(), add the plumbing to retrieve the
dax_device associated with a given block_device.
Signed-off-by: Dan Williams
---
fs/ext2/inode.c |9 -
fs/ext4/inode.c |9 -
fs/
This is leftover dead code that has since been replaced by
bdev_dax_supported().
Signed-off-by: Dan Williams
---
fs/block_dev.c | 24
include/linux/blkdev.h |1 -
2 files changed, 25 deletions(-)
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 2eca00ec4
Replace bdev_direct_access() with dax_direct_access() that uses
dax_device and dax_operations instead of a block_device and
block_device_operations for dax. Once all consumers of the old api have
been converted bdev_direct_access() will be deleted.
Given that block device partitioning decisions ca
Setup a dax_dev to have the same lifetime as the dcssblk block device
and add a ->direct_access() method that is equivalent to
dcssblk_direct_access(). Once fs/dax.c has been converted to use
dax_operations the old dcssblk_direct_access() will be removed.
Cc: Gerald Schaefer
Signed-off-by: Dan Wi
Setup a dax_device to have the same lifetime as the pmem block device
and add a ->direct_access() method that is equivalent to
pmem_direct_access(). Once fs/dax.c has been converted to use
dax_operations the old pmem_direct_access() will be removed.
Signed-off-by: Dan Williams
---
drivers/dax/da
Setup a dax_device to have the same lifetime as the axon_ram block
device and add a ->direct_access() method that is equivalent to
axon_ram_direct_access(). Once fs/dax.c has been converted to use
dax_operations the old axon_ram_direct_access() will be removed.
Signed-off-by: Dan Williams
---
ar
In preparation for introducing a struct dax_device type to the kernel
global type namespace, rename dax_dev to dev_dax. A 'dax_device'
instance will be a generic device-driver object for any provider of dax
functionality. A 'dev_dax' object is a device-dax-driver local /
internal instance.
Signed-
For the current block_device based filesystem-dax path, we need a way
for it to lookup the dax_device associated with a block_device. Add a
'host' property of a dax_device that can be used for this purpose. It is
a free form string, but for a dax_device associated with a block device
it is the bdev
Track a set of dax_operations per dax_device that can be set at
alloc_dax() time. These operations will be used to stop the abuse of
block_device_operations for communicating dax capabilities to
filesystems. It will also be used to replace the "pmem api" and move
pmem-specific cache maintenance, an
Changes since v1 [1] and the dax-fs RFC [2]:
* rename struct dax_inode to struct dax_device (Christoph)
* rewrite arch_memcpy_to_pmem() in C with inline asm
* use QUEUE_FLAG_WC to gate dax cache management (Jeff)
* add device-mapper plumbing for the ->copy_from_iter() and ->flush()
dax_operations
On Fri, Apr 14, 2017 at 3:51 PM, Rafael J. Wysocki wrote:
> On Tuesday, April 11, 2017 12:20:41 AM Rafael J. Wysocki wrote:
>> From: Rafael J. Wysocki
>>
>> Make the schedutil governor take the initial (default) value of the
>> rate_limit_us sysfs attribute from the (new) transition_delay_us
>> p
Other unsigned properties return hexadecimal values, follow this
convention when printing b_vendor_code too. Also add newlines to
the OS Descriptor support related properties, like other sysfs
files use.
Signed-off-by: Stefan Agner
---
drivers/usb/gadget/configfs.c | 6 +++---
1 file changed, 3
Currently qw_sign requires UTF-8 character to set, but returns UTF-16
when read. This isn't obvious when simply using cat since the null
characters are not visible, but hexdump unveils the true string:
# echo MSFT100 > os_desc/qw_sign
# hexdump -C os_desc/qw_sign
4d 00 53 00 46 00
Hi, Johannes,
Johannes Weiner writes:
> Hi Huang,
>
> I reviewed this patch based on the feedback I already provided, but
> eventually gave up and rewrote it. Please take review feedback more
> seriously in the future.
Thanks a lot for your help! I do respect all your review and effort.
The -v
On Fri, 14 Apr 2017, Shivappa Vikas wrote:
On Fri, 14 Apr 2017, Thomas Gleixner wrote:
Please do the following:
1) Verify that it still works as I have no hardware to test it. Once you
confirmed, it's going to show up in -next. So please do that ASAP,
i.e. yesterday.
2) Go through
In the check_only mode, we should not make any dirty node pages. Otherwise,
we can get this panic:
F2FS-fs (nvme0n1p1): Need to recover fsync data
[ cut here ]
kernel BUG at fs/f2fs/node.c:2204!
CPU: 7 PID: 19923 Comm: mount Tainted: G OE 4.9.8 #2
RIP: 0010:[]
This patch flushes data in faster device to cold area.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/f2fs.h| 6 --
fs/f2fs/file.c| 54 +-
fs/f2fs/gc.c | 19 ++-
fs/f2fs/segment.c | 14 ++
fs/f2fs/segment.h
On Fri, 14 Apr 2017 17:02:34 -0700
Linus Torvalds wrote:
> On Fri, Apr 14, 2017 at 3:05 PM, Steven Rostedt wrote:
> >
> > Would it be OK to cherry pick this change that I send to you, which
> > will be based on a commit in your tree, into my development branch
> > where I can continue the work o
On Fri, Apr 14, 2017 at 3:05 PM, Steven Rostedt wrote:
>
> Would it be OK to cherry pick this change that I send to you, which
> will be based on a commit in your tree, into my development branch
> where I can continue the work on top of the previous development that's
> in linux-next and the fix?
On Mon, 10 Apr 2017, Greg Kroah-Hartman wrote:
> Force o32 fp64 support in this case by also selecting
> MIPS_O32_FP64_SUPPORT from CPU_MIPS64_R6 if 32BIT.
[...]
> --- a/arch/mips/Kconfig
> +++ b/arch/mips/Kconfig
> @@ -1412,7 +1412,7 @@ config CPU_MIPS32_R6
> select CPU_SUPPORTS_MSA
>
> -Original Message-
> From: Rafael J. Wysocki [mailto:r...@rjwysocki.net]
> Sent: Friday, April 14, 2017 3:30 PM
> To: Moore, Robert
> Cc: Guenter Roeck; Zheng, Lv; Wysocki, Rafael J; Len Brown; linux-
> a...@vger.kernel.org; de...@acpica.org; linux-kernel@vger.kernel.org
> Subject: Re:
On Fri, Apr 14, 2017 at 04:27:37PM -0700, Andrei Vagin wrote:
> Hello,
>
> One of our CRIU tests hangs with this patch.
>
> Steps to reproduce:
> curl -o cgroupns.c
> https://gist.githubusercontent.com/avagin/f87c8a8bd2a0de9afcc74976327786bc/raw/5843701ef3679f50dd2427cf57a80871082eb28c/gistfile1
From: Kuppuswamy Sathyanarayanan
Since all second level thermal irqs are consumed by the same
device(bxt_wcove_thermal), there is no need to expose them as separate
interrupts. We can just export only the first level irqs for thermal and
let the device(bxt_wcove_thermal) driver handle the second
From: Kuppuswamy Sathyanarayanan
PMIC mfd driver only exports first level irq for thermal device.
But currently we are reading the irqs from the second level irq
chip, So this patch fixes this issue by adding support to use
first level PMIC thermal irq.
Signed-off-by: Kuppuswamy Sathyanarayanan
From: Kuppuswamy Sathyanarayanan
TMU interrupts are registered as a separate interrupt chip, and
hence it should start its interrupt index(BXTWC_TMU_IRQ) number
from 0. But currently, BXTWC_TMU_IRQ is defined as part of enum
bxtwc_irqs_level2 and its index value is 11. Since this index
value is u
From: Kuppuswamy Sathyanarayanan
Whishkey cove PMIC has support to mask/unmask interrupts at two levels.
At first level we can mask/unmask interrupt domains like TMU, GPIO, ADC,
CHGR, BCU THERMAL and PWRBTN and at second level, it provides facility
to mask/unmask individual interrupts belong each
From: Kuppuswamy Sathyanarayanan
Cleanup the resource allocation/free code in probe function by using
devm_* calls.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
drivers/mfd/intel_soc_pmic_bxtwc.c | 54 +-
1 file changed, 18 insertions(+), 36 deletions(-)
From: Kuppuswamy Sathyanarayanan
Currently in WCOVE PMIC mfd driver, all second level irq chips
are chained to the respective first level irqs. So there is no
need for explicitly unmasking the first level irq in this
driver. This patches removes this level 1 irq unmask support.
Signed-off-by: Ku
From: Kuppuswamy Sathyanarayanan
PMIC mfd driver only exports first level irq for GPIO device.
But currently we are reading the irqs from the second level irq
chip, So this patch fixes this issue by adding support to use
first level PMIC GPIO irq.
Signed-off-by: Kuppuswamy Sathyanarayanan
---
From: Kuppuswamy Sathyanarayanan
Currently all PMIC GPIO domain irqs are consumed by the same
device(bxt_wcove_gpio), so there is no need to export them as
separate interrupts. We can just export only the first level
GPIO irq(BXTWC_GPIO_LVL1_IRQ) as an irq resource and let the
GPIO device driver(
Hello,
One of our CRIU tests hangs with this patch.
Steps to reproduce:
curl -o cgroupns.c
https://gist.githubusercontent.com/avagin/f87c8a8bd2a0de9afcc74976327786bc/raw/5843701ef3679f50dd2427cf57a80871082eb28c/gistfile1.txt
gcc cgroupns.c -o cgroupns
./cgroupns
./cgroupns
[root@fc24 ~]# strace
Ard Biesheuvel wrote:
> That does bring me to another EFI related point: many of these patches
> are x86 specific for no good reason.
Note that the sysrq one is awkward since the key chosen *is* arch-specific.
SysRq+x can't be arbitrarily assigned to this since some other arches have
their own u
On Sat, Apr 15, 2017 at 12:45:30AM +0200, Rafael Wysocki wrote:
> On Wednesday, April 12, 2017 04:08:54 PM Darren Hart wrote:
> > Hi All,
> >
> > There are a few parallel efforts involving the Windows Management
> > Instrumentation (WMI)[1] and dependent/related drivers. I'd like to have a
> > ro
On 04/14/17 15:39, Vincent Legoll wrote:
> Hello Randy,
>
> you mean like the following ?
>
> Looks like this is working as intended and much simpler, thanks.
>
Yes, like that. Thanks.
--
~Randy
Hi Mel,
Thanks for the "how to" information.
This is a very interesting use case.
>From trace data, I see a lot of minimal durations with
virtually no load on the CPU, typically more consistent
with some type of light duty periodic (~~100 Hz) work flow
(where we would prefer to not ramp up frequen
Thomas Gleixner wrote:
> > -module_param_named(irq, timer_irq, int, 0644);
> > +module_param_hw_named(irq, timer_irq, int, irq, 0644);
> > MODULE_PARM_DESC(irq, "Which IRQ to use for the clock source MFGPT
> > ticks.");
>
> I'm not sure about this. AFAIR the parameter is required to work on
>
On Tuesday, April 11, 2017 12:20:41 AM Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Make the schedutil governor take the initial (default) value of the
> rate_limit_us sysfs attribute from the (new) transition_delay_us
> policy parameter (to be set by the scaling driver).
>
> That will
On Monday, April 10, 2017 02:51:35 PM Viresh Kumar wrote:
> Compiling the DT file with W=1, DTC warns like follows:
>
> Warning (unit_address_vs_reg): Node /opp_table0/opp@10 has a
> unit name, but no reg property
>
> Fix this by replacing '@' with '-' as the OPP nodes will never have a
>
On Wednesday, April 12, 2017 04:08:54 PM Darren Hart wrote:
> Hi All,
>
> There are a few parallel efforts involving the Windows Management
> Instrumentation (WMI)[1] and dependent/related drivers. I'd like to have a
> round of
> discussion among those of you that have been involved in this space
The driver does not check if mapping dma memory succeed.
The patch adds the checks and failure handling.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov
---
drivers/net/ethernet/natsemi/ns83820.c | 13 +++--
1 file changed, 11 insertions(
On Fri, Apr 14, 2017 at 03:52:23PM +0800, Jason Wang wrote:
>
>
> On 2017年04月12日 16:03, Jason Wang wrote:
> >
> >
> > On 2017年04月07日 13:49, Michael S. Tsirkin wrote:
> > > A known weakness in ptr_ring design is that it does not handle well the
> > > situation when ring is almost full: as entrie
Add a MAINTAINERS block for the FUTEX SUBSYSTEM which includes the core
kernel code, include headers, testing code, and Documentation. Excludes
arch files, and higher level test code.
I added tglx and mingo as M as they have made the tip commits and peterz
and myself as R.
Signed-off-by: Darren H
On 03/29/2017 06:39 AM, Shanker Donthineni wrote:
The optional _PXM method evaluates to an integer that identifies the
proximity domain of a device object. On ACPI based kernel boot, the
field numa_node in 'struct device' is always set to -1 irrespective
of _PXM value that is specified in the AC
No need to get into the submenu to disable all FPGA-related config entries
Signed-off-by: Vincent Legoll
---
drivers/fpga/Kconfig | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
index ce861a2..2cb9b81 100644
--- a/drivers/fpga/
1 - 100 of 514 matches
Mail list logo
