Re: [GIT PULL] PCI: Support for configurable PCI endpoint

2017-04-11 Thread Kishon Vijay Abraham I 
Hi Bjorn,

On Wednesday 12 April 2017 01:04 AM, Bjorn Helgaas wrote:
> On Mon, Apr 10, 2017 at 10:43:28AM -0500, Bjorn Helgaas wrote:
>> On Wed, Apr 05, 2017 at 02:22:20PM +0530, Kishon Vijay Abraham I wrote:
>>> Hi Bjorn,
>>>
>>> Please find the pull request for PCI endpoint support below. I've
>>> also included all the history here.
>>
>> Thanks, I applied these (with v7 of the first patch) to pci/host-designware
>> for v4.12.
> 
> Ok, sorry, I screwed this up.  I think my branch actually had v5, not
> v6.  But I *think* I fixed it.  Here's the diff from my branch to your
> git tree.  Apparently you haven't pushed the v7 patch there, so I
> *think* the diff below is the diff between v6 and v7 of that first
> patch.

I just checked your pci/host-designware branch and it looks correct. Thanks for
sorting this out.

Cheers
Kishon

--
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] hwmon: Add MAX31760 fan controller driver.

2017-04-11 Thread John Muir 
Add a driver for the Maxim Integrated MAX31760 Precision Fan
Speed Controller.

v2:
- Fixup open firmware code.
- Add a few comments.

Signed-off-by: John Muir 
---
 Documentation/hwmon/max31760 |   41 ++
 drivers/hwmon/Kconfig|   10 +
 drivers/hwmon/Makefile   |1 +
 drivers/hwmon/max31760.c | 1461 ++
 4 files changed, 1513 insertions(+)
 create mode 100644 Documentation/hwmon/max31760
 create mode 100644 drivers/hwmon/max31760.c

diff --git a/Documentation/hwmon/max31760 b/Documentation/hwmon/max31760
new file mode 100644
index ..6f53ac6112a5
--- /dev/null
+++ b/Documentation/hwmon/max31760
@@ -0,0 +1,41 @@
+Kernel driver max31760
+==
+
+Supported chips:
+  * Maxim Integrated MAX31760
+Prefix: 'max31760'
+Addresses scanned: none
+Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX31760.pdf
+
+Author:
+   John Muir 
+
+Description
+---
+
+The MAX31760 integrates temperature sensing along with precision PWM fan
+control. Please read the datasheet referenced above for a comprehensive
+description of this device.
+
+This device driver's hwmon integration provides the common sysfs interfaces to
+manage two fans and two temperature sensors, and pwm controls for the fan 
speed.
+A temperature to pwm lookup table is exposed via a series of 'auto_point'
+configuration files. See Documentation/hwmon/sysfs-interface for more
+information.
+
+The following custom controls are defined (in the custom sub-directory):
+
+control- Accepts control commands:
+ "reset"   - Execute a soft reset of the device.
+ "clearff" - Clear the fan fault.
+
+eeprom_read- Read from the EEPROM into registers.
+eeprom_write- Write register contents to the EEPROM.
+ Write "0" to these to read or write the entire register
+ contents. Write a bit-field as per the datasheet to write a
+ portion of the register contents.
+
+pwm1_fan_fault  - PWM value in the range of 0 to 255 used when a fan is faulty.
+
+pwm1_ramp_rate  - PWM increment per second when the PWM value is changed.
+ Accepted values are 8, 16, 32, or 255 (instantaneous).
diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
index 337e9078df0a..83c9b46a3876 100644
--- a/drivers/hwmon/Kconfig
+++ b/drivers/hwmon/Kconfig
@@ -895,6 +895,16 @@ config SENSORS_MAX6697
  This driver can also be built as a module.  If so, the module
  will be called max6697.
 
+config SENSORS_MAX31760
+   tristate "Maxim MAX31760 fan controller"
+   depends on I2C
+   help
+ If you say yes here you get support for the Maxim Integrated
+ MAX31760 Precision Fan-Speed Controller.
+
+ This driver can also be built as a module.  If so, the module
+ will be called max31760.
+
 config SENSORS_MAX31790
tristate "Maxim MAX31790 sensor chip"
depends on I2C
diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
index d2bdccc000e6..e0ab73e0caa6 100644
--- a/drivers/hwmon/Makefile
+++ b/drivers/hwmon/Makefile
@@ -120,6 +120,7 @@ obj-$(CONFIG_SENSORS_MAX6639)   += max6639.o
 obj-$(CONFIG_SENSORS_MAX6642)  += max6642.o
 obj-$(CONFIG_SENSORS_MAX6650)  += max6650.o
 obj-$(CONFIG_SENSORS_MAX6697)  += max6697.o
+obj-$(CONFIG_SENSORS_MAX31760)  += max31760.o
 obj-$(CONFIG_SENSORS_MAX31790) += max31790.o
 obj-$(CONFIG_SENSORS_MC13783_ADC)+= mc13783-adc.o
 obj-$(CONFIG_SENSORS_MCP3021)  += mcp3021.o
diff --git a/drivers/hwmon/max31760.c b/drivers/hwmon/max31760.c
new file mode 100644
index ..f3de3526d802
--- /dev/null
+++ b/drivers/hwmon/max31760.c
@@ -0,0 +1,1461 @@
+/* Maxim Integrated MAX31760 Precision Fan-Speed Controller driver
+ *
+ * Copyright (C) 2017 Google, Inc.
+ * Author: muirj
+ *
+ * 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define DRIVER_NAME "max31760"
+
+/*
+ * MAX31760 registers.
+ * Indentation helps identify how these constants apply:
+ *  Register number.
+ *  Per-register bit fields.
+ *  Values for multi-bit fields.
+ */
+#define MAX31760_REG_CR1   0x00 /* Control Register 1 */
+#define MAX31760_CR1_TIS0x01 /* Temperature Index Source */
+#define MAX31760_CR1_MTI0x02 /* Maximum Temperature Index */
+#define

[PATCH v2 2/2] devicetree: Document the max31760 device binding.

2017-04-11 Thread John Muir 
v2:
- Fixup based on comments.

Signed-off-by: John Muir 
---
 .../devicetree/bindings/hwmon/max31760.txt | 72 ++
 1 file changed, 72 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/hwmon/max31760.txt

diff --git a/Documentation/devicetree/bindings/hwmon/max31760.txt 
b/Documentation/devicetree/bindings/hwmon/max31760.txt
new file mode 100644
index ..760fdf0b55e0
--- /dev/null
+++ b/Documentation/devicetree/bindings/hwmon/max31760.txt
@@ -0,0 +1,72 @@
+MAX31760 fan controller
+---
+
+This device supports I2C only. Fan sub-nodes must be defined in order to enable
+the fan tachometer input. See also the datasheet:
+https://datasheets.maximintegrated.com/en/ds/MAX31760.pdf
+
+Required node properties:
+ - compatible: "maxim,max31760"
+ - reg: The I2C address of the device. This is 0x50 - 0x57 depending on the
+   hardware configuration.
+ - #address-cells: Must be 1.
+ - #size-cells: Must be 0.
+
+Optional node properties:
+ - maxim,fan-fail-full-only: Boolean; Assert a fan failure only when the PWM is
+   at 100%.
+ - maxim,fan-rd-signal: Boolean; Fans provide a rotation detection (RD) signal
+   instead of generating square-wave pulses.
+ - maxim,fan-rd-polarity-high: Boolean; RD is high when the fan is running, not
+   low. Only relevant when fan-rd-signal is true.
+ - maxim,fan-signal-enabled: Boolean; Externally driving FF/FS low should force
+   PWM output to 100%.
+ - maxim,fan-spin-up-enabled: Boolean; For fan startup set the PWM to 100% 
until
+   tach is detected or two seconds have passed before reducing to the target
+   value.
+ - maxim,pwm-polarity-negative: Boolean; 100% PWM is when PWM is low, not high.
+ - maxim,pwm-pulse-stretch-enabled: Boolean; Enable PWM pulse stretching.
+ - maxim,pwm-zero-fan-can-fail: Boolean; Enable fan failure detection while
+   ramping to 0% PWM.
+
+Fan sub-nodes must be present in order to enable the fan.
+
+Required fan sub-node properties:
+ - reg: Fan address. Must be <0x00> or <0x01>.
+
+Optional fan sub-node properties:
+ - label: String; Assigned to the hwmon fanX_label property.
+
+Temperature sub-nodes are optional.
+
+Required temp sub-node properties:
+ - reg: Temperature sensor address. Must be <0x00> or <0x01>.
+
+Optional temp sub-node properties:
+ - label: String; Assigned to the hwmon tempX_label property.
+ - ideality: For temperature node with reg 1 only: Set ideality factor for the
+   remote temperature sensor. Integer with range 0 to 63, representing a
+   multiplication factor of 0.9844 to 1.0489. Default: 24 (1.0080).
+
+Example:
+   max31760@50 {
+   compatible = "maxim,max31760";
+   reg = <0x50>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   maxim,fan-spin-up-enabled;
+
+   fan@0 {
+   reg = <0x00>;
+   label = "Left";
+   };
+   fan@1 {
+   reg = <0x01>;
+   label = "Right";
+   };
+   temp@1 {
+   reg = <0x01>;
+   label = "CPU";
+   };
+   };
-- 
2.12.2.715.g7642488e1d-goog

