Re: [PATCH] vfs: introduce UMOUNT_WAIT which waits for umount completion

[Amir Goldstein]

On Sat, Sep 16, 2017 at 1:12 AM, Theodore Ts'o  wrote:
> On Fri, Sep 15, 2017 at 11:44:33AM -0700, Jaegeuk Kim wrote:
>>
>> So, I digged it in more detail, and found, in drivers/android/binder.c [1],
>> - binder_ioctl()
>>  - create a kernel thread
>>  - zombie_cleanup_check()
>>   - binder_defer_work()
>> - queue_work(..., &binder_deferred_work);
>>
>> - binder_deferred_func()
>>  - binder_clear_zombies()
>>   - binder_proc_clear_zombies()
>>- put_files_struct()
>> - close_files()
>>  - filp_close()
>>   - fput()
>>
>> It seems binder holds some proc files.
>
> If binder was holding some files open, then umount should have failed
> with EBUSY, no?
>
> Does Android use mount namespaces at all?
>

Extensively.
Every user (i.e. from multi user) has its own mount ns with private /data
Every app has its own mount ns, with /sdcard mounted to one of 3 FUSE
sdcard mounts depending of app storage permission (none, rdonly, rdwr).

Amir.

Re: [Outreachy kernel] [PATCH] Staging: irda: Use !x instead of NULL comparison

[Julia Lawall]

On Sat, 16 Sep 2017, Srishti Sharma wrote:

> Test for NULL as !x where functions that return NULL on failure
> are used. Done using the following semantic patch by coccinelle.
>
> @ is_null @
> expression E;
> statement S;
> @@
>
> E = (\(kmalloc\|devm_kzalloc\|kmalloc_array\|devm_ioremap\|
> usb_alloc_urb\|alloc_netdev\|dev_alloc_skb\)(...));
>
> (
> if(!E)
>S
> |
> -if(E==NULL)
> +if(!E)
> S
> )
>
> Signed-off-by: Srishti Sharma 

Acked-by: Julia Lawall 


> ---
>  drivers/staging/irda/net/discovery.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/staging/irda/net/discovery.c 
> b/drivers/staging/irda/net/discovery.c
> index 364d70a..1e54954 100644
> --- a/drivers/staging/irda/net/discovery.c
> +++ b/drivers/staging/irda/net/discovery.c
> @@ -179,7 +179,7 @@ void irlmp_expire_discoveries(hashbin_t *log, __u32 
> saddr, int force)
>   /* Create the client specific buffer */
>   n = HASHBIN_GET_SIZE(log);
>   buffer = kmalloc(n * sizeof(struct 
> irda_device_info), GFP_ATOMIC);
> - if (buffer == NULL) {
> + if (!buffer) {
>   
> spin_unlock_irqrestore(&log->hb_spinlock, flags);
>   return;
>   }
> @@ -291,7 +291,7 @@ struct irda_device_info *irlmp_copy_discoveries(hashbin_t 
> *log, int *pn,
>   /* Create the client specific buffer */
>   n = HASHBIN_GET_SIZE(log);
>   buffer = kmalloc(n * sizeof(struct 
> irda_device_info), GFP_ATOMIC);
> - if (buffer == NULL) {
> + if (!buffer) {
>   
> spin_unlock_irqrestore(&log->hb_spinlock, flags);
>   return NULL;
>   }
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/1505543667-4670-1-git-send-email-srishtishar%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

Re: [PATCH bisected regression in 4.14] PCI: fix race while enabling upstream bridges concurrently

[Konstantin Khlebnikov]

On 15.09.2017 16:43, Srinath Mannam wrote:

Hi Konstantin,

On Fri, Sep 15, 2017 at 6:18 PM, Konstantin Khlebnikov
 wrote:

In pci_enable_bridge() pci_enable_device() is called before calling
pci_set_master(), thus check pci_is_enabled() becomes true in the
middle of this sequence. As a result in pci_enable_device_flags()
concurrent enable of device on same bridge could think that this
bridge is completely enabled, but actually it's not yet.

For me this race broke ethernet devices after booting kernel via
kexec, normal reboot was fine.

This patch removes racy fast-path: pci_enable_bridge() will take
pci_bridge_mutex and do nothing if bridge is already enabled.

Signed-off-by: Konstantin Khlebnikov 
Fixes: 40f11adc7cd9 ("PCI: Avoid race while enabling upstream bridges")
---
  drivers/pci/pci.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index b0002daa50f3..ffbe11dbdd61 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1394,7 +1394,7 @@ static int pci_enable_device_flags(struct pci_dev *dev, 
unsigned long flags)
 return 0;   /* already enabled */

 bridge = pci_upstream_bridge(dev);
-   if (bridge && !pci_is_enabled(bridge))
+   if (bridge)



This patch causes deadlock because of nexted mutex lock.


Oh, yes.

I suppose not ascending to upstream bridge for bridges from 
pci_enable_device_flags should fix this.

Something like this:


--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -1393,9 +1393,11 @@ static int pci_enable_device_flags(struct pci_dev *dev, 
unsigned long flags)
if (atomic_inc_return(&dev->enable_cnt) > 1)
return 0;   /* already enabled */

-   bridge = pci_upstream_bridge(dev);
-   if (bridge)
-   pci_enable_bridge(bridge);
+   if (!pci_is_bridge(dev)) {
+   bridge = pci_upstream_bridge(dev);
+   if (bridge)
+   pci_enable_bridge(bridge);
+   }

/* only skip sriov related */
for (i = 0; i <= PCI_ROM_RESOURCE; i++)


As per original code, Bridge enable function is called equal to number
of child bridges it has.
In the case endpoint is connected to RC through two bridges.
bridge 2 is enabled(both device and bus master) first.
While bridge1 enable, it calls device enable which calls device_enable_flags.
set device enable flag
check it has bridge (here yes because it has bridge2)
calls bridge enable for bridge2. which is already enabled.

So in my patch we introduced mutex to stop the race condition.
By taking this mutex, we see dead lock in the second call for bridge
enable (ex: bridge2)
Here we stopped second time calling of bridge enable using "if (bridge
&& !pci_is_enabled(bridge))"
In this case, there will not be such scenario where device enable and
bus master is missed in bridge enable function.
Because pci_is_enabled check in "if (bridge &&
!pci_is_enabled(bridge))" will check for its bridge not itself.
Stopping its bridge is not a problem because it is already enabled, as
I explained above.

Please explain your case where bus master could missed for bridge. It
helps me to understand more about how various bridges enabled.


Pure race: seocnd deivice could call do_pci_enable_device() while
first still enabling bridge and haven't set bus master for it:


CPU1  CPU2

pci_enable_device_flags(dev1) pci_enable_device_flags(dev2)

pci_is_enabled(bridge)

atomic_read(&bridge->enable_cnt) -> 0

pci_upstream_bridge(bridge)

mutex_lock(&pci_bridge_mutex);

pci_enable_device(bridge)

atomic_inc_return(&bridge->enable_cnt) 0 -> 1

  pci_is_enabled(bridge)

  atomic_read(&bridge->enable_cnt) 
-> 1

  do_pci_enable_device(dev2) -> 
fail,

pci_set_master(bridge);

mutex_unlock(&pci_bridge_mutex);

do_pci_enable_device(dev1)





 pci_enable_bridge(bridge);

 /* only skip sriov related */


Regards,
Srinath.

[PATCH V2] tipc: Use bsearch library function

[Thomas Meyer]

Use common library function rather than explicitly coding
some variant of it yourself.

Signed-off-by: Thomas Meyer 
---
 net/tipc/name_table.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

V2: Coding style

diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
index bd0aac87b41a..eeb4d7a13de2 100644
--- a/net/tipc/name_table.c
+++ b/net/tipc/name_table.c
@@ -44,6 +44,7 @@
 #include "addr.h"
 #include "node.h"
 #include 
+#include 
 
 #define TIPC_NAMETBL_SIZE 1024 /* must be a power of 2 */
 
@@ -168,6 +169,18 @@ static struct name_seq *tipc_nameseq_create(u32 type, 
struct hlist_head *seq_hea
return nseq;
 }
 
+static int nameseq_find_subseq_cmp(const void *key, const void *elt)
+{
+   struct sub_seq *sseq = (struct sub_seq *)elt;
+   u32 instance = *(u32 *)key;
+
+   if (instance < sseq->lower)
+   return -1;
+   else if (instance > sseq->upper)
+   return 1;
+   return 0;
+}
+
 /**
  * nameseq_find_subseq - find sub-sequence (if any) matching a name instance
  *
@@ -176,21 +189,8 @@ static struct name_seq *tipc_nameseq_create(u32 type, 
struct hlist_head *seq_hea
 static struct sub_seq *nameseq_find_subseq(struct name_seq *nseq,
   u32 instance)
 {
-   struct sub_seq *sseqs = nseq->sseqs;
-   int low = 0;
-   int high = nseq->first_free - 1;
-   int mid;
-
-   while (low <= high) {
-   mid = (low + high) / 2;
-   if (instance < sseqs[mid].lower)
-   high = mid - 1;
-   else if (instance > sseqs[mid].upper)
-   low = mid + 1;
-   else
-   return &sseqs[mid];
-   }
-   return NULL;
+   return bsearch(&instance, nseq->sseqs, nseq->first_free,
+  sizeof(struct sub_seq), nameseq_find_subseq_cmp);
 }
 
 /**
-- 
2.11.0

[PATCH] vt: Use bsearch library function in is_double_width

[Thomas Meyer]

Use bsearch library function instead of duplicated functionality.

Signed-off-by: Thomas Meyer 
---
 drivers/tty/vt/vt.c | 29 ++---
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
index 2ebaba16f785..ca55004a639e 100644
--- a/drivers/tty/vt/vt.c
+++ b/drivers/tty/vt/vt.c
@@ -102,6 +102,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define MAX_NR_CON_DRIVER 16
 
@@ -2142,22 +2143,15 @@ struct interval {
uint32_t last;
 };
 
-static int bisearch(uint32_t ucs, const struct interval *table, int max)
+static int ucs_cmp(const void *key, const void *elt)
 {
-   int min = 0;
-   int mid;
+   uint32_t ucs = *(uint32_t *)key;
+   struct interval e = *(struct interval *) elt;
 
-   if (ucs < table[0].first || ucs > table[max].last)
-   return 0;
-   while (max >= min) {
-   mid = (min + max) / 2;
-   if (ucs > table[mid].last)
-   min = mid + 1;
-   else if (ucs < table[mid].first)
-   max = mid - 1;
-   else
-   return 1;
-   }
+   if (ucs > e.last)
+   return 1;
+   else if (ucs < e.first)
+   return -1;
return 0;
 }
 
@@ -2169,7 +2163,12 @@ static int is_double_width(uint32_t ucs)
{ 0xFE10, 0xFE19 }, { 0xFE30, 0xFE6F }, { 0xFF00, 0xFF60 },
{ 0xFFE0, 0xFFE6 }, { 0x2, 0x2FFFD }, { 0x3, 0x3FFFD }
};
-   return bisearch(ucs, double_width, ARRAY_SIZE(double_width) - 1);
+   if (ucs < double_width[0].first ||
+   ucs > double_width[ARRAY_SIZE(double_width) - 1].last)
+   return 0;
+
+   return bsearch(&ucs, double_width, ARRAY_SIZE(double_width),
+   sizeof(struct interval), ucs_cmp) != NULL;
 }
 
 static void con_flush(struct vc_data *vc, unsigned long draw_from,
-- 
2.11.0

[PATCH] [media] Maxi Radio: Delete an error message for a failed memory allocation in maxiradio_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 16 Sep 2017 10:15:29 +0200

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/media/radio/radio-maxiradio.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/media/radio/radio-maxiradio.c 
b/drivers/media/radio/radio-maxiradio.c
index 3aa5ad391581..995bdc7ff4e6 100644
--- a/drivers/media/radio/radio-maxiradio.c
+++ b/drivers/media/radio/radio-maxiradio.c
@@ -125,7 +125,5 @@ static int maxiradio_probe(struct pci_dev *pdev,
-   if (dev == NULL) {
-   dev_err(&pdev->dev, "not enough memory\n");
+   if (!dev)
return -ENOMEM;
-   }
 
v4l2_dev = &dev->v4l2_dev;
v4l2_device_set_name(v4l2_dev, "maxiradio", &maxiradio_instance);
-- 
2.14.1

[PATCH] firmware: Restore support for built-in firmware

[Markus Trippelsdorf]

Commit 5620a0d1aac ("firmware: delete in-kernel firmware") removed the
entire firmware directory. Unfortunately it thereby also removed the
support for built-in firmware.
This restores the ability to build firmware directly into the kernel by
pruning the original Makefile to the necessary minimum. The default for
EXTRA_FIRMWARE_DIR is now the standard directory /lib/firmware/.

Fixes: 5620a0d1aac ("firmware: delete in-kernel firmware")
Signed-off-by: Markus Trippelsdorf 
---
 Makefile |  2 +-
 drivers/base/Kconfig |  5 +
 firmware/.gitignore  |  6 +
 firmware/Makefile| 63 
 4 files changed, 71 insertions(+), 5 deletions(-)
 create mode 100644 firmware/.gitignore
 create mode 100644 firmware/Makefile

diff --git a/Makefile b/Makefile
index 7e2ca4971a39..9f86816c41fd 100644
--- a/Makefile
+++ b/Makefile
@@ -562,7 +562,7 @@ scripts: scripts_basic include/config/auto.conf 
include/config/tristate.conf \
 
 # Objects we will link into vmlinux / subdirs we need to visit
 init-y := init/
-drivers-y  := drivers/ sound/
+drivers-y  := drivers/ sound/ firmware/
 net-y  := net/
 libs-y := lib/
 core-y := usr/
diff --git a/drivers/base/Kconfig b/drivers/base/Kconfig
index f046d21de57d..1a5f6a157a57 100644
--- a/drivers/base/Kconfig
+++ b/drivers/base/Kconfig
@@ -140,13 +140,10 @@ config EXTRA_FIRMWARE
 config EXTRA_FIRMWARE_DIR
string "Firmware blobs root directory"
depends on EXTRA_FIRMWARE != ""
-   default "firmware"
+   default "/lib/firmware"
help
  This option controls the directory in which the kernel build system
  looks for the firmware files listed in the EXTRA_FIRMWARE option.
- The default is firmware/ in the kernel source tree, but by changing
- this option you can point it elsewhere, such as /lib/firmware/ or
- some other directory containing the firmware files.
 
 config FW_LOADER_USER_HELPER
bool
diff --git a/firmware/.gitignore b/firmware/.gitignore
new file mode 100644
index ..d9c69017bc9a
--- /dev/null
+++ b/firmware/.gitignore
@@ -0,0 +1,6 @@
+*.gen.S
+*.fw
+*.bin
+*.csp
+*.dsp
+ihex2fw
diff --git a/firmware/Makefile b/firmware/Makefile
new file mode 100644
index ..fa0808853883
--- /dev/null
+++ b/firmware/Makefile
@@ -0,0 +1,63 @@
+#
+# kbuild file for firmware/
+#
+
+# Create $(fwabs) from $(CONFIG_EXTRA_FIRMWARE_DIR) -- if it doesn't have a
+# leading /, it's relative to $(srctree).
+fwdir := $(subst $(quote),,$(CONFIG_EXTRA_FIRMWARE_DIR))
+fwabs := $(addprefix $(srctree)/,$(filter-out /%,$(fwdir)))$(filter 
/%,$(fwdir))
+
+fw-external-y := $(subst $(quote),,$(CONFIG_EXTRA_FIRMWARE))
+
+quiet_cmd_fwbin = MK_FW   $@
+  cmd_fwbin = FWNAME="$(patsubst firmware/%.gen.S,%,$@)";   \
+ FWSTR="$(subst /,_,$(subst .,_,$(subst -,_,$(patsubst  \
+   firmware/%.gen.S,%,$@";  \
+ ASM_WORD=$(if $(CONFIG_64BIT),.quad,.long);\
+ ASM_ALIGN=$(if $(CONFIG_64BIT),3,2);   \
+ PROGBITS=$(if $(CONFIG_ARM),%,@)progbits;  \
+ echo "/* Generated by firmware/Makefile */"   > $@;\
+ echo ".section .rodata"   >>$@;\
+ echo ".p2align $${ASM_ALIGN}" >>$@;\
+ echo "_fw_$${FWSTR}_bin:" >>$@;\
+ echo ".incbin \"$(2)\""   >>$@;\
+ echo "_fw_end:"   >>$@;\
+ echo "   .section .rodata.str,\"aMS\",$${PROGBITS},1" >>$@;\
+ echo ".p2align $${ASM_ALIGN}" >>$@;\
+ echo "_fw_$${FWSTR}_name:">>$@;\
+ echo ".string \"$$FWNAME\""   >>$@;\
+ echo ".section .builtin_fw,\"a\",$${PROGBITS}">>$@;\
+ echo ".p2align $${ASM_ALIGN}" >>$@;\
+ echo "$${ASM_WORD} _fw_$${FWSTR}_name">>$@;\
+ echo "$${ASM_WORD} _fw_$${FWSTR}_bin" >>$@;\
+ echo "$${ASM_WORD} _fw_end - _fw_$${FWSTR}_bin"   >>$@;
+
+# One of these files will change, or come into existence, whenever
+# the configuration changes between 32-bit and 64-bit. The .S files
+# need to change when that happens.
+wordsize_deps := $(wildcard include/config/64bit.h include/config/32bit.h \
+   include/config/ppc32.h include/config/ppc64.h \
+   include/config/superh32.h include/config/superh64.h \
+   include/config/x86_32.h include/config/x86_64.h \
+   firmware/Makefile)
+
+$(patsubst %,$(obj)/%.gen.S, $(fw-external-y)): %: $(words

Re: [PATCH V2] tipc: Use bsearch library function

[Ying Xue]

On 09/16/2017 03:50 PM, Thomas Meyer wrote:
> Use common library function rather than explicitly coding
> some variant of it yourself.
> 
> Signed-off-by: Thomas Meyer 

Acked-by: Ying Xue 

> ---
>  net/tipc/name_table.c | 30 +++---
>  1 file changed, 15 insertions(+), 15 deletions(-)
> 
> V2: Coding style
> 
> diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
> index bd0aac87b41a..eeb4d7a13de2 100644
> --- a/net/tipc/name_table.c
> +++ b/net/tipc/name_table.c
> @@ -44,6 +44,7 @@
>  #include "addr.h"
>  #include "node.h"
>  #include 
> +#include 
>  
>  #define TIPC_NAMETBL_SIZE 1024   /* must be a power of 2 */
>  
> @@ -168,6 +169,18 @@ static struct name_seq *tipc_nameseq_create(u32 type, 
> struct hlist_head *seq_hea
>   return nseq;
>  }
>  
> +static int nameseq_find_subseq_cmp(const void *key, const void *elt)
> +{
> + struct sub_seq *sseq = (struct sub_seq *)elt;
> + u32 instance = *(u32 *)key;
> +
> + if (instance < sseq->lower)
> + return -1;
> + else if (instance > sseq->upper)
> + return 1;
> + return 0;
> +}
> +
>  /**
>   * nameseq_find_subseq - find sub-sequence (if any) matching a name instance
>   *
> @@ -176,21 +189,8 @@ static struct name_seq *tipc_nameseq_create(u32 type, 
> struct hlist_head *seq_hea
>  static struct sub_seq *nameseq_find_subseq(struct name_seq *nseq,
>  u32 instance)
>  {
> - struct sub_seq *sseqs = nseq->sseqs;
> - int low = 0;
> - int high = nseq->first_free - 1;
> - int mid;
> -
> - while (low <= high) {
> - mid = (low + high) / 2;
> - if (instance < sseqs[mid].lower)
> - high = mid - 1;
> - else if (instance > sseqs[mid].upper)
> - low = mid + 1;
> - else
> - return &sseqs[mid];
> - }
> - return NULL;
> + return bsearch(&instance, nseq->sseqs, nseq->first_free,
> +sizeof(struct sub_seq), nameseq_find_subseq_cmp);
>  }
>  
>  /**
> 

Re: [PATCH V2] tipc: Use bsearch library function

[Joe Perches]

On Sat, 2017-09-16 at 17:02 +0800, Ying Xue wrote:
> On 09/16/2017 03:50 PM, Thomas Meyer wrote:
> > Use common library function rather than explicitly coding
> > some variant of it yourself.
> > 
> > Signed-off-by: Thomas Meyer 
> 
> Acked-by: Ying Xue 

Are you sure you want to do this?

Note the comment above nameseq_find_subseq

 * Very time-critical, so binary searches through sub-sequence array.

What impact does this change have on performance?

> > diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
> > index bd0aac87b41a..eeb4d7a13de2 100644
> > --- a/net/tipc/name_table.c
> > +++ b/net/tipc/name_table.c
> > @@ -44,6 +44,7 @@
> >  #include "addr.h"
> >  #include "node.h"
> >  #include 
> > +#include 
> >  
> >  #define TIPC_NAMETBL_SIZE 1024 /* must be a power of 2 */
> >  
> > @@ -168,6 +169,18 @@ static struct name_seq *tipc_nameseq_create(u32 type, 
> > struct hlist_head *seq_hea
> > return nseq;
> >  }
> >  
> > +static int nameseq_find_subseq_cmp(const void *key, const void *elt)
> > +{
> > +   struct sub_seq *sseq = (struct sub_seq *)elt;
> > +   u32 instance = *(u32 *)key;
> > +
> > +   if (instance < sseq->lower)
> > +   return -1;
> > +   else if (instance > sseq->upper)
> > +   return 1;
> > +   return 0;
> > +}
> > +
> >  /**
> >   * nameseq_find_subseq - find sub-sequence (if any) matching a name 
> > instance
> >   *
> > @@ -176,21 +189,8 @@ static struct name_seq *tipc_nameseq_create(u32 type, 
> > struct hlist_head *seq_hea
> >  static struct sub_seq *nameseq_find_subseq(struct name_seq *nseq,
> >u32 instance)
> >  {
> > -   struct sub_seq *sseqs = nseq->sseqs;
> > -   int low = 0;
> > -   int high = nseq->first_free - 1;
> > -   int mid;
> > -
> > -   while (low <= high) {
> > -   mid = (low + high) / 2;
> > -   if (instance < sseqs[mid].lower)
> > -   high = mid - 1;
> > -   else if (instance > sseqs[mid].upper)
> > -   low = mid + 1;
> > -   else
> > -   return &sseqs[mid];
> > -   }
> > -   return NULL;
> > +   return bsearch(&instance, nseq->sseqs, nseq->first_free,
> > +  sizeof(struct sub_seq), nameseq_find_subseq_cmp);
> >  }
> >  
> >  /**
> > 

Re: [PATCH] mm: meminit: mark init_reserved_page as __meminit

[Mel Gorman]

On Fri, Sep 15, 2017 at 09:31:30PM +0200, Arnd Bergmann wrote:
> The function is called from __meminit context and calls other
> __meminit functions but isn't it self mark as such today:
> 
> WARNING: vmlinux.o(.text.unlikely+0x4516): Section mismatch in reference from 
> the function init_reserved_page() to the function 
> .meminit.text:early_pfn_to_nid()
> The function init_reserved_page() references
> the function __meminit early_pfn_to_nid().
> This is often because init_reserved_page lacks a __meminit
> annotation or the annotation of early_pfn_to_nid is wrong.
> 
> On most compilers, we don't notice this because the function
> gets inlined all the time. Adding __meminit here fixes the
> harmless warning for the old versions and is generally the
> correct annotation.
> 
> Fixes: 7e18adb4f80b ("mm: meminit: initialise remaining struct pages in 
> parallel with kswapd")
> Signed-off-by: Arnd Bergmann 

Acked-by: Mel Gorman 

-- 
Mel Gorman
SUSE Labs

Re: [I2C] About warning 'DMA-API: device driver maps memory from stack'

[Jun Gao]

On Sat, 2017-09-02 at 23:58 +0200, Wolfram Sang wrote:
> Hi,
> 
> nice to see someone else interested in the I2C & DMA topic.
> 
> Please check this series which I sent out recently:
> 
> "[RFC PATCH v4 0/6] i2c: document DMA handling and add helpers for it"
> 
> In that series, I proposed...
> 
> > 3. kmalloc data buffer instead of local variables buf in function
> > i2c_smbus_xfer_emulated(...)
> 
> ... this solution. Although I have to check Mauro's general response to
> the series first. I'd be interested in what you think of the series,
> too.
Sorry for late reply.

As you said in "[RFC,v4,3/6]i2c: add docs to clarify DMA handling". Most
i2c_msgs are register accesses and thus, small messages. And
"[RFC,v4,4/6] i2c: sh_mobile: use helper to decide if DMA is useful".

Maybe the solution as below will be better. Other drivers which will use
i2c would not have to make buffer DMA safe especially register
accesses(they like to use local variables when data_len = 1 or 2).

solution:
2. use FIFO mode when length<=fifo_depth(mtk i2c fifo_depth=8), use
the flag "I2C_M_DMA_SAFE" to check buffer for DMA mode when
length>fifo_depth in i2c-mt65xx.c .

Thanks.
> 
> Kind regards,
> 
>Wolfram
> 

Re: [PATCH V2] tipc: Use bsearch library function

[Ying Xue]

On 09/16/2017 05:26 PM, Joe Perches wrote:
> On Sat, 2017-09-16 at 17:02 +0800, Ying Xue wrote:
>> On 09/16/2017 03:50 PM, Thomas Meyer wrote:
>>> Use common library function rather than explicitly coding
>>> some variant of it yourself.
>>>
>>> Signed-off-by: Thomas Meyer 
>>
>> Acked-by: Ying Xue 
> 
> Are you sure you want to do this?
> 
> Note the comment above nameseq_find_subseq
> 
>  * Very time-critical, so binary searches through sub-sequence array.
> 
> What impact does this change have on performance?

Sorry, I couldn't see any essential difference between this new
implementation and the original one except that the former tries to use
the library function - bsearch() to replace the original binary search
algorithm implemented in TIPC itself. Therefore, I don't think the
change will have a big impact on performance.

If I miss something, please let me know.

Thanks,
Ying

> 
>>> diff --git a/net/tipc/name_table.c b/net/tipc/name_table.c
>>> index bd0aac87b41a..eeb4d7a13de2 100644
>>> --- a/net/tipc/name_table.c
>>> +++ b/net/tipc/name_table.c
>>> @@ -44,6 +44,7 @@
>>>  #include "addr.h"
>>>  #include "node.h"
>>>  #include 
>>> +#include 
>>>  
>>>  #define TIPC_NAMETBL_SIZE 1024 /* must be a power of 2 */
>>>  
>>> @@ -168,6 +169,18 @@ static struct name_seq *tipc_nameseq_create(u32 type, 
>>> struct hlist_head *seq_hea
>>> return nseq;
>>>  }
>>>  
>>> +static int nameseq_find_subseq_cmp(const void *key, const void *elt)
>>> +{
>>> +   struct sub_seq *sseq = (struct sub_seq *)elt;
>>> +   u32 instance = *(u32 *)key;
>>> +
>>> +   if (instance < sseq->lower)
>>> +   return -1;
>>> +   else if (instance > sseq->upper)
>>> +   return 1;
>>> +   return 0;
>>> +}
>>> +
>>>  /**
>>>   * nameseq_find_subseq - find sub-sequence (if any) matching a name 
>>> instance
>>>   *
>>> @@ -176,21 +189,8 @@ static struct name_seq *tipc_nameseq_create(u32 type, 
>>> struct hlist_head *seq_hea
>>>  static struct sub_seq *nameseq_find_subseq(struct name_seq *nseq,
>>>u32 instance)
>>>  {
>>> -   struct sub_seq *sseqs = nseq->sseqs;
>>> -   int low = 0;
>>> -   int high = nseq->first_free - 1;
>>> -   int mid;
>>> -
>>> -   while (low <= high) {
>>> -   mid = (low + high) / 2;
>>> -   if (instance < sseqs[mid].lower)
>>> -   high = mid - 1;
>>> -   else if (instance > sseqs[mid].upper)
>>> -   low = mid + 1;
>>> -   else
>>> -   return &sseqs[mid];
>>> -   }
>>> -   return NULL;
>>> +   return bsearch(&instance, nseq->sseqs, nseq->first_free,
>>> +  sizeof(struct sub_seq), nameseq_find_subseq_cmp);
>>>  }
>>>  
>>>  /**
>>>
> 

Re: [PATCH 3/5] powerpc64: Add .opd based function descriptor dereference

[Naveen N. Rao]

On 2017/09/16 12:53PM, Sergey Senozhatsky wrote:
> We are moving towards separate kernel and module function descriptor
> dereference callbacks. This patch enables it for powerpc64.
> 
> For pointers that belong to the kernel
> -  Added __start_opd and __end_opd pointers, to track the kernel
>.opd section address range;
> 
> -  Added dereference_kernel_function_descriptor(). Now we
>will dereference only function pointers that are within
>[__start_opd, __end_opd];
> 
> For pointers that belong to a module
> -  Added dereference_module_function_descriptor() to handle module
>function descriptor dereference. Now we will dereference only
>pointers that are within [module->opd.start, module->opd.end].

Would it be simpler to just use kernel_text_address() and dereference 
everything else? See commit 83e840c770f2c5 ("powerpc64/elfv1: Only 
dereference function descriptor for non-text symbols") for a related 
patch.

- Naveen

Re: [PATCH v4 4/6] iio: adc: sun4i-gpadc-iio: add support for H3 thermal sensor

[Quentin Schulz]

Hi Icenowy,

On 14/09/2017 16:52, Icenowy Zheng wrote:
> This adds support for the Allwinner H3 thermal sensor.
> 
> Allwinner H3 has a thermal sensor like the one in A33, but have its
> registers nearly all re-arranged, sample clock moved to CCU and a pair
> of bus clock and reset added. It's also the base of newer SoCs' thermal
> sensors.
> 
> The thermal sensors on A64 and H5 is like the one on H3, but with of
> course different formula factors.
> 
> Signed-off-by: Icenowy Zheng 
> ---
> Changes in v4:
> - Splitted out some code refactors.
> - Code sequence changed back. (The gpadc_data went back to the start of
>   the source file)
> 
>  drivers/iio/adc/sun4i-gpadc-iio.c | 48 
> +++
>  include/linux/mfd/sun4i-gpadc.h   | 27 ++
>  2 files changed, 75 insertions(+)
[...]
> diff --git a/include/linux/mfd/sun4i-gpadc.h b/include/linux/mfd/sun4i-gpadc.h
> index 78d31984a222..5c2a12101052 100644
> --- a/include/linux/mfd/sun4i-gpadc.h
> +++ b/include/linux/mfd/sun4i-gpadc.h
[...]
> +#define SUN8I_H3_GPADC_CTRL2_T_ACQ1(x)   ((GENMASK(15, 
> 0) * (x)) << 16)
> +

You want to replace * by &.

((GENMASK(15, 0) & (x)) << 16)

Would ((GENMASK(31, 16) & ((x) << 16)) make the bits you set even more
obvious?

>  #define SUN4I_GPADC_CTRL30x0c
> +/*
> + * This register is named "Average filter Control Register" in H3 Datasheet,
> + * but the register's definition is the same as the old CTRL3 register.
> + */
> +#define SUN8I_H3_GPADC_CTRL3 0x70
>  

I would name it as it is in the documentation:
SUN8I_H3_THS_FILTER

No need for comments then.

>  #define SUN4I_GPADC_CTRL3_FILTER_EN  BIT(2)
>  #define SUN4I_GPADC_CTRL3_FILTER_TYPE(x) (GENMASK(1, 0) & (x))
> @@ -71,6 +84,13 @@
>  #define SUN4I_GPADC_INT_FIFOC_TP_UP_IRQ_EN   BIT(1)
>  #define SUN4I_GPADC_INT_FIFOC_TP_DOWN_IRQ_EN BIT(0)
>  
> +#define SUN8I_H3_GPADC_INTC  0x44
> +
> +#define SUN8I_H3_GPADC_INTC_TEMP_PERIOD(x)   ((GENMASK(19, 0) & (x)) 
> << 12)
> +#define SUN8I_H3_GPADC_INTC_TEMP_DATABIT(8)
> +#define SUN8I_H3_GPADC_INTC_TEMP_SHUTBIT(4)
> +#define SUN8I_H3_GPADC_INTC_TEMP_ALARM   BIT(0)
> +

Since it isn't an ADC anymore but rather just a THS, why don't you use
SUN8I_H3_THS instead of SUN8I_H3_GPADC? That way, it also matches the
datasheet.

>  #define SUN4I_GPADC_INT_FIFOS0x14
>  
>  #define SUN4I_GPADC_INT_FIFOS_TEMP_DATA_PENDING  BIT(18)
> @@ -80,9 +100,16 @@
>  #define SUN4I_GPADC_INT_FIFOS_TP_UP_PENDING  BIT(1)
>  #define SUN4I_GPADC_INT_FIFOS_TP_DOWN_PENDINGBIT(0)
>  
> +#define SUN8I_H3_GPADC_INTS  0x44

0x48

[...]

1) You're not using irqs, why would you define registers that will never
be used?

