Re: [PATCH 1/1 v4] hwmon: add support for Sensirion SHT3x sensors

[Pascal Sachs]

Hi Guenter

I want to thank you again for the fast and detailed code review.
I really appreciate it.

Am 30.05.2016 um 17:45 schrieb Guenter Roeck:

Hi Pascal,

On 05/30/2016 07:46 AM, Pascal Sachs wrote:

From: David Frey 

This driver implements support for the Sensirion SHT3x-DIS chip,
a humidity and temperature sensor. Temperature is measured
in degrees celsius, relative humidity is expressed as a percentage.
In the sysfs interface, all values are scaled by 1000,
i.e. the value for 31.5 degrees celsius is 31500.



Getting there. Mostly nitpicks this time.


Signed-off-by: Pascal Sachs 
---
Patch was generated against kernel v4.7-rc1


A changelog would be useful.

Sure, I will add one with the next submission




  Documentation/hwmon/sht3x   | 72 
  drivers/hwmon/Kconfig   |  11 +
  drivers/hwmon/Makefile  |   1 +
  drivers/hwmon/sht3x.c   | 724 


  include/linux/platform_data/sht3x.h |  25 ++
  5 files changed, 833 insertions(+)
  create mode 100644 Documentation/hwmon/sht3x
  create mode 100644 drivers/hwmon/sht3x.c
  create mode 100644 include/linux/platform_data/sht3x.h

diff --git a/Documentation/hwmon/sht3x b/Documentation/hwmon/sht3x
new file mode 100644
index 000..f5aa633
--- /dev/null
+++ b/Documentation/hwmon/sht3x
@@ -0,0 +1,72 @@
+Kernel driver sht3x
+===
+
+Supported chips:
+  * Sensirion SHT3x-DIS
+Prefix: 'sht3x'
+Addresses scanned: none
+Datasheet: 
http://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/Humidity/Sensirion_Humidity_Datasheet_SHT3x_DIS.pdf

+
+Author:
+  David Frey 
+  Pascal Sachs 
+
+Description
+---
+
+This driver implements support for the Sensirion SHT3x-DIS chip, a 
humidity
+and temperature sensor. Temperature is measured in degrees celsius, 
relative
+humidity is expressed as a percentage. In the sysfs interface, all 
values are

+scaled by 1000, i.e. the value for 31.5 degrees celsius is 31500.
+
+The device communicates with the I2C protocol. Sensors can have the I2C
+addresses 0x44 or 0x45, depending on the wiring. See
+Documentation/i2c/instantiating-devices for methods to instantiate 
the device.

+
+There are two options configurable by means of sht3x_platform_data:
+1. blocking (pull the I2C clock line down while performing the 
measurement) or
+   non-blocking mode. Blocking mode will guarantee the fastest 
result but
+   the I2C bus will be busy during that time. By default, 
non-blocking mode
+   is used. Make sure clock-stretching works properly on your device 
if you

+   want to use blocking mode.
+2. high or low accuracy. High accuracy is used by default and using 
it is

+   strongly recommended.
+
+The sht3x sensor supports a single shot mode as well as 5 periodic 
measure
+modes, which can be controlled with the update_interval sysfs 
interface.

+The allowed update_interval in milliseconds are as follows:
+  * 0   single shot mode
+  *  2000   0.5 Hz periodic measurement
+  *  1000   1   Hz periodic measurement
+  *   500   2   Hz periodic measurement
+  *   250   4   Hz periodic measurement
+  *   100  10   Hz periodic measurement
+
+In the periodic measure mode, the sensor automatically triggers a 
measurement
+with the configured update interval on the chip. When a temperature 
or humidity
+reading exceeds the configured limits, the alert attribute is set to 
1 and

+the alert pin on the sensor is set to high.
+When the temperature and humidity readings move back between the 
hysteresis
+values, the alert bit is set to 0 and the alert pin on the sensor is 
set to

+low.
+
+sysfs-Interface
+---
+
+temp1_input:temperature input
+humidity1_input:humidity input
+temp1_max:  temperature max value
+temp1_max_hyst: temperature hysteresis value for max limit
+humidity1_max:  humidity max value
+humidity1_max_hyst: humidity hysteresis value for max limit
+temp1_min:  temperature min value
+temp1_min_hyst: temperature hysteresis value for min limit
+humidity1_min:  humidity min value
+humidity1_min_hyst: humidity hysteresis value for min limit
+temp1_alarm:alarm flag is set to 1 if the temperature is 
outside the
+configured limits. Alarm only works in periodic 
measure mode
+humidity1_alarm:alarm flag is set to 1 if the humidity is 
outside the
+configured limits. Alarm only works in periodic 
measure mode
+update_interval:update interval, 0 for single shot, interval in 
msec
+for periodic measurement. If the interval is not 
supported

+by the sensor, the next faster interval is chosen
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ff94007..e0be99a 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1265,6 +1265,17 @@ config SENSORS_SHT21
This driver can also be built as a module.  If so, the module
wil

Re: [PATCH 00/10] Documentation/Sphinx

[Markus Heiser]

Am 30.05.2016 um 22:05 schrieb Jani Nikula :

> On Mon, 30 May 2016, Markus Heiser  wrote:
>> Am 30.05.2016 um 16:46 schrieb Jani Nikula :
>>> I am not proposing to merge the documents that I've converted mostly as
>>> samples in the branch. I needed something to demonstrate the build is
>>> sane.
>> 
>>> The authors of the DocBook documents should make the conversions as they
>>> see fit, when they see fit, with the tools they see fit, probably with
>>> some manual work on top.
>> 
>> OK
> 
> To be clear, the "sphinx-for-docs-next" branch of [1], [2] is what I
> propose to merge at this time. There's the Sphinx configuration, kernel
> build integration, Sphinx kernel-doc extension, tons of kernel-doc
> updates, etc. There is no DocBook tmpl conversion; all of that is left
> to the authors (owners, maintainers) of the documents, but this enables
> them to focus on that part.
> 
> I was planning on sending out the patches after some feedback here.
> 
> [1] git://people.freedesktop.org/~jani/drm
> [2] https://cgit.freedesktop.org/~jani/drm/log/?h=sphinx-for-docs-next
> 
>> With DocBook, it was hard to separate a file into small chunks (see media for
>> how it is done). With Sphinx, it is common to split a document in small 
>> chunks 
>> (along parts, chapters, sections ...) Thats why I recommend chunking 
>> documents
>> (from the beginning).
> 
> Agreed, but up to the authors.
> 
>>> One of the goals was to have nice cross-referencing between the
>>> documents (e.g. from GPU to kernel or device driver API). And it works.
>> 
>> For this, Sphinx-doc brings intersphinx: 
>> http://www.sphinx-doc.org/en/stable/ext/intersphinx.html
> 
> If the kernel is split to several intersphinx "prefixes", we won't know
> the prefix of the link targets when we're generating the references in
> kernel-doc. Also, can be deferred to follow-up work if someone figures
> out the how.

It stands to reason that each book should be placed in a separate folder.
This simple role simplifies much, e.g. chunking, "prefixes" for the 
intersphinx, a place for images of this book .. etc. It is also the
base to have one sphinx-doc project (individual config set) for each book.

Please, place each (DocBook) reST-book at least into a separate folder.


>> I can't recommend to use rst2pdf (it is less maintained), use default
>> sphinx LaTeX toolchain.
> 
> I think we'll use whatever works, rst2pdf seemed to work for now, but we
> can change if needed.

The discussion in the past was dominated by the fear, that something
on the sphinx-doc could not be maintained in the future ... I don't
share theses fears, if needed, I also have no problem to repair or throw
my damaged toolchain away ;-)

>>> I find it totally unacceptable to require explicitly marking kernel-doc
>>> comments or source files as being reStructuredText.
>>> Note that it's all opt-in already. If you add a .rst file that includes
>>> kernel-doc via the kernel-doc extension, you better make sure the
>>> comments parse as reStructuredText and render nicely. I'm willing to do
>>> much of the job for all the things that I care about.
>> 
>> We have a different POV ... I try to build up a documentation project,
>> which could use all given kernel-doc markups without any change, where
>> reST is an "addition". Your approach is to fix kernel-doc comments 
>> if they are referred by a kernl-doc directive in a .rst document.
>> There is nothing wrong about your approach, but I try to build
>> a whole source code documentation like the one I started here: 
>> http://return42.github.io/sphkerneldoc/linux_src_doc/index.html
> 
> That looks nice, but I'll argue it would not be much worse even if you
> assumed it's all rst.

A superficial look on the HTML output may give the impression. But in
the log you will find tons of errors and warnings. My experience is,
that authors will not consult logs if there are tons of errors from the 
beginning, which carries a decrease in quality. IMO not a good starting 
point.

> The bigger point is, if you expect people to tag each source file or
> kernel-doc comment with "rst", you'll end up with a mess where some
> places have that tag, some not, but it's not conclusive about whether
> they actually *are* rst or not. (And you've had tons of patch churn to
> add those tags to get there.)

At the end, only sources which have been modified to reST need one
line (in the first lines) :

  /* parse-markup: reST */

which announce the reST markup in this file, normaly this needs
no additional patches, except the author forget to announce his
movement to reST ...

> The kernel-doc comments are written by humans who will screw it up
> anyway. (Apologies for the distrust, fellow developers, but I've been
> reading too many of your fine kernel-doc comments lately.) People will
> happily cargo cult rst and current kernel-doc and javadoc and doxygen
> and whatnot in a fruit salad. The only thing that will help in the end
> is keeping the rules simple and consistent and

Re: [PATCH 00/10] Documentation/Sphinx

[Daniel Vetter]

On Tue, May 31, 2016 at 9:27 AM, Markus Heiser
 wrote:
 I find it totally unacceptable to require explicitly marking kernel-doc
 comments or source files as being reStructuredText.
 Note that it's all opt-in already. If you add a .rst file that includes
 kernel-doc via the kernel-doc extension, you better make sure the
 comments parse as reStructuredText and render nicely. I'm willing to do
 much of the job for all the things that I care about.
>>>
>>> We have a different POV ... I try to build up a documentation project,
>>> which could use all given kernel-doc markups without any change, where
>>> reST is an "addition". Your approach is to fix kernel-doc comments
>>> if they are referred by a kernl-doc directive in a .rst document.
>>> There is nothing wrong about your approach, but I try to build
>>> a whole source code documentation like the one I started here:
>>> http://return42.github.io/sphkerneldoc/linux_src_doc/index.html
>>
>> That looks nice, but I'll argue it would not be much worse even if you
>> assumed it's all rst.
>
> A superficial look on the HTML output may give the impression. But in
> the log you will find tons of errors and warnings. My experience is,
> that authors will not consult logs if there are tons of errors from the
> beginning, which carries a decrease in quality. IMO not a good starting
> point.

0-day builds all docs, and checks for new warnings. Even in today's
gpu.tmpl build there's a massive pile of warnings, so yes developers
don't look. But 0-day does, and then developers look at the nice mails
from 0-day. It mostly works to keep out new fail I think.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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

[PATCH v2 2/2] Documentation/scsi: update scsi_eh.txt about ->host_failed

[Wei Fang]

Update the new concurrency rules of ->host_failed.

Signed-off-by: Wei Fang 
---
 Documentation/scsi/scsi_eh.txt |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/Documentation/scsi/scsi_eh.txt b/Documentation/scsi/scsi_eh.txt
index 8638f61..e6d0de2 100644
--- a/Documentation/scsi/scsi_eh.txt
+++ b/Documentation/scsi/scsi_eh.txt
@@ -252,7 +252,7 @@ scmd->allowed.
- set scmd->eh_eflags
- add scmd to shost->eh_cmd_q
- set SHOST_RECOVERY
-   - shost->host_failed++
+   - atomic_inc(&shost->host_failed)
 LOCKING: shost->host_lock
 
  2. EH starts
@@ -263,7 +263,7 @@ scmd->allowed.
 
  3. scmd recovered
 ACTION: scsi_eh_finish_cmd() is invoked to EH-finish scmd
-   - shost->host_failed--
+   - atomic_dec(&shost->host_failed)
- clear scmd->eh_eflags
- scsi_setup_cmd_retry()
- move from local eh_work_q to local eh_done_q
-- 
1.7.1

--
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

[PATCH v2 1/2] scsi: fix race between simultaneous decrements of ->host_failed

[Wei Fang]

sas_ata_strategy_handler() adds the works of the ata error handler
to system_unbound_wq. This workqueue asynchronously runs work items,
so the ata error handler will be performed concurrently on different
CPUs. In this case, ->host_failed will be decreased simultaneously in
scsi_eh_finish_cmd() on different CPUs, and become abnormal.

It will lead to permanently inequal between ->host_failed and
 ->host_busy, and scsi error handler thread won't become running.
IO errors after that won't be handled forever.

Use atomic type for ->host_failed to fix this race.

This fixes the problem introduced in
commit 50824d6c5657 ("[SCSI] libsas: async ata-eh").

Reviewed-by: Christoph Hellwig 
Signed-off-by: Wei Fang 
---
 drivers/ata/libata-eh.c |2 +-
 drivers/scsi/libsas/sas_scsi_host.c |5 +++--
 drivers/scsi/scsi.c |2 +-
 drivers/scsi/scsi_error.c   |   15 +--
 drivers/scsi/scsi_lib.c |3 ++-
 include/scsi/scsi_host.h|2 +-
 6 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 961acc7..a0e7612 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -606,7 +606,7 @@ void ata_scsi_error(struct Scsi_Host *host)
ata_scsi_port_error_handler(host, ap);
 
/* finish or retry handled scmd's and clean up */
-   WARN_ON(host->host_failed || !list_empty(&eh_work_q));
+   WARN_ON(atomic_read(&host->host_failed) || !list_empty(&eh_work_q));
 
DPRINTK("EXIT\n");
 }
diff --git a/drivers/scsi/libsas/sas_scsi_host.c 
b/drivers/scsi/libsas/sas_scsi_host.c
index 519dac4..8d74003 100644
--- a/drivers/scsi/libsas/sas_scsi_host.c
+++ b/drivers/scsi/libsas/sas_scsi_host.c
@@ -757,7 +757,8 @@ retry:
spin_unlock_irq(shost->host_lock);
 
