Re: Kernel docs: muddying the waters a bit

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

Re: Kernel docs: muddying the waters a bit

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

Re: Kernel docs: muddying the waters a bit

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

Re: Kernel docs: muddying the waters a bit

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

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

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,

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

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

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

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

[PATCH] x86: PAT: Documentation: update overlapping ioremap hack recommendation

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

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

> 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

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

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

Re: [PATCH v3 5/7] ACPI: serial: implement earlycon on ACPI DBG2 port

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

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

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,

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

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

Re: Kernel docs: muddying the waters a bit

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

Re: Kernel docs: muddying the waters a bit

> 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

Re: Kernel docs: muddying the waters a bit

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

Re: Kernel docs: muddying the waters a bit

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

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

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

Re: [PATCHv9 1/3] rdmacg: Added rdma cgroup controller

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