[PATCH bpf-next] bpf, doc: Update bpf_jit_enable limitation for CONFIG_BPF_JIT_ALWAYS_ON

[Leo Yan]

When CONFIG_BPF_JIT_ALWAYS_ON is enabled, kernel has limitation for
bpf_jit_enable, so it has fixed value 1 and we cannot set it to 2
for JIT opcode dumping; this patch is to update the doc for it.

Signed-off-by: Leo Yan 
---
 Documentation/networking/filter.txt | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/networking/filter.txt 
b/Documentation/networking/filter.txt
index fd55c7d..feddab9 100644
--- a/Documentation/networking/filter.txt
+++ b/Documentation/networking/filter.txt
@@ -483,6 +483,12 @@ Example output from dmesg:
 [ 3389.935851] JIT code: 0030: 00 e8 28 94 ff e0 83 f8 01 75 07 b8 ff ff 
00 00
 [ 3389.935852] JIT code: 0040: eb 02 31 c0 c9 c3
 
+When CONFIG_BPF_JIT_ALWAYS_ON is enabled, bpf_jit_enable is set to 1 by default
+and it returns failure if change to any other value from proc node; this is
+for security consideration to avoid leaking info to unprivileged users. In this
+case, we can't directly dump JIT opcode image from kernel log, alternatively we
+need to use bpf tool for the dumping.
+
 In the kernel source tree under tools/bpf/, there's bpf_jit_disasm for
 generating disassembly out of the kernel log's hexdump:
 
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2 1/1] misc: IBM Virtual Management Channel Driver (VMC)

[Bryant G. Ly]

This driver is a logical device which provides an
interface between the hypervisor and a management
partition. This interface is like a message
passing interface. This management partition
is intended to provide an alternative to HMC-based
system management.

VMC enables the Management LPAR to provide basic
logical partition functions:
- Logical Partition Configuration
- Boot, start, and stop actions for individual
  partitions
- Display of partition status
- Management of virtual Ethernet
- Management of virtual Storage
- Basic system management

This driver is to be used for the POWER Virtual
Management Channel Virtual Adapter on the PowerPC
platform. It provides a character device which
allows for both request/response and async message
support through the /dev/ibmvmc node.

Signed-off-by: Bryant G. Ly 
Reviewed-by: Steven Royer 
Reviewed-by: Adam Reznechek 
Reviewed-by: Randy Dunlap 
Tested-by: Taylor Jakobson 
Tested-by: Brad Warrum 
Cc: Greg Kroah-Hartman 
Cc: Arnd Bergmann 
Cc: Benjamin Herrenschmidt 
Cc: Michael Ellerman 
---
 Documentation/ioctl/ioctl-number.txt  |1 +
 Documentation/misc-devices/ibmvmc.rst |  226 +++
 MAINTAINERS   |6 +
 arch/powerpc/include/asm/hvcall.h |1 +
 drivers/misc/Kconfig  |   14 +
 drivers/misc/Makefile |1 +
 drivers/misc/ibmvmc.c | 2418 +
 drivers/misc/ibmvmc.h |  209 +++
 8 files changed, 2876 insertions(+)
 create mode 100644 Documentation/misc-devices/ibmvmc.rst
 create mode 100644 drivers/misc/ibmvmc.c
 create mode 100644 drivers/misc/ibmvmc.h

diff --git a/Documentation/ioctl/ioctl-number.txt 
b/Documentation/ioctl/ioctl-number.txt
index 84bb74d..9851cee 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -329,6 +329,7 @@ Code  Seq#(hex) Include FileComments
 0xCA   80-BF   uapi/scsi/cxlflash_ioctl.h
 0xCB   00-1F   CBM serial IEC bus  in development:


+0xCC   00-0F   drivers/misc/ibmvmc.hpseries VMC driver
 0xCD   01  linux/reiserfs_fs.h
 0xCF   02  fs/cifs/ioctl.c
 0xDB   00-0F   drivers/char/mwave/mwavepub.h
diff --git a/Documentation/misc-devices/ibmvmc.rst 
b/Documentation/misc-devices/ibmvmc.rst
new file mode 100644
index 000..46ded79
--- /dev/null
+++ b/Documentation/misc-devices/ibmvmc.rst
@@ -0,0 +1,226 @@
+.. SPDX-License-Identifier: GPL-2.0+
+==
+IBM Virtual Management Channel Kernel Driver (IBMVMC)
+==
+
+:Authors:
+   Dave Engebretsen ,
+   Adam Reznechek ,
+   Steven Royer ,
+   Bryant G. Ly ,
+
+Introduction
+
+
+Note: Knowledge of virtualization technology is required to understand
+this document.
+
+A good reference document would be:
+
+https://openpowerfoundation.org/wp-content/uploads/2016/05/LoPAPR_DRAFT_v11_24March2016_cmt1.pdf
+
+The Virtual Management Channel (VMC) is a logical device which provides an
+interface between the hypervisor and a management partition. This interface
+is like a message passing interface. This management partition is intended
+to provide an alternative to systems that use a Hardware Management
+Console (HMC) - based system management.
+
+The primary hardware management solution that is developed by IBM relies
+on an appliance server named the Hardware Management Console (HMC),
+packaged as an external tower or rack-mounted personal computer. In a
+Power Systems environment, a single HMC can manage multiple POWER
+processor-based systems.
+
+Management Application
+--
+
+In the management partition, a management application exists which enables
+a system administrator to configure the system’s partitioning
+characteristics via a command line interface (CLI) or Representational
+State Transfer Application (REST API's).
+
+The management application runs on a Linux logical partition on a
+POWER8 or newer processor-based server that is virtualized by PowerVM.
+System configuration, maintenance, and control functions which
+traditionally require an HMC can be implemented in the management
+application using a combination of HMC to hypervisor interfaces and
+existing operating system methods. This tool provides a subset of the
+functions implemented by the HMC and enables basic partition configuration.
+The set of HMC to hypervisor messages supported by the management
+application component are passed to the hypervisor over a VMC 

[PATCH v2 0/1] misc: IBM Virtual Management Channel Driver (VMC)

[Bryant G. Ly]

Steven Royer had previously attempted to upstream this
driver two years ago, but never got the chance to address
the concerns from Greg Kroah-Hartman.

The thread with the initial upstream is:
https://lkml.org/lkml/2016/2/16/918

I have addressed the following:

Version 1:
- Documentation
- Use of dev_dbg instead of pr_dbg
- Change to misc class
- Fixed memory barrier usages
- Addressed styling, checkpatch, renaming of functions
- General fixes to the driver to make it more inline with
  existing upstream drivers.

Version 2:
- Changed Documentation from .rst to .txt and addressed
  small changes in documentation per request from Randy.
- Clarified Documentation based upon Linus Walleij's
  comments
- Fixed kbuild warning in regards to unititialized use of
  rc

Bryant G. Ly (1):
  misc: IBM Virtual Management Channel Driver (VMC)

 Documentation/ioctl/ioctl-number.txt  |1 +
 Documentation/misc-devices/ibmvmc.rst |  226 +++
 MAINTAINERS   |6 +
 arch/powerpc/include/asm/hvcall.h |1 +
 drivers/misc/Kconfig  |   14 +
 drivers/misc/Makefile |1 +
 drivers/misc/ibmvmc.c | 2418 +
 drivers/misc/ibmvmc.h |  209 +++
 8 files changed, 2876 insertions(+)
 create mode 100644 Documentation/misc-devices/ibmvmc.rst
 create mode 100644 drivers/misc/ibmvmc.c
 create mode 100644 drivers/misc/ibmvmc.h

-- 
2.7.2

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH bpf-next v4 03/10] bpf: add documentation for eBPF helpers (12-22)

[Quentin Monnet]

Add documentation for eBPF helper functions to bpf.h user header file.
This documentation can be parsed with the Python script provided in
another commit of the patch series, in order to provide a RST document
that can later be converted into a man page.

The objective is to make the documentation easily understandable and
accessible to all eBPF developers, including beginners.

This patch contains descriptions for the following helper functions, all
written by Alexei:

- bpf_get_current_pid_tgid()
- bpf_get_current_uid_gid()
- bpf_get_current_comm()
- bpf_skb_vlan_push()
- bpf_skb_vlan_pop()
- bpf_skb_get_tunnel_key()
- bpf_skb_set_tunnel_key()
- bpf_redirect()
- bpf_perf_event_output()
- bpf_get_stackid()
- bpf_get_current_task()

v4:
- bpf_redirect(): Fix typo: "XDP_ABORT" changed to "XDP_ABORTED". Add
  note on bpf_redirect_map() providing better performance. Replace "Save
  for" with "Except for".
- bpf_skb_vlan_push(): Clarify comment about invalidated verifier
  checks.
- bpf_skb_vlan_pop(): Clarify comment about invalidated verifier
  checks.
- bpf_skb_get_tunnel_key(): Add notes on tunnel_id, "collect metadata"
  mode, and example tunneling protocols with which it can be used.
- bpf_skb_set_tunnel_key(): Add a reference to the description of
  bpf_skb_get_tunnel_key().
- bpf_perf_event_output(): Specify that, and for what purpose, the
  helper can be used with programs attached to TC and XDP.

v3:
- bpf_skb_get_tunnel_key(): Change and improve description and example.
- bpf_redirect(): Improve description of BPF_F_INGRESS flag.
- bpf_perf_event_output(): Fix first sentence of description. Delete
  wrong statement on context being evaluated as a struct pt_reg. Remove
  the long yet incomplete example.
- bpf_get_stackid(): Add a note about PERF_MAX_STACK_DEPTH being
  configurable.

Cc: Alexei Starovoitov 
Signed-off-by: Quentin Monnet 
Acked-by: Alexei Starovoitov 
---
 include/uapi/linux/bpf.h | 254 +++
 1 file changed, 254 insertions(+)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 6ac56df3ea8d..368d83cf02d8 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -623,6 +623,260 @@ union bpf_attr {
  * direct packet access.
  * Return
  * 0 on success, or a negative error in case of failure.
+ *
+ * u64 bpf_get_current_pid_tgid(void)
+ * Return
+ * A 64-bit integer containing the current tgid and pid, and
+ * created as such:
+ * *current_task*\ **->tgid << 32 \|**
+ * *current_task*\ **->pid**.
+ *
+ * u64 bpf_get_current_uid_gid(void)
+ * Return
+ * A 64-bit integer containing the current GID and UID, and
+ * created as such: *current_gid* **<< 32 \|** *current_uid*.
+ *
+ * int bpf_get_current_comm(char *buf, u32 size_of_buf)
+ * Description
+ * Copy the **comm** attribute of the current task into *buf* of
+ * *size_of_buf*. The **comm** attribute contains the name of
+ * the executable (excluding the path) for the current task. The
+ * *size_of_buf* must be strictly positive. On success, the
+ * helper makes sure that the *buf* is NUL-terminated. On failure,
+ * it is filled with zeroes.
+ * Return
+ * 0 on success, or a negative error in case of failure.
+ *
+ * int bpf_skb_vlan_push(struct sk_buff *skb, __be16 vlan_proto, u16 vlan_tci)
+ * Description
+ * Push a *vlan_tci* (VLAN tag control information) of protocol
+ * *vlan_proto* to the packet associated to *skb*, then update
+ * the checksum. Note that if *vlan_proto* is different from
+ * **ETH_P_8021Q** and **ETH_P_8021AD**, it is considered to
+ * be **ETH_P_8021Q**.
+ *
+ * A call to this helper is susceptible to change the underlaying
+ * packet buffer. Therefore, at load time, all checks on pointers
+ * previously done by the verifier are invalidated and must be
+ * performed again, if the helper is used in combination with
+ * direct packet access.
+ * Return
+ * 0 on success, or a negative error in case of failure.
+ *
+ * int bpf_skb_vlan_pop(struct sk_buff *skb)
+ * Description
+ * Pop a VLAN header from the packet associated to *skb*.
+ *
+ * A call to this helper is susceptible to change the underlaying
+ * packet buffer. Therefore, at load time, all checks on pointers
+ * previously done by the verifier are invalidated and must be
+ * performed again, if the helper is used in combination with
+ * direct packet access.
+ * Return
+ * 0 on success, or a negative error in case of failure.
+ *
+ * int bpf_skb_get_tunnel_key(struct sk_buff *skb, struct 

[PATCH bpf-next v4 02/10] bpf: add documentation for eBPF helpers (01-11)

[Quentin Monnet]

Add documentation for eBPF helper functions to bpf.h user header file.
This documentation can be parsed with the Python script provided in
another commit of the patch series, in order to provide a RST document
that can later be converted into a man page.

The objective is to make the documentation easily understandable and
accessible to all eBPF developers, including beginners.

This patch contains descriptions for the following helper functions, all
written by Alexei:

- bpf_map_lookup_elem()
- bpf_map_update_elem()
- bpf_map_delete_elem()
- bpf_probe_read()
- bpf_ktime_get_ns()
- bpf_trace_printk()
- bpf_skb_store_bytes()
- bpf_l3_csum_replace()
- bpf_l4_csum_replace()
- bpf_tail_call()
- bpf_clone_redirect()

v4:
- bpf_map_lookup_elem(): Add "const" qualifier for key.
- bpf_map_update_elem(): Add "const" qualifier for key and value.
- bpf_map_lookup_elem(): Add "const" qualifier for key.
- bpf_skb_store_bytes(): Clarify comment about invalidated verifier
  checks.
- bpf_l3_csum_replace(): Mention L3 instead of just IP, and add a note
  about bpf_csum_diff().
- bpf_l4_csum_replace(): Mention L4 instead of just TCP/UDP, and add a
  note about bpf_csum_diff().
- bpf_tail_call(): Bring minor edits to description.
- bpf_clone_redirect(): Add a note about the relation with
  bpf_redirect(). Also clarify comment about invalidated verifier
  checks.

v3:
- bpf_map_lookup_elem(): Fix description of restrictions for flags
  related to the existence of the entry.
- bpf_trace_printk(): State that trace_pipe can be configured. Fix
  return value in case an unknown format specifier is met. Add a note on
  kernel log notice when the helper is used. Edit example.
- bpf_tail_call(): Improve comment on stack inheritance.
- bpf_clone_redirect(): Improve description of BPF_F_INGRESS flag.

Cc: Alexei Starovoitov 
Signed-off-by: Quentin Monnet 
Acked-by: Alexei Starovoitov 
---
 include/uapi/linux/bpf.h | 230 +++
 1 file changed, 230 insertions(+)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index df28a60d314c..6ac56df3ea8d 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -393,6 +393,236 @@ union bpf_attr {
  * intentional, removing them would break paragraphs for rst2man.
  *
  * Start of BPF helper function descriptions:
+ *
+ * void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)
+ * Description
+ * Perform a lookup in *map* for an entry associated to *key*.
+ * Return
+ * Map value associated to *key*, or **NULL** if no entry was
+ * found.
+ *
+ * int bpf_map_update_elem(struct bpf_map *map, const void *key, const void 
*value, u64 flags)
+ * Description
+ * Add or update the value of the entry associated to *key* in
+ * *map* with *value*. *flags* is one of:
+ *
+ * **BPF_NOEXIST**
+ * The entry for *key* must not exist in the map.
+ * **BPF_EXIST**
+ * The entry for *key* must already exist in the map.
+ * **BPF_ANY**
+ * No condition on the existence of the entry for *key*.
+ *
+ * Flag value **BPF_NOEXIST** cannot be used for maps of types
+ * **BPF_MAP_TYPE_ARRAY** or **BPF_MAP_TYPE_PERCPU_ARRAY**  (all
+ * elements always exist), the helper would return an error.
+ * Return
+ * 0 on success, or a negative error in case of failure.
+ *
+ * int bpf_map_delete_elem(struct bpf_map *map, const void *key)
+ * Description
+ * Delete entry with *key* from *map*.
+ * Return
+ * 0 on success, or a negative error in case of failure.
+ *
+ * int bpf_probe_read(void *dst, u32 size, const void *src)
+ * Description
+ * For tracing programs, safely attempt to read *size* bytes from
+ * address *src* and store the data in *dst*.
+ * Return
+ * 0 on success, or a negative error in case of failure.
+ *
+ * u64 bpf_ktime_get_ns(void)
+ * Description
+ * Return the time elapsed since system boot, in nanoseconds.
+ * Return
+ * Current *ktime*.
+ *
+ * int bpf_trace_printk(const char *fmt, u32 fmt_size, ...)
+ * Description
+ * This helper is a "printk()-like" facility for debugging. It
+ * prints a message defined by format *fmt* (of size *fmt_size*)
+ * to file *\/sys/kernel/debug/tracing/trace* from DebugFS, if
+ * available. It can take up to three additional **u64**
+ * arguments (as an eBPF helpers, the total number of arguments is
+ * limited to five).
+ *
+ * Each time the helper is called, it appends a line to the trace.
+ * The format of the trace is customizable, and the exact output
+ * one will get depends on the options set in

[PATCH bpf-next v4 10/10] bpf: update bpf.h uapi header for tools

[Quentin Monnet]

Update tools/include/uapi/linux/bpf.h file in order to reflect the
changes for BPF helper functions documentation introduced in previous
commits.

Signed-off-by: Quentin Monnet 
---
 tools/include/uapi/linux/bpf.h | 1776 +++-
 1 file changed, 1380 insertions(+), 396 deletions(-)

diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
index e6679393b687..3b91e22f68c1 100644
--- a/tools/include/uapi/linux/bpf.h
+++ b/tools/include/uapi/linux/bpf.h
@@ -377,412 +377,1396 @@ union bpf_attr {
};
 } __attribute__((aligned(8)));
 
-/* BPF helper function descriptions:
- *
- * void *bpf_map_lookup_elem(, )
- * Return: Map value or NULL
- *
- * int bpf_map_update_elem(, , , flags)
- * Return: 0 on success or negative error
- *
- * int bpf_map_delete_elem(, )
- * Return: 0 on success or negative error
- *
- * int bpf_probe_read(void *dst, int size, void *src)
- * Return: 0 on success or negative error
+/* The description below is an attempt at providing documentation to eBPF
+ * developers about the multiple available eBPF helper functions. It can be
+ * parsed and used to produce a manual page. The workflow is the following,
+ * and requires the rst2man utility:
+ *
+ * $ ./scripts/bpf_helpers_doc.py \
+ * --filename include/uapi/linux/bpf.h > /tmp/bpf-helpers.rst
+ * $ rst2man /tmp/bpf-helpers.rst > /tmp/bpf-helpers.7
+ * $ man /tmp/bpf-helpers.7
+ *
+ * Note that in order to produce this external documentation, some RST
+ * formatting is used in the descriptions to get "bold" and "italics" in
+ * manual pages. Also note that the few trailing white spaces are
+ * intentional, removing them would break paragraphs for rst2man.
+ *
+ * Start of BPF helper function descriptions:
+ *
+ * void *bpf_map_lookup_elem(struct bpf_map *map, const void *key)
+ * Description
+ * Perform a lookup in *map* for an entry associated to *key*.
+ * Return
+ * Map value associated to *key*, or **NULL** if no entry was
+ * found.
+ *
+ * int bpf_map_update_elem(struct bpf_map *map, const void *key, const void 
*value, u64 flags)
+ * Description
+ * Add or update the value of the entry associated to *key* in
+ * *map* with *value*. *flags* is one of:
+ *
+ * **BPF_NOEXIST**
+ * The entry for *key* must not exist in the map.
+ * **BPF_EXIST**
+ * The entry for *key* must already exist in the map.
+ * **BPF_ANY**
+ * No condition on the existence of the entry for *key*.
+ *
+ * Flag value **BPF_NOEXIST** cannot be used for maps of types
+ * **BPF_MAP_TYPE_ARRAY** or **BPF_MAP_TYPE_PERCPU_ARRAY**  (all
+ * elements always exist), the helper would return an error.
+ * Return
+ * 0 on success, or a negative error in case of failure.
+ *
+ * int bpf_map_delete_elem(struct bpf_map *map, const void *key)
+ * Description
+ * Delete entry with *key* from *map*.
+ * Return
+ * 0 on success, or a negative error in case of failure.
+ *
+ * int bpf_probe_read(void *dst, u32 size, const void *src)
+ * Description
+ * For tracing programs, safely attempt to read *size* bytes from
+ * address *src* and store the data in *dst*.
+ * Return
+ * 0 on success, or a negative error in case of failure.
  *
  * u64 bpf_ktime_get_ns(void)
- * Return: current ktime
- *
- * int bpf_trace_printk(const char *fmt, int fmt_size, ...)
- * Return: length of buffer written or negative error
- *
- * u32 bpf_prandom_u32(void)
- * Return: random value
- *
- * u32 bpf_raw_smp_processor_id(void)
- * Return: SMP processor ID
- *
- * int bpf_skb_store_bytes(skb, offset, from, len, flags)
- * store bytes into packet
- * @skb: pointer to skb
- * @offset: offset within packet from skb->mac_header
- * @from: pointer where to copy bytes from
- * @len: number of bytes to store into packet
- * @flags: bit 0 - if true, recompute skb->csum
- * other bits - reserved
- * Return: 0 on success or negative error
- *
- * int bpf_l3_csum_replace(skb, offset, from, to, flags)
- * recompute IP checksum
- * @skb: pointer to skb
- * @offset: offset within packet where IP checksum is located
- * @from: old value of header field
- * @to: new value of header field
- * @flags: bits 0-3 - size of header field
- * other bits - reserved
- * Return: 0 on success or negative error
- *
- * int bpf_l4_csum_replace(skb, offset, from, to, flags)
- * recompute TCP/UDP checksum
- * @skb: pointer to skb
- * @offset: offset within packet where TCP/UDP checksum is located
- * @from: old value of header field
- * @to: new value of header field
- * @flags: bits 0-3 - size of 

[PATCH bpf-next v4 09/10] bpf: add documentation for eBPF helpers (65-66)

[Quentin Monnet]

Add documentation for eBPF helper functions to bpf.h user header file.
This documentation can be parsed with the Python script provided in
another commit of the patch series, in order to provide a RST document
that can later be converted into a man page.

The objective is to make the documentation easily understandable and
accessible to all eBPF developers, including beginners.

This patch contains descriptions for the following helper functions:

Helper from Nikita:
- bpf_xdp_adjust_tail()

Helper from Eyal:
- bpf_skb_get_xfrm_state()

v4:
- New patch (helpers did not exist yet for previous versions).

Cc: Nikita V. Shirokov 
Cc: Eyal Birger 
Signed-off-by: Quentin Monnet 
---
 include/uapi/linux/bpf.h | 30 ++
 1 file changed, 30 insertions(+)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 335ac427d43b..3b91e22f68c1 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -1737,6 +1737,36 @@ union bpf_attr {
  * must be set to zero.
  * Return
  * 0 on success, or a negative error in case of failure.
+ *
+ * int bpf_xdp_adjust_tail(struct xdp_buff *xdp_md, int delta)
+ * Description
+ * Adjust (move) *xdp_md*\ **->data_end** by *delta* bytes. It is
+ * only possible to shrink the packet as of this writing,
+ * therefore *delta* must be a negative integer.
+ *
+ * A call to this helper is susceptible to change the underlaying
+ * packet buffer. Therefore, at load time, all checks on pointers
+ * previously done by the verifier are invalidated and must be
+ * performed again, if the helper is used in combination with
+ * direct packet access.
+ * Return
+ * 0 on success, or a negative error in case of failure.
+ *
+ * int bpf_skb_get_xfrm_state(struct sk_buff *skb, u32 index, struct 
bpf_xfrm_state *xfrm_state, u32 size, u64 flags)
+ * Description
+ * Retrieve the XFRM state (IP transform framework, see also
+ * **ip-xfrm(8)**) at *index* in XFRM "security path" for *skb*.
+ *
+ * The retrieved value is stored in the **struct bpf_xfrm_state**
+ * pointed by *xfrm_state* and of length *size*.
+ *
+ * All values for *flags* are reserved for future usage, and must
+ * be left at zero.
+ *
+ * This helper is available only if the kernel was compiled with
+ * **CONFIG_XFRM** configuration option.
+ * Return
+ * 0 on success, or a negative error in case of failure.
  */
 #define __BPF_FUNC_MAPPER(FN)  \
FN(unspec), \
-- 
2.14.1

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH bpf-next v4 08/10] bpf: add documentation for eBPF helpers (58-64)