SAS_DPRINTK("Enter %s busy: %d failed: %d\n",
-   __func__, atomic_read(&shost->host_busy), 
shost->host_failed);
+   __func__, atomic_read(&shost->host_busy),
+   atomic_read(&shost->host_failed));
/*
 * Deal with commands that still have SAS tasks (i.e. they didn't
 * complete via the normal sas_task completion mechanism),
@@ -800,7 +801,7 @@ out:
 
SAS_DPRINTK("--- Exit %s: busy: %d failed: %d tries: %d\n",
__func__, atomic_read(&shost->host_busy),
-   shost->host_failed, tries);
+   atomic_read(&shost->host_failed), tries);
 }
 
 enum blk_eh_timer_return sas_scsi_timed_out(struct scsi_cmnd *cmd)
diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
index 1deb6ad..7840915 100644
--- a/drivers/scsi/scsi.c
+++ b/drivers/scsi/scsi.c
@@ -527,7 +527,7 @@ void scsi_log_completion(struct scsi_cmnd *cmd, int 
disposition)
scmd_printk(KERN_INFO, cmd,
"scsi host busy %d failed %d\n",

atomic_read(&cmd->device->host->host_busy),
-   cmd->device->host->host_failed);
+   
atomic_read(&cmd->device->host->host_failed));
}
}
 }
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 984ddcb..f37666f 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -62,7 +62,8 @@ static int scsi_try_to_abort_cmd(struct scsi_host_template *,
 /* called with shost->host_lock held */
 void scsi_eh_wakeup(struct Scsi_Host *shost)
 {
-   if (atomic_read(&shost->host_busy) == shost->host_failed) {
+   if (atomic_read(&shost->host_busy) ==
+   atomic_read(&shost->host_failed)) {
trace_scsi_eh_wakeup(shost);
wake_up_process(shost->ehandler);
SCSI_LOG_ERROR_RECOVERY(5, shost_printk(KERN_INFO, shost,
@@ -250,7 +251,7 @@ int scsi_eh_scmd_add(struct scsi_cmnd *scmd, int eh_flag)
eh_flag &= ~SCSI_EH_CANCEL_CMD;
scmd->eh_eflags |= eh_flag;
list_add_tail(&scmd->eh_entry, &shost->eh_cmd_q);
-   shost->host_failed++;
+   atomic_inc(&shost->host_failed);
scsi_eh_wakeup(shost);
  out_unlock:
spin_unlock_irqrestore(shost->host_lock, flags);
@@ -1127,7 +1128,7 @@ static int scsi_eh_action(struct scsi_cmnd *scmd, int rtn)
  */
 void scsi_eh_finish_cmd(struct scsi_cmnd *scmd, struct list_head *done_q)
 {
-   scmd->device->host->host_failed--;
+   atomic_dec(&scmd->device->host->host_failed);
scmd->eh_eflags = 0;
list_move_tail(&scmd->eh_entry, done_q);
 }
@@ -2190,8 +2191,10 @@ int scsi_error_handler(void *data)
if (kthread_should_stop())
break;
 
-   if ((shost->host_failed == 0 && shost->host_eh_scheduled == 0) 
||
-   shost->host_failed != atomic_read(&shost->host_busy)) {
+   if ((atomic_read(&shost->host_failed) == 0 &&
+  

Re: [PATCH v6 0/4] i2c-smbus: add support for HOST NOTIFY

[Benjamin Tissoires]

Hi,

On Mar 16 2016 or thereabouts, Benjamin Tissoires wrote:
> Hi,
> 
> this is a quick respin of the series with the kbuild test bot fixes and the
> requested lm90 change.
> 
> Again, I think applying the RMI4 input driver needs the merge of the input 
> tree
> in master first, but having reviews on the Host Notify implementation would be
> good.


Well, RMI4 is now in master, and it's been 2 months and a half since this
v6. Thanks for everyone who send their acks, but I'd like to have a
review on the Host Notify implementation (Jean??).

We just had a new bug this week that shows that the fallback protocol we
use under Linux for Synaptics touchpad is buggy[1]. I really like to see
this moving forward so I'll send a v7 with the acks and tested by, but I
really would like to get Wolfram's or Jean's attention for the Host
notify part.

Cheers,
Benjamin

[1] https://bugs.freedesktop.org/show_bug.cgi?id=96267

> 
> Cheers,
> Benjamin
> 
> Benjamin Tissoires (4):
>   i2c: add a protocol parameter to the alert callback
>   i2c-smbus: add SMBus Host Notify support
>   i2c: i801: add support of Host Notify
>   Input: synaptics-rmi4 - add SMBus support
> 
>  Documentation/i2c/smbus-protocol |   3 +
>  drivers/char/ipmi/ipmi_ssif.c|   6 +-
>  drivers/hwmon/lm90.c |   6 +-
>  drivers/i2c/busses/Kconfig   |   1 +
>  drivers/i2c/busses/i2c-i801.c|  85 +++-
>  drivers/i2c/i2c-smbus.c  | 112 ++-
>  drivers/input/rmi4/Kconfig   |  12 ++
>  drivers/input/rmi4/Makefile  |   1 +
>  drivers/input/rmi4/rmi_bus.h |  12 ++
>  drivers/input/rmi4/rmi_smbus.c   | 416 
> +++
>  include/linux/i2c-smbus.h|  44 +
>  include/linux/i2c.h  |  10 +-
>  include/uapi/linux/i2c.h |   1 +
>  13 files changed, 699 insertions(+), 10 deletions(-)
>  create mode 100644 drivers/input/rmi4/rmi_smbus.c
> 
> -- 
> 2.5.0
> 
--
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 00/10] Documentation/Sphinx

[Markus Heiser]

Am 31.05.2016 um 10:07 schrieb Daniel Vetter :

> On Tue, May 31, 2016 at 9:27 AM, Markus Heiser
>  wrote:
> I find it totally unacceptable to require explicitly marking kernel-doc
> comments or source files as being reStructuredText.
> Note that it's all opt-in already. If you add a .rst file that includes
> kernel-doc via the kernel-doc extension, you better make sure the
> comments parse as reStructuredText and render nicely. I'm willing to do
> much of the job for all the things that I care about.
 
 We have a different POV ... I try to build up a documentation project,
 which could use all given kernel-doc markups without any change, where
 reST is an "addition". Your approach is to fix kernel-doc comments
 if they are referred by a kernl-doc directive in a .rst document.
 There is nothing wrong about your approach, but I try to build
 a whole source code documentation like the one I started here:
 http://return42.github.io/sphkerneldoc/linux_src_doc/index.html
>>> 
>>> That looks nice, but I'll argue it would not be much worse even if you
>>> assumed it's all rst.
>> 
>> A superficial look on the HTML output may give the impression. But in
>> the log you will find tons of errors and warnings. My experience is,
>> that authors will not consult logs if there are tons of errors from the
>> beginning, which carries a decrease in quality. IMO not a good starting
>> point.
> 
> 0-day builds all docs, and checks for new warnings. Even in today's
> gpu.tmpl build there's a massive pile of warnings, so yes developers
> don't look. But 0-day does, and then developers look at the nice mails
> from 0-day. It mostly works to keep out new fail I think.

In general, I'am not very happy with workarounds like this. IMO these
are workarounds are often, rewards bunglers and punish those with more work,
who want make thinks right. There might be situations where 0-day build
is the only/best solution. But *here* we are talking about one additional
comment line the author adds, when he modify his source comments from 
kernel-doc 
to reST markup .. IMO not very hard.

This one line helps the doc-builder to distinguish between *vintage* kernel-doc
comments and those with reST additions in.

With the announcement of the markup, we can use all existing kernel-doc
markups "as is" for building a complete src-code documentation, with
thousands of errors less in the log (experience from my POC). IMO a great
benefit ... given by just one additional comment line to distinguish between
vintage and reST ... 

BTW it's is not uncommon to announce the markup in projects with mixed 
markups in the source code comments.


 A few words about my point of view / my thought:

I strict separate markup from the doc-building tools. The decision in favor for
reST is not done because sphinx-doc is a great doc-bulding tool, it is done 
because
reST is a easy to write / read markup with a clear and expressive syntax 
definition.
The *best* builder for this markup is sphinx-doc, so it is only natural, that
the decision for the builder falls to sphinx-doc.

But kernel documentation is not a project from scratch, there was the *vintage*
kernel-doc markup first. Therefore, reST is only an additional markup!

With this POV you can add reST (or any other) markup to the doc-building 
process.
The Linux kernel draws on diverse projects, some of them may use different
markups and these maintainers are not interested in changing there whole markup
when they contribute to the kernel ... but may be there is someone how want's 
to add an other additional markup support to the doc-building process.

I'am not interested in supporting additional markups beside reST. But this is a
scalable future-proof solution, which only needs an announcement of the the 
markup.
The one additional comment line we are talking about.

--Markus--

> -Daniel
> -- 
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch

--
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

[PATCH v7 3/4] i2c: i801: add support of Host Notify

[Benjamin Tissoires]

The i801 chip can handle the Host Notify feature since ICH 3 as mentioned
in 
http://www.intel.com/content/dam/doc/datasheet/82801ca-io-controller-hub-3-datasheet.pdf

Enable the functionality unconditionally and propagate the alert
on each notification.

With a T440s and a Synaptics touchpad that implements Host Notify, the
payload data is always 0x, so I am not sure if the device actually
sends the payload or if there is a problem regarding the implementation.

Tested-by: Andrew Duggan 
Signed-off-by: Benjamin Tissoires 
---
changes in v2:
- removed the description of the Slave functionality support in the chip table
  (the table shows what is supported, not what the hardware is capable of)
- use i2c-smbus to forward the notification
- remove the fifo, and directly retrieve the address and payload in the worker
- do not check for Host Notification is the feature is not enabled
- use inw_p() to read the payload instead of 2 inb_p() calls
- add /* fall-through */ comment
- unconditionally enable Host Notify if the hardware supports it (can be
  disabled by the user)
 
no changes in v3

changes in v4:
- make use of the new API -> no more worker spawning here
- solved a race between the access of the Host Notify registers and the actual
  I2C transfers.

changes in v5:
- added SKL Host Notify support

changes in v6:
- select I2C_SMBUS in Kconfig to prevent an undefined reference when I2C_I801
  is set to 'Y' while I2C_SMBUS is set to 'M'

no changes in v7

 drivers/i2c/busses/Kconfig|  1 +
 drivers/i2c/busses/i2c-i801.c | 85 +--
 2 files changed, 83 insertions(+), 3 deletions(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index 0967e1a..0466a4f 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -91,6 +91,7 @@ config I2C_I801
tristate "Intel 82801 (ICH/PCH)"
depends on PCI
select CHECK_SIGNATURE if X86 && DMI
+   select I2C_SMBUS
help
  If you say yes to this option, support will be included for the Intel
  801 family of mainboard I2C interfaces.  Specifically, the following
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index 585a3b7..b244aa40 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -72,6 +72,7 @@
  * Block process call transaction  no
  * I2C block read transaction  yes (doesn't use the block buffer)
  * Slave mode  no
+ * SMBus Host Notify   yes
  * Interrupt processingyes
  *
  * See the file Documentation/i2c/busses/i2c-i801 for details.
@@ -86,6 +87,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -112,6 +114,10 @@
 #define SMBPEC(p)  (8 + (p)->smba) /* ICH3 and later */
 #define SMBAUXSTS(p)   (12 + (p)->smba)/* ICH4 and later */
 #define SMBAUXCTL(p)   (13 + (p)->smba)/* ICH4 and later */
+#define SMBSLVSTS(p)   (16 + (p)->smba)/* ICH3 and later */
+#define SMBSLVCMD(p)   (17 + (p)->smba)/* ICH3 and later */
+#define SMBNTFDADD(p)  (20 + (p)->smba)/* ICH3 and later */
+#define SMBNTFDDAT(p)  (22 + (p)->smba)/* ICH3 and later */
 
 /* PCI Address Constants */
 #define SMBBAR 4
@@ -176,6 +182,12 @@
 #define SMBHSTSTS_INTR 0x02
 #define SMBHSTSTS_HOST_BUSY0x01
 
+/* Host Notify Status registers bits */
+#define SMBSLVSTS_HST_NTFY_STS 1
+
+/* Host Notify Command registers bits */
+#define SMBSLVCMD_HST_NTFY_INTREN  0x01
+
 #define STATUS_ERROR_FLAGS (SMBHSTSTS_FAILED | SMBHSTSTS_BUS_ERR | \
 SMBHSTSTS_DEV_ERR)
 
@@ -244,13 +256,18 @@ struct i801_priv {
struct platform_device *mux_pdev;
 #endif
struct platform_device *tco_pdev;
+
+   struct smbus_host_notify *host_notify;
 };
 
+#define SMBHSTNTFY_SIZE8
+
 #define FEATURE_SMBUS_PEC  (1 << 0)
 #define FEATURE_BLOCK_BUFFER   (1 << 1)
 #define FEATURE_BLOCK_PROC (1 << 2)
 #define FEATURE_I2C_BLOCK_READ (1 << 3)
 #define FEATURE_IRQ(1 << 4)
+#define FEATURE_HOST_NOTIFY(1 << 5)
 /* Not really a feature, but it's convenient to handle it as such */
 #define FEATURE_IDF(1 << 15)
 #define FEATURE_TCO(1 << 16)
@@ -261,6 +278,7 @@ static const char *i801_feature_names[] = {
"Block process call",
"I2C block read",
"Interrupt",
+   "SMBus Host Notify",
 };
 
 static unsigned int disable_features;
@@ -269,7 +287,8 @@ MODULE_PARM_DESC(disable_features, "Disable selected driver 
features:\n"
"\t\t  0x01  disable SMBus PEC\n"
"\t\t  0x02  disable the block buffer\n"
"\t\t  0x08  disable the I2C block read functionality\n"
-   "\t\t  0x10  don't use interrupts ");
+   "\t\t  0x10  don't use interrupts\n"
+   "\t\t  0x20  disable SMBus Host Notify ");
 
 /* Make sure the SMBus host is 

[PATCH v7 2/4] i2c-smbus: add SMBus Host Notify support

[Benjamin Tissoires]

SMBus Host Notify allows a slave device to act as a master on a bus to
notify the host of an interrupt. On Intel chipsets, the functionality
is directly implemented in the firmware. We just need to export a
function to call .alert() on the proper device driver.

i2c_handle_smbus_host_notify() behaves like i2c_handle_smbus_alert().
When called, it schedules a task that will be able to sleep to go through
the list of devices attached to the adapter.

The current implementation allows one Host Notification to be scheduled
while an other is running.

Tested-by: Andrew Duggan 
Signed-off-by: Benjamin Tissoires 
---
changes in v2:
- do the actual processing of finding the device in i2c-smbus.c
- remove the i2c-core implementations
- remove the manual toggle of SMBus Host Notify

no changes in v3

changes in v4:
- schedule the worker in i2c_handle_smbus_host_notify() -> it can now be called
  in an interrupt context.
- introduce i2c_setup_smbus_host_notify()

no changes in v5

changes in v6:
- fix the parameters of the inlined functions when the module is not compiled

changes in v7:
- fixed typo in i2c_handle_smbus_host_notify() warning message ('.' and '\n'
  were inverted)

 Documentation/i2c/smbus-protocol |   3 ++
 drivers/i2c/i2c-smbus.c  | 113 +--
 include/linux/i2c-smbus.h|  44 +++
 include/linux/i2c.h  |   3 ++
 include/uapi/linux/i2c.h |   1 +
 5 files changed, 159 insertions(+), 5 deletions(-)

diff --git a/Documentation/i2c/smbus-protocol b/Documentation/i2c/smbus-protocol
index 6012b12..4e07848 100644
--- a/Documentation/i2c/smbus-protocol
+++ b/Documentation/i2c/smbus-protocol
@@ -199,6 +199,9 @@ alerting device's address.
 
 [S] [HostAddr] [Wr] A [DevAddr] A [DataLow] A [DataHigh] A [P]
 
+I2C drivers for devices which can trigger SMBus Host Notify should implement
+the optional alert() callback.
+
 
 Packet Error Checking (PEC)
 ===
diff --git a/drivers/i2c/i2c-smbus.c b/drivers/i2c/i2c-smbus.c
index 3b6765a..e14672e 100644
--- a/drivers/i2c/i2c-smbus.c
+++ b/drivers/i2c/i2c-smbus.c
@@ -33,7 +33,8 @@ struct i2c_smbus_alert {
 
 struct alert_data {
unsigned short  addr;
-   u8  flag:1;
+   enum i2c_alert_protocol type;
+   unsigned intdata;
 };
 
 /* If this is the alerting device, notify its driver */
@@ -56,8 +57,7 @@ static int smbus_do_alert(struct device *dev, void *addrp)
if (client->dev.driver) {
driver = to_i2c_driver(client->dev.driver);
if (driver->alert)
-   driver->alert(client, I2C_PROTOCOL_SMBUS_ALERT,
- data->flag);
+   driver->alert(client, data->type, data->data);
else
dev_warn(&client->dev, "no driver alert()!\n");
} else
@@ -97,8 +97,9 @@ static void smbus_alert(struct work_struct *work)
if (status < 0)
break;
 
-   data.flag = status & 1;
+   data.data = status & 1;
data.addr = status >> 1;
+   data.type = I2C_PROTOCOL_SMBUS_ALERT;
 
if (data.addr == prev_addr) {
dev_warn(&ara->dev, "Duplicate SMBALERT# from dev "
@@ -106,7 +107,7 @@ static void smbus_alert(struct work_struct *work)
break;
}
dev_dbg(&ara->dev, "SMBALERT# from dev 0x%02x, flag %d\n",
-   data.addr, data.flag);
+   data.addr, data.data);
 
/* Notify driver for the device which issued the alert */
device_for_each_child(&ara->adapter->dev, &data,
@@ -240,6 +241,108 @@ int i2c_handle_smbus_alert(struct i2c_client *ara)
 }
 EXPORT_SYMBOL_GPL(i2c_handle_smbus_alert);
 
+static void smbus_host_notify_work(struct work_struct *work)
+{
+   struct alert_data alert;
+   struct i2c_adapter *adapter;
+   unsigned long flags;
+   u16 payload;
+   u8 addr;
+   struct smbus_host_notify *data;
+
+   data = container_of(work, struct smbus_host_notify, work);
+
+   spin_lock_irqsave(&data->lock, flags);
+   payload = data->payload;
+   addr = data->addr;
+   adapter = data->adapter;
+
+   /* clear the pending bit and release the spinlock */
+   data->pending = false;
+   spin_unlock_irqrestore(&data->lock, flags);
+
+   if (!adapter || !addr)
+   return;
+
+   alert.type = I2C_PROTOCOL_SMBUS_HOST_NOTIFY;
+   alert.addr = addr;
+   alert.data = payload;
+
+   device_for_each_child(&adapter->dev, &alert, smbus_do_alert);
+}
+
+/**
+ * i2c_setup_smbus_host_notify - Allocate a new smbus_host_notify for the given
+ * I2C adapter.
+ * @adapter: the adapter we want to associate a Host Notify function
+ *
+ * Returns a struct smbus_host_notify pointer on success, and NULL 

[PATCH v7 4/4] Input: synaptics-rmi4 - add SMBus support

[Benjamin Tissoires]

Code obtained from 
https://raw.githubusercontent.com/mightybigcar/synaptics-rmi4/jf/drivers/input/rmi4/rmi_smbus.c
and updated to match upstream. And fixed to make it work.

Signed-off-by: Benjamin Tissoires 
Signed-off-by: Andrew Duggan 
---
new in v5

no changes in v6

changes in v7:
- fixed typos as per Andrew's requests
- changed module author from Allie to Andrew as per Andrew's request
- add suspend/resume callbacks to match upstream rmi4 behavior

 drivers/input/rmi4/Kconfig |  12 ++
 drivers/input/rmi4/Makefile|   1 +
 drivers/input/rmi4/rmi_bus.h   |  12 ++
 drivers/input/rmi4/rmi_smbus.c | 470 +
 4 files changed, 495 insertions(+)
 create mode 100644 drivers/input/rmi4/rmi_smbus.c

diff --git a/drivers/input/rmi4/Kconfig b/drivers/input/rmi4/Kconfig
index f73df24..86a180b 100644
--- a/drivers/input/rmi4/Kconfig
+++ b/drivers/input/rmi4/Kconfig
@@ -27,6 +27,18 @@ config RMI4_SPI
 
  If unsure, say N.
 
+config RMI4_SMB
+   tristate "RMI4 SMB Support"
+   depends on RMI4_CORE && I2C
+   help
+ Say Y here if you want to support RMI4 devices connected to an SMB
+ bus.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the module will be
+ called rmi_smbus.
+
 config RMI4_2D_SENSOR
bool
depends on RMI4_CORE
diff --git a/drivers/input/rmi4/Makefile b/drivers/input/rmi4/Makefile
index 95c00a7..3c8ebf2 100644
--- a/drivers/input/rmi4/Makefile
+++ b/drivers/input/rmi4/Makefile
@@ -11,3 +11,4 @@ rmi_core-$(CONFIG_RMI4_F30) += rmi_f30.o
 # Transports
 obj-$(CONFIG_RMI4_I2C) += rmi_i2c.o
 obj-$(CONFIG_RMI4_SPI) += rmi_spi.o
+obj-$(CONFIG_RMI4_SMB) += rmi_smbus.o
diff --git a/drivers/input/rmi4/rmi_bus.h b/drivers/input/rmi4/rmi_bus.h
index 8995798..b7625a9 100644
--- a/drivers/input/rmi4/rmi_bus.h
+++ b/drivers/input/rmi4/rmi_bus.h
@@ -105,6 +105,18 @@ rmi_get_platform_data(struct rmi_device *d)
 bool rmi_is_physical_device(struct device *dev);
 
 /**
+ * rmi_reset - reset a RMI4 device
+ * @d: Pointer to an RMI device
+ *
+ * Calls for a reset of each function implemented by a specific device.
+ * Returns 0 on success or a negative error code.
+ */
+static inline int rmi_reset(struct rmi_device *d)
+{
+   return d->driver->reset_handler(d);
+}
+
+/**
  * rmi_read - read a single byte
  * @d: Pointer to an RMI device
  * @addr: The address to read from
diff --git a/drivers/input/rmi4/rmi_smbus.c b/drivers/input/rmi4/rmi_smbus.c
new file mode 100644
index 000..d60b0e9
--- /dev/null
+++ b/drivers/input/rmi4/rmi_smbus.c
@@ -0,0 +1,470 @@
+/*
+ * Copyright (c) 2015 - 2016 Red Hat, Inc
+ * Copyright (c) 2011, 2012 Synaptics Incorporated
+ * Copyright (c) 2011 Unixphere
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "rmi_driver.h"
+
+#define SMB_PROTOCOL_VERSION_ADDRESS   0xfd
+#define SMB_MAX_COUNT  32
+#define RMI_SMB2_MAP_SIZE  8 /* 8 entry of 4 bytes each */
+#define RMI_SMB2_MAP_FLAGS_WE  0x01
+
+struct mapping_table_entry {
+   u16 rmiaddr;
+   u8 readcount;
+   u8 flags;
+};
+
+struct rmi_smb_xport {
+   struct rmi_transport_dev xport;
+   struct i2c_client *client;
+
+   struct mutex page_mutex;
+   int page;
+   u8 table_index;
+   struct mutex mappingtable_mutex;
+   struct mapping_table_entry mapping_table[RMI_SMB2_MAP_SIZE];
+};
+
+static int rmi_smb_get_version(struct rmi_smb_xport *rmi_smb)
+{
+   struct i2c_client *client = rmi_smb->client;
+   int retval;
+
+   /* Check if for SMBus new version device by reading version byte. */
+   retval = i2c_smbus_read_byte_data(client, SMB_PROTOCOL_VERSION_ADDRESS);
+   if (retval < 0) {
+   dev_err(&client->dev, "failed to get SMBus version number!\n");
+   return retval;
+   }
+   return retval + 1;
+}
+
+/* SMB block write - wrapper over ic2_smb_write_block */
+static int smb_block_write(struct rmi_transport_dev *xport,
+ u8 commandcode, const void *buf, size_t len)
+{
+   struct rmi_smb_xport *rmi_smb =
+   container_of(xport, struct rmi_smb_xport, xport);
+   struct i2c_client *client = rmi_smb->client;
+   int retval;
+
+   retval = i2c_smbus_write_block_data(client, commandcode, len, buf);
+
+   rmi_dbg(RMI_DEBUG_XPORT, &client->dev,
+   "wrote %zd bytes at %#04x: %d (%*ph)\n",
+   len, commandcode, retval, (int)len, buf);
+
+   return retval;
+}
+
+/*
+ * The function to get command code for smbus operations and keeps
+ * records to the driver mapping table
+ */
+static int rmi_smb_get_command_code(struct rmi_transp

[PATCH v7 1/4] i2c: add a protocol parameter to the alert callback

[Benjamin Tissoires]

.alert() is meant to be generic, but there is currently no way
for the device driver to know which protocol generated the alert.
Add a parameter in .alert() to help the device driver to understand
what is given in data.

This patch is required to have the support of SMBus Host Notify protocol
through .alert().

Tested-by: Andrew Duggan 
For IPMI:
Acked-by: Corey Minyard 
Signed-off-by: Benjamin Tissoires 
---

new in v2

changes in v3:
- added also lm90.c to support the new API
 
no changes in v4
 
no changes in v5

changes in v6:
- made sure lm90 also checks for the type of alert first

no changes in v7

 drivers/char/ipmi/ipmi_ssif.c | 6 +-
 drivers/hwmon/lm90.c  | 6 +-
 drivers/i2c/i2c-smbus.c   | 3 ++-
 include/linux/i2c.h   | 7 ++-
 4 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/drivers/char/ipmi/ipmi_ssif.c b/drivers/char/ipmi/ipmi_ssif.c
index 8b3be8b..10a2365 100644
--- a/drivers/char/ipmi/ipmi_ssif.c
+++ b/drivers/char/ipmi/ipmi_ssif.c
@@ -568,12 +568,16 @@ static void retry_timeout(unsigned long data)
 }
 
 
-static void ssif_alert(struct i2c_client *client, unsigned int data)
+static void ssif_alert(struct i2c_client *client, enum i2c_alert_protocol type,
+  unsigned int data)
 {
struct ssif_info *ssif_info = i2c_get_clientdata(client);
unsigned long oflags, *flags;
bool do_get = false;
 
+   if (type != I2C_PROTOCOL_SMBUS_ALERT)
+   return;
+
ssif_inc_stat(ssif_info, alerts);
 
flags = ipmi_ssif_lock_cond(ssif_info, &oflags);
diff --git a/drivers/hwmon/lm90.c b/drivers/hwmon/lm90.c
index c9ff08d..a00fd38 100644
--- a/drivers/hwmon/lm90.c
+++ b/drivers/hwmon/lm90.c
@@ -1624,10 +1624,14 @@ static int lm90_remove(struct i2c_client *client)
return 0;
 }
 
-static void lm90_alert(struct i2c_client *client, unsigned int flag)
+static void lm90_alert(struct i2c_client *client, enum i2c_alert_protocol type,
+  unsigned int flag)
 {
u16 alarms;
 
+   if (type != I2C_PROTOCOL_SMBUS_ALERT)
+   return;
+
if (lm90_is_tripped(client, &alarms)) {
/*
 * Disable ALERT# output, because these chips don't implement
diff --git a/drivers/i2c/i2c-smbus.c b/drivers/i2c/i2c-smbus.c
index abb55d3..3b6765a 100644
--- a/drivers/i2c/i2c-smbus.c
+++ b/drivers/i2c/i2c-smbus.c
@@ -56,7 +56,8 @@ static int smbus_do_alert(struct device *dev, void *addrp)
if (client->dev.driver) {
driver = to_i2c_driver(client->dev.driver);
if (driver->alert)
-   driver->alert(client, data->flag);
+   driver->alert(client, I2C_PROTOCOL_SMBUS_ALERT,
+ data->flag);
else
dev_warn(&client->dev, "no driver alert()!\n");
} else
diff --git a/include/linux/i2c.h b/include/linux/i2c.h
index 200cf13b..baae02a 100644
--- a/include/linux/i2c.h
+++ b/include/linux/i2c.h
@@ -126,6 +126,10 @@ i2c_smbus_read_i2c_block_data_or_emulated(const struct 
i2c_client *client,
  u8 command, u8 length, u8 *values);
 #endif /* I2C */
 
+enum i2c_alert_protocol {
+   I2C_PROTOCOL_SMBUS_ALERT,
+};
+
 /**
  * struct i2c_driver - represent an I2C device driver
  * @class: What kind of i2c device we instantiate (for detect)
@@ -181,7 +185,8 @@ struct i2c_driver {
 * For the SMBus alert protocol, there is a single bit of data passed
 * as the alert response's low bit ("event flag").
 */
-   void (*alert)(struct i2c_client *, unsigned int data);
+   void (*alert)(struct i2c_client *, enum i2c_alert_protocol protocol,
+ unsigned int data);
 
/* a ioctl like command that can be used to perform specific functions
 * with the device.
-- 
2.5.0

--
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

[PATCH v7 0/4] i2c-smbus: add support for HOST NOTIFY

[Benjamin Tissoires]

Hi,

this is mostly a resubmission of the v6 with the acks, tested-by and few typos
here and there.

We really need this to be integrated in the kernel to be able to finally
support the touchpads found in many laptops (such as the Lenovo Thinkpad series,
some HPs, and probably many others). Currently those laptops are running the
fallback mechanism over PS/2 which is full of bugs as it has not been given
the same QA than the RMI4 over SMBus (Windows uses RMI4 over SMBus).

RMI4 is now in Linus' tree since v4.6, so it would be nice to see Host Notify
in the I2C tree as well.

Cheers,
Benjamin

Benjamin Tissoires (4):
  i2c: add a protocol parameter to the alert callback
  i2c-smbus: add SMBus Host Notify support
  i2c: i801: add support of Host Notify
  Input: synaptics-rmi4 - add SMBus support

 Documentation/i2c/smbus-protocol |   3 +
 drivers/char/ipmi/ipmi_ssif.c|   6 +-
 drivers/hwmon/lm90.c |   6 +-
 drivers/i2c/busses/Kconfig   |   1 +
 drivers/i2c/busses/i2c-i801.c|  85 ++-
 drivers/i2c/i2c-smbus.c  | 112 +-
 drivers/input/rmi4/Kconfig   |  12 +
 drivers/input/rmi4/Makefile  |   1 +
 drivers/input/rmi4/rmi_bus.h |  12 +
 drivers/input/rmi4/rmi_smbus.c   | 470 +++
 include/linux/i2c-smbus.h|  44 
 include/linux/i2c.h  |  10 +-
 include/uapi/linux/i2c.h |   1 +
 13 files changed, 753 insertions(+), 10 deletions(-)
 create mode 100644 drivers/input/rmi4/rmi_smbus.c

-- 
2.5.0

--
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 0010/1529] Fix typo

[Herbert Xu]

On Sat, May 21, 2016 at 01:36:43PM +0200, Andrea Gelmini wrote:
> Signed-off-by: Andrea Gelmini 

Applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
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 00/10] Documentation/Sphinx

[Markus Heiser]

Am 30.05.2016 um 23:23 schrieb Mauro Carvalho Chehab :

> Em Mon, 30 May 2016 23:05:34 +0300
> Jani Nikula  escreveu:
> 
>>> I worry a little bit in that reST will be only one more toolchain 
>>> beside DocBook .. in the long term, kernel's documentation 
>>> should get rid of all the DocBook artifacts and for this a more
>>> comprehensive solution is needed.  
>> 
>> We agree on the end goal, eradicate DocBook. I must say that in my
>> experiments, apart from the media docs, almost everything converts
>> surprisingly nicely or IMO "good enough" with just the tmplcvt script in
>> this series.
> 
> With regards to media, my plan is to merge create a topic branch based
> on Kernel 4.7-rc1 at:
>   https://git.linuxtv.org/media_tree.git/
> 
> As none of the Jani's patches seem to affect the media API docs, it
> seems I don't need to merge back from Jon's -next branch.
> 
> There, I intend to add Markus patches with the conversion from the
> DocBook to rst, plus the flat-table extension logic.
> 
> Then, I'll work to manually fix what's needed and I'll add the 
> automation scripting logic that we have at the DocBook Makefile
> to work with the new media rst files.
> 
> Lastly, once the job's done, I'll drop Documentation/DocBook/media.
> 
> Markus,
> 
> With that regards, could you please send the patches to me?

Yes. What is your timeline ... is it OK if I send you a patch in the 
next two weeks? ... first I wan't to finish my other work / I'am just
back from holiday .. a lot of work to do :-o

--Markus--

> 
> Thanks,
> Mauro

--
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 00/10] Documentation/Sphinx

[Jani Nikula]

On Tue, 31 May 2016, Markus Heiser  wrote:
> Am 31.05.2016 um 10:07 schrieb Daniel Vetter :
>> 0-day builds all docs, and checks for new warnings. Even in today's
>> gpu.tmpl build there's a massive pile of warnings, so yes developers
>> don't look. But 0-day does, and then developers look at the nice mails
>> from 0-day. It mostly works to keep out new fail I think.
>
> In general, I'am not very happy with workarounds like this. IMO these
> are workarounds are often, rewards bunglers and punish those with more work,
> who want make thinks right. There might be situations where 0-day build
> is the only/best solution. But *here* we are talking about one additional
> comment line the author adds, when he modify his source comments from 
> kernel-doc 
> to reST markup .. IMO not very hard.

That "one line" translates to nearly 5 kernel-doc comments in more
than 6000 files. If you expect people to add a tag in each file/comment,
it will never happen. If we assume it's all rst, we can at least start
converting.

I quickly wrote a small "kernel-doc-rst-lint" script (70 lines of
python) based on rst-lint [1] that runs kernel-doc on a file and reports
all the kernel-doc and rst-lint errors in the output. This can be run as
a "checker" in the kernel build with

$ make CHECKER=scripts/kernel-doc-rst-lint C=1

and it can provide better and more direct warnings on kernel-doc/rst
errors than a full Sphinx build does.

BR,
Jani.


[1] https://pypi.python.org/pypi/restructuredtext_lint



-- 
Jani Nikula, Intel Open Source Technology Center
--
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

Discrepanyc in Documentation/iostat.h

[Nikolay Borisov]

Hello Jonathan,

I've been doing some digging around the diskstats code and there is
something which bothers me. The 11th field is described as:
"
Field 11 -- weighted # of milliseconds spent doing I/Os

This field is incremented at each I/O start, I/O completion, I/O
merge, or read of these stats by the number of I/Os in progress
(field 9) times the number of milliseconds spent doing I/O since the
last update of this field.  This can provide an easy measure of both
I/O completion time and the backlog that may be accumulating.
"

The actual code which prints the number there is using
jiffies_to_msecs(part_stat_read(hd, time_in_queue). Which is the same
code responsible for /sys/block//stat's last number. So I think the
documentation is wrong regarding the semantics of the 11th field.

Maybe it would be a good idea to get this updated?

Regards,
Nikolay
--
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 00/10] Documentation/Sphinx

[Markus Heiser]

Am 31.05.2016 um 12:30 schrieb Jani Nikula :

> On Tue, 31 May 2016, Markus Heiser  wrote:
>> Am 31.05.2016 um 10:07 schrieb Daniel Vetter :
>>> 0-day builds all docs, and checks for new warnings. Even in today's
>>> gpu.tmpl build there's a massive pile of warnings, so yes developers
>>> don't look. But 0-day does, and then developers look at the nice mails
>>> from 0-day. It mostly works to keep out new fail I think.
>> 
>> In general, I'am not very happy with workarounds like this. IMO these
>> are workarounds are often, rewards bunglers and punish those with more work,
>> who want make thinks right. There might be situations where 0-day build
>> is the only/best solution. But *here* we are talking about one additional
>> comment line the author adds, when he modify his source comments from 
>> kernel-doc 
>> to reST markup .. IMO not very hard.
> 
> That "one line" translates to nearly 5 kernel-doc comments in more
> than 6000 files. If you expect people to add a tag in each file/comment,
> it will never happen. If we assume it's all rst, we can at least start
> converting.

I have the impression that we misunderstand us ...

You will add this line only to these files where you have changed the 
markup from *vintage* kerenel-doc to reST. In my solution, you can
change the markup on every comment, but you don't have to .. it
is enough to add one line at the top of the file.

It's hard to describe something without an example, let my finish my
work and after this I can show it by example. Then you will see,
that the impact is less then you fear.

> I quickly wrote a small "kernel-doc-rst-lint" script (70 lines of
> python) based on rst-lint [1] that runs kernel-doc on a file and reports
> all the kernel-doc and rst-lint errors in the output. This can be run as
> a "checker" in the kernel build with
> 
> $ make CHECKER=scripts/kernel-doc-rst-lint C=1
> 
> and it can provide better and more direct warnings on kernel-doc/rst
> errors than a full Sphinx build does.

I haven't tested [1], but I assume that it covers only docutils-reST not
the Sphinx-doc superset (thats might be the reason why you see less errors)
... anyway it could be convenient tool.


--Markus--

PS: I looked closer to [1], it uses the docutils puplischer ..

  from docutils.core import Publisher

with a /dev/null like stream

  document.reporter.stream = None

The errors you get from this are the same you get from a rst2xxx 
tool ...

|  >>> import restructuredtext_lint
|  >>> errors = restructuredtext_lint.lint("""
|  ... Hello World
|  ... ===
|  ... 
|  ... :ref:`label_name` 
|  ... """)
|  >>> errors[0].astext()
|  u'None:3: (WARNING/2) Title underline too short.\n\nHello World\n==='
|  >>> errors[1].astext()
|  u'None:5: (INFO/1) No role entry for "ref" in module 
"docutils.parsers.rst.languages.en".\nTrying "ref" as canonical role name.'

> 
> BR,
> Jani.
> 
> 
> [1] https://pypi.python.org/pypi/restructuredtext_lint
> 
> 
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

--
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 v2 1/2] scsi: fix race between simultaneous decrements of ->host_failed

[Tejun Heo]

On Tue, May 31, 2016 at 04:38:17PM +0800, Wei Fang wrote:
> sas_ata_strategy_handler() adds the works of the ata error handler
> to system_unbound_wq. This workqueue asynchronously runs work items,

Are there more than one error handling work items per host?

Thanks.

-- 
tejun
--
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

[PATCH 1/1 v5] hwmon: add support for Sensirion SHT3x sensors

[Pascal Sachs]

From: David Frey 

This driver implements support for the Sensirion SHT3x-DIS chip,
a humidity and temperature sensor. Temperature is measured
in degrees celsius, relative humidity is expressed as a percentage.
In the sysfs interface, all values are scaled by 1000,
i.e. the value for 31.5 degrees celsius is 31500.

Signed-off-by: Pascal Sachs 
---
Patch was generated against kernel v4.7-rc1

Changelog
=
v2
* Change humidity type to u32 since it can't be negative
* Use sensor_device_attr instead of device_attr
* mutex protect sht3x_read_from_command

v3
* Wording in documentation
* Remove soft_reset interface
* Rename frequency => update_interval
* Best match algorithm for update_interval selection
* Cache values for limits
* Add alarm channel interface for temp and humidity
* Better mutex protection
* Use an enum to acces limits in the array of limits. This makes sure,
the array definition and will always be in sync with the used indices.

v4
* Proper locking mutex
* Using goto for error handling as specified in coding styles
* Easier to understand syntax for read out alarm states from status register

v5
* Fix styling issues, remove unnecessary empty lines
* Improve usage of mutex
* Update copyright year to 2016 in sht3x.h
* Use define for clamping min,max temp and humidity limits
* Only send abort command if in periodic measure mode

 Documentation/hwmon/sht3x   |  72 
 drivers/hwmon/Kconfig   |  11 +
 drivers/hwmon/Makefile  |   1 +
 drivers/hwmon/sht3x.c   | 713 
 include/linux/platform_data/sht3x.h |  25 ++
 5 files changed, 822 insertions(+)
 create mode 100644 Documentation/hwmon/sht3x
 create mode 100644 drivers/hwmon/sht3x.c
 create mode 100644 include/linux/platform_data/sht3x.h

diff --git a/Documentation/hwmon/sht3x b/Documentation/hwmon/sht3x
new file mode 100644
index 000..f5aa633
--- /dev/null
+++ b/Documentation/hwmon/sht3x
@@ -0,0 +1,72 @@
+Kernel driver sht3x
+===
+
+Supported chips:
+  * Sensirion SHT3x-DIS
+Prefix: 'sht3x'
+Addresses scanned: none
+Datasheet: 
http://www.sensirion.com/fileadmin/user_upload/customers/sensirion/Dokumente/Humidity/Sensirion_Humidity_Datasheet_SHT3x_DIS.pdf
+
+Author:
+  David Frey 
+  Pascal Sachs 
+
+Description
+---
+
+This driver implements support for the Sensirion SHT3x-DIS chip, a humidity
+and temperature sensor. Temperature is measured in degrees celsius, relative
+humidity is expressed as a percentage. In the sysfs interface, all values are
+scaled by 1000, i.e. the value for 31.5 degrees celsius is 31500.
+
+The device communicates with the I2C protocol. Sensors can have the I2C
+addresses 0x44 or 0x45, depending on the wiring. See
+Documentation/i2c/instantiating-devices for methods to instantiate the device.
+
+There are two options configurable by means of sht3x_platform_data:
+1. blocking (pull the I2C clock line down while performing the measurement) or
+   non-blocking mode. Blocking mode will guarantee the fastest result but
+   the I2C bus will be busy during that time. By default, non-blocking mode
+   is used. Make sure clock-stretching works properly on your device if you
+   want to use blocking mode.
+2. high or low accuracy. High accuracy is used by default and using it is
+   strongly recommended.
+
+The sht3x sensor supports a single shot mode as well as 5 periodic measure
+modes, which can be controlled with the update_interval sysfs interface.
+The allowed update_interval in milliseconds are as follows:
+  * 0   single shot mode
+  *  2000   0.5 Hz periodic measurement
+  *  1000   1   Hz periodic measurement
+  *   500   2   Hz periodic measurement
+  *   250   4   Hz periodic measurement
+  *   100  10   Hz periodic measurement
+
+In the periodic measure mode, the sensor automatically triggers a measurement
+with the configured update interval on the chip. When a temperature or humidity
+reading exceeds the configured limits, the alert attribute is set to 1 and
+the alert pin on the sensor is set to high.
+When the temperature and humidity readings move back between the hysteresis
+values, the alert bit is set to 0 and the alert pin on the sensor is set to
+low.
+
+sysfs-Interface
+---
+
+temp1_input:temperature input
+humidity1_input:humidity input
+temp1_max:  temperature max value
+temp1_max_hyst: temperature hysteresis value for max limit
+humidity1_max:  humidity max value
+humidity1_max_hyst: humidity hysteresis value for max limit
+temp1_min:  temperature min value
+temp1_min_hyst: temperature hysteresis value for min limit
+humidity1_min:  humidity min value
+humidity1_min_hyst: humidity hysteresis value for min limit
+temp1_alarm:alarm flag is set to 1 if the temperature is outside the
+configured limits. Alarm only works in periodic measure 
mode
+humidity1_alarm:alarm flag is set to 1 if the humi

[PATCH] hwmon: (tmp401) Add support for TI TMP461

[Andrew F. Davis]

Signed-off-by: Andrew F. Davis 
---
 Documentation/hwmon/tmp401 | 18 +--
 drivers/hwmon/Kconfig  |  2 +-
 drivers/hwmon/tmp401.c | 81 ++
 3 files changed, 92 insertions(+), 9 deletions(-)

diff --git a/Documentation/hwmon/tmp401 b/Documentation/hwmon/tmp401
index 711f75e..eaa2d3b 100644
--- a/Documentation/hwmon/tmp401
+++ b/Documentation/hwmon/tmp401
@@ -22,6 +22,9 @@ Supported chips:
 Prefix: 'tmp435'
 Addresses scanned: I2C 0x48 - 0x4f
 Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp435.html
+  * Texas Instruments TMP461
+Prefix: 'tmp461'
+Datasheet: http://www.ti.com/product/tmp461
 
 Authors:
  Hans de Goede 
@@ -31,8 +34,8 @@ Description
 ---
 
 This driver implements support for Texas Instruments TMP401, TMP411,
-TMP431, TMP432 and TMP435 chips. These chips implement one or two remote
-and one local temperature sensors. Temperature is measured in degrees
+TMP431, TMP432, TMP435, and TMP461 chips. These chips implement one or two
+remote and one local temperature sensors. Temperature is measured in degrees
 Celsius. Resolution of the remote sensor is 0.0625 degree. Local
 sensor resolution can be set to 0.5, 0.25, 0.125 or 0.0625 degree (not
 supported by the driver so far, so using the default resolution of 0.5
@@ -55,3 +58,14 @@ some additional features.
 
 TMP432 is compatible with TMP401 and TMP431. It supports two external
 temperature sensors.
+
+TMP461 is compatible with TMP401. It supports offset and n-factor correction
+that is applied to the remote sensor.
+
+* Sensor offset values are temperature values
+
+  Exported via sysfs attribute tempX_offset
+
+* n-factor correction, values are in raw form as described in the datasheet
+
+  Exported via sysfs attribute tempX_nfactor
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index ff94007..c571dcf 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -1561,7 +1561,7 @@ config SENSORS_TMP401
depends on I2C
help
  If you say yes here you get support for Texas Instruments TMP401,
- TMP411, TMP431, TMP432 and TMP435 temperature sensor chips.
+ TMP411, TMP431, TMP432, TMP435, and TMP461 temperature sensor chips.
 
  This driver can also be built as a module.  If so, the module
  will be called tmp401.
diff --git a/drivers/hwmon/tmp401.c b/drivers/hwmon/tmp401.c
index ccf4cff..280065b 100644
--- a/drivers/hwmon/tmp401.c
+++ b/drivers/hwmon/tmp401.c
@@ -47,7 +47,8 @@
 static const unsigned short normal_i2c[] = { 0x48, 0x49, 0x4a, 0x4c, 0x4d,
0x4e, 0x4f, I2C_CLIENT_END };
 
-enum chips { tmp401, tmp411, tmp431, tmp432, tmp435 };
+enum chips { tmp401, tmp411, tmp431, tmp432, tmp435, tmp461 };
+
 
 /*
  * The TMP401 registers, note some registers have different addresses for
@@ -62,31 +63,37 @@ enum chips { tmp401, tmp411, tmp431, tmp432, tmp435 };
 #define TMP401_MANUFACTURER_ID_REG 0xFE
 #define TMP401_DEVICE_ID_REG   0xFF
 
-static const u8 TMP401_TEMP_MSB_READ[6][2] = {
+static const u8 TMP401_TEMP_MSB_READ[8][2] = {
{ 0x00, 0x01 }, /* temp */
{ 0x06, 0x08 }, /* low limit */
{ 0x05, 0x07 }, /* high limit */
{ 0x20, 0x19 }, /* therm (crit) limit */
{ 0x30, 0x34 }, /* lowest */
{ 0x32, 0x36 }, /* highest */
+   { 0, 0x11 },/* offset */
+   { 0, 0x23 },/* nfactor */
 };
 
-static const u8 TMP401_TEMP_MSB_WRITE[6][2] = {
+static const u8 TMP401_TEMP_MSB_WRITE[8][2] = {
{ 0, 0 },   /* temp (unused) */
{ 0x0C, 0x0E }, /* low limit */
{ 0x0B, 0x0D }, /* high limit */
{ 0x20, 0x19 }, /* therm (crit) limit */
{ 0x30, 0x34 }, /* lowest */
{ 0x32, 0x36 }, /* highest */
+   { 0, 0x11 },/* offset */
+   { 0, 0x23 },/* nfactor */
 };
 
-static const u8 TMP401_TEMP_LSB[6][2] = {
+static const u8 TMP401_TEMP_LSB[8][2] = {
{ 0x15, 0x10 }, /* temp */
{ 0x17, 0x14 }, /* low limit */
{ 0x16, 0x13 }, /* high limit */
{ 0, 0 },   /* therm (crit) limit (unused) */
{ 0x31, 0x35 }, /* lowest */
{ 0x33, 0x37 }, /* highest */
+   { 0, 0x12 },/* offset */
+   { 0, 0 },   /* nfactor (unused) */
 };
 
 static const u8 TMP432_TEMP_MSB_READ[4][3] = {
@@ -149,6 +156,7 @@ static const struct i2c_device_id tmp401_id[] = {
{ "tmp431", tmp431 },
{ "tmp432", tmp432 },
{ "tmp435", tmp435 },
+   { "tmp461", tmp461 },
{ }
 };
 MODULE_DEVICE_TABLE(i2c, tmp401_id);
@@ -170,7 +178,7 @@ struct tmp401_data {
/* register values */
u8 status[4];
u8 config;
-   u16 temp[6][3];
+   u16 temp[8][3];
u8 temp_crit_hyst;
 };
 
@@ -445,6 +453,44 @@ static ssize_t reset_temp_history(struct device *dev,
return count;
 }
 
+static ssize_t show_nfactor(struct device *dev,
+   struct devic

Re: [RFC v2] dma-mapping: Use unsigned long for dma_attrs

[Christoph Hellwig]

On Mon, May 30, 2016 at 01:54:06PM +0200, Krzysztof Kozlowski wrote:
> The dma-mapping core and the implementations do not change the
> DMA attributes passed by pointer.  Thus the pointer can point to const
> data.  However the attributes do not have to be a bitfield. Instead
> unsigned long will do fine:
> 
> 1. This is just simpler.  Both in terms of reading the code and setting
>attributes.  Instead of initializing local attributes on the stack and
>passing pointer to it to dma_set_attr(), just set the bits.
> 
> 2. It brings safeness and checking for const correctness because the
>attributes are passed by value.
> 
> Please have in mind that this is RFC, not finished yet.  Only ARM and
> ARM64 are fixed (and not everywhere).
> However other API users also have to be converted which is quite
> intrusive.  I would rather avoid it until the overall approach is
> accepted.

This looks great!  Please continue doing the full conversion.

> +/**
> + * List of possible attributes associated with a DMA mapping. The semantics
> + * of each attribute should be defined in Documentation/DMA-attributes.txt.
> + */
> +#define DMA_ATTR_WRITE_BARRIER   BIT(1)
> +#define DMA_ATTR_WEAK_ORDERING   BIT(2)
> +#define DMA_ATTR_WRITE_COMBINE   BIT(3)
> +#define DMA_ATTR_NON_CONSISTENT  BIT(4)
> +#define DMA_ATTR_NO_KERNEL_MAPPING   BIT(5)
> +#define DMA_ATTR_SKIP_CPU_SYNC   BIT(6)
> +#define DMA_ATTR_FORCE_CONTIGUOUSBIT(7)
> +#define DMA_ATTR_ALLOC_SINGLE_PAGES  BIT(8)

No really for this patch, but I would much prefer to document them next
to the code in the long run.  Also I really think these BIT() macros
are a distraction compared to the (1 << N) notation.

> +/**
> + * dma_get_attr - check for a specific attribute
> + * @attr: attribute to look for
> + * @attrs: attributes to check within
> + */
> +static inline bool dma_get_attr(unsigned long attr, unsigned long attrs)
> +{
> + return !!(attr & attrs);
> +}

I'd just kill this helper, much easier to simply open code it in the
caller.
--
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 1/1 v4] hwmon: add support for Sensirion SHT3x sensors

[Guenter Roeck]

On Tue, May 31, 2016 at 09:08:27AM +0200, Pascal Sachs wrote:
> Hi Guenter
> 
> I want to thank you again for the fast and detailed code review.
> I really appreciate it.
> 

Sorry it took so long.

[ ... ]

> >>+static struct sht3x_data *sht3x_update_client(struct device *dev)
> >>+{
> >>+struct sht3x_data *data = dev_get_drvdata(dev);
> >>+struct i2c_client *client = data->client;
> >>+u16 interval_ms = mode_to_update_interval[data->mode];
> >
> >If data->mode == 0, interval_ms == 0,
> >
> >>+unsigned long interval_jiffies = msecs_to_jiffies(interval_ms);
> >
> >... interval_jiffies == 1,
> >
> >>+unsigned char buf[SHT3X_RESPONSE_LENGTH];
> >>+u16 val;
> >>+int ret = 0;
> >>+
> >>+mutex_lock(&data->data_lock);
> >>+/* only update once per interval in periodic mode */
> >>+if (time_after(jiffies, data->last_update + interval_jiffies)) {
> >
> >... and the command is executed every other timer tick. Is that
> >intentional ?
> Yes, this is how it should behave. In single shot mode the sensor measures
> values on demand, which means every time the sysfs interface is called, a
> measurement is triggered. In periodic mode however the measurement process
> is handled internally by the sensor and read out only makes sense if a new
> reading is available.

Please add the explanation as comment into the code.

[ ... ]

> >>+commands = &limit_commands[index];
> >>+
> >>+memcpy(position, commands->write_command, SHT3X_CMD_LENGTH);
> >>+position += SHT3X_CMD_LENGTH;
> >>+/*
> >>+ * ST = (T + 45) / 175 * 2^16
> >>+ * SRH = RH / 100 * 2^16
> >>+ * adapted for fixed point arithmetic and packed the same as
> >>+ * in limit_show()
> >>+ */
> >>+raw = ((u32)(temperature + 45000) * 24543) >> (16 + 7);
> >>+raw |= ((humidity * 42950) >> 16) & 0xfe00;
> >>+
> >>+*((__be16 *)position) = cpu_to_be16(raw);
> >>+position += SHT3X_WORD_LEN;
> >>+*position = crc8(sht3x_crc8_table,
> >>+ position - SHT3X_WORD_LEN,
> >>+ SHT3X_WORD_LEN,
> >>+ SHT3X_CRC8_INIT);
> >>+
> >>+mutex_lock(&data->data_lock);
> >>+mutex_lock(&data->i2c_lock);
> >>+ret = i2c_master_send(client, buffer, sizeof(buffer));
> >>+mutex_unlock(&data->i2c_lock);
> >>+
> >>+if (ret != sizeof(buffer))
> >>+goto out;
> >>+
> >>+data->temperature_limits[index] = temperature;
> >>+data->humidity_limits[index] = humidity;
> >>+
> >>+out:
> >>+mutex_unlock(&data->data_lock);
> >>+if (ret != sizeof(buffer))
> >>+return  ret < 0 ? ret : -EIO;
> >>+
> >>+return count;
> >
> >I would prefer something like
> >
> >if (ret != sizeof(buffer)) {
> >if (ret >= 0)
> >ret = -EIO;
> >goto out;
> >}
> >
> >ret = count;
> >data->temperature_limits[index] = temperature;
> >data->humidity_limits[index] = humidity;
> >out:
> >mutex_unlock(&data->data_lock);
> >return ret;
> >
> >which I think would be cleaner. See below though for locking issues.
> OK, wasn't sure if it is appropriate to handle error and valid return in the
> same variable

Done all over the place.

[ ... ]

> >
> >>+mutex_lock(&data->i2c_lock);
> >>+mutex_lock(&data->data_lock);
> >>+/* abort periodic measure */
> >>+ret = i2c_master_send(client, sht3x_cmd_break, SHT3X_CMD_LENGTH);
> >>+if (ret != SHT3X_CMD_LENGTH)
> >>+goto out;
> >>+data->mode = 0;
> >>+
> >
> >Can you explain why you set data->mode = 0 here ?
> To do any changes to the configuration while in periodic mode we have to
> send a break command to the sensor, which then falls back to single shot
> mode (mode = 0). Therefore for consistency reasons we set the mode to
> the value it actually is at this point.
> If setting the new mode fails, we are still in single shot mode. Like this
> we
> ensure that the data->mode is always correct.

Ok; please add the explanation as comment into the code.

Thanks,
Guenter
--
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 v2] dma-mapping: Use unsigned long for dma_attrs

[Konrad Rzeszutek Wilk]

On Mon, May 30, 2016 at 01:54:06PM +0200, Krzysztof Kozlowski wrote:
> The dma-mapping core and the implementations do not change the
> DMA attributes passed by pointer.  Thus the pointer can point to const
> data.  However the attributes do not have to be a bitfield. Instead
> unsigned long will do fine:
> 
> 1. This is just simpler.  Both in terms of reading the code and setting
>attributes.  Instead of initializing local attributes on the stack and
>passing pointer to it to dma_set_attr(), just set the bits.
> 
> 2. It brings safeness and checking for const correctness because the
>attributes are passed by value.


.. why not go the next step a do an enum? Perhaps that should be mentioned
as part of the description?

Thanks.
> 
> Please have in mind that this is RFC, not finished yet.  Only ARM and
> ARM64 are fixed (and not everywhere).
> However other API users also have to be converted which is quite
> intrusive.  I would rather avoid it until the overall approach is
> accepted.
> 
> Signed-off-by: Krzysztof Kozlowski 
> ---
>  Documentation/DMA-API.txt |   2 +-
>  Documentation/DMA-attributes.txt  |   2 +-
>  arch/arm/include/asm/dma-mapping.h|  13 ++--
>  arch/arm/include/asm/xen/page-coherent.h  |  16 ++---
>  arch/arm/mm/dma-mapping.c |  82 +++
>  arch/arm/xen/mm.c |   4 +-
>  arch/arm64/mm/dma-mapping.c   |  57 
>  drivers/gpu/drm/exynos/exynos_drm_fbdev.c |   2 +-
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c   |   1 -
>  drivers/gpu/drm/exynos/exynos_drm_gem.c   |  20 +++---
>  drivers/gpu/drm/exynos/exynos_drm_gem.h   |   2 +-
>  drivers/iommu/dma-iommu.c |   6 +-
>  drivers/xen/swiotlb-xen.c |  14 ++--
>  include/linux/dma-attrs.h |  71 
>  include/linux/dma-iommu.h |   6 +-
>  include/linux/dma-mapping.h   | 105 
> +-
>  include/linux/swiotlb.h   |  10 +--
>  include/xen/swiotlb-xen.h |  12 ++--
>  lib/dma-noop.c|   9 +--
>  lib/swiotlb.c |  13 ++--
>  20 files changed, 195 insertions(+), 252 deletions(-)
>  delete mode 100644 include/linux/dma-attrs.h
> 
> diff --git a/Documentation/DMA-API.txt b/Documentation/DMA-API.txt
> index 45ef3f279c3b..0b55cb7c5aaa 100644
> --- a/Documentation/DMA-API.txt
> +++ b/Documentation/DMA-API.txt
> @@ -391,7 +391,7 @@ without the _attrs suffixes, except that they pass an 
> optional
>  struct dma_attrs*.
>  
>  struct dma_attrs encapsulates a set of "DMA attributes". For the
> -definition of struct dma_attrs see linux/dma-attrs.h.
> +definition of struct dma_attrs see linux/dma-mapping.h.
>  
>  The interpretation of DMA attributes is architecture-specific, and
>  each attribute should be documented in Documentation/DMA-attributes.txt.
> diff --git a/Documentation/DMA-attributes.txt 
> b/Documentation/DMA-attributes.txt
> index e8cf9cf873b3..2d455a5cf671 100644
> --- a/Documentation/DMA-attributes.txt
> +++ b/Documentation/DMA-attributes.txt
> @@ -2,7 +2,7 @@
>   ==
>  
>  This document describes the semantics of the DMA attributes that are
> -defined in linux/dma-attrs.h.
> +defined in linux/dma-mapping.h.
>  
>  DMA_ATTR_WRITE_BARRIER
>  --
> diff --git a/arch/arm/include/asm/dma-mapping.h 
> b/arch/arm/include/asm/dma-mapping.h
> index a83570f10124..d009f7911ffc 100644
> --- a/arch/arm/include/asm/dma-mapping.h
> +++ b/arch/arm/include/asm/dma-mapping.h
> @@ -5,7 +5,6 @@
>  
>  #include 
>  #include 
> -#include 
>  #include 
>  
>  #include 
> @@ -174,7 +173,7 @@ static inline void dma_mark_clean(void *addr, size_t 
> size) { }
>   * to be the device-viewed address.
>   */
>  extern void *arm_dma_alloc(struct device *dev, size_t size, dma_addr_t 
> *handle,
> -gfp_t gfp, struct dma_attrs *attrs);
> +gfp_t gfp, unsigned long attrs);
>  
>  /**
>   * arm_dma_free - free memory allocated by arm_dma_alloc
> @@ -191,7 +190,7 @@ extern void *arm_dma_alloc(struct device *dev, size_t 
> size, dma_addr_t *handle,
>   * during and after this call executing are illegal.
>   */
>  extern void arm_dma_free(struct device *dev, size_t size, void *cpu_addr,
> -  dma_addr_t handle, struct dma_attrs *attrs);
> +  dma_addr_t handle, unsigned long attrs);
>  
>  /**
>   * arm_dma_mmap - map a coherent DMA allocation into user space
> @@ -208,7 +207,7 @@ extern void arm_dma_free(struct device *dev, size_t size, 
> void *cpu_addr,
>   */
>  extern int arm_dma_mmap(struct device *dev, struct vm_area_struct *vma,
>   void *cpu_addr, dma_addr_t dma_addr, size_t size,
> - struct dma_attrs *attrs);
> + unsigned long attrs);
>  
>  /*
>   * This can

Re: [PULL v4.6-rc1] bcache: documentation updates

[Jonathan Corbet]

On Mon, 30 May 2016 07:43:09 -0700
Marc MERLIN  wrote:

> > There is a bcache documentation update available:
> >   
> > > > git pull https://bitbucket.org/ewheelerinc/linux 
> > > > v4.6-rc1-bcache-documentation  
> > 
> > Is this the right list to submit such documentation?  
> 
> Howdy,
> 
> I just pulled 4.6 and noticed the doc updates from Eric and me don't
> seem to have made it.
> 
> Jon, would you know who can help getting those in? I wrote them before
> 4.5 came out :)

I don't think I ever saw this, was it sent to me?

How about we post the docs as patches and go from there?

Thanks,

jon
--
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: [PULL v4.6-rc1] bcache: documentation updates

[Marc MERLIN]

On Tue, May 31, 2016 at 04:55:08PM -0600, Jonathan Corbet wrote:
> On Mon, 30 May 2016 07:43:09 -0700
> Marc MERLIN  wrote:
> 
> > > There is a bcache documentation update available:
> > >   
> > > > > git pull https://bitbucket.org/ewheelerinc/linux 
> > > > > v4.6-rc1-bcache-documentation  
> > > 
> > > Is this the right list to submit such documentation?  
> > 
> > Howdy,
> > 
> > I just pulled 4.6 and noticed the doc updates from Eric and me don't
> > seem to have made it.
> > 
> > Jon, would you know who can help getting those in? I wrote them before
> > 4.5 came out :)
> 
> I don't think I ever saw this, was it sent to me?
 
No I think Eric Emailed linux-doc@vger.kernel.org, instead of you directly.

> How about we post the docs as patches and go from there?

His posted tree contains them. Here are the 2 patches:
https://bitbucket.org/ewheelerinc/linux/commits/606d51faf12382a2a8ab049a5a931533be720386?at=v4.6-rc1-bcache-documentation
https://bitbucket.org/ewheelerinc/linux/commits/69d2dc24a24415901983a045e1f9c7ab1ebb71c4?at=v4.6-rc1-bcache-documentation
(both should be applied)

Thanks for looking at this.
Marc
-- 
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems 
   what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/  
--
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] Documentation: Fix some grammar mistakes in sync_file.txt

[Gustavo Padovan]

2016-05-14 Javier Martinez Canillas :

> There are two sentences in the Sync File documentation where the
> english is a little off. This patch is an attempt to fix these.
> 
> Signed-off-by: Javier Martinez Canillas 
> 
> ---
> 
>  Documentation/sync_file.txt | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/sync_file.txt b/Documentation/sync_file.txt
> index eaf8297dbca2..e8e2ebafe5fa 100644
> --- a/Documentation/sync_file.txt
> +++ b/Documentation/sync_file.txt
> @@ -6,8 +6,8 @@
>  
>  This document serves as a guide for device drivers writers on what the
>  sync_file API is, and how drivers can support it. Sync file is the carrier of
> -the fences(struct fence) that needs to synchronized between drivers or across
> -process boundaries.
> +the fences(struct fence) that are needed to synchronize between drivers or
> +across process boundaries.
>  
>  The sync_file API is meant to be used to send and receive fence information
>  to/from userspace. It enables userspace to do explicit fencing, where instead
> @@ -32,7 +32,7 @@ in-fences and out-fences
>  Sync files can go either to or from userspace. When a sync_file is sent from
>  the driver to userspace we call the fences it contains 'out-fences'. They are
>  related to a buffer that the driver is processing or is going to process, so
> -the driver an create out-fence to be able to notify, through fence_signal(),
> +the driver creates an out-fence to be able to notify, through fence_signal(),
>  when it has finished using (or processing) that buffer. Out-fences are fences
>  that the driver creates.

Thanks, Javier!

Reviewed-by: Gustavo Padovan 

Gustavo
--
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 00/10] Documentation/Sphinx

[Jonathan Corbet]

On Mon, 30 May 2016 11:10:26 +0200
Daniel Vetter  wrote:

> I think next steps is to get this merged into docs-next, with a stable
> tag, so that I can pull it into drm-misc.

So, I want to take another look at this, which probably will need another
day or two before it can happen.  First impression, though, is that this
is great, so I'm expecting that I'll be applying it.

Not sure about the stable tag, though?  It doesn't really seem like
stable material?  

jon
--
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 v2 1/2] scsi: fix race between simultaneous decrements of ->host_failed

[Wei Fang]

Hi, Tejun,

On 2016/5/31 22:33, Tejun Heo wrote:
> On Tue, May 31, 2016 at 04:38:17PM +0800, Wei Fang wrote:
>> sas_ata_strategy_handler() adds the works of the ata error handler
>> to system_unbound_wq. This workqueue asynchronously runs work items,
> 
> Are there more than one error handling work items per host?

The ata error handler here means async_sas_ata_eh(), every port will
execute it's own async_sas_ata_eh() in sas_ata_strategy_handler().

Thanks,
Wei

> 
> Thanks.
> 

--
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

[PATCH v2 06/27] staging: unisys: visorbus: modify format string to match argument

[David Kershner]

From: David Binder 

Modifies the format string of snprintf to expect an unsigned int
instead of a signed one, per the supplied argument.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index cb08ce4..c30b4b2 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -433,7 +433,7 @@ static ssize_t client_bus_info_show(struct device *dev,
if (vdev->name)
partition_name = vdev->name;
shift = snprintf(pos, remain,
-"Client device / client driver info for %s 
eartition (vbus #%d):\n",
+"Client device / client driver info for %s 
eartition (vbus #%u):\n",
 partition_name, vdev->chipset_dev_no);
pos += shift;
remain -= shift;
-- 
1.9.1

--
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

[PATCH v2 25/27] include: linux: visorbus: Add visorbus to include/linux directory

[David Kershner]

Update include/linux to include the s-Par associated common include
header files needed for the s-Par visorbus.

Since we have now moved the include directories over to
include/linux/visorbus this patch makes all of the visor
drivers visorbus, visorinput, visornic, and visorhba use
the new include folders.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/MAINTAINERS| 2 +-
 drivers/staging/unisys/visorbus/Makefile  | 2 --
 drivers/staging/unisys/visorbus/controlvmchannel.h| 2 +-
 drivers/staging/unisys/visorbus/vbuschannel.h | 3 ++-
 drivers/staging/unisys/visorbus/visorbus_main.c   | 6 +++---
 drivers/staging/unisys/visorbus/visorchannel.c| 4 ++--
 drivers/staging/unisys/visorbus/visorchipset.c| 8 
 drivers/staging/unisys/visorbus/vmcallinterface.h | 5 ++---
 drivers/staging/unisys/visorhba/Makefile  | 2 --
 drivers/staging/unisys/visorhba/visorhba_main.c   | 5 ++---
 drivers/staging/unisys/visorinput/Makefile| 2 --
 drivers/staging/unisys/visorinput/visorinput.c| 6 +++---
 drivers/staging/unisys/visornic/Makefile  | 2 --
 drivers/staging/unisys/visornic/visornic_main.c   | 5 ++---
 .../staging/unisys/include => include/linux/visorbus}/channel.h   | 0
 .../unisys/include => include/linux/visorbus}/channel_guid.h  | 0
 .../unisys/include => include/linux/visorbus}/diagchannel.h   | 0
 .../unisys/include => include/linux/visorbus}/guestlinuxdebug.h   | 0
 .../staging/unisys/include => include/linux/visorbus}/iochannel.h | 0
 .../staging/unisys/include => include/linux/visorbus}/version.h   | 0
 .../staging/unisys/include => include/linux/visorbus}/visorbus.h  | 0
 21 files changed, 22 insertions(+), 32 deletions(-)
 rename {drivers/staging/unisys/include => include/linux/visorbus}/channel.h 
(100%)
 rename {drivers/staging/unisys/include => 
include/linux/visorbus}/channel_guid.h (100%)
 rename {drivers/staging/unisys/include => 
include/linux/visorbus}/diagchannel.h (100%)
 rename {drivers/staging/unisys/include => 
include/linux/visorbus}/guestlinuxdebug.h (100%)
 rename {drivers/staging/unisys/include => include/linux/visorbus}/iochannel.h 
(100%)
 rename {drivers/staging/unisys/include => include/linux/visorbus}/version.h 
(100%)
 rename {drivers/staging/unisys/include => include/linux/visorbus}/visorbus.h 
(100%)

diff --git a/drivers/staging/unisys/MAINTAINERS 
b/drivers/staging/unisys/MAINTAINERS
index 1f0425b..146a8c3 100644
--- a/drivers/staging/unisys/MAINTAINERS
+++ b/drivers/staging/unisys/MAINTAINERS
@@ -1,5 +1,5 @@
 Unisys s-Par drivers
 M: David Kershner 
 S: Maintained
-F: Documentation/s-Par/overview.txt
+F: Documentation/visorbus.txt
 F: drivers/staging/unisys/
diff --git a/drivers/staging/unisys/visorbus/Makefile 
b/drivers/staging/unisys/visorbus/Makefile
index f3730d8..7f328cc 100644
--- a/drivers/staging/unisys/visorbus/Makefile
+++ b/drivers/staging/unisys/visorbus/Makefile
@@ -7,5 +7,3 @@ obj-$(CONFIG_UNISYS_VISORBUS)   += visorbus.o
 visorbus-y := visorbus_main.o
 visorbus-y += visorchannel.o
 visorbus-y += visorchipset.o
-
-ccflags-y += -Idrivers/staging/unisys/include
diff --git a/drivers/staging/unisys/visorbus/controlvmchannel.h 
b/drivers/staging/unisys/visorbus/controlvmchannel.h
index 03e36fb..0a0e221 100644
--- a/drivers/staging/unisys/visorbus/controlvmchannel.h
+++ b/drivers/staging/unisys/visorbus/controlvmchannel.h
@@ -16,7 +16,7 @@
 #define __CONTROLVMCHANNEL_H__
 
 #include 
-#include "channel.h"
+#include 
 
 /* {2B3C2D10-7EF5-4ad8-B966-3448B7386B3D} */
 #define SPAR_CONTROLVM_CHANNEL_PROTOCOL_UUID   \
diff --git a/drivers/staging/unisys/visorbus/vbuschannel.h 
b/drivers/staging/unisys/visorbus/vbuschannel.h
index 90fa12e..3e0388d 100644
--- a/drivers/staging/unisys/visorbus/vbuschannel.h
+++ b/drivers/staging/unisys/visorbus/vbuschannel.h
@@ -23,8 +23,9 @@
  *  the client devices and client drivers for the server end to see.
  */
 #include 
+#include 
+
 #include "vbusdeviceinfo.h"
-#include "channel.h"
 
 /* {193b331b-c58f-11da-95a9-00e08161165f} */
 #define SPAR_VBUS_CHANNEL_PROTOCOL_UUID \
diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 0a537c7..ac480fb 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -16,11 +16,11 @@
 
 #include 
 
-#include "visorbus.h"
+#include 
+#include 
+#include 
 #include "visorbus_private.h"
-#include "version.h"
 #include "vbuschannel.h"
-#include "guestlinuxdebug.h"
 #include "vmcallinterface.h"
 
 #define MYDRVNAME "visorbus"
diff --git a/drivers/staging/unisys/visorbus/visorchannel.c 
b/drivers/staging/unisys/visorbus/visorchannel.c
index 1b743d7.

[PATCH v2 26/27] Documentation: Move visorbus documentation from staging to Documentation/

[David Kershner]

This patch simple does a git mv of the
drivers/staging/unisys/Documentation directory to Documentation. Renames
overview.txt to visorbus.txt and renames sysfs-platform-visorchipset to
the correct name sysfs-bus-visorbus.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 .../ABI/stable/sysfs-bus-visorbus | 0
 .../unisys/Documentation/overview.txt => Documentation/visorbus.txt   | 0
 2 files changed, 0 insertions(+), 0 deletions(-)
 rename drivers/staging/unisys/Documentation/ABI/sysfs-platform-visorchipset => 
Documentation/ABI/stable/sysfs-bus-visorbus (100%)
 rename drivers/staging/unisys/Documentation/overview.txt => 
Documentation/visorbus.txt (100%)

diff --git 
a/drivers/staging/unisys/Documentation/ABI/sysfs-platform-visorchipset 
b/Documentation/ABI/stable/sysfs-bus-visorbus
similarity index 100%
rename from drivers/staging/unisys/Documentation/ABI/sysfs-platform-visorchipset
rename to Documentation/ABI/stable/sysfs-bus-visorbus
diff --git a/drivers/staging/unisys/Documentation/overview.txt 
b/Documentation/visorbus.txt
similarity index 100%
rename from drivers/staging/unisys/Documentation/overview.txt
rename to Documentation/visorbus.txt
-- 
1.9.1

--
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

[PATCH v2 04/27] staging: unisys: visorbus: remove unused module parameters

[David Kershner]

From: David Binder 

Removes unused module parameters from visorbus_main.c, in response to
findings by SonarQube.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 9 +
 1 file changed, 1 insertion(+), 8 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index d32b898..8278624 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -27,10 +27,9 @@
 #define MYDRVNAME "visorbus"
 
 /* module parameters */
-static int visorbus_debug;
 static int visorbus_forcematch;
 static int visorbus_forcenomatch;
-static int visorbus_debugref;
+
 #define SERIALLOOPBACKCHANADDR (100 * 1024 * 1024)
 
 /* Display string that is guaranteed to be no longer the 99 characters*/
@@ -1329,9 +1328,6 @@ visorbus_exit(void)
remove_bus_type();
 }
 
-module_param_named(debug, visorbus_debug, int, S_IRUGO);
-MODULE_PARM_DESC(visorbus_debug, "1 to debug");
-
 module_param_named(forcematch, visorbus_forcematch, int, S_IRUGO);
 MODULE_PARM_DESC(visorbus_forcematch,
 "1 to force a successful dev <--> drv match");
@@ -1339,6 +1335,3 @@ MODULE_PARM_DESC(visorbus_forcematch,
 module_param_named(forcenomatch, visorbus_forcenomatch, int, S_IRUGO);
 MODULE_PARM_DESC(visorbus_forcenomatch,
 "1 to force an UNsuccessful dev <--> drv match");
-
-module_param_named(debugref, visorbus_debugref, int, S_IRUGO);
-MODULE_PARM_DESC(visorbus_debugref, "1 to debug reference counting");
-- 
1.9.1

--
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

[PATCH v2 27/27] drivers: Add visorbus to the drivers directory

[David Kershner]

visorbus is currently located at drivers/staging/visorbus,
this patch moves it to drivers/virt.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/Kconfig| 3 +--
 drivers/staging/unisys/Makefile   | 1 -
 drivers/virt/Kconfig  | 2 ++
 drivers/virt/Makefile | 1 +
 drivers/{staging/unisys => virt}/visorbus/Kconfig | 0
 drivers/{staging/unisys => virt}/visorbus/Makefile| 0
 drivers/{staging/unisys => virt}/visorbus/controlvmchannel.h  | 0
 drivers/{staging/unisys => virt}/visorbus/controlvmcompletionstatus.h | 0
 drivers/{staging/unisys => virt}/visorbus/iovmcall_gnuc.h | 0
 drivers/{staging/unisys => virt}/visorbus/vbuschannel.h   | 0
 drivers/{staging/unisys => virt}/visorbus/vbusdeviceinfo.h| 0
 drivers/{staging/unisys => virt}/visorbus/vbushelper.h| 0
 drivers/{staging/unisys => virt}/visorbus/visorbus_main.c | 0
 drivers/{staging/unisys => virt}/visorbus/visorbus_private.h  | 0
 drivers/{staging/unisys => virt}/visorbus/visorchannel.c  | 0
 drivers/{staging/unisys => virt}/visorbus/visorchipset.c  | 0
 drivers/{staging/unisys => virt}/visorbus/vmcallinterface.h   | 0
 17 files changed, 4 insertions(+), 3 deletions(-)
 rename drivers/{staging/unisys => virt}/visorbus/Kconfig (100%)
 rename drivers/{staging/unisys => virt}/visorbus/Makefile (100%)
 rename drivers/{staging/unisys => virt}/visorbus/controlvmchannel.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/controlvmcompletionstatus.h 
(100%)
 rename drivers/{staging/unisys => virt}/visorbus/iovmcall_gnuc.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/vbuschannel.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/vbusdeviceinfo.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/vbushelper.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/visorbus_main.c (100%)
 rename drivers/{staging/unisys => virt}/visorbus/visorbus_private.h (100%)
 rename drivers/{staging/unisys => virt}/visorbus/visorchannel.c (100%)
 rename drivers/{staging/unisys => virt}/visorbus/visorchipset.c (100%)
 rename drivers/{staging/unisys => virt}/visorbus/vmcallinterface.h (100%)

diff --git a/drivers/staging/unisys/Kconfig b/drivers/staging/unisys/Kconfig
index 4f1f5e6..dab09a9 100644
--- a/drivers/staging/unisys/Kconfig
+++ b/drivers/staging/unisys/Kconfig
@@ -3,7 +3,7 @@
 #
 menuconfig UNISYSSPAR
bool "Unisys SPAR driver support"
-   depends on X86_64 && !UML
+   depends on X86_64 && !UML && VIRT_DRIVERS
select PCI
select ACPI
---help---
@@ -11,7 +11,6 @@ menuconfig UNISYSSPAR
 
 if UNISYSSPAR
 
-source "drivers/staging/unisys/visorbus/Kconfig"
 source "drivers/staging/unisys/visornic/Kconfig"
 source "drivers/staging/unisys/visorinput/Kconfig"
 source "drivers/staging/unisys/visorhba/Kconfig"
diff --git a/drivers/staging/unisys/Makefile b/drivers/staging/unisys/Makefile
index 20eb098..e45f44b 100644
--- a/drivers/staging/unisys/Makefile
+++ b/drivers/staging/unisys/Makefile
@@ -1,7 +1,6 @@
 #
 # Makefile for Unisys SPAR drivers
 #
-obj-$(CONFIG_UNISYS_VISORBUS)  += visorbus/
 obj-$(CONFIG_UNISYS_VISORNIC)  += visornic/
 obj-$(CONFIG_UNISYS_VISORINPUT)+= visorinput/
 obj-$(CONFIG_UNISYS_VISORHBA)  += visorhba/
diff --git a/drivers/virt/Kconfig b/drivers/virt/Kconfig
index 99ebdde..0c60896 100644
--- a/drivers/virt/Kconfig
+++ b/drivers/virt/Kconfig
@@ -30,4 +30,6 @@ config FSL_HV_MANAGER
   4) A kernel interface for receiving callbacks when a managed
 partition shuts down.
 
+source "drivers/virt/visorbus/Kconfig"
 endif
+
diff --git a/drivers/virt/Makefile b/drivers/virt/Makefile
index c47f04d..44aebd2 100644
--- a/drivers/virt/Makefile
+++ b/drivers/virt/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-$(CONFIG_FSL_HV_MANAGER)   += fsl_hypervisor.o
+obj-$(CONFIG_UNISYS_VISORBUS)  += visorbus/
diff --git a/drivers/staging/unisys/visorbus/Kconfig 
b/drivers/virt/visorbus/Kconfig
similarity index 100%
rename from drivers/staging/unisys/visorbus/Kconfig
rename to drivers/virt/visorbus/Kconfig
diff --git a/drivers/staging/unisys/visorbus/Makefile 
b/drivers/virt/visorbus/Makefile
similarity index 100%
rename from drivers/staging/unisys/visorbus/Makefile
rename to drivers/virt/visorbus/Makefile
diff --git a/drivers/staging/unisys/visorbus/controlvmchannel.h 
b/drivers/virt/visorbus/controlvmchannel.h
similarity index 100%
rename from drivers/staging/unisys/visorbus/controlvmchannel.h
rename to drivers/virt/visorbus/controlvmchannel.h
diff --git a/drivers/staging/unisys/visorbus/controlvmcompletionstatus.h 
b/drivers/virt/visorbus/controlvmcompletionstatus.h
similarity index 100%
rename from drivers/stagin

[PATCH v2 13/27] staging: unisys: visorbus: Make visordriver_callback_lock a mutex

[David Kershner]

From: Bryan Thompson 

visordriver_callback_lock is just a binary semaphore that logically
makes more sense as a mutex.

Signed-off-by: Bryan Thompson 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/visorbus.h   |  3 ++-
 drivers/staging/unisys/visorbus/visorbus_main.c | 10 +-
 2 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/unisys/include/visorbus.h 
b/drivers/staging/unisys/include/visorbus.h
index 9bb88bb..9da25c0 100644
--- a/drivers/staging/unisys/include/visorbus.h
+++ b/drivers/staging/unisys/include/visorbus.h
@@ -161,7 +161,8 @@ struct visor_device {
struct timer_list timer;
bool timer_active;
bool being_removed;
-   struct semaphore visordriver_callback_lock;
+   /* mutex to serialize visor_driver function callbacks */
+   struct mutex visordriver_callback_lock;
bool pausing;
bool resuming;
u32 chipset_bus_no;
diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 24b27ff..44609ee 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -574,7 +574,7 @@ visordriver_probe_device(struct device *xdev)
if (!drv->probe)
return -ENODEV;
 
-   down(&dev->visordriver_callback_lock);
+   mutex_lock(&dev->visordriver_callback_lock);
dev->being_removed = false;
 
res = drv->probe(dev);
@@ -584,7 +584,7 @@ visordriver_probe_device(struct device *xdev)
fix_vbus_dev_info(dev);
}
 
-   up(&dev->visordriver_callback_lock);
+   mutex_unlock(&dev->visordriver_callback_lock);
return res;
 }
 
@@ -600,11 +600,11 @@ visordriver_remove_device(struct device *xdev)
 
dev = to_visor_device(xdev);
drv = to_visor_driver(xdev->driver);
-   down(&dev->visordriver_callback_lock);
+   mutex_lock(&dev->visordriver_callback_lock);
dev->being_removed = true;
if (drv->remove)
drv->remove(dev);
-   up(&dev->visordriver_callback_lock);
+   mutex_unlock(&dev->visordriver_callback_lock);
dev_stop_periodic_work(dev);
 
put_device(&dev->device);
@@ -764,7 +764,7 @@ create_visor_device(struct visor_device *dev)
POSTCODE_LINUX_4(DEVICE_CREATE_ENTRY_PC, chipset_dev_no, chipset_bus_no,
 POSTCODE_SEVERITY_INFO);
 
-   sema_init(&dev->visordriver_callback_lock, 1);  /* unlocked */
+   mutex_init(&dev->visordriver_callback_lock);
dev->device.bus = &visorbus_type;
dev->device.groups = visorbus_channel_groups;
device_initialize(&dev->device);
-- 
1.9.1

--
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

[PATCH v2 16/27] staging: unisys: Remove reference to unused STANDALONE_CLIENT

[David Kershner]

From: Bryan Thompson 

The STANDALONE_CLIENT define is no longer used by Unisys driver code.

Signed-off-by: Bryan Thompson 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/visorbus.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/unisys/include/visorbus.h 
b/drivers/staging/unisys/include/visorbus.h
index 2fd3016..94dd48e 100644
--- a/drivers/staging/unisys/include/visorbus.h
+++ b/drivers/staging/unisys/include/visorbus.h
@@ -177,7 +177,6 @@ struct visor_device {
 
 #define to_visor_device(x) container_of(x, struct visor_device, device)
 
-#ifndef STANDALONE_CLIENT
 int visorbus_register_visor_driver(struct visor_driver *);
 void visorbus_unregister_visor_driver(struct visor_driver *);
 int visorbus_read_channel(struct visor_device *dev,
@@ -188,7 +187,6 @@ int visorbus_write_channel(struct visor_device *dev,
   unsigned long nbytes);
 void visorbus_enable_channel_interrupts(struct visor_device *dev);
 void visorbus_disable_channel_interrupts(struct visor_device *dev);
-#endif
 
 /* Note that for visorchannel_create()
  *  and  arguments may be 0 if we are a channel CLIENT.
-- 
1.9.1

--
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

[PATCH v2 12/27] staging: unisys: visorbus: remove periodic_work.h/.c

[David Kershner]

From: Tim Sell 

These files were made no-longer-necessary by recent commits.

Signed-off-by: Tim Sell 
Signed-off-by: David Kershner 
---
 drivers/staging/unisys/include/periodic_work.h  |  40 -
 drivers/staging/unisys/visorbus/Makefile|   1 -
 drivers/staging/unisys/visorbus/periodic_work.c | 204 
 drivers/staging/unisys/visorbus/visorchipset.c  |   1 -
 4 files changed, 246 deletions(-)
 delete mode 100644 drivers/staging/unisys/include/periodic_work.h
 delete mode 100644 drivers/staging/unisys/visorbus/periodic_work.c

diff --git a/drivers/staging/unisys/include/periodic_work.h 
b/drivers/staging/unisys/include/periodic_work.h
deleted file mode 100644
index 0b3335a..000
--- a/drivers/staging/unisys/include/periodic_work.h
+++ /dev/null
@@ -1,40 +0,0 @@
-/* periodic_work.h
- *
- * Copyright (C) 2010 - 2013 UNISYS CORPORATION
- * All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or (at
- * your option) any later version.
- *
- * 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, GOOD TITLE or
- * NON INFRINGEMENT.  See the GNU General Public License for more
- * details.
- */
-
-#ifndef __PERIODIC_WORK_H__
-#define __PERIODIC_WORK_H__
-
-#include 
-#include 
-
-/* PERIODIC_WORK an opaque structure to users.
- * Fields are declared only in the implementation .c files.
- */
-struct periodic_work;
-
-struct periodic_work *
-visor_periodic_work_create(ulong jiffy_interval,
-  struct workqueue_struct *workqueue,
-  void (*workfunc)(void *),
-  void *workfuncarg,
-  const char *devnam);
-void visor_periodic_work_destroy(struct periodic_work *pw);
-bool visor_periodic_work_nextperiod(struct periodic_work *pw);
-bool visor_periodic_work_start(struct periodic_work *pw);
-bool visor_periodic_work_stop(struct periodic_work *pw);
-
-#endif
diff --git a/drivers/staging/unisys/visorbus/Makefile 
b/drivers/staging/unisys/visorbus/Makefile
index fc790e7..f3730d8 100644
--- a/drivers/staging/unisys/visorbus/Makefile
+++ b/drivers/staging/unisys/visorbus/Makefile
@@ -7,6 +7,5 @@ obj-$(CONFIG_UNISYS_VISORBUS)   += visorbus.o
 visorbus-y := visorbus_main.o
 visorbus-y += visorchannel.o
 visorbus-y += visorchipset.o
-visorbus-y += periodic_work.o
 
 ccflags-y += -Idrivers/staging/unisys/include
diff --git a/drivers/staging/unisys/visorbus/periodic_work.c 
b/drivers/staging/unisys/visorbus/periodic_work.c
deleted file mode 100644
index 00b1527..000
--- a/drivers/staging/unisys/visorbus/periodic_work.c
+++ /dev/null
@@ -1,204 +0,0 @@
-/* periodic_work.c
- *
- * Copyright (C) 2010 - 2015 UNISYS CORPORATION
- * All rights reserved.
- *
- * This program is free software; you can redistribute it and/or modify it
- * under the terms and conditions of the GNU General Public License,
- * 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, GOOD TITLE or
- * NON INFRINGEMENT.  See the GNU General Public License for more
- * details.
- */
-
-/*
- *  Helper functions to schedule periodic work in Linux kernel mode.
- */
-#include 
-
-#include "periodic_work.h"
-
-#define MYDRVNAME "periodic_work"
-
-struct periodic_work {
-   rwlock_t lock;
-   struct delayed_work work;
-   void (*workfunc)(void *);
-   void *workfuncarg;
-   bool is_scheduled;
-   bool want_to_stop;
-   ulong jiffy_interval;
-   struct workqueue_struct *workqueue;
-   const char *devnam;
-};
-
-static void periodic_work_func(struct work_struct *work)
-{
-   struct periodic_work *pw;
-
-   pw = container_of(work, struct periodic_work, work.work);
-   (*pw->workfunc)(pw->workfuncarg);
-}
-
-struct periodic_work
-*visor_periodic_work_create(ulong jiffy_interval,
-   struct workqueue_struct *workqueue,
-   void (*workfunc)(void *),
-   void *workfuncarg,
-   const char *devnam)
-{
-   struct periodic_work *pw;
-
-   pw = kzalloc(sizeof(*pw), GFP_KERNEL | __GFP_NORETRY);
-   if (!pw)
-   return NULL;
-
-   rwlock_init(&pw->lock);
-   pw->jiffy_interval = jiffy_interval;
-   pw->workqueue = workqueue;
-   pw->workfunc = workfunc;
-   pw->workfuncarg = workfuncarg;
-   pw->devnam = devnam;
-   return pw;
-}
-EXPORT_SYMBOL_GPL(visor_periodic_work_create);
-
-void visor_periodic_work_destroy(struct periodic_work *pw)
-{
-   kfree(

[PATCH v2 17/27] staging: unisys: visorbus: vbusdeviceinfo function descriptions more kerneldoc-like

[David Kershner]

From: David Binder 

Per audit feedback from Thomas Gleixner, function descriptions in
vbusdeviceinfo.h now utilize a more kerneldoc-like formatting. The
affected comments do not implement other kerneldoc requirements.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/vbusdeviceinfo.h | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/vbusdeviceinfo.h 
b/drivers/staging/unisys/visorbus/vbusdeviceinfo.h
index abdab4a..010ea68 100644
--- a/drivers/staging/unisys/visorbus/vbusdeviceinfo.h
+++ b/drivers/staging/unisys/visorbus/vbusdeviceinfo.h
@@ -34,7 +34,8 @@ struct ultra_vbus_deviceinfo {
 
 #pragma pack(pop)
 
-/* Reads chars from the buffer at  for  bytes, and writes to
+/**
+ * Reads chars from the buffer at  for  bytes, and writes to
  * the buffer at , which is  bytes long, ensuring never to
  * overflow the buffer at , using the following rules:
  * - printable characters are simply copied from the buffer at  to the
@@ -92,7 +93,8 @@ vbuschannel_sanitize_buffer(char *p, int remain, char *src, 
int srcmax)
p++;  chars++;  remain--;  \
} while (0)
 
-/* Converts the non-negative value at  to an ascii decimal string
+/**
+ * Converts the non-negative value at  to an ascii decimal string
  * at , writing at most  bytes.  Note there is NO '\0' termination
  * written to .
  *
@@ -141,8 +143,9 @@ vbuschannel_itoa(char *p, int remain, int num)
return digits;
 }
 
-/* Reads , and converts its contents to a printable string at ,
- * writing at most  bytes.  Note there is NO '\0' termination
+/**
+ * Reads , and converts its contents to a printable string at ,
+ * writing at most  bytes. Note there is NO '\0' termination
  * written to .
  *
  * Pass  >= 0 if you want a device index presented.
-- 
1.9.1

--
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

[PATCH v2 03/27] staging: unisys: iovmcall_gnuc.h change -1 return values

[David Kershner]

From: Erik Arfvidson 

This patch changes the vague -1 return values to -EPERM.
This operation is not supported is a good alternative
to -1 because the return is basically telling the caller
that the processor doesn't support vmcall operations.

Signed-off-by: Erik Arfvidson 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/iovmcall_gnuc.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/iovmcall_gnuc.h 
b/drivers/staging/unisys/visorbus/iovmcall_gnuc.h
index b08b6ec..98ea7f3 100644
--- a/drivers/staging/unisys/visorbus/iovmcall_gnuc.h
+++ b/drivers/staging/unisys/visorbus/iovmcall_gnuc.h
@@ -22,7 +22,7 @@ __unisys_vmcall_gnuc(unsigned long tuple, unsigned long 
reg_ebx,
 
cpuid(0x0001, &cpuid_eax, &cpuid_ebx, &cpuid_ecx, &cpuid_edx);
if (!(cpuid_ecx & 0x8000))
-   return -1;
+   return -EPERM;
 
__asm__ __volatile__(".byte 0x00f, 0x001, 0x0c1" : "=a"(result) :
"a"(tuple), "b"(reg_ebx), "c"(reg_ecx));
@@ -40,7 +40,7 @@ __unisys_extended_vmcall_gnuc(unsigned long long tuple,
 
cpuid(0x0001, &cpuid_eax, &cpuid_ebx, &cpuid_ecx, &cpuid_edx);
if (!(cpuid_ecx & 0x8000))
-   return -1;
+   return -EPERM;
 
__asm__ __volatile__(".byte 0x00f, 0x001, 0x0c1" : "=a"(result) :
"a"(tuple), "b"(reg_ebx), "c"(reg_ecx), "d"(reg_edx));
-- 
1.9.1

--
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

[PATCH v2 14/27] staging: unisys: visorbus: Remove unnecessary EXPORT_SYMBOL statements

[David Kershner]

From: Bryan Thompson 

The driver that is now visorbus started out as multiple separate drivers,
and when they were merged the EXPORT_SYMBOL statements that were required
for separate drivers were left in the code. This patch removes those now
unnecessary exports.

Signed-off-by: Bryan Thompson 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_main.c |  1 -
 drivers/staging/unisys/visorbus/visorchannel.c  | 17 -
 drivers/staging/unisys/visorbus/visorchipset.c  |  2 --
 3 files changed, 20 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 44609ee..247a9ad 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -721,7 +721,6 @@ visorbus_clear_channel(struct visor_device *dev, unsigned 
long offset, u8 ch,
 {
return visorchannel_clear(dev->visorchannel, offset, ch, nbytes);
 }
-EXPORT_SYMBOL_GPL(visorbus_clear_channel);
 
 /** We don't really have a real interrupt, so for now we just call the
  *  interrupt function periodically...
diff --git a/drivers/staging/unisys/visorbus/visorchannel.c 
b/drivers/staging/unisys/visorbus/visorchannel.c
index 4337358..1f626c3 100644
--- a/drivers/staging/unisys/visorbus/visorchannel.c
+++ b/drivers/staging/unisys/visorbus/visorchannel.c
@@ -148,7 +148,6 @@ visorchannel_create(u64 physaddr, unsigned long 
channel_bytes,
return visorchannel_create_guts(physaddr, channel_bytes, gfp, 0, guid,
false);
 }
-EXPORT_SYMBOL_GPL(visorchannel_create);
 
 struct visorchannel *
 visorchannel_create_with_lock(u64 physaddr, unsigned long channel_bytes,
@@ -157,7 +156,6 @@ visorchannel_create_with_lock(u64 physaddr, unsigned long 
channel_bytes,
return visorchannel_create_guts(physaddr, channel_bytes, gfp, 0, guid,
true);
 }
-EXPORT_SYMBOL_GPL(visorchannel_create_with_lock);
 
 void
 visorchannel_destroy(struct visorchannel *channel)
@@ -171,21 +169,18 @@ visorchannel_destroy(struct visorchannel *channel)
}
kfree(channel);
 }
-EXPORT_SYMBOL_GPL(visorchannel_destroy);
 
 u64
 visorchannel_get_physaddr(struct visorchannel *channel)
 {
return channel->physaddr;
 }
-EXPORT_SYMBOL_GPL(visorchannel_get_physaddr);
 
 ulong
 visorchannel_get_nbytes(struct visorchannel *channel)
 {
return channel->nbytes;
 }
-EXPORT_SYMBOL_GPL(visorchannel_get_nbytes);
 
 char *
 visorchannel_uuid_id(uuid_le *guid, char *s)
@@ -193,28 +188,24 @@ visorchannel_uuid_id(uuid_le *guid, char *s)
sprintf(s, "%pUL", guid);
return s;
 }
-EXPORT_SYMBOL_GPL(visorchannel_uuid_id);
 
 char *
 visorchannel_id(struct visorchannel *channel, char *s)
 {
return visorchannel_uuid_id(&channel->guid, s);
 }
-EXPORT_SYMBOL_GPL(visorchannel_id);
 
 char *
 visorchannel_zoneid(struct visorchannel *channel, char *s)
 {
return visorchannel_uuid_id(&channel->chan_hdr.zone_uuid, s);
 }
-EXPORT_SYMBOL_GPL(visorchannel_zoneid);
 
 u64
 visorchannel_get_clientpartition(struct visorchannel *channel)
 {
return channel->chan_hdr.partition_handle;
 }
-EXPORT_SYMBOL_GPL(visorchannel_get_clientpartition);
 
 int
 visorchannel_set_clientpartition(struct visorchannel *channel,
@@ -223,7 +214,6 @@ visorchannel_set_clientpartition(struct visorchannel 
*channel,
channel->chan_hdr.partition_handle = partition_handle;
return 0;
 }
-EXPORT_SYMBOL_GPL(visorchannel_set_clientpartition);
 
 uuid_le
 visorchannel_get_uuid(struct visorchannel *channel)
@@ -243,7 +233,6 @@ visorchannel_read(struct visorchannel *channel, ulong 
offset,
 
return 0;
 }
-EXPORT_SYMBOL_GPL(visorchannel_read);
 
 int
 visorchannel_write(struct visorchannel *channel, ulong offset,
@@ -265,7 +254,6 @@ visorchannel_write(struct visorchannel *channel, ulong 
offset,
 
return 0;
 }
-EXPORT_SYMBOL_GPL(visorchannel_write);
 
 int
 visorchannel_clear(struct visorchannel *channel, ulong offset, u8 ch,
@@ -301,14 +289,12 @@ out_free_page:
free_page((unsigned long)buf);
return err;
 }
-EXPORT_SYMBOL_GPL(visorchannel_clear);
 
 void __iomem  *
 visorchannel_get_header(struct visorchannel *channel)
 {
return (void __iomem *)&channel->chan_hdr;
 }
-EXPORT_SYMBOL_GPL(visorchannel_get_header);
 
 /** Return offset of a specific SIGNAL_QUEUE_HEADER from the beginning of a
  *  channel header
@@ -522,7 +508,6 @@ visorchannel_signalqueue_slots_avail(struct visorchannel 
*channel, u32 queue)
slots_avail = sig_hdr.max_signals - slots_used;
return (int)slots_avail;
 }
-EXPORT_SYMBOL_GPL(visorchannel_signalqueue_slots_avail);
 
 int
 visorchannel_signalqueue_max_slots(struct visorchannel *channel, u32 queue)
@@ -533,7 +518,6 @@ visorchannel_signalqueue_max_slots(struct visorchannel 
*channel, u32 queue)
return 0;
return (int)sig_hdr.max

[PATCH v2 08/27] staging: unisys: include: Remove thread-related enum members

[David Kershner]

From: David Binder 

Code relating to ktheads was previously removed from s-Par driver code.
This patch cleans up lingering remnants of kthreads by removing thread-
related enum types.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/guestlinuxdebug.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/unisys/include/guestlinuxdebug.h 
b/drivers/staging/unisys/include/guestlinuxdebug.h
index b81287f..5af3f77 100644
--- a/drivers/staging/unisys/include/guestlinuxdebug.h
+++ b/drivers/staging/unisys/include/guestlinuxdebug.h
@@ -56,7 +56,7 @@ enum driver_pc {  /* POSTCODE driver identifier 
tuples */
UISLIB_PC = 0xD0,
UISLIB_PC_uislib_c = 0xD1,
UISLIB_PC_uisqueue_c = 0xD2,
-   UISLIB_PC_uisthread_c = 0xD3,
+   /* 0xD3 RESERVED */
UISLIB_PC_uisutils_c = 0xD4,
 };
 
@@ -91,7 +91,7 @@ enum event_pc {   /* POSTCODE event 
identifier tuples */
DRIVER_EXIT_PC = 0x0AC,
MALLOC_FAILURE_PC = 0x0AD,
QUEUE_DELAYED_WORK_PC = 0x0AE,
-   UISLIB_THREAD_FAILURE_PC = 0x0B7,
+   /* 0x0B7 RESERVED */
VBUS_CHANNEL_ENTRY_PC = 0x0B8,
VBUS_CHANNEL_FAILURE_PC = 0x0B9,
VBUS_CHANNEL_EXIT_PC = 0x0BA,
-- 
1.9.1

--
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

[PATCH v2 05/27] staging: unisys: visorbus: remove unused struct

[David Kershner]

From: David Binder 

Removes unused struct definition, channel_size_info, in response to
findings by SonarQube.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 8278624..cb08ce4 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -1257,12 +1257,6 @@ chipset_device_resume(struct visor_device *dev_info)
initiate_chipset_device_pause_resume(dev_info, false);
 }
 
-struct channel_size_info {
-   uuid_le guid;
-   unsigned long min_size;
-   unsigned long max_size;
-};
-
 int
 visorbus_init(void)
 {
-- 
1.9.1

--
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

[PATCH v2 02/27] staging: unisys: visorchipset change -1 return value

[David Kershner]

From: Erik Arfvidson 

This patch changes the vague -1 return value to -EINVAL

Signed-off-by: Erik Arfvidson 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 5ba5936..d248c94 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -1613,7 +1613,7 @@ parahotplug_request_complete(int id, u16 active)
}
 
spin_unlock(¶hotplug_request_list_lock);
-   return -1;
+   return -EINVAL;
 }
 
 /*
-- 
1.9.1

--
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

[PATCH v2 07/27] staging: unisys: visornic: Correct comment spelling mistake

[David Kershner]

From: David Binder 

Fixes a comment spelling mistake in visornic.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visornic/visornic_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visornic/visornic_main.c 
b/drivers/staging/unisys/visornic/visornic_main.c
index fd7c9a6..9e5b258 100644
--- a/drivers/staging/unisys/visornic/visornic_main.c
+++ b/drivers/staging/unisys/visornic/visornic_main.c
@@ -1587,7 +1587,7 @@ drain_resp_queue(struct uiscmdrsp *cmdrsp, struct 
visornic_devdata *devdata)
  *
  * Drain the respones queue of any responses from the IO partition.
  * Process the responses as we get them.
- * Returns when response queue is empty or when the threadd stops.
+ * Returns when response queue is empty or when the thread stops.
  */
 static void
 service_resp_queue(struct uiscmdrsp *cmdrsp, struct visornic_devdata *devdata,
-- 
1.9.1

--
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

[PATCH v2 01/27] staging: unisys: visorbus change -1 return values

[David Kershner]

From: Erik Arfvidson 

This patch changes the vague -1 return values to -EFAULT since
it would be the most appropriate, given that this error
would only occur in an unexpected bad offset field.
Resulting in a bad address.

Signed-off-by: Erik Arfvidson 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 3a147db..d32b898 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -876,10 +876,10 @@ write_vbus_chp_info(struct visorchannel *chan,
int off = sizeof(struct channel_header) + hdr_info->chp_info_offset;
 
if (hdr_info->chp_info_offset == 0)
-   return -1;
+   return -EFAULT;
 
if (visorchannel_write(chan, off, info, sizeof(*info)) < 0)
-   return -1;
+   return -EFAULT;
return 0;
 }
 
@@ -895,10 +895,10 @@ write_vbus_bus_info(struct visorchannel *chan,
int off = sizeof(struct channel_header) + hdr_info->bus_info_offset;
 
if (hdr_info->bus_info_offset == 0)
-   return -1;
+   return -EFAULT;
 
if (visorchannel_write(chan, off, info, sizeof(*info)) < 0)
-   return -1;
+   return -EFAULT;
return 0;
 }
 
@@ -915,10 +915,10 @@ write_vbus_dev_info(struct visorchannel *chan,
(hdr_info->device_info_struct_bytes * devix);
 
if (hdr_info->dev_info_offset == 0)
-   return -1;
+   return -EFAULT;
 
if (visorchannel_write(chan, off, info, sizeof(*info)) < 0)
-   return -1;
+   return -EFAULT;
return 0;
 }
 
-- 
1.9.1

--
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

[PATCH v2 09/27] staging: unisys: visorbus: removed unused periodic_test_workqueue

[David Kershner]

From: Tim Sell 

periodic_test_workqueue was an unused relic from the past, and was removed.

Signed-off-by: Tim Sell 
Signed-off-by: David Kershner 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 15 ---
 1 file changed, 15 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index c30b4b2..608ca1a 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -116,14 +116,6 @@ struct bus_type visorbus_type = {
.bus_groups = visorbus_bus_groups,
 };
 
-static struct delayed_work periodic_work;
-
-/* YES, we need 2 workqueues.
- * The reason is, workitems on the test queue may need to cancel
- * workitems on the other queue.  You will be in for trouble if you try to
- * do this with workitems queued on the same workqueue.
- */
-static struct workqueue_struct *periodic_test_workqueue;
 static struct workqueue_struct *periodic_dev_workqueue;
 static long long bus_count;/** number of bus instances */
/** ever-increasing */
@@ -1306,13 +1298,6 @@ visorbus_exit(void)
destroy_workqueue(periodic_dev_workqueue);
periodic_dev_workqueue = NULL;
 
-   if (periodic_test_workqueue) {
-   cancel_delayed_work(&periodic_work);
-   flush_workqueue(periodic_test_workqueue);
-   destroy_workqueue(periodic_test_workqueue);
-   periodic_test_workqueue = NULL;
-   }
-
list_for_each_safe(listentry, listtmp, &list_all_bus_instances) {
struct visor_device *dev = list_entry(listentry,
  struct visor_device,
-- 
1.9.1

--
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

[PATCH v2 00/27] Fixed issues raised by tglx, then move visorbus to drivers/virt

[David Kershner]

tglx: The following patchset fixes issues you raised during your
code review of visorbus on 5/18.

Greg: Please drop all other patch series sent in from me as this
patch series incorporates the required patches from the previous
series. 

Converts visorbus to use a kernel timer for periodic device-specific
callbacks instead of a workqueue, making the implementation in
periodic_work.c and periodic_work.h no longer necessary.  These files
are then deleted.

The visordriver_callback_lock has been switched to a mutex.

Several module parameters and structures were removed that were no
longer being used.

Changes since v1: 

 - Added the patch staging: unisys: visorbus change -1 return values
 - Added the patch staging: unisys: visorchipset change -1 return value
 - Added the patch staging: unisys: iovmcall_gnuc.h change -1 return values

Bryan Thompson (4):
  staging: unisys: visorbus: Make visordriver_callback_lock a mutex
  staging: unisys: visorbus: Remove unnecessary EXPORT_SYMBOL statements
  staging: unisys: visorbus: Remove unused functions
  staging: unisys: Remove reference to unused STANDALONE_CLIENT

David Binder (12):
  staging: unisys: visorbus: remove unused module parameters
  staging: unisys: visorbus: remove unused struct
  staging: unisys: visorbus: modify format string to match argument
  staging: unisys: visornic: Correct comment spelling mistake
  staging: unisys: include: Remove thread-related enum members
  staging: unisys: visorbus: vbusdeviceinfo function descriptions more
kerneldoc-like
  staging: unisys: visorbus: make function descriptions more
kerneldoc-like
  staging: unisys: visorbus: make visorbus_private.h function
descriptions more kerneldoc-like
  staging: unisys: visorbus: make visorchannel function descriptions
more kerneldoc-like
  staging: unisys: visorbus: make visorchipset function descriptions
more kerneldoc-like
  staging: unisys: visorbus: Move visorbus-unique functions to private
header
  staging: unisys: visorbus: Add kerneldoc-style comments for visorbus
API

David Kershner (4):
  staging: unisys: Move vbushelper.h to visorbus directory
  include: linux: visorbus: Add visorbus to include/linux directory
  Documentation: Move visorbus documentation from staging to
Documentation/
  drivers: Add visorbus to the drivers directory

Erik Arfvidson (3):
  staging: unisys: visorbus change -1 return values
  staging: unisys: visorchipset change -1 return value
  staging: unisys: iovmcall_gnuc.h change -1 return values

Tim Sell (4):
  staging: unisys: visorbus: removed unused periodic_test_workqueue
  staging: unisys: visorinput: remove unnecessary locking
  staging: unisys: visorbus: use kernel timer instead of workqueue
  staging: unisys: visorbus: remove periodic_work.h/.c

 .../ABI/stable/sysfs-bus-visorbus  |0
 .../overview.txt => Documentation/visorbus.txt |0
 drivers/staging/unisys/Kconfig |3 +-
 drivers/staging/unisys/MAINTAINERS |2 +-
 drivers/staging/unisys/Makefile|1 -
 drivers/staging/unisys/include/periodic_work.h |   40 -
 drivers/staging/unisys/include/visorbus.h  |  234 
 drivers/staging/unisys/visorbus/Makefile   |   12 -
 drivers/staging/unisys/visorbus/periodic_work.c|  204 ---
 drivers/staging/unisys/visorbus/visorbus_main.c| 1344 
 drivers/staging/unisys/visorbus/visorbus_private.h |   68 -
 drivers/staging/unisys/visorbus/visorchannel.c |  635 -
 drivers/staging/unisys/visorhba/Makefile   |2 -
 drivers/staging/unisys/visorhba/visorhba_main.c|5 +-
 drivers/staging/unisys/visorinput/Makefile |2 -
 drivers/staging/unisys/visorinput/visorinput.c |   63 +-
 drivers/staging/unisys/visornic/Makefile   |2 -
 drivers/staging/unisys/visornic/visornic_main.c|7 +-
 drivers/virt/Kconfig   |2 +
 drivers/virt/Makefile  |1 +
 drivers/{staging/unisys => virt}/visorbus/Kconfig  |0
 drivers/virt/visorbus/Makefile |9 +
 .../unisys => virt}/visorbus/controlvmchannel.h|2 +-
 .../visorbus/controlvmcompletionstatus.h   |0
 .../unisys => virt}/visorbus/iovmcall_gnuc.h   |4 +-
 .../unisys => virt}/visorbus/vbuschannel.h |3 +-
 .../unisys => virt}/visorbus/vbusdeviceinfo.h  |   11 +-
 .../unisys/include => virt/visorbus}/vbushelper.h  |0
 drivers/virt/visorbus/visorbus_main.c  | 1260 ++
 drivers/virt/visorbus/visorbus_private.h   |   96 ++
 drivers/virt/visorbus/visorchannel.c   |  459 +++
 .../unisys => virt}/visorbus/visorchipset.c|   54 +-
 .../unisys => virt}/visorbus/vmcallinterface.h |5 +-
 .../include => include/linux/visorbus}/channel.h   |0
 .../linux/visorbus}/channel_guid.h |0
 .../linux/visorbus

[PATCH v2 19/27] staging: unisys: visorbus: make visorbus_private.h function descriptions more kerneldoc-like

[David Kershner]

From: David Binder 

Per audit feedback from Thomas Gleixner, function descriptions in
visorbus_private.h now utilize a more kerneldoc-like formatting. The
affected comments do not implement other kerneldoc requirements.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_private.h | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_private.h 
b/drivers/staging/unisys/visorbus/visorbus_private.h
index 39edd20..f48f230 100644
--- a/drivers/staging/unisys/visorbus/visorbus_private.h
+++ b/drivers/staging/unisys/visorbus/visorbus_private.h
@@ -51,10 +51,11 @@ struct visorchipset_busdev_responders {
void (*device_resume)(struct visor_device *p, int response);
 };
 
-/** Register functions (in the bus driver) to get called by visorchipset
- *  whenever a bus or device appears for which this guest is to be the
- *  client for.  visorchipset will fill in , to indicate
- *  functions the bus driver should call to indicate message responses.
+/**
+ * Register functions (in the bus driver) to get called by visorchipset
+ * whenever a bus or device appears for which this guest is to be the
+ * client for.  visorchipset will fill in , to indicate
+ * functions the bus driver should call to indicate message responses.
  */
 void
 visorchipset_register_busdev(
-- 
1.9.1

--
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

[PATCH v2 18/27] staging: unisys: visorbus: make function descriptions more kerneldoc-like

[David Kershner]

From: David Binder 

Per audit feedback from Thomas Gleixner, function descriptions in
visorbus_main.c now utilize a more kerneldoc-like formatting. The affected
comments do not implement other kerneldoc requirements.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorbus_main.c | 178 +---
 1 file changed, 98 insertions(+), 80 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index c3f53fb..850998e 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -166,7 +166,8 @@ visorbus_uevent(struct device *xdev, struct kobj_uevent_env 
*env)
return 0;
 }
 
-/* This is called automatically upon adding a visor_device (device_add), or
+/**
+ * This is called automatically upon adding a visor_device (device_add), or
  * adding a visor_driver (visorbus_register_visor_driver), and returns 1 iff 
the
  * provided driver can control the specified device.
  */
@@ -200,9 +201,10 @@ visorbus_match(struct device *xdev, struct device_driver 
*xdrv)
return 0;
 }
 
-/** This is called when device_unregister() is called for the bus device
- *  instance, after all other tasks involved with destroying the device
- *  are complete.
+/**
+ * This is called when device_unregister() is called for the bus device
+ * instance, after all other tasks involved with destroying the device
+ * are complete.
  */
 static void
 visorbus_release_busdevice(struct device *xdev)
@@ -212,8 +214,9 @@ visorbus_release_busdevice(struct device *xdev)
kfree(dev);
 }
 
-/** This is called when device_unregister() is called for each child
- *  device instance.
+/**
+ * This is called when device_unregister() is called for each child
+ * device instance.
  */
 static void
 visorbus_release_device(struct device *xdev)
@@ -556,10 +559,11 @@ dev_stop_periodic_work(struct visor_device *dev)
put_device(&dev->device);
 }
 
-/** This is called automatically upon adding a visor_device (device_add), or
- *  adding a visor_driver (visorbus_register_visor_driver), but only after
- *  visorbus_match has returned 1 to indicate a successful match between
- *  driver and device.
+/**
+ * This is called automatically upon adding a visor_device (device_add), or
+ * adding a visor_driver (visorbus_register_visor_driver), but only after
+ * visorbus_match has returned 1 to indicate a successful match between
+ * driver and device.
  */
 static int
 visordriver_probe_device(struct device *xdev)
@@ -588,9 +592,10 @@ visordriver_probe_device(struct device *xdev)
return res;
 }
 
