Re: [PATCH 16/18] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32

2016-12-07 Thread Catalin Marinas 
On Tue, Dec 06, 2016 at 11:55:08AM +0530, Yury Norov wrote:
> On Mon, Dec 05, 2016 at 04:34:23PM +, Catalin Marinas wrote:
> > On Fri, Oct 21, 2016 at 11:33:15PM +0300, Yury Norov wrote:
> > > New aarch32 ptrace syscall handler is introduced to avoid run-time
> > > detection of the task type.
> > 
> > What's wrong with the run-time detection? If it's just to avoid a
> > negligible overhead, I would rather keep the code simpler by avoiding
> > duplicating the generic compat_sys_ptrace().
> 
> Nothing wrong. This is how Arnd asked me to do. You already asked this
> question: http://lkml.iu.edu/hypermail/linux/kernel/1604.3/00930.html

Hmm, I completely forgot about this ;). There is still an advantage to
doing run-time checking if we avoid touching core code (less acks to
gather and less code duplication).

Let's see what Arnd says but the initial patch looked simpler.

-- 
Catalin
--
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 04/10] Documentation: perf: hisi: Documentation for HIP05/06/07 PMU event counting.

2016-12-07 Thread Anurup M 
Documentation for perf usage and Hisilicon SoC PMU uncore events.
The Hisilicon SOC has event counters for hardware modules like
L3 cache, Miscellaneous node etc. These events are all uncore.

Signed-off-by: Anurup M 
Signed-off-by: Shaokun Zhang 
---
 Documentation/perf/hisi-pmu.txt | 75 +
 1 file changed, 75 insertions(+)
 create mode 100644 Documentation/perf/hisi-pmu.txt

diff --git a/Documentation/perf/hisi-pmu.txt b/Documentation/perf/hisi-pmu.txt
new file mode 100644
index 000..2539caf
--- /dev/null
+++ b/Documentation/perf/hisi-pmu.txt
@@ -0,0 +1,75 @@
+Hisilicon SoC PMU (Performance Monitoring Unit)
+
+The Hisilicon SoC hip05/06/07 chips consist of varous independent system
+device PMU's such as L3 cache(L3C) and Miscellaneous Nodes(MN).
+These PMU devices are independent and have hardware logic to gather
+statistics and performance information.
+
+Hip0x chips are encapsulated by multiple CPU and IO die's. The CPU die is
+called as Super CPU cluster (SCCL) which includes 16 cpu-cores. Every SCCL
+is further grouped as CPU clusters (CCL) which includes 4 cpu-cores each.
+Each SCCL has 1 L3 cache and 1 MN units.
+
+The L3 cache is shared by all CPU cores in a CPU die. The L3C has four banks
+(or instances). Each bank or instance of L3C has Eight 32-bit counter
+registers and also event control registers. The hip05/06 chip L3 cache has
+22 statistics events. The hip07 chip has 66 statistics events. These events
+are very useful for debugging.
+
+The MN module is also shared by all CPU cores in a CPU die. It receives
+barriers and DVM(Distributed Virtual Memory) messages from cpu or smmu, and
+perform the required actions and return response messages. These events are
+very useful for debugging. The MN has total 9 statistics events and support
+four 32-bit counter registers in hip05/06/07 chips.
+
+There is no memory mapping for L3 cache and MN registers. It can be accessed
+by using the Hisilicon djtag interface. The Djtag in a SCCL is an independent
+module which connects with some modules in the SoC by Debug Bus.
+
+Hisilicon SoC (hip05/06/07) PMU driver
+--
+The hip0x PMU driver shall register perf PMU drivers like L3 cache, MN, etc.
+The available events and configuration options shall be described in the sysfs.
+The "perf list" shall list the available events from sysfs.
+
+The L3 cache in a SCCL is divided as 4 banks. Each L3 cache bank have separate
+PMU registers for event counting and control. So each L3 cache bank is
+registered with perf as a separate PMU.
+The PMU name will appear in event listing as hisi_l3c_.
+where "bank-id" is the bank index (0 to 3) and "scl-id" is the SCCL identifier
+e.g. hisi_l3c0_2/read_hit is READ_HIT event of L3 cache bank #0 SCCL ID #2.
+
+The MN in a SCCL is registered as a separate PMU with perf.
+The PMU name will appear in event listing as hisi_mn_.
+e.g. hisi_mn_2/read_req. READ_REQUEST event of MN of Super CPU cluster #2.
+
+The event code is represented by 12 bits.
+   i) event 0-11
+   The event code will be represented using the LSB 12 bits.
+
+The driver also provides a "cpumask" sysfs attribute, which shows the CPU core
+ID used to count the uncore PMU event.
+
+Example usage of perf:
+$# perf list
+hisi_l3c0_2/read_hit/ [kernel PMU event]
+--
+hisi_l3c1_2/write_hit/ [kernel PMU event]
+--
+hisi_l3c0_1/read_hit/ [kernel PMU event]
+--
+hisi_l3c0_1/write_hit/ [kernel PMU event]
+--
+hisi_mn_2/read_req/ [kernel PMU event]
+hisi_mn_2/write_req/ [kernel PMU event]
+--
+
+$# perf stat -a -e "hisi_l3c0_2/read_allocate/" sleep 5
+
+$# perf stat -A -C 0 -e "hisi_l3c0_2/read_allocate/" sleep 5
+
+The current driver doesnot support sampling. so "perf record" is unsupported.
+Also attach to a task is unsupported as the events are all uncore.
+
+Note: Please contact the maintainer for a complete list of events supported for
+the PMU devices in the SoC and its information if needed.
-- 
2.1.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] doc: Explain light-handed markup preference a bit better

