Re: [PATCH] hpet: update the link

[Thomas Gleixner]

On Tue, 26 Jan 2016, Michael S. Tsirkin wrote:

> Looks like the HPET spec at intel.com got moved.
> Update the link.

Either we remove that link completely or we store that document at some stable
URL on kernel.org and be done with it.

I prefer to remove it. 

  1) It's just a bad example of hardware design by committee and we really do
 not need to promote it.
 
  2) Finding that spec if you really have to is not rocket science either.
 
Thanks,

tglx
--
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: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled

[Eric W. Biederman]

Kees Cook  writes:

> On Tue, Jan 26, 2016 at 9:15 AM, Serge Hallyn  wrote:
>> Quoting Josh Boyer (jwbo...@fedoraproject.org):
>>> What you're saying is true for the "oh crap" case of a new userns
>>> related CVE being found.  However, there is the case where sysadmins
>>> know for a fact that a set of machines should not allow user
>>> namespaces to be enabled.  Currently they have 2 choices, 1) use their
>>
>> Hi - can you give a specific example of this?  (Where users really should
>> not be able to use them - not where they might not need them)  I think
>> it'll help the discussion tremendously.  Because so far the only good
>> arguments I've seen have been about actual bugs in the user namespaces,
>> which would not warrant a designed-in permanent disable switch.  If
>> there are good use cases where such a disable switch will always be
>> needed (and compiling out can't satisfy) that'd be helpful.
>
> My example is a machine in a colo rack serving web pages. A site gets
> attacked, and www-data uses user namespaces to continue their attack
> to gain root privileges.
>
> The admin of such a machine could have disabled userns months earlier
> and limited the scope of the attack.

Of course for the paranoid there is already a mechanism to do this.
/sbin/chroot.

No new user namespaces are allowed to be created inside of a chroot.

Eric

--
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] pstore-ram: add Device Tree bindings

[Markus Pargmann]

Hi,

sorry for the late response.

On Thu, Jan 07, 2016 at 03:40:56PM -0800, Greg Hackmann wrote:
> ramoops is one of the remaining places where ARM vendors still rely on
> board-specific shims.  Device Tree lets us replace those shims with
> generic code.
> 
> These bindings mirror the ramoops module parameters, with two small
> differences:
> 
> (1) dump_oops becomes an optional "no-dump-oops" property, since ramoops
> sets dump_oops=1 by default.
> 
> (2) mem_type=1 becomes the more self-explanatory "unbuffered" property.

I thought about the same patch at the end of last year but decided
against this for several reasons.

1) ramoops is a memory region, not hardware or any hardware description.

2) A suitable location for the ramoops depends on many factors. It is
not restricted to a specific board. For example the boot ROM of a SoC
may work differently for different boot mechanisms (usb, nand, SD-Card,
...) and may by accident overwrite the ramoops area given in the
devicetree.

3) Different bootloaders use the available memory differently which may
conflict with the definition in the devicetree and some data is placed
in memory before the devicetree is even accessible, for example if we
are running in sram before switching to a bootloader running in sdram.

These were the reasons why I decided to implement ramoops support in
the bootloader instead. The bootloader is the component that has
knowledge about used memory and it can inform other system components
(kernel) about the ramoops area. This way the ramoops area can be set
where it is not overwritten by any other component.

Best Regards,

Markus

> 
> Signed-off-by: Greg Hackmann 
> ---
> Changes in V3:
> - documentation fixes
> - look for "no-ram-oops" property as documented
> 
> Changes in V2:
> - make DT binding documentation more generic
> 
>  Documentation/devicetree/bindings/misc/ramoops.txt |  43 
>  Documentation/ramoops.txt  |   6 +-
>  fs/pstore/ram.c| 110 
> -
>  3 files changed, 155 insertions(+), 4 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/misc/ramoops.txt
> 
> diff --git a/Documentation/devicetree/bindings/misc/ramoops.txt 
> b/Documentation/devicetree/bindings/misc/ramoops.txt
> new file mode 100644
> index 000..5a475fa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/misc/ramoops.txt
> @@ -0,0 +1,43 @@
> +Ramoops oops/panic logger
> +=
> +
> +ramoops provides persistent RAM storage for oops and panics, so they can be
> +recovered after a reboot.
> +
> +Parts of this storage may be set aside for other persistent log buffers, such
> +as kernel log messages, or for optional ECC error-correction data.  The total
> +size of these optional buffers must fit in the reserved region.
> +
> +Any remaining space will be used for a circular buffer of oops and panic
> +records.  These records have a configurable size, with a size of 0 indicating
> +that they should be disabled.
> +
> +
> +Required properties:
> +
> +- compatible: must be "ramoops"
> +
> +- memory-region: phandle to a region of memory that is preserved between 
> reboots
> +
> +
> +Optional properties:
> +
> +- ecc-size: enables ECC support and specifies ECC buffer size in bytes
> +  (defaults to no ECC)
> +
> +- record-size: maximum size in bytes of each dump done on oops/panic
> +  (defaults to 0)
> +
> +- console-size: size in bytes of log buffer reserved for kernel messages
> +  (defaults to 0)
> +
> +- ftrace-size: size in bytes of log buffer reserved for function tracing and
> +  profiling (defaults to 0)
> +
> +- pmsg-size: size in bytes of log buffer reserved for userspace messages
> +  (defaults to 0)
> +
> +- unbuffered: if present, use unbuffered mappings to map the reserved region
> +  (defaults to buffered mappings)
> +
> +- no-dump-oops: if present, only dump panics (defaults to panics and oops)
> diff --git a/Documentation/ramoops.txt b/Documentation/ramoops.txt
> index 5d86756..9264bca 100644
> --- a/Documentation/ramoops.txt
> +++ b/Documentation/ramoops.txt
> @@ -45,7 +45,7 @@ corrupt, but usually it is restorable.
>  
>  2. Setting the parameters
>  
> -Setting the ramoops parameters can be done in 2 different manners:
> +Setting the ramoops parameters can be done in 3 different manners:
>   1. Use the module parameters (which have the names of the variables 
> described
>   as before).
>   For quick debugging, you can also reserve parts of memory during boot
> @@ -54,7 +54,9 @@ Setting the ramoops parameters can be done in 2 different 
> manners:
>   kernel to use only the first 128 MB of memory, and place ECC-protected 
> ramoops
>   region at 128 MB boundary:
>   "mem=128M ramoops.mem_address=0x800 ramoops.ecc=1"
> - 2. Use a platform device and set the platform data. The parameters can then
> + 2. Use Device Tree bindings, as described in
> + Documentation/device-tree/bindings/misc/ramoops.txt.
> + 3

Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled

[Austin S. Hemmelgarn]

On 2016-01-27 05:27, Eric W. Biederman wrote:

Kees Cook  writes:


On Tue, Jan 26, 2016 at 9:15 AM, Serge Hallyn  wrote:

Quoting Josh Boyer (jwbo...@fedoraproject.org):

What you're saying is true for the "oh crap" case of a new userns
related CVE being found.  However, there is the case where sysadmins
know for a fact that a set of machines should not allow user
namespaces to be enabled.  Currently they have 2 choices, 1) use their