--
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] docs-rst: add input docs at main index and use kernel-figure

2017-04-11 Thread Jonathan Corbet 
On Tue, 11 Apr 2017 07:01:19 -0300
Mauro Carvalho Chehab  wrote:

> This patch contains the final bits of the input documentation
> conversion. The linux-input tree has already the ReST conversion
> patches, but it doesn't have the
> Documentation/sphinx/load_config.py script with implements
> the kernel-figure directive, as it got merged via docs tree.
> 
> So, either one of you should merge from the other tree or this
> patch should be sent in separate upstream after both trees
> gets merged. What do you prefer?

How about if I send it Linusward toward the end of the merge window?

FWIW, while I think the conversion is great, I'm not fully pleased with
having it as a separate top-level document.  Probably what needs to be
done here is to split it up into two pieces, one for driver-api and one
for userspace-api.  But that can happen later, I guess.

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: [PATCH v7 resend 00/20] ILP32 for ARM64

2017-04-11 Thread Yury Norov 
On Tue, Apr 11, 2017 at 08:42:24PM +0200, Florian Weimer wrote:
> On 04/11/2017 08:36 PM, Yury Norov wrote:
> >>Also, the latest benchmarks I've seen were mostly for user space
> >>while I'm more concerned with the user-kernel interface
> >>(https://marc.info/?l=linux-arm-kernel=148690490713310=2).
> >
> >>On the glibc testing side, have the regressions been identified/fixed?
> >
> >I run LTP for testing the ABI and kernel, and there is no failures in
> >ltplite scenario. With glibc testsuite, there's only 3 failures
> >comparing to lp64. (Steve, fix me if something changed.) This is
> >slides on ilp32 from Linaro Connect, hope you'll find it useful.
> >
> >https://docs.google.com/presentation/d/1TKZqgH0XJUgMMGkw2fJA3Lzr57slht1sGKYJVBJTNM4/edit?usp=sharing
> 
> The listed failures are:
> 
> misc/tst-sync_file_range
> nptl/tst-stack4
> malloc/tst-mallocstate
> 
> If necessary, I will fix malloc/tst-mallocstate once there's support for a
> new architecture in build-many-glibcs.py.  The failure is
> architecture-independent, it's related to the lack of a compat symbol and
> the difficulty of checking for that at the Makefile or test level.
> 
> nptl/tst-stack4 is also a generic failure, I think.

That would be great, thanks.

> misc/tst-sync_file_range is probably a real failure related to argument
> passing.  I think this system call was problematic on other architectures,
> too.

At first glance, it's pretty trivial, both on glibc and kernel side:

GLIBC:
int
sync_file_range (int fd, __off64_t offset, __off64_t len, unsigned int flags)
{
#if defined (__NR_sync_file_range2)
  return SYSCALL_CANCEL (sync_file_range2, fd, flags, SYSCALL_LL64 (offset),
 SYSCALL_LL64 (len));
#elif defined (__NR_sync_file_range)
  return SYSCALL_CANCEL (sync_file_range, fd,
 __ALIGNMENT_ARG SYSCALL_LL64 (offset),
 SYSCALL_LL64 (len), flags);
#endif
}

And kernel:
ENTRY(compat_sys_sync_file_range2_wrapper)
regs_to_64  x2, x2, x3
regs_to_64  x3, x4, x5
b   sys_sync_file_range2
ENDPROC(compat_sys_sync_file_range2_wrapper)

Anyway, I'll check everything and report here.

Yury
--
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 00/21] Convert USB documentation to ReST format

2017-04-11 Thread Jonathan Corbet 
On Tue, 11 Apr 2017 16:58:40 +0200
Greg Kroah-Hartman  wrote:

> Nope, they don't apply to my tree, it was probably based on yours.  And
> the first two are ones I shouldn't be taking.
> 
> So, feel free to take all of these with a:
>   Acked-by: Greg Kroah-Hartman 
> for the USB-related patches (2-21).

I have now done that.  Thanks, Mauro!

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 2/2] devicetree: Document the max31760 device binding.

2017-04-11 Thread Guenter Roeck 
On Tue, Apr 11, 2017 at 06:47:28AM -0700, John Muir wrote:
> > On Apr 10, 2017, at 8:42 AM, Rob Herring  wrote:
> > 
> > On Tue, Apr 04, 2017 at 12:20:34PM -0700, John Muir wrote:
> >> +MAX31760 fan controller
> >> +---
> >> +
> >> +This device supports I2C only. Many properties of this device are 
> >> configurable
> >> +thorugh the hwmon interface. See also Documentation/hwmon/max31760.
> > 
> > I really think we need to describe the fans as separate nodes and 
> > preferably with a common binding. This is the second fan controller 
> > binding recently[1].
> > 
> > Features of the "hwmon interface" are not relevant to the binding. 
> > Bindings describe h/w.
> 
> It seems to me that referring to the hwmon interface is only helpful. You are 
> suggesting removing those sentences? If so, can I add a link to the data 
> sheet?
> 

Devicetree properties are supposed to be operating system independent.
Any mention of how access to the device is implemented on a given
operating system is out of scope for this document.

Guenter

> > 
> >> +Optional node properties:
> >> +- maxim,fan1-enabled  - 1 to enable, 0 to disable. Default: 1.
> >> +- maxim,fan2-enabled  - 1 to enable, 0 to disable. Default: 1.
> >> +- maxim,fan1-label- String: Hwmon fan1_label.
> >> +- maxim,fan2-label- String: Hwmon fan2_label.
> > 
> > Perhaps 2 fan sub nodes. reg for fan number, status for enabled, and 
> > label for label.
> 
> OK.
> 
> Right now a fan’s number of pulses and the PWM frequency are configured using 
> the hwmon sysfs interface (which defines standard controls for those), but as 
> those are characteristics of the hardware, should they also be configured via 
> the device tree binding?
> 
> >> +- maxim,pwm-zero-fan-can-fail - 0: Fan failure detection disabled 
> >> when PWM is
> >> +   ramping to 0%.
> >> +1: Fan failure detection enabled for all PWM
> >> +   values.
> >> +Default: 0.
> > 
> > All these can be boolean…
> 
> OK. The only issue I see is when the default is ‘true’ in the device, but 
> I’ll try to avoid that. Sometimes I wish that you could set a boolean to 
> false in DTS files.
> 
> > 
> >> +- maxim,temp1-label   - String: Hwmon temp1_label.
> >> +- maxim,temp2-label   - String: Hwmon temp2_label.
> >> +- maxim,temp2-ideality- Set ideality factor for the remote 
> >> temperature
> >> +sensor. Integer with range 0 to 63,
> >> +representing a multiplication factor of 0.9844
> >> +to 1.0489. Default: 24 (1.0080).
> > 
> > No maxim,temp1-ideality?
> No - the device only lets you set the ideality of the ‘external' temperature 
> sensor. I guess if there is an ideality for the internal temperature sensor, 
> it would be hard-wired as a characteristic of the part that was used.
> 
> > Not sure what to do with these, but perhaps 
> > also as sub-nodes. Surely we have some bindings already for devices with 
> > multiple temp sensors. Don't invent something custom here.
> 
> I’ll look into it.
> 
> What is the best way to distinguish between ‘fan’ and ‘temp’ sub-nodes? Do I 
> require a ‘compatible’ string?
> 
> Thanks!
> 
> John.
> 
> 
--
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 5/5] dm verity: add support for version 0 of the on-disk format

2017-04-11 Thread Enric Balletbo i Serra 