2016-12-07 Thread Daniel Vetter 
We already had a super-short blurb, but worth extending it I think:
We're still pretty far away from anything like a consensus, but
there's clearly a lot of people who prefer an as-light as possible
approach to converting existing .txt files to .rst. Make sure this is
properly taken into account and clear.

Motivated by discussions with Peter and Christoph and others.

v2:
- Mention that existing headings should be kept when converting
  existing .txt files (Mauro).
- Explain that we prefer :: for quoting code, it's easier on the
  eyes (Mauro).
- Explain that blindly converting outdated docs is harmful. Motived
  by comments Peter did in our discussion.

v3: Make the explanations around fixed-width quoting more concise
(Jani).

Cc: Jonathan Corbet 
Cc: linux-doc@vger.kernel.org
Cc: Christoph Hellwig 
Cc: Peter Zijlstra 
Cc: Jani Nikula 
Cc: Mauro Carvalho Chehab 
Signed-off-by: Daniel Vetter 
---
 Documentation/kernel-documentation.rst | 28 ++--
 1 file changed, 26 insertions(+), 2 deletions(-)

diff --git a/Documentation/kernel-documentation.rst 
b/Documentation/kernel-documentation.rst
index 0dd17069bc0b..5bffe5a418aa 100644
--- a/Documentation/kernel-documentation.rst
+++ b/Documentation/kernel-documentation.rst
@@ -77,9 +77,27 @@ Specific guidelines for the kernel documentation
 
 Here are some specific guidelines for the kernel documentation:
 
-* Please don't go overboard with reStructuredText markup. Keep it simple.
+* Please don't go overboard with reStructuredText markup. Keep it simple. A lot
+  of core kernel developers prefer plain text, with a big emphasis on plain. In
+  the end if we have pretty generated docs which the subject experts don't
+  like to edit and keep up-to-date everyone loses.
 
-* Please stick to this order of heading adornments:
+  Be especially considerate when converting existing documentation. There's a
+  wide scale from annotating every little bit with in-line styles to only
+  touching up the bare minimum needed to integrate an existing file into the
+  larger documentation. Please align with the wishes of the maintainer to make
+  sure that documentations stays useful for everyone.
+
+* Don't just blindly convert documents, also carefully review them and fix up
+  any issues in the text itself. Updated docs might trick readers into 
believing
+  they're accurately reflecting current best practice, which would be rather
+  harmful if the text itself is entirely outdated.
+
+* When converting existing documents, please try to retain the existing heading
+  styles as much as possible. Sphinx accept almost anything, as long as it's
+  consistent and headings all start in column 1.
+
+  For new documents please stick to this order of heading adornments:
 
   1. ``=`` with overline for document title::
 
@@ -107,6 +125,12 @@ Here are some specific guidelines for the kernel 
documentation:
   the order as encountered."), having the higher levels the same overall makes
   it easier to follow the documents.
 
+* For inserting fixed width text blocks (for code examples, use case
+  examples, etc.), use ``::`` for anything that doesn't really benefit
+  from syntax highlighting, especially short snippets. Use
+  ``.. code-block:: `` for longer code blocks that benefit
+  from highlighting.
+
 
 the C domain
 
-- 
2.10.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/2] Add maintainers to the admin guide

2016-12-07 Thread Daniel Vetter 
On Fri, Dec 02, 2016 at 10:15:13AM -0200, Mauro Carvalho Chehab wrote:
> That's my third attempt to add the MAINTAINERS contents to the admin-guide.
> 
> On the past approaches, was planning to keep the documentation
> about what's at the MAINTAINERS file inside it, but that would
> require running an external script or use some Sphinx extension.
> 
> This time, I took a much simpler approach: convert the initial
> part of the MAINTAINERS file to ReST and move to a file at the
> admin-guide. So, MAINTAINERS file will now contain only the
> maintainer's database, and a single line pointing to its documentation.
> 
> That should hopefully be a good compromise, as we can add its
> contents to a Sphinx file without causing too much hasle.

Yeah, this seems like a rather neat approach and hopefully keeps everyone
happy. Will probably conflict since there's some in-flight patches to
document the new B: tag a bit better. Anyway:

Reviewed-by: Daniel Vetter 

