date:20151004

From: Marek Belisko 

Code was found at:
https://android.googlesource.com/kernel/tegra/+/a90856a6626d502d42c6e7abccbdf9d730b36270%5E%21/#F1

Signed-off-by: Laxman Dewangan 
[Fixed minor typos + add channels list to documentation]
Signed-off-by: Marek Belisko 
---
 .../devicetree/bindings/iio/adc/palmas-gpadc.txt   | 46 +++
 drivers/iio/adc/palmas_gpadc.c | 52 +++---
 2 files changed, 93 insertions(+), 5 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt

diff --git a/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt 
b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
new file mode 100644
index 000..2149afe
--- /dev/null
+++ b/Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
@@ -0,0 +1,46 @@
+* Palmas general purpose ADC IP block devicetree bindings
+
+Channels list:
+   0 battery type
+   1 battery temp NTC (optional current source)
+   2 GP
+   3 temp (with ext. diode, optional current source)
+   4 GP
+   5 GP
+   6 VBAT_SENSE
+   7 VCC_SENSE
+   8 Backup Battery voltage
+   9 external charger (VCHG)
+   10 VBUS
+   11 DC-DC current probe (how does this work?)
+   12 internal die temp
+   13 internal die temp
+   14 USB ID pin voltage
+   15 test network
+
+Required properties:
+- compatible : Must be "ti,palmas-gpadc".
+
+Optional sub-nodes:
+ti,channel0-current-microamp: Channel 0 current in uA.
+   Values are rounded to derive 0uA, 5uA, 15uA, 20uA.
+ti,channel3-current-microamp: Channel 3 current in uA.
+   Valid are rounded to derive 0uA, 10uA, 400uA, 800uA.
+ti,enable-extended-delay: Enable extended delay.
+
+Example:
+
+pmic {
+   compatible = "ti,twl6035-pmic", "ti,palmas-pmic";
+   ...
+   gpadc {
+   compatible = "ti,palmas-gpadc";
+   interrupts = <18 0
+ 16 0
+ 17 0>;
+   ti,channel0-current-microamp = <5>;
+   ti,channel3-current-microamp = <10>;
+   };
+   };
+   ...
+};
diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
index 6805d81..1297c81 100644
--- a/drivers/iio/adc/palmas_gpadc.c
+++ b/drivers/iio/adc/palmas_gpadc.c
@@ -21,6 +21,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -460,6 +462,34 @@ static const struct iio_chan_spec 
palmas_gpadc_iio_channel[] = {
PALMAS_ADC_CHAN_IIO(IN15, IIO_VOLTAGE, IIO_CHAN_INFO_PROCESSED),
 };
 
+static int palmas_gpadc_get_adc_dt_data(struct platform_device *pdev,
+   struct palmas_gpadc_platform_data **gpadc_pdata)
+{
+   struct device_node *np = pdev->dev.of_node;
+   struct palmas_gpadc_platform_data *gp_data;
+   int ret;
+   u32 pval;
+
+   gp_data = devm_kzalloc(&pdev->dev, sizeof(*gp_data), GFP_KERNEL);
+   if (!gp_data)
+   return -ENOMEM;
+
+   ret = of_property_read_u32(np, "ti,channel0-current-microamp", &pval);
+   if (!ret)
+   gp_data->ch0_current = pval;
+
+   ret = of_property_read_u32(np, "ti,channel3-current-microamp", &pval);
+   if (!ret)
+   gp_data->ch3_current = pval;
+
+   gp_data->extended_delay = of_property_read_bool(np,
+   "ti,enable-extended-delay");
+
+   *gpadc_pdata = gp_data;
+
+   return 0;
+}
+
 static int palmas_gpadc_probe(struct platform_device *pdev)
 {
struct palmas_gpadc *adc;
@@ -469,12 +499,17 @@ static int palmas_gpadc_probe(struct platform_device 
*pdev)
int ret, i;
 
pdata = dev_get_platdata(pdev->dev.parent);
-   if (!pdata || !pdata->gpadc_pdata) {
-   dev_err(&pdev->dev, "No platform data\n");
-   return -ENODEV;
-   }
 
-   gpadc_pdata = pdata->gpadc_pdata;
+   if (pdata && pdata->gpadc_pdata)
+   gpadc_pdata = pdata->gpadc_pdata;
+
+   if (!gpadc_pdata && pdev->dev.of_node) {
+   ret = palmas_gpadc_get_adc_dt_data(pdev, &gpadc_pdata);
+   if (ret < 0)
+   return ret;
+   }
+   if (!gpadc_pdata)
+   return -EINVAL;
 
indio_dev = devm_iio_device_alloc(&pdev->dev, sizeof(*adc));
if (!indio_dev) {
@@ -790,6 +825,12 @@ static const struct dev_pm_ops palmas_pm_ops = {
palmas_gpadc_resume)
 };
 
+static const struct of_device_id of_palmas_gpadc_match_tbl[] = {
+   { .compatible = "ti,palmas-gpadc", },
+   { /* end */ }
+};
+MODULE_DEVICE_TABLE(of, of_palmas_gpadc_match_tbl);
+
 static struct platform_driver palmas_gpadc_driver = {
.probe = palmas_gpadc_probe,
.remove = palmas_gpadc_remove,
@@ -797,6 +838,7 @@ static struct platform_driver palmas_gpadc_driver = {
.name = MOD_NAME,
.owner = THIS_MODULE,
.pm = &palmas

[PATCH v2 1/3] iio:adc: add iio driver for Palmas (twl6035/7) gpadc

This driver code was found as:

https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc

Fixed various compilation issues and test this driver on omap5 evm.

Signed-off-by: Pradeep Goudagunta 
Signed-off-by: H. Nikolaus Schaller 
Signed-off-by: Marek Belisko 
---
 drivers/iio/adc/Kconfig|   9 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/palmas_gpadc.c | 818 +
 include/linux/mfd/palmas.h |  75 ++--
 4 files changed, 879 insertions(+), 24 deletions(-)
 create mode 100644 drivers/iio/adc/palmas_gpadc.c

diff --git a/drivers/iio/adc/Kconfig b/drivers/iio/adc/Kconfig
index eb0cd89..05a0368 100644
--- a/drivers/iio/adc/Kconfig
+++ b/drivers/iio/adc/Kconfig
@@ -242,6 +242,15 @@ config NAU7802
  To compile this driver as a module, choose M here: the
  module will be called nau7802.
 
+config PALMAS_GPADC
+   tristate "TI Palmas General Purpose ADC"
+   depends on MFD_PALMAS
+   help
+ Say yes here to build support for Texas Instruments Palmas.
+
+ Palmas series pmic chip (twl6035/6037) is used in smartphones and
+ tablets and supports a 16 channel general purpose ADC.
+
 config QCOM_SPMI_IADC
tristate "Qualcomm SPMI PMIC current ADC"
depends on SPMI
diff --git a/drivers/iio/adc/Makefile b/drivers/iio/adc/Makefile
index a096210..716f112 100644
--- a/drivers/iio/adc/Makefile
+++ b/drivers/iio/adc/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_MCP320X) += mcp320x.o
 obj-$(CONFIG_MCP3422) += mcp3422.o
 obj-$(CONFIG_MEN_Z188_ADC) += men_z188_adc.o
 obj-$(CONFIG_NAU7802) += nau7802.o
+obj-$(CONFIG_PALMAS_GPADC) += palmas_gpadc.o
 obj-$(CONFIG_QCOM_SPMI_IADC) += qcom-spmi-iadc.o
 obj-$(CONFIG_QCOM_SPMI_VADC) += qcom-spmi-vadc.o
 obj-$(CONFIG_ROCKCHIP_SARADC) += rockchip_saradc.o
diff --git a/drivers/iio/adc/palmas_gpadc.c b/drivers/iio/adc/palmas_gpadc.c
new file mode 100644
index 000..6805d81
--- /dev/null
+++ b/drivers/iio/adc/palmas_gpadc.c
@@ -0,0 +1,818 @@
+/*
+ * palmas-adc.c -- TI PALMAS GPADC.
+ *
+ * Copyright (c) 2013, NVIDIA Corporation. All rights reserved.
+ *
+ * Author: Pradeep Goudagunta 
+ *
+ * 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 version 2.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define MOD_NAME "palmas-gpadc"
+#define PALMAS_ADC_CONVERSION_TIMEOUT  (msecs_to_jiffies(5000))
+#define PALMAS_TO_BE_CALCULATED 0
+#define PALMAS_GPADC_TRIMINVALID   -1
+
+struct palmas_gpadc_info {
+/* calibration codes and regs */
+   int x1; /* lower ideal code */
+   int x2; /* higher ideal code */
+   int v1; /* expected lower volt reading */
+   int v2; /* expected higher volt reading */
+   u8 trim1_reg;   /* register number for lower trim */
+   u8 trim2_reg;   /* register number for upper trim */
+   int gain;   /* calculated from above (after reading trim regs) */
+   int offset; /* calculated from above (after reading trim regs) */
+   int gain_error; /* calculated from above (after reading trim regs) */
+   bool is_uncalibrated;   /* if channel has calibration data */
+};
+
+#define PALMAS_ADC_INFO(_chan, _x1, _x2, _v1, _v2, _t1, _t2, _is_uncalibrated) 
\
+   [PALMAS_ADC_CH_##_chan] = { \
+   .x1 = _x1, \
+   .x2 = _x2, \
+   .v1 = _v1, \
+   .v2 = _v2, \
+   .gain = PALMAS_TO_BE_CALCULATED, \
+   .offset = PALMAS_TO_BE_CALCULATED, \
+   .gain_error = PALMAS_TO_BE_CALCULATED, \
+   .trim1_reg = PALMAS_GPADC_TRIM##_t1, \
+   .trim2_reg = PALMAS_GPADC_TRIM##_t2,  \
+   .is_uncalibrated = _is_uncalibrated \
+   }
+
+static struct palmas_gpadc_info palmas_gpadc_info[] = {
+   PALMAS_ADC_INFO(IN0, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN1, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN2, 2064, 3112, 1260, 1900, 3, 4, false),
+   PALMAS_ADC_INFO(IN3, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN4, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN5, 2064, 3112, 630, 950, 1, 2, false),
+   PALMAS_ADC_INFO(IN6, 2064, 3112, 2520, 3800, 5, 6, false),
+   PALMAS_ADC_INFO(IN7, 2064, 3112, 2520, 3800, 7, 8, false),
+   PALMAS_ADC_INFO(IN8, 2064, 3112, 3150, 4750, 9, 10, false),
+   PALMAS_ADC_INFO(IN9, 2064, 3112, 5670, 8550, 11, 12, false),
+   PALMAS_ADC_INFO(IN10, 2064, 3112, 3465, 5225, 13, 14, false),
+   PALMAS_ADC_INFO(IN11, 0, 0, 0, 0, INVALID, INVALID, true),
+   PALMAS_ADC_INFO(IN12, 0, 0, 0, 0, INVALID, INVALID, true),
+   PALMAS_ADC_INFO(IN13, 0, 0, 0, 0, INVALID, INVALID, true),
+   PAL

[PATCH v2 0/3] Add Palmas iio gpadc

V2 changes:
- worked in review comments by Peter Meerwald
- made channels 1 and 3 report (raw) temperature values
- moved PALMAS_GPADC_TRIMINVALID to driver core
- worked in review comments by Jonathan Cameron
- iio_map removed

Add iio driver for the TI Palmas (twl6035, 6037) including device tree bindings.
It enables the gpadc for the OMAP5 uevm.

This patch series is based on original code taken from Android Tegra kernels:
(https://android.googlesource.com/kernel/tegra/+/aaabb2e045f31e5a970109ffdaae900dd403d17e/drivers/staging/iio/adc)

Tegra code was developed by:
Pradeep Goudagunta 
Laxman Dewangan 

Edited and extended for mainline by:
H. Nikolaus Schaller 
Marek Belisko 


H. Nikolaus Schaller (2):
  iio:adc: add iio driver for Palmas (twl6035/7) gpadc
  ARM: dts: omap5-uevm: enable iio gpadc for Palmas

Marek Belisko (1):
  iio:adc:palmas: add DT support

 .../devicetree/bindings/iio/adc/palmas-gpadc.txt   |  46 ++
 arch/arm/boot/dts/omap5-uevm.dts   |   9 +
 drivers/iio/adc/Kconfig|   9 +
 drivers/iio/adc/Makefile   |   1 +
 drivers/iio/adc/palmas_gpadc.c | 860 +
 include/linux/mfd/palmas.h |  75 +-
 6 files changed, 976 insertions(+), 24 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/iio/adc/palmas-gpadc.txt
 create mode 100644 drivers/iio/adc/palmas_gpadc.c

-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 3/3] ARM: dts: omap5-uevm: enable iio gpadc for Palmas

Signed-off-by: H. Nikolaus Schaller 
---
 arch/arm/boot/dts/omap5-uevm.dts | 9 +
 1 file changed, 9 insertions(+)

diff --git a/arch/arm/boot/dts/omap5-uevm.dts b/arch/arm/boot/dts/omap5-uevm.dts
index 3b16e8f..c78ee2f 100644
--- a/arch/arm/boot/dts/omap5-uevm.dts
+++ b/arch/arm/boot/dts/omap5-uevm.dts
@@ -342,6 +342,15 @@
 
ti,ldo6-vibrator;
 
+   gpadc {
+   compatible = "ti,palmas-gpadc";
+   interrupts = <18 0
+ 16 0
+ 17 0>;
+   ti,channel0-current-microamp = <5>;
+   ti,channel3-current-microamp = <10>;
+   };
+
regulators {
smps123_reg: smps123 {
/* VDD_OPP_MPU */
-- 
2.5.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH 1/1] mm: vmstat: Add OOM kill count in vmstat counter

2015-10-04 Thread PINTU KUMAR

Hi,

> -Original Message-
> From: Michal Hocko [mailto:mho...@kernel.org]
> Sent: Thursday, October 01, 2015 7:09 PM
> To: Pintu Kumar
> Cc: a...@linux-foundation.org; minc...@kernel.org; d...@stgolabs.net;
> koc...@gmail.com; rient...@google.com; han...@cmpxchg.org; penguin-
> ker...@i-love.sakura.ne.jp; bywxiao...@163.com; mgor...@suse.de;
> vba...@suse.cz; js1...@gmail.com; kirill.shute...@linux.intel.com;
> alexander.h.du...@redhat.com; sasha.le...@oracle.com; c...@linux.com;
> fengguang...@intel.com; linux-kernel@vger.kernel.org; linux...@kvack.org;
> c...@samsung.com; pintu_agar...@yahoo.com; pintu.p...@gmail.com;
> vishnu...@samsung.com; rohit...@samsung.com; c.rajku...@samsung.com;
> sreena...@samsung.com
> Subject: Re: [PATCH 1/1] mm: vmstat: Add OOM kill count in vmstat counter
> 
> On Thu 01-10-15 16:18:43, Pintu Kumar wrote:
> > This patch maintains number of oom calls and number of oom kill count
> > in /proc/vmstat.
> > It is helpful during sluggish, aging or long duration tests.
> > Currently if the OOM happens, it can be only seen in kernel ring buffer.
> > But during long duration tests, all the dmesg and /var/log/messages*
> > could be overwritten.
> > So, just like other counters, the oom can also be maintained in
> > /proc/vmstat.
> > It can be also seen if all logs are disabled in kernel.
> >
> > A snapshot of the result of over night test is shown below:
> > $ cat /proc/vmstat
> > oom_stall 610
> > oom_kill_count 1763
> >
> > Here, oom_stall indicates that there are 610 times, kernel entered
> > into OOM cases. However, there were around 1763 oom killing happens.
> 
> This alone looks quite suspicious. Unless you have tasks which share the
address
> space without being in the same thread group this shouldn't happen in such a
> large scale.

Yes, this accounts for out_of_memory even from memory cgroups.
Please check few snapshots of dmesg outputs captured during over-night tests.

[49479.078033]  [2:  :20874] Memory cgroup out of memory: Kill
process 20880 (xxx) score 112 or sacrifice child
[49480.910430]  [2:  :20882] Memory cgroup out of memory: Kill
process 20888 () score 112 or sacrifice child
[49567.046203]  [0:yyy:  548] Out of memory: Kill process 20458
(zz) score 102 or sacrifice child
[49567.346588]  [0:yyy:  548] Out of memory: Kill process 21102
(zz) score 104 or sacrifice child
.
The _out of memory_ count in dmesg dump output exactly matches the number in
/proc/vmstat -> oom_kill_count

> 
> And indeed the patch is incorrect. You are only counting OOMs from the page
> allocator slow path. You are missing all the OOM invocations from the page
fault
> path.

Sorry, I am not sure what exactly you mean. Please point me out if I am missing
some places.
Actually, I tried to add it at generic place that is; oom_kill_process, which is
called by out_of_memory(...).
Are you talking about: pagefault_out_of_memory(...) ?
But, this is already calling: out_of_memory. No?

> The placement inside __alloc_pages_may_oom looks quite arbitrary as well. You
> are not counting events where we are OOM but somebody is holding the
> oom_mutex but you do count last attempt before going really OOM. Then we
> have cases which do not invoke OOM killer which are counted into oom_stall as
> well. I am not sure whether they should because I am not quite sure about the
> semantic of the counter in the first place.

Ok. Yes, it can be added right after it enters into __alloc_pages_may_oom.
I will make the changes.
Actually, I knowingly skipped the oom_lock case, because in our 3.10 kernel, we
had note_oom_kill(..) 
Added right after this check.
So, I also added it exactly at the same place.
Ok, I can make the necessary changes, if the oom_lock case also matters. 

> What is it supposed to tell us? How many times the system had to go into
> emergency OOM steps? How many times the direct reclaim didn't make any
> progress so we can consider the system OOM?
> 
Yes, exactly, oom_stall can tell, how many times OOM is invoked in the system.
Yes, it can also tell how many times direct_reclaim fails completely.
Currently, we don't have any counter for direct_reclaim success/fail.
Also, oom_kill_process will not be invoked for higher orders
(PAGE_ALLOC_COSTLY_ORDER).
But, it will enter OOM and results into straight page allocation failure.

> oom_kill_count has a slightly misleading names because it suggests how many
> times oom_kill was called but in fact it counts the oom victims.
> Not sure whether this information is so much useful but the semantic is clear
at
> least.
> 
Ok, agree about the semantic of the name: oom_kill_count.
If possible please suggest a better name.
How about the following names?
oom_victim_count ?
oom_nr_killed ?
oom_nr_victim ?

> > The OOM is bad for the any system. So, this counter can help the
> > developer in tuning the memory requirement at least during initial bringup.
> >
> > Signed-o

RE: [PATCH 1/3][v4] Documentation: dt: dwc3: Add snps,quirk-frame-length-adjustment property

2015-10-04 Thread RAJESH BHAGAT

Hi Shawn,

Regarding below patch, Felipe has suggested to talk to you:

> [PATCH 3/3][v4] arm: dts: ls1021a: Add quirk for Erratum A009116

talk to you ARM-SoC maintainer.

https://lkml.org/lkml/2015/9/4/7

Please provide your comments. Inform me in case, if a resend is required.

Best Regards,
Rajesh Bhagat

-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com] 
Sent: Saturday, October 03, 2015 1:29 AM
To: Bhagat Rajesh-B56421
Cc: ba...@ti.com; linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; 
linux-...@vger.kernel.org
Subject: Re: [PATCH 1/3][v4] Documentation: dt: dwc3: Add 
snps,quirk-frame-length-adjustment property

On Thu, Sep 24, 2015 at 09:42:59AM +, RAJESH BHAGAT wrote:
> Hi Felipe, 
> 
> Any comments on the below [v4] patches?
> 
> [PATCH 1/3][v4] Documentation: dt: dwc3: Add 
> snps,quirk-frame-length-adjustment property

https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=next&id=3737c54418c35034127bf2837e9b27a3c3c67940

> [PATCH 2/3][v4] drivers: usb: dwc3: Add frame length adjustment quirk

https://git.kernel.org/cgit/linux/kernel/git/balbi/usb.git/commit/?h=next&id=db2be4e9e30c6e43e48c5749d3fc74cee0a6bbb3

> [PATCH 3/3][v4] arm: dts: ls1021a: Add quirk for Erratum A009116

talk to you ARM-SoC maintainer.

> I will be taking forward these patches, as Nikhil has left freescale.

okay, thanks for letting me know.

-- 
balbi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] unicore32: nb0916: Use PWM lookup table

2015-10-04 Thread Thierry Reding

Use a PWM lookup table to provide the PWM to the pwm-backlight device.
The driver has a legacy code path that is required only because boards
still use the legacy method of requesting PWMs by global ID. Replacing
these usages allows that legacy fallback to be removed.

Cc: Guan Xuetao 
Signed-off-by: Thierry Reding 
---
 arch/unicore32/kernel/puv3-nb0916.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/unicore32/kernel/puv3-nb0916.c 
b/arch/unicore32/kernel/puv3-nb0916.c
index 46ebfdccbc31..af3962d90def 100644
--- a/arch/unicore32/kernel/puv3-nb0916.c
+++ b/arch/unicore32/kernel/puv3-nb0916.c
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -49,8 +50,12 @@ static struct resource puv3_i2c_resources[] = {
}
 };
 
+static struct pwm_lookup nb0916_pwm_lookup[] = {
+   PWM_LOOKUP("PKUnity-v3-PWM", 0, "pwm-backlight", NULL, 0,
+  PWM_POLARITY_NORMAL),
+};
+
 static struct platform_pwm_backlight_data nb0916_backlight_data = {
-   .pwm_id = 0,
.max_brightness = 100,
.dft_brightness = 100,
.pwm_period_ns  = 70 * 1024,
@@ -112,6 +117,8 @@ int __init mach_nb0916_init(void)
platform_device_register_simple("PKUnity-v3-I2C", -1,
puv3_i2c_resources, ARRAY_SIZE(puv3_i2c_resources));
 
+   pwm_add_table(nb0916_pwm_lookup, ARRAY_SIZE(nb0916_pwm_lookup));
+
platform_device_register_data(NULL, "pwm-backlight", -1,
&nb0916_backlight_data, sizeof(nb0916_backlight_data));
 
-- 
2.5.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Which PCI development git repo to use?

2015-10-04 Thread Ruud

Hello all,

Looking at the changes in this sundays rc, it seems the PCI patches of
Yinghai do not get picked up in RC2 and later. I did see some patches
from helgaas.

git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git

Does someone know the plans with regard to PCIe support for big
systems with problematic bioses (aka high density GPU computing
clusters) in the linus tree. Or is it just too much of a risk to
migrate to new PCIe configuration code as most users do not need it?

If the latter is the case, it is at least good to know now beforehand...

Best regards,

Ruud
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] security: selinux: Use a kmem_cache for allocation struct file_security_struct

