Re: [PATCH] vfio/pci: Support error recovery

[Alex Williamson]

On Thu, 15 Dec 2016 01:00:06 +0200
"Michael S. Tsirkin"  wrote:

> On Wed, Dec 14, 2016 at 03:47:43PM -0700, Alex Williamson wrote:
> > On Thu, 15 Dec 2016 00:20:20 +0200
> > "Michael S. Tsirkin"  wrote:
> >   
> > > On Tue, Dec 13, 2016 at 08:00:22PM -0700, Alex Williamson wrote:  
> > > > On Wed, 14 Dec 2016 03:58:17 +0200
> > > > "Michael S. Tsirkin"  wrote:
> > > > 
> > > > > On Tue, Dec 13, 2016 at 09:27:59AM -0700, Alex Williamson wrote:
> > > > > > On Tue, 13 Dec 2016 18:12:34 +0200
> > > > > > "Michael S. Tsirkin"  wrote:
> > > > > >   
> > > > > > > On Mon, Dec 12, 2016 at 08:39:48PM -0700, Alex Williamson wrote:  
> > > > > > > 
> > > > > > > > On Tue, 13 Dec 2016 05:15:13 +0200
> > > > > > > > "Michael S. Tsirkin"  wrote:
> > > > > > > > 
> > > > > > > > > On Mon, Dec 12, 2016 at 03:43:13PM -0700, Alex Williamson 
> > > > > > > > > wrote:
> > > > > > > > > > > So just don't do it then. Topology must match between 
> > > > > > > > > > > host and guest,
> > > > > > > > > > > except maybe for the case of devices with host driver  
> > > > > > > > > > > (e.g. PF)
> > > > > > > > > > > which we might be able to synchronize against.  
> > > > > > > > > > 
> > > > > > > > > > We're talking about host kernel level handling here.  The 
> > > > > > > > > > host kernel
> > > > > > > > > > cannot defer the link reset to the user under the 
> > > > > > > > > > assumption that the
> > > > > > > > > > user is handling the devices in a very specific way.  The 
> > > > > > > > > > moment we do
> > > > > > > > > > that, we've lost.  
> > > > > > > > > 
> > > > > > > > > The way is same as baremetal though, so why not?
> > > > > > > > 
> > > > > > > > How do we know this?  What if the user is dpdk?  The kernel is
> > > > > > > > responsible for maintaining the integrity of the system and 
> > > > > > > > devices,
> > > > > > > > not the user.
> > > > > > > > 
> > > > > > > > > And if user doesn't do what's expected, we can
> > > > > > > > > do the full link reset on close.
> > > > > > > > 
> > > > > > > > That's exactly my point, if we're talking about multiple 
> > > > > > > > devices,
> > > > > > > > there's no guarantee that the close() for each is simultaneous. 
> > > > > > > >  If one
> > > > > > > > function is released before the other we cannot do a bus reset. 
> > > > > > > >  If
> > > > > > > > that device is then opened by another user before its sibling is
> > > > > > > > released, then we once again cannot perform a link reset.  I 
> > > > > > > > don't
> > > > > > > > think it would be reasonable to mark the released device 
> > > > > > > > quarantined
> > > > > > > > until the sibling is released, that would be a terrible user 
> > > > > > > > experience.
> > > > > > > 
> > > > > > > Not sure why you find it so terrible, and I don't think there's 
> > > > > > > another way.  
> > > > > > 
> > > > > > If we can't do it without regressing the support we currently have,
> > > > > > let's not do it at all.  
> > > > > 
> > > > > Why would we regress?  As long as there are no unrecoverable errors,
> > > > > there's no need to change behaviour at all.
> > > > 
> > > > Currently if a fatal error occurs we allow the host to reset the
> > > > device, so to the best of our knowledge, the device is always reset.
> > > > The proposal here allows gaps where we assume a particular guest
> > > > behavior that allows the device to be returned to the host or opened by
> > > > other users without that reset.  Any plan that relies on a specific
> > > > user behavior is fundamentally wrong imo.
> > > > 
> > > > > Alex, do you have a picture of how error recovery can work in your 
> > > > > mind?
> > > > > Your answers seem to imply you do, and these patches don't implement
> > > > > this correctly.  I'm not sure about others, but I for one am unable to
> > > > > piece it together from the comments you provide.  If yes, could you
> > > > > maybe do a short writeup of an architecture you would be comfortable
> > > > > with?
> > > > 
> > > > Clearly I have issues with this skip-the-host-reset plan, I don't think
> > > > it works.  We cannot assume the user will do error recovery.
> > > 
> > > Absolutely but we can defer recovery until device close.  
> > 
> > No we can't, as I've tried to describe multiple times, if the functions
> > are part of separate groups then they can be opened and closed
> > asynchronously from each other and we may not have an opportunity where
> > they are all closed together to perform a reset.
> > The only option I can
> > see for this is to quarantine the device, which as I've stated seems
> > like a really poor solution.
> >   
> > > Possibly with userspace invoking an ioctl requesting this,
> > > to make sure we don't break any legacy setups.  
> > 
> > And how do we know that user is not malicious?  How 

Re: [PATCH] vfio/pci: Support error recovery

[Alex Williamson]

On Thu, 15 Dec 2016 01:00:06 +0200
"Michael S. Tsirkin"  wrote:

> On Wed, Dec 14, 2016 at 03:47:43PM -0700, Alex Williamson wrote:
> > On Thu, 15 Dec 2016 00:20:20 +0200
> > "Michael S. Tsirkin"  wrote:
> >   
> > > On Tue, Dec 13, 2016 at 08:00:22PM -0700, Alex Williamson wrote:  
> > > > On Wed, 14 Dec 2016 03:58:17 +0200
> > > > "Michael S. Tsirkin"  wrote:
> > > > 
> > > > > On Tue, Dec 13, 2016 at 09:27:59AM -0700, Alex Williamson wrote:
> > > > > > On Tue, 13 Dec 2016 18:12:34 +0200
> > > > > > "Michael S. Tsirkin"  wrote:
> > > > > >   
> > > > > > > On Mon, Dec 12, 2016 at 08:39:48PM -0700, Alex Williamson wrote:  
> > > > > > > 
> > > > > > > > On Tue, 13 Dec 2016 05:15:13 +0200
> > > > > > > > "Michael S. Tsirkin"  wrote:
> > > > > > > > 
> > > > > > > > > On Mon, Dec 12, 2016 at 03:43:13PM -0700, Alex Williamson 
> > > > > > > > > wrote:
> > > > > > > > > > > So just don't do it then. Topology must match between 
> > > > > > > > > > > host and guest,
> > > > > > > > > > > except maybe for the case of devices with host driver  
> > > > > > > > > > > (e.g. PF)
> > > > > > > > > > > which we might be able to synchronize against.  
> > > > > > > > > > 
> > > > > > > > > > We're talking about host kernel level handling here.  The 
> > > > > > > > > > host kernel
> > > > > > > > > > cannot defer the link reset to the user under the 
> > > > > > > > > > assumption that the
> > > > > > > > > > user is handling the devices in a very specific way.  The 
> > > > > > > > > > moment we do
> > > > > > > > > > that, we've lost.  
> > > > > > > > > 
> > > > > > > > > The way is same as baremetal though, so why not?
> > > > > > > > 
> > > > > > > > How do we know this?  What if the user is dpdk?  The kernel is
> > > > > > > > responsible for maintaining the integrity of the system and 
> > > > > > > > devices,
> > > > > > > > not the user.
> > > > > > > > 
> > > > > > > > > And if user doesn't do what's expected, we can
> > > > > > > > > do the full link reset on close.
> > > > > > > > 
> > > > > > > > That's exactly my point, if we're talking about multiple 
> > > > > > > > devices,
> > > > > > > > there's no guarantee that the close() for each is simultaneous. 
> > > > > > > >  If one
> > > > > > > > function is released before the other we cannot do a bus reset. 
> > > > > > > >  If
> > > > > > > > that device is then opened by another user before its sibling is
> > > > > > > > released, then we once again cannot perform a link reset.  I 
> > > > > > > > don't
> > > > > > > > think it would be reasonable to mark the released device 
> > > > > > > > quarantined
> > > > > > > > until the sibling is released, that would be a terrible user 
> > > > > > > > experience.
> > > > > > > 
> > > > > > > Not sure why you find it so terrible, and I don't think there's 
> > > > > > > another way.  
> > > > > > 
> > > > > > If we can't do it without regressing the support we currently have,
> > > > > > let's not do it at all.  
> > > > > 
> > > > > Why would we regress?  As long as there are no unrecoverable errors,
> > > > > there's no need to change behaviour at all.
> > > > 
> > > > Currently if a fatal error occurs we allow the host to reset the
> > > > device, so to the best of our knowledge, the device is always reset.
> > > > The proposal here allows gaps where we assume a particular guest
> > > > behavior that allows the device to be returned to the host or opened by
> > > > other users without that reset.  Any plan that relies on a specific
> > > > user behavior is fundamentally wrong imo.
> > > > 
> > > > > Alex, do you have a picture of how error recovery can work in your 
> > > > > mind?
> > > > > Your answers seem to imply you do, and these patches don't implement
> > > > > this correctly.  I'm not sure about others, but I for one am unable to
> > > > > piece it together from the comments you provide.  If yes, could you
> > > > > maybe do a short writeup of an architecture you would be comfortable
> > > > > with?
> > > > 
> > > > Clearly I have issues with this skip-the-host-reset plan, I don't think
> > > > it works.  We cannot assume the user will do error recovery.
> > > 
> > > Absolutely but we can defer recovery until device close.  
> > 
> > No we can't, as I've tried to describe multiple times, if the functions
> > are part of separate groups then they can be opened and closed
> > asynchronously from each other and we may not have an opportunity where
> > they are all closed together to perform a reset.
> > The only option I can
> > see for this is to quarantine the device, which as I've stated seems
> > like a really poor solution.
> >   
> > > Possibly with userspace invoking an ioctl requesting this,
> > > to make sure we don't break any legacy setups.  
> > 
> > And how do we know that user is not malicious?  How do we police
> > whether they actually perform a reset?  We can only track whether a

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

[Linus Torvalds]

On Wed, Dec 14, 2016 at 2:56 PM, Jason A. Donenfeld  wrote:
>
> So actually jhash_Nwords makes no sense, since it takes dwords
> (32-bits) not words (16-bits). The siphash analog should be called
> siphash24_Nqwords.

No. The bug is talking about "words" in the first place.

Depending on your background, a "word" can be generally be either 16
bits or 32 bits (or, in some cases, 18 bits).

In theory, a 64-bit entity can be a "word" too, but pretty much nobody
uses that. Even architectures that started out with a 64-bit register
size and never had any smaller historical baggage (eg alpha) tend to
call 32-bit entities "words".

So 16 bits can be a word, but some people/architectures will call it a
"half-word".

To make matters even more confusing, a "quadword" is generally always
64 bits, regardless of the size of "word".

So please try to avoid the use of "word" entirely. It's too ambiguous,
and it's not even helpful as a "size of the native register". It's
almost purely random.

For the kernel, we tend use

 - uX for types that have specific sizes (X being the number of bits)

 - "[unsigned] long" for native register size

But never "word".

   Linus

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

[Linus Torvalds]

On Wed, Dec 14, 2016 at 2:56 PM, Jason A. Donenfeld  wrote:
>
> So actually jhash_Nwords makes no sense, since it takes dwords
> (32-bits) not words (16-bits). The siphash analog should be called
> siphash24_Nqwords.

No. The bug is talking about "words" in the first place.

Depending on your background, a "word" can be generally be either 16
bits or 32 bits (or, in some cases, 18 bits).

In theory, a 64-bit entity can be a "word" too, but pretty much nobody
uses that. Even architectures that started out with a 64-bit register
size and never had any smaller historical baggage (eg alpha) tend to
call 32-bit entities "words".

So 16 bits can be a word, but some people/architectures will call it a
"half-word".

To make matters even more confusing, a "quadword" is generally always
64 bits, regardless of the size of "word".

So please try to avoid the use of "word" entirely. It's too ambiguous,
and it's not even helpful as a "size of the native register". It's
almost purely random.

For the kernel, we tend use

 - uX for types that have specific sizes (X being the number of bits)

 - "[unsigned] long" for native register size

But never "word".

   Linus

Re: CVE-2016-7097 causes acl leak

[Greg KH]