Hi - can you give a specific example of this?  (Where users really should
not be able to use them - not where they might not need them)  I think
it'll help the discussion tremendously.  Because so far the only good
arguments I've seen have been about actual bugs in the user namespaces,
which would not warrant a designed-in permanent disable switch.  If
there are good use cases where such a disable switch will always be
needed (and compiling out can't satisfy) that'd be helpful.


My example is a machine in a colo rack serving web pages. A site gets
attacked, and www-data uses user namespaces to continue their attack
to gain root privileges.

The admin of such a machine could have disabled userns months earlier
and limited the scope of the attack.


Of course for the paranoid there is already a mechanism to do this.
/sbin/chroot.

No new user namespaces are allowed to be created inside of a chroot.
I would like to point out that this is undocumented outside of the 
kernel source code on every Linux system I've seen.  And, it's not 
hugely obvious from looking at the source code unless you have some 
experience with kernel programming.


Also, being able to limit to exactly one (or possibly two depending on 
the application's usage of them) user namespace would be useful, as that 
would allow sand-boxing without the ability to create any more through 
some exploit.

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

Hello dear,

[Mrs. Kumiko Suzuki]

Hi Dear, 

I am Mrs Kumiko Suzuki, from Japan, I Have Been Diagnosed with esophageal 
Cancer. 
I Have Chosen you to distribute my Funds to Charities homes in your Country, 
so if you wish to Carry out this humanitarian Work kindly Get back to me for 
FURTHER details. 

Yours Truely Mrs Suzuki Kumiko
--
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

[PATCHv9 3/4] ARM: socfpga: enable L2 cache ECC on startup

[tthayer]

From: Thor Thayer 

This patch enables the ECC for L2 cache on machine startup. The ECC has to
be enabled before data is stored in memory otherwise the ECC will fail on
reads.

Signed-off-by: Thor Thayer 
---
v9: Improve node put handling.
v8: Address community suggestions for strings. Fix string based on
maintainer feedback. Update year in header.
v7: unmap locally scoped mapped_l2_edac_addr and add of_node_put(np)
v6: Remove pr_debug() & update year in header.
---
 arch/arm/mach-socfpga/Makefile   |1 +
 arch/arm/mach-socfpga/core.h |1 +
 arch/arm/mach-socfpga/l2_cache.c |   41 ++
 arch/arm/mach-socfpga/socfpga.c  |2 ++
 4 files changed, 45 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/l2_cache.c

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index b8f9e23..e9ab7c9 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -5,3 +5,4 @@
 obj-y  := socfpga.o
 obj-$(CONFIG_SMP)  += headsmp.o platsmp.o
 obj-$(CONFIG_SOCFPGA_SUSPEND)  += pm.o self-refresh.o
+obj-$(CONFIG_EDAC_ALTERA_L2C)  += l2_cache.o
diff --git a/arch/arm/mach-socfpga/core.h b/arch/arm/mach-socfpga/core.h
index 5bc6ea8..eb55d66 100644
--- a/arch/arm/mach-socfpga/core.h
+++ b/arch/arm/mach-socfpga/core.h
@@ -36,6 +36,7 @@
 
 extern void socfpga_init_clocks(void);
 extern void socfpga_sysmgr_init(void);
+void socfpga_init_l2_ecc(void);
 
 extern void __iomem *sys_manager_base_addr;
 extern void __iomem *rst_manager_base_addr;
diff --git a/arch/arm/mach-socfpga/l2_cache.c b/arch/arm/mach-socfpga/l2_cache.c
new file mode 100644
index 000..e3907ab
--- /dev/null
+++ b/arch/arm/mach-socfpga/l2_cache.c
@@ -0,0 +1,41 @@
+/*
+ * Copyright Altera Corporation (C) 2016. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+
+void socfpga_init_l2_ecc(void)
+{
+   struct device_node *np;
+   void __iomem *mapped_l2_edac_addr;
+
+   np = of_find_compatible_node(NULL, NULL, "altr,socfpga-l2-ecc");
+   if (!np) {
+   pr_err("Unable to find socfpga-l2-ecc in dtb\n");
+   return;
+   }
+
+   mapped_l2_edac_addr = of_iomap(np, 0);
+   of_node_put(np);
+   if (!mapped_l2_edac_addr) {
+   pr_err("Unable to find L2 ECC mapping in dtb\n");
+   return;
+   }
+
+   /* Enable ECC */
+   writel(0x01, mapped_l2_edac_addr);
+   iounmap(mapped_l2_edac_addr);
+}
diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
index a1c0efa..dd1ff07 100644
--- a/arch/arm/mach-socfpga/socfpga.c
+++ b/arch/arm/mach-socfpga/socfpga.c
@@ -59,6 +59,8 @@ static void __init socfpga_init_irq(void)
 {
irqchip_init();
socfpga_sysmgr_init();
+   if (IS_ENABLED(CONFIG_EDAC_ALTERA_L2C))
+   socfpga_init_l2_ecc();
 }
 
 static void socfpga_cyclone5_restart(enum reboot_mode mode, const char *cmd)
-- 
1.7.9.5

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

[PATCHv9 2/4] ARM: dts: Add Altera L2 Cache and OCRAM EDAC entries

[tthayer]

From: Thor Thayer 

Adding the device tree entries and bindings needed to support
the Altera L2 cache and On-Chip RAM EDAC. This patch relies upon
an earlier patch to declare and setup On-chip RAM properly.
http://www.spinics.net/lists/devicetree/msg51117.html

Signed-off-by: Thor Thayer 
Acked-by: Rob Herring 
---
v9: Remove 0x from ecc-manager in bindings and dts.
v8: Fix node names to include chip family and use ecc manager
to better describe the driver. Rename socfpga-edac.txt to
socfpga-eccmgr.txt.
v7: No Change
v6: Change to nested EDAC device nodes based on community
feedback. Remove L2 syscon. Use consolidated binding.
v3-5: No Change
v2: Remove OCRAM declaration and reference prior patch.
---
 .../bindings/arm/altera/socfpga-eccmgr.txt |   49 
 arch/arm/boot/dts/socfpga.dtsi |   20 
 2 files changed, 69 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt

diff --git a/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt 
b/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
new file mode 100644
index 000..885f93d
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/altera/socfpga-eccmgr.txt
@@ -0,0 +1,49 @@
+Altera SoCFPGA ECC Manager
+This driver uses the EDAC framework to implement the SOCFPGA ECC Manager.
+The ECC Manager counts and corrects single bit errors and counts/handles
+double bit errors which are uncorrectable.
+
+Required Properties:
+- compatible : Should be "altr,socfpga-ecc-manager"
+- #address-cells: must be 1
+- #size-cells: must be 1
+- ranges : standard definition, should translate from local addresses
+
+Subcomponents:
+
+L2 Cache ECC
+Required Properties:
+- compatible : Should be "altr,socfpga-l2-ecc"
+- reg : Address and size for ECC error interrupt clear registers.
+- interrupts : Should be single bit error interrupt, then double bit error
+   interrupt. Note the rising edge type.
+
+On Chip RAM ECC
+Required Properties:
+- compatible : Should be "altr,socfpga-ocram-ecc"
+- reg : Address and size for ECC error interrupt clear registers.
+- iram : phandle to On-Chip RAM definition.
+- interrupts : Should be single bit error interrupt, then double bit error
+   interrupt. Note the rising edge type.
+
+Example:
+
+   eccmgr: eccmgr@ffd08140 {
+   compatible = "altr,socfpga-ecc-manager";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   l2-ecc@ffd08140 {
+   compatible = "altr,socfpga-l2-ecc";
+   reg = <0xffd08140 0x4>;
+   interrupts = <0 36 1>, <0 37 1>;
+   };
+
+   ocram-ecc@ffd08144 {
+   compatible = "altr,socfpga-ocram-ecc";
+   reg = <0xffd08144 0x4>;
+   iram = <&ocram>;
+   interrupts = <0 178 1>, <0 179 1>;
+   };
+   };
diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
index 39c470e..14ac766 100644
--- a/arch/arm/boot/dts/socfpga.dtsi
+++ b/arch/arm/boot/dts/socfpga.dtsi
@@ -656,6 +656,26 @@
status = "disabled";
};
 
+   eccmgr: eccmgr@ffd08140 {
+   compatible = "altr,socfpga-ecc-manager";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges;
+
+   l2-ecc@ffd08140 {
+   compatible = "altr,socfpga-l2-ecc";
+   reg = <0xffd08140 0x4>;
+   interrupts = <0 36 1>, <0 37 1>;
+   };
+
+   ocram-ecc@ffd08144 {
+   compatible = "altr,socfpga-ocram-ecc";
+   reg = <0xffd08144 0x4>;
+   iram = <&ocram>;
+   interrupts = <0 178 1>, <0 179 1>;
+   };
+   };
+
L2: l2-cache@fffef000 {
compatible = "arm,pl310-cache";
reg = <0xfffef000 0x1000>;
-- 
1.7.9.5

--
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 V8 20/23] perf tools: making function set_max_cpu_num() non static

[Mathieu Poirier]

