Re: [RFC qemu 0/4] A PV solution for live migration optimization

[Amit Shah]

On (Thu) 10 Mar 2016 [07:44:19], Li, Liang Z wrote:
> 
> Hi Amit,
> 
>  Could provide more information on how to use virtio-serial to exchange data? 
>  Thread , Wiki or code are all OK. 
>  I have not find some useful information yet.

See this commit in the Linux sources:

108fc82596e3b66b819df9d28c1ebbc9ab5de14c

that adds a way to send guest trace data over to the host.  I think
that's the most relevant to your use-case.  However, you'll have to
add an in-kernel user of virtio-serial (like the virtio-console code
-- the code that deals with tty and hvc currently).  There's no other
non-tty user right now, and this is the right kind of use-case to add
one for!

For many other (userspace) use-cases, see the qemu-guest-agent in the
qemu sources.

The API is documented in the wiki:

http://www.linux-kvm.org/page/Virtio-serial_API

and the feature pages have some information that may help as well:

https://fedoraproject.org/wiki/Features/VirtioSerial

There are some links in here too:

http://log.amitshah.net/2010/09/communication-between-guests-and-hosts/

Hope this helps.


Amit

Re: [RFC qemu 0/4] A PV solution for live migration optimization

[Amit Shah]

On (Thu) 10 Mar 2016 [07:44:19], Li, Liang Z wrote:
> 
> Hi Amit,
> 
>  Could provide more information on how to use virtio-serial to exchange data? 
>  Thread , Wiki or code are all OK. 
>  I have not find some useful information yet.

See this commit in the Linux sources:

108fc82596e3b66b819df9d28c1ebbc9ab5de14c

that adds a way to send guest trace data over to the host.  I think
that's the most relevant to your use-case.  However, you'll have to
add an in-kernel user of virtio-serial (like the virtio-console code
-- the code that deals with tty and hvc currently).  There's no other
non-tty user right now, and this is the right kind of use-case to add
one for!

For many other (userspace) use-cases, see the qemu-guest-agent in the
qemu sources.

The API is documented in the wiki:

http://www.linux-kvm.org/page/Virtio-serial_API

and the feature pages have some information that may help as well:

https://fedoraproject.org/wiki/Features/VirtioSerial

There are some links in here too:

http://log.amitshah.net/2010/09/communication-between-guests-and-hosts/

Hope this helps.


Amit

Pilna Aktualizacja Zabezpieczen Do Roku 2016 !!!

[Admin]

   Ze wzgledu na ostatnie uaktualnienie w naszym serwerem SSL,
aby sluzyc Ci lepiej, prosze pamietac, ze wszyscy
uzytkownicy sa upowaznione do aktualizacji swoich danych do
logowania w innych, aby cieszyc sie nowa aktualizacje DLA
2016. Uzytkownik bedzie zablokowany wysylania i odbierania
wiadomosci e-mail, jesli nie potwierdzone w cigu 48 godzin
od otrzymania tego automatycznego maila. Wymagane jest,
kliknij na link ponizej, albo jeszcze lepiej skopiowac do
Brower.


http://pocztaunitforhellpdeskcenter.ezweb123.com/


Z powazaniem,
SYSTEM ADMIN HELP DESK
Copyright Š 2016, Wszystkie prawa zastrzezone

Pilna Aktualizacja Zabezpieczen Do Roku 2016 !!!

[Admin]

   Ze wzgledu na ostatnie uaktualnienie w naszym serwerem SSL,
aby sluzyc Ci lepiej, prosze pamietac, ze wszyscy
uzytkownicy sa upowaznione do aktualizacji swoich danych do
logowania w innych, aby cieszyc sie nowa aktualizacje DLA
2016. Uzytkownik bedzie zablokowany wysylania i odbierania
wiadomosci e-mail, jesli nie potwierdzone w cigu 48 godzin
od otrzymania tego automatycznego maila. Wymagane jest,
kliknij na link ponizej, albo jeszcze lepiej skopiowac do
Brower.


http://pocztaunitforhellpdeskcenter.ezweb123.com/


Z powazaniem,
SYSTEM ADMIN HELP DESK
Copyright Š 2016, Wszystkie prawa zastrzezone

Re: [PATCH] arc: use little endian accesses

[Arnd Bergmann]

On Thursday 10 March 2016, Vineet Gupta wrote:
> On Wednesday 09 March 2016 10:51 PM, Lada Trimasova wrote:
> > Memory access primitives should use cpu_to_le16, cpu_to_le32, le16_to_cpu
> > and le32_to_cpu because it is not really guaranteed that drivers handles
> > any ordering themselves.
> 
> That is the driver issue. readxx as API simply returns data in native 
> endianness.
> We've had EZChip running big endian and so far and they didn't need this 
> change.

Most drivers using readl() or readl_relaxed() expect those to perform byte
swaps on big-endian architectures, as the registers tend to be fixed endian,
so the change seems reasonable.

It depends a little bit on how endian mode is implemented in the CPU: do you
follow the normal model of swapping byte order in the load/store instructions
of the CPU when running big-endian, or is the CPU always running little-endian
but the bus addresses get mangled on byte accesses to give the illusion
of a big-endian system?

Arnd

Re: [PATCH] arc: use little endian accesses

[Arnd Bergmann]

On Thursday 10 March 2016, Vineet Gupta wrote:
> On Wednesday 09 March 2016 10:51 PM, Lada Trimasova wrote:
> > Memory access primitives should use cpu_to_le16, cpu_to_le32, le16_to_cpu
> > and le32_to_cpu because it is not really guaranteed that drivers handles
> > any ordering themselves.
> 
> That is the driver issue. readxx as API simply returns data in native 
> endianness.
> We've had EZChip running big endian and so far and they didn't need this 
> change.

Most drivers using readl() or readl_relaxed() expect those to perform byte
swaps on big-endian architectures, as the registers tend to be fixed endian,
so the change seems reasonable.

It depends a little bit on how endian mode is implemented in the CPU: do you
follow the normal model of swapping byte order in the load/store instructions
of the CPU when running big-endian, or is the CPU always running little-endian
but the bus addresses get mangled on byte accesses to give the illusion
of a big-endian system?

Arnd

[patch] ata: ahci_xgene: dereferencing uninitialized pointer in probe

[Dan Carpenter]

If the call to acpi_get_object_info() fails then "info" hasn't been
initialized.  In that situation, we already know that "version" should
be XGENE_AHCI_V1 so we don't actually need to dereference "info".

Fixes: c9802a4be661 ('ata: ahci_xgene: Add AHCI Support for 2nd HW version of 
APM X-Gene SoC AHCI SATA Host controller.')
Signed-off-by: Dan Carpenter 

diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
index 8e3f7fa..73b19b2 100644
--- a/drivers/ata/ahci_xgene.c
+++ b/drivers/ata/ahci_xgene.c
@@ -821,9 +821,9 @@ static int xgene_ahci_probe(struct platform_device *pdev)
dev_warn(>dev, "%s: Error reading device 
info. Assume version1\n",
__func__);
version = XGENE_AHCI_V1;
-   }
-   if (info->valid & ACPI_VALID_CID)
+   } else if (info->valid & ACPI_VALID_CID) {
version = XGENE_AHCI_V2;
+   }
}
}
 #endif

[patch] ata: ahci_xgene: dereferencing uninitialized pointer in probe

[Dan Carpenter]

If the call to acpi_get_object_info() fails then "info" hasn't been
initialized.  In that situation, we already know that "version" should
be XGENE_AHCI_V1 so we don't actually need to dereference "info".

Fixes: c9802a4be661 ('ata: ahci_xgene: Add AHCI Support for 2nd HW version of 
APM X-Gene SoC AHCI SATA Host controller.')
Signed-off-by: Dan Carpenter 

diff --git a/drivers/ata/ahci_xgene.c b/drivers/ata/ahci_xgene.c
index 8e3f7fa..73b19b2 100644
--- a/drivers/ata/ahci_xgene.c
+++ b/drivers/ata/ahci_xgene.c
@@ -821,9 +821,9 @@ static int xgene_ahci_probe(struct platform_device *pdev)
dev_warn(>dev, "%s: Error reading device 
info. Assume version1\n",
__func__);
version = XGENE_AHCI_V1;
-   }
-   if (info->valid & ACPI_VALID_CID)
+   } else if (info->valid & ACPI_VALID_CID) {
version = XGENE_AHCI_V2;
+   }
}
}
 #endif

RE: [RFC qemu 0/4] A PV solution for live migration optimization

[Li, Liang Z]

> > This patch set is the QEMU side implementation.
> >
> > The virtio-balloon is extended so that QEMU can get the free pages
> > information from the guest through virtio.
> >
> > After getting the free pages information (a bitmap), QEMU can use it
> > to filter out the guest's free pages in the ram bulk stage. This make
> > the live migration process much more efficient.
> >
> > This RFC version doesn't take the post-copy and RDMA into
> > consideration, maybe both of them can benefit from this PV solution by
> > with some extra modifications.
> 
> I like the idea, just have to prove (review) and test it a lot to ensure we 
> don't
> end up skipping pages that matter.
> 
> However, there are a couple of points:
> 
> In my opinion, the information that's exchanged between the guest and the
> host should be exchanged over a virtio-serial channel rather than virtio-
> balloon.  First, there's nothing related to the balloon here.
> It just happens to be memory info.  Second, I would never enable balloon in
> a guest that I want to be performance-sensitive.  So even if you add this as
> part of balloon, you'll find no one is using this solution.
> 
> Secondly, I suggest virtio-serial, because it's meant exactly to exchange 
> free-
> flowing information between a host and a guest, and you don't need to
> extend any part of the protocol for it (hence no changes necessary to the
> spec).  You can see how spice, vnc, etc., use virtio-serial to exchange data.
> 
> 
>   Amit

Hi Amit,

 Could provide more information on how to use virtio-serial to exchange data?  
Thread , Wiki or code are all OK. 
 I have not find some useful information yet.

Thanks
Liang

Re: [PATCH] arc: use little endian accesses

[Alexey Brodkin]

Hi Vineet,

On Thu, 2016-03-10 at 05:05 +, Vineet Gupta wrote:
> +CC Noam
> 
> On Wednesday 09 March 2016 10:51 PM, Lada Trimasova wrote:
> > 
> > Memory access primitives should use cpu_to_le16, cpu_to_le32, le16_to_cpu
> > and le32_to_cpu because it is not really guaranteed that drivers handles
> > any ordering themselves.
> That is the driver issue. readxx as API simply returns data in native 
> endianness.
> We've had EZChip running big endian and so far and they didn't need this 
> change.

Let me disagree with you here.
See what is said in "include/asm-generic/io.h":
-->8-
/*
 * __raw_{read,write}{b,w,l,q}() access memory in native endianness.
 *
 * On some architectures memory mapped IO needs to be accessed differently.
 * On the simple architectures, we just read/write the memory location
 * directly.
 */

...

/*
 * {read,write}{b,w,l,q}() access little endian memory and return result in
 * native endianness.
 */
-->8-

And that's an implementation we have for ARC:
-->8-
#define readb(c)({ u8  __v = readb_relaxed(c); __iormb(); __v; 
})
#define readw(c)({ u16 __v = readw_relaxed(c); __iormb(); __v; 
})
#define readl(c)({ u32 __v = readl_relaxed(c); __iormb(); __v; 
})

#define writeb(v,c) ({ __iowmb(); writeb_relaxed(v,c); })
#define writew(v,c) ({ __iowmb(); writew_relaxed(v,c); })
#define writel(v,c) ({ __iowmb(); writel_relaxed(v,c); })

/*
 * Relaxed API for drivers which can handle any ordering themselves
 */
#define readb_relaxed(c)__raw_readb(c)
#define readw_relaxed(c)__raw_readw(c)
#define readl_relaxed(c)__raw_readl(c)

#define writeb_relaxed(v,c) __raw_writeb(v,c)
#define writew_relaxed(v,c) __raw_writew(v,c)
#define writel_relaxed(v,c) __raw_writel(v,c)
-->8-

Which is effectively (related to endianess discussion):
-->8-
#define readX(c)__raw_readX(c)
#define writeX(v,c) __raw_writeX(v,c)
-->8-

That looks IMHO incorrect if we read API description in 
"include/asm-generic/io.h".
BTW description of {read,write}{b,w,l,q}() is a bit misleading in part saying
"... and return result in __native_endianness__".

But real implementation of {read,write}{b,w,l,q}() in "include/asm-generic/io.h"
really shows what was meant - note __leXX_to_cpu() and cpu_to_leXX are used.

> > 
> > For example, serial port driver doesn't work when kernel is build for
> > arc big endian architecture.
> Last I tested Big Endian on SDP with 8250 part + 8250 driver it was working 
> fine.
> I presume this is the systemC model for device and standard 8250 driver and 
> very
> likely the model is not fixed endian or something.

Model is indeed little-endian. We build it only once and than changing
only "nsim_isa_big_endian" property (which changes only CPU core endianess) may 
use
it equally well with little- and big-endian builds of Linux kernel.

-Alexey

RE: [RFC qemu 0/4] A PV solution for live migration optimization

[Li, Liang Z]

> > This patch set is the QEMU side implementation.
> >
> > The virtio-balloon is extended so that QEMU can get the free pages
> > information from the guest through virtio.
> >
> > After getting the free pages information (a bitmap), QEMU can use it
> > to filter out the guest's free pages in the ram bulk stage. This make
> > the live migration process much more efficient.
> >
> > This RFC version doesn't take the post-copy and RDMA into
> > consideration, maybe both of them can benefit from this PV solution by
> > with some extra modifications.
> 
> I like the idea, just have to prove (review) and test it a lot to ensure we 
> don't
> end up skipping pages that matter.
> 
> However, there are a couple of points:
> 
> In my opinion, the information that's exchanged between the guest and the
> host should be exchanged over a virtio-serial channel rather than virtio-
> balloon.  First, there's nothing related to the balloon here.
> It just happens to be memory info.  Second, I would never enable balloon in
> a guest that I want to be performance-sensitive.  So even if you add this as
> part of balloon, you'll find no one is using this solution.
> 
> Secondly, I suggest virtio-serial, because it's meant exactly to exchange 
> free-
> flowing information between a host and a guest, and you don't need to
> extend any part of the protocol for it (hence no changes necessary to the
> spec).  You can see how spice, vnc, etc., use virtio-serial to exchange data.
> 
> 
>   Amit

Hi Amit,

 Could provide more information on how to use virtio-serial to exchange data?  
Thread , Wiki or code are all OK. 
 I have not find some useful information yet.

Thanks
Liang

Re: [PATCH] arc: use little endian accesses

[Alexey Brodkin]

Hi Vineet,

On Thu, 2016-03-10 at 05:05 +, Vineet Gupta wrote:
> +CC Noam
> 
> On Wednesday 09 March 2016 10:51 PM, Lada Trimasova wrote:
> > 
> > Memory access primitives should use cpu_to_le16, cpu_to_le32, le16_to_cpu
> > and le32_to_cpu because it is not really guaranteed that drivers handles
> > any ordering themselves.
> That is the driver issue. readxx as API simply returns data in native 
> endianness.
> We've had EZChip running big endian and so far and they didn't need this 
> change.

Let me disagree with you here.
See what is said in "include/asm-generic/io.h":
-->8-
/*
 * __raw_{read,write}{b,w,l,q}() access memory in native endianness.
 *
 * On some architectures memory mapped IO needs to be accessed differently.
 * On the simple architectures, we just read/write the memory location
 * directly.
 */

...

/*
 * {read,write}{b,w,l,q}() access little endian memory and return result in
 * native endianness.
 */
-->8-

And that's an implementation we have for ARC:
-->8-
#define readb(c)({ u8  __v = readb_relaxed(c); __iormb(); __v; 
})
#define readw(c)({ u16 __v = readw_relaxed(c); __iormb(); __v; 
})
#define readl(c)({ u32 __v = readl_relaxed(c); __iormb(); __v; 
})

#define writeb(v,c) ({ __iowmb(); writeb_relaxed(v,c); })
#define writew(v,c) ({ __iowmb(); writew_relaxed(v,c); })
#define writel(v,c) ({ __iowmb(); writel_relaxed(v,c); })

/*
 * Relaxed API for drivers which can handle any ordering themselves
 */
#define readb_relaxed(c)__raw_readb(c)
#define readw_relaxed(c)__raw_readw(c)
#define readl_relaxed(c)__raw_readl(c)

#define writeb_relaxed(v,c) __raw_writeb(v,c)
#define writew_relaxed(v,c) __raw_writew(v,c)
#define writel_relaxed(v,c) __raw_writel(v,c)
-->8-

Which is effectively (related to endianess discussion):
-->8-
#define readX(c)__raw_readX(c)
#define writeX(v,c) __raw_writeX(v,c)
-->8-

That looks IMHO incorrect if we read API description in 
"include/asm-generic/io.h".
BTW description of {read,write}{b,w,l,q}() is a bit misleading in part saying
"... and return result in __native_endianness__".

But real implementation of {read,write}{b,w,l,q}() in "include/asm-generic/io.h"
really shows what was meant - note __leXX_to_cpu() and cpu_to_leXX are used.

> > 
> > For example, serial port driver doesn't work when kernel is build for
> > arc big endian architecture.
> Last I tested Big Endian on SDP with 8250 part + 8250 driver it was working 
> fine.
> I presume this is the systemC model for device and standard 8250 driver and 
> very
> likely the model is not fixed endian or something.

Model is indeed little-endian. We build it only once and than changing
only "nsim_isa_big_endian" property (which changes only CPU core endianess) may 
use
it equally well with little- and big-endian builds of Linux kernel.

-Alexey

Re: [PATCH v3 06/22] media: Media Controller enable/disable source handler API

[Sakari Ailus]

Hi Shuah,

