Re: Kernel docs: muddying the waters a bit

[Jani Nikula]

On Fri, 04 Mar 2016, Russel Winder  wrote:
> On Thu, 2016-03-03 at 15:23 -0800, Keith Packard wrote:
>>   1) the python version (asciidoc) appears to have been abandoned in
>>  favor of the ruby version. 
>
> This is I think true, however the Java-based tool chain Asciidoctor is
> I believe the standard bearer for ASCIIdoc these days, albeit called
> ASCIIdoctor.

If we're talking about the same asciidoctor (http://asciidoctor.org/)
it's written in ruby but you can apparently run it in JVM using
JRuby. Calling it Java-based is misleading.

BR,
Jani.


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

Re: Kernel docs: muddying the waters a bit

[Russel Winder]

On Thu, 2016-03-03 at 15:23 -0800, Keith Packard wrote:
> 
[…]
> However, I think asciidoc has two serious problems:
> 
>   1) the python version (asciidoc) appears to have been abandoned in
>  favor of the ruby version. 

This is I think true, however the Java-based tool chain Asciidoctor is
I believe the standard bearer for ASCIIdoc these days, albeit called
ASCIIdoctor.

>   2) It really is just a docbook pre-processor. Native html/latex
> output
>  is poorly supported at best, and exposes only a small subset of
> the
>  full capabilities of the input language.

This is not true. Yes ASCIIDoc started as a DocBook/XML frontend so as
to use a sane :-) markup language rather than XML (XML is a notation
for consenting computers only), but the current ASCIIDoctor toolchain
deals very well in direct HTML and PDF generation, without needing a
DocBook/XML toolchain. 

> As such, we would have to commit to using the ruby version and either
> committing to fixing the native html output backend or continuing to
> use
> the rest of the docbook toolchain.

Or trial the JVM-based ASCIIdoctor which is what the projects I am
involved with chose to use. Perhaps as an example I can give you http:/
/gpars.website (it's a redirector) all the HTML and PDF is generated
from ASCIIDoc source using ASCIIDoctor driven with a Gradle build
system. This is still very much a work in progress (by Jim Northrop,
not me currently), but I like it.

> We could insist on using the python version, of course. I spent a bit
> of
> time hacking that up to add 'real' support for a table-of-contents in
> the native HTML backend and it looks like getting those changes
> upstreamed would be reasonably straightforward. However, we'd end up
> 'owning' the code, and I'm not sure we want to.

If the Python version is really not being maintained, I would suggest
that unless you want to take over the project and be it's maintainer,
you would be better advised to use a different version.

-- 
Russel.=Dr
 Russel Winder  t: +44 20 7585 2200   voip: sip:russel.winder@ekiga.net41 
Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@winder.org.ukLondon SW11 
1EN, UK   w: www.russel.org.uk  skype: russel_winder


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

Re: Kernel docs: muddying the waters a bit

[Mauro Carvalho Chehab]

Em Thu, 03 Mar 2016 15:23:23 -0800
Keith Packard  escreveu:

> Mauro Carvalho Chehab  writes:
> 
> > On my tests, Sphinix seemed too limited to format tables. Asciidoc
> > produced an output that worked better.  
> 
> Yes, asciidoc has much more flexibility in table formatting, including
> the ability to control text layout within cells and full control over
> borders.
> 
> However, I think asciidoc has two serious problems:
> 
>   1) the python version (asciidoc) appears to have been abandoned in
>  favor of the ruby version. 
> 
>   2) It really is just a docbook pre-processor. Native html/latex output
>  is poorly supported at best, and exposes only a small subset of the
>  full capabilities of the input language.
> 
> As such, we would have to commit to using the ruby version and either
> committing to fixing the native html output backend or continuing to use
> the rest of the docbook toolchain.
> 
> We could insist on using the python version, of course. I spent a bit of
> time hacking that up to add 'real' support for a table-of-contents in
> the native HTML backend and it looks like getting those changes
> upstreamed would be reasonably straightforward. However, we'd end up
> 'owning' the code, and I'm not sure we want to.

I'm a way more concerned about using a tool that fulfill our needs
than to look for something that won't use the docbook toolchain or
require to install ruby.

In the case of Docbook, we know it works and we know already its
issues. Please correct me if I'm wrong, but the big problem we
have is not due to the DocBook toolchain, but due to the lack of
features at the kernel-doc script. Also, xmlto is already installed
by the ones that build the kernel docs. So, keeping use it won't
require to install a weird toolchain by hand.

So, to be frank, it doesn't scary me to use either pyhton or
ruby script + docbook.

Of course, having to own the code has a cost that should be evaluated.

If, on the other hand, we decide to use RST, we'll very likely need to
patch it to fulfill our needs in order to add proper table support.
I've no idea how easy/difficult would be to do that, nor if Sphinx
upstream would accept such changes.