On Wed, Dec 14, 2016 at 12:20:50PM -0800, Mark Salyzyn wrote:
> On 12/13/2016 04:00 PM, Greg KH wrote:
> > On Tue, Dec 13, 2016 at 03:42:58PM -0800, Mark Salyzyn wrote:
> > > On 12/12/2016 10:26 PM, Cong Wang wrote:
> > > > On Mon, Dec 12, 2016 at 4:26 PM, Mark Salyzyn  
> > > > wrote:
> > > > > The leaks were introduced in 9p, gfs2, jfs and xfs drivers only.
> > > > Only the 9p case is obvious to me:
> > > > 
> > > > diff --git a/fs/9p/acl.c b/fs/9p/acl.c
> > > > index b3c2cc7..082d227 100644
> > > > --- a/fs/9p/acl.c
> > > > +++ b/fs/9p/acl.c
> > > > @@ -277,6 +277,7 @@ static int v9fs_xattr_set_acl(const struct
> > > > xattr_handler *handler,
> > > >   case ACL_TYPE_ACCESS:
> > > >   if (acl) {
> > > >   struct iattr iattr;
> > > > +   struct posix_acl *old_acl = acl;
> > > > 
> > > >   retval = posix_acl_update_mode(inode,
> > > > _mode, );
> > > >   if (retval)
> > > > @@ -287,6 +288,7 @@ static int v9fs_xattr_set_acl(const struct
> > > > xattr_handler *handler,
> > > >* by the mode bits. So don't
> > > >* update ACL.
> > > >*/
> > > > +   posix_acl_release(old_acl);
> > > >   value = NULL;
> > > >   size = 0;
> > > >   }
> > > > 
> > > > 
> > > > The rest are anti-pattern (modifying parameters on stack via address)
> > > > but look correct.
> > > Greg KH: Beware that this similar fix needs to be applied to _backports_ 
> > > to
> > > stable kernel trees on other filesystem driver that have the same pattern
> > > (with local posix_acl_release(acl) calls). I have found that depending on
> > > vintage these would include this driver 9p, and possibly gfs2, jfs and 
> > > xfs.
> > > Be aware.
> > I don't understand what you mean here.  What needs to be "backported" to
> > the stable tree?  What commit in Linus's tree do I pick?  If not a
> > commit there, where is it?
> > 
> > totally confused,
> > 
> > greg k-h
> 
> In 3.10-stable if you took the original CVE-2016-7097 fix it could break
> four file system drivers, the fix for each would 'look like' this one fix
> for the 9p driver.

Did I take the fix in 3.10-stable?  What was the git commit id?  Is 3.10
"broken" in this way?  Is any other stable kernel broken?

I still don't have any idea of what is going on here...

greg k-h

Re: CVE-2016-7097 causes acl leak

[Greg KH]

On Wed, Dec 14, 2016 at 12:20:50PM -0800, Mark Salyzyn wrote:
> On 12/13/2016 04:00 PM, Greg KH wrote:
> > On Tue, Dec 13, 2016 at 03:42:58PM -0800, Mark Salyzyn wrote:
> > > On 12/12/2016 10:26 PM, Cong Wang wrote:
> > > > On Mon, Dec 12, 2016 at 4:26 PM, Mark Salyzyn  
> > > > wrote:
> > > > > The leaks were introduced in 9p, gfs2, jfs and xfs drivers only.
> > > > Only the 9p case is obvious to me:
> > > > 
> > > > diff --git a/fs/9p/acl.c b/fs/9p/acl.c
> > > > index b3c2cc7..082d227 100644
> > > > --- a/fs/9p/acl.c
> > > > +++ b/fs/9p/acl.c
> > > > @@ -277,6 +277,7 @@ static int v9fs_xattr_set_acl(const struct
> > > > xattr_handler *handler,
> > > >   case ACL_TYPE_ACCESS:
> > > >   if (acl) {
> > > >   struct iattr iattr;
> > > > +   struct posix_acl *old_acl = acl;
> > > > 
> > > >   retval = posix_acl_update_mode(inode,
> > > > _mode, );
> > > >   if (retval)
> > > > @@ -287,6 +288,7 @@ static int v9fs_xattr_set_acl(const struct
> > > > xattr_handler *handler,
> > > >* by the mode bits. So don't
> > > >* update ACL.
> > > >*/
> > > > +   posix_acl_release(old_acl);
> > > >   value = NULL;
> > > >   size = 0;
> > > >   }
> > > > 
> > > > 
> > > > The rest are anti-pattern (modifying parameters on stack via address)
> > > > but look correct.
> > > Greg KH: Beware that this similar fix needs to be applied to _backports_ 
> > > to
> > > stable kernel trees on other filesystem driver that have the same pattern
> > > (with local posix_acl_release(acl) calls). I have found that depending on
> > > vintage these would include this driver 9p, and possibly gfs2, jfs and 
> > > xfs.
> > > Be aware.
> > I don't understand what you mean here.  What needs to be "backported" to
> > the stable tree?  What commit in Linus's tree do I pick?  If not a
> > commit there, where is it?
> > 
> > totally confused,
> > 
> > greg k-h
> 
> In 3.10-stable if you took the original CVE-2016-7097 fix it could break
> four file system drivers, the fix for each would 'look like' this one fix
> for the 9p driver.

Did I take the fix in 3.10-stable?  What was the git commit id?  Is 3.10
"broken" in this way?  Is any other stable kernel broken?

I still don't have any idea of what is going on here...

greg k-h

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

[Jason A. Donenfeld]

Hi Hannes,

On Wed, Dec 14, 2016 at 11:03 PM, Hannes Frederic Sowa
 wrote:
> I fear that the alignment requirement will be a source of bugs on 32 bit
> machines, where you cannot even simply take a well aligned struct on a
> stack and put it into the normal siphash(aligned) function without
> adding alignment annotations everywhere. Even blocks returned from
> kmalloc on 32 bit are not aligned to 64 bit.

That's what the "__aligned(SIPHASH24_ALIGNMENT)" attribute is for. The
aligned siphash function will be for structs explicitly made for
siphash consumption. For everything else there's siphash_unaligned.

> Can we do this a runtime check and just have one function (siphash)
> dealing with that?

Seems like the runtime branching on the aligned function would be bad
for performance, when we likely know at compile time if it's going to
be aligned or not. I suppose we could add that check just to the
unaligned version, and rename it to "maybe_unaligned"? Is this what
you have in mind?

Jason

Re: [PATCH v2 1/4] siphash: add cryptographically secure hashtable function

[Jason A. Donenfeld]

Hi Hannes,

On Wed, Dec 14, 2016 at 11:03 PM, Hannes Frederic Sowa
 wrote:
> I fear that the alignment requirement will be a source of bugs on 32 bit
> machines, where you cannot even simply take a well aligned struct on a
> stack and put it into the normal siphash(aligned) function without
> adding alignment annotations everywhere. Even blocks returned from
> kmalloc on 32 bit are not aligned to 64 bit.

That's what the "__aligned(SIPHASH24_ALIGNMENT)" attribute is for. The
aligned siphash function will be for structs explicitly made for
siphash consumption. For everything else there's siphash_unaligned.

> Can we do this a runtime check and just have one function (siphash)
> dealing with that?

Seems like the runtime branching on the aligned function would be bad
for performance, when we likely know at compile time if it's going to
be aligned or not. I suppose we could add that check just to the
unaligned version, and rename it to "maybe_unaligned"? Is this what
you have in mind?

Jason

Re: [PATCH 3/3] hv_netvsc: Implement VF matching based on serial numbers

[Greg KH]

On Wed, Dec 14, 2016 at 11:18:59PM +, Haiyang Zhang wrote:
> 
> 
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Saturday, December 10, 2016 7:21 AM
> > To: Stephen Hemminger 
> > Cc: Haiyang Zhang ; o...@aepfle.de;
> > jasow...@redhat.com; linux-kernel@vger.kernel.org;
> > bjorn.helg...@gmail.com; a...@canonical.com; de...@linuxdriverproject.org;
> > leann.ogasaw...@canonical.com
> > Subject: Re: [PATCH 3/3] hv_netvsc: Implement VF matching based on
> > serial numbers
> > 
> > On Fri, Dec 09, 2016 at 04:21:48PM -0800, Stephen Hemminger wrote:
> > > On Fri, 9 Dec 2016 22:35:05 +
> > > Haiyang Zhang  wrote:
> > >
> > > > > > >
> > > > > > > Emulated NIC is already excluded in start of netvc notifier
> > handler.
> > > > > > >
> > > > > > > static int netvsc_netdev_event(struct notifier_block *this,
> > > > > > >  unsigned long event, void *ptr)
> > > > > > > {
> > > > > > >   struct net_device *event_dev =
> > netdev_notifier_info_to_dev(ptr);
> > > > > > >
> > > > > > >   /* Skip our own events */
> > > > > > >   if (event_dev->netdev_ops == _ops)
> > > > > > >   return NOTIFY_DONE;
> > > > > > >
> > > > > >
> > > > > > Emulated device is not based on netvsc. It's the native Linux
> > > > > (dec100M?)
> > > > > > Driver. So this line doesn't exclude it. And how about other NIC
> > type
> > > > > > may be added in the future?
> > > > >
> > > > > Sorry, forgot about that haven't used emulated device in years.
> > > > > The emulated device should appear to be on a PCI bus, but the
> > serial
> > > > > would not match??
> > > >
> > > > It's not a vmbus device, not a hv_pci device either. Hv_PCI is a
> > subset
> > > > of vmbus devices. So emulated NIC won't have hv_pci serial number.
> > > >
> > > > In my patch, the following code ensure, we only try to get serial
> > number
> > > > after confirming it's vmbus and hv_pci device:
> > > >
> > > > +   if (!dev_is_vmbus(dev))
> > > > +   continue;
> > > > +
> > > > +   hdev = device_to_hv_device(dev);
> > > > +   if (hdev->device_id != HV_PCIE)
> > > > +   continue;
> > >
> > > Ok, the walk back up the device tree is logically ok, but I don't
> > > know enough about PCI device tree to be assured that it is safe.
> > > Also, you could short circuit away most of the unwanted devices
> > > by making sure the vf_netdev->dev.parent is a PCI device.
> > 
> > Ugh, this seems really really messy.  Can't we just have the
> > netdev_event interface pass back a pointer to something that we "know"
> > what it is?  This walking the device tree is a mess, and not good.
> > 
> > I'd even argue that dev_is_pci() needs to be removed from the tree too,
> > as it shouldn't be needed either.  We did a lot of work on the driver
> > model to prevent the need for having to declare the "type" of 'struct
> > device' at all, and by doing this type of thing it goes against the
> > basic design of the model.
> > 
> > Yes, it makes things a bit "tougher" in places, but you don't do crazy
> > things like walk device trees to try to find random devices and then
> > think it's safe to actually use them :(
> > 
> 
> We register a notifier_block with:
>   register_netdevice_notifier(struct notifier_block *nb)
> 
> The "struct notifier_block" basically contains a callback function:
> struct notifier_block {
> notifier_fn_t notifier_call;
> struct notifier_block __rcu *next;
> int priority;
> };
> 
> It doesn't specify which device we want, so all net devices can trigger
> this event. Seems we can't have this notifier return VF device only.

Ok, I dug in the kernel and it looks like people check the netdev_ops
structure to see if it matches up with their function pointers to "know"
if this is their device or not.  Why not do that here?  Or compare the
"string" of the driver name?  Or any other such trick that the drivers
that call register_netdevice_notifier do?

All of which are more sane than walking the device tree...

And why am I having to do network driver development, ick ick ick :)

Come on, 'git grep' is your friend.  Even better yet, use a good tool
like 'vgrep' which makes git grep work really really well.

thanks,

greg k-h

Re: [PATCH 3/3] hv_netvsc: Implement VF matching based on serial numbers

[Greg KH]

On Wed, Dec 14, 2016 at 11:18:59PM +, Haiyang Zhang wrote:
> 
> 
> > -Original Message-
> > From: Greg KH [mailto:gre...@linuxfoundation.org]
> > Sent: Saturday, December 10, 2016 7:21 AM
> > To: Stephen Hemminger 
> > Cc: Haiyang Zhang ; o...@aepfle.de;
> > jasow...@redhat.com; linux-kernel@vger.kernel.org;
> > bjorn.helg...@gmail.com; a...@canonical.com; de...@linuxdriverproject.org;
> > leann.ogasaw...@canonical.com
> > Subject: Re: [PATCH 3/3] hv_netvsc: Implement VF matching based on
> > serial numbers
> > 
> > On Fri, Dec 09, 2016 at 04:21:48PM -0800, Stephen Hemminger wrote:
> > > On Fri, 9 Dec 2016 22:35:05 +
> > > Haiyang Zhang  wrote:
> > >
> > > > > > >
> > > > > > > Emulated NIC is already excluded in start of netvc notifier
> > handler.
> > > > > > >
> > > > > > > static int netvsc_netdev_event(struct notifier_block *this,
> > > > > > >  unsigned long event, void *ptr)
> > > > > > > {
> > > > > > >   struct net_device *event_dev =
> > netdev_notifier_info_to_dev(ptr);
> > > > > > >
> > > > > > >   /* Skip our own events */
> > > > > > >   if (event_dev->netdev_ops == _ops)
> > > > > > >   return NOTIFY_DONE;
> > > > > > >
> > > > > >
> > > > > > Emulated device is not based on netvsc. It's the native Linux
> > > > > (dec100M?)
> > > > > > Driver. So this line doesn't exclude it. And how about other NIC
> > type
> > > > > > may be added in the future?
> > > > >
> > > > > Sorry, forgot about that haven't used emulated device in years.
> > > > > The emulated device should appear to be on a PCI bus, but the
> > serial
> > > > > would not match??
> > > >
> > > > It's not a vmbus device, not a hv_pci device either. Hv_PCI is a
> > subset
> > > > of vmbus devices. So emulated NIC won't have hv_pci serial number.
> > > >
> > > > In my patch, the following code ensure, we only try to get serial
> > number
> > > > after confirming it's vmbus and hv_pci device:
> > > >
> > > > +   if (!dev_is_vmbus(dev))
> > > > +   continue;
> > > > +
> > > > +   hdev = device_to_hv_device(dev);
> > > > +   if (hdev->device_id != HV_PCIE)
> > > > +   continue;
> > >
> > > Ok, the walk back up the device tree is logically ok, but I don't
> > > know enough about PCI device tree to be assured that it is safe.
> > > Also, you could short circuit away most of the unwanted devices
> > > by making sure the vf_netdev->dev.parent is a PCI device.
> > 
> > Ugh, this seems really really messy.  Can't we just have the
> > netdev_event interface pass back a pointer to something that we "know"
> > what it is?  This walking the device tree is a mess, and not good.
> > 
> > I'd even argue that dev_is_pci() needs to be removed from the tree too,
> > as it shouldn't be needed either.  We did a lot of work on the driver
> > model to prevent the need for having to declare the "type" of 'struct
> > device' at all, and by doing this type of thing it goes against the
> > basic design of the model.
> > 
> > Yes, it makes things a bit "tougher" in places, but you don't do crazy
> > things like walk device trees to try to find random devices and then
> > think it's safe to actually use them :(
> > 
> 
> We register a notifier_block with:
>   register_netdevice_notifier(struct notifier_block *nb)
> 
> The "struct notifier_block" basically contains a callback function:
> struct notifier_block {
> notifier_fn_t notifier_call;
> struct notifier_block __rcu *next;
> int priority;
> };
> 
> It doesn't specify which device we want, so all net devices can trigger
> this event. Seems we can't have this notifier return VF device only.

Ok, I dug in the kernel and it looks like people check the netdev_ops
structure to see if it matches up with their function pointers to "know"
if this is their device or not.  Why not do that here?  Or compare the
"string" of the driver name?  Or any other such trick that the drivers
that call register_netdevice_notifier do?

All of which are more sane than walking the device tree...

And why am I having to do network driver development, ick ick ick :)

Come on, 'git grep' is your friend.  Even better yet, use a good tool
like 'vgrep' which makes git grep work really really well.

thanks,

greg k-h

linux-next: manual merge of the btrfs-kdave tree with Linus' tree

[Stephen Rothwell]

Hi David,

Today's linux-next merge of the btrfs-kdave tree got a conflict in:

  fs/btrfs/inode.c

between commit:

  70fd76140a6c ("block,fs: use REQ_* flags directly")

from Linus' tree and commit:

  da17066c4047 ("btrfs: pull node/sector/stripe sizes out of root and into 
fs_info")

from the btrfs-kdave tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/btrfs/inode.c
index a4c879671b9d,b2a577cf001f..
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@@ -7935,8 -7941,10 +7941,8 @@@ static int dio_read_error(struct inode 
  
if ((failed_bio->bi_vcnt > 1)
|| (failed_bio->bi_io_vec->bv_len
-   > BTRFS_I(inode)->root->sectorsize))
+   > btrfs_inode_sectorsize(inode)))
 -  read_mode = READ_SYNC | REQ_FAILFAST_DEV;
 -  else
 -  read_mode = READ_SYNC;
 +  read_mode |= REQ_FAILFAST_DEV;
  
isector = start - btrfs_io_bio(failed_bio)->logical;
isector >>= inode->i_sb->s_blocksize_bits;

linux-next: manual merge of the btrfs-kdave tree with Linus' tree

[Stephen Rothwell]

Hi David,

Today's linux-next merge of the btrfs-kdave tree got a conflict in:

  fs/btrfs/inode.c

between commit:

  70fd76140a6c ("block,fs: use REQ_* flags directly")

from Linus' tree and commit:

  da17066c4047 ("btrfs: pull node/sector/stripe sizes out of root and into 
fs_info")

from the btrfs-kdave tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc fs/btrfs/inode.c
index a4c879671b9d,b2a577cf001f..
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@@ -7935,8 -7941,10 +7941,8 @@@ static int dio_read_error(struct inode 
  
if ((failed_bio->bi_vcnt > 1)
|| (failed_bio->bi_io_vec->bv_len
-   > BTRFS_I(inode)->root->sectorsize))
+   > btrfs_inode_sectorsize(inode)))
 -  read_mode = READ_SYNC | REQ_FAILFAST_DEV;
 -  else
 -  read_mode = READ_SYNC;
 +  read_mode |= REQ_FAILFAST_DEV;
  
isector = start - btrfs_io_bio(failed_bio)->logical;
isector >>= inode->i_sb->s_blocksize_bits;

Re: [PATCH] genirq/affinity: fix node generation from cpumask

[Gavin Shan]

On Wed, Dec 14, 2016 at 04:01:12PM -0200, Guilherme G. Piccoli wrote:
>Commit 34c3d9819fda ("genirq/affinity: Provide smarter irq spreading
>infrastructure") introduced a better IRQ spreading mechanism, taking
>account of the available NUMA nodes in the machine.
>
>Problem is that the algorithm of retrieving the nodemask iterates
>"linearly" based on the number of online nodes - some architectures
>present non-linear node distribution among the nodemask, like PowerPC.
>If this is the case, the algorithm lead to a wrong node count number
>and therefore to a bad/incomplete IRQ affinity distribution.
>
>For example, this problem were found in a machine with 128 CPUs and two
>nodes, namely nodes 0 and 8 (instead of 0 and 1, if it was linearly
>distributed). This led to a wrong affinity distribution which then led to
>a bad mq allocation for nvme driver.
>
>Finally, we take the opportunity to fix a comment regarding the affinity
>distribution when we have _more_ nodes than vectors.
>
>Fixes: 34c3d9819fda ("genirq/affinity: Provide smarter irq spreading 
>infrastructure")
>Reported-by: Gabriel Krisman Bertazi 
>Signed-off-by: Guilherme G. Piccoli 
>Cc: sta...@vger.kernel.org # v4.9+
>Cc: Christoph Hellwig 
>Cc: linuxppc-...@lists.ozlabs.org
>Cc: linux-...@vger.kernel.org
>---

Reviewed-by: Gavin Shan 

There is one picky comment as below, but you don't have to fix it :)

> kernel/irq/affinity.c | 8 
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
>index 9be9bda..464eaf0 100644
>--- a/kernel/irq/affinity.c
>+++ b/kernel/irq/affinity.c
>@@ -37,15 +37,15 @@ static void irq_spread_init_one(struct cpumask *irqmsk, 
>struct cpumask *nmsk,
>
> static int get_nodes_in_cpumask(const struct cpumask *mask, nodemask_t 
> *nodemsk)
> {
>-  int n, nodes;
>+  int n, nodes = 0;
>
>   /* Calculate the number of nodes in the supplied affinity mask */
>-  for (n = 0, nodes = 0; n < num_online_nodes(); n++) {
>+  for_each_online_node(n)
>   if (cpumask_intersects(mask, cpumask_of_node(n))) {
>   node_set(n, *nodemsk);
>   nodes++;
>   }
>-  }
>+

It'd better to keep the brackets so that we needn't add them when adding
more code into the block next time.

>   return nodes;
> }
>
>@@ -82,7 +82,7 @@ irq_create_affinity_masks(int nvecs, const struct 
>irq_affinity *affd)
>   nodes = get_nodes_in_cpumask(cpu_online_mask, );
>
>   /*
>-   * If the number of nodes in the mask is less than or equal the
>+   * If the number of nodes in the mask is greater than or equal the
>* number of vectors we just spread the vectors across the nodes.
>*/
>   if (affv <= nodes) {

Thanks,
Gavin

Re: [PATCH] genirq/affinity: fix node generation from cpumask

[Gavin Shan]

On Wed, Dec 14, 2016 at 04:01:12PM -0200, Guilherme G. Piccoli wrote:
>Commit 34c3d9819fda ("genirq/affinity: Provide smarter irq spreading
>infrastructure") introduced a better IRQ spreading mechanism, taking
>account of the available NUMA nodes in the machine.
>
>Problem is that the algorithm of retrieving the nodemask iterates
>"linearly" based on the number of online nodes - some architectures
>present non-linear node distribution among the nodemask, like PowerPC.
>If this is the case, the algorithm lead to a wrong node count number
>and therefore to a bad/incomplete IRQ affinity distribution.
>
>For example, this problem were found in a machine with 128 CPUs and two
>nodes, namely nodes 0 and 8 (instead of 0 and 1, if it was linearly
>distributed). This led to a wrong affinity distribution which then led to
>a bad mq allocation for nvme driver.
>
>Finally, we take the opportunity to fix a comment regarding the affinity
>distribution when we have _more_ nodes than vectors.
>
>Fixes: 34c3d9819fda ("genirq/affinity: Provide smarter irq spreading 
>infrastructure")
>Reported-by: Gabriel Krisman Bertazi 
>Signed-off-by: Guilherme G. Piccoli 
>Cc: sta...@vger.kernel.org # v4.9+
>Cc: Christoph Hellwig 
>Cc: linuxppc-...@lists.ozlabs.org
>Cc: linux-...@vger.kernel.org
>---

Reviewed-by: Gavin Shan 

There is one picky comment as below, but you don't have to fix it :)

> kernel/irq/affinity.c | 8 
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
>diff --git a/kernel/irq/affinity.c b/kernel/irq/affinity.c
>index 9be9bda..464eaf0 100644
>--- a/kernel/irq/affinity.c
>+++ b/kernel/irq/affinity.c
>@@ -37,15 +37,15 @@ static void irq_spread_init_one(struct cpumask *irqmsk, 
>struct cpumask *nmsk,
>
> static int get_nodes_in_cpumask(const struct cpumask *mask, nodemask_t 
> *nodemsk)
> {
>-  int n, nodes;
>+  int n, nodes = 0;
>
>   /* Calculate the number of nodes in the supplied affinity mask */
>-  for (n = 0, nodes = 0; n < num_online_nodes(); n++) {
>+  for_each_online_node(n)
>   if (cpumask_intersects(mask, cpumask_of_node(n))) {
>   node_set(n, *nodemsk);
>   nodes++;
>   }
>-  }
>+

It'd better to keep the brackets so that we needn't add them when adding
more code into the block next time.

>   return nodes;
> }
>
>@@ -82,7 +82,7 @@ irq_create_affinity_masks(int nvecs, const struct 
>irq_affinity *affd)
>   nodes = get_nodes_in_cpumask(cpu_online_mask, );
>
>   /*
>-   * If the number of nodes in the mask is less than or equal the
>+   * If the number of nodes in the mask is greater than or equal the
>* number of vectors we just spread the vectors across the nodes.
>*/
>   if (affv <= nodes) {

Thanks,
Gavin

Re: page allocation stall in kernel 4.9 when copying files from one btrfs hdd to another

[Xin Zhou]

Hi,

The dirty data is in large amount, probably unable to commit to disk.
And this seems to happen when copying from 7200rpm to 5600rpm disks, according 
to previous post.

Probably the I/Os are buffered and pending, unable to get finished in-time.
It might be helpful to know if this only happens for specific types of 5600 rpm 
disks?

And are these disks on RAID groups? Thanks.
Xin
 
 

Sent: Wednesday, December 14, 2016 at 3:38 AM
From: admin 
To: "Michal Hocko" 
Cc: linux-bt...@vger.kernel.org, linux-kernel@vger.kernel.org, "David Sterba" 
, "Chris Mason" 
Subject: Re: page allocation stall in kernel 4.9 when copying files from one 
btrfs hdd to another
Hi,

I verified the log files and see no prior oom killer invocation. Unfortunately 
the machine has been rebooted since. Next time it happens, I will also look in 
dmesg.

Thanks,
David Arendt


Michal Hocko – Wed., 14. December 2016 11:31
> Btw. the stall should be preceded by the OOM killer invocation. Could
> you share the OOM report please. I am asking because such an OOM killer
> would be clearly pre-mature as per your meminfo. I am trying to change
> that code and seeing your numbers might help me.
>
> Thanks!
>
> On Wed 14-12-16 11:17:43, Michal Hocko wrote:
> > On Tue 13-12-16 18:11:01, David Arendt wrote:
> > > Hi,
> > >
> > > I receive the following page allocation stall while copying lots of
> > > large files from one btrfs hdd to another.
> > >
> > > Dec 13 13:04:29 server kernel: kworker/u16:8: page allocation stalls for 
> > > 12260ms, order:0, mode:0x2400840(GFP_NOFS|__GFP_NOFAIL)
> > > Dec 13 13:04:29 server kernel: CPU: 0 PID: 24959 Comm: kworker/u16:8 
> > > Tainted: P O 4.9.0 #1
> > [...]
> > > Dec 13 13:04:29 server kernel: Call Trace:
> > > Dec 13 13:04:29 server kernel: [] ? dump_stack+0x46/0x5d
> > > Dec 13 13:04:29 server kernel: [] ? 
> > > warn_alloc+0x111/0x130
> > > Dec 13 13:04:33 server kernel: [] ? 
> > > __alloc_pages_nodemask+0xbe8/0xd30
> > > Dec 13 13:04:33 server kernel: [] ? 
> > > pagecache_get_page+0xe4/0x230
> > > Dec 13 13:04:33 server kernel: [] ? 
> > > alloc_extent_buffer+0x10b/0x400
> > > Dec 13 13:04:33 server kernel: [] ? 
> > > btrfs_alloc_tree_block+0x125/0x560
> >
> > OK, so this is
> > find_or_create_page(mapping, index, GFP_NOFS|__GFP_NOFAIL)
> >
> > The main question is whether this really needs to be NOFS request...
> >
> > > Dec 13 13:04:33 server kernel: [] ? 
> > > read_extent_buffer_pages+0x21f/0x280
> > > Dec 13 13:04:33 server kernel: [] ? 
> > > __btrfs_cow_block+0x141/0x580
> > > Dec 13 13:04:33 server kernel: [] ? 
> > > btrfs_cow_block+0x100/0x150
> > > Dec 13 13:04:33 server kernel: [] ? 
> > > btrfs_search_slot+0x1e9/0x9c0
> > > Dec 13 13:04:33 server kernel: [] ? 
> > > __set_extent_bit+0x512/0x550
> > > Dec 13 13:04:33 server kernel: [] ? 
> > > lookup_inline_extent_backref+0xf5/0x5e0
> > > Dec 13 13:04:34 server kernel: [] ? 
> > > set_extent_bit+0x24/0x30
> > > Dec 13 13:04:34 server kernel: [] ? 
> > > update_block_group.isra.34+0x114/0x380
> > > Dec 13 13:04:34 server kernel: [] ? 
> > > __btrfs_free_extent.isra.35+0xf4/0xd20
> > > Dec 13 13:04:34 server kernel: [] ? 
> > > btrfs_merge_delayed_refs+0x61/0x5d0
> > > Dec 13 13:04:34 server kernel: [] ? 
> > > __btrfs_run_delayed_refs+0x902/0x10a0
> > > Dec 13 13:04:34 server kernel: [] ? 
> > > btrfs_run_delayed_refs+0x90/0x2a0
> > > Dec 13 13:04:34 server kernel: [] ? 
> > > delayed_ref_async_start+0x84/0xa0
> >
> > What would cause the reclaim recursion?
> >
> > > Dec 13 13:04:34 server kernel: Mem-Info:
> > > Dec 13 13:04:34 server kernel: active_anon:20 inactive_anon:34
> > > isolated_anon:0\x0a active_file:7370032 inactive_file:450105
> > > isolated_file:320\x0a unevictable:0 dirty:522748 writeback:189
> > > unstable:0\x0a slab_reclaimable:178255 slab_unreclaimable:124617\x0a
> > > mapped:4236 shmem:0 pagetables:1163 bounce:0\x0a free:38224 free_pcp:241
> > > free_cma:0
> >
> > This speaks for itself. There is a lot of dirty data, basically no
> > anonymous memory and GFP_NOFS cannot do much to reclaim obviously. This
> > is either a configuraion bug as somebody noted down the thread (setting
> > the dirty_ratio) or suboptimality of the btrfs code which might request
> > NOFS even though it is not strictly necessary. This would be more for
> > btrfs developers.
> > --
> > Michal Hocko
> > SUSE Labs
>
> --
> Michal Hocko
> SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: page allocation stall in kernel 4.9 when copying files from one btrfs hdd to another

[Xin Zhou]

Hi,

The dirty data is in large amount, probably unable to commit to disk.
And this seems to happen when copying from 7200rpm to 5600rpm disks, according 
to previous post.

Probably the I/Os are buffered and pending, unable to get finished in-time.
It might be helpful to know if this only happens for specific types of 5600 rpm 
disks?

And are these disks on RAID groups? Thanks.
Xin
 
 

Sent: Wednesday, December 14, 2016 at 3:38 AM
From: admin 
To: "Michal Hocko" 
Cc: linux-bt...@vger.kernel.org, linux-kernel@vger.kernel.org, "David Sterba" 
, "Chris Mason" 
Subject: Re: page allocation stall in kernel 4.9 when copying files from one 
btrfs hdd to another
Hi,

I verified the log files and see no prior oom killer invocation. Unfortunately 
the machine has been rebooted since. Next time it happens, I will also look in 
dmesg.

Thanks,
David Arendt


Michal Hocko – Wed., 14. December 2016 11:31
> Btw. the stall should be preceded by the OOM killer invocation. Could
> you share the OOM report please. I am asking because such an OOM killer
> would be clearly pre-mature as per your meminfo. I am trying to change
> that code and seeing your numbers might help me.
>
> Thanks!
>
> On Wed 14-12-16 11:17:43, Michal Hocko wrote:
> > On Tue 13-12-16 18:11:01, David Arendt wrote:
> > > Hi,
> > >
> > > I receive the following page allocation stall while copying lots of
> > > large files from one btrfs hdd to another.
> > >
> > > Dec 13 13:04:29 server kernel: kworker/u16:8: page allocation stalls for 
> > > 12260ms, order:0, mode:0x2400840(GFP_NOFS|__GFP_NOFAIL)
> > > Dec 13 13:04:29 server kernel: CPU: 0 PID: 24959 Comm: kworker/u16:8 
> > > Tainted: P O 4.9.0 #1
> > [...]
> > > Dec 13 13:04:29 server kernel: Call Trace:
> > > Dec 13 13:04:29 server kernel: [] ? dump_stack+0x46/0x5d
> > > Dec 13 13:04:29 server kernel: [] ? 
> > > warn_alloc+0x111/0x130
> > > Dec 13 13:04:33 server kernel: [] ? 
> > > __alloc_pages_nodemask+0xbe8/0xd30
> > > Dec 13 13:04:33 server kernel: [] ? 
> > > pagecache_get_page+0xe4/0x230
> > > Dec 13 13:04:33 server kernel: [] ? 
> > > alloc_extent_buffer+0x10b/0x400
> > > Dec 13 13:04:33 server kernel: [] ? 
> > > btrfs_alloc_tree_block+0x125/0x560
> >
> > OK, so this is
> > find_or_create_page(mapping, index, GFP_NOFS|__GFP_NOFAIL)
> >
> > The main question is whether this really needs to be NOFS request...
> >
> > > Dec 13 13:04:33 server kernel: [] ? 
> > > read_extent_buffer_pages+0x21f/0x280
> > > Dec 13 13:04:33 server kernel: [] ? 
> > > __btrfs_cow_block+0x141/0x580
> > > Dec 13 13:04:33 server kernel: [] ? 
> > > btrfs_cow_block+0x100/0x150
> > > Dec 13 13:04:33 server kernel: [] ? 
> > > btrfs_search_slot+0x1e9/0x9c0
> > > Dec 13 13:04:33 server kernel: [] ? 
> > > __set_extent_bit+0x512/0x550
> > > Dec 13 13:04:33 server kernel: [] ? 
> > > lookup_inline_extent_backref+0xf5/0x5e0
> > > Dec 13 13:04:34 server kernel: [] ? 
> > > set_extent_bit+0x24/0x30
> > > Dec 13 13:04:34 server kernel: [] ? 
> > > update_block_group.isra.34+0x114/0x380
> > > Dec 13 13:04:34 server kernel: [] ? 
> > > __btrfs_free_extent.isra.35+0xf4/0xd20
> > > Dec 13 13:04:34 server kernel: [] ? 
> > > btrfs_merge_delayed_refs+0x61/0x5d0
> > > Dec 13 13:04:34 server kernel: [] ? 
> > > __btrfs_run_delayed_refs+0x902/0x10a0
> > > Dec 13 13:04:34 server kernel: [] ? 
> > > btrfs_run_delayed_refs+0x90/0x2a0
> > > Dec 13 13:04:34 server kernel: [] ? 
> > > delayed_ref_async_start+0x84/0xa0
> >
> > What would cause the reclaim recursion?
> >
> > > Dec 13 13:04:34 server kernel: Mem-Info:
> > > Dec 13 13:04:34 server kernel: active_anon:20 inactive_anon:34
> > > isolated_anon:0\x0a active_file:7370032 inactive_file:450105
> > > isolated_file:320\x0a unevictable:0 dirty:522748 writeback:189
> > > unstable:0\x0a slab_reclaimable:178255 slab_unreclaimable:124617\x0a
> > > mapped:4236 shmem:0 pagetables:1163 bounce:0\x0a free:38224 free_pcp:241
> > > free_cma:0
> >
> > This speaks for itself. There is a lot of dirty data, basically no
> > anonymous memory and GFP_NOFS cannot do much to reclaim obviously. This
> > is either a configuraion bug as somebody noted down the thread (setting
> > the dirty_ratio) or suboptimality of the btrfs code which might request
> > NOFS even though it is not strictly necessary. This would be more for
> > btrfs developers.
> > --
> > Michal Hocko
> > SUSE Labs
>
> --
> Michal Hocko
> SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

[Jason A. Donenfeld]

Hey Tom,

On Thu, Dec 15, 2016 at 12:14 AM, Tom Herbert  wrote:
> I'm confused, doesn't 2dword == 1qword? Anyway, I think the qword
> functions are good enough. If someone needs to hash over some odd
> length they can either put them in a structure padded to 64 bits or
> call the hash function that takes a byte length.

Yes. Here's an example:

static inline u64 siphash24_2dwords(const u32 a, const u32 b, const u8
key[SIPHASH24_KEY_LEN])
{
   return siphash24_1qword(((u64)b << 32) | a, key);
}

This winds up being extremely useful and syntactically convenient in a
few places. Check out my git branch in about 10 minutes or wait for v4
to be posted tomorrow; these are nice helpers.

> I'd still drop the "24" unless you really think we're going to have
> multiple variants coming into the kernel.

Okay. I don't have a problem with this, unless anybody has some reason
to the contrary.

Jason

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

[Jason A. Donenfeld]

Hey Tom,

On Thu, Dec 15, 2016 at 12:14 AM, Tom Herbert  wrote:
> I'm confused, doesn't 2dword == 1qword? Anyway, I think the qword
> functions are good enough. If someone needs to hash over some odd
> length they can either put them in a structure padded to 64 bits or
> call the hash function that takes a byte length.

Yes. Here's an example:

static inline u64 siphash24_2dwords(const u32 a, const u32 b, const u8
key[SIPHASH24_KEY_LEN])
{
   return siphash24_1qword(((u64)b << 32) | a, key);
}

This winds up being extremely useful and syntactically convenient in a
few places. Check out my git branch in about 10 minutes or wait for v4
to be posted tomorrow; these are nice helpers.

> I'd still drop the "24" unless you really think we're going to have
> multiple variants coming into the kernel.

Okay. I don't have a problem with this, unless anybody has some reason
to the contrary.

Jason

Re: [kernel-hardening] [RFC 0/4] make call_usermodehelper a bit more "safe"

[Greg Kroah-Hartman]

On Wed, Dec 14, 2016 at 10:28:18PM +0100, Jason A. Donenfeld wrote:
> Hi Greg,
> 
> On Wed, Dec 14, 2016 at 7:50 PM, Greg KH  wrote:
> > So, anyone have any better ideas?  Is this approach worth it?  Or should
> > we just go down the "whitelist" path?
> 
> I think your approach is generally better than the whitelist path. But
> maybe there's yet a third approach that involves futzing with page
> permissions at runtime. I think grsec does something similar with
> read_mostly function pointer structs. Namely, they make them read-only
> const, and then temporarily twiddle the page permissions if it needs
> to be changed while disabling preemption. There could be a particular
> class of data that needs to be "opened" and "closed" in order to
> modify. Seems like these strings would be a good use of that.

Yes, but that's a much larger issue and if that feature ever lands, we
can switch these strings over to that functionality.

thanks,

greg k-h

Re: [kernel-hardening] [RFC 0/4] make call_usermodehelper a bit more "safe"

[Greg Kroah-Hartman]

On Wed, Dec 14, 2016 at 10:28:18PM +0100, Jason A. Donenfeld wrote:
> Hi Greg,
> 
> On Wed, Dec 14, 2016 at 7:50 PM, Greg KH  wrote:
> > So, anyone have any better ideas?  Is this approach worth it?  Or should
> > we just go down the "whitelist" path?
> 
> I think your approach is generally better than the whitelist path. But
> maybe there's yet a third approach that involves futzing with page
> permissions at runtime. I think grsec does something similar with
> read_mostly function pointer structs. Namely, they make them read-only
> const, and then temporarily twiddle the page permissions if it needs
> to be changed while disabling preemption. There could be a particular
> class of data that needs to be "opened" and "closed" in order to
> modify. Seems like these strings would be a good use of that.

Yes, but that's a much larger issue and if that feature ever lands, we
can switch these strings over to that functionality.

thanks,

greg k-h

Re: [PATCH] Add +~800M crashkernel explaination

[Xunlei Pang]

On 12/15/2016 at 01:50 AM, Robert LeBlanc wrote:
> On Tue, Dec 13, 2016 at 8:08 PM, Xunlei Pang  wrote:
>> On 12/10/2016 at 01:20 PM, Robert LeBlanc wrote:
>>> On Fri, Dec 9, 2016 at 7:49 PM, Baoquan He  wrote:
 On 12/09/16 at 05:22pm, Robert LeBlanc wrote:
> When trying to configure crashkernel greater than about 800 MB, the
> kernel fails to allocate memory on x86 and x86_64. This is due to an
> undocumented limit that the crashkernel and other low memory items must
> be allocated below 896 MB unless the ",high" option is given. This
> updates the documentation to explain this and what I understand the
> limitations to be on the option.
 This is true, but not very accurate. You found it's about 800M, it's
 becasue usually the current kernel need about 40M space to run, and some
 extra reservation before reserve_crashkernel invocation, another ~10M.
 However it's normal case, people may build modules into or have some
 special code to bloat kernel. This patch makes sense to address the
 low|high issue, it might be not good so determined to say ~800M.
>>> My testing showed that I could go anywhere from about 830M to 880M,
>>> depending on distro, kernel version, and stuff that you mentioned. I
>>> just thought some rule of thumb of when to consider using high would
>>> be good. People may not think that 800 MB is 'large' when you have 512
>>> GB of RAM for instance. I thought about making 512 MB be the rule of
>>> thumb, but you can do a lot with ~300 MB.
>> Hi Robert,
>>
>> I think you are correct.
>>
>> For x86, the kernel uses memblock to locate the proper range starts from 
>> 16MB to some "end",
>> without "high" prefix, "end" is CRASH_ADDR_LOW_MAX, otherwise 
>> CRASH_ADDR_HIGH_MAX.
>>
>> You can find the definition for both 32-bit and 64-bit:
>> #ifdef CONFIG_X86_32
>> # define CRASH_ADDR_LOW_MAX (512 << 20)
>> # define CRASH_ADDR_HIGH_MAX(512 << 20)
>> #else
>> # define CRASH_ADDR_LOW_MAX (896UL << 20)
>> # define CRASH_ADDR_HIGH_MAXMAXMEM
>> #endif
>>
>> as some memory was already allocated by the kernel, which means it's highly 
>> likely to get a reservation
>> failure after specifying a crashkernel value near 800MB(for x86_64) which 
>> was what you met. But we can't
>> get the exact threshold, but it would be better if there is some explanation 
>> accordingly in the document.
> To make sure I'm understanding what you are say, you want me to go
> into a bit more detail about the limitation and specify the
> differences between x86 and x86_64, right?

Yeah, it would be better to have one, at least to mention the different upper 
bounds.

As I replied in another post, if you really want to detail the behaviour, 
should mention
"crashkernel=size[KMG][@offset[KMG]]" with @offset[KMG] specified explicitly, 
after
all, it's handled differently with no upper bound limitation, but doing this 
may put
the first kernel at the risk of lacking low memory(some devices require 32bit 
DMA),
must use it with care because the kernel will assume users are aware of what 
they
are doing and make a successful reservation as long as the given range is 
available.

>
>>> I'm happy to adjust the wording, what would you recommend? Also, I'm
>>> not 100% sure that I got the cases covered correctly. I was surprised
>>> that I could not get it to work with the "new" format with the
>>> multiple ranges, and that specifying an offset would't work either,
>>> although the offset kind of makes sense. Do you know for sure that it
>>> doesn't work with ranges?
>>>
>>> I tried,
>>>
>>> crashkernel=256M-1G:128M,high,1G-4G:256M,high,4G-:512M,high
>>>
>>> and
>>>
>>> crashkernel=256M-1G:128M,1G-4G:256M,4G-:512M,high
>>>
>>> and neither worked. It seems that a better separator would be ';'
>>> instead of ',' for ranges, then you could specify options better. Kind
>>> of hard to change now.
>> For "crashkernel=range1:size1[,range2:size2,...][@offset]"
>> I'm afraid it doesn't support "high" prefix in the current implementation, 
>> so there is no guarantee.
>> I guess we can drop a note to eliminate the confusion.
> I tried to express in the extended syntax section that ',high' is not
> available and you have to use the 'simple' format. Do you think this

ditto

> needs to be expanded as well?

If you really have good reasons or use cases, please try it :-)

Regards,
Xunlei

>
>
> 
> Robert LeBlanc
> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904  C70E E654 3BB2 FA62 B9F1
>
> Signed-off-by: Robert LeBlanc 
> ---
>  Documentation/kdump/kdump.txt | 22 +-
>  1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> index b0eb27b..aa3efa8 100644
> --- a/Documentation/kdump/kdump.txt
> +++ b/Documentation/kdump/kdump.txt
> @@ -256,7 +256,9 @@ While the "crashkernel=size[@offset]" 

Re: [PATCH] Add +~800M crashkernel explaination

[Xunlei Pang]

On 12/15/2016 at 01:50 AM, Robert LeBlanc wrote:
> On Tue, Dec 13, 2016 at 8:08 PM, Xunlei Pang  wrote:
>> On 12/10/2016 at 01:20 PM, Robert LeBlanc wrote:
>>> On Fri, Dec 9, 2016 at 7:49 PM, Baoquan He  wrote:
 On 12/09/16 at 05:22pm, Robert LeBlanc wrote:
> When trying to configure crashkernel greater than about 800 MB, the
> kernel fails to allocate memory on x86 and x86_64. This is due to an
> undocumented limit that the crashkernel and other low memory items must
> be allocated below 896 MB unless the ",high" option is given. This
> updates the documentation to explain this and what I understand the
> limitations to be on the option.
 This is true, but not very accurate. You found it's about 800M, it's
 becasue usually the current kernel need about 40M space to run, and some
 extra reservation before reserve_crashkernel invocation, another ~10M.
 However it's normal case, people may build modules into or have some
 special code to bloat kernel. This patch makes sense to address the
 low|high issue, it might be not good so determined to say ~800M.
>>> My testing showed that I could go anywhere from about 830M to 880M,
>>> depending on distro, kernel version, and stuff that you mentioned. I
>>> just thought some rule of thumb of when to consider using high would
>>> be good. People may not think that 800 MB is 'large' when you have 512
>>> GB of RAM for instance. I thought about making 512 MB be the rule of
>>> thumb, but you can do a lot with ~300 MB.
>> Hi Robert,
>>
>> I think you are correct.
>>
>> For x86, the kernel uses memblock to locate the proper range starts from 
>> 16MB to some "end",
>> without "high" prefix, "end" is CRASH_ADDR_LOW_MAX, otherwise 
>> CRASH_ADDR_HIGH_MAX.
>>
>> You can find the definition for both 32-bit and 64-bit:
>> #ifdef CONFIG_X86_32
>> # define CRASH_ADDR_LOW_MAX (512 << 20)
>> # define CRASH_ADDR_HIGH_MAX(512 << 20)
>> #else
>> # define CRASH_ADDR_LOW_MAX (896UL << 20)
>> # define CRASH_ADDR_HIGH_MAXMAXMEM
>> #endif
>>
>> as some memory was already allocated by the kernel, which means it's highly 
>> likely to get a reservation
>> failure after specifying a crashkernel value near 800MB(for x86_64) which 
>> was what you met. But we can't
>> get the exact threshold, but it would be better if there is some explanation 
>> accordingly in the document.
> To make sure I'm understanding what you are say, you want me to go
> into a bit more detail about the limitation and specify the
> differences between x86 and x86_64, right?

Yeah, it would be better to have one, at least to mention the different upper 
bounds.

As I replied in another post, if you really want to detail the behaviour, 
should mention
"crashkernel=size[KMG][@offset[KMG]]" with @offset[KMG] specified explicitly, 
after
all, it's handled differently with no upper bound limitation, but doing this 
may put
the first kernel at the risk of lacking low memory(some devices require 32bit 
DMA),
must use it with care because the kernel will assume users are aware of what 
they
are doing and make a successful reservation as long as the given range is 
available.

>
>>> I'm happy to adjust the wording, what would you recommend? Also, I'm
>>> not 100% sure that I got the cases covered correctly. I was surprised
>>> that I could not get it to work with the "new" format with the
>>> multiple ranges, and that specifying an offset would't work either,
>>> although the offset kind of makes sense. Do you know for sure that it
>>> doesn't work with ranges?
>>>
>>> I tried,
>>>
>>> crashkernel=256M-1G:128M,high,1G-4G:256M,high,4G-:512M,high
>>>
>>> and
>>>
>>> crashkernel=256M-1G:128M,1G-4G:256M,4G-:512M,high
>>>
>>> and neither worked. It seems that a better separator would be ';'
>>> instead of ',' for ranges, then you could specify options better. Kind
>>> of hard to change now.
>> For "crashkernel=range1:size1[,range2:size2,...][@offset]"
>> I'm afraid it doesn't support "high" prefix in the current implementation, 
>> so there is no guarantee.
>> I guess we can drop a note to eliminate the confusion.
> I tried to express in the extended syntax section that ',high' is not
> available and you have to use the 'simple' format. Do you think this

ditto

> needs to be expanded as well?

If you really have good reasons or use cases, please try it :-)

Regards,
Xunlei

>
>
> 
> Robert LeBlanc
> PGP Fingerprint 79A2 9CA4 6CC4 45DD A904  C70E E654 3BB2 FA62 B9F1
>
> Signed-off-by: Robert LeBlanc 
> ---
>  Documentation/kdump/kdump.txt | 22 +-
>  1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt
> index b0eb27b..aa3efa8 100644
> --- a/Documentation/kdump/kdump.txt
> +++ b/Documentation/kdump/kdump.txt
> @@ -256,7 +256,9 @@ While the "crashkernel=size[@offset]" syntax is 
> sufficient for most
>  configurations, 

[PATCH 1/6] of: documentation: add bindings documentation for TS-4600

[Sebastien Bourdelin]

This adds the documentation for the TS-4600 by Technologic Systems.

Signed-off-by: Sebastien Bourdelin 
---
 Documentation/devicetree/bindings/arm/technologic.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/technologic.txt 
b/Documentation/devicetree/bindings/arm/technologic.txt
index 33797ac..e9d6d65 100644
--- a/Documentation/devicetree/bindings/arm/technologic.txt
+++ b/Documentation/devicetree/bindings/arm/technologic.txt
@@ -1,6 +1,11 @@
 Technologic Systems Platforms Device Tree Bindings
 --
 
+TS-4600 is a System-on-Module based on the Freescale i.MX28 System-on-Chip.
+It can be mounted on a carrier board providing additional peripheral 
connectors.
+Required root node properties:
+   - compatible = "technologic,imx28-ts4600", "fsl,imx28"
+
 TS-4800 board
 Required root node properties:
- compatible = "technologic,imx51-ts4800", "fsl,imx51";
-- 
2.10.2

[PATCH 1/6] of: documentation: add bindings documentation for TS-4600

[Sebastien Bourdelin]

This adds the documentation for the TS-4600 by Technologic Systems.

Signed-off-by: Sebastien Bourdelin 
---
 Documentation/devicetree/bindings/arm/technologic.txt | 5 +
 1 file changed, 5 insertions(+)

diff --git a/Documentation/devicetree/bindings/arm/technologic.txt 
b/Documentation/devicetree/bindings/arm/technologic.txt
index 33797ac..e9d6d65 100644
--- a/Documentation/devicetree/bindings/arm/technologic.txt
+++ b/Documentation/devicetree/bindings/arm/technologic.txt
@@ -1,6 +1,11 @@
 Technologic Systems Platforms Device Tree Bindings
 --
 
+TS-4600 is a System-on-Module based on the Freescale i.MX28 System-on-Chip.
+It can be mounted on a carrier board providing additional peripheral 
connectors.
+Required root node properties:
+   - compatible = "technologic,imx28-ts4600", "fsl,imx28"
+
 TS-4800 board
 Required root node properties:
- compatible = "technologic,imx51-ts4800", "fsl,imx51";
-- 
2.10.2

[PATCH 4/6] bus: add driver for the Technologic Systems NBUS

[Sebastien Bourdelin]

This driver implements a GPIOs bit-banged bus, called the NBUS by
Technologic Systems. It is used to communicate with the peripherals in
the FPGA on the TS-4600 SoM.

Signed-off-by: Sebastien Bourdelin 
---
 drivers/bus/Kconfig |   9 +
 drivers/bus/Makefile|   1 +
 drivers/bus/ts-nbus.c   | 451 
 include/linux/ts-nbus.h |  17 ++
 4 files changed, 478 insertions(+)
 create mode 100644 drivers/bus/ts-nbus.c
 create mode 100644 include/linux/ts-nbus.h

diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 7875105..74e72b3 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -150,6 +150,15 @@ config TEGRA_ACONNECT
  Driver for the Tegra ACONNECT bus which is used to interface with
  the devices inside the Audio Processing Engine (APE) for Tegra210.
 
+config TS_NBUS
+   tristate "Technologic Systems NBUS Driver"
+   default y
+   depends on SOC_IMX28
+   depends on OF_GPIO && PWM
+   help
+ Driver for the Technologic Systems NBUS which is used to interface
+ with the peripherals in the FPGA of the TS-4600 SoM.
+
 config UNIPHIER_SYSTEM_BUS
tristate "UniPhier System Bus driver"
depends on ARCH_UNIPHIER && OF
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index c6cfa6b..83f874a 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -19,5 +19,6 @@ obj-$(CONFIG_QCOM_EBI2)   += qcom-ebi2.o
 obj-$(CONFIG_SUNXI_RSB)+= sunxi-rsb.o
 obj-$(CONFIG_SIMPLE_PM_BUS)+= simple-pm-bus.o
 obj-$(CONFIG_TEGRA_ACONNECT)   += tegra-aconnect.o
+obj-$(CONFIG_TS_NBUS)  += ts-nbus.o
 obj-$(CONFIG_UNIPHIER_SYSTEM_BUS)  += uniphier-system-bus.o
 obj-$(CONFIG_VEXPRESS_CONFIG)  += vexpress-config.o
diff --git a/drivers/bus/ts-nbus.c b/drivers/bus/ts-nbus.c
new file mode 100644
index 000..44fc89d
--- /dev/null
+++ b/drivers/bus/ts-nbus.c
@@ -0,0 +1,451 @@
+/*
+ * NBUS driver for TS-4600 based boards
+ *
+ * Copyright (c) 2016 - Savoir-faire Linux
+ * Author: Sebastien Bourdelin 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * This driver implements a GPIOs bit-banged bus, called the NBUS by 
Technologic
+ * Systems. It is used to communicate with the peripherals in the FPGA on the
+ * TS-4600 SoM.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static DEFINE_MUTEX(ts_nbus_lock);
+static bool ts_nbus_ready;
+
+#define TS_NBUS_READ_MODE  0
+#define TS_NBUS_WRITE_MODE 1
+#define TS_NBUS_DIRECTION_IN  0
+#define TS_NBUS_DIRECTION_OUT 1
+#define TS_NBUS_WRITE_ADR 0
+#define TS_NBUS_WRITE_VAL 1
+
+struct ts_nbus {
+   struct pwm_device *pwm;
+   int num_data;
+   int *data;
+   int csn;
+   int txrx;
+   int strobe;
+   int ale;
+   int rdy;
+};
+
+static struct ts_nbus *ts_nbus;
+
+/*
+ * request all gpios required by the bus.
+ */
+static int ts_nbus_init(struct platform_device *pdev)
+{
+   int err;
+   int i;
+
+   for (i = 0; i < ts_nbus->num_data; i++) {
+   err = devm_gpio_request_one(>dev, ts_nbus->data[i],
+   GPIOF_OUT_INIT_HIGH,
+   "TS NBUS data");
+   if (err)
+   return err;
+   }
+
+   err = devm_gpio_request_one(>dev, ts_nbus->csn,
+   GPIOF_OUT_INIT_HIGH,
+   "TS NBUS csn");
+   if (err)
+   return err;
+
+   err = devm_gpio_request_one(>dev, ts_nbus->txrx,
+   GPIOF_OUT_INIT_HIGH,
+   "TS NBUS txrx");
+   if (err)
+   return err;
+
+   err = devm_gpio_request_one(>dev, ts_nbus->strobe,
+   GPIOF_OUT_INIT_HIGH,
+   "TS NBUS strobe");
+   if (err)
+   return err;
+
+   err = devm_gpio_request_one(>dev, ts_nbus->ale,
+   GPIOF_OUT_INIT_HIGH,
+   "TS NBUS ale");
+   if (err)
+   return err;
+
+   err = devm_gpio_request_one(>dev, ts_nbus->rdy,
+   GPIOF_IN,
+   "TS NBUS rdy");
+   if (err)
+   return err;
+
+   return 0;
+}
+
+/*
+ * retrieve all gpios used by the bus from the device tree.
+ */
+static int ts_nbus_get_of_pdata(struct device *dev, struct device_node *np)
+{
+   int num_data;
+   int *data;
+   int ret;
+   int i;
+
+   ret = of_gpio_named_count(np, "data-gpios");
+   if (ret < 0) {
+   dev_err(dev,
+ 

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

[Tom Herbert]

On Wed, Dec 14, 2016 at 2:56 PM, Jason A. Donenfeld  wrote:
> Hey Tom,
>
> On Wed, Dec 14, 2016 at 10:35 PM, Tom Herbert  wrote:
>> Those look good, although I would probably just do 1,2,3 words and
>> then have a function that takes n words like jhash. Might want to call
>> these dword to distinguish from 32 bit words in jhash.
>
> So actually jhash_Nwords makes no sense, since it takes dwords
> (32-bits) not words (16-bits). The siphash analog should be called
> siphash24_Nqwords.
>
Yeah, that's a "bug" with jhash function names.

> I think what I'll do is change what I already have to:
> siphash24_1qword
> siphash24_2qword
> siphash24_3qword
> siphash24_4qword
>
> And then add some static inline helpers to assist with smaller u32s
> like ipv4 addresses called:
>
> siphash24_2dword
> siphash24_4dword
> siphash24_6dword
> siphash24_8dword
>
> While we're having something new, might as well call it the right thing.
>
I'm confused, doesn't 2dword == 1qword? Anyway, I think the qword
functions are good enough. If someone needs to hash over some odd
length they can either put them in a structure padded to 64 bits or
call the hash function that takes a byte length.

>
>> Also, what is the significance of "24" in the function and constant
>> names? Can we just drop that and call this siphash?
>
> SipHash is actually a family of PRFs, differentiated by the number of
> SIPROUNDs after each 64-bit input is processed and the number of
> SIPROUNDs at the very end of the function. The best trade-off of speed
> and security for kernel usage is 2 rounds after each 64-bit input and
> 4 rounds at the end of the function. This doesn't fall to any known
> cryptanalysis and it's very fast.

I'd still drop the "24" unless you really think we're going to have
multiple variants coming into the kernel.

Tom

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

[Tom Herbert]

On Wed, Dec 14, 2016 at 2:56 PM, Jason A. Donenfeld  wrote:
> Hey Tom,
>
> On Wed, Dec 14, 2016 at 10:35 PM, Tom Herbert  wrote:
>> Those look good, although I would probably just do 1,2,3 words and
>> then have a function that takes n words like jhash. Might want to call
>> these dword to distinguish from 32 bit words in jhash.
>
> So actually jhash_Nwords makes no sense, since it takes dwords
> (32-bits) not words (16-bits). The siphash analog should be called
> siphash24_Nqwords.
>
Yeah, that's a "bug" with jhash function names.

> I think what I'll do is change what I already have to:
> siphash24_1qword
> siphash24_2qword
> siphash24_3qword
> siphash24_4qword
>
> And then add some static inline helpers to assist with smaller u32s
> like ipv4 addresses called:
>
> siphash24_2dword
> siphash24_4dword
> siphash24_6dword
> siphash24_8dword
>
> While we're having something new, might as well call it the right thing.
>
I'm confused, doesn't 2dword == 1qword? Anyway, I think the qword
functions are good enough. If someone needs to hash over some odd
length they can either put them in a structure padded to 64 bits or
call the hash function that takes a byte length.

>
>> Also, what is the significance of "24" in the function and constant
>> names? Can we just drop that and call this siphash?
>
> SipHash is actually a family of PRFs, differentiated by the number of
> SIPROUNDs after each 64-bit input is processed and the number of
> SIPROUNDs at the very end of the function. The best trade-off of speed
> and security for kernel usage is 2 rounds after each 64-bit input and
> 4 rounds at the end of the function. This doesn't fall to any known
> cryptanalysis and it's very fast.

I'd still drop the "24" unless you really think we're going to have
multiple variants coming into the kernel.

Tom

[PATCH 4/6] bus: add driver for the Technologic Systems NBUS

[Sebastien Bourdelin]

This driver implements a GPIOs bit-banged bus, called the NBUS by
Technologic Systems. It is used to communicate with the peripherals in
the FPGA on the TS-4600 SoM.

Signed-off-by: Sebastien Bourdelin 
---
 drivers/bus/Kconfig |   9 +
 drivers/bus/Makefile|   1 +
 drivers/bus/ts-nbus.c   | 451 
 include/linux/ts-nbus.h |  17 ++
 4 files changed, 478 insertions(+)
 create mode 100644 drivers/bus/ts-nbus.c
 create mode 100644 include/linux/ts-nbus.h

diff --git a/drivers/bus/Kconfig b/drivers/bus/Kconfig
index 7875105..74e72b3 100644
--- a/drivers/bus/Kconfig
+++ b/drivers/bus/Kconfig
@@ -150,6 +150,15 @@ config TEGRA_ACONNECT
  Driver for the Tegra ACONNECT bus which is used to interface with
  the devices inside the Audio Processing Engine (APE) for Tegra210.
 
+config TS_NBUS
+   tristate "Technologic Systems NBUS Driver"
+   default y
+   depends on SOC_IMX28
+   depends on OF_GPIO && PWM
+   help
+ Driver for the Technologic Systems NBUS which is used to interface
+ with the peripherals in the FPGA of the TS-4600 SoM.
+
 config UNIPHIER_SYSTEM_BUS
tristate "UniPhier System Bus driver"
depends on ARCH_UNIPHIER && OF
diff --git a/drivers/bus/Makefile b/drivers/bus/Makefile
index c6cfa6b..83f874a 100644
--- a/drivers/bus/Makefile
+++ b/drivers/bus/Makefile
@@ -19,5 +19,6 @@ obj-$(CONFIG_QCOM_EBI2)   += qcom-ebi2.o
 obj-$(CONFIG_SUNXI_RSB)+= sunxi-rsb.o
 obj-$(CONFIG_SIMPLE_PM_BUS)+= simple-pm-bus.o
 obj-$(CONFIG_TEGRA_ACONNECT)   += tegra-aconnect.o
+obj-$(CONFIG_TS_NBUS)  += ts-nbus.o
 obj-$(CONFIG_UNIPHIER_SYSTEM_BUS)  += uniphier-system-bus.o
 obj-$(CONFIG_VEXPRESS_CONFIG)  += vexpress-config.o
diff --git a/drivers/bus/ts-nbus.c b/drivers/bus/ts-nbus.c
new file mode 100644
index 000..44fc89d
--- /dev/null
+++ b/drivers/bus/ts-nbus.c
@@ -0,0 +1,451 @@
+/*
+ * NBUS driver for TS-4600 based boards
+ *
+ * Copyright (c) 2016 - Savoir-faire Linux
+ * Author: Sebastien Bourdelin 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * This driver implements a GPIOs bit-banged bus, called the NBUS by 
Technologic
+ * Systems. It is used to communicate with the peripherals in the FPGA on the
+ * TS-4600 SoM.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static DEFINE_MUTEX(ts_nbus_lock);
+static bool ts_nbus_ready;
+
+#define TS_NBUS_READ_MODE  0
+#define TS_NBUS_WRITE_MODE 1
+#define TS_NBUS_DIRECTION_IN  0
+#define TS_NBUS_DIRECTION_OUT 1
+#define TS_NBUS_WRITE_ADR 0
+#define TS_NBUS_WRITE_VAL 1
+
+struct ts_nbus {
+   struct pwm_device *pwm;
+   int num_data;
+   int *data;
+   int csn;
+   int txrx;
+   int strobe;
+   int ale;
+   int rdy;
+};
+
+static struct ts_nbus *ts_nbus;
+
+/*
+ * request all gpios required by the bus.
+ */
+static int ts_nbus_init(struct platform_device *pdev)
+{
+   int err;
+   int i;
+
+   for (i = 0; i < ts_nbus->num_data; i++) {
+   err = devm_gpio_request_one(>dev, ts_nbus->data[i],
+   GPIOF_OUT_INIT_HIGH,
+   "TS NBUS data");
+   if (err)
+   return err;
+   }
+
+   err = devm_gpio_request_one(>dev, ts_nbus->csn,
+   GPIOF_OUT_INIT_HIGH,
+   "TS NBUS csn");
+   if (err)
+   return err;
+
+   err = devm_gpio_request_one(>dev, ts_nbus->txrx,
+   GPIOF_OUT_INIT_HIGH,
+   "TS NBUS txrx");
+   if (err)
+   return err;
+
+   err = devm_gpio_request_one(>dev, ts_nbus->strobe,
+   GPIOF_OUT_INIT_HIGH,
+   "TS NBUS strobe");
+   if (err)
+   return err;
+
+   err = devm_gpio_request_one(>dev, ts_nbus->ale,
+   GPIOF_OUT_INIT_HIGH,
+   "TS NBUS ale");
+   if (err)
+   return err;
+
+   err = devm_gpio_request_one(>dev, ts_nbus->rdy,
+   GPIOF_IN,
+   "TS NBUS rdy");
+   if (err)
+   return err;
+
+   return 0;
+}
+
+/*
+ * retrieve all gpios used by the bus from the device tree.
+ */
+static int ts_nbus_get_of_pdata(struct device *dev, struct device_node *np)
+{
+   int num_data;
+   int *data;
+   int ret;
+   int i;
+
+   ret = of_gpio_named_count(np, "data-gpios");
+   if (ret < 0) {
+   dev_err(dev,
+   "failed to count GPIOs in DT property data-gpios\n");
+   

[PATCH 5/6] ARM: dts: TS-4600: add NBUS support

[Sebastien Bourdelin]

This commit enables the NBUS on the TS-4600, using the ts-nbus driver.

Signed-off-by: Sebastien Bourdelin 
---
 arch/arm/boot/dts/imx28-ts4600-common.dtsi | 43 ++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm/boot/dts/imx28-ts4600-common.dtsi 
b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
index 04bd5a5..b668933 100644
--- a/arch/arm/boot/dts/imx28-ts4600-common.dtsi
+++ b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
@@ -44,6 +44,28 @@
fsl,pull-up = ;
};
 
+   nbus_pins: nbus_pins {
+   fsl,pinmux-ids = <
+   MX28_PAD_GPMI_D00__GPIO_0_0
+   MX28_PAD_GPMI_D01__GPIO_0_1
+   MX28_PAD_GPMI_D02__GPIO_0_2
+   MX28_PAD_GPMI_D03__GPIO_0_3
+   MX28_PAD_GPMI_D04__GPIO_0_4
+   MX28_PAD_GPMI_D05__GPIO_0_5
+   MX28_PAD_GPMI_D06__GPIO_0_6
+   MX28_PAD_GPMI_D07__GPIO_0_7
+   MX28_PAD_GPMI_CE0N__GPIO_0_16
+   MX28_PAD_GPMI_RDY1__GPIO_0_21
+   MX28_PAD_GPMI_RDN__GPIO_0_24
+   MX28_PAD_GPMI_WRN__GPIO_0_25
+   MX28_PAD_GPMI_ALE__GPIO_0_26
+   >;
+   fsl,drive-strength = ;
+   fsl,voltage = ;
+   fsl,pull-up = ;
+
+   };
+
};
};
 
@@ -75,4 +97,25 @@
};
};
 
+   nbus {
+   compatible = "technologic,ts-nbus", "simple-bus";
+   pinctrl-0 = <_pins>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pwms = < 2 83>;
+   data-gpios   = < 0 GPIO_ACTIVE_HIGH
+1 GPIO_ACTIVE_HIGH
+2 GPIO_ACTIVE_HIGH
+3 GPIO_ACTIVE_HIGH
+4 GPIO_ACTIVE_HIGH
+5 GPIO_ACTIVE_HIGH
+6 GPIO_ACTIVE_HIGH
+7 GPIO_ACTIVE_HIGH>;
+   csn-gpios= < 16 GPIO_ACTIVE_HIGH>;
+   txrx-gpios   = < 24 GPIO_ACTIVE_HIGH>;
+   strobe-gpios = < 25 GPIO_ACTIVE_HIGH>;
+   ale-gpios= < 26 GPIO_ACTIVE_HIGH>;
+   rdy-gpios= < 21 GPIO_ACTIVE_HIGH>;
+   };
+
 };
-- 
2.10.2

[PATCH 3/6] dt-bindings: bus: Add documentation for the Technologic Systems NBUS

[Sebastien Bourdelin]

Add binding documentation for the Technologic Systems NBUS that is used
to interface with peripherals in the FPGA of the TS-4600 SoM.

Signed-off-by: Sebastien Bourdelin 
---
 Documentation/devicetree/bindings/bus/ts-nbus.txt | 50 +++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/ts-nbus.txt

diff --git a/Documentation/devicetree/bindings/bus/ts-nbus.txt 
b/Documentation/devicetree/bindings/bus/ts-nbus.txt
new file mode 100644
index 000..2f777ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/ts-nbus.txt
@@ -0,0 +1,50 @@
+Technologic Systems NBUS
+
+The NBUS is a bus used to interface with peripherals in the Technologic
+Systems FPGA on the TS-4600 SoM.
+
+Required properties :
+ - compatible : "technologic,ts-nbus", "simple-bus"
+ - #address-cells : must be 1
+ - #size-cells: must be 0
+ - pws: The PWM pin connected to the clock line on the FPGA
+ - data-gpios: The GPIO pin connected to the data line on the FPGA
+ - csn-gpios : The GPIO pin connected to the csn line on the FPGA
+ - txrx-gpios: The GPIO pin connected to the txrx line on the FPGA
+ - strobe-gpios  : The GPIO pin connected to the stobe line on the FPGA
+ - ale-gpios : The GPIO pin connected to the ale line on the FPGA
+ - rdy-gpios : The GPIO pin connected to the rdy line on the FPGA
+
+Child nodes:
+
+The NBUS node can contain zero or more child nodes representing peripherals
+on the bus.
+
+Example:
+
+   nbus {
+   compatible = "technologic,ts-nbus", "simple-bus";
+   pinctrl-0 = <_pins>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pwms = < 2 83>;
+   data-gpios   = < 0 GPIO_ACTIVE_HIGH
+1 GPIO_ACTIVE_HIGH
+2 GPIO_ACTIVE_HIGH
+3 GPIO_ACTIVE_HIGH
+4 GPIO_ACTIVE_HIGH
+5 GPIO_ACTIVE_HIGH
+6 GPIO_ACTIVE_HIGH
+7 GPIO_ACTIVE_HIGH>;
+   csn-gpios= < 16 GPIO_ACTIVE_HIGH>;
+   txrx-gpios   = < 24 GPIO_ACTIVE_HIGH>;
+   strobe-gpios = < 25 GPIO_ACTIVE_HIGH>;
+   ale-gpios= < 26 GPIO_ACTIVE_HIGH>;
+   rdy-gpios= < 21 GPIO_ACTIVE_HIGH>;
+
+   wdt@2a {
+   compatible = "...";
+
+   /* ... */
+   };
+   };
-- 
2.10.2

[PATCH 2/6] ARM: dts: TS-4600: add basic device tree

[Sebastien Bourdelin]

These device trees add support for the TS-4600 by Technologic Systems.

More details here:
  http://wiki.embeddedarm.com/wiki/TS-4600

Signed-off-by: Sebastien Bourdelin 
---
 arch/arm/boot/dts/Makefile |  2 +
 arch/arm/boot/dts/imx28-ts4600-common.dtsi | 78 ++
 arch/arm/boot/dts/imx28-ts4600-rev-a.dts   | 22 +
 arch/arm/boot/dts/imx28-ts4600-rev-b.dts   | 22 +
 4 files changed, 124 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx28-ts4600-common.dtsi
 create mode 100644 arch/arm/boot/dts/imx28-ts4600-rev-a.dts
 create mode 100644 arch/arm/boot/dts/imx28-ts4600-rev-b.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c558ba7..5a79fab 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -466,6 +466,8 @@ dtb-$(CONFIG_ARCH_MXS) += \
imx28-m28cu3.dtb \
imx28-m28evk.dtb \
imx28-sps1.dtb \
+   imx28-ts4600-rev-a.dtb \
+   imx28-ts4600-rev-b.dtb \
imx28-tx28.dtb
 dtb-$(CONFIG_ARCH_NOMADIK) += \
ste-nomadik-s8815.dtb \
diff --git a/arch/arm/boot/dts/imx28-ts4600-common.dtsi 
b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
new file mode 100644
index 000..04bd5a5
--- /dev/null
+++ b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
@@ -0,0 +1,78 @@
+/*
+ * Copyright (C) 2016 Savoir-Faire Linux
+ * Author: Sebastien Bourdelin 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+#include "imx28.dtsi"
+#include "dt-bindings/gpio/gpio.h"
+
+/ {
+
+   compatible = "technologic,imx28-ts4600", "fsl,imx28";
+
+   apb@8000 {
+   apbh@8000 {
+   ssp0: ssp@8001 {
+   compatible = "fsl,imx28-mmc";
+   pinctrl-names = "default";
+   pinctrl-0 = <_4bit_pins_a
+_sck_cfg
+_sd_pwr>;
+   broken-cd = <1>;
+   bus-width = <4>;
+   vmmc-supply = <_vddio_sd0>;
+   status = "okay";
+   };
+
+   pinctrl@80018000 {
+   pinctrl-names = "default";
+
+   en_sd_pwr: en_sd_pwr {
+   fsl,pinmux-ids = <
+   MX28_PAD_PWM3__GPIO_3_28
+   >;
+   fsl,drive-strength = ;
+   fsl,voltage = ;
+   fsl,pull-up = ;
+   };
+
+   };
+   };
+
+   apbx@8004 {
+   pwm: pwm@80064000 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+   };
+
+   duart: serial@80074000 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+   };
+   };
+   };
+
+   regulators {
+   compatible = "simple-bus";
+
+   reg_vddio_sd0: vddio-sd0 {
+   compatible = "regulator-fixed";
+   regulator-name = "vddio-sd0";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   gpio = < 28 0>;
+   };
+   };
+
+};
diff --git a/arch/arm/boot/dts/imx28-ts4600-rev-a.dts 
b/arch/arm/boot/dts/imx28-ts4600-rev-a.dts
new file mode 100644
index 000..e8cb729
--- /dev/null
+++ b/arch/arm/boot/dts/imx28-ts4600-rev-a.dts
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2016 Savoir-Faire Linux
+ * Author: Sebastien Bourdelin 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include "imx28-ts4600-common.dtsi"
+
+/ {
+   model = "Technologic Systems i.MX28 TS-4600 Rev A";
+
+   memory {
+   reg = <0x4000 0x0800>;   /* 128MB */
+   };
+
+};
diff 

[PATCH 5/6] ARM: dts: TS-4600: add NBUS support

[Sebastien Bourdelin]

This commit enables the NBUS on the TS-4600, using the ts-nbus driver.

Signed-off-by: Sebastien Bourdelin 
---
 arch/arm/boot/dts/imx28-ts4600-common.dtsi | 43 ++
 1 file changed, 43 insertions(+)

diff --git a/arch/arm/boot/dts/imx28-ts4600-common.dtsi 
b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
index 04bd5a5..b668933 100644
--- a/arch/arm/boot/dts/imx28-ts4600-common.dtsi
+++ b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
@@ -44,6 +44,28 @@
fsl,pull-up = ;
};
 
+   nbus_pins: nbus_pins {
+   fsl,pinmux-ids = <
+   MX28_PAD_GPMI_D00__GPIO_0_0
+   MX28_PAD_GPMI_D01__GPIO_0_1
+   MX28_PAD_GPMI_D02__GPIO_0_2
+   MX28_PAD_GPMI_D03__GPIO_0_3
+   MX28_PAD_GPMI_D04__GPIO_0_4
+   MX28_PAD_GPMI_D05__GPIO_0_5
+   MX28_PAD_GPMI_D06__GPIO_0_6
+   MX28_PAD_GPMI_D07__GPIO_0_7
+   MX28_PAD_GPMI_CE0N__GPIO_0_16
+   MX28_PAD_GPMI_RDY1__GPIO_0_21
+   MX28_PAD_GPMI_RDN__GPIO_0_24
+   MX28_PAD_GPMI_WRN__GPIO_0_25
+   MX28_PAD_GPMI_ALE__GPIO_0_26
+   >;
+   fsl,drive-strength = ;
+   fsl,voltage = ;
+   fsl,pull-up = ;
+
+   };
+
};
};
 
@@ -75,4 +97,25 @@
};
};
 
+   nbus {
+   compatible = "technologic,ts-nbus", "simple-bus";
+   pinctrl-0 = <_pins>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pwms = < 2 83>;
+   data-gpios   = < 0 GPIO_ACTIVE_HIGH
+1 GPIO_ACTIVE_HIGH
+2 GPIO_ACTIVE_HIGH
+3 GPIO_ACTIVE_HIGH
+4 GPIO_ACTIVE_HIGH
+5 GPIO_ACTIVE_HIGH
+6 GPIO_ACTIVE_HIGH
+7 GPIO_ACTIVE_HIGH>;
+   csn-gpios= < 16 GPIO_ACTIVE_HIGH>;
+   txrx-gpios   = < 24 GPIO_ACTIVE_HIGH>;
+   strobe-gpios = < 25 GPIO_ACTIVE_HIGH>;
+   ale-gpios= < 26 GPIO_ACTIVE_HIGH>;
+   rdy-gpios= < 21 GPIO_ACTIVE_HIGH>;
+   };
+
 };
-- 
2.10.2

[PATCH 3/6] dt-bindings: bus: Add documentation for the Technologic Systems NBUS

[Sebastien Bourdelin]

Add binding documentation for the Technologic Systems NBUS that is used
to interface with peripherals in the FPGA of the TS-4600 SoM.

Signed-off-by: Sebastien Bourdelin 
---
 Documentation/devicetree/bindings/bus/ts-nbus.txt | 50 +++
 1 file changed, 50 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/ts-nbus.txt

diff --git a/Documentation/devicetree/bindings/bus/ts-nbus.txt 
b/Documentation/devicetree/bindings/bus/ts-nbus.txt
new file mode 100644
index 000..2f777ee
--- /dev/null
+++ b/Documentation/devicetree/bindings/bus/ts-nbus.txt
@@ -0,0 +1,50 @@
+Technologic Systems NBUS
+
+The NBUS is a bus used to interface with peripherals in the Technologic
+Systems FPGA on the TS-4600 SoM.
+
+Required properties :
+ - compatible : "technologic,ts-nbus", "simple-bus"
+ - #address-cells : must be 1
+ - #size-cells: must be 0
+ - pws: The PWM pin connected to the clock line on the FPGA
+ - data-gpios: The GPIO pin connected to the data line on the FPGA
+ - csn-gpios : The GPIO pin connected to the csn line on the FPGA
+ - txrx-gpios: The GPIO pin connected to the txrx line on the FPGA
+ - strobe-gpios  : The GPIO pin connected to the stobe line on the FPGA
+ - ale-gpios : The GPIO pin connected to the ale line on the FPGA
+ - rdy-gpios : The GPIO pin connected to the rdy line on the FPGA
+
+Child nodes:
+
+The NBUS node can contain zero or more child nodes representing peripherals
+on the bus.
+
+Example:
+
+   nbus {
+   compatible = "technologic,ts-nbus", "simple-bus";
+   pinctrl-0 = <_pins>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   pwms = < 2 83>;
+   data-gpios   = < 0 GPIO_ACTIVE_HIGH
+1 GPIO_ACTIVE_HIGH
+2 GPIO_ACTIVE_HIGH
+3 GPIO_ACTIVE_HIGH
+4 GPIO_ACTIVE_HIGH
+5 GPIO_ACTIVE_HIGH
+6 GPIO_ACTIVE_HIGH
+7 GPIO_ACTIVE_HIGH>;
+   csn-gpios= < 16 GPIO_ACTIVE_HIGH>;
+   txrx-gpios   = < 24 GPIO_ACTIVE_HIGH>;
+   strobe-gpios = < 25 GPIO_ACTIVE_HIGH>;
+   ale-gpios= < 26 GPIO_ACTIVE_HIGH>;
+   rdy-gpios= < 21 GPIO_ACTIVE_HIGH>;
+
+   wdt@2a {
+   compatible = "...";
+
+   /* ... */
+   };
+   };
-- 
2.10.2

[PATCH 2/6] ARM: dts: TS-4600: add basic device tree

[Sebastien Bourdelin]

These device trees add support for the TS-4600 by Technologic Systems.

More details here:
  http://wiki.embeddedarm.com/wiki/TS-4600

Signed-off-by: Sebastien Bourdelin 
---
 arch/arm/boot/dts/Makefile |  2 +
 arch/arm/boot/dts/imx28-ts4600-common.dtsi | 78 ++
 arch/arm/boot/dts/imx28-ts4600-rev-a.dts   | 22 +
 arch/arm/boot/dts/imx28-ts4600-rev-b.dts   | 22 +
 4 files changed, 124 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx28-ts4600-common.dtsi
 create mode 100644 arch/arm/boot/dts/imx28-ts4600-rev-a.dts
 create mode 100644 arch/arm/boot/dts/imx28-ts4600-rev-b.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c558ba7..5a79fab 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -466,6 +466,8 @@ dtb-$(CONFIG_ARCH_MXS) += \
imx28-m28cu3.dtb \
imx28-m28evk.dtb \
imx28-sps1.dtb \
+   imx28-ts4600-rev-a.dtb \
+   imx28-ts4600-rev-b.dtb \
imx28-tx28.dtb
 dtb-$(CONFIG_ARCH_NOMADIK) += \
ste-nomadik-s8815.dtb \
diff --git a/arch/arm/boot/dts/imx28-ts4600-common.dtsi 
b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
new file mode 100644
index 000..04bd5a5
--- /dev/null
+++ b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
@@ -0,0 +1,78 @@
+/*
+ * Copyright (C) 2016 Savoir-Faire Linux
+ * Author: Sebastien Bourdelin 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+#include "imx28.dtsi"
+#include "dt-bindings/gpio/gpio.h"
+
+/ {
+
+   compatible = "technologic,imx28-ts4600", "fsl,imx28";
+
+   apb@8000 {
+   apbh@8000 {
+   ssp0: ssp@8001 {
+   compatible = "fsl,imx28-mmc";
+   pinctrl-names = "default";
+   pinctrl-0 = <_4bit_pins_a
+_sck_cfg
+_sd_pwr>;
+   broken-cd = <1>;
+   bus-width = <4>;
+   vmmc-supply = <_vddio_sd0>;
+   status = "okay";
+   };
+
+   pinctrl@80018000 {
+   pinctrl-names = "default";
+
+   en_sd_pwr: en_sd_pwr {
+   fsl,pinmux-ids = <
+   MX28_PAD_PWM3__GPIO_3_28
+   >;
+   fsl,drive-strength = ;
+   fsl,voltage = ;
+   fsl,pull-up = ;
+   };
+
+   };
+   };
+
+   apbx@8004 {
+   pwm: pwm@80064000 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+   };
+
+   duart: serial@80074000 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+   };
+   };
+   };
+
+   regulators {
+   compatible = "simple-bus";
+
+   reg_vddio_sd0: vddio-sd0 {
+   compatible = "regulator-fixed";
+   regulator-name = "vddio-sd0";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   gpio = < 28 0>;
+   };
+   };
+
+};
diff --git a/arch/arm/boot/dts/imx28-ts4600-rev-a.dts 
b/arch/arm/boot/dts/imx28-ts4600-rev-a.dts
new file mode 100644
index 000..e8cb729
--- /dev/null
+++ b/arch/arm/boot/dts/imx28-ts4600-rev-a.dts
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2016 Savoir-Faire Linux
+ * Author: Sebastien Bourdelin 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include "imx28-ts4600-common.dtsi"
+
+/ {
+   model = "Technologic Systems i.MX28 TS-4600 Rev A";
+
+   memory {
+   reg = <0x4000 0x0800>;   /* 128MB */
+   };
+
+};
diff --git a/arch/arm/boot/dts/imx28-ts4600-rev-b.dts 
b/arch/arm/boot/dts/imx28-ts4600-rev-b.dts
new file mode 100644
index 