On Thu, Feb 11, 2016 at 04:41:22PM -0700, Shuah Khan wrote:
> Add new fields to struct media_device to add enable_source, and
> disable_source handlers, and source_priv to stash driver private
> data that is used to run these handlers. The enable_source handler
> finds source entity for the passed in entity and checks if it is
> available. When link is found, it activates it. Disable source
> handler deactivates the link.
> 
> Bridge driver is expected to implement and set these handlers.
> 
> Signed-off-by: Shuah Khan 
> ---
>  include/media/media-device.h | 30 ++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/include/media/media-device.h b/include/media/media-device.h
> index 075a482..1a04644 100644
> --- a/include/media/media-device.h
> +++ b/include/media/media-device.h
> @@ -302,6 +302,11 @@ struct media_entity_notify {
>   * @entity_notify: List of registered entity_notify callbacks
>   * @lock:Entities list lock
>   * @graph_mutex: Entities graph operation lock
> + *
> + * @source_priv: Driver Private data for enable/disable source handlers
> + * @enable_source: Enable Source Handler function pointer
> + * @disable_source: Disable Source Handler function pointer
> + *
>   * @link_notify: Link state change notification callback
>   *
>   * This structure represents an abstract high-level media device. It allows 
> easy
> @@ -313,6 +318,26 @@ struct media_entity_notify {
>   *
>   * @model is a descriptive model name exported through sysfs. It doesn't 
> have to
>   * be unique.
> + *
> + * @enable_source is a handler to find source entity for the
> + * sink entity  and activate the link between them if source
> + * entity is free. Drivers should call this handler before
> + * accessing the source.
> + *
> + * @disable_source is a handler to find source entity for the
> + * sink entity  and deactivate the link between them. Drivers
> + * should call this handler to release the source.
> + *

Is there a particular reason you're not simply (de)activating the link, but
instead add a new callback?

> + * Note: Bridge driver is expected to implement and set the
> + * handler when media_device is registered or when
> + * bridge driver finds the media_device during probe.
> + * Bridge driver sets source_priv with information
> + * necessary to run enable/disable source handlers.
> + *
> + * Use-case: find tuner entity connected to the decoder
> + * entity and check if it is available, and activate the
> + * the link between them from enable_source and deactivate
> + * from disable_source.
>   */
>  struct media_device {
>   /* dev->driver_data points to this struct. */
> @@ -344,6 +369,11 @@ struct media_device {
>   /* Serializes graph operations. */
>   struct mutex graph_mutex;
>  
> + void *source_priv;
> + int (*enable_source)(struct media_entity *entity,
> +  struct media_pipeline *pipe);
> + void (*disable_source)(struct media_entity *entity);
> +
>   int (*link_notify)(struct media_link *link, u32 flags,
>  unsigned int notification);
>  };

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v3 06/22] media: Media Controller enable/disable source handler API

[Sakari Ailus]

Hi Shuah,

On Thu, Feb 11, 2016 at 04:41:22PM -0700, Shuah Khan wrote:
> Add new fields to struct media_device to add enable_source, and
> disable_source handlers, and source_priv to stash driver private
> data that is used to run these handlers. The enable_source handler
> finds source entity for the passed in entity and checks if it is
> available. When link is found, it activates it. Disable source
> handler deactivates the link.
> 
> Bridge driver is expected to implement and set these handlers.
> 
> Signed-off-by: Shuah Khan 
> ---
>  include/media/media-device.h | 30 ++
>  1 file changed, 30 insertions(+)
> 
> diff --git a/include/media/media-device.h b/include/media/media-device.h
> index 075a482..1a04644 100644
> --- a/include/media/media-device.h
> +++ b/include/media/media-device.h
> @@ -302,6 +302,11 @@ struct media_entity_notify {
>   * @entity_notify: List of registered entity_notify callbacks
>   * @lock:Entities list lock
>   * @graph_mutex: Entities graph operation lock
> + *
> + * @source_priv: Driver Private data for enable/disable source handlers
> + * @enable_source: Enable Source Handler function pointer
> + * @disable_source: Disable Source Handler function pointer
> + *
>   * @link_notify: Link state change notification callback
>   *
>   * This structure represents an abstract high-level media device. It allows 
> easy
> @@ -313,6 +318,26 @@ struct media_entity_notify {
>   *
>   * @model is a descriptive model name exported through sysfs. It doesn't 
> have to
>   * be unique.
> + *
> + * @enable_source is a handler to find source entity for the
> + * sink entity  and activate the link between them if source
> + * entity is free. Drivers should call this handler before
> + * accessing the source.
> + *
> + * @disable_source is a handler to find source entity for the
> + * sink entity  and deactivate the link between them. Drivers
> + * should call this handler to release the source.
> + *

Is there a particular reason you're not simply (de)activating the link, but
instead add a new callback?

> + * Note: Bridge driver is expected to implement and set the
> + * handler when media_device is registered or when
> + * bridge driver finds the media_device during probe.
> + * Bridge driver sets source_priv with information
> + * necessary to run enable/disable source handlers.
> + *
> + * Use-case: find tuner entity connected to the decoder
> + * entity and check if it is available, and activate the
> + * the link between them from enable_source and deactivate
> + * from disable_source.
>   */
>  struct media_device {
>   /* dev->driver_data points to this struct. */
> @@ -344,6 +369,11 @@ struct media_device {
>   /* Serializes graph operations. */
>   struct mutex graph_mutex;
>  
> + void *source_priv;
> + int (*enable_source)(struct media_entity *entity,
> +  struct media_pipeline *pipe);
> + void (*disable_source)(struct media_entity *entity);
> +
>   int (*link_notify)(struct media_link *link, u32 flags,
>  unsigned int notification);
>  };

-- 
Kind regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [Qemu-devel] [RFC kernel 0/2]A PV solution for KVM live migration optimization

[Amit Shah]

On (Thu) 10 Mar 2016 [12:31:32], Jitendra Kolhe wrote:
> On 3/8/2016 4:44 PM, Amit Shah wrote:
>  Hi,
>    An interesting solution; I know a few different people have been 
>  looking at
>  how to speed up ballooned VM migration.
> 
> >>>
> >>> Ooh, different solutions for the same purpose, and both based on the 
> >>> balloon.
> >>
> >> We were also tying to address similar problem, without actually needing to 
> >> modify
> >> the guest driver. Please find patch details under mail with subject.
> >> migration: skip sending ram pages released by virtio-balloon driver
> >
> > The scope of this patch series seems to be wider: don't send free
> > pages to a dest at all, vs. don't send pages that are ballooned out.
> 
> Hi,
> 
> Thanks for your response. The scope of this patch series doesn’t seem to take 
> care 
> of ballooned out pages. To balloon out a guest ram page the guest balloon 
> driver does 
> a alloc_page() and then return the guest pfn to Qemu, so ballooned out pages 
> will not 
> be seen as free ram pages by the guest.
> Thus we will still end up scanning (for zero page) for ballooned out pages 
> during 
> migration. It would be ideal if we could have both solutions.

Yes, of course it would be nice to have both solutions.  My response was to the 
line:

> >>> Ooh, different solutions for the same purpose, and both based on the 
> >>> balloon.

which sounded misleading to me for a couple of reasons: 1, as you
describe, pages being considered by this patchset and yours are
different; and 2, as I mentioned in the other mail, this patchset
doesn't really depend on the balloon, and I believe it should not.


Amit

Re: [Qemu-devel] [RFC kernel 0/2]A PV solution for KVM live migration optimization

[Amit Shah]

On (Thu) 10 Mar 2016 [12:31:32], Jitendra Kolhe wrote:
> On 3/8/2016 4:44 PM, Amit Shah wrote:
>  Hi,
>    An interesting solution; I know a few different people have been 
>  looking at
>  how to speed up ballooned VM migration.
> 
> >>>
> >>> Ooh, different solutions for the same purpose, and both based on the 
> >>> balloon.
> >>
> >> We were also tying to address similar problem, without actually needing to 
> >> modify
> >> the guest driver. Please find patch details under mail with subject.
> >> migration: skip sending ram pages released by virtio-balloon driver
> >
> > The scope of this patch series seems to be wider: don't send free
> > pages to a dest at all, vs. don't send pages that are ballooned out.
> 
> Hi,
> 
> Thanks for your response. The scope of this patch series doesn’t seem to take 
> care 
> of ballooned out pages. To balloon out a guest ram page the guest balloon 
> driver does 
> a alloc_page() and then return the guest pfn to Qemu, so ballooned out pages 
> will not 
> be seen as free ram pages by the guest.
> Thus we will still end up scanning (for zero page) for ballooned out pages 
> during 
> migration. It would be ideal if we could have both solutions.

Yes, of course it would be nice to have both solutions.  My response was to the 
line:

> >>> Ooh, different solutions for the same purpose, and both based on the 
> >>> balloon.

which sounded misleading to me for a couple of reasons: 1, as you
describe, pages being considered by this patchset and yours are
different; and 2, as I mentioned in the other mail, this patchset
doesn't really depend on the balloon, and I believe it should not.


Amit

Re: [PATCH 1/5] ftrace perf: Check sample types only for sampling events

[Jiri Olsa]

On Thu, Mar 10, 2016 at 09:36:37AM +0900, Namhyung Kim wrote:
> Hi Jiri,
> 
> On Wed, Mar 09, 2016 at 09:46:41PM +0100, Jiri Olsa wrote:
> > Currently we check sample type for ftrace:function event
> > even if it's not created as sampling event. That prevents
> > creating ftrace_function event in counting mode.
> > 
> > Making sure we check sample types only for sampling events.
> > 
> > Before:
> >   $ sudo perf stat -e ftrace:function ls
> >   ...
> > 
> >Performance counter stats for 'ls':
> > 
> >ftrace:function
> > 
> >  0.001983662 seconds time elapsed
> > 
> > After:
> >   $ sudo perf stat -e ftrace:function ls
> >   ...
> > 
> >Performance counter stats for 'ls':
> > 
> >   44,498  ftrace:function
> > 
> >  0.037534722 seconds time elapsed
> > 
> > Signed-off-by: Jiri Olsa 
> > ---
> >  kernel/trace/trace_event_perf.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/kernel/trace/trace_event_perf.c 
> > b/kernel/trace/trace_event_perf.c
> > index 00df25fd86ef..a7171ec2c1ca 100644
> > --- a/kernel/trace/trace_event_perf.c
> > +++ b/kernel/trace/trace_event_perf.c
> > @@ -52,14 +52,14 @@ static int perf_trace_event_perm(struct 
> > trace_event_call *tp_event,
> >  * event, due to issues with page faults while tracing page
> >  * fault handler and its overall trickiness nature.
> >  */
> > -   if (!p_event->attr.exclude_callchain_user)
> > +   if (is_sampling_event(p_event) && 
> > !p_event->attr.exclude_callchain_user)
> > return -EINVAL;
> >  
> > /*
> >  * Same reason to disable user stack dump as for user space
> >  * callchains above.
> >  */
> > -   if (p_event->attr.sample_type & PERF_SAMPLE_STACK_USER)
> > +   if (is_sampling_event(p_event) && p_event->attr.sample_type & 
> > PERF_SAMPLE_STACK_USER)
> > return -EINVAL;
> > }
> >  
> 
> What about checking is_sampling_event() first and goto the last
> paranoid_tracepoint_raw check instead?  This way we can remove the
> same check in the function trace case.

right, will check

thanks,
jirka

Re: [PATCH 1/5] ftrace perf: Check sample types only for sampling events

[Jiri Olsa]

On Thu, Mar 10, 2016 at 09:36:37AM +0900, Namhyung Kim wrote:
> Hi Jiri,
> 
> On Wed, Mar 09, 2016 at 09:46:41PM +0100, Jiri Olsa wrote:
> > Currently we check sample type for ftrace:function event
> > even if it's not created as sampling event. That prevents
> > creating ftrace_function event in counting mode.
> > 
> > Making sure we check sample types only for sampling events.
> > 
> > Before:
> >   $ sudo perf stat -e ftrace:function ls
> >   ...
> > 
> >Performance counter stats for 'ls':
> > 
> >ftrace:function
> > 
> >  0.001983662 seconds time elapsed
> > 
> > After:
> >   $ sudo perf stat -e ftrace:function ls
> >   ...
> > 
> >Performance counter stats for 'ls':
> > 
> >   44,498  ftrace:function
> > 
> >  0.037534722 seconds time elapsed
> > 
> > Signed-off-by: Jiri Olsa 
> > ---
> >  kernel/trace/trace_event_perf.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/kernel/trace/trace_event_perf.c 
> > b/kernel/trace/trace_event_perf.c
> > index 00df25fd86ef..a7171ec2c1ca 100644
> > --- a/kernel/trace/trace_event_perf.c
> > +++ b/kernel/trace/trace_event_perf.c
> > @@ -52,14 +52,14 @@ static int perf_trace_event_perm(struct 
> > trace_event_call *tp_event,
> >  * event, due to issues with page faults while tracing page
> >  * fault handler and its overall trickiness nature.
> >  */
> > -   if (!p_event->attr.exclude_callchain_user)
> > +   if (is_sampling_event(p_event) && 
> > !p_event->attr.exclude_callchain_user)
> > return -EINVAL;
> >  
> > /*
> >  * Same reason to disable user stack dump as for user space
> >  * callchains above.
> >  */
> > -   if (p_event->attr.sample_type & PERF_SAMPLE_STACK_USER)
> > +   if (is_sampling_event(p_event) && p_event->attr.sample_type & 
> > PERF_SAMPLE_STACK_USER)
> > return -EINVAL;
> > }
> >  
> 
> What about checking is_sampling_event() first and goto the last
> paranoid_tracepoint_raw check instead?  This way we can remove the
> same check in the function trace case.

right, will check

thanks,
jirka

RE: [Qemu-devel] [RFC kernel 0/2]A PV solution for KVM live migration optimization

[Li, Liang Z]

> On 3/8/2016 4:44 PM, Amit Shah wrote:
> > On (Fri) 04 Mar 2016 [15:02:47], Jitendra Kolhe wrote:
> 
>  * Liang Li (liang.z...@intel.com) wrote:
> > The current QEMU live migration implementation mark the all the
> > guest's RAM pages as dirtied in the ram bulk stage, all these
> > pages will be processed and that takes quit a lot of CPU cycles.
> >
> > From guest's point of view, it doesn't care about the content in
> > free pages. We can make use of this fact and skip processing the
> > free pages in the ram bulk stage, it can save a lot CPU cycles and
> > reduce the network traffic significantly while speed up the live
> > migration process obviously.
> >
> > This patch set is the QEMU side implementation.
> >
> > The virtio-balloon is extended so that QEMU can get the free pages
> > information from the guest through virtio.
> >
> > After getting the free pages information (a bitmap), QEMU can use
> > it to filter out the guest's free pages in the ram bulk stage.
> > This make the live migration process much more efficient.
> 
>  Hi,
>    An interesting solution; I know a few different people have been
>  looking at how to speed up ballooned VM migration.
> 
> >>>
> >>> Ooh, different solutions for the same purpose, and both based on the
> balloon.
> >>
> >> We were also tying to address similar problem, without actually
> >> needing to modify the guest driver. Please find patch details under mail
> with subject.
> >> migration: skip sending ram pages released by virtio-balloon driver
> >
> > The scope of this patch series seems to be wider: don't send free
> > pages to a dest at all, vs. don't send pages that are ballooned out.
> >
> > Amit
> 
> Hi,
> 
> Thanks for your response. The scope of this patch series doesn’t seem to
> take care of ballooned out pages. To balloon out a guest ram page the guest
> balloon driver does a alloc_page() and then return the guest pfn to Qemu, so
> ballooned out pages will not be seen as free ram pages by the guest.
> Thus we will still end up scanning (for zero page) for ballooned out pages
> during migration. It would be ideal if we could have both solutions.
> 

Agree,  for users who care about the performance, just skipping the free pages.
For users who have already turned on virtio-balloon,  your solution can take 
effect.

Liang
> Thanks,
> - Jitendra

RE: [Qemu-devel] [RFC kernel 0/2]A PV solution for KVM live migration optimization

[Li, Liang Z]

> On 3/8/2016 4:44 PM, Amit Shah wrote:
> > On (Fri) 04 Mar 2016 [15:02:47], Jitendra Kolhe wrote:
> 
>  * Liang Li (liang.z...@intel.com) wrote:
> > The current QEMU live migration implementation mark the all the
> > guest's RAM pages as dirtied in the ram bulk stage, all these
> > pages will be processed and that takes quit a lot of CPU cycles.
> >
> > From guest's point of view, it doesn't care about the content in
> > free pages. We can make use of this fact and skip processing the
> > free pages in the ram bulk stage, it can save a lot CPU cycles and
> > reduce the network traffic significantly while speed up the live
> > migration process obviously.
> >
> > This patch set is the QEMU side implementation.
> >
> > The virtio-balloon is extended so that QEMU can get the free pages
> > information from the guest through virtio.
> >
> > After getting the free pages information (a bitmap), QEMU can use
> > it to filter out the guest's free pages in the ram bulk stage.
> > This make the live migration process much more efficient.
> 
>  Hi,
>    An interesting solution; I know a few different people have been
>  looking at how to speed up ballooned VM migration.
> 
> >>>
> >>> Ooh, different solutions for the same purpose, and both based on the
> balloon.
> >>
> >> We were also tying to address similar problem, without actually
> >> needing to modify the guest driver. Please find patch details under mail
> with subject.
> >> migration: skip sending ram pages released by virtio-balloon driver
> >
> > The scope of this patch series seems to be wider: don't send free
> > pages to a dest at all, vs. don't send pages that are ballooned out.
> >
> > Amit
> 
> Hi,
> 
> Thanks for your response. The scope of this patch series doesn’t seem to
> take care of ballooned out pages. To balloon out a guest ram page the guest
> balloon driver does a alloc_page() and then return the guest pfn to Qemu, so
> ballooned out pages will not be seen as free ram pages by the guest.
> Thus we will still end up scanning (for zero page) for ballooned out pages
> during migration. It would be ideal if we could have both solutions.
> 

Agree,  for users who care about the performance, just skipping the free pages.
For users who have already turned on virtio-balloon,  your solution can take 
effect.

Liang
> Thanks,
> - Jitendra

Re: [PATCH 4/5] gpio: of: Add support to have multiple gpios in gpio-hog

[Laxman Dewangan]

On Wednesday 09 March 2016 10:47 PM, Stephen Warren wrote:

On 03/09/2016 06:20 AM, Laxman Dewangan wrote:


On Wednesday 09 March 2016 11:58 AM, Markus Pargmann wrote:

* PGP Signed by an unknown key

Hi,

On Tue, Mar 08, 2016 at 05:32:07PM +0530, Laxman Dewangan wrote:

The child node for gpio hogs under gpio controller's node
provide the mechanism to automatic GPIO request and
configuration as part of the gpio-controller's driver
probe function.

Currently, property "gpio" takes one gpios for such
configuration. Add support to have multiple GPIOs in
this property so that multiple GPIOs of gpio-controller
can be configured by this mechanism with one child node.

So if I read this correctly you want to have multiple GPIOs with the
same line name? Why don't you use multiple child nodes with individual
line names?


There is cases on which particular functional configuration needs sets
of GPIO to set. On this case, making sub node for each GPIOs creates
lots of sub-nodes and  add complexity on readability, usability and
maintainability.
Example: for my board, I wanted to set GPIO H2 to input and H0 and H1 to
be output high.
Instead of three nodes, I can have two here:
gpio@0,6000d000 {
wlan_input {
gpio-hog;
gpios = ;
input;
};

wlan_output {
gpio-hog;
gpios = ;
output-high;
};
};

>

So here I am grouping the multiple output GPIO together.

This looks much similar if we have many GPIOs for one type of
configurations.

Even it looks better if we have something:
gpio@0,6000d000 {
wlan_control {
gpio-hog;
gpios-input = ;
gpios-output-high = ;
};
};


The problem with that is the description used when acquiring the GPIO 
is just "wlan_input", "wlan_output", or "wlan_control". There's 
nothing to indicate what those individual pins do (perhaps one is a 
reset signal, one is a regulator enable, etc.?) By requiring separate 
nodes for each GPIO, then the node name can provide a meaningful 
semantic name/description for each GPIO, which provides much more 
information.




On this case, we have already property "line-name" and passed the name 
of the gpio via this property.
The property names is "line-name" which is good for one string. We can 
support other property "line-names" with multiple string per GPIO index.


line-names = "wlan-reset", "wlan-enable";


If the approach in this patch is acceptable though, I think you want 
to update the description of "gpios" (in the GPIO hog definition 
section) in Documentation/devicetree/bindings/gpio/gpio.txt to mention 
that multiple GPIO entries are legal. Right now it says that property 
much contain exactly #gpio-cells, not a multiple of #gpio-cells.


I have 5th patch for this and will rearrange series as you suggested on 
5th patch.

Re: [PATCH 4/5] gpio: of: Add support to have multiple gpios in gpio-hog

[Laxman Dewangan]

On Wednesday 09 March 2016 10:47 PM, Stephen Warren wrote:

On 03/09/2016 06:20 AM, Laxman Dewangan wrote:


On Wednesday 09 March 2016 11:58 AM, Markus Pargmann wrote:

* PGP Signed by an unknown key

Hi,

On Tue, Mar 08, 2016 at 05:32:07PM +0530, Laxman Dewangan wrote:

The child node for gpio hogs under gpio controller's node
provide the mechanism to automatic GPIO request and
configuration as part of the gpio-controller's driver
probe function.

Currently, property "gpio" takes one gpios for such
configuration. Add support to have multiple GPIOs in
this property so that multiple GPIOs of gpio-controller
can be configured by this mechanism with one child node.

So if I read this correctly you want to have multiple GPIOs with the
same line name? Why don't you use multiple child nodes with individual
line names?


There is cases on which particular functional configuration needs sets
of GPIO to set. On this case, making sub node for each GPIOs creates
lots of sub-nodes and  add complexity on readability, usability and
maintainability.
Example: for my board, I wanted to set GPIO H2 to input and H0 and H1 to
be output high.
Instead of three nodes, I can have two here:
gpio@0,6000d000 {
wlan_input {
gpio-hog;
gpios = ;
input;
};

wlan_output {
gpio-hog;
gpios = ;
output-high;
};
};

>

So here I am grouping the multiple output GPIO together.

This looks much similar if we have many GPIOs for one type of
configurations.

Even it looks better if we have something:
gpio@0,6000d000 {
wlan_control {
gpio-hog;
gpios-input = ;
gpios-output-high = ;
};
};


The problem with that is the description used when acquiring the GPIO 
is just "wlan_input", "wlan_output", or "wlan_control". There's 
nothing to indicate what those individual pins do (perhaps one is a 
reset signal, one is a regulator enable, etc.?) By requiring separate 
nodes for each GPIO, then the node name can provide a meaningful 
semantic name/description for each GPIO, which provides much more 
information.




On this case, we have already property "line-name" and passed the name 
of the gpio via this property.
The property names is "line-name" which is good for one string. We can 
support other property "line-names" with multiple string per GPIO index.


line-names = "wlan-reset", "wlan-enable";


If the approach in this patch is acceptable though, I think you want 
to update the description of "gpios" (in the GPIO hog definition 
section) in Documentation/devicetree/bindings/gpio/gpio.txt to mention 
that multiple GPIO entries are legal. Right now it says that property 
much contain exactly #gpio-cells, not a multiple of #gpio-cells.


I have 5th patch for this and will rearrange series as you suggested on 
5th patch.

Re: [PATCH 3/5] gpio: of: Return error if gpio hog configuration failed

[Laxman Dewangan]

On Wednesday 09 March 2016 10:41 PM, Stephen Warren wrote:

On 03/08/2016 05:02 AM, Laxman Dewangan wrote:

If GPIO hog configuration failed while adding OF based
gpiochip() then return the error instead of ignoring it.

This helps of properly handling the gpio driver dependency.

When adding the gpio hog nodes for NVIDIA's Tegra210 platforms,
the gpio_hogd() fails with EPROBE_DEFER because pinctrl is not
ready at this time and gpio_request() for Tegra GPIO driver
returns error. The error was not causing the Tegra GPIO driver
to fail as the error was getting ignored.



diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c


@@ -218,9 +220,12 @@ static void of_gpiochip_scan_gpios(struct 
gpio_chip *chip)

  if (IS_ERR(desc))
  continue;

-if (gpiod_hog(desc, name, lflags, dflags))
-continue;
+ret = gpiod_hog(desc, name, lflags, dflags);
+if (ret < 0)
+return ret;
  }
+
+return 0;
  }


If there are multiple child nodes (which the code above is looping 
over), and the hog for entries 0, 1, 2 succeed and the hog for entry 3 
fails, don't you need to go back and unhog for nodes 0..2 so that the 
next time this function is called, those hogs won't already be in 
place thus preventing them from being hogged the second time around? 
Or does hogging not take ownership of the resource and thus prevent it 
from being acquired again?


The gpiolib take care per the error handling:

status = of_gpiochip_add(chip);
if (status)
goto err_remove_chip;

:::
err_remove_chip:
acpi_gpiochip_remove(chip);
gpiochip_free_hogs(chip);
of_gpiochip_remove(chip);

Re: [PATCH 3/5] gpio: of: Return error if gpio hog configuration failed

[Laxman Dewangan]

On Wednesday 09 March 2016 10:41 PM, Stephen Warren wrote:

On 03/08/2016 05:02 AM, Laxman Dewangan wrote:

If GPIO hog configuration failed while adding OF based
gpiochip() then return the error instead of ignoring it.

This helps of properly handling the gpio driver dependency.

When adding the gpio hog nodes for NVIDIA's Tegra210 platforms,
the gpio_hogd() fails with EPROBE_DEFER because pinctrl is not
ready at this time and gpio_request() for Tegra GPIO driver
returns error. The error was not causing the Tegra GPIO driver
to fail as the error was getting ignored.



diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c


@@ -218,9 +220,12 @@ static void of_gpiochip_scan_gpios(struct 
gpio_chip *chip)

  if (IS_ERR(desc))
  continue;

-if (gpiod_hog(desc, name, lflags, dflags))
-continue;
+ret = gpiod_hog(desc, name, lflags, dflags);
+if (ret < 0)
+return ret;
  }
+
+return 0;
  }


If there are multiple child nodes (which the code above is looping 
over), and the hog for entries 0, 1, 2 succeed and the hog for entry 3 
fails, don't you need to go back and unhog for nodes 0..2 so that the 
next time this function is called, those hogs won't already be in 
place thus preventing them from being hogged the second time around? 
Or does hogging not take ownership of the resource and thus prevent it 
from being acquired again?


The gpiolib take care per the error handling:

status = of_gpiochip_add(chip);
if (status)
goto err_remove_chip;

:::
err_remove_chip:
acpi_gpiochip_remove(chip);
gpiochip_free_hogs(chip);
of_gpiochip_remove(chip);

[PATCH 2/2] Staging: nvec: fix multiline comment style.

[Neha Rani]

This is a patch in nvec.c file that fixes a multiline comment found by 
checkpatch.pl tool

Signed-off-by: Neha Rani 
---
 drivers/staging/nvec/nvec.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 4ae44a5..57ad27a 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -508,8 +508,10 @@ static void nvec_rx_completed(struct nvec_chip *nvec)
 
spin_lock(>rx_lock);
 
-   /* add the received data to the work list
-  and move the ring buffer pointer to the next entry */
+   /**
+* add the received data to the work list
+* and move the ring buffer pointer to the next entry
+*/
list_add_tail(>rx->node, >rx_data);
 
spin_unlock(>rx_lock);
-- 
2.5.0

[PATCH 2/2] Staging: nvec: fix multiline comment style.

[Neha Rani]

This is a patch in nvec.c file that fixes a multiline comment found by 
checkpatch.pl tool

Signed-off-by: Neha Rani 
---
 drivers/staging/nvec/nvec.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 4ae44a5..57ad27a 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -508,8 +508,10 @@ static void nvec_rx_completed(struct nvec_chip *nvec)
 
spin_lock(>rx_lock);
 
-   /* add the received data to the work list
-  and move the ring buffer pointer to the next entry */
+   /**
+* add the received data to the work list
+* and move the ring buffer pointer to the next entry
+*/
list_add_tail(>rx->node, >rx_data);
 
spin_unlock(>rx_lock);
-- 
2.5.0

Re: [PATCH 2/5] gpio: gpiolib: Print error number if gpio hog failed

[Laxman Dewangan]

On Wednesday 09 March 2016 10:37 PM, Stephen Warren wrote:

On 03/08/2016 08:32 AM, Laxman Dewangan wrote:


On Tuesday 08 March 2016 07:52 PM, Thierry Reding wrote:

On Tue, Mar 08, 2016 at 05:32:05PM +0530, Laxman Dewangan wrote:


Signed-off-by: Laxman Dewangan 
---
  drivers/gpio/gpiolib.c | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index bc788b9..7575ebb 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2621,15 +2621,16 @@ int gpiod_hog(struct gpio_desc *desc, const
char *name,
  local_desc = gpiochip_request_own_desc(chip, hwnum, name);
  if (IS_ERR(local_desc)) {
-pr_err("requesting hog GPIO %s (chip %s, offset %d) 
failed\n",

-   name, chip->label, hwnum);
+status = PTR_ERR(local_desc);
+pr_err("requesting hog GPIO %s, chip %s, offset %d failed
%d\n",
+   name, chip->label, hwnum, status);

I find this type of format hard to read. I prefer a semi-colon to
separate the message from the failure reason (i.e. error code).

Besides that I don't understand why you're dropping the parentheses
around the "chip %s, offset %d", I found that easier on the eye.


I did to accommodate the  3 extra character ( %d) for string format on
that line as it was already near to 80 column.
Just did not want to split in multiple lines.


Note that strings shouldn't be split across lines since it makes it 
harder to grep for them. This is one case where the 80-column limit 
isn't strict, within reason.


OK, so not change the existing string, just add new  format.

Re: [PATCH 2/5] gpio: gpiolib: Print error number if gpio hog failed

[Laxman Dewangan]

On Wednesday 09 March 2016 10:37 PM, Stephen Warren wrote:

On 03/08/2016 08:32 AM, Laxman Dewangan wrote:


On Tuesday 08 March 2016 07:52 PM, Thierry Reding wrote:

On Tue, Mar 08, 2016 at 05:32:05PM +0530, Laxman Dewangan wrote:


Signed-off-by: Laxman Dewangan 
---
  drivers/gpio/gpiolib.c | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
index bc788b9..7575ebb 100644
--- a/drivers/gpio/gpiolib.c
+++ b/drivers/gpio/gpiolib.c
@@ -2621,15 +2621,16 @@ int gpiod_hog(struct gpio_desc *desc, const
char *name,
  local_desc = gpiochip_request_own_desc(chip, hwnum, name);
  if (IS_ERR(local_desc)) {
-pr_err("requesting hog GPIO %s (chip %s, offset %d) 
failed\n",

-   name, chip->label, hwnum);
+status = PTR_ERR(local_desc);
+pr_err("requesting hog GPIO %s, chip %s, offset %d failed
%d\n",
+   name, chip->label, hwnum, status);

I find this type of format hard to read. I prefer a semi-colon to
separate the message from the failure reason (i.e. error code).

Besides that I don't understand why you're dropping the parentheses
around the "chip %s, offset %d", I found that easier on the eye.


I did to accommodate the  3 extra character ( %d) for string format on
that line as it was already near to 80 column.
Just did not want to split in multiple lines.


Note that strings shouldn't be split across lines since it makes it 
harder to grep for them. This is one case where the 80-column limit 
isn't strict, within reason.


OK, so not change the existing string, just add new  format.

[PATCH] i2c: designware: Add device HID for future AMD I2C controller

[Xiangliang Yu]

Add device HID AMDI0010 to match the AMD ACPI Vendor ID (AMDI) that
was registered in http://www.uefi.org/acpi_id_list, and the I2C
controller on future AMD paltform will use the HID instead of AMD0010.

Signed-off-by: Xiangliang Yu 
---
 drivers/acpi/acpi_apd.c | 1 +
 drivers/i2c/busses/i2c-designware-platdrv.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c
index d507cf6..d0aad06 100644
--- a/drivers/acpi/acpi_apd.c
+++ b/drivers/acpi/acpi_apd.c
@@ -143,6 +143,7 @@ static const struct acpi_device_id acpi_apd_device_ids[] = {
/* Generic apd devices */
 #ifdef CONFIG_X86_AMD_PLATFORM_DEVICE
{ "AMD0010", APD_ADDR(cz_i2c_desc) },
+   { "AMDI0010", APD_ADDR(cz_i2c_desc) },
{ "AMD0020", APD_ADDR(cz_uart_desc) },
{ "AMD0030", },
 #endif
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c 
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 438f1b4..d656657 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -123,6 +123,7 @@ static const struct acpi_device_id dw_i2c_acpi_match[] = {
{ "80860F41", 0 },
{ "808622C1", 0 },
{ "AMD0010", ACCESS_INTR_MASK },
+   { "AMDI0010", ACCESS_INTR_MASK },
{ "AMDI0510", 0 },
{ "APMC0D0F", 0 },
{ }
-- 
1.9.1

[PATCH] i2c: designware: Add device HID for future AMD I2C controller

[Xiangliang Yu]

Add device HID AMDI0010 to match the AMD ACPI Vendor ID (AMDI) that
was registered in http://www.uefi.org/acpi_id_list, and the I2C
controller on future AMD paltform will use the HID instead of AMD0010.

Signed-off-by: Xiangliang Yu 
---
 drivers/acpi/acpi_apd.c | 1 +
 drivers/i2c/busses/i2c-designware-platdrv.c | 1 +
 2 files changed, 2 insertions(+)

diff --git a/drivers/acpi/acpi_apd.c b/drivers/acpi/acpi_apd.c
index d507cf6..d0aad06 100644
--- a/drivers/acpi/acpi_apd.c
+++ b/drivers/acpi/acpi_apd.c
@@ -143,6 +143,7 @@ static const struct acpi_device_id acpi_apd_device_ids[] = {
/* Generic apd devices */
 #ifdef CONFIG_X86_AMD_PLATFORM_DEVICE
{ "AMD0010", APD_ADDR(cz_i2c_desc) },
+   { "AMDI0010", APD_ADDR(cz_i2c_desc) },
{ "AMD0020", APD_ADDR(cz_uart_desc) },
{ "AMD0030", },
 #endif
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c 
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 438f1b4..d656657 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -123,6 +123,7 @@ static const struct acpi_device_id dw_i2c_acpi_match[] = {
{ "80860F41", 0 },
{ "808622C1", 0 },
{ "AMD0010", ACCESS_INTR_MASK },
+   { "AMDI0010", ACCESS_INTR_MASK },
{ "AMDI0510", 0 },
{ "APMC0D0F", 0 },
{ }
-- 
1.9.1

Re: [PATCH V2 5/6] thermal: max77620: Add thermal driver for reporting junction temp

[Laxman Dewangan]

On Thursday 10 March 2016 12:57 AM, Eduardo Valentin wrote:

* PGP Signed by an unknown key

On Wed, Mar 09, 2016 at 06:40:09PM +0530, Laxman Dewangan wrote:

Maxim Semiconductor Max77620 supports alarm interrupts when
its die temperature crosses 120C and 140C. These threshold
temperatures are not configurable.

Add thermal driver to register PMIC die temperature as thermal
zone sensor and capture the die temperature warning interrupts
to notifying the client.

Signed-off-by: Laxman Dewangan 

---
Changes from V1:
- checkpatch warning fix and simplifying the dev.of_node
   initialisation.

  drivers/thermal/Kconfig|  10 +++
  drivers/thermal/Makefile   |   1 +
  drivers/thermal/thermal-max77620.c | 151 +
  3 files changed, 162 insertions(+)
  create mode 100644 drivers/thermal/thermal-max77620.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 5e7c97a..fc856eb 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -194,6 +194,16 @@ config IMX_THERMAL
  cpufreq is used as the cooling device to throttle CPUs when the
  passive trip is crossed.
  
+config MAX77620_THERMAL

+   tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
+   depends on MFD_MAX77620
+   depends on OF

The previous question on compile test was more if we could add depends
on COMPILE_TEST flag. Sorry if I was not clear enough.


I am adding the flag here:

  
   config MAX77620_THERMAL

   tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
  -   depends on MFD_MAX77620
  +   depends on MFD_MAX77620 || COMPILE_TEST
  +   depends on HAS_IOMEM
  depends on OF
  help
Support for die junction temperature
warning alarm for Maxim


but I still cannot compile test the file because of the missing header.
drivers/thermal/thermal-max77620.c:16:32: fatal error:
linux/mfd/max77620.h: No such file or directory
  #include 


I wont be able to merge this as it is. We need to sort out the
dependency first.

I will update you once the mfd patches will merge as this header is on 
that patch.

Re: [PATCH V2 5/6] thermal: max77620: Add thermal driver for reporting junction temp

[Laxman Dewangan]

On Thursday 10 March 2016 12:57 AM, Eduardo Valentin wrote:

* PGP Signed by an unknown key

On Wed, Mar 09, 2016 at 06:40:09PM +0530, Laxman Dewangan wrote:

Maxim Semiconductor Max77620 supports alarm interrupts when
its die temperature crosses 120C and 140C. These threshold
temperatures are not configurable.

Add thermal driver to register PMIC die temperature as thermal
zone sensor and capture the die temperature warning interrupts
to notifying the client.

Signed-off-by: Laxman Dewangan 

---
Changes from V1:
- checkpatch warning fix and simplifying the dev.of_node
   initialisation.

  drivers/thermal/Kconfig|  10 +++
  drivers/thermal/Makefile   |   1 +
  drivers/thermal/thermal-max77620.c | 151 +
  3 files changed, 162 insertions(+)
  create mode 100644 drivers/thermal/thermal-max77620.c

diff --git a/drivers/thermal/Kconfig b/drivers/thermal/Kconfig
index 5e7c97a..fc856eb 100644
--- a/drivers/thermal/Kconfig
+++ b/drivers/thermal/Kconfig
@@ -194,6 +194,16 @@ config IMX_THERMAL
  cpufreq is used as the cooling device to throttle CPUs when the
  passive trip is crossed.
  
+config MAX77620_THERMAL

+   tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
+   depends on MFD_MAX77620
+   depends on OF

The previous question on compile test was more if we could add depends
on COMPILE_TEST flag. Sorry if I was not clear enough.


I am adding the flag here:

  
   config MAX77620_THERMAL

   tristate "Temperature sensor driver for Maxim MAX77620 PMIC"
  -   depends on MFD_MAX77620
  +   depends on MFD_MAX77620 || COMPILE_TEST
  +   depends on HAS_IOMEM
  depends on OF
  help
Support for die junction temperature
warning alarm for Maxim


but I still cannot compile test the file because of the missing header.
drivers/thermal/thermal-max77620.c:16:32: fatal error:
linux/mfd/max77620.h: No such file or directory
  #include 


I wont be able to merge this as it is. We need to sort out the
dependency first.

I will update you once the mfd patches will merge as this header is on 
that patch.

[PATCH] Staging: vt6655: fixed Warnings of more than 80 chars at a line in baseband.c

[nancygoel62]

This is a patch to the baseband.c file that fixes the warnings of more than 80 
characters at a line by the checkpatch.pl tool

Signed-off-by: Nancy Goel 
---
 drivers/staging/vt6655/baseband.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/vt6655/baseband.c 
b/drivers/staging/vt6655/baseband.c
index 1e6c0c4..88aff82 100644
--- a/drivers/staging/vt6655/baseband.c
+++ b/drivers/staging/vt6655/baseband.c
@@ -36,8 +36,10 @@
  * Revision History:
  *  06-10-2003 Bryan YC Fan:  Re-write codes to support VT3253 spec.
  *  08-07-2003 Bryan YC Fan:  Add MAXIM2827/2825 and RFMD2959 support.
- *  08-26-2003 Kyle Hsu:  Modify BBuGetFrameTime() and 
BBvCalculateParameter().
- *cancel the setting of MAC_REG_SOFTPWRCTL on 
BBbVT3253Init().
+ *  08-26-2003 Kyle Hsu:  Modify BBuGetFrameTime() and
+ *   
BBvCalculateParameter().
+ *cancel the setting of MAC_REG_SOFTPWRCTL
+ *   on 
BBbVT3253Init().
  *Add the comments.
  *  09-01-2003 Bryan YC Fan:  RF & BB tables updated.
  *Modified BBvLoopbackOn & BBvLoopbackOff().
@@ -2160,10 +2162,12 @@ bool BBbVT3253Init(struct vnt_private *priv)
 
 
/* {{ RobertYu:20050223, request by JerryChung */
-   /* Init ANT B select,TX Config CR09 = 0x61->0x45, 
0x45->0x41(VC1/VC2 define, make the ANT_A, ANT_B inverted) */
-   /*bResult &= BBbWriteEmbedded(dwIoBase,0x09,0x41);*/
-   /* Init ANT B select,RX Config CR10 = 0x28->0x2A, 
0x2A->0x28(VC1/VC2 define, make the ANT_A, ANT_B inverted) */
-   /*bResult &= BBbWriteEmbedded(dwIoBase,0x0a,0x28);*/
+   /* Init ANT B select,TX Config CR09 = 0x61->0x45, */
+   /* 0x45->0x41(VC1/VC2 define, make the ANT_A, ANT_B inverted) */
+   /* bResult &= BBbWriteEmbedded(dwIoBase,0x09,0x41);*/
+   /* Init ANT B select,RX Config CR10 = 0x28->0x2A, 0x2A->0x28 */
+   /* (VC1/VC2 define, make the ANT_A, ANT_B inverted) */
+   /* bResult &= BBbWriteEmbedded(dwIoBase,0x0a,0x28);*/
/* Select VC1/VC2, CR215 = 0x02->0x06 */
bResult &= BBbWriteEmbedded(priv, 0xd7, 0x06);
/* }} */
-- 
1.9.1

[PATCH] Staging: vt6655: fixed Warnings of more than 80 chars at a line in baseband.c

[nancygoel62]

This is a patch to the baseband.c file that fixes the warnings of more than 80 
characters at a line by the checkpatch.pl tool

Signed-off-by: Nancy Goel 
---
 drivers/staging/vt6655/baseband.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/vt6655/baseband.c 
b/drivers/staging/vt6655/baseband.c
index 1e6c0c4..88aff82 100644
--- a/drivers/staging/vt6655/baseband.c
+++ b/drivers/staging/vt6655/baseband.c
@@ -36,8 +36,10 @@
  * Revision History:
  *  06-10-2003 Bryan YC Fan:  Re-write codes to support VT3253 spec.
  *  08-07-2003 Bryan YC Fan:  Add MAXIM2827/2825 and RFMD2959 support.
- *  08-26-2003 Kyle Hsu:  Modify BBuGetFrameTime() and 
BBvCalculateParameter().
- *cancel the setting of MAC_REG_SOFTPWRCTL on 
BBbVT3253Init().
+ *  08-26-2003 Kyle Hsu:  Modify BBuGetFrameTime() and
+ *   
BBvCalculateParameter().
+ *cancel the setting of MAC_REG_SOFTPWRCTL
+ *   on 
BBbVT3253Init().
  *Add the comments.
  *  09-01-2003 Bryan YC Fan:  RF & BB tables updated.
  *Modified BBvLoopbackOn & BBvLoopbackOff().
@@ -2160,10 +2162,12 @@ bool BBbVT3253Init(struct vnt_private *priv)
 
 
/* {{ RobertYu:20050223, request by JerryChung */
-   /* Init ANT B select,TX Config CR09 = 0x61->0x45, 
0x45->0x41(VC1/VC2 define, make the ANT_A, ANT_B inverted) */
-   /*bResult &= BBbWriteEmbedded(dwIoBase,0x09,0x41);*/
-   /* Init ANT B select,RX Config CR10 = 0x28->0x2A, 
0x2A->0x28(VC1/VC2 define, make the ANT_A, ANT_B inverted) */
-   /*bResult &= BBbWriteEmbedded(dwIoBase,0x0a,0x28);*/
+   /* Init ANT B select,TX Config CR09 = 0x61->0x45, */
+   /* 0x45->0x41(VC1/VC2 define, make the ANT_A, ANT_B inverted) */
+   /* bResult &= BBbWriteEmbedded(dwIoBase,0x09,0x41);*/
+   /* Init ANT B select,RX Config CR10 = 0x28->0x2A, 0x2A->0x28 */
+   /* (VC1/VC2 define, make the ANT_A, ANT_B inverted) */
+   /* bResult &= BBbWriteEmbedded(dwIoBase,0x0a,0x28);*/
/* Select VC1/VC2, CR215 = 0x02->0x06 */
bResult &= BBbWriteEmbedded(priv, 0xd7, 0x06);
/* }} */
-- 
1.9.1

Re: [PATCH V2 0/6] thermal: add devm_ version of thermal_zone register and driver for max77620

[Laxman Dewangan]

On Thursday 10 March 2016 01:02 AM, Eduardo Valentin wrote:

* PGP Signed by an unknown key

On Wed, Mar 09, 2016 at 06:40:04PM +0530, Laxman Dewangan wrote:

The series add the devm_ version of thermal_zone_of_sensor_register/
unregister, interface details, and use this in new thermal driver
for max77620.

The header file for max77620 is part of MFD patch
https://lkml.org/lkml/2016/2/11/186

Changes from V1:
- Run checkpatch with --strict and fix all warnings.
- Added details of interfaces in spifs-api.txt
- Added DT binding doc.

Laxman Dewangan (6):
   thermal: doc: Add details of
 thermal_zone_of_sensor_{register,unregister}
   thermal: of-thermal: Add devm version of
 thermal_zone_of_sensor_register
   thermal: Add devm_thermal_zone_of_sensor_register() in managed devices
 list
   thermal: doc: Add details of
 devm_thermal_zone_of_sensor_{register,unregister}
   thermal: max77620: Add thermal driver for reporting junction temp
   thermal: Add DT binding doc for thermal of PMIC max77620


Add patches 1-3 in my tree. Patch 4 should probably go via documentation
tree. And patch 5 needs dependency to be sorted, and 6 need minor changes.


Thanks for accepting patches.

patch 5 needs mfd patches which is under review. So until that is 
merged, compilation will fail due to header dependency.


Will add complete information on example of patch 6.

Re: [PATCH V2 0/6] thermal: add devm_ version of thermal_zone register and driver for max77620

[Laxman Dewangan]

On Thursday 10 March 2016 01:02 AM, Eduardo Valentin wrote:

* PGP Signed by an unknown key

On Wed, Mar 09, 2016 at 06:40:04PM +0530, Laxman Dewangan wrote:

The series add the devm_ version of thermal_zone_of_sensor_register/
unregister, interface details, and use this in new thermal driver
for max77620.

The header file for max77620 is part of MFD patch
https://lkml.org/lkml/2016/2/11/186

Changes from V1:
- Run checkpatch with --strict and fix all warnings.
- Added details of interfaces in spifs-api.txt
- Added DT binding doc.

Laxman Dewangan (6):
   thermal: doc: Add details of
 thermal_zone_of_sensor_{register,unregister}
   thermal: of-thermal: Add devm version of
 thermal_zone_of_sensor_register
   thermal: Add devm_thermal_zone_of_sensor_register() in managed devices
 list
   thermal: doc: Add details of
 devm_thermal_zone_of_sensor_{register,unregister}
   thermal: max77620: Add thermal driver for reporting junction temp
   thermal: Add DT binding doc for thermal of PMIC max77620


Add patches 1-3 in my tree. Patch 4 should probably go via documentation
tree. And patch 5 needs dependency to be sorted, and 6 need minor changes.


Thanks for accepting patches.

patch 5 needs mfd patches which is under review. So until that is 
merged, compilation will fail due to header dependency.


Will add complete information on example of patch 6.

[PATCH 2/2] spi: rockchip: covert rsd_nsecs to u32 type

[Shawn Lin]

rsd_nsecs is defined as u8 memeber of struct rockchip_spi,
but using of_property_read_u32. That means we take risk of
truncation by type conversion if we pass on big value from
dt.

Signed-off-by: Shawn Lin 
---

 drivers/spi/spi-rockchip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 7a4a131..26e2688 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -173,7 +173,7 @@ struct rockchip_spi {
u8 tmode;
u8 bpw;
u8 n_bytes;
-   u8 rsd_nsecs;
+   u32 rsd_nsecs;
unsigned len;
u32 speed;
 
-- 
2.3.7

[PATCH 2/2] spi: rockchip: covert rsd_nsecs to u32 type

[Shawn Lin]

rsd_nsecs is defined as u8 memeber of struct rockchip_spi,
but using of_property_read_u32. That means we take risk of
truncation by type conversion if we pass on big value from
dt.

Signed-off-by: Shawn Lin 
---

 drivers/spi/spi-rockchip.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 7a4a131..26e2688 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -173,7 +173,7 @@ struct rockchip_spi {
u8 tmode;
u8 bpw;
u8 n_bytes;
-   u8 rsd_nsecs;
+   u32 rsd_nsecs;
unsigned len;
u32 speed;
 
-- 
2.3.7

Re: [Qemu-devel] [RFC kernel 0/2]A PV solution for KVM live migration optimization

[Jitendra Kolhe]

On 3/8/2016 4:44 PM, Amit Shah wrote:
> On (Fri) 04 Mar 2016 [15:02:47], Jitendra Kolhe wrote:

 * Liang Li (liang.z...@intel.com) wrote:
> The current QEMU live migration implementation mark the all the
> guest's RAM pages as dirtied in the ram bulk stage, all these pages
> will be processed and that takes quit a lot of CPU cycles.
>
> From guest's point of view, it doesn't care about the content in free
> pages. We can make use of this fact and skip processing the free pages
> in the ram bulk stage, it can save a lot CPU cycles and reduce the
> network traffic significantly while speed up the live migration
> process obviously.
>
> This patch set is the QEMU side implementation.
>
> The virtio-balloon is extended so that QEMU can get the free pages
> information from the guest through virtio.
>
> After getting the free pages information (a bitmap), QEMU can use it
> to filter out the guest's free pages in the ram bulk stage. This make
> the live migration process much more efficient.

 Hi,
   An interesting solution; I know a few different people have been looking 
 at
 how to speed up ballooned VM migration.

>>>
>>> Ooh, different solutions for the same purpose, and both based on the 
>>> balloon.
>>
>> We were also tying to address similar problem, without actually needing to 
>> modify
>> the guest driver. Please find patch details under mail with subject.
>> migration: skip sending ram pages released by virtio-balloon driver
>
> The scope of this patch series seems to be wider: don't send free
> pages to a dest at all, vs. don't send pages that are ballooned out.
>
>   Amit

Hi,

Thanks for your response. The scope of this patch series doesn’t seem to take 
care 
of ballooned out pages. To balloon out a guest ram page the guest balloon 
driver does 
a alloc_page() and then return the guest pfn to Qemu, so ballooned out pages 
will not 
be seen as free ram pages by the guest.
Thus we will still end up scanning (for zero page) for ballooned out pages 
during 
migration. It would be ideal if we could have both solutions.

Thanks,
- Jitendra

Re: [Qemu-devel] [RFC kernel 0/2]A PV solution for KVM live migration optimization

[Jitendra Kolhe]

On 3/8/2016 4:44 PM, Amit Shah wrote:
> On (Fri) 04 Mar 2016 [15:02:47], Jitendra Kolhe wrote:

 * Liang Li (liang.z...@intel.com) wrote:
> The current QEMU live migration implementation mark the all the
> guest's RAM pages as dirtied in the ram bulk stage, all these pages
> will be processed and that takes quit a lot of CPU cycles.
>
> From guest's point of view, it doesn't care about the content in free
> pages. We can make use of this fact and skip processing the free pages
> in the ram bulk stage, it can save a lot CPU cycles and reduce the
> network traffic significantly while speed up the live migration
> process obviously.
>
> This patch set is the QEMU side implementation.
>
> The virtio-balloon is extended so that QEMU can get the free pages
> information from the guest through virtio.
>
> After getting the free pages information (a bitmap), QEMU can use it
> to filter out the guest's free pages in the ram bulk stage. This make
> the live migration process much more efficient.

 Hi,
   An interesting solution; I know a few different people have been looking 
 at
 how to speed up ballooned VM migration.

>>>
>>> Ooh, different solutions for the same purpose, and both based on the 
>>> balloon.
>>
>> We were also tying to address similar problem, without actually needing to 
>> modify
>> the guest driver. Please find patch details under mail with subject.
>> migration: skip sending ram pages released by virtio-balloon driver
>
> The scope of this patch series seems to be wider: don't send free
> pages to a dest at all, vs. don't send pages that are ballooned out.
>
>   Amit

Hi,

Thanks for your response. The scope of this patch series doesn’t seem to take 
care 
of ballooned out pages. To balloon out a guest ram page the guest balloon 
driver does 
a alloc_page() and then return the guest pfn to Qemu, so ballooned out pages 
will not 
be seen as free ram pages by the guest.
Thus we will still end up scanning (for zero page) for ballooned out pages 
during 
migration. It would be ideal if we could have both solutions.

Thanks,
- Jitendra

[PATCH 1/2] spi: rockchip: header file cleanup

[Shawn Lin]

Remove some of unused header files and reoder
it into alphabetical order.

Signed-off-by: Shawn Lin 
---

 drivers/spi/spi-rockchip.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 7bdbeef..7a4a131 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -13,20 +13,14 @@
  *
  */
 
-#include 
-#include 
 #include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
 #include 
-#include 
 #include 
-#include 
-#include 
 #include 
-#include 
-#include 
+#include 
 
 #define DRIVER_NAME "rockchip-spi"
 
-- 
2.3.7

[PATCH 1/2] spi: rockchip: header file cleanup

[Shawn Lin]

Remove some of unused header files and reoder
it into alphabetical order.

Signed-off-by: Shawn Lin 
---

 drivers/spi/spi-rockchip.c | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/spi/spi-rockchip.c b/drivers/spi/spi-rockchip.c
index 7bdbeef..7a4a131 100644
--- a/drivers/spi/spi-rockchip.c
+++ b/drivers/spi/spi-rockchip.c
@@ -13,20 +13,14 @@
  *
  */
 
-#include 
-#include 
 #include 
-#include 
-#include 
-#include 
+#include 
+#include 
+#include 
 #include 
-#include 
 #include 
-#include 
-#include 
 #include 
-#include 
-#include 
+#include 
 
 #define DRIVER_NAME "rockchip-spi"
 
-- 
2.3.7

[PATCH 2/5] Staging: comedi: fix WARNING issue in s626.c

[Ravishankar Karkala Mallikarjunayya]

This is a patch to the s626.c file that fixes up a  Block comments issues
found by the checkpatch.pl tool.

i.e. Block comments use a trailing */ on a separate line

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
 drivers/staging/comedi/drivers/s626.c | 38 ++-
 1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index 5469ca0..6ebae3a 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -77,23 +77,30 @@ struct s626_buffer_dma {
 struct s626_private {
u8 ai_cmd_running;  /* ai_cmd is running */
unsigned int ai_sample_timer;   /* time between samples in
-* units of the timer */
+* units of the timer
+*/
int ai_convert_count;   /* conversion counter */
unsigned int ai_convert_timer;  /* time between conversion in
-* units of the timer */
-   u16 counter_int_enabs;  /* counter interrupt enable mask
-* for MISC2 register */
+* units of the timer
+*/
+   u16 counter_int_enabs;  /* counter interrupt enable mask
+* for MISC2 register
+*/
u8 adc_items;   /* number of items in ADC poll list */
struct s626_buffer_dma rps_buf; /* DMA buffer used to hold ADC (RPS1)
-* program */
+* program
+*/
struct s626_buffer_dma ana_buf; /* DMA buffer used to receive ADC data
-* and hold DAC data */
-   u32 *dac_wbuf;  /* pointer to logical adrs of DMA buffer
-* used to hold DAC data */
+* and hold DAC data
+*/
+   u32 *dac_wbuf;  /* pointer to logical adrs of DMA buffer
+* used to hold DAC data
+*/
u16 dacpol; /* image of DAC polarity register */
u8 trim_setpoint[12];   /* images of TrimDAC setpoints */
-   u32 i2c_adrs;   /* I2C device address for onboard EEPROM
-* (board rev dependent) */
+   u32 i2c_adrs;   /* I2C device address for onboard EEPROM
+* (board rev dependent)
+*/
 };
 
 /* Counter overflow/index event flag masks for RDMISC2. */
@@ -572,11 +579,14 @@ static int s626_set_dac(struct comedi_device *dev,
 * running after the packet has been sent to the target DAC.
 */
val = 0x0F00;   /* Continue clock after target DAC data
-* (write to non-existent trimdac). */
+* (write to non-existent trimdac).
+*/
val |= 0x4000;  /* Address the two main dual-DAC devices
-* (TSL's chip select enables target device). */
-   val |= ((u32)(chan & 1) << 15); /* Address the DAC channel
-* within the device. */
+* (TSL's chip select enables target device).
+*/
+   val |= ((u32)(chan & 1) << 15); /* Address the DAC channel
+* within the device.
+*/
val |= (u32)dacdata;/* Include DAC setpoint data. */
return s626_send_dac(dev, val);
 }
-- 
1.9.1

[PATCH 2/5] Staging: comedi: fix WARNING issue in s626.c

[Ravishankar Karkala Mallikarjunayya]

This is a patch to the s626.c file that fixes up a  Block comments issues
found by the checkpatch.pl tool.

i.e. Block comments use a trailing */ on a separate line

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
 drivers/staging/comedi/drivers/s626.c | 38 ++-
 1 file changed, 24 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index 5469ca0..6ebae3a 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -77,23 +77,30 @@ struct s626_buffer_dma {
 struct s626_private {
u8 ai_cmd_running;  /* ai_cmd is running */
unsigned int ai_sample_timer;   /* time between samples in
-* units of the timer */
+* units of the timer
+*/
int ai_convert_count;   /* conversion counter */
unsigned int ai_convert_timer;  /* time between conversion in
-* units of the timer */
-   u16 counter_int_enabs;  /* counter interrupt enable mask
-* for MISC2 register */
+* units of the timer
+*/
+   u16 counter_int_enabs;  /* counter interrupt enable mask
+* for MISC2 register
+*/
u8 adc_items;   /* number of items in ADC poll list */
struct s626_buffer_dma rps_buf; /* DMA buffer used to hold ADC (RPS1)
-* program */
+* program
+*/
struct s626_buffer_dma ana_buf; /* DMA buffer used to receive ADC data
-* and hold DAC data */
-   u32 *dac_wbuf;  /* pointer to logical adrs of DMA buffer
-* used to hold DAC data */
+* and hold DAC data
+*/
+   u32 *dac_wbuf;  /* pointer to logical adrs of DMA buffer
+* used to hold DAC data
+*/
u16 dacpol; /* image of DAC polarity register */
u8 trim_setpoint[12];   /* images of TrimDAC setpoints */
-   u32 i2c_adrs;   /* I2C device address for onboard EEPROM
-* (board rev dependent) */
+   u32 i2c_adrs;   /* I2C device address for onboard EEPROM
+* (board rev dependent)
+*/
 };
 
 /* Counter overflow/index event flag masks for RDMISC2. */
@@ -572,11 +579,14 @@ static int s626_set_dac(struct comedi_device *dev,
 * running after the packet has been sent to the target DAC.
 */
val = 0x0F00;   /* Continue clock after target DAC data
-* (write to non-existent trimdac). */
+* (write to non-existent trimdac).
+*/
val |= 0x4000;  /* Address the two main dual-DAC devices
-* (TSL's chip select enables target device). */
-   val |= ((u32)(chan & 1) << 15); /* Address the DAC channel
-* within the device. */
+* (TSL's chip select enables target device).
+*/
+   val |= ((u32)(chan & 1) << 15); /* Address the DAC channel
+* within the device.
+*/
val |= (u32)dacdata;/* Include DAC setpoint data. */
return s626_send_dac(dev, val);
 }
-- 
1.9.1

[PATCH 5/5] Staging: comedi: fix type issue in ni_tio.c

[Ravishankar Karkala Mallikarjunayya]

This is a patch to the ni_tio.c file that fixes up a type issues
found by the checkpatch.pl tool.
i.e. Prefer kernel type 'u64' over 'uint64_t'

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
 drivers/staging/comedi/drivers/ni_tio.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_tio.c 
b/drivers/staging/comedi/drivers/ni_tio.c
index f006805..0ee6d6c 100644
--- a/drivers/staging/comedi/drivers/ni_tio.c
+++ b/drivers/staging/comedi/drivers/ni_tio.c
@@ -189,7 +189,7 @@ static void ni_tio_reset_count_and_disarm(struct ni_gpct 
*counter)
 static uint64_t ni_tio_clock_period_ps(const struct ni_gpct *counter,
   unsigned generic_clock_source)
 {
-   uint64_t clock_period_ps;
+   u64 clock_period_ps;
 
switch (generic_clock_source & NI_GPCT_CLOCK_SRC_SELECT_MASK) {
case NI_GPCT_TIMEBASE_1_CLOCK_SRC_BITS:
@@ -385,9 +385,9 @@ static void ni_tio_set_sync_mode(struct ni_gpct *counter, 
int force_alt_sync)
struct ni_gpct_device *counter_dev = counter->counter_dev;
unsigned cidx = counter->counter_index;
const unsigned counting_mode_reg = NITIO_CNT_MODE_REG(cidx);
-   static const uint64_t min_normal_sync_period_ps = 25000;
+   static const u64 min_normal_sync_period_ps = 25000;
unsigned mode;
-   uint64_t clock_period_ps;
+   u64 clock_period_ps;
 
if (ni_tio_counting_mode_registers_present(counter_dev) == 0)
return;
@@ -730,7 +730,7 @@ static void ni_tio_get_clock_src(struct ni_gpct *counter,
 unsigned int *clock_source,
 unsigned int *period_ns)
 {
-   uint64_t temp64;
+   u64 temp64;
 
*clock_source = ni_tio_generic_clock_src_select(counter);
temp64 = ni_tio_clock_period_ps(counter, *clock_source);
-- 
1.9.1

[PATCH 3/5] Staging: comedi: fix WARNING issue in s626.c

[Ravishankar Karkala Mallikarjunayya]

This is a patch to the s626.c file that fixes up a  line over
80 characters issues found by the checkpatch.pl tool.

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
 drivers/staging/comedi/drivers/s626.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index 6ebae3a..2a5e650 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -2543,7 +2543,8 @@ static int s626_initialize(struct comedi_device *dev)
for (i = 0; i < 2; i++) {
writel(S626_I2C_CLKSEL, dev->mmio + S626_P_I2CSTAT);
s626_mc_enable(dev, S626_MC2_UPLD_IIC, S626_P_MC2);
-   ret = comedi_timeout(dev, NULL, NULL, s626_i2c_handshake_eoc, 
0);
+   ret = comedi_timeout(dev, NULL, NULL, s626_i2c_handshake_eoc,
+0);
if (ret)
return ret;
}
-- 
1.9.1

Re: [PATCH 4/4] media: au0828 change vidioc_s_input() to call v4l_change_media_source()

[kbuild test robot]

Hi Shuah,

[auto build test ERROR on sailus-media/master]
[cannot apply to v4.5-rc7 next-20160309]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Shuah-Khan/media-add-change_source-handler-support/20160310-131140
base:   git://linuxtv.org/media_tree.git master
config: x86_64-rhel (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/media/usb/au0828/au0828-video.c: In function 'vidioc_s_input':
>> drivers/media/usb/au0828/au0828-video.c:1474:2: error: implicit declaration 
>> of function 'v4l_change_media_source' [-Werror=implicit-function-declaration]
 return v4l_change_media_source(vfd);
 ^
   cc1: some warnings being treated as errors

vim +/v4l_change_media_source +1474 drivers/media/usb/au0828/au0828-video.c

  1468  au0828_s_input(dev, index);
  1469  
  1470  /*
  1471   * Input has been changed. Change to media source
  1472   * associated with the for the newly set input.
  1473   */
> 1474  return v4l_change_media_source(vfd);
  1475  }
  1476  
  1477  static int vidioc_enumaudio(struct file *file, void *priv, struct 
v4l2_audio *a)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH 5/5] Staging: comedi: fix type issue in ni_tio.c

[Ravishankar Karkala Mallikarjunayya]

This is a patch to the ni_tio.c file that fixes up a type issues
found by the checkpatch.pl tool.
i.e. Prefer kernel type 'u64' over 'uint64_t'

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
 drivers/staging/comedi/drivers/ni_tio.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_tio.c 
b/drivers/staging/comedi/drivers/ni_tio.c
index f006805..0ee6d6c 100644
--- a/drivers/staging/comedi/drivers/ni_tio.c
+++ b/drivers/staging/comedi/drivers/ni_tio.c
@@ -189,7 +189,7 @@ static void ni_tio_reset_count_and_disarm(struct ni_gpct 
*counter)
 static uint64_t ni_tio_clock_period_ps(const struct ni_gpct *counter,
   unsigned generic_clock_source)
 {
-   uint64_t clock_period_ps;
+   u64 clock_period_ps;
 
switch (generic_clock_source & NI_GPCT_CLOCK_SRC_SELECT_MASK) {
case NI_GPCT_TIMEBASE_1_CLOCK_SRC_BITS:
@@ -385,9 +385,9 @@ static void ni_tio_set_sync_mode(struct ni_gpct *counter, 
int force_alt_sync)
struct ni_gpct_device *counter_dev = counter->counter_dev;
unsigned cidx = counter->counter_index;
const unsigned counting_mode_reg = NITIO_CNT_MODE_REG(cidx);
-   static const uint64_t min_normal_sync_period_ps = 25000;
+   static const u64 min_normal_sync_period_ps = 25000;
unsigned mode;
-   uint64_t clock_period_ps;
+   u64 clock_period_ps;
 
if (ni_tio_counting_mode_registers_present(counter_dev) == 0)
return;
@@ -730,7 +730,7 @@ static void ni_tio_get_clock_src(struct ni_gpct *counter,
 unsigned int *clock_source,
 unsigned int *period_ns)
 {
-   uint64_t temp64;
+   u64 temp64;
 
*clock_source = ni_tio_generic_clock_src_select(counter);
temp64 = ni_tio_clock_period_ps(counter, *clock_source);
-- 
1.9.1

[PATCH 3/5] Staging: comedi: fix WARNING issue in s626.c

[Ravishankar Karkala Mallikarjunayya]

This is a patch to the s626.c file that fixes up a  line over
80 characters issues found by the checkpatch.pl tool.

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
 drivers/staging/comedi/drivers/s626.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index 6ebae3a..2a5e650 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -2543,7 +2543,8 @@ static int s626_initialize(struct comedi_device *dev)
for (i = 0; i < 2; i++) {
writel(S626_I2C_CLKSEL, dev->mmio + S626_P_I2CSTAT);
s626_mc_enable(dev, S626_MC2_UPLD_IIC, S626_P_MC2);
-   ret = comedi_timeout(dev, NULL, NULL, s626_i2c_handshake_eoc, 
0);
+   ret = comedi_timeout(dev, NULL, NULL, s626_i2c_handshake_eoc,
+0);
if (ret)
return ret;
}
-- 
1.9.1

Re: [PATCH 4/4] media: au0828 change vidioc_s_input() to call v4l_change_media_source()

[kbuild test robot]

Hi Shuah,

[auto build test ERROR on sailus-media/master]
[cannot apply to v4.5-rc7 next-20160309]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Shuah-Khan/media-add-change_source-handler-support/20160310-131140
base:   git://linuxtv.org/media_tree.git master
config: x86_64-rhel (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/media/usb/au0828/au0828-video.c: In function 'vidioc_s_input':
>> drivers/media/usb/au0828/au0828-video.c:1474:2: error: implicit declaration 
>> of function 'v4l_change_media_source' [-Werror=implicit-function-declaration]
 return v4l_change_media_source(vfd);
 ^
   cc1: some warnings being treated as errors

vim +/v4l_change_media_source +1474 drivers/media/usb/au0828/au0828-video.c

  1468  au0828_s_input(dev, index);
  1469  
  1470  /*
  1471   * Input has been changed. Change to media source
  1472   * associated with the for the newly set input.
  1473   */
> 1474  return v4l_change_media_source(vfd);
  1475  }
  1476  
  1477  static int vidioc_enumaudio(struct file *file, void *priv, struct 
v4l2_audio *a)

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH 4/5] Staging: comedi: fix CHECK issue in ni_tio.c

[Ravishankar Karkala Mallikarjunayya]

This is a patch to the ni_tio.c file that fixes up a CHECK issues
found by the checkpatch.pl tool.

i.e. Avoid crashing the kernel - try using WARN_ON & recovery code
rather than BUG() or BUG_ON().

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
 drivers/staging/comedi/drivers/ni_tio.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_tio.c 
b/drivers/staging/comedi/drivers/ni_tio.c
index b74e44e..f006805 100644
--- a/drivers/staging/comedi/drivers/ni_tio.c
+++ b/drivers/staging/comedi/drivers/ni_tio.c
@@ -222,7 +222,7 @@ static uint64_t ni_tio_clock_period_ps(const struct ni_gpct 
*counter,
clock_period_ps *= 8;
break;
default:
-   BUG();
+   WARN_ON(1);
break;
}
return clock_period_ps;
@@ -304,7 +304,7 @@ static unsigned ni_m_series_clock_src_select(const struct 
ni_gpct *counter)
}
if (i <= NI_M_MAX_PFI_CHAN)
break;
-   BUG();
+   WARN_ON(1);
break;
}
clock_source |= ni_tio_clock_src_modifiers(counter);
@@ -361,7 +361,7 @@ static unsigned ni_660x_clock_src_select(const struct 
ni_gpct *counter)
}
if (i <= NI_660X_MAX_SRC_PIN)
break;
-   BUG();
+   WARN_ON(1);
break;
}
clock_source |= ni_tio_clock_src_modifiers(counter);
@@ -584,7 +584,7 @@ static unsigned ni_660x_clk_src(unsigned int clock_source)
if (i <= NI_660X_MAX_SRC_PIN)
break;
ni_660x_clock = 0;
-   BUG();
+   WARN_ON(1);
break;
}
return GI_SRC_SEL(ni_660x_clock);
@@ -643,7 +643,7 @@ static unsigned ni_m_clk_src(unsigned int clock_source)
break;
pr_err("invalid clock source 0x%lx\n",
   (unsigned long)clock_source);
-   BUG();
+   WARN_ON(1);
ni_m_series_clock = 0;
break;
}
@@ -946,7 +946,7 @@ int ni_tio_set_gate_src(struct ni_gpct *counter, unsigned 
gate_index,
case ni_gpct_variant_660x:
return ni_660x_set_gate2(counter, gate_source);
default:
-   BUG();
+   WARN_ON(1);
break;
}
break;
@@ -1015,7 +1015,7 @@ static unsigned ni_660x_gate_to_generic_gate(unsigned 
gate)
if (gate == NI_660X_PIN_GATE_SEL(i))
return NI_GPCT_GATE_PIN_GATE_SELECT(i);
}
-   BUG();
+   WARN_ON(1);
break;
}
return 0;
@@ -1051,7 +1051,7 @@ static unsigned ni_m_gate_to_generic_gate(unsigned gate)
if (gate == NI_M_PFI_GATE_SEL(i))
return NI_GPCT_PFI_GATE_SELECT(i);
}
-   BUG();
+   WARN_ON(1);
break;
}
return 0;
@@ -1083,7 +1083,7 @@ static unsigned ni_660x_gate2_to_generic_gate(unsigned 
gate)
if (gate == NI_660X_UD_PIN_GATE2_SEL(i))
return NI_GPCT_UP_DOWN_PIN_GATE_SELECT(i);
}
-   BUG();
+   WARN_ON(1);
break;
}
return 0;
-- 
1.9.1

[PATCH 4/5] Staging: comedi: fix CHECK issue in ni_tio.c

[Ravishankar Karkala Mallikarjunayya]

This is a patch to the ni_tio.c file that fixes up a CHECK issues
found by the checkpatch.pl tool.

i.e. Avoid crashing the kernel - try using WARN_ON & recovery code
rather than BUG() or BUG_ON().

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
 drivers/staging/comedi/drivers/ni_tio.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/staging/comedi/drivers/ni_tio.c 
b/drivers/staging/comedi/drivers/ni_tio.c
index b74e44e..f006805 100644
--- a/drivers/staging/comedi/drivers/ni_tio.c
+++ b/drivers/staging/comedi/drivers/ni_tio.c
@@ -222,7 +222,7 @@ static uint64_t ni_tio_clock_period_ps(const struct ni_gpct 
*counter,
clock_period_ps *= 8;
break;
default:
-   BUG();
+   WARN_ON(1);
break;
}
return clock_period_ps;
@@ -304,7 +304,7 @@ static unsigned ni_m_series_clock_src_select(const struct 
ni_gpct *counter)
}
if (i <= NI_M_MAX_PFI_CHAN)
break;
-   BUG();
+   WARN_ON(1);
break;
}
clock_source |= ni_tio_clock_src_modifiers(counter);
@@ -361,7 +361,7 @@ static unsigned ni_660x_clock_src_select(const struct 
ni_gpct *counter)
}
if (i <= NI_660X_MAX_SRC_PIN)
break;
-   BUG();
+   WARN_ON(1);
break;
}
clock_source |= ni_tio_clock_src_modifiers(counter);
@@ -584,7 +584,7 @@ static unsigned ni_660x_clk_src(unsigned int clock_source)
if (i <= NI_660X_MAX_SRC_PIN)
break;
ni_660x_clock = 0;
-   BUG();
+   WARN_ON(1);
break;
}
return GI_SRC_SEL(ni_660x_clock);
@@ -643,7 +643,7 @@ static unsigned ni_m_clk_src(unsigned int clock_source)
break;
pr_err("invalid clock source 0x%lx\n",
   (unsigned long)clock_source);
-   BUG();
+   WARN_ON(1);
ni_m_series_clock = 0;
break;
}
@@ -946,7 +946,7 @@ int ni_tio_set_gate_src(struct ni_gpct *counter, unsigned 
gate_index,
case ni_gpct_variant_660x:
return ni_660x_set_gate2(counter, gate_source);
default:
-   BUG();
+   WARN_ON(1);
break;
}
break;
@@ -1015,7 +1015,7 @@ static unsigned ni_660x_gate_to_generic_gate(unsigned 
gate)
if (gate == NI_660X_PIN_GATE_SEL(i))
return NI_GPCT_GATE_PIN_GATE_SELECT(i);
}
-   BUG();
+   WARN_ON(1);
break;
}
return 0;
@@ -1051,7 +1051,7 @@ static unsigned ni_m_gate_to_generic_gate(unsigned gate)
if (gate == NI_M_PFI_GATE_SEL(i))
return NI_GPCT_PFI_GATE_SELECT(i);
}
-   BUG();
+   WARN_ON(1);
break;
}
return 0;
@@ -1083,7 +1083,7 @@ static unsigned ni_660x_gate2_to_generic_gate(unsigned 
gate)
if (gate == NI_660X_UD_PIN_GATE2_SEL(i))
return NI_GPCT_UP_DOWN_PIN_GATE_SELECT(i);
}
-   BUG();
+   WARN_ON(1);
break;
}
return 0;
-- 
1.9.1