So, at the end of the day, we may end by having to carry on our own
version of Sphinx inside our tree, with doesn't sound good, specially
since it is not just a script, but a package with hundreds of
files.

Thanks,
Mauro


pgp9vItgvYAsJ.pgp
Description: Assinatura digital OpenPGP

Re: Kernel docs: muddying the waters a bit

[Keith Packard]

Mauro Carvalho Chehab  writes:

> On my tests, Sphinix seemed too limited to format tables. Asciidoc
> produced an output that worked better.

Yes, asciidoc has much more flexibility in table formatting, including
the ability to control text layout within cells and full control over
borders.

However, I think asciidoc has two serious problems:

  1) the python version (asciidoc) appears to have been abandoned in
 favor of the ruby version. 

  2) It really is just a docbook pre-processor. Native html/latex output
 is poorly supported at best, and exposes only a small subset of the
 full capabilities of the input language.

As such, we would have to commit to using the ruby version and either
committing to fixing the native html output backend or continuing to use
the rest of the docbook toolchain.

We could insist on using the python version, of course. I spent a bit of
time hacking that up to add 'real' support for a table-of-contents in
the native HTML backend and it looks like getting those changes
upstreamed would be reasonably straightforward. However, we'd end up
'owning' the code, and I'm not sure we want to.

-- 
-keith


signature.asc
Description: PGP signature

Re: [PATCH v3] pstore-ram: add Device Tree bindings

[Olof Johansson]

Hi,

On Thu, Jan 7, 2016 at 3:40 PM, 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.
>
> 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. Use a platform device and set the platform data. The parameters can then
>   be set through that platform data. An example of doing that is:
>
>  #include 
> diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
> index 319c3a6..0f2912c 100644
> --- a/fs/pstore/ram.c
> +++ b/fs/pstore/ram.c
> @@ -34,6 +34,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>
>  #define RAMOOPS_KERNMSG_HDR ""
>  #define MIN_MEM_SIZE 4096UL
> @@ -458,15 +460,112 @@ static int ramoops_init_prz(struct device *dev, struct 
> ramoops_context *cxt,
> return 0;
>  }
>
> +static int ramoops_parse_dt_size(struct platform_device *pdev,
> +   const char *propname, unsigned long *val)
> +{
> +   u64 val64;
> +   int ret;
> +
> +   ret = of_property_read_u64(pdev->dev.of_node, propname, );

This seems to hardcode the size to 64-bit. It should probably be
controlled by #size-cells instead?

I actually doubt we'll want ramoops larger than 4GB anytime soon, so
it might make more sense to hardcode to 32, if anything.

> +   if (ret == -EINVAL) {
> +   *val = 0;

Re: [PATCH 2/2] isdn: i4l: move active-isdn drivers to staging

[Greg KH]

On Thu, Mar 03, 2016 at 05:22:22PM -0500, David Miller wrote:
> From: Arnd Bergmann 
> Date: Wed,  2 Mar 2016 20:06:46 +0100
> 
> > The icn, act2000 and pcbit drivers are all for very old hardware,
> > and it is highly unlikely that anyone is actually still using them
> > on modern kernels, if at all.
> > 
> > All three drivers apparently are for hardware that predates PCI
> > being the common connector, as they are ISA-only and active
> > PCI ISDN cards were widely available in the 1990s.
> > 
> > Looking through the git logs, it I cannot find any indication of a
> > patch to any of these drivers that has been tested on real hardware,
> > only cleanups or global API changes.
> > 
> > Signed-off-by: Arnd Bergmann 
> 
> Greg, can you please take these two patches?

will do

--
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 2/2] isdn: i4l: move active-isdn drivers to staging

[David Miller]

From: Arnd Bergmann 
Date: Wed,  2 Mar 2016 20:06:46 +0100

> The icn, act2000 and pcbit drivers are all for very old hardware,
> and it is highly unlikely that anyone is actually still using them
> on modern kernels, if at all.
> 
> All three drivers apparently are for hardware that predates PCI
> being the common connector, as they are ISA-only and active
> PCI ISDN cards were widely available in the 1990s.
> 
> Looking through the git logs, it I cannot find any indication of a
> patch to any of these drivers that has been tested on real hardware,
> only cleanups or global API changes.
> 
> Signed-off-by: Arnd Bergmann 

Greg, can you please take these two patches?

Thanks!

--
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] x86: PAT: Documentation: update overlapping ioremap hack recommendation

[Luis R. Rodriguez]

The current documentation refers to using set_memor_wc() as a
possible hole strategy when you have overlapping ioremap() regions,
that's incorrect as set_memory_*() helpers can only be used on RAM,
not IO memory. This fixes that, and updates the documention to
*strongly* discourage overlapping ioremap() memory uses, but also
documents a possible solution should there really be no other
option.