[Quentin Monnet]

Add documentation for eBPF helper functions to bpf.h user header file.
This documentation can be parsed with the Python script provided in
another commit of the patch series, in order to provide a RST document
that can later be converted into a man page.

The objective is to make the documentation easily understandable and
accessible to all eBPF developers, including beginners.

This patch contains descriptions for the following helper functions, all
written by John:

- bpf_redirect_map()
- bpf_sk_redirect_map()
- bpf_sock_map_update()
- bpf_msg_redirect_map()
- bpf_msg_apply_bytes()
- bpf_msg_cork_bytes()
- bpf_msg_pull_data()

v4:
- bpf_redirect_map(): Fix typos: "XDP_ABORT" changed to "XDP_ABORTED",
  "his" to "this". Also add a paragraph on performance improvement over
  bpf_redirect() helper.

v3:
- bpf_sk_redirect_map(): Improve description of BPF_F_INGRESS flag.
- bpf_msg_redirect_map(): Improve description of BPF_F_INGRESS flag.
- bpf_redirect_map(): Fix note on CPU redirection, not fully implemented
  for generic XDP but supported on native XDP.
- bpf_msg_pull_data(): Clarify comment about invalidated verifier
  checks.

Cc: Jesper Dangaard Brouer 
Cc: John Fastabend 
Signed-off-by: Quentin Monnet 
---
 include/uapi/linux/bpf.h | 147 +++
 1 file changed, 147 insertions(+)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 9fe008dd51e7..335ac427d43b 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -1404,6 +1404,56 @@ union bpf_attr {
  * Return
  * 0 on success, or a negative error in case of failure.
  *
+ * int bpf_redirect_map(struct bpf_map *map, u32 key, u64 flags)
+ * Description
+ * Redirect the packet to the endpoint referenced by *map* at
+ * index *key*. Depending on its type, this *map* can contain
+ * references to net devices (for forwarding packets through other
+ * ports), or to CPUs (for redirecting XDP frames to another CPU;
+ * but this is only implemented for native XDP (with driver
+ * support) as of this writing).
+ *
+ * All values for *flags* are reserved for future usage, and must
+ * be left at zero.
+ *
+ * When used to redirect packets to net devices, this helper
+ * provides a high performance increase over **bpf_redirect**\ ().
+ * This is due to various implementation details of the underlying
+ * mechanisms, one of which is the fact that **bpf_redirect_map**\
+ * () tries to send packet as a "bulk" to the device.
+ * Return
+ * **XDP_REDIRECT** on success, or **XDP_ABORTED** on error.
+ *
+ * int bpf_sk_redirect_map(struct bpf_map *map, u32 key, u64 flags)
+ * Description
+ * Redirect the packet to the socket referenced by *map* (of type
+ * **BPF_MAP_TYPE_SOCKMAP**) at index *key*. Both ingress and
+ * egress interfaces can be used for redirection. The
+ * **BPF_F_INGRESS** value in *flags* is used to make the
+ * distinction (ingress path is selected if the flag is present,
+ * egress path otherwise). This is the only flag supported for now.
+ * Return
+ * **SK_PASS** on success, or **SK_DROP** on error.
+ *
+ * int bpf_sock_map_update(struct bpf_sock_ops_kern *skops, struct bpf_map 
*map, void *key, u64 flags)
+ * Description
+ * Add an entry to, or update a *map* referencing sockets. The
+ * *skops* is used as a new value for the entry associated to
+ * *key*. *flags* is one of:
+ *
+ * **BPF_NOEXIST**
+ * The entry for *key* must not exist in the map.
+ * **BPF_EXIST**
+ * The entry for *key* must already exist in the map.
+ * **BPF_ANY**
+ * No condition on the existence of the entry for *key*.
+ *
+ * If the *map* has eBPF programs (parser and verdict), those will
+ * be inherited by the socket being added. If the socket is
+ * already attached to eBPF programs, this results in an error.
+ * Return
+ * 0 on success, or a negative error in case of failure.
+ *
  * int bpf_xdp_adjust_meta(struct xdp_buff *xdp_md, int delta)
  * Description
  * Adjust the address pointed by *xdp_md*\ **->data_meta** by
@@ -1574,6 +1624,103 @@ union bpf_attr {
  * be set is returned (which comes down to 0 if all bits were set
  * as required).
  *
+ * int bpf_msg_redirect_map(struct sk_msg_buff *msg, struct bpf_map *map, u32 
key, u64 flags)
+ * Description
+ * This helper is used in programs implementing policies at the
+ * socket level. If the message *msg* is allowed to pass (i.e. if
+ *  

[PATCH bpf-next v4 05/10] bpf: add documentation for eBPF helpers (33-41)

[Quentin Monnet]

Add documentation for eBPF helper functions to bpf.h user header file.
This documentation can be parsed with the Python script provided in
another commit of the patch series, in order to provide a RST document
that can later be converted into a man page.

The objective is to make the documentation easily understandable and
accessible to all eBPF developers, including beginners.

This patch contains descriptions for the following helper functions, all
written by Daniel:

- bpf_get_hash_recalc()
- bpf_skb_change_tail()
- bpf_skb_pull_data()
- bpf_csum_update()
- bpf_set_hash_invalid()
- bpf_get_numa_node_id()
- bpf_set_hash()
- bpf_skb_adjust_room()
- bpf_xdp_adjust_meta()

v4:
- bpf_skb_change_tail(): Clarify comment about invalidated verifier
  checks.
- bpf_skb_pull_data(): Clarify the motivation for using this helper or
  bpf_skb_load_bytes(), on non-linear buffers. Fix RST formatting for
  *skb*. Clarify comment about invalidated verifier checks.
- bpf_csum_update(): Fix description of checksum (entire packet, not IP
  checksum). Fix a typo: "header" instead of "helper".
- bpf_set_hash_invalid(): Mention bpf_get_hash_recalc().
- bpf_get_numa_node_id(): State that the helper is not restricted to
  programs attached to sockets.
- bpf_skb_adjust_room(): Clarify comment about invalidated verifier
  checks.
- bpf_xdp_adjust_meta(): Clarify comment about invalidated verifier
  checks.

Cc: Daniel Borkmann 
Signed-off-by: Quentin Monnet 
Acked-by: Alexei Starovoitov 
---
 include/uapi/linux/bpf.h | 164 +++
 1 file changed, 164 insertions(+)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 28681cef14d4..d1207ba39280 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -1071,9 +1071,173 @@ union bpf_attr {
  * Return
  * 0 on success, or a negative error in case of failure.
  *
+ * u32 bpf_get_hash_recalc(struct sk_buff *skb)
+ * Description
+ * Retrieve the hash of the packet, *skb*\ **->hash**. If it is
+ * not set, in particular if the hash was cleared due to mangling,
+ * recompute this hash. Later accesses to the hash can be done
+ * directly with *skb*\ **->hash**.
+ *
+ * Calling **bpf_set_hash_invalid**\ (), changing a packet
+ * prototype with **bpf_skb_change_proto**\ (), or calling
+ * **bpf_skb_store_bytes**\ () with the
+ * **BPF_F_INVALIDATE_HASH** are actions susceptible to clear
+ * the hash and to trigger a new computation for the next call to
+ * **bpf_get_hash_recalc**\ ().
+ * Return
+ * The 32-bit hash.
+ *
  * u64 bpf_get_current_task(void)
  * Return
  * A pointer to the current task struct.
+ *
+ * int bpf_skb_change_tail(struct sk_buff *skb, u32 len, u64 flags)
+ * Description
+ * Resize (trim or grow) the packet associated to *skb* to the
+ * new *len*. The *flags* are reserved for future usage, and must
+ * be left at zero.
+ *
+ * The basic idea is that the helper performs the needed work to
+ * change the size of the packet, then the eBPF program rewrites
+ * the rest via helpers like **bpf_skb_store_bytes**\ (),
+ * **bpf_l3_csum_replace**\ (), **bpf_l3_csum_replace**\ ()
+ * and others. This helper is a slow path utility intended for
+ * replies with control messages. And because it is targeted for
+ * slow path, the helper itself can afford to be slow: it
+ * implicitly linearizes, unclones and drops offloads from the
+ * *skb*.
+ *
+ * A call to this helper is susceptible to change the underlaying
+ * packet buffer. Therefore, at load time, all checks on pointers
+ * previously done by the verifier are invalidated and must be
+ * performed again, if the helper is used in combination with
+ * direct packet access.
+ * Return
+ * 0 on success, or a negative error in case of failure.
+ *
+ * int bpf_skb_pull_data(struct sk_buff *skb, u32 len)
+ * Description
+ * Pull in non-linear data in case the *skb* is non-linear and not
+ * all of *len* are part of the linear section. Make *len* bytes
+ * from *skb* readable and writable. If a zero value is passed for
+ * *len*, then the whole length of the *skb* is pulled.
+ *
+ * This helper is only needed for reading and writing with direct
+ * packet access.
+ *
+ * For direct packet access, testing that offsets to access
+ * are within packet boundaries (test on *skb*\ **->data_end**) is
+ * susceptible to fail if offsets are invalid, or if the requested
+ * data is in 

[PATCH bpf-next v4 07/10] bpf: add documentation for eBPF helpers (51-57)

[Quentin Monnet]

Add documentation for eBPF helper functions to bpf.h user header file.
This documentation can be parsed with the Python script provided in
another commit of the patch series, in order to provide a RST document
that can later be converted into a man page.

The objective is to make the documentation easily understandable and
accessible to all eBPF developers, including beginners.

This patch contains descriptions for the following helper functions:

Helpers from Lawrence:
- bpf_setsockopt()
- bpf_getsockopt()
- bpf_sock_ops_cb_flags_set()

Helpers from Yonghong:
- bpf_perf_event_read_value()
- bpf_perf_prog_read_value()

Helper from Josef:
- bpf_override_return()

Helper from Andrey:
- bpf_bind()

v4:
- bpf_perf_event_read_value(): State that this helper should be
  preferred over bpf_perf_event_read().

v3:
- bpf_perf_event_read_value(): Fix time of selection for perf event type
  in description. Remove occurences of "cores" to avoid confusion with
  "CPU".
- bpf_bind(): Remove last paragraph of description, which was off topic.

Cc: Lawrence Brakmo 
Cc: Yonghong Song 
Cc: Josef Bacik 
Cc: Andrey Ignatov 
Signed-off-by: Quentin Monnet 
Acked-by: Yonghong Song 
[for bpf_perf_event_read_value(), bpf_perf_prog_read_value()]
Acked-by: Andrey Ignatov 
[for bpf_bind()]
---
 include/uapi/linux/bpf.h | 180 +++
 1 file changed, 180 insertions(+)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index f06225f3a01d..9fe008dd51e7 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -1361,6 +1361,28 @@ union bpf_attr {
  * Return
  * 0
  *
+ * int bpf_setsockopt(struct bpf_sock_ops_kern *bpf_socket, int level, int 
optname, char *optval, int optlen)
+ * Description
+ * Emulate a call to **setsockopt()** on the socket associated to
+ * *bpf_socket*, which must be a full socket. The *level* at
+ * which the option resides and the name *optname* of the option
+ * must be specified, see **setsockopt(2)** for more information.
+ * The option value of length *optlen* is pointed by *optval*.
+ *
+ * This helper actually implements a subset of **setsockopt()**.
+ * It supports the following *level*\ s:
+ *
+ * * **SOL_SOCKET**, which supports the following *optname*\ s:
+ *   **SO_RCVBUF**, **SO_SNDBUF**, **SO_MAX_PACING_RATE**,
+ *   **SO_PRIORITY**, **SO_RCVLOWAT**, **SO_MARK**.
+ * * **IPPROTO_TCP**, which supports the following *optname*\ s:
+ *   **TCP_CONGESTION**, **TCP_BPF_IW**,
+ *   **TCP_BPF_SNDCWND_CLAMP**.
+ * * **IPPROTO_IP**, which supports *optname* **IP_TOS**.
+ * * **IPPROTO_IPV6**, which supports *optname* **IPV6_TCLASS**.
+ * Return
+ * 0 on success, or a negative error in case of failure.
+ *
  * int bpf_skb_adjust_room(struct sk_buff *skb, u32 len_diff, u32 mode, u64 
flags)
  * Description
  * Grow or shrink the room for data in the packet associated to
@@ -1410,6 +1432,164 @@ union bpf_attr {
  * direct packet access.
  * Return
  * 0 on success, or a negative error in case of failure.
+ *
+ * int bpf_perf_event_read_value(struct bpf_map *map, u64 flags, struct 
bpf_perf_event_value *buf, u32 buf_size)
+ * Description
+ * Read the value of a perf event counter, and store it into *buf*
+ * of size *buf_size*. This helper relies on a *map* of type
+ * **BPF_MAP_TYPE_PERF_EVENT_ARRAY**. The nature of the perf event
+ * counter is selected when *map* is updated with perf event file
+ * descriptors. The *map* is an array whose size is the number of
+ * available CPUs, and each cell contains a value relative to one
+ * CPU. The value to retrieve is indicated by *flags*, that
+ * contains the index of the CPU to look up, masked with
+ * **BPF_F_INDEX_MASK**. Alternatively, *flags* can be set to
+ * **BPF_F_CURRENT_CPU** to indicate that the value for the
+ * current CPU should be retrieved.
+ *
+ * This helper behaves in a way close to
+ * **bpf_perf_event_read**\ () helper, save that instead of
+ * just returning the value observed, it fills the *buf*
+ * structure. This allows for additional data to be retrieved: in
+ * particular, the enabled and running times (in *buf*\
+ * **->enabled** and *buf*\ **->running**, respectively) are
+ * copied. In general, **bpf_perf_event_read_value**\ () is
+ * recommended over **bpf_perf_event_read**\ (), which has some
+ * ABI issues and provides fewer functionalities.
+ *
+ * 

[PATCH bpf-next v4 06/10] bpf: add documentation for eBPF helpers (42-50)

[Quentin Monnet]

Add documentation for eBPF helper functions to bpf.h user header file.
This documentation can be parsed with the Python script provided in
another commit of the patch series, in order to provide a RST document
that can later be converted into a man page.

The objective is to make the documentation easily understandable and
accessible to all eBPF developers, including beginners.

This patch contains descriptions for the following helper functions:

Helper from Kaixu:
- bpf_perf_event_read()

Helpers from Martin:
- bpf_skb_under_cgroup()
- bpf_xdp_adjust_head()

Helpers from Sargun:
- bpf_probe_write_user()
- bpf_current_task_under_cgroup()

Helper from Thomas:
- bpf_skb_change_head()

Helper from Gianluca:
- bpf_probe_read_str()

Helpers from Chenbo:
- bpf_get_socket_cookie()
- bpf_get_socket_uid()

v4:
- bpf_perf_event_read(): State that bpf_perf_event_read_value() should
  be preferred over this helper.
- bpf_skb_change_head(): Clarify comment about invalidated verifier
  checks.
- bpf_xdp_adjust_head(): Clarify comment about invalidated verifier
  checks.
- bpf_probe_write_user(): Add that dst must be a valid user space
  address.
- bpf_get_socket_cookie(): Improve description by making clearer that
  the cockie belongs to the socket, and state that it remains stable for
  the life of the socket.

v3:
- bpf_perf_event_read(): Fix time of selection for perf event type in
  description. Remove occurences of "cores" to avoid confusion with
  "CPU".

Cc: Martin KaFai Lau 
Cc: Sargun Dhillon 
Cc: Thomas Graf 
Cc: Gianluca Borello 
Cc: Chenbo Feng 
Signed-off-by: Quentin Monnet 
Acked-by: Alexei Starovoitov 
Acked-by: Martin KaFai Lau 
[for bpf_skb_under_cgroup(), bpf_xdp_adjust_head()]
---
 include/uapi/linux/bpf.h | 172 +++
 1 file changed, 172 insertions(+)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index d1207ba39280..f06225f3a01d 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -810,6 +810,35 @@ union bpf_attr {
  * Return
  * 0 on success, or a negative error in case of failure.
  *
+ * u64 bpf_perf_event_read(struct bpf_map *map, u64 flags)
+ * Description
+ * Read the value of a perf event counter. This helper relies on a
+ * *map* of type **BPF_MAP_TYPE_PERF_EVENT_ARRAY**. The nature of
+ * the perf event counter is selected when *map* is updated with
+ * perf event file descriptors. The *map* is an array whose size
+ * is the number of available CPUs, and each cell contains a value
+ * relative to one CPU. The value to retrieve is indicated by
+ * *flags*, that contains the index of the CPU to look up, masked
+ * with **BPF_F_INDEX_MASK**. Alternatively, *flags* can be set to
+ * **BPF_F_CURRENT_CPU** to indicate that the value for the
+ * current CPU should be retrieved.
+ *
+ * Note that before Linux 4.13, only hardware perf event can be
+ * retrieved.
+ *
+ * Also, be aware that the newer helper
+ * **bpf_perf_event_read_value**\ () is recommended over
+ * **bpf_perf_event_read*\ () in general. The latter has some ABI
+ * quirks where error and counter value are used as a return code
+ * (which is wrong to do since ranges may overlap). This issue is
+ * fixed with bpf_perf_event_read_value(), which at the same time
+ * provides more features over the **bpf_perf_event_read**\ ()
+ * interface. Please refer to the description of
+ * **bpf_perf_event_read_value**\ () for details.
+ * Return
+ * The value of the perf event counter read from the map, or a
+ * negative error code in case of failure.
+ *
  * int bpf_redirect(u32 ifindex, u64 flags)
  * Description
  * Redirect the packet to another net device of index *ifindex*.
@@ -1071,6 +1100,17 @@ union bpf_attr {
  * Return
  * 0 on success, or a negative error in case of failure.
  *
+ * int bpf_skb_under_cgroup(struct sk_buff *skb, struct bpf_map *map, u32 
index)
+ * Description
+ * Check whether *skb* is a descendant of the cgroup2 held by
+ * *map* of type **BPF_MAP_TYPE_CGROUP_ARRAY**, at *index*.
+ * Return
+ * The return value depends on the result of the test, and can be:
+ *
+ * * 0, if the *skb* failed the cgroup2 descendant test.
+ * * 1, if the *skb* succeeded the cgroup2 descendant test.
+ * * A negative error code, if an error occurred.
+ *
  * u32 bpf_get_hash_recalc(struct sk_buff *skb)
  * Description
  * Retrieve the hash of the packet, *skb*\ **->hash**. If it is
@@ -1091,6 

[PATCH bpf-next v4 01/10] bpf: add script and prepare bpf.h for new helpers documentation

[Quentin Monnet]

Remove previous "overview" of eBPF helpers from user bpf.h header.
Replace it by a comment explaining how to process the new documentation
(to come in following patches) with a Python script to produce RST, then
man page documentation.

Also add the aforementioned Python script under scripts/. It is used to
process include/uapi/linux/bpf.h and to extract helper descriptions, to
turn it into a RST document that can further be processed with rst2man
to produce a man page. The script takes one "--filename "
option. If the script is launched from scripts/ in the kernel root
directory, it should be able to find the location of the header to
parse, and "--filename " is then optional. If it cannot
find the file, then the option becomes mandatory. RST-formatted
documentation is printed to standard output.

Typical workflow for producing the final man page would be:

$ ./scripts/bpf_helpers_doc.py \
--filename include/uapi/linux/bpf.h > /tmp/bpf-helpers.rst
$ rst2man /tmp/bpf-helpers.rst > /tmp/bpf-helpers.7
$ man /tmp/bpf-helpers.7

Note that the tool kernel-doc cannot be used to document eBPF helpers,
whose signatures are not available directly in the header files
(pre-processor directives are used to produce them at the beginning of
the compilation process).

v4:
- Also remove overviews for newly added bpf_xdp_adjust_tail() and
  bpf_skb_get_xfrm_state().
- Remove vague statement about what helpers are restricted to GPL
  programs in "LICENSE" section for man page footer.
- Replace license boilerplate with SPDX tag for Python script.

v3:
- Change license for man page.
- Remove "for safety reasons" from man page header text.
- Change "packets metadata" to "packets" in man page header text.
- Move and fix comment on helpers introducing no overhead.
- Remove "NOTES" section from man page footer.
- Add "LICENSE" section to man page footer.
- Edit description of file include/uapi/linux/bpf.h in man page footer.

Signed-off-by: Quentin Monnet 
---
 include/uapi/linux/bpf.h   | 422 ++---
 scripts/bpf_helpers_doc.py | 421 
 2 files changed, 437 insertions(+), 406 deletions(-)
 create mode 100755 scripts/bpf_helpers_doc.py

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index e6679393b687..df28a60d314c 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -377,412 +377,22 @@ union bpf_attr {
};
 } __attribute__((aligned(8)));
 
-/* BPF helper function descriptions:
- *
- * void *bpf_map_lookup_elem(, )
- * Return: Map value or NULL
- *
- * int bpf_map_update_elem(, , , flags)
- * Return: 0 on success or negative error
- *
- * int bpf_map_delete_elem(, )
- * Return: 0 on success or negative error
- *
- * int bpf_probe_read(void *dst, int size, void *src)
- * Return: 0 on success or negative error
- *
- * u64 bpf_ktime_get_ns(void)
- * Return: current ktime
- *
- * int bpf_trace_printk(const char *fmt, int fmt_size, ...)
- * Return: length of buffer written or negative error
- *
- * u32 bpf_prandom_u32(void)
- * Return: random value
- *
- * u32 bpf_raw_smp_processor_id(void)
- * Return: SMP processor ID
- *
- * int bpf_skb_store_bytes(skb, offset, from, len, flags)
- * store bytes into packet
- * @skb: pointer to skb
- * @offset: offset within packet from skb->mac_header
- * @from: pointer where to copy bytes from
- * @len: number of bytes to store into packet
- * @flags: bit 0 - if true, recompute skb->csum
- * other bits - reserved
- * Return: 0 on success or negative error
- *
- * int bpf_l3_csum_replace(skb, offset, from, to, flags)
- * recompute IP checksum
- * @skb: pointer to skb
- * @offset: offset within packet where IP checksum is located
- * @from: old value of header field
- * @to: new value of header field
- * @flags: bits 0-3 - size of header field
- * other bits - reserved
- * Return: 0 on success or negative error
- *
- * int bpf_l4_csum_replace(skb, offset, from, to, flags)
- * recompute TCP/UDP checksum
- * @skb: pointer to skb
- * @offset: offset within packet where TCP/UDP checksum is located
- * @from: old value of header field
- * @to: new value of header field
- * @flags: bits 0-3 - size of header field
- * bit 4 - is pseudo header
- * other bits - reserved
- * Return: 0 on success or negative error
- *
- * int bpf_tail_call(ctx, prog_array_map, index)
- * jump into another BPF program
- * @ctx: context pointer passed to next program
- * @prog_array_map: pointer to map which type is BPF_MAP_TYPE_PROG_ARRAY
- * @index: 32-bit index inside array that selects specific program to run
- * Return: 0 on success or negative error
- *
- * int bpf_clone_redirect(skb, ifindex, flags)
- * redirect to another netdev
- * @skb: pointer to skb
- * 

[PATCH bpf-next v4 04/10] bpf: add documentation for eBPF helpers (23-32)

[Quentin Monnet]

Add documentation for eBPF helper functions to bpf.h user header file.
This documentation can be parsed with the Python script provided in
another commit of the patch series, in order to provide a RST document
that can later be converted into a man page.

The objective is to make the documentation easily understandable and
accessible to all eBPF developers, including beginners.

This patch contains descriptions for the following helper functions, all
written by Daniel:

- bpf_get_prandom_u32()
- bpf_get_smp_processor_id()
- bpf_get_cgroup_classid()
- bpf_get_route_realm()
- bpf_skb_load_bytes()
- bpf_csum_diff()
- bpf_skb_get_tunnel_opt()
- bpf_skb_set_tunnel_opt()
- bpf_skb_change_proto()
- bpf_skb_change_type()

v4:
- bpf_get_prandom_u32(): Warn that the prng is not cryptographically
  secure.
- bpf_get_smp_processor_id(): Fix a typo (case).
- bpf_get_cgroup_classid(): Clarify description. Add notes on the helper
  being limited to cgroup v1, and to egress path.
- bpf_get_route_realm(): Add comparison with bpf_get_cgroup_classid().
  Add a note about usage with TC and advantage of clsact. Fix a typo in
  return value ("sdb" instead of "skb").
- bpf_skb_load_bytes(): Make explicit loading large data loads it to the
  eBPF stack.
- bpf_csum_diff(): Add a note on seed that can be cascaded. Link to
  bpf_l3|l4_csum_replace().
- bpf_skb_get_tunnel_opt(): Add a note about usage with "collect
  metadata" mode, and example of this with Geneve.
- bpf_skb_set_tunnel_opt(): Add a link to bpf_skb_get_tunnel_opt()
  description.
- bpf_skb_change_proto(): Mention that the main use case is NAT64.
  Clarify comment about invalidated verifier checks.

v3:
- bpf_get_prandom_u32(): Fix helper name :(. Add description, including
  a note on the internal random state.
- bpf_get_smp_processor_id(): Add description, including a note on the
  processor id remaining stable during program run.
- bpf_get_cgroup_classid(): State that CONFIG_CGROUP_NET_CLASSID is
  required to use the helper. Add a reference to related documentation.
  State that placing a task in net_cls controller disables cgroup-bpf.
- bpf_get_route_realm(): State that CONFIG_CGROUP_NET_CLASSID is
  required to use this helper.
- bpf_skb_load_bytes(): Fix comment on current use cases for the helper.

Cc: Daniel Borkmann 
Signed-off-by: Quentin Monnet 
Acked-by: Alexei Starovoitov 
---
 include/uapi/linux/bpf.h | 197 +++
 1 file changed, 197 insertions(+)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 368d83cf02d8..28681cef14d4 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -495,6 +495,27 @@ union bpf_attr {
  * The number of bytes written to the buffer, or a negative error
  * in case of failure.
  *
+ * u32 bpf_get_prandom_u32(void)
+ * Description
+ * Get a pseudo-random number.
+ *
+ * From a security point of view, this helper uses its own
+ * pseudo-random internal state, and cannot be used to infer the
+ * seed of other random functions in the kernel. However, it is
+ * essential to note that the generator used by the helper is not
+ * cryptographically secure.
+ * Return
+ * A random 32-bit unsigned value.
+ *
+ * u32 bpf_get_smp_processor_id(void)
+ * Description
+ * Get the SMP (symmetric multiprocessing) processor id. Note that
+ * all programs run with preemption disabled, which means that the
+ * SMP processor id is stable during all the execution of the
+ * program.
+ * Return
+ * The SMP id of the processor running the program.
+ *
  * int bpf_skb_store_bytes(struct sk_buff *skb, u32 offset, const void *from, 
u32 len, u64 flags)
  * Description
  * Store *len* bytes from address *from* into the packet
@@ -647,6 +668,32 @@ union bpf_attr {
  * Return
  * 0 on success, or a negative error in case of failure.
  *
+ * u32 bpf_get_cgroup_classid(struct sk_buff *skb)
+ * Description
+ * Retrieve the classid for the current task, i.e. for the net_cls
+ * cgroup to which *skb* belongs.
+ *
+ * This helper can be used on TC egress path, but not on ingress.
+ *
+ * The net_cls cgroup provides an interface to tag network packets
+ * based on a user-provided identifier for all traffic coming from
+ * the tasks belonging to the related cgroup. See also the related
+ * kernel documentation, available from the Linux sources in file
+ * *Documentation/cgroup-v1/net_cls.txt*.
+ *
+ * The Linux kernel has two versions for cgroups: there are
+ * cgroups v1 and cgroups v2. Both are available to users, who can
+ * use a mixture of them, but note that the net_cls 

[PATCH bpf-next v4 00/10] bpf: document eBPF helpers and add a script to generate man page

[Quentin Monnet]

eBPF helper functions can be called from within eBPF programs to perform
a variety of tasks that would be otherwise hard or impossible to do with
eBPF itself. There is a growing number of such helper functions in the
kernel, but documentation is scarce. The main user space header file
does contain a short commented description of most helpers, but it is
somewhat outdated and not complete. It is more a "cheat sheet" than a
real documentation accessible to new eBPF developers.

This commit attempts to improve the situation by replacing the existing
overview for the helpers with a more developed description. Furthermore,
a Python script is added to generate a manual page for eBPF helpers. The
workflow is the following, and requires the rst2man utility:

$ ./scripts/bpf_helpers_doc.py \
--filename include/uapi/linux/bpf.h > /tmp/bpf-helpers.rst
$ rst2man /tmp/bpf-helpers.rst > /tmp/bpf-helpers.7
$ man /tmp/bpf-helpers.7

The objective is to keep all documentation related to the helpers in a
single place, and to be able to generate from here a manual page that
could be packaged in the man-pages repository and shipped with most
distributions.

Additionally, parsing the prototypes of the helper functions could
hopefully be reused, with a different Printer object, to generate
header files needed in some eBPF-related projects.

Regarding the description of each helper, it comprises several items:

- The function prototype.
- A description of the function and of its arguments (except for a
  couple of cases, when there are no arguments and the return value
  makes the function usage really obvious).
- A description of return values (if not void).

Additional items such as the list of compatible eBPF program and map
types for each helper, Linux kernel version that introduced the helper,
GPL-only restriction, and commit hash could be added in the future, but
it was decided on the mailing list to leave them aside for now.

For several helpers, descriptions are inspired (at times, nearly copied)
from the commit logs introducing them in the kernel--Many thanks to
their respective authors! Some sentences were also adapted from comments
from the reviews, thanks to the reviewers as well. Descriptions were
completed as much as possible, the objective being to have something easily
accessible even for people just starting with eBPF. There is probably a bit
more work to do in this direction for some helpers.

Some RST formatting is used in the descriptions (not in function
prototypes, to keep them readable, but the Python script provided in
order to generate the RST for the manual page does add formatting to
prototypes, to produce something pretty) to get "bold" and "italics" in
manual pages. Hopefully, the descriptions in bpf.h file remains
perfectly readable. Note that the few trailing white spaces are
intentional, removing them would break paragraphs for rst2man.

The descriptions should ideally be updated each time someone adds a new
helper, or updates the behaviour (new socket option supported, ...) or
the interface (new flags available, ...) of existing ones.

To ease the review process, the documentation has been split into several
patches.

v3 -> v4:
- Add a patch (#9) for newly added BPF helpers.
- Add a patch (#10) to update UAPI bpf.h version under tools/.
- Use SPDX tag in Python script.
- Several fixes on man page header and footer, and helpers documentation.
  Please refer to individual patches for details.

RFC v2 -> PATCH v3:
Several fixes on man page header and footer, and helpers documentation.
Please refer to individual patches for details.

RFC v1 -> RFC v2:
- Remove "For" (compatible program and map types), "Since" (minimal
  Linux kernel version required), "GPL only" sections and commit hashes
  for the helpers.
- Add comment on top of the description list to explain how this
  documentation is supposed to be processed.
- Update Python script accordingly (remove the same sections, and remove
  paragraphs on program types and GPL restrictions from man page
  header).
- Split series into several patches.

Cc: linux-doc@vger.kernel.org
Cc: linux-...@vger.kernel.org

Quentin Monnet (10):
  bpf: add script and prepare bpf.h for new helpers documentation
  bpf: add documentation for eBPF helpers (01-11)
  bpf: add documentation for eBPF helpers (12-22)
  bpf: add documentation for eBPF helpers (23-32)
  bpf: add documentation for eBPF helpers (33-41)
  bpf: add documentation for eBPF helpers (42-50)
  bpf: add documentation for eBPF helpers (51-57)
  bpf: add documentation for eBPF helpers (58-64)
  bpf: add documentation for eBPF helpers (65-66)
  bpf: update bpf.h uapi header for tools

 include/uapi/linux/bpf.h   | 1776 +++-
 scripts/bpf_helpers_doc.py |  421 ++
 tools/include/uapi/linux/bpf.h | 1776 +++-
 3 files changed, 3181 insertions(+), 792 deletions(-)
 create mode 100755 

Re: [PATCH v5 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V

[Palmer Dabbelt]

On Tue, 24 Apr 2018 20:19:36 PDT (-0700), alan...@andestech.com wrote:

Hi Atish, Palmer,

On Tue, Apr 24, 2018 at 06:15:49PM -0700, Atish Patra wrote:

On 4/24/18 5:29 PM, Palmer Dabbelt wrote:
>On Tue, 24 Apr 2018 15:16:16 PDT (-0700), atish.pa...@wdc.com wrote:
>>On 4/24/18 12:44 PM, Palmer Dabbelt wrote:
>>>On Tue, 24 Apr 2018 12:27:26 PDT (-0700), atish.pa...@wdc.com wrote:
On 4/24/18 11:07 AM, Atish Patra wrote:
>On 4/19/18 4:28 PM, Alan Kao wrote:
>However, I got an rcu-stall for the test "47: Event times".
># ./perf test -v 47
Got it working. The test tries to attach the event to CPU0 which doesn't
exist in HighFive Unleashed. Changing it to cpu1 works.

diff --git a/tools/perf/tests/event-times.c b/tools/perf/tests/event-times.c
index 1a2686f..eb11632f 100644
--- a/tools/perf/tests/event-times.c
+++ b/tools/perf/tests/event-times.c
@@ -113,9 +113,9 @@ static int attach__cpu_disabled(struct perf_evlist
*evlist)
   struct cpu_map *cpus;
   int err;

-   pr_debug("attaching to CPU 0 as enabled\n");
+   pr_debug("attaching to CPU 1 as disabled\n");

-   cpus = cpu_map__new("0");
+   cpus = cpu_map__new("1");
   if (cpus == NULL) {
   pr_debug("failed to call cpu_map__new\n");
   return -1;
@@ -142,9 +142,9 @@ static int attach__cpu_enabled(struct perf_evlist
*evlist)
   struct cpu_map *cpus;
   int err;

-   pr_debug("attaching to CPU 0 as enabled\n");
+   pr_debug("attaching to CPU 1 as enabled\n");

-   cpus = cpu_map__new("0");
+   cpus = cpu_map__new("1");
   if (cpus == NULL) {
   pr_debug("failed to call cpu_map__new\n");
   return -1;


Palmer,
Would it be better to officially document it somewhere that CPU0 doesn't
exist in the HighFive Unleashed board ?
I fear that there will be other standard tests/code path that may fail
because of inherent assumption of cpu0 presence.
>>>
>>>I think the best way to fix this is to just have BBL (or whatever the
>>>bootloader is) renumber the CPUs so they're contiguous and begin with 0.
>>
>>Do you mean BBL will update the device tree that kernel eventually parse
>>and set the hart id?
>>Sounds good to me unless it acts as a big hack in future boot loaders.
>
>Right now the machine-mode and supervisor-mode hart IDs are logically separate:
>the bootloader just provides the hart ID as a register argument when starting
>the kernel.

Yes.

  BBL already needs to enumerate the harts by looking through the
>device tree for various other reasons (at least to mask off the harts that
>Linux doesn't support), so it's not that much effort to just maintain a mapping
>from supervisor-mode hart IDs to machine-mode hart IDs.
>

But Linux also parses the device tree to get hart ID in
riscv_of_processor_hart(). This is used to setup the possible/present cpu
map in setup_smp().

Thus, Linux also need to see a device tree with cpu0-3 instead of cpu1-4.
Otherwise, present cpu map will be incorrect. Isn't it ?

>I have some patches floating around that do this, but appear to do it
>incorrectly enough that nothing boots so maybe I'm missing something that makes
>this complicated :).
>

Just a wild guess: May be the because of the above reason ;)



Thanks for the test and discussion.  It looks like am implementation issue from
Unleash, so ... is there anything I should fix and provide a further patch?


You're welcome to fix BBL if you want, but that's unrelated to this patch set.  
I'm going to look over the code again as soon as I get a chance to, thanks for 
submitting the patches!

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v5 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V

[Palmer Dabbelt]

On Tue, 24 Apr 2018 18:15:49 PDT (-0700), atish.pa...@wdc.com wrote:

On 4/24/18 5:29 PM, Palmer Dabbelt wrote:

On Tue, 24 Apr 2018 15:16:16 PDT (-0700), atish.pa...@wdc.com wrote:

On 4/24/18 12:44 PM, Palmer Dabbelt wrote:

On Tue, 24 Apr 2018 12:27:26 PDT (-0700), atish.pa...@wdc.com wrote:

On 4/24/18 11:07 AM, Atish Patra wrote:

On 4/19/18 4:28 PM, Alan Kao wrote:
However, I got an rcu-stall for the test "47: Event times".
# ./perf test -v 47

Got it working. The test tries to attach the event to CPU0 which doesn't
exist in HighFive Unleashed. Changing it to cpu1 works.

diff --git a/tools/perf/tests/event-times.c b/tools/perf/tests/event-times.c
index 1a2686f..eb11632f 100644
--- a/tools/perf/tests/event-times.c
+++ b/tools/perf/tests/event-times.c
@@ -113,9 +113,9 @@ static int attach__cpu_disabled(struct perf_evlist
*evlist)
   struct cpu_map *cpus;
   int err;

-   pr_debug("attaching to CPU 0 as enabled\n");
+   pr_debug("attaching to CPU 1 as disabled\n");

-   cpus = cpu_map__new("0");
+   cpus = cpu_map__new("1");
   if (cpus == NULL) {
   pr_debug("failed to call cpu_map__new\n");
   return -1;
@@ -142,9 +142,9 @@ static int attach__cpu_enabled(struct perf_evlist
*evlist)
   struct cpu_map *cpus;
   int err;

-   pr_debug("attaching to CPU 0 as enabled\n");
+   pr_debug("attaching to CPU 1 as enabled\n");

-   cpus = cpu_map__new("0");
+   cpus = cpu_map__new("1");
   if (cpus == NULL) {
   pr_debug("failed to call cpu_map__new\n");
   return -1;


Palmer,
Would it be better to officially document it somewhere that CPU0 doesn't
exist in the HighFive Unleashed board ?
I fear that there will be other standard tests/code path that may fail
because of inherent assumption of cpu0 presence.


I think the best way to fix this is to just have BBL (or whatever the
bootloader is) renumber the CPUs so they're contiguous and begin with 0.


Do you mean BBL will update the device tree that kernel eventually parse
and set the hart id?
Sounds good to me unless it acts as a big hack in future boot loaders.


Right now the machine-mode and supervisor-mode hart IDs are logically separate:
the bootloader just provides the hart ID as a register argument when starting
the kernel.


Yes.

   BBL already needs to enumerate the harts by looking through the

device tree for various other reasons (at least to mask off the harts that
Linux doesn't support), so it's not that much effort to just maintain a mapping
from supervisor-mode hart IDs to machine-mode hart IDs.



But Linux also parses the device tree to get hart ID in
riscv_of_processor_hart(). This is used to setup the possible/present
cpu map in setup_smp().

Thus, Linux also need to see a device tree with cpu0-3 instead of
cpu1-4. Otherwise, present cpu map will be incorrect. Isn't it ?


I have some patches floating around that do this, but appear to do it
incorrectly enough that nothing boots so maybe I'm missing something that makes
this complicated :).



Just a wild guess: May be the because of the above reason ;)


I was already changing all the IDs in the device tree, so that wasn't it.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 09/15] ARM: dts: dra72-evm-common: Add wilink8 wlan support

[Rob Herring]

On Wed, Apr 25, 2018 at 7:54 AM, Kishon Vijay Abraham I  wrote:
> From: Hari Nagalla 
>
> Wilink8 module is a combo wireless connectivity card based
> on Texas Instrument's wl18xx solution.
>
> Add support for the wlan capabilities of this module by muxing
> the relevant mmc lines, and setting the required device-tree
> data.
>
> Signed-off-by: Eyal Reizer 
> Signed-off-by: Hari Nagalla 
> [nsek...@ti.com: drop WLAN_EN pinmux. It should be done by bootloader.
>  Also, some commit message adjustments]
> Signed-off-by: Sekhar Nori 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  arch/arm/boot/dts/dra72-evm-common.dtsi   | 42 +++
>  arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi | 11 ++
>  2 files changed, 53 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra72-evm-common.dtsi 
> b/arch/arm/boot/dts/dra72-evm-common.dtsi
> index 8e3b185d864b..1e4d36e33a1b 100644
> --- a/arch/arm/boot/dts/dra72-evm-common.dtsi
> +++ b/arch/arm/boot/dts/dra72-evm-common.dtsi
> @@ -44,6 +44,16 @@
> regulator-boot-on;
> };
>
> +   evm_3v6: fixedregulator-evm_3v6 {
> +   compatible = "regulator-fixed";
> +   regulator-name = "evm_3v6";
> +   regulator-min-microvolt = <360>;
> +   regulator-max-microvolt = <360>;
> +   vin-supply = <_5v0>;
> +   regulator-always-on;
> +   regulator-boot-on;
> +   };
> +
> vsys_3v3: fixedregulator-vsys3v3 {
> /* Output 2 of TPS43351QDAPRQ1 on dra72-evm */
> /* Output 2 of LM5140QRWGTQ1 on dra71-evm */
> @@ -171,6 +181,15 @@
> clocks = <_clkin2_ck>;
> };
> };
> +
> +   vmmcwl_fixed: fixedregulator-mmcwl {
> +   compatible = "regulator-fixed";
> +   regulator-name = "vmmcwl_fixed";
> +   regulator-min-microvolt = <180>;
> +   regulator-max-microvolt = <180>;
> +   gpio = < 8 GPIO_ACTIVE_HIGH>;
> +   enable-active-high;
> +   };
>  };
>
>  _pmx_core {
> @@ -398,6 +417,29 @@
> max-frequency = <19200>;
>  };
>
> + {
> +   status = "okay";
> +   vmmc-supply = <_3v6>;
> +   vqmmc-supply = <_fixed>;
> +   bus-width = <4>;
> +   cap-power-off-card;
> +   keep-power-in-suspend;
> +   non-removable;
> +   pinctrl-names = "default", "hs", "sdr12", "sdr25";
> +   pinctrl-0 = <_pins_default>;
> +   pinctrl-1 = <_pins_default>;
> +   pinctrl-2 = <_pins_default>;
> +   pinctrl-3 = <_pins_default>;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   wlcore: wlcore@2 {

wifi@2
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 11/15] ARM: dts: dra7-evm: Add wilink8 wlan support

[Rob Herring]

On Wed, Apr 25, 2018 at 7:54 AM, Kishon Vijay Abraham I  wrote:
> From: Hari Nagalla 
>
> The wilink module is a combo wireless connectivity sdio
> card based on Texas Instrument's wl18xx solution. It is a
> 4-wire, 1.8V, embedded sdio wlan device with an external
> irq line and is power-controlled by a gpio-based fixed
> regulator.
>
> Add pinmux configuration and IODelay values for MMC4.
> On dra7-evm, MMC4 is used for connecting to wilink module.
>
> IODelay data credits to :  Vishal Mahaveer 
> and Sekhar Nori 
>
> Signed-off-by: Ido Yariv 
> Signed-off-by: Eyal Reizer 
> Signed-off-by: Hari Nagalla 
> Signed-off-by: Sekhar Nori 
> Signed-off-by: Kishon Vijay Abraham I 
> ---
>  arch/arm/boot/dts/dra7-evm-common.dtsi | 15 +++
>  arch/arm/boot/dts/dra7-evm.dts | 25 +
>  2 files changed, 40 insertions(+)
>
> diff --git a/arch/arm/boot/dts/dra7-evm-common.dtsi 
> b/arch/arm/boot/dts/dra7-evm-common.dtsi
> index 05a7b1a01bc3..3590c40fc112 100644
> --- a/arch/arm/boot/dts/dra7-evm-common.dtsi
> +++ b/arch/arm/boot/dts/dra7-evm-common.dtsi
> @@ -260,3 +260,18 @@
>  _rc {
> status = "okay";
>  };
> +
> + {
> +   bus-width = <4>;
> +   cap-power-off-card;
> +   keep-power-in-suspend;
> +   non-removable;
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +   wlcore: wlcore@2 {

wifi@2
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/6] arm64: untag user pointers passed to the kernel

[Andrey Konovalov]

On Thu, Apr 19, 2018 at 11:33 AM, Kirill A. Shutemov
 wrote:
> On Wed, Apr 18, 2018 at 08:53:09PM +0200, Andrey Konovalov wrote:
>> Hi!
>>
>> arm64 has a feature called Top Byte Ignore, which allows to embed pointer
>> tags into the top byte of each pointer. Userspace programs (such as
>> HWASan, a memory debugging tool [1]) might use this feature and pass
>> tagged user pointers to the kernel through syscalls or other interfaces.
>>
>> This patch makes a few of the kernel interfaces accept tagged user
>> pointers. The kernel is already able to handle user faults with tagged
>> pointers and has the untagged_addr macro, which this patchset reuses.
>>
>> We're not trying to cover all possible ways the kernel accepts user
>> pointers in one patchset, so this one should be considered as a start.
>
> How many changes do you anticipate?
>
> This patchset looks small and reasonable, but I see a potential to become a
> boilerplate. Would we need to change every driver which implements ioctl()
> to strip these bits?

I've replied to somewhat similar question in one of the previous
versions of the patchset.

"""
There are two different approaches to untagging the user pointers that I see:

1. Untag user pointers right after they are passed to the kernel.

While this might be possible for pointers that are passed to syscalls
as arguments (Catalin's "hack"), this leaves user pointers, that are
embedded into for example structs that are passed to the kernel. Since
there's no specification of the interface between user space and the
kernel, different kernel parts handle user pointers differently and I
don't see an easy way to cover them all.

2. Untag user pointers where they are used in the kernel.

Although there's no specification on the interface between the user
space and the kernel, the kernel still has to use one of a few
specific ways to access user data (copy_from_user, etc.). So the idea
here is to add untagging into them. This patchset mostly takes this
approach (with the exception of memory subsystem syscalls).

If there's a better approach, I'm open to suggestions.
"""

So if we go with the first way, we'll need to go through every syscall
and ioctl handler, which doesn't seem feasible.
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" 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] Documentation: typec.rst: Use literal-block element with ascii art

[Greg KH]

On Wed, Apr 25, 2018 at 04:47:01PM +0300, Jani Nikula wrote:
> On Fri, 06 Apr 2018, Heikki Krogerus  wrote:
> > Using reStructuredText literal-block element with ascii-art.
> > That prevents the ascii art from being processed as
> > reStructuredText.
> >
> > Reported-by: Masanari Iida 
> > Fixes: bdecb33af34f ("usb: typec: API for controlling USB Type-C 
> > Multiplexers")
> > Signed-off-by: Heikki Krogerus 
> 
> Jon, this fixes a documentation build failure in v4.17-rc1. It's not
> just a warning, it's a complete fail. Our docs builder at 01.org is
> failing, apparently the same at kernel.org. Please pick it up soon.

This is in my tree, will go to Linus in a day or so.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" 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] Documentation: typec.rst: Use literal-block element with ascii art

[Jonathan Corbet]

On Wed, 25 Apr 2018 16:47:01 +0300
Jani Nikula  wrote:

> On Fri, 06 Apr 2018, Heikki Krogerus  wrote:
> > Using reStructuredText literal-block element with ascii-art.
> > That prevents the ascii art from being processed as
> > reStructuredText.
> >
> > Reported-by: Masanari Iida 
> > Fixes: bdecb33af34f ("usb: typec: API for controlling USB Type-C 
> > Multiplexers")
> > Signed-off-by: Heikki Krogerus   
> 
> Jon, this fixes a documentation build failure in v4.17-rc1. It's not
> just a warning, it's a complete fail. Our docs builder at 01.org is
> failing, apparently the same at kernel.org. Please pick it up soon.

Sorry, I'd seen the attached and was assuming Greg would ship it
Linusward.  I'll get it upstream soon.

jon

From: Greg KH 
To: changbin...@intel.com
Cc: cor...@lwn.net, linux-doc@vger.kernel.org, 
linux-ker...@vger.kernel.org
Subject: Re: [PATCH] Documentation: fix reST markup error in  
driver-api/usb/typec.rst
Date: Sun, 8 Apr 2018 09:19:58 +0200
Sender: linux-kernel-ow...@vger.kernel.org

On Sun, Apr 08, 2018 at 10:47:12AM +0800, changbin...@intel.com wrote:
> From: Changbin Du 
> 
> There is an format error in driver-api/usb/typec.rst that breaks sphinx
> docs building.
> 
> reST markup error:
> /home/changbin/work/linux/Documentation/driver-api/usb/typec.rst:215: 
> (SEVERE/4) Unexpected section title or transition.
> 
> 
> Documentation/Makefile:68: recipe for target 'htmldocs' failed
> make[1]: *** [htmldocs] Error 1
> Makefile:1527: recipe for target 'htmldocs' failed
> make: *** [htmldocs] Error 2
> 
> Signed-off-by: Changbin Du 
> ---
>  Documentation/driver-api/usb/typec.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)  

Thanks, someone else already sent this, sorry.  I'll be sending it
onward after 4.17-rc1 is out.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" 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] Documentation: typec.rst: Use literal-block element with ascii art

[Jani Nikula]

On Fri, 06 Apr 2018, Heikki Krogerus  wrote:
> Using reStructuredText literal-block element with ascii-art.
> That prevents the ascii art from being processed as
> reStructuredText.
>
> Reported-by: Masanari Iida 
> Fixes: bdecb33af34f ("usb: typec: API for controlling USB Type-C 
> Multiplexers")
> Signed-off-by: Heikki Krogerus 

Jon, this fixes a documentation build failure in v4.17-rc1. It's not
just a warning, it's a complete fail. Our docs builder at 01.org is
failing, apparently the same at kernel.org. Please pick it up soon.

Thanks,
Jani.

> ---
> Changed since v1:
> - Using literal-block element instead of comment
> - Subject in v1 was "Documentation: typec.rst: Mark ascii art as a comment"
> ---
>  Documentation/driver-api/usb/typec.rst | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/driver-api/usb/typec.rst 
> b/Documentation/driver-api/usb/typec.rst
> index feb31946490b..48ff58095f11 100644
> --- a/Documentation/driver-api/usb/typec.rst
> +++ b/Documentation/driver-api/usb/typec.rst
> @@ -210,7 +210,7 @@ If the connector is dual-role capable, there may also be 
> a switch for the data
>  role. USB Type-C Connector Class does not supply separate API for them. The
>  port drivers can use USB Role Class API with those.
>  
> -Illustration of the muxes behind a connector that supports an alternate mode:
> +Illustration of the muxes behind a connector that supports an alternate 
> mode::
>  
>   
>   |   Connector  |

-- 
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 04/15] ARM: dts: dra74x-mmc-iodelay: Add a new pinctrl group for clk line without pullup

[Tony Lindgren]

* Kishon Vijay Abraham I  [180425 12:57]:
> --- a/arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi
> +++ b/arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi
> @@ -49,6 +49,17 @@
>   >;
>   };
>  
> + mmc1_pins_default_no_clk_pu: mmc1_pins_default_no_clk_pu {
> + pinctrl-single,pins = <
> + DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLDOWN | 
> MUX_MODE0) /* mmc1_clk.clk */
> + DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) 
> /* mmc1_cmd.cmd */
> + DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) 
> /* mmc1_dat0.dat0 */
> + DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) 
> /* mmc1_dat1.dat1 */
> + DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) 
> /* mmc1_dat2.dat2 */
> + DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) 
> /* mmc1_dat3.dat3 */
> + >;
> + };
> +
>   mmc1_pins_sdr12: mmc1_pins_sdr12 {
>   pinctrl-single,pins = <
>   DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_MODE0) 
> /* mmc1_clk.clk */
> -- 