On 11/04/17 19:21, Milan Broz wrote:
> On 04/11/2017 05:33 PM, Enric Balletbo i Serra wrote:
>> From: Will Drewry 
>>
>> Version 0 of the on-disk format is compatible with the format used in the
>> Chromium OS. This patch adds support for this version.
>>
>> Format type 0 is the original Chrome OS version, whereas the format type 1
>> is current version, but 0, the original format used in the Chromium OS is
>> still used in most devices. This patch adds support for the original
>> on-disk format so you can decide which want you want to use.
> 
> NACK!
> 
> What the ...  is this patch doing?
> 

Argh! Very sorry about that was *not* my intention add this patch in this
series, I was only trying to submit 1 to 4 which contains the patches already
send long time ago and the patches to move to the public header some functions
needed for init/do_mount_dm.c

I'm using this specific patch to test 1 to 4 and to boot against a chromeos
rootfs as it parses the current chromeos args, this patch also has the use of
some deprecated functions like simple_strtoull, so definitely this *shouldn't*
be here, my bad.

Besides that, with the below comments, you have made me see that I have some
lacks and I need to rethink some things that I wanted to send after this series,
so many thanks and sorry again if you spend some time looking at this.

> Isn't the format 0 already there? According to
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/device-mapper/verity.txt
> 
> 
> This is the type of the on-disk hash format.
> 
> 0 is the original format used in the Chromium OS.
>   The salt is appended when hashing, digests are stored continuously and
>   the rest of the block is padded with zeroes.
> 
> Reading this patch, it does something completely different than it describes
> in header.
> 
> How is superblock format related to:
> +MODULE_PARM_DESC(dev_wait, "Wait forever for a backing device");
> ...
> not mentioning complete rewrite of verity table parsing... why?
> 
> Also please note that there is userspace (veritysetup) that have to work with
> the old format as well (I think it does already).
> I think we solved the compatibility years ago.
> 
> If not, please describe properly what is missing.
> I do not see any on-disk format changes here...
> 
> Milan
> 
>>
>> Signed-off-by: Will Drewry 
>> Signed-off-by: Enric Balletbo i Serra 
>> ---
>>  drivers/md/dm-verity-target.c | 279 
>> --
>>  init/do_mounts_dm.c   |  16 +--
>>  2 files changed, 220 insertions(+), 75 deletions(-)
>>
>> diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c
>> index 7335d8a..c098d22 100644
>> --- a/drivers/md/dm-verity-target.c
>> +++ b/drivers/md/dm-verity-target.c
>> @@ -17,6 +17,7 @@
>>  #include "dm-verity.h"
>>  #include "dm-verity-fec.h"
>>  
>> +#include 
>>  #include 
>>  #include 
>>  
>> @@ -28,6 +29,7 @@
>>  #define DM_VERITY_DEFAULT_PREFETCH_SIZE 262144
>>  
>>  #define DM_VERITY_MAX_CORRUPTED_ERRS100
>> +#define DM_VERITY_NUM_POSITIONAL_ARGS   10
>>  
>>  #define DM_VERITY_OPT_LOGGING   "ignore_corruption"
>>  #define DM_VERITY_OPT_RESTART   "restart_on_corruption"
>> @@ -46,6 +48,11 @@ struct dm_verity_prefetch_work {
>>  unsigned n_blocks;
>>  };
>>  
>> +/* Controls whether verity_get_device will wait forever for a device. */
>> +static int dev_wait;
>> +module_param(dev_wait, int, 0444);
>> +MODULE_PARM_DESC(dev_wait, "Wait forever for a backing device");
>> +
>>  /*
>>   * Auxiliary structure appended to each dm-bufio buffer. If the value
>>   * hash_verified is nonzero, hash of the block has been verified.
>> @@ -803,6 +810,183 @@ static int verity_parse_opt_args(struct dm_arg_set 
>> *as, struct dm_verity *v)
>>  return r;
>>  }
>>  
>> +static int verity_get_device(struct dm_target *ti, const char *devname,
>> + struct dm_dev **dm_dev)
>> +{
>> +do {
>> +/* Try the normal path first since if everything is ready, it
>> + * will be the fastest.
>> + */
>> +if (!dm_get_device(ti, devname, /*FMODE_READ*/
>> +   dm_table_get_mode(ti->table), dm_dev))
>> +return 0;
>> +
>> +if (!dev_wait)
>> +break;
>> +
>> +/* No need to be too aggressive since this is a slow path. */
>> +msleep(500);
>> +} while (driver_probe_done() != 0 || !(*dm_dev));
>> +return -1;
>> +}
>> +
>> +struct verity_args {
>> +int version;
>> +char *data_device;
>> +char *hash_device;
>> +int data_block_size_bits;
>> +int hash_block_size_bits;
>> +u64 num_data_blocks;
>> +u64 hash_start_block;
>> +char *algorithm;
>> +char *digest;
>> +char *salt;
>> +};
>> +
>> +static void pr_args(struct verity_args

Re: [GIT PULL] PCI: Support for configurable PCI endpoint

2017-04-11 Thread Bjorn Helgaas 
On Mon, Apr 10, 2017 at 10:43:28AM -0500, Bjorn Helgaas wrote:
> On Wed, Apr 05, 2017 at 02:22:20PM +0530, Kishon Vijay Abraham I wrote:
> > Hi Bjorn,
> > 
> > Please find the pull request for PCI endpoint support below. I've
> > also included all the history here.
> 
> Thanks, I applied these (with v7 of the first patch) to pci/host-designware
> for v4.12.

Ok, sorry, I screwed this up.  I think my branch actually had v5, not
v6.  But I *think* I fixed it.  Here's the diff from my branch to your
git tree.  Apparently you haven't pushed the v7 patch there, so I
*think* the diff below is the diff between v6 and v7 of that first
patch.

$ git diff pci/host-designware a5c85ba45c96
diff --git a/drivers/pci/endpoint/pci-epc-core.c 
b/drivers/pci/endpoint/pci-epc-core.c
index caa7be10e473..9ae9e59b2a74 100644
--- a/drivers/pci/endpoint/pci-epc-core.c
+++ b/drivers/pci/endpoint/pci-epc-core.c
@@ -83,7 +83,6 @@ struct pci_epc *pci_epc_get(const char *epc_name)
goto err;
}
 
-   class_dev_iter_exit();
get_device(>dev);
return epc;
}
diff --git a/drivers/pci/endpoint/pci-epf-core.c 
b/drivers/pci/endpoint/pci-epf-core.c
index 6877d6a5bcc9..92db7dcd911c 100644
--- a/drivers/pci/endpoint/pci-epf-core.c
+++ b/drivers/pci/endpoint/pci-epf-core.c
@@ -40,10 +40,8 @@ static struct device_type pci_epf_type;
  */
 void pci_epf_linkup(struct pci_epf *epf)
 {
-   if (!epf->driver) {
+   if (!epf->driver)
dev_WARN(>dev, "epf device not bound to driver\n");
-   return;
-   }
 
epf->driver->ops->linkup(epf);
 }