Signed-off-by: Luis R. Rodriguez 
---
 Documentation/x86/pat.txt | 25 ++---
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/Documentation/x86/pat.txt b/Documentation/x86/pat.txt
index 54944c71b819..8a26b4cdccf6 100644
--- a/Documentation/x86/pat.txt
+++ b/Documentation/x86/pat.txt
@@ -113,18 +113,21 @@ MTRR effects on PAT / non-PAT systems
 -
 
 The following table provides the effects of using write-combining MTRRs when
-using ioremap*() calls on x86 for both non-PAT and PAT systems. Ideally
-mtrr_add() usage will be phased out in favor of arch_phys_wc_add() which will
-be a no-op on PAT enabled systems. The region over which a arch_phys_wc_add()
+using ioremap*() calls on x86 for both non-PAT and PAT systems. As of v4.3
+mtrr_add() has been phased out in favor of arch_phys_wc_add(), these calls are
+a no-op on PAT enabled systems. The region over which an arch_phys_wc_add()
 is made, should already have been ioremapped with WC attributes or PAT entries,
-this can be done by using ioremap_wc() / set_memory_wc().  Devices which
-combine areas of IO memory desired to remain uncacheable with areas where
-write-combining is desirable should consider use of ioremap_uc() followed by
-set_memory_wc() to white-list effective write-combined areas.  Such use is
-nevertheless discouraged as the effective memory type is considered
-implementation defined, yet this strategy can be used as last resort on devices
-with size-constrained regions where otherwise MTRR write-combining would
-otherwise not be effective.
+this can be done by using ioremap_wc(). Devices which combine areas of IO
+memory desired to remain uncacheable with areas where write-combining is
+desirable should consider use of ioremap_wc() followed by an overlapping
+ioremap_uc() "hole". For an example of this strategy refer to commit 3cc2dac5be
+("drivers/video/fbdev/atyfb: Replace MTRR UC hole with strong UC").
+Such use is nevertheless heavily discouraged as the effective memory type is
+considered implementation defined. This strategy should only be used used as a
+last resort measure.
+
+Note you cannot use set_memory_*() helpers on ioremap'd regions, even though
+its use currently gives no hint of an error.
 
 --
 MTRR Non-PAT   PATLinux ioremap valueEffective memory type
-- 
2.7.2

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

Re: [PATCH v10 05/12] task_isolation: support CONFIG_TASK_ISOLATION_ALL

[Andi Kleen]

> The same arguments would seem to apply to TASK_ISOLATION_ALL;
> note that applications don't actually go into task isolation mode
> without issuing the appropriate prctl(), so it shouldn't be too

That's a fair point. If it's entirely opt-in it's probably ok.

-Andi
--
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 v10 05/12] task_isolation: support CONFIG_TASK_ISOLATION_ALL

[Chris Metcalf]

On 03/03/2016 01:34 PM, Andi Kleen wrote:

Chris Metcalf  writes:
  
+config TASK_ISOLATION_ALL

+   bool "Provide task isolation on all CPUs by default (except CPU 0)"
+   depends on TASK_ISOLATION
+   help
+If the user doesn't pass the task_isolation boot option to
+define the range of task isolation CPUs, consider that all
+CPUs in the system are task isolation by default.
+Note the boot CPU will still be kept outside the range to
+handle timekeeping duty, etc.

That seems like a very dangerous Kconfig option.
"CONFIG_BREAK_EVERYTHING"
If someone sets that by default they will have a lot of trouble.

I wouldn't add that, make it a run time option only.


So you were thinking, allow a special boot syntax "task_isolation=all",
which puts all the cores into task isolation mode except the boot core?

My original argument was that it was so parallel to the existing
CONFIG_NO_HZ_FULL_ALL option that it just made sense to do it,
and some testers complained about having to specify the precise
cpu range, so this seemed like an easy fix.

The commit comment for NO_HZ_FULL_ALL (f98823ac758ba) reads:

nohz: New option to default all CPUs in full dynticks range
   
Provide a new kernel config that defaults all CPUs to be part

of the full dynticks range, except the boot one for timekeeping.
   
This default setting is overriden by the nohz_full= boot option

if passed by the user.
   
This is helpful for those who don't need a finegrained range

of full dynticks CPU and also for automated testing.

The same arguments would seem to apply to TASK_ISOLATION_ALL;
note that applications don't actually go into task isolation mode
without issuing the appropriate prctl(), so it shouldn't be too
dangerous if users enable it by mistake.  There will be some
extra checks at kernel entry and exit, that's all.

So on balance it still seems like a reasonable choice.  Thoughts?

--
Chris Metcalf, Mellanox Technologies
http://www.mellanox.com

--
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 5/7] ACPI: serial: implement earlycon on ACPI DBG2 port

[Peter Hurley]