If this data is the same for all of them, why don't you add something
like dra7-iodelay.dtsi that can be included as needed?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 15/15] Documentation: ARM: Add new MMC requirements for DRA7/K2G

[Kishon Vijay Abraham I]

>From 4.18 kernel, all the MMC controller instances in DRA7
are programmed using sdhci based driver (sdhci-omap.c). Document
this new requirement here. Both omap2plus_defconfig and
multi_v7_defconfig has CONFIG_MMC_SDHCI_OMAP enabled.

Signed-off-by: Kishon Vijay Abraham I 
---
Changes from v3:
Add K2G also in the dependencies description

 Documentation/arm/OMAP/README | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/arm/OMAP/README b/Documentation/arm/OMAP/README
index 75645c45d14a..5bf5ac3b3ed4 100644
--- a/Documentation/arm/OMAP/README
+++ b/Documentation/arm/OMAP/README
@@ -5,3 +5,7 @@ KERNEL  NEW DEPENDENCIES
 v4.3+  Update is needed for custom .config files to make sure
CONFIG_REGULATOR_PBIAS is enabled for MMC1 to work
properly.
+
+v4.18+ Update is needed for custom .config files to make sure
+   CONFIG_MMC_SDHCI_OMAP is enabled for all MMC instances
+   to work in DRA7 and K2G based boards.
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 02/15] ARM: dts: dra71-evm: Add "vqmmc-supply" property for mmc2