@@ -59,10 +57,8 @@ EXPORT_SYMBOL_GPL(pci_epf_linkup);
  */
 void pci_epf_unbind(struct pci_epf *epf)
 {
-   if (!epf->driver) {
+   if (!epf->driver)
dev_WARN(>dev, "epf device not bound to driver\n");
-   return;
-   }
 
epf->driver->ops->unbind(epf);
module_put(epf->driver->owner);
@@ -78,10 +74,8 @@ EXPORT_SYMBOL_GPL(pci_epf_unbind);
  */
 int pci_epf_bind(struct pci_epf *epf)
 {
-   if (!epf->driver) {
+   if (!epf->driver)
dev_WARN(>dev, "epf device not bound to driver\n");
-   return -EINVAL;
-   }
 
if (!try_module_get(epf->driver->owner))
return -EAGAIN;
@@ -233,7 +227,7 @@ struct pci_epf *pci_epf_create(const char *name)
epf->name = kstrdup(func_name, GFP_KERNEL);
if (!epf->name) {
ret = -ENOMEM;
-   goto free_func_name;
+   goto free_epf;
}
 
dev = >dev;
@@ -255,8 +249,6 @@ struct pci_epf *pci_epf_create(const char *name)
 put_dev:
put_device(dev);
kfree(epf->name);
-
-free_func_name:
kfree(func_name);
 
 free_epf:
--
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 v7 resend 00/20] ILP32 for ARM64

2017-04-11 Thread Florian Weimer 

On 04/11/2017 08:36 PM, Yury Norov wrote:

Also, the latest benchmarks I've seen were mostly for user space
while I'm more concerned with the user-kernel interface
(https://marc.info/?l=linux-arm-kernel=148690490713310=2).



On the glibc testing side, have the regressions been identified/fixed?


I run LTP for testing the ABI and kernel, and there is no failures in
ltplite scenario. With glibc testsuite, there's only 3 failures
comparing to lp64. (Steve, fix me if something changed.) This is
slides on ilp32 from Linaro Connect, hope you'll find it useful.

https://docs.google.com/presentation/d/1TKZqgH0XJUgMMGkw2fJA3Lzr57slht1sGKYJVBJTNM4/edit?usp=sharing


The listed failures are:

misc/tst-sync_file_range
nptl/tst-stack4
malloc/tst-mallocstate

If necessary, I will fix malloc/tst-mallocstate once there's support for 
a new architecture in build-many-glibcs.py.  The failure is 
architecture-independent, it's related to the lack of a compat symbol 
and the difficulty of checking for that at the Makefile or test level.


nptl/tst-stack4 is also a generic failure, I think.

misc/tst-sync_file_range is probably a real failure related to argument 
passing.  I think this system call was problematic on other 
architectures, too.


Thanks,
Florian

(Sorry for the wide Cc: list despite the glibc content.)
--
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 00/21] Convert USB documentation to ReST format

2017-04-11 Thread Greg Kroah-Hartman 
On Tue, Apr 11, 2017 at 03:36:39PM -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 11 Apr 2017 16:58:40 +0200
> Greg Kroah-Hartman  escreveu:
> 
> > On Sat, Apr 08, 2017 at 10:04:33PM +0200, Greg Kroah-Hartman wrote:
> > > On Sat, Apr 08, 2017 at 11:23:28AM -0600, Jonathan Corbet wrote:  
> > > > On Wed,  5 Apr 2017 10:22:54 -0300
> > > > Mauro Carvalho Chehab  wrote:
> > > >   
> > > > > Currently, there are several USB core documents that are at either
> > > > > written in plain text or in DocBook format. Convert them to ReST
> > > > > and add to the driver-api book.  
> > > > 
> > > > Greg, do you see any reason not to apply these for 4.12?  A few of them
> > > > touch comments outside of Documentation/; I'm happy to carry those or
> > > > leave them to you, as you prefer.  
> > > 
> > > I'll queue them up in the next few days, thanks!  
> > 
> > Nope, they don't apply to my tree, it was probably based on yours.  And
> > the first two are ones I shouldn't be taking.
> 
> Yeah, I based it at the docs-next tree. If you prefer, I can rebase
> on your tree, but I guess that the docbook conversion patches
> would likely conflict with some patches at docs-next, because of
> the Makefile changes.

Doesn't bother me, it can go through the Documentation tree as-is.

thanks,

greg k-h
--
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 v7 resend 00/20] ILP32 for ARM64

2017-04-11 Thread Yury Norov 
> Also, the latest benchmarks I've seen were mostly for user space
> while I'm more concerned with the user-kernel interface
> (https://marc.info/?l=linux-arm-kernel=148690490713310=2).

> On the glibc testing side, have the regressions been identified/fixed?

I run LTP for testing the ABI and kernel, and there is no failures in
ltplite scenario. With glibc testsuite, there's only 3 failures
comparing to lp64. (Steve, fix me if something changed.) This is
slides on ilp32 from Linaro Connect, hope you'll find it useful.

https://docs.google.com/presentation/d/1TKZqgH0XJUgMMGkw2fJA3Lzr57slht1sGKYJVBJTNM4/edit?usp=sharing

Yury
--
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 00/21] Convert USB documentation to ReST format

2017-04-11 Thread Mauro Carvalho Chehab 
Em Tue, 11 Apr 2017 16:58:40 +0200
Greg Kroah-Hartman  escreveu:

> On Sat, Apr 08, 2017 at 10:04:33PM +0200, Greg Kroah-Hartman wrote:
> > On Sat, Apr 08, 2017 at 11:23:28AM -0600, Jonathan Corbet wrote:  
> > > On Wed,  5 Apr 2017 10:22:54 -0300
> > > Mauro Carvalho Chehab  wrote:
> > >   
> > > > Currently, there are several USB core documents that are at either
> > > > written in plain text or in DocBook format. Convert them to ReST
> > > > and add to the driver-api book.  
> > > 
> > > Greg, do you see any reason not to apply these for 4.12?  A few of them
> > > touch comments outside of Documentation/; I'm happy to carry those or
> > > leave them to you, as you prefer.  
> > 
> > I'll queue them up in the next few days, thanks!  
> 
> Nope, they don't apply to my tree, it was probably based on yours.  And
> the first two are ones I shouldn't be taking.

Yeah, I based it at the docs-next tree. If you prefer, I can rebase
on your tree, but I guess that the docbook conversion patches
would likely conflict with some patches at docs-next, because of
the Makefile changes.

> So, feel free to take all of these with a:
>   Acked-by: Greg Kroah-Hartman 
> for the USB-related patches (2-21).
> 
> thanks,
> 
> greg k-h



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 v6] kvm: better MWAIT emulation for guests

2017-04-11 Thread Alexander Graf 


> Am 11.04.2017 um 19:10 schrieb Jim Mattson :
> 
> This might be more useful if it could be dynamically toggled on and
> off, depending on system load.

What would trapping mwait (currently) buy you?

As it stands today, before this patch, mwait is simply implemented as a nop, so 
enabling the trap just means you're wasting as much cpu time, but never send 
the pCPU idle. With this patch, the CPU at least has the chance to go idle.

Keep in mind that this patch does *not* advertise the mwait cpuid feature bit 
to the guest.

What you're referring to I guess is actual mwait emulation. That is indeed more 
useful, but a bigger patch than this and needs some more thought on how to 
properly cache the monitor'ed pages.


Alex


--
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 5/5] dm verity: add support for version 0 of the on-disk format

2017-04-11 Thread Milan Broz 
On 04/11/2017 05:33 PM, Enric Balletbo i Serra wrote:
> From: Will Drewry 
> 
> Version 0 of the on-disk format is compatible with the format used in the
> Chromium OS. This patch adds support for this version.
> 
> Format type 0 is the original Chrome OS version, whereas the format type 1
> is current version, but 0, the original format used in the Chromium OS is
> still used in most devices. This patch adds support for the original
> on-disk format so you can decide which want you want to use.

NACK!

What the ...  is this patch doing?

Isn't the format 0 already there? According to
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/device-mapper/verity.txt


This is the type of the on-disk hash format.

0 is the original format used in the Chromium OS.
  The salt is appended when hashing, digests are stored continuously and
  the rest of the block is padded with zeroes.

Reading this patch, it does something completely different than it describes
in header.

How is superblock format related to:
+MODULE_PARM_DESC(dev_wait, "Wait forever for a backing device");
...
not mentioning complete rewrite of verity table parsing... why?

Also please note that there is userspace (veritysetup) that have to work with
the old format as well (I think it does already).
I think we solved the compatibility years ago.

If not, please describe properly what is missing.
I do not see any on-disk format changes here...

Milan

