Am 18.12.2016 um 11:11 schrieb Dmitry Shachnev :
> In docutils 0.13, the return type of get_column_widths method of the
> Table directive has changed [1], which breaks our flat-table directive
> and leads to a TypeError when trying to build the docs [2].
>
> This patch adds support for the new r
On Fri, 16 Dec 2016, Robert Bragg wrote:
> The sphinx.__version__ string doesn't always include a patch version and
> so the previous tuple decomposition failed with to few elements.
>
> Since I hit the case with no patch version ("1.5"), I guess it's
> possible a major release might elide the min
Em Mon, 19 Dec 2016 11:44:57 +0200
Jani Nikula escreveu:
> On Fri, 16 Dec 2016, Robert Bragg wrote:
> > The sphinx.__version__ string doesn't always include a patch version and
> > so the previous tuple decomposition failed with to few elements.
> >
> > Since I hit the case with no patch version
On Mon, 19 Dec 2016, Mauro Carvalho Chehab wrote:
> It could be interesting to print some error message if someone tries
> to build with an older version or if the version can't be detected,
> asking the user to upgrade Sphinx.
This will do it.
BR,
Jani.
diff --git a/Documentation/conf.py b/Do
On Sat, 17 Dec 2016, Kevin Wilson wrote:
> Hi,
> I am trying to clone the linux documentation git repo, according to
> the URL in the Linux kernel Maintainers file, by:
>
> git clone git://git.lwn.net/linux.git
> and I am getting an error as I am behind a company proxy.
>
> With other repos, whic
On Thu, Dec 01, 2016 at 05:21:01PM -0800, Andy Lutomirski wrote:
> On 09/28/2016 07:44 AM, Amir Levy wrote:
> > This patch provides the communication protocol between the
> > Intel Connection Manager(ICM) firmware that is operational in the
> > Thunderbolt controller in non-Apple hardware.
> > The
On 12/18/2016 01:11 PM, Rami Rosen wrote:
This patch fixes a trivial type in IPMI.txt.
Thanks, queued for next release.
-corey
Signed-off-by: Rami Rosen
---
Documentation/IPMI.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/IPMI.txt b/Documentation/I
I guess the obvious questions is: why is a driver for a PCI switch
necessary? The core works with all compliant switches today and there
are no specifics for a particular design or such.
So I guess I'd like to hear the reasoning and justifications for why a
driver for a common device that should
On Sat, Dec 17, 2016 at 10:09:22AM -0700, Logan Gunthorpe wrote:
> Microsemi's "Switchtec" line of PCI switch devices is already
> supported by the kernel with standard PCI switch drivers. However, the
> Switchtec device advertises a special management endpoint which
> enables some additional funct
On 19/12/16 10:02 AM, Keith Busch wrote:
> Some of this would be simplified if you use the managed device API's:
> devm_request_irq, pcim_enable_device, pcim_iomap, etc...
Thanks Keith, I'll look into using those.
Logan
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
Hey,
On 19/12/16 09:09 AM, Myron Stowe wrote:
> I guess the obvious questions is: why is a driver for a PCI switch
> necessary? The core works with all compliant switches today and there
> are no specifics for a particular design or such.
> So I guess I'd like to hear the reasoning and justifica
On Mon, Dec 19, 2016 at 10:06:56AM -0700, Logan Gunthorpe wrote:
> As I noted, the hardware is compliant and works perfectly fine with the
> in-kernel driver. However, the hardware has many additional custom
> features that are not covered by the PCI specs. For example, it has an
> interface to cou
On 19/12/16 10:29 AM, Keith Busch wrote:
> Since the in-kernel driver binds to the device, won't this driver
> conflict with the initialization the in-kernel one already does? Bus
> master, MSI setup, etc?
No. The management interface is on a completely separate PCI endpoint.
So from the kernels
Dell - Internal Use - Confidential
>
> There is small problem, though. On non-Apple systems the host controller only
> appears when something is connected to thunderbolt ports. So the char device
> would not be there all the time. However, I think we can still notify the
> userspace by sending
From: Rafael J. Wysocki
The references to drivers/base/power/main.c and
drivers/acpi/scan.c from Documentation/driver-api/infrastructure.rst
are confusing. They both cause descriptions of functions that are
not relevant to device drivers at all to be generated and none of
them is sufficient to c
From: Rafael J. Wysocki
Refresh the struct dev_pm_ops kerneldoc comment, so that it looks
better and is more readable after processing by Sphinx, and drop
the kerneldoc marker from the "PM_EVENT_ messages" comment which
is not a proper kerneldoc and causes Sphinx to generate confusing
mess.
Sign
Hi Everyone,
These two patches update kerneldoc comments in include/linux/pm.h ([1/2]) and
convert Documentation/power/devices.txt to reST ([2/2], RFC).
Please have a look, especially at patch [2/2], and let me know what can be done
in a better way.
Thanks,
Rafael
--
To unsubscribe from this li
From: Rafael J. Wysocki
Move the document describing the system sleep states transition API
for devices to Documentation/driver-api/pm/, convert it to reST and
update it to use current terminology. Also remove the remaining
reference to the old version from pm.h.
The new document still contains
In the actual implementation ether_addr_equal function tests for equality to 0
when returning. It seems in commit 0d74c4 it is somehow overlooked to change
this operator to reflect the actual function.
Signed-off-by: Cihangir Akturk
---
Documentation/unaligned-memory-access.txt | 2 +-
1 file ch
On Mon, 19 Dec 2016 23:53:40 +0200
Cihangir Akturk wrote:
> In the actual implementation ether_addr_equal function tests for equality to 0
> when returning. It seems in commit 0d74c4 it is somehow overlooked to change
> this operator to reflect the actual function.
I received this patch two days
On Mon, Dec 19, 2016 at 04:13:13PM -0700, Jonathan Corbet wrote:
> On Mon, 19 Dec 2016 23:53:40 +0200
> Cihangir Akturk wrote:
>
> > In the actual implementation ether_addr_equal function tests for equality
> > to 0
> > when returning. It seems in commit 0d74c4 it is somehow overlooked to change
On Sun, Dec 18, 2016 at 12:52:12AM +0200, Ozgur Karatas wrote:
> 17.12.2016, 19:43, "Cihangir Akturk" :
> > In the actual implementation ether_addr_equal function tests for equality
> > to 0
> > when returning. It seems in commit 0d74c4 it is somehow overlooked to change
> > this operator to refle
The following changes since commit
3fa71d0f58a9b9df84e8e79196f961bcfbf01b2e:
crypto: doc - optimize compilation (2016-12-13 16:38:07 -0700)
are available in the git repository at:
git://git.lwn.net/linux.git tags/doc-4.10-3
for you to fetch changes up to 217e2bfab22e740227df09f22165e834cddd
"Luis R. Rodriguez" writes:
> On Dec 16, 2016 9:54 PM, "Rusty Russell" wrote:
> > AFAICT the mistake here is that kmod is returning "done, OK" when the
> > module it is trying to load is already loading (but not finished
> > loading). That's the root problem; it's an attempt at optimization by
>
24 matches
Mail list logo
