Re: [PATCH] Staging:greybus:arche-apb-ctrl: fix trailing */ Block comments and 80 character line limit coding style issue

[Joe Perches]

On Fri, 2016-10-07 at 13:23 -0700, Nadim Almas wrote:
> Fixed coding style issue
> diff --git a/drivers/staging/greybus/arche-apb-ctrl.c 
> b/drivers/staging/greybus/arche-apb-ctrl.c
[]
> @@ -168,7 +168,10 @@ static int standby_boot_seq(struct platform_device *pdev)
>   if (apb->init_disabled)
>   return 0;
>  
> - /* Even if it is in OFF state, then we do not want to change the state 
> */
> + /*
> +  *Even if it is in OFF state,
> +  *then we do not want to change the state
> +  */

block comments use a space after the leading *

/*
 * Even if it is in the OFF state,
 * then we do not want to change the state
 */

[PATCH net-next] nfnetlink_log: Use GFP_NOWARN for skb allocation

[Calvin Owens]

Since the code explicilty falls back to a smaller allocation when the
large one fails, we shouldn't complain when that happens.

Signed-off-by: Calvin Owens 
---
 net/netfilter/nfnetlink_log.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/netfilter/nfnetlink_log.c b/net/netfilter/nfnetlink_log.c
index eb086a1..7435505 100644
--- a/net/netfilter/nfnetlink_log.c
+++ b/net/netfilter/nfnetlink_log.c
@@ -330,7 +330,7 @@ nfulnl_alloc_skb(struct net *net, u32 peer_portid, unsigned 
int inst_size,
 * message.  WARNING: has to be <= 128k due to slab restrictions */
 
n = max(inst_size, pkt_size);
-   skb = alloc_skb(n, GFP_ATOMIC);
+   skb = alloc_skb(n, GFP_ATOMIC | __GFP_NOWARN);
if (!skb) {
if (n > pkt_size) {
/* try to allocate only as much as we need for current
-- 
2.9.3

Re: [PATCH] fs: Assert on module file_operations without an owner

[Calvin Owens]

On Friday 10/07 at 21:48 +0100, Al Viro wrote:
> On Fri, Oct 07, 2016 at 01:35:52PM -0700, Calvin Owens wrote:
> > Omitting the owner field in file_operations declared in modules is an
> > easy mistake to make, and can result in crashes when the module is
> > unloaded while userspace is poking the file.
> > 
> > This patch modifies fops_get() to WARN when it encounters a NULL owner,
> > since in this case it cannot take a reference on the containing module.
> 
> NAK.  This is complete crap - we do *NOT* need ->owner on a lot of
> file_operations.

This isn't a theoretical issue: I have a proprietary module that makes this
mistake and crashes when poking a chrdev it exposes in userspace races with
unloading the module.

Of course, the bug is in this silly module. I'm not arguing that it isn't. I
was hesitant to even mention this because I know waving at something in an OOT
module is a poor argument for changing anything in the proper kernel.

But what I'm trying to do here is prevent people from making that mistake in
the future by yelling at them when they do. The implicit ignoring of a NULL
owner in try_module_get() in fops_get() is not necessarily obvious.

>   * we do not need that on file_operations of a regular file or
> directory on a normal filesystem, since that filesystem is not going
> away until the file has been closed - ->f_path.mnt is holding a reference
> to vfsmount, which is holding a reference to superblock, which is holding
> a reference to file_system_type, which is holding a reference to _its_
> ->owner.
>   * we do not need that on anything on procfs - module removal is
> legal while a procfs file is opened; its cleanup will be blocked for the
> duration of ->read(), ->write(), etc. calls.

I see why this is true, and it's something I considered. But when there is
zero cost to being explicit and setting ->owner, why not do it?

> If anything, we would be better off with modifications that would get
> rid of ->owner on file_operations.  It's not trivial to do, but it might
> be not impossible.

[PATCH V3 01/10] acpi: apei: read ack upon ghes record consumption

[Tyler Baicar]

A RAS (Reliability, Availability, Serviceability) controller
may be a separate processor running in parallel with OS
execution, and may generate error records for consumption by
the OS. If the RAS controller produces multiple error records,
then they may be overwritten before the OS has consumed them.

The Generic Hardware Error Source (GHES) v2 structure
introduces the capability for the OS to acknowledge the
consumption of the error record generated by the RAS
controller. A RAS controller supporting GHESv2 shall wait for
the acknowledgment before writing a new error record, thus
eliminating the race condition.

Signed-off-by: Jonathan (Zhixiong) Zhang 
Signed-off-by: Richard Ruigrok 
Signed-off-by: Tyler Baicar 
Signed-off-by: Naveen Kaje 
---
 drivers/acpi/apei/ghes.c | 41 +
 drivers/acpi/apei/hest.c |  7 +--
 include/acpi/ghes.h  |  1 +
 3 files changed, 47 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 60746ef..3021f0e 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -45,6 +45,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -244,10 +245,22 @@ static struct ghes *ghes_new(struct acpi_hest_generic 
*generic)
struct ghes *ghes;
unsigned int error_block_length;
int rc;
+   struct acpi_hest_header *hest_hdr;
 
ghes = kzalloc(sizeof(*ghes), GFP_KERNEL);
if (!ghes)
return ERR_PTR(-ENOMEM);
+
+   hest_hdr = (struct acpi_hest_header *)generic;
+   if (hest_hdr->type == ACPI_HEST_TYPE_GENERIC_ERROR_V2) {
+   ghes->generic_v2 = (struct acpi_hest_generic_v2 *)generic;
+   rc = apei_map_generic_address(
+   >generic_v2->read_ack_register);
+   if (rc)
+   goto err_unmap;
+   } else
+   ghes->generic_v2 = NULL;
+
ghes->generic = generic;
rc = apei_map_generic_address(>error_status_address);
if (rc)
@@ -270,6 +283,9 @@ static struct ghes *ghes_new(struct acpi_hest_generic 
*generic)
 
 err_unmap:
apei_unmap_generic_address(>error_status_address);
+   if (ghes->generic_v2)
+   apei_unmap_generic_address(
+   >generic_v2->read_ack_register);
 err_free:
kfree(ghes);
return ERR_PTR(rc);
@@ -279,6 +295,9 @@ static void ghes_fini(struct ghes *ghes)
 {
kfree(ghes->estatus);
apei_unmap_generic_address(>generic->error_status_address);
+   if (ghes->generic_v2)
+   apei_unmap_generic_address(
+   >generic_v2->read_ack_register);
 }
 
 static inline int ghes_severity(int severity)
@@ -648,6 +667,22 @@ static void ghes_estatus_cache_add(
rcu_read_unlock();
 }
 
+static int ghes_do_read_ack(struct acpi_hest_generic_v2 *generic_v2)
+{
+   int rc;
+   u64 val = 0;
+
+   rc = apei_read(, _v2->read_ack_register);
+   if (rc)
+   return rc;
+   val &= generic_v2->read_ack_preserve <<
+   generic_v2->read_ack_register.bit_offset;
+   val |= generic_v2->read_ack_write;
+   rc = apei_write(val, _v2->read_ack_register);
+
+   return rc;
+}
+
 static int ghes_proc(struct ghes *ghes)
 {
int rc;
@@ -660,6 +695,12 @@ static int ghes_proc(struct ghes *ghes)
ghes_estatus_cache_add(ghes->generic, ghes->estatus);
}
ghes_do_proc(ghes, ghes->estatus);
+
+   if (ghes->generic_v2) {
+   rc = ghes_do_read_ack(ghes->generic_v2);
+   if (rc)
+   return rc;
+   }
 out:
ghes_clear_estatus(ghes);
return 0;
diff --git a/drivers/acpi/apei/hest.c b/drivers/acpi/apei/hest.c
index 792a0d9..ef725a9 100644
--- a/drivers/acpi/apei/hest.c
+++ b/drivers/acpi/apei/hest.c
@@ -52,6 +52,7 @@ static const int hest_esrc_len_tab[ACPI_HEST_TYPE_RESERVED] = 
{
[ACPI_HEST_TYPE_AER_ENDPOINT] = sizeof(struct acpi_hest_aer),
[ACPI_HEST_TYPE_AER_BRIDGE] = sizeof(struct acpi_hest_aer_bridge),
[ACPI_HEST_TYPE_GENERIC_ERROR] = sizeof(struct acpi_hest_generic),
+   [ACPI_HEST_TYPE_GENERIC_ERROR_V2] = sizeof(struct acpi_hest_generic_v2),
 };
 
 static int hest_esrc_len(struct acpi_hest_header *hest_hdr)
@@ -146,7 +147,8 @@ static int __init hest_parse_ghes_count(struct 
acpi_hest_header *hest_hdr, void
 {
int *count = data;
 
-   if (hest_hdr->type == ACPI_HEST_TYPE_GENERIC_ERROR)
+   if (hest_hdr->type == ACPI_HEST_TYPE_GENERIC_ERROR ||
+   hest_hdr->type == ACPI_HEST_TYPE_GENERIC_ERROR_V2)
(*count)++;
return 0;
 }
@@ -157,7 +159,8 @@ static int __init hest_parse_ghes(struct acpi_hest_header 
*hest_hdr, void *data)
struct ghes_arr *ghes_arr = data;
int rc, i;
 
-   if 

[PATCH V3 00/10] Add UEFI 2.6 and ACPI 6.1 updates for RAS on ARM64

[Tyler Baicar]

When a memory error, CPU error, PCIe error, or other type of hardware error
that's covered by RAS occurs, firmware should populate the shared GHES memory
location with the proper GHES structures to notify the OS of the error.
For example, platforms that implement firmware first handling may implement
separate GHES sources for corrected errors and uncorrected errors. If the
error is an uncorrectable error, then the firmware will notify the OS
immediately since the error needs to be handled ASAP. The OS will then be able
to take the appropriate action needed such as offlining a page. If the error
is a corrected error, then the firmware will not interrupt the OS immediately.
Instead, the OS will see and report the error the next time it's GHES timer
expires. The kernel will first parse the GHES structures and report the errors
through the kernel logs and then notify the user space through RAS trace
events. This allows user space applications such as RAS Daemon to see the
errors and report them however the user desires. This patchset extends the
kernel functionality for RAS errors based on updates in the UEFI 2.6 and
ACPI 6.1 specifications.

An example flow from firmware to user space could be:

 +---+
   +>|   |
   | |  GHES polling |--+
+-+  |source |  |   +---+   ++
| |  +---+  |   |  Kernel GHES  |   ||
|  Firmware   | +-->|  CPER AER and |-->|  RAS trace |
| |  +---+  |   |  EDAC drivers |   |   event|
+-+  |   |  |   +---+   ++
   | |  GHES sci |--+
   +>|   source  |
 +---+

Add support for Generic Hardware Error Source (GHES) v2, which introduces the
capability for the OS to acknowledge the consumption of the error record
generated by the Reliability, Availability and Serviceability (RAS) controller.
This eliminates potential race conditions between the OS and the RAS controller.

Add support for the timestamp field added to the Generic Error Data Entry v3,
allowing the OS to log the time that the error is generated by the firmware,
rather than the time the error is consumed. This improves the correctness of
event sequences when analyzing error logs. The timestamp is added in
ACPI 6.1, reference Table 18-343 Generic Error Data Entry.

Add support for ARMv8 Common Platform Error Record (CPER) per UEFI 2.6
specification. ARMv8 specific processor error information is reported as part of
the CPER records.  This provides more detail on for processor error logs. This
can help describe ARMv8 cache, tlb, and bus errors.

Synchronous External Abort (SEA) represents a specific processor error condition
in ARM systems. A handler is added to recognize SEA errors, and a notifier is
added to parse and report the errors before the process is killed. Refer to
section N.2.1.1 in the Common Platform Error Record appendix of the UEFI 2.6
specification.

Currently the kernel ignores CPER records that are unrecognized.
On the other hand, UEFI spec allows for non-standard (eg. vendor
proprietary) error section type in CPER (Common Platform Error Record),
as defined in section N2.3 of UEFI version 2.5. Therefore, user
is not able to see hardware error data of non-standard section.

If section Type field of Generic Error Data Entry is unrecognized,
prints out the raw data in dmesg buffer, and also adds a tracepoint
for reporting such hardware errors.

Currently even if an error status block's severity is fatal, the kernel
does not honor the severity level and panic. With the firmware first
model, the platform could inform the OS about a fatal hardware error
through the non-NMI GHES notification type. The OS should panic when a
hardware error record is received with this severity.

Add support to handle SEAs that occur while a KVM guest kernel is
running. Currently these are unsupported by the guest abort handling.

Depends on: [PATCH v14] acpi, apei, arm64: APEI initial support for aarch64.
https://lkml.org/lkml/2016/8/10/231

V3: Fix unmapped address to the read_ack_register in ghes.c
Add helper function to get the proper payload based on generic data entry
 version
Move timestamp print to avoid changing function calls in cper.c
Remove patch "arm64: exception: handle instruction abort at current EL"
 since the el1_ia handler is already added in 4.8
Add EFI and ARM64 dependencies for HAVE_ACPI_APEI_SEA
Add a new trace event for ARM type errors
Add support to handle KVM guest SEAs

V2: Add PSCI state print for the ARMv8 error type.
Separate timestamp year into year and century using BCD format.
Rebase on top of ACPICA 20160318 release and remove header file changes
 in include/acpi/actbl1.h.
Add panic OS with fatal error status block patch.
Add processing of 

Re: [PATCH] ARC: [build] Support gz, lzma compressed uImage

[Vineet Gupta]

On 10/04/2016 04:34 PM, Daniel Mentz wrote:
> Add support for lzma compressed uImage.
> 
> Support for gzip was already available but could not be enabled because
> we were missing CONFIG_HAVE_KERNEL_GZIP in arch/arc/Kconfig.
> 
> Signed-off-by: Daniel Mentz 
> Cc: linux-snps-...@lists.infradead.org
> Cc: Vineet Gupta 

Applied to for-curr.

Thx Daniel
-Vineet

Re: [PATCH 00/14] libnvdimm: support sub-divisions of pmem for 4.9

[Linda Knippers]

On 10/7/2016 3:52 PM, Dan Williams wrote:
> On Fri, Oct 7, 2016 at 11:19 AM, Linda Knippers  
> wrote:
>> Hi Dan,
>>
>> A couple of general questions...
>>
>> On 10/7/2016 12:38 PM, Dan Williams wrote:
>>> With the arrival of the device-dax facility in 4.7 a pmem namespace can
>>> now be configured into a total of four distinct modes: 'raw', 'sector',
>>> 'memory', and 'dax'. Where raw, sector, and memory are block device
>>> modes and dax supports the device-dax character device. With that degree
>>> of freedom in the use cases it is overly restrictive to continue the
>>> current limit of only one pmem namespace per-region, or "interleave-set"
>>> in ACPI 6+ terminology.
>>
>> If I understand correctly, at least some of the restrictions were
>> part of the Intel NVDIMM Namespace spec rather than ACPI/NFIT restrictions.
>> The most recent namespace spec on pmem.io hasn't been updated to remove
>> those restrictions.  Is there a different public spec?
> 
> Yes, this is Linux specific and use of this capability needs to be
> cognizant that it could create a configuration that is not understood
> by EFI, or other OSes (including older Linux implementations).  I plan
> to add documentation to ndctl along these lines.  This is similar to
> the current situation with 'pfn' and 'dax' info blocks that are also
> Linux specific.  However, I should note that this implementation
> changes none of the interpretation of the fields nor layout of the
> existing label specification.  It simply allows two pmem labels that
> happen to appear in the same region to result in two namespaces rather
> than 0.

Ok, but the namespace spec says that's not allowed.  It seemed like an odd
restriction to be in the label spec but it is there.
> 
>>> This series adds support for reading and writing configurations that
>>> describe multiple pmem allocations within a region.  The new rules for
>>> allocating / validating the available capacity when blk and pmem regions
>>> alias are (quoting space_valid()):
>>>
>>>BLK-space is valid as long as it does not precede a PMEM
>>>allocation in a given region. PMEM-space must be contiguous
>>>and adjacent to an existing existing allocation (if one
>>>exists).
>>
>> Why is this new rule necessary?  Is this a HW-specific rule or something
>> related to how Linux could possibly support something?  Why do we care
>> whether blk-space is before or after pmem-space? If it's a HW-specific
>> rule, then shouldn't the enforcement be in the management tool that
>> configures the namespaces?
> 
> It is not HW specific, and it's not new in the sense that we already
> arrange for pmem to be allocated from low addresses and blk to be
> allocated from high addresses.  

Who's the "we"?  Does the location within the region come from the OS
or from the tool that created the namespace?  (I should probably know
this but not having labels, I've never looked at this.)

If we're relaxing some of the rules, it seems like one could have
pmem, then block, then free space, and later want to use free space
for another pmem range.  If hardware supported it and the management
tool created it, would the kernel allow it?

> If another implementation violated
> this constraint Linux would parse it just fine. The constraint is a
> Linux decision to maximize available pmem capacity when blk and pmem
> alias.  So this is a situation where Linux is liberal in what it will
> accept when reading labels, but conservative on the configurations it
> will create when writing labels.

Is it ndctl that's being conservative?  It seems like the kernel shouldn't care.
> 
>>> Where "adjacent" allocations grow an existing namespace.  Note that
>>> growing a namespace is potentially destructive if free space is consumed
>>> from a location preceding the current allocation.  There is no support
>>> for dis-continuity within a given namespace allocation.
>>
>> Are you talking about DPAs here?
> 
> No, this is referring to system-physical-address partitioning.
> 
>>> Previously, since there was only one namespace per-region, the resulting
>>> pmem device would be named after the region.  Now, subsequent namespaces
>>> after the first are named with the region index and a
>>> "." suffix. For example:
>>>
>>>   /dev/pmem0.1
>>
>> According to the existing namespace spec, you can already have multiple
>> block namespaces on a device. I've not see a system with block namespaces
>> so what do those /dev entries look like?  (The dots are somewhat 
>> unattractive.)
> 
> Block namespaces result in devices with names like "/dev/ndblk0.0"
> where the X.Y numbers are ..  This new
> naming for pmem devices is following that precedent.  The "dot" was
> originally adopted from Linux USB device naming.

Does this mean that if someone updates their kernel then their /dev/pmem0
becomes /dev/pmem0.0?  Or do you only get the dot if there is more
than one namespace per region?

-- ljk


> 

Re: [PATCH] [media] vb2: move dma-buf unmap from __vb2_dqbuf() to vb2_buffer_done()

[Sakari Ailus]

Hi Javier,

On Tue, Aug 16, 2016 at 05:26:31PM -0400, Javier Martinez Canillas wrote:
> Hello Sakari,
> 
> On 08/16/2016 05:13 PM, Sakari Ailus wrote:
> > Hi Javier,
> > 
> > Javier Martinez Canillas wrote:
> >> Hello Sakari,
> >>
> >> On 08/16/2016 04:47 PM, Sakari Ailus wrote:
> >>> Hi Javier,
> >>>
> >>> Javier Martinez Canillas wrote:
>  Hello Hans,
> 
>  Thanks a lot for your feedback.
> 
>  On 08/13/2016 09:47 AM, Hans Verkuil wrote:
> > On 07/20/2016 08:22 PM, Javier Martinez Canillas wrote:
> >> Currently the dma-buf is unmapped when the buffer is dequeued by 
> >> userspace
> >> but it's not used anymore after the driver finished processing the 
> >> buffer.
> >>
> >> So instead of doing the dma-buf unmapping in __vb2_dqbuf(), it can be 
> >> made
> >> in vb2_buffer_done() after the driver notified that buf processing is 
> >> done.
> >>
> >> Decoupling the buffer dequeue from the dma-buf unmapping has also the 
> >> side
> >> effect of making possible to add dma-buf fence support in the future 
> >> since
> >> the buffer could be dequeued even before the driver has finished using 
> >> it.
> >>
> >> Signed-off-by: Javier Martinez Canillas 
> >>
> >> ---
> >> Hello,
> >>
> >> I've tested this patch doing DMA buffer sharing between a
> >> vivid input and output device with both v4l2-ctl and gst:
> >>
> >> $ v4l2-ctl -d0 -e1 --stream-dmabuf --stream-out-mmap
> >> $ v4l2-ctl -d0 -e1 --stream-mmap --stream-out-dmabuf
> >> $ gst-launch-1.0 v4l2src device=/dev/video0 io-mode=dmabuf ! v4l2sink 
> >> device=/dev/video1 io-mode=dmabuf-import
> >>
> >> And I didn't find any issues but more testing will be appreciated.
> >>
> >> Best regards,
> >> Javier
> >>
> >>  drivers/media/v4l2-core/videobuf2-core.c | 34 
> >> +---
> >>  1 file changed, 22 insertions(+), 12 deletions(-)
> >>
> >> diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
> >> b/drivers/media/v4l2-core/videobuf2-core.c
> >> index 7128b09810be..973331efaf79 100644
> >> --- a/drivers/media/v4l2-core/videobuf2-core.c
> >> +++ b/drivers/media/v4l2-core/videobuf2-core.c
> >> @@ -958,6 +958,22 @@ void *vb2_plane_cookie(struct vb2_buffer *vb, 
> >> unsigned int plane_no)
> >>  EXPORT_SYMBOL_GPL(vb2_plane_cookie);
> >>  
> >>  /**
> >> + * __vb2_unmap_dmabuf() - unmap dma-buf attached to buffer planes
> >> + */
> >> +static void __vb2_unmap_dmabuf(struct vb2_buffer *vb)
> >> +{
> >> +  int i;
> >> +
> >> +  for (i = 0; i < vb->num_planes; ++i) {
> >> +  if (!vb->planes[i].dbuf_mapped)
> >> +  continue;
> >> +  call_void_memop(vb, unmap_dmabuf,
> >> +  vb->planes[i].mem_priv);
> >
> > Does unmap_dmabuf work in interrupt context? Since vb2_buffer_done can 
> > be called from
> > an irq handler this is a concern.
> >
> 
>  Good point, I believe it shouldn't be called from atomic context since 
>  both
>  the dma_buf_vunmap() and dma_buf_unmap_attachment() functions can sleep.
>   
> > That said, vb2_buffer_done already calls call_void_memop(vb, finish, 
> > vb->planes[plane].mem_priv);
> > to sync buffers, and that can take a long time as well. So it is not a 
> > good idea to
> > have this in vb2_buffer_done.
> >
> 
>  I see.
> 
> > What I would like to see is to have vb2 handle this finish() call and 
> > the vb2_unmap_dmabuf
> > in some workthread or equivalent.
> >
> > It would complicate matters somewhat in vb2, but it would simplify 
> > drivers since these
> > actions would not longer take place in interrupt context.
> >
> > I think this patch makes sense, but I would prefer that this is moved 
> > out of the interrupt
> > context.
> >
> 
>  Ok, I can take a look to this and handle the finish() and unmap_dmabuf()
>  out of interrupt context as you suggested.
> >>>
> >>> I have a patch doing the former which is a part of my cache management
> >>> fix patchset:
> >>>
> >>> 
> >>> 
> >>>
> >>
> >> Interesting, thanks for the links.
> >>  
> >>> There were a few drivers doing nasty things with memory that I couldn't
> >>> quite fix back then. Just FYI.
> >>>
> >>
> >> Did you mean that there were issues with moving finish mem op call to 
> >> DQBUF?
> >>
> >> Do you recall what these drivers were or what were doing that caused 
> >> problems?
> > 
> > Not any particular drivers --- the problem is that flushing the cache
> 
> 

Re: [GIT PULL] trivial for 4.9

[Joe Perches]

On Fri, 2016-10-07 at 14:06 -0700, Linus Torvalds wrote:
> And btw, even without an explicit KERN_, you should still not
> get any interleaving. Only an _explicit_ KERN_CONT should cause
> interleaving, and dammit, if some interrupt does a KERN_CONT without
> having had a non-cont printk before it, that code is buggy and should
> damn well be fixed.

That's not true.  KERN_CONT is a no-op.
Bare printks interleave.

$ git grep KERN_CONT include/linux/kern_levels.h
include/linux/kern_levels.h:#define KERN_CONT   ""

I think it was like 2007 when I first suggested _not_ having
newlines on the pr_ macros that were eventually added
by Emil Medve.

Re: md-cluster: Delete unnecessary braces in unlock_all_bitmaps()

[walter harms]

Am 07.10.2016 10:37, schrieb SF Markus Elfring:
>>> Do not use curly brackets at one source code place
>>> where a single statement should be sufficient.
>>
>> The original style was correct and this is wrong.  I have explained this 
>> before.
> 
> Did I change a bit too much in the proposed step according to the following
> update suggestion?
> 
> elfring@Sonne:~/Projekte/Linux/next-patched> git checkout 
> d6385db94196b253ae5eb3678fa95cdf1f839fcc && scripts/checkpatch.pl --types 
> BRACES -f drivers/md/md-cluster.c
> …
> WARNING: braces {} are not necessary for single statement blocks
> #1228: FILE: drivers/md/md-cluster.c:1228:
> + if (cinfo->other_bitmap_lockres[i]) {
> + lockres_free(cinfo->other_bitmap_lockres[i]);
> + }
> …
> 
> 
> How do you think about to adjust this source code place a bit?
> 

perhaps we can agree to delete the if() block ?

static void lockres_free(struct dlm_lock_resource *res)
{
int ret;

   if (!res)
return;




@marcus: is can not send mail to you sf.net adresse because sf.net
 mark my domain als spam (note: nobody else does)

re,
 wh

Re: scripts/coccicheck: Update for a comment?

[SF Markus Elfring]

> Do I overlook any commit for the discussed source file anyhow?
> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/log/dev-tools/coccinelle.rst

It seems that I missed this file also because an other path will be appropriate.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/log/Documentation/dev-tools/coccinelle.rst

Regards,
Markus

Re: Bogus "APIC: NR_CPUS/possible_cpus limit of 4 reached" messages

[Markus Trippelsdorf]

On 2016.10.06 at 13:52 +0200, Markus Trippelsdorf wrote:
> On 2016.10.06 at 12:48 +0100, One Thousand Gnomes wrote:
> > On Thu, 6 Oct 2016 13:27:37 +0200
> > Markus Trippelsdorf  wrote:
> > 
> > > On current trunk I get during boot:
> > > 
> > > [0.00] APIC: NR_CPUS/possible_cpus limit of 4 reached.  Processor 
> > > 4/0x84 ignored.
> > > [0.00] APIC: NR_CPUS/possible_cpus limit of 4 reached.  Processor 
> > > 5/0x85 ignored.
> > > 
> > > I don't think these messages make much sense on a 4-core machine.
> > > 
> > 
> > Four cores with or without hyperthreading ?
> 
> Without. This is a rather old AMD machine (AMD Phenom II X4 955).

CCing more people.

-- 
Markus

[tip:x86/urgent] arch/x86: Handle non enumerated CPU after physical hotplug

[tip-bot for Prarit Bhargava]

Commit-ID:  2a51fe083eba7f99cbda72f5ef90cdf2f4df882c
Gitweb: http://git.kernel.org/tip/2a51fe083eba7f99cbda72f5ef90cdf2f4df882c
Author: Prarit Bhargava 
AuthorDate: Mon, 3 Oct 2016 13:07:12 -0400
Committer:  Thomas Gleixner 
CommitDate: Fri, 7 Oct 2016 15:22:15 +0200

arch/x86: Handle non enumerated CPU after physical hotplug

When a CPU is physically added to a system then the MADT table is not
updated.

If subsequently a kdump kernel is started on that physically added CPU then
the ACPI enumeration fails to provide the information for this CPU which is
now the boot CPU of the kdump kernel.

As a consequence, generic_processor_info() is not invoked for that CPU so
the number of enumerated processors is 0 and none of the initializations,
including the logical package id management, are performed.

We have code which relies on the correctness of the logical package map and
other information which is initialized via generic_processor_info().
Executing such code will result in undefined behaviour or kernel crashes.

This problem applies only to the kdump kernel because a normal kexec will
switch to the original boot CPU, which is enumerated in MADT, before
jumping into the kexec kernel.

The boot code already has a check for num_processors equal 0 in
prefill_possible_map(). We can use that check as an indicator that the
enumeration of the boot CPU did not happen and invoke generic_processor_info()
for it. That initializes the relevant data for the boot CPU and therefore
prevents subsequent failure.

[ tglx: Refined the code and rewrote the changelog ]

Signed-off-by: Prarit Bhargava 
Fixes: 1f12e32f4cd5 ("x86/topology: Create logical package id")
Cc: Peter Zijlstra 
Cc: Len Brown 
Cc: Borislav Petkov 
Cc: Andi Kleen 
Cc: Jiri Olsa 
Cc: Juergen Gross 
Cc: dyo...@redhat.com
Cc: Eric Biederman 
Cc: ke...@lists.infradead.org
Link: 
http://lkml.kernel.org/r/1475514432-27682-1-git-send-email-pra...@redhat.com
Signed-off-by: Thomas Gleixner 

---
 arch/x86/kernel/smpboot.c | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c
index 42a9362..951f093 100644
--- a/arch/x86/kernel/smpboot.c
+++ b/arch/x86/kernel/smpboot.c
@@ -1407,9 +1407,21 @@ __init void prefill_possible_map(void)
 {
int i, possible;
 
-   /* no processor from mptable or madt */
-   if (!num_processors)
-   num_processors = 1;
+   /* No boot processor was found in mptable or ACPI MADT */
+   if (!num_processors) {
+   int apicid = boot_cpu_physical_apicid;
+   int cpu = hard_smp_processor_id();
+
+   pr_warn("Boot CPU (id %d) not listed by BIOS\n", cpu);
+
+   /* Make sure boot cpu is enumerated */
+   if (apic->cpu_present_to_apicid(0) == BAD_APICID &&
+   apic->apic_id_valid(apicid))
+   generic_processor_info(apicid, boot_cpu_apic_version);
+
+   if (!num_processors)
+   num_processors = 1;
+   }
 
i = setup_max_cpus ?: 1;
if (setup_possible_cpus == -1) {

Re: [RESEND PATCH v2 -next 0/3] ARM64: amlogic: Add support for GXL SoC Family

[Kevin Hilman]

Neil Armstrong  writes:

> This is a resend rebased on linux-next-20161004 tag.
>
> The new Amlogic GXL SoCs (S905X and S905D) are part of the Meson GX family and
> share some common features that can be described in a common GX dtsi file used
> by the Meson GXBB and Meson GXL Family dtsi.
>
> This patchset introduces the common GX dtsi and switches the GXBB to use
> the common GX dtsi.
> Then it introduces the GXL S905X SoC with the GXL common dtsi, then the S905D
> dtsi and the p212 board dts.
> Finally the GXL S905D SoC is introduced with a S905D dtsi using the GXL common
> and the p23x Board dtsi for the p231 and p230 development boards.
>
> Changes since v1 at 
> http://lkml.kernel.org/r/20160903082227.30559-1-narmstr...@baylibre.com :
>  - Add missing copyrigh in gx dtsi
>  - Rename gxl SoCs compatibles to amlogic,s905x and amlogic,s905d
>
> Changes since RFC v1:
>  - Merge GX common and GXBB changes in a single patch
>  - Integrate GXL S905X patch
>  - Add support for S905D and the p23x boards
>
> Note: This patchset integrates the patch "ARM64: dts: amlogic: Add basic 
> support for Amlogic S905X" [1]
> from Carlo Caione.

I'm applying this series as the first DT change for v4.10, so all future
DT patches should be applied on top of this.

It's available in the v4.10/dt64 branch of my tree[1].

Kevin

[1] https://git.kernel.org/cgit/linux/kernel/git/khilman/linux-amlogic.git

Re: [patch 14/32] greybus: LED driver

[Pavel Machek]

On Fri 2016-09-16 16:10:14, Greg KH wrote:
> 
> This driver implements the Greybus LED protocol.

I guess this should be copied to LED mainainters?

Havingstandartized phone hardware to work would be great. Is it
possible to get device using this?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: xrandr fails after resume from hibernation in kernels 4.7.4 and 4.8.0

[Gaston Gonzalez]

On Wed, Oct 05, 2016 at 07:23:23AM +0200, Greg KH wrote:
> On Tue, Oct 04, 2016 at 08:43:03PM -0300, Gaston Gonzalez wrote:
> > Hi,
> > 
> > After hibernation I get the following error when I tried to connect to 
> > monitor
> > through hdmi:
> > 
> > $ xrandr --output LVDS1 --off  --output  HDMI1 --auto
> > xrandr: Configure crtc 1 failed
> > 
> > This does not happen in kernel in kernel v4.6.7 but do happen in kernels 
> > v4.7.4
> > and v4.8.0
> 
> Ah, can you use 'git bisect' to track down the offending patch?
> 
> Also, if you let the graphics driver authors know, they are probably the
> best ones to help out with this, not the "generic" stable mailing list.
> 
> thanks,
> 
> greg k-h

Hello,

The culprit commit seems to be:

commit: ed4a6a7
drm/i915: Add two-stage ILK-style watermark programming

Attached the bisection log.

Let me know if additional test or bisect is needed.

Best regards,

Gaston
git bisect start '--' 'drivers/gpu/drm/'
# good: [096998b11906dd79df5af4d688c9974342dd09f2] Linux 4.6.7
git bisect good 096998b11906dd79df5af4d688c9974342dd09f2
# bad: [c8d2bc9bc39ebea8437fd974fdbc21847bb897a3] Linux 4.8
git bisect bad c8d2bc9bc39ebea8437fd974fdbc21847bb897a3
# good: [2dcd0af568b0cf583645c8a317dd12e344b1c72a] Linux 4.6
git bisect good 2dcd0af568b0cf583645c8a317dd12e344b1c72a
# bad: [3c85f20a289d044f303f473ee6ab7502303fc3b0] Merge tag 'omapdrm-4.8' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next
git bisect bad 3c85f20a289d044f303f473ee6ab7502303fc3b0
# bad: [a64424d722504926f3375bc4887976e3bfe3a01d] Merge branch 'drm-next-4.7' 
of git://people.freedesktop.org/~agd5f/linux into drm-next
git bisect bad a64424d722504926f3375bc4887976e3bfe3a01d
# bad: [b5bf0f1ea3658254bd72ef64abc97786e8a32255] drm/exynos: clean up register 
definions for fimd and decon
git bisect bad b5bf0f1ea3658254bd72ef64abc97786e8a32255
# bad: [27878ede4fec7b929c3010710ba4d55c617c621d] drm/i915: Throw out BUGs from 
DPLL/PCH functions
git bisect bad 27878ede4fec7b929c3010710ba4d55c617c621d
# bad: [72341af4285ae1337c0dfdfa3e68318b52b8757c] drm/i915: hide away VBT 
private data in a separate header
git bisect bad 72341af4285ae1337c0dfdfa3e68318b52b8757c
# bad: [71f0a626143368b8aead361ffaff7e36d043fd8e] drm/i915: Only use sanitized 
values for ILK watermarks
git bisect bad 71f0a626143368b8aead361ffaff7e36d043fd8e
# bad: [66e2c4c39cc37beaccc24c9d14c75d627fce9cf4] drm/i915/gen9: Disable DC 
states if power well support is disabled
git bisect bad 66e2c4c39cc37beaccc24c9d14c75d627fce9cf4
# bad: [4f2d9934bd6ac73950832c96b385822846670668] drm/i915: Pass drm_frambuffer 
to intel_compute_page_offset()
git bisect bad 4f2d9934bd6ac73950832c96b385822846670668
# bad: [1d5bf5d9d9ef0c1e639d36178a224d83888c5a29] drm/i915: Add missing NULL 
check before calling initial_watermarks
git bisect bad 1d5bf5d9d9ef0c1e639d36178a224d83888c5a29
# bad: [d9f8e52b22454a30aaaf26b7ef029598b30abf8e] drm/i915: remove dead code
git bisect bad d9f8e52b22454a30aaaf26b7ef029598b30abf8e
# bad: [c3454d575da162cd310d9b83696baefb29d10a70] drm/i915: remove left over 
dead code
git bisect bad c3454d575da162cd310d9b83696baefb29d10a70
# bad: [ed4a6a7ca853253f9b86f3005d76345482a71283] drm/i915: Add two-stage 
ILK-style watermark programming (v11)
git bisect bad ed4a6a7ca853253f9b86f3005d76345482a71283
# first bad commit: [ed4a6a7ca853253f9b86f3005d76345482a71283] drm/i915: Add 
two-stage ILK-style watermark programming (v11)

Re: [patch 14/32] greybus: LED driver

[Greg KH]

On Fri, Oct 07, 2016 at 03:36:56PM +0200, Pavel Machek wrote:
> On Fri 2016-09-16 16:10:14, Greg KH wrote:
> > 
> > This driver implements the Greybus LED protocol.
> 
> I guess this should be copied to LED mainainters?

It will when it comes out of the staging directory.

> Havingstandartized phone hardware to work would be great. Is it
> possible to get device using this?

Yes, Motorolla ships a phone with this hardware in it.

thanks,

greg k-h

Re: [patch 12/32] greybus: es2 host driver

[Pavel Machek]

On Fri 2016-09-16 15:25:25, Greg KH wrote:
> This is a Greybus host driver for the ES2/3 bridge chip from Toshiba.
> 
> Signed-off-by: Greg Kroah-Hartman 
> ---

> +/*
> + * @endpoint: bulk in endpoint for CPort data
> + * @urb: array of urbs for the CPort in messages
> + * @buffer: array of buffers for the @cport_in_urb urbs
> + */
> +struct es2_cport_in {
> + __u8 endpoint;
> + struct urb *urb[NUM_CPORT_IN_URB];
> + u8 *buffer[NUM_CPORT_IN_URB];

Underscored versions of __u8 and friends are unneccessary here... as
shown later in the struct. Makes sense to fix in whole file.
pavel


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v2 0/2] ARM64: meson-gxbb: Add support for the Nexbox A95X Board

[Kevin Hilman]

Neil Armstrong  writes:

> Add support for the Amlogic S905 (GXBB) version of the Nexbox A95X, an IPTV
> set-top-box with Ethernet, SDCard, eMMC, USB, HDMI, IR, Led, Reset button and 
> Audio Jack.
>
> Changes since v1 at: 
> http://lkml.kernel.org/r/1471951370-29269-1-git-send-email-narmstr...@baylibre.com
>  - Rebase on linux-next-20161004 with patchset [1]
>  - Add nexbox vendor prefix
>
> [1] 
> http://lkml.kernel.org/r/1475595430-30075-1-git-send-email-narmstr...@baylibre.com
>
> Neil Armstrong (2):
>   devicetree: Add vendor prefix for Nexbox
>   ARM: dts: meson-gxbb: Add support for the Nexbox A95X Board

Applied to v4.10/dt64 branch,

Kevin

[PATCH V3 1/3] perf intel-pt/bts: Tidy instruction buffer size usage

[Adrian Hunter]

Tidy instruction buffer size usage in preparation for copying the
instruction bytes onto samples.

The instruction buffer is presently used for debugging, so rename its size
macro from INTEL_PT_INSN_DBG_BUF_SZ to INTEL_PT_INSN_BUF_SZ, and use it
everywhere.

Note that the maximum instruction size is 15 which is a less efficient size
to copy than 16, which is why a separate buffer size is used.

Signed-off-by: Adrian Hunter 
---
 tools/perf/util/intel-bts.c  |  8 +++-
 tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.c | 13 ++---
 tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.h |  6 ++
 tools/perf/util/intel-pt-decoder/intel-pt-log.c  |  4 ++--
 tools/perf/util/intel-pt.c   |  8 +++-
 5 files changed, 16 insertions(+), 23 deletions(-)

diff --git a/tools/perf/util/intel-bts.c b/tools/perf/util/intel-bts.c
index f545ec1e758a..8bc7fec817d7 100644
--- a/tools/perf/util/intel-bts.c
+++ b/tools/perf/util/intel-bts.c
@@ -319,15 +319,12 @@ static int intel_bts_get_next_insn(struct intel_bts_queue 
*btsq, u64 ip)
struct machine *machine = btsq->bts->machine;
struct thread *thread;
struct addr_location al;
-   unsigned char buf[1024];
-   size_t bufsz;
+   unsigned char buf[INTEL_PT_INSN_BUF_SZ];
ssize_t len;
int x86_64;
uint8_t cpumode;
int err = -1;
 
-   bufsz = intel_pt_insn_max_size();
-
if (machine__kernel_ip(machine, ip))
cpumode = PERF_RECORD_MISC_KERNEL;
else
@@ -341,7 +338,8 @@ static int intel_bts_get_next_insn(struct intel_bts_queue 
*btsq, u64 ip)
if (!al.map || !al.map->dso)
goto out_put;
 
-   len = dso__data_read_addr(al.map->dso, al.map, machine, ip, buf, bufsz);
+   len = dso__data_read_addr(al.map->dso, al.map, machine, ip, buf,
+ INTEL_PT_INSN_BUF_SZ);
if (len <= 0)
goto out_put;
 
diff --git a/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.c 
b/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.c
index d23138c06665..5f95cd442075 100644
--- a/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.c
+++ b/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.c
@@ -27,6 +27,10 @@
 
 #include "intel-pt-insn-decoder.h"
 
+#if INTEL_PT_INSN_BUF_SZ < MAX_INSN_SIZE
+#error Instruction buffer size too small
+#endif
+
 /* Based on branch_type() from perf_event_intel_lbr.c */
 static void intel_pt_insn_decoder(struct insn *insn,
  struct intel_pt_insn *intel_pt_insn)
@@ -166,10 +170,10 @@ int intel_pt_get_insn(const unsigned char *buf, size_t 
len, int x86_64,
if (!insn_complete() || insn.length > len)
return -1;
intel_pt_insn_decoder(, intel_pt_insn);
-   if (insn.length < INTEL_PT_INSN_DBG_BUF_SZ)
+   if (insn.length < INTEL_PT_INSN_BUF_SZ)
memcpy(intel_pt_insn->buf, buf, insn.length);
else
-   memcpy(intel_pt_insn->buf, buf, INTEL_PT_INSN_DBG_BUF_SZ);
+   memcpy(intel_pt_insn->buf, buf, INTEL_PT_INSN_BUF_SZ);
return 0;
 }
 
@@ -211,11 +215,6 @@ int intel_pt_insn_desc(const struct intel_pt_insn 
*intel_pt_insn, char *buf,
return 0;
 }
 
-size_t intel_pt_insn_max_size(void)
-{
-   return MAX_INSN_SIZE;
-}
-
 int intel_pt_insn_type(enum intel_pt_insn_op op)
 {
switch (op) {
diff --git a/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.h 
b/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.h
index b0adbf37323e..37ec5627ae9b 100644
--- a/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.h
+++ b/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.h
@@ -20,7 +20,7 @@
 #include 
 
 #define INTEL_PT_INSN_DESC_MAX 32
-#define INTEL_PT_INSN_DBG_BUF_SZ   16
+#define INTEL_PT_INSN_BUF_SZ   16
 
 enum intel_pt_insn_op {
INTEL_PT_OP_OTHER,
@@ -47,7 +47,7 @@ struct intel_pt_insn {
enum intel_pt_insn_branch   branch;
int length;
int32_t rel;
-   unsigned char   buf[INTEL_PT_INSN_DBG_BUF_SZ];
+   unsigned char   buf[INTEL_PT_INSN_BUF_SZ];
 };
 
 int intel_pt_get_insn(const unsigned char *buf, size_t len, int x86_64,
@@ -58,8 +58,6 @@ const char *intel_pt_insn_name(enum intel_pt_insn_op op);
 int intel_pt_insn_desc(const struct intel_pt_insn *intel_pt_insn, char *buf,
   size_t buf_len);
 
-size_t intel_pt_insn_max_size(void);
-
 int intel_pt_insn_type(enum intel_pt_insn_op op);
 
 #endif
diff --git a/tools/perf/util/intel-pt-decoder/intel-pt-log.c 
b/tools/perf/util/intel-pt-decoder/intel-pt-log.c
index 319bef33a64b..e02bc7b166a0 100644
--- a/tools/perf/util/intel-pt-decoder/intel-pt-log.c
+++ b/tools/perf/util/intel-pt-decoder/intel-pt-log.c
@@ -119,8 +119,8 @@ void 

[PATCH V3 0/3] perf tools: Support insn and insnlen in perf script

[Adrian Hunter]

Hi

I tidied Intel PT / BTS instruction buffer size usage, and took the liberty
of re-basing Andi's changes on top.


Adrian Hunter (1):
  perf intel-pt/bts: Tidy instruction buffer size usage

Andi Kleen (2):
  perf intel-pt/bts: Report instruction bytes and length in sample
  perf tools: Support insn and insnlen in perf script

 tools/perf/Documentation/perf-script.txt   |  6 +-
 tools/perf/builtin-script.c| 24 --
 tools/perf/util/event.h|  3 +++
 tools/perf/util/intel-bts.c|  9 
 .../perf/util/intel-pt-decoder/intel-pt-decoder.c  |  2 ++
 .../perf/util/intel-pt-decoder/intel-pt-decoder.h  |  1 +
 .../util/intel-pt-decoder/intel-pt-insn-decoder.c  | 13 ++--
 .../util/intel-pt-decoder/intel-pt-insn-decoder.h  |  6 ++
 tools/perf/util/intel-pt-decoder/intel-pt-log.c|  4 ++--
 tools/perf/util/intel-pt.c | 19 -
 10 files changed, 61 insertions(+), 26 deletions(-)


Regards
Adrian

[PATCH V3 2/3] perf intel-pt/bts: Report instruction bytes and length in sample

[Adrian Hunter]

From: Andi Kleen 

Change Intel PT and BTS to pass up the length and the instruction
bytes of the decoded or sampled instruction in the perf sample.

The decoder already knows this information, we just need to pass it
up. Since it is only a couple of movs it is not very expensive.

Handle instruction cache too. Make sure ilen is always initialized.

Used in the next patch.

[Adrian: re-base on top (and adjust for) instruction buffer size tidy-up]
[Adrian: add BTS support and adjust commit message accordingly]

Signed-off-by: Andi Kleen 
Signed-off-by: Adrian Hunter 
---
 tools/perf/util/event.h  |  3 +++
 tools/perf/util/intel-bts.c  |  1 +
 tools/perf/util/intel-pt-decoder/intel-pt-decoder.c  |  2 ++
 tools/perf/util/intel-pt-decoder/intel-pt-decoder.h  |  1 +
 tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.c |  2 +-
 tools/perf/util/intel-pt.c   | 11 +++
 6 files changed, 19 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/event.h b/tools/perf/util/event.h
index 8d363d5e65a2..c735c53a26f8 100644
--- a/tools/perf/util/event.h
+++ b/tools/perf/util/event.h
@@ -177,6 +177,8 @@ enum {
PERF_IP_FLAG_TRACE_BEGIN|\
PERF_IP_FLAG_TRACE_END)
 
+#define MAX_INSN 16
+
 struct perf_sample {
u64 ip;
u32 pid, tid;
@@ -193,6 +195,7 @@ struct perf_sample {
u32 flags;
u16 insn_len;
u8  cpumode;
+   char insn[MAX_INSN];
void *raw_data;
struct ip_callchain *callchain;
struct branch_stack *branch_stack;
diff --git a/tools/perf/util/intel-bts.c b/tools/perf/util/intel-bts.c
index 8bc7fec817d7..6c2eb5da4afc 100644
--- a/tools/perf/util/intel-bts.c
+++ b/tools/perf/util/intel-bts.c
@@ -295,6 +295,7 @@ static int intel_bts_synth_branch_sample(struct 
intel_bts_queue *btsq,
sample.cpu = btsq->cpu;
sample.flags = btsq->sample_flags;
sample.insn_len = btsq->intel_pt_insn.length;
+   memcpy(sample.insn, btsq->intel_pt_insn.buf, INTEL_PT_INSN_BUF_SZ);
 
if (bts->synth_opts.inject) {
event.sample.header.size = bts->branches_event_size;
diff --git a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c 
b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
index 16c06d3ae577..e4e7dc781d21 100644
--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
+++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.c
@@ -980,6 +980,8 @@ out:
 out_no_progress:
decoder->state.insn_op = intel_pt_insn->op;
decoder->state.insn_len = intel_pt_insn->length;
+   memcpy(decoder->state.insn, intel_pt_insn->buf,
+  INTEL_PT_INSN_BUF_SZ);
 
if (decoder->tx_flags & INTEL_PT_IN_TX)
decoder->state.flags |= INTEL_PT_IN_TX;
diff --git a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.h 
b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.h
index 89399985fa4d..e90619a43c0c 100644
--- a/tools/perf/util/intel-pt-decoder/intel-pt-decoder.h
+++ b/tools/perf/util/intel-pt-decoder/intel-pt-decoder.h
@@ -66,6 +66,7 @@ struct intel_pt_state {
uint32_t flags;
enum intel_pt_insn_op insn_op;
int insn_len;
+   char insn[INTEL_PT_INSN_BUF_SZ];
 };
 
 struct intel_pt_insn;
diff --git a/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.c 
b/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.c
index 5f95cd442075..7913363bde5c 100644
--- a/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.c
+++ b/tools/perf/util/intel-pt-decoder/intel-pt-insn-decoder.c
@@ -27,7 +27,7 @@
 
 #include "intel-pt-insn-decoder.h"
 
-#if INTEL_PT_INSN_BUF_SZ < MAX_INSN_SIZE
+#if INTEL_PT_INSN_BUF_SZ < MAX_INSN_SIZE || INTEL_PT_INSN_BUF_SZ > MAX_INSN
 #error Instruction buffer size too small
 #endif
 
diff --git a/tools/perf/util/intel-pt.c b/tools/perf/util/intel-pt.c
index 815a14d8904b..85d5eeb66c75 100644
--- a/tools/perf/util/intel-pt.c
+++ b/tools/perf/util/intel-pt.c
@@ -143,6 +143,7 @@ struct intel_pt_queue {
u32 flags;
u16 insn_len;
u64 last_insn_cnt;
+   char insn[INTEL_PT_INSN_BUF_SZ];
 };
 
 static void intel_pt_dump(struct intel_pt *pt __maybe_unused,
@@ -315,6 +316,7 @@ struct intel_pt_cache_entry {
enum intel_pt_insn_branch   branch;
int length;
int32_t rel;
+   charinsn[INTEL_PT_INSN_BUF_SZ];
 };
 
 static int intel_pt_config_div(const char *var, const char *value, void *data)
@@ -400,6 +402,7 @@ static int intel_pt_cache_add(struct dso *dso, struct 
machine *machine,
e->branch = intel_pt_insn->branch;
e->length = intel_pt_insn->length;
e->rel = intel_pt_insn->rel;
+   memcpy(e->insn, intel_pt_insn->buf, INTEL_PT_INSN_BUF_SZ);
 
err = auxtrace_cache__add(c, offset, >entry);
if (err)

[PATCH V3 3/3] perf tools: Support insn and insnlen in perf script

[Adrian Hunter]

From: Andi Kleen 

When looking at Intel PT traces with perf script it is useful to have
some indication of the instruction. Dump the instruction bytes and
instruction length, which can be used for simple pattern analysis in
scripts.

% perf record -e intel_pt// foo
% perf script --itrace=i0ns -F ip,insn,insnlen
 8101232f ilen: 5 insn: 0f 1f 44 00 00
 81012334 ilen: 1 insn: 5b
 81012335 ilen: 1 insn: 5d
 81012336 ilen: 1 insn: c3
 810123e3 ilen: 1 insn: 5b
 810123e4 ilen: 2 insn: 41 5c
 810123e6 ilen: 1 insn: 5d
 810123e7 ilen: 1 insn: c3
 810124a6 ilen: 2 insn: 31 c0
 810124a8 ilen: 9 insn: 41 83 bc 24 a8 01 00 00 01
 810124b1 ilen: 2 insn: 75 87
...

Signed-off-by: Andi Kleen 
Acked-by: Adrian Hunter 
---
 tools/perf/Documentation/perf-script.txt |  6 +-
 tools/perf/builtin-script.c  | 24 ++--
 2 files changed, 27 insertions(+), 3 deletions(-)

diff --git a/tools/perf/Documentation/perf-script.txt 
b/tools/perf/Documentation/perf-script.txt
index 053bbbd84ece..c01904f388ce 100644
--- a/tools/perf/Documentation/perf-script.txt
+++ b/tools/perf/Documentation/perf-script.txt
@@ -117,7 +117,7 @@ OPTIONS
 Comma separated list of fields to print. Options are:
 comm, tid, pid, time, cpu, event, trace, ip, sym, dso, addr, symoff,
 srcline, period, iregs, brstack, brstacksym, flags, bpf-output,
-callindent. Field list can be prepended with the type, trace, sw or hw,
+callindent, insn, insnlen. Field list can be prepended with the type, 
trace, sw or hw,
 to indicate to which event type the field list applies.
 e.g., -F sw:comm,tid,time,ip,sym  and -F trace:time,cpu,trace
 
@@ -181,6 +181,10 @@ OPTIONS
Instruction Trace decoding. For calls and returns, it will display the
name of the symbol indented with spaces to reflect the stack depth.
 
+   When doing instruction trace decoding insn and insnlen give the
+   instruction bytes and the instruction length of the current
+   instruction.
+
Finally, a user may not set fields to none for all event types.
i.e., -F "" is not allowed.
 
diff --git a/tools/perf/builtin-script.c b/tools/perf/builtin-script.c
index 7228d141a789..412fb6e65ac0 100644
--- a/tools/perf/builtin-script.c
+++ b/tools/perf/builtin-script.c
@@ -66,6 +66,8 @@ enum perf_output_field {
PERF_OUTPUT_WEIGHT  = 1U << 18,
PERF_OUTPUT_BPF_OUTPUT  = 1U << 19,
PERF_OUTPUT_CALLINDENT  = 1U << 20,
+   PERF_OUTPUT_INSN= 1U << 21,
+   PERF_OUTPUT_INSNLEN = 1U << 22,
 };
 
 struct output_option {
@@ -93,6 +95,8 @@ struct output_option {
{.str = "weight",   .field = PERF_OUTPUT_WEIGHT},
{.str = "bpf-output",   .field = PERF_OUTPUT_BPF_OUTPUT},
{.str = "callindent", .field = PERF_OUTPUT_CALLINDENT},
+   {.str = "insn", .field = PERF_OUTPUT_INSN},
+   {.str = "insnlen", .field = PERF_OUTPUT_INSNLEN},
 };
 
 /* default set to maintain compatibility with current format */
@@ -624,6 +628,20 @@ static void print_sample_callindent(struct perf_sample 
*sample,
printf("%*s", spacing - len, "");
 }
 
+static void print_insn(struct perf_sample *sample,
+  struct perf_event_attr *attr)
+{
+   if (PRINT_FIELD(INSNLEN))
+   printf(" ilen: %d", sample->insn_len);
+   if (PRINT_FIELD(INSN)) {
+   int i;
+
+   printf(" insn:");
+   for (i = 0; i < sample->insn_len; i++)
+   printf(" %02x", (unsigned char)sample->insn[i]);
+   }
+}
+
 static void print_sample_bts(struct perf_sample *sample,
 struct perf_evsel *evsel,
 struct thread *thread,
@@ -668,6 +686,8 @@ static void print_sample_bts(struct perf_sample *sample,
if (print_srcline_last)
map__fprintf_srcline(al->map, al->addr, "\n  ", stdout);
 
+   print_insn(sample, attr);
+
printf("\n");
 }
 
@@ -911,7 +931,7 @@ static void process_event(struct perf_script *script,
 
if (perf_evsel__is_bpf_output(evsel) && PRINT_FIELD(BPF_OUTPUT))
print_sample_bpf_output(sample);
-
+   print_insn(sample, attr);
printf("\n");
 }
 
@@ -2124,7 +2144,7 @@ int cmd_script(int argc, const char **argv, const char 
*prefix __maybe_unused)
 "Valid types: hw,sw,trace,raw. "
 "Fields: comm,tid,pid,time,cpu,event,trace,ip,sym,dso,"
 "addr,symoff,period,iregs,brstack,brstacksym,flags,"
-"bpf-output,callindent", parse_output_fields),
+"bpf-output,callindent,insn,insnlen", parse_output_fields),
OPT_BOOLEAN('a', "all-cpus", _wide,
"system-wide collection from 

Re: [PATCH 1/2] perf intel-pt-decoder: Report instruction bytes and length in sample

[Adrian Hunter]

On 05/10/16 14:36, Arnaldo Carvalho de Melo wrote:
> Em Mon, Oct 03, 2016 at 05:30:32PM -0700, Andi Kleen escreveu:
>> From: Andi Kleen 
>>
>> Change the Intel PT decoder to pass up the length and the instruction
>> bytes of the decoded or sampled instruction in the perf sample.
>>
>> The decoder already knows this information, we just need to pass it
>> up. Since it is only a couple of movs it is not very expensive.
>>
>> Used in the next patch.
> 
> Adrian, Ack?

I did a little tidy-up in Intel PT / BTS and re-based Andi's patch with my
SOB.  Please see V3 patch I sent.

Re: [patch 17/32] greybus: power supply driver

[Pavel Machek]

On Fri 2016-09-16 16:10:58, Greg KH wrote:
> 
> This driver implements the Greybus power supply class protocol.

Probably

POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS
M:  Sebastian Reichel 
M:  Dmitry Eremin-Solenikov 
M:  David Woodhouse 
L:  linux...@vger.kernel.org

should be cc-ed?

> +static int is_cache_valid(struct gb_power_supply *gbpsy)
> +{
...
> + if (gbpsy->last_update &&
> + time_is_after_jiffies(gbpsy->last_update +
> +   msecs_to_jiffies(cache_time)))
> + return 1;

Are you sure?
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: [PATCH v2] cinergyT2-core: don't do DMA on stack

[Jörg Otte]

2016-10-06 20:29 GMT+02:00 Mauro Carvalho Chehab :
> Em Thu, 6 Oct 2016 10:27:56 -0700
> Andy Lutomirski  escreveu:
>
>> On Wed, Oct 5, 2016 at 11:58 AM, Mauro Carvalho Chehab
>>  wrote:
>> > Sorry, forgot to C/C people that are at the "Re: Problem with VMAP_STACK=y"
>> > thread.
>> >
>> > Forwarded message:
>> >
>> > Date: Wed,  5 Oct 2016 15:54:18 -0300
>> > From: Mauro Carvalho Chehab 
>> > To: Linux Doc Mailing List 
>> > Cc: Mauro Carvalho Chehab , Mauro Carvalho 
>> > Chehab , Mauro Carvalho Chehab 
>> > Subject: [PATCH v2] cinergyT2-core: don't do DMA on stack
>> >
>> >
>> > The USB control messages require DMA to work. We cannot pass
>> > a stack-allocated buffer, as it is not warranted that the
>> > stack would be into a DMA enabled area.
>> >
>> > Signed-off-by: Mauro Carvalho Chehab 
>> > ---
>> >
>> > Added the fixups made by Johannes Stezenbach
>> >
>> >  drivers/media/usb/dvb-usb/cinergyT2-core.c | 45 
>> > ++
>> >  1 file changed, 27 insertions(+), 18 deletions(-)
>> >
>> > diff --git a/drivers/media/usb/dvb-usb/cinergyT2-core.c 
>> > b/drivers/media/usb/dvb-usb/cinergyT2-core.c
>> > index 9fd1527494eb..8267e3777af6 100644
>> > --- a/drivers/media/usb/dvb-usb/cinergyT2-core.c
>> > +++ b/drivers/media/usb/dvb-usb/cinergyT2-core.c
>> > @@ -41,6 +41,7 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>> >
>> >  struct cinergyt2_state {
>> > u8 rc_counter;
>> > +   unsigned char data[64];
>> >  };
>> >
>> >  /* We are missing a release hook with usb_device data */
>> > @@ -50,29 +51,36 @@ static struct dvb_usb_device_properties 
>> > cinergyt2_properties;
>> >
>> >  static int cinergyt2_streaming_ctrl(struct dvb_usb_adapter *adap, int 
>> > enable)
>> >  {
>> > -   char buf[] = { CINERGYT2_EP1_CONTROL_STREAM_TRANSFER, enable ? 1 : 
>> > 0 };
>> > -   char result[64];
>> > -   return dvb_usb_generic_rw(adap->dev, buf, sizeof(buf), result,
>> > -   sizeof(result), 0);
>> > +   struct dvb_usb_device *d = adap->dev;
>> > +   struct cinergyt2_state *st = d->priv;
>> > +
>> > +   st->data[0] = CINERGYT2_EP1_CONTROL_STREAM_TRANSFER;
>> > +   st->data[1] = enable ? 1 : 0;
>> > +
>> > +   return dvb_usb_generic_rw(d, st->data, 2, st->data, 64, 0);
>> >  }
>> >
>> >  static int cinergyt2_power_ctrl(struct dvb_usb_device *d, int enable)
>> >  {
>>
>> This...
>>
>> > -   char buf[] = { CINERGYT2_EP1_SLEEP_MODE, enable ? 0 : 1 };
>> > -   char state[3];
>> > -   return dvb_usb_generic_rw(d, buf, sizeof(buf), state, 
>> > sizeof(state), 0);
>> > +   struct cinergyt2_state *st = d->priv;
>> > +
>> > +   st->data[0] = CINERGYT2_EP1_SLEEP_MODE;
>>
>> ...does not match this:
>>
>> > +   st->data[1] = enable ? 1 : 0;
>>
>> --Andy
>
> Gah! Yes. This is what happens when coding using cut-and-paste ;)
>
> Jörg,
>
> Please test it with the condition reversed with the enclosed patch.
>
> if this doesn't work, you can enable dvb-usb debug at runtime,
> by loading it with debug parameter:
>
> parm:   debug:set debugging level 
> (1=info,xfer=2,pll=4,ts=8,err=16,rc=32,fw=64,mem=128,uxfer=256  (or-able)). 
> (debugging is not enabled) (int)
>
> debug=2 should show the control messages sent to the device on dmesg.
>
> Regards,
> Mauro
>
>
> [PATCH] cinergyT2-core: don't do DMA on stack
>
> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
>
> Signed-off-by: Mauro Carvalho Chehab 
>
> diff --git a/drivers/media/usb/dvb-usb/cinergyT2-core.c 
> b/drivers/media/usb/dvb-usb/cinergyT2-core.c
> index 9fd1527494eb..91640c927776 100644
> --- a/drivers/media/usb/dvb-usb/cinergyT2-core.c
> +++ b/drivers/media/usb/dvb-usb/cinergyT2-core.c
> @@ -41,6 +41,7 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>
>  struct cinergyt2_state {
> u8 rc_counter;
> +   unsigned char data[64];
>  };
>
>  /* We are missing a release hook with usb_device data */
> @@ -50,29 +51,36 @@ static struct dvb_usb_device_properties 
> cinergyt2_properties;
>
>  static int cinergyt2_streaming_ctrl(struct dvb_usb_adapter *adap, int enable)
>  {
> -   char buf[] = { CINERGYT2_EP1_CONTROL_STREAM_TRANSFER, enable ? 1 : 0 
> };
> -   char result[64];
> -   return dvb_usb_generic_rw(adap->dev, buf, sizeof(buf), result,
> -   sizeof(result), 0);
> +   struct dvb_usb_device *d = adap->dev;
> +   struct cinergyt2_state *st = d->priv;
> +
> +   st->data[0] = CINERGYT2_EP1_CONTROL_STREAM_TRANSFER;
> +   st->data[1] = enable ? 1 : 0;
> +
> +   return dvb_usb_generic_rw(d, st->data, 2, st->data, 64, 0);
>  }
>
>  static int 

Re: [PATCH 09/10] net: phy: Add MDIO driver for Juniper's SAM FPGA

[Andrew Lunn]

On Fri, Oct 07, 2016 at 06:18:37PM +0300, Pantelis Antoniou wrote:
> From: Georgi Vlaev 
> 
> Add driver for the MDIO IP block present in Juniper's
> SAM FPGA.
> 
> This driver supports only Clause 45 of the 802.3 spec.
> 
> Note that due to the fact that there are no drivers for
> Broadcom/Avago retimers on 10/40Ge path that are controlled
> from the MDIO interface there is a method to have direct
> access to registers via a debugfs interface.

This seems to be the wrong solution. Why not write those drivers?

Controlling stuff from user space is generally frowned up. So i expect
DaveM will NACK this patch. Please remove all the debugfs stuff.

> +static int mdio_sam_stat_wait(struct mii_bus *bus, u32 wait_mask)
> +{
> + struct mdio_sam_data *data = bus->priv;
> + unsigned long timeout;
> + u32 stat;
> +
> + timeout = jiffies + msecs_to_jiffies(MDIO_RDY_TMO);
> + do {
> + stat = ioread32(data->base + MDIO_STATUS);
> + if (stat & wait_mask)
> + return 0;
> +
> + usleep_range(50, 100);
> + } while (time_before(jiffies, timeout));
> +
> + return -EBUSY;

I've recently had to fix a loop like this in another
driver. usleep_range(50, 100) can sleep for a lot longer. If it sleeps
for MDIO_RDY_TMO you exit out with -EBUSY after a single iteration,
which is not what you want. It is better to make a fixed number of
iterations rather than a timeout.

> +}
> +
> +static int mdio_sam_read(struct mii_bus *bus, int phy_id, int regnum)
> +{
> + struct mdio_sam_data *data = bus->priv;
> + u32 command, res;
> + int ret;
> +
> + /* mdiobus_read holds the bus->mdio_lock mutex */
> +
> + if (!(regnum & MII_ADDR_C45))
> + return -ENXIO;
> +
> + ret = mdio_sam_stat_wait(bus, STAT_REG_RDY);
> + if (ret < 0)
> + return ret;
> +
> + command = regnum & 0x1f; /* regnum = (dev_id << 16) | reg */
> + command |= ((phy_id & 0x1f) << 21);
> +
> + iowrite32(command, data->base + MDIO_CMD1);
> + ioread32(data->base + MDIO_CMD1);


> + iowrite32(CMD2_READ | CMD2_ENABLE, data->base + MDIO_CMD2);
> + ioread32(data->base + MDIO_CMD2);

Why do you need to read the values back? Hardware bug?

> + iowrite32(TBL_CMD_REG_GO, data->base + MDIO_TBL_CMD);
> + ioread32(data->base + MDIO_TBL_CMD);

Although not wrong, most drivers use writel().

> +
> + usleep_range(50, 100);
> +
> + ret = mdio_sam_stat_wait(bus, (STAT_REG_DONE | STAT_REG_ERR));

Do you really need a wait before calling mdio_sam_stat_wait()? Isn't
that what it is supposed to do, wait...

> + if (ret < 0)
> + return ret;
> +
> + res = ioread32(data->base + MDIO_RESULT);
> +
> + if (res & RES_ERROR || !(res & RES_SUCCESS))
> + return -EIO;
> +
> + return (res & 0x);
> +}
> +
> +static int mdio_sam_write(struct mii_bus *bus, int phy_id, int regnum, u16 
> val)
> +{
> + struct mdio_sam_data *data = bus->priv;
> + u32 command;
> + int ret;
> +
> + /* mdiobus_write holds the bus->mdio_lock mutex */
> +
> + if (!(regnum & MII_ADDR_C45))
> + return -ENXIO;
> +
> + ret = mdio_sam_stat_wait(bus, STAT_REG_RDY);
> + if (ret < 0)
> + return ret;
> +
> + command = regnum & 0x1f; /* regnum = (dev_id << 16) | reg */
> + command |= ((phy_id & 0x1f) << 21);
> +
> + iowrite32(command, data->base + MDIO_CMD1);
> + ioread32(data->base + MDIO_CMD1);
> + iowrite32(CMD2_ENABLE | val, data->base + MDIO_CMD2);
> + ioread32(data->base + MDIO_CMD2);
> + iowrite32(TBL_CMD_REG_GO, data->base + MDIO_TBL_CMD);
> + ioread32(data->base + MDIO_TBL_CMD);
> +
> + usleep_range(50, 100);
> +
> + ret = mdio_sam_stat_wait(bus, (STAT_REG_DONE | STAT_REG_ERR));
> + if (ret < 0)
> + return ret;
> +
> + return 0;
> +}
> +
> +static int mdio_sam_reset(struct mii_bus *bus)
> +{
> + struct mdio_sam_data *data = bus->priv;
> +
> + iowrite32(TBL_CMD_SOFT_RESET, data->base + MDIO_TBL_CMD);
> + ioread32(data->base + MDIO_TBL_CMD);
> + mdelay(10);
> + iowrite32(0, data->base + MDIO_TBL_CMD);
> + ioread32(data->base + MDIO_TBL_CMD);
> +
> + /* zero tables */
> + memset_io(data->base + MDIO_CMD1, 0, 0x1000);
> + memset_io(data->base + MDIO_PRI_CMD1, 0, 0x1000);

What tables?

> +
> + return 0;
> +}
> +
> +static int mdio_sam_of_register_bus(struct platform_device *pdev,
> + struct device_node *np, void __iomem *base)
> +{
> + struct mii_bus *bus;
> + struct mdio_sam_data *data;
> + u32 reg;
> + int ret;
> +
> + bus = devm_mdiobus_alloc_size(>dev, sizeof(*data));
> + if (!bus)
> + return -ENOMEM;
> +
> + /* bus offset */
> + ret = of_property_read_u32(np, "reg", );
> + if (ret)
> + return -ENODEV;
> +
> + data = bus->priv;
> + data->base = base + 

[PATCH v5 01/17] ext4: allow DAX writeback for hole punch

[Ross Zwisler]

Currently when doing a DAX hole punch with ext4 we fail to do a writeback.
This is because the logic around filemap_write_and_wait_range() in
ext4_punch_hole() only looks for dirty page cache pages in the radix tree,
not for dirty DAX exceptional entries.

Signed-off-by: Ross Zwisler 
Reviewed-by: Jan Kara 
Cc: 
---
 fs/ext4/inode.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 3131747..0900cb4 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3890,7 +3890,7 @@ int ext4_update_disksize_before_punch(struct inode 
*inode, loff_t offset,
 }
 
 /*
- * ext4_punch_hole: punches a hole in a file by releaseing the blocks
+ * ext4_punch_hole: punches a hole in a file by releasing the blocks
  * associated with the given offset and length
  *
  * @inode:  File inode
@@ -3919,7 +3919,7 @@ int ext4_punch_hole(struct inode *inode, loff_t offset, 
loff_t length)
 * Write out all dirty pages to avoid race conditions
 * Then release them.
 */
-   if (mapping->nrpages && mapping_tagged(mapping, PAGECACHE_TAG_DIRTY)) {
+   if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY)) {
ret = filemap_write_and_wait_range(mapping, offset,
   offset + length - 1);
if (ret)
-- 
2.7.4

[RFC v3 1/3] skge: Rename LED_OFF and LED_ON in marvel skge driver to avoid conflicts with leds namespace

[Zach Brown]

Adding led support for phy causes namespace conflicts for some
phy drivers.

The marvel skge driver declared an enum for representing the states of
Link LED Register. The enum contained constant LED_OFF which conflicted
with declartation found in linux/leds.h.
LED_OFF changed to LED_REG_OFF
Also changed LED_ON to LED_REG_ON to avoid possible future conflict and
for consistency.

Signed-off-by: Zach Brown 
---
 drivers/net/ethernet/marvell/skge.c | 6 +++---
 drivers/net/ethernet/marvell/skge.h | 4 ++--
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/net/ethernet/marvell/skge.c 
b/drivers/net/ethernet/marvell/skge.c
index 7173836..783df01 100644
--- a/drivers/net/ethernet/marvell/skge.c
+++ b/drivers/net/ethernet/marvell/skge.c
@@ -1048,7 +1048,7 @@ static const char *skge_pause(enum pause_status status)
 static void skge_link_up(struct skge_port *skge)
 {
skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG),
-   LED_BLK_OFF|LED_SYNC_OFF|LED_ON);
+   LED_BLK_OFF|LED_SYNC_OFF|LED_REG_ON);
 
netif_carrier_on(skge->netdev);
netif_wake_queue(skge->netdev);
@@ -1062,7 +1062,7 @@ static void skge_link_up(struct skge_port *skge)
 
 static void skge_link_down(struct skge_port *skge)
 {
-   skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG), LED_OFF);
+   skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG), LED_REG_OFF);
netif_carrier_off(skge->netdev);
netif_stop_queue(skge->netdev);
 
@@ -2668,7 +2668,7 @@ static int skge_down(struct net_device *dev)
if (hw->ports == 1)
free_irq(hw->pdev->irq, hw);
 
-   skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG), LED_OFF);
+   skge_write8(skge->hw, SK_REG(skge->port, LNK_LED_REG), LED_REG_OFF);
if (is_genesis(hw))
genesis_stop(skge);
else
diff --git a/drivers/net/ethernet/marvell/skge.h 
b/drivers/net/ethernet/marvell/skge.h
index a2eb341..3ea151f 100644
--- a/drivers/net/ethernet/marvell/skge.h
+++ b/drivers/net/ethernet/marvell/skge.h
@@ -662,8 +662,8 @@ enum {
LED_BLK_OFF = 1<<4, /* Link LED Blinking Off */
LED_SYNC_ON = 1<<3, /* Use Sync Wire to switch LED */
LED_SYNC_OFF= 1<<2, /* Disable Sync Wire Input */
-   LED_ON  = 1<<1, /* switch LED on */
-   LED_OFF = 1<<0, /* switch LED off */
+   LED_REG_ON  = 1<<1, /* switch LED on */
+   LED_REG_OFF = 1<<0, /* switch LED off */
 };
 
 /* Receive GMAC FIFO (YUKON) */
-- 
2.7.4

Re: [PULL REQUEST] i2c for 4.9

[Linus Torvalds]

On Fri, Oct 7, 2016 at 2:32 AM, Wolfram Sang  wrote:
>
> here is the 4.9 pull request from I2C including:

Would you mind double-checking my merge.

It looked very trivial, but it would be good to have somebody else
give that gpio-pca953x.c conflict a look to verify that I didn't screw
up the 'id' variable split.

Linus

[PATCH] arm64: defconfig: enable EEPROM_AT25 config option

[Scott Branden]

Enable support for on board SPI EEPROM by turning on
CONFIG_EEPROM_AT25.

Signed-off-by: Scott Branden 
---
 arch/arm64/configs/defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index eadf485..9955ee1 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -136,6 +136,7 @@ CONFIG_MTD_SPI_NOR=y
 CONFIG_BLK_DEV_LOOP=y
 CONFIG_BLK_DEV_NBD=m
 CONFIG_VIRTIO_BLK=y
+CONFIG_EEPROM_AT25=y
 CONFIG_SRAM=y
 # CONFIG_SCSI_PROC_FS is not set
 CONFIG_BLK_DEV_SD=y
-- 
2.5.0

Re: [GIT PULL] trivial for 4.9

[Linus Torvalds]

On Fri, Oct 7, 2016 at 2:06 PM, Linus Torvalds
 wrote:
>
> And btw, even without an explicit KERN_, you should still not
> get any interleaving. Only an _explicit_ KERN_CONT should cause
> interleaving

Btw, note the "should" there. Because we do seem to have broken that
_again_.  It worked fine at some point, but lookie here:

commit 61e99ab8e35a88b8c4d0f80d3df9ee16df471be5
Author: Joe Perches 
Date:   Mon Jul 30 14:40:21 2012 -0700

printk: remove the now unnecessary "C" annotation for KERN_CONT

Now that all KERN_ uses are prefixed with ASCII SOH, there is no
need for a KERN_CONT.  Keep it backward compatible by adding #define
KERN_CONT ""

Joe, you *are* the problem here.

So you are literally the person who broke this.

Goddammit, I don't want to hear another peep from you. You broke this
because you wanted to save a few bytes in those strings, and then
*because* you broke it, you then argue for putting those bytes back in
the form of "\n" characters.

Fuck me sideways. You make this big deal about how this interleaving
is a big problem, and at no point did you actually point to the real
issue, which was your very own breakage where you made it all fragile.

Christ.

Linus

Re: [PATCH] fs: Assert on module file_operations without an owner

[Calvin Owens]

On Friday 10/07 at 17:18 -0400, Calvin Owens wrote:
> On Friday 10/07 at 21:48 +0100, Al Viro wrote:
> > On Fri, Oct 07, 2016 at 01:35:52PM -0700, Calvin Owens wrote:
> > > Omitting the owner field in file_operations declared in modules is an
> > > easy mistake to make, and can result in crashes when the module is
> > > unloaded while userspace is poking the file.
> > > 
> > > This patch modifies fops_get() to WARN when it encounters a NULL owner,
> > > since in this case it cannot take a reference on the containing module.
> > 
> > NAK.  This is complete crap - we do *NOT* need ->owner on a lot of
> > file_operations.
> 
> This isn't a theoretical issue: I have a proprietary module that makes this
> mistake and crashes when poking a chrdev it exposes in userspace races with
> unloading the module.
> 
> Of course, the bug is in this silly module. I'm not arguing that it isn't. I
> was hesitant to even mention this because I know waving at something in an OOT
> module is a poor argument for changing anything in the proper kernel.
> 
> But what I'm trying to do here is prevent people from making that mistake in
> the future by yelling at them when they do. The implicit ignoring of a NULL
> owner in try_module_get() in fops_get() is not necessarily obvious.

Let's drop this, I should never have sent the patch in the first place.

> > * we do not need that on file_operations of a regular file or
> > directory on a normal filesystem, since that filesystem is not going
> > away until the file has been closed - ->f_path.mnt is holding a reference
> > to vfsmount, which is holding a reference to superblock, which is holding
> > a reference to file_system_type, which is holding a reference to _its_
> > ->owner.
> > * we do not need that on anything on procfs - module removal is
> > legal while a procfs file is opened; its cleanup will be blocked for the
> > duration of ->read(), ->write(), etc. calls.
> 
> I see why this is true, and it's something I considered. But when there is
> zero cost to being explicit and setting ->owner, why not do it?
> 
> > If anything, we would be better off with modifications that would get
> > rid of ->owner on file_operations.  It's not trivial to do, but it might
> > be not impossible.

I'll look into this, I'm interested.

Thanks,
Calvin

> 

Re: [PATCH V3 09/10] trace, ras: add ARM processor error trace event

[Steven Rostedt]

On Fri,  7 Oct 2016 15:31:21 -0600
Tyler Baicar  wrote:

> Currently there are trace events for the various RAS
> errors with the exception of ARM processor type errors.
> Add a new trace event for such errors so that the user
> will know when they occur. These trace events are
> consistent with the ARM processor error section type
> defined in UEFI 2.6 spec section N.2.4.4.
> 
> Signed-off-by: Tyler Baicar 
> ---
>  drivers/firmware/efi/cper.c |  9 ++
>  drivers/ras/ras.c   |  1 +
>  include/ras/ras_event.h | 67 
> +
>  3 files changed, 77 insertions(+)
> 
> diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
> index f9ffba6..21b8a6f 100644
> --- a/drivers/firmware/efi/cper.c
> +++ b/drivers/firmware/efi/cper.c
> @@ -34,6 +34,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #define INDENT_SP" "
>  
> @@ -256,6 +257,14 @@ static void cper_print_proc_armv8(const char *pfx,
>   CPER_ARMV8_INFO_VALID_PHYSICAL_ADDR)
>   printk("%sphysical fault address: 0x%016llx\n",
>   newpfx, err_info->physical_fault_addr);
> + trace_arm_event(proc->affinity_level, proc->mpidr, proc->midr,
> + proc->running_state, proc->psci_state,
> + err_info->version, err_info->type,
> + err_info->multiple_error,
> + err_info->validation_bits,
> + err_info->error_info,
> + err_info->virt_fault_addr,
> + err_info->physical_fault_addr);

Why waste all the effort into passing each individual field. Why not
just pass the structure in and sort it out in the TP_fast_assign()?

>   err_info += 1;
>   }
>  
> diff --git a/drivers/ras/ras.c b/drivers/ras/ras.c
> index fb2500b..8ba5a94 100644
> --- a/drivers/ras/ras.c
> +++ b/drivers/ras/ras.c
> @@ -28,3 +28,4 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(extlog_mem_event);
>  #endif
>  EXPORT_TRACEPOINT_SYMBOL_GPL(mc_event);
>  EXPORT_TRACEPOINT_SYMBOL_GPL(unknown_sec_event);
> +EXPORT_TRACEPOINT_SYMBOL_GPL(arm_event);
> diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
> index 5861b6f..eb2719a 100644
> --- a/include/ras/ras_event.h
> +++ b/include/ras/ras_event.h
> @@ -162,6 +162,73 @@ TRACE_EVENT(mc_event,
>  );
>  
>  /*
> + * ARM Processor Events Report
> + *
> + * This event is generated when hardware detects an ARM processor error
> + * has occurred. UEFI 2.6 spec section N.2.4.4.
> + */
> +TRACE_EVENT(arm_event,
> +
> + TP_PROTO(const u8 affinity,
> +  const u64 mpidr,
> +  const u64 midr,
> +  const u32 running_state,
> +  const u32 psci_state,
> +  const u8 version,
> +  const u8 type,
> +  const u16 err_count,
> +  const u8 flags,
> +  const u64 info,
> +  const u64 virt_fault_addr,
> +  const u64 phys_fault_addr),
> +
> + TP_ARGS(affinity, mpidr, midr, running_state, psci_state,
> + version, type, err_count, flags, info, virt_fault_addr,
> + phys_fault_addr),
> +
> + TP_STRUCT__entry(
> + __field(u8, affinity)
> + __field(u64, mpidr)
> + __field(u64, midr)
> + __field(u32, running_state)
> + __field(u32, psci_state)
> + __field(u8, version)
> + __field(u8, type)
> + __field(u16, err_count)
> + __field(u8, flags)
> + __field(u64, info)
> + __field(u64, virt_fault_addr)
> + __field(u64, phys_fault_addr)

The above creates a structure with lots of holes in it. Pack it better.
You want something like:

__field(u64, mpidr)
__field(u64, midr)
__field(u64, info)
__field(u64, virt_fault_addr)
__field(u64, phys_fault_addr)
__field(u32, running_state)
__field(u32, psci_state)
__field(u16, err_count)
__field(u8, affinity)
__field(u8, version)
__field(u8, type)
__field(u8, flags)

The above is a total of 54 bytes. Your original was at a minimum, 64
bytes.

-- Steve

> + ),
> +
> + TP_fast_assign(
> + __entry->affinity = affinity;
> + __entry->mpidr = mpidr;
> + __entry->midr = midr;
> + __entry->running_state = running_state;
> + __entry->psci_state = psci_state;
> + __entry->version = version;
> + __entry->type = type;
> + __entry->err_count = err_count;
> + __entry->flags = flags;
> + __entry->info = info;
> + __entry->virt_fault_addr = virt_fault_addr;
> + __entry->phys_fault_addr = phys_fault_addr;
> + ),
> +
> +   

[RELEASE] LTTng modules 2.7.6 and 2.8.2 (Linux tracer timekeeping work-around)

[Mathieu Desnoyers]

Hi,

LTTng modules 2.7.6 and 2.8.2 are bugfix releases which
work around an upstream Linux kernel timekeeping bug. This
bug has been introduced in the 4.8 kernel, and backported
into Linux stable branches. It affects LTTng, perf,
ftrace with "mono" clock source, and eBPF.

All LTTng-modules 2.7.x and 2.8.x users with Linux kernels
4.8, 4.7.4+, 4.4.20+, and 4.1.32+ should upgrade.

The effect of this issue is that timestamps sampled in the
trace are not reliable, and may be off by up to nearly a
second, which makes correlation between cores, and between
kernel and user-space tracing impossible.

The upstream kernel fix is being discussed [1], but it has
not been merged yet.

Linux commit 27727df240c7 ("Avoid taking lock in NMI path with
CONFIG_DEBUG_TIMEKEEPING"), changed the logic to open-code
the timekeeping_get_ns() function, but forgot to include
the unit conversion from cycles to nanoseconds, breaking the
function's output, which impacts LTTng.

We expect that the upstream fix will reach the master and stable
branches timely before the next releases, so we use 4.8.1, 4.7.7,
4.4.24, and 4.1.34 as upper bounds (exclusive).

Fall-back to the non-NMI-safe trace clock for those kernel versions.
We simply discard events from NMI context with a in_nmi() check,
as we did before Linux 3.17.

Project website: http://lttng.org
Documentation: http://lttng.org/docs
Download link: http://lttng.org/download

Changelog:

2016-10-07 (National Frappé Day) LTTng modules 2.8.2
* Fix: show warning for broken clock work-around
* Fix: work-around upstream Linux timekeeping bug

2016-10-07 (National Frappé Day) LTTng modules 2.7.6
* Fix: show warning for broken clock work-around
* Fix: work-around upstream Linux timekeeping bug
* Documentation: lttng-modules 2.7 supports Linux < 4.8

[1] 
http://lkml.kernel.org/r/1475636148-26539-1-git-send-email-john.stu...@linaro.org

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: [GIT PULL] trivial for 4.9

[Joe Perches]

On Fri, 2016-10-07 at 13:25 -0700, Linus Torvalds wrote:
> I find this noise to add '\n' characters completely pointless. It's
> bogus stupid churn that doesn't actually make the source code better,
> and it also doesn't actually seem to fix any behavioral issues.
> 
> And if there are behavioral issues, they should (a) be pointed out and
> (b) be fixed.
> 
> In *no* case does it make sense to randomly just add newline
> characters without even having a reason for it.

It prevents random interleaving from those other
12000+ possible printk calls without an explicit
KERN_

Re: [PATCH v13 15/15] vfio/type1: Return the MSI geometry through VFIO_IOMMU_GET_INFO capability chains

[Alex Williamson]

On Fri, 7 Oct 2016 19:10:27 +0200
Auger Eric  wrote:

> Hi Alex,
> 
> On 06/10/2016 22:42, Alex Williamson wrote:
> > On Thu, 6 Oct 2016 14:20:40 -0600
> > Alex Williamson  wrote:
> >   
> >> On Thu,  6 Oct 2016 08:45:31 +
> >> Eric Auger  wrote:
> >>  
> >>> This patch allows the user-space to retrieve the MSI geometry. The
> >>> implementation is based on capability chains, now also added to
> >>> VFIO_IOMMU_GET_INFO.
> >>>
> >>> The returned info comprise:
> >>> - whether the MSI IOVA are constrained to a reserved range (x86 case) and
> >>>   in the positive, the start/end of the aperture,
> >>> - or whether the IOVA aperture need to be set by the userspace. In that
> >>>   case, the size and alignment of the IOVA window to be provided are
> >>>   returned.
> >>>
> >>> In case the userspace must provide the IOVA aperture, we currently report
> >>> a size/alignment based on all the doorbells registered by the host kernel.
> >>> This may exceed the actual needs.
> >>>
> >>> Signed-off-by: Eric Auger 
> >>>
> >>> ---
> >>> v11 -> v11:
> >>> - msi_doorbell_pages was renamed msi_doorbell_calc_pages
> >>>
> >>> v9 -> v10:
> >>> - move cap_offset after iova_pgsizes
> >>> - replace __u64 alignment by __u32 order
> >>> - introduce __u32 flags in vfio_iommu_type1_info_cap_msi_geometry and
> >>>   fix alignment
> >>> - call msi-doorbell API to compute the size/alignment
> >>>
> >>> v8 -> v9:
> >>> - use iommu_msi_supported flag instead of programmable
> >>> - replace IOMMU_INFO_REQUIRE_MSI_MAP flag by a more sophisticated
> >>>   capability chain, reporting the MSI geometry
> >>>
> >>> v7 -> v8:
> >>> - use iommu_domain_msi_geometry
> >>>
> >>> v6 -> v7:
> >>> - remove the computation of the number of IOVA pages to be provisionned.
> >>>   This number depends on the domain/group/device topology which can
> >>>   dynamically change. Let's rely instead rely on an arbitrary max 
> >>> depending
> >>>   on the system
> >>>
> >>> v4 -> v5:
> >>> - move msi_info and ret declaration within the conditional code
> >>>
> >>> v3 -> v4:
> >>> - replace former vfio_domains_require_msi_mapping by
> >>>   more complex computation of MSI mapping requirements, especially the
> >>>   number of pages to be provided by the user-space.
> >>> - reword patch title
> >>>
> >>> RFC v1 -> v1:
> >>> - derived from
> >>>   [RFC PATCH 3/6] vfio: Extend iommu-info to return MSIs automap state
> >>> - renamed allow_msi_reconfig into require_msi_mapping
> >>> - fixed VFIO_IOMMU_GET_INFO
> >>> ---
> >>>  drivers/vfio/vfio_iommu_type1.c | 78 
> >>> -
> >>>  include/uapi/linux/vfio.h   | 32 -
> >>>  2 files changed, 108 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/drivers/vfio/vfio_iommu_type1.c 
> >>> b/drivers/vfio/vfio_iommu_type1.c
> >>> index dc3ee5d..ce5e7eb 100644
> >>> --- a/drivers/vfio/vfio_iommu_type1.c
> >>> +++ b/drivers/vfio/vfio_iommu_type1.c
> >>> @@ -38,6 +38,8 @@
> >>>  #include 
> >>>  #include 
> >>>  #include 
> >>> +#include 
> >>> +#include 
> >>>  
> >>>  #define DRIVER_VERSION  "0.2"
> >>>  #define DRIVER_AUTHOR   "Alex Williamson "
> >>> @@ -1101,6 +1103,55 @@ static int vfio_domains_have_iommu_cache(struct 
> >>> vfio_iommu *iommu)
> >>>   return ret;
> >>>  }
> >>>  
> >>> +static int compute_msi_geometry_caps(struct vfio_iommu *iommu,
> >>> +  struct vfio_info_cap *caps)
> >>> +{
> >>> + struct vfio_iommu_type1_info_cap_msi_geometry *vfio_msi_geometry;
> >>> + unsigned long order = __ffs(vfio_pgsize_bitmap(iommu));
> >>> + struct iommu_domain_msi_geometry msi_geometry;
> >>> + struct vfio_info_cap_header *header;
> >>> + struct vfio_domain *d;
> >>> + bool reserved;
> >>> + size_t size;
> >>> +
> >>> + mutex_lock(>lock);
> >>> + /* All domains have same require_msi_map property, pick first */
> >>> + d = list_first_entry(>domain_list, struct vfio_domain, next);
> >>> + iommu_domain_get_attr(d->domain, DOMAIN_ATTR_MSI_GEOMETRY,
> >>> +   _geometry);
> >>> + reserved = !msi_geometry.iommu_msi_supported;
> >>> +
> >>> + mutex_unlock(>lock);
> >>> +
> >>> + size = sizeof(*vfio_msi_geometry);
> >>> + header = vfio_info_cap_add(caps, size,
> >>> +VFIO_IOMMU_TYPE1_INFO_CAP_MSI_GEOMETRY, 1);
> >>> +
> >>> + if (IS_ERR(header))
> >>> + return PTR_ERR(header);
> >>> +
> >>> + vfio_msi_geometry = container_of(header,
> >>> + struct vfio_iommu_type1_info_cap_msi_geometry,
> >>> + header);
> >>> +
> >>> + vfio_msi_geometry->flags = reserved;
> >>
> >> Use the bit flag VFIO_IOMMU_MSI_GEOMETRY_RESERVED
> >>  
> >>> + if (reserved) {
> >>> + vfio_msi_geometry->aperture_start = msi_geometry.aperture_start;
> >>> + vfio_msi_geometry->aperture_end = msi_geometry.aperture_end;
> >>
> >> But 

Re: [PATCH 0/6] Introduce Juniper CBC FPGA

[Greg Kroah-Hartman]

On Fri, Oct 07, 2016 at 09:53:29PM +0300, Pantelis Antoniou wrote:
> Hi Greg,
> 
> > On Oct 7, 2016, at 18:39 , Greg Kroah-Hartman  
> > wrote:
> > 
> > On Fri, Oct 07, 2016 at 06:20:08PM +0300, Pantelis Antoniou wrote:
> >> Add Juniper's PTX1K CBC FPGA driver. Those FPGAs
> >> are present in Juniper's PTX series of routers.
> >> 
> >> The MFD driver provices a gpio device and a special
> >> driver for Juniper's board infrastucture.
> >> The FPGA infrastucture driver is providing an interface
> >> for user-space handling of the FPGA in those platforms.
> >> 
> >> There are full device tree binding documents for the
> >> master mfd driver and for the slave driver.
> >> 
> >> This patchset is against mainline as of today: v4.8-9431-g3477d16
> >> and is dependent on the "Juniper prerequisites" and
> >> "Juniper infrastructure" patchsets sent earlier.
> >> 
> >> Georgi Vlaev (5):
> >>  mfd: Add support for the PTX1K CBC FPGA
> >>  gpio: Add support for PTX1K CBC FPGA spare GPIOs
> >>  gpio: gpio-cbc: Document bindings of CBC FPGA GPIO block
> >>  gpio: cbc-presence: Add CBC presence detect as GPIO driver
> >>  gpio: gpio-cbc-presense: Document bindings of CBC FPGA presence
> >> 
> >> Tom Kavanagh (1):
> >>  staging: jnx: CBD-FPGA infrastructure
> >> 
> >> .../bindings/gpio/jnx,gpio-cbc-presense.txt|  31 +
> >> .../devicetree/bindings/gpio/jnx,gpio-cbc.txt  |  30 +
> >> drivers/gpio/Kconfig   |  23 +
> >> drivers/gpio/Makefile  |   2 +
> >> drivers/gpio/gpio-cbc-presence.c   | 460 ++
> >> drivers/gpio/gpio-cbc.c| 236 +
> >> drivers/mfd/Kconfig|  16 +
> >> drivers/mfd/Makefile   |   1 +
> >> drivers/mfd/cbc-core.c | 971 
> >> +
> >> drivers/staging/jnx/Kconfig|  34 +
> >> drivers/staging/jnx/Makefile   |   5 +
> >> drivers/staging/jnx/jnx-cbc-ptx1k.c| 242 +
> >> drivers/staging/jnx/jnx-cbd-fpga-common.c  | 332 +++
> >> drivers/staging/jnx/jnx-cbd-fpga-common.h  |  27 +
> >> drivers/staging/jnx/jnx-cbd-fpga-core.c| 540 
> >> drivers/staging/jnx/jnx-cbd-fpga-core.h|  68 ++
> >> drivers/staging/jnx/jnx-cbd-fpga-platdata.h|  51 ++
> >> drivers/staging/jnx/jnx-cbd-fpga-ptx1k.c   | 134 +++
> >> drivers/staging/jnx/jnx-cbd-fpga-ptx21k.c  | 143 +++
> >> drivers/staging/jnx/jnx-cbd-fpga-ptx3k.c   | 111 +++
> >> drivers/staging/jnx/jnx-cbd-fpga-ptx5k.c   | 107 +++
> >> include/linux/mfd/cbc-core.h   | 181 
> >> 22 files changed, 3745 insertions(+)
> > 
> > Please don't mix driver submissions like this.  Staging stuff needs to
> > go to the staging maintainer, gpio to that one, mfd to that one, and so
> > on.
> > 
> > there's almost nothing anyone can do with this series as-is, sorry.
> > 
> > please split it up.
> > 
> 
> Now I’m confused, this is a typical MFD submission:
> 
> https://lwn.net/Articles/587032/
> 
> Looks like it’s normal for a single patchset against multiple subsystems.

Not when it crosses the drivers/staging/ boundry.

> Do we have a definitive form for this?

Either submit all of this stuff "properly", or put it in staging, don't
cross the boundry if at all possible, it just causes a lot of confusion
and headache as the staging stuff could be deleted at any time.

You still haven't explained why you feel drivers/staging/ is the right
place for this codebase.  Again, why not just submit it "properly"?

thanks,

greg k-h

Re: [v4.8-rc1 Regression] sched/fair: Apply more PELT fixes

[Linus Torvalds]

On Fri, Oct 7, 2016 at 1:22 PM, Joseph Salisbury
 wrote:
>
> Yes, CONFIG_SCHED_AUTOGROUP is enabled in the Ubuntu kernel.  However,
> that config was also enable in the Ubuntu 4.4 kerrnels without seeing
> this issue.   I can try disabling the config in the 4.8 based kernel and
> see if that changes things.

No, that wouldn't make any sense. I just wanted to know that the
option was enabled, because that option really *should* help buffer
other processes from one session that is a CPU hog.

So something is seriously wrong in that situation if other things get
very choppy. Of course, the fact that it apparently happens on one
particular machine only means that it's hard to figure out what
triggers it. Maybe some unlucky combination of cpufreq and thermal
throttling by the hardware, coupled with the scheduler change.

Peter?

 Linus

Re: [PULL REQUEST] i2c for 4.9

[Wolfram Sang]

> I see you didn't pick up the follow-up patch ("gpio: pca953x: add a
> comment explaining the need for a lockdep subclass"). Linus acked it

This was planned for the following pull request. Didn't want to change
what was successfully in linux-next for a while.



signature.asc
Description: PGP signature

Re: [PATCH][V2] nbd: add multi-connection support

[Josef Bacik]

On 10/07/2016 02:36 PM, Pavel Machek wrote:

On Thu 2016-09-15 10:43:54, Josef Bacik wrote:

NBD can become contended on its single connection.  We have to serialize all
writes and we can only process one read response at a time.  Fix this by
allowing userspace to provide multiple connections to a single nbd device.  This
coupled with block-mq drastically increases performance in multi-process cases.
Thanks,

Signed-off-by: Josef Bacik 


Idea is that it can now use multiple CPUs concurrently...?

Do you have a diff for the nbd-server, too?
Pavel



nbd-server doesn't need anything special, it just works.  I have a patch for 
nbd-client so you can open multiple connections to setup the NBD device.  You 
can find my patches for the userspace stuff here


https://github.com/josefbacik/nbd

Thanks,

Josef

Re: [PATCH 4/10] MAINTAINERS: add entry for Marvell Xenon MMC Host Controller drivers

[Joe Perches]

On Fri, 2016-10-07 at 17:22 +0200, Gregory CLEMENT wrote:
> Add maintainer entry for Marvell Xenon eMMC/SD/SDIO Host
> Controller drivers.
[]
> diff --git a/MAINTAINERS b/MAINTAINERS
[]
> @@ -7578,6 +7578,11 @@ M: Nicolas Pitre 
>  S:   Odd Fixes
>  F:   drivers/mmc/host/mvsdio.*
>  
> +MARVELL XENON MMC/SD/SDIO HOST CONTROLLER DRIVER
> +M:   Ziji Hu 
> +L:   linux-...@vger.kernel.org
> +S:   Supported

You should really add F: file patterns here

Re: [PATCH 1/3] fpga manager: Add cyclonespi driver for Altera fpgas

[Joshua Clayton]

On 10/07/2016 11:21 AM, atull wrote:
> On Fri, 7 Oct 2016, Moritz Fischer wrote:
>
>>> +static inline u32 revbit8x4(u32 n)
>>> +{
>>> +   n = ((n & 0xF0F0F0F0UL) >> 4) | ((n & 0x0F0F0F0FUL) << 4);
>>> +   n = ((n & 0xUL) >> 2) | ((n & 0xUL) << 2);
>>> +   n = ((n & 0xUL) >> 1) | ((n & 0xUL) << 1);
>>> +   return n;
>>> +}
The real issue is that The FPGA wants lsb first, and my SPI driver
doesn't support it.
What I really wanted to do here was to get generic support for lsb-first
SPI into the SPI subsystem.
>> During the Zynq FPGA manager reviews we decided that manipulating the 
>> bitstream
>> to be consumable by the driver is userland's job.
> Moritz, Can you remind me what that issue was there (or point me to
> that email, I can't find it)?  I don't think I had a problem with that
> in your case.  In general I think if these drivers can take the
> bitstream that comes from the manufacturer's tools and stuff it into
> the FPGA, then we are accomplishing what we want.  So I am OK with
> this here.  The intent of the driver is to load a standard rbf, same
> as the other Altera FPGA drivers.
> There is a problem here though it will be easy to fix.  This call to
> revbit8x4 should happen in cyclonespi_write(), not in
> cyclonespi_write_init(). The reason for that is that write_init() may
> just get the first chunk of the image (the header) and that write()
> will be called multiple times for the remaining chunks.  The current
> FPGA manager API won't show this problem since you have to give
> fpga_mgr_buf_load the whole image buffer at once.  But it is easy to
> imagine that some time in the future we may want to expand the FPGA
> manager API to support streaming where we don't have the whole buffer.
OK.
If generic lsb first support for SPI is too high a bar (which it may be),
I will move the bit reversing code into the write function.
> Thanks for submitting, Joshua.  Will be looking at this over the
> next several days.
>
> Alan
Thanks for the quick response!
I'll be looking forward to your review,

Joshua Clayton

[PATCH v5 05/17] ext2: return -EIO on ext2_iomap_end() failure

[Ross Zwisler]

Right now we just return 0 for success, but we really want to let callers
know about this failure.

Signed-off-by: Ross Zwisler 
---
 fs/ext2/inode.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/fs/ext2/inode.c b/fs/ext2/inode.c
index c7dbb46..368913c 100644
--- a/fs/ext2/inode.c
+++ b/fs/ext2/inode.c
@@ -830,8 +830,10 @@ ext2_iomap_end(struct inode *inode, loff_t offset, loff_t 
length,
 {
if (iomap->type == IOMAP_MAPPED &&
written < length &&
-   (flags & IOMAP_WRITE))
+   (flags & IOMAP_WRITE)) {
ext2_write_failed(inode->i_mapping, offset + length);
+   return -EIO;
+   }
return 0;
 }
 
-- 
2.7.4

Re: [PATCH] net: Reset skb to network header in neigh_hh_output

[Eric Dumazet]

On Fri, 2016-10-07 at 16:14 +0200, Abdelrhman Ahmed wrote:
> When hardware header is added without using cached one, neigh_resolve_output
> and neigh_connected_output reset skb to network header before adding it.
> When cached one is used, neigh_hh_output does not reset the skb to network
> header.
> 
> The fix is to reset skb to network header before adding cached hardware header
> to keep the behavior consistent in all cases.

What is the issue you want to fix exactly ?

Please describe the use case.

I highly suggest you take a look at commit

e1f165032c8bade3a6bdf546f8faf61fda4dd01c
("net: Fix skb_under_panic oops in neigh_resolve_output")

Otherwise, your fix is in fact adding a critical bug.

[PATCH v5 11/17] dax: correct dax iomap code namespace

[Ross Zwisler]

The recently added DAX functions that use the new struct iomap data
structure were named iomap_dax_rw(), iomap_dax_fault() and
iomap_dax_actor().  These are actually defined in fs/dax.c, though, so
should be part of the "dax" namespace and not the "iomap" namespace.
Rename them to dax_iomap_rw(), dax_iomap_fault() and dax_iomap_actor()
respectively.

Signed-off-by: Ross Zwisler 
Suggested-by: Dave Chinner 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Jan Kara 
---
 fs/dax.c| 16 
 fs/ext2/file.c  |  6 +++---
 fs/xfs/xfs_file.c   |  8 
 include/linux/dax.h |  4 ++--
 4 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/fs/dax.c b/fs/dax.c
index 1b9154a..982ccbb 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1024,7 +1024,7 @@ EXPORT_SYMBOL_GPL(dax_truncate_page);
 
 #ifdef CONFIG_FS_IOMAP
 static loff_t
-iomap_dax_actor(struct inode *inode, loff_t pos, loff_t length, void *data,
+dax_iomap_actor(struct inode *inode, loff_t pos, loff_t length, void *data,
struct iomap *iomap)
 {
struct iov_iter *iter = data;
@@ -1081,7 +1081,7 @@ iomap_dax_actor(struct inode *inode, loff_t pos, loff_t 
length, void *data,
 }
 
 /**
- * iomap_dax_rw - Perform I/O to a DAX file
+ * dax_iomap_rw - Perform I/O to a DAX file
  * @iocb:  The control block for this I/O
  * @iter:  The addresses to do I/O from or to
  * @ops:   iomap ops passed from the file system
@@ -1091,7 +1091,7 @@ iomap_dax_actor(struct inode *inode, loff_t pos, loff_t 
length, void *data,
  * and evicting any page cache pages in the region under I/O.
  */
 ssize_t
-iomap_dax_rw(struct kiocb *iocb, struct iov_iter *iter,
+dax_iomap_rw(struct kiocb *iocb, struct iov_iter *iter,
struct iomap_ops *ops)
 {
struct address_space *mapping = iocb->ki_filp->f_mapping;
@@ -1121,7 +1121,7 @@ iomap_dax_rw(struct kiocb *iocb, struct iov_iter *iter,
 
while (iov_iter_count(iter)) {
ret = iomap_apply(inode, pos, iov_iter_count(iter), flags, ops,
-   iter, iomap_dax_actor);
+   iter, dax_iomap_actor);
if (ret <= 0)
break;
pos += ret;
@@ -1131,10 +1131,10 @@ iomap_dax_rw(struct kiocb *iocb, struct iov_iter *iter,
iocb->ki_pos += done;
return done ? done : ret;
 }
-EXPORT_SYMBOL_GPL(iomap_dax_rw);
+EXPORT_SYMBOL_GPL(dax_iomap_rw);
 
 /**
- * iomap_dax_fault - handle a page fault on a DAX file
+ * dax_iomap_fault - handle a page fault on a DAX file
  * @vma: The virtual memory area where the fault occurred
  * @vmf: The description of the fault
  * @ops: iomap ops passed from the file system
@@ -1143,7 +1143,7 @@ EXPORT_SYMBOL_GPL(iomap_dax_rw);
  * or mkwrite handler for DAX files. Assumes the caller has done all the
  * necessary locking for the page fault to proceed successfully.
  */
-int iomap_dax_fault(struct vm_area_struct *vma, struct vm_fault *vmf,
+int dax_iomap_fault(struct vm_area_struct *vma, struct vm_fault *vmf,
struct iomap_ops *ops)
 {
struct address_space *mapping = vma->vm_file->f_mapping;
@@ -1245,5 +1245,5 @@ int iomap_dax_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf,
return VM_FAULT_SIGBUS | major;
return VM_FAULT_NOPAGE | major;
 }
-EXPORT_SYMBOL_GPL(iomap_dax_fault);
+EXPORT_SYMBOL_GPL(dax_iomap_fault);
 #endif /* CONFIG_FS_IOMAP */
diff --git a/fs/ext2/file.c b/fs/ext2/file.c
index 0f257f8..32a4913 100644
--- a/fs/ext2/file.c
+++ b/fs/ext2/file.c
@@ -38,7 +38,7 @@ static ssize_t ext2_dax_read_iter(struct kiocb *iocb, struct 
iov_iter *to)
return 0; /* skip atime */
 
inode_lock_shared(inode);
-   ret = iomap_dax_rw(iocb, to, _iomap_ops);
+   ret = dax_iomap_rw(iocb, to, _iomap_ops);
inode_unlock_shared(inode);
 
file_accessed(iocb->ki_filp);
@@ -62,7 +62,7 @@ static ssize_t ext2_dax_write_iter(struct kiocb *iocb, struct 
iov_iter *from)
if (ret)
goto out_unlock;
 
-   ret = iomap_dax_rw(iocb, from, _iomap_ops);
+   ret = dax_iomap_rw(iocb, from, _iomap_ops);
if (ret > 0 && iocb->ki_pos > i_size_read(inode)) {
i_size_write(inode, iocb->ki_pos);
mark_inode_dirty(inode);
@@ -99,7 +99,7 @@ static int ext2_dax_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf)
}
down_read(>dax_sem);
 
-   ret = iomap_dax_fault(vma, vmf, _iomap_ops);
+   ret = dax_iomap_fault(vma, vmf, _iomap_ops);
 
up_read(>dax_sem);
if (vmf->flags & FAULT_FLAG_WRITE)
diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index de7c53c..8f12152 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -344,7 +344,7 @@ xfs_file_dax_read(
return 0; /* skip atime */
 
xfs_rw_ilock(ip, XFS_IOLOCK_SHARED);
-   ret = 

[PATCH v5 09/17] dax: coordinate locking for offsets in PMD range

[Ross Zwisler]

DAX radix tree locking currently locks entries based on the unique
combination of the 'mapping' pointer and the pgoff_t 'index' for the entry.
This works for PTEs, but as we move to PMDs we will need to have all the
offsets within the range covered by the PMD to map to the same bit lock.
To accomplish this, for ranges covered by a PMD entry we will instead lock
based on the page offset of the beginning of the PMD entry.  The 'mapping'
pointer is still used in the same way.

Signed-off-by: Ross Zwisler 
---
 fs/dax.c| 58 +++--
 include/linux/dax.h |  2 +-
 mm/filemap.c|  2 +-
 3 files changed, 36 insertions(+), 26 deletions(-)

diff --git a/fs/dax.c b/fs/dax.c
index 152a6e1..608cee9 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -64,14 +64,6 @@ static int __init init_dax_wait_table(void)
 }
 fs_initcall(init_dax_wait_table);
 
-static wait_queue_head_t *dax_entry_waitqueue(struct address_space *mapping,
- pgoff_t index)
-{
-   unsigned long hash = hash_long((unsigned long)mapping ^ index,
-  DAX_WAIT_TABLE_BITS);
-   return wait_table + hash;
-}
-
 static long dax_map_atomic(struct block_device *bdev, struct blk_dax_ctl *dax)
 {
struct request_queue *q = bdev->bd_queue;
@@ -285,7 +277,7 @@ EXPORT_SYMBOL_GPL(dax_do_io);
  */
 struct exceptional_entry_key {
struct address_space *mapping;
-   unsigned long index;
+   pgoff_t entry_start;
 };
 
 struct wait_exceptional_entry_queue {
@@ -293,6 +285,26 @@ struct wait_exceptional_entry_queue {
struct exceptional_entry_key key;
 };
 
+static wait_queue_head_t *dax_entry_waitqueue(struct address_space *mapping,
+   pgoff_t index, void *entry, struct exceptional_entry_key *key)
+{
+   unsigned long hash;
+
+   /*
+* If 'entry' is a PMD, align the 'index' that we use for the wait
+* queue to the start of that PMD.  This ensures that all offsets in
+* the range covered by the PMD map to the same bit lock.
+*/
+   if (RADIX_DAX_TYPE(entry) == RADIX_DAX_PMD)
+   index &= ~((1UL << (PMD_SHIFT - PAGE_SHIFT)) - 1);
+
+   key->mapping = mapping;
+   key->entry_start = index;
+
+   hash = hash_long((unsigned long)mapping ^ index, DAX_WAIT_TABLE_BITS);
+   return wait_table + hash;
+}
+
 static int wake_exceptional_entry_func(wait_queue_t *wait, unsigned int mode,
   int sync, void *keyp)
 {
@@ -301,7 +313,7 @@ static int wake_exceptional_entry_func(wait_queue_t *wait, 
unsigned int mode,
container_of(wait, struct wait_exceptional_entry_queue, wait);
 
if (key->mapping != ewait->key.mapping ||
-   key->index != ewait->key.index)
+   key->entry_start != ewait->key.entry_start)
return 0;
return autoremove_wake_function(wait, mode, sync, NULL);
 }
@@ -359,12 +371,10 @@ static void *get_unlocked_mapping_entry(struct 
address_space *mapping,
 {
void *entry, **slot;
struct wait_exceptional_entry_queue ewait;
-   wait_queue_head_t *wq = dax_entry_waitqueue(mapping, index);
+   wait_queue_head_t *wq;
 
init_wait();
ewait.wait.func = wake_exceptional_entry_func;
-   ewait.key.mapping = mapping;
-   ewait.key.index = index;
 
for (;;) {
entry = __radix_tree_lookup(>page_tree, index, NULL,
@@ -375,6 +385,8 @@ static void *get_unlocked_mapping_entry(struct 
address_space *mapping,
*slotp = slot;
return entry;
}
+
+   wq = dax_entry_waitqueue(mapping, index, entry, );
prepare_to_wait_exclusive(wq, ,
  TASK_UNINTERRUPTIBLE);
spin_unlock_irq(>tree_lock);
@@ -448,9 +460,12 @@ restart:
 }
 
 void dax_wake_mapping_entry_waiter(struct address_space *mapping,
-  pgoff_t index, bool wake_all)
+   pgoff_t index, void *entry, bool wake_all)
 {
-   wait_queue_head_t *wq = dax_entry_waitqueue(mapping, index);
+   struct exceptional_entry_key key;
+   wait_queue_head_t *wq;
+
+   wq = dax_entry_waitqueue(mapping, index, entry, );
 
/*
 * Checking for locked entry and prepare_to_wait_exclusive() happens
@@ -458,13 +473,8 @@ void dax_wake_mapping_entry_waiter(struct address_space 
*mapping,
 * So at this point all tasks that could have seen our entry locked
 * must be in the waitqueue and the following check will see them.
 */
-   if (waitqueue_active(wq)) {
-   struct exceptional_entry_key key;
-
-   key.mapping = mapping;
-   key.index = index;
+   if (waitqueue_active(wq))
__wake_up(wq, TASK_NORMAL, wake_all ? 0 : 1, );
-   }
 }

[PATCH v5 10/17] dax: remove dax_pmd_fault()

[Ross Zwisler]

dax_pmd_fault() is the old struct buffer_head + get_block_t based 2 MiB DAX
fault handler.  This fault handler has been disabled for several kernel
releases, and support for PMDs will be reintroduced using the struct iomap
interface instead.

Signed-off-by: Ross Zwisler 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Jan Kara 
---
 fs/dax.c| 213 
 include/linux/dax.h |   6 +-
 2 files changed, 1 insertion(+), 218 deletions(-)

diff --git a/fs/dax.c b/fs/dax.c
index 608cee9..1b9154a 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -908,219 +908,6 @@ int dax_fault(struct vm_area_struct *vma, struct vm_fault 
*vmf,
 }
 EXPORT_SYMBOL_GPL(dax_fault);
 
-#if defined(CONFIG_TRANSPARENT_HUGEPAGE)
-/*
- * The 'colour' (ie low bits) within a PMD of a page offset.  This comes up
- * more often than one might expect in the below function.
- */
-#define PG_PMD_COLOUR  ((PMD_SIZE >> PAGE_SHIFT) - 1)
-
-static void __dax_dbg(struct buffer_head *bh, unsigned long address,
-   const char *reason, const char *fn)
-{
-   if (bh) {
-   char bname[BDEVNAME_SIZE];
-   bdevname(bh->b_bdev, bname);
-   pr_debug("%s: %s addr: %lx dev %s state %lx start %lld "
-   "length %zd fallback: %s\n", fn, current->comm,
-   address, bname, bh->b_state, (u64)bh->b_blocknr,
-   bh->b_size, reason);
-   } else {
-   pr_debug("%s: %s addr: %lx fallback: %s\n", fn,
-   current->comm, address, reason);
-   }
-}
-
-#define dax_pmd_dbg(bh, address, reason)   __dax_dbg(bh, address, reason, 
"dax_pmd")
-
-/**
- * dax_pmd_fault - handle a PMD fault on a DAX file
- * @vma: The virtual memory area where the fault occurred
- * @vmf: The description of the fault
- * @get_block: The filesystem method used to translate file offsets to blocks
- *
- * When a page fault occurs, filesystems may call this helper in their
- * pmd_fault handler for DAX files.
- */
-int dax_pmd_fault(struct vm_area_struct *vma, unsigned long address,
-   pmd_t *pmd, unsigned int flags, get_block_t get_block)
-{
-   struct file *file = vma->vm_file;
-   struct address_space *mapping = file->f_mapping;
-   struct inode *inode = mapping->host;
-   struct buffer_head bh;
-   unsigned blkbits = inode->i_blkbits;
-   unsigned long pmd_addr = address & PMD_MASK;
-   bool write = flags & FAULT_FLAG_WRITE;
-   struct block_device *bdev;
-   pgoff_t size, pgoff;
-   sector_t block;
-   int result = 0;
-   bool alloc = false;
-
-   /* dax pmd mappings require pfn_t_devmap() */
-   if (!IS_ENABLED(CONFIG_FS_DAX_PMD))
-   return VM_FAULT_FALLBACK;
-
-   /* Fall back to PTEs if we're going to COW */
-   if (write && !(vma->vm_flags & VM_SHARED)) {
-   split_huge_pmd(vma, pmd, address);
-   dax_pmd_dbg(NULL, address, "cow write");
-   return VM_FAULT_FALLBACK;
-   }
-   /* If the PMD would extend outside the VMA */
-   if (pmd_addr < vma->vm_start) {
-   dax_pmd_dbg(NULL, address, "vma start unaligned");
-   return VM_FAULT_FALLBACK;
-   }
-   if ((pmd_addr + PMD_SIZE) > vma->vm_end) {
-   dax_pmd_dbg(NULL, address, "vma end unaligned");
-   return VM_FAULT_FALLBACK;
-   }
-
-   pgoff = linear_page_index(vma, pmd_addr);
-   size = (i_size_read(inode) + PAGE_SIZE - 1) >> PAGE_SHIFT;
-   if (pgoff >= size)
-   return VM_FAULT_SIGBUS;
-   /* If the PMD would cover blocks out of the file */
-   if ((pgoff | PG_PMD_COLOUR) >= size) {
-   dax_pmd_dbg(NULL, address,
-   "offset + huge page size > file size");
-   return VM_FAULT_FALLBACK;
-   }
-
-   memset(, 0, sizeof(bh));
-   bh.b_bdev = inode->i_sb->s_bdev;
-   block = (sector_t)pgoff << (PAGE_SHIFT - blkbits);
-
-   bh.b_size = PMD_SIZE;
-
-   if (get_block(inode, block, , 0) != 0)
-   return VM_FAULT_SIGBUS;
-
-   if (!buffer_mapped() && write) {
-   if (get_block(inode, block, , 1) != 0)
-   return VM_FAULT_SIGBUS;
-   alloc = true;
-   WARN_ON_ONCE(buffer_unwritten() || buffer_new());
-   }
-
-   bdev = bh.b_bdev;
-
-   if (bh.b_size < PMD_SIZE) {
-   dax_pmd_dbg(, address, "allocated block too small");
-   return VM_FAULT_FALLBACK;
-   }
-
-   /*
-* If we allocated new storage, make sure no process has any
-* zero pages covering this hole
-*/
-   if (alloc) {
-   loff_t lstart = pgoff << PAGE_SHIFT;
-   loff_t lend = lstart + PMD_SIZE - 1; /* inclusive */
-
-   truncate_pagecache_range(inode, lstart, lend);

[PATCH] coresight: reset "enable_sink" flag when need be

[Mathieu Poirier]

When using coresight from the perf interface sinks are specified
as part of the perf command line.  As such the sink needs to be
disabled once it has been acknowledged by the coresight framework.
Otherwise the sink stays enabled, which may interfere with other
sessions.

This patch removes the sink selection check from the build path
process and make it a function on it's own.  The function is
then used when operating from sysFS or perf to determine what
sink has been selected.

Signed-off-by: Mathieu Poirier 
---
 drivers/hwtracing/coresight/coresight-etm-perf.c | 31 ++--
 drivers/hwtracing/coresight/coresight-priv.h |  4 +-
 drivers/hwtracing/coresight/coresight.c  | 62 +---
 3 files changed, 75 insertions(+), 22 deletions(-)

diff --git a/drivers/hwtracing/coresight/coresight-etm-perf.c 
b/drivers/hwtracing/coresight/coresight-etm-perf.c
index 2cd7c718198a..1103073b2640 100644
--- a/drivers/hwtracing/coresight/coresight-etm-perf.c
+++ b/drivers/hwtracing/coresight/coresight-etm-perf.c
@@ -202,6 +202,21 @@ static void *etm_setup_aux(int event_cpu, void **pages,
if (!event_data)
return NULL;
 
+   /*
+* In theory nothing prevent tracers in a trace session from being
+* associated with different sinks, nor having a sink per tracer.  But
+* until we have HW with this kind of topolog we need to assume tracers
+* in a trace session are using the same sink.  Therefore go through
+* the coresight bus and pick the first enabled sink.
+*
+* When operated from sysFS users are responsible to enable the sink
+* while from perf, the perf tools will do it based on the choice made
+* on the cmd line.  As such the "enable_sink" flag in sysFS is reset.
+*/
+   sink = coresight_get_enabled_sink(true);
+   if (!sink)
+   return NULL;
+
INIT_WORK(_data->work, free_event_data);
 
mask = _data->mask;
@@ -219,25 +234,11 @@ static void *etm_setup_aux(int event_cpu, void **pages,
 * list of devices from source to sink that can be
 * referenced later when the path is actually needed.
 */
-   event_data->path[cpu] = coresight_build_path(csdev);
+   event_data->path[cpu] = coresight_build_path(csdev, sink);
if (IS_ERR(event_data->path[cpu]))
goto err;
}
 
-   /*
-* In theory nothing prevent tracers in a trace session from being
-* associated with different sinks, nor having a sink per tracer.  But
-* until we have HW with this kind of topology and a way to convey
-* sink assignement from the perf cmd line we need to assume tracers
-* in a trace session are using the same sink.  Therefore pick the sink
-* found at the end of the first available path.
-*/
-   cpu = cpumask_first(mask);
-   /* Grab the sink at the end of the path */
-   sink = coresight_get_sink(event_data->path[cpu]);
-   if (!sink)
-   goto err;
-
if (!sink_ops(sink)->alloc_buffer)
goto err;
 
diff --git a/drivers/hwtracing/coresight/coresight-priv.h 
b/drivers/hwtracing/coresight/coresight-priv.h
index 196a14be4b3d..ef9d8e93e3b2 100644
--- a/drivers/hwtracing/coresight/coresight-priv.h
+++ b/drivers/hwtracing/coresight/coresight-priv.h
@@ -111,7 +111,9 @@ static inline void CS_UNLOCK(void __iomem *addr)
 void coresight_disable_path(struct list_head *path);
 int coresight_enable_path(struct list_head *path, u32 mode);
 struct coresight_device *coresight_get_sink(struct list_head *path);
-struct list_head *coresight_build_path(struct coresight_device *csdev);
+struct coresight_device *coresight_get_enabled_sink(bool reset);
+struct list_head *coresight_build_path(struct coresight_device *csdev,
+  struct coresight_device *sink);
 void coresight_release_path(struct list_head *path);
 
 #ifdef CONFIG_CORESIGHT_SOURCE_ETM3X
diff --git a/drivers/hwtracing/coresight/coresight.c 
b/drivers/hwtracing/coresight/coresight.c
index 7bf00a0beb6f..40ede643d553 100644
--- a/drivers/hwtracing/coresight/coresight.c
+++ b/drivers/hwtracing/coresight/coresight.c
@@ -368,6 +368,40 @@ struct coresight_device *coresight_get_sink(struct 
list_head *path)
return csdev;
 }
 
+static int coresight_enabled_sink(struct device *dev, void *data)
+{
+   bool *reset = data;
+   struct coresight_device *csdev = to_coresight_device(dev);
+
+   if ((csdev->type == CORESIGHT_DEV_TYPE_SINK ||
+csdev->type == CORESIGHT_DEV_TYPE_LINKSINK) &&
+csdev->activated) {
+   /*
+* Now that we have a handle on the sink for this session,
+* disable the sysFS "enable_sink" flag so that possible
+* concurrent perf session that wish to use 

[PATCH v5 13/17] dax: dax_iomap_fault() needs to call iomap_end()

[Ross Zwisler]

Currently iomap_end() doesn't do anything for DAX page faults for both ext2
and XFS.  ext2_iomap_end() just checks for a write underrun, and
xfs_file_iomap_end() checks to see if it needs to finish a delayed
allocation.  However, in the future iomap_end() calls might be needed to
make sure we have balanced allocations, locks, etc.  So, add calls to
iomap_end() with appropriate error handling to dax_iomap_fault().

Signed-off-by: Ross Zwisler 
Suggested-by: Jan Kara 
---
 fs/dax.c | 31 ---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/fs/dax.c b/fs/dax.c
index 7689ab0..5e8febe 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1187,7 +1187,7 @@ int dax_iomap_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf,
goto unlock_entry;
if (WARN_ON_ONCE(iomap.offset + iomap.length < pos + PAGE_SIZE)) {
error = -EIO;   /* fs corruption? */
-   goto unlock_entry;
+   goto finish_iomap;
}
 
sector = dax_iomap_sector(, pos);
@@ -1209,7 +1209,14 @@ int dax_iomap_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf,
}
 
if (error)
-   goto unlock_entry;
+   goto finish_iomap;
+
+   if (ops->iomap_end) {
+   error = ops->iomap_end(inode, pos, PAGE_SIZE,
+   PAGE_SIZE, flags, );
+   if (error)
+   goto unlock_entry;
+   }
if (!radix_tree_exceptional_entry(entry)) {
vmf->page = entry;
return VM_FAULT_LOCKED;
@@ -1230,8 +1237,15 @@ int dax_iomap_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf,
break;
case IOMAP_UNWRITTEN:
case IOMAP_HOLE:
-   if (!(vmf->flags & FAULT_FLAG_WRITE))
+   if (!(vmf->flags & FAULT_FLAG_WRITE)) {
+   if (ops->iomap_end)  {
+   error = ops->iomap_end(inode, pos, PAGE_SIZE,
+   PAGE_SIZE, flags, );
+   if (error)
+   goto unlock_entry;
+   }
return dax_load_hole(mapping, entry, vmf);
+   }
/*FALLTHRU*/
default:
WARN_ON_ONCE(1);
@@ -1239,6 +1253,17 @@ int dax_iomap_fault(struct vm_area_struct *vma, struct 
vm_fault *vmf,
break;
}
 
+ finish_iomap:
+   if (ops->iomap_end) {
+   if (error) {
+   /* keep previous error */
+   ops->iomap_end(inode, pos, PAGE_SIZE, PAGE_SIZE, flags,
+   );
+   } else {
+   error = ops->iomap_end(inode, pos, PAGE_SIZE,
+   PAGE_SIZE, flags, );
+   }
+   }
  unlock_entry:
put_locked_mapping_entry(mapping, vmf->pgoff, entry);
  out:
-- 
2.7.4

[PATCH v5 16/17] xfs: use struct iomap based DAX PMD fault path

[Ross Zwisler]

Switch xfs_filemap_pmd_fault() from using dax_pmd_fault() to the new and
improved dax_iomap_pmd_fault().  Also, now that it has no more users,
remove xfs_get_blocks_dax_fault().

Signed-off-by: Ross Zwisler 
---
 fs/xfs/xfs_aops.c | 26 +-
 fs/xfs/xfs_aops.h |  3 ---
 fs/xfs/xfs_file.c |  2 +-
 3 files changed, 6 insertions(+), 25 deletions(-)

diff --git a/fs/xfs/xfs_aops.c b/fs/xfs/xfs_aops.c
index 0e2a931..1c73d0a 100644
--- a/fs/xfs/xfs_aops.c
+++ b/fs/xfs/xfs_aops.c
@@ -1298,8 +1298,7 @@ __xfs_get_blocks(
sector_tiblock,
struct buffer_head  *bh_result,
int create,
-   booldirect,
-   booldax_fault)
+   booldirect)
 {
struct xfs_inode*ip = XFS_I(inode);
struct xfs_mount*mp = ip->i_mount;
@@ -1420,13 +1419,8 @@ __xfs_get_blocks(
if (ISUNWRITTEN())
set_buffer_unwritten(bh_result);
/* direct IO needs special help */
-   if (create) {
-   if (dax_fault)
-   ASSERT(!ISUNWRITTEN());
-   else
-   xfs_map_direct(inode, bh_result, , offset,
-   is_cow);
-   }
+   if (create)
+   xfs_map_direct(inode, bh_result, , offset, is_cow);
}
 
/*
@@ -1466,7 +1460,7 @@ xfs_get_blocks(
struct buffer_head  *bh_result,
int create)
 {
-   return __xfs_get_blocks(inode, iblock, bh_result, create, false, false);
+   return __xfs_get_blocks(inode, iblock, bh_result, create, false);
 }
 
 int
@@ -1476,17 +1470,7 @@ xfs_get_blocks_direct(
struct buffer_head  *bh_result,
int create)
 {
-   return __xfs_get_blocks(inode, iblock, bh_result, create, true, false);
-}
-
-int
-xfs_get_blocks_dax_fault(
-   struct inode*inode,
-   sector_tiblock,
-   struct buffer_head  *bh_result,
-   int create)
-{
-   return __xfs_get_blocks(inode, iblock, bh_result, create, true, true);
+   return __xfs_get_blocks(inode, iblock, bh_result, create, true);
 }
 
 /*
diff --git a/fs/xfs/xfs_aops.h b/fs/xfs/xfs_aops.h
index b3c6634..34dc00d 100644
--- a/fs/xfs/xfs_aops.h
+++ b/fs/xfs/xfs_aops.h
@@ -59,9 +59,6 @@ int   xfs_get_blocks(struct inode *inode, sector_t offset,
   struct buffer_head *map_bh, int create);
 intxfs_get_blocks_direct(struct inode *inode, sector_t offset,
  struct buffer_head *map_bh, int create);
-intxfs_get_blocks_dax_fault(struct inode *inode, sector_t offset,
-struct buffer_head *map_bh, int create);
-
 intxfs_end_io_direct_write(struct kiocb *iocb, loff_t offset,
ssize_t size, void *private);
 intxfs_setfilesize(struct xfs_inode *ip, xfs_off_t offset, size_t size);
diff --git a/fs/xfs/xfs_file.c b/fs/xfs/xfs_file.c
index 8f12152..7b13dda 100644
--- a/fs/xfs/xfs_file.c
+++ b/fs/xfs/xfs_file.c
@@ -1750,7 +1750,7 @@ xfs_filemap_pmd_fault(
}
 
xfs_ilock(XFS_I(inode), XFS_MMAPLOCK_SHARED);
-   ret = dax_pmd_fault(vma, addr, pmd, flags, xfs_get_blocks_dax_fault);
+   ret = dax_iomap_pmd_fault(vma, addr, pmd, flags, _iomap_ops);
xfs_iunlock(XFS_I(inode), XFS_MMAPLOCK_SHARED);
 
if (flags & FAULT_FLAG_WRITE)
-- 
2.7.4

[PATCH V3 08/10] ras: acpi / apei: generate trace event for unrecognized CPER section

[Tyler Baicar]

UEFI spec allows for non-standard section in Common Platform Error
Record. This is defined in section N.2.3 of UEFI version 2.5.

Currently if the CPER section's type (UUID) does not match with
any section type that the kernel knows how to parse, trace event
is not generated for such section. And thus user is not able to know
happening of such hardware error, including error record of
non-standard section.

This commit generates a trace event which contains raw error data
for unrecognized CPER section.

Signed-off-by: Jonathan (Zhixiong) Zhang 
Signed-off-by: Tyler Baicar 
---
 drivers/acpi/apei/ghes.c | 18 +-
 drivers/ras/ras.c|  1 +
 include/ras/ras_event.h  | 45 +
 3 files changed, 63 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 36894c8..cb4c7f4 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -49,6 +49,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef CONFIG_HAVE_ACPI_APEI_SEA
 #include 
@@ -468,12 +469,21 @@ static void ghes_do_proc(struct ghes *ghes,
int sev, sec_sev;
struct acpi_hest_generic_data *gdata;
uuid_le sec_type;
+   uuid_le *fru_id;
+   char *fru_text = "";
 
sev = ghes_severity(estatus->error_severity);
apei_estatus_for_each_section(estatus, gdata) {
sec_sev = ghes_severity(gdata->error_severity);
sec_type = *(uuid_le *)gdata->section_type;
 
+   if (gdata->validation_bits & CPER_SEC_VALID_FRU_ID)
+   fru_id = (uuid_le *)gdata->fru_id;
+   else
+   fru_id = _UUID_LE;
+   if (gdata->validation_bits & CPER_SEC_VALID_FRU_TEXT)
+   fru_text = gdata->fru_text;
+
if (!uuid_le_cmp(sec_type,
 CPER_SEC_PLATFORM_MEM)) {
struct cper_sec_mem_err *mem_err;
@@ -485,7 +495,7 @@ static void ghes_do_proc(struct ghes *ghes,
ghes_handle_memory_failure(gdata, sev);
}
 #ifdef CONFIG_ACPI_APEI_PCIEAER
-   else if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
+   else if (!uuid_le_cmp(sec_type,
  CPER_SEC_PCIE)) {
struct cper_sec_pcie *pcie_err;
 
@@ -518,6 +528,12 @@ static void ghes_do_proc(struct ghes *ghes,
 
}
 #endif
+   else {
+   void *unknown_err = 
acpi_hest_generic_data_payload(gdata);
+   trace_unknown_sec_event(_type,
+   fru_id, fru_text, sec_sev,
+   unknown_err, gdata->error_data_length);
+   }
}
 }
 
diff --git a/drivers/ras/ras.c b/drivers/ras/ras.c
index b67dd36..fb2500b 100644
--- a/drivers/ras/ras.c
+++ b/drivers/ras/ras.c
@@ -27,3 +27,4 @@ subsys_initcall(ras_init);
 EXPORT_TRACEPOINT_SYMBOL_GPL(extlog_mem_event);
 #endif
 EXPORT_TRACEPOINT_SYMBOL_GPL(mc_event);
+EXPORT_TRACEPOINT_SYMBOL_GPL(unknown_sec_event);
diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
index 1791a12..5861b6f 100644
--- a/include/ras/ras_event.h
+++ b/include/ras/ras_event.h
@@ -162,6 +162,51 @@ TRACE_EVENT(mc_event,
 );
 
 /*
+ * Unknown Section Report
+ *
+ * This event is generated when hardware detected a hardware
+ * error event, which may be of non-standard section as defined
+ * in UEFI spec appendix "Common Platform Error Record", or may
+ * be of sections for which TRACE_EVENT is not defined.
+ *
+ */
+TRACE_EVENT(unknown_sec_event,
+
+   TP_PROTO(const uuid_le *sec_type,
+const uuid_le *fru_id,
+const char *fru_text,
+const u8 sev,
+const u8 *err,
+const u32 len),
+
+   TP_ARGS(sec_type, fru_id, fru_text, sev, err, len),
+
+   TP_STRUCT__entry(
+   __array(char, sec_type, 16)
+   __array(char, fru_id, 16)
+   __string(fru_text, fru_text)
+   __field(u8, sev)
+   __field(u32, len)
+   __dynamic_array(u8, buf, len)
+   ),
+
+   TP_fast_assign(
+   memcpy(__entry->sec_type, sec_type, sizeof(uuid_le));
+   memcpy(__entry->fru_id, fru_id, sizeof(uuid_le));
+   __assign_str(fru_text, fru_text);
+   __entry->sev = sev;
+   __entry->len = len;
+   memcpy(__get_dynamic_array(buf), err, len);
+   ),
+
+   TP_printk("severity: %d; sec type:%pU; FRU: %pU %s; data len:%d; raw 
data:%s",
+ __entry->sev, __entry->sec_type,
+ __entry->fru_id, __get_str(fru_text),
+ __entry->len,
+ __print_hex(__get_dynamic_array(buf), __entry->len))
+);
+
+/*
  * PCIe AER Trace event
  *
  * 

Re: [PATCH -v4 1/8] locking/drm: Kill mutex trickery

[Waiman Long]

On 10/07/2016 12:13 PM, Peter Zijlstra wrote:

On Fri, Oct 07, 2016 at 08:58:43AM -0700, Linus Torvalds wrote:

The other choice would be to just make the choices be negative (==
recursive), zero (== failed) or positive (== got lock), which allows
for the same value re-use for the non-recursive case, and you could
avoid the enum entirely.

I thought about that, but liked the enum better for having to then spell
it out.

I'll go make the enum shout and add comment as you suggest.


I like the idea of having a tri-state returned value (<0, 0, >0). I 
don't mind having the enum, but just making mutex_trylock_recursive 
equal to -1 will be great.


Cheers,
Longman

Re: [PATCH] metag: Only define atomic_dec_if_positive conditionally

[James Hogan]

On Fri, Oct 07, 2016 at 10:40:59AM -0700, Guenter Roeck wrote:
> The definition of atomic_dec_if_positive() assumes that
> atomic_sub_if_positive() exists, which is only the case if
> metag specific atomics are used. This results in the following
> build error when trying to build metag1_defconfig.
> 
> kernel/ucount.c: In function 'dec_ucount':
> kernel/ucount.c:211: error:
>   implicit declaration of function 'atomic_sub_if_positive'
> 
> Moving the definition of atomic_dec_if_positive() into the metag
> conditional code fixes the problem.
> 
> Signed-off-by: Guenter Roeck 
> ---
>  arch/metag/include/asm/atomic.h | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/arch/metag/include/asm/atomic.h b/arch/metag/include/asm/atomic.h
> index 470e365f04ea..8ff0a70865f6 100644
> --- a/arch/metag/include/asm/atomic.h
> +++ b/arch/metag/include/asm/atomic.h
> @@ -39,11 +39,10 @@
>  #define atomic_dec(v) atomic_sub(1, (v))
>  
>  #define atomic_inc_not_zero(v) atomic_add_unless((v), 1, 0)
> +#define atomic_dec_if_positive(v)   atomic_sub_if_positive(1, v)
>  
>  #endif
>  
> -#define atomic_dec_if_positive(v)   atomic_sub_if_positive(1, v)
> -
>  #include 
>  
>  #endif /* __ASM_METAG_ATOMIC_H */

Applied, thanks Guenter!

Cheers
James



signature.asc
Description: Digital signature

[PATCH] crypto: crypto4xx - Fix size used in dma_free_coherent()

[Christophe JAILLET]

The size used in 'dma_free_coherent()' looks un-initialized here.
ctx->sa_len is set a few lines below and is apparently not set by the
caller.
So use 'size' as in the corresponding 'dma_alloc_coherent()' a few lines
above.

This has been spotted with coccinelle, using the following script:

@r@
expression x0, x1, y0, y1, z0, z1, t0, t1, ret;
@@

*   ret = dma_alloc_coherent(x0, y0, z0, t0);
...
*   dma_free_coherent(x1, y1, ret, t1);


@script:python@
y0 << r.y0;
y1 << r.y1;

@@
if y1.find(y0) == -1:
 print "WARNING: sizes look different:  '%s'   vs   '%s'" % (y0, y1)


Signed-off-by: Christophe JAILLET 
---
 drivers/crypto/amcc/crypto4xx_core.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/crypto/amcc/crypto4xx_core.c 
b/drivers/crypto/amcc/crypto4xx_core.c
index dae1e39139e9..d10b4ae5e0da 100644
--- a/drivers/crypto/amcc/crypto4xx_core.c
+++ b/drivers/crypto/amcc/crypto4xx_core.c
@@ -135,8 +135,7 @@ int crypto4xx_alloc_sa(struct crypto4xx_ctx *ctx, u32 size)
ctx->sa_out = dma_alloc_coherent(ctx->dev->core_dev->device, size * 4,
 >sa_out_dma_addr, GFP_ATOMIC);
if (ctx->sa_out == NULL) {
-   dma_free_coherent(ctx->dev->core_dev->device,
- ctx->sa_len * 4,
+   dma_free_coherent(ctx->dev->core_dev->device, size * 4,
  ctx->sa_in, ctx->sa_in_dma_addr);
return -ENOMEM;
}
-- 
2.7.4

Re: [PATCH 2/3] doc: dt: add cyclone-spi binding document

[Joshua Clayton]

Moritz,

thank you very much for the review.
 
On 10/06/2016 07:53 PM, Moritz Fischer wrote:
> Hi Joshua,
>
> On Thu, Oct 6, 2016 at 1:34 PM, Joshua Clayton  
> wrote:
>> Describe a cyclonespi devicetree entry, required features
>>
>> Signed-off-by: Joshua Clayton 
>> ---
>>  .../bindings/fpga/cyclone-spi-fpga-mgr.txt | 23 
>> ++
>>  1 file changed, 23 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/fpga/cyclone-spi-fpga-mgr.txt
>>
>> diff --git a/Documentation/devicetree/bindings/fpga/cyclone-spi-fpga-mgr.txt 
>> b/Documentation/devicetree/bindings/fpga/cyclone-spi-fpga-mgr.txt
>> new file mode 100644
>> index 000..8de34db
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/fpga/cyclone-spi-fpga-mgr.txt
>> @@ -0,0 +1,23 @@
>> +Altera SOCFPGA FPGA Manager
> Copy & Paste? :)
Oops :(
As you might image, documentation was the last item done with the least 
attention.
Will fix.
>
>> +Altera cyclone FPGAs support a method of loading the bitstream over what is
> cyclone->Cyclone
OK.
>> +referred to as "passive serial".
>> +The passive serial link is not technically spi, and might require extra
>> +circuits in order to play nicely with other spi slaves on the same bus.
>> +
>> +See https://www.altera.com/literature/hb/cyc/cyc_c51013.pdf
>> +
>> +Required properties:
>> +- compatible  : should contain "altr,cyclonespi-fpga-mgr"
> Alan, do you guys have any input on the compat string?
I am open to change if it makes sense. I tried to keep the format similar.
> I think generally the bindings should go before the actual usage in
> your patch series. Meaning you wanna document the binding
> before you use it. I think this patch should be [1/3].
Ah, In my mind I had it backwards.
> Cheers,
>
> Moritz
I'll give Alan a chance to review and then spin a V2

Joshua Clayton

Re: [PATCH v13 12/15] vfio: Allow reserved msi iova registration

[Alex Williamson]

On Fri, 7 Oct 2016 19:11:43 +0200
Auger Eric  wrote:

> Hi Alex,
> 
> On 06/10/2016 22:19, Alex Williamson wrote:
> > On Thu,  6 Oct 2016 08:45:28 +
> > Eric Auger  wrote:
> >   
> >> The user is allowed to register a reserved MSI IOVA range by using the
> >> DMA MAP API and setting the new flag: VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA.
> >> This region is stored in the vfio_dma rb tree. At that point the iova
> >> range is not mapped to any target address yet. The host kernel will use
> >> those iova when needed, typically when MSIs are allocated.
> >>
> >> Signed-off-by: Eric Auger 
> >> Signed-off-by: Bharat Bhushan 
> >>
> >> ---
> >> v12 -> v13:
> >> - use iommu_get_dma_msi_region_cookie
> >>
> >> v9 -> v10
> >> - use VFIO_IOVA_RESERVED_MSI enum value
> >>
> >> v7 -> v8:
> >> - use iommu_msi_set_aperture function. There is no notion of
> >>   unregistration anymore since the reserved msi slot remains
> >>   until the container gets closed.
> >>
> >> v6 -> v7:
> >> - use iommu_free_reserved_iova_domain
> >> - convey prot attributes downto dma-reserved-iommu iova domain creation
> >> - reserved bindings teardown now performed on iommu domain destruction
> >> - rename VFIO_DMA_MAP_FLAG_MSI_RESERVED_IOVA into
> >>  VFIO_DMA_MAP_FLAG_RESERVED_MSI_IOVA
> >> - change title
> >> - pass the protection attribute to dma-reserved-iommu API
> >>
> >> v3 -> v4:
> >> - use iommu_alloc/free_reserved_iova_domain exported by dma-reserved-iommu
> >> - protect vfio_register_reserved_iova_range implementation with
> >>   CONFIG_IOMMU_DMA_RESERVED
> >> - handle unregistration by user-space and on vfio_iommu_type1 release
> >>
> >> v1 -> v2:
> >> - set returned value according to alloc_reserved_iova_domain result
> >> - free the iova domains in case any error occurs
> >>
> >> RFC v1 -> v1:
> >> - takes into account Alex comments, based on
> >>   [RFC PATCH 1/6] vfio: Add interface for add/del reserved iova region:
> >> - use the existing dma map/unmap ioctl interface with a flag to register
> >>   a reserved IOVA range. A single reserved iova region is allowed.
> >> ---
> >>  drivers/vfio/vfio_iommu_type1.c | 77 
> >> -
> >>  include/uapi/linux/vfio.h   | 10 +-
> >>  2 files changed, 85 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/vfio/vfio_iommu_type1.c 
> >> b/drivers/vfio/vfio_iommu_type1.c
> >> index 5bc5fc9..c2f8bd9 100644
> >> --- a/drivers/vfio/vfio_iommu_type1.c
> >> +++ b/drivers/vfio/vfio_iommu_type1.c
> >> @@ -442,6 +442,20 @@ static void vfio_unmap_unpin(struct vfio_iommu 
> >> *iommu, struct vfio_dma *dma)
> >>vfio_lock_acct(-unlocked);
> >>  }
> >>  
> >> +static int vfio_set_msi_aperture(struct vfio_iommu *iommu,
> >> +  dma_addr_t iova, size_t size)
> >> +{
> >> +  struct vfio_domain *d;
> >> +  int ret = 0;
> >> +
> >> +  list_for_each_entry(d, >domain_list, next) {
> >> +  ret = iommu_get_dma_msi_region_cookie(d->domain, iova, size);
> >> +  if (ret)
> >> +  break;
> >> +  }
> >> +  return ret;  
> > 
> > Doesn't this need an unwind on failure loop?  
> At the moment the de-allocation is done by the smmu driver, on
> domain_free ops, which calls iommu_put_dma_cookie. In case,
> iommu_get_dma_msi_region_cookie fails on a given VFIO domain currently
> there is no other way but destroying all VFIO domains and redo everything.
> 
> So yes I plan to unfold everything, ie call iommu_put_dma_cookie for
> each domain.

That's a pretty harsh user experience isn't it?  They potentially have
some domains where the cookie is setup and others without and they have
no means to recover except to tear it all down and start over?  Thanks,

Alex

[PATCH] wan/fsl_ucc_hdlc: Fix size used in dma_free_coherent()

[Christophe JAILLET]

Size used with 'dma_alloc_coherent()' and 'dma_free_coherent()' should be
consistent.
Here, the size of a pointer is used in dma_alloc... and the size of the
pointed structure is used in dma_free...

This has been spotted with coccinelle, using the following script:

@r@
expression x0, x1, y0, y1, z0, z1, t0, t1, ret;
@@

*   ret = dma_alloc_coherent(x0, y0, z0, t0);
...
*   dma_free_coherent(x1, y1, ret, t1);


@script:python@
y0 << r.y0;
y1 << r.y1;

@@
if y1.find(y0) == -1:
 print "WARNING: sizes look different:  '%s'   vs   '%s'" % (y0, y1)


Signed-off-by: Christophe JAILLET 
---
Untested
---
 drivers/net/wan/fsl_ucc_hdlc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/wan/fsl_ucc_hdlc.c b/drivers/net/wan/fsl_ucc_hdlc.c
index 5fbf83d5aa57..65647533b401 100644
--- a/drivers/net/wan/fsl_ucc_hdlc.c
+++ b/drivers/net/wan/fsl_ucc_hdlc.c
@@ -295,11 +295,11 @@ static int uhdlc_init(struct ucc_hdlc_private *priv)
qe_muram_free(priv->ucc_pram_offset);
 free_tx_bd:
dma_free_coherent(priv->dev,
- TX_BD_RING_LEN * sizeof(struct qe_bd),
+ TX_BD_RING_LEN * sizeof(struct qe_bd *),
  priv->tx_bd_base, priv->dma_tx_bd);
 free_rx_bd:
dma_free_coherent(priv->dev,
- RX_BD_RING_LEN * sizeof(struct qe_bd),
+ RX_BD_RING_LEN * sizeof(struct qe_bd *),
  priv->rx_bd_base, priv->dma_rx_bd);
 free_uccf:
ucc_fast_free(priv->uccf);
@@ -688,7 +688,7 @@ static void uhdlc_memclean(struct ucc_hdlc_private *priv)
 
if (priv->rx_bd_base) {
dma_free_coherent(priv->dev,
- RX_BD_RING_LEN * sizeof(struct qe_bd),
+ RX_BD_RING_LEN * sizeof(struct qe_bd *),
  priv->rx_bd_base, priv->dma_rx_bd);
 
priv->rx_bd_base = NULL;
@@ -697,7 +697,7 @@ static void uhdlc_memclean(struct ucc_hdlc_private *priv)
 
if (priv->tx_bd_base) {
dma_free_coherent(priv->dev,
- TX_BD_RING_LEN * sizeof(struct qe_bd),
+ TX_BD_RING_LEN * sizeof(struct qe_bd *),
  priv->tx_bd_base, priv->dma_tx_bd);
 
priv->tx_bd_base = NULL;
-- 
2.7.4

Re: [GIT PULL] trivial for 4.9

[Linus Torvalds]

On Fri, Oct 7, 2016 at 1:33 PM, Joe Perches  wrote:
>>
>> And if there are behavioral issues, they should (a) be pointed out and
>> (b) be fixed.
>>
>> In *no* case does it make sense to randomly just add newline
>> characters without even having a reason for it.
>
> It prevents random interleaving from those other
> 12000+ possible printk calls without an explicit
> KERN_

YOU ARE NOT LISTENING.

Let me do this really clearly and slowly.

I'm not applying patches that

 (a) are random churn

 (b) make the code uglier

 (c) are about purely theoretical problems IN OTHER CODE.

How hard is that to understand? The "\n"-adding patches are ALL of the
above. They don't fix a problem, they actually *hide* problems, and
they hide problems that

 (1) do not matter

 (2) aren't in the code that the "\n"-adding patch even adds.

See?

So stop with the idiotic theoretical arguments about interleaving that
isn't even true.

Instead, start with the *actual* problems. First off, if somebody
actually reports an issue like the above, fix *that*.

And btw, even without an explicit KERN_, you should still not
get any interleaving. Only an _explicit_ KERN_CONT should cause
interleaving, and dammit, if some interrupt does a KERN_CONT without
having had a non-cont printk before it, that code is buggy and should
damn well be fixed.

And if it's not an interrupt, then the "not the same task as last
time" should add the newline.

In other words, all your arguments seem entirely wrong. IF that
interleaving actually happens, we have bugs that should be fixed.

Again: we should not add stupid churn that doesn't even fix the bugs,
just makes code harder to read and adds churn.

Seriously.

If you can send me a patch to *fix* anything, go ahead. But stop this
idiotic "let's add random pointless newline characters" crap already.

   Linus

[PATCH v2 1/2] Staging:greybus:arche-apb-ctrl: fix trailing */ Block comments and 80 character line limit coding style issue

[Nadim Almas]

Fixed coding style issue

Signed-off-by: Nadim Almas 
---
Changes in v2:
  - Used space after leading * in block comments.

 drivers/staging/greybus/arche-apb-ctrl.c | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/greybus/arche-apb-ctrl.c 
b/drivers/staging/greybus/arche-apb-ctrl.c
index 70323aa..eeba912 100644
--- a/drivers/staging/greybus/arche-apb-ctrl.c
+++ b/drivers/staging/greybus/arche-apb-ctrl.c
@@ -168,7 +168,10 @@ static int standby_boot_seq(struct platform_device *pdev)
if (apb->init_disabled)
return 0;
 
-   /* Even if it is in OFF state, then we do not want to change the state 
*/
+   /*
+* Even if it is in OFF state,
+* then we do not want to change the state
+*/
if (apb->state == ARCHE_PLATFORM_STATE_STANDBY ||
apb->state == ARCHE_PLATFORM_STATE_OFF)
return 0;
@@ -183,7 +186,7 @@ static int standby_boot_seq(struct platform_device *pdev)
 * Pasted from WDM spec,
 *  - A falling edge on POWEROFF_L is detected (a)
 *  - WDM enters standby mode, but no output signals are changed
-* */
+*/
 
/* TODO: POWEROFF_L is input to WDM module  */
apb->state = ARCHE_PLATFORM_STATE_STANDBY;
@@ -286,7 +289,8 @@ static ssize_t state_store(struct device *dev,
return count;
 
/* First we want to make sure we power off everything
-* and then enter FW flashing state */
+* and then enter FW flashing state
+*/
poweroff_seq(pdev);
ret = fw_flashing_seq(pdev);
} else {
-- 
2.7.4

[PATCH v5 17/17] dax: remove "depends on BROKEN" from FS_DAX_PMD

[Ross Zwisler]

Now that DAX PMD faults are once again working and are now participating in
DAX's radix tree locking scheme, allow their config option to be enabled.

Signed-off-by: Ross Zwisler 
---
 fs/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/fs/Kconfig b/fs/Kconfig
index 2bc7ad7..b6f0fce 100644
--- a/fs/Kconfig
+++ b/fs/Kconfig
@@ -55,7 +55,6 @@ config FS_DAX_PMD
depends on FS_DAX
depends on ZONE_DEVICE
depends on TRANSPARENT_HUGEPAGE
-   depends on BROKEN
 
 endif # BLOCK
 
-- 
2.7.4

[PATCH v5 06/17] dax: make 'wait_table' global variable static

[Ross Zwisler]

The global 'wait_table' variable is only used within fs/dax.c, and
generates the following sparse warning:

fs/dax.c:39:19: warning: symbol 'wait_table' was not declared. Should it be 
static?

Make it static so it has scope local to fs/dax.c, and to make sparse happy.

Signed-off-by: Ross Zwisler 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Jan Kara 
---
 fs/dax.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/dax.c b/fs/dax.c
index 9b9be8a..ac28cdf 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -52,7 +52,7 @@
 #define DAX_WAIT_TABLE_BITS 12
 #define DAX_WAIT_TABLE_ENTRIES (1 << DAX_WAIT_TABLE_BITS)
 
-wait_queue_head_t wait_table[DAX_WAIT_TABLE_ENTRIES];
+static wait_queue_head_t wait_table[DAX_WAIT_TABLE_ENTRIES];
 
 static int __init init_dax_wait_table(void)
 {
-- 
2.7.4

[PATCH v5 00/17] re-enable DAX PMD support

[Ross Zwisler]

DAX PMDs have been disabled since Jan Kara introduced DAX radix tree based
locking.  This series allows DAX PMDs to participate in the DAX radix tree
based locking scheme so that they can be re-enabled.

Dave, can you please take this through the XFS tree as we discussed during
the v4 review?

Changes since v4:
 - Reworked the DAX flags handling to simplify things and get rid of
   RADIX_DAX_PTE. (Jan & Christoph)
 - Moved RADIX_DAX_* macros to be inline functions in include/linux/dax.h.
   (Christoph)
 - Got rid of unneeded macros RADIX_DAX_HZP_ENTRY() and
   RADIX_DAX_EMPTY_ENTRY(), and instead just pass arbitrary flags to
   radix_dax_entry().
 - Re-ordered the arguments to dax_wake_mapping_entry_waiter() to be more
   consistent with the rest of the code. (Jan)
 - Moved radix_dax_order() inside of the #ifdef CONFIG_FS_DAX_PMD block.
   This was causing a build error on various systems that don't define
   PMD_SHIFT.
 - Patch 5 fixes what I believe is a missing error return in
   ext2_iomap_end().
 - Fixed the page_start calculation for PMDs that was previously found in
   dax_entry_start().  (Jan)  This code is now included directly in
   dax_entry_waitqueue().  (Christoph)
 - dax_entry_waitqueue() now sets up the struct exceptional_entry_key() of
   the caller as a service to reduce code duplication. (Christoph)
 - In grab_mapping_entry() we now hold the radix tree entry lock for PMD
   downgrades while we release the tree_lock and do an
   unmap_mapping_range().  (Jan)
 - Removed our last BUG_ON() in dax.c, replacing it with a WARN_ON_ONCE()
   and an error return.
 - The dax_iomap_fault() and dax_iomap_pmd_fault() handlers both now call
   ops->iomap_end() to ensure that we properly balance the
   ops->iomap_begin() calls with respect to locking, allocations, etc.
   (Jan)
 - Removed __GFP_FS from the vmf.gfp_mask used in dax_iomap_pmd_fault().
   (Jan)

Thank you again to Jan, Christoph and Dave for their review feedback.

Here are some related things that are not included in this patch set, but
which I plan on doing in the near future:
 - Add tracepoint support for the PTE and PMD based DAX fault handlers.
   (Dave)
 - Move the DAX 4k zero page handling to use a single 4k zero page instead
   of allocating pages on demand.  This will mirror the way that things are
   done for the 2 MiB case, and will reduce the amount of memory we use
   when reading 4k holes in DAX.
 - Change the API to the PMD fault hanlder so it takes a vmf, and at a
   layer above DAX make sure that the vmf.gfp_mask given to DAX for both
   PMD and PTE faults doesn't include __GFP_FS. (Jan)

These work items will happen after review & integration with Jan's patch
set for DAX radix tree cleaning.

This series was built upon xfs/xfs-4.9-reflink with PMD performance fixes
from Toshi Kani and Dan Williams.  Dan's patch has already been merged for
v4.8, and Toshi's patches are currently queued in Andrew Morton's mm tree
for v4.9 inclusion.  These patches are not needed for correct operation,
only for good performance.

Here is a tree containing my changes:
https://git.kernel.org/cgit/linux/kernel/git/zwisler/linux.git/log/?h=dax_pmd_v5

This tree has passed xfstests for ext2, ext4 and XFS both with and without
DAX, and has passed targeted testing where I inserted, removed and flushed
DAX PTEs and PMDs in every combination I could think of.

Previously reported performance numbers:

In some simple mmap I/O testing with FIO the use of PMD faults more than
doubles I/O performance as compared with PTE faults.  Here is the FIO
script I used for my testing:

  [global]
  bs=4k
  size=2G
  directory=/mnt/pmem0
  ioengine=mmap
  [randrw]
  rw=randrw

Here are the performance results with XFS using only pte faults:
   READ: io=1022.7MB, aggrb=557610KB/s, minb=557610KB/s, maxb=557610KB/s, 
mint=1878msec, maxt=1878msec
  WRITE: io=1025.4MB, aggrb=559084KB/s, minb=559084KB/s, maxb=559084KB/s, 
mint=1878msec, maxt=1878msec

Here are performance numbers for that same test using PMD faults:
   READ: io=1022.7MB, aggrb=1406.7MB/s, minb=1406.7MB/s, maxb=1406.7MB/s, 
mint=727msec, maxt=727msec
  WRITE: io=1025.4MB, aggrb=1410.4MB/s, minb=1410.4MB/s, maxb=1410.4MB/s, 
mint=727msec, maxt=727msec

This was done on a random lab machine with a PMEM device made from memmap'd
RAM.  To get XFS to use PMD faults, I did the following:

  mkfs.xfs -f -d su=2m,sw=1 /dev/pmem0
  mount -o dax /dev/pmem0 /mnt/pmem0
  xfs_io -c "extsize 2m" /mnt/pmem0

Ross Zwisler (17):
  ext4: allow DAX writeback for hole punch
  ext4: tell DAX the size of allocation holes
  dax: remove buffer_size_valid()
  ext2: remove support for DAX PMD faults
  ext2: return -EIO on ext2_iomap_end() failure
  dax: make 'wait_table' global variable static
  dax: remove the last BUG_ON() from fs/dax.c
  dax: consistent variable naming for DAX entries
  dax: coordinate locking for offsets in PMD range
  dax: remove dax_pmd_fault()
  dax: correct dax iomap code namespace
  dax: add 

[PATCH v5 07/17] dax: remove the last BUG_ON() from fs/dax.c

[Ross Zwisler]

Don't take down the kernel if we get an invalid 'from' and 'length'
argument pair.  Just warn once and return an error.

Signed-off-by: Ross Zwisler 
---
 fs/dax.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/fs/dax.c b/fs/dax.c
index ac28cdf..98189ac 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -1194,7 +1194,8 @@ int dax_zero_page_range(struct inode *inode, loff_t from, 
unsigned length,
/* Block boundary? Nothing to do */
if (!length)
return 0;
-   BUG_ON((offset + length) > PAGE_SIZE);
+   if (WARN_ON_ONCE((offset + length) > PAGE_SIZE))
+   return -EINVAL;
 
memset(, 0, sizeof(bh));
bh.b_bdev = inode->i_sb->s_bdev;
-- 
2.7.4

[PATCH v5 08/17] dax: consistent variable naming for DAX entries

[Ross Zwisler]

No functional change.

Consistently use the variable name 'entry' instead of 'ret' for DAX radix
tree entries.  This was already happening in most of the code, so update
get_unlocked_mapping_entry(), grab_mapping_entry() and
dax_unlock_mapping_entry().

Signed-off-by: Ross Zwisler 
Reviewed-by: Christoph Hellwig 
Reviewed-by: Jan Kara 
---
 fs/dax.c | 34 +-
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/fs/dax.c b/fs/dax.c
index 98189ac..152a6e1 100644
--- a/fs/dax.c
+++ b/fs/dax.c
@@ -357,7 +357,7 @@ static inline void *unlock_slot(struct address_space 
*mapping, void **slot)
 static void *get_unlocked_mapping_entry(struct address_space *mapping,
pgoff_t index, void ***slotp)
 {
-   void *ret, **slot;
+   void *entry, **slot;
struct wait_exceptional_entry_queue ewait;
wait_queue_head_t *wq = dax_entry_waitqueue(mapping, index);
 
@@ -367,13 +367,13 @@ static void *get_unlocked_mapping_entry(struct 
address_space *mapping,
ewait.key.index = index;
 
for (;;) {
-   ret = __radix_tree_lookup(>page_tree, index, NULL,
+   entry = __radix_tree_lookup(>page_tree, index, NULL,
  );
-   if (!ret || !radix_tree_exceptional_entry(ret) ||
+   if (!entry || !radix_tree_exceptional_entry(entry) ||
!slot_locked(mapping, slot)) {
if (slotp)
*slotp = slot;
-   return ret;
+   return entry;
}
prepare_to_wait_exclusive(wq, ,
  TASK_UNINTERRUPTIBLE);
@@ -396,13 +396,13 @@ static void *get_unlocked_mapping_entry(struct 
address_space *mapping,
  */
 static void *grab_mapping_entry(struct address_space *mapping, pgoff_t index)
 {
-   void *ret, **slot;
+   void *entry, **slot;
 
 restart:
spin_lock_irq(>tree_lock);
-   ret = get_unlocked_mapping_entry(mapping, index, );
+   entry = get_unlocked_mapping_entry(mapping, index, );
/* No entry for given index? Make sure radix tree is big enough. */
-   if (!ret) {
+   if (!entry) {
int err;
 
spin_unlock_irq(>tree_lock);
@@ -410,10 +410,10 @@ restart:
mapping_gfp_mask(mapping) & ~__GFP_HIGHMEM);
if (err)
return ERR_PTR(err);
-   ret = (void *)(RADIX_TREE_EXCEPTIONAL_ENTRY |
+   entry = (void *)(RADIX_TREE_EXCEPTIONAL_ENTRY |
   RADIX_DAX_ENTRY_LOCK);
spin_lock_irq(>tree_lock);
-   err = radix_tree_insert(>page_tree, index, ret);
+   err = radix_tree_insert(>page_tree, index, entry);
radix_tree_preload_end();
if (err) {
spin_unlock_irq(>tree_lock);
@@ -425,11 +425,11 @@ restart:
/* Good, we have inserted empty locked entry into the tree. */
mapping->nrexceptional++;
spin_unlock_irq(>tree_lock);
-   return ret;
+   return entry;
}
/* Normal page in radix tree? */
-   if (!radix_tree_exceptional_entry(ret)) {
-   struct page *page = ret;
+   if (!radix_tree_exceptional_entry(entry)) {
+   struct page *page = entry;
 
get_page(page);
spin_unlock_irq(>tree_lock);
@@ -442,9 +442,9 @@ restart:
}
return page;
}
-   ret = lock_slot(mapping, slot);
+   entry = lock_slot(mapping, slot);
spin_unlock_irq(>tree_lock);
-   return ret;
+   return entry;
 }
 
 void dax_wake_mapping_entry_waiter(struct address_space *mapping,
@@ -469,11 +469,11 @@ void dax_wake_mapping_entry_waiter(struct address_space 
*mapping,
 
 void dax_unlock_mapping_entry(struct address_space *mapping, pgoff_t index)
 {
-   void *ret, **slot;
+   void *entry, **slot;
 
spin_lock_irq(>tree_lock);
-   ret = __radix_tree_lookup(>page_tree, index, NULL, );
-   if (WARN_ON_ONCE(!ret || !radix_tree_exceptional_entry(ret) ||
+   entry = __radix_tree_lookup(>page_tree, index, NULL, );
+   if (WARN_ON_ONCE(!entry || !radix_tree_exceptional_entry(entry) ||
 !slot_locked(mapping, slot))) {
spin_unlock_irq(>tree_lock);
return;
-- 
2.7.4

[PATCH V3 02/10] ras: acpi/apei: cper: generic error data entry v3 per ACPI 6.1

[Tyler Baicar]

Currently when a RAS error is reported it is not timestamped.
The ACPI 6.1 spec adds the timestamp field to the generic error
data entry v3 structure. The timestamp of when the firmware
generated the error is now being reported.

Signed-off-by: Jonathan (Zhixiong) Zhang 
Signed-off-by: Richard Ruigrok 
Signed-off-by: Tyler Baicar 
Signed-off-by: Naveen Kaje 
---
 drivers/acpi/apei/ghes.c| 25 ++--
 drivers/firmware/efi/cper.c | 97 +++--
 2 files changed, 105 insertions(+), 17 deletions(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 3021f0e..c8488f1 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -80,6 +80,10 @@
((struct acpi_hest_generic_status *)\
 ((struct ghes_estatus_node *)(estatus_node) + 1))
 
+#define acpi_hest_generic_data_version(gdata)  \
+   (gdata->revision >> 8)
+
+
 /*
  * This driver isn't really modular, however for the time being,
  * continuing to use module_param is the easiest way to remain
@@ -412,6 +416,13 @@ static void ghes_clear_estatus(struct ghes *ghes)
ghes->flags &= ~GHES_TO_CLEAR;
 }
 
+inline void *acpi_hest_generic_data_payload(struct acpi_hest_generic_data 
*gdata)
+{
+   return acpi_hest_generic_data_version(gdata) >= 3 ?
+   (void *)(((struct acpi_hest_generic_data_v300 *)(gdata)) + 1) :
+   gdata + 1;
+}
+
 static void ghes_handle_memory_failure(struct acpi_hest_generic_data *gdata, 
int sev)
 {
 #ifdef CONFIG_ACPI_APEI_MEMORY_FAILURE
@@ -419,7 +430,8 @@ static void ghes_handle_memory_failure(struct 
acpi_hest_generic_data *gdata, int
int flags = -1;
int sec_sev = ghes_severity(gdata->error_severity);
struct cper_sec_mem_err *mem_err;
-   mem_err = (struct cper_sec_mem_err *)(gdata + 1);
+
+   mem_err = acpi_hest_generic_data_payload(gdata);
 
if (!(mem_err->validation_bits & CPER_MEM_VALID_PA))
return;
@@ -449,14 +461,18 @@ static void ghes_do_proc(struct ghes *ghes,
 {
int sev, sec_sev;
struct acpi_hest_generic_data *gdata;
+   uuid_le sec_type;
 
sev = ghes_severity(estatus->error_severity);
apei_estatus_for_each_section(estatus, gdata) {
sec_sev = ghes_severity(gdata->error_severity);
-   if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
+   sec_type = *(uuid_le *)gdata->section_type;
+
+   if (!uuid_le_cmp(sec_type,
 CPER_SEC_PLATFORM_MEM)) {
struct cper_sec_mem_err *mem_err;
-   mem_err = (struct cper_sec_mem_err *)(gdata+1);
+
+   mem_err = acpi_hest_generic_data_payload(gdata);
ghes_edac_report_mem_error(ghes, sev, mem_err);
 
arch_apei_report_mem_error(sev, mem_err);
@@ -466,7 +482,8 @@ static void ghes_do_proc(struct ghes *ghes,
else if (!uuid_le_cmp(*(uuid_le *)gdata->section_type,
  CPER_SEC_PCIE)) {
struct cper_sec_pcie *pcie_err;
-   pcie_err = (struct cper_sec_pcie *)(gdata+1);
+
+   pcie_err = acpi_hest_generic_data_payload(gdata);
if (sev == GHES_SEV_RECOVERABLE &&
sec_sev == GHES_SEV_RECOVERABLE &&
pcie_err->validation_bits & 
CPER_PCIE_VALID_DEVICE_ID &&
diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
index d425374..9fa1317 100644
--- a/drivers/firmware/efi/cper.c
+++ b/drivers/firmware/efi/cper.c
@@ -32,9 +32,14 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #define INDENT_SP  " "
 
+#define acpi_hest_generic_data_version(gdata)  \
+   (gdata->revision >> 8)
+
 static char rcd_decode_str[CPER_REC_LEN];
 
 /*
@@ -386,13 +391,47 @@ static void cper_print_pcie(const char *pfx, const struct 
cper_sec_pcie *pcie,
pfx, pcie->bridge.secondary_status, pcie->bridge.control);
 }
 
+static inline void *acpi_hest_generic_data_payload(struct 
acpi_hest_generic_data *gdata)
+{
+   return acpi_hest_generic_data_version(gdata) >= 3 ?
+   (void *)(((struct acpi_hest_generic_data_v300 *)(gdata)) + 1) :
+   gdata + 1;
+}
+
+static void cper_estatus_print_section_v300(const char *pfx,
+   const struct acpi_hest_generic_data_v300 *gdata)
+{
+   __u8 hour, min, sec, day, mon, year, century, *timestamp;
+
+   if (gdata->validation_bits & ACPI_HEST_GEN_VALID_TIMESTAMP) {
+   timestamp = (__u8 *)&(gdata->time_stamp);
+   memcpy(, timestamp, 1);
+   memcpy(, timestamp + 1, 1);
+   memcpy(, timestamp + 2, 1);
+   memcpy(, timestamp + 4, 1);
+  

[PATCH V3 03/10] efi: parse ARMv8 processor error

[Tyler Baicar]

Add support for ARMv8 Common Platform Error Record (CPER).
UEFI 2.6 specification adds support for ARMv8 specific
processor error information to be reported as part of the
CPER records. This provides more detail on for processor error logs.

Signed-off-by: Jonathan (Zhixiong) Zhang 
Signed-off-by: Tyler Baicar 
Signed-off-by: Naveen Kaje 
---
 drivers/firmware/efi/cper.c | 135 
 include/linux/cper.h|  72 +++
 2 files changed, 207 insertions(+)

diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
index 9fa1317..2594245 100644
--- a/drivers/firmware/efi/cper.c
+++ b/drivers/firmware/efi/cper.c
@@ -112,12 +112,15 @@ void cper_print_bits(const char *pfx, unsigned int bits,
 static const char * const proc_type_strs[] = {
"IA32/X64",
"IA64",
+   "ARMv8",
 };
 
 static const char * const proc_isa_strs[] = {
"IA32",
"IA64",
"X64",
+   "ARM A32/T32",
+   "ARM A64",
 };
 
 static const char * const proc_error_type_strs[] = {
@@ -186,6 +189,129 @@ static void cper_print_proc_generic(const char *pfx,
printk("%s""IP: 0x%016llx\n", pfx, proc->ip);
 }
 
+static void cper_print_proc_armv8(const char *pfx,
+ const struct cper_sec_proc_armv8 *proc)
+{
+   int i, len;
+   struct cper_armv8_err_info *err_info;
+   __u64 *qword = NULL;
+   char newpfx[64];
+
+   printk("%ssection length: %d\n", pfx, proc->section_length);
+   printk("%sMIDR: 0x%016llx\n", pfx, proc->midr);
+
+   len = proc->section_length - (sizeof(*proc) +
+   proc->err_info_num * (sizeof(*err_info)));
+   if (len < 0) {
+   printk("%ssection length is too small.\n", pfx);
+   printk("%sERR_INFO_NUM is %d.\n", pfx, proc->err_info_num);
+   return;
+   }
+
+   if (proc->validation_bits & CPER_ARMV8_VALID_MPIDR)
+   printk("%sMPIDR: 0x%016llx\n", pfx, proc->mpidr);
+   if (proc->validation_bits & CPER_ARMV8_VALID_AFFINITY_LEVEL)
+   printk("%serror affinity level: %d\n", pfx,
+   proc->affinity_level);
+   if (proc->validation_bits & CPER_ARMV8_VALID_RUNNING_STATE) {
+   printk("%srunning state: %d\n", pfx, proc->running_state);
+   printk("%sPSCI state: %d\n", pfx, proc->psci_state);
+   }
+
+   snprintf(newpfx, sizeof(newpfx), "%s%s", pfx, INDENT_SP);
+
+   err_info = (struct cper_armv8_err_info *)(proc + 1);
+   for (i = 0; i < proc->err_info_num; i++) {
+   printk("%sError info structure %d:\n", pfx, i);
+   printk("%sversion:%d\n", newpfx, err_info->version);
+   printk("%slength:%d\n", newpfx, err_info->length);
+   if (err_info->validation_bits &
+   CPER_ARMV8_INFO_VALID_MULTI_ERR) {
+   if (err_info->multiple_error == 0)
+   printk("%ssingle error.\n", newpfx);
+   else if (err_info->multiple_error == 1)
+   printk("%smultiple errors.\n", newpfx);
+   else
+   printk("%smultiple errors count:%d.\n",
+   newpfx, err_info->multiple_error);
+   }
+   if (err_info->validation_bits & CPER_ARMV8_INFO_VALID_FLAGS) {
+   if (err_info->flags & CPER_ARMV8_INFO_FLAGS_FIRST)
+   printk("%sfirst error captured.\n", newpfx);
+   if (err_info->flags & CPER_ARMV8_INFO_FLAGS_LAST)
+   printk("%slast error captured.\n", newpfx);
+   if (err_info->flags & CPER_ARMV8_INFO_FLAGS_PROPAGATED)
+   printk("%spropagated error captured.\n",
+  newpfx);
+   }
+   printk("%serror_type: %d, %s\n", newpfx, err_info->type,
+   err_info->type < ARRAY_SIZE(proc_error_type_strs) ?
+   proc_error_type_strs[err_info->type] : "unknown");
+   printk("%serror_info: 0x%016llx\n", newpfx,
+  err_info->error_info);
+   if (err_info->validation_bits & CPER_ARMV8_INFO_VALID_VIRT_ADDR)
+   printk("%svirtual fault address: 0x%016llx\n",
+   newpfx, err_info->virt_fault_addr);
+   if (err_info->validation_bits &
+   CPER_ARMV8_INFO_VALID_PHYSICAL_ADDR)
+   printk("%sphysical fault address: 0x%016llx\n",
+   newpfx, err_info->physical_fault_addr);
+   err_info += 1;
+   }
+
+   if (len < sizeof(*qword) && proc->context_info_num > 0) {
+   printk("%ssection length is too 

[PATCH V3 09/10] trace, ras: add ARM processor error trace event

[Tyler Baicar]

Currently there are trace events for the various RAS
errors with the exception of ARM processor type errors.
Add a new trace event for such errors so that the user
will know when they occur. These trace events are
consistent with the ARM processor error section type
defined in UEFI 2.6 spec section N.2.4.4.

Signed-off-by: Tyler Baicar 
---
 drivers/firmware/efi/cper.c |  9 ++
 drivers/ras/ras.c   |  1 +
 include/ras/ras_event.h | 67 +
 3 files changed, 77 insertions(+)

diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
index f9ffba6..21b8a6f 100644
--- a/drivers/firmware/efi/cper.c
+++ b/drivers/firmware/efi/cper.c
@@ -34,6 +34,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define INDENT_SP  " "
 
@@ -256,6 +257,14 @@ static void cper_print_proc_armv8(const char *pfx,
CPER_ARMV8_INFO_VALID_PHYSICAL_ADDR)
printk("%sphysical fault address: 0x%016llx\n",
newpfx, err_info->physical_fault_addr);
+   trace_arm_event(proc->affinity_level, proc->mpidr, proc->midr,
+   proc->running_state, proc->psci_state,
+   err_info->version, err_info->type,
+   err_info->multiple_error,
+   err_info->validation_bits,
+   err_info->error_info,
+   err_info->virt_fault_addr,
+   err_info->physical_fault_addr);
err_info += 1;
}
 
diff --git a/drivers/ras/ras.c b/drivers/ras/ras.c
index fb2500b..8ba5a94 100644
--- a/drivers/ras/ras.c
+++ b/drivers/ras/ras.c
@@ -28,3 +28,4 @@ EXPORT_TRACEPOINT_SYMBOL_GPL(extlog_mem_event);
 #endif
 EXPORT_TRACEPOINT_SYMBOL_GPL(mc_event);
 EXPORT_TRACEPOINT_SYMBOL_GPL(unknown_sec_event);
+EXPORT_TRACEPOINT_SYMBOL_GPL(arm_event);
diff --git a/include/ras/ras_event.h b/include/ras/ras_event.h
index 5861b6f..eb2719a 100644
--- a/include/ras/ras_event.h
+++ b/include/ras/ras_event.h
@@ -162,6 +162,73 @@ TRACE_EVENT(mc_event,
 );
 
 /*
+ * ARM Processor Events Report
+ *
+ * This event is generated when hardware detects an ARM processor error
+ * has occurred. UEFI 2.6 spec section N.2.4.4.
+ */
+TRACE_EVENT(arm_event,
+
+   TP_PROTO(const u8 affinity,
+const u64 mpidr,
+const u64 midr,
+const u32 running_state,
+const u32 psci_state,
+const u8 version,
+const u8 type,
+const u16 err_count,
+const u8 flags,
+const u64 info,
+const u64 virt_fault_addr,
+const u64 phys_fault_addr),
+
+   TP_ARGS(affinity, mpidr, midr, running_state, psci_state,
+   version, type, err_count, flags, info, virt_fault_addr,
+   phys_fault_addr),
+
+   TP_STRUCT__entry(
+   __field(u8, affinity)
+   __field(u64, mpidr)
+   __field(u64, midr)
+   __field(u32, running_state)
+   __field(u32, psci_state)
+   __field(u8, version)
+   __field(u8, type)
+   __field(u16, err_count)
+   __field(u8, flags)
+   __field(u64, info)
+   __field(u64, virt_fault_addr)
+   __field(u64, phys_fault_addr)
+   ),
+
+   TP_fast_assign(
+   __entry->affinity = affinity;
+   __entry->mpidr = mpidr;
+   __entry->midr = midr;
+   __entry->running_state = running_state;
+   __entry->psci_state = psci_state;
+   __entry->version = version;
+   __entry->type = type;
+   __entry->err_count = err_count;
+   __entry->flags = flags;
+   __entry->info = info;
+   __entry->virt_fault_addr = virt_fault_addr;
+   __entry->phys_fault_addr = phys_fault_addr;
+   ),
+
+   TP_printk("affinity level: %d; MPIDR: %016llx; MIDR: %016llx; "
+ "running state: %d; PSCI state: %d; version: %d; type: %d; "
+ "error count: 0x%04x; flags: 0x%02x; info: %016llx; "
+ "virtual fault address: %016llx; "
+ "physical fault address: %016llx",
+ __entry->affinity, __entry->mpidr, __entry->midr,
+ __entry->running_state, __entry->psci_state, __entry->version,
+ __entry->type, __entry->err_count, __entry->flags,
+ __entry->info, __entry->virt_fault_addr,
+ __entry->phys_fault_addr)
+);
+
+/*
  * Unknown Section Report
  *
  * This event is generated when hardware detected a hardware
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code 

[PATCH V3 05/10] acpi: apei: handle SEA notification type for ARMv8

[Tyler Baicar]

ARM APEI extension proposal added SEA (Synchrounous External
Abort) notification type for ARMv8.
Add a new GHES error source handling function for SEA. If an error
source's notification type is SEA, then this function can be registered
into the SEA exception handler. That way GHES will parse and report
SEA exceptions when they occur.

Signed-off-by: Jonathan (Zhixiong) Zhang 
Signed-off-by: Tyler Baicar 
Signed-off-by: Naveen Kaje 
---
 arch/arm64/Kconfig|  1 +
 drivers/acpi/apei/Kconfig | 15 +
 drivers/acpi/apei/ghes.c  | 83 +++
 3 files changed, 99 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index b380c87..ae34349 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -53,6 +53,7 @@ config ARM64
select HANDLE_DOMAIN_IRQ
select HARDIRQS_SW_RESEND
select HAVE_ACPI_APEI if (ACPI && EFI)
+   select HAVE_ACPI_APEI_SEA if (ACPI && EFI)
select HAVE_ALIGNED_STRUCT_PAGE if SLUB
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_BITREVERSE
diff --git a/drivers/acpi/apei/Kconfig b/drivers/acpi/apei/Kconfig
index b0140c8..fb99c1c 100644
--- a/drivers/acpi/apei/Kconfig
+++ b/drivers/acpi/apei/Kconfig
@@ -4,6 +4,21 @@ config HAVE_ACPI_APEI
 config HAVE_ACPI_APEI_NMI
bool
 
+config HAVE_ACPI_APEI_SEA
+   bool "APEI Synchronous External Abort logging/recovering support"
+   depends on ARM64
+   help
+ This option should be enabled if the system supports
+ firmware first handling of SEA (Synchronous External Abort).
+ SEA happens with certain faults of data abort or instruction
+ abort synchronous exceptions on ARMv8 systems. If a system
+ supports firmware first handling of SEA, the platform analyzes
+ and handles hardware error notifications with SEA, and it may then
+ form a HW error record for the OS to parse and handle. This
+ option allows the OS to look for such HW error record, and
+ take appropriate action.
+
 config ACPI_APEI
bool "ACPI Platform Error Interface (APEI)"
select MISC_FILESYSTEMS
diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index c8488f1..28d5a09 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -50,6 +50,10 @@
 #include 
 #include 
 
+#ifdef CONFIG_HAVE_ACPI_APEI_SEA
+#include 
+#endif
+
 #include "apei-internal.h"
 
 #define GHES_PFX   "GHES: "
@@ -779,6 +783,62 @@ static struct notifier_block ghes_notifier_sci = {
.notifier_call = ghes_notify_sci,
 };
 
+#ifdef CONFIG_HAVE_ACPI_APEI_SEA
+static LIST_HEAD(ghes_sea);
+
+static int ghes_notify_sea(struct notifier_block *this,
+ unsigned long event, void *data)
+{
+   struct ghes *ghes;
+   int ret = NOTIFY_DONE;
+
+   rcu_read_lock();
+   list_for_each_entry_rcu(ghes, _sea, list) {
+   if (!ghes_proc(ghes))
+   ret = NOTIFY_OK;
+   }
+   rcu_read_unlock();
+
+   return ret;
+}
+
+static struct notifier_block ghes_notifier_sea = {
+   .notifier_call = ghes_notify_sea,
+};
+
+static int ghes_sea_add(struct ghes *ghes)
+{
+   mutex_lock(_list_mutex);
+   if (list_empty(_sea))
+   sea_register_handler_chain(_notifier_sea);
+   list_add_rcu(>list, _sea);
+   mutex_unlock(_list_mutex);
+   return 0;
+}
+
+static void ghes_sea_remove(struct ghes *ghes)
+{
+   mutex_lock(_list_mutex);
+   list_del_rcu(>list);
+   if (list_empty(_sea))
+   sea_unregister_handler_chain(_notifier_sea);
+   mutex_unlock(_list_mutex);
+}
+#else /* CONFIG_HAVE_ACPI_APEI_SEA */
+static inline int ghes_sea_add(struct ghes *ghes)
+{
+   pr_err(GHES_PFX "ID: %d, trying to add SEA notification which is not 
supported\n",
+  ghes->generic->header.source_id);
+   return -ENOTSUPP;
+}
+
+static inline void ghes_sea_remove(struct ghes *ghes)
+{
+   pr_err(GHES_PFX "ID: %d, trying to remove SEA notification which is not 
supported\n",
+  ghes->generic->header.source_id);
+}
+#endif /* CONFIG_HAVE_ACPI_APEI_SEA */
+
 #ifdef CONFIG_HAVE_ACPI_APEI_NMI
 /*
  * printk is not safe in NMI context.  So in NMI handler, we allocate
@@ -1023,6 +1083,14 @@ static int ghes_probe(struct platform_device *ghes_dev)
case ACPI_HEST_NOTIFY_EXTERNAL:
case ACPI_HEST_NOTIFY_SCI:
break;
+   case ACPI_HEST_NOTIFY_SEA:
+   if (!IS_ENABLED(CONFIG_HAVE_ACPI_APEI_SEA)) {
+   pr_warn(GHES_PFX "Generic hardware error source: %d 
notified via SEA is not supported\n",
+   generic->header.source_id);
+   rc = -ENOTSUPP;
+   goto err;
+   }
+   break;
case ACPI_HEST_NOTIFY_NMI:
if 

[PATCH V3 06/10] acpi: apei: panic OS with fatal error status block

[Tyler Baicar]

From: "Jonathan (Zhixiong) Zhang" 

Even if an error status block's severity is fatal, the kernel does not
honor the severity level and panic.

With the firmware first model, the platform could inform the OS about a
fatal hardware error through the non-NMI GHES notification type. The OS
should panic when a hardware error record is received with this
severity.

Call panic() after CPER data in error status block is printed if
severity is fatal, before each error section is handled.

Signed-off-by: Jonathan (Zhixiong) Zhang 
---
 drivers/acpi/apei/ghes.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/apei/ghes.c b/drivers/acpi/apei/ghes.c
index 28d5a09..36894c8 100644
--- a/drivers/acpi/apei/ghes.c
+++ b/drivers/acpi/apei/ghes.c
@@ -141,6 +141,8 @@ static unsigned long ghes_estatus_pool_size_request;
 static struct ghes_estatus_cache 
*ghes_estatus_caches[GHES_ESTATUS_CACHES_SIZE];
 static atomic_t ghes_estatus_cache_alloced;
 
+static int ghes_panic_timeout __read_mostly = 30;
+
 static int ghes_ioremap_init(void)
 {
ghes_ioremap_area = __get_vm_area(PAGE_SIZE * GHES_IOREMAP_PAGES,
@@ -715,6 +717,12 @@ static int ghes_proc(struct ghes *ghes)
if (ghes_print_estatus(NULL, ghes->generic, ghes->estatus))
ghes_estatus_cache_add(ghes->generic, ghes->estatus);
}
+   if (ghes_severity(ghes->estatus->error_severity) >= GHES_SEV_PANIC) {
+   if (panic_timeout == 0)
+   panic_timeout = ghes_panic_timeout;
+   panic("Fatal hardware error!");
+   }
+
ghes_do_proc(ghes, ghes->estatus);
 
if (ghes->generic_v2) {
@@ -859,8 +867,6 @@ static atomic_t ghes_in_nmi = ATOMIC_INIT(0);
 
 static LIST_HEAD(ghes_nmi);
 
-static int ghes_panic_timeout  __read_mostly = 30;
-
 static void ghes_proc_in_irq(struct irq_work *irq_work)
 {
struct llist_node *llnode, *next;
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

[PATCH V3 07/10] efi: print unrecognized CPER section

[Tyler Baicar]

UEFI spec allows for non-standard section in Common Platform Error
Record. This is defined in section N.2.3 of UEFI version 2.5.

Currently if the CPER section's type (UUID) does not match with
one of the section types that the kernel knows how to parse, the
section is skipped. Therefore, user is not able to see
such CPER data, for instance, error record of non-standard section.

For above mentioned case, this change prints out the raw data in
hex in dmesg buffer. Data length is taken from Error Data length
field of Generic Error Data Entry.

Following is a sample output from dmesg:
[  115.771702] {1}[Hardware Error]: Hardware error from APEI Generic Hardware 
Error Source: 2
[  115.779042] {1}[Hardware Error]: It has been corrected by h/w and requires 
no further action
[  115.787456] {1}[Hardware Error]: event severity: corrected
[  115.792927] {1}[Hardware Error]:  Error 0, type: corrected
[  115.798415] {1}[Hardware Error]:  fru_id: 
----
[  115.805596] {1}[Hardware Error]:  fru_text:
[  115.816105] {1}[Hardware Error]:  section type: 
d2e2621c-f936-468d-0d84-15a4ed015c8b
[  115.823880] {1}[Hardware Error]:  section length: 88
[  115.828779] {1}[Hardware Error]:   : 0101 0002 5f434345 
525f4543
[  115.836153] {1}[Hardware Error]:   0010: 574d   

[  115.843531] {1}[Hardware Error]:   0020:    

[  115.850908] {1}[Hardware Error]:   0030:    

[  115.858288] {1}[Hardware Error]:   0040: fe80  0004 
5f434345
[  115.865665] {1}[Hardware Error]:   0050: 525f4543 574d

Signed-off-by: Jonathan (Zhixiong) Zhang 
Signed-off-by: Tyler Baicar 
---
 drivers/firmware/efi/cper.c | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/efi/cper.c b/drivers/firmware/efi/cper.c
index 2594245..f9ffba6 100644
--- a/drivers/firmware/efi/cper.c
+++ b/drivers/firmware/efi/cper.c
@@ -605,8 +605,16 @@ static void cper_estatus_print_section(
cper_print_proc_armv8(newpfx, armv8_err);
else
goto err_section_too_small;
-   } else
-   printk("%s""section type: unknown, %pUl\n", newpfx, sec_type);
+   } else {
+   const void *unknown_err;
+
+   unknown_err = acpi_hest_generic_data_payload(gdata);
+   printk("%ssection type: %pUl\n", newpfx, sec_type);
+   printk("%ssection length: %d\n", newpfx,
+  gdata->error_data_length);
+   print_hex_dump(newpfx, "", DUMP_PREFIX_OFFSET, 16, 4,
+  unknown_err, gdata->error_data_length, 0);
+   }
 
return;
 
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

[PATCH V3 04/10] arm64: exception: handle Synchronous External Abort

[Tyler Baicar]

SEA exceptions are often caused by an uncorrected hardware
error, and are handled when data abort and instruction abort
exception classes have specific values for their Fault Status
Code.
When SEA occurs, before killing the process, go through
the handlers registered in the notification list.
Update fault_info[] with specific SEA faults so that the
new SEA handler is used.

Signed-off-by: Jonathan (Zhixiong) Zhang 
Signed-off-by: Tyler Baicar 
Signed-off-by: Naveen Kaje 
---
 arch/arm64/include/asm/system_misc.h | 13 
 arch/arm64/mm/fault.c| 58 +---
 2 files changed, 61 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/include/asm/system_misc.h 
b/arch/arm64/include/asm/system_misc.h
index 57f110b..90daf4a 100644
--- a/arch/arm64/include/asm/system_misc.h
+++ b/arch/arm64/include/asm/system_misc.h
@@ -64,4 +64,17 @@ extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, 
const char *cmd);
 
 #endif /* __ASSEMBLY__ */
 
+/*
+ * The functions below are used to register and unregister callbacks
+ * that are to be invoked when a Synchronous External Abort (SEA)
+ * occurs. An SEA is raised by certain fault status codes that have
+ * either data or instruction abort as the exception class, and
+ * callbacks may be registered to parse or handle such hardware errors.
+ *
+ * Registered callbacks are run in an interrupt/atomic context. They
+ * are not allowed to block or sleep.
+ */
+int sea_register_handler_chain(struct notifier_block *nb);
+void sea_unregister_handler_chain(struct notifier_block *nb);
+
 #endif /* __ASM_SYSTEM_MISC_H */
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 05d2bd7..81cb7ad 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -39,6 +39,22 @@
 #include 
 #include 
 
+/*
+ * GHES SEA handler code may register a notifier call here to
+ * handle HW error record passed from platform.
+ */
+static ATOMIC_NOTIFIER_HEAD(sea_handler_chain);
+
+int sea_register_handler_chain(struct notifier_block *nb)
+{
+   return atomic_notifier_chain_register(_handler_chain, nb);
+}
+
+void sea_unregister_handler_chain(struct notifier_block *nb)
+{
+   atomic_notifier_chain_unregister(_handler_chain, nb);
+}
+
 static const char *fault_name(unsigned int esr);
 
 #ifdef CONFIG_KPROBES
@@ -480,6 +496,28 @@ static int do_bad(unsigned long addr, unsigned int esr, 
struct pt_regs *regs)
return 1;
 }
 
+/*
+ * This abort handler deals with Synchronous External Abort.
+ * It calls notifiers, and then returns "fault".
+ */
+static int do_sea(unsigned long addr, unsigned int esr, struct pt_regs *regs)
+{
+   struct siginfo info;
+
+   atomic_notifier_call_chain(_handler_chain, 0, NULL);
+
+   pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
+fault_name(esr), esr, addr);
+
+   info.si_signo = SIGBUS;
+   info.si_errno = 0;
+   info.si_code  = 0;
+   info.si_addr  = (void __user *)addr;
+   arm64_notify_die("", regs, , esr);
+
+   return 0;
+}
+
 static const struct fault_info {
int (*fn)(unsigned long addr, unsigned int esr, struct pt_regs 
*regs);
int sig;
@@ -502,22 +540,22 @@ static const struct fault_info {
{ do_page_fault,SIGSEGV, SEGV_ACCERR,   "level 1 permission 
fault"  },
{ do_page_fault,SIGSEGV, SEGV_ACCERR,   "level 2 permission 
fault"  },
{ do_page_fault,SIGSEGV, SEGV_ACCERR,   "level 3 permission 
fault"  },
-   { do_bad,   SIGBUS,  0, "synchronous external 
abort"},
+   { do_sea,   SIGBUS,  0, "synchronous external 
abort"},
{ do_bad,   SIGBUS,  0, "unknown 17"
},
{ do_bad,   SIGBUS,  0, "unknown 18"
},
{ do_bad,   SIGBUS,  0, "unknown 19"
},
-   { do_bad,   SIGBUS,  0, "synchronous abort 
(translation table walk)" },
-   { do_bad,   SIGBUS,  0, "synchronous abort 
(translation table walk)" },
-   { do_bad,   SIGBUS,  0, "synchronous abort 
(translation table walk)" },
-   { do_bad,   SIGBUS,  0, "synchronous abort 
(translation table walk)" },
-   { do_bad,   SIGBUS,  0, "synchronous parity 
error"  },
+   { do_sea,   SIGBUS,  0, "level 0 SEA (trans tbl 
walk)"  },
+   { do_sea,   SIGBUS,  0, "level 1 SEA (trans tbl 
walk)"  },
+   { do_sea,   SIGBUS,  0, "level 2 SEA (trans tbl 
walk)"  },
+   { do_sea,   SIGBUS,  0, "level 3 SEA (trans tbl 
walk)"  },
+   { do_sea,   SIGBUS,  0,   

[PATCH V3 10/10] arm64: KVM: add guest SEA support

[Tyler Baicar]

Currently external aborts are unsupported by the guest abort
handling. Add handling for SEAs so that the host kernel reports
SEAs which occur in the guest kernel.

Signed-off-by: Tyler Baicar 
---
 arch/arm/include/asm/kvm_arm.h   |  1 +
 arch/arm/include/asm/system_misc.h   |  5 +
 arch/arm/kvm/mmu.c   | 15 +--
 arch/arm64/include/asm/kvm_arm.h |  1 +
 arch/arm64/include/asm/system_misc.h |  2 ++
 arch/arm64/mm/fault.c| 13 +
 6 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/arch/arm/include/asm/kvm_arm.h b/arch/arm/include/asm/kvm_arm.h
index e22089f..33a77509 100644
--- a/arch/arm/include/asm/kvm_arm.h
+++ b/arch/arm/include/asm/kvm_arm.h
@@ -187,6 +187,7 @@
 #define FSC_FAULT  (0x04)
 #define FSC_ACCESS (0x08)
 #define FSC_PERM   (0x0c)
+#define FSC_EXTABT (0x10)
 
 /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
 #define HPFAR_MASK (~0xf)
diff --git a/arch/arm/include/asm/system_misc.h 
b/arch/arm/include/asm/system_misc.h
index a3d61ad..86e1faa 100644
--- a/arch/arm/include/asm/system_misc.h
+++ b/arch/arm/include/asm/system_misc.h
@@ -24,4 +24,9 @@ extern unsigned int user_debug;
 
 #endif /* !__ASSEMBLY__ */
 
+inline int handle_guest_sea(unsigned long addr, unsigned int esr)
+{
+   return -1;
+}
+
 #endif /* __ASM_ARM_SYSTEM_MISC_H */
diff --git a/arch/arm/kvm/mmu.c b/arch/arm/kvm/mmu.c
index e9a5c0e..24cde84 100644
--- a/arch/arm/kvm/mmu.c
+++ b/arch/arm/kvm/mmu.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "trace.h"
 
@@ -1441,8 +1442,18 @@ int kvm_handle_guest_abort(struct kvm_vcpu *vcpu, struct 
kvm_run *run)
 
/* Check the stage-2 fault is trans. fault or write fault */
fault_status = kvm_vcpu_trap_get_fault_type(vcpu);
-   if (fault_status != FSC_FAULT && fault_status != FSC_PERM &&
-   fault_status != FSC_ACCESS) {
+
+   if (fault_status == FSC_EXTABT) {
+   if(handle_guest_sea((unsigned long)fault_ipa,
+   kvm_vcpu_get_hsr(vcpu))) {
+   kvm_err("Failed to handle guest SEA, FSC: EC=%#x 
xFSC=%#lx ESR_EL2=%#lx\n",
+   kvm_vcpu_trap_get_class(vcpu),
+   (unsigned long)kvm_vcpu_trap_get_fault(vcpu),
+   (unsigned long)kvm_vcpu_get_hsr(vcpu));
+   return -EFAULT;
+   }
+   } else if (fault_status != FSC_FAULT && fault_status != FSC_PERM &&
+  fault_status != FSC_ACCESS) {
kvm_err("Unsupported FSC: EC=%#x xFSC=%#lx ESR_EL2=%#lx\n",
kvm_vcpu_trap_get_class(vcpu),
(unsigned long)kvm_vcpu_trap_get_fault(vcpu),
diff --git a/arch/arm64/include/asm/kvm_arm.h b/arch/arm64/include/asm/kvm_arm.h
index 4b5c977..be0efb6 100644
--- a/arch/arm64/include/asm/kvm_arm.h
+++ b/arch/arm64/include/asm/kvm_arm.h
@@ -201,6 +201,7 @@
 #define FSC_FAULT  ESR_ELx_FSC_FAULT
 #define FSC_ACCESS ESR_ELx_FSC_ACCESS
 #define FSC_PERM   ESR_ELx_FSC_PERM
+#define FSC_EXTABT ESR_ELx_FSC_EXTABT
 
 /* Hyp Prefetch Fault Address Register (HPFAR/HDFAR) */
 #define HPFAR_MASK (~UL(0xf))
diff --git a/arch/arm64/include/asm/system_misc.h 
b/arch/arm64/include/asm/system_misc.h
index 90daf4a..8522fff 100644
--- a/arch/arm64/include/asm/system_misc.h
+++ b/arch/arm64/include/asm/system_misc.h
@@ -77,4 +77,6 @@ extern void (*arm_pm_restart)(enum reboot_mode reboot_mode, 
const char *cmd);
 int sea_register_handler_chain(struct notifier_block *nb);
 void sea_unregister_handler_chain(struct notifier_block *nb);
 
+int handle_guest_sea(unsigned long addr, unsigned int esr);
+
 #endif /* __ASM_SYSTEM_MISC_H */
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index 81cb7ad..d714432 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -597,6 +597,19 @@ static const char *fault_name(unsigned int esr)
 }
 
 /*
+ * Handle Synchronous External Aborts that occur in a guest kernel.
+ */
+int handle_guest_sea(unsigned long addr, unsigned int esr)
+{
+   atomic_notifier_call_chain(_handler_chain, 0, NULL);
+
+   pr_err("Synchronous External Abort: %s (0x%08x) at 0x%016lx\n",
+   fault_name(esr), esr, addr);
+
+   return 0;
+}
+
+/*
  * Dispatch a data abort to the relevant handler.
  */
 asmlinkage void __exception do_mem_abort(unsigned long addr, unsigned int esr,
-- 
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm 
Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project.

Re: [PATCH] ARCv2: intc: untangle SMP, MCIP and IDU

[Vineet Gupta]

On 10/07/2016 10:31 AM, Alexey Brodkin wrote:
>> They are ugly I agree - but not portable - really ? The whole point is to 
>> make
>> > this work on BE w/o changing the src code - this details remains hidden in 
>> > an
>> > obscure header.
> That's what I learned the hard way.
> At least I was beaten a couple of times yet in both Linux kernel community and
> U-Boot
> one.

Beaten for writing code like above - please point me to those discussions. I'd
love to be educated in art of writing portable code !

Re: [PATCH v4] Adding missing features of Coresight PTM components

[Mathieu Poirier]

On 7 October 2016 at 06:16, Muhammad Abdul WAHAB
 wrote:
> In the current driver for Coresight components, two features of PTM
> components are missing:
>
> 1. Branch Broadcasting (present also in ETM but called Branch Output)
> 2. Return Stack (only present in PTM v1.0 and PTMv1.1)
>
> These features can be added simply to the code using `mode` field of
> `etm_config` struct.
>
> 1. **Branch Broadcast** : The branch broadcast feature is present in ETM
> components as well and is called Branch output. It allows to retrieve
> addresses for direct branch addresses alongside the indirect branch
> addresses. For example, it could be useful in cases when tracing without
> source code.
> 2. **Return Stack** : The return stack option allows to retrieve the return
> addresses of function calls. It can be useful to avoid CRA
> (Code Reuse Attacks) by keeping a shadowstack.
>
> Signed-off-by: Muhammad Abdul Wahab 
> ---
> change(s) in v4 :
> - syntax error correction (sorry did not compile after 1st version
> but did compile it before sending it this time)
>
> drivers/hwtracing/coresight/coresight-etm.h |  5 +
>  drivers/hwtracing/coresight/coresight-etm3x-sysfs.c | 10 ++
>  2 files changed, 15 insertions(+)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm.h
> b/drivers/hwtracing/coresight/coresight-etm.h
> index 4a18ee4..ad063d7 100644
> --- a/drivers/hwtracing/coresight/coresight-etm.h
> +++ b/drivers/hwtracing/coresight/coresight-etm.h
> @@ -89,11 +89,13 @@
>  /* ETMCR - 0x00 */
>  #define ETMCR_PWD_DWN  BIT(0)
>  #define ETMCR_STALL_MODE   BIT(7)
> +#define ETMCR_BRANCH_BROADCAST BIT(8)
>  #define ETMCR_ETM_PRG  BIT(10)
>  #define ETMCR_ETM_EN   BIT(11)
>  #define ETMCR_CYC_ACC  BIT(12)
>  #define ETMCR_CTXID_SIZE   (BIT(14)|BIT(15))
>  #define ETMCR_TIMESTAMP_EN BIT(28)
> +#define ETMCR_RETURN_STACK BIT(29)
>  /* ETMCCR - 0x04 */
>  #define ETMCCR_FIFOFULLBIT(23)
>  /* ETMPDCR - 0x310 */
> @@ -110,8 +112,11 @@
>  #define ETM_MODE_STALL BIT(2)
>  #define ETM_MODE_TIMESTAMP BIT(3)
>  #define ETM_MODE_CTXID BIT(4)
> +#define ETM_MODE_BBROADBIT(5)
> +#define ETM_MODE_RET_STACK BIT(6)
>  #define ETM_MODE_ALL   (ETM_MODE_EXCLUDE | ETM_MODE_CYCACC | \
>  ETM_MODE_STALL | ETM_MODE_TIMESTAMP | \
> +ETM_MODE_BBROAD | ETM_MODE_RET_STACK | \
>  ETM_MODE_CTXID | ETM_MODE_EXCL_KERN | \
>  ETM_MODE_EXCL_USER)
>
> diff --git a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> index e9b0719..7308304 100644
> --- a/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> +++ b/drivers/hwtracing/coresight/coresight-etm3x-sysfs.c
> @@ -164,6 +164,16 @@ static ssize_t mode_store(struct device *dev,
> else
> config->ctrl &= ~ETMCR_CTXID_SIZE;
>
> +   if (config->mode & ETM_MODE_BBROAD)
> +   config->ctrl |= ETMCR_BRANCH_BROADCAST;
> +   else
> +   config->ctrl &= ~ETMCR_BRANCH_BROADCAST;
> +
> +   if (config->mode & ETM_MODE_RET_STACK)
> +   config->ctrl |= ETMCR_RETURN_STACK;
> +   else
> +   config->ctrl &= ~ETMCR_RETURN_STACK;
> +
> if (config->mode & (ETM_MODE_EXCL_KERN | ETM_MODE_EXCL_USER))
> etm_config_trace_mode(config);

Applied.

Thanks,
Mathieu

>
> --
> 1.9.1

Re: [RFC PATCH-tip v4 02/10] locking/rwsem: Stop active read lock ASAP

[Waiman Long]

On 10/06/2016 05:47 PM, Dave Chinner wrote:

On Thu, Oct 06, 2016 at 11:17:18AM -0700, Davidlohr Bueso wrote:

On Thu, 18 Aug 2016, Waiman Long wrote:


Currently, when down_read() fails, the active read locking isn't undone
until the rwsem_down_read_failed() function grabs the wait_lock. If the
wait_lock is contended, it may takes a while to get the lock. During
that period, writer lock stealing will be disabled because of the
active read lock.

This patch will release the active read lock ASAP so that writer lock
stealing can happen sooner. The only downside is when the reader is
the first one in the wait queue as it has to issue another atomic
operation to update the count.

On a 4-socket Haswell machine running on a 4.7-rc1 tip-based kernel,
the fio test with multithreaded randrw and randwrite tests on the
same file on a XFS partition on top of a NVDIMM with DAX were run,
the aggregated bandwidths before and after the patch were as follows:

Test  BW before patch BW after patch  % change
  --- --  
randrw1210 MB/s  1352 MB/s  +12%
randwrite 1622 MB/s  1710 MB/s  +5.4%

Yeah, this is really a bad workload to make decisions on locking
heuristics imo - if I'm thinking of the same workload. Mainly because
concurrent buffered io to the same file isn't very realistic and you
end up pathologically pounding on i_rwsem (which used to be until
recently i_mutex until Al's parallel lookup/readdir). Obviously write
lock stealing wins in this case.

Except that it's DAX, and in 4.7-rc1 that used shared locking at the
XFS level and never took exclusive locks.

*However*, the DAX IO path locking in XFS  has changed in 4.9-rc1 to
match the buffered IO single writer POSIX semantics - the test is a
bad test based on the fact it exercised a path that is under heavy
development and so can't be used as a regression test across
multiple kernels.

If you want to stress concurrent access to a single file, please
use direct IO, not DAX or buffered IO.


Thanks for the update. I will change the test when I update this patch.

Cheers,
Longman

Re: Zram for FreeBSD

[Cory Pruce]

Cool, I am starting to get a good grasp on what is going on (I’ll probably need 
to use FreeBSD’s archive.h as opposed to Linux’s crypto.h). I am trying to get 
a hold on what exactly I need to port to FreeBSD. I see that (as Nitin 
suggested) zsmalloc is the main brains of handling the objects and that it 
creates a fixed amount of sharded “pages” which a compressed (or uncompressed) 
actual page can span. I see also that that depends on zpool. 

I will probably find all “dependencies”; however, if one of you could describe 
the components used/implemented for this, that’d be awesome. Also, any linux 
specific setup/layout details come to mind?

Seriously, any details would be appreciated. It will save me time.

Thanks,
Cory

On 10/5/16, 9:43 PM, "Sergey Senozhatsky"  
wrote:

Hi,

On (10/05/16 16:47), Cory Pruce wrote:
>Could one of you tell me why these compression algo’s were chosen,

zram supports more than that.
https://marc.info/?l=linux-kernel=146469777105130


>if they were implemented as a need for zram, and

hm... not all of them (if any at all). lzo, *may be*, was motivated
by "compression/decompression perfromance VS compression ratio", which
is imporatant for zram.


>what the policy is on porting these to FreeBSD?

no idea.

-ss

[git pull] vfs pile 1 (splice)

[Al Viro]

splice stuff.  There are conflicts in lustre; proposed resolution
is in #merge-candidate (same as it is in linux-next).  There's a bunch of
branches this cycle, both mine and from other folks and I'd rather send
pull requests separately.  This one is the conversion of ->splice_read()
to ITER_PIPE iov_iter (and introduction of such).  Gets rid of a lot of
code in fs/splice.c and elsewhere; there will be followups, but these are
for the next cycle...  Some pipe/splice-related cleanups from Miklos in
the same branch as well.

The following changes since commit 08895a8b6b06ed2323cd97a36ee40a116b3db8ed:

  Linux 4.8-rc8 (2016-09-25 18:47:13 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git work.splice_read

for you to fetch changes up to a949e63992469fed87aef197347960ced31701b8:

  pipe: fix comment in pipe_buf_operations (2016-10-05 18:24:00 -0400)


Al Viro (11):
  consistent treatment of EFAULT on O_DIRECT read/write
  splice_to_pipe(): don't open-code wakeup_pipe_readers()
  splice: switch get_iovec_page_array() to iov_iter
  splice: lift pipe_lock out of splice_to_pipe()
  new helper: add_to_pipe()
  skb_splice_bits(): get rid of callback
  fuse_dev_splice_read(): switch to add_to_pipe()
  new iov_iter flavour: pipe-backed
  switch generic_file_splice_read() to use of ->read_iter()
  switch default_file_splice_read() to use of pipe-backed iov_iter
  relay: simplify relay_file_read()

Miklos Szeredi (5):
  pipe: add pipe_buf_get() helper
  pipe: add pipe_buf_release() helper
  pipe: add pipe_buf_confirm() helper
  pipe: add pipe_buf_steal() helper
  pipe: fix comment in pipe_buf_operations

 drivers/char/virtio_console.c  |   2 +-
 drivers/staging/lustre/lustre/llite/file.c |  89 +--
 .../staging/lustre/lustre/llite/llite_internal.h   |  15 +-
 drivers/staging/lustre/lustre/llite/vvp_internal.h |  14 -
 drivers/staging/lustre/lustre/llite/vvp_io.c   |  45 +-
 fs/coda/file.c |  23 +-
 fs/direct-io.c |   3 +
 fs/fuse/dev.c  |  63 +-
 fs/gfs2/file.c |  28 +-
 fs/nfs/file.c  |  25 +-
 fs/nfs/internal.h  |   2 -
 fs/nfs/nfs4file.c  |   2 +-
 fs/ocfs2/file.c|  34 +-
 fs/ocfs2/ocfs2_trace.h |   2 -
 fs/pipe.c  |  13 +-
 fs/splice.c| 683 ++---
 fs/xfs/xfs_file.c  |  41 +-
 fs/xfs/xfs_trace.h |   1 -
 include/linux/fs.h |   2 -
 include/linux/pipe_fs_i.h  |  59 +-
 include/linux/skbuff.h |   8 +-
 include/linux/splice.h |   3 +
 include/linux/uio.h|  14 +-
 kernel/relay.c |  78 +--
 lib/iov_iter.c | 395 +++-
 mm/shmem.c | 115 +---
 net/core/skbuff.c  |  28 +-
 net/ipv4/tcp.c |   3 +-
 net/kcm/kcmsock.c  |  16 +-
 net/unix/af_unix.c |  17 +-
 30 files changed, 746 insertions(+), 1077 deletions(-)

Re: [PATCH] net: macb: NULL out phydev after removing mdio bus

[Nicolas Ferre]

Le 07/10/2016 à 17:13, Xander Huff a écrit :
> From: Nathan Sullivan 
> 
> To ensure the dev->phydev pointer is not used after becoming invalid in
> mdiobus_unregister, set it to NULL. This happens when removing the macb
> driver without first taking its interface down, since unregister_netdev
> will end up calling macb_close.
> 
> Signed-off-by: Xander Huff 
> Signed-off-by: Nathan Sullivan 
> Signed-off-by: Brad Mouring 

Acked-by: Nicolas Ferre 

> ---
>  drivers/net/ethernet/cadence/macb.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/net/ethernet/cadence/macb.c 
> b/drivers/net/ethernet/cadence/macb.c
> index 63144bb..b32444a 100644
> --- a/drivers/net/ethernet/cadence/macb.c
> +++ b/drivers/net/ethernet/cadence/macb.c
> @@ -3117,6 +3117,7 @@ static int macb_remove(struct platform_device *pdev)
>   if (dev->phydev)
>   phy_disconnect(dev->phydev);
>   mdiobus_unregister(bp->mii_bus);
> + dev->phydev = NULL;
>   mdiobus_free(bp->mii_bus);
>  
>   /* Shutdown the PHY if there is a GPIO reset */
> 


-- 
Nicolas Ferre

Re: [PATCH] mm: check VMA flags to avoid invalid PROT_NONE NUMA balancing

[Lorenzo Stoakes]

On Fri, Oct 07, 2016 at 08:34:15AM -0700, Linus Torvalds wrote:
> Would you be willing to look at doing that kind of purely syntactic,
> non-semantic cleanup first?

Sure, more than happy to do that! I'll work on a patch for this.

> I think that if we end up having the FOLL_FORCE semantics, we're
> actually better off having an explicit FOLL_FORCE flag, and *not* do
> some kind of implicit "under these magical circumstances we'll force
> it anyway". The implicit thing is what we used to do long long ago, we
> definitely don't want to.

That's a good point, it would definitely be considerably more 'magical', and
expanding the conditions to include uprobes etc. would only add to that.

I wondered about an alternative parameter/flag but it felt like it was
more-or-less FOLL_FORCE in a different form, at which point it may as well
remain FOLL_FORCE :)

Re: [PATCH 3/3] mtd: s3c2410: parse the device configuration from OF node

[Krzysztof Kozlowski]

On Wed, Oct 05, 2016 at 08:46:57PM -0300, Sergio Prado wrote:
> Allows configuring Samsung's s3c2410 memory controller using a
> devicetree.
> 
> Signed-off-by: Sergio Prado 
> ---
>  drivers/mtd/nand/s3c2410.c | 171 
> ++---
>  include/linux/platform_data/mtd-nand-s3c2410.h |   1 +
>  2 files changed, 156 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/mtd/nand/s3c2410.c b/drivers/mtd/nand/s3c2410.c
> index 174ac9dc4265..352cf2656bc8 100644
> --- a/drivers/mtd/nand/s3c2410.c
> +++ b/drivers/mtd/nand/s3c2410.c
> @@ -39,6 +39,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include 
>  #include 
> @@ -185,6 +187,26 @@ struct s3c2410_nand_info {
>  #endif
>  };
>  
> +struct s3c24XX_nand_devtype_data {
> + enum s3c_cpu_type type;
> +};
> +
> +struct s3c24XX_nand_devtype_data s3c2410_nand_devtype_data = {
> + .type = TYPE_S3C2410,
> +};
> +
> +struct s3c24XX_nand_devtype_data s3c2412_nand_devtype_data = {
> + .type = TYPE_S3C2412,
> +};
> +
> +struct s3c24XX_nand_devtype_data s3c2440_nand_devtype_data = {
> + .type = TYPE_S3C2440,
> +};
> +
> +struct s3c24XX_nand_devtype_data s3c6400_nand_devtype_data = {
> + .type = TYPE_S3C2412,

All of these look like candidate for static const.

Additionally you are not actually differentiating between s3c2412 and
s3c64xx so I think there is not need of samsung,s3c6400-nand compatible.
Just use existing one.

Best regards,
Krzysztof

Re: [PATCH V2 2/2] fs/super.c: don't fool lockdep in freeze_super() and thaw_super() paths

[Oleg Nesterov]

On 10/06, Johannes Weiner wrote:
>
> On Tue, Oct 04, 2016 at 01:48:00PM +0200, Michal Hocko wrote:
> > Johannes is already looking into this
> > http://lkml.kernel.org/r/20161004093216.ga21...@cmpxchg.org
> >
> > On Tue 04-10-16 13:43:43, Oleg Nesterov wrote:
> > > because of kernel bug:
> > >
> > >   [ 2730.242537] run fstests generic/274 at 2016-10-04 05:17:34
> > >   [ 2730.738352] XFS (loop1): Mounting V5 Filesystem
> > >   [ 2730.741451] XFS (loop1): Ending clean mount
> > >   [ 2744.508698] [ cut here ]
> > >   [ 2744.509190] kernel BUG at ./include/linux/swap.h:276!
> > >
> > > static inline void workingset_node_shadows_dec(struct radix_tree_node 
> > > *node)
> > > {
> > >   VM_BUG_ON(!workingset_node_shadows(node));
> > >   node->count -= 1U << RADIX_TREE_COUNT_SHIFT;
>
> We tracked this one down and Linus merged a fix for this issue:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=d3798ae8c6f3767c726403c2ca6ecc317752c9dd

Confirm, generic/274 no longer crashes the kernel.

Thanks.

Oleg.

[PATCH 3/3] Staging: i4l: Error "open brace { should be on the previous line" fixed.

[Harman Kalra]

Error "open brace { should be on the previous line" caught by checkpatch.pl 
fixed.
Signed-off-by: Harman Kalra 
---
 drivers/staging/i4l/icn/icn.c |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/i4l/icn/icn.c b/drivers/staging/i4l/icn/icn.c
index 514bfc2..3750ba3 100644
--- a/drivers/staging/i4l/icn/icn.c
+++ b/drivers/staging/i4l/icn/icn.c
@@ -411,8 +411,7 @@
int action;
 } icn_stat;
 /* *INDENT-OFF* */
-static icn_stat icn_stat_table[] =
-{
+static icn_stat icn_stat_table[] = {
{"BCON_",  ISDN_STAT_BCONN, 1}, /* B-Channel connected*/
{"BDIS_",  ISDN_STAT_BHUP,  2}, /* B-Channel disconnected */
/*
-- 
1.7.9.5

Re: [PATCH v2 2/4] ACPI / gpio: Add support for naming GPIOs

[Andy Shevchenko]

On Thu, Sep 29, 2016 at 4:39 PM, Mika Westerberg
 wrote:
> DT has property 'gpio-line-names' to name GPIO lines the controller has if
> present. Use this very same property in ACPI as well to provide nice names
> for the GPIOS.

One nit below.

> @@ -835,6 +875,9 @@ void acpi_gpiochip_add(struct gpio_chip *chip)
> return;
> }
>
> +   if (!chip->names)
> +   acpi_gpiochip_set_names(acpi_gpio);
> +

I'm okay with this, though wouldn't be better to call it
unconditionally like it's done for below call and move check inside?

> acpi_gpiochip_request_regions(acpi_gpio);
> acpi_walk_dep_device_list(handle);
>  }

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v13 03/15] iommu/dma: Allow MSI-only cookies

[Auger Eric]

Hi Alex,

On 06/10/2016 22:17, Alex Williamson wrote:
> On Thu,  6 Oct 2016 08:45:19 +
> Eric Auger  wrote:
> 
>> From: Robin Murphy 
>>
>> IOMMU domain users such as VFIO face a similar problem to DMA API ops
>> with regard to mapping MSI messages in systems where the MSI write is
>> subject to IOMMU translation. With the relevant infrastructure now in
>> place for managed DMA domains, it's actually really simple for other
>> users to piggyback off that and reap the benefits without giving up
>> their own IOVA management, and without having to reinvent their own
>> wheel in the MSI layer.
>>
>> Allow such users to opt into automatic MSI remapping by dedicating a
>> region of their IOVA space to a managed cookie.
>>
>> Signed-off-by: Robin Murphy 
>> Signed-off-by: Eric Auger 
>>
>> ---
>>
>> v1 -> v2:
>> - compared to Robin's version
>> - add NULL last param to iommu_dma_init_domain
>> - set the msi_geometry aperture
>> - I removed
>>   if (base < U64_MAX - size)
>>  reserve_iova(iovad, iova_pfn(iovad, base + size), ULONG_MAX);
>>   don't get why we would reserve something out of the scope of the iova 
>> domain?
>>   what do I miss?
>> ---
>>  drivers/iommu/dma-iommu.c | 40 
>>  include/linux/dma-iommu.h |  9 +
>>  2 files changed, 49 insertions(+)
>>
>> diff --git a/drivers/iommu/dma-iommu.c b/drivers/iommu/dma-iommu.c
>> index c5ab866..11da1a0 100644
>> --- a/drivers/iommu/dma-iommu.c
>> +++ b/drivers/iommu/dma-iommu.c
>> @@ -716,3 +716,43 @@ void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg)
>>  msg->address_lo += lower_32_bits(msi_page->iova);
>>  }
>>  }
>> +
>> +/**
>> + * iommu_get_dma_msi_region_cookie - Configure a domain for MSI remapping 
>> only
> 
> Should this perhaps be iommu_setup_dma_msi_region_cookie, or something
> along those lines.  I'm not sure what we're get'ing.  Thanks,
This was chosen by analogy with legacy iommu_get_dma_cookie/
iommu_put_dma_cookie. But in practice it does both get &
iommu_dma_init_domain.

I plan to rename into iommu_setup_dma_msi_region if no objection

Thanks

Eric

> 
> Alex
> 
>> + * @domain: IOMMU domain to prepare
>> + * @base: Base address of IOVA region to use as the MSI remapping aperture
>> + * @size: Size of the desired MSI aperture
>> + *
>> + * Users who manage their own IOVA allocation and do not want DMA API 
>> support,
>> + * but would still like to take advantage of automatic MSI remapping, can 
>> use
>> + * this to initialise their own domain appropriately.
>> + */
>> +int iommu_get_dma_msi_region_cookie(struct iommu_domain *domain,
>> +dma_addr_t base, u64 size)
>> +{
>> +struct iommu_dma_cookie *cookie;
>> +struct iova_domain *iovad;
>> +int ret;
>> +
>> +if (domain->type == IOMMU_DOMAIN_DMA)
>> +return -EINVAL;
>> +
>> +ret = iommu_get_dma_cookie(domain);
>> +if (ret)
>> +return ret;
>> +
>> +ret = iommu_dma_init_domain(domain, base, size, NULL);
>> +if (ret) {
>> +iommu_put_dma_cookie(domain);
>> +return ret;
>> +}
>> +
>> +domain->msi_geometry.aperture_start = base;
>> +domain->msi_geometry.aperture_end = base + size - 1;
>> +
>> +cookie = domain->iova_cookie;
>> +iovad = >iovad;
>> +
>> +return 0;
>> +}
>> +EXPORT_SYMBOL(iommu_get_dma_msi_region_cookie);
>> diff --git a/include/linux/dma-iommu.h b/include/linux/dma-iommu.h
>> index 32c5890..1c55413 100644
>> --- a/include/linux/dma-iommu.h
>> +++ b/include/linux/dma-iommu.h
>> @@ -67,6 +67,9 @@ int iommu_dma_mapping_error(struct device *dev, dma_addr_t 
>> dma_addr);
>>  /* The DMA API isn't _quite_ the whole story, though... */
>>  void iommu_dma_map_msi_msg(int irq, struct msi_msg *msg);
>>  
>> +int iommu_get_dma_msi_region_cookie(struct iommu_domain *domain,
>> +dma_addr_t base, u64 size);
>> +
>>  #else
>>  
>>  struct iommu_domain;
>> @@ -90,6 +93,12 @@ static inline void iommu_dma_map_msi_msg(int irq, struct 
>> msi_msg *msg)
>>  {
>>  }
>>  
>> +static inline int iommu_get_dma_msi_region_cookie(struct iommu_domain 
>> *domain,
>> +dma_addr_t base, u64 size)
>> +{
>> +return -ENODEV;
>> +}
>> +
>>  #endif  /* CONFIG_IOMMU_DMA */
>>  #endif  /* __KERNEL__ */
>>  #endif  /* __DMA_IOMMU_H */
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

Re: [PATCH v13 04/15] genirq/msi: Introduce the MSI doorbell API

[Auger Eric]

Hi Alex,

On 06/10/2016 22:17, Alex Williamson wrote:
> On Thu,  6 Oct 2016 08:45:20 +
> Eric Auger  wrote:
> 
>> We introduce a new msi-doorbell API that allows msi controllers
>> to allocate and register their doorbells. This is useful when
>> those doorbells are likely to be iommu mapped (typically on ARM).
>> The VFIO layer will need to gather information about those doorbells:
>> whether they are safe (ie. they implement irq remapping) and how
>> many IOMMU pages are requested to map all of them.
>>
>> This patch first introduces the dedicated msi_doorbell_info struct
>> and the registration/unregistration functions.
>>
>> A doorbell region is characterized by its physical address base, size,
>> and whether it its safe (ie. it implements IRQ remapping). A doorbell
>> can be per-cpu of global. We currently only care about global doorbells.
>  ^^ s/of/or/
OK
> 
>>
>> A function returns whether all doorbells are safe.
>>
>> Signed-off-by: Eric Auger 
>>
>> ---
>> v12 -> v13:
>> - directly select MSI_DOORBELL in ARM_SMMU and ARM_SMMU_V3 configs
>> - remove prot attribute
>> - move msi_doorbell_info struct definition in msi-doorbell.c
>> - change the commit title
>> - change proto of the registration function
>> - msi_doorbell_safe now in this patch
>>
>> v11 -> v12:
>> - rename irqchip_doorbell into msi_doorbell, irqchip_doorbell_list
>>   into msi_doorbell_list and irqchip_doorbell_mutex into
>>   msi_doorbell_mutex
>> - fix style issues: align msi_doorbell struct members, kernel-doc comments
>> - use kzalloc
>> - use container_of in msi_doorbell_unregister_global
>> - compute nb_unsafe_doorbells on registration/unregistration
>> - registration simply returns NULL if allocation failed
>>
>> v10 -> v11:
>> - remove void *chip_data argument from register/unregister function
>> - remove lookup funtions since we restored the struct irq_chip
>>   msi_doorbell_info ops to realize this function
>> - reword commit message and title
>>
>> Conflicts:
>>  kernel/irq/Makefile
>>
>> Conflicts:
>>  drivers/iommu/Kconfig
>> ---
>>  drivers/iommu/Kconfig|  2 +
>>  include/linux/msi-doorbell.h | 77 ++
>>  kernel/irq/Kconfig   |  4 ++
>>  kernel/irq/Makefile  |  1 +
>>  kernel/irq/msi-doorbell.c| 98 
>> 
>>  5 files changed, 182 insertions(+)
>>  create mode 100644 include/linux/msi-doorbell.h
>>  create mode 100644 kernel/irq/msi-doorbell.c
>>
>> diff --git a/drivers/iommu/Kconfig b/drivers/iommu/Kconfig
>> index 8ee54d7..0cc7fac 100644
>> --- a/drivers/iommu/Kconfig
>> +++ b/drivers/iommu/Kconfig
>> @@ -297,6 +297,7 @@ config SPAPR_TCE_IOMMU
>>  config ARM_SMMU
>>  bool "ARM Ltd. System MMU (SMMU) Support"
>>  depends on (ARM64 || ARM) && MMU
>> +select MSI_DOORBELL
>>  select IOMMU_API
>>  select IOMMU_IO_PGTABLE_LPAE
>>  select ARM_DMA_USE_IOMMU if ARM
>> @@ -310,6 +311,7 @@ config ARM_SMMU
>>  config ARM_SMMU_V3
>>  bool "ARM Ltd. System MMU Version 3 (SMMUv3) Support"
>>  depends on ARM64
>> +select MSI_DOORBELL
>>  select IOMMU_API
>>  select IOMMU_IO_PGTABLE_LPAE
>>  select GENERIC_MSI_IRQ_DOMAIN
>> diff --git a/include/linux/msi-doorbell.h b/include/linux/msi-doorbell.h
>> new file mode 100644
>> index 000..c18a382
>> --- /dev/null
>> +++ b/include/linux/msi-doorbell.h
>> @@ -0,0 +1,77 @@
>> +/*
>> + * API to register/query MSI doorbells likely to be IOMMU mapped
>> + *
>> + * Copyright (C) 2016 Red Hat, Inc.
>> + *
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + *
>> + * This program is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
>> + * GNU General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program.  If not, see .
>> + */
>> +
>> +#ifndef _LINUX_MSI_DOORBELL_H
>> +#define _LINUX_MSI_DOORBELL_H
>> +
>> +struct msi_doorbell_info;
>> +
>> +#ifdef CONFIG_MSI_DOORBELL
>> +
>> +/**
>> + * msi_doorbell_register - allocate and register a global doorbell
>> + * @base: physical base address of the global doorbell
>> + * @size: size of the global doorbell
>> + * @prot: protection/memory attributes
>> + * @safe: true is irq_remapping implemented for this doorbell
>> + * @dbinfo: returned doorbell info
>> + *
>> + * Return: 0 on success, -ENOMEM on allocation failure
>> + */
>> +int msi_doorbell_register_global(phys_addr_t base, size_t size,
>> + bool safe,
>> + struct msi_doorbell_info **dbinfo);
>> +
> 
> Seems like alloc/free 

[PATCH 2/3] Staging: i4l: Error "open brace { should be on the previous line" fixed.

[Harman Kalra]

Errors "open brace { should be on the previous line" caught by checkpatch.pl  
fixed.
Signed-off-by: Harman Kalra 
---
 drivers/staging/i4l/icn/icn.h |3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/i4l/icn/icn.h b/drivers/staging/i4l/icn/icn.h
index aa4c593..8d0182c 100644
--- a/drivers/staging/i4l/icn/icn.h
+++ b/drivers/staging/i4l/icn/icn.h
@@ -187,8 +187,7 @@
 #ifdef __KERNEL__
 
 static icn_card *cards = (icn_card *) 0;
-static u_char chan2bank[] =
-{0, 4, 8, 12};  /* for icn_map_channel() */
+static u_char chan2bank[] = {0, 4, 8, 12};  /* for 
icn_map_channel() */
 
 static icn_dev dev;
 
-- 
1.7.9.5

[PATCH 21/26] pctv452e: don't call BUG_ON() on non-fatal error

[Mauro Carvalho Chehab]

There are some conditions on this driver that are tested with
BUG_ON() with are not serious enough to hang a machine.

So, just return an error if this happens.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/dvb-usb/pctv452e.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/pctv452e.c 
b/drivers/media/usb/dvb-usb/pctv452e.c
index 855fe9d34b59..14bd927c50d8 100644
--- a/drivers/media/usb/dvb-usb/pctv452e.c
+++ b/drivers/media/usb/dvb-usb/pctv452e.c
@@ -109,9 +109,11 @@ static int tt3650_ci_msg(struct dvb_usb_device *d, u8 cmd, 
u8 *data,
unsigned int rlen;
int ret;
 
-   BUG_ON(NULL == data && 0 != (write_len | read_len));
-   BUG_ON(write_len > 64 - 4);
-   BUG_ON(read_len > 64 - 4);
+   if (NULL == data && 0 != (write_len | read_len) ||
+   write_len > 64 - 4) || (read_len > 64 - 4)) {
+   ret = -EIO;
+   goto failed;
+   };
 
id = state->c++;
 
-- 
2.7.4

[PATCH 02/26] cinergyT2-core: don't do DMA on stack

[Mauro Carvalho Chehab]

The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/dvb-usb/cinergyT2-core.c | 45 ++
 1 file changed, 27 insertions(+), 18 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/cinergyT2-core.c 
b/drivers/media/usb/dvb-usb/cinergyT2-core.c
index 9fd1527494eb..91640c927776 100644
--- a/drivers/media/usb/dvb-usb/cinergyT2-core.c
+++ b/drivers/media/usb/dvb-usb/cinergyT2-core.c
@@ -41,6 +41,7 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 
 struct cinergyt2_state {
u8 rc_counter;
+   unsigned char data[64];
 };
 
 /* We are missing a release hook with usb_device data */
@@ -50,29 +51,36 @@ static struct dvb_usb_device_properties 
cinergyt2_properties;
 
 static int cinergyt2_streaming_ctrl(struct dvb_usb_adapter *adap, int enable)
 {
-   char buf[] = { CINERGYT2_EP1_CONTROL_STREAM_TRANSFER, enable ? 1 : 0 };
-   char result[64];
-   return dvb_usb_generic_rw(adap->dev, buf, sizeof(buf), result,
-   sizeof(result), 0);
+   struct dvb_usb_device *d = adap->dev;
+   struct cinergyt2_state *st = d->priv;
+
+   st->data[0] = CINERGYT2_EP1_CONTROL_STREAM_TRANSFER;
+   st->data[1] = enable ? 1 : 0;
+
+   return dvb_usb_generic_rw(d, st->data, 2, st->data, 64, 0);
 }
 
 static int cinergyt2_power_ctrl(struct dvb_usb_device *d, int enable)
 {
-   char buf[] = { CINERGYT2_EP1_SLEEP_MODE, enable ? 0 : 1 };
-   char state[3];
-   return dvb_usb_generic_rw(d, buf, sizeof(buf), state, sizeof(state), 0);
+   struct cinergyt2_state *st = d->priv;
+
+   st->data[0] = CINERGYT2_EP1_SLEEP_MODE;
+   st->data[1] = enable ? 0 : 1;
+
+   return dvb_usb_generic_rw(d, st->data, 2, st->data, 3, 0);
 }
 
 static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap)
 {
-   char query[] = { CINERGYT2_EP1_GET_FIRMWARE_VERSION };
-   char state[3];
+   struct dvb_usb_device *d = adap->dev;
+   struct cinergyt2_state *st = d->priv;
int ret;
 
adap->fe_adap[0].fe = cinergyt2_fe_attach(adap->dev);
 
-   ret = dvb_usb_generic_rw(adap->dev, query, sizeof(query), state,
-   sizeof(state), 0);
+   st->data[0] = CINERGYT2_EP1_GET_FIRMWARE_VERSION;
+
+   ret = dvb_usb_generic_rw(d, st->data, 1, st->data, 3, 0);
if (ret < 0) {
deb_rc("cinergyt2_power_ctrl() Failed to retrieve sleep "
"state info\n");
@@ -141,13 +149,14 @@ static int repeatable_keys[] = {
 static int cinergyt2_rc_query(struct dvb_usb_device *d, u32 *event, int *state)
 {
struct cinergyt2_state *st = d->priv;
-   u8 key[5] = {0, 0, 0, 0, 0}, cmd = CINERGYT2_EP1_GET_RC_EVENTS;
int i;
 
*state = REMOTE_NO_KEY_PRESSED;
 
-   dvb_usb_generic_rw(d, , 1, key, sizeof(key), 0);
-   if (key[4] == 0xff) {
+   st->data[0] = CINERGYT2_EP1_GET_RC_EVENTS;
+
+   dvb_usb_generic_rw(d, st->data, 1, st->data, 5, 0);
+   if (st->data[4] == 0xff) {
/* key repeat */
st->rc_counter++;
if (st->rc_counter > RC_REPEAT_DELAY) {
@@ -166,13 +175,13 @@ static int cinergyt2_rc_query(struct dvb_usb_device *d, 
u32 *event, int *state)
}
 
/* hack to pass checksum on the custom field */
-   key[2] = ~key[1];
-   dvb_usb_nec_rc_key_to_event(d, key, event, state);
-   if (key[0] != 0) {
+   st->data[2] = ~st->data[1];
+   dvb_usb_nec_rc_key_to_event(d, st->data, event, state);
+   if (st->data[0] != 0) {
if (*event != d->last_event)
st->rc_counter = 0;
 
-   deb_rc("key: %*ph\n", 5, key);
+   deb_rc("key: %*ph\n", 5, st->data);
}
return 0;
 }
-- 
2.7.4

[PATCH 00/26] Don't use stack for DMA transers on dvb-usb drivers

[Mauro Carvalho Chehab]

Sending URB control messages from stack was never supported. Yet, on x86,
the stack was usually at a memory region that allows DMA transfer.

So, several drivers got it wrong. On Kernel 4.9, if VMAP_STACK=y, none of
those drivers will work, as the stack won't be on a DMA-able area anymore.

So, fix the dvb-usb drivers that requre it.

Please notice that, while all those patches compile, I don't have devices
using those drivers to test. So, I really appreciate if people with devices
using those drivers could test and report if they don't break anything.

Thanks!
Mauro

Mauro Carvalho Chehab (26):
  af9005: don't do DMA on stack
  cinergyT2-core: don't do DMA on stack
  cinergyT2-core:: handle error code on RC query
  cinergyT2-fe: cache stats at cinergyt2_fe_read_status()
  cinergyT2-fe: don't do DMA on stack
  cxusb: don't do DMA on stack
  dib0700: be sure that dib0700_ctrl_rd() users can do DMA
  dib0700_core: don't use stack on I2C reads
  dibusb: don't do DMA on stack
  dibusb: handle error code on RC query
  digitv: don't do DMA on stack
  dtt200u-fe: don't do DMA on stack
  dtt200u-fe: handle errors on USB control messages
  dtt200u: don't do DMA on stack
  dtt200u: handle USB control message errors
  dtv5100: : don't do DMA on stack
  gp8psk: don't do DMA on stack
  gp8psk: don't go past the buffer size
  nova-t-usb2: don't do DMA on stack
  pctv452e: don't do DMA on stack
  pctv452e: don't call BUG_ON() on non-fatal error
  technisat-usb2: use DMA buffers for I2C transfers
  dvb-usb: warn if return value for USB read/write routines is not
checked
  nova-t-usb2: handle error code on RC query
  dw2102: return error if su3000_power_ctrl() fails
  digitv: handle error code on RC query

 drivers/media/usb/dvb-usb/af9005.c  | 211 +++-
 drivers/media/usb/dvb-usb/cinergyT2-core.c  |  52 ---
 drivers/media/usb/dvb-usb/cinergyT2-fe.c|  91 
 drivers/media/usb/dvb-usb/cxusb.c   |  20 +--
 drivers/media/usb/dvb-usb/cxusb.h   |   5 +
 drivers/media/usb/dvb-usb/dib0700_core.c|  31 +++-
 drivers/media/usb/dvb-usb/dib0700_devices.c |  25 ++--
 drivers/media/usb/dvb-usb/dibusb-common.c   | 112 +++
 drivers/media/usb/dvb-usb/dibusb.h  |   5 +
 drivers/media/usb/dvb-usb/digitv.c  |  26 ++--
 drivers/media/usb/dvb-usb/digitv.h  |   3 +
 drivers/media/usb/dvb-usb/dtt200u-fe.c  |  90 
 drivers/media/usb/dvb-usb/dtt200u.c |  80 +++
 drivers/media/usb/dvb-usb/dtv5100.c |  10 +-
 drivers/media/usb/dvb-usb/dvb-usb.h |   6 +-
 drivers/media/usb/dvb-usb/dw2102.c  |   2 +-
 drivers/media/usb/dvb-usb/gp8psk.c  |  25 +++-
 drivers/media/usb/dvb-usb/nova-t-usb2.c |  25 +++-
 drivers/media/usb/dvb-usb/pctv452e.c| 118 
 drivers/media/usb/dvb-usb/technisat-usb2.c  |  16 ++-
 20 files changed, 577 insertions(+), 376 deletions(-)

-- 
2.7.4

[PATCH 20/26] pctv452e: don't do DMA on stack

[Mauro Carvalho Chehab]

The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/dvb-usb/pctv452e.c | 110 ++-
 1 file changed, 58 insertions(+), 52 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/pctv452e.c 
b/drivers/media/usb/dvb-usb/pctv452e.c
index c05de1b088a4..855fe9d34b59 100644
--- a/drivers/media/usb/dvb-usb/pctv452e.c
+++ b/drivers/media/usb/dvb-usb/pctv452e.c
@@ -97,13 +97,14 @@ struct pctv452e_state {
u8 c;  /* transaction counter, wraps around...  */
u8 initialized; /* set to 1 if 0x15 has been sent */
u16 last_rc_key;
+
+   unsigned char data[80];
 };
 
 static int tt3650_ci_msg(struct dvb_usb_device *d, u8 cmd, u8 *data,
 unsigned int write_len, unsigned int read_len)
 {
struct pctv452e_state *state = (struct pctv452e_state *)d->priv;
-   u8 buf[64];
u8 id;
unsigned int rlen;
int ret;
@@ -114,30 +115,30 @@ static int tt3650_ci_msg(struct dvb_usb_device *d, u8 
cmd, u8 *data,
 
id = state->c++;
 
-   buf[0] = SYNC_BYTE_OUT;
-   buf[1] = id;
-   buf[2] = cmd;
-   buf[3] = write_len;
+   state->data[0] = SYNC_BYTE_OUT;
+   state->data[1] = id;
+   state->data[2] = cmd;
+   state->data[3] = write_len;
 
-   memcpy(buf + 4, data, write_len);
+   memcpy(state->data + 4, data, write_len);
 
rlen = (read_len > 0) ? 64 : 0;
-   ret = dvb_usb_generic_rw(d, buf, 4 + write_len,
- buf, rlen, /* delay_ms */ 0);
+   ret = dvb_usb_generic_rw(d, state->data, 4 + write_len,
+ state->data, rlen, /* delay_ms */ 0);
if (0 != ret)
goto failed;
 
ret = -EIO;
-   if (SYNC_BYTE_IN != buf[0] || id != buf[1])
+   if (SYNC_BYTE_IN != state->data[0] || id != state->data[1])
goto failed;
 
-   memcpy(data, buf + 4, read_len);
+   memcpy(data, state->data + 4, read_len);
 
return 0;
 
 failed:
err("CI error %d; %02X %02X %02X -> %*ph.",
-ret, SYNC_BYTE_OUT, id, cmd, 3, buf);
+ret, SYNC_BYTE_OUT, id, cmd, 3, state->data);
 
return ret;
 }
@@ -405,7 +406,6 @@ static int pctv452e_i2c_msg(struct dvb_usb_device *d, u8 
addr,
u8 *rcv_buf, u8 rcv_len)
 {
struct pctv452e_state *state = (struct pctv452e_state *)d->priv;
-   u8 buf[64];
u8 id;
int ret;
 
@@ -415,42 +415,40 @@ static int pctv452e_i2c_msg(struct dvb_usb_device *d, u8 
addr,
if (snd_len > 64 - 7 || rcv_len > 64 - 7)
goto failed;
 
-   buf[0] = SYNC_BYTE_OUT;
-   buf[1] = id;
-   buf[2] = PCTV_CMD_I2C;
-   buf[3] = snd_len + 3;
-   buf[4] = addr << 1;
-   buf[5] = snd_len;
-   buf[6] = rcv_len;
+   state->data[0] = SYNC_BYTE_OUT;
+   state->data[1] = id;
+   state->data[2] = PCTV_CMD_I2C;
+   state->data[3] = snd_len + 3;
+   state->data[4] = addr << 1;
+   state->data[5] = snd_len;
+   state->data[6] = rcv_len;
 
-   memcpy(buf + 7, snd_buf, snd_len);
+   memcpy(state->data + 7, snd_buf, snd_len);
 
-   ret = dvb_usb_generic_rw(d, buf, 7 + snd_len,
- buf, /* rcv_len */ 64,
+   ret = dvb_usb_generic_rw(d, state->data, 7 + snd_len,
+ state->data, /* rcv_len */ 64,
  /* delay_ms */ 0);
if (ret < 0)
goto failed;
 
/* TT USB protocol error. */
ret = -EIO;
-   if (SYNC_BYTE_IN != buf[0] || id != buf[1])
+   if (SYNC_BYTE_IN != state->data[0] || id != state->data[1])
goto failed;
 
/* I2C device didn't respond as expected. */
ret = -EREMOTEIO;
-   if (buf[5] < snd_len || buf[6] < rcv_len)
+   if (state->data[5] < snd_len || state->data[6] < rcv_len)
goto failed;
 
-   memcpy(rcv_buf, buf + 7, rcv_len);
+   memcpy(rcv_buf, state->data + 7, rcv_len);
 
return rcv_len;
 
 failed:
-   err("I2C error %d; %02X %02X  %02X %02X %02X -> "
-"%02X %02X  %02X %02X %02X.",
+   err("I2C error %d; %02X %02X  %02X %02X %02X -> %*ph",
 ret, SYNC_BYTE_OUT, id, addr << 1, snd_len, rcv_len,
-buf[0], buf[1], buf[4], buf[5], buf[6]);
-
+7, state->data);
return ret;
 }
 
@@ -499,8 +497,7 @@ static u32 pctv452e_i2c_func(struct i2c_adapter *adapter)
 static int pctv452e_power_ctrl(struct dvb_usb_device *d, int i)
 {
struct pctv452e_state *state = (struct pctv452e_state *)d->priv;
-   u8 b0[] = { 0xaa, 0, PCTV_CMD_RESET, 1, 0 };
-   u8 rx[PCTV_ANSWER_LEN];
+   u8 *rx;
int ret;
 
info("%s: %d\n", __func__, i);
@@ 

[PATCH 09/26] dibusb: don't do DMA on stack

[Mauro Carvalho Chehab]

The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/dvb-usb/dibusb-common.c | 106 +-
 drivers/media/usb/dvb-usb/dibusb.h|   5 ++
 2 files changed, 81 insertions(+), 30 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/dibusb-common.c 
b/drivers/media/usb/dvb-usb/dibusb-common.c
index 4b08c2a47ae2..76b26dc7339c 100644
--- a/drivers/media/usb/dvb-usb/dibusb-common.c
+++ b/drivers/media/usb/dvb-usb/dibusb-common.c
@@ -12,9 +12,6 @@
 #include 
 #include "dibusb.h"
 
-/* Max transfer size done by I2C transfer functions */
-#define MAX_XFER_SIZE  64
-
 static int debug;
 module_param(debug, int, 0644);
 MODULE_PARM_DESC(debug, "set debugging level (1=info (|-able))." 
DVB_USB_DEBUG_STATUS);
@@ -63,72 +60,109 @@ EXPORT_SYMBOL(dibusb_pid_filter_ctrl);
 
 int dibusb_power_ctrl(struct dvb_usb_device *d, int onoff)
 {
-   u8 b[3];
+   u8 *b;
int ret;
+
+   b = kmalloc(3, GFP_KERNEL);
+   if (!b)
+   return -ENOMEM;
+
b[0] = DIBUSB_REQ_SET_IOCTL;
b[1] = DIBUSB_IOCTL_CMD_POWER_MODE;
b[2] = onoff ? DIBUSB_IOCTL_POWER_WAKEUP : DIBUSB_IOCTL_POWER_SLEEP;
-   ret = dvb_usb_generic_write(d,b,3);
+
+   ret = dvb_usb_generic_write(d, b, 3);
+
+   kfree(b);
+
msleep(10);
+
return ret;
 }
 EXPORT_SYMBOL(dibusb_power_ctrl);
 
 int dibusb2_0_streaming_ctrl(struct dvb_usb_adapter *adap, int onoff)
 {
-   u8 b[3] = { 0 };
+   struct dibusb_state *st = adap->priv;
int ret;
 
if ((ret = dibusb_streaming_ctrl(adap,onoff)) < 0)
return ret;
 
if (onoff) {
-   b[0] = DIBUSB_REQ_SET_STREAMING_MODE;
-   b[1] = 0x00;
-   if ((ret = dvb_usb_generic_write(adap->dev,b,2)) < 0)
+   st->data[0] = DIBUSB_REQ_SET_STREAMING_MODE;
+   st->data[1] = 0x00;
+   ret = dvb_usb_generic_write(adap->dev, st->data, 2);
+   if (ret  < 0)
return ret;
}
 
-   b[0] = DIBUSB_REQ_SET_IOCTL;
-   b[1] = onoff ? DIBUSB_IOCTL_CMD_ENABLE_STREAM : 
DIBUSB_IOCTL_CMD_DISABLE_STREAM;
-   return dvb_usb_generic_write(adap->dev,b,3);
+   st->data[0] = DIBUSB_REQ_SET_IOCTL;
+   st->data[1] = onoff ? DIBUSB_IOCTL_CMD_ENABLE_STREAM : 
DIBUSB_IOCTL_CMD_DISABLE_STREAM;
+   return dvb_usb_generic_write(adap->dev, st->data, 3);
 }
 EXPORT_SYMBOL(dibusb2_0_streaming_ctrl);
 
 int dibusb2_0_power_ctrl(struct dvb_usb_device *d, int onoff)
 {
-   if (onoff) {
-   u8 b[3] = { DIBUSB_REQ_SET_IOCTL, DIBUSB_IOCTL_CMD_POWER_MODE, 
DIBUSB_IOCTL_POWER_WAKEUP };
-   return dvb_usb_generic_write(d,b,3);
-   } else
+   u8 *b;
+   int ret;
+
+   if (!onoff)
return 0;
+
+   b = kmalloc(3, GFP_KERNEL);
+   if (!b)
+   return -ENOMEM;
+
+   b[0] = DIBUSB_REQ_SET_IOCTL;
+   b[1] = DIBUSB_IOCTL_CMD_POWER_MODE;
+   b[2] = DIBUSB_IOCTL_POWER_WAKEUP;
+
+   ret = dvb_usb_generic_write(d, b, 3);
+
+   kfree(b);
+
+   return ret;
 }
 EXPORT_SYMBOL(dibusb2_0_power_ctrl);
 
 static int dibusb_i2c_msg(struct dvb_usb_device *d, u8 addr,
  u8 *wbuf, u16 wlen, u8 *rbuf, u16 rlen)
 {
-   u8 sndbuf[MAX_XFER_SIZE]; /* lead(1) devaddr,direction(1) addr(2) 
data(wlen) (len(2) (when reading)) */
+   u8 *sndbuf;
+   int ret, wo, len;
+
/* write only ? */
-   int wo = (rbuf == NULL || rlen == 0),
-   len = 2 + wlen + (wo ? 0 : 2);
+   wo = (rbuf == NULL || rlen == 0);
 
-   if (4 + wlen > sizeof(sndbuf)) {
+   len = 2 + wlen + (wo ? 0 : 2);
+
+   sndbuf = kmalloc(MAX_XFER_SIZE, GFP_KERNEL);
+   if (!sndbuf)
+   return -ENOMEM;
+
+   if (4 + wlen > MAX_XFER_SIZE) {
warn("i2c wr: len=%d is too big!\n", wlen);
-   return -EOPNOTSUPP;
+   ret = -EOPNOTSUPP;
+   goto ret;
}
 
sndbuf[0] = wo ? DIBUSB_REQ_I2C_WRITE : DIBUSB_REQ_I2C_READ;
sndbuf[1] = (addr << 1) | (wo ? 0 : 1);
 
-   memcpy([2],wbuf,wlen);
+   memcpy([2], wbuf, wlen);
 
if (!wo) {
-   sndbuf[wlen+2] = (rlen >> 8) & 0xff;
-   sndbuf[wlen+3] = rlen & 0xff;
+   sndbuf[wlen + 2] = (rlen >> 8) & 0xff;
+   sndbuf[wlen + 3] = rlen & 0xff;
}
 
-   return dvb_usb_generic_rw(d,sndbuf,len,rbuf,rlen,0);
+   ret = dvb_usb_generic_rw(d, sndbuf, len, rbuf, rlen, 0);
+
+ret:
+   kfree(sndbuf);
+   return ret;
 }
 
 /*
@@ -320,11 +354,23 @@ EXPORT_SYMBOL(rc_map_dibusb_table);
 
 int dibusb_rc_query(struct dvb_usb_device *d, u32 *event, int *state)
 {
-   u8 key[5],cmd = DIBUSB_REQ_POLL_REMOTE;
-   

[PATCH 13/26] dtt200u-fe: handle errors on USB control messages

[Mauro Carvalho Chehab]

If something goes wrong, return an error code, instead of
assuming that everything went fine.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/dvb-usb/dtt200u-fe.c | 38 +++---
 1 file changed, 30 insertions(+), 8 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/dtt200u-fe.c 
b/drivers/media/usb/dvb-usb/dtt200u-fe.c
index 9ed68429e950..ede6e1bc7315 100644
--- a/drivers/media/usb/dvb-usb/dtt200u-fe.c
+++ b/drivers/media/usb/dvb-usb/dtt200u-fe.c
@@ -26,10 +26,15 @@ static int dtt200u_fe_read_status(struct dvb_frontend *fe,
  enum fe_status *stat)
 {
struct dtt200u_fe_state *state = fe->demodulator_priv;
+   int ret;
 
state->data[0] = GET_TUNE_STATUS;
 
-   dvb_usb_generic_rw(state->d, state->data, 1, state->data, 3, 0);
+   ret = dvb_usb_generic_rw(state->d, state->data, 1, state->data, 3, 0);
+   if (ret < 0) {
+   *stat = 0;
+   return ret;
+   }
 
switch (state->data[0]) {
case 0x01:
@@ -50,10 +55,14 @@ static int dtt200u_fe_read_status(struct dvb_frontend *fe,
 static int dtt200u_fe_read_ber(struct dvb_frontend* fe, u32 *ber)
 {
struct dtt200u_fe_state *state = fe->demodulator_priv;
+   int ret;
 
state->data[0] = GET_VIT_ERR_CNT;
 
-   dvb_usb_generic_rw(state->d, state->data, 1, state->data, 3, 0);
+   ret = dvb_usb_generic_rw(state->d, state->data, 1, state->data, 3, 0);
+   if (ret < 0)
+   return ret;
+
*ber = (state->data[0] << 16) | (state->data[1] << 8) | state->data[2];
return 0;
 }
@@ -61,10 +70,13 @@ static int dtt200u_fe_read_ber(struct dvb_frontend* fe, u32 
*ber)
 static int dtt200u_fe_read_unc_blocks(struct dvb_frontend* fe, u32 *unc)
 {
struct dtt200u_fe_state *state = fe->demodulator_priv;
+   int ret;
 
state->data[0] = GET_RS_UNCOR_BLK_CNT;
 
-   dvb_usb_generic_rw(state->d, state->data, 1, state->data, 2, 0);
+   ret = dvb_usb_generic_rw(state->d, state->data, 1, state->data, 2, 0);
+   if (ret < 0)
+   return ret;
 
*unc = (state->data[0] << 8) | state->data[1];
return 0;
@@ -73,10 +85,13 @@ static int dtt200u_fe_read_unc_blocks(struct dvb_frontend* 
fe, u32 *unc)
 static int dtt200u_fe_read_signal_strength(struct dvb_frontend* fe, u16 
*strength)
 {
struct dtt200u_fe_state *state = fe->demodulator_priv;
+   int ret;
 
state->data[0] = GET_AGC;
 
-   dvb_usb_generic_rw(state->d, state->data, 1, state->data, 1, 0);
+   ret = dvb_usb_generic_rw(state->d, state->data, 1, state->data, 1, 0);
+   if (ret < 0)
+   return ret;
 
*strength = (state->data[0] << 8) | state->data[0];
return 0;
@@ -85,10 +100,13 @@ static int dtt200u_fe_read_signal_strength(struct 
dvb_frontend* fe, u16 *strengt
 static int dtt200u_fe_read_snr(struct dvb_frontend* fe, u16 *snr)
 {
struct dtt200u_fe_state *state = fe->demodulator_priv;
+   int ret;
 
state->data[0] = GET_SNR;
 
-   dvb_usb_generic_rw(state->d, state->data, 1, state->data, 1, 0);
+   ret = dvb_usb_generic_rw(state->d, state->data, 1, state->data, 1, 0);
+   if (ret < 0)
+   return ret;
 
*snr = ~((state->data[0] << 8) | state->data[0]);
return 0;
@@ -120,7 +138,7 @@ static int dtt200u_fe_set_frontend(struct dvb_frontend *fe)
 {
struct dtv_frontend_properties *fep = >dtv_property_cache;
struct dtt200u_fe_state *state = fe->demodulator_priv;
-   int i;
+   int i, ret;
enum fe_status st;
u16 freq = fep->frequency / 25;
 
@@ -139,12 +157,16 @@ static int dtt200u_fe_set_frontend(struct dvb_frontend 
*fe)
return -EINVAL;
}
 
-   dvb_usb_generic_write(state->d, state->data, 2);
+   ret = dvb_usb_generic_write(state->d, state->data, 2);
+   if (ret < 0)
+   return ret;
 
state->data[0] = SET_RF_FREQ;
state->data[1] = freq & 0xff;
state->data[2] = (freq >> 8) & 0xff;
-   dvb_usb_generic_write(state->d, state->data, 3);
+   ret = dvb_usb_generic_write(state->d, state->data, 3);
+   if (ret < 0)
+   return ret;
 
for (i = 0; i < 30; i++) {
msleep(20);
-- 
2.7.4

[PATCH 06/26] cxusb: don't do DMA on stack

[Mauro Carvalho Chehab]

The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/dvb-usb/cxusb.c | 20 +++-
 drivers/media/usb/dvb-usb/cxusb.h |  5 +
 2 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/cxusb.c 
b/drivers/media/usb/dvb-usb/cxusb.c
index 907ac01ae297..f3615349de52 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -45,9 +45,6 @@
 #include "si2168.h"
 #include "si2157.h"
 
-/* Max transfer size done by I2C transfer functions */
-#define MAX_XFER_SIZE  80
-
 /* debug */
 static int dvb_usb_cxusb_debug;
 module_param_named(debug, dvb_usb_cxusb_debug, int, 0644);
@@ -61,23 +58,20 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 static int cxusb_ctrl_msg(struct dvb_usb_device *d,
  u8 cmd, u8 *wbuf, int wlen, u8 *rbuf, int rlen)
 {
+   struct cxusb_state *st = d->priv;
int wo = (rbuf == NULL || rlen == 0); /* write-only */
-   u8 sndbuf[MAX_XFER_SIZE];
 
-   if (1 + wlen > sizeof(sndbuf)) {
-   warn("i2c wr: len=%d is too big!\n",
-wlen);
+   if (1 + wlen > MAX_XFER_SIZE) {
+   warn("i2c wr: len=%d is too big!\n", wlen);
return -EOPNOTSUPP;
}
 
-   memset(sndbuf, 0, 1+wlen);
-
-   sndbuf[0] = cmd;
-   memcpy([1], wbuf, wlen);
+   st->data[0] = cmd;
+   memcpy(>data[1], wbuf, wlen);
if (wo)
-   return dvb_usb_generic_write(d, sndbuf, 1+wlen);
+   return dvb_usb_generic_write(d, st->data, 1 + wlen);
else
-   return dvb_usb_generic_rw(d, sndbuf, 1+wlen, rbuf, rlen, 0);
+   return dvb_usb_generic_rw(d, st->data, 1 + wlen, rbuf, rlen, 0);
 }
 
 /* GPIO */
diff --git a/drivers/media/usb/dvb-usb/cxusb.h 
b/drivers/media/usb/dvb-usb/cxusb.h
index 527ff7905e15..18acda19527a 100644
--- a/drivers/media/usb/dvb-usb/cxusb.h
+++ b/drivers/media/usb/dvb-usb/cxusb.h
@@ -28,10 +28,15 @@
 #define CMD_ANALOG0x50
 #define CMD_DIGITAL   0x51
 
+/* Max transfer size done by I2C transfer functions */
+#define MAX_XFER_SIZE  80
+
 struct cxusb_state {
u8 gpio_write_state[3];
struct i2c_client *i2c_client_demod;
struct i2c_client *i2c_client_tuner;
+
+   unsigned char data[MAX_XFER_SIZE];
 };
 
 #endif
-- 
2.7.4

[PATCH 04/26] cinergyT2-fe: cache stats at cinergyt2_fe_read_status()

[Mauro Carvalho Chehab]

Instead of sending USB commands for every stats call, collect
them once, when status is updated. As the frontend kthread
will call it on every few seconds, the stats will still be
collected.

Besides reducing the amount of USB/I2C transfers, this also
warrants that all stats will be collected at the same time,
and makes easier to convert it to DVBv5 stats in the future.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/dvb-usb/cinergyT2-fe.c | 48 +---
 1 file changed, 7 insertions(+), 41 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/cinergyT2-fe.c 
b/drivers/media/usb/dvb-usb/cinergyT2-fe.c
index b3ec743a7a2e..fd8edcb56e61 100644
--- a/drivers/media/usb/dvb-usb/cinergyT2-fe.c
+++ b/drivers/media/usb/dvb-usb/cinergyT2-fe.c
@@ -139,6 +139,7 @@ static uint16_t compute_tps(struct dtv_frontend_properties 
*op)
 struct cinergyt2_fe_state {
struct dvb_frontend fe;
struct dvb_usb_device *d;
+   struct dvbt_get_status_msg status;
 };
 
 static int cinergyt2_fe_read_status(struct dvb_frontend *fe,
@@ -154,6 +155,8 @@ static int cinergyt2_fe_read_status(struct dvb_frontend *fe,
if (ret < 0)
return ret;
 
+   state->status = result;
+
*status = 0;
 
if (0x - le16_to_cpu(result.gain) > 30)
@@ -177,34 +180,16 @@ static int cinergyt2_fe_read_status(struct dvb_frontend 
*fe,
 static int cinergyt2_fe_read_ber(struct dvb_frontend *fe, u32 *ber)
 {
struct cinergyt2_fe_state *state = fe->demodulator_priv;
-   struct dvbt_get_status_msg status;
-   char cmd[] = { CINERGYT2_EP1_GET_TUNER_STATUS };
-   int ret;
 
-   ret = dvb_usb_generic_rw(state->d, cmd, sizeof(cmd), (char *),
-   sizeof(status), 0);
-   if (ret < 0)
-   return ret;
-
-   *ber = le32_to_cpu(status.viterbi_error_rate);
+   *ber = le32_to_cpu(state->status.viterbi_error_rate);
return 0;
 }
 
 static int cinergyt2_fe_read_unc_blocks(struct dvb_frontend *fe, u32 *unc)
 {
struct cinergyt2_fe_state *state = fe->demodulator_priv;
-   struct dvbt_get_status_msg status;
-   u8 cmd[] = { CINERGYT2_EP1_GET_TUNER_STATUS };
-   int ret;
 
-   ret = dvb_usb_generic_rw(state->d, cmd, sizeof(cmd), (u8 *),
-   sizeof(status), 0);
-   if (ret < 0) {
-   err("cinergyt2_fe_read_unc_blocks() Failed! (Error=%d)\n",
-   ret);
-   return ret;
-   }
-   *unc = le32_to_cpu(status.uncorrected_block_count);
+   *unc = le32_to_cpu(state->status.uncorrected_block_count);
return 0;
 }
 
@@ -212,35 +197,16 @@ static int cinergyt2_fe_read_signal_strength(struct 
dvb_frontend *fe,
u16 *strength)
 {
struct cinergyt2_fe_state *state = fe->demodulator_priv;
-   struct dvbt_get_status_msg status;
-   char cmd[] = { CINERGYT2_EP1_GET_TUNER_STATUS };
-   int ret;
 
-   ret = dvb_usb_generic_rw(state->d, cmd, sizeof(cmd), (char *),
-   sizeof(status), 0);
-   if (ret < 0) {
-   err("cinergyt2_fe_read_signal_strength() Failed!"
-   " (Error=%d)\n", ret);
-   return ret;
-   }
-   *strength = (0x - le16_to_cpu(status.gain));
+   *strength = (0x - le16_to_cpu(state->status.gain));
return 0;
 }
 
 static int cinergyt2_fe_read_snr(struct dvb_frontend *fe, u16 *snr)
 {
struct cinergyt2_fe_state *state = fe->demodulator_priv;
-   struct dvbt_get_status_msg status;
-   char cmd[] = { CINERGYT2_EP1_GET_TUNER_STATUS };
-   int ret;
 
-   ret = dvb_usb_generic_rw(state->d, cmd, sizeof(cmd), (char *),
-   sizeof(status), 0);
-   if (ret < 0) {
-   err("cinergyt2_fe_read_snr() Failed! (Error=%d)\n", ret);
-   return ret;
-   }
-   *snr = (status.snr << 8) | status.snr;
+   *snr = (state->status.snr << 8) | state->status.snr;
return 0;
 }
 
-- 
2.7.4

[PATCH 12/26] dtt200u-fe: don't do DMA on stack

[Mauro Carvalho Chehab]

The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/dvb-usb/dtt200u-fe.c | 66 +-
 1 file changed, 41 insertions(+), 25 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/dtt200u-fe.c 
b/drivers/media/usb/dvb-usb/dtt200u-fe.c
index c09332bd99cb..9ed68429e950 100644
--- a/drivers/media/usb/dvb-usb/dtt200u-fe.c
+++ b/drivers/media/usb/dvb-usb/dtt200u-fe.c
@@ -18,17 +18,20 @@ struct dtt200u_fe_state {
 
struct dtv_frontend_properties fep;
struct dvb_frontend frontend;
+
+   unsigned char data[80];
 };
 
 static int dtt200u_fe_read_status(struct dvb_frontend *fe,
  enum fe_status *stat)
 {
struct dtt200u_fe_state *state = fe->demodulator_priv;
-   u8 st = GET_TUNE_STATUS, b[3];
 
-   dvb_usb_generic_rw(state->d,,1,b,3,0);
+   state->data[0] = GET_TUNE_STATUS;
 
-   switch (b[0]) {
+   dvb_usb_generic_rw(state->d, state->data, 1, state->data, 3, 0);
+
+   switch (state->data[0]) {
case 0x01:
*stat = FE_HAS_SIGNAL | FE_HAS_CARRIER |
FE_HAS_VITERBI | FE_HAS_SYNC | FE_HAS_LOCK;
@@ -47,45 +50,57 @@ static int dtt200u_fe_read_status(struct dvb_frontend *fe,
 static int dtt200u_fe_read_ber(struct dvb_frontend* fe, u32 *ber)
 {
struct dtt200u_fe_state *state = fe->demodulator_priv;
-   u8 bw = GET_VIT_ERR_CNT,b[3];
-   dvb_usb_generic_rw(state->d,,1,b,3,0);
-   *ber = (b[0] << 16) | (b[1] << 8) | b[2];
+
+   state->data[0] = GET_VIT_ERR_CNT;
+
+   dvb_usb_generic_rw(state->d, state->data, 1, state->data, 3, 0);
+   *ber = (state->data[0] << 16) | (state->data[1] << 8) | state->data[2];
return 0;
 }
 
 static int dtt200u_fe_read_unc_blocks(struct dvb_frontend* fe, u32 *unc)
 {
struct dtt200u_fe_state *state = fe->demodulator_priv;
-   u8 bw = GET_RS_UNCOR_BLK_CNT,b[2];
 
-   dvb_usb_generic_rw(state->d,,1,b,2,0);
-   *unc = (b[0] << 8) | b[1];
+   state->data[0] = GET_RS_UNCOR_BLK_CNT;
+
+   dvb_usb_generic_rw(state->d, state->data, 1, state->data, 2, 0);
+
+   *unc = (state->data[0] << 8) | state->data[1];
return 0;
 }
 
 static int dtt200u_fe_read_signal_strength(struct dvb_frontend* fe, u16 
*strength)
 {
struct dtt200u_fe_state *state = fe->demodulator_priv;
-   u8 bw = GET_AGC, b;
-   dvb_usb_generic_rw(state->d,,1,,1,0);
-   *strength = (b << 8) | b;
+
+   state->data[0] = GET_AGC;
+
+   dvb_usb_generic_rw(state->d, state->data, 1, state->data, 1, 0);
+
+   *strength = (state->data[0] << 8) | state->data[0];
return 0;
 }
 
 static int dtt200u_fe_read_snr(struct dvb_frontend* fe, u16 *snr)
 {
struct dtt200u_fe_state *state = fe->demodulator_priv;
-   u8 bw = GET_SNR,br;
-   dvb_usb_generic_rw(state->d,,1,,1,0);
-   *snr = ~((br << 8) | br);
+
+   state->data[0] = GET_SNR;
+
+   dvb_usb_generic_rw(state->d, state->data, 1, state->data, 1, 0);
+
+   *snr = ~((state->data[0] << 8) | state->data[0]);
return 0;
 }
 
 static int dtt200u_fe_init(struct dvb_frontend* fe)
 {
struct dtt200u_fe_state *state = fe->demodulator_priv;
-   u8 b = SET_INIT;
-   return dvb_usb_generic_write(state->d,,1);
+
+   state->data[0] = SET_INIT;
+
+   return dvb_usb_generic_write(state->d, state->data, 1);
 }
 
 static int dtt200u_fe_sleep(struct dvb_frontend* fe)
@@ -108,27 +123,28 @@ static int dtt200u_fe_set_frontend(struct dvb_frontend 
*fe)
int i;
enum fe_status st;
u16 freq = fep->frequency / 25;
-   u8 bwbuf[2] = { SET_BANDWIDTH, 0 },freqbuf[3] = { SET_RF_FREQ, 0, 0 };
 
+   state->data[0] = SET_BANDWIDTH;
switch (fep->bandwidth_hz) {
case 800:
-   bwbuf[1] = 8;
+   state->data[1] = 8;
break;
case 700:
-   bwbuf[1] = 7;
+   state->data[1] = 7;
break;
case 600:
-   bwbuf[1] = 6;
+   state->data[1] = 6;
break;
default:
return -EINVAL;
}
 
-   dvb_usb_generic_write(state->d,bwbuf,2);
+   dvb_usb_generic_write(state->d, state->data, 2);
 
-   freqbuf[1] = freq & 0xff;
-   freqbuf[2] = (freq >> 8) & 0xff;
-   dvb_usb_generic_write(state->d,freqbuf,3);
+   state->data[0] = SET_RF_FREQ;
+   state->data[1] = freq & 0xff;
+   state->data[2] = (freq >> 8) & 0xff;
+   dvb_usb_generic_write(state->d, state->data, 3);
 
for (i = 0; i < 30; i++) {
msleep(20);
-- 
2.7.4

[PATCH 03/26] cinergyT2-core:: handle error code on RC query

[Mauro Carvalho Chehab]

There's no sense on decoding and generating a RC key code if
there was an error on the URB control message.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/dvb-usb/cinergyT2-core.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/cinergyT2-core.c 
b/drivers/media/usb/dvb-usb/cinergyT2-core.c
index 91640c927776..c9633f5dd482 100644
--- a/drivers/media/usb/dvb-usb/cinergyT2-core.c
+++ b/drivers/media/usb/dvb-usb/cinergyT2-core.c
@@ -89,7 +89,7 @@ static int cinergyt2_frontend_attach(struct dvb_usb_adapter 
*adap)
/* Copy this pointer as we are gonna need it in the release phase */
cinergyt2_usb_device = adap->dev;
 
-   return 0;
+   return ret;
 }
 
 static struct rc_map_table rc_map_cinergyt2_table[] = {
@@ -149,13 +149,16 @@ static int repeatable_keys[] = {
 static int cinergyt2_rc_query(struct dvb_usb_device *d, u32 *event, int *state)
 {
struct cinergyt2_state *st = d->priv;
-   int i;
+   int i, ret;
 
*state = REMOTE_NO_KEY_PRESSED;
 
st->data[0] = CINERGYT2_EP1_GET_RC_EVENTS;
 
-   dvb_usb_generic_rw(d, st->data, 1, st->data, 5, 0);
+   ret = dvb_usb_generic_rw(d, st->data, 1, st->data, 5, 0);
+   if (ret < 0)
+   return ret;
+
if (st->data[4] == 0xff) {
/* key repeat */
st->rc_counter++;
-- 
2.7.4

[PATCH 25/26] dw2102: return error if su3000_power_ctrl() fails

[Mauro Carvalho Chehab]

Instead of silently ignoring the error, return it.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/dvb-usb/dw2102.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/dvb-usb/dw2102.c 
b/drivers/media/usb/dvb-usb/dw2102.c
index 5fb0c650926e..2c720cb2fb00 100644
--- a/drivers/media/usb/dvb-usb/dw2102.c
+++ b/drivers/media/usb/dvb-usb/dw2102.c
@@ -852,7 +852,7 @@ static int su3000_power_ctrl(struct dvb_usb_device *d, int 
i)
if (i && !state->initialized) {
state->initialized = 1;
/* reset board */
-   dvb_usb_generic_rw(d, obuf, 2, NULL, 0, 0);
+   return dvb_usb_generic_rw(d, obuf, 2, NULL, 0, 0);
}
 
return 0;
-- 
2.7.4

[PATCH 08/26] dib0700_core: don't use stack on I2C reads

[Mauro Carvalho Chehab]

Be sure that I2C reads won't use stack by passing
a pointer to the state buffer, that we know it was
allocated via kmalloc, instead of relying on the buffer
allocated by an I2C client.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/dvb-usb/dib0700_core.c | 27 ++-
 1 file changed, 26 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c 
b/drivers/media/usb/dvb-usb/dib0700_core.c
index 515f89dba199..92d5408684ac 100644
--- a/drivers/media/usb/dvb-usb/dib0700_core.c
+++ b/drivers/media/usb/dvb-usb/dib0700_core.c
@@ -213,7 +213,7 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap, 
struct i2c_msg *msg,
 usb_rcvctrlpipe(d->udev, 0),
 REQUEST_NEW_I2C_READ,
 USB_TYPE_VENDOR | USB_DIR_IN,
-value, index, msg[i].buf,
+value, index, st->buf,
 msg[i].len,
 USB_CTRL_GET_TIMEOUT);
if (result < 0) {
@@ -221,6 +221,14 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap, 
struct i2c_msg *msg,
break;
}
 
+   if (msg[i].len > sizeof(st->buf)) {
+   deb_info("buffer too small to fit %d bytes\n",
+msg[i].len);
+   return -EIO;
+   }
+
+   memcpy(msg[i].buf, st->buf, msg[i].len);
+
deb_data("<<< ");
debug_dump(msg[i].buf, msg[i].len, deb_data);
 
@@ -238,6 +246,13 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap, 
struct i2c_msg *msg,
/* I2C ctrl + FE bus; */
st->buf[3] = ((gen_mode << 6) & 0xC0) |
 ((bus_mode << 4) & 0x30);
+
+   if (msg[i].len > sizeof(st->buf) - 4) {
+   deb_info("i2c message to big: %d\n",
+msg[i].len);
+   return -EIO;
+   }
+
/* The Actual i2c payload */
memcpy(>buf[4], msg[i].buf, msg[i].len);
 
@@ -283,6 +298,11 @@ static int dib0700_i2c_xfer_legacy(struct i2c_adapter 
*adap,
/* fill in the address */
st->buf[1] = msg[i].addr << 1;
/* fill the buffer */
+   if (msg[i].len > sizeof(st->buf) - 2) {
+   deb_info("i2c xfer to big: %d\n",
+   msg[i].len);
+   return -EIO;
+   }
memcpy(>buf[2], msg[i].buf, msg[i].len);
 
/* write/read request */
@@ -299,6 +319,11 @@ static int dib0700_i2c_xfer_legacy(struct i2c_adapter 
*adap,
break;
}
 
+   if (msg[i + 1].len > sizeof(st->buf)) {
+   deb_info("i2c xfer buffer to small for %d\n",
+   msg[i].len);
+   return -EIO;
+   }
memcpy(msg[i + 1].buf, st->buf, msg[i + 1].len);
 
msg[i+1].len = len;
-- 
2.7.4

[PATCH 14/26] dtt200u: don't do DMA on stack

[Mauro Carvalho Chehab]

From: Mauro Carvalho Chehab 

The USB control messages require DMA to work. We cannot pass
a stack-allocated buffer, as it is not warranted that the
stack would be into a DMA enabled area.

Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/dvb-usb/dtt200u.c | 73 +
 1 file changed, 49 insertions(+), 24 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/dtt200u.c 
b/drivers/media/usb/dvb-usb/dtt200u.c
index d2a01b50af0d..d6023fb6a1d4 100644
--- a/drivers/media/usb/dvb-usb/dtt200u.c
+++ b/drivers/media/usb/dvb-usb/dtt200u.c
@@ -20,73 +20,88 @@ MODULE_PARM_DESC(debug, "set debugging level (1=info,xfer=2 
(or-able))." DVB_USB
 
 DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
 
+struct dtt200u_state {
+   unsigned char data[80];
+};
+
 static int dtt200u_power_ctrl(struct dvb_usb_device *d, int onoff)
 {
-   u8 b = SET_INIT;
+   struct dtt200u_state *st = d->priv;
+
+   st->data[0] = SET_INIT;
 
if (onoff)
-   dvb_usb_generic_write(d,,2);
+   dvb_usb_generic_write(d, st->data, 2);
 
return 0;
 }
 
 static int dtt200u_streaming_ctrl(struct dvb_usb_adapter *adap, int onoff)
 {
-   u8 b_streaming[2] = { SET_STREAMING, onoff };
-   u8 b_rst_pid = RESET_PID_FILTER;
+   struct dtt200u_state *st = adap->dev->priv;
 
-   dvb_usb_generic_write(adap->dev, b_streaming, 2);
+   st->data[0] = SET_STREAMING;
+   st->data[1] = onoff;
+
+   dvb_usb_generic_write(adap->dev, st->data, 2);
+
+   if (onoff)
+   return 0;
+
+   st->data[0] = RESET_PID_FILTER;
+   dvb_usb_generic_write(adap->dev, st->data, 1);
 
-   if (onoff == 0)
-   dvb_usb_generic_write(adap->dev, _rst_pid, 1);
return 0;
 }
 
 static int dtt200u_pid_filter(struct dvb_usb_adapter *adap, int index, u16 
pid, int onoff)
 {
-   u8 b_pid[4];
+   struct dtt200u_state *st = adap->dev->priv;
+
pid = onoff ? pid : 0;
 
-   b_pid[0] = SET_PID_FILTER;
-   b_pid[1] = index;
-   b_pid[2] = pid & 0xff;
-   b_pid[3] = (pid >> 8) & 0x1f;
+   st->data[0] = SET_PID_FILTER;
+   st->data[1] = index;
+   st->data[2] = pid & 0xff;
+   st->data[3] = (pid >> 8) & 0x1f;
 
-   return dvb_usb_generic_write(adap->dev, b_pid, 4);
+   return dvb_usb_generic_write(adap->dev, st->data, 4);
 }
 
 static int dtt200u_rc_query(struct dvb_usb_device *d)
 {
-   u8 key[5],cmd = GET_RC_CODE;
+   struct dtt200u_state *st = d->priv;
u32 scancode;
 
-   dvb_usb_generic_rw(d,,1,key,5,0);
-   if (key[0] == 1) {
+   st->data[0] = GET_RC_CODE;
+
+   dvb_usb_generic_rw(d, st->data, 1, st->data, 5, 0);
+   if (st->data[0] == 1) {
enum rc_type proto = RC_TYPE_NEC;
 
-   scancode = key[1];
-   if ((u8) ~key[1] != key[2]) {
+   scancode = st->data[1];
+   if ((u8) ~st->data[1] != st->data[2]) {
/* Extended NEC */
scancode = scancode << 8;
-   scancode |= key[2];
+   scancode |= st->data[2];
proto = RC_TYPE_NECX;
}
scancode = scancode << 8;
-   scancode |= key[3];
+   scancode |= st->data[3];
 
/* Check command checksum is ok */
-   if ((u8) ~key[3] == key[4])
+   if ((u8) ~st->data[3] == st->data[4])
rc_keydown(d->rc_dev, proto, scancode, 0);
else
rc_keyup(d->rc_dev);
-   } else if (key[0] == 2) {
+   } else if (st->data[0] == 2) {
rc_repeat(d->rc_dev);
} else {
rc_keyup(d->rc_dev);
}
 
-   if (key[0] != 0)
-   deb_info("key: %*ph\n", 5, key);
+   if (st->data[0] != 0)
+   deb_info("st->data: %*ph\n", 5, st->data);
 
return 0;
 }
@@ -140,6 +155,8 @@ static struct dvb_usb_device_properties dtt200u_properties 
= {
.usb_ctrl = CYPRESS_FX2,
.firmware = "dvb-usb-dtt200u-01.fw",
 
+   .size_of_priv = sizeof(struct dtt200u_state),
+
.num_adapters = 1,
.adapter = {
{
@@ -190,6 +207,8 @@ static struct dvb_usb_device_properties wt220u_properties = 
{
.usb_ctrl = CYPRESS_FX2,
.firmware = "dvb-usb-wt220u-02.fw",
 
+   .size_of_priv = sizeof(struct dtt200u_state),
+
.num_adapters = 1,
.adapter = {
{
@@ -240,6 +259,8 @@ static struct dvb_usb_device_properties 
wt220u_fc_properties = {
.usb_ctrl = CYPRESS_FX2,
.firmware = "dvb-usb-wt220u-fc03.fw",
 
+   .size_of_priv = sizeof(struct dtt200u_state),
+
.num_adapters = 1,
.adapter = {
{
@@ -290,6 +311,8 @@ static