[GIT PULL] apparmor updates for v4.14-rc2

[John Johansen]

Hi,

This is a direct apparmor pull request, similar to SELinux's for the
v4.14 window, and the seccomp request that was sent today for
v4.14-rc2; it's the same series that I was sent to James' security
tree + one regression fix that was found after the series was sent to
James and would have been sent for v4.14-rc2

Please pull these apparmor changes for v4.14-rc2.

Thanks!

- John


The following changes since commit 520eccdfe187591a51ea9ab4c1a024ae4d0f68d9:

  Linux 4.13-rc2 (2017-07-23 16:15:17 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor 
tags/apparmor-pr-2017-09-22

for you to fetch changes up to bf81100f63db7ea243d17b9d5008ba3af2fdf6b2:

  apparmor: fix apparmorfs DAC access permissions (2017-09-22 13:20:01 -0700)


+ Features
  - in preparation for secid mapping add support for absolute root view
based labels
  - add base infrastructure for socket mediation
  - add mount mediation
  - add signal mediation

+ minor clean-ups and changes
  - be defensive, ensure unconfined profiles have dfas initialized
  - add more debug asserts to apparmorfs
  - enable policy unpacking to audit different reasons for failure
  - cleanup conditional check for label in label_print
  - Redundant condition: prev_ns. in [label.c:1498]

+ Bug Fixes
  - fix regression in apparmorfs DAC access permissions
  - fix build failure on sparc caused by undeclared signals
  - fix sparse report of incorrect type assignment when freeing label proxies
  - fix race condition in null profile creation
  - Fix an error code in aafs_create()
  - Fix logical error in verify_header()
  - Fix shadowed local variable in unpack_trans_table()


Christos Gkekas (1):
  apparmor: Fix logical error in verify_header()

Dan Carpenter (1):
  apparmor: Fix an error code in aafs_create()

Geert Uytterhoeven (1):
  apparmor: Fix shadowed local variable in unpack_trans_table()

John Johansen (14):
  apparmor: Redundant condition: prev_ns. in [label.c:1498]
  apparmor: add the ability to mediate signals
  apparmor: add mount mediation
  apparmor: cleanup conditional check for label in label_print
  apparmor: add support for absolute root view based labels
  apparmor: make policy_unpack able to audit different info messages
  apparmor: add more debug asserts to apparmorfs
  apparmor: add base infastructure for socket mediation
  apparmor: move new_null_profile to after profile lookup fns()
  apparmor: fix race condition in null profile creation
  apparmor: ensure unconfined profiles have dfas initialized
  apparmor: fix incorrect type assignment when freeing proxies
  apparmor: fix build failure on sparc caused by undeclared signals
  apparmor: fix apparmorfs DAC access permissions

 security/apparmor/.gitignore  |   1 +
 security/apparmor/Makefile|  43 ++-
 security/apparmor/apparmorfs.c|  45 ++-
 security/apparmor/domain.c|   4 +-
 security/apparmor/file.c  |  30 ++
 security/apparmor/include/apparmor.h  |   2 +
 security/apparmor/include/audit.h |  39 +-
 security/apparmor/include/domain.h|   5 +
 security/apparmor/include/ipc.h   |   6 +
 security/apparmor/include/label.h |   1 +
 security/apparmor/include/mount.h |  54 +++
 security/apparmor/include/net.h   | 114 ++
 security/apparmor/include/perms.h |   5 +-
 security/apparmor/include/policy.h|  13 +
 security/apparmor/include/sig_names.h |  98 +
 security/apparmor/ipc.c   |  99 +
 security/apparmor/label.c |  36 +-
 security/apparmor/lib.c   |   5 +-
 security/apparmor/lsm.c   | 472 +++
 security/apparmor/mount.c | 696 ++
 security/apparmor/net.c   | 184 +
 security/apparmor/policy.c| 166 
 security/apparmor/policy_ns.c |   2 +
 security/apparmor/policy_unpack.c | 105 -
 24 files changed, 2088 insertions(+), 137 deletions(-)
 create mode 100644 security/apparmor/include/mount.h
 create mode 100644 security/apparmor/include/net.h
 create mode 100644 security/apparmor/include/sig_names.h
 create mode 100644 security/apparmor/mount.c
 create mode 100644 security/apparmor/net.c



signature.asc
Description: OpenPGP digital signature

[GIT PULL] apparmor updates for v4.14-rc2

[John Johansen]

Hi,

This is a direct apparmor pull request, similar to SELinux's for the
v4.14 window, and the seccomp request that was sent today for
v4.14-rc2; it's the same series that I was sent to James' security
tree + one regression fix that was found after the series was sent to
James and would have been sent for v4.14-rc2

Please pull these apparmor changes for v4.14-rc2.

Thanks!

- John


The following changes since commit 520eccdfe187591a51ea9ab4c1a024ae4d0f68d9:

  Linux 4.13-rc2 (2017-07-23 16:15:17 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor 
tags/apparmor-pr-2017-09-22

for you to fetch changes up to bf81100f63db7ea243d17b9d5008ba3af2fdf6b2:

  apparmor: fix apparmorfs DAC access permissions (2017-09-22 13:20:01 -0700)


+ Features
  - in preparation for secid mapping add support for absolute root view
based labels
  - add base infrastructure for socket mediation
  - add mount mediation
  - add signal mediation

+ minor clean-ups and changes
  - be defensive, ensure unconfined profiles have dfas initialized
  - add more debug asserts to apparmorfs
  - enable policy unpacking to audit different reasons for failure
  - cleanup conditional check for label in label_print
  - Redundant condition: prev_ns. in [label.c:1498]

+ Bug Fixes
  - fix regression in apparmorfs DAC access permissions
  - fix build failure on sparc caused by undeclared signals
  - fix sparse report of incorrect type assignment when freeing label proxies
  - fix race condition in null profile creation
  - Fix an error code in aafs_create()
  - Fix logical error in verify_header()
  - Fix shadowed local variable in unpack_trans_table()


Christos Gkekas (1):
  apparmor: Fix logical error in verify_header()

Dan Carpenter (1):
  apparmor: Fix an error code in aafs_create()

Geert Uytterhoeven (1):
  apparmor: Fix shadowed local variable in unpack_trans_table()

John Johansen (14):
  apparmor: Redundant condition: prev_ns. in [label.c:1498]
  apparmor: add the ability to mediate signals
  apparmor: add mount mediation
  apparmor: cleanup conditional check for label in label_print
  apparmor: add support for absolute root view based labels
  apparmor: make policy_unpack able to audit different info messages
  apparmor: add more debug asserts to apparmorfs
  apparmor: add base infastructure for socket mediation
  apparmor: move new_null_profile to after profile lookup fns()
  apparmor: fix race condition in null profile creation
  apparmor: ensure unconfined profiles have dfas initialized
  apparmor: fix incorrect type assignment when freeing proxies
  apparmor: fix build failure on sparc caused by undeclared signals
  apparmor: fix apparmorfs DAC access permissions

 security/apparmor/.gitignore  |   1 +
 security/apparmor/Makefile|  43 ++-
 security/apparmor/apparmorfs.c|  45 ++-
 security/apparmor/domain.c|   4 +-
 security/apparmor/file.c  |  30 ++
 security/apparmor/include/apparmor.h  |   2 +
 security/apparmor/include/audit.h |  39 +-
 security/apparmor/include/domain.h|   5 +
 security/apparmor/include/ipc.h   |   6 +
 security/apparmor/include/label.h |   1 +
 security/apparmor/include/mount.h |  54 +++
 security/apparmor/include/net.h   | 114 ++
 security/apparmor/include/perms.h |   5 +-
 security/apparmor/include/policy.h|  13 +
 security/apparmor/include/sig_names.h |  98 +
 security/apparmor/ipc.c   |  99 +
 security/apparmor/label.c |  36 +-
 security/apparmor/lib.c   |   5 +-
 security/apparmor/lsm.c   | 472 +++
 security/apparmor/mount.c | 696 ++
 security/apparmor/net.c   | 184 +
 security/apparmor/policy.c| 166 
 security/apparmor/policy_ns.c |   2 +
 security/apparmor/policy_unpack.c | 105 -
 24 files changed, 2088 insertions(+), 137 deletions(-)
 create mode 100644 security/apparmor/include/mount.h
 create mode 100644 security/apparmor/include/net.h
 create mode 100644 security/apparmor/include/sig_names.h
 create mode 100644 security/apparmor/mount.c
 create mode 100644 security/apparmor/net.c



signature.asc
Description: OpenPGP digital signature

[GIT] Networking

[David Miller]

1) Fix NAPI poll list corruption in enic driver, from Christian
   Lamparter.

2) Fix route use after free, from Eric Dumazet.

3) Fix regression in reuseaddr handling, from Josef Bacik.

4) Assert the size of control messages in compat handling since we
   copy it in from userspace twice.  From Meng Xu.

5) SMC layer bug fixes (missing RCU locking, bad refcounting, etc.)
   from Ursula Braun.

6) Fix races in AF_PACKET fanout handling, from Willem de Bruijn.

7) Don't use ARRAY_SIZE on spinlock array which might have zero
   entries, from Geert Uytterhoeven.

8) Fix miscomputation of checksum in ipv6 udp code, from Subash
   Abhinov Kasiviswanathan.

9) Push the ipv6 header properly in ipv6 GRE tunnel driver, from
   Xin Long.

Please pull, thanks a lot.

The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:

  Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 

for you to fetch changes up to 4e683f499a15cd777d3cb51aaebe48d72334c852:

  Merge branch 'net-fix-reuseaddr-regression' (2017-09-22 20:33:18 -0700)


Alex Ng (1):
  hv_netvsc: fix send buffer failure on MTU change

Andreas Gruenbacher (1):
  rhashtable: Documentation tweak

Ariel Elior (1):
  MAINTAINERS: Remove Yuval Mintz from maintainers list

Christian Lamparter (1):
  net: emac: Fix napi poll list corruption

Cong Wang (1):
  net_sched: remove cls_flower idr on failure

Daniel Borkmann (1):
  bpf: fix ri->map_owner pointer on bpf_prog_realloc

David S. Miller (8):
  Merge tag 'mac80211-for-davem-2017-11-19' of 
git://git.kernel.org/.../jberg/mac80211
  Merge branch 'hns3-bug-fixes'
  Merge git://git.kernel.org/.../pablo/nf
  Merge branch 'hns3-tm-fixes'
  Merge branch 'phylib-xcvr-type'
  Merge branch 'lan78xx-fixes'
  Merge branch 'smc-bug-fixes'
  Merge branch 'net-fix-reuseaddr-regression'

Davide Caratti (1):
  net/sched: cls_matchall: fix crash when used with classful qdisc

Edward Cree (1):
  net: change skb->mac_header when Generic XDP calls adjust_head

Eric Dumazet (4):
  8139too: revisit napi_complete_done() usage
  bpf: do not disable/enable BH in bpf_map_free_id()
  tcp: fastopen: fix on syn-data transmit failure
  net: prevent dst uses after free

Fahad Kunnathadi (1):
  net: phy: Fix mask value write on gmii2rgmii converter speed register

Florian Fainelli (3):
  net: systemport: Fix 64-bit statistics dependency
  net: ethtool: Add back transceiver type
  net: phy: Keep reporting transceiver type

Geert Uytterhoeven (2):
  netfilter: nat: Do not use ARRAY_SIZE() on spinlocks to fix zero div
  net: phy: Fix truncation of large IRQ numbers in phy_attached_print()

Hans Wippel (2):
  net/smc: add missing dev_put
  net/smc: add receive timeout check

Jerome Brunet (1):
  net: phy: Kconfig: Fix PHY infrastructure menu in menuconfig

Johannes Berg (1):
  nl80211: fix null-ptr dereference on invalid mesh configuration

Josef Bacik (3):
  net: set tb->fast_sk_family
  net: use inet6_rcv_saddr to compare sockets
  inet: fix improper empty comparison

Konstantin Khlebnikov (2):
  net_sched: always reset qdisc backlog in qdisc_reset()
  net_sched/hfsc: fix curve activation in hfsc_change_class()

Lipeng (6):
  net: hns3: Fixes initialization of phy address from firmware
  net: hns3: Fixes the command used to unmap ring from vector
  net: hns3: Fixes ring-to-vector map-and-unmap command
  net: hns3: Fixes the initialization of MAC address in hardware
  net: hns3: Fixes the default VLAN-id of PF
  net: hns3: Fixes the premature exit of loop when matching clients

Matteo Croce (1):
  ipv6: fix net.ipv6.conf.all interface DAD handlers

Meng Xu (2):
  net: compat: assert the size of cmsg copied in is as expected
  isdn/i4l: fetch the ppp_write buffer in one shot

Mike Manning (1):
  net: ipv6: fix regression of no RTM_DELADDR sent after DAD failure

Nisar Sayed (3):
  lan78xx: Fix for eeprom read/write when device auto suspend
  lan78xx: Allow EEPROM write for less than MAX_EEPROM_SIZE
  lan78xx: Use default values loaded from EEPROM/OTP after reset

Randy Dunlap (1):
  Documentation: networking: fix ASCII art in switchdev.txt

Salil Mehta (1):
  net: hns3: Fixes the ether address copy with appropriate API

Sathya Perla (1):
  bnxt_en: check for ingress qdisc in flower offload

Stefan Schmidt (1):
  MAINTAINERS: update git tree locations for ieee802154 subsystem

Subash Abhinov Kasiviswanathan (1):
  udpv6: Fix the checksum computation when HW checksum does not apply

Thomas Meyer (1):
  net: stmmac: Cocci spatch "of_table"

Timur Tabi (1):
  net: qcom/emac: add software control for pause frame mode

Tobias Klauser (1):
  bpf: devmap: pass on 

[GIT] Networking

[David Miller]

1) Fix NAPI poll list corruption in enic driver, from Christian
   Lamparter.

2) Fix route use after free, from Eric Dumazet.

3) Fix regression in reuseaddr handling, from Josef Bacik.

4) Assert the size of control messages in compat handling since we
   copy it in from userspace twice.  From Meng Xu.

5) SMC layer bug fixes (missing RCU locking, bad refcounting, etc.)
   from Ursula Braun.

6) Fix races in AF_PACKET fanout handling, from Willem de Bruijn.

7) Don't use ARRAY_SIZE on spinlock array which might have zero
   entries, from Geert Uytterhoeven.

8) Fix miscomputation of checksum in ipv6 udp code, from Subash
   Abhinov Kasiviswanathan.

9) Push the ipv6 header properly in ipv6 GRE tunnel driver, from
   Xin Long.

Please pull, thanks a lot.

The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:

  Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/davem/net 

for you to fetch changes up to 4e683f499a15cd777d3cb51aaebe48d72334c852:

  Merge branch 'net-fix-reuseaddr-regression' (2017-09-22 20:33:18 -0700)


Alex Ng (1):
  hv_netvsc: fix send buffer failure on MTU change

Andreas Gruenbacher (1):
  rhashtable: Documentation tweak

Ariel Elior (1):
  MAINTAINERS: Remove Yuval Mintz from maintainers list

Christian Lamparter (1):
  net: emac: Fix napi poll list corruption

Cong Wang (1):
  net_sched: remove cls_flower idr on failure

Daniel Borkmann (1):
  bpf: fix ri->map_owner pointer on bpf_prog_realloc

David S. Miller (8):
  Merge tag 'mac80211-for-davem-2017-11-19' of 
git://git.kernel.org/.../jberg/mac80211
  Merge branch 'hns3-bug-fixes'
  Merge git://git.kernel.org/.../pablo/nf
  Merge branch 'hns3-tm-fixes'
  Merge branch 'phylib-xcvr-type'
  Merge branch 'lan78xx-fixes'
  Merge branch 'smc-bug-fixes'
  Merge branch 'net-fix-reuseaddr-regression'

Davide Caratti (1):
  net/sched: cls_matchall: fix crash when used with classful qdisc

Edward Cree (1):
  net: change skb->mac_header when Generic XDP calls adjust_head

Eric Dumazet (4):
  8139too: revisit napi_complete_done() usage
  bpf: do not disable/enable BH in bpf_map_free_id()
  tcp: fastopen: fix on syn-data transmit failure
  net: prevent dst uses after free

Fahad Kunnathadi (1):
  net: phy: Fix mask value write on gmii2rgmii converter speed register

Florian Fainelli (3):
  net: systemport: Fix 64-bit statistics dependency
  net: ethtool: Add back transceiver type
  net: phy: Keep reporting transceiver type

Geert Uytterhoeven (2):
  netfilter: nat: Do not use ARRAY_SIZE() on spinlocks to fix zero div
  net: phy: Fix truncation of large IRQ numbers in phy_attached_print()

Hans Wippel (2):
  net/smc: add missing dev_put
  net/smc: add receive timeout check

Jerome Brunet (1):
  net: phy: Kconfig: Fix PHY infrastructure menu in menuconfig

Johannes Berg (1):
  nl80211: fix null-ptr dereference on invalid mesh configuration

Josef Bacik (3):
  net: set tb->fast_sk_family
  net: use inet6_rcv_saddr to compare sockets
  inet: fix improper empty comparison

Konstantin Khlebnikov (2):
  net_sched: always reset qdisc backlog in qdisc_reset()
  net_sched/hfsc: fix curve activation in hfsc_change_class()

Lipeng (6):
  net: hns3: Fixes initialization of phy address from firmware
  net: hns3: Fixes the command used to unmap ring from vector
  net: hns3: Fixes ring-to-vector map-and-unmap command
  net: hns3: Fixes the initialization of MAC address in hardware
  net: hns3: Fixes the default VLAN-id of PF
  net: hns3: Fixes the premature exit of loop when matching clients

Matteo Croce (1):
  ipv6: fix net.ipv6.conf.all interface DAD handlers

Meng Xu (2):
  net: compat: assert the size of cmsg copied in is as expected
  isdn/i4l: fetch the ppp_write buffer in one shot

Mike Manning (1):
  net: ipv6: fix regression of no RTM_DELADDR sent after DAD failure

Nisar Sayed (3):
  lan78xx: Fix for eeprom read/write when device auto suspend
  lan78xx: Allow EEPROM write for less than MAX_EEPROM_SIZE
  lan78xx: Use default values loaded from EEPROM/OTP after reset

Randy Dunlap (1):
  Documentation: networking: fix ASCII art in switchdev.txt

Salil Mehta (1):
  net: hns3: Fixes the ether address copy with appropriate API

Sathya Perla (1):
  bnxt_en: check for ingress qdisc in flower offload

Stefan Schmidt (1):
  MAINTAINERS: update git tree locations for ieee802154 subsystem

Subash Abhinov Kasiviswanathan (1):
  udpv6: Fix the checksum computation when HW checksum does not apply

Thomas Meyer (1):
  net: stmmac: Cocci spatch "of_table"

Timur Tabi (1):
  net: qcom/emac: add software control for pause frame mode

Tobias Klauser (1):
  bpf: devmap: pass on 

[PATCH] clk: Export clk_bulk_prepare()

[Bjorn Andersson]

Allow clk_bulk_prepare() to be referenced by kernel modules by adding
the missing EXPORT_SYMBOL_GPL().

Fixes: 266e4e9d9150 ("clk: add clk_bulk_get accessories")
Reported-by: Ulf Hansson 
Signed-off-by: Bjorn Andersson 
---
 drivers/clk/clk-bulk.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/clk-bulk.c b/drivers/clk/clk-bulk.c
index c834f5abfc49..4c10456f8a32 100644
--- a/drivers/clk/clk-bulk.c
+++ b/drivers/clk/clk-bulk.c
@@ -105,6 +105,7 @@ int __must_check clk_bulk_prepare(int num_clks,
 
return  ret;
 }
+EXPORT_SYMBOL_GPL(clk_bulk_prepare);
 
 #endif /* CONFIG_HAVE_CLK_PREPARE */
 
-- 
2.12.0

[PATCH] clk: Export clk_bulk_prepare()

[Bjorn Andersson]

Allow clk_bulk_prepare() to be referenced by kernel modules by adding
the missing EXPORT_SYMBOL_GPL().

Fixes: 266e4e9d9150 ("clk: add clk_bulk_get accessories")
Reported-by: Ulf Hansson 
Signed-off-by: Bjorn Andersson 
---
 drivers/clk/clk-bulk.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/clk/clk-bulk.c b/drivers/clk/clk-bulk.c
index c834f5abfc49..4c10456f8a32 100644
--- a/drivers/clk/clk-bulk.c
+++ b/drivers/clk/clk-bulk.c
@@ -105,6 +105,7 @@ int __must_check clk_bulk_prepare(int num_clks,
 
return  ret;
 }
+EXPORT_SYMBOL_GPL(clk_bulk_prepare);
 
 #endif /* CONFIG_HAVE_CLK_PREPARE */
 
-- 
2.12.0

Re: [PATCH] params: Align add_sysfs_param documentation with code

[Rusty Russell]

Jean Delvare  writes:

> This parameter is named kp, so the documentation should use that.
>
> Signed-off-by: Jean Delvare 
> Fixes: 9b473de87209 ("param: Fix duplicate module prefixes")
> Cc: Rusty Russell 

Acked-by: Rusty Russell 

Thanks,
Rusty.