On 03/01/2016 08:57 AM, Aleksey Makarov wrote:
> 
> 
> On 03/01/2016 06:53 PM, Peter Hurley wrote:
>> On 02/29/2016 04:42 AM, Aleksey Makarov wrote:
>>> Add ACPI_DBG2_EARLYCON_DECLARE() macros that declares
>>> an earlycon on the serial port specified in the DBG2 ACPI table.
>>>
>>> Pass the string "earlycon=acpi_dbg2" to the kernel to activate it.
>>>
>>> Callbacks for EARLYCON_DECLARE() and OF_EARLYCON_DECLARE()
>>> can also be used for this macros.
>>>
>>> Signed-off-by: Aleksey Makarov 
>>> ---
>>>  Documentation/kernel-parameters.txt |  3 ++
>>>  drivers/tty/serial/earlycon.c   | 60 
>>> +
>>>  include/linux/acpi_dbg2.h   | 20 +
>>>  3 files changed, 83 insertions(+)
>>>
>>> diff --git a/Documentation/kernel-parameters.txt 
>>> b/Documentation/kernel-parameters.txt
>>> index e0a21e4..19b947b 100644
>>> --- a/Documentation/kernel-parameters.txt
>>> +++ b/Documentation/kernel-parameters.txt
>>> @@ -1072,6 +1072,9 @@ bytes respectively. Such letter suffixes can also be 
>>> entirely omitted.
>>> A valid base address must be provided, and the serial
>>> port must already be setup and configured.
>>>  
>>> +   acpi_dbg2
>>> +   Use serial port specified by the DBG2 ACPI table.
>>> +
>>> earlyprintk=[X86,SH,BLACKFIN,ARM,M68k]
>>> earlyprintk=vga
>>> earlyprintk=efi
>>> diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
>>> index d217366..9ba3a04 100644
>>> --- a/drivers/tty/serial/earlycon.c
>>> +++ b/drivers/tty/serial/earlycon.c
>>> @@ -22,6 +22,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>  
>>>  #ifdef CONFIG_FIX_EARLYCON_MEM
>>>  #include 
>>> @@ -200,6 +201,8 @@ int __init setup_earlycon(char *buf)
>>> return -ENOENT;
>>>  }
>>>  
>>> +static bool setup_dbg2_earlycon;
>>> +
>>>  /* early_param wrapper for setup_earlycon() */
>>>  static int __init param_setup_earlycon(char *buf)
>>>  {
>>> @@ -212,6 +215,11 @@ static int __init param_setup_earlycon(char *buf)
>>> if (!buf || !buf[0])
>>> return early_init_dt_scan_chosen_serial();
>>>  
>>> +   if (!strcmp(buf, "acpi_dbg2")) {
>>> +   setup_dbg2_earlycon = true;
>>> +   return 0;
>>> +   }
>>
>> So this series doesn't start an ACPI earlycon at early_param time?
>> That doesn't seem very useful.
>>
>> When does the ACPI earlycon actually start?
>> And don't say "when the DBG2 table is probed"; that much is obvious.
> 
> ACPI earlycon starts as soon as ACPI tables become accessible (setup_arch()).
> I think that is still quite early.

I see now; the probe is in patch 6/7.

setup_arch()
  acpi_boot_table_init()
acpi_probe_device_table()
  ...
acpi_dbg2_setup()
  ->setup()
acpi_setup_earlycon()


>>> +
>>> err = setup_earlycon(buf);
>>> if (err == -ENOENT || err == -EALREADY)
>>> return 0;
>>> @@ -286,3 +294,55 @@ int __init of_setup_earlycon(const struct earlycon_id 
>>> *match,
>>>  }
>>>  
>>>  #endif /* CONFIG_OF_EARLY_FLATTREE */
>>> +
>>> +#ifdef CONFIG_ACPI_DBG2_TABLE
>>> +
>>> +int __init acpi_setup_earlycon(struct acpi_dbg2_device *device, void *d)
>>> +{
>>> +   int err;
>>> +   struct uart_port *port = _console_dev.port;
>>> +   int (*setup)(struct earlycon_device *, const char *) = d;
>>> +   struct acpi_generic_address *reg;
>>> +
>>> +   if (!setup_dbg2_earlycon)
>>> +   return -ENODEV;
>>> +
>>> +   if (device->register_count < 1)
>>> +   return -ENODEV;
>>> +
>>> +   if (device->base_address_offset >= device->length)
>>> +   return -EINVAL;
>>> +
>>> +   reg = (void *)device + device->base_address_offset;
>>> +
>>> +   if (reg->space_id != ACPI_ADR_SPACE_SYSTEM_MEMORY &&
>>> +   reg->space_id != ACPI_ADR_SPACE_SYSTEM_IO)
>>> +   return -EINVAL;
>>> +
>>> +   spin_lock_init(>lock);
>>> +   port->uartclk = BASE_BAUD * 16;
>>> +
>>> +   if (reg->space_id == ACPI_ADR_SPACE_SYSTEM_MEMORY) {
>>> +   if (device->port_type == ACPI_DBG2_ARM_SBSA_32BIT)
>>> +   port->iotype = UPIO_MEM32;
>>> +   else
>>> +   port->iotype = UPIO_MEM;
>>> +   port->mapbase = reg->address;
>>> +   port->membase = earlycon_map(reg->address, SZ_4K);
>>> +   } else {
>>> +   port->iotype = UPIO_PORT;
>>> +   port->iobase = reg->address;
>>> +   }
>>> +
>>> +   early_console_dev.con->data = _console_dev;
>>> +   err = setup(_console_dev, NULL);
>>> +   if (err < 0)
>>> +   return err;
>>> +   if (!early_console_dev.con->write)
>>> +   return -ENODEV;
>>> +
>>> +   register_console(early_console_dev.con);
>>> +   return 0;
>>> +}
>>> +
>>> +#endif /* CONFIG_ACPI_DBG2_TABLE */
>>> diff --git a/include/linux/acpi_dbg2.h b/include/linux/acpi_dbg2.h
>>> index 125ae7e..b653752 100644
>>> --- 

Re: [PATCH v2] sparc64: Add support for Application Data Integrity (ADI)

[Khalid Aziz]

On 03/02/2016 05:48 PM, Julian Calaby wrote:

Hi Khalid,

On Thu, Mar 3, 2016 at 11:25 AM, Khalid Aziz  wrote:

Thanks, Julian! I really appreciate your feedback.


No problem!


My comments below.

On 03/02/2016 04:08 PM, Julian Calaby wrote:


Hi Khalid,

On Thu, Mar 3, 2016 at 7:39 AM, Khalid Aziz 
wrote:



Enable Application Data Integrity (ADI) support in the sparc
kernel for applications to use ADI in userspace. ADI is a new
feature supported on sparc M7 and newer processors. ADI is supported
for data fetches only and not instruction fetches. This patch adds
prctl commands to enable and disable ADI (TSTATE.mcde), return ADI
parameters to userspace, enable/disable MCD (Memory Corruption
Detection) on selected memory ranges and enable TTE.mcd in PTEs. It
also adds handlers for all traps related to MCD. ADI is not enabled
by default for any task and a task must explicitly enable ADI
(TSTATE.mcde), turn MCD on on a memory range and set version tag
for ADI to be effective for the task. This patch adds support for
ADI for hugepages only. Addresses passed into system calls must be
non-ADI tagged addresses.



I can't comment on the actual functionality here, but I do see a few
minor style issues in your patch.

My big concern is that you're defining a lot of new code that is ADI
specific but isn't inside a CONFIG_SPARC_ADI ifdef. (That said,
handling ADI specific traps if ADI isn't enabled looks like a good
idea to me, however most of the other stuff is just dead code if
CONFIG_SPARC_ADI isn't enabled.)



Some of the code will be executed when CONFIG_SPARC_ADI is not enabled, for
instance init_adi() which will parse machine description to determine if
platform supports ADI. On the other hand, it might still make sense to
enclose this code in #ifdef. More on that below.





Signed-off-by: Khalid Aziz 
---
NOTES: ADI is a new feature added to M7 processor to allow hardware
  to catch rogue accesses to memory. An app can enable ADI on
  its data pages, set version tags on them and use versioned
  addresses (bits 63-60 of the address contain a version tag)
  to access the data pages. If a rogue app attempts to access
  ADI enabled data pages, its access is blocked and processor
  generates an exception. Enabling this functionality for all
  data pages of an app requires adding infrastructure to save
  version tags for any data pages that get swapped out and
  restoring those tags when pages are swapped back in. In this
  first implementation I am enabling ADI for hugepages only
  since these pages are locked in memory and hence avoid the
  issue of saving and restoring tags. Once this core functionality
  is stable, ADI for other memory pages can be enabled more
  easily.

v2:
  - Fixed a build error

   Documentation/prctl/sparc_adi.txt |  62 ++
   Documentation/sparc/adi.txt   | 206
+++
   arch/sparc/Kconfig|  12 ++
   arch/sparc/include/asm/hugetlb.h  |  14 +++
   arch/sparc/include/asm/hypervisor.h   |   2 +
   arch/sparc/include/asm/mmu_64.h   |   1 +
   arch/sparc/include/asm/pgtable_64.h   |  15 +++
   arch/sparc/include/asm/processor_64.h |  19 +++
   arch/sparc/include/asm/ttable.h   |  10 ++
   arch/sparc/include/uapi/asm/asi.h |   3 +
   arch/sparc/include/uapi/asm/pstate.h  |  10 ++
   arch/sparc/kernel/entry.h |   3 +
   arch/sparc/kernel/head_64.S   |   1 +
   arch/sparc/kernel/mdesc.c |  81 +
   arch/sparc/kernel/process_64.c| 222
++
   arch/sparc/kernel/sun4v_mcd.S |  16 +++
   arch/sparc/kernel/traps_64.c  |  96 ++-
   arch/sparc/kernel/ttable_64.S |   6 +-
   include/linux/mm.h|   2 +
   include/uapi/asm-generic/siginfo.h|   5 +-
   include/uapi/linux/prctl.h|  16 +++
   kernel/sys.c  |  30 +
   22 files changed, 826 insertions(+), 6 deletions(-)
   create mode 100644 Documentation/prctl/sparc_adi.txt
   create mode 100644 Documentation/sparc/adi.txt
   create mode 100644 arch/sparc/kernel/sun4v_mcd.S



I must admit that I'm slightly impressed that the documentation is
over a quarter of the lines added. =)


