Re: [PATCH v4] mfd: lp87565: Add lp87565 PMIC support

[Keerthy]

On Sunday 11 June 2017 10:36 AM, Keerthy wrote:
> 
> 
> On Friday 09 June 2017 07:58 PM, Rob Herring wrote:
>> On Thu, Jun 08, 2017 at 09:38:14AM +0530, Keerthy wrote:
>>> The LP87565 chip is a power management IC for Portable Navigation Systems
>>> and Tablet Computing devices. It contains the following components:
>>>
>>> - Configurable Bucks(Single and multi-phase).
>>> - Configurable General Purpose Output Signals (GPO).
>>>
>>> The LP87565-Q1 variant device uses two 2-phase outputs configuration,
>>> Buck0 is master for Buck0/1 output and Buck2 is master for Buck2/3
>>> output.
>>>

Lee Jones,

Shall i add back i2c_device_id as pointed here:
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1417316.html

Best Regards,
Keerthy


>>> Signed-off-by: Keerthy 
>>> ---
>>>
>>> The other patches are already pulled by Mark. Hence posting
>>> the remaining patch.
>>>
>>> Changes in v4:
>>>
>>>   * Fixed device tree comments from Rob on the pmic node name.
>>>   * removed regulators from properties list as it is a node.
>>>  
>>> Changes in v3:
>>>
>>>   * Fixed License to GPL v2.
>>>   * Fixed an indentation issue.
>>>
>>> Changes in v2:
>>>
>>>   * Fixed a bunch of whitespace errors.
>>>   * Changed the License to short form.
>>>   * Added the generic compatible lp87565
>>>   * Removed i2c_device_id table.
>>>   * Introduced probe_new function in place of probe.
>>>
>>>  Documentation/devicetree/bindings/mfd/lp87565.txt |  43 
>>
>> Acked-by: Rob Herring 
> 
> Thanks Rob.
> 
>>
>>>  drivers/mfd/Kconfig   |  14 ++
>>>  drivers/mfd/Makefile  |   1 +
>>>  drivers/mfd/lp87565.c |  92 
>>>  include/linux/mfd/lp87565.h   | 270 
>>> ++
>>>  5 files changed, 420 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/mfd/lp87565.txt
>>>  create mode 100644 drivers/mfd/lp87565.c
>>>  create mode 100644 include/linux/mfd/lp87565.h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH v4] mfd: lp87565: Add lp87565 PMIC support

[Keerthy]

On Sunday 11 June 2017 10:36 AM, Keerthy wrote:
> 
> 
> On Friday 09 June 2017 07:58 PM, Rob Herring wrote:
>> On Thu, Jun 08, 2017 at 09:38:14AM +0530, Keerthy wrote:
>>> The LP87565 chip is a power management IC for Portable Navigation Systems
>>> and Tablet Computing devices. It contains the following components:
>>>
>>> - Configurable Bucks(Single and multi-phase).
>>> - Configurable General Purpose Output Signals (GPO).
>>>
>>> The LP87565-Q1 variant device uses two 2-phase outputs configuration,
>>> Buck0 is master for Buck0/1 output and Buck2 is master for Buck2/3
>>> output.
>>>

Lee Jones,

Shall i add back i2c_device_id as pointed here:
http://www.mail-archive.com/linux-kernel@vger.kernel.org/msg1417316.html

Best Regards,
Keerthy


>>> Signed-off-by: Keerthy 
>>> ---
>>>
>>> The other patches are already pulled by Mark. Hence posting
>>> the remaining patch.
>>>
>>> Changes in v4:
>>>
>>>   * Fixed device tree comments from Rob on the pmic node name.
>>>   * removed regulators from properties list as it is a node.
>>>  
>>> Changes in v3:
>>>
>>>   * Fixed License to GPL v2.
>>>   * Fixed an indentation issue.
>>>
>>> Changes in v2:
>>>
>>>   * Fixed a bunch of whitespace errors.
>>>   * Changed the License to short form.
>>>   * Added the generic compatible lp87565
>>>   * Removed i2c_device_id table.
>>>   * Introduced probe_new function in place of probe.
>>>
>>>  Documentation/devicetree/bindings/mfd/lp87565.txt |  43 
>>
>> Acked-by: Rob Herring 
> 
> Thanks Rob.
> 
>>
>>>  drivers/mfd/Kconfig   |  14 ++
>>>  drivers/mfd/Makefile  |   1 +
>>>  drivers/mfd/lp87565.c |  92 
>>>  include/linux/mfd/lp87565.h   | 270 
>>> ++
>>>  5 files changed, 420 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/mfd/lp87565.txt
>>>  create mode 100644 drivers/mfd/lp87565.c
>>>  create mode 100644 include/linux/mfd/lp87565.h
> --
> To unsubscribe from this list: send the line "unsubscribe linux-omap" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [PATCH v2] mfd: tps65217: Introduce dependency on CONFIG_OF

[Keerthy]

On Friday 09 June 2017 05:18 AM, Javier Martinez Canillas wrote:
> On Fri, Jun 9, 2017 at 1:18 AM, Keerthy  wrote:
> 
> [snip]
> 
>>>
>
> -static const struct i2c_device_id tps65217_id_table[] = {
> -   {"tps65217", TPS65217},
> -   { /* sentinel */ }
> -};
> -MODULE_DEVICE_TABLE(i2c, tps65217_id_table);
>>>
>>> Unfortunately you can't get rid of this table (yet) since the I2C
>>> subsystem always reports a MODALIAS of the form "i2c:tps65217" even
>>> when the devices have been registered via OF. There are only a couple
>>> of drivers more to clean-up and then I'll post a patch that fixes the
>>> I2C core to report a proper OF modalias. But for now, removing will
>>> mean that module autoload will be broken for this driver.
>>
>> So this means whole logic of probe_new without i2c_device_id is not
>> ready? I will have to revert all that logic right?
>>
> 
> No, that's not what I meant.
> 
> It's absolutely correct for drivers that can't be build as a module
> (i.e: have a boolean instead of tristate Kconfig symbol) or if you
> want to get rid of the struct i2c_device_id pointed passed to your
> probe callback since isn't used in the driver.
> 
> But it's not enough to get rid of the struct i2c_device_id table for
> the reason I mentioned before.

Thanks for clarifying!

> 
>> Lee Jones,
>>
>> Does that mean even for LP87565 driver we need MODULE_DEVICE_TABLE for
>> module autoload?
>>
> 
> I guess you are talking about [0], right?
> 
> Yes, it's needed because the driver can be built as a module.

Okay.

> 
> [0]: https://lkml.org/lkml/2017/5/19/394
> 
> Best regards,
> Javier
> 

Re: [PATCH v2] mfd: tps65217: Introduce dependency on CONFIG_OF

[Keerthy]

On Friday 09 June 2017 05:18 AM, Javier Martinez Canillas wrote:
> On Fri, Jun 9, 2017 at 1:18 AM, Keerthy  wrote:
> 
> [snip]
> 
>>>
>
> -static const struct i2c_device_id tps65217_id_table[] = {
> -   {"tps65217", TPS65217},
> -   { /* sentinel */ }
> -};
> -MODULE_DEVICE_TABLE(i2c, tps65217_id_table);
>>>
>>> Unfortunately you can't get rid of this table (yet) since the I2C
>>> subsystem always reports a MODALIAS of the form "i2c:tps65217" even
>>> when the devices have been registered via OF. There are only a couple
>>> of drivers more to clean-up and then I'll post a patch that fixes the
>>> I2C core to report a proper OF modalias. But for now, removing will
>>> mean that module autoload will be broken for this driver.
>>
>> So this means whole logic of probe_new without i2c_device_id is not
>> ready? I will have to revert all that logic right?
>>
> 
> No, that's not what I meant.
> 
> It's absolutely correct for drivers that can't be build as a module
> (i.e: have a boolean instead of tristate Kconfig symbol) or if you
> want to get rid of the struct i2c_device_id pointed passed to your
> probe callback since isn't used in the driver.
> 
> But it's not enough to get rid of the struct i2c_device_id table for
> the reason I mentioned before.

Thanks for clarifying!

> 
>> Lee Jones,
>>
>> Does that mean even for LP87565 driver we need MODULE_DEVICE_TABLE for
>> module autoload?
>>
> 
> I guess you are talking about [0], right?
> 
> Yes, it's needed because the driver can be built as a module.

Okay.

> 
> [0]: https://lkml.org/lkml/2017/5/19/394
> 
> Best regards,
> Javier
> 

Re: [PATCH] platform/x86: ideapad-laptop: Expose conservation mode switch

[Hao Wei Tee]

On 5/30/17 10:05 PM, Hao Wei Tee wrote:
> On 5/30/17 9:22 PM, Andy Shevchenko wrote:
>> On Sun, May 28, 2017 at 4:47 PM, Hao Wei Tee  wrote:
>>> On 5/27/17 3:31 PM, Hao Wei Tee wrote:
 This exposes the battery conservation mode present on some (?) IdeaPads.
 The mode is set by calling ACPI method SBMC with argument 3 (on) or
 5 (off). Status is reported in bit 5 of the return value of ACPI method
 GBMD.

 This patch was written based on an IdeaPad U430p. I'm not sure if the ACPI
 methods are the same across all IdeaPads, so it would be great if this got 
 more
 testing across other models before it's merged.
>>>
>>> I got someone to test on an IdeaPad Y510p. It works on that too.
>>
>> Do we have any other option that expose something via sysfs?
>>
> 
> Sorry, not sure what you meant.
> 
> If you meant
> 
>> Do we have any other options than expose something via sysfs?
> 
> I'm not sure, maybe an ioctl? That wouldn't be very convenient though.
> 
> The tp_smapi module (not in mainline) that exposes the battery threshold
> functionality for ThinkPads also uses sysfs.
> 
> If you meant
> 
>> Do we have any other options that expose something via sysfs?
> 
> yes, camera_power, fan_mode, touchpad and conservation_mode.

Any thoughts on this?

-- 
Hao Wei

Re: [PATCH] platform/x86: ideapad-laptop: Expose conservation mode switch

[Hao Wei Tee]

On 5/30/17 10:05 PM, Hao Wei Tee wrote:
> On 5/30/17 9:22 PM, Andy Shevchenko wrote:
>> On Sun, May 28, 2017 at 4:47 PM, Hao Wei Tee  wrote:
>>> On 5/27/17 3:31 PM, Hao Wei Tee wrote:
 This exposes the battery conservation mode present on some (?) IdeaPads.
 The mode is set by calling ACPI method SBMC with argument 3 (on) or
 5 (off). Status is reported in bit 5 of the return value of ACPI method
 GBMD.

 This patch was written based on an IdeaPad U430p. I'm not sure if the ACPI
 methods are the same across all IdeaPads, so it would be great if this got 
 more
 testing across other models before it's merged.
>>>
>>> I got someone to test on an IdeaPad Y510p. It works on that too.
>>
>> Do we have any other option that expose something via sysfs?
>>
> 
> Sorry, not sure what you meant.
> 
> If you meant
> 
>> Do we have any other options than expose something via sysfs?
> 
> I'm not sure, maybe an ioctl? That wouldn't be very convenient though.
> 
> The tp_smapi module (not in mainline) that exposes the battery threshold
> functionality for ThinkPads also uses sysfs.
> 
> If you meant
> 
>> Do we have any other options that expose something via sysfs?
> 
> yes, camera_power, fan_mode, touchpad and conservation_mode.

Any thoughts on this?

-- 
Hao Wei

Re: [PATCH v4] mfd: lp87565: Add lp87565 PMIC support

[Keerthy]

On Friday 09 June 2017 07:58 PM, Rob Herring wrote:
> On Thu, Jun 08, 2017 at 09:38:14AM +0530, Keerthy wrote:
>> The LP87565 chip is a power management IC for Portable Navigation Systems
>> and Tablet Computing devices. It contains the following components:
>>
>> - Configurable Bucks(Single and multi-phase).
>> - Configurable General Purpose Output Signals (GPO).
>>
>> The LP87565-Q1 variant device uses two 2-phase outputs configuration,
>> Buck0 is master for Buck0/1 output and Buck2 is master for Buck2/3
>> output.
>>
>> Signed-off-by: Keerthy 
>> ---
>>
>> The other patches are already pulled by Mark. Hence posting
>> the remaining patch.
>>
>> Changes in v4:
>>
>>   * Fixed device tree comments from Rob on the pmic node name.
>>   * removed regulators from properties list as it is a node.
>>  
>> Changes in v3:
>>
>>   * Fixed License to GPL v2.
>>   * Fixed an indentation issue.
>>
>> Changes in v2:
>>
>>   * Fixed a bunch of whitespace errors.
>>   * Changed the License to short form.
>>   * Added the generic compatible lp87565
>>   * Removed i2c_device_id table.
>>   * Introduced probe_new function in place of probe.
>>
>>  Documentation/devicetree/bindings/mfd/lp87565.txt |  43 
> 
> Acked-by: Rob Herring 

Thanks Rob.

> 
>>  drivers/mfd/Kconfig   |  14 ++
>>  drivers/mfd/Makefile  |   1 +
>>  drivers/mfd/lp87565.c |  92 
>>  include/linux/mfd/lp87565.h   | 270 
>> ++
>>  5 files changed, 420 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/mfd/lp87565.txt
>>  create mode 100644 drivers/mfd/lp87565.c
>>  create mode 100644 include/linux/mfd/lp87565.h

Re: [PATCH v4] mfd: lp87565: Add lp87565 PMIC support

[Keerthy]

On Friday 09 June 2017 07:58 PM, Rob Herring wrote:
> On Thu, Jun 08, 2017 at 09:38:14AM +0530, Keerthy wrote:
>> The LP87565 chip is a power management IC for Portable Navigation Systems
>> and Tablet Computing devices. It contains the following components:
>>
>> - Configurable Bucks(Single and multi-phase).
>> - Configurable General Purpose Output Signals (GPO).
>>
>> The LP87565-Q1 variant device uses two 2-phase outputs configuration,
>> Buck0 is master for Buck0/1 output and Buck2 is master for Buck2/3
>> output.
>>
>> Signed-off-by: Keerthy 
>> ---
>>
>> The other patches are already pulled by Mark. Hence posting
>> the remaining patch.
>>
>> Changes in v4:
>>
>>   * Fixed device tree comments from Rob on the pmic node name.
>>   * removed regulators from properties list as it is a node.
>>  
>> Changes in v3:
>>
>>   * Fixed License to GPL v2.
>>   * Fixed an indentation issue.
>>
>> Changes in v2:
>>
>>   * Fixed a bunch of whitespace errors.
>>   * Changed the License to short form.
>>   * Added the generic compatible lp87565
>>   * Removed i2c_device_id table.
>>   * Introduced probe_new function in place of probe.
>>
>>  Documentation/devicetree/bindings/mfd/lp87565.txt |  43 
> 
> Acked-by: Rob Herring 

Thanks Rob.

> 
>>  drivers/mfd/Kconfig   |  14 ++
>>  drivers/mfd/Makefile  |   1 +
>>  drivers/mfd/lp87565.c |  92 
>>  include/linux/mfd/lp87565.h   | 270 
>> ++
>>  5 files changed, 420 insertions(+)
>>  create mode 100644 Documentation/devicetree/bindings/mfd/lp87565.txt
>>  create mode 100644 drivers/mfd/lp87565.c
>>  create mode 100644 include/linux/mfd/lp87565.h

RE: [PATCH v1 2/3] gpio: Add support for TPS68470 GPIOs

[Mani, Rajmohan]

Hi Linus,

Thanks for the reviews.

> -Original Message-
> From: Linus Walleij [mailto:linus.wall...@linaro.org]
> Sent: Friday, June 09, 2017 4:15 AM
> To: Mani, Rajmohan 
> Cc: linux-kernel@vger.kernel.org; linux-g...@vger.kernel.org; ACPI Devel
> Maling List ; Lee Jones ;
> Alexandre Courbot ; Rafael J. Wysocki
> ; Len Brown 
> Subject: Re: [PATCH v1 2/3] gpio: Add support for TPS68470 GPIOs
> 
> On Tue, Jun 6, 2017 at 1:55 PM, Rajmohan Mani 
> wrote:
> 
> > This patch adds support for TPS68470 GPIOs.
> > There are 7 GPIOs and a few sensor related GPIOs.
> > These GPIOs can be requested and configured as appropriate.
> >
> > Signed-off-by: Rajmohan Mani 
> 
> Same comments as Andy already sent, plus:
> 
> > +static inline struct tps68470_gpio_data *to_gpio_data(struct
> > +gpio_chip *gpiochp) {
> > +   return container_of(gpiochp, struct tps68470_gpio_data, gc); }
> 
> Please use the data pointe inside gpio_chip.
> 

This is not clear to me.
The driver already gets the data pointer inside gpio_chip (which is gpiochp)
Is the name gpiochp misleading? 
I had to get rid of "i" in gpiochip, to meet 80 char limit.

> struct tps68470_gpio_data *foo = gpiochip_get_data(gc);
> 
> > +   ret = tps68470_reg_read(tps, reg, );
> (...)
> > +   tps68470_update_bits(tps, reg, BIT(offset), value ?
> > + BIT(offset) : 0);
> (...)
> > +   return tps68470_update_bits(tps, TPS68470_GPIO_CTL_REG_A(offset),
> > +TPS68470_GPIO_MODE_MASK,
> > +TPS68470_GPIO_MODE_OUT_CMOS);
> (...)
> > +   return tps68470_update_bits(tps, TPS68470_GPIO_CTL_REG_A(offset),
> > +  TPS68470_GPIO_MODE_MASK, 0x00);
> 
> This looks like a reimplementation of regmap. Is it not possible to create a
> regmap in the MFD driver and pass that around instead?
> 

Ack
Will be addressed in v2 of this patch series.

> > +struct gpiod_lookup_table gpios_table = {
> > +   .dev_id = NULL,
> > +   .table = {
> > + GPIO_LOOKUP("tps68470-gpio", 0, "gpio.0", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 1, "gpio.1", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 2, "gpio.2", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 3, "gpio.3", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 4, "gpio.4", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 5, "gpio.5", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 6, "gpio.6", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 7, "s_enable",
> GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 8, "s_idle", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 9, "s_resetn",
> GPIO_ACTIVE_HIGH),
> > + {},
> > +   },
> > +};
> 
> Hm that's why you include  I guess.
> 

Ack

> This warrants a big comment above it explaining why this is done like that and
> what the use is inside any system with this chip mounted.
> 

Ack
I have added comments in the MFD driver, inside which the lookup table has 
moved.

> > +   tps68470_gpio->gc.label = "tps68470-gpio";
> > +   tps68470_gpio->gc.owner = THIS_MODULE;
> > +   tps68470_gpio->gc.direction_input = tps68470_gpio_input;
> > +   tps68470_gpio->gc.direction_output = tps68470_gpio_output;
> 
> Please implement .get_direction()
> 

Ack

> > +   tps68470_gpio->gc.get = tps68470_gpio_get;
> > +   tps68470_gpio->gc.set = tps68470_gpio_set;
> > +   tps68470_gpio->gc.can_sleep = true;
> > +   tps68470_gpio->gc.ngpio = TPS68470_N_GPIO;
> > +   tps68470_gpio->gc.base = -1;
> > +   tps68470_gpio->gc.parent = >dev;
> 
> Consider assigning the .names() array some sensible line names.
> 

Ack