-/** This is called when device_unregister() is called for each child device
- *  instance, to notify the appropriate visorbus_driver that the device is
- *  going away, and to decrease the reference count of the device.
+/**
+ * This is called when device_unregister() is called for each child device
+ * instance, to notify the appropriate visorbus_driver that the device is
+ * going away, and to decrease the reference count of the device.
  */
 static int
 visordriver_remove_device(struct device *xdev)
@@ -611,47 +616,47 @@ visordriver_remove_device(struct device *xdev)
return 0;
 }
 
-/** A particular type of visor driver calls this function to register
- *  the driver.  The caller MUST fill in the following fields within the
- *  #drv structure:
- *  name, version, owner, channel_types, probe, remove
+/**
+ * A particular type of visor driver calls this function to register
+ * the driver.  The caller MUST fill in the following fields within the
+ * #drv structure:
+ * name, version, owner, channel_types, probe, remove
  *
- *  Here's how the whole Linux bus / driver / device model works.
+ * Here's how the whole Linux bus / driver / device model works.
  *
- *  At system start-up, the visorbus kernel module is loaded, which registers
- *  visorbus_type as a bus type, using bus_register().
+ * At system start-up, the visorbus kernel module is loaded, which registers
+ * visorbus_type as a bus type, using bus_register().
  *
- *  All kernel modules that support particular device types on a
- *  visorbus bus are loaded.  Each of these kernel modules calls
- *  visorbus_register_visor_driver() in their init functions, passing a
- *  visor_driver struct.  visorbus_register_visor_driver() in turn calls
- *  register_driver(&visor_driver.driver).  This .driver member is
- *  initialized with generic methods (like probe), whose sole responsibility
- *  is to act as a broker for the real methods, which are within the
- *  visor_driver struct.  (This is the way the subclass behavior is
- *  implemented, since visor_driver is essentially a subclass of the
- *  generic driver.)  Whenever a driver_register() happens, core bus code in
- *  the kernel does (see device_attach() in drivers/base/dd.c):
+ * All kernel modules that sup

[PATCH v2 15/27] staging: unisys: visorbus: Remove unused functions

[David Kershner]

From: Bryan Thompson 

Remove visorbus_clear_channel, visorchannel_signalqueue_slots_avail,
visorchannel_signalqueue_max_slots, visorchannel_clear, and
visorchannel_debug which are no longer called by any driver.

Signed-off-by: Bryan Thompson 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/visorbus.h   |   9 --
 drivers/staging/unisys/visorbus/visorbus_main.c |   7 --
 drivers/staging/unisys/visorbus/visorchannel.c  | 161 
 3 files changed, 177 deletions(-)

diff --git a/drivers/staging/unisys/include/visorbus.h 
b/drivers/staging/unisys/include/visorbus.h
index 9da25c0..2fd3016 100644
--- a/drivers/staging/unisys/include/visorbus.h
+++ b/drivers/staging/unisys/include/visorbus.h
@@ -186,8 +186,6 @@ int visorbus_read_channel(struct visor_device *dev,
 int visorbus_write_channel(struct visor_device *dev,
   unsigned long offset, void *src,
   unsigned long nbytes);
-int visorbus_clear_channel(struct visor_device *dev,
-  unsigned long offset, u8 ch, unsigned long nbytes);
 void visorbus_enable_channel_interrupts(struct visor_device *dev);
 void visorbus_disable_channel_interrupts(struct visor_device *dev);
 #endif
@@ -207,17 +205,12 @@ int visorchannel_read(struct visorchannel *channel, ulong 
offset,
  void *local, ulong nbytes);
 int visorchannel_write(struct visorchannel *channel, ulong offset,
   void *local, ulong nbytes);
-int visorchannel_clear(struct visorchannel *channel, ulong offset,
-  u8 ch, ulong nbytes);
 bool visorchannel_signalremove(struct visorchannel *channel, u32 queue,
   void *msg);
 bool visorchannel_signalinsert(struct visorchannel *channel, u32 queue,
   void *msg);
 bool visorchannel_signalempty(struct visorchannel *channel, u32 queue);
 
-int visorchannel_signalqueue_slots_avail(struct visorchannel *channel,
-u32 queue);
-int visorchannel_signalqueue_max_slots(struct visorchannel *channel, u32 
queue);
 u64 visorchannel_get_physaddr(struct visorchannel *channel);
 ulong visorchannel_get_nbytes(struct visorchannel *channel);
 char *visorchannel_id(struct visorchannel *channel, char *s);
@@ -227,8 +220,6 @@ int visorchannel_set_clientpartition(struct visorchannel 
*channel,
 u64 partition_handle);
 uuid_le visorchannel_get_uuid(struct visorchannel *channel);
 char *visorchannel_uuid_id(uuid_le *guid, char *s);
-void visorchannel_debug(struct visorchannel *channel, int num_queues,
-   struct seq_file *seq, u32 off);
 void __iomem *visorchannel_get_header(struct visorchannel *channel);
 
 #define BUS_ROOT_DEVICEUINT_MAX
diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 247a9ad..c3f53fb 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -715,13 +715,6 @@ visorbus_write_channel(struct visor_device *dev, unsigned 
long offset,
 }
 EXPORT_SYMBOL_GPL(visorbus_write_channel);
 
-int
-visorbus_clear_channel(struct visor_device *dev, unsigned long offset, u8 ch,
-  unsigned long nbytes)
-{
-   return visorchannel_clear(dev->visorchannel, offset, ch, nbytes);
-}
-
 /** We don't really have a real interrupt, so for now we just call the
  *  interrupt function periodically...
  */
