Re: [PATCHv2 4/4] gpio: smscece: Add support for gpio IO expander feature

[Poddar, Sourav]

Hi Vaibhav,

On Thu, Sep 6, 2012 at 12:29 AM, Vaibhav Hiremath  wrote:
>
>
> On 9/5/2012 5:07 PM, Sourav Poddar wrote:
>> smsc can be used as an gpio io expander device also. So adding
>> support for configuring smsc pins as a gpio.
>>
>> Cc: Benoit Cousson 
>> Cc: Felipe Balbi 
>> Cc: Santosh Shilimkar 
>> Signed-off-by: Sourav Poddar 
>> ---
>> Changes since v1:
>>  - Use edge triggering instead of level
>>  - Use devm_reuest_threaded_irq
>>  - In remove part, use "irq_free_desc" and
>>  "irq_remove_domain" api.
>>  drivers/gpio/Kconfig|7 +
>>  drivers/gpio/Makefile   |1 +
>>  drivers/gpio/gpio-smscece.c |  380 
>> +++
>>  3 files changed, 388 insertions(+), 0 deletions(-)
>>  create mode 100644 drivers/gpio/gpio-smscece.c
>>
>> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
>> index b16c8a7..e883929 100644
>> --- a/drivers/gpio/Kconfig
>> +++ b/drivers/gpio/Kconfig
>> @@ -444,6 +444,13 @@ config GPIO_ADP5588_IRQ
>> Say yes here to enable the adp5588 to be used as an interrupt
>> controller. It requires the driver to be built in the kernel.
>>
>> +config GPIO_SMSCECE
>> + tristate "SMSCECE 1099 I2C GPIO expander"
>> + depends on I2C
>> + help
>> +   This option enables support for 18 GPIOs found
>> +   on SMSC ECE 1099 GPIO Expanders.
>> +
>>  comment "PCI GPIO expanders:"
>>
>>  config GPIO_CS5535
>> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
>> index 153cace..7c803c5 100644
>> --- a/drivers/gpio/Makefile
>> +++ b/drivers/gpio/Makefile
>> @@ -12,6 +12,7 @@ obj-$(CONFIG_GPIO_74X164)   += gpio-74x164.o
>>  obj-$(CONFIG_GPIO_AB8500)+= gpio-ab8500.o
>>  obj-$(CONFIG_GPIO_ADP5520)   += gpio-adp5520.o
>>  obj-$(CONFIG_GPIO_ADP5588)   += gpio-adp5588.o
>> +obj-$(CONFIG_GPIO_SMSCECE)  += gpio-smscece.o
>>  obj-$(CONFIG_GPIO_AMD8111)   += gpio-amd8111.o
>>  obj-$(CONFIG_GPIO_ARIZONA)   += gpio-arizona.o
>>  obj-$(CONFIG_GPIO_BT8XX) += gpio-bt8xx.o
>> diff --git a/drivers/gpio/gpio-smscece.c b/drivers/gpio/gpio-smscece.c
>> new file mode 100644
>> index 000..68a17fa
>> --- /dev/null
>> +++ b/drivers/gpio/gpio-smscece.c
>> @@ -0,0 +1,380 @@
>> +/*
>> + * GPIO Chip driver for smsc
>> + * SMSC I/O Expander and QWERTY Keypad Controller
>> + *
>> + * Copyright 2012 Texas Instruments Inc.
>> + *
>> + * Licensed under the GPL-2 or later.
>
> Can you put proper license here?
>
Ok.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +struct smsc_gpio {
>> + struct device *dev;
>> + struct smsc *smsc;
>> + struct gpio_chip gpio_chip;
>> + struct mutex lock;  /* protect cached dir, dat_out */
>> + /* protect serialized access to the interrupt controller bus */
>> + struct mutex irq_lock;
>> + struct irq_domain   *irq_domain;
>> + unsigned gpio_start;
>> + int type;
>> + int flags;
>> + int irq;
>> + int irq_base;
>> + unsigned int gpio_base;
>> + unsigned int dat_out[5];
>> + unsigned int dir[5];
>> + unsigned int irq_trig_fall[5];
>> + unsigned int irq_trig_raise[5];
>> + unsigned int int_en[5];
>> + unsigned int irq_mask[5];
>> + unsigned int irq_stat[5];
>> +};
>> +
>> +static int smsc_gpio_get_value(struct gpio_chip *chip, unsigned off)
>> +{
>> + struct smsc_gpio *sg =
>> + container_of(chip, struct smsc_gpio, gpio_chip);
>> + unsigned int get;
>> + return !!(smsc_read(sg->dev,
>> + (SMSC_GPIO_DATA_IN_START + SMSC_BANK(off)) & SMSC_BIT(off),
>> + ));
>> +}
>> +
>> +static void smsc_gpio_set_value(struct gpio_chip *chip,
>> + unsigned off, int val)
>> +{
>> + unsigned bank, bit;
>> + struct smsc_gpio *sg =
>> + container_of(chip, struct smsc_gpio, gpio_chip);
>> +
>> + bank = SMSC_BANK(off);
>> + bit = SMSC_BIT(off);
>> +
>> + mutex_lock(>lock);
>> + if (val)
>> + sg->dat_out[bank] |= bit;
>> + else
>> + sg->dat_out[bank] &= ~bit;
>> +
>> + smsc_write(sg->dev, SMSC_GPIO_DATA_OUT_START + bank,
>> +sg->dat_out[bank]);
>> + mutex_unlock(>lock);
>> +}
>> +
>> +static int smsc_gpio_direction_input(struct gpio_chip *chip, unsigned off)
>> +{
>> + unsigned int reg;
>> + struct smsc_gpio *sg =
>> + container_of(chip, struct smsc_gpio, gpio_chip);
>> + int reg_dir;
>> +
>> + mutex_lock(>lock);
>> + reg_dir = SMSC_CFG_START + off;
>> + smsc_read(sg->dev, reg_dir, );
>> + reg |= SMSC_GPIO_INPUT_LOW;
>> + mutex_unlock(>lock);
>> +
>> + return smsc_write(sg->dev, reg_dir, reg);
>> +}
>> +
>> +static int smsc_gpio_direction_output(struct gpio_chip *chip,
>> +  unsigned off, int val)
>> +{
>> + unsigned int reg;
>> + 

Re: [PATCHv2 1/4] mfd: smsc: Add support for smsc gpio io/keypad driver

[Poddar, Sourav]

Hi,

On Wed, Sep 5, 2012 at 11:23 PM, Vaibhav Hiremath  wrote:
>
>
> On 9/5/2012 5:06 PM, Sourav Poddar wrote:
>> smsc ece1099 is a keyboard scan or gpio expansion device.
>> The patch create keypad and gpio expander child for this
>> multi function smsc driver.
>>
>> Cc: Samuel Ortiz 
>> Cc: Benoit Cousson 
>> Cc: Felipe Balbi 
>> Cc: Santosh Shilimkar 
>> Signed-off-by: Sourav Poddar 
>> ---
>> Changes since v1:
>>  - Use Kconfig option correctly
>>  - Add regmap_config paramters
>>  - Modify formatting of logs for devid
>>  - Move read/write function to headed file as an inline
>>function.
>>  Documentation/smsc_ece1099.txt |   56 
>>  drivers/mfd/Kconfig|   12 
>>  drivers/mfd/Makefile   |1 +
>>  drivers/mfd/smsc-ece1099.c |  110 
>> +++
>>  include/linux/mfd/smsc.h   |  111 
>> 
>>  5 files changed, 290 insertions(+), 0 deletions(-)
>>  create mode 100644 Documentation/smsc_ece1099.txt
>>  create mode 100644 drivers/mfd/smsc-ece1099.c
>>  create mode 100644 include/linux/mfd/smsc.h
>>
>> diff --git a/Documentation/smsc_ece1099.txt b/Documentation/smsc_ece1099.txt
>> new file mode 100644
>> index 000..6b492e8
>> --- /dev/null
>> +++ b/Documentation/smsc_ece1099.txt
>> @@ -0,0 +1,56 @@
>> +What is smsc-ece1099?
>> +--
>> +
>> +The ECE1099 is a 40-Pin 3.3V Keyboard Scan Expansion
>> +or GPIO Expansion device. The device supports a keyboard
>> +scan matrix of 23x8. The device is connected to a Master
>> +via the SMSC BC-Link interface or via the SMBus.
>> +Keypad scan Input(KSI) and Keypad Scan Output(KSO) signals
>> +are multiplexed with GPIOs.
>> +
>> +Interrupt generation
>> +
>> +
>> +Interrupts can be generated by an edge detection on a GPIO
>> +pin or an edge detection on one of the bus interface pins.
>> +Interrupts can also be detected on the keyboard scan interface.
>> +The bus interrupt pin (BC_INT# or SMBUS_INT#) is asserted if
>> +any bit in one of the Interrupt Status registers is 1 and
>> +the corresponding Interrupt Mask bit is also 1.
>> +
>> +In order for software to determine which device is the source
>> +of an interrupt, it should first read the Group Interrupt Status Register
>> +to determine which Status register group is a source for the interrupt.
>> +Software should read both the Status register and the associated Mask 
>> register,
>> +then AND the two values together. Bits that are 1 in the result of the AND
>> +are active interrupts. Software clears an interrupt by writing a 1 to the
>> +corresponding bit in the Status register.
>> +
>> +Communication Protocol
>> +--
>> +
>> +- SMbus slave Interface
>> + The host processor communicates with the ECE1099 device
>> + through a series of read/write registers via the SMBus
>> + interface. SMBus is a serial communication protocol between
>> + a computer host and its peripheral devices. The SMBus data
>> + rate is 10KHz minimum to 400 KHz maximum
>> +
>> +- Slave Bus Interface
>> + The ECE1099 device SMBus implementation is a subset of the
>> + SMBus interface to the host. The device is a slave-only SMBus device.
>> + The implementation in the device is a subset of SMBus since it
>> + only supports four protocols.
>> +
>> + The Write Byte, Read Byte, Send Byte, and Receive Byte protocols are 
>> the
>> + only valid SMBus protocols for the device.
>> +
>> +- BC-LinkTM Interface
>> + The BC-Link is a proprietary bus that allows communication
>> + between a Master device and a Companion device. The Master
>> + device uses this serial bus to read and write registers
>> + located on the Companion device. The bus comprises three signals,
>> + BC_CLK, BC_DAT and BC_INT#. The Master device always provides the
>> + clock, BC_CLK, and the Companion device is the source for an
>> + independent asynchronous interrupt signal, BC_INT#. The ECE1099
>> + supports BC-Link speeds up to 24MHz.
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index d1facef..991ef15 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -385,6 +385,18 @@ config MFD_T7L66XB
>>   help
>> Support for Toshiba Mobile IO Controller T7L66XB
>>
>> +config MFD_SMSC
>> +   bool "Support for the SMSC ECE1099 series chips"
>> +   depends on I2C=y
>> +   select MFD_CORE
>> +   select REGMAP_I2C
>> +   help
>> +If you say yes here you get support for the
>> +ece1099 chips from SMSC.
>> +
>> +To compile this driver as a module, choose M here: the
>> +module will be called smsc.
>> +
>>  config MFD_TC6387XB
>>   bool "Support Toshiba TC6387XB"
>>   depends on ARM && HAVE_CLK
>> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
>> index 79dd22d..f587d91 100644
>> --- a/drivers/mfd/Makefile
>> +++ 

Re: [PATCH] OMAP GPIO - don't wake from suspend unless requested.

[Shilimkar, Santosh]

On Thu, Sep 6, 2012 at 8:35 AM, NeilBrown  wrote:
> On Mon, 3 Sep 2012 22:59:06 -0700 "Shilimkar, Santosh"
>  wrote:
>
>> On Sun, Aug 26, 2012 at 6:29 PM, Shilimkar, Santosh
>>  wrote:
>> > On Sun, Aug 26, 2012 at 3:53 PM, NeilBrown  wrote:
>> >>
>> >> On Sun, 26 Aug 2012 09:47:50 +0530 "Shilimkar, Santosh"
>> >>  wrote:
>> >>
>> >> > + Jon,
>> >> >
>> >> > On Sat, Aug 25, 2012 at 5:14 PM, NeilBrown  wrote:
>> >> > >
>> >> > >
>> >> > >
>> >> > > Current kernel will wake from suspend on an event on any active
>> >> > > GPIO even if enable_irq_wake() wasn't called.
>> >> > >
>> >> > > There are two reasons that the hardware wake-enable bit should be set:
>> >> > >
>> >> > > 1/ while non-suspended the CPU might go into a deep sleep (off_mode)
>> >> > >   in which the wake-enable bit is needed for an interrupt to be
>> >> > >   recognised.
>> >> > > 2/ while suspended the GPIO interrupt should wake from suspend if and
>> >> > >only if irq_wake as been enabled.
>> >> > >
>> >> > > The code currently doesn't keep these two reasons separate so they get
>> >> > > confused and sometimes the wakeup flags is set incorrectly.
>> >> > >
>> >> > > This patch reverts:
>> >> > >  commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc
>> >> > > gpio/omap: remove suspend/resume callbacks
>> >> > > and
>> >> > >  commit 0aa2727399c0b78225021413022c164cb99fbc5e
>> >> > > gpio/omap: remove suspend_wakeup field from struct gpio_bank
>> >> > >
>> >> > > and makes some minor changes so that we have separate flags for "GPIO
>> >> > > should wake from deep idle" and "GPIO should wake from suspend".
>> >> > >
>> >> > > With this patch, the GPIO from my touch screen doesn't wake my device
>> >> > > any more, which is what I want.
>> >> > >
>> >> > > Cc: Kevin Hilman 
>> >> > > Cc: Tony Lindgren 
>> >> > > Cc: Santosh Shilimkar 
>> >> > > Cc: Cousson, Benoit 
>> >> > > Cc: Grant Likely 
>> >> > > Cc: Tarun Kanti DebBarma 
>> >> > > Cc: Felipe Balbi 
>> >> > > Cc: Govindraj.R 
>> >> > >
>> >> > > Signed-off-by: NeilBrown 
>> >> > >
>> >> > The patch doesn't seems to be correct. At least the 2/ gets
>> >> > fixed with a proper IRQCHIP flag. Can you try the patch at
>> >> > end of the email and see if it helps ? Am attaching it in case
>> >> > mailer damages it.
>> >> >
>> >> > Regards
>> >> > Santosh
>> >> >
>> >> > >From b8a38fc75e046f6462610e26c47c620cad850c24 Mon Sep 17 00:00:00 2001
>> >> > From: Santosh Shilimkar 
>> >> > Date: Sun, 26 Aug 2012 09:39:51 +0530
>> >> > Subject: [PATCH] gpio: omap: Set IRQCHIP_MASK_ON_SUSPEND to mask all
>> >> >  non-wakeup gpio wakeups.
>> >> >
>> >> > Set the irq chip flag IRQCHIP_MASK_ON_SUSPEND to cause the irq pm code
>> >> > to mask all non-wake gpios in suspend, which will ensure the wakeup
>> >> > enable
>> >> > bit is not set on non-wake gpios.
>> >> >
>> >> > Signed-off-by: Santosh Shilimkar 
>> >> > ---
>> >> >  drivers/gpio/gpio-omap.c |1 +
>> >> >  1 file changed, 1 insertion(+)
>> >> >
>> >> > diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
>> >> > index e6efd77..50b4c18 100644
>> >> > --- a/drivers/gpio/gpio-omap.c
>> >> > +++ b/drivers/gpio/gpio-omap.c
>> >> > @@ -779,6 +779,7 @@ static struct irq_chip gpio_irq_chip = {
>> >> >   .irq_unmask = gpio_unmask_irq,
>> >> >   .irq_set_type   = gpio_irq_type,
>> >> >   .irq_set_wake   = gpio_wake_enable,
>> >> > + .flags  = IRQCHIP_MASK_ON_SUSPEND;
>> >> >  };
>> >> >
>> >> >
>> >> > /*-*/
>> >>
>> >>
>> >> No obvious damage, unless the mailer is responsible or the ';' at the end
>> >> of
>> >> the line, rather than ',' :-)
>> >>
>> > :-) That was typo.
>> >
>> >> The approach makes sense, but does actually work.  Should be fixable
>> >> though.
>> >>
>> >> When I try this I get:
>> >>
>> >>
>> >>
>> >> [  158.114440] Checking wakeup interrupts
>> >> [  158.118408] Unhandled fault: external abort on non-linefetch (0x1028)
>> >> at 0xfb054040
>> >> [  158.126403] Internal error: : 1028 [#1] PREEMPT ARM
>> >> [  158.131500] Modules linked in: ipv6 g_ether hso libertas_sdio libertas
>> >> cfg80211
>> >> [  158.139190] CPU: 0Not tainted  (3.5.0-gta04-debug+ #2)
>> >> [  158.144927] PC is at _set_gpio_triggering+0x38/0x258
>> >> [  158.150115] LR is at gpio_mask_irq+0xac/0xc0
>> >> [  158.154602] pc : []lr : []psr: 6193
>> >> [  158.154602] sp : db521e90  ip : 0011  fp : beeecc2c
>> >> [  158.166595] r10: c05c8ebc  r9 : daa5a858  r8 : 0003
>> >> [  158.172027] r7 : a193  r6 :   r5 : fb054000  r4 : ded44e18
>> >> [  158.178863] r3 : 0001  r2 :   r1 : ded30340  r0 : 0040
>> >> [  158.185668] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
>> >> Segment use
>> >>
>> >> so it looks like runtime PM has turned off the iclk to the GPIO module so
>> >> that
>> >> when we try to tell it to change settings, it is no longer listening to
>> >> us.
>> > From the crash logs it 

linux-next: manual merge of the arm-soc tree with the usb tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the arm-soc tree got a conflict in
drivers/usb/host/Kconfig between commit 952230d774bb ("usb: ohci: Fix
Kconfig dependency on USB_ISP1301") from the usb tree and commit
d684f05f2d55 ("ARM: mach-pnx4008: Remove architecture") from the arm-soc
tree.

I fixed it up (see below) and can carry the fix as necessary (no action
required).
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/usb/host/Kconfig
index 13cd6d5,276add2..000
--- a/drivers/usb/host/Kconfig
+++ b/drivers/usb/host/Kconfig
@@@ -292,7 -292,7 +292,7 @@@ config USB_OHCI_HC
depends on USB && USB_ARCH_HAS_OHCI
select ISP1301_OMAP if MACH_OMAP_H2 || MACH_OMAP_H3
select USB_OTG_UTILS if ARCH_OMAP
-   depends on USB_ISP1301 || !(ARCH_LPC32XX || ARCH_PNX4008)
 -  select USB_ISP1301 if ARCH_LPC32XX
++  depends on USB_ISP1301 || !ARCH_LPC32XX
---help---
  The Open Host Controller Interface (OHCI) is a standard for accessing
  USB 1.1 host controller hardware.  It does more in hardware than 
Intel's


pgp98sWBXgWfB.pgp
Description: PGP signature

Re: [PATCHv2 2/4] Input: keypad: Add smsc ece1099 keypad driver

[Poddar, Sourav]

+ other external mailing list (did a reply to by mistake)

On Thu, Sep 6, 2012 at 11:04 AM, Poddar, Sourav  wrote:
> Hi Vaibhav,
>
> On Thu, Sep 6, 2012 at 12:01 AM, Vaibhav Hiremath  wrote:
>>
>>
>> On 9/5/2012 5:06 PM, Sourav Poddar wrote:
>>> From: G, Manjunath Kondaiah 
>>>
>>> SMSC ECE1099 is a keyboard scan or GPIO expansion device.The device
>>> supports a keypad scan matrix of 23*8.This driver uses this
>>> device as a keypad driver.
>>>
>>> Cc: Dmitry Torokhov 
>>> Cc: Benoit Cousson 
>>> Cc: Felipe Balbi 
>>> Cc: Santosh Shilimkar 
>>> Signed-off-by: G, Manjunath Kondaiah 
>>> Signed-off-by: Sourav Poddar 
>>> Acked-by: Felipe Balbi 
>>> ---
>>> Changes since v1:
>>>  - Prevent the use of kfree since devm_kzalloc was used.
>>>  - Use devexit around remove api
>>>  drivers/input/keyboard/Kconfig   |   11 +
>>>  drivers/input/keyboard/Makefile  |1 +
>>>  drivers/input/keyboard/smsc-ece1099-keypad.c |  306 
>>> ++
>>>  3 files changed, 318 insertions(+), 0 deletions(-)
>>>  create mode 100644 drivers/input/keyboard/smsc-ece1099-keypad.c
>>>
>>> diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
>>> index c50fa75..2a2d374 100644
>>> --- a/drivers/input/keyboard/Kconfig
>>> +++ b/drivers/input/keyboard/Kconfig
>>> @@ -593,6 +593,17 @@ config KEYBOARD_TWL4030
>>> To compile this driver as a module, choose M here: the
>>> module will be called twl4030_keypad.
>>>
>>> +config KEYBOARD_SMSC
>>> +   tristate "SMSC ECE1099 keypad support"
>>> +   depends on I2C=y
>>
>> Any specific reason behind "=y"
>>
> Nope, my bad.."=y" should be dropped.
>>> +   help
>>> + Say Y here if your board use the smsc keypad controller
>>> + for omap5 defconfig. It's safe to say enable this
>>> + even on boards that don't use the keypad controller.
>>> +
>>> + To compile this driver as a module, choose M here: the
>>> + module will be called smsc-ece1099-keypad.
>>> +
>>>  config KEYBOARD_XTKBD
>>>   tristate "XT keyboard"
>>>   select SERIO
>>> diff --git a/drivers/input/keyboard/Makefile 
>>> b/drivers/input/keyboard/Makefile
>>> index 44e7600..0f2aa26 100644
>>> --- a/drivers/input/keyboard/Makefile
>>> +++ b/drivers/input/keyboard/Makefile
>>> @@ -52,5 +52,6 @@ obj-$(CONFIG_KEYBOARD_TC3589X)  += 
>>> tc3589x-keypad.o
>>>  obj-$(CONFIG_KEYBOARD_TEGRA) += tegra-kbc.o
>>>  obj-$(CONFIG_KEYBOARD_TNETV107X) += tnetv107x-keypad.o
>>>  obj-$(CONFIG_KEYBOARD_TWL4030)   += twl4030_keypad.o
>>> +obj-$(CONFIG_KEYBOARD_SMSC)+= smsc-ece1099-keypad.o
>>>  obj-$(CONFIG_KEYBOARD_XTKBD) += xtkbd.o
>>>  obj-$(CONFIG_KEYBOARD_W90P910)   += w90p910_keypad.o
>>> diff --git a/drivers/input/keyboard/smsc-ece1099-keypad.c 
>>> b/drivers/input/keyboard/smsc-ece1099-keypad.c
>>> new file mode 100644
>>> index 000..71cd7d6
>>> --- /dev/null
>>> +++ b/drivers/input/keyboard/smsc-ece1099-keypad.c
>>> @@ -0,0 +1,306 @@
>>> +/*
>>> + * SMSC_ECE1099 Keypad driver
>>> + *
>>> + * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
>>> + *
>>> + * This program is free software; you can redistribute it and/or modify
>>> + * it under the terms of the GNU General Public License version 2 as
>>> + * published by the Free Software Foundation.
>>> + */
>>> +
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +#include 
>>> +
>>> +#define KEYPRESS_TIME  200
>>> +
>>> +struct smsc_keypad {
>>> + struct smsc *smsc;
>>> + struct matrix_keymap_data *keymap_data;
>>> + unsigned int last_key_state[16];
>>> + unsigned int last_col;
>>> + unsigned int last_key_ms[16];
>>> + unsigned short *keymap;
>>> + struct i2c_client *client;
>>> + struct input_dev *input;
>>> + int rows, cols;
>>> + int row_shift;
>>> + bool no_autorepeat;
>>> + unsignedirq;
>>> + struct device *dev;
>>> +};
>>> +
>>> +static void smsc_kp_scan(struct smsc_keypad *kp)
>>> +{
>>> + struct input_dev *input = kp->input;
>>> + int i, j;
>>> + int row, col;
>>> + int temp, code;
>>> + unsigned int new_state[16];
>>> + unsigned int bits_changed;
>>> + int this_ms;
>>> +
>>> + smsc_write(kp->dev, SMSC_KP_INT_MASK, 0x00);
>>> + smsc_write(kp->dev, SMSC_KP_INT_STAT, 0xFF);
>>> +
>>> + /* Scan for row and column */
>>> + for (i = 0; i < kp->cols; i++) {
>>> + smsc_write(kp->dev, SMSC_KP_OUT, SMSC_KSO_EVAL + i);
>>> + /* Read Row Status */
>>> + smsc_read(kp->dev, SMSC_KP_IN, );
>>> + if (temp == 0xFF)
>>> + continue;
>>> +
>>> + col = i;
>>> + for (j = 0; j < kp->rows; j++) {
>>> + if 

[PATCH v2] pwm: pwm-tiehrpwm: Fix conflicting channel period setting

[Philip, Avinash]

EHRPWM hardware supports 2 independent PWM channels. However the device
uses only one register to handle period setting for both channels. So
both channels should be configured for same period (in nsec).

Fix the same by returning error for conflicting period values.

However, allow
1. Configuration of period settings if not conflicting with other
channels
2. Re-configuring of period settings if no other channels being
configured

Signed-off-by: Philip, Avinash 
---
:100644 100644 c3756d1... b1996bc... M  drivers/pwm/pwm-tiehrpwm.c
 drivers/pwm/pwm-tiehrpwm.c |   29 +
 1 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
index c3756d1..b1996bc 100644
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@ -104,6 +104,7 @@ struct ehrpwm_pwm_chip {
struct pwm_chip chip;
unsigned intclk_rate;
void __iomem*mmio_base;
+   unsigned long period_cycles[NUM_PWM_CHANNEL];
 };
 
 static inline struct ehrpwm_pwm_chip *to_ehrpwm_pwm_chip(struct pwm_chip *chip)
@@ -210,6 +211,7 @@ static int ehrpwm_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
unsigned long long c;
unsigned long period_cycles, duty_cycles;
unsigned short ps_divval, tb_divval;
+   int i;
 
if (period_ns < 0 || duty_ns < 0 || period_ns > NSEC_PER_SEC)
return -ERANGE;
@@ -229,6 +231,28 @@ static int ehrpwm_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
duty_cycles = (unsigned long)c;
}
 
+   /*
+* Period values should be same for multiple PWM channels as IP uses
+* same period register for multiple channels.
+*/
+   for (i = 0; i < NUM_PWM_CHANNEL; i++) {
+   if (pc->period_cycles[i] &&
+   (pc->period_cycles[i] != period_cycles)) {
+   /*
+* Allow channel to reconfigure period if no other
+* channels being configured.
+*/
+   if (i == pwm->hwpwm)
+   continue;
+
+   dev_err(chip->dev, "Period value conflicts with channel 
%d\n",
+   i);
+   return -EINVAL;
+   }
+   }
+
+   pc->period_cycles[pwm->hwpwm] = period_cycles;
+
/* Configure clock prescaler to support Low frequency PWM wave */
if (set_prescale_div(period_cycles/PERIOD_MAX, _divval,
_divval)) {
@@ -320,10 +344,15 @@ static void ehrpwm_pwm_disable(struct pwm_chip *chip, 
struct pwm_device *pwm)
 
 static void ehrpwm_pwm_free(struct pwm_chip *chip, struct pwm_device *pwm)
 {
+   struct ehrpwm_pwm_chip *pc = to_ehrpwm_pwm_chip(chip);
+
if (test_bit(PWMF_ENABLED, >flags)) {
dev_warn(chip->dev, "Removing PWM device without disabling\n");
pm_runtime_put_sync(chip->dev);
}
+
+   /* set period value to zero on free */
+   pc->period_cycles[pwm->hwpwm] = 0;
 }
 
 static const struct pwm_ops ehrpwm_pwm_ops = {
-- 
1.7.1

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

Re: [PATCH 2/2] mm: support MIGRATE_DISCARD

[Minchan Kim]

Hi Mel,

On Wed, Sep 05, 2012 at 11:56:11AM +0100, Mel Gorman wrote:
> On Wed, Sep 05, 2012 at 05:11:13PM +0900, Minchan Kim wrote:
> > This patch introudes MIGRATE_DISCARD mode in migration.
> > It drops *clean cache pages* instead of migration so that
> > migration latency could be reduced by avoiding (memcpy + page remapping).
> > It's useful for CMA because latency of migration is very important rather
> > than eviction of background processes's workingset. In addition, it needs
> > less free pages for migration targets so it could avoid memory reclaiming
> > to get free pages, which is another factor increase latency.
> > 
> 
> Bah, this was released while I was reviewing the older version. I did
> not read this one as closely but I see the enum problems have gone away
> at least. I'd still prefer if CMA had an additional helper to discard
> some pages with shrink_page_list() and migrate the remaining pages with
> migrate_pages(). That would remove the need to add a MIGRATE_DISCARD
> migrate mode at all.

I am not convinced with your point. What's the benefit on separating
reclaim and migration? For just removing MIGRATE_DISCARD mode?
I don't think it's not bad because my implementation is very simple(maybe
it's much simpler than separating reclaim and migration) and
could be used by others like memory-hotplug in future.
If you're not strong against with me, I would like to insist on my 
implementation.

> 
> -- 
> Mel Gorman
> SUSE Labs
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
Kind regards,
Minchan Kim
--
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/2] pwm: pwm-tiehrpwm: Add support for configuring polarity of PWM

[Philip, Avinash]

EHRPWM hardware supports polarity configuration of PWM output. However
configuration of polarity done in hardware only in .enable() to ensure
PWM output present only after enabling PWM. This commit adds support for
polarity configuration for EHRPWM.
When being here, remove configuring of polarity during .config() and do
it explicitly from .set_polarity().

Signed-off-by: Philip, Avinash 
---
changes since v1:
- Remove config_chans API. Duty cycle configuration done in .cinfig()
- Introduce config_polarity API, as don't want to confuse the
  functionality of .enable()
- Introduce polarity member as array in private structure to handle
  both channels.

:100644 100644 b1996bc... db3675f... M  drivers/pwm/pwm-tiehrpwm.c
 drivers/pwm/pwm-tiehrpwm.c |   73 ++-
 1 files changed, 51 insertions(+), 22 deletions(-)

diff --git a/drivers/pwm/pwm-tiehrpwm.c b/drivers/pwm/pwm-tiehrpwm.c
index b1996bc..db3675f 100644
--- a/drivers/pwm/pwm-tiehrpwm.c
+++ b/drivers/pwm/pwm-tiehrpwm.c
@@ -81,6 +81,15 @@
 #define AQCTL_ZRO_FRCHIGH  BIT(1)
 #define AQCTL_ZRO_FRCTOGGLE(BIT(1) | BIT(0))
 
+#define AQCTL_CHANA_POLNORMAL  (AQCTL_CAU_FRCLOW | AQCTL_PRD_FRCHIGH | \
+   AQCTL_ZRO_FRCHIGH)
+#define AQCTL_CHANA_POLINVERSED(AQCTL_CAU_FRCHIGH | AQCTL_PRD_FRCLOW | 
\
+   AQCTL_ZRO_FRCLOW)
+#define AQCTL_CHANB_POLNORMAL  (AQCTL_CBU_FRCLOW | AQCTL_PRD_FRCHIGH | \
+   AQCTL_ZRO_FRCHIGH)
+#define AQCTL_CHANB_POLINVERSED(AQCTL_CBU_FRCHIGH | AQCTL_PRD_FRCLOW | 
\
+   AQCTL_ZRO_FRCLOW)
+
 #define AQSFRC_RLDCSF_MASK (BIT(7) | BIT(6))
 #define AQSFRC_RLDCSF_ZRO  0
 #define AQSFRC_RLDCSF_PRD  BIT(6)
@@ -105,6 +114,7 @@ struct ehrpwm_pwm_chip {
unsigned intclk_rate;
void __iomem*mmio_base;
unsigned long period_cycles[NUM_PWM_CHANNEL];
+   enum pwm_polarity polarity[NUM_PWM_CHANNEL];
 };
 
 static inline struct ehrpwm_pwm_chip *to_ehrpwm_pwm_chip(struct pwm_chip *chip)
@@ -165,39 +175,37 @@ static int set_prescale_div(unsigned long rqst_prescaler,
return 1;
 }
 
-static void configure_chans(struct ehrpwm_pwm_chip *pc, int chan,
-   unsigned long duty_cycles)
+static void configure_polarity(struct ehrpwm_pwm_chip *pc, int chan)
 {
-   int cmp_reg, aqctl_reg;
+   int aqctl_reg;
unsigned short aqctl_val, aqctl_mask;
 
/*
-* Channels can be configured from action qualifier module.
-* Channel 0 configured with compare A register and for
-* up-counter mode.
-* Channel 1 configured with compare B register and for
-* up-counter mode.
+* Configure PWM output to HIGH/LOW level on counter
+* reaches compare register value and LOW/HIGH level
+* on counter value reaches period register value and
+* zero value on counter
 */
if (chan == 1) {
aqctl_reg = AQCTLB;
-   cmp_reg = CMPB;
-   /* Configure PWM Low from compare B value */
-   aqctl_val = AQCTL_CBU_FRCLOW;
aqctl_mask = AQCTL_CBU_MASK;
+
+   if (pc->polarity[chan] == PWM_POLARITY_INVERSED)
+   aqctl_val = AQCTL_CHANB_POLINVERSED;
+   else
+   aqctl_val = AQCTL_CHANB_POLNORMAL;
} else {
-   cmp_reg = CMPA;
aqctl_reg = AQCTLA;
-   /* Configure PWM Low from compare A value*/
-   aqctl_val = AQCTL_CAU_FRCLOW;
aqctl_mask = AQCTL_CAU_MASK;
+
+   if (pc->polarity[chan] == PWM_POLARITY_INVERSED)
+   aqctl_val = AQCTL_CHANA_POLINVERSED;
+   else
+   aqctl_val = AQCTL_CHANA_POLNORMAL;
}
 
-   /* Configure PWM High from period value and zero value */
-   aqctl_val |= AQCTL_PRD_FRCHIGH | AQCTL_ZRO_FRCHIGH;
aqctl_mask |= AQCTL_PRD_MASK | AQCTL_ZRO_MASK;
-   ehrpwm_modify(pc->mmio_base,  aqctl_reg, aqctl_mask, aqctl_val);
-
-   ehrpwm_write(pc->mmio_base,  cmp_reg, duty_cycles);
+   ehrpwm_modify(pc->mmio_base, aqctl_reg, aqctl_mask, aqctl_val);
 }
 
 /*
@@ -211,7 +219,7 @@ static int ehrpwm_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
unsigned long long c;
unsigned long period_cycles, duty_cycles;
unsigned short ps_divval, tb_divval;
-   int i;
+   int i, cmp_reg;
 
if (period_ns < 0 || duty_ns < 0 || period_ns > NSEC_PER_SEC)
return -ERANGE;
@@ -278,12 +286,29 @@ static int ehrpwm_pwm_config(struct pwm_chip *chip, 
struct pwm_device *pwm,
ehrpwm_modify(pc->mmio_base, TBCTL, TBCTL_CTRMODE_MASK,
TBCTL_CTRMODE_UP);
 
-   /* Configure the channel for duty cycle */
-   configure_chans(pc, pwm->hwpwm, duty_cycles);
+   

[PATCH V2 1/2] pwm: pwm-tiecap: Add support for configuring polarity of PWM

[Philip, Avinash]

ECAP APWM hardware supports polarity configuration of PWM output.
This commit adds support for polarity configuration of ECAP APWM.

Signed-off-by: Philip, Avinash 
---
:100644 100644 4b66889... a3d21e7... M  drivers/pwm/pwm-tiecap.c
 drivers/pwm/pwm-tiecap.c |   22 ++
 1 files changed, 22 insertions(+), 0 deletions(-)

diff --git a/drivers/pwm/pwm-tiecap.c b/drivers/pwm/pwm-tiecap.c
index 4b66889..a3d21e7 100644
--- a/drivers/pwm/pwm-tiecap.c
+++ b/drivers/pwm/pwm-tiecap.c
@@ -32,6 +32,7 @@
 #define CAP3   0x10
 #define CAP4   0x14
 #define ECCTL2 0x2A
+#define ECCTL2_APWM_POL_LOWBIT(10)
 #define ECCTL2_APWM_MODE   BIT(9)
 #define ECCTL2_SYNC_SEL_DISA   (BIT(7) | BIT(6))
 #define ECCTL2_TSCTR_FREERUN   BIT(4)
@@ -111,6 +112,26 @@ static int ecap_pwm_config(struct pwm_chip *chip, struct 
pwm_device *pwm,
return 0;
 }
 
+static int ecap_pwm_set_polarity(struct pwm_chip *chip, struct pwm_device *pwm,
+   enum pwm_polarity polarity)
+{
+   struct ecap_pwm_chip *pc = to_ecap_pwm_chip(chip);
+   unsigned short reg_val;
+
+   pm_runtime_get_sync(pc->chip.dev);
+   reg_val = readw(pc->mmio_base + ECCTL2);
+   if (polarity == PWM_POLARITY_INVERSED)
+   /* Duty cycle defines LOW period of PWM */
+   reg_val |= ECCTL2_APWM_POL_LOW;
+   else
+   /* Duty cycle defines HIGH period of PWM */
+   reg_val &= ~ECCTL2_APWM_POL_LOW;
+
+   writew(reg_val, pc->mmio_base + ECCTL2);
+   pm_runtime_put_sync(pc->chip.dev);
+   return 0;
+}
+
 static int ecap_pwm_enable(struct pwm_chip *chip, struct pwm_device *pwm)
 {
struct ecap_pwm_chip *pc = to_ecap_pwm_chip(chip);
@@ -157,6 +178,7 @@ static void ecap_pwm_free(struct pwm_chip *chip, struct 
pwm_device *pwm)
 static const struct pwm_ops ecap_pwm_ops = {
.free   = ecap_pwm_free,
.config = ecap_pwm_config,
+   .set_polarity   = ecap_pwm_set_polarity,
.enable = ecap_pwm_enable,
.disable= ecap_pwm_disable,
.owner  = THIS_MODULE,
-- 
1.7.1

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

[PATCH V2 0/2] Support for configuring polarity of PWM

[Philip, Avinash]

These patch set adds support for configuring polarity of eCAP & eHRPWM.

Philip, Avinash (2):
  pwm: pwm-tiecap: Add support for configuring polarity of PWM
  pwm: pwm-tiehrpwm: Add support for configuring polarity of PWM

 drivers/pwm/pwm-tiecap.c   |   22 +
 drivers/pwm/pwm-tiehrpwm.c |   72 +++-
 2 files changed, 73 insertions(+), 21 deletions(-)

--
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] usb: phy: fix build break

[Venu Byravarasu]

During phy interface separation from otg.h, as the enum "usb_otg_state"
was having multiple otg states info and removal of member 'state'
of this enum type from usb_phy struct did not generate any compilation
issues, I removed member state from struct usb_phy.

As this is causing build break in musb code, adding member 'state'
to usb_phy structure.

Signed-off-by: Venu Byravarasu 
---
 include/linux/usb/otg.h |   24 
 include/linux/usb/phy.h |   25 +
 2 files changed, 25 insertions(+), 24 deletions(-)

diff --git a/include/linux/usb/otg.h b/include/linux/usb/otg.h
index 65a2b6a..e8a5fe8 100644
--- a/include/linux/usb/otg.h
+++ b/include/linux/usb/otg.h
@@ -11,30 +11,6 @@
 
 #include 
 
-/* OTG defines lots of enumeration states before device reset */
-enum usb_otg_state {
-   OTG_STATE_UNDEFINED = 0,
-
-   /* single-role peripheral, and dual-role default-b */
-   OTG_STATE_B_IDLE,
-   OTG_STATE_B_SRP_INIT,
-   OTG_STATE_B_PERIPHERAL,
-
-   /* extra dual-role default-b states */
-   OTG_STATE_B_WAIT_ACON,
-   OTG_STATE_B_HOST,
-
-   /* dual-role default-a */
-   OTG_STATE_A_IDLE,
-   OTG_STATE_A_WAIT_VRISE,
-   OTG_STATE_A_WAIT_BCON,
-   OTG_STATE_A_HOST,
-   OTG_STATE_A_SUSPEND,
-   OTG_STATE_A_PERIPHERAL,
-   OTG_STATE_A_WAIT_VFALL,
-   OTG_STATE_A_VBUS_ERR,
-};
-
 struct usb_otg {
u8  default_a;
 
diff --git a/include/linux/usb/phy.h b/include/linux/usb/phy.h
index 88fc160..06b5bae 100644
--- a/include/linux/usb/phy.h
+++ b/include/linux/usb/phy.h
@@ -26,6 +26,30 @@ enum usb_phy_type {
USB_PHY_TYPE_USB3,
 };
 
+/* OTG defines lots of enumeration states before device reset */
+enum usb_otg_state {
+   OTG_STATE_UNDEFINED = 0,
+
+   /* single-role peripheral, and dual-role default-b */
+   OTG_STATE_B_IDLE,
+   OTG_STATE_B_SRP_INIT,
+   OTG_STATE_B_PERIPHERAL,
+
+   /* extra dual-role default-b states */
+   OTG_STATE_B_WAIT_ACON,
+   OTG_STATE_B_HOST,
+
+   /* dual-role default-a */
+   OTG_STATE_A_IDLE,
+   OTG_STATE_A_WAIT_VRISE,
+   OTG_STATE_A_WAIT_BCON,
+   OTG_STATE_A_HOST,
+   OTG_STATE_A_SUSPEND,
+   OTG_STATE_A_PERIPHERAL,
+   OTG_STATE_A_WAIT_VFALL,
+   OTG_STATE_A_VBUS_ERR,
+};
+
 struct usb_phy;
 struct usb_otg;
 
@@ -43,6 +67,7 @@ struct usb_phy {
unsigned int flags;
 
enum usb_phy_type   type;
+   enum usb_otg_state  state;
enum usb_phy_events last_event;
 
struct usb_otg  *otg;
-- 
1.7.1.1

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

Re: [RFC 1/2] virtio_console: Add support for DMA memory allocation

[Michael S. Tsirkin]

On Thu, Sep 06, 2012 at 11:34:25AM +0930, Rusty Russell wrote:
> "Michael S. Tsirkin"  writes:
> > On Tue, Sep 04, 2012 at 06:58:47PM +0200, Sjur Brændeland wrote:
> >> Hi Michael,
> >> 
> >> > Exactly. Though if we just fail load it will be much less code.
> >> >
> >> > Generally, using a feature bit for this is a bit of a problem though:
> >> > normally driver is expected to be able to simply ignore
> >> > a feature bit. In this case driver is required to
> >> > do something so a feature bit is not a good fit.
> >> > I am not sure what the right thing to do is.
> >> 
> >> I see - so in order to avoid the binding between driver and device
> >> there are two options I guess. Either make virtio_dev_match() or
> >> virtcons_probe() fail. Neither of them seems like the obvious choice.
> >> 
> >> Maybe adding a check for VIRTIO_CONSOLE_F_DMA_MEM match
> >> between device and driver in virtcons_probe() is the lesser evil?
> >> 
> >> Regards,
> >> Sjur
> >
> > A simplest thing to do is change dev id. rusty?
> 
> For generic usage, this is correct.  But my opinion is that fallback on
> feature non-ack is quality-of-implementation issue: great to have, but
> there are cases where you just want to fail with "you're too old".
> 
> And in this case, an old system simply will never work.  So it's a
> question of how graceful the failure is.
> 
> Can your userspace loader can refuse to proceed if the driver doesn't
> ack the bits?  If so, it's simpler than a whole new ID.
> 
> Cheers,
> Rusty.

Yes but how can it signal guest that it will never proceed?

Also grep for BUG_ON in core found this:

   drv->remove(dev);

   /* Driver should have reset device. */
   BUG_ON(dev->config->get_status(dev));

I think below is what Sjur refers to.
I think below is a good idea for 3.6. Thoughts?

--->

virtio: don't crash when device is buggy

Because of a sanity check in virtio_dev_remove, a buggy device can crash
kernel.  And in case of rproc it's userspace so it's not a good idea.
We are unloading a driver so how bad can it be?
Be less aggressive in handling this error: if it's a driver bug,
warning once should be enough.

Signed-off-by: Michael S. Tsirkin 

--

diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index c3b3f7f..1e8659c 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -159,7 +159,7 @@ static int virtio_dev_remove(struct device *_d)
drv->remove(dev);
 
/* Driver should have reset device. */
-   BUG_ON(dev->config->get_status(dev));
+   WARN_ON_ONCE(dev->config->get_status(dev));
 
/* Acknowledge the device's existence again. */
add_status(dev, VIRTIO_CONFIG_S_ACKNOWLEDGE);

-- 
MST
--
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] audit: use list_move instead of list_del/list_add in audit-tree

[Wei Yongjun]

From: Wei Yongjun 

Using list_move() instead of list_del() + list_add().

spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)

Signed-off-by: Wei Yongjun 
---
 kernel/audit_tree.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/kernel/audit_tree.c b/kernel/audit_tree.c
index ed206fd..56c4a9e 100644
--- a/kernel/audit_tree.c
+++ b/kernel/audit_tree.c
@@ -585,8 +585,7 @@ void audit_trim_trees(void)
 
tree = container_of(cursor.next, struct audit_tree, list);
get_tree(tree);
-   list_del();
-   list_add(, >list);
+   list_move(, >list);
mutex_unlock(_filter_mutex);
 
err = kern_path(tree->pathname, 0, );
@@ -738,8 +737,7 @@ int audit_tag_tree(char *old, char *new)
 
tree = container_of(cursor.next, struct audit_tree, list);
get_tree(tree);
-   list_del();
-   list_add(, >list);
+   list_move(, >list);
mutex_unlock(_filter_mutex);
 
err = kern_path(tree->pathname, 0, );
@@ -764,8 +762,7 @@ int audit_tag_tree(char *old, char *new)
mutex_lock(_filter_mutex);
spin_lock(_lock);
if (!tree->goner) {
-   list_del(>list);
-   list_add(>list, _list);
+   list_move(>list, _list);
}
spin_unlock(_lock);
put_tree(tree);
@@ -776,8 +773,7 @@ int audit_tag_tree(char *old, char *new)
 
tree = container_of(barrier.prev, struct audit_tree, list);
get_tree(tree);
-   list_del(>list);
-   list_add(>list, );
+   list_move(>list, );
mutex_unlock(_filter_mutex);
 
if (!failed) {


--
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] kbuild rc fixes for v3.6

[Stephen Rothwell]

Hi Linus,

On Wed, 5 Sep 2012 20:32:00 -0700 Linus Torvalds 
 wrote:
>
> On Mon, Sep 3, 2012 at 12:18 PM, Michal Marek  wrote:
> >
> > The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee:
> >
> >   Linux 3.6-rc1 (2012-08-02 16:38:10 -0700)
> >
> > are available in the git repository at:
> >   git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6.git 
> > ..BRANCH.NOT.VERIFIED..
> 
> There's something wrong with that repo
> 
>  "fatal: Could not read from remote repository.
> 
>   Please make sure you have the correct access rights
>   and the repository exists."
> 
> plus that BRANCH.NOT.VERIFIED thing looks bad too (and is probably related).

The kbuild-current tree in linux-next is

git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild.git rc-fixes

and it has those 2 commits in it.  So script update needed, I guess.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgptjlcUQxw83.pgp
Description: PGP signature

[PATCH] clockevents: use list_move instead of list_del/list_add

[Wei Yongjun]

From: Wei Yongjun 

Using list_move() instead of list_del() + list_add().

spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)

Signed-off-by: Wei Yongjun 
---
 kernel/time/clockevents.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/kernel/time/clockevents.c b/kernel/time/clockevents.c
index 7e1ce01..8c4aac5 100644
--- a/kernel/time/clockevents.c
+++ b/kernel/time/clockevents.c
@@ -267,8 +267,7 @@ static void clockevents_notify_released(void)
while (!list_empty(_released)) {
dev = list_entry(clockevents_released.next,
 struct clock_event_device, list);
-   list_del(>list);
-   list_add(>list, _devices);
+   list_move(>list, _devices);
clockevents_do_notify(CLOCK_EVT_NOTIFY_ADD, dev);
}
 }
@@ -386,8 +385,7 @@ void clockevents_exchange_device(struct clock_event_device 
*old,
 */
if (old) {
clockevents_set_mode(old, CLOCK_EVT_MODE_UNUSED);
-   list_del(>list);
-   list_add(>list, _released);
+   list_move(>list, _released);
}
 
if (new) {

--
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 1/1] mmc: block: Add write packing control

[merez]

Hi Venkat,

Sorry for the late response. I came back from a long vacation and had many
issues to take care of.
If you still need a rebased version of the packed commands patches, I can
send a rebased version of the write packing control patch once Seungwon
Jeon will send the rebased version of the packing patches.
Please let us know if you ran into conflicts and it is required.

Thanks,
Maya
On Tue, August 28, 2012 10:40 am, S, Venkatraman wrote:
> On Mon, Aug 27, 2012 at 11:58 PM,   wrote:
>>
>> On Fri, July 27, 2012 2:07 am, S, Venkatraman wrote:
>>> On Fri, Jul 27, 2012 at 12:24 AM,   wrote:

 On Thu, July 26, 2012 8:28 am, S, Venkatraman wrote:
> On Tue, Jul 24, 2012 at 2:14 PM,   wrote:
>> On Mon, July 23, 2012 5:22 am, S, Venkatraman wrote:
>>> On Mon, Jul 23, 2012 at 5:13 PM,   wrote:
 On Wed, July 18, 2012 12:26 am, Chris Ball wrote:
> Hi,  [removing Jens and the documentation list, since now we're
>> talking about the MMC side only]
> On Wed, Jul 18 2012, me...@codeaurora.org wrote:
>> Is there anything else that holds this patch from being pushed
>> to
 mmc-next?
> Yes, I'm still uncomfortable with the write packing patchsets for
> a
 couple of reasons, and I suspect that the sum of those reasons
 means
 that
 we should probably plan on holding off merging it until after 3.6.
> Here are the open issues; please correct any misunderstandings:
> With
>> Seungwon's patchset ("Support packed write command"):
> * I still don't have a good set of representative benchmarks
> showing
>   what kind of performance changes come with this patchset.  It
> seems
 like we've had a small amount of testing on one controller/eMMC
 part
 combo
 from Seungwon, and an entirely different test from Maya, and the
>> results
 aren't documented fully anywhere to the level of describing what
 the
>> hardware was, what the test was, and what the results were before
>> and
>> after the patchset.
 Currently, there is only one card vendor that supports packed
 commands.
>> Following are our sequential write (LMDD) test results on 2 of our
>> targets
 (in MB/s):
No packingpacking
 Target 1 (SDR 50MHz) 15   25
 Target 2 (DDR 50MHz) 20   30
> With the reads-during-writes regression:
> * Venkat still has open questions about the nature of the read
>   regression, and thinks we should understand it with blktrace
> before
 trying to fix it.  Maya has a theory about writes overwhelming
 reads,
 but
 Venkat doesn't understand why this would explain the observed
 bandwidth drop.
 The degradation of read due to writes is not a new behavior and
 exists
>> also without the write packing feature (which only increases the
>> degradation). Our investigation of this phenomenon led us to the
>> Conclusion that a new scheduling policy should be used for mobile
>> devices,
 but this is not related to the current discussion of the write
 packing
>> feature.
 The write packing feature increases the degradation of read due to
>> write
 since it allows the MMC to fetch many write requests in a row,
 instead
 of
 fetching only one at a time.  Therefore some of the read requests
 will
>> have to wait for the completion of more write requests before they
>> can
>> be
 issued.
>>>
>>> I am a bit puzzled by this claim. One thing I checked carefully
>>> when
>> reviewing write packing patches from SJeon was that the code didn't
>> plough through a mixed list of reads and writes and selected only
>> writes.
>>> This section of the code in "mmc_blk_prep_packed_list()", from v8
>> patchset..
>>> 
>>> +   if (rq_data_dir(cur) != rq_data_dir(next)) {
>>> +   put_back = 1;
>>> +   break;
>>> +   }
>>> 
>>>
>>> means that once a read is encountered in the middle of write
>>> packing,
>> the packing is stopped at that point and it is executed. Then the
>> next
>> blk_fetch_request should get the next read and continue as before.
>>>
>>> IOW, the ordering of reads and writes is _not_ altered when using
>>> packed
>> commands.
>>> For example if there were 5 write requests, followed by 1 read,
>>> followed by 5 more write requests in the request_queue, the first 5
>> writes will be executed as one "packed command", then the read will
>> be
>> executed, and then the remaining 5 writes will be executed as one
>> "packed command". So the read 

[PATCH v2 3/3] memory-hotplug: bug fix race between isolation and allocation

[Minchan Kim]

Like below, memory-hotplug makes race between page-isolation
and page-allocation so it can hit BUG_ON in __offline_isolated_pages.

CPU A   CPU B

start_isolate_page_range
set_migratetype_isolate
spin_lock_irqsave(zone->lock)

free_hot_cold_page(Page A)
/* without zone->lock */
migratetype = get_pageblock_migratetype(Page A);
/*
 * Page could be moved into MIGRATE_MOVABLE
 * of per_cpu_pages
 */
list_add_tail(>lru, 
>lists[migratetype]);

set_pageblock_isolate
move_freepages_block
drain_all_pages

/* Page A could be in MIGRATE_MOVABLE of 
free_list. */

check_pages_isolated
__test_page_isolated_in_pageblock
/*
 * We can't catch freed page which
 * is free_list[MIGRATE_MOVABLE]
 */
if (PageBuddy(page A))
pfn += 1 << page_order(page A);

/* So, Page A could be allocated */

__offline_isolated_pages
/*
 * BUG_ON hit or offline page
 * which is used by someone
 */
BUG_ON(!PageBuddy(page A));

This patch checks page's migratetype in freelist in 
__test_page_isolated_in_pageblock.
So now __test_page_isolated_in_pageblock can check the page caused by above 
race and
can fail of memory offlining.

Signed-off-by: Minchan Kim 
---
 mm/page_isolation.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/mm/page_isolation.c b/mm/page_isolation.c
index 87a7929..7ba7405 100644
--- a/mm/page_isolation.c
+++ b/mm/page_isolation.c
@@ -193,8 +193,11 @@ __test_page_isolated_in_pageblock(unsigned long pfn, 
unsigned long end_pfn)
continue;
}
page = pfn_to_page(pfn);
-   if (PageBuddy(page))
+   if (PageBuddy(page)) {
+   if (get_freepage_migratetype(page) != MIGRATE_ISOLATE)
+   break;
pfn += 1 << page_order(page);
+   }
else if (page_count(page) == 0 &&
get_freepage_migratetype(page) == MIGRATE_ISOLATE)
pfn += 1;
-- 
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 2/3] mm: remain migratetype in freed page

[Minchan Kim]

The page allocator caches the pageblock information in page->private while
it is in the PCP freelists but this is overwritten with the order of the
page when freed to the buddy allocator. This patch stores the migratetype
of the page in the page->index field so that it is available at all times
when the page remain in free_list.

This patch adds a new call site in __free_pages_ok so it might be
overhead a bit but it's for high order allocation.
So I believe damage isn't hurt.

* from v1
  * Fix move_freepages's migratetype - Mel
  * Add more kind explanation in description - Mel

Signed-off-by: Minchan Kim 
---
 include/linux/mm.h |4 ++--
 mm/page_alloc.c|7 +--
 2 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 84d1663f..68f9e8d 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -240,13 +240,13 @@ struct inode;
 /* It's valid only if the page is free path or free_list */
 static inline void set_freepage_migratetype(struct page *page, int migratetype)
 {
-   set_page_private(page, migratetype);
+   page->index = migratetype;
 }
 
 /* It's valid only if the page is free path or free_list */
 static inline int get_freepage_migratetype(struct page *page)
 {
-   return page_private(page);
+   return page->index;
 }
 
 /*
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index f5ba236..8531fa3 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -723,6 +723,7 @@ static void __free_pages_ok(struct page *page, unsigned int 
order)
 {
unsigned long flags;
int wasMlocked = __TestClearPageMlocked(page);
+   int migratetype;
 
if (!free_pages_prepare(page, order))
return;
@@ -731,8 +732,9 @@ static void __free_pages_ok(struct page *page, unsigned int 
order)
if (unlikely(wasMlocked))
free_page_mlock(page);
__count_vm_events(PGFREE, 1 << order);
-   free_one_page(page_zone(page), page, order,
-   get_pageblock_migratetype(page));
+   migratetype = get_pageblock_migratetype(page);
+   set_freepage_migratetype(page, migratetype);
+   free_one_page(page_zone(page), page, order, migratetype);
local_irq_restore(flags);
 }
 
@@ -952,6 +954,7 @@ static int move_freepages(struct zone *zone,
order = page_order(page);
list_move(>lru,
  >free_area[order].free_list[migratetype]);
+   set_freepage_migratetype(page, migratetype);
page += 1 << order;
pages_moved += 1 << order;
}
-- 
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/3] use get_page_migratetype instead of page_private

[Minchan Kim]

page allocator uses set_page_private and page_private for handling
migratetype when it frees page. Let's replace them with [set|get]
_freepage_migratetype to make it more clear.

* from v1
  * Change set_page_migratetype with set_freepage_migratetype
  * Add comment on set_freepage_migratetype

Signed-off-by: Minchan Kim 
---
 include/linux/mm.h  |   12 
 mm/page_alloc.c |   10 ++
 mm/page_isolation.c |2 +-
 3 files changed, 19 insertions(+), 5 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0514fe9..84d1663f 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -237,6 +237,18 @@ struct inode;
 #define page_private(page) ((page)->private)
 #define set_page_private(page, v)  ((page)->private = (v))
 
+/* It's valid only if the page is free path or free_list */
+static inline void set_freepage_migratetype(struct page *page, int migratetype)
+{
+   set_page_private(page, migratetype);
+}
+
+/* It's valid only if the page is free path or free_list */
+static inline int get_freepage_migratetype(struct page *page)
+{
+   return page_private(page);
+}
+
 /*
  * FIXME: take this include out, include page-flags.h in
  * files which need it (119 of them)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index ba3100a..f5ba236 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -671,8 +671,10 @@ static void free_pcppages_bulk(struct zone *zone, int 
count,
/* must delete as __free_one_page list manipulates */
list_del(>lru);
/* MIGRATE_MOVABLE list may include MIGRATE_RESERVEs */
-   __free_one_page(page, zone, 0, page_private(page));
-   trace_mm_page_pcpu_drain(page, 0, page_private(page));
+   __free_one_page(page, zone, 0,
+   get_freepage_migratetype(page));
+   trace_mm_page_pcpu_drain(page, 0,
+   get_freepage_migratetype(page));
} while (--to_free && --batch_free && !list_empty(list));
}
__mod_zone_page_state(zone, NR_FREE_PAGES, count);
@@ -1134,7 +1136,7 @@ static int rmqueue_bulk(struct zone *zone, unsigned int 
order,
if (!is_migrate_cma(mt) && mt != MIGRATE_ISOLATE)
mt = migratetype;
}
-   set_page_private(page, mt);
+   set_freepage_migratetype(page, mt);
list = >lru;
}
__mod_zone_page_state(zone, NR_FREE_PAGES, -(i << order));
@@ -1301,7 +1303,7 @@ void free_hot_cold_page(struct page *page, int cold)
return;
 
