Re: [PATCH 11/12] pinctrl: samsung: use __devinit section for init code

2012-10-01 Thread Linus Walleij
On Fri, Sep 28, 2012 at 11:36 PM, Arnd Bergmann a...@arndb.de wrote:

 The samsung pinctrl driver has a probe function that is
 __devinit and that calls a lot of other functions that are
 marked __init, which kbuild complains about.

 Marking everything __devinit means that the code does not
 discarded when CONFIG_HOTPLUG is set, which is a little
 more wasteful, but also more consistent

 Without this patch, building exynos_defconfig results in:

 WARNING: drivers/pinctrl/built-in.o(.devinit.text+0x124): Section mismatch in 
 reference from the function samsung_pinctrl_probe() to the function 
 .init.text:samsung_gpiolib_register()
 The function __devinit samsung_pinctrl_probe() references
 a function __init samsung_gpiolib_register().
 If samsung_gpiolib_register is only used by samsung_pinctrl_probe then
 annotate samsung_gpiolib_register with a matching annotation.

 Signed-off-by: Arnd Bergmann a...@arndb.de
 Cc: Thomas Abraham thomas.abra...@linaro.org
 Cc: Linus Walleij linus.wall...@linaro.org
 Cc: Stephen Warren swar...@nvidia.com
 Cc: Kukjin Kim kgene@samsung.com

Acked-by: Linus Walleij linus.wall...@linaro.org

I think the Samsing pinctrl driver has landed into next from some
branch in ARM SoC so you probably know better than me
where this thing should be merged...

Yours,
Linus Walleij
--
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: [PATCHv4 1/4] modem_shm: Add Modem Access Framework

2012-10-01 Thread anish singh
On Mon, Oct 1, 2012 at 11:00 AM, Arun MURTHY arun.mur...@stericsson.com wrote:
 On Fri, Sep 28, 2012 at 01:35:01PM +0530, Arun Murthy wrote:
  +#include linux/module.h
  +#include linux/slab.h
  +#include linux/err.h
  +#include linux/printk.h
  +#include linux/modem_shm/modem.h
  +
  +static struct class *modem_class;

 What's wrong with a bus_type instead?

 Can I know the advantage of using bus_type over class?


  +static int __modem_is_requested(struct device *dev, void *data) {
  +   struct modem_desc *mdesc = (struct modem_desc *)data;
  +
  +   if (!mdesc-mclients) {
  +   printk(KERN_ERR modem_access: modem description is
 NULL\n);
  +   return 0;
  +   }
  +   return atomic_read(mdesc-mclients-cnt);
  +}
  +
  +int modem_is_requested(struct modem_desc *mdesc) {
  +   return class_for_each_device(modem_class, NULL, (void *)mdesc,
  +__modem_is_requested); }

 Where is the documentation for your public api functions like this?

 Sure will include this in the next patchset.


  +
  +int modem_release(struct modem_desc *mdesc) {
  +   if (!mdesc-release)
  +   return -EFAULT;
  +
  +   if (modem_is_requested(mdesc)) {
  +   atomic_dec(mdesc-mclients-cnt);
  +   if (atomic_read(mdesc-use_cnt) == 1) {
  +   mdesc-release(mdesc);
  +   atomic_dec(mdesc-use_cnt);
  +   }

 Eeek, why aren't you using the built-in reference counting that the struct
 device provided to you, and instead are rolling your own?  This happens in
 many places, why?

 My usage of counters over here is for each modem there are many clients.
 Each of the clients will have a ref to modem_desc. Each of them use this for
 requesting and releasing the modem. One counter for tracking the request
 and release for each client which is done by variable 'cnt' in struct clients.
 The counter use_cnt is used for tracking the modem request/release 
 irrespective
 of the clients and counter cli_cnt is used for restricting the modem_get to
 the no of clients defined in no_clients.

 So totally 3 counter one for restricting the usage of modem_get by clients,
 second for restricting modem request/release at top level, and 3rd for
 restricting modem release/request for per client per modem basis.

 Can you let me know if the same can be achieved by using built-in ref
 counting?
Is this your model:
You have a modem device which can be requested by many clients.This clients
can register for a particular service which this modem provides and then after
that if it client doesn't need this service then it will call un-register.
This can happen for many clients.
So what you need is a way to track clients and once no client is in picture, you
want to de-allocate all the memory and resource associated with modem device.

If this is your model then read on otherwise please skip.
What you can do is this:
On each modem_register
 list_add(modm_dev-entry, modm_dev_list);
and once you de-register, remove the device from the modem_dev_list.

Have this in your modem_register function
modem-dev-release = modem_dev_release;
This will be called once all the device references have been released
and you need to remove all the memory/resources associated with your
modem device.So you will do the final cleanup
modem_cleanup(edev, true); //this will be false when the client just does
the modem_unregister.

Something as below:
void modem_dev_unregister(struct modem_dev *edev)
{
modem_cleanup(edev, false);
}

static void modem_dev_release(struct device *dev)
{
struct modem_dev *edev = (struct modem_dev *) dev_get_drvdata(dev);

modem_cleanup(edev, true);
}

static void modem_cleanup(struct modem_dev *edev, bool skip)
{
mutex_lock(modem_dev_list_lock);
list_del(modem-entry);
mutex_unlock(modem_dev_list_lock);

if (!skip  get_device(modem-dev)) {
//do the cleanup here
}

device_unregister(modem-dev);
put_device(modem-dev);
}

kfree(modem-dev);
}


 Thanks and Regards,
 Arun R Murthy
 --
 --
 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/
--
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] pwm: Check for negative duty-cycle and period

2012-10-01 Thread Thierry Reding
Make sure the duty-cycle and period passed in are not negative. This
should eventually be made implicit by making them unsigned. While at
it, the drivers' .config() implementations can have the equivalent
checks removed.

Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
Cc: Shawn Guo shawn@linaro.org
Cc: Mark Brown broo...@opensource.wolfsonmicro.com
Cc: Arnd Bergmann a...@arndb.de
Cc: Sachin Kamat sachin.ka...@linaro.org
Cc: Axel Lin axel@gmail.com
Cc: Kukjin Kim kgene@samsung.com
Cc: Jingoo Han jg1@samsung.com
Cc: Jonghwan Choi jhbird.c...@samsung.com
Cc: Sascha Hauer s.ha...@pengutronix.de
Cc: Philip, Avinash avinashphi...@ti.com
Cc: Vaibhav Bedia vaibhav.be...@ti.com
---
 drivers/pwm/core.c | 2 +-
 drivers/pwm/pwm-bfin.c | 3 ---
 drivers/pwm/pwm-pxa.c  | 3 ---
 drivers/pwm/pwm-samsung.c  | 3 ---
 drivers/pwm/pwm-tiecap.c   | 2 +-
 drivers/pwm/pwm-tiehrpwm.c | 2 +-
 6 files changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/pwm/core.c b/drivers/pwm/core.c
index 92b1782..f5acdaa 100644
--- a/drivers/pwm/core.c
+++ b/drivers/pwm/core.c
@@ -371,7 +371,7 @@ EXPORT_SYMBOL_GPL(pwm_free);
  */
 int pwm_config(struct pwm_device *pwm, int duty_ns, int period_ns)
 {
-   if (!pwm || period_ns == 0 || duty_ns  period_ns)
+   if (!pwm || duty_ns  0 || period_ns = 0 || duty_ns  period_ns)
return -EINVAL;
 
return pwm-chip-ops-config(pwm-chip, pwm, duty_ns, period_ns);
diff --git a/drivers/pwm/pwm-bfin.c b/drivers/pwm/pwm-bfin.c
index d53c4e7..5da8e18 100644
--- a/drivers/pwm/pwm-bfin.c
+++ b/drivers/pwm/pwm-bfin.c
@@ -69,9 +69,6 @@ static int bfin_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
unsigned long period, duty;
unsigned long long val;
 
-   if (duty_ns  0 || duty_ns  period_ns)
-   return -EINVAL;
-
val = (unsigned long long)get_sclk() * period_ns;
do_div(val, NSEC_PER_SEC);
period = val;
diff --git a/drivers/pwm/pwm-pxa.c b/drivers/pwm/pwm-pxa.c
index bd5867a..260c3a8 100644
--- a/drivers/pwm/pwm-pxa.c
+++ b/drivers/pwm/pwm-pxa.c
@@ -70,9 +70,6 @@ static int pxa_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
unsigned long offset;
int rc;
 
-   if (period_ns == 0 || duty_ns  period_ns)
-   return -EINVAL;
-
offset = pwm-hwpwm ? 0x10 : 0;
 
c = clk_get_rate(pc-clk);
diff --git a/drivers/pwm/pwm-samsung.c b/drivers/pwm/pwm-samsung.c
index e5187c0..023a3be 100644
--- a/drivers/pwm/pwm-samsung.c
+++ b/drivers/pwm/pwm-samsung.c
@@ -126,9 +126,6 @@ static int s3c_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
if (period_ns  NS_IN_HZ || duty_ns  NS_IN_HZ)
return -ERANGE;
 
-   if (duty_ns  period_ns)
-   return -EINVAL;
-
if (period_ns == s3c-period_ns 
duty_ns == s3c-duty_ns)
return 0;
diff --git a/drivers/pwm/pwm-tiecap.c b/drivers/pwm/pwm-tiecap.c
index 081471f..d6d4cf0 100644
--- a/drivers/pwm/pwm-tiecap.c
+++ b/drivers/pwm/pwm-tiecap.c
@@ -60,7 +60,7 @@ static int ecap_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
unsigned long period_cycles, duty_cycles;
unsigned int reg_val;
 
-   if (period_ns  0 || duty_ns  0 || period_ns  NSEC_PER_SEC)
+   if (period_ns  NSEC_PER_SEC)
return -ERANGE;
 
c = pc-clk_rate;
diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
index caf00fe..d3c1dff 100644
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@ -221,7 +221,7 @@ static int ehrpwm_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
unsigned short ps_divval, tb_divval;
int i, cmp_reg;
 
-   if (period_ns  0 || duty_ns  0 || period_ns  NSEC_PER_SEC)
+   if (period_ns  NSEC_PER_SEC)
return -ERANGE;
 
c = pc-clk_rate;
-- 
1.7.12.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: [RFC PATCH 1/6] Introduce acpi_match_device_id().

2012-10-01 Thread Mika Westerberg
On Sat, Sep 29, 2012 at 01:31:52PM +, Zhang, Rui wrote:
  
   +{
   + acpi_handle handle = DEVICE_ACPI_HANDLE(dev);
  
  If the device is not bound to an ACPI handle this will return NULL. And
  I don't see you doing that in this series meaning that..
  
 
 
 You're right, I should set pdev-archdata.acpi_handle to the I2C
 controller in i2c_root.c.

There already is an API for that - check drivers/acpi/glue.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: rt73usb WARNING: at net/mac80211/driver-ops.h:12 check_sdata_in_driver

2012-10-01 Thread Stephen Boyd
On 09/28/2012 05:46 AM, Dan Carpenter wrote:
 Hi Stephen,
 
 I have created a bug for this:
 https://bugzilla.kernel.org/show_bug.cgi?id=48041
 
 We only recently added the warning on that path.
 
 Please add the following information.
 *) Complete dmesg
 

Ok I've added the information to the bug. I'm still seeing it on 3.6.

--
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 0/6] ACPI: ACPI 5.0 device enumeration proposal

2012-10-01 Thread Mika Westerberg
On Fri, Sep 28, 2012 at 03:37:43PM +0800, Zhang Rui wrote:
 
 the main idea is that, for Serial Buses like I2C and SPI, we enumerate
 the controller as a platform device, and then enumerate the slaves via
 i2c/spi_register_board_info. And then, when the controller is really
 probed and enabled in the platform driver, the SPI/I2C bus code will
 enumerate I2C/SPI slaves automatically.
 And for the other devices, we will enumerate all of them as platform
 devices, which is not covered in this patch set yet.

Can you show some example how we could use this new code for example with
an existing I2C/SPI slave driver? Let's say the device uses few GPIOs, one
for interrupt and other for triggering firmware download. In addition to
that it needs a special parameters that can be extracted running the _DSM
method of the device.

Normally the driver would get this stuff from the platform data or from
Device Tree but how it is done with these 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/


[PATCH] Prevent AMD MCE oops on multi-server system

2012-10-01 Thread Daniel J Blueman
When booting on a federated multi-server system, the processor Northbridge
lookup returns NULL; add guards to prevent this causing an oops.

Signed-off-by: Daniel J Blueman dan...@numascale-asia.com
---
 arch/x86/kernel/cpu/mcheck/mce_amd.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/x86/kernel/cpu/mcheck/mce_amd.c 
b/arch/x86/kernel/cpu/mcheck/mce_amd.c
index c4e916d..698b6ec 100644
--- a/arch/x86/kernel/cpu/mcheck/mce_amd.c
+++ b/arch/x86/kernel/cpu/mcheck/mce_amd.c
@@ -576,12 +576,10 @@ static __cpuinit int threshold_create_bank(unsigned int 
cpu, unsigned int bank)
int err = 0;
 
if (shared_bank[bank]) {
-
nb = node_to_amd_nb(amd_get_nb_id(cpu));
-   WARN_ON(!nb);
 
/* threshold descriptor already initialized on this node? */
-   if (nb-bank4) {
+   if (nb  nb-bank4) {
/* yes, use it */
b = nb-bank4;
err = kobject_add(b-kobj, dev-kobj, name);
@@ -615,8 +613,10 @@ static __cpuinit int threshold_create_bank(unsigned int 
cpu, unsigned int bank)
atomic_set(b-cpus, 1);
 
/* nb is already initialized, see above */
-   WARN_ON(nb-bank4);
-   nb-bank4 = b;
+   if (nb) {
+   WARN_ON(nb-bank4);
+   nb-bank4 = b;
+   }
}
 
err = allocate_threshold_blocks(cpu, bank, 0,
-- 
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: [RFC PATCH 2/6] Introduce ACPI style match in platform_match

2012-10-01 Thread Mika Westerberg
On Fri, Sep 28, 2012 at 03:39:15PM +0800, Zhang Rui wrote:
 From 5d7ecd12c2994b8c5905d52718c2870c3b62746e Mon Sep 17 00:00:00 2001
 From: Zhang Rui rui.zh...@intel.com
 Date: Fri, 28 Sep 2012 14:51:03 +0800
 Subject: [RFC PATCH 2/6] Introduce ACPI style match in platform_match
 
 Signed-off-by: Zhang Rui rui.zh...@intel.com
 ---
  drivers/base/platform.c |8 
  1 files changed, 8 insertions(+), 0 deletions(-)
 
 diff --git a/drivers/base/platform.c b/drivers/base/platform.c
 index a1a7225..90e64c6f 100644
 --- a/drivers/base/platform.c
 +++ b/drivers/base/platform.c
 @@ -20,6 +20,7 @@
  #include linux/err.h
  #include linux/slab.h
  #include linux/pm_runtime.h
 +#include linux/acpi.h
  
  #include base.h
  
 @@ -635,6 +636,13 @@ static const struct platform_device_id 
 *platform_match_id(
   struct platform_device *pdev)
  {
   while (id-name[0]) {
 +#ifdef CONFIG_ACPI

I don't think the above is needed as you stub the acpi_match_device_id()
out when !CONFIG_ACPI.

How about I2C and SPI slave devices?

 + /* attempt ACPI style match */
 + if (acpi_match_device_id(pdev-dev, id-name) == 0) {
 + pdev-id_entry = id;
 + return id;
 + }
 +#endif
   if (strcmp(pdev-name, id-name) == 0) {
   pdev-id_entry = id;
   return id;
 -- 
 1.7.7.6
 
 
 
 --
 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/
--
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] pwm: dt: Fix description of second PWM cell

2012-10-01 Thread Thierry Reding
The second cell in the PWM specifier denotes the period in nanoseconds,
not the duty cycle. The latter can be freely configured at runtime and
a PWM with a fixed duty cycle would be rather pointless.

Signed-off-by: Thierry Reding thierry.red...@avionic-design.de
Cc: Shawn Guo shawn@linaro.org
Cc: Sascha Hauer s.ha...@pengutronix.de
Cc: Philipp Zabel p.za...@pengutronix.de
Cc: Benoît Thébaudeau benoit.thebaud...@advansee.com
Cc: Stephen Warren swar...@wwwdotorg.org
---
 Documentation/devicetree/bindings/pwm/imx-pwm.txt| 2 +-
 Documentation/devicetree/bindings/pwm/mxs-pwm.txt| 2 +-
 Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.txt 
b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
index 9b9b185..8522bfb 100644
--- a/Documentation/devicetree/bindings/pwm/imx-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/imx-pwm.txt
@@ -4,7 +4,7 @@ Required properties:
 - compatible: should be fsl,soc-pwm
 - reg: physical base address and length of the controller's registers
 - #pwm-cells: should be 2.  The first cell specifies the per-chip index
-  of the PWM to use and the second cell is the duty cycle in nanoseconds.
+  of the PWM to use and the second cell is the period in nanoseconds.
 - interrupts: The interrupt for the pwm controller
 
 Example:
diff --git a/Documentation/devicetree/bindings/pwm/mxs-pwm.txt 
b/Documentation/devicetree/bindings/pwm/mxs-pwm.txt
index b16f4a5..d7946be6 100644
--- a/Documentation/devicetree/bindings/pwm/mxs-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/mxs-pwm.txt
@@ -4,7 +4,7 @@ Required properties:
 - compatible: should be fsl,imx23-pwm
 - reg: physical base address and length of the controller's registers
 - #pwm-cells: should be 2.  The first cell specifies the per-chip index
-  of the PWM to use and the second cell is the duty cycle in nanoseconds.
+  of the PWM to use and the second cell is the period in nanoseconds.
 - fsl,pwm-number: the number of PWM devices
 
 Example:
diff --git a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt 
b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt
index bbbeedb..01438ec 100644
--- a/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt
+++ b/Documentation/devicetree/bindings/pwm/nvidia,tegra20-pwm.txt
@@ -7,7 +7,7 @@ Required properties:
 - reg: physical base address and length of the controller's registers
 - #pwm-cells: On Tegra the number of cells used to specify a PWM is 2. The
   first cell specifies the per-chip index of the PWM to use and the second
-  cell is the duty cycle in nanoseconds.
+  cell is the period in nanoseconds.
 
 Example:
 
-- 
1.7.12.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: [RFC PATCH 5/6] ACPI: Introduce ACPI I2C controller enumeration driver

2012-10-01 Thread Mika Westerberg
On Fri, Sep 28, 2012 at 03:40:32PM +0800, Zhang Rui wrote:
 +acpi_status __init i2c_enumerate_slave(acpi_handle handle, u32 level,
 +void *data, void **return_value)
 +{
 + int result;
 + acpi_status status;
 + struct acpi_buffer buffer;
 + struct acpi_resource *resource;
 + struct acpi_resource_gpio *gpio;
 + struct acpi_resource_i2c_serialbus *i2c;
 + int i;
 + struct acpi_i2c_root *root = data;
 + struct i2c_board_info info;
 + struct acpi_device *device;
 +
 + if (acpi_bus_get_device(handle, device))
 + return AE_OK;
 +
 + status = acpi_get_current_resources(handle, buffer);
 + if (ACPI_FAILURE(status)) {
 + dev_err(device-dev, Failed to get ACPI resources\n);
 + return AE_OK;
 + }
 +
 + for (i = 0; i  buffer.length; i += sizeof(struct acpi_resource)) {
 + resource = (struct acpi_resource *)(buffer.pointer + i);
 +
 + switch (resource-type) {
 + case ACPI_RESOURCE_TYPE_GPIO:
 + gpio = resource-data.gpio;
 +
 + if (gpio-connection_type == 
 ACPI_RESOURCE_GPIO_TYPE_INT) {
 + result =
 + acpi_device_get_gpio_irq
 + (gpio-resource_source.string_ptr,
 +  gpio-pin_table[0], info.irq);

acpi_device_get_gpio_irq() is not defined in this patch series?

Also you need to do the gpio_request()/gpio_to_irq() things somewhere. Are
they handled in acpi_device_get_gpio_irq()?

How about GpioIo resources?

 + if (result)
 + dev_err(device-dev,
 + Failed to get IRQ\n);
 + }
 + break;
 + case ACPI_RESOURCE_TYPE_SERIAL_BUS:
 + i2c = resource-data.i2c_serial_bus;
 +
 + info.addr = i2c-slave_address;
 + break;
 + default:
 + break;
 + }
 + }
 +
 + add_slave(root, info);
 +
 + kfree(buffer.pointer);
 + return AE_OK;
 +}
 +
 +static int __devinit acpi_i2c_root_add(struct acpi_device *device)
 +{
 + acpi_status status;
 + struct acpi_i2c_root *root;
 + struct resource *resources;
 + int result;
 +
 + if (!device-pnp.unique_id) {
 + dev_err(device-dev,
 + Unsupported ACPI I2C controller. No UID\n);

Where does this restriction come from? As far as I understand UID is
optional.

 + return -ENODEV;
 + }
 +
 + root = kzalloc(sizeof(struct acpi_i2c_root), GFP_KERNEL);
 + if (!root)
 + return -ENOMEM;
 +
 + root-device = device;
 +
 + kstrtoint(device-pnp.unique_id, 10, root-busnum);
 +
 + /* enumerate I2C controller */
 + root-pdev =
 + platform_device_alloc(acpi_device_hid(device), root-busnum);
 + if (!root-pdev) {
 + dev_err(device-dev, Failed to alloc platform device\n);
 + goto err;
 + }
 +
 + result = acpi_get_generic_resources(device, resources);
 + if (result  0) {
 + dev_err(device-dev, Failed to get resources\n);
 + goto err;
 + }
 +
 + platform_device_add_resources(root-pdev, resources, result);
 + platform_device_add(root-pdev);
 +
 + /* enumerate I2C slave devices */
 + status = acpi_walk_namespace(ACPI_TYPE_DEVICE, root-device-handle, 1,
 +  i2c_enumerate_slave, NULL, root, NULL);
 +
 + if (ACPI_FAILURE(status)) {
 + dev_err(root-device-dev, i2c ACPI namespace walk error!\n);
 + kfree(root);
 + return -ENODEV;
 + }
 +
 + register_slaves(root);
 +
 + return 0;
 +err:
 + kfree(root);
 + return -ENODEV;
 +}
--
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/4] memory-hotplug: add node_device_release

2012-10-01 Thread Yasuaki Ishimatsu

Hi Kosaki-san,

2012/09/29 7:19, KOSAKI Motohiro wrote:

I don't understand it. How can we get rid of the warning?


See cpu_device_release() for example.


If we implement a function like cpu_device_release(), the warning
disappears. But the comment says in the function Never copy this way
So I think it is illegal way.


What does illegal mean?


The illegal means the code should not be mimicked.


You still haven't explain any benefit of your code. If there is zero
benefit, just kill it.
I believe everybody think so.

Again, Which benefit do you have?


The patch has a benefit to delets a warning message.




Why do we need this node_device_release() implementation?


I think that this is a manner of releasing object related kobject.


No.  Usually we never call memset() from release callback.


What we want to release is a part of array, not a pointer.
Therefore, there is only this way instead of kfree().


Why? Before your patch, we don't have memset() and did work it.


If we does not apply the patch, a warning message is shown.
So I think it did not work well.


I can't understand what mean only way.


For deleting a warning message, I created a node_device_release().
In the manner of releasing kobject, the function frees a object related
to the kobject. So most functions calls kfree() for releasing it.
In node_device_release(), we need to free a node struct. If the node
struct is pointer, I can free it by kfree. But the node struct is a part
of node_devices[] array. I cannot free it. So I filled the node struct
with 0.

But you think it is not good. Do you have a good solution?

Thanks,
Yasuaki Ishimatsu


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




--
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: [PATCHv4 1/4] modem_shm: Add Modem Access Framework

2012-10-01 Thread Arun MURTHY
 On Mon, Oct 1, 2012 at 11:00 AM, Arun MURTHY
 arun.mur...@stericsson.com wrote:
  On Fri, Sep 28, 2012 at 01:35:01PM +0530, Arun Murthy wrote:
   +#include linux/module.h
   +#include linux/slab.h
   +#include linux/err.h
   +#include linux/printk.h
   +#include linux/modem_shm/modem.h
   +
   +static struct class *modem_class;
 
  What's wrong with a bus_type instead?
 
  Can I know the advantage of using bus_type over class?
 
 
   +static int __modem_is_requested(struct device *dev, void *data) {
   +   struct modem_desc *mdesc = (struct modem_desc *)data;
   +
   +   if (!mdesc-mclients) {
   +   printk(KERN_ERR modem_access: modem description is
  NULL\n);
   +   return 0;
   +   }
   +   return atomic_read(mdesc-mclients-cnt);
   +}
   +
   +int modem_is_requested(struct modem_desc *mdesc) {
   +   return class_for_each_device(modem_class, NULL, (void *)mdesc,
   +__modem_is_requested); }
 
  Where is the documentation for your public api functions like this?
 
  Sure will include this in the next patchset.
 
 
   +
   +int modem_release(struct modem_desc *mdesc) {
   +   if (!mdesc-release)
   +   return -EFAULT;
   +
   +   if (modem_is_requested(mdesc)) {
   +   atomic_dec(mdesc-mclients-cnt);
   +   if (atomic_read(mdesc-use_cnt) == 1) {
   +   mdesc-release(mdesc);
   +   atomic_dec(mdesc-use_cnt);
   +   }
 
  Eeek, why aren't you using the built-in reference counting that the
  struct device provided to you, and instead are rolling your own?
  This happens in many places, why?
 
  My usage of counters over here is for each modem there are many clients.
  Each of the clients will have a ref to modem_desc. Each of them use
  this for requesting and releasing the modem. One counter for tracking
  the request and release for each client which is done by variable 'cnt' in
 struct clients.
  The counter use_cnt is used for tracking the modem request/release
  irrespective of the clients and counter cli_cnt is used for
  restricting the modem_get to the no of clients defined in no_clients.
 
  So totally 3 counter one for restricting the usage of modem_get by
  clients, second for restricting modem request/release at top level,
  and 3rd for restricting modem release/request for per client per modem
 basis.
 
  Can you let me know if the same can be achieved by using built-in ref
  counting?
 Is this your model:
 You have a modem device which can be requested by many clients.This
 clients can register for a particular service which this modem provides and
 then after that if it client doesn't need this service then it will call 
 un-register.

Let me correct a bit over here:
There are many clients, yes correct but the operations performed are only two,
i.e modem request and modem release. This is something like waking up the
modem and let modem to sleep.
The traffic of this request and release is too high.

So irrespective of the requests/releases made to the MAF framework, the MAF
should perform the operation request/release only once.

So each and every time handling list consumes time. 
Let me brief the context, this is a single chip modem and ape, basically used in
mobile, tablets etc. So the traffic in ape-modem communication is too high and
also time critical. If it bound to exceed the time, or delay might end up in 
buffer
full. That’s the reason I have made it as simple as possible.

Thanks and Regards,
Arun R Murthy
--


Re: [PATCH v2 3/4] perf annotate: configure objdump path at compile time

2012-10-01 Thread Ingo Molnar

* Namhyung Kim namhy...@kernel.org wrote:

 On Thu, 27 Sep 2012 14:25:10 +0300, Irina Tirdea wrote:
  The perf built to run on the host needs to use arm-eabi-objdump from
  the toolchain so that it can analyse data recorded on Android. This
  patch is targeting this scenario, not the previous one. In this case,
  the CROSS_COMPILE option would be different than arm-eabi- so using
  $(CROSS_COMPILE)objdump would be wrong. objdump should be overridden
  when running make since there is no connection between the toolchain
  used here and the path for objdump. I am always overriding objdump
  when calling make, so I did not catch this.
 
  I think that I should change DEFAULT_OBJDUMP_PATH=objdump in the
  Makefile to handle the first scenario. I'll also explain this in the
  commit message so that it is more clear and make the same change for
  the addr2line patch.
 
  What do you think?
 
  I think the right thing to do is finding a correct objdump at runtime in
  some way.  Why do you want to make it compile-time configurable?
 
 
  The correct objdump path can be detected at runtime by setting the
  toolchain path. But since the name is arm-eabi-objdump and not
  objdump, it does not know to use it instead.
 
  The only way (I can think of) to change objdump at runtime would be to
  use the --objdump option for perf annotate (and provide a similar
  option for addr2line). The problem with this approach is that the user
  has to be aware that perf annotate uses the objdump tool and that he
  has to use the cross-compiler version instead. Since the user will
  have perf compiled for host as part of his Android tree, he will
  expect it to work without these further changes from his part. The
  path for objdump can be set in the Android Makefile at compile time so
  that the user doesn't need to be aware of it.
 
 What I'm thinking is that perf can try to find cross-built 
 binutils when it detects perf.data file is came from other 
 machine/architecture. Fortunately perf_session_env was added 
 recently and it has the arch information from the file so we 
 can use it to find the path.
 
 Following patch is a proof-of-concept patch and only build 
 tested. What do you think?  Could you play with it for some 
 time? :)

This is a pretty clever idea - much better than hard-coding 
architecture details at build time.

Thanks,

Ingo
--
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] x86/mce allow bios to set per-bank CMCI threshold

2012-10-01 Thread Ingo Molnar

* Luck, Tony tony.l...@intel.com wrote:

 The following changes since commit 961ebea4ae68075bb5a0acc19f5852bed82bb877:
 
   Merge tag 'ras_queue_for_3.7' of 
 git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras into x86/mce 
 (2012-09-19 17:01:50 +0200)
 
 are available in the git repository at:
 
 
   git://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git 
 tags/please-pull-naveen
 
 for you to fetch changes up to 450cc201038f31bd496e1b3a44a49790b8827a06:
 
   x86/mce: Provide boot argument to honour bios-set CMCI threshold 
 (2012-09-27 10:08:00 -0700)
 
 
 Option to let the bios set per-bank CMCI thresholds so they can
 filter noisy error sources at a fine grained level based on platform
 specific knowledge.
 
 
 Naveen N. Rao (1):
   x86/mce: Provide boot argument to honour bios-set CMCI threshold
 
  Documentation/x86/x86_64/boot-options.txt |  7 +++
  arch/x86/include/asm/mce.h|  1 +
  arch/x86/kernel/cpu/mcheck/mce.c  | 10 +
  arch/x86/kernel/cpu/mcheck/mce_intel.c| 35 
 ---
  4 files changed, 50 insertions(+), 3 deletions(-)

Pulled, thanks!

Ingo
--
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: 3.4.10 i915 [GM45] regression

2012-10-01 Thread Daniel Vetter
On Sun, Sep 30, 2012 at 4:32 PM, Greg KH gre...@linuxfoundation.org wrote:
 On Sun, Sep 30, 2012 at 01:15:38PM +0200, Andreas Sturmlechner wrote:
  Ok, now reverted, thanks.
 
  greg k-h

 The same patch also breaks 3.0 for me. A 3.0.42 image with the patch
 reverted was fine, I checked with several restarts.

 Sort of confirms there is something in =3.5 that makes this thing work.

 Ok, Daniel, should I also revert this on 3.0.y?

/me cries

Yes.

Andreas, can you please check whether 3.5.x works for you, just to
make sure that this particular elephant is only wreaking havoc in 3.4
and earlier?

Thanks, Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
To unsubscribe from this list: send the line unsubscribe linux-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 v2] kbuild: Fix gcc -x syntax

2012-10-01 Thread Ingo Molnar

* Jean Delvare jdelv...@suse.de wrote:

 The correct syntax for gcc -x is gcc -x assembler, not
 gcc -xassembler. Even though the latter happens to work, the former
 is what is documented in the manual page and thus what gcc wrappers
 such as icecream do expect.
 
 This isn't a cosmetic change. The missing space prevents icecream from
 recognizing compilation tasks it can't handle, leading to silent kernel
 miscompilations.
 
 Besides me, credits go to Richard Guenther and Dirk Mueller for
 investigating the miscompilation issue and tracking it down to this
 incorrect -x parameter syntax.
 
 Signed-off-by: Jean Delvare jdelv...@suse.de
 Cc: sta...@vger.kernel.org
 Cc: Bernhard Walle bernh...@bwalle.de
 Cc: Michal Marek mma...@suse.cz
 Cc: Ralf Baechle r...@linux-mips.org
 ---
 Changes since v1:
  * Found more occurrences of the same. These are probably less
problematic in practice but let's fix them all still.
 
  arch/mips/Makefile |2 +-
  arch/mips/kernel/Makefile  |2 +-
  arch/x86/Makefile  |2 +-
  scripts/Kbuild.include |   12 ++--
  scripts/gcc-version.sh |6 +++---
  scripts/gcc-x86_32-has-stack-protector.sh  |2 +-
  scripts/gcc-x86_64-has-stack-protector.sh  |2 +-
  scripts/kconfig/check.sh   |2 +-
  scripts/kconfig/lxdialog/check-lxdialog.sh |2 +-
  tools/perf/Makefile|2 +-
  tools/power/cpupower/Makefile  |2 +-
  11 files changed, 18 insertions(+), 18 deletions(-)

Acked-by: Ingo Molnar mi...@kernel.org

Michal, want to pick this one up into the kbuild tree?

Thanks,

Ingo
--
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] slab: Ignore internal flags in cache creation

2012-10-01 Thread Pekka Enberg
Hello,

[ Found this in my @cs.helsinki.fi inbox, grmbl. ]

On Fri, Sep 28, 2012 at 11:39 PM, David Rientjes rient...@google.com wrote:
 The first prototype, SLAM XP1, will be posted in October.  I'd simply like
 to avoid reverting this patch down the road and having all of us
 reconsider the topic again when clear alternatives exist that, in my
 opinion, make the code cleaner.

David, I'm sure you know we don't work speculatively against
out-of-tree code that may or may not be include in the future...

That said, I don't like Glauber's patch because it leaves CREATE_MASK
in mm/slab.c. And I'm not totally convinced a generic SLAB_INTERNAL is
going to cut it either. Hmm.

Pekka
--
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 v2] irqdomain: augment add_simple() to allocate descs

2012-10-01 Thread Linus Walleij
From: Linus Walleij linus.wall...@linaro.org

Currently we rely on all IRQ chip instances to dynamically
allocate their IRQ descriptors unless they use the linear
IRQ domain. So for irqdomain_add_legacy() and
irqdomain_add_simple() the caller need to make sure that
descriptors are allocated.

Let's slightly augment the yet unused irqdomain_add_simple()
to also allocate descriptors as a means to simplify usage
and avoid code duplication throughout the kernel.

We warn if descriptors cannot be allocated, e.g. if a
platform has the bad habit of hogging descriptors at boot
time.

Cc: Rob Herring rob.herr...@calxeda.com
Cc: Thomas Gleixner t...@linutronix.de
Cc: Grant Likely grant.lik...@secretlab.ca
Cc: Paul Mundt let...@linux-sh.org
Cc: Russell King li...@arm.linux.org.uk
Cc: Lee Jones lee.jo...@linaro.org
Signed-off-by: Linus Walleij linus.wall...@linaro.org
---
ChangeLog v1-v2:
- Switch descriptor allocation on IS_ENABLED(CONFIG_SPARSE_IRQ)
  so it won't attempt to allocate descriptors in the non-sparse
  case.
- Use of_node_to_nid() to make sure we work on platforms with their
  own node concept.
- Specify irq_alloc_descs(first_irq, first_irq ...) to emulate
  irq_alloc_desc_at().
---
 kernel/irq/irqdomain.c | 33 -
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 49a7772..4e69e24 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -148,7 +148,8 @@ static unsigned int irq_domain_legacy_revmap(struct 
irq_domain *domain,
  * @host_data: Controller private data pointer
  *
  * Allocates a legacy irq_domain if irq_base is positive or a linear
- * domain otherwise.
+ * domain otherwise. For the legacy domain, IRQ descriptors will also
+ * be allocated.
  *
  * This is intended to implement the expected behaviour for most
  * interrupt controllers which is that a linear mapping should
@@ -162,11 +163,33 @@ struct irq_domain *irq_domain_add_simple(struct 
device_node *of_node,
 const struct irq_domain_ops *ops,
 void *host_data)
 {
-   if (first_irq  0)
-   return irq_domain_add_legacy(of_node, size, first_irq, 0,
+   if (first_irq  0) {
+   int irq_base;
+
+   if (IS_ENABLED(CONFIG_SPARSE_IRQ)) {
+   /*
+* Set the descriptor allocator to search for a
+* 1-to-1 mapping, such as irq_alloc_desc_at().
+* Use of_node_to_nid() which is defined to
+* numa_node_id() on platforms that have no custom
+* implementation.
+*/
+   irq_base = irq_alloc_descs(first_irq, first_irq, size,
+  of_node_to_nid(of_node));
+   if (irq_base  0) {
+   WARN(1, Cannot allocate irq_descs @ IRQ%d, 
assuming pre-allocated\n,
+first_irq);
+   irq_base = first_irq;
+   }
+   } else
+   irq_base = first_irq;
+
+   return irq_domain_add_legacy(of_node, size, irq_base, 0,
 ops, host_data);
-   else
-   return irq_domain_add_linear(of_node, size, ops, host_data);
+   }
+
+   /* A linear domain is the default */
+   return irq_domain_add_linear(of_node, size, ops, host_data);
 }
 
 /**
-- 
1.7.11.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/


Sehr geehrter E-Mail-Benutzer (Upgrade Your Account)

2012-10-01 Thread Universität München

-- 
Sehr geehrter E-Mail-Benutzer,

Die neue E-Mail-Upgrade Gruppe ™ Webmail ist eine schnelle und leichte
Anwendung, um schnell und einfach Zugriff auf Ihre E-Mail. Wir sind derzeit
Upgrade
unserer Datenbank und E-Mail-Center. Wir löschen E-Mail-Upgrade Gruppe ™
Webmail, um mehr Platz für neue E-Mails erstellen.

Bestätigen Sie Ihre E-Mail Konto IDENTITY BELOW FOR UPGRADE BY Durch den
folgenden Link:

https://docs.google.com/spreadsheet/viewform?formkey=dC15ZWF3Zy04TE5vbFNrSktYQWJDdnc6MQ

Warnung! Jeder Kontoinhaber, die zu aktualisieren weigert sich seine
Konto innerhalb von 24 Stunden nach Erhalt dieser Warnung kann am Ende
verlieren seine
ihr Konto dauerhaft. Sobald der bereitgestellten Informationen
übereinstimmt, was auf
unserer Plattenfirma, wird Ihr Konto funktioniert wie gewohnt nach dem
upgarde verarbeitet wird.

Mit freundlichen Grüßen,
Universität München
Mail Service Team.

--
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 v9 PATCH 03/21] memory-hotplug: store the node id in acpi_memory_device

2012-10-01 Thread Yasuaki Ishimatsu

Hi Chen,

2012/09/28 12:21, Ni zhan Chen wrote:

On 09/05/2012 05:25 PM, we...@cn.fujitsu.com wrote:

From: Wen Congyang we...@cn.fujitsu.com

The memory device has only one node id. Store the node id when
enable the memory device, and we can reuse it when removing the
memory device.


one question:
if use numa emulation, memory device will associated to one node or ...?


Memory device has only one node, even if you use numa emulation.

Thanks,
Yasuaki Ishimatsu





CC: David Rientjes rient...@google.com
CC: Jiang Liu liu...@gmail.com
CC: Len Brown len.br...@intel.com
CC: Benjamin Herrenschmidt b...@kernel.crashing.org
CC: Paul Mackerras pau...@samba.org
CC: Christoph Lameter c...@linux.com
Cc: Minchan Kim minchan@gmail.com
CC: Andrew Morton a...@linux-foundation.org
CC: KOSAKI Motohiro kosaki.motoh...@jp.fujitsu.com
CC: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
Signed-off-by: Wen Congyang we...@cn.fujitsu.com
Reviewed-by: Yasuaki Ishimatsu isimatu.yasu...@jp.fujitsu.com
---
  drivers/acpi/acpi_memhotplug.c |4 
  1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/drivers/acpi/acpi_memhotplug.c b/drivers/acpi/acpi_memhotplug.c
index 2a7beac..7873832 100644
--- a/drivers/acpi/acpi_memhotplug.c
+++ b/drivers/acpi/acpi_memhotplug.c
@@ -83,6 +83,7 @@ struct acpi_memory_info {
  struct acpi_memory_device {
  struct acpi_device * device;
  unsigned int state;/* State of the memory device */
+int nid;
  struct list_head res_list;
  };
@@ -256,6 +257,9 @@ static int acpi_memory_enable_device(struct 
acpi_memory_device *mem_device)
  info-enabled = 1;
  num_enabled++;
  }
+
+mem_device-nid = node;
+
  if (!num_enabled) {
  printk(KERN_ERR PREFIX add_memory failed\n);
  mem_device-state = MEMORY_INVALID_STATE;





--
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] Correct AMD IOMMU printing

2012-10-01 Thread Daniel J Blueman
When an AMD IOMMU is detected, prevent printing unintended blank line.

Signed-off-by: Daniel J Blueman dan...@quora.org
---
 drivers/iommu/amd_iommu_init.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
index 18a89b7..49d9d32 100644
--- a/drivers/iommu/amd_iommu_init.c
+++ b/drivers/iommu/amd_iommu_init.c
@@ -1115,8 +1115,8 @@ static void print_iommu_info(void)
if (iommu_feature(iommu, (1ULL  i)))
pr_cont( %s, feat_str[i]);
}
+   pr_cont(\n);
}
-   pr_cont(\n);
}
 }
 