diff --git a/drivers/staging/unisys/visorbus/visorchannel.c 
b/drivers/staging/unisys/visorbus/visorchannel.c
index 1f626c3..43315c2 100644
--- a/drivers/staging/unisys/visorbus/visorchannel.c
+++ b/drivers/staging/unisys/visorbus/visorchannel.c
@@ -255,41 +255,6 @@ visorchannel_write(struct visorchannel *channel, ulong 
offset,
return 0;
 }
 
-int
-visorchannel_clear(struct visorchannel *channel, ulong offset, u8 ch,
-  ulong nbytes)
-{
-   int err;
-   int bufsize = PAGE_SIZE;
-   int written = 0;
-   u8 *buf;
-
-   buf = (u8 *)__get_free_page(GFP_KERNEL);
-   if (!buf)
-   return -ENOMEM;
-
-   memset(buf, ch, bufsize);
-
-   while (nbytes > 0) {
-   int thisbytes = bufsize;
-
-   if (nbytes < thisbytes)
-   thisbytes = nbytes;
-   err = visorchannel_write(channel, offset + written,
-buf, thisbytes);
-   if (err)
-   goto out_free_page;
-
-   written += thisbytes;
-   nbytes -= thisbytes;
-   }
-   err = 0;
-
-out_free_page:
-   free_page((unsigned long)buf);
-   return err;
-}
-
 void __iomem  *
 visorchannel_get_header(struct visorchannel *channel)
 {
@@ -490,129 +455,3 @@ visorchannel_signalinsert(struct visorchannel *channel, 
u32 queue, void *msg)
re

[PATCH v2 22/27] staging: unisys: visorbus: Move visorbus-unique functions to private header

[David Kershner]

From: David Binder 

Moves function prototypes that are unique to visorbus from
include/visorbus.h to visorbus/visorbus_private.h.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/visorbus.h  | 25 
 drivers/staging/unisys/visorbus/visorbus_private.h | 27 ++
 drivers/staging/unisys/visorbus/visorchannel.c |  1 +
 3 files changed, 28 insertions(+), 25 deletions(-)

diff --git a/drivers/staging/unisys/include/visorbus.h 
b/drivers/staging/unisys/include/visorbus.h
index 94dd48e..2c103e8 100644
--- a/drivers/staging/unisys/include/visorbus.h
+++ b/drivers/staging/unisys/include/visorbus.h
@@ -188,37 +188,12 @@ int visorbus_write_channel(struct visor_device *dev,
 void visorbus_enable_channel_interrupts(struct visor_device *dev);
 void visorbus_disable_channel_interrupts(struct visor_device *dev);
 
-/* Note that for visorchannel_create()
- *  and  arguments may be 0 if we are a channel CLIENT.
- * In this case, the values can simply be read from the channel header.
- */
-struct visorchannel *visorchannel_create(u64 physaddr,
-unsigned long channel_bytes,
-gfp_t gfp, uuid_le guid);
-struct visorchannel *visorchannel_create_with_lock(u64 physaddr,
-  unsigned long channel_bytes,
-  gfp_t gfp, uuid_le guid);
-void visorchannel_destroy(struct visorchannel *channel);
-int visorchannel_read(struct visorchannel *channel, ulong offset,
- void *local, ulong nbytes);
-int visorchannel_write(struct visorchannel *channel, ulong offset,
-  void *local, ulong nbytes);
 bool visorchannel_signalremove(struct visorchannel *channel, u32 queue,
   void *msg);
 bool visorchannel_signalinsert(struct visorchannel *channel, u32 queue,
   void *msg);
 bool visorchannel_signalempty(struct visorchannel *channel, u32 queue);
-
-u64 visorchannel_get_physaddr(struct visorchannel *channel);
-ulong visorchannel_get_nbytes(struct visorchannel *channel);
-char *visorchannel_id(struct visorchannel *channel, char *s);
-char *visorchannel_zoneid(struct visorchannel *channel, char *s);
-u64 visorchannel_get_clientpartition(struct visorchannel *channel);
-int visorchannel_set_clientpartition(struct visorchannel *channel,
-u64 partition_handle);
 uuid_le visorchannel_get_uuid(struct visorchannel *channel);
-char *visorchannel_uuid_id(uuid_le *guid, char *s);
-void __iomem *visorchannel_get_header(struct visorchannel *channel);
 
 #define BUS_ROOT_DEVICEUINT_MAX
 struct visor_device *visorbus_get_device_by_id(u32 bus_no, u32 dev_no,
diff --git a/drivers/staging/unisys/visorbus/visorbus_private.h 
b/drivers/staging/unisys/visorbus/visorbus_private.h
index f48f230..0ee7904 100644
--- a/drivers/staging/unisys/visorbus/visorbus_private.h
+++ b/drivers/staging/unisys/visorbus/visorbus_private.h
@@ -66,4 +66,31 @@ visorchipset_register_busdev(
 /* visorbus init and exit functions */
 int visorbus_init(void);
 void visorbus_exit(void);
+
+/* Visorchannel access functions */
+
+/* Note that for visorchannel_create()
+ *  and  arguments may be 0 if we are a channel CLIENT.
+ * In this case, the values can simply be read from the channel header.
+ */
+struct visorchannel *visorchannel_create(u64 physaddr,
+unsigned long channel_bytes,
+gfp_t gfp, uuid_le guid);
+struct visorchannel *visorchannel_create_with_lock(u64 physaddr,
+  unsigned long channel_bytes,
+  gfp_t gfp, uuid_le guid);
+void visorchannel_destroy(struct visorchannel *channel);
+int visorchannel_read(struct visorchannel *channel, ulong offset,
+ void *local, ulong nbytes);
+int visorchannel_write(struct visorchannel *channel, ulong offset,
+  void *local, ulong nbytes);
+u64 visorchannel_get_physaddr(struct visorchannel *channel);
+ulong visorchannel_get_nbytes(struct visorchannel *channel);
+char *visorchannel_id(struct visorchannel *channel, char *s);
+char *visorchannel_zoneid(struct visorchannel *channel, char *s);
+u64 visorchannel_get_clientpartition(struct visorchannel *channel);
+int visorchannel_set_clientpartition(struct visorchannel *channel,
+u64 partition_handle);
+char *visorchannel_uuid_id(uuid_le *guid, char *s);
+void __iomem *visorchannel_get_header(struct visorchannel *channel);
 #endif
diff --git a/drivers/staging/unisys/visorbus/visorchannel.c 
b/drivers/staging/unisys/visorbus/visorchannel.c
index b9f0b6b..1b743d7 100644
--- a/drivers/staging/unisys/visorbus/visorchannel.c
+++ b/drivers/

[PATCH v2 21/27] staging: unisys: visorbus: make visorchipset function descriptions more kerneldoc-like

[David Kershner]

From: David Binder 

Per audit feedback from Thomas Gleixner, function descriptions in
visorchipset.c now utilize a more kerneldoc-like formatting. The affected
comments do not implement other kerneldoc requirements.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchipset.c | 41 +++---
 1 file changed, 24 insertions(+), 17 deletions(-)

diff --git a/drivers/staging/unisys/visorbus/visorchipset.c 
b/drivers/staging/unisys/visorbus/visorchipset.c
index 1da980f..189ba40 100644
--- a/drivers/staging/unisys/visorbus/visorchipset.c
+++ b/drivers/staging/unisys/visorbus/visorchipset.c
@@ -1300,7 +1300,8 @@ my_device_destroy(struct controlvm_message *inmsg)
  inmsg->hdr.flags.response_expected == 1, 1);
 }
 
-/* When provided with the physical address of the controlvm channel
+/**
+ * When provided with the physical address of the controlvm channel
  * (phys_addr), the offset to the payload area we need to manage
  * (offset), and the size of this payload area (bytes), fills in the
  * controlvm_payload_info struct.  Returns true for success or false
@@ -1368,8 +1369,9 @@ initialize_controlvm_payload(void)
  &controlvm_payload_info);
 }
 
-/*  Send ACTION=online for DEVPATH=/sys/devices/platform/visorchipset.
- *  Returns CONTROLVM_RESP_xxx code.
+/**
+ * Send ACTION=online for DEVPATH=/sys/devices/platform/visorchipset.
+ * Returns CONTROLVM_RESP_xxx code.
  */
 static int
 visorchipset_chipset_ready(void)
@@ -1390,8 +1392,9 @@ visorchipset_chipset_selftest(void)
return CONTROLVM_RESP_SUCCESS;
 }
 
-/*  Send ACTION=offline for DEVPATH=/sys/devices/platform/visorchipset.
- *  Returns CONTROLVM_RESP_xxx code.
+/**
+ * Send ACTION=offline for DEVPATH=/sys/devices/platform/visorchipset.
+ * Returns CONTROLVM_RESP_xxx code.
  */
 static int
 visorchipset_chipset_notready(void)
@@ -1433,7 +1436,8 @@ chipset_notready(struct controlvm_message_header *msg_hdr)
controlvm_respond(msg_hdr, rc);
 }
 