> > +static int tps68470_gpio_remove(struct platform_device *pdev) {
> > +   struct tps68470_gpio_data *tps68470_gpio =
> > +platform_get_drvdata(pdev);
> > +
> > +   gpiod_remove_lookup_table(_table);
> > +   gpiochip_remove(_gpio->gc);
> 
> You can't use devm_gpiochip_add()?
> 

Originally I couldn't, because the driver can not remove the lookup table upon 
exit/removal. I moved this code inside the MFD driver, which is modified to use 
.shutdown() to remove the lookup table, so it can use dev_mfd_* call.

RE: [PATCH v1 2/3] gpio: Add support for TPS68470 GPIOs

[Mani, Rajmohan]

Hi Linus,

Thanks for the reviews.

> -Original Message-
> From: Linus Walleij [mailto:linus.wall...@linaro.org]
> Sent: Friday, June 09, 2017 4:15 AM
> To: Mani, Rajmohan 
> Cc: linux-kernel@vger.kernel.org; linux-g...@vger.kernel.org; ACPI Devel
> Maling List ; Lee Jones ;
> Alexandre Courbot ; Rafael J. Wysocki
> ; Len Brown 
> Subject: Re: [PATCH v1 2/3] gpio: Add support for TPS68470 GPIOs
> 
> On Tue, Jun 6, 2017 at 1:55 PM, Rajmohan Mani 
> wrote:
> 
> > This patch adds support for TPS68470 GPIOs.
> > There are 7 GPIOs and a few sensor related GPIOs.
> > These GPIOs can be requested and configured as appropriate.
> >
> > Signed-off-by: Rajmohan Mani 
> 
> Same comments as Andy already sent, plus:
> 
> > +static inline struct tps68470_gpio_data *to_gpio_data(struct
> > +gpio_chip *gpiochp) {
> > +   return container_of(gpiochp, struct tps68470_gpio_data, gc); }
> 
> Please use the data pointe inside gpio_chip.
> 

This is not clear to me.
The driver already gets the data pointer inside gpio_chip (which is gpiochp)
Is the name gpiochp misleading? 
I had to get rid of "i" in gpiochip, to meet 80 char limit.

> struct tps68470_gpio_data *foo = gpiochip_get_data(gc);
> 
> > +   ret = tps68470_reg_read(tps, reg, );
> (...)
> > +   tps68470_update_bits(tps, reg, BIT(offset), value ?
> > + BIT(offset) : 0);
> (...)
> > +   return tps68470_update_bits(tps, TPS68470_GPIO_CTL_REG_A(offset),
> > +TPS68470_GPIO_MODE_MASK,
> > +TPS68470_GPIO_MODE_OUT_CMOS);
> (...)
> > +   return tps68470_update_bits(tps, TPS68470_GPIO_CTL_REG_A(offset),
> > +  TPS68470_GPIO_MODE_MASK, 0x00);
> 
> This looks like a reimplementation of regmap. Is it not possible to create a
> regmap in the MFD driver and pass that around instead?
> 

Ack
Will be addressed in v2 of this patch series.

> > +struct gpiod_lookup_table gpios_table = {
> > +   .dev_id = NULL,
> > +   .table = {
> > + GPIO_LOOKUP("tps68470-gpio", 0, "gpio.0", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 1, "gpio.1", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 2, "gpio.2", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 3, "gpio.3", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 4, "gpio.4", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 5, "gpio.5", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 6, "gpio.6", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 7, "s_enable",
> GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 8, "s_idle", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 9, "s_resetn",
> GPIO_ACTIVE_HIGH),
> > + {},
> > +   },
> > +};
> 
> Hm that's why you include  I guess.
> 

Ack

> This warrants a big comment above it explaining why this is done like that and
> what the use is inside any system with this chip mounted.
> 

Ack
I have added comments in the MFD driver, inside which the lookup table has 
moved.

> > +   tps68470_gpio->gc.label = "tps68470-gpio";
> > +   tps68470_gpio->gc.owner = THIS_MODULE;
> > +   tps68470_gpio->gc.direction_input = tps68470_gpio_input;
> > +   tps68470_gpio->gc.direction_output = tps68470_gpio_output;
> 
> Please implement .get_direction()
> 

Ack

> > +   tps68470_gpio->gc.get = tps68470_gpio_get;
> > +   tps68470_gpio->gc.set = tps68470_gpio_set;
> > +   tps68470_gpio->gc.can_sleep = true;
> > +   tps68470_gpio->gc.ngpio = TPS68470_N_GPIO;
> > +   tps68470_gpio->gc.base = -1;
> > +   tps68470_gpio->gc.parent = >dev;
> 
> Consider assigning the .names() array some sensible line names.
> 

Ack

> > +static int tps68470_gpio_remove(struct platform_device *pdev) {
> > +   struct tps68470_gpio_data *tps68470_gpio =
> > +platform_get_drvdata(pdev);
> > +
> > +   gpiod_remove_lookup_table(_table);
> > +   gpiochip_remove(_gpio->gc);
> 
> You can't use devm_gpiochip_add()?
> 

Originally I couldn't, because the driver can not remove the lookup table upon 
exit/removal. I moved this code inside the MFD driver, which is modified to use 
.shutdown() to remove the lookup table, so it can use dev_mfd_* call.

[PATCH] scsi: mpt3sas: Fix value returned by 'mpt3sas_base_attach' in case of error

[Christophe JAILLET]

'r' is known to be zero here, so it must be set to -ENOMEM is one of these
'kzalloc' fails.

Fixes: c696f7b83edea ("scsi: mpt3sas: Implement device_remove_in_progress check 
in IOCTL path")
Signed-off-by: Christophe JAILLET 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 18039bba26c4..22bee63ce239 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -5453,14 +5453,18 @@ mpt3sas_base_attach(struct MPT3SAS_ADAPTER *ioc)
ioc->pend_os_device_add_sz++;
ioc->pend_os_device_add = kzalloc(ioc->pend_os_device_add_sz,
GFP_KERNEL);
-   if (!ioc->pend_os_device_add)
+   if (!ioc->pend_os_device_add) {
+   r = -ENOMEM;
goto out_free_resources;
+   }
 
ioc->device_remove_in_progress_sz = ioc->pend_os_device_add_sz;
ioc->device_remove_in_progress =
kzalloc(ioc->device_remove_in_progress_sz, GFP_KERNEL);
-   if (!ioc->device_remove_in_progress)
+   if (!ioc->device_remove_in_progress) {
+   r = -ENOMEM;
goto out_free_resources;
+   }
 
ioc->fwfault_debug = mpt3sas_fwfault_debug;
 
-- 
2.11.0

[PATCH] scsi: mpt3sas: Fix value returned by 'mpt3sas_base_attach' in case of error

[Christophe JAILLET]

'r' is known to be zero here, so it must be set to -ENOMEM is one of these
'kzalloc' fails.

Fixes: c696f7b83edea ("scsi: mpt3sas: Implement device_remove_in_progress check 
in IOCTL path")
Signed-off-by: Christophe JAILLET 
---
 drivers/scsi/mpt3sas/mpt3sas_base.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/scsi/mpt3sas/mpt3sas_base.c 
b/drivers/scsi/mpt3sas/mpt3sas_base.c
index 18039bba26c4..22bee63ce239 100644
--- a/drivers/scsi/mpt3sas/mpt3sas_base.c
+++ b/drivers/scsi/mpt3sas/mpt3sas_base.c
@@ -5453,14 +5453,18 @@ mpt3sas_base_attach(struct MPT3SAS_ADAPTER *ioc)
ioc->pend_os_device_add_sz++;
ioc->pend_os_device_add = kzalloc(ioc->pend_os_device_add_sz,
GFP_KERNEL);
-   if (!ioc->pend_os_device_add)
+   if (!ioc->pend_os_device_add) {
+   r = -ENOMEM;
goto out_free_resources;
+   }
 
ioc->device_remove_in_progress_sz = ioc->pend_os_device_add_sz;
ioc->device_remove_in_progress =
kzalloc(ioc->device_remove_in_progress_sz, GFP_KERNEL);
-   if (!ioc->device_remove_in_progress)
+   if (!ioc->device_remove_in_progress) {
+   r = -ENOMEM;
goto out_free_resources;
+   }
 
ioc->fwfault_debug = mpt3sas_fwfault_debug;
 
-- 
2.11.0

Re: [PATCH] gpio: lp87565: Add support for GPIO

[Keerthy]

On Friday 09 June 2017 02:06 PM, Linus Walleij wrote:
> On Thu, Jun 1, 2017 at 5:10 AM, Keerthy  wrote:
> 
>> Add driver for lp87565 PMIC family GPIOs. Three GPIOs are supported
>> and can be configured in Open-drain output or Push-pull output.
>>
>> Signed-off-by: Keerthy 
> 
> (...)
>> The latest version of mfd driver for this pmic is posted:
>> https://lkml.org/lkml/2017/5/30/463
> (...)
>> +config GPIO_LP87565
>> +   tristate "TI LP87565 GPIO"
>> +   depends on MFD_TI_LP87565
> 
> Hm I guess that means I could merge it since it will only compile once
> that symbol turns up in the kernel tree.

Yes.

> 
>> +#include 
> 
> Please use
> #include 
> only.

Okay

> 
>> +#include 
> 
> Is this API stable enough that I could merge this and count on it to
> "just work" once the MFD driver lands?
> 
>> +struct lp87565_gpio {
>> +   struct gpio_chip chip;
>> +   struct lp87565 *lp87565;
>> +};
> 
> It seems the code would be easier to read if you store the struct regmap *map
> pointer here instead of the whole struct lp87565.
> 
> But it's no strong preference.

Okay

> 
>> +static int lp87565_gpio_get(struct gpio_chip *chip, unsigned int offset)
>> +{
>> +   struct lp87565_gpio *gpio = gpiochip_get_data(chip);
>> +   int ret, val;
>> +
>> +   ret = regmap_read(gpio->lp87565->regmap, LP87565_REG_GPIO_IN, );
>> +   if (ret < 0)
>> +   return ret;
>> +
>> +   return val & BIT(offset);
> 
> return !!(val & BIT(offset));
> 
> please, so it's clear that we clamp to [0,1].

Okay

> 
>> +static int lp87565_gpio_request(struct gpio_chip *gc, unsigned int offset)
>> +{
>> +   struct lp87565_gpio *gpio = gpiochip_get_data(gc);
>> +   int ret;
>> +
>> +   switch (offset) {
>> +   case 0:
>> +   case 1:
>> +   case 2:
>> +   /* Setup the GPIO*_SEL MUX to GPIO mode */
>> +   ret = regmap_update_bits(gpio->lp87565->regmap,
>> +LP87565_REG_PIN_FUNCTION,
>> +BIT(offset), BIT(offset));
> 
> Hm. Hm.
> 
> If this IC has several function modes for the pins it should also
> be a pin controller... I know it is a lot of upfront code, but... it will
> benefit you in the long run. Is it really just these three pins?
> 
> Maybe we should merge it into
> drivers/pinctrl/pinctrl-lp87565.c so that at least file placement does
> not become a problem later?

No Linus. Only 2 modes. So went along the lines of
drivers/gpio/gpio-lp873x.c. If you are not okay with this. I can as well
remove this part.

> 
>> +static int lp87565_gpio_set_config(struct gpio_chip *gc, unsigned int 
>> offset,
>> +  unsigned long config)
>> +{
>> +   struct lp87565_gpio *gpio = gpiochip_get_data(gc);
>> +
>> +   switch (pinconf_to_config_param(config)) {
>> +   case PIN_CONFIG_DRIVE_OPEN_DRAIN:
>> +   return regmap_update_bits(gpio->lp87565->regmap,
>> + LP87565_REG_GPIO_CONFIG,
>> + BIT(offset +
>> + __ffs(LP87565_GOIO1_OD)),
>> + BIT(offset +
>> + __ffs(LP87565_GOIO1_OD)));
>> +   case PIN_CONFIG_DRIVE_PUSH_PULL:
>> +   return regmap_update_bits(gpio->lp87565->regmap,
>> + LP87565_REG_GPIO_CONFIG,
>> + BIT(offset +
>> + __ffs(LP87565_GOIO1_OD)), 0);
>> +   default:
>> +   return -ENOTSUPP;
>> +   }
>> +}
> 
> Nice.
> 
> If this was a split GPIO+pin control driver this would just be a call
> into the pinctrl back-end from the GPIO controller, like
> drivers/pinctrl/intel/pinctrl-intel.c does with just using
> gpiochip_generic_config().

okay. These are the two modes. Do you prefer have the driver split. I
took the reference of lp873x and tps65218. So let me know.

> 
>> +static int lp87565_gpio_probe(struct platform_device *pdev)
>> +{
>> +   struct lp87565_gpio *gpio;
>> +   int ret;
>> +
>> +   gpio = devm_kzalloc(>dev, sizeof(*gpio), GFP_KERNEL);
>> +   if (!gpio)
>> +   return -ENOMEM;
>> +
>> +   platform_set_drvdata(pdev, gpio);
> 
> Is this pointer used anywhere?

Actually no. I can remove this.

> 
>> +   gpio->lp87565 = dev_get_drvdata(pdev->dev.parent);
> 
> So maybe assign the regmap instead.

Sure. Seems that is the only thing i am using out of the lp87565
structure. I will do that.

> 
> Yours,
> Linus Walleij
> 

Re: [PATCH] gpio: lp87565: Add support for GPIO

[Keerthy]

On Friday 09 June 2017 02:06 PM, Linus Walleij wrote:
> On Thu, Jun 1, 2017 at 5:10 AM, Keerthy  wrote:
> 
>> Add driver for lp87565 PMIC family GPIOs. Three GPIOs are supported
>> and can be configured in Open-drain output or Push-pull output.
>>
>> Signed-off-by: Keerthy 
> 
> (...)
>> The latest version of mfd driver for this pmic is posted:
>> https://lkml.org/lkml/2017/5/30/463
> (...)
>> +config GPIO_LP87565
>> +   tristate "TI LP87565 GPIO"
>> +   depends on MFD_TI_LP87565
> 
> Hm I guess that means I could merge it since it will only compile once
> that symbol turns up in the kernel tree.

Yes.

> 
>> +#include 
> 
> Please use
> #include 
> only.

Okay

> 
>> +#include 
> 
> Is this API stable enough that I could merge this and count on it to
> "just work" once the MFD driver lands?
> 
>> +struct lp87565_gpio {
>> +   struct gpio_chip chip;
>> +   struct lp87565 *lp87565;
>> +};
> 
> It seems the code would be easier to read if you store the struct regmap *map
> pointer here instead of the whole struct lp87565.
> 
> But it's no strong preference.

Okay

> 
>> +static int lp87565_gpio_get(struct gpio_chip *chip, unsigned int offset)
>> +{
>> +   struct lp87565_gpio *gpio = gpiochip_get_data(chip);
>> +   int ret, val;
>> +
>> +   ret = regmap_read(gpio->lp87565->regmap, LP87565_REG_GPIO_IN, );
>> +   if (ret < 0)
>> +   return ret;
>> +
>> +   return val & BIT(offset);
> 
> return !!(val & BIT(offset));
> 
> please, so it's clear that we clamp to [0,1].

Okay

> 
>> +static int lp87565_gpio_request(struct gpio_chip *gc, unsigned int offset)
>> +{
>> +   struct lp87565_gpio *gpio = gpiochip_get_data(gc);
>> +   int ret;
>> +
>> +   switch (offset) {
>> +   case 0:
>> +   case 1:
>> +   case 2:
>> +   /* Setup the GPIO*_SEL MUX to GPIO mode */
>> +   ret = regmap_update_bits(gpio->lp87565->regmap,
>> +LP87565_REG_PIN_FUNCTION,
>> +BIT(offset), BIT(offset));
> 
> Hm. Hm.
> 
> If this IC has several function modes for the pins it should also
> be a pin controller... I know it is a lot of upfront code, but... it will
> benefit you in the long run. Is it really just these three pins?
> 
> Maybe we should merge it into
> drivers/pinctrl/pinctrl-lp87565.c so that at least file placement does
> not become a problem later?

No Linus. Only 2 modes. So went along the lines of
drivers/gpio/gpio-lp873x.c. If you are not okay with this. I can as well
remove this part.

> 
>> +static int lp87565_gpio_set_config(struct gpio_chip *gc, unsigned int 
>> offset,
>> +  unsigned long config)
>> +{
>> +   struct lp87565_gpio *gpio = gpiochip_get_data(gc);
>> +
>> +   switch (pinconf_to_config_param(config)) {
>> +   case PIN_CONFIG_DRIVE_OPEN_DRAIN:
>> +   return regmap_update_bits(gpio->lp87565->regmap,
>> + LP87565_REG_GPIO_CONFIG,
>> + BIT(offset +
>> + __ffs(LP87565_GOIO1_OD)),
>> + BIT(offset +
>> + __ffs(LP87565_GOIO1_OD)));
>> +   case PIN_CONFIG_DRIVE_PUSH_PULL:
>> +   return regmap_update_bits(gpio->lp87565->regmap,
>> + LP87565_REG_GPIO_CONFIG,
>> + BIT(offset +
>> + __ffs(LP87565_GOIO1_OD)), 0);
>> +   default:
>> +   return -ENOTSUPP;
>> +   }
>> +}
> 
> Nice.
> 
> If this was a split GPIO+pin control driver this would just be a call
> into the pinctrl back-end from the GPIO controller, like
> drivers/pinctrl/intel/pinctrl-intel.c does with just using
> gpiochip_generic_config().

okay. These are the two modes. Do you prefer have the driver split. I
took the reference of lp873x and tps65218. So let me know.

> 
>> +static int lp87565_gpio_probe(struct platform_device *pdev)
>> +{
>> +   struct lp87565_gpio *gpio;
>> +   int ret;
>> +
>> +   gpio = devm_kzalloc(>dev, sizeof(*gpio), GFP_KERNEL);
>> +   if (!gpio)
>> +   return -ENOMEM;
>> +
>> +   platform_set_drvdata(pdev, gpio);
> 
> Is this pointer used anywhere?

Actually no. I can remove this.

> 
>> +   gpio->lp87565 = dev_get_drvdata(pdev->dev.parent);
> 
> So maybe assign the regmap instead.

Sure. Seems that is the only thing i am using out of the lp87565
structure. I will do that.

> 
> Yours,
> Linus Walleij
> 

[PATCH v3 1/2] PCI: iproc: Retry request when CRS returned from EP

[Oza Pawandeep]

For Configuration Requests only, following reset
it is possible for a device to terminate the request
but indicate that it is temporarily unable to process
the Request, but will be able to process the Request
in the future – in this case, the Configuration Request
Retry Status 10 (CRS) Completion Status is used

SPDK user space NVMe driver reinitializes NVMe which
causes reset, while doing this some configuration requests
get NAKed by Endpoint (NVMe).
Current iproc PCI driver is agnostic about it.
PAXB will forward the NAKed response in stipulated AXI code.

NVMe spec defines this timeout in 500 ms units, and this
only happens if controller has been in reset, or with new firmware,
or in abrupt shutdown case.
Meanwhile config access could result into retry.

This patch fixes the problem, and attempts to read again in case
of PAXB forwarding the NAK.

It implements iproc_pcie_config_read which gets called for Stingray.
Otherwise it falls back to PCI generic APIs.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 

diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 0f39bd2..05a3647 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -68,6 +68,9 @@
 #define APB_ERR_EN_SHIFT 0
 #define APB_ERR_EN   BIT(APB_ERR_EN_SHIFT)
 
+#define CFG_RETRY_STATUS 0x0001
+#define CFG_RETRY_STATUS_TIMEOUT_US  50 /* 500 milli-seconds. */
+
 /* derive the enum index of the outbound/inbound mapping registers */
 #define MAP_REG(base_reg, index)  ((base_reg) + (index) * 2)
 
@@ -448,6 +451,47 @@ static inline void iproc_pcie_apb_err_disable(struct 
pci_bus *bus,
}
 }
 
+static int iproc_pcie_cfg_retry(void __iomem *cfg_data_p)
+{
+   int timeout = CFG_RETRY_STATUS_TIMEOUT_US;
+   unsigned int ret;
+
+   do {
+   ret = readl(cfg_data_p);
+   if (ret == CFG_RETRY_STATUS)
+   udelay(1);
+   else
+   return PCIBIOS_SUCCESSFUL;
+   } while (timeout--);
+
+   return PCIBIOS_DEVICE_NOT_FOUND;
+}
+
+static void __iomem *iproc_pcie_map_ep_cfg_reg(struct iproc_pcie *pcie,
+  unsigned int busno,
+  unsigned int slot,
+  unsigned int fn,
+  int where)
+{
+   u16 offset;
+   u32 val;
+
+   /* EP device access */
+   val = (busno << CFG_ADDR_BUS_NUM_SHIFT) |
+   (slot << CFG_ADDR_DEV_NUM_SHIFT) |
+   (fn << CFG_ADDR_FUNC_NUM_SHIFT) |
+   (where & CFG_ADDR_REG_NUM_MASK) |
+   (1 & CFG_ADDR_CFG_TYPE_MASK);
+
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_CFG_ADDR, val);
+   offset = iproc_pcie_reg_offset(pcie, IPROC_PCIE_CFG_DATA);
+
+   if (iproc_pcie_reg_is_invalid(offset))
+   return NULL;
+
+   return (pcie->base + offset);
+}
+
 /**
  * Note access to the configuration registers are protected at the higher layer
  * by 'pci_lock' in drivers/pci/access.c
@@ -499,13 +543,48 @@ static void __iomem *iproc_pcie_map_cfg_bus(struct 
pci_bus *bus,
return (pcie->base + offset);
 }
 
+static int iproc_pcie_config_read(struct pci_bus *bus, unsigned int devfn,
+   int where, int size, u32 *val)
+{
+   struct iproc_pcie *pcie = iproc_data(bus);
+   unsigned int slot = PCI_SLOT(devfn);
+   unsigned int fn = PCI_FUNC(devfn);
+   unsigned int busno = bus->number;
+   void __iomem *cfg_data_p;
+   int ret;
+
+   /* root complex access. */
+   if (busno == 0)
+   return pci_generic_config_read32(bus, devfn, where, size, val);
+
+   cfg_data_p = iproc_pcie_map_ep_cfg_reg(pcie, busno, slot, fn, where);
+
+   if (!cfg_data_p)
+   return PCIBIOS_DEVICE_NOT_FOUND;
+
+   ret = iproc_pcie_cfg_retry(cfg_data_p);
+   if (ret)
+   return ret;
+
+   *val = readl(cfg_data_p);
+
+   if (size <= 2)
+   *val = (*val >> (8 * (where & 3))) & ((1 << (size * 8)) - 1);
+
+   return PCIBIOS_SUCCESSFUL;
+}
+
 static int iproc_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
int where, int size, u32 *val)
 {
int ret;
+   struct iproc_pcie *pcie = iproc_data(bus);
 
iproc_pcie_apb_err_disable(bus, true);
-   ret = pci_generic_config_read32(bus, devfn, where, size, val);
+   if (pcie->type == IPROC_PCIE_PAXB_V2)
+   ret = iproc_pcie_config_read(bus, devfn, where, size, val);
+   else
+   ret = pci_generic_config_read32(bus, devfn, where, size, val);
iproc_pcie_apb_err_disable(bus, false);
 
return ret;
-- 
1.9.1

[PATCH v3 0/2] PCI: iproc: SOC specific fixes

[Oza Pawandeep]

PCI: iproc: Retry request when CRS returned from EP

Above patch adds support for CRS in PCI RC driver,
otherwise if not handled at lower level, the user
space PMD (poll mode drivers) can timeout.

PCI: iproc: add device shutdown for PCI RC

This fixes the issue where certian PCI endpoints are
not getting detected on Stingray SOC after reboot.

Changes Since v3:
[re-send] 
Changes Since v2:
Fix compilation errors for pcie-iproc-platform.ko
which was caught by kbuild.

Oza Pawandeep (2):
  PCI: iproc: Retry request when CRS returned from EP
  PCI: iproc: add device shutdown for PCI RC

 drivers/pci/host/pcie-iproc-platform.c |   8 +++
 drivers/pci/host/pcie-iproc.c  | 126 -
 drivers/pci/host/pcie-iproc.h  |   1 +
 3 files changed, 116 insertions(+), 19 deletions(-)

-- 
1.9.1

[PATCH v3 2/2] PCI: iproc: add device shutdown for PCI RC

[Oza Pawandeep]

PERST# must be asserted around ~500ms before
the reboot is applied.

During soft reset (e.g., "reboot" from Linux) on some iProc based SoCs
LCPLL clock and PERST both goes off simultaneously.
This will cause certain Endpoints Intel NVMe not get detected, upon
next boot sequence.

This happens because; Endpoint is expecting the clock for some amount of
time after PERST is asserted, which is not happening in our case
(Compare to Intel X86 boards, will have clocks running).
this cause NVMe to behave in undefined way.

Essentially clock will remain alive for 500ms with PERST# = 0
before reboot.

This patch adds platform shutdown where it should be
called in device_shutdown while reboot command is issued.

So in sequence first Endpoint Shutdown (e.g. nvme_shutdown)
followed by RC shutdown is called, which issues safe PERST
assertion.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 

diff --git a/drivers/pci/host/pcie-iproc-platform.c 
b/drivers/pci/host/pcie-iproc-platform.c
index 90d2bdd..9512960 100644
--- a/drivers/pci/host/pcie-iproc-platform.c
+++ b/drivers/pci/host/pcie-iproc-platform.c
@@ -131,6 +131,13 @@ static int iproc_pcie_pltfm_remove(struct platform_device 
*pdev)
return iproc_pcie_remove(pcie);
 }
 
+static void iproc_pcie_pltfm_shutdown(struct platform_device *pdev)
+{
+   struct iproc_pcie *pcie = platform_get_drvdata(pdev);
+
+   iproc_pcie_shutdown(pcie);
+}
+
 static struct platform_driver iproc_pcie_pltfm_driver = {
.driver = {
.name = "iproc-pcie",
@@ -138,6 +145,7 @@ static int iproc_pcie_pltfm_remove(struct platform_device 
*pdev)
},
.probe = iproc_pcie_pltfm_probe,
.remove = iproc_pcie_pltfm_remove,
+   .shutdown = iproc_pcie_pltfm_shutdown,
 };
 module_platform_driver(iproc_pcie_pltfm_driver);
 
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 05a3647..bb61376 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -608,32 +608,40 @@ static int iproc_pcie_config_write32(struct pci_bus *bus, 
unsigned int devfn,
.write = iproc_pcie_config_write32,
 };
 
-static void iproc_pcie_reset(struct iproc_pcie *pcie)
+static void iproc_pcie_perst_ctrl(struct iproc_pcie *pcie, bool assert)
 {
u32 val;
 
/*
-* PAXC and the internal emulated endpoint device downstream should not
-* be reset.  If firmware has been loaded on the endpoint device at an
-* earlier boot stage, reset here causes issues.
+* The internal emulated endpoints (such as PAXC) device downstream
+* should not be reset. If firmware has been loaded on the endpoint
+* device at an earlier boot stage, reset here causes issues.
 */
if (pcie->ep_is_internal)
return;
 
-   /*
-* Select perst_b signal as reset source. Put the device into reset,
-* and then bring it out of reset
-*/
-   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
-   val &= ~EP_PERST_SOURCE_SELECT & ~EP_MODE_SURVIVE_PERST &
-   ~RC_PCIE_RST_OUTPUT;
-   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
-   udelay(250);
-
-   val |= RC_PCIE_RST_OUTPUT;
-   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
-   msleep(100);
+   if (assert) {
+   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
+   val &= ~EP_PERST_SOURCE_SELECT & ~EP_MODE_SURVIVE_PERST &
+   ~RC_PCIE_RST_OUTPUT;
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
+   udelay(250);
+   } else {
+   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
+   val |= RC_PCIE_RST_OUTPUT;
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
+   msleep(100);
+   }
+}
+
+int iproc_pcie_shutdown(struct iproc_pcie *pcie)
+{
+   iproc_pcie_perst_ctrl(pcie, true);
+   msleep(500);
+
+   return 0;
 }
+EXPORT_SYMBOL(iproc_pcie_shutdown);
 
 static int iproc_pcie_check_link(struct iproc_pcie *pcie, struct pci_bus *bus)
 {
@@ -1310,7 +1318,8 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct 
list_head *res)
goto err_exit_phy;
}
 
-   iproc_pcie_reset(pcie);
+   iproc_pcie_perst_ctrl(pcie, true);
+   iproc_pcie_perst_ctrl(pcie, false);
 
if (pcie->need_ob_cfg) {
ret = iproc_pcie_map_ranges(pcie, res);
diff --git a/drivers/pci/host/pcie-iproc.h b/drivers/pci/host/pcie-iproc.h
index 0bbe2ea..a6b55ce 100644
--- a/drivers/pci/host/pcie-iproc.h
+++ b/drivers/pci/host/pcie-iproc.h
@@ -110,6 +110,7 @@ struct iproc_pcie {
 
 int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res);
 int iproc_pcie_remove(struct iproc_pcie *pcie);
+int iproc_pcie_shutdown(struct iproc_pcie *pcie);
 
 #ifdef 

[PATCH v3 1/2] PCI: iproc: Retry request when CRS returned from EP

[Oza Pawandeep]

For Configuration Requests only, following reset
it is possible for a device to terminate the request
but indicate that it is temporarily unable to process
the Request, but will be able to process the Request
in the future – in this case, the Configuration Request
Retry Status 10 (CRS) Completion Status is used

SPDK user space NVMe driver reinitializes NVMe which
causes reset, while doing this some configuration requests
get NAKed by Endpoint (NVMe).
Current iproc PCI driver is agnostic about it.
PAXB will forward the NAKed response in stipulated AXI code.

NVMe spec defines this timeout in 500 ms units, and this
only happens if controller has been in reset, or with new firmware,
or in abrupt shutdown case.
Meanwhile config access could result into retry.

This patch fixes the problem, and attempts to read again in case
of PAXB forwarding the NAK.

It implements iproc_pcie_config_read which gets called for Stingray.
Otherwise it falls back to PCI generic APIs.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 

diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 0f39bd2..05a3647 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -68,6 +68,9 @@
 #define APB_ERR_EN_SHIFT 0
 #define APB_ERR_EN   BIT(APB_ERR_EN_SHIFT)
 
+#define CFG_RETRY_STATUS 0x0001
+#define CFG_RETRY_STATUS_TIMEOUT_US  50 /* 500 milli-seconds. */
+
 /* derive the enum index of the outbound/inbound mapping registers */
 #define MAP_REG(base_reg, index)  ((base_reg) + (index) * 2)
 
@@ -448,6 +451,47 @@ static inline void iproc_pcie_apb_err_disable(struct 
pci_bus *bus,
}
 }
 
+static int iproc_pcie_cfg_retry(void __iomem *cfg_data_p)
+{
+   int timeout = CFG_RETRY_STATUS_TIMEOUT_US;
+   unsigned int ret;
+
+   do {
+   ret = readl(cfg_data_p);
+   if (ret == CFG_RETRY_STATUS)
+   udelay(1);
+   else
+   return PCIBIOS_SUCCESSFUL;
+   } while (timeout--);
+
+   return PCIBIOS_DEVICE_NOT_FOUND;
+}
+
+static void __iomem *iproc_pcie_map_ep_cfg_reg(struct iproc_pcie *pcie,
+  unsigned int busno,
+  unsigned int slot,
+  unsigned int fn,
+  int where)
+{
+   u16 offset;
+   u32 val;
+
+   /* EP device access */
+   val = (busno << CFG_ADDR_BUS_NUM_SHIFT) |
+   (slot << CFG_ADDR_DEV_NUM_SHIFT) |
+   (fn << CFG_ADDR_FUNC_NUM_SHIFT) |
+   (where & CFG_ADDR_REG_NUM_MASK) |
+   (1 & CFG_ADDR_CFG_TYPE_MASK);
+
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_CFG_ADDR, val);
+   offset = iproc_pcie_reg_offset(pcie, IPROC_PCIE_CFG_DATA);
+
+   if (iproc_pcie_reg_is_invalid(offset))
+   return NULL;
+
+   return (pcie->base + offset);
+}
+
 /**
  * Note access to the configuration registers are protected at the higher layer
  * by 'pci_lock' in drivers/pci/access.c
@@ -499,13 +543,48 @@ static void __iomem *iproc_pcie_map_cfg_bus(struct 
pci_bus *bus,
return (pcie->base + offset);
 }
 
+static int iproc_pcie_config_read(struct pci_bus *bus, unsigned int devfn,
+   int where, int size, u32 *val)
+{
+   struct iproc_pcie *pcie = iproc_data(bus);
+   unsigned int slot = PCI_SLOT(devfn);
+   unsigned int fn = PCI_FUNC(devfn);
+   unsigned int busno = bus->number;
+   void __iomem *cfg_data_p;
+   int ret;
+
+   /* root complex access. */
+   if (busno == 0)
+   return pci_generic_config_read32(bus, devfn, where, size, val);
+
+   cfg_data_p = iproc_pcie_map_ep_cfg_reg(pcie, busno, slot, fn, where);
+
+   if (!cfg_data_p)
+   return PCIBIOS_DEVICE_NOT_FOUND;
+
+   ret = iproc_pcie_cfg_retry(cfg_data_p);
+   if (ret)
+   return ret;
+
+   *val = readl(cfg_data_p);
+
+   if (size <= 2)
+   *val = (*val >> (8 * (where & 3))) & ((1 << (size * 8)) - 1);
+
+   return PCIBIOS_SUCCESSFUL;
+}
+
 static int iproc_pcie_config_read32(struct pci_bus *bus, unsigned int devfn,
int where, int size, u32 *val)
 {
int ret;
+   struct iproc_pcie *pcie = iproc_data(bus);
 
iproc_pcie_apb_err_disable(bus, true);
-   ret = pci_generic_config_read32(bus, devfn, where, size, val);
+   if (pcie->type == IPROC_PCIE_PAXB_V2)
+   ret = iproc_pcie_config_read(bus, devfn, where, size, val);
+   else
+   ret = pci_generic_config_read32(bus, devfn, where, size, val);
iproc_pcie_apb_err_disable(bus, false);
 
return ret;
-- 
1.9.1

[PATCH v3 0/2] PCI: iproc: SOC specific fixes

[Oza Pawandeep]

PCI: iproc: Retry request when CRS returned from EP

Above patch adds support for CRS in PCI RC driver,
otherwise if not handled at lower level, the user
space PMD (poll mode drivers) can timeout.

PCI: iproc: add device shutdown for PCI RC

This fixes the issue where certian PCI endpoints are
not getting detected on Stingray SOC after reboot.

Changes Since v3:
[re-send] 
Changes Since v2:
Fix compilation errors for pcie-iproc-platform.ko
which was caught by kbuild.

Oza Pawandeep (2):
  PCI: iproc: Retry request when CRS returned from EP
  PCI: iproc: add device shutdown for PCI RC

 drivers/pci/host/pcie-iproc-platform.c |   8 +++
 drivers/pci/host/pcie-iproc.c  | 126 -
 drivers/pci/host/pcie-iproc.h  |   1 +
 3 files changed, 116 insertions(+), 19 deletions(-)

-- 
1.9.1

[PATCH v3 2/2] PCI: iproc: add device shutdown for PCI RC

[Oza Pawandeep]

PERST# must be asserted around ~500ms before
the reboot is applied.

During soft reset (e.g., "reboot" from Linux) on some iProc based SoCs
LCPLL clock and PERST both goes off simultaneously.
This will cause certain Endpoints Intel NVMe not get detected, upon
next boot sequence.

This happens because; Endpoint is expecting the clock for some amount of
time after PERST is asserted, which is not happening in our case
(Compare to Intel X86 boards, will have clocks running).
this cause NVMe to behave in undefined way.

Essentially clock will remain alive for 500ms with PERST# = 0
before reboot.

This patch adds platform shutdown where it should be
called in device_shutdown while reboot command is issued.

So in sequence first Endpoint Shutdown (e.g. nvme_shutdown)
followed by RC shutdown is called, which issues safe PERST
assertion.

Signed-off-by: Oza Pawandeep 
Reviewed-by: Ray Jui 
Reviewed-by: Scott Branden 

diff --git a/drivers/pci/host/pcie-iproc-platform.c 
b/drivers/pci/host/pcie-iproc-platform.c
index 90d2bdd..9512960 100644
--- a/drivers/pci/host/pcie-iproc-platform.c
+++ b/drivers/pci/host/pcie-iproc-platform.c
@@ -131,6 +131,13 @@ static int iproc_pcie_pltfm_remove(struct platform_device 
*pdev)
return iproc_pcie_remove(pcie);
 }
 
+static void iproc_pcie_pltfm_shutdown(struct platform_device *pdev)
+{
+   struct iproc_pcie *pcie = platform_get_drvdata(pdev);
+
+   iproc_pcie_shutdown(pcie);
+}
+
 static struct platform_driver iproc_pcie_pltfm_driver = {
.driver = {
.name = "iproc-pcie",
@@ -138,6 +145,7 @@ static int iproc_pcie_pltfm_remove(struct platform_device 
*pdev)
},
.probe = iproc_pcie_pltfm_probe,
.remove = iproc_pcie_pltfm_remove,
+   .shutdown = iproc_pcie_pltfm_shutdown,
 };
 module_platform_driver(iproc_pcie_pltfm_driver);
 
diff --git a/drivers/pci/host/pcie-iproc.c b/drivers/pci/host/pcie-iproc.c
index 05a3647..bb61376 100644
--- a/drivers/pci/host/pcie-iproc.c
+++ b/drivers/pci/host/pcie-iproc.c
@@ -608,32 +608,40 @@ static int iproc_pcie_config_write32(struct pci_bus *bus, 
unsigned int devfn,
.write = iproc_pcie_config_write32,
 };
 
-static void iproc_pcie_reset(struct iproc_pcie *pcie)
+static void iproc_pcie_perst_ctrl(struct iproc_pcie *pcie, bool assert)
 {
u32 val;
 
/*
-* PAXC and the internal emulated endpoint device downstream should not
-* be reset.  If firmware has been loaded on the endpoint device at an
-* earlier boot stage, reset here causes issues.
+* The internal emulated endpoints (such as PAXC) device downstream
+* should not be reset. If firmware has been loaded on the endpoint
+* device at an earlier boot stage, reset here causes issues.
 */
if (pcie->ep_is_internal)
return;
 
-   /*
-* Select perst_b signal as reset source. Put the device into reset,
-* and then bring it out of reset
-*/
-   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
-   val &= ~EP_PERST_SOURCE_SELECT & ~EP_MODE_SURVIVE_PERST &
-   ~RC_PCIE_RST_OUTPUT;
-   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
-   udelay(250);
-
-   val |= RC_PCIE_RST_OUTPUT;
-   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
-   msleep(100);
+   if (assert) {
+   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
+   val &= ~EP_PERST_SOURCE_SELECT & ~EP_MODE_SURVIVE_PERST &
+   ~RC_PCIE_RST_OUTPUT;
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
+   udelay(250);
+   } else {
+   val = iproc_pcie_read_reg(pcie, IPROC_PCIE_CLK_CTRL);
+   val |= RC_PCIE_RST_OUTPUT;
+   iproc_pcie_write_reg(pcie, IPROC_PCIE_CLK_CTRL, val);
+   msleep(100);
+   }
+}
+
+int iproc_pcie_shutdown(struct iproc_pcie *pcie)
+{
+   iproc_pcie_perst_ctrl(pcie, true);
+   msleep(500);
+
+   return 0;
 }
+EXPORT_SYMBOL(iproc_pcie_shutdown);
 
 static int iproc_pcie_check_link(struct iproc_pcie *pcie, struct pci_bus *bus)
 {
@@ -1310,7 +1318,8 @@ int iproc_pcie_setup(struct iproc_pcie *pcie, struct 
list_head *res)
goto err_exit_phy;
}
 
-   iproc_pcie_reset(pcie);
+   iproc_pcie_perst_ctrl(pcie, true);
+   iproc_pcie_perst_ctrl(pcie, false);
 
if (pcie->need_ob_cfg) {
ret = iproc_pcie_map_ranges(pcie, res);
diff --git a/drivers/pci/host/pcie-iproc.h b/drivers/pci/host/pcie-iproc.h
index 0bbe2ea..a6b55ce 100644
--- a/drivers/pci/host/pcie-iproc.h
+++ b/drivers/pci/host/pcie-iproc.h
@@ -110,6 +110,7 @@ struct iproc_pcie {
 
 int iproc_pcie_setup(struct iproc_pcie *pcie, struct list_head *res);
 int iproc_pcie_remove(struct iproc_pcie *pcie);
+int iproc_pcie_shutdown(struct iproc_pcie *pcie);
 
 #ifdef CONFIG_PCIE_IPROC_MSI
 int iproc_msi_init(struct iproc_pcie *pcie, struct 

[PATCH 4/5] watchdog: it87: Use infrastructure to stop watchdog on reboot

[Guenter Roeck]

Use watchdog_stop_on_reboot() to stop the watchdog on reboot instead
of registering a driver-specific notifier.

While at it, reorder remaining include files alphabetically.

Signed-off-by: Guenter Roeck 
---
 drivers/watchdog/it87_wdt.c | 34 +-
 1 file changed, 5 insertions(+), 29 deletions(-)

diff --git a/drivers/watchdog/it87_wdt.c b/drivers/watchdog/it87_wdt.c
index 29aea28628c8..07f4727eb7f4 100644
--- a/drivers/watchdog/it87_wdt.c
+++ b/drivers/watchdog/it87_wdt.c
@@ -28,15 +28,13 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
-#include 
-#include 
-#include 
 
 #define WATCHDOG_NAME  "IT87 WDT"
 
@@ -260,18 +258,6 @@ static struct watchdog_device wdt_dev = {
.min_timeout = 1,
 };
 
-static int wdt_notify_sys(struct notifier_block *this, unsigned long code,
- void *unused)
-{
-   if (code == SYS_DOWN || code == SYS_HALT)
-   wdt_stop(_dev);
-   return NOTIFY_DONE;
-}
-
-static struct notifier_block wdt_notifier = {
-   .notifier_call = wdt_notify_sys,
-};
-
 static int __init it87_wdt_init(void)
 {
u8  chip_rev;
@@ -338,32 +324,22 @@ static int __init it87_wdt_init(void)
wdt_dev.timeout = timeout;
wdt_dev.max_timeout = max_units * 60;
 
-   rc = register_reboot_notifier(_notifier);
-   if (rc) {
-   pr_err("Cannot register reboot notifier (err=%d)\n", rc);
-   return rc;
-   }
-
+   watchdog_stop_on_reboot(_dev);
rc = watchdog_register_device(_dev);
if (rc) {
pr_err("Cannot register watchdog device (err=%d)\n", rc);
-   goto err_out_reboot;
+   return rc;
}
 
pr_info("Chip IT%04x revision %d initialized. timeout=%d sec 
(nowayout=%d testmode=%d)\n",
chip_type, chip_rev, timeout, nowayout, testmode);
 
return 0;
-
-err_out_reboot:
-   unregister_reboot_notifier(_notifier);
-   return rc;
 }
 
 static void __exit it87_wdt_exit(void)
 {
watchdog_unregister_device(_dev);
-   unregister_reboot_notifier(_notifier);
 }
 
 module_init(it87_wdt_init);
-- 
2.7.4

[PATCH 3/5] watchdog: it87: Drop support for resetting watchdog though CIR and Game port

[Guenter Roeck]

Resetting the watchdog timer on CIR interrupts or on game port interrupts
is not not supported on recent chips, and doesn't really tell if the system
is stable. On top of that, at least the bit to enable resetting the
watchdog through the game port is used differently on recent chips.
Drop resetting the watchdog on CIR  or game port interrupts to simplify
the code.

Signed-off-by: Guenter Roeck 
---
 drivers/watchdog/Kconfig|   3 -
 drivers/watchdog/it87_wdt.c | 226 
 2 files changed, 19 insertions(+), 210 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 20020a4bb71e..793146be38e0 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1043,9 +1043,6 @@ config IT87_WDT
  IT8702, IT8712, IT8716, IT8718, IT8720, IT8721, IT8726 and IT8728
  Super I/O chips.
 
- If the driver does not work, then make sure that the game port in
- the BIOS is enabled.
-
  This watchdog simply watches your kernel to make sure it doesn't
  freeze, and if it does, it reboots your computer after a certain
  amount of time.
diff --git a/drivers/watchdog/it87_wdt.c b/drivers/watchdog/it87_wdt.c
index 9a6523e70ffc..29aea28628c8 100644
--- a/drivers/watchdog/it87_wdt.c
+++ b/drivers/watchdog/it87_wdt.c
@@ -33,7 +33,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -42,8 +41,6 @@
 #define WATCHDOG_NAME  "IT87 WDT"
 
 /* Defaults for Module Parameter */
-#define DEFAULT_NOGAMEPORT 0
-#define DEFAULT_NOCIR  0
 #define DEFAULT_TIMEOUT60
 #define DEFAULT_TESTMODE   0
 #define DEFAULT_NOWAYOUT   WATCHDOG_NOWAYOUT
@@ -54,15 +51,11 @@
 
 /* Logical device Numbers LDN */
 #define GPIO   0x07
-#define GAMEPORT   0x09
-#define CIR0x0a
 
 /* Configuration Registers and Functions */
 #define LDNREG 0x07
 #define CHIPID 0x20
 #define CHIPREV0x22
-#define ACTREG 0x30
-#define BASEREG0x60
 
 /* Chip Id numbers */
 #define NO_DEV_ID  0x
@@ -84,14 +77,6 @@
 #define WDTVALLSB  0x73
 #define WDTVALMSB  0x74
 
-/* GPIO Bits WDTCTRL */
-#define WDT_CIRINT 0x80
-#define WDT_MOUSEINT   0x40
-#define WDT_KYBINT 0x20
-#define WDT_GAMEPORT   0x10 /* not in it8718, it8720, it8721, it8728 */
-#define WDT_FORCE  0x02
-#define WDT_ZERO   0x01
-
 /* GPIO Bits WDTCFG */
 #define WDT_TOV1   0x80
 #define WDT_KRST   0x40
@@ -99,46 +84,12 @@
 #define WDT_PWROK  0x10 /* not in it8721 */
 #define WDT_INT_MASK   0x0f
 
-/* CIR Configuration Register LDN=0x0a */
-#define CIR_ILS0x70
-
-/* The default Base address is not always available, we use this */
-#define CIR_BASE   0x0208
-
-/* CIR Controller */
-#define CIR_DR(b)  (b)
-#define CIR_IER(b) (b + 1)
-#define CIR_RCR(b) (b + 2)
-#define CIR_TCR1(b)(b + 3)
-#define CIR_TCR2(b)(b + 4)
-#define CIR_TSR(b) (b + 5)
-#define CIR_RSR(b) (b + 6)
-#define CIR_BDLR(b)(b + 5)
-#define CIR_BDHR(b)(b + 6)
-#define CIR_IIR(b) (b + 7)
-
-/* Default Base address of Game port */
-#define GP_BASE_DEFAULT0x0201
+static unsigned int max_units, chip_type;
 
-/* wdt_status */
-#define WDTS_USE_GP0
-#define WDTS_USE_CIR   1
-
-static unsigned int base, gpact, ciract, max_units, chip_type;
-static unsigned long wdt_status;
-
-static int nogameport  = DEFAULT_NOGAMEPORT;
-static int nocir   = DEFAULT_NOCIR;
 static unsigned int timeout = DEFAULT_TIMEOUT;
-static int testmode= DEFAULT_TESTMODE;
-static bool nowayout= DEFAULT_NOWAYOUT;
-
-module_param(nogameport, int, 0);
-MODULE_PARM_DESC(nogameport, "Forbid the activation of game port, default="
-   __MODULE_STRING(DEFAULT_NOGAMEPORT));
-module_param(nocir, int, 0);
-MODULE_PARM_DESC(nocir, "Forbid the use of Consumer IR interrupts to reset 
timer, default="
-   __MODULE_STRING(DEFAULT_NOCIR));
+static int testmode = DEFAULT_TESTMODE;
+static bool nowayout = DEFAULT_NOWAYOUT;
+
 module_param(timeout, int, 0);
 MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds, default="
__MODULE_STRING(DEFAULT_TIMEOUT));
@@ -210,29 +161,28 @@ static inline void superio_outw(int val, int reg)
 }
 
 /* Internal function, should be called after superio_select(GPIO) */
-static void _wdt_update_timeout(void)
+static void _wdt_update_timeout(unsigned int t)
 {
unsigned char cfg = WDT_KRST;
-   int tm = timeout;
 
if (testmode)
cfg = 0;
 
-   if (tm <= max_units)
+   if (t <= max_units)
cfg |= WDT_TOV1;
else
-   tm /= 60;
+   t /= 60;
 
if (chip_type != IT8721_ID)
cfg |= WDT_PWROK;
 
superio_outb(cfg, WDTCFG);
-   superio_outb(tm, WDTVALLSB);
+   superio_outb(t, WDTVALLSB);
if 

[PATCH 2/5] watchdog: it87: Convert to use watchdog core infrastructure

[Guenter Roeck]

Signed-off-by: Guenter Roeck 
---
 drivers/watchdog/Kconfig|   1 +
 drivers/watchdog/it87_wdt.c | 375 +---
 2 files changed, 72 insertions(+), 304 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 8b9049dac094..20020a4bb71e 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1037,6 +1037,7 @@ config IT8712F_WDT
 config IT87_WDT
tristate "IT87 Watchdog Timer"
depends on X86
+   select WATCHDOG_CORE
---help---
  This is the driver for the hardware watchdog on the ITE IT8620,
  IT8702, IT8712, IT8716, IT8718, IT8720, IT8721, IT8726 and IT8728
diff --git a/drivers/watchdog/it87_wdt.c b/drivers/watchdog/it87_wdt.c
index 8c847f8c2470..9a6523e70ffc 100644
--- a/drivers/watchdog/it87_wdt.c
+++ b/drivers/watchdog/it87_wdt.c
@@ -32,26 +32,18 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 
-
-#define WATCHDOG_VERSION   "1.14"
 #define WATCHDOG_NAME  "IT87 WDT"
-#define DRIVER_VERSION WATCHDOG_NAME " driver, v" WATCHDOG_VERSION "\n"
-#define WD_MAGIC   'V'
 
 /* Defaults for Module Parameter */
 #define DEFAULT_NOGAMEPORT 0
 #define DEFAULT_NOCIR  0
-#define DEFAULT_EXCLUSIVE  1
 #define DEFAULT_TIMEOUT60
 #define DEFAULT_TESTMODE   0
 #define DEFAULT_NOWAYOUT   WATCHDOG_NOWAYOUT
@@ -129,23 +121,17 @@
 #define GP_BASE_DEFAULT0x0201
 
 /* wdt_status */
-#define WDTS_TIMER_RUN 0
-#define WDTS_DEV_OPEN  1
-#define WDTS_KEEPALIVE 2
-#define WDTS_LOCKED3
-#define WDTS_USE_GP4
-#define WDTS_EXPECTED  5
-#define WDTS_USE_CIR   6
-
-static unsigned int base, gpact, ciract, max_units, chip_type;
-static unsigned long wdt_status;
-
-static int nogameport = DEFAULT_NOGAMEPORT;
-static int nocir  = DEFAULT_NOCIR;
-static int exclusive  = DEFAULT_EXCLUSIVE;
-static int timeout= DEFAULT_TIMEOUT;
-static int testmode   = DEFAULT_TESTMODE;
-static bool nowayout   = DEFAULT_NOWAYOUT;
+#define WDTS_USE_GP0
+#define WDTS_USE_CIR   1
+
+static unsigned int base, gpact, ciract, max_units, chip_type;
+static unsigned long wdt_status;
+
+static int nogameport  = DEFAULT_NOGAMEPORT;
+static int nocir   = DEFAULT_NOCIR;
+static unsigned int timeout = DEFAULT_TIMEOUT;
+static int testmode= DEFAULT_TESTMODE;
+static bool nowayout= DEFAULT_NOWAYOUT;
 
 module_param(nogameport, int, 0);
 MODULE_PARM_DESC(nogameport, "Forbid the activation of game port, default="
@@ -153,9 +139,6 @@ MODULE_PARM_DESC(nogameport, "Forbid the activation of game 
port, default="
 module_param(nocir, int, 0);
 MODULE_PARM_DESC(nocir, "Forbid the use of Consumer IR interrupts to reset 
timer, default="
__MODULE_STRING(DEFAULT_NOCIR));
-module_param(exclusive, int, 0);
-MODULE_PARM_DESC(exclusive, "Watchdog exclusive device open, default="
-   __MODULE_STRING(DEFAULT_EXCLUSIVE));
 module_param(timeout, int, 0);
 MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds, default="
__MODULE_STRING(DEFAULT_TIMEOUT));
@@ -227,7 +210,7 @@ static inline void superio_outw(int val, int reg)
 }
 
 /* Internal function, should be called after superio_select(GPIO) */
-static void wdt_update_timeout(void)
+static void _wdt_update_timeout(void)
 {
unsigned char cfg = WDT_KRST;
int tm = timeout;
@@ -249,6 +232,21 @@ static void wdt_update_timeout(void)
superio_outb(tm>>8, WDTVALMSB);
 }
 
+static int wdt_update_timeout(void)
+{
+   int ret;
+
+   ret = superio_enter();
+   if (ret)
+   return ret;
+
+   superio_select(GPIO);
+   _wdt_update_timeout();
+   superio_exit();
+
+   return 0;
+}
+
 static int wdt_round_time(int t)
 {
t += 59;
@@ -258,25 +256,22 @@ static int wdt_round_time(int t)
 
 /* watchdog timer handling */
 
-static void wdt_keepalive(void)
+static int wdt_keepalive(struct watchdog_device *wdd)
 {
+   int ret = 0;
+
if (test_bit(WDTS_USE_GP, _status))
inb(base);
else if (test_bit(WDTS_USE_CIR, _status))
/* The timer reloads with around 5 msec delay */
outb(0x55, CIR_DR(base));
-   else {
-   if (superio_enter())
-   return;
+   else
+   ret = wdt_update_timeout();
 
-   superio_select(GPIO);
-   wdt_update_timeout();
-   superio_exit();
-   }
-   set_bit(WDTS_KEEPALIVE, _status);
+   return ret;
 }
 
-static int wdt_start(void)
+static int wdt_start(struct watchdog_device *wdd)
 {
int ret = superio_enter();
if (ret)
@@ -287,14 +282,15 @@ static int wdt_start(void)
superio_outb(WDT_GAMEPORT, WDTCTRL);
else if (test_bit(WDTS_USE_CIR, _status))
superio_outb(WDT_CIRINT, 

[PATCH 4/5] watchdog: it87: Use infrastructure to stop watchdog on reboot

[Guenter Roeck]

Use watchdog_stop_on_reboot() to stop the watchdog on reboot instead
of registering a driver-specific notifier.

While at it, reorder remaining include files alphabetically.

Signed-off-by: Guenter Roeck 
---
 drivers/watchdog/it87_wdt.c | 34 +-
 1 file changed, 5 insertions(+), 29 deletions(-)

diff --git a/drivers/watchdog/it87_wdt.c b/drivers/watchdog/it87_wdt.c
index 29aea28628c8..07f4727eb7f4 100644
--- a/drivers/watchdog/it87_wdt.c
+++ b/drivers/watchdog/it87_wdt.c
@@ -28,15 +28,13 @@
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
+#include 
+#include 
+#include 
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
-#include 
-#include 
-#include 
 
 #define WATCHDOG_NAME  "IT87 WDT"
 
@@ -260,18 +258,6 @@ static struct watchdog_device wdt_dev = {
.min_timeout = 1,
 };
 
-static int wdt_notify_sys(struct notifier_block *this, unsigned long code,
- void *unused)
-{
-   if (code == SYS_DOWN || code == SYS_HALT)
-   wdt_stop(_dev);
-   return NOTIFY_DONE;
-}
-
-static struct notifier_block wdt_notifier = {
-   .notifier_call = wdt_notify_sys,
-};
-
 static int __init it87_wdt_init(void)
 {
u8  chip_rev;
@@ -338,32 +324,22 @@ static int __init it87_wdt_init(void)
wdt_dev.timeout = timeout;
wdt_dev.max_timeout = max_units * 60;
 
-   rc = register_reboot_notifier(_notifier);
-   if (rc) {
-   pr_err("Cannot register reboot notifier (err=%d)\n", rc);
-   return rc;
-   }
-
+   watchdog_stop_on_reboot(_dev);
rc = watchdog_register_device(_dev);
if (rc) {
pr_err("Cannot register watchdog device (err=%d)\n", rc);
-   goto err_out_reboot;
+   return rc;
}
 
pr_info("Chip IT%04x revision %d initialized. timeout=%d sec 
(nowayout=%d testmode=%d)\n",
chip_type, chip_rev, timeout, nowayout, testmode);
 
return 0;
-
-err_out_reboot:
-   unregister_reboot_notifier(_notifier);
-   return rc;
 }
 
 static void __exit it87_wdt_exit(void)
 {
watchdog_unregister_device(_dev);
-   unregister_reboot_notifier(_notifier);
 }
 
 module_init(it87_wdt_init);
-- 
2.7.4

[PATCH 3/5] watchdog: it87: Drop support for resetting watchdog though CIR and Game port

[Guenter Roeck]

Resetting the watchdog timer on CIR interrupts or on game port interrupts
is not not supported on recent chips, and doesn't really tell if the system
is stable. On top of that, at least the bit to enable resetting the
watchdog through the game port is used differently on recent chips.
Drop resetting the watchdog on CIR  or game port interrupts to simplify
the code.

Signed-off-by: Guenter Roeck 
---
 drivers/watchdog/Kconfig|   3 -
 drivers/watchdog/it87_wdt.c | 226 
 2 files changed, 19 insertions(+), 210 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 20020a4bb71e..793146be38e0 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1043,9 +1043,6 @@ config IT87_WDT
  IT8702, IT8712, IT8716, IT8718, IT8720, IT8721, IT8726 and IT8728
  Super I/O chips.
 
- If the driver does not work, then make sure that the game port in
- the BIOS is enabled.
-
  This watchdog simply watches your kernel to make sure it doesn't
  freeze, and if it does, it reboots your computer after a certain
  amount of time.
diff --git a/drivers/watchdog/it87_wdt.c b/drivers/watchdog/it87_wdt.c
index 9a6523e70ffc..29aea28628c8 100644
--- a/drivers/watchdog/it87_wdt.c
+++ b/drivers/watchdog/it87_wdt.c
@@ -33,7 +33,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -42,8 +41,6 @@
 #define WATCHDOG_NAME  "IT87 WDT"
 
 /* Defaults for Module Parameter */
-#define DEFAULT_NOGAMEPORT 0
-#define DEFAULT_NOCIR  0
 #define DEFAULT_TIMEOUT60
 #define DEFAULT_TESTMODE   0
 #define DEFAULT_NOWAYOUT   WATCHDOG_NOWAYOUT
@@ -54,15 +51,11 @@
 
 /* Logical device Numbers LDN */
 #define GPIO   0x07
-#define GAMEPORT   0x09
-#define CIR0x0a
 
 /* Configuration Registers and Functions */
 #define LDNREG 0x07
 #define CHIPID 0x20
 #define CHIPREV0x22
-#define ACTREG 0x30
-#define BASEREG0x60
 
 /* Chip Id numbers */
 #define NO_DEV_ID  0x
@@ -84,14 +77,6 @@
 #define WDTVALLSB  0x73
 #define WDTVALMSB  0x74
 
-/* GPIO Bits WDTCTRL */
-#define WDT_CIRINT 0x80
-#define WDT_MOUSEINT   0x40
-#define WDT_KYBINT 0x20
-#define WDT_GAMEPORT   0x10 /* not in it8718, it8720, it8721, it8728 */
-#define WDT_FORCE  0x02
-#define WDT_ZERO   0x01
-
 /* GPIO Bits WDTCFG */
 #define WDT_TOV1   0x80
 #define WDT_KRST   0x40
@@ -99,46 +84,12 @@
 #define WDT_PWROK  0x10 /* not in it8721 */
 #define WDT_INT_MASK   0x0f
 
-/* CIR Configuration Register LDN=0x0a */
-#define CIR_ILS0x70
-
-/* The default Base address is not always available, we use this */
-#define CIR_BASE   0x0208
-
-/* CIR Controller */
-#define CIR_DR(b)  (b)
-#define CIR_IER(b) (b + 1)
-#define CIR_RCR(b) (b + 2)
-#define CIR_TCR1(b)(b + 3)
-#define CIR_TCR2(b)(b + 4)
-#define CIR_TSR(b) (b + 5)
-#define CIR_RSR(b) (b + 6)
-#define CIR_BDLR(b)(b + 5)
-#define CIR_BDHR(b)(b + 6)
-#define CIR_IIR(b) (b + 7)
-
-/* Default Base address of Game port */
-#define GP_BASE_DEFAULT0x0201
+static unsigned int max_units, chip_type;
 
-/* wdt_status */
-#define WDTS_USE_GP0
-#define WDTS_USE_CIR   1
-
-static unsigned int base, gpact, ciract, max_units, chip_type;
-static unsigned long wdt_status;
-
-static int nogameport  = DEFAULT_NOGAMEPORT;
-static int nocir   = DEFAULT_NOCIR;
 static unsigned int timeout = DEFAULT_TIMEOUT;
-static int testmode= DEFAULT_TESTMODE;
-static bool nowayout= DEFAULT_NOWAYOUT;
-
-module_param(nogameport, int, 0);
-MODULE_PARM_DESC(nogameport, "Forbid the activation of game port, default="
-   __MODULE_STRING(DEFAULT_NOGAMEPORT));
-module_param(nocir, int, 0);
-MODULE_PARM_DESC(nocir, "Forbid the use of Consumer IR interrupts to reset 
timer, default="
-   __MODULE_STRING(DEFAULT_NOCIR));
+static int testmode = DEFAULT_TESTMODE;
+static bool nowayout = DEFAULT_NOWAYOUT;
+
 module_param(timeout, int, 0);
 MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds, default="
__MODULE_STRING(DEFAULT_TIMEOUT));
@@ -210,29 +161,28 @@ static inline void superio_outw(int val, int reg)
 }
 
 /* Internal function, should be called after superio_select(GPIO) */
-static void _wdt_update_timeout(void)
+static void _wdt_update_timeout(unsigned int t)
 {
unsigned char cfg = WDT_KRST;
-   int tm = timeout;
 
if (testmode)
cfg = 0;
 
-   if (tm <= max_units)
+   if (t <= max_units)
cfg |= WDT_TOV1;
else
-   tm /= 60;
+   t /= 60;
 
if (chip_type != IT8721_ID)
cfg |= WDT_PWROK;
 
superio_outb(cfg, WDTCFG);
-   superio_outb(tm, WDTVALLSB);
+   superio_outb(t, WDTVALLSB);
if (max_units > 255)
-

[PATCH 2/5] watchdog: it87: Convert to use watchdog core infrastructure

[Guenter Roeck]

Signed-off-by: Guenter Roeck 
---
 drivers/watchdog/Kconfig|   1 +
 drivers/watchdog/it87_wdt.c | 375 +---
 2 files changed, 72 insertions(+), 304 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 8b9049dac094..20020a4bb71e 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1037,6 +1037,7 @@ config IT8712F_WDT
 config IT87_WDT
tristate "IT87 Watchdog Timer"
depends on X86
+   select WATCHDOG_CORE
---help---
  This is the driver for the hardware watchdog on the ITE IT8620,
  IT8702, IT8712, IT8716, IT8718, IT8720, IT8721, IT8726 and IT8728
diff --git a/drivers/watchdog/it87_wdt.c b/drivers/watchdog/it87_wdt.c
index 8c847f8c2470..9a6523e70ffc 100644
--- a/drivers/watchdog/it87_wdt.c
+++ b/drivers/watchdog/it87_wdt.c
@@ -32,26 +32,18 @@
 #include 
 #include 
 #include 
-#include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
 #include 
 
-
-#define WATCHDOG_VERSION   "1.14"
 #define WATCHDOG_NAME  "IT87 WDT"
-#define DRIVER_VERSION WATCHDOG_NAME " driver, v" WATCHDOG_VERSION "\n"
-#define WD_MAGIC   'V'
 
 /* Defaults for Module Parameter */
 #define DEFAULT_NOGAMEPORT 0
 #define DEFAULT_NOCIR  0
-#define DEFAULT_EXCLUSIVE  1
 #define DEFAULT_TIMEOUT60
 #define DEFAULT_TESTMODE   0
 #define DEFAULT_NOWAYOUT   WATCHDOG_NOWAYOUT
@@ -129,23 +121,17 @@
 #define GP_BASE_DEFAULT0x0201
 
 /* wdt_status */
-#define WDTS_TIMER_RUN 0
-#define WDTS_DEV_OPEN  1
-#define WDTS_KEEPALIVE 2
-#define WDTS_LOCKED3
-#define WDTS_USE_GP4
-#define WDTS_EXPECTED  5
-#define WDTS_USE_CIR   6
-
-static unsigned int base, gpact, ciract, max_units, chip_type;
-static unsigned long wdt_status;
-
-static int nogameport = DEFAULT_NOGAMEPORT;
-static int nocir  = DEFAULT_NOCIR;
-static int exclusive  = DEFAULT_EXCLUSIVE;
-static int timeout= DEFAULT_TIMEOUT;
-static int testmode   = DEFAULT_TESTMODE;
-static bool nowayout   = DEFAULT_NOWAYOUT;
+#define WDTS_USE_GP0
+#define WDTS_USE_CIR   1
+
+static unsigned int base, gpact, ciract, max_units, chip_type;
+static unsigned long wdt_status;
+
+static int nogameport  = DEFAULT_NOGAMEPORT;
+static int nocir   = DEFAULT_NOCIR;
+static unsigned int timeout = DEFAULT_TIMEOUT;
+static int testmode= DEFAULT_TESTMODE;
+static bool nowayout= DEFAULT_NOWAYOUT;
 
 module_param(nogameport, int, 0);
 MODULE_PARM_DESC(nogameport, "Forbid the activation of game port, default="
@@ -153,9 +139,6 @@ MODULE_PARM_DESC(nogameport, "Forbid the activation of game 
port, default="
 module_param(nocir, int, 0);
 MODULE_PARM_DESC(nocir, "Forbid the use of Consumer IR interrupts to reset 
timer, default="
__MODULE_STRING(DEFAULT_NOCIR));
-module_param(exclusive, int, 0);
-MODULE_PARM_DESC(exclusive, "Watchdog exclusive device open, default="
-   __MODULE_STRING(DEFAULT_EXCLUSIVE));
 module_param(timeout, int, 0);
 MODULE_PARM_DESC(timeout, "Watchdog timeout in seconds, default="
__MODULE_STRING(DEFAULT_TIMEOUT));
@@ -227,7 +210,7 @@ static inline void superio_outw(int val, int reg)
 }
 
 /* Internal function, should be called after superio_select(GPIO) */
-static void wdt_update_timeout(void)
+static void _wdt_update_timeout(void)
 {
unsigned char cfg = WDT_KRST;
int tm = timeout;
@@ -249,6 +232,21 @@ static void wdt_update_timeout(void)
superio_outb(tm>>8, WDTVALMSB);
 }
 
+static int wdt_update_timeout(void)
+{
+   int ret;
+
+   ret = superio_enter();
+   if (ret)
+   return ret;
+
+   superio_select(GPIO);
+   _wdt_update_timeout();
+   superio_exit();
+
+   return 0;
+}
+
 static int wdt_round_time(int t)
 {
t += 59;
@@ -258,25 +256,22 @@ static int wdt_round_time(int t)
 
 /* watchdog timer handling */
 
-static void wdt_keepalive(void)
+static int wdt_keepalive(struct watchdog_device *wdd)
 {
+   int ret = 0;
+
if (test_bit(WDTS_USE_GP, _status))
inb(base);
else if (test_bit(WDTS_USE_CIR, _status))
/* The timer reloads with around 5 msec delay */
outb(0x55, CIR_DR(base));
-   else {
-   if (superio_enter())
-   return;
+   else
+   ret = wdt_update_timeout();
 
-   superio_select(GPIO);
-   wdt_update_timeout();
-   superio_exit();
-   }
-   set_bit(WDTS_KEEPALIVE, _status);
+   return ret;
 }
 
-static int wdt_start(void)
+static int wdt_start(struct watchdog_device *wdd)
 {
int ret = superio_enter();
if (ret)
@@ -287,14 +282,15 @@ static int wdt_start(void)
superio_outb(WDT_GAMEPORT, WDTCTRL);
else if (test_bit(WDTS_USE_CIR, _status))
superio_outb(WDT_CIRINT, WDTCTRL);
-   

[PATCH 5/5] watchdog: it87: Add support for various Super-IO chips

[Guenter Roeck]

Add support for IT8607, IT8622, IT8625, IT8628, IT8655, IT8665,
and IT8686.

Signed-off-by: Guenter Roeck 
---
 drivers/watchdog/Kconfig|  7 ---
 drivers/watchdog/it87_wdt.c | 19 +--
 2 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 793146be38e0..3b3a8f0e9b7b 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1039,9 +1039,10 @@ config IT87_WDT
depends on X86
select WATCHDOG_CORE
---help---
- This is the driver for the hardware watchdog on the ITE IT8620,
- IT8702, IT8712, IT8716, IT8718, IT8720, IT8721, IT8726 and IT8728
- Super I/O chips.
+ This is the driver for the hardware watchdog on the ITE IT8607,
+ IT8620, IT8622, IT8625, IT8628, IT8655, IT8665, IT8686, IT8702,
+ IT8712, IT8716, IT8718, IT8720, IT8721, IT8726, IT8728, and
+ IT8783 Super I/O chips.
 
  This watchdog simply watches your kernel to make sure it doesn't
  freeze, and if it does, it reboots your computer after a certain
diff --git a/drivers/watchdog/it87_wdt.c b/drivers/watchdog/it87_wdt.c
index 07f4727eb7f4..dd1e7eaef50f 100644
--- a/drivers/watchdog/it87_wdt.c
+++ b/drivers/watchdog/it87_wdt.c
@@ -12,8 +12,9 @@
  * http://www.ite.com.tw/
  *
  * Support of the watchdog timers, which are available on
- * IT8620, IT8702, IT8712, IT8716, IT8718, IT8720, IT8721, IT8726,
- * IT8728 and IT8783.
+ * IT8607, IT8620, IT8622, IT8625, IT8628, IT8655, IT8665, IT8686,
+ * IT8702, IT8712, IT8716, IT8718, IT8720, IT8721, IT8726, IT8728,
+ * and IT8783.
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -57,7 +58,14 @@
 
 /* Chip Id numbers */
 #define NO_DEV_ID  0x
+#define IT8607_ID  0x8607
 #define IT8620_ID  0x8620
+#define IT8622_ID  0x8622
+#define IT8625_ID  0x8625
+#define IT8628_ID  0x8628
+#define IT8655_ID  0x8655
+#define IT8665_ID  0x8665
+#define IT8686_ID  0x8686
 #define IT8702_ID  0x8702
 #define IT8705_ID  0x8705
 #define IT8712_ID  0x8712
@@ -282,7 +290,14 @@ static int __init it87_wdt_init(void)
case IT8726_ID:
max_units = 65535;
break;
+   case IT8607_ID:
case IT8620_ID:
+   case IT8622_ID:
+   case IT8625_ID:
+   case IT8628_ID:
+   case IT8655_ID:
+   case IT8665_ID:
+   case IT8686_ID:
case IT8718_ID:
case IT8720_ID:
case IT8721_ID:
-- 
2.7.4

[PATCH 1/5] watchdog: it87: Drop FSF mailing address

[Guenter Roeck]

The FSF mailing address may change. Drop it.

Signed-off-by: Guenter Roeck 
---
 drivers/watchdog/it87_wdt.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/watchdog/it87_wdt.c b/drivers/watchdog/it87_wdt.c
index b9878c41598f..8c847f8c2470 100644
--- a/drivers/watchdog/it87_wdt.c
+++ b/drivers/watchdog/it87_wdt.c
@@ -24,10 +24,6 @@
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-- 
2.7.4

[PATCH 5/5] watchdog: it87: Add support for various Super-IO chips

[Guenter Roeck]

Add support for IT8607, IT8622, IT8625, IT8628, IT8655, IT8665,
and IT8686.

Signed-off-by: Guenter Roeck 
---
 drivers/watchdog/Kconfig|  7 ---
 drivers/watchdog/it87_wdt.c | 19 +--
 2 files changed, 21 insertions(+), 5 deletions(-)

diff --git a/drivers/watchdog/Kconfig b/drivers/watchdog/Kconfig
index 793146be38e0..3b3a8f0e9b7b 100644
--- a/drivers/watchdog/Kconfig
+++ b/drivers/watchdog/Kconfig
@@ -1039,9 +1039,10 @@ config IT87_WDT
depends on X86
select WATCHDOG_CORE
---help---
- This is the driver for the hardware watchdog on the ITE IT8620,
- IT8702, IT8712, IT8716, IT8718, IT8720, IT8721, IT8726 and IT8728
- Super I/O chips.
+ This is the driver for the hardware watchdog on the ITE IT8607,
+ IT8620, IT8622, IT8625, IT8628, IT8655, IT8665, IT8686, IT8702,
+ IT8712, IT8716, IT8718, IT8720, IT8721, IT8726, IT8728, and
+ IT8783 Super I/O chips.
 
  This watchdog simply watches your kernel to make sure it doesn't
  freeze, and if it does, it reboots your computer after a certain
diff --git a/drivers/watchdog/it87_wdt.c b/drivers/watchdog/it87_wdt.c
index 07f4727eb7f4..dd1e7eaef50f 100644
--- a/drivers/watchdog/it87_wdt.c
+++ b/drivers/watchdog/it87_wdt.c
@@ -12,8 +12,9 @@
  * http://www.ite.com.tw/
  *
  * Support of the watchdog timers, which are available on
- * IT8620, IT8702, IT8712, IT8716, IT8718, IT8720, IT8721, IT8726,
- * IT8728 and IT8783.
+ * IT8607, IT8620, IT8622, IT8625, IT8628, IT8655, IT8665, IT8686,
+ * IT8702, IT8712, IT8716, IT8718, IT8720, IT8721, IT8726, IT8728,
+ * and IT8783.
  *
  * This program is free software; you can redistribute it and/or
  * modify it under the terms of the GNU General Public License
@@ -57,7 +58,14 @@
 
 /* Chip Id numbers */
 #define NO_DEV_ID  0x
+#define IT8607_ID  0x8607
 #define IT8620_ID  0x8620
+#define IT8622_ID  0x8622
+#define IT8625_ID  0x8625
+#define IT8628_ID  0x8628
+#define IT8655_ID  0x8655
+#define IT8665_ID  0x8665
+#define IT8686_ID  0x8686
 #define IT8702_ID  0x8702
 #define IT8705_ID  0x8705
 #define IT8712_ID  0x8712
@@ -282,7 +290,14 @@ static int __init it87_wdt_init(void)
case IT8726_ID:
max_units = 65535;
break;
+   case IT8607_ID:
case IT8620_ID:
+   case IT8622_ID:
+   case IT8625_ID:
+   case IT8628_ID:
+   case IT8655_ID:
+   case IT8665_ID:
+   case IT8686_ID:
case IT8718_ID:
case IT8720_ID:
case IT8721_ID:
-- 
2.7.4

[PATCH 1/5] watchdog: it87: Drop FSF mailing address

[Guenter Roeck]

The FSF mailing address may change. Drop it.

Signed-off-by: Guenter Roeck 
---
 drivers/watchdog/it87_wdt.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/watchdog/it87_wdt.c b/drivers/watchdog/it87_wdt.c
index b9878c41598f..8c847f8c2470 100644
--- a/drivers/watchdog/it87_wdt.c
+++ b/drivers/watchdog/it87_wdt.c
@@ -24,10 +24,6 @@
  * but WITHOUT ANY WARRANTY; without even the implied warranty of
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
-- 
2.7.4

RE: [PATCH v1 2/3] gpio: Add support for TPS68470 GPIOs

[Mani, Rajmohan]

Hi Andy,

Thanks for the reviews and patience.

> 
> On Tue, Jun 6, 2017 at 2:55 PM, Rajmohan Mani 
> wrote:
> > This patch adds support for TPS68470 GPIOs.
> > There are 7 GPIOs and a few sensor related GPIOs.
> > These GPIOs can be requested and configured as appropriate.
> 
> Besides my below comments, just put it here that I recommended earlier to
> provide 2 GPIO chips (one per bank of GPIOs).
> It's up to Linus to decide since you didn't follow the recommendation.
> 

Ack.
Did you mean to add this in Kconfig or this source file?

Here's some more details on these GPIOs.
Each of these 7 GPIOs has 2 registers to control the mode, level, drive 
strength, polarity, hysteresis control among other things. Also there are GPDI 
and GPDO registers to control the input and output values of these 7 GPIOs. 
These GPIOs are numbered 0 through 6.
The remaining 3 GPIOs are more of special purpose GPIOs that are output only, 
with one register to control all of their output values and drive strengths. 
These GPIOs are named with a special purpose (ENABLE, IDLE and RESET of the 
sensor).

> > +#include 
> > +#include 
> 
> These shouldn't be in the driver.
> Instead use
> #include 
> 

Ack

> > +#include 
> > +#include 
> > +#include 
> 
> > +   if (offset >= TPS68470_N_REGULAR_GPIO) {
> > +   offset -= TPS68470_N_REGULAR_GPIO;
> > +   reg = TPS68470_REG_SGPO;
> > +   }
> 
> Two GPIO chips makes this gone.
> 

Ack.
On a closer look, creating two GPIO chips makes things clearer. 
But, this comes at the cost of a new set of gpio_get/set, 
gpio_output/input functions for the new GPIO chip. This results in 
new code for the second GPIO chip, which is pretty much 
going to be the copy of first GPIO chip, except for initializing 
the "reg" variable with GPDO or SGPO register. If we decide to 
reuse the existing code of the first GPIO chip for the new/second 
GPIO chip, we would still need to add a check, which would be 
effectively the same as the existing code, with the only advantage 
of not having to initialize the "offset" variable (which holds the 
GPIO offset). Given the above, it seems ok to retain the existing 
model of a single chip with the adjustments for offset, reg 
variables per the GPIO offset, to keep the whole picture simple.

> > +struct gpiod_lookup_table gpios_table = {
> > +   .dev_id = NULL,
> > +   .table = {
> > + GPIO_LOOKUP("tps68470-gpio", 0, "gpio.0", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 1, "gpio.1", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 2, "gpio.2", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 3, "gpio.3", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 4, "gpio.4", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 5, "gpio.5", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 6, "gpio.6", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 7, "s_enable",
> GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 8, "s_idle", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 9, "s_resetn",
> GPIO_ACTIVE_HIGH),
> > + {},
> > +   },
> > +};
> 
> This doesn't belong to the driver.
> 

Ack
I have moved this code to the MFD driver

> > +static int tps68470_gpio_probe(struct platform_device *pdev) {
> > +   struct tps68470 *tps68470 = dev_get_drvdata(pdev->dev.parent);
> > +   struct tps68470_gpio_data *tps68470_gpio;
> 
> > +   int i, ret;
> 
> unsingned int i;
> 
> > +   ret = gpiochip_add(_gpio->gc);
> 
> devm_ ?
> 

Ack

> > +   gpiod_add_lookup_table(_table);
> 
> Doesn't belong to the driver either.
> I suppose it's a part of MFD (patch 1)
> 

Ack

> > +   /*
> > +* Initialize all the GPIOs to 0, just to make sure all
> > +* GPIOs start with known default values. This protects against
> > +* any GPIOs getting set with a value of 1, after TPS68470
> > + reset
> 
> So, this is hardware bug. Right? Or misconfiguration of the chip we may avoid?
> 

The tps68470 PMIC upon reset, does not have the "power on reset" values.
We just initialize the GPIOs with their known default values.

> > +*/
> > +   for (i = 0; i < tps68470_gpio->gc.ngpio; i++)
> > +   tps68470_gpio_set(_gpio->gc, i, 0);
> > +
> > +   return ret;
> > +}
> 
> > +
> > +static int tps68470_gpio_remove(struct platform_device *pdev) {
> > +   struct tps68470_gpio_data *tps68470_gpio =
> > +platform_get_drvdata(pdev);
> > +
> > +   gpiod_remove_lookup_table(_table);
> > +   gpiochip_remove(_gpio->gc);
> > +
> > +   return 0;
> > +}
> 
> Should gone after devm_ in use.
> 

Ack

RE: [PATCH v1 2/3] gpio: Add support for TPS68470 GPIOs

[Mani, Rajmohan]

Hi Andy,

Thanks for the reviews and patience.

> 
> On Tue, Jun 6, 2017 at 2:55 PM, Rajmohan Mani 
> wrote:
> > This patch adds support for TPS68470 GPIOs.
> > There are 7 GPIOs and a few sensor related GPIOs.
> > These GPIOs can be requested and configured as appropriate.
> 
> Besides my below comments, just put it here that I recommended earlier to
> provide 2 GPIO chips (one per bank of GPIOs).
> It's up to Linus to decide since you didn't follow the recommendation.
> 

Ack.
Did you mean to add this in Kconfig or this source file?

Here's some more details on these GPIOs.
Each of these 7 GPIOs has 2 registers to control the mode, level, drive 
strength, polarity, hysteresis control among other things. Also there are GPDI 
and GPDO registers to control the input and output values of these 7 GPIOs. 
These GPIOs are numbered 0 through 6.
The remaining 3 GPIOs are more of special purpose GPIOs that are output only, 
with one register to control all of their output values and drive strengths. 
These GPIOs are named with a special purpose (ENABLE, IDLE and RESET of the 
sensor).

> > +#include 
> > +#include 
> 
> These shouldn't be in the driver.
> Instead use
> #include 
> 

Ack

> > +#include 
> > +#include 
> > +#include 
> 
> > +   if (offset >= TPS68470_N_REGULAR_GPIO) {
> > +   offset -= TPS68470_N_REGULAR_GPIO;
> > +   reg = TPS68470_REG_SGPO;
> > +   }
> 
> Two GPIO chips makes this gone.
> 

Ack.
On a closer look, creating two GPIO chips makes things clearer. 
But, this comes at the cost of a new set of gpio_get/set, 
gpio_output/input functions for the new GPIO chip. This results in 
new code for the second GPIO chip, which is pretty much 
going to be the copy of first GPIO chip, except for initializing 
the "reg" variable with GPDO or SGPO register. If we decide to 
reuse the existing code of the first GPIO chip for the new/second 
GPIO chip, we would still need to add a check, which would be 
effectively the same as the existing code, with the only advantage 
of not having to initialize the "offset" variable (which holds the 
GPIO offset). Given the above, it seems ok to retain the existing 
model of a single chip with the adjustments for offset, reg 
variables per the GPIO offset, to keep the whole picture simple.

> > +struct gpiod_lookup_table gpios_table = {
> > +   .dev_id = NULL,
> > +   .table = {
> > + GPIO_LOOKUP("tps68470-gpio", 0, "gpio.0", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 1, "gpio.1", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 2, "gpio.2", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 3, "gpio.3", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 4, "gpio.4", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 5, "gpio.5", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 6, "gpio.6", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 7, "s_enable",
> GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 8, "s_idle", 
> > GPIO_ACTIVE_HIGH),
> > + GPIO_LOOKUP("tps68470-gpio", 9, "s_resetn",
> GPIO_ACTIVE_HIGH),
> > + {},
> > +   },
> > +};
> 
> This doesn't belong to the driver.
> 

Ack
I have moved this code to the MFD driver

> > +static int tps68470_gpio_probe(struct platform_device *pdev) {
> > +   struct tps68470 *tps68470 = dev_get_drvdata(pdev->dev.parent);
> > +   struct tps68470_gpio_data *tps68470_gpio;
> 
> > +   int i, ret;
> 
> unsingned int i;
> 
> > +   ret = gpiochip_add(_gpio->gc);
> 
> devm_ ?
> 

Ack

> > +   gpiod_add_lookup_table(_table);
> 
> Doesn't belong to the driver either.
> I suppose it's a part of MFD (patch 1)
> 

Ack

> > +   /*
> > +* Initialize all the GPIOs to 0, just to make sure all
> > +* GPIOs start with known default values. This protects against
> > +* any GPIOs getting set with a value of 1, after TPS68470
> > + reset
> 
> So, this is hardware bug. Right? Or misconfiguration of the chip we may avoid?
> 

The tps68470 PMIC upon reset, does not have the "power on reset" values.
We just initialize the GPIOs with their known default values.

> > +*/
> > +   for (i = 0; i < tps68470_gpio->gc.ngpio; i++)
> > +   tps68470_gpio_set(_gpio->gc, i, 0);
> > +
> > +   return ret;
> > +}
> 
> > +
> > +static int tps68470_gpio_remove(struct platform_device *pdev) {
> > +   struct tps68470_gpio_data *tps68470_gpio =
> > +platform_get_drvdata(pdev);
> > +
> > +   gpiod_remove_lookup_table(_table);
> > +   gpiochip_remove(_gpio->gc);
> > +
> > +   return 0;
> > +}
> 
> Should gone after devm_ in use.
> 

Ack

Re: [PATCH net-next 6/9] net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC

[Andrew Lunn]

> > +int hclge_mac_mdio_config(struct hclge_dev *hdev)
> > +{
> > +   struct hclge_mac *mac = >hw.mac;
> > +   struct mii_bus *mdio_bus;
> > +   struct net_device *ndev = >ndev;
> > +   struct phy_device *phy;
> > +   bool is_c45;
> > +   int ret;
> > +
> > +   if (hdev->hw.mac.phy_addr >= PHY_MAX_ADDR)
> > +   return 0;
> > +
> > +   if (hdev->hw.mac.phy_if == PHY_INTERFACE_MODE_NA)
> > +   return 0;
> > +   else if (mac->phy_if == PHY_INTERFACE_MODE_SGMII)
> > +   is_c45 = 0;
> > +   else if (mac->phy_if == PHY_INTERFACE_MODE_XGMII)
> > +   is_c45 = 1;
> > +   else
> > +   return -ENODATA;
> 
> Can you consider using a switch () case statement here?

Does this concept even make sense? The Marvell 10G phy will use SGMII
for 10/100/1000Mbs and swap to XGMII for 10Gbps. It however stays a
c45 device all the time.

In general, i don't think PHY mode is related to C22/C45.

   Andrew

Re: [PATCH net-next 6/9] net: hns3: Add MDIO support to HNS3 Ethernet driver for hip08 SoC

[Andrew Lunn]

> > +int hclge_mac_mdio_config(struct hclge_dev *hdev)
> > +{
> > +   struct hclge_mac *mac = >hw.mac;
> > +   struct mii_bus *mdio_bus;
> > +   struct net_device *ndev = >ndev;
> > +   struct phy_device *phy;
> > +   bool is_c45;
> > +   int ret;
> > +
> > +   if (hdev->hw.mac.phy_addr >= PHY_MAX_ADDR)
> > +   return 0;
> > +
> > +   if (hdev->hw.mac.phy_if == PHY_INTERFACE_MODE_NA)
> > +   return 0;
> > +   else if (mac->phy_if == PHY_INTERFACE_MODE_SGMII)
> > +   is_c45 = 0;
> > +   else if (mac->phy_if == PHY_INTERFACE_MODE_XGMII)
> > +   is_c45 = 1;
> > +   else
> > +   return -ENODATA;
> 
> Can you consider using a switch () case statement here?

Does this concept even make sense? The Marvell 10G phy will use SGMII
for 10/100/1000Mbs and swap to XGMII for 10Gbps. It however stays a
c45 device all the time.

In general, i don't think PHY mode is related to C22/C45.

   Andrew

Re: [PATCH 08/44] xen-swiotlb: implement ->mapping_error

[Konrad Rzeszutek Wilk]

On Thu, Jun 08, 2017 at 03:25:33PM +0200, Christoph Hellwig wrote:
> DMA_ERROR_CODE is going to go away, so don't rely on it.

Reviewed-by: Konrad Rzeszutek Wilk 

Re: [PATCH 07/44] xen-swiotlb: consolidate xen_swiotlb_dma_ops

[Konrad Rzeszutek Wilk]

On Thu, Jun 08, 2017 at 03:25:32PM +0200, Christoph Hellwig wrote:
> ARM and x86 had duplicated versions of the dma_ops structure, the
> only difference is that x86 hasn't wired up the set_dma_mask,
> mmap, and get_sgtable ops yet.  On x86 all of them are identical
> to the generic version, so they aren't needed but harmless.
> 
> All the symbols used only for xen_swiotlb_dma_ops can now be marked
> static as well.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/arm/xen/mm.c  | 17 
>  arch/x86/xen/pci-swiotlb-xen.c | 14 ---
>  drivers/xen/swiotlb-xen.c  | 93 
> ++
>  include/xen/swiotlb-xen.h  | 62 +---
>  4 files changed, 49 insertions(+), 137 deletions(-)

Yeeey!

Reviewed-by: Konrad Rzeszutek Wilk 

Re: [PATCH 08/44] xen-swiotlb: implement ->mapping_error

[Konrad Rzeszutek Wilk]

On Thu, Jun 08, 2017 at 03:25:33PM +0200, Christoph Hellwig wrote:
> DMA_ERROR_CODE is going to go away, so don't rely on it.

Reviewed-by: Konrad Rzeszutek Wilk 

Re: [PATCH 07/44] xen-swiotlb: consolidate xen_swiotlb_dma_ops

[Konrad Rzeszutek Wilk]

On Thu, Jun 08, 2017 at 03:25:32PM +0200, Christoph Hellwig wrote:
> ARM and x86 had duplicated versions of the dma_ops structure, the
> only difference is that x86 hasn't wired up the set_dma_mask,
> mmap, and get_sgtable ops yet.  On x86 all of them are identical
> to the generic version, so they aren't needed but harmless.
> 
> All the symbols used only for xen_swiotlb_dma_ops can now be marked
> static as well.
> 
> Signed-off-by: Christoph Hellwig 
> ---
>  arch/arm/xen/mm.c  | 17 
>  arch/x86/xen/pci-swiotlb-xen.c | 14 ---
>  drivers/xen/swiotlb-xen.c  | 93 
> ++
>  include/xen/swiotlb-xen.h  | 62 +---
>  4 files changed, 49 insertions(+), 137 deletions(-)

Yeeey!

Reviewed-by: Konrad Rzeszutek Wilk 

Re: [PATCH v2 0/3] Add more algorithms and some misc cleanups

[George Cherian]

Hi Herbert,

Ping on this series

Regards,
-George Cherian

On Thu, May 4, 2017 at 5:04 PM, George Cherian
 wrote:
> This series adds more algorithm support for CPT.
> Add support for
> -ecb(aes)
> -cfb(aes)
> -ecb(des3_ede)
>
> Some cleanups too.
>
> George Cherian (3):
>   crypto: cavium: Downgrade the annoying misc interrupt print from
> dev_err to dev_dbg
>   crypto: cavium: Remove the individual encrypt/decrypt function for
> each algorithm
>   crypto: cavium: Add more algorithms
>
>  drivers/crypto/cavium/cpt/cptvf_algs.c | 234 
> ++---
>  drivers/crypto/cavium/cpt/cptvf_algs.h |   7 +
>  drivers/crypto/cavium/cpt/cptvf_main.c |   2 +-
>  3 files changed, 165 insertions(+), 78 deletions(-)
>
> --
> 2.1.4
>

Re: [PATCH v2 0/3] Add more algorithms and some misc cleanups

[George Cherian]

Hi Herbert,

Ping on this series

Regards,
-George Cherian

On Thu, May 4, 2017 at 5:04 PM, George Cherian
 wrote:
> This series adds more algorithm support for CPT.
> Add support for
> -ecb(aes)
> -cfb(aes)
> -ecb(des3_ede)
>
> Some cleanups too.
>
> George Cherian (3):
>   crypto: cavium: Downgrade the annoying misc interrupt print from
> dev_err to dev_dbg
>   crypto: cavium: Remove the individual encrypt/decrypt function for
> each algorithm
>   crypto: cavium: Add more algorithms
>
>  drivers/crypto/cavium/cpt/cptvf_algs.c | 234 
> ++---
>  drivers/crypto/cavium/cpt/cptvf_algs.h |   7 +
>  drivers/crypto/cavium/cpt/cptvf_main.c |   2 +-
>  3 files changed, 165 insertions(+), 78 deletions(-)
>
> --
> 2.1.4
>

[GIT PULL] hexagon fix for v4.12-rc5

[Guenter Roeck]

Hi Linus,

Please consider pulling a hexagon fix for Linux v4.12-rc5 from signed tag:

git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
hexagon-for-linus-v4.12-rc5

This patch fixes a build error seen when building hexagon images.
Richard sent me an Ack, but didn't reply when asked if he wants me
to send the patch to you directly, so I figured I'd just do it.

Thanks,
Guenter
--

The following changes since commit 5faab9e0f03c4eef97886b45436015e107f79f5f:

  Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2017-06-10 11:09:23 
-0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
tags/hexagon-for-linus-v4.12-rc5

for you to fetch changes up to 4d801cca0bb7011699c2d29f0139902dcfb3482d:

  hexagon: Use raw_copy_to_user (2017-06-10 19:10:31 -0700)


Fix hexagon build error


Guenter Roeck (1):
  hexagon: Use raw_copy_to_user

 arch/hexagon/mm/uaccess.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

[GIT PULL] hexagon fix for v4.12-rc5

[Guenter Roeck]

Hi Linus,

Please consider pulling a hexagon fix for Linux v4.12-rc5 from signed tag:

git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
hexagon-for-linus-v4.12-rc5

This patch fixes a build error seen when building hexagon images.
Richard sent me an Ack, but didn't reply when asked if he wants me
to send the patch to you directly, so I figured I'd just do it.

Thanks,
Guenter
--

The following changes since commit 5faab9e0f03c4eef97886b45436015e107f79f5f:

  Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs (2017-06-10 11:09:23 
-0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging.git 
tags/hexagon-for-linus-v4.12-rc5

for you to fetch changes up to 4d801cca0bb7011699c2d29f0139902dcfb3482d:

  hexagon: Use raw_copy_to_user (2017-06-10 19:10:31 -0700)


Fix hexagon build error


Guenter Roeck (1):
  hexagon: Use raw_copy_to_user

 arch/hexagon/mm/uaccess.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

Re: [PATCH] mm, memory_hotplug: support movable_node for hotplugable nodes

[Wei Yang]

On Thu, Jun 08, 2017 at 02:23:18PM +0200, Michal Hocko wrote:
>From: Michal Hocko 
>
>movable_node kernel parameter allows to make hotplugable NUMA
>nodes to put all the hotplugable memory into movable zone which
>allows more or less reliable memory hotremove.  At least this
>is the case for the NUMA nodes present during the boot (see
>find_zone_movable_pfns_for_nodes).
>
>This is not the case for the memory hotplug, though.
>
>   echo online > /sys/devices/system/memory/memoryXYZ/status
>
>will default to a kernel zone (usually ZONE_NORMAL) unless the
>particular memblock is already in the movable zone range which is not
>the case normally when onlining the memory from the udev rule context
>for a freshly hotadded NUMA node. The only option currently is to have a
>special udev rule to echo online_movable to all memblocks belonging to
>such a node which is rather clumsy. Not the mention this is inconsistent
>as well because what ended up in the movable zone during the boot will
>end up in a kernel zone after hotremove & hotadd without special care.
>

A kernel zone here means? Which is the counterpart in zone_type? or a
combination of several zone_type?


-- 
Wei Yang
Help you, Help me


signature.asc
Description: PGP signature

Re: [PATCH] mm, memory_hotplug: support movable_node for hotplugable nodes

[Wei Yang]

On Thu, Jun 08, 2017 at 02:23:18PM +0200, Michal Hocko wrote:
>From: Michal Hocko 
>
>movable_node kernel parameter allows to make hotplugable NUMA
>nodes to put all the hotplugable memory into movable zone which
>allows more or less reliable memory hotremove.  At least this
>is the case for the NUMA nodes present during the boot (see
>find_zone_movable_pfns_for_nodes).
>
>This is not the case for the memory hotplug, though.
>
>   echo online > /sys/devices/system/memory/memoryXYZ/status
>
>will default to a kernel zone (usually ZONE_NORMAL) unless the
>particular memblock is already in the movable zone range which is not
>the case normally when onlining the memory from the udev rule context
>for a freshly hotadded NUMA node. The only option currently is to have a
>special udev rule to echo online_movable to all memblocks belonging to
>such a node which is rather clumsy. Not the mention this is inconsistent
>as well because what ended up in the movable zone during the boot will
>end up in a kernel zone after hotremove & hotadd without special care.
>

A kernel zone here means? Which is the counterpart in zone_type? or a
combination of several zone_type?


-- 
Wei Yang
Help you, Help me


signature.asc
Description: PGP signature

[GIT PULL] AppArmor for 4.13

[John Johansen]

Hi James,

Here is the apparmor pull request for 4.13

It contains
* several bug fixes and cleanups
* the patch to add symlink support to securityfs that was floated on
  the list earlier and the apparmorfs changes that make use of
  securityfs symlinks
* it introduces the domain labeling base code that Ubuntu has been
  carrying for several years, with several cleanups applied. And it
  converts the current mediation over to using the domain labeling
  base, which brings domain stacking support with it. This finally
  will bring the base upstream code in line with Ubuntu and provide a
  base to upstream the new feature work that Ubuntu carries.

This request does not contain any of the newer apparmor mediation
features/controls (mount, signals, network, keys, ...) that Ubuntu is
currently carrying, all of which will be RFC'd on top of this.


The following changes since commit d68c51e0b377838dd31b37707813bb62089f399c:

  Sync to mainline for security submaintainers to work against (2017-05-22 
16:32:40 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor for-security

for you to fetch changes up to 33f2eadabba59cf1c763c46c4470279ec2054099:

  apparmor: export that basic profile namespaces are supported (2017-06-10 
17:11:48 -0700)


Dan Carpenter (1):
  apparmor: Fix error cod in __aa_fs_profile_mkdir()

John Johansen (59):
  apparmor: move file context into file.h
  apparmor: make internal lib fn skipn_spaces available to the rest of 
apparmor
  apparmor: allow profiles to provide info to disconnected paths
  apparmor: Move path lookup to using preallocated buffers
  securityfs: add the ability to support symlinks
  apparmor: move to per loaddata files, instead of replicating in profiles
  apparmor: use macro template to simplify profile seq_files
  apparmor: use macro template to simplify namespace seq_files
  apparmor: add custom apparmorfs that will be used by policy namespace 
files
  apparmor: rename apparmor file fns and data to indicate use
  apparmor: allow specifying an already created dir to create ns entries in
  apparmor: convert from securityfs to apparmorfs for policy ns files
  apparmor: move permissions into their own file to be more easily shared
  apparmor: rework perm mapping to a slightly broader set
  apparmor: provide finer control over policy management
  apparmor: add policy revision file interface
  apparmor: add mkdir/rmdir interface to manage policy namespaces
  apparmor: add label data availability to the feature set
  apparmor: speed up transactional queries
  apparmor: add fn to test if profile supports a given mediation class
  apparmor: add gerneric permissions struct and support fns
  apparmor: switch from file_perms to aa_perms
  apparmor: add profile permission query ability
  apparmor: provide information about path buffer size at boot
  apparmor: cleanup __find_child()
  apparmor: add namespace lookup fns()
  apparmor: fix policy load/remove semantics
  apparmor: fix apparmor_query data
  apparmor: fix display of ns name
  apparmor: move bprm_committing_creds/committed_creds to lsm.c
  apparmor: convert to profile block critical sections
  apparmor: share profile name on replacement
  apparmor: refactor updating profiles to the newest parent
  apparmor: cleanup remove unused and not fully implemented profile rename
  apparmor: convert aa_change_XXX bool parameters to flags
  apparmor: cleanup rename XXX_file_context() to XXX_file_ctx()
  apparmor: revalidate files during exec
  apparmor: add the base fns() for domain labels
  apparmor: switch from profiles to using labels on contexts
  apparmor: switch getprocattr to using label_print fns()
  apparmor: update query interface to support label queries
  apparmor: move capability checks to using labels
  apparmor: move resource checks to using labels
  apparmor: add cross check permission helper macros
  apparmor: move ptrace checks to using labels
  apparmor: allow ptrace checks to be finer grained than just capability
  apparmor: move aa_file_perm() to use labels
  apparmor: update aa_audit_file() to use labels
  apparmor: refactor path name lookup and permission checks around labels
  apparmor: move path_link mediation to using labels
  apparmor: rework file permission to cache file access in file->ctx
  apparmor: mediate files when they are received
  apparmor: support v7 transition format compatible with label_parse
  apparmor: move exec domain mediation to using labels
  apparmor: move change_hat mediation to using labels
  apparmor: move change_profile mediation to using labels
  apparmor: add domain label stacking info to apparmorfs
  apparmor: add stacked 

[GIT PULL] AppArmor for 4.13

[John Johansen]

Hi James,

Here is the apparmor pull request for 4.13

It contains
* several bug fixes and cleanups
* the patch to add symlink support to securityfs that was floated on
  the list earlier and the apparmorfs changes that make use of
  securityfs symlinks
* it introduces the domain labeling base code that Ubuntu has been
  carrying for several years, with several cleanups applied. And it
  converts the current mediation over to using the domain labeling
  base, which brings domain stacking support with it. This finally
  will bring the base upstream code in line with Ubuntu and provide a
  base to upstream the new feature work that Ubuntu carries.

This request does not contain any of the newer apparmor mediation
features/controls (mount, signals, network, keys, ...) that Ubuntu is
currently carrying, all of which will be RFC'd on top of this.


The following changes since commit d68c51e0b377838dd31b37707813bb62089f399c:

  Sync to mainline for security submaintainers to work against (2017-05-22 
16:32:40 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/jj/linux-apparmor for-security

for you to fetch changes up to 33f2eadabba59cf1c763c46c4470279ec2054099:

  apparmor: export that basic profile namespaces are supported (2017-06-10 
17:11:48 -0700)


Dan Carpenter (1):
  apparmor: Fix error cod in __aa_fs_profile_mkdir()

John Johansen (59):
  apparmor: move file context into file.h
  apparmor: make internal lib fn skipn_spaces available to the rest of 
apparmor
  apparmor: allow profiles to provide info to disconnected paths
  apparmor: Move path lookup to using preallocated buffers
  securityfs: add the ability to support symlinks
  apparmor: move to per loaddata files, instead of replicating in profiles
  apparmor: use macro template to simplify profile seq_files
  apparmor: use macro template to simplify namespace seq_files
  apparmor: add custom apparmorfs that will be used by policy namespace 
files
  apparmor: rename apparmor file fns and data to indicate use
  apparmor: allow specifying an already created dir to create ns entries in
  apparmor: convert from securityfs to apparmorfs for policy ns files
  apparmor: move permissions into their own file to be more easily shared
  apparmor: rework perm mapping to a slightly broader set
  apparmor: provide finer control over policy management
  apparmor: add policy revision file interface
  apparmor: add mkdir/rmdir interface to manage policy namespaces
  apparmor: add label data availability to the feature set
  apparmor: speed up transactional queries
  apparmor: add fn to test if profile supports a given mediation class
  apparmor: add gerneric permissions struct and support fns
  apparmor: switch from file_perms to aa_perms
  apparmor: add profile permission query ability
  apparmor: provide information about path buffer size at boot
  apparmor: cleanup __find_child()
  apparmor: add namespace lookup fns()
  apparmor: fix policy load/remove semantics
  apparmor: fix apparmor_query data
  apparmor: fix display of ns name
  apparmor: move bprm_committing_creds/committed_creds to lsm.c
  apparmor: convert to profile block critical sections
  apparmor: share profile name on replacement
  apparmor: refactor updating profiles to the newest parent
  apparmor: cleanup remove unused and not fully implemented profile rename
  apparmor: convert aa_change_XXX bool parameters to flags
  apparmor: cleanup rename XXX_file_context() to XXX_file_ctx()
  apparmor: revalidate files during exec
  apparmor: add the base fns() for domain labels
  apparmor: switch from profiles to using labels on contexts
  apparmor: switch getprocattr to using label_print fns()
  apparmor: update query interface to support label queries
  apparmor: move capability checks to using labels
  apparmor: move resource checks to using labels
  apparmor: add cross check permission helper macros
  apparmor: move ptrace checks to using labels
  apparmor: allow ptrace checks to be finer grained than just capability
  apparmor: move aa_file_perm() to use labels
  apparmor: update aa_audit_file() to use labels
  apparmor: refactor path name lookup and permission checks around labels
  apparmor: move path_link mediation to using labels
  apparmor: rework file permission to cache file access in file->ctx
  apparmor: mediate files when they are received
  apparmor: support v7 transition format compatible with label_parse
  apparmor: move exec domain mediation to using labels
  apparmor: move change_hat mediation to using labels
  apparmor: move change_profile mediation to using labels
  apparmor: add domain label stacking info to apparmorfs
  apparmor: add stacked 

[rcu:rcu/next 66/109] kernel/rcu/srcu.c:516:15: error: redefinition of 'srcu_batches_completed'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
rcu/next
head:   0d02a83770da1e677b09192a22ae93a9788badcd
commit: 5a0465e17a18c467b712a816985b7b8dd8d10c16 [66/109] srcu: Shrink srcu.h 
by moving docbook and private function
config: mn10300-allmodconfig (attached as .config)
compiler: am33_2.0-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 5a0465e17a18c467b712a816985b7b8dd8d10c16
# save the attached .config to linux build tree
make.cross ARCH=mn10300 

Note: the rcu/rcu/next HEAD 0d02a83770da1e677b09192a22ae93a9788badcd builds 
fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> kernel/rcu/srcu.c:516:15: error: redefinition of 'srcu_batches_completed'
unsigned long srcu_batches_completed(struct srcu_struct *sp)
  ^~
   In file included from kernel/rcu/srcu.c:39:0:
   kernel/rcu/rcu.h:495:29: note: previous definition of 
'srcu_batches_completed' was here
static inline unsigned long srcu_batches_completed(struct srcu_struct *sp)
^~

vim +/srcu_batches_completed +516 kernel/rcu/srcu.c

621934ee kernel/srcu.c Paul E. McKenney 2006-10-04  510   * 
srcu_batches_completed - return batches completed.
621934ee kernel/srcu.c Paul E. McKenney 2006-10-04  511   * @sp: 
srcu_struct on which to report batch completion.
621934ee kernel/srcu.c Paul E. McKenney 2006-10-04  512   *
621934ee kernel/srcu.c Paul E. McKenney 2006-10-04  513   * Report the 
number of batches, correlated with, but not necessarily
621934ee kernel/srcu.c Paul E. McKenney 2006-10-04  514   * precisely the 
same as, the number of grace periods that have elapsed.
621934ee kernel/srcu.c Paul E. McKenney 2006-10-04  515   */
a5c198f4 kernel/rcu/srcu.c Paul E. McKenney 2014-11-23 @516  unsigned long 
srcu_batches_completed(struct srcu_struct *sp)
621934ee kernel/srcu.c Paul E. McKenney 2006-10-04  517  {
621934ee kernel/srcu.c Paul E. McKenney 2006-10-04  518 return 
sp->completed;
621934ee kernel/srcu.c Paul E. McKenney 2006-10-04  519  }

:: The code at line 516 was first introduced by commit
:: a5c198f4f7da6cc48116ca239c59c9f44b753364 rcu: Expand SRCU ->completed to 
64 bits

:: TO: Paul E. McKenney 
:: CC: Paul E. McKenney 

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


.config.gz
Description: application/gzip

[rcu:rcu/next 66/109] kernel/rcu/srcu.c:516:15: error: redefinition of 'srcu_batches_completed'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git 
rcu/next
head:   0d02a83770da1e677b09192a22ae93a9788badcd
commit: 5a0465e17a18c467b712a816985b7b8dd8d10c16 [66/109] srcu: Shrink srcu.h 
by moving docbook and private function
config: mn10300-allmodconfig (attached as .config)
compiler: am33_2.0-linux-gcc (GCC) 6.2.0
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 5a0465e17a18c467b712a816985b7b8dd8d10c16
# save the attached .config to linux build tree
make.cross ARCH=mn10300 

Note: the rcu/rcu/next HEAD 0d02a83770da1e677b09192a22ae93a9788badcd builds 
fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

>> kernel/rcu/srcu.c:516:15: error: redefinition of 'srcu_batches_completed'
unsigned long srcu_batches_completed(struct srcu_struct *sp)
  ^~
   In file included from kernel/rcu/srcu.c:39:0:
   kernel/rcu/rcu.h:495:29: note: previous definition of 
'srcu_batches_completed' was here
static inline unsigned long srcu_batches_completed(struct srcu_struct *sp)
^~

vim +/srcu_batches_completed +516 kernel/rcu/srcu.c

621934ee kernel/srcu.c Paul E. McKenney 2006-10-04  510   * 
srcu_batches_completed - return batches completed.
621934ee kernel/srcu.c Paul E. McKenney 2006-10-04  511   * @sp: 
srcu_struct on which to report batch completion.
621934ee kernel/srcu.c Paul E. McKenney 2006-10-04  512   *
621934ee kernel/srcu.c Paul E. McKenney 2006-10-04  513   * Report the 
number of batches, correlated with, but not necessarily
621934ee kernel/srcu.c Paul E. McKenney 2006-10-04  514   * precisely the 
same as, the number of grace periods that have elapsed.
621934ee kernel/srcu.c Paul E. McKenney 2006-10-04  515   */
a5c198f4 kernel/rcu/srcu.c Paul E. McKenney 2014-11-23 @516  unsigned long 
srcu_batches_completed(struct srcu_struct *sp)
621934ee kernel/srcu.c Paul E. McKenney 2006-10-04  517  {
621934ee kernel/srcu.c Paul E. McKenney 2006-10-04  518 return 
sp->completed;
621934ee kernel/srcu.c Paul E. McKenney 2006-10-04  519  }

:: The code at line 516 was first introduced by commit
:: a5c198f4f7da6cc48116ca239c59c9f44b753364 rcu: Expand SRCU ->completed to 
64 bits

:: TO: Paul E. McKenney 
:: CC: Paul E. McKenney 

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


.config.gz
Description: application/gzip

Re: [PATCH v1 2/2] MIPS: PCI: Remove unused busn_offset

[Joshua Kinard]

On 05/19/2017 15:56, Bjorn Helgaas wrote:
> pci_add_resource_offset() is for host bridge windows where the bridge
> translates CPU addresses to PCI bus addresses by adding an offset.  To my
> knowledge, no host bridge translates bus numbers, so this is only useful
> for MEM and IO windows.  In any event, host->busn_offset is never set to
> anything other than zero, so pci_add_resource() is sufficient.
> 
> a2e50f53d535 ("MIPS: PCI: Add a hook for IORESOURCE_BUS in
> pci_controller/bridge_controller") also added busn_resource itself.  This
> is currently unused but may be used by future SGI IP27 fixes, so I left it
> there.
> 
> Signed-off-by: Bjorn Helgaas 
> CC: Joshua Kinard 
> ---
>  arch/mips/include/asm/pci.h |1 -
>  arch/mips/pci/pci-legacy.c  |3 +--
>  2 files changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/arch/mips/include/asm/pci.h b/arch/mips/include/asm/pci.h
> index 1000c1b4c875..52f551ee492d 100644
> --- a/arch/mips/include/asm/pci.h
> +++ b/arch/mips/include/asm/pci.h
> @@ -39,7 +39,6 @@ struct pci_controller {
>   unsigned long io_offset;
>   unsigned long io_map_base;
>   struct resource *busn_resource;
> - unsigned long busn_offset;
>  
>  #ifndef CONFIG_PCI_DOMAINS_GENERIC
>   unsigned int index;
> diff --git a/arch/mips/pci/pci-legacy.c b/arch/mips/pci/pci-legacy.c
> index 3a84f6c0c840..174575a9a112 100644
> --- a/arch/mips/pci/pci-legacy.c
> +++ b/arch/mips/pci/pci-legacy.c
> @@ -86,8 +86,7 @@ static void pcibios_scanbus(struct pci_controller *hose)
>   hose->mem_resource, hose->mem_offset);
>   pci_add_resource_offset(,
>   hose->io_resource, hose->io_offset);
> - pci_add_resource_offset(,
> - hose->busn_resource, hose->busn_offset);
> + pci_add_resource(, hose->busn_resource);
>   bus = pci_scan_root_bus(NULL, next_busno, hose->pci_ops, hose,
>   );
>   hose->bus = bus;
> 
> 

I tested this change out on my Octane (SGI-IP30) and Origin 200 (SGI-IP27), and
it appears to work fine on both systems (for now).

The Octane has two PCI host bridges in it right now (BaseIO & PCI Card cage),
while the Origin 200 only has one.  Haven't tested it on my bigger Onyx2 w/
multiple host bridges, but that machine has other problems, so I am ignoring it
for now.

I wasn't aware that pci_add_resource existed back when I wrote the patch.  The
symptom that was addressed was some conditional in the PCI core -- I forget
where -- wasn't enumerating multiple PCI busses without having an
IORESOURCE_BUS struct passed to it.  I think it found the first bus and then
moved on to other subsystems, which usually led to a non-booting machine.

Acked-by: Joshua Kinard 

Re: [PATCH v1 2/2] MIPS: PCI: Remove unused busn_offset

[Joshua Kinard]

On 05/19/2017 15:56, Bjorn Helgaas wrote:
> pci_add_resource_offset() is for host bridge windows where the bridge
> translates CPU addresses to PCI bus addresses by adding an offset.  To my
> knowledge, no host bridge translates bus numbers, so this is only useful
> for MEM and IO windows.  In any event, host->busn_offset is never set to
> anything other than zero, so pci_add_resource() is sufficient.
> 
> a2e50f53d535 ("MIPS: PCI: Add a hook for IORESOURCE_BUS in
> pci_controller/bridge_controller") also added busn_resource itself.  This
> is currently unused but may be used by future SGI IP27 fixes, so I left it
> there.
> 
> Signed-off-by: Bjorn Helgaas 
> CC: Joshua Kinard 
> ---
>  arch/mips/include/asm/pci.h |1 -
>  arch/mips/pci/pci-legacy.c  |3 +--
>  2 files changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/arch/mips/include/asm/pci.h b/arch/mips/include/asm/pci.h
> index 1000c1b4c875..52f551ee492d 100644
> --- a/arch/mips/include/asm/pci.h
> +++ b/arch/mips/include/asm/pci.h
> @@ -39,7 +39,6 @@ struct pci_controller {
>   unsigned long io_offset;
>   unsigned long io_map_base;
>   struct resource *busn_resource;
> - unsigned long busn_offset;
>  
>  #ifndef CONFIG_PCI_DOMAINS_GENERIC
>   unsigned int index;
> diff --git a/arch/mips/pci/pci-legacy.c b/arch/mips/pci/pci-legacy.c
> index 3a84f6c0c840..174575a9a112 100644
> --- a/arch/mips/pci/pci-legacy.c
> +++ b/arch/mips/pci/pci-legacy.c
> @@ -86,8 +86,7 @@ static void pcibios_scanbus(struct pci_controller *hose)
>   hose->mem_resource, hose->mem_offset);
>   pci_add_resource_offset(,
>   hose->io_resource, hose->io_offset);
> - pci_add_resource_offset(,
> - hose->busn_resource, hose->busn_offset);
> + pci_add_resource(, hose->busn_resource);
>   bus = pci_scan_root_bus(NULL, next_busno, hose->pci_ops, hose,
>   );
>   hose->bus = bus;
> 
> 

I tested this change out on my Octane (SGI-IP30) and Origin 200 (SGI-IP27), and
it appears to work fine on both systems (for now).

The Octane has two PCI host bridges in it right now (BaseIO & PCI Card cage),
while the Origin 200 only has one.  Haven't tested it on my bigger Onyx2 w/
multiple host bridges, but that machine has other problems, so I am ignoring it
for now.

I wasn't aware that pci_add_resource existed back when I wrote the patch.  The
symptom that was addressed was some conditional in the PCI core -- I forget
where -- wasn't enumerating multiple PCI busses without having an
IORESOURCE_BUS struct passed to it.  I think it found the first bus and then
moved on to other subsystems, which usually led to a non-booting machine.

Acked-by: Joshua Kinard 

Re: [PATCH] drm: Use vsnprintf extension %ph

[Joe Perches]

On Sat, 2017-06-10 at 19:12 +0300, Andy Shevchenko wrote:
> On Wed, May 31, 2017 at 2:35 AM, Joe Perches  wrote:
> > Using the extension saves a bit of code.
> > +   seq_printf(m, "faux/mst: %*ph\n", 2, buf);
> > +   seq_printf(m, "mst ctrl: %*ph\n", 1, buf);
> > +   seq_printf(m, "branch oui: %*phN devid: ", 3, buf);
> 
> All above may use shorter form, i.e.
> "..., "%Xph", buf);", where X is a constant written explicitly inplace.

I know.  Consistency is better though.
Note the use of DP_RECEIVER_CAP_SIZE, etc...

Re: [PATCH] drm: Use vsnprintf extension %ph

[Joe Perches]

On Sat, 2017-06-10 at 19:12 +0300, Andy Shevchenko wrote:
> On Wed, May 31, 2017 at 2:35 AM, Joe Perches  wrote:
> > Using the extension saves a bit of code.
> > +   seq_printf(m, "faux/mst: %*ph\n", 2, buf);
> > +   seq_printf(m, "mst ctrl: %*ph\n", 1, buf);
> > +   seq_printf(m, "branch oui: %*phN devid: ", 3, buf);
> 
> All above may use shorter form, i.e.
> "..., "%Xph", buf);", where X is a constant written explicitly inplace.

I know.  Consistency is better though.
Note the use of DP_RECEIVER_CAP_SIZE, etc...

[PATCH] compiler, clang: check before defining inline

[Alexander Alemayhu]

Fixes the compiler warning below introduced in abb2ea7dfd82 (compiler, clang:
suppress warning for unused static inline functions, 2017-06-06)

./include/linux/compiler-gcc.h:78:9: note: previous definition is here
^
1 warning generated.
clang  -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include 
-I./arch/x86/include -I./arch/x86/include/generated/uapi 
-I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi 
-I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h  
\
-D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value -Wno-pointer-sign \
-Wno-compare-distinct-pointer-types \
-Wno-gnu-variable-sized-type-not-at-end \
-Wno-address-of-packed-member -Wno-tautological-compare \
-Wno-unknown-warning-option \
-O2 -emit-llvm -c 
/home/vagrant/kernels/net-next/samples/bpf/test_map_in_map_kern.c -o -| llc 
-march=bpf -filetype=obj -o 
/home/vagrant/kernels/net-next/samples/bpf/test_map_in_map_kern.o
In file included from 
/home/vagrant/kernels/net-next/samples/bpf/test_map_in_map_kern.c:9:
In file included from ./include/linux/ptrace.h:4:
In file included from ./include/linux/compiler.h:82:
./include/linux/compiler-clang.h:24:9: warning: 'inline' macro redefined 
[-Wmacro-redefined]
^
./include/linux/compiler-gcc.h:78:9: note: previous definition is here
^
1 warning generated.
make[1]: Leaving directory '/home/vagrant/kernels/net-next'

$ clang --version
clang version 3.9.1 (tags/RELEASE_391/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

$ gcc --version
gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Fixes: abb2ea7dfd82 ("compiler, clang: suppress warning for unused static 
inline functions")
Signed-off-by: Alexander Alemayhu 
---

This is causing an error on out of tree builds for example using the
prototype-kernel repository. Should this be sent to Linus?

Thanks

 include/linux/compiler-clang.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index ea9126006a69..7cb55de2703c 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -21,4 +21,6 @@
  * -Wunused-function.  This turns out to avoid the need for complex #ifdef
  * directives.  Suppress the warning in clang as well.
  */
+#ifndef inline
 #define inline inline __attribute__((unused))
+#endif
-- 
2.7.4

[PATCH] compiler, clang: check before defining inline

[Alexander Alemayhu]

Fixes the compiler warning below introduced in abb2ea7dfd82 (compiler, clang:
suppress warning for unused static inline functions, 2017-06-06)

./include/linux/compiler-gcc.h:78:9: note: previous definition is here
^
1 warning generated.
clang  -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/6.3.1/include 
-I./arch/x86/include -I./arch/x86/include/generated/uapi 
-I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi 
-I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h  
\
-D__KERNEL__ -D__ASM_SYSREG_H -Wno-unused-value -Wno-pointer-sign \
-Wno-compare-distinct-pointer-types \
-Wno-gnu-variable-sized-type-not-at-end \
-Wno-address-of-packed-member -Wno-tautological-compare \
-Wno-unknown-warning-option \
-O2 -emit-llvm -c 
/home/vagrant/kernels/net-next/samples/bpf/test_map_in_map_kern.c -o -| llc 
-march=bpf -filetype=obj -o 
/home/vagrant/kernels/net-next/samples/bpf/test_map_in_map_kern.o
In file included from 
/home/vagrant/kernels/net-next/samples/bpf/test_map_in_map_kern.c:9:
In file included from ./include/linux/ptrace.h:4:
In file included from ./include/linux/compiler.h:82:
./include/linux/compiler-clang.h:24:9: warning: 'inline' macro redefined 
[-Wmacro-redefined]
^
./include/linux/compiler-gcc.h:78:9: note: previous definition is here
^
1 warning generated.
make[1]: Leaving directory '/home/vagrant/kernels/net-next'

$ clang --version
clang version 3.9.1 (tags/RELEASE_391/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

$ gcc --version
gcc (GCC) 6.3.1 20161221 (Red Hat 6.3.1-1)
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Fixes: abb2ea7dfd82 ("compiler, clang: suppress warning for unused static 
inline functions")
Signed-off-by: Alexander Alemayhu 
---

This is causing an error on out of tree builds for example using the
prototype-kernel repository. Should this be sent to Linus?

Thanks

 include/linux/compiler-clang.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/linux/compiler-clang.h b/include/linux/compiler-clang.h
index ea9126006a69..7cb55de2703c 100644
--- a/include/linux/compiler-clang.h
+++ b/include/linux/compiler-clang.h
@@ -21,4 +21,6 @@
  * -Wunused-function.  This turns out to avoid the need for complex #ifdef
  * directives.  Suppress the warning in clang as well.
  */
+#ifndef inline
 #define inline inline __attribute__((unused))
+#endif
-- 
2.7.4

Re: [PATCH] compiler, clang: check before defining inline

[Alexander Alemayhu]

On Sun, Jun 11, 2017 at 01:55:20AM +0200, Alexander Alemayhu wrote:
> 
> This is causing an error on out of tree builds for example using the
> prototype-kernel repository. Should this be sent to Linus?
>
Sorry, this comment was meant for someone else. I just forgot to 
strip them out before sending this.

Thanks.

-- 
Mit freundlichen Grüßen

Alexander Alemayhu

Re: [PATCH] compiler, clang: check before defining inline

[Alexander Alemayhu]

On Sun, Jun 11, 2017 at 01:55:20AM +0200, Alexander Alemayhu wrote:
> 
> This is causing an error on out of tree builds for example using the
> prototype-kernel repository. Should this be sent to Linus?
>
Sorry, this comment was meant for someone else. I just forgot to 
strip them out before sending this.

Thanks.

-- 
Mit freundlichen Grüßen

Alexander Alemayhu

Re: [Intel-wired-lan] [PATCH] i40evf: remove redundant null check on key

[Alexander Duyck]

On Sat, Jun 10, 2017 at 4:33 AM, Dan Carpenter  wrote:
>
> This patch isn't right...
>
> On Wed, Jun 07, 2017 at 12:54:07AM +0100, Colin King wrote:
>> From: Colin Ian King 
>>
>> key has previously been null checked so the subsequent null check
>> is redundant as key can never be null at that point, so remove it.
>>
>
> Actually, it's the reverse.  "key" is always NULL.  Probably the ||
> should be a &&?
>
> regards,
> dan carpenter

Actually the original code and the patched version are still both
broken, but it is more broken with the patch. With this change I am
pretty sure we will kernel panic if we use the ethtool ioctl for
ETHTOOL_SRXFHINDIR, or don't update the key when updating other fields
in the flow hash.

So the original logic here looks like a bad copy of code from igb.
There it doesn't support updating the key so if key is set we are
supposed to be returning an error since key update isn't currently
supported. So the check for key at the start of this function should
probably be dropped instead of the second check. From what I can tell
the original code prevents key from ever being updated since if key is
non-null it means we want to update the key.

- Alex

Re: [Intel-wired-lan] [PATCH] i40evf: remove redundant null check on key

[Alexander Duyck]

On Sat, Jun 10, 2017 at 4:33 AM, Dan Carpenter  wrote:
>
> This patch isn't right...
>
> On Wed, Jun 07, 2017 at 12:54:07AM +0100, Colin King wrote:
>> From: Colin Ian King 
>>
>> key has previously been null checked so the subsequent null check
>> is redundant as key can never be null at that point, so remove it.
>>
>
> Actually, it's the reverse.  "key" is always NULL.  Probably the ||
> should be a &&?
>
> regards,
> dan carpenter

Actually the original code and the patched version are still both
broken, but it is more broken with the patch. With this change I am
pretty sure we will kernel panic if we use the ethtool ioctl for
ETHTOOL_SRXFHINDIR, or don't update the key when updating other fields
in the flow hash.

So the original logic here looks like a bad copy of code from igb.
There it doesn't support updating the key so if key is set we are
supposed to be returning an error since key update isn't currently
supported. So the check for key at the start of this function should
probably be dropped instead of the second check. From what I can tell
the original code prevents key from ever being updated since if key is
non-null it means we want to update the key.

- Alex

Re: [PATCH 20/35] openrisc: defconfig: Cleanup from old Kconfig options

[Stafford Horne]

On Sat, Jun 10, 2017 at 06:42:27PM +0200, Krzysztof Kozlowski wrote:
> On Sat, Jun 10, 2017 at 05:13:54PM +0900, Stafford Horne wrote:
> > On Thu, Jun 08, 2017 at 06:10:31PM +0200, Krzysztof Kozlowski wrote:
> > > Remove old, dead Kconfig option INET_LRO. It is gone since
> > > commit 7bbf3cae65b6 ("ipv4: Remove inet_lro library").
> > > 
> > > Signed-off-by: Krzysztof Kozlowski 
> > > ---
> > >  arch/openrisc/configs/or1ksim_defconfig | 1 -
> > >  1 file changed, 1 deletion(-)
> > > 
> > > diff --git a/arch/openrisc/configs/or1ksim_defconfig 
> > > b/arch/openrisc/configs/or1ksim_defconfig
> > > index eb3fc581cf20..a73aa90501be 100644
> > > --- a/arch/openrisc/configs/or1ksim_defconfig
> > > +++ b/arch/openrisc/configs/or1ksim_defconfig
> > > @@ -23,7 +23,6 @@ CONFIG_INET=y
> > >  # CONFIG_INET_XFRM_MODE_TRANSPORT is not set
> > >  # CONFIG_INET_XFRM_MODE_TUNNEL is not set
> > >  # CONFIG_INET_XFRM_MODE_BEET is not set
> > > -# CONFIG_INET_LRO is not set
> > >  # CONFIG_INET_DIAG is not set
> > >  CONFIG_TCP_CONG_ADVANCED=y
> > >  # CONFIG_TCP_CONG_BIC is not set
> > 
> > Thanks, please let me know if you want me to take this, but it looks like
> > you plan to push the whole series in via another route.
> > 
> > Acked-by: Stafford Horne 
> 
> Thanks, I did not mention the merging plan in cover letter but I think
> the best way is to merge it through platform maintainers. Less
> conflicts, I guess.
> 
> I'll be taking and sendin in pull request only ARM part.
> 
> So please go ahead and apply it.

Applied.

Re: [PATCH 20/35] openrisc: defconfig: Cleanup from old Kconfig options

[Stafford Horne]

On Sat, Jun 10, 2017 at 06:42:27PM +0200, Krzysztof Kozlowski wrote:
> On Sat, Jun 10, 2017 at 05:13:54PM +0900, Stafford Horne wrote:
> > On Thu, Jun 08, 2017 at 06:10:31PM +0200, Krzysztof Kozlowski wrote:
> > > Remove old, dead Kconfig option INET_LRO. It is gone since
> > > commit 7bbf3cae65b6 ("ipv4: Remove inet_lro library").
> > > 
> > > Signed-off-by: Krzysztof Kozlowski 
> > > ---
> > >  arch/openrisc/configs/or1ksim_defconfig | 1 -
> > >  1 file changed, 1 deletion(-)
> > > 
> > > diff --git a/arch/openrisc/configs/or1ksim_defconfig 
> > > b/arch/openrisc/configs/or1ksim_defconfig
> > > index eb3fc581cf20..a73aa90501be 100644
> > > --- a/arch/openrisc/configs/or1ksim_defconfig
> > > +++ b/arch/openrisc/configs/or1ksim_defconfig
> > > @@ -23,7 +23,6 @@ CONFIG_INET=y
> > >  # CONFIG_INET_XFRM_MODE_TRANSPORT is not set
> > >  # CONFIG_INET_XFRM_MODE_TUNNEL is not set
> > >  # CONFIG_INET_XFRM_MODE_BEET is not set
> > > -# CONFIG_INET_LRO is not set
> > >  # CONFIG_INET_DIAG is not set
> > >  CONFIG_TCP_CONG_ADVANCED=y
> > >  # CONFIG_TCP_CONG_BIC is not set
> > 
> > Thanks, please let me know if you want me to take this, but it looks like
> > you plan to push the whole series in via another route.
> > 
> > Acked-by: Stafford Horne 
> 
> Thanks, I did not mention the merging plan in cover letter but I think
> the best way is to merge it through platform maintainers. Less
> conflicts, I guess.
> 
> I'll be taking and sendin in pull request only ARM part.
> 
> So please go ahead and apply it.

Applied.

Re: [PATCH v2 2/2] tcp: md5: extend the tcp_md5sig struct to specify a key address prefix

[David Miller]

From: Ivan Delalande 
Date: Fri,  9 Jun 2017 19:14:49 -0700

> Add a flag field and address prefix length at the end of the tcp_md5sig
> structure so users can configure an address prefix length along with a
> key. Make sure shorter option values are still accepted in
> tcp_v4_parse_md5_keys and tcp_v6_parse_md5_keys to maintain backward
> compatibility.
> 
> Signed-off-by: Bob Gilligan 
> Signed-off-by: Eric Mowat 
> Signed-off-by: Ivan Delalande 

As I believe was previously stated, the problem with this approach is
that if a new tool requests the prefix length and is run on an older
kernel, the kernel will return success even though the prefix length
was not taken into account.

We do not want to get a success back when the operation requested was
not performed.

Re: [PATCH v2 2/2] tcp: md5: extend the tcp_md5sig struct to specify a key address prefix

[David Miller]

From: Ivan Delalande 
Date: Fri,  9 Jun 2017 19:14:49 -0700

> Add a flag field and address prefix length at the end of the tcp_md5sig
> structure so users can configure an address prefix length along with a
> key. Make sure shorter option values are still accepted in
> tcp_v4_parse_md5_keys and tcp_v6_parse_md5_keys to maintain backward
> compatibility.
> 
> Signed-off-by: Bob Gilligan 
> Signed-off-by: Eric Mowat 
> Signed-off-by: Ivan Delalande 

As I believe was previously stated, the problem with this approach is
that if a new tool requests the prefix length and is run on an older
kernel, the kernel will return success even though the prefix length
was not taken into account.

We do not want to get a success back when the operation requested was
not performed.

[PATCH] genirq: fix error path in __setup_irq

[Heiner Kallweit]

If __irq_set_trigger() fails irq_request_resources() was successfully
called before. Therefore we should release all potentially claimed
resources in the error path.

Signed-off-by: Heiner Kallweit 
---
 kernel/irq/manage.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 49c37f1e..4c34696c 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1318,8 +1318,10 @@ __setup_irq(unsigned int irq, struct irq_desc *desc, 
struct irqaction *new)
ret = __irq_set_trigger(desc,
new->flags & IRQF_TRIGGER_MASK);
 
-   if (ret)
+   if (ret) {
+   irq_release_resources(desc);
goto out_mask;
+   }
}
 
desc->istate &= ~(IRQS_AUTODETECT | IRQS_SPURIOUS_DISABLED | \
-- 
2.13.1

[PATCH] genirq: fix error path in __setup_irq

[Heiner Kallweit]

If __irq_set_trigger() fails irq_request_resources() was successfully
called before. Therefore we should release all potentially claimed
resources in the error path.

Signed-off-by: Heiner Kallweit 
---
 kernel/irq/manage.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 49c37f1e..4c34696c 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1318,8 +1318,10 @@ __setup_irq(unsigned int irq, struct irq_desc *desc, 
struct irqaction *new)
ret = __irq_set_trigger(desc,
new->flags & IRQF_TRIGGER_MASK);
 
-   if (ret)
+   if (ret) {
+   irq_release_resources(desc);
goto out_mask;
+   }
}
 
desc->istate &= ~(IRQS_AUTODETECT | IRQS_SPURIOUS_DISABLED | \
-- 
2.13.1

Re: [PATCH] net: caif: Fix a sleep-in-atomic bug in cfpkt_create_pfx

[David Miller]

From: Jia-Ju Bai 
Date: Sat, 10 Jun 2017 16:49:39 +0800

> The kernel may sleep under a rcu read lock in cfpkt_create_pfx, and the
> function call path is:
> cfcnfg_linkup_rsp (acquire the lock by rcu_read_lock)
>   cfctrl_linkdown_req
> cfpkt_create
>   cfpkt_create_pfx
> alloc_skb(GFP_KERNEL) --> may sleep
> cfserl_receive (acquire the lock by rcu_read_lock)
>   cfpkt_split
> cfpkt_create_pfx
>   alloc_skb(GFP_KERNEL) --> may sleep
> 
> There is "in_interrupt" in cfpkt_create_pfx to decide use "GFP_KERNEL" or
> "GFP_ATOMIC". In this situation, "GFP_KERNEL" is used because the function 
> is called under a rcu read lock, instead in interrupt.
> 
> To fix it, only "GFP_ATOMIC" is used in cfpkt_create_pfx.
> 
> Signed-off-by: Jia-Ju Bai 

Applied and queued up for -stable.

Re: [PATCH] net: tipc: Fix a sleep-in-atomic bug in tipc_msg_reverse

[David Miller]

From: Jia-Ju Bai 
Date: Sat, 10 Jun 2017 17:03:35 +0800

> The kernel may sleep under a rcu read lock in tipc_msg_reverse, and the
> function call path is:
> tipc_l2_rcv_msg (acquire the lock by rcu_read_lock)
>   tipc_rcv
> tipc_sk_rcv
>   tipc_msg_reverse
> pskb_expand_head(GFP_KERNEL) --> may sleep
> tipc_node_broadcast
>   tipc_node_xmit_skb
> tipc_node_xmit
>   tipc_sk_rcv
> tipc_msg_reverse
>   pskb_expand_head(GFP_KERNEL) --> may sleep
> 
> To fix it, "GFP_KERNEL" is replaced with "GFP_ATOMIC".
> 
> Signed-off-by: Jia-Ju Bai 

Applied and queued up for -stable.

Re: [PATCH] net: caif: Fix a sleep-in-atomic bug in cfpkt_create_pfx

[David Miller]

From: Jia-Ju Bai 
Date: Sat, 10 Jun 2017 16:49:39 +0800

> The kernel may sleep under a rcu read lock in cfpkt_create_pfx, and the
> function call path is:
> cfcnfg_linkup_rsp (acquire the lock by rcu_read_lock)
>   cfctrl_linkdown_req
> cfpkt_create
>   cfpkt_create_pfx
> alloc_skb(GFP_KERNEL) --> may sleep
> cfserl_receive (acquire the lock by rcu_read_lock)
>   cfpkt_split
> cfpkt_create_pfx
>   alloc_skb(GFP_KERNEL) --> may sleep
> 
> There is "in_interrupt" in cfpkt_create_pfx to decide use "GFP_KERNEL" or
> "GFP_ATOMIC". In this situation, "GFP_KERNEL" is used because the function 
> is called under a rcu read lock, instead in interrupt.
> 
> To fix it, only "GFP_ATOMIC" is used in cfpkt_create_pfx.
> 
> Signed-off-by: Jia-Ju Bai 

Applied and queued up for -stable.

Re: [PATCH] net: tipc: Fix a sleep-in-atomic bug in tipc_msg_reverse

[David Miller]

From: Jia-Ju Bai 
Date: Sat, 10 Jun 2017 17:03:35 +0800

> The kernel may sleep under a rcu read lock in tipc_msg_reverse, and the
> function call path is:
> tipc_l2_rcv_msg (acquire the lock by rcu_read_lock)
>   tipc_rcv
> tipc_sk_rcv
>   tipc_msg_reverse
> pskb_expand_head(GFP_KERNEL) --> may sleep
> tipc_node_broadcast
>   tipc_node_xmit_skb
> tipc_node_xmit
>   tipc_sk_rcv
> tipc_msg_reverse
>   pskb_expand_head(GFP_KERNEL) --> may sleep
> 
> To fix it, "GFP_KERNEL" is replaced with "GFP_ATOMIC".
> 
> Signed-off-by: Jia-Ju Bai 

Applied and queued up for -stable.

Re: [PATCH] arm64/dma-mapping: Fix null-pointer check

[Russell King - ARM Linux]

On Sat, Jun 10, 2017 at 12:41:10PM -0700, Olav Haugan wrote:
> @@ -149,6 +140,11 @@ static void *__dma_alloc(struct device *dev, size_t size,
>   bool coherent = is_device_dma_coherent(dev);


This re-introduces an instance that you say you're getting rid of...

>   pgprot_t prot = __get_dma_pgprot(attrs, PAGE_KERNEL, false);
>  
> + if (!dev) {
> + WARN_ONCE(1, "Use an actual device structure for DMA 
> allocation\n");
> + return NULL;
> + }
> +
>   size = PAGE_ALIGN(size);
>  
>   if (!coherent && !gfpflags_allow_blocking(flags)) {

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH] arm64/dma-mapping: Fix null-pointer check

[Russell King - ARM Linux]

On Sat, Jun 10, 2017 at 12:41:10PM -0700, Olav Haugan wrote:
> @@ -149,6 +140,11 @@ static void *__dma_alloc(struct device *dev, size_t size,
>   bool coherent = is_device_dma_coherent(dev);


This re-introduces an instance that you say you're getting rid of...

>   pgprot_t prot = __get_dma_pgprot(attrs, PAGE_KERNEL, false);
>  
> + if (!dev) {
> + WARN_ONCE(1, "Use an actual device structure for DMA 
> allocation\n");
> + return NULL;
> + }
> +
>   size = PAGE_ALIGN(size);
>  
>   if (!coherent && !gfpflags_allow_blocking(flags)) {

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

Re: [PATCH v8 17/34] [media] add Omnivision OV5640 sensor driver

[Sakari Ailus]

Hi Steve,

On Wed, Jun 07, 2017 at 11:33:56AM -0700, Steve Longerbeam wrote:
...
> +/*
> + * FIXME: remove this when a subdev API becomes available
> + * to set the MIPI CSI-2 virtual channel.
> + */
> +static unsigned int virtual_channel;
> +module_param(virtual_channel, int, 0);
> +MODULE_PARM_DESC(virtual_channel,
> +  "MIPI CSI-2 virtual channel (0..3), default 0");

If this works for you it's a good workaround. I hope we can address the
matter properly soon --- it's related to data types, embedded data etc.

For the patch:

Acked-by: Sakari Ailus 

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH v8 17/34] [media] add Omnivision OV5640 sensor driver

[Sakari Ailus]

Hi Steve,

On Wed, Jun 07, 2017 at 11:33:56AM -0700, Steve Longerbeam wrote:
...
> +/*
> + * FIXME: remove this when a subdev API becomes available
> + * to set the MIPI CSI-2 virtual channel.
> + */
> +static unsigned int virtual_channel;
> +module_param(virtual_channel, int, 0);
> +MODULE_PARM_DESC(virtual_channel,
> +  "MIPI CSI-2 virtual channel (0..3), default 0");

If this works for you it's a good workaround. I hope we can address the
matter properly soon --- it's related to data types, embedded data etc.

For the patch:

Acked-by: Sakari Ailus 

-- 
Regards,

Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk

Re: [PATCH 3/6] ccree: use constant time memory comparison for macs and tags

[Henrique de Moraes Holschuh]

On Sat, 10 Jun 2017, Jason A. Donenfeld wrote:
> That's fine. As I mentioned, I really have no clue what this code's
> trying to do. If this is just part of some test that doesn't deal with
> actual messages that could be forged, then of course there's nothing
> that needs to be done and this can be NAKd.

Well, it is *testing* things, so you might want to use whatever the
module(s) will actually use.  Maybe test with both?

-- 
  Henrique Holschuh

Re: [PATCH 3/6] ccree: use constant time memory comparison for macs and tags

[Henrique de Moraes Holschuh]

On Sat, 10 Jun 2017, Jason A. Donenfeld wrote:
> That's fine. As I mentioned, I really have no clue what this code's
> trying to do. If this is just part of some test that doesn't deal with
> actual messages that could be forged, then of course there's nothing
> that needs to be done and this can be NAKd.

Well, it is *testing* things, so you might want to use whatever the
module(s) will actually use.  Maybe test with both?

-- 
  Henrique Holschuh

Re: [PATCH 4/7] iommu: Add driver-not-bound notification

[Joerg Roedel]

On Fri, Jun 09, 2017 at 04:43:34PM -0600, Alex Williamson wrote:
> + case BUS_NOTIFY_DRIVER_NOT_BOUND:
> + group_action = IOMMU_GROUP_NOTIFY_DRIVER_NOT_BOUND;
> + break;

Ah yes, I missed that too when looking at the patch. Still Acked-by-Me
:)


Joerg

Re: [PATCH 4/7] iommu: Add driver-not-bound notification

[Joerg Roedel]

On Fri, Jun 09, 2017 at 04:43:34PM -0600, Alex Williamson wrote:
> + case BUS_NOTIFY_DRIVER_NOT_BOUND:
> + group_action = IOMMU_GROUP_NOTIFY_DRIVER_NOT_BOUND;
> + break;

Ah yes, I missed that too when looking at the patch. Still Acked-by-Me
:)


Joerg

[GIT PULL] SCSI fixes for 4.12-rc4

[James Bottomley]

This is a set of user visible fixes (excepting one format string
change).  Four of the qla2xxx fixes only affect the firmware dump path,
but it's still important to the enterprise.  The rest are various NULL
pointer crash conditions or outright driver hangs.

The patch is available here:

git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes

The short changelog is:

Arnd Bergmann (1):
  scsi: lpfc: nvmet_fc: fix format string

Bill Kuzeja (1):
  scsi: qla2xxx: Fix extraneous ref on sp's after adapter break

Guilherme G. Piccoli (1):
  scsi: lpfc: Avoid NULL pointer dereference in lpfc_els_abort()

Gustavo A. R. Silva (1):
  scsi: lpfc: prevent potential null pointer dereference

Joe Carnuccio (4):
  scsi: qla2xxx: Fix crash due to NULL pointer dereference of ctx
  scsi: qla2xxx: Fix mailbox pointer error in fwdump capture
  scsi: qla2xxx: Set bit 15 for DIAG_ECHO_TEST MBC
  scsi: qla2xxx: Modify T262 FW dump template to specify same start/end to 
debug customer issues

Johannes Thumshirn (1):
  scsi: qla2xxx: don't disable a not previously enabled PCI device

Martin K. Petersen (1):
  scsi: scsi_debug: Avoid PI being disabled when TPGS is enabled

Maurizio Lombardi (1):
  scsi: bnx2fc: fix race condition in bnx2fc_get_host_stats()

Quinn Tran (1):
  scsi: qla2xxx: Fix NULL pointer access due to redundant fc_host_port_name 
call

Sawan Chandak (1):
  scsi: qla2xxx: Fix crash due to mismatch mumber of Q-pair creation for 
Multi queue

Varun Prakash (1):
  scsi: cxgb4i: libcxgbi: in error case RST tcp conn

himanshu.madh...@cavium.com (1):
  scsi: qla2xxx: Fix recursive loop during target mode configuration for 
ISP25XX leaving system unresponsive

And diffstat:

 drivers/scsi/bnx2fc/bnx2fc.h   |  1 +
 drivers/scsi/bnx2fc/bnx2fc_fcoe.c  | 10 +++--
 drivers/scsi/cxgbi/cxgb4i/cxgb4i.c |  1 -
 drivers/scsi/cxgbi/libcxgbi.c  | 29 ++--
 drivers/scsi/cxgbi/libcxgbi.h  |  1 +
 drivers/scsi/lpfc/lpfc_crtn.h  |  2 +-
 drivers/scsi/lpfc/lpfc_ct.c|  5 +++--
 drivers/scsi/lpfc/lpfc_nportdisc.c |  7 --
 drivers/scsi/lpfc/lpfc_nvmet.c |  4 ++--
 drivers/scsi/qla2xxx/qla_bsg.c |  9 
 drivers/scsi/qla2xxx/qla_dbg.c |  4 ++--
 drivers/scsi/qla2xxx/qla_def.h |  1 +
 drivers/scsi/qla2xxx/qla_init.c|  5 -
 drivers/scsi/qla2xxx/qla_inline.h  | 26 ++---
 drivers/scsi/qla2xxx/qla_isr.c |  2 +-
 drivers/scsi/qla2xxx/qla_mbx.c | 13 ++-
 drivers/scsi/qla2xxx/qla_os.c  | 46 --
 drivers/scsi/qla2xxx/qla_target.c  |  8 ---
 drivers/scsi/qla2xxx/qla_tmpl.c|  2 +-
 drivers/scsi/scsi_debug.c  |  2 +-
 20 files changed, 101 insertions(+), 77 deletions(-)

With full diff below.

James

---

diff --git a/drivers/scsi/bnx2fc/bnx2fc.h b/drivers/scsi/bnx2fc/bnx2fc.h
index 4fc8ed5fe067..1f424e40afdf 100644
--- a/drivers/scsi/bnx2fc/bnx2fc.h
+++ b/drivers/scsi/bnx2fc/bnx2fc.h
@@ -191,6 +191,7 @@ struct bnx2fc_hba {
struct bnx2fc_cmd_mgr *cmd_mgr;
spinlock_t hba_lock;
struct mutex hba_mutex;
+   struct mutex hba_stats_mutex;
unsigned long adapter_state;
#define ADAPTER_STATE_UP0
#define ADAPTER_STATE_GOING_DOWN1
diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c 
b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
index 93b5a0012417..902722dc4ce3 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
@@ -663,15 +663,17 @@ static struct fc_host_statistics 
*bnx2fc_get_host_stats(struct Scsi_Host *shost)
if (!fw_stats)
return NULL;
 
+   mutex_lock(>hba_stats_mutex);
+
bnx2fc_stats = fc_get_host_stats(shost);
 
init_completion(>stat_req_done);
if (bnx2fc_send_stat_req(hba))
-   return bnx2fc_stats;
+   goto unlock_stats_mutex;
rc = wait_for_completion_timeout(>stat_req_done, (2 * HZ));
if (!rc) {
BNX2FC_HBA_DBG(lport, "FW stat req timed out\n");
-   return bnx2fc_stats;
+   goto unlock_stats_mutex;
}
BNX2FC_STATS(hba, rx_stat2, fc_crc_cnt);
bnx2fc_stats->invalid_crc_count += hba->bfw_stats.fc_crc_cnt;
@@ -693,6 +695,9 @@ static struct fc_host_statistics 
*bnx2fc_get_host_stats(struct Scsi_Host *shost)
 
memcpy(>prev_stats, hba->stats_buffer,
   sizeof(struct fcoe_statistics_params));
+
+unlock_stats_mutex:
+   mutex_unlock(>hba_stats_mutex);
return bnx2fc_stats;
 }
 
@@ -1340,6 +1345,7 @@ static struct bnx2fc_hba *bnx2fc_hba_create(struct 
cnic_dev *cnic)
}
spin_lock_init(>hba_lock);
mutex_init(>hba_mutex);
+   mutex_init(>hba_stats_mutex);
 
hba->cnic = cnic;
 
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c 
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 1076c1578322..0aae094ab91c 

[GIT PULL] SCSI fixes for 4.12-rc4

[James Bottomley]

This is a set of user visible fixes (excepting one format string
change).  Four of the qla2xxx fixes only affect the firmware dump path,
but it's still important to the enterprise.  The rest are various NULL
pointer crash conditions or outright driver hangs.

The patch is available here:

git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git scsi-fixes

The short changelog is:

Arnd Bergmann (1):
  scsi: lpfc: nvmet_fc: fix format string

Bill Kuzeja (1):
  scsi: qla2xxx: Fix extraneous ref on sp's after adapter break

Guilherme G. Piccoli (1):
  scsi: lpfc: Avoid NULL pointer dereference in lpfc_els_abort()

Gustavo A. R. Silva (1):
  scsi: lpfc: prevent potential null pointer dereference

Joe Carnuccio (4):
  scsi: qla2xxx: Fix crash due to NULL pointer dereference of ctx
  scsi: qla2xxx: Fix mailbox pointer error in fwdump capture
  scsi: qla2xxx: Set bit 15 for DIAG_ECHO_TEST MBC
  scsi: qla2xxx: Modify T262 FW dump template to specify same start/end to 
debug customer issues

Johannes Thumshirn (1):
  scsi: qla2xxx: don't disable a not previously enabled PCI device

Martin K. Petersen (1):
  scsi: scsi_debug: Avoid PI being disabled when TPGS is enabled

Maurizio Lombardi (1):
  scsi: bnx2fc: fix race condition in bnx2fc_get_host_stats()

Quinn Tran (1):
  scsi: qla2xxx: Fix NULL pointer access due to redundant fc_host_port_name 
call

Sawan Chandak (1):
  scsi: qla2xxx: Fix crash due to mismatch mumber of Q-pair creation for 
Multi queue

Varun Prakash (1):
  scsi: cxgb4i: libcxgbi: in error case RST tcp conn

himanshu.madh...@cavium.com (1):
  scsi: qla2xxx: Fix recursive loop during target mode configuration for 
ISP25XX leaving system unresponsive

And diffstat:

 drivers/scsi/bnx2fc/bnx2fc.h   |  1 +
 drivers/scsi/bnx2fc/bnx2fc_fcoe.c  | 10 +++--
 drivers/scsi/cxgbi/cxgb4i/cxgb4i.c |  1 -
 drivers/scsi/cxgbi/libcxgbi.c  | 29 ++--
 drivers/scsi/cxgbi/libcxgbi.h  |  1 +
 drivers/scsi/lpfc/lpfc_crtn.h  |  2 +-
 drivers/scsi/lpfc/lpfc_ct.c|  5 +++--
 drivers/scsi/lpfc/lpfc_nportdisc.c |  7 --
 drivers/scsi/lpfc/lpfc_nvmet.c |  4 ++--
 drivers/scsi/qla2xxx/qla_bsg.c |  9 
 drivers/scsi/qla2xxx/qla_dbg.c |  4 ++--
 drivers/scsi/qla2xxx/qla_def.h |  1 +
 drivers/scsi/qla2xxx/qla_init.c|  5 -
 drivers/scsi/qla2xxx/qla_inline.h  | 26 ++---
 drivers/scsi/qla2xxx/qla_isr.c |  2 +-
 drivers/scsi/qla2xxx/qla_mbx.c | 13 ++-
 drivers/scsi/qla2xxx/qla_os.c  | 46 --
 drivers/scsi/qla2xxx/qla_target.c  |  8 ---
 drivers/scsi/qla2xxx/qla_tmpl.c|  2 +-
 drivers/scsi/scsi_debug.c  |  2 +-
 20 files changed, 101 insertions(+), 77 deletions(-)

With full diff below.

James

---

diff --git a/drivers/scsi/bnx2fc/bnx2fc.h b/drivers/scsi/bnx2fc/bnx2fc.h
index 4fc8ed5fe067..1f424e40afdf 100644
--- a/drivers/scsi/bnx2fc/bnx2fc.h
+++ b/drivers/scsi/bnx2fc/bnx2fc.h
@@ -191,6 +191,7 @@ struct bnx2fc_hba {
struct bnx2fc_cmd_mgr *cmd_mgr;
spinlock_t hba_lock;
struct mutex hba_mutex;
+   struct mutex hba_stats_mutex;
unsigned long adapter_state;
#define ADAPTER_STATE_UP0
#define ADAPTER_STATE_GOING_DOWN1
diff --git a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c 
b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
index 93b5a0012417..902722dc4ce3 100644
--- a/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
+++ b/drivers/scsi/bnx2fc/bnx2fc_fcoe.c
@@ -663,15 +663,17 @@ static struct fc_host_statistics 
*bnx2fc_get_host_stats(struct Scsi_Host *shost)
if (!fw_stats)
return NULL;
 
+   mutex_lock(>hba_stats_mutex);
+
bnx2fc_stats = fc_get_host_stats(shost);
 
init_completion(>stat_req_done);
if (bnx2fc_send_stat_req(hba))
-   return bnx2fc_stats;
+   goto unlock_stats_mutex;
rc = wait_for_completion_timeout(>stat_req_done, (2 * HZ));
if (!rc) {
BNX2FC_HBA_DBG(lport, "FW stat req timed out\n");
-   return bnx2fc_stats;
+   goto unlock_stats_mutex;
}
BNX2FC_STATS(hba, rx_stat2, fc_crc_cnt);
bnx2fc_stats->invalid_crc_count += hba->bfw_stats.fc_crc_cnt;
@@ -693,6 +695,9 @@ static struct fc_host_statistics 
*bnx2fc_get_host_stats(struct Scsi_Host *shost)
 
memcpy(>prev_stats, hba->stats_buffer,
   sizeof(struct fcoe_statistics_params));
+
+unlock_stats_mutex:
+   mutex_unlock(>hba_stats_mutex);
return bnx2fc_stats;
 }
 
@@ -1340,6 +1345,7 @@ static struct bnx2fc_hba *bnx2fc_hba_create(struct 
cnic_dev *cnic)
}
spin_lock_init(>hba_lock);
mutex_init(>hba_mutex);
+   mutex_init(>hba_stats_mutex);
 
hba->cnic = cnic;
 
diff --git a/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c 
b/drivers/scsi/cxgbi/cxgb4i/cxgb4i.c
index 1076c1578322..0aae094ab91c 

Re: [PATCH] scsi: remove useless variable assignment

[James Bottomley]

On Thu, 2017-05-18 at 12:41 -0500, Gustavo A. R. Silva wrote:
> Hi James,
> 
> Quoting James Bottomley :
> 
> > On Wed, 2017-05-17 at 19:30 -0500, Gustavo A. R. Silva wrote:
> > > Remove this assignment once the value stored in variable _k_ is
> > > overwritten after a few lines.
> > > 
> > > Addresses-Coverity-ID: 1226927
> > > Signed-off-by: Gustavo A. R. Silva 
> > > ---
> > >  drivers/scsi/qlogicfas408.c | 1 -
> > >  1 file changed, 1 deletion(-)
> > > 
> > > diff --git a/drivers/scsi/qlogicfas408.c
> > > b/drivers/scsi/qlogicfas408.c
> > > index c3a9151..269440a 100644
> > > --- a/drivers/scsi/qlogicfas408.c
> > > +++ b/drivers/scsi/qlogicfas408.c
> > > @@ -329,7 +329,6 @@ static unsigned int ql_pcmd(struct scsi_cmnd
> > > *cmd)
> > >*/
> > >   if ((k = ql_wai(priv)))
> > >   return (k << 16);
> > > - k = inb(qbase + 5); /* should be 0x10,
> > > bus
> > > service */
> > 
> > That doesn't look right to me.  inb() is a statement which has an
> > effect on the I/O device regardless of whether the returned value
> > is
> > used or discarded.  In this case I think it's being used to clear
> > pending interrupts, so removing it will likely cause a phase error.
> > 
> 
> You are right, I get it.
> 
> In this case I think a patch to ignore the return value could be
> applied:
> 
> index c3a9151..8f5339a 100644
> --- a/drivers/scsi/qlogicfas408.c
> +++ b/drivers/scsi/qlogicfas408.c
> @@ -329,7 +329,7 @@ static unsigned int ql_pcmd(struct scsi_cmnd
> *cmd)
>   */
>  if ((k = ql_wai(priv)))
>  return (k << 16);
> -   k = inb(qbase + 5); /* should be 0x10, bus
> service */
> +   inb(qbase + 5); /* should be 0x10, bus service */
>  }
> 
> What do you think?

Really, no ... fix coverity.  The pattern of  = inX(something) is
perfectly correct kernel code even if the actual value of  is
never used again.  Unless there's some security bug possibility I'm not
seeing, I don't think the pattern needs altering.

In theory (void)inX() is the slightly more correct way to do this in
that it tells the compiler you need to read from here and you're
deliberately discarding the value but I don't see any value to
enforcing that.

James

Re: [PATCH] scsi: remove useless variable assignment

[James Bottomley]

On Thu, 2017-05-18 at 12:41 -0500, Gustavo A. R. Silva wrote:
> Hi James,
> 
> Quoting James Bottomley :
> 
> > On Wed, 2017-05-17 at 19:30 -0500, Gustavo A. R. Silva wrote:
> > > Remove this assignment once the value stored in variable _k_ is
> > > overwritten after a few lines.
> > > 
> > > Addresses-Coverity-ID: 1226927
> > > Signed-off-by: Gustavo A. R. Silva 
> > > ---
> > >  drivers/scsi/qlogicfas408.c | 1 -
> > >  1 file changed, 1 deletion(-)
> > > 
> > > diff --git a/drivers/scsi/qlogicfas408.c
> > > b/drivers/scsi/qlogicfas408.c
> > > index c3a9151..269440a 100644
> > > --- a/drivers/scsi/qlogicfas408.c
> > > +++ b/drivers/scsi/qlogicfas408.c
> > > @@ -329,7 +329,6 @@ static unsigned int ql_pcmd(struct scsi_cmnd
> > > *cmd)
> > >*/
> > >   if ((k = ql_wai(priv)))
> > >   return (k << 16);
> > > - k = inb(qbase + 5); /* should be 0x10,
> > > bus
> > > service */
> > 
> > That doesn't look right to me.  inb() is a statement which has an
> > effect on the I/O device regardless of whether the returned value
> > is
> > used or discarded.  In this case I think it's being used to clear
> > pending interrupts, so removing it will likely cause a phase error.
> > 
> 
> You are right, I get it.
> 
> In this case I think a patch to ignore the return value could be
> applied:
> 
> index c3a9151..8f5339a 100644
> --- a/drivers/scsi/qlogicfas408.c
> +++ b/drivers/scsi/qlogicfas408.c
> @@ -329,7 +329,7 @@ static unsigned int ql_pcmd(struct scsi_cmnd
> *cmd)
>   */
>  if ((k = ql_wai(priv)))
>  return (k << 16);
> -   k = inb(qbase + 5); /* should be 0x10, bus
> service */
> +   inb(qbase + 5); /* should be 0x10, bus service */
>  }
> 
> What do you think?

Really, no ... fix coverity.  The pattern of  = inX(something) is
perfectly correct kernel code even if the actual value of  is
never used again.  Unless there's some security bug possibility I'm not
seeing, I don't think the pattern needs altering.

In theory (void)inX() is the slightly more correct way to do this in
that it tells the compiler you need to read from here and you're
deliberately discarding the value but I don't see any value to
enforcing that.

James

Re: [PATCH v5 03/23] scsi: hisi_sas: optimise the usage of hisi_hba.lock

[kbuild test robot]

Hi Xiang,

[auto build test WARNING on mkp-scsi/for-next]
[also build test WARNING on v4.12-rc4 next-20170609]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/John-Garry/hisi_sas-hip08-support/20170611-014437
base:   https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next


coccinelle warnings: (new ones prefixed by >>)

>> drivers/scsi/hisi_sas/hisi_sas_main.c:1208:1-18: ERROR: nested lock+irqsave 
>> that reuses flags from line 1178.

vim +1208 drivers/scsi/hisi_sas/hisi_sas_main.c

bf95e9ccc Xiang Chen 2017-06-09  1172   if (rc) {
bf95e9ccc Xiang Chen 2017-06-09  1173   
spin_unlock_irqrestore(_hba->lock, flags);
441c27401 John Garry 2016-08-24  1174   goto err_out;
bf95e9ccc Xiang Chen 2017-06-09  1175   }
bf95e9ccc Xiang Chen 2017-06-09  1176   spin_unlock_irqrestore(_hba->lock, 
flags);
bf95e9ccc Xiang Chen 2017-06-09  1177  
bf95e9ccc Xiang Chen 2017-06-09 @1178   spin_lock_irqsave(>lock, flags);
bf95e9ccc Xiang Chen 2017-06-09  1179   rc = 
hisi_hba->hw->get_free_slot(hisi_hba, dq);
441c27401 John Garry 2016-08-24  1180   if (rc)
441c27401 John Garry 2016-08-24  1181   goto err_out_tag;
441c27401 John Garry 2016-08-24  1182  
bf95e9ccc Xiang Chen 2017-06-09  1183   dlvry_queue = dq->id;
bf95e9ccc Xiang Chen 2017-06-09  1184   dlvry_queue_slot = dq->wr_point;
bf95e9ccc Xiang Chen 2017-06-09  1185  
441c27401 John Garry 2016-08-24  1186   slot = _hba->slot_info[slot_idx];
441c27401 John Garry 2016-08-24  1187   memset(slot, 0, sizeof(struct 
hisi_sas_slot));
441c27401 John Garry 2016-08-24  1188  
441c27401 John Garry 2016-08-24  1189   slot->idx = slot_idx;
441c27401 John Garry 2016-08-24  1190   slot->n_elem = n_elem;
441c27401 John Garry 2016-08-24  1191   slot->dlvry_queue = dlvry_queue;
441c27401 John Garry 2016-08-24  1192   slot->dlvry_queue_slot = 
dlvry_queue_slot;
441c27401 John Garry 2016-08-24  1193   cmd_hdr_base = 
hisi_hba->cmd_hdr[dlvry_queue];
441c27401 John Garry 2016-08-24  1194   slot->cmd_hdr = 
_hdr_base[dlvry_queue_slot];
441c27401 John Garry 2016-08-24  1195   slot->task = task;
441c27401 John Garry 2016-08-24  1196   slot->port = port;
441c27401 John Garry 2016-08-24  1197   task->lldd_task = slot;
441c27401 John Garry 2016-08-24  1198  
441c27401 John Garry 2016-08-24  1199   memset(slot->cmd_hdr, 0, sizeof(struct 
hisi_sas_cmd_hdr));
441c27401 John Garry 2016-08-24  1200  
441c27401 John Garry 2016-08-24  1201   rc = hisi_sas_task_prep_abort(hisi_hba, 
slot, device_id,
441c27401 John Garry 2016-08-24  1202 
abort_flag, task_tag);
441c27401 John Garry 2016-08-24  1203   if (rc)
441c27401 John Garry 2016-08-24  1204   goto err_out_tag;
441c27401 John Garry 2016-08-24  1205  
405314df5 John Garry 2017-03-23  1206  
405314df5 John Garry 2017-03-23  1207   list_add_tail(>entry, 
_dev->list);
54c9dd2d2 John Garry 2017-03-23 @1208   
spin_lock_irqsave(>task_state_lock, flags);
441c27401 John Garry 2016-08-24  1209   task->task_state_flags |= 
SAS_TASK_AT_INITIATOR;
54c9dd2d2 John Garry 2017-03-23  1210   
spin_unlock_irqrestore(>task_state_lock, flags);
441c27401 John Garry 2016-08-24  1211  

:: The code at line 1208 was first introduced by commit
:: 54c9dd2d26d0951891516a956893428feb9aea17 scsi: hisi_sas: fix some 
sas_task.task_state_lock locking

:: TO: John Garry 
:: CC: Martin K. Petersen 

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

Re: [PATCH v5 03/23] scsi: hisi_sas: optimise the usage of hisi_hba.lock

[kbuild test robot]

Hi Xiang,

[auto build test WARNING on mkp-scsi/for-next]
[also build test WARNING on v4.12-rc4 next-20170609]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/John-Garry/hisi_sas-hip08-support/20170611-014437
base:   https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git for-next


coccinelle warnings: (new ones prefixed by >>)

>> drivers/scsi/hisi_sas/hisi_sas_main.c:1208:1-18: ERROR: nested lock+irqsave 
>> that reuses flags from line 1178.

vim +1208 drivers/scsi/hisi_sas/hisi_sas_main.c

bf95e9ccc Xiang Chen 2017-06-09  1172   if (rc) {
bf95e9ccc Xiang Chen 2017-06-09  1173   
spin_unlock_irqrestore(_hba->lock, flags);
441c27401 John Garry 2016-08-24  1174   goto err_out;
bf95e9ccc Xiang Chen 2017-06-09  1175   }
bf95e9ccc Xiang Chen 2017-06-09  1176   spin_unlock_irqrestore(_hba->lock, 
flags);
bf95e9ccc Xiang Chen 2017-06-09  1177  
bf95e9ccc Xiang Chen 2017-06-09 @1178   spin_lock_irqsave(>lock, flags);
bf95e9ccc Xiang Chen 2017-06-09  1179   rc = 
hisi_hba->hw->get_free_slot(hisi_hba, dq);
441c27401 John Garry 2016-08-24  1180   if (rc)
441c27401 John Garry 2016-08-24  1181   goto err_out_tag;
441c27401 John Garry 2016-08-24  1182  
bf95e9ccc Xiang Chen 2017-06-09  1183   dlvry_queue = dq->id;
bf95e9ccc Xiang Chen 2017-06-09  1184   dlvry_queue_slot = dq->wr_point;
bf95e9ccc Xiang Chen 2017-06-09  1185  
441c27401 John Garry 2016-08-24  1186   slot = _hba->slot_info[slot_idx];
441c27401 John Garry 2016-08-24  1187   memset(slot, 0, sizeof(struct 
hisi_sas_slot));
441c27401 John Garry 2016-08-24  1188  
441c27401 John Garry 2016-08-24  1189   slot->idx = slot_idx;
441c27401 John Garry 2016-08-24  1190   slot->n_elem = n_elem;
441c27401 John Garry 2016-08-24  1191   slot->dlvry_queue = dlvry_queue;
441c27401 John Garry 2016-08-24  1192   slot->dlvry_queue_slot = 
dlvry_queue_slot;
441c27401 John Garry 2016-08-24  1193   cmd_hdr_base = 
hisi_hba->cmd_hdr[dlvry_queue];
441c27401 John Garry 2016-08-24  1194   slot->cmd_hdr = 
_hdr_base[dlvry_queue_slot];
441c27401 John Garry 2016-08-24  1195   slot->task = task;
441c27401 John Garry 2016-08-24  1196   slot->port = port;
441c27401 John Garry 2016-08-24  1197   task->lldd_task = slot;
441c27401 John Garry 2016-08-24  1198  
441c27401 John Garry 2016-08-24  1199   memset(slot->cmd_hdr, 0, sizeof(struct 
hisi_sas_cmd_hdr));
441c27401 John Garry 2016-08-24  1200  
441c27401 John Garry 2016-08-24  1201   rc = hisi_sas_task_prep_abort(hisi_hba, 
slot, device_id,
441c27401 John Garry 2016-08-24  1202 
abort_flag, task_tag);
441c27401 John Garry 2016-08-24  1203   if (rc)
441c27401 John Garry 2016-08-24  1204   goto err_out_tag;
441c27401 John Garry 2016-08-24  1205  
405314df5 John Garry 2017-03-23  1206  
405314df5 John Garry 2017-03-23  1207   list_add_tail(>entry, 
_dev->list);
54c9dd2d2 John Garry 2017-03-23 @1208   
spin_lock_irqsave(>task_state_lock, flags);
441c27401 John Garry 2016-08-24  1209   task->task_state_flags |= 
SAS_TASK_AT_INITIATOR;
54c9dd2d2 John Garry 2017-03-23  1210   
spin_unlock_irqrestore(>task_state_lock, flags);
441c27401 John Garry 2016-08-24  1211  

:: The code at line 1208 was first introduced by commit
:: 54c9dd2d26d0951891516a956893428feb9aea17 scsi: hisi_sas: fix some 
sas_task.task_state_lock locking

:: TO: John Garry 
:: CC: Martin K. Petersen 

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

Re: [linux-sunxi] Re: [PATCH v2] arm64: allwinner: a64: Add initial NanoPi A64 support

[Maxime Ripard]

On Fri, Jun 09, 2017 at 04:36:09PM +0100, Andre Przywara wrote:
> Hi,
> 
> On 09/06/17 16:26, Jagan Teki wrote:
> > On Friday 09 June 2017 08:21 PM, Maxime Ripard wrote:
> >> Hi Jagan,
> >>
> >> On Fri, Jun 09, 2017 at 12:40:52PM +, Jagan Teki wrote:
> >>> + {
> >>> +pinctrl-names = "default";
> >>> +pinctrl-0 = <_pins>;
> >>> +status = "okay";
> >>> +};
> >>> +
> >>> +_pins {
> >>> +bias-pull-up;
> >>> +};
> >>
> >> What is connected on that bus?
> > 
> > i2c1 connected with gpio/i2s
> 
> Those are the I2C pins connected to the headers. We have them in the
> other A64 DTs as well (Pine64, BananaPi).

We've always had the policy of not enabling anything outside of the
board has been there from the very start, arm64 or not.

> If that is not the right approach, we should discuss this and keep it
> consistent at least across the A64 boards.

If some boards slipped through, then that would be on me I guess,
but it's (unfortunate) exceptions.

If you want to ease that for the users, you can have that node with
the pinctrl nodes pre-set, but leave it disabled. We have that on a
number of boards already.

> >>> + {
> >>> +pinctrl-names = "default";
> >>> +pinctrl-0 = <_pins>, <_rts_cts_pins>;
> >>> +status = "okay";
> >>> +};
> >>
> >> And on that UART?
> > 
> > uart1 for SDIO (Wifi connector, with RTS/CTS), this along with mmc1
> 
> To be precise, UART1 (with h/w handshake) is connected to the Bluetooth
> part of the WiFi/BT chip, which is soldered on that board. Regardless of
> the actual *WiFi* support state BT should work already - at least it did
> when I tried this a few months ago on the Pine64 (although this involved
> some userland heavy lifting).
> Not sure what the approach here is in regard to the power supply and
> wake-up GPIOs, shall they be described in this node as well or is that
> up for userspace to control?

There's probably more to it though. Most BT chips require regulators
and clocks to be enabled. Ideally, this would even be a full DT node
for the bluetooth chip.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [linux-sunxi] Re: [PATCH v2] arm64: allwinner: a64: Add initial NanoPi A64 support

[Maxime Ripard]

On Fri, Jun 09, 2017 at 04:36:09PM +0100, Andre Przywara wrote:
> Hi,
> 
> On 09/06/17 16:26, Jagan Teki wrote:
> > On Friday 09 June 2017 08:21 PM, Maxime Ripard wrote:
> >> Hi Jagan,
> >>
> >> On Fri, Jun 09, 2017 at 12:40:52PM +, Jagan Teki wrote:
> >>> + {
> >>> +pinctrl-names = "default";
> >>> +pinctrl-0 = <_pins>;
> >>> +status = "okay";
> >>> +};
> >>> +
> >>> +_pins {
> >>> +bias-pull-up;
> >>> +};
> >>
> >> What is connected on that bus?
> > 
> > i2c1 connected with gpio/i2s
> 
> Those are the I2C pins connected to the headers. We have them in the
> other A64 DTs as well (Pine64, BananaPi).

We've always had the policy of not enabling anything outside of the
board has been there from the very start, arm64 or not.

> If that is not the right approach, we should discuss this and keep it
> consistent at least across the A64 boards.

If some boards slipped through, then that would be on me I guess,
but it's (unfortunate) exceptions.

If you want to ease that for the users, you can have that node with
the pinctrl nodes pre-set, but leave it disabled. We have that on a
number of boards already.

> >>> + {
> >>> +pinctrl-names = "default";
> >>> +pinctrl-0 = <_pins>, <_rts_cts_pins>;
> >>> +status = "okay";
> >>> +};
> >>
> >> And on that UART?
> > 
> > uart1 for SDIO (Wifi connector, with RTS/CTS), this along with mmc1
> 
> To be precise, UART1 (with h/w handshake) is connected to the Bluetooth
> part of the WiFi/BT chip, which is soldered on that board. Regardless of
> the actual *WiFi* support state BT should work already - at least it did
> when I tried this a few months ago on the Pine64 (although this involved
> some userland heavy lifting).
> Not sure what the approach here is in regard to the power supply and
> wake-up GPIOs, shall they be described in this node as well or is that
> up for userspace to control?

There's probably more to it though. Most BT chips require regulators
and clocks to be enabled. Ideally, this would even be a full DT node
for the bluetooth chip.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH v10 09/10] powerpc/perf: Thread IMC PMU functions

[kbuild test robot]

Hi Anju,

[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.12-rc4 next-20170609]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Madhavan-Srinivasan/IMC-Instrumentation-Support/20170609-183528
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

Note: the 
linux-review/Madhavan-Srinivasan/IMC-Instrumentation-Support/20170609-183528 
HEAD 32ada0705ff79986e8ceca5e83dba14c0b620751 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   In file included from include/linux/compiler.h:62:0,
from include/uapi/linux/stddef.h:1,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/uapi/linux/perf_event.h:17,
from include/linux/perf_event.h:17,
from arch/powerpc/perf/imc-pmu.c:13:
   arch/powerpc/perf/imc-pmu.c: In function 'cleanup_all_thread_imc_memory':
>> arch/powerpc/perf/imc-pmu.c:863:31: error: 'cpu' undeclared (first use in 
>> this function)
  if (per_cpu(thread_imc_mem, cpu))
  ^
   include/linux/compiler-gcc.h:53:26: note: in definition of macro 'RELOC_HIDE'
 (typeof(ptr)) (__ptr + (off)); \
 ^~~
   include/linux/percpu-defs.h:223:2: note: in expansion of macro 
'SHIFT_PERCPU_PTR'
 SHIFT_PERCPU_PTR((ptr), per_cpu_offset((cpu)));   \
 ^~~~
   include/linux/percpu-defs.h:223:26: note: in expansion of macro 
'per_cpu_offset'
 SHIFT_PERCPU_PTR((ptr), per_cpu_offset((cpu)));   \
 ^~
   include/linux/percpu-defs.h:256:29: note: in expansion of macro 'per_cpu_ptr'
#define per_cpu(var, cpu) (*per_cpu_ptr(&(var), cpu))
^~~
   arch/powerpc/perf/imc-pmu.c:863:7: note: in expansion of macro 'per_cpu'
  if (per_cpu(thread_imc_mem, cpu))
  ^~~
   arch/powerpc/perf/imc-pmu.c:863:31: note: each undeclared identifier is 
reported only once for each function it appears in
  if (per_cpu(thread_imc_mem, cpu))
  ^
   include/linux/compiler-gcc.h:53:26: note: in definition of macro 'RELOC_HIDE'
 (typeof(ptr)) (__ptr + (off)); \
 ^~~
   include/linux/percpu-defs.h:223:2: note: in expansion of macro 
'SHIFT_PERCPU_PTR'
 SHIFT_PERCPU_PTR((ptr), per_cpu_offset((cpu)));   \
 ^~~~
   include/linux/percpu-defs.h:223:26: note: in expansion of macro 
'per_cpu_offset'
 SHIFT_PERCPU_PTR((ptr), per_cpu_offset((cpu)));   \
 ^~
   include/linux/percpu-defs.h:256:29: note: in expansion of macro 'per_cpu_ptr'
#define per_cpu(var, cpu) (*per_cpu_ptr(&(var), cpu))
^~~
   arch/powerpc/perf/imc-pmu.c:863:7: note: in expansion of macro 'per_cpu'
  if (per_cpu(thread_imc_mem, cpu))
  ^~~

vim +/cpu +863 arch/powerpc/perf/imc-pmu.c

   857  
   858  static void cleanup_all_thread_imc_memory(void)
   859  {
   860  int i;
   861  
   862  for_each_online_cpu(i) {
 > 863  if (per_cpu(thread_imc_mem, cpu))
   864  free_pages(per_cpu(thread_imc_mem, cpu), 0);
   865  }
   866  }

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


.config.gz
Description: application/gzip

Re: [PATCH v10 09/10] powerpc/perf: Thread IMC PMU functions

[kbuild test robot]

Hi Anju,

[auto build test ERROR on powerpc/next]
[also build test ERROR on v4.12-rc4 next-20170609]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Madhavan-Srinivasan/IMC-Instrumentation-Support/20170609-183528
base:   https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git next
config: powerpc-defconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://raw.githubusercontent.com/01org/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=powerpc 

Note: the 
linux-review/Madhavan-Srinivasan/IMC-Instrumentation-Support/20170609-183528 
HEAD 32ada0705ff79986e8ceca5e83dba14c0b620751 builds fine.
  It only hurts bisectibility.

All errors (new ones prefixed by >>):

   In file included from include/linux/compiler.h:62:0,
from include/uapi/linux/stddef.h:1,
from include/linux/stddef.h:4,
from include/uapi/linux/posix_types.h:4,
from include/uapi/linux/types.h:13,
from include/linux/types.h:5,
from include/uapi/linux/perf_event.h:17,
from include/linux/perf_event.h:17,
from arch/powerpc/perf/imc-pmu.c:13:
   arch/powerpc/perf/imc-pmu.c: In function 'cleanup_all_thread_imc_memory':
>> arch/powerpc/perf/imc-pmu.c:863:31: error: 'cpu' undeclared (first use in 
>> this function)
  if (per_cpu(thread_imc_mem, cpu))
  ^
   include/linux/compiler-gcc.h:53:26: note: in definition of macro 'RELOC_HIDE'
 (typeof(ptr)) (__ptr + (off)); \
 ^~~
   include/linux/percpu-defs.h:223:2: note: in expansion of macro 
'SHIFT_PERCPU_PTR'
 SHIFT_PERCPU_PTR((ptr), per_cpu_offset((cpu)));   \
 ^~~~
   include/linux/percpu-defs.h:223:26: note: in expansion of macro 
'per_cpu_offset'
 SHIFT_PERCPU_PTR((ptr), per_cpu_offset((cpu)));   \
 ^~
   include/linux/percpu-defs.h:256:29: note: in expansion of macro 'per_cpu_ptr'
#define per_cpu(var, cpu) (*per_cpu_ptr(&(var), cpu))
^~~
   arch/powerpc/perf/imc-pmu.c:863:7: note: in expansion of macro 'per_cpu'
  if (per_cpu(thread_imc_mem, cpu))
  ^~~
   arch/powerpc/perf/imc-pmu.c:863:31: note: each undeclared identifier is 
reported only once for each function it appears in
  if (per_cpu(thread_imc_mem, cpu))
  ^
   include/linux/compiler-gcc.h:53:26: note: in definition of macro 'RELOC_HIDE'
 (typeof(ptr)) (__ptr + (off)); \
 ^~~
   include/linux/percpu-defs.h:223:2: note: in expansion of macro 
'SHIFT_PERCPU_PTR'
 SHIFT_PERCPU_PTR((ptr), per_cpu_offset((cpu)));   \
 ^~~~
   include/linux/percpu-defs.h:223:26: note: in expansion of macro 
'per_cpu_offset'
 SHIFT_PERCPU_PTR((ptr), per_cpu_offset((cpu)));   \
 ^~
   include/linux/percpu-defs.h:256:29: note: in expansion of macro 'per_cpu_ptr'
#define per_cpu(var, cpu) (*per_cpu_ptr(&(var), cpu))
^~~
   arch/powerpc/perf/imc-pmu.c:863:7: note: in expansion of macro 'per_cpu'
  if (per_cpu(thread_imc_mem, cpu))
  ^~~

vim +/cpu +863 arch/powerpc/perf/imc-pmu.c

   857  
   858  static void cleanup_all_thread_imc_memory(void)
   859  {
   860  int i;
   861  
   862  for_each_online_cpu(i) {
 > 863  if (per_cpu(thread_imc_mem, cpu))
   864  free_pages(per_cpu(thread_imc_mem, cpu), 0);
   865  }
   866  }

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


.config.gz
Description: application/gzip

Re: [PATCH] l2tp: cast l2tp traffic counter to unsigned

[David Miller]

From: Eric Dumazet 
Date: Fri, 09 Jun 2017 17:29:11 -0700

> On Fri, 2017-06-09 at 15:16 -0700, Stephen Hemminger wrote:
>> On Fri,  9 Jun 2017 16:29:47 +0200
>> Dominik Heidler  wrote:
>> 
>> > This fixes a counter problem on 32bit systems:
>> > When the rx_bytes counter reached 2 GiB, it jumpd to (2^64 Bytes - 2GiB) 
>> > Bytes.
>> > 
>> > rtnl_link_stats64 has __u64 type and atomic_long_read returns
>> > atomic_long_t which is signed. Due to the conversation
>> > we get an incorrect value on 32bit systems if the MSB of
>> > the atomic_long_t value is set.
>> > 
>> > CC: Tom Parkin 
>> > Fixes: 7b7c0719cd7a ("l2tp: avoid deadlock in l2tp stats update")
>> > Signed-off-by: Dominik Heidler 
>> > ---
>> >  net/l2tp/l2tp_eth.c | 13 +++--
>> >  1 file changed, 7 insertions(+), 6 deletions(-)
>> > 
>> > diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
>> > index 8b21af7321b9..668a75e002e9 100644
>> > --- a/net/l2tp/l2tp_eth.c
>> > +++ b/net/l2tp/l2tp_eth.c
>> > @@ -114,12 +114,13 @@ static void l2tp_eth_get_stats64(struct net_device 
>> > *dev,
>> >  {
>> >struct l2tp_eth *priv = netdev_priv(dev);
>> >  
>> > -  stats->tx_bytes   = atomic_long_read(>tx_bytes);
>> > -  stats->tx_packets = atomic_long_read(>tx_packets);
>> > -  stats->tx_dropped = atomic_long_read(>tx_dropped);
>> > -  stats->rx_bytes   = atomic_long_read(>rx_bytes);
>> > -  stats->rx_packets = atomic_long_read(>rx_packets);
>> > -  stats->rx_errors  = atomic_long_read(>rx_errors);
>> > +  stats->tx_bytes   = (unsigned long) atomic_long_read(>tx_bytes);
>> > +  stats->tx_packets = (unsigned long) atomic_long_read(>tx_packets);
>> > +  stats->tx_dropped = (unsigned long) atomic_long_read(>tx_dropped);
>> > +  stats->rx_bytes   = (unsigned long) atomic_long_read(>rx_bytes);
>> > +  stats->rx_packets = (unsigned long) atomic_long_read(>rx_packets);
>> > +  stats->rx_errors  = (unsigned long) atomic_long_read(>rx_errors);
>> > +
>> >  }
>> >  
>> >  static const struct net_device_ops l2tp_eth_netdev_ops = {
>> 
>> This is not the right way to fix this.
>> 
>> 1. shouldn't be using atomic's for network counters, look at other network 
>> devices.
>> 
>> 2. should be using u64_stats_fetch  api to handle 64 bit counters.
> 
> But they do not want 64bit counters, and not per cpu counters for a
> driver handling few packets per second.
> 
> Just use native size of "unsigned long".

Ahh yeah, indeed.  I've applied this l2tp patch, therefore.

> We use the same atomic_long_t for (struct netdev)->rx_dropped,
> tx_dropped & rx_nohandler
> 
> So I guess same fix is needed in dev_get_stats()

Looks like it, I'll apply a formal submission of this.

Re: [PATCH] l2tp: cast l2tp traffic counter to unsigned

[David Miller]

From: Eric Dumazet 
Date: Fri, 09 Jun 2017 17:29:11 -0700

> On Fri, 2017-06-09 at 15:16 -0700, Stephen Hemminger wrote:
>> On Fri,  9 Jun 2017 16:29:47 +0200
>> Dominik Heidler  wrote:
>> 
>> > This fixes a counter problem on 32bit systems:
>> > When the rx_bytes counter reached 2 GiB, it jumpd to (2^64 Bytes - 2GiB) 
>> > Bytes.
>> > 
>> > rtnl_link_stats64 has __u64 type and atomic_long_read returns
>> > atomic_long_t which is signed. Due to the conversation
>> > we get an incorrect value on 32bit systems if the MSB of
>> > the atomic_long_t value is set.
>> > 
>> > CC: Tom Parkin 
>> > Fixes: 7b7c0719cd7a ("l2tp: avoid deadlock in l2tp stats update")
>> > Signed-off-by: Dominik Heidler 
>> > ---
>> >  net/l2tp/l2tp_eth.c | 13 +++--
>> >  1 file changed, 7 insertions(+), 6 deletions(-)
>> > 
>> > diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
>> > index 8b21af7321b9..668a75e002e9 100644
>> > --- a/net/l2tp/l2tp_eth.c
>> > +++ b/net/l2tp/l2tp_eth.c
>> > @@ -114,12 +114,13 @@ static void l2tp_eth_get_stats64(struct net_device 
>> > *dev,
>> >  {
>> >struct l2tp_eth *priv = netdev_priv(dev);
>> >  
>> > -  stats->tx_bytes   = atomic_long_read(>tx_bytes);
>> > -  stats->tx_packets = atomic_long_read(>tx_packets);
>> > -  stats->tx_dropped = atomic_long_read(>tx_dropped);
>> > -  stats->rx_bytes   = atomic_long_read(>rx_bytes);
>> > -  stats->rx_packets = atomic_long_read(>rx_packets);
>> > -  stats->rx_errors  = atomic_long_read(>rx_errors);
>> > +  stats->tx_bytes   = (unsigned long) atomic_long_read(>tx_bytes);
>> > +  stats->tx_packets = (unsigned long) atomic_long_read(>tx_packets);
>> > +  stats->tx_dropped = (unsigned long) atomic_long_read(>tx_dropped);
>> > +  stats->rx_bytes   = (unsigned long) atomic_long_read(>rx_bytes);
>> > +  stats->rx_packets = (unsigned long) atomic_long_read(>rx_packets);
>> > +  stats->rx_errors  = (unsigned long) atomic_long_read(>rx_errors);
>> > +
>> >  }
>> >  
>> >  static const struct net_device_ops l2tp_eth_netdev_ops = {
>> 
>> This is not the right way to fix this.
>> 
>> 1. shouldn't be using atomic's for network counters, look at other network 
>> devices.
>> 
>> 2. should be using u64_stats_fetch  api to handle 64 bit counters.
> 
> But they do not want 64bit counters, and not per cpu counters for a
> driver handling few packets per second.
> 
> Just use native size of "unsigned long".

Ahh yeah, indeed.  I've applied this l2tp patch, therefore.

> We use the same atomic_long_t for (struct netdev)->rx_dropped,
> tx_dropped & rx_nohandler
> 
> So I guess same fix is needed in dev_get_stats()

Looks like it, I'll apply a formal submission of this.

Re: [PATCH] drm/panel: st7789v: Add a dependency on the backlight framework

[Maxime Ripard]

On Tue, May 30, 2017 at 11:01:36PM +0200, Maxime Ripard wrote:
> The driver depends on the backlight functions, but we have no dependency
> on it in Kconfig. Add this dependency to avoid breakages.
> 
> Signed-off-by: Maxime Ripard 

Ping?
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH] drm/panel: st7789v: Add a dependency on the backlight framework

[Maxime Ripard]

On Tue, May 30, 2017 at 11:01:36PM +0200, Maxime Ripard wrote:
> The driver depends on the backlight functions, but we have no dependency
> on it in Kconfig. Add this dependency to avoid breakages.
> 
> Signed-off-by: Maxime Ripard 

Ping?
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature

Re: [PATCH] net: aquantia: atlantic: remove declaration of hw_atl_utils_hw_set_power

[David Miller]

From: Philippe Reynes 
Date: Fri,  9 Jun 2017 23:50:57 +0200

> This function is not defined, so no need to declare it.
> 
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
> 
> Signed-off-by: Philippe Reynes 

Applied, thanks.

Re: [PATCH] net: aquantia: atlantic: remove declaration of hw_atl_utils_hw_set_power

[David Miller]

From: Philippe Reynes 
Date: Fri,  9 Jun 2017 23:50:57 +0200

> This function is not defined, so no need to declare it.
> 
> As I don't have the hardware, I'd be very pleased if
> someone may test this patch.
> 
> Signed-off-by: Philippe Reynes 

Applied, thanks.

[PATCH] arm64/dma-mapping: Fix null-pointer check

[Olav Haugan]

The current null-pointer check in __dma_alloc_coherent and
__dma_free_coherent is pretty much useless since we are dereferencing
the pointer before checking for null.
Check for null-pointer before the actual dereferencing of the pointer.

Signed-off-by: Olav Haugan 
---
 arch/arm64/mm/dma-mapping.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 3216e098c058..a4b65773711d 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -95,11 +95,6 @@ static void *__dma_alloc_coherent(struct device *dev, size_t 
size,
  dma_addr_t *dma_handle, gfp_t flags,
  unsigned long attrs)
 {
-   if (dev == NULL) {
-   WARN_ONCE(1, "Use an actual device structure for DMA 
allocation\n");
-   return NULL;
-   }
-
if (IS_ENABLED(CONFIG_ZONE_DMA) &&
dev->coherent_dma_mask <= DMA_BIT_MASK(32))
flags |= GFP_DMA;
@@ -128,10 +123,6 @@ static void __dma_free_coherent(struct device *dev, size_t 
size,
bool freed;
phys_addr_t paddr = dma_to_phys(dev, dma_handle);
 
-   if (dev == NULL) {
-   WARN_ONCE(1, "Use an actual device structure for DMA 
allocation\n");
-   return;
-   }
 
freed = dma_release_from_contiguous(dev,
phys_to_page(paddr),
@@ -149,6 +140,11 @@ static void *__dma_alloc(struct device *dev, size_t size,
bool coherent = is_device_dma_coherent(dev);
pgprot_t prot = __get_dma_pgprot(attrs, PAGE_KERNEL, false);
 
+   if (!dev) {
+   WARN_ONCE(1, "Use an actual device structure for DMA 
allocation\n");
+   return NULL;
+   }
+
size = PAGE_ALIGN(size);
 
if (!coherent && !gfpflags_allow_blocking(flags)) {
@@ -192,8 +188,13 @@ static void __dma_free(struct device *dev, size_t size,
   void *vaddr, dma_addr_t dma_handle,
   unsigned long attrs)
 {
-   void *swiotlb_addr = phys_to_virt(dma_to_phys(dev, dma_handle));
+   void *swiotlb_addr;
 
+   if (!dev) {
+   WARN_ONCE(1, "Use an actual device structure for DMA free\n");
+   return;
+   }
+   swiotlb_addr = phys_to_virt(dma_to_phys(dev, dma_handle));
size = PAGE_ALIGN(size);
 
if (!is_device_dma_coherent(dev)) {
-- 
2.13.0

[PATCH] arm64/dma-mapping: Fix null-pointer check

[Olav Haugan]

The current null-pointer check in __dma_alloc_coherent and
__dma_free_coherent is pretty much useless since we are dereferencing
the pointer before checking for null.
Check for null-pointer before the actual dereferencing of the pointer.

Signed-off-by: Olav Haugan 
---
 arch/arm64/mm/dma-mapping.c | 21 +++--
 1 file changed, 11 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/mm/dma-mapping.c b/arch/arm64/mm/dma-mapping.c
index 3216e098c058..a4b65773711d 100644
--- a/arch/arm64/mm/dma-mapping.c
+++ b/arch/arm64/mm/dma-mapping.c
@@ -95,11 +95,6 @@ static void *__dma_alloc_coherent(struct device *dev, size_t 
size,
  dma_addr_t *dma_handle, gfp_t flags,
  unsigned long attrs)
 {
-   if (dev == NULL) {
-   WARN_ONCE(1, "Use an actual device structure for DMA 
allocation\n");
-   return NULL;
-   }
-
if (IS_ENABLED(CONFIG_ZONE_DMA) &&
dev->coherent_dma_mask <= DMA_BIT_MASK(32))
flags |= GFP_DMA;
@@ -128,10 +123,6 @@ static void __dma_free_coherent(struct device *dev, size_t 
size,
bool freed;
phys_addr_t paddr = dma_to_phys(dev, dma_handle);
 
-   if (dev == NULL) {
-   WARN_ONCE(1, "Use an actual device structure for DMA 
allocation\n");
-   return;
-   }
 
freed = dma_release_from_contiguous(dev,
phys_to_page(paddr),
@@ -149,6 +140,11 @@ static void *__dma_alloc(struct device *dev, size_t size,
bool coherent = is_device_dma_coherent(dev);
pgprot_t prot = __get_dma_pgprot(attrs, PAGE_KERNEL, false);
 
+   if (!dev) {
+   WARN_ONCE(1, "Use an actual device structure for DMA 
allocation\n");
+   return NULL;
+   }
+
size = PAGE_ALIGN(size);
 
if (!coherent && !gfpflags_allow_blocking(flags)) {
@@ -192,8 +188,13 @@ static void __dma_free(struct device *dev, size_t size,
   void *vaddr, dma_addr_t dma_handle,
   unsigned long attrs)
 {
-   void *swiotlb_addr = phys_to_virt(dma_to_phys(dev, dma_handle));
+   void *swiotlb_addr;
 
+   if (!dev) {
+   WARN_ONCE(1, "Use an actual device structure for DMA free\n");
+   return;
+   }
+   swiotlb_addr = phys_to_virt(dma_to_phys(dev, dma_handle));
size = PAGE_ALIGN(size);
 
if (!is_device_dma_coherent(dev)) {
-- 
2.13.0

Re: [PATCH v2 1/3] dt-bindings: remoteproc: Add Keystone DSP remoteproc binding

[Santosh Shilimkar]

On 6/7/2017 5:24 PM, Suman Anna wrote:

Add the device tree bindings document for the Texas Instrument's
Keystone 2 DSP remoteproc devices.

Signed-off-by: Suman Anna 
Signed-off-by: Sam Nelson 
---
v2 Changes:
  - Modified the patch title
  - Dropped unstable binding status
  - Dropped the 'label' property and replaced the device node description
to use an alias
  - Renamed 'kick-gpio' to 'kick-gpios'
  - Updated the example


Looks reasonable to me. Ofcourse you need Rob's ack for this one.

Acked-by: Santosh Shilimkar 

Re: [PATCH v2 1/3] dt-bindings: remoteproc: Add Keystone DSP remoteproc binding

[Santosh Shilimkar]

On 6/7/2017 5:24 PM, Suman Anna wrote:

Add the device tree bindings document for the Texas Instrument's
Keystone 2 DSP remoteproc devices.

Signed-off-by: Suman Anna 
Signed-off-by: Sam Nelson 
---
v2 Changes:
  - Modified the patch title
  - Dropped unstable binding status
  - Dropped the 'label' property and replaced the device node description
to use an alias
  - Renamed 'kick-gpio' to 'kick-gpios'
  - Updated the example


Looks reasonable to me. Ofcourse you need Rob's ack for this one.

Acked-by: Santosh Shilimkar 

Re: [PATCH v2 3/3] remoteproc/keystone: Ensure the DSPs are in reset in probe

[Santosh Shilimkar]

On 6/7/2017 5:24 PM, Suman Anna wrote:

From: "Andrew F. Davis" 

The DSPs are expected to be in reset when the driver probes a device.
If the DSPs are out of reset in probe, the system may crash when the
firmware is being loaded. So, add a check to make sure the DSP resets
are asserted, and if not, throw a eye-catchy warning and assert the
resets specifically.

Signed-off-by: Andrew F. Davis 
[s-a...@ti.com: replace warning with a WARN]
Signed-off-by: Suman Anna 
---

Acked-by: Santosh Shilimkar 

Re: [PATCH v2 3/3] remoteproc/keystone: Ensure the DSPs are in reset in probe

[Santosh Shilimkar]

On 6/7/2017 5:24 PM, Suman Anna wrote:

From: "Andrew F. Davis" 

The DSPs are expected to be in reset when the driver probes a device.
If the DSPs are out of reset in probe, the system may crash when the
firmware is being loaded. So, add a check to make sure the DSP resets
are asserted, and if not, throw a eye-catchy warning and assert the
resets specifically.

Signed-off-by: Andrew F. Davis 
[s-a...@ti.com: replace warning with a WARN]
Signed-off-by: Suman Anna 
---

Acked-by: Santosh Shilimkar 

Re: [PATCH v2 2/3] remoteproc/keystone: Add a remoteproc driver for Keystone 2 DSPs

[Santosh Shilimkar]

6/7/2017 5:24 PM, Suman Anna wrote:

The Texas Instrument's Keystone 2 family of SoCs has 1 or more
TMS320C66x DSP Core Subsystems (C66x CorePacs). Each subsystem has
a C66x Fixed/Floating-Point DSP Core, with 32KB of L1P and L1D SRAMs,
that can be configured and partitioned as either RAM and/or Cache,
and 1 MB of L2 SRAM. The CorePac also includes an Internal DMA (IDMA),
External Memory Controller (EMC), Extended Memory Controller (XMC)
with a Memory Protection and Address Extension (MPAX) unit, a Bandwidth
Management (BWM) unit, an Interrupt Controller (INTC) and a Powerdown
Controller (PDC).

A new remoteproc module is added to perform the device management of
these DSP devices. The driver expects the firmware names to be of the
form "keystone-dsp-fw", where X is the corresponding DSP number, and
uses the standard remoteproc core ELF loader. The support is limited
to images only using the DSP internal memories at the moment. This
remoteproc driver is also designed to work with virtio, and uses the
IPC Generation registers for performing the virtio signalling and
getting notified of exceptions.

The driver currently supports the 66AK2H/66AK2K, 66AK2L and 66AK2E
SoCs.

Signed-off-by: Suman Anna 
Signed-off-by: Sam Nelson 
Signed-off-by: Andrew F. Davis 
---


Acked-by: Santosh Shilimkar 

Re: [PATCH v2 2/3] remoteproc/keystone: Add a remoteproc driver for Keystone 2 DSPs

[Santosh Shilimkar]

6/7/2017 5:24 PM, Suman Anna wrote:

The Texas Instrument's Keystone 2 family of SoCs has 1 or more
TMS320C66x DSP Core Subsystems (C66x CorePacs). Each subsystem has
a C66x Fixed/Floating-Point DSP Core, with 32KB of L1P and L1D SRAMs,
that can be configured and partitioned as either RAM and/or Cache,
and 1 MB of L2 SRAM. The CorePac also includes an Internal DMA (IDMA),
External Memory Controller (EMC), Extended Memory Controller (XMC)
with a Memory Protection and Address Extension (MPAX) unit, a Bandwidth
Management (BWM) unit, an Interrupt Controller (INTC) and a Powerdown
Controller (PDC).

A new remoteproc module is added to perform the device management of
these DSP devices. The driver expects the firmware names to be of the
form "keystone-dsp-fw", where X is the corresponding DSP number, and
uses the standard remoteproc core ELF loader. The support is limited
to images only using the DSP internal memories at the moment. This
remoteproc driver is also designed to work with virtio, and uses the
IPC Generation registers for performing the virtio signalling and
getting notified of exceptions.

The driver currently supports the 66AK2H/66AK2K, 66AK2L and 66AK2E
SoCs.

Signed-off-by: Suman Anna 
Signed-off-by: Sam Nelson 
Signed-off-by: Andrew F. Davis 
---


Acked-by: Santosh Shilimkar