2) Why aren't you using irqs? I remember we discussed on IRC that you
had some problems with the H3 when resuming or when probing the driver.
The register would have a zero in it until you have a first sample that
arrived (i.e. after the sample rate you set with T_ACQ) that would make
the thermal framework panic since the thermal sensor would return
something way too hot and shutdown your board?

The H3 apparently supports IRQs, why do you not support them for the
temperature? They might be broken as it is on A33 but then it might be a
good idea to write it down in a comment in the driver (and not adding
the unused registers in the header file) or at least in the commit log.

3) Now that you have support for clocks, wouldn't it be a good idea to
disable them during suspend?

Thanks,
Quentin
-- 
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v2 0/2] enable hires timer to timeout datagram socket

[Thomas Gleixner]

On Fri, 8 Sep 2017, Eric Dumazet wrote:
> On Fri, 2017-09-08 at 11:55 -0700, Eduardo Valentin wrote:
> > Hello,
> > 
> > On Fri, Sep 08, 2017 at 10:26:45AM -0700, David Miller wrote:
> > > From: David Woodhouse 
> > > Date: Fri, 08 Sep 2017 18:23:22 +0100
> > > 
> > > > I don't know that anyone's ever tried saying "show me the chapter
> > and
> > > > verse of the documentation"
> > > 
> > > Do you know why I brought this up?  Because the person I am replying
> > > to told me that the syscall documentation should have suggested this
> > > or that.
> > > 
> > > That's why.
> > 
> > :-) My intention was for sure not to upset anybody.
> > 
> > Just to reiterate, the point of patch is simple, there was a change in
> > behavior in the system call from one kernel version to the other. As I
> > mentioned, I agree that the userspace could use other means to achieve
> > the same, but still the system call behavior has changed.
> > 
> > > 
> > > So let's concentrate on the other aspects of my reply, ok?
> > 
> > I agree. I would prefer to understand here what is the technical
> > reason not to accept these patches other than "use other system
> > calls".
> 
> So if we need to replace all 'legacy' timers to high resolution timer,
> because some application was _relying_ on jiffies being kind of precise,
> maybe it is better to revert the change done on legacy timers.

Which would be a major step back in terms of timer performance and system
disturbance caused by massive recascading operations.

> Or continue the migration and make them use high res internally.
> 
> select() and poll() are the standard way to have precise timeouts,
> it is silly we have to maintain a timeout handling in the datagram fast
> path.

A few years ago we switched select/poll over to use hrtimers because the
wheel timers were too inaccurate for some operations, so it feels
consequent to switch the timeout in the datagram rcv path over as well. I
agree that the whole timeout magic there feels silly, but unfortunately
it's a documented property of sockets.

Thanks,

tglx

Re: [PATCH V2] tipc: Use bsearch library function

[Joe Perches]

On Sat, 2017-09-16 at 17:36 +0800, Ying Xue wrote:
> On 09/16/2017 05:26 PM, Joe Perches wrote:
> > On Sat, 2017-09-16 at 17:02 +0800, Ying Xue wrote:
> > > On 09/16/2017 03:50 PM, Thomas Meyer wrote:
> > > > Use common library function rather than explicitly coding
> > > > some variant of it yourself.
> > > > 
> > > > Signed-off-by: Thomas Meyer 
> > > 
> > > Acked-by: Ying Xue 
> > 
> > Are you sure you want to do this?
> > 
> > Note the comment above nameseq_find_subseq
> > 
> >  * Very time-critical, so binary searches through sub-sequence array.
> > 
> > What impact does this change have on performance?
> 
> Sorry, I couldn't see any essential difference between this new
> implementation and the original one except that the former tries to use
> the library function - bsearch() to replace the original binary search
> algorithm implemented in TIPC itself. Therefore, I don't think the
> change will have a big impact on performance.
> 
> If I miss something, please let me know.

Comparison via a function pointer in bsearch is slower
than direct code without the function call overhead.

Re: [PATCH v4 6/6] ARM: sun8i: h3: add partial CPU thermal zone

[Quentin Schulz]

Hi Icenowy,

On 14/09/2017 16:52, Icenowy Zheng wrote:
> Because of the restriction of the OF thermal framework, the thermal
> sensor will fail to probe if the thermal zone doesn't exist.
> 

Oh no, that's not good.

We discussed about it on IRC and I even proposed a patch for it, telling
you I would post it on the mailing list soon after. Of course, I forgot
and you definitely should have yelled at me for not doing it :)

I won't be able to test the patch soon. I can send it to you so that you
can test it and integrate it in your patch series so it won't block you.
Otherwise, we'll have to wait for a week or two for me to test it.

Thanks and sorry for forgetting to post the patch you need,
Quentin

> Add a partial thermal zone which claims the H3 THS as the thermal sensor.
> 
> The cooling device (CPU DVFS) is still not added as it's not ready, and
> the trip points are also not added yet.
> 
> Signed-off-by: Icenowy Zheng 
> ---
>  arch/arm/boot/dts/sun8i-h3.dtsi | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/sun8i-h3.dtsi b/arch/arm/boot/dts/sun8i-h3.dtsi
> index 3220da3ad790..687c6457d214 100644
> --- a/arch/arm/boot/dts/sun8i-h3.dtsi
> +++ b/arch/arm/boot/dts/sun8i-h3.dtsi
> @@ -89,6 +89,15 @@
>   };
>   };
>  
> + thermal-zones {
> + cpu-thermal {
> + /* milliseconds */
> + polling-delay-passive = <250>;
> + polling-delay = <1000>;
> + thermal-sensors = <&ths>;
> + };
> + };
> +
>   timer {
>   compatible = "arm,armv7-timer";
>   interrupts =  IRQ_TYPE_LEVEL_LOW)>,
> 

-- 
Quentin Schulz, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH V2] tipc: Use bsearch library function

[Ying Xue]

On 09/16/2017 05:58 PM, Joe Perches wrote:
> On Sat, 2017-09-16 at 17:36 +0800, Ying Xue wrote:
>> On 09/16/2017 05:26 PM, Joe Perches wrote:
>>> On Sat, 2017-09-16 at 17:02 +0800, Ying Xue wrote:
 On 09/16/2017 03:50 PM, Thomas Meyer wrote:
> Use common library function rather than explicitly coding
> some variant of it yourself.
>
> Signed-off-by: Thomas Meyer 

 Acked-by: Ying Xue 
>>>
>>> Are you sure you want to do this?
>>>
>>> Note the comment above nameseq_find_subseq
>>>
>>>  * Very time-critical, so binary searches through sub-sequence array.
>>>
>>> What impact does this change have on performance?
>>
>> Sorry, I couldn't see any essential difference between this new
>> implementation and the original one except that the former tries to use
>> the library function - bsearch() to replace the original binary search
>> algorithm implemented in TIPC itself. Therefore, I don't think the
>> change will have a big impact on performance.
>>
>> If I miss something, please let me know.
> 
> Comparison via a function pointer in bsearch is slower
> than direct code without the function call overhead.
> 

Right, but probably we can tolerate the slight sacrifice here.

> 

Re: [PATCH v4 4/6] iio: adc: sun4i-gpadc-iio: add support for H3 thermal sensor

[icenowy]

在 2017-09-16 17:45，Quentin Schulz 写道：

Hi Icenowy,

On 14/09/2017 16:52, Icenowy Zheng wrote:

This adds support for the Allwinner H3 thermal sensor.

Allwinner H3 has a thermal sensor like the one in A33, but have its
registers nearly all re-arranged, sample clock moved to CCU and a pair
of bus clock and reset added. It's also the base of newer SoCs' 
thermal

sensors.

The thermal sensors on A64 and H5 is like the one on H3, but with of
course different formula factors.

Signed-off-by: Icenowy Zheng 
---
Changes in v4:
- Splitted out some code refactors.
- Code sequence changed back. (The gpadc_data went back to the start 
of

  the source file)

 drivers/iio/adc/sun4i-gpadc-iio.c | 48 
+++

 include/linux/mfd/sun4i-gpadc.h   | 27 ++
 2 files changed, 75 insertions(+)

[...]
diff --git a/include/linux/mfd/sun4i-gpadc.h 
b/include/linux/mfd/sun4i-gpadc.h

index 78d31984a222..5c2a12101052 100644
--- a/include/linux/mfd/sun4i-gpadc.h
+++ b/include/linux/mfd/sun4i-gpadc.h

[...]
+#define SUN8I_H3_GPADC_CTRL2_T_ACQ1(x)			((GENMASK(15, 0) * (x)) << 
16)

+


You want to replace * by &.

((GENMASK(15, 0) & (x)) << 16)

Would ((GENMASK(31, 16) & ((x) << 16)) make the bits you set even more
obvious?


 #define SUN4I_GPADC_CTRL3  0x0c
+/*
+ * This register is named "Average filter Control Register" in H3 
Datasheet,
+ * but the register's definition is the same as the old CTRL3 
register.

+ */
+#define SUN8I_H3_GPADC_CTRL3   0x70



I would name it as it is in the documentation:
SUN8I_H3_THS_FILTER


The definition of this register is the same as the CTRL3.

Maybe this name is better, but the similarity between them still needs
to be documented, as the SUN4I_GPADC_CTRL3_XXX macros will be used to
populate this register.



No need for comments then.


 #define SUN4I_GPADC_CTRL3_FILTER_ENBIT(2)
 #define SUN4I_GPADC_CTRL3_FILTER_TYPE(x)   (GENMASK(1, 0) & (x))
@@ -71,6 +84,13 @@
 #define SUN4I_GPADC_INT_FIFOC_TP_UP_IRQ_EN BIT(1)
 #define SUN4I_GPADC_INT_FIFOC_TP_DOWN_IRQ_EN   BIT(0)

+#define SUN8I_H3_GPADC_INTC0x44
+
+#define SUN8I_H3_GPADC_INTC_TEMP_PERIOD(x)		((GENMASK(19, 0) & (x)) 
<< 12)

+#define SUN8I_H3_GPADC_INTC_TEMP_DATA  BIT(8)
+#define SUN8I_H3_GPADC_INTC_TEMP_SHUT  BIT(4)
+#define SUN8I_H3_GPADC_INTC_TEMP_ALARM BIT(0)
+


Since it isn't an ADC anymore but rather just a THS, why don't you use
SUN8I_H3_THS instead of SUN8I_H3_GPADC? That way, it also matches the
datasheet.


 #define SUN4I_GPADC_INT_FIFOS  0x14

 #define SUN4I_GPADC_INT_FIFOS_TEMP_DATA_PENDINGBIT(18)
@@ -80,9 +100,16 @@
 #define SUN4I_GPADC_INT_FIFOS_TP_UP_PENDINGBIT(1)
 #define SUN4I_GPADC_INT_FIFOS_TP_DOWN_PENDING  BIT(0)

+#define SUN8I_H3_GPADC_INTS0x44


0x48

[...]

1) You're not using irqs, why would you define registers that will 
never

be used?


I will then rework it to use IRQs, but not now.

Maybe I should add it when I use them?



2) Why aren't you using irqs? I remember we discussed on IRC that you
had some problems with the H3 when resuming or when probing the driver.
The register would have a zero in it until you have a first sample that
arrived (i.e. after the sample rate you set with T_ACQ) that would make
the thermal framework panic since the thermal sensor would return
something way too hot and shutdown your board?


Nope, it's another problem -- the runtime resume function is even not
called before the first sample, and the first sample will happen when
the THS is still suspended.



The H3 apparently supports IRQs, why do you not support them for the
temperature? They might be broken as it is on A33 but then it might be 
a

good idea to write it down in a comment in the driver (and not adding
the unused registers in the header file) or at least in the commit log.

3) Now that you have support for clocks, wouldn't it be a good idea to
disable them during suspend?


Interesting... It's meaningful to disable the mod clock during suspend.



Thanks,
Quentin

Re: system hung up when offlining CPUs

[Thomas Gleixner]

On Thu, 14 Sep 2017, YASUAKI ISHIMATSU wrote:
> On 09/13/2017 09:33 AM, Thomas Gleixner wrote:
> >> Question - "what happens once __cpu_disable is called and some of the 
> >> queued
> >> interrupt has affinity to that particular CPU ?"
> >> I assume ideally those pending/queued Interrupt should be migrated to
> >> remaining online CPUs. It should not be unhandled if we want to avoid such
> >> IO timeout.
> > 
> > Can you please provide the following information, before and after
> > offlining the last CPU in the affinity set:
> > 
> > # cat /proc/irq/$IRQNUM/smp_affinity_list
> > # cat /proc/irq/$IRQNUM/effective_affinity
> > # cat /sys/kernel/debug/irq/irqs/$IRQNUM
> > 
> > The last one requires: CONFIG_GENERIC_IRQ_DEBUGFS=y
> 
> Here are one irq's info of megasas:
> 
> - Before offline CPU
> /proc/irq/70/smp_affinity_list
> 24-29
> 
> /proc/irq/70/effective_affinity
> ,,,,,,,,,,,,,,,3f00
> 
> /sys/kernel/debug/irq/irqs/70
> handler:  handle_edge_irq
> status:   0x4000
> istate:   0x
> ddepth:   0
> wdepth:   0
> dstate:   0x00609200
> IRQD_ACTIVATED
> IRQD_IRQ_STARTED
> IRQD_MOVE_PCNTXT
> IRQD_AFFINITY_SET
> IRQD_AFFINITY_MANAGED

So this uses managed affinity, which means that once the last CPU in the
affinity mask goes offline, the interrupt is shut down by the irq core
code, which is the case:

> dstate:   0x00a39000
> IRQD_IRQ_DISABLED
> IRQD_IRQ_MASKED
> IRQD_MOVE_PCNTXT
> IRQD_AFFINITY_SET
> IRQD_AFFINITY_MANAGED
> IRQD_MANAGED_SHUTDOWN  <---

So the irq core code works as expected, but something in the
driver/scsi/block stack seems to fiddle with that shut down queue.

I only can tell about the inner workings of the irq code, but I have no
clue about the rest.

Thanks,

tglx

Re: [PATCH V2] tipc: Use bsearch library function

[Joe Perches]

On Sat, 2017-09-16 at 18:10 +0800, Ying Xue wrote:
> On 09/16/2017 05:58 PM, Joe Perches wrote:
> > On Sat, 2017-09-16 at 17:36 +0800, Ying Xue wrote:
> > > On 09/16/2017 05:26 PM, Joe Perches wrote:
> > > > On Sat, 2017-09-16 at 17:02 +0800, Ying Xue wrote:
> > > > > On 09/16/2017 03:50 PM, Thomas Meyer wrote:
> > > > > > Use common library function rather than explicitly coding
> > > > > > some variant of it yourself.
> > > > > > 
> > > > > > Signed-off-by: Thomas Meyer 
> > > > > 
> > > > > Acked-by: Ying Xue 
> > > > 
> > > > Are you sure you want to do this?
> > > > 
> > > > Note the comment above nameseq_find_subseq
> > > > 
> > > >  * Very time-critical, so binary searches through sub-sequence array.
> > > > 
> > > > What impact does this change have on performance?
> > > 
> > > Sorry, I couldn't see any essential difference between this new
> > > implementation and the original one except that the former tries to use
> > > the library function - bsearch() to replace the original binary search
> > > algorithm implemented in TIPC itself. Therefore, I don't think the
> > > change will have a big impact on performance.
> > > 
> > > If I miss something, please let me know.
> > 
> > Comparison via a function pointer in bsearch is slower
> > than direct code without the function call overhead.
> > 
> 
> Right, but probably we can tolerate the slight sacrifice here.

What part of "very time critical" have you verified
and benchmarked as inconsequential?

Please post your results.

Re: [PATCH v4 4/6] iio: adc: sun4i-gpadc-iio: add support for H3 thermal sensor

[Quentin Schulz]

Hi Icenowy,

On 16/09/2017 12:14, icen...@aosc.io wrote:
> 在 2017-09-16 17:45，Quentin Schulz 写道：
>> Hi Icenowy,
>>
>> On 14/09/2017 16:52, Icenowy Zheng wrote:
>>> This adds support for the Allwinner H3 thermal sensor.
>>>
>>> Allwinner H3 has a thermal sensor like the one in A33, but have its
>>> registers nearly all re-arranged, sample clock moved to CCU and a pair
>>> of bus clock and reset added. It's also the base of newer SoCs' thermal
>>> sensors.
>>>
>>> The thermal sensors on A64 and H5 is like the one on H3, but with of
>>> course different formula factors.
>>>
>>> Signed-off-by: Icenowy Zheng 
>>> ---
>>> Changes in v4:
>>> - Splitted out some code refactors.
>>> - Code sequence changed back. (The gpadc_data went back to the start of
>>>   the source file)
>>>
>>>  drivers/iio/adc/sun4i-gpadc-iio.c | 48
>>> +++
>>>  include/linux/mfd/sun4i-gpadc.h   | 27 ++
>>>  2 files changed, 75 insertions(+)
[...]
>>>  #define SUN4I_GPADC_CTRL3    0x0c
>>> +/*
>>> + * This register is named "Average filter Control Register" in H3
>>> Datasheet,
>>> + * but the register's definition is the same as the old CTRL3 register.
>>> + */
>>> +#define SUN8I_H3_GPADC_CTRL3    0x70
>>>
>>
>> I would name it as it is in the documentation:
>> SUN8I_H3_THS_FILTER
> 
> The definition of this register is the same as the CTRL3.
> 
> Maybe this name is better, but the similarity between them still needs
> to be documented, as the SUN4I_GPADC_CTRL3_XXX macros will be used to
> populate this register.
> 
>>
>> No need for comments then.
>>
>>>  #define SUN4I_GPADC_CTRL3_FILTER_EN    BIT(2)
>>>  #define SUN4I_GPADC_CTRL3_FILTER_TYPE(x)    (GENMASK(1, 0) & (x))

They have _FILTER_ in their name, isn't it enough?

Just a matter of taste for me.

>>> @@ -71,6 +84,13 @@
>>>  #define SUN4I_GPADC_INT_FIFOC_TP_UP_IRQ_EN    BIT(1)
>>>  #define SUN4I_GPADC_INT_FIFOC_TP_DOWN_IRQ_EN    BIT(0)
>>>
>>> +#define SUN8I_H3_GPADC_INTC    0x44
>>> +
>>> +#define SUN8I_H3_GPADC_INTC_TEMP_PERIOD(x)    ((GENMASK(19, 0) &
>>> (x)) << 12)
>>> +#define SUN8I_H3_GPADC_INTC_TEMP_DATA    BIT(8)
>>> +#define SUN8I_H3_GPADC_INTC_TEMP_SHUT    BIT(4)
>>> +#define SUN8I_H3_GPADC_INTC_TEMP_ALARM    BIT(0)
>>> +
>>
>> Since it isn't an ADC anymore but rather just a THS, why don't you use
>> SUN8I_H3_THS instead of SUN8I_H3_GPADC? That way, it also matches the
>> datasheet.
>>
>>>  #define SUN4I_GPADC_INT_FIFOS    0x14
>>>
>>>  #define SUN4I_GPADC_INT_FIFOS_TEMP_DATA_PENDING    BIT(18)
>>> @@ -80,9 +100,16 @@
>>>  #define SUN4I_GPADC_INT_FIFOS_TP_UP_PENDING    BIT(1)
>>>  #define SUN4I_GPADC_INT_FIFOS_TP_DOWN_PENDING    BIT(0)
>>>
>>> +#define SUN8I_H3_GPADC_INTS    0x44
>>
>> 0x48
>>
>> [...]
>>
>> 1) You're not using irqs, why would you define registers that will never
>> be used?
> 
> I will then rework it to use IRQs, but not now.
> 
> Maybe I should add it when I use them?
> 

Why not make it work right away the way we want :)?

>>
>> 2) Why aren't you using irqs? I remember we discussed on IRC that you
>> had some problems with the H3 when resuming or when probing the driver.
>> The register would have a zero in it until you have a first sample that
>> arrived (i.e. after the sample rate you set with T_ACQ) that would make
>> the thermal framework panic since the thermal sensor would return
>> something way too hot and shutdown your board?
> 
> Nope, it's another problem -- the runtime resume function is even not
> called before the first sample, and the first sample will happen when
> the THS is still suspended.
> 

As discussed on IRC (a long time ago :) ), it's a combination of two
problems:
1) get_temp (used by thermal framework) uses pm_runtime function that
isn't ready yet <= I will send a patch for registering thermal framework
after pm_runtime to you, hopefully in the upcoming hour or tomorrow,

2) The A33 (and H3 in your implementation) does not wait for an
interrupt to read the TEMP_DATA register which resets to 0 when the
sensor is disabled (or until a first sample arrives) i.e. when probing
or when resuming. Using IRQs would get rid of 2). It isn't critical for
A33 as the formula for temp returns something really cold so thermal
does not care. But for the H3, it's critically hot and shuts down your
board. To make it work on the H3, we would have to use a delay in the
pm_resume function equal to the sensor sampling rate and I don't really
like that. If we could use IRQs, it'd be better IMHO (but they aren't
working on A33).

Thanks,
Quentin

>>
>> The H3 apparently supports IRQs, why do you not support them for the
>> temperature? They might be broken as it is on A33 but then it might be a
>> good idea to write it down in a comment in the driver (and not adding
>> the unused registers in the header file) or at least in the commit log.
>>
>> 3) Now that you have support for c

[PATCH 0/9 v2] usb: usb251xb: Add USB2517i hub support and fix some bugs

[Serge Semin]

Primarily it was intended to just add USB2517 hub support to the driver.
But after tests a bug and inconistency were discovered. So it was decided
to make the following changes:

Changelog v1:
- Add USB2517/i hub specifics support to the driver
- Fix property_u32 NULL-pointer dereference
- Add new {bus,self}-max-{power,curret} dts properties
- Replace legacy GPIO API usage with descriptor-based one

Changelog v2:
- Split first patch into smaller ones
- Fix invalid BOOST_14 register definition
- Combine copyrights adding patch into the last one

Serge Semin (9):
  usb: usb251xb: Add USB2517i specific struct and IDs
  usb: usb251xb: Add USB251x specific port count setting
  usb: usb251xb: Add 5,6,7 ports mapping def setting
  usb: usb251xb: Add 5,6,7 ports boost settings
  usb: usb251xb: Add battery enable setting flag
  usb: usb251xb: Add USB2517 LED settings
  usb: usb251xb: Fix property_u32 NULL pointer dereference
  usb: usb251xb: Add max power/current dts property support
  usb: usb251xb: Use GPIO descriptor consumer interface

 Documentation/devicetree/bindings/usb/usb251xb.txt |  12 +-
 drivers/usb/misc/usb251xb.c| 160 +++--
 2 files changed, 128 insertions(+), 44 deletions(-)

-- 
2.12.0

[PATCH 2/9 v2] usb: usb251xb: Add USB251x specific port count setting

[Serge Semin]

USB251xb as well as USB2517 datasheet states, that all these
hubs differ by number of ports declared as the last digit in the
model name. So USB2512 got two ports, USB2513 - three, and so on.
Such setting must be reflected in the device specific data
structure and corresponding dts property should be checked whether
it doesn't get out of available ports.

Signed-off-by: Serge Semin 
---
 drivers/usb/misc/usb251xb.c | 21 ++---
 1 file changed, 18 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/misc/usb251xb.c b/drivers/usb/misc/usb251xb.c