migratetype = get_pageblock_migratetype(page);
-   set_page_private(page, migratetype);
+   set_freepage_migratetype(page, migratetype);
local_irq_save(flags);
if (unlikely(wasMlocked))
free_page_mlock(page);
diff --git a/mm/page_isolation.c b/mm/page_isolation.c
index 247d1f1..87a7929 100644
--- a/mm/page_isolation.c
+++ b/mm/page_isolation.c
@@ -196,7 +196,7 @@ __test_page_isolated_in_pageblock(unsigned long pfn, 
unsigned long end_pfn)
if (PageBuddy(page))
pfn += 1 << page_order(page);
else if (page_count(page) == 0 &&
-   page_private(page) == MIGRATE_ISOLATE)
+   get_freepage_migratetype(page) == MIGRATE_ISOLATE)
pfn += 1;
else
break;
-- 
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/3] memory-hotplug: handle page race between allocation and isolation

[Minchan Kim]

Memory hotplug has a subtle race problem so this patchset fixes the problem
(Look at [3/3] for detail and please confirm the problem before review
other patches in this series.)

 [1/3] is just clean up and help for [2/3].
 [2/3] keeps the migratetype information to freed page's index field
   and [3/3] uses the information.
 [3/3] fixes the race problem with [2/3]'s information.