-/* This is your "one-stop" shop for grabbing the next message from the
+/**
+ * This is your "one-stop" shop for grabbing the next message from the
  * CONTROLVM_QUEUE_EVENT queue in the controlvm channel.
  */
 static bool
@@ -1464,7 +1468,7 @@ read_controlvm_event(struct controlvm_message *msg)
 
 #define PARAHOTPLUG_TIMEOUT_MS 2000
 
-/*
+/**
  * Generate unique int to match an outstanding CONTROLVM message with a
  * udev script /proc response
  */
@@ -1476,7 +1480,7 @@ parahotplug_next_id(void)
return atomic_inc_return(&id);
 }
 
-/*
+/**
  * Returns the time (in jiffies) when a CONTROLVM message on the list
  * should expire -- PARAHOTPLUG_TIMEOUT_MS in the future
  */
@@ -1486,7 +1490,7 @@ parahotplug_next_expiration(void)
return jiffies + msecs_to_jiffies(PARAHOTPLUG_TIMEOUT_MS);
 }
 
-/*
+/**
  * Create a parahotplug_request, which is basically a wrapper for a
  * CONTROLVM_MESSAGE that we can stick on a list
  */
@@ -1506,7 +1510,7 @@ parahotplug_request_create(struct controlvm_message *msg)
return req;
 }
 