2015-10-04 Thread Sangwoo

The size of struct file_security_struct is 16byte at my setup.
But, the real allocation size for per each file_security_struct
is 64bytes in my setup that kmalloc min size is 64bytes
because ARCH_DMA_MINALIGN is 64.

This allocation is called every times at file allocation(alloc_file()).
So, the total slack memory size(allocated size - request size)
is increased exponentially.

E.g) Min Kmalloc Size : 64bytes, Unit : bytes
  Allocated Size | Request Size | Slack Size | Allocation Count
---
 770048  |192512|   577536   |  12032

At the result, this change reduce memory usage 42bytes per each
file_security_struct

Signed-off-by: Sangwoo 
---
 security/selinux/hooks.c |8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/security/selinux/hooks.c b/security/selinux/hooks.c
index 3f8d567..c20e082 100644
--- a/security/selinux/hooks.c
+++ b/security/selinux/hooks.c
@@ -126,6 +126,7 @@ int selinux_enabled = 1;
 #endif
 
 static struct kmem_cache *sel_inode_cache;
+static struct kmem_cache *file_security_cache;
 
 /**
  * selinux_secmark_enabled - Check to see if SECMARK is currently enabled
@@ -287,7 +288,7 @@ static int file_alloc_security(struct file *file)
struct file_security_struct *fsec;
u32 sid = current_sid();
 
-   fsec = kzalloc(sizeof(struct file_security_struct), GFP_KERNEL);
+   fsec = kmem_cache_zalloc(file_security_cache, GFP_KERNEL);
if (!fsec)
return -ENOMEM;
 
@@ -302,7 +303,7 @@ static void file_free_security(struct file *file)
 {
struct file_security_struct *fsec = file->f_security;
file->f_security = NULL;
-   kfree(fsec);
+   kmem_cache_free(file_security_cache, fsec);
 }
 
 static int superblock_alloc_security(struct super_block *sb)
@@ -6086,6 +6087,9 @@ static __init int selinux_init(void)
sel_inode_cache = kmem_cache_create("selinux_inode_security",
sizeof(struct 
inode_security_struct),
0, SLAB_PANIC, NULL);
+   file_security_cache = kmem_cache_create("selinux_file_security",
+   sizeof(struct file_security_struct),
+   0, SLAB_PANIC, NULL);
avc_init();
 
security_add_hooks(selinux_hooks, ARRAY_SIZE(selinux_hooks));
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: lustre: lustre: llite: Added const

2015-10-04 Thread Sudip Mukherjee

On Sat, Oct 03, 2015 at 09:13:36PM +0530, Anjali Menon wrote:
> Added const to the struct statement which fixed the coding
> style warning detected by chekpatch.pl
> 
> WARNING: struct seq_operations should normally be const
> 
> Signed-off-by: Anjali Menon 
> ---
Again same problem. This has already been done. I think you are using
some other tree.

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: i20: Added a blank line after declaration

2015-10-04 Thread Sudip Mukherjee

On Sat, Oct 03, 2015 at 10:47:47AM +0530, Anjali Menon wrote:
> Added a blank line after declaration to fix the coding style
> warning detected by checkpatch.pl
> 
> WARNING: Missing a blank line after declarations
> 
> Signed-off-by: Anjali Menon 
> ---
>  drivers/staging/i2o/pci.c | 1 +
>  1 file changed, 1 insertion(+)
How did you get this? i2o was removed from staging in May 2015.
Which tree are you using?

regards
sudip
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Re: [PATCH] clk: qcom: Make oxili GDSC parent of oxili_cx GDSC

2015-10-04 Thread kbuild test robot

Hi Rajendra,

[auto build test ERROR on next-20151002 -- if it's inappropriate base, please 
ignore]

config: i386-allmodconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> ERROR: "pm_genpd_add_subdomain" undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

Re: [PATCH 03/17] input: tegra-kbc: drop use of IRQF_NO_SUSPEND flag

2015-10-04 Thread Thierry Reding

On Mon, Sep 21, 2015 at 04:46:59PM +0100, Sudeep Holla wrote:
> The driver handles wakeup irq correctly using device_init_wakeup and
> enable_irq_wake. There's no need to use IRQF_NO_SUSPEND while registering
> the interrupt.
> 
> This patch removes the use of IRQF_NO_SUSPEND flag.
> 
> Cc: Laxman Dewangan 
> Cc: Stephen Warren 
> Cc: Thierry Reding 
> Cc: linux-in...@vger.kernel.org
> Cc: linux-te...@vger.kernel.org
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/input/keyboard/tegra-kbc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Acked-by: Thierry Reding 


signature.asc
Description: PGP signature

Re: [PATCH v2] jbd2: gate checksum calculations on crc driver presence, not sb flags

2015-10-04 Thread Nikolay Borisov

It is just me or am I not seeing this feature test helper in this patch ?

On 10/03/2015 06:46 AM, Darrick J. Wong wrote:
> Change the journal's checksum functions to gate on whether or not the
> crc32c driver is loaded, and gate the loading on the superblock bits.
> This prevents a journal crash if someone loads a journal in no-csum
> mode and then randomizes the superblock, thus flipping on the feature
> bits.
> 
> v2: Create a feature-test helper, use it everywhere.
> 
> Tested-By: Nikolay Borisov 
> Reported-by: Nikolay Borisov 
> Signed-off-by: Darrick J. Wong 
> ---
>  fs/jbd2/journal.c|6 +++---
>  include/linux/jbd2.h |   13 +
>  2 files changed, 12 insertions(+), 7 deletions(-)
> 
> diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
> index 8270fe9..00f7dbd 100644
> --- a/fs/jbd2/journal.c
> +++ b/fs/jbd2/journal.c
> @@ -124,7 +124,7 @@ EXPORT_SYMBOL(__jbd2_debug);
>  /* Checksumming functions */
>  static int jbd2_verify_csum_type(journal_t *j, journal_superblock_t *sb)
>  {
> - if (!jbd2_journal_has_csum_v2or3(j))
> + if (!jbd2_journal_has_csum_v2or3_feature(j))
>   return 1;
>  
>   return sb->s_checksum_type == JBD2_CRC32C_CHKSUM;
> @@ -1531,7 +1531,7 @@ static int journal_get_superblock(journal_t *journal)
>   goto out;
>   }
>  
> - if (jbd2_journal_has_csum_v2or3(journal) &&
> + if (jbd2_journal_has_csum_v2or3_feature(journal) &&
>   JBD2_HAS_COMPAT_FEATURE(journal, JBD2_FEATURE_COMPAT_CHECKSUM)) {
>   /* Can't have checksum v1 and v2 on at the same time! */
>   printk(KERN_ERR "JBD2: Can't enable checksumming v1 and v2/3 "
> @@ -1545,7 +1545,7 @@ static int journal_get_superblock(journal_t *journal)
>   }
>  
>   /* Load the checksum driver */
> - if (jbd2_journal_has_csum_v2or3(journal)) {
> + if (jbd2_journal_has_csum_v2or3_feature(journal)) {
>   journal->j_chksum_driver = crypto_alloc_shash("crc32c", 0, 0);
>   if (IS_ERR(journal->j_chksum_driver)) {
>   printk(KERN_ERR "JBD2: Cannot load crc32c driver.\n");
> diff --git a/include/linux/jbd2.h b/include/linux/jbd2.h
> index df07e78..6da6f89 100644
> --- a/include/linux/jbd2.h
> +++ b/include/linux/jbd2.h
> @@ -1338,13 +1338,18 @@ static inline int tid_geq(tid_t x, tid_t y)
>  extern int jbd2_journal_blocks_per_page(struct inode *inode);
>  extern size_t journal_tag_bytes(journal_t *journal);
>  
> +static inline bool jbd2_journal_has_csum_v2or3_feature(journal_t *j)
> +{
> + return JBD2_HAS_INCOMPAT_FEATURE(j, JBD2_FEATURE_INCOMPAT_CSUM_V2) ||
> +JBD2_HAS_INCOMPAT_FEATURE(j, JBD2_FEATURE_INCOMPAT_CSUM_V3);
> +}
> +
>  static inline int jbd2_journal_has_csum_v2or3(journal_t *journal)
>  {
> - if (JBD2_HAS_INCOMPAT_FEATURE(journal, JBD2_FEATURE_INCOMPAT_CSUM_V2) ||
> - JBD2_HAS_INCOMPAT_FEATURE(journal, JBD2_FEATURE_INCOMPAT_CSUM_V3))
> - return 1;
> + WARN_ON_ONCE(jbd2_journal_has_csum_v2or3_feature(journal) &&
> +  journal->j_chksum_driver == NULL);
>  
> - return 0;
> + return journal->j_chksum_driver != NULL;
>  }
>  
>  /*
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] clk: qcom: Make oxili GDSC parent of oxili_cx GDSC

2015-10-04 Thread Rajendra Nayak

[]...

>>> It would also be nicer if this parent/child relationship can
>>> somehow be represented in data (struct gdsc) that gets passed to
>>> the gdsc driver which then sets it up, instead of individual
>>> clock drivers doing it.
>>
>> Agreed. I'd rather that we do nothing besides register domains
>> and then let the core code handle hooking up domains and
>> subdomains.
> 
> A little closer inspection makes me want to skip this. PM domains
> can have multiple "master" domains, and pm_genpd_init() is the
> only API that would be able to do the linking. That API is mostly
> about initializing things to default values, so it doesn't seem
> like a good fit. I'll send a v2 with the remove part and the
> exports.

What I was suggesting is that the qcom gdsc driver handle this
instead of the qcom clock drivers.
Something like..

diff --git a/drivers/clk/qcom/gdsc.c b/drivers/clk/qcom/gdsc.c
index da9fad8..00edb2d 100644
--- a/drivers/clk/qcom/gdsc.c
+++ b/drivers/clk/qcom/gdsc.c
@@ -226,6 +226,8 @@ int gdsc_register(struct device *dev, struct gdsc **scs, 
size_t num,
if (ret)
return ret;
data->domains[i] = &scs[i]->pd;
+   if (scs[i]->parent)
+   pm_genpd_add_subdomain(scs[i]->parent, &scs[i]->pd);
}
 
return of_genpd_add_provider_onecell(dev->of_node, data);
diff --git a/drivers/clk/qcom/gdsc.h b/drivers/clk/qcom/gdsc.h
index 5ded268..bc5791f 100644
--- a/drivers/clk/qcom/gdsc.h
+++ b/drivers/clk/qcom/gdsc.h
@@ -49,6 +49,7 @@ struct gdsc {
struct reset_controller_dev *rcdev;
unsigned int*resets;
unsigned intreset_count;
+   struct generic_pm_domain*parent;
 };
 
 #ifdef CONFIG_QCOM_GDSC
diff --git a/drivers/clk/qcom/mmcc-msm8974.c b/drivers/clk/qcom/mmcc-msm8974.c
index fe8320d..51ad8de 100644
--- a/drivers/clk/qcom/mmcc-msm8974.c
+++ b/drivers/clk/qcom/mmcc-msm8974.c
@@ -2400,6 +2400,7 @@ static struct gdsc oxilicx_gdsc = {
.pd = {
.name = "oxilicx",
},
+   .parent = &oxili_gdsc.pd,
.pwrsts = PWRSTS_OFF_ON,
 };

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 4/4] mm, procfs: Display VmAnon, VmFile and VmShm in /proc/pid/status

On Fri, 2 Oct 2015, Vlastimil Babka wrote:

> From: Jerome Marchand 
> 
> It's currently inconvenient to retrieve MM_ANONPAGES value from status
> and statm files and there is no way to separate MM_FILEPAGES and
> MM_SHMEMPAGES. Add RssAnon, RssFile and RssShm lines in /proc//status
> to solve these issues.
> 
> Signed-off-by: Jerome Marchand 
> Signed-off-by: Vlastimil Babka 
> Acked-by: Konstantin Khlebnikov 
> Acked-by: Michal Hocko 

Mostly
Acked-by: Hugh Dickins 
but I loathe the alignment...

> ---
>  Documentation/filesystems/proc.txt | 10 +-
>  fs/proc/task_mmu.c | 14 --
>  2 files changed, 21 insertions(+), 3 deletions(-)
> 
> diff --git a/Documentation/filesystems/proc.txt 
> b/Documentation/filesystems/proc.txt
> index 82d3657..c887a42 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -169,6 +169,9 @@ For example, to get the status information of a process, 
> all you have to do is
>VmLck: 0 kB
>VmHWM:   476 kB
>VmRSS:   476 kB
> +  RssAnon  352 kB
> +  RssFile: 120 kB
> +  RssShm:4 kB

That looks nice...

>VmData:  156 kB
>VmStk:88 kB
>VmExe:68 kB
> @@ -231,7 +234,12 @@ Table 1-2: Contents of the status files (as of 4.1)
>   VmSize  total program size
>   VmLck   locked memory size
>   VmHWM   peak resident set size ("high water mark")
> - VmRSS   size of memory portions
> + VmRSS   size of memory portions. It contains the three
> + following parts (VmRSS = RssAnon + RssFile + 
> RssShm)
> + RssAnon size of resident anonymous memory
> + RssFile size of resident file mappings
> + RssShm  size of resident shmem memory (includes SysV 
> shm,
> + mapping of tmpfs and shared anonymous mappings)
>   VmData  size of data, stack, and text segments
>   VmStk   size of data, stack, and text segments
>   VmExe   size of text segment
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 9b9708e..7332afd 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -23,9 +23,13 @@
>  
>  void task_mem(struct seq_file *m, struct mm_struct *mm)
>  {
> - unsigned long data, text, lib, swap, ptes, pmds;
> + unsigned long data, text, lib, swap, ptes, pmds, anon, file, shmem;
>   unsigned long hiwater_vm, total_vm, hiwater_rss, total_rss;
>  
> + anon = get_mm_counter(mm, MM_ANONPAGES);
> + file = get_mm_counter(mm, MM_FILEPAGES);
> + shmem = get_mm_counter(mm, MM_SHMEMPAGES);
> +
>   /*
>* Note: to minimize their overhead, mm maintains hiwater_vm and
>* hiwater_rss only when about to *lower* total_vm or rss.  Any
> @@ -36,7 +40,7 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
>   hiwater_vm = total_vm = mm->total_vm;
>   if (hiwater_vm < mm->hiwater_vm)
>   hiwater_vm = mm->hiwater_vm;
> - hiwater_rss = total_rss = get_mm_rss(mm);
> + hiwater_rss = total_rss = anon + file + shmem;
>   if (hiwater_rss < mm->hiwater_rss)
>   hiwater_rss = mm->hiwater_rss;
>  
> @@ -53,6 +57,9 @@ void task_mem(struct seq_file *m, struct mm_struct *mm)
>   "VmPin:\t%8lu kB\n"
>   "VmHWM:\t%8lu kB\n"
>   "VmRSS:\t%8lu kB\n"
> + "RssAnon:\t%8lu kB\n"
> + "RssFile:\t%8lu kB\n"
> + "RssShm:\t%8lu kB\n"

... but on my terminal that comes out as

VmPeak: 4584 kB
VmSize: 4584 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM:  1264 kB
VmRSS:  1264 kB
RssAnon:  84 kB
RssFile:1180 kB
RssShm:0 kB
VmData:  184 kB
VmStk:   136 kB
VmExe:48 kB
VmLib:  1808 kB
VmPTE:32 kB
VmPMD:12 kB
VmSwap:0 kB
HugetlbPages:  0 kB

Notice anything ugly about that?  Of course, what's really wrong was
the years-ago choice of absurdly short names, with a tab after them.
Ugh.  The HugetlbPages line probably can't be helped (even HugeTLB:
would be too long).  But your three, I hope we can do better: I can
understand why Rss instead of Vm, sure, Vm on the front contributes
nothing but incorrectness, and it wasn't a bad idea to group them as
contributors to VmRSS.

I suggest either indenting them with spaces to keep the alignment,

"  Anon:\t%8lu kB\n"
"  File:\t%8lu kB\n"
" Shmem:\t%8lu kB\n"

or keeping your Rss prefix but misaligning the three together,

"RssAnon:\t%8lu kB\n"
"RssFile:\t%8lu kB\n"
"RssShmem:\t%8lu kB\n"

I somewhat prefer "Shmem" to "Shm" because "Shmem" is what
/proc/meminfo already says, and "Shm" makes me think of SysV SHM only.
But I'd happily settle for Shm if it helped in the alignment.

I realize that /proc//status is not universally lov

[PATCH v2] x86/apic: Use smaller array for __apicid_to_node[] mapping

2015-10-04 Thread Daniel J Blueman

The Intel x2APIC spec states the upper 16-bits of APIC ID is the
cluster ID [1, p2-12], intended for future distributed systems. Beyond
the legacy 8-bit APIC ID, Numascale NumaConnect uses 4-bits for the
position of a server on each axis of a multi-dimension torus; SGI
NUMAlink also structures the APIC ID space.

Instead, define an array based on NR_CPUs to achieve a 1:1 mapping and
perform linear search; we see "ACPI: NR_CPUS/possible_cpus limit of X
reached.  Processor 8/0x16 ignored." when config-limited. This addresses
the binary bloat and the present artificial APIC ID limits. With
CONFIG_NR_CPUS=256, we save ~64KB of vmlinux data:

$ size vmlinux vmlinux-patched
  text  data bss  dec hex filename
18232877 1849656 2281472 22364005 1553f65 vmlinux
18233034 1786168 2281472 22300674 1544802 vmlinux-patched

Tested on a 256-core system with a 20-bit APIC ID space, and on a
48-core legacy 8-bit APIC ID system with and without CONFIG_NUMA,
CONFIG_NUMA_EMU and CONFIG_AMD_NUMA.

v2: Improved readability by moving static variable out; integrated Denys's
numa emulation fix

Signed-off-by: Daniel J Blueman 
CC: Denys Vlasenko 
CC: Ingo Molnar 
CC: Thomas Gleixner 
CC: Jiang Liu 
CC: Len Brown 
CC: Steffen Persvold 
CC: linux-kernel@vger.kernel.org
CC: x...@kernel.org

[1] 
http://www.intel.com/content/dam/doc/specification-update/64-architecture-x2apic-specification.pdf
---
 arch/x86/include/asm/numa.h  | 13 +++--
 arch/x86/kernel/cpu/amd.c| 11 ++-
 arch/x86/mm/numa.c   | 29 +
 arch/x86/mm/numa_emulation.c |  6 +++---
 4 files changed, 37 insertions(+), 22 deletions(-)

diff --git a/arch/x86/include/asm/numa.h b/arch/x86/include/asm/numa.h
index 01b493e..33becb8 100644
--- a/arch/x86/include/asm/numa.h
+++ b/arch/x86/include/asm/numa.h
@@ -17,6 +17,11 @@
  */
 #define NODE_MIN_SIZE (4*1024*1024)
 
+struct apicid_to_node {
+   int apicid;
+   s16 node;
+};
+
 extern int numa_off;
 
 /*
@@ -27,17 +32,13 @@ extern int numa_off;
  * should be accessed by the accessors - set_apicid_to_node() and
  * numa_cpu_node().
  */
-extern s16 __apicid_to_node[MAX_LOCAL_APIC];
+extern struct apicid_to_node __apicid_to_node[NR_CPUS];
 extern nodemask_t numa_nodes_parsed __initdata;
 
 extern int __init numa_add_memblk(int nodeid, u64 start, u64 end);
 extern void __init numa_set_distance(int from, int to, int distance);
 
-static inline void set_apicid_to_node(int apicid, s16 node)
-{
-   __apicid_to_node[apicid] = node;
-}
-
+extern void set_apicid_to_node(int apicid, s16 node);
 extern int numa_cpu_node(int cpu);
 
 #else  /* CONFIG_NUMA */
diff --git a/arch/x86/kernel/cpu/amd.c b/arch/x86/kernel/cpu/amd.c
index 4a70fc6..9494f0e 100644
--- a/arch/x86/kernel/cpu/amd.c
+++ b/arch/x86/kernel/cpu/amd.c
@@ -277,12 +277,13 @@ static int nearby_node(int apicid)
int i, node;
 
for (i = apicid - 1; i >= 0; i--) {
-   node = __apicid_to_node[i];
+   node = __apicid_to_node[i].node;
if (node != NUMA_NO_NODE && node_online(node))
return node;
}
-   for (i = apicid + 1; i < MAX_LOCAL_APIC; i++) {
-   node = __apicid_to_node[i];
+   for (i = apicid + 1; i < NR_CPUS; i++) {
+   node = __apicid_to_node[i].node;
+
if (node != NUMA_NO_NODE && node_online(node))
return node;
}
@@ -422,8 +423,8 @@ static void srat_detect_node(struct cpuinfo_x86 *c)
int ht_nodeid = c->initial_apicid;
 
if (ht_nodeid >= 0 &&
-   __apicid_to_node[ht_nodeid] != NUMA_NO_NODE)
-   node = __apicid_to_node[ht_nodeid];
+   __apicid_to_node[ht_nodeid].node != NUMA_NO_NODE)
+   node = __apicid_to_node[ht_nodeid].node;
/* Pick a nearby node */
if (!node_online(node))
node = nearby_node(apicid);
diff --git a/arch/x86/mm/numa.c b/arch/x86/mm/numa.c
index c3b3f65..849a113 100644
--- a/arch/x86/mm/numa.c
+++ b/arch/x86/mm/numa.c
@@ -26,6 +26,7 @@ nodemask_t numa_nodes_parsed __initdata;
 struct pglist_data *node_data[MAX_NUMNODES] __read_mostly;
 EXPORT_SYMBOL(node_data);
 
+static unsigned apicids;
 static struct numa_meminfo numa_meminfo
 #ifndef CONFIG_MEMORY_HOTPLUG
 __initdata
@@ -56,16 +57,31 @@ early_param("numa", numa_setup);
 /*
  * apicid, cpu, node mappings
  */
-s16 __apicid_to_node[MAX_LOCAL_APIC] = {
-   [0 ... MAX_LOCAL_APIC-1] = NUMA_NO_NODE
+struct apicid_to_node __apicid_to_node[NR_CPUS] = {
+   [0 ... NR_CPUS-1] = {-1, NUMA_NO_NODE}
 };
 
+void set_apicid_to_node(int apicid, s16 node)
+{
+   /* Protect against small kernel on large system */
+   if (apicids >= NR_CPUS)
+   return;
+
+   __apicid_to_node[apicids].apicid = apicid;
+   __apicid_to_node[apicids].node = node;
+   apicids++;
+}
+
 int numa_cpu_node(int cpu

Re: [PATCH v4 3/4] mm, shmem: Add shmem resident memory accounting

On Fri, 2 Oct 2015, Vlastimil Babka wrote:

> From: Jerome Marchand 
> 
> Currently looking at /proc//status or statm, there is no way to
> distinguish shmem pages from pages mapped to a regular file (shmem
> pages are mapped to /dev/zero), even though their implication in
> actual memory use is quite different.
> This patch adds MM_SHMEMPAGES counter to mm_rss_stat to account for
> shmem pages instead of MM_FILEPAGES.
> 
> Signed-off-by: Jerome Marchand 
> Signed-off-by: Vlastimil Babka 
> Acked-by: Konstantin Khlebnikov 
> Acked-by: Michal Hocko 

Acked-by: Hugh Dickins 

Good, this one long overdue, I've grown tired for writing those if/elses.
I'd have probably have done without mm_counter_file(), but it's okay.

> ---
>  arch/s390/mm/pgtable.c   |  5 +
>  fs/proc/task_mmu.c   |  3 ++-
>  include/linux/mm.h   | 18 +-
>  include/linux/mm_types.h |  7 ---
>  kernel/events/uprobes.c  |  2 +-
>  mm/memory.c  | 30 ++
>  mm/oom_kill.c|  5 +++--
>  mm/rmap.c| 12 +++-
>  8 files changed, 41 insertions(+), 41 deletions(-)
> 
> diff --git a/arch/s390/mm/pgtable.c b/arch/s390/mm/pgtable.c
> index 54ef3bc..9816f25 100644
> --- a/arch/s390/mm/pgtable.c
> +++ b/arch/s390/mm/pgtable.c
> @@ -603,10 +603,7 @@ static void gmap_zap_swap_entry(swp_entry_t entry, 
> struct mm_struct *mm)
>   else if (is_migration_entry(entry)) {
>   struct page *page = migration_entry_to_page(entry);
>  
> - if (PageAnon(page))
> - dec_mm_counter(mm, MM_ANONPAGES);
> - else
> - dec_mm_counter(mm, MM_FILEPAGES);
> + dec_mm_counter(mm, mm_counter(page));
>   }
>   free_swap_and_cache(entry);
>  }
> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index 103457c..9b9708e 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -83,7 +83,8 @@ unsigned long task_statm(struct mm_struct *mm,
>unsigned long *shared, unsigned long *text,
>unsigned long *data, unsigned long *resident)
>  {
> - *shared = get_mm_counter(mm, MM_FILEPAGES);
> + *shared = get_mm_counter(mm, MM_FILEPAGES) +
> + get_mm_counter(mm, MM_SHMEMPAGES);
>   *text = (PAGE_ALIGN(mm->end_code) - (mm->start_code & PAGE_MASK))
>   >> PAGE_SHIFT;
>   *data = mm->total_vm - mm->shared_vm;
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index d30eea3..8be4efc 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -1361,10 +1361,26 @@ static inline void dec_mm_counter(struct mm_struct 
> *mm, int member)
>   atomic_long_dec(&mm->rss_stat.count[member]);
>  }
>  
> +/* Optimized variant when page is already known not to be PageAnon */
> +static inline int mm_counter_file(struct page *page)
> +{
> + if (PageSwapBacked(page))
> + return MM_SHMEMPAGES;
> + return MM_FILEPAGES;
> +}
> +
> +static inline int mm_counter(struct page *page)
> +{
> + if (PageAnon(page))
> + return MM_ANONPAGES;
> + return mm_counter_file(page);
> +}
> +
>  static inline unsigned long get_mm_rss(struct mm_struct *mm)
>  {
>   return get_mm_counter(mm, MM_FILEPAGES) +
> - get_mm_counter(mm, MM_ANONPAGES);
> + get_mm_counter(mm, MM_ANONPAGES) +
> + get_mm_counter(mm, MM_SHMEMPAGES);
>  }
>  
>  static inline unsigned long get_mm_hiwater_rss(struct mm_struct *mm)
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index f8d1492..207890b 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -369,9 +369,10 @@ struct core_state {
>  };
>  
>  enum {
> - MM_FILEPAGES,
> - MM_ANONPAGES,
> - MM_SWAPENTS,
> + MM_FILEPAGES,   /* Resident file mapping pages */
> + MM_ANONPAGES,   /* Resident anonymous pages */
> + MM_SWAPENTS,/* Anonymous swap entries */
> + MM_SHMEMPAGES,  /* Resident shared memory pages */
>   NR_MM_COUNTERS
>  };
>  
> diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
> index 4e5e979..6288606 100644
> --- a/kernel/events/uprobes.c
> +++ b/kernel/events/uprobes.c
> @@ -180,7 +180,7 @@ static int __replace_page(struct vm_area_struct *vma, 
> unsigned long addr,
>   lru_cache_add_active_or_unevictable(kpage, vma);
>  
>   if (!PageAnon(page)) {
> - dec_mm_counter(mm, MM_FILEPAGES);
> + dec_mm_counter(mm, mm_counter_file(page));
>   inc_mm_counter(mm, MM_ANONPAGES);
>   }
>  
> diff --git a/mm/memory.c b/mm/memory.c
> index 3bd465a..f10d458 100644
> --- a/mm/memory.c
> +++ b/mm/memory.c
> @@ -832,10 +832,7 @@ copy_one_pte(struct mm_struct *dst_mm, struct mm_struct 
> *src_mm,
>   } else if (is_migration_entry(entry)) {
>   page = migration_entry_to_page(entry);
>  
> -

Re: [PATCH] ARM: multi_v7_defconfig: Add missing QCOM APQ8064 configs

2015-10-04 Thread Andy Gross

On Thu, Oct 01, 2015 at 01:57:38PM +0100, Srinivas Kandagatla wrote:
> This patch adds few missing essential configs in the multi_v7_defconf,
> absense of some configs like PINCTRL_APQ8064 would prevent the board from
> getting access to serial.
> 
> cc: Kevin Hilman 
> cc: Tyler Baker 
> Signed-off-by: Srinivas Kandagatla 
> ---
>  arch/arm/configs/multi_v7_defconfig | 8 
>  1 file changed, 8 insertions(+)

Works like a charm.

Tested-by: Andy Gross 

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] vme: tsi148: silence uninitialized variable warning

2015-10-04 Thread Dmitry Kalinkin

The warning is a false positive.

drivers/vme/bridges/vme_tsi148.c: In function 'tsi148_master_write':
drivers/vme/bridges/vme_tsi148.c:1358:31: warning: 'handler' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
   vme_unregister_error_handler(handler);
   ^
drivers/vme/bridges/vme_tsi148.c: In function 'tsi148_master_read':
drivers/vme/bridges/vme_tsi148.c:1260:31: warning: 'handler' may be used 
uninitialized in this function [-Wmaybe-uninitialized]
   vme_unregister_error_handler(handler);
   ^

Fixes: 0b0496625715 ("vme: change bus error handling scheme")
Signed-off-by: Dmitry Kalinkin 
---
 drivers/vme/bridges/vme_tsi148.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/vme/bridges/vme_tsi148.c b/drivers/vme/bridges/vme_tsi148.c
index d1e383b..6052483 100644
--- a/drivers/vme/bridges/vme_tsi148.c
+++ b/drivers/vme/bridges/vme_tsi148.c
@@ -1186,7 +1186,7 @@ static ssize_t tsi148_master_read(struct 
vme_master_resource *image, void *buf,
int retval, enabled;
unsigned long long vme_base, size;
u32 aspace, cycle, dwidth;
-   struct vme_error_handler *handler;
+   struct vme_error_handler *handler = NULL;
struct vme_bridge *tsi148_bridge;
void __iomem *addr = image->kern_base + offset;
unsigned int done = 0;
@@ -1276,7 +1276,7 @@ static ssize_t tsi148_master_write(struct 
vme_master_resource *image, void *buf,
unsigned int done = 0;
unsigned int count32;
 
-   struct vme_error_handler *handler;
+   struct vme_error_handler *handler = NULL;
struct vme_bridge *tsi148_bridge;
struct tsi148_driver *bridge;
 
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] mm/nommu: drop unlikely behind BUG_ON()

2015-10-04 Thread Davidlohr Bueso

On Mon, 05 Oct 2015, Geliang Tang wrote:

On Sun, Oct 04, 2015 at 06:50:55PM -0700, Davidlohr Bueso wrote:

On Sun, 04 Oct 2015, Geliang Tang wrote:

>BUG_ON() already contain an unlikely compiler flag. Drop it.
>
>Signed-off-by: Geliang Tang 

Acked-by: Davidlohr Bueso 

... but I believe you do have some left:

drivers/scsi/scsi_lib.c:BUG_ON(unlikely(count > ivecs));
drivers/scsi/scsi_lib.c:BUG_ON(unlikely(count > 
queue_max_integrity_segments(rq->q)));
kernel/sched/core.c:BUG_ON(unlikely(task_stack_end_corrupted(prev)));

Thanks for your review, the left have been sended out already in two other 
patches.

So given that the 'unlikely' is based on CONFIG_BUG/HAVE_ARCH_BUG_ON, the
changelog needs to be rewritten. Ie mentioning at least why it should be
ok to drop the redundant predictions: (1) For !CONFIG_BUG cases, the bug call
is a no-op, so we couldn't care less and the change is ok. (2) ppc and
mips, which HAVE_ARCH_BUG_ON, do not rely on branch predictions as it seems
to be pointless[1] and thus callers should not be trying to push an optimization
in the first place.

Also, I think that all the changes should be in the same patch. Logically,
this is a tree wide change, and trivial enough. But I don't really have a
preference.

Thanks,
Davidlohr

[1] http://lkml.iu.edu/hypermail/linux/kernel/1101.3/02289.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND PATCH 0/2] memory: Fix module autoload for OF platform driver

2015-10-04 Thread santosh.shilim...@oracle.com




On 10/4/15 9:23 AM, Luis de Bethencourt wrote:

Hi,

Resending this patch series as requested by Greg. So he can have them in his
queue for picking up.
https://lkml.org/lkml/2015/10/4/76

These patches add the missing MODULE_DEVICE_TABLE() for OF to export
the information so modules have the correct aliases built-in and
autoloading works correctly.

A longer explanation by Javier Canillas can be found here:
https://lkml.org/lkml/2015/7/30/519

Thanks,
Luis

Luis de Bethencourt (2):
   memory: fsl-corenet: Fix module autoload for OF platform driver
   memory: ti-aemif: Fix module autoload for OF platform driver


Acking them second time since author missed to pick the tag ;-)

Acked-by: Santosh Shilimkar 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] memory: Fix module autoload for OF platform driver

2015-10-04 Thread santosh.shilim...@oracle.com


On 10/4/15 4:36 AM, Greg Kroah-Hartman wrote:

On Tue, Sep 29, 2015 at 10:40:17AM -0700, santosh shilimkar wrote:

+Greg, arm-sock folks

On 9/17/2015 10:56 AM, santosh shilimkar wrote:

On 9/17/2015 10:41 AM, Luis de Bethencourt wrote:

Hello,

These patches add the missing MODULE_DEVICE_TABLE() for OF to export
the information so modules have the correct aliases built-in and
autoloading works correctly.

A longer explanation by Javier Canillas can be found here:
https://lkml.org/lkml/2015/7/30/519





Luis de Bethencourt (2):
   memory: fsl-corenet: Fix module autoload for OF platform driver
   memory: ti-aemif: Fix module autoload for OF platform driver

  drivers/memory/fsl-corenet-cf.c | 1 +
  drivers/memory/ti-aemif.c   | 1 +
  2 files changed, 2 insertions(+)


Acked-by: Santosh Shilimkar 


Will you be able to pick these two as part of your drivers/core ?
In past you have helped me to queue the drivers/memory/*emif*
via you tree but of late, I have seen other patches from
drivers/memory/ made it via arm-soc.

I just want to make sure that some one pick these up and hence
the email.


I don't have these in any queue, so someone is going to have to resend
them so that I can pick them up.


Thanks !!

Regards,
Santosh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

APPLY TODAY

2015-10-04 Thread Roland S

WE OFFER LOAN AT 3% INTEREST RATE
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] drivers: staging: wilc1000: Call kfree only for error cases

2015-10-04 Thread Tony Cho




On 2015년 10월 04일 19:28, Chandra Gorentla wrote:

On Sun, Oct 04, 2015 at 09:44:57AM +0100, Greg KH wrote:

On Sat, Oct 03, 2015 at 02:57:30PM +0530, Chandra S Gorentla wrote:

  - kfree is being called for the members of the queue without
de-queuing them; they are just inserted within this function;
they are supposed to be de-queued and freed in a function
for receiving the queue items
  - goto statements are removed
  - After kfree correction, there is no need for target block
of goto statement; hence it is removed

Signed-off-by: Chandra S Gorentla 
---
  drivers/staging/wilc1000/wilc_msgqueue.c | 22 ++
  1 file changed, 6 insertions(+), 16 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_msgqueue.c 
b/drivers/staging/wilc1000/wilc_msgqueue.c
index 284a3f5..eae90be 100644
--- a/drivers/staging/wilc1000/wilc_msgqueue.c
+++ b/drivers/staging/wilc1000/wilc_msgqueue.c
@@ -56,32 +56,30 @@ int wilc_mq_destroy(WILC_MsgQueueHandle *pHandle)
  int wilc_mq_send(WILC_MsgQueueHandle *pHandle,
 const void *pvSendBuffer, u32 u32SendBufferSize)
  {
-   int result = 0;
unsigned long flags;
Message *pstrMessage = NULL;
  
  	if ((!pHandle) || (u32SendBufferSize == 0) || (!pvSendBuffer)) {

PRINT_ER("pHandle or pvSendBuffer is null\n");
-   result = -EFAULT;
-   goto ERRORHANDLER;
+   return -EFAULT;
}
  
  	if (pHandle->bExiting) {

PRINT_ER("pHandle fail\n");
-   result = -EFAULT;
-   goto ERRORHANDLER;
+   return -EFAULT;
}
  
  	/* construct a new message */

pstrMessage = kmalloc(sizeof(Message), GFP_ATOMIC);
if (!pstrMessage)
return -ENOMEM;
+
pstrMessage->u32Length = u32SendBufferSize;
pstrMessage->pstrNext = NULL;
pstrMessage->pvBuffer = kmalloc(u32SendBufferSize, GFP_ATOMIC);
if (!pstrMessage->pvBuffer) {
-   result = -ENOMEM;
-   goto ERRORHANDLER;
+   kfree(pstrMessage);
+   return -ENOMEM;
}
memcpy(pstrMessage->pvBuffer, pvSendBuffer, u32SendBufferSize);
  
@@ -102,15 +100,7 @@ int wilc_mq_send(WILC_MsgQueueHandle *pHandle,

spin_unlock_irqrestore(&pHandle->strCriticalSection, flags);
  
  	up(&pHandle->hSem);

-
-ERRORHANDLER:
-   /* error occured, free any allocations */
-   if (pstrMessage) {
-   kfree(pstrMessage->pvBuffer);
-   kfree(pstrMessage);
-   }
-
-   return result;
+   return 0;

Aren't you now leaking memory as you aren't freeing pstrMessage and the
buffer on the "normal" return path?

In the normal path kfree is called in a separate (wilc_mq_recv) function.
The purpose of the currently modified function (wilc_mq_send) is to post
a message to a queue by allocating memory for the message.  The receiver
function is supposed to remove the message from the queue and free the
memory.


This patch is reasonable and normal free is done in recv function as Chandra 
said.

Thanks,

Tony.


thanks,

greg k-h


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] drivers: staging: wilc1000: Move spin lock to the start of critical section

2015-10-04 Thread Tony Cho




On 2015년 10월 04일 17:43, Greg KH wrote:

On Sat, Oct 03, 2015 at 02:57:29PM +0530, Chandra S Gorentla wrote:

The spin_lock_irqsave is moved to just beginning of critical section.
This change moves a couple of return statements out of the lock.

Signed-off-by: Chandra S Gorentla 
---
  drivers/staging/wilc1000/wilc_msgqueue.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/wilc1000/wilc_msgqueue.c 
b/drivers/staging/wilc1000/wilc_msgqueue.c
index d5ebd6d..284a3f5 100644
--- a/drivers/staging/wilc1000/wilc_msgqueue.c
+++ b/drivers/staging/wilc1000/wilc_msgqueue.c
@@ -72,8 +72,6 @@ int wilc_mq_send(WILC_MsgQueueHandle *pHandle,
goto ERRORHANDLER;
}
  
-	spin_lock_irqsave(&pHandle->strCriticalSection, flags);

-
/* construct a new message */
pstrMessage = kmalloc(sizeof(Message), GFP_ATOMIC);

As you have moved the lock, can you also change this to GFP_KERNEL as
well because we do not have a lock held?

And how have you tested that this is ok?  What is this lock trying to
protect?


This function is called even in interrupt context, so GFP_ATOMIC should be 
called. The spinlock
also should protect pstrMessage from allocating the memory, so we don't place 
it to the beginning
of critical section as Chandra said.

Thanks,
Tony.


thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 8/8] bdc_pci: use PCI_VDEVICE() instead of PCI_DEVICE()

2015-10-04 Thread Greg KH

On Mon, Oct 05, 2015 at 12:08:26AM +0300, Sergei Shtylyov wrote:
> Fix using the PCI_DEVICE() macro instead of less verbose PCI_VDEVICE().

Why?  I hate PCI_VDEVICE(), it's impossible to grep for things and does
not help with readability and is pointless.  My one wish was that when I
was the PCI maintainer I would have just deleted the thing from the
kernel entirely instead of leaving it there hoping no one would use it.

I don't like these types of pointless patches, sorry.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

APPLY TODAY

2015-10-04 Thread Roland S

WE OFFER LOAN AT 3% INTEREST RATE
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v7 5/6] Documentation: dt-bindings: pci: altera pcie device tree binding

2015-10-04 Thread Ley Foon Tan

On Sat, Oct 3, 2015 at 5:56 AM, Arnd Bergmann  wrote:
> On Friday 02 October 2015 15:53:44 Ley Foon Tan wrote:
>> > Strictly speaking, if you have undocumented bindings downstream that
>> > is your problem and we don't have to accept them as-is upstream. I'm
>> > not going to worry about that here.
>> >
>> >>> txs contains the config space?
>> >> It is not the config space, but a memory slave port.
>> >
>> > Then where is the config space? It should not be part of "ranges" is
>> > all I care about.
>> The config space is not part of "ranges". Our IP uses TLP packet to
>> access config space.
>>
>
> It took me a bit to figure out what you mean here. To save others
> from reading the source, here is what I found:
>
> * The config space is accessed indirectly through registers from the
>   "cra" register range, which is the right approach according to the
>   point that Rob made.
You are right.

> * hardware-wise this basically looks like bit-banged PCIe, which is
>   both awesome and scary ;-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/3] uio_pci_generic: add MSI/MSI-X support

2015-10-04 Thread Greg KH

On Sun, Oct 04, 2015 at 11:43:17PM +0300, Vlad Zolotarov wrote:
> Add support for MSI and MSI-X interrupt modes:
>- Interrupt mode selection order is:
> INT#X (for backward compatibility) -> MSI-X -> MSI.
>- Add ioctl() commands:
>   - UIO_PCI_GENERIC_INT_MODE_GET: query the current interrupt mode.
>   - UIO_PCI_GENERIC_IRQ_NUM_GET: query the maximum number of IRQs.
>   - UIO_PCI_GENERIC_IRQ_SET: bind the IRQ to eventfd (similar to vfio).
>- Add mappings to all bars (memory and portio): some devices have
>  registers related to MSI/MSI-X handling outside BAR0.
> 
> Signed-off-by: Vlad Zolotarov 
> ---
> New in v3:
>- Add __iomem qualifier to temp buffer receiving ioremap value.
> 
> New in v2:
>- Added #include  to uio_pci_generic.c
> 
> Signed-off-by: Vlad Zolotarov 
> ---
>  drivers/uio/uio_pci_generic.c   | 410 
> +---
>  include/linux/uio_pci_generic.h |  36 
>  2 files changed, 423 insertions(+), 23 deletions(-)
>  create mode 100644 include/linux/uio_pci_generic.h
> 
> diff --git a/drivers/uio/uio_pci_generic.c b/drivers/uio/uio_pci_generic.c
> index d0b508b..6b8b1789 100644
> --- a/drivers/uio/uio_pci_generic.c
> +++ b/drivers/uio/uio_pci_generic.c
> @@ -22,16 +22,32 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 
>  
>  #define DRIVER_VERSION   "0.01.0"
>  #define DRIVER_AUTHOR"Michael S. Tsirkin "
>  #define DRIVER_DESC  "Generic UIO driver for PCI 2.3 devices"
>  
> +struct msix_info {
> + int num_irqs;
> + struct msix_entry *table;
> + struct uio_msix_irq_ctx {
> + struct eventfd_ctx *trigger;/* MSI-x vector to eventfd */

Why are you using eventfd for msi vectors?  What's the reason for
needing this?

You haven't documented how this api works at all, you are going to have
to a lot more work to justify this, as this greatly increases the
complexity of the user/kernel api in unknown ways.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2] arm: Adding support for atomic half word exchange

2015-10-04 Thread Sarbojit Ganguly


Hello Will,

This is my second version of the patch which covers the byte exclusive case as 
pointed out by you.
Please share your opinion on this.


v1-->v2 : Extended the guard code to cover the byte exchange case as 
well following opinion of Will Deacon.
Checkpatch has been run and issues were taken care of.

Since support for half-word atomic exchange was not there and Qspinlock
on ARM requires it, modified __xchg() to add support for that as well.
ARMv6 and lower does not support ldrex{b,h} so, added a guard code
to prevent build breaks.

Signed-off-by: Sarbojit Ganguly 
---
 arch/arm/include/asm/cmpxchg.h | 17 +
 1 file changed, 17 insertions(+)

diff --git a/arch/arm/include/asm/cmpxchg.h b/arch/arm/include/asm/cmpxchg.h 
index 916a274..a53cbeb 100644
--- a/arch/arm/include/asm/cmpxchg.h
+++ b/arch/arm/include/asm/cmpxchg.h
@@ -39,6 +39,7 @@ static inline unsigned long __xchg(unsigned long x, volatile 
void *ptr, int size
 
  switch (size) {
 #if __LINUX_ARM_ARCH__ >= 6
+#if !defined(CONFIG_CPU_V6)
  case 1:
   asm volatile("@ __xchg1\n"
   "1: ldrexb %0, [%3]\n"
@@ -49,6 +50,22 @@ static inline unsigned long __xchg(unsigned long x, volatile 
void *ptr, int size
: "r" (x), "r" (ptr)
: "memory", "cc");
   break;
+
+  /*
+   * Half-word atomic exchange, required
+   * for Qspinlock support on ARM.
+   */
+ case 2:
+  asm volatile("@ __xchg2\n"
+  "1: ldrexh %0, [%3]\n"
+  " strexh %1, %2, [%3]\n"
+  " teq %1, #0\n"
+  " bne 1b"
+   : "=&r" (ret), "=&r" (tmp)
+   : "r" (x), "r" (ptr)
+   : "memory", "cc");
+  break;
+#endif
  case 4:
   asm volatile("@ __xchg4\n"
   "1: ldrex %0, [%3]\n"
--

Re: [PATCH v3 1/3] uio: add ioctl support

2015-10-04 Thread Greg KH

On Sun, Oct 04, 2015 at 11:43:16PM +0300, Vlad Zolotarov wrote:
> Signed-off-by: Vlad Zolotarov 
> ---
>  drivers/uio/uio.c  | 15 +++
>  include/linux/uio_driver.h |  3 +++
>  2 files changed, 18 insertions(+)

You add an ioctl yet fail to justify _why_ you need/want that ioctl, and
you don't document it at all?  Come on, you know better than that, no
one can take a patch that has no changelog comments at all like this :(

Also, I _REALLY_ don't want to add any ioctls to the UIO interface, so
you had better have a really compelling argument as to why this is the
_ONLY_ way you can solve this unknown problem by using such a horrid
thing...

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 2/4] mm, proc: account for shmem swap in /proc/pid/smaps

On Fri, 2 Oct 2015, Vlastimil Babka wrote:

> Currently, /proc/pid/smaps will always show "Swap: 0 kB" for shmem-backed
> mappings, even if the mapped portion does contain pages that were swapped out.
> This is because unlike private anonymous mappings, shmem does not change pte
> to swap entry, but pte_none when swapping the page out. In the smaps page
> walk, such page thus looks like it was never faulted in.
> 
> This patch changes smaps_pte_entry() to determine the swap status for such
> pte_none entries for shmem mappings, similarly to how mincore_page() does it.
> Swapped out pages are thus accounted for.
> 
> The accounting is arguably still not as precise as for private anonymous
> mappings, since now we will count also pages that the process in question 
> never
> accessed, but only another process populated them and then let them become
> swapped out. I believe it is still less confusing and subtle than not showing
> any swap usage by shmem mappings at all. Also, swapped out pages only becomee 
> a
> performance issue for future accesses, and we cannot predict those for neither
> kind of mapping.
> 
> Signed-off-by: Vlastimil Babka 
> Acked-by: Konstantin Khlebnikov 

Neither Ack nor Nack from me.

I don't want to stand in the way of this patch, if you and others
believe that it will help to diagnose problems in the field better
than what's shown at present; but to me it looks dangerously like
replacing no information by wrong information.

As you acknowledge in the commit message, if a file of 100 pages
were copied to tmpfs, and 100 tasks map its full extent, but they
all mess around with the first 50 pages and take no interest in
the last 50, then it's quite likely that that last 50 will get
swapped out; then with your patch, 100 tasks are each shown as
using 50 pages of swap, when none of them are actually using any.

It is rather as if we didn't bother to record Rss, and just put
Size in there instead: you are (for understandable reasons) treating
the virtual address space as if every page of it had been touched.

But I accept that there may well be a class of processes and problems
which would be better served by this fiction than the present: I expect
you have much more experience of helping out in such situations than I.

And perhaps you do balance it nicely by going to the opposite extreme
with SwapPss 0 for all (again for the eminently understandable reason,
that it would be a whole lot more new code to work out the right number).
Altogther, you're saying everyone's using more swap than they probably
are, but that's okay because it's infinitely shared.

I am not at all angling for you or anyone to make the changes necessary
to make those numbers accurate.  I think there's a point at which we
stop cluttering up the core kernel code, just for the sake of
maintaining numbers for a /proc file someone thought was a good idea
at the time.  But I am hoping that if this patch goes in, you will take
responsibility for batting away all the complaints that it doesn't work
as this or that person expected, rather than a long stream of patches
to refine it.

I think the root problem is that we're trying to use /proc//smaps
for something that's independent of  and its maps: a shmem object.
Would we be better served by a tmpfs-ish filesystem mounted somewhere,
which gives names to all the objects on the internal mount of tmpfs
(SysV SHM, memfds etc); and some fincore-ish syscalls which could be
used to interrogate how much swap any tmpfs file is using in any range?
(I am not volunteering to write this, not in the foreseeable future.)

I have no idea of the security implications of naming the hidden, it
may be a non-starter.  And my guess is, it would be nice if it already
existed, but you need a solution today to some problems that have been
wasting your time; and grafting it into smaps looks to be good enough.

Some comments on your implementation below.

> ---
>  Documentation/filesystems/proc.txt |  6 ++--
>  fs/proc/task_mmu.c | 48 ++
>  include/linux/shmem_fs.h   |  6 
>  mm/shmem.c | 61 
> ++
>  4 files changed, 119 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/filesystems/proc.txt 
> b/Documentation/filesystems/proc.txt
> index 7ef50cb..82d3657 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -457,8 +457,10 @@ accessed.
>  a mapping associated with a file may contain anonymous pages: when 
> MAP_PRIVATE
>  and a page is modified, the file page is replaced by a private anonymous 
> copy.
>  "Swap" shows how much would-be-anonymous memory is also used, but out on
> -swap.
> -"SwapPss" shows proportional swap share of this mapping.
> +swap. For shmem mappings, "Swap" shows how much of the mapped portion of the
> +underlying shmem object is on swap.

And for private mappings of tmpfs files?  I expected it to show an
inderm

Re: [PATCH 2/2] NTB: remove unused variable

2015-10-04 Thread Jon Mason

On Sat, Oct 3, 2015 at 4:09 AM, Sudip Mukherjee
 wrote:
> These variables were not used anywhere. So remove them.
>
> Signed-off-by: Sudip Mukherjee 

Applied.

Thanks,
Jon

> ---
>  drivers/ntb/ntb_transport.c | 4 
>  1 file changed, 4 deletions(-)
>
> diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
> index 69953ee..28f9a03 100644
> --- a/drivers/ntb/ntb_transport.c
> +++ b/drivers/ntb/ntb_transport.c
> @@ -928,7 +928,6 @@ static int ntb_transport_init_queue(struct 
> ntb_transport_ctx *nt,
> unsigned int qp_num)
>  {
> struct ntb_transport_qp *qp;
> -   struct ntb_transport_mw *mw;
> phys_addr_t mw_base;
> resource_size_t mw_size;
> unsigned int num_qps_mw, tx_size;
> @@ -939,7 +938,6 @@ static int ntb_transport_init_queue(struct 
> ntb_transport_ctx *nt,
> qp_count = nt->qp_count;
>
> mw_num = QP_TO_MW(nt, qp_num);
> -   mw = &nt->mw_vec[mw_num];
>
> qp = &nt->qp_vec[qp_num];
> qp->qp_num = qp_num;
> @@ -1930,13 +1928,11 @@ EXPORT_SYMBOL_GPL(ntb_transport_link_up);
>   */
>  void ntb_transport_link_down(struct ntb_transport_qp *qp)
>  {
> -   struct pci_dev *pdev;
> int val;
>
> if (!qp)
> return;
>
> -   pdev = qp->ndev->pdev;
> qp->client_ready = false;
>
> val = ntb_spad_read(qp->ndev, QP_LINKS);
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] NTB: fix access of free-ed pointer

2015-10-04 Thread Jon Mason

On Sat, Oct 3, 2015 at 4:09 AM, Sudip Mukherjee
 wrote:
> We were accessing nt->mw_vec after freeing it. Fix the error path so
> that we free nt->mw_vec after we have finished using it.
>
> Signed-off-by: Sudip Mukherjee 

Good catch.  Pulled into my ntb branch.

Thanks,
Jon


> ---
>  drivers/ntb/ntb_transport.c | 15 +++
>  1 file changed, 7 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/ntb/ntb_transport.c b/drivers/ntb/ntb_transport.c
> index 6e3ee90..69953ee 100644
> --- a/drivers/ntb/ntb_transport.c
> +++ b/drivers/ntb/ntb_transport.c
> @@ -1080,7 +1080,7 @@ static int ntb_transport_probe(struct ntb_client *self, 
> struct ntb_dev *ndev)
>   GFP_KERNEL, node);
> if (!nt->qp_vec) {
> rc = -ENOMEM;
> -   goto err2;
> +   goto err1;
> }
>
> if (nt_debugfs_dir) {
> @@ -1092,7 +1092,7 @@ static int ntb_transport_probe(struct ntb_client *self, 
> struct ntb_dev *ndev)
> for (i = 0; i < qp_count; i++) {
> rc = ntb_transport_init_queue(nt, i);
> if (rc)
> -   goto err3;
> +   goto err2;
> }
>
> INIT_DELAYED_WORK(&nt->link_work, ntb_transport_link_work);
> @@ -1100,12 +1100,12 @@ static int ntb_transport_probe(struct ntb_client 
> *self, struct ntb_dev *ndev)
>
> rc = ntb_set_ctx(ndev, nt, &ntb_transport_ops);
> if (rc)
> -   goto err3;
> +   goto err2;
>
> INIT_LIST_HEAD(&nt->client_devs);
> rc = ntb_bus_init(nt);
> if (rc)
> -   goto err4;
> +   goto err3;
>
> nt->link_is_up = false;
> ntb_link_enable(ndev, NTB_SPEED_AUTO, NTB_WIDTH_AUTO);
> @@ -1113,17 +1113,16 @@ static int ntb_transport_probe(struct ntb_client 
> *self, struct ntb_dev *ndev)
>
> return 0;
>
> -err4:
> -   ntb_clear_ctx(ndev);
>  err3:
> -   kfree(nt->qp_vec);
> +   ntb_clear_ctx(ndev);
>  err2:
> -   kfree(nt->mw_vec);
> +   kfree(nt->qp_vec);
>  err1:
> while (i--) {
> mw = &nt->mw_vec[i];
> iounmap(mw->vbase);
> }
> +   kfree(nt->mw_vec);
>  err:
> kfree(nt);
> return rc;
> --
> 1.9.1
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] mm/nommu: drop unlikely behind BUG_ON()

2015-10-04 Thread Geliang Tang

On Sun, Oct 04, 2015 at 06:50:55PM -0700, Davidlohr Bueso wrote:
> On Sun, 04 Oct 2015, Geliang Tang wrote:
> 
> >BUG_ON() already contain an unlikely compiler flag. Drop it.
> >
> >Signed-off-by: Geliang Tang 
> 
> Acked-by: Davidlohr Bueso 
> 
> ... but I believe you do have some left:
> 
> drivers/scsi/scsi_lib.c:BUG_ON(unlikely(count > ivecs));
> drivers/scsi/scsi_lib.c:BUG_ON(unlikely(count > 
> queue_max_integrity_segments(rq->q)));
> kernel/sched/core.c:BUG_ON(unlikely(task_stack_end_corrupted(prev)));

Thanks for your review, the left have been sended out already in two other 
patches.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 07/26] ARM: pxa: magician: Fix HTC Magician pin mux definitions

2015-10-04 Thread Petr Cvek

Dne 3.10.2015 v 14:30 Philipp Zabel napsal(a):
> Am Montag, den 28.09.2015, 23:15 +0200 schrieb Petr Cvek:
>> This patch fixes a pin mux for the HTC Magician machine. Wrong and
>> missing
>> definitions caused a bad LCD operation and an unavailability of
>> several
>> peripherals.
>>
>> Signed-off-by: Petr Cvek 
> 
> NAK on this one. Until this patch I can boot my o2 Xda mini with
> Toppoly display and see the framebuffer kernel console output. Can we
> split the LCD changes from the rest, I assume those are what breaks my
> display.

I read the Toppoly datasheet and it seems, the LCD panel implements V/HSYNC, 
while Samsung does not (and I'm sure at least one of these sync pins must be 
GPIO for DC-DC control). A solution is probably to reconfigure the GPIO muxes 
by detected LCD type.

> 
> best regards
> Philipp
> 

Petr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Lucky Email Winner

2015-10-04 Thread POSTCODESLOTERIJ.NL




We are please to inform you of our yearly promotion award program held 1st
October 2015,have pronounce your email-address as the lucky winner of a
total sum:of 500,000.00(Five Hundred Thousand Euros Only)
CONTACT:
The claim office/Email:posti...@luckymail.com,with your winning 
Serial-No:LE0031#13350PSNL.
Postcodesloterij.nl**
WARNING!!
This winning notification is expected to be read and/or used only by the
individual(s) for whom it is intended.If you have received this electronic
communication in error, please reply to the sender advising of the error
in transmission and delete the original message FOR SECURITY REASON
:**

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/2] Add RT5033 Flash LED driver

2015-10-04 Thread Ingi Kim

Hi, Jacek

Thanks for review my patch
Oops! old version patch is sent.
I should have checked..
I'll send new patch, soon.

Thanks
Ingi Kim

On 2015년 10월 02일 23:59, Jacek Anaszewski wrote:
> Hi Ingi,
> 
> Thanks for the patches. Please fix build errors
> and resubmit.
> 
> On 10/02/2015 11:41 AM, Ingi Kim wrote:
>> This patch adds ktd2692 Flash LED driver with LED Flash class
>>
>> Ingi Kim (2):
>>leds: rt5033: add DT binding for RT5033
>>leds: rt5033: Add RT5033 Flash led device driver
>>
>>   .../devicetree/bindings/leds/leds-rt5033.txt   |  38 
>>   drivers/leds/Kconfig   |   8 +
>>   drivers/leds/Makefile  |   1 +
>>   drivers/leds/leds-rt5033.c | 222 
>> +
>>   drivers/mfd/rt5033.c   |   3 +
>>   include/linux/mfd/rt5033-private.h |  67 ++-
>>   include/linux/mfd/rt5033.h |  27 ++-
>>   7 files changed, 355 insertions(+), 11 deletions(-)
>>   create mode 100644 Documentation/devicetree/bindings/leds/leds-rt5033.txt
>>   create mode 100644 drivers/leds/leds-rt5033.c
>>
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] mm/nommu: drop unlikely behind BUG_ON()

2015-10-04 Thread Davidlohr Bueso


On Sun, 04 Oct 2015, Leon Romanovsky wrote:


On Sun, Oct 4, 2015 at 9:18 AM, Geliang Tang  wrote:

BUG_ON() already contain an unlikely compiler flag. Drop it.

It is not the case if CONFIG_BUG and HAVE_ARCH_BUG_ON are not set.


Yeah, but that's like the 1% of the cases -- and those probably don't even care
about the branch prediction (I could be wrong). So overall I like getting rid of
explicit BUG_ON(unlikely(... calls. In fact there's a _reason_ why there are so
few of them in the kernel.

Thanks,
Davidlohr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 17/26] ARM: pxa: magician: Fix wrongly enabled USB host ports

2015-10-04 Thread Petr Cvek

Dne 3.10.2015 v 14:45 Philipp Zabel napsal(a):
> Am Montag, den 28.09.2015, 23:38 +0200 schrieb Petr Cvek:
>> USB host ports on the HTC Magician are wrongly enabled. Port 1 is for
>> bluetooth and port 2 is for OTG (mux in the charger connector).
>>
>> Signed-off-by: Petr Cvek 
>> ---
>>  arch/arm/mach-pxa/magician.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/mach-pxa/magician.c b/arch/arm/mach
>> -pxa/magician.c
>> index 8e8b122..af8133a 100644
>> --- a/arch/arm/mach-pxa/magician.c
>> +++ b/arch/arm/mach-pxa/magician.c
>> @@ -780,8 +780,10 @@ static struct pxamci_platform_data
>> magician_mci_info = {
>>  
>>  static struct pxaohci_platform_data magician_ohci_info = {
>>  .port_mode  = PMM_PERPORT_MODE,
>> -.flags  = ENABLE_PORT1 | ENABLE_PORT3 |
>> POWER_CONTROL_LOW,
>> +/* port1: CSR Bluetooth, port2: OTG with UDC */
>> +.flags  = ENABLE_PORT1 | ENABLE_PORT2 |
>> POWER_CONTROL_LOW,
>>  .power_budget   = 0,
>> +.power_on_delay = 100,
>>  };
> 
> I have only ever tested the CSR bluetooth chip, so this could be
> correct, or again something that is different between the magician
> variants. I don't know.

If your magician has USB client directly from PXA SoC (not external PHY),
then only host port 2 can be muxed with client.

Intel® PXA27x Processor Family, Developer’s Manual

"12.5 USB On-The-Go Operation"
"Figure 12-15. USB OTG Configurations"

I think there was no implementation in the Windows Mobile, but I was able to
switch this mux and use a wifi usb dongle on the same connector as USB client.

> 
> regards
> Philipp
> 

Petr
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [V4 PATCH 4/4] x86/apic: Introduce noextnmi boot option

2015-10-04 Thread 河合英宏 / KAWAI，HIDEHIRO

> On Fri, Oct 02, 2015 at 12:58:02AM +, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > On Thu, Oct 01, 2015 at 10:24:19AM +, 河合英宏 / KAWAI，HIDEHIRO wrote:
> > > > But how do we check if the starting kernel is a dump capture kernel?
> > >
> > > How does that first kernel pass info to the capture kernel?
> >
> > As I described in the previous mail,
> 
> I meant: "How does the first kernel pass info to the capture kernel by
> *not* using the kernel command line"?
> 
> The kernel command line is not the channel to pass data to the kdump
> kernel.

That's different from my point of view.  I'm not going to pass
some data from the first kernel to the second kernel. I'm just going to
provide a configurable option for the second kernel to users.

We souldn't enable this feature silently.  Some users wouldn't like
to enable this feature.  For example, a user enables a watchdog timer
which raises an external NMI when the counter is not reset for a
specific duration.  Then, the second kernel hangs up while saving
crash dump, and NMI is delivered to the CPU.  The kernel gets panic
due to the NMI, prints some information to the display and serial
console, and then automatically reboot.  In this case, users don't
want to block external NMIs.

So, making this feature configurable by command line option is
reasonable.

> > Yes, your first kernel doesn't get external NMIs, but basically
> > you don't have to set "noextnmi" option to the first kernel.
> 
> So it doesn't belong there as a kernel command line parameter in the
> first place.
> 
> IOW, you need a different method to pass data to the second kernel. Be
> it an ELF header, be it a shared page, whatever.

I think we should use the ELF header only if the passed information
is saved to a crash dump.

Also, we wouldn't want to introduce new shared page for that purpose.
A memory segment provided by kexec syscall is not usable because
the second kernel doesn't know what there is in a segment without a
command line option.  Please note that "elfcorehdr" command line option
prepared by kexec command is used to inform the second kernel about
the address of the ELF header memory segment.

Regards,

Hidehiro Kawai
Hitachi, Ltd. Research & Development Group

N�r��yb�X��ǧv�^�)޺{.n�+{zX����ܨ}���Ơz�&j:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf��^jǫy�m��@A�a���
0��h���i

Re: [PATCH 3/3] mm/nommu: drop unlikely behind BUG_ON()

2015-10-04 Thread Davidlohr Bueso


On Sun, 04 Oct 2015, Geliang Tang wrote:


BUG_ON() already contain an unlikely compiler flag. Drop it.

Signed-off-by: Geliang Tang 


Acked-by: Davidlohr Bueso 

... but I believe you do have some left:

drivers/scsi/scsi_lib.c:BUG_ON(unlikely(count > ivecs));
drivers/scsi/scsi_lib.c:BUG_ON(unlikely(count > 
queue_max_integrity_segments(rq->q)));
kernel/sched/core.c:BUG_ON(unlikely(task_stack_end_corrupted(prev)));
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/4] sched/fair: Remove scale_load_down() for load_avg

Currently, load_avg = scale_load_down(load) * runnable%. This does
not make much sense, because load_avg is primarily the load that
takes runnable time ratio into account.

We therefore remove scale_load_down() for load_avg. But we need to
carefully consider the overflow risk if load has higher resolution
(2*SCHED_RESOLUTION_SHIFT). The only case an overflow may occur due
to us is on 64bit kernel with increased load resolution. In that
case, the 64bit load_sum can afford 4251057 (=2^64/47742/88761/1024)
entities with the highest load (=88761*1024) always runnable on one
single cfs_rq, which may be an issue, but should be fine.

Signed-off-by: Yuyang Du 
---
 include/linux/sched.h | 69 +++
 kernel/sched/fair.c   | 11 
 2 files changed, 63 insertions(+), 17 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index b3ba0fb..a63271e 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -1185,18 +1185,65 @@ struct load_weight {
 };
 
 /*
- * The load_avg/util_avg accumulates an infinite geometric series.
- * 1) load_avg factors frequency scaling into the amount of time that a
- * sched_entity is runnable on a rq into its weight. For cfs_rq, it is the
- * aggregated such weights of all runnable and blocked sched_entities.
- * 2) util_avg factors frequency and cpu capacity scaling into the amount of 
time
- * that a sched_entity is running on a CPU, in the range 
[0..SCHED_CAPACITY_SCALE].
- * For cfs_rq, it is the aggregated such times of all runnable and
+ * The load_avg/util_avg accumulates an infinite geometric series
+ * (see __update_load_avg() in kernel/sched/fair.c).
+ *
+ * [load_avg definition]
+ *
+ * load_avg = runnable% * load
+ *
+ * where runnable% is the time ratio that a sched_entity is runnable.
+ * For cfs_rq, it is the aggregated such load_avg of all runnable and
  * blocked sched_entities.
- * The 64 bit load_sum can:
- * 1) for cfs_rq, afford 4353082796 (=2^64/47742/88761) entities with
- * the highest weight (=88761) always runnable, we should not overflow
- * 2) for entity, support any load.weight always runnable
+ *
+ * load_avg may also take frequency scaling into account:
+ *
+ * load_avg = runnable% * load * freq%
+ *
+ * where freq% is the CPU frequency normalize to the highest frequency
+ *
+ * [util_avg definition]
+ *
+ * util_avg = running% * SCHED_CAPACITY_SCALE
+ *
+ * where running% is the time ratio that a sched_entity is running on
+ * a CPU. For cfs_rq, it is the aggregated such util_avg of all running
+ * and blocked sched_entities.
+ *
+ * util_avg may also factor frequency scaling and CPU capacity scaling:
+ *
+ * util_avg = running% * SCHED_CAPACITY_SCALE * freq% * capacity%
+ *
+ * where freq% is the same as above, and capacity% is the CPU capacity
+ * normalized to the greatest capacity (due to uarch differences, etc).
+ *
+ * N.B., the above ratios (runnable%, running%, freq%, and capacity%)
+ * themselves are in the range of [0, 1]. We therefore scale them to
+ * not lose the intermediate values due to integer rounding and provide
+ * as fine resolution as necessary. This is for example reflected by
+ * util_avg's SCHED_CAPACITY_SCALE.
+ *
+ * [Overflow issue]
+ *
+ * On 64bit kernel:
+ *
+ * When load has low resolution (SCHED_RESOLUTION_SHIFT), the 64bit
+ * load_sum can have 4353082796 (=2^64/47742/88761) entities with
+ * the highest load (=88761) always runnable on a cfs_rq, we should
+ * not overflow.
+ *
+ * When load has high resolution (2*SCHED_RESOLUTION_SHIFT), the 64bit
+ * load_sum can have 4251057 (=2^64/47742/88761/1024) entities with
+ * the highest load (=88761*1024) always runnable on ONE cfs_rq, we
+ * should be fine.
+ *
+ * For all other cases (including 32bit kernel), struct load_weight's
+ * weight will overflow first before we do, because:
+ *
+ *Max(load_avg) <= Max(load.weight)
+ *
+ * Then, it is the load_weight's responsibility to consider overflow
+ * issues.
  */
 struct sched_avg {
u64 last_update_time, load_sum;
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index fdb7937..807d960 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -680,7 +680,7 @@ void init_entity_runnable_average(struct sched_entity *se)
 * will definitely be update (after enqueue).
 */
sa->period_contrib = 1023;
-   sa->load_avg = scale_load_down(se->load.weight);
+   sa->load_avg = se->load.weight;
sa->load_sum = sa->load_avg * LOAD_AVG_MAX;
sa->util_avg = SCHED_CAPACITY_SCALE;
sa->util_sum = sa->util_avg * LOAD_AVG_MAX;
@@ -2697,7 +2697,7 @@ static inline int update_cfs_rq_load_avg(u64 now, struct 
cfs_rq *cfs_rq)
}
 
decayed = __update_load_avg(now, cpu_of(rq_of(cfs_rq)), sa,
-   scale_load_down(cfs_rq->load.weight), cfs_rq->curr != NULL, 
cfs_rq);
+   cfs_rq->load.weight, cfs_rq->curr != NULL, cfs_rq);
 
 #ifndef CONFIG_64BIT
smp_wmb();
@@ -27

[PATCH 4/4] sched/fair: Rename scale_load() and scale_load_down()

Rename scale_load() and scale_load_down() to user_to_kernel_load()
and kernel_to_user_load() respectively, to allow the names to bear
what they are really about.

Signed-off-by: Yuyang Du 
---
 kernel/sched/core.c  |  8 
 kernel/sched/fair.c  |  7 ---
 kernel/sched/sched.h | 15 ---
 3 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index ffe7b7e..1359871 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -818,12 +818,12 @@ static void set_load_weight(struct task_struct *p)
 * SCHED_IDLE tasks get minimal weight:
 */
if (idle_policy(p->policy)) {
-   load->weight = scale_load(WEIGHT_IDLEPRIO);
+   load->weight = user_to_kernel_load(WEIGHT_IDLEPRIO);
load->inv_weight = WMULT_IDLEPRIO;
return;
}
 
-   load->weight = scale_load(prio_to_weight[prio]);
+   load->weight = user_to_kernel_load(prio_to_weight[prio]);
load->inv_weight = prio_to_wmult[prio];
 }
 
@@ -8199,7 +8199,7 @@ static void cpu_cgroup_exit(struct cgroup_subsys_state 
*css,
 static int cpu_shares_write_u64(struct cgroup_subsys_state *css,
struct cftype *cftype, u64 shareval)
 {
-   return sched_group_set_shares(css_tg(css), scale_load(shareval));
+   return sched_group_set_shares(css_tg(css), 
user_to_kernel_load(shareval));
 }
 
 static u64 cpu_shares_read_u64(struct cgroup_subsys_state *css,
@@ -8207,7 +8207,7 @@ static u64 cpu_shares_read_u64(struct cgroup_subsys_state 
*css,
 {
struct task_group *tg = css_tg(css);
 
-   return (u64) scale_load_down(tg->shares);
+   return (u64) kernel_to_user_load(tg->shares);
 }
 
 #ifdef CONFIG_CFS_BANDWIDTH
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 807d960..72db21e 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -189,7 +189,7 @@ static void __update_inv_weight(struct load_weight *lw)
if (likely(lw->inv_weight))
return;
 
-   w = scale_load_down(lw->weight);
+   w = kernel_to_user_load(lw->weight);
 
if (BITS_PER_LONG > 32 && unlikely(w >= WMULT_CONST))
lw->inv_weight = 1;
@@ -213,7 +213,7 @@ static void __update_inv_weight(struct load_weight *lw)
  */
 static u64 __calc_delta(u64 delta_exec, unsigned long weight, struct 
load_weight *lw)
 {
-   u64 fact = scale_load_down(weight);
+   u64 fact = kernel_to_user_load(weight);
int shift = WMULT_SHIFT;
 
__update_inv_weight(lw);
@@ -8205,7 +8205,8 @@ int sched_group_set_shares(struct task_group *tg, 
unsigned long shares)
if (!tg->se[0])
return -EINVAL;
 
-   shares = clamp(shares, scale_load(MIN_SHARES), scale_load(MAX_SHARES));
+   shares = clamp(shares, user_to_kernel_load(MIN_SHARES),
+  user_to_kernel_load(MAX_SHARES));
 
mutex_lock(&shares_mutex);
if (tg->shares == shares)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 3d03956..0a1e972 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -54,21 +54,22 @@ static inline void update_cpu_load_active(struct rq 
*this_rq) { }
  */
 #if 0 /* BITS_PER_LONG > 32 -- currently broken: it increases power usage 
under light load  */
 # define NICE_0_LOAD_SHIFT (SCHED_RESOLUTION_SHIFT + 
SCHED_RESOLUTION_SHIFT)
-# define scale_load(w) ((w) << SCHED_RESOLUTION_SHIFT)
-# define scale_load_down(w)((w) >> SCHED_RESOLUTION_SHIFT)
+# define user_to_kernel_load(w)((w) << SCHED_RESOLUTION_SHIFT)
+# define kernel_to_user_load(w)((w) >> SCHED_RESOLUTION_SHIFT)
 #else
 # define NICE_0_LOAD_SHIFT (SCHED_RESOLUTION_SHIFT)
-# define scale_load(w) (w)
-# define scale_load_down(w)(w)
+# define user_to_kernel_load(w)(w)
+# define kernel_to_user_load(w)(w)
 #endif
 
 /*
  * Task weight (visible to user) and its load (invisible to user) have
  * independent resolution, but they should be well calibrated. We use
- * scale_load() and scale_load_down(w) to convert between them. The
- * following must be true:
+ * user_to_kernel_load() and kernel_to_user_load(w) to convert between
+ * them. The following must be true:
  *
- *  scale_load(prio_to_weight[USER_PRIO(NICE_TO_PRIO(0))]) == NICE_0_LOAD
+ * user_to_kernel_load(prio_to_weight[USER_PRIO(NICE_TO_PRIO(0))]) == 
NICE_0_LOAD
+ * kernel_to_user_load(NICE_0_LOAD) == 
prio_to_weight[USER_PRIO(NICE_TO_PRIO(0))]
  *
  */
 #define NICE_0_LOAD(1L << NICE_0_LOAD_SHIFT)
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/4] sched/fair: Clean up sched metric definitions

Hi Peter and Ingo,

As discussed recently, the sched metrics need a little bit cleanup. This
series of patches attempt to do that: refactor, rename, remove...

Thanks a lot to Ben, Morten, Dietmar, Vincent, and others who provided
valuable comments.

Thanks,
Yuyang

Yuyang Du (4):
  sched/fair: Generalize the load/util averages resolution definition
  sched/fair: Remove SCHED_LOAD_SHIFT and SCHED_LOAD_SCALE
  sched/fair: Remove scale_load_down() for load_avg
  sched/fair: Rename scale_load() and scale_load_down()

 include/linux/sched.h | 80 +++
 kernel/sched/core.c   |  8 +++---
 kernel/sched/fair.c   | 26 +++--
 kernel/sched/sched.h  | 30 +++
 4 files changed, 101 insertions(+), 43 deletions(-)

-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/4] sched/fair: Remove SCHED_LOAD_SHIFT and SCHED_LOAD_SCALE

After cleaning up the sched metrics, these two definitions that cause
ambiguity are not needed any more. Use NICE_0_LOAD_SHIFT and NICE_0_LOAD
instead (the names suggest clearly who they are).

Suggested-by: Ben Segall 
Signed-off-by: Yuyang Du 
---
 kernel/sched/fair.c  |  4 ++--
 kernel/sched/sched.h | 22 +++---
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index c61fd8e..fdb7937 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -682,7 +682,7 @@ void init_entity_runnable_average(struct sched_entity *se)
sa->period_contrib = 1023;
sa->load_avg = scale_load_down(se->load.weight);
sa->load_sum = sa->load_avg * LOAD_AVG_MAX;
-   sa->util_avg = scale_load_down(SCHED_LOAD_SCALE);
+   sa->util_avg = SCHED_CAPACITY_SCALE;
sa->util_sum = sa->util_avg * LOAD_AVG_MAX;
/* when this task enqueue'ed, it will contribute to its cfs_rq's 
load_avg */
 }
@@ -6651,7 +6651,7 @@ static inline void calculate_imbalance(struct lb_env 
*env, struct sd_lb_stats *s
if (busiest->group_type == group_overloaded &&
local->group_type   == group_overloaded) {
load_above_capacity = busiest->sum_nr_running *
-   SCHED_LOAD_SCALE;
+   SCHED_CAPACITY_SCALE;
if (load_above_capacity > busiest->group_capacity)
load_above_capacity -= busiest->group_capacity;
else
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 31b4022..3d03956 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -53,25 +53,25 @@ static inline void update_cpu_load_active(struct rq 
*this_rq) { }
  * increased costs.
  */
 #if 0 /* BITS_PER_LONG > 32 -- currently broken: it increases power usage 
under light load  */
-# define SCHED_LOAD_SHIFT  (SCHED_RESOLUTION_SHIFT + 
SCHED_RESOLUTION_SHIFT)
+# define NICE_0_LOAD_SHIFT (SCHED_RESOLUTION_SHIFT + 
SCHED_RESOLUTION_SHIFT)
 # define scale_load(w) ((w) << SCHED_RESOLUTION_SHIFT)
 # define scale_load_down(w)((w) >> SCHED_RESOLUTION_SHIFT)
 #else
-# define SCHED_LOAD_SHIFT  (SCHED_RESOLUTION_SHIFT)
+# define NICE_0_LOAD_SHIFT (SCHED_RESOLUTION_SHIFT)
 # define scale_load(w) (w)
 # define scale_load_down(w)(w)
 #endif
 
-#define SCHED_LOAD_SCALE   (1L << SCHED_LOAD_SHIFT)
-
 /*
- * NICE_0's weight (visible to user) and its load (invisible to user) have
- * independent resolution, but they should be well calibrated. We use 
scale_load()
- * and scale_load_down(w) to convert between them, the following must be true:
- * scale_load(prio_to_weight[20]) == NICE_0_LOAD
+ * Task weight (visible to user) and its load (invisible to user) have
+ * independent resolution, but they should be well calibrated. We use
+ * scale_load() and scale_load_down(w) to convert between them. The
+ * following must be true:
+ *
+ *  scale_load(prio_to_weight[USER_PRIO(NICE_TO_PRIO(0))]) == NICE_0_LOAD
+ *
  */
-#define NICE_0_LOADSCHED_LOAD_SCALE
-#define NICE_0_SHIFT   SCHED_LOAD_SHIFT
+#define NICE_0_LOAD(1L << NICE_0_LOAD_SHIFT)
 
 /*
  * Single value that decides SCHED_DEADLINE internal math precision.
@@ -850,7 +850,7 @@ DECLARE_PER_CPU(struct sched_domain *, sd_asym);
 struct sched_group_capacity {
atomic_t ref;
/*
-* CPU capacity of this group, SCHED_LOAD_SCALE being max capacity
+* CPU capacity of this group, SCHED_CAPACITY_SCALE being max capacity
 * for a single CPU.
 */
unsigned int capacity;
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/4] sched/fair: Generalize the load/util averages resolution definition

Metric needs certain resolution to allow detail we can look into,
which also determines the range of the metric.

For instance, increasing the resolution of [0, 1] (two levels), one
can multiply 1024 and get [0..1024] (1025 levels).

In sched/fair, a few metrics depend on the resolution: weight, load,
load_avg, util_avg, freq, and capacity. In order to reduce the risks
of making mistakes relating to the resolution and range, we generalize
the resolution by defining a basic resolution constant number, and
then formalize all metrics to base on the basic resolution.

The basic resolution is 1024 or (1 << 10). Further, one can recursively
apply the basic resolution to have higher resolution.

Pointed out by Ben Segall, weight (visible to user, e.g., NICE-0 has
1024) and load (e.g., NICE_0_LOAD) have independent resolution, but
they must be well calibrated.

Signed-off-by: Yuyang Du 
---
 include/linux/sched.h | 15 ---
 kernel/sched/fair.c   |  4 
 kernel/sched/sched.h  | 15 ++-
 3 files changed, 22 insertions(+), 12 deletions(-)

diff --git a/include/linux/sched.h b/include/linux/sched.h
index bd38b3e..b3ba0fb 100644
--- a/include/linux/sched.h
+++ b/include/linux/sched.h
@@ -910,9 +910,18 @@ enum cpu_idle_type {
 };
 
 /*
+ * Integer metrics need certain resolution to allow how much detail we
+ * can look into, e.g., load, load_avg, util_avg, freq, and capacity.
+ * We define a basic resolution constant number, and then formalize
+ * all these metrics based on that basic resolution.
+ */
+# define SCHED_RESOLUTION_SHIFT10
+# define SCHED_RESOLUTION_SCALE(1L << SCHED_RESOLUTION_SHIFT)
+
+/*
  * Increase resolution of cpu_capacity calculations
  */
-#define SCHED_CAPACITY_SHIFT   10
+#define SCHED_CAPACITY_SHIFT   SCHED_RESOLUTION_SHIFT
 #define SCHED_CAPACITY_SCALE   (1L << SCHED_CAPACITY_SHIFT)
 
 /*
@@ -1180,8 +1189,8 @@ struct load_weight {
  * 1) load_avg factors frequency scaling into the amount of time that a
  * sched_entity is runnable on a rq into its weight. For cfs_rq, it is the
  * aggregated such weights of all runnable and blocked sched_entities.
- * 2) util_avg factors frequency and cpu scaling into the amount of time
- * that a sched_entity is running on a CPU, in the range [0..SCHED_LOAD_SCALE].
+ * 2) util_avg factors frequency and cpu capacity scaling into the amount of 
time
+ * that a sched_entity is running on a CPU, in the range 
[0..SCHED_CAPACITY_SCALE].
  * For cfs_rq, it is the aggregated such times of all runnable and
  * blocked sched_entities.
  * The 64 bit load_sum can:
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 4df37a4..c61fd8e 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2522,10 +2522,6 @@ static u32 __compute_runnable_contrib(u64 n)
return contrib + runnable_avg_yN_sum[n];
 }
 
-#if (SCHED_LOAD_SHIFT - SCHED_LOAD_RESOLUTION) != 10 || SCHED_CAPACITY_SHIFT 
!= 10
-#error "load tracking assumes 2^10 as unit"
-#endif
-
 #define cap_scale(v, s) ((v)*(s) >> SCHED_CAPACITY_SHIFT)
 
 /*
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index 3845a71..31b4022 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -53,18 +53,23 @@ static inline void update_cpu_load_active(struct rq 
*this_rq) { }
  * increased costs.
  */
 #if 0 /* BITS_PER_LONG > 32 -- currently broken: it increases power usage 
under light load  */
-# define SCHED_LOAD_RESOLUTION 10
-# define scale_load(w) ((w) << SCHED_LOAD_RESOLUTION)
-# define scale_load_down(w)((w) >> SCHED_LOAD_RESOLUTION)
+# define SCHED_LOAD_SHIFT  (SCHED_RESOLUTION_SHIFT + 
SCHED_RESOLUTION_SHIFT)
+# define scale_load(w) ((w) << SCHED_RESOLUTION_SHIFT)
+# define scale_load_down(w)((w) >> SCHED_RESOLUTION_SHIFT)
 #else
-# define SCHED_LOAD_RESOLUTION 0
+# define SCHED_LOAD_SHIFT  (SCHED_RESOLUTION_SHIFT)
 # define scale_load(w) (w)
 # define scale_load_down(w)(w)
 #endif
 
-#define SCHED_LOAD_SHIFT   (10 + SCHED_LOAD_RESOLUTION)
 #define SCHED_LOAD_SCALE   (1L << SCHED_LOAD_SHIFT)
 
+/*
+ * NICE_0's weight (visible to user) and its load (invisible to user) have
+ * independent resolution, but they should be well calibrated. We use 
scale_load()
+ * and scale_load_down(w) to convert between them, the following must be true:
+ * scale_load(prio_to_weight[20]) == NICE_0_LOAD
+ */
 #define NICE_0_LOADSCHED_LOAD_SCALE
 #define NICE_0_SHIFT   SCHED_LOAD_SHIFT
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH v8 0/10] Add external dma support for Synopsys MSHC

2015-10-04 Thread Jaehoon Chung

Hi, Shawn.

On 10/02/2015 06:49 PM, Shawn Lin wrote:
> On 2015/10/1 17:14, Jaehoon Chung wrote:
>> Dear, All.
>>
>> I will apply patch 01-03 at my repository on today.
>> But i don't know better how i do about other patches relevant to config file.
>>
> 
> Thanks, Jaehoon. :)
> 
> I guess it would be acceptable to pick the config changes, already they were 
> acked by the soc maintainers, via dw_mmc tree when ulf merge dw_mmc tree into 
> his mmc-tree.

Some patches didn't get the maintainer's acked-by. 
I will wait for that..until this week. How about?

Best Regards,
Jaehoon Chung

> 
> 
>> Best Regards,
>> Jaehoon Chung
>>
>> On 09/16/2015 03:40 PM, Shawn Lin wrote:
>>> Synopsys DesignWare mobile storage host controller supports three
>>> types of transfer mode: pio, internal dma and external dma. However,
>>> dw_mmc can only supports pio and internal dma now. Thus some platforms
>>> using dw-mshc integrated with generic dma can't work in dma mode. So we
>>> submit this patch to achieve it.
>>>
>>> And the config option, CONFIG_MMC_DW_IDMAC, was added by Will Newton
>>> (commit:f95f3850) for the first version of dw_mmc and never be touched since
>>> then. At that time dt-bindings hadn't been introduced into dw_mmc yet means
>>> we should select CONFIG_MMC_DW_IDMAC to enable internal dma mode at compile
>>> time. Nowadays, device-tree helps us to support a variety of boards with one
>>> kernel. That's why we need to remove it and decide the transfer mode by 
>>> reading
>>> dw_mmc's HCON reg at runtime.
>>>
>>> This RFC patch needs lots of ACKs. I know it's hard, but it does need 
>>> someone
>>> to make the running.
>>>
>>> Patch does the following things:
>>> - remove CONFIG_MMC_DW_IDMAC config option
>>> - add bindings for edmac used by synopsys-dw-mshc
>>>at runtime
>>> - add edmac support for synopsys-dw-mshc
>>>
>>> Patch is based on next of git://git.linaro.org/people/ulf.hansson/mmc
>>>
>>> Test emmc throughput on my platform with edmac support and without edmac 
>>> support(pio only)
>>> iozone -L64 -S32 -azecwI -+n -r4k -r64k -r128k -s1g -i0 -i1 -i2 -f datafile 
>>> -Rb out.xls > /mnt/result.txt
>>> (light cpu loading, Direct IO, fixed line size, all pattern recycle, 1GB 
>>> data in total)
>>>   ___
>>> |   external dma mode   |
>>> |---|
>>> |blksz | Random Read | Random Write | Seq Read   | Seq Write|
>>> |---|
>>> |4kB   |  13953kB/s  |8602kB/s  | 13672kB/s  |  9785kB/s|
>>> |---|
>>> |64kB  |  46058kB/s  |   24794kB/s  | 48058kB/s  | 25418kB/s|
>>> |---|
>>> |128kB |  57026kB/s  |   35117kB/s  | 57375kB/s  | 35183kB/s|
>>> |---|
>>> VS
>>>   ___
>>> |  pio mode |
>>> |---|
>>> |blksz | Random Read  | Random Write | Seq Read  | Seq Write|
>>> |---|
>>> |4kB   |  11720kB/s   |8644kB/s  | 11549kB/s |  9624kB/s|
>>> |---|
>>> |64kB  |  21869kB/s   |   24414kB/s  | 22031kB/s | 27986kB/s|
>>> |---|
>>> |128kB |  23718kB/s   |   34495kB/s  | 24698kB/s | 34637kB/s|
>>> |---|
>>>
>>>
>>> Changes in v8:
>>> - remove trans_mode variable
>>> - remove unnecessary dma_ops check
>>> - remove unnecessary comment
>>> - fix coding style based on latest ulf's next
>>> - add Acked-by: Jaehoon Chung 
>>>for HCON's changes
>>>
>>> Changes in v7:
>>> - rebased on Ulf's next
>>> - combine condition state
>>> - elaborate more about DMA_INTERFACE
>>> - define some macro for DMA_INERFACE value
>>> - spilt HCON ops' changes into another patch
>>>
>>> Changes in v6:
>>> - add trans_mode condition for IDMAC initialization
>>>suggested by Heiko
>>> - re-test my patch on rk3188 platform and update commit msg
>>> - update performance of pio vs edmac in cover letter
>>>
>>> Changes in v5:
>>> - add the title of cover letter
>>> - fix typo of comment
>>> - add macro for reading HCON register
>>> - add "Acked-by: Krzysztof Kozlowski " for 
>>> exynos_defconfig patch
>>> - add "Acked-by: Vineet Gupta " for axs10x_defconfig 
>>> patch
>>> - add "Acked-by: Govindraj Raja " and
>>>"Acked-by: Ralf Baechle " for pistachio_defconfig 
>>> patch
>>> - add "Acked-by: Joachim Eastwood " for 
>>> lpc18xx_defconfig patch
>>> - add "Acked-by: Wei Xu " for hisi_defconfig patch
>>> - rebase on "https://github.com/jh80chung/dw-mmc.git 
>>> tags/dw-mm

RE: [GIT PULL] Samsung fixes for v4.3

2015-10-04 Thread Kukjin Kim

Krzysztof Kozlowski wrote:
> 
> On 30.09.2015 15:50, Kukjin Kim wrote:
> > On 09/30/15 08:59, Krzysztof Kozlowski wrote:
> >> Dear Kukjin,
> >>
> >> Below you will find fixes for current release cycle which are not
> >> present yet in your tree.
> >>
> >> Best regards,
> >> Krzysztof
> >>
> >>
> >> The following changes since commit 
> >> 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
> >>
> >>   Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
> >>
> >> are available in the git repository at:
> >>
> >>   https://github.com/krzk/linux.git tags/samsung-fixes-4.3
> >>
> >> for you to fetch changes up to c7d2ecd9f64c351cb4d551f1f472d0fc09c3cae8:
> >>
> >>   ARM: dts: Fix wrong clock binding for sysmmu_fimd1_1 on exynos5420 
> >> (2015-09-29 15:39:58 +0900)
> >>
> >> 
> >> Fixes for Exynos (DT and mach code):
> >> 1. Finally fix booting of all 8 cores on Exynos Octa (Exynos542x): all
> >>8 cores are booting and can be used. The fix, based on vendor
> >>code and bootloader behavior, is as for time being only
> >>for MCPM enabled path.
> >> 2. Fix thermal boot issue on SMDK5250.
> >> 3. Fix invalid clock used for FIMD IOMMU.
> >>
> > Pulled, thanks.
> >
> > Note it will be sent to upstream in a day.
> 
> A day extended to a week. Please do not hold the fixes but send them. If
> they reached Linus tree late and they required any further fix, then we
> would have less time for any updates.
> 
Sorry for the delay and it's my fault. I'll handle it tonight...

> The same applies for regular pull request for 4.4. For previous v4.3
> release many changes were too late (so they could even slip from 4.3 to
> 4.4). Can we just avoid such issues and send pull requests earlier?
> 
Krzysztof, I sent a pull request lately because of handling of cross-tree but I
don't think so it causes some missing because it was due to cross tree not only
mine. Please don't worry about that I'll handle it.

Anyway thanks for your gentle reminder.

- Kukjin

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/4] mm, documentation: clarify /proc/pid/status VmSwap limitations