> 
> Signed-off-by: Will Drewry 
> Signed-off-by: Enric Balletbo i Serra 
> ---
>  drivers/md/dm-verity-target.c | 279 
> --
>  init/do_mounts_dm.c   |  16 +--
>  2 files changed, 220 insertions(+), 75 deletions(-)
> 
> diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c
> index 7335d8a..c098d22 100644
> --- a/drivers/md/dm-verity-target.c
> +++ b/drivers/md/dm-verity-target.c
> @@ -17,6 +17,7 @@
>  #include "dm-verity.h"
>  #include "dm-verity-fec.h"
>  
> +#include 
>  #include 
>  #include 
>  
> @@ -28,6 +29,7 @@
>  #define DM_VERITY_DEFAULT_PREFETCH_SIZE  262144
>  
>  #define DM_VERITY_MAX_CORRUPTED_ERRS 100
> +#define DM_VERITY_NUM_POSITIONAL_ARGS10
>  
>  #define DM_VERITY_OPT_LOGGING"ignore_corruption"
>  #define DM_VERITY_OPT_RESTART"restart_on_corruption"
> @@ -46,6 +48,11 @@ struct dm_verity_prefetch_work {
>   unsigned n_blocks;
>  };
>  
> +/* Controls whether verity_get_device will wait forever for a device. */
> +static int dev_wait;
> +module_param(dev_wait, int, 0444);
> +MODULE_PARM_DESC(dev_wait, "Wait forever for a backing device");
> +
>  /*
>   * Auxiliary structure appended to each dm-bufio buffer. If the value
>   * hash_verified is nonzero, hash of the block has been verified.
> @@ -803,6 +810,183 @@ static int verity_parse_opt_args(struct dm_arg_set *as, 
> struct dm_verity *v)
>   return r;
>  }
>  
> +static int verity_get_device(struct dm_target *ti, const char *devname,
> +  struct dm_dev **dm_dev)
> +{
> + do {
> + /* Try the normal path first since if everything is ready, it
> +  * will be the fastest.
> +  */
> + if (!dm_get_device(ti, devname, /*FMODE_READ*/
> +dm_table_get_mode(ti->table), dm_dev))
> + return 0;
> +
> + if (!dev_wait)
> + break;
> +
> + /* No need to be too aggressive since this is a slow path. */
> + msleep(500);
> + } while (driver_probe_done() != 0 || !(*dm_dev));
> + return -1;
> +}
> +
> +struct verity_args {
> + int version;
> + char *data_device;
> + char *hash_device;
> + int data_block_size_bits;
> + int hash_block_size_bits;
> + u64 num_data_blocks;
> + u64 hash_start_block;
> + char *algorithm;
> + char *digest;
> + char *salt;
> +};
> +
> +static void pr_args(struct verity_args *args)
> +{
> + printk(KERN_INFO "VERITY args: version=%d data_device=%s hash_device=%s"
> + " data_block_size_bits=%d hash_block_size_bits=%d"
> + " num_data_blocks=%lld hash_start_block=%lld"
> + " algorithm=%s digest=%s salt=%s\n",
> + args->version,
> + args->data_device,
> + args->hash_device,
> + args->data_block_size_bits,
> + args->hash_block_size_bits,
> + args->num_data_blocks,
> + args->hash_start_block,
> + args->algorithm,
> + args->digest,
> + args->salt);
> +}
> +
> +/*
> + * positional_args - collects the argments using the positional
> + * parameters.
> + * arg# - parameter
> + *0 - version
> + *1 - data device
> + *2 - hash device - may be same as data device
> + *3 - data block size log2
> + *4 - hash

Re: [PATCH v6] kvm: better MWAIT emulation for guests

2017-04-11 Thread Jim Mattson 
This might be more useful if it could be dynamically toggled on and
off, depending on system load.

On Tue, Apr 11, 2017 at 4:45 AM, Alexander Graf  wrote:
> From: "Michael S. Tsirkin" 
>
> Guests that are heavy on futexes end up IPI'ing each other a lot. That
> can lead to significant slowdowns and latency increase for those guests
> when running within KVM.
>
> If only a single guest is needed on a host, we have a lot of spare host
> CPU time we can throw at the problem. Modern CPUs implement a feature
> called "MWAIT" which allows guests to wake up sleeping remote CPUs without
> an IPI - thus without an exit - at the expense of never going out of guest
> context.
>
> The decision whether this is something sensible to use should be up to the
> VM admin, so to user space. We can however allow MWAIT execution on systems
> that support it properly hardware wise.
>
> This patch adds a CAP to user space and a KVM cpuid leaf to indicate
> availability of native MWAIT execution. With that enabled, the worst a
> guest can do is waste as many cycles as a "jmp ." would do, so it's not
> a privilege problem.
>
> We consciously do *not* expose the feature in our CPUID bitmap, as most
> people will want to benefit from sleeping vCPUs to allow for over commit.
>
> Reported-by: "Gabriel L. Somlo" 
> Signed-off-by: Michael S. Tsirkin 
> [agraf: fix amd, change commit message]
> Signed-off-by: Alexander Graf 
>
> ---
>
> v5 -> v6:
>
>   - Fix AMD check, so that we're consistent between svm and vmx
>   - Clarify commit message
> ---
>  Documentation/virtual/kvm/api.txt|  9 +
>  Documentation/virtual/kvm/cpuid.txt  |  6 ++
>  arch/x86/include/uapi/asm/kvm_para.h |  1 +
>  arch/x86/kvm/cpuid.c |  3 +++
>  arch/x86/kvm/svm.c   |  7 +--
>  arch/x86/kvm/vmx.c   |  6 --
>  arch/x86/kvm/x86.c   |  3 +++
>  arch/x86/kvm/x86.h   | 36 
> 
>  include/uapi/linux/kvm.h |  1 +
>  9 files changed, 68 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/virtual/kvm/api.txt 
> b/Documentation/virtual/kvm/api.txt
> index 1a18484..dacc3d7 100644
> --- a/Documentation/virtual/kvm/api.txt
> +++ b/Documentation/virtual/kvm/api.txt
> @@ -4094,3 +4094,12 @@ reserved.
>   2: MIPS64 or microMIPS64 with access to all address segments.
>  Both registers and addresses are 64-bits wide.
>  It will be possible to run 64-bit or 32-bit guest code.
> +
> +8.8 KVM_CAP_X86_GUEST_MWAIT
> +
> +Architectures: x86
> +
> +This capability indicates that guest using memory monotoring instructions
> +(MWAIT/MWAITX) to stop the virtual CPU will not cause a VM exit.  As such 
> time
> +spent while virtual CPU is halted in this way will then be accounted for as
> +guest running time on the host (as opposed to e.g. HLT).
> diff --git a/Documentation/virtual/kvm/cpuid.txt 
> b/Documentation/virtual/kvm/cpuid.txt
> index 3c65feb..04c201c 100644
> --- a/Documentation/virtual/kvm/cpuid.txt
> +++ b/Documentation/virtual/kvm/cpuid.txt
> @@ -54,6 +54,12 @@ KVM_FEATURE_PV_UNHALT  || 7 || guest 
> checks this feature bit
> ||   || before enabling 
> paravirtualized
> ||   || spinlock support.
>  
> --
> +KVM_FEATURE_MWAIT  || 8 || guest can use monitor/mwait
> +   ||   || to halt the VCPU without 
> exits,
> +   ||   || time spent while halted in 
> this
> +   ||   || way is accounted for on host 
> as
> +   ||   || VCPU run time.
> +--
>  KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||24 || host will warn if no 
> guest-side
> ||   || per-cpu warps are expected in
> ||   || kvmclock.
> diff --git a/arch/x86/include/uapi/asm/kvm_para.h 
> b/arch/x86/include/uapi/asm/kvm_para.h
> index cff0bb6..9cc77a7 100644
> --- a/arch/x86/include/uapi/asm/kvm_para.h
> +++ b/arch/x86/include/uapi/asm/kvm_para.h
> @@ -24,6 +24,7 @@
>  #define KVM_FEATURE_STEAL_TIME 5
>  #define KVM_FEATURE_PV_EOI 6
>  #define KVM_FEATURE_PV_UNHALT  7
> +#define KVM_FEATURE_MWAIT  8
>
>  /* The last 8 bits are used to indicate how to interpret the flags field
>   * in pvclock structure. If no bits are set, all flags are ignored.
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index efde6cc..5638102 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -594,6 +594,9 @@ static inline int __do_cpuid_ent(struct

[PATCH 2/5] dm: move dm definitions outside the private header to boot dm targets.

2017-04-11 Thread Enric Balletbo i Serra 
To boot to device-mapper targets without an initr* we should be able to
use some dm functions, move these to the device-mapper include file so
we can call these functions from init/*

The functions moved are:

  dm_table_get_type()
  dm_lock_md_type()
  dm_unlock_md_type()
  dm_set_md_type()
  dm_get_md_type()
  dm_setup_md_queue()

Signed-off-by: Enric Balletbo i Serra 
---
 drivers/md/dm.h   | 7 ---
 include/linux/device-mapper.h | 8 
 2 files changed, 8 insertions(+), 7 deletions(-)

diff --git a/drivers/md/dm.h b/drivers/md/dm.h
index c54d2f1..6b501b5 100644
--- a/drivers/md/dm.h
+++ b/drivers/md/dm.h
@@ -63,7 +63,6 @@ void dm_table_presuspend_undo_targets(struct dm_table *t);
 void dm_table_postsuspend_targets(struct dm_table *t);
 int dm_table_resume_targets(struct dm_table *t);
 int dm_table_any_congested(struct dm_table *t, int bdi_bits);
-unsigned dm_table_get_type(struct dm_table *t);
 struct target_type *dm_table_get_immutable_target_type(struct dm_table *t);
 struct dm_target *dm_table_get_immutable_target(struct dm_table *t);
 struct dm_target *dm_table_get_wildcard_target(struct dm_table *t);
@@ -73,14 +72,8 @@ bool dm_table_all_blk_mq_devices(struct dm_table *t);
 void dm_table_free_md_mempools(struct dm_table *t);
 struct dm_md_mempools *dm_table_get_md_mempools(struct dm_table *t);
 
-void dm_lock_md_type(struct mapped_device *md);
-void dm_unlock_md_type(struct mapped_device *md);
-void dm_set_md_type(struct mapped_device *md, unsigned type);
-unsigned dm_get_md_type(struct mapped_device *md);
 struct target_type *dm_get_immutable_target_type(struct mapped_device *md);
 
-int dm_setup_md_queue(struct mapped_device *md, struct dm_table *t);
-
 /*
  * To check the return value from dm_table_find_target().
  */
diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h
index 70cb6af..013ac2e 100644
--- a/include/linux/device-mapper.h
+++ b/include/linux/device-mapper.h
@@ -513,6 +513,14 @@ void dm_table_run_md_queue_async(struct dm_table *t);
 struct dm_table *dm_swap_table(struct mapped_device *md,
   struct dm_table *t);
 
+unsigned dm_table_get_type(struct dm_table *t);
+
+void dm_lock_md_type(struct mapped_device *md);
+void dm_unlock_md_type(struct mapped_device *md);
+void dm_set_md_type(struct mapped_device *md, unsigned type);
+unsigned dm_get_md_type(struct mapped_device *md);
+int dm_setup_md_queue(struct mapped_device *md, struct dm_table *t);
+
 /*
  * A wrapper around vmalloc.
  */
-- 
2.9.3

--
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 3/5] dm: export a table+mapped device to the ioctl interface

2017-04-11 Thread Enric Balletbo i Serra 
From: Will Drewry 

One function is added which allows for a programmatically created
mapped device to be inserted into the dm-ioctl hash table. This binds
the device to a name and, optional, uuid which is needed by udev and
allows for userspace management of the mapped device.

Signed-off-by: Will Drewry 
Signed-off-by: Enric Balletbo i Serra 
---
 drivers/md/dm-ioctl.c | 39 +++
 include/linux/device-mapper.h |  6 ++
 2 files changed, 45 insertions(+)

diff --git a/drivers/md/dm-ioctl.c b/drivers/md/dm-ioctl.c
index 4da6fc6..cdd7a14 100644
--- a/drivers/md/dm-ioctl.c
+++ b/drivers/md/dm-ioctl.c
@@ -1929,6 +1929,45 @@ void dm_interface_exit(void)
 }
 
 /**
+ * dm_ioctl_export - Permanently export a mapped device via the ioctl interface
+ * @md: Pointer to mapped_device
+ * @name: Buffer (size DM_NAME_LEN) for name
+ * @uuid: Buffer (size DM_UUID_LEN) for uuid or NULL if not desired
+ */
+int dm_ioctl_export(struct mapped_device *md, const char *name,
+   const char *uuid)
+{
+   int r = 0;
+   struct hash_cell *hc;
+
+   if (!md) {
+   r = -ENXIO;
+   goto out;
+   }
+
+   /* The name and uuid can only be set once. */
+   mutex_lock(_hash_cells_mutex);
+   hc = dm_get_mdptr(md);
+   mutex_unlock(_hash_cells_mutex);
+   if (hc) {
+   DMERR("%s: already exported", dm_device_name(md));
+   r = -ENXIO;
+   goto out;
+   }
+
+   r = dm_hash_insert(name, uuid, md);
+   if (r) {
+   DMERR("%s: could not bind to '%s'", dm_device_name(md), name);
+   goto out;
+   }
+
+   /* Let udev know we've changed. */
+   dm_kobject_uevent(md, KOBJ_CHANGE, dm_get_event_nr(md));
+out:
+   return r;
+}
+
+/**
  * dm_copy_name_and_uuid - Copy mapped device name & uuid into supplied buffers
  * @md: Pointer to mapped_device
  * @name: Buffer (size DM_NAME_LEN) for name
diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h
index 013ac2e..b60892e 100644
--- a/include/linux/device-mapper.h
+++ b/include/linux/device-mapper.h
@@ -405,6 +405,12 @@ void dm_set_mdptr(struct mapped_device *md, void *ptr);
 void *dm_get_mdptr(struct mapped_device *md);
 
 /*
+ * Export the device via the ioctl interface (uses mdptr).
+ */
+int dm_ioctl_export(struct mapped_device *md, const char *name,
+   const char *uuid);
+
+/*
  * A device can still be used while suspended, but I/O is deferred.
  */
 int dm_suspend(struct mapped_device *md, unsigned suspend_flags);
-- 
2.9.3

--
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 4/5] init: add support to directly boot to a mapped device

2017-04-11 Thread Enric Balletbo i Serra 
From: Will Drewry 

Add a dm= kernel parameter modeled after the md= parameter from
do_mounts_md. It allows for device-mapper targets to be configured at
boot time for use early in the boot process (as the root device or
otherwise).

Signed-off-by: Will Drewry 
Signed-off-by: Enric Balletbo i Serra 
---
 Documentation/admin-guide/kernel-parameters.rst |   1 +
 Documentation/admin-guide/kernel-parameters.txt |   3 +
 Documentation/device-mapper/boot.txt|  42 +++
 init/Makefile   |   1 +
 init/do_mounts.c|   1 +
 init/do_mounts.h|  10 +
 init/do_mounts_dm.c | 478 
 7 files changed, 536 insertions(+)
 create mode 100644 Documentation/device-mapper/boot.txt
 create mode 100644 init/do_mounts_dm.c

diff --git a/Documentation/admin-guide/kernel-parameters.rst 
b/Documentation/admin-guide/kernel-parameters.rst
index b516164..ecb58d6 100644
--- a/Documentation/admin-guide/kernel-parameters.rst
+++ b/Documentation/admin-guide/kernel-parameters.rst
@@ -91,6 +91,7 @@ parameter is applicable::
BLACKFIN Blackfin architecture is enabled.
CLK Common clock infrastructure is enabled.
CMA Contiguous Memory Area support is enabled.
+   DM  Device mapper support is enabled.
DRM Direct Rendering Management support is enabled.
DYNAMIC_DEBUG Build in debug messages and enable them at runtime
EDD BIOS Enhanced Disk Drive Services (EDD) is enabled
diff --git a/Documentation/admin-guide/kernel-parameters.txt 
b/Documentation/admin-guide/kernel-parameters.txt
index 2ba45ca..686453d 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -830,6 +830,9 @@
 
dis_ucode_ldr   [X86] Disable the microcode loader.
 
+   dm= [DM] Allows early creation of a device-mapper device.
+   See Documentation/device-mapper/boot.txt.
+
dma_debug=off   If the kernel is compiled with DMA_API_DEBUG support,
this option disables the debugging code at boot.
 
diff --git a/Documentation/device-mapper/boot.txt 
b/Documentation/device-mapper/boot.txt
new file mode 100644
index 000..76ea6ac
--- /dev/null
+++ b/Documentation/device-mapper/boot.txt
@@ -0,0 +1,42 @@
+Boot time creation of mapped devices
+===
+
+It is possible to configure a device mapper device to act as the root
+device for your system in two ways.
+
+The first is to build an initial ramdisk which boots to a minimal
+userspace which configures the device, then pivot_root(8) in to it.
+
+For simple device mapper configurations, it is possible to boot directly
+using the following kernel command line:
+
+dm="  ,table line 1,...,table line n"
+
+name = the name to associate with the device
+   after boot, udev, if used, will use that name to label
+   the device node.
+uuid = may be 'none' or the UUID desired for the device.
+ro = may be 'ro' or 'rw'.  If 'ro', the device and device table will be
+   marked read-only.
+
+Each table line may be as normal when using the dmsetup tool except for
+two variations:
+1. Any use of commas will be interpreted as a newline
+2. Quotation marks cannot be escaped and cannot be used without
+   terminating the dm= argument.
+
+Unless renamed by udev, the device node created will be dm-0 as the
+first minor number for the device-mapper is used during early creation.
+
+Example
+===
+
+- Booting to a linear array made up of user-mode linux block devices:
+
+  dm="lroot none 0, 0 4096 linear 98:16 0, 4096 4096 linear 98:32 0" \
+  root=/dev/dm-0
+
+Will boot to a rw dm-linear target of 8192 sectors split across two
+block devices identified by their major:minor numbers.  After boot, udev
+will rename this target to /dev/mapper/lroot (depending on the rules).
+No uuid was assigned.
diff --git a/init/Makefile b/init/Makefile
index c4fb455..30424d7 100644
--- a/init/Makefile
+++ b/init/Makefile
@@ -20,6 +20,7 @@ mounts-y  := do_mounts.o
 mounts-$(CONFIG_BLK_DEV_RAM)   += do_mounts_rd.o
 mounts-$(CONFIG_BLK_DEV_INITRD)+= do_mounts_initrd.o
 mounts-$(CONFIG_BLK_DEV_MD)+= do_mounts_md.o