-/*
+/**
  * Free a parahotplug_request.
  */
 static void
@@ -1515,7 +1519,7 @@ parahotplug_request_destroy(struct parahotplug_request 
*req)
kfree(req);
 }
 
-/*
+/**
  * Cause uevent to run the user level script to do the disable/enable
  * specified in (the CONTROLVM message in) the specified
  * parahotplug_request
@@ -1545,7 +1549,7 @@ parahotplug_request_kickoff(struct parahotplug_request 
*req)
   envp);
 }
 
-/*
+/**
  * Remove any request from the list that's been on there too long and
  * respond with an error.
  */
@@ -1576,7 +1580,7 @@ parahotplug_process_list(void)
spin_unlock(¶hotplug_request_list_lock);
 }
 
-/*
+/**
  * Called from the /proc handler, which means the user script has
  * finished the enable/disable.  Find the matching identifier, and
  * respond to the CONTROLVM message with success.
@@ -1613,7 +1617,7 @@ parahotplug_request_complete(int id, u16 active)
return -EINVAL;
 }
 
-/*
+/**
  * Enables or disables a PCI device by kicking off a udev script
  */
 static void
@@ -1656,7 +1660,8 @@ parahotplug_process_message(struct controlvm_message 
*inmsg)
}
 }
 
-/* Process a controlvm message.
+/**
+ * Process a controlvm message.
  * Return result:
  *false - this function will return false only in the case where the
  *controlvm message was NOT processed, but processing must be
@@ -2024,7 +2029,8 @@ device_resume_response(struct visor_device *dev_info, int 
response)
dev_info->pending_msg_hdr = NULL;
 }
 
-/* The parahotplug/devicedisabled interface gets called by our support script
+/**
+ * The parahotplug/devicedisabled interface gets called by our support script
  * when an SR-IOV device has been shut down. The ID is passed to the script
  * and then passed back when the device has been removed.
 

[PATCH v2 23/27] staging: unisys: visorbus: Add kerneldoc-style comments for visorbus API

[David Kershner]

From: David Binder 

Adds kerneldoc-style comments for those functions which may be used outside
of the visorbus driver.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/include/visorbus.h   | 127 
 drivers/staging/unisys/visorbus/visorbus_main.c |  42 
 2 files changed, 127 insertions(+), 42 deletions(-)

diff --git a/drivers/staging/unisys/include/visorbus.h 
b/drivers/staging/unisys/include/visorbus.h
index 2c103e8..99c7beb 100644
--- a/drivers/staging/unisys/include/visorbus.h
+++ b/drivers/staging/unisys/include/visorbus.h
@@ -177,22 +177,149 @@ struct visor_device {
 
 #define to_visor_device(x) container_of(x, struct visor_device, device)
 
+/**
+ * visorbus_register_visor_driver() - registers the provided driver
+ * @struct visor_driver *: the driver to register
+ *
+ * A particular type of visor driver calls this function to register
+ * the driver.  The caller MUST fill in the following fields within the
+ * #drv structure:
+ * name, version, owner, channel_types, probe, remove
+ *
+ * Here's how the whole Linux bus / driver / device model works.
+ *
+ * At system start-up, the visorbus kernel module is loaded, which registers
+ * visorbus_type as a bus type, using bus_register().
+ *
+ * All kernel modules that support particular device types on a
+ * visorbus bus are loaded.  Each of these kernel modules calls
+ * visorbus_register_visor_driver() in their init functions, passing a
+ * visor_driver struct.  visorbus_register_visor_driver() in turn calls
+ * register_driver(&visor_driver.driver).  This .driver member is
+ * initialized with generic methods (like probe), whose sole responsibility
+ * is to act as a broker for the real methods, which are within the
+ * visor_driver struct.  (This is the way the subclass behavior is
+ * implemented, since visor_driver is essentially a subclass of the
+ * generic driver.)  Whenever a driver_register() happens, core bus code in
+ * the kernel does (see device_attach() in drivers/base/dd.c):
+ *
+ * for each dev associated with the bus (the bus that driver is on) that
+ * does not yet have a driver
+ * if bus.match(dev,newdriver) == yes_matched  ** .match specified
+ *** during bus_register().
+ * newdriver.probe(dev)  ** for visor drivers, this will call
+ *   ** the generic driver.probe implemented in visorbus.c,
+ *   ** which in turn calls the probe specified within the
+ *   ** struct visor_driver (which was specified by the
+ *   ** actual device driver as part of
+ *   ** visorbus_register_visor_driver()).
+ *
+ * The above dance also happens when a new device appears.
+ * So the question is, how are devices created within the system?
+ * Basically, just call device_add(dev).  See pci_bus_add_devices().
+ * pci_scan_device() shows an example of how to build a device struct.  It
+ * returns the newly-created struct to pci_scan_single_device(), who adds it
+ * to the list of devices at PCIBUS.devices.  That list of devices is what
+ * is traversed by pci_bus_add_devices().
+ *
+ * Return: integer indicating success (zero) or failure (non-zero)
+ */
 int visorbus_register_visor_driver(struct visor_driver *);