On Fri, 2 Oct 2015, Vlastimil Babka wrote:

> The documentation for /proc/pid/status does not mention that the value of
> VmSwap counts only swapped out anonymous private pages and not shmem. This is
> not obvious, so document this limitation.
> 
> Signed-off-by: Vlastimil Babka 
> Acked-by: Konstantin Khlebnikov 
> Acked-by: Michal Hocko 
> ---
>  Documentation/filesystems/proc.txt | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/filesystems/proc.txt 
> b/Documentation/filesystems/proc.txt
> index a99b208..7ef50cb 100644
> --- a/Documentation/filesystems/proc.txt
> +++ b/Documentation/filesystems/proc.txt
> @@ -239,6 +239,8 @@ Table 1-2: Contents of the status files (as of 4.1)
>   VmPTE   size of page table entries
>   VmPMD   size of second level page tables
>   VmSwap  size of swap usage (the number of referred 
> swapents)
> + by anonymous private data (shmem swap usage is 
> not
> + included)

I have difficulty in reading "size of swap usage (the number of referred
swapents) by anonymous private data (shmem swap usage is not included)".

Luckily, VmSwap never was "the number of referred swapents", it's in kB.
So I suggestamount of swap used by anonymous private data
(shmem swap usage is not included)

for which you can assume Acked-by: Hugh Dickins 