diff --git a/arch/sparc/Kconfig b/arch/sparc/Kconfig
index 56442d2..0aac0ae 100644
--- a/arch/sparc/Kconfig
+++ b/arch/sparc/Kconfig
@@ -80,6 +80,7 @@ config SPARC64
  select NO_BOOTMEM
  select HAVE_ARCH_AUDITSYSCALL
  select ARCH_SUPPORTS_ATOMIC_RMW
+   select SPARC_ADI



This doesn't look right.


   config ARCH_DEFCONFIG
  string
@@ -314,6 +315,17 @@ if SPARC64
   source "kernel/power/Kconfig"
   endif

+config SPARC_ADI
+   bool "Application Data Integrity support"
+   def_bool y if 

[PATCH v2] can: rcar_canfd: Add Renesas R-Car CAN FD driver

[Ramesh Shanmugasundaram]

This patch adds support for the CAN FD controller found in Renesas R-Car
SoCs. The controller operates in CAN FD mode by default.

CAN FD mode supports both Classical CAN & CAN FD frame formats. The
controller supports ISO 11898-1:2015 CAN FD format only.

This controller supports two channels and the driver can enable either
or both of the channels.

Driver uses Rx FIFOs (one per channel) for reception & Common FIFOs (one
per channel) for transmission. Rx filter rules are configured to the
minimum (one per channel) and it accepts Standard, Extended, Data &
Remote Frame combinations.