> ---
>  kernel/params.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-4.14-rc1.orig/kernel/params.c   2017-09-17 00:47:51.0 
> +0200
> +++ linux-4.14-rc1/kernel/params.c2017-09-19 14:19:51.399247222 +0200
> @@ -600,7 +600,7 @@ EXPORT_SYMBOL(kernel_param_unlock);
>  /*
>   * add_sysfs_param - add a parameter to sysfs
>   * @mk: struct module_kobject
> - * @kparam: the actual parameter definition to add to sysfs
> + * @kp: the actual parameter definition to add to sysfs
>   * @name: name of parameter
>   *
>   * Create a kobject if for a (per-module) parameter if mp NULL, and
>
> -- 
> Jean Delvare
> SUSE L3 Support

Re: [PATCH] params: Align add_sysfs_param documentation with code

[Rusty Russell]

Jean Delvare  writes:

> This parameter is named kp, so the documentation should use that.
>
> Signed-off-by: Jean Delvare 
> Fixes: 9b473de87209 ("param: Fix duplicate module prefixes")
> Cc: Rusty Russell 

Acked-by: Rusty Russell 

Thanks,
Rusty.

> ---
>  kernel/params.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-4.14-rc1.orig/kernel/params.c   2017-09-17 00:47:51.0 
> +0200
> +++ linux-4.14-rc1/kernel/params.c2017-09-19 14:19:51.399247222 +0200
> @@ -600,7 +600,7 @@ EXPORT_SYMBOL(kernel_param_unlock);
>  /*
>   * add_sysfs_param - add a parameter to sysfs
>   * @mk: struct module_kobject
> - * @kparam: the actual parameter definition to add to sysfs
> + * @kp: the actual parameter definition to add to sysfs
>   * @name: name of parameter
>   *
>   * Create a kobject if for a (per-module) parameter if mp NULL, and
>
> -- 
> Jean Delvare
> SUSE L3 Support

drivers/scsi/pcmcia/aha152x_core.o: warning: objtool: is_complete()+0x83: unreachable instruction

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   c0a3a64e723324ae6dda53214061a71de63808c3
commit: 39358a033b2e4432052265c1fa0f36f572d8cfb5 objtool, x86: Add facility for 
asm code to provide unwind hints
date:   10 weeks ago
config: x86_64-randconfig-v0-09231149 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
git checkout 39358a033b2e4432052265c1fa0f36f572d8cfb5
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

>> drivers/scsi/pcmcia/aha152x_core.o: warning: objtool: is_complete()+0x83: 
>> unreachable instruction

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


.config.gz
Description: application/gzip

drivers/scsi/pcmcia/aha152x_core.o: warning: objtool: is_complete()+0x83: unreachable instruction

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   c0a3a64e723324ae6dda53214061a71de63808c3
commit: 39358a033b2e4432052265c1fa0f36f572d8cfb5 objtool, x86: Add facility for 
asm code to provide unwind hints
date:   10 weeks ago
config: x86_64-randconfig-v0-09231149 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
git checkout 39358a033b2e4432052265c1fa0f36f572d8cfb5
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

>> drivers/scsi/pcmcia/aha152x_core.o: warning: objtool: is_complete()+0x83: 
>> unreachable instruction

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


.config.gz
Description: application/gzip

drivers/staging//rtlwifi/phydm/phydm_dig.c:494:45: warning: array subscript is below array bounds

[kbuild test robot]

Hi Larry,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   c0a3a64e723324ae6dda53214061a71de63808c3
commit: 5b5ab4cb5cda824ef59e0511ac5d585f35f1a1a6 staging: r8822be: Add 
Makefiles and Kconfig for new driver
date:   5 weeks ago
config: x86_64-randconfig-n0-09231026 (attached as .config)
compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
reproduce:
git checkout 5b5ab4cb5cda824ef59e0511ac5d585f35f1a1a6
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.

All warnings (new ones prefixed by >>):

   Cyclomatic Complexity 5 
drivers/staging//rtlwifi/phydm/phydm_dig.c:get_igi_for_diff
   Cyclomatic Complexity 11 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_fa_threshold_check
   Cyclomatic Complexity 7 
drivers/staging//rtlwifi/phydm/phydm_dig.c:phydm_get_current_igi
   Cyclomatic Complexity 21 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_dig_abort
   Cyclomatic Complexity 16 
drivers/staging//rtlwifi/phydm/phydm_dig.c:phydm_set_big_jump_step
   Cyclomatic Complexity 19 
drivers/staging//rtlwifi/phydm/phydm_dig.c:phydm_check_ap_write_dig
   Cyclomatic Complexity 60 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_forbidden_igi_check
   Cyclomatic Complexity 21 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_change_dynamic_init_gain_thresh
   Cyclomatic Complexity 59 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_write_dig
   Cyclomatic Complexity 56 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_pause_dig
   Cyclomatic Complexity 13 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_dig_init
   Cyclomatic Complexity 197 drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_DIG
   Cyclomatic Complexity 22 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_dig_by_rssi_lps
   Cyclomatic Complexity 35 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_false_alarm_counter_statistics
   Cyclomatic Complexity 3 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_write_cck_cca_thres
   Cyclomatic Complexity 56 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_pause_cck_packet_detection
   Cyclomatic Complexity 31 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_cck_packet_detection_thresh
   Cyclomatic Complexity 1 
drivers/staging//rtlwifi/phydm/phydm_dig.c:phydm_dig_go_up_check
   drivers/staging//rtlwifi/phydm/phydm_dig.c: In function 'odm_pause_dig':
>> drivers/staging//rtlwifi/phydm/phydm_dig.c:494:45: warning: array subscript 
>> is below array bounds [-Warray-bounds]
  odm_write_dig(dm, dig_tab->pause_dig_value[max_level]);
^
   drivers/staging//rtlwifi/phydm/phydm_dig.c: In function 
'odm_pause_cck_packet_detection':
   drivers/staging//rtlwifi/phydm/phydm_dig.c:1429:32: warning: array subscript 
is below array bounds [-Warray-bounds]
 dig_tab->pause_cckpd_value[max_level]);
   ^

vim +494 drivers/staging//rtlwifi/phydm/phydm_dig.c

9ce99b04 Ping-Ke Shih 2017-08-17  380  
9ce99b04 Ping-Ke Shih 2017-08-17  381  void odm_pause_dig(void *dm_void, enum 
phydm_pause_type pause_type,
9ce99b04 Ping-Ke Shih 2017-08-17  382  enum phydm_pause_level 
pause_level, u8 igi_value)
9ce99b04 Ping-Ke Shih 2017-08-17  383  {
9ce99b04 Ping-Ke Shih 2017-08-17  384   struct phy_dm_struct *dm = (struct 
phy_dm_struct *)dm_void;
9ce99b04 Ping-Ke Shih 2017-08-17  385   struct dig_thres *dig_tab = 
>dm_dig_table;
9ce99b04 Ping-Ke Shih 2017-08-17  386   s8 max_level;
9ce99b04 Ping-Ke Shih 2017-08-17  387  
9ce99b04 Ping-Ke Shih 2017-08-17  388   ODM_RT_TRACE(dm, ODM_COMP_DIG, 
"%s()=> level = %d\n", __func__,
9ce99b04 Ping-Ke Shih 2017-08-17  389pause_level);
9ce99b04 Ping-Ke Shih 2017-08-17  390  
9ce99b04 Ping-Ke Shih 2017-08-17  391   if ((dig_tab->pause_dig_level == 0) &&
9ce99b04 Ping-Ke Shih 2017-08-17  392   (!(dm->support_ability & 
ODM_BB_DIG) ||
9ce99b04 Ping-Ke Shih 2017-08-17  393!(dm->support_ability & 
ODM_BB_FA_CNT))) {
9ce99b04 Ping-Ke Shih 2017-08-17  394   ODM_RT_TRACE(
9ce99b04 Ping-Ke Shih 2017-08-17  395   dm, ODM_COMP_DIG,
9ce99b04 Ping-Ke Shih 2017-08-17  396   "%s(): Return: 
support_ability DIG or FA is disabled !!\n",
9ce99b04 Ping-Ke Shih 2017-08-17  397   __func__);
9ce99b04 Ping-Ke Shih 2017-08-17  398   return;
9ce99b04 Ping-Ke Shih 2017-08-17  399   }
9ce99b04 Ping-Ke Shih 2017-08-17  400  
9ce99b04 Ping-Ke Shih 2017-08-17  401   if (pause_level > 
DM_DIG_MAX_PAUSE_TYPE) {
9ce99b04 Ping-Ke Shih 2017-08-17  402   ODM_RT_TRACE(dm, ODM_COMP_DIG,
9ce99b04 Ping-Ke Shih 2017-08-17  403"%s(): Return: 
Wrong pause level !!\n", __func__);
9ce99b04 Ping-Ke Shih 2017-08-17  404   return;
9ce99b04 Ping-Ke Shih 2017-08-17  405   }
9ce99b04 Ping-Ke Shih 2017-08-17  406  
9ce99b04 Ping-Ke Shih 2017-08-17  407   

drivers/staging//rtlwifi/phydm/phydm_dig.c:494:45: warning: array subscript is below array bounds

[kbuild test robot]

Hi Larry,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   c0a3a64e723324ae6dda53214061a71de63808c3
commit: 5b5ab4cb5cda824ef59e0511ac5d585f35f1a1a6 staging: r8822be: Add 
Makefiles and Kconfig for new driver
date:   5 weeks ago
config: x86_64-randconfig-n0-09231026 (attached as .config)
compiler: gcc-4.8 (Debian 4.8.4-1) 4.8.4
reproduce:
git checkout 5b5ab4cb5cda824ef59e0511ac5d585f35f1a1a6
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.

All warnings (new ones prefixed by >>):

   Cyclomatic Complexity 5 
drivers/staging//rtlwifi/phydm/phydm_dig.c:get_igi_for_diff
   Cyclomatic Complexity 11 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_fa_threshold_check
   Cyclomatic Complexity 7 
drivers/staging//rtlwifi/phydm/phydm_dig.c:phydm_get_current_igi
   Cyclomatic Complexity 21 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_dig_abort
   Cyclomatic Complexity 16 
drivers/staging//rtlwifi/phydm/phydm_dig.c:phydm_set_big_jump_step
   Cyclomatic Complexity 19 
drivers/staging//rtlwifi/phydm/phydm_dig.c:phydm_check_ap_write_dig
   Cyclomatic Complexity 60 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_forbidden_igi_check
   Cyclomatic Complexity 21 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_change_dynamic_init_gain_thresh
   Cyclomatic Complexity 59 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_write_dig
   Cyclomatic Complexity 56 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_pause_dig
   Cyclomatic Complexity 13 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_dig_init
   Cyclomatic Complexity 197 drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_DIG
   Cyclomatic Complexity 22 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_dig_by_rssi_lps
   Cyclomatic Complexity 35 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_false_alarm_counter_statistics
   Cyclomatic Complexity 3 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_write_cck_cca_thres
   Cyclomatic Complexity 56 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_pause_cck_packet_detection
   Cyclomatic Complexity 31 
drivers/staging//rtlwifi/phydm/phydm_dig.c:odm_cck_packet_detection_thresh
   Cyclomatic Complexity 1 
drivers/staging//rtlwifi/phydm/phydm_dig.c:phydm_dig_go_up_check
   drivers/staging//rtlwifi/phydm/phydm_dig.c: In function 'odm_pause_dig':
>> drivers/staging//rtlwifi/phydm/phydm_dig.c:494:45: warning: array subscript 
>> is below array bounds [-Warray-bounds]
  odm_write_dig(dm, dig_tab->pause_dig_value[max_level]);
^
   drivers/staging//rtlwifi/phydm/phydm_dig.c: In function 
'odm_pause_cck_packet_detection':
   drivers/staging//rtlwifi/phydm/phydm_dig.c:1429:32: warning: array subscript 
is below array bounds [-Warray-bounds]
 dig_tab->pause_cckpd_value[max_level]);
   ^

vim +494 drivers/staging//rtlwifi/phydm/phydm_dig.c

9ce99b04 Ping-Ke Shih 2017-08-17  380  
9ce99b04 Ping-Ke Shih 2017-08-17  381  void odm_pause_dig(void *dm_void, enum 
phydm_pause_type pause_type,
9ce99b04 Ping-Ke Shih 2017-08-17  382  enum phydm_pause_level 
pause_level, u8 igi_value)
9ce99b04 Ping-Ke Shih 2017-08-17  383  {
9ce99b04 Ping-Ke Shih 2017-08-17  384   struct phy_dm_struct *dm = (struct 
phy_dm_struct *)dm_void;
9ce99b04 Ping-Ke Shih 2017-08-17  385   struct dig_thres *dig_tab = 
>dm_dig_table;
9ce99b04 Ping-Ke Shih 2017-08-17  386   s8 max_level;
9ce99b04 Ping-Ke Shih 2017-08-17  387  
9ce99b04 Ping-Ke Shih 2017-08-17  388   ODM_RT_TRACE(dm, ODM_COMP_DIG, 
"%s()=> level = %d\n", __func__,
9ce99b04 Ping-Ke Shih 2017-08-17  389pause_level);
9ce99b04 Ping-Ke Shih 2017-08-17  390  
9ce99b04 Ping-Ke Shih 2017-08-17  391   if ((dig_tab->pause_dig_level == 0) &&
9ce99b04 Ping-Ke Shih 2017-08-17  392   (!(dm->support_ability & 
ODM_BB_DIG) ||
9ce99b04 Ping-Ke Shih 2017-08-17  393!(dm->support_ability & 
ODM_BB_FA_CNT))) {
9ce99b04 Ping-Ke Shih 2017-08-17  394   ODM_RT_TRACE(
9ce99b04 Ping-Ke Shih 2017-08-17  395   dm, ODM_COMP_DIG,
9ce99b04 Ping-Ke Shih 2017-08-17  396   "%s(): Return: 
support_ability DIG or FA is disabled !!\n",
9ce99b04 Ping-Ke Shih 2017-08-17  397   __func__);
9ce99b04 Ping-Ke Shih 2017-08-17  398   return;
9ce99b04 Ping-Ke Shih 2017-08-17  399   }
9ce99b04 Ping-Ke Shih 2017-08-17  400  
9ce99b04 Ping-Ke Shih 2017-08-17  401   if (pause_level > 
DM_DIG_MAX_PAUSE_TYPE) {
9ce99b04 Ping-Ke Shih 2017-08-17  402   ODM_RT_TRACE(dm, ODM_COMP_DIG,
9ce99b04 Ping-Ke Shih 2017-08-17  403"%s(): Return: 
Wrong pause level !!\n", __func__);
9ce99b04 Ping-Ke Shih 2017-08-17  404   return;
9ce99b04 Ping-Ke Shih 2017-08-17  405   }
9ce99b04 Ping-Ke Shih 2017-08-17  406  
9ce99b04 Ping-Ke Shih 2017-08-17  407   

Re: [PATCH 0/3] fix reuseaddr regression

[David Miller]

From: Josef Bacik 
Date: Fri, 22 Sep 2017 20:20:05 -0400

> I introduced a regression when reworking the fastreuse port stuff that allows
> bind conflicts to occur once a reuseaddr successfully opens on an existing tb.
> The root cause is I reversed an if statement which caused us to set the tb as 
> if
> there were no owners on the socket if there were, which obviously is not
> correct.
> 
> Dave could you please queue these changes up for -stable, I've run them 
> through
> the net tests and added another test to check for this problem specifically.

Series applied and queued up for -stable, thanks.

Re: [PATCH 0/3] fix reuseaddr regression

[David Miller]

From: Josef Bacik 
Date: Fri, 22 Sep 2017 20:20:05 -0400

> I introduced a regression when reworking the fastreuse port stuff that allows
> bind conflicts to occur once a reuseaddr successfully opens on an existing tb.
> The root cause is I reversed an if statement which caused us to set the tb as 
> if
> there were no owners on the socket if there were, which obviously is not
> correct.
> 
> Dave could you please queue these changes up for -stable, I've run them 
> through
> the net tests and added another test to check for this problem specifically.

Series applied and queued up for -stable, thanks.

Re: [PATCH v2 11/12] arm64: allwinner: a64: Fix node with unit name and no reg property

[Chen-Yu Tsai]

On Sat, Sep 23, 2017 at 2:40 AM, Corentin Labbe
 wrote:
> This patch fix the warning "xxx has a unit name, but no reg property" by
> removing "@0" from such node
>
> Signed-off-by: Corentin Labbe 
> Acked-by: Maxime Ripard 
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 662e8b7981b5..b02a8476b0c8 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -347,7 +347,7 @@
> function = "spi1";
> };
>
> -   uart0_pins_a: uart0@0 {
> +   uart0_pins_a: uart0 {

Same here. This should be uart0_pb_pins.

> pins = "PB8", "PB9";
> function = "uart0";
> };
> @@ -571,7 +571,7 @@
> interrupt-controller;
> #interrupt-cells = <3>;
>
> -   r_rsb_pins: rsb@0 {
> +   r_rsb_pins: rsb {

And this rsb_pins.

ChenYu

> pins = "PL0", "PL1";
> function = "s_rsb";
> };
> --
> 2.13.5
>

Re: [PATCH v2 11/12] arm64: allwinner: a64: Fix node with unit name and no reg property

[Chen-Yu Tsai]

On Sat, Sep 23, 2017 at 2:40 AM, Corentin Labbe
 wrote:
> This patch fix the warning "xxx has a unit name, but no reg property" by
> removing "@0" from such node
>
> Signed-off-by: Corentin Labbe 
> Acked-by: Maxime Ripard 
> ---
>  arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
> b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> index 662e8b7981b5..b02a8476b0c8 100644
> --- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> +++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
> @@ -347,7 +347,7 @@
> function = "spi1";
> };
>
> -   uart0_pins_a: uart0@0 {
> +   uart0_pins_a: uart0 {

Same here. This should be uart0_pb_pins.

> pins = "PB8", "PB9";
> function = "uart0";
> };
> @@ -571,7 +571,7 @@
> interrupt-controller;
> #interrupt-cells = <3>;
>
> -   r_rsb_pins: rsb@0 {
> +   r_rsb_pins: rsb {

And this rsb_pins.

ChenYu

> pins = "PL0", "PL1";
> function = "s_rsb";
> };
> --
> 2.13.5
>

Re: [PATCH 1/5] Squashfs: remove the FILE_CACHE option

[Phillip Lougher]

On Fri, Sep 22, 2017 at 10:55 PM, Daniel Rosenberg  wrote:
> From: Adrien Schildknecht 
>
> FILE_DIRECT is working fine and offers faster results and lower memory
> footprint.
>
> Removing FILE_CACHE makes our life easier because we don't have to
> maintain 2 differents function that does the same thing.

When I added FILE_DIRECT, I deliberately retained the original
FILE_CACHE behaviour and kept it as default, and I spent a lot of
effort  to do so.  It basically required complete rewriting to enable
FILE_CACHE and FILE_DIRECT to co-exist.  FILE_CACHE wasn't simply some
old cruft I left in there because I couldn't be bothered to remove it.

There is a good reason for keeping the FILE_CACHE behaviour.  While
FILE_DIRECT improves the performance of Squashfs by eliminating a
memcpy, and removing contention on a lock, it also increases the
amount of I/O and CPU Squashfs can use at any one time (by enabling
multiple Squashfs operations to run in parallel).   This changes
scheduling and can take resources away from other tasks.

Who knows how many low-end embedded systems are out there that rely on
the original slower behaviour of FILE_CACHE and will break if it is
removed.

I didn't want to remove the FILE_CACHE behaviour and get a lot of
people complaining (and quite rightly too) that I'd removed a feature
they were relying on, and I don't intend to now either.  You quite
simply don't remove a feature that people may be relying on.

Let's be clear.  Your reason for removing FILE_CACHE is simply because
when adding your new whizzo feature, you needed to update both the
FILE_CACHE and FILE_DIRECT code, and as *you* didn't use FILE_CACHE,
you couldn't be bothered to update it, and removed it instead.  This
is not a valid reason for removing it.

NACK

Phillip

>
> Signed-off-by: Adrien Schildknecht 
> Signed-off-by: Daniel Rosenberg 
> ---
>  fs/squashfs/Kconfig  | 28 
>  fs/squashfs/Makefile |  3 +--
>  fs/squashfs/file_cache.c | 38 --
>  fs/squashfs/page_actor.h | 42 +-
>  4 files changed, 2 insertions(+), 109 deletions(-)
>  delete mode 100644 fs/squashfs/file_cache.c
>
> diff --git a/fs/squashfs/Kconfig b/fs/squashfs/Kconfig
> index 1adb3346b9d6..6c81bf620067 100644
> --- a/fs/squashfs/Kconfig
> +++ b/fs/squashfs/Kconfig
> @@ -25,34 +25,6 @@ config SQUASHFS
>
>   If unsure, say N.
>
> -choice
> -   prompt "File decompression options"
> -   depends on SQUASHFS
> -   help
> - Squashfs now supports two options for decompressing file
> - data.  Traditionally Squashfs has decompressed into an
> - intermediate buffer and then memcopied it into the page cache.
> - Squashfs now supports the ability to decompress directly into
> - the page cache.
> -
> - If unsure, select "Decompress file data into an intermediate buffer"
> -
> -config SQUASHFS_FILE_CACHE
> -   bool "Decompress file data into an intermediate buffer"
> -   help
> - Decompress file data into an intermediate buffer and then
> - memcopy it into the page cache.
> -
> -config SQUASHFS_FILE_DIRECT
> -   bool "Decompress files directly into the page cache"
> -   help
> - Directly decompress file data into the page cache.
> - Doing so can significantly improve performance because
> - it eliminates a memcpy and it also removes the lock contention
> - on the single buffer.
> -
> -endchoice
> -
>  choice
> prompt "Decompressor parallelisation options"
> depends on SQUASHFS
> diff --git a/fs/squashfs/Makefile b/fs/squashfs/Makefile
> index 6655631c53ae..225330ab7723 100644
> --- a/fs/squashfs/Makefile
> +++ b/fs/squashfs/Makefile
> @@ -5,8 +5,7 @@
>  obj-$(CONFIG_SQUASHFS) += squashfs.o
>  squashfs-y += block.o cache.o dir.o export.o file.o fragment.o id.o inode.o
>  squashfs-y += namei.o super.o symlink.o decompressor.o
> -squashfs-$(CONFIG_SQUASHFS_FILE_CACHE) += file_cache.o
> -squashfs-$(CONFIG_SQUASHFS_FILE_DIRECT) += file_direct.o page_actor.o
> +squashfs-y += file_direct.o page_actor.o
>  squashfs-$(CONFIG_SQUASHFS_DECOMP_SINGLE) += decompressor_single.o
>  squashfs-$(CONFIG_SQUASHFS_DECOMP_MULTI) += decompressor_multi.o
>  squashfs-$(CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU) += 
> decompressor_multi_percpu.o
> diff --git a/fs/squashfs/file_cache.c b/fs/squashfs/file_cache.c
> deleted file mode 100644
> index f2310d2a2019..
> --- a/fs/squashfs/file_cache.c
> +++ /dev/null
> @@ -1,38 +0,0 @@
> -/*
> - * Copyright (c) 2013
> - * Phillip Lougher 
> - *
> - * This work is licensed under the terms of the GNU GPL, version 2. See
> - * the COPYING file in the top-level directory.
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#include 

Re: [PATCH 1/5] Squashfs: remove the FILE_CACHE option

[Phillip Lougher]

On Fri, Sep 22, 2017 at 10:55 PM, Daniel Rosenberg  wrote:
> From: Adrien Schildknecht 
>
> FILE_DIRECT is working fine and offers faster results and lower memory
> footprint.
>
> Removing FILE_CACHE makes our life easier because we don't have to
> maintain 2 differents function that does the same thing.

When I added FILE_DIRECT, I deliberately retained the original
FILE_CACHE behaviour and kept it as default, and I spent a lot of
effort  to do so.  It basically required complete rewriting to enable
FILE_CACHE and FILE_DIRECT to co-exist.  FILE_CACHE wasn't simply some
old cruft I left in there because I couldn't be bothered to remove it.

There is a good reason for keeping the FILE_CACHE behaviour.  While
FILE_DIRECT improves the performance of Squashfs by eliminating a
memcpy, and removing contention on a lock, it also increases the
amount of I/O and CPU Squashfs can use at any one time (by enabling
multiple Squashfs operations to run in parallel).   This changes
scheduling and can take resources away from other tasks.

Who knows how many low-end embedded systems are out there that rely on
the original slower behaviour of FILE_CACHE and will break if it is
removed.

I didn't want to remove the FILE_CACHE behaviour and get a lot of
people complaining (and quite rightly too) that I'd removed a feature
they were relying on, and I don't intend to now either.  You quite
simply don't remove a feature that people may be relying on.

Let's be clear.  Your reason for removing FILE_CACHE is simply because
when adding your new whizzo feature, you needed to update both the
FILE_CACHE and FILE_DIRECT code, and as *you* didn't use FILE_CACHE,
you couldn't be bothered to update it, and removed it instead.  This
is not a valid reason for removing it.

NACK

Phillip

>
> Signed-off-by: Adrien Schildknecht 
> Signed-off-by: Daniel Rosenberg 
> ---
>  fs/squashfs/Kconfig  | 28 
>  fs/squashfs/Makefile |  3 +--
>  fs/squashfs/file_cache.c | 38 --
>  fs/squashfs/page_actor.h | 42 +-
>  4 files changed, 2 insertions(+), 109 deletions(-)
>  delete mode 100644 fs/squashfs/file_cache.c
>
> diff --git a/fs/squashfs/Kconfig b/fs/squashfs/Kconfig
> index 1adb3346b9d6..6c81bf620067 100644
> --- a/fs/squashfs/Kconfig
> +++ b/fs/squashfs/Kconfig
> @@ -25,34 +25,6 @@ config SQUASHFS
>
>   If unsure, say N.
>
> -choice
> -   prompt "File decompression options"
> -   depends on SQUASHFS
> -   help
> - Squashfs now supports two options for decompressing file
> - data.  Traditionally Squashfs has decompressed into an
> - intermediate buffer and then memcopied it into the page cache.
> - Squashfs now supports the ability to decompress directly into
> - the page cache.
> -
> - If unsure, select "Decompress file data into an intermediate buffer"
> -
> -config SQUASHFS_FILE_CACHE
> -   bool "Decompress file data into an intermediate buffer"
> -   help
> - Decompress file data into an intermediate buffer and then
> - memcopy it into the page cache.
> -
> -config SQUASHFS_FILE_DIRECT
> -   bool "Decompress files directly into the page cache"
> -   help
> - Directly decompress file data into the page cache.
> - Doing so can significantly improve performance because
> - it eliminates a memcpy and it also removes the lock contention
> - on the single buffer.
> -
> -endchoice
> -
>  choice
> prompt "Decompressor parallelisation options"
> depends on SQUASHFS
> diff --git a/fs/squashfs/Makefile b/fs/squashfs/Makefile
> index 6655631c53ae..225330ab7723 100644
> --- a/fs/squashfs/Makefile
> +++ b/fs/squashfs/Makefile
> @@ -5,8 +5,7 @@
>  obj-$(CONFIG_SQUASHFS) += squashfs.o
>  squashfs-y += block.o cache.o dir.o export.o file.o fragment.o id.o inode.o
>  squashfs-y += namei.o super.o symlink.o decompressor.o
> -squashfs-$(CONFIG_SQUASHFS_FILE_CACHE) += file_cache.o
> -squashfs-$(CONFIG_SQUASHFS_FILE_DIRECT) += file_direct.o page_actor.o
> +squashfs-y += file_direct.o page_actor.o
>  squashfs-$(CONFIG_SQUASHFS_DECOMP_SINGLE) += decompressor_single.o
>  squashfs-$(CONFIG_SQUASHFS_DECOMP_MULTI) += decompressor_multi.o
>  squashfs-$(CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU) += 
> decompressor_multi_percpu.o
> diff --git a/fs/squashfs/file_cache.c b/fs/squashfs/file_cache.c
> deleted file mode 100644
> index f2310d2a2019..
> --- a/fs/squashfs/file_cache.c
> +++ /dev/null
> @@ -1,38 +0,0 @@
> -/*
> - * Copyright (c) 2013
> - * Phillip Lougher 
> - *
> - * This work is licensed under the terms of the GNU GPL, version 2. See
> - * the COPYING file in the top-level directory.
> - */
> -
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -#include 
> -
> -#include "squashfs_fs.h"
> -#include "squashfs_fs_sb.h"
> -#include "squashfs_fs_i.h"
> -#include "squashfs.h"
> -
> 

Re: [PATCH v2 03/22] fpga: bridge: remove OF dependency for fpga-bridge

[Alan Tull]

On Thu, Sep 21, 2017 at 9:15 PM, Wu Hao  wrote:
> On Thu, Sep 21, 2017 at 02:50:07PM -0500, Alan Tull wrote:
>> On Thu, Sep 21, 2017 at 2:11 PM, Moritz Fischer  wrote:
>>
>> Hi Moritz,
>>
>> > Hi,
>> >
>> > On Mon, Jun 26, 2017 at 09:51:59AM +0800, Wu Hao wrote:
>> >> This patch removes OF dependency of fpga-bridge, it allows drivers
>> >> to use fpga-bridge class without device tree support.
>> >>
>> >> Signed-off-by: Wu Hao 
>> >> ---
>> >>  drivers/fpga/Kconfig | 1 -
>> >>  1 file changed, 1 deletion(-)
>> >>
>> >> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
>> >> index ed600d5..c1d8f41 100644
>> >> --- a/drivers/fpga/Kconfig
>> >> +++ b/drivers/fpga/Kconfig
>> >> @@ -75,7 +75,6 @@ config FPGA_MGR_ZYNQ_FPGA
>> >>
>> >>  config FPGA_BRIDGE
>> >>   tristate "FPGA Bridge Framework"
>> >> - depends on OF
>> >
>> > Shouldn't that dependency be removed in the patch that removes the
>> > dependency, or was the dependency never there in the first place?
>>
>> It wasn't dependent on OF in the first place.
>
> Hi Alan / Moritz
>
> I see this change has been integrated into below patch from Alan.
>
> [PATCH v4 15/18] fpga: region: move device tree support to of-fpga-region.c
>
> so I think I can drop this patch in my next version patch set. : )

Hi Hao,

Yes, I went ahead and pulled it into my patchset so you can drop it.

Thanks for the patch!

Alan

>
> Thanks
> Hao
>
>>
>> Thanks,
>> Alan
>>
>> >
>> >>   help
>> >> Say Y here if you want to support bridges connected between host
>> >> processors and FPGAs or between FPGAs.
>> >> --
>> >> 1.8.3.1
>> >>
>> >
>> > Thanks,
>> >
>> > Moritz
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 03/22] fpga: bridge: remove OF dependency for fpga-bridge

[Alan Tull]

On Thu, Sep 21, 2017 at 9:15 PM, Wu Hao  wrote:
> On Thu, Sep 21, 2017 at 02:50:07PM -0500, Alan Tull wrote:
>> On Thu, Sep 21, 2017 at 2:11 PM, Moritz Fischer  wrote:
>>
>> Hi Moritz,
>>
>> > Hi,
>> >
>> > On Mon, Jun 26, 2017 at 09:51:59AM +0800, Wu Hao wrote:
>> >> This patch removes OF dependency of fpga-bridge, it allows drivers
>> >> to use fpga-bridge class without device tree support.
>> >>
>> >> Signed-off-by: Wu Hao 
>> >> ---
>> >>  drivers/fpga/Kconfig | 1 -
>> >>  1 file changed, 1 deletion(-)
>> >>
>> >> diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
>> >> index ed600d5..c1d8f41 100644
>> >> --- a/drivers/fpga/Kconfig
>> >> +++ b/drivers/fpga/Kconfig
>> >> @@ -75,7 +75,6 @@ config FPGA_MGR_ZYNQ_FPGA
>> >>
>> >>  config FPGA_BRIDGE
>> >>   tristate "FPGA Bridge Framework"
>> >> - depends on OF
>> >
>> > Shouldn't that dependency be removed in the patch that removes the
>> > dependency, or was the dependency never there in the first place?
>>
>> It wasn't dependent on OF in the first place.
>
> Hi Alan / Moritz
>
> I see this change has been integrated into below patch from Alan.
>
> [PATCH v4 15/18] fpga: region: move device tree support to of-fpga-region.c
>
> so I think I can drop this patch in my next version patch set. : )

Hi Hao,

Yes, I went ahead and pulled it into my patchset so you can drop it.

Thanks for the patch!

Alan

>
> Thanks
> Hao
>
>>
>> Thanks,
>> Alan
>>
>> >
>> >>   help
>> >> Say Y here if you want to support bridges connected between host
>> >> processors and FPGAs or between FPGAs.
>> >> --
>> >> 1.8.3.1
>> >>
>> >
>> > Thanks,
>> >
>> > Moritz
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-fpga" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 03/12] ARM: dts: sunxi: h3/h5: Fix node with unit name and no reg property

[Chen-Yu Tsai]

On Sat, Sep 23, 2017 at 2:40 AM, Corentin Labbe
 wrote:
> This patch fix the warning "xxx has a unit name, but no reg property" by
> removing "@0" from such node.
>
> Signed-off-by: Corentin Labbe 
> Acked-by: Maxime Ripard 
> ---
>  arch/arm/boot/dts/sunxi-h3-h5.dtsi | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi 
> b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> index 289f2cd06dfe..2e4bae988acd 100644
> --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> @@ -322,7 +322,7 @@
> function = "i2c2";
> };
>
> -   mmc0_pins_a: mmc0@0 {
> +   mmc0_pins_a: mmc0 {

All pinmux nodes should have the suffix "_pins" or "_pin".

In the case where there are multiple choices, the node name should convey
what or which pingroup the choice is. In this case the name should be
"mmc0_pf_pins".

> pins = "PF0", "PF1", "PF2", "PF3",
>"PF4", "PF5";
> function = "mmc0";
> @@ -330,13 +330,13 @@
> bias-pull-up;
> };
>
> -   mmc0_cd_pin: mmc0_cd_pin@0 {
> +   mmc0_cd_pin: mmc0_cd_pin {
> pins = "PF6";
> function = "gpio_in";
> bias-pull-up;
> };
>
> -   mmc1_pins_a: mmc1@0 {
> +   mmc1_pins_a: mmc1 {

mmc1_pins

> pins = "PG0", "PG1", "PG2", "PG3",
>"PG4", "PG5";
> function = "mmc1";
> @@ -354,7 +354,7 @@
> bias-pull-up;
> };
>
> -   spdif_tx_pins_a: spdif@0 {
> +   spdif_tx_pins_a: spdif {

spdif_pin

> pins = "PA17";
> function = "spdif";
> };
> @@ -369,7 +369,7 @@
> function = "spi1";
> };
>
> -   uart0_pins_a: uart0@0 {
> +   uart0_pins_a: uart0 {

uart0_pb_pins

> pins = "PA4", "PA5";
> function = "uart0";
> };
> @@ -697,7 +697,7 @@
> interrupt-controller;
> #interrupt-cells = <3>;
>
> -   ir_pins_a: ir@0 {
> +   ir_pins_a: ir {

ir_pin

ChenYu

> pins = "PL11";
> function = "s_cir_rx";
> };
> --
> 2.13.5
>

Re: [PATCH v2 03/12] ARM: dts: sunxi: h3/h5: Fix node with unit name and no reg property

[Chen-Yu Tsai]

On Sat, Sep 23, 2017 at 2:40 AM, Corentin Labbe
 wrote:
> This patch fix the warning "xxx has a unit name, but no reg property" by
> removing "@0" from such node.
>
> Signed-off-by: Corentin Labbe 
> Acked-by: Maxime Ripard 
> ---
>  arch/arm/boot/dts/sunxi-h3-h5.dtsi | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sunxi-h3-h5.dtsi 
> b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> index 289f2cd06dfe..2e4bae988acd 100644
> --- a/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> +++ b/arch/arm/boot/dts/sunxi-h3-h5.dtsi
> @@ -322,7 +322,7 @@
> function = "i2c2";
> };
>
> -   mmc0_pins_a: mmc0@0 {
> +   mmc0_pins_a: mmc0 {

All pinmux nodes should have the suffix "_pins" or "_pin".

In the case where there are multiple choices, the node name should convey
what or which pingroup the choice is. In this case the name should be
"mmc0_pf_pins".

> pins = "PF0", "PF1", "PF2", "PF3",
>"PF4", "PF5";
> function = "mmc0";
> @@ -330,13 +330,13 @@
> bias-pull-up;
> };
>
> -   mmc0_cd_pin: mmc0_cd_pin@0 {
> +   mmc0_cd_pin: mmc0_cd_pin {
> pins = "PF6";
> function = "gpio_in";
> bias-pull-up;
> };
>
> -   mmc1_pins_a: mmc1@0 {
> +   mmc1_pins_a: mmc1 {

mmc1_pins

> pins = "PG0", "PG1", "PG2", "PG3",
>"PG4", "PG5";
> function = "mmc1";
> @@ -354,7 +354,7 @@
> bias-pull-up;
> };
>
> -   spdif_tx_pins_a: spdif@0 {
> +   spdif_tx_pins_a: spdif {

spdif_pin

> pins = "PA17";
> function = "spdif";
> };
> @@ -369,7 +369,7 @@
> function = "spi1";
> };
>
> -   uart0_pins_a: uart0@0 {
> +   uart0_pins_a: uart0 {

uart0_pb_pins

> pins = "PA4", "PA5";
> function = "uart0";
> };
> @@ -697,7 +697,7 @@
> interrupt-controller;
> #interrupt-cells = <3>;
>
> -   ir_pins_a: ir@0 {
> +   ir_pins_a: ir {

ir_pin

ChenYu

> pins = "PL11";
> function = "s_cir_rx";
> };
> --
> 2.13.5
>

[PATCH v2] spi: fix spi-sprd-adi build errors when HWSPINLOCK=m and SPI_SPRD_ADI=y

[Randy Dunlap]

From: Randy Dunlap 

Fix build errors when CONFIG_HWSPINLOCK=m and SPI_SPRD_ADI=y.
That combination is not allowed.

This allows building with HWSPINLOCK and SPI_SPRD_ADI in any
combinations except for HWSPINLOCK=m and SPI_SPRD_ADI=y.

drivers/spi/spi-sprd-adi.o: In function `sprd_adi_remove':
spi-sprd-adi.c:(.text+0x13): undefined reference to `hwspin_lock_free'
drivers/spi/spi-sprd-adi.o: In function `sprd_adi_probe':
spi-sprd-adi.c:(.text+0xf5): undefined reference to `of_hwspin_lock_get_id'
spi-sprd-adi.c:(.text+0x107): undefined reference to 
`hwspin_lock_request_specific'
spi-sprd-adi.c:(.text+0x22e): undefined reference to `hwspin_lock_free'
drivers/spi/spi-sprd-adi.o: In function `sprd_adi_transfer_one':
spi-sprd-adi.c:(.text+0x2eb): undefined reference to `__hwspin_lock_timeout'
spi-sprd-adi.c:(.text+0x349): undefined reference to `__hwspin_unlock'
spi-sprd-adi.c:(.text+0x389): undefined reference to `__hwspin_lock_timeout'
spi-sprd-adi.c:(.text+0x3ee): undefined reference to `__hwspin_unlock'

Signed-off-by: Randy Dunlap 
Cc: Baolin Wang 
Cc: Mark Brown 
Cc: linux-...@vger.kernel.org
---
 drivers/spi/Kconfig |1 +
 1 file changed, 1 insertion(+)

v2: allow build with or without HWSPINLOCK, but restrict SPI_SPRD_ADI
to =m if HWSPINLOCK=m.

--- linux-next-20170921.orig/drivers/spi/Kconfig
+++ linux-next-20170921/drivers/spi/Kconfig
@@ -625,6 +625,7 @@ config SPI_SIRF
 config SPI_SPRD_ADI
tristate "Spreadtrum ADI controller"
depends on ARCH_SPRD || COMPILE_TEST
+   depends on HWSPINLOCK || HWSPINLOCK=n
help
  ADI driver based on SPI for Spreadtrum SoCs.
 

[PATCH v2] spi: fix spi-sprd-adi build errors when HWSPINLOCK=m and SPI_SPRD_ADI=y

[Randy Dunlap]

From: Randy Dunlap 

Fix build errors when CONFIG_HWSPINLOCK=m and SPI_SPRD_ADI=y.
That combination is not allowed.

This allows building with HWSPINLOCK and SPI_SPRD_ADI in any
combinations except for HWSPINLOCK=m and SPI_SPRD_ADI=y.

drivers/spi/spi-sprd-adi.o: In function `sprd_adi_remove':
spi-sprd-adi.c:(.text+0x13): undefined reference to `hwspin_lock_free'
drivers/spi/spi-sprd-adi.o: In function `sprd_adi_probe':
spi-sprd-adi.c:(.text+0xf5): undefined reference to `of_hwspin_lock_get_id'
spi-sprd-adi.c:(.text+0x107): undefined reference to 
`hwspin_lock_request_specific'
spi-sprd-adi.c:(.text+0x22e): undefined reference to `hwspin_lock_free'
drivers/spi/spi-sprd-adi.o: In function `sprd_adi_transfer_one':
spi-sprd-adi.c:(.text+0x2eb): undefined reference to `__hwspin_lock_timeout'
spi-sprd-adi.c:(.text+0x349): undefined reference to `__hwspin_unlock'
spi-sprd-adi.c:(.text+0x389): undefined reference to `__hwspin_lock_timeout'
spi-sprd-adi.c:(.text+0x3ee): undefined reference to `__hwspin_unlock'

Signed-off-by: Randy Dunlap 
Cc: Baolin Wang 
Cc: Mark Brown 
Cc: linux-...@vger.kernel.org
---
 drivers/spi/Kconfig |1 +
 1 file changed, 1 insertion(+)

v2: allow build with or without HWSPINLOCK, but restrict SPI_SPRD_ADI
to =m if HWSPINLOCK=m.

--- linux-next-20170921.orig/drivers/spi/Kconfig
+++ linux-next-20170921/drivers/spi/Kconfig
@@ -625,6 +625,7 @@ config SPI_SIRF
 config SPI_SPRD_ADI
tristate "Spreadtrum ADI controller"
depends on ARCH_SPRD || COMPILE_TEST
+   depends on HWSPINLOCK || HWSPINLOCK=n
help
  ADI driver based on SPI for Spreadtrum SoCs.
 

Re: [PATCH v2 -next] spi: fix spi-sprd-adi build errors when SPI_SPRD_ADI=y and HWSPINLOCK=m

[Randy Dunlap]

On 09/22/17 02:26, Mark Brown wrote:
> On Thu, Sep 21, 2017 at 11:02:31AM -0700, Randy Dunlap wrote:
> 
>> spi-sprd-adi.c:(.text+0x3ee): undefined reference to `__hwspin_unlock'
>>
>> v2: allow build with or without HWSPINLOCK, but restrict to =m
>> if HWSPINLOCK=m.
>>
>> Signed-off-by: Randy Dunlap 
> 
> Please put inter version changelogs after the --- as covered in
> SubmittingPatches.  This still seems like the stubs aren't doing the

Yep.

> right thing - if we can use hwspinlocks in a module when they're enabled
> I'd expect to be able to build the stubs that way too.

Sorry, I'm not understanding what you are trying to say on that one.

The hwspinlock stubs are present if HWSPINLOCK is not enabled (when
 is #included).

The following kconfig combinations build:

HWSPINLOCK  SPI_SPRD_ADI
n   y
n   m
y   y
y   m
m   m
but this combo is not allowed (with the patch) or causes build errors
(without the patch):
m   y

-- 
~Randy

Re: [PATCH v2 -next] spi: fix spi-sprd-adi build errors when SPI_SPRD_ADI=y and HWSPINLOCK=m

[Randy Dunlap]

On 09/22/17 02:26, Mark Brown wrote:
> On Thu, Sep 21, 2017 at 11:02:31AM -0700, Randy Dunlap wrote:
> 
>> spi-sprd-adi.c:(.text+0x3ee): undefined reference to `__hwspin_unlock'
>>
>> v2: allow build with or without HWSPINLOCK, but restrict to =m
>> if HWSPINLOCK=m.
>>
>> Signed-off-by: Randy Dunlap 
> 
> Please put inter version changelogs after the --- as covered in
> SubmittingPatches.  This still seems like the stubs aren't doing the

Yep.

> right thing - if we can use hwspinlocks in a module when they're enabled
> I'd expect to be able to build the stubs that way too.

Sorry, I'm not understanding what you are trying to say on that one.

The hwspinlock stubs are present if HWSPINLOCK is not enabled (when
 is #included).

The following kconfig combinations build:

HWSPINLOCK  SPI_SPRD_ADI
n   y
n   m
y   y
y   m
m   m
but this combo is not allowed (with the patch) or causes build errors
(without the patch):
m   y

-- 
~Randy

Re: [PATCH] lib/lz4: make arrays static const, reduces object code size

[Joe Perches]

On Fri, 2017-09-22 at 23:39 +0200, Arnd Bergmann wrote:
> On Fri, Sep 22, 2017 at 9:17 PM, Arnd Bergmann  wrote:
> > On Fri, Sep 22, 2017 at 7:21 PM, Joe Perches  wrote:
> > > On Fri, 2017-09-22 at 09:48 +0200, Arnd Bergmann wrote:
> > > > On Fri, Sep 22, 2017 at 1:11 AM, Colin Ian King
> > > >textdata bss dec hex filename
> > > >   18220 176   0   1839647dc 
> > > > build/tmp/lib/lz4/lz4_decompress-after.o
> > > >   22297   0   0   222975719 
> > > > build/tmp/lib/lz4/lz4_decompress-before.o
> > > 
> > > Perhaps not so much a gcc bug as an opportunity
> > > for gcc to add an additional optimization.
> > > 
> > > gcc would have to verify that the const array is
> > > not initialized with some variable or argument like:
> > > 
> > > int foo(int a)
> > > {
> > > const int array[] = {1, a};
> > > ...
> > > }
> > 
> > It depends. With a 10KB different in .text size, my guess is that this
> > is a case where gcc does the right optimization in principle, but
> > fails to do what was intended in some corner cases.
> 
> I found the problem: "gcc -fsanitze=kernel-address --param asan-stack=1"
> produces lots of expensive checks here with gcc-5 or higher.
> 
> Disabling it makes a big difference:
> 
> upstream:
> gcc-7.0.0 --fsanitze=kernel-address --param asan-stack=1: 31789 bytes
> gcc-7.0.0: 16535 bytes
> 
> patched:
> gcc-7.0.0 --fsanitze=kernel-address --param asan-stack=1: 20351 bytes
> gcc-7.0.0: 14490 bytes

I think you are looking at a different issue.

There seems still a difference in size between
current and Colin's patch in compiled object size.



>   Arnd

Re: [PATCH] lib/lz4: make arrays static const, reduces object code size

[Joe Perches]

On Fri, 2017-09-22 at 21:17 +0200, Arnd Bergmann wrote:
> On Fri, Sep 22, 2017 at 7:21 PM, Joe Perches  wrote:
> > On Fri, 2017-09-22 at 09:48 +0200, Arnd Bergmann wrote:
> > > On Fri, Sep 22, 2017 at 1:11 AM, Colin Ian King
> > >textdata bss dec hex filename
> > >   18220 176   0   1839647dc 
> > > build/tmp/lib/lz4/lz4_decompress-after.o
> > >   22297   0   0   222975719 
> > > build/tmp/lib/lz4/lz4_decompress-before.o
> > 
> > Perhaps not so much a gcc bug as an opportunity
> > for gcc to add an additional optimization.
> > 
> > gcc would have to verify that the const array is
> > not initialized with some variable or argument like:
> > 
> > int foo(int a)
> > {
> > const int array[] = {1, a};
> > ...
> > }
> 
> It depends. With a 10KB different in .text size, my guess is that this
> is a case where gcc does the right optimization in principle, but
> fails to do what was intended in some corner cases.

Maybe/maybe not.  
> I just cross-checked by building with clang, there the patch has
> no impact on code size, it is 24929 bytes with or without the patch.
> 
> Looking at other versions of (x86) gcc, I see .text sizes of
> 
>  afterbefore
> gcc-3.4.6 10855 12977
> gcc-4.0.4 11088 11088
> gcc-4.1.3 10973 10973
> gcc-4.2.5 11183 11183
> gcc-4.3.6 15501 17724

Interesting this was apparently deoptimized at version 4.3.

Glancing at the release notes doesn't seem to indicate
anything obvious.

https://gcc.gnu.org/gcc-4.3/changes.html

> gcc-4.4.7 13337 15693
> gcc-4.5.4 13162 15491
> gcc-4.6.4 14846 17302
> gcc-4.7.4 14187 16294
> gcc-4.8.5 16591 18730
> gcc-4.9.4 19582 21995
> gcc-5.4.1 18294 22510
> gcc-6.1.1 20487 25172
> gcc-6.3.1 20487 25172
> gcc-7.0.0 20351 31789
> gcc-7.0.1 20351 24966
> gcc-7.1.1 20383 24982
> gcc-8.0.0 20686 25065
> 
> It seems whatever happened in early versions of gcc-7 has since
> improved, and it probably was a bug since older and newer versions
> create similar code size (I have not looked at the actual object code).
> 
> The 5K difference in gcc-5 and higher still seems like a lot. It would
> also be interesting to look at the decompression performance of
> this code witth the different compilers to see if it got better or worse.

yup

> Most likely, gcc got better at inlining and unrolling parts of the
> algorithm, but sometimes an object file that doubles or triples in
> size is an indication that the compiler did something really bad.

yup[2]

cheers, Joe

Re: [PATCH] lib/lz4: make arrays static const, reduces object code size

[Joe Perches]

On Fri, 2017-09-22 at 23:39 +0200, Arnd Bergmann wrote:
> On Fri, Sep 22, 2017 at 9:17 PM, Arnd Bergmann  wrote:
> > On Fri, Sep 22, 2017 at 7:21 PM, Joe Perches  wrote:
> > > On Fri, 2017-09-22 at 09:48 +0200, Arnd Bergmann wrote:
> > > > On Fri, Sep 22, 2017 at 1:11 AM, Colin Ian King
> > > >textdata bss dec hex filename
> > > >   18220 176   0   1839647dc 
> > > > build/tmp/lib/lz4/lz4_decompress-after.o
> > > >   22297   0   0   222975719 
> > > > build/tmp/lib/lz4/lz4_decompress-before.o
> > > 
> > > Perhaps not so much a gcc bug as an opportunity
> > > for gcc to add an additional optimization.
> > > 
> > > gcc would have to verify that the const array is
> > > not initialized with some variable or argument like:
> > > 
> > > int foo(int a)
> > > {
> > > const int array[] = {1, a};
> > > ...
> > > }
> > 
> > It depends. With a 10KB different in .text size, my guess is that this
> > is a case where gcc does the right optimization in principle, but
> > fails to do what was intended in some corner cases.
> 
> I found the problem: "gcc -fsanitze=kernel-address --param asan-stack=1"
> produces lots of expensive checks here with gcc-5 or higher.
> 
> Disabling it makes a big difference:
> 
> upstream:
> gcc-7.0.0 --fsanitze=kernel-address --param asan-stack=1: 31789 bytes
> gcc-7.0.0: 16535 bytes
> 
> patched:
> gcc-7.0.0 --fsanitze=kernel-address --param asan-stack=1: 20351 bytes
> gcc-7.0.0: 14490 bytes

I think you are looking at a different issue.

There seems still a difference in size between
current and Colin's patch in compiled object size.



>   Arnd

Re: [PATCH] lib/lz4: make arrays static const, reduces object code size

[Joe Perches]

On Fri, 2017-09-22 at 21:17 +0200, Arnd Bergmann wrote:
> On Fri, Sep 22, 2017 at 7:21 PM, Joe Perches  wrote:
> > On Fri, 2017-09-22 at 09:48 +0200, Arnd Bergmann wrote:
> > > On Fri, Sep 22, 2017 at 1:11 AM, Colin Ian King
> > >textdata bss dec hex filename
> > >   18220 176   0   1839647dc 
> > > build/tmp/lib/lz4/lz4_decompress-after.o
> > >   22297   0   0   222975719 
> > > build/tmp/lib/lz4/lz4_decompress-before.o
> > 
> > Perhaps not so much a gcc bug as an opportunity
> > for gcc to add an additional optimization.
> > 
> > gcc would have to verify that the const array is
> > not initialized with some variable or argument like:
> > 
> > int foo(int a)
> > {
> > const int array[] = {1, a};
> > ...
> > }
> 
> It depends. With a 10KB different in .text size, my guess is that this
> is a case where gcc does the right optimization in principle, but
> fails to do what was intended in some corner cases.

Maybe/maybe not.  
> I just cross-checked by building with clang, there the patch has
> no impact on code size, it is 24929 bytes with or without the patch.
> 
> Looking at other versions of (x86) gcc, I see .text sizes of
> 
>  afterbefore
> gcc-3.4.6 10855 12977
> gcc-4.0.4 11088 11088
> gcc-4.1.3 10973 10973
> gcc-4.2.5 11183 11183
> gcc-4.3.6 15501 17724

Interesting this was apparently deoptimized at version 4.3.

Glancing at the release notes doesn't seem to indicate
anything obvious.

https://gcc.gnu.org/gcc-4.3/changes.html

> gcc-4.4.7 13337 15693
> gcc-4.5.4 13162 15491
> gcc-4.6.4 14846 17302
> gcc-4.7.4 14187 16294
> gcc-4.8.5 16591 18730
> gcc-4.9.4 19582 21995
> gcc-5.4.1 18294 22510
> gcc-6.1.1 20487 25172
> gcc-6.3.1 20487 25172
> gcc-7.0.0 20351 31789
> gcc-7.0.1 20351 24966
> gcc-7.1.1 20383 24982
> gcc-8.0.0 20686 25065
> 
> It seems whatever happened in early versions of gcc-7 has since
> improved, and it probably was a bug since older and newer versions
> create similar code size (I have not looked at the actual object code).
> 
> The 5K difference in gcc-5 and higher still seems like a lot. It would
> also be interesting to look at the decompression performance of
> this code witth the different compilers to see if it got better or worse.

yup

> Most likely, gcc got better at inlining and unrolling parts of the
> algorithm, but sometimes an object file that doubles or triples in
> size is an indication that the compiler did something really bad.

yup[2]

cheers, Joe

Re: [PATCH 4/4] tracing: Remove RCU work arounds from stack tracer

[Steven Rostedt]

On Fri, 22 Sep 2017 15:54:55 -0700
"Paul E. McKenney"  wrote:

> On Fri, Sep 22, 2017 at 06:15:47PM -0400, Steven Rostedt wrote:
> > From: "Steven Rostedt (VMware)" 
> > 
> > While debugging some RCU issues with the stack tracer, it was discovered
> > that the problem was much more than with the stack tracer itself, but with
> > the saving of the stack trace, which could happen from any WARN() as well.
> > The problem was fixed within kernel_text_address().
> > 
> > One of the bugs that was discovered was that the stack tracer called
> > rcu_enter_irq() unconditionally. Paul McKenney said that could cause issues
> > as well. Instead of adding logic to only call rcu_enter_irq() if RCU is not
> > watching from within the stack tracer, since the core issue has been fixed
> > (within save_stack_trace()), we can simply remove all the logic in the stack
> > tracer that deals with RCU work arounds.  
> 
> I must confess that I am having some difficulty parsing this paragraph,
> especially the last sentence...
> 
> Does this capture it?
> 
>   One problem is that the stack tracer called rcu_irq_enter()
>   unconditionally, which is problematic if RCU's last
>   not-watching-to-watching transition was carried out by
>   rcu_nmi_enter.  In that case, rcu_irq_enter() actually switches

I thought the rcu_irq_enter() after rcu_nmi_enter() was a separate bug.
Your original complaint was that I called rcu_irq_enter()
unconditionally, and wanted me to only call it if RCU wasn't watching.

But, the new code could possibly have this get called after
rcu_nmi_enter() because we are calling it without in_nmi() being set.


>   RCU back to the not-watching state for this CPU, which results
>   in lockdep splats complaining about rcu_read_lock() being
>   used on an idle (not-watched) CPU.  The first patch of this
>   series addressed this problem by having rcu_irq_enter() and
>   rcu_irq_exit() refrain from doing anything when rcu_nmi_enter()
>   caused RCU to start watching this CPU.  The third patch in this
>   series caused save_stack_trace() to invoke rcu_nmi_enter() and
>   rcu_nmi_exit() as needed, so this fourth patch now removes the
>   rcu_irq_enter() and rcu_irq_exit() from within the stack tracer.
> 
> One further question...  Can I now remove the rcu_irq_enter_disabled()
> logic?

After this goes in. Yes. But that doesn't need to be a stable change.

> 
> > Cc: "Paul E. McKenney" 
> > Cc: sta...@vger.kernel.org
> > Fixes: 0be964be0 ("module: Sanitize RCU usage and locking")
> > Suggested-by: "Paul E. McKenney" 
> > Signed-off-by: Steven Rostedt (VMware)   
> 
> With the hard-to-parse paragraph fixed:
> 
> Acked-by: Paul E. McKenney 

Thanks, but we may need to go back and forth a bit to get the change
log correct.

Remember the first bug. The one that was fixed by changing
rcu_irq_enter() to rcu_nmi_enter()?

=
 WARNING: suspicious RCU usage
 4.13.0-rc7-test+ #117 Tainted: GW  
 -
 /work/git/linux-trace.git/arch/x86/kernel/traps.c:305 entry code didn't wake 
RCU!
 
 other info that might help us debug this:

 
 RCU used illegally from idle CPU!
 rcu_scheduler_active = 2, debug_locks = 1
 RCU used illegally from extended quiescent state!
 no locks held by swapper/1/0.
 
 stack backtrace:
 CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW   4.13.0-rc7-test+ #117
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 
07/14/2016
 Call Trace:
  dump_stack+0x86/0xcf
  lockdep_rcu_suspicious+0xc5/0x100
  do_error_trap+0x125/0x130
  ? do_error_trap+0x5/0x130
  ? trace_hardirqs_off_thunk+0x1a/0x1c
  ? do_invalid_op+0x5/0x30
  do_invalid_op+0x20/0x30
  invalid_op+0x1e/0x30
 RIP: 0010:module_assert_mutex_or_preempt+0x34/0x40
 RSP: 0018:c96abc58 EFLAGS: 00010046
 RAX:  RBX: a000a077 RCX: 0002
 RDX:  RSI:  RDI: 0046
 RBP: c96abc58 R08: c96abf40 R09: 
 R10:  R11:  R12: 
 R13:  R14: 8801188d8040 R15: 81ed5720
  ? 0xa000a077
  ? module_assert_mutex_or_preempt+0x30/0x40
  __module_address+0x2c/0xf0
  ? 0xa000a077
  __module_text_address+0x12/0x60
  ? 0xa000a077
  is_module_text_address+0x1f/0x50
  ? 0xa000a077
  __kernel_text_address+0x30/0x90
  unwind_get_return_address+0x1f/0x30
  __save_stack_trace+0x83/0xd0
  ? 0xa000a077
  ? rcu_dynticks_eqs_exit+0x5/0x40
  save_stack_trace+0x1b/0x20
  check_stack+0xf8/0x2f0
  ? rcu_dynticks_eqs_enter+0x30/0x30
  stack_trace_call+0x6e/0x80
  0xa000a077
  ? ftrace_graph_caller+0x78/0xa8
  ? rcu_dynticks_eqs_exit+0x5/0x40
  rcu_dynticks_eqs_exit+0x5/0x40
  

Re: [PATCH 4/4] tracing: Remove RCU work arounds from stack tracer

[Steven Rostedt]

On Fri, 22 Sep 2017 15:54:55 -0700
"Paul E. McKenney"  wrote:

> On Fri, Sep 22, 2017 at 06:15:47PM -0400, Steven Rostedt wrote:
> > From: "Steven Rostedt (VMware)" 
> > 
> > While debugging some RCU issues with the stack tracer, it was discovered
> > that the problem was much more than with the stack tracer itself, but with
> > the saving of the stack trace, which could happen from any WARN() as well.
> > The problem was fixed within kernel_text_address().
> > 
> > One of the bugs that was discovered was that the stack tracer called
> > rcu_enter_irq() unconditionally. Paul McKenney said that could cause issues
> > as well. Instead of adding logic to only call rcu_enter_irq() if RCU is not
> > watching from within the stack tracer, since the core issue has been fixed
> > (within save_stack_trace()), we can simply remove all the logic in the stack
> > tracer that deals with RCU work arounds.  
> 
> I must confess that I am having some difficulty parsing this paragraph,
> especially the last sentence...
> 
> Does this capture it?
> 
>   One problem is that the stack tracer called rcu_irq_enter()
>   unconditionally, which is problematic if RCU's last
>   not-watching-to-watching transition was carried out by
>   rcu_nmi_enter.  In that case, rcu_irq_enter() actually switches

I thought the rcu_irq_enter() after rcu_nmi_enter() was a separate bug.
Your original complaint was that I called rcu_irq_enter()
unconditionally, and wanted me to only call it if RCU wasn't watching.

But, the new code could possibly have this get called after
rcu_nmi_enter() because we are calling it without in_nmi() being set.


>   RCU back to the not-watching state for this CPU, which results
>   in lockdep splats complaining about rcu_read_lock() being
>   used on an idle (not-watched) CPU.  The first patch of this
>   series addressed this problem by having rcu_irq_enter() and
>   rcu_irq_exit() refrain from doing anything when rcu_nmi_enter()
>   caused RCU to start watching this CPU.  The third patch in this
>   series caused save_stack_trace() to invoke rcu_nmi_enter() and
>   rcu_nmi_exit() as needed, so this fourth patch now removes the
>   rcu_irq_enter() and rcu_irq_exit() from within the stack tracer.
> 
> One further question...  Can I now remove the rcu_irq_enter_disabled()
> logic?

After this goes in. Yes. But that doesn't need to be a stable change.

> 
> > Cc: "Paul E. McKenney" 
> > Cc: sta...@vger.kernel.org
> > Fixes: 0be964be0 ("module: Sanitize RCU usage and locking")
> > Suggested-by: "Paul E. McKenney" 
> > Signed-off-by: Steven Rostedt (VMware)   
> 
> With the hard-to-parse paragraph fixed:
> 
> Acked-by: Paul E. McKenney 

Thanks, but we may need to go back and forth a bit to get the change
log correct.

Remember the first bug. The one that was fixed by changing
rcu_irq_enter() to rcu_nmi_enter()?

=
 WARNING: suspicious RCU usage
 4.13.0-rc7-test+ #117 Tainted: GW  
 -
 /work/git/linux-trace.git/arch/x86/kernel/traps.c:305 entry code didn't wake 
RCU!
 
 other info that might help us debug this:

 
 RCU used illegally from idle CPU!
 rcu_scheduler_active = 2, debug_locks = 1
 RCU used illegally from extended quiescent state!
 no locks held by swapper/1/0.
 
 stack backtrace:
 CPU: 1 PID: 0 Comm: swapper/1 Tainted: GW   4.13.0-rc7-test+ #117
 Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 
07/14/2016
 Call Trace:
  dump_stack+0x86/0xcf
  lockdep_rcu_suspicious+0xc5/0x100
  do_error_trap+0x125/0x130
  ? do_error_trap+0x5/0x130
  ? trace_hardirqs_off_thunk+0x1a/0x1c
  ? do_invalid_op+0x5/0x30
  do_invalid_op+0x20/0x30
  invalid_op+0x1e/0x30
 RIP: 0010:module_assert_mutex_or_preempt+0x34/0x40
 RSP: 0018:c96abc58 EFLAGS: 00010046
 RAX:  RBX: a000a077 RCX: 0002
 RDX:  RSI:  RDI: 0046
 RBP: c96abc58 R08: c96abf40 R09: 
 R10:  R11:  R12: 
 R13:  R14: 8801188d8040 R15: 81ed5720
  ? 0xa000a077
  ? module_assert_mutex_or_preempt+0x30/0x40
  __module_address+0x2c/0xf0
  ? 0xa000a077
  __module_text_address+0x12/0x60
  ? 0xa000a077
  is_module_text_address+0x1f/0x50
  ? 0xa000a077
  __kernel_text_address+0x30/0x90
  unwind_get_return_address+0x1f/0x30
  __save_stack_trace+0x83/0xd0
  ? 0xa000a077
  ? rcu_dynticks_eqs_exit+0x5/0x40
  save_stack_trace+0x1b/0x20
  check_stack+0xf8/0x2f0
  ? rcu_dynticks_eqs_enter+0x30/0x30
  stack_trace_call+0x6e/0x80
  0xa000a077
  ? ftrace_graph_caller+0x78/0xa8
  ? rcu_dynticks_eqs_exit+0x5/0x40
  rcu_dynticks_eqs_exit+0x5/0x40
  rcu_idle_exit+0xdf/0xf0
  ? rcu_dynticks_eqs_exit+0x5/0x40
  ? rcu_idle_exit+0xdf/0xf0
  do_idle+0x128/0x200
  cpu_startup_entry+0x1d/0x20
  

Re: [PATCH] net: stmmac: Meet alignment requirements for DMA

[David Miller]

From: Matt Redfearn 
Date: Fri, 22 Sep 2017 12:13:53 +0100

> According to Documentation/DMA-API.txt:
>  Warnings:  Memory coherency operates at a granularity called the cache
>  line width.  In order for memory mapped by this API to operate
>  correctly, the mapped region must begin exactly on a cache line
>  boundary and end exactly on one (to prevent two separately mapped
>  regions from sharing a single cache line).  Since the cache line size
>  may not be known at compile time, the API will not enforce this
>  requirement.  Therefore, it is recommended that driver writers who
>  don't take special care to determine the cache line size at run time
>  only map virtual regions that begin and end on page boundaries (which
>  are guaranteed also to be cache line boundaries).

This is rediculious.  You're misreading what this document is trying
to explain.

As long as you use the dma_{map,unamp}_single() and sync to/from
deivce interfaces properly, the cacheline issues will be handled properly
and the cpu and the device will see proper uptodate memory contents.

It is completely rediculious to require every driver to stash away two
sets of pointer for every packet, and to DMA map the headroom of the SKB
which is wasteful.

I'm not applying this, fix this problem properly, thanks.

Re: [PATCH] net: stmmac: Meet alignment requirements for DMA

[David Miller]

From: Matt Redfearn 
Date: Fri, 22 Sep 2017 12:13:53 +0100

> According to Documentation/DMA-API.txt:
>  Warnings:  Memory coherency operates at a granularity called the cache
>  line width.  In order for memory mapped by this API to operate
>  correctly, the mapped region must begin exactly on a cache line
>  boundary and end exactly on one (to prevent two separately mapped
>  regions from sharing a single cache line).  Since the cache line size
>  may not be known at compile time, the API will not enforce this
>  requirement.  Therefore, it is recommended that driver writers who
>  don't take special care to determine the cache line size at run time
>  only map virtual regions that begin and end on page boundaries (which
>  are guaranteed also to be cache line boundaries).

This is rediculious.  You're misreading what this document is trying
to explain.

As long as you use the dma_{map,unamp}_single() and sync to/from
deivce interfaces properly, the cacheline issues will be handled properly
and the cpu and the device will see proper uptodate memory contents.

It is completely rediculious to require every driver to stash away two
sets of pointer for every packet, and to DMA map the headroom of the SKB
which is wasteful.

I'm not applying this, fix this problem properly, thanks.

Re: [PATCH net-next] virtio-net: correctly set xdp_xmit for mergeable buffer

[David Miller]

From: Jason Wang 
Date: Fri, 22 Sep 2017 14:38:58 +0800

> We should set xdp_xmit only when xdp_do_redirect() succeed.
> 
> Cc: John Fastabend 
> Signed-off-by: Jason Wang 

Applied, thanks Jason.

Re: [PATCH net-next] virtio-net: correctly set xdp_xmit for mergeable buffer

[David Miller]

From: Jason Wang 
Date: Fri, 22 Sep 2017 14:38:58 +0800

> We should set xdp_xmit only when xdp_do_redirect() succeed.
> 
> Cc: John Fastabend 
> Signed-off-by: Jason Wang 

Applied, thanks Jason.

[PATCH 3/4 v2] extable: Enable RCU if it is not watching in kernel_text_address()

[Steven Rostedt]

>From 32b9a1b584549478af9e55e2008d50c58a98535f Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (VMware)" 
Date: Fri, 22 Sep 2017 17:36:32 -0400
Subject: [PATCH] extable: Enable RCU if it is not watching in
 kernel_text_address()

If kernel_text_address() is called when RCU is not watching, it can cause an
RCU bug because is_module_text_address(), the is_kprobe_*insn_slot()
and is_bpf_text_address() functions require the use of RCU.

Only enable RCU if it is not currently watching before it calls
is_module_text_address(). The use of rcu_nmi_enter() is used to enable RCU
because kernel_text_address() can happen pretty much anywhere (like an NMI),
and even from within an NMI. It is called via save_stack_trace() that can be
called by any WARN() or tracing function, which can happen while RCU is not
watching (for example, going to or coming from idle, or during CPU take down
or bring up).

Cc: sta...@vger.kernel.org
Fixes: 0be964be0 ("module: Sanitize RCU usage and locking")
Acked-by: Paul E. McKenney 
Signed-off-by: Steven Rostedt (VMware) 
---
 kernel/extable.c | 35 ++-
 1 file changed, 30 insertions(+), 5 deletions(-)

diff --git a/kernel/extable.c b/kernel/extable.c
index a7024a4..9aa1cc4 100644
--- a/kernel/extable.c
+++ b/kernel/extable.c
@@ -119,17 +119,42 @@ int __kernel_text_address(unsigned long addr)
 
 int kernel_text_address(unsigned long addr)
 {
+   bool no_rcu;
+   int ret = 1;
+
if (core_kernel_text(addr))
return 1;
+
+   /*
+* If a stack dump happens while RCU is not watching, then
+* RCU needs to be notified that it requires to start
+* watching again. This can happen either by tracing that
+* triggers a stack trace, or a WARN() that happens during
+* coming back from idle, or cpu on or offlining.
+*
+* is_module_text_address() as well as the kprobe slots
+* and is_bpf_text_address() require RCU to be watching.
+*/
+   no_rcu = !rcu_is_watching();
+
+   /* Treat this like an NMI as it can happen anywhere */
+   if (no_rcu)
+   rcu_nmi_enter();
+
if (is_module_text_address(addr))
-   return 1;
+   goto out;
if (is_ftrace_trampoline(addr))
-   return 1;
+   goto out;
if (is_kprobe_optinsn_slot(addr) || is_kprobe_insn_slot(addr))
-   return 1;
+   goto out;
if (is_bpf_text_address(addr))
-   return 1;
-   return 0;
+   goto out;
+   ret = 0;
+out:
+   if (no_rcu)
+   rcu_nmi_exit();
+
+   return ret;
 }
 
 /*
-- 
2.9.5

[PATCH 3/4 v2] extable: Enable RCU if it is not watching in kernel_text_address()

[Steven Rostedt]

>From 32b9a1b584549478af9e55e2008d50c58a98535f Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (VMware)" 
Date: Fri, 22 Sep 2017 17:36:32 -0400
Subject: [PATCH] extable: Enable RCU if it is not watching in
 kernel_text_address()

If kernel_text_address() is called when RCU is not watching, it can cause an
RCU bug because is_module_text_address(), the is_kprobe_*insn_slot()
and is_bpf_text_address() functions require the use of RCU.

Only enable RCU if it is not currently watching before it calls
is_module_text_address(). The use of rcu_nmi_enter() is used to enable RCU
because kernel_text_address() can happen pretty much anywhere (like an NMI),
and even from within an NMI. It is called via save_stack_trace() that can be
called by any WARN() or tracing function, which can happen while RCU is not
watching (for example, going to or coming from idle, or during CPU take down
or bring up).

Cc: sta...@vger.kernel.org
Fixes: 0be964be0 ("module: Sanitize RCU usage and locking")
Acked-by: Paul E. McKenney 
Signed-off-by: Steven Rostedt (VMware) 
---
 kernel/extable.c | 35 ++-
 1 file changed, 30 insertions(+), 5 deletions(-)

diff --git a/kernel/extable.c b/kernel/extable.c
index a7024a4..9aa1cc4 100644
--- a/kernel/extable.c
+++ b/kernel/extable.c
@@ -119,17 +119,42 @@ int __kernel_text_address(unsigned long addr)
 
 int kernel_text_address(unsigned long addr)
 {
+   bool no_rcu;
+   int ret = 1;
+
if (core_kernel_text(addr))
return 1;
+
+   /*
+* If a stack dump happens while RCU is not watching, then
+* RCU needs to be notified that it requires to start
+* watching again. This can happen either by tracing that
+* triggers a stack trace, or a WARN() that happens during
+* coming back from idle, or cpu on or offlining.
+*
+* is_module_text_address() as well as the kprobe slots
+* and is_bpf_text_address() require RCU to be watching.
+*/
+   no_rcu = !rcu_is_watching();
+
+   /* Treat this like an NMI as it can happen anywhere */
+   if (no_rcu)
+   rcu_nmi_enter();
+
if (is_module_text_address(addr))
-   return 1;
+   goto out;
if (is_ftrace_trampoline(addr))
-   return 1;
+   goto out;
if (is_kprobe_optinsn_slot(addr) || is_kprobe_insn_slot(addr))
-   return 1;
+   goto out;
if (is_bpf_text_address(addr))
-   return 1;
-   return 0;
+   goto out;
+   ret = 0;
+out:
+   if (no_rcu)
+   rcu_nmi_exit();
+
+   return ret;
 }
 
 /*
-- 
2.9.5

Re: [PATCH 3/4] extable: Enable RCU if it is not watching in kernel_text_address()

[Steven Rostedt]

On Fri, 22 Sep 2017 15:44:06 -0700
"Paul E. McKenney"  wrote:

> On Fri, Sep 22, 2017 at 06:15:46PM -0400, Steven Rostedt wrote:
> > From: "Steven Rostedt (VMware)" 
> > 
> > If kernel_text_address() is called when RCU is not watching, it can cause an
> > RCU bug because is_module_text_address() and the is_kprobe_*insn_slot()
> > functions require the use of RCU.
> > 
> > Only enable RCU if it is not currently watching before it calls
> > is_module_text_address(). The use of rcu_nmi_enter() is used to enable RCU
> > because kernel_text_address() can happen pretty much anywhere (like an NMI),
> > and even from within an NMI. It is called via save_stack_trace() that can be
> > called by any WARN() or tracing function, which can happen while RCU is not
> > watching (for example, going to or coming from idle, or during CPU take down
> > or bring up).
> > 
> > Cc: Paul E. McKenney 
> > Cc: sta...@vger.kernel.org  
> 
> Do we need something calling out the dependency on the first two patches,
> or is that implied these days?

I believe the stable folks will simply apply patches marked for stable
in the order they are applied. This is a patch series, so I don't think
it will be an issue for them.

> 
> > Fixes: 0be964be0 ("module: Sanitize RCU usage and locking")
> > Signed-off-by: Steven Rostedt (VMware)   
> 
> Give or take Josh's feedback on the commit log and comment:

Yep.

> 
> Acked-by: Paul E. McKenney 

Thanks!

-- Steve

Re: [PATCH 3/4] extable: Enable RCU if it is not watching in kernel_text_address()

[Steven Rostedt]

On Fri, 22 Sep 2017 15:44:06 -0700
"Paul E. McKenney"  wrote:

> On Fri, Sep 22, 2017 at 06:15:46PM -0400, Steven Rostedt wrote:
> > From: "Steven Rostedt (VMware)" 
> > 
> > If kernel_text_address() is called when RCU is not watching, it can cause an
> > RCU bug because is_module_text_address() and the is_kprobe_*insn_slot()
> > functions require the use of RCU.
> > 
> > Only enable RCU if it is not currently watching before it calls
> > is_module_text_address(). The use of rcu_nmi_enter() is used to enable RCU
> > because kernel_text_address() can happen pretty much anywhere (like an NMI),
> > and even from within an NMI. It is called via save_stack_trace() that can be
> > called by any WARN() or tracing function, which can happen while RCU is not
> > watching (for example, going to or coming from idle, or during CPU take down
> > or bring up).
> > 
> > Cc: Paul E. McKenney 
> > Cc: sta...@vger.kernel.org  
> 
> Do we need something calling out the dependency on the first two patches,
> or is that implied these days?

I believe the stable folks will simply apply patches marked for stable
in the order they are applied. This is a patch series, so I don't think
it will be an issue for them.

> 
> > Fixes: 0be964be0 ("module: Sanitize RCU usage and locking")
> > Signed-off-by: Steven Rostedt (VMware)   
> 
> Give or take Josh's feedback on the commit log and comment:

Yep.

> 
> Acked-by: Paul E. McKenney 

Thanks!

-- Steve

[PATCH] nvme: use menu Kconfig interface

[Randy Dunlap]

From: Randy Dunlap 

Add a menu interface for NVME host and target support so that it is
presented to users more like other Kconfig symbols.
This makes the Device Driver menu less cluttered (easier to read)
and keeps all of these symbols grouped together.

Signed-off-by: Randy Dunlap 
Cc: Jay Sternberg 
Cc: Jens Axboe 
Cc: Keith Busch 
Cc: Christoph Hellwig 
Cc: Sagi Grimberg 
Cc: linux-n...@lists.infradead.org
---
 drivers/nvme/Kconfig |4 
 1 file changed, 4 insertions(+)

--- lnx-414-rc1.orig/drivers/nvme/Kconfig
+++ lnx-414-rc1/drivers/nvme/Kconfig
@@ -1,2 +1,6 @@
+menu "NVME Support"
+
 source "drivers/nvme/host/Kconfig"
 source "drivers/nvme/target/Kconfig"
+
+endmenu

[PATCH] nvme: use menu Kconfig interface

[Randy Dunlap]

From: Randy Dunlap 

Add a menu interface for NVME host and target support so that it is
presented to users more like other Kconfig symbols.
This makes the Device Driver menu less cluttered (easier to read)
and keeps all of these symbols grouped together.

Signed-off-by: Randy Dunlap 
Cc: Jay Sternberg 
Cc: Jens Axboe 
Cc: Keith Busch 
Cc: Christoph Hellwig 
Cc: Sagi Grimberg 
Cc: linux-n...@lists.infradead.org
---
 drivers/nvme/Kconfig |4 
 1 file changed, 4 insertions(+)

--- lnx-414-rc1.orig/drivers/nvme/Kconfig
+++ lnx-414-rc1/drivers/nvme/Kconfig
@@ -1,2 +1,6 @@
+menu "NVME Support"
+
 source "drivers/nvme/host/Kconfig"
 source "drivers/nvme/target/Kconfig"
+
+endmenu

Re: [PATCH 1/2] KVM: nVMX: Fix nested #PF intends to break L1's vmlauch/vmresume

[Wanpeng Li]

2017-09-15 19:26 GMT+08:00 Paolo Bonzini :
> On 15/09/2017 05:48, Wanpeng Li wrote:
>> 2017-09-14 5:45 GMT+08:00 Paolo Bonzini :
>>> On 13/09/2017 13:03, Wanpeng Li wrote:
 From: Wanpeng Li 

 [ cut here ]
  WARNING: CPU: 4 PID: 5280 at /home/kernel/linux/arch/x86/kvm//vmx.c:11394 
 nested_vmx_vmexit+0xc2b/0xd70 [kvm_intel]
  CPU: 4 PID: 5280 Comm: qemu-system-x86 Tainted: GW  OE   4.13.0+ 
 #17
  RIP: 0010:nested_vmx_vmexit+0xc2b/0xd70 [kvm_intel]
  Call Trace:
   ? emulator_read_emulated+0x15/0x20 [kvm]
   ? segmented_read+0xae/0xf0 [kvm]
   vmx_inject_page_fault_nested+0x60/0x70 [kvm_intel]
   ? vmx_inject_page_fault_nested+0x60/0x70 [kvm_intel]
   x86_emulate_instruction+0x733/0x810 [kvm]
   vmx_handle_exit+0x2f4/0xda0 [kvm_intel]
   ? kvm_arch_vcpu_ioctl_run+0xd2f/0x1c60 [kvm]
   kvm_arch_vcpu_ioctl_run+0xdab/0x1c60 [kvm]
   ? kvm_arch_vcpu_load+0x62/0x230 [kvm]
   kvm_vcpu_ioctl+0x340/0x700 [kvm]
   ? kvm_vcpu_ioctl+0x340/0x700 [kvm]
   ? __fget+0xfc/0x210
   do_vfs_ioctl+0xa4/0x6a0
   ? __fget+0x11d/0x210
   SyS_ioctl+0x79/0x90
   entry_SYSCALL_64_fastpath+0x23/0xc2

 A nested #PF is triggered during L0 emulating instruction for L2. However, 
 it
 doesn't consider we should not break L1's vmlauch/vmresme. This patch fixes
 it by queuing the #PF exception instead ,requesting an immediate VM exit 
 from
 L2 and keeping the exception for L1 pending for a subsequent nested VM 
 exit.

 Cc: Paolo Bonzini 
 Cc: Radim Krčmář 
 Signed-off-by: Wanpeng Li 
 ---
  arch/x86/kvm/vmx.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
 index 4253ade..fda9dd6 100644
 --- a/arch/x86/kvm/vmx.c
 +++ b/arch/x86/kvm/vmx.c
 @@ -9829,7 +9829,8 @@ static void vmx_inject_page_fault_nested(struct 
 kvm_vcpu *vcpu,

   WARN_ON(!is_guest_mode(vcpu));

 - if (nested_vmx_is_page_fault_vmexit(vmcs12, fault->error_code)) {
 + if (nested_vmx_is_page_fault_vmexit(vmcs12, fault->error_code) &&
 + !to_vmx(vcpu)->nested.nested_run_pending) {
   vmcs12->vm_exit_intr_error_code = fault->error_code;
   nested_vmx_vmexit(vcpu, EXIT_REASON_EXCEPTION_NMI,
 PF_VECTOR | INTR_TYPE_HARD_EXCEPTION |

>>>
>>> Is vmx_inject_page_fault_nested even needed at all these days?
>>>
>>> kvm_inject_page_fault's call to kvm_queue_exception_e should transform
>>> into an L2->L1 vmexit when vmx_check_nested_events is called.
>>
>> After more investigation, this will break the original goal of what
>> vmx_inject_page_fault_nested() tries to fix.
>> http://www.spinics.net/lists/kvm/msg96579.html
>
> Right!  I think I have a generic patch for the same issue that Gleb
> solved there.  We can fill in the IDT vectoring info early in the
> vmexit, so that the L1 vmexit can overwrite the L2 exception easily.

Maybe my commit can be merged for the moment I think.

Regards,
Wanpeng Li

Re: [PATCH 1/2] KVM: nVMX: Fix nested #PF intends to break L1's vmlauch/vmresume

[Wanpeng Li]

2017-09-15 19:26 GMT+08:00 Paolo Bonzini :
> On 15/09/2017 05:48, Wanpeng Li wrote:
>> 2017-09-14 5:45 GMT+08:00 Paolo Bonzini :
>>> On 13/09/2017 13:03, Wanpeng Li wrote:
 From: Wanpeng Li 

 [ cut here ]
  WARNING: CPU: 4 PID: 5280 at /home/kernel/linux/arch/x86/kvm//vmx.c:11394 
 nested_vmx_vmexit+0xc2b/0xd70 [kvm_intel]
  CPU: 4 PID: 5280 Comm: qemu-system-x86 Tainted: GW  OE   4.13.0+ 
 #17
  RIP: 0010:nested_vmx_vmexit+0xc2b/0xd70 [kvm_intel]
  Call Trace:
   ? emulator_read_emulated+0x15/0x20 [kvm]
   ? segmented_read+0xae/0xf0 [kvm]
   vmx_inject_page_fault_nested+0x60/0x70 [kvm_intel]
   ? vmx_inject_page_fault_nested+0x60/0x70 [kvm_intel]
   x86_emulate_instruction+0x733/0x810 [kvm]
   vmx_handle_exit+0x2f4/0xda0 [kvm_intel]
   ? kvm_arch_vcpu_ioctl_run+0xd2f/0x1c60 [kvm]
   kvm_arch_vcpu_ioctl_run+0xdab/0x1c60 [kvm]
   ? kvm_arch_vcpu_load+0x62/0x230 [kvm]
   kvm_vcpu_ioctl+0x340/0x700 [kvm]
   ? kvm_vcpu_ioctl+0x340/0x700 [kvm]
   ? __fget+0xfc/0x210
   do_vfs_ioctl+0xa4/0x6a0
   ? __fget+0x11d/0x210
   SyS_ioctl+0x79/0x90
   entry_SYSCALL_64_fastpath+0x23/0xc2

 A nested #PF is triggered during L0 emulating instruction for L2. However, 
 it
 doesn't consider we should not break L1's vmlauch/vmresme. This patch fixes
 it by queuing the #PF exception instead ,requesting an immediate VM exit 
 from
 L2 and keeping the exception for L1 pending for a subsequent nested VM 
 exit.

 Cc: Paolo Bonzini 
 Cc: Radim Krčmář 
 Signed-off-by: Wanpeng Li 
 ---
  arch/x86/kvm/vmx.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

 diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
 index 4253ade..fda9dd6 100644
 --- a/arch/x86/kvm/vmx.c
 +++ b/arch/x86/kvm/vmx.c
 @@ -9829,7 +9829,8 @@ static void vmx_inject_page_fault_nested(struct 
 kvm_vcpu *vcpu,

   WARN_ON(!is_guest_mode(vcpu));

 - if (nested_vmx_is_page_fault_vmexit(vmcs12, fault->error_code)) {
 + if (nested_vmx_is_page_fault_vmexit(vmcs12, fault->error_code) &&
 + !to_vmx(vcpu)->nested.nested_run_pending) {
   vmcs12->vm_exit_intr_error_code = fault->error_code;
   nested_vmx_vmexit(vcpu, EXIT_REASON_EXCEPTION_NMI,
 PF_VECTOR | INTR_TYPE_HARD_EXCEPTION |

>>>
>>> Is vmx_inject_page_fault_nested even needed at all these days?
>>>
>>> kvm_inject_page_fault's call to kvm_queue_exception_e should transform
>>> into an L2->L1 vmexit when vmx_check_nested_events is called.
>>
>> After more investigation, this will break the original goal of what
>> vmx_inject_page_fault_nested() tries to fix.
>> http://www.spinics.net/lists/kvm/msg96579.html
>
> Right!  I think I have a generic patch for the same issue that Gleb
> solved there.  We can fill in the IDT vectoring info early in the
> vmexit, so that the L1 vmexit can overwrite the L2 exception easily.

Maybe my commit can be merged for the moment I think.

Regards,
Wanpeng Li

Re: [PATCH net-next 10/10] net: hns3: Add mqprio support when interacting with network stack

[Yunsheng Lin]

Hi, Jiri

On 2017/9/23 0:03, Jiri Pirko wrote:
> Fri, Sep 22, 2017 at 04:11:51PM CEST, linyunsh...@huawei.com wrote:
>> Hi, Jiri
>>
 - if (!tc) {
 + if (if_running) {
 + (void)hns3_nic_net_stop(netdev);
 + msleep(100);
 + }
 +
 + ret = (kinfo->dcb_ops && kinfo->dcb_ops->>setup_tc) ?
 + kinfo->dcb_ops->setup_tc(h, tc, prio_tc) : ->EOPNOTSUPP;
>>
>>> This is most odd. Why do you call dcb_ops from >ndo_setup_tc callback?
>>> Why are you mixing this together? prio->tc mapping >can be done
>>> directly in dcbnl
>>
>> Here is what we do in dcb_ops->setup_tc:
>> Firstly, if current tc num is different from the tc num
>> that user provide, then we setup the queues for each
>> tc.
>>
>> Secondly, we tell hardware the pri to tc mapping that
>> the stack is using. In rx direction, our hardware need
>> that mapping to put different packet into different tc'
>> queues according to the priority of the packet, then
>> rss decides which specific queue in the tc should the
>> packet goto.
>>
>> By mixing, I suppose you meant why we need the
>> pri to tc infomation?
> 
> by mixing, I mean what I wrote. You are calling dcb_ops callback from
> ndo_setup_tc callback. So you are mixing DCBNL subsystem and TC
> subsystem. Why? Why do you need sch_mqprio? Why DCBNL is not enough for
> all?

When using lldptool, dcbnl is involved.

But when using tc qdisc, dcbbl is not involved, below is the a few key
call graph in the kernel when tc qdisc cmd is executed.

cmd:
tc qdisc add dev eth0 root handle 1:0 mqprio num_tc 4 map 1 2 3 3 1 3 1 1 hw 1

call graph:
rtnetlink_rcv_msg -> tc_modify_qdisc -> qdisc_create -> mqprio_init ->
hns3_nic_setup_tc

When hns3_nic_setup_tc is called, we need to know how many tc num and
prio_tc mapping from the tc_mqprio_qopt which is provided in the paramter
in the ndo_setup_tc function, and dcb_ops is the our hardware specific
method to setup the tc related parameter to the hardware, so this is why
we call dcb_ops callback in ndo_setup_tc callback.

I hope this will answer your question, thanks for your time.

> 
> 
> 
>> I hope I did not misunderstand your question, thanks
>> for your time reviewing.
> 
> .
> 

Re: [PATCH net-next 10/10] net: hns3: Add mqprio support when interacting with network stack

[Yunsheng Lin]

Hi, Jiri

On 2017/9/23 0:03, Jiri Pirko wrote:
> Fri, Sep 22, 2017 at 04:11:51PM CEST, linyunsh...@huawei.com wrote:
>> Hi, Jiri
>>
 - if (!tc) {
 + if (if_running) {
 + (void)hns3_nic_net_stop(netdev);
 + msleep(100);
 + }
 +
 + ret = (kinfo->dcb_ops && kinfo->dcb_ops->>setup_tc) ?
 + kinfo->dcb_ops->setup_tc(h, tc, prio_tc) : ->EOPNOTSUPP;
>>
>>> This is most odd. Why do you call dcb_ops from >ndo_setup_tc callback?
>>> Why are you mixing this together? prio->tc mapping >can be done
>>> directly in dcbnl
>>
>> Here is what we do in dcb_ops->setup_tc:
>> Firstly, if current tc num is different from the tc num
>> that user provide, then we setup the queues for each
>> tc.
>>
>> Secondly, we tell hardware the pri to tc mapping that
>> the stack is using. In rx direction, our hardware need
>> that mapping to put different packet into different tc'
>> queues according to the priority of the packet, then
>> rss decides which specific queue in the tc should the
>> packet goto.
>>
>> By mixing, I suppose you meant why we need the
>> pri to tc infomation?
> 
> by mixing, I mean what I wrote. You are calling dcb_ops callback from
> ndo_setup_tc callback. So you are mixing DCBNL subsystem and TC
> subsystem. Why? Why do you need sch_mqprio? Why DCBNL is not enough for
> all?

When using lldptool, dcbnl is involved.

But when using tc qdisc, dcbbl is not involved, below is the a few key
call graph in the kernel when tc qdisc cmd is executed.

cmd:
tc qdisc add dev eth0 root handle 1:0 mqprio num_tc 4 map 1 2 3 3 1 3 1 1 hw 1

call graph:
rtnetlink_rcv_msg -> tc_modify_qdisc -> qdisc_create -> mqprio_init ->
hns3_nic_setup_tc

When hns3_nic_setup_tc is called, we need to know how many tc num and
prio_tc mapping from the tc_mqprio_qopt which is provided in the paramter
in the ndo_setup_tc function, and dcb_ops is the our hardware specific
method to setup the tc related parameter to the hardware, so this is why
we call dcb_ops callback in ndo_setup_tc callback.

I hope this will answer your question, thanks for your time.

> 
> 
> 
>> I hope I did not misunderstand your question, thanks
>> for your time reviewing.
> 
> .
> 

Re: [PATCH 10/11] selftests: futex: copy sub-dir test scripts for make O=dir run

[Darren Hart]

On Tue, Sep 12, 2017 at 05:53:03PM -0600, Shuah Khan wrote:
> For make O=dir run_tests to work, test scripts from sub-directories
> need to be copied over to the object directory. Running tests from the
> object directory is necessary to avoid making the source tree dirty.
> 
> Signed-off-by: Shuah Khan 
> ---
>  tools/testing/selftests/futex/Makefile | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/futex/Makefile 
> b/tools/testing/selftests/futex/Makefile
> index 7c647f619d63..9358cb210fd5 100644
> --- a/tools/testing/selftests/futex/Makefile
> +++ b/tools/testing/selftests/futex/Makefile
> @@ -11,10 +11,13 @@ all:
>   BUILD_TARGET=$(OUTPUT)/$$DIR;   \
>   mkdir $$BUILD_TARGET  -p;   \
>   make OUTPUT=$$BUILD_TARGET -C $$DIR $@;\
> + if [ -e $$DIR/$(TEST_PROGS) ]; then
> + rsync -a $$DIR/$(TEST_PROGS) $$BUILD_TARGET/;

Hrm, I was going to raise a concern with adding an rsync dependency
here, but it is already used several times by lib.mk, so that isn't new.

Reviewed-by: Darren Hart (VMware) 

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH 10/11] selftests: futex: copy sub-dir test scripts for make O=dir run

[Darren Hart]

On Tue, Sep 12, 2017 at 05:53:03PM -0600, Shuah Khan wrote:
> For make O=dir run_tests to work, test scripts from sub-directories
> need to be copied over to the object directory. Running tests from the
> object directory is necessary to avoid making the source tree dirty.
> 
> Signed-off-by: Shuah Khan 
> ---
>  tools/testing/selftests/futex/Makefile | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/tools/testing/selftests/futex/Makefile 
> b/tools/testing/selftests/futex/Makefile
> index 7c647f619d63..9358cb210fd5 100644
> --- a/tools/testing/selftests/futex/Makefile
> +++ b/tools/testing/selftests/futex/Makefile
> @@ -11,10 +11,13 @@ all:
>   BUILD_TARGET=$(OUTPUT)/$$DIR;   \
>   mkdir $$BUILD_TARGET  -p;   \
>   make OUTPUT=$$BUILD_TARGET -C $$DIR $@;\
> + if [ -e $$DIR/$(TEST_PROGS) ]; then
> + rsync -a $$DIR/$(TEST_PROGS) $$BUILD_TARGET/;

Hrm, I was going to raise a concern with adding an rsync dependency
here, but it is already used several times by lib.mk, so that isn't new.

Reviewed-by: Darren Hart (VMware) 

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH 0/3] fix reuseaddr regression

[Josef Bacik]

On Tue, Sep 19, 2017 at 01:50:56PM -0700, David Miller wrote:
> From: jo...@toxicpanda.com
> Date: Mon, 18 Sep 2017 12:28:54 -0400
> 
> > I introduced a regression when reworking the fastreuse port stuff that 
> > allows
> > bind conflicts to occur once a reuseaddr socket successfully opens on an
> > existing tb.  The root cause is I reversed an if statement which caused us 
> > to
> > set the tb as if there were no owners on the socket if there were, which
> > obviously is not correct.
> > 
> > Dave I have follow up patches that will add a selftest for this case and I 
> > ran
> > the other reuseport related tests as well.  These need to go in pretty 
> > quickly
> > as it breaks kvm, I've marked them for stable.  Sorry for the regression,
> 
> First, please fix your "From: " field so that it actually has your full
> name rather than just your email address.  This matter when I apply
> your patches.
> 
> Second, remove the stable CC:.  For networking changes, you simply ask
> me to queue the changes up for -stable.
> 

Sorry Dave, I've fixed my git email settings and I droped the stable cc and sent
a new round.  Didn't see this until just now, my bad.

Josef

Re: [PATCH 0/3] fix reuseaddr regression

[Josef Bacik]

On Tue, Sep 19, 2017 at 01:50:56PM -0700, David Miller wrote:
> From: jo...@toxicpanda.com
> Date: Mon, 18 Sep 2017 12:28:54 -0400
> 
> > I introduced a regression when reworking the fastreuse port stuff that 
> > allows
> > bind conflicts to occur once a reuseaddr socket successfully opens on an
> > existing tb.  The root cause is I reversed an if statement which caused us 
> > to
> > set the tb as if there were no owners on the socket if there were, which
> > obviously is not correct.
> > 
> > Dave I have follow up patches that will add a selftest for this case and I 
> > ran
> > the other reuseport related tests as well.  These need to go in pretty 
> > quickly
> > as it breaks kvm, I've marked them for stable.  Sorry for the regression,
> 
> First, please fix your "From: " field so that it actually has your full
> name rather than just your email address.  This matter when I apply
> your patches.
> 
> Second, remove the stable CC:.  For networking changes, you simply ask
> me to queue the changes up for -stable.
> 

Sorry Dave, I've fixed my git email settings and I droped the stable cc and sent
a new round.  Didn't see this until just now, my bad.

Josef

Re: [PATCH] selftests: futex: Makefile: fix for lops in targets to run silently

[Darren Hart]

On Mon, Sep 18, 2017 at 06:59:15PM -0600, Shuah Khan wrote:
> Fix for loops in targets to run silently to avoid cluttering the test
> results.
> 
> Suppresses the following from targets:
> 
> for DIR in functional; do   \
> BUILD_TARGET=./tools/testing/selftests/futex/$DIR; \
> mkdir $BUILD_TARGET  -p;\
> make OUTPUT=$BUILD_TARGET -C $DIR all;\
> done
> 
> ./tools/testing/selftests/futex/run.sh
> 
> Signed-off-by: Shuah Khan 

Thanks Shuah,

Reviewed-by: Darren Hart (VMware) 

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH] selftests: futex: Makefile: fix for lops in targets to run silently

[Darren Hart]

On Mon, Sep 18, 2017 at 06:59:15PM -0600, Shuah Khan wrote:
> Fix for loops in targets to run silently to avoid cluttering the test
> results.
> 
> Suppresses the following from targets:
> 
> for DIR in functional; do   \
> BUILD_TARGET=./tools/testing/selftests/futex/$DIR; \
> mkdir $BUILD_TARGET  -p;\
> make OUTPUT=$BUILD_TARGET -C $DIR all;\
> done
> 
> ./tools/testing/selftests/futex/run.sh
> 
> Signed-off-by: Shuah Khan 

Thanks Shuah,

Reviewed-by: Darren Hart (VMware) 

-- 
Darren Hart
VMware Open Source Technology Center

[PATCH 1/3] net: set tb->fast_sk_family

[Josef Bacik]

From: Josef Bacik 

We need to set the tb->fast_sk_family properly so we can use the proper
comparison function for all subsequent reuseport bind requests.

Fixes: 637bc8bbe6c0 ("inet: reset tb->fastreuseport when adding a reuseport sk")
Reported-and-tested-by: Cole Robinson 
Signed-off-by: Josef Bacik 
---
 net/ipv4/inet_connection_sock.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index b9c64b40a83a..f87f4805e244 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -328,6 +328,7 @@ int inet_csk_get_port(struct sock *sk, unsigned short snum)
tb->fastuid = uid;
tb->fast_rcv_saddr = sk->sk_rcv_saddr;
tb->fast_ipv6_only = ipv6_only_sock(sk);
+   tb->fast_sk_family = sk->sk_family;
 #if IS_ENABLED(CONFIG_IPV6)
tb->fast_v6_rcv_saddr = sk->sk_v6_rcv_saddr;
 #endif
@@ -354,6 +355,7 @@ int inet_csk_get_port(struct sock *sk, unsigned short snum)
tb->fastuid = uid;
tb->fast_rcv_saddr = sk->sk_rcv_saddr;
tb->fast_ipv6_only = ipv6_only_sock(sk);
+   tb->fast_sk_family = sk->sk_family;
 #if IS_ENABLED(CONFIG_IPV6)
tb->fast_v6_rcv_saddr = sk->sk_v6_rcv_saddr;
 #endif
-- 
2.7.4

[PATCH 1/3] net: set tb->fast_sk_family

[Josef Bacik]

From: Josef Bacik 

We need to set the tb->fast_sk_family properly so we can use the proper
comparison function for all subsequent reuseport bind requests.

Fixes: 637bc8bbe6c0 ("inet: reset tb->fastreuseport when adding a reuseport sk")
Reported-and-tested-by: Cole Robinson 
Signed-off-by: Josef Bacik 
---
 net/ipv4/inet_connection_sock.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index b9c64b40a83a..f87f4805e244 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -328,6 +328,7 @@ int inet_csk_get_port(struct sock *sk, unsigned short snum)
tb->fastuid = uid;
tb->fast_rcv_saddr = sk->sk_rcv_saddr;
tb->fast_ipv6_only = ipv6_only_sock(sk);
+   tb->fast_sk_family = sk->sk_family;
 #if IS_ENABLED(CONFIG_IPV6)
tb->fast_v6_rcv_saddr = sk->sk_v6_rcv_saddr;
 #endif
@@ -354,6 +355,7 @@ int inet_csk_get_port(struct sock *sk, unsigned short snum)
tb->fastuid = uid;
tb->fast_rcv_saddr = sk->sk_rcv_saddr;
tb->fast_ipv6_only = ipv6_only_sock(sk);
+   tb->fast_sk_family = sk->sk_family;
 #if IS_ENABLED(CONFIG_IPV6)
tb->fast_v6_rcv_saddr = sk->sk_v6_rcv_saddr;
 #endif
-- 
2.7.4

[PATCH 2/3] net: use inet6_rcv_saddr to compare sockets

[Josef Bacik]

From: Josef Bacik 

In ipv6_rcv_saddr_equal() we need to use inet6_rcv_saddr(sk) for the
ipv6 compare with the fast socket information to make sure we're doing
the proper comparisons.

Fixes: 637bc8bbe6c0 ("inet: reset tb->fastreuseport when adding a reuseport sk")
Reported-and-tested-by: Cole Robinson 
Signed-off-by: Josef Bacik 
---
 net/ipv4/inet_connection_sock.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index f87f4805e244..a1bf30438bc5 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -266,7 +266,7 @@ static inline int sk_reuseport_match(struct 
inet_bind_bucket *tb,
 #if IS_ENABLED(CONFIG_IPV6)
if (tb->fast_sk_family == AF_INET6)
return ipv6_rcv_saddr_equal(>fast_v6_rcv_saddr,
-   >sk_v6_rcv_saddr,
+   inet6_rcv_saddr(sk),
tb->fast_rcv_saddr,
sk->sk_rcv_saddr,
tb->fast_ipv6_only,
-- 
2.7.4

[PATCH 2/3] net: use inet6_rcv_saddr to compare sockets

[Josef Bacik]

From: Josef Bacik 

In ipv6_rcv_saddr_equal() we need to use inet6_rcv_saddr(sk) for the
ipv6 compare with the fast socket information to make sure we're doing
the proper comparisons.

Fixes: 637bc8bbe6c0 ("inet: reset tb->fastreuseport when adding a reuseport sk")
Reported-and-tested-by: Cole Robinson 
Signed-off-by: Josef Bacik 
---
 net/ipv4/inet_connection_sock.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index f87f4805e244..a1bf30438bc5 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -266,7 +266,7 @@ static inline int sk_reuseport_match(struct 
inet_bind_bucket *tb,
 #if IS_ENABLED(CONFIG_IPV6)
if (tb->fast_sk_family == AF_INET6)
return ipv6_rcv_saddr_equal(>fast_v6_rcv_saddr,
-   >sk_v6_rcv_saddr,
+   inet6_rcv_saddr(sk),
tb->fast_rcv_saddr,
sk->sk_rcv_saddr,
tb->fast_ipv6_only,
-- 
2.7.4

[PATCH 3/3] inet: fix improper empty comparison

[Josef Bacik]

From: Josef Bacik 

When doing my reuseport rework I screwed up and changed a

if (hlist_empty(>owners))

to

if (!hlist_empty(>owners))

This is obviously bad as all of the reuseport/reuse logic was reversed,
which caused weird problems like allowing an ipv4 bind conflict if we
opened an ipv4 only socket on a port followed by an ipv6 only socket on
the same port.

Fixes: b9470c27607b ("inet: kill smallest_size and smallest_port")
Reported-by: Cole Robinson 
Signed-off-by: Josef Bacik 
---
 net/ipv4/inet_connection_sock.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index a1bf30438bc5..c039c937ba90 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -321,7 +321,7 @@ int inet_csk_get_port(struct sock *sk, unsigned short snum)
goto fail_unlock;
}
 success:
-   if (!hlist_empty(>owners)) {
+   if (hlist_empty(>owners)) {
tb->fastreuse = reuse;
if (sk->sk_reuseport) {
tb->fastreuseport = FASTREUSEPORT_ANY;
-- 
2.7.4

[PATCH 3/3] inet: fix improper empty comparison

[Josef Bacik]

From: Josef Bacik 

When doing my reuseport rework I screwed up and changed a

if (hlist_empty(>owners))

to

if (!hlist_empty(>owners))

This is obviously bad as all of the reuseport/reuse logic was reversed,
which caused weird problems like allowing an ipv4 bind conflict if we
opened an ipv4 only socket on a port followed by an ipv6 only socket on
the same port.

Fixes: b9470c27607b ("inet: kill smallest_size and smallest_port")
Reported-by: Cole Robinson 
Signed-off-by: Josef Bacik 
---
 net/ipv4/inet_connection_sock.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index a1bf30438bc5..c039c937ba90 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -321,7 +321,7 @@ int inet_csk_get_port(struct sock *sk, unsigned short snum)
goto fail_unlock;
}
 success:
-   if (!hlist_empty(>owners)) {
+   if (hlist_empty(>owners)) {
tb->fastreuse = reuse;
if (sk->sk_reuseport) {
tb->fastreuseport = FASTREUSEPORT_ANY;
-- 
2.7.4

[PATCH 0/3] fix reuseaddr regression

[Josef Bacik]

I introduced a regression when reworking the fastreuse port stuff that allows
bind conflicts to occur once a reuseaddr successfully opens on an existing tb.
The root cause is I reversed an if statement which caused us to set the tb as if
there were no owners on the socket if there were, which obviously is not
correct.

Dave could you please queue these changes up for -stable, I've run them through
the net tests and added another test to check for this problem specifically.
Thanks,

Josef

[PATCH 0/3] fix reuseaddr regression

[Josef Bacik]

I introduced a regression when reworking the fastreuse port stuff that allows
bind conflicts to occur once a reuseaddr successfully opens on an existing tb.
The root cause is I reversed an if statement which caused us to set the tb as if
there were no owners on the socket if there were, which obviously is not
correct.

Dave could you please queue these changes up for -stable, I've run them through
the net tests and added another test to check for this problem specifically.
Thanks,

Josef

Re: [PATCH] Asus WMI : Add lightbar led support

[Darren Hart]

On Thu, Sep 21, 2017 at 01:20:01PM +0200, Maxime Bellengé wrote:
> Some asus laptops (ROG series for example) are provided with a lightbar 
> behind the monitor.
> This patch make posible to switch it on and off. This lightbar works exactly 
> as any other led.
> 

Hi Maxime,

The patch looks good from a functional implementation perspective.

There are 3 mechanical and style errors the checkpatch script catches. Please
update the patch and resubmit:

WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per 
line)
#85: 
Some asus laptops (ROG series for example) are provided with a lightbar behind 
the monitor.

WARNING: 'posible' may be misspelled - perhaps 'possible'?
#86: 
This patch make posible to switch it on and off. This lightbar works exactly as 
any other led.

WARNING: please, no space before tabs
#101: FILE: drivers/platform/x86/asus-wmi.c:122:
+#define ASUS_WMI_DEVID_LIGHTBAR ^I0x00050025$

total: 0 errors, 3 warnings, 103 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
  mechanically convert to the typical style using --fix or --fix-inplace.

/home/dvhart/incoming/PATCH_Asus_WMI_Add_lightbar_led_support.mbox has style 
problems, please review.

NOTE: If any of the errors are false positives, please report
  them to the maintainer, see CHECKPATCH in MAINTAINERS.

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH] Asus WMI : Add lightbar led support

[Darren Hart]

On Thu, Sep 21, 2017 at 01:20:01PM +0200, Maxime Bellengé wrote:
> Some asus laptops (ROG series for example) are provided with a lightbar 
> behind the monitor.
> This patch make posible to switch it on and off. This lightbar works exactly 
> as any other led.
> 

Hi Maxime,

The patch looks good from a functional implementation perspective.

There are 3 mechanical and style errors the checkpatch script catches. Please
update the patch and resubmit:

WARNING: Possible unwrapped commit description (prefer a maximum 75 chars per 
line)
#85: 
Some asus laptops (ROG series for example) are provided with a lightbar behind 
the monitor.

WARNING: 'posible' may be misspelled - perhaps 'possible'?
#86: 
This patch make posible to switch it on and off. This lightbar works exactly as 
any other led.

WARNING: please, no space before tabs
#101: FILE: drivers/platform/x86/asus-wmi.c:122:
+#define ASUS_WMI_DEVID_LIGHTBAR ^I0x00050025$

total: 0 errors, 3 warnings, 103 lines checked

NOTE: For some of the reported defects, checkpatch may be able to
  mechanically convert to the typical style using --fix or --fix-inplace.

/home/dvhart/incoming/PATCH_Asus_WMI_Add_lightbar_led_support.mbox has style 
problems, please review.

NOTE: If any of the errors are false positives, please report
  them to the maintainer, see CHECKPATCH in MAINTAINERS.

-- 
Darren Hart
VMware Open Source Technology Center

[PATCH 1/3] clk: sunxi-ng: add mux and pll notifiers for A64 CPU clock

[Icenowy Zheng]

The A64 PLL_CPU clock has the same instability if some factor changed
without the PLL gated like other SoCs with sun6i-style CCU, e.g. A33,
H3.

Add the mux and pll notifiers for A64 CPU clock to workaround the
problem.

Fixes: c6a0637460c2 ("clk: sunxi-ng: Add A64 clocks")
Signed-off-by: Icenowy Zheng 
---
 drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c 
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index 2bb4cabf802f..b55fa69dd0c1 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -879,11 +879,26 @@ static const struct sunxi_ccu_desc sun50i_a64_ccu_desc = {
.num_resets = ARRAY_SIZE(sun50i_a64_ccu_resets),
 };
 
+static struct ccu_pll_nb sun50i_a64_pll_cpu_nb = {
+   .common = _cpux_clk.common,
+   /* copy from pll_cpux_clk */
+   .enable = BIT(31),
+   .lock   = BIT(28),
+};
+
+static struct ccu_mux_nb sun50i_a64_cpu_nb = {
+   .common = _clk.common,
+   .cm = _clk.mux,
+   .delay_us   = 1, /* > 8 clock cycles at 24 MHz */
+   .bypass_index   = 1, /* index of 24 MHz oscillator */
+};
+
 static int sun50i_a64_ccu_probe(struct platform_device *pdev)
 {
struct resource *res;
void __iomem *reg;
u32 val;
+   int ret;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
reg = devm_ioremap_resource(>dev, res);
@@ -897,7 +912,18 @@ static int sun50i_a64_ccu_probe(struct platform_device 
*pdev)
 
writel(0x515, reg + SUN50I_A64_PLL_MIPI_REG);
 
-   return sunxi_ccu_probe(pdev->dev.of_node, reg, _a64_ccu_desc);
+   ret = sunxi_ccu_probe(pdev->dev.of_node, reg, _a64_ccu_desc);
+   if (ret)
+   return ret;
+
+   /* Gate then ungate PLL CPU after any rate changes */
+   ccu_pll_notifier_register(_a64_pll_cpu_nb);
+
+   /* Reparent CPU during PLL CPU rate changes */
+   ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
+ _a64_cpu_nb);
+
+   return 0;
 }
 
 static const struct of_device_id sun50i_a64_ccu_ids[] = {
-- 
2.13.5

[PATCH 3/3] arm64: allwinner: a64: set CPU regulator for Pine64

[Icenowy Zheng]

The DCDC2 regulator of the AXP803 PMIC is used for the voltage scaling
of the ARM cores on the A64 SoC.

Add this definition to enable it on Pine64.

Signed-off-by: Icenowy Zheng 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index d06e34b5d192..cc77503091f1 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -63,6 +63,10 @@
};
 };
 
+ {
+   cpu-supply = <_dcdc2>;
+};
+
  {
status = "okay";
 };
-- 
2.13.5

[PATCH 1/3] clk: sunxi-ng: add mux and pll notifiers for A64 CPU clock

[Icenowy Zheng]

The A64 PLL_CPU clock has the same instability if some factor changed
without the PLL gated like other SoCs with sun6i-style CCU, e.g. A33,
H3.

Add the mux and pll notifiers for A64 CPU clock to workaround the
problem.

Fixes: c6a0637460c2 ("clk: sunxi-ng: Add A64 clocks")
Signed-off-by: Icenowy Zheng 
---
 drivers/clk/sunxi-ng/ccu-sun50i-a64.c | 28 +++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c 
b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
index 2bb4cabf802f..b55fa69dd0c1 100644
--- a/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
+++ b/drivers/clk/sunxi-ng/ccu-sun50i-a64.c
@@ -879,11 +879,26 @@ static const struct sunxi_ccu_desc sun50i_a64_ccu_desc = {
.num_resets = ARRAY_SIZE(sun50i_a64_ccu_resets),
 };
 
+static struct ccu_pll_nb sun50i_a64_pll_cpu_nb = {
+   .common = _cpux_clk.common,
+   /* copy from pll_cpux_clk */
+   .enable = BIT(31),
+   .lock   = BIT(28),
+};
+
+static struct ccu_mux_nb sun50i_a64_cpu_nb = {
+   .common = _clk.common,
+   .cm = _clk.mux,
+   .delay_us   = 1, /* > 8 clock cycles at 24 MHz */
+   .bypass_index   = 1, /* index of 24 MHz oscillator */
+};
+
 static int sun50i_a64_ccu_probe(struct platform_device *pdev)
 {
struct resource *res;
void __iomem *reg;
u32 val;
+   int ret;
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
reg = devm_ioremap_resource(>dev, res);
@@ -897,7 +912,18 @@ static int sun50i_a64_ccu_probe(struct platform_device 
*pdev)
 
writel(0x515, reg + SUN50I_A64_PLL_MIPI_REG);
 
-   return sunxi_ccu_probe(pdev->dev.of_node, reg, _a64_ccu_desc);
+   ret = sunxi_ccu_probe(pdev->dev.of_node, reg, _a64_ccu_desc);
+   if (ret)
+   return ret;
+
+   /* Gate then ungate PLL CPU after any rate changes */
+   ccu_pll_notifier_register(_a64_pll_cpu_nb);
+
+   /* Reparent CPU during PLL CPU rate changes */
+   ccu_mux_notifier_register(pll_cpux_clk.common.hw.clk,
+ _a64_cpu_nb);
+
+   return 0;
 }
 
 static const struct of_device_id sun50i_a64_ccu_ids[] = {
-- 
2.13.5

[PATCH 3/3] arm64: allwinner: a64: set CPU regulator for Pine64

[Icenowy Zheng]

The DCDC2 regulator of the AXP803 PMIC is used for the voltage scaling
of the ARM cores on the A64 SoC.

Add this definition to enable it on Pine64.

Signed-off-by: Icenowy Zheng 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts 
b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
index d06e34b5d192..cc77503091f1 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64-pine64.dts
@@ -63,6 +63,10 @@
};
 };
 
+ {
+   cpu-supply = <_dcdc2>;
+};
+
  {
status = "okay";
 };
-- 
2.13.5

[PATCH 0/3] Simple DVFS support for Allwinner A64 SoC

[Icenowy Zheng]

This patchset imports simple DVFS support for Allwinner A64 SoC.

As the thermal sensor driver is not yet implemented and some boards
have still no AXP PMIC support, now only two OPPs are present --
648MHz@1.04V and 816MHz@1.1V to prevent overheat or undervoltage.

PATCH 1 is a fix to the CCU driver of A64, and the remaining patches
set up the device tree bits of the DVFS on Pine64.

Icenowy Zheng (3):
  clk: sunxi-ng: add mux and pll notifiers for A64 CPU clock
  arm64: allwinner: a64: add CPU opp table
  arm64: allwinner: a64: set CPU regulator for Pine64

 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts |  4 
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi  | 24 +++
 drivers/clk/sunxi-ng/ccu-sun50i-a64.c  | 28 +-
 3 files changed, 55 insertions(+), 1 deletion(-)

-- 
2.13.5

[PATCH 0/3] Simple DVFS support for Allwinner A64 SoC

[Icenowy Zheng]

This patchset imports simple DVFS support for Allwinner A64 SoC.

As the thermal sensor driver is not yet implemented and some boards
have still no AXP PMIC support, now only two OPPs are present --
648MHz@1.04V and 816MHz@1.1V to prevent overheat or undervoltage.

PATCH 1 is a fix to the CCU driver of A64, and the remaining patches
set up the device tree bits of the DVFS on Pine64.

Icenowy Zheng (3):
  clk: sunxi-ng: add mux and pll notifiers for A64 CPU clock
  arm64: allwinner: a64: add CPU opp table
  arm64: allwinner: a64: set CPU regulator for Pine64

 .../arm64/boot/dts/allwinner/sun50i-a64-pine64.dts |  4 
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi  | 24 +++
 drivers/clk/sunxi-ng/ccu-sun50i-a64.c  | 28 +-
 3 files changed, 55 insertions(+), 1 deletion(-)

-- 
2.13.5

[PATCH 2/3] arm64: allwinner: a64: add CPU opp table

[Icenowy Zheng]

Add the operating table for the CPU (ARM cores) on Allwinner A64 SoC.

OPPs higher to 816MHz is temporarily dropped, to prevent overheat on
boards with AXP803 support and undervoltage on boards without AXP803
support.

Signed-off-by: Icenowy Zheng 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 20aba7b186aa..0532da4939eb 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -52,6 +52,23 @@
#address-cells = <1>;
#size-cells = <1>;
 
+   cpu0_opp_table: opp_table0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp-64800 {
+   opp-hz = /bits/ 64 <64800>;
+   opp-microvolt = <104>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+
+   opp-81600 {
+   opp-hz = /bits/ 64 <81600>;
+   opp-microvolt = <110>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+   };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -61,6 +78,10 @@
device_type = "cpu";
reg = <0>;
enable-method = "psci";
+   clocks = < CLK_CPUX>;
+   clock-names = "cpu";
+   operating-points-v2 = <_opp_table>;
+   #cooling-cells = <2>;
};
 
cpu1: cpu@1 {
@@ -68,6 +89,7 @@
device_type = "cpu";
reg = <1>;
enable-method = "psci";
+   operating-points-v2 = <_opp_table>;
};
 
cpu2: cpu@2 {
@@ -75,6 +97,7 @@
device_type = "cpu";
reg = <2>;
enable-method = "psci";
+   operating-points-v2 = <_opp_table>;
};
 
cpu3: cpu@3 {
@@ -82,6 +105,7 @@
device_type = "cpu";
reg = <3>;
enable-method = "psci";
+   operating-points-v2 = <_opp_table>;
};
};
 
-- 
2.13.5

[PATCH 2/3] arm64: allwinner: a64: add CPU opp table

[Icenowy Zheng]

Add the operating table for the CPU (ARM cores) on Allwinner A64 SoC.

OPPs higher to 816MHz is temporarily dropped, to prevent overheat on
boards with AXP803 support and undervoltage on boards without AXP803
support.

Signed-off-by: Icenowy Zheng 
---
 arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi | 24 
 1 file changed, 24 insertions(+)

diff --git a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi 
b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
index 20aba7b186aa..0532da4939eb 100644
--- a/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
+++ b/arch/arm64/boot/dts/allwinner/sun50i-a64.dtsi
@@ -52,6 +52,23 @@
#address-cells = <1>;
#size-cells = <1>;
 
+   cpu0_opp_table: opp_table0 {
+   compatible = "operating-points-v2";
+   opp-shared;
+
+   opp-64800 {
+   opp-hz = /bits/ 64 <64800>;
+   opp-microvolt = <104>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+
+   opp-81600 {
+   opp-hz = /bits/ 64 <81600>;
+   opp-microvolt = <110>;
+   clock-latency-ns = <244144>; /* 8 32k periods */
+   };
+   };
+
cpus {
#address-cells = <1>;
#size-cells = <0>;
@@ -61,6 +78,10 @@
device_type = "cpu";
reg = <0>;
enable-method = "psci";
+   clocks = < CLK_CPUX>;
+   clock-names = "cpu";
+   operating-points-v2 = <_opp_table>;
+   #cooling-cells = <2>;
};
 
cpu1: cpu@1 {
@@ -68,6 +89,7 @@
device_type = "cpu";
reg = <1>;
enable-method = "psci";
+   operating-points-v2 = <_opp_table>;
};
 
cpu2: cpu@2 {
@@ -75,6 +97,7 @@
device_type = "cpu";
reg = <2>;
enable-method = "psci";
+   operating-points-v2 = <_opp_table>;
};
 
cpu3: cpu@3 {
@@ -82,6 +105,7 @@
device_type = "cpu";
reg = <3>;
enable-method = "psci";
+   operating-points-v2 = <_opp_table>;
};
};
 
-- 
2.13.5

Re: [PATCH v2 07/10] dmaengine: sun6i: Retrieve channel count/max request from devicetree

[Brüns , Stefan]

On Freitag, 22. September 2017 23:30:27 CEST Maxime Ripard wrote:
> On Tue, Sep 19, 2017 at 04:17:59PM +, Brüns, Stefan wrote:
> > On Dienstag, 19. September 2017 16:25:08 CEST Maxime Ripard wrote:
> > > On Mon, Sep 18, 2017 at 02:09:43PM +, Brüns, Stefan wrote:
> > > > On Montag, 18. September 2017 10:18:24 CEST you wrote:
> > > > > Hi,
> > > > > 
> > > > > On Sun, Sep 17, 2017 at 05:19:53AM +0200, Stefan Brüns wrote:
> > > > > > +   ret = of_property_read_u32(np, "dma-channels",
> > > > > > >num_pchans);
> > > > > > +   if (ret && !sdc->num_pchans) {
> > > > > > +   dev_err(>dev, "Can't get dma-channels.\n");
> > > > > > +   return ret;
> > > > > > +   }
> > > > > > +
> > > > > > +   if (sdc->num_pchans > DMA_MAX_CHANNELS) {
> > > > > > +   dev_err(>dev, "Number of dma-channels out of 
> > > > > > range.
\n");
> > > > > > +   return -EINVAL;
> > > > > > +   }
> > > > > > +
> > > > > > +   ret = of_property_read_u32(np, "dma-requests",
> > > > > > >max_request);
> > > > > > +   if (ret && !sdc->max_request) {
> > > > > > +   dev_info(>dev, "Missing dma-requests, using 
> > > > > > %u.\n",
> > > > > > +DMA_CHAN_MAX_DRQ);
> > > > > > +   sdc->max_request = DMA_CHAN_MAX_DRQ;
> > > > > > +   }
> > > > > > +
> > > > > > +   if (sdc->max_request > DMA_CHAN_MAX_DRQ) {
> > > > > > +   dev_err(>dev, "Value of dma-requests out of 
> > > > > > range.\n");
> > > > > > +   return -EINVAL;
> > > > > > +   }
> > > > > 
> > > > > I'm not really convinced about these two checks. They don't catch
> > > > > all
> > > > > errors (the range between the actual number of channels / DRQ and
> > > > > the
> > > > > maximum allowed per the registers), they might increase in the
> > > > > future
> > > > > too, and if we want to make that check actually working, we would
> > > > > have
> > > > > to duplicate the number of requests and channels into the driver.
> > > > 
> > > > 1. If these values increase, we have a new register layout and and
> > > > need a new compatible anyway.
> > > 
> > > And you want to store a new maximum attached to the compatible? Isn't
> > > that exactly the situation you're trying to get away from?
> > 
> > Yes, and no. H3, H5, A64 and R40 have the exact same register layout, but
> > different number of channels and ports. They could share a compatible (if
> > DMA channels were generalized), and we already have several register
> > offsets/ widths (implicitly via the callbacks) attached to the compatible
> > (so these don't need generalization via DT).
> > 
> > Now, we could also move everything that is currently attached to the
> > compatible, i.e. clock gate register offset, burst widths/lengths etc.
> > into
> > the devicetree binding, but that would just be too much.
> > 
> > The idea is to find a middle ground here, using common patterns in the
> > existing SoCs. The register layout has hardly changed, while the number of
> > DMA channels and ports changes all the time. Moving the number of DMA
> > channels and ports to the DT is trivial, and a pattern also found in
> > other DMA controller drivers.
> 
> I'm sorry, but the code is inconsistent here. You basically have two
> variables from one SoC to the other, the number of channels and
> requests.
> 
> In one case (channels), it mandates that the property is provided in
> the device tree, and doesn't default to anything.
> 
> In the other case (requests), the property is optional and it will
> provide a default. All that in 20 lines.

The channel number is a hardware property. Using more channels than the 
hardware provides is a bug. There is no default.

The port/request is just some lax property to limit the resource allocation 
upfront. As long as the bindings of the different IP blocks (SPI, audio, ...) 
provide the correct port numbers, all required information is available.
 
> I guess we already reached that middle ground by providing them
> through the DT, we just have to make sure we remain consistent.
> 
> > *If* the number of dma channels and ports is ever increased,
> > exceeding the current maximum, this would amount to major changes in
> > the driver and maybe even warrant a completely new driver.
> > 
> > > > 2. As long as the the limits are adhered to, no other
> > > > registers/register
> > > > fields are overwritten. As the channel number and port are used to
> > > > calculate memory offsets bounds checking is IMHO a good idea.
> > > 
> > > And this is true for many other resources, starting with the one
> > > defined in reg. We don't error check every register range, clock
> > > index, reset line, interrupt, DMA channel, the memory size, etc. yet
> > > you could make the same argument.
> > > 
> > > The DT has to be right, and we have to trust it. Otherwise we can just
> > > throw it away.
> > 
> > So your argument here basically is - don't do any checks on DT provided
> > values, these are always correct. So, following this argument, not 

Re: [PATCH v2 07/10] dmaengine: sun6i: Retrieve channel count/max request from devicetree

[Brüns , Stefan]

On Freitag, 22. September 2017 23:30:27 CEST Maxime Ripard wrote:
> On Tue, Sep 19, 2017 at 04:17:59PM +, Brüns, Stefan wrote:
> > On Dienstag, 19. September 2017 16:25:08 CEST Maxime Ripard wrote:
> > > On Mon, Sep 18, 2017 at 02:09:43PM +, Brüns, Stefan wrote:
> > > > On Montag, 18. September 2017 10:18:24 CEST you wrote:
> > > > > Hi,
> > > > > 
> > > > > On Sun, Sep 17, 2017 at 05:19:53AM +0200, Stefan Brüns wrote:
> > > > > > +   ret = of_property_read_u32(np, "dma-channels",
> > > > > > >num_pchans);
> > > > > > +   if (ret && !sdc->num_pchans) {
> > > > > > +   dev_err(>dev, "Can't get dma-channels.\n");
> > > > > > +   return ret;
> > > > > > +   }
> > > > > > +
> > > > > > +   if (sdc->num_pchans > DMA_MAX_CHANNELS) {
> > > > > > +   dev_err(>dev, "Number of dma-channels out of 
> > > > > > range.
\n");
> > > > > > +   return -EINVAL;
> > > > > > +   }
> > > > > > +
> > > > > > +   ret = of_property_read_u32(np, "dma-requests",
> > > > > > >max_request);
> > > > > > +   if (ret && !sdc->max_request) {
> > > > > > +   dev_info(>dev, "Missing dma-requests, using 
> > > > > > %u.\n",
> > > > > > +DMA_CHAN_MAX_DRQ);
> > > > > > +   sdc->max_request = DMA_CHAN_MAX_DRQ;
> > > > > > +   }
> > > > > > +
> > > > > > +   if (sdc->max_request > DMA_CHAN_MAX_DRQ) {
> > > > > > +   dev_err(>dev, "Value of dma-requests out of 
> > > > > > range.\n");
> > > > > > +   return -EINVAL;
> > > > > > +   }
> > > > > 
> > > > > I'm not really convinced about these two checks. They don't catch
> > > > > all
> > > > > errors (the range between the actual number of channels / DRQ and
> > > > > the
> > > > > maximum allowed per the registers), they might increase in the
> > > > > future
> > > > > too, and if we want to make that check actually working, we would
> > > > > have
> > > > > to duplicate the number of requests and channels into the driver.
> > > > 
> > > > 1. If these values increase, we have a new register layout and and
> > > > need a new compatible anyway.
> > > 
> > > And you want to store a new maximum attached to the compatible? Isn't
> > > that exactly the situation you're trying to get away from?
> > 
> > Yes, and no. H3, H5, A64 and R40 have the exact same register layout, but
> > different number of channels and ports. They could share a compatible (if
> > DMA channels were generalized), and we already have several register
> > offsets/ widths (implicitly via the callbacks) attached to the compatible
> > (so these don't need generalization via DT).
> > 
> > Now, we could also move everything that is currently attached to the
> > compatible, i.e. clock gate register offset, burst widths/lengths etc.
> > into
> > the devicetree binding, but that would just be too much.
> > 
> > The idea is to find a middle ground here, using common patterns in the
> > existing SoCs. The register layout has hardly changed, while the number of
> > DMA channels and ports changes all the time. Moving the number of DMA
> > channels and ports to the DT is trivial, and a pattern also found in
> > other DMA controller drivers.
> 
> I'm sorry, but the code is inconsistent here. You basically have two
> variables from one SoC to the other, the number of channels and
> requests.
> 
> In one case (channels), it mandates that the property is provided in
> the device tree, and doesn't default to anything.
> 
> In the other case (requests), the property is optional and it will
> provide a default. All that in 20 lines.

The channel number is a hardware property. Using more channels than the 
hardware provides is a bug. There is no default.

The port/request is just some lax property to limit the resource allocation 
upfront. As long as the bindings of the different IP blocks (SPI, audio, ...) 
provide the correct port numbers, all required information is available.
 
> I guess we already reached that middle ground by providing them
> through the DT, we just have to make sure we remain consistent.
> 
> > *If* the number of dma channels and ports is ever increased,
> > exceeding the current maximum, this would amount to major changes in
> > the driver and maybe even warrant a completely new driver.
> > 
> > > > 2. As long as the the limits are adhered to, no other
> > > > registers/register
> > > > fields are overwritten. As the channel number and port are used to
> > > > calculate memory offsets bounds checking is IMHO a good idea.
> > > 
> > > And this is true for many other resources, starting with the one
> > > defined in reg. We don't error check every register range, clock
> > > index, reset line, interrupt, DMA channel, the memory size, etc. yet
> > > you could make the same argument.
> > > 
> > > The DT has to be right, and we have to trust it. Otherwise we can just
> > > throw it away.
> > 
> > So your argument here basically is - don't do any checks on DT provided
> > values, these are always correct. So, following this argument, not 

Re: [PATCH] platform/x86: intel-hid: Power button suspend on Dell Latitude 7275

[Darren Hart]

On Mon, Sep 18, 2017 at 12:57:12AM +0200, Jérôme de Bretagne wrote:
> From: Jérôme de Bretagne 
> 
> On Dell Latitude 7275 the 5-button array is not exposed in the
> ACPI tables, but still notifies are sent to the Intel HID device
> object (device ID INT33D5) in response to power button actions.
> They were ignored as the intel-hid driver was not prepared to
> take care of them until recently.
> 
> Power button wakeup from suspend-to-idle was added in:
> 635173a17b03 ("intel-hid: Wake up Dell Latitude 7275 from
> suspend-to-idle"). However power button suspend doesn't work
> yet on this platform so it would be good to add it also.
> 
> On the affected platform (for which priv->array is NULL), add
> a new upfront check against the power button press notification
> (0xCE) to notify_handler(), outside the wakeup mode this time,
> which allows to report the power button press event and
> trigger the suspend. Also catch and ignore the corresponding
> power button release notification (0xCF) to stop it from being
> reported as an "unknown event" in the logs.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=196115
> Tested-by: Jérôme de Bretagne 
> Signed-off-by: Jérôme de Bretagne 
> ---
>  drivers/platform/x86/intel-hid.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/platform/x86/intel-hid.c 
> b/drivers/platform/x86/intel-hid.c
> index a782c78e7c63..b19f8dcf9d8c 100644
> --- a/drivers/platform/x86/intel-hid.c
> +++ b/drivers/platform/x86/intel-hid.c
> @@ -226,6 +226,22 @@ static void notify_handler(acpi_handle handle, u32 
> event, void *context)
>   return;
>   }
>  
> + /*
> +  * Needed for suspend to work on some platforms that don't expose
> +  * the 5-button array, but still send notifies with power button
> +  * event code to this device object on power button actions.
> +  *
> +  * Report the power button press; catch and ignore the button release.
> +  */
> + if (!priv->array) {
> + if (event == 0xce) {
> + input_report_key(priv->input_dev, KEY_POWER, 1);
> + input_sync(priv->input_dev);
> + return;
> + } else if (event == 0xcf)
> + return;

Minor CodingStyle nit. If the if block uses parens, so does the else block. In
this case, since the if returns, just skip the else entirely.

See Documentation/process/coding-style.rst
The example immediatley *before* 3.1) Spaces.

I've made this change and queued for testing.

> + }
> +
>   /* 0xC0 is for HID events, other values are for 5 button array */
>   if (event != 0xc0) {
>   if (!priv->array ||
> 

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH] platform/x86: intel-hid: Power button suspend on Dell Latitude 7275

[Darren Hart]

On Mon, Sep 18, 2017 at 12:57:12AM +0200, Jérôme de Bretagne wrote:
> From: Jérôme de Bretagne 
> 
> On Dell Latitude 7275 the 5-button array is not exposed in the
> ACPI tables, but still notifies are sent to the Intel HID device
> object (device ID INT33D5) in response to power button actions.
> They were ignored as the intel-hid driver was not prepared to
> take care of them until recently.
> 
> Power button wakeup from suspend-to-idle was added in:
> 635173a17b03 ("intel-hid: Wake up Dell Latitude 7275 from
> suspend-to-idle"). However power button suspend doesn't work
> yet on this platform so it would be good to add it also.
> 
> On the affected platform (for which priv->array is NULL), add
> a new upfront check against the power button press notification
> (0xCE) to notify_handler(), outside the wakeup mode this time,
> which allows to report the power button press event and
> trigger the suspend. Also catch and ignore the corresponding
> power button release notification (0xCF) to stop it from being
> reported as an "unknown event" in the logs.
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=196115
> Tested-by: Jérôme de Bretagne 
> Signed-off-by: Jérôme de Bretagne 
> ---
>  drivers/platform/x86/intel-hid.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/drivers/platform/x86/intel-hid.c 
> b/drivers/platform/x86/intel-hid.c
> index a782c78e7c63..b19f8dcf9d8c 100644
> --- a/drivers/platform/x86/intel-hid.c
> +++ b/drivers/platform/x86/intel-hid.c
> @@ -226,6 +226,22 @@ static void notify_handler(acpi_handle handle, u32 
> event, void *context)
>   return;
>   }
>  
> + /*
> +  * Needed for suspend to work on some platforms that don't expose
> +  * the 5-button array, but still send notifies with power button
> +  * event code to this device object on power button actions.
> +  *
> +  * Report the power button press; catch and ignore the button release.
> +  */
> + if (!priv->array) {
> + if (event == 0xce) {
> + input_report_key(priv->input_dev, KEY_POWER, 1);
> + input_sync(priv->input_dev);
> + return;
> + } else if (event == 0xcf)
> + return;

Minor CodingStyle nit. If the if block uses parens, so does the else block. In
this case, since the if returns, just skip the else entirely.

See Documentation/process/coding-style.rst
The example immediatley *before* 3.1) Spaces.

I've made this change and queued for testing.

> + }
> +
>   /* 0xC0 is for HID events, other values are for 5 button array */
>   if (event != 0xc0) {
>   if (!priv->array ||
> 

-- 
Darren Hart
VMware Open Source Technology Center

Re: [PATCH v2 1/6] gpu: host1x: Enable Tegra186 syncpoint protection

[Dmitry Osipenko]

On 22.09.2017 17:02, Mikko Perttunen wrote:
> On 09/05/2017 04:33 PM, Dmitry Osipenko wrote:
>> On 05.09.2017 11:10, Mikko Perttunen wrote:
>>> ... >> diff --git a/drivers/gpu/host1x/hw/channel_hw.c 
> b/drivers/gpu/host1x/hw/channel_hw.c
>>> index 8447a56c41ca..0161da331702 100644
>>> --- a/drivers/gpu/host1x/hw/channel_hw.c
>>> +++ b/drivers/gpu/host1x/hw/channel_hw.c
>>> @@ -147,6 +147,9 @@ static int channel_submit(struct host1x_job *job)
>>>     syncval = host1x_syncpt_incr_max(sp, user_syncpt_incrs);
>>>   +    /* assign syncpoint to channel */
>>> +    host1x_hw_syncpt_assign_channel(host, sp, ch);
>>
>> This function could be renamed to host1x_hw_assign_syncpt_to_channel() and 
>> then
>> comment to it won't be needed.
> 
> Maybe host1x_hw_syncpt_assign_to_channel? I'd like to keep the current 
> noun_verb
> format. Though IMHO even the current name is pretty descriptive in itself.
> 

That variant sounds good to me as well.

>>
>> It is not very nice that channel would be re-assigned on each submit. Maybe 
>> that
>> assignment should be done by host1x_syncpt_request() ?
> 
> host1x_syncpt_request doesn't know about the channel so we'd have to thread 
> this
> information there and through each client driver in drm/tegra/, so I decided 
> not
> to do this at this time. I'm planning a new channel allocation model which 
> will
> change that side of the code anyway, so I'd like to revisit this at that 
> point.
> For our current channel model, the current implementation doesn't have any
> functional downsides anyway.
> 

Another very minor downside is that it causes an extra dummy invocation on
pre-Tegra186. Of course that could be changed later in a follow-up patch, not a
big deal :)

>>
>>> +
>>>   job->syncpt_end = syncval;
>>>     /* add a setclass for modules that require it */
>>> diff --git a/drivers/gpu/host1x/hw/syncpt_hw.c
>>> b/drivers/gpu/host1x/hw/syncpt_hw.c
>>> index 7b0270d60742..dc7a44614fef 100644
>>> --- a/drivers/gpu/host1x/hw/syncpt_hw.c
>>> +++ b/drivers/gpu/host1x/hw/syncpt_hw.c
>>> @@ -106,6 +106,50 @@ static int syncpt_patch_wait(struct host1x_syncpt *sp,
>>> void *patch_addr)
>>>   return 0;
>>>   }
>>>   +/**
>>> + * syncpt_assign_channel() - Assign syncpoint to channel
>>> + * @sp: syncpoint
>>> + * @ch: channel
>>> + *
>>> + * On chips with the syncpoint protection feature (Tegra186+), assign @sp 
>>> to
>>> + * @ch, preventing other channels from incrementing the syncpoints. If @ch 
>>> is
>>> + * NULL, unassigns the syncpoint.
>>> + *
>>> + * On older chips, do nothing.
>>> + */
>>> +static void syncpt_assign_channel(struct host1x_syncpt *sp,
>>> +  struct host1x_channel *ch)
>>> +{
>>> +#if HOST1X_HW >= 6
>>> +    struct host1x *host = sp->host;
>>> +
>>> +    if (!host->hv_regs)
>>> +    return;
>>> +
>>> +    host1x_sync_writel(host,
>>> +   HOST1X_SYNC_SYNCPT_CH_APP_CH(ch ? ch->id : 0xff),
>>> +   HOST1X_SYNC_SYNCPT_CH_APP(sp->id));
>>> +#endif
>>> +}
>>> +
>>> +/**
>>> + * syncpt_enable_protection() - Enable syncpoint protection
>>> + * @host: host1x instance
>>> + *
>>> + * On chips with the syncpoint protection feature (Tegra186+), enable this
>>> + * feature. On older chips, do nothing.
>>> + */
>>> +static void syncpt_enable_protection(struct host1x *host)
>>> +{
>>> +#if HOST1X_HW >= 6
>>> +    if (!host->hv_regs)
>>> +    return;
>>> +
>>> +    host1x_hypervisor_writel(host, HOST1X_HV_SYNCPT_PROT_EN_CH_EN,
>>> + HOST1X_HV_SYNCPT_PROT_EN);
>>> +#endif
>>> +}
>>> +
>>>   static const struct host1x_syncpt_ops host1x_syncpt_ops = {
>>>   .restore = syncpt_restore,
>>>   .restore_wait_base = syncpt_restore_wait_base,
>>> @@ -113,4 +157,6 @@ static const struct host1x_syncpt_ops host1x_syncpt_ops 
>>> = {
>>>   .load = syncpt_load,
>>>   .cpu_incr = syncpt_cpu_incr,
>>>   .patch_wait = syncpt_patch_wait,
>>> +    .assign_channel = syncpt_assign_channel,
>>> +    .enable_protection = syncpt_enable_protection,
>>>   };
>>> diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c
>>> index 048ac9e344ce..4c7a4c8b2ad2 100644
>>> --- a/drivers/gpu/host1x/syncpt.c
>>> +++ b/drivers/gpu/host1x/syncpt.c
>>> @@ -398,6 +398,13 @@ int host1x_syncpt_init(struct host1x *host)
>>>   for (i = 0; i < host->info->nb_pts; i++) {
>>>   syncpt[i].id = i;
>>>   syncpt[i].host = host;
>>> +
>>> +    /*
>>> + * Unassign syncpt from channels for purposes of Tegra186
>>> + * syncpoint protection. This prevents any channel from
>>> + * accessing it until it is reassigned.
>>> + */
>>> +    host1x_hw_syncpt_assign_channel(host, [i], NULL);
>>>   }
>>>     for (i = 0; i < host->info->nb_bases; i++)
>>> @@ -408,6 +415,7 @@ int host1x_syncpt_init(struct host1x *host)
>>>   host->bases = bases;
>>>     host1x_syncpt_restore(host);
>>> +    host1x_hw_syncpt_enable_protection(host);
>>>     /* Allocate 

Re: [PATCH v2 1/6] gpu: host1x: Enable Tegra186 syncpoint protection

[Dmitry Osipenko]

On 22.09.2017 17:02, Mikko Perttunen wrote:
> On 09/05/2017 04:33 PM, Dmitry Osipenko wrote:
>> On 05.09.2017 11:10, Mikko Perttunen wrote:
>>> ... >> diff --git a/drivers/gpu/host1x/hw/channel_hw.c 
> b/drivers/gpu/host1x/hw/channel_hw.c
>>> index 8447a56c41ca..0161da331702 100644
>>> --- a/drivers/gpu/host1x/hw/channel_hw.c
>>> +++ b/drivers/gpu/host1x/hw/channel_hw.c
>>> @@ -147,6 +147,9 @@ static int channel_submit(struct host1x_job *job)
>>>     syncval = host1x_syncpt_incr_max(sp, user_syncpt_incrs);
>>>   +    /* assign syncpoint to channel */
>>> +    host1x_hw_syncpt_assign_channel(host, sp, ch);
>>
>> This function could be renamed to host1x_hw_assign_syncpt_to_channel() and 
>> then
>> comment to it won't be needed.
> 
> Maybe host1x_hw_syncpt_assign_to_channel? I'd like to keep the current 
> noun_verb
> format. Though IMHO even the current name is pretty descriptive in itself.
> 

That variant sounds good to me as well.

>>
>> It is not very nice that channel would be re-assigned on each submit. Maybe 
>> that
>> assignment should be done by host1x_syncpt_request() ?
> 
> host1x_syncpt_request doesn't know about the channel so we'd have to thread 
> this
> information there and through each client driver in drm/tegra/, so I decided 
> not
> to do this at this time. I'm planning a new channel allocation model which 
> will
> change that side of the code anyway, so I'd like to revisit this at that 
> point.
> For our current channel model, the current implementation doesn't have any
> functional downsides anyway.
> 

Another very minor downside is that it causes an extra dummy invocation on
pre-Tegra186. Of course that could be changed later in a follow-up patch, not a
big deal :)

>>
>>> +
>>>   job->syncpt_end = syncval;
>>>     /* add a setclass for modules that require it */
>>> diff --git a/drivers/gpu/host1x/hw/syncpt_hw.c
>>> b/drivers/gpu/host1x/hw/syncpt_hw.c
>>> index 7b0270d60742..dc7a44614fef 100644
>>> --- a/drivers/gpu/host1x/hw/syncpt_hw.c
>>> +++ b/drivers/gpu/host1x/hw/syncpt_hw.c
>>> @@ -106,6 +106,50 @@ static int syncpt_patch_wait(struct host1x_syncpt *sp,
>>> void *patch_addr)
>>>   return 0;
>>>   }
>>>   +/**
>>> + * syncpt_assign_channel() - Assign syncpoint to channel
>>> + * @sp: syncpoint
>>> + * @ch: channel
>>> + *
>>> + * On chips with the syncpoint protection feature (Tegra186+), assign @sp 
>>> to
>>> + * @ch, preventing other channels from incrementing the syncpoints. If @ch 
>>> is
>>> + * NULL, unassigns the syncpoint.
>>> + *
>>> + * On older chips, do nothing.
>>> + */
>>> +static void syncpt_assign_channel(struct host1x_syncpt *sp,
>>> +  struct host1x_channel *ch)
>>> +{
>>> +#if HOST1X_HW >= 6
>>> +    struct host1x *host = sp->host;
>>> +
>>> +    if (!host->hv_regs)
>>> +    return;
>>> +
>>> +    host1x_sync_writel(host,
>>> +   HOST1X_SYNC_SYNCPT_CH_APP_CH(ch ? ch->id : 0xff),
>>> +   HOST1X_SYNC_SYNCPT_CH_APP(sp->id));
>>> +#endif
>>> +}
>>> +
>>> +/**
>>> + * syncpt_enable_protection() - Enable syncpoint protection
>>> + * @host: host1x instance
>>> + *
>>> + * On chips with the syncpoint protection feature (Tegra186+), enable this
>>> + * feature. On older chips, do nothing.
>>> + */
>>> +static void syncpt_enable_protection(struct host1x *host)
>>> +{
>>> +#if HOST1X_HW >= 6
>>> +    if (!host->hv_regs)
>>> +    return;
>>> +
>>> +    host1x_hypervisor_writel(host, HOST1X_HV_SYNCPT_PROT_EN_CH_EN,
>>> + HOST1X_HV_SYNCPT_PROT_EN);
>>> +#endif
>>> +}
>>> +
>>>   static const struct host1x_syncpt_ops host1x_syncpt_ops = {
>>>   .restore = syncpt_restore,
>>>   .restore_wait_base = syncpt_restore_wait_base,
>>> @@ -113,4 +157,6 @@ static const struct host1x_syncpt_ops host1x_syncpt_ops 
>>> = {
>>>   .load = syncpt_load,
>>>   .cpu_incr = syncpt_cpu_incr,
>>>   .patch_wait = syncpt_patch_wait,
>>> +    .assign_channel = syncpt_assign_channel,
>>> +    .enable_protection = syncpt_enable_protection,
>>>   };
>>> diff --git a/drivers/gpu/host1x/syncpt.c b/drivers/gpu/host1x/syncpt.c
>>> index 048ac9e344ce..4c7a4c8b2ad2 100644
>>> --- a/drivers/gpu/host1x/syncpt.c
>>> +++ b/drivers/gpu/host1x/syncpt.c
>>> @@ -398,6 +398,13 @@ int host1x_syncpt_init(struct host1x *host)
>>>   for (i = 0; i < host->info->nb_pts; i++) {
>>>   syncpt[i].id = i;
>>>   syncpt[i].host = host;
>>> +
>>> +    /*
>>> + * Unassign syncpt from channels for purposes of Tegra186
>>> + * syncpoint protection. This prevents any channel from
>>> + * accessing it until it is reassigned.
>>> + */
>>> +    host1x_hw_syncpt_assign_channel(host, [i], NULL);
>>>   }
>>>     for (i = 0; i < host->info->nb_bases; i++)
>>> @@ -408,6 +415,7 @@ int host1x_syncpt_init(struct host1x *host)
>>>   host->bases = bases;
>>>     host1x_syncpt_restore(host);
>>> +    host1x_hw_syncpt_enable_protection(host);
>>>     /* Allocate 

[GIT PULL] ACPI fixes for v4.14-rc2

[Rafael J. Wysocki]

Hi Linus,

Please pull from the tag

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 acpi-4.14-rc2

with top-most commit 672d0e4502a22364b298f9307f651c1b8313514b

 Merge branches 'acpi-pmic', 'acpi-bus', 'acpi-wdat' and 'acpi-properties'

on top of commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e

 Linux 4.14-rc1

to receive ACPI fixes for v4.14-rc2.

These fix the initialization of resources in the ACPI WDAT watchdog
driver, a recent regression in the ACPI device properties handling,
a recent change in behavior causing the ACPI_HANDLE() macro to only
work for GPL code and create a MAINTAINERS entry for ACPI PMIC
drivers in order to specify the official reviewers for that code.

Specifics:

 - Fix the initialization of resources in the ACPI WDAT watchdog
   driver that uses unititialized memory which causes compiler
   warnings to be triggered (Arnd Bergmann).

 - Fix a recent regression in the ACPI device properties handling
   that causes some device properties data to be skipped during
   enumeration (Sakari Ailus).

 - Fix a recent change in behavior that caused the ACPI_HANDLE()
   macro to stop working for non-GPL code which is a problem for
   the NVidia binary graphics driver, for example (John Hubbard).

 - Add a MAINTAINERS entry for the ACPI PMIC drivers to specify
   the official reviewers for that code (Rafael Wysocki).

Thanks!


---

Arnd Bergmann (1):
  ACPI / watchdog: properly initialize resources

John Hubbard (1):
  ACPI / bus: Make ACPI_HANDLE() work for non-GPL code again

Rafael Wysocki (1):
  ACPI / PMIC: Add code reviewers to MAINTAINERS

Sakari Ailus (1):
  ACPI: properties: Return _DSD hierarchical extension (data)
sub-nodes correctly

---

 MAINTAINERS  | 12 
 drivers/acpi/acpi_watchdog.c |  2 +-
 drivers/acpi/property.c  | 24 +++-
 include/acpi/acpi_bus.h  | 18 --
 4 files changed, 36 insertions(+), 20 deletions(-)

[GIT PULL] ACPI fixes for v4.14-rc2

[Rafael J. Wysocki]

Hi Linus,

Please pull from the tag

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 acpi-4.14-rc2

with top-most commit 672d0e4502a22364b298f9307f651c1b8313514b

 Merge branches 'acpi-pmic', 'acpi-bus', 'acpi-wdat' and 'acpi-properties'

on top of commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e

 Linux 4.14-rc1

to receive ACPI fixes for v4.14-rc2.

These fix the initialization of resources in the ACPI WDAT watchdog
driver, a recent regression in the ACPI device properties handling,
a recent change in behavior causing the ACPI_HANDLE() macro to only
work for GPL code and create a MAINTAINERS entry for ACPI PMIC
drivers in order to specify the official reviewers for that code.

Specifics:

 - Fix the initialization of resources in the ACPI WDAT watchdog
   driver that uses unititialized memory which causes compiler
   warnings to be triggered (Arnd Bergmann).

 - Fix a recent regression in the ACPI device properties handling
   that causes some device properties data to be skipped during
   enumeration (Sakari Ailus).

 - Fix a recent change in behavior that caused the ACPI_HANDLE()
   macro to stop working for non-GPL code which is a problem for
   the NVidia binary graphics driver, for example (John Hubbard).

 - Add a MAINTAINERS entry for the ACPI PMIC drivers to specify
   the official reviewers for that code (Rafael Wysocki).

Thanks!


---

Arnd Bergmann (1):
  ACPI / watchdog: properly initialize resources

John Hubbard (1):
  ACPI / bus: Make ACPI_HANDLE() work for non-GPL code again

Rafael Wysocki (1):
  ACPI / PMIC: Add code reviewers to MAINTAINERS

Sakari Ailus (1):
  ACPI: properties: Return _DSD hierarchical extension (data)
sub-nodes correctly

---

 MAINTAINERS  | 12 
 drivers/acpi/acpi_watchdog.c |  2 +-
 drivers/acpi/property.c  | 24 +++-
 include/acpi/acpi_bus.h  | 18 --
 4 files changed, 36 insertions(+), 20 deletions(-)

Re: [PATCH] mm: madvise: add description for MADV_WIPEONFORK and MADV_KEEPONFORK

[Rik van Riel]

On Sat, 2017-09-23 at 05:55 +0800, Yang Shi wrote:
> mm/madvise.c has the brief description about all MADV_ flags, added
> the
> description for the newly added MADV_WIPEONFORK and MADV_KEEPONFORK.
> 
> Although man page has the similar information, but it'd better to
> keep the
> consistency with other flags.
> 
> Signed-off-by: Yang Shi 
> 
Thank you for spotting that I missed a location!

Reviewed-by: Rik van Riel 

Re: [PATCH] mm: madvise: add description for MADV_WIPEONFORK and MADV_KEEPONFORK

[Rik van Riel]

On Sat, 2017-09-23 at 05:55 +0800, Yang Shi wrote:
> mm/madvise.c has the brief description about all MADV_ flags, added
> the
> description for the newly added MADV_WIPEONFORK and MADV_KEEPONFORK.
> 
> Although man page has the similar information, but it'd better to
> keep the
> consistency with other flags.
> 
> Signed-off-by: Yang Shi 
> 
Thank you for spotting that I missed a location!

Reviewed-by: Rik van Riel 

[GIT PULL] Power management fixes for v4.14-rc2

[Rafael J. Wysocki]

Hi Linus,

Please pull from the tag

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pm-4.14-rc2

with top-most commit d84c97f8f77bc4124256e76864f125f45ad53744

 Merge branches 'pm-cpufreq' and 'pm-cpuidle'

on top of commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e

 Linux 4.14-rc1

to receive power management fixes for v4.14-rc2.

These fix a cpufreq regression introduced by recent changes related
to the generic DT driver, an initialization time memory leak in
cpuidle on ARM, a PM core bug that may cause system suspend/resume
to fail on some systems, a request type validation issue in the PM
QoS framework and two documentation-related issues.

Specifics:

 - Fix a regression in cpufreq on systems using DT as the source of
   CPU configuration information where two different code paths
   attempt to create the cpufreq-dt device object (there can be only
   one) and fix up the "compatible" matching for some TI platforms
   on top of that (Viresh Kumar, Dave Gerlach).

 - Fix an initialization time memory leak in cpuidle on ARM which
   occurs if the cpuidle driver initialization fails (Stefan Wahren).

 - Fix a PM core function that checks whether or not there are any
   system suspend/resume callbacks for a device, but forgets to
   check legacy callbacks which then may be skipped incorrectly
   and the system may crash and/or the device may become unusable
   after a suspend-resume cycle (Rafael Wysocki).

 - Fix request type validation for latency tolerance PM QoS requests
   which may lead to unexpected behavior (Jan Schönherr).

 - Fix a broken link to PM documentation from a header file and a
   typo in a PM document (Geert Uytterhoeven, Rafael Wysocki).

Thanks!


---

Dave Gerlach (1):
  cpufreq: ti-cpufreq: Support additional am43xx platforms

Geert Uytterhoeven (1):
  driver core: Fix link to device power management documentation

Jan H. Schönherr (1):
  PM / QoS: Use the correct variable to check the QoS request type

Rafael J. Wysocki (2):
  PM: docs: Drop an excess character from devices.rst
  PM: core: Fix device_pm_check_callbacks()

Stefan Wahren (1):
  ARM: cpuidle: Avoid memleak if init fail

Viresh Kumar (1):
  cpufreq: dt-platdev: Add some missing platforms to the blacklist

---

 Documentation/driver-api/pm/devices.rst |  2 +-
 drivers/base/power/main.c   |  9 ++---
 drivers/base/power/qos.c| 10 +-
 drivers/cpufreq/cpufreq-dt-platdev.c| 12 
 drivers/cpufreq/ti-cpufreq.c|  2 +-
 drivers/cpuidle/cpuidle-arm.c   |  6 --
 include/linux/device.h  |  2 +-
 7 files changed, 30 insertions(+), 13 deletions(-)

[GIT PULL] Power management fixes for v4.14-rc2

[Rafael J. Wysocki]

Hi Linus,

Please pull from the tag

 git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm.git \
 pm-4.14-rc2

with top-most commit d84c97f8f77bc4124256e76864f125f45ad53744

 Merge branches 'pm-cpufreq' and 'pm-cpuidle'

on top of commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e

 Linux 4.14-rc1

to receive power management fixes for v4.14-rc2.

These fix a cpufreq regression introduced by recent changes related
to the generic DT driver, an initialization time memory leak in
cpuidle on ARM, a PM core bug that may cause system suspend/resume
to fail on some systems, a request type validation issue in the PM
QoS framework and two documentation-related issues.

Specifics:

 - Fix a regression in cpufreq on systems using DT as the source of
   CPU configuration information where two different code paths
   attempt to create the cpufreq-dt device object (there can be only
   one) and fix up the "compatible" matching for some TI platforms
   on top of that (Viresh Kumar, Dave Gerlach).

 - Fix an initialization time memory leak in cpuidle on ARM which
   occurs if the cpuidle driver initialization fails (Stefan Wahren).

 - Fix a PM core function that checks whether or not there are any
   system suspend/resume callbacks for a device, but forgets to
   check legacy callbacks which then may be skipped incorrectly
   and the system may crash and/or the device may become unusable
   after a suspend-resume cycle (Rafael Wysocki).

 - Fix request type validation for latency tolerance PM QoS requests
   which may lead to unexpected behavior (Jan Schönherr).

 - Fix a broken link to PM documentation from a header file and a
   typo in a PM document (Geert Uytterhoeven, Rafael Wysocki).

Thanks!


---

Dave Gerlach (1):
  cpufreq: ti-cpufreq: Support additional am43xx platforms

Geert Uytterhoeven (1):
  driver core: Fix link to device power management documentation

Jan H. Schönherr (1):
  PM / QoS: Use the correct variable to check the QoS request type

Rafael J. Wysocki (2):
  PM: docs: Drop an excess character from devices.rst
  PM: core: Fix device_pm_check_callbacks()

Stefan Wahren (1):
  ARM: cpuidle: Avoid memleak if init fail

Viresh Kumar (1):
  cpufreq: dt-platdev: Add some missing platforms to the blacklist

---

 Documentation/driver-api/pm/devices.rst |  2 +-
 drivers/base/power/main.c   |  9 ++---
 drivers/base/power/qos.c| 10 +-
 drivers/cpufreq/cpufreq-dt-platdev.c| 12 
 drivers/cpufreq/ti-cpufreq.c|  2 +-
 drivers/cpuidle/cpuidle-arm.c   |  6 --
 include/linux/device.h  |  2 +-
 7 files changed, 30 insertions(+), 13 deletions(-)

[PATCH net-next v3 1/2] net: dsa: make slave close symmetrical to open

[Vivien Didelot]

The DSA slave open function configures the unicast MAC addresses on the
master device, enable the switch port, change its STP state, then start
the PHY device.

Make the close function symmetric, by first stopping the PHY device,
then changing the STP state, disabling the switch port and restore the
master device.

Signed-off-by: Vivien Didelot 
Reviewed-by: Florian Fainelli 
Reviewed-by: Andrew Lunn 
---
 net/dsa/slave.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 02ace7d462c4..c2bb48579032 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -133,6 +133,11 @@ static int dsa_slave_close(struct net_device *dev)
if (p->phy)
phy_stop(p->phy);
 
+   dsa_port_set_state_now(p->dp, BR_STATE_DISABLED);
+
+   if (ds->ops->port_disable)
+   ds->ops->port_disable(ds, p->dp->index, p->phy);
+
dev_mc_unsync(master, dev);
dev_uc_unsync(master, dev);
if (dev->flags & IFF_ALLMULTI)
@@ -143,11 +148,6 @@ static int dsa_slave_close(struct net_device *dev)
if (!ether_addr_equal(dev->dev_addr, master->dev_addr))
dev_uc_del(master, dev->dev_addr);
 
-   if (ds->ops->port_disable)
-   ds->ops->port_disable(ds, p->dp->index, p->phy);
-
-   dsa_port_set_state_now(p->dp, BR_STATE_DISABLED);
-
return 0;
 }
 
-- 
2.14.1

[PATCH net-next v3 1/2] net: dsa: make slave close symmetrical to open

[Vivien Didelot]

The DSA slave open function configures the unicast MAC addresses on the
master device, enable the switch port, change its STP state, then start
the PHY device.

Make the close function symmetric, by first stopping the PHY device,
then changing the STP state, disabling the switch port and restore the
master device.

Signed-off-by: Vivien Didelot 
Reviewed-by: Florian Fainelli 
Reviewed-by: Andrew Lunn 
---
 net/dsa/slave.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index 02ace7d462c4..c2bb48579032 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -133,6 +133,11 @@ static int dsa_slave_close(struct net_device *dev)
if (p->phy)
phy_stop(p->phy);
 
+   dsa_port_set_state_now(p->dp, BR_STATE_DISABLED);
+
+   if (ds->ops->port_disable)
+   ds->ops->port_disable(ds, p->dp->index, p->phy);
+
dev_mc_unsync(master, dev);
dev_uc_unsync(master, dev);
if (dev->flags & IFF_ALLMULTI)
@@ -143,11 +148,6 @@ static int dsa_slave_close(struct net_device *dev)
if (!ether_addr_equal(dev->dev_addr, master->dev_addr))
dev_uc_del(master, dev->dev_addr);
 
-   if (ds->ops->port_disable)
-   ds->ops->port_disable(ds, p->dp->index, p->phy);
-
-   dsa_port_set_state_now(p->dp, BR_STATE_DISABLED);
-
return 0;
 }
 
-- 
2.14.1

[PATCH net-next v3 2/2] net: dsa: add port enable and disable helpers

[Vivien Didelot]

Provide dsa_port_enable and dsa_port_disable helpers to respectively
enable and disable a switch port. This makes the dsa_port_set_state_now
helper static.

Signed-off-by: Vivien Didelot 
Reviewed-by: Florian Fainelli 
Reviewed-by: Andrew Lunn 
---
 net/dsa/dsa_priv.h |  3 ++-
 net/dsa/port.c | 31 ++-
 net/dsa/slave.c| 19 +--
 3 files changed, 37 insertions(+), 16 deletions(-)

diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index 9803952a5b40..0298a0f6a349 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -117,7 +117,8 @@ void dsa_master_ethtool_restore(struct net_device *dev);
 /* port.c */
 int dsa_port_set_state(struct dsa_port *dp, u8 state,
   struct switchdev_trans *trans);
-void dsa_port_set_state_now(struct dsa_port *dp, u8 state);
+int dsa_port_enable(struct dsa_port *dp, struct phy_device *phy);
+void dsa_port_disable(struct dsa_port *dp, struct phy_device *phy);
 int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br);
 void dsa_port_bridge_leave(struct dsa_port *dp, struct net_device *br);
 int dsa_port_vlan_filtering(struct dsa_port *dp, bool vlan_filtering,
diff --git a/net/dsa/port.c b/net/dsa/port.c
index 76d43a82d397..72c8dbd3d3f2 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -56,7 +56,7 @@ int dsa_port_set_state(struct dsa_port *dp, u8 state,
return 0;
 }
 
-void dsa_port_set_state_now(struct dsa_port *dp, u8 state)
+static void dsa_port_set_state_now(struct dsa_port *dp, u8 state)
 {
int err;
 
@@ -65,6 +65,35 @@ void dsa_port_set_state_now(struct dsa_port *dp, u8 state)
pr_err("DSA: failed to set STP state %u (%d)\n", state, err);
 }
 
+int dsa_port_enable(struct dsa_port *dp, struct phy_device *phy)
+{
+   u8 stp_state = dp->bridge_dev ? BR_STATE_BLOCKING : BR_STATE_FORWARDING;
+   struct dsa_switch *ds = dp->ds;
+   int port = dp->index;
+   int err;
+
+   if (ds->ops->port_enable) {
+   err = ds->ops->port_enable(ds, port, phy);
+   if (err)
+   return err;
+   }
+
+   dsa_port_set_state_now(dp, stp_state);
+
+   return 0;
+}
+
+void dsa_port_disable(struct dsa_port *dp, struct phy_device *phy)
+{
+   struct dsa_switch *ds = dp->ds;
+   int port = dp->index;
+
+   dsa_port_set_state_now(dp, BR_STATE_DISABLED);
+
+   if (ds->ops->port_disable)
+   ds->ops->port_disable(ds, port, phy);
+}
+
 int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br)
 {
struct dsa_notifier_bridge_info info = {
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index c2bb48579032..bd51ef56ec5b 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -73,9 +73,7 @@ static int dsa_slave_open(struct net_device *dev)
 {
struct dsa_slave_priv *p = netdev_priv(dev);
struct dsa_port *dp = p->dp;
-   struct dsa_switch *ds = dp->ds;
struct net_device *master = dsa_master_netdev(p);
-   u8 stp_state = dp->bridge_dev ? BR_STATE_BLOCKING : BR_STATE_FORWARDING;
int err;
 
if (!(master->flags & IFF_UP))
@@ -98,13 +96,9 @@ static int dsa_slave_open(struct net_device *dev)
goto clear_allmulti;
}
 
-   if (ds->ops->port_enable) {
-   err = ds->ops->port_enable(ds, p->dp->index, p->phy);
-   if (err)
-   goto clear_promisc;
-   }
-
-   dsa_port_set_state_now(p->dp, stp_state);
+   err = dsa_port_enable(dp, p->phy);
+   if (err)
+   goto clear_promisc;
 
if (p->phy)
phy_start(p->phy);
@@ -128,15 +122,12 @@ static int dsa_slave_close(struct net_device *dev)
 {
struct dsa_slave_priv *p = netdev_priv(dev);
struct net_device *master = dsa_master_netdev(p);
-   struct dsa_switch *ds = p->dp->ds;
+   struct dsa_port *dp = p->dp;
 
if (p->phy)
phy_stop(p->phy);
 
-   dsa_port_set_state_now(p->dp, BR_STATE_DISABLED);
-
-   if (ds->ops->port_disable)
-   ds->ops->port_disable(ds, p->dp->index, p->phy);
+   dsa_port_disable(dp, p->phy);
 
dev_mc_unsync(master, dev);
dev_uc_unsync(master, dev);
-- 
2.14.1

[PATCH net-next v3 2/2] net: dsa: add port enable and disable helpers

[Vivien Didelot]

Provide dsa_port_enable and dsa_port_disable helpers to respectively
enable and disable a switch port. This makes the dsa_port_set_state_now
helper static.

Signed-off-by: Vivien Didelot 
Reviewed-by: Florian Fainelli 
Reviewed-by: Andrew Lunn 
---
 net/dsa/dsa_priv.h |  3 ++-
 net/dsa/port.c | 31 ++-
 net/dsa/slave.c| 19 +--
 3 files changed, 37 insertions(+), 16 deletions(-)

diff --git a/net/dsa/dsa_priv.h b/net/dsa/dsa_priv.h
index 9803952a5b40..0298a0f6a349 100644
--- a/net/dsa/dsa_priv.h
+++ b/net/dsa/dsa_priv.h
@@ -117,7 +117,8 @@ void dsa_master_ethtool_restore(struct net_device *dev);
 /* port.c */
 int dsa_port_set_state(struct dsa_port *dp, u8 state,
   struct switchdev_trans *trans);
-void dsa_port_set_state_now(struct dsa_port *dp, u8 state);
+int dsa_port_enable(struct dsa_port *dp, struct phy_device *phy);
+void dsa_port_disable(struct dsa_port *dp, struct phy_device *phy);
 int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br);
 void dsa_port_bridge_leave(struct dsa_port *dp, struct net_device *br);
 int dsa_port_vlan_filtering(struct dsa_port *dp, bool vlan_filtering,
diff --git a/net/dsa/port.c b/net/dsa/port.c
index 76d43a82d397..72c8dbd3d3f2 100644
--- a/net/dsa/port.c
+++ b/net/dsa/port.c
@@ -56,7 +56,7 @@ int dsa_port_set_state(struct dsa_port *dp, u8 state,
return 0;
 }
 
-void dsa_port_set_state_now(struct dsa_port *dp, u8 state)
+static void dsa_port_set_state_now(struct dsa_port *dp, u8 state)
 {
int err;
 
@@ -65,6 +65,35 @@ void dsa_port_set_state_now(struct dsa_port *dp, u8 state)
pr_err("DSA: failed to set STP state %u (%d)\n", state, err);
 }
 
+int dsa_port_enable(struct dsa_port *dp, struct phy_device *phy)
+{
+   u8 stp_state = dp->bridge_dev ? BR_STATE_BLOCKING : BR_STATE_FORWARDING;
+   struct dsa_switch *ds = dp->ds;
+   int port = dp->index;
+   int err;
+
+   if (ds->ops->port_enable) {
+   err = ds->ops->port_enable(ds, port, phy);
+   if (err)
+   return err;
+   }
+
+   dsa_port_set_state_now(dp, stp_state);
+
+   return 0;
+}
+
+void dsa_port_disable(struct dsa_port *dp, struct phy_device *phy)
+{
+   struct dsa_switch *ds = dp->ds;
+   int port = dp->index;
+
+   dsa_port_set_state_now(dp, BR_STATE_DISABLED);
+
+   if (ds->ops->port_disable)
+   ds->ops->port_disable(ds, port, phy);
+}
+
 int dsa_port_bridge_join(struct dsa_port *dp, struct net_device *br)
 {
struct dsa_notifier_bridge_info info = {
diff --git a/net/dsa/slave.c b/net/dsa/slave.c
index c2bb48579032..bd51ef56ec5b 100644
--- a/net/dsa/slave.c
+++ b/net/dsa/slave.c
@@ -73,9 +73,7 @@ static int dsa_slave_open(struct net_device *dev)
 {
struct dsa_slave_priv *p = netdev_priv(dev);
struct dsa_port *dp = p->dp;
-   struct dsa_switch *ds = dp->ds;
struct net_device *master = dsa_master_netdev(p);
-   u8 stp_state = dp->bridge_dev ? BR_STATE_BLOCKING : BR_STATE_FORWARDING;
int err;
 
if (!(master->flags & IFF_UP))
@@ -98,13 +96,9 @@ static int dsa_slave_open(struct net_device *dev)
goto clear_allmulti;
}
 
-   if (ds->ops->port_enable) {
-   err = ds->ops->port_enable(ds, p->dp->index, p->phy);
-   if (err)
-   goto clear_promisc;
-   }
-
-   dsa_port_set_state_now(p->dp, stp_state);
+   err = dsa_port_enable(dp, p->phy);
+   if (err)
+   goto clear_promisc;
 
if (p->phy)
phy_start(p->phy);
@@ -128,15 +122,12 @@ static int dsa_slave_close(struct net_device *dev)
 {
struct dsa_slave_priv *p = netdev_priv(dev);
struct net_device *master = dsa_master_netdev(p);
-   struct dsa_switch *ds = p->dp->ds;
+   struct dsa_port *dp = p->dp;
 
if (p->phy)
phy_stop(p->phy);
 
-   dsa_port_set_state_now(p->dp, BR_STATE_DISABLED);
-
-   if (ds->ops->port_disable)
-   ds->ops->port_disable(ds, p->dp->index, p->phy);
+   dsa_port_disable(dp, p->phy);
 
dev_mc_unsync(master, dev);
dev_uc_unsync(master, dev);
-- 
2.14.1

[PATCH 2/2] cpufreq: schedutil: consolidate capacity margin calculation

[Leo Yan]

Scheduler CFS class has variable 'capacity_margin' to calculate the
capacity margin, and schedutil governor also needs to compensate the
same margin for frequency tipping point. Below are formulas used in
CFS class and schedutil governor separately:

CFS:   U` = U * capacity_margin / 1024 = U * 1.25
Schedutil: U` = U + U >> 2 = U + U * 0.25  = U * 1.25

This patch consolidates the capacity margin calculation so let
schedutil to use same formula with CFS class. As result this can avoid
the mismatch issue between schedutil and CFS class after change
'capacity_margin' to other values.

Cc: Dietmar Eggemann 
Cc: Morten Rasmussen 
Cc: Chris Redpath 
Cc: Joel Fernandes 
Cc: Vincent Guittot 
Signed-off-by: Leo Yan 
---
 kernel/sched/cpufreq_schedutil.c | 5 +++--
 kernel/sched/sched.h | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 9209d83..067abbe 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -155,7 +155,8 @@ static void sugov_update_commit(struct sugov_policy 
*sg_policy, u64 time,
  *
  * next_freq = C * curr_freq * util_raw / max
  *
- * Take C = 1.25 for the frequency tipping point at (util / max) = 0.8.
+ * Take C = capacity_margin / 1024 = 1.25, so it's for the frequency tipping
+ * point at (util / max) = 0.8.
  *
  * The lowest driver-supported frequency which is equal or greater than the raw
  * next_freq (as calculated above) is returned, subject to policy min/max and
@@ -168,7 +169,7 @@ static unsigned int get_next_freq(struct sugov_policy 
*sg_policy,
unsigned int freq = arch_scale_freq_invariant() ?
policy->cpuinfo.max_freq : policy->cur;
 
-   freq = (freq + (freq >> 2)) * util / max;
+   freq = (freq * capacity_margin / 1024) * util / max;
 
if (freq == sg_policy->cached_raw_freq && sg_policy->next_freq != 
UINT_MAX)
return sg_policy->next_freq;
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 14db76c..cf75bdc 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -52,6 +52,7 @@ struct cpuidle_state;
 #define TASK_ON_RQ_MIGRATING   2
 
 extern __read_mostly int scheduler_running;
+extern unsigned int capacity_margin __read_mostly;
 
 extern unsigned long calc_load_update;
 extern atomic_long_t calc_load_tasks;
-- 
2.7.4

[PATCH net-next v3 0/2] net: dsa: port enabling

[Vivien Didelot]

This patchset makes slave open and close symmetrical and provides
helpers for enabling or disabling a given DSA port.

Changes in v3:
  - save the phy_device change for a future patchset

Changes in v2:
  - do not remove the phy argument from port enable/disable

Vivien Didelot (2):
  net: dsa: make slave close symmetrical to open
  net: dsa: add port enable and disable helpers

 net/dsa/dsa_priv.h |  3 ++-
 net/dsa/port.c | 31 ++-
 net/dsa/slave.c| 21 ++---
 3 files changed, 38 insertions(+), 17 deletions(-)

-- 
2.14.1

[PATCH 2/2] cpufreq: schedutil: consolidate capacity margin calculation

[Leo Yan]

Scheduler CFS class has variable 'capacity_margin' to calculate the
capacity margin, and schedutil governor also needs to compensate the
same margin for frequency tipping point. Below are formulas used in
CFS class and schedutil governor separately:

CFS:   U` = U * capacity_margin / 1024 = U * 1.25
Schedutil: U` = U + U >> 2 = U + U * 0.25  = U * 1.25

This patch consolidates the capacity margin calculation so let
schedutil to use same formula with CFS class. As result this can avoid
the mismatch issue between schedutil and CFS class after change
'capacity_margin' to other values.

Cc: Dietmar Eggemann 
Cc: Morten Rasmussen 
Cc: Chris Redpath 
Cc: Joel Fernandes 
Cc: Vincent Guittot 
Signed-off-by: Leo Yan 
---
 kernel/sched/cpufreq_schedutil.c | 5 +++--
 kernel/sched/sched.h | 1 +
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 9209d83..067abbe 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -155,7 +155,8 @@ static void sugov_update_commit(struct sugov_policy 
*sg_policy, u64 time,
  *
  * next_freq = C * curr_freq * util_raw / max
  *
- * Take C = 1.25 for the frequency tipping point at (util / max) = 0.8.
+ * Take C = capacity_margin / 1024 = 1.25, so it's for the frequency tipping
+ * point at (util / max) = 0.8.
  *
  * The lowest driver-supported frequency which is equal or greater than the raw
  * next_freq (as calculated above) is returned, subject to policy min/max and
@@ -168,7 +169,7 @@ static unsigned int get_next_freq(struct sugov_policy 
*sg_policy,
unsigned int freq = arch_scale_freq_invariant() ?
policy->cpuinfo.max_freq : policy->cur;
 
-   freq = (freq + (freq >> 2)) * util / max;
+   freq = (freq * capacity_margin / 1024) * util / max;
 
if (freq == sg_policy->cached_raw_freq && sg_policy->next_freq != 
UINT_MAX)
return sg_policy->next_freq;
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 14db76c..cf75bdc 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -52,6 +52,7 @@ struct cpuidle_state;
 #define TASK_ON_RQ_MIGRATING   2
 
 extern __read_mostly int scheduler_running;
+extern unsigned int capacity_margin __read_mostly;
 
 extern unsigned long calc_load_update;
 extern atomic_long_t calc_load_tasks;
-- 
2.7.4

[PATCH net-next v3 0/2] net: dsa: port enabling

[Vivien Didelot]

This patchset makes slave open and close symmetrical and provides
helpers for enabling or disabling a given DSA port.

Changes in v3:
  - save the phy_device change for a future patchset

Changes in v2:
  - do not remove the phy argument from port enable/disable

Vivien Didelot (2):
  net: dsa: make slave close symmetrical to open
  net: dsa: add port enable and disable helpers

 net/dsa/dsa_priv.h |  3 ++-
 net/dsa/port.c | 31 ++-
 net/dsa/slave.c| 21 ++---
 3 files changed, 38 insertions(+), 17 deletions(-)

-- 
2.14.1

[PATCH 1/2] sched/fair: make capacity_margin __read_mostly

[Leo Yan]

Variable 'capacity_margin' is used with read operation for most cases
to calculate the capacity margin, put it into __read_mostly section.

Cc: Dietmar Eggemann 
Cc: Morten Rasmussen 
Cc: Chris Redpath 
Cc: Joel Fernandes 
Cc: Vincent Guittot 
Signed-off-by: Leo Yan 
---
 kernel/sched/fair.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 70ba32e..ad03bf4 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -129,7 +129,7 @@ unsigned int sysctl_sched_cfs_bandwidth_slice   
= 5000UL;
  *
  * (default: ~20%)
  */
-unsigned int capacity_margin   = 1280;
+unsigned int capacity_margin __read_mostly = 1280;
 
 static inline void update_load_add(struct load_weight *lw, unsigned long inc)
 {
-- 
2.7.4

[PATCH 1/2] sched/fair: make capacity_margin __read_mostly

[Leo Yan]

Variable 'capacity_margin' is used with read operation for most cases
to calculate the capacity margin, put it into __read_mostly section.

Cc: Dietmar Eggemann 
Cc: Morten Rasmussen 
Cc: Chris Redpath 
Cc: Joel Fernandes 
Cc: Vincent Guittot 
Signed-off-by: Leo Yan 
---
 kernel/sched/fair.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 70ba32e..ad03bf4 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -129,7 +129,7 @@ unsigned int sysctl_sched_cfs_bandwidth_slice   
= 5000UL;
  *
  * (default: ~20%)
  */
-unsigned int capacity_margin   = 1280;
+unsigned int capacity_margin __read_mostly = 1280;
 
 static inline void update_load_add(struct load_weight *lw, unsigned long inc)
 {
-- 
2.7.4

Re: [PATCH 1/7] drm/rockchip/dsi: correct Feedback divider setting

[Matthias Kaehlcke]

Hi Nickey,

El Mon, Sep 18, 2017 at 05:05:33PM +0800 Nickey Yang ha dit:

> This patch correct Feedback divider setting:
> 1、Set Feedback divider [8:5] when HIGH_PROGRAM_EN
> 2、Due to the use of a "by 2 pre-scaler," the range of the
> feedback multiplication Feedback divider is limited to even
> division numbers, and Feedback divider must be greater than
> 12, less than 1000.
> 3、Make the previously configured Feedback divider(LSB)
> factors effective
> 
> Signed-off-by: Nickey Yang 
> ---
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 83 
> ++
>  1 file changed, 54 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index 9a20b9d..52698b7 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -228,7 +228,7 @@
>  #define LOW_PROGRAM_EN   0
>  #define HIGH_PROGRAM_EN  BIT(7)
>  #define LOOP_DIV_LOW_SEL(val)(((val) - 1) & 0x1f)
> -#define LOOP_DIV_HIGH_SEL(val)   val) - 1) >> 5) & 0x1f)
> +#define LOOP_DIV_HIGH_SEL(val)   val) - 1) >> 5) & 0xf)
>  #define PLL_LOOP_DIV_EN  BIT(5)
>  #define PLL_INPUT_DIV_EN BIT(4)
>  
> @@ -461,6 +461,7 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>   dw_mipi_dsi_phy_write(dsi, 0x17, INPUT_DIVIDER(dsi->input_div));
>   dw_mipi_dsi_phy_write(dsi, 0x18, LOOP_DIV_LOW_SEL(dsi->feedback_div) |
>LOW_PROGRAM_EN);
> + dw_mipi_dsi_phy_write(dsi, 0x19, PLL_LOOP_DIV_EN | PLL_INPUT_DIV_EN);
>   dw_mipi_dsi_phy_write(dsi, 0x18, LOOP_DIV_HIGH_SEL(dsi->feedback_div) |
>HIGH_PROGRAM_EN);
>   dw_mipi_dsi_phy_write(dsi, 0x19, PLL_LOOP_DIV_EN | PLL_INPUT_DIV_EN);
> @@ -521,11 +522,16 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>  static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi,
>   struct drm_display_mode *mode)
>  {
> - unsigned int i, pre;
> - unsigned long mpclk, pllref, tmp;
> - unsigned int m = 1, n = 1, target_mbps = 1000;
> + unsigned long mpclk, tmp;
> + unsigned int target_mbps = 1000;
>   unsigned int max_mbps = dptdin_map[ARRAY_SIZE(dptdin_map) - 1].max_mbps;
>   int bpp;
> + unsigned long best_freq = 0;
> + unsigned long fvco_min, fvco_max, fin ,fout;

nit: should be 'fin, fout'.

> + unsigned int min_prediv, max_prediv;
> + unsigned int _prediv, uninitialized_var(best_prediv);
> + unsigned long _fbdiv, uninitialized_var(best_fbdiv);
> + unsigned long min_delta = UINT_MAX;
>  
>   bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
>   if (bpp < 0) {
> @@ -544,34 +550,53 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi 
> *dsi,
>   dev_err(dsi->dev, "DPHY clock frequency is out of 
> range\n");
>   }
>  
> - pllref = DIV_ROUND_UP(clk_get_rate(dsi->pllref_clk), USEC_PER_SEC);
> - tmp = pllref;
> -
> - /*
> -  * The limits on the PLL divisor are:
> -  *
> -  *  5MHz <= (pllref / n) <= 40MHz
> -  *
> -  * we walk over these values in descreasing order so that if we hit
> -  * an exact match for target_mbps it is more likely that "m" will be
> -  * even.
> -  *
> -  * TODO: ensure that "m" is even after this loop.
> -  */
> - for (i = pllref / 5; i > (pllref / 40); i--) {
> - pre = pllref / i;
> - if ((tmp > (target_mbps % pre)) && (target_mbps / pre < 512)) {
> - tmp = target_mbps % pre;
> - n = i;
> - m = target_mbps / pre;
> + fin = clk_get_rate(dsi->pllref_clk);
> + fout = target_mbps * USEC_PER_SEC;
> +
> + /* constraint: 5Mhz < Fref / N < 40MHz */

According to the previous comment above it should be '<=' instead of
'<'.

> + min_prediv = DIV_ROUND_UP(fin, 40 * USEC_PER_SEC);
> + max_prediv = fin / (5 * USEC_PER_SEC);
> +
> + /* constraint: 80MHz < Fvco < 1500Mhz */

Same here.

> + fvco_min = 80 * USEC_PER_SEC;
> + fvco_max = 1500 * USEC_PER_SEC;
> +
> + for (_prediv = min_prediv; _prediv <= max_prediv; _prediv++) {
> + u32 delta;
> + /* Fvco = Fref * M / N */
> + tmp = fout * _prediv;
> + do_div(tmp, fin);
> + _fbdiv = tmp;
> + /*
> +  * Due to the use of a "by 2 pre-scaler," the range of the
> +  * feedback multiplication value M is limited to even division
> +  * numbers, and m must be greater than 12, less than 1000.
> +  */

I didn't encounter the second part of the constraint in my version of
the databook, judging from the code below it seems the comment should
be "12 <= m <= 1000".

> + if (_fbdiv < 12 || _fbdiv > 1000)
> + continue;
> +

Re: [PATCH 1/7] drm/rockchip/dsi: correct Feedback divider setting

[Matthias Kaehlcke]

Hi Nickey,

El Mon, Sep 18, 2017 at 05:05:33PM +0800 Nickey Yang ha dit:

> This patch correct Feedback divider setting:
> 1、Set Feedback divider [8:5] when HIGH_PROGRAM_EN
> 2、Due to the use of a "by 2 pre-scaler," the range of the
> feedback multiplication Feedback divider is limited to even
> division numbers, and Feedback divider must be greater than
> 12, less than 1000.
> 3、Make the previously configured Feedback divider(LSB)
> factors effective
> 
> Signed-off-by: Nickey Yang 
> ---
>  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 83 
> ++
>  1 file changed, 54 insertions(+), 29 deletions(-)
> 
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index 9a20b9d..52698b7 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -228,7 +228,7 @@
>  #define LOW_PROGRAM_EN   0
>  #define HIGH_PROGRAM_EN  BIT(7)
>  #define LOOP_DIV_LOW_SEL(val)(((val) - 1) & 0x1f)
> -#define LOOP_DIV_HIGH_SEL(val)   val) - 1) >> 5) & 0x1f)
> +#define LOOP_DIV_HIGH_SEL(val)   val) - 1) >> 5) & 0xf)
>  #define PLL_LOOP_DIV_EN  BIT(5)
>  #define PLL_INPUT_DIV_EN BIT(4)
>  
> @@ -461,6 +461,7 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>   dw_mipi_dsi_phy_write(dsi, 0x17, INPUT_DIVIDER(dsi->input_div));
>   dw_mipi_dsi_phy_write(dsi, 0x18, LOOP_DIV_LOW_SEL(dsi->feedback_div) |
>LOW_PROGRAM_EN);
> + dw_mipi_dsi_phy_write(dsi, 0x19, PLL_LOOP_DIV_EN | PLL_INPUT_DIV_EN);
>   dw_mipi_dsi_phy_write(dsi, 0x18, LOOP_DIV_HIGH_SEL(dsi->feedback_div) |
>HIGH_PROGRAM_EN);
>   dw_mipi_dsi_phy_write(dsi, 0x19, PLL_LOOP_DIV_EN | PLL_INPUT_DIV_EN);
> @@ -521,11 +522,16 @@ static int dw_mipi_dsi_phy_init(struct dw_mipi_dsi *dsi)
>  static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi *dsi,
>   struct drm_display_mode *mode)
>  {
> - unsigned int i, pre;
> - unsigned long mpclk, pllref, tmp;
> - unsigned int m = 1, n = 1, target_mbps = 1000;
> + unsigned long mpclk, tmp;
> + unsigned int target_mbps = 1000;
>   unsigned int max_mbps = dptdin_map[ARRAY_SIZE(dptdin_map) - 1].max_mbps;
>   int bpp;
> + unsigned long best_freq = 0;
> + unsigned long fvco_min, fvco_max, fin ,fout;

nit: should be 'fin, fout'.

> + unsigned int min_prediv, max_prediv;
> + unsigned int _prediv, uninitialized_var(best_prediv);
> + unsigned long _fbdiv, uninitialized_var(best_fbdiv);
> + unsigned long min_delta = UINT_MAX;
>  
>   bpp = mipi_dsi_pixel_format_to_bpp(dsi->format);
>   if (bpp < 0) {
> @@ -544,34 +550,53 @@ static int dw_mipi_dsi_get_lane_bps(struct dw_mipi_dsi 
> *dsi,
>   dev_err(dsi->dev, "DPHY clock frequency is out of 
> range\n");
>   }
>  
> - pllref = DIV_ROUND_UP(clk_get_rate(dsi->pllref_clk), USEC_PER_SEC);
> - tmp = pllref;
> -
> - /*
> -  * The limits on the PLL divisor are:
> -  *
> -  *  5MHz <= (pllref / n) <= 40MHz
> -  *
> -  * we walk over these values in descreasing order so that if we hit
> -  * an exact match for target_mbps it is more likely that "m" will be
> -  * even.
> -  *
> -  * TODO: ensure that "m" is even after this loop.
> -  */
> - for (i = pllref / 5; i > (pllref / 40); i--) {
> - pre = pllref / i;
> - if ((tmp > (target_mbps % pre)) && (target_mbps / pre < 512)) {
> - tmp = target_mbps % pre;
> - n = i;
> - m = target_mbps / pre;
> + fin = clk_get_rate(dsi->pllref_clk);
> + fout = target_mbps * USEC_PER_SEC;
> +
> + /* constraint: 5Mhz < Fref / N < 40MHz */

According to the previous comment above it should be '<=' instead of
'<'.

> + min_prediv = DIV_ROUND_UP(fin, 40 * USEC_PER_SEC);
> + max_prediv = fin / (5 * USEC_PER_SEC);
> +
> + /* constraint: 80MHz < Fvco < 1500Mhz */

Same here.

> + fvco_min = 80 * USEC_PER_SEC;
> + fvco_max = 1500 * USEC_PER_SEC;
> +
> + for (_prediv = min_prediv; _prediv <= max_prediv; _prediv++) {
> + u32 delta;
> + /* Fvco = Fref * M / N */
> + tmp = fout * _prediv;
> + do_div(tmp, fin);
> + _fbdiv = tmp;
> + /*
> +  * Due to the use of a "by 2 pre-scaler," the range of the
> +  * feedback multiplication value M is limited to even division
> +  * numbers, and m must be greater than 12, less than 1000.
> +  */

I didn't encounter the second part of the constraint in my version of
the databook, judging from the code below it seems the comment should
be "12 <= m <= 1000".

> + if (_fbdiv < 12 || _fbdiv > 1000)
> + continue;
> +
> + if (_fbdiv 

Re: [PATCH 4/4] tracing: Remove RCU work arounds from stack tracer

[Paul E. McKenney]

On Fri, Sep 22, 2017 at 06:15:47PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" 
> 
> While debugging some RCU issues with the stack tracer, it was discovered
> that the problem was much more than with the stack tracer itself, but with
> the saving of the stack trace, which could happen from any WARN() as well.
> The problem was fixed within kernel_text_address().
> 
> One of the bugs that was discovered was that the stack tracer called
> rcu_enter_irq() unconditionally. Paul McKenney said that could cause issues
> as well. Instead of adding logic to only call rcu_enter_irq() if RCU is not
> watching from within the stack tracer, since the core issue has been fixed
> (within save_stack_trace()), we can simply remove all the logic in the stack
> tracer that deals with RCU work arounds.

I must confess that I am having some difficulty parsing this paragraph,
especially the last sentence...

Does this capture it?

One problem is that the stack tracer called rcu_irq_enter()
unconditionally, which is problematic if RCU's last
not-watching-to-watching transition was carried out by
rcu_nmi_enter.  In that case, rcu_irq_enter() actually switches
RCU back to the not-watching state for this CPU, which results
in lockdep splats complaining about rcu_read_lock() being
used on an idle (not-watched) CPU.  The first patch of this
series addressed this problem by having rcu_irq_enter() and
rcu_irq_exit() refrain from doing anything when rcu_nmi_enter()
caused RCU to start watching this CPU.  The third patch in this
series caused save_stack_trace() to invoke rcu_nmi_enter() and
rcu_nmi_exit() as needed, so this fourth patch now removes the
rcu_irq_enter() and rcu_irq_exit() from within the stack tracer.

One further question...  Can I now remove the rcu_irq_enter_disabled()
logic?

> Cc: "Paul E. McKenney" 
> Cc: sta...@vger.kernel.org
> Fixes: 0be964be0 ("module: Sanitize RCU usage and locking")
> Suggested-by: "Paul E. McKenney" 
> Signed-off-by: Steven Rostedt (VMware) 

With the hard-to-parse paragraph fixed:

Acked-by: Paul E. McKenney 

> ---
>  kernel/trace/trace_stack.c | 15 ---
>  1 file changed, 15 deletions(-)
> 
> diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
> index a4df67cbc711..49cb41412eec 100644
> --- a/kernel/trace/trace_stack.c
> +++ b/kernel/trace/trace_stack.c
> @@ -96,23 +96,9 @@ check_stack(unsigned long ip, unsigned long *stack)
>   if (in_nmi())
>   return;
> 
> - /*
> -  * There's a slight chance that we are tracing inside the
> -  * RCU infrastructure, and rcu_irq_enter() will not work
> -  * as expected.
> -  */
> - if (unlikely(rcu_irq_enter_disabled()))
> - return;
> -
>   local_irq_save(flags);
>   arch_spin_lock(_trace_max_lock);
> 
> - /*
> -  * RCU may not be watching, make it see us.
> -  * The stack trace code uses rcu_sched.
> -  */
> - rcu_irq_enter();
> -
>   /* In case another CPU set the tracer_frame on us */
>   if (unlikely(!frame_size))
>   this_size -= tracer_frame;
> @@ -205,7 +191,6 @@ check_stack(unsigned long ip, unsigned long *stack)
>   }
> 
>   out:
> - rcu_irq_exit();
>   arch_spin_unlock(_trace_max_lock);
>   local_irq_restore(flags);
>  }
> -- 
> 2.13.2
> 
> 

Re: [PATCH 4/4] tracing: Remove RCU work arounds from stack tracer

[Paul E. McKenney]

On Fri, Sep 22, 2017 at 06:15:47PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" 
> 
> While debugging some RCU issues with the stack tracer, it was discovered
> that the problem was much more than with the stack tracer itself, but with
> the saving of the stack trace, which could happen from any WARN() as well.
> The problem was fixed within kernel_text_address().
> 
> One of the bugs that was discovered was that the stack tracer called
> rcu_enter_irq() unconditionally. Paul McKenney said that could cause issues
> as well. Instead of adding logic to only call rcu_enter_irq() if RCU is not
> watching from within the stack tracer, since the core issue has been fixed
> (within save_stack_trace()), we can simply remove all the logic in the stack
> tracer that deals with RCU work arounds.

I must confess that I am having some difficulty parsing this paragraph,
especially the last sentence...

Does this capture it?

One problem is that the stack tracer called rcu_irq_enter()
unconditionally, which is problematic if RCU's last
not-watching-to-watching transition was carried out by
rcu_nmi_enter.  In that case, rcu_irq_enter() actually switches
RCU back to the not-watching state for this CPU, which results
in lockdep splats complaining about rcu_read_lock() being
used on an idle (not-watched) CPU.  The first patch of this
series addressed this problem by having rcu_irq_enter() and
rcu_irq_exit() refrain from doing anything when rcu_nmi_enter()
caused RCU to start watching this CPU.  The third patch in this
series caused save_stack_trace() to invoke rcu_nmi_enter() and
rcu_nmi_exit() as needed, so this fourth patch now removes the
rcu_irq_enter() and rcu_irq_exit() from within the stack tracer.

One further question...  Can I now remove the rcu_irq_enter_disabled()
logic?

> Cc: "Paul E. McKenney" 
> Cc: sta...@vger.kernel.org
> Fixes: 0be964be0 ("module: Sanitize RCU usage and locking")
> Suggested-by: "Paul E. McKenney" 
> Signed-off-by: Steven Rostedt (VMware) 

With the hard-to-parse paragraph fixed:

Acked-by: Paul E. McKenney 

> ---
>  kernel/trace/trace_stack.c | 15 ---
>  1 file changed, 15 deletions(-)
> 
> diff --git a/kernel/trace/trace_stack.c b/kernel/trace/trace_stack.c
> index a4df67cbc711..49cb41412eec 100644
> --- a/kernel/trace/trace_stack.c
> +++ b/kernel/trace/trace_stack.c
> @@ -96,23 +96,9 @@ check_stack(unsigned long ip, unsigned long *stack)
>   if (in_nmi())
>   return;
> 
> - /*
> -  * There's a slight chance that we are tracing inside the
> -  * RCU infrastructure, and rcu_irq_enter() will not work
> -  * as expected.
> -  */
> - if (unlikely(rcu_irq_enter_disabled()))
> - return;
> -
>   local_irq_save(flags);
>   arch_spin_lock(_trace_max_lock);
> 
> - /*
> -  * RCU may not be watching, make it see us.
> -  * The stack trace code uses rcu_sched.
> -  */
> - rcu_irq_enter();
> -
>   /* In case another CPU set the tracer_frame on us */
>   if (unlikely(!frame_size))
>   this_size -= tracer_frame;
> @@ -205,7 +191,6 @@ check_stack(unsigned long ip, unsigned long *stack)
>   }
> 
>   out:
> - rcu_irq_exit();
>   arch_spin_unlock(_trace_max_lock);
>   local_irq_restore(flags);
>  }
> -- 
> 2.13.2
> 
> 

Re: [PATCH v4 12/13] xen/pvcalls: implement release command

[Boris Ostrovsky]

>> + */
>> +map->active.ring->in_error = -EBADF;
>> +wake_up_interruptible(>active.inflight_conn_req);
>> +
>> +/*
>> + * Wait until there are no more waiters on the mutexes.
>> + * We know that no new waiters can be added because sk_send_head
>> + * is set to NULL -- we only need to wait for the existing
>> + * waiters to return.
>> + */
>> +while (!mutex_trylock(>active.in_mutex) ||
>> +   !mutex_trylock(>active.out_mutex))
>> +cpu_relax();
>
> What if you manage to grab the locks before waiters get to run? for
> example, in recvmsg:
>
>   while (!(flags & MSG_DONTWAIT) && !pvcalls_front_read_todo(map)) {
>   wait_event_interruptible(map->active.inflight_conn_req,
>pvcalls_front_read_todo(map));
>   }
>   ret = __read_ring(map->active.ring, >active.data,
> >msg_iter, len, flags);
>
> map will be freed (by pvcalls_front_free_map() below) before __read_ring
> is passed the just-freed ring.

Actually, since you don't drop the locks I am not sure recvmsg side will
even get there.

-boris

>
>
>> +
>> +pvcalls_front_free_map(bedata, map);
>> +kfree(map);
>
> -boris
>
>

Re: [PATCH v4 12/13] xen/pvcalls: implement release command

[Boris Ostrovsky]

>> + */
>> +map->active.ring->in_error = -EBADF;
>> +wake_up_interruptible(>active.inflight_conn_req);
>> +
>> +/*
>> + * Wait until there are no more waiters on the mutexes.
>> + * We know that no new waiters can be added because sk_send_head
>> + * is set to NULL -- we only need to wait for the existing
>> + * waiters to return.
>> + */
>> +while (!mutex_trylock(>active.in_mutex) ||
>> +   !mutex_trylock(>active.out_mutex))
>> +cpu_relax();
>
> What if you manage to grab the locks before waiters get to run? for
> example, in recvmsg:
>
>   while (!(flags & MSG_DONTWAIT) && !pvcalls_front_read_todo(map)) {
>   wait_event_interruptible(map->active.inflight_conn_req,
>pvcalls_front_read_todo(map));
>   }
>   ret = __read_ring(map->active.ring, >active.data,
> >msg_iter, len, flags);
>
> map will be freed (by pvcalls_front_free_map() below) before __read_ring
> is passed the just-freed ring.

Actually, since you don't drop the locks I am not sure recvmsg side will
even get there.

-boris

>
>
>> +
>> +pvcalls_front_free_map(bedata, map);
>> +kfree(map);
>
> -boris
>
>

Re: [PATCH 3/4] extable: Enable RCU if it is not watching in kernel_text_address()

[Paul E. McKenney]

On Fri, Sep 22, 2017 at 06:15:46PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" 
> 
> If kernel_text_address() is called when RCU is not watching, it can cause an
> RCU bug because is_module_text_address() and the is_kprobe_*insn_slot()
> functions require the use of RCU.
> 
> Only enable RCU if it is not currently watching before it calls
> is_module_text_address(). The use of rcu_nmi_enter() is used to enable RCU
> because kernel_text_address() can happen pretty much anywhere (like an NMI),
> and even from within an NMI. It is called via save_stack_trace() that can be
> called by any WARN() or tracing function, which can happen while RCU is not
> watching (for example, going to or coming from idle, or during CPU take down
> or bring up).
> 
> Cc: Paul E. McKenney 
> Cc: sta...@vger.kernel.org

Do we need something calling out the dependency on the first two patches,
or is that implied these days?

> Fixes: 0be964be0 ("module: Sanitize RCU usage and locking")
> Signed-off-by: Steven Rostedt (VMware) 

Give or take Josh's feedback on the commit log and comment:

Acked-by: Paul E. McKenney 

> ---
>  kernel/extable.c | 35 ++-
>  1 file changed, 30 insertions(+), 5 deletions(-)
> 
> diff --git a/kernel/extable.c b/kernel/extable.c
> index a7024a494faf..89c4668376a6 100644
> --- a/kernel/extable.c
> +++ b/kernel/extable.c
> @@ -119,17 +119,42 @@ int __kernel_text_address(unsigned long addr)
> 
>  int kernel_text_address(unsigned long addr)
>  {
> + bool no_rcu;
> + int ret = 1;
> +
>   if (core_kernel_text(addr))
>   return 1;
> +
> + /*
> +  * If a stack dump happens while RCU is not watching, then
> +  * RCU needs to be notified that it requires to start
> +  * watching again. This can happen either by tracing that
> +  * triggers a stack trace, or a WARN() that happens during
> +  * coming back from idle, or cpu on or offlining.
> +  *
> +  * is_module_text_address() as well as the kprobe slots
> +  * require RCU to be watching.
> +  */
> + no_rcu = !rcu_is_watching();
> +
> + /* Treat this like an NMI as it can happen anywhere */
> + if (no_rcu)
> + rcu_nmi_enter();
> +
>   if (is_module_text_address(addr))
> - return 1;
> + goto out;
>   if (is_ftrace_trampoline(addr))
> - return 1;
> + goto out;
>   if (is_kprobe_optinsn_slot(addr) || is_kprobe_insn_slot(addr))
> - return 1;
> + goto out;
>   if (is_bpf_text_address(addr))
> - return 1;
> - return 0;
> + goto out;
> + ret = 0;
> +out:
> + if (no_rcu)
> + rcu_nmi_exit();
> +
> + return ret;
>  }
> 
>  /*
> -- 
> 2.13.2
> 
> 

Re: [PATCH 3/4] extable: Enable RCU if it is not watching in kernel_text_address()

[Paul E. McKenney]

On Fri, Sep 22, 2017 at 06:15:46PM -0400, Steven Rostedt wrote:
> From: "Steven Rostedt (VMware)" 
> 
> If kernel_text_address() is called when RCU is not watching, it can cause an
> RCU bug because is_module_text_address() and the is_kprobe_*insn_slot()
> functions require the use of RCU.
> 
> Only enable RCU if it is not currently watching before it calls
> is_module_text_address(). The use of rcu_nmi_enter() is used to enable RCU
> because kernel_text_address() can happen pretty much anywhere (like an NMI),
> and even from within an NMI. It is called via save_stack_trace() that can be
> called by any WARN() or tracing function, which can happen while RCU is not
> watching (for example, going to or coming from idle, or during CPU take down
> or bring up).
> 
> Cc: Paul E. McKenney 
> Cc: sta...@vger.kernel.org

Do we need something calling out the dependency on the first two patches,
or is that implied these days?

> Fixes: 0be964be0 ("module: Sanitize RCU usage and locking")
> Signed-off-by: Steven Rostedt (VMware) 

Give or take Josh's feedback on the commit log and comment:

Acked-by: Paul E. McKenney 

> ---
>  kernel/extable.c | 35 ++-
>  1 file changed, 30 insertions(+), 5 deletions(-)
> 
> diff --git a/kernel/extable.c b/kernel/extable.c
> index a7024a494faf..89c4668376a6 100644
> --- a/kernel/extable.c
> +++ b/kernel/extable.c
> @@ -119,17 +119,42 @@ int __kernel_text_address(unsigned long addr)
> 
>  int kernel_text_address(unsigned long addr)
>  {
> + bool no_rcu;
> + int ret = 1;
> +
>   if (core_kernel_text(addr))
>   return 1;
> +
> + /*
> +  * If a stack dump happens while RCU is not watching, then
> +  * RCU needs to be notified that it requires to start
> +  * watching again. This can happen either by tracing that
> +  * triggers a stack trace, or a WARN() that happens during
> +  * coming back from idle, or cpu on or offlining.
> +  *
> +  * is_module_text_address() as well as the kprobe slots
> +  * require RCU to be watching.
> +  */
> + no_rcu = !rcu_is_watching();
> +
> + /* Treat this like an NMI as it can happen anywhere */
> + if (no_rcu)
> + rcu_nmi_enter();
> +
>   if (is_module_text_address(addr))
> - return 1;
> + goto out;
>   if (is_ftrace_trampoline(addr))
> - return 1;
> + goto out;
>   if (is_kprobe_optinsn_slot(addr) || is_kprobe_insn_slot(addr))
> - return 1;
> + goto out;
>   if (is_bpf_text_address(addr))
> - return 1;
> - return 0;
> + goto out;
> + ret = 0;
> +out:
> + if (no_rcu)
> + rcu_nmi_exit();
> +
> + return ret;
>  }
> 
>  /*
> -- 
> 2.13.2
> 
>