Hugh

>   HugetlbPagessize of hugetlb memory portions
>   Threads number of threads
>   SigQnumber of signals queued/max. number for queue
> -- 
> 2.5.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] usb-host: Remove fusbh200 driver

2015-10-04 Thread 江峰興

Hi Balbi,

>> John Feng-Hsin Chiang, can you confirm that from your side the
>> fusbh200 driver can be deleted?
>... but let's get this confirmation.

Yes, you can delete fusbh200.

Best Regards,
John Chiang

-Original Message-
From: Felipe Balbi [mailto:ba...@ti.com] 
Sent: Sunday, October 04, 2015 5:21 AM
To: Peter Senna Tschudin
Cc: John Feng-Hsin Chiang(江峰興); Yuan-Hsin Chen; Greg Kroah-Hartman; Alan Stern; 
mathias.ny...@linux.intel.com; r...@linux-mips.org; 
alexandre.bell...@free-electrons.com; ramneek.mehr...@freescale.com; Laurent 
Pinchart; abres...@chromium.org; sb...@codeaurora.org; Rafał Miłecki; 
haoke...@gmail.com; pebo...@tiscali.nl; Sergei Shtylyov; Masanari Iida; Randy 
Dunlap; ch...@rorvick.com; linux-kernel@vger.kernel.org; 
linux-...@vger.kernel.org
Subject: Re: [PATCH] usb-host: Remove fusbh200 driver

