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
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
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
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
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,
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
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
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
> 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
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
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
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,
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
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
> 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
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
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
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
> > > >
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
19 matches
Mail list logo