[Kishon Vijay Abraham I]

Add "vqmmc-supply" property for mmc2 to indicate the supply connected
to the IO lines.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra71-evm.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/dra71-evm.dts b/arch/arm/boot/dts/dra71-evm.dts
index ebc4bbae981e..64c57d87ca2f 100644
--- a/arch/arm/boot/dts/dra71-evm.dts
+++ b/arch/arm/boot/dts/dra71-evm.dts
@@ -204,6 +204,7 @@
pinctrl-2 = <_pins_ddr_rev20 _iodelay_ddr_conf>;
pinctrl-3 = <_pins_hs200 _iodelay_hs200_rev20_conf>;
vmmc-supply = <_1v8_sw>;
+   vqmmc-supply = <_1v8_sw>;
 };
 
  {
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 00/15] dra7: mmc: Update mmc dt node to use sdhci-omap

[Kishon Vijay Abraham I]

Previous version of the patch series was sent here
https://lkml.org/lkml/2018/2/6/250

Most of the patches sent for v2 was merged. Remaining unmerged patches
from v2 and a few additional patches are sent here.

This series should be merged only after [1].
[1] -> https://marc.info/?l=linux-kernel=152465820531802=2

This series:
 *) Adds wilink wlan support (Now all MMC instances in DRA7 will use
sdhci-omap)
 *) Add a new pinctrl group for clk line without pullup required for