Peter Senna Tschudin  writes:

> On Fri, Oct 2, 2015 at 7:39 PM, Felipe Balbi  wrote:
>> On Fri, Oct 02, 2015 at 01:18:27PM +0200, Peter Senna Tschudin wrote:
>>> fusbh200 and fotg210 are very similar. The initial idea was to 
>>> consolidate both drivers but I'm afraid fusbh200 is not being used.
>>>
>>> This patch remove the fusbh200 source code, update Kconfig and two 
>>> Makefiles.
>>>
>>> Signed-off-by: Peter Senna Tschudin 
>>
>> after all this work on these previous patches, you just remove fusbh200 ?
>>
>> that's a bit odd. Are you sure there are no users for this driver ? 
>> It has been in tree since 2013.
> I don't know about users, but I could not find devices using fusbh200.
> The closest I got was:
>
> http://www.ebay.fr/itm/Digital-Video-Langzeit-Recorder-H264-DVR-3G-4-K
> anal-/370525106495
>
> But it only says: Main Processor: Faraday. I don't know which usb host 
> controller it uses.
>
> The idea of deleting fusbh200 came from contacting the driver authors.
> I was asking where to find hw for testing, and I was told that the
> fusbh200 driver can be deleted. Also at least Fedora and Ubuntu build 
> modules for these host controllers by default. If fusbh200 and fotg210 
> are only available integrated into SOCs, maybe building the modules by 
> default for x86 is not a good idea. But if there are users I'll be 
> happy to continue the integration work, even better if I find hardware 
> for testing.