After applying [2/3], migratetype argument in __free_one_page
and free_one_page is redundant so we can remove it but I decide
to not touch them because it increases code size about 50 byte.

Minchan Kim (3):
  use get_page_migratetype instead of page_private
  mm: remain migratetype in freed page
  memory-hotplug: bug fix race between isolation and allocation

 include/linux/mm.h  |   12 
 mm/page_alloc.c |   17 +++--
 mm/page_isolation.c |7 +--
 3 files changed, 28 insertions(+), 8 deletions(-)

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

linux-next: build failure after merge of the tty tree

[Stephen Rothwell]

Hi Greg,

After merging the tty tree, today's linux-next build (x86_64 allmodconfig)
failed like this:

In file included from drivers/tty/serial/sccnxp.c:20:0:
include/linux/serial_core.h: In function 'uart_handle_break':
include/linux/serial_core.h:543:30: error: dereferencing pointer to incomplete 
type

Caused by commit 1d65c0b12656 ("serial: New serial driver SCCNXP").  This
seems to be just exposing a preexisting problem with linux/serial_core.h:
when SUPPORT_SYSRQ is defined, this header depends on linux/console.h.  I
can only imagein that every other use of serial_core.h pre-includes
(maybe indirectly) console.h (or doesn't define SUPPORT_SYSRQ).

I have applied the following patch, but a better solution should be
figured out.

From: Stephen Rothwell 
Date: Thu, 6 Sep 2012 15:05:04 +1000
Subject: [PATCH] serial: serial_core.h needs console.h included first

Fixes these build errors:

In file included from drivers/tty/serial/sccnxp.c:20:0:
include/linux/serial_core.h: In function 'uart_handle_break':
include/linux/serial_core.h:543:30: error: dereferencing pointer to incomplete 
type

Signed-off-by: Stephen Rothwell 
---
 drivers/tty/serial/sccnxp.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/sccnxp.c b/drivers/tty/serial/sccnxp.c
index 29dda9b..05d767c 100644
--- a/drivers/tty/serial/sccnxp.c
+++ b/drivers/tty/serial/sccnxp.c
@@ -17,12 +17,12 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
-- 
1.7.10.280.gaa39

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgp0daI40tn6h.pgp
Description: PGP signature

Re: A workaround for request_firmware() stuck in module_init

[Benjamin Herrenschmidt]

On Thu, 2012-09-06 at 00:18 +0100, Alan Cox wrote:
> > But then you have cases where probe() -> register_with_my_subsystem() ->
> > open(). Network devices come to mind. IE. udev must be able to deal with
> > a synchronous firmware load from probe I'm afraid.
> 
> I don't believe so. You have
> 
>   begin probe
>   find match .. .firmware_name is set
>   issue firmware load request
>   set defer flag
>   end probe
> 
> Later..
> 
>   firmware load complete
>   kick probe up arse
> 
>   begin probe
>   find match .. .firmware is loaded
>   call ->probe()
>   register
>   open
>   happiness
>   end probe

Ok, so this is my fault for picking the thread half way through and
missing the crucial point ... deferring probe() itself. BTW. Deferring
probe is useful for other things.

I've long advocated this as a way to deal with various soft dependencies
between services for example. Cases of a driver hooking up to two or 3
different busses, and wanting all the bits to be actually probed &
connected to each other in order, that sort of thing.

This can be done by defining the initialization order, have the "late"
ones defer when the depend aren't initialized yet, and kick probe arse
from bus notifiers (tho that could be moved to the core via some
helpers).

Cheers,
Ben.



--
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 2/2] virtio-ring: Allocate indirect buffers from cache when possible

[Michael S. Tsirkin]

On Thu, Sep 06, 2012 at 10:32:48AM +0930, Rusty Russell wrote:
> Sasha Levin  writes:
> >> On Wed, Aug 29, 2012 at 05:03:03PM +0200, Sasha Levin wrote:
> >>> I've also re-ran it on a IBM server type host instead of my laptop. Here 
> >>> are the
> >>> results:
> >>>
> >>> Vanilla kernel:
> >>>
> >>> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 
> >>> 192.168.33.1
> >>> () port 0 AF_INET
> >>> enable_enobufs failed: getprotobyname
> >>> Recv   SendSend
> >>> Socket Socket  Message  Elapsed
> >>> Size   SizeSize Time Throughput
> >>> bytes  bytes   bytessecs.10^6bits/sec
> >>>
> >>>  87380  16384  1638410.007922.72
> >>>
> >>> Patch 1, with threshold=16:
> >>>
> >>> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 
> >>> 192.168.33.1
> >>> () port 0 AF_INET
> >>> enable_enobufs failed: getprotobyname
> >>> Recv   SendSend
> >>> Socket Socket  Message  Elapsed
> >>> Size   SizeSize Time Throughput
> >>> bytes  bytes   bytessecs.10^6bits/sec
> >>>
> >>>  87380  16384  1638410.008415.07
> >>>
> >>> Patch 2:
> >>>
> >>> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 
> >>> 192.168.33.1
> >>> () port 0 AF_INET
> >>> enable_enobufs failed: getprotobyname
> >>> Recv   SendSend
> >>> Socket Socket  Message  Elapsed
> >>> Size   SizeSize Time Throughput
> >>> bytes  bytes   bytessecs.10^6bits/sec
> >>>
> >>>  87380  16384  1638410.008931.05
> >>>
> >>>
> >>> Note that these are simple tests with netperf listening on one end and a 
> >>> simple
> >>> 'netperf -H [host]' within the guest. If there are other tests which may 
> >>> be
> >>> interesting please let me know.
> 
> It might be worth just unconditionally having a cache for the 2
> descriptor case.  This is what I get with qemu tap, though for some
> reason the device features don't have guest or host CSUM, so my setup is
> probably screwed:

Yes without checksum net core always linearizes packets, so yes it is
screwed.
For -net, skb always allocates space for 17 frags + linear part so
it seems sane to do same in virtio core, and allocate, for -net,
up to max_frags + 1 from cache.
We can adjust it: no _SG -> 2 otherwise 18.

Not sure about other drivers, maybe really use 2 there for now.