UHS cards to work reliably.
 *) Update README to make sure users update .config file from 4.18
kernel.
 *) Use sdhci-omap programming model.

In the "Use sdhci-omap programming model" patch, "ti,omap4-hsmmc"
compatible is removed. This is because if both "ti,dra7-sdhci" and
"ti,omap4-hsmmc" is added and if there is probe deferral in sdhci_omap
driver, the device is binding to omap_hsmmc driver.

Once omap_hsmmc and sdhci_omap driver are feature identical,
sdhci_omap driver will be made to support omap_hsmmc binding
(including "ti,omap4-hsmmc" compatible) and omap_hsmmc driver will
be removed. Till then dt nodes with "ti,omap4-hsmmc" compatible
will use omap_hsmmc driver and "ti,dra7-sdhci" compatible will
use sdhci_omap driver.

Hari Nagalla (2):
  ARM: dts: dra72-evm-common: Add wilink8 wlan support
  ARM: dts: dra7-evm: Add wilink8 wlan support

Kishon Vijay Abraham I (11):
  ARM: dts: dra72-evm-common: Remove mmc specific pinmux
  ARM: dts: dra71-evm: Add "vqmmc-supply" property for mmc2
  ARM: dts: dra72x-mmc-iodelay: Add a new pinctrl group for clk line
without pullup
  ARM: dts: dra74x-mmc-iodelay: Add a new pinctrl group for clk line
without pullup
  ARM: dts: dra76x-mmc-iodelay: Add a new pinctrl group for clk line
without pullup
  ARM: dts: am57xx-idk: Use pinctrl group from dra7xx-mmc-iodelay.dtsi
to select pulldown
  ARM: dts: dra71-evm: Use pinctrl group from dra72x-mmc-iodelay.dtsi to
select pulldown
  ARM: dts: dra7-evm: Model EVM_3V6 regulator
  ARM: dts: dra7: Use sdhci-omap programming model
  ARM: dts: dra7: Add high speed modes capability to MMC1/MMC2 dt node
  Documentation: ARM: Add new MMC requirements for DRA7/K2G

Sekhar Nori (1):
  ARM: dts: am574x-idk: Add pinmux configuration for MMC

Vishal Mahaveer (1):
  ARM: dts: dra76-evm: Add wilink8 wlan support

 Documentation/arm/OMAP/README |  4 ++
 arch/arm/boot/dts/am571x-idk.dts  |  2 +-
 arch/arm/boot/dts/am572x-idk.dts  |  2 +-
 arch/arm/boot/dts/am574x-idk.dts  | 19 +
 .../boot/dts/am57xx-beagle-x15-common.dtsi|  4 +-
 arch/arm/boot/dts/am57xx-beagle-x15.dts   |  1 +
 arch/arm/boot/dts/am57xx-idk-common.dtsi  |  3 +-
 arch/arm/boot/dts/dra7-evm-common.dtsi| 15 
 arch/arm/boot/dts/dra7-evm.dts| 68 ++
 arch/arm/boot/dts/dra7.dtsi   | 30 
 arch/arm/boot/dts/dra71-evm.dts   | 16 +
 arch/arm/boot/dts/dra72-evm-common.dtsi   | 71 +++
 arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi | 22 ++
 arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi | 11 +++
 arch/arm/boot/dts/dra76-evm.dts   | 34 -
 arch/arm/boot/dts/dra76x-mmc-iodelay.dtsi | 11 +++
 16 files changed, 248 insertions(+), 65 deletions(-)

-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 03/15] ARM: dts: dra72x-mmc-iodelay: Add a new pinctrl group for clk line without pullup

[Kishon Vijay Abraham I]

During a short period when the bus voltage is switched from 3.3v to 1.8v,
(to enumerate UHS mode), the mmc module is disabled and the mmc IO lines
are kept in a state according to the programmed pad mux pull type.

According to 4.2.4.2 Timing to Switch Signal Voltage in "SD Specifications
Part 1 Physical Layer Specification Version 5.00 February 22, 2016", the
host should hold CLK low for at least 5ms.

In order to keep the card line low during voltage switch, the pad mux of
mmc1_clk line should be configured to pull down.

Add a new pinctrl group for clock line without pullup to be used in boards
where mmc1_clk line is not connected to an external pullup.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi 
b/arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi
index 088013c6dc6e..c9351eaf97f0 100644
--- a/arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi
+++ b/arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi
@@ -51,6 +51,17 @@
>;
};
 
+   mmc1_pins_default_no_clk_pu: mmc1_pins_default_no_clk_pu {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLDOWN | 
MUX_MODE0) /* mmc1_clk.clk */
+   DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_cmd.cmd */
+   DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat0.dat0 */
+   DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat1.dat1 */
+   DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat2.dat2 */
+   DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat3.dat3 */
+   >;
+   };
+
mmc1_pins_sdr12: mmc1_pins_sdr12 {
pinctrl-single,pins = <
DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_clk.clk */
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 01/15] ARM: dts: dra72-evm-common: Remove mmc specific pinmux

[Kishon Vijay Abraham I]

mmc specific pinmux is selected from dra72x-mmc-iodelay.dtsi, so remove
it from dra72-evm-common.dtsi.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra72-evm-common.dtsi | 27 -
 1 file changed, 27 deletions(-)