> 
> 
> Mauro Carvalho Chehab (2):
>   MAINTAINERS: convert first part to ReST markup
>   MAINTAINERS: add it to the admin-guide
> 
>  Documentation/admin-guide/index.rst   |   1 +
>  Documentation/admin-guide/maintainers.rst | 184 
> ++
>  MAINTAINERS   | 125 +---
>  3 files changed, 187 insertions(+), 123 deletions(-)
>  create mode 100644 Documentation/admin-guide/maintainers.rst
> 
> -- 
> 2.9.3
> 
> 
> --
> 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

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
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] doc: Explain light-handed markup preference a bit better

2016-12-07 Thread Daniel Vetter 
On Tue, Dec 06, 2016 at 08:52:41AM +0100, Peter Zijlstra wrote:
> On Tue, Nov 29, 2016 at 02:17:52PM +0100, Daniel Vetter wrote:
> > Hi Peter,
> > 
> > On Tue, Nov 29, 2016 at 10:23:14AM +0100, Daniel Vetter wrote:
> > > We already had a super-short blurb, but worth extending it I think:
> > > We're still pretty far away from anything like a consensus, but
> > > there's clearly a lot of people who prefer an as-light as possible
> > > approach to converting existing .txt files to .rst. Make sure this is
> > > properly taken into account and clear.
> > > 
> > > Motivated by discussions with Peter and Christoph and others.
> > > 
> > > v2:
> > > - Mention that existing headings should be kept when converting
> > >   existing .txt files (Mauro).
> > > - Explain that we prefer :: for quoting code, it's easier on the
> > >   eyes (Mauro).
> > > - Explain that blindly converting outdated docs is harmful. Motived
> > >   by comments Peter did in our discussion.
> > > 
> > > Cc: Jonathan Corbet 
> > > Cc: linux-doc@vger.kernel.org
> > > Cc: Christoph Hellwig 
> > > Cc: Peter Zijlstra 
> > > Cc: Jani Nikula 
> > > Cc: Mauro Carvalho Chehab 
> > > Signed-off-by: Daniel Vetter 
> > 
> > Since this was motivated by a discussion you've (re)started, does this
> > sufficiently address your concerns for conversion from plain text .txt to
> > plain text .rst of existing documents? Anything you'd want to see changed?
> 
> Seems OK to me, but there's already a bunch of bike-shedding in this
> thread.

Thanks for taking a look, I'll resend trying to address the other feedback
and make everyone happy.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
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] doc: Explain light-handed markup preference a bit better

2016-12-07 Thread Daniel Vetter 
On Tue, Nov 29, 2016 at 05:08:30PM +0200, Jani Nikula wrote:
> On Tue, 29 Nov 2016, Mauro Carvalho Chehab  wrote:
> > Sorry, but I agree with Daniel here: we should provide a guide
> > for those people that will be helping with the document conversion.
> 
> That goal is not mutually exclusive with keeping this document concise.
> 
> That is all.

Opted for some comprimise-y thing, going with Jani's proposal for the
fixed-width quoting (since mine was definitely too wordy), but opted to
keep the others unchanged. Still feels like overall a concise and balanced
expose, but happy to change if folks object.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
--
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 6/6] net: smmac: allow configuring lower pbl values

2016-12-07 Thread Niklas Cassel 
From: Niklas Cassel 

The driver currently always sets the PBLx8/PBLx4 bit, which means that
the pbl values configured via the pbl/txpbl/rxpbl DT properties are
always multiplied by 8/4 in the hardware.

In order to allow the DT to configure lower pbl values, while at the
same time not changing behavior of any existing device trees using the
pbl/txpbl/rxpbl settings, add a property to disable the multiplication
of the pbl by 8/4 in the hardware.

Suggested-by: Rabin Vincent 
Signed-off-by: Niklas Cassel 
---
 Documentation/devicetree/bindings/net/stmmac.txt  | 2 ++
 Documentation/networking/stmmac.txt   | 5 -
 drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c   | 3 ++-
 drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c  | 3 ++-
 drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c  | 2 ++
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c | 1 +
 include/linux/stmmac.h| 1 +
 7 files changed, 14 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/stmmac.txt 
b/Documentation/devicetree/bindings/net/stmmac.txt
index 8080038ff1b2..128da752fec9 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -39,6 +39,8 @@ Optional properties:
If set, DMA tx will use this value rather than snps,pbl.
 - snps,rxpbl   Rx Programmable Burst Length. Only for GMAC and newer.
If set, DMA rx will use this value rather than snps,pbl.
+- snps,no-pbl-x8   Don't multiply the pbl/txpbl/rxpbl values by 8.
+   For core rev < 3.50, don't multiply the values by 4.
 - snps,aal Address-Aligned Beats
 - snps,fixed-burst Program the DMA to use the fixed burst mode
 - snps,mixed-burst Program the DMA to use the mixed burst mode
diff --git a/Documentation/networking/stmmac.txt 
b/Documentation/networking/stmmac.txt
index 6add57374f70..2bb07078f535 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
@@ -152,8 +152,9 @@ Where:
  o dma_cfg: internal DMA parameters
