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
>>> lo
Hi Arnd,
I fully agree and ack.
Thanks for the work.
Am 02.03.2016 um 20:06 schrieb Arnd Bergmann:
> 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 apparent
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 migr
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 03, 2016 at 10:48:45AM +, Lorenzo Pieralisi wrote:
> 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 i
Hi Marc,
Sorry for the late response.
> On 03/02/2016 11:08 AM, Ramesh Shanmugasundaram wrote:
> I see no locking for the tx-path.
> >>>
> >>> I am not sure why locking is needed in tx-path?
> >>
> >> If the tx-path is shared between both channels you need locking as
> >> the networking subs
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 th
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 so
> 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 mo
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
On Thu, Mar 3, 2016 at 4:17 PM, Jonathan Corbet wrote:
> 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 t
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 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 A
On 03/02/2016 06:33 PM, Julian Calaby wrote:
Hi Khalid,
A couple of other comments:
On Thu, Mar 3, 2016 at 5:54 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
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
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, co
Em Thu, 03 Mar 2016 07:13:05 -0700
Jonathan Corbet escreveu:
> 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, unfortunat
On 03/03/2016 09:48 AM, Peter Hurley wrote:
> 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 specifi
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
+d
> 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 li
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 iore
On Thu, Mar 03, 2016 at 01:21:48PM -0800, Luis R. Rodriguez wrote:
> 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
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
>
Hi Khalid,
On Fri, Mar 4, 2016 at 4:42 AM, Khalid Aziz wrote:
> On 03/02/2016 06:33 PM, Julian Calaby wrote:
>>
>> Hi Khalid,
>>
>> A couple of other comments:
>>
>> On Thu, Mar 3, 2016 at 5:54 AM, Khalid Aziz
>> wrote:
>>>
>>>
>>> Enable Application Data Integrity (ADI) support in the sparc
>>>
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 a
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
> differe
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.
Howev
On 03/03/2016 03:26 PM, Julian Calaby wrote:
Hi Khalid,
On Fri, Mar 4, 2016 at 4:42 AM, Khalid Aziz wrote:
On 03/02/2016 06:33 PM, Julian Calaby wrote:
Hi Khalid,
A couple of other comments:
On Thu, Mar 3, 2016 at 5:54 AM, Khalid Aziz
wrote:
Enable Application Data Integrity (ADI) supp
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 abil
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
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
31 matches
Mail list logo