> Queue histogram for virtio0:
> Size distribution for input (max=128427):
>   1: 128427  
> Size distribution for output (max=256485):
>   2: 256485  
> Size distribution for control (max=10):
>   3: 10  
>   4: 5   
> 
> Here's a patch, what do you get (run ifconfig to trigger the dump; yeah,
> it's a hack!)
> 
> Hack: histogram of buffer sizes for virtio devices.
> 
> Currently triggered by a stats query (eg ifconfig) on a net device.
> 
> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
> --- a/drivers/net/virtio_net.c
> +++ b/drivers/net/virtio_net.c
> @@ -727,6 +727,8 @@ static struct rtnl_link_stats64 *virtnet
>   tot->rx_length_errors = dev->stats.rx_length_errors;
>   tot->rx_frame_errors = dev->stats.rx_frame_errors;
>  
> + virtio_dev_dump_histogram(vi->vdev);
> +
>   return tot;
>  }
>  
> diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
> --- a/drivers/virtio/virtio.c
> +++ b/drivers/virtio/virtio.c
> @@ -108,6 +108,16 @@ void virtio_check_driver_offered_feature
>  }
>  EXPORT_SYMBOL_GPL(virtio_check_driver_offered_feature);
>  
> +void virtio_dev_dump_histogram(const struct virtio_device *vdev)
> +{
> + const struct virtqueue *vq;
> +
> + printk("Queue histogram for %s:\n", dev_name(>dev));
> + list_for_each_entry(vq, >vqs, list)
> + virtqueue_dump_histogram(vq);
> +}
> +EXPORT_SYMBOL_GPL(virtio_dev_dump_histogram);
> +
>  static int virtio_dev_probe(struct device *_d)
>  {
>   int err, i;
> diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
> --- a/drivers/virtio/virtio_ring.c
> +++ b/drivers/virtio/virtio_ring.c
> @@ -120,6 +120,8 @@ struct vring_virtqueue
>   ktime_t last_add_time;
>  #endif
>  
> + unsigned int *histo;
> +
>   /* Tokens for callbacks. */
>   void *data[];
>  };
> @@ -259,6 +261,8 @@ int virtqueue_add_buf(struct virtqueue *
>   BUG_ON(out + in > vq->vring.num);
>   BUG_ON(out + in == 0);
>  
> + vq->histo[out+in]++;
> +
>   /* If the host supports indirect descriptor tables, consider it. */
>   if (vq->indirect) {
>   bool try_indirect;
> @@ -726,6 +730,7 @@ struct virtqueue *vring_new_virtqueue(un
>   }
>   vq->data[i] = NULL;
>  
> + vq->histo = kzalloc(num * sizeof(vq->histo[0]), GFP_KERNEL);
>   return >vq;
>  }
>  EXPORT_SYMBOL_GPL(vring_new_virtqueue);
> @@ -772,4 +777,33 @@ unsigned int 

[PATCH] [v2] sata_fsl: add workaround for data length mismatch on freescale V2 controller

[Shaohui Xie]

The freescale V2 SATA controller checks if the received data length matches
the programmed length 'ttl', if not, it assumes that this is an error.
In ATAPI, the 'ttl' is based on max allocation length and not the actual
data transfer length, controller will raise 'DLM' (Data length Mismatch)
error bit in Hstatus register. Along with 'DLM', DE (Device error) and
FE (fatal Error) bits are also set in Hstatus register, 'E' (Internal Error)
bit is set in Serror register and CE (Command Error) and DE (Device error)
registers have the corresponding bit set. In this condition, we need to
clear errors in following way: in the service routine, based on 'DLM' flag,
HCONTROL[27] operation clears Hstatus, CE and DE registers, clear Serror
register.

Signed-off-by: Shaohui Xie 
Signed-off-by: Anju Bhartiya 
---
changes for V2:
1. remove the using of quirk;
2. wrap errata codes in condition;

 drivers/ata/sata_fsl.c |   40 +++-
 1 files changed, 35 insertions(+), 5 deletions(-)

diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c
index d6577b9..6b7b73e 100644
--- a/drivers/ata/sata_fsl.c
+++ b/drivers/ata/sata_fsl.c
@@ -143,6 +143,7 @@ enum {
FATAL_ERR_CRC_ERR_RX |
FATAL_ERR_FIFO_OVRFL_TX | FATAL_ERR_FIFO_OVRFL_RX,
 
+   INT_ON_DATA_LENGTH_MISMATCH = (1 << 12),
INT_ON_FATAL_ERR = (1 << 5),
INT_ON_PHYRDY_CHG = (1 << 4),
 
@@ -1180,26 +1181,55 @@ static void sata_fsl_host_intr(struct ata_port *ap)
void __iomem *hcr_base = host_priv->hcr_base;
u32 hstatus, done_mask = 0;
struct ata_queued_cmd *qc;
-   u32 SError;
+   u32 SError, tag;
+   u32 status_mask = INT_ON_ERROR;
 
hstatus = ioread32(hcr_base + HSTATUS);
 
sata_fsl_scr_read(>link, SCR_ERROR, );
 
+   /* Read command completed register */
+   done_mask = ioread32(hcr_base + CC);
+
+   /* Workaround for data length mismatch errata */
+   if (unlikely(hstatus & INT_ON_DATA_LENGTH_MISMATCH)) {
+   for (tag = 0; tag < ATA_MAX_QUEUE; tag++) {
+   qc = ata_qc_from_tag(ap, tag);
+   if (qc && ata_is_atapi(qc->tf.protocol)) {
+   u32 Hcontrol;
+#define HCONTROL_CLEAR_ERROR   (1 << 27)
+   /* Set HControl[27] to clear error registers */
+   Hcontrol = ioread32(hcr_base + HCONTROL);
+   iowrite32(Hcontrol | HCONTROL_CLEAR_ERROR,
+   hcr_base + HCONTROL);
+
+   /* Clear HControl[27] */
+   iowrite32(Hcontrol & (~HCONTROL_CLEAR_ERROR),
+   hcr_base + HCONTROL);
+
+   /* Clear SError[E] bit */
+   sata_fsl_scr_write(>link, SCR_ERROR,
+   SError);
+
+   /* Ignore fatal error and device error */
+   status_mask &= ~(INT_ON_SINGL_DEVICE_ERR
+   | INT_ON_FATAL_ERR);
+   break;
+   }
+   }
+   }
+
if (unlikely(SError & 0x)) {
DPRINTK("serror @host_intr : 0x%x\n", SError);
sata_fsl_error_intr(ap);
}
 
-   if (unlikely(hstatus & INT_ON_ERROR)) {
+   if (unlikely(hstatus & status_mask)) {
DPRINTK("error interrupt!!\n");
sata_fsl_error_intr(ap);
return;
}
 
-   /* Read command completed register */
-   done_mask = ioread32(hcr_base + CC);
-
VPRINTK("Status of all queues :\n");
VPRINTK("done_mask/CC = 0x%x, CA = 0x%x, CE=0x%x,CQ=0x%x,apqa=0x%x\n",
done_mask,
-- 
1.6.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/

linux-next: build failure after merge of the driver-core tree (workqueues tree related)

[Stephen Rothwell]

Hi Greg, Tejun,

After merging the driver-core tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/extcon/extcon-adc-jack.c: In function 'adc_jack_probe':
drivers/extcon/extcon-adc-jack.c:146:2: error: implicit declaration of function 
'INIT_DELAYED_WORK_DEFERRABLE' [-Werror=implicit-function-declaration]

Caused by commit 19939860dcae ("extcon: adc_jack: adc-jack driver to
support 3.5 pi or simliar devices") from the driver-core tree interacting
with commit 203b42f73174 ("workqueue: make deferrable delayed_work
initializer names consistent") from the workqueues tree.

I have added this merge fix patch (no action is required):

From: Stephen Rothwell 
Date: Thu, 6 Sep 2012 14:45:26 +1000
Subject: [PATCH] extcon: adc_jack: update for INIT_DELAYED_WORK_DEFERRABLE
 name change

Signed-off-by: Stephen Rothwell 
---
 drivers/extcon/extcon-adc-jack.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/extcon/extcon-adc-jack.c b/drivers/extcon/extcon-adc-jack.c
index 60ac3fb..725eb5a 100644
--- a/drivers/extcon/extcon-adc-jack.c
+++ b/drivers/extcon/extcon-adc-jack.c
@@ -143,7 +143,7 @@ static int __devinit adc_jack_probe(struct platform_device 
*pdev)
 
data->handling_delay = msecs_to_jiffies(pdata->handling_delay_ms);
 
-   INIT_DELAYED_WORK_DEFERRABLE(>handler, adc_jack_handler);
+   INIT_DEFERRABLE_WORK(>handler, adc_jack_handler);
 
platform_set_drvdata(pdev, data);
 
-- 
1.7.10.280.gaa39

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/


pgpM9M4GNPHio.pgp
Description: PGP signature

Re: [PATCH 3/3] memory-hotplug: bug fix race between isolation and allocation

[Minchan Kim]

On Wed, Sep 05, 2012 at 10:40:41AM +0100, Mel Gorman wrote:
> On Wed, Sep 05, 2012 at 04:26:02PM +0900, Minchan Kim wrote:
> > Like below, memory-hotplug makes race between page-isolation
> > and page-allocation so it can hit BUG_ON in __offline_isolated_pages.
> > 
> > CPU A   CPU B
> > 
> > start_isolate_page_range
> > set_migratetype_isolate
> > spin_lock_irqsave(zone->lock)
> > 
> > free_hot_cold_page(Page A)
> > /* without zone->lock */
> > migratetype = get_pageblock_migratetype(Page A);
> > /*
> >  * Page could be moved into MIGRATE_MOVABLE
> >  * of per_cpu_pages
> >  */
> > list_add_tail(>lru, 
> > >lists[migratetype]);
> > 
> > set_pageblock_isolate
> > move_freepages_block
> > drain_all_pages
> > 
> > /* Page A could be in MIGRATE_MOVABLE of 
> > free_list. */
> > 
> > check_pages_isolated
> > __test_page_isolated_in_pageblock
> > /*
> >  * We can't catch freed page which
> >  * is free_list[MIGRATE_MOVABLE]
> >  */
> > if (PageBuddy(page A))
> > pfn += 1 << page_order(page A);
> > 
> > /* So, Page A could be allocated */
> > 
> > __offline_isolated_pages
> > /*
> >  * BUG_ON hit or offline page
> >  * which is used by someone
> >  */
> > BUG_ON(!PageBuddy(page A));
> > 
> 
> offline_page calling BUG_ON because someone allocated the page is
> ridiculous. I did not spot where that check is but it should be changed. The
> correct action is to retry the isolation.

It is where __offline_isolated_pges.

..
while (pfn < end_pfn) {
if (!pfn_valid(pfn)) {
pfn++;
continue;
}
page = pfn_to_page(pfn);
BUG_ON(page_count(page));
BUG_ON(!PageBuddy(page)); < HERE
order = page_order(page);
...

Comment of offline_isolated_pages says following as.

We cannot do rollback at this point

So if the comment is true, BUG_ON does make sense to me.
But I don't see why we can't retry it as I look thorugh code.
Anyway, It's another story which isn't related to this patch.

> 
> > Signed-off-by: Minchan Kim 
> 
> At no point in the changelog do you actually say what he patch does :/

Argh, I will do.

> 
> > ---
> >  mm/page_isolation.c |5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> > 
> > diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> > index acf65a7..4699d1f 100644
> > --- a/mm/page_isolation.c
> > +++ b/mm/page_isolation.c
> > @@ -196,8 +196,11 @@ __test_page_isolated_in_pageblock(unsigned long pfn, 
> > unsigned long end_pfn)
> > continue;
> > }
> > page = pfn_to_page(pfn);
> > -   if (PageBuddy(page))
> > +   if (PageBuddy(page)) {
> > +   if (get_page_migratetype(page) != MIGRATE_ISOLATE)
> > +   break;
> > pfn += 1 << page_order(page);
> > +   }
> 
> It is possible the page is moved to the MIGRATE_ISOLATE list between when
> the page was freed to the buddy allocator and this check was made. The
> page->index information is stale and the impact is that the hotplug
> operation fails when it could have succeeded. That said, I think it is a
> very unlikely race that will never happen in practice.

I understand you mean move_freepages which I have missed. Right?
Then, I will fix it, too.

> 
> More importantly, the effect of this path is that EBUSY gets bubbled all
> the way up and the hotplug operations fails. This is fine but as the page
> is free at the time this problem is detected you also have the option
> of moving the PageBuddy page to the MIGRATE_ISOLATE list at this time
> if you take the zone lock. This will mean you need to change the name of
> test_pages_isolated() of course.

Sorry, I can't get your point. Could you elaborate it more?
Is it related to this patch?


> 
> > else if (page_count(page) == 0 &&
> > get_page_migratetype(page) == MIGRATE_ISOLATE)
> > pfn += 1;
> > -- 
> > 1.7.9.5
> > 
> 
> -- 
> Mel Gorman
> SUSE Labs
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
Kind regards,
Minchan Kim
--
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] staging: wlags49_h2: use list_move instead of list_del/list_add

[Wei Yongjun]

From: Wei Yongjun 

Using list_move() instead of list_del() + list_add().

spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)

Signed-off-by: Wei Yongjun 
---
 drivers/staging/wlags49_h2/wl_netdev.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/wlags49_h2/wl_netdev.c 
b/drivers/staging/wlags49_h2/wl_netdev.c
index 824b852..e401b49 100644
--- a/drivers/staging/wlags49_h2/wl_netdev.c
+++ b/drivers/staging/wlags49_h2/wl_netdev.c
@@ -836,8 +836,7 @@ int wl_tx( struct sk_buff *skb, struct net_device *dev, int 
port )
 txF->frame.port = port;
 /* Move the frame to the txQ */
 /* NOTE: Here's where we would do priority queueing */
-list_del( &( txF->node ));
-list_add( &( txF->node ), &( lp->txQ[0] ));
+list_move(&(txF->node), &(lp->txQ[0]));
 
 lp->txQ_count++;
 if( lp->txQ_count >= DEFAULT_NUM_TX_FRAMES ) {

--
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] staging: gdm72xx: use list_move instead of list_del/list_add

[Wei Yongjun]

From: Wei Yongjun 

Using list_move() instead of list_del() + list_add().

spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)

Signed-off-by: Wei Yongjun 
---
 drivers/staging/gdm72xx/gdm_usb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/staging/gdm72xx/gdm_usb.c 
b/drivers/staging/gdm72xx/gdm_usb.c
index d48d49c..b74442f 100644
--- a/drivers/staging/gdm72xx/gdm_usb.c
+++ b/drivers/staging/gdm72xx/gdm_usb.c
@@ -189,8 +189,7 @@ static struct usb_rx *get_rx_struct(struct rx_cxt *rx)
 /* Before this function is called, spin lock should be locked. */
 static void put_rx_struct(struct rx_cxt *rx, struct usb_rx *r)
 {
-   list_del(>list);
-   list_add(>list, >free_list);
+   list_move(>list, >free_list);
 }
 
 static int init_usb(struct usbwm_dev *udev)

--
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] iommu/exynos: use list_del_init instead of list_del/INIT_LIST_HEAD

[Wei Yongjun]

From: Wei Yongjun 

Using list_del_init() instead of list_del() + INIT_LIST_HEAD().

spatch with a semantic match is used to found this problem.
(http://coccinelle.lip6.fr/)

Signed-off-by: Wei Yongjun 
---
 drivers/iommu/exynos-iommu.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/iommu/exynos-iommu.c b/drivers/iommu/exynos-iommu.c
index 80bad32..7fe44f8 100644
--- a/drivers/iommu/exynos-iommu.c
+++ b/drivers/iommu/exynos-iommu.c
@@ -840,8 +840,7 @@ static void exynos_iommu_detach_device(struct iommu_domain 
*domain,
if (__exynos_sysmmu_disable(data)) {
dev_dbg(dev, "%s: Detached IOMMU with pgtable %#lx\n",
__func__, __pa(priv->pgtable));
-   list_del(>node);
-   INIT_LIST_HEAD(>node);
+   list_del_init(>node);
 
} else {
dev_dbg(dev, "%s: Detaching IOMMU with pgtable %#lx delayed",


--
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] ARM: S3C24XX: Add WIZnet W5300E01-ARM board support

[Taehun Kim]

- The gpio routines are changed to use the gpio_request() functions from
  comments of Vasily and Sylwester.
- The mistake of adding a character by my email client automatically is fixed.

Please review this patch and apply it if do not have any problems.

Signed-off-by: Taehun Kim 
---
 arch/arm/mach-s3c24xx/Kconfig |5 +
 arch/arm/mach-s3c24xx/Makefile|1 +
 arch/arm/mach-s3c24xx/mach-w5300e01.c |  193 +
 3 files changed, 199 insertions(+)
 create mode 100644 arch/arm/mach-s3c24xx/mach-w5300e01.c

diff --git a/arch/arm/mach-s3c24xx/Kconfig b/arch/arm/mach-s3c24xx/Kconfig
index d56b0f7..94b60ca 100644
--- a/arch/arm/mach-s3c24xx/Kconfig
+++ b/arch/arm/mach-s3c24xx/Kconfig
@@ -248,6 +248,11 @@ config MACH_VR1000
help
  Say Y here if you are using the Thorcom VR1000 board.
 
+config MACH_W5300E01
+   bool "WIZnet W5300E01-ARM Board"
+   help
+ Say Y here if you are using the Wiznet W5300E01-ARM board.
+
 endif  # CPU_S3C2410
 
 config S3C2412_PM_SLEEP
diff --git a/arch/arm/mach-s3c24xx/Makefile b/arch/arm/mach-s3c24xx/Makefile
index 0ab6ab1..fc1a89e 100644
--- a/arch/arm/mach-s3c24xx/Makefile
+++ b/arch/arm/mach-s3c24xx/Makefile
@@ -61,6 +61,7 @@ obj-$(CONFIG_MACH_QT2410) += mach-qt2410.o
 obj-$(CONFIG_ARCH_SMDK2410)+= mach-smdk2410.o
 obj-$(CONFIG_MACH_TCT_HAMMER)  += mach-tct_hammer.o
 obj-$(CONFIG_MACH_VR1000)  += mach-vr1000.o
+obj-$(CONFIG_MACH_W5300E01)+= mach-w5300e01.o
 
 obj-$(CONFIG_MACH_JIVE)+= mach-jive.o
 obj-$(CONFIG_MACH_SMDK2413)+= mach-smdk2413.o
diff --git a/arch/arm/mach-s3c24xx/mach-w5300e01.c 
b/arch/arm/mach-s3c24xx/mach-w5300e01.c
new file mode 100644
index 000..ab648e5
--- /dev/null
+++ b/arch/arm/mach-s3c24xx/mach-w5300e01.c
@@ -0,0 +1,193 @@
+/* linux/arch/arm/mach-s3c24xx/mach-w5300e01.c
+ *
+ * Copyright (c) 2012 Taehun Kim 
+ *
+ * For product information, visit http://www.wiznet.co.kr/
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * @History:
+ * derived from linux/arch/arm/mach-s3c24xx/mach-bast.c, written by
+ * Ben Dooks 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static struct map_desc w5300e01_iodesc[] __initdata = {
+   /* Character LCD register map. */
+   { 0xf800, __phys_to_pfn(S3C2410_CS3), SZ_1M, MT_DEVICE }
+};
+
+#define UCON S3C2410_UCON_DEFAULT
+#define ULCON (S3C2410_LCON_CS8 | S3C2410_LCON_PNONE | S3C2410_LCON_STOPB)
+#define UFCON (S3C2410_UFCON_RXTRIG8 | S3C2410_UFCON_FIFOMODE)
+
+static struct s3c2410_uartcfg w5300e01_uartcfgs[] __initdata = {
+   [0] = {
+   .hwport = 0,
+   .flags  = 0,
+   .ucon   = UCON,
+   .ulcon  = ULCON,
+   .ufcon  = UFCON,
+   },
+   [1] = {
+   .hwport = 1,
+   .flags  = 0,
+   .ucon   = UCON,
+   .ulcon  = ULCON,
+   .ufcon  = UFCON,
+   },
+   [2] = {
+   .hwport = 2,
+   .flags  = 0,
+   .ucon   = UCON,
+   .ulcon  = ULCON,
+   .ufcon  = UFCON,
+   }
+};
+
+static struct mtd_partition w5300e01_mtd_partitions[] = {
+   [0] = {
+   .name   = "Bootloader",
+   .size   = 0x2,
+   .offset = 0,
+   .mask_flags = MTD_WRITEABLE,
+   },
+   [1] = {
+   .name   = "Boot Param",
+   .size   = 0x2,
+   .offset = MTDPART_OFS_APPEND,
+   },
+   [2] = {
+   .name   = "Kernel",
+   .size   = 0x3C,
+   .offset = MTDPART_OFS_APPEND,
+   },
+   [3] = {
+   .name   = "Ramdisk",
+   .size   = 0x100,
+   .offset = MTDPART_OFS_APPEND,
+   },
+   [4] = {
+   .name   = "JFFS2 FileSystem",
+   .size   = MTDPART_SIZ_FULL,
+   .offset = MTDPART_OFS_APPEND,
+   },
+};
+
+static struct resource w5300_resources[] = {
+   [0] = {
+   .start  = S3C2410_CS2,
+   .end= S3C2410_CS2 + SZ_1M,
+   .flags  = IORESOURCE_MEM,
+   },
+   [1] = {
+   .start  = IRQ_EINT0,
+   .end= IRQ_EINT0,
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
+static struct platform_device w5300_device = {
+   .name   = "w5300",
+   

Re: A workaround for request_firmware() stuck in module_init

[Ming Lei]

On Thu, Sep 6, 2012 at 12:30 AM, Alan Cox  wrote:
>> Yes, deferring the load may fix the built in case, but which also
>> introduces much work on changes of current drivers. In fact,
>> there are few guys who complained the built in case.
>
> It fixes the modular case too.

Sorry, I don't see anyone explained clearly why request_firmware()
can't be called inside module_init() in module case, so maybe it is
a bit early to say it is a fix on 'bug', :-)

>
>> The current complaint is from that udev may timeout request inside probe()
>> when drivers are built as module. As pointed by Linus and Benjamin,
>> it is better to fix it in udev, and looks not good to introduce great changes
>> (such as Takashi's defer probe patch) in kernel to workaround the problem.
>
> It's not about a workaround but about doing it properly for the long term
> and doing it in one place. It's also not a "great change", its a small
> change.
>
>> Linus has said that he doesn't like to load firmware in probe(), but in some
>> situation the drivers have to load firmware in its probe():
>
> You don't want to load firmware in probe because of the locking problems
> - you can trigger a load of another device on the same bus - the defer
>   dodges that nicely

Yes, it is alike with the patches from Takashi and me.

Also it is a kind of async probe, all these drivers may convert to
async probe to fix the problem for built-in case, I guess. If it is doable,
it may be a easier approach.

>
>> In fact, it is better for drivers to load firmware just when user wants to 
>> use
>> the device, and some drivers have already changed to load firmware in
>> the open() callback.
>
> For those devices sure but they are if anything a minority as far as I
> can see.
>
>> So looks loading firmware always before probe in driver core is
>> against the above idea.
>
> I never said "always"

Sorry for misunderstanding your idea.

>
>> > firmware load off and only when the firmware had loaded would it call
>> > ->probe with dev->firmware pointing at a refcounted firmware struct.
>>
>> IMO, introduce refcount for the firmware doesn't make sense. The lifetime
>> of firmware is completely different with lifetime of driver or device:
>
> Exactly. Which is why the moment you have multiple devices you need
> refcounts. It's also why the propsoal included a
>
> dev_discard_firmware()
>
> so you an instance can drop its firmware reference if it doesn't need it
> post probe.

This kind of mechanism has been implemented already: request_firmware()
and release_firmware() will get and put a refcount.  And, the reference
count is associated with firmware name, and it should be so, IMO.

>
>> - firmware needn't be kept in memory in the device/driver's lifetime, and
>>   should be loaded just in need, and be released after downloading
>>   it into device.
>
> You broke suspend/resume for lots of devices.

The firmware cache mechanism will keep the firmware during suspend/resume
cycle to address the problem.

>
>>- sometimes devices may disappear, but it is better to keep the
>>  firmware in memory, for example, device may be disconnected
>>  during resume but will come back later.
>
> So the moment you have multiple instances of a device with their own
> lifetime and you have the need to pin it sometimes you need a refcount
>
>> As said above, ref/deref on probe/remove is not a good idea since
>> we needn't to keep the firmware in memory during the whole device/driver
>> lifetime.
>
> Often you do. And in the case you don't you still have to deal with
> multiple probes doing asynchronous loads of the same firmware so you want
> to do matching and refcounting. It's pretty much essential.

For drivers, I understand request_firmware()/request_firmware_nowait()
and release_firmware() are enough. If many devices share one firmware,
there is only one firmware kept in memory for their requests if one holds
the firmware, and there is a refcount for it already, :-)

So I don't see why it is difficult to use request/release_firmware() inside
drivers, :-)

> The other big value apart from making it harder for driver writers to
> screw up is that it takes some of the control and puts it in one place.
> That means you can change it later easily not in each driver.
>
> This is enabling for device drivers. With no intention of offending
> driver authors the reality is that we should have driver interfaces that
>
> - work the right way by default
> - allow driver authors to do things themselves if they need to instead
>   (ie opt out)
> - are hard to f**k up
>
> because we want it to just work.

Thanks,
--
Ming Lei
--
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] extcon: use IRQF_ONESHOT

[Fengguang Wu]

Generated by: scripts/coccinelle/misc/irqf_oneshot.cocci

Make sure threaded IRQs without a primary handler are always
requested with IRQF_ONESHOT.

Signed-off-by: Fengguang Wu 
---

Please take the patch only if it's a positive warning. Thanks!

 cocci-output-4211-882baf-extcon-max77693.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/extcon/extcon-max77693.c
+++ b/drivers/extcon/extcon-max77693.c
@@ -700,7 +700,7 @@ static int __devinit max77693_muic_probe
 
ret = request_threaded_irq(virq, NULL,
max77693_muic_irq_handler,
-   0, muic_irq->name, info);
+   IRQF_ONESHOT, muic_irq->name, info);
if (ret) {
dev_err(>dev,
"failed: irq request (IRQ: %d,"
--
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/

linux-next: build failure after merge of the spi-mb tree

[Stephen Rothwell]

Hi Mark, Daniel,

After merging the spi-mb tree, today's linux-next build (x86_64
allmodconfig) failed like this:

drivers/spi/spi-gpio.c: In function 'spi_gpio_setup':
drivers/spi/spi-gpio.c:255:8: warning: cast from pointer to integer of 
different size [-Wpointer-to-int-cast]
drivers/spi/spi-gpio.c: In function 'spi_probe_dt':
drivers/spi/spi-gpio.c:389:39: error: parameter name omitted
drivers/spi/spi-gpio.c: In function 'spi_gpio_probe':
drivers/spi/spi-gpio.c:404:2: error: implicit declaration of function 
'spi_gpio_probe_dt' [-Werror=implicit-function-declaration]

Caused by commit 38ab18caa0ad ("spi: spi-gpio: Add DT bindings").  Please
build test these sort of patches with and without CONFIG_OF.

I have used the spi-mb tree from next-20120905 for today.
-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au


pgppgL0onmWo8.pgp
Description: PGP signature

Re: Re: [PATCH -next] extcon: extcon-arizona depends on INPUT

[Greg KH]

On Thu, Sep 06, 2012 at 08:54:16AM +0530, anish singh wrote:
> On Thu, Sep 6, 2012 at 5:36 AM, Greg KH  wrote:
> > On Wed, Sep 05, 2012 at 11:47:31PM +, MyungJoo Ham wrote:
> >> > On Wed, Sep 05, 2012 at 11:28:03AM +0800, Mark Brown wrote:
> >> > > On Tue, Sep 04, 2012 at 04:51:00PM -0700, Randy Dunlap wrote:
> >> > >
> >> > > > This build error still happens in linux-next of 20120904.
> >> > >
> >> > > > Can we get the patch merged for linux-next?
> >> > >
> >> > > Greg's the one managing extcon in -next.
> >> >
> >> > Yeah, can someone forward this to me so I can apply it?  I can't seem to
> >> > find it anywhere...
> >> >
> >> > greg k-h
> >>
> >> I've been creating "extcon-for-next" tree at git.infradead.org
> >> I'll rebase the branch base on your driver-core-next
> >>
> >> http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/extcon-for-next
> Is it possible to apply all the patches found here?I can see that some
> couldn't make
> it to your driver tree.

If no one asks, they how can I know to apply them?

(hint, hint, hint...)

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

Re: [GIT] kbuild rc fixes for v3.6

[Linus Torvalds]

On Mon, Sep 3, 2012 at 12:18 PM, Michal Marek  wrote:
>
> The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee:
>
>   Linux 3.6-rc1 (2012-08-02 16:38:10 -0700)
>
> are available in the git repository at:
>   git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6.git 
> ..BRANCH.NOT.VERIFIED..

There's something wrong with that repo

 "fatal: Could not read from remote repository.

  Please make sure you have the correct access rights
  and the repository exists."

plus that BRANCH.NOT.VERIFIED thing looks bad too (and is probably related).

 Linus
--
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: [tip:sched/core] sched: Fix load avg vs cpu-hotplug

[Rakib Mullick]

On 9/6/12, Peter Zijlstra  wrote:
> On Wed, 2012-09-05 at 19:01 +0200, Peter Zijlstra wrote:
>> > Please do a delta.
>
> OK, so I suppose something like the below ought to do. Paul its slightly
> different than the one in your tree, given the changelog below, do you
> see anything wrong with it?
>
> Rakib, again, sorry for getting your name wrong, and this time for
> getting it merged :/
>
It's okay, no problem. I was just pointed out what was the mistakes. I
didn't take too much seriously. ( Actually, my friends often called me
in such names that are no way near of "Rakib" or "Rabik", those names
sounds worse than "Rabik" ;-). So, I had to cope with it :-).)

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

Re: Re: [PATCH -next] extcon: extcon-arizona depends on INPUT

[anish singh]

On Thu, Sep 6, 2012 at 5:36 AM, Greg KH  wrote:
> On Wed, Sep 05, 2012 at 11:47:31PM +, MyungJoo Ham wrote:
>> > On Wed, Sep 05, 2012 at 11:28:03AM +0800, Mark Brown wrote:
>> > > On Tue, Sep 04, 2012 at 04:51:00PM -0700, Randy Dunlap wrote:
>> > >
>> > > > This build error still happens in linux-next of 20120904.
>> > >
>> > > > Can we get the patch merged for linux-next?
>> > >
>> > > Greg's the one managing extcon in -next.
>> >
>> > Yeah, can someone forward this to me so I can apply it?  I can't seem to
>> > find it anywhere...
>> >
>> > greg k-h
>>
>> I've been creating "extcon-for-next" tree at git.infradead.org
>> I'll rebase the branch base on your driver-core-next
>>
>> http://git.infradead.org/users/kmpark/linux-samsung/shortlog/refs/heads/extcon-for-next
Is it possible to apply all the patches found here?I can see that some
couldn't make
it to your driver tree.
>
> Don't worry, I've already applied this patch now.
>
> thanks,
>
> greg k-h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
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/

linux-next: manual merge of the trivial tree with the powerpc tree

[Stephen Rothwell]

Hi Jiri,

Today's linux-next merge of the trivial tree got a conflict in
drivers/scsi/ipr.c between commit d3dbeef657fd ("powerpc: Rename 64-bit
PVR constants to PVR_foo") from the powerpc tree and commit 203fa3fe9c9d
("ipr: fix small coding style issues") from the trivial tree.

Just context changes.  I fixed it up (see below) and can carry the fix as
necessary (no action required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/scsi/ipr.c
index cff6503,1059c99..000
--- a/drivers/scsi/ipr.c
+++ b/drivers/scsi/ipr.c
@@@ -6398,8 -6330,8 +6398,8 @@@ static int ipr_invalid_adapter(struct i
int i;
  
if ((ioa_cfg->type == 0x5702) && (ioa_cfg->pdev->revision < 4)) {
-   for (i = 0; i < ARRAY_SIZE(ipr_blocked_processors); i++){
+   for (i = 0; i < ARRAY_SIZE(ipr_blocked_processors); i++) {
 -  if (__is_processor(ipr_blocked_processors[i]))
 +  if (pvr_version_is(ipr_blocked_processors[i]))
return 1;
}
}


pgpwxUbz6gpbc.pgp
Description: PGP signature

Re: [dm-devel] [PATCH v8 3/8] dm: Use bioset's front_pad for dm_rq_clone_bio_info

[Jun'ichi Nomura]

On 09/06/12 05:27, Kent Overstreet wrote:
> @@ -2718,7 +2705,8 @@ struct dm_md_mempools *dm_alloc_md_mempools(unsigned 
> type, unsigned integrity)
>   if (!pools->tio_pool)
>   goto free_io_pool_and_out;
>  
> - pools->bs = bioset_create(pool_size, 0);
> + pools->bs = bioset_create(pool_size,
> +   offsetof(struct dm_rq_clone_bio_info, clone));
>   if (!pools->bs)
>   goto free_tio_pool_and_out;

frontpad is not necessary if type is DM_TYPE_BIO_BASED.

Other pool creation in that function do something like:
pools->bs = (type == DM_TYPE_BIO_BASED) ?
bioset_create(pool_size, 0) :
bioset_create(pool_size, offsetof(struct 
dm_rq_clone_bio_info, clone));

-- 
Jun'ichi Nomura, NEC Corporation

--
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] OMAP GPIO - don't wake from suspend unless requested.

[NeilBrown]

On Mon, 3 Sep 2012 22:59:06 -0700 "Shilimkar, Santosh"
 wrote:

> On Sun, Aug 26, 2012 at 6:29 PM, Shilimkar, Santosh
>  wrote:
> > On Sun, Aug 26, 2012 at 3:53 PM, NeilBrown  wrote:
> >>
> >> On Sun, 26 Aug 2012 09:47:50 +0530 "Shilimkar, Santosh"
> >>  wrote:
> >>
> >> > + Jon,
> >> >
> >> > On Sat, Aug 25, 2012 at 5:14 PM, NeilBrown  wrote:
> >> > >
> >> > >
> >> > >
> >> > > Current kernel will wake from suspend on an event on any active
> >> > > GPIO even if enable_irq_wake() wasn't called.
> >> > >
> >> > > There are two reasons that the hardware wake-enable bit should be set:
> >> > >
> >> > > 1/ while non-suspended the CPU might go into a deep sleep (off_mode)
> >> > >   in which the wake-enable bit is needed for an interrupt to be
> >> > >   recognised.
> >> > > 2/ while suspended the GPIO interrupt should wake from suspend if and
> >> > >only if irq_wake as been enabled.
> >> > >
> >> > > The code currently doesn't keep these two reasons separate so they get
> >> > > confused and sometimes the wakeup flags is set incorrectly.
> >> > >
> >> > > This patch reverts:
> >> > >  commit 9c4ed9e6c01e7a8bd9079da8267e1f03cb4761fc
> >> > > gpio/omap: remove suspend/resume callbacks
> >> > > and
> >> > >  commit 0aa2727399c0b78225021413022c164cb99fbc5e
> >> > > gpio/omap: remove suspend_wakeup field from struct gpio_bank
> >> > >
> >> > > and makes some minor changes so that we have separate flags for "GPIO
> >> > > should wake from deep idle" and "GPIO should wake from suspend".
> >> > >
> >> > > With this patch, the GPIO from my touch screen doesn't wake my device
> >> > > any more, which is what I want.
> >> > >
> >> > > Cc: Kevin Hilman 
> >> > > Cc: Tony Lindgren 
> >> > > Cc: Santosh Shilimkar 
> >> > > Cc: Cousson, Benoit 
> >> > > Cc: Grant Likely 
> >> > > Cc: Tarun Kanti DebBarma 
> >> > > Cc: Felipe Balbi 
> >> > > Cc: Govindraj.R 
> >> > >
> >> > > Signed-off-by: NeilBrown 
> >> > >
> >> > The patch doesn't seems to be correct. At least the 2/ gets
> >> > fixed with a proper IRQCHIP flag. Can you try the patch at
> >> > end of the email and see if it helps ? Am attaching it in case
> >> > mailer damages it.
> >> >
> >> > Regards
> >> > Santosh
> >> >
> >> > >From b8a38fc75e046f6462610e26c47c620cad850c24 Mon Sep 17 00:00:00 2001
> >> > From: Santosh Shilimkar 
> >> > Date: Sun, 26 Aug 2012 09:39:51 +0530
> >> > Subject: [PATCH] gpio: omap: Set IRQCHIP_MASK_ON_SUSPEND to mask all
> >> >  non-wakeup gpio wakeups.
> >> >
> >> > Set the irq chip flag IRQCHIP_MASK_ON_SUSPEND to cause the irq pm code
> >> > to mask all non-wake gpios in suspend, which will ensure the wakeup
> >> > enable
> >> > bit is not set on non-wake gpios.
> >> >
> >> > Signed-off-by: Santosh Shilimkar 
> >> > ---
> >> >  drivers/gpio/gpio-omap.c |1 +
> >> >  1 file changed, 1 insertion(+)
> >> >
> >> > diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> >> > index e6efd77..50b4c18 100644
> >> > --- a/drivers/gpio/gpio-omap.c
> >> > +++ b/drivers/gpio/gpio-omap.c
> >> > @@ -779,6 +779,7 @@ static struct irq_chip gpio_irq_chip = {
> >> >   .irq_unmask = gpio_unmask_irq,
> >> >   .irq_set_type   = gpio_irq_type,
> >> >   .irq_set_wake   = gpio_wake_enable,
> >> > + .flags  = IRQCHIP_MASK_ON_SUSPEND;
> >> >  };
> >> >
> >> >
> >> > /*-*/
> >>
> >>
> >> No obvious damage, unless the mailer is responsible or the ';' at the end
> >> of
> >> the line, rather than ',' :-)
> >>
> > :-) That was typo.
> >
> >> The approach makes sense, but does actually work.  Should be fixable
> >> though.
> >>
> >> When I try this I get:
> >>
> >>
> >>
> >> [  158.114440] Checking wakeup interrupts
> >> [  158.118408] Unhandled fault: external abort on non-linefetch (0x1028)
> >> at 0xfb054040
> >> [  158.126403] Internal error: : 1028 [#1] PREEMPT ARM
> >> [  158.131500] Modules linked in: ipv6 g_ether hso libertas_sdio libertas
> >> cfg80211
> >> [  158.139190] CPU: 0Not tainted  (3.5.0-gta04-debug+ #2)
> >> [  158.144927] PC is at _set_gpio_triggering+0x38/0x258
> >> [  158.150115] LR is at gpio_mask_irq+0xac/0xc0
> >> [  158.154602] pc : []lr : []psr: 6193
> >> [  158.154602] sp : db521e90  ip : 0011  fp : beeecc2c
> >> [  158.166595] r10: c05c8ebc  r9 : daa5a858  r8 : 0003
> >> [  158.172027] r7 : a193  r6 :   r5 : fb054000  r4 : ded44e18
> >> [  158.178863] r3 : 0001  r2 :   r1 : ded30340  r0 : 0040
> >> [  158.185668] Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM
> >> Segment use
> >>
> >> so it looks like runtime PM has turned off the iclk to the GPIO module so
> >> that
> >> when we try to tell it to change settings, it is no longer listening to
> >> us.
> > From the crash logs it appears like that.
> >
> >> The "Checking wakeup interrupts" function happens very late in the suspend
> >> cycle, after all the suspend_late and suspend_noirq functions have run.
> >> 

Re: [PATCH] slab: fix the DEADLOCK issue on l3 alien lock

[Michael Wang]

On 09/05/2012 09:55 PM, Christoph Lameter wrote:
> On Wed, 5 Sep 2012, Michael Wang wrote:
> 
>> Since the cachep and cachep->slabp_cache's l3 alien are in the same lock 
>> class,
>> fake report generated.
> 
> Ahh... That is a key insight into why this occurs.
> 
>> This should not happen since we already have init_lock_keys() which will
>> reassign the lock class for both l3 list and l3 alien.
> 
> Right. I was wondering why we still get intermitted reports on this.
> 
>> This patch will invoke init_lock_keys() after we done enable_cpucache()
>> instead of before to avoid the fake DEADLOCK report.
> 
> Acked-by: Christoph Lameter 

Thanks for your review.

And add Paul to the cc list(my skills on mailing is really poor...).

Regards,
Michael Wang

> --
> 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: [PATCH] Add a page cache-backed balloon device driver.

[Rusty Russell]

Paolo Bonzini  writes:
> Il 02/07/2012 02:29, Rusty Russell ha scritto:
>> VIRTIO_BALLOON_F_MUST_TELL_HOST
>> implies you should tell the host (eventually).  I don't know if any
>> implementations actually care though.
>
> This is indeed broken, because it is a "negative" feature: it tells you
> that "implicit deflate" is _not_ supported.
>
> Right now, QEMU refuses migration if the target does not support all the
> features that were negotiated.  But then:
>
> - a migration from non-MUST_TELL_HOST to MUST_TELL_HOST will succeed,
> which is wrong;
>
> - a migration from MUST_TELL_HOST to non-MUST_TELL_HOST will fail, which
> is useless.
>
>> We could add a VIRTIO_BALLOON_F_NEVER_TELL_DEFLATE which would mean the
>> deflate vq need not be used at all.
>
> That would work.  At the same time we could deprecate MUST_TELL_HOST.
> Certainly the guest implementations don't care, or we would have
> experienced problems such as the one above.  The QEMU implementation
> also does not care but, for example, a Xen implementation would care.

OK; I'm not sure we need to deprecate MUST_TELL_HOST, though since it's
never actually been used there's a good argument.

VIRTIO_BALLOON_F_SILENT_DEFLATE (or whatever it's called) would
obviously mean you couldn't ack VIRTIO_BALLOON_F_MUST_TELL_HOST.

Patches welcome!

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

Re: [PATCH 1/2] module: allow loading module from fd

[Rusty Russell]

Kees Cook  writes:
> This changes the init_module syscall so that when the first argument
> (blob address) is NULL, the second argument is used as a file descriptor
> to the module (instead of length). The third argument (module arguments)
> remains unchanged.

Do you know why Linus hates ioctls?  It's because they encourage
casual introduction of new ABIs.

I see you managed the same feat with a different system call.  It avoids
the agony of debate a new system call would entail.  Very clever.

Now do it properly.
Rusty.
--
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] virtio-blk: Fix kconfig option

[Rusty Russell]

"Michael S. Tsirkin"  writes:
> On Tue, Sep 04, 2012 at 03:53:53PM +0930, Rusty Russell wrote:
>> Kent Overstreet  writes:
>> 
>> > CONFIG_VIRTIO isn't exposed, everything else is supposed to select it
>> > instead.
>> 
>> This is a slight mis-understanding.  It's supposed to be selected by
>> the particular driver, probably virtio_pci in your case.
>> 
>> Cheers,
>> Rusty.
>
> Actually balloon selects VIRTIO, I think it's a bug.
> Also isn't it time we dropped the experimental tag?
> Leaving it in for now.

Thanks, I applied this, and killed the EXPERIMENTAL in a separate patch.

Cheers,
Rusty.
--
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] virtio: support reserved vqs

[Rusty Russell]

"Michael S. Tsirkin"  writes:

> virtio network device multiqueue support reserves
> vq 3 for future use (useful both for future extensions and to make it
> pretty - this way receive vqs have even and transmit - odd numbers).
> Make it possible to skip initialization for
> specific vq numbers by specifying NULL for name.
> Document this usage as well as (existing) NULL callback.
>
> Drivers using this not coded up yet, so I simply tested
> with virtio-pci and verified that this patch does
> not break existing drivers.
>
> Signed-off-by: Michael S. Tsirkin 

This seems sane.  Applied.

Thanks,
Rusty.
--
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 2/2] virtio-ring: Allocate indirect buffers from cache when possible

[Rusty Russell]

Sasha Levin  writes:
>> On Wed, Aug 29, 2012 at 05:03:03PM +0200, Sasha Levin wrote:
>>> I've also re-ran it on a IBM server type host instead of my laptop. Here 
>>> are the
>>> results:
>>>
>>> Vanilla kernel:
>>>
>>> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 
>>> 192.168.33.1
>>> () port 0 AF_INET
>>> enable_enobufs failed: getprotobyname
>>> Recv   SendSend
>>> Socket Socket  Message  Elapsed
>>> Size   SizeSize Time Throughput
>>> bytes  bytes   bytessecs.10^6bits/sec
>>>
>>>  87380  16384  1638410.007922.72
>>>
>>> Patch 1, with threshold=16:
>>>
>>> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 
>>> 192.168.33.1
>>> () port 0 AF_INET
>>> enable_enobufs failed: getprotobyname
>>> Recv   SendSend
>>> Socket Socket  Message  Elapsed
>>> Size   SizeSize Time Throughput
>>> bytes  bytes   bytessecs.10^6bits/sec
>>>
>>>  87380  16384  1638410.008415.07
>>>
>>> Patch 2:
>>>
>>> MIGRATED TCP STREAM TEST from 0.0.0.0 (0.0.0.0) port 0 AF_INET to 
>>> 192.168.33.1
>>> () port 0 AF_INET
>>> enable_enobufs failed: getprotobyname
>>> Recv   SendSend
>>> Socket Socket  Message  Elapsed
>>> Size   SizeSize Time Throughput
>>> bytes  bytes   bytessecs.10^6bits/sec
>>>
>>>  87380  16384  1638410.008931.05
>>>
>>>
>>> Note that these are simple tests with netperf listening on one end and a 
>>> simple
>>> 'netperf -H [host]' within the guest. If there are other tests which may be
>>> interesting please let me know.

It might be worth just unconditionally having a cache for the 2
descriptor case.  This is what I get with qemu tap, though for some
reason the device features don't have guest or host CSUM, so my setup is
probably screwed:

Queue histogram for virtio0:
Size distribution for input (max=128427):
  1: 128427  
Size distribution for output (max=256485):
  2: 256485  
Size distribution for control (max=10):
  3: 10  
  4: 5   

Here's a patch, what do you get (run ifconfig to trigger the dump; yeah,
it's a hack!)

Hack: histogram of buffer sizes for virtio devices.

Currently triggered by a stats query (eg ifconfig) on a net device.

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -727,6 +727,8 @@ static struct rtnl_link_stats64 *virtnet
tot->rx_length_errors = dev->stats.rx_length_errors;
tot->rx_frame_errors = dev->stats.rx_frame_errors;
 
+   virtio_dev_dump_histogram(vi->vdev);
+
return tot;
 }
 
diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -108,6 +108,16 @@ void virtio_check_driver_offered_feature
 }
 EXPORT_SYMBOL_GPL(virtio_check_driver_offered_feature);
 
+void virtio_dev_dump_histogram(const struct virtio_device *vdev)
+{
+   const struct virtqueue *vq;
+
+   printk("Queue histogram for %s:\n", dev_name(>dev));
+   list_for_each_entry(vq, >vqs, list)
+   virtqueue_dump_histogram(vq);
+}
+EXPORT_SYMBOL_GPL(virtio_dev_dump_histogram);
+
 static int virtio_dev_probe(struct device *_d)
 {
int err, i;
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -120,6 +120,8 @@ struct vring_virtqueue
ktime_t last_add_time;
 #endif
 
+   unsigned int *histo;
+
/* Tokens for callbacks. */
void *data[];
 };
@@ -259,6 +261,8 @@ int virtqueue_add_buf(struct virtqueue *
BUG_ON(out + in > vq->vring.num);
BUG_ON(out + in == 0);
 
+   vq->histo[out+in]++;
+
/* If the host supports indirect descriptor tables, consider it. */
if (vq->indirect) {
bool try_indirect;
@@ -726,6 +730,7 @@ struct virtqueue *vring_new_virtqueue(un
}
vq->data[i] = NULL;
 
+   vq->histo = kzalloc(num * sizeof(vq->histo[0]), GFP_KERNEL);
return >vq;
 }
 EXPORT_SYMBOL_GPL(vring_new_virtqueue);
@@ -772,4 +777,33 @@ unsigned int virtqueue_get_vring_size(st
 }
 EXPORT_SYMBOL_GPL(virtqueue_get_vring_size);
 
+void virtqueue_dump_histogram(const struct virtqueue *_vq)
+{
+   const struct vring_virtqueue *vq = to_vvq(_vq);
+   int i, j, start = 0, end = 0, max = 1;
+   char line[120];
+
+   for (i = 0; i < vq->vring.num; i++) {
+   if (!vq->histo[i])
+   continue;
+
+   end = i;
+   if (!vq->histo[start])
+   start = i;
+
+   if (vq->histo[i] > max)
+   max = vq->histo[i];
+   }
+
+   printk("Size distribution for %s (max=%u):\n", _vq->name, max);

Re: [PATCH 1/5] virtio-ring: move queue_index to vring_virtqueue

[Rusty Russell]

Paolo Bonzini  writes:

> From: Jason Wang 
>
> Instead of storing the queue index in transport-specific virtio structs,
> this patch moves them to vring_virtqueue and introduces an helper to get
> the value.  This lets drivers simplify their management and tracing of
> virtqueues.
>
> Signed-off-by: Jason Wang 
> Signed-off-by: Paolo Bonzini 

Sorry for the delay, I was at Kernel Summit and am only now actually
reading (vs skimming) my backlog.

Putting it in vring_virtqueue rather than virtqueue seems weird, though.
But I've applied as-is, we can clean up that later if we want (probably
by merging the two structures, I'll have to think harder on that).

Acked-by: Rusty Russell 

Cheers,
Rusty.
--
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 2/2] virtio-ring: Allocate indirect buffers from cache when possible

[Rusty Russell]

Sasha Levin  writes:

> On 08/28/2012 03:20 PM, Michael S. Tsirkin wrote:
>> On Tue, Aug 28, 2012 at 03:04:03PM +0200, Sasha Levin wrote:
>>> Currently if VIRTIO_RING_F_INDIRECT_DESC is enabled we will
>>> use indirect descriptors and allocate them using a simple
>>> kmalloc().
>>>
>>> This patch adds a cache which will allow indirect buffers under
>>> a configurable size to be allocated from that cache instead.
>>>
>>> Signed-off-by: Sasha Levin 
>> 
>> I imagine this helps performance? Any numbers?
>
> I ran benchmarks on the original RFC, I've re-tested it now and got similar
> numbers to the original ones (virtio-net using vhost-net, thresh=16):
>
> Before:
>   Recv   SendSend
>   Socket Socket  Message  Elapsed
>   Size   SizeSize Time Throughput
>   bytes  bytes   bytessecs.10^6bits/sec
>
>87380  16384  1638410.004512.12
>
> After:
>   Recv   SendSend
>   Socket Socket  Message  Elapsed
>   Size   SizeSize Time Throughput
>   bytes  bytes   bytessecs.10^6bits/sec
>
>87380  16384  1638410.005399.18

I have an older patch which adjusts the threshold dynamically, can you
compare?  User-adjustable thresholds are statistically never adjusted :(

virtio: use indirect buffers based on demand (heuristic)

virtio_ring uses a ring buffer of descriptors: indirect support allows
a single descriptor to refer to a table of descriptors.  This saves
space in the ring, but requires a kmalloc/kfree.

Rather than try to figure out what the right threshold at which to use
indirect buffers, we drop the threshold dynamically when the ring is
under stress.

Note: to stress this, I reduced the ring size to 32 in lguest, and a
1G send reduced the threshold to 9.

Note2: I moved the BUG_ON()s above the indirect test, where they belong
(indirect falls thru on OOM, so the constraints still apply).

Signed-off-by: Rusty Russell 
---
 drivers/virtio/virtio_ring.c |   61 ---
 1 file changed, 52 insertions(+), 9 deletions(-)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -89,6 +89,8 @@ struct vring_virtqueue
 
/* Host supports indirect buffers */
bool indirect;
+   /* Threshold before we go indirect. */
+   unsigned int indirect_threshold;
 
/* Host publishes avail event idx */
bool event;
@@ -174,6 +176,34 @@ static int vring_add_indirect(struct vri
return head;
 }
 
+static void adjust_threshold(struct vring_virtqueue *vq,
+unsigned int out, unsigned int in)
+{
+   /* There are really two species of virtqueue, and it matters here.
+* If there are no output parts, it's a "normally full" receive queue,
+* otherwise it's a "normally empty" send queue. */
+   if (out) {
+   /* Leave threshold unless we're full. */
+   if (out + in < vq->num_free)
+   return;
+   } else {
+   /* Leave threshold unless we're empty. */
+   if (vq->num_free != vq->vring.num)
+   return;
+   }
+
+   /* Never drop threshold below 1 */
+   vq->indirect_threshold /= 2;
+   vq->indirect_threshold |= 1;
+
+#if 0
+   printk("%s %s: indirect threshold %u (%u+%u vs %u)\n",
+  dev_name(>vq.vdev->dev),
+  vq->vq.name, vq->indirect_threshold,
+  out, in, vq->num_free);
+#endif
+}
+
 int virtqueue_get_queue_index(struct virtqueue *_vq)
 {
struct vring_virtqueue *vq = to_vvq(_vq);
@@ -226,17 +256,32 @@ int virtqueue_add_buf(struct virtqueue *
}
 #endif
 
-   /* If the host supports indirect descriptor tables, and we have multiple
-* buffers, then go indirect. FIXME: tune this threshold */
-   if (vq->indirect && (out + in) > 1 && vq->num_free) {
-   head = vring_add_indirect(vq, sg, out, in, gfp);
-   if (likely(head >= 0))
-   goto add_head;
-   }
-
BUG_ON(out + in > vq->vring.num);
BUG_ON(out + in == 0);
 
+
+   /* If the host supports indirect descriptor tables, consider it. */
+   if (vq->indirect) {
+   bool try_indirect;
+
+   /* We tweak the threshold automatically. */
+   adjust_threshold(vq, out, in);
+
+   /* If we can't fit any at all, fall through. */
+   if (vq->num_free == 0)
+   try_indirect = false;
+   else if (out + in > vq->num_free)
+   try_indirect = true;
+   else
+   try_indirect = (out + in > vq->indirect_threshold);
+
+   if (try_indirect) {
+   head = vring_add_indirect(vq, sg, out, in);
+   if (head != vq->vring.num)
+   goto 

Re: [PATCH 2/5] virtio: introduce an API to set affinity for a virtqueue

[Rusty Russell]

Paolo Bonzini  writes:

> From: Jason Wang 
>
> Sometimes, virtio device need to configure irq affinity hint to maximize the
> performance. Instead of just exposing the irq of a virtqueue, this patch
> introduce an API to set the affinity for a virtqueue.
>
> The api is best-effort, the affinity hint may not be set as expected due to
> platform support, irq sharing or irq type. Currently, only pci method were
> implemented and we set the affinity according to:
>
> - if device uses INTX, we just ignore the request
> - if device has per vq vector, we force the affinity hint
> - if the virtqueues share MSI, make the affinity OR over all affinities
>   requested
>
> Signed-off-by: Jason Wang 
> Signed-off-by: Paolo Bonzini 

Applied, thanks.

Acked-by: Rusty Russell 

Cheers,
Rusty.
--
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] module: signature infrastructure

[Rusty Russell]

Mimi Zohar  writes:

> On Wed, 2012-09-05 at 09:59 +0930, Rusty Russell wrote:
>> "Kasatkin, Dmitry"  writes:
>> > Hi,
>> >
>> > Please read bellow...
>> >
>> > On Tue, Sep 4, 2012 at 8:55 AM, Rusty Russell  
>> > wrote:
>> >> OK, I took a look at the module.c parts of David and Dmitry's patchsets,
>> >> and didn't really like either, but I stole parts of David's to make
>> >> this.
>> >>
>> >> So, here's the module.c part of module signing.  I hope you two got time
>> >> to discuss the signature format details?  Mimi suggested a scheme where
>> >> the private key would never be saved on disk (even temporarily), but I
>> >> didn't see patches.  Frankly it's something we can do later; let's aim
>> >> at getting the format right for the next merge window.
>> >
>> > In our patches key is stored on the disc in encrypted format...
>> 
>> Oh, I missed that twist.  Thanks for the explanation.
>> 
>> On consideration, I prefer signing to be the final part of the "modules"
>> target rather than modules_install.  I run the latter as root, and that
>> is wrong for doing any code generation.
>
> Agreed, but keep in mind that 'modules_install' could subsequently strip
> the module.

That had better be part of your signing step then!

Cheers,
Rusty.
--
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 1/2] virtio_console: Add support for DMA memory allocation

[Rusty Russell]

"Michael S. Tsirkin"  writes:
> On Tue, Sep 04, 2012 at 06:58:47PM +0200, Sjur Brændeland wrote:
>> Hi Michael,
>> 
>> > Exactly. Though if we just fail load it will be much less code.
>> >
>> > Generally, using a feature bit for this is a bit of a problem though:
>> > normally driver is expected to be able to simply ignore
>> > a feature bit. In this case driver is required to
>> > do something so a feature bit is not a good fit.
>> > I am not sure what the right thing to do is.
>> 
>> I see - so in order to avoid the binding between driver and device
>> there are two options I guess. Either make virtio_dev_match() or
>> virtcons_probe() fail. Neither of them seems like the obvious choice.
>> 
>> Maybe adding a check for VIRTIO_CONSOLE_F_DMA_MEM match
>> between device and driver in virtcons_probe() is the lesser evil?
>> 
>> Regards,
>> Sjur
>
> A simplest thing to do is change dev id. rusty?

For generic usage, this is correct.  But my opinion is that fallback on
feature non-ack is quality-of-implementation issue: great to have, but
there are cases where you just want to fail with "you're too old".

And in this case, an old system simply will never work.  So it's a
question of how graceful the failure is.

Can your userspace loader can refuse to proceed if the driver doesn't
ack the bits?  If so, it's simpler than a whole new ID.

Cheers,
Rusty.
--
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] memory-hotplug: bug fix race between isolation and allocation

[Minchan Kim]

Hello Xishi,

On Thu, Sep 06, 2012 at 10:35:39AM +0800, qiuxishi wrote:
> On 2012/9/5 17:40, Mel Gorman wrote:
> 
> > On Wed, Sep 05, 2012 at 04:26:02PM +0900, Minchan Kim wrote:
> >> Like below, memory-hotplug makes race between page-isolation
> >> and page-allocation so it can hit BUG_ON in __offline_isolated_pages.
> >>
> >>CPU A   CPU B
> >>
> >> start_isolate_page_range
> >> set_migratetype_isolate
> >> spin_lock_irqsave(zone->lock)
> >>
> >>free_hot_cold_page(Page A)
> >>/* without zone->lock */
> >>migratetype = get_pageblock_migratetype(Page A);
> >>/*
> >> * Page could be moved into MIGRATE_MOVABLE
> >> * of per_cpu_pages
> >> */
> >>list_add_tail(>lru, 
> >> >lists[migratetype]);
> >>
> >> set_pageblock_isolate
> >> move_freepages_block
> >> drain_all_pages
> 
> I think here is the problem you want to fix, it is not sure that pcp will be 
> moved
> into MIGRATE_ISOLATE list. They may be moved into MIGRATE_MOVABLE list because
> page_private() maybe 2, it uses page_private() not get_pageblock_migratetype()
> 
> So when finish migrating pages, the free pages from pcp may be allocated 
> again, and
> failed in check_pages_isolated().
> 
> drain_all_pages()
>   drain_local_pages()
>   drain_pages()
>   free_pcppages_bulk()
>   __free_one_page(page, zone, 0, 
> page_private(page))
> 
> I reported this problem too. 
> http://marc.info/?l=linux-mm=134555113706068=2
> How about this change:
>   free_pcppages_bulk()
>   __free_one_page(page, zone, 0, get_pageblock_migratetype(page))

I already explained why it was not good solution.
Again, here it goes from my previous reply.

"
Anyway, I don't like your approach which I already considered because it hurts 
hotpath
while the race is really unlikely. Get_pageblock_migratetype is never trivial.
We should avoid the overhead in hotpath and move into memory-hotplug itself.
Do you see my patch in https://patchwork.kernel.org/patch/1225081/ ?
"

-- 
Kind regards,
Minchan Kim
--
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/

[RFC v2] memory-hotplug: remove MIGRATE_ISOLATE from free_area->free_list

[Minchan Kim]

Normally, MIGRATE_ISOLATE type is used for memory-hotplug.
But it's irony type because the pages isolated would exist
as free page in free_area->free_list[MIGRATE_ISOLATE] so people
can think of it as allocatable pages but it is *never* allocatable.
It ends up confusing NR_FREE_PAGES vmstat so it would be
totally not accurate so some of place which depend on such vmstat
could reach wrong decision by the context.

There were already report about it.[1]
[1] 702d1a6e, memory-hotplug: fix kswapd looping forever problem

Then, there was other report which is other problem.[2]
[2] http://www.spinics.net/lists/linux-mm/msg41251.html

I believe it can make problems in future, too.
So I hope removing such irony type by another design.

I hope this patch solves it and let's revert [1] and doesn't need [2].

* Changelog v1
 * Fix from Michal's many suggestion

Cc: Michal Nazarewicz 
Cc: Mel Gorman 
Cc: Kamezawa Hiroyuki 
Cc: Yasuaki Ishimatsu 
Cc: Wen Congyang 
Cc: Konrad Rzeszutek Wilk 
Signed-off-by: Minchan Kim 
---
It's very early version which show the concept so I still marked it with RFC.
I just tested it with simple test and works.
This patch is needed indepth review from memory-hotplug guys from fujitsu
because I saw there are lots of patches recenlty they sent to about
memory-hotplug change. Please take a look at this patch.

 drivers/xen/balloon.c  |2 +
 include/linux/mmzone.h |4 +-
 include/linux/page-isolation.h |   11 ++-
 mm/internal.h  |3 +
 mm/memory_hotplug.c|   38 ++
 mm/page_alloc.c|   33 
 mm/page_isolation.c|  162 +---
 mm/vmstat.c|1 -
 8 files changed, 193 insertions(+), 61 deletions(-)

diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
index 31ab82f..df0f5f3 100644
--- a/drivers/xen/balloon.c
+++ b/drivers/xen/balloon.c
@@ -50,6 +50,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -268,6 +269,7 @@ static void xen_online_page(struct page *page)
else
--balloon_stats.balloon_hotplug;
 
+   delete_from_isolated_list(page);
mutex_unlock(_mutex);
 }
 
diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 2daa54f..438bab8 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -57,8 +57,8 @@ enum {
 */
MIGRATE_CMA,
 #endif
-   MIGRATE_ISOLATE,/* can't allocate from here */
-   MIGRATE_TYPES
+   MIGRATE_TYPES,
+   MIGRATE_ISOLATE
 };
 
 #ifdef CONFIG_CMA
diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
index 105077a..1ae2cd6 100644
--- a/include/linux/page-isolation.h
+++ b/include/linux/page-isolation.h
@@ -1,11 +1,16 @@
 #ifndef __LINUX_PAGEISOLATION_H
 #define __LINUX_PAGEISOLATION_H
 
+extern struct list_head isolated_pages;
 
 bool has_unmovable_pages(struct zone *zone, struct page *page, int count);
 void set_pageblock_migratetype(struct page *page, int migratetype);
 int move_freepages_block(struct zone *zone, struct page *page,
int migratetype);
+
+void isolate_free_page(struct page *page, unsigned int order);
+void delete_from_isolated_list(struct page *page);
+
 /*
  * Changes migrate type in [start_pfn, end_pfn) to be MIGRATE_ISOLATE.
  * If specified range includes migrate types other than MOVABLE or CMA,
@@ -20,9 +25,13 @@ start_isolate_page_range(unsigned long start_pfn, unsigned 
long end_pfn,
 unsigned migratetype);
 
 /*
- * Changes MIGRATE_ISOLATE to MIGRATE_MOVABLE.
+ * Changes MIGRATE_ISOLATE to @migratetype.
  * target range is [start_pfn, end_pfn)
  */
+void
+undo_isolate_pageblocks(unsigned long start_pfn, unsigned long end_pfn,
+   unsigned migratetype);
+
 int
 undo_isolate_page_range(unsigned long start_pfn, unsigned long end_pfn,
unsigned migratetype);
diff --git a/mm/internal.h b/mm/internal.h
index 3314f79..393197e 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -144,6 +144,9 @@ isolate_migratepages_range(struct zone *zone, struct 
compact_control *cc,
  * function for dealing with page's order in buddy system.
  * zone->lock is already acquired when we use these.
  * So, we don't need atomic page->flags operations here.
+ *
+ * Page order should be put on page->private because
+ * memory-hotplug depends on it. Look mm/page_isolation.c.
  */
 static inline unsigned long page_order(struct page *page)
 {
diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 3ad25f9..30c36d5 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -410,26 +410,29 @@ void __online_page_set_limits(struct page *page)
unsigned long pfn = page_to_pfn(page);
 
if (pfn >= num_physpages)
-   num_physpages = pfn + 1;
+   num_physpages = pfn + (1 << page_order(page));
 }
 EXPORT_SYMBOL_GPL(__online_page_set_limits);
 
 void 

Re: A workaround for request_firmware() stuck in module_init

[Linus Torvalds]

On Wed, Sep 5, 2012 at 9:30 AM, Alan Cox  wrote:
>
> It's not about a workaround but about doing it properly for the long term
> and doing it in one place. It's also not a "great change", its a small
> change.

udev needs to get fixed regardless.

Stop this "we can break stuff" crap. Who maintains udev? Regressions
are not acceptable. I'm not going to change the kernel because udev
broke, f*ck it.

Seriously. More projects need to realize that regressions are totally
and utterly unacceptable.

The "long term cleaner issues" can be handled separately, but are
*not* an excuse to work around clear regressions in core packages.
That just encourages those package maintainers to be shit maintainers.

Just fix udev, which had a regression. And stop blaming the kernel for
user space breakage! Tying these kinds of things together ("udev
broke, so now we need to change the kernel") is *wrong*. It's totally
unacceptable to tie the two together that way.

  Linus
--
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 v2] trace: Move trace event enable from fs_initcall to early_initcall

[Steven Rostedt]

On Wed, 2012-09-05 at 13:53 -0400, Steven Rostedt wrote:
> On Tue, 2012-09-04 at 22:18 -0300, Ezequiel Garcia wrote:
> > Hi Steven,
> > 
> > On 8/17/12, Steven Rostedt  wrote:
> > > On Fri, 2012-08-17 at 09:03 -0300, Ezequiel Garcia wrote:
> > >> This patch splits trace event initialization in two stages:
> > >>  * ftrace enable
> > >>  * sysfs event entry creation
> > >>
> > >> This allows to capture trace events from an earlier point
> > >> by using 'trace_event' kernel parameter and is important
> > >> to trace boot-up allocations.
> > >>
> > >
> > > This is much better, I'll give it some tests and add it to my 3.7 queue.
> > >
> > 
> > Ping? Will you add this to your tree?
> 
> Yeah, I haven't been able to test it yet. I've been stuck trying to
> figure out bugs on other patches I have queued. I'll let you know when I
> do apply it though.

Just tested it and it failed :-/

Enable CONFIG_FTRACE_SELFTEST and CONFIG_FTRACE_STARTUP_TEST, along with
events and syscall events. The syscall event self test fails with this
patch applied.

-- Steve


--
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] memory-hotplug: bug fix race between isolation and allocation

[qiuxishi]

On 2012/9/5 17:40, Mel Gorman wrote:

> On Wed, Sep 05, 2012 at 04:26:02PM +0900, Minchan Kim wrote:
>> Like below, memory-hotplug makes race between page-isolation
>> and page-allocation so it can hit BUG_ON in __offline_isolated_pages.
>>
>>  CPU A   CPU B
>>
>> start_isolate_page_range
>> set_migratetype_isolate
>> spin_lock_irqsave(zone->lock)
>>
>>  free_hot_cold_page(Page A)
>>  /* without zone->lock */
>>  migratetype = get_pageblock_migratetype(Page A);
>>  /*
>>   * Page could be moved into MIGRATE_MOVABLE
>>   * of per_cpu_pages
>>   */
>>  list_add_tail(>lru, 
>> >lists[migratetype]);
>>
>> set_pageblock_isolate
>> move_freepages_block
>> drain_all_pages

I think here is the problem you want to fix, it is not sure that pcp will be 
moved
into MIGRATE_ISOLATE list. They may be moved into MIGRATE_MOVABLE list because
page_private() maybe 2, it uses page_private() not get_pageblock_migratetype()

So when finish migrating pages, the free pages from pcp may be allocated again, 
and
failed in check_pages_isolated().

drain_all_pages()
drain_local_pages()
drain_pages()
free_pcppages_bulk()
__free_one_page(page, zone, 0, 
page_private(page))

I reported this problem too. http://marc.info/?l=linux-mm=134555113706068=2
How about this change:
free_pcppages_bulk()
__free_one_page(page, zone, 0, get_pageblock_migratetype(page))

Thanks
Xishi Qiu

>>
>>  /* Page A could be in MIGRATE_MOVABLE of 
>> free_list. */
>>
>> check_pages_isolated
>> __test_page_isolated_in_pageblock
>> /*
>>  * We can't catch freed page which
>>  * is free_list[MIGRATE_MOVABLE]
>>  */
>> if (PageBuddy(page A))
>>  pfn += 1 << page_order(page A);
>>
>>  /* So, Page A could be allocated */
>>
>> __offline_isolated_pages
>> /*
>>  * BUG_ON hit or offline page
>>  * which is used by someone
>>  */
>> BUG_ON(!PageBuddy(page A));
>>
>
> offline_page calling BUG_ON because someone allocated the page is
> ridiculous. I did not spot where that check is but it should be changed. The
> correct action is to retry the isolation.
>
>> Signed-off-by: Minchan Kim 
>
> At no point in the changelog do you actually say what he patch does :/
>
>> ---
>>  mm/page_isolation.c |5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/mm/page_isolation.c b/mm/page_isolation.c
>> index acf65a7..4699d1f 100644
>> --- a/mm/page_isolation.c
>> +++ b/mm/page_isolation.c
>> @@ -196,8 +196,11 @@ __test_page_isolated_in_pageblock(unsigned long pfn, 
>> unsigned long end_pfn)
>>  continue;
>>  }
>>  page = pfn_to_page(pfn);
>> -if (PageBuddy(page))
>> +if (PageBuddy(page)) {
>> +if (get_page_migratetype(page) != MIGRATE_ISOLATE)
>> +break;
>>  pfn += 1 << page_order(page);
>> +}
>
> It is possible the page is moved to the MIGRATE_ISOLATE list between when
> the page was freed to the buddy allocator and this check was made. The
> page->index information is stale and the impact is that the hotplug
> operation fails when it could have succeeded. That said, I think it is a
> very unlikely race that will never happen in practice.
>
> More importantly, the effect of this path is that EBUSY gets bubbled all
> the way up and the hotplug operations fails. This is fine but as the page
> is free at the time this problem is detected you also have the option
> of moving the PageBuddy page to the MIGRATE_ISOLATE list at this time
> if you take the zone lock. This will mean you need to change the name of
> test_pages_isolated() of course.
>
>>  else if (page_count(page) == 0 &&
>>  get_page_migratetype(page) == MIGRATE_ISOLATE)
>>  pfn += 1;
>> --
>> 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] drm/exynos: fix double call of drm_prime_(init/destroy)_file_private