diff --git a/arch/arm/boot/dts/dra72-evm-common.dtsi 
b/arch/arm/boot/dts/dra72-evm-common.dtsi
index e85f560a2f78..8e3b185d864b 100644
--- a/arch/arm/boot/dts/dra72-evm-common.dtsi
+++ b/arch/arm/boot/dts/dra72-evm-common.dtsi
@@ -174,33 +174,6 @@
 };
 
 _pmx_core {
-   mmc1_pins_default: mmc1_pins_default {
-   pinctrl-single,pins = <
-   DRA7XX_CORE_IOPAD(0x376c, PIN_INPUT | MUX_MODE14)   
/* mmc1sdcd.gpio219 */
-   DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_clk.clk */
-   DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_cmd.cmd */
-   DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat0.dat0 */
-   DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat1.dat1 */
-   DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat2.dat2 */
-   DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat3.dat3 */
-   >;
-   };
-
-   mmc2_pins_default: mmc2_pins_default {
-   pinctrl-single,pins = <
-   DRA7XX_CORE_IOPAD(0x349c, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a23.mmc2_clk */
-   DRA7XX_CORE_IOPAD(0x34b0, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_cs1.mmc2_cmd */
-   DRA7XX_CORE_IOPAD(0x34a0, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a24.mmc2_dat0 */
-   DRA7XX_CORE_IOPAD(0x34a4, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a25.mmc2_dat1 */
-   DRA7XX_CORE_IOPAD(0x34a8, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a26.mmc2_dat2 */
-   DRA7XX_CORE_IOPAD(0x34ac, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a27.mmc2_dat3 */
-   DRA7XX_CORE_IOPAD(0x348c, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a19.mmc2_dat4 */
-   DRA7XX_CORE_IOPAD(0x3490, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a20.mmc2_dat5 */
-   DRA7XX_CORE_IOPAD(0x3494, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a21.mmc2_dat6 */
-   DRA7XX_CORE_IOPAD(0x3498, PIN_INPUT_PULLUP | MUX_MODE1) 
/* gpmc_a22.mmc2_dat7 */
-   >;
-   };
-
dcan1_pins_default: dcan1_pins_default {
pinctrl-single,pins = <
DRA7XX_CORE_IOPAD(0x37d0, PIN_OUTPUT_PULLUP | 
MUX_MODE0) /* dcan1_tx */
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 06/15] ARM: dts: am57xx-idk: Use pinctrl group from dra7xx-mmc-iodelay.dtsi to select pulldown

[Kishon Vijay Abraham I]

commit 18aa0f4bca701cb078a6 ("ARM: dts: am57xx-idk: Select pull down
for mmc1_clk line in default mode") modified mmc1_pins_default
pinctrl group in am57xx-idk-common.dtsi in order to change the CLK
line to PIN_INPUT_PULLDOWN. However instead of modifying the pinctrl
group, use the new pinctrl group "mmc1_pins_default_no_clk_pu" in
dra72x-mmc-iodelay/dra74x-mmc-iodelay added specifically to be used
for CLK line without external pull up.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/am571x-idk.dts | 2 +-
 arch/arm/boot/dts/am572x-idk.dts | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/am571x-idk.dts b/arch/arm/boot/dts/am571x-idk.dts
index a2555140babc..9d8b9dc31476 100644
--- a/arch/arm/boot/dts/am571x-idk.dts
+++ b/arch/arm/boot/dts/am571x-idk.dts
@@ -102,7 +102,7 @@
 
  {
pinctrl-names = "default", "hs", "sdr12", "sdr25", "sdr50", "ddr50", 
"sdr104";
-   pinctrl-0 = <_pins_default>;
+   pinctrl-0 = <_pins_default_no_clk_pu>;
pinctrl-1 = <_pins_hs>;
pinctrl-2 = <_pins_sdr12>;
pinctrl-3 = <_pins_sdr25>;
diff --git a/arch/arm/boot/dts/am572x-idk.dts b/arch/arm/boot/dts/am572x-idk.dts
index 3a02ed720957..338dd4c5c825 100644
--- a/arch/arm/boot/dts/am572x-idk.dts
+++ b/arch/arm/boot/dts/am572x-idk.dts
@@ -20,7 +20,7 @@
 
  {
pinctrl-names = "default", "hs", "sdr12", "sdr25", "sdr50", "ddr50", 
"sdr104";
-   pinctrl-0 = <_pins_default>;
+   pinctrl-0 = <_pins_default_no_clk_pu>;
pinctrl-1 = <_pins_hs>;
pinctrl-2 = <_pins_sdr12>;
pinctrl-3 = <_pins_sdr25>;
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 08/15] ARM: dts: am574x-idk: Add pinmux configuration for MMC

[Kishon Vijay Abraham I]

From: Sekhar Nori 

Include dra76x-mmc-iodelay.dtsi which has pinmux and IODelay
configuration values for the various MMC modes for am574x SoC
and use it in the pinctrl properties of MMC devicetree
nodes present in am574x-idk.dts.

Signed-off-by: Sekhar Nori 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/am574x-idk.dts | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/arch/arm/boot/dts/am574x-idk.dts b/arch/arm/boot/dts/am574x-idk.dts
index 41e12a382d2f..500235e6d1c6 100644
--- a/arch/arm/boot/dts/am574x-idk.dts
+++ b/arch/arm/boot/dts/am574x-idk.dts
@@ -7,6 +7,7 @@
 /dts-v1/;
 
 #include "dra76x.dtsi"
+#include "dra76x-mmc-iodelay.dtsi"
 #include "am572x-idk-common.dtsi"
 
 / {
@@ -20,3 +21,21 @@
spi-max-frequency = <9600>;
};
 };
+
+ {
+   pinctrl-names = "default", "hs", "sdr12", "sdr25", "sdr50", "ddr50", 
"sdr104";
+   pinctrl-0 = <_pins_default_no_clk_pu>;
+   pinctrl-1 = <_pins_hs>;
+   pinctrl-2 = <_pins_default>;
+   pinctrl-3 = <_pins_hs>;
+   pinctrl-4 = <_pins_sdr50>;
+   pinctrl-5 = <_pins_ddr50 _iodelay_ddr_conf>;
+   pinctrl-6 = <_pins_ddr50 _iodelay_sdr104_conf>;
+};
+
+ {
+   pinctrl-names = "default", "hs", "ddr_1_8v";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_default>;
+   pinctrl-2 = <_pins_default>;
+};
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 14/15] ARM: dts: dra7: Add high speed modes capability to MMC1/MMC2 dt node

[Kishon Vijay Abraham I]

While the supported UHS mode can be obtained from CAPA2
register, SD Host Controller Standard Specification
doesn't define bits for MMC's HS200 and DDR mode capability.
Add properties to indicate MMC HS200 and DDR speed mode capability in
dt node.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7.dtsi | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index ae2f8dd46328..90f378b28915 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1086,6 +1086,7 @@
status = "disabled";
pbias-supply = <_mmc_reg>;
max-frequency = <19200>;
+   mmc-ddr-1_8v;
};
 
hdqw1w: 1w@480b2000 {
@@ -1104,6 +1105,8 @@
max-frequency = <19200>;
/* SDR104/DDR50/SDR50 bits in CAPA2 is not supported */
sdhci-caps-mask = <0x7 0x0>;
+   mmc-hs200-1_8v;
+   mmc-ddr-1_8v;
};
 
mmc3: mmc@480ad000 {
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 10/15] ARM: dts: dra7-evm: Model EVM_3V6 regulator

[Kishon Vijay Abraham I]

On TI's DRA74x EVM, EVM_3V6 is connected is connected to the VBAT line
of the wilink card. Model it here so that it can be used while adding
wilink8 WLAN support.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7-evm.dts | 42 ++
 1 file changed, 42 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index f1425b0f3a54..181289a28ca1 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -20,6 +20,16 @@
reg = <0x0 0x8000 0x0 0x6000>; /* 1536 MB */
};
 
+   evm_12v0: fixedregulator-evm_12v0 {
+   /* main supply */
+   compatible = "regulator-fixed";
+   regulator-name = "evm_12v0";
+   regulator-min-microvolt = <1200>;
+   regulator-max-microvolt = <1200>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
evm_1v8_sw: fixedregulator-evm_1v8 {
compatible = "regulator-fixed";
regulator-name = "evm_1v8";
@@ -54,6 +64,38 @@
regulator-max-microvolt = <180>;
};
 
+   evm_3v3: fixedregulator-evm3v3 {
+   /* Output of Cntlr A of TPS43351-Q1 on dra7-evm */
+   compatible = "regulator-fixed";
+   regulator-name = "evm_3v3";
+   regulator-min-microvolt = <330>;
+   regulator-max-microvolt = <330>;
+   vin-supply = <_12v0>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   evm_5v0: fixedregulator-evm_5v0 {
+   /* Output of Cntlr B of TPS43351-Q1 on dra7-evm */
+   compatible = "regulator-fixed";
+   regulator-name = "evm_5v0";
+   regulator-min-microvolt = <500>;
+   regulator-max-microvolt = <500>;
+   vin-supply = <_12v0>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
+   evm_3v6: fixedregulator-evm_3v6 {
+   compatible = "regulator-fixed";
+   regulator-name = "evm_3v6";
+   regulator-min-microvolt = <360>;
+   regulator-max-microvolt = <360>;
+   vin-supply = <_5v0>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
extcon_usb2: extcon_usb2 {
compatible = "linux,extcon-usb-gpio";
id-gpio = <_gpio_21 2 GPIO_ACTIVE_HIGH>;
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 07/15] ARM: dts: dra71-evm: Use pinctrl group from dra72x-mmc-iodelay.dtsi to select pulldown

[Kishon Vijay Abraham I]

commit 0e43884cca77218d2eccc331396e8 ("ARM: dts: dra71-evm: Select pull
down for mmc1_clk line in default mode") modified mmc1_pins_default
pinctrl group in dra71-evm.dts to change the CLK line to
PIN_INPUT_PULLDOWN. However instead of changing the pinctrl group,
use the new pinctrl group "mmc1_pins_default_no_clk_pu" in
dra72x-mmc-iodelay added specifically to be used for CLK line
without external pull up.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra71-evm.dts | 15 +--
 1 file changed, 1 insertion(+), 14 deletions(-)

diff --git a/arch/arm/boot/dts/dra71-evm.dts b/arch/arm/boot/dts/dra71-evm.dts
index 64c57d87ca2f..8065678b8016 100644
--- a/arch/arm/boot/dts/dra71-evm.dts
+++ b/arch/arm/boot/dts/dra71-evm.dts
@@ -50,19 +50,6 @@
};
 };
 
-_pmx_core {
-   mmc1_pins_default: mmc1_pins_default {
-   pinctrl-single,pins = <
-   DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLDOWN | 
MUX_MODE0) /* mmc1_clk.clk */
-   DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_cmd.cmd */
-   DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat0.dat0 */
-   DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat1.dat1 */
-   DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat2.dat2 */
-   DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat3.dat3 */
-   >;
-   };
-};
-
  {
status = "okay";
clock-frequency = <40>;
@@ -187,7 +174,7 @@
 
  {
pinctrl-names = "default", "hs", "sdr12", "sdr25", "sdr50", "ddr50", 
"sdr104";
-   pinctrl-0 = <_pins_default>;
+   pinctrl-0 = <_pins_default_no_clk_pu>;
pinctrl-1 = <_pins_hs>;
pinctrl-2 = <_pins_sdr12>;
pinctrl-3 = <_pins_sdr25>;
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 13/15] ARM: dts: dra7: Use sdhci-omap programming model

[Kishon Vijay Abraham I]

Use sdhci-omap programming model based on the generic sdhci
library for programming the eMMC/SD/SDIO controller.

Signed-off-by: Kishon Vijay Abraham I 
---
 .../boot/dts/am57xx-beagle-x15-common.dtsi|  4 +--
 arch/arm/boot/dts/am57xx-beagle-x15.dts   |  1 +
 arch/arm/boot/dts/am57xx-idk-common.dtsi  |  3 ++-
 arch/arm/boot/dts/dra7-evm.dts|  1 +
 arch/arm/boot/dts/dra7.dtsi   | 27 +++
 arch/arm/boot/dts/dra72-evm-common.dtsi   |  2 +-
 arch/arm/boot/dts/dra76-evm.dts   |  3 ++-
 7 files changed, 19 insertions(+), 22 deletions(-)

diff --git a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi 
b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
index 6204a266212a..ad953113cefb 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-beagle-x15-common.dtsi
@@ -444,8 +444,8 @@
vmmc-supply = <_3v3>;
vqmmc-supply = <_3v3>;
bus-width = <8>;
-   ti,non-removable;
-   cap-mmc-dual-data-rate;
+   non-removable;
+   no-1-8-v;
 };
 
  {
diff --git a/arch/arm/boot/dts/am57xx-beagle-x15.dts 
b/arch/arm/boot/dts/am57xx-beagle-x15.dts
index d6689106d2a8..c393de8a2391 100644
--- a/arch/arm/boot/dts/am57xx-beagle-x15.dts
+++ b/arch/arm/boot/dts/am57xx-beagle-x15.dts
@@ -25,6 +25,7 @@
pinctrl-1 = <_pins_hs>;
 
vmmc-supply = <_reg>;
+   no-1-8-v;
 };
 
  {
diff --git a/arch/arm/boot/dts/am57xx-idk-common.dtsi 
b/arch/arm/boot/dts/am57xx-idk-common.dtsi
index 43cdf523a8a0..605e7ec1b218 100644
--- a/arch/arm/boot/dts/am57xx-idk-common.dtsi
+++ b/arch/arm/boot/dts/am57xx-idk-common.dtsi
@@ -423,8 +423,9 @@
vmmc-supply = <_3d>;
vqmmc-supply = <_3d>;
bus-width = <8>;
-   ti,non-removable;
+   non-removable;
max-frequency = <9600>;
+   no-1-8-v;
 };
 
  {
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 704947cbef48..0894593860d6 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -377,6 +377,7 @@
vmmc-supply = <_1v8_sw>;
vqmmc-supply = <_1v8_sw>;
bus-width = <8>;
+   non-removable;
pinctrl-names = "default", "hs", "ddr_1_8v-rev11", "ddr_1_8v", 
"hs200_1_8v-rev11", "hs200_1_8v";
pinctrl-0 = <_pins_default>;
pinctrl-1 = <_pins_hs>;
diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
index f4ddd86f2c77..ae2f8dd46328 100644
--- a/arch/arm/boot/dts/dra7.dtsi
+++ b/arch/arm/boot/dts/dra7.dtsi
@@ -1079,14 +1079,10 @@
};
 
mmc1: mmc@4809c000 {
-   compatible = "ti,omap4-hsmmc";
+   compatible = "ti,dra7-sdhci";
reg = <0x4809c000 0x400>;
interrupts = ;
ti,hwmods = "mmc1";
-   ti,dual-volt;
-   ti,needs-special-reset;
-   dmas = <_xbar 61>, <_xbar 62>;
-   dma-names = "tx", "rx";
status = "disabled";
pbias-supply = <_mmc_reg>;
max-frequency = <19200>;
@@ -1100,40 +1096,37 @@
};
 
mmc2: mmc@480b4000 {
-   compatible = "ti,omap4-hsmmc";
+   compatible = "ti,dra7-sdhci";
reg = <0x480b4000 0x400>;
interrupts = ;
ti,hwmods = "mmc2";
-   ti,needs-special-reset;
-   dmas = <_xbar 47>, <_xbar 48>;
-   dma-names = "tx", "rx";
status = "disabled";
max-frequency = <19200>;
+   /* SDR104/DDR50/SDR50 bits in CAPA2 is not supported */
+   sdhci-caps-mask = <0x7 0x0>;
};
 
mmc3: mmc@480ad000 {
-   compatible = "ti,omap4-hsmmc";
+   compatible = "ti,dra7-sdhci";
reg = <0x480ad000 0x400>;
interrupts = ;
ti,hwmods = "mmc3";
-   ti,needs-special-reset;
-   dmas = <_xbar 77>, <_xbar 78>;
-   dma-names = "tx", "rx";
status = "disabled";
/* Errata i887 limits max-frequency of MMC3 to 64 MHz */
max-frequency = <6400>;
+   /* SDMA is not supported */
+   sdhci-caps-mask = <0x0 0x40>;
};
 
mmc4: mmc@480d1000 {
-   compatible = "ti,omap4-hsmmc";
+   compatible = "ti,dra7-sdhci";
reg = <0x480d1000 0x400>;
interrupts = ;
ti,hwmods = "mmc4";
- 

[PATCH v3 15/15] Documentation: ARM: Add new MMC requirements for DRA7/K2G

[Kishon Vijay Abraham I]

>From 4.18 kernel, all the MMC controller instances in DRA7
are programmed using sdhci based driver (sdhci-omap.c). Document
this new requirement here. Both omap2plus_defconfig and
multi_v7_defconfig has CONFIG_MMC_SDHCI_OMAP enabled.

Signed-off-by: Kishon Vijay Abraham I 
---
 Documentation/arm/OMAP/README | 4 
 1 file changed, 4 insertions(+)

diff --git a/Documentation/arm/OMAP/README b/Documentation/arm/OMAP/README
index 75645c45d14a..5bf5ac3b3ed4 100644
--- a/Documentation/arm/OMAP/README
+++ b/Documentation/arm/OMAP/README
@@ -5,3 +5,7 @@ KERNEL  NEW DEPENDENCIES
 v4.3+  Update is needed for custom .config files to make sure
CONFIG_REGULATOR_PBIAS is enabled for MMC1 to work
properly.
+
+v4.18+ Update is needed for custom .config files to make sure
+   CONFIG_MMC_SDHCI_OMAP is enabled for all MMC instances
+   to work in DRA7 based boards.
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 05/15] ARM: dts: dra76x-mmc-iodelay: Add a new pinctrl group for clk line without pullup

[Kishon Vijay Abraham I]

During a short period when the bus voltage is switched from 3.3v to 1.8v,
(to enumerate UHS mode), the mmc module is disabled and the mmc IO lines
are kept in a state according to the programmed pad mux pull type.

According to 4.2.4.2 Timing to Switch Signal Voltage in "SD Specifications
Part 1 Physical Layer Specification Version 5.00 February 22, 2016", the
host should hold CLK line low for at least 5ms.

In order to keep the card line low during voltage switch, the pad mux of
mmc1_clk line should be configured to pull down.

Add a new pinctrl group for clock line without pullup to be used in boards
where mmc1_clk line is not connected to an external pullup.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra76x-mmc-iodelay.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/dra76x-mmc-iodelay.dtsi 
b/arch/arm/boot/dts/dra76x-mmc-iodelay.dtsi
index baba7b00eca7..b6327220a88e 100644
--- a/arch/arm/boot/dts/dra76x-mmc-iodelay.dtsi
+++ b/arch/arm/boot/dts/dra76x-mmc-iodelay.dtsi
@@ -38,6 +38,17 @@
>;
};
 
+   mmc1_pins_default_no_clk_pu: mmc1_pins_default_no_clk_pu {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLDOWN | 
MUX_MODE0) /* mmc1_clk.clk */
+   DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_cmd.cmd */
+   DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat0.dat0 */
+   DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat1.dat1 */
+   DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat2.dat2 */
+   DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat3.dat3 */
+   >;
+   };
+
mmc1_pins_hs: mmc1_pins_hs {
pinctrl-single,pins = <
DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | 
MUX_VIRTUAL_MODE11 | MUX_MODE0) /* mmc1_clk.clk */
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 09/15] ARM: dts: dra72-evm-common: Add wilink8 wlan support

[Kishon Vijay Abraham I]

From: Hari Nagalla 

Wilink8 module is a combo wireless connectivity card based
on Texas Instrument's wl18xx solution.

Add support for the wlan capabilities of this module by muxing
the relevant mmc lines, and setting the required device-tree
data.

Signed-off-by: Eyal Reizer 
Signed-off-by: Hari Nagalla 
[nsek...@ti.com: drop WLAN_EN pinmux. It should be done by bootloader.
 Also, some commit message adjustments]
Signed-off-by: Sekhar Nori 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra72-evm-common.dtsi   | 42 +++
 arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi | 11 ++
 2 files changed, 53 insertions(+)

diff --git a/arch/arm/boot/dts/dra72-evm-common.dtsi 
b/arch/arm/boot/dts/dra72-evm-common.dtsi
index 8e3b185d864b..1e4d36e33a1b 100644
--- a/arch/arm/boot/dts/dra72-evm-common.dtsi
+++ b/arch/arm/boot/dts/dra72-evm-common.dtsi
@@ -44,6 +44,16 @@
regulator-boot-on;
};
 
+   evm_3v6: fixedregulator-evm_3v6 {
+   compatible = "regulator-fixed";
+   regulator-name = "evm_3v6";
+   regulator-min-microvolt = <360>;
+   regulator-max-microvolt = <360>;
+   vin-supply = <_5v0>;
+   regulator-always-on;
+   regulator-boot-on;
+   };
+
vsys_3v3: fixedregulator-vsys3v3 {
/* Output 2 of TPS43351QDAPRQ1 on dra72-evm */
/* Output 2 of LM5140QRWGTQ1 on dra71-evm */
@@ -171,6 +181,15 @@
clocks = <_clkin2_ck>;
};
};
+
+   vmmcwl_fixed: fixedregulator-mmcwl {
+   compatible = "regulator-fixed";
+   regulator-name = "vmmcwl_fixed";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   gpio = < 8 GPIO_ACTIVE_HIGH>;
+   enable-active-high;
+   };
 };
 
 _pmx_core {
@@ -398,6 +417,29 @@
max-frequency = <19200>;
 };
 
+ {
+   status = "okay";
+   vmmc-supply = <_3v6>;
+   vqmmc-supply = <_fixed>;
+   bus-width = <4>;
+   cap-power-off-card;
+   keep-power-in-suspend;
+   non-removable;
+   pinctrl-names = "default", "hs", "sdr12", "sdr25";
+   pinctrl-0 = <_pins_default>;
+   pinctrl-1 = <_pins_default>;
+   pinctrl-2 = <_pins_default>;
+   pinctrl-3 = <_pins_default>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   wlcore: wlcore@2 {
+   compatible = "ti,wl1835";
+   reg = <2>;
+   interrupt-parent = <>;
+   interrupts = <7 IRQ_TYPE_EDGE_RISING>;
+   };
+};
+
  {
status = "okay";
 };
diff --git a/arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi 
b/arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi
index c9351eaf97f0..4cf5482fbc33 100644
--- a/arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi
+++ b/arch/arm/boot/dts/dra72x-mmc-iodelay.dtsi
@@ -213,6 +213,17 @@
DRA7XX_CORE_IOPAD(0x3498, PIN_INPUT_PULLUP | 
MODE_SELECT | MUX_MODE1) /* gpmc_a22.mmc2_dat7 */
>;
};
+
+   mmc4_pins_default: mmc4_pins_default {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x37e8, PIN_INPUT_PULLUP | MUX_MODE3) 
/* uart1_ctsn.mmc4_clk */
+   DRA7XX_CORE_IOPAD(0x37ec, PIN_INPUT_PULLUP | MUX_MODE3) 
/* uart1_rtsn.mmc4_cmd */
+   DRA7XX_CORE_IOPAD(0x37f0, PIN_INPUT_PULLUP | MUX_MODE3) 
/* uart2_rxd.mmc4_dat0 */
+   DRA7XX_CORE_IOPAD(0x37f4, PIN_INPUT_PULLUP | MUX_MODE3) 
/* uart2_txd.mmc4_dat1 */
+   DRA7XX_CORE_IOPAD(0x37f8, PIN_INPUT_PULLUP | MUX_MODE3) 
/* uart2_ctsn.mmc4_dat2 */
+   DRA7XX_CORE_IOPAD(0x37fc, PIN_INPUT_PULLUP | MUX_MODE3) 
/* uart2_rtsn.mmc4_dat3 */
+   >;
+   };
 };
 
 _iodelay_core {
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 11/15] ARM: dts: dra7-evm: Add wilink8 wlan support

[Kishon Vijay Abraham I]

From: Hari Nagalla 

The wilink module is a combo wireless connectivity sdio
card based on Texas Instrument's wl18xx solution. It is a
4-wire, 1.8V, embedded sdio wlan device with an external
irq line and is power-controlled by a gpio-based fixed
regulator.

Add pinmux configuration and IODelay values for MMC4.
On dra7-evm, MMC4 is used for connecting to wilink module.

IODelay data credits to :  Vishal Mahaveer 
and Sekhar Nori 

Signed-off-by: Ido Yariv 
Signed-off-by: Eyal Reizer 
Signed-off-by: Hari Nagalla 
Signed-off-by: Sekhar Nori 
Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra7-evm-common.dtsi | 15 +++
 arch/arm/boot/dts/dra7-evm.dts | 25 +
 2 files changed, 40 insertions(+)

diff --git a/arch/arm/boot/dts/dra7-evm-common.dtsi 
b/arch/arm/boot/dts/dra7-evm-common.dtsi
index 05a7b1a01bc3..3590c40fc112 100644
--- a/arch/arm/boot/dts/dra7-evm-common.dtsi
+++ b/arch/arm/boot/dts/dra7-evm-common.dtsi
@@ -260,3 +260,18 @@
 _rc {
status = "okay";
 };
+
+ {
+   bus-width = <4>;
+   cap-power-off-card;
+   keep-power-in-suspend;
+   non-removable;
+   #address-cells = <1>;
+   #size-cells = <0>;
+   wlcore: wlcore@2 {
+   compatible = "ti,wl1835";
+   reg = <2>;
+   interrupt-parent = <>;
+   interrupts = <7 IRQ_TYPE_EDGE_RISING>;
+   };
+};
diff --git a/arch/arm/boot/dts/dra7-evm.dts b/arch/arm/boot/dts/dra7-evm.dts
index 181289a28ca1..704947cbef48 100644
--- a/arch/arm/boot/dts/dra7-evm.dts
+++ b/arch/arm/boot/dts/dra7-evm.dts
@@ -96,6 +96,16 @@
regulator-boot-on;
};
 
