On Sun, 20 Nov 2016 14:08:31 -0200
Mauro Carvalho Chehab wrote:
> The goal of this patch series is to get rid of PNG images, using either
> graphviz
> or SVG for images.
So the pdfdocs build fails with an error when I apply this...
> xelatex -interaction=batchmode 'media.tex'
> This is XeTeX,
On Mon, Nov 28, 2016 at 03:10:38PM -0800, John Muir wrote:
> On Nov 28, 2016, at 2:19 PM, Guenter Roeck wrote:
> >
> > The tmp102 driver adds the timeout if the device was in shutdown mode
> > (SD=1).
> >
> > if (tmp102->config_orig & TMP102_CONF_SD) {
> > ...
> > tm
On Nov 28, 2016, at 2:19 PM, Guenter Roeck wrote:
>
> The tmp102 driver adds the timeout if the device was in shutdown mode (SD=1).
>
> if (tmp102->config_orig & TMP102_CONF_SD) {
> ...
> tmp102->ready_time += msecs_to_jiffies(CONVERSION_TIME_MS);
> }
>
>
On Mon, Nov 28, 2016 at 01:25:37PM -0800, John Muir wrote:
>
> > On Nov 28, 2016, at 11:58 AM, Guenter Roeck wrote:
> >
> > On Mon, Nov 28, 2016 at 11:40:42AM -0800, John Muir wrote:
> +static void tmp108_update_ready_time(struct tmp108 *tmp108)
> +{
> +tmp108->ready_time
> On Nov 28, 2016, at 11:58 AM, Guenter Roeck wrote:
>
> On Mon, Nov 28, 2016 at 11:40:42AM -0800, John Muir wrote:
+static void tmp108_update_ready_time(struct tmp108 *tmp108)
+{
+ tmp108->ready_time = jiffies;
+ if ((tmp108->config & TMP108_CONF_MODE_MASK)
+ ==
On Mon, Nov 28, 2016 at 11:40:42AM -0800, John Muir wrote:
>
> > On Nov 27, 2016, at 4:19 AM, Guenter Roeck wrote:
> >
> > On 11/26/2016 09:15 PM, John Muir wrote:
> >> Add support for the TI TMP108 temperature sensor with some device
> >> configuration parameters.
> >> +- ti,alert-active-high :
> On Nov 27, 2016, at 4:19 AM, Guenter Roeck wrote:
>
> On 11/26/2016 09:15 PM, John Muir wrote:
>> Add support for the TI TMP108 temperature sensor with some device
>> configuration parameters.
>> +- ti,alert-active-high : (boolean) make the alert pin active-high instead of
>> + the defaul
Em Mon, 28 Nov 2016 17:16:22 +0100
Daniel Vetter escreveu:
> We already had a super-short blurb, but worth extending it I think:
> We're still pretty far away from anything like a consensus, but
> there's clearly a lot of people who prefer an as-light as possible
> approach to converting existing
This patch removes following error at for `make htmldocs`. No functional
change.
./drivers/base/firmware_class.c:1348: WARNING: Bullet list ends without
a blank line; unexpected unindent.
Signed-off-by: Silvio Fricke
Reviewed-by: Mauro Carvalho Chehab
---
drivers/base/firmware_class.c
... and move to core-api folder.
Signed-off-by: Silvio Fricke
Reviewed-by: Mauro Carvalho Chehab
---
Documentation/core-api/index.rst| 1 +-
Documentation/local_ops.txt => Documentation/core-api/local_ops.rst | 273
+++
2 files changed, 145 insertions(
... and move to core-api folder.
Signed-off-by: Silvio Fricke
---
Documentation/atomic_ops.txt => Documentation/core-api/atomic_ops.rst | 324
++--
Documentation/core-api/index.rst | 1 +-
... and move to Documentation/core-api folder.
Signed-off-by: Silvio Fricke
Reviewed-by: Mauro Carvalho Chehab
---
Documentation/assoc_array.txt => Documentation/core-api/assoc_array.rst | 639
++--
Documentation/core-api/inde
Hi,
Some more ReSTification of core-api's: assoc_array, atomic_ops and local_ops. A
fourth patch removes a warning about a bullet list without ending at
firmware_class.c
v3 -> v4
* add Review-by comments
* rewrite atomic_ops.rst file with fewer inversive changes
* reorder patch series old(1,2,3,4
We already had a super-short blurb, but worth extending it I think:
We're still pretty far away from anything like a consensus, but
there's clearly a lot of people who prefer an as-light as possible
approach to converting existing .txt files to .rst. Make sure this is
properly taken into account an
Em Mon, 28 Nov 2016 14:46:45 +0100
Daniel Vetter escreveu:
> On Mon, Nov 28, 2016 at 12:54:13PM +0100, Peter Zijlstra wrote:
> > On Mon, Nov 28, 2016 at 09:08:55AM -0200, Mauro Carvalho Chehab wrote:
> > > - use *foo* (for italics) or **foo** (for bold) instead of _foo_;
> >
> > That's daft,
On Mon, 28 Nov 2016 15:13:14 +0100
Daniel Vetter wrote:
> Jon, should we document that we want a very light-handed approach to rst
> markup in kernel docs? This has come up a few times now, and irrespective
> of what exactly we're going to do with atomic_ops.txt I think it would
> help with makin
Hi Peter,
On Mon, Nov 28, 2016 at 11:20:09AM +0100, Peter Zijlstra wrote:
> On Mon, Nov 28, 2016 at 09:44:42AM +0100, Daniel Vetter wrote:
> > > Why change them? What was wrong with txt to begin with?
> >
> > In my opinion good docs matter, and one of the key things is to be able to
> > cross ref
On Mon, Nov 28, 2016 at 12:54:13PM +0100, Peter Zijlstra wrote:
> On Mon, Nov 28, 2016 at 09:08:55AM -0200, Mauro Carvalho Chehab wrote:
> > - use *foo* (for italics) or **foo** (for bold) instead of _foo_;
>
> That's daft, and also you're wrong. The normal convention is:
>
> /italic/
>
On Mon, 28 Nov 2016, Peter Zijlstra wrote:
> On Mon, Nov 28, 2016 at 01:16:45PM +0200, Jani Nikula wrote:
>> Using rst we can produce decent HTML pages, and make them available at
>> [1], in context. You don't have to read that, but it will be a lot more
>> discoverable for other people, another i
Documentation/filesystems/configfs/configfs.txt says:
"When unlink(2) is called on the symbolic link, the source item is
notified via the ->drop_link() method. Like the ->drop_item() method,
this is a void function and cannot return failure."
The ->drop_item() is indeed a void function, the ->dr
On Mon, Nov 28, 2016 at 01:16:45PM +0200, Jani Nikula wrote:
> Using rst we can produce decent HTML pages, and make them available at
> [1], in context. You don't have to read that, but it will be a lot more
> discoverable for other people, another important quality of good
> documentation. And per
On Mon, Nov 28, 2016 at 09:08:55AM -0200, Mauro Carvalho Chehab wrote:
> - use *foo* (for italics) or **foo** (for bold) instead of _foo_;
That's daft, and also you're wrong. The normal convention is:
/italic/
*bold*
_underlined_
> :ref:`Documentation/admin-guide/s
On Mon, 28 Nov 2016, Peter Zijlstra wrote:
> On Mon, Nov 28, 2016 at 09:44:42AM +0100, Daniel Vetter wrote:
>
>> >
>> > Why change them? What was wrong with txt to begin with?
>>
>> In my opinion good docs matter, and one of the key things is to be able to
>> cross reference stuff.
>
> Well, goo
Em Mon, 28 Nov 2016 11:20:09 +0100
Peter Zijlstra escreveu:
> On Mon, Nov 28, 2016 at 09:44:42AM +0100, Daniel Vetter wrote:
>
> > >
> > > Why change them? What was wrong with txt to begin with?
> >
> > In my opinion good docs matter, and one of the key things is to be able to
> > cross refe
On Mon, Nov 28, 2016 at 09:44:42AM +0100, Daniel Vetter wrote:
> >
> > Why change them? What was wrong with txt to begin with?
>
> In my opinion good docs matter, and one of the key things is to be able to
> cross reference stuff.
Well, good docs begin with useful content; and many docs lack th
Em Mon, 28 Nov 2016 12:02:43 +0200
Jani Nikula escreveu:
> On Mon, 28 Nov 2016, Mauro Carvalho Chehab wrote:
> > Em Mon, 28 Nov 2016 09:22:31 +0100
> > Markus Heiser escreveu:
> >> Since this is for "figure" AND "image" (inline) I thought it is
> >> better to replace. But I'am open to change
On Mon, 28 Nov 2016, Mauro Carvalho Chehab wrote:
> Em Mon, 28 Nov 2016 09:22:31 +0100
> Markus Heiser escreveu:
>> Since this is for "figure" AND "image" (inline) I thought it is
>> better to replace. But I'am open to change this .. concrete ideas?
>
> I agree. IMHO, the best is to keep the exis
Em Mon, 28 Nov 2016 09:47:56 +0100
Daniel Vetter escreveu:
> On Sun, Nov 27, 2016 at 04:02:05PM +0100, Markus Heiser wrote:
> > Replacement for the sphinx ``figure`` and ``images`` directive.
> >
> > A image (or figure) directive which make use of the *glob* notation::
> >
> > .. figure:: he
Em Mon, 28 Nov 2016 10:43:15 +0100
Markus Heiser escreveu:
> Am 28.11.2016 um 10:16 schrieb Jani Nikula :
>
> >> Since this is for "figure" AND "image" (inline) I thought it is
> >> better to replace. But I'am open to change this .. concrete ideas?
> >
> > Please don't shadow Sphinx directive
Em Mon, 28 Nov 2016 09:22:31 +0100
Markus Heiser escreveu:
> Hi Jon,
>
> you forgot to reply ML (and other CC) ... so I will do it here.
>
> Am 27.11.2016 um 18:54 schrieb Jonathan Corbet :
>
> > On Sun, 27 Nov 2016 16:25:43 +0100
> > Markus Heiser wrote:
> >
> >> Replacement for the sphin
Am 28.11.2016 um 10:16 schrieb Jani Nikula :
>> Since this is for "figure" AND "image" (inline) I thought it is
>> better to replace. But I'am open to change this .. concrete ideas?
>
> Please don't shadow Sphinx directives. Otherwise people will look for
> Sphinx documentation for the directive
On Mon, 28 Nov 2016, Markus Heiser wrote:
> Hi Jon,
>
> you forgot to reply ML (and other CC) ... so I will do it here.
>
> Am 27.11.2016 um 18:54 schrieb Jonathan Corbet :
>
>> On Sun, 27 Nov 2016 16:25:43 +0100
>> Markus Heiser wrote:
>>
>>> Replacement for the sphinx ``figure`` and ``images``
On Sun, Nov 27, 2016 at 04:02:05PM +0100, Markus Heiser wrote:
> Replacement for the sphinx ``figure`` and ``images`` directive.
>
> A image (or figure) directive which make use of the *glob* notation::
>
> .. figure:: hello.*
For namespacing, I think we should call this kernel-figure or some
On Mon, Nov 28, 2016 at 08:26:26AM +0100, Peter Zijlstra wrote:
> On Sun, Nov 27, 2016 at 04:59:14PM -0700, Jonathan Corbet wrote:
> > On Fri, 25 Nov 2016 22:58:14 +0100
> > Peter Zijlstra wrote:
> >
> > > Not a fan of this. The atomic_ops.txt file needs a lot of love, and I
> > > wouldn't want t
On Wed, Nov 23, 2016 at 07:30:21AM -0200, Mauro Carvalho Chehab wrote:
> Em Wed, 23 Nov 2016 08:34:11 +0100
> Daniel Vetter escreveu:
>
> > On Mon, Nov 21, 2016 at 05:42:07PM -0200, Mauro Carvalho Chehab wrote:
> > > Em Mon, 21 Nov 2016 17:03:55 +0100
> > > Daniel Vetter escreveu:
>
> > > > I'm
Hi Jon,
you forgot to reply ML (and other CC) ... so I will do it here.
Am 27.11.2016 um 18:54 schrieb Jonathan Corbet :
> On Sun, 27 Nov 2016 16:25:43 +0100
> Markus Heiser wrote:
>
>> Replacement for the sphinx ``figure`` and ``images`` directive.
>>
>> A image (or figure) directive which m
36 matches
Mail list logo
