Re: [PATCH 1/2] vfio, platform: add support for ACPI while detecting the reset driver

[Dan Carpenter]

On Tue, Mar 08, 2016 at 10:37:34AM -0500, Sinan Kaya wrote:
> On 3/8/2016 10:33 AM, Sinan Kaya wrote:
> > +   int rc = 0;
> > +
> 
> I should have initialized this to -1. 
> 

-1 is a magic number which stands for -EPERM which is wrong.  Use
-ENODEV.

regards,
dan carpenter

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

[Ingo Molnar]

* Stephen Rothwell  wrote:

> 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.

Andrew, what's your preference for merging it? I can drop it too.

Thanks,

Ingo

Re: [PATCH 1/3] block: introduce device_add_disk()

[Christoph Hellwig]

>  /**
> - * add_disk - add partitioning information to kernel list
> + * device_add_disk - add partitioning information to kernel list
> + * @parent: parent device for the disk
>   * @disk: per-device partitioning information
>   *
>   * This function registers the partitioning information in @disk
> @@ -581,7 +582,7 @@ exit:
>   *
>   * FIXME: error handling
>   */
> -void add_disk(struct gendisk *disk)
> +int device_add_disk(struct device *parent, struct gendisk *disk)
>  {
>   struct backing_dev_info *bdi;
>   dev_t devt;
> @@ -597,10 +598,8 @@ void add_disk(struct gendisk *disk)
>   disk->flags |= GENHD_FL_UP;
>  
>   retval = blk_alloc_devt(&disk->part0, &devt);
> - if (retval) {
> - WARN_ON(1);
> - return;
> - }
> + if (retval)
> + return retval;
>   disk_to_dev(disk)->devt = devt;
>  
>   /* ->major and ->first_minor aren't supposed to be
> @@ -617,7 +616,7 @@ void add_disk(struct gendisk *disk)
>  
>   blk_register_region(disk_devt(disk), disk->minors, NULL,
>   exact_match, exact_lock, disk);
> - register_disk(disk);
> + register_disk(parent, disk);
>   blk_register_queue(disk);
>  
>   /*
> @@ -628,12 +627,11 @@ void add_disk(struct gendisk *disk)
>  
>   retval = sysfs_create_link(&disk_to_dev(disk)->kobj, &bdi->dev->kobj,
>  "bdi");
> - WARN_ON(retval);
> -
>   disk_add_events(disk);
>   blk_integrity_add(disk);
> + return retval;

How are the callers expected to unwind after already having added the
disk?

Re: [patch net 1/2] net: hns: fix return value of the function about rss

[Andy Shevchenko]

On Thu, 2016-03-10 at 10:16 +0800, Kejian Yan wrote:
> Both .get_rxfh and .get_rxfh are always return 0, it should return
> result
> from hardware when getting or setting rss. And the rss function
> should
> return the correct data type.
> 

@@ -1213,7 +1213,7 @@ hns_get_rss(struct net_device *netdev, u32
> *indir, u8 *key, u8 *hfunc)
>  
> 

>   ret = ops->get_rss(priv->ae_handle, indir, key, hfunc);
>  
> - return 0;
> + return ret;

All three can be one line.

> @@ -1241,7 +1241,7 @@ hns_set_rss(struct net_device *netdev, const
> u32 *indir, const u8 *key,
>  
>   ret = ops->set_rss(priv->ae_handle, indir, key, hfunc);
>  
> - return 0;
> + return ret;

Ditto.

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH 1/5] doc/memory-barriers: fix missed renaming: s/lock/acquire

[David Howells]

SeongJae Park  wrote:

> - - Locking functions.
> + - Acquiring functions.

Actually, this should be 'locking' functions.  If you look at the text:

ACQUIRING FUNCTIONS
---

The Linux kernel has a number of locking constructs:

 (*) spin locks
 (*) R/W spin locks
 (*) mutexes
 (*) semaphores
 (*) R/W semaphores

It's specifically talking about locking functions that the kernel provides -
or are we calling the spin acquires and R/W spin acquires now?  "Locking" is
the key that people referring to the document are going to use.

David

Re: [PATCH 4/5] doc/memory-barriers: Insert white spaces consistently

[David Howells]

SeongJae Park  wrote:

> The document uses two newlines between sections, one newline between
> item and its detailed description, and two spaces between sentences.
> However, there is few point that missed the rule.  This commit fix them
> to use the rule consistently.
> 
> Signed-off-by: SeongJae Park 

Excellent, thanks!  It's something I've been meaning to do for a while.

Acked-by: David Howells 

Re: [PATCH 3/5] doc/memory-barriers: fix typo

[David Howells]

SeongJae Park  wrote:

> Signed-off-by: SeongJae Park 

Acked-by: David Howells 

Re: [PATCH 2/5] doc/memory-barriers: add missed subsection in TOC

[David Howells]

SeongJae Park  wrote:

> Virtual Machine Guests subsection has added with commit
> 6a65d26385bf487926a0616650927303058551e3 ("asm-generic: implement
> virt_xxx memory barriers") in memory-barriers.txt but it forgot to add
> the subsection in 'table of contents'.  This commit adds the subsection
> in the 'table of contents'.
> 
> Signed-off-by: SeongJae Park 

Acked-by: David Howells 

RE: [PATCH v2 1/2] usb:dwc3: Enable support for 64-bit system

[Felipe Balbi]

Hi,

"Thang Q. Nguyen"  writes:
> [ text/plain ]
> Hi,
> I would like to ask if I need to update anything else for this change?

seems like I don't have original patch in my inbox. Please resend.

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH 5/5] Doc/memory-barriers: add Korean translation

[David Howells]

SeongJae Park  wrote:

> This commit adds Korean version of memory-barriers.txt document.  The
> header is refered to HOWTO Korean version.
> 
> Signed-off-by: SeongJae Park 

Nice.  I just wish I could read it:-)

For what it's worth:

Acked-by: David Howells 

[PATCH 2/2] Staging: dgap: modified the block comments

[Tanvi Surana]

I have modified the file dgap.c ,making changes to the multiline comments,thus 
making them appear presentable

Signed-Off-By: Tanvi Surana 
---
 drivers/staging/dgap/dgap.c | 59 +
 1 file changed, 33 insertions(+), 26 deletions(-)

diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
index bad3551..deff2c4 100644
--- a/drivers/staging/dgap/dgap.c
+++ b/drivers/staging/dgap/dgap.c
@@ -91,22 +91,22 @@ static uint dgap_poll_stop; /* Used to tell poller 
to stop */
 static struct timer_list dgap_poll_timer;
 
 /*
- SUPPORTED PRODUCTS
-
- Card Model   Number of Ports  Interface
- 
- Acceleport Xem   4 - 64  (EIA232 & EIA422)
- Acceleport Xr4 & 8   (EIA232)
- Acceleport Xr 9204 & 8   (EIA232)
- Acceleport C/X   8 - 128 (EIA232)
- Acceleport EPC/X 8 - 224 (EIA232)
- Acceleport Xr/4224 & 8   (EIA422)
- Acceleport 2r/9202   (EIA232)
- Acceleport 4r/9204   (EIA232)
- Acceleport 8r/9208   (EIA232)
-
- IBM 8-Port Asynchronous PCI Adapter  (EIA232)
- IBM 128-Port Asynchronous PCI Adapter(EIA232 & EIA422)
+   SUPPORTED PRODUCTS
+
+   Card Model   Number of Ports  Interface
+   
+   Acceleport Xem   4 - 64  (EIA232 & EIA422)
+   Acceleport Xr4 & 8   (EIA232)
+   Acceleport Xr 9204 & 8   (EIA232)
+   Acceleport C/X   8 - 128 (EIA232)
+   Acceleport EPC/X 8 - 224 (EIA232)
+   Acceleport Xr/4224 & 8   (EIA422)
+   Acceleport 2r/9202   (EIA232)
+   Acceleport 4r/9204   (EIA232)
+   Acceleport 8r/9208   (EIA232)
+
+   IBM 8-Port Asynchronous PCI Adapter  (EIA232)
+   IBM 128-Port Asynchronous PCI Adapter(EIA232 & EIA422)
 */
 
 static struct pci_device_id dgap_pci_tbl[] = {
@@ -1465,7 +1465,8 @@ static void dgap_parity_scan(struct channel_t *ch, 
unsigned char *cbuf,
  *
  *  ch  - Pointer to channel structure.
  *
- *===*/
+ *===
+ */
 
 static void dgap_input(struct channel_t *ch)
 {
@@ -1694,7 +1695,8 @@ static void dgap_write_wakeup(struct board_t *bd, struct 
channel_t *ch,
 /
  * Determines when CARRIER changes state and takes appropriate
  * action.
- /
+ ***
+ */
 static void dgap_carrier(struct channel_t *ch)
 {
struct board_t *bd;
@@ -2339,7 +2341,8 @@ schedule_poller:
  *  ncmds   - Wait until ncmds or fewer cmds are left
  *in the cmd buffer before returning.
  *
- *===*/
+ *===
+ */
 static void dgap_cmdb(struct channel_t *ch, u8 cmd, u8 byte1,
  u8 byte2, uint ncmds)
 {
@@ -2424,7 +2427,8 @@ static void dgap_cmdb(struct channel_t *ch, u8 cmd, u8 
byte1,
  *  ncmds   - Wait until ncmds or fewer cmds are left
  *in the cmd buffer before returning.
  *
- *===*/
+ *===
+ */
 static void dgap_cmdw(struct channel_t *ch, u8 cmd, u16 word, uint ncmds)
 {
char __iomem *vaddr;
@@ -2506,7 +2510,8 @@ static void dgap_cmdw(struct channel_t *ch, u8 cmd, u16 
word, uint ncmds)
  *  ncmds   - Wait until ncmds or fewer cmds are left
  *in the cmd buffer before returning.
  *
- *===*/
+ *===
+ */
 static void dgap_cmdw_ext(struct channel_t *ch, u16 cmd, u16 word, uint ncmds)
 {
char __iomem *vaddr;
@@ -2598,7 +2603,8 @@ static void dgap_cmdw_ext(struct channel_t *ch, u16 cmd, 
u16 word, uint ncmds)
  *  buf - Pointer to characters to be moved.
  *  cnt - Number of characters to move.
  *
- *===*/
+ *===
+ */
 static void dgap_wmove(struct channel_t *ch, char *bu

Re: [patch net 2/2] net: hns: fixes a bug of RSS

[Andy Shevchenko]

On Thu, 2016-03-10 at 10:16 +0800, Kejian Yan wrote:
> If trying to get receive flow hash indirection table by ethtool, it
> needs
> to call .get_rxnfc to get ring number first. So this patch implements
> the
> .get_rxnfc of ethtool. And the data type of rss_indir_table is u32,
> it has
> to be multiply by the width of data type when using memcpy.

+static int hns_get_rxnfc(struct net_device *netdev,
> +  struct ethtool_rxnfc *cmd,
> +  u32 *rule_locs)
> +{
> + struct hns_nic_priv *priv = netdev_priv(netdev);
> + int ret = 0;
> +
> + switch (cmd->cmd) {
> + case ETHTOOL_GRXRINGS:
> + cmd->data = priv->ae_handle->q_num;
> + break;
> + default:
> + ret = -EOPNOTSUPP;
> + break;
> + }
> +
> + return ret;

Redundant ret variable.

switch (value) {
case X:
 break;
default:
 return -ERRNO;
}

return 0;

> +}

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [PATCH 1/2] KVM: MMU: fix ept=0/pte.u=0/pte.w=0/CR0.WP=0/CR4.SMEP=1/EFER.NX=0 combo

[Xiao Guangrong]

On 03/08/2016 07:44 PM, Paolo Bonzini wrote:

Yes, all of these are needed. :) This is admittedly a bit odd, but
kvm-unit-tests access.flat tests this if you run it with "-cpu host"
and of course ept=0.

KVM handles supervisor writes of a pte.u=0/pte.w=0/CR0.WP=0 page by
setting U=0 and W=1 in the shadow PTE.  This will cause a user write
to fault and a supervisor write to succeed (which is correct because
CR0.WP=0).  A user read instead will flip U=0 to 1 and W=1 back to 0.
This enables user reads; it also disables supervisor writes, the next
of which will then flip the bits again.

When SMEP is in effect, however, U=0 will enable kernel execution of
this page.  To avoid this, KVM also sets NX=1 in the shadow PTE together
with U=0.  If the guest has not enabled NX, the result is a continuous
stream of page faults due to the NX bit being reserved.

The fix is to force EFER.NX=1 even if the CPU is taking care of the EFER
switch.


Good catch!

So it only hurts the box which has cpu_has_load_ia32_efer support otherwise
NX is inherited from kernel (kernel always sets NX if CPU supports it),
right?



There is another bug in the reserved bit check, which I've split to a
separate patch for easier application to stable kernels.




Cc: sta...@vger.kernel.org
Cc: Xiao Guangrong 
Cc: Andy Lutomirski 
Fixes: f6577a5fa15d82217ca73c74cd2dcbc0f6c781dd
Signed-off-by: Paolo Bonzini 
---
  Documentation/virtual/kvm/mmu.txt |  3 ++-
  arch/x86/kvm/vmx.c| 25 +++--
  2 files changed, 17 insertions(+), 11 deletions(-)

diff --git a/Documentation/virtual/kvm/mmu.txt 
b/Documentation/virtual/kvm/mmu.txt
index daf9c0f742d2..c81731096a43 100644
--- a/Documentation/virtual/kvm/mmu.txt
+++ b/Documentation/virtual/kvm/mmu.txt
@@ -358,7 +358,8 @@ In the first case there are two additional complications:
  - if CR4.SMEP is enabled: since we've turned the page into a kernel page,
the kernel may now execute it.  We handle this by also setting spte.nx.
If we get a user fetch or read fault, we'll change spte.u=1 and
-  spte.nx=gpte.nx back.
+  spte.nx=gpte.nx back.  For this to work, KVM forces EFER.NX to 1 when
+  shadow paging is in use.
  - if CR4.SMAP is disabled: since the page has been changed to a kernel
page, it can not be reused when CR4.SMAP is enabled. We set
CR4.SMAP && !CR0.WP into shadow page's role to avoid this case. Note,
diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
index 6e51493ff4f9..91830809d837 100644
--- a/arch/x86/kvm/vmx.c
+++ b/arch/x86/kvm/vmx.c
@@ -1863,20 +1863,20 @@ static bool update_transition_efer(struct vcpu_vmx 
*vmx, int efer_offset)
guest_efer = vmx->vcpu.arch.efer;

/*
-* NX is emulated; LMA and LME handled by hardware; SCE meaningless
-* outside long mode
+* LMA and LME handled by hardware; SCE meaningless outside long mode.
 */
-   ignore_bits = EFER_NX | EFER_SCE;
+   ignore_bits = EFER_SCE;
  #ifdef CONFIG_X86_64
ignore_bits |= EFER_LMA | EFER_LME;
/* SCE is meaningful only in long mode on Intel */
if (guest_efer & EFER_LMA)
ignore_bits &= ~(u64)EFER_SCE;
  #endif
-   guest_efer &= ~ignore_bits;
-   guest_efer |= host_efer & ignore_bits;
-   vmx->guest_msrs[efer_offset].data = guest_efer;
-   vmx->guest_msrs[efer_offset].mask = ~ignore_bits;
+   /* NX is needed to handle CR0.WP=1, CR4.SMEP=1.  */



+   if (!enable_ept) {
+   guest_efer |= EFER_NX;
+   ignore_bits |= EFER_NX;


Update ignore_bits is not necessary i think.


+   }

clear_atomic_switch_msr(vmx, MSR_EFER);

@@ -1887,16 +1887,21 @@ static bool update_transition_efer(struct vcpu_vmx 
*vmx, int efer_offset)
 */
if (cpu_has_load_ia32_efer ||
(enable_ept && ((vmx->vcpu.arch.efer ^ host_efer) & EFER_NX))) {
-   guest_efer = vmx->vcpu.arch.efer;
if (!(guest_efer & EFER_LMA))
guest_efer &= ~EFER_LME;
if (guest_efer != host_efer)
add_atomic_switch_msr(vmx, MSR_EFER,
  guest_efer, host_efer);


So, why not set EFER_NX (if !ept) just in this branch to make the fix more 
simpler?

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

[Jarkko Nikula]

On 03/10/2016 01:34 PM, Xiangliang Yu wrote:

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 },
{ }
--
I guess these changes don't necessarily need to go together? Although I 
think chances to get a conflict is pretty low.


For i2c-designware:
Acked-by: Jarkko Nikula 

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

[Andrzej Pietrasiewicz]

Hi Nicholas,

W dniu 10.03.2016 o 06:19, Nicholas A. Bellinger pisze:

Hi Andrzej,

On Wed, 2016-03-09 at 13:53 +0100, Andrzej Pietrasiewicz wrote:

Hi Nicholas,







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(&tpg->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);







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;





I tested it. Works for me.

AP

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

[Li, Liang Z]

> >  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

Thanks a lot !!

Liang

Re: [PATCH 2/2] KVM: MMU: fix reserved bit check for pte.u=0/pte.w=0/CR0.WP=0/CR4.SMEP=1/EFER.NX=0

[Xiao Guangrong]

On 03/08/2016 07:44 PM, Paolo Bonzini wrote:

KVM handles supervisor writes of a pte.u=0/pte.w=0/CR0.WP=0 page by
setting U=0 and W=1 in the shadow PTE.  This will cause a user write
to fault and a supervisor write to succeed (which is correct because
CR0.WP=0).  A user read instead will flip U=0 to 1 and W=1 back to 0.
This enables user reads; it also disables supervisor writes, the next
of which will then flip the bits again.

When SMEP is in effect, however, pte.u=0 will enable kernel execution
of this page.  To avoid this, KVM also sets pte.nx=1.  The reserved bit
catches this because it only looks at the guest's EFER.NX bit.  Teach it
that smep_andnot_wp will also use the NX bit of SPTEs.

Cc: sta...@vger.kernel.org
Cc: Xiao Guangrong 


As a redhat guy i am so proud. :)


Fixes: c258b62b264fdc469b6d3610a907708068145e3b


Thanks for you fixing it, Paolo!

Reviewed-by: Xiao Guangrong 


Signed-off-by: Paolo Bonzini 
---
  arch/x86/kvm/mmu.c | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 95a955de5964..0cd4ee01de94 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -3721,13 +3721,15 @@ static void reset_rsvds_bits_mask_ept(struct kvm_vcpu 
*vcpu,
  void
  reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu *context)
  {
+   int uses_nx = context->nx || context->base_role.smep_andnot_wp;


It would be better if it is 'bool'

Re: [PATCH v2 0/5] introduce kcompactd and stop compacting in kswapd

[Vlastimil Babka]

On 03/09/2016 04:52 PM, Michal Hocko wrote:

On Mon 08-02-16 14:38:06, Vlastimil Babka wrote:

The previous RFC is here [1]. It didn't have a cover letter, so the description
and results are in the individual patches.


FWIW I think this is a step in the right direction. I would give my


Thanks!


Acked-by to all patches but I wasn't able to find time for a deep review
and my lack of knowledge of compaction details doesn't help much. I do
agree that conflating kswapd with compaction didn't really work out well
and fixing this would just make the code more complex and would more
prone to new bugs.


Yeah, it seems that direct reclaim/compaction is complex enough already...


In future we might want to invent something similar
to watermarks and set an expected level of high order pages prepared for
the allocation (e.g. have at least XMB of memory in order-9+). kcompact
then could try as hard as possible to provide them. Does that sound at
least doable?


Sure, that was/is part of the plan. But I was trimming the series for 
initial merge over the past year to arrive at a starting point where 
reaching consensus is easier.



Thanks!

[GIT PULL] s390 patches for 4.5-rc7

[Martin Schwidefsky]

Hi Linus,

please pull from the 'for-linus' branch of

git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git for-linus

to receive the following updates:

Three bug fixes:
 - The fix for the page table corruption (CVE-2016-2143)
 - The diagnose statistics introduced a regression for the dasd diag driver
 - Boot crash on systems without the set-program-parameters facility

Christian Borntraeger (1):
  s390/cpumf: Fix lpp detection

Heiko Carstens (1):
  s390/dasd: fix diag 0x250 inline assembly

Martin Schwidefsky (1):
  s390/mm: four page table levels vs. fork

 arch/s390/include/asm/mmu_context.h | 16 +++-
 arch/s390/include/asm/pgalloc.h | 24 +++-
 arch/s390/kernel/head64.S   |  2 +-
 drivers/s390/block/dasd_diag.c  |  9 +++--
 4 files changed, 38 insertions(+), 13 deletions(-)

diff --git a/arch/s390/include/asm/mmu_context.h 
b/arch/s390/include/asm/mmu_context.h
index fb1b93e..e485817 100644
--- a/arch/s390/include/asm/mmu_context.h
+++ b/arch/s390/include/asm/mmu_context.h
@@ -15,17 +15,25 @@
 static inline int init_new_context(struct task_struct *tsk,
   struct mm_struct *mm)
 {
+   spin_lock_init(&mm->context.list_lock);
+   INIT_LIST_HEAD(&mm->context.pgtable_list);
+   INIT_LIST_HEAD(&mm->context.gmap_list);
cpumask_clear(&mm->context.cpu_attach_mask);
atomic_set(&mm->context.attach_count, 0);
mm->context.flush_mm = 0;
-   mm->context.asce_bits = _ASCE_TABLE_LENGTH | _ASCE_USER_BITS;
-   mm->context.asce_bits |= _ASCE_TYPE_REGION3;
 #ifdef CONFIG_PGSTE
mm->context.alloc_pgste = page_table_allocate_pgste;
mm->context.has_pgste = 0;
mm->context.use_skey = 0;
 #endif
-   mm->context.asce_limit = STACK_TOP_MAX;
+   if (mm->context.asce_limit == 0) {
+   /* context created by exec, set asce limit to 4TB */
+   mm->context.asce_bits = _ASCE_TABLE_LENGTH |
+   _ASCE_USER_BITS | _ASCE_TYPE_REGION3;
+   mm->context.asce_limit = STACK_TOP_MAX;
+   } else if (mm->context.asce_limit == (1UL << 31)) {
+   mm_inc_nr_pmds(mm);
+   }
crst_table_init((unsigned long *) mm->pgd, pgd_entry_type(mm));
return 0;
 }
@@ -111,8 +119,6 @@ static inline void activate_mm(struct mm_struct *prev,
 static inline void arch_dup_mmap(struct mm_struct *oldmm,
 struct mm_struct *mm)
 {
-   if (oldmm->context.asce_limit < mm->context.asce_limit)
-   crst_table_downgrade(mm, oldmm->context.asce_limit);
 }
 
 static inline void arch_exit_mmap(struct mm_struct *mm)
diff --git a/arch/s390/include/asm/pgalloc.h b/arch/s390/include/asm/pgalloc.h
index 7b7858f..d7cc79f 100644
--- a/arch/s390/include/asm/pgalloc.h
+++ b/arch/s390/include/asm/pgalloc.h
@@ -100,12 +100,26 @@ static inline void pud_populate(struct mm_struct *mm, 
pud_t *pud, pmd_t *pmd)
 
 static inline pgd_t *pgd_alloc(struct mm_struct *mm)
 {
-   spin_lock_init(&mm->context.list_lock);
-   INIT_LIST_HEAD(&mm->context.pgtable_list);
-   INIT_LIST_HEAD(&mm->context.gmap_list);
-   return (pgd_t *) crst_table_alloc(mm);
+   unsigned long *table = crst_table_alloc(mm);
+
+   if (!table)
+   return NULL;
+   if (mm->context.asce_limit == (1UL << 31)) {
+   /* Forking a compat process with 2 page table levels */
+   if (!pgtable_pmd_page_ctor(virt_to_page(table))) {
+   crst_table_free(mm, table);
+   return NULL;
+   }
+   }
+   return (pgd_t *) table;
+}
+
+static inline void pgd_free(struct mm_struct *mm, pgd_t *pgd)
+{
+   if (mm->context.asce_limit == (1UL << 31))
+   pgtable_pmd_page_dtor(virt_to_page(pgd));
+   crst_table_free(mm, (unsigned long *) pgd);
 }
-#define pgd_free(mm, pgd) crst_table_free(mm, (unsigned long *) pgd)
 
 static inline void pmd_populate(struct mm_struct *mm,
pmd_t *pmd, pgtable_t pte)
diff --git a/arch/s390/kernel/head64.S b/arch/s390/kernel/head64.S
index c5febe8..03c2b46 100644
--- a/arch/s390/kernel/head64.S
+++ b/arch/s390/kernel/head64.S
@@ -16,7 +16,7 @@
 
 __HEAD
 ENTRY(startup_continue)
-   tm  __LC_STFLE_FAC_LIST+6,0x80  # LPP available ?
+   tm  __LC_STFLE_FAC_LIST+5,0x80  # LPP available ?
jz  0f
xc  __LC_LPP+1(7,0),__LC_LPP+1  # clear lpp and current_pid
mvi __LC_LPP,0x80   #   and set LPP_MAGIC
diff --git a/drivers/s390/block/dasd_diag.c b/drivers/s390/block/dasd_diag.c
index cb61f30..277b5c8 100644
--- a/drivers/s390/block/dasd_diag.c
+++ b/drivers/s390/block/dasd_diag.c
@@ -67,7 +67,7 @@ static const u8 DASD_DIAG_CMS1[] = { 0xc3, 0xd4, 0xe2, 0xf1 
};/* EBCDIC CMS1 */
  * and function code cmd.
  * In case of an exception return 3. Otherwise return result of bitwis

Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data

[Peter Zijlstra]

On Thu, Mar 10, 2016 at 12:28:52AM +0100, Rafael J. Wysocki wrote:
> > [ I would not have chosen (1 + 1/n), but lets stick to that ]
> 
> Well, what would you choose then? :-)

1/p ; 0 < p < 1

or so. Where p then represents the percentile threshold where you want
to bump to the next freq.

> I think that should be
> 
>   next_freq = (1 + 1/n) * max_freq * util / max
> 
> (where max is the second argument of cpufreq_update_util) or the
> dimensions on both sides don't match.

Well yes, but so far we were treating util (and util_raw) as 0 < u < 1,
values, so already normalized against max.

But yes..

> > if we substitute (2) into (3) we get:
> >
> >   = (1 + 1/n) * max_freq * util_raw * current_freq / 
> > max_freq
> >   = (1 + 1/n) * current_freq * util_raw (4)
> >
> > Which gets you two formula with the same general behaviour. As (2) is
> > the only approximation of (1) we can make.
> 
> OK
> 
> So since utilization is not frequency invariant in the current
> mainline (or linux-next for that matter) AFAIC, I'm going to use the
> following in the next version of the schedutil patch series:
> 
>   next_freq = 1.25 * current_freq * util_raw / max
> 
> where util_raw and max are what I get from cpufreq_update_util().
> 
> 1.25 is for the 80% tipping point which I think is reasonable.

OK.

Re: [PATCH 12/13] thermal: convert tegra_thermal to use devm_thermal_zone_of_sensor_register

[Wei Ni]

On 2016年03月10日 05:35, Eduardo Valentin wrote:
> This changes the driver to use the devm_ version
> of thermal_zone_of_sensor_register and cleans
> up the  local points and unregister calls.
> 
> Cc: Zhang Rui 
> Cc: Stephen Warren 
> Cc: Thierry Reding 
> Cc: Alexandre Courbot 
> Cc: linux...@vger.kernel.org
> Cc: linux-te...@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin 
> ---
>  drivers/thermal/tegra_soctherm.c | 31 +--
>  1 file changed, 9 insertions(+), 22 deletions(-)
> 
> diff --git a/drivers/thermal/tegra_soctherm.c 
> b/drivers/thermal/tegra_soctherm.c
> index 74ea576..0018ccd 100644
> --- a/drivers/thermal/tegra_soctherm.c
> +++ b/drivers/thermal/tegra_soctherm.c
> @@ -168,7 +168,7 @@ struct tegra_soctherm {
>   struct clk *clock_soctherm;
>   void __iomem *regs;
>  
> - struct thermal_zone_device *thermctl_tzs[4];
> +#define ZONE_NUMBER  4
>  };
>  
>  struct tsensor_shared_calibration {
> @@ -342,7 +342,7 @@ static const struct thermctl_zone_desc 
> t124_thermctl_temp_zones[] = {
>  static int tegra_soctherm_probe(struct platform_device *pdev)
>  {
>   struct tegra_soctherm *tegra;
> - struct thermal_zone_device *tz;
> + struct thermal_zone_device *z;
>   struct tsensor_shared_calibration shared_calib;
>   struct resource *res;
>   unsigned int i;
> @@ -408,36 +408,29 @@ static int tegra_soctherm_probe(struct platform_device 
> *pdev)
>  
>   /* Initialize thermctl sensors */
>  
> - for (i = 0; i < ARRAY_SIZE(tegra->thermctl_tzs); ++i) {
> + for (i = 0; i < ZONE_NUMBER; ++i) {
>   struct tegra_thermctl_zone *zone =
>   devm_kzalloc(&pdev->dev, sizeof(*zone), GFP_KERNEL);
>   if (!zone) {
>   err = -ENOMEM;
> - goto unregister_tzs;
> + goto disable_clocks;
>   }
>  
>   zone->reg = tegra->regs + t124_thermctl_temp_zones[i].offset;
>   zone->shift = t124_thermctl_temp_zones[i].shift;
>  
> - tz = thermal_zone_of_sensor_register(&pdev->dev, i, zone,
> -  &tegra_of_thermal_ops);
> - if (IS_ERR(tz)) {
> - err = PTR_ERR(tz);
> + z = devm_thermal_zone_of_sensor_register(&pdev->dev, i, zone,

I prefer to still use "tz", it seems this line isn't over 80 characters, or we
can add newline.

> +  &tegra_of_thermal_ops);
> + if (IS_ERR(z)) {
> + err = PTR_ERR(z);
>   dev_err(&pdev->dev, "failed to register sensor: %d\n",
>   err);
> - goto unregister_tzs;
> + goto disable_clocks;
>   }
> -
> - tegra->thermctl_tzs[i] = tz;
>   }
>  
>   return 0;
>  
> -unregister_tzs:
> - while (i--)
> - thermal_zone_of_sensor_unregister(&pdev->dev,
> -   tegra->thermctl_tzs[i]);
> -
>  disable_clocks:
>   clk_disable_unprepare(tegra->clock_tsensor);
>   clk_disable_unprepare(tegra->clock_soctherm);
> @@ -448,12 +441,6 @@ disable_clocks:
>  static int tegra_soctherm_remove(struct platform_device *pdev)
>  {
>   struct tegra_soctherm *tegra = platform_get_drvdata(pdev);
> - unsigned int i;
> -
> - for (i = 0; i < ARRAY_SIZE(tegra->thermctl_tzs); ++i) {
> - thermal_zone_of_sensor_unregister(&pdev->dev,
> -   tegra->thermctl_tzs[i]);
> - }
>  
>   clk_disable_unprepare(tegra->clock_tsensor);
>   clk_disable_unprepare(tegra->clock_soctherm);
> 

Re: [PATCH 1/2] KVM: MMU: fix ept=0/pte.u=0/pte.w=0/CR0.WP=0/CR4.SMEP=1/EFER.NX=0 combo

[Xiao Guangrong]

On 03/08/2016 07:44 PM, Paolo Bonzini wrote:

Yes, all of these are needed. :) This is admittedly a bit odd, but
kvm-unit-tests access.flat tests this if you run it with "-cpu host"
and of course ept=0.

KVM handles supervisor writes of a pte.u=0/pte.w=0/CR0.WP=0 page by
setting U=0 and W=1 in the shadow PTE.  This will cause a user write
to fault and a supervisor write to succeed (which is correct because
CR0.WP=0).  A user read instead will flip U=0 to 1 and W=1 back to 0.


BTW, it should be pte.u = 1 where you mentioned above.

RE: [PATCH v2 1/2] usb:dwc3: Enable support for 64-bit system

[Thang Q. Nguyen]

Thanks Felipe for your feedback.
I will re-generate patches and resend.

Regards,
Thang Q. Nguyen -
-Original Message-
From: Felipe Balbi [mailto:felipe.ba...@linux.intel.com]
Sent: Thursday, March 10, 2016 3:15 PM
To: Thang Q. Nguyen; Thang Q. Nguyen; Felipe Balbi; Greg Kroah-Hartman;
linux-...@vger.kernel.org; linux-o...@vger.kernel.org;
linux-kernel@vger.kernel.org; linux-...@lists.infradead.org
Cc: Phong Vo; Loc Ho; patches
Subject: RE: [PATCH v2 1/2] usb:dwc3: Enable support for 64-bit system


Hi,

"Thang Q. Nguyen"  writes:
> [ text/plain ]
> Hi,
> I would like to ask if I need to update anything else for this change?

seems like I don't have original patch in my inbox. Please resend.

-- 
balbi

[PATCH] rcu: Remove some superfluous lines

[Peter Zijlstra]

I think you'll find this condition is superfluous, as the whole function
is under #ifdef of that same.

Signed-off-by: Peter Zijlstra (Intel) 
---
 kernel/rcu/tree.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c
index 4f7369d54de0..dd2646e56456 100644
--- a/kernel/rcu/tree.c
+++ b/kernel/rcu/tree.c
@@ -4237,9 +4237,6 @@ static void rcu_cleanup_dying_idle_cpu(int cpu, struct 
rcu_state *rsp)
struct rcu_data *rdp = per_cpu_ptr(rsp->rda, cpu);
struct rcu_node *rnp = rdp->mynode;  /* Outgoing CPU's rdp & rnp. */
 
-   if (!IS_ENABLED(CONFIG_HOTPLUG_CPU))
-   return;
-
/* Remove outgoing CPU from mask in the leaf rcu_node structure. */
mask = rdp->grpmask;
raw_spin_lock_irqsave_rcu_node(rnp, flags); /* Enforce GP memory-order 
guarantee. */

Re: [PATCH 1/5] doc/memory-barriers: fix missed renaming: s/lock/acquire

[SeongJae Park]

On Thu, 10 Mar 2016, David Howells wrote:


SeongJae Park  wrote:


- - Locking functions.
+ - Acquiring functions.


Actually, this should be 'locking' functions.  If you look at the text:

ACQUIRING FUNCTIONS
---

The Linux kernel has a number of locking constructs:

 (*) spin locks
 (*) R/W spin locks
 (*) mutexes
 (*) semaphores
 (*) R/W semaphores

It's specifically talking about locking functions that the kernel provides -
or are we calling the spin acquires and R/W spin acquires now?  "Locking" is
the key that people referring to the document are going to use.


AFAIU, the next line of the quoted text says the section is talking about
variants on "ACQUIRE" operations and "RELEASE" operations for each locking
constructs.  I thought the original change which changed the name of
section has made full consensus and I am just want to make the section
names in `Contents` section and its real section name.  I will listen to
other's opinions more.


Thanks,
SeongJae Park



David

Re: [PATCH v2] MAINTAINERS: add a maintainer for the NAND subsystem

[Artem Bityutskiy]

On Wed, 2016-03-09 at 13:48 -0800, Brian Norris wrote:
> On Wed, Mar 09, 2016 at 09:57:24PM +0100, Boris Brezillon wrote:
> > 
> > Add myself as the maintainer of the NAND subsystem.
> > 
> > Signed-off-by: Boris Brezillon 
> > ---
> > Changes since v1:
> > - rename the MAINTAINERS entry to NAND FLASH SUBSYSTEM
> > - add Richard as a reviewer
> > - add a git tree
> Acked-by: Brian Norris 

Acked-by: Artem Bityutskiy 

[PATCH V3] PM / clk: Add support for obtaining clocks from device-tree

[Jon Hunter]

The PM clocks framework requires clients to pass either a con-id or a
valid clk pointer in order to add a clock to a device. Add a new
function of_pm_clk_add_clks() to allows device clocks to be retrieved
from device-tree and populated for a given device. Note that
of_clk_get_from_provider() is not defined if CONFIG_OF and
CONFIG_COMMON_CLK are not selected. Therefore, make of_pm_clk_add_clks()
dependent on these options.

An optional function pointer may be passed to of_pm_clk_add_clks() that
can be used to filter the clocks that are added for a device when
calling of_pm_clk_add_clks().

In order to handle errors encountered when adding clocks from
device-tree, add a function pm_clk_remove_clk() to remove any clocks
(using a pointer to the clk structure) that have been added
successfully before the error occurred.

Signed-off-by: Jon Hunter 
---

Changes v2-v3:
- Constified the of_phandle_args parameter
- Added data parameter to filter function

Changes v1-v2:
- Added support for optional filter function as suggested by Geert U.

 drivers/base/power/clock_ops.c | 108 +
 include/linux/pm_clock.h   |  19 
 2 files changed, 127 insertions(+)

diff --git a/drivers/base/power/clock_ops.c b/drivers/base/power/clock_ops.c
index 272a52ebafc0..d912944a1a9e 100644
--- a/drivers/base/power/clock_ops.c
+++ b/drivers/base/power/clock_ops.c
@@ -137,6 +137,81 @@ int pm_clk_add_clk(struct device *dev, struct clk *clk)
return __pm_clk_add(dev, NULL, clk);
 }
 
+
+#if defined(CONFIG_OF) && defined(CONFIG_COMMON_CLK)
+/**
+ * of_pm_clk_add_clks - Start using device clock(s) for power management.
+ * @dev: Device whose clock(s) is going to be used for power management.
+ * @of_pm_clk_filter: Optional function for filtering clocks
+ *
+ * Add a series of clocks described in the 'clocks' device-tree node for
+ * a device to the list of clocks used for the power management of @dev.
+ * If 'of_pm_clk_filter' is specified, then this filter function will be
+ * called for each clock found and the clock will be added to the list
+ * of clocks if this function returns true. Return success if clocks are
+ * added successfully and return a negative error code if adding a clock
+ * fails or there are no clocks that match with the filter function.
+ */
+int of_pm_clk_add_clks(struct device *dev, of_pm_clk_filter fn, void *data)
+{
+   struct of_phandle_args clkspec;
+   struct clk **clks;
+   unsigned int i, count, added = 0;
+   int ret;
+
+   if (!dev || !dev->of_node)
+   return -EINVAL;
+
+   count = of_count_phandle_with_args(dev->of_node, "clocks",
+  "#clock-cells");
+   if (count == 0)
+   return -ENODEV;
+
+   clks = kcalloc(count, sizeof(*clks), GFP_KERNEL);
+   if (!clks)
+   return -ENOMEM;
+
+   for (i = 0; i < count; i++) {
+   if (of_parse_phandle_with_args(dev->of_node, "clocks",
+  "#clock-cells", i, &clkspec))
+   goto error;
+
+   if (fn && !fn(&clkspec, data)) {
+   of_node_put(clkspec.np);
+   continue;
+   }
+
+   clks[added] = of_clk_get_from_provider(&clkspec);
+   of_node_put(clkspec.np);
+
+   if (IS_ERR(clks[added])) {
+   ret = PTR_ERR(clks[added]);
+   goto error;
+   }
+
+   ret = pm_clk_add_clk(dev, clks[added]);
+   if (ret) {
+   clk_put(clks[added]);
+   goto error;
+   }
+
+   added++;
+   }
+
+   kfree(clks);
+
+   return added ? 0 : -ENODEV;
+
+error:
+   while (added--)
+   pm_clk_remove_clk(dev, clks[added]);
+
+   kfree(clks);
+
+   return ret;
+}
+#endif /* CONFIG_OF && CONFIG_COMMON_CLK */
+
 /**
  * __pm_clk_remove - Destroy PM clock entry.
  * @ce: PM clock entry to destroy.
@@ -198,6 +273,39 @@ void pm_clk_remove(struct device *dev, const char *con_id)
 }
 
 /**
+ * pm_clk_remove_clk - Stop using a device clock for power management.
+ * @dev: Device whose clock should not be used for PM any more.
+ * @clk: Clock pointer
+ *
+ * Remove the clock pointed to by @clk from the list of clocks used for
+ * the power management of @dev.
+ */
+void pm_clk_remove_clk(struct device *dev, struct clk *clk)
+{
+   struct pm_subsys_data *psd = dev_to_psd(dev);
+   struct pm_clock_entry *ce;
+
+   if (!psd || !clk)
+   return;
+
+   spin_lock_irq(&psd->lock);
+
+   list_for_each_entry(ce, &psd->clock_list, node) {
+   if (clk == ce->clk)
+   goto remove;
+   }
+
+   spin_unlock_irq(&psd->lock);
+   return;
+
+ remove:
+   list_del(&ce->node);
+   spin_unlock_irq(&psd->lock);
+
+   __pm_clk_remove(ce);
+}

Re: [PATCH 1/2] spi: sun4i: add DMA support

[Michal Suchanek]

Hello,

On 6 March 2016 at 22:42, Maxime Ripard
 wrote:
> On Fri, Feb 26, 2016 at 01:51:51PM +0100, Michal Suchanek wrote:

>> Besides this non-technical objection there were multiple technical
>> objections.
>>
>> IIRC one was that the driver does not handle the case when the DMA
>> channels are not available. As I understand it the channels are
>> exclusively reserved for a particular peripherial on sunxi platform so
>> this ShoulNotHappen(tm). So it's probably fine for the driver to fail
>> probe  when you have broken DT or no DMA engine support for sunxi
>> platform.
>
> There's a quite trivial scenario that would trigger this: if the dma
> driver or dmaengine is not enabled / loaded.

There are other trivial scenarios under which the driver will fail
like loading wrong DT, not compiling or loading the sunxi pinmux
driver, and whatnot.

When you misconfigure your kernel it does not work. So long as the
driver just fails and does not crash and burn it's normal. Since the
driver is pretty much useless without DMA as it is now (63 byte
transfer limit) losing the non-DMA functionality when DMA engine is
not compiled-in does not seem that terrible.

Thanks

Michal

Re: [PATCH 1/4] nvdimm/blk: don't allocate unused major device number

[Johannes Thumshirn]

On Thu, Mar 10, 2016 at 08:59:28AM +1100, NeilBrown wrote:
> When alloc_disk(0) is used ->major is completely ignored, all devices
> are allocated with a "major" of BLOCK_EXT_MAJOR.
> 
> So don't allocate nd_blk_major
> 
> Signed-off-by: NeilBrown 

Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

Re: [PATCH 2/4] nvdimm/btt: don't allocate unused major device number

[Johannes Thumshirn]

On Thu, Mar 10, 2016 at 08:59:28AM +1100, NeilBrown wrote:
> alloc_disk(0) does not require or use a ->major number,
> all devices are allocated with a major of BLOCK_EXT_MAJOR.
> 
> So don't allocate btt_major.
> 
> Signed-off-by: NeilBrown 

Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

Re: [PATCH] HID: i2c-hid: Add hid-over-i2c name to i2c id table

[Jiri Kosina]

On Wed, 9 Mar 2016, Dmitry Torokhov wrote:

> >> When using the device tree binding OF compatible = "hid-over-i2c" the
> >> i2c id table also needs to have that name in order to auto load this
> >> driver, since i2c core reports module alias as i2c: where
> >>  is compatible string of OF binding stripped of manufacturer's
> >> prefix.
> >>
> >> Signed-off-by: Benson Leung 
> >> Signed-off-by: Dmitry Torokhov 
> >
> > Applied, thanks.
> 
> Crap, can you change author on this to "Benson Leung
> " and on "HID: i2c-hid: Fix suspend/resume when
> already runtime suspended" to "Doug Anderson "?
> 
> I need to fix my script...

Alright, this is one of the rare ocasions where I believe that rebase of a 
public git tree is justifiable. I've just fixed the commits and pushed out 
the new branches.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH 3/4] memstick: don't allocate unused major for ms_block

[Johannes Thumshirn]

On Thu, Mar 10, 2016 at 08:59:28AM +1100, NeilBrown wrote:
> When alloc_disk(0) is used the ->major number is completely ignored.
> All devices are allocated with a major of BLOCK_EXT_MAJOR.
> 
> So remove registration and deregistration of 'major'.
> 
> Signed-off-by: NeilBrown 

Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

Re: [PATCH 4/4] NVMe: don't allocate unused nvme_major

[Johannes Thumshirn]

On Thu, Mar 10, 2016 at 08:59:28AM +1100, NeilBrown wrote:
> When alloc_disk(0) is used, the ->major number is ignored.  All device
> numbers are allocated with a major of BLOCK_EXT_MAJOR.
> 
> So remove all references to nvme_major.
> 
> Signed-off-by: NeilBrown 

Reviewed-by: Johannes Thumshirn 

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

Re: [PATCH] livepatch: Add some basic LivePatch documentation

[Jiri Kosina]

On Wed, 9 Mar 2016, Petr Mladek wrote:

> LivePatch framework deserves some documentation, definitely.
> This is an attempt to provide some basic info. I hope that
> it will be useful for both LivePatch producers and also
> potential developers of the framework itself.

Thanks for starting the efforts; this is really needed if we want the 
infrastructure to be used also by someone else than its developers :)

[ ... snip ... ]
> +7. Limitations
> +==

Miroslav Benes, who is working on creating the actual patches we are 
shipping for our kernels, should already have a decent cheat-sheet 
regarding things that the patch author should be extra careful when 
creating a patch (inlining and other gcc optimizations such as isra, 
functions that use switch_to(), percpu, ...).

I am not really sure whether these should go to limitations, or maybe 
they'd better be placed into a separate chapter, but I'd really like to 
see it included.

Thanks,

-- 
Jiri Kosina
SUSE Labs

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

[Peter Zijlstra]

On Thu, Mar 10, 2016 at 11:21:21AM +0530, Vineet Gupta wrote:
> 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 the thing is, __bit_spin_unlock() is not safe if other bits in that
word can have concurrent modifications.

Only if the bitlock locks the whole word (or something else ensures no
other bits will change) can you use __bit_spin_unlock() to clear the
lock bit.

Re: [PATCH] bpf: make bpf_stackmap_copy conditionally called

[Arnd Bergmann]

On Thursday 10 March 2016, Alexei Starovoitov wrote:
> yes. this is also ok-ish fix.
> I've sent different version already:
> http://patchwork.ozlabs.org/patch/595617/
> 
> I considered the option like yours but it's relying on gcc doing
> dead code elimination of 'if (false) {}' branch and though kernel
> is never compiled with -O0. I didn't want to take the risk.
> I'm fine with either approach though.

Ok, and I see yours is already applied, so that's fine.

In general, I don't like __weak symbols in the kernel as they
make it less clear what is actually getting called, and I think my
version would have been safe, we rely on building with -O2 or -Os
in a lot of places because of similar things.

Arnd

Re: [PATCH v3 0/8] arm64: rockchip: Initial GeekBox enablement

[Giuseppe CAVALLARO]

On 3/9/2016 5:31 PM, Dinh Nguyen wrote:

On Wed, Mar 9, 2016 at 8:53 AM, Giuseppe CAVALLARO
 wrote:

Hi Tomeu, Dinh, Andreas

I need a sum and help from you to go ahead on the
tx timeout.

The "stmmac: MDIO fixes" seems to be the candidate to
fix the phy connection and I will send the V2 asap (Andreas' comment).

So, supposing the probe is ok and phy is connected,
I need your input ...

  Tomeu: after revering the 0e80bdc9a72d (stmmac: first frame
 prep at the end of xmit routine) the network is
 not stable and there is a timeout after a while.
 The box has 3.50 with normal desc settings.

  Dinh: the network is ok, I wonder if you can share a boot
log just to understand if the normal or enhanced
descriptors are used.



Here it is:

...

[0.850523] stmmac - user ID: 0x10, Synopsys ID: 0x37
[0.855570]  Ring mode enabled
[0.858611]  DMA HW capability register supported
[0.863128]  Enhanced/Alternate descriptors
[0.867482]  Enabled extended descriptors
[0.871482]  RX Checksum Offload Engine supported (type 2)
[0.876948]  TX Checksum insertion supported
[0.881204]  Enable RX Mitigation via HW Watchdog Timer
[0.886863] socfpga-dwmac ff702000.ethernet eth0: No MDIO subnode found
[0.899090] libphy: stmmac: probed
[0.902484] eth0: PHY ID 00221611 at 4 IRQ POLL (stmmac-0:04) active


Thx Dinh, so you are using the Enhanced/Alternate descriptors
I am debugging on my side on a setup with normal descriptors, I let you
know

peppe

Hello dear,

[Nabila karim]

Hello dear,
I am Miss Nabila Karim. hope you remember me? is been a long time,
where have you been. well, contact me at this, is my directly and
private mail so we can talk
Nabila.

Re: [PATCH 11/13] thermal: convert exynos to use devm_thermal_zone_of_sensor_register

[Lukasz Majewski]

Hi Eduardo,

> This changes the driver to use the devm_ version
> of thermal_zone_of_sensor_register and cleans
> up the  local points and unregister calls.
> 
> Cc: Lukasz Majewski 
> Cc: Zhang Rui 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: linux...@vger.kernel.org
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin 
> ---
>  drivers/thermal/samsung/exynos_tmu.c | 12 
>  1 file changed, 4 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/thermal/samsung/exynos_tmu.c
> b/drivers/thermal/samsung/exynos_tmu.c index fa61eff..256039e 100644
> --- a/drivers/thermal/samsung/exynos_tmu.c
> +++ b/drivers/thermal/samsung/exynos_tmu.c
> @@ -1363,8 +1363,8 @@ static int exynos_tmu_probe(struct
> platform_device *pdev)
>* data->tzd must be registered before calling
> exynos_tmu_initialize(),
>* requesting irq and calling exynos_tmu_control().
>*/
> - data->tzd = thermal_zone_of_sensor_register(&pdev->dev, 0,
> data,
> -
> &exynos_sensor_ops);
> + data->tzd = devm_thermal_zone_of_sensor_register(&pdev->dev,
> 0, data,
> +
> &exynos_sensor_ops); if (IS_ERR(data->tzd)) {
>   ret = PTR_ERR(data->tzd);
>   dev_err(&pdev->dev, "Failed to register sensor:
> %d\n", ret); @@ -1374,21 +1374,19 @@ static int
> exynos_tmu_probe(struct platform_device *pdev) ret =
> exynos_tmu_initialize(pdev); if (ret) {
>   dev_err(&pdev->dev, "Failed to initialize TMU\n");
> - goto err_thermal;
> + goto err_sclk;
>   }
>  
>   ret = devm_request_irq(&pdev->dev, data->irq, exynos_tmu_irq,
>   IRQF_TRIGGER_RISING | IRQF_SHARED,
> dev_name(&pdev->dev), data); if (ret) {
>   dev_err(&pdev->dev, "Failed to request irq: %d\n",
> data->irq);
> - goto err_thermal;
> + goto err_sclk;
>   }
>  
>   exynos_tmu_control(pdev, true);
>   return 0;
>  
> -err_thermal:
> - thermal_zone_of_sensor_unregister(&pdev->dev, data->tzd);
>  err_sclk:
>   clk_disable_unprepare(data->sclk);
>  err_clk:
> @@ -1406,9 +1404,7 @@ err_sensor:
>  static int exynos_tmu_remove(struct platform_device *pdev)
>  {
>   struct exynos_tmu_data *data = platform_get_drvdata(pdev);
> - struct thermal_zone_device *tzd = data->tzd;
>  
> - thermal_zone_of_sensor_unregister(&pdev->dev, tzd);
>   exynos_tmu_control(pdev, false);
>  
>   clk_disable_unprepare(data->sclk);

Reviewed-by: Lukasz Majewski 

-- 
Best regards,

Lukasz Majewski

Samsung R&D Institute Poland (SRPOL) | Linux Platform Group

[RESEND PATCH] dmaengine: at_xdmac: fix residue computation

[Ludovic Desroches]

When computing the residue we need two pieces of information: the current
descriptor and the remaining data of the current descriptor. To get
that information, we need to read consecutively two registers but we
can't do it in an atomic way. For that reason, we have to check manually
that current descriptor has not changed.

Signed-off-by: Ludovic Desroches 
Suggested-by: Cyrille Pitchen 
Reported-by: David Engraf 
Tested-by: David Engraf 
Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel
eXtended DMA Controller driver")
Cc: sta...@vger.kernel.org #4.1 and later
---
 drivers/dma/at_xdmac.c | 42 +++---
 1 file changed, 39 insertions(+), 3 deletions(-)

diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index 64f5d1b..8e304b1 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -176,6 +176,7 @@
 #define AT_XDMAC_MAX_CHAN  0x20
 #define AT_XDMAC_MAX_CSIZE 16  /* 16 data */
 #define AT_XDMAC_MAX_DWIDTH8   /* 64 bits */
+#define AT_XDMAC_RESIDUE_MAX_RETRIES   5
 
 #define AT_XDMAC_DMA_BUSWIDTHS\
(BIT(DMA_SLAVE_BUSWIDTH_UNDEFINED) |\
@@ -1395,8 +1396,8 @@ at_xdmac_tx_status(struct dma_chan *chan, dma_cookie_t 
cookie,
struct at_xdmac_desc*desc, *_desc;
struct list_head*descs_list;
enum dma_status ret;
-   int residue;
-   u32 cur_nda, mask, value;
+   int residue, retry;
+   u32 cur_nda, check_nda, cur_ubc, mask, value;
u8  dwidth = 0;
unsigned long   flags;
 
@@ -1433,7 +1434,42 @@ at_xdmac_tx_status(struct dma_chan *chan, dma_cookie_t 
cookie,
cpu_relax();
}
 
+   /*
+* When processing the residue, we need to read two registers but we
+* can't do it in an atomic way. AT_XDMAC_CNDA is used to find where
+* we stand in the descriptor list and AT_XDMAC_CUBC is used
+* to know how many data are remaining for the current descriptor.
+* Since the dma channel is not paused to not loose data, between the
+* AT_XDMAC_CNDA and AT_XDMAC_CUBC read, we may have change of
+* descriptor.
+* For that reason, after reading AT_XDMAC_CUBC, we check if we are
+* still using the same descriptor by reading a second time
+* AT_XDMAC_CNDA. If AT_XDMAC_CNDA has changed, it means we have to
+* read again AT_XDMAC_CUBC.
+* Memory barriers are used to ensure the read order of the registers.
+* A max number of retries is set because unlikely it can never ends if
+* we are transferring a lot of data with small buffers.
+*/
cur_nda = at_xdmac_chan_read(atchan, AT_XDMAC_CNDA) & 0xfffc;
+   rmb();
+   cur_ubc = at_xdmac_chan_read(atchan, AT_XDMAC_CUBC);
+   for (retry = 0; retry < AT_XDMAC_RESIDUE_MAX_RETRIES; retry++) {
+   rmb();
+   check_nda = at_xdmac_chan_read(atchan, AT_XDMAC_CNDA) & 
0xfffc;
+
+   if (likely(cur_nda == check_nda))
+   break;
+
+   cur_nda = check_nda;
+   rmb();
+   cur_ubc = at_xdmac_chan_read(atchan, AT_XDMAC_CUBC);
+   }
+
+   if (unlikely(retry >= AT_XDMAC_RESIDUE_MAX_RETRIES)) {
+   ret = DMA_ERROR;
+   goto spin_unlock;
+   }
+
/*
 * Remove size of all microblocks already transferred and the current
 * one. Then add the remaining size to transfer of the current
@@ -1446,7 +1482,7 @@ at_xdmac_tx_status(struct dma_chan *chan, dma_cookie_t 
cookie,
if ((desc->lld.mbr_nda & 0xfffc) == cur_nda)
break;
}
-   residue += at_xdmac_chan_read(atchan, AT_XDMAC_CUBC) << dwidth;
+   residue += cur_ubc << dwidth;
 
dma_set_residue(txstate, residue);
 
-- 
2.5.0

Re: [PATCH -tip 0/2] kernel/smp: Small csd_lock optimizations

[Peter Zijlstra]

On Wed, Mar 09, 2016 at 05:55:34PM -0800, Davidlohr Bueso wrote:
> From: Davidlohr Bueso 
> 
> Hi,
> 
> Justifications are in each patch, there is slight impact (patch 2)
> on some tlb flushing intensive benchmarks (albeit using ipi batching
> nowadays).  Specifically for the pft
> benchmark, on a 12-core box:

>  4.4 4.4
>  vanilla smp
> User   11.91   11.85
> System197.11  194.69
> Elapsed44.24   40.26
> 
> While the single thread is an abnormality, overall we don't seem
> to do any harm (noise range). Could be give or take, but overall
> the patches at least make some sense afaict.

Acked-by: Peter Zijlstra (Intel) 

Re: linux-next: manual merge of the xfs tree with the ext4 tree

[Jan Kara]

On Thu 10-03-16 10:41:00, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the xfs tree got a conflict in:
> 
>   fs/ext4/ext4.h
> 
> between commit:
> 
>   109811c20fb8 ("ext4: simplify io_end handling for AIO DIO")
> 
> from the ext4 tree and commit:
> 
>   74c66bcb7eda ("ext4: Fix data exposure after failed AIO DIO")
> 
> from the xfs tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Thanks! This merge looks correct as well.

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: linux-next: manual merge of the xfs tree with the ext4 tree

[Jan Kara]

On Thu 10-03-16 10:40:56, Stephen Rothwell wrote:
> Hi all,
> 
> Today's linux-next merge of the xfs tree got a conflict in:
> 
>   fs/ext4/inode.c
> 
> between commit:
> 
>   109811c20fb8 ("ext4: simplify io_end handling for AIO DIO")
> 
> from the ext4 tree and commit:
> 
>   74c66bcb7eda ("ext4: Fix data exposure after failed AIO DIO")
> 
> from the xfs tree.
> 
> I fixed it up (see below) and can carry the fix as necessary (no action
> is required).

Thanks. The merge looks correct.

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH v2 1/10] cpufreq: Reduce cpufreq_update_util() overhead a bit

[Peter Zijlstra]

On Wed, Mar 09, 2016 at 10:35:02PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki 
> Subject: [PATCH] cpufreq: Move scheduler-related code to the sched directory
> 
> Create cpufreq.c under kernel/sched/ and move the cpufreq code
> related to the scheduler to that file and to sched.h.
> 
> Redefine cpufreq_update_util() as a static inline function to avoid
> function calls at its call sites in the scheduler code (as suggested
> by Peter Zijlstra).
> 
> Also move the definition of struct update_util_data and declaration
> of cpufreq_set_update_util_data() from include/linux/cpufreq.h to
> include/linux/sched.h.
> 
> Signed-off-by: Rafael J. Wysocki 
> ---
>  drivers/cpufreq/cpufreq.c  |   53 
> -
>  drivers/cpufreq/cpufreq_governor.c |1 
>  include/linux/cpufreq.h|   34 ---
>  include/linux/sched.h  |9 ++
>  kernel/sched/Makefile  |1 
>  kernel/sched/cpufreq.c |   37 +
>  kernel/sched/sched.h   |   49 +-
>  7 files changed, 96 insertions(+), 88 deletions(-)

Acked-by: Peter Zijlstra (Intel) 

Re: [PATCH] usb: gadget: f_midi: Fixed a bug when buflen was smaller than wMaxPacketSize

[Felipe Ferreri Tonello]

Hi Steve,

On 09/03/16 22:43, Steve Calfee wrote:
> On Wed, Mar 9, 2016 at 11:39 AM, Felipe F. Tonello  
> wrote:
>> buflen by default (256) is smaller than wMaxPacketSize (512) in high-speed
>> devices.
>>
>> That caused the OUT endpoint to freeze if the host send any data packet of
>> length greater than 256 bytes.
>>
>> This is an example dump of what happended on that enpoint:
>> HOST:   [DATA][Length=260][...]
>> DEVICE: [NAK]
>> HOST:   [PING]
>> DEVICE: [NAK]
>> HOST:   [PING]
>> DEVICE: [NAK]
>> ...
>> HOST:   [PING]
>> DEVICE: [NAK]
>>
>> This patch fixes this problem by setting the minimum usb_request's buffer 
>> size
>> for the OUT endpoint as its wMaxPacketSize.
>>
>> Signed-off-by: Felipe F. Tonello 
>> ---
>>  drivers/usb/gadget/function/f_midi.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/usb/gadget/function/f_midi.c 
>> b/drivers/usb/gadget/function/f_midi.c
>> index 8475e3dc82d4..826ba641f29d 100644
>> --- a/drivers/usb/gadget/function/f_midi.c
>> +++ b/drivers/usb/gadget/function/f_midi.c
>> @@ -366,7 +366,9 @@ static int f_midi_set_alt(struct usb_function *f, 
>> unsigned intf, unsigned alt)
>> /* allocate a bunch of read buffers and queue them all at once. */
>> for (i = 0; i < midi->qlen && err == 0; i++) {
>> struct usb_request *req =
>> -   midi_alloc_ep_req(midi->out_ep, midi->buflen);
>> +   midi_alloc_ep_req(midi->out_ep,
>> +   max_t(unsigned, midi->buflen,
>> +   bulk_out_desc.wMaxPacketSize));
>> if (req == NULL)
>> return -ENOMEM;
>>
> Won't you get a buffer overrun if midi->buflen is less than wMaxPacketSize?
> 

No, because of the *max_t(unsigned, midi->buflen,
bulk_out_desc.wMaxPacketSize)*.

Maybe that's not the most clear indentation but I had to break it in
order to avoid passing 80 columns.

-- 
Felipe


0x92698E6A.asc
Description: application/pgp-keys

RE: [PATCH v3 1/4] mtd:fsl-quadspi:use the property fields of SPI-NOR

[Yunhui Cui]

Hi All,

Thanks for your suggestions before.
Could you help me to review this patch set if you are free?

Thanks
Yunhui

-Original Message-
From: Yunhui Cui [mailto:b56...@freescale.com] 
Sent: Thursday, March 03, 2016 2:54 PM
To: dw...@infradead.org; computersforpe...@gmail.com; han...@freescale.com
Cc: linux-kernel@vger.kernel.org; linux-...@lists.infradead.org; 
linux-arm-ker...@lists.infradead.org; Yao Yuan; Yunhui Cui
Subject: [PATCH v3 1/4] mtd:fsl-quadspi:use the property fields of SPI-NOR

We can get the read/write/erase opcode from the spi nor framework directly. 
This patch uses the information stored in the SPI-NOR to remove the hardcode in 
the fsl_qspi_init_lut().

Signed-off-by: Yunhui Cui 
Signed-off-by: Yunhui Cui 
---
 drivers/mtd/spi-nor/fsl-quadspi.c | 40 ---
 1 file changed, 12 insertions(+), 28 deletions(-)

diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c 
b/drivers/mtd/spi-nor/fsl-quadspi.c
index 9ab2b51..517ffe2 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -373,9 +373,13 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
void __iomem *base = q->iobase;
int rxfifo = q->devtype_data->rxfifo;
u32 lut_base;
-   u8 cmd, addrlen, dummy;
int i;
 
+   struct spi_nor *nor = &q->nor[0];
+   u8 addrlen = (nor->addr_width == 3) ? ADDR24BIT : ADDR32BIT;
+   u8 read_op = nor->read_opcode;
+   u8 read_dm = nor->read_dummy;
+
fsl_qspi_unlock_lut(q);
 
/* Clear all the LUT table */
@@ -385,20 +389,10 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
/* Quad Read */
lut_base = SEQID_QUAD_READ * 4;
 
-   if (q->nor_size <= SZ_16M) {
-   cmd = SPINOR_OP_READ_1_1_4;
-   addrlen = ADDR24BIT;
-   dummy = 8;
-   } else {
-   /* use the 4-byte address */
-   cmd = SPINOR_OP_READ_1_1_4;
-   addrlen = ADDR32BIT;
-   dummy = 8;
-   }
-
-   qspi_writel(q, LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
+   qspi_writel(q, LUT0(CMD, PAD1, read_op) | LUT1(ADDR, PAD1, addrlen),
base + QUADSPI_LUT(lut_base));
-   qspi_writel(q, LUT0(DUMMY, PAD1, dummy) | LUT1(FSL_READ, PAD4, rxfifo),
+   qspi_writel(q, LUT0(DUMMY, PAD1, read_dm) |
+   LUT1(FSL_READ, PAD4, rxfifo),
base + QUADSPI_LUT(lut_base + 1));
 
/* Write enable */
@@ -409,16 +403,8 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
/* Page Program */
lut_base = SEQID_PP * 4;
 
-   if (q->nor_size <= SZ_16M) {
-   cmd = SPINOR_OP_PP;
-   addrlen = ADDR24BIT;
-   } else {
-   /* use the 4-byte address */
-   cmd = SPINOR_OP_PP;
-   addrlen = ADDR32BIT;
-   }
-
-   qspi_writel(q, LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
+   qspi_writel(q, LUT0(CMD, PAD1, nor->program_opcode) |
+   LUT1(ADDR, PAD1, addrlen),
base + QUADSPI_LUT(lut_base));
qspi_writel(q, LUT0(FSL_WRITE, PAD1, 0),
base + QUADSPI_LUT(lut_base + 1));
@@ -432,10 +418,8 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
/* Erase a sector */
lut_base = SEQID_SE * 4;
 
-   cmd = q->nor[0].erase_opcode;
-   addrlen = q->nor_size <= SZ_16M ? ADDR24BIT : ADDR32BIT;
-
-   qspi_writel(q, LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
+   qspi_writel(q, LUT0(CMD, PAD1, nor->erase_opcode) |
+   LUT1(ADDR, PAD1, addrlen),
base + QUADSPI_LUT(lut_base));
 
/* Erase the whole chip */
--
2.1.0.27.g96db324

Re: [PATCH] watchdog: add driver for StreamLabs USB watchdog device

[Oliver Neukum]

On Thu, 2016-03-10 at 02:29 +, Alexey Klimov wrote:
> This patch creates new driver that supports StreamLabs usb watchdog
> device. This device plugs into 9-pin usb header and connects to
> reset pin and reset button on common PC.

Hi,

a few remarks.

Regards
Oliver

> 
> USB commands used to communicate with device were reverse
> engineered using usbmon.
> 
> Signed-off-by: Alexey Klimov 
> ---
>  drivers/watchdog/Kconfig  |  15 ++
>  drivers/watchdog/Makefile |   1 +
>  drivers/watchdog/streamlabs_wdt.c | 370 
> ++
>  3 files changed, 386 insertions(+)
>  create mode 100644 drivers/watchdog/streamlabs_wdt.c
> 
> diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
> index 80825a7..95d8f72 100644
> --- a/drivers/watchdog/Kconfig
> +++ b/drivers/watchdog/Kconfig
> @@ -1705,4 +1705,19 @@ config USBPCWATCHDOG
>  
> Most people will say N.
>  
> +config USB_STREAMLABS_WATCHDOG
> + tristate "StreamLabs USB watchdog driver"
> + depends on USB
> + ---help---
> +   This is the driver for the USB Watchdog dongle from StreamLabs.
> +   If you correctly connect reset pins to motherboard Reset pin and
> +   to Reset button then this device will simply watch your kernel to make
> +   sure it doesn't freeze, and if it does, it reboots your computer
> +   after a certain amount of time.
> +
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called streamlabs_wdt.
> +
> +   Most people will say N. Say yes or M if you want to use such usb 
> device.
>  endif # WATCHDOG
> diff --git a/drivers/watchdog/Makefile b/drivers/watchdog/Makefile
> index f6a6a38..d54fd31 100644
> --- a/drivers/watchdog/Makefile
> +++ b/drivers/watchdog/Makefile
> @@ -25,6 +25,7 @@ obj-$(CONFIG_WDTPCI) += wdt_pci.o
>  
>  # USB-based Watchdog Cards
>  obj-$(CONFIG_USBPCWATCHDOG) += pcwd_usb.o
> +obj-$(CONFIG_USB_STREAMLABS_WATCHDOG) += streamlabs_wdt.o
>  
>  # ALPHA Architecture
>  
> diff --git a/drivers/watchdog/streamlabs_wdt.c 
> b/drivers/watchdog/streamlabs_wdt.c
> new file mode 100644
> index 000..031dbc35
> --- /dev/null
> +++ b/drivers/watchdog/streamlabs_wdt.c
> @@ -0,0 +1,370 @@
> +/*
> + * StreamLabs USB Watchdog driver
> + *
> + * Copyright (c) 2016 Alexey Klimov 
> + *
> + * This program is free software; you may redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/*
> + * USB Watchdog device from Streamlabs
> + * http://www.stream-labs.com/products/devices/watchdog/
> + *
> + * USB commands have been reverse engineered using usbmon.
> + */
> +
> +#define DRIVER_AUTHOR "Alexey Klimov "
> +#define DRIVER_DESC "StreamLabs USB watchdog driver"
> +#define DRIVER_NAME "usb_streamlabs_wdt"
> +
> +MODULE_AUTHOR(DRIVER_AUTHOR);
> +MODULE_DESCRIPTION(DRIVER_DESC);
> +MODULE_LICENSE("GPL");
> +
> +#define USB_STREAMLABS_WATCHDOG_VENDOR   0x13c0
> +#define USB_STREAMLABS_WATCHDOG_PRODUCT  0x0011
> +
> +/* one buffer is used for communication, however transmitted message is only
> + * 32 bytes long */
> +#define BUFFER_TRANSFER_LENGTH   32
> +#define BUFFER_LENGTH64
> +#define USB_TIMEOUT  350
> +
> +#define STREAMLABS_CMD_START 0
> +#define STREAMLABS_CMD_STOP  1
> +
> +#define STREAMLABS_WDT_MIN_TIMEOUT   1
> +#define STREAMLABS_WDT_MAX_TIMEOUT   46
> +
> +struct streamlabs_wdt {
> + struct watchdog_device wdt_dev;
> + struct usb_device *usbdev;

You can always deduce the device from the interface. There's
no need to store it.

> + struct usb_interface *intf;
> +
> + struct kref kref;
> + struct mutex lock;
> + u8 *buffer;
> +};
> +
> +static bool nowayout = WATCHDOG_NOWAYOUT;
> +
> +static int usb_streamlabs_wdt_validate_response(u8 *buf)
> +{
> + /* If watchdog device understood the command it will acknowledge
> +  * with values 1,2,3,4 at indexes 10, 11, 12, 13 in response message.
> +  */
> + if (buf[10] != 1 || buf[11] != 2 || buf[12] != 3 || buf[13] != 4)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int usb_streamlabs_wdt_command(struct watchdog_device *wdt_dev, int 
> cmd)
> +{
> + struct streamlabs_wdt *streamlabs_wdt = watchdog_get_drvdata(wdt_dev);
> + int retval;
> + int size;
> + unsigned long timeout_msec;
> + int retry_counter = 10; /* how many times to re-send stop cmd */
> +
> + mutex_

Re: [RFC][PATCH v2 1/2] printk: Make printk() completely async

[Jan Kara]

On Wed 09-03-16 15:09:50, Sergey Senozhatsky wrote:
> Hello Jan,
> 
> On (03/07/16 13:16), Jan Kara wrote:
> [..]
> > > So if this will be a problem in practice, using a kthread will probably be
> > > the easiest solution.
> > 
> > Hum, and thinking more about it: Considering that WQ_MEM_RECLAIM workqueues
> > create kthread anyway as a rescuer thread, it may be the simplest to just
> > go back to using a single kthread for printing. What do you think?
> 
> I have this patch on top of the series now. In short, it closes one more
> possibility of lockups -- console_lock()/console_unlock() calls. the patch
> splits console_unlock() in two parts:
> -- the fast one just wake up printing kthread
> -- the slow one does call_console_drivers() loop
> 
> I think it sort of makes sense to tweak the patch below a bit and fold it
> into 0001, and move _some_ of the vprintk_emit() checks to console_unlock().
> 
> very schematically, after folding, vprintk_emit() will be
> 
>   if (in_sched) {
>   if (!printk_sync && printk_thread)
>   wake_up()
>   else
>   irq_work_queue()
>   }
>   
>   if (!in_sched)
>   if (console_trylock())
>   console_unlock()
> 
> and console_unlock() will be
> 
>   if (!in_panic && !printk_sync && printk_thread) {
>   up_console_sem()
>   wake_up()
>   } else {
>   console_unlock_for_printk()
>   }
> 
> console_unlock_for_printk() does the call_console_drivers() loop.
> 
> console_flush_on_panic() and printing_func() call console_unlock_for_printk()
> directly.
> 
> 
> What do you think? Or would you prefer to first introduce async
> printk() rework, and move to console_unlock() in vprintk_emit()
> one release cycle later?
> IOW, in 3 steps:
> -- first make printk() async
> -- then console_unlock() async, and use console_unlock_for_printk() in
>vprintk_emit()
> -- then switch to console_unlock() in vprintk_emit().
> 
> 
> below is the patch which introduces console_unlock_for_printk().
> not the squashed console_unlock_for_printk() and 0001.

So I think this should definitely stay as a separate patch since it
possibly changes user visible behavior and sometimes blocking may be
actually desirable for userspace. I don't have that strong opinion whether
it should be in a separate patch set or part of this one. Maybe a separate
patch set would be somewhat better so that we first hash out possible issues
with async printk and once that's settled we start messing more with the
code changing the behavior of console_unlock() as well.

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH] serial-uartlite: un-constify uartlite_be/uartlite_le

[Maarten Brock]

I've created a version 2 of this patch immediately which fixes the warning,
but somehow this stays ignored.

Please apply my second patch!
Maarten

> The patch to make uartlite_be/uartlite_le const was well-intended but
> caused a new build warning:
> 
> tty/serial/uartlite.c: In function 'ulite_request_port':
> tty/serial/uartlite.c:348:21: error: assignment discards 'const' qualifier
> from pointer target type [-Werror=discarded-qualifiers]
> tty/serial/uartlite.c:354:22: error: assignment discards 'const' qualifier
> from pointer target type [-Werror=discarded-qualifiers]
> 
> It would be nice to allow passing const pointers through
> port->private_data, but that would be way more work, so this
> reverts part of the original commit for now.
> 
> A possible alternative might be to pass a structure in the private_data
> that contains a const pointer to the operations, which introduces a little
> extra overhead, or we could just add a cast to a non-const pointer, I'll
> leave that to the maintainer.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: 2905697a82ea ("serial-uartlite: Constify uartlite_be/uartlite_le")
> ---
>  drivers/tty/serial/uartlite.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/tty/serial/uartlite.c b/drivers/tty/serial/uartlite.c
> index c9fdfc8bf47f..1474c5755140 100644
> --- a/drivers/tty/serial/uartlite.c
> +++ b/drivers/tty/serial/uartlite.c
> @@ -72,7 +72,7 @@ static void uartlite_outbe32(u32 val, void __iomem *addr)
>   iowrite32be(val, addr);
>  }
>  
> -static const struct uartlite_reg_ops uartlite_be = {
> +static struct uartlite_reg_ops uartlite_be = {
>   .in = uartlite_inbe32,
>   .out = uartlite_outbe32,
>  };
> @@ -87,7 +87,7 @@ static void uartlite_outle32(u32 val, void __iomem *addr)
>   iowrite32(val, addr);
>  }
>  
> -static const struct uartlite_reg_ops uartlite_le = {
> +static struct uartlite_reg_ops uartlite_le = {
>   .in = uartlite_inle32,
>   .out = uartlite_outle32,
>  };
> -- 
> 2.7.0
> 
> 

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

[Roman Kagan]

On Wed, Mar 09, 2016 at 02:38:52PM -0500, Rik van Riel wrote:
> On Wed, 2016-03-09 at 20:04 +0300, Roman Kagan wrote:
> > On Wed, Mar 09, 2016 at 05:41:39PM +0200, Michael S. Tsirkin wrote:
> > > On Wed, Mar 09, 2016 at 05:28:54PM +0300, Roman Kagan wrote:
> > > > For (1) I've been trying to make a point that skipping clean
> > > > pages is
> > > > much more likely to result in noticable benefit than free pages
> > > > only.
> > > 
> > > I guess when you say clean you mean zero?
> > 
> > No I meant clean, i.e. those that could be evicted from RAM without
> > causing I/O.
> > 
> 
> Programs in the guest may have that memory mmapped.
> This could include things like libraries and executables.
> 
> How do you deal with the guest page cache containing
> references to now non-existent memory?
> 
> How do you re-populate the memory on the destination
> host?

I guess the confusion is due to the context I stripped from the previous
messages...  Actually I've been talking about doing full-fledged balloon
inflation before the migration, so, when it's deflated the guest will
fault in that data from the filesystem as usual.

Roman.

[PATCH] perf tool: Build jitdump only on supported archs

[Jiri Olsa]

On Mon, Mar 07, 2016 at 04:44:36PM -0300, Arnaldo Carvalho de Melo wrote:

SNIP

> 
> Adrian Hunter (5):
>   perf inject: Hit all DSOs for AUX data in JIT and other cases
>   perf session: Simplify tool stubs
>   perf jit: Let jit_process() return errors
>   perf jit: Move clockid validation
>   perf tools: Use 64-bit shifts with (TSC) time conversion

hi,
perf build failed for me on s390x because of jitdump feature.

Attached patch tries to enable the build only on supported archs.

I haven't followed this feature too much, so I might have missed
something.. anyway it builds on s390x now ;-) I took the list of
archs from util/genelf.h

thanks,
jirka


---
Make jitdump being built only on architectures
defined in util/genelf.h file.

Signed-off-by: Jiri Olsa 
---
 tools/perf/arch/arm/Makefile |  1 +
 tools/perf/arch/arm64/Makefile   |  1 +
 tools/perf/arch/powerpc/Makefile |  1 +
 tools/perf/arch/x86/Makefile |  1 +
 tools/perf/builtin-inject.c  | 12 +++-
 tools/perf/config/Makefile   |  7 +++
 tools/perf/util/Build|  2 +-
 7 files changed, 19 insertions(+), 6 deletions(-)

diff --git a/tools/perf/arch/arm/Makefile b/tools/perf/arch/arm/Makefile
index 7fbca175099e..18b13518d8d8 100644
--- a/tools/perf/arch/arm/Makefile
+++ b/tools/perf/arch/arm/Makefile
@@ -1,3 +1,4 @@
 ifndef NO_DWARF
 PERF_HAVE_DWARF_REGS := 1
 endif
+PERF_HAVE_JITDUMP := 1
diff --git a/tools/perf/arch/arm64/Makefile b/tools/perf/arch/arm64/Makefile
index 7fbca175099e..18b13518d8d8 100644
--- a/tools/perf/arch/arm64/Makefile
+++ b/tools/perf/arch/arm64/Makefile
@@ -1,3 +1,4 @@
 ifndef NO_DWARF
 PERF_HAVE_DWARF_REGS := 1
 endif
+PERF_HAVE_JITDUMP := 1
diff --git a/tools/perf/arch/powerpc/Makefile b/tools/perf/arch/powerpc/Makefile
index 9f9cea3478fd..56e05f126ad8 100644
--- a/tools/perf/arch/powerpc/Makefile
+++ b/tools/perf/arch/powerpc/Makefile
@@ -3,3 +3,4 @@ PERF_HAVE_DWARF_REGS := 1
 endif
 
 HAVE_KVM_STAT_SUPPORT := 1
+PERF_HAVE_JITDUMP := 1
diff --git a/tools/perf/arch/x86/Makefile b/tools/perf/arch/x86/Makefile
index 09ba923debe8..269af2143735 100644
--- a/tools/perf/arch/x86/Makefile
+++ b/tools/perf/arch/x86/Makefile
@@ -3,3 +3,4 @@ PERF_HAVE_DWARF_REGS := 1
 endif
 HAVE_KVM_STAT_SUPPORT := 1
 PERF_HAVE_ARCH_REGS_QUERY_REGISTER_OFFSET := 1
+PERF_HAVE_JITDUMP := 1
diff --git a/tools/perf/builtin-inject.c b/tools/perf/builtin-inject.c
index e219ed458d97..6eb17e24c4cc 100644
--- a/tools/perf/builtin-inject.c
+++ b/tools/perf/builtin-inject.c
@@ -73,7 +73,7 @@ static int perf_event__repipe_oe_synth(struct perf_tool *tool,
return perf_event__repipe_synth(tool, event);
 }
 
-#if defined(HAVE_LIBELF_SUPPORT) && defined(HAVE_DWARF_SUPPORT)
+#ifdef HAVE_JITDUMP
 static int perf_event__drop_oe(struct perf_tool *tool __maybe_unused,
   union perf_event *event __maybe_unused,
   struct ordered_events *oe __maybe_unused)
@@ -245,7 +245,7 @@ static int perf_event__repipe_mmap(struct perf_tool *tool,
return err;
 }
 
-#if defined(HAVE_LIBELF_SUPPORT) && defined(HAVE_DWARF_SUPPORT)
+#if defined(HAVE_JITDUMP)
 static int perf_event__jit_repipe_mmap(struct perf_tool *tool,
   union perf_event *event,
   struct perf_sample *sample,
@@ -283,7 +283,7 @@ static int perf_event__repipe_mmap2(struct perf_tool *tool,
return err;
 }
 
-#if defined(HAVE_LIBELF_SUPPORT) && defined(HAVE_DWARF_SUPPORT)
+#if defined(HAVE_JITDUMP)
 static int perf_event__jit_repipe_mmap2(struct perf_tool *tool,
union perf_event *event,
struct perf_sample *sample,
@@ -778,7 +778,9 @@ int cmd_inject(int argc, const char **argv, const char 
*prefix __maybe_unused)
OPT_BOOLEAN('s', "sched-stat", &inject.sched_stat,
"Merge sched-stat and sched-switch for getting 
events "
"where and how long tasks slept"),
+#ifdef HAVE_JITDUMP
OPT_BOOLEAN('j', "jit", &inject.jit_mode, "merge jitdump files 
into perf.data file"),
+#endif
OPT_INCR('v', "verbose", &verbose,
 "be more verbose (show build ids, etc)"),
OPT_STRING(0, "kallsyms", &symbol_conf.kallsyms_name, "file",
@@ -795,7 +797,7 @@ int cmd_inject(int argc, const char **argv, const char 
*prefix __maybe_unused)
"perf inject []",
NULL
};
-#if !defined(HAVE_LIBELF_SUPPORT) || !defined(HAVE_DWARF_SUPPORT)
+#ifndef HAVE_JITDUMP
set_option_nobuild(options, 'j', "jit", "NO_LIBELF=1", true);
 #endif
argc = parse_options(argc, argv, options, inject_usage, 0);
@@ -833,7 +835,7 @@ int cmd_inject(int argc, const char **argv, const char 
*prefix __maybe_unused)
inject.tool.ordered_events =

Re: [PATCH 05/13] input: convert sun4i-ts to use devm_thermal_zone_of_sensor_register

[Sascha Hauer]

On Wed, Mar 09, 2016 at 01:35:27PM -0800, Eduardo Valentin wrote:
> This changes the driver to use the devm_ version
> of thermal_zone_of_sensor_register and cleans
> up the  local points and unregister calls.
> 
> Cc: Dmitry Torokhov 
> Cc: Maxime Ripard 
> Cc: Chen-Yu Tsai 
> Cc: Hans de Goede 
> Cc: Zhang Rui 
> Cc: Lukasz Majewski 
> Cc: Heiko Stuebner 
> Cc: Sascha Hauer 
> Cc: Jens Thiele 
> Cc: linux-in...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Eduardo Valentin 
> ---
>  drivers/input/touchscreen/sun4i-ts.c | 9 +
>  1 file changed, 1 insertion(+), 8 deletions(-)
> 
> diff --git a/drivers/input/touchscreen/sun4i-ts.c 
> b/drivers/input/touchscreen/sun4i-ts.c
> index 4857943..d07dd29 100644
> --- a/drivers/input/touchscreen/sun4i-ts.c
> +++ b/drivers/input/touchscreen/sun4i-ts.c
> @@ -115,7 +115,6 @@
>  struct sun4i_ts_data {
>   struct device *dev;
>   struct input_dev *input;
> - struct thermal_zone_device *tz;
>   void __iomem *base;
>   unsigned int irq;
>   bool ignore_fifo_data;
> @@ -366,10 +365,7 @@ static int sun4i_ts_probe(struct platform_device *pdev)
>   if (IS_ERR(hwmon))
>   return PTR_ERR(hwmon);
>  
> - ts->tz = thermal_zone_of_sensor_register(ts->dev, 0, ts,
> -  &sun4i_ts_tz_ops);
> - if (IS_ERR(ts->tz))
> - ts->tz = NULL;
> + devm_thermal_zone_of_sensor_register(ts->dev, 0, ts, &sun4i_ts_tz_ops);

Shouldn't we check the return value? There are a few possibilities for
thermal_zone_of_sensor_register to fail.

Sascha


-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: + x86-add-support-for-pud-sized-transparent-hugepages-checkpatch-fixes.patch added to -mm tree

[Ingo Molnar]

* Matthew Wilcox  wrote:

> On Wed, Mar 09, 2016 at 01:08:08PM +0100, Ingo Molnar wrote:
> > * Matthew Wilcox  wrote:
> > > I have no idea what it means.  This is copy-and-change of the pmd version,
> > > which was originally commit db3eb96f4e6281b84dd33c8980dacc27f2efe177 by
> > > Andrea.
> > 
> > It means that we don't want to copy-and-change a crappy comment that 
> > slipped 
> > through 5 years ago, we want to copy-and-improve. I even suggested the 
> > comment 
> > improvement (which needs to be checked though).
> 
> The "it" in my sentence referred to the comment.  I have no idea what
> the comment is supposed to mean.  I am the worst person to figure out
> what the comment is supposed to mean as I have the least experience with
> the code here.
> 
> The PUD and PMD code should be as similar as possible, down to the
> comments and the spacing.  If you want the original fixed, that's fine,
> and I'm willing to include it as part of this patch set.  But it's not
> my responsibility to fix up the comments that you don't like.
> 
> > > It seems unfair to ask me to do better than what is there right now.
> > 
> > It's absolutely fair for maintainers to require the improvement of existing 
> > code 
> > you want to modify, especially when you are complicating existing code ...
> 
> I'm not complicating it.  I'm duplicating it.

I don't think your language lawyering is particularly constructive: you are 
adding 
new functionality to existing x86 code, and as such you need to address review 
feedback from x86 maintainers - even if it involves old code.

( There's an obvious maintainability threshold concern behind such requests 
from 
  maintainers: existing bad practices in old code accumulate, and the code can
  bear only so much complexity, so there's a level over which we require 
cleanups 
  to existing code before we accept new changes. )

This is nothing new, this happens all the time, it's a routine review practice 
when new patches are applied.

Anyway, until my concerns are addressed the x86 bits are NAK-ed:

  NAKed-by: Ingo Molnar 

Thanks,

Ingo

Re: [PATCH V3] PM / clk: Add support for obtaining clocks from device-tree

[Geert Uytterhoeven]

Hi Jon,

On Thu, Mar 10, 2016 at 10:00 AM, Jon Hunter  wrote:
> The PM clocks framework requires clients to pass either a con-id or a
> valid clk pointer in order to add a clock to a device. Add a new
> function of_pm_clk_add_clks() to allows device clocks to be retrieved
> from device-tree and populated for a given device. Note that
> of_clk_get_from_provider() is not defined if CONFIG_OF and
> CONFIG_COMMON_CLK are not selected. Therefore, make of_pm_clk_add_clks()
> dependent on these options.
>
> An optional function pointer may be passed to of_pm_clk_add_clks() that
> can be used to filter the clocks that are added for a device when
> calling of_pm_clk_add_clks().
>
> In order to handle errors encountered when adding clocks from
> device-tree, add a function pm_clk_remove_clk() to remove any clocks
> (using a pointer to the clk structure) that have been added
> successfully before the error occurred.
>
> Signed-off-by: Jon Hunter 

Tested-by: Geert Uytterhoeven 

But more comments below...

> --- a/drivers/base/power/clock_ops.c
> +++ b/drivers/base/power/clock_ops.c
> @@ -137,6 +137,81 @@ int pm_clk_add_clk(struct device *dev, struct clk *clk)
> return __pm_clk_add(dev, NULL, clk);
>  }
>
> +
> +#if defined(CONFIG_OF) && defined(CONFIG_COMMON_CLK)
> +/**
> + * of_pm_clk_add_clks - Start using device clock(s) for power management.
> + * @dev: Device whose clock(s) is going to be used for power management.
> + * @of_pm_clk_filter: Optional function for filtering clocks
> + *
> + * Add a series of clocks described in the 'clocks' device-tree node for
> + * a device to the list of clocks used for the power management of @dev.
> + * If 'of_pm_clk_filter' is specified, then this filter function will be
> + * called for each clock found and the clock will be added to the list
> + * of clocks if this function returns true. Return success if clocks are
> + * added successfully and return a negative error code if adding a clock
> + * fails or there are no clocks that match with the filter function.
> + */
> +int of_pm_clk_add_clks(struct device *dev, of_pm_clk_filter fn, void *data)
> +{

[...]

> +   count = of_count_phandle_with_args(dev->of_node, "clocks",
> +  "#clock-cells");
> +   if (count == 0)
> +   return -ENODEV;

[...]

+   return added ? 0 : -ENODEV;

Is it an error condition if no clocks were present in DT, or if no clocks have
been accepted by the filter function? If not, the caller has to check for
-ENODEV. Now the caller has to call pm_clk_create() first, before it knows if
any clocks will be added, it may want to call pm_clk_destroy() later if no
clocks have been added.

Alternatively, you could return 0 vs. the actual number of clocks added.

I hooked up your code in renesas-cpg-mssr.c, and it worked.
However, I noticed it added 27 clocks for one device node (rcar_sound), and
only then I realized that I only want to add the first clock accepted by the
filter, not all of them, as the others are under driver control.
I'm not sure this can be handled in the filter function.
So I can't use your code (for now)...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [PATCH 1/4] scatterlist: Introduce some helper functions

[Robert Jarzmik]

Baolin Wang  writes:

> Hi Robert,
>
> On 4 March 2016 at 03:15, Robert Jarzmik  wrote:
>> Baolin Wang  writes:
>>> +static inline bool sg_is_contiguous(struct scatterlist *sga,
>>> + struct scatterlist *sgb)
>>> +{
>>> + return ((sga->page_link & ~0x3UL) + sga->offset + sga->length ==
>>> + (sgb->page_link & ~0x3UL));
>>> +}
>> I don't understand that one.
>> sga->page_link is a pointer to a "struct page *". How can it be added to an
>> offset within a page ???
>
>
> Ah, sorry that's a mistake. It should check as below:
> static inline bool sg_is_contiguous(struct scatterlist *sga, struct
> scatterlist *sgb)
> {
> return (unsigned int)sg_virt(sga) + sga->length == (unsigned
> int)sg_virt(sgb);
> }
NAK.
First, I don't like the cast.
Second ask yourself: what if you compile on a 64 bit architecture ?
Third, I don't like void* arithmetics, some compilers might refuse it.

And as a last comment, is it "virtual" contiguity you're looking after, physical
contiguity, or dma_addr_t contiguity ?

>>> @@ -370,6 +370,65 @@ int sg_alloc_table(struct sg_table *table, unsigned int
>>> nents, gfp_t gfp_mask)
>> ...
>>>  /**
>>> + * sg_add_sg_to_table - Add one scatterlist into sg table
>>> + * @sgt: The sg table header to use
>>> + * @src: The sg need to be added into sg table
>>> + *
>>> + * Description:
>>> + *   The 'nents' member indicates how many scatterlists added in the sg 
>>> table.
>>> + *   Copy the @src@ scatterlist into sg table and increase 'nents' member.
>>> + *
>>> + **/
>>> +int sg_add_sg_to_table(struct sg_table *sgt, struct scatterlist *src)
>>> +{
>>> + unsigned int i = 0, orig_nents = sgt->orig_nents;
>>> + struct scatterlist *sgl = sgt->sgl;
>>> + struct scatterlist *sg;
>>> +
>>> + /* Check if there are enough space for the new sg to be added */
>>> + if (sgt->nents >= sgt->orig_nents)
>>> + return -EINVAL;
>> I must admit I don't understand that one either : how do comparing the 
>> number of
>> "mapped" entries against the number of "allocated" entries determines if 
>> there
>> is enough room ?
>
> That's for a dynamic sg table. If there is one sg table allocated
> 'orig_nents' scatterlists, and we need copy another mapped scatterlist
> into the sg table if there are some requirements. So we use 'nents' to
> record how many scatterlists have been copied into the sg table.
As I'm still having difficulities to understand, please explain to me :
 - what is a dynamic sg_table
 - how it works
 - if it's "struct sg_table", how the field of this structure are different when
   it's a dynamic sg_table from a "static sg_table" ?

>>> +/**
>>> + * sg_alloc_empty_table - Allocate one empty sg table
>>> + * @sgt: The sg table header to use
>>> + * @nents:   Number of entries in sg list
>>> + * @gfp_mask:GFP allocation mask
>>> + *
>>> + *  Description:
>>> + *Allocate and initialize an sg table. The 'nents' member of sg_table
>>> + *indicates how many scatterlists added in the sg table. It should set
>>> + *0 which means there are no scatterlists added in this sg table now.
>>> + *
>>> + **/
>>> +int sg_alloc_empty_table(struct sg_table *sgt, unsigned int nents,
>>> +  gfp_t gfp_mask)
>> As for this one, there has to be a purpose for it I fail to see. From far 
>> away
>> it looks exactly like sg_alloc_table(), excepting it "works around" the 
>> nents >
>> 0 protection of __sg_alloc_table().
>> What is exactly the need for this one, and if it's usefull why not simply
>> changing the __sg_alloc_table() "nents > 0" test and see what the outcome of 
>> the
>> review will be ?
>
> Like I said above. If we want to copy some mapped scatterlists into
> one sg table, we should set the 'nents' to 0 to indicates how many
> scatterlists coppied in the sg table.
So how do you unmap this scatterlist once you've lost the number of mapped
entries ?

I think we'll come back to this once I understand how a "dynamic" sg_table is
different from a "static" one.

Cheers.

-- 
Robert

Re: [PATCH v3 1/3] SROP Mitigation: Architecture independent code for signal cookies

[Ingo Molnar]

* Jonathan Corbet  wrote:

> On Wed, 9 Mar 2016 15:07:07 -0700
> Scotty Bauer  wrote:
> 
> > On 03/09/2016 01:32 AM, Ingo Molnar wrote:
> > > 
> > > Could you please add a high level description in Documentation
> > > that explains the attack and the way how this mitigation code
> > > prevents that kind of attack?
> > > 
> > > Also, the first changelogs should contain more high level
> > > description as well. For example, what does the 'verification'
> > > of the signal cookie mean, and how does it prevent an SROP
> > > attempt?
> > > 
> > > All of these patches seem to assume that people reading this code
> > > know what SROP is and how we defend against it - that is not so.
> > 
> > I'm going to submit v4 to fix some nits where I'll include the explanation
> > and a change log, I apologize for not doing that here. In the meantime if
> > you don't mind visiting a link I included a brief explanation on previous
> > versions of the patch set.
> > 
> > https://lkml.org/lkml/2016/2/6/166
> 
> The curious might also find background information in my article about this
> patch set:
> 
>   https://lwn.net/Articles/676803/

Scott, mind including a prominent link to the (excellent!) LWN.net article in 
the 
changelog/documentation as well?

Thanks,

Ingo

Re: [PATCH 1/5] doc/memory-barriers: fix missed renaming: s/lock/acquire

[David Howells]

SeongJae Park  wrote:

> >> - - Locking functions.
> >> + - Acquiring functions.
> ...
> > It's specifically talking about locking functions that the kernel provides -
> > or are we calling the spin acquires and R/W spin acquires now?  "Locking" is
> > the key that people referring to the document are going to use.
> 
> AFAIU, the next line of the quoted text says the section is talking about
> variants on "ACQUIRE" operations and "RELEASE" operations for each locking
> constructs.

Whilst that's true, most people think of them as locks.  You could change the
name of the section to:

Locking/Acquiring functions

or:

Lock acquisition functions

perhaps.

David

Re: [PATCH v3 05/12] arm64, acpi, numa: NUMA support based on SRAT and SLIT

[Hanjun Guo]

Hi Matthias,

Sorry for the late reply, on a travelling now.

On 03/02/2016 10:08 PM, Matthias Brugger wrote:



On 23/01/16 10:39, Hanjun Guo wrote:

From: Hanjun Guo 

Introduce a new file to hold ACPI based NUMA information
parsing from SRAT and SLIT.

SRAT includes the CPU ACPI ID to Proximity Domain mappings
and memory ranges to Proximity Domain mapping.
SLIT has the information of inter node
distances(relative number for access latency).

Signed-off-by: Hanjun Guo 
Signed-off-by: Ganapatrao Kulkarni 

[..]


diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index 9e8704b..e974995 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -17,6 +17,7 @@
   * along with this program.  If not, see
.
   */

+#include 
  #include 
  #include 
  #include 
@@ -385,10 +386,8 @@ void __init arm64_numa_init(void)
  {
  int ret = -ENODEV;

-#ifdef CONFIG_OF_NUMA
  if (!numa_off)
-ret = numa_init(arm64_of_numa_init);
-#endif
+ret = numa_init(acpi_disabled ? arm64_of_numa_init :
arm64_acpi_numa_init);


Header asm/acpi.h is included in linux/acpi.h but only if CONFIG_ACPI=y
arm64_acpi_numa_init is declared in asm/acpi.h, so if we don't use the
ifdef CONFIG_* approach from Robert, we will need to include as/acpi.h
implicitly here. Otherwise we get a compilation error if CONFIG_ACPI is
not set.


Yes, I noticed the same issue as you spotted out, and I agree with
you and Robert that I should use the ifdef CONFIG_* approach.

Thanks
Hanjun

Re: [RFC][PATCH v2 1/2] printk: Make printk() completely async

[Petr Mladek]

On Wed 2016-03-09 15:09:50, Sergey Senozhatsky wrote:
> On (03/07/16 13:16), Jan Kara wrote:
> What do you think? Or would you prefer to first introduce async
> printk() rework, and move to console_unlock() in vprintk_emit()
> one release cycle later?
> IOW, in 3 steps:
> -- first make printk() async
> -- then console_unlock() async, and use console_unlock_for_printk() in
>vprintk_emit()
>
> -- then switch to console_unlock() in vprintk_emit().

I would sort this by priorities. I know about real-world problems
that will get solved by async printk. I haven't heard yet people
complaining about blocked console_lock()/console_unlock() calls
outside printk code. So, I would personally prefer to handle
async printk first.

Heh, you opened an interesting can of worms. There are definitely
locations that just want to manipulate the list of consoles and
their setting without the need to push the date. I wonder how
many locations really need to push the data.

Note that console_unlock_for_printk() might be a bit
misleading. Especially when you suggest to replace it by
console_unlock() in vprintk_emit() ;-) I wonder if
console_flush_and_unlock() might be more descriptive.

We might even split flush_console() into a separate function in the end.
I think that the combination with unlock() is there to make sure
that somebody will flush the last messages from printk(), see
the retry stuff. It probably won't be needed with the asynch printk().

Anyway, all these console_unlock() changes looks like another big step
and I suggest to do it separately.

I looking forward to see where this ends.

Thanks,
Petr

PS: I want to check more precisely the async printk patchset but
I am repeatedy sidetracked this week :-(

Re: [PATCH] mm: avoid unnecessary swapin in khugepaged

[Kirill A. Shutemov]

On Wed, Mar 09, 2016 at 11:55:43PM +0200, Ebru Akagunduz wrote:
> Currently khugepaged makes swapin readahead to improve
> THP collapse rate. This patch checks vm statistics
> to avoid workload of swapin, if unnecessary. So that
> when system under pressure, khugepaged won't consume
> resources to swapin.
> 
> The patch was tested with a test program that allocates
> 800MB of memory, writes to it, and then sleeps. The system
> was forced to swap out all. Afterwards, the test program
> touches the area by writing, it skips a page in each
> 20 pages of the area. When waiting to swapin readahead
> left part of the test, the memory forced to be busy
> doing page reclaim. There was enough free memory during
> test, khugepaged did not swapin readahead due to business.
> 
> Test results:
> 
>   After swapped out
> ---
>   | Anonymous | AnonHugePages | Swap  | Fraction  |
> ---
> With patch| 450964 kB |  450560 kB| 349036 kB |%99|
> ---
> Without patch | 351308 kB | 350208 kB | 448692 kB |%99|
> ---
> 
> After swapped in (waiting 10 minutes)
> ---
>   | Anonymous | AnonHugePages | Swap  | Fraction  |
> ---
> With patch| 637932 kB | 559104 kB | 162068 kB |%69|
> ---
> Without patch | 586816 kB | 464896 kB | 213184 kB |%79|
> ---
> 
> Signed-off-by: Ebru Akagunduz 
> ---
>  mm/huge_memory.c | 15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 7f75292..109a2af 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -102,6 +102,7 @@ static DECLARE_WAIT_QUEUE_HEAD(khugepaged_wait);
>   */
>  static unsigned int khugepaged_max_ptes_none __read_mostly;
>  static unsigned int khugepaged_max_ptes_swap __read_mostly;
> +static unsigned long int allocstall = 0;
>  
>  static int khugepaged(void *none);
>  static int khugepaged_slab_init(void);
> @@ -2411,6 +2412,7 @@ static void collapse_huge_page(struct mm_struct *mm,
>   struct mem_cgroup *memcg;
>   unsigned long mmun_start;   /* For mmu_notifiers */
>   unsigned long mmun_end; /* For mmu_notifiers */
> + unsigned long events[NR_VM_EVENT_ITEMS], swap = 0;

collapse_huge_page() is nested under collapse_huge_page(), so you
effectively allocate 2 * NR_VM_EVENT_ITEMS * sizeof(long) on stack.
That's a lot for stack. And it's only get total value of ALLOCSTALL event.

Should we instead introduce a helper to sum values of a particular event
over all cpu? I'm surprised that we don't have any yet.

Something like this (totally untested):

unsigned long sum_vm_event(enum vm_event_item item)
{
int cpu;
unsigned long ret = 0;

get_online_cpus();
for_each_online_cpu(cpu)
ret += per_cpu(vm_event_states, cpu).event[item];
put_online_cpus();
return ret;
}

-- 
 Kirill A. Shutemov

Re: [PATCH] arc: use little endian accesses

[Vineet Gupta]

On Thursday 10 March 2016 01:14 PM, Alexey Brodkin wrote:
>>> 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.

Can you or Lada provide more details as to exactly what is not working - what
driver to be precise 8250 or dw-8250.
And where exactly the failure shows up. I want to understand this more
Noam told me off list that he has no issues with both big endian ARC + 8250 in
systemc model or silicon.

-Vineet

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

[Ingo Molnar]

* Andy Lutomirski  wrote:

> 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.

If so then mind picking up (and fixing ;-) tip:WIP.x86/mm in its entirety? It's 
well tested so shouldn't have too many easy to hit bugs. Feel free to rebase 
and 
restructure it, it's a WIP tree.

I keep getting distracted with other things but I'd hate if this got dropped on 
the floor.

Thanks,

Ingo

Re: [PATCH 0/2 v6] printk, Add monotonic and real printk timestamps

[Petr Mladek]

On Tue 2016-03-08 06:03:24, Prarit Bhargava wrote:
> 
> 
> On 03/08/2016 02:59 AM, Thomas Gleixner wrote:
> > On Tue, 23 Feb 2016, Prarit Bhargava wrote:
> > 
> >> This patchset adds monotonic and real printk timestamps.  The first patch
> >> changes CONFIG_PRINT_TIME from a bool to an int to allow for the additional
> >> timestamps that are added in patch 2.
> >>
> >> Changes from v6: Petr Mladek pointed out that the current patch
> >> fails to indicate to userspace programs which timestamp is being used.
> > 
> > How is that solved?
> 
> Hi Thomas,
> 
> Userspace programs can now look at /sys/modules/printk/parameters/time which
> will contain [0-3] for the timestamp clock.

But it includes only the current setting that is valid only for
messages printed with this setting. The ring buffer might include
different messages produced with different setting.

I suggest to look how dmesg handles the time stamp. I wonder how it
converts the relative time into an absolute one. I wonder if you
could convert all timestamps to the relative format, so that you
do not need to change all userspace tools at all.

Best regards,
Petr

Re: [PATCH 1/2] KVM: MMU: fix ept=0/pte.u=0/pte.w=0/CR0.WP=0/CR4.SMEP=1/EFER.NX=0 combo

[Paolo Bonzini]

On 10/03/2016 09:46, Xiao Guangrong wrote:
> 
>> Yes, all of these are needed. :) This is admittedly a bit odd, but
>> kvm-unit-tests access.flat tests this if you run it with "-cpu host"
>> and of course ept=0.
>>
>> KVM handles supervisor writes of a pte.u=0/pte.w=0/CR0.WP=0 page by
>> setting U=0 and W=1 in the shadow PTE.  This will cause a user write
>> to fault and a supervisor write to succeed (which is correct because
>> CR0.WP=0).  A user read instead will flip U=0 to 1 and W=1 back to 0.
> 
> BTW, it should be pte.u = 1 where you mentioned above.

Ok, will fix.

Paolo

Re: [PATCH 2/2] KVM: MMU: fix reserved bit check for pte.u=0/pte.w=0/CR0.WP=0/CR4.SMEP=1/EFER.NX=0

[Paolo Bonzini]

On 10/03/2016 09:36, Xiao Guangrong wrote:
> 
> 
> On 03/08/2016 07:44 PM, Paolo Bonzini wrote:
>> KVM handles supervisor writes of a pte.u=0/pte.w=0/CR0.WP=0 page by
>> setting U=0 and W=1 in the shadow PTE.  This will cause a user write
>> to fault and a supervisor write to succeed (which is correct because
>> CR0.WP=0).  A user read instead will flip U=0 to 1 and W=1 back to 0.
>> This enables user reads; it also disables supervisor writes, the next
>> of which will then flip the bits again.
>>
>> When SMEP is in effect, however, pte.u=0 will enable kernel execution
>> of this page.  To avoid this, KVM also sets pte.nx=1.  The reserved bit
>> catches this because it only looks at the guest's EFER.NX bit.  Teach it
>> that smep_andnot_wp will also use the NX bit of SPTEs.
>>
>> Cc: sta...@vger.kernel.org
>> Cc: Xiao Guangrong 
> 
> As a redhat guy i am so proud. :)
> 
>> Fixes: c258b62b264fdc469b6d3610a907708068145e3b
> 
> Thanks for you fixing it, Paolo!
> 
> Reviewed-by: Xiao Guangrong 
> 
>> Signed-off-by: Paolo Bonzini 
>> ---
>>   arch/x86/kvm/mmu.c | 4 +++-
>>   1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
>> index 95a955de5964..0cd4ee01de94 100644
>> --- a/arch/x86/kvm/mmu.c
>> +++ b/arch/x86/kvm/mmu.c
>> @@ -3721,13 +3721,15 @@ static void reset_rsvds_bits_mask_ept(struct
>> kvm_vcpu *vcpu,
>>   void
>>   reset_shadow_zero_bits_mask(struct kvm_vcpu *vcpu, struct kvm_mmu
>> *context)
>>   {
>> +int uses_nx = context->nx || context->base_role.smep_andnot_wp;
> 
> It would be better if it is 'bool'

Ok, will do.

Paolo

[PATCH v1] regulator: gpio: check return value of of_get_named_gpio

[Mihai Mihalache]

At boot time the regulator driver can be initialized before the
gpio, in which case the call to of_get_named_gpio will return
EPROBE_DEFER. This value is silently passed to regulator_register
which will return success, although the gpio is not registered
(regulator_ena_gpio_request not called) as the value passed is
detected as invalid. The gpio_regulator_probe will therefore
succeed win no gpio requested.

Signed-off-by: Mihai Mihalache 
---

History:
V1:
- Fix comment from Mark Brown

 drivers/regulator/gpio-regulator.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/regulator/gpio-regulator.c 
b/drivers/regulator/gpio-regulator.c
index 464018d..9108c57 100644
--- a/drivers/regulator/gpio-regulator.c
+++ b/drivers/regulator/gpio-regulator.c
@@ -162,6 +162,8 @@ of_get_gpio_regulator_config(struct device *dev, struct 
device_node *np,
of_property_read_u32(np, "startup-delay-us", &config->startup_delay);
 
config->enable_gpio = of_get_named_gpio(np, "enable-gpio", 0);
+   if (IS_ERR_VALUE(config->enable_gpio))
+   return ERR_PTR(config->enable_gpio);
 
/* Fetch GPIOs. - optional property*/
ret = of_gpio_count(np);
-- 
2.1.4

Re: [PATCH 2/2] Staging: dgap: modified the block comments

[DaeSeok Youn]

2016-03-10 17:21 GMT+09:00 Tanvi Surana :
> I have modified the file dgap.c ,making changes to the multiline 
> comments,thus making them appear presentable
>
> Signed-Off-By: Tanvi Surana 
> ---
>  drivers/staging/dgap/dgap.c | 59 
> +
>  1 file changed, 33 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/staging/dgap/dgap.c b/drivers/staging/dgap/dgap.c
> index bad3551..deff2c4 100644
> --- a/drivers/staging/dgap/dgap.c
> +++ b/drivers/staging/dgap/dgap.c
> @@ -91,22 +91,22 @@ static uint dgap_poll_stop; /* Used to tell 
> poller to stop */
>  static struct timer_list dgap_poll_timer;
>
>  /*
> - SUPPORTED PRODUCTS
> -
> - Card Model   Number of Ports  Interface
> - 
> - Acceleport Xem   4 - 64  (EIA232 & EIA422)
> - Acceleport Xr4 & 8   (EIA232)
> - Acceleport Xr 9204 & 8   (EIA232)
> - Acceleport C/X   8 - 128 (EIA232)
> - Acceleport EPC/X 8 - 224 (EIA232)
> - Acceleport Xr/4224 & 8   (EIA422)
> - Acceleport 2r/9202   (EIA232)
> - Acceleport 4r/9204   (EIA232)
> - Acceleport 8r/9208   (EIA232)
> -
> - IBM 8-Port Asynchronous PCI Adapter  (EIA232)
> - IBM 128-Port Asynchronous PCI Adapter(EIA232 & EIA422)
> +   SUPPORTED PRODUCTS
> +
> +   Card Model   Number of Ports  Interface
> +   
> +   Acceleport Xem   4 - 64  (EIA232 & EIA422)
> +   Acceleport Xr4 & 8   (EIA232)
> +   Acceleport Xr 9204 & 8   (EIA232)
> +   Acceleport C/X   8 - 128 (EIA232)
> +   Acceleport EPC/X 8 - 224 (EIA232)
> +   Acceleport Xr/4224 & 8   (EIA422)
> +   Acceleport 2r/9202   (EIA232)
> +   Acceleport 4r/9204   (EIA232)
> +   Acceleport 8r/9208   (EIA232)
> +
> +   IBM 8-Port Asynchronous PCI Adapter  (EIA232)
> +   IBM 128-Port Asynchronous PCI Adapter(EIA232 & EIA422)
>  */
>
>  static struct pci_device_id dgap_pci_tbl[] = {
> @@ -1465,7 +1465,8 @@ static void dgap_parity_scan(struct channel_t *ch, 
> unsigned char *cbuf,
>   *
>   *  ch  - Pointer to channel structure.
>   *
> - *===*/
> + *===
> + */
>
>  static void dgap_input(struct channel_t *ch)
>  {
> @@ -1694,7 +1695,8 @@ static void dgap_write_wakeup(struct board_t *bd, 
> struct channel_t *ch,
>  /
>   * Determines when CARRIER changes state and takes appropriate
>   * action.
> - /
> + ***
> + */
>  static void dgap_carrier(struct channel_t *ch)
>  {
> struct board_t *bd;
> @@ -2339,7 +2341,8 @@ schedule_poller:
>   *  ncmds   - Wait until ncmds or fewer cmds are left
>   *in the cmd buffer before returning.
>   *
> - *===*/
> + *===
> + */
>  static void dgap_cmdb(struct channel_t *ch, u8 cmd, u8 byte1,
>   u8 byte2, uint ncmds)
>  {
> @@ -2424,7 +2427,8 @@ static void dgap_cmdb(struct channel_t *ch, u8 cmd, u8 
> byte1,
>   *  ncmds   - Wait until ncmds or fewer cmds are left
>   *in the cmd buffer before returning.
>   *
> - *===*/
> + *===
> + */
>  static void dgap_cmdw(struct channel_t *ch, u8 cmd, u16 word, uint ncmds)
>  {
> char __iomem *vaddr;
> @@ -2506,7 +2510,8 @@ static void dgap_cmdw(struct channel_t *ch, u8 cmd, u16 
> word, uint ncmds)
>   *  ncmds   - Wait until ncmds or fewer cmds are left
>   *in the cmd buffer before returning.
>   *
> - *===*/
> + *===
> + */
>  static void dgap_cmdw_ext(struct channel_t *ch, u16 cmd, u16 word, uint 
> ncmds)
>  {
> char __iomem *vaddr;
> @@ -2598,7 +2603,8 @@ static void dgap_cmdw_ext(struct channel_t *ch, u16 
> cmd, u16 word, uint ncmds)
>   *  buf - Pointer to characters to be moved.
>   * 

Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data

[Peter Zijlstra]

On Thu, Mar 10, 2016 at 10:44:21AM +0700, Vincent Guittot wrote:
> We have the arch_scale_freq_capacity function that is arch dependent
> and can be used to merge the 2 formula that were described by peter
> above.
> By default, arch_scale_freq_capacity return SCHED_CAPACITY_SCALE which
> is max capacity
> but when arch_scale_freq_capacity is defined by an architecture,

> arch_scale_freq_capacity returns current_freq * max_capacity/max_freq

However, current_freq is a very fluid thing, it might (and will) change
very rapidly on some platforms.

This is the same point I made earlier, you cannot try and divide out
current_freq from the invariant measure.

> so can't we use arch_scale_freq in your formula ? Taking your formula
> above it becomes:
> next_freq = 1.25 * current_freq * util / arch_scale_freq_capacity()

No, that cannot work, nor makes any sense, per the above.

> With invariance feature, we have:
>
>   next_freq = 1.25 * current_freq * util / 
> (current_freq*max_capacity/max_freq)
> = 1.25 * util * max_freq / max
>
> which is the formula that has to be used with frequency invariant
> utilization.

Wrong, you cannot talk about current_freq in the invariant case.

> May be we can pass arch_scale_freq_capacity value instead of max one
> as a parameter of update_util function prototype

No, since its a compile time thing, we can simply do:

#ifdef arch_scale_freq_capacity
next_freq = (1 + 1/n) * max_freq * (util / max)
#else
next_freq = (1 + 1/n) * current_freq * (util_raw / max)
#endif

[PATCH v5 net-next 07/10] bus: mvebu-mbus: provide api for obtaining IO and DRAM window information

[Gregory CLEMENT]

From: Marcin Wojtas 

This commit enables finding appropriate mbus window and obtaining its
target id and attribute for given physical address in two separate
routines, both for IO and DRAM windows. This functionality
is needed for Armada XP/38x Network Controller's Buffer Manager and
PnC configuration.

[gregory.clem...@free-electrons.com: Fix size test for
mvebu_mbus_get_dram_win_info]

Signed-off-by: Marcin Wojtas 
[DRAM window information reference in LKv3.10]
Signed-off-by: Evan Wang 
Signed-off-by: Gregory CLEMENT 
---
 drivers/bus/mvebu-mbus.c | 52 
 include/linux/mbus.h |  3 +++
 2 files changed, 55 insertions(+)

diff --git a/drivers/bus/mvebu-mbus.c b/drivers/bus/mvebu-mbus.c
index c43c3d2baf73..c2e52864bb03 100644
--- a/drivers/bus/mvebu-mbus.c
+++ b/drivers/bus/mvebu-mbus.c
@@ -948,6 +948,58 @@ void mvebu_mbus_get_pcie_io_aperture(struct resource *res)
*res = mbus_state.pcie_io_aperture;
 }
 
+int mvebu_mbus_get_dram_win_info(phys_addr_t phyaddr, u8 *target, u8 *attr)
+{
+   const struct mbus_dram_target_info *dram;
+   int i;
+
+   /* Get dram info */
+   dram = mv_mbus_dram_info();
+   if (!dram) {
+   pr_err("missing DRAM information\n");
+   return -ENODEV;
+   }
+
+   /* Try to find matching DRAM window for phyaddr */
+   for (i = 0; i < dram->num_cs; i++) {
+   const struct mbus_dram_window *cs = dram->cs + i;
+
+   if (cs->base <= phyaddr &&
+   phyaddr <= (cs->base + cs->size - 1)) {
+   *target = dram->mbus_dram_target_id;
+   *attr = cs->mbus_attr;
+   return 0;
+   }
+   }
+
+   pr_err("invalid dram address 0x%x\n", phyaddr);
+   return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(mvebu_mbus_get_dram_win_info);
+
+int mvebu_mbus_get_io_win_info(phys_addr_t phyaddr, u32 *size, u8 *target,
+  u8 *attr)
+{
+   int win;
+
+   for (win = 0; win < mbus_state.soc->num_wins; win++) {
+   u64 wbase;
+   int enabled;
+
+   mvebu_mbus_read_window(&mbus_state, win, &enabled, &wbase,
+  size, target, attr, NULL);
+
+   if (!enabled)
+   continue;
+
+   if (wbase <= phyaddr && phyaddr <= wbase + *size)
+   return win;
+   }
+
+   return -EINVAL;
+}
+EXPORT_SYMBOL_GPL(mvebu_mbus_get_io_win_info);
+
 static __init int mvebu_mbus_debugfs_init(void)
 {
struct mvebu_mbus_state *s = &mbus_state;
diff --git a/include/linux/mbus.h b/include/linux/mbus.h
index 1f7bc630d225..ea34a867caa0 100644
--- a/include/linux/mbus.h
+++ b/include/linux/mbus.h
@@ -69,6 +69,9 @@ static inline const struct mbus_dram_target_info 
*mv_mbus_dram_info_nooverlap(vo
 int mvebu_mbus_save_cpu_target(u32 *store_addr);
 void mvebu_mbus_get_pcie_mem_aperture(struct resource *res);
 void mvebu_mbus_get_pcie_io_aperture(struct resource *res);
+int mvebu_mbus_get_dram_win_info(phys_addr_t phyaddr, u8 *target, u8 *attr);
+int mvebu_mbus_get_io_win_info(phys_addr_t phyaddr, u32 *size, u8 *target,
+  u8 *attr);
 int mvebu_mbus_add_window_remap_by_id(unsigned int target,
  unsigned int attribute,
  phys_addr_t base, size_t size,
-- 
2.5.0

[PATCH v5 net-next 02/10] ARM: dts: armada-38x: add buffer manager nodes

[Gregory CLEMENT]

From: Marcin Wojtas 

Armada 38x network controller supports hardware buffer management (BM).
Since it is now enabled in mvneta driver, appropriate nodes can be added
to armada-38x.dtsi - for the actual common BM unit (bm@c8000) and its
internal SRAM (bm-bppi), which is used for indirect access to buffer
pointer ring residing in DRAM.

Pools - ports mapping, bm-bppi entry in 'soc' node's ranges and optional
parameters are supposed to be set in board files.

Signed-off-by: Marcin Wojtas 
Signed-off-by: Gregory CLEMENT 
---
 arch/arm/boot/dts/armada-38x.dtsi | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/armada-38x.dtsi 
b/arch/arm/boot/dts/armada-38x.dtsi
index e8b7f6726772..066a8f06405c 100644
--- a/arch/arm/boot/dts/armada-38x.dtsi
+++ b/arch/arm/boot/dts/armada-38x.dtsi
@@ -540,6 +540,14 @@
status = "disabled";
};
 
+   bm: bm@c8000 {
+   compatible = "marvell,armada-380-neta-bm";
+   reg = <0xc8000 0xac>;
+   clocks = <&gateclk 13>;
+   internal-mem = <&bm_bppi>;
+   status = "disabled";
+   };
+
sata@e {
compatible = "marvell,armada-380-ahci";
reg = <0xe 0x2000>;
@@ -618,6 +626,17 @@
#size-cells = <1>;
ranges = <0 MBUS_ID(0x09, 0x15) 0 0x800>;
};
+
+   bm_bppi: bm-bppi {
+   compatible = "mmio-sram";
+   reg = ;
+   ranges = <0 MBUS_ID(0x0c, 0x04) 0 0x10>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   clocks = <&gateclk 13>;
+   no-memory-wc;
+   status = "disabled";
+   };
};
 
clocks {
-- 
2.5.0

Re: [PATCH 1/2] KVM: MMU: fix ept=0/pte.u=0/pte.w=0/CR0.WP=0/CR4.SMEP=1/EFER.NX=0 combo

[Paolo Bonzini]

On 10/03/2016 09:27, Xiao Guangrong wrote:
>>
> 
>> +if (!enable_ept) {
>> +guest_efer |= EFER_NX;
>> +ignore_bits |= EFER_NX;
> 
> Update ignore_bits is not necessary i think.

More precisely, ignore_bits is only needed if guest EFER.NX=0 and we're
not in this CR0.WP=1/CR4.SMEP=0 situation.  In theory you could have
guest EFER.NX=1 and host EFER.NX=0.

This is what I came up with (plus some comments :)):

u64 guest_efer = vmx->vcpu.arch.efer;
u64 ignore_bits = 0;

if (!enable_ept) {
if (boot_cpu_has(X86_FEATURE_SMEP))
guest_efer |= EFER_NX;
else if (!(guest_efer & EFER_NX))
ignore_bits |= EFER_NX;
}

>> -guest_efer = vmx->vcpu.arch.efer;
>>   if (!(guest_efer & EFER_LMA))
>>   guest_efer &= ~EFER_LME;
>>   if (guest_efer != host_efer)
>>   add_atomic_switch_msr(vmx, MSR_EFER,
>> guest_efer, host_efer);
> 
> So, why not set EFER_NX (if !ept) just in this branch to make the fix
> more simpler?

I didn't like having

guest_efer = vmx->vcpu.arch.efer;
...
if (!enable_ept)
guest_efer |= EFER_NX;
guest_efer &= ~ignore_bits;
guest_efer |= host_efer & ignore_bits;
...
if (...) {
guest_efer = vmx->vcpu.arch.efer;
if (!enable_ept)
guest_efer |= EFER_NX;
...
}

My patch is bigger but the resulting code is smaller and easier to follow:

guest_efer = vmx->vcpu.arch.efer;
if (!enable_ept)
guest_efer |= EFER_NX;
...
if (...) {
...
} else {
guest_efer &= ~ignore_bits;
guest_efer |= host_efer & ignore_bits;
}

Paolo

[PATCH v5 net-next 09/10] net: add a hardware buffer management helper API

[Gregory CLEMENT]

This basic implementation allows to share code between driver using
hardware buffer management. As the code is hardware agnostic, there is
few helpers, most of the optimization brought by the an HW BM has to be
done at driver level.

Signed-off-by: Gregory CLEMENT 
---
 include/net/hwbm.h | 28 ++
 net/Kconfig|  3 ++
 net/core/Makefile  |  1 +
 net/core/hwbm.c| 87 ++
 4 files changed, 119 insertions(+)
 create mode 100644 include/net/hwbm.h
 create mode 100644 net/core/hwbm.c

diff --git a/include/net/hwbm.h b/include/net/hwbm.h
new file mode 100644
index ..47d08662501b
--- /dev/null
+++ b/include/net/hwbm.h
@@ -0,0 +1,28 @@
+#ifndef _HWBM_H
+#define _HWBM_H
+
+struct hwbm_pool {
+   /* Capacity of the pool */
+   int size;
+   /* Size of the buffers managed */
+   int frag_size;
+   /* Number of buffers currently used by this pool */
+   int buf_num;
+   /* constructor called during alocation */
+   int (*construct)(struct hwbm_pool *bm_pool, void *buf);
+   /* protect acces to the buffer counter*/
+   spinlock_t lock;
+   /* private data */
+   void *priv;
+};
+#ifdef CONFIG_HWBM
+void hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf);
+int hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t gfp);
+int hwbm_pool_add(struct hwbm_pool *bm_pool, unsigned int buf_num, gfp_t gfp);
+#else
+void hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf) {}
+int hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t gfp) { return 0; }
+int hwbm_pool_add(struct hwbm_pool *bm_pool, unsigned int buf_num, gfp_t gfp)
+{ return 0; }
+#endif /* CONFIG_HWBM */
+#endif /* _HWBM_H */
diff --git a/net/Kconfig b/net/Kconfig
index 174354618f8a..f50c8af4308b 100644
--- a/net/Kconfig
+++ b/net/Kconfig
@@ -253,6 +253,9 @@ config XPS
depends on SMP
default y
 
+config HWBM
+   bool
+
 config SOCK_CGROUP_DATA
bool
default n
diff --git a/net/core/Makefile b/net/core/Makefile
index 0b835de04de3..57e6dd81c6be 100644
--- a/net/core/Makefile
+++ b/net/core/Makefile
@@ -24,3 +24,4 @@ obj-$(CONFIG_NET_PTP_CLASSIFY) += ptp_classifier.o
 obj-$(CONFIG_CGROUP_NET_PRIO) += netprio_cgroup.o
 obj-$(CONFIG_CGROUP_NET_CLASSID) += netclassid_cgroup.o
 obj-$(CONFIG_LWTUNNEL) += lwtunnel.o
+obj-$(CONFIG_HWBM) += hwbm.o
diff --git a/net/core/hwbm.c b/net/core/hwbm.c
new file mode 100644
index ..941c28486896
--- /dev/null
+++ b/net/core/hwbm.c
@@ -0,0 +1,87 @@
+/* Support for hardware buffer manager.
+ *
+ * Copyright (C) 2016 Marvell
+ *
+ * Gregory CLEMENT 
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ */
+#include 
+#include 
+#include 
+#include 
+
+void hwbm_buf_free(struct hwbm_pool *bm_pool, void *buf)
+{
+   if (likely(bm_pool->frag_size <= PAGE_SIZE))
+   skb_free_frag(buf);
+   else
+   kfree(buf);
+}
+EXPORT_SYMBOL_GPL(hwbm_buf_free);
+
+/* Refill processing for HW buffer management */
+int hwbm_pool_refill(struct hwbm_pool *bm_pool, gfp_t gfp)
+{
+   int frag_size = bm_pool->frag_size;
+   void *buf;
+
+   if (likely(frag_size <= PAGE_SIZE))
+   buf = netdev_alloc_frag(frag_size);
+   else
+   buf = kmalloc(frag_size, gfp);
+
+   if (!buf)
+   return -ENOMEM;
+
+   if (bm_pool->construct)
+   if (bm_pool->construct(bm_pool, buf)) {
+   hwbm_buf_free(bm_pool, buf);
+   return -ENOMEM;
+   }
+
+   return 0;
+}
+EXPORT_SYMBOL_GPL(hwbm_pool_refill);
+
+int hwbm_pool_add(struct hwbm_pool *bm_pool, unsigned int buf_num, gfp_t gfp)
+{
+   int err, i;
+   unsigned long flags;
+
+   spin_lock_irqsave(&bm_pool->lock, flags);
+   if (bm_pool->buf_num == bm_pool->size) {
+   pr_warn("pool already filled\n");
+   return bm_pool->buf_num;
+   }
+
+   if (buf_num + bm_pool->buf_num > bm_pool->size) {
+   pr_warn("cannot allocate %d buffers for pool\n",
+   buf_num);
+   return 0;
+   }
+
+   if ((buf_num + bm_pool->buf_num) < bm_pool->buf_num) {
+   pr_warn("Adding %d buffers to the %d current buffers will 
overflow\n",
+   buf_num,  bm_pool->buf_num);
+   return 0;
+   }
+
+   for (i = 0; i < buf_num; i++) {
+   err = hwbm_pool_refill(bm_pool, gfp);
+   if (err < 0)
+   break;
+   }
+
+   /* Update BM driver with number of buffers added to pool */
+   bm_pool->buf_num += i;
+
+   pr_debug("hwpm pool: %d of %d buffers added\n", i, buf_num);
+   spin_unlock_irqrestore(&bm_pool->lock, flags);
+
+   

[PATCH v5 net-next 03/10] ARM: dts: armada-38x: enable buffer manager support on Armada 38x boards

[Gregory CLEMENT]

From: Marcin Wojtas 

Since mvneta driver supports using hardware buffer management (BM), in
order to use it, board files have to be adjusted accordingly. This commit
enables BM on:
* A385-DB-AP - each port has its own pool for long and common pool for
short packets,
* A388-ClearFog - same as above,
* A388-DB - to each port unique 'short' and 'long' pools are mapped,
* A388-GP - same as above.

Moreover appropriate entry is added to 'soc' node ranges, as well as "okay"
status for 'bm' and 'bm-bppi' (internal SRAM) nodes.

[gregory.clem...@free-electrons.com: add suppport for the ClearFog board]

Signed-off-by: Marcin Wojtas 
Signed-off-by: Gregory CLEMENT 
Acked-by: Russell King 
---
 arch/arm/boot/dts/armada-385-db-ap.dts  | 20 +++-
 arch/arm/boot/dts/armada-388-clearfog.dts   |  6 ++
 arch/arm/boot/dts/armada-388-db.dts | 17 -
 arch/arm/boot/dts/armada-388-gp.dts | 17 -
 arch/arm/boot/dts/armada-38x-solidrun-microsom.dtsi | 15 ++-
 5 files changed, 71 insertions(+), 4 deletions(-)

diff --git a/arch/arm/boot/dts/armada-385-db-ap.dts 
b/arch/arm/boot/dts/armada-385-db-ap.dts
index acd5b1519edb..5f9451be21ff 100644
--- a/arch/arm/boot/dts/armada-385-db-ap.dts
+++ b/arch/arm/boot/dts/armada-385-db-ap.dts
@@ -61,7 +61,8 @@
ranges = ;
+ MBUS_ID(0x09, 0x15) 0 0xf111 0x1
+ MBUS_ID(0x0c, 0x04) 0 0xf120 0x10>;
 
internal-regs {
spi1: spi@10680 {
@@ -138,12 +139,18 @@
status = "okay";
phy = <&phy2>;
phy-mode = "sgmii";
+   buffer-manager = <&bm>;
+   bm,pool-long = <1>;
+   bm,pool-short = <3>;
};
 
ethernet@34000 {
status = "okay";
phy = <&phy1>;
phy-mode = "sgmii";
+   buffer-manager = <&bm>;
+   bm,pool-long = <2>;
+   bm,pool-short = <3>;
};
 
ethernet@7 {
@@ -157,6 +164,13 @@
status = "okay";
phy = <&phy0>;
phy-mode = "rgmii-id";
+   buffer-manager = <&bm>;
+   bm,pool-long = <0>;
+   bm,pool-short = <3>;
+   };
+
+   bm@c8000 {
+   status = "okay";
};
 
nfc: flash@d {
@@ -178,6 +192,10 @@
};
};
 
+   bm-bppi {
+   status = "okay";
+   };
+
pcie-controller {
status = "okay";
 
diff --git a/arch/arm/boot/dts/armada-388-clearfog.dts 
b/arch/arm/boot/dts/armada-388-clearfog.dts
index c6e180eb3b11..c60206efb583 100644
--- a/arch/arm/boot/dts/armada-388-clearfog.dts
+++ b/arch/arm/boot/dts/armada-388-clearfog.dts
@@ -78,6 +78,9 @@
internal-regs {
ethernet@3 {
phy-mode = "sgmii";
+   buffer-manager = <&bm>;
+   bm,pool-long = <2>;
+   bm,pool-short = <1>;
status = "okay";
 
fixed-link {
@@ -88,6 +91,9 @@
 
ethernet@34000 {
phy-mode = "sgmii";
+   buffer-manager = <&bm>;
+   bm,pool-long = <3>;
+   bm,pool-short = <1>;
status = "okay";
 
fixed-link {
diff --git a/arch/arm/boot/dts/armada-388-db.dts 
b/arch/arm/boot/dts/armada-388-db.dts
index ff47af57f091..ea93ed727030 100644
--- a/arch/arm/boot/dts/armada-388-db.dts
+++ b/arch/arm/boot/dts/armada-388-db.dts
@@ -66,7 +66,8 @@
ranges = ;
+ MBUS_ID(0x09, 0x15) 0 0xf111 0x1
+ MBUS_ID(0x0c, 0x04) 0 0xf120 0x10>;
 
internal-regs {
spi@10600 {
@@ -99,6 +100,9 @@
status = "okay";
phy = <&phy1>;
phy-mode = "rgmii-id";
+   buffer-manager = <&bm>;
+   bm,pool-long = <2>;
+   bm,pool-short = <3>;
};
 
usb@58000 {
@@ -

Re: [PATCH v3 08/12] arm64, numa: rework numa_add_memblk()

[Hanjun Guo]

Hi Robert,

On 03/09/2016 08:27 PM, Robert Richter wrote:

On 23.01.16 17:39:23, Hanjun Guo wrote:

From: Hanjun Guo 

Rework numa_add_memblk() to update the parameter "u64 size"
to "u64 end", this will make it consistent with x86 and
can simplify the code later.

Updates for arch/arm64/mm/numa.c should squash to core NUMA
patches from Ganapat.

Signed-off-by: Hanjun Guo 
---
  arch/arm64/kernel/acpi_numa.c |  2 +-
  arch/arm64/kernel/of_numa.c   |  2 +-
  arch/arm64/mm/numa.c  | 12 ++--
  3 files changed, 8 insertions(+), 8 deletions(-)



diff --git a/arch/arm64/kernel/of_numa.c b/arch/arm64/kernel/of_numa.c
index 2f9e34b..aa6f3a3 100644
--- a/arch/arm64/kernel/of_numa.c
+++ b/arch/arm64/kernel/of_numa.c
@@ -168,7 +168,7 @@ static int __init early_init_parse_memory_node(unsigned 
long node)
pr_debug("NUMA-DT:  base = %llx , node = %u\n",
base, nid);

-   if (numa_add_memblk(nid, base, size) < 0)
+   if (numa_add_memblk(nid, base, base + size) < 0)
return -EINVAL;
}

diff --git a/arch/arm64/mm/numa.c b/arch/arm64/mm/numa.c
index e974995..2b04b8a 100644
--- a/arch/arm64/mm/numa.c
+++ b/arch/arm64/mm/numa.c
@@ -137,25 +137,25 @@ void numa_store_cpu_info(unsigned int cpu)
   * numa_add_memblk - Set node id to memblk
   * @nid: NUMA node ID of the new memblk
   * @start: Start address of the new memblk
- * @size:  Size of the new memblk
+ * @end:  End address of the new memblk


Apart from my earlier comment, this is not exactly correct and may
cause confussion. The implementation here defines:

  size == end - start

which is different to struct resource, where:

  resource_size(res) == res->end - res->start + 1

Thus, @end here is the first address outside of memblk.

This is one more argument for keeping @size here.


I agree :)

I'm working on the new version and met the problem of no
definition for numa_add_memblk() and numa_set_distance()
on IA64, numa_set_distance() seems to easy to add one for
IA64, but numa_add_memblk() is not, this will the blocker
for moving functions to common place, what's your opinion
here?

Also I'm thinking to move all the code in arch/arm64/kernel/acpi_numa.c
to the arch/arm64/kernel/acpi.c to make the ACPI code in ARM64
self-contained, what do you think?

Thanks
Hanjun

[PATCH v5 net-next 08/10] net: mvneta: bm: add support for hardware buffer management

[Gregory CLEMENT]

From: Marcin Wojtas 

Buffer manager (BM) is a dedicated hardware unit that can be used by all
ethernet ports of Armada XP and 38x SoC's. It allows to offload CPU on RX
path by sparing DRAM access on refilling buffer pool, hardware-based
filling of descriptor ring data and better memory utilization due to HW
arbitration for using 'short' pools for small packets.

Tests performed with A388 SoC working as a network bridge between two
packet generators showed increase of maximum processed 64B packets by
~20k (~555k packets with BM enabled vs ~535 packets without BM). Also
when pushing 1500B-packets with a line rate achieved, CPU load decreased
from around 25% without BM to 20% with BM.

BM comprise up to 4 buffer pointers' (BP) rings kept in DRAM, which
are called external BP pools - BPPE. Allocating and releasing buffer
pointers (BP) to/from BPPE is performed indirectly by write/read access
to a dedicated internal SRAM, where internal BP pools (BPPI) are placed.
BM hardware controls status of BPPE automatically, as well as assigning
proper buffers to RX descriptors. For more details please refer to
Functional Specification of Armada XP or 38x SoC.

In order to enable support for a separate hardware block, common for all
ports, a new driver has to be implemented ('mvneta_bm'). It provides
initialization sequence of address space, clocks, registers, SRAM,
empty pools' structures and also obtaining optional configuration
from DT (please refer to device tree binding documentation). mvneta_bm
exposes also a necessary API to mvneta driver, as well as a dedicated
structure with BM information (bm_priv), whose presence is used as a
flag notifying of BM usage by port. It has to be ensured that mvneta_bm
probe is executed prior to the ones in ports' driver. In case BM is not
used or its probe fails, mvneta falls back to use software buffer
management.

A sequence executed in mvneta_probe function is modified in order to have
an access to needed resources before possible port's BM initialization is
done. According to port-pools mapping provided by DT appropriate registers
are configured and the buffer pools are filled. RX path is modified
accordingly. Becaues the hardware allows a wide variety of configuration
options, following assumptions are made:
* using BM mechanisms can be selectively disabled/enabled basing
  on DT configuration among the ports
* 'long' pool's single buffer size is tied to port's MTU
* using 'long' pool by port is obligatory and it cannot be shared
* using 'short' pool for smaller packets is optional
* one 'short' pool can be shared among all ports

This commit enables hardware buffer management operation cooperating with
existing mvneta driver. New device tree binding documentation is added and
the one of mvneta is updated accordingly.

[gregory.clem...@free-electrons.com: removed the suspend/resume part]

Signed-off-by: Marcin Wojtas 
Signed-off-by: Gregory CLEMENT 
---
 .../bindings/net/marvell-armada-370-neta.txt   |  19 +-
 .../devicetree/bindings/net/marvell-neta-bm.txt|  49 ++
 drivers/net/ethernet/marvell/Kconfig   |  13 +
 drivers/net/ethernet/marvell/Makefile  |   1 +
 drivers/net/ethernet/marvell/mvneta.c  | 507 +--
 drivers/net/ethernet/marvell/mvneta_bm.c   | 546 +
 drivers/net/ethernet/marvell/mvneta_bm.h   | 189 +++
 7 files changed, 1285 insertions(+), 39 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/net/marvell-neta-bm.txt
 create mode 100644 drivers/net/ethernet/marvell/mvneta_bm.c
 create mode 100644 drivers/net/ethernet/marvell/mvneta_bm.h

diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt 
b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
index d0cb8693963b..73be8970815e 100644
--- a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
+++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt
@@ -18,15 +18,30 @@ Optional properties:
   "core" for core clock and "bus" for the optional bus clock.
 
 
+Optional properties (valid only for Armada XP/38x):
+
+- buffer-manager: a phandle to a buffer manager node. Please refer to
+  Documentation/devicetree/bindings/net/marvell-neta-bm.txt
+- bm,pool-long: ID of a pool, that will accept all packets of a size
+  higher than 'short' pool's threshold (if set) and up to MTU value.
+  Obligatory, when the port is supposed to use hardware
+  buffer management.
+- bm,pool-short: ID of a pool, that will be used for accepting
+  packets of a size lower than given threshold. If not set, the port
+  will use a single 'long' pool for all packets, as defined above.
+
 Example:
 
-ethernet@d007 {
+ethernet@7 {
compatible = "marvell,armada-370-neta";
-   reg = <0xd007 0x2500>;
+   reg = <0x7 0x2500>;
interrupts = <8>;
clocks = <&gate_clk 4>;
tx-csum-limit = <9800>
status = "okay";
phy 

[PATCH v5 net-next 05/10] ARM: dts: armada-xp: enable buffer manager support on Armada XP boards

[Gregory CLEMENT]

From: Marcin Wojtas 

Since mvneta driver supports using hardware buffer management (BM), in
order to use it, board files have to be adjusted accordingly. This commit
enables BM on AXP-DB and AXP-GP in same manner - because number of ports
on those boards is the same as number of possible pools, each port is
supposed to use single pool for all kind of packets.

Moreover appropriate entry is added to 'soc' node ranges, as well as "okay"
status for 'bm' and 'bm-bppi' (internal SRAM) nodes.

Signed-off-by: Marcin Wojtas 
Signed-off-by: Gregory CLEMENT 
---
 arch/arm/boot/dts/armada-xp-db.dts | 19 ++-
 arch/arm/boot/dts/armada-xp-gp.dts | 19 ++-
 2 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/armada-xp-db.dts 
b/arch/arm/boot/dts/armada-xp-db.dts
index f774101416a5..30657302305d 100644
--- a/arch/arm/boot/dts/armada-xp-db.dts
+++ b/arch/arm/boot/dts/armada-xp-db.dts
@@ -77,7 +77,8 @@
  MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10
  MBUS_ID(0x01, 0x2f) 0 0 0xf000 0x100
  MBUS_ID(0x09, 0x09) 0 0 0xf810 0x1
- MBUS_ID(0x09, 0x05) 0 0 0xf811 0x1>;
+ MBUS_ID(0x09, 0x05) 0 0 0xf811 0x1
+ MBUS_ID(0x0c, 0x04) 0 0 0xf120 0x10>;
 
devbus-bootcs {
status = "okay";
@@ -181,21 +182,33 @@
status = "okay";
phy = <&phy0>;
phy-mode = "rgmii-id";
+   buffer-manager = <&bm>;
+   bm,pool-long = <0>;
};
ethernet@74000 {
status = "okay";
phy = <&phy1>;
phy-mode = "rgmii-id";
+   buffer-manager = <&bm>;
+   bm,pool-long = <1>;
};
ethernet@3 {
status = "okay";
phy = <&phy2>;
phy-mode = "sgmii";
+   buffer-manager = <&bm>;
+   bm,pool-long = <2>;
};
ethernet@34000 {
status = "okay";
phy = <&phy3>;
phy-mode = "sgmii";
+   buffer-manager = <&bm>;
+   bm,pool-long = <3>;
+   };
+
+   bm@c {
+   status = "okay";
};
 
mvsdio@d4000 {
@@ -230,5 +243,9 @@
};
};
};
+
+   bm-bppi {
+   status = "okay";
+   };
};
 };
diff --git a/arch/arm/boot/dts/armada-xp-gp.dts 
b/arch/arm/boot/dts/armada-xp-gp.dts
index 4878d7353069..a1ded01d0c07 100644
--- a/arch/arm/boot/dts/armada-xp-gp.dts
+++ b/arch/arm/boot/dts/armada-xp-gp.dts
@@ -96,7 +96,8 @@
  MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10
  MBUS_ID(0x01, 0x2f) 0 0 0xf000 0x100
  MBUS_ID(0x09, 0x09) 0 0 0xf810 0x1
- MBUS_ID(0x09, 0x05) 0 0 0xf811 0x1>;
+ MBUS_ID(0x09, 0x05) 0 0 0xf811 0x1
+ MBUS_ID(0x0c, 0x04) 0 0 0xf120 0x10>;
 
devbus-bootcs {
status = "okay";
@@ -196,21 +197,29 @@
status = "okay";
phy = <&phy0>;
phy-mode = "qsgmii";
+   buffer-manager = <&bm>;
+   bm,pool-long = <0>;
};
ethernet@74000 {
status = "okay";
phy = <&phy1>;
phy-mode = "qsgmii";
+   buffer-manager = <&bm>;
+   bm,pool-long = <1>;
};
ethernet@3 {
status = "okay";
phy = <&phy2>;
phy-mode = "qsgmii";
+   buffer-manager = <&bm>;
+   bm,pool-long = <2>;
};
ethernet@34000 {
status = "okay";
phy = <&phy3>;
phy-mode = "qsgmii";
+   

[PATCH v5 net-next 06/10] ARM: dts: armada-xp-openblocks-ax3-4: Add BM support

[Gregory CLEMENT]

Allow Openblock AX3 using hardware buffer management with mvneta.

Signed-off-by: Gregory CLEMENT 
---
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts 
b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
index a5db17782e08..3aa29a91c7b8 100644
--- a/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
+++ b/arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts
@@ -67,7 +67,8 @@
  MBUS_ID(0x01, 0x1d) 0 0 0xfff0 0x10
  MBUS_ID(0x01, 0x2f) 0 0 0xf000 0x800
  MBUS_ID(0x09, 0x09) 0 0 0xf810 0x1
- MBUS_ID(0x09, 0x05) 0 0 0xf811 0x1>;
+ MBUS_ID(0x09, 0x05) 0 0 0xf811 0x1
+ MBUS_ID(0x0c, 0x04) 0 0 0xd120 0x10>;
 
devbus-bootcs {
status = "okay";
@@ -176,21 +177,29 @@
status = "okay";
phy = <&phy0>;
phy-mode = "sgmii";
+   buffer-manager = <&bm>;
+   bm,pool-long = <0>;
};
ethernet@74000 {
status = "okay";
phy = <&phy1>;
phy-mode = "sgmii";
+   buffer-manager = <&bm>;
+   bm,pool-long = <1>;
};
ethernet@3 {
status = "okay";
phy = <&phy2>;
phy-mode = "sgmii";
+   buffer-manager = <&bm>;
+   bm,pool-long = <2>;
};
ethernet@34000 {
status = "okay";
phy = <&phy3>;
phy-mode = "sgmii";
+   buffer-manager = <&bm>;
+   bm,pool-long = <3>;
};
i2c@11000 {
status = "okay";
@@ -219,6 +228,14 @@
usb@51000 {
status = "okay";
};
+
+   bm@c {
+   status = "okay";
+   };
+   };
+
+   bm-bppi {
+   status = "okay";
};
};
 };
-- 
2.5.0

[PATCH v5 net-next 04/10] ARM: dts: armada-xp: add buffer manager nodes

[Gregory CLEMENT]

From: Marcin Wojtas 

Armada XP network controller supports hardware buffer management (BM).
Since it is now enabled in mvneta driver, appropriate nodes can be added
to armada-xp.dtsi - for the actual common BM unit (bm@c) and its
internal SRAM (bm-bppi), which is used for indirect access to buffer
pointer ring residing in DRAM.

Pools - ports mapping, bm-bppi entry in 'soc' node's ranges and optional
parameters are supposed to be set in board files.

Signed-off-by: Marcin Wojtas 
Signed-off-by: Gregory CLEMENT 
---
 arch/arm/boot/dts/armada-xp.dtsi | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/armada-xp.dtsi b/arch/arm/boot/dts/armada-xp.dtsi
index be23196829bb..553349c07f28 100644
--- a/arch/arm/boot/dts/armada-xp.dtsi
+++ b/arch/arm/boot/dts/armada-xp.dtsi
@@ -253,6 +253,14 @@
marvell,crypto-sram-size = <0x800>;
};
 
+   bm: bm@c {
+   compatible = "marvell,armada-380-neta-bm";
+   reg = <0xc 0xac>;
+   clocks = <&gateclk 13>;
+   internal-mem = <&bm_bppi>;
+   status = "disabled";
+   };
+
xor@f0900 {
compatible = "marvell,orion-xor";
reg = <0xF0900 0x100
@@ -291,6 +299,17 @@
#size-cells = <1>;
ranges = <0 MBUS_ID(0x09, 0x05) 0 0x800>;
};
+
+   bm_bppi: bm-bppi {
+   compatible = "mmio-sram";
+   reg = ;
+   ranges = <0 MBUS_ID(0x0c, 0x04) 0 0x10>;
+   #address-cells = <1>;
+   #size-cells = <1>;
+   clocks = <&gateclk 13>;
+   no-memory-wc;
+   status = "disabled";
+   };
};
 
clocks {
-- 
2.5.0

[PATCH] dt: bindings: add new dt entry for pre calibration in qcom,ath10k.txt

[Raja Mani]

There two things done in this patch,

1) Existing device tree entry 'qcom,ath10k-calibration-data' carries
   not only calibration data, it carries board specific data too.
   So, make appropriate update in doc.

2) ipq4019 wifi needs new devie tree entry to carry calibration
   data alone (called pre cal data, it doesn't include any other info).
   Using 'qcom,ath10k-calibration-data' for ipq4019 would alter
   the purpose of it. Hence, add new device tree entry called
   'qcom,ath10k-pre-calibration-data' to carry only pre calibration data.

Signed-off-by: Raja Mani 
---

Below patches covers the corresponding changes in the ath10k driver.
It's posted separately to ath10k and linux-wireless mailing list.

  1) ath10k: pass cal data location as an argument to 
ath10k_download_cal_{file|dt}
  2) ath10k: move cal data len to hw_params
  3) ath10k: incorporate qca4019 cal data download sequence

 .../bindings/net/wireless/qcom,ath10k.txt  | 23 +++---
 1 file changed, 16 insertions(+), 7 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt 
b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
index 96aae6b..74d7f0a 100644
--- a/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
+++ b/Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
@@ -5,12 +5,18 @@ Required properties:
* "qcom,ath10k"
* "qcom,ipq4019-wifi"
 
-PCI based devices uses compatible string "qcom,ath10k" and takes only
-calibration data via "qcom,ath10k-calibration-data". Rest of the properties
-are not applicable for PCI based devices.
+PCI based devices uses compatible string "qcom,ath10k" and takes calibration
+data along with board specific data via "qcom,ath10k-calibration-data".
+Rest of the properties are not applicable for PCI based devices.
 
 AHB based devices (i.e. ipq4019) uses compatible string "qcom,ipq4019-wifi"
-and also uses most of the properties defined in this doc.
+and also uses most of the properties defined in this doc (except
+"qcom,ath10k-calibration-data"). It uses "qcom,ath10k-pre-calibration-data"
+to carry pre calibration data.
+
+In general, entry "qcom,ath10k-pre-calibration-data" and
+"qcom,ath10k-calibration-data" conflict with each other and only one
+can be provided per device.
 
 Optional properties:
 - reg: Address and length of the register set for the device.
@@ -35,8 +41,11 @@ Optional properties:
 - qcom,msi_addr: MSI interrupt address.
 - qcom,msi_base: Base value to add before writing MSI data into
MSI address register.
-- qcom,ath10k-calibration-data : calibration data as an array, the
-length can vary between hw versions
+- qcom,ath10k-calibration-data : calibration data + board specific data
+as an array, the length can vary between
+hw versions.
+- qcom,ath10k-pre-calibration-data : pre calibration data as an array,
+the length can vary between hw versions.
 
 Example (to supply the calibration data alone):
 
@@ -105,5 +114,5 @@ wifi0: wifi@a00 {
  "legacy";
qcom,msi_addr = <0x0b006040>;
qcom,msi_base = <0x40>;
-   qcom,ath10k-calibration-data = [ 01 02 03 ... ];
+   qcom,ath10k-pre-calibration-data = [ 01 02 03 ... ];
 };
-- 
1.8.1.2

Re: [PATCH 1/2] vfio, platform: add support for ACPI while detecting the reset driver

[Eric Auger]

Hi Sinan,
On 03/08/2016 04:33 PM, Sinan Kaya wrote:
> The  code is using the compatible DT string to associate a reset driver with
> the actual device itself. The compatible string does not exist on ACPI
> based systems. HID is the unique identifier for a device driver instead.
> The change allows a driver to register with DT compatible string or ACPI
> HID and then match the object with one of these conditions.
> 
> Rules for loading the reset driver are as follow:
> - ACPI HID needs match for ACPI systems
> - DT compat needs to match for OF systems
> 
> Tested-by: Eric Auger  (device tree only)
> Tested-by: Shanker Donthineni  (ACPI only)
> Signed-off-by: Sinan Kaya 
> ---
>  .../vfio/platform/reset/vfio_platform_amdxgbe.c|   4 +-
>  .../platform/reset/vfio_platform_calxedaxgmac.c|   4 +-
>  drivers/vfio/platform/vfio_platform_common.c   | 112 
> +
>  drivers/vfio/platform/vfio_platform_private.h  |  43 
>  4 files changed, 125 insertions(+), 38 deletions(-)
> 
> diff --git a/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c 
> b/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c
> index d4030d0..170dcf5 100644
> --- a/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c
> +++ b/drivers/vfio/platform/reset/vfio_platform_amdxgbe.c
> @@ -119,7 +119,9 @@ int vfio_platform_amdxgbe_reset(struct 
> vfio_platform_device *vdev)
>   return 0;
>  }
>  
> -module_vfio_reset_handler("amd,xgbe-seattle-v1a", 
> vfio_platform_amdxgbe_reset);
> +module_vfio_reset_handler("amd,xgbe-seattle-v1a", NULL,
> +   vfio_platform_amdxgbe_reset);
> +VFIO_PLATFORM_MODULE_ALIAS("amd,xgbe-seattle-v1a");
Looks the other overridden MODULE_ALIAS have a naming like
MODULE_ALIAS_something? what about MODULE_ALIAS_VFIO_PLATFORM_RESET?
not very compact but maybe closer to what it stands for.
>  
>  MODULE_VERSION("0.1");
>  MODULE_LICENSE("GPL v2");
> diff --git a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c 
> b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
> index e3d3d94..635c6e0 100644
> --- a/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
> +++ b/drivers/vfio/platform/reset/vfio_platform_calxedaxgmac.c
> @@ -77,7 +77,9 @@ int vfio_platform_calxedaxgmac_reset(struct 
> vfio_platform_device *vdev)
>   return 0;
>  }
>  
> -module_vfio_reset_handler("calxeda,hb-xgmac", 
> vfio_platform_calxedaxgmac_reset);
> +module_vfio_reset_handler("calxeda,hb-xgmac", NULL,
> +   vfio_platform_calxedaxgmac_reset);
> +VFIO_PLATFORM_MODULE_ALIAS("calxeda,hb-xgmac");
>  
>  MODULE_VERSION(DRIVER_VERSION);
>  MODULE_LICENSE("GPL v2");
> diff --git a/drivers/vfio/platform/vfio_platform_common.c 
> b/drivers/vfio/platform/vfio_platform_common.c
> index 418cdd9..c758e72 100644
> --- a/drivers/vfio/platform/vfio_platform_common.c
> +++ b/drivers/vfio/platform/vfio_platform_common.c
> @@ -13,6 +13,7 @@
>   */
>  
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -31,14 +32,22 @@ static LIST_HEAD(reset_list);
>  static DEFINE_MUTEX(driver_lock);
>  
>  static vfio_platform_reset_fn_t vfio_platform_lookup_reset(const char 
> *compat,
> - struct module **module)
> +   const char *acpihid, struct module **module)
>  {
>   struct vfio_platform_reset_node *iter;
>   vfio_platform_reset_fn_t reset_fn = NULL;
>  
>   mutex_lock(&driver_lock);
>   list_for_each_entry(iter, &reset_list, link) {
> - if (!strcmp(iter->compat, compat) &&
> + if (acpihid && iter->acpihid &&
> + !strcmp(iter->acpihid, acpihid) &&
> + try_module_get(iter->owner)) {
> + *module = iter->owner;
> + reset_fn = iter->reset;
> + break;
> + }
> + if (compat && iter->compat &&
> + !strcmp(iter->compat, compat) &&
>   try_module_get(iter->owner)) {
>   *module = iter->owner;
>   reset_fn = iter->reset;
> @@ -49,15 +58,30 @@ static vfio_platform_reset_fn_t 
> vfio_platform_lookup_reset(const char *compat,
>   return reset_fn;
>  }
>  
> -static void vfio_platform_get_reset(struct vfio_platform_device *vdev)
> +static int vfio_platform_get_reset(struct vfio_platform_device *vdev)
What is the point returning a value here? See my comment at the end.
>  {
> - vdev->reset = vfio_platform_lookup_reset(vdev->compat,
> - &vdev->reset_module);
> - if (!vdev->reset) {
> - request_module("vfio-reset:%s", vdev->compat);
> - vdev->reset = vfio_platform_lookup_reset(vdev->compat,
> -  &vdev->reset_module);
> - }
> + int rc = 0;
> +
> + vdev->reset = vfio_platform_lookup_reset(vdev->compat, vdev->acpihid,
> +  

[PATCH v5 net-next 00/10] API set for HW Buffer management

[Gregory CLEMENT]

Hi,

This is the fifth version of the API set for HW Buffer management (that was
initially submitted here:
http://thread.gmane.org/gmane.linux.kernel/2125152).

Since the forth I integrated fixes found by Dmitri Epshtein:
- as pointed by Marcin, a filed witth the size of the buffer of the
  pool was added. It then allow to fix some misused size in the
  mvneta_bm code when using the new framework.

I also added a new patch from Marcin for sram allowing to require
non-bufferable access to the memory. It was needed for the hardwre
buffer management of the mvneta.

Finally, I fixed the build issue notified by the 0-day builder when
building the drivers as module.

For the record in the previous versions I made the following changes:
v3 -> v4
- Fix build issue when HWBM is not selected

v2 -> v3
- Make a HWBM and a SWBM version of the mvneta_rx() function in order
  to reduce the the conditional code. Kept a condition inside the
  mvneta_poll because specializing this function would have means
  duplicating 95% of the code.

- Put back the register_netdev() call at the end of the mvneta_probe()
  function. In order to have a unique ID for each port, just used a
  global variable in the driver.

- Added a fix from Marcin in the "net: mvneta: bm: add support for
  hardware buffer management" patch: "when dropping packets, only
  buffer pointers passed from BM to descriptors have to be returned to
  the pool. In submitted version after closing the port and
  mvneta_rxq_deinit(), it was very likely that a lot of fake buffers
  are added to the pool, because all descriptors took part in
  iteration."

- Removed the select MVNETA_BM from the Kconfig, it will let the user
  the choice to use not use it if they want.

v1 -> v2
- The hardware buffer management helpers are no more built by default
  and now depend on a hidden config symbol which has to be selected
  by the driver if needed
- The hwbm_pool_refill() and hwbm_pool_add() now receive a gfp_t as
  argument allowing the caller to specify the flag it needs.
- buf_num is now tested to ensure there is no wrapping
- A spinlock has been added to protect the hwbm_pool_add() function in
  SMP or irq context.
- used pr_warn instead of pr_debug in case of errors.
- fixed the mvneta implementation by returning the buffer to the pool
  at various place instead of ignoring it.
- Squashed "bus: mvenus-mbus: Fix size test for
   mvebu_mbus_get_dram_win_info" into bus: mvebu-mbus: provide api for
   obtaining IO and DRAM window information.
- Added my signed-otf-by on all the patches as submitter of the series.
- Renamed the dts patches with the pattern "ARM: dts: platform:"
- Removed the patch "ARM: mvebu: enable SRAM support in
  mvebu_v7_defconfig" of this series and already applied it
- Modified the order of the patches.

In order to ease the test the branch mvneta-BM-framework-v5 is
available at g...@github.com:MISL-EBU-System-SW/mainline-public.git.

Thanks,

Gregory


Gregory CLEMENT (3):
  ARM: dts: armada-xp-openblocks-ax3-4: Add BM support
  net: add a hardware buffer management helper API
  net: mvneta: Use the new hwbm framework

Marcin Wojtas (7):
  misc: sram: add optional ioremap without write combining
  ARM: dts: armada-38x: add buffer manager nodes
  ARM: dts: armada-38x: enable buffer manager support on Armada 38x
boards
  ARM: dts: armada-xp: add buffer manager nodes
  ARM: dts: armada-xp: enable buffer manager support on Armada XP boards
  bus: mvebu-mbus: provide api for obtaining IO and DRAM window
information
  net: mvneta: bm: add support for hardware buffer management

 .../bindings/net/marvell-armada-370-neta.txt   |  19 +-
 .../devicetree/bindings/net/marvell-neta-bm.txt|  49 ++
 Documentation/devicetree/bindings/sram/sram.txt|   5 +
 arch/arm/boot/dts/armada-385-db-ap.dts |  20 +-
 arch/arm/boot/dts/armada-388-clearfog.dts  |   6 +
 arch/arm/boot/dts/armada-388-db.dts|  17 +-
 arch/arm/boot/dts/armada-388-gp.dts|  17 +-
 .../arm/boot/dts/armada-38x-solidrun-microsom.dtsi |  15 +-
 arch/arm/boot/dts/armada-38x.dtsi  |  19 +
 arch/arm/boot/dts/armada-xp-db.dts |  19 +-
 arch/arm/boot/dts/armada-xp-gp.dts |  19 +-
 arch/arm/boot/dts/armada-xp-openblocks-ax3-4.dts   |  19 +-
 arch/arm/boot/dts/armada-xp.dtsi   |  19 +
 drivers/bus/mvebu-mbus.c   |  52 +++
 drivers/misc/sram.c|   5 +-
 drivers/net/ethernet/marvell/Kconfig   |  14 +
 drivers/net/ethernet/marvell/Makefile  |   1 +
 drivers/net/ethernet/marvell/mvneta.c  | 509 +++--
 drivers/net/ethernet/marvell/mvneta_bm.c   | 487 
 drivers/net/ethernet/marvell/mvneta_bm.h   | 182 
 include/linux/mbus.h   |   3 +
 include/net/hwbm.h |  28 ++
 net/Kconfig

[PATCH v5 net-next 10/10] net: mvneta: Use the new hwbm framework

[Gregory CLEMENT]

Now that the hardware buffer management framework had been introduced,
let's use it.

Signed-off-by: Gregory CLEMENT 
---
 drivers/net/ethernet/marvell/Kconfig |   1 +
 drivers/net/ethernet/marvell/mvneta.c|  18 +++--
 drivers/net/ethernet/marvell/mvneta_bm.c | 125 ---
 drivers/net/ethernet/marvell/mvneta_bm.h |  17 ++---
 4 files changed, 49 insertions(+), 112 deletions(-)

diff --git a/drivers/net/ethernet/marvell/Kconfig 
b/drivers/net/ethernet/marvell/Kconfig
index ac6605c62f46..62d80fddbe34 100644
--- a/drivers/net/ethernet/marvell/Kconfig
+++ b/drivers/net/ethernet/marvell/Kconfig
@@ -43,6 +43,7 @@ config MVMDIO
 config MVNETA_BM
tristate "Marvell Armada 38x/XP network interface BM support"
depends on MVNETA
+   select HWBM
---help---
  This driver supports auxiliary block of the network
  interface units in the Marvell ARMADA XP and ARMADA 38x SoC
diff --git a/drivers/net/ethernet/marvell/mvneta.c 
b/drivers/net/ethernet/marvell/mvneta.c
index ade5b0b961d3..daf94a82c9f5 100644
--- a/drivers/net/ethernet/marvell/mvneta.c
+++ b/drivers/net/ethernet/marvell/mvneta.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "mvneta_bm.h"
 #include 
 #include 
@@ -1021,11 +1022,12 @@ static int mvneta_bm_port_init(struct platform_device 
*pdev,
 static void mvneta_bm_update_mtu(struct mvneta_port *pp, int mtu)
 {
struct mvneta_bm_pool *bm_pool = pp->pool_long;
+   struct hwbm_pool *hwbm_pool = &bm_pool->hwbm_pool;
int num;
 
/* Release all buffers from long pool */
mvneta_bm_bufs_free(pp->bm_priv, bm_pool, 1 << pp->id);
-   if (bm_pool->buf_num) {
+   if (hwbm_pool->buf_num) {
WARN(1, "cannot free all buffers in pool %d\n",
 bm_pool->id);
goto bm_mtu_err;
@@ -1033,14 +1035,14 @@ static void mvneta_bm_update_mtu(struct mvneta_port 
*pp, int mtu)
 
bm_pool->pkt_size = MVNETA_RX_PKT_SIZE(mtu);
bm_pool->buf_size = MVNETA_RX_BUF_SIZE(bm_pool->pkt_size);
-   bm_pool->frag_size = SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) +
- SKB_DATA_ALIGN(MVNETA_RX_BUF_SIZE(bm_pool->pkt_size));
+   hwbm_pool->frag_size = SKB_DATA_ALIGN(sizeof(struct skb_shared_info)) +
+   SKB_DATA_ALIGN(MVNETA_RX_BUF_SIZE(bm_pool->pkt_size));
 
/* Fill entire long pool */
-   num = mvneta_bm_bufs_add(pp->bm_priv, bm_pool, bm_pool->size);
-   if (num != bm_pool->size) {
+   num = hwbm_pool_add(hwbm_pool, hwbm_pool->size, GFP_ATOMIC);
+   if (num != hwbm_pool->size) {
WARN(1, "pool %d: %d of %d allocated\n",
-bm_pool->id, num, bm_pool->size);
+bm_pool->id, num, hwbm_pool->size);
goto bm_mtu_err;
}
mvneta_bm_pool_bufsize_set(pp, bm_pool->buf_size, bm_pool->id);
@@ -2028,14 +2030,14 @@ err_drop_frame:
}
 
/* Refill processing */
-   err = mvneta_bm_pool_refill(pp->bm_priv, bm_pool);
+   err = hwbm_pool_refill(&bm_pool->hwbm_pool, GFP_ATOMIC);
if (err) {
netdev_err(dev, "Linux processing - Can't refill\n");
rxq->missed++;
goto err_drop_frame_ret_pool;
}
 
-   frag_size = bm_pool->frag_size;
+   frag_size = bm_pool->hwbm_pool.frag_size;
 
skb = build_skb(data, frag_size > PAGE_SIZE ? 0 : frag_size);
 
diff --git a/drivers/net/ethernet/marvell/mvneta_bm.c 
b/drivers/net/ethernet/marvell/mvneta_bm.c
index 8c968e7d2d8f..01fccec632ec 100644
--- a/drivers/net/ethernet/marvell/mvneta_bm.c
+++ b/drivers/net/ethernet/marvell/mvneta_bm.c
@@ -10,16 +10,17 @@
  * warranty of any kind, whether express or implied.
  */
 
-#include 
+#include 
 #include 
-#include 
-#include 
-#include 
+#include 
+#include 
 #include 
 #include 
-#include 
+#include 
 #include 
-#include 
+#include 
+#include 
+#include 
 #include "mvneta_bm.h"
 
 #define MVNETA_BM_DRIVER_NAME "mvneta_bm"
@@ -88,17 +89,13 @@ static void mvneta_bm_pool_target_set(struct mvneta_bm 
*priv, int pool_id,
mvneta_bm_write(priv, MVNETA_BM_XBAR_POOL_REG(pool_id), val);
 }
 
-/* Allocate skb for BM pool */
-void *mvneta_buf_alloc(struct mvneta_bm *priv, struct mvneta_bm_pool *bm_pool,
-  dma_addr_t *buf_phys_addr)
+int mvneta_bm_construct(struct hwbm_pool *hwbm_pool, void *buf)
 {
-   void *buf;
+   struct mvneta_bm_pool *bm_pool =
+   (struct mvneta_bm_pool *)hwbm_pool->priv;
+   struct mvneta_bm *priv = bm_pool->priv;
dma_addr_t phys_addr;
 
-   buf = mvneta_frag_alloc(bm_pool->frag_size);
-   if (!buf)
-   return NULL;
-
/* In order to update buf_cookie field of RX descriptor properly,
 * BM hardware expects buf virtual address to be placed in

[PATCH v5 net-next 01/10] misc: sram: add optional ioremap without write combining

[Gregory CLEMENT]

From: Marcin Wojtas 

Some SRAM users may require non-bufferable access to the memory, which is
impossible, because devm_ioremap_wc() is used for setting sram->virt_base.

This commit adds optional flag 'no-memory-wc', which allow to choose remap
method, using DT property. Documentation is updated accordingly.

Signed-off-by: Marcin Wojtas 
---
 Documentation/devicetree/bindings/sram/sram.txt | 5 +
 drivers/misc/sram.c | 5 -
 2 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/sram/sram.txt 
b/Documentation/devicetree/bindings/sram/sram.txt
index 42ee9438b771..227e3a341af1 100644
--- a/Documentation/devicetree/bindings/sram/sram.txt
+++ b/Documentation/devicetree/bindings/sram/sram.txt
@@ -25,6 +25,11 @@ Required properties in the sram node:
 - ranges : standard definition, should translate from local addresses
within the sram to bus addresses
 
+Optional properties in the sram node:
+
+- no-memory-wc : the flag indicating, that SRAM memory region has not to
+ be remapped as write combining. WC is used by default.
+
 Required properties in the area nodes:
 
 - reg : iomem address range, relative to the SRAM range
diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
index 736dae715dbf..69cdabea9c03 100644
--- a/drivers/misc/sram.c
+++ b/drivers/misc/sram.c
@@ -360,7 +360,10 @@ static int sram_probe(struct platform_device *pdev)
return -EBUSY;
}
 
-   sram->virt_base = devm_ioremap_wc(sram->dev, res->start, size);
+   if (of_property_read_bool(pdev->dev.of_node, "no-memory-wc"))
+   sram->virt_base = devm_ioremap(sram->dev, res->start, size);
+   else
+   sram->virt_base = devm_ioremap_wc(sram->dev, res->start, size);
if (IS_ERR(sram->virt_base))
return PTR_ERR(sram->virt_base);
 
-- 
2.5.0

[PATCH RESEND] mfd: arizona: Fix lockdep recursion warning on set_irq_wake

[Charles Keepax]

Lockdep explicitly sets all the irq_desc locks as a single lock-class,
which causes a "possible recursive locking detected" warning when we
attempt to propagate the IRQ wake to our parent IRQ in
arizona_irq_set_wake. Although this appears to be a false positive
because an IRQ is unlikely to be its own parent, this was clearly
intentionally prohibited.

To avoid this lockdep warning, take a cue from the regmap-irq system,
and add bus lock callbacks on the IRQ chip and propagate the wake in
the bus unlock which will happen after the desc lock has been released
and thus avoid the issue.

Signed-off-by: Charles Keepax 
---
 drivers/mfd/arizona-irq.c| 35 ++-
 include/linux/mfd/arizona/core.h |  3 +++
 2 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/arizona-irq.c b/drivers/mfd/arizona-irq.c
index 5fef014..6497a65 100644
--- a/drivers/mfd/arizona-irq.c
+++ b/drivers/mfd/arizona-irq.c
@@ -154,17 +154,48 @@ static void arizona_irq_disable(struct irq_data *data)
 {
 }
 
+static void arizona_irq_lock(struct irq_data *data)
+{
+   struct arizona *arizona = irq_data_get_irq_chip_data(data);
+
+   mutex_lock(&arizona->irq_lock);
+}
+
+static void arizona_irq_sync_unlock(struct irq_data *data)
+{
+   struct arizona *arizona = irq_data_get_irq_chip_data(data);
+   int i;
+
+   if (arizona->pending_wake_count < 0)
+   for (i = arizona->pending_wake_count; i < 0; i++)
+   irq_set_irq_wake(arizona->irq, 0);
+   else if (arizona->pending_wake_count > 0)
+   for (i = 0; i < arizona->pending_wake_count; i++)
+   irq_set_irq_wake(arizona->irq, 1);
+
+   arizona->pending_wake_count = 0;
+
+   mutex_unlock(&arizona->irq_lock);
+}
+
 static int arizona_irq_set_wake(struct irq_data *data, unsigned int on)
 {
struct arizona *arizona = irq_data_get_irq_chip_data(data);
 
-   return irq_set_irq_wake(arizona->irq, on);
+   if (on)
+   arizona->pending_wake_count++;
+   else
+   arizona->pending_wake_count--;
+
+   return 0;
 }
 
 static struct irq_chip arizona_irq_chip = {
.name   = "arizona",
.irq_disable= arizona_irq_disable,
.irq_enable = arizona_irq_enable,
+   .irq_bus_lock   = arizona_irq_lock,
+   .irq_bus_sync_unlock= arizona_irq_sync_unlock,
.irq_set_wake   = arizona_irq_set_wake,
 };
 
@@ -193,6 +224,8 @@ int arizona_irq_init(struct arizona *arizona)
const struct regmap_irq_chip *aod, *irq;
struct irq_data *irq_data;
 
+   mutex_init(&arizona->irq_lock);
+
arizona->ctrlif_error = true;
 
switch (arizona->type) {
diff --git a/include/linux/mfd/arizona/core.h b/include/linux/mfd/arizona/core.h
index d55a422..a0374ea 100644
--- a/include/linux/mfd/arizona/core.h
+++ b/include/linux/mfd/arizona/core.h
@@ -148,6 +148,9 @@ struct arizona {
uint16_t dac_comp_coeff;
uint8_t dac_comp_enabled;
struct mutex dac_comp_lock;
+
+   int pending_wake_count;
+   struct mutex irq_lock;
 };
 
 int arizona_clk32k_enable(struct arizona *arizona);
-- 
2.1.4

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

[Roman Kagan]

On Wed, Mar 09, 2016 at 07:39:18PM +0200, Michael S. Tsirkin wrote:
> On Wed, Mar 09, 2016 at 08:04:39PM +0300, Roman Kagan wrote:
> > On Wed, Mar 09, 2016 at 05:41:39PM +0200, Michael S. Tsirkin wrote:
> > > On Wed, Mar 09, 2016 at 05:28:54PM +0300, Roman Kagan wrote:
> > > > For (1) I've been trying to make a point that skipping clean pages is
> > > > much more likely to result in noticable benefit than free pages only.
> > > 
> > > I guess when you say clean you mean zero?
> > 
> > No I meant clean, i.e. those that could be evicted from RAM without
> > causing I/O.
> 
> They must be migrated unless guest actually evicts them.

If the balloon is inflated the guest will.

> It's not at all clear to me that it's always preferable
> to drop all clean pages from pagecache. It is clearly is
> going to slow the guest down significantly.

That's a matter for optimization.  The current value for
/proc/meminfo:MemAvailable (which is being proposed as a member of
balloon stats, too) is a conservative estimate which will probably cover
a good deal of cases.

> > I must be missing something obvious, but how is that different from
> > inflating and then immediately deflating the balloon?
> 
> It's exactly the same except
> - we do not initiate this from host - it's guest doing
>   things for its own reasons
> - a bit less guest/host interaction this way

I don't quite understand why you need to deflate the balloon until the
VM is on the destination host.  deflate_on_oom will do it if the guest
is really tight on memory; otherwise there appears to be no reason for
it.  But then inflation followed immediately by deflation doubles the
guest/host interactions rather than reduces them, no?

> > it's just the granularity that makes things slow and
> > stands in the way.
> 
> So we could request a specific page size/alignment from guest.
> Send guest request to give us memory in aligned units of 2Mbytes,
> and then host can treat each of these as a single huge page.

I'd guess just coalescing contiguous pages would already speed things
up.  I'll try to find some time to experiment with it.

Roman.

Re: [RFC 0/12] introduce down_write_killable for rw_semaphore

[Ingo Molnar]

* Michal Hocko  wrote:

> > > Why? Each syscall already is killable as the task might be killed by the 
> > > OOM 
> > > killer.
> > 
> > Not all syscalls are interruptible - for example sys_sync() isn't:
> 
> I guess we are talking past each other. [...]

Heh, you are being polite, I think what happened is that I was being dense and 
didn't understand your point:

> [...] What I meant was that while all syscalls are allowed to not return to 
> the 
> userspace because the task might get killed but not all of them accept to get 
> interrupted by a signal and return with EINTR. None of the man page of mmap, 
> mremap, mlock, mprotect list EINTR as a possibility so I would be really 
> afraid 
> of returning an unexpected error code.

Indeed.

> Does this make more sense now?

It does!

Thanks,

Ingo

Re: [PATCH] [Cleanup] x86: signal: unify the sigaltstack check with other arches

[Ingo Molnar]

* Andy Lutomirski  wrote:

> On Tue, Mar 8, 2016 at 8:20 AM, Ingo Molnar  wrote:
> >
> > * Stas Sergeev  wrote:
> >
> >> 25.02.2016 11:25, Ingo Molnar пишет:
> >> >
> >> > * Stas Sergeev  wrote:
> >> >
> >> >> Currently x86's get_sigframe() checks for "current->sas_ss_size"
> >> >> to determine whether there is a need to switch to sigaltstack.
> >> >> The common practice used by all other arches is to check for
> >> >> sas_ss_flags(sp) == 0
> >> >>
> >> >> This patch makes the code consistent with other arches.
> >> >> The slight complexity of the patch is added by the optimization on
> >> >> !sigstack check that was requested by Andy Lutomirski: 
> >> >> sas_ss_flags(sp)==0
> >> >> already implies that we are not on a sigstack, so the code is shuffled
> >> >> to avoid the duplicate checking.
> >> >
> >> > So this changelog is missing an analysis about what effect this change 
> >> > will have
> >> > on applications. Can any type of user-space code see a change in 
> >> > behavior? If yes,
> >> > what will happen and is that effect desirable?
> >> This is a clean-up, and as such, there is no visible effect.
> >> If there is - it is a bug.
> >> The purpose of this patch is only to unify the x86 code with
> >> what all the other arches do. It was initially the part of the
> >> rejected series, but now it is just a clean-up.
> >
> > Ok, so AFAICS the relevant change is:
> >
> > -   if (current->sas_ss_size)
> > -   sp = current->sas_ss_sp + current->sas_ss_size;
> > +   if (sas_ss_flags(sp) == 0)
> > +   sp = current->sas_ss_sp + current->sas_ss_size;
> >
> > and since sas_ss_flags() is defined as:
> >
> > static inline int sas_ss_flags(unsigned long sp)
> > {
> > if (!current->sas_ss_size)
> > return SS_DISABLE;
> >
> > return on_sig_stack(sp) ? SS_ONSTACK : 0;
> > }
> >
> > sas_ss_flags() returns 0 iff current->sas_ss_size && !on_sig_stack().
> >
> > But we already have on_sig_stack(sp) calculated. Why not write that as:
> >
> > +   if (current->sas_ss_size && !onsigstack)
> > +   sp = current->sas_ss_sp + current->sas_ss_size;
> >
> > and since we check '!onsigstack' in both branches, we might as well factor 
> > it out
> > into a single condition ... and arrive to the exact code that we began with.
> 
> ISTM it's silly for us to be unconditionally computing onsigstack.
> We're doing it because we need it later for this:
> 
> /*
>  * If we are on the alternate signal stack and would overflow it, 
> don't.
>  * Return an always-bogus address instead so we will die with SIGSEGV.
>  */
> if (onsigstack && !likely(on_sig_stack(sp)))
> return (void __user *)-1L;
> 
> This seems basically useless to me.  Sure, it's nice to send SIGSEGV
> if we overflow due to signal delivery.  But we're almost as likely to
> overflow in the signal handler as we are to overflow during delivery,
> and we don't even try to catch that.

Ok, I was just put off by the code size difference - but no strong opinion from 
me, I'd certainly be fine with (as a first step) harmonizing the implementation 
with other architectures. I withdraw my objection.

> Anyway, I think we should make two changes to the sig_on_stack thing:
> 
> 1. If SS_AUTODISARM, then we're not on the stack, regardless of what sp says.
> 
> 2. If !user_64bit_mode(regs) && (regs->ss & 0x4), then we're not on
> the signal stack.  This will happen if we're running on an LDT stack
> and we coincidentally have the ESP part of SS:ESP matching the signal
> stack.
> 
> In general, the existing design is crap and it should always have
> worked the way that Stas is proposing with SS_AUTODISARM.

Ok, no objections here either.

Thanks,

Ingo

Re: Kernel docs: muddying the waters a bit

[Jani Nikula]

TL;DR? Skip to the last paragraph.

On Wed, 09 Mar 2016, Mauro Carvalho Chehab  wrote:
> I guess the conversion to asciidoc format is now in good shape,
> at least to demonstrate that it is possible to use this format for the
> media docbook. Still, there are lots of broken references.

Getting references right with asciidoc is a big problem in the
kernel-doc side. As I wrote before, the proofs of concept only worked
because everything was processed as one big file (via includes). The
Asciidoctor inter-document references won't help, because we won't know
the target document name while processing kernel-doc.

Sphinx is massively better at handling cross references for
kernel-doc. We can use domains (C language) and roles (e.g. functions,
types, etc.) for the references, which provide kind of
namespaces. Sphinx warns for referencing non-existing targets, but
doesn't generate broken links in the result like Asciidoctor does.

For example, in the documentation for a function that has struct foo as
parameter or return type, a cross reference to struct foo is added
automagically, but only if documentation for struct foo actually
exists. In Asciidoctor, we would have to blindly generate the references
ourselves, and try to resolve broken links ourselves by somehow
post-processing the result.

> Yet, from my side, if we're willing to get rid of DocBook, then
> Asciidoctor seems to be the *only* alternative so far to parse the
> complex media documents.

I think you mean, "get rid of DocBook as source format", not altogether?
I'm yet to be convinved we could rely on Asciidoctor's native formats.

---

Mauro, I truly appreciate your efforts at evaluating both
alternatives. I also appreciate Dan's inputs on Asciidoctor.

Despite your evaluation that Asciidoctor is the only alternative for
media documents, it is my opinion that we should go with Sphinx.

It's an opinion, it's subjective, it's from my perspective, especially
from the kernel-doc POV, so please don't take it as a slap in the face
after all the work you've done. With that out of the way, here's why.

For starters, Jon's Sphinx proof-of-concept at
http://static.lwn.net/kerneldoc/ is pretty amazing. It's beautiful and
usable. Cross references work, there are no broken links (I hacked a bit
more on kernel-doc and it gets even better). There's embedded search
(and if this gets exported to https://readthedocs.org/ the search is
even better). The API documentation is sensible and the headings aren't
mixed up with other headings. It's all there. It's what we've been
looking for.

The toolchain gets faster, easier to debug and simplified a lot with
DocBook out of the equation completely. Sphinx itself is stable, widely
available, and well documented. IMO there's sufficient native output
format support. There are plenty of really nice extensions
available. There's a possibility of doing kernel-doc as an extension in
the future (either by calling current kernel-doc from the extension or
by rewriting it).

Dan keeps bringing up the active community in Asciidoctor, and how
they're fixing things up as we speak... which is great, but Sphinx is
here now, packaged and shipping in distros ready to use. It seems that
of the two, an Asciidoctor based toolchain is currently more in need of
hacking and extending to meet our needs. Which brings us to the
implementation language, Python vs. Ruby.

I won't make the mistake of comparing the relative merits of the
languages, but I'll boldly claim the set of kernel developers who know
Python is likely larger than the set of kernel developers who know Ruby
[citation needed]. AFAICT there are no Ruby tools in the kernel tree,
but there is a bunch of Python. My own very limited and subjective
experience with other tools around the kernel is that Python is much
more popular than Ruby. So my claim here is that we're in a better
position to hack on Sphinx extensions ourselves than Asciidoctor.

My conclusion is that Sphinx covers the vast majority of the needs of
our documentation producers and consumers, in an amazing way, out of the
box, better than Asciidoctor.

Which brings us to the minority and the parts where Sphinx falls short,
media documentation in particular. It's complex documentation, with very
specific requirements on the output, especially that many things remain
exactly as they are now. It also feels like the target is more to have
standalone media documentation, and not so much to be aligned with and
be part of the rest of the kernel documentation.

I want to question the need to have all kernel documentation use tools
that meet the strict requirements of the outlier, when there's a better
alternative for the vast majority of the documentation. Especially when
Asciidoctor isn't a ready solution for media documentation either.

In summary, my proposal is to go with Sphinx, leave media docs as
DocBook for now, and see if and how they can be converted to
Sphinx/reStructuredText later on when we have everything else in
pla

Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data

[Vincent Guittot]

On 10 March 2016 at 17:07, Peter Zijlstra  wrote:
> On Thu, Mar 10, 2016 at 10:44:21AM +0700, Vincent Guittot wrote:
>> We have the arch_scale_freq_capacity function that is arch dependent
>> and can be used to merge the 2 formula that were described by peter
>> above.
>> By default, arch_scale_freq_capacity return SCHED_CAPACITY_SCALE which
>> is max capacity
>> but when arch_scale_freq_capacity is defined by an architecture,
>
>> arch_scale_freq_capacity returns current_freq * max_capacity/max_freq
>
> However, current_freq is a very fluid thing, it might (and will) change
> very rapidly on some platforms.
>
> This is the same point I made earlier, you cannot try and divide out
> current_freq from the invariant measure.
>
>> so can't we use arch_scale_freq in your formula ? Taking your formula
>> above it becomes:
>> next_freq = 1.25 * current_freq * util / arch_scale_freq_capacity()
>
> No, that cannot work, nor makes any sense, per the above.
>
>> With invariance feature, we have:
>>
>>   next_freq = 1.25 * current_freq * util / 
>> (current_freq*max_capacity/max_freq)
>> = 1.25 * util * max_freq / max
>>
>> which is the formula that has to be used with frequency invariant
>> utilization.
>
> Wrong, you cannot talk about current_freq in the invariant case.
>
>> May be we can pass arch_scale_freq_capacity value instead of max one
>> as a parameter of update_util function prototype
>
> No, since its a compile time thing, we can simply do:
>
> #ifdef arch_scale_freq_capacity
> next_freq = (1 + 1/n) * max_freq * (util / max)
> #else
> next_freq = (1 + 1/n) * current_freq * (util_raw / max)
> #endif

selecting formula at compilation is clearly better. I wrongly thought
that it can't be accepted as a solution.

Re: [PATCH]x86/cpufeatures.h: Enumerate A Few New AVX-512 Features

[Ingo Molnar]

* Fenghua Yu  wrote:

> From: Fenghua Yu 
> 
> A few new AVX-512 instruction groups/features are added in cpufeatures.h
> for enuermation: AVX512DQ, AVX512BW, and AVX512VL.
> 
> The specification for latest AVX-512 including the features can be found at
> https://software.intel.com/sites/default/files/managed/07/b7/319433-023.pdf
> 
> Signed-off-by: Fenghua Yu 
> ---
>  arch/x86/include/asm/cpufeature.h | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/x86/include/asm/cpufeature.h 
> b/arch/x86/include/asm/cpufeature.h
> index 7ad8c94..71a5cc4 100644
> --- a/arch/x86/include/asm/cpufeature.h
> +++ b/arch/x86/include/asm/cpufeature.h
> @@ -219,6 +219,7 @@
>  #define X86_FEATURE_CQM  ( 9*32+12) /* Cache QoS Monitoring */
>  #define X86_FEATURE_MPX  ( 9*32+14) /* Memory Protection 
> Extension */
>  #define X86_FEATURE_AVX512F  ( 9*32+16) /* AVX-512 Foundation */
> +#define X86_FEATURE_AVX512DQ ( 9*32+17) /* AVX-512 DQ Instructions */
>  #define X86_FEATURE_RDSEED   ( 9*32+18) /* The RDSEED instruction */
>  #define X86_FEATURE_ADX  ( 9*32+19) /* The ADCX and ADOX 
> instructions */
>  #define X86_FEATURE_SMAP ( 9*32+20) /* Supervisor Mode Access Prevention 
> */
> @@ -229,6 +230,8 @@
>  #define X86_FEATURE_AVX512ER ( 9*32+27) /* AVX-512 Exponential and 
> Reciprocal */
>  #define X86_FEATURE_AVX512CD ( 9*32+28) /* AVX-512 Conflict Detection */
>  #define X86_FEATURE_SHA_NI   ( 9*32+29) /* SHA1/SHA256 Instruction 
> Extensions */
> +#define X86_FEATURE_AVX512BW ( 9*32+30) /* AVX-512 BW Instructions */
> +#define X86_FEATURE_AVX512VL ( 9*32+31) /* AVX-512 Vector Lengths */
>  
>  /* Extended state features, CPUID level 0x000d:1 (eax), word 10 */
>  #define X86_FEATURE_XSAVEOPT (10*32+ 0) /* XSAVEOPT */

In the latest x86 tree these defines are in cpufeatures.h, not cpufeature.h.

Thanks,

Ingo

Re: [PATCH 6/6] cpufreq: schedutil: New governor based on scheduler utilization data

[Peter Zijlstra]

On Thu, Mar 10, 2016 at 05:23:54PM +0700, Vincent Guittot wrote:

> > No, since its a compile time thing, we can simply do:
> >
> > #ifdef arch_scale_freq_capacity
> > next_freq = (1 + 1/n) * max_freq * (util / max)
> > #else
> > next_freq = (1 + 1/n) * current_freq * (util_raw / max)
> > #endif
> 
> selecting formula at compilation is clearly better. I wrongly thought that
> it can't be accepted as a solution.

Well, its bound to get more 'interesting' since I forse implementations
not always actually doing the invariant thing.

Take for example the thing I send:

  lkml.kernel.org/r/20160303162829.gb6...@twins.programming.kicks-ass.net

it both shows why you cannot talk about current_freq but also that the
above needs a little more help (for the !X86_FEATURE_APERFMPERF case).

But the !arch_scale_freq_capacity case should indeed be that simple.

[PATCH] mmc: sdhci-of-at91: fix wakeup issue when using runtime pm

[Ludovic Desroches]

It was impossible to wake-up on card detect event because when sdhci
controller is runtime suspend, it is assumed that all the clocks are
disabled so we can't get irqs.
If the device is removable and there is no gpio to manage the card
detection then card detection polling is used.

Signed-off-by: Ludovic Desroches 
---

Hi Ulf, Adrian,

Following the discussion, I need to fix my issue. I think we could both agree
on this patch that I see more as temporary workaround.

I will try to change the muxing of the card detect pio in order to no more
use the sdhci controller to manage it but a gpio. If it do not work then
I may send another patch in the spirit of the previous one (keeping one clock
enabled and not calling sdhci_runtime_suspend_host()).

Regards

 drivers/mmc/host/sdhci-of-at91.c | 16 
 1 file changed, 16 insertions(+)

diff --git a/drivers/mmc/host/sdhci-of-at91.c b/drivers/mmc/host/sdhci-of-at91.c
index 35c02fc..dac8508 100644
--- a/drivers/mmc/host/sdhci-of-at91.c
+++ b/drivers/mmc/host/sdhci-of-at91.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -204,6 +205,21 @@ static int sdhci_at91_probe(struct platform_device *pdev)
if (ret)
goto pm_runtime_disable;
 
+   /*
+* When calling sdhci_runtime_suspend_host(), the sdhci layer makes
+* the assumption that all the clocks of the controller are disabled.
+* It means we can't get irq from it when it is runtime suspended.
+* For that reason, it is not planned to wake-up on a card detect irq
+* from the controller.
+* If we want to use runtime PM and to be able to wake-up on card
+* insertion, we have to use a GPIO for the card detection or we can
+* use polling for the card detection. Be aware that using polling
+* will resume/suspend the controller between each attempt.
+*/
+   if (!(host->mmc->caps & MMC_CAP_NONREMOVABLE) &&
+   IS_ERR_VALUE(mmc_gpio_get_cd(host->mmc)))
+   host->mmc->caps |= MMC_CAP_NEEDS_POLL;
+
pm_runtime_put_autosuspend(&pdev->dev);
 
return 0;
-- 
2.5.0

Re: [PATCHSET 0/7] perf tools: Fix and cleanups for hierarchy mode (v2)

[Jiri Olsa]

On Wed, Mar 09, 2016 at 10:46:55PM +0900, Namhyung Kim wrote:
> Hello,
> 
> These are filter-related fixes and cleanups in the new hierarchy mode.
> Currently perf misbehaves in hierarchy mode when filter is applied.
> For example, it sometimes misses some (upper level) entries in the
> output or shows incorrect (very large) overhead.
> 
>  * Changes in v2)
>   - update hist_entry__filter() to check multiple filters properly
>   - add missing runtime filter check when adding hierarchy entries
>   - recalculate total period using top-level entries  (Jiri)
>   - add more comment
>   
> 
> Before:
> 
>   $ perf report --hierarchy -s 'cpu,{dso,comm}' --comms swapper --stdio
>   ...
>   #Overhead  CPU / Shared Object+Command
>   # ...  ...
>   #
>  13.79% [kernel.vmlinux]  swapper
>   31.71% 000
>  13.80% [kernel.vmlinux]  swapper
>   0.43% [e1000e]  swapper
>  11.89% [kernel.vmlinux]  swapper
>   9.18% [kernel.vmlinux]  swapper
> 
> After:
> 
>   #Overhead  CPU / Shared Object+Command
>   # ...  ...
>   #
>   33.09% 003
>  13.79% [kernel.vmlinux]  swapper
>   31.71% 000
>  13.80% [kernel.vmlinux]  swapper
>   0.43% [e1000e]  swapper
>   21.90% 002
>  11.89% [kernel.vmlinux]  swapper
>   13.30% 001
>   9.18% [kernel.vmlinux]  swapper
> 
> 
> It's also available on 'perf/hierarchy-filter-v2' branch in my tree
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/namhyung/linux-perf.git
> 
> any feedback are welcome.

looks good to me, the 'F' toggle shows sane number for me now

Acked-and-tested-by: Jiri Olsa 

thanks,
jirka

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

[Ian Abbott]

On 10/03/16 06:52, Ravishankar Karkala Mallikarjunayya wrote:

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(-)


Thanks!

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-

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

[Ian Abbott]

On 10/03/16 06:52, Ravishankar Karkala Mallikarjunayya wrote:

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;
}




Thanks!

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-

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

[Ian Abbott]

On 10/03/16 06:52, Ravishankar Karkala Mallikarjunayya wrote:

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(-)


Thanks!

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-

Re: [PATCH 2/3] perf/x86/pebs: add workaround for broken OVFL status on HSW

[Peter Zijlstra]

On Wed, Mar 09, 2016 at 09:40:07AM -0800, Stephane Eranian wrote:
> With your queue.tip perf/core branch, I run into another problem.
> I am monitoring with 2 PEBS events and I have the NMI watchdog enabled.
> 
> I see non-EXACT PEBS records again, despite my change (which is in).
> I tracked it down to the following issue after the testing of bit 62:
> 
> [31137.273061] CPU71 status=0x20001 orig_status=0x20001 bit62=0
> 
> The IRQ handler is called because the fixed counter for the NMI has overflowed
> and it sees this in bit 33, but it also sees that one of the PEBS
> events has also
> overflowed, yet bit 62 is not set. Therefore both overflows are
> treated as regular
> and the drain_pebs() is not called generating a non-EXACT record for the PEBS
> counter (counter 0). So something is wrong still and this is on Broadwell.
> 
> First, I don't understand why the OVF bit for counter 0 is set. It
> should not according
> to specs because the counter is in PEBS mode. There must be a race there. So 
> we
> have to handle it by relying on cpuc->pebs_enabled. I will try that.
> We likely also
> need to force OVF bit 62 to 1 so we can ack it in the end (and in case
> it gets set).

How about we make the clear of pebs_enabled unconditional?

---
 arch/x86/events/intel/core.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 68fa55b4d42e..dc9579665425 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -1883,6 +1883,16 @@ static int intel_pmu_handle_irq(struct pt_regs *regs)
status &= ~(GLOBAL_STATUS_COND_CHG |
GLOBAL_STATUS_ASIF |
GLOBAL_STATUS_LBRS_FROZEN);
+   /*
+* There are cases where, even though, the PEBS ovfl bit is set
+* in GLOBAL_OVF_STATUS, the PEBS events may also have their
+* overflow bits set for their counters. We must clear them
+* here because they have been processed as exact samples in
+* the drain_pebs() routine. They must not be processed again
+* in the for_each_bit_set() loop for regular samples below.
+*/
+   status &= ~cpuc->pebs_enabled;
+
if (!status)
goto done;
 
@@ -1892,16 +1902,6 @@ static int intel_pmu_handle_irq(struct pt_regs *regs)
if (__test_and_clear_bit(62, (unsigned long *)&status)) {
handled++;
x86_pmu.drain_pebs(regs);
-   /*
-* There are cases where, even though, the PEBS ovfl bit is set
-* in GLOBAL_OVF_STATUS, the PEBS events may also have their
-* overflow bits set for their counters. We must clear them
-* here because they have been processed as exact samples in
-* the drain_pebs() routine. They must not be processed again
-* in the for_each_bit_set() loop for regular samples below.
-*/
-   status &= ~cpuc->pebs_enabled;
-   status &= x86_pmu.intel_ctrl | GLOBAL_STATUS_TRACE_TOPAPMI;
}
 
/*

Re: [PATCH 1/2] net: thunderx: Set recevie buffer page usage count in bulk

[Sunil Kovvuri]

Hi David,


>> So if you know ahead of time how the page will be split up, just
>> calculate that when you get the page and increment the page count
>> appropriately.
>>
>> That's what we do in the NIU driver.
>
> Thanks for the suggestion, will check and get back.
>

I looked at the NIU driver and in fn() niu_rbr_refill()
static void niu_rbr_refill(struct niu *np, struct rx_ring_info *rp, gfp_t mask)
{
int index = rp->rbr_index;

rp->rbr_pending++;
if ((rp->rbr_pending % rp->rbr_blocks_per_page) == 0) {

Here it's been checked whether rbr_pending is a exact multiple of page
split count.
And hence updating page count based on fixed calculation is right.

On my platform driver receives a interrupt when free buffer count
falls below a threshold
and by the time SW reads count of buffers to be refilled it can be any
number i.e
may or may not be a exact multiple of page split count.

When interface is being brought down and while freeing unused receive
buffers one
page's count will go wrong and hence will disappear completely. In the
patch i am
updating page->count before issuing doorbell to HW irrespective of
full page utilised
or not. So there is no mismatch while doing put_page(unused buffer).

Thanks,
Sunil.

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

[Ian Abbott]

On 10/03/16 06:52, Ravishankar Karkala Mallikarjunayya wrote:

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(-)



Thanks!

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-

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

[Ian Abbott]

On 10/03/16 06:52, Ravishankar Karkala Mallikarjunayya wrote:

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(-)



Thanks!

Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-