[PATCH 1/5] Staging: comedi: fix type issue in s626.c

[Ravishankar Karkala Mallikarjunayya]

This is a patch to the s626.c file that fixes up a type issues
found by the checkpatch.pl tool.

i.e Prefer kernel type 'u8' over 'uint8_t'
Prefer kernel type 'u16' over 'uint16_t'
Prefer kernel type 'u32' over 'uint32_t'
Prefer kernel type 's16' over 'int16_t'
Prefer kernel type 's32' over 'int32_t'

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
 drivers/staging/comedi/drivers/s626.c | 312 +-
 1 file changed, 156 insertions(+), 156 deletions(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index 35f0f67..5469ca0 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -75,24 +75,24 @@ struct s626_buffer_dma {
 };
 
 struct s626_private {
-   uint8_t ai_cmd_running; /* ai_cmd is running */
+   u8 ai_cmd_running;  /* ai_cmd is running */
unsigned int ai_sample_timer;   /* time between samples in
 * units of the timer */
int ai_convert_count;   /* conversion counter */
unsigned int ai_convert_timer;  /* time between conversion in
 * units of the timer */
-   uint16_t counter_int_enabs; /* counter interrupt enable mask
+   u16 counter_int_enabs;  /* counter interrupt enable mask
 * for MISC2 register */
-   uint8_t adc_items;  /* number of items in ADC poll list */
+   u8 adc_items;   /* number of items in ADC poll list */
struct s626_buffer_dma rps_buf; /* DMA buffer used to hold ADC (RPS1)
 * program */
struct s626_buffer_dma ana_buf; /* DMA buffer used to receive ADC data
 * and hold DAC data */
-   uint32_t *dac_wbuf; /* pointer to logical adrs of DMA buffer
+   u32 *dac_wbuf;  /* pointer to logical adrs of DMA buffer
 * used to hold DAC data */
-   uint16_t dacpol;/* image of DAC polarity register */
-   uint8_t trim_setpoint[12];  /* images of TrimDAC setpoints */
-   uint32_t i2c_adrs;  /* I2C device address for onboard EEPROM
+   u16 dacpol; /* image of DAC polarity register */
+   u8 trim_setpoint[12];   /* images of TrimDAC setpoints */
+   u32 i2c_adrs;   /* I2C device address for onboard EEPROM
 * (board rev dependent) */
 };
 
@@ -179,7 +179,7 @@ static void s626_debi_transfer(struct comedi_device *dev)
 /*
  * Read a value from a gate array register.
  */
-static uint16_t s626_debi_read(struct comedi_device *dev, uint16_t addr)
+static u16 s626_debi_read(struct comedi_device *dev, u16 addr)
 {
/* Set up DEBI control register value in shadow RAM */
writel(S626_DEBI_CMD_RDWORD | addr, dev->mmio + S626_P_DEBICMD);
@@ -193,8 +193,8 @@ static uint16_t s626_debi_read(struct comedi_device *dev, 
uint16_t addr)
 /*
  * Write a value to a gate array register.
  */
-static void s626_debi_write(struct comedi_device *dev, uint16_t addr,
-   uint16_t wdata)
+static void s626_debi_write(struct comedi_device *dev, u16 addr,
+   u16 wdata)
 {
/* Set up DEBI control register value in shadow RAM */
writel(S626_DEBI_CMD_WRWORD | addr, dev->mmio + S626_P_DEBICMD);
@@ -241,7 +241,7 @@ static int s626_i2c_handshake_eoc(struct comedi_device *dev,
return -EBUSY;
 }
 
-static int s626_i2c_handshake(struct comedi_device *dev, uint32_t val)
+static int s626_i2c_handshake(struct comedi_device *dev, u32 val)
 {
unsigned int ctrl;
int ret;
@@ -267,8 +267,8 @@ static int s626_i2c_handshake(struct comedi_device *dev, 
uint32_t val)
return ctrl & S626_I2C_ERR;
 }
 
-/* Read uint8_t from EEPROM. */
-static uint8_t s626_i2c_read(struct comedi_device *dev, uint8_t addr)
+/* Read u8 from EEPROM. */
+static u8 s626_i2c_read(struct comedi_device *dev, u8 addr)
 {
struct s626_private *devpriv = dev->private;
 
@@ -288,7 +288,7 @@ static uint8_t s626_i2c_read(struct comedi_device *dev, 
uint8_t addr)
/*
 * Execute EEPROM read:
 *  Byte2 = I2C command: read from I2C EEPROM device.
-*  Byte1 receives uint8_t from EEPROM.
+*  Byte1 receives u8 from EEPROM.
 *  Byte0 = Not sent.
 */
if (s626_i2c_handshake(dev, S626_I2C_B2(S626_I2C_ATTRSTART,
@@ -304,10 +304,10 @@ static uint8_t s626_i2c_read(struct comedi_device *dev, 
uint8_t addr)
 /* ***  DAC FUNCTIONS *** */
 
 /* TrimDac LogicalChan-to-PhysicalChan mapping table. */
-static const uint8_t s626_trimchan[] = { 10, 9, 8, 3, 2, 7, 6, 1, 0, 5, 4 };
+static const u8 s626_trimchan[] = { 10, 9, 8, 3, 2, 7, 6, 1, 0, 5, 4 };
 
 /* TrimDac 

[PATCH 1/5] Staging: comedi: fix type issue in s626.c

[Ravishankar Karkala Mallikarjunayya]

This is a patch to the s626.c file that fixes up a type issues
found by the checkpatch.pl tool.

i.e Prefer kernel type 'u8' over 'uint8_t'
Prefer kernel type 'u16' over 'uint16_t'
Prefer kernel type 'u32' over 'uint32_t'
Prefer kernel type 's16' over 'int16_t'
Prefer kernel type 's32' over 'int32_t'

Signed-off-by: Ravishankar Karkala Mallikarjunayya 
---
 drivers/staging/comedi/drivers/s626.c | 312 +-
 1 file changed, 156 insertions(+), 156 deletions(-)

diff --git a/drivers/staging/comedi/drivers/s626.c 
b/drivers/staging/comedi/drivers/s626.c
index 35f0f67..5469ca0 100644
--- a/drivers/staging/comedi/drivers/s626.c
+++ b/drivers/staging/comedi/drivers/s626.c
@@ -75,24 +75,24 @@ struct s626_buffer_dma {
 };
 
 struct s626_private {
-   uint8_t ai_cmd_running; /* ai_cmd is running */
+   u8 ai_cmd_running;  /* ai_cmd is running */
unsigned int ai_sample_timer;   /* time between samples in
 * units of the timer */
int ai_convert_count;   /* conversion counter */
unsigned int ai_convert_timer;  /* time between conversion in
 * units of the timer */
-   uint16_t counter_int_enabs; /* counter interrupt enable mask
+   u16 counter_int_enabs;  /* counter interrupt enable mask
 * for MISC2 register */
-   uint8_t adc_items;  /* number of items in ADC poll list */
+   u8 adc_items;   /* number of items in ADC poll list */
struct s626_buffer_dma rps_buf; /* DMA buffer used to hold ADC (RPS1)
 * program */
struct s626_buffer_dma ana_buf; /* DMA buffer used to receive ADC data
 * and hold DAC data */
-   uint32_t *dac_wbuf; /* pointer to logical adrs of DMA buffer
+   u32 *dac_wbuf;  /* pointer to logical adrs of DMA buffer
 * used to hold DAC data */
-   uint16_t dacpol;/* image of DAC polarity register */
-   uint8_t trim_setpoint[12];  /* images of TrimDAC setpoints */
-   uint32_t i2c_adrs;  /* I2C device address for onboard EEPROM
+   u16 dacpol; /* image of DAC polarity register */
+   u8 trim_setpoint[12];   /* images of TrimDAC setpoints */
+   u32 i2c_adrs;   /* I2C device address for onboard EEPROM
 * (board rev dependent) */
 };
 
@@ -179,7 +179,7 @@ static void s626_debi_transfer(struct comedi_device *dev)
 /*
  * Read a value from a gate array register.
  */
-static uint16_t s626_debi_read(struct comedi_device *dev, uint16_t addr)
+static u16 s626_debi_read(struct comedi_device *dev, u16 addr)
 {
/* Set up DEBI control register value in shadow RAM */
writel(S626_DEBI_CMD_RDWORD | addr, dev->mmio + S626_P_DEBICMD);
@@ -193,8 +193,8 @@ static uint16_t s626_debi_read(struct comedi_device *dev, 
uint16_t addr)
 /*
  * Write a value to a gate array register.
  */
-static void s626_debi_write(struct comedi_device *dev, uint16_t addr,
-   uint16_t wdata)
+static void s626_debi_write(struct comedi_device *dev, u16 addr,
+   u16 wdata)
 {
/* Set up DEBI control register value in shadow RAM */
writel(S626_DEBI_CMD_WRWORD | addr, dev->mmio + S626_P_DEBICMD);
@@ -241,7 +241,7 @@ static int s626_i2c_handshake_eoc(struct comedi_device *dev,
return -EBUSY;
 }
 
-static int s626_i2c_handshake(struct comedi_device *dev, uint32_t val)
+static int s626_i2c_handshake(struct comedi_device *dev, u32 val)
 {
unsigned int ctrl;
int ret;
@@ -267,8 +267,8 @@ static int s626_i2c_handshake(struct comedi_device *dev, 
uint32_t val)
return ctrl & S626_I2C_ERR;
 }
 
-/* Read uint8_t from EEPROM. */
-static uint8_t s626_i2c_read(struct comedi_device *dev, uint8_t addr)
+/* Read u8 from EEPROM. */
+static u8 s626_i2c_read(struct comedi_device *dev, u8 addr)
 {
struct s626_private *devpriv = dev->private;
 
@@ -288,7 +288,7 @@ static uint8_t s626_i2c_read(struct comedi_device *dev, 
uint8_t addr)
/*
 * Execute EEPROM read:
 *  Byte2 = I2C command: read from I2C EEPROM device.
-*  Byte1 receives uint8_t from EEPROM.
+*  Byte1 receives u8 from EEPROM.
 *  Byte0 = Not sent.
 */
if (s626_i2c_handshake(dev, S626_I2C_B2(S626_I2C_ATTRSTART,
@@ -304,10 +304,10 @@ static uint8_t s626_i2c_read(struct comedi_device *dev, 
uint8_t addr)
 /* ***  DAC FUNCTIONS *** */
 
 /* TrimDac LogicalChan-to-PhysicalChan mapping table. */
-static const uint8_t s626_trimchan[] = { 10, 9, 8, 3, 2, 7, 6, 1, 0, 5, 4 };
+static const u8 s626_trimchan[] = { 10, 9, 8, 3, 2, 7, 6, 1, 0, 5, 4 };
 
 /* TrimDac LogicalChan-to-EepromAdrs 

Re: [PATCH V4 0/3] basic busy polling support for vhost_net

[Michael Rapoport]

Hi Greg,

> Greg Kurz  wrote on 03/09/2016 09:26:45 PM:
> > On Fri,  4 Mar 2016 06:24:50 -0500
> > Jason Wang  wrote:
> 
> > This series tries to add basic busy polling for vhost net. The idea is
> > simple: at the end of tx/rx processing, busy polling for new tx added
> > descriptor and rx receive socket for a while. The maximum number of
> > time (in us) could be spent on busy polling was specified ioctl.
> > 
> > Test A were done through:
> > 
> > - 50 us as busy loop timeout
> > - Netperf 2.6
> > - Two machines with back to back connected mlx4
> 
> Hi Jason,
> 
> Could this also improve performance if both VMs are
> on the same host system ?

I've experimented a little with Jason's patches and guest-to-guest netperf 
when both guests were on the same host, and I saw improvements for that 
case.
 
> > - Guest with 1 vcpus and 1 queue
> > 
> > Results:
> > - Obvious improvements (%5 - 20%) for latency (TCP_RR).
> > - Get a better or minor regression on most of the TX tests, but see
> >   some regression on 4096 size.
> > - Except for 8 sessions of 4096 size RX, have a better or same
> >   performance.
> > - CPU utilization were incrased as expected.
> > 
> > TCP_RR:
> > size/session/+thu%/+normalize%/+tpkts%/+rpkts%/+ioexits%/
> > 1/ 1/   +8%/  -32%/   +8%/   +8%/   +7%
> > 1/50/   +7%/  -19%/   +7%/   +7%/   +1%
> > 1/   100/   +5%/  -21%/   +5%/   +5%/0%
> > 1/   200/   +5%/  -21%/   +7%/   +7%/   +1%
> >64/ 1/  +11%/  -29%/  +11%/  +11%/  +10%
> >64/50/   +7%/  -19%/   +8%/   +8%/   +2%
> >64/   100/   +8%/  -18%/   +9%/   +9%/   +2%
> >64/   200/   +6%/  -19%/   +6%/   +6%/0%
> >   256/ 1/   +7%/  -33%/   +7%/   +7%/   +6%
> >   256/50/   +7%/  -18%/   +7%/   +7%/0%
> >   256/   100/   +9%/  -18%/   +8%/   +8%/   +2%
> >   256/   200/   +9%/  -18%/  +10%/  +10%/   +3%
> >  1024/ 1/  +20%/  -28%/  +20%/  +20%/  +19%
> >  1024/50/   +8%/  -18%/   +9%/   +9%/   +2%
> >  1024/   100/   +6%/  -19%/   +5%/   +5%/0%
> >  1024/   200/   +8%/  -18%/   +9%/   +9%/   +2%
> > Guest TX:
> > size/session/+thu%/+normalize%/+tpkts%/+rpkts%/+ioexits%/
> >64/ 1/   -5%/  -28%/  +11%/  +12%/  +10%
> >64/ 4/   -2%/  -26%/  +13%/  +13%/  +13%
> >64/ 8/   -6%/  -29%/   +9%/  +10%/  +10%
> >   512/ 1/  +15%/   -7%/  +13%/  +11%/   +3%
> >   512/ 4/  +17%/   -6%/  +18%/  +13%/  +11%
> >   512/ 8/  +14%/   -7%/  +13%/   +7%/   +7%
> >  1024/ 1/  +27%/   -2%/  +26%/  +29%/  +12%
> >  1024/ 4/   +8%/   -9%/   +6%/   +1%/   +6%
> >  1024/ 8/  +41%/  +12%/  +34%/  +20%/   -3%
> >  4096/ 1/  -22%/  -21%/  -36%/  +81%/+1360%
> >  4096/ 4/  -57%/  -58%/ +286%/  +15%/+2074%
> >  4096/ 8/  +67%/  +70%/  -45%/   -8%/  +63%
> > 16384/ 1/   -2%/   -5%/   +5%/   -3%/  +80%
> > 16384/ 4/0%/0%/0%/   +4%/ +138%
> > 16384/ 8/0%/0%/0%/   +1%/  +41%
> > 65535/ 1/   -3%/   -6%/   +2%/  +11%/ +113%
> > 65535/ 4/   -2%/   -1%/   -2%/   -3%/ +484%
> > 65535/ 8/0%/   +1%/0%/   +2%/  +40%
> > Guest RX:
> > size/session/+thu%/+normalize%/+tpkts%/+rpkts%/+ioexits%/
> >64/ 1/  +31%/   -3%/   +8%/   +8%/   +8%
> >64/ 4/  +11%/  -17%/  +13%/  +14%/  +15%
> >64/ 8/   +4%/  -23%/  +11%/  +11%/  +12%
> >   512/ 1/  +24%/0%/  +18%/  +14%/   -8%
> >   512/ 4/   +4%/  -15%/   +6%/   +5%/   +6%
> >   512/ 8/  +26%/0%/  +21%/  +10%/   +3%
> >  1024/ 1/  +88%/  +47%/  +69%/  +44%/  -30%
> >  1024/ 4/  +18%/   -5%/  +19%/  +16%/   +2%
> >  1024/ 8/  +15%/   -4%/  +13%/   +8%/   +1%
> >  4096/ 1/   -3%/   -5%/   +2%/   -2%/  +41%
> >  4096/ 4/   +2%/   +3%/  -20%/  -14%/  -24%
> >  4096/ 8/  -43%/  -45%/  +69%/  -24%/  +94%
> > 16384/ 1/   -3%/  -11%/  +23%/   +7%/  +42%
> > 16384/ 4/   -3%/   -3%/   -4%/   +5%/ +115%
> > 16384/ 8/   -1%/0%/   -1%/   -3%/  +32%
> > 65535/ 1/   +1%/0%/   +2%/0%/  +66%
> > 65535/ 4/   -1%/   -1%/0%/   +4%/ +492%
> > 65535/ 8/0%/   -1%/   -1%/   +4%/  +38%
> > 
> > Changes from V3:
> > - drop single_task_running()
> > - use cpu_relax_lowlatency() instead of cpu_relax()
> > 
> > Changes from V2:
> > - rename vhost_vq_more_avail() to vhost_vq_avail_empty(). And return
> > false we __get_user() fails.
> > - do not bother premmptions/timers for good path.
> > - use vhost_vring_state as ioctl parameter instead of reinveting a new
> > one.
> > - add the unit of timeout (us) to the comment of new added ioctls
> > 
> > Changes from V1:
> > - remove the buggy vq_error() in vhost_vq_more_avail().
> > - leave vhost_enable_notify() untouched.
> > 
> > Changes from RFC V3:
> > - small tweak on the code to avoid multiple duplicate conditions in
> > critical path when busy loop is not enabled.
> > - add the test result of multiple VMs
> > 
> > Changes from RFC V2:
> > - poll also at the end of rx 

Re: [PATCH V4 0/3] basic busy polling support for vhost_net

[Michael Rapoport]

Hi Greg,

> Greg Kurz  wrote on 03/09/2016 09:26:45 PM:
> > On Fri,  4 Mar 2016 06:24:50 -0500
> > Jason Wang  wrote:
> 
> > This series tries to add basic busy polling for vhost net. The idea is
> > simple: at the end of tx/rx processing, busy polling for new tx added
> > descriptor and rx receive socket for a while. The maximum number of
> > time (in us) could be spent on busy polling was specified ioctl.
> > 
> > Test A were done through:
> > 
> > - 50 us as busy loop timeout
> > - Netperf 2.6
> > - Two machines with back to back connected mlx4
> 
> Hi Jason,
> 
> Could this also improve performance if both VMs are
> on the same host system ?

I've experimented a little with Jason's patches and guest-to-guest netperf 
when both guests were on the same host, and I saw improvements for that 
case.
 
> > - Guest with 1 vcpus and 1 queue
> > 
> > Results:
> > - Obvious improvements (%5 - 20%) for latency (TCP_RR).
> > - Get a better or minor regression on most of the TX tests, but see
> >   some regression on 4096 size.
> > - Except for 8 sessions of 4096 size RX, have a better or same
> >   performance.
> > - CPU utilization were incrased as expected.
> > 
> > TCP_RR:
> > size/session/+thu%/+normalize%/+tpkts%/+rpkts%/+ioexits%/
> > 1/ 1/   +8%/  -32%/   +8%/   +8%/   +7%
> > 1/50/   +7%/  -19%/   +7%/   +7%/   +1%
> > 1/   100/   +5%/  -21%/   +5%/   +5%/0%
> > 1/   200/   +5%/  -21%/   +7%/   +7%/   +1%
> >64/ 1/  +11%/  -29%/  +11%/  +11%/  +10%
> >64/50/   +7%/  -19%/   +8%/   +8%/   +2%
> >64/   100/   +8%/  -18%/   +9%/   +9%/   +2%
> >64/   200/   +6%/  -19%/   +6%/   +6%/0%
> >   256/ 1/   +7%/  -33%/   +7%/   +7%/   +6%
> >   256/50/   +7%/  -18%/   +7%/   +7%/0%
> >   256/   100/   +9%/  -18%/   +8%/   +8%/   +2%
> >   256/   200/   +9%/  -18%/  +10%/  +10%/   +3%
> >  1024/ 1/  +20%/  -28%/  +20%/  +20%/  +19%
> >  1024/50/   +8%/  -18%/   +9%/   +9%/   +2%
> >  1024/   100/   +6%/  -19%/   +5%/   +5%/0%
> >  1024/   200/   +8%/  -18%/   +9%/   +9%/   +2%
> > Guest TX:
> > size/session/+thu%/+normalize%/+tpkts%/+rpkts%/+ioexits%/
> >64/ 1/   -5%/  -28%/  +11%/  +12%/  +10%
> >64/ 4/   -2%/  -26%/  +13%/  +13%/  +13%
> >64/ 8/   -6%/  -29%/   +9%/  +10%/  +10%
> >   512/ 1/  +15%/   -7%/  +13%/  +11%/   +3%
> >   512/ 4/  +17%/   -6%/  +18%/  +13%/  +11%
> >   512/ 8/  +14%/   -7%/  +13%/   +7%/   +7%
> >  1024/ 1/  +27%/   -2%/  +26%/  +29%/  +12%
> >  1024/ 4/   +8%/   -9%/   +6%/   +1%/   +6%
> >  1024/ 8/  +41%/  +12%/  +34%/  +20%/   -3%
> >  4096/ 1/  -22%/  -21%/  -36%/  +81%/+1360%
> >  4096/ 4/  -57%/  -58%/ +286%/  +15%/+2074%
> >  4096/ 8/  +67%/  +70%/  -45%/   -8%/  +63%
> > 16384/ 1/   -2%/   -5%/   +5%/   -3%/  +80%
> > 16384/ 4/0%/0%/0%/   +4%/ +138%
> > 16384/ 8/0%/0%/0%/   +1%/  +41%
> > 65535/ 1/   -3%/   -6%/   +2%/  +11%/ +113%
> > 65535/ 4/   -2%/   -1%/   -2%/   -3%/ +484%
> > 65535/ 8/0%/   +1%/0%/   +2%/  +40%
> > Guest RX:
> > size/session/+thu%/+normalize%/+tpkts%/+rpkts%/+ioexits%/
> >64/ 1/  +31%/   -3%/   +8%/   +8%/   +8%
> >64/ 4/  +11%/  -17%/  +13%/  +14%/  +15%
> >64/ 8/   +4%/  -23%/  +11%/  +11%/  +12%
> >   512/ 1/  +24%/0%/  +18%/  +14%/   -8%
> >   512/ 4/   +4%/  -15%/   +6%/   +5%/   +6%
> >   512/ 8/  +26%/0%/  +21%/  +10%/   +3%
> >  1024/ 1/  +88%/  +47%/  +69%/  +44%/  -30%
> >  1024/ 4/  +18%/   -5%/  +19%/  +16%/   +2%
> >  1024/ 8/  +15%/   -4%/  +13%/   +8%/   +1%
> >  4096/ 1/   -3%/   -5%/   +2%/   -2%/  +41%
> >  4096/ 4/   +2%/   +3%/  -20%/  -14%/  -24%
> >  4096/ 8/  -43%/  -45%/  +69%/  -24%/  +94%
> > 16384/ 1/   -3%/  -11%/  +23%/   +7%/  +42%
> > 16384/ 4/   -3%/   -3%/   -4%/   +5%/ +115%
> > 16384/ 8/   -1%/0%/   -1%/   -3%/  +32%
> > 65535/ 1/   +1%/0%/   +2%/0%/  +66%
> > 65535/ 4/   -1%/   -1%/0%/   +4%/ +492%
> > 65535/ 8/0%/   -1%/   -1%/   +4%/  +38%
> > 
> > Changes from V3:
> > - drop single_task_running()
> > - use cpu_relax_lowlatency() instead of cpu_relax()
> > 
> > Changes from V2:
> > - rename vhost_vq_more_avail() to vhost_vq_avail_empty(). And return
> > false we __get_user() fails.
> > - do not bother premmptions/timers for good path.
> > - use vhost_vring_state as ioctl parameter instead of reinveting a new
> > one.
> > - add the unit of timeout (us) to the comment of new added ioctls
> > 
> > Changes from V1:
> > - remove the buggy vq_error() in vhost_vq_more_avail().
> > - leave vhost_enable_notify() untouched.
> > 
> > Changes from RFC V3:
> > - small tweak on the code to avoid multiple duplicate conditions in
> > critical path when busy loop is not enabled.
> > - add the test result of multiple VMs
> > 
> > Changes from RFC V2:
> > - poll also at the end of rx handling
> > - factor out the polling logic and 

Re: [kernel-hardening] Re: [PATCH v3 3/3] SROP mitigation: Add sysctl to disable SROP protection.

[Andy Lutomirski]

On Wed, Mar 9, 2016 at 10:36 PM, Kees Cook  wrote:
> On Tue, Mar 8, 2016 at 1:00 PM, One Thousand Gnomes
>  wrote:
>> On Tue,  8 Mar 2016 13:47:55 -0700
>> Scott Bauer  wrote:
>>
>>> This patch adds a sysctl argument to disable SROP protection.
>>
>> Shouldn't it be a sysctl to enable it irrevocably, otherwise if I have DAC
>> capability I can turn off SROP and attack something to get to higher
>> capability levels ?
>>
>> (The way almost all distros are set up its kind of academic but for a
>> properly secured system it might matter).
>
> Perhaps use proc_dointvec_minmax_sysadmin instead to tie changes
> strictly to CAP_SYS_ADMIN?

I don't see why this needs to be irrevocable.  If you have
CAP_SYS_ADMIN or write access to /proc or whatever, you can do much
worse things than turning off a user-level mitigation.  For example,
you can ptrace things.  Also, you're already root, so what's the
point?

--Andy

Re: [kernel-hardening] Re: [PATCH v3 3/3] SROP mitigation: Add sysctl to disable SROP protection.

[Andy Lutomirski]

On Wed, Mar 9, 2016 at 10:36 PM, Kees Cook  wrote:
> On Tue, Mar 8, 2016 at 1:00 PM, One Thousand Gnomes
>  wrote:
>> On Tue,  8 Mar 2016 13:47:55 -0700
>> Scott Bauer  wrote:
>>
>>> This patch adds a sysctl argument to disable SROP protection.
>>
>> Shouldn't it be a sysctl to enable it irrevocably, otherwise if I have DAC
>> capability I can turn off SROP and attack something to get to higher
>> capability levels ?
>>
>> (The way almost all distros are set up its kind of academic but for a
>> properly secured system it might matter).
>
> Perhaps use proc_dointvec_minmax_sysadmin instead to tie changes
> strictly to CAP_SYS_ADMIN?

I don't see why this needs to be irrevocable.  If you have
CAP_SYS_ADMIN or write access to /proc or whatever, you can do much
worse things than turning off a user-level mitigation.  For example,
you can ptrace things.  Also, you're already root, so what's the
point?

--Andy

Re: [PATCH 03/11] x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()

[Andy Lutomirski]

On Fri, Feb 12, 2016 at 11:04 AM, Andy Lutomirski  wrote:
> On Mon, Sep 21, 2015 at 11:23 PM, Ingo Molnar  wrote:
>> So when memory hotplug removes a piece of physical memory from pagetable
>> mappings, it also frees the underlying PGD entry.
>>
>> This complicates PGD management, so don't do this. We can keep the
>> PGD mapped and the PUD table all clear - it's only a single 4K page
>> per 512 GB of memory hotplugged.
>
> Ressurecting an ancient thread: I want this particular change to make
> it (much) easier to make vmapped stacks work correctly.  Could it be
> applied by itself?
>

It's incomplete.  pageattr.c has another instance of the same thing.
I'll see if I can make it work, but I may end up doing something a
little different.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH 03/11] x86/mm/hotplug: Don't remove PGD entries in remove_pagetable()

[Andy Lutomirski]

On Fri, Feb 12, 2016 at 11:04 AM, Andy Lutomirski  wrote:
> On Mon, Sep 21, 2015 at 11:23 PM, Ingo Molnar  wrote:
>> So when memory hotplug removes a piece of physical memory from pagetable
>> mappings, it also frees the underlying PGD entry.
>>
>> This complicates PGD management, so don't do this. We can keep the
>> PGD mapped and the PUD table all clear - it's only a single 4K page
>> per 512 GB of memory hotplugged.
>
> Ressurecting an ancient thread: I want this particular change to make
> it (much) easier to make vmapped stacks work correctly.  Could it be
> applied by itself?
>

It's incomplete.  pageattr.c has another instance of the same thing.
I'll see if I can make it work, but I may end up doing something a
little different.

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [kernel-hardening] Re: [PATCH v3 3/3] SROP mitigation: Add sysctl to disable SROP protection.

[Kees Cook]

On Tue, Mar 8, 2016 at 1:00 PM, One Thousand Gnomes
 wrote:
> On Tue,  8 Mar 2016 13:47:55 -0700
> Scott Bauer  wrote:
>
>> This patch adds a sysctl argument to disable SROP protection.
>
> Shouldn't it be a sysctl to enable it irrevocably, otherwise if I have DAC
> capability I can turn off SROP and attack something to get to higher
> capability levels ?
>
> (The way almost all distros are set up its kind of academic but for a
> properly secured system it might matter).

Perhaps use proc_dointvec_minmax_sysadmin instead to tie changes
strictly to CAP_SYS_ADMIN?

-Kees

>
> Alan



-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] Re: [PATCH v3 3/3] SROP mitigation: Add sysctl to disable SROP protection.

[Kees Cook]

On Tue, Mar 8, 2016 at 1:00 PM, One Thousand Gnomes
 wrote:
> On Tue,  8 Mar 2016 13:47:55 -0700
> Scott Bauer  wrote:
>
>> This patch adds a sysctl argument to disable SROP protection.
>
> Shouldn't it be a sysctl to enable it irrevocably, otherwise if I have DAC
> capability I can turn off SROP and attack something to get to higher
> capability levels ?
>
> (The way almost all distros are set up its kind of academic but for a
> properly secured system it might matter).

Perhaps use proc_dointvec_minmax_sysadmin instead to tie changes
strictly to CAP_SYS_ADMIN?

-Kees

>
> Alan



-- 
Kees Cook
Chrome OS & Brillo Security

linux-next: Tree for Mar 10

[Stephen Rothwell]

Hi all,

Changes since 20160309:

Trees removed: apm, tiny, mips-fixes, lblnet, rpmsg,
llvmlinux, bcm2835, kgdb, mmc, random, squashfs
all were unsed for at leat a year

The xfs tree gained conflicts against the ext4 tree.

The aio tree still had a build failure so I used the version from
next-20160111.

The akpm tree gained a conflict against the tip tree.

Non-merge commits (relative to Linus' tree): 10346
 8096 files changed, 391322 insertions(+), 192001 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 230 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (7f02bf6b5f5d Merge tag 'sound-4.5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound)
Merging fixes/master (36f90b0a2ddd Linux 4.5-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (fc77dbd34c5c Linux 4.5-rc6)
Merging arm-current/fixes (f474c8c857d9 ARM: 8544/1: set_memory_xx fixes)
Merging m68k-current/for-linus (daf670bc9d36 m68k/defconfig: Update defconfigs 
for v4.5-rc1)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (37c5e942bb2e powerpc/fsl-book3e: Avoid lbarx on 
e5500)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (f983cd32cd5d Merge branch 'parisc-4.5-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux)
Merging net/master (133800d1f028 sctp: fix copying more bytes than expected in 
sctp_add_bind_addr)
Merging ipsec/master (52717aa43094 vti: Fix recource leeks on pmtu discovery)
Merging ipvs/master (7617a24f83b5 ipvs: correct initial offset of Call-ID 
header search in SIP persistence engine)
Merging wireless-drivers/master (10da848f67a7 ssb: host_soc depends on sprom)
Merging mac80211/master (2af8c4dc2e9c mac80211_hwsim: treat as part of mac80211 
for MAINTAINERS)
Merging sound-current/for-linus (ad09ef2cce91 Merge tag 'asoc-fix-v4.5-rc6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (54c6e2dd00c3 PCI: Allow a NULL "parent" pointer 
in pci_bus_assign_domain_nr())
Merging driver-core.current/driver-core-linus (18558cae0272 Linux 4.5-rc4)
Merging tty.current/tty-linus (18558cae0272 Linux 4.5-rc4)
Merging usb.current/usb-linus (861c3849222b Merge tag 'usb-serial-4.5-rc7' of 
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus)
Merging usb-gadget-fixes/fixes (3b2435192fe9 MAINTAINERS: drop OMAP USB and 
MUSB maintainership)
Merging usb-serial-fixes/usb-linus (f6cede5b49e8 Linux 4.5-rc7)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (fc77dbd34c5c Linux 4.5-rc6)
Merging char-misc.current/char-misc-linus (fc77dbd34c5c Linux 4.5-rc6)
Merging input-current/for-linus (ff84dabe3c6e Input: colibri-vf50-ts - add 
missing #include )
Merging crypto-current/master (8a3978ad55fb crypto: marvell/cesa - fix test in 
mv_cesa_dev_dma_init())
Merging ide/master (e04a2bd6d8c9 drivers/ide: make ide-scan-pci.c driver 
explicitly non-modular)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fix

linux-next: Tree for Mar 10

[Stephen Rothwell]

Hi all,

Changes since 20160309:

Trees removed: apm, tiny, mips-fixes, lblnet, rpmsg,
llvmlinux, bcm2835, kgdb, mmc, random, squashfs
all were unsed for at leat a year

The xfs tree gained conflicts against the ext4 tree.

The aio tree still had a build failure so I used the version from
next-20160111.

The akpm tree gained a conflict against the tip tree.

Non-merge commits (relative to Linus' tree): 10346
 8096 files changed, 391322 insertions(+), 192001 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 230 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (7f02bf6b5f5d Merge tag 'sound-4.5' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound)
Merging fixes/master (36f90b0a2ddd Linux 4.5-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (fc77dbd34c5c Linux 4.5-rc6)
Merging arm-current/fixes (f474c8c857d9 ARM: 8544/1: set_memory_xx fixes)
Merging m68k-current/for-linus (daf670bc9d36 m68k/defconfig: Update defconfigs 
for v4.5-rc1)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (37c5e942bb2e powerpc/fsl-book3e: Avoid lbarx on 
e5500)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (f983cd32cd5d Merge branch 'parisc-4.5-2' of 
git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux)
Merging net/master (133800d1f028 sctp: fix copying more bytes than expected in 
sctp_add_bind_addr)
Merging ipsec/master (52717aa43094 vti: Fix recource leeks on pmtu discovery)
Merging ipvs/master (7617a24f83b5 ipvs: correct initial offset of Call-ID 
header search in SIP persistence engine)
Merging wireless-drivers/master (10da848f67a7 ssb: host_soc depends on sprom)
Merging mac80211/master (2af8c4dc2e9c mac80211_hwsim: treat as part of mac80211 
for MAINTAINERS)
Merging sound-current/for-linus (ad09ef2cce91 Merge tag 'asoc-fix-v4.5-rc6' of 
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound into for-linus)
Merging pci-current/for-linus (54c6e2dd00c3 PCI: Allow a NULL "parent" pointer 
in pci_bus_assign_domain_nr())
Merging driver-core.current/driver-core-linus (18558cae0272 Linux 4.5-rc4)
Merging tty.current/tty-linus (18558cae0272 Linux 4.5-rc4)
Merging usb.current/usb-linus (861c3849222b Merge tag 'usb-serial-4.5-rc7' of 
git://git.kernel.org/pub/scm/linux/kernel/git/johan/usb-serial into usb-linus)
Merging usb-gadget-fixes/fixes (3b2435192fe9 MAINTAINERS: drop OMAP USB and 
MUSB maintainership)
Merging usb-serial-fixes/usb-linus (f6cede5b49e8 Linux 4.5-rc7)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (fc77dbd34c5c Linux 4.5-rc6)
Merging char-misc.current/char-misc-linus (fc77dbd34c5c Linux 4.5-rc6)
Merging input-current/for-linus (ff84dabe3c6e Input: colibri-vf50-ts - add 
missing #include )
Merging crypto-current/master (8a3978ad55fb crypto: marvell/cesa - fix test in 
mv_cesa_dev_dma_init())
Merging ide/master (e04a2bd6d8c9 drivers/ide: make ide-scan-pci.c driver 
explicitly non-modular)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fix

КЛИЕНТСКИЕ БАЗЫ! Тел\Viber\Whatsapp: +79133913837 Email: vavdee...@gmail.com Skype: prodawez389

[linux-kernel@vger.kernel.org]

КЛИЕНТСКИЕ БАЗЫ!

Соберем для Вас по интернет базу данных потенциальных клиентов 
для Вашего Бизнеса!
Много! Быстро! Недорого! 
Узнайте об этом подробнее по 
Тел: +79133913837
Viber: +79133913837
Whatsapp: +79133913837
Skype: prodawez389
Email: vavdee...@gmail.com

КЛИЕНТСКИЕ БАЗЫ! Тел\Viber\Whatsapp: +79133913837 Email: vavdee...@gmail.com Skype: prodawez389

[linux-kernel@vger.kernel.org]

КЛИЕНТСКИЕ БАЗЫ!

Соберем для Вас по интернет базу данных потенциальных клиентов 
для Вашего Бизнеса!
Много! Быстро! Недорого! 
Узнайте об этом подробнее по 
Тел: +79133913837
Viber: +79133913837
Whatsapp: +79133913837
Skype: prodawez389
Email: vavdee...@gmail.com

Re: [patch -target tree] usb: gadget: f_tcm: use after free

[Nicholas A. Bellinger]

On Wed, 2016-03-09 at 13:38 +0200, Felipe Balbi wrote:
> Hi,
> 
> "Nicholas A. Bellinger"  writes:
> > [ text/plain ]
> > Hi Felipe + usb-gadget folks,
> >
> > On Wed, 2016-03-02 at 13:55 +0200, Felipe Balbi wrote:
> >> Dan Carpenter  writes:
> >> > We need to move the kfree() down a line so we don't dereference a freed
> >> > variable.
> >> >
> >> > Fixes: 1b418a8fcbc0 ('target: Convert demo-mode only drivers to 
> >> > target_alloc_session')
> >> > Signed-off-by: Dan Carpenter 
> >> 
> >> It's okay to take this via target:
> >> 
> >> Signed-off-by: Felipe Balbi 
> >> 
> >
> > Note this specific patch is only a mechanical change, and we still need
> > reviews for the more interesting conversions:
> >
> > usb-gadget/tcm: Conversion to percpu_ida tag pre-allocation
> > http://www.spinics.net/lists/target-devel/msg11777.html
> >
> > usb-gadget/tcm: Convert to TARGET_SCF_ACK_KREF I/O krefs
> > http://www.spinics.net/lists/target-devel/msg11782.html
> >
> I don't have either patch in my inbox apparently. Care to resend ?
> 
> sorry
> 

A -v4 is going on this week, and will make sure they hit your inbox.

Re: [patch -target tree] usb: gadget: f_tcm: use after free

[Nicholas A. Bellinger]

On Wed, 2016-03-09 at 13:38 +0200, Felipe Balbi wrote:
> Hi,
> 
> "Nicholas A. Bellinger"  writes:
> > [ text/plain ]
> > Hi Felipe + usb-gadget folks,
> >
> > On Wed, 2016-03-02 at 13:55 +0200, Felipe Balbi wrote:
> >> Dan Carpenter  writes:
> >> > We need to move the kfree() down a line so we don't dereference a freed
> >> > variable.
> >> >
> >> > Fixes: 1b418a8fcbc0 ('target: Convert demo-mode only drivers to 
> >> > target_alloc_session')
> >> > Signed-off-by: Dan Carpenter 
> >> 
> >> It's okay to take this via target:
> >> 
> >> Signed-off-by: Felipe Balbi 
> >> 
> >
> > Note this specific patch is only a mechanical change, and we still need
> > reviews for the more interesting conversions:
> >
> > usb-gadget/tcm: Conversion to percpu_ida tag pre-allocation
> > http://www.spinics.net/lists/target-devel/msg11777.html
> >
> > usb-gadget/tcm: Convert to TARGET_SCF_ACK_KREF I/O krefs
> > http://www.spinics.net/lists/target-devel/msg11782.html
> >
> I don't have either patch in my inbox apparently. Care to resend ?
> 
> sorry
> 

A -v4 is going on this week, and will make sure they hit your inbox.

Re: [PATCH 1/2] Staging: atm: fix 'endianess' spelling to 'endianness' in fore200e.c This is a patch to the fore200e that fixes the spelling of 'endianess' to the correct one, that is, 'endianness' fo

[Amitoj Kaur Chawla]

On Thu, Mar 10, 2016 at 11:00 AM, rneha725  wrote:
> Signed-off-by: Neha Rani 
> ---
Hi Neha,

You should ideally submit patches for drivers/staging/ as a newbie and
not other drivers.

Other than that,
Your subject is too long and you haven't written a commit message,

A better way to write the subject would be `atm: Fix spelling of endianness `

The commit message can contain the other details like this:
This patch fixes the spelling of 'endianness'. Problem found by
checkpatch.pl tool


Also your From should contain your full legal name like your Signed
Off instead of rneha725.
Same comments for patch 2/2.

>  drivers/atm/fore200e.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c
> index 75dde90..fac5e4fd 100644
> --- a/drivers/atm/fore200e.c
> +++ b/drivers/atm/fore200e.c
> @@ -409,7 +409,7 @@ fore200e_shutdown(struct fore200e* fore200e)
>  static u32 fore200e_pca_read(volatile u32 __iomem *addr)
>  {
>  /* on big-endian hosts, the board is configured to convert
> -   the endianess of slave RAM accesses  */
> +   the endianness of slave RAM accesses  */
>  return le32_to_cpu(readl(addr));
>  }
>
> @@ -417,7 +417,7 @@ static u32 fore200e_pca_read(volatile u32 __iomem *addr)
>  static void fore200e_pca_write(u32 val, volatile u32 __iomem *addr)
>  {
>  /* on big-endian hosts, the board is configured to convert
> -   the endianess of slave RAM accesses  */
> +   the endianness of slave RAM accesses  */
>  writel(cpu_to_le32(val), addr);
>  }
>
> @@ -577,7 +577,7 @@ static int fore200e_pca_configure(struct fore200e 
> *fore200e)
>
>  master_ctrl = master_ctrl
>  #if defined(__BIG_ENDIAN)
> -   /* request the PCA board to convert the endianess of slave RAM 
> accesses */
> +   /* request the PCA board to convert the endianness of slave RAM 
> accesses */
> | PCA200E_CTRL_CONVERT_ENDIAN
>  #endif
>  #if 0
> --
> 2.5.0
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Re: [PATCH 1/2] Staging: atm: fix 'endianess' spelling to 'endianness' in fore200e.c This is a patch to the fore200e that fixes the spelling of 'endianess' to the correct one, that is, 'endianness' fo

[Amitoj Kaur Chawla]

On Thu, Mar 10, 2016 at 11:00 AM, rneha725  wrote:
> Signed-off-by: Neha Rani 
> ---
Hi Neha,

You should ideally submit patches for drivers/staging/ as a newbie and
not other drivers.

Other than that,
Your subject is too long and you haven't written a commit message,

A better way to write the subject would be `atm: Fix spelling of endianness `

The commit message can contain the other details like this:
This patch fixes the spelling of 'endianness'. Problem found by
checkpatch.pl tool


Also your From should contain your full legal name like your Signed
Off instead of rneha725.
Same comments for patch 2/2.

>  drivers/atm/fore200e.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c
> index 75dde90..fac5e4fd 100644
> --- a/drivers/atm/fore200e.c
> +++ b/drivers/atm/fore200e.c
> @@ -409,7 +409,7 @@ fore200e_shutdown(struct fore200e* fore200e)
>  static u32 fore200e_pca_read(volatile u32 __iomem *addr)
>  {
>  /* on big-endian hosts, the board is configured to convert
> -   the endianess of slave RAM accesses  */
> +   the endianness of slave RAM accesses  */
>  return le32_to_cpu(readl(addr));
>  }
>
> @@ -417,7 +417,7 @@ static u32 fore200e_pca_read(volatile u32 __iomem *addr)
>  static void fore200e_pca_write(u32 val, volatile u32 __iomem *addr)
>  {
>  /* on big-endian hosts, the board is configured to convert
> -   the endianess of slave RAM accesses  */
> +   the endianness of slave RAM accesses  */
>  writel(cpu_to_le32(val), addr);
>  }
>
> @@ -577,7 +577,7 @@ static int fore200e_pca_configure(struct fore200e 
> *fore200e)
>
>  master_ctrl = master_ctrl
>  #if defined(__BIG_ENDIAN)
> -   /* request the PCA board to convert the endianess of slave RAM 
> accesses */
> +   /* request the PCA board to convert the endianness of slave RAM 
> accesses */
> | PCA200E_CTRL_CONVERT_ENDIAN
>  #endif
>  #if 0
> --
> 2.5.0
>
> ___
> devel mailing list
> de...@linuxdriverproject.org
> http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

[PATCH] writeback: Fix performance regression in wb_over_bg_thresh()

[Howard Cochran]

Commit 947e9762a8dd ("writeback: update wb_over_bg_thresh() to use
wb_domain aware operations") unintentionally changed this function's
meaning from "are there more dirty pages than the background writeback
threshold" to "are there more dirty pages than the writeback threshold".
The background writeback threshold is typically half of the writeback
threshold, so this had the effect of raising the number of dirty pages
required to cause a writeback worker to perform background writeout.

This can cause a very severe performance regression when a BDI uses
BDI_CAP_STRICTLIMIT because balance_dirty_pages() and the writeback worker
can now disagree on whether writeback should be initiated.

For example, in a system having 1GB of RAM, a single spinning disk, and
a "pass-through" FUSE filesystem mounted over the disk, application code
mmapped a 128MB file on the disk and was randomly dirtying pages in that
mapping.

Because FUSE uses strictlimit and has a default max_ratio of only 1%,
in balance_dirty_pages, thresh is ~200, bg_thresh is ~100, and the
dirty_freerun_ceiling is the average of those, ~150. So, it pauses the
dirtying processes when we have 151 dirty pages and wakes up a
background writeback worker. But the worker tests the wrong threshold
(200 instead of 100), so it does not initiate writeback and just
returns.

Thus, balance_dirty_pages keeps looping, sleeping and then waking up the
worker who will do nothing. It remains stuck in this state until the few
dirty pages that we have finally expire and we write them back for that
reason. Then the whole process repeats, resulting in near-zero
throughput through the FUSE BDI.

The fix is to call the parameterized variant of wb_calc_thresh, so that
the worker will do writeback if the bg_thresh is exceeded which was the
bahavior before the referenced commit.

Fixes: 947e9762a8dd ("writeback: update wb_over_bg_thresh() to use
 wb_domain aware operations")
Signed-off-by: Howard Cochran 
Cc: Tejun Heo 
Cc: Jens Axboe 
---
 mm/page-writeback.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 6fe7d15..62bbf35 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -1909,7 +1909,8 @@ bool wb_over_bg_thresh(struct bdi_writeback *wb)
if (gdtc->dirty > gdtc->bg_thresh)
return true;
 
-   if (wb_stat(wb, WB_RECLAIMABLE) > __wb_calc_thresh(gdtc))
+   if (wb_stat(wb, WB_RECLAIMABLE) >
+   wb_calc_thresh(gdtc->wb, gdtc->bg_thresh))
return true;
 
if (mdtc) {
@@ -1923,7 +1924,8 @@ bool wb_over_bg_thresh(struct bdi_writeback *wb)
if (mdtc->dirty > mdtc->bg_thresh)
return true;
 
-   if (wb_stat(wb, WB_RECLAIMABLE) > __wb_calc_thresh(mdtc))
+   if (wb_stat(wb, WB_RECLAIMABLE) >
+   wb_calc_thresh(mdtc->wb, mdtc->bg_thresh))
return true;
}
 
-- 
1.9.1

[PATCH] writeback: Fix performance regression in wb_over_bg_thresh()

[Howard Cochran]

Commit 947e9762a8dd ("writeback: update wb_over_bg_thresh() to use
wb_domain aware operations") unintentionally changed this function's
meaning from "are there more dirty pages than the background writeback
threshold" to "are there more dirty pages than the writeback threshold".
The background writeback threshold is typically half of the writeback
threshold, so this had the effect of raising the number of dirty pages
required to cause a writeback worker to perform background writeout.

This can cause a very severe performance regression when a BDI uses
BDI_CAP_STRICTLIMIT because balance_dirty_pages() and the writeback worker
can now disagree on whether writeback should be initiated.

For example, in a system having 1GB of RAM, a single spinning disk, and
a "pass-through" FUSE filesystem mounted over the disk, application code
mmapped a 128MB file on the disk and was randomly dirtying pages in that
mapping.

Because FUSE uses strictlimit and has a default max_ratio of only 1%,
in balance_dirty_pages, thresh is ~200, bg_thresh is ~100, and the
dirty_freerun_ceiling is the average of those, ~150. So, it pauses the
dirtying processes when we have 151 dirty pages and wakes up a
background writeback worker. But the worker tests the wrong threshold
(200 instead of 100), so it does not initiate writeback and just
returns.

Thus, balance_dirty_pages keeps looping, sleeping and then waking up the
worker who will do nothing. It remains stuck in this state until the few
dirty pages that we have finally expire and we write them back for that
reason. Then the whole process repeats, resulting in near-zero
throughput through the FUSE BDI.

The fix is to call the parameterized variant of wb_calc_thresh, so that
the worker will do writeback if the bg_thresh is exceeded which was the
bahavior before the referenced commit.

Fixes: 947e9762a8dd ("writeback: update wb_over_bg_thresh() to use
 wb_domain aware operations")
Signed-off-by: Howard Cochran 
Cc: Tejun Heo 
Cc: Jens Axboe 
---
 mm/page-writeback.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 6fe7d15..62bbf35 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -1909,7 +1909,8 @@ bool wb_over_bg_thresh(struct bdi_writeback *wb)
if (gdtc->dirty > gdtc->bg_thresh)
return true;
 
-   if (wb_stat(wb, WB_RECLAIMABLE) > __wb_calc_thresh(gdtc))
+   if (wb_stat(wb, WB_RECLAIMABLE) >
+   wb_calc_thresh(gdtc->wb, gdtc->bg_thresh))
return true;
 
if (mdtc) {
@@ -1923,7 +1924,8 @@ bool wb_over_bg_thresh(struct bdi_writeback *wb)
if (mdtc->dirty > mdtc->bg_thresh)
return true;
 
-   if (wb_stat(wb, WB_RECLAIMABLE) > __wb_calc_thresh(mdtc))
+   if (wb_stat(wb, WB_RECLAIMABLE) >
+   wb_calc_thresh(mdtc->wb, mdtc->bg_thresh))
return true;
}
 
-- 
1.9.1

Re: [PATCH] mm: slub: Ensure that slab_unlock() is atomic

[Vineet Gupta]

On Wednesday 09 March 2016 08:21 PM, Peter Zijlstra wrote:
>> But in SLUB: bit_spin_lock() + __bit_spin_unlock() is acceptable ? How so
>> (ignoring the performance thing for discussion sake, which is a side effect 
>> of
>> this implementation).
> 
> The sort answer is: Per definition. They are defined to work together,
> which is what makes __clear_bit_unlock() such a special function.
> 
>> So despite the comment below in bit_spinlock.h I don't quite comprehend how 
>> this
>> is allowable. And if say, by deduction, this is fine for LLSC or lock 
>> prefixed
>> cases, then isn't this true in general for lot more cases in kernel, i.e. 
>> pairing
>> atomic lock with non-atomic unlock ? I'm missing something !
> 
> x86 (and others) do in fact use non-atomic instructions for
> spin_unlock(). But as this is all arch specific, we can make these
> assumptions. Its just that generic code cannot rely on it.

OK despite being obvious now, I was not seeing the similarity between 
spin_*lock()
and bit_spin*lock() :-(

ARC also uses standard ST for spin_unlock() so by analogy __bit_spin_unlock() 
(for
LLSC case) would be correctly paired with bit_spin_lock().

But then why would anyone need bit_spin_unlock() at all. Specially after this
patch from you which tightens __bit_spin_lock() even more for the general case.

Thing is if the API exists majority of people would would use the more
conservative version w/o understand all these nuances. Can we pursue the path of
moving bit_spin_unlock() over to __bit_spin_lock(): first changing the backend
only and if proven stable replacing the call-sites themselves.

> 
> So let me try and explain.
> 
> 
> The problem as identified is:
> 
> CPU0  CPU1
> 
> bit_spin_lock()   __bit_spin_unlock()
> 1:
>   /* fetch_or, r1 holds the old value */
>   spin_lock
>   loadr1, addr
>   loadr1, addr
>   bclrr2, r1, 1
>   store   r2, addr
>   or  r2, r1, 1
>   store   r2, addr/* lost the store from CPU1 */
>   spin_unlock
> 
>   and r1, 1
>   bnz 2   /* it was set, go wait */
>   ret
> 
> 2:
>   loadr1, addr
>   and r1, 1
>   bnz 2   /* wait until its not set */
> 
>   b   1   /* try again */
> 
> 
> 
> For LL/SC we replace:
> 
>   spin_lock
>   loadr1, addr
> 
>   ...
> 
>   store   r2, addr
>   spin_unlock
> 
> With the (obvious):
> 
> 1:
>   load-locked r1, addr
> 
>   ...
> 
>   store-cond  r2, addr
>   bnz 1 /* or whatever branch instruction is required to 
> retry */
> 
> 
> In this case the failure cannot happen, because the store from CPU1
> would have invalidated the lock from CPU0 and caused the
> store-cond to fail and retry the loop, observing the new value. 

You did it again, A picture is worth thousand words !

Thx,
-Vineet

Re: [PATCH] mm: slub: Ensure that slab_unlock() is atomic

[Vineet Gupta]

On Wednesday 09 March 2016 08:21 PM, Peter Zijlstra wrote:
>> But in SLUB: bit_spin_lock() + __bit_spin_unlock() is acceptable ? How so
>> (ignoring the performance thing for discussion sake, which is a side effect 
>> of
>> this implementation).
> 
> The sort answer is: Per definition. They are defined to work together,
> which is what makes __clear_bit_unlock() such a special function.
> 
>> So despite the comment below in bit_spinlock.h I don't quite comprehend how 
>> this
>> is allowable. And if say, by deduction, this is fine for LLSC or lock 
>> prefixed
>> cases, then isn't this true in general for lot more cases in kernel, i.e. 
>> pairing
>> atomic lock with non-atomic unlock ? I'm missing something !
> 
> x86 (and others) do in fact use non-atomic instructions for
> spin_unlock(). But as this is all arch specific, we can make these
> assumptions. Its just that generic code cannot rely on it.

OK despite being obvious now, I was not seeing the similarity between 
spin_*lock()
and bit_spin*lock() :-(

ARC also uses standard ST for spin_unlock() so by analogy __bit_spin_unlock() 
(for
LLSC case) would be correctly paired with bit_spin_lock().

But then why would anyone need bit_spin_unlock() at all. Specially after this
patch from you which tightens __bit_spin_lock() even more for the general case.

Thing is if the API exists majority of people would would use the more
conservative version w/o understand all these nuances. Can we pursue the path of
moving bit_spin_unlock() over to __bit_spin_lock(): first changing the backend
only and if proven stable replacing the call-sites themselves.

> 
> So let me try and explain.
> 
> 
> The problem as identified is:
> 
> CPU0  CPU1
> 
> bit_spin_lock()   __bit_spin_unlock()
> 1:
>   /* fetch_or, r1 holds the old value */
>   spin_lock
>   loadr1, addr
>   loadr1, addr
>   bclrr2, r1, 1
>   store   r2, addr
>   or  r2, r1, 1
>   store   r2, addr/* lost the store from CPU1 */
>   spin_unlock
> 
>   and r1, 1
>   bnz 2   /* it was set, go wait */
>   ret
> 
> 2:
>   loadr1, addr
>   and r1, 1
>   bnz 2   /* wait until its not set */
> 
>   b   1   /* try again */
> 
> 
> 
> For LL/SC we replace:
> 
>   spin_lock
>   loadr1, addr
> 
>   ...
> 
>   store   r2, addr
>   spin_unlock
> 
> With the (obvious):
> 
> 1:
>   load-locked r1, addr
> 
>   ...
> 
>   store-cond  r2, addr
>   bnz 1 /* or whatever branch instruction is required to 
> retry */
> 
> 
> In this case the failure cannot happen, because the store from CPU1
> would have invalidated the lock from CPU0 and caused the
> store-cond to fail and retry the loop, observing the new value. 

You did it again, A picture is worth thousand words !

Thx,
-Vineet

Re: [RFC 4/9] powerpc/mm: Split huge_pte_alloc function for BOOK3S 64K

[Anshuman Khandual]

On 03/10/2016 01:25 AM, Aneesh Kumar K.V wrote:
> Anshuman Khandual  writes:
> 
>> > [ text/plain ]
>> > From: root 
>> >
>> > Currently the 'huge_pte_alloc' function has two versions, one for the
>> > BOOK3S and the other one for the BOOK3E platforms. This change splits
>> > the BOOK3S version into two parts, one for the 4K page size based
>> > implementation and the other one for the 64K page sized implementation.
>> > This change is one of the prerequisites towards enabling GENERAL_HUGETLB
>> > implementation for BOOK3S 64K based huge pages.
> I really wish we reduce #ifdefs in C code and start splitting hash
> and nonhash code out where ever we can.

Okay but here we are only dealing with 64K and 4K configs inside book3s.
I guess it covers both hash and no hash implementations. Not sure if I
got it correctly.

> 
> What we really want here is a book3s version and in book3s version use
> powerpc specific huge_pte_alloc only if GENERAL_HUGETLB was not defined.

got it.

> Don't limit it to 64k linux page size. We should select between powerpc
> specific implementation and generic code using GENERAL_HUGETLB define.

Got it. will try.

Re: [RFC 4/9] powerpc/mm: Split huge_pte_alloc function for BOOK3S 64K

[Anshuman Khandual]

On 03/10/2016 01:25 AM, Aneesh Kumar K.V wrote:
> Anshuman Khandual  writes:
> 
>> > [ text/plain ]
>> > From: root 
>> >
>> > Currently the 'huge_pte_alloc' function has two versions, one for the
>> > BOOK3S and the other one for the BOOK3E platforms. This change splits
>> > the BOOK3S version into two parts, one for the 4K page size based
>> > implementation and the other one for the 64K page sized implementation.
>> > This change is one of the prerequisites towards enabling GENERAL_HUGETLB
>> > implementation for BOOK3S 64K based huge pages.
> I really wish we reduce #ifdefs in C code and start splitting hash
> and nonhash code out where ever we can.

Okay but here we are only dealing with 64K and 4K configs inside book3s.
I guess it covers both hash and no hash implementations. Not sure if I
got it correctly.

> 
> What we really want here is a book3s version and in book3s version use
> powerpc specific huge_pte_alloc only if GENERAL_HUGETLB was not defined.

got it.

> Don't limit it to 64k linux page size. We should select between powerpc
> specific implementation and generic code using GENERAL_HUGETLB define.

Got it. will try.

[PATCH 1/2] Staging: atm: fix 'endianess' spelling to 'endianness' in fore200e.c This is a patch to the fore200e that fixes the spelling of 'endianess' to the correct one, that is, 'endianness' found

[rneha725]

Signed-off-by: Neha Rani 
---
 drivers/atm/fore200e.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c
index 75dde90..fac5e4fd 100644
--- a/drivers/atm/fore200e.c
+++ b/drivers/atm/fore200e.c
@@ -409,7 +409,7 @@ fore200e_shutdown(struct fore200e* fore200e)
 static u32 fore200e_pca_read(volatile u32 __iomem *addr)
 {
 /* on big-endian hosts, the board is configured to convert
-   the endianess of slave RAM accesses  */
+   the endianness of slave RAM accesses  */
 return le32_to_cpu(readl(addr));
 }
 
@@ -417,7 +417,7 @@ static u32 fore200e_pca_read(volatile u32 __iomem *addr)
 static void fore200e_pca_write(u32 val, volatile u32 __iomem *addr)
 {
 /* on big-endian hosts, the board is configured to convert
-   the endianess of slave RAM accesses  */
+   the endianness of slave RAM accesses  */
 writel(cpu_to_le32(val), addr);
 }
 
@@ -577,7 +577,7 @@ static int fore200e_pca_configure(struct fore200e *fore200e)
 
 master_ctrl = master_ctrl
 #if defined(__BIG_ENDIAN)
-   /* request the PCA board to convert the endianess of slave RAM accesses 
*/
+   /* request the PCA board to convert the endianness of slave RAM 
accesses */
| PCA200E_CTRL_CONVERT_ENDIAN
 #endif
 #if 0
-- 
2.5.0

[PATCH 1/2] Staging: atm: fix 'endianess' spelling to 'endianness' in fore200e.c This is a patch to the fore200e that fixes the spelling of 'endianess' to the correct one, that is, 'endianness' found

[rneha725]

Signed-off-by: Neha Rani 
---
 drivers/atm/fore200e.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/atm/fore200e.c b/drivers/atm/fore200e.c
index 75dde90..fac5e4fd 100644
--- a/drivers/atm/fore200e.c
+++ b/drivers/atm/fore200e.c
@@ -409,7 +409,7 @@ fore200e_shutdown(struct fore200e* fore200e)
 static u32 fore200e_pca_read(volatile u32 __iomem *addr)
 {
 /* on big-endian hosts, the board is configured to convert
-   the endianess of slave RAM accesses  */
+   the endianness of slave RAM accesses  */
 return le32_to_cpu(readl(addr));
 }
 
@@ -417,7 +417,7 @@ static u32 fore200e_pca_read(volatile u32 __iomem *addr)
 static void fore200e_pca_write(u32 val, volatile u32 __iomem *addr)
 {
 /* on big-endian hosts, the board is configured to convert
-   the endianess of slave RAM accesses  */
+   the endianness of slave RAM accesses  */
 writel(cpu_to_le32(val), addr);
 }
 
@@ -577,7 +577,7 @@ static int fore200e_pca_configure(struct fore200e *fore200e)
 
 master_ctrl = master_ctrl
 #if defined(__BIG_ENDIAN)
-   /* request the PCA board to convert the endianess of slave RAM accesses 
*/
+   /* request the PCA board to convert the endianness of slave RAM 
accesses */
| PCA200E_CTRL_CONVERT_ENDIAN
 #endif
 #if 0
-- 
2.5.0

Re: linux-next: removal of the rpmsg tree

[Bjorn Andersson]

On Wed, Mar 9, 2016 at 7:07 AM, Ohad Ben-Cohen  wrote:
> Hi Stephen,
>
> On Wed, Mar 9, 2016 at 7:28 AM, Stephen Rothwell  
> wrote:
>> Hi Ohad,
>>
>> I noticed that the rpmsg tree
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git branch 
>> for-next
>>
>> has not been updated since November 2014.  I am going to remove it from
>> linux-next tomorrow unless I hear that it may be useful.  It can always
>> be easily added back if it proves useful in the future.
>
> That should be fine.
>
> FWIW, Bjorn will most likely setup another rpmsg tree and ask you to
> add it to linux-next, as he's co-maintaining
> remoteproc/rpmsg/hwspinlock now.
>

Thanks for the poke.

Stephen, I'm co-maintain the hwspinlock, rpmsg and remoteproc
subsystems; and will as such maintain the next branches.

Could you please pull the remoteproc next patches from the "for-next" branch of:
git://github.com/andersson/remoteproc.git



I will let you know when we have patches in hwspinlock and rpmsg to
set those up as well, but at the moment we don't have anything
incoming there.

Regards,
Bjorn

Re: linux-next: removal of the rpmsg tree

[Bjorn Andersson]

On Wed, Mar 9, 2016 at 7:07 AM, Ohad Ben-Cohen  wrote:
> Hi Stephen,
>
> On Wed, Mar 9, 2016 at 7:28 AM, Stephen Rothwell  
> wrote:
>> Hi Ohad,
>>
>> I noticed that the rpmsg tree
>>
>>   git://git.kernel.org/pub/scm/linux/kernel/git/ohad/rpmsg.git branch 
>> for-next
>>
>> has not been updated since November 2014.  I am going to remove it from
>> linux-next tomorrow unless I hear that it may be useful.  It can always
>> be easily added back if it proves useful in the future.
>
> That should be fine.
>
> FWIW, Bjorn will most likely setup another rpmsg tree and ask you to
> add it to linux-next, as he's co-maintaining
> remoteproc/rpmsg/hwspinlock now.
>

Thanks for the poke.

Stephen, I'm co-maintain the hwspinlock, rpmsg and remoteproc
subsystems; and will as such maintain the next branches.

Could you please pull the remoteproc next patches from the "for-next" branch of:
git://github.com/andersson/remoteproc.git



I will let you know when we have patches in hwspinlock and rpmsg to
set those up as well, but at the moment we don't have anything
incoming there.

Regards,
Bjorn

[PATCH 2/2] Staging: nvec: fix multiline comment style. This is a patch in nvec.c file that fixes a multiline comment found by checkpatch.pl tool

[rneha725]

Signed-off-by: Neha Rani 
---
 drivers/staging/nvec/nvec.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 4ae44a5..57ad27a 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -508,8 +508,10 @@ static void nvec_rx_completed(struct nvec_chip *nvec)
 
spin_lock(>rx_lock);
 
-   /* add the received data to the work list
-  and move the ring buffer pointer to the next entry */
+   /**
+* add the received data to the work list
+* and move the ring buffer pointer to the next entry
+*/
list_add_tail(>rx->node, >rx_data);
 
spin_unlock(>rx_lock);
-- 
2.5.0

[PATCH 2/2] Staging: nvec: fix multiline comment style. This is a patch in nvec.c file that fixes a multiline comment found by checkpatch.pl tool

[rneha725]

Signed-off-by: Neha Rani 
---
 drivers/staging/nvec/nvec.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/nvec/nvec.c b/drivers/staging/nvec/nvec.c
index 4ae44a5..57ad27a 100644
--- a/drivers/staging/nvec/nvec.c
+++ b/drivers/staging/nvec/nvec.c
@@ -508,8 +508,10 @@ static void nvec_rx_completed(struct nvec_chip *nvec)
 
spin_lock(>rx_lock);
 
-   /* add the received data to the work list
-  and move the ring buffer pointer to the next entry */
+   /**
+* add the received data to the work list
+* and move the ring buffer pointer to the next entry
+*/
list_add_tail(>rx->node, >rx_data);
 
spin_unlock(>rx_lock);
-- 
2.5.0

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

Hi Andrew,

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

  drivers/gpu/drm/omapdrm/omap_gem.c

between commit:

  f6e45661f9be ("dma, mm/pat: Rename dma_*_writecombine() to dma_*_wc()")

from the tip tree and patch:

  "dma-mapping: rename dma_*_writecombine() to dma_*_wc()"

from the akpm tree.

These a basically the same patch, so I dropped the one from the akpm tree.

-- 
Cheers,
Stephen Rothwell

linux-next: manual merge of the akpm tree with the tip tree

[Stephen Rothwell]

Hi Andrew,

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

  drivers/gpu/drm/omapdrm/omap_gem.c

between commit:

  f6e45661f9be ("dma, mm/pat: Rename dma_*_writecombine() to dma_*_wc()")

from the tip tree and patch:

  "dma-mapping: rename dma_*_writecombine() to dma_*_wc()"

from the akpm tree.

These a basically the same patch, so I dropped the one from the akpm tree.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH] arc: use little endian accesses

[Vineet Gupta]

On Thursday 10 March 2016 10:35 AM, Vineet Gupta wrote:
> +CC Noam
>
> On Wednesday 09 March 2016 10:51 PM, Lada Trimasova wrote:
>> > Memory access primitives should use cpu_to_le16, cpu_to_le32, le16_to_cpu
>> > and le32_to_cpu because it is not really guaranteed that drivers handles
>> > any ordering themselves.
> That is the driver issue. readxx as API simply returns data in native 
> endianness.
> We've had EZChip running big endian and so far and they didn't need this 
> change.
>
>> > For example, serial port driver doesn't work when kernel is build for
>> > arc big endian architecture.
> Last I tested Big Endian on SDP with 8250 part + 8250 driver it was working 
> fine.
> I presume this is the systemC model for device and standard 8250 driver and 
> very
> likely the model is not fixed endian or something.
>
> Alexey knows about this stuff - this was discussed on lkml back in 2013 when 
> he
> was fighting the Xilinx systemAce driver endian issues
>

Do you need "native-endian" DT entry in nsimosci DT bindings for uart ?

Re: [PATCH] arc: use little endian accesses

[Vineet Gupta]

On Thursday 10 March 2016 10:35 AM, Vineet Gupta wrote:
> +CC Noam
>
> On Wednesday 09 March 2016 10:51 PM, Lada Trimasova wrote:
>> > Memory access primitives should use cpu_to_le16, cpu_to_le32, le16_to_cpu
>> > and le32_to_cpu because it is not really guaranteed that drivers handles
>> > any ordering themselves.
> That is the driver issue. readxx as API simply returns data in native 
> endianness.
> We've had EZChip running big endian and so far and they didn't need this 
> change.
>
>> > For example, serial port driver doesn't work when kernel is build for
>> > arc big endian architecture.
> Last I tested Big Endian on SDP with 8250 part + 8250 driver it was working 
> fine.
> I presume this is the systemC model for device and standard 8250 driver and 
> very
> likely the model is not fixed endian or something.
>
> Alexey knows about this stuff - this was discussed on lkml back in 2013 when 
> he
> was fighting the Xilinx systemAce driver endian issues
>

Do you need "native-endian" DT entry in nsimosci DT bindings for uart ?

Re: [patch -target tree] usb: gadget: f_tcm: use after free

[Nicholas A. Bellinger]

Hi Andrzej,

On Wed, 2016-03-09 at 13:53 +0100, Andrzej Pietrasiewicz wrote:
> Hi Nicholas,
> 
> W dniu 05.03.2016 o 08:26, Nicholas A. Bellinger pisze:
> > Hi Felipe + usb-gadget folks,
> >
> > On Wed, 2016-03-02 at 13:55 +0200, Felipe Balbi wrote:
> 
> 
> 
> >
> > usb-gadget/tcm: Conversion to percpu_ida tag pre-allocation
> > http://www.spinics.net/lists/target-devel/msg11777.html
> >
> > usb-gadget/tcm: Convert to TARGET_SCF_ACK_KREF I/O krefs
> > http://www.spinics.net/lists/target-devel/msg11782.html
> >
> > Felipe, Sebastian, & Andrezj, would you be so kind to review and test
> > usb-gadget using target-pending/for-next code..?
> >
> >
> 
> Actually I have noticed a problem at
> 8b00965 "target: Convert demo-mode only drivers to target_alloc_session"
> 
> I get:
> 
> [ 1698.406304] configfs-gadget gadget: high-speed config #1: c
> [ 1698.410547] Using the BOT protocol
> [ 1698.414163] Missing nexus, ignoring command
> [ 1698.417944] bot_cmd_complete(309): -22
> 
> I think the third message is from f_tcm. It is because
> tpg->tpg_nexus is not set anymore, because the line
> 
>   tpg->tpg_nexus = tv_nexus;
> 
> is removed by the commit mentioned above.
> 
> Restoring this line fixes the problem.

Thanks for testing!

Applying the following patch to re-add the missing assingment
as a proper alloc_session callback.

diff --git a/drivers/usb/gadget/function/f_tcm.c 
b/drivers/usb/gadget/function/f_tcm.c
index e352a31..348140c 100644
--- a/drivers/usb/gadget/function/f_tcm.c
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -1570,6 +1570,16 @@ out:
return ret;
 }
 
+static int usbg_alloc_sess_cb(struct se_portal_group *se_tpg,
+ struct se_session *se_sess, void *p)
+{
+   struct usbg_tpg *tpg = container_of(se_tpg,
+   struct usbg_tpg, se_tpg);
+
+   tpg->tpg_nexus = p;
+   return 0;
+}
+
 static int tcm_usbg_make_nexus(struct usbg_tpg *tpg, char *name)
 {
struct tcm_usbg_nexus *tv_nexus;
@@ -1591,7 +1601,7 @@ static int tcm_usbg_make_nexus(struct usbg_tpg *tpg, char 
*name)
tv_nexus->tvn_se_sess = target_alloc_session(>se_tpg, 128,
 sizeof(struct usbg_cmd),
 TARGET_PROT_NORMAL, name,
-tv_nexus, NULL);
+tv_nexus, 
usbg_alloc_sess_cb);
if (IS_ERR(tv_nexus->tvn_se_sess)) {
 #define MAKE_NEXUS_MSG "core_tpg_check_initiator_node_acl() failed for %s\n"
pr_debug(MAKE_NEXUS_MSG, name);

> 
> Then percpu_ida commit produces the below result
> (it does not happen immediately, but a while after
> running the script).
> I did not bisect, though; I only checked the commits
> which alter drivers/usb/gadget/function/f_tcm.c.
> The last one which (almost) works is:
> 
> 8b00965 "target: Convert demo-mode only drivers to target_alloc_session"
> 
> AP
> 
> I used the following script:
> 
> 8<
> 
> #!/bin/bash
> 
> mount -t configfs none /sys/kernel/config
> modprobe libcomposite
> cd /sys/kernel/config/usb_gadget
> mkdir tcm
> cd tcm
> mkdir functions/tcm.0
> cd /sys/kernel/config/target/
> mkdir usb_gadget
> cd usb_gadget
> mkdir naa.0123456789abcdef
> cd naa.0123456789abcdef
> mkdir tpgt_1
> cd tpgt_1
> echo naa.01234567890abcdef > nexus
> echo 1 > enable
> cd /sys/kernel/config/usb_gadget/tcm
> mkdir configs/c.1
> ln -s functions/tcm.0 configs/c.1
> echo 0x0525 > idVendor
> echo 0x1234 > idProduct
> echo 1240.dwc3 > UDC
> 
> 8<
> 
> # [   45.510513] ERR bot_status_complete(73)
> [   45.671921] configfs-gadget gadget: high-speed config #1: c
> [   45.676158] Using the BOT protocol
> [   45.679860] [ cut here ]
> [   45.683981] kernel BUG at drivers/target/target_core_transport.c:1476!

Mmmm, usbg_get_cmd() was missing an explicit memset() after tag lookup.

How about the following..?

diff --git a/drivers/usb/gadget/function/f_tcm.c 
b/drivers/usb/gadget/function/f_tcm.c
index e352a31..d4e8a91 100644
--- a/drivers/usb/gadget/function/f_tcm.c
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -1078,6 +1078,7 @@ static struct usbg_cmd *usbg_get_cmd(struct f_uas *fu,
return ERR_PTR(-ENOMEM);
 
cmd = &((struct usbg_cmd *)se_sess->sess_cmd_map)[tag];
+   memset(cmd, 0, sizeof(*cmd));
cmd->se_cmd.map_tag = tag;
cmd->se_cmd.tag = cmd->tag = scsi_tag;
cmd->fu = fu;

Re: [PATCH] ext4: drop unneeded BUFFER_TRACE in ext4_delete_inline_entry()

[Theodore Ts'o]

On Sun, Jan 31, 2016 at 11:51:54PM +0800, Geliang Tang wrote:
> BUFFER_TRACE info "call ext4_handle_dirty_metadata" doesn't match the
> code, so drop it.
> 
> Signed-off-by: Geliang Tang 

Thanks, applied.

- Ted

Re: [patch -target tree] usb: gadget: f_tcm: use after free

[Nicholas A. Bellinger]

Hi Andrzej,

On Wed, 2016-03-09 at 13:53 +0100, Andrzej Pietrasiewicz wrote:
> Hi Nicholas,
> 
> W dniu 05.03.2016 o 08:26, Nicholas A. Bellinger pisze:
> > Hi Felipe + usb-gadget folks,
> >
> > On Wed, 2016-03-02 at 13:55 +0200, Felipe Balbi wrote:
> 
> 
> 
> >
> > usb-gadget/tcm: Conversion to percpu_ida tag pre-allocation
> > http://www.spinics.net/lists/target-devel/msg11777.html
> >
> > usb-gadget/tcm: Convert to TARGET_SCF_ACK_KREF I/O krefs
> > http://www.spinics.net/lists/target-devel/msg11782.html
> >
> > Felipe, Sebastian, & Andrezj, would you be so kind to review and test
> > usb-gadget using target-pending/for-next code..?
> >
> >
> 
> Actually I have noticed a problem at
> 8b00965 "target: Convert demo-mode only drivers to target_alloc_session"
> 
> I get:
> 
> [ 1698.406304] configfs-gadget gadget: high-speed config #1: c
> [ 1698.410547] Using the BOT protocol
> [ 1698.414163] Missing nexus, ignoring command
> [ 1698.417944] bot_cmd_complete(309): -22
> 
> I think the third message is from f_tcm. It is because
> tpg->tpg_nexus is not set anymore, because the line
> 
>   tpg->tpg_nexus = tv_nexus;
> 
> is removed by the commit mentioned above.
> 
> Restoring this line fixes the problem.

Thanks for testing!

Applying the following patch to re-add the missing assingment
as a proper alloc_session callback.

diff --git a/drivers/usb/gadget/function/f_tcm.c 
b/drivers/usb/gadget/function/f_tcm.c
index e352a31..348140c 100644
--- a/drivers/usb/gadget/function/f_tcm.c
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -1570,6 +1570,16 @@ out:
return ret;
 }
 
+static int usbg_alloc_sess_cb(struct se_portal_group *se_tpg,
+ struct se_session *se_sess, void *p)
+{
+   struct usbg_tpg *tpg = container_of(se_tpg,
+   struct usbg_tpg, se_tpg);
+
+   tpg->tpg_nexus = p;
+   return 0;
+}
+
 static int tcm_usbg_make_nexus(struct usbg_tpg *tpg, char *name)
 {
struct tcm_usbg_nexus *tv_nexus;
@@ -1591,7 +1601,7 @@ static int tcm_usbg_make_nexus(struct usbg_tpg *tpg, char 
*name)
tv_nexus->tvn_se_sess = target_alloc_session(>se_tpg, 128,
 sizeof(struct usbg_cmd),
 TARGET_PROT_NORMAL, name,
-tv_nexus, NULL);
+tv_nexus, 
usbg_alloc_sess_cb);
if (IS_ERR(tv_nexus->tvn_se_sess)) {
 #define MAKE_NEXUS_MSG "core_tpg_check_initiator_node_acl() failed for %s\n"
pr_debug(MAKE_NEXUS_MSG, name);

> 
> Then percpu_ida commit produces the below result
> (it does not happen immediately, but a while after
> running the script).
> I did not bisect, though; I only checked the commits
> which alter drivers/usb/gadget/function/f_tcm.c.
> The last one which (almost) works is:
> 
> 8b00965 "target: Convert demo-mode only drivers to target_alloc_session"
> 
> AP
> 
> I used the following script:
> 
> 8<
> 
> #!/bin/bash
> 
> mount -t configfs none /sys/kernel/config
> modprobe libcomposite
> cd /sys/kernel/config/usb_gadget
> mkdir tcm
> cd tcm
> mkdir functions/tcm.0
> cd /sys/kernel/config/target/
> mkdir usb_gadget
> cd usb_gadget
> mkdir naa.0123456789abcdef
> cd naa.0123456789abcdef
> mkdir tpgt_1
> cd tpgt_1
> echo naa.01234567890abcdef > nexus
> echo 1 > enable
> cd /sys/kernel/config/usb_gadget/tcm
> mkdir configs/c.1
> ln -s functions/tcm.0 configs/c.1
> echo 0x0525 > idVendor
> echo 0x1234 > idProduct
> echo 1240.dwc3 > UDC
> 
> 8<
> 
> # [   45.510513] ERR bot_status_complete(73)
> [   45.671921] configfs-gadget gadget: high-speed config #1: c
> [   45.676158] Using the BOT protocol
> [   45.679860] [ cut here ]
> [   45.683981] kernel BUG at drivers/target/target_core_transport.c:1476!

Mmmm, usbg_get_cmd() was missing an explicit memset() after tag lookup.

How about the following..?

diff --git a/drivers/usb/gadget/function/f_tcm.c 
b/drivers/usb/gadget/function/f_tcm.c
index e352a31..d4e8a91 100644
--- a/drivers/usb/gadget/function/f_tcm.c
+++ b/drivers/usb/gadget/function/f_tcm.c
@@ -1078,6 +1078,7 @@ static struct usbg_cmd *usbg_get_cmd(struct f_uas *fu,
return ERR_PTR(-ENOMEM);
 
cmd = &((struct usbg_cmd *)se_sess->sess_cmd_map)[tag];
+   memset(cmd, 0, sizeof(*cmd));
cmd->se_cmd.map_tag = tag;
cmd->se_cmd.tag = cmd->tag = scsi_tag;
cmd->fu = fu;

Re: [PATCH] ext4: drop unneeded BUFFER_TRACE in ext4_delete_inline_entry()

[Theodore Ts'o]

On Sun, Jan 31, 2016 at 11:51:54PM +0800, Geliang Tang wrote:
> BUFFER_TRACE info "call ext4_handle_dirty_metadata" doesn't match the
> code, so drop it.
> 
> Signed-off-by: Geliang Tang 

Thanks, applied.

- Ted

Re: [RFC 6/9] powerpc/hugetlb: Enable ARCH_WANT_GENERAL_HUGETLB for BOOK3S 64K

[Anshuman Khandual]

On 03/10/2016 01:28 AM, Aneesh Kumar K.V wrote:
> Anshuman Khandual  writes:
> 
>> > [ text/plain ]
>> > This enables ARCH_WANT_GENERAL_HUGETLB for BOOK3S 64K in Kconfig.
>> > It also implements a new function 'pte_huge' which is required by
>> > function 'huge_pte_alloc' from generic VM. Existing BOOK3S 64K
>> > specific functions 'huge_pte_alloc' and 'huge_pte_offset' (which
>> > are no longer required) are removed with this change.
>> >
> You want this to be the last patch isn't it ? And you are mixing too

Yeah, it should be the last one.

> many things in this patch. Why not do this
> 
> * book3s specific hash pte routines
> * book3s add conditional based on GENERAL_HUGETLB
> * Enable GENERAL_HUGETLB for 64k page size config

which creates three separate patches ?

Re: [RFC 6/9] powerpc/hugetlb: Enable ARCH_WANT_GENERAL_HUGETLB for BOOK3S 64K

[Anshuman Khandual]

On 03/10/2016 01:28 AM, Aneesh Kumar K.V wrote:
> Anshuman Khandual  writes:
> 
>> > [ text/plain ]
>> > This enables ARCH_WANT_GENERAL_HUGETLB for BOOK3S 64K in Kconfig.
>> > It also implements a new function 'pte_huge' which is required by
>> > function 'huge_pte_alloc' from generic VM. Existing BOOK3S 64K
>> > specific functions 'huge_pte_alloc' and 'huge_pte_offset' (which
>> > are no longer required) are removed with this change.
>> >
> You want this to be the last patch isn't it ? And you are mixing too

Yeah, it should be the last one.

> many things in this patch. Why not do this
> 
> * book3s specific hash pte routines
> * book3s add conditional based on GENERAL_HUGETLB
> * Enable GENERAL_HUGETLB for 64k page size config

which creates three separate patches ?

[PATCH 2/4] media: v4l2-mc add v4l_change_media_source() to invoke change_source

[Shuah Khan]

Add a common routine to invoke media device change_source handler.

Signed-off-by: Shuah Khan 
---
 drivers/media/v4l2-core/v4l2-mc.c | 14 ++
 include/media/v4l2-mc.h   | 20 +++-
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-mc.c 
b/drivers/media/v4l2-core/v4l2-mc.c
index ae661ac..478b2768 100644
--- a/drivers/media/v4l2-core/v4l2-mc.c
+++ b/drivers/media/v4l2-core/v4l2-mc.c
@@ -217,6 +217,20 @@ void v4l_disable_media_source(struct video_device *vdev)
 }
 EXPORT_SYMBOL_GPL(v4l_disable_media_source);
 
+int v4l_change_media_source(struct video_device *vdev)
+{
+   struct media_device *mdev = vdev->entity.graph_obj.mdev;
+   int ret;
+
+   if (!mdev || !mdev->change_source)
+   return 0;
+   ret = mdev->change_source(>entity, >pipe);
+   if (ret)
+   return -EBUSY;
+   return 0;
+}
+EXPORT_SYMBOL_GPL(v4l_change_media_source);
+
 int v4l_vb2q_enable_media_source(struct vb2_queue *q)
 {
struct v4l2_fh *fh = q->owner;
diff --git a/include/media/v4l2-mc.h b/include/media/v4l2-mc.h
index 98a938a..884b969 100644
--- a/include/media/v4l2-mc.h
+++ b/include/media/v4l2-mc.h
@@ -154,8 +154,26 @@ int v4l_enable_media_source(struct video_device *vdev);
  */
 void v4l_disable_media_source(struct video_device *vdev);
 
+/**
+ * v4l_change_media_source() - Hold media source for exclusive use
+ * if free
+ *
+ * @vdev:  pointer to struct video_device
+ *
+ * This interface calls change_source handler to change
+ * the current source it is holding. The change_source
+ * disables the current source and starts pipeline to
+ * the new source. This interface should be used when
+ * user changes source using s_input handler to keep
+ * the previously granted permission for exclusive use
+ * with a new input source.
+ *
+ * Return: returns zero on success or a negative error code.
+ */
+int v4l_change_media_source(struct video_device *vdev);
+
 /*
- * v4l_vb2q_enable_media_tuner -  Hold media source for exclusive use
+ * v4l_vb2q_enable_media_source - Hold media source for exclusive use
  *   if free.
  * @q - pointer to struct vb2_queue
  *
-- 
2.5.0

[PATCH 1/4] media: add change_source handler function pointer

[Shuah Khan]

Add change_source handler function pointer to struct media_device. Using
the change_source handler, driver can disable current source and enable
new one in one step when user selects a new input.

Signed-off-by: Shuah Khan 
---
 include/media/media-device.h | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/include/media/media-device.h b/include/media/media-device.h
index df74cfa..d9867ed 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -309,9 +309,11 @@ struct media_entity_notify {
  * @pm_count_walk: Graph walk for power state walk. Access serialised using
  *graph_mutex.
  *
- * @source_priv: Driver Private data for enable/disable source handlers
+ * @source_priv: Driver Private data for enable/disable/change source
+ *  handlers
  * @enable_source: Enable Source Handler function pointer
  * @disable_source: Disable Source Handler function pointer
+ * @change_source: Change Source Handler function pointer
  *
  * @link_notify: Link state change notification callback
  *
@@ -326,14 +328,22 @@ struct media_entity_notify {
  * be unique.
  *
  * @enable_source is a handler to find source entity for the
- * sink entity  and activate the link between them if source
+ * sink entity and activate the link between them if source
  * entity is free. Drivers should call this handler before
  * accessing the source.
  *
  * @disable_source is a handler to find source entity for the
- * sink entity  and deactivate the link between them. Drivers
+ * sink entity and deactivate the link between them. Drivers
  * should call this handler to release the source.
  *
+ * @change_source is a handler to find source entity for the
+ * sink entity and deactivate the link between them. Once the
+ * existing link is deactivated, it will find and activate the
+ * source for the sink for the newly selected input. Drivers
+ * should call this handler to change the source when user
+ * changes input. Using change_source helps not loose the hold
+ * on the media resource when a new input is selected.
+ *
  * Note: Bridge driver is expected to implement and set the
  * handler when media_device is registered or when
  * bridge driver finds the media_device during probe.
@@ -381,6 +391,8 @@ struct media_device {
int (*enable_source)(struct media_entity *entity,
 struct media_pipeline *pipe);
void (*disable_source)(struct media_entity *entity);
+   int (*change_source)(struct media_entity *entity,
+struct media_pipeline *pipe);
 
int (*link_notify)(struct media_link *link, u32 flags,
   unsigned int notification);
-- 
2.5.0

[PATCH 2/4] media: v4l2-mc add v4l_change_media_source() to invoke change_source

[Shuah Khan]

Add a common routine to invoke media device change_source handler.

Signed-off-by: Shuah Khan 
---
 drivers/media/v4l2-core/v4l2-mc.c | 14 ++
 include/media/v4l2-mc.h   | 20 +++-
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-mc.c 
b/drivers/media/v4l2-core/v4l2-mc.c
index ae661ac..478b2768 100644
--- a/drivers/media/v4l2-core/v4l2-mc.c
+++ b/drivers/media/v4l2-core/v4l2-mc.c
@@ -217,6 +217,20 @@ void v4l_disable_media_source(struct video_device *vdev)
 }
 EXPORT_SYMBOL_GPL(v4l_disable_media_source);
 
+int v4l_change_media_source(struct video_device *vdev)
+{
+   struct media_device *mdev = vdev->entity.graph_obj.mdev;
+   int ret;
+
+   if (!mdev || !mdev->change_source)
+   return 0;
+   ret = mdev->change_source(>entity, >pipe);
+   if (ret)
+   return -EBUSY;
+   return 0;
+}
+EXPORT_SYMBOL_GPL(v4l_change_media_source);
+
 int v4l_vb2q_enable_media_source(struct vb2_queue *q)
 {
struct v4l2_fh *fh = q->owner;
diff --git a/include/media/v4l2-mc.h b/include/media/v4l2-mc.h
index 98a938a..884b969 100644
--- a/include/media/v4l2-mc.h
+++ b/include/media/v4l2-mc.h
@@ -154,8 +154,26 @@ int v4l_enable_media_source(struct video_device *vdev);
  */
 void v4l_disable_media_source(struct video_device *vdev);
 
+/**
+ * v4l_change_media_source() - Hold media source for exclusive use
+ * if free
+ *
+ * @vdev:  pointer to struct video_device
+ *
+ * This interface calls change_source handler to change
+ * the current source it is holding. The change_source
+ * disables the current source and starts pipeline to
+ * the new source. This interface should be used when
+ * user changes source using s_input handler to keep
+ * the previously granted permission for exclusive use
+ * with a new input source.
+ *
+ * Return: returns zero on success or a negative error code.
+ */
+int v4l_change_media_source(struct video_device *vdev);
+
 /*
- * v4l_vb2q_enable_media_tuner -  Hold media source for exclusive use
+ * v4l_vb2q_enable_media_source - Hold media source for exclusive use
  *   if free.
  * @q - pointer to struct vb2_queue
  *
-- 
2.5.0

[PATCH 1/4] media: add change_source handler function pointer

[Shuah Khan]

Add change_source handler function pointer to struct media_device. Using
the change_source handler, driver can disable current source and enable
new one in one step when user selects a new input.

Signed-off-by: Shuah Khan 
---
 include/media/media-device.h | 18 +++---
 1 file changed, 15 insertions(+), 3 deletions(-)

diff --git a/include/media/media-device.h b/include/media/media-device.h
index df74cfa..d9867ed 100644
--- a/include/media/media-device.h
+++ b/include/media/media-device.h
@@ -309,9 +309,11 @@ struct media_entity_notify {
  * @pm_count_walk: Graph walk for power state walk. Access serialised using
  *graph_mutex.
  *
- * @source_priv: Driver Private data for enable/disable source handlers
+ * @source_priv: Driver Private data for enable/disable/change source
+ *  handlers
  * @enable_source: Enable Source Handler function pointer
  * @disable_source: Disable Source Handler function pointer
+ * @change_source: Change Source Handler function pointer
  *
  * @link_notify: Link state change notification callback
  *
@@ -326,14 +328,22 @@ struct media_entity_notify {
  * be unique.
  *
  * @enable_source is a handler to find source entity for the
- * sink entity  and activate the link between them if source
+ * sink entity and activate the link between them if source
  * entity is free. Drivers should call this handler before
  * accessing the source.
  *
  * @disable_source is a handler to find source entity for the
- * sink entity  and deactivate the link between them. Drivers
+ * sink entity and deactivate the link between them. Drivers
  * should call this handler to release the source.
  *
+ * @change_source is a handler to find source entity for the
+ * sink entity and deactivate the link between them. Once the
+ * existing link is deactivated, it will find and activate the
+ * source for the sink for the newly selected input. Drivers
+ * should call this handler to change the source when user
+ * changes input. Using change_source helps not loose the hold
+ * on the media resource when a new input is selected.
+ *
  * Note: Bridge driver is expected to implement and set the
  * handler when media_device is registered or when
  * bridge driver finds the media_device during probe.
@@ -381,6 +391,8 @@ struct media_device {
int (*enable_source)(struct media_entity *entity,
 struct media_pipeline *pipe);
void (*disable_source)(struct media_entity *entity);
+   int (*change_source)(struct media_entity *entity,
+struct media_pipeline *pipe);
 
int (*link_notify)(struct media_link *link, u32 flags,
   unsigned int notification);
-- 
2.5.0

[PATCH 3/4] media: au0828 add media device change_source handler

[Shuah Khan]

Add media device change_source handler. Using the change_source handler,
driver can disable current source and enable new one in one step when
user selects a new input.

Signed-off-by: Shuah Khan 
---
 drivers/media/usb/au0828/au0828-core.c | 64 --
 1 file changed, 46 insertions(+), 18 deletions(-)

diff --git a/drivers/media/usb/au0828/au0828-core.c 
b/drivers/media/usb/au0828/au0828-core.c
index 5dc82e8..01dba5a 100644
--- a/drivers/media/usb/au0828/au0828-core.c
+++ b/drivers/media/usb/au0828/au0828-core.c
@@ -258,8 +258,8 @@ create_link:
}
 }
 
-static int au0828_enable_source(struct media_entity *entity,
-   struct media_pipeline *pipe)
+static int __au0828_enable_source(struct media_entity *entity,
+ struct media_pipeline *pipe)
 {
struct media_entity  *source, *find_source;
struct media_entity *sink;
@@ -268,11 +268,6 @@ static int au0828_enable_source(struct media_entity 
*entity,
struct media_device *mdev = entity->graph_obj.mdev;
struct au0828_dev *dev;
 
-   if (!mdev)
-   return -ENODEV;
-
-   mutex_lock(>graph_mutex);
-
dev = mdev->source_priv;
 
/*
@@ -399,28 +394,36 @@ static int au0828_enable_source(struct media_entity 
*entity,
 dev->active_source->name, dev->active_sink->name,
 dev->active_link_owner->name, ret);
 end:
-   mutex_unlock(>graph_mutex);
pr_debug("au0828_enable_source() end %s %d %d\n",
 entity->name, entity->function, ret);
return ret;
 }
 
-static void au0828_disable_source(struct media_entity *entity)
+static int au0828_enable_source(struct media_entity *entity,
+   struct media_pipeline *pipe)
 {
-   int ret = 0;
struct media_device *mdev = entity->graph_obj.mdev;
-   struct au0828_dev *dev;
+   int ret;
 
if (!mdev)
-   return;
+   return -ENODEV;
 
mutex_lock(>graph_mutex);
+   ret = __au0828_enable_source(entity, pipe);
+   mutex_unlock(>graph_mutex);
+   return ret;
+}
+
+static void __au0828_disable_source(struct media_entity *entity)
+{
+   int ret = 0;
+   struct media_device *mdev = entity->graph_obj.mdev;
+   struct au0828_dev *dev;
+
dev = mdev->source_priv;
 
-   if (!dev->active_link) {
-   ret = -ENODEV;
-   goto end;
-   }
+   if (!dev->active_link)
+   return;
 
/* link is active - stop pipeline from source (tuner) */
if (dev->active_link->sink->entity == dev->active_sink &&
@@ -430,7 +433,7 @@ static void au0828_disable_source(struct media_entity 
*entity)
 * has active pipeline
*/
if (dev->active_link_owner != entity)
-   goto end;
+   return;
__media_entity_pipeline_stop(entity);
ret = __media_entity_setup_link(dev->active_link, 0);
if (ret)
@@ -445,10 +448,34 @@ static void au0828_disable_source(struct media_entity 
*entity)
dev->active_source = NULL;
dev->active_sink = NULL;
}
+}
 
-end:
+static void au0828_disable_source(struct media_entity *entity)
+{
+   struct media_device *mdev = entity->graph_obj.mdev;
+
+   if (!mdev)
+   return;
+
+   mutex_lock(>graph_mutex);
+   __au0828_disable_source(entity);
mutex_unlock(>graph_mutex);
 }
+static int au0828_change_source(struct media_entity *entity,
+   struct media_pipeline *pipe)
+{
+   struct media_device *mdev = entity->graph_obj.mdev;
+   int ret;
+
+   if (!mdev)
+   return -ENODEV;
+
+   mutex_lock(>graph_mutex);
+   __au0828_disable_source(entity);
+   ret = __au0828_enable_source(entity, pipe);
+   mutex_unlock(>graph_mutex);
+   return ret;
+}
 #endif
 
 static int au0828_media_device_register(struct au0828_dev *dev,
@@ -520,6 +547,7 @@ static int au0828_media_device_register(struct au0828_dev 
*dev,
dev->media_dev->source_priv = (void *) dev;
dev->media_dev->enable_source = au0828_enable_source;
dev->media_dev->disable_source = au0828_disable_source;
+   dev->media_dev->change_source = au0828_change_source;
 #endif
return 0;
 }
-- 
2.5.0

Re: modules: set mod->state to GOING before going notifiers are called

[Jessica Yu]

+++ Rusty Russell [10/03/16 13:57 +1030]:

Jessica Yu  writes:

In load_module(), the going notifiers are called during error handling
when an error occurs after the coming notifiers have already been called.
However, a module's state is still MODULE_STATE_COMING when the going
notifiers are called in the error path. To be consistent, also set
mod->state to MODULE_STATE_GOING before calling the going notifiers.

Signed-off-by: Jessica Yu 
---
 kernel/module.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/module.c b/kernel/module.c
index 1981ae0..9e80576 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3494,6 +3494,9 @@ static int load_module(struct load_info *info, const char 
__user *uargs,
return do_init_module(mod);

  coming_cleanup:
+   mutex_lock(_mutex);
+   mod->state = MODULE_STATE_GOING;
+   mutex_unlock(_mutex);
blocking_notifier_call_chain(_notify_list,
 MODULE_STATE_GOING, mod);


Actually, reviewing this patch makes me realize it is wrong.

We rely on the state of the module being MODULE_STATE_COMING here:

   static inline int strong_try_module_get(struct module *mod)
   {
BUG_ON(mod && mod->state == MODULE_STATE_UNFORMED);
if (mod && mod->state == MODULE_STATE_COMING)
return -EBUSY;

We will just have to document that the notifier can be called with
a module in MODULE_STATE_COMING if it never succeeded its
initialization.


Ah, thanks for catching that. I think I remember seeing this conditional and
assuming it wouldn't be a problem since GOING modules would fail in
try_module_get() (as it is does not pass the module_is_live() test) and
subsequently strong_try_module_get() would also fail.. But, I think I ought to
review how module states interact before making a change like this, so, please
ignore this patch.

Jessica

[PATCH 3/4] media: au0828 add media device change_source handler

[Shuah Khan]

Add media device change_source handler. Using the change_source handler,
driver can disable current source and enable new one in one step when
user selects a new input.

Signed-off-by: Shuah Khan 
---
 drivers/media/usb/au0828/au0828-core.c | 64 --
 1 file changed, 46 insertions(+), 18 deletions(-)

diff --git a/drivers/media/usb/au0828/au0828-core.c 
b/drivers/media/usb/au0828/au0828-core.c
index 5dc82e8..01dba5a 100644
--- a/drivers/media/usb/au0828/au0828-core.c
+++ b/drivers/media/usb/au0828/au0828-core.c
@@ -258,8 +258,8 @@ create_link:
}
 }
 
-static int au0828_enable_source(struct media_entity *entity,
-   struct media_pipeline *pipe)
+static int __au0828_enable_source(struct media_entity *entity,
+ struct media_pipeline *pipe)
 {
struct media_entity  *source, *find_source;
struct media_entity *sink;
@@ -268,11 +268,6 @@ static int au0828_enable_source(struct media_entity 
*entity,
struct media_device *mdev = entity->graph_obj.mdev;
struct au0828_dev *dev;
 
-   if (!mdev)
-   return -ENODEV;
-
-   mutex_lock(>graph_mutex);
-
dev = mdev->source_priv;
 
/*
@@ -399,28 +394,36 @@ static int au0828_enable_source(struct media_entity 
*entity,
 dev->active_source->name, dev->active_sink->name,
 dev->active_link_owner->name, ret);
 end:
-   mutex_unlock(>graph_mutex);
pr_debug("au0828_enable_source() end %s %d %d\n",
 entity->name, entity->function, ret);
return ret;
 }
 
-static void au0828_disable_source(struct media_entity *entity)
+static int au0828_enable_source(struct media_entity *entity,
+   struct media_pipeline *pipe)
 {
-   int ret = 0;
struct media_device *mdev = entity->graph_obj.mdev;
-   struct au0828_dev *dev;
+   int ret;
 
if (!mdev)
-   return;
+   return -ENODEV;
 
mutex_lock(>graph_mutex);
+   ret = __au0828_enable_source(entity, pipe);
+   mutex_unlock(>graph_mutex);
+   return ret;
+}
+
+static void __au0828_disable_source(struct media_entity *entity)
+{
+   int ret = 0;
+   struct media_device *mdev = entity->graph_obj.mdev;
+   struct au0828_dev *dev;
+
dev = mdev->source_priv;
 
-   if (!dev->active_link) {
-   ret = -ENODEV;
-   goto end;
-   }
+   if (!dev->active_link)
+   return;
 
/* link is active - stop pipeline from source (tuner) */
if (dev->active_link->sink->entity == dev->active_sink &&
@@ -430,7 +433,7 @@ static void au0828_disable_source(struct media_entity 
*entity)
 * has active pipeline
*/
if (dev->active_link_owner != entity)
-   goto end;
+   return;
__media_entity_pipeline_stop(entity);
ret = __media_entity_setup_link(dev->active_link, 0);
if (ret)
@@ -445,10 +448,34 @@ static void au0828_disable_source(struct media_entity 
*entity)
dev->active_source = NULL;
dev->active_sink = NULL;
}
+}
 
-end:
+static void au0828_disable_source(struct media_entity *entity)
+{
+   struct media_device *mdev = entity->graph_obj.mdev;
+
+   if (!mdev)
+   return;
+
+   mutex_lock(>graph_mutex);
+   __au0828_disable_source(entity);
mutex_unlock(>graph_mutex);
 }
+static int au0828_change_source(struct media_entity *entity,
+   struct media_pipeline *pipe)
+{
+   struct media_device *mdev = entity->graph_obj.mdev;
+   int ret;
+
+   if (!mdev)
+   return -ENODEV;
+
+   mutex_lock(>graph_mutex);
+   __au0828_disable_source(entity);
+   ret = __au0828_enable_source(entity, pipe);
+   mutex_unlock(>graph_mutex);
+   return ret;
+}
 #endif
 
 static int au0828_media_device_register(struct au0828_dev *dev,
@@ -520,6 +547,7 @@ static int au0828_media_device_register(struct au0828_dev 
*dev,
dev->media_dev->source_priv = (void *) dev;
dev->media_dev->enable_source = au0828_enable_source;
dev->media_dev->disable_source = au0828_disable_source;
+   dev->media_dev->change_source = au0828_change_source;
 #endif
return 0;
 }
-- 
2.5.0

Re: modules: set mod->state to GOING before going notifiers are called

[Jessica Yu]

+++ Rusty Russell [10/03/16 13:57 +1030]:

Jessica Yu  writes:

In load_module(), the going notifiers are called during error handling
when an error occurs after the coming notifiers have already been called.
However, a module's state is still MODULE_STATE_COMING when the going
notifiers are called in the error path. To be consistent, also set
mod->state to MODULE_STATE_GOING before calling the going notifiers.

Signed-off-by: Jessica Yu 
---
 kernel/module.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/kernel/module.c b/kernel/module.c
index 1981ae0..9e80576 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3494,6 +3494,9 @@ static int load_module(struct load_info *info, const char 
__user *uargs,
return do_init_module(mod);

  coming_cleanup:
+   mutex_lock(_mutex);
+   mod->state = MODULE_STATE_GOING;
+   mutex_unlock(_mutex);
blocking_notifier_call_chain(_notify_list,
 MODULE_STATE_GOING, mod);


Actually, reviewing this patch makes me realize it is wrong.

We rely on the state of the module being MODULE_STATE_COMING here:

   static inline int strong_try_module_get(struct module *mod)
   {
BUG_ON(mod && mod->state == MODULE_STATE_UNFORMED);
if (mod && mod->state == MODULE_STATE_COMING)
return -EBUSY;

We will just have to document that the notifier can be called with
a module in MODULE_STATE_COMING if it never succeeded its
initialization.


Ah, thanks for catching that. I think I remember seeing this conditional and
assuming it wouldn't be a problem since GOING modules would fail in
try_module_get() (as it is does not pass the module_is_live() test) and
subsequently strong_try_module_get() would also fail.. But, I think I ought to
review how module states interact before making a change like this, so, please
ignore this patch.

Jessica