[PATCH 0/6] Add board support for TS-4600

[Sebastien Bourdelin]

This patch serie adds support for the TS-4600 boards rev A and B. These
boards, manufactured by Technologic Systems, are based on an i.MX28.

This serie include the support for the watchdog which could be enable
at Linux boot time depending on the bootloader.

The watchdog and few peripherals are implemented in a FPGA, and can
only be access using a custom GPIOs bit-banged bus which is called the
NBUS by Technologic Systems.
A driver for this bus is also included and used by the watchdog.

Sebastien Bourdelin (6):
  of: documentation: add bindings documentation for TS-4600
  ARM: dts: TS-4600: add basic device tree
  dt-bindings: bus: Add documentation for the Technologic Systems NBUS
  bus: add driver for the Technologic Systems NBUS
  ARM: dts: TS-4600: add NBUS support
  watchdog: ts4600: add driver for TS-4600 watchdog

 .../devicetree/bindings/arm/technologic.txt|   5 +
 Documentation/devicetree/bindings/bus/ts-nbus.txt  |  50 +++
 .../devicetree/bindings/watchdog/ts4600-wdt.txt|  16 +
 arch/arm/boot/dts/Makefile |   2 +
 arch/arm/boot/dts/imx28-ts4600-common.dtsi | 126 ++
 arch/arm/boot/dts/imx28-ts4600-rev-a.dts   |  22 +
 arch/arm/boot/dts/imx28-ts4600-rev-b.dts   |  22 +
 drivers/bus/Kconfig|   9 +
 drivers/bus/Makefile   |   1 +
 drivers/bus/ts-nbus.c  | 451 +
 drivers/watchdog/Kconfig   |  10 +
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/ts4600_wdt.c  | 213 ++
 include/linux/ts-nbus.h|  17 +
 14 files changed, 945 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/ts-nbus.txt
 create mode 100644 Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
 create mode 100644 arch/arm/boot/dts/imx28-ts4600-common.dtsi
 create mode 100644 arch/arm/boot/dts/imx28-ts4600-rev-a.dts
 create mode 100644 arch/arm/boot/dts/imx28-ts4600-rev-b.dts
 create mode 100644 drivers/bus/ts-nbus.c
 create mode 100644 drivers/watchdog/ts4600_wdt.c
 create mode 100644 include/linux/ts-nbus.h