[InKi Dae]

Hi,

2012/9/6 Mandeep Singh Baines :
> The double invocations are incorrect but seem to be safe so I don't
> think this will fix any bugs.
>
> Before:
>
> [7.639366] drm_prime_init_file ee3675d0
> [7.639377] drm_prime_init_file ee3675d0
> [7.639507] drm_prime_destroy_file ee3675d0
> [7.639518] drm_prime_destroy_file ee3675d0
> [7.639802] drm_prime_init_file ee372390
> [7.639810] drm_prime_init_file ee372390
> [8.473316] drm_prime_init_file ee356390
> [8.473331] drm_prime_init_file ee356390
>
> After:
>
> [6.363842] drm_prime_init_file edc2e5d0
> [6.363994] drm_prime_destroy_file edc2e5d0
> [6.364260] drm_prime_init_file edc2e750
> [8.004837] drm_prime_init_file ee36ded0
>
> Signed-off-by: Mandeep Singh Baines 
> CC: Stéphane Marchesin 
> CC: Pawel Osciak 
> CC: Inki Dae 
> CC: Joonyoung Shim 
> CC: Seung-Woo Kim 
> CC: Kyungmin Park 
> CC: David Airlie 
> CC: dri-de...@lists.freedesktop.org

remove all CCs and can you send it again using text mode? your patch
is messed up when I try to get patch file.

Thanks.
Inki Dae

> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index ebacec6..a27b8ff 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -160,7 +160,6 @@ static int exynos_drm_open(struct drm_device *dev, struct 
> drm_file *file)
> if (!file_priv)
> return -ENOMEM;
>
> -   drm_prime_init_file_private(>prime);
> file->driver_priv = file_priv;
>
> return exynos_drm_subdrv_open(dev, file);
> @@ -184,7 +183,6 @@ static void exynos_drm_preclose(struct drm_device *dev,
> e->base.destroy(>base);
> }
> }
> -   drm_prime_destroy_file_private(>prime);
> spin_unlock_irqrestore(>event_lock, flags);
>
> exynos_drm_subdrv_close(dev, file);
> --
> 1.7.7.3
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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/3] tcm_iscsi: support multiple sizes in the scatterlist

[Nicholas A. Bellinger]

On Wed, 2012-09-05 at 17:13 +0200, Paolo Bonzini wrote:
> The next patch will use multiple orders to satisfy the allocation
> of the data buffers.
> 
> We need to support this in iscsi_map_iovec and iscsi_unmap_iovec.
> The idea here is to walk each relevant page in the scatterlist
> (which may not be every page in the scatterlist due to data_offset)
> and kmap it.  iscsi_unmap_iovec uses the same algorithm, so that
> each kunmap maps the kmap that was used in iscsi_map_iovec.
> 

CC'ing Agrover here as he last touched the iscsit_[map,unmap]_iovec()
before the mainline merge of this code..

Also, this type of change is going to require other Reviewed-By's and
serious fio+writeverify Tested-By's to make sure we get all of the
corner cases as this enabled for upstream iscsi-target.

I'll be having a deeper look sometime next week, but as long as we can
selectively disable this for fabrics I don't have a problem considering
it for-3.7 code.

Nice work Paolo!

