Re: [PATCH v3 3/7] usb: mux: add common code for Intel dual role port mux

[Lu Baolu]

Hi,

On 03/11/2016 07:57 AM, Greg Kroah-Hartman wrote:
> On Thu, Mar 10, 2016 at 01:39:43PM +0100, Oliver Neukum wrote:
>> On Tue, 2016-03-08 at 15:53 +0800, Lu Baolu wrote:
>>
>>> diff --git a/Documentation/ABI/testing/sysfs-bus-platform 
>>> b/Documentation/ABI/testing/sysfs-bus-platform
>>> index 5172a61..a2261cb 100644
>>> --- a/Documentation/ABI/testing/sysfs-bus-platform
>>> +++ b/Documentation/ABI/testing/sysfs-bus-platform
>>> @@ -18,3 +18,18 @@ Description:
>>> devices to opt-out of driver binding using a driver_override
>>> name such as "none".  Only a single driver may be specified in
>>> the override, there is no support for parsing delimiters.
>>> +
>>> +What:  /sys/bus/platform/devices/.../intel_mux
>> Hi,
>>
>> is there any reason to call this "intel_mux"? We want a common interface
>> for such things. So how about "role_mux" or "master_slave_mux"?
> I agree, don't make this intel specific, as it shouldn't be.
>

By the way, do you expect a class for port mux in sysfs?

Best regards,
Baolu

Re: [PATCH v3 3/7] usb: mux: add common code for Intel dual role port mux

[Lu Baolu]

Hi,

On 03/11/2016 07:57 AM, Greg Kroah-Hartman wrote:
> On Thu, Mar 10, 2016 at 01:39:43PM +0100, Oliver Neukum wrote:
>> On Tue, 2016-03-08 at 15:53 +0800, Lu Baolu wrote:
>>
>>> diff --git a/Documentation/ABI/testing/sysfs-bus-platform 
>>> b/Documentation/ABI/testing/sysfs-bus-platform
>>> index 5172a61..a2261cb 100644
>>> --- a/Documentation/ABI/testing/sysfs-bus-platform
>>> +++ b/Documentation/ABI/testing/sysfs-bus-platform
>>> @@ -18,3 +18,18 @@ Description:
>>> devices to opt-out of driver binding using a driver_override
>>> name such as "none".  Only a single driver may be specified in
>>> the override, there is no support for parsing delimiters.
>>> +
>>> +What:  /sys/bus/platform/devices/.../intel_mux
>> Hi,
>>
>> is there any reason to call this "intel_mux"? We want a common interface
>> for such things. So how about "role_mux" or "master_slave_mux"?
> I agree, don't make this intel specific, as it shouldn't be.
>

By the way, do you expect a class for port mux in sysfs?

Best regards,
Baolu

Re: [PATCH V2 01/30] bitops: add parity functions

[Zeng Zhaoxiu]

在 2016年04月06日 03:04, Sam Ravnborg 写道:

On Tue, Apr 05, 2016 at 10:06:21AM +0800, Zeng Zhaoxiu wrote:

From: Zhaoxiu Zeng 

These patches provide generic and architecture-specific odd parity
calculations.

Hi Zeng.

Can you please fix your mail script.
I see only 1/30 (sent to linux-arch) - and patch looks mangeled (broken lines)
No mail was sent to sparclinux - but sparc was mentioned.

git send-mail usually do the trick.

Sam


When I do "git send-email", I got:
...
5.7.14 JTibJDWdGxPcfa-E9KgtF-grMQl9w> Please log in via your web browser and
5.7.14 then try again.
5.7.14  Learn more at
5.7.14  https://support.google.com/mail/answer/78754 zp5sm464879pac.9 - gsmtp
...

So I use thunderbird to send email, but the text wrap error.

Re: [PATCH V2 01/30] bitops: add parity functions

[Zeng Zhaoxiu]

在 2016年04月06日 03:04, Sam Ravnborg 写道:

On Tue, Apr 05, 2016 at 10:06:21AM +0800, Zeng Zhaoxiu wrote:

From: Zhaoxiu Zeng 

These patches provide generic and architecture-specific odd parity
calculations.

Hi Zeng.

Can you please fix your mail script.
I see only 1/30 (sent to linux-arch) - and patch looks mangeled (broken lines)
No mail was sent to sparclinux - but sparc was mentioned.

git send-mail usually do the trick.

Sam


When I do "git send-email", I got:
...
5.7.14 JTibJDWdGxPcfa-E9KgtF-grMQl9w> Please log in via your web browser and
5.7.14 then try again.
5.7.14  Learn more at
5.7.14  https://support.google.com/mail/answer/78754 zp5sm464879pac.9 - gsmtp
...

So I use thunderbird to send email, but the text wrap error.

Re: [BUG] lib: zram lz4 compression/decompression still broken on big endian

[Sergey Senozhatsky]

On (04/05/16 17:02), Rui Salvaterra wrote:
[..]
> > For some reason it never got merged, sorry, I don't remember why.
> >
> > Have you tested this patch?  If so, can you resend it with your
> > tested-by: line added to it?
> >
> > thanks,
> >
> > greg k-h
> 
> Hi, Greg
> 
> 
> No, I haven't tested the patch at all. I want to do so, and fix if if
> necessary, but I still need to learn how to (meaning, I need to watch
> your "first kernel patch" presentation again). I'd love to get
> involved in kernel development, and this seems to be a good
> opportunity, if none of the kernel gods beat me to it (I may need a
> month, but then again nobody complained about this bug in almost two
> years).

Hello Rui,

may we please ask you to test the patch first? quite possible there
is nothing to fix there; I've no access to mips h/w but the patch
seems correct to me.

LZ4_READ_LITTLEENDIAN_16 does get_unaligned_le16(), so
LZ4_WRITE_LITTLEENDIAN_16 must do put_unaligned_le16() /* not put_unaligned() */

-ss

Re: [BUG] lib: zram lz4 compression/decompression still broken on big endian

[Sergey Senozhatsky]

On (04/05/16 17:02), Rui Salvaterra wrote:
[..]
> > For some reason it never got merged, sorry, I don't remember why.
> >
> > Have you tested this patch?  If so, can you resend it with your
> > tested-by: line added to it?
> >
> > thanks,
> >
> > greg k-h
> 
> Hi, Greg
> 
> 
> No, I haven't tested the patch at all. I want to do so, and fix if if
> necessary, but I still need to learn how to (meaning, I need to watch
> your "first kernel patch" presentation again). I'd love to get
> involved in kernel development, and this seems to be a good
> opportunity, if none of the kernel gods beat me to it (I may need a
> month, but then again nobody complained about this bug in almost two
> years).

Hello Rui,

may we please ask you to test the patch first? quite possible there
is nothing to fix there; I've no access to mips h/w but the patch
seems correct to me.

LZ4_READ_LITTLEENDIAN_16 does get_unaligned_le16(), so
LZ4_WRITE_LITTLEENDIAN_16 must do put_unaligned_le16() /* not put_unaligned() */

-ss

Re: [PATCH v2] module: fix noreturn attribute for __module_put_and_exit()

[Jiri Kosina]

On Wed, 30 Mar 2016, Jiri Kosina wrote:

> > __module_put_and_exit() is makred noreturn in module.h declaration, but is
> > lacking the attribute in the definition, which makes some tools (such as
> > sparse) unhappy. Amend the definition with the attribute as well (and
> > reformat the declaration so that it uses more common format).
> > 
> > Signed-off-by: Jiri Kosina 
> > ---
> > 
> > v1 -> v2: use __noreturn instead of __attribute__((noreturn)) as requested 
> >   by Rusty
> 
> Rusty, friendly ping on this one.

Not seeing this in your tree, let me send another friendly ping :)

Rusty, if you want me to take this through trivial.git, just let me know, 
I'll happily do it.

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH v2] module: fix noreturn attribute for __module_put_and_exit()

[Jiri Kosina]

On Wed, 30 Mar 2016, Jiri Kosina wrote:

> > __module_put_and_exit() is makred noreturn in module.h declaration, but is
> > lacking the attribute in the definition, which makes some tools (such as
> > sparse) unhappy. Amend the definition with the attribute as well (and
> > reformat the declaration so that it uses more common format).
> > 
> > Signed-off-by: Jiri Kosina 
> > ---
> > 
> > v1 -> v2: use __noreturn instead of __attribute__((noreturn)) as requested 
> >   by Rusty
> 
> Rusty, friendly ping on this one.

Not seeing this in your tree, let me send another friendly ping :)

Rusty, if you want me to take this through trivial.git, just let me know, 
I'll happily do it.

Thanks,

-- 
Jiri Kosina
SUSE Labs

[PATCH 8/9] iio: health: afe4404: use regmap to retrieve struct device

[Alison Schofield]

Driver includes struct regmap and struct device in its global data.
Remove the struct device and use regmap API to retrieve device info.

Patch created using Coccinelle plus manual edits.