On 26 January 2016 at 11:51, Arnaldo Carvalho de Melo  wrote:
> Em Tue, Jan 26, 2016 at 10:08:21AM -0700, Mathieu Poirier escreveu:
>> On 25 January 2016 at 14:29, Arnaldo Carvalho de Melo  
>> wrote:
>> > Em Mon, Jan 25, 2016 at 06:12:42PM -0300, Arnaldo Carvalho de Melo 
>> > escreveu:
>> >> Em Mon, Jan 25, 2016 at 01:46:22PM -0700, Mathieu Poirier escreveu:
>> >> > On 14 January 2016 at 14:46, Mathieu Poirier 
>> >> >  wrote:
>> >> > I can't queue this patch for 4.6 without at least a reviewed by from 
>> >> > you.
>> >>
>> >> This one I remember, looks ugly, the name set_max_cpu_num() looks
>> >> strange, when that was restricted (static) to that cpumap.c file, it
>> >> wasn't a problem, exporting it for wider usage looks bad.
>> >>
>> >> You've been waiting for this for quite a while, it seems, lemme stop
>> >> what I am doing to check this...
>> >
>> > So, please check the patch below, what you need then is just to use
>> > cpu__max_cpu().
>>
>> I like your approach - thanks for the review.  I will spin V9 when I
>> have received Adrian's comments.
>
> I'll take that as an Acked-by: and since this improves the current
> situation by hiding needlessly exported global variables, I'll get it in
> now, thanks.

I would have added this code in my patchset with the right authorship
- whatever works best for you.

Thanks,
Mathieu

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

[PATCHv9 1/4] EDAC, altera: Add Altera L2 Cache and OCRAM EDAC Support

[tthayer]

From: Thor Thayer 

Adding L2 Cache and On-Chip RAM EDAC support for the
Altera SoCs using the EDAC device  model. The SDRAM
controller is using the Memory Controller model.

Each type of ECC is individually configurable.

Signed-off-by: Thor Thayer 
---
v9: Improve device tree node release. Free managed resources
on error path. Fix ocram memory leak.
v8: Remove MASK from single bit mask names.
s/altr,edac/altr,socfpga-ecc-manager
Use debugfs instead of sysfs.
Add chip family name to match string.
Fix header year.
Fix build dependencies & change commit accordingly.
s/CONFIG_EDAC_ALTERA_MC/CONFIG_EDAC_ALTERA
v7: s/of_get_named_gen_pool/of_gen_pool_get
Remove #ifdef for EDAC_DEBUG
Use -ENODEV instead of EPROBE_DEFER
v6: Convert to nested EDAC in device tree. Force L2 cache
on for L2Cache ECC & remove L2 cache syscon for checking
enable bit. Update year in header.
v5: No change.
v4: Change mask defines to use BIT().
Fix comment style to agree with kernel coding style.
Better printk description for read != write in trigger.
Remove SysFS debugging message.
Better dci->mod_name
Move gen_pool pointer assignment to end of function.
Invert logic to reduce indent in ocram depenency check.
Change from dev_err() to edac_printk()
Replace magic numbers with defines & comments.
Improve error injection test.
Change Makefile intermediary name to altr (from alt)
v3: Move OCRAM and L2 cache EDAC functions into altera_edac.c
instead of separate files.
v2: Fix L2 dependency comments.
---
 drivers/edac/Kconfig   |   26 ++-
 drivers/edac/Makefile  |2 +-
 drivers/edac/altera_edac.c |  487 +++-
 3 files changed, 507 insertions(+), 8 deletions(-)

diff --git a/drivers/edac/Kconfig b/drivers/edac/Kconfig
index ef25000..15a6df4 100644
--- a/drivers/edac/Kconfig
+++ b/drivers/edac/Kconfig
@@ -367,14 +367,30 @@ config EDAC_OCTEON_PCI
  Support for error detection and correction on the
  Cavium Octeon family of SOCs.
 
-config EDAC_ALTERA_MC
-   bool "Altera SDRAM Memory Controller EDAC"
+config EDAC_ALTERA
+   bool "Altera SOCFPGA ECC"
depends on EDAC_MM_EDAC=y && ARCH_SOCFPGA
help
  Support for error detection and correction on the
- Altera SDRAM memory controller. Note that the
- preloader must initialize the SDRAM before loading
- the kernel.
+ Altera SOCs. This must be selected for SDRAM ECC.
+ Note that the preloader must initialize the SDRAM
+ before loading the kernel.
+
+config EDAC_ALTERA_L2C
+   bool "Altera L2 Cache ECC"
+   depends on EDAC_ALTERA=y
+   select CACHE_L2X0
+   help
+ Support for error detection and correction on the
+ Altera L2 cache Memory for Altera SoCs. This option
+  requires L2 cache so it will force that selection.
+
+config EDAC_ALTERA_OCRAM
+   bool "Altera On-Chip RAM ECC"
+   depends on EDAC_ALTERA=y && SRAM && GENERIC_ALLOCATOR
+   help
+ Support for error detection and correction on the
+ Altera On-Chip RAM Memory for Altera SoCs.
 
 config EDAC_SYNOPSYS
tristate "Synopsys DDR Memory Controller"
diff --git a/drivers/edac/Makefile b/drivers/edac/Makefile
index be163e2..f9e4a3e 100644
--- a/drivers/edac/Makefile
+++ b/drivers/edac/Makefile
@@ -67,6 +67,6 @@ obj-$(CONFIG_EDAC_OCTEON_L2C) += octeon_edac-l2c.o
 obj-$(CONFIG_EDAC_OCTEON_LMC)  += octeon_edac-lmc.o
 obj-$(CONFIG_EDAC_OCTEON_PCI)  += octeon_edac-pci.o
 
-obj-$(CONFIG_EDAC_ALTERA_MC)   += altera_edac.o
+obj-$(CONFIG_EDAC_ALTERA)  += altera_edac.o
 obj-$(CONFIG_EDAC_SYNOPSYS)+= synopsys_edac.o
 obj-$(CONFIG_EDAC_XGENE)   += xgene_edac.o
diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
index 9296409..07c13a7 100644
--- a/drivers/edac/altera_edac.c
+++ b/drivers/edac/altera_edac.c
@@ -1,5 +1,5 @@
 /*
- *  Copyright Altera Corporation (C) 2014-2015. All rights reserved.
+ *  Copyright Altera Corporation (C) 2014-2016. All rights reserved.
  *  Copyright 2011-2012 Calxeda, Inc.
  *
  * This program is free software; you can redistribute it and/or modify it
@@ -17,8 +17,10 @@
  * Adapted from the highbank_mc_edac driver.
  */
 
+#include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -34,6 +36,7 @@
 
 #define EDAC_MOD_STR   "altera_edac"
 #define EDAC_VERSION   "1"
