* Mike Travis wrote:
> --- linux.orig/arch/x86/kernel/apic/x2apic_uv_x.c
> +++ linux/arch/x86/kernel/apic/x2apic_uv_x.c
> @@ -1529,6 +1529,8 @@ void __init uv_system_init(void)
> uv_system_init_hub();
>
> /* Initialize UV hubless system here */
> + else
> +
On 13/01/17 22:54, Sebastian Hesselbarth wrote:
> On 13.01.2017 10:12, Chris Packham wrote:
>> From: Kalyan Kinthada
>>
>> This pinctrl driver supports the 98DX3236, 98DX3336 and 98DX4251 SoCs
>> from Marvell.
>>
>> Signed-off-by: Kalyan Kinthada
>> Signed-off-by: Chris Packham
>> Acked-by: Rob
Hi Jaegeuk,
On 2017/1/13 6:44, Jaegeuk Kim wrote:
This patch adds stat information for flush and discard commands.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/debug.c | 7 +--
fs/f2fs/f2fs.h| 3 ++-
fs/f2fs/segment.c | 4
3 files changed, 11 insertions(+), 3 deletions(-)
diff --git
On Fri, Jan 13, 2017 at 09:00:34PM +0100, Manuel Schölling wrote:
> On Tue, 2017-01-10 at 23:58 +0100, Adam Borowski wrote:
> > On Tue, Jan 10, 2017 at 10:28:38PM +0100, Manuel Schölling wrote:
> > > The impact of the persistent scrollback feature on the code size is
> > > rather small, so the conf
On Fri, Jan 13, 2017 at 12:19:08PM -0800, Guenter Roeck wrote:
> On Fri, Jan 13, 2017 at 12:38:17PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.43 release.
> > There are 27 patches in this series, all will be posted as a response
> > to this one. I
On Fri, Jan 13, 2017 at 12:20:20PM -0800, Guenter Roeck wrote:
> On Fri, Jan 13, 2017 at 01:01:07PM +0100, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.4 release.
> > There are 59 patches in this series, all will be posted as a response
> > to this one. If
On Fri, Jan 13, 2017 at 02:58:09PM -0700, Shuah Khan wrote:
> On 01/13/2017 05:01 AM, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.9.4 release.
> > There are 59 patches in this series, all will be posted as a response
> > to this one. If anyone has any issue
This patch adds dt-binding documentation for zx2967 family
reset controller.
Signed-off-by: Baoyou Xie
---
.../devicetree/bindings/reset/zte,zx2967-reset.txt | 20
1 file changed, 20 insertions(+)
create mode 100644 Documentation/devicetree/bindings/reset/zte,zx2967-reset
Add the zx2967 reset controller driver as maintained by ARM ZTE
architecture maintainers, as they're parts of the core IP.
Signed-off-by: Baoyou Xie
---
MAINTAINERS | 2 ++
1 file changed, 2 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 2793808..08f8155 100644
--- a/MAINTAINERS
+++
This patch adds reset controller driver for ZTE's zx2967 family.
Signed-off-by: Baoyou Xie
---
drivers/reset/Kconfig| 6 ++
drivers/reset/Makefile | 1 +
drivers/reset/reset-zx2967.c | 136 +++
3 files changed, 143 insertions(+)
create m
On Fri, Jan 13, 2017 at 06:24:22PM +0100, SF Markus Elfring wrote:
> From: Markus Elfring
> Date: Fri, 13 Jan 2017 16:16:05 +0100
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> The script "checkpatch.pl" pointed information out like the followi
On (01/13/17 14:15), Petr Mladek wrote:
> Some console drivers code calls console_conditional_schedule()
> that looks at @console_may_schedule. The value must be cleared
> when the drivers are called from console_unlock() with
> interrupts disabled. But rescheduling is fine when the same
> code is
Guenter Roeck writes:
> Use device managed functions to simplify error handling, reduce
> source code size, improve readability, and reduce the likelyhood of bugs.
> Other improvements as listed below.
>
> The conversion was done automatically with coccinelle using the
> following semantic patche
With kmem cgroup support enabled, kmem_caches can be created and
destroyed frequently and a great number of near empty kmem_caches can
accumulate if there are a lot of transient cgroups and the system is
not under memory pressure. When memory reclaim starts under such
conditions, it can lead to co
With kmem cgroup support enabled, kmem_caches can be created and
destroyed frequently and a great number of near empty kmem_caches can
accumulate if there are a lot of transient cgroups and the system is
not under memory pressure. When memory reclaim starts under such
conditions, it can lead to co
With kmem cgroup support enabled, kmem_caches can be created and
destroyed frequently and a great number of near empty kmem_caches can
accumulate if there are a lot of transient cgroups and the system is
not under memory pressure. When memory reclaim starts under such
conditions, it can lead to co
shutdown_memcg_caches() shuts down all memcg caches associated with a
root cache. It first walks the index table clearing and shutting down
each entry and then shuts down the ones on
root_cache->memcg_params.list. As active caches are on both the table
and the list, they're stashed away from the
With kmem cgroup support enabled, kmem_caches can be created and
destroyed frequently and a great number of near empty kmem_caches can
accumulate if there are a lot of transient cgroups and the system is
not under memory pressure. When memory reclaim starts under such
conditions, it can lead to co
With kmem cgroup support enabled, kmem_caches can be created and
destroyed frequently and a great number of near empty kmem_caches can
accumulate if there are a lot of transient cgroups and the system is
not under memory pressure. When memory reclaim starts under such
conditions, it can lead to co
__kmem_cache_shrink() is called with %true @deactivate only for memcg
caches. Remove @deactivate from __kmem_cache_shrink() and introduce
__kmemcg_cache_deactivate() instead. Each memcg-supporting allocator
should implement it and it should deactivate and drain the cache.
This is to allow memcg
We're gonna change how memcg caches are iterated. In preparation,
clean up and reorganize memcg_cache_params.
* The shared ->list is replaced by ->children in root and
->children_node in children.
* ->is_root_cache is removed. Instead ->root_cache is moved out of
the child union and now use
This reverts commit 89e364db71fb5e7fc8d93228152abfa67daf35fa.
With kmem cgroup support enabled, kmem_caches can be created and
destroyed frequently and a great number of near empty kmem_caches can
accumulate if there are a lot of transient cgroups and the system is
not under memory pressure. When
With kmem cgroup support enabled, kmem_caches can be created and
destroyed frequently and a great number of near empty kmem_caches can
accumulate if there are a lot of transient cgroups and the system is
not under memory pressure. When memory reclaim starts under such
conditions, it can lead to co
On 01/13/2017 03:15 PM, Florian Fainelli wrote:
On 01/13/2017 08:38 AM, Andy Shevchenko wrote:
On Wed, Jan 11, 2017 at 11:26 PM, Florian Fainelli wrote:
From: Guenter Roeck
This patch adds support for the IMS (now Zodiac Inflight Innovations)
SCU Generation 1/2/3 platform driver. This driver
Add variable for checking channel idle state to ensure that dma descriptor is
not
Submitted when DMA engine is in progress.
This will avoids the pollling for a bit in the status register to know
Dma state in the driver hot path.
Reviewed-by: Jose Abreu
Signed-off-by: Kedareswara rao Appana
---
This patch series fixes below bugs in DMA and VDMA IP's
---> Do not start VDMA until frame buffer is processed by the h/w
---> Fix bug in Multi frame sotres handling in VDMA
---> Fix issues w.r.to multi frame descriptors submit with AXI DMA S2MM(recv)
Side.
Kedareswara rao Appana (3):
dmaengine
When VDMA is configured for more than one frame in the h/w.
For example h/w is configured for n number of frames, user
Submits n number of frames and triggered the DMA using issue_pending API.
In the current driver flow we are submitting one frame at a time,
But we should submit all the n number o
As per AXI DMA spec the software must not move the tail pointer to a location
That has not been updated (next descriptor field of the h/w descriptor
Should always point to a valid address).
When user submits multiple descriptors on the recv side, with the
Current driver flow the last buffer descri
On Sat, 14 Jan 2017 13:20:00 +0900
Namhyung Kim wrote:
> But I'm not sure how to synchronize hash table manipulations. It
> seems synchronize_sched() is not good enough for function graph
> tracer, right? So I limited changing filter size only when no tracer
> is used, but is it ok to have the
This patch is to reduce the lock contention of swap_info_struct->lock
via using a more fine grained lock in swap_cluster_info for some swap
operations. swap_info_struct->lock is heavily contended if multiple
processes reclaim pages simultaneously. Because there is only one lock
for each swap devi
Hi Wei,
On 2017/1/13 22:11, Wei Xu wrote:
> Hi Hanjun,
>
> On 2017/1/11 15:06, Hanjun Guo wrote:
>> With platform msi support landed in the kernel, and the introduction
>> of IORT for GICv3 ITS (PCI MSI) and SMMU, the framework for platform msi
>> is ready, this patch set add few patches to enable
Hi Steve,
On Fri, Jan 13, 2017 at 11:16:18AM -0500, Steven Rostedt wrote:
> On Fri, 13 Jan 2017 13:22:43 +0900
> Namhyung Kim wrote:
>
> > It's currently fixed to 32 and it ignores when user gives a pattern
> > which match to functions more than the size. So filtering like all
> > system calls
Hi Lorenzo,
On 2017/1/13 20:11, Lorenzo Pieralisi wrote:
> On Wed, Jan 11, 2017 at 11:06:33PM +0800, Hanjun Guo wrote:
>> For devices connecting to ITS, it needs dev id to identify itself, and
>> this dev id is represented in the IORT table in named component node
>> [1] for platform devices, so i
On Thu 12.Jan'17 at 17:33:38 +0100, Oliver Hartkopp wrote:
On 01/12/2017 02:01 PM, Eric Dumazet wrote:
On Thu, 2017-01-12 at 09:22 +0100, Oliver Hartkopp wrote:
But my main concern is:
The reason why can_rx_delete_receiver() was introduced was the need to
remove a huge number of receivers wi
On Fri, 13 Jan 2017 13:32:58 -0800, Jakub Kicinski wrote:
> If one requests a FW which does not exist in the FS and the user space
> helper is used then fw_load_abort() will be called twice which leads to
> NULL-deref.
>
> It will be called once in firmware_loading_store() (handling the -1
> case)
On 2017/1/13 19:47, Lorenzo Pieralisi wrote:
> On Wed, Jan 11, 2017 at 11:06:32PM +0800, Hanjun Guo wrote:
>> iort_node_map_rid() was designed for both PCI and platform
>> device, but the rid means requester id is for ITS mappings,
> I do not understand what this means sorry.
>
>> rename iort_node_
On 2017/1/13 18:45, Lorenzo Pieralisi wrote:
> On Wed, Jan 11, 2017 at 11:06:36PM +0800, Hanjun Guo wrote:
>> platform_msi_create_device_domain() is used to ctreate
>> irqdomain for the device such as irqchip mbigen generating
>> the MSIs, it's almost ready for ACPI use except
>> of_node_to_fwnode(
Hi Lorenzo,
On 2017/1/13 18:21, Lorenzo Pieralisi wrote:
> On Wed, Jan 11, 2017 at 11:06:39PM +0800, Hanjun Guo wrote:
>> With the preparation of platform msi support and interrupt producer
>> in DSDT, we can add mbigen ACPI support now.
>>
>> We are using _PRS methd to indicate number of irq pins
On 2017/01/13 2:29, Michal Hocko wrote:
> Ilya has noticed that I've screwed up some k[zc]alloc conversions and
> didn't use the kvzalloc. This is an updated patch with some acks
> collected on the way
> ---
> From a7b89c6d0a3c685045e37740c8f97b065f37e0a4 Mon Sep 17 00:00:00 2001
> From: Michal Hoc
On 1/13/17 18:49, Borislav Petkov wrote:
On Fri, Jan 13, 2017 at 05:24:01PM +0700, Suravee Suthikulpanit wrote:
IIUC, Perf tools looks at the /sys/devices/x to identify
availalble PMUs. Are you planning to have perf tools look at
/sys/devices/system/iommu/xxx instead?
No, I'm planning to
On Tue, Jan 10, 2017 at 4:04 PM, Pavel Machek wrote:
> Hi!
>
>> +MODULE_AUTHOR("Rob Herring
> Missing ">".
Actually, this I should drop because this driver can not be a module.
The bus can be though.
Rob
On Thu, Jan 12, 2017 at 12:29 PM, Sudeep Holla wrote:
> It is useful to have helper function just to get the number of cache
> levels for a given logical cpu. We can obtain the same by just checking
> the level at which the last cache is present. This patch adds support
> to find the level of the
On 2017/01/13 0:37, Michal Hocko wrote:
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index 5dc34653274a..105cd04c7414 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -797,12 +797,9 @@ static int vhost_net_open(struct inode *inode, struct
> file *f)
> struct
On Fri, Jan 13, 2017 at 2:28 PM, Dave Gerlach wrote:
> On 01/13/2017 01:25 PM, Rob Herring wrote:
>>
>> On Thu, Jan 12, 2017 at 9:27 AM, Dave Gerlach wrote:
>>>
>>> Rob,
>>>
>>> On 01/11/2017 03:34 PM, Rob Herring wrote:
On Mon, Jan 9, 2017 at 11:57 AM, Dave Gerlach wrote:
>
>
Hi Jaegeuk Kim,
On 2017/1/13 6:44, Jaegeuk Kim wrote:
This patch adds stat information for flush and discard commands.
Signed-off-by: Jaegeuk Kim
---
fs/f2fs/debug.c | 7 +--
fs/f2fs/f2fs.h| 3 ++-
fs/f2fs/segment.c | 4
3 files changed, 11 insertions(+), 3 deletions(-)
diff -
Marvell folks tell me this is a debugging event that the driver doesn't
need to handle, but on 8997 w/ firmware 16.68.1.p97, I see several of
these sorts of messages at (for instance) boot time:
[ 13.825848] mwifiex_pcie :01:00.0: event: unknown event id: 0x63
[ 14.838561] mwifiex_pcie 000
> -Original Message-
> From: Bart Van Assche [mailto:bart.vanass...@sandisk.com]
> Sent: Friday, January 13, 2017 5:00 PM
> To: Estrin, Alex ; dledf...@redhat.com
> Cc: linux-kernel@vger.kernel.org; linux-r...@vger.kernel.org;
> gre...@linuxfoundation.org
> Subject: Re: [PATCH v2 00/26] I
On Fri, Jan 13, 2017 at 05:46:34PM -0800, Linus Torvalds wrote:
> On Fri, Jan 13, 2017 at 5:24 PM, Al Viro wrote:
> >
> > Why would advance by 0 change ->iov_offset here?
>
> That's not my worry. Advancing by zero obviously doesn't change the position.
>
> But the _truncation_ of the rest requir
On Fri, Jan 13, 2017 at 5:24 PM, Al Viro wrote:
>
> Why would advance by 0 change ->iov_offset here?
That's not my worry. Advancing by zero obviously doesn't change the position.
But the _truncation_ of the rest requires iov_offset to be zero in
order to actually truncate everything.
So I was w
On Sat, Jan 14, 2017 at 01:24:28AM +, Al Viro wrote:
> On Fri, Jan 13, 2017 at 04:59:37PM -0800, Linus Torvalds wrote:
>
> > EXCEPT.
> >
> > I don't think "i->iov_offset" is actually correct. If you truncated
> > the whole thing, you should have cleared iov_offset too, and that
> > never happ
From: Tiantian Feng
We need to disable VMX on all CPUs before stop cpu when OS panic,
otherwisewe risk hanging up the machine, because the CPU ignore INIT
signals when VMX is enabled. In kernel mainline this issue existence.
Signed-off-by: Tiantian Feng
---
arch/x86/kernel/smp.c | 3 +++
1 fil
On 2017/1/14 9:36, Xishi Qiu wrote:
> From: Tiantian Feng
>
> We need to disable VMX on all CPUs before stop cpu when OS panic, otherwisewe
> risk hanging up the machine, because the CPU ignore INIT signals when VMX is
> enabled.
> In kernel mainline this issue existence.
>
> Signed-off-by: Ti
From: Tiantian Feng
We need to disable VMX on all CPUs before stop cpu when OS panic, otherwisewe
risk hanging up the machine, because the CPU ignore INIT signals when VMX is
enabled.
In kernel mainline this issue existence.
Signed-off-by: Tiantian Feng
---
arch/x86/kernel/smp.c | 2 ++
1 fil
ping...
On 2017/1/12 17:32, Zhou Chengming wrote:
After online an offline cpu, cpu_hw_events.excl_thread_id will always be
set to 1 in intel_pmu_cpu_starting() even when its sibling's excl_thread_id
is also 1. Then the two siblings will use the same state in their shared
hw_hw_events.excl_cntrs,
On Fri, Jan 13, 2017 at 04:59:37PM -0800, Linus Torvalds wrote:
> EXCEPT.
>
> I don't think "i->iov_offset" is actually correct. If you truncated
> the whole thing, you should have cleared iov_offset too, and that
> never happened. So truncating everything will not empty the buffers
> for us, we'
From: Vivien Didelot
Date: Thu, 12 Jan 2017 18:07:16 -0500
> The Marvell 6352 chip has a 8-bit address/16-bit data EEPROM access.
> The Marvell 6390 chip has a 16-bit address/8-bit data EEPROM access.
>
> This patch implements the 8-bit data EEPROM access in the mv88e6xxx
> driver and adds its s
The region set by the call to memset, immediately overwritten by
the subsequent call to memcpy and thus makes the memset redundant.
Also remove the memset((&info, 0, sizeof(info)) on line 398 because
info is memcpy()'ed to before being used in the loop and it isn't
used outside of the loop.
Sign
On Fri, 2017-01-13 at 14:23 -0700, Jason Gunthorpe wrote:
> On Fri, Jan 13, 2017 at 12:02:36PM -0800, James Bottomley wrote:
> > > > Actually, no, the devrm is a completely lifetime managed device
> > > > as part of the chip structure. once you've done a device_del
> > > > on it, it can be kfree
Hi Ming,
On 2017/1/13 18:23, Ming Lei wrote:
> On Wed, Jan 11, 2017 at 11:06 PM, Hanjun Guo wrote:
>> With platform msi support landed in the kernel, and the introduction
>> of IORT for GICv3 ITS (PCI MSI) and SMMU, the framework for platform msi
>> is ready, this patch set add few patches to ena
On Fri, Jan 13, 2017 at 2:50 PM, Al Viro wrote:
>
> Or, even better, we can get rid of all wraparound-related crap if we
> calculate the final value of pipe->nrbufs and watch for _that_ as
> loop condition:
Ok, I like the 'expected nrbufs' approach. It makes the actual freeing
loop trivial, and g
On Fri, Jan 13, 2017 at 04:57:14PM +0100, Tobias Klauser wrote:
> On 2017-01-13 at 10:52:49 +0100, Shyam Saini wrote:
> > The region set by the call to memset, immediately overwritten by the
> > subsequent call to memcpy and thus makes the memset redundant
> >
> > Signed-off-by: Shyam Saini
> >
On Fri, Jan 13, 2017 at 05:28:57PM -0700, Jason Gunthorpe wrote:
> On Fri, Jan 13, 2017 at 04:09:54PM -0800, Andrey Pronin wrote:
> > Resetting TPM while processing a command may lead to issues
> > on the next boot. Ensure that we don't have any ongoing
> > commands, and that no further commands ca
On Fri, Jan 13, 2017 at 04:09:54PM -0800, Andrey Pronin wrote:
> Resetting TPM while processing a command may lead to issues
> on the next boot. Ensure that we don't have any ongoing
> commands, and that no further commands can be sent to the chip
> by unregistering the device in the shutdown handl
Hi,
I submitted https://marc.info/?l=linux-kernel&m=147343473231192&w=2
a while ago and it was suggested postponing any discussion until
after ksummit
(https://lists.linuxfoundation.org/pipermail/ksummit-discuss/2016-September/003829.html)
Did any discussion/hacking end up happening? There's inte
This plugin, ported from PaX, instruments C function call sites (and
returns) to set the high bit of the instruction pointer to force any
attempts to execute userspace memory into the faulting non-canonical
address range. This can be thought of as a weak form of SMEP emulation.
For function pointe
Resetting TPM while processing a command may lead to issues
on the next boot. Ensure that we don't have any ongoing
commands, and that no further commands can be sent to the chip
by unregistering the device in the shutdown handler.
tpm_chip_unregister() waits for the completion of an ongoing
comman
Update USB/IP driver location in README.
Signed-off-by: Shuah Khan
---
tools/usb/usbip/README | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/usb/usbip/README b/tools/usb/usbip/README
index 831f49f..f349ef4 100644
--- a/tools/usb/usbip/README
+++ b/tools/usb/usbip/READM
In mwifiex_delay_for_sleep_cookie(), we're looping and waiting for the
PCIe endpoint to write a magic value back to memory, to signal that it
has finished going to sleep. We're not letting the compiler know that
this might change underneath our feet though. Let's do that, for good
hygiene.
I'm not
Depending on system factors (e.g., the PCIe link PM state), the first
read to wake up the Wifi firmware can take a long time. There is no
reason to use a (blocking, non-posted) read at this point, so let's just
use a write instead. Write vs. read doesn't matter functionality-wise --
it's just a dum
The following sequence occurs when using IEEE power-save on 8997:
(a) driver sees SLEEP event
(b) driver issues SLEEP CONFIRM
(c) driver recevies CMD interrupt; within the interrupt processing loop,
we do (d) and (e):
(d) wait for FW sleep cookie (and often time out; it takes a while), FW
i
On Fri, 13 Jan 2017 23:09:58 + "Kani, Toshimitsu"
wrote:
> On Fri, 2017-01-13 at 14:54 -0800, Andrew Morton wrote:
> > On Fri, 13 Jan 2017 16:34:18 -0700 Toshi Kani
> > wrote:
> >
> > > DAX IO path does not support iostat, but its metadata IO path does.
> > > Therefore, iostat shows metada
On 01/13/2017 08:38 AM, Andy Shevchenko wrote:
> On Wed, Jan 11, 2017 at 11:26 PM, Florian Fainelli
> wrote:
>> From: Guenter Roeck
>>
>> This patch adds support for the IMS (now Zodiac Inflight Innovations)
>> SCU Generation 1/2/3 platform driver. This driver registers all the
>> on-module peri
On 01/13/2017 04:05 AM, Philipp Zabel wrote:
Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
This adds a header file for use by userspace programs wanting to interact
with the i.MX media driver. It defines custom v4l2 controls and events
generated by the i.MX v4l2 subdevices.
On 01/13/2017 10:22 AM, Darren Hart wrote:
>> Btw, Darren, would it be good idea to start creating folders to make a
>> bit of order in the subsystem? For first I would move Intel's PMIC/SCU
>> stuff to somewhere (not sure if it should be per manufacturer or per
>> function).
>
> If we create fold
On 01/13/2017 04:03 AM, Philipp Zabel wrote:
Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor.
Both hang off the same i2c2 bus, so they require different (and non-
default) i2c slave addresses.
The OV564
On Fri, 2017-01-13 at 14:54 -0800, Andrew Morton wrote:
> On Fri, 13 Jan 2017 16:34:18 -0700 Toshi Kani
> wrote:
>
> > DAX IO path does not support iostat, but its metadata IO path does.
> > Therefore, iostat shows metadata IO statistics only, which has been
> > confusing to users.
> >
> > Add i
On 01/11/2017 07:19 PM, Andy Lutomirski wrote:
On Wed, Jan 11, 2017 at 1:09 AM, Daniel Borkmann wrote:
[...]
Ok. Sleeping over this a bit, how about a general rename into
"prog_tag" for fdinfo and TCA_BPF_TAG resp. TCA_ACT_BPF_TAG for
the netlink attributes, fwiw, it might reduce any assumptio
On Wed, 11 Jan 2017 09:41:52 +
Eric Auger wrote:
> When attaching a group to the container, check the group's
> reserved regions and test whether the IOMMU translates MSI
> transactions. If yes, we initialize an IOVA allocator through
> the iommu_get_msi_cookie API. This will allow the MSI IO
On Wed, 11 Jan 2017 09:41:53 +
Eric Auger wrote:
> In case the IOMMU translates MSI transactions (typical case
> on ARM), we check MSI remapping capability at IRQ domain
> level. Otherwise it is checked at IOMMU level.
>
> At this stage the arm-smmu-(v3) still advertise the
> IOMMU_CAP_INTR_
On Fri, 13 Jan 2017 16:34:18 -0700 Toshi Kani wrote:
> DAX IO path does not support iostat, but its metadata IO path does.
> Therefore, iostat shows metadata IO statistics only, which has been
> confusing to users.
>
> Add iostat support to the DAX read/write path.
>
> Note, iostat still does n
On Thu, Jan 12, 2017 at 01:02:32PM -0800, Brian Norris wrote:
> Wifi modules like 8997 don't support the "sleep cookie", and so most of
> the time, we just time out in the mwifiex_delay_for_sleep_cookie()
> function ("max count reached while accessing sleep cookie"). This is a
> waste of time, and
host->dma_addr can store a value that is not returned by the DMA API,
so it is safer to check if is a valid DMA address indirectly.
Signed-off-by: Alexey Khoroshilov
---
drivers/mmc/host/wbsd.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/mmc/host/wbsd.c b/d
On Fri, Jan 13, 2017 at 10:13:08PM +, Al Viro wrote:
> On Fri, Jan 13, 2017 at 09:59:19PM +, Al Viro wrote:
> > + if (off) {
> > + pipe->bufs[idx].len = off - pipe->bufs[idx].offset;
> > + /* free all after idx; n can't be 0 */
>
> Yes, it can
On Thu, Jan 12, 2017 at 01:02:31PM -0800, Brian Norris wrote:
> Depending on system factors (e.g., the PCIe link PM state), the first
> read to wake up the Wifi firmware can take a long time. There is no
> reason to use a (blocking, non-posted) read at this point, so let's just
> use a write instea
Based on feedback, Fedora is a popular distribution for people who like
to build their own kernels. To make this easier, add a set of
reasonablly common config options for Fedora.
fedora-core.config contains a base set of options that should work on a
standard fedora system. fedora-fs.config and f
On 01/13/2017 03:57 AM, Philipp Zabel wrote:
Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
Add to the MIPI CSI2 receiver node: compatible string, interrupt sources,
clocks.
Signed-off-by: Steve Longerbeam
---
arch/arm/boot/dts/imx6qdl.dtsi | 7 +++
1 file changed,
On Fri, Dec 30, 2016 at 05:02:10PM +0530, Ritesh Harjani wrote:
> From: Sahitya Tummala
>
> Implement ->platform_dumpregs host operation to print the
> platform specific registers in addition to standard SDHC
> register during error conditions.
>
> Signed-off-by: Sahitya Tummala
> Signed-off-by
DAX IO path does not support iostat, but its metadata IO path does.
Therefore, iostat shows metadata IO statistics only, which has been
confusing to users.
Add iostat support to the DAX read/write path.
Note, iostat still does not support the DAX mmap path as it allows
user applications to access
On 01/13/2017 06:11 AM, Andrew Lunn wrote:
>> static int _dsa_register_switch(struct dsa_switch *ds, struct device *dev)
>> {
>> +struct dsa_chip_data *pdata = dev->platform_data;
>> struct device_node *np = dev->of_node;
>> struct dsa_switch_tree *dst;
>> struct device_node *p
On 01/13/2017 06:04 AM, Andrew Lunn wrote:
>> index cd91070b5467..d326fc4afad7 100644
>> --- a/net/dsa/dsa2.c
>> +++ b/net/dsa/dsa2.c
>> @@ -81,17 +81,23 @@ static void dsa_dst_del_ds(struct dsa_switch_tree *dst,
>>
>> static bool dsa_port_is_valid(struct dsa_port *port)
>> {
>> -return !!p
On 01/12/2017 11:36 PM, Viresh Kumar wrote:
> Hi,
>
> This patchset adds support for cpufreq selftests to the kernel selftest
> framework. More details can be found on individual patches.
>
> These are all tested after installation of selftests on ARM Dual A15
> core Exynos platform.
>
> The con
On Fri, Jan 13, 2017 at 03:07:51PM -0500, Dan Streetman wrote:
> Revert the main part of commit:
> af42b8d12f8a ("xen: fix MSI setup and teardown for PV on HVM guests")
>
> That commit introduced reading the pci device's msi message data to see
> if a pirq was previously configured for the device'
On Fri, Jan 13, 2017 at 4:53 AM, Bard Liao wrote:
>> +static const struct acpi_gpio_mapping byt_rt5660_gpios[] = {
>> + { "audio-wake-intr-gpios", &audio_wake_intr_gpio, 1 },
>> + { "lineout-mute-gpios", &lineout_mute_gpio, 1 },
>> + { NULL },
>> +};
>> +
>
> I am thinking if it is mor
On Thu, 2017-01-12 at 10:39 +0100, Torvald Riegel wrote:
> On Sat, 2016-12-24 at 17:01 +0100, Torvald Riegel wrote:
> > === Robust mutexes have bugs, in both glibc and the kernel
> >
> > I've been reviewing the implementation of robust mutexes in both glibc
> > and the kernel support code recently
>>> @@ -402,9 +403,16 @@ int sg_alloc_table_from_pages(struct sg_table *sgt,
>>>
>>> /* compute number of contiguous chunks */
>>> chunks = 1;
>>> - for (i = 1; i < n_pages; ++i)
>>> - if (page_to_pfn(pages[i]) != page_to_pfn(pages[i - 1]) +
>>> 1)
>>> + se
On Fri, Dec 30, 2016 at 05:02:09PM +0530, Ritesh Harjani wrote:
> From: Sahitya Tummala
>
> Add new host operation ->platform_dumpregs to provide a
> mechanism through which host drivers can dump platform
> specific registers in addition to SDHC registers
> during error conditions.
>
> Signed-of
Now that PASS_INFO() exists, use it in the other existing gcc plugins,
instead of always open coding the same thing.
Based on updates to the grsecurity/PaX gcc plugins.
Signed-off-by: Kees Cook
---
scripts/gcc-plugins/cyc_complexity_plugin.c | 6 +-
scripts/gcc-plugins/sancov_plugin.c
On Fri, Jan 13, 2017 at 09:59:19PM +, Al Viro wrote:
> + if (off) {
> + pipe->bufs[idx].len = off - pipe->bufs[idx].offset;
> + /* free all after idx; n can't be 0 */
Yes, it can - full pipe, truncation to the part of the first buffer ;-/
OTO
On Wed, Jan 11, 2017 at 11:18:13PM +1030, Jonathan Woithe wrote:
> On Wed, Jan 11, 2017 at 01:26:49PM +0100, Micha?? K??pie?? wrote:
> > > On Wed, Jan 11, 2017 at 09:59:29AM +0100, Micha?? K??pie?? wrote:
> > > > I am currently preparing a patch series which makes fujitsu-laptop use a
> > > > spars
On 01/13/2017 04:38 AM, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.4.43 release.
> There are 27 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 sh
1 - 100 of 805 matches
Mail list logo