+   vmmcwl_fixed: fixedregulator-mmcwl {
+   compatible = "regulator-fixed";
+   regulator-name = "vmmcwl_fixed";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <180>;
+   gpio = < 8 0>;
+   startup-delay-us = <7>;
+   enable-active-high;
+   };
+
extcon_usb2: extcon_usb2 {
compatible = "linux,extcon-usb-gpio";
id-gpio = <_gpio_21 2 GPIO_ACTIVE_HIGH>;
@@ -376,6 +386,21 @@
pinctrl-5 = <_pins_hs200 _iodelay_hs200_rev20_conf>;
 };
 
+ {
+   status = "okay";
+   vmmc-supply = <_3v6>;
+   vqmmc-supply = <_fixed>;
+   pinctrl-names = "default-rev11", "default", "hs-rev11", "hs", 
"sdr12-rev11", "sdr12", "sdr25-rev11", "sdr25";
+   pinctrl-0 = <_pins_default _iodelay_ds_rev11_conf>;
+   pinctrl-1 = <_pins_default _iodelay_ds_rev20_conf>;
+   pinctrl-2 = <_pins_hs _iodelay_sdr12_hs_sdr25_rev11_conf>;
+   pinctrl-3 = <_pins_hs _iodelay_sdr12_hs_sdr25_rev20_conf>;
+   pinctrl-4 = <_pins_sdr12 _iodelay_sdr12_hs_sdr25_rev11_conf>;
+   pinctrl-5 = <_pins_sdr12 _iodelay_sdr12_hs_sdr25_rev20_conf>;
+   pinctrl-6 = <_pins_sdr25 _iodelay_sdr12_hs_sdr25_rev11_conf>;
+   pinctrl-7 = <_pins_sdr25 _iodelay_sdr12_hs_sdr25_rev20_conf>;
+};
+
  {
vdd-supply = <_reg>;
 };
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v3 04/15] ARM: dts: dra74x-mmc-iodelay: Add a new pinctrl group for clk line without pullup

[Kishon Vijay Abraham I]

During a short period when the bus voltage is switched from 3.3v to 1.8v,
(to enumerate UHS mode), the mmc module is disabled and the mmc IO lines
are kept in a state according to the programmed pad mux pull type.

According to 4.2.4.2 Timing to Switch Signal Voltage in "SD Specifications
Part 1 Physical Layer Specification Version 5.00 February 22, 2016", the
host should hold CLK line low for at least 5ms.

In order to keep the card line low during voltage switch, the pad mux of
mmc1_clk line should be configured to pull down.

Add a new pinctrl group for clock line without pullup to be used in boards
where mmc1_clk line is not connected to an external pullup.

Signed-off-by: Kishon Vijay Abraham I 
---
 arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi 
b/arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi
index 28ebb4eb884a..30af5a03a852 100644
--- a/arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi
+++ b/arch/arm/boot/dts/dra74x-mmc-iodelay.dtsi
@@ -49,6 +49,17 @@
>;
};
 