+#define EDAC_DEVICE"Altera"
 
 static const struct altr_sdram_prv_data c5_data = {
.ecc_ctrl_offset= CV_CTLCFG_OFST,
@@ -75,6 +78,31 @@ static const struct altr_sdram_prv_data a10_data = {
.ue_set_mask= A10_DIAGINT_TDERRA_MASK,
 };
 
+/** EDAC Device Defines **/
+
+/* OCRAM ECC Management Group Defines */
+#define ALTR_MAN_GRP_OCRAM_ECC_OFFSET   0x04
+#define ALTR_OCR

[PATCHv9 4/4] ARM: socfpga: Enable OCRAM ECC on startup

[tthayer]

From: Thor Thayer 

This patch enables the ECC for On-Chip RAM on machine startup. The ECC
has to be enabled before data is stored in memory otherwise the ECC will
fail on reads.

Signed-off-by: Thor Thayer 
---
v9: Improve node release handling.
v8: Address community comments on strings. Fix match strings based
on maintainer feedback. Update year in header.
v7: enable OCRAM ECC during platform init
v6: Implement OCRAM discovery changes from community. Add
of_node_put(). Remove be32_to_cpup(). Use __init() which
allows removal of .init_machine(). Update year in header.
---
 arch/arm/mach-socfpga/Makefile  |1 +
 arch/arm/mach-socfpga/core.h|1 +
 arch/arm/mach-socfpga/ocram.c   |   49 +++
 arch/arm/mach-socfpga/socfpga.c |3 +++
 4 files changed, 54 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/ocram.c

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index e9ab7c9..ed15db1 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -6,3 +6,4 @@ obj-y   := socfpga.o
 obj-$(CONFIG_SMP)  += headsmp.o platsmp.o
 obj-$(CONFIG_SOCFPGA_SUSPEND)  += pm.o self-refresh.o
 obj-$(CONFIG_EDAC_ALTERA_L2C)  += l2_cache.o
+obj-$(CONFIG_EDAC_ALTERA_OCRAM)+= ocram.o
diff --git a/arch/arm/mach-socfpga/core.h b/arch/arm/mach-socfpga/core.h
index eb55d66..575195b 100644
--- a/arch/arm/mach-socfpga/core.h
+++ b/arch/arm/mach-socfpga/core.h
@@ -37,6 +37,7 @@
 extern void socfpga_init_clocks(void);
 extern void socfpga_sysmgr_init(void);
 void socfpga_init_l2_ecc(void);
+void socfpga_init_ocram_ecc(void);
 
 extern void __iomem *sys_manager_base_addr;
 extern void __iomem *rst_manager_base_addr;
diff --git a/arch/arm/mach-socfpga/ocram.c b/arch/arm/mach-socfpga/ocram.c
new file mode 100644
index 000..60ec643
--- /dev/null
+++ b/arch/arm/mach-socfpga/ocram.c
@@ -0,0 +1,49 @@
+/*
+ * Copyright Altera Corporation (C) 2016. All rights reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope 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 
+#include 
+
+#define ALTR_OCRAM_CLEAR_ECC  0x0018
+#define ALTR_OCRAM_ECC_EN 0x0019
+
+void socfpga_init_ocram_ecc(void)
+{
+   struct device_node *np;
+   void __iomem *mapped_ocr_edac_addr;
+
+   /* Find the OCRAM EDAC device tree node */
+   np = of_find_compatible_node(NULL, NULL, "altr,socfpga-ocram-ecc");
+   if (!np) {
+   pr_err("Unable to find socfpga-ocram-ecc\n");
+   return;
+   }
+
+   mapped_ocr_edac_addr = of_iomap(np, 0);
+   of_node_put(np);
+   if (!mapped_ocr_edac_addr) {
+   pr_err("Unable to map OCRAM ecc regs.\n");
+   return;
+   }
+
+   /* Clear any pending OCRAM ECC interrupts, then enable ECC */
+   writel(ALTR_OCRAM_CLEAR_ECC, mapped_ocr_edac_addr);
+   writel(ALTR_OCRAM_ECC_EN, mapped_ocr_edac_addr);
+
+   iounmap(mapped_ocr_edac_addr);
+}
diff --git a/arch/arm/mach-socfpga/socfpga.c b/arch/arm/mach-socfpga/socfpga.c
index dd1ff07..7e0aad2 100644
--- a/arch/arm/mach-socfpga/socfpga.c
+++ b/arch/arm/mach-socfpga/socfpga.c
@@ -61,6 +61,9 @@ static void __init socfpga_init_irq(void)
socfpga_sysmgr_init();
if (IS_ENABLED(CONFIG_EDAC_ALTERA_L2C))
socfpga_init_l2_ecc();
+
+   if (IS_ENABLED(CONFIG_EDAC_ALTERA_OCRAM))
+   socfpga_init_ocram_ecc();
 }
 
 static void socfpga_cyclone5_restart(enum reboot_mode mode, const char *cmd)
-- 
1.7.9.5

--
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] pstore-ram: add Device Tree bindings

[Rob Herring]

On Wed, Jan 27, 2016 at 4:44 AM, Markus Pargmann  wrote:
> Hi,
>
> sorry for the late response.
>
> On Thu, Jan 07, 2016 at 03:40:56PM -0800, Greg Hackmann wrote:
>> ramoops is one of the remaining places where ARM vendors still rely on
>> board-specific shims.  Device Tree lets us replace those shims with
>> generic code.
>>
>> These bindings mirror the ramoops module parameters, with two small
>> differences:
>>
>> (1) dump_oops becomes an optional "no-dump-oops" property, since ramoops
>> sets dump_oops=1 by default.
>>
>> (2) mem_type=1 becomes the more self-explanatory "unbuffered" property.
>
> I thought about the same patch at the end of last year but decided
> against this for several reasons.
>
> 1) ramoops is a memory region, not hardware or any hardware description.

Yes, but...

> 2) A suitable location for the ramoops depends on many factors. It is
> not restricted to a specific board. For example the boot ROM of a SoC
> may work differently for different boot mechanisms (usb, nand, SD-Card,
> ...) and may by accident overwrite the ramoops area given in the
> devicetree.

How RAM is used is a hardware constraint especially when the bootROM
can't be changed.

> 3) Different bootloaders use the available memory differently which may
> conflict with the definition in the devicetree and some data is placed
> in memory before the devicetree is even accessible, for example if we
> are running in sram before switching to a bootloader running in sdram.

Then the bootloader would need to update the default location.

> These were the reasons why I decided to implement ramoops support in
> the bootloader instead. The bootloader is the component that has
> knowledge about used memory and it can inform other system components
> (kernel) about the ramoops area. This way the ramoops area can be set
> where it is not overwritten by any other component.

That is fine. I could imagine wanting to read the ramoops in the
bootloader as well.

Your questioning is really about when you configure ramoops, not how.
I assume the how in your case is using the kernel command line.
Putting ramoops in DT is just the how it is communicated to the
kernel, not the when. The bootloader could just as easily setup the
ramoops node in DT rather than statically defining it in the dts. We
already have various properties that can be passed either way
(console, memory, CMA size, etc.) and are frequently setup by the
bootloader.

Also, the kernel command line should override whatever is in DT, so
your use would still work even if the DT had ramoops entry.

Rob
--
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 V8 18/23] coresight: etm-perf: new PMU driver for ETM tracers

[Mathieu Poirier]

On 26 January 2016 at 08:27, Alexander Shishkin
 wrote:
> Mathieu Poirier  writes:
>
>> +static int etm_event_init(struct perf_event *event)
>> +{
>> + if (event->attr.type != etm_pmu.type)
>> + return -ENOENT;
>> +
>> + if (event->cpu >= nr_cpu_ids)
>> + return -EINVAL;
>
> perf_event_alloc() already does this. Except for this one doesn't cover
> the negative space.

Ack

>
> [snip]
>
>> +static void etm_free_aux(void *data)
>> +{
>> + struct etm_event_data *event_data = data;
>> +
>> + pr_err("Queing work\n");
>
> Probably not pr_err().

That's an old debug message - I've removed it already.

>
>> + schedule_work(&event_data->work);
>> +}
>
> [snip]
>
>> +static void etm_event_start(struct perf_event *event, int flags)
>> +{
>> + int cpu = smp_processor_id();
>> + struct etm_event_data *event_data;
>> + struct perf_output_handle *handle = this_cpu_ptr(&ctx_handle);
>> + struct coresight_device *sink, *csdev = per_cpu(csdev_src, cpu);
>> +
>> + if (!csdev)
>> + goto fail;
>> +
>> + /*
>> +  * Deal with the ring buffer API and get a handle on the
>> +  * session's information.
>> +  */
>> + event_data = perf_aux_output_begin(handle, event);
>> + if (WARN_ON_ONCE(!event_data))
>> + goto fail;
>
> There really shouldn't be a warning here. I understand that the 'no
> buffer' case is taped over by the !csdev check above, but there are
> other ligitimate reasons for perf_aux_output_begin() to return NULL,
> like no-space-left.

That's too harsh yes.

>
>> +
>> + /* We need a sink, no need to continue without one */
>> + sink = coresight_get_sink(event_data->path[cpu]);
>> + if (!sink || !sink_ops(sink)->set_buffer)
>> + goto fail_end_stop;
>
> Is this possible after the coresight_build_path() things in setup_aux?
> Might be a better candidate for WARN_*ONCE().
>
>> +
>> + /* Configure the sink */
>> + if (sink_ops(sink)->set_buffer(sink, handle,
>> +event_data->snk_config))
>> + goto fail_end_stop;
>> +
>> + /* Nothing will happen without a path */
>> + if (coresight_enable_path(event_data->path[cpu], CS_MODE_PERF))
>> + goto fail_end_stop;
>
> I'd like to understand all the potential failures here, because it's
> really a good idea to keep those to a minimum for the sake of
> consistency. That is, if the user succeeded in creating an event, about
> the only good reason for the event not starting is a filled up buffer.

Enabling a path should fail when one or many components of that path
are already enabled by an ongoing trace session.  This situation is
quite likely to happen since in a lot of design tracers share the link
and sinks.

>
> This is why it makes a lot of sense to keep all the
> coresight_build_path()/coresight_enable_path() to the .event_init()
> phase and let them fail early, if they should fail.

If we do enable enable paths in .event_init() we can't support
multiple concurrent trace session (see explanation above).  The
ultimate design is to have a source directly connected to a sink but
so far none of the coresight topologies I've seen have been wired like
that.

>
> Regards,
> --
> Alex
--
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 v15 5/6] fpga: fpga-area and fpga-bus: device tree control for FPGA

[atull]

On Mon, 25 Jan 2016, Rob Herring wrote:

> On Fri, Jan 22, 2016 at 6:07 PM, Moritz Fischer
>  wrote:
> > On Fri, Jan 22, 2016 at 5:37 PM, atull  wrote:
> >> On Fri, 22 Jan 2016, Moritz Fischer wrote:
> >>
> >>> Alan,
> >>>
> >>> On Wed, Jan 20, 2016 at 8:24 PM,   wrote:
> >>>
> >>> > +static int fpga_area_probe(struct platform_device *pdev)
> >>> > +{
> >>> > +   struct device *dev = &pdev->dev;
> >>> > +   struct device_node *np = dev->of_node;
> >>> > +   struct fpga_area *area;
> >>> > +   int ret;
> >>> > +
> >>> > +   area = devm_kzalloc(dev, sizeof(*area), GFP_KERNEL);
> >>> > +   if (!area)
> >>> > +   return -ENOMEM;
> >>> > +
> >>> > +   INIT_LIST_HEAD(&area->bridge_list);
> >>> > +
> >>> > +   ret = fpga_bridge_register(dev, "FPGA Area", NULL, area);
> >>> > +   if (ret)
> >>> > +   return ret;
> >>> > +   area->br = dev_get_drvdata(dev);
> >>> > +
> >>> > +   if (of_property_read_string(np, "firmware-name",
> >>> > +   &area->firmware_name)) {
> >>> > +   of_platform_populate(np, of_default_bus_match_table, 
> >>> > NULL, dev);
> >>> > +   return 0;
> >>> > +   }
> >>>
> >>> This is the use case where the bootloader loaded the fpga, and you
> >>> just want to populate
> >>> the devices in the fabric, right?
> >>
> >> Hi Moritz,
> >>
> >> Yes
> 
> That is very strange logic. It should be fine to just call
> of_platform_populate unconditionally. If there are no children of np,
> then it will be a nop.

That's what it is doing.  It's coded this way to reduce indentation.  If there
is no FPGA image to load, call of_platform_populate() and return.  Otherwise do
a bunch of steps to load the FPGA image and handle the bridges, then call
of_platform_populate() and return.  If there's no children, no problem.

> 
> >>> > +   if (of_property_read_bool(np, "partial-reconfig"))
> >>> > +   area->flags |= FPGA_MGR_PARTIAL_RECONFIG;
> >>> > +
> >>> > +   ret = fpga_area_get_bus(area);
> >>> > +   if (ret) {
> >>> > +   dev_dbg(dev, "Should be child of a FPGA Bus");
> >>> > +   goto err_unreg;
> >>> > +   }
> >>>
> >>> Looking at socfpga.dtsi, would that mean that the fpgamgr0 node would
> >>> need to become a subnode of fpgabus@0 at the same place?
> >>>
> >>> i.e. /soc/fpgamgr@ff706000 -> /soc/fpgabus@0/fpgamgr@ff706000
> >>>
> >>> and the ranges property would be used to translate to the fpga memory
> >>> mapped space?
> >>>
> >>> I know we're going back and forth on this. I think Rob brought up a
> >>> similar question:
> >>> "Does the bus really go thru the fpgamgr and then the bridge as this
> >>> implies? Or fpgamgr is a sideband controller?"
> >>>
> >>> To which I think the answer is 'sideband' controller, yet with the new
> >>> bindings it looks like
> >>> the bus goes through the fpgamgr.
> >>
> >> Yeah, let's get this right.  First, let's be clear on the reason for FPGA 
> >> Bus to
> >> exist.  There may be >1 FPGA in a system.  I want the FPGA Bus bring 
> >> together
> >> the bridges and manager that are associated with a certain FPGA.  This 
> >> allows
> >> the system designer to specify which FPGA is getting programmed with which
> >> image/hardware.  So at minimum, we need some way of associating a FPGA Bus 
> >> with
> >> a FPGA Manager.
> >
> > I see your argument for the FPGA bus. I agree that we need to
> > distinguish different FPGAs,
> > and we need a way to associate an area with a manager (and potentially 
> > bridges).
> >
> >> As far as the target path is concerned, in the case of no bridges, we 
> >> could have
> >> the overlay target the FPGA Bus instead of the FPGA Manager.  That may be 
> >> more
> >> logical.  This would just be a documentation change; I think fpga-area.c 
> >> will
> >> work OK if you specify the FPGA bus as your target (the manager still has 
> >> to
> >> be a child of the bus so the bus knows what manager to use).
> >
> > Could the bus not just use a phandle to the manager? Or the area a
> > phandle to the bus?
> 
> That may be better as it would avoid the virtual fpga-bus which is a
> bit questionable. I'm okay with allowing it, but will happily take any
> examples where it doesn't work. However, I'm not sure this case is
> one.

I have no problem with specifying FPGA manager with a phandle, seems
like it will be better in some cases.

I'm proposing FPGA Bus to specify all the things (manager and bridges) that are
needed to do a reprogramming cycle on a specific FPGA. The FPGA Bus may seem
less necessary in Moritz' case where there are no FPGA Bridges in the DT.

I'll discuss this more on the other thread.

> 
> > Like that one could have potentially disjunct groups. Say I have a SPI
> > device that is in an FPGA area.
> > With our current system, I'd have a FPGA Manager that needs to be a
> > child of the bus as child of the SPI controller
> > with the memory addresses being addre

Re: [PATCH v15 1/6] fpga: add bindings document for fpga area and fpga bus

[atull]

On Mon, 25 Jan 2016, Rob Herring wrote:

> On Wed, Jan 20, 2016 at 01:24:22PM -0600, at...@opensource.altera.com wrote:
> > From: Alan Tull 
> > 
> > New bindings document for FPGA Area for reprogramming
> > FPGA's under Device Tree control
> > 
> > Signed-off-by: Alan Tull 
> > ---
> > v9:  initial version added to this patchset
> > v10: s/fpga/FPGA/g
> >  replace DT overlay example with slightly more complicated example
> >  move to staging/simple-fpga-bus
> > v11: No change in this patch for v11 of the patch set
> > v12: Moved out of staging.
> >  Changed to use FPGA bridges framework instead of resets
> >  for bridges.
> > v13: bridge@0xff2 -> bridge@ff20, etc
> >  Leave out directly talking about overlays
> >  Remove regs and clocks directly under simple-fpga-bus in example
> >  Use common "firmware-name" binding instead of "fpga-firmware"
> > v14: Use firmware-name in bindings description
> >  Call it FPGA Area
> >  Remove bindings that specify FPGA Manager and FPGA Bridges
> > v15: Cleanup as per Rob's comments
> >  Combine usage doc with bindings document
> >  Document as being Altera specific
> >  Additions and changes to add FPGA Bus
> > ---
> >  .../bindings/fpga/altera-fpga-bus-fpga-area.txt|  452 
> > 
> >  1 file changed, 452 insertions(+)
> >  create mode 100644 
> > Documentation/devicetree/bindings/fpga/altera-fpga-bus-fpga-area.txt
> > 
> > diff --git 
> > a/Documentation/devicetree/bindings/fpga/altera-fpga-bus-fpga-area.txt 
> > b/Documentation/devicetree/bindings/fpga/altera-fpga-bus-fpga-area.txt
> > new file mode 100644
> > index 000..8ea38ca
> > --- /dev/null
> > +++ b/Documentation/devicetree/bindings/fpga/altera-fpga-bus-fpga-area.txt
> > @@ -0,0 +1,452 @@
> > +Altera FPGA Area and FPGA Bus Device Tree Binding
> 
> Getting closer I think...

Great!

> 
> > +
> > +Alan Tull 2016
> > +
> > + CONTENTS
> > + - Introduction
> > + - Terminology
> > + - Overview
> > + - Constraints
> > + - FPGA Bus
> > + - FPGA Area
> > + - Supported Use Models
> > + - Sequence
> > + - Device Tree Examples
> > +
> > +
> > +Introduction
> > +
> > +
> > +FPGA Buses and FPGA Areas are introduced as a way to solve the problem of 
> > how to
> > +reprogram an Altera FPGA under an operating system and have the new 
> > hardware
> > +show up in the device tree.  By adding these bindings to the Device Tree, a
> > +system can have the information needed to do the FPGA programming to add 
> > the
> > +desired hardware, and also the information about the devices to be added 
> > to the
> > +Device Tree once the programming has succeeded.
> > +
> > +
> > +Terminology
> > +===
> > +
> > +Full Reconfiguration
> > + * The entire FPGA is programmed.
> > +
> > +Partial Reconfiguration (PR)
> > + * The FPGA is broken up into regions.  One of these regions is 
> > reprogrammed
> > +   while the rest of the FPGA is not affected.  Not all FPGA's support 
> > this.
> > +
> > +FPGA Manager & FPGA Manager Framework
> > + * An FPGA Manager is a hardware block that programs an FPGA under the 
> > control
> > +   of a host processor.
> > + * The FPGA Manager Framework provides drivers and functions to program an
> > +   FPGA.
> > +
> > +FPGA Bridge & FPGA Bridge Framework
> > + * Provides drivers and functions to control bridges that enable/disable
> > +   data to the FPGA.
> > + * FPGA Bridges should be disabled while the FPGA is being programmed to
> > +   prevent spurious data on the bus.
> > + * FPGA Bridges may not be needed in implementations where the FPGA Manager
> > +   handles this.
> > +
> > +Freeze Blocks
> > + * Freeze Blocks function as FPGA Bridges within the FPGA fabric.  In the 
> > case
> > +   of PR, the buses from the processor are split within the FPGA.  Each PR
> > +   region gets its own split of the buses, protected by an independently
> > +   controlled Freeze Block.  Several busses may be connected to a single
> > +   PR region; a Freeze Block controls the traffic of all these busses
> > +   together.
> > +
> > +Controlling Bridge
> > + * The processor and FPGA may be connected by multiple FPGA Bridges.  In a 
> > text
> > +   based hierarchy, it is difficult to show this properly as a device would
> > +   have several parents.
> > + * The bridge that handles register access to the FPGA is designated the
> > +   "controlling" bridge.
> > + * The controlling bridge will be the target point under which the overlay 
> > is
> > +   inserted.
> > +
> > +
> > +Overview
> > +
> > +
> > +This binding introduces the FPGA Bus and FPGA Area.
> > +
> > +An FPGA Bus is a virtualized bus that contains the devices needed to be 
> > able to
> > +program an FPGA device.  It contains a child FPGA Manager and may contain 
> > child
> > +FPGA Bridges, if needed.  The FPGA Manager is the hardware block that 
> > handles
> > +programming the FPGA.  FPGA Bridges function to prevent spurious data from 
> > the
> > +FPG

Re: [PATCH V8 16/23] coresight: etb10: implementing AUX API

[Mathieu Poirier]

On 26 January 2016 at 08:53, Alexander Shishkin
 wrote:
> Mathieu Poirier  writes:
>
>> Adding an ETB10 specific AUX area operations to be used
>> by the perf framework when events are initialised.
>>
>> Part of this operation involves modeling the mmap'ed area
>> based on the specific ways a sink buffer gathers information.
>
> I don't mind being CC'd on the rest of the patches too, btw. :)

Most definitely.

>
>> +static unsigned long etb_reset_buffer(struct coresight_device *csdev,
>> +   struct perf_output_handle *handle,
>> +   void *sink_config, bool *lost)
>> +{
>> + unsigned long size = 0;
>> + struct cs_buffers *buf = sink_config;
>> +
>> + if (buf) {
>> + /*
>> +  * In snapshot mode ->data_size holds the new address of the
>> +  * ring buffer's head.  The size itself is the whole address
>> +  * range since we want the latest information.
>> +  */
>> + if (buf->snapshot)
>> + handle->head = local_xchg(&buf->data_size,
>> +   buf->nr_pages << PAGE_SHIFT);
>> +
>> + /*
>> +  * Tell the tracer PMU how much we got in this run and if
>> +  * something went wrong along the way.  Nobody else can use
>> +  * this cs_buffers instance until we are done.  As such
>> +  * resetting parameters here and squaring off with the ring
>> +  * buffer API in the tracer PMU is fine.
>> +  */
>> + *lost = local_xchg(&buf->lost, 0);
>
> This is a thin ice, you can't really make assumptions about bool's
> storage size or even type, afaict.

You are theoretically correct but I wonder if the value of &buf->lost
can get to a size where it won't fit in *lost... Nevertheless I'll fix
it with:

*lost = !!local_xchg(&buf->lost, 0);

>
>> + size = local_xchg(&buf->data_size, 0);
>> + }
>> +
>> + return size;
>> +}
>> +
>> +static void etb_update_buffer(struct coresight_device *csdev,
>> +   struct perf_output_handle *handle,
>> +   void *sink_config)
>> +{
>> + int i, cur;
>> + u8 *buf_ptr;
>> + u32 read_ptr, write_ptr, capacity;
>> + u32 status, read_data, to_read;
>> + unsigned long flags, offset;
>> + struct cs_buffers *buf = sink_config;
>> + struct etb_drvdata *drvdata = dev_get_drvdata(csdev->dev.parent);
>> +
>> + if (!buf)
>> + return;
>> +
>> + capacity = drvdata->buffer_depth * ETB_FRAME_SIZE_WORDS;
>> +
>> + spin_lock_irqsave(&drvdata->spinlock, flags);
>
> This spinlock seems to be held over the entire readout operation,
> however, I can't find clear rules wrt what structures etc are serialized
> on it. Instead, the comment says "only one at a time pls". Same for
> etm's big drvdata spinlock.

That spinlock is there to serialise actions coming from sysFS.  I
originally added the spinlock to 'etb_update_buffer()' to guard
against reading the internal RAM buffer from sysfs while a perf
session is active.  But after supplementing 'etb_dump()' with 'mode'
awareness this spinlock it is no longer required.

>
> Regards,
> --
> Alex
--
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] Documentation: cgroup: Fix 'cgroup-legacy' -> 'cgroup-v1'

[W. Trevor King]

This should have happened in 6255c46f (cgroup: rename cgroup
documentations, 2016-01-11).

Signed-off-by: W. Trevor King 
---
 Documentation/cgroup-v2.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/cgroup-v2.txt b/Documentation/cgroup-v2.txt
index 65b3eac..9ae148a 100644
--- a/Documentation/cgroup-v2.txt
+++ b/Documentation/cgroup-v2.txt
@@ -7,7 +7,7 @@ This is the authoritative documentation on the design, 
interface and
 conventions of cgroup v2.  It describes all userland-visible aspects
 of cgroup including core and specific controller behaviors.  All
 future changes must be reflected in this document.  Documentation for
-v1 is available under Documentation/cgroup-legacy/.
+v1 is available under Documentation/cgroup-v1/.
 
 CONTENTS
 
-- 
2.1.0.60.g85f0837

--
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 v15 1/6] fpga: add bindings document for fpga area and fpga bus