o pbl: the Programmable Burst Length is maximum number of beats to
be transferred in one DMA transaction.
-   GMAC also enables the 4xPBL by default.
+   GMAC also enables the 4xPBL by default. (8xPBL for GMAC 3.50 and newer)
o txpbl/rxpbl: GMAC and newer supports independent DMA pbl for tx/rx.
+   o pblx8: Enable 8xPBL (4xPBL for core rev < 3.50). Enabled by default.
o fixed_burst/mixed_burst/aal
  o clk_csr: fixed CSR Clock range selection.
  o has_gmac: uses the GMAC core.
@@ -208,6 +209,7 @@ struct stmmac_dma_cfg {
int pbl;
int txpbl;
int rxpbl;
+   bool pblx8;
int fixed_burst;
int mixed_burst;
bool aal;
@@ -219,6 +221,7 @@ Where:
 If set, DMA tx will use this value rather than pbl.
  o rxpbl: Receive Programmable Burst Length. Only for GMAC and newer.
 If set, DMA rx will use this value rather than pbl.
+ o pblx8: Enable 8xPBL (4xPBL for core rev < 3.50). Enabled by default.
  o fixed_burst: program the DMA to use the fixed burst mode
  o mixed_burst: program the DMA to use the mixed burst mode
  o aal: Address-Aligned Beats
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
index 99b8040af592..612d3aaac9a4 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
@@ -98,7 +98,8 @@ static void dwmac1000_dma_init(void __iomem *ioaddr,
 * Note: before stmmac core 3.50 this mode bit was 4xPBL, and
 * post 3.5 mode bit acts as 8*PBL.
 */
-   value |= DMA_BUS_MODE_MAXPBL;
+   if (dma_cfg->pblx8)
+   value |= DMA_BUS_MODE_MAXPBL;
value |= DMA_BUS_MODE_USP;
value &= ~(DMA_BUS_MODE_PBL_MASK | DMA_BUS_MODE_RPBL_MASK);
value |= (txpbl << DMA_BUS_MODE_PBL_SHIFT);
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
index 2c3b2098f350..8196ab5fc33c 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c
@@ -84,7 +84,8 @@ static void dwmac4_dma_init_channel(void __iomem *ioaddr,
 * on each channel
 */
value = readl(ioaddr + DMA_CHAN_CONTROL(channel));
-   value = value | DMA_BUS_MODE_PBL;
+   if (dma_cfg->pblx8)
+   value = value | DMA_BUS_MODE_PBL;
writel(value, ioaddr + DMA_CHAN_CONTROL(channel));
 
value = readl(ioaddr + DMA_CHAN_TX_CONTROL(channel));
diff --git a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c 
b/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
index 56c8a2342c14..a2831773431a 100644
--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c
+++

[PATCH v3 5/6] net: stmmac: add support for independent DMA pbl for tx/rx

2016-12-07 Thread Niklas Cassel 
From: Niklas Cassel 

GMAC and newer supports independent programmable burst lengths for
DMA tx/rx. Add new optional devicetree properties representing this.

To be backwards compatible, snps,pbl will still be valid, but
snps,txpbl/snps,rxpbl will override the value in snps,pbl if set.

If the IP is synthesized to use the AXI interface, there is a register
and a matching DT property inside the optional stmmac-axi-config DT node
for controlling burst lengths, named snps,blen.
However, using this register, it is not possible to control tx and rx
independently. Also, this register is not available if the IP was
synthesized with, e.g., the AHB interface.

Signed-off-by: Niklas Cassel 
---
 Documentation/devicetree/bindings/net/stmmac.txt  |  6 +-
 Documentation/networking/stmmac.txt   | 19 +--
 drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c   | 12 ++--
 drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c  | 12 +++-
 drivers/net/ethernet/stmicro/stmmac/stmmac_platform.c |  2 ++
 include/linux/stmmac.h|  2 ++
 6 files changed, 35 insertions(+), 18 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/stmmac.txt 
b/Documentation/devicetree/bindings/net/stmmac.txt
index b95ff998ba73..8080038ff1b2 100644
--- a/Documentation/devicetree/bindings/net/stmmac.txt
+++ b/Documentation/devicetree/bindings/net/stmmac.txt
@@ -34,7 +34,11 @@ Optional properties:
   platforms.
 - tx-fifo-depth: See ethernet.txt file in the same directory
 - rx-fifo-depth: See ethernet.txt file in the same directory
-- snps,pbl Programmable Burst Length
+- snps,pbl Programmable Burst Length (tx and rx)
+- snps,txpbl   Tx Programmable Burst Length. Only for GMAC and newer.
+   If set, DMA tx will use this value rather than snps,pbl.
+- snps,rxpbl   Rx Programmable Burst Length. Only for GMAC and newer.
+   If set, DMA rx will use this value rather than snps,pbl.
 - snps,aal Address-Aligned Beats
 - snps,fixed-burst Program the DMA to use the fixed burst mode
 - snps,mixed-burst Program the DMA to use the mixed burst mode
diff --git a/Documentation/networking/stmmac.txt 
b/Documentation/networking/stmmac.txt
index 014f4f756cb7..6add57374f70 100644
--- a/Documentation/networking/stmmac.txt
+++ b/Documentation/networking/stmmac.txt
@@ -153,7 +153,8 @@ Where:
o pbl: the Programmable Burst Length is maximum number of beats to
be transferred in one DMA transaction.
GMAC also enables the 4xPBL by default.
-   o fixed_burst/mixed_burst/burst_len
+   o txpbl/rxpbl: GMAC and newer supports independent DMA pbl for tx/rx.
+   o fixed_burst/mixed_burst/aal
  o clk_csr: fixed CSR Clock range selection.
  o has_gmac: uses the GMAC core.
  o enh_desc: if sets the MAC will use the enhanced descriptor structure.
@@ -205,16 +206,22 @@ tuned according to the HW capabilities.
 
 struct stmmac_dma_cfg {
int pbl;
+   int txpbl;
+   int rxpbl;
int fixed_burst;
-   int burst_len_supported;
+   int mixed_burst;
+   bool aal;
 };
 
 Where:
- o pbl: Programmable Burst Length
+ o pbl: Programmable Burst Length (tx and rx)
+ o txpbl: Transmit Programmable Burst Length. Only for GMAC and newer.
+If set, DMA tx will use this value rather than pbl.
+ o rxpbl: Receive Programmable Burst Length. Only for GMAC and newer.
+If set, DMA rx will use this value rather than pbl.
  o fixed_burst: program the DMA to use the fixed burst mode
- o burst_len: this is the value we put in the register
- supported values are provided as macros in
- linux/stmmac.h header file.
+ o mixed_burst: program the DMA to use the mixed burst mode
+ o aal: Address-Aligned Beats
 
 ---
 
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
index 318ae9f10104..99b8040af592 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac1000_dma.c
@@ -89,20 +89,20 @@ static void dwmac1000_dma_init(void __iomem *ioaddr,
   u32 dma_tx, u32 dma_rx, int atds)
 {
u32 value = readl(ioaddr + DMA_BUS_MODE);
+   int txpbl = dma_cfg->txpbl ?: dma_cfg->pbl;
+   int rxpbl = dma_cfg->rxpbl ?: dma_cfg->pbl;
 
/*
 * Set the DMA PBL (Programmable Burst Length) mode.
 *
 * Note: before stmmac core 3.50 this mode bit was 4xPBL, and
 * post 3.5 mode bit acts as 8*PBL.
-*
-* This configuration doesn't take care about the Separate PBL
-* so only the bits: 13-8 are programmed with the PBL passed from the
-* platform.
 */
value |= DMA_BUS_MODE_MAXPBL;
-   value &= ~DMA_BUS_MODE_PBL_MASK;
-   value |= (dma_cfg->pbl <<

[PATCH v3 0/6] net: stmmac: make DMA programmable burst length more configurable

2016-12-07 Thread Niklas Cassel 
Make DMA programmable burst length more configurable in the stmmac driver.

This is done by adding support for independent pbl for tx/rx through DT.
More fine grained tuning of pbl is possible thanks to a DT property saying
that we should NOT multiply pbl values by x8/x4 in hardware.

All new DT properties are optional, and created in a way that it will not
affect any existing DT configurations.

Changes since V1:
Created cover-letter.
Rebased patch set against next-20161205, since conflicting patches to
stmmac_platform.c has been merged since V1.

Changes since V2:
Moved default value initialization of pbl to stmmac_platform.c
and added a check for pbl != 0 in stmmac_main.c,
to catch a possble pbl == 0 from pci glue.


Niklas Cassel (6):
  net: stmmac: return error if no DMA configuration is found
  net: stmmac: simplify the common DMA init API
  net: stmmac: stmmac_platform: fix parsing of DT binding
  net: stmmac: dwmac1000: fix define DMA_BUS_MODE_RPBL_MASK
  net: stmmac: add support for independent DMA pbl for tx/rx
  net: smmac: allow configuring lower pbl values

 Documentation/devicetree/bindings/net/stmmac.txt   |  8 +-
 Documentation/networking/stmmac.txt| 24 +++-
 drivers/net/ethernet/stmicro/stmmac/common.h   |  4 +--
 drivers/net/ethernet/stmicro/stmmac/dwmac1000.h|  2 +-
 .../net/ethernet/stmicro/stmmac/dwmac1000_dma.c| 26 ++
 drivers/net/ethernet/stmicro/stmmac/dwmac100_dma.c |  7 +++--
 drivers/net/ethernet/stmicro/stmmac/dwmac4_dma.c   | 25 ++---
 drivers/net/ethernet/stmicro/stmmac/stmmac_main.c  | 14 --
 drivers/net/ethernet/stmicro/stmmac/stmmac_pci.c   |  2 ++
 .../net/ethernet/stmicro/stmmac/stmmac_platform.c  | 32 --
 include/linux/stmmac.h |  3 ++
 11 files changed, 88 insertions(+), 59 deletions(-)

-- 
2.1.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: [RFC PATCH v3 10/20] Add support to access boot related data in the clear

2016-12-07 Thread Matt Fleming 
On Wed, 09 Nov, at 06:36:31PM, Tom Lendacky wrote:
> Boot data (such as EFI related data) is not encrypted when the system is
> booted and needs to be accessed unencrypted.  Add support to apply the
> proper attributes to the EFI page tables and to the early_memremap and
> memremap APIs to identify the type of data being accessed so that the
> proper encryption attribute can be applied.
> 
> Signed-off-by: Tom Lendacky 
> ---
>  arch/x86/include/asm/e820.h|1 
>  arch/x86/kernel/e820.c |   16 +++
>  arch/x86/mm/ioremap.c  |   89 
> 
>  arch/x86/platform/efi/efi_64.c |   12 -
>  drivers/firmware/efi/efi.c |   33 +++
>  include/linux/efi.h|2 +
>  kernel/memremap.c  |8 +++-
>  mm/early_ioremap.c |   18 +++-
>  8 files changed, 172 insertions(+), 7 deletions(-)
 
FWIW, I think this version is an improvement over all the previous
ones.

[...]

> diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
> index ff542cd..ee347c2 100644
> --- a/arch/x86/mm/ioremap.c
> +++ b/arch/x86/mm/ioremap.c
> @@ -20,6 +20,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  #include "physaddr.h"
>  
> @@ -418,6 +421,92 @@ void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr)
>   iounmap((void __iomem *)((unsigned long)addr & PAGE_MASK));
>  }
>  
> +static bool memremap_setup_data(resource_size_t phys_addr,
> + unsigned long size)
> +{
> + u64 paddr;
> +
> + if (phys_addr == boot_params.hdr.setup_data)
> + return true;
> +

Why is the setup_data linked list not traversed when checking for
matching addresses? Am I reading this incorrectly? I don't see how
this can work.

> + paddr = boot_params.efi_info.efi_memmap_hi;
> + paddr <<= 32;
> + paddr |= boot_params.efi_info.efi_memmap;
> + if (phys_addr == paddr)
> + return true;
> +
> + paddr = boot_params.efi_info.efi_systab_hi;
> + paddr <<= 32;
> + paddr |= boot_params.efi_info.efi_systab;
> + if (phys_addr == paddr)
> + return true;
> +
> + if (efi_table_address_match(phys_addr))
> + return true;
> +
> + return false;
> +}
> +
> +static bool memremap_apply_encryption(resource_size_t phys_addr,
> +   unsigned long size)
> +{
> + /* SME is not active, just return true */
> + if (!sme_me_mask)
> + return true;
> +
> + /* Check if the address is part of the setup data */
> + if (memremap_setup_data(phys_addr, size))
> + return false;
> +
> + /* Check if the address is part of EFI boot/runtime data */
> + switch (efi_mem_type(phys_addr)) {
> + case EFI_BOOT_SERVICES_DATA:
> + case EFI_RUNTIME_SERVICES_DATA:
> + return false;
> + }

EFI_LOADER_DATA is notable by its absence.

We use that memory type for allocations inside of the EFI boot stub
that are than used while the kernel is running. One use that comes to
mind is for initrd files, see handle_cmdline_files().

Oh I see you handle that in PATCH 9, never mind.

> diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
> index 58b0f80..3f89179 100644
> --- a/arch/x86/platform/efi/efi_64.c
> +++ b/arch/x86/platform/efi/efi_64.c
> @@ -221,7 +221,13 @@ int __init efi_setup_page_tables(unsigned long 
> pa_memmap, unsigned num_pages)
>   if (efi_enabled(EFI_OLD_MEMMAP))
>   return 0;
>  
> - efi_scratch.efi_pgt = (pgd_t *)__pa(efi_pgd);
> + /*
> +  * Since the PGD is encrypted, set the encryption mask so that when
> +  * this value is loaded into cr3 the PGD will be decrypted during
> +  * the pagetable walk.
> +  */
> + efi_scratch.efi_pgt = (pgd_t *)__sme_pa(efi_pgd);
> +
>   pgd = efi_pgd;
>  
>   /*

Do all callers of __pa() in arch/x86 need fixing up like this?
--
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: [RFC PATCH v3 1/1] docs-rst: automatically convert Graphviz and SVG images

2016-12-07 Thread Mauro Carvalho Chehab 
Hi Markus,

Em Wed,  7 Dec 2016 09:49:44 +0100
Markus Heiser  escreveu:

> This patch brings scalable figure, image handling and a concept to
> embed *render* markups:
> 
> * DOT (http://www.graphviz.org)
> * SVG
> 
> For image handling use the 'image' replacement::
> 
> .. kernel-image::  svg_image.svg
>:alt:simple SVG image
> 
> For figure handling use the 'figure' replacement::
> 
> .. kernel-figure::  svg_image.svg
>:alt:simple SVG image
> 
>SVG image example
> 
> Embed *render* markups (or languages) like Graphviz's **DOC** is
> provided by the *render* directive.::
> 
>   .. kernel-render:: DOT
>  :alt: foobar digraph
>  :caption: Embedded **DOT** (Graphviz) code.
> 
>  digraph foo {
>   "bar" -> "baz";
>  }
> 
> The *render* directive is a concept to integrate *render* markups and
> languages, yet supported markups:
> 
> * DOT: render embedded Graphviz's **DOC**
> * SVG: render embedded Scalable Vector Graphics (**SVG**)

Nice work! Didn't test it yet, but, from what you exposed, it seems
to meet our needs ;)

I didn't review the python code itself, as others can provide a better
feedback than me on that, but I have a few comments about the 
documentation. See below.

> 
> Signed-off-by: Markus Heiser 
> ---
>  Documentation/conf.py |   2 +-
>  Documentation/doc-guide/hello.dot |   3 +
>  Documentation/doc-guide/sphinx.rst|  90 +-
>  Documentation/doc-guide/svg_image.svg |  10 +
>  Documentation/process/changes.rst |   8 +-
>  Documentation/sphinx/kfigure.py   | 505 
> ++
>  6 files changed, 612 insertions(+), 6 deletions(-)
>  create mode 100644 Documentation/doc-guide/hello.dot
>  create mode 100644 Documentation/doc-guide/svg_image.svg
>  create mode 100644 Documentation/sphinx/kfigure.py
> 
> diff --git a/Documentation/conf.py b/Documentation/conf.py
> index 1ac958c..19ea030 100644
> --- a/Documentation/conf.py
> +++ b/Documentation/conf.py
> @@ -34,7 +34,7 @@ from load_config import loadConfig
>  # Add any Sphinx extension module names here, as strings. They can be
>  # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
>  # ones.
> -extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain']
> +extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain', 
> 'kfigure']
>  
>  # The name of the math extension changed on Sphinx 1.4
>  if major == 1 and minor > 3:
> diff --git a/Documentation/doc-guide/hello.dot 
> b/Documentation/doc-guide/hello.dot
> new file mode 100644
> index 000..504621d
> --- /dev/null
> +++ b/Documentation/doc-guide/hello.dot
> @@ -0,0 +1,3 @@
> +graph G {
> +  Hello -- World
> +}
> diff --git a/Documentation/doc-guide/sphinx.rst 
> b/Documentation/doc-guide/sphinx.rst
> index 96fe7ccb..c7c7876 100644
> --- a/Documentation/doc-guide/sphinx.rst
> +++ b/Documentation/doc-guide/sphinx.rst
> @@ -34,8 +34,10 @@ format-specific subdirectories under 
> ``Documentation/output``.
>  
>  To generate documentation, Sphinx (``sphinx-build``) must obviously be
>  installed. For prettier HTML output, the Read the Docs Sphinx theme
> -(``sphinx_rtd_theme``) is used if available. For PDF output, ``rst2pdf`` is 
> also
> -needed. All of these are widely available and packaged in distributions.
> +(``sphinx_rtd_theme``) is used if available. For PDF output you'll also need
> +``XeLaTeX`` and CairoSVG (http://cairosvg.org) or alternatively 
> ``convert(1)``
> +from ImageMagick (https://www.imagemagick.org). All of these are widely
> +available and packaged in distributions.

You forgot to mention Graphviz here.

>  
>  To pass extra options to Sphinx, you can use the ``SPHINXOPTS`` make
>  variable. For example, use ``make SPHINXOPTS=-v htmldocs`` to get more 
> verbose
> @@ -217,3 +219,87 @@ Rendered as:
>* .. _`last row`:
>  
>  - column 3
> +
> +
> +Figures & Images
> +
> +
> +If you want to add an image, you should use the ``kernel-figure`` and
> +``kernel-image`` directives. E.g. to insert a figure with a scalable
> +image format use SVG::

As discussed upstream, the idea is to avoid using bitmap images inside
the Kernel documentation.

On my previous patch, I added this:

The Kernel documentation new build system is prepared for two types of
images: `Graphviz `__ (``*.dot``) diagrams
and Scalable Vector Graphics (``*.svg``). While Sphinx also supports a 
few
bitmap formats, please don't use it, as it may not work on all output 
formats.

> +
> +.. kernel-figure::  svg_image.svg
> +   :alt:simple SVG image
> +
> +   SVG image example
> +
> +.. kernel-figure::  svg_image.svg
> +   :alt:simple SVG image
> +
> +   SVG image example
> +
> +The kernel figure (and image) directive support **DOT** formated files, see
> +
> +* DOT:

[RFC PATCH v3 1/1] docs-rst: automatically convert Graphviz and SVG images

2016-12-07 Thread Markus Heiser 
This patch brings scalable figure, image handling and a concept to
embed *render* markups:

* DOT (http://www.graphviz.org)
* SVG

For image handling use the 'image' replacement::

.. kernel-image::  svg_image.svg
   :alt:simple SVG image

For figure handling use the 'figure' replacement::

.. kernel-figure::  svg_image.svg
   :alt:simple SVG image

   SVG image example

Embed *render* markups (or languages) like Graphviz's **DOC** is
provided by the *render* directive.::

  .. kernel-render:: DOT
 :alt: foobar digraph
 :caption: Embedded **DOT** (Graphviz) code.

 digraph foo {
  "bar" -> "baz";
 }

The *render* directive is a concept to integrate *render* markups and
languages, yet supported markups:

* DOT: render embedded Graphviz's **DOC**
* SVG: render embedded Scalable Vector Graphics (**SVG**)

Signed-off-by: Markus Heiser 
---
 Documentation/conf.py |   2 +-
 Documentation/doc-guide/hello.dot |   3 +
 Documentation/doc-guide/sphinx.rst|  90 +-
 Documentation/doc-guide/svg_image.svg |  10 +
 Documentation/process/changes.rst |   8 +-
 Documentation/sphinx/kfigure.py   | 505 ++
 6 files changed, 612 insertions(+), 6 deletions(-)
 create mode 100644 Documentation/doc-guide/hello.dot
 create mode 100644 Documentation/doc-guide/svg_image.svg
 create mode 100644 Documentation/sphinx/kfigure.py

diff --git a/Documentation/conf.py b/Documentation/conf.py
index 1ac958c..19ea030 100644
--- a/Documentation/conf.py
+++ b/Documentation/conf.py
@@ -34,7 +34,7 @@ from load_config import loadConfig
 # Add any Sphinx extension module names here, as strings. They can be
 # extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
 # ones.
-extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain']
+extensions = ['kerneldoc', 'rstFlatTable', 'kernel_include', 'cdomain', 
'kfigure']
 
 # The name of the math extension changed on Sphinx 1.4
 if major == 1 and minor > 3:
diff --git a/Documentation/doc-guide/hello.dot 
b/Documentation/doc-guide/hello.dot
new file mode 100644
index 000..504621d
--- /dev/null
+++ b/Documentation/doc-guide/hello.dot
@@ -0,0 +1,3 @@
+graph G {
+  Hello -- World
+}
diff --git a/Documentation/doc-guide/sphinx.rst 
b/Documentation/doc-guide/sphinx.rst
index 96fe7ccb..c7c7876 100644
--- a/Documentation/doc-guide/sphinx.rst
+++ b/Documentation/doc-guide/sphinx.rst
@@ -34,8 +34,10 @@ format-specific subdirectories under 
``Documentation/output``.
 
 To generate documentation, Sphinx (``sphinx-build``) must obviously be
 installed. For prettier HTML output, the Read the Docs Sphinx theme
-(``sphinx_rtd_theme``) is used if available. For PDF output, ``rst2pdf`` is 
also
-needed. All of these are widely available and packaged in distributions.
+(``sphinx_rtd_theme``) is used if available. For PDF output you'll also need
+``XeLaTeX`` and CairoSVG (http://cairosvg.org) or alternatively ``convert(1)``
+from ImageMagick (https://www.imagemagick.org). All of these are widely
+available and packaged in distributions.
 
 To pass extra options to Sphinx, you can use the ``SPHINXOPTS`` make
 variable. For example, use ``make SPHINXOPTS=-v htmldocs`` to get more verbose
@@ -217,3 +219,87 @@ Rendered as:
   * .. _`last row`:
 
 - column 3
+
+
+Figures & Images
+
+
+If you want to add an image, you should use the ``kernel-figure`` and
+``kernel-image`` directives. E.g. to insert a figure with a scalable
+image format use SVG::
+
+.. kernel-figure::  svg_image.svg
+   :alt:simple SVG image
+
+   SVG image example
+
+.. kernel-figure::  svg_image.svg
+   :alt:simple SVG image
+
+   SVG image example
+
+The kernel figure (and image) directive support **DOT** formated files, see
+
+* DOT: http://graphviz.org/pdf/dotguide.pdf
+* Graphviz: http://www.graphviz.org/content/dot-language
+
+A simple example::
+
+  .. kernel-figure::  hello.dot
+ :alt:hello world
+
+ DOT's hello world example
+
+.. kernel-figure::  hello.dot
+   :alt:hello world
+
+   DOT's hello world example
+
+Embed *render* markups (or languages) like Graphviz's **DOC** is provided by 
the
+``kernel-render`` directives.::
+
+  .. kernel-render:: DOT
+ :alt: foobar digraph
+ :caption: Embedded **DOT** (Graphviz) code.
+
+ digraph foo {
+  "bar" -> "baz";
+ }
+
+How this will be rendered depends on the installed tools. If Graphviz is
+installed, you will see an vector image. If not the raw markup is inserted as
+*literal-block*.
+
+.. kernel-render:: DOT
+   :alt: foobar digraph
+   :caption: Embedded **DOT** (Graphviz) code.
+
+   digraph foo {
+  "bar" -> "baz";
+   }
+
+The *render* directive has all the options known from the *figure* directive,
+plus option ``caption``.  If ``caption`` has a value, a *figure* node is
+inserted. If not, a *image* node is inserted.
+
+Embedded **SVG**::
+
+