-- 
2.10.2

[PATCH 6/6] watchdog: ts4600: add driver for TS-4600 watchdog

[Sebastien Bourdelin]

This watchdog is instantiated in a FPGA and can only be access using a
GPIOs bit-banged bus, called the NBUS by Technologic Systems.
The watchdog is made of only one register, called the feed register.
Writing to this register will re-arm the watchdog for a given time (and
enable it if it was disable). It can be disabled by writing a special
value into it.

Signed-off-by: Sebastien Bourdelin 
---
 .../devicetree/bindings/watchdog/ts4600-wdt.txt|  16 ++
 arch/arm/boot/dts/imx28-ts4600-common.dtsi |   5 +
 drivers/watchdog/Kconfig   |  10 +
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/ts4600_wdt.c  | 213 +
 5 files changed, 245 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
 create mode 100644 drivers/watchdog/ts4600_wdt.c

diff --git a/Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt 
b/Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
new file mode 100644
index 000..61d620e
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
@@ -0,0 +1,16 @@
+TS-4600 Technologic Systems Watchdog
+
+Required properties:
+- compatible: must be "technologic,ts4600-wdt"
+- reg: offset to the FPGA's watchdog register
+
+Optional property:
+- timeout-sec: contains the watchdog timeout in seconds.
+
+Example:
+
+wdt {
+   compatible = "technologic,ts4600-wdt";
+   reg = <0x2a>;
+   timeout-sec = <10>;
+};
diff --git a/arch/arm/boot/dts/imx28-ts4600-common.dtsi 
b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
index b668933..dd7318c 100644
--- a/arch/arm/boot/dts/imx28-ts4600-common.dtsi
+++ b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
@@ -116,6 +116,11 @@
strobe-gpios = < 25 GPIO_ACTIVE_HIGH>;
ale-gpios= < 26 GPIO_ACTIVE_HIGH>;
rdy-gpios= < 21 GPIO_ACTIVE_HIGH>;
+
+   wdt@2a {
+   compatible = "technologic,ts4600-wdt";
+   reg = <0x2a>;
+   };
};
 
 };
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 3eb58cb..7a8e176 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -500,6 +500,16 @@ config NUC900_WATCHDOG
  To compile this driver as a module, choose M here: the
  module will be called nuc900_wdt.
 
+config TS4600_WATCHDOG
+   tristate "TS-4600 Watchdog"
+   depends on HAS_IOMEM && OF
+   depends on SOC_IMX28 || COMPILE_TEST
+   select WATCHDOG_CORE
+   help
+ Technologic Systems TS-4600 has watchdog timer implemented in
+ an external FPGA. Say Y here if you want to support for the
+ watchdog timer on TS-4600 board.
+
 config TS4800_WATCHDOG
tristate "TS-4800 Watchdog"
depends on HAS_IOMEM && OF
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index caa9f4a..d4b4bd2 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_RN5T618_WATCHDOG) += rn5t618_wdt.o
 obj-$(CONFIG_COH901327_WATCHDOG) += coh901327_wdt.o
 obj-$(CONFIG_STMP3XXX_RTC_WATCHDOG) += stmp3xxx_rtc_wdt.o
 obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
+obj-$(CONFIG_TS4600_WATCHDOG) += ts4600_wdt.o
 obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o
 obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
 obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
diff --git a/drivers/watchdog/ts4600_wdt.c b/drivers/watchdog/ts4600_wdt.c
new file mode 100644
index 000..db91b40
--- /dev/null
+++ b/drivers/watchdog/ts4600_wdt.c
@@ -0,0 +1,213 @@
+/*
+ * Watchdog driver for TS-4600 based boards
+ *
+ * Copyright (c) 2016 - Savoir-faire Linux
+ * Author: Sebastien Bourdelin 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * The watchdog on the TS-4600 based boards is in an FPGA and can only be
+ * accessed using a GPIO bit-banged bus called the NBUS by Technologic Systems.
+ * The logic for the watchdog is the same then for the TS-4800 SoM, only the 
way
+ * to access it change, therefore this driver is heavely based on the 
ts4800_wdt
+ * driver from Damien Riegel .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout,
+   "Watchdog cannot be stopped once started (default="
+   __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+/* possible feed values */
+#define TS4600_WDT_FEED_2S   0x1
+#define TS4600_WDT_FEED_10S  0x2
+#define TS4600_WDT_DISABLE   0x3
+
+struct ts4600_wdt {
+   struct watchdog_device  wdd;
+   u32 feed_offset;
+   u32 

[PATCH 0/6] Add board support for TS-4600

[Sebastien Bourdelin]

This patch serie adds support for the TS-4600 boards rev A and B. These
boards, manufactured by Technologic Systems, are based on an i.MX28.

This serie include the support for the watchdog which could be enable
at Linux boot time depending on the bootloader.

The watchdog and few peripherals are implemented in a FPGA, and can
only be access using a custom GPIOs bit-banged bus which is called the
NBUS by Technologic Systems.
A driver for this bus is also included and used by the watchdog.

Sebastien Bourdelin (6):
  of: documentation: add bindings documentation for TS-4600
  ARM: dts: TS-4600: add basic device tree
  dt-bindings: bus: Add documentation for the Technologic Systems NBUS
  bus: add driver for the Technologic Systems NBUS
  ARM: dts: TS-4600: add NBUS support
  watchdog: ts4600: add driver for TS-4600 watchdog

 .../devicetree/bindings/arm/technologic.txt|   5 +
 Documentation/devicetree/bindings/bus/ts-nbus.txt  |  50 +++
 .../devicetree/bindings/watchdog/ts4600-wdt.txt|  16 +
 arch/arm/boot/dts/Makefile |   2 +
 arch/arm/boot/dts/imx28-ts4600-common.dtsi | 126 ++
 arch/arm/boot/dts/imx28-ts4600-rev-a.dts   |  22 +
 arch/arm/boot/dts/imx28-ts4600-rev-b.dts   |  22 +
 drivers/bus/Kconfig|   9 +
 drivers/bus/Makefile   |   1 +
 drivers/bus/ts-nbus.c  | 451 +
 drivers/watchdog/Kconfig   |  10 +
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/ts4600_wdt.c  | 213 ++
 include/linux/ts-nbus.h|  17 +
 14 files changed, 945 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/bus/ts-nbus.txt
 create mode 100644 Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
 create mode 100644 arch/arm/boot/dts/imx28-ts4600-common.dtsi
 create mode 100644 arch/arm/boot/dts/imx28-ts4600-rev-a.dts
 create mode 100644 arch/arm/boot/dts/imx28-ts4600-rev-b.dts
 create mode 100644 drivers/bus/ts-nbus.c
 create mode 100644 drivers/watchdog/ts4600_wdt.c
 create mode 100644 include/linux/ts-nbus.h

-- 
2.10.2

[PATCH 6/6] watchdog: ts4600: add driver for TS-4600 watchdog

[Sebastien Bourdelin]

This watchdog is instantiated in a FPGA and can only be access using a
GPIOs bit-banged bus, called the NBUS by Technologic Systems.
The watchdog is made of only one register, called the feed register.
Writing to this register will re-arm the watchdog for a given time (and
enable it if it was disable). It can be disabled by writing a special
value into it.

Signed-off-by: Sebastien Bourdelin 
---
 .../devicetree/bindings/watchdog/ts4600-wdt.txt|  16 ++
 arch/arm/boot/dts/imx28-ts4600-common.dtsi |   5 +
 drivers/watchdog/Kconfig   |  10 +
 drivers/watchdog/Makefile  |   1 +
 drivers/watchdog/ts4600_wdt.c  | 213 +
 5 files changed, 245 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
 create mode 100644 drivers/watchdog/ts4600_wdt.c

diff --git a/Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt 
b/Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
new file mode 100644
index 000..61d620e
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/ts4600-wdt.txt
@@ -0,0 +1,16 @@
+TS-4600 Technologic Systems Watchdog
+
+Required properties:
+- compatible: must be "technologic,ts4600-wdt"
+- reg: offset to the FPGA's watchdog register
+
+Optional property:
+- timeout-sec: contains the watchdog timeout in seconds.
+
+Example:
+
+wdt {
+   compatible = "technologic,ts4600-wdt";
+   reg = <0x2a>;
+   timeout-sec = <10>;
+};
diff --git a/arch/arm/boot/dts/imx28-ts4600-common.dtsi 
b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
index b668933..dd7318c 100644
--- a/arch/arm/boot/dts/imx28-ts4600-common.dtsi
+++ b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
@@ -116,6 +116,11 @@
strobe-gpios = < 25 GPIO_ACTIVE_HIGH>;
ale-gpios= < 26 GPIO_ACTIVE_HIGH>;
rdy-gpios= < 21 GPIO_ACTIVE_HIGH>;
+
+   wdt@2a {
+   compatible = "technologic,ts4600-wdt";
+   reg = <0x2a>;
+   };
};
 
 };
diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 3eb58cb..7a8e176 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -500,6 +500,16 @@ config NUC900_WATCHDOG
  To compile this driver as a module, choose M here: the
  module will be called nuc900_wdt.
 
+config TS4600_WATCHDOG
+   tristate "TS-4600 Watchdog"
+   depends on HAS_IOMEM && OF
+   depends on SOC_IMX28 || COMPILE_TEST
+   select WATCHDOG_CORE
+   help
+ Technologic Systems TS-4600 has watchdog timer implemented in
+ an external FPGA. Say Y here if you want to support for the
+ watchdog timer on TS-4600 board.
+
 config TS4800_WATCHDOG
tristate "TS-4800 Watchdog"
depends on HAS_IOMEM && OF
diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
index caa9f4a..d4b4bd2 100644
--- a/drivers/watchdog/Makefile
+++ b/drivers/watchdog/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_RN5T618_WATCHDOG) += rn5t618_wdt.o
 obj-$(CONFIG_COH901327_WATCHDOG) += coh901327_wdt.o
 obj-$(CONFIG_STMP3XXX_RTC_WATCHDOG) += stmp3xxx_rtc_wdt.o
 obj-$(CONFIG_NUC900_WATCHDOG) += nuc900_wdt.o
+obj-$(CONFIG_TS4600_WATCHDOG) += ts4600_wdt.o
 obj-$(CONFIG_TS4800_WATCHDOG) += ts4800_wdt.o
 obj-$(CONFIG_TS72XX_WATCHDOG) += ts72xx_wdt.o
 obj-$(CONFIG_IMX2_WDT) += imx2_wdt.o
diff --git a/drivers/watchdog/ts4600_wdt.c b/drivers/watchdog/ts4600_wdt.c
new file mode 100644
index 000..db91b40
--- /dev/null
+++ b/drivers/watchdog/ts4600_wdt.c
@@ -0,0 +1,213 @@
+/*
+ * Watchdog driver for TS-4600 based boards
+ *
+ * Copyright (c) 2016 - Savoir-faire Linux
+ * Author: Sebastien Bourdelin 
+ *
+ * This file is licensed under the terms of the GNU General Public
+ * License version 2. This program is licensed "as is" without any
+ * warranty of any kind, whether express or implied.
+ *
+ * The watchdog on the TS-4600 based boards is in an FPGA and can only be
+ * accessed using a GPIO bit-banged bus called the NBUS by Technologic Systems.
+ * The logic for the watchdog is the same then for the TS-4800 SoM, only the 
way
+ * to access it change, therefore this driver is heavely based on the 
ts4800_wdt
+ * driver from Damien Riegel .
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout,
+   "Watchdog cannot be stopped once started (default="
+   __MODULE_STRING(WATCHDOG_NOWAYOUT) ")");
+
+/* possible feed values */
+#define TS4600_WDT_FEED_2S   0x1
+#define TS4600_WDT_FEED_10S  0x2
+#define TS4600_WDT_DISABLE   0x3
+
+struct ts4600_wdt {
+   struct watchdog_device  wdd;
+   u32 feed_offset;
+   u32 feed_val;
+};
+
+/*
+ * TS-4600 supports the following timeout values:
+ *
+ *   value desc
+ *   -
+ 

[PATCH] net: sfc: use new api ethtool_{get|set}_link_ksettings

[Philippe Reynes]

The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/sfc/ethtool.c|   35 ---
 drivers/net/ethernet/sfc/mcdi_port.c  |   60 
 drivers/net/ethernet/sfc/net_driver.h |   12 +++---
 3 files changed, 65 insertions(+), 42 deletions(-)

diff --git a/drivers/net/ethernet/sfc/ethtool.c 
b/drivers/net/ethernet/sfc/ethtool.c
index f644216..87bdc56 100644
--- a/drivers/net/ethernet/sfc/ethtool.c
+++ b/drivers/net/ethernet/sfc/ethtool.c
@@ -120,44 +120,53 @@ static int efx_ethtool_phys_id(struct net_device *net_dev,
 }
 
 /* This must be called with rtnl_lock held. */
-static int efx_ethtool_get_settings(struct net_device *net_dev,
-   struct ethtool_cmd *ecmd)
+static int
+efx_ethtool_get_link_ksettings(struct net_device *net_dev,
+  struct ethtool_link_ksettings *cmd)
 {
struct efx_nic *efx = netdev_priv(net_dev);
struct efx_link_state *link_state = >link_state;
+   u32 supported;
 
mutex_lock(>mac_lock);
-   efx->phy_op->get_settings(efx, ecmd);
+   efx->phy_op->get_link_ksettings(efx, cmd);
mutex_unlock(>mac_lock);
 
/* Both MACs support pause frames (bidirectional and respond-only) */
-   ecmd->supported |= SUPPORTED_Pause | SUPPORTED_Asym_Pause;
+   ethtool_convert_link_mode_to_legacy_u32(,
+   cmd->link_modes.supported);
+
+   supported |= SUPPORTED_Pause | SUPPORTED_Asym_Pause;
+
+   ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+   supported);
 
if (LOOPBACK_INTERNAL(efx)) {
-   ethtool_cmd_speed_set(ecmd, link_state->speed);
-   ecmd->duplex = link_state->fd ? DUPLEX_FULL : DUPLEX_HALF;
+   cmd->base.speed = link_state->speed;
+   cmd->base.duplex = link_state->fd ? DUPLEX_FULL : DUPLEX_HALF;
}
 
return 0;
 }
 
 /* This must be called with rtnl_lock held. */
-static int efx_ethtool_set_settings(struct net_device *net_dev,
-   struct ethtool_cmd *ecmd)
+static int
+efx_ethtool_set_link_ksettings(struct net_device *net_dev,
+  const struct ethtool_link_ksettings *cmd)
 {
struct efx_nic *efx = netdev_priv(net_dev);
int rc;
 
/* GMAC does not support 1000Mbps HD */
-   if ((ethtool_cmd_speed(ecmd) == SPEED_1000) &&
-   (ecmd->duplex != DUPLEX_FULL)) {
+   if ((cmd->base.speed == SPEED_1000) &&
+   (cmd->base.duplex != DUPLEX_FULL)) {
netif_dbg(efx, drv, efx->net_dev,
  "rejecting unsupported 1000Mbps HD setting\n");
return -EINVAL;
}
 
mutex_lock(>mac_lock);
-   rc = efx->phy_op->set_settings(efx, ecmd);
+   rc = efx->phy_op->set_link_ksettings(efx, cmd);
mutex_unlock(>mac_lock);
return rc;
 }
@@ -1342,8 +1351,6 @@ static int efx_ethtool_get_module_info(struct net_device 
*net_dev,
 }
 
 const struct ethtool_ops efx_ethtool_ops = {
-   .get_settings   = efx_ethtool_get_settings,
-   .set_settings   = efx_ethtool_set_settings,
.get_drvinfo= efx_ethtool_get_drvinfo,
.get_regs_len   = efx_ethtool_get_regs_len,
.get_regs   = efx_ethtool_get_regs,
@@ -1373,4 +1380,6 @@ static int efx_ethtool_get_module_info(struct net_device 
*net_dev,
.get_ts_info= efx_ethtool_get_ts_info,
.get_module_info= efx_ethtool_get_module_info,
.get_module_eeprom  = efx_ethtool_get_module_eeprom,
+   .get_link_ksettings = efx_ethtool_get_link_ksettings,
+   .set_link_ksettings = efx_ethtool_set_link_ksettings,
 };
diff --git a/drivers/net/ethernet/sfc/mcdi_port.c 
b/drivers/net/ethernet/sfc/mcdi_port.c
index 9dcd396..c905971 100644
--- a/drivers/net/ethernet/sfc/mcdi_port.c
+++ b/drivers/net/ethernet/sfc/mcdi_port.c
@@ -503,45 +503,59 @@ static void efx_mcdi_phy_remove(struct efx_nic *efx)
kfree(phy_data);
 }
 
-static void efx_mcdi_phy_get_settings(struct efx_nic *efx, struct ethtool_cmd 
*ecmd)
+static void efx_mcdi_phy_get_link_ksettings(struct efx_nic *efx,
+   struct ethtool_link_ksettings *cmd)
 {
struct efx_mcdi_phy_data *phy_cfg = efx->phy_data;
MCDI_DECLARE_BUF(outbuf, MC_CMD_GET_LINK_OUT_LEN);
int rc;
-
-   ecmd->supported =
-   mcdi_to_ethtool_cap(phy_cfg->media, phy_cfg->supported_cap);
-   ecmd->advertising = efx->link_advertising;
-   ethtool_cmd_speed_set(ecmd, efx->link_state.speed);
-   ecmd->duplex = efx->link_state.fd;
-   ecmd->port = mcdi_to_ethtool_media(phy_cfg->media);
-   

[PATCH 2/6] ARM: dts: TS-4600: add basic device tree

[Sebastien Bourdelin]

These device trees add support for the TS-4600 by Technologic Systems.

More details here:
  http://wiki.embeddedarm.com/wiki/TS-4600

Signed-off-by: Sebastien Bourdelin 
---
 arch/arm/boot/dts/Makefile |  2 +
 arch/arm/boot/dts/imx28-ts4600-common.dtsi | 78 ++
 arch/arm/boot/dts/imx28-ts4600-rev-a.dts   | 22 +
 arch/arm/boot/dts/imx28-ts4600-rev-b.dts   | 22 +
 4 files changed, 124 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx28-ts4600-common.dtsi
 create mode 100644 arch/arm/boot/dts/imx28-ts4600-rev-a.dts
 create mode 100644 arch/arm/boot/dts/imx28-ts4600-rev-b.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c558ba7..5a79fab 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -466,6 +466,8 @@ dtb-$(CONFIG_ARCH_MXS) += \
imx28-m28cu3.dtb \
imx28-m28evk.dtb \
imx28-sps1.dtb \
+   imx28-ts4600-rev-a.dtb \
+   imx28-ts4600-rev-b.dtb \
imx28-tx28.dtb
 dtb-$(CONFIG_ARCH_NOMADIK) += \
ste-nomadik-s8815.dtb \
diff --git a/arch/arm/boot/dts/imx28-ts4600-common.dtsi 
b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
new file mode 100644
index 000..04bd5a5
--- /dev/null
+++ b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
@@ -0,0 +1,78 @@
+/*
+ * Copyright (C) 2016 Savoir-Faire Linux
+ * Author: Sebastien Bourdelin 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+#include "imx28.dtsi"
+#include "dt-bindings/gpio/gpio.h"
+
+/ {
+
+   compatible = "technologic,imx28-ts4600", "fsl,imx28";
+
+   apb@8000 {
+   apbh@8000 {
+   ssp0: ssp@8001 {
+   compatible = "fsl,imx28-mmc";
+   pinctrl-names = "default";
+   pinctrl-0 = <_4bit_pins_a
+_sck_cfg
+_sd_pwr>;
+   broken-cd = <1>;
+   bus-width = <4>;
+   vmmc-supply = <_vddio_sd0>;
+   status = "okay";
+   };
+
+   pinctrl@80018000 {
+   pinctrl-names = "default";
+
+   en_sd_pwr: en_sd_pwr {
+   fsl,pinmux-ids = <
+   MX28_PAD_PWM3__GPIO_3_28
+   >;
+   fsl,drive-strength = ;
+   fsl,voltage = ;
+   fsl,pull-up = ;
+   };
+
+   };
+   };
+
+   apbx@8004 {
+   pwm: pwm@80064000 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+   };
+
+   duart: serial@80074000 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+   };
+   };
+   };
+
+   regulators {
+   compatible = "simple-bus";
+
+   reg_vddio_sd0: vddio-sd0 {
+   compatible = "regulator-fixed";
+   regulator-name = "vddio-sd0";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   gpio = < 28 0>;
+   };
+   };
+
+};
diff --git a/arch/arm/boot/dts/imx28-ts4600-rev-a.dts 
b/arch/arm/boot/dts/imx28-ts4600-rev-a.dts
new file mode 100644
index 000..e8cb729
--- /dev/null
+++ b/arch/arm/boot/dts/imx28-ts4600-rev-a.dts
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2016 Savoir-Faire Linux
+ * Author: Sebastien Bourdelin 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include "imx28-ts4600-common.dtsi"
+
+/ {
+   model = "Technologic Systems i.MX28 TS-4600 Rev A";
+
+   memory {
+   reg = <0x4000 0x0800>;   /* 128MB */
+   };
+
+};
diff 

[PATCH] net: sfc: use new api ethtool_{get|set}_link_ksettings

[Philippe Reynes]

The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/sfc/ethtool.c|   35 ---
 drivers/net/ethernet/sfc/mcdi_port.c  |   60 
 drivers/net/ethernet/sfc/net_driver.h |   12 +++---
 3 files changed, 65 insertions(+), 42 deletions(-)

diff --git a/drivers/net/ethernet/sfc/ethtool.c 
b/drivers/net/ethernet/sfc/ethtool.c
index f644216..87bdc56 100644
--- a/drivers/net/ethernet/sfc/ethtool.c
+++ b/drivers/net/ethernet/sfc/ethtool.c
@@ -120,44 +120,53 @@ static int efx_ethtool_phys_id(struct net_device *net_dev,
 }
 
 /* This must be called with rtnl_lock held. */
-static int efx_ethtool_get_settings(struct net_device *net_dev,
-   struct ethtool_cmd *ecmd)
+static int
+efx_ethtool_get_link_ksettings(struct net_device *net_dev,
+  struct ethtool_link_ksettings *cmd)
 {
struct efx_nic *efx = netdev_priv(net_dev);
struct efx_link_state *link_state = >link_state;
+   u32 supported;
 
mutex_lock(>mac_lock);
-   efx->phy_op->get_settings(efx, ecmd);
+   efx->phy_op->get_link_ksettings(efx, cmd);
mutex_unlock(>mac_lock);
 
/* Both MACs support pause frames (bidirectional and respond-only) */
-   ecmd->supported |= SUPPORTED_Pause | SUPPORTED_Asym_Pause;
+   ethtool_convert_link_mode_to_legacy_u32(,
+   cmd->link_modes.supported);
+
+   supported |= SUPPORTED_Pause | SUPPORTED_Asym_Pause;
+
+   ethtool_convert_legacy_u32_to_link_mode(cmd->link_modes.supported,
+   supported);
 
if (LOOPBACK_INTERNAL(efx)) {
-   ethtool_cmd_speed_set(ecmd, link_state->speed);
-   ecmd->duplex = link_state->fd ? DUPLEX_FULL : DUPLEX_HALF;
+   cmd->base.speed = link_state->speed;
+   cmd->base.duplex = link_state->fd ? DUPLEX_FULL : DUPLEX_HALF;
}
 
return 0;
 }
 
 /* This must be called with rtnl_lock held. */