> Signed-off-by: Paolo Bonzini 
> ---
>  drivers/target/iscsi/iscsi_target.c  |  106 -
>  drivers/target/iscsi/iscsi_target_core.h |2 +-
>  2 files changed, 89 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/target/iscsi/iscsi_target.c 
> b/drivers/target/iscsi/iscsi_target.c
> index 224679e..dc4f5da 100644
> --- a/drivers/target/iscsi/iscsi_target.c
> +++ b/drivers/target/iscsi/iscsi_target.c
> @@ -684,45 +684,115 @@ static int iscsit_map_iovec(
>   u32 data_offset,
>   u32 data_length)
>  {
> - u32 i = 0;
>   struct scatterlist *sg;
> - unsigned int page_off;
> + u32 sg_off, sg_left, cur_len;
> + u32 sg_pfn = 0;
> + u32 i = 0;
>  
> - /*
> -  * We know each entry in t_data_sg contains a page.
> -  */
> - sg = >se_cmd.t_data_sg[data_offset / PAGE_SIZE];
> - page_off = (data_offset % PAGE_SIZE);
> + sg = cmd->se_cmd.t_data_sg;
> + while (data_offset >= sg->length) {
> + data_offset -= sg->length;
> + sg++;
> + }
>  
>   cmd->first_data_sg = sg;
> - cmd->first_data_sg_off = page_off;
> + cmd->first_data_sg_off = sg->offset + data_offset;
> + cmd->kmapped_length = data_length;
>  
> + sg_left = 0;
>   while (data_length) {
> - u32 cur_len = min_t(u32, data_length, sg->length - page_off);
> + if (!sg_left) {
> + sg_off = sg->offset + data_offset;
> + sg_pfn = page_to_pfn(sg_page(sg));
> + sg_pfn += sg_off >> PAGE_SHIFT;
> + sg_off &= PAGE_SIZE - 1;
> +
> + sg_left = min(sg->length, data_length);
> +
> + /*
> +  * The next scatterlist is mapped from the beginning.
> +  */
> + sg++;
> + data_offset = 0;
> + }
>  
> - iov[i].iov_base = kmap(sg_page(sg)) + sg->offset + page_off;
> + /*
> +  * Create an iovec for (a part of) this page.
> +  */
> + cur_len = min_t(u32, PAGE_SIZE - sg_off, sg_left);
> + BUG_ON(!cur_len);
> +
> + iov[i].iov_base = kmap(pfn_to_page(sg_pfn)) + sg_off;
>   iov[i].iov_len = cur_len;
> + i++;
>  
>   data_length -= cur_len;
> - page_off = 0;
> - sg = sg_next(sg);
> - i++;
> - }
> + sg_left -= cur_len;
>  
> - cmd->kmapped_nents = i;
> + /*
> +  * The next pfn is mapped from the beginning.
> +  */
> + sg_pfn++;
> + sg_off = 0;
> + }
>  
> + BUG_ON(sg_left);
>   return i;
>  }
>  
>  static void iscsit_unmap_iovec(struct iscsi_cmd *cmd)
>  {
> - u32 i;
>   struct scatterlist *sg;
> + u32 data_offset, data_length;
> + u32 sg_off, sg_left, cur_len;
> + u32 sg_pfn = 0;
> +
> + if (!cmd->kmapped_length)
> + return;
>  
>   sg = cmd->first_data_sg;
> + data_offset = cmd->first_data_sg_off - sg->offset;
> + data_length = cmd->kmapped_length;
> +
> + /*
> +  * This loop must mirror exactly what is done in iscsi_map_iovec.
> +  */
> + sg_left = 0;
> + while (data_length) {
> + if (!sg_left) {
> + sg_off = sg->offset + data_offset;
> + sg_pfn = page_to_pfn(sg_page(sg));
> + sg_pfn += sg_off >> PAGE_SHIFT;
> + sg_off &= PAGE_SIZE - 1;
> +
> + sg_left = min(sg->length, data_length);
> +
> + /*
> +  * The next scatterlist is mapped from the beginning.
> +  */
> + sg++;
> + data_offset = 0;
> + }
> +
> + /*
> +  * Create an iovec for (a part of) this page.
> +  */
> + cur_len = min_t(u32, 

[PATCH] serial_core: fix sizeof(pointer)

[Fengguang Wu]

sizeof when applied to a pointer typed expression gives the
size of the pointer.

Generated by: scripts/coccinelle/misc/noderef.cocci

Signed-off-by: Fengguang Wu 
---

 cocci-output-38612-39d907-serial_core.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -640,7 +640,7 @@ static void uart_get_info(struct tty_por
 {
struct uart_port *uport = state->uart_port;
 
-   memset(retinfo, 0, sizeof(retinfo));
+   memset(retinfo, 0, sizeof(*retinfo));
 
retinfo->type   = uport->type;
retinfo->line   = uport->line;
--
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/3] mm: remain migratetype in freed page

[Minchan Kim]

On Wed, Sep 05, 2012 at 10:25:34AM +0100, Mel Gorman wrote:
> On Wed, Sep 05, 2012 at 04:26:01PM +0900, Minchan Kim wrote:
> > Page allocator doesn't keep migratetype information to page
> > when the page is freed. This patch remains the information
> > to freed page's index field which isn't used by free/alloc
> > preparing so it shouldn't change any behavir except below one.
> > 
> 
> This explanation could have been a *LOT* more helpful.
> 
> The page allocator caches the pageblock information in page->private while
> it is in the PCP freelists but this is overwritten with the order of the
> page when freed to the buddy allocator. This patch stores the migratetype
> of the page in the page->index field so that it is available at all times.

I will add your comment in my description.

> 
> > This patch adds a new call site in __free_pages_ok so it might be
> > overhead a bit but it's for high order allocation.
> > So I believe damage isn't hurt.
> > 
> 
> The additional call to set_page_migratetype() is not heavy. If you were
> adding a new call to get_pageblock_migratetype() or something equally
> expensive I would be more concerned.

I'm lucky to avoid your keen eye. ;)

> 
> > Signed-off-by: Minchan Kim 
> 
> The information you store in the page->index becomes stale if the page
> gets moved to another free list by move_freepages(). Not sure if that is
> a problem for you or not but it is possible that
> get_page_migratetype(page) != get_pageblock_migratetype(page)

Thanks for the spot. I have to fix it.

> 
> > ---
> >  include/linux/mm.h |6 --
> >  mm/page_alloc.c|7 ---
> >  2 files changed, 8 insertions(+), 5 deletions(-)
> > 
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index 86d61d6..8fd32da 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -251,12 +251,14 @@ struct inode;
> >  
> >  static inline void set_page_migratetype(struct page *page, int migratetype)
> >  {
> > -   set_page_private(page, migratetype);
> > +   VM_BUG_ON((unsigned int)migratetype >= MIGRATE_TYPES);
> 
> This additional bug check is not mentioned in the changelog. Not clear
> if it's necessary.

I'm not strong so if anyone think it's not necessary, I will drop.

> 
> > +   page->index = migratetype;
> >  }
> >  
> >  static inline int get_page_migratetype(struct page *page)
> >  {
> > -   return page_private(page);
> > +   VM_BUG_ON((unsigned int)page->index >= MIGRATE_TYPES);
> > +   return page->index;
> >  }
> >  
> >  /*
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 103ba66..32985dd 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -723,6 +723,7 @@ static void __free_pages_ok(struct page *page, unsigned 
> > int order)
> >  {
> > unsigned long flags;
> > int wasMlocked = __TestClearPageMlocked(page);
> > +   int migratetype;
> >  
> > if (!free_pages_prepare(page, order))
> > return;
> > @@ -731,9 +732,9 @@ static void __free_pages_ok(struct page *page, unsigned 
> > int order)
> > if (unlikely(wasMlocked))
> > free_page_mlock(page);
> > __count_vm_events(PGFREE, 1 << order);
> > -   free_one_page(page_zone(page), page, order,
> > -   get_pageblock_migratetype(page));
> > -
> > +   migratetype = get_pageblock_migratetype(page);
> > +   set_page_migratetype(page, migratetype);
> > +   free_one_page(page_zone(page), page, order, migratetype);
> > local_irq_restore(flags);
> >  }
> >  
> 
> -- 
> Mel Gorman
> SUSE Labs
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
Kind regards,
Minchan Kim
--
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 3/3] target: try satisfying memory requests with contiguous blocks

[Nicholas A. Bellinger]

On Wed, 2012-09-05 at 17:13 +0200, Paolo Bonzini wrote:
> transport_generic_get_mem's strategy of allocating pages one-by-one
> for the data scatterlist may fail for even not-so-big data transfers
> if the underlying device poses a small limit on the number of segments.
> 
> This patch fixes this problem by trying to allocate pages in relatively
> large groups (at most 512 pages right now, equivalent to 2 MB per
> allocation), but still without any slack.  The remainder is then
> satisfied with subsequent smaller allocations.  For example, if the
> data to be transferred is 132 KB, the new algorithm will attempt
> a single 128 KB allocation, followed by a 4 KB allocation.
> In case a contiguous block cannot be found, it will fall back to
> a progressively smaller order.
> 
> Signed-off-by: Paolo Bonzini 
> ---
>  drivers/target/target_core_transport.c |   58 
> +++-
>  1 files changed, 49 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/target/target_core_transport.c 
> b/drivers/target/target_core_transport.c
> index 09028af..6e90e2c 100644
> --- a/drivers/target/target_core_transport.c
> +++ b/drivers/target/target_core_transport.c
> @@ -2058,7 +2058,7 @@ static inline void transport_free_sgl(struct 
> scatterlist *sgl, int nents)
>   int count;
>  
>   for_each_sg(sgl, sg, nents, count)
> - __free_page(sg_page(sg));
> + __free_pages(sg_page(sg), get_order(sg->length));
>  
>   kfree(sgl);
>  }
> @@ -2229,41 +2229,81 @@ void transport_kunmap_data_sg(struct se_cmd *cmd)
>  }
>  EXPORT_SYMBOL(transport_kunmap_data_sg);
>  
> +#define TRANSPORT_MAX_ORDER  9
> +
> +static inline int
> +get_order_no_slack(u32 length)
> +{
> + /*
> +  * get_order gives the smallest order that length fits in.
> +  * We want instead the largest order that does not give
> +  * any slack.
> +  *
> +  * Example (with PAGE_SIZE = 4096, PAGE_SHIFT = 12):
> +  *  get_order_no_slack(0x1000) = fls(0) = 0, get_order(0x1000) = 0
> +  *  get_order_no_slack(0x1001) = fls(0) = 0, get_order(0x1001) = 1
> +  *  get_order_no_slack(0x1fff) = fls(0) = 0, get_order(0x1fff) = 1
> +  *  get_order_no_slack(0x2000) = fls(1) = 1, get_order(0x2000) = 1
> +  *  get_order_no_slack(0x3000) = fls(1) = 1, get_order(0x3000) = 2
> +  *  get_order_no_slack(0x4000) = fls(2) = 2, get_order(0x4000) = 2
> +  *  get_order_no_slack(0x8000) = fls(4) = 3, get_order(0x8000) = 3
> +  */
> + length >>= PAGE_SHIFT + 1;
> + return fls(length);
> +}
> +
>  static int
>  transport_generic_get_mem(struct se_cmd *cmd)
>  {
>   u32 length = cmd->data_length;
> + u32 page_len;
>   unsigned int nents;
>   struct page *page;
>   gfp_t zero_flag;
>   int i = 0;
> + int order, max_order;
>  
>   nents = DIV_ROUND_UP(length, PAGE_SIZE);
>   cmd->t_data_sg = kmalloc(sizeof(struct scatterlist) * nents, 
> GFP_KERNEL);
>   if (!cmd->t_data_sg)
>   return -ENOMEM;
>  
> - cmd->t_data_nents = nents;
>   sg_init_table(cmd->t_data_sg, nents);
>  
>   zero_flag = cmd->se_cmd_flags & SCF_SCSI_DATA_CDB ? 0 : __GFP_ZERO;
>  
> + max_order = TRANSPORT_MAX_ORDER;

Please go ahead and turn max_order into an DEF_DEV_ATTRIB within
target_core_configfs.c, so we're able to change this value on the fly
using an per device configfs attr.

>   while (length) {
> - u32 page_len = min_t(u32, length, PAGE_SIZE);
> - page = alloc_page(GFP_KERNEL | zero_flag);
> - if (!page)
> - goto out;
> + order = get_order_no_slack(length);
> + for (;;) {
> + order = min(order, max_order);
> + page_len = min_t(u32, length, PAGE_SIZE << order);
> + page = alloc_pages(GFP_KERNEL | zero_flag, order);
> + if (page)
> + break;
> +
> + if (!order)
> + goto out;
> +
> + /*
> +  * Allocation failed, only try with a smaller order
> +  * from this point.
> +  */
> + max_order = order - 1;
> + }

Seems reasonable to back-off in reverse max_order in the face of large
order allocation failures..

>  
>   sg_set_page(>t_data_sg[i], page, page_len, 0);
>   length -= page_len;
>   i++;
>   }
> + cmd->t_data_nents = i;
> + sg_mark_end(>t_data_sg[i - 1]);
>   return 0;
>  
>  out:
> - while (i > 0) {
> - i--;
> - __free_page(sg_page(>t_data_sg[i]));
> + while (i-- > 0) {
> + struct scatterlist *sg = >t_data_sg[i];
> + __free_pages(sg_page(sg), get_order(sg->length));
>   }
>   kfree(cmd->t_data_sg);
>   cmd->t_data_sg = NULL;

So what I'd like to see 

[PATCH 2/2] perf header: Prepare tracepoint events regardless of name

[Namhyung Kim]

From: Namhyung Kim 

Current perf_evlist__set_tracepoint_names is a misnomer because it
finds and sets correspoding event_format in addition to the name.  So
skipping it when a event has set name already caused a trouble.

Rename it and set name only a event doesn't have one.

Reported-by: David Ahern 
Signed-off-by: Namhyung Kim 
---
Arnaldo, I made it incremental for your convenience.  But if you want
to drop my previous one I can resend with it.  Please let me know your
preference. :)

 tools/perf/util/header.c | 36 ++--
 1 file changed, 22 insertions(+), 14 deletions(-)

diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index eb7a8da2f4f5..19be34145a18 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -2500,33 +2500,39 @@ static int read_attr(int fd, struct perf_header *ph,
return ret <= 0 ? -1 : 0;
 }
 
-static int perf_evsel__set_tracepoint_name(struct perf_evsel *evsel,
-  struct pevent *pevent)
+static int perf_evsel__prepare_tracepoint_event(struct perf_evsel *evsel,
+   struct pevent *pevent)
 {
-   struct event_format *event = pevent_find_event(pevent,
-  evsel->attr.config);
+   struct event_format *event;
char bf[128];
 
+   /* already prepared */
+   if (evsel->tp_format)
+   return 0;
+
+   event = pevent_find_event(pevent, evsel->attr.config);
if (event == NULL)
return -1;
 
-   snprintf(bf, sizeof(bf), "%s:%s", event->system, event->name);
-   evsel->name = strdup(bf);
-   if (evsel->name == NULL)
-   return -1;
+   if (!evsel->name) {
+   snprintf(bf, sizeof(bf), "%s:%s", event->system, event->name);
+   evsel->name = strdup(bf);
+   if (evsel->name == NULL)
+   return -1;
+   }
 
evsel->tp_format = event;
return 0;
 }
 
-static int perf_evlist__set_tracepoint_names(struct perf_evlist *evlist,
-struct pevent *pevent)
+static int perf_evlist__prepare_tracepoint_events(struct perf_evlist *evlist,
+ struct pevent *pevent)
 {
struct perf_evsel *pos;
 
list_for_each_entry(pos, >entries, node) {
-   if (pos->attr.type == PERF_TYPE_TRACEPOINT && !pos->name &&
-   perf_evsel__set_tracepoint_name(pos, pevent))
+   if (pos->attr.type == PERF_TYPE_TRACEPOINT &&
+   perf_evsel__prepare_tracepoint_event(pos, pevent))
return -1;
}
 
@@ -2614,7 +2620,8 @@ int perf_session__read_header(struct perf_session 
*session, int fd)
 
lseek(fd, header->data_offset, SEEK_SET);
 
-   if (perf_evlist__set_tracepoint_names(session->evlist, session->pevent))
+   if (perf_evlist__prepare_tracepoint_events(session->evlist,
+  session->pevent))
goto out_delete_evlist;
 
header->frozen = 1;
@@ -2848,7 +2855,8 @@ int perf_event__process_tracing_data(union perf_event 
*event,
if (size_read + padding != size)
die("tracing data size mismatch");
 
-   perf_evlist__set_tracepoint_names(session->evlist, session->pevent);
+   perf_evlist__prepare_tracepoint_events(session->evlist,
+  session->pevent);
 
return size_read + padding;
 }
-- 
1.7.11.4

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

[PATCH 1/2] perf header: Fix a typo on evsel

[Namhyung Kim]

From: Namhyung Kim 

For checking return value of the strdup, 'event' should be 'evsel'.

Signed-off-by: Namhyung Kim 
---
 tools/perf/util/header.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
index 06ecd577d1b8..eb7a8da2f4f5 100644
--- a/tools/perf/util/header.c
+++ b/tools/perf/util/header.c
@@ -2512,7 +2512,7 @@ static int perf_evsel__set_tracepoint_name(struct 
perf_evsel *evsel,
 
snprintf(bf, sizeof(bf), "%s:%s", event->system, event->name);
evsel->name = strdup(bf);
-   if (event->name == NULL)
+   if (evsel->name == NULL)
return -1;
 
evsel->tp_format = event;
-- 
1.7.11.4

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

Re: [PATCH 1/3] mm: use get_page_migratetype instead of page_private

[Minchan Kim]

Hi Kame,

On Thu, Sep 06, 2012 at 11:02:47AM +0900, Kamezawa Hiroyuki wrote:
> (2012/09/05 16:26), Minchan Kim wrote:
> > page allocator uses set_page_private and page_private for handling
> > migratetype when it frees page. Let's replace them with [set|get]
> > _page_migratetype to make it more clear.
> > 
> > Signed-off-by: Minchan Kim 
> 
> Hmm. one request from me.
> 
> > ---
> >   include/linux/mm.h  |   10 ++
> >   mm/page_alloc.c |   11 +++
> >   mm/page_isolation.c |2 +-
> >   3 files changed, 18 insertions(+), 5 deletions(-)
> > 
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index 5c76634..86d61d6 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -249,6 +249,16 @@ struct inode;
> >   #define page_private(page)((page)->private)
> >   #define set_page_private(page, v) ((page)->private = (v))
> >   
> > +static inline void set_page_migratetype(struct page *page, int migratetype)
> > +{
> > +   set_page_private(page, migratetype);
> > +}
> > +
> > +static inline int get_page_migratetype(struct page *page)
> > +{
> > +   return page_private(page);
> > +}
> > +
> 
> Could you add comments to explain "when this function returns expected value" 
> ?
> These functions can work well only in very restricted area of codes.

Yes. It works only if the page exist in free_list.
I will add the comment about that and hope change function name
get_page_migratetype with get_buddypage_migratetype.
It would be less confusing.

Thanks.

-- 
Kind regards,
Minchan Kim
--
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] mm: use get_page_migratetype instead of page_private

[Minchan Kim]

Hi Mel,

On Wed, Sep 05, 2012 at 10:09:55AM +0100, Mel Gorman wrote:
> On Wed, Sep 05, 2012 at 04:26:00PM +0900, Minchan Kim wrote:
> > page allocator uses set_page_private and page_private for handling
> > migratetype when it frees page. Let's replace them with [set|get]
> > _page_migratetype to make it more clear.
> > 
> > Signed-off-by: Minchan Kim 
> 
> Maybe it's because I'm used of setting set_page_private() in the page
> allocator and what it means but I fear that it'll be very easy to confuse
> get_page_migratetype() with get_pageblock_migratetype(). The former only
> works while the page is in the buddy allocator. The latter can be called
> at any time. I'm not against the patch as such but I'm not convinced
> either :)

How about using name "get_buddypage_migratetype" instead of 
"get_page_migratetype"?

> 
> One nit below
> 
> > ---
> >  include/linux/mm.h  |   10 ++
> >  mm/page_alloc.c |   11 +++
> >  mm/page_isolation.c |2 +-
> >  3 files changed, 18 insertions(+), 5 deletions(-)
> > 
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index 5c76634..86d61d6 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -249,6 +249,16 @@ struct inode;
> >  #define page_private(page) ((page)->private)
> >  #define set_page_private(page, v)  ((page)->private = (v))
> >  
> > +static inline void set_page_migratetype(struct page *page, int migratetype)
> > +{
> > +   set_page_private(page, migratetype);
> > +}
> > +
> > +static inline int get_page_migratetype(struct page *page)
> > +{
> > +   return page_private(page);
> > +}
> > +
> >  /*
> >   * FIXME: take this include out, include page-flags.h in
> >   * files which need it (119 of them)
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 710d91c..103ba66 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> > @@ -671,8 +671,10 @@ static void free_pcppages_bulk(struct zone *zone, int 
> > count,
> > /* must delete as __free_one_page list manipulates */
> > list_del(>lru);
> > /* MIGRATE_MOVABLE list may include MIGRATE_RESERVEs */
> > -   __free_one_page(page, zone, 0, page_private(page));
> > -   trace_mm_page_pcpu_drain(page, 0, page_private(page));
> > +   __free_one_page(page, zone, 0,
> > +   get_page_migratetype(page));
> > +   trace_mm_page_pcpu_drain(page, 0,
> > +   get_page_migratetype(page));
> > } while (--to_free && --batch_free && !list_empty(list));
> > }
> > __mod_zone_page_state(zone, NR_FREE_PAGES, count);
> > @@ -731,6 +733,7 @@ static void __free_pages_ok(struct page *page, unsigned 
> > int order)
> > __count_vm_events(PGFREE, 1 << order);
> > free_one_page(page_zone(page), page, order,
> > get_pageblock_migratetype(page));
> > +
> > local_irq_restore(flags);
> >  }
> >  
> 
> Unnecessary whitespace change.

Will fix.
Thanks!

-- 
Kind regards,
Minchan Kim
--
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] drm/exynos: fix double call of drm_prime_(init/destroy)_file_private

[김승우]

Hi Mandeep,

On 2012년 09월 06일 06:47, Mandeep Singh Baines wrote:
> The double invocations are incorrect but seem to be safe so I don't
> think this will fix any bugs.
> 
> Before:
> 
> [7.639366] drm_prime_init_file ee3675d0
> [7.639377] drm_prime_init_file ee3675d0
> [7.639507] drm_prime_destroy_file ee3675d0
> [7.639518] drm_prime_destroy_file ee3675d0
> [7.639802] drm_prime_init_file ee372390
> [7.639810] drm_prime_init_file ee372390
> [8.473316] drm_prime_init_file ee356390
> [8.473331] drm_prime_init_file ee356390
> 
> After:
> 
> [6.363842] drm_prime_init_file edc2e5d0
> [6.363994] drm_prime_destroy_file edc2e5d0
> [6.364260] drm_prime_init_file edc2e750
> [8.004837] drm_prime_init_file ee36ded0
> 

You are right. prime file_priv is handled by drm_fops.c, so it can be
removed from exynos drm.

Thanks for your patch.

> Signed-off-by: Mandeep Singh Baines 
> CC: Stéphane Marchesin 
> CC: Pawel Osciak 
> CC: Inki Dae 
> CC: Joonyoung Shim 
> CC: Seung-Woo Kim 
> CC: Kyungmin Park 
> CC: David Airlie 
> CC: dri-de...@lists.freedesktop.org

Acked-by: Seung-Woo Kim 

> ---
>  drivers/gpu/drm/exynos/exynos_drm_drv.c |2 --
>  1 files changed, 0 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
> b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> index ebacec6..a27b8ff 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> @@ -160,7 +160,6 @@ static int exynos_drm_open(struct drm_device *dev, struct 
> drm_file *file)
>   if (!file_priv)
>   return -ENOMEM;
>  
> - drm_prime_init_file_private(>prime);
>   file->driver_priv = file_priv;
>  
>   return exynos_drm_subdrv_open(dev, file);
> @@ -184,7 +183,6 @@ static void exynos_drm_preclose(struct drm_device *dev,
>   e->base.destroy(>base);
>   }
>   }
> - drm_prime_destroy_file_private(>prime);
>   spin_unlock_irqrestore(>event_lock, flags);
>  
>   exynos_drm_subdrv_close(dev, file);
> 

-- 
Seung-Woo Kim
Samsung Software R Center
--

--
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] perf: add SLANG_INC for slang.h

[Liang Li]