+
+/**
+ * visorbus_unregister_visor_driver() - unregisters the provided driver
+ * @struct visor_driver *: the driver to unregister
+ */
 void visorbus_unregister_visor_driver(struct visor_driver *);
+
+/**
+ * visorbus_read_channel() - reads from the designated channel into
+ *   the provided buffer
+ * @dev:the device whose channel is read from
+ * @offset: the offset into the channel at which reading starts
+ * @dest:   the destination buffer that is written into from the channel
+ * @nbytes: the number of bytes to read from the channel
+ *
+ * If receiving a message, use the visorchannel_signalremove()
+ * function instead.
+ *
+ * Return: integer indicating success (zero) or failure (non-zero)
+ */
 int visorbus_read_channel(struct visor_device *dev,
  unsigned long offset, void *dest,
  unsigned long nbytes);
+
+/**
+ * visorbus_write_channel() - writes the provided buffer into the designated
+ *channel
+ * @dev:the device whose channel is written to
+ * @offset: the offset into the channel at which writing starts
+ * @src:the source buffer that is written into the channel
+ * @nbytes: the number of bytes to write into the channel
+ *
+ * If sending a message, use the visorchannel_signalinsert()
+ * function instead.
+ *
+ * Return: integer indicating success (zero) or failure (non-zero)
+ */
 int visorbus_write_channel(struct visor_device *dev,
   unsigned long offset, void *src,
   unsigned long nbytes);
+/**
+ * visorbus_en

[PATCH v2 24/27] staging: unisys: Move vbushelper.h to visorbus directory

[David Kershner]

Only visorbus needs this header file so move it to visorbus
directory.

Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/{include => visorbus}/vbushelper.h | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename drivers/staging/unisys/{include => visorbus}/vbushelper.h (100%)

diff --git a/drivers/staging/unisys/include/vbushelper.h 
b/drivers/staging/unisys/visorbus/vbushelper.h
similarity index 100%
rename from drivers/staging/unisys/include/vbushelper.h
rename to drivers/staging/unisys/visorbus/vbushelper.h
-- 
1.9.1

--
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

[PATCH v2 11/27] staging: unisys: visorbus: use kernel timer instead of workqueue

[David Kershner]

From: Tim Sell 

A kernel timer is now used as the vehicle to periodically call the
channel_interrupt function of registered visor drivers, instead of a
workqueue.

This simplifies a lot of things by making periodic_work.c and
periodic_work.h no longer necessary.  This change also means that the
channel_interrupt() callbacks registered by visor drivers (via
visorbus_register_visor_driver()) will now be called in atomic context
(i.e., canNOT sleep) rather than kernel thread context (CAN sleep).
Fortunately this did NOT necessitate any change to the existing
channel_interrupt() callbacks, because none of them ever perform any
operations that would be invalid in atomic context.

Signed-off-by: Tim Sell 
Signed-off-by: David Kershner 
---
 drivers/staging/unisys/include/visorbus.h   | 10 +++--
 drivers/staging/unisys/visorbus/visorbus_main.c | 54 +++--
 2 files changed, 21 insertions(+), 43 deletions(-)

diff --git a/drivers/staging/unisys/include/visorbus.h 
b/drivers/staging/unisys/include/visorbus.h
index 9baf1ec..9bb88bb 100644
--- a/drivers/staging/unisys/include/visorbus.h
+++ b/drivers/staging/unisys/include/visorbus.h
@@ -34,8 +34,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
-#include "periodic_work.h"
 #include "channel.h"
 
 struct visor_driver;
@@ -126,8 +127,8 @@ struct visor_driver {
  * device: Device struct meant for use by the bus driver
  * only.
  * list_all:   Used by the bus driver to enumerate devices.
- * periodic_work:  Device work queue. Private use by bus driver
- * only.
+ * timer:  Timer fired periodically to do interrupt-type
+ * activity.
  * being_removed:  Indicates that the device is being removed from
  * the bus. Private bus driver use only.
  * visordriver_callback_lock:  Used by the bus driver to lock when handling
@@ -157,7 +158,8 @@ struct visor_device {
/* These fields are for private use by the bus driver only. */
struct device device;
struct list_head list_all;
-   struct periodic_work *periodic_work;
+   struct timer_list timer;
+   bool timer_active;
bool being_removed;
struct semaphore visordriver_callback_lock;
bool pausing;
diff --git a/drivers/staging/unisys/visorbus/visorbus_main.c 
b/drivers/staging/unisys/visorbus/visorbus_main.c
index 608ca1a..24b27ff 100644
--- a/drivers/staging/unisys/visorbus/visorbus_main.c
+++ b/drivers/staging/unisys/visorbus/visorbus_main.c
@@ -19,7 +19,6 @@
 #include "visorbus.h"
 #include "visorbus_private.h"
 #include "version.h"
-#include "periodic_work.h"
 #include "vbuschannel.h"
 #include "guestlinuxdebug.h"
 #include "vmcallinterface.h"
@@ -116,7 +115,6 @@ struct bus_type visorbus_type = {
.bus_groups = visorbus_bus_groups,
 };
 
-static struct workqueue_struct *periodic_dev_workqueue;
 static long long bus_count;/** number of bus instances */
/** ever-increasing */
 