Note: There are few documentation errors in R-Car Gen3 Hardware User
Manual v0.5E with respect to CAN FD controller. They are listed below:

1. CAN FD interrupt numbers 29 & 30 are listed as per channel
interrupts. However, they are common to both channels (i.e.) they are
global and channel interrupts respectively.

2. CANFD clock is derived from PLL1. This is not documented.

3. CANFD clock is further divided by (1/2) within the CAN FD controller.
This is not documented.

4. The minimum value of NTSEG1 in RSCFDnCFDCmNCFG register is 2 Tq. It
is mentioned 4 Tq in the manual.

5. The maximum number of message RAM area the controller can use is 3584
bytes. It is specified 10752 bytes in the manual.

Signed-off-by: Ramesh Shanmugasundaram 
---
Changes since v1:
* Removed testmodes & debugfs code (suggested by Oliver H)
* Fixed tx path race issue by introducing lock (suggested by Marc K)
* Removed __maybe_unused attribute of rcar_canfd_of_table

Thanks,
Ramesh
---
 .../devicetree/bindings/net/can/rcar_canfd.txt |   86 ++
 drivers/net/can/Kconfig|   10 +
 drivers/net/can/Makefile   |1 +
 drivers/net/can/rcar_canfd.c   | 1624 
 4 files changed, 1721 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/net/can/rcar_canfd.txt
 create mode 100644 drivers/net/can/rcar_canfd.c

diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt 
b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
new file mode 100644
index 000..4299bd8
--- /dev/null
+++ b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt
@@ -0,0 +1,86 @@
+Renesas R-Car CAN FD controller Device Tree Bindings
+
+
+Required properties:
+- compatible: Must contain one or more of the following:
+  - "renesas,rcar-gen3-canfd" for R-Car Gen3 compatible controller.
+  - "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller.
+
+  When compatible with the generic version, nodes must list the
+  SoC-specific version corresponding to the platform first, followed by the
+  family-specific and/or generic versions.
+
+- reg: physical base address and size of the R-Car CAN FD register map.
+- interrupts: interrupt specifier for the Global & Channel interrupts
+- clocks: phandles and clock specifiers for 3 clock inputs.
+- clock-names: 3 clock input name strings: "fck", "canfd", "can_clk".
+- pinctrl-0: pin control group to be used for this controller.
+- pinctrl-names: must be "default".
+
+Required properties for "renesas,r8a7795-canfd" compatible:
+In R8A7795 SoC, canfd clock is a div6 clock and can be used by both CAN
+and CAN FD controller at the same time. It needs to be scaled to maximum
+frequency if any of these controllers use it. This is done using the
+below properties.
+
+- assigned-clocks: phandle of canfd clock.
+- assigned-clock-rates: maximum frequency of this clock.
+
+Each channel is represented as a child node. They can be enabled/disabled
+using "status" property.
+
+Example
+---
+
+SoC common .dtsi file:
+
+   canfd: canfd@e66c {
+   compatible = "renesas,r8a7795-canfd",
+"renesas,rcar-gen3-canfd";
+   reg = <0 0xe66c 0 0x8000>;
+   interrupts = ,
+  ;
+   clocks = < CPG_MOD 914>,
+  < CPG_CORE R8A7795_CLK_CANFD>,
+  <_clk>;
+   clock-names = "fck", "canfd", "can_clk";
+   assigned-clocks = < CPG_CORE R8A7795_CLK_CANFD>;
+   assigned-clock-rates = <4000>;
+   power-domains = <>;
+   status = "disabled";
+
+   channel0 {
+   status = "disabled";
+   };
+
+   channel1 {
+   status = "disabled";
+   };
+   };
+
+Board specific .dts file:
+
+E.g. below enables Channel 1 alone in the board.
+
+ {
+pinctrl-0 = <_pins>;
+pinctrl-names = "default";
+status = "okay";
+
+   channel1 {
+   status = 

Re: Kernel docs: muddying the waters a bit

[Jonathan Corbet]

On Thu, 3 Mar 2016 14:34:25 +
One Thousand Gnomes  wrote:

> We only have docbook because it was the tool of choice rather a lot of
> years ago to then get useful output formats. It was just inherited when
> borrowed the original scripts from Gnome/Gtk. It's still the most
> effective way IMHO of building big structured documents out of the kernel.

...except that we haven't used it that way.  Instead, we make a whole
bunch of smaller, partially structured document silos.

> The Gtk people long ago rewrote the original document script into a real
> tool so they have some different and maintained tools that are close to
> equivalent and already have some markdown support. Before we go off and
> re-invent the wheel it might be worth just borrowing their wheel and
> tweaking it as needed ? In particular they can generate help indexes so
> that the entire output becomes nicely browsable with an HTML based help
> browser.

Well, not inventing the wheel was kind of the motivation behind much of
this effort; I got kind of worried watching us trying to cobble more
functionality into our existing house-of-cards documentation system.

Sphinx is a well-established, heavily used, and well supported system;
using it would not be an exercise in wheel reinvention.  As far as I can
tell, it does everything we need (with some open questions about table
support), lets us drop the whole DocBook toolchain dependency, and move to
a much better-supported setup than we have now.  Plus we get much nicer
output, index generation, cross-references between documents, and the
ability to write documents in a lightweight markup language.  Seems like a
win.

I assume you're referring to gtk-doc?  It's web page
(http://www.gtk.org/gtk-doc/) starts by noting that it's "a bit awkward to
setup and use"; they recommend looking at Doxygen instead.  So I guess I'm
not really sure what it offers that merits throwing another option into
the mix now?  What am I missing?

Thanks,

jon
--
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 docs: muddying the waters a bit

[One Thousand Gnomes]

> DocBook is a means to an end; nobody really wants DocBook itself as far
> as I can tell. 

We only have docbook because it was the tool of choice rather a lot of
years ago to then get useful output formats. It was just inherited when
borrowed the original scripts from Gnome/Gtk. It's still the most
effective way IMHO of building big structured documents out of the kernel.

The Gtk people long ago rewrote the original document script into a real
tool so they have some different and maintained tools that are close to
equivalent and already have some markdown support. Before we go off and
re-invent the wheel it might be worth just borrowing their wheel and
tweaking it as needed ? In particular they can generate help indexes so
that the entire output becomes nicely browsable with an HTML based help
browser.

Alan
--
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 docs: muddying the waters a bit

[Jonathan Corbet]

On Thu, 03 Mar 2016 16:03:14 +0200
Jani Nikula  wrote:

> This stalled a bit, but the waters are still muddy...

I've been dealing with real-world obnoxiousness, something which won't
come to an immediate end, unfortunately.  But I have been taking some time
to mess with things, and hope to have some more POC patches to send out
soon.

> Is the Sphinx/reStructuredText table support adequate for media/v4l
> documentation?

That's perhaps the biggest question.  My sense is "yes", but this needs a
bit more assurance than that.

> Are the Sphinx output formats adequate in general? Specifically, is the
> lack of DocBook support, and the flexibility it provides, a blocker?

DocBook is a means to an end; nobody really wants DocBook itself as far
as I can tell. I've been messing with rst2pdf a bit; it's not hard to get
reasonable output, and, with some effort, we could probably get really
nice output. HTML and EPUB are easily covered, still haven't really played
around with man pages yet.  And there's LaTeX if we really need it.  I
kind of think we're covered there, unless I've missed something?

> Otherwise, I think Sphinx is promising.
> 
> Jon, I think we need a roll of dice, err, a well-thought-out decision
> from the maintainer to go with one or the other, so we can make some
> real progress.

My inclination at the moment is very much in the Sphinx direction.  I had
some vague thoughts of pushing a throwaway experimental directory with a
couple of docs for 4.6 that would just let people play with it easily;
then we'd see how many screams we get.  We'll see if the world lets me get
there.

Thanks,

jon
--
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 docs: muddying the waters a bit

[Jani Nikula]

On Sat, 13 Feb 2016, Jonathan Corbet  wrote:
> So can we discuss?  I'm not saying we have to use Sphinx, but, should we
> choose not to, we should do so with open eyes and good reasons for the
> course we do take.  What do you all think?

This stalled a bit, but the waters are still muddy...

Is the Sphinx/reStructuredText table support adequate for media/v4l
documentation?

Are the Sphinx output formats adequate in general? Specifically, is the
lack of DocBook support, and the flexibility it provides, a blocker?

Otherwise, I think Sphinx is promising.

Jon, I think we need a roll of dice, err, a well-thought-out decision
from the maintainer to go with one or the other, so we can make some
real progress.

BR,
Jani.


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

Re: [RFC PATCH] arm: kernel: pci: remove pci=firmware command line parameter handling

[Lorenzo Pieralisi]

On Thu, Mar 03, 2016 at 12:31:42AM +0200, Lennert Buytenhek wrote:
> On Tue, Mar 01, 2016 at 09:58:33AM +, Lorenzo Pieralisi wrote:
> 
> > > > According to kernel documentation, the pci=firmware command line
> > > > parameter is only meant to be used on IXP2000 ARM platforms to prevent
> > > > the kernel from assigning PCI resources configured by the bootloader.
> > > > 
> > > > Since the IXP2000 ARM platforms support has been removed from the
> > > > kernel in commit:
> > > > 
> > > > commit c65f2abf54a6 ("ARM: remove ixp23xx and ixp2000 platforms")
> > > > 
> > > > its platforms specific kernel parameters should be removed
> > > > too from the kernel documentation along with the kernel code
> > > > currently handling them in that they have just become obsolete.
> > > > 
> > > > This patch removes the pci=firmware command line parameter handling
> > > > from ARM code and the related kernel parameters documentation
> > > > section.
> > > > 
> > > > Signed-off-by: Lorenzo Pieralisi 
> > > > Cc: Arnd Bergmann 
> > > > Cc: Lennert Buytenhek 
> > > > Cc: Jonathan Corbet 
> > > > Cc: Bjorn Helgaas 
> > > > Cc: Rob Herring 
> > > > Cc: Russell King 
> > > 
> > > Acked-by: Lennert Buytenhek 
> > 
> > Thank you Lennert, I take this as an acknowledgement that you are not
> > aware of any other ARM platform using that kernel parameter other than
> > IXP2000s, according to documentation there should not be any but it is a
> > bit complicated to figure out.
> 
> I'm not aware of other platforms using this, but that might not say
> much, I've been out of the loop on Linux/ARM things for a while now.

I think we should go ahead otherwise we are stuck forever with it,
it is probably best for this patch to land in -next beginning of
next cycle to unearth possible issues, that's the same thing
we did for the latest changes in arm pcibios that we feared could
trigger regressions.

Russell, what's your opinion on this ? Please let me know.

Thanks !
Lorenzo
--
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: [PATCHv9 1/3] rdmacg: Added rdma cgroup controller

[Parav Pandit]

On Thu, Mar 3, 2016 at 1:44 PM, Haggai Eran  wrote:
> On 03/03/2016 05:18, Parav Pandit wrote:
>> On Thu, Mar 3, 2016 at 1:28 AM, Parav Pandit  wrote:
>>> On Wed, Mar 2, 2016 at 11:09 PM, Tejun Heo  wrote:
 Nothing seems to prevent @cg from going away if this races with
 @current being migrated to a different cgroup.  Have you run this with
 lockdep and rcu debugging enabled?  This should have triggered a
 warning.
>> I am able to reproduce this race. Looking into how to address it.
>
> If I understand correctly, task_css() requires rcu read lock being held.
> Is task_get_css() suitable here?

Yes. Its suitable if we continue with newer API to drop "num" entries.
Or I will have make minor modification to support that in cgroup.h.
There is no variation as task_get_css_many, but its minor change anyway.
I saw slept off yesterday night, saw today morning.
Will test over weekend and wait for Tejun's opinion if there is any.
--
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