+   mmc1_pins_default_no_clk_pu: mmc1_pins_default_no_clk_pu {
+   pinctrl-single,pins = <
+   DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLDOWN | 
MUX_MODE0) /* mmc1_clk.clk */
+   DRA7XX_CORE_IOPAD(0x3758, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_cmd.cmd */
+   DRA7XX_CORE_IOPAD(0x375c, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat0.dat0 */
+   DRA7XX_CORE_IOPAD(0x3760, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat1.dat1 */
+   DRA7XX_CORE_IOPAD(0x3764, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat2.dat2 */
+   DRA7XX_CORE_IOPAD(0x3768, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_dat3.dat3 */
+   >;
+   };
+
mmc1_pins_sdr12: mmc1_pins_sdr12 {
pinctrl-single,pins = <
DRA7XX_CORE_IOPAD(0x3754, PIN_INPUT_PULLUP | MUX_MODE0) 
/* mmc1_clk.clk */
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/1] misc: IBM Virtual Management Channel Driver

[kbuild test robot]

Hi Bryant,

I love your patch! Perhaps something to improve:

[auto build test WARNING on char-misc/char-misc-testing]
[also build test WARNING on v4.17-rc2 next-20180424]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Bryant-G-Ly/misc-IBM-Virtual-Management-Channel-Driver/20180424-060306
config: powerpc64-allyesconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All warnings (new ones prefixed by >>):

   drivers//misc/ibmvmc.c: In function 'ibmvmc_probe':
>> drivers//misc/ibmvmc.c:2133:5: warning: 'rc' may be used uninitialized in 
>> this function [-Wmaybe-uninitialized]
 if (rc == H_RESOURCE)
^
   drivers//misc/ibmvmc.c:2111:6: note: 'rc' was declared here
 int rc;
 ^~

vim +/rc +2133 drivers//misc/ibmvmc.c

  2097  
  2098  /**
  2099   * ibmvmc_init_crq_queue - Init CRQ Queue
  2100   *
  2101   * @adapter:crq_server_adapter struct
  2102   *
  2103   * Return:
  2104   *  0 - Success
  2105   *  Non-zero - Failure
  2106   */
  2107  static int ibmvmc_init_crq_queue(struct crq_server_adapter *adapter)
  2108  {
  2109  struct vio_dev *vdev = to_vio_dev(adapter->dev);
  2110  struct crq_queue *queue = >queue;
  2111  int rc;
  2112  int retrc;
  2113  
  2114  queue->msgs = (struct ibmvmc_crq_msg 
*)get_zeroed_page(GFP_KERNEL);
  2115  
  2116  if (!queue->msgs)
  2117  goto malloc_failed;
  2118  
  2119  queue->size = PAGE_SIZE / sizeof(*queue->msgs);
  2120  
  2121  queue->msg_token = dma_map_single(adapter->dev, queue->msgs,
  2122queue->size * 
sizeof(*queue->msgs),
  2123DMA_BIDIRECTIONAL);
  2124  
  2125  if (dma_mapping_error(adapter->dev, queue->msg_token))
  2126  goto map_failed;
  2127  
  2128  retrc = plpar_hcall_norets(H_REG_CRQ,
  2129 vdev->unit_address,
  2130 queue->msg_token, PAGE_SIZE);
  2131  retrc = rc;
  2132  
> 2133  if (rc == H_RESOURCE)
  2134  rc = ibmvmc_reset_crq_queue(adapter);
  2135  
  2136  if (rc == 2) {
  2137  dev_warn(adapter->dev, "Partner adapter not ready\n");
  2138  retrc = 0;
  2139  } else if (rc != 0) {
  2140  dev_err(adapter->dev, "Error %d opening adapter\n", rc);
  2141  goto reg_crq_failed;
  2142  }
  2143  
  2144  queue->cur = 0;
  2145  spin_lock_init(>lock);
  2146  
  2147  tasklet_init(>work_task, ibmvmc_task, (unsigned 
long)adapter);
  2148  
  2149  if (request_irq(vdev->irq,
  2150  ibmvmc_handle_event,
  2151  0, "ibmvmc", (void *)adapter) != 0) {
  2152  dev_err(adapter->dev, "couldn't register irq 0x%x\n",
  2153  vdev->irq);
  2154  goto req_irq_failed;
  2155  }
  2156  
  2157  rc = vio_enable_interrupts(vdev);
  2158  if (rc != 0) {
  2159  dev_err(adapter->dev, "Error %d enabling 
interrupts!!!\n", rc);
  2160  goto req_irq_failed;
  2161  }
  2162  
  2163  return retrc;
  2164  
  2165  req_irq_failed:
  2166  /* Cannot have any work since we either never got our IRQ 
registered,
  2167   * or never got interrupts enabled
  2168   */
  2169  tasklet_kill(>work_task);
  2170  h_free_crq(vdev->unit_address);
  2171  reg_crq_failed:
  2172  dma_unmap_single(adapter->dev,
  2173   queue->msg_token,
  2174   queue->size * sizeof(*queue->msgs), 
DMA_BIDIRECTIONAL);
  2175  map_failed:
  2176  free_page((unsigned long)queue->msgs);
  2177  malloc_failed:
  2178  return -ENOMEM;
  2179  }
  2180  

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


.config.gz
Description: application/gzip

[PATCH] PM: docs: sleep-states: Fix a typo ("includig")

[Jonathan Neuschäfer]

Signed-off-by: Jonathan Neuschäfer 
---
 Documentation/admin-guide/pm/sleep-states.rst | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/pm/sleep-states.rst 
b/Documentation/admin-guide/pm/sleep-states.rst
index 1e5c0f00cb2f..dbf5acd49f35 100644
--- a/Documentation/admin-guide/pm/sleep-states.rst
+++ b/Documentation/admin-guide/pm/sleep-states.rst
@@ -15,7 +15,7 @@ Sleep States That Can Be Supported
 ==
 
 Depending on its configuration and the capabilities of the platform it runs on,
-the Linux kernel can support up to four system sleep states, includig
+the Linux kernel can support up to four system sleep states, including
 hibernation and up to three variants of system suspend.  The sleep states that
 can be supported by the kernel are listed below.
 
-- 
2.17.0

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 1/2] perf: uncore: Adding documentation for ThunderX2 pmu uncore driver

[Ganapatrao Kulkarni]

Documentation for the UNCORE PMUs on Cavium's ThunderX2 SoC.
The SoC has PMU support in its L3 cache controller (L3C) and in the
DDR4 Memory Controller (DMC).

Signed-off-by: Ganapatrao Kulkarni 
---
 Documentation/perf/thunderx2-pmu.txt | 66 
 1 file changed, 66 insertions(+)
 create mode 100644 Documentation/perf/thunderx2-pmu.txt

diff --git a/Documentation/perf/thunderx2-pmu.txt 
b/Documentation/perf/thunderx2-pmu.txt
new file mode 100644
index 000..9e9f535
--- /dev/null
+++ b/Documentation/perf/thunderx2-pmu.txt
@@ -0,0 +1,66 @@
+
+Cavium ThunderX2 SoC Performance Monitoring Unit (PMU UNCORE)
+==
+
+ThunderX2 SoC PMU consists of independent system wide per Socket PMUs such
+as Level 3 Cache(L3C) and DDR4 Memory Controller(DMC).
+
+It has 8 independent DMC PMUs to capture performance events corresponding
+to 8 channels of DDR4 Memory Controller. There are 16 independent L3C PMUs
+to capture events corresponding to 16 tiles of L3 cache. Each PMU supports
+up to 4 counters.
+
+Counters are independent programmable and can be started and stopped
+individually. Each counter can be set to sample specific perf events.
+Counters are 32 bit and does not support overflow interrupt, they are
+sampled at every 2 seconds. The Counters register access are multiplexed
+across channels of DMC and L3C. The muxing(select channel) is done through
+write to a Secure register using smcc calls.
+
+PMU UNCORE (perf) driver:
+
+The thunderx2-pmu driver registers several perf PMUs for DMC and L3C devices.
+Each of the PMU provides description of its available events
+and configuration options in sysfs.
+   see /sys/devices/uncore_
+
+S is socket id and X represents channel number.
+Each PMU can be used to sample up to 4 events simultaneously.
+
+The "format" directory describes format of the config (event ID).
+The "events" directory provides configuration templates for all
+supported event types that can be used with perf tool.
+
+For example, "uncore_dmc_0_0/cnt_cycles/" is an
+equivalent of "uncore_dmc_0_0/config=0x1/".
+
+Each perf driver also provides a "cpumask" sysfs attribute, which contains a
+single CPU ID of the processor which is likely to be used to handle all the
+PMU events. It will be the first online CPU from the NUMA node of PMU device.
+
+Example for perf tool use:
+
+perf stat -a -e \
+uncore_dmc_0_0/cnt_cycles/,\
+uncore_dmc_0_1/cnt_cycles/,\
+uncore_dmc_0_2/cnt_cycles/,\
+uncore_dmc_0_3/cnt_cycles/,\
+uncore_dmc_0_4/cnt_cycles/,\
+uncore_dmc_0_5/cnt_cycles/,\
+uncore_dmc_0_6/cnt_cycles/,\
+uncore_dmc_0_7/cnt_cycles/ sleep 1
+
+perf stat -a -e \
+uncore_dmc_0_0/cancelled_read_txns/,\
+uncore_dmc_0_0/cnt_cycles/,\
+uncore_dmc_0_0/consumed_read_txns/,\
+uncore_dmc_0_0/data_transfers/ sleep 1
+
+perf stat -a -e \
+uncore_l3c_0_0/l3_retry/,\
+uncore_l3c_0_0/read_hit/,\
+uncore_l3c_0_0/read_request/,\
+uncore_l3c_0_0/inv_request/ sleep 1
+
+The driver does not support sampling, therefore "perf record" will
+not work. Per-task (without "-a") perf sessions are not supported.
-- 
2.9.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v4 2/2] ThunderX2: Add Cavium ThunderX2 SoC UNCORE PMU driver

[Ganapatrao Kulkarni]

This patch adds a perf driver for the PMU UNCORE devices DDR4 Memory
Controller(DMC) and Level 3 Cache(L3C).

ThunderX2 has 8 independent DMC PMUs to capture performance events
corresponding to 8 channels of DDR4 Memory Controller and 16 independent
L3C PMUs to capture events corresponding to 16 tiles of L3 cache.
Each PMU supports up to 4 counters. All counters lack overflow interrupt
and are sampled periodically.

Signed-off-by: Ganapatrao Kulkarni 
---
 drivers/perf/Kconfig |   8 +
 drivers/perf/Makefile|   1 +
 drivers/perf/thunderx2_pmu.c | 958 +++
 3 files changed, 967 insertions(+)
 create mode 100644 drivers/perf/thunderx2_pmu.c

diff --git a/drivers/perf/Kconfig b/drivers/perf/Kconfig
index 28bb5a0..eafd0fc 100644
--- a/drivers/perf/Kconfig
+++ b/drivers/perf/Kconfig
@@ -85,6 +85,14 @@ config QCOM_L3_PMU
   Adds the L3 cache PMU into the perf events subsystem for
   monitoring L3 cache events.
 
+config THUNDERX2_PMU
+bool "Cavium ThunderX2 SoC PMU UNCORE"
+depends on ARCH_THUNDER2 && PERF_EVENTS && ACPI
+   help
+ Provides support for ThunderX2 UNCORE events.
+ The SoC has PMU support in its L3 cache controller (L3C) and
+ in the DDR4 Memory Controller (DMC).
+
 config XGENE_PMU
 depends on ARCH_XGENE
 bool "APM X-Gene SoC PMU"
diff --git a/drivers/perf/Makefile b/drivers/perf/Makefile
index b3902bd..909f27f 100644
--- a/drivers/perf/Makefile
+++ b/drivers/perf/Makefile
@@ -7,5 +7,6 @@ obj-$(CONFIG_ARM_PMU_ACPI) += arm_pmu_acpi.o
 obj-$(CONFIG_HISI_PMU) += hisilicon/
 obj-$(CONFIG_QCOM_L2_PMU)  += qcom_l2_pmu.o
 obj-$(CONFIG_QCOM_L3_PMU) += qcom_l3_pmu.o
+obj-$(CONFIG_THUNDERX2_PMU) += thunderx2_pmu.o
 obj-$(CONFIG_XGENE_PMU) += xgene_pmu.o
 obj-$(CONFIG_ARM_SPE_PMU) += arm_spe_pmu.o
diff --git a/drivers/perf/thunderx2_pmu.c b/drivers/perf/thunderx2_pmu.c
new file mode 100644
index 000..92d19b5
--- /dev/null
+++ b/drivers/perf/thunderx2_pmu.c
@@ -0,0 +1,958 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * CAVIUM THUNDERX2 SoC PMU UNCORE
+ *
+ * Copyright (C) 2018 Cavium Inc.
+ * Author: Ganapatrao Kulkarni 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+/* L3c and DMC has 16 and 8 channels per socket respectively.
+ * Each Channel supports UNCORE PMU device and consists of
+ * 4 independent programmable counters. Counters are 32 bit
+ * and does not support overflow interrupt, they needs to be
+ * sampled before overflow(i.e, at every 2 seconds).
+ */
+
+#define UNCORE_MAX_COUNTERS4
+#define UNCORE_L3_MAX_TILES16
+#define UNCORE_DMC_MAX_CHANNELS8
+
+#define UNCORE_HRTIMER_INTERVAL(2 * NSEC_PER_SEC)
+#define GET_EVENTID(ev)((ev->hw.config) & 0x1ff)
+#define GET_COUNTERID(ev)  ((ev->hw.idx) & 0xf)
+#define GET_CHANNELID(pmu_uncore)  (pmu_uncore->channel)
+
+#define DMC_COUNTER_CTL0x234
+#define DMC_COUNTER_DATA   0x240
+#define L3C_COUNTER_CTL0xA8
+#define L3C_COUNTER_DATA   0xAC
+
+#define THUNDERX2_SMC_CALL_ID  0xC200FF00
+#define THUNDERX2_SMC_SET_CHANNEL  0xB010
+
+
+enum thunderx2_uncore_l3_events {
+   L3_EVENT_NONE,
+   L3_EVENT_NBU_CANCEL,
+   L3_EVENT_DIB_RETRY,
+   L3_EVENT_DOB_RETRY,
+   L3_EVENT_DIB_CREDIT_RETRY,
+   L3_EVENT_DOB_CREDIT_RETRY,
+   L3_EVENT_FORCE_RETRY,
+   L3_EVENT_IDX_CONFLICT_RETRY,
+   L3_EVENT_EVICT_CONFLICT_RETRY,
+   L3_EVENT_BANK_CONFLICT_RETRY,
+   L3_EVENT_FILL_ENTRY_RETRY,
+   L3_EVENT_EVICT_NOT_READY_RETRY,
+   L3_EVENT_L3_RETRY,
+   L3_EVENT_READ_REQ,
+   L3_EVENT_WRITE_BACK_REQ,
+   L3_EVENT_INVALIDATE_NWRITE_REQ,
+   L3_EVENT_INV_REQ,
+   L3_EVENT_SELF_REQ,
+   L3_EVENT_REQ,
+   L3_EVENT_EVICT_REQ,
+   L3_EVENT_INVALIDATE_NWRITE_HIT,
+   L3_EVENT_INVALIDATE_HIT,
+   L3_EVENT_SELF_HIT,
+   L3_EVENT_READ_HIT,
+   L3_EVENT_MAX,
+};
+
+enum thunderx2_uncore_dmc_events {
+   DMC_EVENT_NONE,
+   DMC_EVENT_COUNT_CYCLES,
+   DMC_EVENT_RES2,
+   DMC_EVENT_RES3,
+   DMC_EVENT_RES4,
+   DMC_EVENT_RES5,
+   DMC_EVENT_RES6,
+   DMC_EVENT_RES7,
+   DMC_EVENT_RES8,
+   

[PATCH v4 0/2] Add ThunderX2 SoC Performance Monitoring Unit driver

[Ganapatrao Kulkarni]

This patchset adds PMU driver for Cavium's ThunderX2 SoC UNCORE devices.
The SoC has PMU support in L3 cache controller (L3C) and in the
DDR4 Memory Controller (DMC).

v4:
 -Incroporated review comments from Mark Rutland[1]

[1] https://www.spinics.net/lists/arm-kernel/msg588563.html

v3:
 - fixed warning reported by kbuild robot

v2:
 - rebased to 4.12-rc1
 - Removed Arch VULCAN dependency.
 - update SMC call parameters as per latest firmware.

v1:
 -Initial patch

Ganapatrao Kulkarni (2):
  perf: uncore: Adding documentation for ThunderX2 pmu uncore driver
  ThunderX2: Add Cavium ThunderX2 SoC UNCORE PMU driver

 Documentation/perf/thunderx2-pmu.txt |  66 +++
 drivers/perf/Kconfig |   8 +
 drivers/perf/Makefile|   1 +
 drivers/perf/thunderx2_pmu.c | 958 +++
 4 files changed, 1033 insertions(+)
 create mode 100644 Documentation/perf/thunderx2-pmu.txt
 create mode 100644 drivers/perf/thunderx2_pmu.c

-- 
2.9.4

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1 1/1] misc: IBM Virtual Management Channel Driver

[Linus Walleij]

I don't know why I'm included in review of this driver, but why
not :) it is good to include people.

Thanks for your patch! It looks exciting and complicated,
I like that kind of stuff.

On Mon, Apr 23, 2018 at 4:46 PM, Bryant G. Ly
 wrote:

> This driver is a logical device which provides an
> interface between the hypervisor and a management
> partition.

Please indicate what this management partition is to
be used for, i.e. the intended use case.

> This driver is to be used for the POWER Virtual
> Management Channel Virtual Adapter on the PowerVM
> platform.

Is that virtualization on the PowerPC platform?

> It provides both request/response and
> async message support through the /dev/ibmvmc node.

Is that a character or block device?
I guess block, but it's nice to have some specifics
in the commit message.

> diff --git a/Documentation/misc-devices/ibmvmc.txt 
> b/Documentation/misc-devices/ibmvmc.txt

The document suffers a bit from internal lingo, so it's be great
if you improve it a bit with a style that will be welcoming for newcomers
who have no idea what you are talking about.

I will point out some items below.

> +Description
> +===
> +
> +The Virtual Management Channel (VMC) is a logical device which provides an
> +interface between the hypervisor and a management partition.

What kind of interface? A bitstream? Message passing interface?
Marshalling of structs? Some specifics would be great.

> This
> +management partition is intended to provide an alternative to HMC-based
> +system management.

Please expand the acronym HMC for the newcomer so we do not need
to look it up, or it looks like the document is only for people who already
know everything about virtualization specifics.

> In the management partition, a Novalink application
> +exists

Is Novalink some kind of product name? In that case, can it be
instead described with some neutral technology name and state
Novalink as an examplf of this type of technology?

> which enables a system administrator to configure the system’s
> +partitioning characteristics

Exemplify "partitioning characteristics", with a sentence in this
vein: "partitioning characteristics such as FOO, BAR and BAZ".

> via a command line interface (CLI) or
> +Representational State Transfer Application (REST).

I understand what CLI is but what is a representational state
transfer application? Is that a fancy name for a GUI application
doing the same thing as a CLI program would do?

> You can also manage the
> +server by using PowerVC

There was PowerVM now there is PowerVC. What are those things
really? PowerVM I guess is virtual machine on PowerPC? What is
PowerVC? Virtual client (guest) in the PowerVM?

This kind of lingo makes the document a hard read for me.

> or other OpenStack solution.

I heard about OpenStack. I have a vague idea about what it is,
do you mean "other virtualization concepts"?

> Support for
> +conventional HMC management of the system may still be provided on a
> +system; however, when an HMC is attached to the system, the VMC
> +interface is disabled by the hypervisor.

The VMC acronym is expanded below, instead expand it at first
instance. The same for HMC (hypervisor management channel I guess?
it is never really explained.)

> +NovaLink runs on a Linux logical partition on a POWER8 or newer processor-
> +based server that is virtualized by PowerVM.

So this information needs to be in the top of the document.

> System configuration,
> +maintenance, and control functions which traditionally require an HMC can
> +be implemented in the Novalink using a combination of HMC to hypervisor
> +interfaces and existing operating system methods. This tool provides

What tool? It is unclear what tool we are referring to here.
A command line tool? A technology? etc.

> a
> +subset of the functions implemented by the HMC and enables basic partition
> +configuration. The set of HMC to hypervisor messages

This makes me think that probably the "h" in HMC stands for "hypervisor"
so now I start to puzzle things together. But it's nicer if you just expand
the acronym the first time you use it.

> supported by the
> +Novalink component

I still haven't figured out what that is, in practice.

> are passed to the hypervisor over a VMC interface, which
> +is defined below.

Maybe some illustration of how HMC, Novalink and VMC work
together would be appropriate?

> +Virtual Management Channel (VMC)
> +A logical device, called the virtual management channel (VMC), is defined
> +for communicating between the Novalink application and the hypervisor.


So is "Novalink" some specific application, as in a proprietary
piece of software or something?

I'm still confused.

> +This device, similar to a VSCSI server device,

What is that acronym now, I get completely confused.

> is presented to a designated
> +management partition as a virtual device and is only presented when the
> +system is not HMC managed.
> +This 

Re: [PATCH v5 0/2] perf: riscv: Preliminary Perf Event Support on RISC-V

[Atish Patra]

On 4/24/18 8:19 PM, Alan Kao wrote:

Hi Atish, Palmer,

On Tue, Apr 24, 2018 at 06:15:49PM -0700, Atish Patra wrote:

On 4/24/18 5:29 PM, Palmer Dabbelt wrote:

On Tue, 24 Apr 2018 15:16:16 PDT (-0700), atish.pa...@wdc.com wrote:

On 4/24/18 12:44 PM, Palmer Dabbelt wrote:

On Tue, 24 Apr 2018 12:27:26 PDT (-0700), atish.pa...@wdc.com wrote:

On 4/24/18 11:07 AM, Atish Patra wrote:

On 4/19/18 4:28 PM, Alan Kao wrote:
However, I got an rcu-stall for the test "47: Event times".
# ./perf test -v 47

Got it working. The test tries to attach the event to CPU0 which doesn't
exist in HighFive Unleashed. Changing it to cpu1 works.

diff --git a/tools/perf/tests/event-times.c b/tools/perf/tests/event-times.c
index 1a2686f..eb11632f 100644
--- a/tools/perf/tests/event-times.c
+++ b/tools/perf/tests/event-times.c
@@ -113,9 +113,9 @@ static int attach__cpu_disabled(struct perf_evlist
*evlist)
   struct cpu_map *cpus;
   int err;

-   pr_debug("attaching to CPU 0 as enabled\n");
+   pr_debug("attaching to CPU 1 as disabled\n");

-   cpus = cpu_map__new("0");
+   cpus = cpu_map__new("1");
   if (cpus == NULL) {
   pr_debug("failed to call cpu_map__new\n");
   return -1;
@@ -142,9 +142,9 @@ static int attach__cpu_enabled(struct perf_evlist
*evlist)
   struct cpu_map *cpus;
   int err;

-   pr_debug("attaching to CPU 0 as enabled\n");
+   pr_debug("attaching to CPU 1 as enabled\n");

-   cpus = cpu_map__new("0");
+   cpus = cpu_map__new("1");
   if (cpus == NULL) {
   pr_debug("failed to call cpu_map__new\n");
   return -1;


Palmer,
Would it be better to officially document it somewhere that CPU0 doesn't
exist in the HighFive Unleashed board ?
I fear that there will be other standard tests/code path that may fail
because of inherent assumption of cpu0 presence.


I think the best way to fix this is to just have BBL (or whatever the
bootloader is) renumber the CPUs so they're contiguous and begin with 0.


Do you mean BBL will update the device tree that kernel eventually parse
and set the hart id?
Sounds good to me unless it acts as a big hack in future boot loaders.


Right now the machine-mode and supervisor-mode hart IDs are logically separate:
the bootloader just provides the hart ID as a register argument when starting
the kernel.


Yes.

   BBL already needs to enumerate the harts by looking through the

device tree for various other reasons (at least to mask off the harts that
Linux doesn't support), so it's not that much effort to just maintain a mapping

>from supervisor-mode hart IDs to machine-mode hart IDs.




But Linux also parses the device tree to get hart ID in
riscv_of_processor_hart(). This is used to setup the possible/present cpu
map in setup_smp().

Thus, Linux also need to see a device tree with cpu0-3 instead of cpu1-4.
Otherwise, present cpu map will be incorrect. Isn't it ?


I have some patches floating around that do this, but appear to do it
incorrectly enough that nothing boots so maybe I'm missing something that makes
this complicated :).



Just a wild guess: May be the because of the above reason ;)



Thanks for the test and discussion.  It looks like am implementation issue from
Unleash, so ... is there anything I should fix and provide a further patch?


Nope. Nothing for this issue.
The fix for this issue should be either in bbl or kernel as a separate 
patch.

--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Documentation/i2c: direct users to i2c-tools regarding i2c/smbus.h

[Jean Delvare]

Hi Sam,

Please don't include the same persons in To: and Cc:. It makes the
message delivered twice to them.

On Thu, 19 Apr 2018 15:23:56 -0700, Sam Hansen wrote:
> The current examples reference i2c/smbus.h, which is the first reference
> in Documentation/i2c/dev-interface to anything related to the i2c-tools
> project.  This moves the existing reference to i2c-tools up into the
> C-example, directing the user to the project's git repository.
> 
> Signed-off-by: Sam Hansen 
> ---
>  Documentation/i2c/dev-interface | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/i2c/dev-interface b/Documentation/i2c/dev-interface
> index fbed645ccd75..ed20f7b7851a 100644
> --- a/Documentation/i2c/dev-interface
> +++ b/Documentation/i2c/dev-interface
> @@ -23,6 +23,10 @@ First, you need to include these two headers:
>#include 
>#include 
>  
> +The i2c/smbus header file is provided by the i2c-tools project.  For more 
> info
> +about i2c-tools, see:
> +https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/
> +
>  Now, you have to decide which adapter you want to access. You should
>  inspect /sys/class/i2c-dev/ or run "i2cdetect -l" to decide this.
>  Adapter numbers are assigned somewhat dynamically, so you can not
> @@ -163,10 +167,6 @@ what happened. The 'write' transactions return 0 on 
> success; the
>  returns the number of values read. The block buffers need not be longer
>  than 32 bytes.
>  
> -The above functions are made available by linking against the libi2c library,
> -which is provided by the i2c-tools project.  See:
> -https://git.kernel.org/pub/scm/utils/i2c-tools/i2c-tools.git/.
> -

I'm fine with moving the pointer to i2c-tools up in the document.
However I find it unfortunate to remove the only reference to libi2c.
Typically, distributions will only include the tools in i2c-tools, and
they are not relevant in this case. The library will be in a separate
package (libi2c or similar), and the header file in yet another package
(libi2c-devel or similar.) Although the exact package names are
distribution specific, it would be convenient to hint the reader at
which packages he is supposed to install. You could also mention that
the C program must be compiled with -li2c.

>  
>  Implementation details
>  ==


-- 
Jean Delvare
SUSE L3 Support
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html