@@ -222,10 +220,6 @@ visorbus_release_device(struct device *xdev)
 {
struct visor_device *dev = to_visor_device(xdev);
 
-   if (dev->periodic_work) {
-   visor_periodic_work_destroy(dev->periodic_work);
-   dev->periodic_work = NULL;
-   }
if (dev->visorchannel) {
visorchannel_destroy(dev->visorchannel);
dev->visorchannel = NULL;
@@ -530,35 +524,36 @@ unregister_driver_attributes(struct visor_driver *drv)
 }
 
 static void
-dev_periodic_work(void *xdev)
+dev_periodic_work(unsigned long __opaque)
 {
-   struct visor_device *dev = xdev;
+   struct visor_device *dev = (struct visor_device *)__opaque;
struct visor_driver *drv = to_visor_driver(dev->device.driver);
 
-   down(&dev->visordriver_callback_lock);
if (drv->channel_interrupt)
drv->channel_interrupt(dev);
-   up(&dev->visordriver_callback_lock);
-   if (!visor_periodic_work_nextperiod(dev->periodic_work))
-   put_device(&dev->device);
+   mod_timer(&dev->timer, jiffies + POLLJIFFIES_NORMALCHANNEL);
 }
 
 static void
 dev_start_periodic_work(struct visor_device *dev)
 {
-   if (dev->being_removed)
+   if (dev->being_removed || dev->timer_active)
return;
/* now up by at least 2 */
get_device(&dev->device);
-   if (!visor_periodic_work_start(dev->periodic_work))
-   put_device(&dev->device);
+   dev->timer.expires = jiffies + POLLJIFFIES_NORMALCHANNEL;
+   add_timer(&dev->timer);
+   dev->timer_active = true;
 }
 
 static void
 dev_stop_periodic_work(struct visor_device *dev)
 {
-   if (visor_periodic_work_stop(dev->periodic_work))
-   put_device(&dev->device);
+   if (!dev->timer_active)
+   return;
+   del_timer_sync(&dev->t

[PATCH v2 20/27] staging: unisys: visorbus: make visorchannel function descriptions more kerneldoc-like

[David Kershner]

From: David Binder 

Per audit feedback from Thomas Gleixner, function descriptions in
visorchannel.c now utilize a more kerneldoc-like formatting. The affected
comments do not implement other kerneldoc requirements.

Signed-off-by: David Binder 
Signed-off-by: David Kershner 
Reviewed-by: Tim Sell 
---
 drivers/staging/unisys/visorbus/visorchannel.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/unisys/visorbus/visorchannel.c 
b/drivers/staging/unisys/visorbus/visorchannel.c
index 43315c2..b9f0b6b 100644
--- a/drivers/staging/unisys/visorbus/visorchannel.c
+++ b/drivers/staging/unisys/visorbus/visorchannel.c
@@ -55,7 +55,8 @@ struct visorchannel {
uuid_le inst;
 };
 
-/* Creates the struct visorchannel abstraction for a data area in memory,
+/**
+ * Creates the struct visorchannel abstraction for a data area in memory,
  * but does NOT modify this data area.
  */
 static struct visorchannel *
-- 
1.9.1

--
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

[PATCH v2 10/27] staging: unisys: visorinput: remove unnecessary locking

[David Kershner]

From: Tim Sell 

Locking in the _interrupt() function is NOT necessary so long as we ensure
that interrupts have been stopped whenever we need to pause or resume the
device, which we now do.

While a device is paused, we ensure that interrupts stay disabled, i.e.
that the _interrupt() function will NOT be called, yet remember the desired
state in devdata->interrupts_enabled if open() or close() are called are
called while the device is paused.  Then when the device is resumed, we
restore the actual state of interrupts (i.e., whether _interrupt() is going
to be called or not) to the desired state in devdata->interrupts_enabled.

Signed-off-by: Tim Sell 
Signed-off-by: David Kershner 
---
 drivers/staging/unisys/visorinput/visorinput.c | 57 +-
 1 file changed, 47 insertions(+), 10 deletions(-)

diff --git a/drivers/staging/unisys/visorinput/visorinput.c 
b/drivers/staging/unisys/visorinput/visorinput.c
index 12a3570..9c00710 100644
--- a/drivers/staging/unisys/visorinput/visorinput.c
+++ b/drivers/staging/unisys/visorinput/visorinput.c
@@ -66,6 +66,7 @@ struct visorinput_devdata {
struct rw_semaphore lock_visor_dev; /* lock for dev */
struct input_dev *visorinput_dev;
bool paused;
+   bool interrupts_enabled;
unsigned int keycode_table_bytes; /* size of following array */
/* for keyboard devices: visorkbd_keycode[] + visorkbd_ext_keycode[] */
unsigned char keycode_table[0];
@@ -228,7 +229,21 @@ static int visorinput_open(struct input_dev 
*visorinput_dev)
return -EINVAL;
}
dev_dbg(&visorinput_dev->dev, "%s opened\n", __func__);
+
+   /*
+* If we're not paused, really enable interrupts.
+* Regardless of whether we are paused, set a flag indicating
+* interrupts should be enabled so when we resume, interrupts
+* will really be enabled.
+*/
+   down_write(&devdata->lock_visor_dev);
+   devdata->interrupts_enabled = true;
+   if (devdata->paused)
+   goto out_unlock;
visorbus_enable_channel_interrupts(devdata->dev);
+
+out_unlock:
+   up_write(&devdata->lock_visor_dev);
return 0;
 }
 
@@ -243,7 +258,22 @@ static void visorinput_close(struct input_dev 
*visorinput_dev)
return;
}
dev_dbg(&visorinput_dev->dev, "%s closed\n", __func__);
+
+   /*
+* If we're not paused, really disable interrupts.
+* Regardless of whether we are paused, set a flag indicating
+* interrupts should be disabled so when we resume we will
+* not re-enable them.
+*/
+
+   down_write(&devdata->lock_visor_dev);
+   devdata->interrupts_enabled = false;
+   if (devdata->paused)
+   goto out_unlock;
visorbus_disable_channel_interrupts(devdata->dev);
+
+out_unlock:
+   up_write(&devdata->lock_visor_dev);
 }
 
 /*
@@ -438,10 +468,8 @@ visorinput_remove(struct visor_device *dev)
 * in visorinput_channel_interrupt()
 */
 
-   down_write(&devdata->lock_visor_dev);
dev_set_drvdata(&dev->device, NULL);
unregister_client_input(devdata->visorinput_dev);
-   up_write(&devdata->lock_visor_dev);
kfree(devdata);
 }
 
@@ -529,13 +557,7 @@ visorinput_channel_interrupt(struct visor_device *dev)
if (!devdata)
return;
 
-   down_write(&devdata->lock_visor_dev);
-   if (devdata->paused) /* don't touch device/channel when paused */
-   goto out_locked;
-
visorinput_dev = devdata->visorinput_dev;
-   if (!visorinput_dev)
-   goto out_locked;
 
while (visorchannel_signalremove(dev->visorchannel, 0, &r)) {
scancode = r.activity.arg1;
@@ -611,8 +633,6 @@ visorinput_channel_interrupt(struct visor_device *dev)
break;
}
}
-out_locked:
-   up_write(&devdata->lock_visor_dev);
 }
 
 static int
@@ -632,6 +652,14 @@ visorinput_pause(struct visor_device *dev,
rc = -EBUSY;
goto out_locked;
}
+   if (devdata->interrupts_enabled)
+   visorbus_disable_channel_interrupts(dev);
+
+   /*
+* due to above, at this time no thread of execution will be
+* in visorinput_channel_interrupt()
+*/
+
devdata->paused = true;
complete_func(dev, 0);
rc = 0;
@@ -659,6 +687,15 @@ visorinput_resume(struct visor_device *dev,
}
devdata->paused = false;
complete_func(dev, 0);
+
+   /*
+* Re-establish calls to visorinput_channel_interrupt() if that is
+* the desired state that we've kept track of in interrupts_enabled
+* while the device was paused.
+*/
+   if (devdata->interrupts_enabled)
+   visorbus_enable_channel_interrupts(dev);
+
rc = 0;
 out_locked:
up_write(&devdata->lock_visor_dev);
-- 
1.9.1

--
To unsubscribe

Re: [PATCH v2 1/2] scsi: fix race between simultaneous decrements of ->host_failed

[Dan Williams]

On Tue, May 31, 2016 at 1:38 AM, Wei Fang  wrote:
> sas_ata_strategy_handler() adds the works of the ata error handler
> to system_unbound_wq. This workqueue asynchronously runs work items,
> so the ata error handler will be performed concurrently on different
> CPUs. In this case, ->host_failed will be decreased simultaneously in
> scsi_eh_finish_cmd() on different CPUs, and become abnormal.
>
> It will lead to permanently inequal between ->host_failed and
>  ->host_busy, and scsi error handler thread won't become running.
> IO errors after that won't be handled forever.
>
> Use atomic type for ->host_failed to fix this race.
>
> This fixes the problem introduced in
> commit 50824d6c5657 ("[SCSI] libsas: async ata-eh").
>
> Reviewed-by: Christoph Hellwig 
> Signed-off-by: Wei Fang 

Acked-by: Dan Williams 
--
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 v2 1/2] scsi: fix race between simultaneous decrements of ->host_failed

[Dan Williams]

On Tue, May 31, 2016 at 8:21 PM, Dan Williams  wrote:
> On Tue, May 31, 2016 at 1:38 AM, Wei Fang  wrote:
>> sas_ata_strategy_handler() adds the works of the ata error handler
>> to system_unbound_wq. This workqueue asynchronously runs work items,
>> so the ata error handler will be performed concurrently on different
>> CPUs. In this case, ->host_failed will be decreased simultaneously in
>> scsi_eh_finish_cmd() on different CPUs, and become abnormal.
>>
>> It will lead to permanently inequal between ->host_failed and
>>  ->host_busy, and scsi error handler thread won't become running.
>> IO errors after that won't be handled forever.
>>
>> Use atomic type for ->host_failed to fix this race.
>>
>> This fixes the problem introduced in
>> commit 50824d6c5657 ("[SCSI] libsas: async ata-eh").
>>
>> Reviewed-by: Christoph Hellwig 
>> Signed-off-by: Wei Fang 
>
> Acked-by: Dan Williams 

Should also tag this for -stable.
--
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 v2] dma-mapping: Use unsigned long for dma_attrs

[Krzysztof Kozlowski]

On 05/31/2016 07:04 PM, Christoph Hellwig wrote:
> On Mon, May 30, 2016 at 01:54:06PM +0200, Krzysztof Kozlowski wrote:
>> The dma-mapping core and the implementations do not change the
>> DMA attributes passed by pointer.  Thus the pointer can point to const
>> data.  However the attributes do not have to be a bitfield. Instead
>> unsigned long will do fine:
>>
>> 1. This is just simpler.  Both in terms of reading the code and setting
>>attributes.  Instead of initializing local attributes on the stack and
>>passing pointer to it to dma_set_attr(), just set the bits.
>>
>> 2. It brings safeness and checking for const correctness because the
>>attributes are passed by value.
>>
>> Please have in mind that this is RFC, not finished yet.  Only ARM and
>> ARM64 are fixed (and not everywhere).
>> However other API users also have to be converted which is quite
>> intrusive.  I would rather avoid it until the overall approach is
>> accepted.
> 
> This looks great!  Please continue doing the full conversion.
> 
>> +/**
>> + * List of possible attributes associated with a DMA mapping. The semantics
>> + * of each attribute should be defined in Documentation/DMA-attributes.txt.
>> + */
>> +#define DMA_ATTR_WRITE_BARRIER  BIT(1)
>> +#define DMA_ATTR_WEAK_ORDERING  BIT(2)
>> +#define DMA_ATTR_WRITE_COMBINE  BIT(3)
>> +#define DMA_ATTR_NON_CONSISTENT BIT(4)
>> +#define DMA_ATTR_NO_KERNEL_MAPPING  BIT(5)
>> +#define DMA_ATTR_SKIP_CPU_SYNC  BIT(6)
>> +#define DMA_ATTR_FORCE_CONTIGUOUS   BIT(7)
>> +#define DMA_ATTR_ALLOC_SINGLE_PAGES BIT(8)
> 
> No really for this patch, but I would much prefer to document them next
> to the code in the long run.  Also I really think these BIT() macros
> are a distraction compared to the (1 << N) notation.

Not much difference to me but maybe plain number:
... 0x01u
... 0x02u
?

> 
>> +/**
>> + * dma_get_attr - check for a specific attribute
>> + * @attr: attribute to look for
>> + * @attrs: attributes to check within
>> + */
>> +static inline bool dma_get_attr(unsigned long attr, unsigned long attrs)
>> +{
>> +return !!(attr & attrs);
>> +}
> 
> I'd just kill this helper, much easier to simply open code it in the
> caller.

Keeping it for now helps reducing the number of changes in the patch.
The patch will be quite big as it has to replace all the uses atomically.

I can get rid of the helper in consecutive patch.

Best regards,
Krzysztof


--
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: [2/3] hwmon: xgene: Adds hwmon driver

[Hoan Tran]

Hi Guenter,

Thanks for your review !

On Sun, May 29, 2016 at 10:25 PM, Guenter Roeck  wrote:
> On Mon, May 16, 2016 at 09:17:26AM -0700, hotran wrote:
>> This patch adds hardware temperature and power reading support for
>> APM X-Gene SoC's using the mailbox communication interface.
>>
> Please drop the "'".

Yes, will remove it.

>
>>
>> Signed-off-by: Hoan Tran 
>> ---
>>  Documentation/hwmon/xgene-hwmon |  32 ++
>>  drivers/hwmon/Kconfig   |   7 +
>>  drivers/hwmon/Makefile  |   1 +
>>  drivers/hwmon/xgene-hwmon.c | 801 
>> 
>>  4 files changed, 841 insertions(+)
>>  create mode 100644 Documentation/hwmon/xgene-hwmon
>>  create mode 100644 drivers/hwmon/xgene-hwmon.c
>>
>> diff --git a/Documentation/hwmon/xgene-hwmon 
>> b/Documentation/hwmon/xgene-hwmon
>> new file mode 100644
>> index 000..040a7f2
>> --- /dev/null
>> +++ b/Documentation/hwmon/xgene-hwmon
>> @@ -0,0 +1,32 @@
>> +Kernel driver xgene-hwmon
>> +
>> +
>> +Supported chips:
>> + * APM X-Gene SoC
>> +
>> +Description
>> +---
>> +
>> +This driver adds hardware temperature and power reading support for
>> +APM X-Gene SoC's using the mailbox communication interface.
>>
> No "'".

Yes,

>>
>> +For device tree, it is the standard DT mailbox.
>> +For ACPI, it is the PCC mailbox.
>> +
>> +The following sensors are supported
>> +
>> +  * Temperature
>> +- SoC on-die temperature in milli-degree
>> +- Alarm when high/over temperature occurs
>> +  * Power
>> +- CPU power in uW
>> +- IO power in uW
>> +- CPU and IO power in uW
>> +
>> +sysfs-Interface
>> +---
>> +
>> +temp1_input - SoC on-die temperature (milli-degree C)
>> +temp1_critical_alarm - An 1 would indicates on-die temperature exceeded 
>> threshold
>> +power1_input - CPU power in (uW)
>> +power2_input - IO power in (uW)
>> +power3_input - CPU and IO power in (uW)
>> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
>> index 5c2d13a..91c3056 100644
>> --- a/drivers/hwmon/Kconfig
>> +++ b/drivers/hwmon/Kconfig
>> @@ -1776,6 +1776,13 @@ config SENSORS_ULTRA45
>> This driver provides support for the Ultra45 workstation 
>> environmental
>> sensors.
>>
>> +config SENSORS_XGENE
>> + tristate "APM X-Gene SoC hardware monitoring driver"
>> + depends on XGENE_SLIMPRO_MBOX || PCC
>> + help
>> +   If you say yes here you get support for the temperature
>> +   and power sensors for APM X-Gene SoC.
>> +
>>  if ACPI
>>
>>  comment "ACPI drivers"
>> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
>> index 58cc3ac..668d0f1 100644
>> --- a/drivers/hwmon/Makefile
>> +++ b/drivers/hwmon/Makefile
>> @@ -161,6 +161,7 @@ obj-$(CONFIG_SENSORS_W83L785TS)   += w83l785ts.o
>>  obj-$(CONFIG_SENSORS_W83L786NG)  += w83l786ng.o
>>  obj-$(CONFIG_SENSORS_WM831X) += wm831x-hwmon.o
>>  obj-$(CONFIG_SENSORS_WM8350) += wm8350-hwmon.o
>> +obj-$(CONFIG_SENSORS_XGENE)  += xgene-hwmon.o
>>
>>  obj-$(CONFIG_PMBUS)  += pmbus/
>>
>> diff --git a/drivers/hwmon/xgene-hwmon.c b/drivers/hwmon/xgene-hwmon.c
>> new file mode 100644
>> index 000..bc4ad29
>> --- /dev/null
>> +++ b/drivers/hwmon/xgene-hwmon.c
>> @@ -0,0 +1,801 @@
>> +/*
>> + * APM X-Gene SoC Hardware Monitoring Driver
>> + *
>> + * Copyright (c) 2016, Applied Micro Circuits Corporation
>> + * Author: Loc Ho 
>> + * Hoan Tran 
>> + *
>> + * This program is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU General Public License as
>> + * published by the Free Software Foundation; either version 2 of
>> + * the License, or (at your option) any later version.
>> + *
>> + * 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.
>> + *
>> + * You should have received a copy of the GNU General Public License
>> + * along with this program; if not, see .
>> + *
>> + * This driver provides the following features:
>> + *  - Retrieve CPU's total power (uW)
>> + *  - Retrieve IO's total power (uW)
>
> Please drop the "'s".

Yes,

>
>> + *  - Retrieve SoC total power (uW)
>> + *  - Retrieve SoC temperature (milli-degree C) and alarm
>> + */
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +/* SLIMpro message defines */
>> +#define SLIMPRO_MSG_TYPE_DBG_ID  0
>> +#define SLIMPRO_MSG_TYPE_ERR_ID  7
>> +#define SLIMPRO_MSG_TYPE_PWRMGMT_ID  9
>> +
>> +#define SLIMPRO_MSG_TYPE(v)  (((v) & 0xF000) >> 28)
>> +#define SLIMPRO_MSG_TYPE_SET(v)  (((v) << 28) & 0xF000)
>> +#define SLIMPRO_MSG_SUBTYPE(v)   (((v) & 0x0F00) >> 24)
>> +#define SLIMPRO_MSG_

Re: [RFC v2] dma-mapping: Use unsigned long for dma_attrs

[Krzysztof Kozlowski]

On 05/31/2016 08:15 PM, Konrad Rzeszutek Wilk wrote:
> On Mon, May 30, 2016 at 01:54:06PM +0200, Krzysztof Kozlowski wrote:
>> The dma-mapping core and the implementations do not change the
>> DMA attributes passed by pointer.  Thus the pointer can point to const
>> data.  However the attributes do not have to be a bitfield. Instead
>> unsigned long will do fine:
>>
>> 1. This is just simpler.  Both in terms of reading the code and setting
>>attributes.  Instead of initializing local attributes on the stack and
>>passing pointer to it to dma_set_attr(), just set the bits.
>>
>> 2. It brings safeness and checking for const correctness because the
>>attributes are passed by value.
> 
> 
> .. why not go the next step a do an enum? Perhaps that should be mentioned
> as part of the description?

These are additive flags so to me this would look a little bit weird:
enum dma_attr {
DMA_ATTR_WRITE_BARRIER  = 0x1,
DMA_ATTR_WEAK_ORDERING  = 0x2,
DMA_ATTR_WRITE_COMBINE  = 0x4,
DMA_ATTR_NON_CONSISTENT = 0x8,
...
}

It doesn't really look like enumeration.

Best regards,
Krzysztof
--
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 00/10] Documentation/Sphinx

[Daniel Vetter]

On Wed, Jun 1, 2016 at 3:07 AM, Jonathan Corbet  wrote:
> On Mon, 30 May 2016 11:10:26 +0200
> Daniel Vetter  wrote:
>
>> I think next steps is to get this merged into docs-next, with a stable
>> tag, so that I can pull it into drm-misc.
>
> So, I want to take another look at this, which probably will need another
> day or two before it can happen.  First impression, though, is that this
> is great, so I'm expecting that I'll be applying it.
>
> Not sure about the stable tag, though?  It doesn't really seem like
> stable material?

Oh, I meant a git tag of a stable (non-rebasing) branch that I can
pull into drm-misc so that we can apply the gpu.tmpl->gpu.rst
conversion on top. Not a cc: stable tag. Too many kinds of stable tags
I guess ;-)
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
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 v2 10/27] staging: unisys: visorinput: remove unnecessary locking

[Thomas Gleixner]

On Tue, 31 May 2016, David Kershner wrote:
> + /*
> +  * If we're not paused, really enable interrupts.
> +  * Regardless of whether we are paused, set a flag indicating
> +  * interrupts should be enabled so when we resume, interrupts
> +  * will really be enabled.
> +  */
> + down_write(&devdata->lock_visor_dev);

Why is this a rw_semaphore? It's only ever taken with down_write() and it's
always the same context. Should be a mutex, right?

While at it, please convert the notifier_lock to a mutex as well.

Thanks,

tglx
--
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 v2 20/27] staging: unisys: visorbus: make visorchannel function descriptions more kerneldoc-like

[Thomas Gleixner]

On Tue, 31 May 2016, David Kershner wrote:

> From: David Binder 
> 
> Per audit feedback from Thomas Gleixner, function descriptions in
> visorchannel.c now utilize a more kerneldoc-like formatting. The affected
> comments do not implement other kerneldoc requirements.

That was not my feedback. If you start a comment with '/**' then it should be
a kernel-doc function/struct documentation. If not then it starts with '/*'.
 
Thanks,

tglx
--
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 v2 13/27] staging: unisys: visorbus: Make visordriver_callback_lock a mutex

[Thomas Gleixner]

On Tue, 31 May 2016, David Kershner wrote:

> From: Bryan Thompson 
> 
> visordriver_callback_lock is just a binary semaphore that logically
> makes more sense as a mutex.
> 
> Signed-off-by: Bryan Thompson 
> Signed-off-by: David Kershner 
> Reviewed-by: Tim Sell 
> ---
>  drivers/staging/unisys/include/visorbus.h   |  3 ++-
>  drivers/staging/unisys/visorbus/visorbus_main.c | 10 +-
>  2 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/staging/unisys/include/visorbus.h 
> b/drivers/staging/unisys/include/visorbus.h
> index 9bb88bb..9da25c0 100644
> --- a/drivers/staging/unisys/include/visorbus.h
> +++ b/drivers/staging/unisys/include/visorbus.h
> @@ -161,7 +161,8 @@ struct visor_device {
>   struct timer_list timer;
>   bool timer_active;
>   bool being_removed;
> - struct semaphore visordriver_callback_lock;
> + /* mutex to serialize visor_driver function callbacks */

TBH. I hate these kind of comments. The mutex name is self explaining, right?
I rather wish you would have spent time documenting the non obvious parts of
the code.

Thanks,

tglx
--
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