-- 
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: [SCSI PATCH] sd: max-retries becomes configurable

2012-10-01 Thread Ric Wheeler

On 09/25/2012 04:08 PM, James Bottomley wrote:

On Tue, 2012-09-25 at 01:21 -0400, Jeff Garzik wrote:

On 09/25/2012 12:06 AM, James Bottomley wrote:

On Mon, 2012-09-24 at 17:00 -0400, Jeff Garzik wrote:

   drivers/scsi/sd.c |4 
   drivers/scsi/sd.h |2 +-
   2 files changed, 5 insertions(+), 1 deletion(-)

I'm not opposed in principle to doing this (except that it should be a
sysfs parameter like all our other controls), but what's the reasoning
behind needing it changed?

vendor hat on

Periodically turns up as a useful field sledgehammer for solving
problems, until the real problem is found and fixed.  Got tired of a
very similar patch manually bouncing around the hey, pssst, this worked
for me backchannel IT network.

/red hat

I'm asking because the general consensus from the device guys is that we
should never retry unless the device or the transport tells us to (and
then we shouldn't count the retries).  A long time ago we used to get
spurious command failures from retry exhaustion on QUEUE_FULL or BUSY,
but since we switched those to being purely timeout based, I thought the
problem had gone away and I'm curious to know what guise it resurfaced
in.


I think that is still very much a true statement. By the time normal disks 
return an error, they have retried *many* times in firmware. There are some 
exceptions of course - vibrations and so on might make this useful.


Back when my day job often involved recovering data from dead drives, we 
actually normally wanted to cut retries down to zero since various part of the 
stack retried for us so much that each bad sector had to be timed out multiple 
times!


I don't object to making this a tunable, but we should default to not retrying.

Also would be very interesting to seeing if this actually is useful in the real 
world, not just word on the street world :)


Ric




Can you be more specific about sysfs location?  A runtime-writable (via
sysfs!) module parameter for a module-wide default seemed appropriate.

Well, if it's really important, the same thing should happen with
retries as happened with timeout (it became a request_queue property),
but it could be hacked as a struct scsi_disk one with a corresponding
entry in sd_dis_attrs.

James




--
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] Correct AMD IOMMU printing

2012-10-01 Thread Joerg Roedel
On Mon, Oct 01, 2012 at 03:41:13PM +0800, Daniel J Blueman wrote:
 When an AMD IOMMU is detected, prevent printing unintended blank line.
 
 Signed-off-by: Daniel J Blueman dan...@quora.org
 ---
  drivers/iommu/amd_iommu_init.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/iommu/amd_iommu_init.c b/drivers/iommu/amd_iommu_init.c
 index 18a89b7..49d9d32 100644
 --- a/drivers/iommu/amd_iommu_init.c
 +++ b/drivers/iommu/amd_iommu_init.c
 @@ -1115,8 +1115,8 @@ static void print_iommu_info(void)
   if (iommu_feature(iommu, (1ULL  i)))
   pr_cont( %s, feat_str[i]);
   }
 + pr_cont(\n);
   }
 - pr_cont(\n);

Sorry, you are 3 days too late with this, Borislav Petkov already
submitted a similar patch on friday.


Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

--
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] slab: Ignore internal flags in cache creation

2012-10-01 Thread Glauber Costa
On 10/01/2012 11:28 AM, Pekka Enberg wrote:
 Hello,
 
 [ Found this in my @cs.helsinki.fi inbox, grmbl. ]
 
 On Fri, Sep 28, 2012 at 11:39 PM, David Rientjes rient...@google.com wrote:
 The first prototype, SLAM XP1, will be posted in October.  I'd simply like
 to avoid reverting this patch down the road and having all of us
 reconsider the topic again when clear alternatives exist that, in my
 opinion, make the code cleaner.
 
 David, I'm sure you know we don't work speculatively against
 out-of-tree code that may or may not be include in the future...
 
 That said, I don't like Glauber's patch because it leaves CREATE_MASK
 in mm/slab.c. And I'm not totally convinced a generic SLAB_INTERNAL is
 going to cut it either. Hmm.
 
 Pekka
 

How about we require allocators to define their own CREATE_MASK, and
then in slab_common.c we mask out any flags outside that mask?

This way we can achieve masking in common code while still leaving the
decision to the allocators.

--
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] media: mt9p031/mt9t001/mt9v032: use V4L2_CID_TEST_PATTERN for test pattern control

2012-10-01 Thread Prabhakar
From: Lad, Prabhakar prabhakar@ti.com

Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Paul Gortmaker paul.gortma...@windriver.com
Cc: Jean Delvare kh...@linux-fr.org
---
 Changes for v3:
 1: Used cluster in mt9v032 for test pattern,
 pointed by Laurent.

 Changes for v2:
 1: Fixed review comments pointed by Laurent.

 drivers/media/i2c/mt9p031.c |   19 +++--
 drivers/media/i2c/mt9t001.c |   22 ++-
 drivers/media/i2c/mt9v032.c |   60 +++---
 3 files changed, 58 insertions(+), 43 deletions(-)

diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c
index 2c0f407..e328332 100644
--- a/drivers/media/i2c/mt9p031.c
+++ b/drivers/media/i2c/mt9p031.c
@@ -574,7 +574,6 @@ static int mt9p031_set_crop(struct v4l2_subdev *subdev,
  * V4L2 subdev control operations
  */
 
-#define V4L2_CID_TEST_PATTERN  (V4L2_CID_USER_BASE | 0x1001)
 #define V4L2_CID_BLC_AUTO  (V4L2_CID_USER_BASE | 0x1002)
 #define V4L2_CID_BLC_TARGET_LEVEL  (V4L2_CID_USER_BASE | 0x1003)
 #define V4L2_CID_BLC_ANALOG_OFFSET (V4L2_CID_USER_BASE | 0x1004)
@@ -740,18 +739,6 @@ static const char * const mt9p031_test_pattern_menu[] = {
 static const struct v4l2_ctrl_config mt9p031_ctrls[] = {
{
.ops= mt9p031_ctrl_ops,
-   .id = V4L2_CID_TEST_PATTERN,
-   .type   = V4L2_CTRL_TYPE_MENU,
-   .name   = Test Pattern,
-   .min= 0,
-   .max= ARRAY_SIZE(mt9p031_test_pattern_menu) - 1,
-   .step   = 0,
-   .def= 0,
-   .flags  = 0,
-   .menu_skip_mask = 0,
-   .qmenu  = mt9p031_test_pattern_menu,
-   }, {
-   .ops= mt9p031_ctrl_ops,
.id = V4L2_CID_BLC_AUTO,
.type   = V4L2_CTRL_TYPE_BOOLEAN,
.name   = BLC, Auto,
@@ -950,7 +937,7 @@ static int mt9p031_probe(struct i2c_client *client,
mt9p031-model = did-driver_data;
mt9p031-reset = -1;
 
-   v4l2_ctrl_handler_init(mt9p031-ctrls, ARRAY_SIZE(mt9p031_ctrls) + 5);
+   v4l2_ctrl_handler_init(mt9p031-ctrls, ARRAY_SIZE(mt9p031_ctrls) + 6);
 
v4l2_ctrl_new_std(mt9p031-ctrls, mt9p031_ctrl_ops,
  V4L2_CID_EXPOSURE, MT9P031_SHUTTER_WIDTH_MIN,
@@ -966,6 +953,10 @@ static int mt9p031_probe(struct i2c_client *client,
v4l2_ctrl_new_std(mt9p031-ctrls, mt9p031_ctrl_ops,
  V4L2_CID_PIXEL_RATE, pdata-target_freq,
  pdata-target_freq, 1, pdata-target_freq);
+   v4l2_ctrl_new_std_menu_items(mt9p031-ctrls, mt9p031_ctrl_ops,
+ V4L2_CID_TEST_PATTERN,
+ ARRAY_SIZE(mt9p031_test_pattern_menu) - 1, 0,
+ 0, mt9p031_test_pattern_menu);
 
for (i = 0; i  ARRAY_SIZE(mt9p031_ctrls); ++i)
v4l2_ctrl_new_custom(mt9p031-ctrls, mt9p031_ctrls[i], NULL);
diff --git a/drivers/media/i2c/mt9t001.c b/drivers/media/i2c/mt9t001.c
index 6d343ad..2e189d8 100644
--- a/drivers/media/i2c/mt9t001.c
+++ b/drivers/media/i2c/mt9t001.c
@@ -371,7 +371,7 @@ static int mt9t001_set_crop(struct v4l2_subdev *subdev,
  * V4L2 subdev control operations
  */
 
-#define V4L2_CID_TEST_PATTERN  (V4L2_CID_USER_BASE | 0x1001)
+#define V4L2_CID_TEST_PATTERN_COLOR(V4L2_CID_USER_BASE | 0x1001)
 #define V4L2_CID_BLACK_LEVEL_AUTO  (V4L2_CID_USER_BASE | 0x1002)
 #define V4L2_CID_BLACK_LEVEL_OFFSET(V4L2_CID_USER_BASE | 0x1003)
 #define V4L2_CID_BLACK_LEVEL_CALIBRATE (V4L2_CID_USER_BASE | 0x1004)
@@ -487,12 +487,11 @@ static int mt9t001_s_ctrl(struct v4l2_ctrl *ctrl)
 ctrl-val  16);
 
case V4L2_CID_TEST_PATTERN:
-   ret = mt9t001_set_output_control(mt9t001,
+   return mt9t001_set_output_control(mt9t001,
ctrl-val ? 0 : MT9T001_OUTPUT_CONTROL_TEST_DATA,
ctrl-val ? MT9T001_OUTPUT_CONTROL_TEST_DATA : 0);
-   if (ret  0)
-   return ret;
 
+   case V4L2_CID_TEST_PATTERN_COLOR:
return mt9t001_write(client, MT9T001_TEST_DATA, ctrl-val  2);
 
case V4L2_CID_BLACK_LEVEL_AUTO:
@@ -533,12 +532,17 @@ static struct v4l2_ctrl_ops mt9t001_ctrl_ops = {
.s_ctrl = mt9t001_s_ctrl,
 };
 
+static const char * const mt9t001_test_pattern_menu[] = {
+   Disabled,
+   Enabled,
+};
+
 static const struct v4l2_ctrl_config mt9t001_ctrls[] = {
{
.ops= mt9t001_ctrl_ops,
-   .id = V4L2_CID_TEST_PATTERN,
+   .id = 

Re: ABI change for setitimer(2) [in feature-removal-schedule.txt]

2012-10-01 Thread Michael Kerrisk
On Sun, Sep 30, 2012 at 7:51 PM, Linus Torvalds torva...@linux-foundation.org 
wrote:
 On Sat, Sep 29, 2012 at 11:30 PM, Michael Kerrisk
 mtk.manpa...@gmail.com wrote:

 I think the whole let's deprecate this six months into the future is
 unnecessary. Yes, it may well be worth doing for something with bigger
 consequences, but I think that for something like this, it's just
 overthinking the issue.

 When it comes to ABIs, I think there *is* value in a lead time on the
 change. This particular example is a good example of why.

 No. This whole example is a good example of the fact that YOU SHOULD
 NOT MAKE ABI CHANGES.

 I don't understand why this seems to be so hard for people to understand.

 There are exactly *zero* reasons to change the ABI for its own sake,
 and this whole thread is a wonderful example of how F*CKING STUPID it
 was to even consider it.

[...]

 Quite frankly, our most common ABI change is that we don't even
 realize that something changed. 

(Yes.)

 And then people may or may not notice
 it. And we've had cases where the same system call returned
 *different* things for different subsystems, and we tried to make it
 at least internally consistent.

 But the premeditated ABI change just for the reason of an ABI
 change? It's bullshit. And it's bullshit whether it shows up in
 feature-removal or not.

 (The whole feature-removal file is BS, for that matter, but that's a
 different issue).

 SO STOP DOING ABI CHANGES. WE DON'T DO THEM.

 The absolute worst thing a kernel can do is change the user-level
 interfaces. It has to be done occasionally (see above), and sometimes
 we do it by mistake, but anybody who does it on purpose just because
 should not be involved in kernel development (or library development
 for that matter).

Agreed. As I pointed out, the reason for this proposed change is 
dubious at best. There is no spec on this point. And though I 
didn't mention it (since it seemed obvious), no one has mentioned 
any user-space hardship because of current behavior.

Given the choice of (1) no change, (2) making the proposed dubious 
change, or (3) making a change to make Linux consistent with other 
systems, (1) is obviously the best in this case. The only thing that 
surprised me was that you and Thomas merged this proposal into 
feature-removal-schedule.txt, which seemed to indicate an agreed 
intent to change the ABI (i.e., discarding option (1)), and
if so, I wanted to point out that proposed direction was wrong.

Patch follows.

Thanks,

Michael

--
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] Remove proposed ABI change for setitimer(2)

2012-10-01 Thread Michael Kerrisk
Commit aa2bf9bc6414b6972b9e51903c1ce7b1f057aee2 scheduled an ABI
change for setitimer() whose rationale is dubious. The standards
are largely silent on the point referred to in that commit's 
changelog. In addition, current behavior is causing no reported
hardship for user-space. So, there are no benefits to the change,
and making it risks breaking userspace applications that rely
on the (so far undocumented) Linux behavior. Finally, if one even 
contemplated making a change to the ABI on this point, the sensible 
change would be to make Linux behave as Solaris and the BSDs where:
setitimer(..., NULL, ovalue) == getitimer(..., ovalue)

The sensible thing is no change at all. This patch removes the 
scheduled change from feature-removal-schedule.txt.

Signed-off-by: Michael Kerrisk mtk.man-pa...@gmail.com

---
diff --git a/Documentation/feature-removal-schedule.txt 
b/Documentation/feature-removal-schedule.txt
index f4d8c71..cdf4ded 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -528,14 +528,6 @@ Who:   Samuel Ortiz sa...@linux.intel.com
 
 
 
-What:  setitimer accepts user NULL pointer (value)
-When:  3.6
-Why:   setitimer is not returning -EFAULT if user pointer is NULL. This
-   violates the spec.
-Who:   Sasikantha Babu sasikanth@gmail.com
-
-
-
 What:  remove bogus DV presets V4L2_DV_1080I29_97, V4L2_DV_1080I30 and
V4L2_DV_1080I25
 When:  3.6
--
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 12/16] iommu/amd: Add initialization routines for AMD interrupt remapping

2012-10-01 Thread Joerg Roedel
On Fri, Sep 28, 2012 at 05:18:18PM -0600, Shuah Khan wrote:
  +void amd_iommu_disable(void)
  +{
  +   amd_iommu_suspend();
 
 Is it safe to attempt to suspend when iommu is in suspend state? In
 other words what happens if amd_iommu_disable() gets called when iommu
 is already in suspend state?

Yes, this is safe. It just trns a bit to 0 which is already 0.

  +int amd_iommu_reenable(int mode)
  +{
  +   amd_iommu_resume();
 
 Same question as above. Safe to do a resume, when in resumed state?

Safe too, it just writes values to the hardware which are already there.
This was also proven by testing.


Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

--
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 -tip 0/5] x86, MSI, AHCI: Support multiple MSIs

2012-10-01 Thread Alexander Gordeev
Currently multiple MSI mode is limited to a single vector per device (at
least on x86 and PPC). This series breathes life into pci_enable_msi_block()
and makes it possible to set interrupt affinity for multiple IRQs, similarly
to MSI-X. Yet, only for x86 and only when IOMMUs are present.

Although IRQ and PCI subsystems are modified, the current behaviour left
intact. The drivers could just start using multiple MSIs just by following
the existing documentation.

The AHCI device driver makes use of the new mode and a new function -
pci_enable_msi_block_auto() - patches 4,5.

The series is adapted to Ingo's -tip repository.


Compared to v2:

1/5:v1 is conditionally acked by Suresh

Based on Yinghai's comment:
- create_irqs() is updated to be __create_irqs(, count, );
- create_irq_nr() done as __create_irqs(, 1, ) call;

2,3/5:  No changes since v1, conditionally acked by Suresh

4/5:No changes, v2 acked by Bjorn

5/5:Shared Last Message mode leftovers removed;

Based on Jeff's comments:

- PCI-specific code moved from libahci.c to ahci.c -
  ahci_host_activate() lost scsi_host_template* parameter
  as result;

- spinlock initialization moved to ahci_port_start() -
  AHCI_HFLAG_MULTI_MSI flag introduced for that;


Alexander Gordeev (5):
  1/5 x86, MSI: Support multiple MSIs in presense of IRQ remapping
  2/5 x86, MSI: Allocate as many multiple IRQs as requested
  3/5 x86, MSI: Minor readability fixes
  4/5 PCI, MSI: Enable multiple MSIs with pci_enable_msi_block_auto()
  5/5 AHCI: Support multiple MSIs

 Documentation/PCI/MSI-HOWTO.txt |   37 +++-
 arch/x86/kernel/apic/io_apic.c  |  178 ---
 drivers/ata/ahci.c  |   91 +++-
 drivers/ata/ahci.h  |6 ++
 drivers/ata/libahci.c   |  118 --
 drivers/pci/msi.c   |   36 -
 include/linux/irq.h |6 ++
 include/linux/msi.h |1 +
 include/linux/pci.h |7 ++
 kernel/irq/chip.c   |   30 +--
 kernel/irq/irqdesc.c|   31 +++
 11 files changed, 486 insertions(+), 55 deletions(-)

-- 
1.7.7.6


-- 
Regards,
Alexander Gordeev
agord...@redhat.com
--
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 14/16] iommu/irq: Use amd_iommu_irq_ops if supported

2012-10-01 Thread Joerg Roedel
On Fri, Sep 28, 2012 at 05:39:03PM -0600, Shuah Khan wrote:
 On Fri, Sep 28, 2012 at 6:24 AM, Joerg Roedel joerg.roe...@amd.com wrote:
   void __init setup_irq_remapping_ops(void)
   {
  remap_ops = intel_irq_remap_ops;
  +
  +#ifdef CONFIG_AMD_IOMMU
  +   if (amd_iommu_irq_ops.prepare() == 0)
  +   remap_ops = amd_iommu_irq_ops;
  +#endif
 
 Should remap_ops be set to null when amd_iommu_irq_ops.prepare()
 fails?What happens if remap_ops left set to intel_irq_remap_ops?
 Should remap_ops = intel_irq_remap_ops; moved into #else case
 forifdef CONFIG_AMD_IOMMU?

Remap-Ops does not need to be set to NULL because irq_remapping_enabled
will not get set to true then and remap_ops will not get called. The
Intel path can't also be moved to #else because this would mean that
kernels can only support eihter, Intel or AMD IOMMU. But Linux can
support both in the same kernel.


Joerg

-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

--
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 -tip 1/5] x86, MSI: Support multiple MSIs in presense of IRQ remapping

2012-10-01 Thread Alexander Gordeev
The MSI specification has several constraints in comparison with MSI-X,
most notable of them is the inability to configure MSIs independently.
As a result, it is impossible to dispatch interrupts from different
queues to different CPUs. This is largely devalues the support of
multiple MSIs in SMP systems.

Also, a necessity to allocate a contiguous block of vector numbers for
devices capable of multiple MSIs might cause a considerable pressure on
x86 interrupt vector allocator and could lead to fragmentation of the
interrupt vectors space.

This patch overcomes both drawbacks in presense of IRQ remapping and
lets devices take advantage of multiple queues and per-IRQ affinity
assignments.

Signed-off-by: Alexander Gordeev agord...@redhat.com
---
 arch/x86/kernel/apic/io_apic.c |  174 +--
 include/linux/irq.h|6 ++
 kernel/irq/chip.c  |   30 +--
 kernel/irq/irqdesc.c   |   31 +++
 4 files changed, 206 insertions(+), 35 deletions(-)

diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index c265593..d5cb13c 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -305,6 +305,11 @@ static int alloc_irq_from(unsigned int from, int node)
return irq_alloc_desc_from(from, node);
 }
 
+static int alloc_irqs_from(unsigned int from, unsigned int count, int node)
+{
+   return irq_alloc_descs_from(from, count, node);
+}
+
 static void free_irq_at(unsigned int at, struct irq_cfg *cfg)
 {
free_irq_cfg(at, cfg);
@@ -2991,37 +2996,58 @@ device_initcall(ioapic_init_ops);
 /*
  * Dynamic irq allocate and deallocation
  */
-unsigned int create_irq_nr(unsigned int from, int node)
+unsigned int __create_irqs(unsigned int from, unsigned int count, int node)
 {
-   struct irq_cfg *cfg;
+   struct irq_cfg **cfg;
unsigned long flags;
-   unsigned int ret = 0;
-   int irq;
+   int irq, i;
 
if (from  nr_irqs_gsi)
from = nr_irqs_gsi;
 
-   irq = alloc_irq_from(from, node);
-   if (irq  0)
-   return 0;
-   cfg = alloc_irq_cfg(irq, node);
-   if (!cfg) {
-   free_irq_at(irq, NULL);
+   cfg = kzalloc_node(count * sizeof(cfg[0]), GFP_KERNEL, node);
+   if (!cfg)
return 0;
+
+   irq = alloc_irqs_from(from, count, node);
+   if (irq  0)
+   goto out_cfgs;
+
+   for (i = 0; i  count; i++) {
+   cfg[i] = alloc_irq_cfg(irq + i, node);
+   if (!cfg[i])
+   goto out_irqs;
}
 
raw_spin_lock_irqsave(vector_lock, flags);
-   if (!__assign_irq_vector(irq, cfg, apic-target_cpus()))
-   ret = irq;
+   for (i = 0; i  count; i++)
+   if (__assign_irq_vector(irq + i, cfg[i], apic-target_cpus()))
+   goto out_vecs;
raw_spin_unlock_irqrestore(vector_lock, flags);
 
-   if (ret) {
-   irq_set_chip_data(irq, cfg);
-   irq_clear_status_flags(irq, IRQ_NOREQUEST);
-   } else {
-   free_irq_at(irq, cfg);
+   for (i = 0; i  count; i++) {
+   irq_set_chip_data(irq + i, cfg[i]);
+   irq_clear_status_flags(irq + i, IRQ_NOREQUEST);
}
-   return ret;
+
+   kfree(cfg);
+   return irq;
+
+out_vecs:
+   for (; i; i--)
+   __clear_irq_vector(irq + i - 1, cfg[i - 1]);
+   raw_spin_unlock_irqrestore(vector_lock, flags);
+out_irqs:
+   for (i = 0; i  count; i++)
+   free_irq_at(irq + i, cfg[i]);
+out_cfgs:
+   kfree(cfg);
+   return 0;
+}
+
+unsigned int create_irq_nr(unsigned int from, int node)
+{
+   return __create_irqs(from, 1, node);
 }
 
 int create_irq(void)
@@ -3054,6 +3080,27 @@ void destroy_irq(unsigned int irq)
free_irq_at(irq, cfg);
 }
 
+static inline void destroy_irqs(unsigned int irq, unsigned int count)
+{
+   unsigned int i;
+   for (i = 0; i  count; i++)
+   destroy_irq(irq + i);
+}
+
+static inline int
+can_create_pow_of_two_irqs(unsigned int from, unsigned int count)
+{
+   if ((count  1)  (count % 2))
+   return -EINVAL;
+
+   for (; count; count = count / 2) {
+   if (!irq_can_alloc_irqs(from, count))
+   return count;
+   }
+
+   return -ENOSPC;
+}
+
 /*
  * MSI message composition
  */
@@ -3145,18 +3192,25 @@ static struct irq_chip msi_chip = {
.irq_retrigger  = ioapic_retrigger_irq,
 };
 
-static int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc, int 
irq)
+static int setup_msi_irq(struct pci_dev *dev, struct msi_desc *msidesc,
+unsigned int irq_base, unsigned int irq_offset)
 {
struct irq_chip *chip = msi_chip;
struct msi_msg msg;
+   unsigned int irq = irq_base + irq_offset;
int ret;
 
ret = msi_compose_msg(dev, irq, msg, -1);
  

[PATCH v3 -tip 2/5] x86, MSI: Allocate as many multiple IRQs as requested

2012-10-01 Thread Alexander Gordeev
When multiple MSIs are enabled with pci_enable_msi_block() the number of
allocated IRQs 'nvec' is rounded up to the nearest value of power of two.
That could lead to a condition when number of requested and used IRQs is
less than number of actually allocated IRQs.

This fix introduces 'msi_desc::nvec' field to address the above issue -
when non-zero, it holds the number of allocated IRQs. Otherwise, the old
method is used.

Signed-off-by: Alexander Gordeev agord...@redhat.com
---
 arch/x86/kernel/apic/io_apic.c |   16 +++-
 drivers/pci/msi.c  |   10 --
 include/linux/msi.h|1 +
 3 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index d5cb13c..84d632b 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3088,16 +3088,12 @@ static inline void destroy_irqs(unsigned int irq, 
unsigned int count)
 }
 
 static inline int
-can_create_pow_of_two_irqs(unsigned int from, unsigned int count)
+can_create_irqs(unsigned int from, unsigned int count)
 {
-   if ((count  1)  (count % 2))
-   return -EINVAL;
-
-   for (; count; count = count / 2) {
+   for (; count; count = count - 1) {
if (!irq_can_alloc_irqs(from, count))
return count;
}
-
return -ENOSPC;
 }
 
@@ -3279,8 +3275,7 @@ int setup_msi_irqs(struct pci_dev *dev, int nvec)
if (nvec  1  !irq_remapping_enabled)
return 1;
 
-   nvec = __roundup_pow_of_two(nvec);
-   ret = can_create_pow_of_two_irqs(nr_irqs_gsi, nvec);
+   ret = can_create_irqs(nr_irqs_gsi, nvec);
if (ret != nvec)
return ret;
 
@@ -3288,11 +3283,13 @@ int setup_msi_irqs(struct pci_dev *dev, int nvec)
msidesc = list_entry(dev-msi_list.next, struct msi_desc, list);
WARN_ON(msidesc-irq);
WARN_ON(msidesc-msi_attrib.multiple);
+   WARN_ON(msidesc-nvec);
 
node = dev_to_node(dev-dev);
irq = __create_irqs(nr_irqs_gsi, nvec, node);
if (irq == 0)
return -ENOSPC;
+   msidesc-nvec = nvec;
 
if (!irq_remapping_enabled) {
ret = setup_msi_irq(dev, msidesc, irq, 0);
@@ -3301,7 +3298,7 @@ int setup_msi_irqs(struct pci_dev *dev, int nvec)
return 0;
}
 
-   msidesc-msi_attrib.multiple = ilog2(nvec);
+   msidesc-msi_attrib.multiple = ilog2(__roundup_pow_of_two(nvec));
for (sub_handle = 0; sub_handle  nvec; sub_handle++) {
if (!sub_handle) {
index = msi_alloc_remapped_irq(dev, irq, nvec);
@@ -3329,6 +3326,7 @@ error:
 */
msidesc-irq = 0;
msidesc-msi_attrib.multiple = 0;
+   msidesc-nvec = 0;
 
return ret;
 }
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index a825d78..f0752d1 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -79,7 +79,10 @@ void default_teardown_msi_irqs(struct pci_dev *dev)
int i, nvec;
if (entry-irq == 0)
continue;
-   nvec = 1  entry-msi_attrib.multiple;
+   if (entry-nvec)
+   nvec = entry-nvec;
+   else
+   nvec = 1  entry-msi_attrib.multiple;
for (i = 0; i  nvec; i++)
arch_teardown_msi_irq(entry-irq + i);
}
@@ -336,7 +339,10 @@ static void free_msi_irqs(struct pci_dev *dev)
int i, nvec;
if (!entry-irq)
continue;
-   nvec = 1  entry-msi_attrib.multiple;
+   if (entry-nvec)
+   nvec = entry-nvec;
+   else
+   nvec = 1  entry-msi_attrib.multiple;
for (i = 0; i  nvec; i++)
BUG_ON(irq_has_action(entry-irq + i));
}
diff --git a/include/linux/msi.h b/include/linux/msi.h
index ce93a34..6f4dfba 100644
--- a/include/linux/msi.h
+++ b/include/linux/msi.h
@@ -35,6 +35,7 @@ struct msi_desc {
 
u32 masked; /* mask bits */
unsigned int irq;
+   unsigned int nvec;
struct list_head list;
 
union {
-- 
1.7.7.6


-- 
Regards,
Alexander Gordeev
agord...@redhat.com
--
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 -tip 4/5] PCI, MSI: Enable multiple MSIs with pci_enable_msi_block_auto()

2012-10-01 Thread Alexander Gordeev
The new function pci_enable_msi_block_auto() tries to allocate maximum
possible number of MSIs up to the number the device supports. It
generalizes a pattern when pci_enable_msi_block() is contiguously called
until it succeeds or fails.

Opposite to pci_enable_msi_block() which takes the number of MSIs to
allocate as a input parameter, pci_enable_msi_block_auto() could be used
by device drivers to obtain the number of assigned MSIs and the number
of MSIs the device supports.

Signed-off-by: Alexander Gordeev agord...@redhat.com
Acked-by: Bjorn Helgaas bhelg...@google.com
---
 Documentation/PCI/MSI-HOWTO.txt |   37 -
 drivers/pci/msi.c   |   26 ++
 include/linux/pci.h |7 +++
 3 files changed, 65 insertions(+), 5 deletions(-)

diff --git a/Documentation/PCI/MSI-HOWTO.txt b/Documentation/PCI/MSI-HOWTO.txt
index 53e6fca..a091780 100644
--- a/Documentation/PCI/MSI-HOWTO.txt
+++ b/Documentation/PCI/MSI-HOWTO.txt
@@ -127,15 +127,42 @@ on the number of vectors that can be allocated; 
pci_enable_msi_block()
 returns as soon as it finds any constraint that doesn't allow the
 call to succeed.
 
-4.2.3 pci_disable_msi
+4.2.3 pci_enable_msi_block_auto
+
+int pci_enable_msi_block_auto(struct pci_dev *dev, unsigned int *count)
+
+This variation on pci_enable_msi() call allows a device driver to request
+the maximum possible number of MSIs.  The MSI specification only allows
+interrupts to be allocated in powers of two, up to a maximum of 2^5 (32).
+
+If this function returns a positive number, it indicates that it has
+succeeded and the returned value is the number of allocated interrupts. In
+this case, the function enables MSI on this device and updates dev-irq to
+be the lowest of the new interrupts assigned to it.  The other interrupts
+assigned to the device are in the range dev-irq to dev-irq + returned
+value - 1.
+
+If this function returns a negative number, it indicates an error and
+the driver should not attempt to request any more MSI interrupts for
+this device.
+
+If the device driver needs to know the number of interrupts the device
+supports it can pass the pointer count where that number is stored. The
+device driver must decide what action to take if pci_enable_msi_block_auto()
+succeeds, but returns a value less than the number of interrupts supported.
+If the device driver does not need to know the number of interrupts
+supported, it can set the pointer count to NULL.
+
+4.2.4 pci_disable_msi
 
 void pci_disable_msi(struct pci_dev *dev)
 
 This function should be used to undo the effect of pci_enable_msi() or
-pci_enable_msi_block().  Calling it restores dev-irq to the pin-based
-interrupt number and frees the previously allocated message signaled
-interrupt(s).  The interrupt may subsequently be assigned to another
-device, so drivers should not cache the value of dev-irq.
+pci_enable_msi_block() or pci_enable_msi_block_auto().  Calling it restores
+dev-irq to the pin-based interrupt number and frees the previously
+allocated message signaled interrupt(s).  The interrupt may subsequently be
+assigned to another device, so drivers should not cache the value of
+dev-irq.
 
 Before calling this function, a device driver must always call free_irq()
 on any interrupt for which it previously called request_irq().
diff --git a/drivers/pci/msi.c b/drivers/pci/msi.c
index f0752d1..690b268 100644
--- a/drivers/pci/msi.c
+++ b/drivers/pci/msi.c
@@ -845,6 +845,32 @@ int pci_enable_msi_block(struct pci_dev *dev, unsigned int 
nvec)
 }
 EXPORT_SYMBOL(pci_enable_msi_block);
 
+int pci_enable_msi_block_auto(struct pci_dev *dev, unsigned int *maxvec)
+{
+   int ret, pos, nvec;
+   u16 msgctl;
+
+   pos = pci_find_capability(dev, PCI_CAP_ID_MSI);
+   if (!pos)
+   return -EINVAL;
+
+   pci_read_config_word(dev, pos + PCI_MSI_FLAGS, msgctl);
+   ret = 1  ((msgctl  PCI_MSI_FLAGS_QMASK)  1);
+
+   if (maxvec)
+   *maxvec = ret;
+
+   do {
+   nvec = ret;
+   ret = pci_enable_msi_block(dev, nvec);
+   } while (ret  0);
+
+   if (ret  0)
+   return ret;
+   return nvec;
+}
+EXPORT_SYMBOL(pci_enable_msi_block_auto);
+
 void pci_msi_shutdown(struct pci_dev *dev)
 {
struct msi_desc *desc;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 5faa831..b8a9454 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -1070,6 +1070,12 @@ static inline int pci_enable_msi_block(struct pci_dev 
*dev, unsigned int nvec)
return -1;
 }
 
+static inline int
+pci_enable_msi_block_auto(struct pci_dev *dev, unsigned int *maxvec)
+{
+   return -1;
+}
+
 static inline void pci_msi_shutdown(struct pci_dev *dev)
 { }
 static inline void pci_disable_msi(struct pci_dev *dev)
@@ -1101,6 +1107,7 @@ static inline int pci_msi_enabled(void)
 }
 #else
 extern int pci_enable_msi_block(struct pci_dev *dev, unsigned int nvec);

[PATCH v3 -tip 5/5] AHCI: Support multiple MSIs

2012-10-01 Thread Alexander Gordeev
Take advantage of multiple MSIs implementation on x86 - on systems with
IRQ remapping AHCI ports not only get assigned separate MSI vectors -
but also separate IRQs. As result, interrupts generated by different
ports could be serviced on different CPUs rather than on a single one.

In cases when number of allocated MSIs is less than requested the Sharing
Last MSI mode does not get used, no matter implemented in hardware or not.
Instead, the driver assumes the advantage of multiple MSIs is negated and
falls back to the single MSI mode as if MRSM bit was set (some Intel chips
implement this strategy anyway - MRSM bit gets set even if the number of
allocated MSIs exceeds the number of implemented ports).

Signed-off-by: Alexander Gordeev agord...@redhat.com
---
 drivers/ata/ahci.c|   91 --
 drivers/ata/ahci.h|6 +++
 drivers/ata/libahci.c |  118 ++---
 3 files changed, 205 insertions(+), 10 deletions(-)

diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 7862d17..5463fcea 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -1057,6 +1057,84 @@ static inline void ahci_gtf_filter_workaround(struct 
ata_host *host)
 {}
 #endif
 
+int ahci_init_interrupts(struct pci_dev *pdev, struct ahci_host_priv *hpriv)
+{
+   int rc;
+   unsigned int maxvec;
+
+   if (!(hpriv-flags  AHCI_HFLAG_NO_MSI)) {
+   rc = pci_enable_msi_block_auto(pdev, maxvec);
+   if (rc  0) {
+   if ((rc == maxvec) || (rc == 1))
+   return rc;
+   /* assume that advantage of multipe MSIs is negated,
+* so fallback to single MSI mode to save resources */
+   pci_disable_msi(pdev);
+   if (!pci_enable_msi(pdev))
+   return 1;
+   }
+   }
+
+   pci_intx(pdev, 1);
+   return 0;
+}
+
+/**
+ * ahci_host_activate - start AHCI host, request IRQs and register it
+ * @host: target ATA host
+ * @irq: base IRQ number to request
+ * @n_msis: number of MSIs allocated for this host
+ * @irq_handler: irq_handler used when requesting IRQs
+ * @irq_flags: irq_flags used when requesting IRQs
+ *
+ * Similar to ata_host_activate, but requests IRQs according to AHCI-1.1
+ * when multiple MSIs were allocated. That is one MSI per port, starting
+ * from @irq.
+ *
+ * LOCKING:
+ * Inherited from calling layer (may sleep).
+ *
+ * RETURNS:
+ * 0 on success, -errno otherwise.
+ */
+int ahci_host_activate(struct ata_host *host, int irq, unsigned int n_msis)
+{
+   int i, rc;
+
+   /* Sharing Last Message among several ports is not supported */
+   if (n_msis  host-n_ports)
+   return -EINVAL;
+
+   rc = ata_host_start(host);
+   if (rc)
+   return rc;
+
+   for (i = 0; i  host-n_ports; i++) {
+   rc = devm_request_threaded_irq(host-dev,
+   irq + i, ahci_hw_interrupt, ahci_thread_fn, IRQF_SHARED,
+   dev_driver_string(host-dev), host-ports[i]);
+   if (rc)
+   goto out_free_irqs;
+   }
+
+   for (i = 0; i  host-n_ports; i++)
+   ata_port_desc(host-ports[i], irq %d, irq + i);
+
+   rc = ata_host_register(host, ahci_sht);
+   if (rc)
+   goto out_free_all_irqs;
+
+   return 0;
+
+out_free_all_irqs:
+   i = host-n_ports;
+out_free_irqs:
+   for (; i; i--)
+   devm_free_irq(host-dev, irq + i - 1, host-ports[i]);
+
+   return rc;
+}
+
 static int ahci_init_one(struct pci_dev *pdev, const struct pci_device_id *ent)
 {
unsigned int board_id = ent-driver_data;
@@ -1065,7 +1143,7 @@ static int ahci_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
struct device *dev = pdev-dev;
struct ahci_host_priv *hpriv;
struct ata_host *host;
-   int n_ports, i, rc;
+   int n_ports, n_msis, i, rc;
int ahci_pci_bar = AHCI_PCI_BAR_STANDARD;
 
VPRINTK(ENTER\n);
@@ -1150,11 +1228,12 @@ static int ahci_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
if (ahci_sb600_enable_64bit(pdev))
hpriv-flags = ~AHCI_HFLAG_32BIT_ONLY;
 
-   if ((hpriv-flags  AHCI_HFLAG_NO_MSI) || pci_enable_msi(pdev))
-   pci_intx(pdev, 1);
-
hpriv-mmio = pcim_iomap_table(pdev)[ahci_pci_bar];
 
+   n_msis = ahci_init_interrupts(pdev, hpriv);
+   if (n_msis  1)
+   hpriv-flags |= AHCI_HFLAG_MULTI_MSI;
+
/* save initial config */
ahci_pci_save_initial_config(pdev, hpriv);
 
@@ -1250,6 +1329,10 @@ static int ahci_init_one(struct pci_dev *pdev, const 
struct pci_device_id *ent)
ahci_pci_print_info(host);
 
pci_set_master(pdev);
+
+   if (hpriv-flags  AHCI_HFLAG_MULTI_MSI)
+   

Re: [PATCH v4] KSM: numa awareness sysfs knob

2012-10-01 Thread Hugh Dickins
On Sun, 30 Sep 2012, Hugh Dickins wrote:
 Andrea's point about ksm_migrate_page() is an important one, and I've
 answered that against his mail, but here's some other easier points.

There's another point that I completely forgot to make once I got down
to the details of your patch.

Somewhere, I didn't decide exactly where, perhaps near the memcmp_pages()
call in unstable_tree_search_insert(), you do need to check that the page
in the unstable tree still belongs to the NUMAnode of the page we're
comparing with.

While that is, of course, the NUMAnode of the unstable tree we're
searching, the unstable tree places no hold on the pages in it (it's
actually a tree of rmap_items, not of pages), so they could get migrated
to a different NUMAnode (or faulted out and then faulted back in on a
different NUMAnode) since the rmap_item was placed in that tree.

This is little different from the other instabilities of the unstable
tree, it's not a big deal, and gets corrected (usually) next time around;
but you do want to check, to avoid promoting such a mismatch into the
stable tree.

Hugh
--
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: [PATCHv2 00/14] perf diff: Factor diff command

2012-10-01 Thread Jiri Olsa
On Thu, Sep 27, 2012 at 11:31:02PM +0200, Andi Kleen wrote:
 On Thu, Sep 27, 2012 at 01:09:21PM +0200, Jiri Olsa wrote:
  hi,
  this is v2 of diff command changes proposed in here:
  https://lkml.org/lkml/2012/9/6/344
  
  It's now rebased on new hists hpp* interface plus few
  more additional changes.
 
 FWIW I've been playing around with it a bit. It seems useful
 both for scaling problems and likely for performance regression tracking too.

cool ;)

 
 Some minor issues I ran into (but no show stoppers):
 - The error messages for bad -c expressions could be better
 - I found the requirement for no space after -c unintuitive.

I'll see to that

 - It would be nice to have support for doing the bucketizing per line
 instead of per function. With a large function and/or inlining 
 it's sometimes hard to identify the actual problem
 Acme recently added this for perf report.

hm, I missed this one.. hopefully it should be no problem to add it

thanks for testing this!
jirka
--
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] drm/nouveau: fix crash regression

2012-10-01 Thread Ortwin Glück

Work around a crash during boot if noaccel is set.

NB: still broken in 3.5 as well, used to work in 3.4. Why are people 
ignoring this? It's a regression!


Signed-off-by: Ortwin Glück o...@odi.ch
---
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
b/drivers/gpu/drm/nouveau/nv50_display.c

index b244d99..c7ffa63 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -650,6 +650,12 @@ nv50_display_vblank_crtc_handler(struct drm_device 
*dev, int crtc)

struct nouveau_software_priv *psw = nv_engine(dev, NVOBJ_ENGINE_SW);
struct nouveau_software_chan *pch, *tmp;

+if (!psw) {
+WARN_ON_ONCE(1);
+printk(KERN_ERR NULL software engine\n);
+return;
+}
+
list_for_each_entry_safe(pch, tmp, psw-vblank, vblank.list) {
if (pch-vblank.head != crtc)
continue;
--
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] hid:Fix problem on GeneralTouch multi-touchscreen

2012-10-01 Thread Jiri Kosina
On Fri, 28 Sep 2012, GeneralTouch wrote:

 From: Xianhan Yu aroundigh...@gmail.com
 
 Fix the touch-up no response problem on GeneralTouch twofingers 
 touchscreen and modify the driver for new GeneralTouch PWT touchscreen.
 
 Signed-off-by: Xianhan Yu aroundigh...@gmail.com

Applied, 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/


Re: [PATCH 3/3] virtio_console: Don't initialize buffers to zero

2012-10-01 Thread Amit Shah
On (Tue) 25 Sep 2012 [15:47:17], sjur.brandel...@stericsson.com wrote:
 From: Sjur Brændeland sjur.brandel...@stericsson.com
 
 Skip initializing the receive buffers.

This tells 'what', but not 'why'.  Please add some more description.
For the generic virtio ports case, at least, my original thinking was
to not send random guest data to the host device.  However, we don't
have any device isolation in the host yet, and doing that will be
expensive, so it's not going to be done in the near future.. this can
be safely skipped.

Also, please make this patch 1/3, so we don't end up doing

 kzalloc-kmalloc+memset-kmalloc

Thanks,
Amit
--
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: HID: picoLCD: optimize for inactive debugfs

2012-10-01 Thread Jiri Kosina
On Sun, 30 Sep 2012, Bruno Prémont wrote:

 Matthieu CASTET adjusted picolcd_debug_out_report() to only operate when
 there is an active listener on debugfs for events.
 
 His change got lost while splitting hid_picolcd.c, restore it.
 
 Signed-off-by: Bruno Prémont bonb...@linux-vserver.org
 ---
 
 
 diff --git a/drivers/hid/hid-picolcd_debugfs.c 
 b/drivers/hid/hid-picolcd_debugfs.c
 index 6ef03be..4809aa1 100644
 --- a/drivers/hid/hid-picolcd_debugfs.c
 +++ b/drivers/hid/hid-picolcd_debugfs.c
 @@ -402,7 +402,7 @@ void picolcd_debug_out_report(struct picolcd_data *data,
  #define BUFF_SZ 256
  
   /* Avoid unnecessary overhead if debugfs is disabled */
 - if (!hdev-debug_events)
 + if (list_empty(hdev-debug_list))
   return;
  
   buff = kmalloc(BUFF_SZ, GFP_ATOMIC);

Applied, 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/


Re: [PATCH v3 06/13] memcg: kmem controller infrastructure

2012-10-01 Thread Glauber Costa
On 09/30/2012 12:25 PM, Tejun Heo wrote:
 On Fri, Sep 28, 2012 at 03:34:19PM +0400, Glauber Costa wrote:
 On 09/27/2012 05:44 PM, Michal Hocko wrote:
 Anyway, I have just noticed that __mem_cgroup_try_charge does
 VM_BUG_ON(css_is_removed(memcg-css)) on a given memcg so you should
 keep css ref count up as well.

 IIRC, css_get will prevent the cgroup directory from being removed.
 Because some allocations are expected to outlive the cgroup, we
 specifically don't want that.
 
 That synchronous ref draining is going away.  Maybe we can do that
 before kmemcg?  Michal, do you have some timeframe on mind?
 

Since you said yourself in other points in this thread that you are fine
with some page references outliving the cgroup in the case of slab, this
is a situation that comes with the code, not a situation that was
incidentally there, and we're making use of.


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


x86_64: wrong DirectMap kB

2012-10-01 Thread Hugh Dickins
Jan,

I noticed yesterday that the DirectMap counts at the bottom of x86_64's
/proc/meminfo are wrong on v3.5 and v3.6.  For example, I happen to have
booted this laptop with mem=700M to run a test, but /proc/meminfo shows

DirectMap4k:4096 kB
DirectMap2M:18446744073709547520 kB

Or if I boot with the full amount of physical memory, the DirectMap
numbers do not add up to the full amount of physical memory, as they
used to do on v3.4 and before.

Whilst I've not yet tried reverting it, I strongly suspect your
20167d3421a0 x86-64: Fix accounting in kernel_physical_mapping_init().

Either it was a complete misunderstanding, totally bogus, and should
simply be reverted; or perhaps you really noticed something wrong in
your code inspection, but didn't get the fix quite right?

Hugh
--
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 04/13] kmem accounting basic infrastructure

2012-10-01 Thread Glauber Costa
On 09/30/2012 11:57 AM, Tejun Heo wrote:
 Hello, Glauber.
 
 On Thu, Sep 27, 2012 at 10:45:01PM +0400, Glauber Costa wrote:
 Can you please give other examples of cases where this type of issue
 exists (plenty of shared kernel data structure which is inherent to
 the workload at hand)?  Until now, this has been the only example for
 this type of issues.

 Yes. the namespace related caches (*), all kinds of sockets and network
 structures, other file system structures like file struct, vm areas, and
 pretty much everything a full container does.

 (*) we run full userspace, so we have namespaces + cgroups combination.
 
 This is probably me being dumb but wouldn't resources used by full
 namespaces be mostly independent?  Which parts get shared?  Also, if
 you do full namespace, isn't it more likely that you would want fuller
 resource isolation too?
 

Not necessarily. Namespaces are pretty flexible. If you are using the
network namespace, for instance, you can create interfaces, routes,
addresses, etc. But because this deals with the network only, there is
nothing unreasonable in saying that your webserver and database lives in
the same network (which is a different network namespace), but are
entitled to different memory limits - which is cgroups realm. With
application-only containers being championed these days by multiple
users, I would expect this situation to become non-negligible.

The full container scenario, of course, is very different. Most of the
accesses tends to be local.

I will second what Michal said, since I believe this is also very
important: User memory is completely at the control of the application,
while kernel memory is not, and never will. It is perfectly fine to
imagine applications that want its memory to be limited by a very
predictable amount, and there are no reasons to believe that those
cannot live in the same box as full containers - the biggest example of
kmem interested folks. It could be, for instance, that a management tool
for containers lives in there, and that application wants to be umem
limited but not kmem limited. (If it goes touching files and data inside
each container, for instance, it is obviously not local)

 Mel suggestion of not allowing this to happen once the cgroup has tasks
 takes care of this, and is something I thought of myself.

 You mean Michal's?  It should also disallow switching if there are
 children cgroups, right?

 No, I meant Mel, quoting this:

 Further I would expect that an administrator would be aware of these
 limitations and set kmem_accounting at cgroup creation time before any
 processes start. Maybe that should be enforced but it's not a
 fundamental problem.

 But I guess it is pretty much the same thing Michal proposes, in essence.

 Or IOW, if your concern is with the fact that charges may have happened
 in the past before this is enabled, we can make sure this cannot happen
 by disallowing the limit to be set if currently unset (value changes are
 obviously fine) if you have children or any tasks already in the group.
 
 Yeah, please do that.
 

I did already, patches soon! =)

--
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 09/16] iommu/amd: Add IOAPIC remapping routines

2012-10-01 Thread Joerg Roedel
On Fri, Sep 28, 2012 at 10:45:15AM -0400, Konrad Rzeszutek Wilk wrote:
 On Fri, Sep 28, 2012 at 02:23:59PM +0200, Joerg Roedel wrote:
  +   /*
  +* Mask level triggered irqs.
  +* Use IRQ_DELAYED_DISABLE for edge triggered irqs.
 
 so how come it is not set?

Don't understand this. What is not set?

  +   if (!config_enabled(CONFIG_SMP))
  +   return -1;
 
 -1? -ENOx something?

No, -1 for compatibiblity with the other implementation of this.

  +   err = apic-cpu_mask_to_apicid_and(cfg-domain, mask, dest);
  +   if (err) {
  +   if (assign_irq_vector(irq, cfg, data-affinity))
  +   pr_err(AMD-Vi: Failed to recover vector for irq %d\n, 
  irq);
 
 If we do OK with the assignment of the vector, should we just continue
 on instead of returning error?

The purpose of this is to recover to the old affinity if we failed at
this point. Even in this case, setting the new affinity still failed and
we need to inform the caller about this. Thus returning the error.
Also note the pr_err message which also tells you about the
recovery-case :)


Joerg


-- 
AMD Operating System Research Center

Advanced Micro Devices GmbH Einsteinring 24 85609 Dornach
General Managers: Alberto Bozzo
Registration: Dornach, Landkr. Muenchen; Registerger. Muenchen, HRB Nr. 43632

--
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 04/12] perf tools: Convert to LIBUNWIND_SUPPORT

2012-10-01 Thread Jiri Olsa
On Fri, Sep 28, 2012 at 06:32:00PM +0900, Namhyung Kim wrote:
 From: Namhyung Kim namhyung@lge.com
 
 For building perf without libunwind, we can set NO_LIBUNWIND=1 as a
 argument of make.  It then defines NO_LIBUNWIND_SUPPORT macro for C
 code to do the proper handling.  However it usually used in a negative
 semantics - e.g. #ifndef - so we saw double negations which can be
 misleading.  Convert it to a positive form to make it more readable.
 
 Also change NO_PERF_REGS macro to HAVE_PERF_REGS for the same reason.
 
 Cc: Jiri Olsa jo...@redhat.com
 Signed-off-by: Namhyung Kim namhy...@kernel.org

Acked-by: Jiri Olsa jo...@redhat.com
--
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/6] target/file: Re-enable optional fd_buffered_io=1 operation

2012-10-01 Thread Christoph Hellwig
On Sun, Sep 30, 2012 at 05:58:11AM +, Nicholas A. Bellinger wrote:
 From: Nicholas Bellinger n...@linux-iscsi.org
 
 This patch re-adds the ability to optionally run in buffered FILEIO mode
 (eg: w/o O_DSYNC) for device backends in order to once again use the
 Linux buffered cache as a write-back storage mechanism.
 
 This difference with this patch is that fd_create_virtdevice() now
 forces the explicit setting of emulate_write_cache=1 when buffered FILEIO
 operation has been enabled.

What this lacks is a clear reason why you would enable this inherently
unsafe mode.  While there is some clear precedence to allow people doing
stupid thing I'd least like a rationale for it, and it being documented
as unsafe.

 +  /*

Indention error.

 +  * Optionally allow fd_buffered_io=1 to be enabled for people
 +  * who know what they are doing w/o O_DSYNC.
 +  */

This comment doesn't explain at all what's going on here.  It should be
something like

/*
 * Unsafe mode allows disabling data integrity by not forcing
 * data out to disk in writethrough cache mode.  Only to be used
 * for benchmark cheating or similar purposes.
 */

  #define FBDF_HAS_PATH0x01
  #define FBDF_HAS_SIZE0x02
 +#define FDBD_USE_BUFFERED_IO 0x04

This should be named BDBD_UNSAFE

--
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 04/13] kmem accounting basic infrastructure

2012-10-01 Thread Glauber Costa
On 10/01/2012 04:57 AM, Tejun Heo wrote:
 Hello, James.
 
 On Sun, Sep 30, 2012 at 12:25:52PM +0100, James Bottomley wrote:
 But you've got to ask yourself who cares about accurate accounting per
 container of dentry and inode objects? They're not objects that any
 administrator is used to limiting.  What we at parallels care about
 isn't accurately accounting them, it's that one container can't DoS
 another by exhausting system resources.  That's achieved equally well by
 first charge slab accounting, so we don't really have an interest in
 pushing object accounting code for which there's no use case.
 
 Isn't it more because the use cases you have on mind don't share
 dentries/inodes too much?  Wildly incorrect accounting definitely
 degrades container isolation and can lead to unexpected behaviors.
 
 All we need kernel memory accounting and limiting for is DoS prevention.
 There aren't really any system administrators who care about Kernel
 Memory accounting (at least until the system goes oom) because there are
 no absolute knobs for it (all there is are a set of weird and wonderful
 heuristics, like dirty limit ratio and drop caches).  Kernel memory
 
 I think that's because the mechanism currently doesn't exist.  If one
 wants to control how memory is distributed across different cgroups,
 it's logical to control kernel memory too.  The resource in question
 is the actual memory after all.  I think at least google would be
 interested in it, so, no, I don't agree that nobody wants it.  If that
 is the case, we're working towards the wrong direction.
 
 usage has a whole set of regulatory infrastructure for trying to make it
 transparent to the user.

 Don't get me wrong: if there were some easy way to get proper memory
 accounting for free, we'd be happy but, because it has no practical
 application for any of our customers, there's a limited price we're
 willing to pay to get it.
 
 Even on purely technical ground, it could be that first-use is the
 right trade off if other more accurate approaches are too difficult
 and most workloads are happy with such approach.  I'm still a bit
 weary to base userland interface decisions on that tho.
 

For the record, user memory also suffers a bit from being always
constrained to first-touch accounting. Greg Thelen is working on
alternative solutions to make first-accounting the default in a
configurable environment, as he explained in the kernel summit.

When that happens, kernel memory can take advantage of it for free.

--
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 04/13] kmem accounting basic infrastructure

2012-10-01 Thread Glauber Costa
On 09/30/2012 12:23 PM, Tejun Heo wrote:
 Hello, Glauber.
 
 On Thu, Sep 27, 2012 at 10:30:36PM +0400, Glauber Costa wrote:
 But that happens only when pages enter and leave slab and if it still
 is significant, we can try to further optimize charging.  Given that
 this is only for cases where memcg is already in use and we provide a
 switch to disable it globally, I really don't think this warrants
 implementing fully hierarchy configuration.

 Not totally true. We still have to match every allocation to the right
 cache, and that is actually our heaviest hit, responsible for the 2, 3 %
 we're seeing when this is enabled. It is the kind of path so hot that
 people frown upon branches being added, so I don't think we'll ever get
 this close to being free.
 
 Sure, depening on workload, any addition to alloc/free could be
 noticeable.  I don't know.  I'll write more about it when replying to
 Michal's message.  BTW, __memcg_kmem_get_cache() does seem a bit
 heavy.  I wonder whether indexing from cache side would make it
 cheaper?  e.g. something like the following.
 
   kmem_cache *__memcg_kmem_get_cache(cachep, gfp)
   {
   struct kmem_cache *c;
 
   c = cachep-memcg_params-caches[percpu_read(kmemcg_slab_idx)];
   if (likely(c))
   return c;
   /* try to create and then fall back to cachep */
   }
 
 where kmemcg_slab_idx is updated from sched notifier (or maybe add and
 use current-kmemcg_slab_idx?).  You would still need __GFP_* and
 in_interrupt() tests but current-mm and PF_KTHREAD tests can be
 rolled into index selection.
 

How big would this array be? there can be a lot more kmem_caches than
there are memcgs. That is why it is done from memcg side.

--
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 04/13] kmem accounting basic infrastructure

2012-10-01 Thread Glauber Costa
On 09/30/2012 02:37 PM, Tejun Heo wrote:
 Hello, James.
 
 On Sun, Sep 30, 2012 at 09:56:28AM +0100, James Bottomley wrote:
 The beancounter approach originally used by OpenVZ does exactly this.
 There are two specific problems, though, firstly you can't count
 references in generic code, so now you have to extend the cgroup
 tentacles into every object, an invasiveness which people didn't really
 like.
 
 Yeah, it will need some hooks.  For dentry and inode, I think it would
 be pretty well isolated tho.  Wasn't it?
 

We would still need something for the stack. For open files, and for
everything that becomes a potential problem. We then end up with 35
different knobs instead of one. One of the perceived advantages of this
approach, is that it condenses as much data as a single knob as
possible, reducing complexity and over flexibility.

--
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/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER

2012-10-01 Thread Thomas Hellstrom

On 09/29/2012 05:16 PM, Maarten Lankhorst wrote:

Op 28-09-12 22:10, Thomas Hellstrom schreef:

On 09/28/2012 09:42 PM, Thomas Hellstrom wrote:

On 09/28/2012 04:14 PM, Maarten Lankhorst wrote:

Hey,

Op 28-09-12 14:41, Maarten Lankhorst schreef:

Documentation says that code requiring dma-buf should add it to
select, so inline fallbacks are not going to be used. A link error
will make it obvious what went wrong, instead of silently doing
nothing at runtime.



The whole patch series is in my tree, I use stg so things might
move around, do not use for merging currently:

http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip

It contains everything in here plus the patches for ttm to make
it work, I use a old snapshot of drm-next + merge of nouveau as
base. Description of what the parts do:

Series to fix small api issues when moving over:

drm/ttm: Remove cpu_writers related code
drm/ttm: Add ttm_bo_is_reserved function
drm/radeon: Use ttm_bo_is_reserved
drm/vmwgfx: use ttm_bo_is_reserved

drm/vmwgfx: remove use of fence_obj_args
drm/ttm: remove sync_obj_arg
drm/ttm: remove sync_obj_arg from ttm_bo_move_accel_cleanup
drm/ttm: remove sync_arg entirely

drm/nouveau: unpin buffers before releasing to prevent lockdep warnings
drm/nouveau: add reservation to nouveau_bo_vma_del
drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep

Hey great, now we only have one user left for fence waiting before reserving,
lets fix that and remove fence lock:
ttm_bo_cleanup_refs_or_queue and ttm_bo_cleanup_refs have to reserve before
waiting, lets do it in the squash commit so we don't have to throw lock order
around everywhere:

drm/ttm: remove fence_lock

-- Up to this point should be mergeable now

Then we start working on lru_lock removal slightly, this means the lru
list no longer is empty but can contain only reserved buffers:

drm/ttm: do not check if list is empty in ttm_bo_force_list_clean
drm/ttm: move reservations for ttm_bo_cleanup_refs

-- Still mergeable up to this point, just fixes

Patch series from this email:
dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
fence: dma-buf cross-device synchronization (v9)
seqno-fence: Hardware dma-buf implementation of fencing (v3)
reservation: cross-device reservation support
reservation: Add lockdep annotation and selftests

Now hook it up to drm/ttm in a few steps:
usage around reservations:
drm/ttm: make ttm reservation calls behave like reservation calls
drm/ttm: use dma_reservation api
dma-buf: use reservations
drm/ttm: allow drivers to pass custom dma_reservation_objects for a bo

then kill off the lru lock around reservation:
drm/ttm: remove lru_lock around ttm_bo_reserve
drm/ttm: simplify ttm_eu_*

The lru_lock removal patch removes the lock around lru_lock around the
reservation, this will break the assumption that items on the lru list
and swap list can always be reserved, and this gets patched up too.
Is there any part in ttm you disagree with? I believe that this
is all mergeable, the lru_lock removal patch could be moved to before
the reservation parts, this might make merging easier, but I don't
think there is any ttm part of the series that are wrong on a conceptual
level.

~Maarten


From another email


As previously discussed, I'm unfortunately not prepared to accept removal of 
the reserve-lru atomicity
   into the TTM code at this point.
The current code is based on this assumption and removing it will end up with
efficiencies, breaking the delayed delete code and probably a locking nightmare 
when trying to write
new TTM code.

The lru lock removal patch fixed the delayed delete code, it really is not 
different from the current
situation. In fact it is more clear without the guarantee what various parts 
are trying to protect.

Nothing prevents you from holding the lru_lock while trylocking,

[1]
While this would not cause any deadlocks, Any decent lockdep code would establish 
lru-reserve as the locking
order once a lru- reserve trylock succeeds, but the locking order is really 
reserve-lru for obvious reasons, which
means we will get a lot of lockdep errors? Yes, there are a two reversals like 
these already in the TTM code, and I'm
not very proud of them.

leaving that guarantee intact for that part. Can you really just review
the patch and tell me where it breaks and/or makes the code unreadable?

OK. Now I'm looking at
http://cgit.freedesktop.org/~mlankhorst/linux/tree/drivers/gpu/drm/ttm/ttm_bo.c?h=v10-wipid=1436e2e64697c744d6e186618448e1e6354846bb

And let's start with a function that's seen some change, ttm_mem_evict_first:

*) Line 715: You're traversing a list using list_for_each() calling a function 
that may remove the list entry
*) Line 722: You're unlocking the lock protecting the list in the middle of 
list traversal
*) Line 507: WARN_ON_ONCE in a code path quite likely to get called?