fair enough, if can be deleted it's fine...

> John Feng-Hsin Chiang, can you confirm that from your side the
> fusbh200 driver can be deleted?

... but let's get this confirmation.

> For the patches I sent, 10 of 14 are for fotg210 which I'll fix and resend.

cool, thanks

--
balbi
N떑꿩�r툤y鉉싕b쾊Ф푤v�^�)頻{.n�+돴쪐{콗喩zX㎍썳變}찠꼿쟺�&j:+v돣�쳭喩zZ+�+zf＂톒쉱�~넮녬i鎬z�췿ⅱ�?솳鈺�&�)刪f뷌^j푹y쬶끷@A첺뛴
0띠h��뭝

[PATCH v2] misc: mic: replace kfree with put_device

2015-10-04 Thread Geliang Tang

Handle a failed device_register(), replace kfree() with put_device(),
which will call mbus_release_dev() or scif_release_dev().

Signed-off-by: Geliang Tang 
---
Changes in v2:
  - Just refresh this patch.
---
 drivers/misc/mic/bus/mic_bus.c  | 2 +-
 drivers/misc/mic/bus/scif_bus.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/mic/bus/mic_bus.c b/drivers/misc/mic/bus/mic_bus.c
index c64955d..be37890 100644
--- a/drivers/misc/mic/bus/mic_bus.c
+++ b/drivers/misc/mic/bus/mic_bus.c
@@ -175,7 +175,7 @@ mbus_register_device(struct device *pdev, int id, struct 
dma_map_ops *dma_ops,
goto free_mbdev;
return mbdev;
 free_mbdev:
-   kfree(mbdev);
+   put_device(&mbdev->dev);
return ERR_PTR(ret);
 }
 EXPORT_SYMBOL_GPL(mbus_register_device);
diff --git a/drivers/misc/mic/bus/scif_bus.c b/drivers/misc/mic/bus/scif_bus.c
index fd27021..ff6e01c 100644
--- a/drivers/misc/mic/bus/scif_bus.c
+++ b/drivers/misc/mic/bus/scif_bus.c
@@ -180,7 +180,7 @@ scif_register_device(struct device *pdev, int id, struct 
dma_map_ops *dma_ops,
goto free_sdev;
return sdev;
 free_sdev:
-   kfree(sdev);
+   put_device(&sdev->dev);
return ERR_PTR(ret);
 }
 EXPORT_SYMBOL_GPL(scif_register_device);
-- 
2.5.0


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [GIT PULL] Samsung fixes for v4.3

2015-10-04 Thread Krzysztof Kozlowski

On 30.09.2015 15:50, Kukjin Kim wrote:
> On 09/30/15 08:59, Krzysztof Kozlowski wrote:
>> Dear Kukjin,
>>
>> Below you will find fixes for current release cycle which are not
>> present yet in your tree.
>>
>> Best regards,
>> Krzysztof
>>
>>
>> The following changes since commit 6ff33f3902c3b1c5d0db6b1e2c70b6d76fba357f:
>>
>>   Linux 4.3-rc1 (2015-09-12 16:35:56 -0700)
>>
>> are available in the git repository at:
>>
>>   https://github.com/krzk/linux.git tags/samsung-fixes-4.3
>>
>> for you to fetch changes up to c7d2ecd9f64c351cb4d551f1f472d0fc09c3cae8:
>>
>>   ARM: dts: Fix wrong clock binding for sysmmu_fimd1_1 on exynos5420 
>> (2015-09-29 15:39:58 +0900)
>>
>> 
>> Fixes for Exynos (DT and mach code):
>> 1. Finally fix booting of all 8 cores on Exynos Octa (Exynos542x): all
>>8 cores are booting and can be used. The fix, based on vendor
>>code and bootloader behavior, is as for time being only
>>for MCPM enabled path.
>> 2. Fix thermal boot issue on SMDK5250.
>> 3. Fix invalid clock used for FIMD IOMMU.
>>
> Pulled, thanks.
> 
> Note it will be sent to upstream in a day.

A day extended to a week. Please do not hold the fixes but send them. If
they reached Linus tree late and they required any further fix, then we
would have less time for any updates.

The same applies for regular pull request for 4.4. For previous v4.3
release many changes were too late (so they could even slip from 4.3 to
4.4). Can we just avoid such issues and send pull requests earlier?

Best regards,
Krzysztof

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH][RESEND] drm: panel-simple: add URT UMSH-8596MD-xT panel support

2015-10-04 Thread Maciej S. Szmigiero

Hi Emil,

Thanks for your response,

On 04.10.2015 12:43, Emil Velikov wrote:
> Hi Maciej,
> 
> On 2 October 2015 at 22:40, Maciej S. Szmigiero
>  wrote:
>> Anybody here?
>>
>> I've already submitted this patch two times but received no response...
>>
> Seems that the maintainer (Thierry) isn't Cc'ed.

Yes, he was Cc'ed - see for example https://patchwork.ozlabs.org/patch/512858/ .

> You might want to
> split the DT binding and vendor prefix to separate patches.

Do you mean to first submit new vendor prefix then panel patch with docs?
Or even docs separately?

> -Emil
> 

Best regards,
Maciej

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCHv4 2/2] staging: rtl8192u: r8192U_core: reuse local temporary variables to keep lines under 80 characters

2015-10-04 Thread Raphaël Beamonte

Reuse some local temporary variables to reduce line length under the maximum
of 80 characters, as per the kernel code style.

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/rtl8192u/r8192U_core.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index e67be02..35f7d0e 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -1704,8 +1704,9 @@ static short rtl8192_usb_initendpoints(struct net_device 
*dev)
oldaddr = priv->oldaddr;
align = ((long)oldaddr) & 3;
if (align) {
-   newaddr = oldaddr + 4 - align;
-   priv->rx_urb[16]->transfer_buffer_length = 16 - 4 + 
align;
+   align = 4 - align;
+   newaddr = oldaddr + align;
+   priv->rx_urb[16]->transfer_buffer_length = 16 - align;
} else {
newaddr = oldaddr;
priv->rx_urb[16]->transfer_buffer_length = 16;
@@ -5198,7 +5199,8 @@ void setKey(struct net_device *dev, u8 EntryNo, u8 
KeyIndex, u16 KeyType,
} else {
/* Key Material */
if (KeyContent != NULL) {
-   write_nic_dword(dev, WCAMI, (u32)(*(KeyContent 
+ i - 2)));
+   TargetContent = (u32)(*(KeyContent + i - 2));
+   write_nic_dword(dev, WCAMI, TargetContent);
write_nic_dword(dev, RWCAM, TargetCommand);
}
}
-- 
2.5.3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 1/5] gadget: Introduce the notifier functions

2015-10-04 Thread Mark Brown

On Fri, Oct 02, 2015 at 02:11:25PM -0500, Felipe Balbi wrote:
> On Fri, Oct 02, 2015 at 07:49:09PM +0100, Mark Brown wrote:
> > On Fri, Oct 02, 2015 at 12:23:11PM -0500, Felipe Balbi wrote:

> > > > Things more difficult, if nothing else it means we need to get whatever
> > > > userspace component deployed in all relevant userspace stacks with
> > > > appropriate configuration in order to do things.

> > > but that will be a thing for the kernel too. We will have to deploy this 
> > > new
> > > kernel component in all relevant stacks with appropriate configuration in 
> > > order
> > > to do things :-) No changes there.

> > Sure, but it's one project which is developed entirely in the open -
> > that's a lot more manageable.

> We can have a fully open source userland daemon too. Much like systemd, bluez,
> neard, and many, many others. Why wouldn't that be a thing ?

The trouble is getting traction on adoption.  Vendors have a habit of
doing things like finding problems and rather than reporting them
deciding that the open source solution isn't great and going and writing
their own thing (especially when they're in stealth mode) rather than
talking to anyone.  Sometimes we manage to avoid that but it can be
challenging, and often we only even hear about the new thing after it's
shipping and there's a lot of inertia behind changing it.  The kernel
ABIs tend to be a lot sticker than userspace things here.

> Similar applies to power delivery charging profile themselves. Not all 
> profiles
> are mandatory. Some are optional and that will be completely device/board
> specific. How an OEM implements that in the PCB is also completely
> board-specific :-) Some might have a dumb IC hardcoding some messages, some
> might have something largely more flexible.

Right, and what I was trying to say was that it seems like the kernel
ought to be worrying about the board specific bits and userspace
worrying about what to do with those bits.

> > The things we've got with audio are a combination of tuning to taste and
> > (even more importantly) very different ideas about what you want to do
> > with an audio subsystem that influence how you set things up in a given
> > use case.

> the same thing will happen with Type-C and power delivery. There won't be 
> tuning
> to taste, of course :-) But there will be "very different ideas what what you
> want to do with" your charging methodology.