+mounts-$(CONFIG_BLK_DEV_DM)+= do_mounts_dm.o
 
 # dependencies on generated files need to be listed explicitly
 $(obj)/version.o: include/generated/compile.h
diff --git a/init/do_mounts.c b/init/do_mounts.c
index c2de510..8b9182b 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -566,6 +566,7 @@ void __init prepare_namespace(void)
wait_for_device_probe();
 
md_run_setup();
+   dm_run_setup();
 
if (saved_root_name[0]) {
root_device_name = saved_root_name;
diff --git a/init/do_mounts.h b/init/do_mounts.h
index

[PATCH 5/5] dm verity: add support for version 0 of the on-disk format

2017-04-11 Thread Enric Balletbo i Serra 
From: Will Drewry 

Version 0 of the on-disk format is compatible with the format used in the
Chromium OS. This patch adds support for this version.

Format type 0 is the original Chrome OS version, whereas the format type 1
is current version, but 0, the original format used in the Chromium OS is
still used in most devices. This patch adds support for the original
on-disk format so you can decide which want you want to use.

Signed-off-by: Will Drewry 
Signed-off-by: Enric Balletbo i Serra 
---
 drivers/md/dm-verity-target.c | 279 --
 init/do_mounts_dm.c   |  16 +--
 2 files changed, 220 insertions(+), 75 deletions(-)

diff --git a/drivers/md/dm-verity-target.c b/drivers/md/dm-verity-target.c
index 7335d8a..c098d22 100644
--- a/drivers/md/dm-verity-target.c
+++ b/drivers/md/dm-verity-target.c
@@ -17,6 +17,7 @@
 #include "dm-verity.h"
 #include "dm-verity-fec.h"
 
+#include 
 #include 
 #include 
 
@@ -28,6 +29,7 @@
 #define DM_VERITY_DEFAULT_PREFETCH_SIZE262144
 
 #define DM_VERITY_MAX_CORRUPTED_ERRS   100
+#define DM_VERITY_NUM_POSITIONAL_ARGS  10
 
 #define DM_VERITY_OPT_LOGGING  "ignore_corruption"
 #define DM_VERITY_OPT_RESTART  "restart_on_corruption"
@@ -46,6 +48,11 @@ struct dm_verity_prefetch_work {
unsigned n_blocks;
 };
 
+/* Controls whether verity_get_device will wait forever for a device. */
+static int dev_wait;
+module_param(dev_wait, int, 0444);
+MODULE_PARM_DESC(dev_wait, "Wait forever for a backing device");
+
 /*
  * Auxiliary structure appended to each dm-bufio buffer. If the value
  * hash_verified is nonzero, hash of the block has been verified.
@@ -803,6 +810,183 @@ static int verity_parse_opt_args(struct dm_arg_set *as, 
struct dm_verity *v)
return r;
 }
 
+static int verity_get_device(struct dm_target *ti, const char *devname,
+struct dm_dev **dm_dev)
+{
+   do {
+   /* Try the normal path first since if everything is ready, it
+* will be the fastest.
+*/
+   if (!dm_get_device(ti, devname, /*FMODE_READ*/
+  dm_table_get_mode(ti->table), dm_dev))
+   return 0;
+
+   if (!dev_wait)
+   break;
+
+   /* No need to be too aggressive since this is a slow path. */
+   msleep(500);
+   } while (driver_probe_done() != 0 || !(*dm_dev));
+   return -1;
+}
+
+struct verity_args {
+   int version;
+   char *data_device;
+   char *hash_device;
+   int data_block_size_bits;
+   int hash_block_size_bits;
+   u64 num_data_blocks;
+   u64 hash_start_block;
+   char *algorithm;
+   char *digest;
+   char *salt;
+};
+
+static void pr_args(struct verity_args *args)
+{
+   printk(KERN_INFO "VERITY args: version=%d data_device=%s hash_device=%s"
+   " data_block_size_bits=%d hash_block_size_bits=%d"
+   " num_data_blocks=%lld hash_start_block=%lld"
+   " algorithm=%s digest=%s salt=%s\n",
+   args->version,
+   args->data_device,
+   args->hash_device,
+   args->data_block_size_bits,
+   args->hash_block_size_bits,
+   args->num_data_blocks,
+   args->hash_start_block,
+   args->algorithm,
+   args->digest,
+   args->salt);
+}
+
+/*
+ * positional_args - collects the argments using the positional
+ * parameters.
+ * arg# - parameter
+ *0 - version
+ *1 - data device
+ *2 - hash device - may be same as data device
+ *3 - data block size log2
+ *4 - hash block size log2
+ *5 - number of data blocks
+ *6 - hash start block
+ *7 - algorithm
+ *8 - digest
+ *9 - salt
+ */
+static char *positional_args(unsigned argc, char **argv,
+struct verity_args *args)
+{
+   unsigned int num;
+   unsigned long long num_ll;
+   char dummy;
+
+   if (argc < DM_VERITY_NUM_POSITIONAL_ARGS)
+   return "Invalid argument count: at least 10 arguments required";
+
+   if (sscanf(argv[0], "%d%c", , ) != 1 ||
+   num < 0 || num > 1)
+   return "Invalid version";
+   args->version = num;
+
+   args->data_device = argv[1];
+   args->hash_device = argv[2];
+
+   if (sscanf(argv[3], "%u%c", , ) != 1 ||
+   !num || (num & (num - 1)) ||
+   num > PAGE_SIZE)
+   return "Invalid data device block size";
+   args->data_block_size_bits = ffs(num) - 1;
+
+   if (sscanf(argv[4], "%u%c", , ) != 1 ||
+   !num || (num & (num - 1)) ||
+   num > INT_MAX)
+   return "Invalid hash device block size";
+   args->hash_block_size_bits = ffs(num) - 1;
+
+   if (sscanf(argv[5], "%llu%c", _ll, ) != 1

[PATCH 0/5] dm: boot a mapped device without an initramfs

2017-04-11 Thread Enric Balletbo i Serra 
Hello,

Some of these patches were send few years back, I saw that first
version was send to this list in 2010, and after some reviews did not
landi [1] , apparently without any reason.

The patches has been used and working well on the ChromeOS kernel for
long time, this version is basically a rebase on top of mainline based
on latest version found in chromeos 4.4 kernel, the patches has also
been tested on a veyron device.

This a new attempt to try to land these patches again, so I'll wait
for comments/reviews and send new version to the list.

[1] Patchwork links:
https://patchwork.kernel.org/patch/104857/
https://patchwork.kernel.org/patch/104856/
https://patchwork.kernel.org/patch/104858/

Best regards,
 Enric

Brian Norris (1):
  dm: move dm_table_destroy() to same header as dm_table_create()

Enric Balletbo i Serra (1):
  dm: move dm definitions outside the private header to boot dm targets.

Will Drewry (3):
  dm: export a table+mapped device to the ioctl interface
  init: add support to directly boot to a mapped device
  dm verity: add support for version 0 of the on-disk format

 Documentation/admin-guide/kernel-parameters.rst |   1 +
 Documentation/admin-guide/kernel-parameters.txt |   3 +
 Documentation/device-mapper/boot.txt|  42 +++
 drivers/md/dm-ioctl.c   |  39 ++
 drivers/md/dm-verity-target.c   | 279 ++
 drivers/md/dm.h |   8 -
 include/linux/device-mapper.h   |  19 +
 init/Makefile   |   1 +
 init/do_mounts.c|   1 +
 init/do_mounts.h|  10 +
 init/do_mounts_dm.c | 472 
 11 files changed, 803 insertions(+), 72 deletions(-)
 create mode 100644 Documentation/device-mapper/boot.txt
 create mode 100644 init/do_mounts_dm.c

-- 
2.9.3

--
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/5] dm: move dm_table_destroy() to same header as dm_table_create()

2017-04-11 Thread Enric Balletbo i Serra 
From: Brian Norris 

If anyone is going to use dm_table_create(), they probably should be
able to use dm_table_destroy() too. Move the dm_table_destroy()
definition outside the private header, near dm_table_create()

Signed-off-by: Brian Norris 
Signed-off-by: Enric Balletbo i Serra 
---
 drivers/md/dm.h   | 1 -
 include/linux/device-mapper.h | 5 +
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/md/dm.h b/drivers/md/dm.h
index f298b01..c54d2f1 100644
--- a/drivers/md/dm.h
+++ b/drivers/md/dm.h
@@ -48,7 +48,6 @@ struct dm_md_mempools;
 /*-
  * Internal table functions.
  *---*/
-void dm_table_destroy(struct dm_table *t);
 void dm_table_event_callback(struct dm_table *t,
 void (*fn)(void *), void *context);
 struct dm_target *dm_table_get_target(struct dm_table *t, unsigned int index);
diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h
index a7e6903..70cb6af 100644
--- a/include/linux/device-mapper.h
+++ b/include/linux/device-mapper.h
@@ -472,6 +472,11 @@ void dm_table_set_type(struct dm_table *t, unsigned type);
 int dm_table_complete(struct dm_table *t);
 
 /*
+ * Destroy the table when finished.
+ */
+void dm_table_destroy(struct dm_table *t);
+
+/*
  * Target may require that it is never sent I/O larger than len.
  */
 int __must_check dm_set_target_max_io_len(struct dm_target *ti, sector_t len);
-- 
2.9.3

--
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] docs-rst: add input docs at main index and use kernel-figure

