[PATCH] regulator/overview.txt: Use ".." for ranges, instead of "->"
Using "->" to indicate range is not too common, switch to ".." Signed-off-by: Pavel Machek --- a/Documentation/power/regulator/overview.txt +++ b/Documentation/power/regulator/overview.txt @@ -90,7 +90,7 @@ Some terms used in this document:- operating parameters and is specified in the regulator datasheet. i.e. - - voltage output is in the range 800mV -> 3500mV. + - voltage output is in the range 800mV .. 3500mV. - regulator current output limit is 20mA @ 5V but is 10mA @ 10V. @@ -99,8 +99,8 @@ Some terms used in this document:- power domain to a particular power range. i.e. - Domain-1 voltage is 3300mV - - Domain-2 voltage is 1400mV -> 1600mV - - Domain-3 current limit is 0mA -> 20mA. + - Domain-2 voltage is 1400mV .. 1600mV + - Domain-3 current limit is 0mA .. 20mA. Consumer Level: This is defined by consumer drivers dynamically setting voltage or current limit levels. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature
Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts
Am 07.10.2016 um 07:56 schrieb Jani Nikula : > On Thu, 06 Oct 2016, Mauro Carvalho Chehab wrote: >> Em Thu, 06 Oct 2016 17:21:36 +0300 >> Jani Nikula escreveu: >>> We've seen what happens when we make it easy to add random scripts to >>> build documentation. We've worked hard to get rid of that. In my books, >>> one of the bigger points in favor of Sphinx over AsciiDoc(tor) was >>> getting rid of all the hacks required in the build. Things that broke in >>> subtle ways. >> >> I really can't see what scripts it get rids. > > Really? You don't see why the DocBook build was so fragile and difficult > to maintain? That scares me a bit, because then you will not have > learned why we should at all costs avoid adding random scripts to > produce documentation. For me, disassembling the DocBok build was hard and bothersome, I don't want this back. IMO: old hats are productive with perl and they won't adapt another interpreter language (like python) for scripting. This series -- the kernel-cmd -- directive avoid that they build fragile and difficult to maintain Makefile constructs, calling their perl scripts. Am 06.10.2016 um 16:21 schrieb Jani Nikula : > This is connected to the above: keeping documentation buildable with > sphinx-build directly will force you to avoid the Makefile hacks. Thats why I think, that the kernel-cmd directive is a more *straight- forward* solution, helps to **avoid** complexity while not everyone has to script in python ... > Case in point, parse-headers.pl was added for a specific need of media > documentation, and for the life of me I can't figure out by reading the > script what good, if any, it would be for gpu documentation. I call > *that* unmaintainable. If one adds a script like parse-headers.pl to the Documentation/sphinx folder, he/she also has to add a documentation to the kernel-documentation.rst If the kernel-cmd directive gets acked, I will add a description to kernel-documentation.rst and I request Mauro to document the parse-headers.pl also. But, let's hear what Jon says. -- Markus -- -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] rpmsg: Driver for user space endpoint interface
On 10/08/2016 06:23 AM, Bjorn Andersson wrote:
This driver allows rpmsg instances to expose access to rpmsg endpoints
to user space processes. It provides a control interface, allowing
userspace to export endpoints and an endpoint interface for each exposed
endpoint.
The implementation is based on prior art by Texas Instrument, Google,
PetaLogix and was derived from a FreeRTOS performance statistics driver
written by Michal Simek.
The control interface provides a "create endpoint" ioctl, which is fed a
name, source and destination address. The three values are used to
create the endpoint, in a backend-specific way, and a rpmsg endpoint
device is created - with the three parameters are available in sysfs for
udev usage.
E.g. to create an endpoint device for one of the Qualcomm SMD channel
related to DIAG one would issue:
struct rpmsg_endpoint_info info = { "DIAG_CNTL", 0, 0 };
int fd = open("/dev/rpmsg_ctrl0", O_RDWR);
ioctl(fd, RPMSG_CREATE_EPT_IOCTL, &info);
Each created endpoint device shows up as an individual character device
in /dev, allowing permission to be controlled on a per-endpoint basis.
The rpmsg endpoint will be created and destroyed following the opening
and closing of the endpoint device, allowing rpmsg backends to open and
close the physical channel, if supported by the wire protocol.
Cc: Marek Novak
Cc: Matteo Sartori
Cc: Michal Simek
Signed-off-by: Bjorn Andersson
---
Documentation/ioctl/ioctl-number.txt | 1 +
drivers/rpmsg/Makefile | 2 +-
drivers/rpmsg/rpmsg_char.c | 576 +++
drivers/rpmsg/rpmsg_internal.h | 2 +
include/uapi/linux/rpmsg.h | 35 +++
5 files changed, 615 insertions(+), 1 deletion(-)
create mode 100644 drivers/rpmsg/rpmsg_char.c
create mode 100644 include/uapi/linux/rpmsg.h
diff --git a/Documentation/ioctl/ioctl-number.txt
b/Documentation/ioctl/ioctl-number.txt
index 81c7f2bb7daf..08244bea5048 100644
--- a/Documentation/ioctl/ioctl-number.txt
+++ b/Documentation/ioctl/ioctl-number.txt
@@ -321,6 +321,7 @@ Code Seq#(hex) Include FileComments
0xB1 00-1F PPPoX
0xB3 00 linux/mmc/ioctl.h
0xB4 00-0F linux/gpio.h
+0xB5 00-0F uapi/linux/rpmsg.h
0xC0 00-0F linux/usb/iowarrior.h
0xCA 00-0F uapi/misc/cxl.h
0xCA 80-8F uapi/scsi/cxlflash_ioctl.h
diff --git a/drivers/rpmsg/Makefile b/drivers/rpmsg/Makefile
index ae9c9132cf76..5daf1209b77d 100644
--- a/drivers/rpmsg/Makefile
+++ b/drivers/rpmsg/Makefile
@@ -1,3 +1,3 @@
-obj-$(CONFIG_RPMSG)+= rpmsg_core.o
+obj-$(CONFIG_RPMSG)+= rpmsg_core.o rpmsg_char.o
Hi Bjorn,
Could you please create a dedicated Kconfig entry for this new interface?
This should be an option like i2C_dev.
Regards,
Loic
obj-$(CONFIG_RPMSG_QCOM_SMD) += qcom_smd.o
obj-$(CONFIG_RPMSG_VIRTIO) += virtio_rpmsg_bus.o
diff --git a/drivers/rpmsg/rpmsg_char.c b/drivers/rpmsg/rpmsg_char.c
new file mode 100644
index ..a398a63e8d44
--- /dev/null
+++ b/drivers/rpmsg/rpmsg_char.c
@@ -0,0 +1,576 @@
+/*
+ * Copyright (c) 2016, Linaro Ltd.
+ * Copyright (c) 2012, Michal Simek
+ * Copyright (c) 2012, PetaLogix
+ * Copyright (c) 2011, Texas Instruments, Inc.
+ * Copyright (c) 2011, Google, Inc.
+ *
+ * Based on rpmsg performance statistics driver by Michal Simek, which in turn
+ * was based on TI & Google OMX rpmsg driver.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 and
+ * only version 2 as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include "rpmsg_internal.h"
+
+#define RPMSG_DEV_MAX 256
+
+static dev_t rpmsg_major;
+static struct class *rpmsg_class;
+
+static DEFINE_IDA(rpmsg_ctrl_ida);
+static DEFINE_IDA(rpmsg_ept_ida);
+static DEFINE_IDA(rpmsg_minor_ida);
+
+#define dev_to_eptdev(dev) container_of(dev, struct rpmsg_eptdev, dev)
+#define cdev_to_eptdev(i_cdev) container_of(i_cdev, struct rpmsg_eptdev, cdev)
+
+#define dev_to_ctrldev(dev) container_of(dev, struct rpmsg_ctrldev, dev)
+#define cdev_to_ctrldev(i_cdev) container_of(i_cdev, struct rpmsg_ctrldev,
cdev)
+
+struct rpmsg_ctrldev {
+ struct rpmsg_device *rpdev;
+ struct cdev cdev;
+ struct device dev;
+};
+
+struct rpmsg_eptdev {
+ struct device dev;
+ struct cdev cdev;
+
+ struct rpmsg_device *rpdev;
+ struct rpmsg_channel_info chinfo;
+
+ struct mutex e
Re: [PATCH] scripts/coccicheck: Update reference for the corresponding documentation
On Fri, Oct 07, 2016 at 08:30:48PM +0200, Julia Lawall wrote:
>
>
> On Fri, 7 Oct 2016, SF Markus Elfring wrote:
>
> > From: Markus Elfring
> > Date: Fri, 7 Oct 2016 16:06:15 +0200
> >
> > Use the current name (in a comment at the beginning of this script) for
> > the file which was converted to the documentation format "reStructuredText"
> > in August 2016.
> >
> > Fixes: 4b9033a33494ec9154d63e706e9e47f7eb3fd59e ("docs: sphinxify
> > coccinelle.txt and add it to dev-tools")
> > Signed-off-by: Markus Elfring
>
> Acked-by: Julia Lawall
Applied to kbuild.git#misc, thanks.
Michal
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v11 2/4] drm: Add API for capturing frame CRCs
Hello, I have been able to test it on my setup and, after implementing set_crc_source function, I have crc/data and crc/control entries for each of my crtc. "cat /sys/kernel/debug/dri/0/crtc-0/crc/data" is blocking but I'm really sure of my driver implementation... Anyway you could add my ack on this patch Regards, Benjamin 2016-10-10 15:12 GMT+02:00 Emil Velikov : > On 6 October 2016 at 16:21, Tomeu Vizoso wrote: >> Adds files and directories to debugfs for controlling and reading frame >> CRCs, per CRTC: >> >> dri/0/crtc-0/crc >> dri/0/crtc-0/crc/control >> dri/0/crtc-0/crc/data >> >> Drivers can implement the set_crc_source callback() in drm_crtc_funcs to >> start and stop generating frame CRCs and can add entries to the output >> by calling drm_crtc_add_crc_entry. >> >> v2: >> - Lots of good fixes suggested by Thierry. >> - Added documentation. >> - Changed the debugfs layout. >> - Moved to allocate the entries circular queue once when frame >> generation gets enabled for the first time. >> v3: >> - Use the control file just to select the source, and start and stop >> capture when the data file is opened and closed, respectively. >> - Make variable the number of CRC values per entry, per source. >> - Allocate entries queue each time we start capturing as now there >> isn't a fixed number of CRC values per entry. >> - Store the frame counter in the data file as a 8-digit hex number. >> - For sources that cannot provide useful frame numbers, place >> in the frame field. >> >> v4: >> - Build only if CONFIG_DEBUG_FS is enabled. >> - Use memdup_user_nul. >> - Consolidate calculation of the size of an entry in a helper. >> - Add 0x prefix to hex numbers in the data file. >> - Remove unnecessary snprintf and strlen usage in read callback. >> >> v5: >> - Made the crcs array in drm_crtc_crc_entry fixed-size >> - Lots of other smaller improvements suggested by Emil Velikov >> >> v7: >> - Move definition of drm_debugfs_crtc_crc_add to drm_internal.h >> >> v8: >> - Call debugfs_remove_recursive when we fail to create the minor >> device >> >> v9: >> - Register the debugfs directory for a crtc from >> drm_crtc_register_all() >> >> v10: >> - Don't let debugfs failures interrupt CRTC registration (Emil >> Velikov) >> >> v11: >> - Remove extra brace that broke compilation. Sorry! >> >> Signed-off-by: Tomeu Vizoso > > Reviewed-by: Emil Velikov > > Emil > ___ > dri-devel mailing list > dri-de...@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Benjamin Gaignard Graphic Study Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 8/8] Input: elan_i2c - add Host Notify support
On Oct 10 2016 or thereabouts, Dmitry Torokhov wrote:
> Hi Benjamin,
>
> On Mon, Oct 10, 2016 at 9:42 AM, Benjamin Tissoires
> wrote:
> > The Thinkpad series 13 uses Host Notify to report the interrupt.
> > Add elan_smb_alert() to handle those interrupts and disable the irq
> > handling on this case.
> >
> > Signed-off-by: Benjamin Tissoires
> >
>
> Why do we have to do this in the driver instead of having I2C core set
> it up for us? I expect we'd be repeating this block of code for every
> driver that has an option of using SMbus notify.
I didn't want to assign blindly an IRQ for Host Notify because it's a
device (as I2C client) feature. Not all SMBus clients on the Host Notify
capable bus are capable of Host Notify, so I thought it was the
responsibility of the driver to assign it.
However, I can see your point, though I'd need some inputs (and I'll
have to resend the series as the Intel bot showed me 2 mistakes).
So, if i2c-core gets to assign itself the IRQ for Host Notify, do we:
1) assign an IRQ to any SMBus device on a Host Notify capable adapter
that doesn't have a valid provided IRQ?
2) have a new field in struct i2c_board_info that explicitly requires
Host Notify as an IRQ?
3) do not touch anything in i2c_core, let the caller of i2c_new_device
fill in the irq by a call to
i2c_smbus_host_notify_to_irq(adapter, address)?
1) has the advantage of being transparent for everybody, except we will
provide IRQs to devices that don't have one (this can be ignored), but
this may also lead to errors when IRQ is not correctly set by the caller
where it should be, and the driver/developer doesn't understand why it
is never triggered.
2) is a nice compromise, but we will need some OF binding, add some work
in for the callers of i2c_new_device() and will not work nicely with
sysfs instantiated i2c devices (the new_device sysfs entry). The sysfs
could be solved by adding some new address namespace, but that doesn't
make sense I think
3) requires less changes in i2c_core but it's going to be even harder
to add a device through sysfs that is Host Notify capable given that we
can't specify the IRQ.
After thinking a bit, I think I'd lean toward 1), but I am open to other
options as well.
Cheers,
Benjamin
>
> Thanks!
>
> > ---
> >
> > new in v4 (was submitted on linux-input with the .alert callback)
> > ---
> > drivers/input/mouse/elan_i2c_core.c | 15 +++
> > 1 file changed, 15 insertions(+)
> >
> > diff --git a/drivers/input/mouse/elan_i2c_core.c
> > b/drivers/input/mouse/elan_i2c_core.c
> > index 6f16eb4..4aaac5d 100644
> > --- a/drivers/input/mouse/elan_i2c_core.c
> > +++ b/drivers/input/mouse/elan_i2c_core.c
> > @@ -1040,6 +1040,21 @@ static int elan_probe(struct i2c_client *client,
> > I2C_FUNC_SMBUS_BLOCK_DATA |
> > I2C_FUNC_SMBUS_I2C_BLOCK)) {
> > transport_ops = &elan_smbus_ops;
> > +
> > + if (!irq) {
> > + if (!i2c_check_functionality(client->adapter,
> > + I2C_FUNC_SMBUS_HOST_NOTIFY)) {
> > + dev_err(dev, "no Host Notify support\n");
> > + return -ENODEV;
> > + }
> > +
> > + irq = i2c_smbus_host_notify_to_irq(client);
> > + if (irq < 0) {
> > + dev_err(dev,
> > + "Unable to request a Host Notify
> > IRQ.\n");
> > + return irq;
> > + }
> > + }
> > } else {
> > dev_err(dev, "not a supported I2C/SMBus adapter\n");
> > return -EIO;
> > --
> > 2.7.4
> >
>
>
>
> --
> Dmitry
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts
Em Tue, 11 Oct 2016 09:26:48 +0200 Markus Heiser escreveu: > Am 07.10.2016 um 07:56 schrieb Jani Nikula : > > > On Thu, 06 Oct 2016, Mauro Carvalho Chehab wrote: > >> Em Thu, 06 Oct 2016 17:21:36 +0300 > >> Jani Nikula escreveu: > >>> We've seen what happens when we make it easy to add random scripts to > >>> build documentation. We've worked hard to get rid of that. In my books, > >>> one of the bigger points in favor of Sphinx over AsciiDoc(tor) was > >>> getting rid of all the hacks required in the build. Things that broke in > >>> subtle ways. > >> > >> I really can't see what scripts it get rids. > > > > Really? You don't see why the DocBook build was so fragile and difficult > > to maintain? That scares me a bit, because then you will not have > > learned why we should at all costs avoid adding random scripts to > > produce documentation. > > For me, disassembling the DocBok build was hard and bothersome, I don't > want this back. > > IMO: old hats are productive with perl and they won't adapt another > interpreter language (like python) for scripting. > > This series -- the kernel-cmd -- directive avoid that they build > fragile and difficult to maintain Makefile constructs, calling their > perl scripts. > > Am 06.10.2016 um 16:21 schrieb Jani Nikula : > > > This is connected to the above: keeping documentation buildable with > > sphinx-build directly will force you to avoid the Makefile hacks. > > > Thats why I think, that the kernel-cmd directive is a more *straight- > forward* solution, helps to **avoid** complexity while not everyone > has to script in python ... > > > Case in point, parse-headers.pl was added for a specific need of media > > documentation, and for the life of me I can't figure out by reading the > > script what good, if any, it would be for gpu documentation. I call > > *that* unmaintainable. > > > If one adds a script like parse-headers.pl to the Documentation/sphinx > folder, he/she also has to add a documentation to the kernel-documentation.rst > > If the kernel-cmd directive gets acked, I will add a description to > kernel-documentation.rst and I request Mauro to document the parse-headers.pl > also. I can write documentation for parse-headers.pl, either as a --help/--man option or at some ReST file (or both). I'll add this to my mental TODO list. - With regards to Sphinx x DocBook, in terms of functionality, Sphinx is an improvement, as we can now use the same markup for everything, and cross-reference all documents. Unfortunately, it has less functionality than DocBook, and requires more magic to work. However, there are costs to pay on using a Python script like Sphinx. I won't mention again the issues with Python itself and its unstable API, but, instead, focus on Sphinx script itself. First of all, installing packages for Sphinx script to work is a lot more complex, specially for the PDF output, as the LaTeX requirements are very distribution specific, as some distributions package each LaTeX extension as optional packages, and the required extensions used by the Sphinx script are not documented. Also, the Sphinx script and its build logic is a lot more fragile than the Makefile/xmlto that we use on DocBook, and this has nothing to do with adding extra perl/python scripts. While it is clean for html output, it is very dirty when producing a PDF output. It starts by generating its own Makefile for PDF builds, at the output directory, with we have little control on it. Also, it seems that almost all books will need hacks to produce proper PDF, as neither ReST or Sphinx extensions currently have proper support to adjust things provided on DocBook, like setting page properties, enabling image/table scaling, auto-numbering images/tables/examples or changing page orientation in the middle of a document. The biggest issue I found is related to table outputs in PDF format, as it does a very poor job adjusting table margins to fit inside the paper margins. Also, the auto-generated TOC index on PDF doesn't match the numeration of the HTML output. Currently, I didn't find any solution for the latter issue. As Sphinx markup doesn't have any way to tell how the output would be formatted, a lot of magic is required at Sphinx conf.py for PDF output to start working. Worse than that, several tables require extra tags for PDF output, specifying the column sizes, and forcing them to be handled as longtables[1]. Also, if the table is too big, the rst files require raw latex macros/code before/after such tables, in order for them to fit inside a paper page - either by changing their orientation or enabling auto-scale, if the table is not a longtable. Currently, no way to tell Sphinx to enable auto-scale on big tables. So, in practice, it means that Sphinx build is a house of cards, at least for PDF output, as every new book should be tested if it will produce a proper PDF output, and add extra hacks inside the rst files to fix them, whe
Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts
On Tue, 11 Oct 2016, Mauro Carvalho Chehab wrote: > Em Tue, 11 Oct 2016 09:26:48 +0200 > Markus Heiser escreveu: > >> Am 07.10.2016 um 07:56 schrieb Jani Nikula : >> >> > On Thu, 06 Oct 2016, Mauro Carvalho Chehab wrote: >> >> Em Thu, 06 Oct 2016 17:21:36 +0300 >> >> Jani Nikula escreveu: >> >>> We've seen what happens when we make it easy to add random scripts to >> >>> build documentation. We've worked hard to get rid of that. In my books, >> >>> one of the bigger points in favor of Sphinx over AsciiDoc(tor) was >> >>> getting rid of all the hacks required in the build. Things that broke in >> >>> subtle ways. >> >> >> >> I really can't see what scripts it get rids. >> > >> > Really? You don't see why the DocBook build was so fragile and difficult >> > to maintain? That scares me a bit, because then you will not have >> > learned why we should at all costs avoid adding random scripts to >> > produce documentation. >> >> For me, disassembling the DocBok build was hard and bothersome, I don't >> want this back. >> >> IMO: old hats are productive with perl and they won't adapt another >> interpreter language (like python) for scripting. >> >> This series -- the kernel-cmd -- directive avoid that they build >> fragile and difficult to maintain Makefile constructs, calling their >> perl scripts. >> >> Am 06.10.2016 um 16:21 schrieb Jani Nikula : >> >> > This is connected to the above: keeping documentation buildable with >> > sphinx-build directly will force you to avoid the Makefile hacks. >> >> >> Thats why I think, that the kernel-cmd directive is a more *straight- >> forward* solution, helps to **avoid** complexity while not everyone >> has to script in python ... >> >> > Case in point, parse-headers.pl was added for a specific need of media >> > documentation, and for the life of me I can't figure out by reading the >> > script what good, if any, it would be for gpu documentation. I call >> > *that* unmaintainable. >> >> >> If one adds a script like parse-headers.pl to the Documentation/sphinx >> folder, he/she also has to add a documentation to the >> kernel-documentation.rst >> >> If the kernel-cmd directive gets acked, I will add a description to >> kernel-documentation.rst and I request Mauro to document the parse-headers.pl >> also. > > I can write documentation for parse-headers.pl, either as a --help/--man > option or at some ReST file (or both). I'll add this to my mental TODO > list. Thanks, documentation will help everyone else evaluate whether parse-headers.pl is only useful for some corner case in media docs, or perhaps more generally useful. Currently, it's hard to tell. Anyway, documentation does not change my view on adding such scripts. As I've said, I think they will make the documentation build more difficult to maintain. They are likely to become special purpose hacks for corner cases across documentation. The rest of what you say is unrelated to the patches at hand. BR, Jani. > > - > > With regards to Sphinx x DocBook, in terms of functionality, Sphinx > is an improvement, as we can now use the same markup for everything, > and cross-reference all documents. Unfortunately, it has less > functionality than DocBook, and requires more magic to work. > > However, there are costs to pay on using a Python script like Sphinx. > I won't mention again the issues with Python itself and its unstable > API, but, instead, focus on Sphinx script itself. > > First of all, installing packages for Sphinx script to work is a lot > more complex, specially for the PDF output, as the LaTeX requirements are > very distribution specific, as some distributions package each LaTeX > extension as optional packages, and the required extensions used by > the Sphinx script are not documented. > > Also, the Sphinx script and its build logic is a lot more fragile than > the Makefile/xmlto that we use on DocBook, and this has nothing to do > with adding extra perl/python scripts. > > While it is clean for html output, it is very dirty when producing > a PDF output. > > It starts by generating its own Makefile for PDF builds, at the output > directory, with we have little control on it. > > Also, it seems that almost all books will need hacks to produce proper PDF, > as neither ReST or Sphinx extensions currently have proper support to adjust > things provided on DocBook, like setting page properties, enabling > image/table scaling, auto-numbering images/tables/examples or changing page > orientation in the middle of a document. > > The biggest issue I found is related to table outputs in PDF format, as > it does a very poor job adjusting table margins to fit inside the paper > margins. Also, the auto-generated TOC index on PDF doesn't match the > numeration of the HTML output. Currently, I didn't find any solution > for the latter issue. > > As Sphinx markup doesn't have any way to tell how the output would be > formatted, a lot of magic is required at Sphinx conf.py for
Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts
Am 11.10.2016 um 17:34 schrieb Jani Nikula : > On Tue, 11 Oct 2016, Mauro Carvalho Chehab wrote: >> Em Tue, 11 Oct 2016 09:26:48 +0200 >> Markus Heiser escreveu: >> >>> Am 07.10.2016 um 07:56 schrieb Jani Nikula : >>> On Thu, 06 Oct 2016, Mauro Carvalho Chehab wrote: > Em Thu, 06 Oct 2016 17:21:36 +0300 > Jani Nikula escreveu: >> We've seen what happens when we make it easy to add random scripts to >> build documentation. We've worked hard to get rid of that. In my books, >> one of the bigger points in favor of Sphinx over AsciiDoc(tor) was >> getting rid of all the hacks required in the build. Things that broke in >> subtle ways. > > I really can't see what scripts it get rids. Really? You don't see why the DocBook build was so fragile and difficult to maintain? That scares me a bit, because then you will not have learned why we should at all costs avoid adding random scripts to produce documentation. >>> >>> For me, disassembling the DocBok build was hard and bothersome, I don't >>> want this back. >>> >>> IMO: old hats are productive with perl and they won't adapt another >>> interpreter language (like python) for scripting. >>> >>> This series -- the kernel-cmd -- directive avoid that they build >>> fragile and difficult to maintain Makefile constructs, calling their >>> perl scripts. >>> >>> Am 06.10.2016 um 16:21 schrieb Jani Nikula : >>> This is connected to the above: keeping documentation buildable with sphinx-build directly will force you to avoid the Makefile hacks. >>> >>> >>> Thats why I think, that the kernel-cmd directive is a more *straight- >>> forward* solution, helps to **avoid** complexity while not everyone >>> has to script in python ... >>> Case in point, parse-headers.pl was added for a specific need of media documentation, and for the life of me I can't figure out by reading the script what good, if any, it would be for gpu documentation. I call *that* unmaintainable. >>> >>> >>> If one adds a script like parse-headers.pl to the Documentation/sphinx >>> folder, he/she also has to add a documentation to the >>> kernel-documentation.rst >>> >>> If the kernel-cmd directive gets acked, I will add a description to >>> kernel-documentation.rst and I request Mauro to document the >>> parse-headers.pl >>> also. >> >> I can write documentation for parse-headers.pl, either as a --help/--man >> option or at some ReST file (or both). I'll add this to my mental TODO >> list. > > Thanks, documentation will help everyone else evaluate whether > parse-headers.pl is only useful for some corner case in media docs, or > perhaps more generally useful. Currently, it's hard to tell. > > Anyway, documentation does not change my view on adding such scripts. As > I've said, I think they will make the documentation build more difficult > to maintain. They are likely to become special purpose hacks for corner > cases across documentation. Hmm, why not generating reST content by (Perl) scripts? From my POV, the scripts/kernel-doc is such a script and parse-headers.pl is just another. The only difference of both is, that kernel-doc has its own integration (directive) while kernel-cmd is a simple solution to call scripts (e.g. parse-headers.pl) within sphinx-build. Joking: the kernel-doc directive could replaced by the kernel-cmd directive ;-) > The rest of what you say is unrelated to the patches at hand. I think Mauro want's to address your (justifiable) fear about complexity and hacks. IMO he says (by examples); "there are a lot of other hard to maintain hacks required, especially when it comes to build PDF". IMO, complexity is not reduced by prohibit scripts, it is ongoing job of the maintainers to observe. Anyway, these are only my 2cent. I'am interested in what Jon says in general about using (Perl) scripts to generate reST content. --Markus-- -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/5] rpmsg: Driver for user space endpoint interface
On Tue 11 Oct 00:46 PDT 2016, loic pallardy wrote: > On 10/08/2016 06:23 AM, Bjorn Andersson wrote: [..] > >diff --git a/drivers/rpmsg/Makefile b/drivers/rpmsg/Makefile > >index ae9c9132cf76..5daf1209b77d 100644 > >--- a/drivers/rpmsg/Makefile > >+++ b/drivers/rpmsg/Makefile > >@@ -1,3 +1,3 @@ > >-obj-$(CONFIG_RPMSG) += rpmsg_core.o > >+obj-$(CONFIG_RPMSG) += rpmsg_core.o rpmsg_char.o > Hi Bjorn, > > Could you please create a dedicated Kconfig entry for this new interface? > This should be an option like i2C_dev. > No problem, I'll do that. Regards, Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/4] reST-directive kernel-cmd / include contentent from scripts
Em Tue, 11 Oct 2016 18:06:46 +0200 Markus Heiser escreveu: > Am 11.10.2016 um 17:34 schrieb Jani Nikula : > > > On Tue, 11 Oct 2016, Mauro Carvalho Chehab wrote: > >> Em Tue, 11 Oct 2016 09:26:48 +0200 > >> Markus Heiser escreveu: > >> > >>> Am 07.10.2016 um 07:56 schrieb Jani Nikula : > >>> > On Thu, 06 Oct 2016, Mauro Carvalho Chehab > wrote: > > Em Thu, 06 Oct 2016 17:21:36 +0300 > > Jani Nikula escreveu: > >> We've seen what happens when we make it easy to add random scripts to > >> build documentation. We've worked hard to get rid of that. In my books, > >> one of the bigger points in favor of Sphinx over AsciiDoc(tor) was > >> getting rid of all the hacks required in the build. Things that broke > >> in > >> subtle ways. > > > > I really can't see what scripts it get rids. > > Really? You don't see why the DocBook build was so fragile and difficult > to maintain? That scares me a bit, because then you will not have > learned why we should at all costs avoid adding random scripts to > produce documentation. > >>> > >>> For me, disassembling the DocBok build was hard and bothersome, I don't > >>> want this back. > >>> > >>> IMO: old hats are productive with perl and they won't adapt another > >>> interpreter language (like python) for scripting. > >>> > >>> This series -- the kernel-cmd -- directive avoid that they build > >>> fragile and difficult to maintain Makefile constructs, calling their > >>> perl scripts. > >>> > >>> Am 06.10.2016 um 16:21 schrieb Jani Nikula : > >>> > This is connected to the above: keeping documentation buildable with > sphinx-build directly will force you to avoid the Makefile hacks. > >>> > >>> > >>> Thats why I think, that the kernel-cmd directive is a more *straight- > >>> forward* solution, helps to **avoid** complexity while not everyone > >>> has to script in python ... > >>> > Case in point, parse-headers.pl was added for a specific need of media > documentation, and for the life of me I can't figure out by reading the > script what good, if any, it would be for gpu documentation. I call > *that* unmaintainable. > >>> > >>> > >>> If one adds a script like parse-headers.pl to the Documentation/sphinx > >>> folder, he/she also has to add a documentation to the > >>> kernel-documentation.rst > >>> > >>> If the kernel-cmd directive gets acked, I will add a description to > >>> kernel-documentation.rst and I request Mauro to document the > >>> parse-headers.pl > >>> also. > >> > >> I can write documentation for parse-headers.pl, either as a --help/--man > >> option or at some ReST file (or both). I'll add this to my mental TODO > >> list. > > > > Thanks, documentation will help everyone else evaluate whether > > parse-headers.pl is only useful for some corner case in media docs, or > > perhaps more generally useful. Currently, it's hard to tell. > > > > Anyway, documentation does not change my view on adding such scripts. As > > I've said, I think they will make the documentation build more difficult > > to maintain. They are likely to become special purpose hacks for corner > > cases across documentation. > > Hmm, why not generating reST content by (Perl) scripts? From my POV, > the scripts/kernel-doc is such a script and parse-headers.pl > is just another. And Sphinx is a third one - or, actually, a set of scripts, as each extension is also a script ;) > The only difference of both is, that kernel-doc > has its own integration (directive) while kernel-cmd is a simple > solution to call scripts (e.g. parse-headers.pl) within sphinx-build. > > Joking: the kernel-doc directive could replaced by > the kernel-cmd directive ;-) I'm actually OK with either strategy - although it sounds easier to maintain if we have a single extension to run an external script - including kernel-doc - specially if the Sphinx extension API and/or Python changes in the future in a non-backward compatible way. > > The rest of what you say is unrelated to the patches at hand. > > I think Mauro want's to address your (justifiable) fear about > complexity and hacks. IMO he says (by examples); "there are a lot of > other hard to maintain hacks required, especially when it comes > to build PDF". > > IMO, complexity is not reduced by prohibit scripts, it is > ongoing job of the maintainers to observe. Yes, that's exactly my point. IMO, not allowing scripts actually increase complexity, as we'll need Makefile rules to generate rst files, if we won't allow doing that via perl/python scripts. If we allow such scripts (and we do since day zero, due to kernel-doc), then there are 3 options: 1) use a single python script to run the scripts needed in the build process (e. g. merging kernel-cmd extension upstream); 2) use a dedicated python script for every non-phyton script; 3) use only python scripts to
Re: [PATCH v4 8/8] Input: elan_i2c - add Host Notify support
On Tue, Oct 11, 2016 at 04:20:52PM +0200, Benjamin Tissoires wrote: > On Oct 10 2016 or thereabouts, Dmitry Torokhov wrote: > > Hi Benjamin, > > > > On Mon, Oct 10, 2016 at 9:42 AM, Benjamin Tissoires > > wrote: > > > The Thinkpad series 13 uses Host Notify to report the interrupt. > > > Add elan_smb_alert() to handle those interrupts and disable the irq > > > handling on this case. > > > > > > Signed-off-by: Benjamin Tissoires > > > > > > > Why do we have to do this in the driver instead of having I2C core set > > it up for us? I expect we'd be repeating this block of code for every > > driver that has an option of using SMbus notify. > > I didn't want to assign blindly an IRQ for Host Notify because it's a > device (as I2C client) feature. Not all SMBus clients on the Host Notify > capable bus are capable of Host Notify, so I thought it was the > responsibility of the driver to assign it. Right, it is device's feature and it is up to the driver to decide if it should be using interrupt-driven model or not. From I2C core I'd try the following logic: if client->irq is not already set up and ACPI/DT/platform data does not have any mention of IERQ and device is on Host Notify capable bus then assign IRQ and let the dirver decide if it wants to use it or not. Having client->irq present does not mean that we have to use it. Driver knows the device best. > > However, I can see your point, though I'd need some inputs (and I'll > have to resend the series as the Intel bot showed me 2 mistakes). > > So, if i2c-core gets to assign itself the IRQ for Host Notify, do we: > 1) assign an IRQ to any SMBus device on a Host Notify capable adapter >that doesn't have a valid provided IRQ? > 2) have a new field in struct i2c_board_info that explicitly requires >Host Notify as an IRQ? > 3) do not touch anything in i2c_core, let the caller of i2c_new_device >fill in the irq by a call to >i2c_smbus_host_notify_to_irq(adapter, address)? > > 1) has the advantage of being transparent for everybody, except we will > provide IRQs to devices that don't have one (this can be ignored), but > this may also lead to errors when IRQ is not correctly set by the caller > where it should be, and the driver/developer doesn't understand why it > is never triggered. > > 2) is a nice compromise, but we will need some OF binding, add some work > in for the callers of i2c_new_device() and will not work nicely with > sysfs instantiated i2c devices (the new_device sysfs entry). The sysfs > could be solved by adding some new address namespace, but that doesn't > make sense I think > > 3) requires less changes in i2c_core but it's going to be even harder > to add a device through sysfs that is Host Notify capable given that we > can't specify the IRQ. > > After thinking a bit, I think I'd lean toward 1), but I am open to other > options as well. Yes, I think #1 is what we should do (but ultimately it is up to Wolfram to decide). Thanks. -- Dmitry -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH-tip v4 02/10] locking/rwsem: Stop active read lock ASAP
On Mon, Oct 10, 2016 at 02:34:34AM -0700, Christoph Hellwig wrote: > On Mon, Oct 10, 2016 at 05:07:45PM +1100, Dave Chinner wrote: > > > > *However*, the DAX IO path locking in XFS has changed in 4.9-rc1 to > > > > match the buffered IO single writer POSIX semantics - the test is a > > > > bad test based on the fact it exercised a path that is under heavy > > > > development and so can't be used as a regression test across > > > > multiple kernels. > > > > > > That being said - I wonder if we should allow the shared lock on DAX > > > files IFF the user is specifying O_DIRECT in the open mode.. > > > > It should do - if it doesn't then we screwed up the IO path > > selection logic in XFS and we'll need to fix it. > > Depends on your defintion of "we". The DAX code has always abused the > direct I/O path, and that abuse is ingrained in the VFS path in a way that > we can't easily undo it in XFS, e.g. take a look at io_is_direct and > iocb_flags in include/linux/fs.h, which ensure that DAX I/O will always > appear as IOCB_DIRECT to the fs. Um, I seem to have completely missed that change - when did that happen and why? Oh, it was part of the misguided "enable DAX on block devices" changes - it was supposed to fix a problem with block device access using buffered IO instead of DAX (commit 65f87ee71852 "fs, block: force direct-I/O for dax-enabled block devices")). The original block device DAX code was reverted soon after this because it was badly flawed, but this change was not removed at the same time (probably because it was forgotton about). Hence I'd suggest that DAX check in io_is_direct() should be removed ASAP; the filesystems don't need it as they check the inode DAX state directly, and the code it "fixed" is no longer in the tree. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