Are those very different things about the use cases ("don't bother with
high speed data, get all the power you can" or whatever) or are they
about the details of the board?

> > > Actually, I was thinking about it in a more granular fashion. Kernel 
> > > exposes a
> > > charger/power_supply, a few regulators, a UDC view and this single 
> > > userspace
> > > daemon figures out how to tie those together.

> > That sounds worrying - it means that new hardware support needs
> > supporting in every userspace (it seems inevitable that there will be at
> > least some reimplementations because that's fun) which gets old really
> > fast, and every userspace needs to understand every topology.

> very true, but it's also true for a kernel solution.

> It seems like you want it in the kernel because of it being convenient :-)

Yes, definitely - my experience both in terms of watching how people
like handset vendors often work internally and in terms of getting
things adopted is that it's a lot easier if you can have one component
you need to update to handle new hardware rather than multiple ones that
need to be upgraded for things that are purely board differences.

> > > The view here isn't really a USB port, it's just a source of power. But 
> > > how much
> > > power we can draw from it depends on, possibly, a ton of different chips 
> > > and
> > > different notifications.

> > Right, yes - it's the power input/output associated with the USB port.
> > The USB port is just the physical thing users can see so it's a good way
> > to label it.  That could mean that we ought to move the aggregation bit
> > into the power supply code of course, but then a lot of the decisions
> > are going to be specific to USB.

> in a sense, yes. But they can happen at a layer which knows nothing (or very
> little) about USB. Here's an example:

> Not everybody follows USB Battery Charging class. Some chargers don't short
> D+/D- to signify they are a wall charger. Some will use different resistance
> values on the ID pin to tell you how much current you can draw from them.

> From a PMIC (or something else) point of view, all it needs is a tiny current
> source and a an ADC, then it reports the ADC value to the upper layer. This
> really doesn't even need to know that it's using an ID pin, or whatever.

This doesn't seem much different to things like the various GPIO to
subsystem X drivers we've got - we already have some for IIO type
things IIRC.

> > How different are the end goals of these designs really going to be
> > though - that's more of the questi

[PATCHv4 1/2] staging: rtl8192u: r8192U_core: add temporary variables to keep lines under 80 characters

2015-10-04 Thread Raphaël Beamonte

Add some temporary variables to reduce line length under the maximum
of 80 characters, as per the kernel code style.

Signed-off-by: Raphaël Beamonte 
---
 drivers/staging/rtl8192u/r8192U_core.c | 130 ++---
 1 file changed, 88 insertions(+), 42 deletions(-)

diff --git a/drivers/staging/rtl8192u/r8192U_core.c 
b/drivers/staging/rtl8192u/r8192U_core.c
index 28b54ba..e67be02 100644
--- a/drivers/staging/rtl8192u/r8192U_core.c
+++ b/drivers/staging/rtl8192u/r8192U_core.c
@@ -171,6 +171,7 @@ static void rtl819x_set_channel_map(u8 channel_plan, struct 
r8192_priv *priv)
 {
int i, max_chan = -1, min_chan = -1;
struct ieee80211_device *ieee = priv->ieee80211;
+   struct CHANNEL_LIST *cl;
 
switch (channel_plan) {
case COUNTRY_CODE_FCC:
@@ -194,15 +195,18 @@ static void rtl819x_set_channel_map(u8 channel_plan, 
struct r8192_priv *priv)
 "unknown rf chip, can't set channel map in 
function:%s()\n",
 __func__);
}
-   if (ChannelPlan[channel_plan].Len != 0) {
+   cl = &ChannelPlan[channel_plan];
+   if (cl->Len != 0) {
/* Clear old channel map */
memset(GET_DOT11D_INFO(ieee)->channel_map, 0,
   sizeof(GET_DOT11D_INFO(ieee)->channel_map));
/* Set new channel map */
-   for (i = 0; i < ChannelPlan[channel_plan].Len; i++) {
-   if (ChannelPlan[channel_plan].Channel[i] < 
min_chan || ChannelPlan[channel_plan].Channel[i] > max_chan)
+   for (i = 0; i < cl->Len; i++) {
+   u8 chan = cl->Channel[i];
+
+   if (chan < min_chan || chan > max_chan)
break;
-   
GET_DOT11D_INFO(ieee)->channel_map[ChannelPlan[channel_plan].Channel[i]] = 1;
+   GET_DOT11D_INFO(ieee)->channel_map[chan] = 1;
}
}
break;
@@ -1649,9 +1653,11 @@ short rtl8192_tx(struct net_device *dev, struct sk_buff 
*skb)
  &zero, 0, tx_zero_isr, dev);
status = usb_submit_urb(tx_urb_zero, GFP_ATOMIC);
if (status) {
+   int idx = tcb_desc->queue_index;
+
RT_TRACE(COMP_ERR,
 "Error TX URB for zero byte %d, error 
%d",
-
atomic_read(&priv->tx_pending[tcb_desc->queue_index]),
+atomic_read(&priv->tx_pending[idx]),
 status);
return -1;
}
@@ -1863,7 +1869,9 @@ static void rtl8192_qos_activate(struct work_struct *work)
 */
for (i = 0; i <  QOS_QUEUE_NUM; i++) {
/* Mode G/A: slotTimeTimer = 9; Mode B: 20 */
-   u1bAIFS = qos_parameters->aifs[i] * ((mode & (IEEE_G | 
IEEE_N_24G)) ? 9 : 20) + aSifsTime;
+   int slotTimeTimer = ((mode & (IEEE_G | IEEE_N_24G)) ? 9 : 20);
+
+   u1bAIFS = qos_parameters->aifs[i] * slotTimeTimer + aSifsTime;
u1bAIFS <<= AC_PARAM_AIFS_OFFSET;
op_limit = (u32)le16_to_cpu(qos_parameters->tx_op_limit[i]);
op_limit <<= AC_PARAM_TXOP_LIMIT_OFFSET;
@@ -2071,10 +2079,12 @@ static bool GetNmodeSupportBySecCfg8192(struct 
net_device *dev)
return false;
} else if ((wpa_ie_len != 0)) {
/* parse pairwise key type */
-   if (((ieee->wpa_ie[0] == 0xdd) && (!memcmp(&(ieee->wpa_ie[14]), 
ccmp_ie, 4))) || ((ieee->wpa_ie[0] == 0x30) && (!memcmp(&ieee->wpa_ie[10], 
ccmp_rsn_ie, 4
-   return true;
-   else
-   return false;
+   bool wpaie_dd = (ieee->wpa_ie[0] == 0xdd &&
+!memcmp(&ieee->wpa_ie[14], ccmp_ie, 4));
+   bool wpaie_30 = (ieee->wpa_ie[0] == 0x30 &&
+!memcmp(&ieee->wpa_ie[10], ccmp_rsn_ie, 4));
+
+   return (wpaie_dd || wpaie_30);
} else {
return true;
}
@@ -2420,9 +2430,9 @@ static void rtl8192_read_eeprom_info(struct net_device 
*dev)
int i;
 
for (i = 0; i < 6; i += 2) {
-   u16 tmp = 0;
+   u16 tmp = ((EEPROM_NODE_ADDRESS_BYTE_0 + i) >> 1);
 
-   tmp = eprom_read(dev, (u16)((EEPROM_NODE_ADDRESS_BYTE_0 
+ i) >> 1));
+   tmp = eprom_read(dev, tmp);
*(u16 *)(&dev->dev_addr[i]) = tmp;
}
} else {
@@ -2952,9 +2962,11 @@ static bool rtl8192_adapter_start(st

[PATCH] rbtree: clarify documentation of rbtree_postorder_for_each_entry_safe()

2015-10-04 Thread Cody P Schafer

Noticed that commit a20135ffbc44 ("writeback: don't drain
bdi_writeback_congested on bdi destruction") added a usage of
rbtree_postorder_for_each_entry_safe() in mm/backing-dev.c which appears
to try to rb_erase() elements from an rbtree while iterating over it
using rbtree_postorder_for_each_entry_safe().

Doing this will cause random nodes to be missed by the iteration because
rb_erase() may rebalance the tree, changing the ordering that we're
trying to iterate over.

The previous documentation for rbtree_postorder_for_each_entry_safe()
wasn't clear that this wasn't allowed, it was taken from the docs for
list_for_each_entry_safe(), where erasing isn't a problem due to
list_del() not reordering.

Explicitly warn developers about this potential pit-fall.

Note that I haven't fixed the actual issue that (it appears) the commit
referenced above introduced (not familiar enough with that code).

In general (and in this case), the patterns to follow are:
 - switch to rb_first() + rb_erase(), don't use
   rbtree_postorder_for_each_entry_safe().
 - keep the postorder iteration and don't rb_erase() at all. Instead
   just clear the fields of rb_node & cgwb_congested_tree as required by
   other users of those structures.

CC: Tejun Heo 
Signed-off-by: Cody P Schafer 
---
 include/linux/rbtree.h | 12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/include/linux/rbtree.h b/include/linux/rbtree.h
index 830c499..39de3df 100644
--- a/include/linux/rbtree.h
+++ b/include/linux/rbtree.h
@@ -101,13 +101,21 @@ static inline void rb_link_node_rcu(struct rb_node *node, 
struct rb_node *parent
})
 
 /**
- * rbtree_postorder_for_each_entry_safe - iterate over rb_root in post order of
- * given type safe against removal of rb_node entry
+ * rbtree_postorder_for_each_entry_safe - iterate in post-order over rb_root of
+ * given type allowing the backing memory of @pos to be invalidated
  *
  * @pos:   the 'type *' to use as a loop cursor.
  * @n: another 'type *' to use as temporary storage
  * @root:  'rb_root *' of the rbtree.
  * @field: the name of the rb_node field within 'type'.
+ *
+ * This function provides a similar guarantee as list_for_each_entry_safe() and
+ * allows the iteration to continue independent of changes to @pos by the body
+ * of the loop.
+ *
+ * Note, however, that it cannot handle other modifications that re-order the
+ * rbtree it is iterating over. This includes calling rb_erase() on @pos, as
+ * rb_erase() may rebalance the tree, causing us to miss some nodes.
  */
 #define rbtree_postorder_for_each_entry_safe(pos, n, root, field) \
for (pos = rb_entry_safe(rb_first_postorder(root), typeof(*pos), 
field); \
-- 
2.4.9

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] memcg: simplify charging kmem pages

2015-10-04 Thread Vladimir Davydov

Charging kmem pages proceeds in two steps. First, we try to charge the
allocation size to the memcg the current task belongs to, then we
allocate a page and "commit" the charge storing the pointer to the memcg
in the page struct.

Such a design looks overcomplicated, because there is no much sense in
trying charging the allocation before actually allocating a page: we
won't be able to consume much memory over the limit even if we charge
after doing the actual allocation, besides we already charge user pages
post factum, so being pedantic with kmem pages just looks pointless.

So this patch simplifies the design by merging the "charge" and the
"commit" steps into the same function, which takes the allocated page.

Also, rename the charge and uncharge methods to memcg_kmem_charge and
memcg_kmem_uncharge and make the charge method return error code instead
of bool to conform to mem_cgroup_try_charge.

Signed-off-by: Vladimir Davydov 
---
 include/linux/memcontrol.h | 69 +-
 mm/memcontrol.c| 39 +++---
 mm/page_alloc.c| 18 ++--
 3 files changed, 32 insertions(+), 94 deletions(-)

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index a3e0296eb063..9e1f4d5efc56 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -752,11 +752,8 @@ static inline bool memcg_kmem_is_active(struct mem_cgroup 
*memcg)
  * conditions, but because they are pretty simple, they are expected to be
  * fast.
  */
-bool __memcg_kmem_newpage_charge(gfp_t gfp, struct mem_cgroup **memcg,
-   int order);
-void __memcg_kmem_commit_charge(struct page *page,
-  struct mem_cgroup *memcg, int order);
-void __memcg_kmem_uncharge_pages(struct page *page, int order);
+int __memcg_kmem_charge(struct page *page, gfp_t gfp, int order);
+void __memcg_kmem_uncharge(struct page *page, int order);
 
 /*
  * helper for acessing a memcg's index. It will be used as an index in the
@@ -789,52 +786,30 @@ static inline bool __memcg_kmem_bypass(gfp_t gfp)
 }
 
 /**
- * memcg_kmem_newpage_charge: verify if a new kmem allocation is allowed.
- * @gfp: the gfp allocation flags.
- * @memcg: a pointer to the memcg this was charged against.
- * @order: allocation order.
+ * memcg_kmem_charge: charge a kmem page
+ * @page: page to charge
+ * @gfp: reclaim mode
+ * @order: allocation order
  *
- * returns true if the memcg where the current task belongs can hold this
- * allocation.
- *
- * We return true automatically if this allocation is not to be accounted to
- * any memcg.
+ * Returns 0 on success, an error code on failure.
  */
-static inline bool
-memcg_kmem_newpage_charge(gfp_t gfp, struct mem_cgroup **memcg, int order)
+static __always_inline int memcg_kmem_charge(struct page *page,
+gfp_t gfp, int order)
 {
if (__memcg_kmem_bypass(gfp))
-   return true;
-   return __memcg_kmem_newpage_charge(gfp, memcg, order);
+   return 0;
+   return __memcg_kmem_charge(page, gfp, order);
 }
 
 /**
- * memcg_kmem_uncharge_pages: uncharge pages from memcg
- * @page: pointer to struct page being freed
- * @order: allocation order.
+ * memcg_kmem_uncharge: uncharge a kmem page
+ * @page: page to uncharge
+ * @order: allocation order
  */
-static inline void
-memcg_kmem_uncharge_pages(struct page *page, int order)
+static __always_inline void memcg_kmem_uncharge(struct page *page, int order)
 {
if (memcg_kmem_enabled())
-   __memcg_kmem_uncharge_pages(page, order);
-}
-
-/**
- * memcg_kmem_commit_charge: embeds correct memcg in a page
- * @page: pointer to struct page recently allocated
- * @memcg: the memcg structure we charged against
- * @order: allocation order.
- *
- * Needs to be called after memcg_kmem_newpage_charge, regardless of success or
- * failure of the allocation. if @page is NULL, this function will revert the
- * charges. Otherwise, it will commit @page to @memcg.
- */
-static inline void
-memcg_kmem_commit_charge(struct page *page, struct mem_cgroup *memcg, int 
order)
-{
-   if (memcg_kmem_enabled() && memcg)
-   __memcg_kmem_commit_charge(page, memcg, order);
+   __memcg_kmem_uncharge(page, order);
 }
 
 /**
@@ -878,18 +853,12 @@ static inline bool memcg_kmem_is_active(struct mem_cgroup 
*memcg)
return false;
 }
 
-static inline bool
-memcg_kmem_newpage_charge(gfp_t gfp, struct mem_cgroup **memcg, int order)
-{
-   return true;
-}
-
-static inline void memcg_kmem_uncharge_pages(struct page *page, int order)
+static inline int memcg_kmem_charge(struct page *page, gfp_t gfp, int order)
 {
+   return 0;
 }
 
-static inline void
-memcg_kmem_commit_charge(struct page *page, struct mem_cgroup *memcg, int 
order)
+static inline void memcg_kmem_uncharge(struct page *page, int order)
 {
 }
 
diff --git a/mm/memcontrol.c

[PATCH 3/3] memcg: simplify and inline __mem_cgroup_from_kmem

2015-10-04 Thread Vladimir Davydov

Before the previous patch, __mem_cgroup_from_kmem had to handle two
types of kmem - slab pages and pages allocated with alloc_kmem_pages -
differently, because slab pages did not store information about owner
memcg in the page struct. Now we can unify it. Since after it, this
function becomes tiny we can fold it into mem_cgroup_from_kmem.

Signed-off-by: Vladimir Davydov 
---
 include/linux/memcontrol.h |  7 ---
 mm/memcontrol.c| 18 --
 2 files changed, 4 insertions(+), 21 deletions(-)

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 8a9b7a798f14..0e2e039609d1 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -769,8 +769,6 @@ static inline int memcg_cache_id(struct mem_cgroup *memcg)
 struct kmem_cache *__memcg_kmem_get_cache(struct kmem_cache *cachep);
 void __memcg_kmem_put_cache(struct kmem_cache *cachep);
 
-struct mem_cgroup *__mem_cgroup_from_kmem(void *ptr);
-
 static inline bool __memcg_kmem_bypass(gfp_t gfp)
 {
if (!memcg_kmem_enabled())
@@ -832,9 +830,12 @@ static __always_inline void memcg_kmem_put_cache(struct 
kmem_cache *cachep)
 
 static __always_inline struct mem_cgroup *mem_cgroup_from_kmem(void *ptr)
 {
+   struct page *page;
+
if (!memcg_kmem_enabled())
return NULL;
-   return __mem_cgroup_from_kmem(ptr);
+   page = virt_to_head_page(ptr);
+   return page->mem_cgroup;
 }
 #else
 #define for_each_memcg_cache_index(_idx)   \
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 1d6413e0dd29..6329e6182d89 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2430,24 +2430,6 @@ void __memcg_kmem_uncharge(struct page *page, int order)
page->mem_cgroup = NULL;
css_put_many(&memcg->css, nr_pages);
 }
-
-struct mem_cgroup *__mem_cgroup_from_kmem(void *ptr)
-{
-   struct mem_cgroup *memcg = NULL;
-   struct kmem_cache *cachep;
-   struct page *page;
-
-   page = virt_to_head_page(ptr);
-   if (PageSlab(page)) {
-   cachep = page->slab_cache;
-   if (!is_root_cache(cachep))
-   memcg = cachep->memcg_params.memcg;
-   } else
-   /* page allocated by alloc_kmem_pages */
-   memcg = page->mem_cgroup;
-
-   return memcg;
-}
 #endif /* CONFIG_MEMCG_KMEM */
 
 #ifdef CONFIG_TRANSPARENT_HUGEPAGE
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] memcg: unify slab and other kmem pages charging

2015-10-04 Thread Vladimir Davydov

We have memcg_kmem_charge and memcg_kmem_uncharge methods for charging
and uncharging kmem pages to memcg, but currently they are not used for
charging slab pages (i.e. they are only used for charging pages
allocated with alloc_kmem_pages). The only reason why the slab subsystem
uses special helpers, memcg_charge_slab and memcg_uncharge_slab, is that
it needs to charge to the memcg of kmem cache while memcg_charge_kmem
charges to the memcg that the current task belongs to.

To remove this diversity, this patch adds an extra argument to
__memcg_kmem_charge that can be a pointer to a memcg or NULL. If it is
not NULL, the function tries to charge to the memcg it points to,
otherwise it charge to the current context. Next, it makes the slab
subsystem use this function to charge slab pages.

Since memcg_charge_kmem and memcg_uncharge_kmem helpers are now used
only in __memcg_kmem_charge and __memcg_kmem_uncharge, they are inlined.
Since __memcg_kmem_charge stores a pointer to the memcg in the page
struct, we don't need memcg_uncharge_slab anymore and can use
free_kmem_pages. Besides, one can now detect which memcg a slab page
belongs to by reading /proc/kpagecgroup.

Note, this patch switches slab to charge-after-alloc design. Since this
design is already used for all other memcg charges, it should not make
any difference.

Signed-off-by: Vladimir Davydov 
---
 include/linux/memcontrol.h |  9 ++
 mm/memcontrol.c| 73 +-
 mm/slab.c  | 12 
 mm/slab.h  | 24 +--
 mm/slub.c  | 12 
 5 files changed, 55 insertions(+), 75 deletions(-)

diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index 9e1f4d5efc56..8a9b7a798f14 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -752,7 +752,8 @@ static inline bool memcg_kmem_is_active(struct mem_cgroup 
*memcg)
  * conditions, but because they are pretty simple, they are expected to be
  * fast.
  */
-int __memcg_kmem_charge(struct page *page, gfp_t gfp, int order);
+int __memcg_kmem_charge(struct page *page, gfp_t gfp, int order,
+   struct mem_cgroup *memcg);
 void __memcg_kmem_uncharge(struct page *page, int order);
 
 /*
@@ -770,10 +771,6 @@ void __memcg_kmem_put_cache(struct kmem_cache *cachep);
 
 struct mem_cgroup *__mem_cgroup_from_kmem(void *ptr);
 
-int memcg_charge_kmem(struct mem_cgroup *memcg, gfp_t gfp,
- unsigned long nr_pages);
-void memcg_uncharge_kmem(struct mem_cgroup *memcg, unsigned long nr_pages);
-
 static inline bool __memcg_kmem_bypass(gfp_t gfp)
 {
if (!memcg_kmem_enabled())
@@ -798,7 +795,7 @@ static __always_inline int memcg_kmem_charge(struct page 
*page,
 {
if (__memcg_kmem_bypass(gfp))
return 0;
-   return __memcg_kmem_charge(page, gfp, order);
+   return __memcg_kmem_charge(page, gfp, order, NULL);
 }
 
 /**
diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 7c0af36fc8d0..1d6413e0dd29 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -2215,34 +2215,6 @@ static void commit_charge(struct page *page, struct 
mem_cgroup *memcg,
 }
 
 #ifdef CONFIG_MEMCG_KMEM
-int memcg_charge_kmem(struct mem_cgroup *memcg, gfp_t gfp,
- unsigned long nr_pages)
-{
-   struct page_counter *counter;
-   int ret = 0;
-
-   ret = page_counter_try_charge(&memcg->kmem, nr_pages, &counter);
-   if (ret < 0)
-   return ret;
-
-   ret = try_charge(memcg, gfp, nr_pages);
-   if (ret)
-   page_counter_uncharge(&memcg->kmem, nr_pages);
-
-   return ret;
-}
-
-void memcg_uncharge_kmem(struct mem_cgroup *memcg, unsigned long nr_pages)
-{
-   page_counter_uncharge(&memcg->memory, nr_pages);
-   if (do_swap_account)
-   page_counter_uncharge(&memcg->memsw, nr_pages);
-
-   page_counter_uncharge(&memcg->kmem, nr_pages);
-
-   css_put_many(&memcg->css, nr_pages);
-}
-
 static int memcg_alloc_cache_id(void)
 {
int id, size;
@@ -2404,36 +2376,59 @@ void __memcg_kmem_put_cache(struct kmem_cache *cachep)
css_put(&cachep->memcg_params.memcg->css);
 }
 
-int __memcg_kmem_charge(struct page *page, gfp_t gfp, int order)
+/*
+ * If @memcg != NULL, charge to @memcg, otherwise charge to the memcg the
+ * current task belongs to.
+ */
+int __memcg_kmem_charge(struct page *page, gfp_t gfp, int order,
+   struct mem_cgroup *memcg)
 {
-   struct mem_cgroup *memcg;
-   int ret;
-
-   memcg = get_mem_cgroup_from_mm(current->mm);
+   struct page_counter *counter;
+   unsigned int nr_pages = 1 << order;
+   bool put = false;
+   int ret = 0;
 
-   if (!memcg_kmem_is_active(memcg)) {
-   css_put(&memcg->css);
-   return 0;
+   if (!memcg) {
+   memcg = get_mem_cgroup_from_mm(current->mm);
+   put = true;
}
+   if

Re: [PATCH] ebpf, events: make it actually more configurable

2015-10-04 Thread Daniel Borkmann


On 10/03/2015 10:24 AM, Ingo Molnar wrote:
...

Feel free to send a patch that adds a sentence to that help text that explains
that this is an internal helper Kconfig entry that does not need to be
interactively configurable.


Sorry for the late reply. I think it's actually fine as-is, noticed that the
same is being done various times in this Kconfig.

Thanks again,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] PCI: prevent out of bounds access in numa_node override

2015-10-04 Thread Sasha Levin

Commit 63692df1 ("PCI: Allow numa_node override via sysfs") didn't check that
the numa node provided by userspace is valid. Passing a node number too high
would attempt to access invalid memory and trigger a kernel panic.

Fixes: 63692df1 ("PCI: Allow numa_node override via sysfs")
Signed-off-by: Sasha Levin 
---
 drivers/pci/pci-sysfs.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 312f23a..e9abca8 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -216,7 +216,7 @@ static ssize_t numa_node_store(struct device *dev,
if (ret)
return ret;
 
-   if (!node_online(node))
+   if (node > MAX_NUMNODES || !node_online(node))
return -EINVAL;
 
add_taint(TAINT_FIRMWARE_WORKAROUND, LOCKDEP_STILL_OK);
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/5] mtd: brcmnand: Optional DT flag to reset IPROC NAND controller

2015-10-04 Thread Brian Norris

+ Rafal (to extend this mighty CC list)

On Fri, Oct 02, 2015 at 11:26:44PM +0530, Anup Patel wrote:
> The BRCM NAND controller on NS2 SoC requires a reset to
> cleanup previously configured NAND controller state.
> 
> This patch adds optional boolean device tree flag named
> "brcm,nand-iproc-reset". If this flag is present in NAND
> controller DT node then BRCM IPROC NAND driver will reset
> the NAND controller before any commands are issued.

Is there a reason not to do this reset unconditionally? I recall this
came up in discussion previously, when the OpenWRT folks were trying to
integrate with BCMA, where this reset was one of the few differences
between the platform-device-based driver (i.e., this one) and the BCMA
based driver. Might it help simplify things a bit if we just did the
same thing everywhere?

Brian

> Signed-off-by: Anup Patel 
> Reviewed-by: Pramod KUMAR 
> Reviewed-by: Ray Jui 
> Reviewed-by: Scott Branden 
> ---
>  drivers/mtd/nand/brcmnand/iproc_nand.c | 19 +++
>  1 file changed, 19 insertions(+)
> 
> diff --git a/drivers/mtd/nand/brcmnand/iproc_nand.c 
> b/drivers/mtd/nand/brcmnand/iproc_nand.c
> index 683495c..d837207 100644
> --- a/drivers/mtd/nand/brcmnand/iproc_nand.c
> +++ b/drivers/mtd/nand/brcmnand/iproc_nand.c
> @@ -11,6 +11,7 @@
>   * GNU General Public License for more details.
>   */
>  
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -35,6 +36,10 @@ struct iproc_nand_soc_priv {
>  #define IPROC_NAND_APB_LE_MODE BIT(24)
>  #define IPROC_NAND_INT_CTRL_READ_ENABLEBIT(6)
>  
> +#define IPROC_NAND_RESET_OFFSET0x3f8
> +#define IPROC_NAND_RESET_BIT_SHIFT 0
> +#define IPROC_NAND_RESET_BIT   BIT(IPROC_NAND_RESET_BIT_SHIFT)
> +
>  static bool iproc_nand_intc_ack(struct brcmnand_soc *soc)
>  {
>   struct iproc_nand_soc_priv *priv = soc->priv;
> @@ -93,6 +98,7 @@ static void iproc_nand_apb_access(struct brcmnand_soc *soc, 
> bool prepare)
>  
>  static int iproc_nand_probe(struct platform_device *pdev)
>  {
> + u32 reset;
>   struct device *dev = &pdev->dev;
>   struct iproc_nand_soc_priv *priv;
>   struct brcmnand_soc *soc;
> @@ -124,6 +130,19 @@ static int iproc_nand_probe(struct platform_device *pdev)
>   soc->ctlrdy_set_enabled = iproc_nand_intc_set;
>   soc->prepare_data_bus = iproc_nand_apb_access;
>  
> + if (of_property_read_bool(dev->of_node, "brcm,nand-iproc-reset")) {
> + /* Put controller in reset and wait 10 usecs */
> + reset = readl(priv->idm_base + IPROC_NAND_RESET_OFFSET);
> + reset |= IPROC_NAND_RESET_BIT;
> + writel(reset, priv->idm_base + IPROC_NAND_RESET_OFFSET);
> + udelay(10);
> + /* Bring controller out of reset and wait 10 usecs */
> + reset = readl(priv->idm_base + IPROC_NAND_RESET_OFFSET);
> + reset &= ~IPROC_NAND_RESET_BIT;
> + writel(reset, priv->idm_base + IPROC_NAND_RESET_OFFSET);
> + udelay(10);
> + }
> +
>   return brcmnand_probe(pdev, soc);
>  }
>  
> -- 
> 1.9.1
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] pinctrl: at91-pio4: Use irq_set_handler_locked()

2015-10-04 Thread Nicolas Ferre

Le 02/10/2015 15:57, Nicolas Ferre a écrit :
> Hi all,
> 
> Well it seems my cover letter is missing. So, here it is:
> 
> ---8<
> pinctrl: at91-pio4: fixes for current linux-next (irq)
> 
> While testing the sama5d2 on today's linux-next I discovered that some
> adaptations were missing. So, I don't know if you were aware but here
> are my fixes in case you don't have them already.
> 
> +Cc: Thomas and Stephen in case these errors happen while building
> linux-next...

After seeing that Linus applied 2 patches by Ludovic, I realized that as
I had foreseen correctly: it was known and corrected.

Sorry for the noise. Bye,
-- 
Nicolas Ferre
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 8/8] bdc_pci: use PCI_VDEVICE() instead of PCI_DEVICE()

Fix using the PCI_DEVICE() macro instead of less verbose PCI_VDEVICE().

Signed-off-by: Sergei Shtylyov 

---
 drivers/usb/gadget/udc/bdc/bdc_pci.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: usb/drivers/usb/gadget/udc/bdc/bdc_pci.c
===
--- usb.orig/drivers/usb/gadget/udc/bdc/bdc_pci.c
+++ usb/drivers/usb/gadget/udc/bdc/bdc_pci.c
@@ -113,7 +113,7 @@ static void bdc_pci_remove(struct pci_de
 }
 
 static struct pci_device_id bdc_pci_id_table[] = {
-   { PCI_DEVICE(PCI_VENDOR_ID_BROADCOM, BDC_PCI_PID), },
+   { PCI_VDEVICE(BROADCOM, BDC_PCI_PID), },
{} /* Terminating Entry */
 };
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 7/8] pch_udc: use PCI_VDEVICE() instead of PCI_DEVICE()

Fix using the PCI_DEVICE() macro instead of less verbose PCI_VDEVICE().

Signed-off-by: Sergei Shtylyov 

---
 drivers/usb/gadget/udc/pch_udc.c |9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

Index: usb/drivers/usb/gadget/udc/pch_udc.c
===
--- usb.orig/drivers/usb/gadget/udc/pch_udc.c
+++ usb/drivers/usb/gadget/udc/pch_udc.c
@@ -3232,23 +3232,22 @@ finished:
 
 static const struct pci_device_id pch_udc_pcidev_id[] = {
{
-   PCI_DEVICE(PCI_VENDOR_ID_INTEL,
-  PCI_DEVICE_ID_INTEL_QUARK_X1000_UDC),
+   PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_QUARK_X1000_UDC),
.class = (PCI_CLASS_SERIAL_USB << 8) | 0xfe,
.class_mask = 0x,
},
{
-   PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_EG20T_UDC),
+   PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_EG20T_UDC),
.class = (PCI_CLASS_SERIAL_USB << 8) | 0xfe,
.class_mask = 0x,
},
{
-   PCI_DEVICE(PCI_VENDOR_ID_ROHM, PCI_DEVICE_ID_ML7213_IOH_UDC),
+   PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7213_IOH_UDC),
.class = (PCI_CLASS_SERIAL_USB << 8) | 0xfe,
.class_mask = 0x,
},
{
-   PCI_DEVICE(PCI_VENDOR_ID_ROHM, PCI_DEVICE_ID_ML7831_IOH_UDC),
+   PCI_VDEVICE(ROHM, PCI_DEVICE_ID_ML7831_IOH_UDC),
.class = (PCI_CLASS_SERIAL_USB << 8) | 0xfe,
.class_mask = 0x,
},

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 6/8] amd5536udc: use PCI_VDEVICE() instead of PCI_DEVICE()

Fix using the PCI_DEVICE() macro instead of less verbose PCI_VDEVICE().

Signed-off-by: Sergei Shtylyov 

---
 drivers/usb/gadget/udc/amd5536udc.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: usb/drivers/usb/gadget/udc/amd5536udc.c
===
--- usb.orig/drivers/usb/gadget/udc/amd5536udc.c
+++ usb/drivers/usb/gadget/udc/amd5536udc.c
@@ -3405,7 +3405,7 @@ static int udc_remote_wakeup(struct udc
 /* PCI device parameters */
 static const struct pci_device_id pci_id[] = {
{
-   PCI_DEVICE(PCI_VENDOR_ID_AMD, 0x2096),
+   PCI_VDEVICE(AMD, 0x2096),
.class =(PCI_CLASS_SERIAL_USB << 8) | 0xfe,
.class_mask =   0x,
},

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] usbhid: Fix for the WiiU adapter from Mayflash

2015-10-04 Thread Jiri Kosina

On Sat, 3 Oct 2015, Felipe Balbi wrote:

> > The WiiU adapter from Mayflash (see 
> > http://www.mayflash.com/Products/NINTENDOWiiU/W009.html) is not 
> > working correctly.
> >
> > The "XInput" mode works fine, the controller is recognized as a xbox 
> > controller. But it is only possible to connect one controller with 
> > this method.
> >
> > In "DInput" mode the device is recognized as some kind of mouse input 
> > but no joystick is created. This commit will change this behavior with 
> > HID_QUIRK_MULTI_INPUT to split the device into 4 input devices so that 
> > it will also create joysticks in /dev/input/js*.
> >
> 
> Please split your commit log so that sentences don't go over 72
> characters.
> 
> Other than that:
> 
> Reviewed-by: Felipe Balbi 

I've fixed up the formatting and applied to hid.git#for-4.3/upstream-fixes 
(please note that this doesn't guarantee that this patch will not go to 
4.3 still, because it alone is not going to be reason for pull request, 
but might eventually piggy-back on something that'll be needed for 4.3).

Thanks,

-- 
Jiri Kosina
SUSE Labs

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/8] dwc3-pci: use PCI_VDEVICE() instead of PCI_DEVICE()

Fix using the PCI_DEVICE() macro instead of less verbose PCI_VDEVICE().

Signed-off-by: Sergei Shtylyov 

---
 drivers/usb/dwc3/dwc3-pci.c |   17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

Index: usb/drivers/usb/dwc3/dwc3-pci.c
===
--- usb.orig/drivers/usb/dwc3/dwc3-pci.c
+++ usb/drivers/usb/dwc3/dwc3-pci.c
@@ -174,16 +174,13 @@ static void dwc3_pci_remove(struct pci_d
 }
 
 static const struct pci_device_id dwc3_pci_id_table[] = {
-   {
-   PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS,
-   PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3),
-   },
-   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BSW), },
-   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_BYT), },
-   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_MRFLD), },
-   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SPTLP), },
-   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_SPTH), },
-   { PCI_DEVICE(PCI_VENDOR_ID_AMD, PCI_DEVICE_ID_AMD_NL_USB), },
+   { PCI_VDEVICE(SYNOPSYS, PCI_DEVICE_ID_SYNOPSYS_HAPSUSB3), },
+   { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_BSW), },
+   { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_BYT), },
+   { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_MRFLD), },
+   { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_SPTLP), },
+   { PCI_VDEVICE(INTEL, PCI_DEVICE_ID_INTEL_SPTH), },
+   { PCI_VDEVICE(AMD, PCI_DEVICE_ID_AMD_NL_USB), },
{  }/* Terminating Entry */
 };
 MODULE_DEVICE_TABLE(pci, dwc3_pci_id_table);

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] brcm80211:Use proper skb wrapper function in the function brcmf_sdio_txpkt_postp