Signed-off-by: Alison Schofield 
---
 drivers/iio/health/afe4404.c | 38 +++---
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/iio/health/afe4404.c b/drivers/iio/health/afe4404.c
index 5096a46..9cd8590 100644
--- a/drivers/iio/health/afe4404.c
+++ b/drivers/iio/health/afe4404.c
@@ -107,14 +107,12 @@
 
 /**
  * struct afe4404_data
- * @dev - Device structure
  * @regmap - Register map of the device
  * @regulator - Pointer to the regulator for the IC
  * @trig - IIO trigger for this device
  * @irq - ADC_RDY line interrupt number
  */
 struct afe4404_data {
-   struct device *dev;
struct regmap *regmap;
struct regulator *regulator;
struct iio_trigger *trig;
@@ -534,54 +532,54 @@ static int afe4404_probe(struct i2c_client *client,
afe = iio_priv(indio_dev);
i2c_set_clientdata(client, indio_dev);
 
-   afe->dev = >dev;
afe->irq = client->irq;
 
afe->regmap = devm_regmap_init_i2c(client, _regmap_config);
if (IS_ERR(afe->regmap)) {
-   dev_err(afe->dev, "Unable to allocate register map\n");
+   dev_err(>dev, "Unable to allocate register map\n");
return PTR_ERR(afe->regmap);
}
 
-   afe->regulator = devm_regulator_get(afe->dev, "tx_sup");
+   afe->regulator = devm_regulator_get(>dev, "tx_sup");
if (IS_ERR(afe->regulator)) {
-   dev_err(afe->dev, "Unable to get regulator\n");
+   dev_err(>dev, "Unable to get regulator\n");
return PTR_ERR(afe->regulator);
}
ret = regulator_enable(afe->regulator);
if (ret) {
-   dev_err(afe->dev, "Unable to enable regulator\n");
+   dev_err(>dev, "Unable to enable regulator\n");
return ret;
}
 
ret = regmap_write(afe->regmap, AFE440X_CONTROL0,
   AFE440X_CONTROL0_SW_RESET);
if (ret) {
-   dev_err(afe->dev, "Unable to reset device\n");
+   dev_err(>dev, "Unable to reset device\n");
goto disable_reg;
}
 
ret = regmap_multi_reg_write(afe->regmap, afe4404_reg_sequences,
 ARRAY_SIZE(afe4404_reg_sequences));
if (ret) {
-   dev_err(afe->dev, "Unable to set register defaults\n");
+   dev_err(>dev, "Unable to set register defaults\n");
goto disable_reg;
}
 
indio_dev->modes = INDIO_DIRECT_MODE;
-   indio_dev->dev.parent = afe->dev;
+   indio_dev->dev.parent = >dev;
indio_dev->channels = afe4404_channels;
indio_dev->num_channels = ARRAY_SIZE(afe4404_channels);
indio_dev->name = AFE4404_DRIVER_NAME;
indio_dev->info = _iio_info;
 
if (afe->irq > 0) {
-   afe->trig = devm_iio_trigger_alloc(afe->dev,
+   afe->trig = devm_iio_trigger_alloc(>dev,
   "%s-dev%d",
   indio_dev->name,
   indio_dev->id);
if (!afe->trig) {
-   dev_err(afe->dev, "Unable to allocate IIO trigger\n");
+   dev_err(>dev,
+   "Unable to allocate IIO trigger\n");
ret = -ENOMEM;
goto disable_reg;
}
@@ -589,21 +587,22 @@ static int afe4404_probe(struct i2c_client *client,
iio_trigger_set_drvdata(afe->trig, indio_dev);
 
afe->trig->ops = _trigger_ops;
-   afe->trig->dev.parent = afe->dev;
+   afe->trig->dev.parent = >dev;
 
ret = iio_trigger_register(afe->trig);
if (ret) {
-   dev_err(afe->dev, "Unable to register IIO trigger\n");
+   dev_err(>dev,
+   "Unable to register IIO trigger\n");
goto disable_reg;
}
 
-   ret = devm_request_threaded_irq(afe->dev, afe->irq,
+   ret = devm_request_threaded_irq(>dev, afe->irq,

iio_trigger_generic_data_rdy_poll,
NULL, IRQF_ONESHOT,
AFE4404_DRIVER_NAME,
afe->trig);
if (ret) {
-   dev_err(afe->dev, "Unable to request IRQ\n");
+   dev_err(>dev, "Unable to request IRQ\n");
goto disable_reg;
}
}
@@ -611,13 +610,13 @@ static int 

[PATCH 8/9] iio: health: afe4404: use regmap to retrieve struct device

[Alison Schofield]

Driver includes struct regmap and struct device in its global data.
Remove the struct device and use regmap API to retrieve device info.

Patch created using Coccinelle plus manual edits.

Signed-off-by: Alison Schofield 
---
 drivers/iio/health/afe4404.c | 38 +++---
 1 file changed, 19 insertions(+), 19 deletions(-)

diff --git a/drivers/iio/health/afe4404.c b/drivers/iio/health/afe4404.c
index 5096a46..9cd8590 100644
--- a/drivers/iio/health/afe4404.c
+++ b/drivers/iio/health/afe4404.c
@@ -107,14 +107,12 @@
 
 /**
  * struct afe4404_data
- * @dev - Device structure
  * @regmap - Register map of the device
  * @regulator - Pointer to the regulator for the IC
  * @trig - IIO trigger for this device
  * @irq - ADC_RDY line interrupt number
  */
 struct afe4404_data {
-   struct device *dev;
struct regmap *regmap;
struct regulator *regulator;
struct iio_trigger *trig;
@@ -534,54 +532,54 @@ static int afe4404_probe(struct i2c_client *client,
afe = iio_priv(indio_dev);
i2c_set_clientdata(client, indio_dev);
 
-   afe->dev = >dev;
afe->irq = client->irq;
 
afe->regmap = devm_regmap_init_i2c(client, _regmap_config);
if (IS_ERR(afe->regmap)) {
-   dev_err(afe->dev, "Unable to allocate register map\n");
+   dev_err(>dev, "Unable to allocate register map\n");
return PTR_ERR(afe->regmap);
}
 
-   afe->regulator = devm_regulator_get(afe->dev, "tx_sup");
+   afe->regulator = devm_regulator_get(>dev, "tx_sup");
if (IS_ERR(afe->regulator)) {
-   dev_err(afe->dev, "Unable to get regulator\n");
+   dev_err(>dev, "Unable to get regulator\n");
return PTR_ERR(afe->regulator);
}
ret = regulator_enable(afe->regulator);
if (ret) {
-   dev_err(afe->dev, "Unable to enable regulator\n");
+   dev_err(>dev, "Unable to enable regulator\n");
return ret;
}
 
ret = regmap_write(afe->regmap, AFE440X_CONTROL0,
   AFE440X_CONTROL0_SW_RESET);
if (ret) {
-   dev_err(afe->dev, "Unable to reset device\n");
+   dev_err(>dev, "Unable to reset device\n");
goto disable_reg;
}
 
ret = regmap_multi_reg_write(afe->regmap, afe4404_reg_sequences,
 ARRAY_SIZE(afe4404_reg_sequences));
if (ret) {
-   dev_err(afe->dev, "Unable to set register defaults\n");
+   dev_err(>dev, "Unable to set register defaults\n");
goto disable_reg;
}
 
indio_dev->modes = INDIO_DIRECT_MODE;
-   indio_dev->dev.parent = afe->dev;
+   indio_dev->dev.parent = >dev;
indio_dev->channels = afe4404_channels;
indio_dev->num_channels = ARRAY_SIZE(afe4404_channels);
indio_dev->name = AFE4404_DRIVER_NAME;
indio_dev->info = _iio_info;
 
if (afe->irq > 0) {
-   afe->trig = devm_iio_trigger_alloc(afe->dev,
+   afe->trig = devm_iio_trigger_alloc(>dev,
   "%s-dev%d",
   indio_dev->name,
   indio_dev->id);
if (!afe->trig) {
-   dev_err(afe->dev, "Unable to allocate IIO trigger\n");
+   dev_err(>dev,
+   "Unable to allocate IIO trigger\n");
ret = -ENOMEM;
goto disable_reg;
}
@@ -589,21 +587,22 @@ static int afe4404_probe(struct i2c_client *client,
iio_trigger_set_drvdata(afe->trig, indio_dev);
 
afe->trig->ops = _trigger_ops;
-   afe->trig->dev.parent = afe->dev;
+   afe->trig->dev.parent = >dev;
 
ret = iio_trigger_register(afe->trig);
if (ret) {
-   dev_err(afe->dev, "Unable to register IIO trigger\n");
+   dev_err(>dev,
+   "Unable to register IIO trigger\n");
goto disable_reg;
}
 
-   ret = devm_request_threaded_irq(afe->dev, afe->irq,
+   ret = devm_request_threaded_irq(>dev, afe->irq,

iio_trigger_generic_data_rdy_poll,
NULL, IRQF_ONESHOT,
AFE4404_DRIVER_NAME,
afe->trig);
if (ret) {
-   dev_err(afe->dev, "Unable to request IRQ\n");
+   dev_err(>dev, "Unable to request IRQ\n");
goto disable_reg;
}
}
@@ -611,13 +610,13 @@ static int afe4404_probe(struct 

[PATCH 9/9] iio: gyro: bmg160_core: use regmap to retrieve struct device

[Alison Schofield]

Driver includes struct regmap and struct device in its global data.
Remove the struct device and use regmap API to retrieve device info.

Patch created using Coccinelle plus manual edits.

Signed-off-by: Alison Schofield 
---
 drivers/iio/gyro/bmg160_core.c | 86 +-
 1 file changed, 44 insertions(+), 42 deletions(-)

diff --git a/drivers/iio/gyro/bmg160_core.c b/drivers/iio/gyro/bmg160_core.c
index 2493bb1..b2b1071 100644
--- a/drivers/iio/gyro/bmg160_core.c
+++ b/drivers/iio/gyro/bmg160_core.c
@@ -95,7 +95,6 @@
 #define BMG160_AUTO_SUSPEND_DELAY_MS   2000
 
 struct bmg160_data {
-   struct device *dev;
struct regmap *regmap;
struct iio_trigger *dready_trig;
struct iio_trigger *motion_trig;
@@ -137,11 +136,12 @@ static const struct {
 
 static int bmg160_set_mode(struct bmg160_data *data, u8 mode)
 {
+   struct device *dev = regmap_get_device(data->regmap);
int ret;
 
ret = regmap_write(data->regmap, BMG160_REG_PMU_LPW, mode);
if (ret < 0) {
-   dev_err(data->dev, "Error writing reg_pmu_lpw\n");
+   dev_err(dev, "Error writing reg_pmu_lpw\n");
return ret;
}
 
@@ -162,6 +162,7 @@ static int bmg160_convert_freq_to_bit(int val)
 
 static int bmg160_set_bw(struct bmg160_data *data, int val)
 {
+   struct device *dev = regmap_get_device(data->regmap);
int ret;
int bw_bits;
 
@@ -171,7 +172,7 @@ static int bmg160_set_bw(struct bmg160_data *data, int val)
 
ret = regmap_write(data->regmap, BMG160_REG_PMU_BW, bw_bits);
if (ret < 0) {
-   dev_err(data->dev, "Error writing reg_pmu_bw\n");
+   dev_err(dev, "Error writing reg_pmu_bw\n");
return ret;
}
 
@@ -182,18 +183,19 @@ static int bmg160_set_bw(struct bmg160_data *data, int 
val)
 
 static int bmg160_chip_init(struct bmg160_data *data)
 {
+   struct device *dev = regmap_get_device(data->regmap);
int ret;
unsigned int val;
 
ret = regmap_read(data->regmap, BMG160_REG_CHIP_ID, );
if (ret < 0) {
-   dev_err(data->dev, "Error reading reg_chip_id\n");
+   dev_err(dev, "Error reading reg_chip_id\n");
return ret;
}
 
-   dev_dbg(data->dev, "Chip Id %x\n", val);
+   dev_dbg(dev, "Chip Id %x\n", val);
if (val != BMG160_CHIP_ID_VAL) {
-   dev_err(data->dev, "invalid chip %x\n", val);
+   dev_err(dev, "invalid chip %x\n", val);
return -ENODEV;
}
 
@@ -212,14 +214,14 @@ static int bmg160_chip_init(struct bmg160_data *data)
/* Set Default Range */
ret = regmap_write(data->regmap, BMG160_REG_RANGE, BMG160_RANGE_500DPS);
if (ret < 0) {
-   dev_err(data->dev, "Error writing reg_range\n");
+   dev_err(dev, "Error writing reg_range\n");
return ret;
}
data->dps_range = BMG160_RANGE_500DPS;
 
ret = regmap_read(data->regmap, BMG160_REG_SLOPE_THRES, );
if (ret < 0) {
-   dev_err(data->dev, "Error reading reg_slope_thres\n");
+   dev_err(dev, "Error reading reg_slope_thres\n");
return ret;
}
data->slope_thres = val;
@@ -228,7 +230,7 @@ static int bmg160_chip_init(struct bmg160_data *data)
ret = regmap_update_bits(data->regmap, BMG160_REG_INT_EN_1,
 BMG160_INT1_BIT_OD, 0);
if (ret < 0) {
-   dev_err(data->dev, "Error updating bits in reg_int_en_1\n");
+   dev_err(dev, "Error updating bits in reg_int_en_1\n");
return ret;
}
 
@@ -236,7 +238,7 @@ static int bmg160_chip_init(struct bmg160_data *data)
   BMG160_INT_MODE_LATCH_INT |
   BMG160_INT_MODE_LATCH_RESET);
if (ret < 0) {
-   dev_err(data->dev,
+   dev_err(dev,
"Error writing reg_motion_intr\n");
return ret;
}
@@ -247,20 +249,21 @@ static int bmg160_chip_init(struct bmg160_data *data)
 static int bmg160_set_power_state(struct bmg160_data *data, bool on)
 {
 #ifdef CONFIG_PM
+   struct device *dev = regmap_get_device(data->regmap);
int ret;
 
if (on)
-   ret = pm_runtime_get_sync(data->dev);
+   ret = pm_runtime_get_sync(dev);
else {
-   pm_runtime_mark_last_busy(data->dev);
-   ret = pm_runtime_put_autosuspend(data->dev);
+   pm_runtime_mark_last_busy(dev);
+   ret = pm_runtime_put_autosuspend(dev);
}
 
if (ret < 0) {
-   dev_err(data->dev,
-   "Failed: bmg160_set_power_state for %d\n", on);
+   dev_err(dev, "Failed: bmg160_set_power_state for %d\n", on);
+
if (on)
-   

Re: [RESEND][PATCH] mtd: devices: m25p80: add support for mmap read request

[Vignesh R]

Hi,

On 04/05/2016 11:44 PM, Brian Norris wrote:
> + Mark, Cyrille
> 
> On Tue, Mar 29, 2016 at 11:16:17AM +0530, Vignesh R wrote:
>> Certain SPI controllers may provide accelerated hardware interface to
>> read from m25p80 type flash devices in order to provide better read
>> performance. SPI core supports such devices with spi_flash_read() API.
>> Call spi_flash_read(), if supported, to make use of such interface.
>>
>> Signed-off-by: Vignesh R 
>> ---
> 
> Applied, with a small diff.
> 
>> Resend v5:
>> Rebased on top of v4.6-rc1
>> v5: http://www.spinics.net/lists/devicetree/msg106696.html
>>
>>  drivers/mtd/devices/m25p80.c | 20 
>>  1 file changed, 20 insertions(+)
>>
>> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
>> index c9c3b7fa3051..7730e633d7d3 100644
>> --- a/drivers/mtd/devices/m25p80.c
>> +++ b/drivers/mtd/devices/m25p80.c
>> @@ -131,6 +131,26 @@ static int m25p80_read(struct spi_nor *nor, loff_t 
>> from, size_t len,
>>  /* convert the dummy cycles to the number of bytes */
>>  dummy /= 8;
>>  
>> +if (spi_flash_read_supported(spi)) {
>> +struct spi_flash_read_message msg;
>> +int ret;
>> +
> 
> I added a memset(, 0, sizeof(msg)), since spi_flash_read() doesn't
> guarantee msg.retlen is zeroed for failures. 

Thanks!

> Do we want a
> spi_flash_read_message_init() function, to mirror spi_message_init()?
> 

Not sure, there is nothing much to initialize (apart from memset msg to
zero), all fields are expected to explicitly populated by MTD flash driver.

>> +msg.buf = buf;
>> +msg.from = from;
>> +msg.len = len;
>> +msg.read_opcode = nor->read_opcode;
>> +msg.addr_width = nor->addr_width;
>> +msg.dummy_bytes = dummy;
>> +/* TODO: Support other combinations */
> 
> Speaking of "other combinations": does the TI QSPI controller support
> MMAP'ed read modes other than 1/1/{1,2,4}? It doesn't seem to implement
> support, and the SPI core doesn't handle this. So if we merge any of
> Cyrille's work on other modes, then this is going to break quickly.
> 

No, TI QSPI only supports 1/1/{1,2,4} mode in MMAP'ed mode or in normal
SPI mode. This is specified in DT as:
spi-tx-bus-width = <1>;
inside m25p80 slave node. This indicates that cmd,addr are always on D0
line only.
AFAIK, Cyrille's series starts using 4-4-4/2-2-2/ etc only if the flash
 was  initially configured to be in that mode by bootloader/ROM code. If
flash's bit to enter 4-4-4 is not set, then there will be no change and
m25p80 continues to use 1-1-4 format for QUAD read. Therefore I don't
think those patches will break TI QSPI. I will try and test that series
on top of this patch sometime soon.

-- 
Regards
Vignesh

[PATCH 9/9] iio: gyro: bmg160_core: use regmap to retrieve struct device

[Alison Schofield]

Driver includes struct regmap and struct device in its global data.
Remove the struct device and use regmap API to retrieve device info.

Patch created using Coccinelle plus manual edits.

Signed-off-by: Alison Schofield 
---
 drivers/iio/gyro/bmg160_core.c | 86 +-
 1 file changed, 44 insertions(+), 42 deletions(-)

diff --git a/drivers/iio/gyro/bmg160_core.c b/drivers/iio/gyro/bmg160_core.c
index 2493bb1..b2b1071 100644
--- a/drivers/iio/gyro/bmg160_core.c
+++ b/drivers/iio/gyro/bmg160_core.c
@@ -95,7 +95,6 @@
 #define BMG160_AUTO_SUSPEND_DELAY_MS   2000
 
 struct bmg160_data {
-   struct device *dev;
struct regmap *regmap;
struct iio_trigger *dready_trig;
struct iio_trigger *motion_trig;
@@ -137,11 +136,12 @@ static const struct {
 
 static int bmg160_set_mode(struct bmg160_data *data, u8 mode)
 {
+   struct device *dev = regmap_get_device(data->regmap);
int ret;
 
ret = regmap_write(data->regmap, BMG160_REG_PMU_LPW, mode);
if (ret < 0) {
-   dev_err(data->dev, "Error writing reg_pmu_lpw\n");
+   dev_err(dev, "Error writing reg_pmu_lpw\n");
return ret;
}
 
@@ -162,6 +162,7 @@ static int bmg160_convert_freq_to_bit(int val)
 
 static int bmg160_set_bw(struct bmg160_data *data, int val)
 {
+   struct device *dev = regmap_get_device(data->regmap);
int ret;
int bw_bits;
 
@@ -171,7 +172,7 @@ static int bmg160_set_bw(struct bmg160_data *data, int val)
 
ret = regmap_write(data->regmap, BMG160_REG_PMU_BW, bw_bits);
if (ret < 0) {
-   dev_err(data->dev, "Error writing reg_pmu_bw\n");
+   dev_err(dev, "Error writing reg_pmu_bw\n");
return ret;
}
 
@@ -182,18 +183,19 @@ static int bmg160_set_bw(struct bmg160_data *data, int 
val)
 
 static int bmg160_chip_init(struct bmg160_data *data)
 {
+   struct device *dev = regmap_get_device(data->regmap);
int ret;
unsigned int val;
 
ret = regmap_read(data->regmap, BMG160_REG_CHIP_ID, );
if (ret < 0) {
-   dev_err(data->dev, "Error reading reg_chip_id\n");
+   dev_err(dev, "Error reading reg_chip_id\n");
return ret;
}
 
-   dev_dbg(data->dev, "Chip Id %x\n", val);
+   dev_dbg(dev, "Chip Id %x\n", val);
if (val != BMG160_CHIP_ID_VAL) {
-   dev_err(data->dev, "invalid chip %x\n", val);
+   dev_err(dev, "invalid chip %x\n", val);
return -ENODEV;
}
 
@@ -212,14 +214,14 @@ static int bmg160_chip_init(struct bmg160_data *data)
/* Set Default Range */
ret = regmap_write(data->regmap, BMG160_REG_RANGE, BMG160_RANGE_500DPS);
if (ret < 0) {
-   dev_err(data->dev, "Error writing reg_range\n");
+   dev_err(dev, "Error writing reg_range\n");
return ret;
}
data->dps_range = BMG160_RANGE_500DPS;
 
ret = regmap_read(data->regmap, BMG160_REG_SLOPE_THRES, );
if (ret < 0) {
-   dev_err(data->dev, "Error reading reg_slope_thres\n");
+   dev_err(dev, "Error reading reg_slope_thres\n");
return ret;
}
data->slope_thres = val;
@@ -228,7 +230,7 @@ static int bmg160_chip_init(struct bmg160_data *data)
ret = regmap_update_bits(data->regmap, BMG160_REG_INT_EN_1,
 BMG160_INT1_BIT_OD, 0);
if (ret < 0) {
-   dev_err(data->dev, "Error updating bits in reg_int_en_1\n");
+   dev_err(dev, "Error updating bits in reg_int_en_1\n");
return ret;
}
 
@@ -236,7 +238,7 @@ static int bmg160_chip_init(struct bmg160_data *data)
   BMG160_INT_MODE_LATCH_INT |
   BMG160_INT_MODE_LATCH_RESET);
if (ret < 0) {
-   dev_err(data->dev,
+   dev_err(dev,
"Error writing reg_motion_intr\n");
return ret;
}
@@ -247,20 +249,21 @@ static int bmg160_chip_init(struct bmg160_data *data)
 static int bmg160_set_power_state(struct bmg160_data *data, bool on)
 {
 #ifdef CONFIG_PM
+   struct device *dev = regmap_get_device(data->regmap);
int ret;
 
if (on)
-   ret = pm_runtime_get_sync(data->dev);
+   ret = pm_runtime_get_sync(dev);
else {
-   pm_runtime_mark_last_busy(data->dev);
-   ret = pm_runtime_put_autosuspend(data->dev);
+   pm_runtime_mark_last_busy(dev);
+   ret = pm_runtime_put_autosuspend(dev);
}
 
if (ret < 0) {
-   dev_err(data->dev,
-   "Failed: bmg160_set_power_state for %d\n", on);
+   dev_err(dev, "Failed: bmg160_set_power_state for %d\n", on);
+
if (on)
-   pm_runtime_put_noidle(data->dev);
+ 

Re: [RESEND][PATCH] mtd: devices: m25p80: add support for mmap read request

[Vignesh R]

Hi,

On 04/05/2016 11:44 PM, Brian Norris wrote:
> + Mark, Cyrille
> 
> On Tue, Mar 29, 2016 at 11:16:17AM +0530, Vignesh R wrote:
>> Certain SPI controllers may provide accelerated hardware interface to
>> read from m25p80 type flash devices in order to provide better read
>> performance. SPI core supports such devices with spi_flash_read() API.
>> Call spi_flash_read(), if supported, to make use of such interface.
>>
>> Signed-off-by: Vignesh R 
>> ---
> 
> Applied, with a small diff.
> 
>> Resend v5:
>> Rebased on top of v4.6-rc1
>> v5: http://www.spinics.net/lists/devicetree/msg106696.html
>>
>>  drivers/mtd/devices/m25p80.c | 20 
>>  1 file changed, 20 insertions(+)
>>
>> diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c
>> index c9c3b7fa3051..7730e633d7d3 100644
>> --- a/drivers/mtd/devices/m25p80.c
>> +++ b/drivers/mtd/devices/m25p80.c
>> @@ -131,6 +131,26 @@ static int m25p80_read(struct spi_nor *nor, loff_t 
>> from, size_t len,
>>  /* convert the dummy cycles to the number of bytes */
>>  dummy /= 8;
>>  
>> +if (spi_flash_read_supported(spi)) {
>> +struct spi_flash_read_message msg;
>> +int ret;
>> +
> 
> I added a memset(, 0, sizeof(msg)), since spi_flash_read() doesn't
> guarantee msg.retlen is zeroed for failures. 

Thanks!

> Do we want a
> spi_flash_read_message_init() function, to mirror spi_message_init()?
> 

Not sure, there is nothing much to initialize (apart from memset msg to
zero), all fields are expected to explicitly populated by MTD flash driver.

>> +msg.buf = buf;
>> +msg.from = from;
>> +msg.len = len;
>> +msg.read_opcode = nor->read_opcode;
>> +msg.addr_width = nor->addr_width;
>> +msg.dummy_bytes = dummy;
>> +/* TODO: Support other combinations */
> 
> Speaking of "other combinations": does the TI QSPI controller support
> MMAP'ed read modes other than 1/1/{1,2,4}? It doesn't seem to implement
> support, and the SPI core doesn't handle this. So if we merge any of
> Cyrille's work on other modes, then this is going to break quickly.
> 

No, TI QSPI only supports 1/1/{1,2,4} mode in MMAP'ed mode or in normal
SPI mode. This is specified in DT as:
spi-tx-bus-width = <1>;
inside m25p80 slave node. This indicates that cmd,addr are always on D0
line only.
AFAIK, Cyrille's series starts using 4-4-4/2-2-2/ etc only if the flash
 was  initially configured to be in that mode by bootloader/ROM code. If
flash's bit to enter 4-4-4 is not set, then there will be no change and
m25p80 continues to use 1-1-4 format for QUAD read. Therefore I don't
think those patches will break TI QSPI. I will try and test that series
on top of this patch sometime soon.

-- 
Regards
Vignesh

[PATCH 7/9] iio: health: afe4403: use regmap to retrieve struct device

[Alison Schofield]

Driver includes struct regmap and struct device in its global data.
Remove the struct device and use regmap API to retrieve device info.

Patch created using Coccinelle plus manual edits.

Signed-off-by: Alison Schofield 
---
 drivers/iio/health/afe4403.c | 36 +---
 1 file changed, 17 insertions(+), 19 deletions(-)

diff --git a/drivers/iio/health/afe4403.c b/drivers/iio/health/afe4403.c
index 88e43f8..71b8f70 100644
--- a/drivers/iio/health/afe4403.c
+++ b/drivers/iio/health/afe4403.c
@@ -104,7 +104,6 @@
 
 /**
  * struct afe4403_data
- * @dev - Device structure
  * @spi - SPI device handle
  * @regmap - Register map of the device
  * @regulator - Pointer to the regulator for the IC
@@ -112,7 +111,6 @@
  * @irq - ADC_RDY line interrupt number
  */
 struct afe4403_data {
-   struct device *dev;
struct spi_device *spi;
struct regmap *regmap;
struct regulator *regulator;
@@ -562,55 +560,54 @@ static int afe4403_probe(struct spi_device *spi)
afe = iio_priv(indio_dev);
spi_set_drvdata(spi, indio_dev);
 
-   afe->dev = >dev;
afe->spi = spi;
afe->irq = spi->irq;
 
afe->regmap = devm_regmap_init_spi(spi, _regmap_config);
if (IS_ERR(afe->regmap)) {
-   dev_err(afe->dev, "Unable to allocate register map\n");
+   dev_err(>dev, "Unable to allocate register map\n");
return PTR_ERR(afe->regmap);
}
 
-   afe->regulator = devm_regulator_get(afe->dev, "tx_sup");
+   afe->regulator = devm_regulator_get(>dev, "tx_sup");
if (IS_ERR(afe->regulator)) {
-   dev_err(afe->dev, "Unable to get regulator\n");
+   dev_err(>dev, "Unable to get regulator\n");
return PTR_ERR(afe->regulator);
}
ret = regulator_enable(afe->regulator);
if (ret) {
-   dev_err(afe->dev, "Unable to enable regulator\n");
+   dev_err(>dev, "Unable to enable regulator\n");
return ret;
}
 
ret = regmap_write(afe->regmap, AFE440X_CONTROL0,
   AFE440X_CONTROL0_SW_RESET);
if (ret) {
-   dev_err(afe->dev, "Unable to reset device\n");
+   dev_err(>dev, "Unable to reset device\n");
goto err_disable_reg;
}
 
ret = regmap_multi_reg_write(afe->regmap, afe4403_reg_sequences,
 ARRAY_SIZE(afe4403_reg_sequences));
if (ret) {
-   dev_err(afe->dev, "Unable to set register defaults\n");
+   dev_err(>dev, "Unable to set register defaults\n");
goto err_disable_reg;
}
 
indio_dev->modes = INDIO_DIRECT_MODE;
-   indio_dev->dev.parent = afe->dev;
+   indio_dev->dev.parent = >dev;
indio_dev->channels = afe4403_channels;
indio_dev->num_channels = ARRAY_SIZE(afe4403_channels);
indio_dev->name = AFE4403_DRIVER_NAME;
indio_dev->info = _iio_info;
 
if (afe->irq > 0) {
-   afe->trig = devm_iio_trigger_alloc(afe->dev,
+   afe->trig = devm_iio_trigger_alloc(>dev,
   "%s-dev%d",
   indio_dev->name,
   indio_dev->id);
if (!afe->trig) {
-   dev_err(afe->dev, "Unable to allocate IIO trigger\n");
+   dev_err(>dev, "Unable to allocate IIO trigger\n");
ret = -ENOMEM;
goto err_disable_reg;
}
@@ -618,21 +615,21 @@ static int afe4403_probe(struct spi_device *spi)
iio_trigger_set_drvdata(afe->trig, indio_dev);
 
afe->trig->ops = _trigger_ops;
-   afe->trig->dev.parent = afe->dev;
+   afe->trig->dev.parent = >dev;
 
ret = iio_trigger_register(afe->trig);
if (ret) {
-   dev_err(afe->dev, "Unable to register IIO trigger\n");
+   dev_err(>dev, "Unable to register IIO trigger\n");
goto err_disable_reg;
}
 
-   ret = devm_request_threaded_irq(afe->dev, afe->irq,
+   ret = devm_request_threaded_irq(>dev, afe->irq,

iio_trigger_generic_data_rdy_poll,
NULL, IRQF_ONESHOT,
AFE4403_DRIVER_NAME,
afe->trig);
if (ret) {
-   dev_err(afe->dev, "Unable to request IRQ\n");
+   dev_err(>dev, "Unable to request IRQ\n");
goto err_trig;
}
}
@@ -640,13 +637,13 @@ static int afe4403_probe(struct spi_device *spi)

[PATCH 7/9] iio: health: afe4403: use regmap to retrieve struct device

[Alison Schofield]

Driver includes struct regmap and struct device in its global data.
Remove the struct device and use regmap API to retrieve device info.

Patch created using Coccinelle plus manual edits.

Signed-off-by: Alison Schofield 
---
 drivers/iio/health/afe4403.c | 36 +---
 1 file changed, 17 insertions(+), 19 deletions(-)

diff --git a/drivers/iio/health/afe4403.c b/drivers/iio/health/afe4403.c
index 88e43f8..71b8f70 100644
--- a/drivers/iio/health/afe4403.c
+++ b/drivers/iio/health/afe4403.c
@@ -104,7 +104,6 @@
 
 /**
  * struct afe4403_data
- * @dev - Device structure
  * @spi - SPI device handle
  * @regmap - Register map of the device
  * @regulator - Pointer to the regulator for the IC
@@ -112,7 +111,6 @@
  * @irq - ADC_RDY line interrupt number
  */
 struct afe4403_data {
-   struct device *dev;
struct spi_device *spi;
struct regmap *regmap;
struct regulator *regulator;
@@ -562,55 +560,54 @@ static int afe4403_probe(struct spi_device *spi)
afe = iio_priv(indio_dev);
spi_set_drvdata(spi, indio_dev);
 
-   afe->dev = >dev;
afe->spi = spi;
afe->irq = spi->irq;
 
afe->regmap = devm_regmap_init_spi(spi, _regmap_config);
if (IS_ERR(afe->regmap)) {
-   dev_err(afe->dev, "Unable to allocate register map\n");
+   dev_err(>dev, "Unable to allocate register map\n");
return PTR_ERR(afe->regmap);
}
 
-   afe->regulator = devm_regulator_get(afe->dev, "tx_sup");
+   afe->regulator = devm_regulator_get(>dev, "tx_sup");
if (IS_ERR(afe->regulator)) {
-   dev_err(afe->dev, "Unable to get regulator\n");
+   dev_err(>dev, "Unable to get regulator\n");
return PTR_ERR(afe->regulator);
}
ret = regulator_enable(afe->regulator);
if (ret) {
-   dev_err(afe->dev, "Unable to enable regulator\n");
+   dev_err(>dev, "Unable to enable regulator\n");
return ret;
}
 
ret = regmap_write(afe->regmap, AFE440X_CONTROL0,
   AFE440X_CONTROL0_SW_RESET);
if (ret) {
-   dev_err(afe->dev, "Unable to reset device\n");
+   dev_err(>dev, "Unable to reset device\n");
goto err_disable_reg;
}
 
ret = regmap_multi_reg_write(afe->regmap, afe4403_reg_sequences,
 ARRAY_SIZE(afe4403_reg_sequences));
if (ret) {
-   dev_err(afe->dev, "Unable to set register defaults\n");
+   dev_err(>dev, "Unable to set register defaults\n");
goto err_disable_reg;
}
 
indio_dev->modes = INDIO_DIRECT_MODE;
-   indio_dev->dev.parent = afe->dev;
+   indio_dev->dev.parent = >dev;
indio_dev->channels = afe4403_channels;
indio_dev->num_channels = ARRAY_SIZE(afe4403_channels);
indio_dev->name = AFE4403_DRIVER_NAME;
indio_dev->info = _iio_info;
 
if (afe->irq > 0) {
-   afe->trig = devm_iio_trigger_alloc(afe->dev,
+   afe->trig = devm_iio_trigger_alloc(>dev,
   "%s-dev%d",
   indio_dev->name,
   indio_dev->id);
if (!afe->trig) {
-   dev_err(afe->dev, "Unable to allocate IIO trigger\n");
+   dev_err(>dev, "Unable to allocate IIO trigger\n");
ret = -ENOMEM;
goto err_disable_reg;
}
@@ -618,21 +615,21 @@ static int afe4403_probe(struct spi_device *spi)
iio_trigger_set_drvdata(afe->trig, indio_dev);
 
afe->trig->ops = _trigger_ops;
-   afe->trig->dev.parent = afe->dev;
+   afe->trig->dev.parent = >dev;
 
ret = iio_trigger_register(afe->trig);
if (ret) {
-   dev_err(afe->dev, "Unable to register IIO trigger\n");
+   dev_err(>dev, "Unable to register IIO trigger\n");
goto err_disable_reg;
}
 
-   ret = devm_request_threaded_irq(afe->dev, afe->irq,
+   ret = devm_request_threaded_irq(>dev, afe->irq,

iio_trigger_generic_data_rdy_poll,
NULL, IRQF_ONESHOT,
AFE4403_DRIVER_NAME,
afe->trig);
if (ret) {
-   dev_err(afe->dev, "Unable to request IRQ\n");
+   dev_err(>dev, "Unable to request IRQ\n");
goto err_trig;
}
}
@@ -640,13 +637,13 @@ static int afe4403_probe(struct spi_device *spi)
ret = 

[PATCH 5/9] iio: accel: mma7455: use regmap to retrieve struct device

[Alison Schofield]

Driver includes struct regmap and struct device in its global data.
Remove the struct device and use regmap API to retrieve device info.

Patch created using Coccinelle plus manual edits.

Signed-off-by: Alison Schofield 
---
 drivers/iio/accel/mma7455_core.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/iio/accel/mma7455_core.c b/drivers/iio/accel/mma7455_core.c
index c633cc2..c902f54 100644
--- a/drivers/iio/accel/mma7455_core.c
+++ b/drivers/iio/accel/mma7455_core.c
@@ -55,11 +55,11 @@
 
 struct mma7455_data {
struct regmap *regmap;
-   struct device *dev;
 };
 
 static int mma7455_drdy(struct mma7455_data *mma7455)
 {
+   struct device *dev = regmap_get_device(mma7455->regmap);
unsigned int reg;
int tries = 3;
int ret;
@@ -75,7 +75,7 @@ static int mma7455_drdy(struct mma7455_data *mma7455)
msleep(20);
}
 
-   dev_warn(mma7455->dev, "data not ready\n");
+   dev_warn(dev, "data not ready\n");
 
return -EIO;
 }
@@ -260,7 +260,6 @@ int mma7455_core_probe(struct device *dev, struct regmap 
*regmap,
dev_set_drvdata(dev, indio_dev);
mma7455 = iio_priv(indio_dev);
mma7455->regmap = regmap;
-   mma7455->dev = dev;
 
indio_dev->info = _info;
indio_dev->name = name;
-- 
2.1.4

[PATCH 6/9] iio: accel: mxc4005: use regmap to retrieve struct device

[Alison Schofield]

Driver includes struct regmap and struct device in its global data.
Remove the struct device and use regmap API to retrieve device info.

Patch created using Coccinelle plus manual edits.

Signed-off-by: Alison Schofield 
---
 drivers/iio/accel/mxc4005.c | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/iio/accel/mxc4005.c b/drivers/iio/accel/mxc4005.c
index c23f47a..013d511 100644
--- a/drivers/iio/accel/mxc4005.c
+++ b/drivers/iio/accel/mxc4005.c
@@ -60,7 +60,6 @@ enum mxc4005_range {
 };
 
 struct mxc4005_data {
-   struct device *dev;
struct mutex mutex;
struct regmap *regmap;
struct iio_trigger *dready_trig;
@@ -140,12 +139,13 @@ static const struct regmap_config mxc4005_regmap_config = 
{
 
 static int mxc4005_read_xyz(struct mxc4005_data *data)
 {
+   struct device *dev = regmap_get_device(data->regmap);
int ret;
 
ret = regmap_bulk_read(data->regmap, MXC4005_REG_XOUT_UPPER,
   (u8 *) data->buffer, sizeof(data->buffer));
if (ret < 0) {
-   dev_err(data->dev, "failed to read axes\n");
+   dev_err(dev, "failed to read axes\n");
return ret;
}
 
@@ -155,12 +155,13 @@ static int mxc4005_read_xyz(struct mxc4005_data *data)
 static int mxc4005_read_axis(struct mxc4005_data *data,
 unsigned int addr)
 {
+   struct device *dev = regmap_get_device(data->regmap);
__be16 reg;
int ret;
 
ret = regmap_bulk_read(data->regmap, addr, (u8 *) , sizeof(reg));
if (ret < 0) {
-   dev_err(data->dev, "failed to read reg %02x\n", addr);
+   dev_err(dev, "failed to read reg %02x\n", addr);
return ret;
}
 
@@ -169,13 +170,14 @@ static int mxc4005_read_axis(struct mxc4005_data *data,
 
 static int mxc4005_read_scale(struct mxc4005_data *data)
 {
+   struct device *dev = regmap_get_device(data->regmap);
unsigned int reg;
int ret;
int i;
 
ret = regmap_read(data->regmap, MXC4005_REG_CONTROL, );
if (ret < 0) {
-   dev_err(data->dev, "failed to read reg_control\n");
+   dev_err(dev, "failed to read reg_control\n");
return ret;
}
 
@@ -189,6 +191,7 @@ static int mxc4005_read_scale(struct mxc4005_data *data)
 
 static int mxc4005_set_scale(struct mxc4005_data *data, int val)
 {
+   struct device *dev = regmap_get_device(data->regmap);
unsigned int reg;
int i;
int ret;
@@ -201,8 +204,7 @@ static int mxc4005_set_scale(struct mxc4005_data *data, int 
val)
 MXC4005_REG_CONTROL_MASK_FSR,
 reg);
if (ret < 0)
-   dev_err(data->dev,
-   "failed to write reg_control\n");
+   dev_err(dev, "failed to write reg_control\n");
return ret;
}
}
@@ -321,13 +323,14 @@ err:
 
 static int mxc4005_clr_intr(struct mxc4005_data *data)
 {
+   struct device *dev = regmap_get_device(data->regmap);
int ret;
 
/* clear interrupt */
ret = regmap_write(data->regmap, MXC4005_REG_INT_CLR1,
   MXC4005_REG_INT_CLR1_BIT_DRDYC);
if (ret < 0) {
-   dev_err(data->dev, "failed to write to reg_int_clr1\n");
+   dev_err(dev, "failed to write to reg_int_clr1\n");
return ret;
}
 
@@ -339,6 +342,7 @@ static int mxc4005_set_trigger_state(struct iio_trigger 
*trig,
 {
struct iio_dev *indio_dev = iio_trigger_get_drvdata(trig);
struct mxc4005_data *data = iio_priv(indio_dev);
+   struct device *dev = regmap_get_device(data->regmap);
int ret;
 
mutex_lock(>mutex);
@@ -352,7 +356,7 @@ static int mxc4005_set_trigger_state(struct iio_trigger 
*trig,
 
if (ret < 0) {
mutex_unlock(>mutex);
-   dev_err(data->dev, "failed to update reg_int_mask1");
+   dev_err(dev, "failed to update reg_int_mask1");
return ret;
}
 
@@ -381,16 +385,17 @@ static const struct iio_trigger_ops mxc4005_trigger_ops = 
{
 
 static int mxc4005_chip_init(struct mxc4005_data *data)
 {
+   struct device *dev = regmap_get_device(data->regmap);
int ret;
unsigned int reg;
 
ret = regmap_read(data->regmap, MXC4005_REG_DEVICE_ID, );
if (ret < 0) {
-   dev_err(data->dev, "failed to read chip id\n");
+   dev_err(dev, "failed to read chip id\n");
return ret;
}
 
-   dev_dbg(data->dev, "MXC4005 chip id %02x\n", reg);
+   dev_dbg(dev, "MXC4005 chip id %02x\n", reg);
 
return 0;
 }
@@ -415,7 +420,6 @@ static int 

[PATCH 5/9] iio: accel: mma7455: use regmap to retrieve struct device

[Alison Schofield]

Driver includes struct regmap and struct device in its global data.
Remove the struct device and use regmap API to retrieve device info.

Patch created using Coccinelle plus manual edits.

Signed-off-by: Alison Schofield 
---
 drivers/iio/accel/mma7455_core.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/iio/accel/mma7455_core.c b/drivers/iio/accel/mma7455_core.c
index c633cc2..c902f54 100644
--- a/drivers/iio/accel/mma7455_core.c
+++ b/drivers/iio/accel/mma7455_core.c
@@ -55,11 +55,11 @@
 
 struct mma7455_data {
struct regmap *regmap;
-   struct device *dev;
 };
 
 static int mma7455_drdy(struct mma7455_data *mma7455)
 {
+   struct device *dev = regmap_get_device(mma7455->regmap);
unsigned int reg;
int tries = 3;
int ret;
@@ -75,7 +75,7 @@ static int mma7455_drdy(struct mma7455_data *mma7455)
msleep(20);
}
 
-   dev_warn(mma7455->dev, "data not ready\n");
+   dev_warn(dev, "data not ready\n");
 
return -EIO;
 }
@@ -260,7 +260,6 @@ int mma7455_core_probe(struct device *dev, struct regmap 
*regmap,
dev_set_drvdata(dev, indio_dev);
mma7455 = iio_priv(indio_dev);
mma7455->regmap = regmap;
-   mma7455->dev = dev;
 
indio_dev->info = _info;
indio_dev->name = name;
-- 
2.1.4

[PATCH 6/9] iio: accel: mxc4005: use regmap to retrieve struct device

[Alison Schofield]

Driver includes struct regmap and struct device in its global data.
Remove the struct device and use regmap API to retrieve device info.

Patch created using Coccinelle plus manual edits.

Signed-off-by: Alison Schofield 
---
 drivers/iio/accel/mxc4005.c | 26 +++---
 1 file changed, 15 insertions(+), 11 deletions(-)

diff --git a/drivers/iio/accel/mxc4005.c b/drivers/iio/accel/mxc4005.c
index c23f47a..013d511 100644
--- a/drivers/iio/accel/mxc4005.c
+++ b/drivers/iio/accel/mxc4005.c
@@ -60,7 +60,6 @@ enum mxc4005_range {
 };
 
 struct mxc4005_data {
-   struct device *dev;
struct mutex mutex;
struct regmap *regmap;
struct iio_trigger *dready_trig;
@@ -140,12 +139,13 @@ static const struct regmap_config mxc4005_regmap_config = 
{
 
 static int mxc4005_read_xyz(struct mxc4005_data *data)
 {
+   struct device *dev = regmap_get_device(data->regmap);
int ret;
 
ret = regmap_bulk_read(data->regmap, MXC4005_REG_XOUT_UPPER,
   (u8 *) data->buffer, sizeof(data->buffer));
if (ret < 0) {
-   dev_err(data->dev, "failed to read axes\n");
+   dev_err(dev, "failed to read axes\n");
return ret;
}
 
@@ -155,12 +155,13 @@ static int mxc4005_read_xyz(struct mxc4005_data *data)
 static int mxc4005_read_axis(struct mxc4005_data *data,
 unsigned int addr)
 {
+   struct device *dev = regmap_get_device(data->regmap);
__be16 reg;
int ret;
 
ret = regmap_bulk_read(data->regmap, addr, (u8 *) , sizeof(reg));
if (ret < 0) {
-   dev_err(data->dev, "failed to read reg %02x\n", addr);
+   dev_err(dev, "failed to read reg %02x\n", addr);
return ret;
}
 
@@ -169,13 +170,14 @@ static int mxc4005_read_axis(struct mxc4005_data *data,
 
 static int mxc4005_read_scale(struct mxc4005_data *data)
 {
+   struct device *dev = regmap_get_device(data->regmap);
unsigned int reg;
int ret;
int i;
 
ret = regmap_read(data->regmap, MXC4005_REG_CONTROL, );
if (ret < 0) {
-   dev_err(data->dev, "failed to read reg_control\n");
+   dev_err(dev, "failed to read reg_control\n");
return ret;
}
 
@@ -189,6 +191,7 @@ static int mxc4005_read_scale(struct mxc4005_data *data)
 
 static int mxc4005_set_scale(struct mxc4005_data *data, int val)
 {
+   struct device *dev = regmap_get_device(data->regmap);
unsigned int reg;
int i;
int ret;
@@ -201,8 +204,7 @@ static int mxc4005_set_scale(struct mxc4005_data *data, int 
val)
 MXC4005_REG_CONTROL_MASK_FSR,
 reg);
if (ret < 0)
-   dev_err(data->dev,
-   "failed to write reg_control\n");
+   dev_err(dev, "failed to write reg_control\n");
return ret;
}
}
@@ -321,13 +323,14 @@ err:
 
 static int mxc4005_clr_intr(struct mxc4005_data *data)
 {
+   struct device *dev = regmap_get_device(data->regmap);
int ret;
 
/* clear interrupt */
ret = regmap_write(data->regmap, MXC4005_REG_INT_CLR1,
   MXC4005_REG_INT_CLR1_BIT_DRDYC);
if (ret < 0) {
-   dev_err(data->dev, "failed to write to reg_int_clr1\n");
+   dev_err(dev, "failed to write to reg_int_clr1\n");
return ret;
}
 
@@ -339,6 +342,7 @@ static int mxc4005_set_trigger_state(struct iio_trigger 
*trig,
 {
struct iio_dev *indio_dev = iio_trigger_get_drvdata(trig);
struct mxc4005_data *data = iio_priv(indio_dev);
+   struct device *dev = regmap_get_device(data->regmap);
int ret;
 
mutex_lock(>mutex);
@@ -352,7 +356,7 @@ static int mxc4005_set_trigger_state(struct iio_trigger 
*trig,
 
if (ret < 0) {
mutex_unlock(>mutex);
-   dev_err(data->dev, "failed to update reg_int_mask1");
+   dev_err(dev, "failed to update reg_int_mask1");
return ret;
}
 
@@ -381,16 +385,17 @@ static const struct iio_trigger_ops mxc4005_trigger_ops = 
{
 
 static int mxc4005_chip_init(struct mxc4005_data *data)
 {
+   struct device *dev = regmap_get_device(data->regmap);
int ret;
unsigned int reg;
 
ret = regmap_read(data->regmap, MXC4005_REG_DEVICE_ID, );
if (ret < 0) {
-   dev_err(data->dev, "failed to read chip id\n");
+   dev_err(dev, "failed to read chip id\n");
return ret;
}
 
-   dev_dbg(data->dev, "MXC4005 chip id %02x\n", reg);
+   dev_dbg(dev, "MXC4005 chip id %02x\n", reg);
 
return 0;
 }
@@ -415,7 +420,6 @@ static int mxc4005_probe(struct i2c_client 

[PATCH 3/9] iio: adc: qcom-spmi-vadc: use regmap to retrieve struct device

[Alison Schofield]

Driver includes struct regmap and struct device in its global data.
Remove the struct device and use regmap API to retrieve device info.

Patch created using Coccinelle plus manual edits.

Signed-off-by: Alison Schofield 
---
 drivers/iio/adc/qcom-spmi-vadc.c | 37 -
 1 file changed, 20 insertions(+), 17 deletions(-)

diff --git a/drivers/iio/adc/qcom-spmi-vadc.c b/drivers/iio/adc/qcom-spmi-vadc.c
index c2babe5..9e7aeca 100644
--- a/drivers/iio/adc/qcom-spmi-vadc.c
+++ b/drivers/iio/adc/qcom-spmi-vadc.c
@@ -161,7 +161,6 @@ struct vadc_channel_prop {
 /**
  * struct vadc_priv - VADC private structure.
  * @regmap: pointer to struct regmap.
- * @dev: pointer to struct device.
  * @base: base address for the ADC peripheral.
  * @nchannels: number of VADC channels.
  * @chan_props: array of VADC channel properties.
@@ -174,7 +173,6 @@ struct vadc_channel_prop {
  */
 struct vadc_priv {
struct regmap*regmap;
-   struct device*dev;
u16  base;
unsigned int nchannels;
struct vadc_channel_prop *chan_props;
@@ -236,6 +234,7 @@ static int vadc_set_state(struct vadc_priv *vadc, bool 
state)
 
 static void vadc_show_status(struct vadc_priv *vadc)
 {
+   struct device *dev = regmap_get_device(vadc->regmap);
u8 mode, sta1, chan, dig, en, req;
int ret;
 
@@ -263,7 +262,7 @@ static void vadc_show_status(struct vadc_priv *vadc)
if (ret)
return;
 
-   dev_err(vadc->dev,
+   dev_err(dev,
"mode:%02x en:%02x chan:%02x dig:%02x req:%02x sta1:%02x\n",
mode, en, chan, dig, req, sta1);
 }
@@ -350,13 +349,14 @@ static int vadc_read_result(struct vadc_priv *vadc, u16 
*data)
 static struct vadc_channel_prop *vadc_get_channel(struct vadc_priv *vadc,
  unsigned int num)
 {
+   struct device *dev = regmap_get_device(vadc->regmap);
unsigned int i;
 
for (i = 0; i < vadc->nchannels; i++)
if (vadc->chan_props[i].channel == num)
return >chan_props[i];
 
-   dev_dbg(vadc->dev, "no such channel %02x\n", num);
+   dev_dbg(dev, "no such channel %02x\n", num);
 
return NULL;
 }
@@ -364,6 +364,7 @@ static struct vadc_channel_prop *vadc_get_channel(struct 
vadc_priv *vadc,
 static int vadc_do_conversion(struct vadc_priv *vadc,
  struct vadc_channel_prop *prop, u16 *data)
 {
+   struct device *dev = regmap_get_device(vadc->regmap);
unsigned int timeout;
int ret;
 
@@ -406,7 +407,7 @@ static int vadc_do_conversion(struct vadc_priv *vadc,
 err_disable:
vadc_set_state(vadc, false);
if (ret)
-   dev_err(vadc->dev, "conversion failed\n");
+   dev_err(dev, "conversion failed\n");
 unlock:
mutex_unlock(>lock);
return ret;
@@ -414,6 +415,7 @@ unlock:
 
 static int vadc_measure_ref_points(struct vadc_priv *vadc)
 {
+   struct device *dev = regmap_get_device(vadc->regmap);
struct vadc_channel_prop *prop;
u16 read_1, read_2;
int ret;
@@ -463,7 +465,7 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc)
vadc->graph[VADC_CALIB_RATIOMETRIC].gnd = read_2;
 err:
if (ret)
-   dev_err(vadc->dev, "measure reference points failed\n");
+   dev_err(dev, "measure reference points failed\n");
 
return ret;
 }
@@ -814,6 +816,7 @@ static int vadc_get_dt_channel_data(struct device *dev,
 
 static int vadc_get_dt_data(struct vadc_priv *vadc, struct device_node *node)
 {
+   struct device *dev = regmap_get_device(vadc->regmap);
const struct vadc_channels *vadc_chan;
struct iio_chan_spec *iio_chan;
struct vadc_channel_prop prop;
@@ -825,12 +828,12 @@ static int vadc_get_dt_data(struct vadc_priv *vadc, 
struct device_node *node)
if (!vadc->nchannels)
return -EINVAL;
 
-   vadc->iio_chans = devm_kcalloc(vadc->dev, vadc->nchannels,
+   vadc->iio_chans = devm_kcalloc(dev, vadc->nchannels,
   sizeof(*vadc->iio_chans), GFP_KERNEL);
if (!vadc->iio_chans)
return -ENOMEM;
 
-   vadc->chan_props = devm_kcalloc(vadc->dev, vadc->nchannels,
+   vadc->chan_props = devm_kcalloc(dev, vadc->nchannels,
sizeof(*vadc->chan_props), GFP_KERNEL);
if (!vadc->chan_props)
return -ENOMEM;
@@ -838,7 +841,7 @@ static int vadc_get_dt_data(struct vadc_priv *vadc, struct 
device_node *node)
iio_chan = vadc->iio_chans;
 
for_each_available_child_of_node(node, child) {
-   ret = vadc_get_dt_channel_data(vadc->dev, , child);
+   ret = vadc_get_dt_channel_data(dev, , child);
if (ret) {
of_node_put(child);
 

Re: [REF PATCH] x86/tlb: just do tlb flush on one of siblings of SMT

[Alex Shi]

On 04/06/2016 12:47 PM, Andy Lutomirski wrote:
> On Apr 5, 2016 8:17 PM, "Alex Shi"  wrote:
>>
>> It seems Intel core still share the TLB pool, flush both of threads' TLB
>> just cause a extra useless IPI and a extra flush. The extra flush will
>> flush out TLB again which another thread just introduced.
>> That's double waste.
> 
> Do you have a reference in both the SDM and the APM for this?

No. as I said in the end of commit log. There are no any official
guarantee for this usage, but it seems working widely in Intel CPUs.

And the performance benefit is so tempted...
Is there Intel's guys like to dig it more? :)

> 
> Do we have a guarantee that this serialized the front end such that
> the non-targetted sibling won't execute an instruction that it decoded
> from a stale translation?

Is your worrying an evidence for my guess? Otherwise the stale
instruction happens either before IPI coming in... :)
> 
> This will conflict rather deeply with my PCID series, too.
> 
> --Andy
> 

[RESEND PATCH v2 6/6] dmaengine: vdma: Add Support for Xilinx AXI Central Direct Memory Access Engine

[Kedareswara rao Appana]

This patch adds support for the AXI Central Direct Memory Access
(AXI CDMA) core to the existing vdma driver, AXI CDMA is a
soft Xilinx IP core that provides high-bandwidth
Direct Memory Access(DMA) between a memory-mapped
source address and a memory-mapped destination address.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v2:
---> have differenet structures for h/w desc.
---> Added comments to the relevant sections as suggested by Laurent Pinchart.
---> Fixed trival code clean up/spacing issues as suggested by Laurent Pinchart.

 drivers/dma/xilinx/xilinx_vdma.c | 236 ++-
 include/linux/dma/xilinx_dma.h   |   2 +
 2 files changed, 236 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index 3268415..e5771a0 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -21,6 +21,10 @@
  * and AXI4-Stream target peripherals. It supports one receive and one
  * transmit channel, both of them optional at synthesis time.
  *
+ * The AXI CDMA, is a soft IP, which provides high-bandwidth Direct Memory
+ * Access (DMA) between a memory-mapped source address and a memory-mapped
+ * destination address.
+ *
  * 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
@@ -158,6 +162,13 @@
 #define XILINX_DMA_COALESCE_MAX255
 #define XILINX_DMA_NUM_APP_WORDS   5
 
+/* AXI CDMA Specific Registers/Offsets */
+#define XILINX_CDMA_REG_SRCADDR0x18
+#define XILINX_CDMA_REG_DSTADDR0x20
+
+/* AXI CDMA Specific Masks */
+#define XILINX_CDMA_CR_SGMODE  BIT(3)
+
 /**
  * struct xilinx_vdma_desc_hw - Hardware Descriptor
  * @next_desc: Next Descriptor Pointer @0x00
@@ -204,6 +215,28 @@ struct xilinx_axidma_desc_hw {
 } __aligned(64);
 
 /**
+ * struct xilinx_cdma_desc_hw - Hardware Descriptor
+ * @next_desc: Next Descriptor Pointer @0x00
+ * @pad1: Reserved @0x04
+ * @src_addr: Source address @0x08
+ * @pad2: Reserved @0x0C
+ * @dest_addr: Destination address @0x10
+ * @pad3: Reserved @0x14
+ * @control: Control field @0x18
+ * @status: Status field @0x1C
+ */
+struct xilinx_cdma_desc_hw {
+   u32 next_desc;
+   u32 pad1;
+   u32 src_addr;
+   u32 pad2;
+   u32 dest_addr;
+   u32 pad3;
+   u32 control;
+   u32 status;
+} __aligned(64);
+
+/**
  * struct xilinx_vdma_tx_segment - Descriptor segment
  * @hw: Hardware descriptor
  * @node: Node in the descriptor segments list
@@ -228,6 +261,18 @@ struct xilinx_axidma_tx_segment {
 } __aligned(64);
 
 /**
+ * struct xilinx_cdma_tx_segment - Descriptor segment
+ * @hw: Hardware descriptor
+ * @node: Node in the descriptor segments list
+ * @phys: Physical address of segment
+ */
+struct xilinx_cdma_tx_segment {
+   struct xilinx_cdma_desc_hw hw;
+   struct list_head node;
+   dma_addr_t phys;
+} __aligned(64);
+
+/**
  * struct xilinx_dma_tx_descriptor - Per Transaction structure
  * @async_tx: Async transaction descriptor
  * @segments: TX segments list
@@ -416,6 +461,28 @@ xilinx_vdma_alloc_tx_segment(struct xilinx_dma_chan *chan)
 }
 
 /**
+ * xilinx_cdma_alloc_tx_segment - Allocate transaction segment
+ * @chan: Driver specific DMA channel
+ *
+ * Return: The allocated segment on success and NULL on failure.
+ */
+static struct xilinx_cdma_tx_segment *
+xilinx_cdma_alloc_tx_segment(struct xilinx_dma_chan *chan)
+{
+   struct xilinx_cdma_tx_segment *segment;
+   dma_addr_t phys;
+
+   segment = dma_pool_alloc(chan->desc_pool, GFP_ATOMIC, );
+   if (!segment)
+   return NULL;
+
+   memset(segment, 0, sizeof(*segment));
+   segment->phys = phys;
+
+   return segment;
+}
+
+/**
  * xilinx_axidma_alloc_tx_segment - Allocate transaction segment
  * @chan: Driver specific DMA channel
  *
@@ -449,6 +516,17 @@ static void xilinx_dma_free_tx_segment(struct 
xilinx_dma_chan *chan,
 }
 
 /**
+ * xilinx_cdma_free_tx_segment - Free transaction segment
+ * @chan: Driver specific DMA channel
+ * @segment: DMA transaction segment
+ */
+static void xilinx_cdma_free_tx_segment(struct xilinx_dma_chan *chan,
+   struct xilinx_cdma_tx_segment *segment)
+{
+   dma_pool_free(chan->desc_pool, segment, segment->phys);
+}
+
+/**
  * xilinx_vdma_free_tx_segment - Free transaction segment
  * @chan: Driver specific DMA channel
  * @segment: DMA transaction segment
@@ -489,6 +567,7 @@ xilinx_dma_free_tx_descriptor(struct xilinx_dma_chan *chan,
   struct xilinx_dma_tx_descriptor *desc)
 {
struct xilinx_vdma_tx_segment *segment, *next;
+   struct xilinx_cdma_tx_segment *cdma_segment, *cdma_next;
struct xilinx_axidma_tx_segment *axidma_segment, *axidma_next;
 
if (!desc)
@@ -499,6 

[RESEND PATCH v2 5/6] Documentation: DT: vdma: update binding doc for AXI CDMA

[Kedareswara rao Appana]

This patch updates the device-tree binding doc for
adding support for AXI CDMA.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v2:
---> Modified commit message as suggested by Vinod.
---> Moved the patch to forward in the series as suggested by vinod.

 .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
index 5841421..2b0c12b 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
@@ -8,8 +8,12 @@ target devices. It can be configured to have one channel or 
two channels.
 If configured as two channels, one is to transmit to the device and another
 is to receive from the device.
 
+Xilinx AXI CDMA engine, it does transfers between memory-mapped source
+address and a memory-mapped destination address.
+
 Required properties:
-- compatible: Should be "xlnx,axi-vdma-1.00.a" or "xlnx,axi-dma-1.00.a"
+- compatible: Should be "xlnx,axi-vdma-1.00.a" or "xlnx,axi-dma-1.00.a" or
+ "xlnx,axi-cdma-1.00.a""
 - #dma-cells: Should be <1>, see "dmas" property below
 - reg: Should contain VDMA registers location and length.
 - xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
@@ -80,6 +84,18 @@ axi_dma_0: axidma@4040 {
} ;
 } ;
 
+axi_cdma_0: axicdma@7e20 {
+   compatible = "xlnx,axi-cdma-1.00.a";
+   #dma-cells = <1>;
+   reg = < 0x7e20 0x1 >;
+   xlnx,addrwidth = <0x20>;
+   dma-channel@7e20 {
+   compatible = "xlnx,axi-dma-mm2s-channel";
+   interrupts = < 0 55 4 >;
+   xlnx,datawidth = <0x40>;
+   } ;
+} ;
+
 * DMA client
 
 Required properties:
-- 
2.1.2

[PATCH 2/9] iio: adc: qcom-spmi-iadc: use regmap to retrieve struct device

[Alison Schofield]

Driver includes struct regmap and struct device in its global data.
Remove the struct device and use regmap API to retrieve device info.

Patch created using Coccinelle plus manual edits.

Signed-off-by: Alison Schofield 
---
 drivers/iio/adc/qcom-spmi-iadc.c | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/iio/adc/qcom-spmi-iadc.c b/drivers/iio/adc/qcom-spmi-iadc.c
index fabd24e..f69a057 100644
--- a/drivers/iio/adc/qcom-spmi-iadc.c
+++ b/drivers/iio/adc/qcom-spmi-iadc.c
@@ -102,7 +102,6 @@
 /**
  * struct iadc_chip - IADC Current ADC device structure.
  * @regmap: regmap for register read/write.
- * @dev: This device pointer.
  * @base: base offset for the ADC peripheral.
  * @rsense: Values of the internal and external sense resister in micro Ohms.
  * @poll_eoc: Poll for end of conversion instead of waiting for IRQ.
@@ -113,7 +112,6 @@
  */
 struct iadc_chip {
struct regmap   *regmap;
-   struct device   *dev;
u16 base;
boolpoll_eoc;
u32 rsense[2];
@@ -170,6 +168,7 @@ static int iadc_set_state(struct iadc_chip *iadc, bool 
state)
 
 static void iadc_status_show(struct iadc_chip *iadc)
 {
+   struct device *dev = regmap_get_device(iadc->regmap);
u8 mode, sta1, chan, dig, en, req;
int ret;
 
@@ -197,7 +196,7 @@ static void iadc_status_show(struct iadc_chip *iadc)
if (ret < 0)
return;
 
-   dev_err(iadc->dev,
+   dev_err(dev,
"mode:%02x en:%02x chan:%02x dig:%02x req:%02x sta1:%02x\n",
mode, en, chan, dig, req, sta1);
 }
@@ -284,6 +283,7 @@ static int iadc_read_result(struct iadc_chip *iadc, u16 
*data)
 
 static int iadc_do_conversion(struct iadc_chip *iadc, int chan, u16 *data)
 {
+   struct device *dev = regmap_get_device(iadc->regmap);
unsigned int wait;
int ret;
 
@@ -310,7 +310,7 @@ static int iadc_do_conversion(struct iadc_chip *iadc, int 
chan, u16 *data)
 exit:
iadc_set_state(iadc, false);
if (ret < 0)
-   dev_err(iadc->dev, "conversion failed\n");
+   dev_err(dev, "conversion failed\n");
 
return ret;
 }
@@ -320,6 +320,7 @@ static int iadc_read_raw(struct iio_dev *indio_dev,
 int *val, int *val2, long mask)
 {
struct iadc_chip *iadc = iio_priv(indio_dev);
+   struct device *dev = regmap_get_device(iadc->regmap);
s32 isense_ua, vsense_uv;
u16 adc_raw, vsense_raw;
int ret;
@@ -339,7 +340,7 @@ static int iadc_read_raw(struct iio_dev *indio_dev,
 
isense_ua = vsense_uv / iadc->rsense[chan->channel];
 
-   dev_dbg(iadc->dev, "off %d gain %d adc %d %duV I %duA\n",
+   dev_dbg(dev, "off %d gain %d adc %d %duV I %duA\n",
iadc->offset[chan->channel], iadc->gain,
adc_raw, vsense_uv, isense_ua);
 
@@ -370,6 +371,7 @@ static irqreturn_t iadc_isr(int irq, void *dev_id)
 
 static int iadc_update_offset(struct iadc_chip *iadc)
 {
+   struct device *dev = regmap_get_device(iadc->regmap);
int ret;
 
ret = iadc_do_conversion(iadc, IADC_GAIN_17P857MV, >gain);
@@ -382,7 +384,7 @@ static int iadc_update_offset(struct iadc_chip *iadc)
return ret;
 
if (iadc->gain == iadc->offset[IADC_INT_RSENSE]) {
-   dev_err(iadc->dev, "error: internal offset == gain %d\n",
+   dev_err(dev, "error: internal offset == gain %d\n",
iadc->gain);
return -EINVAL;
}
@@ -393,8 +395,7 @@ static int iadc_update_offset(struct iadc_chip *iadc)
return ret;
 
if (iadc->gain == iadc->offset[IADC_EXT_RSENSE]) {
-   dev_err(iadc->dev, "error: external offset == gain %d\n",
-   iadc->gain);
+   dev_err(dev, "error: external offset == gain %d\n", iadc->gain);
return -EINVAL;
}
 
@@ -403,6 +404,7 @@ static int iadc_update_offset(struct iadc_chip *iadc)
 
 static int iadc_version_check(struct iadc_chip *iadc)
 {
+   struct device *dev = regmap_get_device(iadc->regmap);
u8 val;
int ret;
 
@@ -411,7 +413,7 @@ static int iadc_version_check(struct iadc_chip *iadc)
return ret;
 
if (val < IADC_PERPH_TYPE_ADC) {
-   dev_err(iadc->dev, "%d is not ADC\n", val);
+   dev_err(dev, "%d is not ADC\n", val);
return -EINVAL;
}
 
@@ -420,7 +422,7 @@ static int iadc_version_check(struct iadc_chip *iadc)
return ret;
 
if (val < IADC_PERPH_SUBTYPE_IADC) {
-   dev_err(iadc->dev, "%d is not IADC\n", val);
+   dev_err(dev, "%d is not IADC\n", val);
return -EINVAL;
}
 
@@ -429,7 +431,7 @@ static int iadc_version_check(struct iadc_chip *iadc)

[PATCH 3/9] iio: adc: qcom-spmi-vadc: use regmap to retrieve struct device

[Alison Schofield]

Driver includes struct regmap and struct device in its global data.
Remove the struct device and use regmap API to retrieve device info.

Patch created using Coccinelle plus manual edits.

Signed-off-by: Alison Schofield 
---
 drivers/iio/adc/qcom-spmi-vadc.c | 37 -
 1 file changed, 20 insertions(+), 17 deletions(-)

diff --git a/drivers/iio/adc/qcom-spmi-vadc.c b/drivers/iio/adc/qcom-spmi-vadc.c
index c2babe5..9e7aeca 100644
--- a/drivers/iio/adc/qcom-spmi-vadc.c
+++ b/drivers/iio/adc/qcom-spmi-vadc.c
@@ -161,7 +161,6 @@ struct vadc_channel_prop {
 /**
  * struct vadc_priv - VADC private structure.
  * @regmap: pointer to struct regmap.
- * @dev: pointer to struct device.
  * @base: base address for the ADC peripheral.
  * @nchannels: number of VADC channels.
  * @chan_props: array of VADC channel properties.
@@ -174,7 +173,6 @@ struct vadc_channel_prop {
  */
 struct vadc_priv {
struct regmap*regmap;
-   struct device*dev;
u16  base;
unsigned int nchannels;
struct vadc_channel_prop *chan_props;
@@ -236,6 +234,7 @@ static int vadc_set_state(struct vadc_priv *vadc, bool 
state)
 
 static void vadc_show_status(struct vadc_priv *vadc)
 {
+   struct device *dev = regmap_get_device(vadc->regmap);
u8 mode, sta1, chan, dig, en, req;
int ret;
 
@@ -263,7 +262,7 @@ static void vadc_show_status(struct vadc_priv *vadc)
if (ret)
return;
 
-   dev_err(vadc->dev,
+   dev_err(dev,
"mode:%02x en:%02x chan:%02x dig:%02x req:%02x sta1:%02x\n",
mode, en, chan, dig, req, sta1);
 }
@@ -350,13 +349,14 @@ static int vadc_read_result(struct vadc_priv *vadc, u16 
*data)
 static struct vadc_channel_prop *vadc_get_channel(struct vadc_priv *vadc,
  unsigned int num)
 {
+   struct device *dev = regmap_get_device(vadc->regmap);
unsigned int i;
 
for (i = 0; i < vadc->nchannels; i++)
if (vadc->chan_props[i].channel == num)
return >chan_props[i];
 
-   dev_dbg(vadc->dev, "no such channel %02x\n", num);
+   dev_dbg(dev, "no such channel %02x\n", num);
 
return NULL;
 }
@@ -364,6 +364,7 @@ static struct vadc_channel_prop *vadc_get_channel(struct 
vadc_priv *vadc,
 static int vadc_do_conversion(struct vadc_priv *vadc,
  struct vadc_channel_prop *prop, u16 *data)
 {
+   struct device *dev = regmap_get_device(vadc->regmap);
unsigned int timeout;
int ret;
 
@@ -406,7 +407,7 @@ static int vadc_do_conversion(struct vadc_priv *vadc,
 err_disable:
vadc_set_state(vadc, false);
if (ret)
-   dev_err(vadc->dev, "conversion failed\n");
+   dev_err(dev, "conversion failed\n");
 unlock:
mutex_unlock(>lock);
return ret;
@@ -414,6 +415,7 @@ unlock:
 
 static int vadc_measure_ref_points(struct vadc_priv *vadc)
 {
+   struct device *dev = regmap_get_device(vadc->regmap);
struct vadc_channel_prop *prop;
u16 read_1, read_2;
int ret;
@@ -463,7 +465,7 @@ static int vadc_measure_ref_points(struct vadc_priv *vadc)
vadc->graph[VADC_CALIB_RATIOMETRIC].gnd = read_2;
 err:
if (ret)
-   dev_err(vadc->dev, "measure reference points failed\n");
+   dev_err(dev, "measure reference points failed\n");
 
return ret;
 }
@@ -814,6 +816,7 @@ static int vadc_get_dt_channel_data(struct device *dev,
 
 static int vadc_get_dt_data(struct vadc_priv *vadc, struct device_node *node)
 {
+   struct device *dev = regmap_get_device(vadc->regmap);
const struct vadc_channels *vadc_chan;
struct iio_chan_spec *iio_chan;
struct vadc_channel_prop prop;
@@ -825,12 +828,12 @@ static int vadc_get_dt_data(struct vadc_priv *vadc, 
struct device_node *node)
if (!vadc->nchannels)
return -EINVAL;
 
-   vadc->iio_chans = devm_kcalloc(vadc->dev, vadc->nchannels,
+   vadc->iio_chans = devm_kcalloc(dev, vadc->nchannels,
   sizeof(*vadc->iio_chans), GFP_KERNEL);
if (!vadc->iio_chans)
return -ENOMEM;
 
-   vadc->chan_props = devm_kcalloc(vadc->dev, vadc->nchannels,
+   vadc->chan_props = devm_kcalloc(dev, vadc->nchannels,
sizeof(*vadc->chan_props), GFP_KERNEL);
if (!vadc->chan_props)
return -ENOMEM;
@@ -838,7 +841,7 @@ static int vadc_get_dt_data(struct vadc_priv *vadc, struct 
device_node *node)
iio_chan = vadc->iio_chans;
 
for_each_available_child_of_node(node, child) {
-   ret = vadc_get_dt_channel_data(vadc->dev, , child);
+   ret = vadc_get_dt_channel_data(dev, , child);
if (ret) {
of_node_put(child);

Re: [REF PATCH] x86/tlb: just do tlb flush on one of siblings of SMT

[Alex Shi]

On 04/06/2016 12:47 PM, Andy Lutomirski wrote:
> On Apr 5, 2016 8:17 PM, "Alex Shi"  wrote:
>>
>> It seems Intel core still share the TLB pool, flush both of threads' TLB
>> just cause a extra useless IPI and a extra flush. The extra flush will
>> flush out TLB again which another thread just introduced.
>> That's double waste.
> 
> Do you have a reference in both the SDM and the APM for this?

No. as I said in the end of commit log. There are no any official
guarantee for this usage, but it seems working widely in Intel CPUs.

And the performance benefit is so tempted...
Is there Intel's guys like to dig it more? :)

> 
> Do we have a guarantee that this serialized the front end such that
> the non-targetted sibling won't execute an instruction that it decoded
> from a stale translation?

Is your worrying an evidence for my guess? Otherwise the stale
instruction happens either before IPI coming in... :)
> 
> This will conflict rather deeply with my PCID series, too.
> 
> --Andy
> 

[RESEND PATCH v2 6/6] dmaengine: vdma: Add Support for Xilinx AXI Central Direct Memory Access Engine

[Kedareswara rao Appana]

This patch adds support for the AXI Central Direct Memory Access
(AXI CDMA) core to the existing vdma driver, AXI CDMA is a
soft Xilinx IP core that provides high-bandwidth
Direct Memory Access(DMA) between a memory-mapped
source address and a memory-mapped destination address.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v2:
---> have differenet structures for h/w desc.
---> Added comments to the relevant sections as suggested by Laurent Pinchart.
---> Fixed trival code clean up/spacing issues as suggested by Laurent Pinchart.

 drivers/dma/xilinx/xilinx_vdma.c | 236 ++-
 include/linux/dma/xilinx_dma.h   |   2 +
 2 files changed, 236 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index 3268415..e5771a0 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -21,6 +21,10 @@
  * and AXI4-Stream target peripherals. It supports one receive and one
  * transmit channel, both of them optional at synthesis time.
  *
+ * The AXI CDMA, is a soft IP, which provides high-bandwidth Direct Memory
+ * Access (DMA) between a memory-mapped source address and a memory-mapped
+ * destination address.
+ *
  * 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
@@ -158,6 +162,13 @@
 #define XILINX_DMA_COALESCE_MAX255
 #define XILINX_DMA_NUM_APP_WORDS   5
 
+/* AXI CDMA Specific Registers/Offsets */
+#define XILINX_CDMA_REG_SRCADDR0x18
+#define XILINX_CDMA_REG_DSTADDR0x20
+
+/* AXI CDMA Specific Masks */
+#define XILINX_CDMA_CR_SGMODE  BIT(3)
+
 /**
  * struct xilinx_vdma_desc_hw - Hardware Descriptor
  * @next_desc: Next Descriptor Pointer @0x00
@@ -204,6 +215,28 @@ struct xilinx_axidma_desc_hw {
 } __aligned(64);
 
 /**
+ * struct xilinx_cdma_desc_hw - Hardware Descriptor
+ * @next_desc: Next Descriptor Pointer @0x00
+ * @pad1: Reserved @0x04
+ * @src_addr: Source address @0x08
+ * @pad2: Reserved @0x0C
+ * @dest_addr: Destination address @0x10
+ * @pad3: Reserved @0x14
+ * @control: Control field @0x18
+ * @status: Status field @0x1C
+ */
+struct xilinx_cdma_desc_hw {
+   u32 next_desc;
+   u32 pad1;
+   u32 src_addr;
+   u32 pad2;
+   u32 dest_addr;
+   u32 pad3;
+   u32 control;
+   u32 status;
+} __aligned(64);
+
+/**
  * struct xilinx_vdma_tx_segment - Descriptor segment
  * @hw: Hardware descriptor
  * @node: Node in the descriptor segments list
@@ -228,6 +261,18 @@ struct xilinx_axidma_tx_segment {
 } __aligned(64);
 
 /**
+ * struct xilinx_cdma_tx_segment - Descriptor segment
+ * @hw: Hardware descriptor
+ * @node: Node in the descriptor segments list
+ * @phys: Physical address of segment
+ */
+struct xilinx_cdma_tx_segment {
+   struct xilinx_cdma_desc_hw hw;
+   struct list_head node;
+   dma_addr_t phys;
+} __aligned(64);
+
+/**
  * struct xilinx_dma_tx_descriptor - Per Transaction structure
  * @async_tx: Async transaction descriptor
  * @segments: TX segments list
@@ -416,6 +461,28 @@ xilinx_vdma_alloc_tx_segment(struct xilinx_dma_chan *chan)
 }
 
 /**
+ * xilinx_cdma_alloc_tx_segment - Allocate transaction segment
+ * @chan: Driver specific DMA channel
+ *
+ * Return: The allocated segment on success and NULL on failure.
+ */
+static struct xilinx_cdma_tx_segment *
+xilinx_cdma_alloc_tx_segment(struct xilinx_dma_chan *chan)
+{
+   struct xilinx_cdma_tx_segment *segment;
+   dma_addr_t phys;
+
+   segment = dma_pool_alloc(chan->desc_pool, GFP_ATOMIC, );
+   if (!segment)
+   return NULL;
+
+   memset(segment, 0, sizeof(*segment));
+   segment->phys = phys;
+
+   return segment;
+}
+
+/**
  * xilinx_axidma_alloc_tx_segment - Allocate transaction segment
  * @chan: Driver specific DMA channel
  *
@@ -449,6 +516,17 @@ static void xilinx_dma_free_tx_segment(struct 
xilinx_dma_chan *chan,
 }
 
 /**
+ * xilinx_cdma_free_tx_segment - Free transaction segment
+ * @chan: Driver specific DMA channel
+ * @segment: DMA transaction segment
+ */
+static void xilinx_cdma_free_tx_segment(struct xilinx_dma_chan *chan,
+   struct xilinx_cdma_tx_segment *segment)
+{
+   dma_pool_free(chan->desc_pool, segment, segment->phys);
+}
+
+/**
  * xilinx_vdma_free_tx_segment - Free transaction segment
  * @chan: Driver specific DMA channel
  * @segment: DMA transaction segment
@@ -489,6 +567,7 @@ xilinx_dma_free_tx_descriptor(struct xilinx_dma_chan *chan,
   struct xilinx_dma_tx_descriptor *desc)
 {
struct xilinx_vdma_tx_segment *segment, *next;
+   struct xilinx_cdma_tx_segment *cdma_segment, *cdma_next;
struct xilinx_axidma_tx_segment *axidma_segment, *axidma_next;
 
if (!desc)
@@ -499,6 +578,12 @@ 

[RESEND PATCH v2 5/6] Documentation: DT: vdma: update binding doc for AXI CDMA

[Kedareswara rao Appana]

This patch updates the device-tree binding doc for
adding support for AXI CDMA.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v2:
---> Modified commit message as suggested by Vinod.
---> Moved the patch to forward in the series as suggested by vinod.

 .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
index 5841421..2b0c12b 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
@@ -8,8 +8,12 @@ target devices. It can be configured to have one channel or 
two channels.
 If configured as two channels, one is to transmit to the device and another
 is to receive from the device.
 
+Xilinx AXI CDMA engine, it does transfers between memory-mapped source
+address and a memory-mapped destination address.
+
 Required properties:
-- compatible: Should be "xlnx,axi-vdma-1.00.a" or "xlnx,axi-dma-1.00.a"
+- compatible: Should be "xlnx,axi-vdma-1.00.a" or "xlnx,axi-dma-1.00.a" or
+ "xlnx,axi-cdma-1.00.a""
 - #dma-cells: Should be <1>, see "dmas" property below
 - reg: Should contain VDMA registers location and length.
 - xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
@@ -80,6 +84,18 @@ axi_dma_0: axidma@4040 {
} ;
 } ;
 
+axi_cdma_0: axicdma@7e20 {
+   compatible = "xlnx,axi-cdma-1.00.a";
+   #dma-cells = <1>;
+   reg = < 0x7e20 0x1 >;
+   xlnx,addrwidth = <0x20>;
+   dma-channel@7e20 {
+   compatible = "xlnx,axi-dma-mm2s-channel";
+   interrupts = < 0 55 4 >;
+   xlnx,datawidth = <0x40>;
+   } ;
+} ;
+
 * DMA client
 
 Required properties:
-- 
2.1.2

[PATCH 2/9] iio: adc: qcom-spmi-iadc: use regmap to retrieve struct device

[Alison Schofield]

Driver includes struct regmap and struct device in its global data.
Remove the struct device and use regmap API to retrieve device info.

Patch created using Coccinelle plus manual edits.

Signed-off-by: Alison Schofield 
---
 drivers/iio/adc/qcom-spmi-iadc.c | 32 +---
 1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/iio/adc/qcom-spmi-iadc.c b/drivers/iio/adc/qcom-spmi-iadc.c
index fabd24e..f69a057 100644
--- a/drivers/iio/adc/qcom-spmi-iadc.c
+++ b/drivers/iio/adc/qcom-spmi-iadc.c
@@ -102,7 +102,6 @@
 /**
  * struct iadc_chip - IADC Current ADC device structure.
  * @regmap: regmap for register read/write.
- * @dev: This device pointer.
  * @base: base offset for the ADC peripheral.
  * @rsense: Values of the internal and external sense resister in micro Ohms.
  * @poll_eoc: Poll for end of conversion instead of waiting for IRQ.
@@ -113,7 +112,6 @@
  */
 struct iadc_chip {
struct regmap   *regmap;
-   struct device   *dev;
u16 base;
boolpoll_eoc;
u32 rsense[2];
@@ -170,6 +168,7 @@ static int iadc_set_state(struct iadc_chip *iadc, bool 
state)
 
 static void iadc_status_show(struct iadc_chip *iadc)
 {
+   struct device *dev = regmap_get_device(iadc->regmap);
u8 mode, sta1, chan, dig, en, req;
int ret;
 
@@ -197,7 +196,7 @@ static void iadc_status_show(struct iadc_chip *iadc)
if (ret < 0)
return;
 
-   dev_err(iadc->dev,
+   dev_err(dev,
"mode:%02x en:%02x chan:%02x dig:%02x req:%02x sta1:%02x\n",
mode, en, chan, dig, req, sta1);
 }
@@ -284,6 +283,7 @@ static int iadc_read_result(struct iadc_chip *iadc, u16 
*data)
 
 static int iadc_do_conversion(struct iadc_chip *iadc, int chan, u16 *data)
 {
+   struct device *dev = regmap_get_device(iadc->regmap);
unsigned int wait;
int ret;
 
@@ -310,7 +310,7 @@ static int iadc_do_conversion(struct iadc_chip *iadc, int 
chan, u16 *data)
 exit:
iadc_set_state(iadc, false);
if (ret < 0)
-   dev_err(iadc->dev, "conversion failed\n");
+   dev_err(dev, "conversion failed\n");
 
return ret;
 }
@@ -320,6 +320,7 @@ static int iadc_read_raw(struct iio_dev *indio_dev,
 int *val, int *val2, long mask)
 {
struct iadc_chip *iadc = iio_priv(indio_dev);
+   struct device *dev = regmap_get_device(iadc->regmap);
s32 isense_ua, vsense_uv;
u16 adc_raw, vsense_raw;
int ret;
@@ -339,7 +340,7 @@ static int iadc_read_raw(struct iio_dev *indio_dev,
 
isense_ua = vsense_uv / iadc->rsense[chan->channel];
 
-   dev_dbg(iadc->dev, "off %d gain %d adc %d %duV I %duA\n",
+   dev_dbg(dev, "off %d gain %d adc %d %duV I %duA\n",
iadc->offset[chan->channel], iadc->gain,
adc_raw, vsense_uv, isense_ua);
 
@@ -370,6 +371,7 @@ static irqreturn_t iadc_isr(int irq, void *dev_id)
 
 static int iadc_update_offset(struct iadc_chip *iadc)
 {
+   struct device *dev = regmap_get_device(iadc->regmap);
int ret;
 
ret = iadc_do_conversion(iadc, IADC_GAIN_17P857MV, >gain);
@@ -382,7 +384,7 @@ static int iadc_update_offset(struct iadc_chip *iadc)
return ret;
 
if (iadc->gain == iadc->offset[IADC_INT_RSENSE]) {
-   dev_err(iadc->dev, "error: internal offset == gain %d\n",
+   dev_err(dev, "error: internal offset == gain %d\n",
iadc->gain);
return -EINVAL;
}
@@ -393,8 +395,7 @@ static int iadc_update_offset(struct iadc_chip *iadc)
return ret;
 
if (iadc->gain == iadc->offset[IADC_EXT_RSENSE]) {
-   dev_err(iadc->dev, "error: external offset == gain %d\n",
-   iadc->gain);
+   dev_err(dev, "error: external offset == gain %d\n", iadc->gain);
return -EINVAL;
}
 
@@ -403,6 +404,7 @@ static int iadc_update_offset(struct iadc_chip *iadc)
 
 static int iadc_version_check(struct iadc_chip *iadc)
 {
+   struct device *dev = regmap_get_device(iadc->regmap);
u8 val;
int ret;
 
@@ -411,7 +413,7 @@ static int iadc_version_check(struct iadc_chip *iadc)
return ret;
 
if (val < IADC_PERPH_TYPE_ADC) {
-   dev_err(iadc->dev, "%d is not ADC\n", val);
+   dev_err(dev, "%d is not ADC\n", val);
return -EINVAL;
}
 
@@ -420,7 +422,7 @@ static int iadc_version_check(struct iadc_chip *iadc)
return ret;
 
if (val < IADC_PERPH_SUBTYPE_IADC) {
-   dev_err(iadc->dev, "%d is not IADC\n", val);
+   dev_err(dev, "%d is not IADC\n", val);
return -EINVAL;
}
 
@@ -429,7 +431,7 @@ static int iadc_version_check(struct iadc_chip *iadc)
return ret;
 
if 

[RESEND PATCH v2 3/6] Documentation: DT: vdma: update binding doc for AXI DMA

[Kedareswara rao Appana]

This patch updates the device-tree binding doc for
adding support for AXI DMA.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v2:
---> Modified commit message as suggested by Vinod.
---> Moved the patch to forward in the series as suggested by vinod.

 .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
index a86737c..5841421 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
@@ -3,8 +3,13 @@ It can be configured to have one channel or two channels. If 
configured
 as two channels, one is to transmit to the video device and another is
 to receive from the video device.
 
+Xilinx AXI DMA engine, it does transfers between memory and AXI4 stream
+target devices. It can be configured to have one channel or two channels.
+If configured as two channels, one is to transmit to the device and another
+is to receive from the device.
+
 Required properties:
-- compatible: Should be "xlnx,axi-vdma-1.00.a"
+- compatible: Should be "xlnx,axi-vdma-1.00.a" or "xlnx,axi-dma-1.00.a"
 - #dma-cells: Should be <1>, see "dmas" property below
 - reg: Should contain VDMA registers location and length.
 - xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
@@ -59,6 +64,21 @@ axi_vdma_0: axivdma@4003 {
} ;
 } ;
 
+axi_dma_0: axidma@4040 {
+   compatible = "xlnx,axi-dma-1.00.a";
+   #dma-cells = <1>;
+   reg = < 0x4040 0x1 >;
+   dma-channel@4040 {
+   compatible = "xlnx,axi-dma-mm2s-channel";
+   interrupts = < 0 59 4 >;
+   xlnx,datawidth = <0x40>;
+   } ;
+   dma-channel@40400030 {
+   compatible = "xlnx,axi-dma-s2mm-channel";
+   interrupts = < 0 58 4 >;
+   xlnx,datawidth = <0x40>;
+   } ;
+} ;
 
 * DMA client
 
-- 
2.1.2

[PATCH 4/9] iio: accel: bmc150: use regmap to retrieve struct device

[Alison Schofield]

Driver includes struct regmap and struct device in its global data.
Remove the struct device and use regmap API to retrieve device info.

Patch created using Coccinelle plus manual edits.

Signed-off-by: Alison Schofield 
---
 drivers/iio/accel/bmc150-accel-core.c | 99 +++
 1 file changed, 54 insertions(+), 45 deletions(-)

diff --git a/drivers/iio/accel/bmc150-accel-core.c 
b/drivers/iio/accel/bmc150-accel-core.c
index f3d096f..ad5310b 100644
--- a/drivers/iio/accel/bmc150-accel-core.c
+++ b/drivers/iio/accel/bmc150-accel-core.c
@@ -188,7 +188,6 @@ enum bmc150_accel_trigger_id {
 
 struct bmc150_accel_data {
struct regmap *regmap;
-   struct device *dev;
int irq;
struct bmc150_accel_interrupt interrupts[BMC150_ACCEL_INTERRUPTS];
atomic_t active_intr;
@@ -256,6 +255,7 @@ static int bmc150_accel_set_mode(struct bmc150_accel_data 
*data,
 enum bmc150_power_modes mode,
 int dur_us)
 {
+   struct device *dev = regmap_get_device(data->regmap);
int i;
int ret;
u8 lpw_bits;
@@ -279,11 +279,11 @@ static int bmc150_accel_set_mode(struct bmc150_accel_data 
*data,
lpw_bits = mode << BMC150_ACCEL_PMU_MODE_SHIFT;
lpw_bits |= (dur_val << BMC150_ACCEL_PMU_BIT_SLEEP_DUR_SHIFT);
 
-   dev_dbg(data->dev, "Set Mode bits %x\n", lpw_bits);
+   dev_dbg(dev, "Set Mode bits %x\n", lpw_bits);
 
ret = regmap_write(data->regmap, BMC150_ACCEL_REG_PMU_LPW, lpw_bits);
if (ret < 0) {
-   dev_err(data->dev, "Error writing reg_pmu_lpw\n");
+   dev_err(dev, "Error writing reg_pmu_lpw\n");
return ret;
}
 
@@ -316,23 +316,24 @@ static int bmc150_accel_set_bw(struct bmc150_accel_data 
*data, int val,
 
 static int bmc150_accel_update_slope(struct bmc150_accel_data *data)
 {
+   struct device *dev = regmap_get_device(data->regmap);
int ret;
 
ret = regmap_write(data->regmap, BMC150_ACCEL_REG_INT_6,
data->slope_thres);
if (ret < 0) {
-   dev_err(data->dev, "Error writing reg_int_6\n");
+   dev_err(dev, "Error writing reg_int_6\n");
return ret;
}
 
ret = regmap_update_bits(data->regmap, BMC150_ACCEL_REG_INT_5,
 BMC150_ACCEL_SLOPE_DUR_MASK, data->slope_dur);
if (ret < 0) {
-   dev_err(data->dev, "Error updating reg_int_5\n");
+   dev_err(dev, "Error updating reg_int_5\n");
return ret;
}
 
-   dev_dbg(data->dev, "%s: %x %x\n", __func__, data->slope_thres,
+   dev_dbg(dev, "%s: %x %x\n", __func__, data->slope_thres,
data->slope_dur);
 
return ret;
@@ -378,20 +379,21 @@ static int bmc150_accel_get_startup_times(struct 
bmc150_accel_data *data)
 
 static int bmc150_accel_set_power_state(struct bmc150_accel_data *data, bool 
on)
 {
+   struct device *dev = regmap_get_device(data->regmap);
int ret;
 
if (on) {
-   ret = pm_runtime_get_sync(data->dev);
+   ret = pm_runtime_get_sync(dev);
} else {
-   pm_runtime_mark_last_busy(data->dev);
-   ret = pm_runtime_put_autosuspend(data->dev);
+   pm_runtime_mark_last_busy(dev);
+   ret = pm_runtime_put_autosuspend(dev);
}
 
if (ret < 0) {
-   dev_err(data->dev,
+   dev_err(dev,
"Failed: bmc150_accel_set_power_state for %d\n", on);
if (on)
-   pm_runtime_put_noidle(data->dev);
+   pm_runtime_put_noidle(dev);
 
return ret;
}
@@ -445,6 +447,7 @@ static void bmc150_accel_interrupts_setup(struct iio_dev 
*indio_dev,
 static int bmc150_accel_set_interrupt(struct bmc150_accel_data *data, int i,
  bool state)
 {
+   struct device *dev = regmap_get_device(data->regmap);
struct bmc150_accel_interrupt *intr = >interrupts[i];
const struct bmc150_accel_interrupt_info *info = intr->info;
int ret;
@@ -474,7 +477,7 @@ static int bmc150_accel_set_interrupt(struct 
bmc150_accel_data *data, int i,
ret = regmap_update_bits(data->regmap, info->map_reg, info->map_bitmask,
 (state ? info->map_bitmask : 0));
if (ret < 0) {
-   dev_err(data->dev, "Error updating reg_int_map\n");
+   dev_err(dev, "Error updating reg_int_map\n");
goto out_fix_power_state;
}
 
@@ -482,7 +485,7 @@ static int bmc150_accel_set_interrupt(struct 
bmc150_accel_data *data, int i,
ret = regmap_update_bits(data->regmap, info->en_reg, info->en_bitmask,
 (state ? info->en_bitmask : 0));
if (ret < 0) {
-   

[RESEND PATCH v2 4/6] dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine

[Kedareswara rao Appana]

This patch adds support for the AXI Direct Memory Access (AXI DMA)
core in the existing vdma driver, AXI DMA Core is a
soft Xilinx IP core that provides high-bandwidth
direct memory access between memory and AXI4-Stream
type target peripherals.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v2:
---> have differenet structures for h/w desc.
---> Added comments to the relevant sections as suggested by Laurent Pinchart.
---> Fixed trival code clean up/spacing issues as suggested by Laurent Pinchart.

 drivers/dma/xilinx/xilinx_vdma.c | 474 +++
 include/linux/dma/xilinx_dma.h   |  12 +
 2 files changed, 444 insertions(+), 42 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index 04fd8f5..3268415 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -16,6 +16,11 @@
  * video device (S2MM). Initialization, status, interrupt and management
  * registers are accessed through an AXI4-Lite slave interface.
  *
+ * The AXI Direct Memory Access (AXI DMA) core is a soft Xilinx IP core that
+ * provides high-bandwidth one dimensional direct memory access between memory
+ * and AXI4-Stream target peripherals. It supports one receive and one
+ * transmit channel, both of them optional at synthesis time.
+ *
  * 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
@@ -140,6 +145,19 @@
 /* Delay loop counter to prevent hardware failure */
 #define XILINX_DMA_LOOP_COUNT  100
 
+/* AXI DMA Specific Registers/Offsets */
+#define XILINX_DMA_REG_SRCDSTADDR  0x18
+#define XILINX_DMA_REG_BTT 0x28
+
+/* AXI DMA Specific Masks/Bit fields */
+#define XILINX_DMA_MAX_TRANS_LEN   GENMASK(22, 0)
+#define XILINX_DMA_CR_COALESCE_MAX GENMASK(23, 16)
+#define XILINX_DMA_CR_COALESCE_SHIFT   16
+#define XILINX_DMA_BD_SOP  BIT(27)
+#define XILINX_DMA_BD_EOP  BIT(26)
+#define XILINX_DMA_COALESCE_MAX255
+#define XILINX_DMA_NUM_APP_WORDS   5
+
 /**
  * struct xilinx_vdma_desc_hw - Hardware Descriptor
  * @next_desc: Next Descriptor Pointer @0x00
@@ -162,6 +180,30 @@ struct xilinx_vdma_desc_hw {
 } __aligned(64);
 
 /**
+ * struct xilinx_axidma_desc_hw - Hardware Descriptor for AXI DMA
+ * @next_desc: Next Descriptor Pointer @0x00
+ * @pad1: Reserved @0x04
+ * @buf_addr: Buffer address @0x08
+ * @pad2: Reserved @0x0C
+ * @pad3: Reserved @0x10
+ * @pad4: Reserved @0x14
+ * @control: Control field @0x18
+ * @status: Status field @0x1C
+ * @app: APP Fields @0x20 - 0x30
+ */
+struct xilinx_axidma_desc_hw {
+   u32 next_desc;
+   u32 pad1;
+   u32 buf_addr;
+   u32 pad2;
+   u32 pad3;
+   u32 pad4;
+   u32 control;
+   u32 status;
+   u32 app[XILINX_DMA_NUM_APP_WORDS];
+} __aligned(64);
+
+/**
  * struct xilinx_vdma_tx_segment - Descriptor segment
  * @hw: Hardware descriptor
  * @node: Node in the descriptor segments list
@@ -174,6 +216,18 @@ struct xilinx_vdma_tx_segment {
 } __aligned(64);
 
 /**
+ * struct xilinx_axidma_tx_segment - Descriptor segment
+ * @hw: Hardware descriptor
+ * @node: Node in the descriptor segments list
+ * @phys: Physical address of segment
+ */
+struct xilinx_axidma_tx_segment {
+   struct xilinx_axidma_desc_hw hw;
+   struct list_head node;
+   dma_addr_t phys;
+} __aligned(64);
+
+/**
  * struct xilinx_dma_tx_descriptor - Per Transaction structure
  * @async_tx: Async transaction descriptor
  * @segments: TX segments list
@@ -210,6 +264,9 @@ struct xilinx_dma_tx_descriptor {
  * @desc_pendingcount: Descriptor pending count
  * @ext_addr: Indicates 64 bit addressing is supported by dma channel
  * @desc_submitcount: Descriptor h/w submitted count
+ * @residue: Residue for AXI DMA
+ * @seg_v: Statically allocated segments base
+ * @start_transfer: Differentiate b/w DMA IP's transfer
  */
 struct xilinx_dma_chan {
struct xilinx_dma_device *xdev;
@@ -235,6 +292,9 @@ struct xilinx_dma_chan {
u32 desc_pendingcount;
bool ext_addr;
u32 desc_submitcount;
+   u32 residue;
+   struct xilinx_axidma_tx_segment *seg_v;
+   void (*start_transfer)(struct xilinx_dma_chan *chan);
 };
 
 /**
@@ -246,6 +306,7 @@ struct xilinx_dma_chan {
  * @has_sg: Specifies whether Scatter-Gather is present or not
  * @flush_on_fsync: Flush on frame sync
  * @ext_addr: Indicates 64 bit addressing is supported by dma device
+ * @dmatype: DMA ip type
  */
 struct xilinx_dma_device {
void __iomem *regs;
@@ -255,6 +316,7 @@ struct xilinx_dma_device {
bool has_sg;
u32 flush_on_fsync;
bool ext_addr;
+   enum xdma_ip_type dmatype;
 };
 
 /* Macros */
@@ -354,6 +416,39 @@ xilinx_vdma_alloc_tx_segment(struct xilinx_dma_chan *chan)
 }
 
 /**
+ * 

[RESEND PATCH v2 0/6] dmaengine: vdma: AXI DMA's enhancments

[Kedareswara rao Appana]

This patch series does some enhancments to the VDMA driver
which includes
--> Adding support for AXI DMA IP.
--> Adding support for AXI CDMA IP.
--> Fixing checkpatch warnings.

Kedareswara rao Appana (6):
  dmaengine: vdma: Fix checkpatch.pl warnings
  dmaengine: vdma: Rename xilinx_vdma_ prefix to xilinx_dma
  Documentation: DT: vdma: update binding doc for AXI DMA
  dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access
Engine
  Documentation: DT: vdma: update binding doc for AXI CDMA
  dmaengine: vdma: Add Support for Xilinx AXI Central Direct Memory
Access Engine

 .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt |   38 +-
 drivers/dma/xilinx/xilinx_vdma.c   | 1335 ++--
 include/linux/dma/xilinx_dma.h |   14 +
 3 files changed, 1028 insertions(+), 359 deletions(-)

-- 
2.1.2

[RESEND PATCH v2 3/6] Documentation: DT: vdma: update binding doc for AXI DMA

[Kedareswara rao Appana]

This patch updates the device-tree binding doc for
adding support for AXI DMA.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v2:
---> Modified commit message as suggested by Vinod.
---> Moved the patch to forward in the series as suggested by vinod.

 .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt | 22 +-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
index a86737c..5841421 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
@@ -3,8 +3,13 @@ It can be configured to have one channel or two channels. If 
configured
 as two channels, one is to transmit to the video device and another is
 to receive from the video device.
 
+Xilinx AXI DMA engine, it does transfers between memory and AXI4 stream
+target devices. It can be configured to have one channel or two channels.
+If configured as two channels, one is to transmit to the device and another
+is to receive from the device.
+
 Required properties:
-- compatible: Should be "xlnx,axi-vdma-1.00.a"
+- compatible: Should be "xlnx,axi-vdma-1.00.a" or "xlnx,axi-dma-1.00.a"
 - #dma-cells: Should be <1>, see "dmas" property below
 - reg: Should contain VDMA registers location and length.
 - xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
@@ -59,6 +64,21 @@ axi_vdma_0: axivdma@4003 {
} ;
 } ;
 
+axi_dma_0: axidma@4040 {
+   compatible = "xlnx,axi-dma-1.00.a";
+   #dma-cells = <1>;
+   reg = < 0x4040 0x1 >;
+   dma-channel@4040 {
+   compatible = "xlnx,axi-dma-mm2s-channel";
+   interrupts = < 0 59 4 >;
+   xlnx,datawidth = <0x40>;
+   } ;
+   dma-channel@40400030 {
+   compatible = "xlnx,axi-dma-s2mm-channel";
+   interrupts = < 0 58 4 >;
+   xlnx,datawidth = <0x40>;
+   } ;
+} ;
 
 * DMA client
 
-- 
2.1.2

[PATCH 4/9] iio: accel: bmc150: use regmap to retrieve struct device

[Alison Schofield]

Driver includes struct regmap and struct device in its global data.
Remove the struct device and use regmap API to retrieve device info.

Patch created using Coccinelle plus manual edits.

Signed-off-by: Alison Schofield 
---
 drivers/iio/accel/bmc150-accel-core.c | 99 +++
 1 file changed, 54 insertions(+), 45 deletions(-)

diff --git a/drivers/iio/accel/bmc150-accel-core.c 
b/drivers/iio/accel/bmc150-accel-core.c
index f3d096f..ad5310b 100644
--- a/drivers/iio/accel/bmc150-accel-core.c
+++ b/drivers/iio/accel/bmc150-accel-core.c
@@ -188,7 +188,6 @@ enum bmc150_accel_trigger_id {
 
 struct bmc150_accel_data {
struct regmap *regmap;
-   struct device *dev;
int irq;
struct bmc150_accel_interrupt interrupts[BMC150_ACCEL_INTERRUPTS];
atomic_t active_intr;
@@ -256,6 +255,7 @@ static int bmc150_accel_set_mode(struct bmc150_accel_data 
*data,
 enum bmc150_power_modes mode,
 int dur_us)
 {
+   struct device *dev = regmap_get_device(data->regmap);
int i;
int ret;
u8 lpw_bits;
@@ -279,11 +279,11 @@ static int bmc150_accel_set_mode(struct bmc150_accel_data 
*data,
lpw_bits = mode << BMC150_ACCEL_PMU_MODE_SHIFT;
lpw_bits |= (dur_val << BMC150_ACCEL_PMU_BIT_SLEEP_DUR_SHIFT);
 
-   dev_dbg(data->dev, "Set Mode bits %x\n", lpw_bits);
+   dev_dbg(dev, "Set Mode bits %x\n", lpw_bits);
 
ret = regmap_write(data->regmap, BMC150_ACCEL_REG_PMU_LPW, lpw_bits);
if (ret < 0) {
-   dev_err(data->dev, "Error writing reg_pmu_lpw\n");
+   dev_err(dev, "Error writing reg_pmu_lpw\n");
return ret;
}
 
@@ -316,23 +316,24 @@ static int bmc150_accel_set_bw(struct bmc150_accel_data 
*data, int val,
 
 static int bmc150_accel_update_slope(struct bmc150_accel_data *data)
 {
+   struct device *dev = regmap_get_device(data->regmap);
int ret;
 
ret = regmap_write(data->regmap, BMC150_ACCEL_REG_INT_6,
data->slope_thres);
if (ret < 0) {
-   dev_err(data->dev, "Error writing reg_int_6\n");
+   dev_err(dev, "Error writing reg_int_6\n");
return ret;
}
 
ret = regmap_update_bits(data->regmap, BMC150_ACCEL_REG_INT_5,
 BMC150_ACCEL_SLOPE_DUR_MASK, data->slope_dur);
if (ret < 0) {
-   dev_err(data->dev, "Error updating reg_int_5\n");
+   dev_err(dev, "Error updating reg_int_5\n");
return ret;
}
 
-   dev_dbg(data->dev, "%s: %x %x\n", __func__, data->slope_thres,
+   dev_dbg(dev, "%s: %x %x\n", __func__, data->slope_thres,
data->slope_dur);
 
return ret;
@@ -378,20 +379,21 @@ static int bmc150_accel_get_startup_times(struct 
bmc150_accel_data *data)
 
 static int bmc150_accel_set_power_state(struct bmc150_accel_data *data, bool 
on)
 {
+   struct device *dev = regmap_get_device(data->regmap);
int ret;
 
if (on) {
-   ret = pm_runtime_get_sync(data->dev);
+   ret = pm_runtime_get_sync(dev);
} else {
-   pm_runtime_mark_last_busy(data->dev);
-   ret = pm_runtime_put_autosuspend(data->dev);
+   pm_runtime_mark_last_busy(dev);
+   ret = pm_runtime_put_autosuspend(dev);
}
 
if (ret < 0) {
-   dev_err(data->dev,
+   dev_err(dev,
"Failed: bmc150_accel_set_power_state for %d\n", on);
if (on)
-   pm_runtime_put_noidle(data->dev);
+   pm_runtime_put_noidle(dev);
 
return ret;
}
@@ -445,6 +447,7 @@ static void bmc150_accel_interrupts_setup(struct iio_dev 
*indio_dev,
 static int bmc150_accel_set_interrupt(struct bmc150_accel_data *data, int i,
  bool state)
 {
+   struct device *dev = regmap_get_device(data->regmap);
struct bmc150_accel_interrupt *intr = >interrupts[i];
const struct bmc150_accel_interrupt_info *info = intr->info;
int ret;
@@ -474,7 +477,7 @@ static int bmc150_accel_set_interrupt(struct 
bmc150_accel_data *data, int i,
ret = regmap_update_bits(data->regmap, info->map_reg, info->map_bitmask,
 (state ? info->map_bitmask : 0));
if (ret < 0) {
-   dev_err(data->dev, "Error updating reg_int_map\n");
+   dev_err(dev, "Error updating reg_int_map\n");
goto out_fix_power_state;
}
 
@@ -482,7 +485,7 @@ static int bmc150_accel_set_interrupt(struct 
bmc150_accel_data *data, int i,
ret = regmap_update_bits(data->regmap, info->en_reg, info->en_bitmask,
 (state ? info->en_bitmask : 0));
if (ret < 0) {
-   dev_err(data->dev, 

[RESEND PATCH v2 4/6] dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access Engine

[Kedareswara rao Appana]

This patch adds support for the AXI Direct Memory Access (AXI DMA)
core in the existing vdma driver, AXI DMA Core is a
soft Xilinx IP core that provides high-bandwidth
direct memory access between memory and AXI4-Stream
type target peripherals.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v2:
---> have differenet structures for h/w desc.
---> Added comments to the relevant sections as suggested by Laurent Pinchart.
---> Fixed trival code clean up/spacing issues as suggested by Laurent Pinchart.

 drivers/dma/xilinx/xilinx_vdma.c | 474 +++
 include/linux/dma/xilinx_dma.h   |  12 +
 2 files changed, 444 insertions(+), 42 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index 04fd8f5..3268415 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -16,6 +16,11 @@
  * video device (S2MM). Initialization, status, interrupt and management
  * registers are accessed through an AXI4-Lite slave interface.
  *
+ * The AXI Direct Memory Access (AXI DMA) core is a soft Xilinx IP core that
+ * provides high-bandwidth one dimensional direct memory access between memory
+ * and AXI4-Stream target peripherals. It supports one receive and one
+ * transmit channel, both of them optional at synthesis time.
+ *
  * 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
@@ -140,6 +145,19 @@
 /* Delay loop counter to prevent hardware failure */
 #define XILINX_DMA_LOOP_COUNT  100
 
+/* AXI DMA Specific Registers/Offsets */
+#define XILINX_DMA_REG_SRCDSTADDR  0x18
+#define XILINX_DMA_REG_BTT 0x28
+
+/* AXI DMA Specific Masks/Bit fields */
+#define XILINX_DMA_MAX_TRANS_LEN   GENMASK(22, 0)
+#define XILINX_DMA_CR_COALESCE_MAX GENMASK(23, 16)
+#define XILINX_DMA_CR_COALESCE_SHIFT   16
+#define XILINX_DMA_BD_SOP  BIT(27)
+#define XILINX_DMA_BD_EOP  BIT(26)
+#define XILINX_DMA_COALESCE_MAX255
+#define XILINX_DMA_NUM_APP_WORDS   5
+
 /**
  * struct xilinx_vdma_desc_hw - Hardware Descriptor
  * @next_desc: Next Descriptor Pointer @0x00
@@ -162,6 +180,30 @@ struct xilinx_vdma_desc_hw {
 } __aligned(64);
 
 /**
+ * struct xilinx_axidma_desc_hw - Hardware Descriptor for AXI DMA
+ * @next_desc: Next Descriptor Pointer @0x00
+ * @pad1: Reserved @0x04
+ * @buf_addr: Buffer address @0x08
+ * @pad2: Reserved @0x0C
+ * @pad3: Reserved @0x10
+ * @pad4: Reserved @0x14
+ * @control: Control field @0x18
+ * @status: Status field @0x1C
+ * @app: APP Fields @0x20 - 0x30
+ */
+struct xilinx_axidma_desc_hw {
+   u32 next_desc;
+   u32 pad1;
+   u32 buf_addr;
+   u32 pad2;
+   u32 pad3;
+   u32 pad4;
+   u32 control;
+   u32 status;
+   u32 app[XILINX_DMA_NUM_APP_WORDS];
+} __aligned(64);
+
+/**
  * struct xilinx_vdma_tx_segment - Descriptor segment
  * @hw: Hardware descriptor
  * @node: Node in the descriptor segments list
@@ -174,6 +216,18 @@ struct xilinx_vdma_tx_segment {
 } __aligned(64);
 
 /**
+ * struct xilinx_axidma_tx_segment - Descriptor segment
+ * @hw: Hardware descriptor
+ * @node: Node in the descriptor segments list
+ * @phys: Physical address of segment
+ */
+struct xilinx_axidma_tx_segment {
+   struct xilinx_axidma_desc_hw hw;
+   struct list_head node;
+   dma_addr_t phys;
+} __aligned(64);
+
+/**
  * struct xilinx_dma_tx_descriptor - Per Transaction structure
  * @async_tx: Async transaction descriptor
  * @segments: TX segments list
@@ -210,6 +264,9 @@ struct xilinx_dma_tx_descriptor {
  * @desc_pendingcount: Descriptor pending count
  * @ext_addr: Indicates 64 bit addressing is supported by dma channel
  * @desc_submitcount: Descriptor h/w submitted count
+ * @residue: Residue for AXI DMA
+ * @seg_v: Statically allocated segments base
+ * @start_transfer: Differentiate b/w DMA IP's transfer
  */
 struct xilinx_dma_chan {
struct xilinx_dma_device *xdev;
@@ -235,6 +292,9 @@ struct xilinx_dma_chan {
u32 desc_pendingcount;
bool ext_addr;
u32 desc_submitcount;
+   u32 residue;
+   struct xilinx_axidma_tx_segment *seg_v;
+   void (*start_transfer)(struct xilinx_dma_chan *chan);
 };
 
 /**
@@ -246,6 +306,7 @@ struct xilinx_dma_chan {
  * @has_sg: Specifies whether Scatter-Gather is present or not
  * @flush_on_fsync: Flush on frame sync
  * @ext_addr: Indicates 64 bit addressing is supported by dma device
+ * @dmatype: DMA ip type
  */
 struct xilinx_dma_device {
void __iomem *regs;
@@ -255,6 +316,7 @@ struct xilinx_dma_device {
bool has_sg;
u32 flush_on_fsync;
bool ext_addr;
+   enum xdma_ip_type dmatype;
 };
 
 /* Macros */
@@ -354,6 +416,39 @@ xilinx_vdma_alloc_tx_segment(struct xilinx_dma_chan *chan)
 }
 
 /**
+ * xilinx_axidma_alloc_tx_segment - 

[RESEND PATCH v2 0/6] dmaengine: vdma: AXI DMA's enhancments

[Kedareswara rao Appana]

This patch series does some enhancments to the VDMA driver
which includes
--> Adding support for AXI DMA IP.
--> Adding support for AXI CDMA IP.
--> Fixing checkpatch warnings.

Kedareswara rao Appana (6):
  dmaengine: vdma: Fix checkpatch.pl warnings
  dmaengine: vdma: Rename xilinx_vdma_ prefix to xilinx_dma
  Documentation: DT: vdma: update binding doc for AXI DMA
  dmaengine: vdma: Add Support for Xilinx AXI Direct Memory Access
Engine
  Documentation: DT: vdma: update binding doc for AXI CDMA
  dmaengine: vdma: Add Support for Xilinx AXI Central Direct Memory
Access Engine

 .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt |   38 +-
 drivers/dma/xilinx/xilinx_vdma.c   | 1335 ++--
 include/linux/dma/xilinx_dma.h |   14 +
 3 files changed, 1028 insertions(+), 359 deletions(-)

-- 
2.1.2

[PATCH 1/9] iio: adc: exynos_adc: use regmap to retrieve struct device

[Alison Schofield]

Driver includes struct regmap and struct device in its global data.
Remove the struct device and use regmap API to retrieve device info.

Patch created using Coccinelle plus manual edits.

Signed-off-by: Alison Schofield 
---
 drivers/iio/adc/exynos_adc.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index c15756d..0313e0f 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -130,7 +130,6 @@
 
 struct exynos_adc {
struct exynos_adc_data  *data;
-   struct device   *dev;
struct input_dev*input;
void __iomem*regs;
struct regmap   *pmu_map;
@@ -173,11 +172,12 @@ static void exynos_adc_unprepare_clk(struct exynos_adc 
*info)
 
 static int exynos_adc_prepare_clk(struct exynos_adc *info)
 {
+   struct device *dev = regmap_get_device(info->pmu_map);
int ret;
 
ret = clk_prepare(info->clk);
if (ret) {
-   dev_err(info->dev, "failed preparing adc clock: %d\n", ret);
+   dev_err(dev, "failed preparing adc clock: %d\n", ret);
return ret;
}
 
@@ -185,7 +185,7 @@ static int exynos_adc_prepare_clk(struct exynos_adc *info)
ret = clk_prepare(info->sclk);
if (ret) {
clk_unprepare(info->clk);
-   dev_err(info->dev,
+   dev_err(dev,
"failed preparing sclk_adc clock: %d\n", ret);
return ret;
}
@@ -203,11 +203,12 @@ static void exynos_adc_disable_clk(struct exynos_adc 
*info)
 
 static int exynos_adc_enable_clk(struct exynos_adc *info)
 {
+   struct device *dev = regmap_get_device(info->pmu_map);
int ret;
 
ret = clk_enable(info->clk);
if (ret) {
-   dev_err(info->dev, "failed enabling adc clock: %d\n", ret);
+   dev_err(dev, "failed enabling adc clock: %d\n", ret);
return ret;
}
 
@@ -215,7 +216,7 @@ static int exynos_adc_enable_clk(struct exynos_adc *info)
ret = clk_enable(info->sclk);
if (ret) {
clk_disable(info->clk);
-   dev_err(info->dev,
+   dev_err(dev,
"failed enabling sclk_adc clock: %d\n", ret);
return ret;
}
@@ -610,13 +611,14 @@ static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
 static irqreturn_t exynos_ts_isr(int irq, void *dev_id)
 {
struct exynos_adc *info = dev_id;
-   struct iio_dev *dev = dev_get_drvdata(info->dev);
+   struct device *dev = regmap_get_device(info->pmu_map);
+   struct iio_dev *indio_dev = dev_get_drvdata(dev);
u32 x, y;
bool pressed;
int ret;
 
while (info->input->users) {
-   ret = exynos_read_s3c64xx_ts(dev, , );
+   ret = exynos_read_s3c64xx_ts(indio_dev, , );
if (ret == -ETIMEDOUT)
break;
 
@@ -800,8 +802,6 @@ static int exynos_adc_probe(struct platform_device *pdev)
 
info->tsirq = irq;
 
-   info->dev = >dev;
-
init_completion(>completion);
 
info->clk = devm_clk_get(>dev, "adc");
-- 
2.1.4

[RESEND PATCH v2 2/6] dmaengine: vdma: Rename xilinx_vdma_ prefix to xilinx_dma

[Kedareswara rao Appana]

This patch renames the xilinx_vdma_ prefix to xilinx_dma
for the API's and masks that will be shared b/w three DMA
IP cores.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v2:
---> New patch as suggested by Laurent Pinchart.

 drivers/dma/xilinx/xilinx_vdma.c | 636 +++
 1 file changed, 318 insertions(+), 318 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index 3c5ce37..04fd8f5 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -39,106 +39,106 @@
 #include "../dmaengine.h"
 
 /* Register/Descriptor Offsets */
-#define XILINX_VDMA_MM2S_CTRL_OFFSET   0x
-#define XILINX_VDMA_S2MM_CTRL_OFFSET   0x0030
+#define XILINX_DMA_MM2S_CTRL_OFFSET0x
+#define XILINX_DMA_S2MM_CTRL_OFFSET0x0030
 #define XILINX_VDMA_MM2S_DESC_OFFSET   0x0050
 #define XILINX_VDMA_S2MM_DESC_OFFSET   0x00a0
 
 /* Control Registers */
-#define XILINX_VDMA_REG_DMACR  0x
-#define XILINX_VDMA_DMACR_DELAY_MAX0xff
-#define XILINX_VDMA_DMACR_DELAY_SHIFT  24
-#define XILINX_VDMA_DMACR_FRAME_COUNT_MAX  0xff
-#define XILINX_VDMA_DMACR_FRAME_COUNT_SHIFT16
-#define XILINX_VDMA_DMACR_ERR_IRQ  BIT(14)
-#define XILINX_VDMA_DMACR_DLY_CNT_IRQ  BIT(13)
-#define XILINX_VDMA_DMACR_FRM_CNT_IRQ  BIT(12)
-#define XILINX_VDMA_DMACR_MASTER_SHIFT 8
-#define XILINX_VDMA_DMACR_FSYNCSRC_SHIFT   5
-#define XILINX_VDMA_DMACR_FRAMECNT_EN  BIT(4)
-#define XILINX_VDMA_DMACR_GENLOCK_EN   BIT(3)
-#define XILINX_VDMA_DMACR_RESETBIT(2)
-#define XILINX_VDMA_DMACR_CIRC_EN  BIT(1)
-#define XILINX_VDMA_DMACR_RUNSTOP  BIT(0)
-#define XILINX_VDMA_DMACR_FSYNCSRC_MASKGENMASK(6, 5)
-
-#define XILINX_VDMA_REG_DMASR  0x0004
-#define XILINX_VDMA_DMASR_EOL_LATE_ERR BIT(15)
-#define XILINX_VDMA_DMASR_ERR_IRQ  BIT(14)
-#define XILINX_VDMA_DMASR_DLY_CNT_IRQ  BIT(13)
-#define XILINX_VDMA_DMASR_FRM_CNT_IRQ  BIT(12)
-#define XILINX_VDMA_DMASR_SOF_LATE_ERR BIT(11)
-#define XILINX_VDMA_DMASR_SG_DEC_ERR   BIT(10)
-#define XILINX_VDMA_DMASR_SG_SLV_ERR   BIT(9)
-#define XILINX_VDMA_DMASR_EOF_EARLY_ERRBIT(8)
-#define XILINX_VDMA_DMASR_SOF_EARLY_ERRBIT(7)
-#define XILINX_VDMA_DMASR_DMA_DEC_ERR  BIT(6)
-#define XILINX_VDMA_DMASR_DMA_SLAVE_ERRBIT(5)
-#define XILINX_VDMA_DMASR_DMA_INT_ERR  BIT(4)
-#define XILINX_VDMA_DMASR_IDLE BIT(1)
-#define XILINX_VDMA_DMASR_HALTED   BIT(0)
-#define XILINX_VDMA_DMASR_DELAY_MASK   GENMASK(31, 24)
-#define XILINX_VDMA_DMASR_FRAME_COUNT_MASK GENMASK(23, 16)
-
-#define XILINX_VDMA_REG_CURDESC0x0008
-#define XILINX_VDMA_REG_TAILDESC   0x0010
-#define XILINX_VDMA_REG_REG_INDEX  0x0014
-#define XILINX_VDMA_REG_FRMSTORE   0x0018
-#define XILINX_VDMA_REG_THRESHOLD  0x001c
-#define XILINX_VDMA_REG_FRMPTR_STS 0x0024
-#define XILINX_VDMA_REG_PARK_PTR   0x0028
-#define XILINX_VDMA_PARK_PTR_WR_REF_SHIFT  8
-#define XILINX_VDMA_PARK_PTR_RD_REF_SHIFT  0
-#define XILINX_VDMA_REG_VDMA_VERSION   0x002c
+#define XILINX_DMA_REG_DMACR   0x
+#define XILINX_DMA_DMACR_DELAY_MAX 0xff
+#define XILINX_DMA_DMACR_DELAY_SHIFT   24
+#define XILINX_DMA_DMACR_FRAME_COUNT_MAX   0xff
+#define XILINX_DMA_DMACR_FRAME_COUNT_SHIFT 16
+#define XILINX_DMA_DMACR_ERR_IRQ   BIT(14)
+#define XILINX_DMA_DMACR_DLY_CNT_IRQ   BIT(13)
+#define XILINX_DMA_DMACR_FRM_CNT_IRQ   BIT(12)
+#define XILINX_DMA_DMACR_MASTER_SHIFT  8
+#define XILINX_DMA_DMACR_FSYNCSRC_SHIFT5
+#define XILINX_DMA_DMACR_FRAMECNT_EN   BIT(4)
+#define XILINX_DMA_DMACR_GENLOCK_ENBIT(3)
+#define XILINX_DMA_DMACR_RESET BIT(2)
+#define XILINX_DMA_DMACR_CIRC_EN   BIT(1)
+#define XILINX_DMA_DMACR_RUNSTOP   BIT(0)
+#define XILINX_DMA_DMACR_FSYNCSRC_MASK GENMASK(6, 5)
+
+#define XILINX_DMA_REG_DMASR   0x0004
+#define XILINX_DMA_DMASR_EOL_LATE_ERR  BIT(15)
+#define XILINX_DMA_DMASR_ERR_IRQ   BIT(14)
+#define XILINX_DMA_DMASR_DLY_CNT_IRQ   BIT(13)
+#define XILINX_DMA_DMASR_FRM_CNT_IRQ   BIT(12)
+#define XILINX_DMA_DMASR_SOF_LATE_ERR  BIT(11)
+#define XILINX_DMA_DMASR_SG_DEC_ERRBIT(10)
+#define XILINX_DMA_DMASR_SG_SLV_ERRBIT(9)
+#define XILINX_DMA_DMASR_EOF_EARLY_ERR BIT(8)
+#define XILINX_DMA_DMASR_SOF_EARLY_ERR BIT(7)
+#define XILINX_DMA_DMASR_DMA_DEC_ERR   BIT(6)
+#define XILINX_DMA_DMASR_DMA_SLAVE_ERR BIT(5)
+#define 

[RESEND PATCH v2 1/6] dmaengine: vdma: Fix checkpatch.pl warnings

[Kedareswara rao Appana]

This patch fixes the below checkpatch.pl warnings.

WARNING: void function return statements are not generally useful
+   return;
+}

WARNING: void function return statements are not generally useful
+   return;
+}

WARNING: Missing a blank line after declarations
+   u32 errors = status & XILINX_VDMA_DMASR_ALL_ERR_MASK;
+   vdma_ctrl_write(chan, XILINX_VDMA_REG_DMASR,

Acked-by: Laurent Pinchart 
Acked-by: Moritz Fischer 
Signed-off-by: Kedareswara rao Appana 
---
Changes for v2:
---> None.

 drivers/dma/xilinx/xilinx_vdma.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index b873d98..3c5ce37 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -597,8 +597,6 @@ static void xilinx_vdma_halt(struct xilinx_vdma_chan *chan)
chan, vdma_ctrl_read(chan, XILINX_VDMA_REG_DMASR));
chan->err = true;
}
-
-   return;
 }
 
 /**
@@ -623,8 +621,6 @@ static void xilinx_vdma_start(struct xilinx_vdma_chan *chan)
 
chan->err = true;
}
-
-   return;
 }
 
 /**
@@ -874,6 +870,7 @@ static irqreturn_t xilinx_vdma_irq_handler(int irq, void 
*data)
 * make sure not to write to other error bits to 1.
 */
u32 errors = status & XILINX_VDMA_DMASR_ALL_ERR_MASK;
+
vdma_ctrl_write(chan, XILINX_VDMA_REG_DMASR,
errors & XILINX_VDMA_DMASR_ERR_RECOVER_MASK);
 
-- 
2.1.2

[PATCH 0/9] iio: use regmap to retrieve struct device

[Alison Schofield]

These drivers include both struct regmap and struct device in their
global data.  Remove the redundant copy by deleting struct device 
from the drivers global data and using regmap API to retrieve when
needed.

This patchset removes all such redundancies in drivers/iio/.

Patches created using Coccinelle plus hand edits for whitespace and
one local var naming collision.

Alison Schofield (9):
  iio: adc: exynos_adc: use regmap to retrieve struct device
  iio: adc: qcom-spmi-iadc: use regmap to retrieve struct device
  iio: adc: qcom-spmi-vadc: use regmap to retrieve struct device
  iio: accel: bmc150: use regmap to retrieve struct device
  iio: accel: mma7455: use regmap to retrieve struct device
  iio: accel: mxc4005: use regmap to retrieve struct device
  iio: health: afe4403: use regmap to retrieve struct device
  iio: health: afe4404: use regmap to retrieve struct device
  iio: gyro: bmg160_core: use regmap to retrieve struct device

 drivers/iio/accel/bmc150-accel-core.c | 99 +++
 drivers/iio/accel/mma7455_core.c  |  5 +-
 drivers/iio/accel/mxc4005.c   | 26 +
 drivers/iio/adc/exynos_adc.c  | 18 +++
 drivers/iio/adc/qcom-spmi-iadc.c  | 32 +--
 drivers/iio/adc/qcom-spmi-vadc.c  | 37 +++--
 drivers/iio/gyro/bmg160_core.c| 86 +++---
 drivers/iio/health/afe4403.c  | 36 ++---
 drivers/iio/health/afe4404.c  | 38 +++---
 9 files changed, 197 insertions(+), 180 deletions(-)

-- 
2.1.4

[PATCH 1/9] iio: adc: exynos_adc: use regmap to retrieve struct device

[Alison Schofield]

Driver includes struct regmap and struct device in its global data.
Remove the struct device and use regmap API to retrieve device info.

Patch created using Coccinelle plus manual edits.

Signed-off-by: Alison Schofield 
---
 drivers/iio/adc/exynos_adc.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/iio/adc/exynos_adc.c b/drivers/iio/adc/exynos_adc.c
index c15756d..0313e0f 100644
--- a/drivers/iio/adc/exynos_adc.c
+++ b/drivers/iio/adc/exynos_adc.c
@@ -130,7 +130,6 @@
 
 struct exynos_adc {
struct exynos_adc_data  *data;
-   struct device   *dev;
struct input_dev*input;
void __iomem*regs;
struct regmap   *pmu_map;
@@ -173,11 +172,12 @@ static void exynos_adc_unprepare_clk(struct exynos_adc 
*info)
 
 static int exynos_adc_prepare_clk(struct exynos_adc *info)
 {
+   struct device *dev = regmap_get_device(info->pmu_map);
int ret;
 
ret = clk_prepare(info->clk);
if (ret) {
-   dev_err(info->dev, "failed preparing adc clock: %d\n", ret);
+   dev_err(dev, "failed preparing adc clock: %d\n", ret);
return ret;
}
 
@@ -185,7 +185,7 @@ static int exynos_adc_prepare_clk(struct exynos_adc *info)
ret = clk_prepare(info->sclk);
if (ret) {
clk_unprepare(info->clk);
-   dev_err(info->dev,
+   dev_err(dev,
"failed preparing sclk_adc clock: %d\n", ret);
return ret;
}
@@ -203,11 +203,12 @@ static void exynos_adc_disable_clk(struct exynos_adc 
*info)
 
 static int exynos_adc_enable_clk(struct exynos_adc *info)
 {
+   struct device *dev = regmap_get_device(info->pmu_map);
int ret;
 
ret = clk_enable(info->clk);
if (ret) {
-   dev_err(info->dev, "failed enabling adc clock: %d\n", ret);
+   dev_err(dev, "failed enabling adc clock: %d\n", ret);
return ret;
}
 
@@ -215,7 +216,7 @@ static int exynos_adc_enable_clk(struct exynos_adc *info)
ret = clk_enable(info->sclk);
if (ret) {
clk_disable(info->clk);
-   dev_err(info->dev,
+   dev_err(dev,
"failed enabling sclk_adc clock: %d\n", ret);
return ret;
}
@@ -610,13 +611,14 @@ static irqreturn_t exynos_adc_isr(int irq, void *dev_id)
 static irqreturn_t exynos_ts_isr(int irq, void *dev_id)
 {
struct exynos_adc *info = dev_id;
-   struct iio_dev *dev = dev_get_drvdata(info->dev);
+   struct device *dev = regmap_get_device(info->pmu_map);
+   struct iio_dev *indio_dev = dev_get_drvdata(dev);
u32 x, y;
bool pressed;
int ret;
 
while (info->input->users) {
-   ret = exynos_read_s3c64xx_ts(dev, , );
+   ret = exynos_read_s3c64xx_ts(indio_dev, , );
if (ret == -ETIMEDOUT)
break;
 
@@ -800,8 +802,6 @@ static int exynos_adc_probe(struct platform_device *pdev)
 
info->tsirq = irq;
 
-   info->dev = >dev;
-
init_completion(>completion);
 
info->clk = devm_clk_get(>dev, "adc");
-- 
2.1.4

[RESEND PATCH v2 2/6] dmaengine: vdma: Rename xilinx_vdma_ prefix to xilinx_dma

[Kedareswara rao Appana]

This patch renames the xilinx_vdma_ prefix to xilinx_dma
for the API's and masks that will be shared b/w three DMA
IP cores.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v2:
---> New patch as suggested by Laurent Pinchart.

 drivers/dma/xilinx/xilinx_vdma.c | 636 +++
 1 file changed, 318 insertions(+), 318 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index 3c5ce37..04fd8f5 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -39,106 +39,106 @@
 #include "../dmaengine.h"
 
 /* Register/Descriptor Offsets */
-#define XILINX_VDMA_MM2S_CTRL_OFFSET   0x
-#define XILINX_VDMA_S2MM_CTRL_OFFSET   0x0030
+#define XILINX_DMA_MM2S_CTRL_OFFSET0x
+#define XILINX_DMA_S2MM_CTRL_OFFSET0x0030
 #define XILINX_VDMA_MM2S_DESC_OFFSET   0x0050
 #define XILINX_VDMA_S2MM_DESC_OFFSET   0x00a0
 
 /* Control Registers */
-#define XILINX_VDMA_REG_DMACR  0x
-#define XILINX_VDMA_DMACR_DELAY_MAX0xff
-#define XILINX_VDMA_DMACR_DELAY_SHIFT  24
-#define XILINX_VDMA_DMACR_FRAME_COUNT_MAX  0xff
-#define XILINX_VDMA_DMACR_FRAME_COUNT_SHIFT16
-#define XILINX_VDMA_DMACR_ERR_IRQ  BIT(14)
-#define XILINX_VDMA_DMACR_DLY_CNT_IRQ  BIT(13)
-#define XILINX_VDMA_DMACR_FRM_CNT_IRQ  BIT(12)
-#define XILINX_VDMA_DMACR_MASTER_SHIFT 8
-#define XILINX_VDMA_DMACR_FSYNCSRC_SHIFT   5
-#define XILINX_VDMA_DMACR_FRAMECNT_EN  BIT(4)
-#define XILINX_VDMA_DMACR_GENLOCK_EN   BIT(3)
-#define XILINX_VDMA_DMACR_RESETBIT(2)
-#define XILINX_VDMA_DMACR_CIRC_EN  BIT(1)
-#define XILINX_VDMA_DMACR_RUNSTOP  BIT(0)
-#define XILINX_VDMA_DMACR_FSYNCSRC_MASKGENMASK(6, 5)
-
-#define XILINX_VDMA_REG_DMASR  0x0004
-#define XILINX_VDMA_DMASR_EOL_LATE_ERR BIT(15)
-#define XILINX_VDMA_DMASR_ERR_IRQ  BIT(14)
-#define XILINX_VDMA_DMASR_DLY_CNT_IRQ  BIT(13)
-#define XILINX_VDMA_DMASR_FRM_CNT_IRQ  BIT(12)
-#define XILINX_VDMA_DMASR_SOF_LATE_ERR BIT(11)
-#define XILINX_VDMA_DMASR_SG_DEC_ERR   BIT(10)
-#define XILINX_VDMA_DMASR_SG_SLV_ERR   BIT(9)
-#define XILINX_VDMA_DMASR_EOF_EARLY_ERRBIT(8)
-#define XILINX_VDMA_DMASR_SOF_EARLY_ERRBIT(7)
-#define XILINX_VDMA_DMASR_DMA_DEC_ERR  BIT(6)
-#define XILINX_VDMA_DMASR_DMA_SLAVE_ERRBIT(5)
-#define XILINX_VDMA_DMASR_DMA_INT_ERR  BIT(4)
-#define XILINX_VDMA_DMASR_IDLE BIT(1)
-#define XILINX_VDMA_DMASR_HALTED   BIT(0)
-#define XILINX_VDMA_DMASR_DELAY_MASK   GENMASK(31, 24)
-#define XILINX_VDMA_DMASR_FRAME_COUNT_MASK GENMASK(23, 16)
-
-#define XILINX_VDMA_REG_CURDESC0x0008
-#define XILINX_VDMA_REG_TAILDESC   0x0010
-#define XILINX_VDMA_REG_REG_INDEX  0x0014
-#define XILINX_VDMA_REG_FRMSTORE   0x0018
-#define XILINX_VDMA_REG_THRESHOLD  0x001c
-#define XILINX_VDMA_REG_FRMPTR_STS 0x0024
-#define XILINX_VDMA_REG_PARK_PTR   0x0028
-#define XILINX_VDMA_PARK_PTR_WR_REF_SHIFT  8
-#define XILINX_VDMA_PARK_PTR_RD_REF_SHIFT  0
-#define XILINX_VDMA_REG_VDMA_VERSION   0x002c
+#define XILINX_DMA_REG_DMACR   0x
+#define XILINX_DMA_DMACR_DELAY_MAX 0xff
+#define XILINX_DMA_DMACR_DELAY_SHIFT   24
+#define XILINX_DMA_DMACR_FRAME_COUNT_MAX   0xff
+#define XILINX_DMA_DMACR_FRAME_COUNT_SHIFT 16
+#define XILINX_DMA_DMACR_ERR_IRQ   BIT(14)
+#define XILINX_DMA_DMACR_DLY_CNT_IRQ   BIT(13)
+#define XILINX_DMA_DMACR_FRM_CNT_IRQ   BIT(12)
+#define XILINX_DMA_DMACR_MASTER_SHIFT  8
+#define XILINX_DMA_DMACR_FSYNCSRC_SHIFT5
+#define XILINX_DMA_DMACR_FRAMECNT_EN   BIT(4)
+#define XILINX_DMA_DMACR_GENLOCK_ENBIT(3)
+#define XILINX_DMA_DMACR_RESET BIT(2)
+#define XILINX_DMA_DMACR_CIRC_EN   BIT(1)
+#define XILINX_DMA_DMACR_RUNSTOP   BIT(0)
+#define XILINX_DMA_DMACR_FSYNCSRC_MASK GENMASK(6, 5)
+
+#define XILINX_DMA_REG_DMASR   0x0004
+#define XILINX_DMA_DMASR_EOL_LATE_ERR  BIT(15)
+#define XILINX_DMA_DMASR_ERR_IRQ   BIT(14)
+#define XILINX_DMA_DMASR_DLY_CNT_IRQ   BIT(13)
+#define XILINX_DMA_DMASR_FRM_CNT_IRQ   BIT(12)
+#define XILINX_DMA_DMASR_SOF_LATE_ERR  BIT(11)
+#define XILINX_DMA_DMASR_SG_DEC_ERRBIT(10)
+#define XILINX_DMA_DMASR_SG_SLV_ERRBIT(9)
+#define XILINX_DMA_DMASR_EOF_EARLY_ERR BIT(8)
+#define XILINX_DMA_DMASR_SOF_EARLY_ERR BIT(7)
+#define XILINX_DMA_DMASR_DMA_DEC_ERR   BIT(6)
+#define XILINX_DMA_DMASR_DMA_SLAVE_ERR BIT(5)
+#define XILINX_DMA_DMASR_DMA_INT_ERR  

[RESEND PATCH v2 1/6] dmaengine: vdma: Fix checkpatch.pl warnings

[Kedareswara rao Appana]

This patch fixes the below checkpatch.pl warnings.

WARNING: void function return statements are not generally useful
+   return;
+}

WARNING: void function return statements are not generally useful
+   return;
+}

WARNING: Missing a blank line after declarations
+   u32 errors = status & XILINX_VDMA_DMASR_ALL_ERR_MASK;
+   vdma_ctrl_write(chan, XILINX_VDMA_REG_DMASR,

Acked-by: Laurent Pinchart 
Acked-by: Moritz Fischer 
Signed-off-by: Kedareswara rao Appana 
---
Changes for v2:
---> None.

 drivers/dma/xilinx/xilinx_vdma.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index b873d98..3c5ce37 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -597,8 +597,6 @@ static void xilinx_vdma_halt(struct xilinx_vdma_chan *chan)
chan, vdma_ctrl_read(chan, XILINX_VDMA_REG_DMASR));
chan->err = true;
}
-
-   return;
 }
 
 /**
@@ -623,8 +621,6 @@ static void xilinx_vdma_start(struct xilinx_vdma_chan *chan)
 
chan->err = true;
}
-
-   return;
 }
 
 /**
@@ -874,6 +870,7 @@ static irqreturn_t xilinx_vdma_irq_handler(int irq, void 
*data)
 * make sure not to write to other error bits to 1.
 */
u32 errors = status & XILINX_VDMA_DMASR_ALL_ERR_MASK;
+
vdma_ctrl_write(chan, XILINX_VDMA_REG_DMASR,
errors & XILINX_VDMA_DMASR_ERR_RECOVER_MASK);
 
-- 
2.1.2

[PATCH 0/9] iio: use regmap to retrieve struct device

[Alison Schofield]

These drivers include both struct regmap and struct device in their
global data.  Remove the redundant copy by deleting struct device 
from the drivers global data and using regmap API to retrieve when
needed.

This patchset removes all such redundancies in drivers/iio/.

Patches created using Coccinelle plus hand edits for whitespace and
one local var naming collision.

Alison Schofield (9):
  iio: adc: exynos_adc: use regmap to retrieve struct device
  iio: adc: qcom-spmi-iadc: use regmap to retrieve struct device
  iio: adc: qcom-spmi-vadc: use regmap to retrieve struct device
  iio: accel: bmc150: use regmap to retrieve struct device
  iio: accel: mma7455: use regmap to retrieve struct device
  iio: accel: mxc4005: use regmap to retrieve struct device
  iio: health: afe4403: use regmap to retrieve struct device
  iio: health: afe4404: use regmap to retrieve struct device
  iio: gyro: bmg160_core: use regmap to retrieve struct device

 drivers/iio/accel/bmc150-accel-core.c | 99 +++
 drivers/iio/accel/mma7455_core.c  |  5 +-
 drivers/iio/accel/mxc4005.c   | 26 +
 drivers/iio/adc/exynos_adc.c  | 18 +++
 drivers/iio/adc/qcom-spmi-iadc.c  | 32 +--
 drivers/iio/adc/qcom-spmi-vadc.c  | 37 +++--
 drivers/iio/gyro/bmg160_core.c| 86 +++---
 drivers/iio/health/afe4403.c  | 36 ++---
 drivers/iio/health/afe4404.c  | 38 +++---
 9 files changed, 197 insertions(+), 180 deletions(-)

-- 
2.1.4

[RESEND PATCH v3 2/2] dmaengine: vdma: Fix race condition in Non-SG mode

[Kedareswara rao Appana]

When VDMA is configured in  Non-sg mode
Users can queue descriptors greater than h/w configured frames.

Current driver allows the user to queue descriptors upto h/w configured.
Which is wrong for non-sg mode configuration.

This patch fixes this issue.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v3:
---> New patch.

 drivers/dma/xilinx/xilinx_vdma.c | 25 +++--
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index abe915c..b873d98 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -209,6 +209,7 @@ struct xilinx_vdma_tx_descriptor {
  * @flush_on_fsync: Flush on Frame sync
  * @desc_pendingcount: Descriptor pending count
  * @ext_addr: Indicates 64 bit addressing is supported by dma channel
+ * @desc_submitcount: Descriptor h/w submitted count
  */
 struct xilinx_vdma_chan {
struct xilinx_vdma_device *xdev;
@@ -233,6 +234,7 @@ struct xilinx_vdma_chan {
bool flush_on_fsync;
u32 desc_pendingcount;
bool ext_addr;
+   u32 desc_submitcount;
 };
 
 /**
@@ -716,9 +718,10 @@ static void xilinx_vdma_start_transfer(struct 
xilinx_vdma_chan *chan)
struct xilinx_vdma_tx_segment *segment, *last = NULL;
int i = 0;
 
-   list_for_each_entry(desc, >pending_list, node) {
-   segment = list_first_entry(>segments,
-  struct xilinx_vdma_tx_segment, node);
+   if (chan->desc_submitcount < chan->num_frms)
+   i = chan->desc_submitcount;
+
+   list_for_each_entry(segment, >segments, node) {
if (chan->ext_addr)
vdma_desc_write_64(chan,
XILINX_VDMA_REG_START_ADDRESS_64(i++),
@@ -742,8 +745,17 @@ static void xilinx_vdma_start_transfer(struct 
xilinx_vdma_chan *chan)
vdma_desc_write(chan, XILINX_VDMA_REG_VSIZE, last->hw.vsize);
}
 
-   list_splice_tail_init(>pending_list, >active_list);
-   chan->desc_pendingcount = 0;
+   if (!chan->has_sg) {
+   list_del(>node);
+   list_add_tail(>node, >active_list);
+   chan->desc_submitcount++;
+   chan->desc_pendingcount--;
+   if (chan->desc_submitcount == chan->num_frms)
+   chan->desc_submitcount = 0;
+   } else {
+   list_splice_tail_init(>pending_list, >active_list);
+   chan->desc_pendingcount = 0;
+   }
 }
 
 /**
@@ -927,7 +939,8 @@ append:
list_add_tail(>node, >pending_list);
chan->desc_pendingcount++;
 
-   if (unlikely(chan->desc_pendingcount > chan->num_frms)) {
+   if (chan->has_sg &&
+   unlikely(chan->desc_pendingcount > chan->num_frms)) {
dev_dbg(chan->dev, "desc pendingcount is too high\n");
chan->desc_pendingcount = chan->num_frms;
}
-- 
2.1.2

RE: [PATCH v3 2/2] dmaengine: vdma: Fix race condition in Non-SG mode

[Appana Durga Kedareswara Rao]

Hi Vinod,

> -Original Message-
> From: Vinod Koul [mailto:vinod.k...@intel.com]
> Sent: Wednesday, April 06, 2016 3:23 AM
> To: Appana Durga Kedareswara Rao 
> Cc: dan.j.willi...@intel.com; Michal Simek ; Soren
> Brinkmann ; Appana Durga Kedareswara Rao
> ; moritz.fisc...@ettus.com;
> laurent.pinch...@ideasonboard.com; l...@debethencourt.com; Srikanth
> Vemula ; Anirudha Sarangi ;
> dmaeng...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH v3 2/2] dmaengine: vdma: Fix race condition in Non-SG
> mode
> 
> On Fri, Mar 25, 2016 at 02:46:39PM +0530, Kedareswara rao Appana wrote:
> > When VDMA is configured in  Non-sg mode Users can queue descriptors
> > greater than h/w configured frames.
> >
> > Current driver allows the user to queue descriptors upto h/w configured.
> > Which is wrong for non-sg mode configuration.
> 
> I see to have standalone patch 2, where is 1st patch?
> 
> There seems to be an issue with other 6 patch series with threading broken and
> few patches showing up standalone and not part of series
> 
> Can you resend the whole thing please..

Ok Sure will resend both the patch series again

Regards,
Kedar.

> 
> >
> > This patch fixes this issue.
> >
> > Signed-off-by: Kedareswara rao Appana 
> > ---
> > Changes for v3:
> > ---> New patch.
> >
> >  drivers/dma/xilinx/xilinx_vdma.c | 25 +++--
> >  1 file changed, 19 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/dma/xilinx/xilinx_vdma.c
> > b/drivers/dma/xilinx/xilinx_vdma.c
> > index abe915c..b873d98 100644
> > --- a/drivers/dma/xilinx/xilinx_vdma.c
> > +++ b/drivers/dma/xilinx/xilinx_vdma.c
> > @@ -209,6 +209,7 @@ struct xilinx_vdma_tx_descriptor {
> >   * @flush_on_fsync: Flush on Frame sync
> >   * @desc_pendingcount: Descriptor pending count
> >   * @ext_addr: Indicates 64 bit addressing is supported by dma channel
> > + * @desc_submitcount: Descriptor h/w submitted count
> >   */
> >  struct xilinx_vdma_chan {
> > struct xilinx_vdma_device *xdev;
> > @@ -233,6 +234,7 @@ struct xilinx_vdma_chan {
> > bool flush_on_fsync;
> > u32 desc_pendingcount;
> > bool ext_addr;
> > +   u32 desc_submitcount;
> >  };
> >
> >  /**
> > @@ -716,9 +718,10 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_vdma_chan *chan)
> > struct xilinx_vdma_tx_segment *segment, *last = NULL;
> > int i = 0;
> >
> > -   list_for_each_entry(desc, >pending_list, node) {
> > -   segment = list_first_entry(>segments,
> > -  struct xilinx_vdma_tx_segment,
> node);
> > +   if (chan->desc_submitcount < chan->num_frms)
> > +   i = chan->desc_submitcount;
> > +
> > +   list_for_each_entry(segment, >segments, node) {
> > if (chan->ext_addr)
> > vdma_desc_write_64(chan,
> >
>   XILINX_VDMA_REG_START_ADDRESS_64(i++),
> > @@ -742,8 +745,17 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_vdma_chan *chan)
> > vdma_desc_write(chan, XILINX_VDMA_REG_VSIZE, last-
> >hw.vsize);
> > }
> >
> > -   list_splice_tail_init(>pending_list, >active_list);
> > -   chan->desc_pendingcount = 0;
> > +   if (!chan->has_sg) {
> > +   list_del(>node);
> > +   list_add_tail(>node, >active_list);
> > +   chan->desc_submitcount++;
> > +   chan->desc_pendingcount--;
> > +   if (chan->desc_submitcount == chan->num_frms)
> > +   chan->desc_submitcount = 0;
> > +   } else {
> > +   list_splice_tail_init(>pending_list, >active_list);
> > +   chan->desc_pendingcount = 0;
> > +   }
> >  }
> >
> >  /**
> > @@ -927,7 +939,8 @@ append:
> > list_add_tail(>node, >pending_list);
> > chan->desc_pendingcount++;
> >
> > -   if (unlikely(chan->desc_pendingcount > chan->num_frms)) {
> > +   if (chan->has_sg &&
> > +   unlikely(chan->desc_pendingcount > chan->num_frms)) {
> > dev_dbg(chan->dev, "desc pendingcount is too high\n");
> > chan->desc_pendingcount = chan->num_frms;
> > }
> > --
> > 2.1.2
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe dmaengine"
> > in the body of a message to majord...@vger.kernel.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> ~Vinod

[RESEND PATCH v3 1/2] dmaengine: vdma: Add 64 bit addressing support to the driver

[Kedareswara rao Appana]

This VDMA  is a soft ip, which can be programmed to support
32 bit addressing or greater than 32 bit addressing.

When the VDMA ip is configured for 32 bit address space
the buffer address is specified by a single register
(0x5C for MM2S and 0xAC for S2MM channel).

When the  VDMA core is configured for an address space greater
than 32 then each buffer address is specified by a combination of
two registers.

The first register specifies the LSB 32 bits of address,
while the next register specifies the MSB 32 bits of address.

For example, 5Ch will specify the LSB 32 bits while 60h will
specify the MSB 32 bits of the first start address.
So we need to program two registers at a time.

This patch adds the 64 bit addressing support to the vdma driver.

Signed-off-by: Anurag Kumar Vulisha 
Signed-off-by: Kedareswara rao Appana 
---
Changes for v3:
--> Improved commit message as suggested by vinod.
--> removed unnecessary braces for single line if conditions.
Changes for v2:
---> Added dma-ranges property in device tree as suggested by Arnd Bergmann.
---> Added device tree property(xlnx,addrwidth) for an identification of whether
 the IP block itself is configured in 64-bit or 32-bit mode as suggested by
 Laurent Pinchart.
---> Modified the driver code based on the xlnx,addrwidth.

 .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt |  4 ++
 drivers/dma/Kconfig|  2 +-
 drivers/dma/xilinx/xilinx_vdma.c   | 73 +++---
 3 files changed, 70 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
index e4c4d47..a86737c 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
@@ -8,6 +8,8 @@ Required properties:
 - #dma-cells: Should be <1>, see "dmas" property below
 - reg: Should contain VDMA registers location and length.
 - xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
+- xlnx,addrwidth: Should be the vdma addressing size in bits(ex: 32 bits).
+- dma-ranges: Should be as the following .
 - dma-channel child node: Should have at least one channel and can have up to
two channels per device. This node specifies the properties of each
DMA channel (see child node properties below).
@@ -41,8 +43,10 @@ axi_vdma_0: axivdma@4003 {
compatible = "xlnx,axi-vdma-1.00.a";
#dma_cells = <1>;
reg = < 0x4003 0x1 >;
+   dma-ranges = <0x 0x 0x4000>;
xlnx,num-fstores = <0x8>;
xlnx,flush-fsync = <0x1>;
+   xlnx,addrwidth = <0x20>;
dma-channel@4003 {
compatible = "xlnx,axi-vdma-mm2s-channel";
interrupts = < 0 54 4 >;
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index d96d87c..2846753 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -507,7 +507,7 @@ config XGENE_DMA
 
 config XILINX_VDMA
tristate "Xilinx AXI VDMA Engine"
-   depends on (ARCH_ZYNQ || MICROBLAZE)
+   depends on (ARCH_ZYNQ || MICROBLAZE || ARM64)
select DMA_ENGINE
help
  Enable support for Xilinx AXI VDMA Soft IP.
diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index 0ee0321..abe915c 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -100,6 +100,7 @@
 #define XILINX_VDMA_FRMDLY_STRIDE_STRIDE_SHIFT 0
 
 #define XILINX_VDMA_REG_START_ADDRESS(n)   (0x000c + 4 * (n))
+#define XILINX_VDMA_REG_START_ADDRESS_64(n)(0x000c + 8 * (n))
 
 /* HW specific definitions */
 #define XILINX_VDMA_MAX_CHANS_PER_DEVICE   0x2
@@ -144,7 +145,7 @@
  * @next_desc: Next Descriptor Pointer @0x00
  * @pad1: Reserved @0x04
  * @buf_addr: Buffer address @0x08
- * @pad2: Reserved @0x0C
+ * @buf_addr_msb: MSB of Buffer address @0x0C
  * @vsize: Vertical Size @0x10
  * @hsize: Horizontal Size @0x14
  * @stride: Number of bytes between the first
@@ -154,7 +155,7 @@ struct xilinx_vdma_desc_hw {
u32 next_desc;
u32 pad1;
u32 buf_addr;
-   u32 pad2;
+   u32 buf_addr_msb;
u32 vsize;
u32 hsize;
u32 stride;
@@ -207,6 +208,7 @@ struct xilinx_vdma_tx_descriptor {
  * @config: Device configuration info
  * @flush_on_fsync: Flush on Frame sync
  * @desc_pendingcount: Descriptor pending count
+ * @ext_addr: Indicates 64 bit addressing is supported by dma channel
  */
 struct xilinx_vdma_chan {
struct xilinx_vdma_device *xdev;
@@ -230,6 +232,7 @@ struct xilinx_vdma_chan {
struct xilinx_vdma_config config;
bool flush_on_fsync;
u32 desc_pendingcount;
+   bool ext_addr;
 };
 
 /**
@@ -240,6 +243,7 @@ struct xilinx_vdma_chan {
  * @chan: Driver specific VDMA channel
  * @has_sg: Specifies whether Scatter-Gather is 

[RESEND PATCH v3 2/2] dmaengine: vdma: Fix race condition in Non-SG mode

[Kedareswara rao Appana]

When VDMA is configured in  Non-sg mode
Users can queue descriptors greater than h/w configured frames.

Current driver allows the user to queue descriptors upto h/w configured.
Which is wrong for non-sg mode configuration.

This patch fixes this issue.

Signed-off-by: Kedareswara rao Appana 
---
Changes for v3:
---> New patch.

 drivers/dma/xilinx/xilinx_vdma.c | 25 +++--
 1 file changed, 19 insertions(+), 6 deletions(-)

diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index abe915c..b873d98 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -209,6 +209,7 @@ struct xilinx_vdma_tx_descriptor {
  * @flush_on_fsync: Flush on Frame sync
  * @desc_pendingcount: Descriptor pending count
  * @ext_addr: Indicates 64 bit addressing is supported by dma channel
+ * @desc_submitcount: Descriptor h/w submitted count
  */
 struct xilinx_vdma_chan {
struct xilinx_vdma_device *xdev;
@@ -233,6 +234,7 @@ struct xilinx_vdma_chan {
bool flush_on_fsync;
u32 desc_pendingcount;
bool ext_addr;
+   u32 desc_submitcount;
 };
 
 /**
@@ -716,9 +718,10 @@ static void xilinx_vdma_start_transfer(struct 
xilinx_vdma_chan *chan)
struct xilinx_vdma_tx_segment *segment, *last = NULL;
int i = 0;
 
-   list_for_each_entry(desc, >pending_list, node) {
-   segment = list_first_entry(>segments,
-  struct xilinx_vdma_tx_segment, node);
+   if (chan->desc_submitcount < chan->num_frms)
+   i = chan->desc_submitcount;
+
+   list_for_each_entry(segment, >segments, node) {
if (chan->ext_addr)
vdma_desc_write_64(chan,
XILINX_VDMA_REG_START_ADDRESS_64(i++),
@@ -742,8 +745,17 @@ static void xilinx_vdma_start_transfer(struct 
xilinx_vdma_chan *chan)
vdma_desc_write(chan, XILINX_VDMA_REG_VSIZE, last->hw.vsize);
}
 
-   list_splice_tail_init(>pending_list, >active_list);
-   chan->desc_pendingcount = 0;
+   if (!chan->has_sg) {
+   list_del(>node);
+   list_add_tail(>node, >active_list);
+   chan->desc_submitcount++;
+   chan->desc_pendingcount--;
+   if (chan->desc_submitcount == chan->num_frms)
+   chan->desc_submitcount = 0;
+   } else {
+   list_splice_tail_init(>pending_list, >active_list);
+   chan->desc_pendingcount = 0;
+   }
 }
 
 /**
@@ -927,7 +939,8 @@ append:
list_add_tail(>node, >pending_list);
chan->desc_pendingcount++;
 
-   if (unlikely(chan->desc_pendingcount > chan->num_frms)) {
+   if (chan->has_sg &&
+   unlikely(chan->desc_pendingcount > chan->num_frms)) {
dev_dbg(chan->dev, "desc pendingcount is too high\n");
chan->desc_pendingcount = chan->num_frms;
}
-- 
2.1.2

RE: [PATCH v3 2/2] dmaengine: vdma: Fix race condition in Non-SG mode

[Appana Durga Kedareswara Rao]

Hi Vinod,

> -Original Message-
> From: Vinod Koul [mailto:vinod.k...@intel.com]
> Sent: Wednesday, April 06, 2016 3:23 AM
> To: Appana Durga Kedareswara Rao 
> Cc: dan.j.willi...@intel.com; Michal Simek ; Soren
> Brinkmann ; Appana Durga Kedareswara Rao
> ; moritz.fisc...@ettus.com;
> laurent.pinch...@ideasonboard.com; l...@debethencourt.com; Srikanth
> Vemula ; Anirudha Sarangi ;
> dmaeng...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-
> ker...@vger.kernel.org
> Subject: Re: [PATCH v3 2/2] dmaengine: vdma: Fix race condition in Non-SG
> mode
> 
> On Fri, Mar 25, 2016 at 02:46:39PM +0530, Kedareswara rao Appana wrote:
> > When VDMA is configured in  Non-sg mode Users can queue descriptors
> > greater than h/w configured frames.
> >
> > Current driver allows the user to queue descriptors upto h/w configured.
> > Which is wrong for non-sg mode configuration.
> 
> I see to have standalone patch 2, where is 1st patch?
> 
> There seems to be an issue with other 6 patch series with threading broken and
> few patches showing up standalone and not part of series
> 
> Can you resend the whole thing please..

Ok Sure will resend both the patch series again

Regards,
Kedar.

> 
> >
> > This patch fixes this issue.
> >
> > Signed-off-by: Kedareswara rao Appana 
> > ---
> > Changes for v3:
> > ---> New patch.
> >
> >  drivers/dma/xilinx/xilinx_vdma.c | 25 +++--
> >  1 file changed, 19 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/dma/xilinx/xilinx_vdma.c
> > b/drivers/dma/xilinx/xilinx_vdma.c
> > index abe915c..b873d98 100644
> > --- a/drivers/dma/xilinx/xilinx_vdma.c
> > +++ b/drivers/dma/xilinx/xilinx_vdma.c
> > @@ -209,6 +209,7 @@ struct xilinx_vdma_tx_descriptor {
> >   * @flush_on_fsync: Flush on Frame sync
> >   * @desc_pendingcount: Descriptor pending count
> >   * @ext_addr: Indicates 64 bit addressing is supported by dma channel
> > + * @desc_submitcount: Descriptor h/w submitted count
> >   */
> >  struct xilinx_vdma_chan {
> > struct xilinx_vdma_device *xdev;
> > @@ -233,6 +234,7 @@ struct xilinx_vdma_chan {
> > bool flush_on_fsync;
> > u32 desc_pendingcount;
> > bool ext_addr;
> > +   u32 desc_submitcount;
> >  };
> >
> >  /**
> > @@ -716,9 +718,10 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_vdma_chan *chan)
> > struct xilinx_vdma_tx_segment *segment, *last = NULL;
> > int i = 0;
> >
> > -   list_for_each_entry(desc, >pending_list, node) {
> > -   segment = list_first_entry(>segments,
> > -  struct xilinx_vdma_tx_segment,
> node);
> > +   if (chan->desc_submitcount < chan->num_frms)
> > +   i = chan->desc_submitcount;
> > +
> > +   list_for_each_entry(segment, >segments, node) {
> > if (chan->ext_addr)
> > vdma_desc_write_64(chan,
> >
>   XILINX_VDMA_REG_START_ADDRESS_64(i++),
> > @@ -742,8 +745,17 @@ static void xilinx_vdma_start_transfer(struct
> xilinx_vdma_chan *chan)
> > vdma_desc_write(chan, XILINX_VDMA_REG_VSIZE, last-
> >hw.vsize);
> > }
> >
> > -   list_splice_tail_init(>pending_list, >active_list);
> > -   chan->desc_pendingcount = 0;
> > +   if (!chan->has_sg) {
> > +   list_del(>node);
> > +   list_add_tail(>node, >active_list);
> > +   chan->desc_submitcount++;
> > +   chan->desc_pendingcount--;
> > +   if (chan->desc_submitcount == chan->num_frms)
> > +   chan->desc_submitcount = 0;
> > +   } else {
> > +   list_splice_tail_init(>pending_list, >active_list);
> > +   chan->desc_pendingcount = 0;
> > +   }
> >  }
> >
> >  /**
> > @@ -927,7 +939,8 @@ append:
> > list_add_tail(>node, >pending_list);
> > chan->desc_pendingcount++;
> >
> > -   if (unlikely(chan->desc_pendingcount > chan->num_frms)) {
> > +   if (chan->has_sg &&
> > +   unlikely(chan->desc_pendingcount > chan->num_frms)) {
> > dev_dbg(chan->dev, "desc pendingcount is too high\n");
> > chan->desc_pendingcount = chan->num_frms;
> > }
> > --
> > 2.1.2
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe dmaengine"
> > in the body of a message to majord...@vger.kernel.org More majordomo
> > info at  http://vger.kernel.org/majordomo-info.html
> 
> --
> ~Vinod

[RESEND PATCH v3 1/2] dmaengine: vdma: Add 64 bit addressing support to the driver

[Kedareswara rao Appana]

This VDMA  is a soft ip, which can be programmed to support
32 bit addressing or greater than 32 bit addressing.

When the VDMA ip is configured for 32 bit address space
the buffer address is specified by a single register
(0x5C for MM2S and 0xAC for S2MM channel).

When the  VDMA core is configured for an address space greater
than 32 then each buffer address is specified by a combination of
two registers.

The first register specifies the LSB 32 bits of address,
while the next register specifies the MSB 32 bits of address.

For example, 5Ch will specify the LSB 32 bits while 60h will
specify the MSB 32 bits of the first start address.
So we need to program two registers at a time.

This patch adds the 64 bit addressing support to the vdma driver.

Signed-off-by: Anurag Kumar Vulisha 
Signed-off-by: Kedareswara rao Appana 
---
Changes for v3:
--> Improved commit message as suggested by vinod.
--> removed unnecessary braces for single line if conditions.
Changes for v2:
---> Added dma-ranges property in device tree as suggested by Arnd Bergmann.
---> Added device tree property(xlnx,addrwidth) for an identification of whether
 the IP block itself is configured in 64-bit or 32-bit mode as suggested by
 Laurent Pinchart.
---> Modified the driver code based on the xlnx,addrwidth.

 .../devicetree/bindings/dma/xilinx/xilinx_vdma.txt |  4 ++
 drivers/dma/Kconfig|  2 +-
 drivers/dma/xilinx/xilinx_vdma.c   | 73 +++---
 3 files changed, 70 insertions(+), 9 deletions(-)

diff --git a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt 
b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
index e4c4d47..a86737c 100644
--- a/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
+++ b/Documentation/devicetree/bindings/dma/xilinx/xilinx_vdma.txt
@@ -8,6 +8,8 @@ Required properties:
 - #dma-cells: Should be <1>, see "dmas" property below
 - reg: Should contain VDMA registers location and length.
 - xlnx,num-fstores: Should be the number of framebuffers as configured in h/w.
+- xlnx,addrwidth: Should be the vdma addressing size in bits(ex: 32 bits).
+- dma-ranges: Should be as the following .
 - dma-channel child node: Should have at least one channel and can have up to
two channels per device. This node specifies the properties of each
DMA channel (see child node properties below).
@@ -41,8 +43,10 @@ axi_vdma_0: axivdma@4003 {
compatible = "xlnx,axi-vdma-1.00.a";
#dma_cells = <1>;
reg = < 0x4003 0x1 >;
+   dma-ranges = <0x 0x 0x4000>;
xlnx,num-fstores = <0x8>;
xlnx,flush-fsync = <0x1>;
+   xlnx,addrwidth = <0x20>;
dma-channel@4003 {
compatible = "xlnx,axi-vdma-mm2s-channel";
interrupts = < 0 54 4 >;
diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index d96d87c..2846753 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -507,7 +507,7 @@ config XGENE_DMA
 
 config XILINX_VDMA
tristate "Xilinx AXI VDMA Engine"
-   depends on (ARCH_ZYNQ || MICROBLAZE)
+   depends on (ARCH_ZYNQ || MICROBLAZE || ARM64)
select DMA_ENGINE
help
  Enable support for Xilinx AXI VDMA Soft IP.
diff --git a/drivers/dma/xilinx/xilinx_vdma.c b/drivers/dma/xilinx/xilinx_vdma.c
index 0ee0321..abe915c 100644
--- a/drivers/dma/xilinx/xilinx_vdma.c
+++ b/drivers/dma/xilinx/xilinx_vdma.c
@@ -100,6 +100,7 @@
 #define XILINX_VDMA_FRMDLY_STRIDE_STRIDE_SHIFT 0
 
 #define XILINX_VDMA_REG_START_ADDRESS(n)   (0x000c + 4 * (n))
+#define XILINX_VDMA_REG_START_ADDRESS_64(n)(0x000c + 8 * (n))
 
 /* HW specific definitions */
 #define XILINX_VDMA_MAX_CHANS_PER_DEVICE   0x2
@@ -144,7 +145,7 @@
  * @next_desc: Next Descriptor Pointer @0x00
  * @pad1: Reserved @0x04
  * @buf_addr: Buffer address @0x08
- * @pad2: Reserved @0x0C
+ * @buf_addr_msb: MSB of Buffer address @0x0C
  * @vsize: Vertical Size @0x10
  * @hsize: Horizontal Size @0x14
  * @stride: Number of bytes between the first
@@ -154,7 +155,7 @@ struct xilinx_vdma_desc_hw {
u32 next_desc;
u32 pad1;
u32 buf_addr;
-   u32 pad2;
+   u32 buf_addr_msb;
u32 vsize;
u32 hsize;
u32 stride;
@@ -207,6 +208,7 @@ struct xilinx_vdma_tx_descriptor {
  * @config: Device configuration info
  * @flush_on_fsync: Flush on Frame sync
  * @desc_pendingcount: Descriptor pending count
+ * @ext_addr: Indicates 64 bit addressing is supported by dma channel
  */
 struct xilinx_vdma_chan {
struct xilinx_vdma_device *xdev;
@@ -230,6 +232,7 @@ struct xilinx_vdma_chan {
struct xilinx_vdma_config config;
bool flush_on_fsync;
u32 desc_pendingcount;
+   bool ext_addr;
 };
 
 /**
@@ -240,6 +243,7 @@ struct xilinx_vdma_chan {
  * @chan: Driver specific VDMA channel
  * @has_sg: Specifies whether Scatter-Gather is present or not
  * @flush_on_fsync: Flush on 

Re: [PATCH 2/2] qcom: ipq4019: Add LDO regulator driver for SDHC controller

[Sreedhar Sambangi]

On 2016-04-04 22:53, Andy Gross wrote:

On Mon, Apr 04, 2016 at 02:08:24PM -0700, Sreedhar Sambangi wrote:

From: Kirthik Srinivasan 

Add LDO regulator driver to enable SD /MMC  card to
switch between 3.0 volts and 1.8 volts

Change-Id: I66f770878570b1f5b1db044ba626e0f6989acc3f
Signed-off-by: Kirthik Srinivasan 
Signed-off-by: Rajith Cherian 
Signed-off-by: Sreedhar Sambangi 
---
 drivers/regulator/Kconfig |   7 +
 drivers/regulator/Makefile|   1 +
 drivers/regulator/ipq4019-regulator.c | 275 
++


It'd be good to have the file name have qcom prepended.  See the other 
qcom

regulators as an example.


Sure, but is it reasonable to say qcom_ipq4019-regulator ? Since as of 
now ,this regulator driver is supporting only ipq4019 SOC.





 3 files changed, 283 insertions(+)
 create mode 100644 drivers/regulator/ipq4019-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index c77dc08..bb44873 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -843,5 +843,12 @@ config REGULATOR_WM8994
  This driver provides support for the voltage regulators on the
  WM8994 CODEC.

+config REGULATOR_IPQ4019


How bout REGULATOR_QCOM_IPQ4019.


Sounds good, Will update in V2


+   tristate "IPQ4019 regulator support"
+   depends on ARCH_QCOM
+   help
+ This driver provides support for the voltage regulators of the
+ IPQ40xx devices.
+
 endif






+static int ipq4019_regulator_set_voltage(struct regulator_dev *dev,
+   int min_uV, int max_uV,
+   unsigned *selector)
+{
+   struct ipq4019_regulator_data *data = rdev_get_drvdata(dev);
+   struct ipq4019_regulator_config *cfg = data->config;
+
+   int ptr, best_val = INT_MAX, val;
+
+   for (ptr = 0; ptr < cfg->nr_states; ptr++)
+   if (cfg->states[ptr].range < best_val &&
+   cfg->states[ptr].range >= min_uV &&
+   cfg->states[ptr].range <= max_uV) {
+   best_val = cfg->states[ptr].value;
+   if (selector)
+   *selector = ptr;
+   }
+
+   if (best_val == INT_MAX)
+   return -EINVAL;
+
+   val = readl(cfg->base);
+   val  = val & (~(cfg->mask));


val &= mask


Thank you, Will fix this




+   writel((val | best_val), cfg->base);
+
+   data->range = cfg->states[ptr].range;
+
+   return 0;
+}
+
+static int ipq4019_regulator_list_voltage(struct regulator_dev *dev,
+ unsigned selector)
+{
+   struct ipq4019_regulator_data *data = rdev_get_drvdata(dev);
+   struct ipq4019_regulator_config *cfg = data->config;
+
+   if (selector >= cfg->nr_states)
+   return -EINVAL;
+
+   return cfg->states[selector].range;


If you can define your ranges using LINEAR_RANGE, you can just use the
regulator_list_voltage_linear_range.
Since we are supporting only two states , haven't gone through the 
approach of LINEAR_RANGE.but sure will look in to it.





+}
+
+static struct regulator_ops ipq4019_regulator_voltage_ops = {
+   .get_voltage = ipq4019_regulator_get_voltage,
+   .set_voltage = ipq4019_regulator_set_voltage,
+   .list_voltage = ipq4019_regulator_list_voltage,


No enable and disable?


There is no such states like enable and disable.



+};
+
+static struct ipq4019_regulator_config *
+of_get_ipq4019_regulator_data(struct device *dev, struct device_node 
*np, const struct regulator_desc *desc)

+{
+   struct ipq4019_regulator_config *config;
+   struct property *prop;
+   int proplen, i;
+
+   config = devm_kzalloc(dev,
+   sizeof(struct ipq4019_regulator_config),
+   GFP_KERNEL);
+   if (!config)
+   return ERR_PTR(-ENOMEM);
+
+   config->init_data = of_get_regulator_init_data(dev, np, desc);
+   if (!config->init_data)
+   return ERR_PTR(-EINVAL);
+
+   config->supply_name = config->init_data->constraints.name;
+
+
+   /* Fetch states. */
+   prop = of_find_property(np, "states", NULL);
+   if (!prop) {
+   dev_err(dev, "No 'states' property found\n");
+   return ERR_PTR(-EINVAL);
+   }
+
+   proplen = prop->length / sizeof(int);
+
+   config->states = devm_kzalloc(dev,
+   sizeof(struct ipq4019_regulator_state)
+   * (proplen / 2),
+   GFP_KERNEL);
+   if (!config->states)
+   return ERR_PTR(-ENOMEM);
+
+   for (i = 0; i < proplen / 2; i++) {
+   config->states[i].range =
+   be32_to_cpup((int *)prop->value + (i * 2));
+   

Re: [PATCH 2/2] qcom: ipq4019: Add LDO regulator driver for SDHC controller

[Sreedhar Sambangi]

On 2016-04-04 22:53, Andy Gross wrote:

On Mon, Apr 04, 2016 at 02:08:24PM -0700, Sreedhar Sambangi wrote:

From: Kirthik Srinivasan 

Add LDO regulator driver to enable SD /MMC  card to
switch between 3.0 volts and 1.8 volts

Change-Id: I66f770878570b1f5b1db044ba626e0f6989acc3f
Signed-off-by: Kirthik Srinivasan 
Signed-off-by: Rajith Cherian 
Signed-off-by: Sreedhar Sambangi 
---
 drivers/regulator/Kconfig |   7 +
 drivers/regulator/Makefile|   1 +
 drivers/regulator/ipq4019-regulator.c | 275 
++


It'd be good to have the file name have qcom prepended.  See the other 
qcom

regulators as an example.


Sure, but is it reasonable to say qcom_ipq4019-regulator ? Since as of 
now ,this regulator driver is supporting only ipq4019 SOC.





 3 files changed, 283 insertions(+)
 create mode 100644 drivers/regulator/ipq4019-regulator.c

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index c77dc08..bb44873 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -843,5 +843,12 @@ config REGULATOR_WM8994
  This driver provides support for the voltage regulators on the
  WM8994 CODEC.

+config REGULATOR_IPQ4019


How bout REGULATOR_QCOM_IPQ4019.


Sounds good, Will update in V2


+   tristate "IPQ4019 regulator support"
+   depends on ARCH_QCOM
+   help
+ This driver provides support for the voltage regulators of the
+ IPQ40xx devices.
+
 endif






+static int ipq4019_regulator_set_voltage(struct regulator_dev *dev,
+   int min_uV, int max_uV,
+   unsigned *selector)
+{
+   struct ipq4019_regulator_data *data = rdev_get_drvdata(dev);
+   struct ipq4019_regulator_config *cfg = data->config;
+
+   int ptr, best_val = INT_MAX, val;
+
+   for (ptr = 0; ptr < cfg->nr_states; ptr++)
+   if (cfg->states[ptr].range < best_val &&
+   cfg->states[ptr].range >= min_uV &&
+   cfg->states[ptr].range <= max_uV) {
+   best_val = cfg->states[ptr].value;
+   if (selector)
+   *selector = ptr;
+   }
+
+   if (best_val == INT_MAX)
+   return -EINVAL;
+
+   val = readl(cfg->base);
+   val  = val & (~(cfg->mask));


val &= mask


Thank you, Will fix this




+   writel((val | best_val), cfg->base);
+
+   data->range = cfg->states[ptr].range;
+
+   return 0;
+}
+
+static int ipq4019_regulator_list_voltage(struct regulator_dev *dev,
+ unsigned selector)
+{
+   struct ipq4019_regulator_data *data = rdev_get_drvdata(dev);
+   struct ipq4019_regulator_config *cfg = data->config;
+
+   if (selector >= cfg->nr_states)
+   return -EINVAL;
+
+   return cfg->states[selector].range;


If you can define your ranges using LINEAR_RANGE, you can just use the
regulator_list_voltage_linear_range.
Since we are supporting only two states , haven't gone through the 
approach of LINEAR_RANGE.but sure will look in to it.





+}
+
+static struct regulator_ops ipq4019_regulator_voltage_ops = {
+   .get_voltage = ipq4019_regulator_get_voltage,
+   .set_voltage = ipq4019_regulator_set_voltage,
+   .list_voltage = ipq4019_regulator_list_voltage,


No enable and disable?


There is no such states like enable and disable.



+};
+
+static struct ipq4019_regulator_config *
+of_get_ipq4019_regulator_data(struct device *dev, struct device_node 
*np, const struct regulator_desc *desc)

+{
+   struct ipq4019_regulator_config *config;
+   struct property *prop;
+   int proplen, i;
+
+   config = devm_kzalloc(dev,
+   sizeof(struct ipq4019_regulator_config),
+   GFP_KERNEL);
+   if (!config)
+   return ERR_PTR(-ENOMEM);
+
+   config->init_data = of_get_regulator_init_data(dev, np, desc);
+   if (!config->init_data)
+   return ERR_PTR(-EINVAL);
+
+   config->supply_name = config->init_data->constraints.name;
+
+
+   /* Fetch states. */
+   prop = of_find_property(np, "states", NULL);
+   if (!prop) {
+   dev_err(dev, "No 'states' property found\n");
+   return ERR_PTR(-EINVAL);
+   }
+
+   proplen = prop->length / sizeof(int);
+
+   config->states = devm_kzalloc(dev,
+   sizeof(struct ipq4019_regulator_state)
+   * (proplen / 2),
+   GFP_KERNEL);
+   if (!config->states)
+   return ERR_PTR(-ENOMEM);
+
+   for (i = 0; i < proplen / 2; i++) {
+   config->states[i].range =
+   be32_to_cpup((int *)prop->value + (i * 2));
+   config->states[i].value =
+   be32_to_cpup((int *)prop->value + (i * 2 + 1));
+   }
+  

Re: [PATCH 4/4] irqchip: bcm2836: Use a more generic memory barrier call

[Stephen Warren]

On 04/04/2016 09:44 PM, Eric Anholt wrote:

dsb() requires an argument on arm64, so we needed to add "sy".
Instead, take this opportunity to switch to the same smp_wmb() call
that gic uses for its IPIs.  This is a less strong barrier than we
were doing before (dmb(ishst) compared to dsb(sy)), but it seems to be
the correct one.


I assume all MMIO is part of the ish domain?

If so, the series,
Acked-by: Stephen Warren 

Re: [PATCH 4/4] irqchip: bcm2836: Use a more generic memory barrier call

[Stephen Warren]

On 04/04/2016 09:44 PM, Eric Anholt wrote:

dsb() requires an argument on arm64, so we needed to add "sy".
Instead, take this opportunity to switch to the same smp_wmb() call
that gic uses for its IPIs.  This is a less strong barrier than we
were doing before (dmb(ishst) compared to dsb(sy)), but it seems to be
the correct one.


I assume all MMIO is part of the ish domain?

If so, the series,
Acked-by: Stephen Warren 

Re: [PATCH 1/2] qcom: ipq4019: Add regulator support to DK04 device tree

[Sreedhar Sambangi]

On 2016-04-04 22:59, Andy Gross wrote:

On Mon, Apr 04, 2016 at 02:08:10PM -0700, Sreedhar Sambangi wrote:

This adds the regulator nodes to DK04 device tree to support

Change-Id: I9c1df0e720a330bf6db1889fd2247f6a70ea6faa
Signed-off-by: Sreedhar Sambangi 
---
 .../bindings/regulator/ipq4019-regulator.txt  | 19 
+++
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi | 11 
+++

 2 files changed, 30 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt


diff --git 
a/Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt 
b/Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt

new file mode 100644
index 000..9d934a4
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt

@@ -0,0 +1,19 @@
+* Qualcomm Technologies, Inc. IPQ4019 regulators
+
+Required properties:
+- compatible   : Must be "regulator-ipq4019".
+- states   : Selection of available voltages and corresponding 
values
+- reg  : Register address for controlling LDO
+- mask : Mask value for switching voltages
+Example:


How many LDOs are there on the IPQ4019?  Can you document all of the 
supplies?
You can figure this out by looking for the vdd pins in the chip 
documentation


In this Chip , We only have one Software programmable LDO used for SD 
/eMMC. The other LDO's are with fixed voltage.



+
+   vccq_sd0: regulator@0 {
+   compatible = "qcom,regulator-ipq4019";
+   regulator-name = "SD0 VccQ";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <300>;
+   states = <300 0x3
+   180 0x1>;


So there are only 2 states?  No linear range from 1.8 to 3.3?


Currently this LDO can support [1.5, 1.8, 2.5 and 3] but for the SD / 
eMMC scenario, we use only two states.





+   reg = <0x01948000 0x4>;
+   mask = <0x3>;
+   };


--
-Sree

Re: [PATCH 1/2] qcom: ipq4019: Add regulator support to DK04 device tree

[Sreedhar Sambangi]

On 2016-04-04 22:59, Andy Gross wrote:

On Mon, Apr 04, 2016 at 02:08:10PM -0700, Sreedhar Sambangi wrote:

This adds the regulator nodes to DK04 device tree to support

Change-Id: I9c1df0e720a330bf6db1889fd2247f6a70ea6faa
Signed-off-by: Sreedhar Sambangi 
---
 .../bindings/regulator/ipq4019-regulator.txt  | 19 
+++
 arch/arm/boot/dts/qcom-ipq4019-ap.dk04.1.dtsi | 11 
+++

 2 files changed, 30 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt


diff --git 
a/Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt 
b/Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt

new file mode 100644
index 000..9d934a4
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/regulator/ipq4019-regulator.txt

@@ -0,0 +1,19 @@
+* Qualcomm Technologies, Inc. IPQ4019 regulators
+
+Required properties:
+- compatible   : Must be "regulator-ipq4019".
+- states   : Selection of available voltages and corresponding 
values
+- reg  : Register address for controlling LDO
+- mask : Mask value for switching voltages
+Example:


How many LDOs are there on the IPQ4019?  Can you document all of the 
supplies?
You can figure this out by looking for the vdd pins in the chip 
documentation


In this Chip , We only have one Software programmable LDO used for SD 
/eMMC. The other LDO's are with fixed voltage.



+
+   vccq_sd0: regulator@0 {
+   compatible = "qcom,regulator-ipq4019";
+   regulator-name = "SD0 VccQ";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <300>;
+   states = <300 0x3
+   180 0x1>;


So there are only 2 states?  No linear range from 1.8 to 3.3?


Currently this LDO can support [1.5, 1.8, 2.5 and 3] but for the SD / 
eMMC scenario, we use only two states.





+   reg = <0x01948000 0x4>;
+   mask = <0x3>;
+   };


--
-Sree

Re: [REF PATCH] x86/tlb: just do tlb flush on one of siblings of SMT

[Andy Lutomirski]

On Apr 5, 2016 8:17 PM, "Alex Shi"  wrote:
>
> It seems Intel core still share the TLB pool, flush both of threads' TLB
> just cause a extra useless IPI and a extra flush. The extra flush will
> flush out TLB again which another thread just introduced.
> That's double waste.

Do you have a reference in both the SDM and the APM for this?

Do we have a guarantee that this serialized the front end such that
the non-targetted sibling won't execute an instruction that it decoded
from a stale translation?

This will conflict rather deeply with my PCID series, too.

--Andy

Re: [REF PATCH] x86/tlb: just do tlb flush on one of siblings of SMT

[Andy Lutomirski]

On Apr 5, 2016 8:17 PM, "Alex Shi"  wrote:
>
> It seems Intel core still share the TLB pool, flush both of threads' TLB
> just cause a extra useless IPI and a extra flush. The extra flush will
> flush out TLB again which another thread just introduced.
> That's double waste.

Do you have a reference in both the SDM and the APM for this?

Do we have a guarantee that this serialized the front end such that
the non-targetted sibling won't execute an instruction that it decoded
from a stale translation?

This will conflict rather deeply with my PCID series, too.

--Andy

Re: [PATCH 4/5] devicetree: leds: Introduce "panic-blink" optional property

[Ezequiel Garcia]

On 5 April 2016 at 18:37, Jacek Anaszewski  wrote:
> Hi Ezequiel,
>
> On 04/04/2016 10:22 PM, Ezequiel Garcia wrote:
>>
>> It's desirable to specify which LEDs are to be blinked on a kernel
>> panic. Therefore, introduce a devicetree boolean property to mark
>> which LEDs should be treated this way.
>>
>> Signed-off-by: Ezequiel Garcia 
>> ---
>>   Documentation/devicetree/bindings/leds/common.txt | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/leds/common.txt
>> b/Documentation/devicetree/bindings/leds/common.txt
>> index 68419843e32f..dd409df9203a 100644
>> --- a/Documentation/devicetree/bindings/leds/common.txt
>> +++ b/Documentation/devicetree/bindings/leds/common.txt
>> @@ -37,6 +37,8 @@ Optional properties for child nodes:
>>property is mandatory for the LEDs in the non-flash
>> modes
>>(e.g. torch or indicator).
>>
>> +- panic-blink : Mark this LED to be used by the panic LED trigger.
>
>
> I'd say that 'panic-indicator' would be more informative.
>

Sure, that looks much better.

> Please next time cc also devicetree list and maintainers.
>

Will do.

Thanks for the reviews!
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar

Re: [PATCH 4/5] devicetree: leds: Introduce "panic-blink" optional property

[Ezequiel Garcia]

On 5 April 2016 at 18:37, Jacek Anaszewski  wrote:
> Hi Ezequiel,
>
> On 04/04/2016 10:22 PM, Ezequiel Garcia wrote:
>>
>> It's desirable to specify which LEDs are to be blinked on a kernel
>> panic. Therefore, introduce a devicetree boolean property to mark
>> which LEDs should be treated this way.
>>
>> Signed-off-by: Ezequiel Garcia 
>> ---
>>   Documentation/devicetree/bindings/leds/common.txt | 2 ++
>>   1 file changed, 2 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/leds/common.txt
>> b/Documentation/devicetree/bindings/leds/common.txt
>> index 68419843e32f..dd409df9203a 100644
>> --- a/Documentation/devicetree/bindings/leds/common.txt
>> +++ b/Documentation/devicetree/bindings/leds/common.txt
>> @@ -37,6 +37,8 @@ Optional properties for child nodes:
>>property is mandatory for the LEDs in the non-flash
>> modes
>>(e.g. torch or indicator).
>>
>> +- panic-blink : Mark this LED to be used by the panic LED trigger.
>
>
> I'd say that 'panic-indicator' would be more informative.
>

Sure, that looks much better.

> Please next time cc also devicetree list and maintainers.
>

Will do.

Thanks for the reviews!
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar

Re: [PATCH 2/5] leds: triggers: Add a led_trigger_event_nosleep API

[Ezequiel Garcia]

On 5 April 2016 at 18:36, Jacek Anaszewski  wrote:
> Hi Ezequiel,
>
>
> On 04/04/2016 10:22 PM, Ezequiel Garcia wrote:
>>
>> Now that we can mark any LED (even those in use by delayed blink
>> triggers) to trigger on a kernel panic, let's introduce a nosleep
>> led_trigger_event API.
>>
>> This API is needed to skip the delayed blink path on
>> led_trigger_event. LEDs that are switched on a kernel panic,
>> might be in use by a delayed blink trigger.
>>
>> This will be used by the panic LED trigger.
>>
>> Signed-off-by: Ezequiel Garcia 
>> ---
>>   drivers/leds/led-triggers.c | 26 ++
>>   include/linux/leds.h|  4 
>>   2 files changed, 26 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
>> index f5c9d7c4d181..00b9d849 100644
>> --- a/drivers/leds/led-triggers.c
>> +++ b/drivers/leds/led-triggers.c
>> @@ -307,8 +307,9 @@ EXPORT_SYMBOL_GPL(devm_led_trigger_register);
>>
>>   /* Simple LED Tigger Interface */
>>
>> -void led_trigger_event(struct led_trigger *trig,
>> -   enum led_brightness brightness)
>> +static void do_led_trigger_event(struct led_trigger *trig,
>> +enum led_brightness brightness,
>> +bool nosleep)
>>   {
>> struct led_classdev *led_cdev;
>>
>> @@ -316,12 +317,29 @@ void led_trigger_event(struct led_trigger *trig,
>> return;
>>
>> read_lock(>leddev_list_lock);
>> -   list_for_each_entry(led_cdev, >led_cdevs, trig_list)
>> -   led_set_brightness(led_cdev, brightness);
>
>
> led_set_brightness() can gently disable blinking if passed 0 in the
> brightness argument. IMHO this patch is not needed then.
>
>

Yes, but the blinking disable is deferred, and so might never
run (e.g. I'd say it won't run on a non-preemptible kernel).

I think we need this API, or otherwise some way of circumventing
the deferred path on led_set_brightness. For instance, we
could turn off delay_on and delay_off in the panic atomic notifier.

I'm not strongly convinced by any approach, but this API seemed
slightly cleaner.
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar

Re: [PATCH 2/5] leds: triggers: Add a led_trigger_event_nosleep API

[Ezequiel Garcia]

On 5 April 2016 at 18:36, Jacek Anaszewski  wrote:
> Hi Ezequiel,
>
>
> On 04/04/2016 10:22 PM, Ezequiel Garcia wrote:
>>
>> Now that we can mark any LED (even those in use by delayed blink
>> triggers) to trigger on a kernel panic, let's introduce a nosleep
>> led_trigger_event API.
>>
>> This API is needed to skip the delayed blink path on
>> led_trigger_event. LEDs that are switched on a kernel panic,
>> might be in use by a delayed blink trigger.
>>
>> This will be used by the panic LED trigger.
>>
>> Signed-off-by: Ezequiel Garcia 
>> ---
>>   drivers/leds/led-triggers.c | 26 ++
>>   include/linux/leds.h|  4 
>>   2 files changed, 26 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/leds/led-triggers.c b/drivers/leds/led-triggers.c
>> index f5c9d7c4d181..00b9d849 100644
>> --- a/drivers/leds/led-triggers.c
>> +++ b/drivers/leds/led-triggers.c
>> @@ -307,8 +307,9 @@ EXPORT_SYMBOL_GPL(devm_led_trigger_register);
>>
>>   /* Simple LED Tigger Interface */
>>
>> -void led_trigger_event(struct led_trigger *trig,
>> -   enum led_brightness brightness)
>> +static void do_led_trigger_event(struct led_trigger *trig,
>> +enum led_brightness brightness,
>> +bool nosleep)
>>   {
>> struct led_classdev *led_cdev;
>>
>> @@ -316,12 +317,29 @@ void led_trigger_event(struct led_trigger *trig,
>> return;
>>
>> read_lock(>leddev_list_lock);
>> -   list_for_each_entry(led_cdev, >led_cdevs, trig_list)
>> -   led_set_brightness(led_cdev, brightness);
>
>
> led_set_brightness() can gently disable blinking if passed 0 in the
> brightness argument. IMHO this patch is not needed then.
>
>

Yes, but the blinking disable is deferred, and so might never
run (e.g. I'd say it won't run on a non-preemptible kernel).

I think we need this API, or otherwise some way of circumventing
the deferred path on led_set_brightness. For instance, we
could turn off delay_on and delay_off in the panic atomic notifier.

I'm not strongly convinced by any approach, but this API seemed
slightly cleaner.
-- 
Ezequiel García, VanguardiaSur
www.vanguardiasur.com.ar

Re: [PATCH v2] arm: omap2: remove redundant multiplatform checks

[Lokesh Vutla]

On Wednesday 06 April 2016 04:05 AM, Jonas Rabenstein wrote:
> The directory arch/arm/mach-omap2 is only selected for compilation if
> CONFIG_ARCH_OMAP2PLUS is selected. CONFIG_ARCH_OMAP2PLUS itself is a
> silent option and all machines selecting this option are multiplatform
> devices. As a consequence checks for CONFIG_ARCH_MULTIPLATFORM as well
> as CONFIG_ARCH_OMAP2PLUS within that directory are superfluous and can
> be removed.
> 
> Signed-off-by: Jonas Rabenstein 
> ---
> changes in v2:
>  * missed two #endif's
> 
>  arch/arm/mach-omap2/Makefile |   2 +-
>  arch/arm/mach-omap2/soc.h| 121 
> +++
>  2 files changed, 8 insertions(+), 115 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 0ba6a0e..04e276c 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -2,7 +2,7 @@
>  # Makefile for the linux kernel.
>  #
>  
> -ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
> +ccflags-y := -I$(srctree)/$(src)/include \
>   -I$(srctree)/arch/arm/plat-omap/include
>  
>  # Common support
> diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
> index 364418c..79f1573 100644
> --- a/arch/arm/mach-omap2/soc.h
> +++ b/arch/arm/mach-omap2/soc.h
> @@ -42,79 +42,7 @@
>   * Test if multicore OMAP support is needed
>   */
>  #undef MULTI_OMAP2
> -#undef OMAP_NAME
> -
> -#ifdef CONFIG_ARCH_MULTIPLATFORM
>  #define MULTI_OMAP2
> -#endif
> -#ifdef CONFIG_SOC_OMAP2420
> -# ifdef OMAP_NAME
> -#  undef  MULTI_OMAP2
> -#  define MULTI_OMAP2
> -# else
> -#  define OMAP_NAME omap2420
> -# endif
> -#endif
> -#ifdef CONFIG_SOC_OMAP2430
> -# ifdef OMAP_NAME
> -#  undef  MULTI_OMAP2
> -#  define MULTI_OMAP2
> -# else
> -#  define OMAP_NAME omap2430
> -# endif
> -#endif
> -#ifdef CONFIG_ARCH_OMAP3
> -# ifdef OMAP_NAME
> -#  undef  MULTI_OMAP2
> -#  define MULTI_OMAP2
> -# else
> -#  define OMAP_NAME omap3
> -# endif
> -#endif
> -#ifdef CONFIG_ARCH_OMAP4
> -# ifdef OMAP_NAME
> -#  undef  MULTI_OMAP2
> -#  define MULTI_OMAP2
> -# else
> -#  define OMAP_NAME omap4
> -# endif
> -#endif
> -
> -#ifdef CONFIG_SOC_OMAP5
> -# ifdef OMAP_NAME
> -#  undef  MULTI_OMAP2
> -#  define MULTI_OMAP2
> -# else
> -#  define OMAP_NAME omap5
> -# endif
> -#endif
> -
> -#ifdef CONFIG_SOC_AM33XX
> -# ifdef OMAP_NAME
> -#  undef  MULTI_OMAP2
> -#  define MULTI_OMAP2
> -# else
> -#  define OMAP_NAME am33xx
> -# endif
> -#endif
> -
> -#ifdef CONFIG_SOC_AM43XX
> -# ifdef OMAP_NAME
> -#  undef  MULTI_OMAP2
> -#  define MULTI_OMAP2
> -# else
> -#  define OMAP_NAME am43xx
> -# endif
> -#endif
> -
> -#ifdef CONFIG_SOC_DRA7XX
> -# ifdef OMAP_NAME
> -#  undef MULTI_OMAP2
> -#  define MULTI_OMAP2
> -# else
> -#  define OMAP_NAME DRA7XX
> -# endif
> -#endif
>  
>  /*
>   * Omap device type i.e. EMU/HS/TST/GP/BAD
> @@ -242,11 +170,6 @@ IS_AM_SUBCLASS(437x, 0x437)
>  IS_DRA_SUBCLASS(75x, 0x75)
>  IS_DRA_SUBCLASS(72x, 0x72)
>  
> -#define soc_is_omap24xx()0
> -#define soc_is_omap242x()0
> -#define soc_is_omap243x()0
> -#define soc_is_omap34xx()0
> -#define soc_is_omap343x()0

Why are you deleting these definitions. Without these I am sure there
will be a build error when you don't select ARCH_OMAP2 or ARCH_OMAP3 and
building with omap2plus_defconfig.

Thanks and regards,
Lokesh

Re: [PATCH v2] arm: omap2: remove redundant multiplatform checks

[Lokesh Vutla]

On Wednesday 06 April 2016 04:05 AM, Jonas Rabenstein wrote:
> The directory arch/arm/mach-omap2 is only selected for compilation if
> CONFIG_ARCH_OMAP2PLUS is selected. CONFIG_ARCH_OMAP2PLUS itself is a
> silent option and all machines selecting this option are multiplatform
> devices. As a consequence checks for CONFIG_ARCH_MULTIPLATFORM as well
> as CONFIG_ARCH_OMAP2PLUS within that directory are superfluous and can
> be removed.
> 
> Signed-off-by: Jonas Rabenstein 
> ---
> changes in v2:
>  * missed two #endif's
> 
>  arch/arm/mach-omap2/Makefile |   2 +-
>  arch/arm/mach-omap2/soc.h| 121 
> +++
>  2 files changed, 8 insertions(+), 115 deletions(-)
> 
> diff --git a/arch/arm/mach-omap2/Makefile b/arch/arm/mach-omap2/Makefile
> index 0ba6a0e..04e276c 100644
> --- a/arch/arm/mach-omap2/Makefile
> +++ b/arch/arm/mach-omap2/Makefile
> @@ -2,7 +2,7 @@
>  # Makefile for the linux kernel.
>  #
>  
> -ccflags-$(CONFIG_ARCH_MULTIPLATFORM) := -I$(srctree)/$(src)/include \
> +ccflags-y := -I$(srctree)/$(src)/include \
>   -I$(srctree)/arch/arm/plat-omap/include
>  
>  # Common support
> diff --git a/arch/arm/mach-omap2/soc.h b/arch/arm/mach-omap2/soc.h
> index 364418c..79f1573 100644
> --- a/arch/arm/mach-omap2/soc.h
> +++ b/arch/arm/mach-omap2/soc.h
> @@ -42,79 +42,7 @@
>   * Test if multicore OMAP support is needed
>   */
>  #undef MULTI_OMAP2
> -#undef OMAP_NAME
> -
> -#ifdef CONFIG_ARCH_MULTIPLATFORM
>  #define MULTI_OMAP2
> -#endif
> -#ifdef CONFIG_SOC_OMAP2420
> -# ifdef OMAP_NAME
> -#  undef  MULTI_OMAP2
> -#  define MULTI_OMAP2
> -# else
> -#  define OMAP_NAME omap2420
> -# endif
> -#endif
> -#ifdef CONFIG_SOC_OMAP2430
> -# ifdef OMAP_NAME
> -#  undef  MULTI_OMAP2
> -#  define MULTI_OMAP2
> -# else
> -#  define OMAP_NAME omap2430
> -# endif
> -#endif
> -#ifdef CONFIG_ARCH_OMAP3
> -# ifdef OMAP_NAME
> -#  undef  MULTI_OMAP2
> -#  define MULTI_OMAP2
> -# else
> -#  define OMAP_NAME omap3
> -# endif
> -#endif
> -#ifdef CONFIG_ARCH_OMAP4
> -# ifdef OMAP_NAME
> -#  undef  MULTI_OMAP2
> -#  define MULTI_OMAP2
> -# else
> -#  define OMAP_NAME omap4
> -# endif
> -#endif
> -
> -#ifdef CONFIG_SOC_OMAP5
> -# ifdef OMAP_NAME
> -#  undef  MULTI_OMAP2
> -#  define MULTI_OMAP2
> -# else
> -#  define OMAP_NAME omap5
> -# endif
> -#endif
> -
> -#ifdef CONFIG_SOC_AM33XX
> -# ifdef OMAP_NAME
> -#  undef  MULTI_OMAP2
> -#  define MULTI_OMAP2
> -# else
> -#  define OMAP_NAME am33xx
> -# endif
> -#endif
> -
> -#ifdef CONFIG_SOC_AM43XX
> -# ifdef OMAP_NAME
> -#  undef  MULTI_OMAP2
> -#  define MULTI_OMAP2
> -# else
> -#  define OMAP_NAME am43xx
> -# endif
> -#endif
> -
> -#ifdef CONFIG_SOC_DRA7XX
> -# ifdef OMAP_NAME
> -#  undef MULTI_OMAP2
> -#  define MULTI_OMAP2
> -# else
> -#  define OMAP_NAME DRA7XX
> -# endif
> -#endif
>  
>  /*
>   * Omap device type i.e. EMU/HS/TST/GP/BAD
> @@ -242,11 +170,6 @@ IS_AM_SUBCLASS(437x, 0x437)
>  IS_DRA_SUBCLASS(75x, 0x75)
>  IS_DRA_SUBCLASS(72x, 0x72)
>  
> -#define soc_is_omap24xx()0
> -#define soc_is_omap242x()0
> -#define soc_is_omap243x()0
> -#define soc_is_omap34xx()0
> -#define soc_is_omap343x()0

Why are you deleting these definitions. Without these I am sure there
will be a build error when you don't select ARCH_OMAP2 or ARCH_OMAP3 and
building with omap2plus_defconfig.

Thanks and regards,
Lokesh

linux-next: Tree for Apr 6

[Stephen Rothwell]

Hi all,

Changes since 20160405:

Non-merge commits (relative to Linus' tree): 2369
 2200 files changed, 93285 insertions(+), 58570 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 232 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (541d8f4d59d7 Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/virt/kvm/kvm)
Merging fixes/master (9735a22799b9 Linux 4.6-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (f86b8892a1b7 ARC: Don't source 
drivers/pci/pcie/Kconfig ourselves)
Merging arm-current/fixes (0fc03d4c8761 ARM: SMP enable of cache maintanence 
broadcast)
Merging m68k-current/for-linus (efbec135f11d m68k: Fix misspellings in 
comments.)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (71528d8bd7a8 powerpc: Correct used_vsr comment)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (5ec712934ce1 sparc: Write up preadv2/pwritev2 syscalls.)
Merging net/master (b6ee376cb0b7 ip6_tunnel: set rtnl_link_ops before calling 
register_netdevice)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (7617a24f83b5 ipvs: correct initial offset of Call-ID 
header search in SIP persistence engine)
Merging wireless-drivers/master (15da5d11040c Merge tag 
'iwlwifi-for-kalle-2016-03-30' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (f6d4671a0881 mac80211: close the SP when we enqueue 
frames during the SP)
Merging sound-current/for-linus (f03b24a851d3 ALSA: usb-audio: Add a sample 
rate quirk for Phoenix Audio TMX320)
Merging pci-current/for-linus (b2d7a9cd3ff8 Revert "PCI: imx6: Add support for 
active-low reset GPIO")
Merging driver-core.current/driver-core-linus (f55532a0c0b8 Linux 4.6-rc1)
Merging tty.current/tty-linus (5e00bbfbc5ec tty: Fix merge of "tty: Refactor 
tty_open()")
Merging usb.current/usb-linus (5a07975ad0a3 USB: digi_acceleport: do sanity 
checking for the number of ports)
Merging usb-gadget-fixes/fixes (7e8ac87a4474 usb: phy: qcom-8x16: fix regulator 
API abuse)
Merging usb-serial-fixes/usb-linus (f55532a0c0b8 Linux 4.6-rc1)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (53c43c5ca133 Revert "Staging: olpc_dcon: 
Remove obsolete driver")
Merging char-misc.current/char-misc-linus (f55532a0c0b8 Linux 4.6-rc1)
Merging input-current/for-linus (d63b0f0c0f19 Input: xpad - add Mad Catz 
FightStick TE 2 VID/PID)
Merging crypto-current/master (47cd30608f3f hwrng: bcm63xx - fix device tree 
compilation)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (8160c4e45582 vfio: fix ioctl error handling)
Merging kselftest-fixes/fixes (505ce68c6da3 selftest/seccomp: Fix the 
seccomp(2) signature)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: 

linux-next: Tree for Apr 6

[Stephen Rothwell]

Hi all,

Changes since 20160405:

Non-merge commits (relative to Linus' tree): 2369
 2200 files changed, 93285 insertions(+), 58570 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
(this fails its final link) and pseries_le_defconfig and i386, sparc
and sparc64 defconfig.

Below is a summary of the state of the merge.

I am currently merging 232 trees (counting Linus' and 35 trees of patches
pending for Linus' tree).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (541d8f4d59d7 Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/virt/kvm/kvm)
Merging fixes/master (9735a22799b9 Linux 4.6-rc2)
Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on 
module install)
Merging arc-current/for-curr (f86b8892a1b7 ARC: Don't source 
drivers/pci/pcie/Kconfig ourselves)
Merging arm-current/fixes (0fc03d4c8761 ARM: SMP enable of cache maintanence 
broadcast)
Merging m68k-current/for-linus (efbec135f11d m68k: Fix misspellings in 
comments.)
Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached 
build errors)
Merging powerpc-fixes/fixes (71528d8bd7a8 powerpc: Correct used_vsr comment)
Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2)
Merging sparc/master (5ec712934ce1 sparc: Write up preadv2/pwritev2 syscalls.)
Merging net/master (b6ee376cb0b7 ip6_tunnel: set rtnl_link_ops before calling 
register_netdevice)
Merging ipsec/master (d6af1a31cc72 vti: Add pmtu handling to vti_xmit.)
Merging ipvs/master (7617a24f83b5 ipvs: correct initial offset of Call-ID 
header search in SIP persistence engine)
Merging wireless-drivers/master (15da5d11040c Merge tag 
'iwlwifi-for-kalle-2016-03-30' of 
https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/iwlwifi-fixes)
Merging mac80211/master (f6d4671a0881 mac80211: close the SP when we enqueue 
frames during the SP)
Merging sound-current/for-linus (f03b24a851d3 ALSA: usb-audio: Add a sample 
rate quirk for Phoenix Audio TMX320)
Merging pci-current/for-linus (b2d7a9cd3ff8 Revert "PCI: imx6: Add support for 
active-low reset GPIO")
Merging driver-core.current/driver-core-linus (f55532a0c0b8 Linux 4.6-rc1)
Merging tty.current/tty-linus (5e00bbfbc5ec tty: Fix merge of "tty: Refactor 
tty_open()")
Merging usb.current/usb-linus (5a07975ad0a3 USB: digi_acceleport: do sanity 
checking for the number of ports)
Merging usb-gadget-fixes/fixes (7e8ac87a4474 usb: phy: qcom-8x16: fix regulator 
API abuse)
Merging usb-serial-fixes/usb-linus (f55532a0c0b8 Linux 4.6-rc1)
Merging usb-chipidea-fixes/ci-for-usb-stable (d144dfea8af7 usb: chipidea: otg: 
change workqueue ci_otg as freezable)
Merging staging.current/staging-linus (53c43c5ca133 Revert "Staging: olpc_dcon: 
Remove obsolete driver")
Merging char-misc.current/char-misc-linus (f55532a0c0b8 Linux 4.6-rc1)
Merging input-current/for-linus (d63b0f0c0f19 Input: xpad - add Mad Catz 
FightStick TE 2 VID/PID)
Merging crypto-current/master (47cd30608f3f hwrng: bcm63xx - fix device tree 
compilation)
Merging ide/master (1993b176a822 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide)
Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test 
for PPC_PSERIES)
Merging rr-fixes/fixes (8244062ef1e5 modules: fix longstanding /proc/kallsyms 
vs module insertion race.)
Merging vfio-fixes/for-linus (8160c4e45582 vfio: fix ioctl error handling)
Merging kselftest-fixes/fixes (505ce68c6da3 selftest/seccomp: Fix the 
seccomp(2) signature)
Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: 

Re: [PATCH 01/27] block: bio: introduce 4 helpers for cleanup

[Ming Lei]

On Wed, Apr 6, 2016 at 10:21 AM, Kent Overstreet
 wrote:
> On Wed, Apr 06, 2016 at 10:11:27AM +0800, Ming Lei wrote:
>> On Wed, Apr 6, 2016 at 9:46 AM, Kent Overstreet
>>  wrote:
>> > On Wed, Apr 06, 2016 at 09:34:34AM +0800, Ming Lei wrote:
>> >> On Wed, Apr 6, 2016 at 8:18 AM, Kent Overstreet
>> >>  wrote:
>> >> > On Tue, Apr 05, 2016 at 07:56:46PM +0800, Ming Lei wrote:
>> >> >> Some drivers access bio->bi_vcnt and bio->bi_io_vec directly,
>> >> >> firstly it isn't a good practice, secondly it may cause trouble
>> >> >> for converting to multipage bvecs.
>> >> >
>> >> > "not good practice" is OO bullshit snake oil without more 
>> >> > justification. We
>> >> > don't plaster accessors everywhere without an actual reason.
>> >> >
>> >> > How would it cause trouble with multipage bvecs?
>> >>
>> >> Simply speaking, the current drivers may depend on .bi_vcnt for
>> >> computing how many page there are in one bio. After multipage bvecs,
>> >> it is not true any more. Isn't it a actual reason?
>> >
>> > But it's completely valid to use bi_vcnt for segments, which is what it's 
>> > always
>> > _really_ meant anyways.
>>
>> Previously drivers may be confused with segment and page, so they just 
>> thought
>> segment is same with page. The situation will change after multipage bvecs
>> is introduced.
>>
>> Drivers may loop over .bi_io_vec and .bi_vcnt for accessing each pages.
>> (pktcdvd, staging: lustre, raid,...)
>>
>> It isn't practical to fix all these drivers before introducing multipage 
>> bvecs.
>> Meantime we can't cause regressions with multipage bvecs. But we can
>> disable multipage bvecs for some insane drivers if they insist on their
>> misusing.
>
> No - it is both practical and IMO _required_ to convert those drivers to
> bio_for_each_segment() or bio_for_each_page() as appropriate, before multipage
> bvecs.
>
> Especially code that needs pages and segments _has_ to be converted before
> multipage bvecs.
>
> If you'll recall looking at my various patch series from way back, especially
> around immutable biovecs - most of the work was in converting drivers, not the
> actual implementation (and I got rid of a more bi_io_vec/bi_vcnt uses than you
> have left, so honestly there's no excuse for not doing it right).

Looks your style for new featue is the following way:
- convert all drivers to new interface
- convert core code to new feature and enable it

My style is:
- if driver is easy to convert, then take new interface; othewise just leave it
alone without using new feature
- convert core code to new feature and enable it

I don't want to discuss which way is better.

But my way just introduces change to driver as few as possible, and
I try to avoid regression becasue I don't want to change code hugely
without detailed test.

That is why you can see the change to driver in this patchset is just
a little.

Thanks,

>
>> With these helpers, it is easy to audit drivers about their access to
>> .bi_vcnt & .bi_io_vec.
>
> It's easy to grep for those uses now!
>
>> After this ptach is applied, only btrfs and md are left with these 
>> references.
>>
>> For btrfs, we still need to audit each usage and try to clean them up.
>> For md, we can't enable multipage bvecs for them until all these usage
>> are cleaned up or audited.
>
> Cleaning up those should be your focus now, not adding these helpers. You 
> don't
> need these patches to go in to tell you what needs to be cleaned up, we 
> already
> know wha thas to be done.




-- 
Ming Lei

Re: [PATCH 01/27] block: bio: introduce 4 helpers for cleanup

[Ming Lei]

On Wed, Apr 6, 2016 at 10:21 AM, Kent Overstreet
 wrote:
> On Wed, Apr 06, 2016 at 10:11:27AM +0800, Ming Lei wrote:
>> On Wed, Apr 6, 2016 at 9:46 AM, Kent Overstreet
>>  wrote:
>> > On Wed, Apr 06, 2016 at 09:34:34AM +0800, Ming Lei wrote:
>> >> On Wed, Apr 6, 2016 at 8:18 AM, Kent Overstreet
>> >>  wrote:
>> >> > On Tue, Apr 05, 2016 at 07:56:46PM +0800, Ming Lei wrote:
>> >> >> Some drivers access bio->bi_vcnt and bio->bi_io_vec directly,
>> >> >> firstly it isn't a good practice, secondly it may cause trouble
>> >> >> for converting to multipage bvecs.
>> >> >
>> >> > "not good practice" is OO bullshit snake oil without more 
>> >> > justification. We
>> >> > don't plaster accessors everywhere without an actual reason.
>> >> >
>> >> > How would it cause trouble with multipage bvecs?
>> >>
>> >> Simply speaking, the current drivers may depend on .bi_vcnt for
>> >> computing how many page there are in one bio. After multipage bvecs,
>> >> it is not true any more. Isn't it a actual reason?
>> >
>> > But it's completely valid to use bi_vcnt for segments, which is what it's 
>> > always
>> > _really_ meant anyways.
>>
>> Previously drivers may be confused with segment and page, so they just 
>> thought
>> segment is same with page. The situation will change after multipage bvecs
>> is introduced.
>>
>> Drivers may loop over .bi_io_vec and .bi_vcnt for accessing each pages.
>> (pktcdvd, staging: lustre, raid,...)
>>
>> It isn't practical to fix all these drivers before introducing multipage 
>> bvecs.
>> Meantime we can't cause regressions with multipage bvecs. But we can
>> disable multipage bvecs for some insane drivers if they insist on their
>> misusing.
>
> No - it is both practical and IMO _required_ to convert those drivers to
> bio_for_each_segment() or bio_for_each_page() as appropriate, before multipage
> bvecs.
>
> Especially code that needs pages and segments _has_ to be converted before
> multipage bvecs.
>
> If you'll recall looking at my various patch series from way back, especially
> around immutable biovecs - most of the work was in converting drivers, not the
> actual implementation (and I got rid of a more bi_io_vec/bi_vcnt uses than you
> have left, so honestly there's no excuse for not doing it right).

Looks your style for new featue is the following way:
- convert all drivers to new interface
- convert core code to new feature and enable it

My style is:
- if driver is easy to convert, then take new interface; othewise just leave it
alone without using new feature
- convert core code to new feature and enable it

I don't want to discuss which way is better.

But my way just introduces change to driver as few as possible, and
I try to avoid regression becasue I don't want to change code hugely
without detailed test.

That is why you can see the change to driver in this patchset is just
a little.

Thanks,

>
>> With these helpers, it is easy to audit drivers about their access to
>> .bi_vcnt & .bi_io_vec.
>
> It's easy to grep for those uses now!
>
>> After this ptach is applied, only btrfs and md are left with these 
>> references.
>>
>> For btrfs, we still need to audit each usage and try to clean them up.
>> For md, we can't enable multipage bvecs for them until all these usage
>> are cleaned up or audited.
>
> Cleaning up those should be your focus now, not adding these helpers. You 
> don't
> need these patches to go in to tell you what needs to be cleaned up, we 
> already
> know wha thas to be done.




-- 
Ming Lei

[PATCH v2] staging: iio: ad7606: use iio_device_{claim|release}_direct_mode()

[Alison Schofield]

Replace the code that guarantees the device stays in direct mode with
iio_device_{claim|release}_direct_mode() which does same.

Signed-off-by: Alison Schofield 
---
Changed in v2:
 - removed improper application of claim/release from intr handler
 - updated changelog

 drivers/staging/iio/adc/ad7606_core.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/iio/adc/ad7606_core.c 
b/drivers/staging/iio/adc/ad7606_core.c
index 6dbc811..f79ee61 100644
--- a/drivers/staging/iio/adc/ad7606_core.c
+++ b/drivers/staging/iio/adc/ad7606_core.c
@@ -88,12 +88,12 @@ static int ad7606_read_raw(struct iio_dev *indio_dev,
 
switch (m) {
case IIO_CHAN_INFO_RAW:
-   mutex_lock(_dev->mlock);
-   if (iio_buffer_enabled(indio_dev))
-   ret = -EBUSY;
-   else
-   ret = ad7606_scan_direct(indio_dev, chan->address);
-   mutex_unlock(_dev->mlock);
+   ret = iio_device_claim_direct_mode(indio_dev);
+   if (ret)
+   return ret;
+
+   ret = ad7606_scan_direct(indio_dev, chan->address);
+   iio_device_release_direct_mode(indio_dev);
 
if (ret < 0)
return ret;
-- 
2.1.4

[PATCH v2] staging: iio: ad7606: use iio_device_{claim|release}_direct_mode()

[Alison Schofield]

Replace the code that guarantees the device stays in direct mode with
iio_device_{claim|release}_direct_mode() which does same.

Signed-off-by: Alison Schofield 
---
Changed in v2:
 - removed improper application of claim/release from intr handler
 - updated changelog

 drivers/staging/iio/adc/ad7606_core.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/staging/iio/adc/ad7606_core.c 
b/drivers/staging/iio/adc/ad7606_core.c
index 6dbc811..f79ee61 100644
--- a/drivers/staging/iio/adc/ad7606_core.c
+++ b/drivers/staging/iio/adc/ad7606_core.c
@@ -88,12 +88,12 @@ static int ad7606_read_raw(struct iio_dev *indio_dev,
 
switch (m) {
case IIO_CHAN_INFO_RAW:
-   mutex_lock(_dev->mlock);
-   if (iio_buffer_enabled(indio_dev))
-   ret = -EBUSY;
-   else
-   ret = ad7606_scan_direct(indio_dev, chan->address);
-   mutex_unlock(_dev->mlock);
+   ret = iio_device_claim_direct_mode(indio_dev);
+   if (ret)
+   return ret;
+
+   ret = ad7606_scan_direct(indio_dev, chan->address);
+   iio_device_release_direct_mode(indio_dev);
 
if (ret < 0)
return ret;
-- 
2.1.4

[PATCH] IMA: Use the system trusted keyrings instead of .ima_mok (update)

[Mimi Zohar]

Hi David,

Please feel free to squash this patch with yours of the same name (12/12).

Just replace the .ima_mok keyring with the .secondary_trusted_keys.

Signed-off-by: Mimi Zohar 
---
 include/keys/system_keyring.h|  4 +--
 security/integrity/digsig.c  |  9 ++
 security/integrity/ima/Kconfig   | 61 +++-
 security/integrity/ima/Makefile  |  2 +-
 security/integrity/ima/ima_mok.c |  4 +--
 5 files changed, 24 insertions(+), 56 deletions(-)

diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
index 87eeea4..fbd4647 100644
--- a/include/keys/system_keyring.h
+++ b/include/keys/system_keyring.h
@@ -33,7 +33,7 @@ extern int restrict_link_by_builtin_and_secondary_trusted(
 #define restrict_link_by_builtin_and_secondary_trusted 
restrict_link_by_builtin_trusted
 #endif
 
-#ifdef CONFIG_IMA_MOK_KEYRING
+#ifdef CONFIG_IMA_BLACKLIST_KEYRING
 extern struct key *ima_blacklist_keyring;
 
 static inline struct key *get_ima_blacklist_keyring(void)
@@ -45,7 +45,7 @@ static inline struct key *get_ima_blacklist_keyring(void)
 {
return NULL;
 }
-#endif /* CONFIG_IMA_MOK_KEYRING */
+#endif /* CONFIG_IMA_BLACKLIST_KEYRING */
 
 
 #endif /* _KEYS_SYSTEM_KEYRING_H */
diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index ef2f911..4304372 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -42,12 +42,10 @@ static bool init_keyring __initdata = true;
 static bool init_keyring __initdata;
 #endif
 
-#if defined(CONFIG_IMA_KEYRINGS_ADD_IF_SIGNED_BY_BUILTIN)
-#define restrict_link_to_ima restrict_link_by_builtin_trusted
-#elif defined(CONFIG_IMA_KEYRINGS_ADD_IF_SIGNED_BY_BUILTIN_OR_SECONDARY)
+#ifdef CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY
 #define restrict_link_to_ima restrict_link_by_builtin_and_secondary_trusted
 #else
-#define restrict_link_to_ima restrict_link_reject
+#define restrict_link_to_ima restrict_link_by_builtin_trusted
 #endif
 
 int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,
@@ -94,8 +92,7 @@ int __init integrity_init_keyring(const unsigned int id)
 KEY_USR_VIEW | KEY_USR_READ |
 KEY_USR_WRITE | KEY_USR_SEARCH),
KEY_ALLOC_NOT_IN_QUOTA,
-   restrict_link_to_ima,
-   NULL);
+   restrict_link_to_ima, NULL);
if (IS_ERR(keyring[id])) {
err = PTR_ERR(keyring[id]);
pr_info("Can't allocate %s keyring (%d)\n",
diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
index 90a65fb..aab9b0a 100644
--- a/security/integrity/ima/Kconfig
+++ b/security/integrity/ima/Kconfig
@@ -155,61 +155,32 @@ config IMA_TRUSTED_KEYRING
 
   This option is deprecated in favor of INTEGRITY_TRUSTED_KEYRING
 
-config IMA_MOK_KEYRING
-   bool "Create IMA machine owner blacklist keyrings"
-   depends on SYSTEM_TRUSTED_KEYRING
-   depends on IMA_TRUSTED_KEYRING
-   default n
-   help
-  This option creates IMA blacklist keyring.  This contains all
-  revoked IMA keys.  It is consulted before any other keyring.  If the
-  search is successful the requested operation is rejected and error
-  is returned to the caller.
-
-choice
-   prompt "Allow keys to be added to the ima keyrings by userspace?"
-   depends on IMA_APPRAISE
-   depends on INTEGRITY_ASYMMETRIC_KEYS
-   default IMA_NO_ADD_TO_IMA_KEYRINGS
-   help
- This option selects whether keys may be added to the ima keyrings
- using add_key() or KEYCTL_LINK, and, if so, under what restrictions
- the key being added will be placed.
-
-config IMA_KEYRINGS_COMPILE_LOAD_ONLY
-   bool "No runtime key addition"
-   help
- No keys may be added to the IMA keyrings by userspace in the running
- kernel.  Keys may still be added by including X.509 certificates in
- the kernel image at compile time.
-
- Attempts to add to the ima keyrings will be rejected with EPERM.
-
-config IMA_KEYRINGS_ADD_IF_SIGNED_BY_BUILTIN
-   bool "Keys may be added at runtime if validly signed by a built-in CA 
cert"
-   depends on SYSTEM_TRUSTED_KEYRING
-   select INTEGRITY_TRUSTED_KEYRING
-   help
- keys may be added to the IMA keyrings by userspace in the running
- kernel if the keys to be added are validly signed by a CA cert in the
- system built-in trusted keyring.
-
-config IMA_KEYRINGS_ADD_IF_SIGNED_BY_BUILTIN_OR_SECONDARY
-   bool "Keys may be added at runtime if validly signed by a built-in or 
secondary CA cert"
+config IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY
+   bool "Permit keys validly signed by a built-in or secondary CA cert 
(EXPERIMENTAL)"
depends on 

[PATCH] IMA: Use the system trusted keyrings instead of .ima_mok (update)

[Mimi Zohar]

Hi David,

Please feel free to squash this patch with yours of the same name (12/12).

Just replace the .ima_mok keyring with the .secondary_trusted_keys.

Signed-off-by: Mimi Zohar 
---
 include/keys/system_keyring.h|  4 +--
 security/integrity/digsig.c  |  9 ++
 security/integrity/ima/Kconfig   | 61 +++-
 security/integrity/ima/Makefile  |  2 +-
 security/integrity/ima/ima_mok.c |  4 +--
 5 files changed, 24 insertions(+), 56 deletions(-)

diff --git a/include/keys/system_keyring.h b/include/keys/system_keyring.h
index 87eeea4..fbd4647 100644
--- a/include/keys/system_keyring.h
+++ b/include/keys/system_keyring.h
@@ -33,7 +33,7 @@ extern int restrict_link_by_builtin_and_secondary_trusted(
 #define restrict_link_by_builtin_and_secondary_trusted 
restrict_link_by_builtin_trusted
 #endif
 
-#ifdef CONFIG_IMA_MOK_KEYRING
+#ifdef CONFIG_IMA_BLACKLIST_KEYRING
 extern struct key *ima_blacklist_keyring;
 
 static inline struct key *get_ima_blacklist_keyring(void)
@@ -45,7 +45,7 @@ static inline struct key *get_ima_blacklist_keyring(void)
 {
return NULL;
 }
-#endif /* CONFIG_IMA_MOK_KEYRING */
+#endif /* CONFIG_IMA_BLACKLIST_KEYRING */
 
 
 #endif /* _KEYS_SYSTEM_KEYRING_H */
diff --git a/security/integrity/digsig.c b/security/integrity/digsig.c
index ef2f911..4304372 100644
--- a/security/integrity/digsig.c
+++ b/security/integrity/digsig.c
@@ -42,12 +42,10 @@ static bool init_keyring __initdata = true;
 static bool init_keyring __initdata;
 #endif
 
-#if defined(CONFIG_IMA_KEYRINGS_ADD_IF_SIGNED_BY_BUILTIN)
-#define restrict_link_to_ima restrict_link_by_builtin_trusted
-#elif defined(CONFIG_IMA_KEYRINGS_ADD_IF_SIGNED_BY_BUILTIN_OR_SECONDARY)
+#ifdef CONFIG_IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY
 #define restrict_link_to_ima restrict_link_by_builtin_and_secondary_trusted
 #else
-#define restrict_link_to_ima restrict_link_reject
+#define restrict_link_to_ima restrict_link_by_builtin_trusted
 #endif
 
 int integrity_digsig_verify(const unsigned int id, const char *sig, int siglen,
@@ -94,8 +92,7 @@ int __init integrity_init_keyring(const unsigned int id)
 KEY_USR_VIEW | KEY_USR_READ |
 KEY_USR_WRITE | KEY_USR_SEARCH),
KEY_ALLOC_NOT_IN_QUOTA,
-   restrict_link_to_ima,
-   NULL);
+   restrict_link_to_ima, NULL);
if (IS_ERR(keyring[id])) {
err = PTR_ERR(keyring[id]);
pr_info("Can't allocate %s keyring (%d)\n",
diff --git a/security/integrity/ima/Kconfig b/security/integrity/ima/Kconfig
index 90a65fb..aab9b0a 100644
--- a/security/integrity/ima/Kconfig
+++ b/security/integrity/ima/Kconfig
@@ -155,61 +155,32 @@ config IMA_TRUSTED_KEYRING
 
   This option is deprecated in favor of INTEGRITY_TRUSTED_KEYRING
 
-config IMA_MOK_KEYRING
-   bool "Create IMA machine owner blacklist keyrings"
-   depends on SYSTEM_TRUSTED_KEYRING
-   depends on IMA_TRUSTED_KEYRING
-   default n
-   help
-  This option creates IMA blacklist keyring.  This contains all
-  revoked IMA keys.  It is consulted before any other keyring.  If the
-  search is successful the requested operation is rejected and error
-  is returned to the caller.
-
-choice
-   prompt "Allow keys to be added to the ima keyrings by userspace?"
-   depends on IMA_APPRAISE
-   depends on INTEGRITY_ASYMMETRIC_KEYS
-   default IMA_NO_ADD_TO_IMA_KEYRINGS
-   help
- This option selects whether keys may be added to the ima keyrings
- using add_key() or KEYCTL_LINK, and, if so, under what restrictions
- the key being added will be placed.
-
-config IMA_KEYRINGS_COMPILE_LOAD_ONLY
-   bool "No runtime key addition"
-   help
- No keys may be added to the IMA keyrings by userspace in the running
- kernel.  Keys may still be added by including X.509 certificates in
- the kernel image at compile time.
-
- Attempts to add to the ima keyrings will be rejected with EPERM.
-
-config IMA_KEYRINGS_ADD_IF_SIGNED_BY_BUILTIN
-   bool "Keys may be added at runtime if validly signed by a built-in CA 
cert"
-   depends on SYSTEM_TRUSTED_KEYRING
-   select INTEGRITY_TRUSTED_KEYRING
-   help
- keys may be added to the IMA keyrings by userspace in the running
- kernel if the keys to be added are validly signed by a CA cert in the
- system built-in trusted keyring.
-
-config IMA_KEYRINGS_ADD_IF_SIGNED_BY_BUILTIN_OR_SECONDARY
-   bool "Keys may be added at runtime if validly signed by a built-in or 
secondary CA cert"
+config IMA_KEYRINGS_PERMIT_SIGNED_BY_BUILTIN_OR_SECONDARY
+   bool "Permit keys validly signed by a built-in or secondary CA cert 
(EXPERIMENTAL)"
depends on SYSTEM_TRUSTED_KEYRING

Re: [PATCH RFC v2 1/2] media: platform: transfer format translations to soc_mediabus

[Guennadi Liakhovetski]

Hi Robert,

Not sure I understand, what should the purpose of this patch be? Why do 
you want to move some function(s) from one file to another? And you aren't 
even calling the new soc_mbus_build_fmts_xlate() function, and you aren't 
replacing the currently used analogous soc_camera_init_user_formats() 
function. Or was this patch not-to-be-reviewed?

Thanks
Guennadi

On Sat, 2 Apr 2016, Robert Jarzmik wrote:

> Transfer the formats translations to soc_mediabus. Even is soc_camera
> was to be deprecated, soc_mediabus will survive, and should describe all
> that happens on the bus connecting the image processing unit of the SoC
> and the sensor.
> 
> The translation engine provides an easy way to compute the formats
> available in the v4l2 device, given any sensors format capabilities
> bound with known image processing transformations.
> 
> Signed-off-by: Robert Jarzmik 
> ---
>  drivers/media/platform/soc_camera/soc_camera.c   |  7 +--
>  drivers/media/platform/soc_camera/soc_mediabus.c | 65 
> 
>  include/media/drv-intf/soc_mediabus.h| 22 
>  include/media/soc_camera.h   | 15 --
>  4 files changed, 88 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/media/platform/soc_camera/soc_camera.c 
> b/drivers/media/platform/soc_camera/soc_camera.c
> index 46c7186f7867..039524a20056 100644
> --- a/drivers/media/platform/soc_camera/soc_camera.c
> +++ b/drivers/media/platform/soc_camera/soc_camera.c
> @@ -204,12 +204,7 @@ static void soc_camera_clock_stop(struct soc_camera_host 
> *ici)
>  const struct soc_camera_format_xlate *soc_camera_xlate_by_fourcc(
>   struct soc_camera_device *icd, unsigned int fourcc)
>  {
> - unsigned int i;
> -
> - for (i = 0; i < icd->num_user_formats; i++)
> - if (icd->user_formats[i].host_fmt->fourcc == fourcc)
> - return icd->user_formats + i;
> - return NULL;
> + return soc_mbus_xlate_by_fourcc(icd->user_formats, fourcc);
>  }
>  EXPORT_SYMBOL(soc_camera_xlate_by_fourcc);
>  
> diff --git a/drivers/media/platform/soc_camera/soc_mediabus.c 
> b/drivers/media/platform/soc_camera/soc_mediabus.c
> index e3e665e1c503..95c13055f50f 100644
> --- a/drivers/media/platform/soc_camera/soc_mediabus.c
> +++ b/drivers/media/platform/soc_camera/soc_mediabus.c
> @@ -10,6 +10,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -512,6 +513,70 @@ unsigned int soc_mbus_config_compatible(const struct 
> v4l2_mbus_config *cfg,
>  }
>  EXPORT_SYMBOL(soc_mbus_config_compatible);
>  
> +struct soc_camera_format_xlate *soc_mbus_build_fmts_xlate(
> + struct v4l2_device *v4l2_dev, struct v4l2_subdev *subdev,
> + int (*get_formats)(struct v4l2_device *, unsigned int,
> +struct soc_camera_format_xlate *xlate))
> +{
> + unsigned int i, fmts = 0, raw_fmts = 0;
> + int ret;
> + struct v4l2_subdev_mbus_code_enum code = {
> + .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> + };
> + struct soc_camera_format_xlate *user_formats;
> +
> + while (!v4l2_subdev_call(subdev, pad, enum_mbus_code, NULL, )) {
> + raw_fmts++;
> + code.index++;
> + }
> +
> + /*
> +  * First pass - only count formats this host-sensor
> +  * configuration can provide
> +  */
> + for (i = 0; i < raw_fmts; i++) {
> + ret = get_formats(v4l2_dev, i, NULL);
> + if (ret < 0)
> + return ERR_PTR(ret);
> + fmts += ret;
> + }
> +
> + if (!fmts)
> + return ERR_PTR(-ENXIO);
> +
> + user_formats = kcalloc(fmts + 1, sizeof(*user_formats), GFP_KERNEL);
> + if (!user_formats)
> + return ERR_PTR(-ENOMEM);
> +
> + /* Second pass - actually fill data formats */
> + fmts = 0;
> + for (i = 0; i < raw_fmts; i++) {
> + ret = get_formats(v4l2_dev, i, user_formats + fmts);
> + if (ret < 0)
> + goto egfmt;
> + fmts += ret;
> + }
> + user_formats[fmts].code = 0;
> +
> + return user_formats;
> +egfmt:
> + kfree(user_formats);
> + return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL(soc_mbus_build_fmts_xlate);
> +
> +const struct soc_camera_format_xlate *soc_mbus_xlate_by_fourcc(
> + struct soc_camera_format_xlate *user_formats, unsigned int fourcc)
> +{
> + unsigned int i;
> +
> + for (i = 0; user_formats[i].code; i++)
> + if (user_formats[i].host_fmt->fourcc == fourcc)
> + return user_formats + i;
> + return NULL;
> +}
> +EXPORT_SYMBOL(soc_mbus_xlate_by_fourcc);
> +
>  static int __init soc_mbus_init(void)
>  {
>   return 0;
> diff --git a/include/media/drv-intf/soc_mediabus.h 
> b/include/media/drv-intf/soc_mediabus.h
> index 2ff773785fb6..08af52f6338c 100644
> --- a/include/media/drv-intf/soc_mediabus.h
> +++ b/include/media/drv-intf/soc_mediabus.h
> @@ -95,6 +95,21 

Re: [PATCH RFC v2 1/2] media: platform: transfer format translations to soc_mediabus

[Guennadi Liakhovetski]

Hi Robert,

Not sure I understand, what should the purpose of this patch be? Why do 
you want to move some function(s) from one file to another? And you aren't 
even calling the new soc_mbus_build_fmts_xlate() function, and you aren't 
replacing the currently used analogous soc_camera_init_user_formats() 
function. Or was this patch not-to-be-reviewed?

Thanks
Guennadi

On Sat, 2 Apr 2016, Robert Jarzmik wrote:

> Transfer the formats translations to soc_mediabus. Even is soc_camera
> was to be deprecated, soc_mediabus will survive, and should describe all
> that happens on the bus connecting the image processing unit of the SoC
> and the sensor.
> 
> The translation engine provides an easy way to compute the formats
> available in the v4l2 device, given any sensors format capabilities
> bound with known image processing transformations.
> 
> Signed-off-by: Robert Jarzmik 
> ---
>  drivers/media/platform/soc_camera/soc_camera.c   |  7 +--
>  drivers/media/platform/soc_camera/soc_mediabus.c | 65 
> 
>  include/media/drv-intf/soc_mediabus.h| 22 
>  include/media/soc_camera.h   | 15 --
>  4 files changed, 88 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/media/platform/soc_camera/soc_camera.c 
> b/drivers/media/platform/soc_camera/soc_camera.c
> index 46c7186f7867..039524a20056 100644
> --- a/drivers/media/platform/soc_camera/soc_camera.c
> +++ b/drivers/media/platform/soc_camera/soc_camera.c
> @@ -204,12 +204,7 @@ static void soc_camera_clock_stop(struct soc_camera_host 
> *ici)
>  const struct soc_camera_format_xlate *soc_camera_xlate_by_fourcc(
>   struct soc_camera_device *icd, unsigned int fourcc)
>  {
> - unsigned int i;
> -
> - for (i = 0; i < icd->num_user_formats; i++)
> - if (icd->user_formats[i].host_fmt->fourcc == fourcc)
> - return icd->user_formats + i;
> - return NULL;
> + return soc_mbus_xlate_by_fourcc(icd->user_formats, fourcc);
>  }
>  EXPORT_SYMBOL(soc_camera_xlate_by_fourcc);
>  
> diff --git a/drivers/media/platform/soc_camera/soc_mediabus.c 
> b/drivers/media/platform/soc_camera/soc_mediabus.c
> index e3e665e1c503..95c13055f50f 100644
> --- a/drivers/media/platform/soc_camera/soc_mediabus.c
> +++ b/drivers/media/platform/soc_camera/soc_mediabus.c
> @@ -10,6 +10,7 @@
>  
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -512,6 +513,70 @@ unsigned int soc_mbus_config_compatible(const struct 
> v4l2_mbus_config *cfg,
>  }
>  EXPORT_SYMBOL(soc_mbus_config_compatible);
>  
> +struct soc_camera_format_xlate *soc_mbus_build_fmts_xlate(
> + struct v4l2_device *v4l2_dev, struct v4l2_subdev *subdev,
> + int (*get_formats)(struct v4l2_device *, unsigned int,
> +struct soc_camera_format_xlate *xlate))
> +{
> + unsigned int i, fmts = 0, raw_fmts = 0;
> + int ret;
> + struct v4l2_subdev_mbus_code_enum code = {
> + .which = V4L2_SUBDEV_FORMAT_ACTIVE,
> + };
> + struct soc_camera_format_xlate *user_formats;
> +
> + while (!v4l2_subdev_call(subdev, pad, enum_mbus_code, NULL, )) {
> + raw_fmts++;
> + code.index++;
> + }
> +
> + /*
> +  * First pass - only count formats this host-sensor
> +  * configuration can provide
> +  */
> + for (i = 0; i < raw_fmts; i++) {
> + ret = get_formats(v4l2_dev, i, NULL);
> + if (ret < 0)
> + return ERR_PTR(ret);
> + fmts += ret;
> + }
> +
> + if (!fmts)
> + return ERR_PTR(-ENXIO);
> +
> + user_formats = kcalloc(fmts + 1, sizeof(*user_formats), GFP_KERNEL);
> + if (!user_formats)
> + return ERR_PTR(-ENOMEM);
> +
> + /* Second pass - actually fill data formats */
> + fmts = 0;
> + for (i = 0; i < raw_fmts; i++) {
> + ret = get_formats(v4l2_dev, i, user_formats + fmts);
> + if (ret < 0)
> + goto egfmt;
> + fmts += ret;
> + }
> + user_formats[fmts].code = 0;
> +
> + return user_formats;
> +egfmt:
> + kfree(user_formats);
> + return ERR_PTR(ret);
> +}
> +EXPORT_SYMBOL(soc_mbus_build_fmts_xlate);
> +
> +const struct soc_camera_format_xlate *soc_mbus_xlate_by_fourcc(
> + struct soc_camera_format_xlate *user_formats, unsigned int fourcc)
> +{
> + unsigned int i;
> +
> + for (i = 0; user_formats[i].code; i++)
> + if (user_formats[i].host_fmt->fourcc == fourcc)
> + return user_formats + i;
> + return NULL;
> +}
> +EXPORT_SYMBOL(soc_mbus_xlate_by_fourcc);
> +
>  static int __init soc_mbus_init(void)
>  {
>   return 0;
> diff --git a/include/media/drv-intf/soc_mediabus.h 
> b/include/media/drv-intf/soc_mediabus.h
> index 2ff773785fb6..08af52f6338c 100644
> --- a/include/media/drv-intf/soc_mediabus.h
> +++ b/include/media/drv-intf/soc_mediabus.h
> @@ -95,6 +95,21 @@ struct 

Re: [PATCH v3 00/14] use of_platform_default_populate() to populate default bus

[Kefeng Wang]

Hi all,

On 2016/4/5 13:59, Kefeng Wang wrote:
> Use helper of_platform_default_populate() in linux/of_platform
> when possible, instead of calling of_platform_populate() with
> the default match table.
> 
> Then it is possible for driver code build as a module, and no
> need to export of_default_bus_match_table anymore.
> 
> This patchset is based on Linux 4.6-rc2.

This patchset isn't a big change, and almost all patches has been added ack or 
review.
Is it possible to be merged in v4.7, and could anyone help me to pick up them?

Thanks
Kefeng


> 
> Changes since v2:
> - Add more acks
> - Update based on v4.6-rc2, of-generic.c in sh and board-artpec6.c in arm
>   are considered
> 
> Changes since v1:
> - Add ack, test and review
> - Remove v1 patch 14/15, the similar patch has posted and applied,
>   see https://patchwork.kernel.org/patch/8096991/
> 

Re: [PATCH v3 00/14] use of_platform_default_populate() to populate default bus

[Kefeng Wang]

Hi all,

On 2016/4/5 13:59, Kefeng Wang wrote:
> Use helper of_platform_default_populate() in linux/of_platform
> when possible, instead of calling of_platform_populate() with
> the default match table.
> 
> Then it is possible for driver code build as a module, and no
> need to export of_default_bus_match_table anymore.
> 
> This patchset is based on Linux 4.6-rc2.

This patchset isn't a big change, and almost all patches has been added ack or 
review.
Is it possible to be merged in v4.7, and could anyone help me to pick up them?

Thanks
Kefeng


> 
> Changes since v2:
> - Add more acks
> - Update based on v4.6-rc2, of-generic.c in sh and board-artpec6.c in arm
>   are considered
> 
> Changes since v1:
> - Add ack, test and review
> - Remove v1 patch 14/15, the similar patch has posted and applied,
>   see https://patchwork.kernel.org/patch/8096991/
> 

Re: [PATCH v1] block: make sure big bio is splitted into at most 256 bvecs

[Kent Overstreet]

On Wed, Apr 06, 2016 at 11:43:32AM +0800, Ming Lei wrote:
> After arbitrary bio size is supported, the incoming bio may
> be very big. We have to split the bio into small bios so that
> each holds at most BIO_MAX_PAGES bvecs for safety reason, such
> as bio_clone().
> 
> This patch fixes the following kernel crash:
> 
> > [  172.660142] BUG: unable to handle kernel NULL pointer dereference at 
> > 0028
> > [  172.660229] IP: [] bio_trim+0xf/0x2a
> > [  172.660289] PGD 7faf3e067 PUD 7f9279067 PMD 0
> > [  172.660399] Oops:  [#1] SMP
> > [...]
> > [  172.664780] Call Trace:
> > [  172.664813]  [] ? raid1_make_request+0x2e8/0xad7 
> > [raid1]
> > [  172.664846]  [] ? blk_queue_split+0x377/0x3d4
> > [  172.664880]  [] ? md_make_request+0xf6/0x1e9 [md_mod]
> > [  172.664912]  [] ? generic_make_request+0xb5/0x155
> > [  172.664947]  [] ? prio_io+0x85/0x95 [bcache]
> > [  172.664981]  [] ? register_cache_set+0x355/0x8d0 
> > [bcache]
> > [  172.665016]  [] ? register_bcache+0x1006/0x1174 
> > [bcache]
> 
> Fixes: 54efd50(block: make generic_make_request handle arbitrarily sized bios)
> Reported-by: Sebastian Roesner 
> Reported-by: Eric Wheeler 
> Cc: sta...@vger.kernel.org (4.3+)
> Cc: Shaohua Li 
> Cc: Kent Overstreet 
> Signed-off-by: Ming Lei 

That'll work

Acked-by: Kent Overstreet 

> ---
> V1:
>   - Kent pointed out that using max io size can't cover
>   the case of non-full bvecs/pages
> 
> The issue can be reproduced by the following approach:
> - create one raid1 over two virtio-blk
> - build bcache device over the above raid1 and another cache device
>   and bucket size is set 2Mbytes
> - set cache mode as writeback
> - run random write over ext4 on the bcache device
> - then the crash can be triggered
> 
>  block/blk-merge.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index 2613531..7b96471 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -94,8 +94,10 @@ static struct bio *blk_bio_segment_split(struct 
> request_queue *q,
>   bool do_split = true;
>   struct bio *new = NULL;
>   const unsigned max_sectors = get_max_io_size(q, bio);
> + unsigned bvecs = 0;
>  
>   bio_for_each_segment(bv, bio, iter) {
> + bvecs++;
>   /*
>* If the queue doesn't support SG gaps and adding this
>* offset would create a gap, disallow it.
> @@ -103,6 +105,23 @@ static struct bio *blk_bio_segment_split(struct 
> request_queue *q,
>   if (bvprvp && bvec_gap_to_prev(q, bvprvp, bv.bv_offset))
>   goto split;
>  
> + /*
> +  * With arbitrary bio size, the incoming bio may be very
> +  * big. We have to split the bio into small bios so that
> +  * each holds at most BIO_MAX_PAGES bvecs because
> +  * bio_clone() can fail to allocate big bvecs.
> +  *
> +  * It should have been better to apply the limit per
> +  * request queue in which bio_clone() is involved,
> +  * instead of globally. The biggest blocker is
> +  * bio_clone() in bio bounce.
> +  *
> +  * TODO: deal with bio bounce's bio_clone() gracefully
> +  * and convert the global limit into per-queue limit.
> +  */
> + if (bvecs >= BIO_MAX_PAGES)
> + goto split;
> +
>   if (sectors + (bv.bv_len >> 9) > max_sectors) {
>   /*
>* Consider this a new segment if we're splitting in
> -- 
> 1.9.1
> 

Re: [PATCH v1] block: make sure big bio is splitted into at most 256 bvecs

[Kent Overstreet]

On Wed, Apr 06, 2016 at 11:43:32AM +0800, Ming Lei wrote:
> After arbitrary bio size is supported, the incoming bio may
> be very big. We have to split the bio into small bios so that
> each holds at most BIO_MAX_PAGES bvecs for safety reason, such
> as bio_clone().
> 
> This patch fixes the following kernel crash:
> 
> > [  172.660142] BUG: unable to handle kernel NULL pointer dereference at 
> > 0028
> > [  172.660229] IP: [] bio_trim+0xf/0x2a
> > [  172.660289] PGD 7faf3e067 PUD 7f9279067 PMD 0
> > [  172.660399] Oops:  [#1] SMP
> > [...]
> > [  172.664780] Call Trace:
> > [  172.664813]  [] ? raid1_make_request+0x2e8/0xad7 
> > [raid1]
> > [  172.664846]  [] ? blk_queue_split+0x377/0x3d4
> > [  172.664880]  [] ? md_make_request+0xf6/0x1e9 [md_mod]
> > [  172.664912]  [] ? generic_make_request+0xb5/0x155
> > [  172.664947]  [] ? prio_io+0x85/0x95 [bcache]
> > [  172.664981]  [] ? register_cache_set+0x355/0x8d0 
> > [bcache]
> > [  172.665016]  [] ? register_bcache+0x1006/0x1174 
> > [bcache]
> 
> Fixes: 54efd50(block: make generic_make_request handle arbitrarily sized bios)
> Reported-by: Sebastian Roesner 
> Reported-by: Eric Wheeler 
> Cc: sta...@vger.kernel.org (4.3+)
> Cc: Shaohua Li 
> Cc: Kent Overstreet 
> Signed-off-by: Ming Lei 

That'll work

Acked-by: Kent Overstreet 

> ---
> V1:
>   - Kent pointed out that using max io size can't cover
>   the case of non-full bvecs/pages
> 
> The issue can be reproduced by the following approach:
> - create one raid1 over two virtio-blk
> - build bcache device over the above raid1 and another cache device
>   and bucket size is set 2Mbytes
> - set cache mode as writeback
> - run random write over ext4 on the bcache device
> - then the crash can be triggered
> 
>  block/blk-merge.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index 2613531..7b96471 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -94,8 +94,10 @@ static struct bio *blk_bio_segment_split(struct 
> request_queue *q,
>   bool do_split = true;
>   struct bio *new = NULL;
>   const unsigned max_sectors = get_max_io_size(q, bio);
> + unsigned bvecs = 0;
>  
>   bio_for_each_segment(bv, bio, iter) {
> + bvecs++;
>   /*
>* If the queue doesn't support SG gaps and adding this
>* offset would create a gap, disallow it.
> @@ -103,6 +105,23 @@ static struct bio *blk_bio_segment_split(struct 
> request_queue *q,
>   if (bvprvp && bvec_gap_to_prev(q, bvprvp, bv.bv_offset))
>   goto split;
>  
> + /*
> +  * With arbitrary bio size, the incoming bio may be very
> +  * big. We have to split the bio into small bios so that
> +  * each holds at most BIO_MAX_PAGES bvecs because
> +  * bio_clone() can fail to allocate big bvecs.
> +  *
> +  * It should have been better to apply the limit per
> +  * request queue in which bio_clone() is involved,
> +  * instead of globally. The biggest blocker is
> +  * bio_clone() in bio bounce.
> +  *
> +  * TODO: deal with bio bounce's bio_clone() gracefully
> +  * and convert the global limit into per-queue limit.
> +  */
> + if (bvecs >= BIO_MAX_PAGES)
> + goto split;
> +
>   if (sectors + (bv.bv_len >> 9) > max_sectors) {
>   /*
>* Consider this a new segment if we're splitting in
> -- 
> 1.9.1
> 

[PATCH v2] fs: return EPERM on immutable inode

[Eryu Guan]

In most cases, EPERM is returned on immutable inode, and there're only a
few places returning EACCES. I noticed this when running LTP on
overlayfs, setxattr03 failed due to unexpected EACCES on immutable
inode.

So converting all EACCES to EPERM on immutable inode.

Acked-by: Dave Chinner 
Signed-off-by: Eryu Guan 
---
v2:
- update commit message to include the background on noticing this issue

 fs/gfs2/inode.c| 2 +-
 fs/namei.c | 2 +-
 fs/utimes.c| 3 ++-
 fs/xfs/xfs_ioctl.c | 2 +-
 4 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c
index bb30f9a..4c68d91 100644
--- a/fs/gfs2/inode.c
+++ b/fs/gfs2/inode.c
@@ -1757,7 +1757,7 @@ int gfs2_permission(struct inode *inode, int mask)
}
 
if ((mask & MAY_WRITE) && IS_IMMUTABLE(inode))
-   error = -EACCES;
+   error = -EPERM;
else
error = generic_permission(inode, mask);
if (unlock)
diff --git a/fs/namei.c b/fs/namei.c
index 1d9ca2d..7f4a40a 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -408,7 +408,7 @@ int __inode_permission(struct inode *inode, int mask)
 * Nobody gets write access to an immutable file.
 */
if (IS_IMMUTABLE(inode))
-   return -EACCES;
+   return -EPERM;
}
 
retval = do_inode_permission(inode, mask);
diff --git a/fs/utimes.c b/fs/utimes.c
index 85c40f4..794f5f5 100644
--- a/fs/utimes.c
+++ b/fs/utimes.c
@@ -92,10 +92,11 @@ static int utimes_common(struct path *path, struct timespec 
*times)
 * then we need to check permissions, because
 * inode_change_ok() won't do it.
 */
-   error = -EACCES;
+   error = -EPERM;
 if (IS_IMMUTABLE(inode))
goto mnt_drop_write_and_out;
 
+   error = -EACCES;
if (!inode_owner_or_capable(inode)) {
error = inode_permission(inode, MAY_WRITE);
if (error)
diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
index bcb6c19..4c4c58f 100644
--- a/fs/xfs/xfs_ioctl.c
+++ b/fs/xfs/xfs_ioctl.c
@@ -232,7 +232,7 @@ xfs_open_by_handle(
}
 
if ((fmode & FMODE_WRITE) && IS_IMMUTABLE(inode)) {
-   error = -EACCES;
+   error = -EPERM;
goto out_dput;
}
 
-- 
2.5.5

[PATCH v2] fs: return EPERM on immutable inode

[Eryu Guan]

In most cases, EPERM is returned on immutable inode, and there're only a
few places returning EACCES. I noticed this when running LTP on
overlayfs, setxattr03 failed due to unexpected EACCES on immutable
inode.

So converting all EACCES to EPERM on immutable inode.

Acked-by: Dave Chinner 
Signed-off-by: Eryu Guan 
---
v2:
- update commit message to include the background on noticing this issue

 fs/gfs2/inode.c| 2 +-
 fs/namei.c | 2 +-
 fs/utimes.c| 3 ++-
 fs/xfs/xfs_ioctl.c | 2 +-
 4 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/fs/gfs2/inode.c b/fs/gfs2/inode.c
index bb30f9a..4c68d91 100644
--- a/fs/gfs2/inode.c
+++ b/fs/gfs2/inode.c
@@ -1757,7 +1757,7 @@ int gfs2_permission(struct inode *inode, int mask)
}
 
if ((mask & MAY_WRITE) && IS_IMMUTABLE(inode))
-   error = -EACCES;
+   error = -EPERM;
else
error = generic_permission(inode, mask);
if (unlock)
diff --git a/fs/namei.c b/fs/namei.c
index 1d9ca2d..7f4a40a 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -408,7 +408,7 @@ int __inode_permission(struct inode *inode, int mask)
 * Nobody gets write access to an immutable file.
 */
if (IS_IMMUTABLE(inode))
-   return -EACCES;
+   return -EPERM;
}
 
retval = do_inode_permission(inode, mask);
diff --git a/fs/utimes.c b/fs/utimes.c
index 85c40f4..794f5f5 100644
--- a/fs/utimes.c
+++ b/fs/utimes.c
@@ -92,10 +92,11 @@ static int utimes_common(struct path *path, struct timespec 
*times)
 * then we need to check permissions, because
 * inode_change_ok() won't do it.
 */
-   error = -EACCES;
+   error = -EPERM;
 if (IS_IMMUTABLE(inode))
goto mnt_drop_write_and_out;
 
+   error = -EACCES;
if (!inode_owner_or_capable(inode)) {
error = inode_permission(inode, MAY_WRITE);
if (error)
diff --git a/fs/xfs/xfs_ioctl.c b/fs/xfs/xfs_ioctl.c
index bcb6c19..4c4c58f 100644
--- a/fs/xfs/xfs_ioctl.c
+++ b/fs/xfs/xfs_ioctl.c
@@ -232,7 +232,7 @@ xfs_open_by_handle(
}
 
if ((fmode & FMODE_WRITE) && IS_IMMUTABLE(inode)) {
-   error = -EACCES;
+   error = -EPERM;
goto out_dput;
}
 
-- 
2.5.5

[PATCH v1] block: make sure big bio is splitted into at most 256 bvecs

[Ming Lei]

After arbitrary bio size is supported, the incoming bio may
be very big. We have to split the bio into small bios so that
each holds at most BIO_MAX_PAGES bvecs for safety reason, such
as bio_clone().

This patch fixes the following kernel crash:

> [  172.660142] BUG: unable to handle kernel NULL pointer dereference at 
> 0028
> [  172.660229] IP: [] bio_trim+0xf/0x2a
> [  172.660289] PGD 7faf3e067 PUD 7f9279067 PMD 0
> [  172.660399] Oops:  [#1] SMP
> [...]
> [  172.664780] Call Trace:
> [  172.664813]  [] ? raid1_make_request+0x2e8/0xad7 [raid1]
> [  172.664846]  [] ? blk_queue_split+0x377/0x3d4
> [  172.664880]  [] ? md_make_request+0xf6/0x1e9 [md_mod]
> [  172.664912]  [] ? generic_make_request+0xb5/0x155
> [  172.664947]  [] ? prio_io+0x85/0x95 [bcache]
> [  172.664981]  [] ? register_cache_set+0x355/0x8d0 [bcache]
> [  172.665016]  [] ? register_bcache+0x1006/0x1174 [bcache]

Fixes: 54efd50(block: make generic_make_request handle arbitrarily sized bios)
Reported-by: Sebastian Roesner 
Reported-by: Eric Wheeler 
Cc: sta...@vger.kernel.org (4.3+)
Cc: Shaohua Li 
Cc: Kent Overstreet 
Signed-off-by: Ming Lei 
---
V1:
- Kent pointed out that using max io size can't cover
the case of non-full bvecs/pages

The issue can be reproduced by the following approach:
- create one raid1 over two virtio-blk
- build bcache device over the above raid1 and another cache device
and bucket size is set 2Mbytes
- set cache mode as writeback
- run random write over ext4 on the bcache device
- then the crash can be triggered

 block/blk-merge.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/block/blk-merge.c b/block/blk-merge.c
index 2613531..7b96471 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -94,8 +94,10 @@ static struct bio *blk_bio_segment_split(struct 
request_queue *q,
bool do_split = true;
struct bio *new = NULL;
const unsigned max_sectors = get_max_io_size(q, bio);
+   unsigned bvecs = 0;
 
bio_for_each_segment(bv, bio, iter) {
+   bvecs++;
/*
 * If the queue doesn't support SG gaps and adding this
 * offset would create a gap, disallow it.
@@ -103,6 +105,23 @@ static struct bio *blk_bio_segment_split(struct 
request_queue *q,
if (bvprvp && bvec_gap_to_prev(q, bvprvp, bv.bv_offset))
goto split;
 
+   /*
+* With arbitrary bio size, the incoming bio may be very
+* big. We have to split the bio into small bios so that
+* each holds at most BIO_MAX_PAGES bvecs because
+* bio_clone() can fail to allocate big bvecs.
+*
+* It should have been better to apply the limit per
+* request queue in which bio_clone() is involved,
+* instead of globally. The biggest blocker is
+* bio_clone() in bio bounce.
+*
+* TODO: deal with bio bounce's bio_clone() gracefully
+* and convert the global limit into per-queue limit.
+*/
+   if (bvecs >= BIO_MAX_PAGES)
+   goto split;
+
if (sectors + (bv.bv_len >> 9) > max_sectors) {
/*
 * Consider this a new segment if we're splitting in
-- 
1.9.1

[PATCH v1] block: make sure big bio is splitted into at most 256 bvecs

[Ming Lei]

After arbitrary bio size is supported, the incoming bio may
be very big. We have to split the bio into small bios so that
each holds at most BIO_MAX_PAGES bvecs for safety reason, such
as bio_clone().

This patch fixes the following kernel crash:

> [  172.660142] BUG: unable to handle kernel NULL pointer dereference at 
> 0028
> [  172.660229] IP: [] bio_trim+0xf/0x2a
> [  172.660289] PGD 7faf3e067 PUD 7f9279067 PMD 0
> [  172.660399] Oops:  [#1] SMP
> [...]
> [  172.664780] Call Trace:
> [  172.664813]  [] ? raid1_make_request+0x2e8/0xad7 [raid1]
> [  172.664846]  [] ? blk_queue_split+0x377/0x3d4
> [  172.664880]  [] ? md_make_request+0xf6/0x1e9 [md_mod]
> [  172.664912]  [] ? generic_make_request+0xb5/0x155
> [  172.664947]  [] ? prio_io+0x85/0x95 [bcache]
> [  172.664981]  [] ? register_cache_set+0x355/0x8d0 [bcache]
> [  172.665016]  [] ? register_bcache+0x1006/0x1174 [bcache]

Fixes: 54efd50(block: make generic_make_request handle arbitrarily sized bios)
Reported-by: Sebastian Roesner 
Reported-by: Eric Wheeler 
Cc: sta...@vger.kernel.org (4.3+)
Cc: Shaohua Li 
Cc: Kent Overstreet 
Signed-off-by: Ming Lei 
---
V1:
- Kent pointed out that using max io size can't cover
the case of non-full bvecs/pages

The issue can be reproduced by the following approach:
- create one raid1 over two virtio-blk
- build bcache device over the above raid1 and another cache device
and bucket size is set 2Mbytes
- set cache mode as writeback
- run random write over ext4 on the bcache device
- then the crash can be triggered

 block/blk-merge.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/block/blk-merge.c b/block/blk-merge.c
index 2613531..7b96471 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -94,8 +94,10 @@ static struct bio *blk_bio_segment_split(struct 
request_queue *q,
bool do_split = true;
struct bio *new = NULL;
const unsigned max_sectors = get_max_io_size(q, bio);
+   unsigned bvecs = 0;
 
bio_for_each_segment(bv, bio, iter) {
+   bvecs++;
/*
 * If the queue doesn't support SG gaps and adding this
 * offset would create a gap, disallow it.
@@ -103,6 +105,23 @@ static struct bio *blk_bio_segment_split(struct 
request_queue *q,
if (bvprvp && bvec_gap_to_prev(q, bvprvp, bv.bv_offset))
goto split;
 
+   /*
+* With arbitrary bio size, the incoming bio may be very
+* big. We have to split the bio into small bios so that
+* each holds at most BIO_MAX_PAGES bvecs because
+* bio_clone() can fail to allocate big bvecs.
+*
+* It should have been better to apply the limit per
+* request queue in which bio_clone() is involved,
+* instead of globally. The biggest blocker is
+* bio_clone() in bio bounce.
+*
+* TODO: deal with bio bounce's bio_clone() gracefully
+* and convert the global limit into per-queue limit.
+*/
+   if (bvecs >= BIO_MAX_PAGES)
+   goto split;
+
if (sectors + (bv.bv_len >> 9) > max_sectors) {
/*
 * Consider this a new segment if we're splitting in
-- 
1.9.1

Re: [PART1 RFC v3 12/12] svm: Manage vcpu load/unload when enable AVIC

[Suravee Suthikulpanit]

Radim,

On 04/05/2016 09:56 PM, Radim Krčmář wrote:

I meant to change the place where we remember that is_running must not
be true.  Something like

   svm_vcpu_blocking(struct kvm_vcpu *vcpu):
  vcpu->is_blocking = true;
  avic_set_running(vcpu, false);

   avic_vcpu_load(struct kvm_vcpu *vcpu, bool is_load):
  avic_set_running(vcpu, is_load && !vcpu->is_blocking)


I assume that you also imply that we would also need:

svm_vcpu_unblocking(struct kvm_vcpu *vcpu) {
avic_set_running(vcpu, false);
vcpu->is_blocking = false;
}

Thanks,
Suravee

Re: [PART1 RFC v3 12/12] svm: Manage vcpu load/unload when enable AVIC

[Suravee Suthikulpanit]

Radim,

On 04/05/2016 09:56 PM, Radim Krčmář wrote:

I meant to change the place where we remember that is_running must not
be true.  Something like

   svm_vcpu_blocking(struct kvm_vcpu *vcpu):
  vcpu->is_blocking = true;
  avic_set_running(vcpu, false);

   avic_vcpu_load(struct kvm_vcpu *vcpu, bool is_load):
  avic_set_running(vcpu, is_load && !vcpu->is_blocking)


I assume that you also imply that we would also need:

svm_vcpu_unblocking(struct kvm_vcpu *vcpu) {
avic_set_running(vcpu, false);
vcpu->is_blocking = false;
}

Thanks,
Suravee

Re: [RFC v5 7/7] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

[Yongji Xie]

On 2016/4/6 8:00, Gavin Shan wrote:

On Tue, Apr 05, 2016 at 09:46:44PM +0800, Yongji Xie wrote:

This patch enables mmapping MSI-X tables if
hardware supports interrupt remapping which
can ensure that a given pci device can only
shoot the MSIs assigned for it.

Signed-off-by: Yongji Xie 
---
drivers/vfio/pci/vfio_pci.c |9 +++--
drivers/vfio/pci/vfio_pci_private.h |1 +
drivers/vfio/pci/vfio_pci_rdwr.c|2 +-
3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index c60d790..ef02896 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -201,6 +201,10 @@ static int vfio_pci_enable(struct vfio_pci_device *vdev)
} else
vdev->msix_bar = 0xFF;

+   if (iommu_capable(pdev->dev.bus, IOMMU_CAP_INTR_REMAP) ||
+   pdev->bus->bus_flags | PCI_BUS_FLAGS_MSI_REMAP)
+   vdev->msi_remap = true;
+

I guess you probably need a "&" here. Otherwise, the condition
is always true.


Yes, you are right. I'll fix it.


if (!vfio_vga_disabled() && vfio_pci_is_vga(pdev))
vdev->has_vga = true;

@@ -635,7 +639,8 @@ static long vfio_pci_ioctl(void *device_data,
 VFIO_REGION_INFO_FLAG_WRITE;
if (vdev->bar_mmap_supported[info.index]) {
info.flags |= VFIO_REGION_INFO_FLAG_MMAP;
-   if (info.index == vdev->msix_bar) {
+   if (info.index == vdev->msix_bar &&
+   !vdev->msi_remap) {
ret = msix_sparse_mmap_cap(vdev, );
if (ret)
return ret;
@@ -1067,7 +1072,7 @@ static int vfio_pci_mmap(void *device_data, struct 
vm_area_struct *vma)
if (req_start + req_len > phys_len)
return -EINVAL;

-   if (index == vdev->msix_bar) {
+   if (index == vdev->msix_bar && !vdev->msi_remap) {
/*
 * Disallow mmaps overlapping the MSI-X table; users don't
 * get to touch this directly.  We could find somewhere
diff --git a/drivers/vfio/pci/vfio_pci_private.h 
b/drivers/vfio/pci/vfio_pci_private.h
index 0ea4c62..4f20963 100644
--- a/drivers/vfio/pci/vfio_pci_private.h
+++ b/drivers/vfio/pci/vfio_pci_private.h
@@ -78,6 +78,7 @@ struct vfio_pci_device {
int irq_type;
int num_regions;
struct vfio_pci_region  *region;
+   boolmsi_remap;
u8  msi_qmax;
u8  msix_bar;
u16 msix_size;
diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c
index 5ffd1d9..606ee3c 100644
--- a/drivers/vfio/pci/vfio_pci_rdwr.c
+++ b/drivers/vfio/pci/vfio_pci_rdwr.c
@@ -164,7 +164,7 @@ ssize_t vfio_pci_bar_rw(struct vfio_pci_device *vdev, char 
__user *buf,
} else
io = vdev->barmap[bar];

-   if (bar == vdev->msix_bar) {
+   if (bar == vdev->msix_bar && !vdev->msi_remap) {
x_start = vdev->msix_offset;
x_end = vdev->msix_offset + vdev->msix_size;
}

When PCI_BUS_FLAGS_MSI_REMAP is set, the MSIx table can be accessed by
read/write interface except mmap(). The commit log doesn't mention it.
It would be better if you have some words about it.

Thanks,
Gavin



OK. I will mention it in commit log.

Thanks,
Yongji


--
1.7.9.5

Re: [RFC v5 7/7] vfio-pci: Allow to mmap MSI-X table if interrupt remapping is supported

[Yongji Xie]

On 2016/4/6 8:00, Gavin Shan wrote:

On Tue, Apr 05, 2016 at 09:46:44PM +0800, Yongji Xie wrote:

This patch enables mmapping MSI-X tables if
hardware supports interrupt remapping which
can ensure that a given pci device can only
shoot the MSIs assigned for it.

Signed-off-by: Yongji Xie 
---
drivers/vfio/pci/vfio_pci.c |9 +++--
drivers/vfio/pci/vfio_pci_private.h |1 +
drivers/vfio/pci/vfio_pci_rdwr.c|2 +-
3 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index c60d790..ef02896 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -201,6 +201,10 @@ static int vfio_pci_enable(struct vfio_pci_device *vdev)
} else
vdev->msix_bar = 0xFF;

+   if (iommu_capable(pdev->dev.bus, IOMMU_CAP_INTR_REMAP) ||
+   pdev->bus->bus_flags | PCI_BUS_FLAGS_MSI_REMAP)
+   vdev->msi_remap = true;
+

I guess you probably need a "&" here. Otherwise, the condition
is always true.


Yes, you are right. I'll fix it.


if (!vfio_vga_disabled() && vfio_pci_is_vga(pdev))
vdev->has_vga = true;

@@ -635,7 +639,8 @@ static long vfio_pci_ioctl(void *device_data,
 VFIO_REGION_INFO_FLAG_WRITE;
if (vdev->bar_mmap_supported[info.index]) {
info.flags |= VFIO_REGION_INFO_FLAG_MMAP;
-   if (info.index == vdev->msix_bar) {
+   if (info.index == vdev->msix_bar &&
+   !vdev->msi_remap) {
ret = msix_sparse_mmap_cap(vdev, );
if (ret)
return ret;
@@ -1067,7 +1072,7 @@ static int vfio_pci_mmap(void *device_data, struct 
vm_area_struct *vma)
if (req_start + req_len > phys_len)
return -EINVAL;

-   if (index == vdev->msix_bar) {
+   if (index == vdev->msix_bar && !vdev->msi_remap) {
/*
 * Disallow mmaps overlapping the MSI-X table; users don't
 * get to touch this directly.  We could find somewhere
diff --git a/drivers/vfio/pci/vfio_pci_private.h 
b/drivers/vfio/pci/vfio_pci_private.h
index 0ea4c62..4f20963 100644
--- a/drivers/vfio/pci/vfio_pci_private.h
+++ b/drivers/vfio/pci/vfio_pci_private.h
@@ -78,6 +78,7 @@ struct vfio_pci_device {
int irq_type;
int num_regions;
struct vfio_pci_region  *region;
+   boolmsi_remap;
u8  msi_qmax;
u8  msix_bar;
u16 msix_size;
diff --git a/drivers/vfio/pci/vfio_pci_rdwr.c b/drivers/vfio/pci/vfio_pci_rdwr.c
index 5ffd1d9..606ee3c 100644
--- a/drivers/vfio/pci/vfio_pci_rdwr.c
+++ b/drivers/vfio/pci/vfio_pci_rdwr.c
@@ -164,7 +164,7 @@ ssize_t vfio_pci_bar_rw(struct vfio_pci_device *vdev, char 
__user *buf,
} else
io = vdev->barmap[bar];

-   if (bar == vdev->msix_bar) {
+   if (bar == vdev->msix_bar && !vdev->msi_remap) {
x_start = vdev->msix_offset;
x_end = vdev->msix_offset + vdev->msix_size;
}

When PCI_BUS_FLAGS_MSI_REMAP is set, the MSIx table can be accessed by
read/write interface except mmap(). The commit log doesn't mention it.
It would be better if you have some words about it.

Thanks,
Gavin



OK. I will mention it in commit log.

Thanks,
Yongji


--
1.7.9.5

Re: [PATCH 1/4] KVM: MMU: fix permission_fault()

[Xiao Guangrong]

On 03/30/2016 02:39 PM, Xiao Guangrong wrote:



On 03/30/2016 02:36 PM, Paolo Bonzini wrote:



On 30/03/2016 03:56, Xiao Guangrong wrote:

x86/access.flat is currently using the "other" definition, i.e., PFEC.PK
is only set if W=1 or CR0.WP=0 && PFEC.U=0 or PFEC.W=0.  Can you use it
(with ept=1 of course) to check what the processor is doing?


Sure.

And ept=1 is hard to trigger MMU issue, i am enabling PKEY on shadow
MMU, let's see what will happen. ;)


No, don't do that!

ept=1 lets you test what the processor does.  It means you cannot test
permission_fault(), but what we want here is just reverse engineering
the microcode.  ept=1 lets you do exactly that.


Yes, i got this point. Huaitong will do the test once the machine gets
free.


I tested it and it is failed:

test pte.p pte.user pde.p pde.user pde.a pde.pse pkru.wd pkey=1 user write efer.nx cr4.pke: FAIL: 
error code 27 expected 7

Dump mapping: address: 0x1234
--L4: 2ebe007
--L3: 2ebf007
--L2: 80002a5

So PFEC.PKEY is set even if the ordinary check failed (caused by pde.rw = 0), 
the kvm code is
right. :)

Re: [PATCH 1/4] KVM: MMU: fix permission_fault()

[Xiao Guangrong]

On 03/30/2016 02:39 PM, Xiao Guangrong wrote:



On 03/30/2016 02:36 PM, Paolo Bonzini wrote:



On 30/03/2016 03:56, Xiao Guangrong wrote:

x86/access.flat is currently using the "other" definition, i.e., PFEC.PK
is only set if W=1 or CR0.WP=0 && PFEC.U=0 or PFEC.W=0.  Can you use it
(with ept=1 of course) to check what the processor is doing?


Sure.

And ept=1 is hard to trigger MMU issue, i am enabling PKEY on shadow
MMU, let's see what will happen. ;)


No, don't do that!

ept=1 lets you test what the processor does.  It means you cannot test
permission_fault(), but what we want here is just reverse engineering
the microcode.  ept=1 lets you do exactly that.


Yes, i got this point. Huaitong will do the test once the machine gets
free.


I tested it and it is failed:

test pte.p pte.user pde.p pde.user pde.a pde.pse pkru.wd pkey=1 user write efer.nx cr4.pke: FAIL: 
error code 27 expected 7

Dump mapping: address: 0x1234
--L4: 2ebe007
--L3: 2ebf007
--L2: 80002a5

So PFEC.PKEY is set even if the ordinary check failed (caused by pde.rw = 0), 
the kvm code is
right. :)

RE: [PATCH v6 12/12] usb: host: xhci-plat: Add otg device to platform data

[Yoshihiro Shimoda]

Hi,

> Sent: Tuesday, April 05, 2016 11:05 PM
> 
> Host controllers that are part of an OTG/dual-role instance
> need to somehow pass the OTG controller device information
> to the HCD core.
> 
> We use platform data to pass the OTG controller device.
> 
> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/host/xhci-plat.c | 35 ---
>  include/linux/usb/xhci_pdriver.h |  3 +++
>  2 files changed, 31 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 5c15e9b..3d0f597 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -230,11 +230,20 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   goto put_usb3_hcd;
>   }
> 
> - ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
> + if (pdata->otg_dev)

I think that this should be changed like below:
if (pdata && pdata->otg_dev)

Otherwise, panic happened on my environment (arm64 / r8a7795 board) because the 
pdata was NULL.

> + ret = usb_otg_add_hcd(hcd, irq, IRQF_SHARED, pdata->otg_dev);
> + else
> + ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
> +
>   if (ret)
>   goto disable_usb_phy;
> 
> - ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
> + if (pdata->otg_dev)

Ditto.

> + ret = usb_otg_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED,
> +   pdata->otg_dev);
> + else
> + ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
> +
>   if (ret)
>   goto dealloc_usb2_hcd;
> 
> @@ -242,7 +251,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
> 
> 
>  dealloc_usb2_hcd:
> - usb_remove_hcd(hcd);
> + if (pdata->otg_dev)

Ditto.

> + usb_otg_remove_hcd(hcd);
> + else
> + usb_remove_hcd(hcd);
> 
>  disable_usb_phy:
>   usb_phy_shutdown(hcd->usb_phy);
> @@ -260,16 +272,25 @@ put_hcd:
>   return ret;
>  }
> 
> -static int xhci_plat_remove(struct platform_device *dev)
> +static int xhci_plat_remove(struct platform_device *pdev)
>  {
> - struct usb_hcd  *hcd = platform_get_drvdata(dev);
> + struct usb_hcd  *hcd = platform_get_drvdata(pdev);
>   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>   struct clk *clk = xhci->clk;
> + struct usb_xhci_pdata *pdata = dev_get_platdata(>dev);
> +
> + if (pdata->otg_dev)

Ditto.

> + usb_otg_remove_hcd(xhci->shared_hcd);
> + else
> + usb_remove_hcd(xhci->shared_hcd);
> 
> - usb_remove_hcd(xhci->shared_hcd);
>   usb_phy_shutdown(hcd->usb_phy);
> 
> - usb_remove_hcd(hcd);
> + if (pdata->otg_dev)

Ditto.

Best regards,
Yoshihiro Shimoda

> + usb_otg_remove_hcd(hcd);
> + else
> + usb_remove_hcd(hcd);
> +
>   usb_put_hcd(xhci->shared_hcd);
> 
>   if (!IS_ERR(clk))
> diff --git a/include/linux/usb/xhci_pdriver.h 
> b/include/linux/usb/xhci_pdriver.h
> index 376654b..5c68b83 100644
> --- a/include/linux/usb/xhci_pdriver.h
> +++ b/include/linux/usb/xhci_pdriver.h
> @@ -18,10 +18,13 @@
>   *
>   * @usb3_lpm_capable:determines if this xhci platform supports USB3
>   *   LPM capability
> + * @otg_dev: OTG controller device. Only requied if part of
> + *   OTG/dual-role.
>   *
>   */
>  struct usb_xhci_pdata {
>   unsignedusb3_lpm_capable:1;
> + struct device   *otg_dev;
>  };
> 
>  #endif /* __USB_CORE_XHCI_PDRIVER_H */
> --
> 2.5.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" 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 12/12] usb: host: xhci-plat: Add otg device to platform data

[Yoshihiro Shimoda]

Hi,

> Sent: Tuesday, April 05, 2016 11:05 PM
> 
> Host controllers that are part of an OTG/dual-role instance
> need to somehow pass the OTG controller device information
> to the HCD core.
> 
> We use platform data to pass the OTG controller device.
> 
> Signed-off-by: Roger Quadros 
> ---
>  drivers/usb/host/xhci-plat.c | 35 ---
>  include/linux/usb/xhci_pdriver.h |  3 +++
>  2 files changed, 31 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/usb/host/xhci-plat.c b/drivers/usb/host/xhci-plat.c
> index 5c15e9b..3d0f597 100644
> --- a/drivers/usb/host/xhci-plat.c
> +++ b/drivers/usb/host/xhci-plat.c
> @@ -230,11 +230,20 @@ static int xhci_plat_probe(struct platform_device *pdev)
>   goto put_usb3_hcd;
>   }
> 
> - ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
> + if (pdata->otg_dev)

I think that this should be changed like below:
if (pdata && pdata->otg_dev)

Otherwise, panic happened on my environment (arm64 / r8a7795 board) because the 
pdata was NULL.

> + ret = usb_otg_add_hcd(hcd, irq, IRQF_SHARED, pdata->otg_dev);
> + else
> + ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
> +
>   if (ret)
>   goto disable_usb_phy;
> 
> - ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
> + if (pdata->otg_dev)

Ditto.

> + ret = usb_otg_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED,
> +   pdata->otg_dev);
> + else
> + ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
> +
>   if (ret)
>   goto dealloc_usb2_hcd;
> 
> @@ -242,7 +251,10 @@ static int xhci_plat_probe(struct platform_device *pdev)
> 
> 
>  dealloc_usb2_hcd:
> - usb_remove_hcd(hcd);
> + if (pdata->otg_dev)

Ditto.

> + usb_otg_remove_hcd(hcd);
> + else
> + usb_remove_hcd(hcd);
> 
>  disable_usb_phy:
>   usb_phy_shutdown(hcd->usb_phy);
> @@ -260,16 +272,25 @@ put_hcd:
>   return ret;
>  }
> 
> -static int xhci_plat_remove(struct platform_device *dev)
> +static int xhci_plat_remove(struct platform_device *pdev)
>  {
> - struct usb_hcd  *hcd = platform_get_drvdata(dev);
> + struct usb_hcd  *hcd = platform_get_drvdata(pdev);
>   struct xhci_hcd *xhci = hcd_to_xhci(hcd);
>   struct clk *clk = xhci->clk;
> + struct usb_xhci_pdata *pdata = dev_get_platdata(>dev);
> +
> + if (pdata->otg_dev)

Ditto.

> + usb_otg_remove_hcd(xhci->shared_hcd);
> + else
> + usb_remove_hcd(xhci->shared_hcd);
> 
> - usb_remove_hcd(xhci->shared_hcd);
>   usb_phy_shutdown(hcd->usb_phy);
> 
> - usb_remove_hcd(hcd);
> + if (pdata->otg_dev)

Ditto.

Best regards,
Yoshihiro Shimoda

> + usb_otg_remove_hcd(hcd);
> + else
> + usb_remove_hcd(hcd);
> +
>   usb_put_hcd(xhci->shared_hcd);
> 
>   if (!IS_ERR(clk))
> diff --git a/include/linux/usb/xhci_pdriver.h 
> b/include/linux/usb/xhci_pdriver.h
> index 376654b..5c68b83 100644
> --- a/include/linux/usb/xhci_pdriver.h
> +++ b/include/linux/usb/xhci_pdriver.h
> @@ -18,10 +18,13 @@
>   *
>   * @usb3_lpm_capable:determines if this xhci platform supports USB3
>   *   LPM capability
> + * @otg_dev: OTG controller device. Only requied if part of
> + *   OTG/dual-role.
>   *
>   */
>  struct usb_xhci_pdata {
>   unsignedusb3_lpm_capable:1;
> + struct device   *otg_dev;
>  };
> 
>  #endif /* __USB_CORE_XHCI_PDRIVER_H */
> --
> 2.5.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC v5 6/7] PCI: Add a new bit to pci_bus_flags to indicate interrupt remapping

[Yongji Xie]

On 2016/4/6 8:11, Gavin Shan wrote:

On Tue, Apr 05, 2016 at 09:46:43PM +0800, Yongji Xie wrote:

I'm trying to find a proper way to indicate
the capability of interrupt remapping on PPC64
because we need this to determine whether it is
safe to mmap MSI-X table in VFIO driver.

There is a existing flag for this in the IOMMU
space:

enum iommu_cap {
IOMMU_CAP_CACHE_COHERENCY,
--->IOMMU_CAP_INTR_REMAP,
IOMMU_CAP_NOEXEC,
};

But it seems to be not a good idea to use
bus_set_iommu() to add this flag on PPC64 which
never set/use iommu_ops.

Eric also posted a patchset [1] to abstract
this capability on MSI controller side for ARM.
But I found we also never use msi_domain_info
on PPC64. We have to rework the MSI code on
PPC64 to support msi_domain_ops if we want to
use msi_domain_info.

Then I noticed that interrupt remapping is
abstracted on PCI host bridge side on PPC64.
So I'm thinking whether we could add a new
bit to pci_bus_flags to indicate this
capability, like this patch does.

Compared with IOMMU_CAP_INTR_REMAP, this
flag is more common. Any arch can set/use this
easily. And it can provide a better granularity
(pci_bus_type -> pci_bus).

[1] http://www.spinics.net/lists/kvm/msg130262.html

Signed-off-by: Yongji Xie 
---
arch/powerpc/platforms/powernv/pci-ioda.c |8 
include/linux/pci.h   |1 +
2 files changed, 9 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index f90dc04..9557638 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -3080,6 +3080,12 @@ static void pnv_pci_ioda_fixup(void)
pnv_npu_ioda_fixup();
}

+int pnv_pci_ioda_root_bridge_prepare(struct pci_host_bridge *bridge)
+{
+   bridge->bus->bus_flags |= PCI_BUS_FLAGS_MSI_REMAP;
+   return 0;
+}
+

A irelevent question: Here we set the flag unconditionally. Can the
MSIx table be exposed to user space unconditionally? Do we have issues
if the MSIx related BAR isn't page aligned or overlapped with others?


This flag is just used to indicate the capability of MSI
remapping which means PCI devices on this bus
can only shoot the MSIs assigned for them. It does
not mean MSIx table can be exposed to user space
unconditionally.


/*
  * Returns the alignment for I/O or memory windows for P2P
  * bridges. That actually depends on how PEs are segmented.
@@ -3364,6 +3370,8 @@ static void __init pnv_pci_init_ioda_phb(struct 
device_node *np,
 */
ppc_md.pcibios_fixup = pnv_pci_ioda_fixup;

+   ppc_md.pcibios_root_bridge_prepare = pnv_pci_ioda_root_bridge_prepare;
+
if (phb->type == PNV_PHB_NPU)
hose->controller_ops = pnv_npu_ioda_controller_ops;
else
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 27df4a6..741dcaf 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -193,6 +193,7 @@ typedef unsigned short __bitwise pci_bus_flags_t;
enum pci_bus_flags {
PCI_BUS_FLAGS_NO_MSI   = (__force pci_bus_flags_t) 1,
PCI_BUS_FLAGS_NO_MMRBC = (__force pci_bus_flags_t) 2,
+   PCI_BUS_FLAGS_MSI_REMAP = (__force pci_bus_flags_t) 3,

Yongji, I guess the corresponding value to PCI_BUS_FLAGS_MSI_REMAP
would be 4 other than 3. Otherwise, two of the flags cannot exist
at the same time.

Thanks,
Gavin


Yes, you are right. It should be 4 (1 << 2).

Thanks,
Yongji


};

/* These values come from the PCI Express Spec */
--
1.7.9.5

Re: [RFC v5 6/7] PCI: Add a new bit to pci_bus_flags to indicate interrupt remapping

[Yongji Xie]

On 2016/4/6 8:11, Gavin Shan wrote:

On Tue, Apr 05, 2016 at 09:46:43PM +0800, Yongji Xie wrote:

I'm trying to find a proper way to indicate
the capability of interrupt remapping on PPC64
because we need this to determine whether it is
safe to mmap MSI-X table in VFIO driver.

There is a existing flag for this in the IOMMU
space:

enum iommu_cap {
IOMMU_CAP_CACHE_COHERENCY,
--->IOMMU_CAP_INTR_REMAP,
IOMMU_CAP_NOEXEC,
};

But it seems to be not a good idea to use
bus_set_iommu() to add this flag on PPC64 which
never set/use iommu_ops.

Eric also posted a patchset [1] to abstract
this capability on MSI controller side for ARM.
But I found we also never use msi_domain_info
on PPC64. We have to rework the MSI code on
PPC64 to support msi_domain_ops if we want to
use msi_domain_info.

Then I noticed that interrupt remapping is
abstracted on PCI host bridge side on PPC64.
So I'm thinking whether we could add a new
bit to pci_bus_flags to indicate this
capability, like this patch does.

Compared with IOMMU_CAP_INTR_REMAP, this
flag is more common. Any arch can set/use this
easily. And it can provide a better granularity
(pci_bus_type -> pci_bus).

[1] http://www.spinics.net/lists/kvm/msg130262.html

Signed-off-by: Yongji Xie 
---
arch/powerpc/platforms/powernv/pci-ioda.c |8 
include/linux/pci.h   |1 +
2 files changed, 9 insertions(+)

diff --git a/arch/powerpc/platforms/powernv/pci-ioda.c 
b/arch/powerpc/platforms/powernv/pci-ioda.c
index f90dc04..9557638 100644
--- a/arch/powerpc/platforms/powernv/pci-ioda.c
+++ b/arch/powerpc/platforms/powernv/pci-ioda.c
@@ -3080,6 +3080,12 @@ static void pnv_pci_ioda_fixup(void)
pnv_npu_ioda_fixup();
}

+int pnv_pci_ioda_root_bridge_prepare(struct pci_host_bridge *bridge)
+{
+   bridge->bus->bus_flags |= PCI_BUS_FLAGS_MSI_REMAP;
+   return 0;
+}
+

A irelevent question: Here we set the flag unconditionally. Can the
MSIx table be exposed to user space unconditionally? Do we have issues
if the MSIx related BAR isn't page aligned or overlapped with others?


This flag is just used to indicate the capability of MSI
remapping which means PCI devices on this bus
can only shoot the MSIs assigned for them. It does
not mean MSIx table can be exposed to user space
unconditionally.


/*
  * Returns the alignment for I/O or memory windows for P2P
  * bridges. That actually depends on how PEs are segmented.
@@ -3364,6 +3370,8 @@ static void __init pnv_pci_init_ioda_phb(struct 
device_node *np,
 */
ppc_md.pcibios_fixup = pnv_pci_ioda_fixup;

+   ppc_md.pcibios_root_bridge_prepare = pnv_pci_ioda_root_bridge_prepare;
+
if (phb->type == PNV_PHB_NPU)
hose->controller_ops = pnv_npu_ioda_controller_ops;
else
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 27df4a6..741dcaf 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -193,6 +193,7 @@ typedef unsigned short __bitwise pci_bus_flags_t;
enum pci_bus_flags {
PCI_BUS_FLAGS_NO_MSI   = (__force pci_bus_flags_t) 1,
PCI_BUS_FLAGS_NO_MMRBC = (__force pci_bus_flags_t) 2,
+   PCI_BUS_FLAGS_MSI_REMAP = (__force pci_bus_flags_t) 3,

Yongji, I guess the corresponding value to PCI_BUS_FLAGS_MSI_REMAP
would be 4 other than 3. Otherwise, two of the flags cannot exist
at the same time.

Thanks,
Gavin


Yes, you are right. It should be 4 (1 << 2).

Thanks,
Yongji


};

/* These values come from the PCI Express Spec */
--
1.7.9.5

[REF PATCH] x86/tlb: just do tlb flush on one of siblings of SMT

[Alex Shi]

It seems Intel core still share the TLB pool, flush both of threads' TLB
just cause a extra useless IPI and a extra flush. The extra flush will 
flush out TLB again which another thread just introduced.
That's double waste.

The micro testing show memory access can save about 25% time on my 
haswell i7 desktop.
munmap source code is here: https://lkml.org/lkml/2012/5/17/59

test result on Kernel v4.5.0:
$/home/alexs/bin/perf stat -e 
dTLB-load-misses,dTLB-loads,dTLB-store-misses,dTLB-stores,iTLB-load-misses,iTLB-loads
 -e tlb:tlb_flush munmap -n 64 -t 16
munmap use 57ms 14072ns/time, memory access uses 48356 times/thread/ms, cost 
20ns/time

 Performance counter stats for '/home/alexs/backups/exec-laptop/tlb/munmap -n 
64 -t 16':

18,739,808  dTLB-load-misses  #2.47% of all dTLB cache 
hits   (43.05%)
   757,380,911  dTLB-loads  
  (34.34%)
 2,125,275  dTLB-store-misses   
  (32.23%)
   318,307,759  dTLB-stores 
  (46.32%)
32,765  iTLB-load-misses  #2.03% of all iTLB cache 
hits   (56.90%)
 1,616,237  iTLB-loads  
  (44.47%)
41,476  tlb:tlb_flush

   1.443484546 seconds time elapsed

/proc/vmstat/nr_tlb_remote_flush increased: 4616
/proc/vmstat/nr_tlb_remote_flush_received increased: 32262

test result on Kernel v4.5.0 + this patch:
$/home/alexs/bin/perf stat -e 
dTLB-load-misses,dTLB-loads,dTLB-store-misses,dTLB-stores,iTLB-load-misses,iTLB-loads
 -e tlb:tlb_flush munmap -n 64 -t 16
munmap use 48ms 11933ns/time, memory access uses 59966 times/thread/ms, cost 
16ns/time

 Performance counter stats for '/home/alexs/backups/exec-laptop/tlb/munmap -n 
64 -t 16':

15,984,772  dTLB-load-misses  #1.89% of all dTLB cache 
hits   (41.72%)
   844,099,241  dTLB-loads  
  (33.30%)
 1,328,102  dTLB-store-misses   
  (52.13%)
   280,902,875  dTLB-stores 
  (52.03%)
27,678  iTLB-load-misses  #1.67% of all iTLB cache 
hits   (35.35%)
 1,659,550  iTLB-loads  
  (38.38%)
25,137  tlb:tlb_flush

   1.428880301 seconds time elapsed

/proc/vmstat/nr_tlb_remote_flush increased: 4616
/proc/vmstat/nr_tlb_remote_flush_received increased: 15912

BTW, 
This change isn't architecturally guaranteed.

Signed-off-by: Alex Shi 
Cc: Andrew Morton 
To: linux-kernel@vger.kernel.org
To: Mel Gorman 
To: x...@kernel.org
To: "H. Peter Anvin" 
To: Thomas Gleixner 
Cc: Andy Lutomirski 
Cc: Rik van Riel 
Cc: Alex Shi 
---
 arch/x86/mm/tlb.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 8f4cc3d..6510316 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -134,7 +134,10 @@ void native_flush_tlb_others(const struct cpumask *cpumask,
 struct mm_struct *mm, unsigned long start,
 unsigned long end)
 {
+   int cpu;
struct flush_tlb_info info;
+   cpumask_t flush_mask, *sblmask;
+
info.flush_mm = mm;
info.flush_start = start;
info.flush_end = end;
@@ -151,7 +154,23 @@ void native_flush_tlb_others(const struct cpumask *cpumask,
, 1);
return;
}
-   smp_call_function_many(cpumask, flush_tlb_func, , 1);
+
+   if (unlikely(smp_num_siblings <= 1)) {
+   smp_call_function_many(cpumask, flush_tlb_func, , 1);
+   return;
+   }
+
+   /* Only one flush needed on both siblings of SMT */
+   cpumask_copy(_mask, cpumask);
+   for_each_cpu(cpu, _mask) {
+   sblmask = topology_sibling_cpumask(cpu);
+   if (!cpumask_subset(sblmask, _mask))
+   continue;
+
+   cpumask_clear_cpu(cpumask_next(cpu, sblmask), _mask);
+   }
+
+   smp_call_function_many(_mask, flush_tlb_func, , 1);
 }
 
 void flush_tlb_current_task(void)
-- 
2.7.2.333.g70bd996

[REF PATCH] x86/tlb: just do tlb flush on one of siblings of SMT

[Alex Shi]

It seems Intel core still share the TLB pool, flush both of threads' TLB
just cause a extra useless IPI and a extra flush. The extra flush will 
flush out TLB again which another thread just introduced.
That's double waste.

The micro testing show memory access can save about 25% time on my 
haswell i7 desktop.
munmap source code is here: https://lkml.org/lkml/2012/5/17/59

test result on Kernel v4.5.0:
$/home/alexs/bin/perf stat -e 
dTLB-load-misses,dTLB-loads,dTLB-store-misses,dTLB-stores,iTLB-load-misses,iTLB-loads
 -e tlb:tlb_flush munmap -n 64 -t 16
munmap use 57ms 14072ns/time, memory access uses 48356 times/thread/ms, cost 
20ns/time

 Performance counter stats for '/home/alexs/backups/exec-laptop/tlb/munmap -n 
64 -t 16':

18,739,808  dTLB-load-misses  #2.47% of all dTLB cache 
hits   (43.05%)
   757,380,911  dTLB-loads  
  (34.34%)
 2,125,275  dTLB-store-misses   
  (32.23%)
   318,307,759  dTLB-stores 
  (46.32%)
32,765  iTLB-load-misses  #2.03% of all iTLB cache 
hits   (56.90%)
 1,616,237  iTLB-loads  
  (44.47%)
41,476  tlb:tlb_flush

   1.443484546 seconds time elapsed

/proc/vmstat/nr_tlb_remote_flush increased: 4616
/proc/vmstat/nr_tlb_remote_flush_received increased: 32262

test result on Kernel v4.5.0 + this patch:
$/home/alexs/bin/perf stat -e 
dTLB-load-misses,dTLB-loads,dTLB-store-misses,dTLB-stores,iTLB-load-misses,iTLB-loads
 -e tlb:tlb_flush munmap -n 64 -t 16
munmap use 48ms 11933ns/time, memory access uses 59966 times/thread/ms, cost 
16ns/time

 Performance counter stats for '/home/alexs/backups/exec-laptop/tlb/munmap -n 
64 -t 16':

15,984,772  dTLB-load-misses  #1.89% of all dTLB cache 
hits   (41.72%)
   844,099,241  dTLB-loads  
  (33.30%)
 1,328,102  dTLB-store-misses   
  (52.13%)
   280,902,875  dTLB-stores 
  (52.03%)
27,678  iTLB-load-misses  #1.67% of all iTLB cache 
hits   (35.35%)
 1,659,550  iTLB-loads  
  (38.38%)
25,137  tlb:tlb_flush

   1.428880301 seconds time elapsed

/proc/vmstat/nr_tlb_remote_flush increased: 4616
/proc/vmstat/nr_tlb_remote_flush_received increased: 15912

BTW, 
This change isn't architecturally guaranteed.

Signed-off-by: Alex Shi 
Cc: Andrew Morton 
To: linux-kernel@vger.kernel.org
To: Mel Gorman 
To: x...@kernel.org
To: "H. Peter Anvin" 
To: Thomas Gleixner 
Cc: Andy Lutomirski 
Cc: Rik van Riel 
Cc: Alex Shi 
---
 arch/x86/mm/tlb.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c
index 8f4cc3d..6510316 100644
--- a/arch/x86/mm/tlb.c
+++ b/arch/x86/mm/tlb.c
@@ -134,7 +134,10 @@ void native_flush_tlb_others(const struct cpumask *cpumask,
 struct mm_struct *mm, unsigned long start,
 unsigned long end)
 {
+   int cpu;
struct flush_tlb_info info;
+   cpumask_t flush_mask, *sblmask;
+
info.flush_mm = mm;
info.flush_start = start;
info.flush_end = end;
@@ -151,7 +154,23 @@ void native_flush_tlb_others(const struct cpumask *cpumask,
, 1);
return;
}
-   smp_call_function_many(cpumask, flush_tlb_func, , 1);
+
+   if (unlikely(smp_num_siblings <= 1)) {
+   smp_call_function_many(cpumask, flush_tlb_func, , 1);
+   return;
+   }
+
+   /* Only one flush needed on both siblings of SMT */
+   cpumask_copy(_mask, cpumask);
+   for_each_cpu(cpu, _mask) {
+   sblmask = topology_sibling_cpumask(cpu);
+   if (!cpumask_subset(sblmask, _mask))
+   continue;
+
+   cpumask_clear_cpu(cpumask_next(cpu, sblmask), _mask);
+   }
+
+   smp_call_function_many(_mask, flush_tlb_func, , 1);
 }
 
 void flush_tlb_current_task(void)
-- 
2.7.2.333.g70bd996

Re: [PATCH net-next 1/3] net: dsa: make the STP state function return void

[Vivien Didelot]

Hi Andrew,

Andrew Lunn  writes:

>> -- port_stp_update: bridge layer function invoked when a given switch port 
>> STP
>> +- port_stp_state: bridge layer function invoked when a given switch port STP
>
> port_stp_state_set might be a better name, to make it clear it is
> setting the state, not getting the current state, etc. Most of the
> other functions are _add, _prepare, _join, _leave, so _set would fit
> the pattern.

I agree, I'm changing that.

> Changing to a void makes sense.

Thanks,
Vivien

Re: [PATCH net-next 1/3] net: dsa: make the STP state function return void

[Vivien Didelot]

Hi Andrew,

Andrew Lunn  writes:

>> -- port_stp_update: bridge layer function invoked when a given switch port 
>> STP
>> +- port_stp_state: bridge layer function invoked when a given switch port STP
>
> port_stp_state_set might be a better name, to make it clear it is
> setting the state, not getting the current state, etc. Most of the
> other functions are _add, _prepare, _join, _leave, so _set would fit
> the pattern.

I agree, I'm changing that.

> Changing to a void makes sense.

Thanks,
Vivien

Re: [PATCH net-next 2/3] net: dsa: make the FDB add function return void

[Vivien Didelot]

Hi Andrew,

Andrew Lunn  writes:

>>  mutex_lock(>smi_mutex);
>> -ret = _mv88e6xxx_port_fdb_load(ds, port, fdb->addr, fdb->vid, state);
>> +if (_mv88e6xxx_port_fdb_load(ds, port, fdb->addr, fdb->vid, state))
>> +netdev_warn(ds->ports[port], "cannot load address\n");
>
> In the SF2 driver you use pr_err, but here netdev_warn. We probably
> should be consistent if we error or warn. I would use netdev_error,
> since if this fails we probably have a real hardware problem.

I used pr_err in the SF2 driver to be consistent with the rest of the
code which only uses pr_err and pr_info.

I was thinking about adding ds_err and ds_port_err to print errors for
ds->master_dev and ds->ports[port], but that might be overkill. What do
you think? Or local to the driver for the moment, like mvsw_err maybe?

I tend to use warn for cases where the user cannot really do something
about the situation, but an hardware problem is indeed critical, so I
agree with you to use error over warn here.

Thanks,
Vivien

Re: [PATCH net-next 2/3] net: dsa: make the FDB add function return void

[Vivien Didelot]

Hi Andrew,

Andrew Lunn  writes:

>>  mutex_lock(>smi_mutex);
>> -ret = _mv88e6xxx_port_fdb_load(ds, port, fdb->addr, fdb->vid, state);
>> +if (_mv88e6xxx_port_fdb_load(ds, port, fdb->addr, fdb->vid, state))
>> +netdev_warn(ds->ports[port], "cannot load address\n");
>
> In the SF2 driver you use pr_err, but here netdev_warn. We probably
> should be consistent if we error or warn. I would use netdev_error,
> since if this fails we probably have a real hardware problem.

I used pr_err in the SF2 driver to be consistent with the rest of the
code which only uses pr_err and pr_info.

I was thinking about adding ds_err and ds_port_err to print errors for
ds->master_dev and ds->ports[port], but that might be overkill. What do
you think? Or local to the driver for the moment, like mvsw_err maybe?

I tend to use warn for cases where the user cannot really do something
about the situation, but an hardware problem is indeed critical, so I
agree with you to use error over warn here.

Thanks,
Vivien