index 96a8c20ac..5cb0e5570 100644
--- a/drivers/usb/misc/usb251xb.c
+++ b/drivers/usb/misc/usb251xb.c
@@ -154,46 +154,55 @@ struct usb251xb {
 
 struct usb251xb_data {
u16 product_id;
+   u8 port_cnt;
char product_str[USB251XB_STRING_BUFSIZE / 2]; /* ASCII string */
 };
 
 static const struct usb251xb_data usb2512b_data = {
.product_id = 0x2512,
+   .port_cnt = 2,
.product_str = "USB2512B",
 };
 
 static const struct usb251xb_data usb2512bi_data = {
.product_id = 0x2512,
+   .port_cnt = 2,
.product_str = "USB2512Bi",
 };
 
 static const struct usb251xb_data usb2513b_data = {
.product_id = 0x2513,
+   .port_cnt = 3,
.product_str = "USB2513B",
 };
 
 static const struct usb251xb_data usb2513bi_data = {
.product_id = 0x2513,
+   .port_cnt = 3,
.product_str = "USB2513Bi",
 };
 
 static const struct usb251xb_data usb2514b_data = {
.product_id = 0x2514,
+   .port_cnt = 4,
.product_str = "USB2514B",
 };
 
 static const struct usb251xb_data usb2514bi_data = {
.product_id = 0x2514,
+   .port_cnt = 4,
.product_str = "USB2514Bi",
 };
 
 static const struct usb251xb_data usb2517_data = {
.product_id = 0x2517,
+   .port_cnt = 7,
.product_str = "USB2517",
 };
 
 static const struct usb251xb_data usb2517i_data = {
.product_id = 0x2517,
+   .port_cnt = 7,
.product_str = "USB2517i",
 };
 
@@ -422,8 +431,10 @@ static int usb251xb_get_ofdata(struct usb251xb *hub,
for (i = 0; i < len / sizeof(u32); i++) {
u32 port = be32_to_cpu(cproperty_u32[i]);
 
-   if ((port >= 1) && (port <= 4))
+   if ((port >= 1) && (port <= data->port_cnt))
hub->non_rem_dev |= BIT(port);
+   else
+   dev_warn(dev, "port %u doesn't exist\n", port);
}
}
 
@@ -433,8 +444,10 @@ static int usb251xb_get_ofdata(struct usb251xb *hub,
for (i = 0; i < len / sizeof(u32); i++) {
u32 port = be32_to_cpu(cproperty_u32[i]);
 
-   if ((port >= 1) && (port <= 4))
+   if ((port >= 1) && (port <= data->port_cnt))
hub->port_disable_sp |= BIT(port);
+   else
+   dev_warn(dev, "port %u doesn't exist\n", port);
}
}
 
@@ -444,8 +457,10 @@ static int usb251xb_get_ofdata(struct usb251xb *hub,
for (i = 0; i < len / sizeof(u32); i++) {
u32 port = be32_to_cpu(cproperty_u32[i]);
 
-   if ((port >= 1) && (port <= 4))
+   if ((port >= 1) && (port <= data->port_cnt))
hub->port_disable_bp |= BIT(port);
+   else
+   dev_warn(dev, "port %u doesn't exist\n", port);
}
}
 
-- 
2.12.0

[PATCH 6/9 v2] usb: usb251xb: Add USB2517 LED settings

[Serge Semin]

USB2517 supports two LED modes: USB mode (default) and speed indication
mode. The last one can be switched on by corresponding dts property.
Since USB251xb hubs doesn't support LEDs settings, we need to ignore
this setting.

Signed-off-by: Serge Semin 
---
 Documentation/devicetree/bindings/usb/usb251xb.txt |  1 +
 drivers/usb/misc/usb251xb.c| 14 +-
 2 files changed, 14 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/usb/usb251xb.txt 
b/Documentation/devicetree/bindings/usb/usb251xb.txt
index 1682d4087..3d84626d3 100644
--- a/Documentation/devicetree/bindings/usb/usb251xb.txt
+++ b/Documentation/devicetree/bindings/usb/usb251xb.txt
@@ -37,6 +37,7 @@ Optional properties :
an invalid value is given, the default is used instead.
  - compound-device : indicate the hub is part of a compound device
  - port-mapping-mode : enable port mapping mode
+ - speed-led-mode : led speed indiation mode selection (usb2517 only)
  - string-support : enable string descriptor support (required for 
manufacturer,
product and serial string configuration)
  - non-removable-ports : Should specify the ports which have a non-removable
diff --git a/drivers/usb/misc/usb251xb.c b/drivers/usb/misc/usb251xb.c
index 0834729d1..51cc53ddc 100644
--- a/drivers/usb/misc/usb251xb.c
+++ b/drivers/usb/misc/usb251xb.c
@@ -49,7 +49,7 @@
 #define USB251XB_ADDR_CONFIG_DATA_20x07
 #define USB251XB_DEF_CONFIG_DATA_2 0x20
 #define USB251XB_ADDR_CONFIG_DATA_30x08
-#define USB251XB_DEF_CONFIG_DATA_3 0x02
+#define USB251XB_DEF_CONFIG_DATA_3 0x00
 
 #define USB251XB_ADDR_NON_REMOVABLE_DEVICES0x09
 #define USB251XB_DEF_NON_REMOVABLE_DEVICES 0x00
@@ -164,6 +164,7 @@ struct usb251xb {
 struct usb251xb_data {
u16 product_id;
u8 port_cnt;
+   bool led_support;
bool bat_support;
char product_str[USB251XB_STRING_BUFSIZE / 2]; /* ASCII string */
 };
@@ -171,6 +172,7 @@ struct usb251xb_data {
 static const struct usb251xb_data usb2512b_data = {
.product_id = 0x2512,
.port_cnt = 2,
+   .led_support = false,
.bat_support = true,
.product_str = "USB2512B",
 };
@@ -178,6 +180,7 @@ static const struct usb251xb_data usb2512b_data = {
 static const struct usb251xb_data usb2512bi_data = {
.product_id = 0x2512,
.port_cnt = 2,
+   .led_support = false,
.bat_support = true,
.product_str = "USB2512Bi",
 };
@@ -185,6 +188,7 @@ static const struct usb251xb_data usb2512bi_data = {
 static const struct usb251xb_data usb2513b_data = {
.product_id = 0x2513,
.port_cnt = 3,
+   .led_support = false,
.bat_support = true,
.product_str = "USB2513B",
 };
@@ -192,6 +196,7 @@ static const struct usb251xb_data usb2513b_data = {
 static const struct usb251xb_data usb2513bi_data = {
.product_id = 0x2513,
.port_cnt = 3,
+   .led_support = false,
.bat_support = true,
.product_str = "USB2513Bi",
 };
@@ -199,6 +204,7 @@ static const struct usb251xb_data usb2513bi_data = {
 static const struct usb251xb_data usb2514b_data = {
.product_id = 0x2514,
.port_cnt = 4,
+   .led_support = false,
.bat_support = true,
.product_str = "USB2514B",
 };
@@ -206,6 +212,7 @@ static const struct usb251xb_data usb2514b_data = {
 static const struct usb251xb_data usb2514bi_data = {
.product_id = 0x2514,
.port_cnt = 4,
+   .led_support = false,
.bat_support = true,
.product_str = "USB2514Bi",
 };
@@ -213,6 +220,7 @@ static const struct usb251xb_data usb2514bi_data = {
 static const struct usb251xb_data usb2517_data = {
.product_id = 0x2517,
.port_cnt = 7,
+   .led_support = true,
.bat_support = false,
.product_str = "USB2517",
 };
@@ -220,6 +228,7 @@ static const struct usb251xb_data usb2517_data = {
 static const struct usb251xb_data usb2517i_data = {
.product_id = 0x2517,
.port_cnt = 7,
+   .led_support = true,
.bat_support = false,
.product_str = "USB2517i",
 };
@@ -443,6 +452,9 @@ static int usb251xb_get_ofdata(struct usb251xb *hub,
if (of_get_property(np, "port-mapping-mode", NULL))
hub->conf_data3 |= BIT(3);
 
+   if (data->led_support && of_get_property(np, "speed-led-mode", NULL))
+   hub->conf_data3 |= BIT(1);
+
if (of_get_property(np, "string-support", NULL))
hub->conf_data3 |= BIT(0);
 
-- 
2.12.0

[PATCH 8/9 v2] usb: usb251xb: Add max power/current dts property support

[Serge Semin]

This parameters may be varied in accordance with hardware specifics.
So lets add the corresponding settings to the usb251x driver dts
specification.

Signed-off-by: Serge Semin 
---
 Documentation/devicetree/bindings/usb/usb251xb.txt   |  6 ++
 drivers/usb/misc/usb251xb.c  | 20 
 2 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/usb251xb.txt 
b/Documentation/devicetree/bindings/usb/usb251xb.txt
index 3d84626d3..dd59a32e7 100644
--- a/Documentation/devicetree/bindings/usb/usb251xb.txt
+++ b/Documentation/devicetree/bindings/usb/usb251xb.txt
@@ -44,6 +44,12 @@ Optional properties :
device connected.
  - sp-disabled-ports : Specifies the ports which will be self-power disabled
  - bp-disabled-ports : Specifies the ports which will be bus-power disabled
+ - sp-max-{power,current} : Indicates the power/current consumed by hub from
+   an upstream port (VBUS) when operation as a self-powered hub. The value
+   is given in mA in a 0 - 100 range (default is 1mA).
+ - bp-max-{power,current} : Indicates the power/current consumed by hub from
+   an upstream port (VBUS) when operation as a bus-powered hub. The value
+   is given in mA in a 0 - 510 range (default is 100mA).
  - power-on-time-ms : Specifies the time it takes from the time the host
initiates the power-on sequence to a port until the port has adequate
power. The value is given in ms in a 0 - 510 range (default is 100ms).
diff --git a/drivers/usb/misc/usb251xb.c b/drivers/usb/misc/usb251xb.c
index c308b0006..71994b883 100644
--- a/drivers/usb/misc/usb251xb.c
+++ b/drivers/usb/misc/usb251xb.c
@@ -497,6 +497,22 @@ static int usb251xb_get_ofdata(struct usb251xb *hub,
}
}
 
+   hub->max_power_sp = USB251XB_DEF_MAX_POWER_SELF;
+   if (!of_property_read_u32(np, "sp-max-power", &property_u32))
+   hub->max_power_sp = min_t(u8, property_u32 / 2, 50);
+
+   hub->max_power_bp = USB251XB_DEF_MAX_POWER_BUS;
+   if (!of_property_read_u32(np, "bp-max-power", &property_u32))
+   hub->max_power_bp = min_t(u8, property_u32 / 2, 255);
+
+   hub->max_current_sp = USB251XB_DEF_MAX_CURRENT_SELF;
+   if (!of_property_read_u32(np, "sp-max-current", &property_u32))
+   hub->max_current_sp = min_t(u8, property_u32 / 2, 50);
+
+   hub->max_current_bp = USB251XB_DEF_MAX_CURRENT_BUS;
+   if (!of_property_read_u32(np, "bp-max-current", &property_u32))
+   hub->max_current_bp = min_t(u8, property_u32 / 2, 255);
+
hub->power_on_time = USB251XB_DEF_POWER_ON_TIME;
if (!of_property_read_u32(np, "power-on-time-ms", &property_u32))
hub->power_on_time = min_t(u8, property_u32 / 2, 255);
@@ -536,10 +552,6 @@ static int usb251xb_get_ofdata(struct usb251xb *hub,
/* The following parameters are currently not exposed to devicetree, but
 * may be as soon as needed.
 */
-   hub->max_power_sp = USB251XB_DEF_MAX_POWER_SELF;
-   hub->max_power_bp = USB251XB_DEF_MAX_POWER_BUS;
-   hub->max_current_sp = USB251XB_DEF_MAX_CURRENT_SELF;
-   hub->max_current_bp = USB251XB_DEF_MAX_CURRENT_BUS;
hub->bat_charge_en = USB251XB_DEF_BATTERY_CHARGING_ENABLE;
hub->boost_up = USB251XB_DEF_BOOST_UP;
hub->boost_57 = USB251XB_DEF_BOOST_57;
-- 
2.12.0

[PATCH 7/9 v2] usb: usb251xb: Fix property_u32 NULL pointer dereference

[Serge Semin]

The methods like of_property_read_u32 utilizing the specified
pointer permit only the pointer to a preallocated u32 storage as the
third argument. As a result the driver crashes on NULL pointer
dereference in case if "oc-delay-us" or "power-on-time-ms" declared
in dts file.

Signed-off-by: Serge Semin 
---
 drivers/usb/misc/usb251xb.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/usb/misc/usb251xb.c b/drivers/usb/misc/usb251xb.c
index 51cc53ddc..c308b0006 100644
--- a/drivers/usb/misc/usb251xb.c
+++ b/drivers/usb/misc/usb251xb.c
@@ -348,7 +348,7 @@ static int usb251xb_get_ofdata(struct usb251xb *hub,
struct device *dev = hub->dev;
struct device_node *np = dev->of_node;
int len, err, i;
-   u32 *property_u32 = NULL;
+   u32 property_u32 = 0;
const u32 *cproperty_u32;
const char *cproperty_char;
char str[USB251XB_STRING_BUFSIZE / 2];
@@ -425,16 +425,16 @@ static int usb251xb_get_ofdata(struct usb251xb *hub,
if (of_get_property(np, "dynamic-power-switching", NULL))
hub->conf_data2 |= BIT(7);
 
-   if (!of_property_read_u32(np, "oc-delay-us", property_u32)) {
-   if (*property_u32 == 100) {
+   if (!of_property_read_u32(np, "oc-delay-us", &property_u32)) {
+   if (property_u32 == 100) {
/* 100 us*/
hub->conf_data2 &= ~BIT(5);
hub->conf_data2 &= ~BIT(4);
-   } else if (*property_u32 == 4000) {
+   } else if (property_u32 == 4000) {
/* 4 ms */
hub->conf_data2 &= ~BIT(5);
hub->conf_data2 |= BIT(4);
-   } else if (*property_u32 == 16000) {
+   } else if (property_u32 == 16000) {
/* 16 ms */
hub->conf_data2 |= BIT(5);
hub->conf_data2 |= BIT(4);
@@ -498,8 +498,8 @@ static int usb251xb_get_ofdata(struct usb251xb *hub,
}
 
hub->power_on_time = USB251XB_DEF_POWER_ON_TIME;
-   if (!of_property_read_u32(np, "power-on-time-ms", property_u32))
-   hub->power_on_time = min_t(u8, *property_u32 / 2, 255);
+   if (!of_property_read_u32(np, "power-on-time-ms", &property_u32))
+   hub->power_on_time = min_t(u8, property_u32 / 2, 255);
 
if (of_property_read_u16_array(np, "language-id", &hub->lang_id, 1))
hub->lang_id = USB251XB_DEF_LANGUAGE_ID;
-- 
2.12.0

[PATCH 9/9 v2] usb: usb251xb: Use GPIO descriptor consumer interface

[Serge Semin]

The driver used to be developed with legacy GPIO API support. It's
better to use descriptor-based interface for several reasons. First
of all the legacy API doesn't support the ACTIVE_LOW/HIGH flag of dts
nodes, which is essential since different hardware may have different
GPIOs connectivity including the logical value inversion. Secondly,
by requesting the reset GPIO descriptor the driver prevent the other
applications from changing its value. And last but not least the
legacy GPIO interface should be avoided in the new code due to it
obsolescence.

Signed-off-by: Serge Semin 
---
 Documentation/devicetree/bindings/usb/usb251xb.txt |  2 +-
 drivers/usb/misc/usb251xb.c| 34 +-
 2 files changed, 15 insertions(+), 21 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/usb251xb.txt 
b/Documentation/devicetree/bindings/usb/usb251xb.txt
index dd59a32e7..7c981d556 100644
--- a/Documentation/devicetree/bindings/usb/usb251xb.txt
+++ b/Documentation/devicetree/bindings/usb/usb251xb.txt
@@ -8,10 +8,10 @@ Required properties :
"microchip,usb2512b", "microchip,usb2512bi", "microchip,usb2513b",
"microchip,usb2513bi", "microchip,usb2514b", "microchip,usb2514bi",
"microchip,usb2517", "microchip,usb2517i"
- - reset-gpios : Should specify the gpio for hub reset
  - reg : I2C address on the selected bus (default is <0x2C>)
 
 Optional properties :
+ - reset-gpios : Should specify the gpio for hub reset
  - skip-config : Skip Hub configuration, but only send the USB-Attach command
  - vendor-id : Set USB Vendor ID of the hub (16 bit, default is 0x0424)
  - product-id : Set USB Product ID of the hub (16 bit, default depends on type)
diff --git a/drivers/usb/misc/usb251xb.c b/drivers/usb/misc/usb251xb.c
index 71994b883..c2dd9742f 100644
--- a/drivers/usb/misc/usb251xb.c
+++ b/drivers/usb/misc/usb251xb.c
@@ -3,6 +3,7 @@
  * Configuration via SMBus.
  *
  * Copyright (c) 2017 SKIDATA AG
+ * Copyright (c) 2017 T-platforms
  *
  * This work is based on the USB3503 driver by Dongjin Kim and
  * a not-accepted patch by Fabien Lahoudere, see:
@@ -20,12 +21,11 @@
  */
 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 
 /* Internal Register Set Addresses & Default Values acc. to DS1692C */
@@ -127,7 +127,7 @@ struct usb251xb {
struct device *dev;
struct i2c_client *i2c;
u8 skip_config;
-   int gpio_reset;
+   struct gpio_desc *gpio_reset;
u16 vendor_id;
u16 product_id;
u16 device_id;
@@ -235,13 +235,13 @@ static const struct usb251xb_data usb2517i_data = {
 
 static void usb251xb_reset(struct usb251xb *hub, int state)
 {
-   if (!gpio_is_valid(hub->gpio_reset))
+   if (!hub->gpio_reset)
return;
 
-   gpio_set_value_cansleep(hub->gpio_reset, state);
+   gpiod_set_value_cansleep(hub->gpio_reset, state);
 
/* wait for hub recovery/stabilization */
-   if (state)
+   if (!state)
usleep_range(500, 750); /* >=500us at power on */
else
usleep_range(1, 10);/* >=1us at power down */
@@ -260,7 +260,7 @@ static int usb251xb_connect(struct usb251xb *hub)
i2c_wb[0] = 0x01;
i2c_wb[1] = USB251XB_STATUS_COMMAND_ATTACH;
 
-   usb251xb_reset(hub, 1);
+   usb251xb_reset(hub, 0);
 
err = i2c_smbus_write_i2c_block_data(hub->i2c,
USB251XB_ADDR_STATUS_COMMAND, 2, i2c_wb);
@@ -310,7 +310,7 @@ static int usb251xb_connect(struct usb251xb *hub)
i2c_wb[USB251XB_ADDR_PORT_MAP_7]= hub->port_map7;
i2c_wb[USB251XB_ADDR_STATUS_COMMAND] = USB251XB_STATUS_COMMAND_ATTACH;
 
-   usb251xb_reset(hub, 1);
+   usb251xb_reset(hub, 0);
 
/* write registers */
for (i = 0; i < (USB251XB_I2C_REG_SZ / USB251XB_I2C_WRITE_SZ); i++) {
@@ -363,19 +363,13 @@ static int usb251xb_get_ofdata(struct usb251xb *hub,
else
hub->skip_config = 0;
 
-   hub->gpio_reset = of_get_named_gpio(np, "reset-gpios", 0);
-   if (hub->gpio_reset == -EPROBE_DEFER)
+   hub->gpio_reset = devm_gpiod_get_optional(dev, "reset", GPIOD_OUT_HIGH);
+   if (PTR_ERR(hub->gpio_reset) == -EPROBE_DEFER) {
return -EPROBE_DEFER;
-   if (gpio_is_valid(hub->gpio_reset)) {
-   err = devm_gpio_request_one(dev, hub->gpio_reset,
-   GPIOF_OUT_INIT_LOW,
-   "usb251xb reset");
-   if (err) {
-   dev_err(dev,
-   "unable to request GPIO %d as reset pin (%d)\n",
-   hub->gpio_reset, err);
-   return err;
-   }
+   } else if (IS_ERR(hub->gpio_reset)) {
+   err = PTR_ERR(hub->gpio_reset);
+   dev_err(dev, "unable 

[PATCH 5/9 v2] usb: usb251xb: Add battery enable setting flag

[Serge Semin]

Battery charging settings are supported by USB251xb hubs only.
USB2517i isn't one of them. So we need to reflect it within the
device-specific data structure. The driver doesn't support dts
property to change this setting, but instead defaults it with zero.
So the flag isn't used anywhere in the driver, but still can be helpful
in future, when necessity of corresponding dts setting arises.

Signed-off-by: Serge Semin 
---
 drivers/usb/misc/usb251xb.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/usb/misc/usb251xb.c b/drivers/usb/misc/usb251xb.c
index 44fa7d084..0834729d1 100644
--- a/drivers/usb/misc/usb251xb.c
+++ b/drivers/usb/misc/usb251xb.c
@@ -164,54 +164,63 @@ struct usb251xb {
 struct usb251xb_data {
u16 product_id;
u8 port_cnt;
+   bool bat_support;
char product_str[USB251XB_STRING_BUFSIZE / 2]; /* ASCII string */
 };
 
 static const struct usb251xb_data usb2512b_data = {
.product_id = 0x2512,
.port_cnt = 2,
+   .bat_support = true,
.product_str = "USB2512B",
 };
 
 static const struct usb251xb_data usb2512bi_data = {
.product_id = 0x2512,
.port_cnt = 2,
+   .bat_support = true,
.product_str = "USB2512Bi",
 };
 
 static const struct usb251xb_data usb2513b_data = {
.product_id = 0x2513,
.port_cnt = 3,
+   .bat_support = true,
.product_str = "USB2513B",
 };
 
 static const struct usb251xb_data usb2513bi_data = {
.product_id = 0x2513,
.port_cnt = 3,
+   .bat_support = true,
.product_str = "USB2513Bi",
 };
 
 static const struct usb251xb_data usb2514b_data = {
.product_id = 0x2514,
.port_cnt = 4,
+   .bat_support = true,
.product_str = "USB2514B",
 };
 
 static const struct usb251xb_data usb2514bi_data = {
.product_id = 0x2514,
.port_cnt = 4,
+   .bat_support = true,
.product_str = "USB2514Bi",
 };
 
 static const struct usb251xb_data usb2517_data = {
.product_id = 0x2517,
.port_cnt = 7,
+   .bat_support = false,
.product_str = "USB2517",
 };
 
 static const struct usb251xb_data usb2517i_data = {
.product_id = 0x2517,
.port_cnt = 7,
+   .bat_support = false,
.product_str = "USB2517i",
 };
 
-- 
2.12.0

[PATCH 4/9 v2] usb: usb251xb: Add 5,6,7 ports boost settings

[Serge Semin]

USB electrical signaling drive strength boost bit is also supported
by USB2517 hub. Since it got three addition ports, the designers
needed to add one more register for initialization. It turned out
to be formerly reserved 0xF7. As before we just initialize it with
default zeros.

Signed-off-by: Serge Semin 
---
 drivers/usb/misc/usb251xb.c | 15 ++-
 1 file changed, 10 insertions(+), 5 deletions(-)

diff --git a/drivers/usb/misc/usb251xb.c b/drivers/usb/misc/usb251xb.c
index 3de0de93b..44fa7d084 100644
--- a/drivers/usb/misc/usb251xb.c
+++ b/drivers/usb/misc/usb251xb.c
@@ -94,8 +94,10 @@
 
 #define USB251XB_ADDR_BOOST_UP 0xF6
 #define USB251XB_DEF_BOOST_UP  0x00
-#define USB251XB_ADDR_BOOST_X  0xF8
-#define USB251XB_DEF_BOOST_X   0x00
+#define USB251XB_ADDR_BOOST_57 0xF7
+#define USB251XB_DEF_BOOST_57  0x00
+#define USB251XB_ADDR_BOOST_14 0xF8
+#define USB251XB_DEF_BOOST_14  0x00
 
 #define USB251XB_ADDR_PORT_SWAP0xFA
 #define USB251XB_DEF_PORT_SWAP 0x00
@@ -149,7 +151,8 @@ struct usb251xb {
char serial[USB251XB_STRING_BUFSIZE];
u8  bat_charge_en;
u8  boost_up;
-   u8  boost_x;
+   u8  boost_57;
+   u8  boost_14;
u8  port_swap;
u8  port_map12;
u8  port_map34;
@@ -280,7 +283,8 @@ static int usb251xb_connect(struct usb251xb *hub)
   USB251XB_STRING_BUFSIZE);
i2c_wb[USB251XB_ADDR_BATTERY_CHARGING_ENABLE] = hub->bat_charge_en;
i2c_wb[USB251XB_ADDR_BOOST_UP]  = hub->boost_up;
-   i2c_wb[USB251XB_ADDR_BOOST_X]   = hub->boost_x;
+   i2c_wb[USB251XB_ADDR_BOOST_57]  = hub->boost_57;
+   i2c_wb[USB251XB_ADDR_BOOST_14]  = hub->boost_14;
i2c_wb[USB251XB_ADDR_PORT_SWAP] = hub->port_swap;
i2c_wb[USB251XB_ADDR_PORT_MAP_12]   = hub->port_map12;
i2c_wb[USB251XB_ADDR_PORT_MAP_34]   = hub->port_map34;
@@ -517,7 +521,8 @@ static int usb251xb_get_ofdata(struct usb251xb *hub,
hub->max_current_bp = USB251XB_DEF_MAX_CURRENT_BUS;
hub->bat_charge_en = USB251XB_DEF_BATTERY_CHARGING_ENABLE;
hub->boost_up = USB251XB_DEF_BOOST_UP;
-   hub->boost_x = USB251XB_DEF_BOOST_X;
+   hub->boost_57 = USB251XB_DEF_BOOST_57;
+   hub->boost_14 = USB251XB_DEF_BOOST_14;
hub->port_swap = USB251XB_DEF_PORT_SWAP;
hub->port_map12 = USB251XB_DEF_PORT_MAP_12;
hub->port_map34 = USB251XB_DEF_PORT_MAP_34;
-- 
2.12.0

[PATCH 1/9 v2] usb: usb251xb: Add USB2517i specific struct and IDs

[Serge Semin]

There are USB2517 and USB2517i hubs, which have almost the same
registers space as already supported USB251xbi series. The difference
it in DIDs and in few functions. This patch adds the USB2517/i data
structures to the driver, so it would have different setting depending
on the device discovered on i2c-bus.

Signed-off-by: Serge Semin 
---
 Documentation/devicetree/bindings/usb/usb251xb.txt  |  3 ++-
 drivers/usb/misc/usb251xb.c | 21 -
 2 files changed, 22 insertions(+), 2 deletions(-)

diff --git a/Documentation/devicetree/bindings/usb/usb251xb.txt 
b/Documentation/devicetree/bindings/usb/usb251xb.txt
index 3957d4eda..1682d4087 100644
--- a/Documentation/devicetree/bindings/usb/usb251xb.txt
+++ b/Documentation/devicetree/bindings/usb/usb251xb.txt
@@ -6,7 +6,8 @@ Hi-Speed Controller.
 Required properties :
  - compatible : Should be "microchip,usb251xb" or one of the specific types:
"microchip,usb2512b", "microchip,usb2512bi", "microchip,usb2513b",
-   "microchip,usb2513bi", "microchip,usb2514b", "microchip,usb2514bi"
+   "microchip,usb2513bi", "microchip,usb2514b", "microchip,usb2514bi",
+   "microchip,usb2517", "microchip,usb2517i"
  - reset-gpios : Should specify the gpio for hub reset
  - reg : I2C address on the selected bus (default is <0x2C>)
 
diff --git a/drivers/usb/misc/usb251xb.c b/drivers/usb/misc/usb251xb.c
index 91f66d68b..96a8c20ac 100644
--- a/drivers/usb/misc/usb251xb.c
+++ b/drivers/usb/misc/usb251xb.c
@@ -38,6 +38,7 @@
 #define USB251XB_DEF_PRODUCT_ID_12 0x2512 /* USB2512B/12Bi */
 #define USB251XB_DEF_PRODUCT_ID_13 0x2513 /* USB2513B/13Bi */
 #define USB251XB_DEF_PRODUCT_ID_14 0x2514 /* USB2514B/14Bi */
+#define USB251XB_DEF_PRODUCT_ID_17 0x2517 /* USB2517i */
 
 #define USB251XB_ADDR_DEVICE_ID_LSB0x04
 #define USB251XB_ADDR_DEVICE_ID_MSB0x05
@@ -82,7 +83,7 @@
 
 #define USB251XB_ADDR_PRODUCT_STRING_LEN   0x14
 #define USB251XB_ADDR_PRODUCT_STRING   0x54
-#define USB251XB_DEF_PRODUCT_STRING"USB251xB/xBi"
+#define USB251XB_DEF_PRODUCT_STRING"USB251xB/xBi/7i"
 
 #define USB251XB_ADDR_SERIAL_STRING_LEN0x15
 #define USB251XB_ADDR_SERIAL_STRING0x92
@@ -186,6 +187,16 @@ static const struct usb251xb_data usb2514bi_data = {
.product_str = "USB2514Bi",
 };
 
+static const struct usb251xb_data usb2517_data = {
+   .product_id = 0x2517,
+   .product_str = "USB2517",
+};
+
+static const struct usb251xb_data usb2517i_data = {
+   .product_id = 0x2517,
+   .product_str = "USB2517i",
+};
+
 static void usb251xb_reset(struct usb251xb *hub, int state)
 {
if (!gpio_is_valid(hub->gpio_reset))
@@ -511,6 +522,12 @@ static const struct of_device_id usb251xb_of_match[] = {
.compatible = "microchip,usb2514bi",
.data = &usb2514bi_data,
}, {
+   .compatible = "microchip,usb2517",
+   .data = &usb2517_data,
+   }, {
+   .compatible = "microchip,usb2517i",
+   .data = &usb2517i_data,
+   }, {
/* sentinel */
}
 };
@@ -574,6 +591,8 @@ static const struct i2c_device_id usb251xb_id[] = {
{ "usb2513bi", 0 },
{ "usb2514b", 0 },
{ "usb2514bi", 0 },
+   { "usb2517", 0 },
+   { "usb2517i", 0 },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(i2c, usb251xb_id);
-- 
2.12.0

[PATCH 3/9 v2] usb: usb251xb: Add 5,6,7 ports mapping def setting

[Serge Semin]

USB2517 got three additionl downstream ports, which can
as well be mapped to another logical ports. USB2551xb driver
currently doesn't fully support such setting configuration
from dts file. This patch doesn't change this, but adds
usb2517 spcific ports default liner mapping.

Signed-off-by: Serge Semin 
---
 drivers/usb/misc/usb251xb.c | 12 +++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/misc/usb251xb.c b/drivers/usb/misc/usb251xb.c
index 5cb0e5570..3de0de93b 100644
--- a/drivers/usb/misc/usb251xb.c
+++ b/drivers/usb/misc/usb251xb.c
@@ -103,7 +103,11 @@
 #define USB251XB_ADDR_PORT_MAP_12  0xFB
 #define USB251XB_DEF_PORT_MAP_12   0x00
 #define USB251XB_ADDR_PORT_MAP_34  0xFC
-#define USB251XB_DEF_PORT_MAP_34   0x00 /* USB2513B/i & USB2514B/i only */
+#define USB251XB_DEF_PORT_MAP_34   0x00 /* USB251{3B/i,4B/i,7/i} only */
+#define USB251XB_ADDR_PORT_MAP_56  0xFD
+#define USB251XB_DEF_PORT_MAP_56   0x00 /* USB2517/i only */
+#define USB251XB_ADDR_PORT_MAP_7   0xFE
+#define USB251XB_DEF_PORT_MAP_70x00 /* USB2517/i only */
 
 #define USB251XB_ADDR_STATUS_COMMAND   0xFF
 #define USB251XB_STATUS_COMMAND_SMBUS_DOWN 0x04
@@ -149,6 +153,8 @@ struct usb251xb {
u8  port_swap;
u8  port_map12;
u8  port_map34;
+   u8  port_map56;
+   u8  port_map7;
u8  status;
 };
 
@@ -278,6 +284,8 @@ static int usb251xb_connect(struct usb251xb *hub)
i2c_wb[USB251XB_ADDR_PORT_SWAP] = hub->port_swap;
i2c_wb[USB251XB_ADDR_PORT_MAP_12]   = hub->port_map12;
i2c_wb[USB251XB_ADDR_PORT_MAP_34]   = hub->port_map34;
+   i2c_wb[USB251XB_ADDR_PORT_MAP_56]   = hub->port_map56;
+   i2c_wb[USB251XB_ADDR_PORT_MAP_7]= hub->port_map7;
i2c_wb[USB251XB_ADDR_STATUS_COMMAND] = USB251XB_STATUS_COMMAND_ATTACH;
 
usb251xb_reset(hub, 1);
@@ -513,6 +521,8 @@ static int usb251xb_get_ofdata(struct usb251xb *hub,
hub->port_swap = USB251XB_DEF_PORT_SWAP;
hub->port_map12 = USB251XB_DEF_PORT_MAP_12;
hub->port_map34 = USB251XB_DEF_PORT_MAP_34;
+   hub->port_map56 = USB251XB_DEF_PORT_MAP_56;
+   hub->port_map7  = USB251XB_DEF_PORT_MAP_7;
 
return 0;
 }
-- 
2.12.0

[PATCH 0/3] [media] MR800: Adjustments for usb_amradio_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 16 Sep 2017 12:35:43 +0200

Three update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
  Delete two error messages for a failed memory allocation
  Improve a size determination
  Delete an unnecessary variable initialisation

 drivers/media/radio/radio-mr800.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

-- 
2.14.1

[PATCH 1/3] [media] mr800: Delete two error messages for a failed memory allocation in usb_amradio_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 16 Sep 2017 11:23:53 +0200

Omit extra messages for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/media/radio/radio-mr800.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/media/radio/radio-mr800.c 
b/drivers/media/radio/radio-mr800.c
index c9f59129af79..63a9b92ab495 100644
--- a/drivers/media/radio/radio-mr800.c
+++ b/drivers/media/radio/radio-mr800.c
@@ -518,5 +518,4 @@ static int usb_amradio_probe(struct usb_interface *intf,
if (!radio) {
-   dev_err(&intf->dev, "kmalloc for amradio_device failed\n");
retval = -ENOMEM;
goto err;
}
@@ -526,5 +525,4 @@ static int usb_amradio_probe(struct usb_interface *intf,
if (!radio->buffer) {
-   dev_err(&intf->dev, "kmalloc for radio->buffer failed\n");
retval = -ENOMEM;
goto err_nobuf;
}
-- 
2.14.1

[PATCH 2/3] [media] mr800: Improve a size determination in usb_amradio_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 16 Sep 2017 11:34:11 +0200

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/media/radio/radio-mr800.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/radio/radio-mr800.c 
b/drivers/media/radio/radio-mr800.c
index 63a9b92ab495..7c4554ce1cf0 100644
--- a/drivers/media/radio/radio-mr800.c
+++ b/drivers/media/radio/radio-mr800.c
@@ -515,4 +515,3 @@ static int usb_amradio_probe(struct usb_interface *intf,
 
-   radio = kzalloc(sizeof(struct amradio_device), GFP_KERNEL);
-
+   radio = kzalloc(sizeof(*radio), GFP_KERNEL);
if (!radio) {
-- 
2.14.1

[PATCH 3/3] [media] mr800: Delete an unnecessary variable initialisation in usb_amradio_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 16 Sep 2017 11:39:50 +0200

The variable "retval" will eventually be set to an appropriate value
a bit later. Thus omit the explicit initialisation at the beginning.

Signed-off-by: Markus Elfring 
---
 drivers/media/radio/radio-mr800.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/radio/radio-mr800.c 
b/drivers/media/radio/radio-mr800.c
index 7c4554ce1cf0..a1f4dc9be284 100644
--- a/drivers/media/radio/radio-mr800.c
+++ b/drivers/media/radio/radio-mr800.c
@@ -511,5 +511,5 @@ static int usb_amradio_probe(struct usb_interface *intf,
const struct usb_device_id *id)
 {
struct amradio_device *radio;
-   int retval = 0;
+   int retval;
 
-- 
2.14.1

Re: [PATCH] [media] solo6x10: hide unused variable

[Anton Sviridenko]

On Fri, Sep 15, 2017 at 09:52:04PM +0200, Arnd Bergmann wrote:
> When building without CONFIG_GPIOLIB, we get a harmless
> warning about an unused variable:
> 
> drivers/media/pci/solo6x10/solo6x10-gpio.c: In function 'solo_gpio_init':
> drivers/media/pci/solo6x10/solo6x10-gpio.c:165:6: error: unused variable 
> 'ret' [-Werror=unused-variable]
> 
> This adds another #ifdef around the declaration.
> 
> Fixes: d3202d1981dc ("media: solo6x10: export hardware GPIO pins 8:31 to 
> gpiolib interface")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/media/pci/solo6x10/solo6x10-gpio.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/media/pci/solo6x10/solo6x10-gpio.c 
> b/drivers/media/pci/solo6x10/solo6x10-gpio.c
> index 3d0d1aa2f6a8..7b4641a2cb84 100644
> --- a/drivers/media/pci/solo6x10/solo6x10-gpio.c
> +++ b/drivers/media/pci/solo6x10/solo6x10-gpio.c
> @@ -162,7 +162,9 @@ static void solo_gpiochip_set(struct gpio_chip *chip,
>  
>  int solo_gpio_init(struct solo_dev *solo_dev)
>  {
> +#ifdef CONFIG_GPIOLIB
>   int ret;
> +#endif
>  
>   solo_gpio_config(solo_dev);
>  #ifdef CONFIG_GPIOLIB
> -- 
> 2.9.0
> 

Acked-by: Anton Sviridenko 

Re: [PATCH] thinkpad_acpi: Implement tablet mode resolving using GMMS method

[Henrique de Moraes Holschuh]

On Fri, 15 Sep 2017, Benjamin Berg wrote:
> Many thinkpad laptops and convertibles provide the GMMS method to
> resolve how far the laptop has been opened and whether it has been
> converted into tablet mode. This allows reporting a more precise tablet
> mode state to userspace.
> 
> The current implementation only reports a summarized tablet mode state
> which is triggered as soon as the input devices become unusable as they
> are folded away from the display.
> 
> This will work on all models where the CMMD method was used previously and
> it may also work in other cases.
> 
> Thanks to Peter Zhang of Lenovo for providing information on how to use the
> GMMS method to query the tablet mode.
> 
> Signed-off-by: Benjamin Berg 
> Cc: Peter FP1 Zhang 
> Cc: Lyude Paul 

Looks good.

Acked-by: Henrique de Moraes Holschuh 

---
  PS: please send me the documentation for CMMD/GMMS off-list.

> ---
>  drivers/platform/x86/thinkpad_acpi.c | 132 
> +++
>  1 file changed, 119 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/platform/x86/thinkpad_acpi.c 
> b/drivers/platform/x86/thinkpad_acpi.c
> index 2242d6035d9e..91fab1a13a6d 100644
> --- a/drivers/platform/x86/thinkpad_acpi.c
> +++ b/drivers/platform/x86/thinkpad_acpi.c
> @@ -310,8 +310,7 @@ static struct {
>   enum {
>   TP_HOTKEY_TABLET_NONE = 0,
>   TP_HOTKEY_TABLET_USES_MHKG,
> - /* X1 Yoga 2016, seen on BIOS N1FET44W */
> - TP_HOTKEY_TABLET_USES_CMMD,
> + TP_HOTKEY_TABLET_USES_GMMS,
>   } hotkey_tablet;
>   u32 kbdlight:1;
>   u32 light:1;
> @@ -2044,8 +2043,28 @@ static void hotkey_poll_setup(const bool may_warn);
>  
>  /* HKEY.MHKG() return bits */
>  #define TP_HOTKEY_TABLET_MASK (1 << 3)
> -/* ThinkPad X1 Yoga (2016) */
> -#define TP_EC_CMMD_TABLET_MODE 0x6
> +enum {
> + TP_ACPI_MULTI_MODE_INVALID  = 0,
> + TP_ACPI_MULTI_MODE_UNKNOWN  = 1 << 0,
> + TP_ACPI_MULTI_MODE_LAPTOP   = 1 << 1,
> + TP_ACPI_MULTI_MODE_TABLET   = 1 << 2,
> + TP_ACPI_MULTI_MODE_FLAT = 1 << 3,
> + TP_ACPI_MULTI_MODE_STAND= 1 << 4,
> + TP_ACPI_MULTI_MODE_TENT = 1 << 5,
> + TP_ACPI_MULTI_MODE_STAND_TENT   = 1 << 6,
> +};
> +
> +enum {
> + /* The following modes are considered tablet mode for the purpose of
> +  * reporting the status to userspace. i.e. in all these modes it makes
> +  * sense to disable the laptop input devices such as touchpad and
> +  * keyboard.
> +  */
> + TP_ACPI_MULTI_MODE_TABLET_LIKE  = TP_ACPI_MULTI_MODE_TABLET |
> +   TP_ACPI_MULTI_MODE_STAND |
> +   TP_ACPI_MULTI_MODE_TENT |
> +   TP_ACPI_MULTI_MODE_STAND_TENT,
> +};
>  
>  static int hotkey_get_wlsw(void)
>  {
> @@ -2066,6 +2085,90 @@ static int hotkey_get_wlsw(void)
>   return (status) ? TPACPI_RFK_RADIO_ON : TPACPI_RFK_RADIO_OFF;
>  }
>  
> +static int hotkey_gmms_get_tablet_mode(int s, int *has_tablet_mode)
> +{
> + int type = (s >> 16) & 0x;
> + int value = s & 0x;
> + int mode = TP_ACPI_MULTI_MODE_INVALID;
> + int valid_modes = 0;
> +
> + if (has_tablet_mode)
> + *has_tablet_mode = 0;
> +
> + switch (type) {
> + case 1:
> + valid_modes = TP_ACPI_MULTI_MODE_LAPTOP |
> +   TP_ACPI_MULTI_MODE_TABLET |
> +   TP_ACPI_MULTI_MODE_STAND_TENT;
> + break;
> + case 2:
> + valid_modes = TP_ACPI_MULTI_MODE_LAPTOP |
> +   TP_ACPI_MULTI_MODE_FLAT |
> +   TP_ACPI_MULTI_MODE_TABLET |
> +   TP_ACPI_MULTI_MODE_STAND |
> +   TP_ACPI_MULTI_MODE_TENT;
> + break;
> + case 3:
> + valid_modes = TP_ACPI_MULTI_MODE_LAPTOP |
> +   TP_ACPI_MULTI_MODE_FLAT;
> + break;
> + case 4:
> + valid_modes = TP_ACPI_MULTI_MODE_LAPTOP |
> +   TP_ACPI_MULTI_MODE_TABLET |
> +   TP_ACPI_MULTI_MODE_STAND |
> +   TP_ACPI_MULTI_MODE_TENT;
> + break;
> + case 5:
> + valid_modes = TP_ACPI_MULTI_MODE_LAPTOP |
> +   TP_ACPI_MULTI_MODE_FLAT |
> +   TP_ACPI_MULTI_MODE_TABLET |
> +   TP_ACPI_MULTI_MODE_STAND |
> +   TP_ACPI_MULTI_MODE_TENT;
> + break;
> + default:
> + pr_err("Unknown multi mode status type %d with value 0x%04X, 
> please report this to %s\n",
> +type, value, TPACPI_MAIL);
> + return 0;
> + }
> +
> + if (has_tablet_mode && (valid_modes & TP_ACPI_MULTI_MODE_TABLET_LIKE))
> + *has_tablet_mode = 1;
> +
> + switch (value) {
> + case 1:
> +  

Re: [Outreachy kernel] [PATCH] staging: lustre: lnet: Replace list_for_each with list_for_each_entry

[Julia Lawall]

On Fri, 15 Sep 2017, Haneen Mohammed wrote:

> Replace use of the combination of list_for_each and list_entry
> with list_for_each_entry to simplify the code and remove variables
> that are used only in list_for_each.
> Issue found and corrected using Coccinelle script:
>
> @r@
> expression head, member, e;
> type T1, T2, T3;
> iterator name list_for_each, list_for_each_entry;
> identifier pos, var;
> @@
>
> -T1 *pos;
> ...when!=pos=e;
>
> -list_for_each(pos, head)
> +list_for_each_entry(var, head, member)
> {
> ...when!=pos=e;
>when!=T3 *var;
> -var = list_entry(pos, T2, member);
> ...when!=pos=e;
> }
> ...when!=pos=e;

Actually, one could consider that there should be when != pos, not when !=
pos=e, because you need that there are no references at all to pos to be
able to delete it.  But it's true that if pos is not initialized then
there should be no other kinds of references either.  The other
possibility for initialization would be eg

f(...,&pos,...)

You could be suspicious of &pos in general.  But anyway there is no &pos
in this code.

julia

> Signed-off-by: Haneen Mohammed 

Acked-by: Julia Lawall 

> ---
>  drivers/staging/lustre/lnet/lnet/router.c | 9 ++---
>  1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/staging/lustre/lnet/lnet/router.c 
> b/drivers/staging/lustre/lnet/lnet/router.c
> index 3df101b..b8eba33 100644
> --- a/drivers/staging/lustre/lnet/lnet/router.c
> +++ b/drivers/staging/lustre/lnet/lnet/router.c
> @@ -222,15 +222,12 @@ struct lnet_remotenet *
>  lnet_find_net_locked(__u32 net)
>  {
>   struct lnet_remotenet *rnet;
> - struct list_head *tmp;
>   struct list_head *rn_list;
>
>   LASSERT(!the_lnet.ln_shutdown);
>
>   rn_list = lnet_net2rnethash(net);
> - list_for_each(tmp, rn_list) {
> - rnet = list_entry(tmp, struct lnet_remotenet, lrn_list);
> -
> + list_for_each_entry(rnet, rn_list, lrn_list) {
>   if (rnet->lrn_net == net)
>   return rnet;
>   }
> @@ -243,7 +240,6 @@ static void lnet_shuffle_seed(void)
>   __u32 lnd_type, seed[2];
>   struct timespec64 ts;
>   struct lnet_ni *ni;
> - struct list_head *tmp;
>
>   if (seeded)
>   return;
> @@ -254,8 +250,7 @@ static void lnet_shuffle_seed(void)
>* Nodes with small feet have little entropy
>* the NID for this node gives the most entropy in the low bits
>*/
> - list_for_each(tmp, &the_lnet.ln_nis) {
> - ni = list_entry(tmp, struct lnet_ni, ni_list);
> + list_for_each_entry(ni, &the_lnet.ln_nis, ni_list) {
>   lnd_type = LNET_NETTYP(LNET_NIDNET(ni->ni_nid));
>
>   if (lnd_type != LOLND)
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/20170916004148.GA25693%40Haneen.
> For more options, visit https://groups.google.com/d/optout.
>

Re: [PATCH 3/5] powerpc64: Add .opd based function descriptor dereference

[Sergey Senozhatsky]

On (09/16/17 15:13), Naveen N. Rao wrote:
[..]
> Would it be simpler to just use kernel_text_address() and dereference 
> everything else? See commit 83e840c770f2c5 ("powerpc64/elfv1: Only 
> dereference function descriptor for non-text symbols") for a related 
> patch.

I had this idea, see

lkml.kernel.org/r/20170908172528.qc2vdtxzqh777...@intel.com


-ss

[PATCH] i2c: i2c-stm32f7: make structure stm32f7_setup static

[Colin King]

From: Colin Ian King 

The structure stm32f7_setup is local to the source and does not need
to be in global scope, so make it static.

Cleans up sparse warning:
symbol 'stm32f7_setup' was not declared. Should it be static?

Signed-off-by: Colin Ian King 
---
 drivers/i2c/busses/i2c-stm32f7.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-stm32f7.c b/drivers/i2c/busses/i2c-stm32f7.c
index 47c67b0ca896..a9cb78de22e0 100644
--- a/drivers/i2c/busses/i2c-stm32f7.c
+++ b/drivers/i2c/busses/i2c-stm32f7.c
@@ -265,7 +265,7 @@ static struct stm32f7_i2c_spec i2c_specs[] = {
},
 };
 
-struct stm32f7_i2c_setup stm32f7_setup = {
+static struct stm32f7_i2c_setup stm32f7_setup = {
.rise_time = STM32F7_I2C_RISE_TIME_DEFAULT,
.fall_time = STM32F7_I2C_FALL_TIME_DEFAULT,
.dnf = STM32F7_I2C_DNF_DEFAULT,
-- 
2.14.1

Re: [PATCH v2 3/3] kernel/uprobes: Fix check for active uprobe

[Naveen N. Rao]

On 2017/09/15 05:38PM, Oleg Nesterov wrote:
> Hi Naveen,

Hi Oleg,

> 
> I forgot almost everything about this code, but at first glance this patch
> needs more comments and the changelog should be updated, at least. And in
> any case this needs more changes iirc.

Sure, thanks for the review!

> 
> On 09/14, Naveen N. Rao wrote:
> >
> > If we try to install a uprobe on a breakpoint instruction, we register the
> > probe, but refuse to install it. In this case, when the breakpoint hits, we
> > incorrectly assume that the probe hit and end up looping.
> 
> This looks confusing to me...
> 
> If we try to install a uprobe on a breakpoint instruction, uprobe_register()
> should fail and remove uprobe. The task which hits this uprobe will loop
> until this uprobe goes away, this is fine.
> 
> But there is another case and probably this is what you mean. 
> uprobe_register()
> can do nothing except insert_uprobe() if nobody mmaps this binary, and after 
> that
> uprobe_mmap()->prepare_uprobe() can fail if the original isns is int3. In this
> case this !UPROBE_COPY_INSN uprobe won't go away, and the task can loop until
> it is killed or uprobe_unregister().
> 
> Right?

You're right -- I should have elaborated.

> 
> 
> Now. The real fix should kill UPROBE_COPY_INSN altogether and simply move
> prepare_uprobe() from install_breakpoint() into __uprobe_register(), before
> it does register_for_each_vma().
> 
> The only problem is that read_mapping_page() needs "struct file *" and nobody
> confirmed that read_mapping_page(data => NULL) is fine on all filesystems.
> I think it should be fine though, and perhaps we should finally do this 
> change.

Sure. I will take a stab at this after these fixes.

> 
> 
> until then we can probably make the things a bit better, but
> 
> > Fix this by checking that the trap was actually installed in
> > find_active_uprobe().
> > 
> > Reported-by: Anton Blanchard 
> > Signed-off-by: Naveen N. Rao 
> > ---
> >  kernel/events/uprobes.c | 7 +++
> >  1 file changed, 7 insertions(+)
> > 
> > diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> > index e14eb0a6e4f3..599078e6a092 100644
> > --- a/kernel/events/uprobes.c
> > +++ b/kernel/events/uprobes.c
> > @@ -1752,6 +1752,13 @@ static struct uprobe *find_active_uprobe(unsigned 
> > long bp_vaddr, int *is_swbp)
> > uprobe = find_uprobe(inode, offset);
> > }
> >  
> > +   /* Ensure that the breakpoint was actually installed */
> > +   if (uprobe) {
> > +   smp_rmb(); /* pairs with wmb() in prepare_uprobe() */
> > +   if (unlikely(!test_bit(UPROBE_COPY_INSN, 
> > &uprobe->flags)))
> > +   uprobe = NULL;
> > +   }
> 
> I need to recall how this code works... but if we add this change, shouldn't
> we remove another similar UPROBE_COPY_INSN check in handle_swbp() and add more
> comments?

Yes, you're right. The check in handle_swbp() won't be needed anymore. I 
will make that change and re-spin.

Thanks,
Naveen

[PATCH] Staging: dgnc: Remove unused variables from structure definition

[Srishti Sharma]

Some variables in the structure were unused and hence them and
the comments associated with them can be removed.

Signed-off-by: Srishti Sharma 
---
 drivers/staging/dgnc/dgnc_driver.h | 10 --
 1 file changed, 10 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_driver.h 
b/drivers/staging/dgnc/dgnc_driver.h
index 764d6fe..2b625cc 100644
--- a/drivers/staging/dgnc/dgnc_driver.h
+++ b/drivers/staging/dgnc/dgnc_driver.h
@@ -103,8 +103,6 @@ struct board_ops {
 /**
  * struct dgnc_board - Per board information.
  * @boardnum: Board number (0 - 32).
- *
- * @type: Type of board.
  * @name: Product name.
  * @pdev: Pointer to the pci_dev structure.
  * @bd_flags: Board flags.
@@ -140,13 +138,9 @@ struct board_ops {
  * @dpastatus: Board status as defined by DPA.
  * @bd_dividend: Board/UART's specific dividend.
  * @bd_ops: Pointer to board operations structure.
- * @proc_entry_pointer: Proc/ entry
- * @dgnc_board_table: Proc/ entry
  */
 struct dgnc_board {
int boardnum;
-
-   int type;
char*name;
struct pci_dev  *pdev;
unsigned long   bd_flags;
@@ -200,10 +194,6 @@ struct dgnc_board {
uintbd_dividend;
 
struct board_ops *bd_ops;
-
-   struct proc_dir_entry *proc_entry_pointer;
-   struct dgnc_proc_entry *dgnc_board_table;
-
 };
 
 /* Unit flag definitions for un_flags. */
-- 
2.7.4

Re: [PATCH v2 1/3] kernel/uprobes: Warn if unable to install breakpoint

[Naveen N. Rao]

On 2017/09/15 05:53PM, Oleg Nesterov wrote:
> On 09/14, Naveen N. Rao wrote:
> >
> > +static void uprobe_warn(struct task_struct *t, const char *msg)
> > +{
> > +   pr_warn("uprobe: %s:%d failed to %s\n",
> > +   current->comm, current->pid, msg);
> > +}
> > +
> >  /*
> >   * valid_vma: Verify if the specified vma is an executable vma
> >   * Relax restrictions while unregistering: vm_flags might have
> > @@ -1087,7 +1093,14 @@ int uprobe_mmap(struct vm_area_struct *vma)
> > if (!fatal_signal_pending(current) &&
> > filter_chain(uprobe, UPROBE_FILTER_MMAP, vma->vm_mm)) {
> > unsigned long vaddr = offset_to_vaddr(vma, 
> > uprobe->offset);
> > -   install_breakpoint(uprobe, vma->vm_mm, vma, vaddr);
> > +   int ret = install_breakpoint(uprobe, vma->vm_mm, vma, 
> > vaddr);
> > +   if (ret) {
> > +   char msg[64];
> > +   snprintf(msg, sizeof(msg),
> > +   "setup probe at 0x%llx (%d)",
> > +   uprobe->offset, ret);
> > +   uprobe_warn(current, (const char *)msg);
> 
> Agreed, but... this is cosmetic, but I don't really like this snprintf().
> 
> I won't insist too much, but wouldn't it better to turn uprobe_warn() into
> uprobe_warn(struct task_struct *t, char *fmt, ...) ?

Good point. In fact, I think we can just use pr_fmt().

Thanks,
Naveen

[PATCH] Documentation: fix little inconsistencies

[Pavel Machek]

Fix little inconsistencies in Documentation: make case and spacing
match surrounding text.

Signed-off-by: Pavel Machek 
Reviewed-by: Darrick J. Wong 


diff --git a/Documentation/filesystems/ext4.txt 
b/Documentation/filesystems/ext4.txt
index 5a8f7f4..75236c0 100644
--- a/Documentation/filesystems/ext4.txt
+++ b/Documentation/filesystems/ext4.txt
@@ -94,10 +94,10 @@ Note: More extensive information for getting started with 
ext4 can be
 * ability to pack bitmaps and inode tables into larger virtual groups via the
   flex_bg feature
 * large file support
-* Inode allocation using large virtual block groups via flex_bg
+* inode allocation using large virtual block groups via flex_bg
 * delayed allocation
 * large block (up to pagesize) support
-* efficient new ordered mode in JBD2 and ext4(avoid using buffer head to force
+* efficient new ordered mode in JBD2 and ext4 (avoid using buffer head to force
   the ordering)
 
 [1] Filesystems with a block size of 1k may see a limit imposed by the
@@ -105,7 +105,7 @@ directory hash tree having a maximum depth of two.
 
 2.2 Candidate features for future inclusion
 
-* Online defrag (patches available but not well tested)
+* online defrag (patches available but not well tested)
 * reduced mke2fs time via lazy itable initialization in conjunction with
   the uninit_bg feature (capability to do this is available in e2fsprogs
   but a kernel thread to do lazy zeroing of unused inode table blocks
@@ -602,7 +602,7 @@ Table of Ext4 specific ioctls
  bitmaps and inode table, the userspace tool thus
  just passes the new number of blocks.
 
-EXT4_IOC_SWAP_BOOT   Swap i_blocks and associated attributes
+ EXT4_IOC_SWAP_BOOT  Swap i_blocks and associated attributes
  (like i_blocks, i_size, i_flags, ...) from
  the specified inode with inode
  EXT4_BOOT_LOADER_INO (#5). This is typically

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


signature.asc
Description: Digital signature

Re: [Outreachy kernel] [PATCH] Staging: dgnc: Remove unused variables from structure definition

[Julia Lawall]

On Sat, 16 Sep 2017, Srishti Sharma wrote:

> Some variables in the structure were unused and hence them and
> the comments associated with them can be removed.

How did you find these?  The last two can easily be checked with grep, but
that is ont the case for type.

Actually there are two structures in the file with useless
proc_entry_pointer fields.  The other one has a useless
dgnc_channel_table.  It could be reasonable to make a series to do both
structures.

julia

>
> Signed-off-by: Srishti Sharma 
> ---
>  drivers/staging/dgnc/dgnc_driver.h | 10 --
>  1 file changed, 10 deletions(-)
>
> diff --git a/drivers/staging/dgnc/dgnc_driver.h 
> b/drivers/staging/dgnc/dgnc_driver.h
> index 764d6fe..2b625cc 100644
> --- a/drivers/staging/dgnc/dgnc_driver.h
> +++ b/drivers/staging/dgnc/dgnc_driver.h
> @@ -103,8 +103,6 @@ struct board_ops {
>  /**
>   * struct dgnc_board - Per board information.
>   * @boardnum: Board number (0 - 32).
> - *
> - * @type: Type of board.
>   * @name: Product name.
>   * @pdev: Pointer to the pci_dev structure.
>   * @bd_flags: Board flags.
> @@ -140,13 +138,9 @@ struct board_ops {
>   * @dpastatus: Board status as defined by DPA.
>   * @bd_dividend: Board/UART's specific dividend.
>   * @bd_ops: Pointer to board operations structure.
> - * @proc_entry_pointer: Proc/ entry
> - * @dgnc_board_table: Proc/ entry
>   */
>  struct dgnc_board {
>   int boardnum;
> -
> - int type;
>   char*name;
>   struct pci_dev  *pdev;
>   unsigned long   bd_flags;
> @@ -200,10 +194,6 @@ struct dgnc_board {
>   uintbd_dividend;
>
>   struct board_ops *bd_ops;
> -
> - struct proc_dir_entry *proc_entry_pointer;
> - struct dgnc_proc_entry *dgnc_board_table;
> -
>  };
>
>  /* Unit flag definitions for un_flags. */
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/1505562186-11813-1-git-send-email-srishtishar%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

[PATCH] Documentation: fix ascii art in networking docs

[Pavel Machek]

Fix ascii-art.

Signed-off-by: Pavel Machek 

diff --git a/Documentation/networking/switchdev.txt 
b/Documentation/networking/switchdev.txt
index 5e40e1f..6309e90 100644
--- a/Documentation/networking/switchdev.txt
+++ b/Documentation/networking/switchdev.txt
@@ -29,7 +29,7 @@ with SR-IOV or soft switches, such as OVS, are possible.
   sw1p1  +  sw1p3  +  sw1p5  +  eth1
 +|+|+|+
 |||||||
- +--++++-+--++---+  +-+-+
+ +--++++++---+  +-+-+
  | Switch driver |  |mgmt   |
  |(this document)|  |   driver  |
  |   |  |   |

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


signature.asc
Description: Digital signature

Re: [Outreachy kernel] [PATCH] Staging: dgnc: Remove unused variables from structure definition

[Srishti Sharma]

On Sat, Sep 16, 2017 at 5:20 PM, Julia Lawall  wrote:
>
>
> On Sat, 16 Sep 2017, Srishti Sharma wrote:
>
>> Some variables in the structure were unused and hence them and
>> the comments associated with them can be removed.
>
> How did you find these?  The last two can easily be checked with grep, but
> that is ont the case for type.

I removed them and then compiled the code to see if it still compiles.
I was using grep earlier to see if the fields in the structure are
ever accessed by the variables of that structure type, as the TODO of
the driver says that there is a lot of unneeded code.
>
> Actually there are two structures in the file with useless
> proc_entry_pointer fields.  The other one has a useless
> dgnc_channel_table.  It could be reasonable to make a series to do both
> structures.

Okay, I'll send them as a series. Thanks

Regards,
Srishti

> julia
>
>>
>> Signed-off-by: Srishti Sharma 
>> ---
>>  drivers/staging/dgnc/dgnc_driver.h | 10 --
>>  1 file changed, 10 deletions(-)
>>
>> diff --git a/drivers/staging/dgnc/dgnc_driver.h 
>> b/drivers/staging/dgnc/dgnc_driver.h
>> index 764d6fe..2b625cc 100644
>> --- a/drivers/staging/dgnc/dgnc_driver.h
>> +++ b/drivers/staging/dgnc/dgnc_driver.h
>> @@ -103,8 +103,6 @@ struct board_ops {
>>  /**
>>   * struct dgnc_board - Per board information.
>>   * @boardnum: Board number (0 - 32).
>> - *
>> - * @type: Type of board.
>>   * @name: Product name.
>>   * @pdev: Pointer to the pci_dev structure.
>>   * @bd_flags: Board flags.
>> @@ -140,13 +138,9 @@ struct board_ops {
>>   * @dpastatus: Board status as defined by DPA.
>>   * @bd_dividend: Board/UART's specific dividend.
>>   * @bd_ops: Pointer to board operations structure.
>> - * @proc_entry_pointer: Proc/ entry
>> - * @dgnc_board_table: Proc/ entry
>>   */
>>  struct dgnc_board {
>>   int boardnum;
>> -
>> - int type;
>>   char*name;
>>   struct pci_dev  *pdev;
>>   unsigned long   bd_flags;
>> @@ -200,10 +194,6 @@ struct dgnc_board {
>>   uintbd_dividend;
>>
>>   struct board_ops *bd_ops;
>> -
>> - struct proc_dir_entry *proc_entry_pointer;
>> - struct dgnc_proc_entry *dgnc_board_table;
>> -
>>  };
>>
>>  /* Unit flag definitions for un_flags. */
>> --
>> 2.7.4
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "outreachy-kernel" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to outreachy-kernel+unsubscr...@googlegroups.com.
>> To post to this group, send email to outreachy-ker...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/outreachy-kernel/1505562186-11813-1-git-send-email-srishtishar%40gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>>

Re: [Outreachy kernel] [PATCH] Staging: dgnc: Remove unused variables from structure definition

[Julia Lawall]

On Sat, 16 Sep 2017, Srishti Sharma wrote:

> On Sat, Sep 16, 2017 at 5:20 PM, Julia Lawall  wrote:
> >
> >
> > On Sat, 16 Sep 2017, Srishti Sharma wrote:
> >
> >> Some variables in the structure were unused and hence them and
> >> the comments associated with them can be removed.
> >
> > How did you find these?  The last two can easily be checked with grep, but
> > that is ont the case for type.
>
> I removed them and then compiled the code to see if it still compiles.

This is not 100% reliable because of the possibility of uses inside
ifdefs.  So you need to double check that you have found every occurrence
of the structure type for the type field.  The others seem not dangerous.

julia

> I was using grep earlier to see if the fields in the structure are
> ever accessed by the variables of that structure type, as the TODO of
> the driver says that there is a lot of unneeded code.
> >
> > Actually there are two structures in the file with useless
> > proc_entry_pointer fields.  The other one has a useless
> > dgnc_channel_table.  It could be reasonable to make a series to do both
> > structures.
>
> Okay, I'll send them as a series. Thanks
>
> Regards,
> Srishti
>
> > julia
> >
> >>
> >> Signed-off-by: Srishti Sharma 
> >> ---
> >>  drivers/staging/dgnc/dgnc_driver.h | 10 --
> >>  1 file changed, 10 deletions(-)
> >>
> >> diff --git a/drivers/staging/dgnc/dgnc_driver.h 
> >> b/drivers/staging/dgnc/dgnc_driver.h
> >> index 764d6fe..2b625cc 100644
> >> --- a/drivers/staging/dgnc/dgnc_driver.h
> >> +++ b/drivers/staging/dgnc/dgnc_driver.h
> >> @@ -103,8 +103,6 @@ struct board_ops {
> >>  /**
> >>   * struct dgnc_board - Per board information.
> >>   * @boardnum: Board number (0 - 32).
> >> - *
> >> - * @type: Type of board.
> >>   * @name: Product name.
> >>   * @pdev: Pointer to the pci_dev structure.
> >>   * @bd_flags: Board flags.
> >> @@ -140,13 +138,9 @@ struct board_ops {
> >>   * @dpastatus: Board status as defined by DPA.
> >>   * @bd_dividend: Board/UART's specific dividend.
> >>   * @bd_ops: Pointer to board operations structure.
> >> - * @proc_entry_pointer: Proc/ entry
> >> - * @dgnc_board_table: Proc/ entry
> >>   */
> >>  struct dgnc_board {
> >>   int boardnum;
> >> -
> >> - int type;
> >>   char*name;
> >>   struct pci_dev  *pdev;
> >>   unsigned long   bd_flags;
> >> @@ -200,10 +194,6 @@ struct dgnc_board {
> >>   uintbd_dividend;
> >>
> >>   struct board_ops *bd_ops;
> >> -
> >> - struct proc_dir_entry *proc_entry_pointer;
> >> - struct dgnc_proc_entry *dgnc_board_table;
> >> -
> >>  };
> >>
> >>  /* Unit flag definitions for un_flags. */
> >> --
> >> 2.7.4
> >>
> >> --
> >> You received this message because you are subscribed to the Google Groups 
> >> "outreachy-kernel" group.
> >> To unsubscribe from this group and stop receiving emails from it, send an 
> >> email to outreachy-kernel+unsubscr...@googlegroups.com.
> >> To post to this group, send email to outreachy-ker...@googlegroups.com.
> >> To view this discussion on the web visit 
> >> https://groups.google.com/d/msgid/outreachy-kernel/1505562186-11813-1-git-send-email-srishtishar%40gmail.com.
> >> For more options, visit https://groups.google.com/d/optout.
> >>
>

[PATCH 0/3] [media] WL1273: Adjustments for two function implementations

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 16 Sep 2017 14:05:45 +0200

Three update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
  Delete an error message for a failed memory allocation
  Delete an unnecessary goto statement
  Delete an unnecessary variable initialisation

 drivers/media/radio/radio-wl1273.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

-- 
2.14.1

Re: [PATCH] drm/radeon: properly initialize r600_audio_status() data

[Christian König]

Am 15.09.2017 um 22:06 schrieb Arnd Bergmann:

The structure returned from r600_audio_status() is only partially
initialized, and older gcc versions (4.3 and 4.4) warn about this:

drivers/gpu/drm/radeon/r600_hdmi.c: In function 'r600_audio_status':
drivers/gpu/drm/radeon/r600_hdmi.c:108: error: 'status.id' is used 
uninitialized in this function
drivers/gpu/drm/radeon/r600_hdmi.c:108: error: 'status.connected' is used 
uninitialized in this function
drivers/gpu/drm/radeon/r600_hdmi.c:108: error: 'status.offset' is used 
uninitialized in this function

This is harmless and surprisingly correct in C99, as the caller
only accesses the fields that got initialized, so newer compilers
don't warn about it, but initializing the entire structure feels
like the right thing to do here and avoids the warning.

Signed-off-by: Arnd Bergmann 


Reviewed-by: Christian König 


---
  drivers/gpu/drm/radeon/r600_hdmi.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/radeon/r600_hdmi.c 
b/drivers/gpu/drm/radeon/r600_hdmi.c
index e82a99cb2459..ab32830c4e23 100644
--- a/drivers/gpu/drm/radeon/r600_hdmi.c
+++ b/drivers/gpu/drm/radeon/r600_hdmi.c
@@ -58,7 +58,7 @@ enum r600_hdmi_iec_status_bits {
  
  static struct r600_audio_pin r600_audio_status(struct radeon_device *rdev)

  {
-   struct r600_audio_pin status;
+   struct r600_audio_pin status = {};
uint32_t value;
  
  	value = RREG32(R600_AUDIO_RATE_BPS_CHANNEL);

[PATCH 1/3] [media] WL1273: Delete an error message for a failed memory allocation in wl1273_fm_radio_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 16 Sep 2017 13:28:38 +0200

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/media/radio/radio-wl1273.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/radio/radio-wl1273.c 
b/drivers/media/radio/radio-wl1273.c
index 903fcd5e99c0..020a792173f6 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -2034,5 +2034,4 @@ static int wl1273_fm_radio_probe(struct platform_device 
*pdev)
if (!radio->buffer) {
-   pr_err("Cannot allocate memory for RDS buffer.\n");
r = -ENOMEM;
goto pdata_err;
}
-- 
2.14.1

[PATCH 2/3] [media] WL1273: Delete an unnecessary goto statement in wl1273_fm_suspend()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 16 Sep 2017 13:53:22 +0200

* Remove an extra goto statement.

* Delete the label "out" which became unnecessary with this refactoring.

Signed-off-by: Markus Elfring 
---
 drivers/media/radio/radio-wl1273.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/media/radio/radio-wl1273.c 
b/drivers/media/radio/radio-wl1273.c
index 020a792173f6..74dc3195ea2c 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -683,12 +683,9 @@ static int wl1273_fm_suspend(struct wl1273_device *radio)
else
r = -EINVAL;
 
-   if (r) {
+   if (r)
dev_err(radio->dev, "%s: POWER_SET fails: %d\n", __func__, r);
-   goto out;
-   }
 
-out:
return r;
 }
 
-- 
2.14.1

[PATCH 3/3] [media] WL1273: Delete an unnecessary variable initialisation in wl1273_fm_suspend()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 16 Sep 2017 13:55:56 +0200

The local variable "r" will be set to an appropriate value a bit later.
Thus omit the explicit initialisation at the beginning.

Signed-off-by: Markus Elfring 
---
 drivers/media/radio/radio-wl1273.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/radio/radio-wl1273.c 
b/drivers/media/radio/radio-wl1273.c
index 74dc3195ea2c..b8f08bfc31c3 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -671,6 +671,6 @@ static int wl1273_fm_start(struct wl1273_device *radio, int 
new_mode)
 static int wl1273_fm_suspend(struct wl1273_device *radio)
 {
struct wl1273_core *core = radio->core;
-   int r = 0;
+   int r;
 
/* Cannot go from OFF to SUSPENDED */
-- 
2.14.1

Re: [FYI] GCC segfaults under heavy multithreaded compilation with AMD Ryzen

[Satoru Takeuchi]

2017-08-11 19:07 GMT+09:00 Borislav Petkov :
> On Wed, Jul 26, 2017 at 06:54:01AM +0900, Satoru Takeuchi wrote:
>> # I'm a LKML subscriber, but not a x86 list subscriber
>>
>> I found the following new linux kernel bugzilla about Ryzen related problem.
>> Since many developers don't check this bugzilla and I've also
>> encountered this problem,
>> I decided to introduce this problem here.
>>
>> https://bugzilla.kernel.org/show_bug.cgi?id=196481:
>> > I am running Ubuntu and installed the mainline kernel from the mainline 
>> > PPA.
>> > It seems like the Ryzen processor has some bug that leads to gcc crashing
>> > when compiling a very large program under heavy load. This is easily 
>> > reproduced
>> > in my system using the script from
>> >
>> > https://github.com/suaefar/ryzen-test
>> >
>> > (It assumes that you are running Ubuntu, maybe Debian also works. Just 
>> > clone it and run the > script kill_ryzen.sh. It downloads the gcc 7.1 code 
>> > and start multiple compilations of it. If any
>> > compilations fails its warns the user giving the time to detect failure).
>> >
>> > There is already a bug report about this in the FreeBSD bugzilla
>> > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=219399#c89).
>> > There is also a thread on the subject in AMD community forum
>> > (https://community.amd.com/thread/215773?start=300&tstart=0)
>> > and Phoronix 
>> > (https://www.phoronix.com/forums/forum/hardware/processors-memory/955368-some-ryzen-linux-users-are-facing-issues-with-heavy-compilation-loads).
>
> Apparently, you can RMA your CPU:
>
> https://www.phoronix.com/scan.php?page=news_item&px=Ryzen-Segv-Response
>

Sorry for late reply and thank you for letting me know. I've already RMA'ed my
CPU and the new one works fine. I have one more Ryzen which I got for
investigating
this problem and I'll RMA it soon.

Regards,
Satoru

> --
> Regards/Gruss,
> Boris.
>
> ECO tip #101: Trim your mails when you reply.
> --

Re: [Outreachy kernel] [PATCH] Staging: dgnc: Remove unused variables from structure definition

[Srishti Sharma]

On Sat, Sep 16, 2017 at 5:45 PM, Julia Lawall  wrote:
>
>
> On Sat, 16 Sep 2017, Srishti Sharma wrote:
>
>> On Sat, Sep 16, 2017 at 5:20 PM, Julia Lawall  wrote:
>> >
>> >
>> > On Sat, 16 Sep 2017, Srishti Sharma wrote:
>> >
>> >> Some variables in the structure were unused and hence them and
>> >> the comments associated with them can be removed.
>> >
>> > How did you find these?  The last two can easily be checked with grep, but
>> > that is ont the case for type.
>>
>> I removed them and then compiled the code to see if it still compiles.
>
> This is not 100% reliable because of the possibility of uses inside
> ifdefs.  So you need to double check that you have found every occurrence
> of the structure type for the type field.  The others seem not dangerous.

Okay, I'll do that . Thanks

Srishti
>
> julia
>
>> I was using grep earlier to see if the fields in the structure are
>> ever accessed by the variables of that structure type, as the TODO of
>> the driver says that there is a lot of unneeded code.
>> >
>> > Actually there are two structures in the file with useless
>> > proc_entry_pointer fields.  The other one has a useless
>> > dgnc_channel_table.  It could be reasonable to make a series to do both
>> > structures.
>>
>> Okay, I'll send them as a series. Thanks
>>
>> Regards,
>> Srishti
>>
>> > julia
>> >
>> >>
>> >> Signed-off-by: Srishti Sharma 
>> >> ---
>> >>  drivers/staging/dgnc/dgnc_driver.h | 10 --
>> >>  1 file changed, 10 deletions(-)
>> >>
>> >> diff --git a/drivers/staging/dgnc/dgnc_driver.h 
>> >> b/drivers/staging/dgnc/dgnc_driver.h
>> >> index 764d6fe..2b625cc 100644
>> >> --- a/drivers/staging/dgnc/dgnc_driver.h
>> >> +++ b/drivers/staging/dgnc/dgnc_driver.h
>> >> @@ -103,8 +103,6 @@ struct board_ops {
>> >>  /**
>> >>   * struct dgnc_board - Per board information.
>> >>   * @boardnum: Board number (0 - 32).
>> >> - *
>> >> - * @type: Type of board.
>> >>   * @name: Product name.
>> >>   * @pdev: Pointer to the pci_dev structure.
>> >>   * @bd_flags: Board flags.
>> >> @@ -140,13 +138,9 @@ struct board_ops {
>> >>   * @dpastatus: Board status as defined by DPA.
>> >>   * @bd_dividend: Board/UART's specific dividend.
>> >>   * @bd_ops: Pointer to board operations structure.
>> >> - * @proc_entry_pointer: Proc/ entry
>> >> - * @dgnc_board_table: Proc/ entry
>> >>   */
>> >>  struct dgnc_board {
>> >>   int boardnum;
>> >> -
>> >> - int type;
>> >>   char*name;
>> >>   struct pci_dev  *pdev;
>> >>   unsigned long   bd_flags;
>> >> @@ -200,10 +194,6 @@ struct dgnc_board {
>> >>   uintbd_dividend;
>> >>
>> >>   struct board_ops *bd_ops;
>> >> -
>> >> - struct proc_dir_entry *proc_entry_pointer;
>> >> - struct dgnc_proc_entry *dgnc_board_table;
>> >> -
>> >>  };
>> >>
>> >>  /* Unit flag definitions for un_flags. */
>> >> --
>> >> 2.7.4
>> >>
>> >> --
>> >> You received this message because you are subscribed to the Google Groups 
>> >> "outreachy-kernel" group.
>> >> To unsubscribe from this group and stop receiving emails from it, send an 
>> >> email to outreachy-kernel+unsubscr...@googlegroups.com.
>> >> To post to this group, send email to outreachy-ker...@googlegroups.com.
>> >> To view this discussion on the web visit 
>> >> https://groups.google.com/d/msgid/outreachy-kernel/1505562186-11813-1-git-send-email-srishtishar%40gmail.com.
>> >> For more options, visit https://groups.google.com/d/optout.
>> >>
>>

Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Pavel Machek]

Hi!

>  These patch series add the LED_BRIGHTNESS_FAST flag support for
>  ledtrig-transient to use hrtimer so that platforms with high-resolution 
>  timer
>  support can have better accuracy in the trigger duration timing. The 
>  need for
...
> > If we want to say "lets move all vibrations from input to LED
> > subsystem"... I don't think that is good idea, but its a valid
> > discussion. Some good reasons would be needed.
> > 
> > But having half devices use one interface and half use different one
> > is just bad... especially when only reason to do it that way is
> > "David wants to do it that way, android library made a mistake and he
> > now wants it to propagate to whole world".
> 
> This is not the only reason. Adding hr_timer support to
> ledtrig-transient (and similarly to ledtrig-timer) would allow
> to increase the accuracy and stability of delay_on/delay_off
> intervals at low values.
> 
> Do you think such an improvement could be harmful in some way,
> even if it was made optional?

Of course, we can make LED timing accurate down to microseconds. It will
mean increased overhead -- for "improvement" human can not perceive.

If someone has problems with LED delays not being accurate enough... we
may want to fix it. But that is not the case here, is it?
Pavel

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

[Part1 PATCH v4 00/17] x86: Secure Encrypted Virtualization (AMD)

[Brijesh Singh]

This part of Secure Encrypted Virtualization (SEV) series focuses on the
changes required in a guest OS for SEV support.

When SEV is active, the memory content of guest OS will be transparently 
encrypted
with a key unique to the guest VM.

SEV guests have concept of private and shared memory. Private memory is 
encrypted
with the guest-specific key, while shared memory may be encrypted with 
hypervisor
key. Certain type of memory (namely insruction pages and guest page tables) are
always treated as private. Due to security reasons all DMA operations inside the
guest must be performed on shared memory.

The SEV feature is enabled by the hypervisor, and guest can identify it through
CPUID function and the 0xc0010131 (F17H_SEV) MSR. When enabled, page table 
entries
will determine how memory is accessed. If a page table entry has the memory
encryption mask set, then that memory will be accessed using guest-specific key.
Certain memory (instruction pages, page tables) will always be accessed using
guest-specific key.

This patch series builds upon the Secure Memory Encryption (SME) feature. Unlike
SME, when SEV is enabled, all the data (e.g EFI, kernel, initrd, etc) will have
been placed into memory as encrypted by the guest BIOS.

The approach that this patch series takes is to encrypt everything possible
starting early in the boot. Since the DMA operations inside guest must be
performed on shared memory hence it uses SW-IOTLB to complete the DMA 
operations.

The following links provide additional details:

AMD Memory Encryption whitepaper:
http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf


AMD64 Architecture Programmer's Manual:
http://support.amd.com/TechDocs/24593.pdf
SME is section 7.10
SEV is section 15.34

Secure Encrypted Virutualization Key Management:
http://support.amd.com/TechDocs/55766_SEV-KM API_Specification.pdf

KVM Forum Presentation:
http://www.linux-kvm.org/images/7/74/02x08A-Thomas_Lendacky-AMDs_Virtualizatoin_Memory_Encryption_Technology.pdf


SEV Guest BIOS support:
  SEV support has been accepted into EDKII/OVMF BIOS
  https://github.com/tianocore/edk2/commits/master

---
This series is based on tip/master commit : e3b4bfd351fa (Merge branch 
'WIP.x86/apic').
Complete git tree is available: https://github.com/codomania/tip/tree/sev-v4-p1

Changes since v3:
 * use static key to branch the unrolling of rep ins/outs when SEV is active
 * simplify the memory encryption detection logic
 * rename per-cpu define to DEFINE_PER_CPU_UNENCRYPTED
 * simplfy the logic to map per-cpu as unencrypted
 * changes to address v3 feedbacks

Changes since v2:
 * add documentation
 * update early_set_memory_* to use kernel_physical_mapping_init()
   to split larger page into smaller (recommended by Boris)
 * changes to address v2 feedback
 * drop hypervisor specific patches, those patches will be included in part 2

Brijesh Singh (5):
  Documentation/x86: Add AMD Secure Encrypted Virtualization (SEV)
description
  x86: Add support for changing memory encryption attribute in early
boot
  percpu: introduce DEFINE_PER_CPU_UNENCRYPTED
  X86/KVM: Unencrypt shared per-cpu variables when SEV is active
  X86/KVM: Clear encryption attribute when SEV is active

Tom Lendacky (12):
  x86/mm: Add Secure Encrypted Virtualization (SEV) support
  x86/mm: Don't attempt to encrypt initrd under SEV
  x86/realmode: Don't decrypt trampoline area under SEV
  x86/mm: Use encrypted access of boot related data with SEV
  x86/mm: Include SEV for encryption memory attribute changes
  x86/efi: Access EFI data as encrypted when SEV is active
  resource: Consolidate resource walking code
  resource: Provide resource struct in resource walk callback
  x86/mm, resource: Use PAGE_KERNEL protection for ioremap of memory
pages
  x86/mm: DMA support for SEV memory encryption
  x86/boot: Add early boot support when running with SEV active
  x86/io: Unroll string I/O when SEV is active

 Documentation/x86/amd-memory-encryption.txt |  30 ++-
 arch/powerpc/kernel/machine_kexec_file_64.c |  12 +-
 arch/x86/boot/compressed/Makefile   |   1 +
 arch/x86/boot/compressed/head_64.S  |  16 ++
 arch/x86/boot/compressed/mem_encrypt.S  | 115 +++
 arch/x86/boot/compressed/misc.h |   2 +
 arch/x86/boot/compressed/pagetable.c|   8 +-
 arch/x86/entry/vdso/vma.c   |   5 +-
 arch/x86/include/asm/io.h   |  42 +++-
 arch/x86/include/asm/mem_encrypt.h  |  23 +++
 arch/x86/include/asm/msr-index.h|   3 +
 arch/x86/include/uapi/asm/kvm_para.h|   1 -
 arch/x86/kernel/crash.c |  18 +-
 arch/x86/kernel/kvm.c   |  46 -
 arch/x86/kernel/kvmclock.c  |  65 +--
 arch/x86/kernel/pmem.c  |   2 +-
 arch/x86/kernel/setup.c |   6 +-
 arch/x86/mm/ioremap.c   | 121 +++

[Part1 PATCH v4 03/17] x86/mm: Don't attempt to encrypt initrd under SEV

[Brijesh Singh]

From: Tom Lendacky 

When SEV is active the initrd/initramfs will already have already been
placed in memory encrypted so do not try to encrypt it.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Borislav Petkov 
Cc: Andy Lutomirski 
Cc: linux-kernel@vger.kernel.org
Cc: x...@kernel.org
Signed-off-by: Tom Lendacky 
Signed-off-by: Brijesh Singh 
---
 arch/x86/kernel/setup.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 82559867e0a9..967155e63afe 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -368,9 +368,11 @@ static void __init reserve_initrd(void)
 * If SME is active, this memory will be marked encrypted by the
 * kernel when it is accessed (including relocation). However, the
 * ramdisk image was loaded decrypted by the bootloader, so make
-* sure that it is encrypted before accessing it.
+* sure that it is encrypted before accessing it. For SEV the
+* ramdisk will already be encrypted, so only do this for SME.
 */
-   sme_early_encrypt(ramdisk_image, ramdisk_end - ramdisk_image);
+   if (sme_active())
+   sme_early_encrypt(ramdisk_image, ramdisk_end - ramdisk_image);
 
initrd_start = 0;
 
-- 
2.9.5

[Part1 PATCH v4 10/17] x86/mm, resource: Use PAGE_KERNEL protection for ioremap of memory pages

[Brijesh Singh]

From: Tom Lendacky 

In order for memory pages to be properly mapped when SEV is active, we
need to use the PAGE_KERNEL protection attribute as the base protection.
This will insure that memory mapping of, e.g. ACPI tables, receives the
proper mapping attributes.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Borislav Petkov 
Cc: "Kirill A. Shutemov" 
Cc: Laura Abbott 
Cc: Andy Lutomirski 
Cc: "Jérôme Glisse" 
Cc: Andrew Morton 
Cc: Dan Williams 
Cc: Kees Cook 
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Tom Lendacky 
Signed-off-by: Brijesh Singh 
---
 arch/x86/mm/ioremap.c  | 77 ++
 include/linux/ioport.h |  3 ++
 kernel/resource.c  | 19 +
 3 files changed, 88 insertions(+), 11 deletions(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 52cc0f4ed494..812b8a8066ba 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -27,6 +27,11 @@
 
 #include "physaddr.h"
 
+struct ioremap_mem_flags {
+   bool system_ram;
+   bool desc_other;
+};
+
 /*
  * Fix up the linear direct mapping of the kernel to avoid cache attribute
  * conflicts.
@@ -56,19 +61,61 @@ int ioremap_change_attr(unsigned long vaddr, unsigned long 
size,
return err;
 }
 
-static int __ioremap_check_ram(unsigned long start_pfn, unsigned long nr_pages,
-  void *arg)
+static int __ioremap_check_ram(struct resource *res)
 {
+   unsigned long start_pfn, stop_pfn;
unsigned long i;
 
-   for (i = 0; i < nr_pages; ++i)
-   if (pfn_valid(start_pfn + i) &&
-   !PageReserved(pfn_to_page(start_pfn + i)))
-   return 1;
+   if ((res->flags & IORESOURCE_SYSTEM_RAM) != IORESOURCE_SYSTEM_RAM)
+   return 0;
+
+   start_pfn = (res->start + PAGE_SIZE - 1) >> PAGE_SHIFT;
+   stop_pfn = (res->end + 1) >> PAGE_SHIFT;
+   if (stop_pfn > start_pfn) {
+   for (i = 0; i < (stop_pfn - start_pfn); ++i)
+   if (pfn_valid(start_pfn + i) &&
+   !PageReserved(pfn_to_page(start_pfn + i)))
+   return 1;
+   }
 
return 0;
 }
 
+static int __ioremap_check_desc_other(struct resource *res)
+{
+   return (res->desc != IORES_DESC_NONE);
+}
+
+static int __ioremap_res_check(struct resource *res, void *arg)
+{
+   struct ioremap_mem_flags *flags = arg;
+
+   if (!flags->system_ram)
+   flags->system_ram = __ioremap_check_ram(res);
+
+   if (!flags->desc_other)
+   flags->desc_other = __ioremap_check_desc_other(res);
+
+   return flags->system_ram && flags->desc_other;
+}
+
+/*
+ * To avoid multiple resource walks, this function walks resources marked as
+ * IORESOURCE_MEM and IORESOURCE_BUSY and looking for system RAM and/or a
+ * resource described not as IORES_DESC_NONE (e.g. IORES_DESC_ACPI_TABLES).
+ */
+static void __ioremap_check_mem(resource_size_t addr, unsigned long size,
+   struct ioremap_mem_flags *flags)
+{
+   u64 start, end;
+
+   start = (u64)addr;
+   end = start + size - 1;
+   memset(flags, 0, sizeof(*flags));
+
+   walk_mem_res(start, end, flags, __ioremap_res_check);
+}
+
 /*
  * Remap an arbitrary physical address space into the kernel virtual
  * address space. It transparently creates kernel huge I/O mapping when
@@ -87,9 +134,10 @@ static void __iomem *__ioremap_caller(resource_size_t 
phys_addr,
unsigned long size, enum page_cache_mode pcm, void *caller)
 {
unsigned long offset, vaddr;
-   resource_size_t pfn, last_pfn, last_addr;
+   resource_size_t last_addr;
const resource_size_t unaligned_phys_addr = phys_addr;
const unsigned long unaligned_size = size;
+   struct ioremap_mem_flags mem_flags;
struct vm_struct *area;
enum page_cache_mode new_pcm;
pgprot_t prot;
@@ -108,13 +156,12 @@ static void __iomem *__ioremap_caller(resource_size_t 
phys_addr,
return NULL;
}
 
+   __ioremap_check_mem(phys_addr, size, &mem_flags);
+
/*
 * Don't allow anybody to remap normal RAM that we're using..
 */
-   pfn  = phys_addr >> PAGE_SHIFT;
-   last_pfn = last_addr >> PAGE_SHIFT;
-   if (walk_system_ram_range(pfn, last_pfn - pfn + 1, NULL,
- __ioremap_check_ram) == 1) {
+   if (mem_flags.system_ram) {
WARN_ONCE(1, "ioremap on RAM at %pa - %pa\n",
  &phys_addr, &last_addr);
return NULL;
@@ -146,7 +193,15 @@ static void __iomem *__ioremap_caller(resource_size_t 
phys_addr,
pcm = new_pcm;
}
 
+   /*
+* If the page being mapped is in memory and SEV is active then
+* make sure the memory encryption attribute is enabled in the
+* resulting mappi

[Part1 PATCH v4 16/17] X86/KVM: Unencrypt shared per-cpu variables when SEV is active

[Brijesh Singh]

When SEV is active, guest memory is encrypted with guest-specific key, a
guest memory region shared with hypervisor must be mapped as unencrypted
before we share it.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Borislav Petkov 
Cc: Paolo Bonzini 
Cc: "Radim Krčmář" 
Cc: Tom Lendacky 
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: k...@vger.kernel.org
Signed-off-by: Brijesh Singh 
---
 arch/x86/kernel/kvm.c | 46 +++---
 1 file changed, 43 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 874827b0d7ca..9ccb48b027e4 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -75,8 +75,8 @@ static int parse_no_kvmclock_vsyscall(char *arg)
 
 early_param("no-kvmclock-vsyscall", parse_no_kvmclock_vsyscall);
 
-static DEFINE_PER_CPU(struct kvm_vcpu_pv_apf_data, apf_reason) __aligned(64);
-static DEFINE_PER_CPU(struct kvm_steal_time, steal_time) __aligned(64);
+static DEFINE_PER_CPU_UNENCRYPTED(struct kvm_vcpu_pv_apf_data, apf_reason) 
__aligned(64);
+static DEFINE_PER_CPU_UNENCRYPTED(struct kvm_steal_time, steal_time) 
__aligned(64);
 static int has_steal_clock = 0;
 
 /*
@@ -305,7 +305,7 @@ static void kvm_register_steal_time(void)
cpu, (unsigned long long) slow_virt_to_phys(st));
 }
 
-static DEFINE_PER_CPU(unsigned long, kvm_apic_eoi) = KVM_PV_EOI_DISABLED;
+static DEFINE_PER_CPU_UNENCRYPTED(unsigned long, kvm_apic_eoi) = 
KVM_PV_EOI_DISABLED;
 
 static notrace void kvm_guest_apic_eoi_write(u32 reg, u32 val)
 {
@@ -419,9 +419,46 @@ void kvm_disable_steal_time(void)
wrmsr(MSR_KVM_STEAL_TIME, 0, 0);
 }
 
+static inline void __init __set_percpu_var_unencrypted(
+   void *var, int size)
+{
+   unsigned long pa = slow_virt_to_phys(var);
+
+   /* decrypt the memory in-place */
+   sme_early_decrypt(pa, size);
+
+   /* clear the C-bit from the page table */
+   early_set_memory_decrypted(pa, size);
+}
+
+/*
+ * Iterate through all possible CPUs and map the memory region pointed
+ * by apf_reason, steal_time and kvm_apic_eoi as unencrypted at once.
+ *
+ * Note: we iterate through all possible CPUs to ensure that CPUs
+ * hotplugged will have their per-cpu variable already mapped as
+ * unencrypted.
+ */
+static void __init set_percpu_unencrypted(void)
+{
+   int cpu;
+
+   for_each_possible_cpu(cpu) {
+   __set_percpu_var_unencrypted(&per_cpu(apf_reason, cpu),
+   sizeof(struct kvm_vcpu_pv_apf_data));
+   __set_percpu_var_unencrypted(&per_cpu(steal_time, cpu),
+   sizeof(struct kvm_steal_time));
+   __set_percpu_var_unencrypted(&per_cpu(kvm_apic_eoi, cpu),
+   sizeof(unsigned long));
+   }
+}
+
 #ifdef CONFIG_SMP
 static void __init kvm_smp_prepare_boot_cpu(void)
 {
+   if (sev_active())
+   set_percpu_unencrypted();
+
kvm_guest_cpu_init();
native_smp_prepare_boot_cpu();
kvm_spinlock_init();
@@ -489,6 +526,9 @@ void __init kvm_guest_init(void)
  kvm_cpu_online, kvm_cpu_down_prepare) < 0)
pr_err("kvm_guest: Failed to install cpu hotplug callbacks\n");
 #else
+   if (sev_active())
+   set_percpu_unencrypted();
+
kvm_guest_cpu_init();
 #endif
 
-- 
2.9.5

[Part1 PATCH v4 08/17] resource: Consolidate resource walking code

[Brijesh Singh]

From: Tom Lendacky 

The walk_iomem_res_desc(), walk_system_ram_res() and walk_system_ram_range()
functions each have much of the same code.  Create a new function that
consolidates the common code from these functions in one place to reduce
the amount of duplicated code.

Cc: Borislav Petkov 
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Tom Lendacky 
Signed-off-by: Brijesh Singh 
---
 kernel/resource.c | 52 +---
 1 file changed, 25 insertions(+), 27 deletions(-)

diff --git a/kernel/resource.c b/kernel/resource.c
index 9b5f04404152..7323c1b636cd 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -400,6 +400,26 @@ static int find_next_iomem_res(struct resource *res, 
unsigned long desc,
return 0;
 }
 
+static int __walk_iomem_res_desc(struct resource *res, unsigned long desc,
+bool first_level_children_only,
+void *arg, int (*func)(u64, u64, void *))
+{
+   u64 orig_end = res->end;
+   int ret = -1;
+
+   while ((res->start < res->end) &&
+  !find_next_iomem_res(res, desc, first_level_children_only)) {
+   ret = (*func)(res->start, res->end, arg);
+   if (ret)
+   break;
+
+   res->start = res->end + 1;
+   res->end = orig_end;
+   }
+
+   return ret;
+}
+
 /*
  * Walks through iomem resources and calls func() with matching resource
  * ranges. This walks through whole tree and not just first level children.
@@ -418,26 +438,12 @@ int walk_iomem_res_desc(unsigned long desc, unsigned long 
flags, u64 start,
u64 end, void *arg, int (*func)(u64, u64, void *))
 {
struct resource res;
-   u64 orig_end;
-   int ret = -1;
 
res.start = start;
res.end = end;
res.flags = flags;
-   orig_end = res.end;
-
-   while ((res.start < res.end) &&
-   (!find_next_iomem_res(&res, desc, false))) {
-
-   ret = (*func)(res.start, res.end, arg);
-   if (ret)
-   break;
-
-   res.start = res.end + 1;
-   res.end = orig_end;
-   }
 
-   return ret;
+   return __walk_iomem_res_desc(&res, desc, false, arg, func);
 }
 
 /*
@@ -451,22 +457,13 @@ int walk_system_ram_res(u64 start, u64 end, void *arg,
int (*func)(u64, u64, void *))
 {
struct resource res;
-   u64 orig_end;
-   int ret = -1;
 
res.start = start;
res.end = end;
res.flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY;
-   orig_end = res.end;
-   while ((res.start < res.end) &&
-   (!find_next_iomem_res(&res, IORES_DESC_NONE, true))) {
-   ret = (*func)(res.start, res.end, arg);
-   if (ret)
-   break;
-   res.start = res.end + 1;
-   res.end = orig_end;
-   }
-   return ret;
+
+   return __walk_iomem_res_desc(&res, IORES_DESC_NONE, true,
+arg, func);
 }
 
 #if !defined(CONFIG_ARCH_HAS_WALK_MEMORY)
@@ -508,6 +505,7 @@ static int __is_ram(unsigned long pfn, unsigned long 
nr_pages, void *arg)
 {
return 1;
 }
+
 /*
  * This generic page_is_ram() returns true if specified address is
  * registered as System RAM in iomem_resource list.
-- 
2.9.5

[Part1 PATCH v4 17/17] X86/KVM: Clear encryption attribute when SEV is active

[Brijesh Singh]

The guest physical memory area holding the struct pvclock_wall_clock and
struct pvclock_vcpu_time_info are shared with the hypervisor. Hypervisor
periodically updates the contents of the memory. When SEV is active, we
must clear the encryption attributes from the shared memory pages so that
both hypervisor and guest can access the data.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Borislav Petkov 
Cc: Paolo Bonzini 
Cc: "Radim Krčmář" 
Cc: Tom Lendacky 
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: k...@vger.kernel.org
Signed-off-by: Brijesh Singh 
---
 arch/x86/entry/vdso/vma.c  |  5 ++--
 arch/x86/kernel/kvmclock.c | 65 ++
 2 files changed, 57 insertions(+), 13 deletions(-)

diff --git a/arch/x86/entry/vdso/vma.c b/arch/x86/entry/vdso/vma.c
index 1911310959f8..d63053142b16 100644
--- a/arch/x86/entry/vdso/vma.c
+++ b/arch/x86/entry/vdso/vma.c
@@ -114,10 +114,11 @@ static int vvar_fault(const struct vm_special_mapping *sm,
struct pvclock_vsyscall_time_info *pvti =
pvclock_pvti_cpu0_va();
if (pvti && vclock_was_used(VCLOCK_PVCLOCK)) {
-   ret = vm_insert_pfn(
+   ret = vm_insert_pfn_prot(
vma,
vmf->address,
-   __pa(pvti) >> PAGE_SHIFT);
+   __pa(pvti) >> PAGE_SHIFT,
+   pgprot_decrypted(vma->vm_page_prot));
}
} else if (sym_offset == image->sym_hvclock_page) {
struct ms_hyperv_tsc_page *tsc_pg = hv_get_tsc_page();
diff --git a/arch/x86/kernel/kvmclock.c b/arch/x86/kernel/kvmclock.c
index d88967659098..3de184be0887 100644
--- a/arch/x86/kernel/kvmclock.c
+++ b/arch/x86/kernel/kvmclock.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -45,7 +46,7 @@ early_param("no-kvmclock", parse_no_kvmclock);
 
 /* The hypervisor will put information about time periodically here */
 static struct pvclock_vsyscall_time_info *hv_clock;
-static struct pvclock_wall_clock wall_clock;
+static struct pvclock_wall_clock *wall_clock;
 
 struct pvclock_vsyscall_time_info *pvclock_pvti_cpu0_va(void)
 {
@@ -64,15 +65,15 @@ static void kvm_get_wallclock(struct timespec *now)
int low, high;
int cpu;
 
-   low = (int)__pa_symbol(&wall_clock);
-   high = ((u64)__pa_symbol(&wall_clock) >> 32);
+   low = (int)slow_virt_to_phys(wall_clock);
+   high = ((u64)slow_virt_to_phys(wall_clock) >> 32);
 
native_write_msr(msr_kvm_wall_clock, low, high);
 
cpu = get_cpu();
 
vcpu_time = &hv_clock[cpu].pvti;
-   pvclock_read_wallclock(&wall_clock, vcpu_time, now);
+   pvclock_read_wallclock(wall_clock, vcpu_time, now);
 
put_cpu();
 }
@@ -249,11 +250,39 @@ static void kvm_shutdown(void)
native_machine_shutdown();
 }
 
+static phys_addr_t __init kvm_memblock_alloc(phys_addr_t size,
+phys_addr_t align)
+{
+   phys_addr_t mem;
+
+   mem = memblock_alloc(size, align);
+   if (!mem)
+   return 0;
+
+   if (sev_active()) {
+   if (early_set_memory_decrypted(mem, size))
+   goto e_free;
+   }
+
+   return mem;
+e_free:
+   memblock_free(mem, size);
+   return 0;
+}
+
+static void __init kvm_memblock_free(phys_addr_t addr, phys_addr_t size)
+{
+   if (sev_active())
+   early_set_memory_encrypted(addr, size);
+
+   memblock_free(addr, size);
+}
+
 void __init kvmclock_init(void)
 {
struct pvclock_vcpu_time_info *vcpu_time;
-   unsigned long mem;
-   int size, cpu;
+   unsigned long mem, mem_wall_clock;
+   int size, cpu, wall_clock_size;
u8 flags;
 
size = PAGE_ALIGN(sizeof(struct pvclock_vsyscall_time_info)*NR_CPUS);
@@ -267,21 +296,35 @@ void __init kvmclock_init(void)
} else if (!(kvmclock && kvm_para_has_feature(KVM_FEATURE_CLOCKSOURCE)))
return;
 
-   printk(KERN_INFO "kvm-clock: Using msrs %x and %x",
-   msr_kvm_system_time, msr_kvm_wall_clock);
+   wall_clock_size = PAGE_ALIGN(sizeof(struct pvclock_wall_clock));
+   mem_wall_clock = kvm_memblock_alloc(wall_clock_size, PAGE_SIZE);
+   if (!mem_wall_clock)
+   return;
 
-   mem = memblock_alloc(size, PAGE_SIZE);
-   if (!mem)
+   wall_clock = __va(mem_wall_clock);
+   memset(wall_clock, 0, wall_clock_size);
+
+   mem = kvm_memblock_alloc(size, PAGE_SIZE);
+   if (!mem) {
+   kvm_memblock_free(mem_wall_clock, wall_clock_size);
+   wall_clock = NULL;
return;
+   }
+
hv_clock = __va(mem);
memset(hv_clock, 0, size);
 
if (kvm_register_clock("primary cpu clock")) {
hv_clock = NULL;
- 

[Part1 PATCH v4 15/17] percpu: introduce DEFINE_PER_CPU_UNENCRYPTED

[Brijesh Singh]

When SEV is active, memory is encrypted with guest-specific key, and if
guest OS wants to share the memory region with hypervisor then it must
clear the C-bit (i.e set unencrypted) before sharing it.

DEFINE_PER_CPU_UNENCRYPTED can be used to define the per-cpu variables
which will be shared between guest and hypervisor. Currently, KVM defines
three variables (steal-time, apf_reason, and avic_eio) which are shared
with hypervisor.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Borislav Petkov 
Cc: Arnd Bergmann 
Cc: Tejun Heo 
Cc: Christoph Lameter 
Cc: linux-a...@vger.kernel.org
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Tom Lendacky 
Signed-off-by: Brijesh Singh 
---
 include/asm-generic/vmlinux.lds.h | 11 +++
 include/linux/percpu-defs.h   | 15 +++
 2 files changed, 26 insertions(+)

diff --git a/include/asm-generic/vmlinux.lds.h 
b/include/asm-generic/vmlinux.lds.h
index 8acfc1e099e1..363858f43cbc 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -777,6 +777,16 @@
 #define INIT_RAM_FS
 #endif
 
+#ifdef CONFIG_AMD_MEM_ENCRYPT
+#define PERCPU_UNENCRYPTED_SECTION \
+   . = ALIGN(PAGE_SIZE);   \
+   *(.data..percpu..unencrypted)   \
+   . = ALIGN(PAGE_SIZE);
+#else
+#define PERCPU_UNENCRYPTED_SECTION
+#endif
+
+
 /*
  * Default discarded sections.
  *
@@ -815,6 +825,7 @@
. = ALIGN(cacheline);   \
*(.data..percpu)\
*(.data..percpu..shared_aligned)\
+   PERCPU_UNENCRYPTED_SECTION  \
VMLINUX_SYMBOL(__per_cpu_end) = .;
 
 /**
diff --git a/include/linux/percpu-defs.h b/include/linux/percpu-defs.h
index 8f16299ca068..b2b99ad4b31d 100644
--- a/include/linux/percpu-defs.h
+++ b/include/linux/percpu-defs.h
@@ -173,6 +173,21 @@
DEFINE_PER_CPU_SECTION(type, name, "..read_mostly")
 
 /*
+ * Declaration/definition used for per-CPU variables that should be accessed
+ * as unencrypted when memory encryption is enabled in the guest.
+ */
+#if defined(CONFIG_VIRTUALIZATION) && defined(CONFIG_AMD_MEM_ENCRYPT)
+
+#define DECLARE_PER_CPU_UNENCRYPTED(type, name)
\
+   DECLARE_PER_CPU_SECTION(type, name, "..unencrypted")
+
+#define DEFINE_PER_CPU_UNENCRYPTED(type, name) \
+   DEFINE_PER_CPU_SECTION(type, name, "..unencrypted")
+#else
+#define DEFINE_PER_CPU_UNENCRYPTED(type, name) DEFINE_PER_CPU(type, name)
+#endif
+
+/*
  * Intermodule exports for per-CPU variables.  sparse forgets about
  * address space across EXPORT_SYMBOL(), change EXPORT_SYMBOL() to
  * noop if __CHECKER__.
-- 
2.9.5

[Part1 PATCH v4 14/17] x86: Add support for changing memory encryption attribute in early boot

[Brijesh Singh]

Some KVM-specific custom MSRs share the guest physical address with the
hypervisor in early boot. When SEV is active, the shared physical address
must be mapped with memory encryption attribute cleared so that both
hypervisor and guest can access the data.

Add APIs to change the memory encryption attribute in early boot code.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Borislav Petkov 
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: Tom Lendacky 
Signed-off-by: Brijesh Singh 
---
 arch/x86/include/asm/mem_encrypt.h |  17 ++
 arch/x86/mm/mem_encrypt.c  | 121 +
 2 files changed, 138 insertions(+)

diff --git a/arch/x86/include/asm/mem_encrypt.h 
b/arch/x86/include/asm/mem_encrypt.h
index 2b024741bce9..21b9d8fc8293 100644
--- a/arch/x86/include/asm/mem_encrypt.h
+++ b/arch/x86/include/asm/mem_encrypt.h
@@ -42,6 +42,11 @@ void __init sme_early_init(void);
 void __init sme_encrypt_kernel(void);
 void __init sme_enable(struct boot_params *bp);
 
+int __init early_set_memory_decrypted(resource_size_t paddr,
+ unsigned long size);
+int __init early_set_memory_encrypted(resource_size_t paddr,
+ unsigned long size);
+
 /* Architecture __weak replacement functions */
 void __init mem_encrypt_init(void);
 
@@ -70,6 +75,18 @@ static inline void __init sme_enable(struct boot_params *bp) 
{ }
 static inline bool sme_active(void) { return false; }
 static inline bool sev_active(void) { return false; }
 
+static inline int __init early_set_memory_decrypted(resource_size_t paddr,
+   unsigned long size)
+{
+   return 0;
+}
+
+static inline int __init early_set_memory_encrypted(resource_size_t paddr,
+   unsigned long size)
+{
+   return 0;
+}
+
 #endif /* CONFIG_AMD_MEM_ENCRYPT */
 
 /*
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index b361fabde4c8..cecdf52f3c70 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -28,6 +28,8 @@
 #include 
 #include 
 
+#include "mm_internal.h"
+
 static char sme_cmdline_arg[] __initdata = "mem_encrypt";
 static char sme_cmdline_on[]  __initdata = "on";
 static char sme_cmdline_off[] __initdata = "off";
@@ -258,6 +260,125 @@ static void sme_free(struct device *dev, size_t size, 
void *vaddr,
swiotlb_free_coherent(dev, size, vaddr, dma_handle);
 }
 
+static void __init __set_clr_pte_enc(pte_t *kpte, int level, bool enc)
+{
+   pgprot_t old_prot, new_prot;
+   unsigned long pfn;
+   pte_t new_pte;
+
+   switch (level) {
+   case PG_LEVEL_4K:
+   pfn = pte_pfn(*kpte);
+   old_prot = pte_pgprot(*kpte);
+   break;
+   case PG_LEVEL_2M:
+   pfn = pmd_pfn(*(pmd_t *)kpte);
+   old_prot = pmd_pgprot(*(pmd_t *)kpte);
+   break;
+   case PG_LEVEL_1G:
+   pfn = pud_pfn(*(pud_t *)kpte);
+   old_prot = pud_pgprot(*(pud_t *)kpte);
+   break;
+   default:
+   return;
+   }
+
+   new_prot = old_prot;
+   if (enc)
+   pgprot_val(new_prot) |= _PAGE_ENC;
+   else
+   pgprot_val(new_prot) &= ~_PAGE_ENC;
+
+   /* if prot is same then do nothing */
+   if (pgprot_val(old_prot) == pgprot_val(new_prot))
+   return;
+
+   new_pte = pfn_pte(pfn, new_prot);
+   set_pte_atomic(kpte, new_pte);
+}
+
+static int __init early_set_memory_enc_dec(resource_size_t paddr,
+  unsigned long size, bool enc)
+{
+   unsigned long vaddr, vaddr_end, vaddr_next;
+   unsigned long psize, pmask;
+   int split_page_size_mask;
+   pte_t *kpte;
+   int level, ret;
+
+   vaddr = (unsigned long)__va(paddr);
+   vaddr_next = vaddr;
+   vaddr_end = vaddr + size;
+
+   /*
+* We are going to change the physical page attribute from C=1 to C=0
+* or vice versa. Flush the caches to ensure that data is written into
+* memory with correct C-bit before we change attribute.
+*/
+   clflush_cache_range(__va(paddr), size);
+
+   for (; vaddr < vaddr_end; vaddr = vaddr_next) {
+   kpte = lookup_address(vaddr, &level);
+   if (!kpte || pte_none(*kpte)) {
+   ret = 1;
+   goto out;
+   }
+
+   if (level == PG_LEVEL_4K) {
+   __set_clr_pte_enc(kpte, level, enc);
+   vaddr_next = (vaddr & PAGE_MASK) + PAGE_SIZE;
+   continue;
+   }
+
+   psize = page_level_size(level);
+   pmask = page_level_mask(level);
+
+   /*
+* Check, whether we can change the large page in one go.
+* We request a split, when the addr

[Part1 PATCH v4 12/17] x86/boot: Add early boot support when running with SEV active

[Brijesh Singh]

From: Tom Lendacky 

Early in the boot process, add checks to determine if the kernel is
running with Secure Encrypted Virtualization (SEV) active.

Checking for SEV requires checking that the kernel is running under a
hypervisor (CPUID 0x0001, bit 31), that the SEV feature is available
(CPUID 0x801f, bit 1) and then checking a non-interceptable SEV MSR
(0xc0010131, bit 0).

This check is required so that during early compressed kernel booting the
pagetables (both the boot pagetables and KASLR pagetables (if enabled) are
updated to include the encryption mask so that when the kernel is
decompressed into encrypted memory, it can boot properly.

After the kernel is decompressed and continues booting the same logic is
used to check if SEV is active and set a flag indicating so.  This allows
us to distinguish between SME and SEV, each of which have unique
differences in how certain things are handled: e.g. DMA (always bounce
buffered with SEV) or EFI tables (always access decrypted with SME).

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Borislav Petkov 
Cc: Konrad Rzeszutek Wilk 
Cc: "Kirill A. Shutemov" 
Cc: Laura Abbott 
Cc: Andy Lutomirski 
Cc: Kees Cook 
Cc: Paolo Bonzini 
Cc: "Radim Krčmář" 
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Tom Lendacky 
Signed-off-by: Brijesh Singh 
---
 arch/x86/boot/compressed/Makefile  |   1 +
 arch/x86/boot/compressed/head_64.S |  16 +
 arch/x86/boot/compressed/mem_encrypt.S | 115 +
 arch/x86/boot/compressed/misc.h|   2 +
 arch/x86/boot/compressed/pagetable.c   |   8 ++-
 arch/x86/include/asm/msr-index.h   |   3 +
 arch/x86/include/uapi/asm/kvm_para.h   |   1 -
 arch/x86/mm/mem_encrypt.c  |  50 ++
 8 files changed, 181 insertions(+), 15 deletions(-)
 create mode 100644 arch/x86/boot/compressed/mem_encrypt.S

diff --git a/arch/x86/boot/compressed/Makefile 
b/arch/x86/boot/compressed/Makefile
index 8a958274b54c..7fc5b7168e4f 100644
--- a/arch/x86/boot/compressed/Makefile
+++ b/arch/x86/boot/compressed/Makefile
@@ -77,6 +77,7 @@ vmlinux-objs-$(CONFIG_EARLY_PRINTK) += 
$(obj)/early_serial_console.o
 vmlinux-objs-$(CONFIG_RANDOMIZE_BASE) += $(obj)/kaslr.o
 ifdef CONFIG_X86_64
vmlinux-objs-$(CONFIG_RANDOMIZE_BASE) += $(obj)/pagetable.o
+   vmlinux-objs-y += $(obj)/mem_encrypt.o
 endif
 
 $(obj)/eboot.o: KBUILD_CFLAGS += -fshort-wchar -mno-red-zone
diff --git a/arch/x86/boot/compressed/head_64.S 
b/arch/x86/boot/compressed/head_64.S
index b4a5d284391c..3dfad60720d0 100644
--- a/arch/x86/boot/compressed/head_64.S
+++ b/arch/x86/boot/compressed/head_64.S
@@ -130,6 +130,19 @@ ENTRY(startup_32)
  /*
   * Build early 4G boot pagetable
   */
+   /*
+* If SEV is active then set the encryption mask in the page tables.
+* This will insure that when the kernel is copied and decompressed
+* it will be done so encrypted.
+*/
+   callget_sev_encryption_bit
+   xorl%edx, %edx
+   testl   %eax, %eax
+   jz  1f
+   subl$32, %eax   /* Encryption bit is always above bit 31 */
+   bts %eax, %edx  /* Set encryption mask for page tables */
+1:
+
/* Initialize Page tables to 0 */
lealpgtable(%ebx), %edi
xorl%eax, %eax
@@ -140,12 +153,14 @@ ENTRY(startup_32)
lealpgtable + 0(%ebx), %edi
leal0x1007 (%edi), %eax
movl%eax, 0(%edi)
+   addl%edx, 4(%edi)
 
/* Build Level 3 */
lealpgtable + 0x1000(%ebx), %edi
leal0x1007(%edi), %eax
movl$4, %ecx
 1: movl%eax, 0x00(%edi)
+   addl%edx, 0x04(%edi)
addl$0x1000, %eax
addl$8, %edi
decl%ecx
@@ -156,6 +171,7 @@ ENTRY(startup_32)
movl$0x0183, %eax
movl$2048, %ecx
 1: movl%eax, 0(%edi)
+   addl%edx, 4(%edi)
addl$0x0020, %eax
addl$8, %edi
decl%ecx
diff --git a/arch/x86/boot/compressed/mem_encrypt.S 
b/arch/x86/boot/compressed/mem_encrypt.S
new file mode 100644
index ..03149c77c749
--- /dev/null
+++ b/arch/x86/boot/compressed/mem_encrypt.S
@@ -0,0 +1,115 @@
+/*
+ * AMD Memory Encryption Support
+ *
+ * Copyright (C) 2017 Advanced Micro Devices, Inc.
+ *
+ * Author: Tom Lendacky 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+
+   .text
+   .code32
+ENTRY(get_sev_encryption_bit)
+   xor %eax, %eax
+
+#ifdef CONFIG_AMD_MEM_ENCRYPT
+   push%ebx
+   push%ecx
+   push%edx
+   push%edi
+
+   call1f
+1: popl%edi
+   subl$1b, %edi
+
+   movlenc_bit(%edi), %eax
+   cmpl$0, %eax
+   jge .Lsev_exi

[Part1 PATCH v4 11/17] x86/mm: DMA support for SEV memory encryption

[Brijesh Singh]

From: Tom Lendacky 

DMA access to encrypted memory cannot be performed when SEV is active.
In order for DMA to properly work when SEV is active, the SWIOTLB bounce
buffers must be used.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Borislav Petkov 
Cc: Konrad Rzeszutek Wilk 
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Tom Lendacky 
Signed-off-by: Brijesh Singh 
---
 arch/x86/mm/mem_encrypt.c | 86 +++
 lib/swiotlb.c |  5 +--
 2 files changed, 89 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 4e6dcabe52fc..967f116ec65e 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -190,6 +190,70 @@ void __init sme_early_init(void)
/* Update the protection map with memory encryption mask */
for (i = 0; i < ARRAY_SIZE(protection_map); i++)
protection_map[i] = pgprot_encrypted(protection_map[i]);
+
+   if (sev_active())
+   swiotlb_force = SWIOTLB_FORCE;
+}
+
+static void *sme_alloc(struct device *dev, size_t size, dma_addr_t *dma_handle,
+  gfp_t gfp, unsigned long attrs)
+{
+   unsigned long dma_mask;
+   unsigned int order;
+   struct page *page;
+   void *vaddr = NULL;
+
+   dma_mask = dma_alloc_coherent_mask(dev, gfp);
+   order = get_order(size);
+
+   /*
+* Memory will be memset to zero after marking decrypted, so don't
+* bother clearing it before.
+*/
+   gfp &= ~__GFP_ZERO;
+
+   page = alloc_pages_node(dev_to_node(dev), gfp, order);
+   if (page) {
+   dma_addr_t addr;
+
+   /*
+* Since we will be clearing the encryption bit, check the
+* mask with it already cleared.
+*/
+   addr = __sme_clr(phys_to_dma(dev, page_to_phys(page)));
+   if ((addr + size) > dma_mask) {
+   __free_pages(page, get_order(size));
+   } else {
+   vaddr = page_address(page);
+   *dma_handle = addr;
+   }
+   }
+
+   if (!vaddr)
+   vaddr = swiotlb_alloc_coherent(dev, size, dma_handle, gfp);
+
+   if (!vaddr)
+   return NULL;
+
+   /* Clear the SME encryption bit for DMA use if not swiotlb area */
+   if (!is_swiotlb_buffer(dma_to_phys(dev, *dma_handle))) {
+   set_memory_decrypted((unsigned long)vaddr, 1 << order);
+   memset(vaddr, 0, PAGE_SIZE << order);
+   *dma_handle = __sme_clr(*dma_handle);
+   }
+
+   return vaddr;
+}
+
+static void sme_free(struct device *dev, size_t size, void *vaddr,
+dma_addr_t dma_handle, unsigned long attrs)
+{
+   /* Set the SME encryption bit for re-use if not swiotlb area */
+   if (!is_swiotlb_buffer(dma_to_phys(dev, dma_handle)))
+   set_memory_encrypted((unsigned long)vaddr,
+1 << get_order(size));
+
+   swiotlb_free_coherent(dev, size, vaddr, dma_handle);
 }
 
 /*
@@ -216,6 +280,20 @@ bool sev_active(void)
 }
 EXPORT_SYMBOL_GPL(sev_active);
 
+static const struct dma_map_ops sev_dma_ops = {
+   .alloc  = sme_alloc,
+   .free   = sme_free,
+   .map_page   = swiotlb_map_page,
+   .unmap_page = swiotlb_unmap_page,
+   .map_sg = swiotlb_map_sg_attrs,
+   .unmap_sg   = swiotlb_unmap_sg_attrs,
+   .sync_single_for_cpu= swiotlb_sync_single_for_cpu,
+   .sync_single_for_device = swiotlb_sync_single_for_device,
+   .sync_sg_for_cpu= swiotlb_sync_sg_for_cpu,
+   .sync_sg_for_device = swiotlb_sync_sg_for_device,
+   .mapping_error  = swiotlb_dma_mapping_error,
+};
+
 /* Architecture __weak replacement functions */
 void __init mem_encrypt_init(void)
 {
@@ -225,6 +303,14 @@ void __init mem_encrypt_init(void)
/* Call into SWIOTLB to update the SWIOTLB DMA buffers */
swiotlb_update_mem_attributes();
 
+   /*
+* With SEV, DMA operations cannot use encryption. New DMA ops
+* are required in order to mark the DMA areas as decrypted or
+* to use bounce buffers.
+*/
+   if (sev_active())
+   dma_ops = &sev_dma_ops;
+
pr_info("AMD Secure Memory Encryption (SME) active\n");
 }
 
diff --git a/lib/swiotlb.c b/lib/swiotlb.c
index 8c6c83ef57a4..cea19aaf303c 100644
--- a/lib/swiotlb.c
+++ b/lib/swiotlb.c
@@ -507,8 +507,9 @@ phys_addr_t swiotlb_tbl_map_single(struct device *hwdev,
if (no_iotlb_memory)
panic("Can not allocate SWIOTLB buffer earlier and can't now 
provide you with the DMA bounce buffer");
 
-   if (sme_active())
-   pr_warn_once("SME is active and system is using DMA bounce 
buffers\n");
+   if (m

[Part1 PATCH v4 13/17] x86/io: Unroll string I/O when SEV is active

[Brijesh Singh]

From: Tom Lendacky 

Secure Encrypted Virtualization (SEV) does not support string I/O, so
unroll the string I/O operation into a loop operating on one element at
a time.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Borislav Petkov 
Cc: Andy Shevchenko 
Cc: David Laight 
Cc: Arnd Bergmann 
Cc: x...@kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Tom Lendacky 
Signed-off-by: Brijesh Singh 
---
 arch/x86/include/asm/io.h | 42 ++
 arch/x86/mm/mem_encrypt.c |  8 
 2 files changed, 46 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/io.h b/arch/x86/include/asm/io.h
index c40a95c33bb8..07c28ee398d9 100644
--- a/arch/x86/include/asm/io.h
+++ b/arch/x86/include/asm/io.h
@@ -265,6 +265,20 @@ static inline void slow_down_io(void)
 
 #endif
 
+#ifdef CONFIG_AMD_MEM_ENCRYPT
+
+extern struct static_key_false __sev;
+static inline bool __sev_active(void)
+{
+   return static_branch_unlikely(&__sev);
+}
+
+#else /* !CONFIG_AMD_MEM_ENCRYPT */
+
+static inline bool __sev_active(void) { return false; }
+
+#endif /* CONFIG_AMD_MEM_ENCRYPT */
+
 #define BUILDIO(bwl, bw, type) \
 static inline void out##bwl(unsigned type value, int port) \
 {  \
@@ -295,14 +309,34 @@ static inline unsigned type in##bwl##_p(int port) 
\
\
 static inline void outs##bwl(int port, const void *addr, unsigned long count) \
 {  \
-   asm volatile("rep; outs" #bwl   \
-: "+S"(addr), "+c"(count) : "d"(port) : "memory"); \
+   if (__sev_active()) {   \
+   unsigned type *value = (unsigned type *)addr;   \
+   while (count) { \
+   out##bwl(*value, port); \
+   value++;\
+   count--;\
+   }   \
+   } else {\
+   asm volatile("rep; outs" #bwl   \
+: "+S"(addr), "+c"(count)  \
+: "d"(port) : "memory");   \
+   }   \
 }  \
\
 static inline void ins##bwl(int port, void *addr, unsigned long count) \
 {  \
-   asm volatile("rep; ins" #bwl\
-: "+D"(addr), "+c"(count) : "d"(port) : "memory"); \
+   if (__sev_active()) {   \
+   unsigned type *value = (unsigned type *)addr;   \
+   while (count) { \
+   *value = in##bwl(port); \
+   value++;\
+   count--;\
+   }   \
+   } else {\
+   asm volatile("rep; ins" #bwl\
+: "+D"(addr), "+c"(count)  \
+: "d"(port) : "memory");   \
+   }   \
 }
 
 BUILDIO(b, b, char)
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 9b0c921c0597..b361fabde4c8 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -39,6 +39,8 @@ static char sme_cmdline_off[] __initdata = "off";
  */
 u64 sme_me_mask __section(.data) = 0;
 EXPORT_SYMBOL_GPL(sme_me_mask);
+DEFINE_STATIC_KEY_FALSE(__sev);
+EXPORT_SYMBOL_GPL(__sev);
 
 unsigned int sev_enabled __section(.data) = 0;
 
@@ -311,6 +313,12 @@ void __init mem_encrypt_init(void)
if (sev_active())
dma_ops = &sev_dma_ops;
 
+   /*
+* With SEV, we need to unroll the rep string I/O instructions.
+*/
+   if (sev_active())
+   static_branch_enable(&__sev);
+
pr_info("AMD %s active\n",
sev_active() ? "Secure Encrypted Virtualization (SEV)"
 : "Secure Memory Encryption (SME)");
-- 
2.9.5

[Part1 PATCH v4 06/17] x86/mm: Include SEV for encryption memory attribute changes

[Brijesh Singh]

From: Tom Lendacky 

The current code checks only for sme_active() when determining whether
to perform the encryption attribute change.  Include sev_active() in this
check so that memory attribute changes can occur under SME and SEV.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Borislav Petkov 
Cc: Andy Lutomirski 
Cc: John Ogness 
Cc: Matt Fleming 
Cc: Laura Abbott 
Cc: Dan Williams 
Cc: "Kirill A. Shutemov" 
Cc: linux-kernel@vger.kernel.org
Cc: x...@kernel.org
Signed-off-by: Tom Lendacky 
Signed-off-by: Brijesh Singh 
---
 arch/x86/mm/pageattr.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/mm/pageattr.c b/arch/x86/mm/pageattr.c
index dfb7d657cf43..3fe68483463c 100644
--- a/arch/x86/mm/pageattr.c
+++ b/arch/x86/mm/pageattr.c
@@ -1781,8 +1781,8 @@ static int __set_memory_enc_dec(unsigned long addr, int 
numpages, bool enc)
unsigned long start;
int ret;
 
-   /* Nothing to do if the SME is not active */
-   if (!sme_active())
+   /* Nothing to do if memory encryption is not active */
+   if (!mem_encrypt_active())
return 0;
 
/* Should not be working on unaligned addresses */
-- 
2.9.5

[Part1 PATCH v4 09/17] resource: Provide resource struct in resource walk callback

[Brijesh Singh]

From: Tom Lendacky 

In prep for a new function that will need additional resource information
during the resource walk, update the resource walk callback to pass the
resource structure.  Since the current callback start and end arguments
are pulled from the resource structure, the callback functions can obtain
them from the resource structure directly.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Borislav Petkov 
Cc: linux-kernel@vger.kernel.org
Cc: linuxppc-...@lists.ozlabs.org
Cc: Benjamin Herrenschmidt 
Reviewed-by: Kees Cook 
Reviewed-by: Borislav Petkov 
Signed-off-by: Tom Lendacky 
Signed-off-by: Brijesh Singh 
---
 arch/powerpc/kernel/machine_kexec_file_64.c | 12 +---
 arch/x86/kernel/crash.c | 18 +-
 arch/x86/kernel/pmem.c  |  2 +-
 include/linux/ioport.h  |  4 ++--
 include/linux/kexec.h   |  2 +-
 kernel/kexec_file.c |  5 +++--
 kernel/resource.c   |  9 +
 7 files changed, 30 insertions(+), 22 deletions(-)

diff --git a/arch/powerpc/kernel/machine_kexec_file_64.c 
b/arch/powerpc/kernel/machine_kexec_file_64.c
index 992c0d258e5d..e4395f937d63 100644
--- a/arch/powerpc/kernel/machine_kexec_file_64.c
+++ b/arch/powerpc/kernel/machine_kexec_file_64.c
@@ -91,11 +91,13 @@ int arch_kimage_file_post_load_cleanup(struct kimage *image)
  * and that value will be returned. If all free regions are visited without
  * func returning non-zero, then zero will be returned.
  */
-int arch_kexec_walk_mem(struct kexec_buf *kbuf, int (*func)(u64, u64, void *))
+int arch_kexec_walk_mem(struct kexec_buf *kbuf,
+   int (*func)(struct resource *, void *))
 {
int ret = 0;
u64 i;
phys_addr_t mstart, mend;
+   struct resource res = { };
 
if (kbuf->top_down) {
for_each_free_mem_range_reverse(i, NUMA_NO_NODE, 0,
@@ -105,7 +107,9 @@ int arch_kexec_walk_mem(struct kexec_buf *kbuf, int 
(*func)(u64, u64, void *))
 * range while in kexec, end points to the last byte
 * in the range.
 */
-   ret = func(mstart, mend - 1, kbuf);
+   res.start = mstart;
+   res.end = mend - 1;
+   ret = func(&res, kbuf);
if (ret)
break;
}
@@ -117,7 +121,9 @@ int arch_kexec_walk_mem(struct kexec_buf *kbuf, int 
(*func)(u64, u64, void *))
 * range while in kexec, end points to the last byte
 * in the range.
 */
-   ret = func(mstart, mend - 1, kbuf);
+   res.start = mstart;
+   res.end = mend - 1;
+   ret = func(&res, kbuf);
if (ret)
break;
}
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index 44404e2307bb..815008c9ca18 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -209,7 +209,7 @@ void native_machine_crash_shutdown(struct pt_regs *regs)
 }
 
 #ifdef CONFIG_KEXEC_FILE
-static int get_nr_ram_ranges_callback(u64 start, u64 end, void *arg)
+static int get_nr_ram_ranges_callback(struct resource *res, void *arg)
 {
unsigned int *nr_ranges = arg;
 
@@ -342,7 +342,7 @@ static int elf_header_exclude_ranges(struct crash_elf_data 
*ced,
return ret;
 }
 
-static int prepare_elf64_ram_headers_callback(u64 start, u64 end, void *arg)
+static int prepare_elf64_ram_headers_callback(struct resource *res, void *arg)
 {
struct crash_elf_data *ced = arg;
Elf64_Ehdr *ehdr;
@@ -355,7 +355,7 @@ static int prepare_elf64_ram_headers_callback(u64 start, 
u64 end, void *arg)
ehdr = ced->ehdr;
 
/* Exclude unwanted mem ranges */
-   ret = elf_header_exclude_ranges(ced, start, end);
+   ret = elf_header_exclude_ranges(ced, res->start, res->end);
if (ret)
return ret;
 
@@ -518,14 +518,14 @@ static int add_e820_entry(struct boot_params *params, 
struct e820_entry *entry)
return 0;
 }
 
-static int memmap_entry_callback(u64 start, u64 end, void *arg)
+static int memmap_entry_callback(struct resource *res, void *arg)
 {
struct crash_memmap_data *cmd = arg;
struct boot_params *params = cmd->params;
struct e820_entry ei;
 
-   ei.addr = start;
-   ei.size = end - start + 1;
+   ei.addr = res->start;
+   ei.size = res->end - res->start + 1;
ei.type = cmd->type;
add_e820_entry(params, &ei);
 
@@ -619,12 +619,12 @@ int crash_setup_memmap_entries(struct kimage *image, 
struct boot_params *params)
return ret;
 }
 
-static int determine_backup_region(u64 start, u64 end, void *arg)
+static int determine_backup_regi

[Part1 PATCH v4 07/17] x86/efi: Access EFI data as encrypted when SEV is active

[Brijesh Singh]

From: Tom Lendacky 

EFI data is encrypted when the kernel is run under SEV. Update the
page table references to be sure the EFI memory areas are accessed
encrypted.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Borislav Petkov 
Cc: Andy Lutomirski 
Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: x...@kernel.org
Signed-off-by: Tom Lendacky 
Signed-off-by: Brijesh Singh 
---
 arch/x86/platform/efi/efi_64.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 12e83888e5b9..5469c9319f43 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -369,7 +370,11 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, 
unsigned num_pages)
 * as trim_bios_range() will reserve the first page and isolate it away
 * from memory allocators anyway.
 */
-   if (kernel_map_pages_in_pgd(pgd, 0x0, 0x0, 1, _PAGE_RW)) {
+   pf = _PAGE_RW;
+   if (sev_active())
+   pf |= _PAGE_ENC;
+
+   if (kernel_map_pages_in_pgd(pgd, 0x0, 0x0, 1, pf)) {
pr_err("Failed to create 1:1 mapping for the first page!\n");
return 1;
}
@@ -412,6 +417,9 @@ static void __init __map_region(efi_memory_desc_t *md, u64 
va)
if (!(md->attribute & EFI_MEMORY_WB))
flags |= _PAGE_PCD;
 
+   if (sev_active())
+   flags |= _PAGE_ENC;
+
pfn = md->phys_addr >> PAGE_SHIFT;
if (kernel_map_pages_in_pgd(pgd, pfn, va, md->num_pages, flags))
pr_warn("Error mapping PA 0x%llx -> VA 0x%llx!\n",
@@ -538,6 +546,9 @@ static int __init efi_update_mem_attr(struct mm_struct *mm, 
efi_memory_desc_t *m
if (!(md->attribute & EFI_MEMORY_RO))
pf |= _PAGE_RW;
 
+   if (sev_active())
+   pf |= _PAGE_ENC;
+
return efi_update_mappings(md, pf);
 }
 
@@ -589,6 +600,9 @@ void __init efi_runtime_update_mappings(void)
(md->type != EFI_RUNTIME_SERVICES_CODE))
pf |= _PAGE_RW;
 
+   if (sev_active())
+   pf |= _PAGE_ENC;
+
efi_update_mappings(md, pf);
}
 }
-- 
2.9.5

[Part1 PATCH v4 05/17] x86/mm: Use encrypted access of boot related data with SEV

[Brijesh Singh]

From: Tom Lendacky 

When Secure Encrypted Virtualization (SEV) is active, boot data (such as
EFI related data, setup data) is encrypted and needs to be accessed as
such when mapped. Update the architecture override in early_memremap to
keep the encryption attribute when mapping this data.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Borislav Petkov 
Cc: Andy Lutomirski 
Cc: Laura Abbott 
Cc: "Kirill A. Shutemov" 
Cc: Matt Fleming 
Cc: linux-kernel@vger.kernel.org
Cc: x...@kernel.org
Signed-off-by: Tom Lendacky 
Signed-off-by: Brijesh Singh 
---
 arch/x86/mm/ioremap.c | 44 ++--
 1 file changed, 30 insertions(+), 14 deletions(-)

diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index 34f0e1847dd6..52cc0f4ed494 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -422,6 +422,9 @@ void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr)
  * areas should be mapped decrypted. And since the encryption key can
  * change across reboots, persistent memory should also be mapped
  * decrypted.
+ *
+ * If SEV is active, that implies that BIOS/UEFI also ran encrypted so
+ * only persistent memory should be mapped decrypted.
  */
 static bool memremap_should_map_decrypted(resource_size_t phys_addr,
  unsigned long size)
@@ -458,6 +461,11 @@ static bool memremap_should_map_decrypted(resource_size_t 
phys_addr,
case E820_TYPE_ACPI:
case E820_TYPE_NVS:
case E820_TYPE_UNUSABLE:
+   /* For SEV, these areas are encrypted */
+   if (sev_active())
+   break;
+   /* Fallthrough */
+
case E820_TYPE_PRAM:
return true;
default:
@@ -581,7 +589,7 @@ static bool __init 
early_memremap_is_setup_data(resource_size_t phys_addr,
 bool arch_memremap_can_ram_remap(resource_size_t phys_addr, unsigned long size,
 unsigned long flags)
 {
-   if (!sme_active())
+   if (!mem_encrypt_active())
return true;
 
if (flags & MEMREMAP_ENC)
@@ -590,12 +598,13 @@ bool arch_memremap_can_ram_remap(resource_size_t 
phys_addr, unsigned long size,
if (flags & MEMREMAP_DEC)
return false;
 
-   if (memremap_is_setup_data(phys_addr, size) ||
-   memremap_is_efi_data(phys_addr, size) ||
-   memremap_should_map_decrypted(phys_addr, size))
-   return false;
+   if (sme_active()) {
+   if (memremap_is_setup_data(phys_addr, size) ||
+   memremap_is_efi_data(phys_addr, size))
+   return false;
+   }
 
-   return true;
+   return !memremap_should_map_decrypted(phys_addr, size);
 }
 
 /*
@@ -608,17 +617,24 @@ pgprot_t __init 
early_memremap_pgprot_adjust(resource_size_t phys_addr,
 unsigned long size,
 pgprot_t prot)
 {
-   if (!sme_active())
+   bool encrypted_prot;
+
+   if (!mem_encrypt_active())
return prot;
 
-   if (early_memremap_is_setup_data(phys_addr, size) ||
-   memremap_is_efi_data(phys_addr, size) ||
-   memremap_should_map_decrypted(phys_addr, size))
-   prot = pgprot_decrypted(prot);
-   else
-   prot = pgprot_encrypted(prot);
+   encrypted_prot = true;
+
+   if (sme_active()) {
+   if (early_memremap_is_setup_data(phys_addr, size) ||
+   memremap_is_efi_data(phys_addr, size))
+   encrypted_prot = false;
+   }
+
+   if (encrypted_prot && memremap_should_map_decrypted(phys_addr, size))
+   encrypted_prot = false;
 
-   return prot;
+   return encrypted_prot ? pgprot_encrypted(prot)
+ : pgprot_decrypted(prot);
 }
 
 bool phys_mem_access_encrypted(unsigned long phys_addr, unsigned long size)
-- 
2.9.5

[Part1 PATCH v4 04/17] x86/realmode: Don't decrypt trampoline area under SEV

[Brijesh Singh]

From: Tom Lendacky 

When SEV is active the trampoline area will need to be in encrypted
memory so only mark the area decrypted if SME is active.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Borislav Petkov 
Cc: Andy Lutomirski 
Cc: Laura Abbott 
Cc: "Kirill A. Shutemov" 
Cc: linux-kernel@vger.kernel.org
Cc: x...@kernel.org
Signed-off-by: Tom Lendacky 
Signed-off-by: Brijesh Singh 
---
 arch/x86/realmode/init.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/x86/realmode/init.c b/arch/x86/realmode/init.c
index 1f71980fc5e0..d03125c2b73b 100644
--- a/arch/x86/realmode/init.c
+++ b/arch/x86/realmode/init.c
@@ -63,9 +63,10 @@ static void __init setup_real_mode(void)
/*
 * If SME is active, the trampoline area will need to be in
 * decrypted memory in order to bring up other processors
-* successfully.
+* successfully. This is not needed for SEV.
 */
-   set_memory_decrypted((unsigned long)base, size >> PAGE_SHIFT);
+   if (sme_active())
+   set_memory_decrypted((unsigned long)base, size >> PAGE_SHIFT);
 
memcpy(base, real_mode_blob, size);
 
-- 
2.9.5

[Part1 PATCH v4 02/17] x86/mm: Add Secure Encrypted Virtualization (SEV) support

[Brijesh Singh]

From: Tom Lendacky 

Provide support for Secure Encrypted Virtualization (SEV). This initial
support defines a flag that is used by the kernel to determine if it is
running with SEV active.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Borislav Petkov 
Cc: Andy Lutomirski 
Cc: linux-kernel@vger.kernel.org
Cc: x...@kernel.org
Signed-off-by: Tom Lendacky 
Signed-off-by: Brijesh Singh 
---
 arch/x86/include/asm/mem_encrypt.h |  6 ++
 arch/x86/mm/mem_encrypt.c  | 26 ++
 include/linux/mem_encrypt.h| 12 
 3 files changed, 40 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/mem_encrypt.h 
b/arch/x86/include/asm/mem_encrypt.h
index 6a77c63540f7..2b024741bce9 100644
--- a/arch/x86/include/asm/mem_encrypt.h
+++ b/arch/x86/include/asm/mem_encrypt.h
@@ -47,6 +47,9 @@ void __init mem_encrypt_init(void);
 
 void swiotlb_set_mem_attributes(void *vaddr, unsigned long size);
 
+bool sme_active(void);
+bool sev_active(void);
+
 #else  /* !CONFIG_AMD_MEM_ENCRYPT */
 
 #define sme_me_mask0ULL
@@ -64,6 +67,9 @@ static inline void __init sme_early_init(void) { }
 static inline void __init sme_encrypt_kernel(void) { }
 static inline void __init sme_enable(struct boot_params *bp) { }
 
+static inline bool sme_active(void) { return false; }
+static inline bool sev_active(void) { return false; }
+
 #endif /* CONFIG_AMD_MEM_ENCRYPT */
 
 /*
diff --git a/arch/x86/mm/mem_encrypt.c b/arch/x86/mm/mem_encrypt.c
index 3fcc8e01683b..4e6dcabe52fc 100644
--- a/arch/x86/mm/mem_encrypt.c
+++ b/arch/x86/mm/mem_encrypt.c
@@ -40,6 +40,8 @@ static char sme_cmdline_off[] __initdata = "off";
 u64 sme_me_mask __section(.data) = 0;
 EXPORT_SYMBOL_GPL(sme_me_mask);
 
+unsigned int sev_enabled __section(.data) = 0;
+
 /* Buffer used for early in-place encryption by BSP, no locking needed */
 static char sme_early_buffer[PAGE_SIZE] __aligned(PAGE_SIZE);
 
@@ -190,6 +192,30 @@ void __init sme_early_init(void)
protection_map[i] = pgprot_encrypted(protection_map[i]);
 }
 
+/*
+ * SME and SEV are very similar but they are not the same, so there are
+ * times that the kernel will need to distinguish between SME and SEV. The
+ * sme_active() and sev_active() functions are used for this.  When a
+ * distinction isn't needed, the mem_encrypt_active() function can be used.
+ *
+ * The trampoline code is a good example for this requirement.  Before
+ * paging is activated, SME will access all memory as decrypted, but SEV
+ * will access all memory as encrypted.  So, when APs are being brought
+ * up under SME the trampoline area cannot be encrypted, whereas under SEV
+ * the trampoline area must be encrypted.
+ */
+bool sme_active(void)
+{
+   return sme_me_mask && !sev_enabled;
+}
+EXPORT_SYMBOL_GPL(sme_active);
+
+bool sev_active(void)
+{
+   return sme_me_mask && sev_enabled;
+}
+EXPORT_SYMBOL_GPL(sev_active);
+
 /* Architecture __weak replacement functions */
 void __init mem_encrypt_init(void)
 {
diff --git a/include/linux/mem_encrypt.h b/include/linux/mem_encrypt.h
index 265a9cd21cb4..b55ba30a60a0 100644
--- a/include/linux/mem_encrypt.h
+++ b/include/linux/mem_encrypt.h
@@ -22,17 +22,21 @@
 #else  /* !CONFIG_ARCH_HAS_MEM_ENCRYPT */
 
 #define sme_me_mask0ULL
+#define sev_enabled0
+
+static inline bool sme_active(void) { return false; }
+static inline bool sev_active(void) { return false; }
 
 #endif /* CONFIG_ARCH_HAS_MEM_ENCRYPT */
 
-static inline bool sme_active(void)
+static inline unsigned long sme_get_me_mask(void)
 {
-   return !!sme_me_mask;
+   return sme_me_mask;
 }
 
-static inline u64 sme_get_me_mask(void)
+static inline bool mem_encrypt_active(void)
 {
-   return sme_me_mask;
+   return !!sme_me_mask;
 }
 
 #ifdef CONFIG_AMD_MEM_ENCRYPT
-- 
2.9.5

[Part1 PATCH v4 01/17] Documentation/x86: Add AMD Secure Encrypted Virtualization (SEV) description

[Brijesh Singh]

Update the AMD memory encryption document describing the Secure Encrypted
Virtualization (SEV) feature.

Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: Jonathan Corbet 
Cc: Borislav Petkov 
Cc: Tom Lendacky 
Signed-off-by: Brijesh Singh 
---
 Documentation/x86/amd-memory-encryption.txt | 30 +
 1 file changed, 26 insertions(+), 4 deletions(-)

diff --git a/Documentation/x86/amd-memory-encryption.txt 
b/Documentation/x86/amd-memory-encryption.txt
index f512ab718541..afc41f544dab 100644
--- a/Documentation/x86/amd-memory-encryption.txt
+++ b/Documentation/x86/amd-memory-encryption.txt
@@ -1,4 +1,5 @@
-Secure Memory Encryption (SME) is a feature found on AMD processors.
+Secure Memory Encryption (SME) and Secure Encrypted Virtualization (SEV) are
+features found on AMD processors.
 
 SME provides the ability to mark individual pages of memory as encrypted using
 the standard x86 page tables.  A page that is marked encrypted will be
@@ -6,24 +7,38 @@ automatically decrypted when read from DRAM and encrypted 
when written to
 DRAM.  SME can therefore be used to protect the contents of DRAM from physical
 attacks on the system.
 
+SEV enables running encrypted virtual machines (VMs) in which the code and data
+of the guest VM are secured so that a decrypted version is available only
+within the VM itself. SEV guest VMs have the concept of private and shared
+memory. Private memory is encrypted with the guest-specific key, while shared
+memory may be encrypted with hypervisor key. When SME is enabled, the 
hypervisor
+key is the same key which is used in SME.
+
 A page is encrypted when a page table entry has the encryption bit set (see
 below on how to determine its position).  The encryption bit can also be
 specified in the cr3 register, allowing the PGD table to be encrypted. Each
 successive level of page tables can also be encrypted by setting the encryption
 bit in the page table entry that points to the next table. This allows the full
 page table hierarchy to be encrypted. Note, this means that just because the
-encryption bit is set in cr3, doesn't imply the full hierarchy is encyrpted.
+encryption bit is set in cr3, doesn't imply the full hierarchy is encrypted.
 Each page table entry in the hierarchy needs to have the encryption bit set to
 achieve that. So, theoretically, you could have the encryption bit set in cr3
 so that the PGD is encrypted, but not set the encryption bit in the PGD entry
 for a PUD which results in the PUD pointed to by that entry to not be
 encrypted.
 
-Support for SME can be determined through the CPUID instruction. The CPUID
-function 0x801f reports information related to SME:
+When SEV is enabled, instruction pages and guest page tables are always treated
+as private. All the DMA operations inside the guest must be performed on shared
+memory. Since the memory encryption bit is controlled by the guest OS when it
+is operating in 64-bit or 32-bit PAE mode, in all other modes the SEV hardware
+forces the memory encryption bit to 1.
+
+Support for SME and SEV can be determined through the CPUID instruction. The
+CPUID function 0x801f reports information related to SME:
 
0x801f[eax]:
Bit[0] indicates support for SME
+   Bit[1] indicates support for SEV
0x801f[ebx]:
Bits[5:0]  pagetable bit number used to activate memory
   encryption
@@ -39,6 +54,13 @@ determine if SME is enabled and/or to enable memory 
encryption:
Bit[23]   0 = memory encryption features are disabled
  1 = memory encryption features are enabled
 
+If SEV is supported, MSR 0xc0010131 (MSR_AMD64_SEV) can be used to determine if
+SEV is active:
+
+   0xc0010131:
+   Bit[0]0 = memory encryption is not active
+ 1 = memory encryption is active
+
 Linux relies on BIOS to set this bit if BIOS has determined that the reduction
 in the physical address space as a result of enabling memory encryption (see
 CPUID information above) will not conflict with the address space resource
-- 
2.9.5

Re: d57108d4f6 ("watchdog/core: Get rid of the thread .."): BUG: unable to handle kernel NULL pointer dereference at 0000000000000208

[Fengguang Wu]

On Fri, Sep 15, 2017 at 06:24:20PM +0200, Thomas Gleixner wrote:

On Fri, 15 Sep 2017, Thomas Gleixner wrote:


On Fri, 15 Sep 2017, Thomas Gleixner wrote:

> On Fri, 15 Sep 2017, kernel test robot wrote:
> > [0.035023] CPU: Intel Common KVM processor (family: 0xf, model: 0x6, 
stepping: 0x1)
> > [0.042302] Performance Events: unsupported Netburst CPU model 6 no PMU 
driver, software events only.
>
> Cute. So there is no supported PMU, but for some unknown reason the lockup
> detector can create an event, otherwise the perf availaibility check in
> lockup_detector_init() would fail 
>
> Peter???

In my VM the corresponding dmesg is:

[0.038086] Performance Events: unsupported p6 CPU model 61 no PMU driver, 
software events only.


What's your host CPU? I can reproduce it in Nehalem, Haswell and Sandy
Bridge machines with the attached script.


[0.041031] Hierarchical SRCU implementation.
[0.046210] NMI watchdog: Perf event create on CPU 0 failed with -2
[0.046980] NMI watchdog: Perf NMI watchdog permanetely disabled

Confused


I still can't reproduce. Can you please apply the debug patch below and
provide the output?


OK. I'll try and report back tomorrow.

Thanks,
Fengguang


8<-

diff --git a/kernel/watchdog_hld.c b/kernel/watchdog_hld.c
index b2931154b5f2..e6c9ca516945 100644
--- a/kernel/watchdog_hld.c
+++ b/kernel/watchdog_hld.c
@@ -171,6 +171,7 @@ static int hardlockup_detector_event_create(void)
/* Try to register using hardware perf events */
evt = perf_event_create_kernel_counter(wd_attr, cpu, NULL,
   watchdog_overflow_callback, 
NULL);
+   pr_info("EVT create on CPU %u returned %p\n", cpu, evt);
if (IS_ERR(evt)) {
pr_info("Perf event create on CPU %d failed with %ld\n", cpu,
PTR_ERR(evt));
@@ -221,7 +222,10 @@ void hardlockup_detector_perf_cleanup(void)
struct perf_event *event = per_cpu(watchdog_ev, cpu);

per_cpu(watchdog_ev, cpu) = NULL;
-   perf_event_release_kernel(event);
+   pr_info("EVT on CPU %u in dead mask: %p\n",  cpu, event);
+   if (event)
+   perf_event_release_kernel(event);
+
}
cpumask_clear(&dead_events_mask);
}
#!/bin/bash

kernel=$1

kvm=(
qemu-system-x86_64
-enable-kvm
-cpu kvm64
-kernel $kernel
-m 399
-smp 2
-device e1000,netdev=net0
-netdev user,id=net0
-boot order=nc
-no-reboot
-watchdog i6300esb
-watchdog-action debug
-rtc base=localtime
-serial stdio
-display none
-monitor null
)

append=(
root=/dev/ram0
hung_task_panic=1
debug
apic=debug
sysrq_always_enabled
rcupdate.rcu_cpu_stall_timeout=100
net.ifnames=0
printk.devkmsg=on
panic=-1
softlockup_panic=1
nmi_watchdog=panic
oops=panic
load_ramdisk=2
prompt_ramdisk=0
drbd.minor_count=8
systemd.log_level=err
ignore_loglevel
console=tty0
earlyprintk=ttyS0,115200
console=ttyS0,115200
vga=normal
rw
drbd.minor_count=8
)

"${kvm[@]}" -append "${append[*]}"

Re: Vibrations in input vs. LED was Re: [PATCH v2 0/3] led: ledtrig-transient: add support for hrtimer

[Pavel Machek]

Hi!

> >> If we want to have discussion "how to make vibrations in input
> >> easier to use", well that's fair. But I don't think it is particulary hard.
> >>
> > 
> > I would like to know more about why you find the FF interface hard,
> 
> led-transient trigger can be activated using only following bash
> commands:
> 
> # echo 1 > state
> # echo 1000 > duration
> # while [ 1 ]; do echo 1 > activate; sleep 3; done
> 
> Could you share sample sequence of commands to use ff driver?

Well, LED transient trigger can be activated like that. But that will
not work on any hardware currently supported by the mainline kernel.

Equivalent command with forcefeedback is:

(echo 5; sleep 1; echo -1) | sudo fftest /dev/input/event2

You would not want to use either in production.

> >> But having half devices use one interface and half use different one
> >> is just bad...
> > 
> > Completely agree here. I just merged PWM vibra driver from Sebastian
> > Reichel, we already had regulator-haptic driver, do we need gpio-based
> > one? Or make regulator-based one working with fixed regulators?
> 
> Just to clarify: the background of this discussion is the question
> whether we should remove the following lines from
> Documentation/leds/ledtrig-transient.txt:
> 
> -As a specific example of this use-case, let's look at vibrate feature on
> -phones. Vibrate function on phones is implemented using PWM pins on SoC or
> -PMIC. There is a need to activate one shot timer to control the vibrate
> -feature, to prevent user space crashes leaving the phone in vibrate mode
> -permanently causing the battery to drain.
> whether we should remove the following use case example from
> 
> In effect Pavel has objections to increasing ledtrig-transient
> interval accuracy by adding hr_timer support to it, because vibrate
> devices, as one of the use cases, can benefit from it.
> 
> So there are two issues:
> 1. Addition of hr_timer support to LED trigger.
> 2. Removal of vibrate devices use case from ledtrig-transient doc.
> 
> I am in favour of 1. and against 2. since we're not gaining anything
> by hiding information about some kernel functionality when it will
> still be there. It also doesn't define the location of any vibrate
> device drivers, since sheer leds-gpio driver can be used for that
> purpose.

I would like to see reasonable explanation why we want 1. (and
vibrations are not that) and certainly 2. because we don't want people
to use LED subsystem for vibrations.

We already have perfectly good interface for that.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

[PATCH v4] security/keys: rewrite all of big_key crypto

[Jason A. Donenfeld]

This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot time.
But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.

It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored untrusted,
using ECB and no authentication is simply not okay at all. I find it
surprising and a bit horrifying that this code even made it past basic
crypto review, which perhaps points to some larger issues. This patch
moves from using AES-ECB to using AES-GCM. Since keys are uniquely generated
each time, we can set the nonce to zero. There was also a race condition in
which the same key would be reused at the same time in different threads. A
mutex fixes this issue now. And, some error paths forgot to zero out sensitive
material, so this patch changes a kfree into a kzfree.

So, to summarize, this commit fixes the following vulnerabilities:

  * Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
  * Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
  * Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
  * Key re-use.
  * Faulty memory zeroing.

Signed-off-by: Jason A. Donenfeld 
Cc: David Howells 
Cc: Eric Biggers 
Cc: Herbert Xu 
Cc: Kirill Marinushkin 
Cc: Ard Biesheuvel 
Cc: Ilhan Gurel 
Cc: secur...@kernel.org
Cc: sta...@vger.kernel.org
---
 security/keys/Kconfig   |   4 +-
 security/keys/big_key.c | 139 ++--
 2 files changed, 65 insertions(+), 78 deletions(-)

Changes v3->v4:
  - Patchset resurrected from the dead. Just like the original use of ECB,
which this patch fixes, crypto-related things are sometimes neglected,
unfortunately.
  - Rebased on top of 4.13+ changes.
  - Now that get_random_bytes_wait has been merged, we can actually use
it, just like in v1 of this patch.

diff --git a/security/keys/Kconfig b/security/keys/Kconfig
index a7a23b5541f8..91eafada3164 100644
--- a/security/keys/Kconfig
+++ b/security/keys/Kconfig
@@ -45,10 +45,8 @@ config BIG_KEYS
bool "Large payload keys"
depends on KEYS
depends on TMPFS
-   depends on (CRYPTO_ANSI_CPRNG = y || CRYPTO_DRBG = y)
select CRYPTO_AES
-   select CRYPTO_ECB
-   select CRYPTO_RNG
+   select CRYPTO_GCM
help
  This option provides support for holding large keys within the kernel
  (for example Kerberos ticket caches).  The data may be stored out to
diff --git a/security/keys/big_key.c b/security/keys/big_key.c
index 6acb00f6f22c..36682686f8c2 100644
--- a/security/keys/big_key.c
+++ b/security/keys/big_key.c
@@ -1,5 +1,6 @@
 /* Large capacity key type
  *
+ * Copyright (C) 2017 Jason A. Donenfeld . All Rights 
Reserved.
  * Copyright (C) 2013 Red Hat, Inc. All Rights Reserved.
  * Written by David Howells (dhowe...@redhat.com)
  *
@@ -16,10 +17,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
-#include 
+#include 
 
 /*
  * Layout of key payload words.
@@ -49,7 +50,12 @@ enum big_key_op {
 /*
  * Key size for big_key data encryption
  */
-#define ENC_KEY_SIZE   16
+#define ENC_KEY_SIZE 32
+
+/*
+ * Authentication tag length
+ */
+#define ENC_AUTHTAG_SIZE 16
 
 /*
  * big_key defined keys take an arbitrary string as the description and an
@@ -64,57 +70,62 @@ struct key_type key_type_big_key = {
.destroy= big_key_destroy,
.describe   = big_key_describe,
.read   = big_key_read,
+   /* no ->update(); don't add it without changing big_key_crypt() nonce */
 };
 
 /*
- * Crypto names for big_key data encryption
+ * Crypto names for big_key data authenticated encryption
  */
-static const char big_key_rng_name[] = "stdrng";
-static const char big_key_alg_name[] = "ecb(aes)";
+static const char big_key_alg_name[] = "gcm(aes)";
 
 /*
- * Crypto algorithms for big_key data encryption
+ * Crypto algorithms for big_key data authenticated encryption
  */
-static struct crypto_rng *big_key_rng;
-static struct crypto_skcipher *big_key_skcipher;
+static struct crypto_aead *big_key_aead;
 
 /*
- * Generate random key to encrypt big_key data
+ * Since changing the key affects the entire object, we need a mutex.
  */
-static inline int big_key_gen_enckey(u8 *key)
-{
-   return

Re: [PATCH manpages] stat.2: correct AT_NO_AUTOMOUNT text and general revisions.

[Michael Kerrisk (man-pages)]

On 09/15/2017 12:25 AM, NeilBrown wrote:
> On Thu, Sep 14 2017, Michael Kerrisk (man-pages) wrote:
> 
>> Hi Neil,
>>
>> On 25 August 2017 at 07:32, NeilBrown  wrote:
>>>
>>> Expand on the relationship between fstatat() and the other
>>> three functions, and improve the description of AT_NO_AUTOMOUNT.
>>> Specifically, both  stat() and lstat() act the same way
>>> with respect to automounts, and that behavior matches
>>> fstatat with the AT_NO_AUTOMOUNT flag.
>>>
>>> The text in the NOTES is removed and places with the text for
>>> AT_NO_AUTOMOUNT to improve cohesion.
>>>
>>> New text for a difference to be introduced in 4.14.
>>
>> Has the 4.14 piece gone in?
>>
> 
> Yes.
> 
> Commit: 42f461482178 ("autofs: fix AT_NO_AUTOMOUNT not being honored")

Thanks. I've applied the patch.

Cheers,

Michael


-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/

[PATCH v5] security/keys: rewrite all of big_key crypto

[Jason A. Donenfeld]

This started out as just replacing the use of crypto/rng with
get_random_bytes_wait, so that we wouldn't use bad randomness at boot time.
But, upon looking further, it appears that there were even deeper
underlying cryptographic problems, and that this seems to have been
committed with very little crypto review. So, I rewrote the whole thing,
trying to keep to the conventions introduced by the previous author, to
fix these cryptographic flaws.

It makes no sense to seed crypto/rng at boot time and then keep
using it like this, when in fact there's already get_random_bytes_wait,
which can ensure there's enough entropy and be a much more standard way
of generating keys. Since this sensitive material is being stored untrusted,
using ECB and no authentication is simply not okay at all. I find it
surprising and a bit horrifying that this code even made it past basic
crypto review, which perhaps points to some larger issues. This patch
moves from using AES-ECB to using AES-GCM. Since keys are uniquely generated
each time, we can set the nonce to zero. There was also a race condition in
which the same key would be reused at the same time in different threads. A
mutex fixes this issue now. And, some error paths forgot to zero out sensitive
material, so this patch changes a kfree into a kzfree.

So, to summarize, this commit fixes the following vulnerabilities:

  * Low entropy key generation, allowing an attacker to potentially
guess or predict keys.
  * Unauthenticated encryption, allowing an attacker to modify the
cipher text in particular ways in order to manipulate the plaintext,
which is is even more frightening considering the next point.
  * Use of ECB mode, allowing an attacker to trivially swap blocks or
compare identical plaintext blocks.
  * Key re-use.
  * Faulty memory zeroing.

Signed-off-by: Jason A. Donenfeld 
Cc: David Howells 
Cc: Eric Biggers 
Cc: Herbert Xu 
Cc: Kirill Marinushkin 
Cc: secur...@kernel.org
Cc: sta...@vger.kernel.org
---
 security/keys/Kconfig   |   4 +-
 security/keys/big_key.c | 141 +++-
 2 files changed, 67 insertions(+), 78 deletions(-)

Changes v4->v5:
 - Fix get_random_bytes_wait ret value derp.

diff --git a/security/keys/Kconfig b/security/keys/Kconfig
index a7a23b5541f8..91eafada3164 100644
--- a/security/keys/Kconfig
+++ b/security/keys/Kconfig
@@ -45,10 +45,8 @@ config BIG_KEYS
bool "Large payload keys"
depends on KEYS
depends on TMPFS
-   depends on (CRYPTO_ANSI_CPRNG = y || CRYPTO_DRBG = y)
select CRYPTO_AES
-   select CRYPTO_ECB
-   select CRYPTO_RNG
+   select CRYPTO_GCM
help
  This option provides support for holding large keys within the kernel
  (for example Kerberos ticket caches).  The data may be stored out to
diff --git a/security/keys/big_key.c b/security/keys/big_key.c
index 6acb00f6f22c..26d74721b6b6 100644
--- a/security/keys/big_key.c
+++ b/security/keys/big_key.c
@@ -1,5 +1,6 @@
 /* Large capacity key type
  *
+ * Copyright (C) 2017 Jason A. Donenfeld . All Rights 
Reserved.
  * Copyright (C) 2013 Red Hat, Inc. All Rights Reserved.
  * Written by David Howells (dhowe...@redhat.com)
  *
@@ -16,10 +17,10 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
-#include 
-#include 
+#include 
 
 /*
  * Layout of key payload words.
@@ -49,7 +50,12 @@ enum big_key_op {
 /*
  * Key size for big_key data encryption
  */
-#define ENC_KEY_SIZE   16
+#define ENC_KEY_SIZE 32
+
+/*
+ * Authentication tag length
+ */
+#define ENC_AUTHTAG_SIZE 16
 
 /*
  * big_key defined keys take an arbitrary string as the description and an
@@ -64,57 +70,62 @@ struct key_type key_type_big_key = {
.destroy= big_key_destroy,
.describe   = big_key_describe,
.read   = big_key_read,
+   /* no ->update(); don't add it without changing big_key_crypt() nonce */
 };
 
 /*
- * Crypto names for big_key data encryption
+ * Crypto names for big_key data authenticated encryption
  */
-static const char big_key_rng_name[] = "stdrng";
-static const char big_key_alg_name[] = "ecb(aes)";
+static const char big_key_alg_name[] = "gcm(aes)";
 
 /*
- * Crypto algorithms for big_key data encryption
+ * Crypto algorithms for big_key data authenticated encryption
  */
-static struct crypto_rng *big_key_rng;
-static struct crypto_skcipher *big_key_skcipher;
+static struct crypto_aead *big_key_aead;
 
 /*
- * Generate random key to encrypt big_key data
+ * Since changing the key affects the entire object, we need a mutex.
  */
-static inline int big_key_gen_enckey(u8 *key)
-{
-   return crypto_rng_get_bytes(big_key_rng, key, ENC_KEY_SIZE);
-}
+static DEFINE_MUTEX(big_key_aead_lock);
 
 /*
  * Encrypt/decrypt big_key data
  */
 static int big_key_crypt(enum big_key_op op, u8 *data, size_t datalen, u8 *key)
 {
-   int ret = -EINVAL;
+   int ret;
struct scatterlist sgio;
-

Re: [PATCH] xen: x86: mark xen_find_pt_base as __init

[Boris Ostrovsky]

On 09/15/2017 03:29 PM, Arnd Bergmann wrote:
> gcc-4.6 causes a harmless link-time warning:
>
> WARNING: vmlinux.o(.text.unlikely+0x48e): Section mismatch in reference from 
> the function xen_find_pt_base() to the function .init.text:m2p()
> The function xen_find_pt_base() references
> the function __init m2p().
> This is often because xen_find_pt_base lacks a __init
> annotation or the annotation of m2p is wrong.
>
> Newer compilers inline this function, so it never shows up, but marking
> it __init is the right way to avoid the warning.
>
> Fixes: 70e61199559a ("xen: move p2m list if conflicting with e820 map")
> Signed-off-by: Arnd Bergmann 

Applied to for-linus-14b.

-boris

Re: [PATCH v8 10/18] RISC-V: Init and Halt Code

[Daniel Lezcano]

On 16/09/2017 08:23, Dmitriy Cherkasov wrote:
> On 09/13/2017 11:15 AM, Daniel Lezcano wrote:
>>
>> All this code must go in the timer side and use the TIMER_OF_DECLARE
>> macro with the proper wrappers.
> 
> Hi, thanks for the feedback.
> 
> Agreed. I'll clean this up.
> 
>>
>> Where is the request_per_cpu_interrupt()?
>>
>> What is this riscv_timer_interrupt() signature?
> 
> This arch defines a separate exception type for local timer interrupts.
> Currently the interrupt controller driver checks the trap cause
> register, determines that it's a timer, and calls the handler directly.
> To make this go through the interrupt subsystem, this driver would need
> to be reworked.
> 
>>
>> Where is get_cycles64() ?
> 
> This is in asm/timex.h. Should this be split into a separate asm header
> ala arm64?

No, it is fine but may be it is get_cycles(), no get_cycles64(), right?

>> The timer driver should be self-contained and not spread across
>> different places, it is very difficult to review it.
>>
>> [ ... ]
>>
> 
> Agreed, thanks again for reviewing it anyway :)

Ok, thanks.

  -- Daniel

-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

[git pull] Input updates for v4.14-rc0

[Dmitry Torokhov]

Hi Linus,

Please pull from:

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

to receive second round of updates for the input subsystem. You will get:

- a new driver for PWM-controlled vibrators

- ucb1400 touchscreen driver had completely busted suspend/resume handling

- we now handle "home" button found on some devices with Goodix touchscreens

- assorted other fixups.

Changelog:
-

Cameron Gutman (1):
  Input: xpad - validate USB endpoint type during probe

Colin Ian King (3):
  Input: adi - make array seq static, reduces object code size
  Input: surface3_spi - make const array header static, reduces object code 
size
  Input: elantech - make arrays debounce_packet static, reduces object code 
size

Dmitry Torokhov (1):
  Input: ucb1400_ts - fix suspend and resume handling

Kai-Heng Feng (1):
  Input: i8042 - add Gigabyte P57 to the keyboard reset table

Luca Ceresoli (1):
  Input: edt-ft5x06 - fix access to non-existing register

Sebastian Reichel (1):
  Input: add a driver for PWM controllable vibrators

Sergei A. Trusov (1):
  Input: goodix - add support for capacitive home button

Diffstat:


 .../devicetree/bindings/input/pwm-vibrator.txt |  66 +
 drivers/input/joystick/adi.c   |   2 +-
 drivers/input/joystick/xpad.c  |  10 +-
 drivers/input/misc/Kconfig |  12 +
 drivers/input/misc/Makefile|   1 +
 drivers/input/misc/pwm-vibra.c | 267 +
 drivers/input/mouse/elantech.c |   8 +-
 drivers/input/serio/i8042-x86ia64io.h  |   7 +
 drivers/input/touchscreen/edt-ft5x06.c |   3 +-
 drivers/input/touchscreen/goodix.c |   9 +
 drivers/input/touchscreen/surface3_spi.c   |   2 +-
 drivers/input/touchscreen/ucb1400_ts.c |   4 +-
 12 files changed, 380 insertions(+), 11 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/input/pwm-vibrator.txt
 create mode 100644 drivers/input/misc/pwm-vibra.c

Thanks.


-- 
Dmitry

RE: [PATCH V2] tipc: Use bsearch library function

[Jon Maloy]

> -Original Message-
> From: netdev-ow...@vger.kernel.org [mailto:netdev-
> ow...@vger.kernel.org] On Behalf Of Joe Perches
> Sent: Saturday, September 16, 2017 06:18
> To: Ying Xue ; Thomas Meyer
> ; Jon Maloy ;
> net...@vger.kernel.org; tipc-discuss...@lists.sourceforge.net; linux-
> ker...@vger.kernel.org; da...@davemloft.net
> Subject: Re: [PATCH V2] tipc: Use bsearch library function
> 
> On Sat, 2017-09-16 at 18:10 +0800, Ying Xue wrote:
> > On 09/16/2017 05:58 PM, Joe Perches wrote:
> > > On Sat, 2017-09-16 at 17:36 +0800, Ying Xue wrote:
> > > > On 09/16/2017 05:26 PM, Joe Perches wrote:
> > > > > On Sat, 2017-09-16 at 17:02 +0800, Ying Xue wrote:
> > > > > > On 09/16/2017 03:50 PM, Thomas Meyer wrote:
> > > > > > > Use common library function rather than explicitly coding
> > > > > > > some variant of it yourself.
> > > > > > >
> > > > > > > Signed-off-by: Thomas Meyer 
> > > > > >
> > > > > > Acked-by: Ying Xue 
> > > > >
> > > > > Are you sure you want to do this?
> > > > >
> > > > > Note the comment above nameseq_find_subseq
> > > > >
> > > > >  * Very time-critical, so binary searches through sub-sequence array.
> > > > >
> > > > > What impact does this change have on performance?
> > > >
> > > > Sorry, I couldn't see any essential difference between this new
> > > > implementation and the original one except that the former tries
> > > > to use the library function - bsearch() to replace the original
> > > > binary search algorithm implemented in TIPC itself. Therefore, I
> > > > don't think the change will have a big impact on performance.
> > > >
> > > > If I miss something, please let me know.
> > >
> > > Comparison via a function pointer in bsearch is slower than direct
> > > code without the function call overhead.
> > >
> >
> > Right, but probably we can tolerate the slight sacrifice here.
> 
> What part of "very time critical" have you verified and benchmarked as
> inconsequential?
> 
> Please post your results.

I agree with Joe here. This change does not simplify anything, it does not 
reduce the amount of code, plus that it introduce an unnecessary outline call 
in a place where we have every reason to let the compiler do its optimization 
job properly.

///jon

[PATCH 0/3] [media] si470x: Adjustments for si470x_usb_driver_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 16 Sep 2017 15:16:17 +0200

Three update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
  Delete an error message for a failed memory allocation
  Improve a size determination
  Delete an unnecessary variable initialisation

 drivers/media/radio/si470x/radio-si470x-usb.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

-- 
2.14.1

[PATCH 1/3] [media] si470x: Delete an error message for a failed memory allocation in si470x_usb_driver_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 16 Sep 2017 14:53:49 +0200

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/media/radio/si470x/radio-si470x-usb.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/radio/si470x/radio-si470x-usb.c 
b/drivers/media/radio/si470x/radio-si470x-usb.c
index c311f9951d80..af295530b20f 100644
--- a/drivers/media/radio/si470x/radio-si470x-usb.c
+++ b/drivers/media/radio/si470x/radio-si470x-usb.c
@@ -618,5 +618,4 @@ static int si470x_usb_driver_probe(struct usb_interface 
*intf,
if (!radio->int_in_buffer) {
-   dev_info(&intf->dev, "could not allocate int_in_buffer");
retval = -ENOMEM;
goto err_usbbuf;
}
-- 
2.14.1

[PATCH 2/3] [media] si470x: Improve a size determination in si470x_usb_driver_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 16 Sep 2017 14:58:06 +0200

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/media/radio/si470x/radio-si470x-usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/radio/si470x/radio-si470x-usb.c 
b/drivers/media/radio/si470x/radio-si470x-usb.c
index af295530b20f..6fc6e8235f20 100644
--- a/drivers/media/radio/si470x/radio-si470x-usb.c
+++ b/drivers/media/radio/si470x/radio-si470x-usb.c
@@ -584,5 +584,5 @@ static int si470x_usb_driver_probe(struct usb_interface 
*intf,
/* private data allocation and initialization */
-   radio = kzalloc(sizeof(struct si470x_device), GFP_KERNEL);
+   radio = kzalloc(sizeof(*radio), GFP_KERNEL);
if (!radio) {
retval = -ENOMEM;
goto err_initial;
-- 
2.14.1

[PATCH 3/3] [media] si470x: Delete an unnecessary variable initialisation in si470x_usb_driver_probe()

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 16 Sep 2017 15:08:39 +0200

The variable "retval" will eventually be set to an appropriate value
a bit later. Thus omit the explicit initialisation at the beginning.

Signed-off-by: Markus Elfring 
---
 drivers/media/radio/si470x/radio-si470x-usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/radio/si470x/radio-si470x-usb.c 
b/drivers/media/radio/si470x/radio-si470x-usb.c
index 6fc6e8235f20..ae30e3da9d13 100644
--- a/drivers/media/radio/si470x/radio-si470x-usb.c
+++ b/drivers/media/radio/si470x/radio-si470x-usb.c
@@ -578,6 +578,6 @@ static int si470x_usb_driver_probe(struct usb_interface 
*intf,
struct si470x_device *radio;
struct usb_host_interface *iface_desc;
struct usb_endpoint_descriptor *endpoint;
-   int i, int_end_size, retval = 0;
+   int i, int_end_size, retval;
unsigned char version_warning = 0;
 
-- 
2.14.1

Re: intel-vbtn: match power button on press rather than release

[Pali Rohár]

On Friday 04 August 2017 19:00:06 Mario Limonciello wrote:
> This fixes a problem where the system gets stuck in a loop
> unable to wakeup via power button in s2idle.
> 
> The problem happens because:
>  - press power button:
>- system emits 0xc0 (power press), event ignored
>- system emits 0xc1 (power release), event processed,
>  emited as KEY_POWER
>- set wakeup_mode to true
>- system goes to s2idle
>  - press power button
>- system emits 0xc0 (power press), wakeup_mode is true,
>  system wakes
>- system emits 0xc1 (power release), event processed,
>  emited as KEY_POWER
>- system goes to s2idle again
> 
> To avoid this situation, process the presses (which matches what
> intel-hid does too).
> 
> Verified on an Dell XPS 9365
> 
> Signed-off-by: Mario Limonciello 
> ---
>  drivers/platform/x86/intel-vbtn.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/platform/x86/intel-vbtn.c
> b/drivers/platform/x86/intel-vbtn.c index 61f1063..4809267 100644
> --- a/drivers/platform/x86/intel-vbtn.c
> +++ b/drivers/platform/x86/intel-vbtn.c
> @@ -36,8 +36,8 @@ static const struct acpi_device_id intel_vbtn_ids[]
> = {
> 
>  /* In theory, these are HID usages. */
>  static const struct key_entry intel_vbtn_keymap[] = {
> - { KE_IGNORE, 0xC0, { KEY_POWER } }, /* power key press */
> - { KE_KEY, 0xC1, { KEY_POWER } },/* power key release */
> + { KE_KEY, 0xC0, { KEY_POWER } },/* power key press */
> + { KE_IGNORE, 0xC1, { KEY_POWER } }, /* power key release */
>   { KE_KEY, 0xC4, { KEY_VOLUMEUP } }, /* volume-up key press 
> */
>   { KE_IGNORE, 0xC5, { KEY_VOLUMEUP } },  /* volume-up key 
> release 
*/
>   { KE_KEY, 0xC6, { KEY_VOLUMEDOWN } },   /* volume-down key 
> press */

Hello, maybe a stupid question, but why to not report both events "key 
pressed" and "key released" to userspace? IIRC kernel input layer can 
distinguish between these two type of events. But in intel-vbtn.c source 
code I see that all "release" ACPI events are ignored and just "press" 
are processed.

-- 
Pali Rohár
pali.ro...@gmail.com


signature.asc
Description: This is a digitally signed message part.

[PATCH] Documentation: link in networking docs

[Pavel Machek]

Fix link in filter.txt.

Acked-by: Pavel Machek 

diff --git a/Documentation/networking/filter.txt 
b/Documentation/networking/filter.txt
index e5e33ba..789b74d 100644
--- a/Documentation/networking/filter.txt
+++ b/Documentation/networking/filter.txt
@@ -45,7 +45,7 @@ in many more places. There's xt_bpf for netfilter, cls_bpf in 
the kernel
 qdisc layer, SECCOMP-BPF (SECure COMPuting [1]), and lots of other places
 such as team driver, PTP code, etc where BPF is being used.
 
- [1] Documentation/prctl/seccomp_filter.txt
+ [1] Documentation/userspace-api/seccomp_filter.rst
 
 Original BPF paper:
 

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


signature.asc
Description: Digital signature

[PATCH] [media] Si4713: Delete an error message for a failed memory allocation in two functions

[SF Markus Elfring]

From: Markus Elfring 
Date: Sat, 16 Sep 2017 16:15:44 +0200

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/media/radio/si4713/radio-platform-si4713.c | 1 -
 drivers/media/radio/si4713/si4713.c| 1 -
 2 files changed, 2 deletions(-)

diff --git a/drivers/media/radio/si4713/radio-platform-si4713.c 
b/drivers/media/radio/si4713/radio-platform-si4713.c
index 27339ec495f6..4b7943e385a0 100644
--- a/drivers/media/radio/si4713/radio-platform-si4713.c
+++ b/drivers/media/radio/si4713/radio-platform-si4713.c
@@ -162,5 +162,4 @@ static int radio_si4713_pdriver_probe(struct 
platform_device *pdev)
if (!rsdev) {
-   dev_err(&pdev->dev, "Failed to alloc video device.\n");
rval = -ENOMEM;
goto exit;
}
diff --git a/drivers/media/radio/si4713/si4713.c 
b/drivers/media/radio/si4713/si4713.c
index f4a53f1e856e..46b1fe36f713 100644
--- a/drivers/media/radio/si4713/si4713.c
+++ b/drivers/media/radio/si4713/si4713.c
@@ -1451,5 +1451,4 @@ static int si4713_probe(struct i2c_client *client,
if (!sdev) {
-   dev_err(&client->dev, "Failed to alloc video device.\n");
rval = -ENOMEM;
goto exit;
}
-- 
2.14.1

[PATCH 1/2] Staging: dgnc: Remove unused variables in struct dgnc_board

[Srishti Sharma]

Remove unused variables and comments associated with them in
the structure definition.

Signed-off-by: Srishti Sharma 
---
 drivers/staging/dgnc/dgnc_driver.h | 9 -
 1 file changed, 9 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_driver.h 
b/drivers/staging/dgnc/dgnc_driver.h
index 764d6fe..5d2566e 100644
--- a/drivers/staging/dgnc/dgnc_driver.h
+++ b/drivers/staging/dgnc/dgnc_driver.h
@@ -104,7 +104,6 @@ struct board_ops {
  * struct dgnc_board - Per board information.
  * @boardnum: Board number (0 - 32).
  *
- * @type: Type of board.
  * @name: Product name.
  * @pdev: Pointer to the pci_dev structure.
  * @bd_flags: Board flags.
@@ -140,13 +139,9 @@ struct board_ops {
  * @dpastatus: Board status as defined by DPA.
  * @bd_dividend: Board/UART's specific dividend.
  * @bd_ops: Pointer to board operations structure.
- * @proc_entry_pointer: Proc/ entry
- * @dgnc_board_table: Proc/ entry
  */
 struct dgnc_board {
int boardnum;
-
-   int type;
char*name;
struct pci_dev  *pdev;
unsigned long   bd_flags;
@@ -200,10 +195,6 @@ struct dgnc_board {
uintbd_dividend;
 
struct board_ops *bd_ops;
-
-   struct proc_dir_entry *proc_entry_pointer;
-   struct dgnc_proc_entry *dgnc_board_table;
-
 };
 
 /* Unit flag definitions for un_flags. */
-- 
2.7.4

[PATCH 2/2] Staging: dgnc: Remove unused variable in struct channel_t

[Srishti Sharma]

Eliminate the variables that are not used and the comments
associated with them.

Signed-off-by: Srishti Sharma 
---
 drivers/staging/dgnc/dgnc_driver.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_driver.h 
b/drivers/staging/dgnc/dgnc_driver.h
index 5d2566e..082d659 100644
--- a/drivers/staging/dgnc/dgnc_driver.h
+++ b/drivers/staging/dgnc/dgnc_driver.h
@@ -312,8 +312,6 @@ struct un_t {
  * @ch_err_overrun: Count of overruns on channel.
  * @ch_xon_sends: Count of xons transmitted.
  * @ch_xoff_sends: Count of xoffs transmitted.
- * @proc_entry_pointer: Proc// entry.
- * @dgnc_channel_table: Proc// entry.
  */
 struct channel_t {
struct dgnc_board *ch_bd;
@@ -382,10 +380,6 @@ struct channel_t {
 
ulong   ch_xon_sends;
ulong   ch_xoff_sends;
-
-   struct proc_dir_entry *proc_entry_pointer;
-   struct dgnc_proc_entry *dgnc_channel_table;
-
 };
 
 extern uintdgnc_major; /* Our driver/mgmt major */
-- 
2.7.4

[PATCH 0/2] Remove unused variables in structure definition

[Srishti Sharma]

This patch series attempts to remove unused variables in structure
variables and the comments associated with them.

Srishti Sharma (2):
  Staging: dgnc: Remove unused variables in structure definition
  Staging: dgnc: Remove unused variable in structure

 drivers/staging/dgnc/dgnc_driver.h | 15 ---
 1 file changed, 15 deletions(-)

-- 
2.7.4

Re: system hung up when offlining CPUs

[Thomas Gleixner]

On Sat, 16 Sep 2017, Thomas Gleixner wrote:
> On Thu, 14 Sep 2017, YASUAKI ISHIMATSU wrote:
> > Here are one irq's info of megasas:
> > 
> > - Before offline CPU
> > /proc/irq/70/smp_affinity_list
> > 24-29
> > 
> > /proc/irq/70/effective_affinity
> > ,,,,,,,,,,,,,,,3f00
> > 
> > /sys/kernel/debug/irq/irqs/70
> > handler:  handle_edge_irq
> > status:   0x4000
> > istate:   0x
> > ddepth:   0
> > wdepth:   0
> > dstate:   0x00609200
> > IRQD_ACTIVATED
> > IRQD_IRQ_STARTED
> > IRQD_MOVE_PCNTXT
> > IRQD_AFFINITY_SET
> > IRQD_AFFINITY_MANAGED
> 
> So this uses managed affinity, which means that once the last CPU in the
> affinity mask goes offline, the interrupt is shut down by the irq core
> code, which is the case:
> 
> > dstate:   0x00a39000
> > IRQD_IRQ_DISABLED
> > IRQD_IRQ_MASKED
> > IRQD_MOVE_PCNTXT
> > IRQD_AFFINITY_SET
> > IRQD_AFFINITY_MANAGED
> > IRQD_MANAGED_SHUTDOWN  <---
> 
> So the irq core code works as expected, but something in the
> driver/scsi/block stack seems to fiddle with that shut down queue.
> 
> I only can tell about the inner workings of the irq code, but I have no
> clue about the rest.

Though there is something wrong here:

> affinity: 24-29
> effectiv: 24-29

and after offlining:

> affinity: 29
> effectiv: 29

But that should be:

affinity: 24-29
effectiv: 29

because the irq core code preserves 'affinity'. It merily updates
'effective', which is where your interrupts are routed to.

Is the driver issuing any set_affinity() calls? If so, that's wrong.

Which driver are we talking about?

Thanks,

tglx

Re: [PATCH 1/3] Add a new element for the struct perf_tool, and add the --per-event-dump option for perf script

[David Ahern]

On 9/13/17 9:10 AM, yuzhoujian wrote:
> @@ -2797,7 +2801,12 @@ int cmd_script(int argc, const char **argv)
>  
>   file.path = input_name;
>   file.force = symbol_conf.force;
> -
> + for (i = 1; argv[i] != NULL; i++) {
> + if (strcmp(argv[i], "-O") == 0) {
> + script.tool.orientation_output = true;
> + break;
> + }
> + }
>   if (argc > 1 && !strncmp(argv[0], "rec", strlen("rec"))) {
>   rec_script_path = get_script_path(argv[1], RECORD_SUFFIX);
>   if (!rec_script_path)


That change should be dropped. I recall Arnaldo saying this feature does
not need a short option and the above is not how it should done anyways.

Re: [PATCH 2/3] Makes all those related functions receive the FILE pointer

[David Ahern]

On 9/13/17 9:10 AM, yuzhoujian wrote:
> @@ -1621,8 +1634,12 @@ static int process_comm_event(struct perf_tool *tool,
>   sample->tid = event->comm.tid;
>   sample->pid = event->comm.pid;
>   }
> - print_sample_start(sample, thread, evsel);
> - perf_event__fprintf(event, stdout);
> + if (tool->orientation_output == false)
> + fp = stdout;
> + else
> + fp = orientation_file;
> + fprint_sample_start(sample, thread, evsel, fp);
> + perf_event__fprintf(event, fp);
>   ret = 0;
>  out:
>   thread__put(thread);

The subject of this patch is replacing printf and stdout with fprintf
and a given fp. Please keep it to that one change. Meaning the above
setting of fp something other than stdout should be a separate patch.

And it would be best to have the fp selection in a helper, versus the
same change in so many places.

Re: [Outreachy kernel] [PATCH 0/2] Remove unused variables in structure definition

[Julia Lawall]

On Sat, 16 Sep 2017, Srishti Sharma wrote:

> This patch series attempts to remove unused variables in structure
> variables and the comments associated with them.

Actually, I would say that a structure has fields, not variables.

julia

>
> Srishti Sharma (2):
>   Staging: dgnc: Remove unused variables in structure definition
>   Staging: dgnc: Remove unused variable in structure
>
>  drivers/staging/dgnc/dgnc_driver.h | 15 ---
>  1 file changed, 15 deletions(-)
>
> --
> 2.7.4
>
> --
> You received this message because you are subscribed to the Google Groups 
> "outreachy-kernel" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to outreachy-kernel+unsubscr...@googlegroups.com.
> To post to this group, send email to outreachy-ker...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/outreachy-kernel/cover.1505572018.git.srishtishar%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.
>

[PATCH] mwifiex: make const arrays static to shink object code size

[Colin King]

From: Colin Ian King 

Don't populate const arrays on the stack, instead make them static
Makes the object code smaller by nearly 300 bytes:

Before:
   textdata bss dec hex filename
  69260   16149 576   85985   14fe1 cfg80211.o

After:
   textdata bss dec hex filename
  68385   16725 576   85686   14eb6 cfg80211.o

Signed-off-by: Colin Ian King 
---
 drivers/net/wireless/marvell/mwifiex/cfg80211.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/net/wireless/marvell/mwifiex/cfg80211.c 
b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
index 32c5074da84c..c45b86fcfd8d 100644
--- a/drivers/net/wireless/marvell/mwifiex/cfg80211.c
+++ b/drivers/net/wireless/marvell/mwifiex/cfg80211.c
@@ -142,7 +142,7 @@ mwifiex_cfg80211_del_key(struct wiphy *wiphy, struct 
net_device *netdev,
 u8 key_index, bool pairwise, const u8 *mac_addr)
 {
struct mwifiex_private *priv = mwifiex_netdev_get_priv(netdev);
-   const u8 bc_mac[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
+   static const u8 bc_mac[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
const u8 *peer_mac = pairwise ? mac_addr : bc_mac;
 
if (mwifiex_set_encode(priv, NULL, NULL, 0, key_index, peer_mac, 1)) {
@@ -454,7 +454,7 @@ mwifiex_cfg80211_add_key(struct wiphy *wiphy, struct 
net_device *netdev,
 {
struct mwifiex_private *priv = mwifiex_netdev_get_priv(netdev);
struct mwifiex_wep_key *wep_key;
-   const u8 bc_mac[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
+   static const u8 bc_mac[] = {0xff, 0xff, 0xff, 0xff, 0xff, 0xff};
const u8 *peer_mac = pairwise ? mac_addr : bc_mac;
 
if (GET_BSS_ROLE(priv) == MWIFIEX_BSS_ROLE_UAP &&
@@ -3250,8 +3250,8 @@ static int mwifiex_set_wowlan_mef_entry(struct 
mwifiex_private *priv,
int i, filt_num = 0, ret = 0;
bool first_pat = true;
u8 byte_seq[MWIFIEX_MEF_MAX_BYTESEQ + 1];
-   const u8 ipv4_mc_mac[] = {0x33, 0x33};
-   const u8 ipv6_mc_mac[] = {0x01, 0x00, 0x5e};
+   static const u8 ipv4_mc_mac[] = {0x33, 0x33};
+   static const u8 ipv6_mc_mac[] = {0x01, 0x00, 0x5e};
 
mef_entry->mode = MEF_MODE_HOST_SLEEP;
mef_entry->action = MEF_ACTION_ALLOW_AND_WAKEUP_HOST;
@@ -3544,9 +3544,9 @@ static int mwifiex_set_rekey_data(struct wiphy *wiphy, 
struct net_device *dev,
 
 static int mwifiex_get_coalesce_pkt_type(u8 *byte_seq)
 {
-   const u8 ipv4_mc_mac[] = {0x33, 0x33};
-   const u8 ipv6_mc_mac[] = {0x01, 0x00, 0x5e};
-   const u8 bc_mac[] = {0xff, 0xff, 0xff, 0xff};
+   static const u8 ipv4_mc_mac[] = {0x33, 0x33};
+   static const u8 ipv6_mc_mac[] = {0x01, 0x00, 0x5e};
+   static const u8 bc_mac[] = {0xff, 0xff, 0xff, 0xff};
 
if ((byte_seq[0] & 0x01) &&
(byte_seq[MWIFIEX_COALESCE_MAX_BYTESEQ] == 1))
-- 
2.14.1

Re: [Part1 PATCH v4 01/17] Documentation/x86: Add AMD Secure Encrypted Virtualization (SEV) description

[Borislav Petkov]

On Sat, Sep 16, 2017 at 07:34:02AM -0500, Brijesh Singh wrote:
> Update the AMD memory encryption document describing the Secure Encrypted
> Virtualization (SEV) feature.
> 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: Jonathan Corbet 
> Cc: Borislav Petkov 
> Cc: Tom Lendacky 
> Signed-off-by: Brijesh Singh 
> ---
>  Documentation/x86/amd-memory-encryption.txt | 30 
> +
>  1 file changed, 26 insertions(+), 4 deletions(-)

Reviewed-by: Borislav Petkov 

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
--