2015-10-04 Thread Arend van Spriel


On 10/03/2015 06:24 AM, Nicholas Krause wrote:

This uses the proper skb wrapper function sk_unlink in the function
brcmf_sdio_txpkt_postp to properly protect against concurrent users
accessing this skb_buff pointer or skb_buff_head pointer by locking
the spinlock as part of the passed skb_buff_head's definition due to
neither this function nor its callers locking this spinlock before
calling skb_unlink in order to avoid possible concurrent access on
either of these possibly shared structure pointers.

Signed-off-by: Nicholas Krause 
---
  drivers/net/wireless/brcm80211/brcmfmac/sdio.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
index f990e3d..6b66542 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
@@ -2308,7 +2308,7 @@ brcmf_sdio_txpkt_postp(struct brcmf_sdio *bus, struct 
sk_buff_head *pktq)
pkt_prev = pkt_next->prev;
skb_put(pkt_prev, chop_len);
}
-   __skb_unlink(pkt_next, pktq);
+   skb_unlink(pkt_next, pktq);


Not sure what issue you are trying to solve here. I am pretty sure I 
used __skb_unlink here on purpose. To my knowledge there is no 
concurrency issue so please elaborate. Your commit message seems a bit 
hypothetical.


Regards,
Arend


brcmu_pkt_buf_free_skb(pkt_next);
} else {
hdr = pkt_next->data + bus->tx_hdrlen - SDPCM_SWHDR_LEN;



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH RFC] IB/mad: remove obsolete snoop interface

2015-10-04 Thread Or Gerlitz

On Wed, Sep 30, 2015 at 9:01 AM,   wrote:

> This interface has no current users and is obsolete.

mmm, how does Sean's madeye util is working?

Or.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/8] dwc2: pci: use PCI_VDEVICE() instead of PCI_DEVICE()

Fix using the PCI_DEVICE() macro instead of less verbose PCI_VDEVICE().

Signed-off-by: Sergei Shtylyov 

---
 drivers/usb/dwc2/pci.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

Index: usb/drivers/usb/dwc2/pci.c
===
--- usb.orig/drivers/usb/dwc2/pci.c
+++ usb/drivers/usb/dwc2/pci.c
@@ -145,11 +145,10 @@ err:
 
 static const struct pci_device_id dwc2_pci_ids[] = {
{
-   PCI_DEVICE(PCI_VENDOR_ID_SYNOPSYS, PCI_PRODUCT_ID_HAPS_HSOTG),
+   PCI_VDEVICE(SYNOPSYS, PCI_PRODUCT_ID_HAPS_HSOTG),
},
{
-   PCI_DEVICE(PCI_VENDOR_ID_STMICRO,
-  PCI_DEVICE_ID_STMICRO_USB_OTG),
+   PCI_VDEVICE(STMICRO, PCI_DEVICE_ID_STMICRO_USB_OTG),
},
{ /* end: all zeroes */ }
 };

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/8] chipidea: ci_hdrc_pci: use PCI_VDEVICE() instead of PCI_DEVICE()

Fix using the PCI_DEVICE() macro instead of less verbose PCI_VDEVICE().

Signed-off-by: Sergei Shtylyov 

---
 drivers/usb/chipidea/ci_hdrc_pci.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Index: usb/drivers/usb/chipidea/ci_hdrc_pci.c
===
--- usb.orig/drivers/usb/chipidea/ci_hdrc_pci.c
+++ usb/drivers/usb/chipidea/ci_hdrc_pci.c
@@ -142,16 +142,16 @@ static const struct pci_device_id ci_hdr
.driver_data = (kernel_ulong_t)&pci_platdata,
},
{
-   PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0811),
+   PCI_VDEVICE(INTEL, 0x0811),
.driver_data = (kernel_ulong_t)&langwell_pci_platdata,
},
{
-   PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0829),
+   PCI_VDEVICE(INTEL, 0x0829),
.driver_data = (kernel_ulong_t)&penwell_pci_platdata,
},
{
/* Intel Clovertrail */
-   PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xe006),
+   PCI_VDEVICE(INTEL, 0xe006),
.driver_data = (kernel_ulong_t)&penwell_pci_platdata,
},
{ 0 } /* end: all zeroes */

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] brcm80211:Fix locking region in the function brcmf_sdio_sendfromq

2015-10-04 Thread Arend van Spriel


On 10/03/2015 06:19 PM, Nicholas Krause wrote:

This fixes the locking region in the function brcmf_sdio_sendfromq
to properly lock around the call to the function brcmrf_sdio_txpkt
in order to avoid concurrent access issues when calling this
function as stated in the function's comments about the caller
being required to lock around the call to this particular function.

Signed-off-by: Nicholas Krause 
---
  drivers/net/wireless/brcm80211/brcmfmac/sdio.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/sdio.c 
b/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
index f990e3d..da59683 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/sdio.c
@@ -2388,11 +2388,11 @@ static uint brcmf_sdio_sendfromq(struct brcmf_sdio 
*bus, uint maxframes)
break;
__skb_queue_tail(&pktq, pkt);
}
-   spin_unlock_bh(&bus->txq_lock);
if (i == 0)
break;


So what if we break here. Seems you need to do unlock if i == 0 here.

Regards,
Arend



ret = brcmf_sdio_txpkt(bus, &pktq, SDPCM_DATA_CHANNEL);
+   spin_unlock_bh(&bus->txq_lock);

cnt += i;




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/8] ohci-pci:-use-PCI_VDEVICE() instead of PCI_DEVICE()

Fix using the PCI_DEVICE() macro instead of less verbose PCI_VDEVICE().

Signed-off-by: Sergei Shtylyov 

---
 drivers/usb/host/ohci-pci.c |   20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

Index: usb/drivers/usb/host/ohci-pci.c
===
--- usb.orig/drivers/usb/host/ohci-pci.c
+++ usb/drivers/usb/host/ohci-pci.c
@@ -167,27 +167,27 @@ static int ohci_quirk_amd700(struct usb_
 /* List of quirks for OHCI */
 static const struct pci_device_id ohci_pci_quirks[] = {
{
-   PCI_DEVICE(PCI_VENDOR_ID_AMD, 0x740c),
+   PCI_VDEVICE(AMD, 0x740c),
.driver_data = (unsigned long)ohci_quirk_amd756,
},
{
-   PCI_DEVICE(PCI_VENDOR_ID_OPTI, 0xc861),
+   PCI_VDEVICE(OPTI, 0xc861),
.driver_data = (unsigned long)ohci_quirk_opti,
},
{
-   PCI_DEVICE(PCI_VENDOR_ID_NS, PCI_ANY_ID),
+   PCI_VDEVICE(NS, PCI_ANY_ID),
.driver_data = (unsigned long)ohci_quirk_ns,
},
{
-   PCI_DEVICE(PCI_VENDOR_ID_COMPAQ, 0xa0f8),
+   PCI_VDEVICE(COMPAQ, 0xa0f8),
.driver_data = (unsigned long)ohci_quirk_zfmicro,
},
{
-   PCI_DEVICE(PCI_VENDOR_ID_TOSHIBA_2, 0x01b6),
+   PCI_VDEVICE(TOSHIBA_2, 0x01b6),
.driver_data = (unsigned long)ohci_quirk_toshiba_scc,
},
{
-   PCI_DEVICE(PCI_VENDOR_ID_NEC, PCI_DEVICE_ID_NEC_USB),
+   PCI_VDEVICE(NEC, PCI_DEVICE_ID_NEC_USB),
.driver_data = (unsigned long)ohci_quirk_nec,
},
{
@@ -199,19 +199,19 @@ static const struct pci_device_id ohci_p
.driver_data= (unsigned long) broken_suspend,
},
{
-   PCI_DEVICE(PCI_VENDOR_ID_ITE, 0x8152),
+   PCI_VDEVICE(ITE, 0x8152),
.driver_data = (unsigned long) broken_suspend,
},
{
-   PCI_DEVICE(PCI_VENDOR_ID_ATI, 0x4397),
+   PCI_VDEVICE(ATI, 0x4397),
.driver_data = (unsigned long)ohci_quirk_amd700,
},
{
-   PCI_DEVICE(PCI_VENDOR_ID_ATI, 0x4398),
+   PCI_VDEVICE(ATI, 0x4398),
.driver_data = (unsigned long)ohci_quirk_amd700,
},
{
-   PCI_DEVICE(PCI_VENDOR_ID_ATI, 0x4399),
+   PCI_VDEVICE(ATI, 0x4399),
.driver_data = (unsigned long)ohci_quirk_amd700,
},
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/8] ehci-pci: use PCI_VDEVICE() instead of PCI_DEVICE()

Fix using the PCI_DEVICE() macro instead of less verbose PCI_VDEVICE().

Signed-off-by: Sergei Shtylyov 

---
 drivers/usb/host/ehci-pci.c |6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

Index: usb/drivers/usb/host/ehci-pci.c
===
--- usb.orig/drivers/usb/host/ehci-pci.c
+++ usb/drivers/usb/host/ehci-pci.c
@@ -49,9 +49,9 @@ static inline bool is_intel_quark_x1000(
  */
 static const struct pci_device_id bypass_pci_id_table[] = {
/* ChipIdea on Intel MID platform */
-   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0811), },
-   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0x0829), },
-   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 0xe006), },
+   { PCI_VDEVICE(INTEL, 0x0811), },
+   { PCI_VDEVICE(INTEL, 0x0829), },
+   { PCI_VDEVICE(INTEL, 0xe006), },
{}
 };
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [dpdk-dev] [PATCH 0/2] uio_msi: device driver




On 10/04/15 22:03, Greg KH wrote:

On Sun, Oct 04, 2015 at 07:49:35PM +0300, Vlad Zolotarov wrote:

FYI: I've just posted to linux-kernel list patches that add support for both
MSI and MSI-X interrupt modes to uio_pci_generic driver.
It addresses most (all) remarks on this thread and also fixes some issues
this code has, e.g. not disabling msi-x in remove(), etc.

U are all welcome to comment... ;)

Not if you don't at least cc: all of the uio maintainers :(

I'm just going to ignore the things, as obviously you don't want them
merged, quite strange...


I actually do mean them to be merged and I do (tried to) cc all the 
maintainers. Unfortunately I missed the first letter when I copied your 
email from the get_maintainers.pl output. I resent v3 with the correct 
email of yours. Hope u don't have (too) hard feelings about the first 
iterations of the series. Pls., believe me there was nothing personal, 
just a typo... ;)




greg k-h


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 0/3] uio: add MSI/MSI-X support to uio_pci_generic driver

This is the same v3 but with the correct email address of Greg. In the
first iteration the first letter of the email was missing... ;)

On 10/04/15 23:43, Vlad Zolotarov wrote:

This series add support for MSI and MSI-X interrupts to uio_pci_generic driver.

Currently uio_pci_generic supports only legacy INT#x interrupts source. However

there are situations when this is not enough, for instance SR-IOV VF devices
that
simply don't have INT#x capability. For such devices uio_pci_generic will simply
fail (more specifically probe() will fail).

When IOMMU is either not available (e.g. Amazon EC2) or not acceptable due to performance

overhead and thus VFIO is not an option users that develop user-space drivers
are left
without any option but to develop some proprietary UIO drivers (e.g. igb_uio
driver in Intel's
DPDK) just to be able to use UIO infrastructure.

This series provides a generic solution for this problem while preserving the original behaviour

for devices for which the original uio_pci_generic had worked before (i.e.
INT#x will be used by default).

New in v3:
- Add __iomem qualifier to temp buffer receiving ioremap value.

New in v2:
- Added #include to uio_pci_generic.c

Vlad Zolotarov (3):
uio: add ioctl support
uio_pci_generic: add MSI/MSI-X support
Documentation: update uio-howto

Documentation/DocBook/uio-howto.tmpl | 29 ++-
drivers/uio/uio.c| 15 ++
drivers/uio/uio_pci_generic.c| 410 +--
include/linux/uio_driver.h | 3 +
include/linux/uio_pci_generic.h | 36 +++
5 files changed, 467 insertions(+), 26 deletions(-)
create mode 100644 include/linux/uio_pci_generic.h

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[PATCH v3 0/3] uio: add MSI/MSI-X support to uio_pci_generic driver

This series add support for MSI and MSI-X interrupts to uio_pci_generic driver.
 
Currently uio_pci_generic supports only legacy INT#x interrupts source. However
there are situations when this is not enough, for instance SR-IOV VF devices 
that
simply don't have INT#x capability. For such devices uio_pci_generic will simply
fail (more specifically probe() will fail).
 
When IOMMU is either not available (e.g. Amazon EC2) or not acceptable due to 
performance
overhead and thus VFIO is not an option users that develop user-space drivers 
are left
without any option but to develop some proprietary UIO drivers (e.g. igb_uio 
driver in Intel's
DPDK) just to be able to use UIO infrastructure.
 
This series provides a generic solution for this problem while preserving the 
original behaviour
for devices for which the original uio_pci_generic had worked before (i.e. 
INT#x will be used by default).

New in v3:
   - Add __iomem qualifier to temp buffer receiving ioremap value.  

New in v2:
   - Added #include  to uio_pci_generic.c

Vlad Zolotarov (3):
  uio: add ioctl support
  uio_pci_generic: add MSI/MSI-X support
  Documentation: update uio-howto

 Documentation/DocBook/uio-howto.tmpl |  29 ++-
 drivers/uio/uio.c|  15 ++
 drivers/uio/uio_pci_generic.c| 410 +--
 include/linux/uio_driver.h   |   3 +
 include/linux/uio_pci_generic.h  |  36 +++
 5 files changed, 467 insertions(+), 26 deletions(-)
 create mode 100644 include/linux/uio_pci_generic.h

-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v3 3/3] Documentation: update uio-howto