[Moritz Fischer]

Hi,

On Wed, Jan 27, 2016 at 9:24 PM, atull  wrote:

>> I think I said this before, but you should not need simple-bus. Having
>> it is wrong if the bus requires some configuration before enumerating
>> the child nodes. The way you have it, the bridge driver could probe
>> before the FPGA manager or vice-versa. I'm guessing one way will work
>> and the other will not, and you are getting lucky. You should also test
>> will the overlay applied before boot (i.e. single dtb with all areas
>> populated). The simple rule is does the node (containing simple-bus)
>> require configuration for child nodes to be accessed? If yes, you can't
>> use simple-bus.
>
> Yes you did say that before.  Thanks for the explanation here, it
> clarifies a lot.  I'll work on something that implements this without
> relying on luck and simple-busses.
>
>>
>> Part of your problem is you may need a custom match table. Using
>> of_default_bus_match_table will only match the immediate child nodes of
>> the starting node. Alternatively, you need to make the bridge node the
>> starting node.
>>
>
> Not sure what you ment here, maybe you mean leaving out the fpga-bus?
> I'm using fpga-bus to bring the specific manager and bridges together
> needed to handle reprogramming cycles on a specific FPGA.

While I see the grouping argument I don't see binding wise why the manager
needs to move into the bus. If each area specifies the bridges by handle,
would that make more sense?