2017-04-11 Thread Mauro Carvalho Chehab 
The input subsystem documentation got converted into ReST.

Add it to the main documentation index and use kernel-figure
for the two svg images there.

Signed-off-by: Mauro Carvalho Chehab 
---

Jon/Dmitry,

This patch contains the final bits of the input documentation
conversion. The linux-input tree has already the ReST conversion
patches, but it doesn't have the
Documentation/sphinx/load_config.py script with implements
the kernel-figure directive, as it got merged via docs tree.

So, either one of you should merge from the other tree or this
patch should be sent in separate upstream after both trees
gets merged. What do you prefer?

Thanks!
Mauro


 Documentation/index.rst| 1 +
 Documentation/input/ff.rst | 4 ++--
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/Documentation/index.rst b/Documentation/index.rst
index 61306a22888d..bc67dbf76eb0 100644
--- a/Documentation/index.rst
+++ b/Documentation/index.rst
@@ -67,6 +67,7 @@ needed).
driver-api/index
core-api/index
media/index
+   input/index
gpu/index
security/index
sound/index
diff --git a/Documentation/input/ff.rst b/Documentation/input/ff.rst
index c30f185216a0..0ea123c64dd2 100644
--- a/Documentation/input/ff.rst
+++ b/Documentation/input/ff.rst
@@ -129,11 +129,11 @@ Effects are file descriptor specific.
 See  for a description of the ff_effect struct. You should also
 find help in a few sketches, contained in files shape.svg and interactive.svg:
 
-.. figure:: shape.svg
+.. kernel-figure:: shape.svg
 
 Shape
 
-.. figure:: interactive.svg
+.. kernel-figure:: interactive.svg
 
 Interactive
 
-- 
2.9.3


--
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: [v3,1/4] input: add an EV_REL event for high-res vertical wheel

2017-04-11 Thread Mauro Carvalho Chehab 
Em Fri, 7 Apr 2017 17:10:27 +0200
Benjamin Tissoires  escreveu:

> On Apr 07 2017 or thereabouts, Mauro Carvalho Chehab wrote:
> > Em Fri, 7 Apr 2017 14:17:51 +0200
> > Benjamin Tissoires  escreveu:
> >   
> > > Hi Mauro,
> > > 
> > > On Apr 07 2017 or thereabouts, Mauro Carvalho Chehab wrote:  
> > > > As some devices can produce either low-res or high-res
> > > > vertical wheel EV_REL events, add a new event to allow
> > > > userspace to distinguish between them.
> > > > 
> > > > Signed-off-by: Mauro Carvalho Chehab 
> > > > ---
> > > >  Documentation/input/event-codes.rst| 16 +---
> > > >  include/uapi/linux/input-event-codes.h |  1 +
> > > >  2 files changed, 14 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/Documentation/input/event-codes.rst 
> > > > b/Documentation/input/event-codes.rst
> > > > index 92db50954169..0c8591d39bc6 100644
> > > > --- a/Documentation/input/event-codes.rst
> > > > +++ b/Documentation/input/event-codes.rst
> > > > @@ -185,10 +185,20 @@ instead of EV_REL codes.
> > > >  
> > > >  A few EV_REL codes have special meanings:
> > > >  
> > > > -* REL_WHEEL, REL_HWHEEL:
> > > > +* REL_WHEEL:
> > > >  
> > > > -  - These codes are used for vertical and horizontal scroll wheels,
> > > > -respectively.
> > > > +  - These codes are used for vertical scroll wheels.
> > > > +
> > > > +  - REL_WHEEL is for normal wheel operational mode, e. g. 
> > > > low-resolution
> > > > +(line-based) scroll.
> > > > +
> > > > +  - REL_HIRES_WHEEL should be used when the wheel has two resolutions 
> > > > and it
> > > > +is in high-resolution mode, e. g. the same angular movement that 
> > > > would
> > > > +produce a single REL_WHEEL will produce multiple REL_HIRES_WHEEL 
> > > > events.
> > > > +
> > > > +* REL_HWHEEL:
> > > > +
> > > > +  - This code is used for horizontal scroll wheels.
> > > >  
> > > >  EV_ABS
> > > >  --
> > > > diff --git a/include/uapi/linux/input-event-codes.h 
> > > > b/include/uapi/linux/input-event-codes.h
> > > > index 3af60ee69053..23b2d377af59 100644
> > > > --- a/include/uapi/linux/input-event-codes.h
> > > > +++ b/include/uapi/linux/input-event-codes.h
> > > > @@ -703,6 +703,7 @@
> > > >  #define REL_DIAL   0x07
> > > >  #define REL_WHEEL  0x08
> > > >  #define REL_MISC   0x09
> > > > +#define REL_HIRES_WHEEL0x0a
> > > 
> > > There is one issue here. The HID input layer has a tendency to map
> > > usages to REL_MISC +1, +2, +3, etc... When it doesn't know how to map an
> > > usage, the core layer maps it to the next one.
> > > 
> > > I am not aware of devices exposing such REL axes, but I wouldn't be
> > > surprised if the issue will not raise at some point.
> > > 
> > > We already had an issue with ABS events where ABS_MISC are conflicting
> > > with ABS_MT_SLOTS. Luckily, we have a little empty space between
> > > ABS_MISC and ABS_MT_SLOT, which allows userspace to detect such issues.
> > > 
> > > Could you give the define a bigger number (and maybe reserve a couple of
> > > REL_MISC-n) to make sure that we do not end up with joysticks exporting
> > > REL_HIRES_WHEEL?  
> > 
> > Sure. How many REL_MISC-n should be reserved?  
> 
> Not sure. As I mentioned, I haven' t seen such device myself, but maybe
> we should reserve the rest of the 0x0n range for those (0x0a-0x0f). This
> would force to bump REL_MAX, but I don't think this is an issue besides
> recompiling libevdev and others.

Ok, I'll do that on a separate patch.

Btw, you requested to rebase patches on the top of HID tree.

Well, if I rebase on the top of HID for_next branch, patches 1 and 2
will have (trivial) conflicts with input-next, due to the documentation
patches that got merged there.

I might rebase just patches 3 and 4, but, in this case, the HID
branch won't compile.

So, I guess either input should pull from HID or vice-versa, in order
to avoid such conflicts.

> 
> >   
> > > I'll try the rest of the series on the MX Master today.  
> > 
> > It would be great if you could test it!  
> 
> I found some issues, I'll report in the other patches.

Ok.

> 
> Cheers,
> Benjamin
> 
> > 
> > Regards,
> > Mauro  



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