When will it get called?
ttm_bo_delayed_delete calls it if it's already on delayed destroy list.
ttm_mem_evict_first only calls 

[PATCH v3 -tip 3/5] x86, MSI: Minor readability fixes

2012-10-01 Thread Alexander Gordeev
Signed-off-by: Alexander Gordeev agord...@redhat.com
---
 arch/x86/kernel/apic/io_apic.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kernel/apic/io_apic.c b/arch/x86/kernel/apic/io_apic.c
index 84d632b..0489699 100644
--- a/arch/x86/kernel/apic/io_apic.c
+++ b/arch/x86/kernel/apic/io_apic.c
@@ -3123,7 +3123,7 @@ static int msi_compose_msg(struct pci_dev *pdev, unsigned 
int irq,
 
if (irq_remapped(cfg)) {
compose_remapped_msi_msg(pdev, irq, dest, msg, hpet_id);
-   return err;
+   return 0;
}
 
if (x2apic_enabled())
@@ -3150,7 +3150,7 @@ static int msi_compose_msg(struct pci_dev *pdev, unsigned 
int irq,
MSI_DATA_DELIVERY_LOWPRI) |
MSI_DATA_VECTOR(cfg-vector);
 
-   return err;
+   return 0;
 }
 
 static int
@@ -3232,7 +3232,7 @@ int setup_msix_irqs(struct pci_dev *dev, int nvec)
list_for_each_entry(msidesc, dev-msi_list, list) {
irq = create_irq_nr(irq_want, node);
if (irq == 0)
-   return -1;
+   return -ENOSPC;
irq_want = irq + 1;
if (!irq_remapping_enabled)
goto no_ir;
-- 
1.7.7.6


-- 
Regards,
Alexander Gordeev
agord...@redhat.com
--
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: rcu self-detected stall messages on OMAP3, 4 boards

2012-10-01 Thread Linus Walleij
On Sat, Sep 22, 2012 at 11:59 PM, Paul E. McKenney
paul...@linux.vnet.ibm.com wrote:

 rcu: Fix day-one dyntick-idle stall-warning bug

As mentioned in another thread this solves the same problem for ux500.
Reported/Tested-by: Linus Walleij linus.wall...@linaro.org

But now it appears that this commit didn't make it into v3.6 so
it definately needs to be tagged with Cc: sta...@kernel.org
before it gets merged since the stall warnings are kinda scary.

Yours,
Linus Walleij
--
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/6] usb: dwc3-omap: use of_platform API to create dwc3 core pdev

2012-10-01 Thread Felipe Balbi
Hi,

On Fri, Sep 28, 2012 at 07:01:04PM +0530, ABRAHAM, KISHON VIJAY wrote:
 Hi,
 
 On Fri, Sep 28, 2012 at 6:27 PM, Felipe Balbi ba...@ti.com wrote:
  Hi,
 
  On Fri, Sep 28, 2012 at 06:23:10PM +0530, Kishon Vijay Abraham I wrote:
  Used of_platform_populate() to populate dwc3 core platform_device
  from device tree data. Since now the allocation of unique device id is
  handled be of_*, removed the call to dwc3_get_device_id.
 
  Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
 
  I think it's best if you split the use of device_for_each_child() from
  this patch. So first do the device_for_each_child() part, then later use
  of_platform_populate().
 
 I think it's better to have it both together as of_platform_populate
 will create the device and the device_for_each_child() part will
 delete it on error conditions and during driver removal.
 In this patch the first device_for_each_child() comes in error
 condition and it is not needed if we have not created the device using
 of_platform_populate.

We are already parent of a device and we already handle child removal
manually. You can change the current implementation to use
device_for_each_child() and on a later patch introduce
of_platform_populate().

-- 
balbi


signature.asc
Description: Digital signature


Re: [PATCHv4 1/4] modem_shm: Add Modem Access Framework