> I can see reasons for having the fpga manager and also the bridges
> specified by phandle within a fpga-bus.  So an fpga-bus will add the
> following propertities:
>
> fpga-mgr = ;
> fpga-bridges = , ;
>
>>
>> > +   compatible = "altr,socfpga-fpga-mgr";
>> > +   reg = <0xff706000 0x1000
>> > +  0xffb9 0x1000>;
>> > +   interrupts = <0 175 4>;
>> > +   };
>> > +
>> > +   bridge@0 {
>>
>> Same here. Doesn't this bridge have some associated address range.
>>
>> Essentially, the hierarchy from child devices up to the root should
>> reflect the address decoding at each step.
>
> Yes
>
>>
>> > +   compatible = "altr,socfpga-lwhps2fpga-bridge",
>> > +"simple-bus";
>> > +   resets = <&rst LWHPS2FPGA_RESET>;
>> > +   reset-names = "lwhps2fpga";
>> > +   clocks = <&l4_main_clk>;
>> > +   #address-cells = <0x1>;
>> > +   #size-cells = <0x1>;
>> > +   ranges;
>> > +   };
>> > +
>> > +   bridge@1 {
>> > +   compatible = "altr,socfpga-hps2fpga-bridge";
>> > +   resets = <&rst HPS2FPGA_RESET>;
>> > +   reset-names = "hps2fpga";
>> > +   clocks = <&l4_main_clk>;
>> > +   };
>> > +   };
>> > +

>> How do you not have a bridge? There has to be something preventing
>> access. Do you really mean the bridge and fpga-mgr blocks are combined
>> into 1?
>
> In the Xilinx case, the manager and bridge are still two hardware
> blocks but handled together by the manager driver.  I didn't want to
> make Moritz write a FPGA Bridge when he already had code that handled
> his hardware bridges when he told his manager to do a write cycle.

If we all feel that as a good abstraction bridges are necessary, I can add that.
They're basically level shifters that you turn on and off, there's nothing smart
beyond that. If you disable the bridge and try to access stuff it just
doesn't work.

> This could be called fpga-area or fpga-region.  More on that below.


>> Are the number of areas software configurable? If not, then the areas
>> should be part of the base DT rather than the overlay.
>
> The number of areas is set by the FPGA image that creates the areas.
> A base FPGA image could be loaded by the bootloader or by the OS with
> a set number of area slots available.