On 2012-09-06 06:41, Arnaldo Carvalho de Melo  wrote:
> Em Wed, Sep 05, 2012 at 10:23:03PM +0100, Richard Purdie escreveu:
> > On Wed, 2012-09-05 at 13:54 -0700, Arnaldo Carvalho de Melo wrote:
> > > Em Fri, Aug 24, 2012 at 11:10:39AM +0800, Liang Li escreveu:
> > > > CFLAGS was previously hard coded to contain "-I/usr/include/slang" to
> > > > work with hosts that have "/usr/include/slang/slang.h" as well as hosts
> > > > that have "/usr/include/slang.h". This path can cause compile warnings
> > > > like:
> > > > 
> > > > cc1: warning: '/usr/include/slang' doesn't exists.
> > > > 
> > > > or
> > > > 
> > > > cc1: warning: include location "/usr/include/slang" is unsafe for
> > > > cross-compilation [-Wpoison-system-directories]
> > > > 
> > > > Then in some cases warnings become errors if WERROR is enabled hence
> > > > build errors.
> > > > 
> > > > To fix this issue, we can use -idirafter to downgrade the priority of 
> > > > the
> > > > default hard coded path. We can also make the slang include directory
> > > > a variable, to allow the user to specify SLANG_INC and set their own
> > > > include location. And add a '=' prefix to indicate better
> > > > compatibility with sysroot/cross compile cases.
> > > 
> > > CC /home/acme/git/build/perf/builtin-diff.o
> > > In file included from util/../ui/keysyms.h:4,
> > >  from util/hist.h:142,
> > >  from builtin-diff.c:11:
> > > util/../ui/libslang.h:12:19: error: slang.h: No such file or directory
> > > util/../ui/libslang.h:14:5: error: "SLANG_VERSION" is not defined
> > > In file included from util/../ui/keysyms.h:4,
> > >  from util/hist.h:142,
> > >  from util/evsel.h:10,
> > >  from util/evlist.h:8,
> > >  from builtin-annotate.c:20:
> > > util/../ui/libslang.h:12:19: error: slang.h: No such file or directory
> > > util/../ui/libslang.h:14:5: error: "SLANG_VERSION" is not defined
> > > builtin-annotate.c: In function ‘hists__find_annotations’:
> > > builtin-annotate.c:122: error: ‘SL_KEY_RIGHT’ undeclared (first use in
> > > this function)
> > > builtin-annotate.c:122: error: (Each undeclared identifier is reported
> > > only once
> > > builtin-annotate.c:122: error: for each function it appears in.)
> > > builtin-annotate.c:134: error: ‘SL_KEY_LEFT’ undeclared (first use in
> > > this function)
> > > make: *** [/home/acme/git/build/perf/builtin-annotate.o] Error 1
> > > make: *** Waiting for unfinished jobs
> > > make: *** [/home/acme/git/build/perf/builtin-diff.o] Error 1
> > > make: Leaving directory `/home/git/linux/tools/perf'
> > > [acme@sandy linux]$ cat /etc/redhat-release 
> > > Red Hat Enterprise Linux Server release 6.3 (Santiago)
> > > [acme@sandy linux]$
> > 
> > Does:
> > 
> > SLANG_INC ?= -I=/usr/include/slang
> > 
> > work any better? Its hard to tell from the above error which bit of the
> 
> I'll try later
> 
> > syntax is failing. Which gcc version is it?
> 
> [acme@sandy linux]$ gcc -v
> Using built-in specs.
> Target: x86_64-redhat-linux
> Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
> --infodir=/usr/share/info
> --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap
> --enable-shared --enable-threads=posix --enable-checking=release
> --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
> --enable-gnu-unique-object
> --enable-languages=c,c++,objc,obj-c++,java,fortran,ada
> --enable-java-awt=gtk --disable-dssi
> --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
> --enable-libgcj-multifile --enable-java-maintainer-mode
> --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
> --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic
> --with-arch_32=i686 --build=x86_64-redhat-linux
> Thread model: posix
> gcc version 4.4.6 20120305 (Red Hat 4.4.6-4) (GCC) 
> [acme@sandy linux]$

Seems like there is no slang.h installed. Could you please check:

$ find /usr/include/ -name slang.h

On my FC17:

$ find /usr/include/ -name slang.h
/usr/include/slang/slang.h
/usr/include/slang.h
$ rpm -qf /usr/include/slang.h
slang-devel-2.2.4-3.fc17.x86_64
$ rpm -qf /usr/include/slang/slang.h
slang-devel-2.2.4-3.fc17.x86_64

---

And does 'export SLANG_INC=' works any
better? :)

Cheers,
Liang Li
--
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 03/11 V5] workqueue: new day don't need WORKER_REBIND for busy rebinding

[Lai Jiangshan]

On 09/06/2012 02:31 AM, Tejun Heo wrote:
> On Wed, Sep 05, 2012 at 06:37:40PM +0800, Lai Jiangshan wrote:
>> because old busy_worker_rebind_fn() have to wait until all idle worker 
>> finish.
>> so we have to use two flags WORKER_UNBOUND and WORKER_REBIND to avoid
>> prematurely clear all NOT_RUNNING bit when highly frequent offline/online.
>>
>> but current code don't need to wait idle workers. so we don't need to
>> use two flags, just one is enough. remove WORKER_REBIND from busy rebinding.
> 
> ROGUE / REBIND thing existed for busy workers from the beginning when
> there was no idle worker rebinding, so this definitely wasn't about
> whether idle rebind is synchronous or not. 

In very old day, this definitely wasn't about whether idle rebind is 
synchronous or not.
but after you reimplement rebind_worker(), it is the only reason for 
WORKER_REBIND in busy rebinding.

if I miss something, this 03/11 will be wrong. the old code did not comment all 
why
WORKER_REBIND is needed. so we have to think more about the correctness of this 
03/11.

> Trying to remember
> what... ah, okay, setting of DISASSOCIATED and setting of WORKER_ROGUE
> didn't use to happen together with gcwq->lock held.  CPU_DOWN would
> first set ROGUE and then later on set DISASSOCIATED, so if the
> rebind_fn kicks in inbetween that, it would break CPU_DOWN.
> 
> I think now that both CPU_DOWN and UP are done under single holding of
> gcwq->lock, this should be safe.  It would be nice to note what
> changed in the patch description and the atomicity requirement as a
> comment tho.
> 

Oh, I forgot to add changelog about single holding of gcwq->lock.


Thanks
Lai

--
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] memory-hotplug: remove MIGRATE_ISOLATE from free_area->free_list

[Minchan Kim]

Hi Michal,

On Wed, Sep 05, 2012 at 07:28:23PM +0200, Michal Nazarewicz wrote:
> On Wed, Sep 05 2012, Minchan Kim wrote:
> > Normally, MIGRATE_ISOLATE type is used for memory-hotplug.
> > But it's irony type because the pages isolated would exist
> > as free page in free_area->free_list[MIGRATE_ISOLATE] so people
> > can think of it as allocatable pages but it is *never* allocatable.
> > It ends up confusing NR_FREE_PAGES vmstat so it would be
> > totally not accurate so some of place which depend on such vmstat
> > could reach wrong decision by the context.
> >
> > There were already report about it.[1]
> > [1] 702d1a6e, memory-hotplug: fix kswapd looping forever problem
> >
> > Then, there was other report which is other problem.[2]
> > [2] http://www.spinics.net/lists/linux-mm/msg41251.html
> >
> > I believe it can make problems in future, too.
> > So I hope removing such irony type by another design.
> >
> > I hope this patch solves it and let's revert [1] and doesn't need [2].
> >
> > Cc: Mel Gorman 
> > Cc: Kamezawa Hiroyuki 
> > Cc: Yasuaki Ishimatsu 
> > Cc: Konrad Rzeszutek Wilk 
> > Signed-off-by: Minchan Kim 
> 
> If you ask me, I'm not convinced that this improves anything.

At least, it removes MIGRATE_ISOLATE type in free_area->free_list
which is very irony type as I mentioned. I really don't like such
type in free_area. What's the benefit if we remain code as it is?
It could make more problem in future.

> 
> > ---
> >
> > It's very early version which show the concept and just tested it with 
> > simple
> > test and works. This patch is needed indepth review from memory-hotplug
> > guys from fujitsu because I saw there are lots of patches recenlty they 
> > sent to
> > about memory-hotplug change. Please take a look at this patch.
> >
> >  drivers/xen/balloon.c  |3 +-
> >  include/linux/mmzone.h |2 +-
> >  include/linux/page-isolation.h |   11 ++-
> >  mm/internal.h  |4 +
> >  mm/memory_hotplug.c|   38 +
> >  mm/page_alloc.c|   35 
> >  mm/page_isolation.c|  184 
> > +++-
> >  7 files changed, 218 insertions(+), 59 deletions(-)
> >
> > diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c
> > index 31ab82f..617d7a3 100644
> > --- a/drivers/xen/balloon.c
> > +++ b/drivers/xen/balloon.c
> > @@ -50,6 +50,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  
> >  #include 
> >  #include 
> > @@ -66,7 +67,6 @@
> >  #include 
> >  #include 
> >  #include 
> > -
> 
> Unrelated and in fact should not be here at all.

Okay.

> 
> >  /*
> >   * balloon_process() state:
> >   *
> > @@ -268,6 +268,7 @@ static void xen_online_page(struct page *page)
> > else
> > --balloon_stats.balloon_hotplug;
> >  
> > +   delete_from_isolated_list(page);
> > mutex_unlock(_mutex);
> >  }
> >  
> > diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
> > index 2daa54f..977dceb 100644
> > --- a/include/linux/mmzone.h
> > +++ b/include/linux/mmzone.h
> > @@ -57,7 +57,7 @@ enum {
> >  */
> > MIGRATE_CMA,
> >  #endif
> > -   MIGRATE_ISOLATE,/* can't allocate from here */
> > +   MIGRATE_ISOLATE,
> > MIGRATE_TYPES
> >  };
> 
> Why remove that comment?

Argh, It was my mistake.
I wanted to remove MIGRATE_ISOLTE from free_area.
So here it goes for that.

diff --git a/include/linux/mmzone.h b/include/linux/mmzone.h
index 977dceb..438bab8 100644
--- a/include/linux/mmzone.h
+++ b/include/linux/mmzone.h
@@ -57,8 +57,8 @@ enum {
 */
MIGRATE_CMA,
 #endif
-   MIGRATE_ISOLATE,
-   MIGRATE_TYPES
+   MIGRATE_TYPES,
+   MIGRATE_ISOLATE
 };
 
 #ifdef CONFIG_CMA
diff --git a/mm/vmstat.c b/mm/vmstat.c
index df7a674..bb59ff7 100644
--- a/mm/vmstat.c
+++ b/mm/vmstat.c
@@ -616,7 +616,6 @@ static char * const migratetype_names[MIGRATE_TYPES] = {
 #ifdef CONFIG_CMA
"CMA",
 #endif
-   "Isolate",
 };


> 
> > diff --git a/include/linux/page-isolation.h b/include/linux/page-isolation.h
> > index 105077a..a26eb8a 100644
> > --- a/include/linux/page-isolation.h
> > +++ b/include/linux/page-isolation.h
> > @@ -1,11 +1,16 @@
> >  #ifndef __LINUX_PAGEISOLATION_H
> >  #define __LINUX_PAGEISOLATION_H
> >  
> > +extern struct list_head isolated_pages;
> >  
> >  bool has_unmovable_pages(struct zone *zone, struct page *page, int count);
> >  void set_pageblock_migratetype(struct page *page, int migratetype);
> >  int move_freepages_block(struct zone *zone, struct page *page,
> > int migratetype);
> > +
> > +void isolate_free_page(struct page *page, unsigned int order);
> > +void delete_from_isolated_list(struct page *page);
> > +
> >  /*
> >   * Changes migrate type in [start_pfn, end_pfn) to be MIGRATE_ISOLATE.
> >   * If specified range includes migrate types other than MOVABLE or CMA,
> > @@ -20,9 +25,13 @@ start_isolate_page_range(unsigned long start_pfn, 
> > unsigned long 

Re: [PATCH 1/3] mm: use get_page_migratetype instead of page_private

[Kamezawa Hiroyuki]

(2012/09/05 16:26), Minchan Kim wrote:
> page allocator uses set_page_private and page_private for handling
> migratetype when it frees page. Let's replace them with [set|get]
> _page_migratetype to make it more clear.
> 
> Signed-off-by: Minchan Kim 

Hmm. one request from me.

> ---
>   include/linux/mm.h  |   10 ++
>   mm/page_alloc.c |   11 +++
>   mm/page_isolation.c |2 +-
>   3 files changed, 18 insertions(+), 5 deletions(-)
> 
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 5c76634..86d61d6 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -249,6 +249,16 @@ struct inode;
>   #define page_private(page)  ((page)->private)
>   #define set_page_private(page, v)   ((page)->private = (v))
>   
> +static inline void set_page_migratetype(struct page *page, int migratetype)
> +{
> + set_page_private(page, migratetype);
> +}
> +
> +static inline int get_page_migratetype(struct page *page)
> +{
> + return page_private(page);
> +}
> +

Could you add comments to explain "when this function returns expected value" ?
These functions can work well only in very restricted area of codes.

By the way, does these functions should be static-inline ?

Thanks,
-Kame

>   /*
>* FIXME: take this include out, include page-flags.h in
>* files which need it (119 of them)
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 710d91c..103ba66 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -671,8 +671,10 @@ static void free_pcppages_bulk(struct zone *zone, int 
> count,
>   /* must delete as __free_one_page list manipulates */
>   list_del(>lru);
>   /* MIGRATE_MOVABLE list may include MIGRATE_RESERVEs */
> - __free_one_page(page, zone, 0, page_private(page));
> - trace_mm_page_pcpu_drain(page, 0, page_private(page));
> + __free_one_page(page, zone, 0,
> + get_page_migratetype(page));
> + trace_mm_page_pcpu_drain(page, 0,
> + get_page_migratetype(page));
>   } while (--to_free && --batch_free && !list_empty(list));
>   }
>   __mod_zone_page_state(zone, NR_FREE_PAGES, count);
> @@ -731,6 +733,7 @@ static void __free_pages_ok(struct page *page, unsigned 
> int order)
>   __count_vm_events(PGFREE, 1 << order);
>   free_one_page(page_zone(page), page, order,
>   get_pageblock_migratetype(page));
> +
>   local_irq_restore(flags);
>   }
>   
> @@ -1134,7 +1137,7 @@ static int rmqueue_bulk(struct zone *zone, unsigned int 
> order,
>   if (!is_migrate_cma(mt) && mt != MIGRATE_ISOLATE)
>   mt = migratetype;
>   }
> - set_page_private(page, mt);
> + set_page_migratetype(page, mt);
>   list = >lru;
>   }
>   __mod_zone_page_state(zone, NR_FREE_PAGES, -(i << order));
> @@ -1301,7 +1304,7 @@ void free_hot_cold_page(struct page *page, int cold)
>   return;
>   
>   migratetype = get_pageblock_migratetype(page);
> - set_page_private(page, migratetype);
> + set_page_migratetype(page, migratetype);
>   local_irq_save(flags);
>   if (unlikely(wasMlocked))
>   free_page_mlock(page);
> diff --git a/mm/page_isolation.c b/mm/page_isolation.c
> index 64abb33..acf65a7 100644
> --- a/mm/page_isolation.c
> +++ b/mm/page_isolation.c
> @@ -199,7 +199,7 @@ __test_page_isolated_in_pageblock(unsigned long pfn, 
> unsigned long end_pfn)
>   if (PageBuddy(page))
>   pfn += 1 << page_order(page);
>   else if (page_count(page) == 0 &&
> - page_private(page) == MIGRATE_ISOLATE)
> + get_page_migratetype(page) == MIGRATE_ISOLATE)
>   pfn += 1;
>   else
>   break;
> 


--
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] USB/host: Cleanup unneccessary irq disable code

[Liu, Chuansheng]

Because the IRQF_DISABLED as the flag is now a NOOP and has been
deprecated and in hardirq context the interrupt is disabled.

so in usb/host code:
Removing the usage of flag IRQF_DISABLED;
Removing the calling local_irq save/restore actions in irq
handler usb_hcd_irq();

Signed-off-by: liu chuansheng 
Acked-by: Alan Stern 
---
 drivers/usb/core/hcd.c   |   15 ---
 drivers/usb/host/ehci-ls1x.c |2 +-
 drivers/usb/host/ohci-xls.c  |2 +-
 3 files changed, 2 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index bc84106..f84ddea 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2153,15 +2153,8 @@ EXPORT_SYMBOL_GPL(usb_bus_start_enum);
 irqreturn_t usb_hcd_irq (int irq, void *__hcd)
 {
struct usb_hcd  *hcd = __hcd;
-   unsigned long   flags;
irqreturn_t rc;
 
-   /* IRQF_DISABLED doesn't work correctly with shared IRQs
-* when the first handler doesn't use it.  So let's just
-* assume it's never used.
-*/
-   local_irq_save(flags);
-
if (unlikely(HCD_DEAD(hcd) || !HCD_HW_ACCESSIBLE(hcd)))
rc = IRQ_NONE;
else if (hcd->driver->irq(hcd) == IRQ_NONE)
@@ -2169,7 +2162,6 @@ irqreturn_t usb_hcd_irq (int irq, void *__hcd)
else
rc = IRQ_HANDLED;
 
-   local_irq_restore(flags);
return rc;
 }
 EXPORT_SYMBOL_GPL(usb_hcd_irq);
@@ -2358,13 +2350,6 @@ static int usb_hcd_request_irqs(struct usb_hcd *hcd,
 
if (hcd->driver->irq) {
 
-   /* IRQF_DISABLED doesn't work as advertised when used together
-* with IRQF_SHARED. As usb_hcd_irq() will always disable
-* interrupts we can remove it here.
-*/
-   if (irqflags & IRQF_SHARED)
-   irqflags &= ~IRQF_DISABLED;
-
snprintf(hcd->irq_descr, sizeof(hcd->irq_descr), "%s:usb%d",
hcd->driver->description, hcd->self.busnum);
retval = request_irq(irqnum, _hcd_irq, irqflags,
diff --git a/drivers/usb/host/ehci-ls1x.c b/drivers/usb/host/ehci-ls1x.c
index a283e59..425cb4a 100644
--- a/drivers/usb/host/ehci-ls1x.c
+++ b/drivers/usb/host/ehci-ls1x.c
@@ -119,7 +119,7 @@ static int ehci_hcd_ls1x_probe(struct platform_device *pdev)
goto err_release_region;
}
 
-   ret = usb_add_hcd(hcd, irq, IRQF_DISABLED | IRQF_SHARED);
+   ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto err_iounmap;
 
diff --git a/drivers/usb/host/ohci-xls.c b/drivers/usb/host/ohci-xls.c
index 41e378f..84201cd 100644
--- a/drivers/usb/host/ohci-xls.c
+++ b/drivers/usb/host/ohci-xls.c
@@ -56,7 +56,7 @@ static int ohci_xls_probe_internal(const struct hc_driver 
*driver,
goto err3;
}
 
-   retval = usb_add_hcd(hcd, irq, IRQF_DISABLED | IRQF_SHARED);
+   retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (retval != 0)
goto err4;
return retval;
-- 
1.7.0.4

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

Re: [RFC PATCH 0/3] target: try satisfying memory requests with higher-order allocations

[Nicholas A. Bellinger]

On Wed, 2012-09-05 at 17:13 +0200, Paolo Bonzini wrote:
> Hi all,
> 
> while testing PSCSI I noticed that even requests for a smallish amount
> of data (approximately 700 KB) failed due to an excessive number of
> segments in the request.  In fact, using alloc_page resulted in a
> completely fragmented request, with no merging of consecutive pages
> at all.
> 
> This patch series fixes this problem by using higher-order allocations
> to build the data scatterlist.  The problem is that iscsi assumes that the
> scatterlist consists of single pages, which is not true anymore.  So
> patch 2 has to introduce some relatively complicated changes to
> iscsi_map_iovec and iscsi_unmap_iovec.
> 

So enabling multi-page per SGL support is a feature that has been
dormant within target core for a long time.  It's about time that we
start taking advantage of it again.  ;)

> While doing this, I noticed something strange in iscsit_do_crypto_hash_sg.
> Patch 1 adds a warning about it.
> 

M, looks like a separate bug with DataDigest enabled.  

> The approach may be completely wrong and it needs more testing anyway.
> Please review!
> 

Adding my comments inline.

Thanks Paolo!

--nab

> Paolo
> 
> Paolo Bonzini (3):
>   tcm_iscsi: warn on incorrect precondition for iscsit_do_crypto_hash_sg
>   tcm_iscsi: support multiple sizes in the scatterlist
>   target: try satisfying memory requests with contiguous blocks
> 
>  drivers/target/iscsi/iscsi_target.c  |  106 
> +-
>  drivers/target/iscsi/iscsi_target_core.h |2 +-
>  drivers/target/target_core_transport.c   |   58 ++---
>  3 files changed, 138 insertions(+), 28 deletions(-)
> 
> --
> To unsubscribe from this list: send the line "unsubscribe target-devel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


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

[GIT PULL] MMC fixes for 3.6-rc5

[Chris Ball]

Hi Linus,

Please pull from:

  git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git 
tags/mmc-fixes-for-3.6-rc5

to receive MMC fixes for 3.6-rc5.  There are no merge conflicts, and the
patches have been tested in linux-next.  Thanks.


The following changes since commit 0d7614f09c1ebdbaa1599a5aba7593f147bf96ee:

  Linux 3.6-rc1 (2012-08-02 16:38:10 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/cjb/mmc.git 
tags/mmc-fixes-for-3.6-rc5

for you to fetch changes up to 75b53aee2f4fe6375c6007226bf68d75b5c4a929:

  mmc: omap: fix broken PIO mode (2012-09-04 13:58:11 -0400)


MMC fixes for 3.6-rc5:
 - a firmware bug on several Samsung MoviNAND eMMC models causes
   permanent corruption on the device when secure erase and secure trim
   requests are made, so we disable those requests on these eMMC devices.
 - atmel-mci: fix a hang with some SD cards by waiting for not-busy flag.
 - dw_mmc: low-power mode breaks SDIO interrupts; fix PIO error handling;
   fix handling of error interrupts.
 - mxs-mmc: fix deadlocks; fix compile error due to dma.h arch change.
 - omap: fix broken PIO mode causing memory corruption.
 - sdhci-esdhc: fix card detection.


Doug Anderson (1):
  mmc: dw_mmc: Disable low power mode if SDIO interrupts are used

Ian Chen (1):
  mmc: card: Skip secure erase on MoviNAND; causes unrecoverable corruption.

Lauri Hintsala (2):
  mmc: mxs-mmc: fix deadlock in SDIO IRQ case
  mmc: mxs-mmc: fix deadlock caused by recursion loop

Ludovic Desroches (1):
  mmc: atmel-mci: not busy flag has also to be used for read operations

Paul Walmsley (1):
  mmc: omap: fix broken PIO mode

Seungwon Jeon (3):
  mmc: dw_mmc: amend using error interrupt status
  mmc: dw_mmc: correct mishandling error interrupt
  mmc: dw_mmc: fix error handling in PIO mode

Shawn Guo (1):
  mmc: sdhci-esdhc: break out early if clock is 0

Sonic Zhang (1):
  mmc: bfin_sdh: fix dma_desc_array build error

 drivers/mmc/card/block.c   | 26 -
 drivers/mmc/host/atmel-mci.c   |  6 ++-
 drivers/mmc/host/bfin_sdh.c|  7 
 drivers/mmc/host/dw_mmc.c  | 85 +++---
 drivers/mmc/host/mxs-mmc.c | 14 +++
 drivers/mmc/host/omap.c| 14 +--
 drivers/mmc/host/sdhci-esdhc.h |  6 +--
 include/linux/mmc/card.h   |  1 +
 8 files changed, 98 insertions(+), 61 deletions(-)

-- 
Chris Ball  
One Laptop Per Child
--
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/10 V4] workqueue: add manage_workers_slowpath()

[Lai Jiangshan]

On 09/05/2012 09:12 AM, Tejun Heo wrote:
> Hello, Lai.
> 
> On Sun, Sep 02, 2012 at 12:28:22AM +0800, Lai Jiangshan wrote:
>> If hotplug code grabbed the manager_mutex and worker_thread try to create
>> a worker, the manage_worker() will return false and worker_thread go to
>> process work items. Now, on the CPU, all workers are processing work items,
>> no idle_worker left/ready for managing. It breaks the concept of workqueue
>> and it is bug.
>>
>> So when manage_worker() failed to grab the manager_mutex, it should
>> try to enter normal process contex and then compete on the manager_mutex
>> instead of return false.
>>
>> To safely do this, we add manage_workers_slowpath() and the worker
>> go to process work items mode to do the managing jobs. thus
>> managing jobs are processed via work item and can free to compete
>> on manager_mutex.
> 
> Ummm this seems overly complicated.  How about scheduling rebind
> work to a worker and forcing it to break out of the work processing
> loop?  I think it can be done fairly easily using POOL_MANAGE_WORKERS
> - set it from the rebind function, break out of work processing loop
> if it's set, replace need_to_manage_workers() with POOL_MANAGE_WORKERS
> test (the function really isn't necessary) and always jump back to
> recheck afterwards.  It might need a bit more mangling here and there
> but that should be the essence of it.  I'll give a stab at it later
> today.
> 

This approach is a little like my unsent approach3.(I will explain in other 
mail)
This approach is most complicated and changing more code if it is implemented.

First we should rebind/unbind separated by pool. because,
if we queue the rebind-work to high-pri pool, we will break normal-pool
vice versa

and this forces us move DISASSOCIATED to pool-flags.
and this forces us add more code in cpu-notify

second, reuse POOL_MANAGE_WORKERS, or add new one.

third, need to restruct of rebind/unbind and change a lot in worker_thread.

my partial/unsent approach3 has almost the same problem.
(different, my approach3 don't use work item, it is checked and called from
the "recheck" label of worker_thread. it is called with WORKER_PREP bit set
and it uses "mutex_trylock" to grab lock like manage_workers())

how much code will be changed for only unbind part of this approach:


 kernel/workqueue.c |  103 ++--
 1 files changed, 76 insertions(+), 27 deletions(-)


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

Re: [PATCH 2/2] workqueue: fix possible deadlock in idle worker rebinding

[Lai Jiangshan]

On 09/06/2012 07:11 AM, Tejun Heo wrote:
> On Tue, Sep 04, 2012 at 11:16:32PM -0700, Tejun Heo wrote:
>> Currently, rebind_workers() and idle_worker_rebind() are two-way
>> interlocked.  rebind_workers() waits for idle workers to finish
>> rebinding and rebound idle workers wait for rebind_workers() to finish
>> rebinding busy workers before proceeding.
> 
> Applied to wq/for-3.6-fixes.
> 
> Thanks.
> 

OK for me.

Thanks.
Lai
--
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/17] perf header: Set tracepoint event name only if not set

[Namhyung Kim]

On Wed, 05 Sep 2012 18:01:16 -0600, David Ahern wrote:
> On 9/5/12 5:08 PM, Arnaldo Carvalho de Melo wrote:
>> From: Namhyung Kim 
>>
>> The event name can be set already by processing a event_desc data.
>>
>> So check it before setting to prevent possible leak.
>>
>> Signed-off-by: Namhyung Kim 
>> Cc: Ingo Molnar 
>> Cc: Paul Mackerras 
>> Cc: Peter Zijlstra 
>> Link: 
>> http://lkml.kernel.org/r/1346821373-31621-3-git-send-email-namhy...@kernel.org
>> Signed-off-by: Arnaldo Carvalho de Melo 
>> ---
>>   tools/perf/util/header.c |2 +-
>>   1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/tools/perf/util/header.c b/tools/perf/util/header.c
>> index a124b93..05c9310 100644
>> --- a/tools/perf/util/header.c
>> +++ b/tools/perf/util/header.c
>> @@ -2314,7 +2314,7 @@ static int perf_evlist__set_tracepoint_names(struct 
>> perf_evlist *evlist,
>>  struct perf_evsel *pos;
>>
>>  list_for_each_entry(pos, >entries, node) {
>> -if (pos->attr.type == PERF_TYPE_TRACEPOINT &&
>> +if (pos->attr.type == PERF_TYPE_TRACEPOINT && !pos->name &&
>>  perf_evsel__set_tracepoint_name(pos, pevent))
>>  return -1;
>>  }
>>
>
> I'm getting a segfault running perf-script due to this patch. Most
> likely this is exposing another problem. Back trace is:

Hmm.  It's because evsel->tp_format being not set, not sure why I didn't
detect this during tests.  Will find out a solution.

Thanks,
Namhyung


>
> #0  0x0049f4f2 in pevent_event_info (s=0x7fffdab0,
> event=0x0, record=0x7fffda70)
> at tools/lib/traceevent/event-parse.c:4183
> #1  0x0046cd52 in event_format__print (event=0x0,
> cpu=, data=, size=)
> at util/trace-event-parse.c:182
> #2  0x0042d41b in process_event (event=0x7fffef9d1e60,
> sample=0x7fffdc90, evsel=0x90d870, machine=0x906f80,
> al=) at builtin-script.c:415
> #3  0x0042c4e1 in process_sample_event (tool=,
> event=0x7fffef9d1e60, sample=0x7fffdc90, evsel=
> 0x90d870, machine=0x906f80) at builtin-script.c:515
> #4  0x0046864d in perf_session_deliver_event
> (session=, event=0x7fffef9d1e60, sample=0x7fffdc90,
> tool=0x79d020, file_offset=) at util/session.c:1065
> #5  0x00468c5a in flush_sample_queue (s=0x906f20,
> tool=0x79d020) at util/session.c:719
> #6  0x00468d46 in process_finished_round (tool= out>, event=, session=0x906f20)
> at util/session.c:790
> #7  0x00469055 in perf_session__process_user_event
> (file_offset=541768, tool=0x79d020, event=0x7fffefa2b448,
> session=0x906f20) at util/session.c:1129
> #8  perf_session__process_event (session=0x906f20,
> event=0x7fffefa2b448, tool=0x79d020, file_offset=541768)
> at util/session.c:1161
> #9  0x0046a851 in __perf_session__process_events
> (session=0x906f20, data_offset=,
> data_size=, file_size=2564784, tool=0x79d020) at
> util/session.c:1429
> #10 0x0042ebdc in __cmd_script (session=0x906f20) at
> builtin-script.c:548
--
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: 3.5-rc7: nouveau doesn't X on NVC0

[Dave Airlie]

On Thu, Sep 6, 2012 at 11:15 AM, Linus Torvalds
 wrote:
> [ This got dropped somehow - it's in my draft folder. The bisection
> may be irrelevant now: does it work with current git, since we've had
> some nouveau changes? ]
>
> On Tue, Aug 28, 2012 at 8:26 AM, Alexey Dobriyan  wrote:
>> Ping!
>>
>> No X for me with 3.6-rc2.

Can you try -rc4?

Ben thinks the pcopy fix should fix it.

Dave.
--
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] x86/oprofile: Fix the calltrace upon profiling some specified events with oprofile

[wyang1]

On 09/04/2012 06:24 PM, Robert Richter wrote:

Wei,

see my comments below.

On 27.08.12 09:32:13, wei.y...@windriver.com wrote:

From: Wei Yang

Upon enabling the call-graph functionality of oprofile, A few minutes
later the following calltrace will always occur.

BUG: unable to handle kernel paging request at 656d6153
IP: [] print_context_stack+0x55/0x110
*pde = 
Oops:  [#1] PREEMPT SMP
Modules linked in:
Pid: 0, comm: swapper/0 Not tainted 3.6.0-rc3-WR5.0+snapshot-20120820_standard
EIP: 0060:[] EFLAGS: 00010093 CPU: 0
EIP is at print_context_stack+0x55/0x110
EAX: 656d7ffc EBX: 656d6153 ECX: c1837ee0 EDX: 656d6153
ESI:  EDI: e000 EBP: f600deac ESP: f600de88
DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
CR0: 8005003b CR2: 656d6153 CR3: 01934000 CR4: 07d0
DR0:  DR1:  DR2:  DR3: 
DR6: 0ff0 DR7: 0400
Process swapper/0 (pid: 0, ti=f600c000 task=c18411a0 task.ti=c1836000)
Stack:
1a7f76ea 656d7ffc 656d6000 c1837ee0 e000 c1837ee0 656d6153 c188e27c
656d6000 f600dedc c10040f8 c188e27c f600def0  f600dec8 c1837ee0
 f600ded4 c1837ee0 f600dfc4 001f f600df08 c1564d22 
Call Trace:
[] dump_trace+0x68/0xf0
[] x86_backtrace+0xb2/0xc0
[] oprofile_add_sample+0xa2/0xc0
[] ? do_softirq+0x6f/0xa0
[] ppro_check_ctrs+0x79/0x100
[] ? ppro_shutdown+0x60/0x60
[] profile_exceptions_notify+0x8f/0xb0
[] nmi_handle.isra.0+0x48/0x70
[] do_nmi+0xd3/0x3c0
[] ? __local_bh_enable+0x29/0x70
[] ? ftrace_define_fields_irq_handler_entry+0x80/0x80
[] nmi_stack_correct+0x28/0x2d
[] ? ftrace_define_fields_irq_handler_entry+0x80/0x80
[] ? do_softirq+0x6f/0xa0

[] irq_exit+0x65/0x70
[] smp_apic_timer_interrupt+0x59/0x89
[] apic_timer_interrupt+0x2a/0x30
[] ? acpi_idle_enter_bm+0x245/0x273
[] cpuidle_enter+0x15/0x20
[] cpuidle_idle_call+0xa0/0x320
[] cpu_idle+0x55/0xb0
[] rest_init+0x6c/0x74
[] start_kernel+0x2ec/0x2f3
[] ? repair_env_string+0x51/0x51
[] i386_start_kernel+0x78/0x7d
Code: e0 ff ff 89 7d ec 74 5a 8d b4 26 00 00 00 00 8d bc 27 00 00
00 00 39 f3 72 0c 8b 45 f0 8d 64 24 18 5b 5e 5f 5d c3 3b 5d ec 72
ef<8b>  3b 89 f8 89 7d dc e8 ef 40 04 00 85 c0 74 20 8b 40
EIP: [] print_context_stack+0x55/0x110 SS:ESP 0068:f600de88
CR2: 656d6153
---[ end trace 751c9b47c6ff5e29 ]---

Let's assume a scenario that do_softirq() switches the stack to a soft irq
stack, and the soft irq stack is totally empty. At this moment, a nmi interrupt
occurs, subsequently, CPU does not automatically save SS and SP registers
and switch any stack, but instead only stores EFLAGS, CS and IP to the soft irq
stack. since the CPU is in kernel mode when the NMI exception occurs.
the layout of the current soft irq stack is this:

   +--+<-the top of soft irq
   |   EFLAGS |
   +--+
   |CS|
   +--+
   |IP|
   +--+
   |   SAVE_ALL   |
   +--+

but the return value of the function kernel_stack_pointer() is'>sp'
(for x86_32 CPU), which is invoked by the x86_backtrace function. Since
the type of regs pointer is a pt_regs structure, the return value is not
in the range of the soft irq stack, as the SP register is not save in the
soft irq stack. Therefore, we need to check if the return value of the function
resides in valid range. Additionally, the changes has no impact on the normal
NMI exception.

Signed-off-by: Yang Wei
---
  arch/x86/oprofile/backtrace.c |   10 ++
  1 files changed, 10 insertions(+), 0 deletions(-)

diff --git a/arch/x86/oprofile/backtrace.c b/arch/x86/oprofile/backtrace.c
index d6aa6e8..a5fca0b 100644
--- a/arch/x86/oprofile/backtrace.c
+++ b/arch/x86/oprofile/backtrace.c
@@ -17,6 +17,11 @@
  #include
  #include

+static inline int valid_stack_ptr(struct thread_info *tinfo, void *p)
+{
+   void *t = tinfo;
+   return p>  t + sizeof(struct thread_info)&&  p<  t + THREAD_SIZE;
+}
  static int backtrace_stack(void *data, char *name)
  {
/* Yes, we want all stacks */
@@ -110,9 +115,14 @@ void
  x86_backtrace(struct pt_regs * const regs, unsigned int depth)
  {
struct stack_frame *head = (struct stack_frame *)frame_pointer(regs);
+   struct thread_info *context;

if (!user_mode_vm(regs)) {
unsigned long stack = kernel_stack_pointer(regs);
+   context = (struct thread_info *)
+   (stack&  (~(THREAD_SIZE - 1)));

You derive the context from a potential wrong stack here.


+   if (!valid_stack_ptr(context, (void *)stack))

Thus, you basically test this:

if (t&  (THREAD_SIZE - 1)<  sizeof(struct thread_info))
...


+   return;
if (depth)
dump_trace(NULL, regs, (unsigned long *)stack, 0,
_ops,);
--
1.7.0.2



Though this patch prevents access to an invalid stack (NULL pointer
access or page fault), I don't think this is the proper fix since it
does not fix the 

[PATCH v6] uartclk value from serial_core exposed to sysfs

[Tomas Hlavacek]

Added file /sys/devices/.../tty/ttySX/uartclk to allow reading
uartclk value in struct uart_port in serial_core via sysfs.

tty_register_device() has been generalized and refactored in order
to add support for setting drvdata and attribute_group to the device.

Signed-off-by: Tomas Hlavacek 
---
 Documentation/ABI/testing/sysfs-tty |9 +
 drivers/tty/serial/serial_core.c|   34 -
 drivers/tty/tty_io.c|   69 ++-
 include/linux/tty.h |4 ++
 4 files changed, 104 insertions(+), 12 deletions(-)

diff --git a/Documentation/ABI/testing/sysfs-tty 
b/Documentation/ABI/testing/sysfs-tty
index b138b66..0c43015 100644
--- a/Documentation/ABI/testing/sysfs-tty
+++ b/Documentation/ABI/testing/sysfs-tty
@@ -17,3 +17,12 @@ Description:
 device, like 'tty1'.
 The file supports poll() to detect virtual
 console switches.
+
+What:  /sys/class/tty/ttyS0/uartclk
+Date:  Sep 2012
+Contact:   Tomas Hlavacek 
+Description:
+Shows the current uartclk value associated with the
+UART port in serial_core, that is bound to TTY like ttyS0.
+uartclk = 16 * baud_base
+
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 137b25c..5d212f8 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -2309,6 +2309,36 @@ struct tty_driver *uart_console_device(struct console 
*co, int *index)
return p->tty_driver;
 }
 
+static ssize_t uart_get_attr_uartclk(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   int ret;
+
+   struct tty_port *port = dev_get_drvdata(dev);
+   struct uart_state *state = container_of(port, struct uart_state, port);
+   mutex_lock(>port.mutex);
+   ret = snprintf(buf, PAGE_SIZE, "%d\n", state->uart_port->uartclk);
+   mutex_unlock(>port.mutex);
+
+   return ret;
+}
+
+static DEVICE_ATTR(uartclk, S_IRUSR | S_IRGRP, uart_get_attr_uartclk, NULL);
+
+static struct attribute *tty_dev_attrs[] = {
+   _attr_uartclk.attr,
+   NULL,
+   };
+
+static struct attribute_group tty_dev_attr_group = {
+   .attrs = tty_dev_attrs,
+   };
+
+static const struct attribute_group *tty_dev_attr_groups[] = {
+   _dev_attr_group,
+   NULL
+   };
+
 /**
  * uart_add_one_port - attach a driver-defined port structure
  * @drv: pointer to the uart low level driver structure for this port
@@ -2362,8 +2392,8 @@ int uart_add_one_port(struct uart_driver *drv, struct 
uart_port *uport)
 * Register the port whether it's detected or not.  This allows
 * setserial to be used to alter this ports parameters.
 */
-   tty_dev = tty_port_register_device(port, drv->tty_driver, uport->line,
-   uport->dev);
+   tty_dev = tty_register_device_attr(drv->tty_driver, uport->line,
+   uport->dev, port, tty_dev_attr_groups);
if (likely(!IS_ERR(tty_dev))) {
device_set_wakeup_capable(tty_dev, 1);
} else {
diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c
index d3bf91a..dcb30d5 100644
--- a/drivers/tty/tty_io.c
+++ b/drivers/tty/tty_io.c
@@ -3041,9 +3041,39 @@ static int tty_cdev_add(struct tty_driver *driver, dev_t 
dev,
 struct device *tty_register_device(struct tty_driver *driver, unsigned index,
   struct device *device)
 {
-   struct device *ret;
+   return tty_register_device_attr(driver, index, device, NULL, NULL);
+}
+EXPORT_SYMBOL(tty_register_device);
+
+/**
+ * tty_register_device_attr - register a tty device
+ * @driver: the tty driver that describes the tty device
+ * @index: the index in the tty driver for this tty device
+ * @device: a struct device that is associated with this tty device.
+ * This field is optional, if there is no known struct device
+ * for this tty device it can be set to NULL safely.
+ * @drvdata: Driver data to be set to device.
+ * @attr_grp: Attribute group to be set on device.
+ *
+ * Returns a pointer to the struct device for this tty device
+ * (or ERR_PTR(-EFOO) on error).
+ *
+ * This call is required to be made to register an individual tty device
+ * if the tty driver's flags have the TTY_DRIVER_DYNAMIC_DEV bit set.  If
+ * that bit is not set, this function should not be called by a tty
+ * driver.
+ *
+ * Locking: ??
+ */
+struct device *tty_register_device_attr(struct tty_driver *driver,
+  unsigned index, struct device *device,
+  void *drvdata,
+  const struct attribute_group **attr_grp)
+{
char name[64];
-   dev_t dev = MKDEV(driver->major, driver->minor_start) + index;
+   dev_t devt = MKDEV(driver->major, 

Re: [PATCH 02/11 V5] workqueue: async idle rebinding

[Lai Jiangshan]

On 09/06/2012 02:06 AM, Tejun Heo wrote:
> Hello, Lai.
> 
> Ooh, I like the approach.  That said, I think it's a bit too invasive
> for 3.6-fixes.  I'll merge the two patches I posted yesterday in
> 3.6-fixes.  Let's do this restructuring in for-3.7.

OK for me.
it is too complicated for 3.6.

> 
> On Wed, Sep 05, 2012 at 06:37:39PM +0800, Lai Jiangshan wrote:
>>  static void idle_worker_rebind(struct worker *worker)
>>  {
>>  struct global_cwq *gcwq = worker->pool->gcwq;
>>  
>> -/* CPU must be online at this point */
>> -WARN_ON(!worker_maybe_bind_and_lock(worker));
>> -if (!--worker->idle_rebind->cnt)
>> -complete(>idle_rebind->done);
>> -spin_unlock_irq(>pool->gcwq->lock);
>> +if (worker_maybe_bind_and_lock(worker))
>> +worker_clr_flags(worker, WORKER_UNBOUND);
>>  
>> -/* we did our part, wait for rebind_workers() to finish up */
>> -wait_event(gcwq->rebind_hold, !(worker->flags & WORKER_REBIND));
>> +worker_clr_flags(worker, WORKER_REBIND);
>> +list_add(>entry, >pool->idle_list);
>> +spin_unlock_irq(>lock);
> 
> This looks correct to me but it's still a bit scary.  Some comments
> explaining why the above is correct would be nice.

How to explain the correct, could you give some clues.
correctness for rebinding and the flags: comments is missing. (old code miss it 
too, so I forgot it)
correctness for idle management: list_del_init() and list_add(), I don't like 
to add comment for slef-explain-code.
correctness for quick-enabled-CMWQ, local-wake-up: comments is in the 
changelog. (I should also add it to the code)
correctness for integrating of above: ..

> 
> Yeah, other than that, looks good to me.  I'll prepare new for-3.7
> branch this can be based on, so please wait a bit.  Also, I think I'll
> probably update commit description / comments while committing.
> 

I was coding it based on wq/for-3.7. so you can merge it easier.
waiting for you merged-result.

Thanks.
Lai

--
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] perf: clean target should do clean for lib/traceevent too

[Namhyung Kim]

On Wed,  5 Sep 2012 18:53:36 -0600, David Ahern wrote:
> It's built as part of perf, so it should be cleaned too.
>
> Signed-off-by: David Ahern 
> Cc: Steven Rostedt 

Tested-by: Namhyung Kim 

Thanks,
Namhyung


> ---
>  tools/perf/Makefile |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/tools/perf/Makefile b/tools/perf/Makefile
> index 90d8e09..e7e62b2 100644
> --- a/tools/perf/Makefile
> +++ b/tools/perf/Makefile
> @@ -921,6 +921,9 @@ $(LIB_FILE): $(LIB_OBJS)
>  $(LIBTRACEEVENT):
>   $(QUIET_SUBDIR0)$(TRACE_EVENT_DIR) $(QUIET_SUBDIR1) O=$(OUTPUT) 
> libtraceevent.a
>  
> +$(LIBTRACEEVENT)-clean:
> + $(QUIET_SUBDIR0)$(TRACE_EVENT_DIR) $(QUIET_SUBDIR1) O=$(OUTPUT) clean
> +
>  help:
>   @echo 'Perf make targets:'
>   @echo '  doc- make *all* documentation (see below)'
> @@ -1060,7 +1063,7 @@ quick-install-html:
>  
>  ### Cleaning rules
>  
> -clean:
> +clean: $(LIBTRACEEVENT)-clean
>   $(RM) $(LIB_OBJS) $(BUILTIN_OBJS) $(LIB_FILE) $(OUTPUT)perf-archive 
> $(OUTPUT)perf.o $(LANG_BINDINGS)
>   $(RM) $(ALL_PROGRAMS) perf
>   $(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo $(OUTPUT)common-cmds.h TAGS 
> tags cscope*
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [PATCH] USB/host: Cleanup unneccessary irq disable code

[Liu, Chuansheng]

> > From: liu chuansheng 
> > Subject: [PATCH] USB/host: Cleanup unneccessary irq disable code
> 
> Why is this in the patch?
> 
> Please resend it in a format that I do not have to manually edit the patch.
> 
> greg k-h
Thanks your teaching, resend again.


Because the IRQF_DISABLED as the flag is now a NOOP and has been
deprecated and in hardirq context the interrupt is disabled.

so in usb/host code:
Removing the usage of flag IRQF_DISABLED;
Removing the calling local_irq save/restore actions in irq
handler usb_hcd_irq();

Signed-off-by: liu chuansheng 
---
 drivers/usb/core/hcd.c   |   15 ---
 drivers/usb/host/ehci-ls1x.c |2 +-
 drivers/usb/host/ohci-xls.c  |2 +-
 3 files changed, 2 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index bc84106..f84ddea 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2153,15 +2153,8 @@ EXPORT_SYMBOL_GPL(usb_bus_start_enum);
 irqreturn_t usb_hcd_irq (int irq, void *__hcd)
 {
struct usb_hcd  *hcd = __hcd;
-   unsigned long   flags;
irqreturn_t rc;
 
-   /* IRQF_DISABLED doesn't work correctly with shared IRQs
-* when the first handler doesn't use it.  So let's just
-* assume it's never used.
-*/
-   local_irq_save(flags);
-
if (unlikely(HCD_DEAD(hcd) || !HCD_HW_ACCESSIBLE(hcd)))
rc = IRQ_NONE;
else if (hcd->driver->irq(hcd) == IRQ_NONE)
@@ -2169,7 +2162,6 @@ irqreturn_t usb_hcd_irq (int irq, void *__hcd)
else
rc = IRQ_HANDLED;
 
-   local_irq_restore(flags);
return rc;
 }
 EXPORT_SYMBOL_GPL(usb_hcd_irq);
@@ -2358,13 +2350,6 @@ static int usb_hcd_request_irqs(struct usb_hcd *hcd,
 
if (hcd->driver->irq) {
 
-   /* IRQF_DISABLED doesn't work as advertised when used together
-* with IRQF_SHARED. As usb_hcd_irq() will always disable
-* interrupts we can remove it here.
-*/
-   if (irqflags & IRQF_SHARED)
-   irqflags &= ~IRQF_DISABLED;
-
snprintf(hcd->irq_descr, sizeof(hcd->irq_descr), "%s:usb%d",
hcd->driver->description, hcd->self.busnum);
retval = request_irq(irqnum, _hcd_irq, irqflags,
diff --git a/drivers/usb/host/ehci-ls1x.c b/drivers/usb/host/ehci-ls1x.c
index a283e59..425cb4a 100644
--- a/drivers/usb/host/ehci-ls1x.c
+++ b/drivers/usb/host/ehci-ls1x.c
@@ -119,7 +119,7 @@ static int ehci_hcd_ls1x_probe(struct platform_device *pdev)
goto err_release_region;
}
 
-   ret = usb_add_hcd(hcd, irq, IRQF_DISABLED | IRQF_SHARED);
+   ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto err_iounmap;
 
diff --git a/drivers/usb/host/ohci-xls.c b/drivers/usb/host/ohci-xls.c
index 41e378f..84201cd 100644
--- a/drivers/usb/host/ohci-xls.c
+++ b/drivers/usb/host/ohci-xls.c
@@ -56,7 +56,7 @@ static int ohci_xls_probe_internal(const struct hc_driver 
*driver,
goto err3;
}
 
-   retval = usb_add_hcd(hcd, irq, IRQF_DISABLED | IRQF_SHARED);
+   retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (retval != 0)
goto err4;
return retval;
-- 
1.7.0.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: 3.5-rc7: nouveau doesn't X on NVC0

[Linus Torvalds]

[ This got dropped somehow - it's in my draft folder. The bisection
may be irrelevant now: does it work with current git, since we've had
some nouveau changes? ]

On Tue, Aug 28, 2012 at 8:26 AM, Alexey Dobriyan  wrote:
> Ping!
>
> No X for me with 3.6-rc2.

Can you possibly bisect it, at least partially? Just knowing exactly
where it started might help the nouveau developers,

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

Re: [PATCH] USB/host: Cleanup unneccessary irq disable code

[gre...@linuxfoundation.org]

On Thu, Sep 06, 2012 at 12:39:09AM +, Liu, Chuansheng wrote:
> > This patch is corrupted and can not be applied at all.  Please fix your 
> > email
> > client and try again.
> > 
> > greg k-h
> 
> I am very sorry to waste your time, resend it again.
> 
> From: liu chuansheng 
> Subject: [PATCH] USB/host: Cleanup unneccessary irq disable code

Why is this in the patch?

Please resend it in a format that I do not have to manually edit the
patch.

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

Re: [PATCH 05/11 V5] workqueue: Add @bind arguement back without change any thing

[Lai Jiangshan]

On 09/06/2012 03:49 AM, Tejun Heo wrote:
> Hello,
> 
> On Wed, Sep 05, 2012 at 06:37:42PM +0800, Lai Jiangshan wrote:
>> Ensure the gcwq->flags is only accessed with gcwq->lock held.
>> And make the code more easier to understand.
>>
>> In all current callsite of create_worker(), DISASSOCIATED can't
>> be flipped while create_worker().
>> So the whole behavior is unchanged with this patch.
> 
> This doesn't change anything.  You're just moving the test to the
> caller with comments there explaining how it won't change even if
> gcwq->lock is released.  It seems more confusing to me.  The flag is
> still protected by manager_mutex.  How is this an improvement?
> 

Some other bit of gcwq->flags is accessed(modified) without manager_mutex.
making gcwq->flags be accessed only form gcwq->lock C.S. will help the reviewer.

I don't like adding special things/code when not-absolutely-required.

--
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 1/1] uartclk value from serial_core exposed to sysfs

[Tomas Hlavacek]

Hello Greg,

On Thu, Sep 6, 2012 at 1:42 AM, Greg KH  wrote:
> On Thu, Sep 06, 2012 at 01:16:56AM +0200, Tomas Hlavacek wrote:
>> Added file /sys/devices/.../tty/ttySX/uartclk to allow reading
>> uartclk value in struct uart_port in serial_core via sysfs.
>>
>> tty_register_device() has been generalized and refactored in order
>> to add support for setting drvdata and attribute_group to the device.
>>
>> Signed-off-by: Tomas Hlavacek 
>> ---
>>  Documentation/ABI/testing/sysfs-tty |9 ++
>>  drivers/tty/serial/serial_core.c|   36 -
>>  drivers/tty/tty_io.c|   59 
>> +--
>>  include/linux/tty.h |4 +++
>>  4 files changed, 104 insertions(+), 4 deletions(-)
>>
>> diff --git a/Documentation/ABI/testing/sysfs-tty 
>> b/Documentation/ABI/testing/sysfs-tty
>> index b138b66..2f10855 100644
>
> Odd, what tree did you make this against?  It doesn't apply at all, even
> if I mess with it to try a --3way merge, it still throws up a ton of
> conflicts.
>
> Care to do it against my tty-next branch in git?

I did it wrong obviously. Sorry. I am resending it (it is going to be
against tty-next branch in
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git, I hope
it is right this time).

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

RE: [Patch 0/1]drm_irq: Introducing the irq_thread support

[Liu, Chuansheng]

> Well, you cant use the pre_install/post_install hooks the drm_irq code 
> provides,
> but yes, just do the request_irq in your driver code at the right time, with 
> the
> right parameters. Much easier than adding code to a part of the drm core
> fraught with backwards-compat stuff no one really wants to touch ... All the
> additional stuff besides calling request_irq and the driver hooks that
> drm_irq_install does is really just to support old dri1 userspace.
> 
Please have a look for the patch, I just added the callback of irq thread 
handler, default is NULL without set,
So it should be no impact with others.

In case irq threadler func is NULL, it equals to request_irq, 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/

[PATCH] perf: clean target should do clean for lib/traceevent too

[David Ahern]

It's built as part of perf, so it should be cleaned too.

Signed-off-by: David Ahern 
Cc: Steven Rostedt 
Cc: Namhyung Kim 
---
 tools/perf/Makefile |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 90d8e09..e7e62b2 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -921,6 +921,9 @@ $(LIB_FILE): $(LIB_OBJS)
 $(LIBTRACEEVENT):
$(QUIET_SUBDIR0)$(TRACE_EVENT_DIR) $(QUIET_SUBDIR1) O=$(OUTPUT) 
libtraceevent.a
 
+$(LIBTRACEEVENT)-clean:
+   $(QUIET_SUBDIR0)$(TRACE_EVENT_DIR) $(QUIET_SUBDIR1) O=$(OUTPUT) clean
+
 help:
@echo 'Perf make targets:'
@echo '  doc- make *all* documentation (see below)'
@@ -1060,7 +1063,7 @@ quick-install-html:
 
 ### Cleaning rules
 
-clean:
+clean: $(LIBTRACEEVENT)-clean
$(RM) $(LIB_OBJS) $(BUILTIN_OBJS) $(LIB_FILE) $(OUTPUT)perf-archive 
$(OUTPUT)perf.o $(LANG_BINDINGS)
$(RM) $(ALL_PROGRAMS) perf
$(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo $(OUTPUT)common-cmds.h TAGS 
tags cscope*
-- 
1.7.10.1

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

Re: [PATCH] perf: clean should remove libtraceevent.a too

[David Ahern]

On 9/5/12 6:42 PM, Steven Rostedt wrote:

On Wed, 2012-09-05 at 18:10 -0600, David Ahern wrote:

It's built as part of perf, so it should be cleaned too.

Signed-off-by: David Ahern 
Cc: Steven Rostedt 
Cc: Namhyung Kim 
---
  tools/perf/Makefile |1 +
  1 file changed, 1 insertion(+)

diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 90d8e09..5f0259e 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -1068,6 +1068,7 @@ clean:
$(RM) $(OUTPUT)PERF-VERSION-FILE $(OUTPUT)PERF-CFLAGS
$(RM) $(OUTPUT)util/*-bison*
$(RM) $(OUTPUT)util/*-flex*
+   $(RM) $(LIBTRACEEVENT)
$(python-clean)


Actually, this should do the clean in the tools/lib/traceevent
directory, as this change wont clean the objects created.

-- Steve




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

RE: [Patch 0/1]drm_irq: Introducing the irq_thread support

[Liu, Chuansheng]

> For a kms drm driver (and tbh, doing a non-kms driver today is not a great 
> idea),
> there's no reason to use the drm_irq_install/_unistall helpers.
> 
Can not understand well, I found many GPU drivers are using drm_irq helpers' 
function, including ours:)

--
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 -next] soc: fix wm0010.c printk format warning

[Mark Brown]

On Wed, Sep 05, 2012 at 05:11:08PM -0700, Randy Dunlap wrote:
> On 09/05/2012 05:06 PM, Mark Brown wrote:

> > Somone already sent this.  As ever please try to use subject lines
> > appropriate for the subsystem.  Please also consider who you're CCing -

> Unfortunately the MAINTAINERS file does not tell me what to include
> in the $subject line for the subsystem.
> What would you like to see there, please?  Maybe ASoC?

As with every other subsystem in the kernel look at the log for the
thing your changing and do something that visually resembles it.  If you
want get_maintainers to do this for you you'll need to write the code
(or convince someone else to do it).

> > there's no need to copy -next on things like this which aren't

> I have always done a reply-to-all for linux-next patches, so after
> a few years someone days Don't Do That (IYO).

I'm pretty sure I've mentioned this before...  actually, if you're
relying on get_maintainers that's probably some of the false positives
too.  If you've found an issue related to the -next integration that's
one thing but if you've just noticed a random thing in the kernel that
could be improved that's not really something about -next.
--
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] perf: clean should remove libtraceevent.a too

[Steven Rostedt]

On Wed, 2012-09-05 at 18:10 -0600, David Ahern wrote:
> It's built as part of perf, so it should be cleaned too.
> 
> Signed-off-by: David Ahern 
> Cc: Steven Rostedt 
> Cc: Namhyung Kim 
> ---
>  tools/perf/Makefile |1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/tools/perf/Makefile b/tools/perf/Makefile
> index 90d8e09..5f0259e 100644
> --- a/tools/perf/Makefile
> +++ b/tools/perf/Makefile
> @@ -1068,6 +1068,7 @@ clean:
>   $(RM) $(OUTPUT)PERF-VERSION-FILE $(OUTPUT)PERF-CFLAGS
>   $(RM) $(OUTPUT)util/*-bison*
>   $(RM) $(OUTPUT)util/*-flex*
> + $(RM) $(LIBTRACEEVENT)
>   $(python-clean)

Actually, this should do the clean in the tools/lib/traceevent
directory, as this change wont clean the objects created.

-- Steve


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

RE: [Patch 0/1]drm_irq: Introducing the irq_thread support

[Liu, Chuansheng]

> This possibly ought to be submitted in parallel with the code that uses it so 
> that
> the whole proposal can be evaluated as one thing ?
> 
> Alan

Patch is here, thanks.

From: liu chuansheng 
Subject: [PATCH] drm_irq: Introducing the irq_thread support

For some GPUs, the irq handler need >1ms to handle the irq action.
And it will delay the whole system irq handler.

This patch is adding the irq thread support, it will make the drm_irq
interface more flexible.

The changes include:
1/ Change the request_irq to request_thread_irq, and add new callback
   irq_handler_t;
2/ Normally we need IRQF_ONESHOT flag support for irq thread, so add
   this option in drm_irq;

Cc: Shi Yang 
Signed-off-by: liu chuansheng 
---
 drivers/gpu/drm/drm_irq.c |8 ++--
 include/drm/drmP.h|2 ++
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 03f16f3..bc105fe 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -345,13 +345,17 @@ int drm_irq_install(struct drm_device *dev)
if (drm_core_check_feature(dev, DRIVER_IRQ_SHARED))
sh_flags = IRQF_SHARED;
 
+   if (drm_core_check_feature(dev, DRIVER_IRQ_ONESHOT))
+   sh_flags |= IRQF_ONESHOT;
+
if (dev->devname)
irqname = dev->devname;
else
irqname = dev->driver->name;
 
-   ret = request_irq(drm_dev_to_irq(dev), dev->driver->irq_handler,
- sh_flags, irqname, dev);
+   ret = request_threaded_irq(drm_dev_to_irq(dev),
+   dev->driver->irq_handler, dev->driver->irq_handler_t,
+   sh_flags, irqname, dev);
 
if (ret < 0) {
mutex_lock(>struct_mutex);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index d6b67bb..b28be4b 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -152,6 +152,7 @@ int drm_err(const char *func, const char *format, ...);
 #define DRIVER_GEM 0x1000
 #define DRIVER_MODESET 0x2000
 #define DRIVER_PRIME   0x4000
+#define DRIVER_IRQ_ONESHOT 0x8000
 
 #define DRIVER_BUS_PCI 0x1
 #define DRIVER_BUS_PLATFORM 0x2
@@ -872,6 +873,7 @@ struct drm_driver {
/* these have to be filled in */
 
irqreturn_t(*irq_handler) (DRM_IRQ_ARGS);
+   irqreturn_t(*irq_handler_t) (DRM_IRQ_ARGS);
void (*irq_preinstall) (struct drm_device *dev);
int (*irq_postinstall) (struct drm_device *dev);
void (*irq_uninstall) (struct drm_device *dev);
-- 
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.6 0/3] Fix use-after-free in PSCSI

[Nicholas A. Bellinger]

On Wed, 2012-09-05 at 17:09 +0200, Paolo Bonzini wrote:
> Hi,
> 
> this series fixes the bug I reported with wrong sense data.  The
> memory corruption is caused by using the sense data after freeing
> it.  The series corrects it by moving the copy of the sense data
> earlier, to the transport_complete callback.
> 
> Please review and be kind on my first lio patches! :)
> 
> Paolo
> 
> Paolo Bonzini (3):
>   target: move transport_get_sense_data
>   target: simplify code around transport_get_sense_data
>   target: fix use-after-free with PSCSI sense data
> 
>  drivers/target/target_core_pscsi.c |   21 ++
>  drivers/target/target_core_transport.c |  117 
> 
>  include/target/target_core_backend.h   |4 +-
>  3 files changed, 53 insertions(+), 89 deletions(-)
> 

The approach to squash the bug looks easonable to me, and nice work on
the extra cleanups for backend sense w/ TRANSPORT_PLUGIN_PHBA_PDEV !

I've applied this to target-pending/master w/ CC stable, and will plan
to send out the PULL request for -rc5 over the next days.

Nice work Paolo!

--nab

--
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: PCI/e1000 BUG: unable to handle kernel paging request at 0ffff163

[Fengguang Wu]

On Wed, Sep 05, 2012 at 11:41:04AM -0700, Yinghai Lu wrote:
> On Tue, Sep 4, 2012 at 11:51 PM, Fengguang Wu  wrote:
> > Yinghai,
> >
> > There are many kernel paging errors showing up in tree:
> >
> >   git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git 
> > for-pci-for-each-res-addon-v2
> >
> > The below summary shows that
> >
> > 1) it's a reliably reproducible bug
> > 2) all paging fault happens at address 0163 and in some e1000 functions
> >
> > I'll try to bisect if the root cause is not obvious to you.  (Cannot
> > do so for now because there are 3 bisections on the way and I cannot
> > afford more..)
> 
> thanks, will check that...
> 
> the 32bit kernel as kvm gust, and host is doing pci passthrough to
> export the VF to the KVM guest?

No I didn't do anything special for PCI passthrough. I just used KVM's
emulated e1000 device.

btw, I'll be able to start bisection after several hours.

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

RE: [PATCH] USB/host: Cleanup unneccessary irq disable code

[Liu, Chuansheng]

> This patch is corrupted and can not be applied at all.  Please fix your email
> client and try again.
> 
> greg k-h

I am very sorry to waste your time, resend it again.

From: liu chuansheng 
Subject: [PATCH] USB/host: Cleanup unneccessary irq disable code

Because the IRQF_DISABLED as the flag is now a NOOP and has been
deprecated and in hardirq context the interrupt is disabled.

so in usb/host code:
Removing the usage of flag IRQF_DISABLED;
Removing the calling local_irq save/restore actions in irq
handler usb_hcd_irq();

Signed-off-by: liu chuansheng 
---
 drivers/usb/core/hcd.c   |   15 ---
 drivers/usb/host/ehci-ls1x.c |2 +-
 drivers/usb/host/ohci-xls.c  |2 +-
 3 files changed, 2 insertions(+), 17 deletions(-)

diff --git a/drivers/usb/core/hcd.c b/drivers/usb/core/hcd.c
index bc84106..f84ddea 100644
--- a/drivers/usb/core/hcd.c
+++ b/drivers/usb/core/hcd.c
@@ -2153,15 +2153,8 @@ EXPORT_SYMBOL_GPL(usb_bus_start_enum);
 irqreturn_t usb_hcd_irq (int irq, void *__hcd)
 {
struct usb_hcd  *hcd = __hcd;
-   unsigned long   flags;
irqreturn_t rc;
 
-   /* IRQF_DISABLED doesn't work correctly with shared IRQs
-* when the first handler doesn't use it.  So let's just
-* assume it's never used.
-*/
-   local_irq_save(flags);
-
if (unlikely(HCD_DEAD(hcd) || !HCD_HW_ACCESSIBLE(hcd)))
rc = IRQ_NONE;
else if (hcd->driver->irq(hcd) == IRQ_NONE)
@@ -2169,7 +2162,6 @@ irqreturn_t usb_hcd_irq (int irq, void *__hcd)
else
rc = IRQ_HANDLED;
 
-   local_irq_restore(flags);
return rc;
 }
 EXPORT_SYMBOL_GPL(usb_hcd_irq);
@@ -2358,13 +2350,6 @@ static int usb_hcd_request_irqs(struct usb_hcd *hcd,
 
if (hcd->driver->irq) {
 
-   /* IRQF_DISABLED doesn't work as advertised when used together
-* with IRQF_SHARED. As usb_hcd_irq() will always disable
-* interrupts we can remove it here.
-*/
-   if (irqflags & IRQF_SHARED)
-   irqflags &= ~IRQF_DISABLED;
-
snprintf(hcd->irq_descr, sizeof(hcd->irq_descr), "%s:usb%d",
hcd->driver->description, hcd->self.busnum);
retval = request_irq(irqnum, _hcd_irq, irqflags,
diff --git a/drivers/usb/host/ehci-ls1x.c b/drivers/usb/host/ehci-ls1x.c
index a283e59..425cb4a 100644
--- a/drivers/usb/host/ehci-ls1x.c
+++ b/drivers/usb/host/ehci-ls1x.c
@@ -119,7 +119,7 @@ static int ehci_hcd_ls1x_probe(struct platform_device *pdev)
goto err_release_region;
}
 
-   ret = usb_add_hcd(hcd, irq, IRQF_DISABLED | IRQF_SHARED);
+   ret = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (ret)
goto err_iounmap;
 
diff --git a/drivers/usb/host/ohci-xls.c b/drivers/usb/host/ohci-xls.c
index 41e378f..84201cd 100644
--- a/drivers/usb/host/ohci-xls.c
+++ b/drivers/usb/host/ohci-xls.c
@@ -56,7 +56,7 @@ static int ohci_xls_probe_internal(const struct hc_driver 
*driver,
goto err3;
}
 
-   retval = usb_add_hcd(hcd, irq, IRQF_DISABLED | IRQF_SHARED);
+   retval = usb_add_hcd(hcd, irq, IRQF_SHARED);
if (retval != 0)
goto err4;
return retval;
-- 
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] pch_uart: Add eg20t_port lock field, avoid recursive spinlocks

[Darren Hart]

On 09/05/2012 05:25 PM, Darren Hart wrote:
> 
> 
> On 09/05/2012 05:18 PM, Greg Kroah-Hartman wrote:
>> On Wed, Sep 05, 2012 at 05:14:48PM -0700, Greg Kroah-Hartman wrote:
>>> On Wed, Sep 05, 2012 at 05:04:07PM -0700, Darren Hart wrote:
 The following patch has been included in linux-next
 (fe89def79c48e2149abdd1e816523e69a9067191) but has not yet landed in 
 mainline
 nor been queued for stable so far as I can determine. This patch addresses 
 a
 deadlock in mainline and is a prerequisite for an additional fix required 
 by the
 PREEMPT_RT kernel. Can we get this pulled into 3.4.11 please?
>>>
>>> 3.4.11?  It has to hit Linus's tree first.
>>>
 Perhaps I am
 jumping the gun, but this patch was originally pulled on June 19, 2012.
>>>
>>> Remember, we missed a pull cycle for tty due to other problems, I
>>> thought I picked all of the different pieces needed for 3.6, but I must
>>> of missed this one.
>>
>> Nope, it made it, it is commit 2588aba002d14e938c2f56d299ecf3e7ce1302a5.
> 
> Doh, I pulled master and stable, but only checked stable. Sigh. My
> apologies Greg.
> 
>>
>> Now, do you want that patch in the -stable releases?  If so, how far
>> back? :)
> 
> Yes, back to 3.0 would be ideal. It needs mangling for 3.2 and back
> though. I will send patches for 3.4, 3.2 and possibly 3.0 following the
> stable_kernel_rules.txt procedure.

On second thought, there are way too many changes to pch_uart that are
required before this patch can really be applied prior to 3.4. I suspect
these are not all appropriate for -stable. I'd be happy just getting
this into 3.4.11. 2588aba002d14e938c2f56d299ecf3e7ce1302a5 cherry-picks
cleanly to 3.4.

Thanks,

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
--
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] checkpatch: Suggest using min_t or max_t

[Joe Perches]

On Thu, 2012-09-06 at 02:16 +0200, Philippe De Muyter wrote:
> On Wed, Sep 5, 2012 at 7:07 PM, Joe Perches  wrote:
> > On Wed, 2012-09-05 at 13:21 +0200, Philippe De Muyter wrote:
> >> > v2: Make $match_balanced_parentheses work in perl 5.8
> >>
> >> Has this been applied  ?
> >>
> >> v3.3 version of checkpatch.pl works for me, but v3.4, v3.5 & v3.6rc2 say:
> >> Nested quantifiers in regex; marked by <-- HERE in m/(\((?:[^\(\)]++
> >> <-- HERE |(?-1))*\))/ at scripts/checkpatch.pl line 340.
> >>
> >> and my perl is :
> >>
> >> perl --version
> >>
> >> This is perl, v5.8.8 built for i586-linux-thread-multi
> >
> > The current version of checkpatch skips this
> > check when the perl version is less than 5.10.0
> >
> >
> > commit d7c76ba7e58bc3ca674f20759c686535db484749
> > Author: Joe Perches 
> > Date:   Tue Jan 10 15:09:58 2012 -0800
> >
> > checkpatch: improve memset and min/max with cast checking
> >
> > Improve the checking of arguments to memset and min/max tests.
> >
> > Move the checking of min/max to statement blocks instead of single line.
> > Change $Constant to allow any case type 0x initiator and trailing ul
> > specifier.  Add $FuncArg type as any function argument with or without a
> > cast.  Print the whole statement when showing memset or min/max 
> > messages.
> > Improve the memset with 0 as 3rd argument error message.
> >
> > There are still weaknesses in the $FuncArg and $Constant code as 
> > arbitrary
> > parentheses and negative signs are not generically supported.
> >
> > []
> > # Using $balanced_parens, $LvalOrFunc, or $FuncArg
> > # requires at least perl version v5.10.0
> > # Any use must be runtime checked with $^V
> > []
> > # typecasts on min/max could be min_t/max_t
> > if ($^V && $^V ge 5.10.0 &&
> > defined $stat &&
> > $stat =~ 
> > /^\+(?:.*?)\b(min|max)\s*\(\s*$FuncArg\s*,\s*$FuncArg\s*\)/) {
> >
> >
> 
> I know nothing about perl, and when I read 3.6rc2's checkpatch.pl it
> seems to me that every usage of  $balanced_parens, $LvalOrFunc, or
> $FuncArg is protected by a test for v5.10.0, but line 340, which perl
> complains about, is not a use, but merely a definition.  Should the
> definition not be protected too ?

Beats me.

I'm not a perl monk either.  Maybe it should.
I don't have 5.8 and the latest is 5.16.
5.8 is pretty old.

--
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] pch_uart: Add eg20t_port lock field, avoid recursive spinlocks

[Darren Hart]

On 09/05/2012 05:18 PM, Greg Kroah-Hartman wrote:
> On Wed, Sep 05, 2012 at 05:14:48PM -0700, Greg Kroah-Hartman wrote:
>> On Wed, Sep 05, 2012 at 05:04:07PM -0700, Darren Hart wrote:
>>> The following patch has been included in linux-next
>>> (fe89def79c48e2149abdd1e816523e69a9067191) but has not yet landed in 
>>> mainline
>>> nor been queued for stable so far as I can determine. This patch addresses a
>>> deadlock in mainline and is a prerequisite for an additional fix required 
>>> by the
>>> PREEMPT_RT kernel. Can we get this pulled into 3.4.11 please?
>>
>> 3.4.11?  It has to hit Linus's tree first.
>>
>>> Perhaps I am
>>> jumping the gun, but this patch was originally pulled on June 19, 2012.
>>
>> Remember, we missed a pull cycle for tty due to other problems, I
>> thought I picked all of the different pieces needed for 3.6, but I must
>> of missed this one.
> 
> Nope, it made it, it is commit 2588aba002d14e938c2f56d299ecf3e7ce1302a5.

Doh, I pulled master and stable, but only checked stable. Sigh. My
apologies Greg.

> 
> Now, do you want that patch in the -stable releases?  If so, how far
> back? :)

Yes, back to 3.0 would be ideal. It needs mangling for 3.2 and back
though. I will send patches for 3.4, 3.2 and possibly 3.0 following the
stable_kernel_rules.txt procedure.

> 
> Sorry for the mess,

Looks like it was my mess today :-)

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel
--
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 -next] soc: fix wm0010.c printk format warning

[Sedat Dilek]

On Thu, Sep 6, 2012 at 2:11 AM, Randy Dunlap  wrote:
> On 09/05/2012 05:06 PM, Mark Brown wrote:
>
>> On Wed, Sep 05, 2012 at 04:24:57PM -0700, Randy Dunlap wrote:
>>> From: Randy Dunlap 
>>>
>>> Fix printk format warning:
>>
>> Somone already sent this.  As ever please try to use subject lines
>> appropriate for the subsystem.  Please also consider who you're CCing -
>
>
> Unfortunately the MAINTAINERS file does not tell me what to include
> in the $subject line for the subsystem.
> What would you like to see there, please?  Maybe ASoC?
>

git log --oneline sound/soc/codecs/wm0010.c

Label looks like "ASoC: wm0010:"... (ASoC kills my shift key, I would
like to see all labels lower-case).

>> there's no need to copy -next on things like this which aren't
>
>
> I have always done a reply-to-all for linux-next patches, so after
> a few years someone days Don't Do That (IYO).
>

Then maintainers should check compiler-warnings in their area - regularly?

$ grep warning: v3.6.0-rc4-next20120905-1-iniza-generic/deb-pkg.log |
grep 'sound/soc' | wc -l
10

I agree that breakage and regressions should be dealt with higher
priority... Such patches like this should be welcome, anyway.

>> integration issues for example, if we start doing that then it'd get
>> drowned in noise from all the development.
>
>
> Agreed, many of us are already drowning from 1000+ emails per day.
> (seriously)
>

Spam will one day eliminate Email, it's perverted.

- Sedat -

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