-static int efx_ethtool_set_settings(struct net_device *net_dev,
-   struct ethtool_cmd *ecmd)
+static int
+efx_ethtool_set_link_ksettings(struct net_device *net_dev,
+  const struct ethtool_link_ksettings *cmd)
 {
struct efx_nic *efx = netdev_priv(net_dev);
int rc;
 
/* GMAC does not support 1000Mbps HD */
-   if ((ethtool_cmd_speed(ecmd) == SPEED_1000) &&
-   (ecmd->duplex != DUPLEX_FULL)) {
+   if ((cmd->base.speed == SPEED_1000) &&
+   (cmd->base.duplex != DUPLEX_FULL)) {
netif_dbg(efx, drv, efx->net_dev,
  "rejecting unsupported 1000Mbps HD setting\n");
return -EINVAL;
}
 
mutex_lock(>mac_lock);
-   rc = efx->phy_op->set_settings(efx, ecmd);
+   rc = efx->phy_op->set_link_ksettings(efx, cmd);
mutex_unlock(>mac_lock);
return rc;
 }
@@ -1342,8 +1351,6 @@ static int efx_ethtool_get_module_info(struct net_device 
*net_dev,
 }
 
 const struct ethtool_ops efx_ethtool_ops = {
-   .get_settings   = efx_ethtool_get_settings,
-   .set_settings   = efx_ethtool_set_settings,
.get_drvinfo= efx_ethtool_get_drvinfo,
.get_regs_len   = efx_ethtool_get_regs_len,
.get_regs   = efx_ethtool_get_regs,
@@ -1373,4 +1380,6 @@ static int efx_ethtool_get_module_info(struct net_device 
*net_dev,
.get_ts_info= efx_ethtool_get_ts_info,
.get_module_info= efx_ethtool_get_module_info,
.get_module_eeprom  = efx_ethtool_get_module_eeprom,
+   .get_link_ksettings = efx_ethtool_get_link_ksettings,
+   .set_link_ksettings = efx_ethtool_set_link_ksettings,
 };
diff --git a/drivers/net/ethernet/sfc/mcdi_port.c 
b/drivers/net/ethernet/sfc/mcdi_port.c
index 9dcd396..c905971 100644
--- a/drivers/net/ethernet/sfc/mcdi_port.c
+++ b/drivers/net/ethernet/sfc/mcdi_port.c
@@ -503,45 +503,59 @@ static void efx_mcdi_phy_remove(struct efx_nic *efx)
kfree(phy_data);
 }
 
-static void efx_mcdi_phy_get_settings(struct efx_nic *efx, struct ethtool_cmd 
*ecmd)
+static void efx_mcdi_phy_get_link_ksettings(struct efx_nic *efx,
+   struct ethtool_link_ksettings *cmd)
 {
struct efx_mcdi_phy_data *phy_cfg = efx->phy_data;
MCDI_DECLARE_BUF(outbuf, MC_CMD_GET_LINK_OUT_LEN);
int rc;
-
-   ecmd->supported =
-   mcdi_to_ethtool_cap(phy_cfg->media, phy_cfg->supported_cap);
-   ecmd->advertising = efx->link_advertising;
-   ethtool_cmd_speed_set(ecmd, efx->link_state.speed);
-   ecmd->duplex = efx->link_state.fd;
-   ecmd->port = mcdi_to_ethtool_media(phy_cfg->media);
-   ecmd->phy_address = 

[PATCH 2/6] ARM: dts: TS-4600: add basic device tree

[Sebastien Bourdelin]

These device trees add support for the TS-4600 by Technologic Systems.

More details here:
  http://wiki.embeddedarm.com/wiki/TS-4600

Signed-off-by: Sebastien Bourdelin 
---
 arch/arm/boot/dts/Makefile |  2 +
 arch/arm/boot/dts/imx28-ts4600-common.dtsi | 78 ++
 arch/arm/boot/dts/imx28-ts4600-rev-a.dts   | 22 +
 arch/arm/boot/dts/imx28-ts4600-rev-b.dts   | 22 +
 4 files changed, 124 insertions(+)
 create mode 100644 arch/arm/boot/dts/imx28-ts4600-common.dtsi
 create mode 100644 arch/arm/boot/dts/imx28-ts4600-rev-a.dts
 create mode 100644 arch/arm/boot/dts/imx28-ts4600-rev-b.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c558ba7..5a79fab 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -466,6 +466,8 @@ dtb-$(CONFIG_ARCH_MXS) += \
imx28-m28cu3.dtb \
imx28-m28evk.dtb \
imx28-sps1.dtb \
+   imx28-ts4600-rev-a.dtb \
+   imx28-ts4600-rev-b.dtb \
imx28-tx28.dtb
 dtb-$(CONFIG_ARCH_NOMADIK) += \
ste-nomadik-s8815.dtb \
diff --git a/arch/arm/boot/dts/imx28-ts4600-common.dtsi 
b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
new file mode 100644
index 000..04bd5a5
--- /dev/null
+++ b/arch/arm/boot/dts/imx28-ts4600-common.dtsi
@@ -0,0 +1,78 @@
+/*
+ * Copyright (C) 2016 Savoir-Faire Linux
+ * Author: Sebastien Bourdelin 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+/dts-v1/;
+#include "imx28.dtsi"
+#include "dt-bindings/gpio/gpio.h"
+
+/ {
+
+   compatible = "technologic,imx28-ts4600", "fsl,imx28";
+
+   apb@8000 {
+   apbh@8000 {
+   ssp0: ssp@8001 {
+   compatible = "fsl,imx28-mmc";
+   pinctrl-names = "default";
+   pinctrl-0 = <_4bit_pins_a
+_sck_cfg
+_sd_pwr>;
+   broken-cd = <1>;
+   bus-width = <4>;
+   vmmc-supply = <_vddio_sd0>;
+   status = "okay";
+   };
+
+   pinctrl@80018000 {
+   pinctrl-names = "default";
+
+   en_sd_pwr: en_sd_pwr {
+   fsl,pinmux-ids = <
+   MX28_PAD_PWM3__GPIO_3_28
+   >;
+   fsl,drive-strength = ;
+   fsl,voltage = ;
+   fsl,pull-up = ;
+   };
+
+   };
+   };
+
+   apbx@8004 {
+   pwm: pwm@80064000 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+   };
+
+   duart: serial@80074000 {
+   pinctrl-names = "default";
+   pinctrl-0 = <_pins_a>;
+   status = "okay";
+   };
+   };
+   };
+
+   regulators {
+   compatible = "simple-bus";
+
+   reg_vddio_sd0: vddio-sd0 {
+   compatible = "regulator-fixed";
+   regulator-name = "vddio-sd0";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   regulator-boot-on;
+   gpio = < 28 0>;
+   };
+   };
+
+};
diff --git a/arch/arm/boot/dts/imx28-ts4600-rev-a.dts 
b/arch/arm/boot/dts/imx28-ts4600-rev-a.dts
new file mode 100644
index 000..e8cb729
--- /dev/null
+++ b/arch/arm/boot/dts/imx28-ts4600-rev-a.dts
@@ -0,0 +1,22 @@
+/*
+ * Copyright (C) 2016 Savoir-Faire Linux
+ * Author: Sebastien Bourdelin 
+ *
+ * The code contained herein is licensed under the GNU General Public
+ * License. You may obtain a copy of the GNU General Public License
+ * Version 2 or later at the following locations:
+ *
+ * http://www.opensource.org/licenses/gpl-license.html
+ * http://www.gnu.org/copyleft/gpl.html
+ */
+
+#include "imx28-ts4600-common.dtsi"
+
+/ {
+   model = "Technologic Systems i.MX28 TS-4600 Rev A";
+
+   memory {
+   reg = <0x4000 0x0800>;   /* 128MB */
+   };
+
+};
diff --git a/arch/arm/boot/dts/imx28-ts4600-rev-b.dts 
b/arch/arm/boot/dts/imx28-ts4600-rev-b.dts
new file mode 100644
index 

[PATCH] platform/x86: thinkpad_acpi: Initialize local in_tablet_mode

[Darren Hart]

linux-next reported in_tablet_mode may be used uninitialized after:

b31800283868 ("platform/x86: thinkpad_acpi: Move tablet detection into separate 
function")

This turns out to be a false positive as the pr_info call cannot be
reached if tp_features.hotkey_tablet (global scope) is 0, and
in_tablet_mode is assigned in both places tp_features.hotkey_tablet is
assigned.

Regardless, to make it explicit and avoid further reports, initialize
in_tablet_mode to 0.

Signed-off-by: Darren Hart 
Cc: Lyude 
Cc: Henrique de Moraes Holschuh 
Cc: Andy Shevchenko 
---
 drivers/platform/x86/thinkpad_acpi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/thinkpad_acpi.c 
b/drivers/platform/x86/thinkpad_acpi.c
index 69cb0da..1c5a6e2 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -3143,7 +3143,7 @@ typedef tpacpi_keymap_entry_t 
tpacpi_keymap_t[TPACPI_HOTKEY_MAP_LEN];
 
 static int hotkey_init_tablet_mode(void)
 {
-   int in_tablet_mode, res;
+   int in_tablet_mode = 0, res;
char *type;
 
if (acpi_evalf(hkey_handle, , "MHKG", "qd")) {
-- 
2.9.3


-- 
Darren Hart
Intel Open Source Technology Center

[PATCH] platform/x86: thinkpad_acpi: Initialize local in_tablet_mode

[Darren Hart]

linux-next reported in_tablet_mode may be used uninitialized after:

b31800283868 ("platform/x86: thinkpad_acpi: Move tablet detection into separate 
function")

This turns out to be a false positive as the pr_info call cannot be
reached if tp_features.hotkey_tablet (global scope) is 0, and
in_tablet_mode is assigned in both places tp_features.hotkey_tablet is
assigned.

Regardless, to make it explicit and avoid further reports, initialize
in_tablet_mode to 0.

Signed-off-by: Darren Hart 
Cc: Lyude 
Cc: Henrique de Moraes Holschuh 
Cc: Andy Shevchenko 
---
 drivers/platform/x86/thinkpad_acpi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/platform/x86/thinkpad_acpi.c 
b/drivers/platform/x86/thinkpad_acpi.c
index 69cb0da..1c5a6e2 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -3143,7 +3143,7 @@ typedef tpacpi_keymap_entry_t 
tpacpi_keymap_t[TPACPI_HOTKEY_MAP_LEN];
 
 static int hotkey_init_tablet_mode(void)
 {
-   int in_tablet_mode, res;
+   int in_tablet_mode = 0, res;
char *type;
 
if (acpi_evalf(hkey_handle, , "MHKG", "qd")) {
-- 
2.9.3


-- 
Darren Hart
Intel Open Source Technology Center

[PATCH perf/core REBASE 5/5] samples/bpf: Move open_raw_sock to separate header

[Joe Stringer]

This function was declared in libbpf.c and was the only remaining
function in this library, but has nothing to do with BPF. Shift it out
into a new header, sock_example.h, and include it from the relevant
samples.

Signed-off-by: Joe Stringer 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Wang Nan 
Link: http://lkml.kernel.org/r/20161209024620.31660-8-...@ovn.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 samples/bpf/Makefile | 2 +-
 samples/bpf/fds_example.c| 1 +
 samples/bpf/libbpf.h | 3 ---
 samples/bpf/sock_example.c   | 1 +
 samples/bpf/{libbpf.c => sock_example.h} | 3 +--
 samples/bpf/sockex1_user.c   | 1 +
 samples/bpf/sockex2_user.c   | 1 +
 samples/bpf/sockex3_user.c   | 1 +
 8 files changed, 7 insertions(+), 6 deletions(-)
 rename samples/bpf/{libbpf.c => sock_example.h} (92%)

diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 9718f664fedf..c9496fb98ba1 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -36,7 +36,7 @@ hostprogs-y += lwt_len_hist
 hostprogs-y += xdp_tx_iptunnel
 
 # Libbpf dependencies
-LIBBPF := libbpf.o ../../tools/lib/bpf/bpf.o
+LIBBPF := ../../tools/lib/bpf/bpf.o
 
 test_lru_dist-objs := test_lru_dist.o $(LIBBPF)
 sock_example-objs := sock_example.o $(LIBBPF)
diff --git a/samples/bpf/fds_example.c b/samples/bpf/fds_example.c
index 8a4fc4ef3993..f8080dbc8356 100644
--- a/samples/bpf/fds_example.c
+++ b/samples/bpf/fds_example.c
@@ -14,6 +14,7 @@
 
 #include "bpf_load.h"
 #include "libbpf.h"
+#include "sock_example.h"
 
 #define BPF_F_PIN  (1 << 0)
 #define BPF_F_GET  (1 << 1)
diff --git a/samples/bpf/libbpf.h b/samples/bpf/libbpf.h
index 09aedc320009..3705fba453a0 100644
--- a/samples/bpf/libbpf.h
+++ b/samples/bpf/libbpf.h
@@ -185,7 +185,4 @@ struct bpf_insn;
.off   = 0, \
.imm   = 0 })
 
-/* create RAW socket and bind to interface 'name' */
-int open_raw_sock(const char *name);
-
 #endif
diff --git a/samples/bpf/sock_example.c b/samples/bpf/sock_example.c
index d6b91e9a38ad..682ffb1e8c1a 100644
--- a/samples/bpf/sock_example.c
+++ b/samples/bpf/sock_example.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include "libbpf.h"
+#include "sock_example.h"
 
 char bpf_log_buf[BPF_LOG_BUF_SIZE];
 
diff --git a/samples/bpf/libbpf.c b/samples/bpf/sock_example.h
similarity index 92%
rename from samples/bpf/libbpf.c
rename to samples/bpf/sock_example.h
index bee473a494f1..09f7fe7e5fd7 100644
--- a/samples/bpf/libbpf.c
+++ b/samples/bpf/sock_example.h
@@ -1,4 +1,3 @@
-/* eBPF mini library */
 #include 
 #include 
 #include 
@@ -11,7 +10,7 @@
 #include 
 #include "libbpf.h"
 
-int open_raw_sock(const char *name)
+static inline int open_raw_sock(const char *name)
 {
struct sockaddr_ll sll;
int sock;
diff --git a/samples/bpf/sockex1_user.c b/samples/bpf/sockex1_user.c
index 9454448bf198..6cd2feb3e9b3 100644
--- a/samples/bpf/sockex1_user.c
+++ b/samples/bpf/sockex1_user.c
@@ -3,6 +3,7 @@
 #include 
 #include "libbpf.h"
 #include "bpf_load.h"
+#include "sock_example.h"
 #include 
 #include 
 
diff --git a/samples/bpf/sockex2_user.c b/samples/bpf/sockex2_user.c
index 6a40600d5a83..0e0207c90841 100644
--- a/samples/bpf/sockex2_user.c
+++ b/samples/bpf/sockex2_user.c
@@ -3,6 +3,7 @@
 #include 
 #include "libbpf.h"
 #include "bpf_load.h"
+#include "sock_example.h"
 #include 
 #include 
 #include 
diff --git a/samples/bpf/sockex3_user.c b/samples/bpf/sockex3_user.c
index 9099c4255f23..b5524d417eb5 100644
--- a/samples/bpf/sockex3_user.c
+++ b/samples/bpf/sockex3_user.c
@@ -3,6 +3,7 @@
 #include 
 #include "libbpf.h"
 #include "bpf_load.h"
+#include "sock_example.h"
 #include 
 #include 
 #include 
-- 
2.10.2

[PATCH perf/core REBASE 5/5] samples/bpf: Move open_raw_sock to separate header

[Joe Stringer]

This function was declared in libbpf.c and was the only remaining
function in this library, but has nothing to do with BPF. Shift it out
into a new header, sock_example.h, and include it from the relevant
samples.

Signed-off-by: Joe Stringer 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Wang Nan 
Link: http://lkml.kernel.org/r/20161209024620.31660-8-...@ovn.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 samples/bpf/Makefile | 2 +-
 samples/bpf/fds_example.c| 1 +
 samples/bpf/libbpf.h | 3 ---
 samples/bpf/sock_example.c   | 1 +
 samples/bpf/{libbpf.c => sock_example.h} | 3 +--
 samples/bpf/sockex1_user.c   | 1 +
 samples/bpf/sockex2_user.c   | 1 +
 samples/bpf/sockex3_user.c   | 1 +
 8 files changed, 7 insertions(+), 6 deletions(-)
 rename samples/bpf/{libbpf.c => sock_example.h} (92%)

diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index 9718f664fedf..c9496fb98ba1 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -36,7 +36,7 @@ hostprogs-y += lwt_len_hist
 hostprogs-y += xdp_tx_iptunnel
 
 # Libbpf dependencies
-LIBBPF := libbpf.o ../../tools/lib/bpf/bpf.o
+LIBBPF := ../../tools/lib/bpf/bpf.o
 
 test_lru_dist-objs := test_lru_dist.o $(LIBBPF)
 sock_example-objs := sock_example.o $(LIBBPF)
diff --git a/samples/bpf/fds_example.c b/samples/bpf/fds_example.c
index 8a4fc4ef3993..f8080dbc8356 100644
--- a/samples/bpf/fds_example.c
+++ b/samples/bpf/fds_example.c
@@ -14,6 +14,7 @@
 
 #include "bpf_load.h"
 #include "libbpf.h"
+#include "sock_example.h"
 
 #define BPF_F_PIN  (1 << 0)
 #define BPF_F_GET  (1 << 1)
diff --git a/samples/bpf/libbpf.h b/samples/bpf/libbpf.h
index 09aedc320009..3705fba453a0 100644
--- a/samples/bpf/libbpf.h
+++ b/samples/bpf/libbpf.h
@@ -185,7 +185,4 @@ struct bpf_insn;
.off   = 0, \
.imm   = 0 })
 
-/* create RAW socket and bind to interface 'name' */
-int open_raw_sock(const char *name);
-
 #endif
diff --git a/samples/bpf/sock_example.c b/samples/bpf/sock_example.c
index d6b91e9a38ad..682ffb1e8c1a 100644
--- a/samples/bpf/sock_example.c
+++ b/samples/bpf/sock_example.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include "libbpf.h"
+#include "sock_example.h"
 
 char bpf_log_buf[BPF_LOG_BUF_SIZE];
 
diff --git a/samples/bpf/libbpf.c b/samples/bpf/sock_example.h
similarity index 92%
rename from samples/bpf/libbpf.c
rename to samples/bpf/sock_example.h
index bee473a494f1..09f7fe7e5fd7 100644
--- a/samples/bpf/libbpf.c
+++ b/samples/bpf/sock_example.h
@@ -1,4 +1,3 @@
-/* eBPF mini library */
 #include 
 #include 
 #include 
@@ -11,7 +10,7 @@
 #include 
 #include "libbpf.h"
 
-int open_raw_sock(const char *name)
+static inline int open_raw_sock(const char *name)
 {
struct sockaddr_ll sll;
int sock;
diff --git a/samples/bpf/sockex1_user.c b/samples/bpf/sockex1_user.c
index 9454448bf198..6cd2feb3e9b3 100644
--- a/samples/bpf/sockex1_user.c
+++ b/samples/bpf/sockex1_user.c
@@ -3,6 +3,7 @@
 #include 
 #include "libbpf.h"
 #include "bpf_load.h"
+#include "sock_example.h"
 #include 
 #include 
 
diff --git a/samples/bpf/sockex2_user.c b/samples/bpf/sockex2_user.c
index 6a40600d5a83..0e0207c90841 100644
--- a/samples/bpf/sockex2_user.c
+++ b/samples/bpf/sockex2_user.c
@@ -3,6 +3,7 @@
 #include 
 #include "libbpf.h"
 #include "bpf_load.h"
+#include "sock_example.h"
 #include 
 #include 
 #include 
diff --git a/samples/bpf/sockex3_user.c b/samples/bpf/sockex3_user.c
index 9099c4255f23..b5524d417eb5 100644
--- a/samples/bpf/sockex3_user.c
+++ b/samples/bpf/sockex3_user.c
@@ -3,6 +3,7 @@
 #include 
 #include "libbpf.h"
 #include "bpf_load.h"
+#include "sock_example.h"
 #include 
 #include 
 #include 
-- 
2.10.2

[PATCH perf/core REBASE 4/5] samples/bpf: Remove perf_event_open() declaration

[Joe Stringer]

This declaration was made in samples/bpf/libbpf.c for convenience, but
there's already one in tools/perf/perf-sys.h. Reuse that one.

Committer notes:

Testing it:

  $ make -j4 O=../build/v4.9.0-rc8+ samples/bpf/
  make[1]: Entering directory '/home/build/v4.9.0-rc8+'
CHK include/config/kernel.release
GEN ./Makefile
CHK include/generated/uapi/linux/version.h
Using /home/acme/git/linux as source for kernel
CHK include/generated/utsrelease.h
CHK include/generated/timeconst.h
CHK include/generated/bounds.h
CHK include/generated/asm-offsets.h
CALL/home/acme/git/linux/scripts/checksyscalls.sh
HOSTCC  samples/bpf/test_verifier.o
HOSTCC  samples/bpf/libbpf.o
HOSTCC  samples/bpf/../../tools/lib/bpf/bpf.o
HOSTCC  samples/bpf/test_maps.o
HOSTCC  samples/bpf/sock_example.o
HOSTCC  samples/bpf/bpf_load.o

HOSTLD  samples/bpf/trace_event
HOSTLD  samples/bpf/sampleip
HOSTLD  samples/bpf/tc_l2_redirect
  make[1]: Leaving directory '/home/build/v4.9.0-rc8+'
  $

Signed-off-by: Joe Stringer 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Wang Nan 
Link: http://lkml.kernel.org/r/20161209024620.31660-7-...@ovn.org
[ Use -I$(srctree)/tools/lib/ to support out of source code tree builds ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 samples/bpf/Makefile| 2 ++
 samples/bpf/bpf_load.c  | 3 ++-
 samples/bpf/libbpf.c| 7 ---
 samples/bpf/libbpf.h| 3 ---
 samples/bpf/sampleip_user.c | 3 ++-
 samples/bpf/trace_event_user.c  | 9 +
 samples/bpf/trace_output_user.c | 3 ++-
 samples/bpf/tracex6_user.c  | 3 ++-
 8 files changed, 15 insertions(+), 18 deletions(-)

diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index add514e2984a..9718f664fedf 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -108,6 +108,8 @@ always += xdp_tx_iptunnel_kern.o
 
 HOSTCFLAGS += -I$(objtree)/usr/include
 HOSTCFLAGS += -I$(srctree)/tools/testing/selftests/bpf/
+HOSTCFLAGS += -I$(srctree)/tools/lib/ -I$(srctree)/tools/include
+HOSTCFLAGS += -I$(srctree)/tools/perf
 
 HOSTCFLAGS_bpf_load.o += -I$(objtree)/usr/include -Wno-unused-variable
 HOSTLOADLIBES_fds_example += -lelf
diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
index f5b186c46b7c..982c3be702d7 100644
--- a/samples/bpf/bpf_load.c
+++ b/samples/bpf/bpf_load.c
@@ -23,6 +23,7 @@
 #include 
 #include "libbpf.h"
 #include "bpf_load.h"
+#include "perf-sys.h"
 
 #define DEBUGFS "/sys/kernel/debug/tracing/"
 
@@ -178,7 +179,7 @@ static int load_and_attach(const char *event, struct 
bpf_insn *prog, int size)
id = atoi(buf);
attr.config = id;
 
-   efd = perf_event_open(, -1/*pid*/, 0/*cpu*/, -1/*group_fd*/, 0);
+   efd = sys_perf_event_open(, -1/*pid*/, 0/*cpu*/, -1/*group_fd*/, 
0);
if (efd < 0) {
printf("event %d fd %d err %s\n", id, efd, strerror(errno));
return -1;
diff --git a/samples/bpf/libbpf.c b/samples/bpf/libbpf.c
index d9af876b4a2c..bee473a494f1 100644
--- a/samples/bpf/libbpf.c
+++ b/samples/bpf/libbpf.c
@@ -34,10 +34,3 @@ int open_raw_sock(const char *name)
 
return sock;
 }
-
-int perf_event_open(struct perf_event_attr *attr, int pid, int cpu,
-   int group_fd, unsigned long flags)
-{
-   return syscall(__NR_perf_event_open, attr, pid, cpu,
-  group_fd, flags);
-}
diff --git a/samples/bpf/libbpf.h b/samples/bpf/libbpf.h
index cc815624aacf..09aedc320009 100644
--- a/samples/bpf/libbpf.h
+++ b/samples/bpf/libbpf.h
@@ -188,7 +188,4 @@ struct bpf_insn;
 /* create RAW socket and bind to interface 'name' */
 int open_raw_sock(const char *name);
 
-struct perf_event_attr;
-int perf_event_open(struct perf_event_attr *attr, int pid, int cpu,
-   int group_fd, unsigned long flags);
 #endif
diff --git a/samples/bpf/sampleip_user.c b/samples/bpf/sampleip_user.c
index 5ac5adf75931..be59d7dcbdde 100644
--- a/samples/bpf/sampleip_user.c
+++ b/samples/bpf/sampleip_user.c
@@ -21,6 +21,7 @@
 #include 
 #include "libbpf.h"
 #include "bpf_load.h"
+#include "perf-sys.h"
 
 #define DEFAULT_FREQ   99
 #define DEFAULT_SECS   5
@@ -49,7 +50,7 @@ static int sampling_start(int *pmu_fd, int freq)
};
 
for (i = 0; i < nr_cpus; i++) {
-   pmu_fd[i] = perf_event_open(_sample_attr, -1 /* pid */, i,
+   pmu_fd[i] = sys_perf_event_open(_sample_attr, -1 /* pid */, 
i,
-1 /* group_fd */, 0 /* flags */);
if (pmu_fd[i] < 0) {
fprintf(stderr, "ERROR: Initializing perf sampling\n");
diff --git a/samples/bpf/trace_event_user.c b/samples/bpf/trace_event_user.c
index 704fe9fa77b2..0c5561d193a4 100644
--- a/samples/bpf/trace_event_user.c
+++ 

[PATCH perf/core REBASE 4/5] samples/bpf: Remove perf_event_open() declaration

[Joe Stringer]

This declaration was made in samples/bpf/libbpf.c for convenience, but
there's already one in tools/perf/perf-sys.h. Reuse that one.

Committer notes:

Testing it:

  $ make -j4 O=../build/v4.9.0-rc8+ samples/bpf/
  make[1]: Entering directory '/home/build/v4.9.0-rc8+'
CHK include/config/kernel.release
GEN ./Makefile
CHK include/generated/uapi/linux/version.h
Using /home/acme/git/linux as source for kernel
CHK include/generated/utsrelease.h
CHK include/generated/timeconst.h
CHK include/generated/bounds.h
CHK include/generated/asm-offsets.h
CALL/home/acme/git/linux/scripts/checksyscalls.sh
HOSTCC  samples/bpf/test_verifier.o
HOSTCC  samples/bpf/libbpf.o
HOSTCC  samples/bpf/../../tools/lib/bpf/bpf.o
HOSTCC  samples/bpf/test_maps.o
HOSTCC  samples/bpf/sock_example.o
HOSTCC  samples/bpf/bpf_load.o

HOSTLD  samples/bpf/trace_event
HOSTLD  samples/bpf/sampleip
HOSTLD  samples/bpf/tc_l2_redirect
  make[1]: Leaving directory '/home/build/v4.9.0-rc8+'
  $

Signed-off-by: Joe Stringer 
Tested-by: Arnaldo Carvalho de Melo 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Wang Nan 
Link: http://lkml.kernel.org/r/20161209024620.31660-7-...@ovn.org
[ Use -I$(srctree)/tools/lib/ to support out of source code tree builds ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 samples/bpf/Makefile| 2 ++
 samples/bpf/bpf_load.c  | 3 ++-
 samples/bpf/libbpf.c| 7 ---
 samples/bpf/libbpf.h| 3 ---
 samples/bpf/sampleip_user.c | 3 ++-
 samples/bpf/trace_event_user.c  | 9 +
 samples/bpf/trace_output_user.c | 3 ++-
 samples/bpf/tracex6_user.c  | 3 ++-
 8 files changed, 15 insertions(+), 18 deletions(-)

diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index add514e2984a..9718f664fedf 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -108,6 +108,8 @@ always += xdp_tx_iptunnel_kern.o
 
 HOSTCFLAGS += -I$(objtree)/usr/include
 HOSTCFLAGS += -I$(srctree)/tools/testing/selftests/bpf/
+HOSTCFLAGS += -I$(srctree)/tools/lib/ -I$(srctree)/tools/include
+HOSTCFLAGS += -I$(srctree)/tools/perf
 
 HOSTCFLAGS_bpf_load.o += -I$(objtree)/usr/include -Wno-unused-variable
 HOSTLOADLIBES_fds_example += -lelf
diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
index f5b186c46b7c..982c3be702d7 100644
--- a/samples/bpf/bpf_load.c
+++ b/samples/bpf/bpf_load.c
@@ -23,6 +23,7 @@
 #include 
 #include "libbpf.h"
 #include "bpf_load.h"
+#include "perf-sys.h"
 
 #define DEBUGFS "/sys/kernel/debug/tracing/"
 
@@ -178,7 +179,7 @@ static int load_and_attach(const char *event, struct 
bpf_insn *prog, int size)
id = atoi(buf);
attr.config = id;
 
-   efd = perf_event_open(, -1/*pid*/, 0/*cpu*/, -1/*group_fd*/, 0);
+   efd = sys_perf_event_open(, -1/*pid*/, 0/*cpu*/, -1/*group_fd*/, 
0);
if (efd < 0) {
printf("event %d fd %d err %s\n", id, efd, strerror(errno));
return -1;
diff --git a/samples/bpf/libbpf.c b/samples/bpf/libbpf.c
index d9af876b4a2c..bee473a494f1 100644
--- a/samples/bpf/libbpf.c
+++ b/samples/bpf/libbpf.c
@@ -34,10 +34,3 @@ int open_raw_sock(const char *name)
 
return sock;
 }
-
-int perf_event_open(struct perf_event_attr *attr, int pid, int cpu,
-   int group_fd, unsigned long flags)
-{
-   return syscall(__NR_perf_event_open, attr, pid, cpu,
-  group_fd, flags);
-}
diff --git a/samples/bpf/libbpf.h b/samples/bpf/libbpf.h
index cc815624aacf..09aedc320009 100644
--- a/samples/bpf/libbpf.h
+++ b/samples/bpf/libbpf.h
@@ -188,7 +188,4 @@ struct bpf_insn;
 /* create RAW socket and bind to interface 'name' */
 int open_raw_sock(const char *name);
 
-struct perf_event_attr;
-int perf_event_open(struct perf_event_attr *attr, int pid, int cpu,
-   int group_fd, unsigned long flags);
 #endif
diff --git a/samples/bpf/sampleip_user.c b/samples/bpf/sampleip_user.c
index 5ac5adf75931..be59d7dcbdde 100644
--- a/samples/bpf/sampleip_user.c
+++ b/samples/bpf/sampleip_user.c
@@ -21,6 +21,7 @@
 #include 
 #include "libbpf.h"
 #include "bpf_load.h"
+#include "perf-sys.h"
 
 #define DEFAULT_FREQ   99
 #define DEFAULT_SECS   5
@@ -49,7 +50,7 @@ static int sampling_start(int *pmu_fd, int freq)
};
 
for (i = 0; i < nr_cpus; i++) {
-   pmu_fd[i] = perf_event_open(_sample_attr, -1 /* pid */, i,
+   pmu_fd[i] = sys_perf_event_open(_sample_attr, -1 /* pid */, 
i,
-1 /* group_fd */, 0 /* flags */);
if (pmu_fd[i] < 0) {
fprintf(stderr, "ERROR: Initializing perf sampling\n");
diff --git a/samples/bpf/trace_event_user.c b/samples/bpf/trace_event_user.c
index 704fe9fa77b2..0c5561d193a4 100644
--- a/samples/bpf/trace_event_user.c
+++ b/samples/bpf/trace_event_user.c
@@ -20,6 +20,7 @@
 #include 
 #include "libbpf.h"
 #include "bpf_load.h"

[PATCH perf/core REBASE 3/5] tools lib bpf: Add bpf_prog_{attach,detach}

[Joe Stringer]

Commit d8c5b17f2bc0 ("samples: bpf: add userspace example for attaching
eBPF programs to cgroups") added these functions to samples/libbpf, but
during this merge all of the samples libbpf functionality is shifting to
tools/lib/bpf. Shift these functions there.

Signed-off-by: Joe Stringer 
---
Arnaldo, this is a new patch you didn't previously review which I've
prepared due to the conflict with net-next. I figured it's better to try
to get samples/bpf properly switched over this window rather than defer the
problem and end up having to deal with another merge problem next time
around. I hope that is fine for you. If not, this patch onwards will need
to be dropped

It's a simple copy/paste/delete with a minor change for sys_bpf() vs
syscall().
---
 samples/bpf/libbpf.c | 21 -
 samples/bpf/libbpf.h |  3 ---
 tools/lib/bpf/bpf.c  | 21 +
 tools/lib/bpf/bpf.h  |  3 +++
 4 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/samples/bpf/libbpf.c b/samples/bpf/libbpf.c
index 3391225ad7e9..d9af876b4a2c 100644
--- a/samples/bpf/libbpf.c
+++ b/samples/bpf/libbpf.c
@@ -11,27 +11,6 @@
 #include 
 #include "libbpf.h"
 
-int bpf_prog_attach(int prog_fd, int target_fd, enum bpf_attach_type type)
-{
-   union bpf_attr attr = {
-   .target_fd = target_fd,
-   .attach_bpf_fd = prog_fd,
-   .attach_type = type,
-   };
-
-   return syscall(__NR_bpf, BPF_PROG_ATTACH, , sizeof(attr));
-}
-
-int bpf_prog_detach(int target_fd, enum bpf_attach_type type)
-{
-   union bpf_attr attr = {
-   .target_fd = target_fd,
-   .attach_type = type,
-   };
-
-   return syscall(__NR_bpf, BPF_PROG_DETACH, , sizeof(attr));
-}
-
 int open_raw_sock(const char *name)
 {
struct sockaddr_ll sll;
diff --git a/samples/bpf/libbpf.h b/samples/bpf/libbpf.h
index cf7d2386d1f9..cc815624aacf 100644
--- a/samples/bpf/libbpf.h
+++ b/samples/bpf/libbpf.h
@@ -6,9 +6,6 @@
 
 struct bpf_insn;
 
-int bpf_prog_attach(int prog_fd, int attachable_fd, enum bpf_attach_type type);
-int bpf_prog_detach(int attachable_fd, enum bpf_attach_type type);
-
 /* ALU ops on registers, bpf_add|sub|...: dst_reg += src_reg */
 
 #define BPF_ALU64_REG(OP, DST, SRC)\
diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index d0afb26c2e0f..e19335df0d3a 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -167,3 +167,24 @@ int bpf_obj_get(const char *pathname)
 
return sys_bpf(BPF_OBJ_GET, , sizeof(attr));
 }
+
+int bpf_prog_attach(int prog_fd, int target_fd, enum bpf_attach_type type)
+{
+   union bpf_attr attr = {
+   .target_fd = target_fd,
+   .attach_bpf_fd = prog_fd,
+   .attach_type = type,
+   };
+
+   return sys_bpf(BPF_PROG_ATTACH, , sizeof(attr));
+}
+
+int bpf_prog_detach(int target_fd, enum bpf_attach_type type)
+{
+   union bpf_attr attr = {
+   .target_fd = target_fd,
+   .attach_type = type,
+   };
+
+   return sys_bpf(BPF_PROG_DETACH, , sizeof(attr));
+}
diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
index 7fcdce16fd62..a2f9853dd882 100644
--- a/tools/lib/bpf/bpf.h
+++ b/tools/lib/bpf/bpf.h
@@ -41,5 +41,8 @@ int bpf_map_delete_elem(int fd, void *key);
 int bpf_map_get_next_key(int fd, void *key, void *next_key);
 int bpf_obj_pin(int fd, const char *pathname);
 int bpf_obj_get(const char *pathname);
+int bpf_prog_attach(int prog_fd, int attachable_fd, enum bpf_attach_type type);
+int bpf_prog_detach(int attachable_fd, enum bpf_attach_type type);
+
 
 #endif
-- 
2.10.2

[PATCH perf/core REBASE 3/5] tools lib bpf: Add bpf_prog_{attach,detach}

[Joe Stringer]

Commit d8c5b17f2bc0 ("samples: bpf: add userspace example for attaching
eBPF programs to cgroups") added these functions to samples/libbpf, but
during this merge all of the samples libbpf functionality is shifting to
tools/lib/bpf. Shift these functions there.

Signed-off-by: Joe Stringer 
---
Arnaldo, this is a new patch you didn't previously review which I've
prepared due to the conflict with net-next. I figured it's better to try
to get samples/bpf properly switched over this window rather than defer the
problem and end up having to deal with another merge problem next time
around. I hope that is fine for you. If not, this patch onwards will need
to be dropped

It's a simple copy/paste/delete with a minor change for sys_bpf() vs
syscall().
---
 samples/bpf/libbpf.c | 21 -
 samples/bpf/libbpf.h |  3 ---
 tools/lib/bpf/bpf.c  | 21 +
 tools/lib/bpf/bpf.h  |  3 +++
 4 files changed, 24 insertions(+), 24 deletions(-)

diff --git a/samples/bpf/libbpf.c b/samples/bpf/libbpf.c
index 3391225ad7e9..d9af876b4a2c 100644
--- a/samples/bpf/libbpf.c
+++ b/samples/bpf/libbpf.c
@@ -11,27 +11,6 @@
 #include 
 #include "libbpf.h"
 
-int bpf_prog_attach(int prog_fd, int target_fd, enum bpf_attach_type type)
-{
-   union bpf_attr attr = {
-   .target_fd = target_fd,
-   .attach_bpf_fd = prog_fd,
-   .attach_type = type,
-   };
-
-   return syscall(__NR_bpf, BPF_PROG_ATTACH, , sizeof(attr));
-}
-
-int bpf_prog_detach(int target_fd, enum bpf_attach_type type)
-{
-   union bpf_attr attr = {
-   .target_fd = target_fd,
-   .attach_type = type,
-   };
-
-   return syscall(__NR_bpf, BPF_PROG_DETACH, , sizeof(attr));
-}
-
 int open_raw_sock(const char *name)
 {
struct sockaddr_ll sll;
diff --git a/samples/bpf/libbpf.h b/samples/bpf/libbpf.h
index cf7d2386d1f9..cc815624aacf 100644
--- a/samples/bpf/libbpf.h
+++ b/samples/bpf/libbpf.h
@@ -6,9 +6,6 @@
 
 struct bpf_insn;
 
-int bpf_prog_attach(int prog_fd, int attachable_fd, enum bpf_attach_type type);
-int bpf_prog_detach(int attachable_fd, enum bpf_attach_type type);
-
 /* ALU ops on registers, bpf_add|sub|...: dst_reg += src_reg */
 
 #define BPF_ALU64_REG(OP, DST, SRC)\
diff --git a/tools/lib/bpf/bpf.c b/tools/lib/bpf/bpf.c
index d0afb26c2e0f..e19335df0d3a 100644
--- a/tools/lib/bpf/bpf.c
+++ b/tools/lib/bpf/bpf.c
@@ -167,3 +167,24 @@ int bpf_obj_get(const char *pathname)
 
return sys_bpf(BPF_OBJ_GET, , sizeof(attr));
 }
+
+int bpf_prog_attach(int prog_fd, int target_fd, enum bpf_attach_type type)
+{
+   union bpf_attr attr = {
+   .target_fd = target_fd,
+   .attach_bpf_fd = prog_fd,
+   .attach_type = type,
+   };
+
+   return sys_bpf(BPF_PROG_ATTACH, , sizeof(attr));
+}
+
+int bpf_prog_detach(int target_fd, enum bpf_attach_type type)
+{
+   union bpf_attr attr = {
+   .target_fd = target_fd,
+   .attach_type = type,
+   };
+
+   return sys_bpf(BPF_PROG_DETACH, , sizeof(attr));
+}
diff --git a/tools/lib/bpf/bpf.h b/tools/lib/bpf/bpf.h
index 7fcdce16fd62..a2f9853dd882 100644
--- a/tools/lib/bpf/bpf.h
+++ b/tools/lib/bpf/bpf.h
@@ -41,5 +41,8 @@ int bpf_map_delete_elem(int fd, void *key);
 int bpf_map_get_next_key(int fd, void *key, void *next_key);
 int bpf_obj_pin(int fd, const char *pathname);
 int bpf_obj_get(const char *pathname);
+int bpf_prog_attach(int prog_fd, int attachable_fd, enum bpf_attach_type type);
+int bpf_prog_detach(int attachable_fd, enum bpf_attach_type type);
+
 
 #endif
-- 
2.10.2

[PATCH perf/core REBASE 1/5] samples/bpf: Make samples more libbpf-centric

[Joe Stringer]

Switch all of the sample code to use the function names from
tools/lib/bpf so that they're consistent with that, and to declare their
own log buffers. This allow the next commit to be purely devoted to
getting rid of the duplicate library in samples/bpf.

Signed-off-by: Joe Stringer 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Wang Nan 
Link: http://lkml.kernel.org/r/20161209024620.31660-5-...@ovn.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 samples/bpf/bpf_load.c| 17 +---
 samples/bpf/bpf_load.h|  3 +++
 samples/bpf/fds_example.c |  9 ---
 samples/bpf/lathist_user.c|  2 +-
 samples/bpf/libbpf.c  | 23 
 samples/bpf/libbpf.h  | 18 ++---
 samples/bpf/lwt_len_hist_user.c   |  6 +++--
 samples/bpf/offwaketime_user.c|  8 +++---
 samples/bpf/sampleip_user.c   |  4 +--
 samples/bpf/sock_example.c| 12 +
 samples/bpf/sockex1_user.c|  6 ++---
 samples/bpf/sockex2_user.c|  4 +--
 samples/bpf/sockex3_user.c|  4 +--
 samples/bpf/spintest_user.c   |  8 +++---
 samples/bpf/tc_l2_redirect_user.c |  4 +--
 samples/bpf/test_cgrp2_array_pin.c|  4 +--
 samples/bpf/test_cgrp2_attach.c   | 11 +---
 samples/bpf/test_cgrp2_attach2.c  |  7 +++--
 samples/bpf/test_cgrp2_sock.c |  6 +++--
 samples/bpf/test_current_task_under_cgroup_user.c |  8 +++---
 samples/bpf/test_lru_dist.c   | 32 +++
 samples/bpf/test_probe_write_user_user.c  |  2 +-
 samples/bpf/trace_event_user.c| 14 +-
 samples/bpf/trace_output_user.c   |  2 +-
 samples/bpf/tracex2_user.c| 10 +++
 samples/bpf/tracex3_user.c|  4 +--
 samples/bpf/tracex4_user.c|  4 +--
 samples/bpf/tracex6_user.c|  2 +-
 samples/bpf/xdp1_user.c   |  2 +-
 samples/bpf/xdp_tx_iptunnel_user.c|  6 ++---
 30 files changed, 133 insertions(+), 109 deletions(-)

diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
index e30b6de94f2e..f5b186c46b7c 100644
--- a/samples/bpf/bpf_load.c
+++ b/samples/bpf/bpf_load.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include "libbpf.h"
-#include "bpf_helpers.h"
 #include "bpf_load.h"
 
 #define DEBUGFS "/sys/kernel/debug/tracing/"
@@ -30,17 +29,26 @@
 static char license[128];
 static int kern_version;
 static bool processed_sec[128];
+char bpf_log_buf[BPF_LOG_BUF_SIZE];
 int map_fd[MAX_MAPS];
 int prog_fd[MAX_PROGS];
 int event_fd[MAX_PROGS];
 int prog_cnt;
 int prog_array_fd = -1;
 
+struct bpf_map_def {
+   unsigned int type;
+   unsigned int key_size;
+   unsigned int value_size;
+   unsigned int max_entries;
+   unsigned int map_flags;
+};
+
 static int populate_prog_array(const char *event, int prog_fd)
 {
int ind = atoi(event), err;
 
-   err = bpf_update_elem(prog_array_fd, , _fd, BPF_ANY);
+   err = bpf_map_update_elem(prog_array_fd, , _fd, BPF_ANY);
if (err < 0) {
printf("failed to store prog_fd in prog_array\n");
return -1;
@@ -87,9 +95,10 @@ static int load_and_attach(const char *event, struct 
bpf_insn *prog, int size)
return -1;
}
 
-   fd = bpf_prog_load(prog_type, prog, size, license, kern_version);
+   fd = bpf_load_program(prog_type, prog, size, license, kern_version,
+ bpf_log_buf, BPF_LOG_BUF_SIZE);
if (fd < 0) {
-   printf("bpf_prog_load() err=%d\n%s", errno, bpf_log_buf);
+   printf("bpf_load_program() err=%d\n%s", errno, bpf_log_buf);
return -1;
}
 
diff --git a/samples/bpf/bpf_load.h b/samples/bpf/bpf_load.h
index fb46a421ab41..c827827299b3 100644
--- a/samples/bpf/bpf_load.h
+++ b/samples/bpf/bpf_load.h
@@ -1,12 +1,15 @@
 #ifndef __BPF_LOAD_H
 #define __BPF_LOAD_H
 
+#include "libbpf.h"
+
 #define MAX_MAPS 32
 #define MAX_PROGS 32
 
 extern int map_fd[MAX_MAPS];
 extern int prog_fd[MAX_PROGS];
 extern int event_fd[MAX_PROGS];
+extern char bpf_log_buf[BPF_LOG_BUF_SIZE];
 extern int prog_cnt;
 
 /* parses elf file compiled by llvm .c->.o
diff --git a/samples/bpf/fds_example.c b/samples/bpf/fds_example.c
index 625e797be6ef..8a4fc4ef3993 100644
--- a/samples/bpf/fds_example.c
+++ b/samples/bpf/fds_example.c
@@ -58,8 +58,9 @@ static int bpf_prog_create(const char *object)
assert(!load_bpf_file((char *)object));
return prog_fd[0];
} 

[PATCH perf/core REBASE 1/5] samples/bpf: Make samples more libbpf-centric

[Joe Stringer]

Switch all of the sample code to use the function names from
tools/lib/bpf so that they're consistent with that, and to declare their
own log buffers. This allow the next commit to be purely devoted to
getting rid of the duplicate library in samples/bpf.

Signed-off-by: Joe Stringer 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Wang Nan 
Link: http://lkml.kernel.org/r/20161209024620.31660-5-...@ovn.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 samples/bpf/bpf_load.c| 17 +---
 samples/bpf/bpf_load.h|  3 +++
 samples/bpf/fds_example.c |  9 ---
 samples/bpf/lathist_user.c|  2 +-
 samples/bpf/libbpf.c  | 23 
 samples/bpf/libbpf.h  | 18 ++---
 samples/bpf/lwt_len_hist_user.c   |  6 +++--
 samples/bpf/offwaketime_user.c|  8 +++---
 samples/bpf/sampleip_user.c   |  4 +--
 samples/bpf/sock_example.c| 12 +
 samples/bpf/sockex1_user.c|  6 ++---
 samples/bpf/sockex2_user.c|  4 +--
 samples/bpf/sockex3_user.c|  4 +--
 samples/bpf/spintest_user.c   |  8 +++---
 samples/bpf/tc_l2_redirect_user.c |  4 +--
 samples/bpf/test_cgrp2_array_pin.c|  4 +--
 samples/bpf/test_cgrp2_attach.c   | 11 +---
 samples/bpf/test_cgrp2_attach2.c  |  7 +++--
 samples/bpf/test_cgrp2_sock.c |  6 +++--
 samples/bpf/test_current_task_under_cgroup_user.c |  8 +++---
 samples/bpf/test_lru_dist.c   | 32 +++
 samples/bpf/test_probe_write_user_user.c  |  2 +-
 samples/bpf/trace_event_user.c| 14 +-
 samples/bpf/trace_output_user.c   |  2 +-
 samples/bpf/tracex2_user.c| 10 +++
 samples/bpf/tracex3_user.c|  4 +--
 samples/bpf/tracex4_user.c|  4 +--
 samples/bpf/tracex6_user.c|  2 +-
 samples/bpf/xdp1_user.c   |  2 +-
 samples/bpf/xdp_tx_iptunnel_user.c|  6 ++---
 30 files changed, 133 insertions(+), 109 deletions(-)

diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
index e30b6de94f2e..f5b186c46b7c 100644
--- a/samples/bpf/bpf_load.c
+++ b/samples/bpf/bpf_load.c
@@ -22,7 +22,6 @@
 #include 
 #include 
 #include "libbpf.h"
-#include "bpf_helpers.h"
 #include "bpf_load.h"
 
 #define DEBUGFS "/sys/kernel/debug/tracing/"
@@ -30,17 +29,26 @@
 static char license[128];
 static int kern_version;
 static bool processed_sec[128];
+char bpf_log_buf[BPF_LOG_BUF_SIZE];
 int map_fd[MAX_MAPS];
 int prog_fd[MAX_PROGS];
 int event_fd[MAX_PROGS];
 int prog_cnt;
 int prog_array_fd = -1;
 
+struct bpf_map_def {
+   unsigned int type;
+   unsigned int key_size;
+   unsigned int value_size;
+   unsigned int max_entries;
+   unsigned int map_flags;
+};
+
 static int populate_prog_array(const char *event, int prog_fd)
 {
int ind = atoi(event), err;
 
-   err = bpf_update_elem(prog_array_fd, , _fd, BPF_ANY);
+   err = bpf_map_update_elem(prog_array_fd, , _fd, BPF_ANY);
if (err < 0) {
printf("failed to store prog_fd in prog_array\n");
return -1;
@@ -87,9 +95,10 @@ static int load_and_attach(const char *event, struct 
bpf_insn *prog, int size)
return -1;
}
 
-   fd = bpf_prog_load(prog_type, prog, size, license, kern_version);
+   fd = bpf_load_program(prog_type, prog, size, license, kern_version,
+ bpf_log_buf, BPF_LOG_BUF_SIZE);
if (fd < 0) {
-   printf("bpf_prog_load() err=%d\n%s", errno, bpf_log_buf);
+   printf("bpf_load_program() err=%d\n%s", errno, bpf_log_buf);
return -1;
}
 
diff --git a/samples/bpf/bpf_load.h b/samples/bpf/bpf_load.h
index fb46a421ab41..c827827299b3 100644
--- a/samples/bpf/bpf_load.h
+++ b/samples/bpf/bpf_load.h
@@ -1,12 +1,15 @@
 #ifndef __BPF_LOAD_H
 #define __BPF_LOAD_H
 
+#include "libbpf.h"
+
 #define MAX_MAPS 32
 #define MAX_PROGS 32
 
 extern int map_fd[MAX_MAPS];
 extern int prog_fd[MAX_PROGS];
 extern int event_fd[MAX_PROGS];
+extern char bpf_log_buf[BPF_LOG_BUF_SIZE];
 extern int prog_cnt;
 
 /* parses elf file compiled by llvm .c->.o
diff --git a/samples/bpf/fds_example.c b/samples/bpf/fds_example.c
index 625e797be6ef..8a4fc4ef3993 100644
--- a/samples/bpf/fds_example.c
+++ b/samples/bpf/fds_example.c
@@ -58,8 +58,9 @@ static int bpf_prog_create(const char *object)
assert(!load_bpf_file((char *)object));
return prog_fd[0];
} else {
-   return bpf_prog_load(BPF_PROG_TYPE_SOCKET_FILTER,
-  

Re: [PATCH] vfio/pci: Support error recovery

[Michael S. Tsirkin]

On Wed, Dec 14, 2016 at 03:47:43PM -0700, Alex Williamson wrote:
> On Thu, 15 Dec 2016 00:20:20 +0200
> "Michael S. Tsirkin"  wrote:
> 
> > On Tue, Dec 13, 2016 at 08:00:22PM -0700, Alex Williamson wrote:
> > > On Wed, 14 Dec 2016 03:58:17 +0200
> > > "Michael S. Tsirkin"  wrote:
> > >   
> > > > On Tue, Dec 13, 2016 at 09:27:59AM -0700, Alex Williamson wrote:  
> > > > > On Tue, 13 Dec 2016 18:12:34 +0200
> > > > > "Michael S. Tsirkin"  wrote:
> > > > > 
> > > > > > On Mon, Dec 12, 2016 at 08:39:48PM -0700, Alex Williamson wrote:
> > > > > > > On Tue, 13 Dec 2016 05:15:13 +0200
> > > > > > > "Michael S. Tsirkin"  wrote:
> > > > > > >   
> > > > > > > > On Mon, Dec 12, 2016 at 03:43:13PM -0700, Alex Williamson 
> > > > > > > > wrote:  
> > > > > > > > > > So just don't do it then. Topology must match between host 
> > > > > > > > > > and guest,
> > > > > > > > > > except maybe for the case of devices with host driver  
> > > > > > > > > > (e.g. PF)
> > > > > > > > > > which we might be able to synchronize against.
> > > > > > > > > 
> > > > > > > > > We're talking about host kernel level handling here.  The 
> > > > > > > > > host kernel
> > > > > > > > > cannot defer the link reset to the user under the assumption 
> > > > > > > > > that the
> > > > > > > > > user is handling the devices in a very specific way.  The 
> > > > > > > > > moment we do
> > > > > > > > > that, we've lost.
> > > > > > > > 
> > > > > > > > The way is same as baremetal though, so why not?  
> > > > > > > 
> > > > > > > How do we know this?  What if the user is dpdk?  The kernel is
> > > > > > > responsible for maintaining the integrity of the system and 
> > > > > > > devices,
> > > > > > > not the user.
> > > > > > >   
> > > > > > > > And if user doesn't do what's expected, we can
> > > > > > > > do the full link reset on close.  
> > > > > > > 
> > > > > > > That's exactly my point, if we're talking about multiple devices,
> > > > > > > there's no guarantee that the close() for each is simultaneous.  
> > > > > > > If one
> > > > > > > function is released before the other we cannot do a bus reset.  
> > > > > > > If
> > > > > > > that device is then opened by another user before its sibling is
> > > > > > > released, then we once again cannot perform a link reset.  I don't
> > > > > > > think it would be reasonable to mark the released device 
> > > > > > > quarantined
> > > > > > > until the sibling is released, that would be a terrible user 
> > > > > > > experience.  
> > > > > > 
> > > > > > Not sure why you find it so terrible, and I don't think there's 
> > > > > > another way.
> > > > > 
> > > > > If we can't do it without regressing the support we currently have,
> > > > > let's not do it at all.
> > > > 
> > > > Why would we regress?  As long as there are no unrecoverable errors,
> > > > there's no need to change behaviour at all.  
> > > 
> > > Currently if a fatal error occurs we allow the host to reset the
> > > device, so to the best of our knowledge, the device is always reset.
> > > The proposal here allows gaps where we assume a particular guest
> > > behavior that allows the device to be returned to the host or opened by
> > > other users without that reset.  Any plan that relies on a specific
> > > user behavior is fundamentally wrong imo.
> > >   
> > > > Alex, do you have a picture of how error recovery can work in your mind?
> > > > Your answers seem to imply you do, and these patches don't implement
> > > > this correctly.  I'm not sure about others, but I for one am unable to
> > > > piece it together from the comments you provide.  If yes, could you
> > > > maybe do a short writeup of an architecture you would be comfortable
> > > > with?  
> > > 
> > > Clearly I have issues with this skip-the-host-reset plan, I don't think
> > > it works.  We cannot assume the user will do error recovery.  
> > 
> > Absolutely but we can defer recovery until device close.
> 
> No we can't, as I've tried to describe multiple times, if the functions
> are part of separate groups then they can be opened and closed
> asynchronously from each other and we may not have an opportunity where
> they are all closed together to perform a reset.
> The only option I can
> see for this is to quarantine the device, which as I've stated seems
> like a really poor solution.
> 
> > Possibly with userspace invoking an ioctl requesting this,
> > to make sure we don't break any legacy setups.
> 
> And how do we know that user is not malicious?  How do we police
> whether they actually perform a reset?  We can only track whether a
> reset has occurred, which leads back to the quarantine scenario.

I don't really know what do you call the quarantine scenario.
Malicious users get non working devices.
Why is this poor? 


> > >  As I
> > > stated previously we should enable the user to do error recovery
> > > without 

Re: [PATCH] vfio/pci: Support error recovery

[Michael S. Tsirkin]

On Wed, Dec 14, 2016 at 03:47:43PM -0700, Alex Williamson wrote:
> On Thu, 15 Dec 2016 00:20:20 +0200
> "Michael S. Tsirkin"  wrote:
> 
> > On Tue, Dec 13, 2016 at 08:00:22PM -0700, Alex Williamson wrote:
> > > On Wed, 14 Dec 2016 03:58:17 +0200
> > > "Michael S. Tsirkin"  wrote:
> > >   
> > > > On Tue, Dec 13, 2016 at 09:27:59AM -0700, Alex Williamson wrote:  
> > > > > On Tue, 13 Dec 2016 18:12:34 +0200
> > > > > "Michael S. Tsirkin"  wrote:
> > > > > 
> > > > > > On Mon, Dec 12, 2016 at 08:39:48PM -0700, Alex Williamson wrote:
> > > > > > > On Tue, 13 Dec 2016 05:15:13 +0200
> > > > > > > "Michael S. Tsirkin"  wrote:
> > > > > > >   
> > > > > > > > On Mon, Dec 12, 2016 at 03:43:13PM -0700, Alex Williamson 
> > > > > > > > wrote:  
> > > > > > > > > > So just don't do it then. Topology must match between host 
> > > > > > > > > > and guest,
> > > > > > > > > > except maybe for the case of devices with host driver  
> > > > > > > > > > (e.g. PF)
> > > > > > > > > > which we might be able to synchronize against.
> > > > > > > > > 
> > > > > > > > > We're talking about host kernel level handling here.  The 
> > > > > > > > > host kernel
> > > > > > > > > cannot defer the link reset to the user under the assumption 
> > > > > > > > > that the
> > > > > > > > > user is handling the devices in a very specific way.  The 
> > > > > > > > > moment we do
> > > > > > > > > that, we've lost.
> > > > > > > > 
> > > > > > > > The way is same as baremetal though, so why not?  
> > > > > > > 
> > > > > > > How do we know this?  What if the user is dpdk?  The kernel is
> > > > > > > responsible for maintaining the integrity of the system and 
> > > > > > > devices,
> > > > > > > not the user.
> > > > > > >   
> > > > > > > > And if user doesn't do what's expected, we can
> > > > > > > > do the full link reset on close.  
> > > > > > > 
> > > > > > > That's exactly my point, if we're talking about multiple devices,
> > > > > > > there's no guarantee that the close() for each is simultaneous.  
> > > > > > > If one
> > > > > > > function is released before the other we cannot do a bus reset.  
> > > > > > > If
> > > > > > > that device is then opened by another user before its sibling is
> > > > > > > released, then we once again cannot perform a link reset.  I don't
> > > > > > > think it would be reasonable to mark the released device 
> > > > > > > quarantined
> > > > > > > until the sibling is released, that would be a terrible user 
> > > > > > > experience.  
> > > > > > 
> > > > > > Not sure why you find it so terrible, and I don't think there's 
> > > > > > another way.
> > > > > 
> > > > > If we can't do it without regressing the support we currently have,
> > > > > let's not do it at all.
> > > > 
> > > > Why would we regress?  As long as there are no unrecoverable errors,
> > > > there's no need to change behaviour at all.  
> > > 
> > > Currently if a fatal error occurs we allow the host to reset the
> > > device, so to the best of our knowledge, the device is always reset.
> > > The proposal here allows gaps where we assume a particular guest
> > > behavior that allows the device to be returned to the host or opened by
> > > other users without that reset.  Any plan that relies on a specific
> > > user behavior is fundamentally wrong imo.
> > >   
> > > > Alex, do you have a picture of how error recovery can work in your mind?
> > > > Your answers seem to imply you do, and these patches don't implement
> > > > this correctly.  I'm not sure about others, but I for one am unable to
> > > > piece it together from the comments you provide.  If yes, could you
> > > > maybe do a short writeup of an architecture you would be comfortable
> > > > with?  
> > > 
> > > Clearly I have issues with this skip-the-host-reset plan, I don't think
> > > it works.  We cannot assume the user will do error recovery.  
> > 
> > Absolutely but we can defer recovery until device close.
> 
> No we can't, as I've tried to describe multiple times, if the functions
> are part of separate groups then they can be opened and closed
> asynchronously from each other and we may not have an opportunity where
> they are all closed together to perform a reset.
> The only option I can
> see for this is to quarantine the device, which as I've stated seems
> like a really poor solution.
> 
> > Possibly with userspace invoking an ioctl requesting this,
> > to make sure we don't break any legacy setups.
> 
> And how do we know that user is not malicious?  How do we police
> whether they actually perform a reset?  We can only track whether a
> reset has occurred, which leads back to the quarantine scenario.

I don't really know what do you call the quarantine scenario.
Malicious users get non working devices.
Why is this poor? 


> > >  As I
> > > stated previously we should enable the user to do error recovery
> > > without depending on the user to do error recovery.  I'm a bit lost why
> > > 

[PATCH perf/core REBASE 2/5] samples/bpf: Switch over to libbpf

[Joe Stringer]

Now that libbpf under tools/lib/bpf/* is synced with the version from
samples/bpf, we can get rid most of the libbpf library here.

Signed-off-by: Joe Stringer 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Wang Nan 
Link: http://lkml.kernel.org/r/20161209024620.31660-6-...@ovn.org
[ Use -I$(srctree)/tools/lib/ to support out of source code tree builds, as 
noticed by Wang Nan ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 samples/bpf/Makefile   |  67 +++--
 samples/bpf/README.rst |   4 +-
 samples/bpf/libbpf.c   | 111 -
 samples/bpf/libbpf.h   |  19 +
 4 files changed, 39 insertions(+), 162 deletions(-)

diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index f2219c1489e5..add514e2984a 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -35,40 +35,43 @@ hostprogs-y += tc_l2_redirect
 hostprogs-y += lwt_len_hist
 hostprogs-y += xdp_tx_iptunnel
 
-test_lru_dist-objs := test_lru_dist.o libbpf.o
-sock_example-objs := sock_example.o libbpf.o
-fds_example-objs := bpf_load.o libbpf.o fds_example.o
-sockex1-objs := bpf_load.o libbpf.o sockex1_user.o
-sockex2-objs := bpf_load.o libbpf.o sockex2_user.o
-sockex3-objs := bpf_load.o libbpf.o sockex3_user.o
-tracex1-objs := bpf_load.o libbpf.o tracex1_user.o
-tracex2-objs := bpf_load.o libbpf.o tracex2_user.o
-tracex3-objs := bpf_load.o libbpf.o tracex3_user.o
-tracex4-objs := bpf_load.o libbpf.o tracex4_user.o
-tracex5-objs := bpf_load.o libbpf.o tracex5_user.o
-tracex6-objs := bpf_load.o libbpf.o tracex6_user.o
-test_probe_write_user-objs := bpf_load.o libbpf.o test_probe_write_user_user.o
-trace_output-objs := bpf_load.o libbpf.o trace_output_user.o
-lathist-objs := bpf_load.o libbpf.o lathist_user.o
-offwaketime-objs := bpf_load.o libbpf.o offwaketime_user.o
-spintest-objs := bpf_load.o libbpf.o spintest_user.o
-map_perf_test-objs := bpf_load.o libbpf.o map_perf_test_user.o
-test_overhead-objs := bpf_load.o libbpf.o test_overhead_user.o
-test_cgrp2_array_pin-objs := libbpf.o test_cgrp2_array_pin.o
-test_cgrp2_attach-objs := libbpf.o test_cgrp2_attach.o
-test_cgrp2_attach2-objs := libbpf.o test_cgrp2_attach2.o cgroup_helpers.o
-test_cgrp2_sock-objs := libbpf.o test_cgrp2_sock.o
-test_cgrp2_sock2-objs := bpf_load.o libbpf.o test_cgrp2_sock2.o
-xdp1-objs := bpf_load.o libbpf.o xdp1_user.o
+# Libbpf dependencies
+LIBBPF := libbpf.o ../../tools/lib/bpf/bpf.o
+
+test_lru_dist-objs := test_lru_dist.o $(LIBBPF)
+sock_example-objs := sock_example.o $(LIBBPF)
+fds_example-objs := bpf_load.o $(LIBBPF) fds_example.o
+sockex1-objs := bpf_load.o $(LIBBPF) sockex1_user.o
+sockex2-objs := bpf_load.o $(LIBBPF) sockex2_user.o
+sockex3-objs := bpf_load.o $(LIBBPF) sockex3_user.o
+tracex1-objs := bpf_load.o $(LIBBPF) tracex1_user.o
+tracex2-objs := bpf_load.o $(LIBBPF) tracex2_user.o
+tracex3-objs := bpf_load.o $(LIBBPF) tracex3_user.o
+tracex4-objs := bpf_load.o $(LIBBPF) tracex4_user.o
+tracex5-objs := bpf_load.o $(LIBBPF) tracex5_user.o
+tracex6-objs := bpf_load.o $(LIBBPF) tracex6_user.o
+test_probe_write_user-objs := bpf_load.o $(LIBBPF) test_probe_write_user_user.o
+trace_output-objs := bpf_load.o $(LIBBPF) trace_output_user.o
+lathist-objs := bpf_load.o $(LIBBPF) lathist_user.o
+offwaketime-objs := bpf_load.o $(LIBBPF) offwaketime_user.o
+spintest-objs := bpf_load.o $(LIBBPF) spintest_user.o
+map_perf_test-objs := bpf_load.o $(LIBBPF) map_perf_test_user.o
+test_overhead-objs := bpf_load.o $(LIBBPF) test_overhead_user.o
+test_cgrp2_array_pin-objs := $(LIBBPF) test_cgrp2_array_pin.o
+test_cgrp2_attach-objs := $(LIBBPF) test_cgrp2_attach.o
+test_cgrp2_attach2-objs := $(LIBBPF) test_cgrp2_attach2.o cgroup_helpers.o
+test_cgrp2_sock-objs := $(LIBBPF) test_cgrp2_sock.o
+test_cgrp2_sock2-objs := bpf_load.o $(LIBBPF) test_cgrp2_sock2.o
+xdp1-objs := bpf_load.o $(LIBBPF) xdp1_user.o
 # reuse xdp1 source intentionally
-xdp2-objs := bpf_load.o libbpf.o xdp1_user.o
-test_current_task_under_cgroup-objs := bpf_load.o libbpf.o cgroup_helpers.o \
+xdp2-objs := bpf_load.o $(LIBBPF) xdp1_user.o
+test_current_task_under_cgroup-objs := bpf_load.o $(LIBBPF) cgroup_helpers.o \
   test_current_task_under_cgroup_user.o
-trace_event-objs := bpf_load.o libbpf.o trace_event_user.o
-sampleip-objs := bpf_load.o libbpf.o sampleip_user.o
-tc_l2_redirect-objs := bpf_load.o libbpf.o tc_l2_redirect_user.o
-lwt_len_hist-objs := bpf_load.o libbpf.o lwt_len_hist_user.o
-xdp_tx_iptunnel-objs := bpf_load.o libbpf.o xdp_tx_iptunnel_user.o
+trace_event-objs := bpf_load.o $(LIBBPF) trace_event_user.o
+sampleip-objs := bpf_load.o $(LIBBPF) sampleip_user.o
+tc_l2_redirect-objs := bpf_load.o $(LIBBPF) tc_l2_redirect_user.o
+lwt_len_hist-objs := bpf_load.o $(LIBBPF) lwt_len_hist_user.o
+xdp_tx_iptunnel-objs := bpf_load.o $(LIBBPF) xdp_tx_iptunnel_user.o
 
 # Tell kbuild to always build the programs
 

Re: linux-next: build warning after merge of the drivers-x86 tree

[Darren Hart]

On Wed, Dec 14, 2016 at 02:21:38PM -0800, Darren Hart wrote:
> On Wed, Dec 14, 2016 at 01:50:44PM +1100, Stephen Rothwell wrote:
> > Hi Darren,
> > 
> > After merging the drivers-x86 tree, today's linux-next build (x86_64
> > allmodconfig) produced this warning:
> > 
> > In file included from include/linux/kernel.h:13:0,
> >  from drivers/platform/x86/thinkpad_acpi.c:52:
> > drivers/platform/x86/thinkpad_acpi.c: In function 'hotkey_init':
> > include/linux/printk.h:299:2: warning: 'type' may be used uninitialized in 
> > this function [-Wmaybe-uninitialized]
> >   printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
> >   ^
> > drivers/platform/x86/thinkpad_acpi.c:3147:8: note: 'type' was declared here
> >   char *type;
> > ^
> > In file included from include/linux/kernel.h:13:0,
> >  from drivers/platform/x86/thinkpad_acpi.c:52:
> > include/linux/printk.h:299:2: warning: 'in_tablet_mode' may be used 
> > uninitialized in this function [-Wmaybe-uninitialized]
> >   printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
> >   ^
> > drivers/platform/x86/thinkpad_acpi.c:3146:6: note: 'in_tablet_mode' was 
> > declared here
> >   int in_tablet_mode, res;
> >   ^
> > 
> > Introduced by commit
> > 
> >   b31800283868 ("platform/x86: thinkpad_acpi: Move tablet detection into 
> > separate function")
> > 
> > I can't tell if this is a false positive or not.
> 
> That's an uninitialized local variable. Not sure how I missed that. I'll
> fix it up today. Thank you for the report.

OK, no, it's a false positive because tp_features.hotkey_tablet is assigned in
both places where in_tablet_mode is assigned, and if the former is 0 (global
scope), the function returns without calling pr_info.

Lyude, Henrique, please confirm.

Regardless, I'll add a patch to init in_tablet_mode to 0 so it is explicit - but
will not rebase as it isn't technically an error.

-- 
Darren Hart
Intel Open Source Technology Center

[PATCH perf/core REBASE 2/5] samples/bpf: Switch over to libbpf

[Joe Stringer]

Now that libbpf under tools/lib/bpf/* is synced with the version from
samples/bpf, we can get rid most of the libbpf library here.

Signed-off-by: Joe Stringer 
Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Wang Nan 
Link: http://lkml.kernel.org/r/20161209024620.31660-6-...@ovn.org
[ Use -I$(srctree)/tools/lib/ to support out of source code tree builds, as 
noticed by Wang Nan ]
Signed-off-by: Arnaldo Carvalho de Melo 
---
 samples/bpf/Makefile   |  67 +++--
 samples/bpf/README.rst |   4 +-
 samples/bpf/libbpf.c   | 111 -
 samples/bpf/libbpf.h   |  19 +
 4 files changed, 39 insertions(+), 162 deletions(-)

diff --git a/samples/bpf/Makefile b/samples/bpf/Makefile
index f2219c1489e5..add514e2984a 100644
--- a/samples/bpf/Makefile
+++ b/samples/bpf/Makefile
@@ -35,40 +35,43 @@ hostprogs-y += tc_l2_redirect
 hostprogs-y += lwt_len_hist
 hostprogs-y += xdp_tx_iptunnel
 
-test_lru_dist-objs := test_lru_dist.o libbpf.o
-sock_example-objs := sock_example.o libbpf.o
-fds_example-objs := bpf_load.o libbpf.o fds_example.o
-sockex1-objs := bpf_load.o libbpf.o sockex1_user.o
-sockex2-objs := bpf_load.o libbpf.o sockex2_user.o
-sockex3-objs := bpf_load.o libbpf.o sockex3_user.o
-tracex1-objs := bpf_load.o libbpf.o tracex1_user.o
-tracex2-objs := bpf_load.o libbpf.o tracex2_user.o
-tracex3-objs := bpf_load.o libbpf.o tracex3_user.o
-tracex4-objs := bpf_load.o libbpf.o tracex4_user.o
-tracex5-objs := bpf_load.o libbpf.o tracex5_user.o
-tracex6-objs := bpf_load.o libbpf.o tracex6_user.o
-test_probe_write_user-objs := bpf_load.o libbpf.o test_probe_write_user_user.o
-trace_output-objs := bpf_load.o libbpf.o trace_output_user.o
-lathist-objs := bpf_load.o libbpf.o lathist_user.o
-offwaketime-objs := bpf_load.o libbpf.o offwaketime_user.o
-spintest-objs := bpf_load.o libbpf.o spintest_user.o
-map_perf_test-objs := bpf_load.o libbpf.o map_perf_test_user.o
-test_overhead-objs := bpf_load.o libbpf.o test_overhead_user.o
-test_cgrp2_array_pin-objs := libbpf.o test_cgrp2_array_pin.o
-test_cgrp2_attach-objs := libbpf.o test_cgrp2_attach.o
-test_cgrp2_attach2-objs := libbpf.o test_cgrp2_attach2.o cgroup_helpers.o
-test_cgrp2_sock-objs := libbpf.o test_cgrp2_sock.o
-test_cgrp2_sock2-objs := bpf_load.o libbpf.o test_cgrp2_sock2.o
-xdp1-objs := bpf_load.o libbpf.o xdp1_user.o
+# Libbpf dependencies
+LIBBPF := libbpf.o ../../tools/lib/bpf/bpf.o
+
+test_lru_dist-objs := test_lru_dist.o $(LIBBPF)
+sock_example-objs := sock_example.o $(LIBBPF)
+fds_example-objs := bpf_load.o $(LIBBPF) fds_example.o
+sockex1-objs := bpf_load.o $(LIBBPF) sockex1_user.o
+sockex2-objs := bpf_load.o $(LIBBPF) sockex2_user.o
+sockex3-objs := bpf_load.o $(LIBBPF) sockex3_user.o
+tracex1-objs := bpf_load.o $(LIBBPF) tracex1_user.o
+tracex2-objs := bpf_load.o $(LIBBPF) tracex2_user.o
+tracex3-objs := bpf_load.o $(LIBBPF) tracex3_user.o
+tracex4-objs := bpf_load.o $(LIBBPF) tracex4_user.o
+tracex5-objs := bpf_load.o $(LIBBPF) tracex5_user.o
+tracex6-objs := bpf_load.o $(LIBBPF) tracex6_user.o
+test_probe_write_user-objs := bpf_load.o $(LIBBPF) test_probe_write_user_user.o
+trace_output-objs := bpf_load.o $(LIBBPF) trace_output_user.o
+lathist-objs := bpf_load.o $(LIBBPF) lathist_user.o
+offwaketime-objs := bpf_load.o $(LIBBPF) offwaketime_user.o
+spintest-objs := bpf_load.o $(LIBBPF) spintest_user.o
+map_perf_test-objs := bpf_load.o $(LIBBPF) map_perf_test_user.o
+test_overhead-objs := bpf_load.o $(LIBBPF) test_overhead_user.o
+test_cgrp2_array_pin-objs := $(LIBBPF) test_cgrp2_array_pin.o
+test_cgrp2_attach-objs := $(LIBBPF) test_cgrp2_attach.o
+test_cgrp2_attach2-objs := $(LIBBPF) test_cgrp2_attach2.o cgroup_helpers.o
+test_cgrp2_sock-objs := $(LIBBPF) test_cgrp2_sock.o
+test_cgrp2_sock2-objs := bpf_load.o $(LIBBPF) test_cgrp2_sock2.o
+xdp1-objs := bpf_load.o $(LIBBPF) xdp1_user.o
 # reuse xdp1 source intentionally
-xdp2-objs := bpf_load.o libbpf.o xdp1_user.o
-test_current_task_under_cgroup-objs := bpf_load.o libbpf.o cgroup_helpers.o \
+xdp2-objs := bpf_load.o $(LIBBPF) xdp1_user.o
+test_current_task_under_cgroup-objs := bpf_load.o $(LIBBPF) cgroup_helpers.o \
   test_current_task_under_cgroup_user.o
-trace_event-objs := bpf_load.o libbpf.o trace_event_user.o
-sampleip-objs := bpf_load.o libbpf.o sampleip_user.o
-tc_l2_redirect-objs := bpf_load.o libbpf.o tc_l2_redirect_user.o
-lwt_len_hist-objs := bpf_load.o libbpf.o lwt_len_hist_user.o
-xdp_tx_iptunnel-objs := bpf_load.o libbpf.o xdp_tx_iptunnel_user.o
+trace_event-objs := bpf_load.o $(LIBBPF) trace_event_user.o
+sampleip-objs := bpf_load.o $(LIBBPF) sampleip_user.o
+tc_l2_redirect-objs := bpf_load.o $(LIBBPF) tc_l2_redirect_user.o
+lwt_len_hist-objs := bpf_load.o $(LIBBPF) lwt_len_hist_user.o
+xdp_tx_iptunnel-objs := bpf_load.o $(LIBBPF) xdp_tx_iptunnel_user.o
 
 # Tell kbuild to always build the programs
 always := $(hostprogs-y)
diff --git a/samples/bpf/README.rst b/samples/bpf/README.rst

Re: linux-next: build warning after merge of the drivers-x86 tree

[Darren Hart]

On Wed, Dec 14, 2016 at 02:21:38PM -0800, Darren Hart wrote:
> On Wed, Dec 14, 2016 at 01:50:44PM +1100, Stephen Rothwell wrote:
> > Hi Darren,
> > 
> > After merging the drivers-x86 tree, today's linux-next build (x86_64
> > allmodconfig) produced this warning:
> > 
> > In file included from include/linux/kernel.h:13:0,
> >  from drivers/platform/x86/thinkpad_acpi.c:52:
> > drivers/platform/x86/thinkpad_acpi.c: In function 'hotkey_init':
> > include/linux/printk.h:299:2: warning: 'type' may be used uninitialized in 
> > this function [-Wmaybe-uninitialized]
> >   printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
> >   ^
> > drivers/platform/x86/thinkpad_acpi.c:3147:8: note: 'type' was declared here
> >   char *type;
> > ^
> > In file included from include/linux/kernel.h:13:0,
> >  from drivers/platform/x86/thinkpad_acpi.c:52:
> > include/linux/printk.h:299:2: warning: 'in_tablet_mode' may be used 
> > uninitialized in this function [-Wmaybe-uninitialized]
> >   printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
> >   ^
> > drivers/platform/x86/thinkpad_acpi.c:3146:6: note: 'in_tablet_mode' was 
> > declared here
> >   int in_tablet_mode, res;
> >   ^
> > 
> > Introduced by commit
> > 
> >   b31800283868 ("platform/x86: thinkpad_acpi: Move tablet detection into 
> > separate function")
> > 
> > I can't tell if this is a false positive or not.
> 
> That's an uninitialized local variable. Not sure how I missed that. I'll
> fix it up today. Thank you for the report.

OK, no, it's a false positive because tp_features.hotkey_tablet is assigned in
both places where in_tablet_mode is assigned, and if the former is 0 (global
scope), the function returns without calling pr_info.

Lyude, Henrique, please confirm.

Regardless, I'll add a patch to init in_tablet_mode to 0 so it is explicit - but
will not rebase as it isn't technically an error.

-- 
Darren Hart
Intel Open Source Technology Center

[PATCH perf/core REBASE 0/5] Reuse libbpf from samples/bpf

[Joe Stringer]

Arnaldo, here's the refresh of this series that you requested after the merge
with net-next. It is based on commit 1f125a4aa4d8 ("tools lib bpf: Add flags
to bpf_create_map()") from perf/core today.

Patch #3 is new, but trivial. It has the biggest changes compared to the
version that you previously applied to perf/core.

---

Update tools/lib/bpf to provide the remaining bpf wrapper pieces needed by the
samples/bpf/ code, then get rid of all of the duplicate BPF libraries in
samples/bpf/libbpf.[ch].

---
REBASE: Rebased v3 that was applied to perf/core.
Resolved merge conflict with net-next.
New patch shifts bpf_prog_{attach,detach}() to libbpf.
Drop unnecessary build targets
Drop extra unneeded log buffers

v3: Add ack for first patch.
Split out second patch from v2 into separate changes for remaining diff.
Add patches to switch samples/bpf over to using tools/lib/.

(Was "libbpf: Synchronize implementations")
v2: Don't shift non-bpf code into libbpf.
Drop the patch to synchronize ELF definitions with tc.

v1: https://www.mail-archive.com/netdev@vger.kernel.org/msg135088.html
First post.


Joe Stringer (5):
  samples/bpf: Make samples more libbpf-centric
  samples/bpf: Switch over to libbpf
  tools lib bpf: Add bpf_prog_{attach,detach}
  samples/bpf: Remove perf_event_open() declaration
  samples/bpf: Move open_raw_sock to separate header

 samples/bpf/Makefile  |  69 +
 samples/bpf/README.rst|   4 +-
 samples/bpf/bpf_load.c|  20 ++-
 samples/bpf/bpf_load.h|   3 +
 samples/bpf/fds_example.c |  10 +-
 samples/bpf/lathist_user.c|   2 +-
 samples/bpf/libbpf.c  | 176 --
 samples/bpf/libbpf.h  |  28 +---
 samples/bpf/lwt_len_hist_user.c   |   6 +-
 samples/bpf/offwaketime_user.c|   8 +-
 samples/bpf/sampleip_user.c   |   7 +-
 samples/bpf/sock_example.c|  13 +-
 samples/bpf/sock_example.h|  35 +
 samples/bpf/sockex1_user.c|   7 +-
 samples/bpf/sockex2_user.c|   5 +-
 samples/bpf/sockex3_user.c|   5 +-
 samples/bpf/spintest_user.c   |   8 +-
 samples/bpf/tc_l2_redirect_user.c |   4 +-
 samples/bpf/test_cgrp2_array_pin.c|   4 +-
 samples/bpf/test_cgrp2_attach.c   |  11 +-
 samples/bpf/test_cgrp2_attach2.c  |   7 +-
 samples/bpf/test_cgrp2_sock.c |   6 +-
 samples/bpf/test_current_task_under_cgroup_user.c |   8 +-
 samples/bpf/test_lru_dist.c   |  32 ++--
 samples/bpf/test_probe_write_user_user.c  |   2 +-
 samples/bpf/trace_event_user.c|  23 +--
 samples/bpf/trace_output_user.c   |   5 +-
 samples/bpf/tracex2_user.c|  10 +-
 samples/bpf/tracex3_user.c|   4 +-
 samples/bpf/tracex4_user.c|   4 +-
 samples/bpf/tracex6_user.c|   5 +-
 samples/bpf/xdp1_user.c   |   2 +-
 samples/bpf/xdp_tx_iptunnel_user.c|   6 +-
 tools/lib/bpf/bpf.c   |  21 +++
 tools/lib/bpf/bpf.h   |   3 +
 35 files changed, 231 insertions(+), 332 deletions(-)
 delete mode 100644 samples/bpf/libbpf.c
 create mode 100644 samples/bpf/sock_example.h

-- 
2.10.2

[PATCH perf/core REBASE 0/5] Reuse libbpf from samples/bpf

[Joe Stringer]

Arnaldo, here's the refresh of this series that you requested after the merge
with net-next. It is based on commit 1f125a4aa4d8 ("tools lib bpf: Add flags
to bpf_create_map()") from perf/core today.

Patch #3 is new, but trivial. It has the biggest changes compared to the
version that you previously applied to perf/core.

---

Update tools/lib/bpf to provide the remaining bpf wrapper pieces needed by the
samples/bpf/ code, then get rid of all of the duplicate BPF libraries in
samples/bpf/libbpf.[ch].

---
REBASE: Rebased v3 that was applied to perf/core.
Resolved merge conflict with net-next.
New patch shifts bpf_prog_{attach,detach}() to libbpf.
Drop unnecessary build targets
Drop extra unneeded log buffers

v3: Add ack for first patch.
Split out second patch from v2 into separate changes for remaining diff.
Add patches to switch samples/bpf over to using tools/lib/.

(Was "libbpf: Synchronize implementations")
v2: Don't shift non-bpf code into libbpf.
Drop the patch to synchronize ELF definitions with tc.

v1: https://www.mail-archive.com/netdev@vger.kernel.org/msg135088.html
First post.


Joe Stringer (5):
  samples/bpf: Make samples more libbpf-centric
  samples/bpf: Switch over to libbpf
  tools lib bpf: Add bpf_prog_{attach,detach}
  samples/bpf: Remove perf_event_open() declaration
  samples/bpf: Move open_raw_sock to separate header

 samples/bpf/Makefile  |  69 +
 samples/bpf/README.rst|   4 +-
 samples/bpf/bpf_load.c|  20 ++-
 samples/bpf/bpf_load.h|   3 +
 samples/bpf/fds_example.c |  10 +-
 samples/bpf/lathist_user.c|   2 +-
 samples/bpf/libbpf.c  | 176 --
 samples/bpf/libbpf.h  |  28 +---
 samples/bpf/lwt_len_hist_user.c   |   6 +-
 samples/bpf/offwaketime_user.c|   8 +-
 samples/bpf/sampleip_user.c   |   7 +-
 samples/bpf/sock_example.c|  13 +-
 samples/bpf/sock_example.h|  35 +
 samples/bpf/sockex1_user.c|   7 +-
 samples/bpf/sockex2_user.c|   5 +-
 samples/bpf/sockex3_user.c|   5 +-
 samples/bpf/spintest_user.c   |   8 +-
 samples/bpf/tc_l2_redirect_user.c |   4 +-
 samples/bpf/test_cgrp2_array_pin.c|   4 +-
 samples/bpf/test_cgrp2_attach.c   |  11 +-
 samples/bpf/test_cgrp2_attach2.c  |   7 +-
 samples/bpf/test_cgrp2_sock.c |   6 +-
 samples/bpf/test_current_task_under_cgroup_user.c |   8 +-
 samples/bpf/test_lru_dist.c   |  32 ++--
 samples/bpf/test_probe_write_user_user.c  |   2 +-
 samples/bpf/trace_event_user.c|  23 +--
 samples/bpf/trace_output_user.c   |   5 +-
 samples/bpf/tracex2_user.c|  10 +-
 samples/bpf/tracex3_user.c|   4 +-
 samples/bpf/tracex4_user.c|   4 +-
 samples/bpf/tracex6_user.c|   5 +-
 samples/bpf/xdp1_user.c   |   2 +-
 samples/bpf/xdp_tx_iptunnel_user.c|   6 +-
 tools/lib/bpf/bpf.c   |  21 +++
 tools/lib/bpf/bpf.h   |   3 +
 35 files changed, 231 insertions(+), 332 deletions(-)
 delete mode 100644 samples/bpf/libbpf.c
 create mode 100644 samples/bpf/sock_example.h

-- 
2.10.2

Re: [PATCH] vfio/pci: Support error recovery

[Alex Williamson]

On Thu, 15 Dec 2016 00:20:20 +0200
"Michael S. Tsirkin"  wrote:

> On Tue, Dec 13, 2016 at 08:00:22PM -0700, Alex Williamson wrote:
> > On Wed, 14 Dec 2016 03:58:17 +0200
> > "Michael S. Tsirkin"  wrote:
> >   
> > > On Tue, Dec 13, 2016 at 09:27:59AM -0700, Alex Williamson wrote:  
> > > > On Tue, 13 Dec 2016 18:12:34 +0200
> > > > "Michael S. Tsirkin"  wrote:
> > > > 
> > > > > On Mon, Dec 12, 2016 at 08:39:48PM -0700, Alex Williamson wrote:
> > > > > > On Tue, 13 Dec 2016 05:15:13 +0200
> > > > > > "Michael S. Tsirkin"  wrote:
> > > > > >   
> > > > > > > On Mon, Dec 12, 2016 at 03:43:13PM -0700, Alex Williamson wrote:  
> > > > > > > 
> > > > > > > > > So just don't do it then. Topology must match between host 
> > > > > > > > > and guest,
> > > > > > > > > except maybe for the case of devices with host driver  (e.g. 
> > > > > > > > > PF)
> > > > > > > > > which we might be able to synchronize against.
> > > > > > > > 
> > > > > > > > We're talking about host kernel level handling here.  The host 
> > > > > > > > kernel
> > > > > > > > cannot defer the link reset to the user under the assumption 
> > > > > > > > that the
> > > > > > > > user is handling the devices in a very specific way.  The 
> > > > > > > > moment we do
> > > > > > > > that, we've lost.
> > > > > > > 
> > > > > > > The way is same as baremetal though, so why not?  
> > > > > > 
> > > > > > How do we know this?  What if the user is dpdk?  The kernel is
> > > > > > responsible for maintaining the integrity of the system and devices,
> > > > > > not the user.
> > > > > >   
> > > > > > > And if user doesn't do what's expected, we can
> > > > > > > do the full link reset on close.  
> > > > > > 
> > > > > > That's exactly my point, if we're talking about multiple devices,
> > > > > > there's no guarantee that the close() for each is simultaneous.  If 
> > > > > > one
> > > > > > function is released before the other we cannot do a bus reset.  If
> > > > > > that device is then opened by another user before its sibling is
> > > > > > released, then we once again cannot perform a link reset.  I don't
> > > > > > think it would be reasonable to mark the released device quarantined
> > > > > > until the sibling is released, that would be a terrible user 
> > > > > > experience.  
> > > > > 
> > > > > Not sure why you find it so terrible, and I don't think there's 
> > > > > another way.
> > > > 
> > > > If we can't do it without regressing the support we currently have,
> > > > let's not do it at all.
> > > 
> > > Why would we regress?  As long as there are no unrecoverable errors,
> > > there's no need to change behaviour at all.  
> > 
> > Currently if a fatal error occurs we allow the host to reset the
> > device, so to the best of our knowledge, the device is always reset.
> > The proposal here allows gaps where we assume a particular guest
> > behavior that allows the device to be returned to the host or opened by
> > other users without that reset.  Any plan that relies on a specific
> > user behavior is fundamentally wrong imo.
> >   
> > > Alex, do you have a picture of how error recovery can work in your mind?
> > > Your answers seem to imply you do, and these patches don't implement
> > > this correctly.  I'm not sure about others, but I for one am unable to
> > > piece it together from the comments you provide.  If yes, could you
> > > maybe do a short writeup of an architecture you would be comfortable
> > > with?  
> > 
> > Clearly I have issues with this skip-the-host-reset plan, I don't think
> > it works.  We cannot assume the user will do error recovery.  
> 
> Absolutely but we can defer recovery until device close.

No we can't, as I've tried to describe multiple times, if the functions
are part of separate groups then they can be opened and closed
asynchronously from each other and we may not have an opportunity where
they are all closed together to perform a reset.  The only option I can
see for this is to quarantine the device, which as I've stated seems
like a really poor solution.

> Possibly with userspace invoking an ioctl requesting this,
> to make sure we don't break any legacy setups.

And how do we know that user is not malicious?  How do we police
whether they actually perform a reset?  We can only track whether a
reset has occurred, which leads back to the quarantine scenario.

> >  As I
> > stated previously we should enable the user to do error recovery
> > without depending on the user to do error recovery.  I'm a bit lost why
> > we're focusing on this approach when the v9 approach of blocking user
> > access to the device during the host recovery seemed like a better
> > solution.  I don't think I've said anything bad about that approach,
> > but it does need further testing and debugging.  Nobody seems to be
> > interested in debugging why it wasn't quite working to understand
> 

Re: [PATCH] vfio/pci: Support error recovery

[Alex Williamson]

On Thu, 15 Dec 2016 00:20:20 +0200
"Michael S. Tsirkin"  wrote:

> On Tue, Dec 13, 2016 at 08:00:22PM -0700, Alex Williamson wrote:
> > On Wed, 14 Dec 2016 03:58:17 +0200
> > "Michael S. Tsirkin"  wrote:
> >   
> > > On Tue, Dec 13, 2016 at 09:27:59AM -0700, Alex Williamson wrote:  
> > > > On Tue, 13 Dec 2016 18:12:34 +0200
> > > > "Michael S. Tsirkin"  wrote:
> > > > 
> > > > > On Mon, Dec 12, 2016 at 08:39:48PM -0700, Alex Williamson wrote:
> > > > > > On Tue, 13 Dec 2016 05:15:13 +0200
> > > > > > "Michael S. Tsirkin"  wrote:
> > > > > >   
> > > > > > > On Mon, Dec 12, 2016 at 03:43:13PM -0700, Alex Williamson wrote:  
> > > > > > > 
> > > > > > > > > So just don't do it then. Topology must match between host 
> > > > > > > > > and guest,
> > > > > > > > > except maybe for the case of devices with host driver  (e.g. 
> > > > > > > > > PF)
> > > > > > > > > which we might be able to synchronize against.
> > > > > > > > 
> > > > > > > > We're talking about host kernel level handling here.  The host 
> > > > > > > > kernel
> > > > > > > > cannot defer the link reset to the user under the assumption 
> > > > > > > > that the
> > > > > > > > user is handling the devices in a very specific way.  The 
> > > > > > > > moment we do
> > > > > > > > that, we've lost.
> > > > > > > 
> > > > > > > The way is same as baremetal though, so why not?  
> > > > > > 
> > > > > > How do we know this?  What if the user is dpdk?  The kernel is
> > > > > > responsible for maintaining the integrity of the system and devices,
> > > > > > not the user.
> > > > > >   
> > > > > > > And if user doesn't do what's expected, we can
> > > > > > > do the full link reset on close.  
> > > > > > 
> > > > > > That's exactly my point, if we're talking about multiple devices,
> > > > > > there's no guarantee that the close() for each is simultaneous.  If 
> > > > > > one
> > > > > > function is released before the other we cannot do a bus reset.  If
> > > > > > that device is then opened by another user before its sibling is
> > > > > > released, then we once again cannot perform a link reset.  I don't
> > > > > > think it would be reasonable to mark the released device quarantined
> > > > > > until the sibling is released, that would be a terrible user 
> > > > > > experience.  
> > > > > 
> > > > > Not sure why you find it so terrible, and I don't think there's 
> > > > > another way.
> > > > 
> > > > If we can't do it without regressing the support we currently have,
> > > > let's not do it at all.
> > > 
> > > Why would we regress?  As long as there are no unrecoverable errors,
> > > there's no need to change behaviour at all.  
> > 
> > Currently if a fatal error occurs we allow the host to reset the
> > device, so to the best of our knowledge, the device is always reset.
> > The proposal here allows gaps where we assume a particular guest
> > behavior that allows the device to be returned to the host or opened by
> > other users without that reset.  Any plan that relies on a specific
> > user behavior is fundamentally wrong imo.
> >   
> > > Alex, do you have a picture of how error recovery can work in your mind?
> > > Your answers seem to imply you do, and these patches don't implement
> > > this correctly.  I'm not sure about others, but I for one am unable to
> > > piece it together from the comments you provide.  If yes, could you
> > > maybe do a short writeup of an architecture you would be comfortable
> > > with?  
> > 
> > Clearly I have issues with this skip-the-host-reset plan, I don't think
> > it works.  We cannot assume the user will do error recovery.  
> 
> Absolutely but we can defer recovery until device close.

No we can't, as I've tried to describe multiple times, if the functions
are part of separate groups then they can be opened and closed
asynchronously from each other and we may not have an opportunity where
they are all closed together to perform a reset.  The only option I can
see for this is to quarantine the device, which as I've stated seems
like a really poor solution.

> Possibly with userspace invoking an ioctl requesting this,
> to make sure we don't break any legacy setups.

And how do we know that user is not malicious?  How do we police
whether they actually perform a reset?  We can only track whether a
reset has occurred, which leads back to the quarantine scenario.

> >  As I
> > stated previously we should enable the user to do error recovery
> > without depending on the user to do error recovery.  I'm a bit lost why
> > we're focusing on this approach when the v9 approach of blocking user
> > access to the device during the host recovery seemed like a better
> > solution.  I don't think I've said anything bad about that approach,
> > but it does need further testing and debugging.  Nobody seems to be
> > interested in debugging why it wasn't quite working to understand
> > whether that was an implementation issue or a design issue. That's

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

[Jason A. Donenfeld]

Hey Tom,

On Wed, Dec 14, 2016 at 10:35 PM, Tom Herbert  wrote:
> Those look good, although I would probably just do 1,2,3 words and
> then have a function that takes n words like jhash. Might want to call
> these dword to distinguish from 32 bit words in jhash.

So actually jhash_Nwords makes no sense, since it takes dwords
(32-bits) not words (16-bits). The siphash analog should be called
siphash24_Nqwords.

I think what I'll do is change what I already have to:
siphash24_1qword
siphash24_2qword
siphash24_3qword
siphash24_4qword

And then add some static inline helpers to assist with smaller u32s
like ipv4 addresses called:

siphash24_2dword
siphash24_4dword
siphash24_6dword
siphash24_8dword

While we're having something new, might as well call it the right thing.


> Also, what is the significance of "24" in the function and constant
> names? Can we just drop that and call this siphash?

SipHash is actually a family of PRFs, differentiated by the number of
SIPROUNDs after each 64-bit input is processed and the number of
SIPROUNDs at the very end of the function. The best trade-off of speed
and security for kernel usage is 2 rounds after each 64-bit input and
4 rounds at the end of the function. This doesn't fall to any known
cryptanalysis and it's very fast.

Re: [PATCH v3 1/3] siphash: add cryptographically secure hashtable function

[Jason A. Donenfeld]

Hey Tom,

On Wed, Dec 14, 2016 at 10:35 PM, Tom Herbert  wrote:
> Those look good, although I would probably just do 1,2,3 words and
> then have a function that takes n words like jhash. Might want to call
> these dword to distinguish from 32 bit words in jhash.

So actually jhash_Nwords makes no sense, since it takes dwords
(32-bits) not words (16-bits). The siphash analog should be called
siphash24_Nqwords.

I think what I'll do is change what I already have to:
siphash24_1qword
siphash24_2qword
siphash24_3qword
siphash24_4qword

And then add some static inline helpers to assist with smaller u32s
like ipv4 addresses called:

siphash24_2dword
siphash24_4dword
siphash24_6dword
siphash24_8dword

While we're having something new, might as well call it the right thing.


> Also, what is the significance of "24" in the function and constant
> names? Can we just drop that and call this siphash?

SipHash is actually a family of PRFs, differentiated by the number of
SIPROUNDs after each 64-bit input is processed and the number of
SIPROUNDs at the very end of the function. The best trade-off of speed
and security for kernel usage is 2 rounds after each 64-bit input and
4 rounds at the end of the function. This doesn't fall to any known
cryptanalysis and it's very fast.

[GIT PULL] Block IO fixes for 4.10-rc1

[Jens Axboe]

Hi Linus,

A few fixes that I collected as post-merge. I was going to wait a bit
with sending this out, but the O_DIRECT fix should really go in sooner
rather than later.

Please pull!


  git://git.kernel.dk/linux-block.git for-linus



Andy Lutomirski (1):
  nvme/pci: Log PCI_STATUS when the controller dies

Gabriel Krisman Bertazi (2):
  blk-mq: Avoid memory reclaim when remapping queues
  blk-mq: Fix failed allocation path when mapping queues

NeilBrown (1):
  block_dev: don't test bdev->bd_contains when it is not stable

Shaohua Li (1):
  block_dev: don't update file access position for sync direct IO

 block/blk-mq.c  | 32 
 drivers/nvme/host/pci.c | 22 +++---
 fs/block_dev.c  |  7 ++-
 3 files changed, 45 insertions(+), 16 deletions(-)

-- 
Jens Axboe

[GIT PULL] Block IO fixes for 4.10-rc1

[Jens Axboe]

Hi Linus,

A few fixes that I collected as post-merge. I was going to wait a bit
with sending this out, but the O_DIRECT fix should really go in sooner
rather than later.

Please pull!


  git://git.kernel.dk/linux-block.git for-linus



Andy Lutomirski (1):
  nvme/pci: Log PCI_STATUS when the controller dies

Gabriel Krisman Bertazi (2):
  blk-mq: Avoid memory reclaim when remapping queues
  blk-mq: Fix failed allocation path when mapping queues

NeilBrown (1):
  block_dev: don't test bdev->bd_contains when it is not stable

Shaohua Li (1):
  block_dev: don't update file access position for sync direct IO

 block/blk-mq.c  | 32 
 drivers/nvme/host/pci.c | 22 +++---
 fs/block_dev.c  |  7 ++-
 3 files changed, 45 insertions(+), 16 deletions(-)

-- 
Jens Axboe

Re: [patch 0/2] tsc/adjust: Cure suspend/resume issues and prevent TSC deadline timer irq storm

[Roland Scheidegger]

Am 14.12.2016 um 22:40 schrieb Thomas Gleixner:
> On Wed, 14 Dec 2016, Thomas Gleixner wrote:
>> Positive space, results in timer not firing anymore - at least not in a
>> time frame you are willing to wait for.
>>
>>  0x  8000 
>>
>> Negative space, results in an interrupt storm.
>>
>>  0x   
>>  0x fffe  
>>  0x fffd  
>>  0x fffc  
>>  0x fffb  
>>  
>>
>> These points are independent of the underlying counter value (cold boot,
>> warm boot) and even reproduce after hours of power on reliably.
>>
>> And looking at the values makes me wonder about 32bit vs. 64bit wreckage
>> combined with sign expansion done wrong. Im really impressed!
> 
> And the whole mess stems from the fact that the deadline is not as one
> would expect simply compared against the sum of the counter and the adjust
> MSR.
Why would it be compared against the sum? As far as I can tell the adjust
value should never come into play when using deadline timer (other than
indirectly because the TSC would change).
(And I'd guess better avoid an armed deadline timer while changing
TSC_ADJ...)

In any case, I've tested the two patches on top of x86-timers and they
work just fine - all TSC_ADJ values get set to zero both on boot and
resume, no lockups, and tsc clocksource active, with some whining in the
log of course :-).
So,
Tested-by: Roland Scheidegger 

> No, they subtract the adjust value from the MSR when you write the deadline
> and latch the result to compare it against the counter.
> 
> So when the following happens:
> 
>ADJUST = 0
>RDTSC  = 1000 
>DEADLINE   = 1100
> 
>ADJUST =  100
> 
>INTERRUPT
>RDTSC  = 1200
> 
>DEADLINE   = 1300
> 
>ADJUST =0
> 
>INTERRUPT
>RDTSC  = 1200
> 
> So depending on the direction of the adjustment the timer fires late or
> early.
> 
> Combined with that math wreckage this is a complete disaster. And of course
> nothing is documented anywhere and the SDM is outright wrong:
> 
> 10.5.4.1 TSC-Deadline Mode
> 
>   The processor generates a timer interrupt when the value of time-stamp
>   counter is greater than or equal to that of IA32_TSC_DEADLINE. It then
>   disarms the timer and clear the IA32_TSC_DEADLINE MSR. (Both the time-stamp
>   counter and the IA32_TSC_DEADLINE MSR are 64-bit unsigned integers.)
> 
> See the example above. 120 is neither equal nor greater than 130, at
> least not in my universe.
> 
> I serioulsy doubt that Intel manages it to design at least ONE functional
> non broken timer before I retire.
> 
> Thanks,
> 
>   tglx
> 

Re: [patch 0/2] tsc/adjust: Cure suspend/resume issues and prevent TSC deadline timer irq storm

[Roland Scheidegger]

Am 14.12.2016 um 22:40 schrieb Thomas Gleixner:
> On Wed, 14 Dec 2016, Thomas Gleixner wrote:
>> Positive space, results in timer not firing anymore - at least not in a
>> time frame you are willing to wait for.
>>
>>  0x  8000 
>>
>> Negative space, results in an interrupt storm.
>>
>>  0x   
>>  0x fffe  
>>  0x fffd  
>>  0x fffc  
>>  0x fffb  
>>  
>>
>> These points are independent of the underlying counter value (cold boot,
>> warm boot) and even reproduce after hours of power on reliably.
>>
>> And looking at the values makes me wonder about 32bit vs. 64bit wreckage
>> combined with sign expansion done wrong. Im really impressed!
> 
> And the whole mess stems from the fact that the deadline is not as one
> would expect simply compared against the sum of the counter and the adjust
> MSR.
Why would it be compared against the sum? As far as I can tell the adjust
value should never come into play when using deadline timer (other than
indirectly because the TSC would change).
(And I'd guess better avoid an armed deadline timer while changing
TSC_ADJ...)

In any case, I've tested the two patches on top of x86-timers and they
work just fine - all TSC_ADJ values get set to zero both on boot and
resume, no lockups, and tsc clocksource active, with some whining in the
log of course :-).
So,
Tested-by: Roland Scheidegger 

> No, they subtract the adjust value from the MSR when you write the deadline
> and latch the result to compare it against the counter.
> 
> So when the following happens:
> 
>ADJUST = 0
>RDTSC  = 1000 
>DEADLINE   = 1100
> 
>ADJUST =  100
> 
>INTERRUPT
>RDTSC  = 1200
> 
>DEADLINE   = 1300
> 
>ADJUST =0
> 
>INTERRUPT
>RDTSC  = 1200
> 
> So depending on the direction of the adjustment the timer fires late or
> early.
> 
> Combined with that math wreckage this is a complete disaster. And of course
> nothing is documented anywhere and the SDM is outright wrong:
> 
> 10.5.4.1 TSC-Deadline Mode
> 
>   The processor generates a timer interrupt when the value of time-stamp
>   counter is greater than or equal to that of IA32_TSC_DEADLINE. It then
>   disarms the timer and clear the IA32_TSC_DEADLINE MSR. (Both the time-stamp
>   counter and the IA32_TSC_DEADLINE MSR are 64-bit unsigned integers.)
> 
> See the example above. 120 is neither equal nor greater than 130, at
> least not in my universe.
> 
> I serioulsy doubt that Intel manages it to design at least ONE functional
> non broken timer before I retire.
> 
> Thanks,
> 
>   tglx
> 

[GIT PULL] fs meta data unmap

[Jens Axboe]

Hi Linus,

A series from Jan Kara, providing a more efficient way for unmapping
meta data from in the buffer cache than doing it block-by-block. Provide
a general helper that existing callers can use.

Please pull!


  git://git.kernel.dk/linux-block.git for-4.10/fs-unmap



Jan Kara (6):
  fs: Provide function to unmap metadata for a range of blocks
  direct-io: Use clean_bdev_aliases() instead of handmade iteration
  ext4: Use clean_bdev_aliases() instead of iteration
  ext2: Use clean_bdev_aliases() instead of iteration
  fs: Add helper to clean bdev aliases under a bh and use it
  fs: Remove unmap_underlying_metadata

 fs/buffer.c | 104 +++-
 fs/direct-io.c  |  28 +++-
 fs/ext2/inode.c |   9 ++--
 fs/ext4/extents.c   |  13 +-
 fs/ext4/inode.c |  18 +++-
 fs/ext4/page-io.c   |   2 +-
 fs/mpage.c  |   3 +-
 fs/ntfs/aops.c  |   2 +-
 fs/ntfs/file.c  |   5 +--
 fs/ocfs2/aops.c |   2 +-
 fs/ufs/balloc.c |   3 +-
 fs/ufs/inode.c  |   3 +-
 include/linux/buffer_head.h |   7 ++-
 13 files changed, 104 insertions(+), 95 deletions(-)

-- 
Jens Axboe

[GIT PULL] fs meta data unmap

[Jens Axboe]

Hi Linus,

A series from Jan Kara, providing a more efficient way for unmapping
meta data from in the buffer cache than doing it block-by-block. Provide
a general helper that existing callers can use.

Please pull!


  git://git.kernel.dk/linux-block.git for-4.10/fs-unmap



Jan Kara (6):
  fs: Provide function to unmap metadata for a range of blocks
  direct-io: Use clean_bdev_aliases() instead of handmade iteration
  ext4: Use clean_bdev_aliases() instead of iteration
  ext2: Use clean_bdev_aliases() instead of iteration
  fs: Add helper to clean bdev aliases under a bh and use it
  fs: Remove unmap_underlying_metadata

 fs/buffer.c | 104 +++-
 fs/direct-io.c  |  28 +++-
 fs/ext2/inode.c |   9 ++--
 fs/ext4/extents.c   |  13 +-
 fs/ext4/inode.c |  18 +++-
 fs/ext4/page-io.c   |   2 +-
 fs/mpage.c  |   3 +-
 fs/ntfs/aops.c  |   2 +-
 fs/ntfs/file.c  |   5 +--
 fs/ocfs2/aops.c |   2 +-
 fs/ufs/balloc.c |   3 +-
 fs/ufs/inode.c  |   3 +-
 include/linux/buffer_head.h |   7 ++-
 13 files changed, 104 insertions(+), 95 deletions(-)

-- 
Jens Axboe

Re: [PATCH] vfio/pci: Support error recovery

[Alex Williamson]

On Thu, 15 Dec 2016 00:25:13 +0200
"Michael S. Tsirkin"  wrote:

> On Wed, Dec 14, 2016 at 03:16:37PM -0700, Alex Williamson wrote:
> > On Wed, 14 Dec 2016 18:24:23 +0800
> > Cao jin  wrote:
> >   
> > > Sorry for late.
> > > after reading all your comments, I think I will try the solution 1.
> > > 
> > > On 12/13/2016 03:12 AM, Alex Williamson wrote:  
> > > > On Mon, 12 Dec 2016 21:49:01 +0800
> > > > Cao jin  wrote:
> > > > 
> > > >> Hi,
> > > >> I have 2 solutions(high level design) came to me, please see if they 
> > > >> are
> > > >> acceptable, or which one is acceptable. Also have some questions.
> > > >>
> > > >> 1. block guest access during host recovery
> > > >>
> > > >>add new field error_recovering in struct vfio_pci_device to
> > > >>indicate host recovery status. aer driver in host will still do
> > > >>reset link
> > > >>
> > > >>- set error_recovering in vfio-pci driver's error_detected, used to
> > > >>  block all kinds of user access(config space, mmio)
> > > >>- in order to solve concurrent issue of device resetting & user
> > > >>  access, check device state[*] in vfio-pci driver's resume, see if
> > > >>  device reset is done, if it is, then clear"error_recovering", or
> > > >>  else new a timer, check device state periodically until device
> > > >>  reset is done. (what if device reset don't end for a long time?)
> > > >>- In qemu, translate guest link reset to host link reset.
> > > >>  A question here: we already have link reset in host, is a second
> > > >>  link reset necessary? why?
> > > >>  
> > > >>[*] how to check device state: reading certain config space
> > > >>register, check return value is valid or not(All F's)
> > > > 
> > > > Isn't this exactly the path we were on previously?
> > > 
> > > Yes, it is basically the previous path, plus the optimization.
> > >   
> > > > There might be an
> > > > optimization that we could skip back-to-back resets, but how can you
> > > > necessarily infer that the resets are for the same thing? If the user
> > > > accesses the device between resets, can you still guarantee the guest
> > > > directed reset is unnecessary?  If time passes between resets, do you
> > > > know they're for the same event?  How much time can pass between the
> > > > host and guest reset to know they're for the same event?  In the
> > > > process of error handling, which is more important, speed or
> > > > correctness?
> > > >  
> > > 
> > > I think vfio driver itself won't know what each reset comes for, and I
> > > don't quite understand why should vfio care this question, is this a new
> > > question in the design?  
> > 
> > You're suggesting an optimization to eliminate one of the resets,
> > and as we've discussed, I don't see removing the host induced reset
> > as a viable option.  That means you want to eliminate the guest
> > directed reset.  There are potentially three levels to do that, the
> > vfio-pci driver in the host kernel, somewhere in QEMU, or eliminate it
> > within the guest.  My comments were directed to the first option, the
> > host kernel level cannot correlate user directed resets as duplicates
> > of host directed resets.  
> >
> > > But I think it make sense that the user access during 2 resets maybe a
> > > trouble for guest recovery, misbehaved user could be out of our
> > > imagination.  Correctness is more important.
> > > 
> > > If I understand you right, let me make a summary: host recovery just
> > > does link reset, which is incomplete, so we'd better do a complete guest
> > > recovery for correctness.  
> > 
> > We don't know whether the host link reset is incomplete, but we can't do
> > a link reset transparently to the device, the device is no longer in the
> > same state after the reset.  The device specific driver, which exists
> > in userspace needs to be involved in device recovery.  Therefore
> > regardless of how QEMU handles the error, the driver within the guest
> > needs to be notified and perform recovery.  Since the device is PCI and
> > we're on x86 and nobody wants to introduce paravirtual error recovery,
> > we must use AER.  Part of AER recovery includes the possibility of
> > performing a link reset.  So it seems this eliminates avoiding the link
> > reset within the guest.
> > 
> > That leaves QEMU.  Here we need to decide whether a guest triggered
> > link reset induces a host link reset.  The current working theory is
> > that yes, this must be the case.  If there is ever a case where a
> > driver within the guest could trigger a link reset for the purposes
> > of error recovery when the host has not, I think this must be the
> > case.  Therefore, at least some guest induced link resets must become
> > host link resets.  Currently we assume all guest induced link resets
> > become host link resets.  Minimally to avoid that, QEMU would need to
> > know 

Re: [PATCH] vfio/pci: Support error recovery

[Alex Williamson]

On Thu, 15 Dec 2016 00:25:13 +0200
"Michael S. Tsirkin"  wrote:

> On Wed, Dec 14, 2016 at 03:16:37PM -0700, Alex Williamson wrote:
> > On Wed, 14 Dec 2016 18:24:23 +0800
> > Cao jin  wrote:
> >   
> > > Sorry for late.
> > > after reading all your comments, I think I will try the solution 1.
> > > 
> > > On 12/13/2016 03:12 AM, Alex Williamson wrote:  
> > > > On Mon, 12 Dec 2016 21:49:01 +0800
> > > > Cao jin  wrote:
> > > > 
> > > >> Hi,
> > > >> I have 2 solutions(high level design) came to me, please see if they 
> > > >> are
> > > >> acceptable, or which one is acceptable. Also have some questions.
> > > >>
> > > >> 1. block guest access during host recovery
> > > >>
> > > >>add new field error_recovering in struct vfio_pci_device to
> > > >>indicate host recovery status. aer driver in host will still do
> > > >>reset link
> > > >>
> > > >>- set error_recovering in vfio-pci driver's error_detected, used to
> > > >>  block all kinds of user access(config space, mmio)
> > > >>- in order to solve concurrent issue of device resetting & user
> > > >>  access, check device state[*] in vfio-pci driver's resume, see if
> > > >>  device reset is done, if it is, then clear"error_recovering", or
> > > >>  else new a timer, check device state periodically until device
> > > >>  reset is done. (what if device reset don't end for a long time?)
> > > >>- In qemu, translate guest link reset to host link reset.
> > > >>  A question here: we already have link reset in host, is a second
> > > >>  link reset necessary? why?
> > > >>  
> > > >>[*] how to check device state: reading certain config space
> > > >>register, check return value is valid or not(All F's)
> > > > 
> > > > Isn't this exactly the path we were on previously?
> > > 
> > > Yes, it is basically the previous path, plus the optimization.
> > >   
> > > > There might be an
> > > > optimization that we could skip back-to-back resets, but how can you
> > > > necessarily infer that the resets are for the same thing? If the user
> > > > accesses the device between resets, can you still guarantee the guest
> > > > directed reset is unnecessary?  If time passes between resets, do you
> > > > know they're for the same event?  How much time can pass between the
> > > > host and guest reset to know they're for the same event?  In the
> > > > process of error handling, which is more important, speed or
> > > > correctness?
> > > >  
> > > 
> > > I think vfio driver itself won't know what each reset comes for, and I
> > > don't quite understand why should vfio care this question, is this a new
> > > question in the design?  
> > 
> > You're suggesting an optimization to eliminate one of the resets,
> > and as we've discussed, I don't see removing the host induced reset
> > as a viable option.  That means you want to eliminate the guest
> > directed reset.  There are potentially three levels to do that, the
> > vfio-pci driver in the host kernel, somewhere in QEMU, or eliminate it
> > within the guest.  My comments were directed to the first option, the
> > host kernel level cannot correlate user directed resets as duplicates
> > of host directed resets.  
> >
> > > But I think it make sense that the user access during 2 resets maybe a
> > > trouble for guest recovery, misbehaved user could be out of our
> > > imagination.  Correctness is more important.
> > > 
> > > If I understand you right, let me make a summary: host recovery just
> > > does link reset, which is incomplete, so we'd better do a complete guest
> > > recovery for correctness.  
> > 
> > We don't know whether the host link reset is incomplete, but we can't do
> > a link reset transparently to the device, the device is no longer in the
> > same state after the reset.  The device specific driver, which exists
> > in userspace needs to be involved in device recovery.  Therefore
> > regardless of how QEMU handles the error, the driver within the guest
> > needs to be notified and perform recovery.  Since the device is PCI and
> > we're on x86 and nobody wants to introduce paravirtual error recovery,
> > we must use AER.  Part of AER recovery includes the possibility of
> > performing a link reset.  So it seems this eliminates avoiding the link
> > reset within the guest.
> > 
> > That leaves QEMU.  Here we need to decide whether a guest triggered
> > link reset induces a host link reset.  The current working theory is
> > that yes, this must be the case.  If there is ever a case where a
> > driver within the guest could trigger a link reset for the purposes
> > of error recovery when the host has not, I think this must be the
> > case.  Therefore, at least some guest induced link resets must become
> > host link resets.  Currently we assume all guest induced link resets
> > become host link resets.  Minimally to avoid that, QEMU would need to
> > know (not assume) whether the host performed a link reset.  Even with
> > 

[PATCH 0/4] ARM64: dts: marvell: fix license text

[Alexandre Belloni]

The dual GPLv2/X11 license the text that is used
is missing a few characters.


Alexandre Belloni (4):
  ARM64: dts: marvell/armada-371x: Correct license text
  ARM64: dts: marvell/armada-3720-db: Correct license text
  ARM64: dts: marvell/armada-372x: Correct license text
  ARM64: dts: marvell/armada-37xx: Correct license text

 arch/arm64/boot/dts/marvell/armada-371x.dtsi   | 10 +-
 arch/arm64/boot/dts/marvell/armada-3720-db.dts | 10 +-
 arch/arm64/boot/dts/marvell/armada-372x.dtsi   | 10 +-
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi   | 10 +-
 4 files changed, 20 insertions(+), 20 deletions(-)

-- 
2.10.2

[PATCH 0/4] ARM64: dts: marvell: fix license text

[Alexandre Belloni]

The dual GPLv2/X11 license the text that is used
is missing a few characters.


Alexandre Belloni (4):
  ARM64: dts: marvell/armada-371x: Correct license text
  ARM64: dts: marvell/armada-3720-db: Correct license text
  ARM64: dts: marvell/armada-372x: Correct license text
  ARM64: dts: marvell/armada-37xx: Correct license text

 arch/arm64/boot/dts/marvell/armada-371x.dtsi   | 10 +-
 arch/arm64/boot/dts/marvell/armada-3720-db.dts | 10 +-
 arch/arm64/boot/dts/marvell/armada-372x.dtsi   | 10 +-
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi   | 10 +-
 4 files changed, 20 insertions(+), 20 deletions(-)

-- 
2.10.2

Re: [PATCHv3 perf/core 0/7] Reuse libbpf from samples/bpf

[Joe Stringer]

On 14 December 2016 at 06:55, Arnaldo Carvalho de Melo  wrote:
> Em Wed, Dec 14, 2016 at 10:25:01AM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Fri, Dec 09, 2016 at 04:30:54PM +0100, Daniel Borkmann escreveu:
>> > On 12/09/2016 04:09 PM, Arnaldo Carvalho de Melo wrote:
>> > Please note that this might result in hopefully just a minor merge issue
>> > with net-next. Looks like patch 4/7 touches test_maps.c and 
>> > test_verifier.c,
>> > which moved to a new bpf selftest suite [1] this net-next cycle. Seems it's
>> > just log buffer and some renames there, which can be discarded for both
>> > files sitting in selftests.
>>
>> Yeah, I've got to this point, and the merge has a little bit more than
>> that, including BPF_PROG_ATTACH/BPF_PROG_DETACH, etc, working on it...
>
> So, Joe, can you try refreshing this work, starting from what I have in
> perf/core? It has the changes coming from net-next that Daniel warned us about
> and some more.

Hi Arnaldo,

I've just respun this series based on the version you previously
applied to perf/core. Since bpf_prog_{attach,detach}() were added to
samples/libbpf, a new patch will shift these over to tools/lib/bpf.
Other than that, I folded "samples/bpf: Drop unnecessary build
targets." back into "samples/bpf: Switch over to libbpf", and I
noticed that there were a couple of unnecessary log buffers with the
latest changes. For any new sample programs, those were fixed up to
use libbpf as well.

Don't forget to do a "make headers_install" before attempting to build
the samples, access to the latest headers is required (as per the
readme in samples/bpf).

Thanks,
Joe

[PATCH 2/4] ARM64: dts: marvell/armada-3720-db: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Andreas Färber 
Cc: Bjorn Helgaas 
Cc: Thomas Petazzoni 
Signed-off-by: Alexandre Belloni 
---
 arch/arm64/boot/dts/marvell/armada-3720-db.dts | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts 
b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 1372e9a6aaa4..2e707875039a 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -15,17 +15,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -34,11 +34,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

[PATCH 4/4] ARM64: dts: marvell/armada-37xx: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Andreas Färber 
Cc: Bjorn Helgaas 
Cc: Marcin Wojtas 
Cc: Thomas Petazzoni 
Signed-off-by: Alexandre Belloni 
---
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi 
b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index e9bd58793464..3c6f5d9d15c4 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -15,17 +15,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -34,11 +34,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

[PATCH 2/4] ARM64: dts: marvell/armada-3720-db: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Andreas Färber 
Cc: Bjorn Helgaas 
Cc: Thomas Petazzoni 
Signed-off-by: Alexandre Belloni 
---
 arch/arm64/boot/dts/marvell/armada-3720-db.dts | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/marvell/armada-3720-db.dts 
b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
index 1372e9a6aaa4..2e707875039a 100644
--- a/arch/arm64/boot/dts/marvell/armada-3720-db.dts
+++ b/arch/arm64/boot/dts/marvell/armada-3720-db.dts
@@ -15,17 +15,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -34,11 +34,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

[PATCH 4/4] ARM64: dts: marvell/armada-37xx: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Andreas Färber 
Cc: Bjorn Helgaas 
Cc: Marcin Wojtas 
Cc: Thomas Petazzoni 
Signed-off-by: Alexandre Belloni 
---
 arch/arm64/boot/dts/marvell/armada-37xx.dtsi | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi 
b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
index e9bd58793464..3c6f5d9d15c4 100644
--- a/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-37xx.dtsi
@@ -15,17 +15,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -34,11 +34,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

Re: [PATCHv3 perf/core 0/7] Reuse libbpf from samples/bpf

[Joe Stringer]

On 14 December 2016 at 06:55, Arnaldo Carvalho de Melo  wrote:
> Em Wed, Dec 14, 2016 at 10:25:01AM -0300, Arnaldo Carvalho de Melo escreveu:
>> Em Fri, Dec 09, 2016 at 04:30:54PM +0100, Daniel Borkmann escreveu:
>> > On 12/09/2016 04:09 PM, Arnaldo Carvalho de Melo wrote:
>> > Please note that this might result in hopefully just a minor merge issue
>> > with net-next. Looks like patch 4/7 touches test_maps.c and 
>> > test_verifier.c,
>> > which moved to a new bpf selftest suite [1] this net-next cycle. Seems it's
>> > just log buffer and some renames there, which can be discarded for both
>> > files sitting in selftests.
>>
>> Yeah, I've got to this point, and the merge has a little bit more than
>> that, including BPF_PROG_ATTACH/BPF_PROG_DETACH, etc, working on it...
>
> So, Joe, can you try refreshing this work, starting from what I have in
> perf/core? It has the changes coming from net-next that Daniel warned us about
> and some more.

Hi Arnaldo,

I've just respun this series based on the version you previously
applied to perf/core. Since bpf_prog_{attach,detach}() were added to
samples/libbpf, a new patch will shift these over to tools/lib/bpf.
Other than that, I folded "samples/bpf: Drop unnecessary build
targets." back into "samples/bpf: Switch over to libbpf", and I
noticed that there were a couple of unnecessary log buffers with the
latest changes. For any new sample programs, those were fixed up to
use libbpf as well.

Don't forget to do a "make headers_install" before attempting to build
the samples, access to the latest headers is required (as per the
readme in samples/bpf).

Thanks,
Joe

[PATCH 3/4] ARM64: dts: marvell/armada-372x: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Andreas Färber 
Signed-off-by: Alexandre Belloni 
---
 arch/arm64/boot/dts/marvell/armada-372x.dtsi | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/marvell/armada-372x.dtsi 
b/arch/arm64/boot/dts/marvell/armada-372x.dtsi
index 5120296596c2..59d7557d3b1b 100644
--- a/arch/arm64/boot/dts/marvell/armada-372x.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-372x.dtsi
@@ -16,17 +16,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -35,11 +35,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

[PATCH 1/4] ARM64: dts: marvell/armada-371x: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Signed-off-by: Alexandre Belloni 
---
 arch/arm64/boot/dts/marvell/armada-371x.dtsi | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/marvell/armada-371x.dtsi 
b/arch/arm64/boot/dts/marvell/armada-371x.dtsi
index c9e5325b8ac3..11226f7b9ed9 100644
--- a/arch/arm64/boot/dts/marvell/armada-371x.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-371x.dtsi
@@ -16,17 +16,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -35,11 +35,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

[PATCH 3/4] ARM64: dts: marvell/armada-372x: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Andreas Färber 
Signed-off-by: Alexandre Belloni 
---
 arch/arm64/boot/dts/marvell/armada-372x.dtsi | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/marvell/armada-372x.dtsi 
b/arch/arm64/boot/dts/marvell/armada-372x.dtsi
index 5120296596c2..59d7557d3b1b 100644
--- a/arch/arm64/boot/dts/marvell/armada-372x.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-372x.dtsi
@@ -16,17 +16,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -35,11 +35,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

[PATCH 1/4] ARM64: dts: marvell/armada-371x: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Signed-off-by: Alexandre Belloni 
---
 arch/arm64/boot/dts/marvell/armada-371x.dtsi | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm64/boot/dts/marvell/armada-371x.dtsi 
b/arch/arm64/boot/dts/marvell/armada-371x.dtsi
index c9e5325b8ac3..11226f7b9ed9 100644
--- a/arch/arm64/boot/dts/marvell/armada-371x.dtsi
+++ b/arch/arm64/boot/dts/marvell/armada-371x.dtsi
@@ -16,17 +16,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -35,11 +35,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

[PATCH 02/39] ARM: dts: armada-370-dlink-dns327l: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Andrew Andrianov 
Cc: Boris Brezillon 
Signed-off-by: Alexandre Belloni 
---
 arch/arm/boot/dts/armada-370-dlink-dns327l.dts | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-dlink-dns327l.dts 
b/arch/arm/boot/dts/armada-370-dlink-dns327l.dts
index e2a363b1dd8a..60821b77297d 100644
--- a/arch/arm/boot/dts/armada-370-dlink-dns327l.dts
+++ b/arch/arm/boot/dts/armada-370-dlink-dns327l.dts
@@ -13,17 +13,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -32,11 +32,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

[PATCH 02/39] ARM: dts: armada-370-dlink-dns327l: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Andrew Andrianov 
Cc: Boris Brezillon 
Signed-off-by: Alexandre Belloni 
---
 arch/arm/boot/dts/armada-370-dlink-dns327l.dts | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-dlink-dns327l.dts 
b/arch/arm/boot/dts/armada-370-dlink-dns327l.dts
index e2a363b1dd8a..60821b77297d 100644
--- a/arch/arm/boot/dts/armada-370-dlink-dns327l.dts
+++ b/arch/arm/boot/dts/armada-370-dlink-dns327l.dts
@@ -13,17 +13,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -32,11 +32,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

[PATCH 09/39] ARM: dts: armada-370-xp: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Arnaud Ebalard 
Cc: Ben Dooks 
Cc: Ezequiel Garcia 
Cc: Greg Ungerer 
Cc: Heikki Krogerus 
Cc: Kevin Hilman 
Cc: Lior Amsalem 
Cc: Lorenzo Pieralisi 
Cc: Maxime Ripard 
Cc: Nobuhiro Iwamatsu 
Cc: Simon Baatz 
Cc: Simon Guinot 
Cc: Stefan Roese 
Cc: Thomas Petazzoni 
Cc: Willy Tarreau 
Cc: Yehuda Yitschak 
Signed-off-by: Alexandre Belloni 
---
 arch/arm/boot/dts/armada-370-xp.dtsi | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 3ccedc9dffb2..743b2ec2af4f 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -18,17 +18,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -37,11 +37,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

[PATCH 09/39] ARM: dts: armada-370-xp: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Arnaud Ebalard 
Cc: Ben Dooks 
Cc: Ezequiel Garcia 
Cc: Greg Ungerer 
Cc: Heikki Krogerus 
Cc: Kevin Hilman 
Cc: Lior Amsalem 
Cc: Lorenzo Pieralisi 
Cc: Maxime Ripard 
Cc: Nobuhiro Iwamatsu 
Cc: Simon Baatz 
Cc: Simon Guinot 
Cc: Stefan Roese 
Cc: Thomas Petazzoni 
Cc: Willy Tarreau 
Cc: Yehuda Yitschak 
Signed-off-by: Alexandre Belloni 
---
 arch/arm/boot/dts/armada-370-xp.dtsi | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-xp.dtsi 
b/arch/arm/boot/dts/armada-370-xp.dtsi
index 3ccedc9dffb2..743b2ec2af4f 100644
--- a/arch/arm/boot/dts/armada-370-xp.dtsi
+++ b/arch/arm/boot/dts/armada-370-xp.dtsi
@@ -18,17 +18,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -37,11 +37,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

[PATCH 05/39] ARM: dts: armada-370-netgear-rn102: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Arnaud Ebalard 
Cc: Ben Peddell 
Cc: Boris Brezillon 
Cc: Ezequiel Garcia 
Cc: Philipp Zabel 
Cc: Sudeep Holla 
Cc: Thomas Petazzoni 
Signed-off-by: Alexandre Belloni 
---
 arch/arm/boot/dts/armada-370-netgear-rn102.dts | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-netgear-rn102.dts 
b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
index 39181b3fa90d..c4cbb81b43e8 100644
--- a/arch/arm/boot/dts/armada-370-netgear-rn102.dts
+++ b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
@@ -13,17 +13,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -32,11 +32,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

[PATCH 05/39] ARM: dts: armada-370-netgear-rn102: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Arnaud Ebalard 
Cc: Ben Peddell 
Cc: Boris Brezillon 
Cc: Ezequiel Garcia 
Cc: Philipp Zabel 
Cc: Sudeep Holla 
Cc: Thomas Petazzoni 
Signed-off-by: Alexandre Belloni 
---
 arch/arm/boot/dts/armada-370-netgear-rn102.dts | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-netgear-rn102.dts 
b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
index 39181b3fa90d..c4cbb81b43e8 100644
--- a/arch/arm/boot/dts/armada-370-netgear-rn102.dts
+++ b/arch/arm/boot/dts/armada-370-netgear-rn102.dts
@@ -13,17 +13,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -32,11 +32,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

[PATCH 01/39] ARM: dts: armada-370-db: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Arnaud Ebalard 
Cc: Ben Dooks 
Cc: Boris Brezillon 
Cc: Ezequiel Garcia 
Cc: Lior Amsalem 
Cc: Rafał Miłecki 
Cc: Simon Baatz 
Cc: Stefan Roese 
Cc: Thomas Petazzoni 
Signed-off-by: Alexandre Belloni 
---
 arch/arm/boot/dts/armada-370-db.dts | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts 
b/arch/arm/boot/dts/armada-370-db.dts
index 033fa63544f7..1dc63e7eaece 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -18,17 +18,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -37,11 +37,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

[PATCH 10/39] ARM: dts: armada-375-db: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Boris Brezillon 
Cc: Ezequiel Garcia 
Cc: Rafał Miłecki 
Cc: Thomas Petazzoni 
Signed-off-by: Alexandre Belloni 
---
 arch/arm/boot/dts/armada-375-db.dts | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/armada-375-db.dts 
b/arch/arm/boot/dts/armada-375-db.dts
index cded5f0a262d..6bbe3a35810d 100644
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -17,17 +17,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -36,11 +36,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

[PATCH 01/39] ARM: dts: armada-370-db: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Arnaud Ebalard 
Cc: Ben Dooks 
Cc: Boris Brezillon 
Cc: Ezequiel Garcia 
Cc: Lior Amsalem 
Cc: Rafał Miłecki 
Cc: Simon Baatz 
Cc: Stefan Roese 
Cc: Thomas Petazzoni 
Signed-off-by: Alexandre Belloni 
---
 arch/arm/boot/dts/armada-370-db.dts | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-db.dts 
b/arch/arm/boot/dts/armada-370-db.dts
index 033fa63544f7..1dc63e7eaece 100644
--- a/arch/arm/boot/dts/armada-370-db.dts
+++ b/arch/arm/boot/dts/armada-370-db.dts
@@ -18,17 +18,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -37,11 +37,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

[PATCH 10/39] ARM: dts: armada-375-db: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Boris Brezillon 
Cc: Ezequiel Garcia 
Cc: Rafał Miłecki 
Cc: Thomas Petazzoni 
Signed-off-by: Alexandre Belloni 
---
 arch/arm/boot/dts/armada-375-db.dts | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/armada-375-db.dts 
b/arch/arm/boot/dts/armada-375-db.dts
index cded5f0a262d..6bbe3a35810d 100644
--- a/arch/arm/boot/dts/armada-375-db.dts
+++ b/arch/arm/boot/dts/armada-375-db.dts
@@ -17,17 +17,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -36,11 +36,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

[PATCH 23/39] ARM: dts: armada-xp-axpwifiap: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Arnaud Ebalard 
Cc: Boris Brezillon 
Cc: Ezequiel Garcia 
Cc: Paul Bolle 
Cc: Rafał Miłecki 
Cc: Sebastian Hesselbarth 
Cc: Stefan Roese 
Cc: Thomas Petazzoni 
Signed-off-by: Alexandre Belloni 
---
 arch/arm/boot/dts/armada-xp-axpwifiap.dts | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-axpwifiap.dts 
b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
index ce152719bc28..6a25eb427822 100644
--- a/arch/arm/boot/dts/armada-xp-axpwifiap.dts
+++ b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
@@ -20,17 +20,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -39,11 +39,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

[PATCH 23/39] ARM: dts: armada-xp-axpwifiap: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Arnaud Ebalard 
Cc: Boris Brezillon 
Cc: Ezequiel Garcia 
Cc: Paul Bolle 
Cc: Rafał Miłecki 
Cc: Sebastian Hesselbarth 
Cc: Stefan Roese 
Cc: Thomas Petazzoni 
Signed-off-by: Alexandre Belloni 
---
 arch/arm/boot/dts/armada-xp-axpwifiap.dts | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-axpwifiap.dts 
b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
index ce152719bc28..6a25eb427822 100644
--- a/arch/arm/boot/dts/armada-xp-axpwifiap.dts
+++ b/arch/arm/boot/dts/armada-xp-axpwifiap.dts
@@ -20,17 +20,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -39,11 +39,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

[PATCH 07/39] ARM: dts: armada-370-rd: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Arnaud Ebalard 
Cc: Boris Brezillon 
Cc: Ezequiel Garcia 
Cc: Florian Fainelli 
Cc: Simon Baatz 
Cc: Thomas Petazzoni 
Signed-off-by: Alexandre Belloni 
---
 arch/arm/boot/dts/armada-370-rd.dts | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/armada-370-rd.dts 
b/arch/arm/boot/dts/armada-370-rd.dts
index fbef730e8d37..e920f7166d4a 100644
--- a/arch/arm/boot/dts/armada-370-rd.dts
+++ b/arch/arm/boot/dts/armada-370-rd.dts
@@ -16,17 +16,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -35,11 +35,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

[PATCH 11/39] ARM: dts: armada-375: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Boris Brezillon 
Cc: Ezequiel Garcia 
Cc: Lior Amsalem 
Cc: Marcin Wojtas 
Cc: Maxime Ripard 
Cc: Thomas Petazzoni 
Signed-off-by: Alexandre Belloni 
---
 arch/arm/boot/dts/armada-375.dtsi | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/armada-375.dtsi 
b/arch/arm/boot/dts/armada-375.dtsi
index cc952cf8ec30..23548223797a 100644
--- a/arch/arm/boot/dts/armada-375.dtsi
+++ b/arch/arm/boot/dts/armada-375.dtsi
@@ -16,17 +16,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -35,11 +35,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

[PATCH 13/39] ARM: dts: armada-388-clearfog: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Marcin Wojtas 
Cc: Russell King 
Cc: Stefan Roese 
Signed-off-by: Alexandre Belloni 
---
 arch/arm/boot/dts/armada-388-clearfog.dts | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/arm/boot/dts/armada-388-clearfog.dts 
b/arch/arm/boot/dts/armada-388-clearfog.dts
index 71ce201c903e..2d5b8cdeaaf8 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dts
+++ b/arch/arm/boot/dts/armada-388-clearfog.dts
@@ -17,17 +17,17 @@
  * modify it under the terms of the GNU General Public License
  * version 2 as published by the Free Software Foundation.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -36,11 +36,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
-- 
2.10.2

[PATCH 12/39] ARM: dts: armada-38x: Correct license text

[Alexandre Belloni]

The license test has been mangled at some point then copy pasted across
multiple files. Restore it to what it should be.
Note that this is not intended as a license change.

Cc: Boris Brezillon 
Cc: Chris Packham 
Cc: Ezequiel Garcia 
Cc: Imre Kaloz 
Cc: Marcin Wojtas 
Cc: Maxime Ripard 
Cc: Stefan Roese 
Cc: Thomas Petazzoni 
Signed-off-by: Alexandre Belloni 
---
 arch/arm/boot/dts/armada-380.dtsi | 10 +-
 arch/arm/boot/dts/armada-385.dtsi | 10 +-
 arch/arm/boot/dts/armada-38x.dtsi | 10 +-
 3 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/arch/arm/boot/dts/armada-380.dtsi 
b/arch/arm/boot/dts/armada-380.dtsi
index 5102d19cc8f4..e392f6036f39 100644
--- a/arch/arm/boot/dts/armada-380.dtsi
+++ b/arch/arm/boot/dts/armada-380.dtsi
@@ -17,17 +17,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -36,11 +36,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
  * OTHER DEALINGS IN THE SOFTWARE.
diff --git a/arch/arm/boot/dts/armada-385.dtsi 
b/arch/arm/boot/dts/armada-385.dtsi
index 8e67d2c083dd..8e63be33472e 100644
--- a/arch/arm/boot/dts/armada-385.dtsi
+++ b/arch/arm/boot/dts/armada-385.dtsi
@@ -17,17 +17,17 @@
  * published by the Free Software Foundation; either version 2 of the
  * License, or (at your option) any later version.
  *
- * This file is distributed in the hope that it will be useful
+ * This file 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.
  *
- * Or, alternatively
+ * Or, alternatively,
  *
  *  b) Permission is hereby granted, free of charge, to any person
  * obtaining a copy of this software and associated documentation
  * files (the "Software"), to deal in the Software without
- * restriction, including without limitation the rights to use
+ * restriction, including without limitation the rights to use,
  * copy, modify, merge, publish, distribute, sublicense, and/or
  * sell copies of the Software, and to permit persons to whom the
  * Software is furnished to do so, subject to the following
@@ -36,11 +36,11 @@
  * The above copyright notice and this permission notice shall be
  * included in all copies or substantial portions of the Software.
  *
- * THE SOFTWARE IS PROVIDED , WITHOUT WARRANTY OF ANY KIND
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
  * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
  * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
  * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
- * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
  * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
  * FROM, OUT OF OR IN CONNECTION WITH