Not a big fan of this idea. See below. Somehow the info needs. That
seems like an unnatural abstraction for an FPGA. See below:
>
> So this could be done differently, divided into something where the
> areas (some call them "regions") are created in the live DT when the
> base FPGA image is loaded.  Then the overlays would have something
> called 'personas' that plug into them.  The areas would contain the
> information of which bridges to control and which fpga manager.  Maybe
> this heirarchy (indexes are probably screwed up below).
>
> Below, the fpga manager and hardware fpga bridges are specified
> outside the fpga bus and are referred to by phandles.  Leaving out
> ranges, cells for brevity.
>
> Live tree (after base FPGA image is loaded):
> fpga-bus@0 {
> compatible = "fpga-bus";
> fpga-mgr = ;
> fpga-bridges = <..>, <..>;
>
> fpga-area@0 {
> compatible = "fpga-area";
> bridges = ;
> };
>
> fpga-area@... {
>   

[PATCH] documentation: add kernel-dot.emacs.txt

[Geyslan G. Bem]

This patch adds kernel-dot-emacs.txt (elisp) which deliver best
indentation, comments and white space highlighting functionalities.

This also changes the CodingStyle and 00-INDEX files by referencing
the new kernel-dot-emacs.

Signed-off-by: Geyslan G. Bem 
---

Notes:
This patch was done by suggestion of Jonathan Corbet:
http://thread.gmane.org/gmane.linux.documentation/35265/focus=35309

 Documentation/00-INDEX |   2 +
 Documentation/CodingStyle  |  38 +
 Documentation/kernel-dot-emacs.txt | 285 +
 3 files changed, 291 insertions(+), 34 deletions(-)
 create mode 100644 Documentation/kernel-dot-emacs.txt

diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index cd077ca..d4c48f5 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -259,6 +259,8 @@ kernel-doc-nano-HOWTO.txt
- mini HowTo on generation and location of kernel documentation files.
 kernel-docs.txt
- listing of various WWW + books that document kernel internals.
+kernel-dot-emacs.txt
+   - emacs dot file for kernel coding style.
 kernel-parameters.txt
- summary listing of command line / boot prompt args for the kernel.
 kernel-per-CPU-kthreads.txt
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
index c06f817..4d64b58 100644
--- a/Documentation/CodingStyle
+++ b/Documentation/CodingStyle
@@ -501,40 +501,10 @@ typing - an infinite number of monkeys typing into GNU 
emacs would never
 make a good program).
 
 So, you can either get rid of GNU emacs, or change it to use saner
-values.  To do the latter, you can stick the following in your .emacs file:
-
-(defun c-lineup-arglist-tabs-only (ignored)
-  "Line up argument lists by tabs, not spaces"
-  (let* ((anchor (c-langelem-pos c-syntactic-element))
- (column (c-langelem-2nd-pos c-syntactic-element))
- (offset (- (1+ column) anchor))
- (steps (floor offset c-basic-offset)))
-(* (max steps 1)
-   c-basic-offset)))
-
-(add-hook 'c-mode-common-hook
-  (lambda ()
-;; Add kernel style
-(c-add-style
- "linux-tabs-only"
- '("linux" (c-offsets-alist
-(arglist-cont-nonempty
- c-lineup-gcc-asm-reg
- c-lineup-arglist-tabs-only))
-
-(add-hook 'c-mode-hook
-  (lambda ()
-(let ((filename (buffer-file-name)))
-  ;; Enable kernel mode for the appropriate files
-  (when (and filename
- (string-match (expand-file-name "~/src/linux-trees")
-   filename))
-(setq indent-tabs-mode t)
-(setq show-trailing-whitespace t)
-(c-set-style "linux-tabs-only")
-
-This will make emacs go better with the kernel coding style for C
-files below ~/src/linux-trees.
+values. To do the latter, you can stick the elisp code from
+Documentation/kernel-dot-emacs.txt in your emacs init file. This will make
+emacs go better with the kernel coding style for C files below
+~/src/linux-trees.
 
 But even if you fail in getting emacs to do sane formatting, not
 everything is lost: use "indent".
diff --git a/Documentation/kernel-dot-emacs.txt 
b/Documentation/kernel-dot-emacs.txt
new file mode 100644
index 000..b6d6816
--- /dev/null
+++ b/Documentation/kernel-dot-emacs.txt
@@ -0,0 +1,285 @@
+;; Kernel dot emacs
+;; Based on the prior elisp from Documentantion/CodingStyle
+;;
+;; January, 2016
+;; Geyslan G. Bem 
+
+;; This elisp does use of emacs functionalities which deliver to the
+;; user indentation, comments and white space highlighting.
+;;
+;; As known tabs are the higher law and the prior elisp code enforces
+;; that law for any lineup indentation.
+;;
+;; However some trees have specific rules about line continuation
+;; indentation. Even scripts/checkpatch.pl suggests the TABS+SPACES (lining up
+;; under the open paren) for lineup the sequential lines.
+;;
+;; In addition to allowing the automatic setup by tree, this elisp can easily
+;; be modified for new configurations. Eg.
+;;
+;; (when (or (string-match (concat source-path "/net") filename)
+;;   (string-match (concat source-path "/drivers/net") 
filename))
+;;   (setup-kernel-style 'extra-bottom-line t nil))
+;;
+;; The above model can be used for a new tree just changing the tree path
+;; and parameters of setup-kernel-style function.
+;;
+;; setup-kernel-style function sets the kernel-comment-style,
+;; kernel-lineup-tabs-only and kernel-lineup-maximum-tabs variables. They
+;; are used by the functions kernel-comment-dwim and kernel-lineup-arglist.
+;;
+;; The kernel-lineup-arglist function detects the maximum tabs allowed to
+;; lineup and if it must use tabs and spaces instead of only tabs.
+;;
+;; There are two cleanups for else and else if braces enabled when
+;; auto-newline is on. These a

Re: [PATCH v9 04/13] task_isolation: add initial support

[Frederic Weisbecker]

On Tue, Jan 19, 2016 at 03:45:04PM -0500, Chris Metcalf wrote:
> On 01/19/2016 10:42 AM, Frederic Weisbecker wrote:
> >>+/*
> >>+ * Isolation requires both nohz and isolcpus support from the scheduler.
> >>+ * We provide a boot flag that enables both for now, and which we can
> >>+ * add other functionality to over time if needed.  Note that just
> >>+ * specifying "nohz_full=... isolcpus=..." does not enable task isolation.
> >>+ */
> >>+static int __init task_isolation_setup(char *str)
> >>+{
> >>+   alloc_bootmem_cpumask_var(&task_isolation_map);
> >>+   if (cpulist_parse(str, task_isolation_map) < 0) {
> >>+   pr_warn("task_isolation: Incorrect cpumask '%s'\n", str);
> >>+   return 1;
> >>+   }
> >>+
> >>+   alloc_bootmem_cpumask_var(&cpu_isolated_map);
> >>+   cpumask_copy(cpu_isolated_map, task_isolation_map);
> >>+
> >>+   alloc_bootmem_cpumask_var(&tick_nohz_full_mask);
> >>+   cpumask_copy(tick_nohz_full_mask, task_isolation_map);
> >>+   tick_nohz_full_running = true;
> >How about calling tick_nohz_full_setup() instead? I'd rather prefer
> >that nohz full implementation details stay in tick-sched.c
> >
> >Also what happens if nohz_full= is given as well as task_isolation= ?
> >Don't we risk a memory leak and maybe breaking the fact that
> >(nohz_full & task_isolation != task_isolation) which is really a requirement?
> 
> Yeah, this is a good point.  I'm not sure what the best way is to make
> this happen.  It's already true that we will leak memory if you
> specify "nohz_full=" more than once on the command line, but it's
> awkward to fix (assuming we want the last value to win) so maybe
> we can just ignore this problem - it's a pretty small amount of memory
> after all.  If so, then making tick_nohz_full_setup() and
> isolated_cpu_setup()
> both non-static and calling them from task_isolation_setup() might
> be the cleanest approach.  What do you think?

I think we can reuse tick_nohz_full_setup() indeed, or some of its internals
and encapsulate that in a function so that isolation.c can initialize nohz full
without fiddling with internal variables.

> 
> You asked what happens if nohz_full= is given as well, which is a very
> good question.  Perhaps the right answer is to have an early_initcall
> that suppresses task isolation on any cores that lost their nohz_full
> or isolcpus status due to later boot command line arguments (and
> generate a console warning, obviously).

I'd rather imagine that the final nohz full cpumask is "nohz_full=" | 
"task_isolation="
That's the easiest way to deal with and both nohz and task isolation can call
a common initializer that takes care of the allocation and add the cpus to the 
mask.

> >>+int task_isolation_set(unsigned int flags)
> >>+{
> >>+   if (cpumask_weight(tsk_cpus_allowed(current)) != 1 ||
> >>+   !task_isolation_possible(smp_processor_id()))
> >>+   return -EINVAL;
> >>+
> >>+   current->task_isolation_flags = flags;
> >>+   return 0;
> >>+}
> >What if we concurrently change the task's affinity? Also it seems that 
> >preemption
> >isn't disabled, so we can also migrate concurrently. I'm surprised you 
> >haven't
> >seen warnings with smp_processor_id().
> >
> >Also we should protect against task's affinity change when 
> >task_isolation_flags
> >is set.
> 
> I talked about this a bit when you raised it for the v8 patch series:
> 
>   http://lkml.kernel.org/r/562fa8fd.8080...@ezchip.com
> 
> I'd be curious to hear your take on the arguments I made there.

Oh ok, I'm going to reply there then :)

> 
> You're absolutely right about the preemption warnings, which I only fixed
> a few days ago.  In this case I use raw_smp_processor_id() since with a
> fixed single-core cpu affinity, we're not going anywhere, so the warning
> from smp_processor_id() would be bogus.  And although technically it is
> still correct (racing with another task resetting the task affinity on this
> one), it is in any case equivalent to having that other task reset the
> affinity
> on return from the prctl(), which I've already claimed isn't an interesting
> use case to try to handle.  But let me know what you think!

Ok it's very much tied to the affinity issue. If we deal with affinity changes
properly I think we can use the raw_ version.

> 
> >>+
> >>+/*
> >>+ * In task isolation mode we try to return to userspace only after
> >>+ * attempting to make sure we won't be interrupted again.  To handle
> >>+ * the periodic scheduler tick, we test to make sure that the tick is
> >>+ * stopped, and if it isn't yet, we request a reschedule so that if
> >>+ * another task needs to run to completion first, it can do so.
> >>+ * Similarly, if any other subsystems require quiescing, we will need
> >>+ * to do that before we return to userspace.
> >>+ */
> >>+bool _task_isolation_ready(void)
> >>+{
> >>+   WARN_ON_ONCE(!irqs_disabled());
> >>+
> >>+   /* If we need to drain the LRU cache, we're not ready. */
> >>+   if (lru_add_drain_needed(smp_processor_i

NEW ARRIVALS, CISCO,CPU's,Memory, LAPTOP AND AVAYA

[Laison Computech Inc]

Dear Sir/Madam,

Clean tested working pulls CPUs and QTYs in stock.

115  X   X5650
65  X   E5410
75  X   X5660
145  X   E5530
100  X   E5645
40  X   X5680
75  X   X5690

Brand new sealed  IP phones and QTYs in stock.

55 x CP-7937G
77 x CP-7942G
54 x CP-7945G
75 x CP-7962G
..
45 x Avaya 9630
65 x Avaya 9641
55 x Avaya 9640

All NIB.

Here is our current stock list.

 SSD drives and 750 gig 2.5" sata drives

We also have
250 x i5 dell
133 x HP
360 x Lenevo
all grade A

Here is the qty in stock for laptops
 
150 x E6500 Dell Latitude E6500 Core 2 Duo 2.80GHz T9600 4GB 160GB DVD+/-RW Win 
7
 60 x E6510 Dell Ltitude E6510. 15.6" Intel Core i5- M520 @ 2.40GHz. 4GB. 320GB 
DVD+/-RW Win 7
30 X 8530P HP EliteBook 8530p 15.4" Laptop 2.53GHz Core 2 Duo T9400, 4GB RAM, 
160GB HDD, Win
100 x  8740W  HP EliteBook 8740w 17" 2.4Ghz Core i5 6GB 250GB Win 7 Pr
45 x 8760W HP EliteBook 8760W 17.3" 2nd Gen Intel Core i7 2.70GHz 8GB 320GB 
Windows 7 Pro
50 x DELL 6520Dell latitude e6520 15.6" i5-2520M 2.5Ghz, 8GB Ram, 500GB HD Win 
7 @ $115
120 x DELL 6420 Laptop Dell Latitude E6420 14" Intel Core i5 2.4Ghz 4GB RAM 
250GB HDD DVD Win 7
150 x T410 Lenovo ThinkPad Laptop T410s 14.1" 2.40GHz Core i5 4GB RAM 160GB Win 
7
180 x 8440P HP EliteBook 8440p 14" M520 Core i5 2.4GHz 4GB 250GB Win 7


Let me know if you're interested. We are very open to offers and willing to 
work with you to make sure that we have a deal.

Thank You
Barbara Johnson
Laison Computech Inc
210 N Scoring Ave,
Rialto California, 92376
Tel: +1-657-232-7047
Fax: +1-347-214-047
--
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] A first shot at asciidoc-based formatted docs

[Alex Elsayed]

Jonathan Corbet  lwn.net> writes:

> 
> So here is a proof-of-concept series showing how a fully asciidoc-based
> toolchain might work.  Lots of hackery here, this isn't meant to be applied
> to anything at this point, but it's a good start.  What this series has is:



> I'm sure there's a thousand details to deal with, and there is the issue of
> the other output formats.  asciidoctor claims to be able to create man
> pages, but I've not tried that yet; neither tool will do PDF.  Maybe we
> could rely on pandoc to do that.  Otherwise, getting to asciidoc to XML is
> straightforward, so it should be possible to use xmlto as is done now.
> 
> It's all in the doc/asciidoc branch of git://git.lwn.net/linux.git if
> anybody wants to mess with it.
> 
> Comments?

On the topic of PDF output, AsciiDoctor has a gem that adds PDF output support:

http://asciidoctor.org/docs/convert-asciidoc-to-pdf/

And the a2x wrapper from the original Asciidoc project can output pdf using
either dblatex or (used in the examples) FOP:

http://www.methods.co.nz/asciidoc/publishing-ebooks-with-asciidoc.html

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