2012-10-01 Thread anish singh
On Mon, Oct 1, 2012 at 12:27 PM, Arun MURTHY arun.mur...@stericsson.com wrote:
 On Mon, Oct 1, 2012 at 11:00 AM, Arun MURTHY
 arun.mur...@stericsson.com wrote:
  On Fri, Sep 28, 2012 at 01:35:01PM +0530, Arun Murthy wrote:
   +#include linux/module.h
   +#include linux/slab.h
   +#include linux/err.h
   +#include linux/printk.h
   +#include linux/modem_shm/modem.h
   +
   +static struct class *modem_class;
 
  What's wrong with a bus_type instead?
 
  Can I know the advantage of using bus_type over class?
 
 
   +static int __modem_is_requested(struct device *dev, void *data) {
   +   struct modem_desc *mdesc = (struct modem_desc *)data;
   +
   +   if (!mdesc-mclients) {
   +   printk(KERN_ERR modem_access: modem description is
  NULL\n);
   +   return 0;
   +   }
   +   return atomic_read(mdesc-mclients-cnt);
   +}
   +
   +int modem_is_requested(struct modem_desc *mdesc) {
   +   return class_for_each_device(modem_class, NULL, (void *)mdesc,
   +__modem_is_requested); }
 
  Where is the documentation for your public api functions like this?
 
  Sure will include this in the next patchset.
 
 
   +
   +int modem_release(struct modem_desc *mdesc) {
   +   if (!mdesc-release)
   +   return -EFAULT;
   +
   +   if (modem_is_requested(mdesc)) {
   +   atomic_dec(mdesc-mclients-cnt);
   +   if (atomic_read(mdesc-use_cnt) == 1) {
   +   mdesc-release(mdesc);
   +   atomic_dec(mdesc-use_cnt);
   +   }
 
  Eeek, why aren't you using the built-in reference counting that the
  struct device provided to you, and instead are rolling your own?
  This happens in many places, why?
 
  My usage of counters over here is for each modem there are many clients.
  Each of the clients will have a ref to modem_desc. Each of them use
  this for requesting and releasing the modem. One counter for tracking
  the request and release for each client which is done by variable 'cnt' in
 struct clients.
  The counter use_cnt is used for tracking the modem request/release
  irrespective of the clients and counter cli_cnt is used for
  restricting the modem_get to the no of clients defined in no_clients.
 
  So totally 3 counter one for restricting the usage of modem_get by
  clients, second for restricting modem request/release at top level,
  and 3rd for restricting modem release/request for per client per modem
 basis.
 
  Can you let me know if the same can be achieved by using built-in ref
  counting?
 Is this your model:
 You have a modem device which can be requested by many clients.This
 clients can register for a particular service which this modem provides and
 then after that if it client doesn't need this service then it will call 
 un-register.

 Let me correct a bit over here:
 There are many clients, yes correct but the operations performed are only two,
 i.e modem request and modem release. This is something like waking up the
 modem and let modem to sleep.
 The traffic of this request and release is too high.

 So irrespective of the requests/releases made to the MAF framework, the MAF
 should perform the operation request/release only once.

 So each and every time handling list consumes time.
 Let me brief the context, this is a single chip modem and ape, basically used 
 in
 mobile, tablets etc. So the traffic in ape-modem communication is too high and
 also time critical. If it bound to exceed the time, or delay might end up in 
 buffer
 full. That’s the reason I have made it as simple as possible.

So let me put it this way:
   Modem Client1 Client2Client3Client4
State  turn-on   request
State  no-state-change request
State  no-state-change   request
State  no-state-change
request
State  no-state-change  release
State  no-state-change release
State  no-state-change   release
State   turn-off
  release

So eventhough all the clients have requested the modem it is being
turned on only once and when all of them have released then it will be
turned-off.

In this case it makes sense to use the atomic variables to track the requests
and release but what will happen to sysfs incase the device is released when the
last call to release has come from client4?Won't it lead to kernel panic or some
unwanted behaviour?


 Thanks and Regards,
 Arun R Murthy
 --
--
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: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data

2012-10-01 Thread Andy Shevchenko
On Thu, 2012-09-27 at 16:03 +0530, Vinod Koul wrote: 
 On Thu, 2012-09-27 at 15:36 +0530, Vinod Koul wrote:
  On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote:
   Not all of the controllers support the 64 bit data width. Make it 
   configurable
   via platform data. The driver will try to get a value from the component
   parameters, otherwise it will use the platform data.
   
  What was this gen against, I can apply this.
 %s/can/can't
Today I got what was happened. I sent an update to one patch of the
series, but you tried to apply it on top of previous version. It seems I
was not clear. So, now we have a regression, and I will send a fix soon
today.


-- 
Andy Shevchenko andriy.shevche...@linux.intel.com
Intel Finland Oy
--
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: [tpmdd-devel] [PATCH] TPM: Let the tpm char device be openable multiple times

2012-10-01 Thread Peter.Huewe
Hi Jason,

one quick question:
-   TPM_BUFSIZE = 4096,
[...]
+   u8 data_bufferx[2048];

Why do you half the buffer size?

Thanks,
Peter
--
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: kernel BUG at fs/buffer.c:3205 (stable 3.5.3)

2012-10-01 Thread Jan Kara
On Sat 29-09-12 21:07:27, Alexander Holler wrote:
 Am 27.09.2012 22:03, schrieb Jan Kara:
 On Thu 27-09-12 17:46:48, Alexander Holler wrote:
 Hello,
 
 Am 27.09.2012 17:12, schrieb Jan Kara:
Just some thoughts about your oops:
 The assertion which fails is:
 BUG_ON(!list_empty(bh-b_assoc_buffers));
 
 Now b_assoc_buffers isn't used very much. In particular ext4 which you seem
 to be using doesn't use this list at all (except when mounted in nojournal
 mode but that doesn't seem to be your case). That would point rather
 strongly at a memory corruption issue.
 
 So if you can reproduce the oops, it might be interesting to print
 bh-b_assoc_buffers.next and bh-b_assoc_buffers.next if the list is found
 to be non-empty.
 
 Hmm, a loose pointer would explain it all too. Especially the cases
 when I just have seen wrong content in the archive without having
 any oops. I try to reproduce it with
 
 pr_info(AHO: %p %p\n, bh-b_assoc_buffers.next,
 bh-b_assoc_buffers.next);
 after the BUG_ON().
It should have been:
  if (!list_empty(bh-b_assoc_buffers))
  pr_info(AHO: %p %p\n, bh-b_assoc_buffers.next,
  bh-b_assoc_buffers.next);
*before* BUG_ON().
 
What you saw in the logs were just pointers showing the list is empty
 (naturally as otherwise we'd see the BUG_ON trigger).
 
 Yes, I've already wondered what you want to read in the output. ;)
 
 Btw. I've just had that bug while doing sha1sum /dev/sr0, where sr0
 is a dvd-writer attached to a sata-port. No USB involved. Before the
 sha1sum I did an mbuffer  /dev/sr0 | bzip2smp foo.iso.bz2. But
 that needed only a few minutes (8GB) and I haven't had any throttle
 events or similiar, so Idon't think the cpu (or whatever) got hot.
 
 -
 Sep 29 20:38:20 krabat kernel: [ 1652.879952] [ cut here
 ]
 Sep 29 20:38:20 krabat kernel: [ 1652.879956] kernel BUG at
 fs/buffer.c:3199!
 Sep 29 20:38:20 krabat kernel: [ 1652.879957] invalid opcode:  [#1] SMP
 Sep 29 20:38:20 krabat kernel: [ 1652.879959] CPU 2
 Sep 29 20:38:20 krabat kernel: [ 1652.879960] Modules linked in: nfs
 rfcomm fuse hidp ebtable_nat ebtables ipt_MASQUERADE xt_CHECKSUM
 iptable_mangle iptable_nat nf_nat bridge stp llc it87 hwmon_vid
 ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter
 ip6_tables xt_physdev ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4
 xt_state nf_conntrack iptable_filter btusb bluetooth rfkill joydev
 hid_logitech ff_memless usbhid pata_jmicron binfmt_misc usb_storage
 uas virtio_blk virtio_net virtio_balloon virtio_pci virtio_ring
 virtio vhost_net tun macvtap macvlan snd_hda_codec_hdmi
 snd_hda_codec_realtek coretemp kvm_intel snd_hda_intel snd_hda_codec
 kvm snd_hwdep uhci_hcd uinput snd_seq crc32c_intel snd_seq_device
 sr_mod snd_pcm xhci_hcd cdrom i7core_edac microcode ehci_hcd
 snd_page_alloc dm_mod edac_core fglrx(PO) r8169 snd_timer lpc_ich
 mii snd jmicron mfd_core soundcore agpgart usbcore usb_common nfsd
 nfs_acl auth_rpcgss lockd sunrpc ipv6 [last unloaded:
 scsi_wait_scan]
 Sep 29 20:38:20 krabat kernel: [ 1652.879992]
 Sep 29 20:38:20 krabat kernel: [ 1652.879993] Pid: 4670, comm:
 sha1sum Tainted: P   O 3.5.4-9-gfa43f23-dirty #228
  BTW, fglrx moodule taints the kernel because it is a proprietary driver.
Can you reproduce the issue without this module loaded?

Honza

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


GFS2: Pull request (merge window)

2012-10-01 Thread Steven Whitehouse
Hi,

Please consider pulling the following changes,

Steve.

---

The major feature this time is the rbm conversion in the resource
group code. The new struct gfs2_rbm specifies the location of an
allocatable block in (resource group, bitmap, offset) form. There
are a number of added helper functions, and later patches then
rewrite some of the resource group code in terms of this new
structure. Not only does this give us a nice code clean up, but 
it also removes some of the previous restructions where extents
could not cross bitmap boundaries, for example.

In addition to that, there are a few bug fixes and clean ups, but
the rbm work is by far the majority of this patch set in terms of
number of changed lines.

---

The following changes since commit 979570e02981d4a8fc20b3cc8fd651856c98ee9d:

  Linux 3.6-rc7 (2012-09-23 18:10:57 -0700)

are available in the git repository at:
  git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-3.0-nmw.git master

Benjamin Marzinski (1):
  GFS2: Write out dirty inode metadata in delayed deletes

Bob Peterson (9):
  GFS2: rbm code cleanup
  GFS2: change function gfs2_direct_IO to use a normal gfs2_glock_dq
  GFS2: inline __gfs2_glock_schedule_for_reclaim
  GFS2: Combine functions gfs2_glock_wait and wait_on_holder
  GFS2: Combine functions gfs2_glock_dq_wait and wait_on_demote
  GFS2: Eliminate redundant calls to may_grant
  GFS2: Eliminate unnecessary check for state  3 in bitfit
  GFS2: Stop block extents at the end of bitmaps
  GFS2: Fix infinite loop in rbm_find

Eric Sandeen (1):
  GFS2: fix s_writers.counter imbalance in gfs2_ail_empty_gl

Jan Kara (1):
  GFS2: Get rid of I_MUTEX_QUOTA usage

Michel Lespinasse (1):
  GFS2: Use RB_CLEAR_NODE() rather than rb_init_node()

Steven Whitehouse (14):
  GFS2: Merge two nearly identical xattr functions
  GFS2: Remove rs_requested field from reservations
  GFS2: Add structure to contain rgrp, bitmap, offset tuple
  GFS2: Replace rgblk_search with gfs2_rbm_find
  GFS2: Update gfs2_get_block_type() to use rbm
  GFS2: Update rgblk_free() to use rbm
  GFS2: Fix case where reservation finished at end of rgrp
  GFS2: Use rbm for gfs2_testbit()
  GFS2: Use rbm for gfs2_setbit()
  GFS2: Fix -show_options() for statfs slow
  GFS2: Fall back to ignoring reservations, if there are no other blocks 
left
  GFS2: Improve block reservation tracing
  GFS2: Fix unclaimed_blocks() wrapping bug and clean up
  GFS2: Consolidate free block searching functions

 fs/gfs2/aops.c   |   11 +-
 fs/gfs2/bmap.c   |2 +-
 fs/gfs2/file.c   |4 +-
 fs/gfs2/glock.c  |   60 +--
 fs/gfs2/glops.c  |1 +
 fs/gfs2/incore.h |   30 +-
 fs/gfs2/inode.c  |   20 +-
 fs/gfs2/ops_fstype.c |8 +
 fs/gfs2/quota.c  |   11 +-
 fs/gfs2/rgrp.c   | 1203 --
 fs/gfs2/rgrp.h   |   28 +-
 fs/gfs2/super.c  |9 +-
 fs/gfs2/trace_gfs2.h |   20 +-
 fs/gfs2/trans.h  |7 +-
 fs/gfs2/xattr.c  |   96 ++---
 15 files changed, 710 insertions(+), 800 deletions(-)



signature.asc
Description: This is a digitally signed message part


Re: CONFIG_EXPERT is a booby trap

2012-10-01 Thread Mikael Pettersson
Tim Shepard writes:
  This weekend I finally figured out why the keyboard in my MacBook Pro
  stopped working between 3.4 and 3.5.
  
  When I turned on CONFIG_EXPERT it turned off CONFIG_HID_APPLE.  There
  was no warning that selecting Configure standard kernel features will
  invisibly turn off needed things elsewhere in the configuration tree.
  
  Something needs to be fixed, but it's not obvious that any simple change
  will work without causing other troubles.

diff the before and after .config files.  That's alerted me to unexpected
changes (not just where did CONFIG_${foo} go? but also wtf is CONFIG_${bar}
doing there?) on numerous occasions.
--
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 V2 3/3] workqueue: Schedule work on non-idle cpu instead of current one

2012-10-01 Thread Vincent Guittot
On 1 October 2012 05:47, Viresh Kumar viresh.ku...@linaro.org wrote:
 On 1 October 2012 06:02, Tejun Heo t...@kernel.org wrote:
 It isn't about the CPU being actually idle?

 No. Being idle only from scheduler's perspective. :)

 Also, if it's only about timers, shouldn't it be enough to implement
 it for timer and delayed_work?

 What if we need a timer, which must re-arm itself + schedule a work?
 delayed_work will not be sufficient in that case, and we would need
 to use normal work.

 If i am not wrong, there can be other future users of this routine too.
 @Vincent: Can you please comment on this?

The goal is to consolidate the place, where the selection of a target
CPU for running something is done. The scheduler should select the CPU
in order to have coherent behaviour of all framework.

A delayed work can be delayed for a long period and the target CPU
that have been selected for the timer could not be the best place to
queue a work any more.

The goal is to be able to migrate a work if the scheduler thinks that'
is necessary.

Vincent


 It would be great if you explain what you're trying to achieve how.  I
 can't tell what you're aiming for and why that would be beneficial
 from these submissions.

 Following slides are implemented by Vincent and presented during LPC.
 Please have a look at them, they explain the problem statement well:

 http://www.linuxplumbersconf.org/2012/wp-content/uploads/2012/08/lpc2012-sched-timer-workqueue.pdf

 Specifically slides: 12  19.

 There aren't too many users with this behavior, but even a single user
 will be sufficient not to let the cpu get idle at all. And that will result in
 less power saving.

 --
 viresh
--
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: [PATCHv4 1/4] modem_shm: Add Modem Access Framework

2012-10-01 Thread Arun MURTHY
+int modem_release(struct modem_desc *mdesc) {
+   if (!mdesc-release)
+   return -EFAULT;
+
+   if (modem_is_requested(mdesc)) {
+   atomic_dec(mdesc-mclients-cnt);
+   if (atomic_read(mdesc-use_cnt) == 1) {
+   mdesc-release(mdesc);
+   atomic_dec(mdesc-use_cnt);
+   }
  
   Eeek, why aren't you using the built-in reference counting that
   the struct device provided to you, and instead are rolling your own?
   This happens in many places, why?
  
   My usage of counters over here is for each modem there are many
 clients.
   Each of the clients will have a ref to modem_desc. Each of them use
   this for requesting and releasing the modem. One counter for
   tracking the request and release for each client which is done by
   variable 'cnt' in
  struct clients.
   The counter use_cnt is used for tracking the modem request/release
   irrespective of the clients and counter cli_cnt is used for
   restricting the modem_get to the no of clients defined in no_clients.
  
   So totally 3 counter one for restricting the usage of modem_get by
   clients, second for restricting modem request/release at top level,
   and 3rd for restricting modem release/request for per client per
   modem
  basis.
  
   Can you let me know if the same can be achieved by using built-in
   ref counting?
  Is this your model:
  You have a modem device which can be requested by many clients.This
  clients can register for a particular service which this modem
  provides and then after that if it client doesn't need this service then 
  it will
 call un-register.
 
  Let me correct a bit over here:
  There are many clients, yes correct but the operations performed are
  only two, i.e modem request and modem release. This is something like
  waking up the modem and let modem to sleep.
  The traffic of this request and release is too high.
 
  So irrespective of the requests/releases made to the MAF framework,
  the MAF should perform the operation request/release only once.
 
  So each and every time handling list consumes time.
  Let me brief the context, this is a single chip modem and ape,
  basically used in mobile, tablets etc. So the traffic in ape-modem
  communication is too high and also time critical. If it bound to
  exceed the time, or delay might end up in buffer full. That’s the reason I
 have made it as simple as possible.
 
 So let me put it this way:
Modem Client1 Client2Client3Client4
 State  turn-on   request
 State  no-state-change request
 State  no-state-change   request
 State  no-state-change
 request
 State  no-state-change  release
 State  no-state-change release
 State  no-state-change   release
 State   turn-off
   release
 
 So eventhough all the clients have requested the modem it is being turned
 on only once and when all of them have released then it will be turned-off.
 
 In this case it makes sense to use the atomic variables to track the requests
 and release but what will happen to sysfs incase the device is released when
 the last call to release has come from client4?Won't it lead to kernel panic 
 or
 some unwanted behaviour?


Yes, you are right, so will add a check in modem_put and modem_unregister
to check if modem is requested and if so will release first and then go ahead.
But actually clients are not suppose to call modem_put/modem_unregister
unless modem is released but yes, in MAF we can take this precaution.

Thanks and Regards,
Arun R Murthy
-
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 v4] media: v4l2-ctrls: add control for test pattern

2012-10-01 Thread Sakari Ailus

Hi Prabhakar,

Prabhakar wrote:

From: Lad, Prabhakar prabhakar@ti.com

add V4L2_CID_TEST_PATTERN of type menu, which determines
the internal test pattern selected by the device.

Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Acked-by: Sakari Ailus sakari.ai...@iki.fi
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Hans de Goede hdego...@redhat.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Rob Landley r...@landley.net
---
  This patches has one checkpatch warning for line over
  80 characters altough it can be avoided I have kept it
  for consistency.

  Changes for v4:
  1: Fixed some grammar/style issues, pointed by Hans.

  Changes for v3:
  1: Removed the menu for test pattern, pointed by Sakari.

  Changes for v2:
  1: Included display devices in the description for test pattern
as pointed by Hans.
  2: In the menu replaced 'Test Pattern Disabled' by 'Disabled' as
pointed by Sylwester.
  3: Removed the test patterns from menu as the are hardware specific
as pointed by Sakari.

  Documentation/DocBook/media/v4l/controls.xml |   10 ++
  drivers/media/v4l2-core/v4l2-ctrls.c |2 ++
  include/linux/videodev2.h|1 +
  3 files changed, 13 insertions(+), 0 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/controls.xml 
b/Documentation/DocBook/media/v4l/controls.xml
index f0fb08d..5450d31 100644
--- a/Documentation/DocBook/media/v4l/controls.xml
+++ b/Documentation/DocBook/media/v4l/controls.xml
@@ -4313,6 +4313,16 @@ interface and may change in the future./para
  /tbody
/entrytbl
  /row
+ row
+   entry 
spanname=idconstantV4L2_CID_TEST_PATTERN/constant/entry
+   entrymenu/entry
+ /row
+ row id=v4l2-test-pattern
+   entry spanname=descr Some capture/display/sensor devices have
+   the capability to generate test pattern images. These hardware
+   specific test patterns can be used to test if a device is working
+   properly./entry
+ /row
rowentry/entry/row
/tbody
/tgroup
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c 
b/drivers/media/v4l2-core/v4l2-ctrls.c
index 8f2f40b..41b7732 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -740,6 +740,7 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_LINK_FREQ:return Link Frequency;
case V4L2_CID_PIXEL_RATE:   return Pixel Rate;
case V4L2_CID_DPCM_PREDICTOR:   return DPCM Predictor;
+   case V4L2_CID_TEST_PATTERN: return Test Pattern;

default:
return NULL;
@@ -841,6 +842,7 @@ void v4l2_ctrl_fill(u32 id, const char **name, enum 
v4l2_ctrl_type *type,
case V4L2_CID_EXPOSURE_METERING:
case V4L2_CID_SCENE_MODE:
case V4L2_CID_DPCM_PREDICTOR:
+   case V4L2_CID_TEST_PATTERN:
*type = V4L2_CTRL_TYPE_MENU;
break;
case V4L2_CID_LINK_FREQ:
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index ca9fb78..7014c0b 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -2005,6 +2005,7 @@ enum v4l2_dpcm_predictor {
V4L2_DPCM_PREDICTOR_SIMPLE  = 0,
V4L2_DPCM_PREDICTOR_ADVANCED= 1,
  };
+#define V4L2_CID_TEST_PATTERN  (V4L2_CID_IMAGE_PROC_CLASS_BASE 
+ 4)

  /*
   *T U N I N G



Acked-by: Sakari Ailus sakari.ai...@iki.fi

I'd suggest to rebase this under the DPCM predictor patch. As the choice of
the predictor affects the resulting format, it has to be the same on the
transmitter and the receiver, and also affects the in-memory pixel format.

I'll prepare an RFC on the topic shortly.

Kind regards,

--
Sakari Ailus
sakari.ai...@iki.fi
--
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: [tpmdd-devel] [PATCH] TPM: Issue TPM_STARTUP at driver load if the TPM has not been started

2012-10-01 Thread Peter.Huewe
Hi Jason,

 The TPM will respond to TPM_GET_CAP with TPM_ERR_INVALID_POSTINIT if
 TPM_STARTUP has not been issued. This will result in the TPM driver
 failing to load and no way to recover. Detect this and automatically
 issue TPM_STARTUP.

 This is for embedded applications where the kernel is the first thing
 to touch the TPM.

Thanks for working on this.
I also thought about this scenario quite often.

Shouldn't we then also add a TpmStartup(ST_STATE) in case of a resume?
 rc=GetCapability()
 if(rc==INVALID_POSTINIT)
tpm_transmit (TPM_STARTUP(ST_STATE))...

Thanks,
Peter
--
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: kernel BUG at fs/buffer.c:3205 (stable 3.5.3)

2012-10-01 Thread Alexander Holler

Hello,

Am 01.10.2012 11:10, schrieb Jan Kara:


sha1sum Tainted: P   O 3.5.4-9-gfa43f23-dirty #228

   BTW, fglrx moodule taints the kernel because it is a proprietary driver.


I know.


Can you reproduce the issue without this module loaded?


I will try it with a clean 3.6. Most of the 9 additional patches here 
are for ARM boxes, but anyway. I will need a few days.


Regards,

Alexander
--
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 04/13] kmem accounting basic infrastructure

2012-10-01 Thread Michal Hocko
Hi,

On Sun 30-09-12 17:47:50, Tejun Heo wrote:
[...]
   The hot path overhead is quite minimal - it doesn't do much more than
   indirecting one more time.  In terms of memory usage, it sure could
   lead to a bit more fragmentation but even if it gets to several megs
   per cgroup, I don't think that's something excessive.  So, there is
   overhead but I don't believe it to be prohibitive.
  
  Remember that users do not want to pay even something minimal when the
  feature is not needed.
 
 Yeah but, if we can get it down to, say, around 1% under most
 workloads for memcg users, it is quite questionable to introduce full
 hierarchical configuration to allow avoiding that, isn't it?

Remember that the kmem memory is still accounted to u+k if it is enabled
which could be a no-go because some workloads (I have provided an
example that those which are trusted are generally safe to ignore kernel
memory overhead) simply don't want to consider additional memory which
is mostly invisible for them.

   The distinction between trusted and untrusted is something
   artificially created due to the assumed deficiency of kmemcg
   implementation.  
  
  Not really. It doesn't have to do anything with the overhead (be it
  memory or runtime). It really boils down to do I need/want it at all.
  Why would I want to think about how much kernel memory is in use in the
  first place? Or do you think that user memory accounting should be
  deprecated?
 
 But you can apply the same do I need/want it at all question to the
 configuration parameter too.  

Yes but, as I've said, the global configuration parameter is too
coarse. You can have a mix of trusted and untrusted workloads at the
same machine (e.g. web server which is inherently untrusted) and trusted
(local batch jobs which just needs a special LRU aging).

 I can see your point but the decision seems muddy to me, and if muddy,
 I prefer to err on the side of being too conservative.
 
   This is userland visible API.  
  
  I am not sure which API visible part you have in mind but
  kmem.limit_in_bytes will be there whether we go with global knob or no
  limit no accounting approach. 
 
 I mean full hierarchical configuration of it.  It becomes something
 which each memcg user cares about instead of something which the base
 system / admin flips on system boot.
 
   We can always expand the flexibility.  Let's do the simple thing
   first.  As an added bonus, it would enable using static_keys for
   accounting branches too.
  
  While I do agree with you in general and being careful is at place in
  this area as time shown several times, this seems to be too restrictive
  in this particular case.
  We won't save almost no code with the global knob so I am not sure
  what we are actually saving here. Global knob will just give us all or
  nothing semantic without making the whole thing simpler. You will stick
  with static branches and checkes whether the group accountable anyway,
  right?
 
 The thing is about the same argument can be made about .use_hierarchy
 too.  It doesn't necessarily make the code much harier.  Especially
 because the code is structured with that feature on mind, removing
 .use_hierarchy might not remove whole lot of code; however, the wider
 range of behavior which got exposed through that poses a much larger
 problem when we try to make modifications on related behaviors.  We
 get a lot more locked down by seemingly not too much code and our long
 term maintainability / sustainability suffers as a result.

I think that comparing kmem accounting with use_hierarchy is not fair.
Glauber tried to explain why already so I will not repeat it here.
I will just mention one thing. use_hierarchy has been introduces becuase
hierarchies were expensive at the time. kmem accounting is about should
we do u or u+k accounting. So there is a crucial difference.
 
 I'm not trying to say this is as bad as .use_hierarchy but want to
 point out that memcg and cgroup in general have had pretty strong
 tendency to choose overly flexible and complex designs and interfaces
 and it's probably about time we become more careful especially about
 stuff which is visible to userland.

That is right but I think that the current discussion shows that a mixed
(kmem disabled and kmem enabled hierarchies) workloads are far from
being theoretical and a global knob is just too coarse. I am afraid we
will see we want that per hierarchy requests shortly and that would
just add a new confusion where global knob would complicate it
considerably (do we really want on/off/per_hierarchy global knob?).
-- 
Michal Hocko
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/


Re: tg3 driver upgrade (Linux 2.6.32 - 3.2) breaks IBM Bladecenter SoL

2012-10-01 Thread Michael Chan
On Fri, 2012-09-28 at 22:45 +0200, Ferenc Wagner wrote: 
 Hi,
 
 Upgrading the kernel on our HS20 blades resulted in their SoL (serial
 over LAN) connection being broken.  The disconnection happens when eth0
 (the interface involved in SoL) is brought up during the boot sequence.
 If I later ip link set eth0 down, then the connection is restored, but
 ip link set eth0 up breaks it again on 3.2.  ethtool -a, -c, -g, -k
 and -u show no difference; ethtool -i on the 2.6.32 kernel reports:
 
 driver: tg3
 version: 3.116
 firmware-version: 5704s-v3.38, ASFIPMIs v2.47
 bus-info: :05:01.0
 
 In the 3.2 kernel the driver version is 3.121.

2.6.32 to 3.2 is a big jump.  Can you narrow this down further?  It will
be hard for us to find a HS20 with 5704 to test this.  Thanks.


--
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/3] virtio_console:Merge struct buffer_token into struct port_buffer

2012-10-01 Thread Amit Shah
On (Tue) 25 Sep 2012 [15:47:15], sjur.brandel...@stericsson.com wrote:
 From: Sjur Brændeland sjur.brandel...@stericsson.com
 
 This merge reduces code size by unifying the approach for
 sending scatter-lists and regular buffers. Any type of
 write operation (splice, write, put_chars) will now allocate
 a port_buffer and send_buf() and free_buf() can always be used.

Thanks for this cleanup; I should've caught it at the review of the
virtio-trace patchset itself -- sorry for that.

 Signed-off-by: Sjur Brændeland sjur.brandel...@stericsson.com
 cc: Rusty Russell ru...@rustcorp.com.au
 cc: Michael S. Tsirkin m...@redhat.com
 cc: Amit Shah amit.s...@redhat.com
 cc: Linus Walleij linus.wall...@linaro.org
 cc: Masami Hiramatsu masami.hiramatsu...@hitachi.com
 ---
  drivers/char/virtio_console.c |  141 
 ++---
  1 files changed, 62 insertions(+), 79 deletions(-)
 
 diff --git a/drivers/char/virtio_console.c b/drivers/char/virtio_console.c
 index 8ab9c3d..f4f7b04 100644
 --- a/drivers/char/virtio_console.c
 +++ b/drivers/char/virtio_console.c
 @@ -111,6 +111,11 @@ struct port_buffer {
   size_t len;
   /* offset in the buf from which to consume data */
   size_t offset;
 +
 + /* If sgpages == 0 then buf is used, else sg is used */
 + unsigned int sgpages;
 +
 + struct scatterlist sg[1];
  };
  
  /*
 @@ -338,23 +343,46 @@ static inline bool use_multiport(struct ports_device 
 *portdev)
  
  static void free_buf(struct port_buffer *buf)
  {
 + int i;

unsigned int

 +
   kfree(buf-buf);

buf-buf isn't set to NULL in case sgpages is  0.  Please set
buf-buf to NULL (and initialise other fields to default values) in
alloc_buf() (and leave this as is).

 +
 + if (buf-sgpages)

This 'if' is not necessary; just having the for loop will do the right
thing.

 + for (i = 0; i  buf-sgpages; i++) {
 + struct page *page = sg_page(buf-sg[i]);
 + if (!page)
 + break;
 + put_page(page);
 + }
 +
   kfree(buf);
  }
  
 -static struct port_buffer *alloc_buf(size_t buf_size)
 +static struct port_buffer *alloc_buf(struct virtqueue *vq, size_t buf_size,
 +  int nrbufs)

Indentation is off.

  {
   struct port_buffer *buf;
 + size_t alloc_size;
  
 - buf = kmalloc(sizeof(*buf), GFP_KERNEL);
 + /* Allocate buffer and the scatter list */
 + alloc_size = sizeof(*buf) + sizeof(struct scatterlist) * nrbufs;
 + buf = kmalloc(alloc_size, GFP_ATOMIC);

This looks hacky, along with the 'struct scatterlist sg[1]' in
port_buffer above.  Use a pointer instead?  At the least, please
include a comment in struct port_buffer mentioning sg has to be the
last element in the struct.

   if (!buf)
   goto fail;
 - buf-buf = kzalloc(buf_size, GFP_KERNEL);
 +
 + buf-sgpages = nrbufs;
 + if (nrbufs  0)
 + return buf;
 +
 + buf-buf = kmalloc(buf_size, GFP_ATOMIC);

That's a lot of GFP_ATOMICS; even for the cases that don't need them.
Maybe add a gfp param that only allocates GFP_ATOMIC memory from
callers in interrupt context.  All existing code got switched to using
GFP_ATOMIC buffers as well, that's definitely not good.

   if (!buf-buf)
   goto free_buf;
   buf-len = 0;
   buf-offset = 0;
   buf-size = buf_size;
 +
 + /* Prepare scatter buffer for sending */
 + sg_init_one(buf-sg, buf-buf, buf_size);
   return buf;
  
  free_buf:
 @@ -476,52 +504,25 @@ static ssize_t send_control_msg(struct port *port, 
 unsigned int event,
   return 0;
  }
  
 -struct buffer_token {
 - union {
 - void *buf;
 - struct scatterlist *sg;
 - } u;
 - /* If sgpages == 0 then buf is used, else sg is used */
 - unsigned int sgpages;
 -};
 -
 -static void reclaim_sg_pages(struct scatterlist *sg, unsigned int nrpages)
 -{
 - int i;
 - struct page *page;
 -
 - for (i = 0; i  nrpages; i++) {
 - page = sg_page(sg[i]);
 - if (!page)
 - break;
 - put_page(page);
 - }
 - kfree(sg);
 -}
  
  /* Callers must take the port-outvq_lock */
  static void reclaim_consumed_buffers(struct port *port)
  {
 - struct buffer_token *tok;
 + struct port_buffer *buf;
   unsigned int len;
  
   if (!port-portdev) {
   /* Device has been unplugged.  vqs are already gone. */
   return;
   }
 - while ((tok = virtqueue_get_buf(port-out_vq, len))) {
 - if (tok-sgpages)
 - reclaim_sg_pages(tok-u.sg, tok-sgpages);
 - else
 - kfree(tok-u.buf);
 - kfree(tok);
 + while ((buf = virtqueue_get_buf(port-out_vq, len))) {
 + free_buf(buf);
   port-outvq_full = false;
   }
  }
  
 -static ssize_t __send_to_port(struct port 

Re: [PATCH 07/19] mm/mpol: Add MPOL_MF_NOOP

2012-10-01 Thread Michael Kerrisk
On Tue, Jul 31, 2012 at 9:12 PM, Peter Zijlstra a.p.zijls...@chello.nl wrote:
 From: Lee Schermerhorn lee.schermerh...@hp.com

 This patch augments the MPOL_MF_LAZY feature by adding a NOOP
 policy to mbind().  When the NOOP policy is used with the 'MOVE
 and 'LAZY flags, mbind() [check_range()] will walk the specified
 range and unmap eligible pages so that they will be migrated on
 next touch.

This patch is mistitled. The new flag is MPOL_NOOP. That made it
difficult to find the commit in linux-next. Does it make sense to fix
the patch title before this hits mainline?

Thanks,

Michael



-- 
Michael Kerrisk Linux man-pages maintainer;
http://www.kernel.org/doc/man-pages/
Author of The Linux Programming Interface, http://blog.man7.org/
--
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 05/11] x86/xen: Register resources required by kexec-tools

2012-10-01 Thread Jan Beulich
 On 28.09.12 at 18:21, Konrad Rzeszutek Wilk konrad.w...@oracle.com wrote:
 On Thu, Sep 27, 2012 at 08:06:32PM +0200, Daniel Kiper wrote:
 +for (i = 0; i  cpus; ++i) {
 
 Any specific reason for using '++i' instead of 'i++' ?

For people occasionally also writing C++ code this is the
canonical form.

Jan

--
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] media: mt9p031/mt9t001/mt9v032: use V4L2_CID_TEST_PATTERN for test pattern control

2012-10-01 Thread Laurent Pinchart
Hi Prabhakar,

Thanks for the patch.

On Monday 01 October 2012 13:31:59 Prabhakar wrote:
 From: Lad, Prabhakar prabhakar@ti.com
 
 Signed-off-by: Lad, Prabhakar prabhakar@ti.com
 Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
 Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Cc: Sakari Ailus sakari.ai...@iki.fi
 Cc: Paul Gortmaker paul.gortma...@windriver.com
 Cc: Jean Delvare kh...@linux-fr.org
 ---
  Changes for v3:
  1: Used cluster in mt9v032 for test pattern,
  pointed by Laurent.
 
  Changes for v2:
  1: Fixed review comments pointed by Laurent.
 
  drivers/media/i2c/mt9p031.c |   19 +++--
  drivers/media/i2c/mt9t001.c |   22 ++-
  drivers/media/i2c/mt9v032.c |   60 +---
  3 files changed, 58 insertions(+), 43 deletions(-)
 
 diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c
 index 2c0f407..e328332 100644
 --- a/drivers/media/i2c/mt9p031.c
 +++ b/drivers/media/i2c/mt9p031.c
 @@ -574,7 +574,6 @@ static int mt9p031_set_crop(struct v4l2_subdev *subdev,
   * V4L2 subdev control operations
   */
 
 -#define V4L2_CID_TEST_PATTERN(V4L2_CID_USER_BASE | 0x1001)
  #define V4L2_CID_BLC_AUTO(V4L2_CID_USER_BASE | 0x1002)
  #define V4L2_CID_BLC_TARGET_LEVEL(V4L2_CID_USER_BASE | 0x1003)
  #define V4L2_CID_BLC_ANALOG_OFFSET   (V4L2_CID_USER_BASE | 0x1004)
 @@ -740,18 +739,6 @@ static const char * const mt9p031_test_pattern_menu[] =
 { static const struct v4l2_ctrl_config mt9p031_ctrls[] = {
   {
   .ops= mt9p031_ctrl_ops,
 - .id = V4L2_CID_TEST_PATTERN,
 - .type   = V4L2_CTRL_TYPE_MENU,
 - .name   = Test Pattern,
 - .min= 0,
 - .max= ARRAY_SIZE(mt9p031_test_pattern_menu) - 1,
 - .step   = 0,
 - .def= 0,
 - .flags  = 0,
 - .menu_skip_mask = 0,
 - .qmenu  = mt9p031_test_pattern_menu,
 - }, {
 - .ops= mt9p031_ctrl_ops,
   .id = V4L2_CID_BLC_AUTO,
   .type   = V4L2_CTRL_TYPE_BOOLEAN,
   .name   = BLC, Auto,
 @@ -950,7 +937,7 @@ static int mt9p031_probe(struct i2c_client *client,
   mt9p031-model = did-driver_data;
   mt9p031-reset = -1;
 
 - v4l2_ctrl_handler_init(mt9p031-ctrls, ARRAY_SIZE(mt9p031_ctrls) + 5);
 + v4l2_ctrl_handler_init(mt9p031-ctrls, ARRAY_SIZE(mt9p031_ctrls) + 6);
 
   v4l2_ctrl_new_std(mt9p031-ctrls, mt9p031_ctrl_ops,
 V4L2_CID_EXPOSURE, MT9P031_SHUTTER_WIDTH_MIN,
 @@ -966,6 +953,10 @@ static int mt9p031_probe(struct i2c_client *client,
   v4l2_ctrl_new_std(mt9p031-ctrls, mt9p031_ctrl_ops,
 V4L2_CID_PIXEL_RATE, pdata-target_freq,
 pdata-target_freq, 1, pdata-target_freq);
 + v4l2_ctrl_new_std_menu_items(mt9p031-ctrls, mt9p031_ctrl_ops,
 +   V4L2_CID_TEST_PATTERN,
 +   ARRAY_SIZE(mt9p031_test_pattern_menu) - 1, 0,
 +   0, mt9p031_test_pattern_menu);
 
   for (i = 0; i  ARRAY_SIZE(mt9p031_ctrls); ++i)
   v4l2_ctrl_new_custom(mt9p031-ctrls, mt9p031_ctrls[i], NULL);
 diff --git a/drivers/media/i2c/mt9t001.c b/drivers/media/i2c/mt9t001.c
 index 6d343ad..2e189d8 100644
 --- a/drivers/media/i2c/mt9t001.c
 +++ b/drivers/media/i2c/mt9t001.c
 @@ -371,7 +371,7 @@ static int mt9t001_set_crop(struct v4l2_subdev *subdev,
   * V4L2 subdev control operations
   */
 
 -#define V4L2_CID_TEST_PATTERN(V4L2_CID_USER_BASE | 0x1001)
 +#define V4L2_CID_TEST_PATTERN_COLOR  (V4L2_CID_USER_BASE | 0x1001)
  #define V4L2_CID_BLACK_LEVEL_AUTO(V4L2_CID_USER_BASE | 0x1002)
  #define V4L2_CID_BLACK_LEVEL_OFFSET  (V4L2_CID_USER_BASE | 0x1003)
  #define V4L2_CID_BLACK_LEVEL_CALIBRATE   (V4L2_CID_USER_BASE | 0x1004)
 @@ -487,12 +487,11 @@ static int mt9t001_s_ctrl(struct v4l2_ctrl *ctrl)
ctrl-val  16);
 
   case V4L2_CID_TEST_PATTERN:
 - ret = mt9t001_set_output_control(mt9t001,
 + return mt9t001_set_output_control(mt9t001,
   ctrl-val ? 0 : MT9T001_OUTPUT_CONTROL_TEST_DATA,
   ctrl-val ? MT9T001_OUTPUT_CONTROL_TEST_DATA : 0);
 - if (ret  0)
 - return ret;
 
 + case V4L2_CID_TEST_PATTERN_COLOR:
   return mt9t001_write(client, MT9T001_TEST_DATA, ctrl-val  2);
 
   case V4L2_CID_BLACK_LEVEL_AUTO:
 @@ -533,12 +532,17 @@ static struct v4l2_ctrl_ops mt9t001_ctrl_ops = {
   .s_ctrl = mt9t001_s_ctrl,
  };
 
 +static const char * const mt9t001_test_pattern_menu[] = {
 + Disabled,
 + Enabled,
 +};
 +
  static const struct v4l2_ctrl_config mt9t001_ctrls[] = {
   {
   .ops= mt9t001_ctrl_ops,
 - 

Re: [PATCH v3 06/13] memcg: kmem controller infrastructure

2012-10-01 Thread Michal Hocko
On Sun 30-09-12 17:25:42, Tejun Heo wrote:
 On Fri, Sep 28, 2012 at 03:34:19PM +0400, Glauber Costa wrote:
  On 09/27/2012 05:44 PM, Michal Hocko wrote:
   Anyway, I have just noticed that __mem_cgroup_try_charge does
   VM_BUG_ON(css_is_removed(memcg-css)) on a given memcg so you should
   keep css ref count up as well.
  
  IIRC, css_get will prevent the cgroup directory from being removed.
  Because some allocations are expected to outlive the cgroup, we
  specifically don't want that.
 
 That synchronous ref draining is going away.  Maybe we can do that
 before kmemcg?  Michal, do you have some timeframe on mind?

It is on my todo list but I didn't get to it yet. I am not sure we can
get rid of css_get though - will have to think about that.

 
 Thanks.
 
 -- 
 tejun

-- 
Michal Hocko
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/


Re: [PATCH 07/19] mm/mpol: Add MPOL_MF_NOOP

2012-10-01 Thread Ingo Molnar

* Michael Kerrisk mtk.manpa...@gmail.com wrote:

 On Tue, Jul 31, 2012 at 9:12 PM, Peter Zijlstra a.p.zijls...@chello.nl 
 wrote:
  From: Lee Schermerhorn lee.schermerh...@hp.com
 
  This patch augments the MPOL_MF_LAZY feature by adding a 
  NOOP policy to mbind().  When the NOOP policy is used with 
  the 'MOVE and 'LAZY flags, mbind() [check_range()] will walk 
  the specified range and unmap eligible pages so that they 
  will be migrated on next touch.
 
 This patch is mistitled. The new flag is MPOL_NOOP. That made 
 it difficult to find the commit in linux-next. Does it make 
 sense to fix the patch title before this hits mainline?

In isolation such a minor title problem alone does not justify 
rebasing.

Thanks,

Ingo
--
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/5] dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER

2012-10-01 Thread Maarten Lankhorst
Op 28-09-12 21:42, Thomas Hellstrom schreef:
 On 09/28/2012 04:14 PM, Maarten Lankhorst wrote:
 Hey,

 Op 28-09-12 14:41, Maarten Lankhorst schreef:
 Documentation says that code requiring dma-buf should add it to
 select, so inline fallbacks are not going to be used. A link error
 will make it obvious what went wrong, instead of silently doing
 nothing at runtime.

   

 The whole patch series is in my tree, I use stg so things might
 move around, do not use for merging currently:

 http://cgit.freedesktop.org/~mlankhorst/linux/log/?h=v10-wip

 It contains everything in here plus the patches for ttm to make
 it work, I use a old snapshot of drm-next + merge of nouveau as
 base. Description of what the parts do:

 Series to fix small api issues when moving over:

 drm/ttm: Remove cpu_writers related code
 drm/ttm: Add ttm_bo_is_reserved function
 drm/radeon: Use ttm_bo_is_reserved
 drm/vmwgfx: use ttm_bo_is_reserved

 drm/vmwgfx: remove use of fence_obj_args
 drm/ttm: remove sync_obj_arg
 drm/ttm: remove sync_obj_arg from ttm_bo_move_accel_cleanup
 drm/ttm: remove sync_arg entirely

 drm/nouveau: unpin buffers before releasing to prevent lockdep warnings
 drm/nouveau: add reservation to nouveau_bo_vma_del
 drm/nouveau: add reservation to nouveau_gem_ioctl_cpu_prep

 Hey great, now we only have one user left for fence waiting before reserving,
 lets fix that and remove fence lock:
 ttm_bo_cleanup_refs_or_queue and ttm_bo_cleanup_refs have to reserve before
 waiting, lets do it in the squash commit so we don't have to throw lock order
 around everywhere:

 drm/ttm: remove fence_lock

 -- Up to this point should be mergeable now

 Then we start working on lru_lock removal slightly, this means the lru
 list no longer is empty but can contain only reserved buffers:

 drm/ttm: do not check if list is empty in ttm_bo_force_list_clean
 drm/ttm: move reservations for ttm_bo_cleanup_refs

 -- Still mergeable up to this point, just fixes

 Patch series from this email:
 dma-buf: remove fallback for !CONFIG_DMA_SHARED_BUFFER
 fence: dma-buf cross-device synchronization (v9)
 seqno-fence: Hardware dma-buf implementation of fencing (v3)
 reservation: cross-device reservation support
 reservation: Add lockdep annotation and selftests

 Now hook it up to drm/ttm in a few steps:
 usage around reservations:
 drm/ttm: make ttm reservation calls behave like reservation calls
 drm/ttm: use dma_reservation api
 dma-buf: use reservations
 drm/ttm: allow drivers to pass custom dma_reservation_objects for a bo

 then kill off the lru lock around reservation:
 drm/ttm: remove lru_lock around ttm_bo_reserve
 drm/ttm: simplify ttm_eu_*

 The lru_lock removal patch removes the lock around lru_lock around the
 reservation, this will break the assumption that items on the lru list
 and swap list can always be reserved, and this gets patched up too.
 Is there any part in ttm you disagree with? I believe that this
 is all mergeable, the lru_lock removal patch could be moved to before
 the reservation parts, this might make merging easier, but I don't
 think there is any ttm part of the series that are wrong on a conceptual
 level.

 ~Maarten

 From another email

 As previously discussed, I'm unfortunately not prepared to accept removal 
 of the reserve-lru atomicity
   into the TTM code at this point.
 The current code is based on this assumption and removing it will end up 
 with
 efficiencies, breaking the delayed delete code and probably a locking 
 nightmare when trying to write
 new TTM code.
 The lru lock removal patch fixed the delayed delete code, it really is not 
 different from the current
 situation. In fact it is more clear without the guarantee what various parts 
 are trying to protect.

 Nothing prevents you from holding the lru_lock while trylocking,
 [1]
 While this would not cause any deadlocks, Any decent lockdep code would 
 establish lru-reserve as the locking
 order once a lru- reserve trylock succeeds, but the locking order is really 
 reserve-lru for obvious reasons, which
 means we will get a lot of lockdep errors? Yes, there are a two reversals 
 like these already in the TTM code, and I'm
 not very proud of them.
I was doing a evil hack where I 'released' lru_lock to lockdep before doing the 
annotation
for a blocking acquire, and left trylock annotations as they were. This made 
lockdep do the
right thing.
 And this is even before it starts to get interesting, like how you guarantee 
 that when you release a buffer from
 the delayed delete list, you're the only process having a reference?
l thought list_kref made sure of that? Even if not the only one with a 
reference, the list_empty check would
make sure it would only run once. I'l fix it up again so it doesn't become a 
WARN_ON_ONCE, I didn't know
it could run multiple times at the time, so I'll change it back to unlikely.

 Now, it's probably possible to achieve what you're trying to do, if we accept 
 the lock reversal in
 [1], but since I have 

Re: [PATCH v3 06/13] memcg: kmem controller infrastructure

2012-10-01 Thread Michal Hocko
On Fri 28-09-12 15:34:19, Glauber Costa wrote:
 On 09/27/2012 05:44 PM, Michal Hocko wrote:
   the reference count aquired by mem_cgroup_get will still prevent the
   memcg from going away, no?
  Yes but you are outside of the rcu now and we usually do css_get before
  we rcu_unlock. mem_cgroup_get just makes sure the group doesn't get
  deallocated but it could be gone before you call it. Or I am just
  confused - these 2 levels of ref counting is really not nice.
  
  Anyway, I have just noticed that __mem_cgroup_try_charge does
  VM_BUG_ON(css_is_removed(memcg-css)) on a given memcg so you should
  keep css ref count up as well.
  
 
 IIRC, css_get will prevent the cgroup directory from being removed.
 Because some allocations are expected to outlive the cgroup, we
 specifically don't want that.

Yes, but how do you guarantee that the above VM_BUG_ON doesn't trigger?
Task could have been moved to another group between mem_cgroup_from_task
and mem_cgroup_get, no?
-- 
Michal Hocko
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/


Re: [PATCH 1/4] mfd: ab8500: add devicetree support for fuelgauge

2012-10-01 Thread Lee Jones
On Mon, 01 Oct 2012, Rajanikanth H.V wrote:

 From: Rajanikanth H.V rajanikanth...@stericsson.com
 
 - This patch adds device tree support for fuelguage driver
 - optimize bm devices platform_data usage and of_probe(...)
   Note: of_probe() routine for battery managed devices is made
   common across all bm drivers.
 
 Signed-off-by: Rajanikanth H.V rajanikanth...@stericsson.com
 ---
  Documentation/devicetree/bindings/mfd/ab8500.txt   |8 +-
  .../devicetree/bindings/power_supply/ab8500/fg.txt |   86 +++
  arch/arm/boot/dts/dbx5x0.dtsi  |   22 +-
  drivers/mfd/ab8500-core.c  |1 +
  drivers/power/Makefile |2 +-
  drivers/power/ab8500_bmdata.c  |  549 
 
  drivers/power/ab8500_btemp.c   |4 +-
  drivers/power/ab8500_charger.c |4 +-
  drivers/power/ab8500_fg.c  |   76 ++-
  drivers/power/abx500_chargalg.c|4 +-
  include/linux/mfd/abx500.h |   37 +-
  include/linux/mfd/abx500/ab8500-bm.h   |7 +
  12 files changed, 744 insertions(+), 56 deletions(-)
  create mode 100644 
 Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
  create mode 100644 drivers/power/ab8500_bmdata.c
 
 diff --git a/Documentation/devicetree/bindings/mfd/ab8500.txt 
 b/Documentation/devicetree/bindings/mfd/ab8500.txt
 index ce83c8d..762dc11 100644
 --- a/Documentation/devicetree/bindings/mfd/ab8500.txt
 +++ b/Documentation/devicetree/bindings/mfd/ab8500.txt
 @@ -24,7 +24,13 @@ ab8500-bm:  :  
 : Battery Manager
  ab8500-btemp :  :  : Battery 
 Temperature
  ab8500-charger   :  :  : Battery 
 Charger
  ab8500-codec :  :  : Audio Codec
 -ab8500-fg:  :  : Fuel Gauge
 +ab8500-fg:   : vddadc   : Fuel Gauge
 +  : NCONV_ACCU   :  : Accumulate N 
 Sample Conversion
 +  : BATT_OVV :  : Battery Over 
 Voltage
 +  : LOW_BAT_F:  : LOW threshold 
 battery voltage
 +  : CC_INT_CALIB :  : Counter 
 Counter Internal Calibration

I think you mean: Coulomb Counter.

 +  : CCEOC:  : Coulomb 
 Counter End of Conversion
 +  :  :  :

Random empty entry.

  ab8500-gpadc : HW_CONV_END  : vddadc   : Analogue to 
 Digital Converter
 SW_CONV_END  :  :
  ab8500-gpio  :  :  : GPIO 
 Controller
 diff --git a/Documentation/devicetree/bindings/power_supply/ab8500/fg.txt 
 b/Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
 new file mode 100644
 index 000..caa33b0
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
 @@ -0,0 +1,86 @@
 +=== AB8500 Fuel Gauge Driver ===
 +
 +AB8500 is a mixed signal multimedia and power management
 +device comprising: power and energy-management-module,
 +wall-charger, usb-charger, audio codec, general purpose adc,
 +tvout, clock management and sim card interface.
 +
 +Fuel-guage support is part of energy-management-module, the other

Spelling.

 +components of this module are:
 +main-charger, usb-combo-charger and Battery temperature monitoring.
 +
 +The properties below describes the node for fuel guage driver.

Spelling.

 +
 +Required Properties:
 +- compatible = stericsson,ab8500-fg
 +- interface-name:
 + Name of the controller/driver which is part of energy-management-module
 +- supplied-to:

Still not sure about this property, or your justification for use.

 + This property shall have dependent nodes which represent other
 + energy-management-module.

Plural?

 + This is a logical binding w.r.t power supply events

Proper English please, no slang.

 + across energy-management-module drivers where-in, the

Ill placed comma?

 + runtime battery properties are shared along with uevent
 + notification.

Plural?

 + ref: di-fg.external_power_changed =
 + ab8500_fg_external_power_changed;
 + ab8500_fg.c
 +
 + Need for this property:
 + energy-management-module driver updates power-supply properties
 + which are subset of events listed in 'enum 
 power_supply_property',
 + ref: power_supply.h file
 + Event handler invokes power supply change notifier
 + which in-turn invokes registered power supply class call-back
 + based on the 'supplied-to' string.
 + 

Re: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data

2012-10-01 Thread Vinod Koul
On Mon, 2012-10-01 at 12:04 +0300, Andy Shevchenko wrote:
 On Thu, 2012-09-27 at 16:03 +0530, Vinod Koul wrote: 
  On Thu, 2012-09-27 at 15:36 +0530, Vinod Koul wrote:
   On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote:
Not all of the controllers support the 64 bit data width. Make it 
configurable
via platform data. The driver will try to get a value from the component
parameters, otherwise it will use the platform data.

   What was this gen against, I can apply this.
  %s/can/can't
 Today I got what was happened. I sent an update to one patch of the
 series, but you tried to apply it on top of previous version. It seems I
 was not clear. So, now we have a regression, and I will send a fix soon
 today.
I received a series, and a patch on top and that what I tried to
apply :(
I am okay to revert the whole series now.

Please send me fix by today, merge window has started, I hate to change
stuff now.



-- 
~Vinod

--
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: [PATCHv5 2/3] virtio_console: Add support for remoteproc serial

2012-10-01 Thread Amit Shah
On (Tue) 25 Sep 2012 [15:47:16], sjur.brandel...@stericsson.com wrote:

 +static DEFINE_SPINLOCK(dma_bufs_lock);
 +static LIST_HEAD(pending_free_dma_bufs);
 +
  static void free_buf(struct port_buffer *buf)
  {
   int i;
 + unsigned long flags;
  
 - kfree(buf-buf);
 + if (!buf-dev)
 + kfree(buf-buf);

Doesn't hurt to just kfree a NULL pointer; so check is not needed.

 - if (buf-sgpages)
 + if (buf-sgpages) {
   for (i = 0; i  buf-sgpages; i++) {
   struct page *page = sg_page(buf-sg[i]);
   if (!page)
   break;
   put_page(page);
   }
 + return;
 + }

No kfree(buf)?

 + if (buf-dev  is_rproc_enabled) {
 +
 + /* dma_free_coherent requires interrupts to be enabled. */
 + if (irqs_disabled()) {
 + /* queue up dma-buffers to be freed later */
 + spin_lock_irqsave(dma_bufs_lock, flags);
 + list_add_tail(buf-list, pending_free_dma_bufs);
 + spin_unlock_irqrestore(dma_bufs_lock, flags);
 + return;
 + }
 + dma_free_coherent(buf-dev, buf-size, buf-buf, buf-dma);
 +
 + /* Release device refcnt and allow it to be freed */
 + might_sleep();
 + put_device(buf-dev);
 + }
  
   kfree(buf);
  }
  
 +static void reclaim_dma_bufs(void)
 +{
 + unsigned long flags;
 + struct port_buffer *buf, *tmp;
 + LIST_HEAD(tmp_list);
 +
 + WARN_ON(irqs_disabled());
 + if (list_empty(pending_free_dma_bufs))
 + return;
 +
 + BUG_ON(!is_rproc_enabled);
 +
 + /* Create a copy of the pending_free_dma_bufs while holding the lock*/
 + spin_lock_irqsave(dma_bufs_lock, flags);
 + list_cut_position(tmp_list, pending_free_dma_bufs,
 +   pending_free_dma_bufs.prev);
 + spin_unlock_irqrestore(dma_bufs_lock, flags);
 +
 + /* Release the dma buffers, without irqs enabled */
 + list_for_each_entry_safe(buf, tmp, tmp_list, list) {
 + list_del(buf-list);
 + free_buf(buf);
 + }
 +}
 +
  static struct port_buffer *alloc_buf(struct virtqueue *vq, size_t buf_size,
int nrbufs)
  {
   struct port_buffer *buf;
   size_t alloc_size;
  
 + if (is_rproc_serial(vq-vdev)  !irqs_disabled())
 + reclaim_dma_bufs();
 +
   /* Allocate buffer and the scatter list */
   alloc_size = sizeof(*buf) + sizeof(struct scatterlist) * nrbufs;
 - buf = kmalloc(alloc_size, GFP_ATOMIC);
 + buf = kzalloc(alloc_size, GFP_ATOMIC);

Why change from kmalloc to kzalloc?  It's better to split out such
changes into separate patch for easier review.

   if (!buf)
   goto fail;
  
 @@ -374,11 +444,30 @@ static struct port_buffer *alloc_buf(struct virtqueue 
 *vq, size_t buf_size,
   if (nrbufs  0)
   return buf;
  
 - buf-buf = kmalloc(buf_size, GFP_ATOMIC);
 + if (is_rproc_serial(vq-vdev)) {
 + /*
 +  * Allocate DMA memory from ancestor. When a virtio
 +  * device is created by remoteproc, the DMA memory is
 +  * associated with the grandparent device:
 +  * vdev = rproc = platform-dev.
 +  * The code here would have been less quirky if
 +  * DMA_MEMORY_INCLUDES_CHILDREN had been supported
 +  * in dma-coherent.c
 +  */
 + if (!vq-vdev-dev.parent || !vq-vdev-dev.parent-parent)
 + goto free_buf;
 + buf-dev = vq-vdev-dev.parent-parent;
 +
 + /* Increase device refcnt to avoid freeing it*/

missing space before */

 + get_device(buf-dev);
 + buf-buf = dma_alloc_coherent(buf-dev, buf_size, buf-dma,
 +   GFP_ATOMIC);
 + } else {
 + buf-buf = kmalloc(buf_size, GFP_ATOMIC);
 + }
 +
   if (!buf-buf)
   goto free_buf;
 - buf-len = 0;
 - buf-offset = 0;

As noted in a comment to previous patch, please use kmalloc and
explicit initialisation of variables.

   buf-size = buf_size;
  
   /* Prepare scatter buffer for sending */
 @@ -838,6 +927,10 @@ static ssize_t port_fops_splice_write(struct 
 pipe_inode_info *pipe,
   .u.data = sgl,
   };
  
 + /* rproc_serial does not support splice */
 + if (is_rproc_serial(port-out_vq-vdev))
 + return -EINVAL;

Will something break if this is not done?


Amit
--
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/3] virtio_console:Merge struct buffer_token into struct port_buffer

2012-10-01 Thread Amit Shah
On (Wed) 26 Sep 2012 [09:48:12], Sjur BRENDELAND wrote:
   This merge reduces code size by unifying the approach for
   sending scatter-lists and regular buffers. Any type of
   write operation (splice, write, put_chars) will now allocate
   a port_buffer and send_buf() and free_buf() can always be used.
  
  Thanks!
  This looks much nicer and simpler. I just have some comments below.
 
 OK, good to hear that you agree to this kind of change. I'll do a respin
 of this patch fixing the issues you have pointed out.
 
static void free_buf(struct port_buffer *buf)
{
   + int i;
   +
 kfree(buf-buf);
  
  this should be done only when !buf-sgpages, or (see below)
 
 Agree, I'll put this statement in an else branch to the if-statement below.

Not necessary; see my comments in another mail.

   -static struct port_buffer *alloc_buf(size_t buf_size)
   +static struct port_buffer *alloc_buf(struct virtqueue *vq, size_t 
   buf_size,
   +  int nrbufs)
{
 struct port_buffer *buf;
   + size_t alloc_size;
  
   - buf = kmalloc(sizeof(*buf), GFP_KERNEL);
   + /* Allocate buffer and the scatter list */
   + alloc_size = sizeof(*buf) + sizeof(struct scatterlist) * nrbufs;
  
  This allocates one redundant sg entry when nrbuf  0,
  but I think it is OK. (just a comment)
 
 I did this on purpose for the sake of simplicity, but I can
 change this to something like:
alloc_size = sizeof(*buf) + sizeof(buf-sg) * max(nrbufs - 1, 1);
 
 
   + buf = kmalloc(alloc_size, GFP_ATOMIC);
  
  This should be kzalloc(), or buf-buf and others are not initialized,
  which will cause unexpected kfree bug at kfree(buf-buf) in free_buf.
 
 Agree, kzalloc() is better in this case. 

Not really -- one thing I've picked up from Rusty is to use kmallocs
and explicitly initialise values.  Then, missing such initialisations
(like in this case) will cause tools like valgrind to show the error
pretty quickly.

 if (!buf)
 goto fail;
   - buf-buf = kzalloc(buf_size, GFP_KERNEL);
   +
   + buf-sgpages = nrbufs;
   + if (nrbufs  0)
   + return buf;
   +
   + buf-buf = kmalloc(buf_size, GFP_ATOMIC);
  
  You can also use kzalloc here as previous code does.
  But if the reason why using kzalloc comes from the security,
  I think kmalloc is enough here, since the host can access
  all the guest pages anyway.
 
 With this new patch alloc_buf() is used both for both RX and TX.
 The out_vq did previously use malloc(). But I have preserved
 the legacy behavior for the in_vq by calling memset() in function
 fill_queue().

But we're dropping the memset/kzalloc anyway.

Amit
--
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] DMA: PL330: Balance module remove function with probe

2012-10-01 Thread Inderpal Singh
On 28 September 2012 16:28, Jassi Brar jassisinghb...@gmail.com wrote:
 On Fri, Sep 28, 2012 at 10:03 AM, Inderpal Singh
 inderpal.si...@linaro.org wrote:

 Now, if we have to check if any client is using the channel and then
 decide. We will have to traverse the channel list twice once to check
 the usage and second time to delete the nodes from the list if we go
 ahead with remove.
 The remove will look like below:

 @@ -3008,18 +3008,19 @@ static int __devexit pl330_remove(struct
 amba_device *adev)
 if (!pdmac)
 return 0;

 +   /* check if any client is using any channel */
 +   list_for_each_entry_safe(pch, _p, pdmac-ddma.channels,
 +   chan.device_node) {
 +
 +   if (pch-chan.client_count)
 +   return -EBUSY;
 +   }
 +
 The iteration doesn't have to be the 'safe' version here. Other than
 that it seems OK.

Ok. I will update the patch and send again.

Thanks,
Inder
--
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/4] mfd: ab8500: add devicetree support for fuelgauge

2012-10-01 Thread Rajanikanth HV
did you have a look at arnd and anton comments regarding
'supplied-to' and boolean property

On Monday 01 October 2012 03:19 PM, Lee Jones wrote:
 On Mon, 01 Oct 2012, Rajanikanth H.V wrote:
 
 From: Rajanikanth H.V rajanikanth...@stericsson.com

 - This patch adds device tree support for fuelguage driver
 - optimize bm devices platform_data usage and of_probe(...)
   Note: of_probe() routine for battery managed devices is made
   common across all bm drivers.

 Signed-off-by: Rajanikanth H.V rajanikanth...@stericsson.com
 ---
  Documentation/devicetree/bindings/mfd/ab8500.txt   |8 +-
  .../devicetree/bindings/power_supply/ab8500/fg.txt |   86 +++
  arch/arm/boot/dts/dbx5x0.dtsi  |   22 +-
  drivers/mfd/ab8500-core.c  |1 +
  drivers/power/Makefile |2 +-
  drivers/power/ab8500_bmdata.c  |  549 
 
  drivers/power/ab8500_btemp.c   |4 +-
  drivers/power/ab8500_charger.c |4 +-
  drivers/power/ab8500_fg.c  |   76 ++-
  drivers/power/abx500_chargalg.c|4 +-
  include/linux/mfd/abx500.h |   37 +-
  include/linux/mfd/abx500/ab8500-bm.h   |7 +
  12 files changed, 744 insertions(+), 56 deletions(-)
  create mode 100644 
 Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
  create mode 100644 drivers/power/ab8500_bmdata.c

 diff --git a/Documentation/devicetree/bindings/mfd/ab8500.txt 
 b/Documentation/devicetree/bindings/mfd/ab8500.txt
 index ce83c8d..762dc11 100644
 --- a/Documentation/devicetree/bindings/mfd/ab8500.txt
 +++ b/Documentation/devicetree/bindings/mfd/ab8500.txt
 @@ -24,7 +24,13 @@ ab8500-bm:  : 
  : Battery Manager
  ab8500-btemp :  :  : Battery 
 Temperature
  ab8500-charger   :  :  : Battery 
 Charger
  ab8500-codec :  :  : Audio Codec
 -ab8500-fg:  :  : Fuel Gauge
 +ab8500-fg:   : vddadc   : Fuel Gauge
 +  : NCONV_ACCU   :  : Accumulate N 
 Sample Conversion
 +  : BATT_OVV :  : Battery Over 
 Voltage
 +  : LOW_BAT_F:  : LOW threshold 
 battery voltage
 +  : CC_INT_CALIB :  : Counter 
 Counter Internal Calibration
 
 I think you mean: Coulomb Counter.
 
 +  : CCEOC:  : Coulomb 
 Counter End of Conversion
 +  :  :  :
 
 Random empty entry.
 
  ab8500-gpadc : HW_CONV_END  : vddadc   : Analogue 
 to Digital Converter
 SW_CONV_END  :  :
  ab8500-gpio  :  :  : GPIO 
 Controller
 diff --git a/Documentation/devicetree/bindings/power_supply/ab8500/fg.txt 
 b/Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
 new file mode 100644
 index 000..caa33b0
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/power_supply/ab8500/fg.txt
 @@ -0,0 +1,86 @@
 +=== AB8500 Fuel Gauge Driver ===
 +
 +AB8500 is a mixed signal multimedia and power management
 +device comprising: power and energy-management-module,
 +wall-charger, usb-charger, audio codec, general purpose adc,
 +tvout, clock management and sim card interface.
 +
 +Fuel-guage support is part of energy-management-module, the other
 
 Spelling.
 
 +components of this module are:
 +main-charger, usb-combo-charger and Battery temperature monitoring.
 +
 +The properties below describes the node for fuel guage driver.
 
 Spelling.
 
 +
 +Required Properties:
 +- compatible = stericsson,ab8500-fg
 +- interface-name:
 + Name of the controller/driver which is part of energy-management-module
 +- supplied-to:
 
 Still not sure about this property, or your justification for use.
 
 + This property shall have dependent nodes which represent other
 + energy-management-module.
 
 Plural?
 
 + This is a logical binding w.r.t power supply events
 
 Proper English please, no slang.
 
 + across energy-management-module drivers where-in, the
 
 Ill placed comma?
 
 + runtime battery properties are shared along with uevent
 + notification.
 
 Plural?
 
 + ref: di-fg.external_power_changed =
 + ab8500_fg_external_power_changed;
 + ab8500_fg.c
 +
 + Need for this property:
 + energy-management-module driver updates power-supply properties
 + which are subset of events listed in 'enum 
 power_supply_property',
 + ref: power_supply.h file
 + Event handler invokes 

Re: [PATCH v3 08/13] res_counter: return amount of charges after res_counter_uncharge

2012-10-01 Thread Michal Hocko
On Tue 18-09-12 18:04:05, Glauber Costa wrote:
 It is useful to know how many charges are still left after a call to
 res_counter_uncharge. 

 While it is possible to issue a res_counter_read
 after uncharge, this is racy. It would be better if uncharge itself
 would tell us what the current status is.

Well I am not sure how less racy it would be if you return the old
value. It could be out of date when you read it, right? (this is even
more visible with res_counter_uncharge_until)
res_counter_read_u64 uses locks only for 32b when your change could help
to reduce lock contention. Other than that it is just res_counter_member
which is one cmp and a dereference. Sure you safe something but it is
barely noticable I guess.

I am not saying I do not like this change I just think that the
above part of the changelog doesn't fit. So it would be much better if
you tell us why this is needed for your patchset because the usage is
not part of the patch.

 Since the current return value is void, we don't need to worry about
 anything breaking due to this change: nobody relied on that, and only
 users appearing from now on will be checking this value.
 
 Signed-off-by: Glauber Costa glom...@parallels.com
 CC: Michal Hocko mho...@suse.cz
 CC: Johannes Weiner han...@cmpxchg.org
 CC: Suleiman Souhlal sulei...@google.com
 CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com
 ---
  Documentation/cgroups/resource_counter.txt |  7 ---
  include/linux/res_counter.h| 12 +++-
  kernel/res_counter.c   | 20 +---
  3 files changed, 24 insertions(+), 15 deletions(-)
 
 diff --git a/Documentation/cgroups/resource_counter.txt 
 b/Documentation/cgroups/resource_counter.txt
 index 0c4a344..c4d99ed 100644
 --- a/Documentation/cgroups/resource_counter.txt
 +++ b/Documentation/cgroups/resource_counter.txt
 @@ -83,16 +83,17 @@ to work with it.
   res_counter-lock internally (it must be called with res_counter-lock
   held). The force parameter indicates whether we can bypass the limit.
  
 - e. void res_counter_uncharge[_locked]
 + e. u64 res_counter_uncharge[_locked]
   (struct res_counter *rc, unsigned long val)
  
   When a resource is released (freed) it should be de-accounted
   from the resource counter it was accounted to.  This is called
 - uncharging.
 + uncharging. The return value of this function indicate the amount
 + of charges still present in the counter.
  
   The _locked routines imply that the res_counter-lock is taken.
  
 - f. void res_counter_uncharge_until
 + f. u64 res_counter_uncharge_until
   (struct res_counter *rc, struct res_counter *top,
unsinged long val)
  
 diff --git a/include/linux/res_counter.h b/include/linux/res_counter.h
 index 7d7fbe2..4b173b6 100644
 --- a/include/linux/res_counter.h
 +++ b/include/linux/res_counter.h
 @@ -130,14 +130,16 @@ int res_counter_charge_nofail(struct res_counter 
 *counter,
   *
   * these calls check for usage underflow and show a warning on the console
   * _locked call expects the counter-lock to be taken
 + *
 + * returns the total charges still present in @counter.
   */
  
 -void res_counter_uncharge_locked(struct res_counter *counter, unsigned long 
 val);
 -void res_counter_uncharge(struct res_counter *counter, unsigned long val);
 +u64 res_counter_uncharge_locked(struct res_counter *counter, unsigned long 
 val);
 +u64 res_counter_uncharge(struct res_counter *counter, unsigned long val);
  
 -void res_counter_uncharge_until(struct res_counter *counter,
 - struct res_counter *top,
 - unsigned long val);
 +u64 res_counter_uncharge_until(struct res_counter *counter,
 +struct res_counter *top,
 +unsigned long val);
  /**
   * res_counter_margin - calculate chargeable space of a counter
   * @cnt: the counter
 diff --git a/kernel/res_counter.c b/kernel/res_counter.c
 index ad581aa..7b3d6dc 100644
 --- a/kernel/res_counter.c
 +++ b/kernel/res_counter.c
 @@ -86,33 +86,39 @@ int res_counter_charge_nofail(struct res_counter 
 *counter, unsigned long val,
   return __res_counter_charge(counter, val, limit_fail_at, true);
  }
  
 -void res_counter_uncharge_locked(struct res_counter *counter, unsigned long 
 val)
 +u64 res_counter_uncharge_locked(struct res_counter *counter, unsigned long 
 val)
  {
   if (WARN_ON(counter-usage  val))
   val = counter-usage;
  
   counter-usage -= val;
 + return counter-usage;
  }
  
 -void res_counter_uncharge_until(struct res_counter *counter,
 - struct res_counter *top,
 - unsigned long val)
 +u64 res_counter_uncharge_until(struct res_counter *counter,
 +struct res_counter *top,
 +unsigned long val)
  {
   unsigned long flags;
   struct 

Re: [PATCH] regmap: silence GCC warning

2012-10-01 Thread Mark Brown
On Sun, Sep 30, 2012 at 12:15:55PM +0200, Paul Bolle wrote:
 Building regmap.o triggers this GCC warning:
 drivers/base/regmap/regmap.c: In function ‘regmap_raw_read’:
 drivers/base/regmap/regmap.c:1172:6: warning: ‘ret’ may be used 
 uninitialized in this function [-Wmaybe-uninitialized]
 
 It seems 'ret' should always be set when this function returns. See, the
 else-branch can leave 'ret' uninitialized only if 'val_count' is zero.
 But if 'val_count' is zero regmap_volatile_range() will return true.
 That implies that 'ret' will be set in the if-branch. ('val_count' could
 be zero if 'val_len' is, for example, zero. That would be useless input,
 however.)
 
 Anyhow, initializing 'ret' to -EINVAL silences GCC and is harmless.

Have you reported this bug in GCC?  Their flow analyis just seems to
keep on getting worse and worse.
--
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 08/13] res_counter: return amount of charges after res_counter_uncharge

2012-10-01 Thread Glauber Costa
On 10/01/2012 02:00 PM, Michal Hocko wrote:
 On Tue 18-09-12 18:04:05, Glauber Costa wrote:
 It is useful to know how many charges are still left after a call to
 res_counter_uncharge. 
 
 While it is possible to issue a res_counter_read
 after uncharge, this is racy. It would be better if uncharge itself
 would tell us what the current status is.
 
 Well I am not sure how less racy it would be if you return the old
 value. It could be out of date when you read it, right? (this is even
 more visible with res_counter_uncharge_until)
 res_counter_read_u64 uses locks only for 32b when your change could help
 to reduce lock contention. Other than that it is just res_counter_member
 which is one cmp and a dereference. Sure you safe something but it is
 barely noticable I guess.
 

Sure it can. But this is the same semantics of the atomic updates, which
were always considered to be good enough for cases like this.


 I am not saying I do not like this change I just think that the
 above part of the changelog doesn't fit. So it would be much better if
 you tell us why this is needed for your patchset because the usage is
 not part of the patch.
 

I can update the changelog, for sure. But for the record, this has the
goal of taking the get/put pair out of the charge/uncharge path.

If I have 8k of data, and two threads decrement 4k each, a update + read
may return 0 for both. With this patch, only one of them will see 0, and
will proceed with the reference drop.

Again, this is the same semantics as all of the atomic variables in the
kernel.


 Since the current return value is void, we don't need to worry about
 anything breaking due to this change: nobody relied on that, and only
 users appearing from now on will be checking this value.

 Signed-off-by: Glauber Costa glom...@parallels.com
 CC: Michal Hocko mho...@suse.cz
 CC: Johannes Weiner han...@cmpxchg.org
 CC: Suleiman Souhlal sulei...@google.com
 CC: Kamezawa Hiroyuki kamezawa.hir...@jp.fujitsu.com
 ---
  Documentation/cgroups/resource_counter.txt |  7 ---
  include/linux/res_counter.h| 12 +++-
  kernel/res_counter.c   | 20 +---
  3 files changed, 24 insertions(+), 15 deletions(-)

 diff --git a/Documentation/cgroups/resource_counter.txt 
 b/Documentation/cgroups/resource_counter.txt
 index 0c4a344..c4d99ed 100644
 --- a/Documentation/cgroups/resource_counter.txt
 +++ b/Documentation/cgroups/resource_counter.txt
 @@ -83,16 +83,17 @@ to work with it.
  res_counter-lock internally (it must be called with res_counter-lock
  held). The force parameter indicates whether we can bypass the limit.
  
 - e. void res_counter_uncharge[_locked]
 + e. u64 res_counter_uncharge[_locked]
  (struct res_counter *rc, unsigned long val)
  
  When a resource is released (freed) it should be de-accounted
  from the resource counter it was accounted to.  This is called
 -uncharging.
 +uncharging. The return value of this function indicate the amount
 +of charges still present in the counter.
  
  The _locked routines imply that the res_counter-lock is taken.
  
 - f. void res_counter_uncharge_until
 + f. u64 res_counter_uncharge_until
  (struct res_counter *rc, struct res_counter *top,
   unsinged long val)
  
 diff --git a/include/linux/res_counter.h b/include/linux/res_counter.h
 index 7d7fbe2..4b173b6 100644
 --- a/include/linux/res_counter.h
 +++ b/include/linux/res_counter.h
 @@ -130,14 +130,16 @@ int res_counter_charge_nofail(struct res_counter 
 *counter,
   *
   * these calls check for usage underflow and show a warning on the console
   * _locked call expects the counter-lock to be taken
 + *
 + * returns the total charges still present in @counter.
   */
  
 -void res_counter_uncharge_locked(struct res_counter *counter, unsigned long 
 val);
 -void res_counter_uncharge(struct res_counter *counter, unsigned long val);
 +u64 res_counter_uncharge_locked(struct res_counter *counter, unsigned long 
 val);
 +u64 res_counter_uncharge(struct res_counter *counter, unsigned long val);
  
 -void res_counter_uncharge_until(struct res_counter *counter,
 -struct res_counter *top,
 -unsigned long val);
 +u64 res_counter_uncharge_until(struct res_counter *counter,
 +   struct res_counter *top,
 +   unsigned long val);
  /**
   * res_counter_margin - calculate chargeable space of a counter
   * @cnt: the counter
 diff --git a/kernel/res_counter.c b/kernel/res_counter.c
 index ad581aa..7b3d6dc 100644
 --- a/kernel/res_counter.c
 +++ b/kernel/res_counter.c
 @@ -86,33 +86,39 @@ int res_counter_charge_nofail(struct res_counter 
 *counter, unsigned long val,
  return __res_counter_charge(counter, val, limit_fail_at, true);
  }
  
 -void res_counter_uncharge_locked(struct res_counter *counter, unsigned long 
 val)
 +u64 

Re: [PATCH] Prevent AMD MCE oops on multi-server system

2012-10-01 Thread Borislav Petkov
On Mon, Oct 01, 2012 at 02:42:05PM +0800, Daniel J Blueman wrote:
 When booting on a federated multi-server system, the processor Northbridge
 lookup returns NULL; add guards to prevent this causing an oops.

Interesting.

What does lspci say on those systems?

Thanks.

-- 
Regards/Gruss,
Boris.

Advanced Micro Devices GmbH
Einsteinring 24, 85609 Dornach
GM: Alberto Bozzo
Reg: Dornach, Landkreis Muenchen
HRB Nr. 43632 WEEE Registernr: 129 19551
--
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] dw_dmac: fix a regression in dwc_prep_dma_memcpy

2012-10-01 Thread Andy Shevchenko
Sometimes memory-to-memory test is failed, that's why we need to choose minimum
data portion between source and destination limits together.

Signed-off-by: Andy Shevchenko andriy.shevche...@linux.intel.com
---
 drivers/dma/dw_dmac.c |9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/dw_dmac.c b/drivers/dma/dw_dmac.c
index 9ca9ca4..c4b0eb3 100644
--- a/drivers/dma/dw_dmac.c
+++ b/drivers/dma/dw_dmac.c
@@ -716,6 +716,7 @@ dwc_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t dest, 
dma_addr_t src,
size_t  offset;
unsigned intsrc_width;
unsigned intdst_width;
+   unsigned intdata_width;
u32 ctllo;
 
dev_vdbg(chan2dev(chan),
@@ -728,11 +729,11 @@ dwc_prep_dma_memcpy(struct dma_chan *chan, dma_addr_t 
dest, dma_addr_t src,
return NULL;
}
 
-   src_width = min_t(unsigned int, dwc-dw-data_width[dwc_get_sms(dws)],
- dwc_fast_fls(src | len));
+   data_width = min_t(unsigned int, dwc-dw-data_width[dwc_get_sms(dws)],
+dwc-dw-data_width[dwc_get_dms(dws)]);
 
-   dst_width = min_t(unsigned int, dwc-dw-data_width[dwc_get_dms(dws)],
- dwc_fast_fls(dest | len));
+   src_width = dst_width = min_t(unsigned int, data_width,
+ dwc_fast_fls(src | dest | len));
 
ctllo = DWC_DEFAULT_CTLLO(chan)
| DWC_CTLL_DST_WIDTH(dst_width)
-- 
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: [PATCHv3] dw_dmac: autoconfigure data_width or get it via platform data

2012-10-01 Thread Andy Shevchenko
On Mon, 2012-10-01 at 15:15 +0530, Vinod Koul wrote: 
 On Mon, 2012-10-01 at 12:04 +0300, Andy Shevchenko wrote:
  On Thu, 2012-09-27 at 16:03 +0530, Vinod Koul wrote: 
   On Thu, 2012-09-27 at 15:36 +0530, Vinod Koul wrote:
On Tue, 2012-09-25 at 14:39 +0300, Andy Shevchenko wrote:
 Not all of the controllers support the 64 bit data width. Make it 
 configurable
 via platform data. The driver will try to get a value from the 
 component
 parameters, otherwise it will use the platform data.
 
What was this gen against, I can apply this.
   %s/can/can't
  Today I got what was happened. I sent an update to one patch of the
  series, but you tried to apply it on top of previous version. It seems I
  was not clear. So, now we have a regression, and I will send a fix soon
  today.
 I received a series, and a patch on top and that what I tried to
 apply :(
 I am okay to revert the whole series now.
 
 Please send me fix by today, merge window has started, I hate to change
 stuff now.
I've sent a patch. You could apply on top of the series, or squash it
with the one called dw_dmac: autoconfigure data_width or get it via
platform data

-- 
Andy Shevchenko andriy.shevche...@linux.intel.com
Intel Finland Oy
--
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] media: mt9p031/mt9t001/mt9v032: use V4L2_CID_TEST_PATTERN for test pattern control

2012-10-01 Thread Prabhakar Lad
Hi Laurent,

Thanks for the review.

On Mon, Oct 1, 2012 at 3:12 PM, Laurent Pinchart
laurent.pinch...@ideasonboard.com wrote:
 Hi Prabhakar,

 Thanks for the patch.

 On Monday 01 October 2012 13:31:59 Prabhakar wrote:
 From: Lad, Prabhakar prabhakar@ti.com

 Signed-off-by: Lad, Prabhakar prabhakar@ti.com
 Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
 Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Cc: Sakari Ailus sakari.ai...@iki.fi
 Cc: Paul Gortmaker paul.gortma...@windriver.com
 Cc: Jean Delvare kh...@linux-fr.org
 ---
  Changes for v3:
  1: Used cluster in mt9v032 for test pattern,
  pointed by Laurent.

  Changes for v2:
  1: Fixed review comments pointed by Laurent.

  drivers/media/i2c/mt9p031.c |   19 +++--
  drivers/media/i2c/mt9t001.c |   22 ++-
  drivers/media/i2c/mt9v032.c |   60 +---
  3 files changed, 58 insertions(+), 43 deletions(-)

 diff --git a/drivers/media/i2c/mt9p031.c b/drivers/media/i2c/mt9p031.c
 index 2c0f407..e328332 100644
 --- a/drivers/media/i2c/mt9p031.c
 +++ b/drivers/media/i2c/mt9p031.c
 @@ -574,7 +574,6 @@ static int mt9p031_set_crop(struct v4l2_subdev *subdev,
   * V4L2 subdev control operations
   */

 -#define V4L2_CID_TEST_PATTERN(V4L2_CID_USER_BASE | 0x1001)
  #define V4L2_CID_BLC_AUTO(V4L2_CID_USER_BASE | 0x1002)
  #define V4L2_CID_BLC_TARGET_LEVEL(V4L2_CID_USER_BASE | 0x1003)
  #define V4L2_CID_BLC_ANALOG_OFFSET   (V4L2_CID_USER_BASE | 0x1004)
 @@ -740,18 +739,6 @@ static const char * const mt9p031_test_pattern_menu[] =
 { static const struct v4l2_ctrl_config mt9p031_ctrls[] = {
   {
   .ops= mt9p031_ctrl_ops,
 - .id = V4L2_CID_TEST_PATTERN,
 - .type   = V4L2_CTRL_TYPE_MENU,
 - .name   = Test Pattern,
 - .min= 0,
 - .max= ARRAY_SIZE(mt9p031_test_pattern_menu) - 1,
 - .step   = 0,
 - .def= 0,
 - .flags  = 0,
 - .menu_skip_mask = 0,
 - .qmenu  = mt9p031_test_pattern_menu,
 - }, {
 - .ops= mt9p031_ctrl_ops,
   .id = V4L2_CID_BLC_AUTO,
   .type   = V4L2_CTRL_TYPE_BOOLEAN,
   .name   = BLC, Auto,
 @@ -950,7 +937,7 @@ static int mt9p031_probe(struct i2c_client *client,
   mt9p031-model = did-driver_data;
   mt9p031-reset = -1;

 - v4l2_ctrl_handler_init(mt9p031-ctrls, ARRAY_SIZE(mt9p031_ctrls) + 5);
 + v4l2_ctrl_handler_init(mt9p031-ctrls, ARRAY_SIZE(mt9p031_ctrls) + 6);

   v4l2_ctrl_new_std(mt9p031-ctrls, mt9p031_ctrl_ops,
 V4L2_CID_EXPOSURE, MT9P031_SHUTTER_WIDTH_MIN,
 @@ -966,6 +953,10 @@ static int mt9p031_probe(struct i2c_client *client,
   v4l2_ctrl_new_std(mt9p031-ctrls, mt9p031_ctrl_ops,
 V4L2_CID_PIXEL_RATE, pdata-target_freq,
 pdata-target_freq, 1, pdata-target_freq);
 + v4l2_ctrl_new_std_menu_items(mt9p031-ctrls, mt9p031_ctrl_ops,
 +   V4L2_CID_TEST_PATTERN,
 +   ARRAY_SIZE(mt9p031_test_pattern_menu) - 1, 0,
 +   0, mt9p031_test_pattern_menu);

   for (i = 0; i  ARRAY_SIZE(mt9p031_ctrls); ++i)
   v4l2_ctrl_new_custom(mt9p031-ctrls, mt9p031_ctrls[i], NULL);
 diff --git a/drivers/media/i2c/mt9t001.c b/drivers/media/i2c/mt9t001.c
 index 6d343ad..2e189d8 100644
 --- a/drivers/media/i2c/mt9t001.c
 +++ b/drivers/media/i2c/mt9t001.c
 @@ -371,7 +371,7 @@ static int mt9t001_set_crop(struct v4l2_subdev *subdev,
   * V4L2 subdev control operations
   */

 -#define V4L2_CID_TEST_PATTERN(V4L2_CID_USER_BASE | 0x1001)
 +#define V4L2_CID_TEST_PATTERN_COLOR  (V4L2_CID_USER_BASE | 0x1001)
  #define V4L2_CID_BLACK_LEVEL_AUTO(V4L2_CID_USER_BASE | 0x1002)
  #define V4L2_CID_BLACK_LEVEL_OFFSET  (V4L2_CID_USER_BASE | 0x1003)
  #define V4L2_CID_BLACK_LEVEL_CALIBRATE   (V4L2_CID_USER_BASE | 0x1004)
 @@ -487,12 +487,11 @@ static int mt9t001_s_ctrl(struct v4l2_ctrl *ctrl)
ctrl-val  16);

   case V4L2_CID_TEST_PATTERN:
 - ret = mt9t001_set_output_control(mt9t001,
 + return mt9t001_set_output_control(mt9t001,
   ctrl-val ? 0 : MT9T001_OUTPUT_CONTROL_TEST_DATA,
   ctrl-val ? MT9T001_OUTPUT_CONTROL_TEST_DATA : 0);
 - if (ret  0)
 - return ret;

 + case V4L2_CID_TEST_PATTERN_COLOR:
   return mt9t001_write(client, MT9T001_TEST_DATA, ctrl-val  
 2);

   case V4L2_CID_BLACK_LEVEL_AUTO:
 @@ -533,12 +532,17 @@ static struct v4l2_ctrl_ops mt9t001_ctrl_ops = {
   .s_ctrl = mt9t001_s_ctrl,
  };

 +static const char * const mt9t001_test_pattern_menu[] = {
 + Disabled,
 + Enabled,
 +};
 +
  static const 

Re: [PATCH v3 06/13] memcg: kmem controller infrastructure

2012-10-01 Thread Glauber Costa
On 10/01/2012 01:48 PM, Michal Hocko wrote:
 On Fri 28-09-12 15:34:19, Glauber Costa wrote:
 On 09/27/2012 05:44 PM, Michal Hocko wrote:
 the reference count aquired by mem_cgroup_get will still prevent the
 memcg from going away, no?
 Yes but you are outside of the rcu now and we usually do css_get before
 we rcu_unlock. mem_cgroup_get just makes sure the group doesn't get
 deallocated but it could be gone before you call it. Or I am just
 confused - these 2 levels of ref counting is really not nice.

 Anyway, I have just noticed that __mem_cgroup_try_charge does
 VM_BUG_ON(css_is_removed(memcg-css)) on a given memcg so you should
 keep css ref count up as well.


 IIRC, css_get will prevent the cgroup directory from being removed.
 Because some allocations are expected to outlive the cgroup, we
 specifically don't want that.
 
 Yes, but how do you guarantee that the above VM_BUG_ON doesn't trigger?
 Task could have been moved to another group between mem_cgroup_from_task
 and mem_cgroup_get, no?
 

Ok, after reading this again (and again), you seem to be right. It
concerns me, however, that simply getting the css would lead us to a
double get/put pair, since try_charge will have to do it anyway.

I considered just letting try_charge selecting the memcg, but that is
not really what we want, since if that memcg will fail kmem allocations,
we simply won't issue try charge, but return early.

Any immediate suggestions on how to handle this ?

--
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 RESEND] PM/Hibernate: use rb_entry

2012-10-01 Thread Davidlohr Bueso
Since the software suspend extents are organized in an rbtree, use rb_entry
instead of container_of, as it is semantically more appropriate in order to
get a node as it is iterated.

Signed-off-by: Davidlohr Bueso d...@gnu.org
---
 kernel/power/swap.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/power/swap.c b/kernel/power/swap.c
index 3c9d764..7c33ed2 100644
--- a/kernel/power/swap.c
+++ b/kernel/power/swap.c
@@ -126,7 +126,7 @@ static int swsusp_extents_insert(unsigned long swap_offset)
 
/* Figure out where to put the new node */
while (*new) {
-   ext = container_of(*new, struct swsusp_extent, node);
+   ext = rb_entry(*new, struct swsusp_extent, node);
parent = *new;
if (swap_offset  ext-start) {
/* Try to merge */
-- 
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] regmap: silence GCC warning

2012-10-01 Thread Paul Bolle
On Mon, 2012-10-01 at 11:03 +0100, Mark Brown wrote:
 On Sun, Sep 30, 2012 at 12:15:55PM +0200, Paul Bolle wrote:
  Building regmap.o triggers this GCC warning:
  drivers/base/regmap/regmap.c: In function ‘regmap_raw_read’:
  drivers/base/regmap/regmap.c:1172:6: warning: ‘ret’ may be used 
  uninitialized in this function [-Wmaybe-uninitialized]
  
  It seems 'ret' should always be set when this function returns. See, the
  else-branch can leave 'ret' uninitialized only if 'val_count' is zero.
  But if 'val_count' is zero regmap_volatile_range() will return true.
  That implies that 'ret' will be set in the if-branch. ('val_count' could
  be zero if 'val_len' is, for example, zero. That would be useless input,
  however.)
  
  Anyhow, initializing 'ret' to -EINVAL silences GCC and is harmless.
 
 Have you reported this bug in GCC?

No I haven't. Since you ask, I guess you too think 'ret' is always set
when this function returns, don't you? Ie, my analysis isn't obviously
wrong.

 Their flow analyis just seems to keep on getting worse and worse.


Paul Bolle

--
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] regmap: silence GCC warning

2012-10-01 Thread Mark Brown
On Mon, Oct 01, 2012 at 12:16:46PM +0200, Paul Bolle wrote:
 On Mon, 2012-10-01 at 11:03 +0100, Mark Brown wrote:

  Have you reported this bug in GCC?

 No I haven't. Since you ask, I guess you too think 'ret' is always set
 when this function returns, don't you? Ie, my analysis isn't obviously
 wrong.

I haven't actually stared hard enough at the code to figure this out
yet but given what you're changing I'd hope it's a flow analysis bug.
I'm certainly not seeing a warning here.
--
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/


[GIT PULL] Xen on ARM

2012-10-01 Thread Stefano Stabellini
Hi Konrad,
please pull the following changes, based on your branch
stable/for-linus-3.7 (ecc635f90adfe1b7cd5fd354f49edfbf24aa4e3e):


git://xenbits.xen.org/people/sstabellini/linux-pvhvm.git xenarm-for-linus


Stefano Stabellini (18):
  arm: initial Xen support
  xen/arm: hypercalls
  xen/arm: page.h definitions
  xen/arm: sync_bitops
  xen/arm: empty implementation of grant_table arch specific functions
  docs: Xen ARM DT bindings
  xen/arm: Xen detection and shared_info page mapping
  xen/arm: Introduce xen_ulong_t for unsigned long
  xen: do not compile manage, balloon, pci, acpi, pcpu and cpu_hotplug on 
ARM
  xen/arm: introduce CONFIG_XEN on ARM
  xen/arm: get privilege status
  xen/arm: initialize grant_table on ARM
  xen/arm: receive Xen events on ARM
  xen/arm: implement alloc/free_xenballooned_pages with alloc_pages/kfree
  xen/arm: compile blkfront and blkback
  xen/arm: compile netback
  MAINTAINERS: add myself as Xen ARM maintainer
  arm: introduce a DTS for Xen unprivileged virtual machines

 Documentation/devicetree/bindings/arm/xen.txt |   25 
 MAINTAINERS   |7 +
 arch/arm/Kconfig  |   10 ++
 arch/arm/Makefile |1 +
 arch/arm/boot/dts/xenvm-4.2.dts   |   68 ++
 arch/arm/include/asm/hypervisor.h |6 +
 arch/arm/include/asm/sync_bitops.h|   27 
 arch/arm/include/asm/xen/events.h |   18 +++
 arch/arm/include/asm/xen/hypercall.h  |   69 ++
 arch/arm/include/asm/xen/hypervisor.h |   19 +++
 arch/arm/include/asm/xen/interface.h  |   73 +++
 arch/arm/include/asm/xen/page.h   |   82 
 arch/arm/mach-vexpress/Makefile.boot  |3 +-
 arch/arm/mach-vexpress/v2m.c  |1 +
 arch/arm/xen/Makefile |1 +
 arch/arm/xen/enlighten.c  |  168 +
 arch/arm/xen/grant-table.c|   53 
 arch/arm/xen/hypercall.S  |  106 
 arch/ia64/include/asm/xen/interface.h |1 +
 arch/x86/include/asm/xen/interface.h  |1 +
 arch/x86/xen/enlighten.c  |1 +
 arch/x86/xen/irq.c|1 +
 arch/x86/xen/xen-ops.h|1 -
 drivers/block/xen-blkback/blkback.c   |1 +
 drivers/net/xen-netback/netback.c |1 +
 drivers/net/xen-netfront.c|1 +
 drivers/xen/Makefile  |   13 ++-
 drivers/xen/events.c  |   17 ++-
 include/xen/events.h  |2 +
 include/xen/interface/features.h  |3 +
 include/xen/interface/io/protocols.h  |3 +
 include/xen/interface/memory.h|   12 +-
 include/xen/interface/physdev.h   |2 +-
 include/xen/interface/version.h   |2 +-
 include/xen/xen.h |2 +-
 35 files changed, 783 insertions(+), 18 deletions(-)

Cheers,

Stefano
--
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/4] mfd: ab8500: add devicetree support for fuelgauge

2012-10-01 Thread Lee Jones
Sorry, some mistakes:

  From: Rajanikanth H.V rajanikanth...@stericsson.com
  
  - This patch adds device tree support for fuelguage driver
  - optimize bm devices platform_data usage and of_probe(...)
Note: of_probe() routine for battery managed devices is made
common across all bm drivers.

Spelling errors in here.

  +   dev_err(dev, invalid battery-info node\n);
  +   return -EINVAL;
  +   }
  +   if (of_property_read_bool(np_bat_supply,
  +   thermistor-on-batctrl) == false){
 
 Replace with: 
 if (of_get_property(np_bat_supply, thermistor-on-batctr, NULL))
   np_bat_supply =  true;

This should be: 

 if (of_get_property(np_bat_supply, thermistor-on-batctr, NULL))
thermistor = NTC_INTERNAL;
 else
thermistor = NTC_EXTERNAL;

 remove
 
  +   dev_warn(dev, missing property thermistor-on-batctrl\n);
  +   thermistor = NTC_EXTERNAL;
  +   }
 
 /remove

-- 
Lee Jones
Linaro ST-Ericsson Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
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 v2] mfd: da9052-core: Use regmap_irq_get_virq() and fix the probe

2012-10-01 Thread Mark Brown
On Fri, Sep 28, 2012 at 05:34:18PM -0300, Fabio Estevam wrote:

 +static struct irq_chip da9052_irq_chip = {
 + .name   = da9052,
 + .irq_disable= da9052_irq_disable,
 + .irq_enable = da9052_irq_enable,
 +};

I don't understand what this irq_chip or the custom domain you're adding
are for?
--
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 2/7] usb: dwc3-omap: use of_platform API to create dwc3 core pdev

2012-10-01 Thread Kishon Vijay Abraham I
Used of_platform_populate() to populate dwc3 core platform_device
from device tree data. Since now the allocation of unique device id is
handled be of_*, removed the call to dwc3_get_device_id.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 drivers/usb/dwc3/dwc3-omap.c |   52 --
 1 file changed, 10 insertions(+), 42 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index e335da3..cb4037a 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -47,6 +47,7 @@
 #include linux/ioport.h
 #include linux/io.h
 #include linux/of.h
+#include linux/of_platform.h
 
 #include core.h
 
@@ -130,7 +131,6 @@ struct dwc3_omap {
/* device lock */
spinlock_t  lock;
 
-   struct platform_device  *dwc3;
struct device   *dev;
 
int irq;
@@ -218,12 +218,10 @@ static int __devinit dwc3_omap_probe(struct 
platform_device *pdev)
struct dwc3_omap_data   *pdata = pdev-dev.platform_data;
struct device_node  *node = pdev-dev.of_node;
 
-   struct platform_device  *dwc3;
struct dwc3_omap*omap;
struct resource *res;
struct device   *dev = pdev-dev;
 
-   int devid;
int size;
int ret = -ENOMEM;
int irq;
@@ -260,34 +258,19 @@ static int __devinit dwc3_omap_probe(struct 
platform_device *pdev)
return -ENOMEM;
}
 
-   devid = dwc3_get_device_id();
-   if (devid  0)
-   return -ENODEV;
-
-   dwc3 = platform_device_alloc(dwc3, devid);
-   if (!dwc3) {
-   dev_err(dev, couldn't allocate dwc3 device\n);
-   goto err1;
-   }
-
context = devm_kzalloc(dev, resource_size(res), GFP_KERNEL);
if (!context) {
dev_err(dev, couldn't allocate dwc3 context memory\n);
-   goto err2;
+   return -ENOMEM;
}
 
spin_lock_init(omap-lock);
-   dma_set_coherent_mask(dwc3-dev, dev-coherent_dma_mask);
 
-   dwc3-dev.parent = dev;
-   dwc3-dev.dma_mask = dev-dma_mask;
-   dwc3-dev.dma_parms = dev-dma_parms;
omap-resource_size = resource_size(res);
omap-context   = context;
omap-dev   = dev;
omap-irq   = irq;
omap-base  = base;
-   omap-dwc3  = dwc3;
 
reg = dwc3_omap_readl(omap-base, USBOTGSS_UTMI_OTG_STATUS);
 
@@ -332,7 +315,7 @@ static int __devinit dwc3_omap_probe(struct platform_device 
*pdev)
if (ret) {
dev_err(dev, failed to request IRQ #%d -- %d\n,
omap-irq, ret);
-   goto err2;
+   return ret;
}
 
/* enable all IRQs */
@@ -351,35 +334,20 @@ static int __devinit dwc3_omap_probe(struct 
platform_device *pdev)
 
dwc3_omap_writel(omap-base, USBOTGSS_IRQENABLE_SET_1, reg);
 
-   ret = platform_device_add_resources(dwc3, pdev-resource,
-   pdev-num_resources);
-   if (ret) {
-   dev_err(dev, couldn't add resources to dwc3 device\n);
-   goto err2;
-   }
-
-   ret = platform_device_add(dwc3);
-   if (ret) {
-   dev_err(dev, failed to register dwc3 device\n);
-   goto err2;
+   if (node) {
+   ret = of_platform_populate(node, NULL, NULL, dev);
+   if (ret) {
+   dev_err(pdev-dev,
+   failed to add create dwc3 core\n);
+   return ret;
+   }
}
 
return 0;
-
-err2:
-   platform_device_put(dwc3);
-
-err1:
-   dwc3_put_device_id(devid);
-
-   return ret;
 }
 
 static int __devexit dwc3_omap_remove(struct platform_device *pdev)
 {
-   struct dwc3_omap*omap = platform_get_drvdata(pdev);
-
-   dwc3_put_device_id(omap-dwc3-id);
device_for_each_child(pdev-dev, NULL, dwc3_omap_remove_core);
 
return 0;
-- 
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/


[PATCH v2 3/7] usb: dwc3-omap: use runtime API's to enable clocks

2012-10-01 Thread Kishon Vijay Abraham I
Before accessing any register, runtime API's should be invoked to enable
the clocks. runtime API's are added here to prevent abort during register
access.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 drivers/usb/dwc3/dwc3-omap.c |   10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index cb4037a..850a0cf 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -43,6 +43,7 @@
 #include linux/spinlock.h
 #include linux/platform_device.h
 #include linux/platform_data/dwc3-omap.h
+#include linux/pm_runtime.h
 #include linux/dma-mapping.h
 #include linux/ioport.h
 #include linux/io.h
@@ -272,6 +273,13 @@ static int __devinit dwc3_omap_probe(struct 
platform_device *pdev)
omap-irq   = irq;
omap-base  = base;
 
+   pm_runtime_enable(dev);
+   ret = pm_runtime_get_sync(dev);
+   if (ret  0) {
+   dev_err(dev, get_sync failed with err %d\n, ret);
+   return ret;
+   }
+
reg = dwc3_omap_readl(omap-base, USBOTGSS_UTMI_OTG_STATUS);
 
utmi_mode = of_get_property(node, utmi-mode, size);
@@ -348,6 +356,8 @@ static int __devinit dwc3_omap_probe(struct platform_device 
*pdev)
 
 static int __devexit dwc3_omap_remove(struct platform_device *pdev)
 {
+   pm_runtime_put_sync(pdev-dev);
+   pm_runtime_disable(pdev-dev);
device_for_each_child(pdev-dev, NULL, dwc3_omap_remove_core);
 
return 0;
-- 
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/


[PATCH v2 5/7] usb: dwc3-omap: Add an API to write to dwc mailbox

2012-10-01 Thread Kishon Vijay Abraham I
Add an API in the omap glue layer to write to the mailbox register which
can be used by comparator driver(twl). To pass the detection of the attached
device (signified by VBUS, ID) to the dwc3 core, dwc3 core has to write
to the mailbox regiter.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 drivers/usb/dwc3/dwc3-omap.c  |   59 +
 include/linux/usb/dwc3-omap.h |   30 +
 2 files changed, 89 insertions(+)
 create mode 100644 include/linux/usb/dwc3-omap.h

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index d417bec..c19affa 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -43,6 +43,7 @@
 #include linux/spinlock.h
 #include linux/platform_device.h
 #include linux/platform_data/dwc3-omap.h
+#include linux/usb/dwc3-omap.h
 #include linux/pm_runtime.h
 #include linux/dma-mapping.h
 #include linux/ioport.h
@@ -126,6 +127,8 @@ struct dwc3_omap {
u32 dma_status:1;
 };
 
+struct dwc3_omap   *_omap;
+
 static inline u32 dwc3_omap_readl(void __iomem *base, u32 offset)
 {
return readl(base + offset);
@@ -136,6 +139,56 @@ static inline void dwc3_omap_writel(void __iomem *base, 
u32 offset, u32 value)
writel(value, base + offset);
 }
 
+void dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
+{
+   u32 val;
+   struct dwc3_omap*omap = _omap;
+
+   switch (status) {
+   case OMAP_DWC3_ID_GROUND:
+   dev_dbg(omap-dev, ID GND\n);
+
+   val = dwc3_omap_readl(omap-base, USBOTGSS_UTMI_OTG_STATUS);
+   val = ~(USBOTGSS_UTMI_OTG_STATUS_IDDIG
+   | USBOTGSS_UTMI_OTG_STATUS_VBUSVALID
+   | USBOTGSS_UTMI_OTG_STATUS_SESSEND);
+   val |= USBOTGSS_UTMI_OTG_STATUS_SESSVALID
+   | USBOTGSS_UTMI_OTG_STATUS_POWERPRESENT;
+   dwc3_omap_writel(omap-base, USBOTGSS_UTMI_OTG_STATUS, val);
+   break;
+
+   case OMAP_DWC3_VBUS_VALID:
+   dev_dbg(omap-dev, VBUS Connect\n);
+
+   val = dwc3_omap_readl(omap-base, USBOTGSS_UTMI_OTG_STATUS);
+   val = ~USBOTGSS_UTMI_OTG_STATUS_SESSEND;
+   val |= USBOTGSS_UTMI_OTG_STATUS_IDDIG
+   | USBOTGSS_UTMI_OTG_STATUS_VBUSVALID
+   | USBOTGSS_UTMI_OTG_STATUS_SESSVALID
+   | USBOTGSS_UTMI_OTG_STATUS_POWERPRESENT;
+   dwc3_omap_writel(omap-base, USBOTGSS_UTMI_OTG_STATUS, val);
+   break;
+
+   case OMAP_DWC3_ID_FLOAT:
+   case OMAP_DWC3_VBUS_OFF:
+   dev_dbg(omap-dev, VBUS Disconnect\n);
+
+   val = dwc3_omap_readl(omap-base, USBOTGSS_UTMI_OTG_STATUS);
+   val = ~(USBOTGSS_UTMI_OTG_STATUS_SESSVALID
+   | USBOTGSS_UTMI_OTG_STATUS_VBUSVALID
+   | USBOTGSS_UTMI_OTG_STATUS_POWERPRESENT);
+   val |= USBOTGSS_UTMI_OTG_STATUS_SESSEND
+   | USBOTGSS_UTMI_OTG_STATUS_IDDIG;
+   dwc3_omap_writel(omap-base, USBOTGSS_UTMI_OTG_STATUS, val);
+   break;
+
+   default:
+   dev_dbg(omap-dev, ID float\n);
+   }
+
+   return;
+}
+EXPORT_SYMBOL_GPL(dwc3_omap_mailbox);
 
 static irqreturn_t dwc3_omap_interrupt(int irq, void *_omap)
 {
@@ -256,6 +309,12 @@ static int __devinit dwc3_omap_probe(struct 
platform_device *pdev)
omap-irq   = irq;
omap-base  = base;
 
+   /*
+* REVISIT if we ever have two instances of the wrapper, we will be
+* in big trouble
+*/
+   _omap   = omap;
+
pm_runtime_enable(dev);
ret = pm_runtime_get_sync(dev);
if (ret  0) {
diff --git a/include/linux/usb/dwc3-omap.h b/include/linux/usb/dwc3-omap.h
new file mode 100644
index 000..6ebcf73
--- /dev/null
+++ b/include/linux/usb/dwc3-omap.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright (C) 2011-2012 by Texas Instruments
+ *
+ * The Inventra Controller Driver for Linux is free software; you
+ * can redistribute it and/or modify it under the terms of the GNU
+ * General Public License version 2 as published by the Free Software
+ * Foundation.
+ */
+
+#ifndef __DWC3_OMAP_H__
+#define __DWC3_OMAP_H__
+
+enum omap_dwc3_vbus_id_status {
+   OMAP_DWC3_UNKNOWN = 0,
+   OMAP_DWC3_ID_GROUND,
+   OMAP_DWC3_ID_FLOAT,
+   OMAP_DWC3_VBUS_VALID,
+   OMAP_DWC3_VBUS_OFF,
+};
+
+#if (defined(CONFIG_USB_DWC3) || defined(CONFIG_USB_DWC3_MODULE))
+void dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status);
+#else
+static inline void dwc3_omap_mailbox(enum omap_dwc3_vbus_id_status status)
+{
+   return;
+}
+#endif
+
+#endif /* __DWC3_OMAP_H__ */
-- 
1.7.9.5

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to 

[PATCH v2 7/7] usb: dwc3: core: add dt support for dwc3 core

2012-10-01 Thread Kishon Vijay Abraham I
Added dwc3 support for dwc3 core and update the documentation with
device tree binding information.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 Documentation/devicetree/bindings/usb/dwc3.txt |   23 +++
 drivers/usb/dwc3/core.c|   14 --
 2 files changed, 35 insertions(+), 2 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt

diff --git a/Documentation/devicetree/bindings/usb/dwc3.txt 
b/Documentation/devicetree/bindings/usb/dwc3.txt
new file mode 100644
index 000..9ec9316
--- /dev/null
+++ b/Documentation/devicetree/bindings/usb/dwc3.txt
@@ -0,0 +1,23 @@
+synopsys DWC3 CORE
+
+DWC3- USB3 CONTROLLER
+
+Required properties:
+ - compatible: must be synopsys,dwc3
+ - reg : Address and length of the register set for the device
+ - interrupts: Interrupts used by the dwc3 controller.
+ - interrupt-parent: the phandle for the interrupt controller that
+   services interrupts for this device.
+
+Optional properties:
+ - tx-fifo-resize: determines if the FIFO *has* to be reallocated.
+
+This is usually a subnode to DWC3 glue to which it is connected.
+
+dwc3@4a03 {
+   compatible = synopsys,dwc3;
+   reg = 0x4a03 0xcfff;
+   interrupts = 0 92 4
+   interrupt-parent = gic
+   tx-fifo-resize;
+};
diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
index 08a5738..4335a17 100644
--- a/drivers/usb/dwc3/core.c
+++ b/drivers/usb/dwc3/core.c
@@ -484,8 +484,7 @@ static int __devinit dwc3_probe(struct platform_device 
*pdev)
else
dwc-maximum_speed = DWC3_DCFG_SUPERSPEED;
 
-   if (of_get_property(node, tx-fifo-resize, NULL))
-   dwc-needs_fifo_resize = true;
+   dwc-needs_fifo_resize = of_property_read_bool(node, tx-fifo-resize);
 
pm_runtime_enable(dev);
pm_runtime_get_sync(dev);
@@ -602,11 +601,22 @@ static int __devexit dwc3_remove(struct platform_device 
*pdev)
return 0;
 }
 
+#ifdef CONFIG_OF
+static const struct of_device_id of_dwc3_match[] = {
+   {
+   .compatible = synopsys,dwc3
+   },
+   { },
+};
+MODULE_DEVICE_TABLE(of, of_dwc3_match);
+#endif
+
 static struct platform_driver dwc3_driver = {
.probe  = dwc3_probe,
.remove = __devexit_p(dwc3_remove),
.driver = {
.name   = dwc3,
+   .of_match_table = of_match_ptr(of_dwc3_match),
},
 };
 
-- 
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/


[PATCH v2 1/7] usb: dwc3-omap: use device_for_each_child to handle child removal

2012-10-01 Thread Kishon Vijay Abraham I
Used device_for_each_child() to handle child device (dwc3 core) removal
during devexit of dwc3 omap.

Signed-off-by: Kishon Vijay Abraham I kis...@ti.com
---
 drivers/usb/dwc3/dwc3-omap.c |   12 ++--
 1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/dwc3/dwc3-omap.c b/drivers/usb/dwc3/dwc3-omap.c
index 479dc04..e335da3 100644
--- a/drivers/usb/dwc3/dwc3-omap.c
+++ b/drivers/usb/dwc3/dwc3-omap.c
@@ -204,6 +204,15 @@ static irqreturn_t dwc3_omap_interrupt(int irq, void 
*_omap)
return IRQ_HANDLED;
 }
 
+static int dwc3_omap_remove_core(struct device *dev, void *c)
+{
+   struct platform_device *pdev = to_platform_device(dev);
+
+   platform_device_unregister(pdev);
+
+   return 0;
+}
+
 static int __devinit dwc3_omap_probe(struct platform_device *pdev)
 {
struct dwc3_omap_data   *pdata = pdev-dev.platform_data;
@@ -370,9 +379,8 @@ static int __devexit dwc3_omap_remove(struct 
platform_device *pdev)
 {
struct dwc3_omap*omap = platform_get_drvdata(pdev);
 
-   platform_device_unregister(omap-dwc3);
-
dwc3_put_device_id(omap-dwc3-id);
+   device_for_each_child(pdev-dev, NULL, dwc3_omap_remove_core);
 
return 0;
 }
-- 
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/


[PATCH v2 0/7] usb: dwc3-omap: add dt support

2012-10-01 Thread Kishon Vijay Abraham I
This patch series adds dt support to dwc3 core and fixes few minor
stuff in dwc3-omap glue to get dwc3 working.

While at that it also uses *of_platform* to create the child device
(dwc3-core) and fixes to use runtime API's to enable clock and write
to SYSCONFIG register.

Changes from v1:
* made device_for_each_child() as a seperate patch
* made all other minor fixes wrt typos and function renames

This patch series is developed on:
git://git.kernel.org/pub/scm/linux/kernel/git/balbi/usb.git dwc3

Kishon Vijay Abraham I (7):
  usb: dwc3-omap: use device_for_each_child to handle child removal
  usb: dwc3-omap: use of_platform API to create dwc3 core pdev
  usb: dwc3-omap: use runtime API's to enable clocks
  usb: dwc3-omap: Remove explicit writes to SYSCONFIG register
  usb: dwc3-omap: Add an API to write to dwc mailbox
  usb: dwc3-omap: Minor fixes to get dt working
  usb: dwc3: core: add dt support for dwc3 core

 Documentation/devicetree/bindings/usb/dwc3.txt |   23 
 drivers/usb/dwc3/core.c|   14 +-
 drivers/usb/dwc3/dwc3-omap.c   |  167 +---
 include/linux/usb/dwc3-omap.h  |   30 +
 4 files changed, 158 insertions(+), 76 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/usb/dwc3.txt
 create mode 100644 include/linux/usb/dwc3-omap.h

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


  1   2   3   4   5   6   7   8   >