Re: [PATCH v4] Thermal cleanups and hardware trip points

[Sascha Hauer]

Eduardo, Rui,

Any feedback to this series?

Thanks
  Sascha

On Wed, May 20, 2015 at 03:20:30PM +0200, Sascha Hauer wrote:
> This series adds support for hardware trip points. It picks up earlier
> work from Mikko Perttunen. Mikko implemented hardware trip points as part
> of the device tree support. It was suggested back then to move the
> functionality to the thermal core instead of putting more code into the
> device tree support. This series does exactly that.
> 
> The majority of the patches are cleanups and fixes. Patch 11 introduces
> hardware tracked trip points and finally a driver for the Mediatek
> thermal controller is introduced as the first user.
> 
> All comments welcome
> 
> Changes since v3:
> - Fix some missing function type changes in int3400_thermal.c,
>   processor_thermal_device.c, kirkwood_thermal.c and exynos_tmu.c
> - Add better description for set_trips callback
> - update the interrupt triggers also when the trip points change
> - Add missing MODULE_* tags
> - Broaden temperature range in the Mediatek driver so that we can be sure
>   the measured temperatures are really out of the desired range
> 
> Changes since v2:
> - Add Mediatek thermal controller driver as first user for hardware trip
>   points
> 
> Changes since v1:
> - Use int instead of unsigned long consistently for temperatures
> - Instead of misfixing the emulation code add a comment how the
>   code is meant
> - Add doc entry for .set_trips callback
> - initialize prev_low_trip/prev_high_trip properly
> - get tz->lock before calling thermal_zone_set_trips()
> 
> 
> 

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] sched: Fix sched_wakeup tracepoint

[Peter Zijlstra]

On Fri, 2015-06-05 at 13:23 +, Mathieu Desnoyers wrote:
> sched_wakeup: when try_to_wake_up{,_local} is called in the waker.
> sched_activate_task: when the wakee is marked runnable.
> sched_switch: when scheduling actually happens.
> 
> We can then calculate wakeup latency as
> 
>   time@sched_activate - time@sched_wakeup

One more thing, I think I would disagree with this. I would suggest
never to use the 'wakeup' (or 'waking' in my proposal) for timing. I
would suggest to use your interrupt tracepoint (or whatever else causes
wakeup to be called for this).

The wakeup times should be measured in tasktime -- of course, if
interrupts/preemption are disabled then tasktime == walltime.

The scheduling bit OTOH always needs to be measured in walltime, and is
most affected by the presence of other tasks on the system.

This too is why I'm not sure it makes sense to combine the two into a
single measurement. They should be measured in different time domains.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] thermal: exynos: Disable the regulator on probe failure

[Javier Martinez Canillas]

Hello Krzysztof,

On Mon, Jun 8, 2015 at 3:35 AM, Krzysztof Kozlowski
 wrote:
> During probe the regulator (if present) was enabled but not disabled in
> case of failure. So an unsuccessful probe lead to enabling the
> regulator which was actually not needed because the device was not
> enabled.
>
> Additionally each deferred probe lead to increase of regulator enable
> count so it would not be effectively disabled during removal of the
> device.
>
> Signed-off-by: Krzysztof Kozlowski 
> Fixes: 498d22f616f6 ("thermal: exynos: Support for TMU regulator defined at 
> device tree")
> Cc: 
>

Reviewed-by: Javier Martinez Canillas 

> ---
>
> I am not entirely convinced that this should go to stable. Leaving a
> regulator enabled in case of probe failure (no exynos TMU device) or
> after deferred probe (regulator won't be disabled during device removal)
> is not a critical issue, just leaks power.


Yes, as you said leaving the regulator enabled is not critical but
OTOH is a very small patch and is fixing a very evident bug so I think
it's OK.

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

Re: [RESEND 1/2] usb: ehci-exynos: Make provision for vdd regulators

[Krzysztof Kozlowski]

2015-06-08 15:42 GMT+09:00 Javier Martinez Canillas :
> Hello,
>
> On Mon, Jun 8, 2015 at 7:14 AM, Krzysztof Kozlowski
>  wrote:
>
> [...]
>
>>
>> To summarize my point of view:
>> 1. Unless Vivek's says otherwise, please give him the credits with
>> proper "from" field.
>> 2. Issues mentioned in previous mail should be addressed (missing
>> IS_ERR(), how disabling the regulator during suspend affects waking
>> up).
>> 3. The patchset must be tested, even after rebasing.
>>
>
> Agreed with all the points.
>
> Anand,
>
> An easy way to preserve authorship when rebasing patches is to use the
> git command author option. As an example you can execute the following
> command:
>
> $ git commit -a -s --author='Vivek Gautam '

By default "git am" and "git format-patch" preserve the author of a
patch so usually this step is not necessary. Unless the patch is
applied in a different way... :)

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

Re: [PATCH] x86/asm/entry/32: Reinstate clearing of pt_regs->r8..r11 on EFAULT path

[Ingo Molnar]

* Denys Vlasenko  wrote:

> I broke this recently when I changed pt_regs->r8..r11 clearing logic
> in INT 80 code path.
> 
> There is a branch from SYSENTER/SYSCALL code to INT 80 code:
> if we fail to retrieve arg6, we return EFAULT. Before this patch,
> in this case we don't clear pt_regs->r8..r11.
> 
> This patch fixes this. The resulting code is smaller and simpler.

So how did you notice this bug - through actual info leak testing, or review?

Thanks,

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

Re: NILFS2: double uuid

[Heinz Diehl]

On 08.06.2015, Heinz Diehl wrote: 

> [root@keera ~]# lsblk -f
> NAMEFSTYPE LABEL UUID MOUNTPOINT
> sdb  ff17dda9-fcae-42e7-a438-9087de58902e 
>  
> `-sdb1  xfs  ff17dda9-fcae-42e7-a438-9087de58902e 

Copy error: replace xfs with nilfs2. Sorry!



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

Re: [PATCH V2] wan: dscc4: use msecs_to_jiffies for conversions

[David Miller]

From: Nicholas Mc Guire 
Date: Sun,  7 Jun 2015 12:35:46 +0200

> API compliance scanning with coccinelle flagged:
> ./drivers/net/wan/dscc4.c:1036:1-33:
> WARNING: timeout (10) seems HZ dependent
> ./drivers/net/wan/dscc4.c:554:2-34:
> WARNING: timeout (10) seems HZ dependent
> ./drivers/net/wan/dscc4.c:599:2-34:
> WARNING: timeout (10) seems HZ dependent
> 
> Numeric constants passed to schedule_timeout_*() make the effective
> timeout HZ dependent which does not seem to be the intent here.
> Fixed up by converting the constant to jiffies with msecs_to_jiffies(),
> passing 100ms (assuming HZ==100 in the original code).
> 
> Signed-off-by: Nicholas Mc Guire 

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

Re: [PATCH] cosa: use msecs_to_jiffies for conversions

[David Miller]

From: Nicholas Mc Guire 
Date: Sun, 7 Jun 2015 10:25:58 +0200

> for the dscc4 case Im not sure - that seems to have gone in in 2.4
> and that had HZ configurable. The cosa case was checked 
> again 2.2.26 (no config HZ) and the timeout there was 30 -> 300ms.
> 
> I think that this is consistent with respect to the limited available
> information of the timeout unit in the code.

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

[PATCH] mm/memory hotplug: print the last vmemmap region at the end of hot add memory

[Zhu Guihua]

When hot add two nodes continuously, we found the vmemmap region info is a
bit messed. The last region of node 2 is printed when node 3 hot added,
like the following:
Initmem setup node 2 [mem 0x-0x]
 On node 2 totalpages: 0
 Built 2 zonelists in Node order, mobility grouping on.  Total pages: 16090539
 Policy zone: Normal
 init_memory_mapping: [mem 0x400-0x407]
  [mem 0x400-0x407] page 1G
  [ea10-ea10001f] PMD -> 
[8a077d80-8a077d9f] on node 2
  [ea100020-ea10003f] PMD -> 
[8a077de0-8a077dff] on node 2
...
  [ea101f60-ea101f9f] PMD -> 
[8a074ac0-8a074aff] on node 2
  [ea101fa0-ea101fdf] PMD -> 
[8a074a80-8a074abf] on node 2
Initmem setup node 3 [mem 0x-0x]
 On node 3 totalpages: 0
 Built 3 zonelists in Node order, mobility grouping on.  Total pages: 16090539
 Policy zone: Normal
 init_memory_mapping: [mem 0x600-0x607]
  [mem 0x600-0x607] page 1G
  [ea101fe0-ea101fff] PMD -> 
[8a074a40-8a074a5f] on node 2 <=== node 2 ???
  [ea18-ea18001f] PMD -> 
[8a074a60-8a074a7f] on node 3
  [ea180020-ea18005f] PMD -> 
[8a074a00-8a074a3f] on node 3
  [ea180060-ea18009f] PMD -> 
[8a0749c0-8a0749ff] on node 3
...

The cause is the last region was missed at the and of hot add memory, and
p_start, p_end, node_start were not reset, so when hot add memory to a new
node, it will consider they are not contiguous blocks and print the
previous one. So we print the last vmemmap region at the end of hot add
memory to avoid the confusion.

Signed-off-by: Zhu Guihua 
---
 mm/memory_hotplug.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/mm/memory_hotplug.c b/mm/memory_hotplug.c
index 457bde5..58fb223 100644
--- a/mm/memory_hotplug.c
+++ b/mm/memory_hotplug.c
@@ -513,6 +513,7 @@ int __ref __add_pages(int nid, struct zone *zone, unsigned 
long phys_start_pfn,
break;
err = 0;
}
+   vmemmap_populate_print_last();
 
return err;
 }
-- 
1.9.3

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

Re: [RESEND 1/2] usb: ehci-exynos: Make provision for vdd regulators

[Javier Martinez Canillas]

Hello,

On Mon, Jun 8, 2015 at 7:14 AM, Krzysztof Kozlowski
 wrote:

[...]

>
> To summarize my point of view:
> 1. Unless Vivek's says otherwise, please give him the credits with
> proper "from" field.
> 2. Issues mentioned in previous mail should be addressed (missing
> IS_ERR(), how disabling the regulator during suspend affects waking
> up).
> 3. The patchset must be tested, even after rebasing.
>

Agreed with all the points.

Anand,

An easy way to preserve authorship when rebasing patches is to use the
git command author option. As an example you can execute the following
command:

$ git commit -a -s --author='Vivek Gautam '

> Best regards,
> Krzysztof

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

NILFS2: double uuid

[Heinz Diehl]

Hi,

a nilfs2 formatted disk fails to mount via fstab due to double uuid's.
See lsblk output below. The logs indicate that the system attempts to
mount /dev/sdb rather than /dev/sdb1, which of course fails. In
addition, /dev/sdb should not have any uuid at all. Don't know why
that happens.

The phenomenon is easily reproducible: format a partition with nilfs2,
register it with the proper uuid in fstab and reboot. Tried both with
USB memory and real HDD.

[root@keera ~]# lsblk -f
NAMEFSTYPE LABEL UUID MOUNTPOINT
sdb  ff17dda9-fcae-42e7-a438-9087de58902e   
   
`-sdb1  xfs  ff17dda9-fcae-42e7-a438-9087de58902e 

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

Re: [PATCH V2 2/3] tty: serial: fsl_lpuart: remove RTS/CTS control from set/get_mctrl

[Uwe Kleine-König]

Hello,

On Mon, Jun 01, 2015 at 10:51:06AM +0530, Bhuvanchandra DV wrote:
> The LPUART does not provide manual control of RTS/CTS signals,
> those can only be controlled by the hardware directly. Therefore
> manual control of those signals through mctrl can not be provided.
> The current implementation enables/disables the automatic control,
> which is not what mctrl should do, hence remove the incorrect
> implementation.
> 
> Signed-off-by: Bhuvanchandra DV 
> ---
>  drivers/tty/serial/fsl_lpuart.c | 63 
> +
>  1 file changed, 7 insertions(+), 56 deletions(-)
> 
> diff --git a/drivers/tty/serial/fsl_lpuart.c b/drivers/tty/serial/fsl_lpuart.c
> index 08ce76f..532cfb7 100644
> --- a/drivers/tty/serial/fsl_lpuart.c
> +++ b/drivers/tty/serial/fsl_lpuart.c
> @@ -822,64 +822,15 @@ static unsigned int lpuart32_tx_empty(struct uart_port 
> *port)
>  
>  static unsigned int lpuart_get_mctrl(struct uart_port *port)
>  {
> - unsigned int temp = 0;
> - unsigned char reg;
> -
> - reg = readb(port->membase + UARTMODEM);
> - if (reg & UARTMODEM_TXCTSE)
> - temp |= TIOCM_CTS;
> -
> - if (reg & UARTMODEM_RXRTSE)
> - temp |= TIOCM_RTS;
> -
> - return temp;
>From reading the commit log I would expect that you only touch the
set_mctrl function, but not get_mctrl. Assuming your code change is
right, can you mention this in the commit log please? The bits
UARTMODEM_TXCTSE and UARTMODEM_RXRTSE only control the automatic mode?

What is the problem you're fixing here? I'm not sure how such an UART
should be handled, but I imagine that you want to make use of automatic
mode in some cases. Greg?

Best regards
Uwe

-- 
Pengutronix e.K.   | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/  |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] added device tree support to gpio-generic driver

[Alexandre Courbot]

On Mon, Jun 8, 2015 at 3:26 PM, Romain Baeriswyl
 wrote:
>
>
> On 2015-06-08 06:19, Alexandre Courbot wrote:
>> On Fri, Jun 5, 2015 at 3:51 PM, Romain Baeriswyl
>>  wrote:
>>> ---
>>
>> Your patch is missing a detailed commit message.
>>
>>>  .../devicetree/bindings/gpio/gpio-generic.txt  |   19 +
>>>  drivers/gpio/gpio-generic.c|   81 
>>> ++-
>>>  2 files changed, 78 insertions(+), 22 deletions(-)
>>>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-generic.txt
>>>
>>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-generic.txt 
>>> b/Documentation/devicetree/bindings/gpio/gpio-generic.txt
>>> new file mode 100644
>>> index 000..c2c4b98
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/gpio/gpio-generic.txt
>>> @@ -0,0 +1,19 @@
>>> +Bindings for gpio-generic
>>> +
>>> +Required properties:
>>> +- compatible : "basic-mmio-gpio" for little endian register access or
>>> +   "basic-mmio-gpio-be" for big endian register access
>>> +- ngpios: Specifies the number of gpio mapped in the register. The value is
>>> +  limited to the number of bits of the LONG type.
>>> +
>>> +Optional properties:
>>> +- base: Allows to forces the gpio number base offset used to index the 
>>> gpio in
>>> +the device. If it is not see then the driver search autonoumously 
>>> for
>>> +valid index range.
>>
>> A base property for GPIO drivers is frown upon nowadays. >:/
>>
> OK, I will remove it.
>
>>> +
>>> +Examples:
>>> +
>>> +   gpio_a {
>>> +   compatible = "basic-mmio-gpio";
>>> +   ngpios = <32>;
>>> +   };
>>> diff --git a/drivers/gpio/gpio-generic.c b/drivers/gpio/gpio-generic.c
>>> index b92a690..9a4354c 100644
>>> --- a/drivers/gpio/gpio-generic.c
>>> +++ b/drivers/gpio/gpio-generic.c
>>> @@ -15,11 +15,11 @@
>>>   *  `.just a single "data" register, where GPIO state can be read and/or `
>>>   *`,..written. ,,..`` .``.`.`.~~.```.`.``.```
>>>   *`
>>> -___
>>> -_/~~|___/~|   . ```~~   ___/___\___ ,~.`.`.`.`.~~......
>>> -__|~$@~~~%~/o*o*o*o*o*o\   .. Implementing such a GPIO 
>>> .
>>> -o` \___/` controller in FPGA is ,.`
>>> - `trivial..'~`.```.```
>>> + *   ___
>>> + * _/~~|___/~|   . ```~~   ___/___\___ 
>>> ,~.`.`.`.`.~~......
>>> + * __|~$@~~~%~/o*o*o*o*o*o\   .. Implementing such a 
>>> GPIO .
>>> + * o` \___/` controller in FPGA is 
>>> ,.`
>>> + *`trivial..'~`.```.```
>>
>> Comment fix? Why not, but this is not related to the subject of this
>> patch. Please do this in a separate patch.
>>
> I just added the '*' to have the checkpatch.pl passing.

Would be great as the first patch of your series then. :P

>
>>>   *```
>>>   *  .````..`.``.``.
>>>   * .  The driver supports  `...   
>>> ,..```.`~~~```.``,,
>>> @@ -61,6 +61,8 @@ o` \___/` 
>>> controller in FPGA is ,.`
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>> +#include 
>>>
>>>  static void bgpio_write8(void __iomem *reg, unsigned long data)
>>>  {
>>> @@ -375,10 +377,9 @@ static int bgpio_setup_accessors(struct device *dev,
>>> dev_err(dev,
>>> "64 bit big endian byte order 
>>> unsupported\n");
>>> return -EINVAL;
>>> -   } else {
>>> -   bgc->read_reg   = bgpio_read64;
>>> -   bgc->write_reg  = bgpio_write64;
>>> }
>>> +   bgc->read_reg   = bgpio_read64;
>>> +   bgc->write_reg  = bgpio_write64;
>>
>> Why change this? This if/else sequence was consistent with the other
>> cases, I think it would be better to keep it that way.
>>
> The else is actually not required as there is a return in the first
> case. This change was also suggested by checkpatch.pl.

checkpatch is a useful script, but at the end of the day you still
should apply your judgment to know whether what it suggests actually
makes sense or not. In this case, I would favor code consistency over
arbitrary rules.

>
>>> break;
>>>  #endif /* BITS_PER_LONG >= 64 */
>>> default:
>>> @@ -564,6 +565,27 @@ static void __iomem *bgpio_map(struct platform_device 
>>> *pdev,
>>> return ret;
>>>  }
>>>
>>> +static const struct platform_device_id bgpio_id_table[] = {
>>> +   { "basic-mmio-gpio",
>>> + .driver_data  = 0,
>>> +   }, { "basic-mmio-gpio-be",
>>> + .driver_data  = BGPIOF_BIG_ENDIAN
>>> +   },
>>> +   { }

Re: [PATCH] added device tree support to gpio-generic driver

[Romain Baeriswyl]

On 2015-06-08 06:19, Alexandre Courbot wrote:
> On Fri, Jun 5, 2015 at 3:51 PM, Romain Baeriswyl
>  wrote:
>> ---
> 
> Your patch is missing a detailed commit message.
> 
>>  .../devicetree/bindings/gpio/gpio-generic.txt  |   19 +
>>  drivers/gpio/gpio-generic.c|   81 
>> ++-
>>  2 files changed, 78 insertions(+), 22 deletions(-)
>>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-generic.txt
>>
>> diff --git a/Documentation/devicetree/bindings/gpio/gpio-generic.txt 
>> b/Documentation/devicetree/bindings/gpio/gpio-generic.txt
>> new file mode 100644
>> index 000..c2c4b98
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/gpio/gpio-generic.txt
>> @@ -0,0 +1,19 @@
>> +Bindings for gpio-generic
>> +
>> +Required properties:
>> +- compatible : "basic-mmio-gpio" for little endian register access or
>> +   "basic-mmio-gpio-be" for big endian register access
>> +- ngpios: Specifies the number of gpio mapped in the register. The value is
>> +  limited to the number of bits of the LONG type.
>> +
>> +Optional properties:
>> +- base: Allows to forces the gpio number base offset used to index the gpio 
>> in
>> +the device. If it is not see then the driver search autonoumously 
>> for
>> +valid index range.
> 
> A base property for GPIO drivers is frown upon nowadays. >:/
> 
OK, I will remove it.

>> +
>> +Examples:
>> +
>> +   gpio_a {
>> +   compatible = "basic-mmio-gpio";
>> +   ngpios = <32>;
>> +   };
>> diff --git a/drivers/gpio/gpio-generic.c b/drivers/gpio/gpio-generic.c
>> index b92a690..9a4354c 100644
>> --- a/drivers/gpio/gpio-generic.c
>> +++ b/drivers/gpio/gpio-generic.c
>> @@ -15,11 +15,11 @@
>>   *  `.just a single "data" register, where GPIO state can be read and/or `
>>   *`,..written. ,,..`` .``.`.`.~~.```.`.``.```
>>   *`
>> -___
>> -_/~~|___/~|   . ```~~   ___/___\___ ,~.`.`.`.`.~~......
>> -__|~$@~~~%~/o*o*o*o*o*o\   .. Implementing such a GPIO .
>> -o` \___/` controller in FPGA is ,.`
>> - `trivial..'~`.```.```
>> + *   ___
>> + * _/~~|___/~|   . ```~~   ___/___\___ 
>> ,~.`.`.`.`.~~......
>> + * __|~$@~~~%~/o*o*o*o*o*o\   .. Implementing such a 
>> GPIO .
>> + * o` \___/` controller in FPGA is 
>> ,.`
>> + *`trivial..'~`.```.```
> 
> Comment fix? Why not, but this is not related to the subject of this
> patch. Please do this in a separate patch.
> 
I just added the '*' to have the checkpatch.pl passing.

>>   *```
>>   *  .````..`.``.``.
>>   * .  The driver supports  `...   
>> ,..```.`~~~```.``,,
>> @@ -61,6 +61,8 @@ o` \___/` 
>> controller in FPGA is ,.`
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>> +#include 
>>
>>  static void bgpio_write8(void __iomem *reg, unsigned long data)
>>  {
>> @@ -375,10 +377,9 @@ static int bgpio_setup_accessors(struct device *dev,
>> dev_err(dev,
>> "64 bit big endian byte order 
>> unsupported\n");
>> return -EINVAL;
>> -   } else {
>> -   bgc->read_reg   = bgpio_read64;
>> -   bgc->write_reg  = bgpio_write64;
>> }
>> +   bgc->read_reg   = bgpio_read64;
>> +   bgc->write_reg  = bgpio_write64;
> 
> Why change this? This if/else sequence was consistent with the other
> cases, I think it would be better to keep it that way.
> 
The else is actually not required as there is a return in the first
case. This change was also suggested by checkpatch.pl.

>> break;
>>  #endif /* BITS_PER_LONG >= 64 */
>> default:
>> @@ -564,6 +565,27 @@ static void __iomem *bgpio_map(struct platform_device 
>> *pdev,
>> return ret;
>>  }
>>
>> +static const struct platform_device_id bgpio_id_table[] = {
>> +   { "basic-mmio-gpio",
>> + .driver_data  = 0,
>> +   }, { "basic-mmio-gpio-be",
>> + .driver_data  = BGPIOF_BIG_ENDIAN
>> +   },
>> +   { },
>> +};
> 
> Formatting is wrong here. Please keep the same formatting as the
> original statement.
> 
OK

>> +MODULE_DEVICE_TABLE(platform, bgpio_id_table);
>> +
>> +static const struct of_device_id  bgpio_dt_ids[] = {
>> +   { .compatible = "basic-mmio-gpio",
> 
> Same remark about formatting.
> 
>> + .data = bgpio_id_table + 0
> 
> I would probably prefer &bgpio_id_table[0], but your call.
> 
>> +   },
>> +   { .compatible = "basic-mmio-g

RE: [PATCH] qla4xxx: pass timeout as HZ independent value

[Nilesh Javali]

> -Original Message-
> From: Nicholas Mc Guire [mailto:hof...@osadl.org]
> Sent: Thursday, May 28, 2015 1:40 AM
> To: Dept-Eng QLogic Storage Upstream
> Cc: James E.J. Bottomley; linux-scsi; linux-kernel; Nicholas Mc Guire
> Subject: [PATCH] qla4xxx: pass timeout as HZ independent value
> 
> schedule_timeout_* takes a timeout in jiffies but the code currently is
> passing in a constant which makes this timeout HZ dependent, so pass it
> through msecs_to_jiffies() to fix this up.
> 
> patch was compile tested with x86_64_defconfig + SCSI_LOWLEVEL=y,
> CONFIG_SCSI_QLA_ISCSI=m
> 
> Patch is against 4.1-rc5 (localversion-next is -next-20150527)
> 
> Signed-off-by: Nicholas Mc Guire 
> ---
> 
> As there is no documentation of the intended timeout it might be wrong to
> convert it with msecs_to_jiffies as this can reduces the actual jiffies value 
> by
> at least a factor of 10 - so someone that knows this driver needs to check on
> the actual value - but in any case it needs to be passed in a HZ independent
> way.
> 
>  drivers/scsi/qla4xxx/ql4_nx.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/scsi/qla4xxx/ql4_nx.c b/drivers/scsi/qla4xxx/ql4_nx.c
> index 7c33658..7b53eab 100644
> --- a/drivers/scsi/qla4xxx/ql4_nx.c
> +++ b/drivers/scsi/qla4xxx/ql4_nx.c
> @@ -1569,7 +1569,7 @@ static int qla4_82xx_cmdpeg_ready(struct
> scsi_qla_host *ha, int pegtune_val)
>   (val == PHAN_INITIALIZE_ACK))
>   return 0;
>   set_current_state(TASK_UNINTERRUPTIBLE);
> - schedule_timeout(500);
> + schedule_timeout(msecs_to_jiffies(500));
> 
>   } while (--retries);
> 
> --
> 1.7.10.4

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

[PATCH] usb: gadget: nokia: Add mass storage driver to g_nokia

[Pali Rohár]

This patch adds removable mass storage support to g_nokia gadget (for N900).
It means that at runtime block device can be exported or unexported.
So it does not export anything by default and thus allows to use MyDocs
partition as before...

Signed-off-by: Pali Rohár 
---
 drivers/usb/gadget/legacy/Kconfig |1 +
 drivers/usb/gadget/legacy/nokia.c |  102 -
 2 files changed, 102 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/gadget/legacy/Kconfig 
b/drivers/usb/gadget/legacy/Kconfig
index d5a7102..ddef41f 100644
--- a/drivers/usb/gadget/legacy/Kconfig
+++ b/drivers/usb/gadget/legacy/Kconfig
@@ -346,6 +346,7 @@ config USB_G_NOKIA
select USB_F_OBEX
select USB_F_PHONET
select USB_F_ECM
+   select USB_F_MASS_STORAGE
help
  The Nokia composite gadget provides support for acm, obex
  and phonet in only one composite gadget driver.
diff --git a/drivers/usb/gadget/legacy/nokia.c 
b/drivers/usb/gadget/legacy/nokia.c
index 4bb498a..021c8d9 100644
--- a/drivers/usb/gadget/legacy/nokia.c
+++ b/drivers/usb/gadget/legacy/nokia.c
@@ -24,6 +24,7 @@
 #include "u_phonet.h"
 #include "u_ecm.h"
 #include "gadget_chips.h"
+#include "f_mass_storage.h"
 
 /* Defines */
 
@@ -34,6 +35,29 @@ USB_GADGET_COMPOSITE_OPTIONS();
 
 USB_ETHERNET_MODULE_PARAMETERS();
 
+static struct fsg_module_parameters fsg_mod_data = {
+   .stall = 0,
+   .luns = 2,
+   .removable_count = 2,
+   .removable = { 1, 1, },
+};
+
+FSG_MODULE_PARAMETERS(/* no prefix */, fsg_mod_data);
+
+#ifdef CONFIG_USB_GADGET_DEBUG_FILES
+
+static unsigned int fsg_num_buffers = CONFIG_USB_GADGET_STORAGE_NUM_BUFFERS;
+
+#else
+
+/*
+ * Number of buffers we will use.
+ * 2 is usually enough for good buffering pipeline
+ */
+#define fsg_num_buffersCONFIG_USB_GADGET_STORAGE_NUM_BUFFERS
+
+#endif /* CONFIG_USB_DEBUG */
+
 #define NOKIA_VENDOR_ID0x0421  /* Nokia */
 #define NOKIA_PRODUCT_ID   0x01c8  /* Nokia Gadget */
 
@@ -94,6 +118,8 @@ static struct usb_function *f_obex1_cfg2;
 static struct usb_function *f_obex2_cfg2;
 static struct usb_function *f_phonet_cfg1;
 static struct usb_function *f_phonet_cfg2;
+static struct usb_function *f_msg_cfg1;
+static struct usb_function *f_msg_cfg2;
 
 
 static struct usb_configuration nokia_config_500ma_driver = {
@@ -117,6 +143,7 @@ static struct usb_function_instance *fi_ecm;
 static struct usb_function_instance *fi_obex1;
 static struct usb_function_instance *fi_obex2;
 static struct usb_function_instance *fi_phonet;
+static struct usb_function_instance *fi_msg;
 
 static int nokia_bind_config(struct usb_configuration *c)
 {
@@ -125,6 +152,8 @@ static int nokia_bind_config(struct usb_configuration *c)
struct usb_function *f_obex1 = NULL;
struct usb_function *f_ecm;
struct usb_function *f_obex2 = NULL;
+   struct usb_function *f_msg;
+   struct fsg_opts *fsg_opts;
int status = 0;
int obex1_stat = -1;
int obex2_stat = -1;
@@ -160,6 +189,12 @@ static int nokia_bind_config(struct usb_configuration *c)
goto err_get_ecm;
}
 
+   f_msg = usb_get_function(fi_msg);
+   if (IS_ERR(f_msg)) {
+   status = PTR_ERR(f_msg);
+   goto err_get_msg;
+   }
+
if (!IS_ERR_OR_NULL(f_phonet)) {
phonet_stat = usb_add_function(c, f_phonet);
if (phonet_stat)
@@ -187,21 +222,36 @@ static int nokia_bind_config(struct usb_configuration *c)
pr_debug("could not bind ecm config %d\n", status);
goto err_ecm;
}
+
+   fsg_opts = fsg_opts_from_func_inst(fi_msg);
+
+   status = fsg_common_run_thread(fsg_opts->common);
+   if (status)
+   goto err_msg;
+
+   status = usb_add_function(c, f_msg);
+   if (status)
+   goto err_msg;
+
if (c == &nokia_config_500ma_driver) {
f_acm_cfg1 = f_acm;
f_ecm_cfg1 = f_ecm;
f_phonet_cfg1 = f_phonet;
f_obex1_cfg1 = f_obex1;
f_obex2_cfg1 = f_obex2;
+   f_msg_cfg1 = f_msg;
} else {
f_acm_cfg2 = f_acm;
f_ecm_cfg2 = f_ecm;
f_phonet_cfg2 = f_phonet;
f_obex1_cfg2 = f_obex1;
f_obex2_cfg2 = f_obex2;
+   f_msg_cfg2 = f_msg;
}
 
return status;
+err_msg:
+   usb_remove_function(c, f_ecm);
 err_ecm:
usb_remove_function(c, f_acm);
 err_conf:
@@ -211,6 +261,8 @@ err_conf:
usb_remove_function(c, f_obex1);
if (!phonet_stat)
usb_remove_function(c, f_phonet);
+   usb_put_function(f_msg);
+err_get_msg:
usb_put_function(f_ecm);
 err_get_ecm:
usb_put_function(f_acm);
@@ -227,6 +279,8 @@ err_get_acm:
 static int nokia_bind(struct usb_composite_dev *cdev)
 {
struct usb_gadget   

[GIT PULL] libata fixes for v4.1-rc7

[Tejun Heo]

Hello, Linus.

This contains one ahci_mvebu fix commit for a controller config bug.

Thanks.

The following changes since commit dbfe8ef5599a5370abc441fcdbb382b656563eb4:

  ahci: avoton port-disable reset-quirk (2015-05-10 11:39:16 -0400)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata.git for-4.1-fixes

for you to fetch changes up to e96998fc200867f005dd14c7d1dd35e1107d4914:

  ata: ahci_mvebu: Fix wrongly set base address for the MBus window setting 
(2015-05-26 14:46:15 -0400)


Nadav Haklai (1):
  ata: ahci_mvebu: Fix wrongly set base address for the MBus window setting

 drivers/ata/ahci_mvebu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

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

Re: [PATCH] rtl8723au: replaced asm/atomic.h by linux/atomic.h

[Kalle Valo]

Xavier Roche  writes:

> Minor additional checkpatch.pl fix for include/rtw_io.h
>
> Signed-off-by: Xavier Roche 
> ---
>  drivers/staging/rtl8723au/include/rtw_io.h | 2 +-

For staging patches please prefix the title "staging: " so that people
will realise that this a patch for a driver in staging. So this should
be renamed to "staging: rtl8723au: replaced asm/atomic.h by
linux/atomic.h".

Here's a tip how you can check what commit title you should use:

git log --oneline drivers/staging/rtl8723au/include/rtw_io.h

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

Re: [PATCH] [media] s5k5baf: Convert use of __constant_cpu_to_be16 to cpu_to_be16

[Andrzej Hajda]

On 06/06/2015 03:53 AM, Vaishali Thakkar wrote:
> In little endian cases, macro cpu_to_be16 unfolds to __swab16 which
> provides special case for constants. In big endian cases,
> __constant_cpu_to_be16 and cpu_to_be16 expand directly to the
> same expression. So, replace __constant_cpu_to_be16 with
> cpu_to_be16 with the goal of getting rid of the definition of
> __constant_cpu_to_be16 completely.
>
> The semantic patch that performs this transformation is as follows:
>
> @@expression x;@@
>
> - __constant_cpu_to_be16(x)
> + cpu_to_be16(x)
>
> Signed-off-by: Vaishali Thakkar 
Reviewed-by: Andrzej Hajda 

> ---
>  drivers/media/i2c/s5k5baf.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/i2c/s5k5baf.c b/drivers/media/i2c/s5k5baf.c
> index 297ef04..7a43b55 100644
> --- a/drivers/media/i2c/s5k5baf.c
> +++ b/drivers/media/i2c/s5k5baf.c
> @@ -491,7 +491,7 @@ static void s5k5baf_write_arr_seq(struct s5k5baf *state, 
> u16 addr,
>   v4l2_dbg(3, debug, c, "i2c_write_seq(count=%d): %*ph\n", count,
>min(2 * count, 64), seq);
>  
> - buf[0] = __constant_cpu_to_be16(REG_CMD_BUF);
> + buf[0] = cpu_to_be16(REG_CMD_BUF);
>  
>   while (count > 0) {
>   int n = min_t(int, count, ARRAY_SIZE(buf) - 1);

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

Re: [PATCH V2 0/3] Add RS-485 support and fix RTS/CTS implementation

[Bhuvanchandra DV]

Hello,

Ping!

On 06/01/2015 10:51 AM, Bhuvanchandra DV wrote:

Changes since V1:
Use common get/set mctrl control methods for both lpuart, lpuart32
and fix indention.

Bhuvanchandra DV (3):
   ARM: dts: colibri-vf: Add pinmux for UART_0 aka UART_A RTS/CTS pins
   tty: serial: fsl_lpuart: remove RTS/CTS control from set/get_mctrl
   tty: serial: fsl_lpuart: Add support for RS-485

  arch/arm/boot/dts/vf-colibri.dtsi |   2 +
  drivers/tty/serial/fsl_lpuart.c   | 103 --
  2 files changed, 57 insertions(+), 48 deletions(-)


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

[PATCH block/for-4.2-writeback] v9fs: fix error handling in v9fs_session_init()

[Tejun Heo]

On failure, v9fs_session_init() returns with the v9fs_session_info
struct partially initialized and expects the caller to invoke
v9fs_session_close() to clean it up; however, it doesn't track whether
the bdi is initialized or not and curiously invokes bdi_destroy() in
both vfs_session_init() failure path too.

A. If v9fs_session_init() fails before the bdi is initialized, the
   follow-up v9fs_session_close() will invoke bdi_destroy() on an
   uninitialized bdi.

B. If v9fs_session_init() fails after the bdi is initialized,
   bdi_destroy() will be called twice on the same bdi - once in the
   failure path of v9fs_session_init() and then by
   v9fs_session_close().

A is broken no matter what.  B used to be okay because bdi_destroy()
allowed being invoked multiple times on the same bdi, which BTW was
broken in its own way - if bdi_destroy() was invoked on an initialiezd
but !registered bdi, it'd fail to free percpu counters.  Since
f0054bb1e1f3 ("writeback: move backing_dev_info->wb_lock and
->worklist into bdi_writeback"), this no longer work - bdi_destroy()
on an initialized but not registered bdi works correctly but multiple
invocations of bdi_destroy() is no longer allowed.

The obvious culprit here is v9fs_session_init()'s odd and broken error
behavior.  It should simply clean up after itself on failures.  This
patch makes the following updates to v9fs_session_init().

* @rc -> @retval error return propagation removed.  It didn't serve
  any purpose.  Just use @rc.

* Move addition to v9fs_sessionlist to the end of the function so that
  incomplete sessions are not put on the list or iterated and error
  path doesn't have to worry about it.

* Update error handling so that it cleans up after itself.

Signed-off-by: Tejun Heo 
Reported-by: Sasha Levin 
---
 fs/9p/v9fs.c  |   50 ++
 fs/9p/vfs_super.c |8 ++--
 2 files changed, 24 insertions(+), 34 deletions(-)

diff --git a/fs/9p/v9fs.c b/fs/9p/v9fs.c
index 620d934..8aa56bb 100644
--- a/fs/9p/v9fs.c
+++ b/fs/9p/v9fs.c
@@ -320,31 +320,21 @@ static int v9fs_parse_options(struct v9fs_session_info 
*v9ses, char *opts)
 struct p9_fid *v9fs_session_init(struct v9fs_session_info *v9ses,
  const char *dev_name, char *data)
 {
-   int retval = -EINVAL;
struct p9_fid *fid;
-   int rc;
+   int rc = -ENOMEM;
 
v9ses->uname = kstrdup(V9FS_DEFUSER, GFP_KERNEL);
if (!v9ses->uname)
-   return ERR_PTR(-ENOMEM);
+   goto err_names;
 
v9ses->aname = kstrdup(V9FS_DEFANAME, GFP_KERNEL);
-   if (!v9ses->aname) {
-   kfree(v9ses->uname);
-   return ERR_PTR(-ENOMEM);
-   }
+   if (!v9ses->aname)
+   goto err_names;
init_rwsem(&v9ses->rename_sem);
 
rc = bdi_setup_and_register(&v9ses->bdi, "9p");
-   if (rc) {
-   kfree(v9ses->aname);
-   kfree(v9ses->uname);
-   return ERR_PTR(rc);
-   }
-
-   spin_lock(&v9fs_sessionlist_lock);
-   list_add(&v9ses->slist, &v9fs_sessionlist);
-   spin_unlock(&v9fs_sessionlist_lock);
+   if (rc)
+   goto err_names;
 
v9ses->uid = INVALID_UID;
v9ses->dfltuid = V9FS_DEFUID;
@@ -352,10 +342,9 @@ struct p9_fid *v9fs_session_init(struct v9fs_session_info 
*v9ses,
 
v9ses->clnt = p9_client_create(dev_name, data);
if (IS_ERR(v9ses->clnt)) {
-   retval = PTR_ERR(v9ses->clnt);
-   v9ses->clnt = NULL;
+   rc = PTR_ERR(v9ses->clnt);
p9_debug(P9_DEBUG_ERROR, "problem initializing 9p client\n");
-   goto error;
+   goto err_bdi;
}
 
v9ses->flags = V9FS_ACCESS_USER;
@@ -368,10 +357,8 @@ struct p9_fid *v9fs_session_init(struct v9fs_session_info 
*v9ses,
}
 
rc = v9fs_parse_options(v9ses, data);
-   if (rc < 0) {
-   retval = rc;
-   goto error;
-   }
+   if (rc < 0)
+   goto err_clnt;
 
v9ses->maxdata = v9ses->clnt->msize - P9_IOHDRSZ;
 
@@ -405,10 +392,9 @@ struct p9_fid *v9fs_session_init(struct v9fs_session_info 
*v9ses,
fid = p9_client_attach(v9ses->clnt, NULL, v9ses->uname, INVALID_UID,
v9ses->aname);
if (IS_ERR(fid)) {
-   retval = PTR_ERR(fid);
-   fid = NULL;
+   rc = PTR_ERR(fid);
p9_debug(P9_DEBUG_ERROR, "cannot attach\n");
-   goto error;
+   goto err_clnt;
}
 
if ((v9ses->flags & V9FS_ACCESS_MASK) == V9FS_ACCESS_SINGLE)
@@ -420,12 +406,20 @@ struct p9_fid *v9fs_session_init(struct v9fs_session_info 
*v9ses,
/* register the session for caching */
v9fs_cache_session_get_cookie(v9ses);
 #endif
+   spin_lock(&v9fs_sessionlist_lock);
+   list_add(&v9ses->slist, &v9fs_sessionlist);
+   spin_unlock(&v

[BUG, bisect] Re: drm/i915: WARN_ON(dev_priv->mm.busy)

[Jeremiah Mahler]

all,

On Sat, Jun 06, 2015 at 08:09:34PM -0700, Jeremiah Mahler wrote:
> all,
> 
> On all my machines with Intel graphics I get the following warning
> in the logs when the machine is suspended.  Apparently some part of
> the graphics system is busy when it should be idle. This is present
> on the latest linux-next 20150604.
> 
>   ...
>   [   33.141747] Suspending console(s) (use no_console_suspend to debug)
>   [   33.142146] wlan0: deauthenticating from 00:1a:70:5a:6e:0b by local
>   choice (Reason: 3=DEAUTH_LEAVING)
>   [   33.147395] queueing ieee80211 work while going to suspend
>   [   33.151597] cfg80211: Calling CRDA to update world regulatory domain
>   [   33.190430] sd 0:0:0:0: [sda] Synchronizing SCSI cache
>   [   33.190523] sd 0:0:0:0: [sda] Stopping disk
>   [   33.275743] [ cut here ]
>   [   33.275764] WARNING: CPU: 0 PID: 1617 at
>   drivers/gpu/drm/i915/i915_gem.c:4808 i915_gem_suspend+0xe4/0xf0 [i915]()
>   [   33.275766] WARN_ON(dev_priv->mm.busy)
>   [   33.275811] Modules linked in: binfmt_misc snd_hda_codec_hdmi
>   hid_generic isl29018(C) industrialio regmap_i2c cyapatp crc_itu_t usbhid
>   hid arc4 x86_pkg_temp_thermal intel_powerclamp intel_rapl iosf_mbi
>   coretemp ath9k tpm_infineon kvm_intel kvm ath9k_common ath9k_hw
>   crct10dif_pclmul crc32_pclmul crc32c_intel chromeos_laptop ath mac80211
>   ghash_clmulni_intel cryptd i915 cfg80211 pcspkr serio_raw sg ath3k btusb
>   btrtl lpc_ich snd_hda_codec_realtek shpchp i2c_i801 mfd_core
>   snd_hda_codec_generic btbcm btintel bluetooth snd_hda_intel battery
>   snd_hda_codec ac i2c_algo_bit drm_kms_helper tpm_tis snd_hwdep tpm
>   snd_hda_core drm snd_pcm video rfkill processor button snd_timer snd
>   soundcore i2c_designware_pci i2c_designware_core evdev uvcvideo
>   videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common videodev
>   [   33.275825]  media i2c_core fuse autofs4 ext4 crc16 mbcache jbd2
>   sd_mod fan xhci_pci sdhci_acpi sdhci xhci_hcd mmc_core thermal
>   thermal_sys usbcore ahci libahci usb_common libata scsi_mod
>   [   33.275828] CPU: 0 PID: 1617 Comm: kworker/u4:4 Tainted: G C
>   4.1.0-rc6-next-20150604+ #207
>   [   33.275829] Hardware name: Acer Peppy, BIOS  04/30/2014
>   [   33.275834] Workqueue: events_unbound async_run_entry_fn
>   [   33.275838]   a05b7908 8152ca4d
>   880035effc58
>   [   33.275840]  8106bce1 880073587f20 
>   88007358
>   [   33.275842]  88003534f860 88007358 8106bd5a
>   a05c74c1
>   [   33.275843] Call Trace:
>   [   33.275849]  [] ? dump_stack+0x40/0x50
>   [   33.275853]  [] ? warn_slowpath_common+0x81/0xb0
>   [   33.275855]  [] ? warn_slowpath_fmt+0x4a/0x50
>   [   33.275865]  [] ? i915_gem_suspend+0xe4/0xf0 [i915]
>   [   33.275872]  [] ? i915_drm_suspend+0x61/0x1b0
>   [i915]
>   [   33.275876]  [] ? pci_pm_suspend+0x71/0x140
>   [   33.275878]  [] ? pci_pm_freeze+0xd0/0xd0
>   [   33.275881]  [] ? dpm_run_callback+0x39/0xd0
>   [   33.275883]  [] ? __device_suspend+0xe4/0x300
>   [   33.275884]  [] ? async_suspend+0x1e/0x90
>   [   33.275887]  [] ? async_run_entry_fn+0x43/0x150
>   [   33.275890]  [] ? process_one_work+0x148/0x3b0
>   [   33.275892]  [] ? worker_thread+0x4a/0x440
>   [   33.275895]  [] ? rescuer_thread+0x2e0/0x2e0
>   [   33.275898]  [] ? kthread+0xc1/0xe0
>   [   33.275901]  [] ?
>   kthread_create_on_node+0x190/0x190
>   [   33.275904]  [] ? ret_from_fork+0x3f/0x70
>   [   33.275907]  [] ?
>   kthread_create_on_node+0x190/0x190
>   [   33.275908] ---[ end trace e1c3eb5e163b3520 ]---
>   [   33.560558] PM: suspend of devices complete after 423.034 msecs
>   [   33.577985] PM: late suspend of devices complete after 17.589 msecs
>   [   33.579036] xhci_hcd :00:14.0: System wakeup enabled by ACPI
>   [   33.594059] PM: noirq suspend of devices complete after 16.226 msecs
>   [   33.594498] ACPI: Preparing to enter system sleep state S3
>   [   33.595066] ACPI : EC: EC stopped
>   ...
> 
> -- 
> - Jeremiah Mahler

I bisected the kernel and found that the following patch introduced the
bug.

  From b47161858ba13c9c7e0132230d66e008dd55 Mon Sep 17 00:00:00 2001
  From: Chris Wilson 
  Date: Mon, 27 Apr 2015 13:41:17 +0100
  Subject: [PATCH] drm/i915: Implement inter-engine read-read optimisations
  MIME-Version: 1.0
  Content-Type: text/plain; charset=UTF-8
  Content-Transfer-Encoding: 8bit
  
  Currently, we only track the last request globally across all engines.
  This prevents us from issuing concurrent read requests on e.g. the RCS
  and BCS engines (or more likely the render and media engines). Without
  semaphores, we incur costly stalls as we synchronise between rings -
  greatly impacting the current performance of Broadwell versus Haswell in
  certain workloads (like video decode). With the introduction of
  reference counted requests, it is much easier to track the last request
  per ring, as well as 

Re: [PATCH v5] Fix the resolution issue in ChromeOS

[Dmitry Torokhov]

Hi Hn,

On Fri, May 29, 2015 at 12:27:29PM +0800, HungNien Chen wrote:
> Signed-off-by: HungNien Chen 

Thank you for making changes, I have some more comments. By the way,
have you tried running scripts/checkpatch.pl over your patch? It often
picks up some common issues.

> ---
>  drivers/input/touchscreen/Kconfig   |   12 +
>  drivers/input/touchscreen/Makefile  |1 +
>  drivers/input/touchscreen/wdt87xx_i2c.c | 1404 
> +++
>  3 files changed, 1417 insertions(+)
>  create mode 100644 drivers/input/touchscreen/wdt87xx_i2c.c
> 
> diff --git a/drivers/input/touchscreen/Kconfig 
> b/drivers/input/touchscreen/Kconfig
> index 80f6386..0c1a6cc 100644
> --- a/drivers/input/touchscreen/Kconfig
> +++ b/drivers/input/touchscreen/Kconfig
> @@ -658,6 +658,18 @@ config TOUCHSCREEN_PIXCIR
> To compile this driver as a module, choose M here: the
> module will be called pixcir_i2c_ts.
>  
> +config TOUCHSCREEN_WDT87XX_I2C
> + tristate "Weida HiTech I2C touchscreen"
> + depends on I2C
> + help
> +   Say Y here if you have an Weida WDT87XX I2C touchscreen
> +   connected to your system.
> +
> +   If unsure, say N.
> +
> +   To compile this driver as a module, choose M here: the
> +   module will be called wdt87xx_i2c.
> +
>  config TOUCHSCREEN_WM831X
>   tristate "Support for WM831x touchscreen controllers"
>   depends on MFD_WM831X
> diff --git a/drivers/input/touchscreen/Makefile 
> b/drivers/input/touchscreen/Makefile
> index 44deea7..fa3d33b 100644
> --- a/drivers/input/touchscreen/Makefile
> +++ b/drivers/input/touchscreen/Makefile
> @@ -72,6 +72,7 @@ obj-$(CONFIG_TOUCHSCREEN_TSC2007)   += tsc2007.o
>  obj-$(CONFIG_TOUCHSCREEN_UCB1400)+= ucb1400_ts.o
>  obj-$(CONFIG_TOUCHSCREEN_WACOM_W8001)+= wacom_w8001.o
>  obj-$(CONFIG_TOUCHSCREEN_WACOM_I2C)  += wacom_i2c.o
> +obj-$(CONFIG_TOUCHSCREEN_WDT87XX_I2C)+= wdt87xx_i2c.o
>  obj-$(CONFIG_TOUCHSCREEN_WM831X) += wm831x-ts.o
>  obj-$(CONFIG_TOUCHSCREEN_WM97XX) += wm97xx-ts.o
>  wm97xx-ts-$(CONFIG_TOUCHSCREEN_WM9705)   += wm9705.o
> diff --git a/drivers/input/touchscreen/wdt87xx_i2c.c 
> b/drivers/input/touchscreen/wdt87xx_i2c.c
> new file mode 100644
> index 000..4998ad5
> --- /dev/null
> +++ b/drivers/input/touchscreen/wdt87xx_i2c.c
> @@ -0,0 +1,1404 @@
> +/*
> + * Weida HiTech WDT87xx TouchScreen I2C driver
> + *
> + * Copyright (c) 2015  Weida HiTech Ltd.
> + * HN Chen 
> + *
> + * This software is licensed under the terms of the GNU General Public
> + * License, as published by the Free Software Foundation, and
> + * may be copied, distributed, and modified under those terms.
> + *
> + * Note: this is a I2C device driver and report touch events througt the
> + *   input device
> + */
> +
> +
> +#include 

Yo do not need version.h

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

I do not think you need gpio.h

> +#include 
> +#include 

I do not see why you'd need this.

> +#include 
> +#include 
> +#include 

Not needed it seems.

> +#include 
> +#include 
> +#include 

And definitely not the 2nd copy ;)

> +#include 
> +#include 

Please arrange asm/ includes after linux/ ones.

> +#include 
> +
> +#define WDT87XX_NAME "wdt87xx_i2c"
> +#define  WDT87XX_DRV_VER "0.9.4"
> +#define  WDT87XX_FW_NAME "wdt87xx_fw.bin"
> +
> +#define  WDT87XX_FW  1
> +#define  WDT87XX_CFG 2
> +
> +#define MODE_ACTIVE  0x01
> +#define MODE_READY   0x02
> +#define MODE_IDLE0x03
> +#define MODE_SLEEP   0x04
> +#define  MODE_STOP   0xFF
> +
> +#define  WDT_PKT_V0  0
> +#define  WDT_PKT_V1  1
> +
> +#define WDT_MAX_FINGER   10
> +#define  WDT_RAW_BUF_COUNT   54
> +#define  WDT_V1_RAW_BUF_COUNT74
> +#define WDT_FIRMWARE_ID  0xa9e368f5
> +
> +#define  PG_SIZE 0x1000
> +#define MAX_RETRIES  3
> +
> +#define  MAX_UNIT_AXIS   0x7FFF
> +
> +#define  PKT_READ_SIZE   72
> +#define  PKT_WRITE_SIZE  80
> +
> +/* the definition for one finger */
> +#define  FINGER_EV_OFFSET_ID 0
> +#define  FINGER_EV_OFFSET_X  1
> +#define  FINGER_EV_OFFSET_Y  3
> +#define  FINGER_EV_SIZE  5
> +
> +#define  FINGER_EV_V1_OFFSET_ID  0
> +#define  FINGER_EV_V1_OFFSET_W   1
> +#define  FINGER_EV_V1_OFFSET_H   2
> +#define  FINGER_EV_V1_OFFSET_X   3
> +#define  FINGER_EV_V1_OFFSET_Y   5
> +#define  FINGER_EV_V1_SIZE   7
> +
> +/* the definition for a packet */
> +#define  TOUCH_PK_OFFSET_REPORT_ID   0
> +#define  TOUCH_PK_OFFSET_

Re: [PATCH] RDMA/ocrdma: fix double free on pd

[Devesh Sharma]

Acked-By: Devesh Sharma 

On Fri, Jun 5, 2015 at 8:17 PM, Colin King  wrote:
> From: Colin Ian King 
>
> A reorganisation of the PD allocation and deallocation in commit
> 9ba1377daa ("RDMA/ocrdma: Move PD resource management to driver.")
> introduced a double free on pd, as detected by static analysis by
> smatch:
>
> drivers/infiniband/hw/ocrdma/ocrdma_verbs.c:682 ocrdma_alloc_pd()
>   error: double free of 'pd'^
>
> The original call to ocrdma_mbx_dealloc_pd() (which does not kfree
> pd) was replaced with a call to _ocrdma_dealloc_pd() (which does
> kfree pd).  The kfree following this call causes the double free,
> so just remove it to fix the problem.
>
> Fixes: 9ba1377daa ("RDMA/ocrdma: Move PD resource management to driver.")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c 
> b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> index 9dcb660..219f212 100644
> --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> @@ -679,7 +679,6 @@ err:
> ocrdma_release_ucontext_pd(uctx);
> } else {
> status = _ocrdma_dealloc_pd(dev, pd);
> -   kfree(pd);
> }
>  exit:
> return ERR_PTR(status);
> --
> 2.1.4
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kernel/params.c: make use of unused but set variable

[Louis Langholtz]

On Jun 7, 2015, at 6:17 PM, Linus Torvalds  
wrote:

> On Sun, Jun 7, 2015 at 5:00 PM, Tejun Heo  wrote:
>> On Sun, Jun 07, 2015 at 05:54:30PM -0600, Louis Langholtz wrote:
>>> @@ -853,6 +853,7 @@ static void __init version_sysfs_builtin(void)
>>>  mk = locate_module_kobject(vattr->module_name);
>>>  if (mk) {
>>>  err = sysfs_create_file(&mk->kobj, &vattr->mattr.attr);
>>> + BUG_ON(err);
>> 
>> Maybe BUG_ON(sysfs_create_file(...)); is simpler?  Other than that,
> 
> Hell no.
> 
> Stop with the random BUG_ON() additions.
> ...
> The *ONLY* acceptable reason for a BUG_ON() is if the machine is dead
> anyway because of some major internal corruption.
> ...
> At most, it could be a "WARN_ON_ONCE()"...
> 
>Linus

Agreed. The comments in the bug.h file say this clearly too - to not use
BUG_ON "unless there's really no way out".

I originally just wanted a light-weight message to be issued on failure so
at least there's some notice that something unexpected happened (and
to have the must-check value used). I've submitted a second version
now as you probably saw (that instead uses WARN_ON_ONCE).--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v1 0/2] Implement sample time consideration

[Sanchayan Maity]

Hello,

This patchset adds a dt binding for specifying sample time
for the vybrid adc driver and takes this into account for
sampling frequency calculation and related configuration in
the driver.

The patchset is based on top of Stefan's patches here
http://lkml.iu.edu/hypermail/linux/kernel/1505.3/02043.html

which got recently applied. Tested with shawn's for-next
branch.

Regards,
Sanchayan.

Sanchayan Maity (2):
  iio: adc: Determine sampling frequencies by using minimum sample time
  ARM: dts: vfxxx: Add property for minimum sample time

 .../devicetree/bindings/iio/adc/vf610-adc.txt  |  6 ++
 arch/arm/boot/dts/vfxxx.dtsi   |  2 +
 drivers/iio/adc/vf610_adc.c| 74 --
 3 files changed, 78 insertions(+), 4 deletions(-)

-- 
2.4.2

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

[PATCH v1 1/2] iio: adc: Determine sampling frequencies by using minimum sample time

[Sanchayan Maity]

The driver currently does not take into account the minimum sample time
as per the Figure 6-8 Chapter 9.1.1 12-bit ADC electrical characteristics.
We set a static amount of cycles instead of considering the sample time as
a given value, which depends on hardware characteristics.

Determine sampling frequencies by first reading the device tree property
node and then calculating the required Long Sample Time Adder (LSTAdder)
value based on the ADC clock frequency and sample time value obtained
from the device tree, this LSTAdder value is then used for calculating
the sampling frequencies possible.

Signed-off-by: Sanchayan Maity 
---
 .../devicetree/bindings/iio/adc/vf610-adc.txt  |  6 ++
 drivers/iio/adc/vf610_adc.c| 74 --
 2 files changed, 76 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt 
b/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt
index 3eb40e2..4419126 100644
--- a/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt
+++ b/Documentation/devicetree/bindings/iio/adc/vf610-adc.txt
@@ -17,6 +17,11 @@ Recommended properties:
   - Frequency in normal mode (ADLPC=0, ADHSC=0)
   - Frequency in high-speed mode (ADLPC=0, ADHSC=1)
   - Frequency in low-power mode (ADLPC=1, ADHSC=0)
+  - fsl,min-sample-time: Minimum sampling time in nanoseconds. This value has
+to be chosen according to the conversion mode and the connected analog
+source resistance (R_as) and capacitance (C_as). Refer the datasheet's
+operating requirements. A safe default across a wide range of R_as and
+C_as as well as conversion modes is 1000ns.
 
 Example:
 adc0: adc@4003b000 {
@@ -27,5 +32,6 @@ adc0: adc@4003b000 {
clock-names = "adc";
fsl,adck-max-frequency = <3000>, <4000>,
<2000>;
+   fsl,min-sample-time = <1000>;
vref-supply = <®_vcc_3v3_mcu>;
 };
diff --git a/drivers/iio/adc/vf610_adc.c b/drivers/iio/adc/vf610_adc.c
index 480f335..bcae8fd 100644
--- a/drivers/iio/adc/vf610_adc.c
+++ b/drivers/iio/adc/vf610_adc.c
@@ -68,6 +68,9 @@
 #define VF610_ADC_CLK_DIV8 0x60
 #define VF610_ADC_CLK_MASK 0x60
 #define VF610_ADC_ADLSMP_LONG  0x10
+#define VF610_ADC_ADSTS_SHORT   0x100
+#define VF610_ADC_ADSTS_NORMAL  0x200
+#define VF610_ADC_ADSTS_LONG0x300
 #define VF610_ADC_ADSTS_MASK   0x300
 #define VF610_ADC_ADLPC_EN 0x80
 #define VF610_ADC_ADHSC_EN 0x400
@@ -124,6 +127,17 @@ enum conversion_mode_sel {
VF610_ADC_CONV_LOW_POWER,
 };
 
+enum lst_adder_sel {
+   VF610_ADCK_CYCLES_3,
+   VF610_ADCK_CYCLES_5,
+   VF610_ADCK_CYCLES_7,
+   VF610_ADCK_CYCLES_9,
+   VF610_ADCK_CYCLES_13,
+   VF610_ADCK_CYCLES_17,
+   VF610_ADCK_CYCLES_21,
+   VF610_ADCK_CYCLES_25,
+};
+
 struct vf610_adc_feature {
enum clk_selclk_sel;
enum vol_refvol_ref;
@@ -132,6 +146,8 @@ struct vf610_adc_feature {
int clk_div;
int sample_rate;
int res_mode;
+   u32 lst_adder_index;
+   u32 default_sample_time;
 
boolcalibration;
boolovwren;
@@ -155,11 +171,13 @@ struct vf610_adc {
 };
 
 static const u32 vf610_hw_avgs[] = { 1, 4, 8, 16, 32 };
+static const u32 vf610_lst_adder[] = { 3, 5, 7, 9, 13, 17, 21, 25 };
 
 static inline void vf610_adc_calculate_rates(struct vf610_adc *info)
 {
struct vf610_adc_feature *adc_feature = &info->adc_feature;
unsigned long adck_rate, ipg_rate = clk_get_rate(info->clk);
+   u32 adck_period, lst_addr_min;
int divisor, i;
 
adck_rate = info->max_adck_rate[adc_feature->conv_mode];
@@ -174,6 +192,19 @@ static inline void vf610_adc_calculate_rates(struct 
vf610_adc *info)
}
 
/*
+* Determine the long sample time adder value to be used based
+* on the default minimum sample time provided.
+*/
+   adck_period = NSEC_PER_SEC / adck_rate;
+   lst_addr_min = adc_feature->default_sample_time / adck_period;
+   for (i = 0; i < ARRAY_SIZE(vf610_lst_adder); i++) {
+   if (vf610_lst_adder[i] > lst_addr_min) {
+   adc_feature->lst_adder_index = i;
+   break;
+   }
+   }
+
+   /*
 * Calculate ADC sample frequencies
 * Sample time unit is ADCK cycles. ADCK clk source is ipg clock,
 * which is the same as bus clock.
@@ -182,12 +213,13 @@ static inline void vf610_adc_calculate_rates(struct 
vf610_adc *info)
 * SFCAdder: fixed to 6 ADCK cycles
 * AverageNum: 1, 4, 8, 16, 32 samples for hardware average.
 * BCT (Base Conversion Time): fixed to 25 ADCK cycles for 12 bit mode
-* LSTAdder(Long Sample Time): fixed to 3 ADCK cycles
+* LSTAdder(Long Sample Time): 3, 5, 7, 9, 13, 17, 21, 25 ADCK cycles
 */
adck_rate = ipg_rate / info->a

[PATCH v1 2/2] ARM: dts: vfxxx: Add property for minimum sample time

[Sanchayan Maity]

Add a device tree property which allows to specify the minimum sample
time which can be used to calculate the actual ADC cycles required
depending on the hardware.

Signed-off-by: Sanchayan Maity 
---
 arch/arm/boot/dts/vfxxx.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
index 90a03d5..463cfe3 100644
--- a/arch/arm/boot/dts/vfxxx.dtsi
+++ b/arch/arm/boot/dts/vfxxx.dtsi
@@ -229,6 +229,7 @@
status = "disabled";
fsl,adck-max-frequency = <3000>, <4000>,
<2000>;
+   fsl,min-sample-time = <1000>;
};
 
wdoga5: wdog@4003e000 {
@@ -447,6 +448,7 @@
status = "disabled";
fsl,adck-max-frequency = <3000>, <4000>,
<2000>;
+   fsl,min-sample-time = <1000>;
};
 
esdhc1: esdhc@400b2000 {
-- 
2.4.2

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

[PATCH] checkpatch: Warn on BUG and BUG_ON uses

[Joe Perches]

Spake Linus:

> Hell no.
> 
> Stop with the random BUG_ON() additions.
> 
> I have said this before, and apparently I need to sat this again, and
> probably I will have to say it in the future.
> 
> We don't add BUG_ON's for random reasons.
> 
> The *ONLY* acceptable reason for a BUG_ON() is if the machine is dead
> anyway because of some major internal corruption.
> 
> We have too many BUG_ON's. We've had people add BUG_ON's because "this
> cannot happen", and then it turns out they were wrong, and they just
> killed the machine.
> 
> Dammit, there's no reason to add a BUG_ON() here in the first place,
> and the reason of "but but it's an unused error return": is f*cking
> retarded.
> 
> Stop this idiocy. We don't write crap code just to satisfy some random
> coding standard or shut up a compiler error.
> 
> At most, it could be a "WARN_ON_ONCE()". Maybe even just silently
> ignore the error. But BUG_ON()? Hell no.
>
> NO NO NO.
> 
> Quite frankly, if you want to add error handling, then dammit, add it
> right. And no, BUG_ON() is _never_ proper error handling.
> 
> BUG_ON() is for things like "uhhuh, somebody is trying to free a page
> that is already free". That is some serious internal corruption.
> 
> BUG_ON() is _not_ for "I'm not doing any error handling, so I'll
> sprinkle random lines of BUG_ON() like fairy dust to make the compiler
> happen".
> 
> Really.  I'm getting very tired indeed of people adding BUG_ON's like
> that. Stop it.

Signed-off-by: Joe Perches 
---
 scripts/checkpatch.pl | 11 +--
 1 file changed, 5 insertions(+), 6 deletions(-)

diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index 69c4716..f3daa4e 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -3423,12 +3423,11 @@ sub process {
}
}
 
-# # no BUG() or BUG_ON()
-#  if ($line =~ /\b(BUG|BUG_ON)\b/) {
-#  print "Try to use WARN_ON & Recovery code rather than 
BUG() or BUG_ON()\n";
-#  print "$herecurr";
-#  $clean = 0;
-#  }
+# avoid BUG() or BUG_ON()
+   if ($line =~ /\b(BUG|BUG_ON)\b/) {
+   WARN("BUG",
+"Avoid using $1 unless there is a serious 
corruption - try to use WARN_ON & recovery code instead\n" .  $herecurr);
+   }
 
if ($line =~ /\bLINUX_VERSION_CODE\b/) {
WARN("LINUX_VERSION_CODE",


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

Re: [PATCH] x86/asm/entry/32: Rename labels in INT 0x80 code path

[Ingo Molnar]

* Linus Torvalds  wrote:

> On Jun 7, 2015 11:42 AM, "Denys Vlasenko"  wrote:
> >
> > Rename it to ia32_int80_target.
> 
> Btw, could we arrive to get rid of the idiotic "ia32" naming too? It's wrong, 
> and it harkens back to the days when intel thought itanium makes sense and 
> wanted to talk about "intel architecture".

Absolutely, I've been slowly eliminating uses of it - that naming is very 
annoying.

Another thing I'm doing is to slowly remove references to 'emulation' - we 
don't 
emulate 32-bit in any way, we implement various 32-bit syscall ABIs (old a new) 
natively.

I'd like to remove CONFIG_IA32_EMULATION from the .config as well - it offers 
nothing real over CONFIG_COMPAT.

> The platform is called x86, not ia32. And in this particular case, u suspect 
> the 
> important part isn't the x86 part, but the "compat" part - we damn well know 
> we're x86, the important part is that this is the 32-bit compat entry point 
> of a 
> 64-bit kernel. No?

Totally. All strings of 'ia32' and 'IA32' will be gone in the long run except 
from 
Intel specific MSR names or so.

> So "ia32" is just crazy, and the architecture is not in question anyway, why 
> not 
> name these things for the things that really matter?

Yeah. I wanted to rename all the entry points to be logical, and beyond 
removing 
the nonsensical 'ia32' names I also wanted to make it clear what kind of 
instruction's entry point they are.

For example whoever thought that 'ia32_cstar_target' is a proper name for the 
primary 32-bit syscall entry point needs their head examined.

My (re-)naming plan is:

ia32_sysenter_target-> entry_SYSENTER_32
system_call (32)-> entry_INT80_32
system_call (64)-> entry_SYSCALL_64
ia32_cstar_target   -> entry_SYSCALL_compat
ia32_syscall-> entry_INT80_compat
ia32_sysenter_target-> entry_SYSENTER_compat

The ideas behind this naming scheme is to:

  - Make it really obvious, through a capitalized asm mnemonic, which 
particular 
x86 CPU instruction a particular entry point corresponds to. People 
changing 
that code should be absolutely aware of the various special properties these
instructions have.

  - Harmonize the naming across the native 32-bit, 64-bit and compat space.

  - Unconfuse the 32-bit and 64-bit logic where the 'system_call' entry point 
is 
actually for two (starkly) different instructions.

  - Remove the various ia32 prefixes that are sometimes denoting compat, 
sometimes
native 32-bit.

Another possibility would be:

ia32_sysenter_target-> entry_32_SYSENTER
system_call (32)-> entry_32_INT80
system_call (64)-> entry_64_SYSCALL
ia32_cstar_target   -> entry_64_SYSCALL_compat
ia32_syscall-> entry_64_INT80_compat
ia32_sysenter_target-> entry_64_SYSENTER_compat

These names are typically only used in two places, so name length is not as 
critical as for other function names.

And naming matters: a good name is both descriptive and short, as we know it 
from 
the excellent examples of 'Linux' and 'Git'. Oh wait ...

Thanks,

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

[PATCH 2/2] f2fs: skip committing valid superblock

[Chao Yu]

In recovery procedure for superblock, we try to write data of valid
superblock into invalid one for recovery, work should be finished here,
but then still we will write the valid one with its original data.
This operation is not needed. Let's skip doing this unnecessary work.

Signed-off-by: Chao Yu 
---
 fs/f2fs/f2fs.h  | 2 +-
 fs/f2fs/file.c  | 2 +-
 fs/f2fs/super.c | 8 +---
 3 files changed, 7 insertions(+), 5 deletions(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 1a0716c..a8327ed 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1624,7 +1624,7 @@ static inline int f2fs_add_link(struct dentry *dentry, 
struct inode *inode)
 /*
  * super.c
  */
-int f2fs_commit_super(struct f2fs_sb_info *);
+int f2fs_commit_super(struct f2fs_sb_info *, bool);
 int f2fs_sync_fs(struct super_block *, int);
 extern __printf(3, 4)
 void f2fs_msg(struct super_block *, const char *, const char *, ...);
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index 85f97af..4c8885d 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -1530,7 +1530,7 @@ static int f2fs_ioc_get_encryption_pwsalt(struct file 
*filp, unsigned long arg)
/* update superblock with uuid */
generate_random_uuid(sbi->raw_super->encrypt_pw_salt);
 
-   err = f2fs_commit_super(sbi);
+   err = f2fs_commit_super(sbi, false);
 
mnt_drop_write_file(filp);
if (err) {
diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index f0be6a6..fbbf785 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -1035,7 +1035,7 @@ out:
return 0;
 }
 
-int f2fs_commit_super(struct f2fs_sb_info *sbi)
+int f2fs_commit_super(struct f2fs_sb_info *sbi, bool recover)
 {
struct buffer_head *sbh = sbi->raw_super_buf;
sector_t block = sbh->b_blocknr;
@@ -1047,7 +1047,9 @@ int f2fs_commit_super(struct f2fs_sb_info *sbi)
err = sync_dirty_buffer(sbh);
 
sbh->b_blocknr = block;
-   if (err)
+
+   /* if we are in recovery path, skip writing valid superblock */
+   if (recover || err)
goto out;
 
/* write current valid superblock */
@@ -1291,7 +1293,7 @@ try_onemore:
/* recover broken superblock */
if (recovery && !f2fs_readonly(sb) && !bdev_read_only(sb->s_bdev)) {
f2fs_msg(sb, KERN_INFO, "Recover invalid superblock");
-   f2fs_commit_super(sbi);
+   f2fs_commit_super(sbi, true);
}
 
return 0;
-- 
2.4.2


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

[PATCH 1/6] ACPI / EC: Cleanup transaction state transition.

[Lv Zheng]

This patch collects transaction state transition code into one function. We
then could have a single function to maintain transaction related
behaviors. No functional changes.

Signed-off-by: Lv Zheng 
Tested-by: Gabriele Mazzotta 
Tested-by: Tigran Gabrielyan 
Tested-by: Adrien D 
---
 drivers/acpi/ec.c |   23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 149b5e7..0ce8b6e8 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -391,7 +391,7 @@ static void acpi_ec_submit_query(struct acpi_ec *ec)
 
 static void acpi_ec_complete_query(struct acpi_ec *ec)
 {
-   if (ec->curr->command == ACPI_EC_COMMAND_QUERY) {
+   if (test_bit(EC_FLAGS_QUERY_PENDING, &ec->flags)) {
clear_bit(EC_FLAGS_QUERY_PENDING, &ec->flags);
ec_dbg_req("Event stopped");
}
@@ -421,6 +421,15 @@ static int ec_transaction_completed(struct acpi_ec *ec)
return ret;
 }
 
+static inline void ec_transaction_transition(struct acpi_ec *ec, unsigned long 
flag)
+{
+   ec->curr->flags |= flag;
+   if (ec->curr->command == ACPI_EC_COMMAND_QUERY) {
+   if (flag == ACPI_EC_COMMAND_POLL)
+   acpi_ec_complete_query(ec);
+   }
+}
+
 static void advance_transaction(struct acpi_ec *ec)
 {
struct transaction *t;
@@ -449,7 +458,7 @@ static void advance_transaction(struct acpi_ec *ec)
if ((status & ACPI_EC_FLAG_OBF) == 1) {
t->rdata[t->ri++] = acpi_ec_read_data(ec);
if (t->rlen == t->ri) {
-   t->flags |= ACPI_EC_COMMAND_COMPLETE;
+   ec_transaction_transition(ec, 
ACPI_EC_COMMAND_COMPLETE);
if (t->command == ACPI_EC_COMMAND_QUERY)
ec_dbg_req("Command(%s) 
hardware completion",
   
acpi_ec_cmd_string(t->command));
@@ -459,7 +468,7 @@ static void advance_transaction(struct acpi_ec *ec)
goto err;
} else if (t->wlen == t->wi &&
   (status & ACPI_EC_FLAG_IBF) == 0) {
-   t->flags |= ACPI_EC_COMMAND_COMPLETE;
+   ec_transaction_transition(ec, ACPI_EC_COMMAND_COMPLETE);
wakeup = true;
}
goto out;
@@ -467,17 +476,15 @@ static void advance_transaction(struct acpi_ec *ec)
if (EC_FLAGS_QUERY_HANDSHAKE &&
!(status & ACPI_EC_FLAG_SCI) &&
(t->command == ACPI_EC_COMMAND_QUERY)) {
-   t->flags |= ACPI_EC_COMMAND_POLL;
-   acpi_ec_complete_query(ec);
+   ec_transaction_transition(ec, ACPI_EC_COMMAND_POLL);
t->rdata[t->ri++] = 0x00;
-   t->flags |= ACPI_EC_COMMAND_COMPLETE;
+   ec_transaction_transition(ec, ACPI_EC_COMMAND_COMPLETE);
ec_dbg_req("Command(%s) software completion",
   acpi_ec_cmd_string(t->command));
wakeup = true;
} else if ((status & ACPI_EC_FLAG_IBF) == 0) {
acpi_ec_write_cmd(ec, t->command);
-   t->flags |= ACPI_EC_COMMAND_POLL;
-   acpi_ec_complete_query(ec);
+   ec_transaction_transition(ec, ACPI_EC_COMMAND_POLL);
} else
goto err;
goto out;
-- 
1.7.10

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

[PATCH 4/6] ACPI / EC: Add event clearing variation support.

[Lv Zheng]

We've been suffering from the uncertainty of the SCI_EVT clearing timing.
This patch implements 4 possible modes to handle SCI_EVT clearing
variations. The old behavior is kept in this patch.

Status: QR_EC is re-checked as early as possible after checking previous
SCI_EVT. This always leads to 2 QR_EC transactions per SCI_EVT
indication and the target may implement event queue which returns
0x00 indicating "no outstanding event".
Query: QR_EC is re-checked after the target has handled the QR_EC query
   request command pushed by the host.
Event: QR_EC is re-checked after the target has noticed the query event
   response data pulled by the host.
Method: QR_EC is re-checked as late as possible after completing the _Qxx
evaluation. The target may implement SCI_EVT like a level triggered
interrupt.

Note that, according to the reports, there are platforms that cannot be
handled using the "Status" mode without enabling the
EC_FLAGS_QUERY_HANDSHAKE quirk. But they can be handled with the other 3
modes according to the tests. See Lenovo Z50 test result.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=94411
Link: https://bugzilla.kernel.org/show_bug.cgi?id=97381
Link: https://bugzilla.kernel.org/show_bug.cgi?id=98111
Reported-and-tested-by: Gabriele Mazzotta 
Reported-and-tested-by: Tigran Gabrielyan 
Reported-and-tested-by: Adrien D 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/ec.c |  157 +++--
 1 file changed, 152 insertions(+), 5 deletions(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 7a30f59..8477626 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -59,6 +59,49 @@
 #define ACPI_EC_FLAG_BURST 0x10/* burst mode */
 #define ACPI_EC_FLAG_SCI   0x20/* EC-SCI occurred */
 
+/*
+ * The SCI_EVT clearing timing is not defined by the ACPI specification.
+ * This leads to lots of practical timing issues for the host EC driver.
+ * The following variations are defined (from the target EC firmware's
+ * perspective):
+ * STATUS: After indicating SCI_EVT edge triggered IRQ to the host, the
+ * target can clear SCI_EVT at any time so long as the host can see
+ * the indication by reading the status register (EC_SC). So the
+ * host should re-check SCI_EVT after the first time the SCI_EVT
+ * indication is seen, which is the same time the query request
+ * (QR_EC) is written to the command register (EC_CMD). SCI_EVT set
+ * at any later time could indicate another event. Normally such
+ * kind of EC firmware has implemented an event queue and will
+ * return 0x00 to indicate "no outstanding event".
+ * QUERY: After seeing the query request (QR_EC) written to the command
+ *register (EC_CMD) by the host and having prepared the responding
+ *event value in the data register (EC_DATA), the target can safely
+ *clear SCI_EVT because the target can confirm that the current
+ *event is being handled by the host. The host then should check
+ *SCI_EVT right after reading the event response from the data
+ *register (EC_DATA).
+ * EVENT: After seeing the event response read from the data register
+ *(EC_DATA) by the host, the target can clear SCI_EVT. As the
+ *target requires time to notice the change in the data register
+ *(EC_DATA), the host may be required to wait additional guarding
+ *time before checking the SCI_EVT again. Such guarding may not be
+ *necessary if the host is notified via another IRQ.
+ * METHOD: After the event has been handled via the host _Qxx evaluation,
+ * the target can clear SCI_EVT. Normally such kind of EC firmware
+ * flags SCI_EVT in a level triggered way, so the host can wait
+ * another IRQ instead of checking SCI_EVT again right after _Qxx
+ * evaluation completes. This case can thus be covered by any of
+ * the above modes except the overheads caused by the unwanted
+ * queries. But if the firmware doesn't keep on raising IRQs to the
+ * host, the host have to wait an additional guarding time and
+ * check the SCI_EVT again. Such guarding may not be necessary
+ * if the host is notified via another IRQ.
+ */
+#define ACPI_EC_EVT_TIMING_STATUS  0x00
+#define ACPI_EC_EVT_TIMING_QUERY   0x01
+#define ACPI_EC_EVT_TIMING_EVENT   0x02
+#define ACPI_EC_EVT_TIMING_METHOD  0x03
+
 /* EC commands */
 enum ec_command {
ACPI_EC_COMMAND_READ = 0x80,
@@ -76,6 +119,7 @@ enum ec_command {
 
 enum {
EC_FLAGS_QUERY_PENDING, /* Query is pending */
+   EC_FLAGS_QUERY_GUARDING,/* Guard for SCI_EVT check */
EC_FLAGS_HANDLERS_INSTALLED,/* Handlers for GPE and
 * OpReg are installed */
EC_FLAGS_STARTED,   /* Driver is started */
@@ -100,6 +

[PATCH 3/6] ACPI / EC: Convert event handling work queue into loop style.

[Lv Zheng]

During the period that a work queue is scheduled (queued up for run) but
hasn't been run, second schedule_work() could fail. This may not lead to
the loss of queries because QR_EC is always ensured to be submitted after
the work queue has been in the running state.

Thus except the logging message changes, this patch is just a no-op. But
the event handling work queue can be changed into the loop style to allow
us to control the code in a more flexible way (for example, adding
event=0x00 termination condition in the loop).

Signed-off-by: Lv Zheng 
Tested-by: Gabriele Mazzotta 
Tested-by: Tigran Gabrielyan 
Tested-by: Adrien D 
---
 drivers/acpi/ec.c   |   33 -
 drivers/acpi/internal.h |1 +
 2 files changed, 25 insertions(+), 9 deletions(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index b956dbc..7a30f59 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -384,7 +384,9 @@ static bool acpi_ec_submit_flushable_request(struct acpi_ec 
*ec)
 static void acpi_ec_submit_query(struct acpi_ec *ec)
 {
if (!test_and_set_bit(EC_FLAGS_QUERY_PENDING, &ec->flags)) {
-   ec_dbg_req("Event started");
+   ec_dbg_evt("Command(%s) submitted/blocked",
+  acpi_ec_cmd_string(ACPI_EC_COMMAND_QUERY));
+   ec->nr_pending_queries++;
schedule_work(&ec->work);
}
 }
@@ -393,7 +395,8 @@ static void acpi_ec_complete_query(struct acpi_ec *ec)
 {
if (test_bit(EC_FLAGS_QUERY_PENDING, &ec->flags)) {
clear_bit(EC_FLAGS_QUERY_PENDING, &ec->flags);
-   ec_dbg_req("Event stopped");
+   ec_dbg_evt("Command(%s) unblocked",
+  acpi_ec_cmd_string(ACPI_EC_COMMAND_QUERY));
}
 }
 
@@ -460,8 +463,8 @@ static void advance_transaction(struct acpi_ec *ec)
if (t->rlen == t->ri) {
ec_transaction_transition(ec, 
ACPI_EC_COMMAND_COMPLETE);
if (t->command == ACPI_EC_COMMAND_QUERY)
-   ec_dbg_req("Command(%s) 
hardware completion",
-  
acpi_ec_cmd_string(t->command));
+   ec_dbg_evt("Command(%s) 
completed by hardware",
+  
acpi_ec_cmd_string(ACPI_EC_COMMAND_QUERY));
wakeup = true;
}
} else
@@ -479,8 +482,8 @@ static void advance_transaction(struct acpi_ec *ec)
ec_transaction_transition(ec, ACPI_EC_COMMAND_POLL);
t->rdata[t->ri++] = 0x00;
ec_transaction_transition(ec, ACPI_EC_COMMAND_COMPLETE);
-   ec_dbg_req("Command(%s) software completion",
-  acpi_ec_cmd_string(t->command));
+   ec_dbg_evt("Command(%s) completed by software",
+  acpi_ec_cmd_string(ACPI_EC_COMMAND_QUERY));
wakeup = true;
} else if ((status & ACPI_EC_FLAG_IBF) == 0) {
acpi_ec_write_cmd(ec, t->command);
@@ -950,11 +953,23 @@ static int acpi_ec_query(struct acpi_ec *ec, u8 *data)
return result;
 }
 
-static void acpi_ec_gpe_poller(struct work_struct *work)
+static void acpi_ec_event_handler(struct work_struct *work)
 {
+   unsigned long flags;
struct acpi_ec *ec = container_of(work, struct acpi_ec, work);
 
-   acpi_ec_query(ec, NULL);
+   ec_dbg_evt("Event started");
+
+   spin_lock_irqsave(&ec->lock, flags);
+   while (ec->nr_pending_queries) {
+   spin_unlock_irqrestore(&ec->lock, flags);
+   (void)acpi_ec_query(ec, NULL);
+   spin_lock_irqsave(&ec->lock, flags);
+   ec->nr_pending_queries--;
+   }
+   spin_unlock_irqrestore(&ec->lock, flags);
+
+   ec_dbg_evt("Event stopped");
 }
 
 static u32 acpi_ec_gpe_handler(acpi_handle gpe_device,
@@ -1029,7 +1044,7 @@ static struct acpi_ec *make_acpi_ec(void)
init_waitqueue_head(&ec->wait);
INIT_LIST_HEAD(&ec->list);
spin_lock_init(&ec->lock);
-   INIT_WORK(&ec->work, acpi_ec_gpe_poller);
+   INIT_WORK(&ec->work, acpi_ec_event_handler);
ec->timestamp = jiffies;
return ec;
 }
diff --git a/drivers/acpi/internal.h b/drivers/acpi/internal.h
index cf358d4..ae919b5 100644
--- a/drivers/acpi/internal.h
+++ b/drivers/acpi/internal.h
@@ -139,6 +139,7 @@ struct acpi_ec {
spinlock_t lock;
struct work_struct work;
unsigned long timestamp;
+   unsigned long nr_pending_queries;
 };
 
 extern struct acpi_ec *first_ec;
-- 
1.7.10

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

[PATCH 6/6] ACPI / EC: Fix a code coverity issue when QR_EC transactions are failed.

[Lv Zheng]

When the QR_EC transaction fails, the EC_FLAGS_QUERY_PENDING flag prevents
the event handling work queue from being scheduled again.

Though there shouldn't be failed QR_EC transactions, and this gap was
efficiently used for catching and learning the SCI_EVT clearing timing
compliance issues, we need to fix this as we are not fully compatible
with all platforms/Windows to handle SCI_EVT clearing timing correctly.
Fixing this gives the EC driver the chances to recover from a state machine
failure.

So this patch fixes this issue. When nr_pending_queries drops to 0, it
clears EC_FLAGS_QUERY_PENDING at the proper position for different modes in
order to ensure SCI_EVT handling can proceed. For "event" mode, this is
already covered in advance_transaction().

Cc: 3.16+  # 3.16+
Signed-off-by: Lv Zheng 
---
 drivers/acpi/ec.c |   14 +-
 1 file changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 2f13880..cb1c1aa 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -523,7 +523,8 @@ static void advance_transaction(struct acpi_ec *ec)
 */
if (!t || !(t->flags & ACPI_EC_COMMAND_POLL)) {
if (ec_event_clearing == ACPI_EC_EVT_TIMING_EVENT &&
-   test_bit(EC_FLAGS_QUERY_GUARDING, &ec->flags)) {
+   (!ec->nr_pending_queries ||
+test_bit(EC_FLAGS_QUERY_GUARDING, &ec->flags))) {
clear_bit(EC_FLAGS_QUERY_GUARDING, &ec->flags);
acpi_ec_complete_query(ec);
}
@@ -1069,6 +1070,17 @@ static void acpi_ec_event_handler(struct work_struct 
*work)
(void)acpi_ec_query(ec, NULL);
spin_lock_irqsave(&ec->lock, flags);
ec->nr_pending_queries--;
+   /*
+* Before exit, make sure that this work item can be
+* scheduled again. There might be QR_EC/_Qxx failures,
+* leaving EC_FLAGS_QUERY_PENDING uncleared and preventing
+* this work item from being scheduled again.
+*/
+   if (!ec->nr_pending_queries) {
+   if (ec_event_clearing == ACPI_EC_EVT_TIMING_STATUS ||
+   ec_event_clearing == ACPI_EC_EVT_TIMING_QUERY)
+   acpi_ec_complete_query(ec);
+   }
}
spin_unlock_irqrestore(&ec->lock, flags);
 
-- 
1.7.10

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

[PATCH 2/6] ACPI / EC: Cleanup _Qxx evaluation work item.

[Lv Zheng]

The _Qxx evaluation work item can be eliminated and _Qxx can be evaluated
right in the same work item as the QR_EC transaction. This patch cleans up
the code to achieve this.

Originally, QR_EC transaction and _Qxx evaluation were all done in the same
work queue flushed by acpi_os_wait_events_complete(). Though the QR_EC
transaction (previous commit) and _Qxx evaluation (this commmit) are now
moved to the work queue that is not covered by
acpi_os_wait_events_complete(), there is no issue can be seen in the
suspend/resume tests.

Signed-off-by: Lv Zheng 
---
 drivers/acpi/ec.c |   35 ---
 1 file changed, 12 insertions(+), 23 deletions(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 0ce8b6e8..b956dbc 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -904,27 +904,12 @@ void acpi_ec_remove_query_handler(struct acpi_ec *ec, u8 
query_bit)
 }
 EXPORT_SYMBOL_GPL(acpi_ec_remove_query_handler);
 
-static void acpi_ec_run(void *cxt)
-{
-   struct acpi_ec_query_handler *handler = cxt;
-
-   if (!handler)
-   return;
-   ec_dbg_evt("Query(0x%02x) started", handler->query_bit);
-   if (handler->func)
-   handler->func(handler->data);
-   else if (handler->handle)
-   acpi_evaluate_object(handler->handle, NULL, NULL, NULL);
-   ec_dbg_evt("Query(0x%02x) stopped", handler->query_bit);
-   acpi_ec_put_query_handler(handler);
-}
-
 static int acpi_ec_query(struct acpi_ec *ec, u8 *data)
 {
u8 value = 0;
int result;
-   acpi_status status;
struct acpi_ec_query_handler *handler;
+   bool handler_found = false;
struct transaction t = {.command = ACPI_EC_COMMAND_QUERY,
.wdata = NULL, .rdata = &value,
.wlen = 0, .rlen = 1};
@@ -947,17 +932,21 @@ static int acpi_ec_query(struct acpi_ec *ec, u8 *data)
if (value == handler->query_bit) {
/* have custom handler for this bit */
handler = acpi_ec_get_query_handler(handler);
-   ec_dbg_evt("Query(0x%02x) scheduled",
-  handler->query_bit);
-   status = acpi_os_execute((handler->func) ?
-   OSL_NOTIFY_HANDLER : OSL_GPE_HANDLER,
-   acpi_ec_run, handler);
-   if (ACPI_FAILURE(status))
-   result = -EBUSY;
+   handler_found = true;
break;
}
}
mutex_unlock(&ec->mutex);
+
+   if (handler_found) {
+   ec_dbg_evt("Query(0x%02x) started", handler->query_bit);
+   if (handler->func)
+   handler->func(handler->data);
+   else if (handler->handle)
+   acpi_evaluate_object(handler->handle, NULL, NULL, NULL);
+   ec_dbg_evt("Query(0x%02x) stopped", handler->query_bit);
+   acpi_ec_put_query_handler(handler);
+   }
return result;
 }
 
-- 
1.7.10

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

[PATCH 5/6] ACPI / EC: Fix EC_FLAGS_QUERY_HANDSHAKE platforms using new event clearing timing.

[Lv Zheng]

It is reported that on several platforms, EC firmware will not respond
non-expected QR_EC (see EC_FLAGS_QUERY_HANDSHAKE, only write QR_EC when
SCI_EVT is set).

Unfortunately, ACPI specification doesn't define when the SCI_EVT should be
cleared by the firmware, thus the original implementation queued up second
QR_EC right after writing QR_EC command and before reading the returned
event value as at that time the SCI_EVT is ensured not cleared. This
behavior is also based on the assumption that the firmware should be able
to return 0x00 to indicate "no outstanding event". This behavior did fix
issues on Samsung platforms where the spurious query value of 0x00 is
supported and didn't break platforms in my test queue.

But recently, specific Acer, Asus, Lenovo platforms keep on blaming this
change.

This patch changes the behavior to re-check the SCI_EVT a bit later and
removes EC_FLAGS_QUERY_HANDSHAKE quirks, hoping this is the Windows
compliant EC driver behavior.

This patch keeps old behavior for Samsung platforms.

In order to be robust to the possible regressions, instead of removing the
quirk directly, this patch keeps the quirk code and removes the quirk
users.

Cc: 3.16+  # 3.16+
Link: https://bugzilla.kernel.org/show_bug.cgi?id=94411
Link: https://bugzilla.kernel.org/show_bug.cgi?id=97381
Link: https://bugzilla.kernel.org/show_bug.cgi?id=98111
Reported-and-tested-by: Gabriele Mazzotta 
Reported-and-tested-by: Tigran Gabrielyan 
Reported-and-tested-by: Adrien D 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/ec.c |   16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/drivers/acpi/ec.c b/drivers/acpi/ec.c
index 8477626..2f13880 100644
--- a/drivers/acpi/ec.c
+++ b/drivers/acpi/ec.c
@@ -144,7 +144,7 @@ static unsigned int ec_polling_guard __read_mostly = 
ACPI_EC_UDELAY_POLL;
 module_param(ec_polling_guard, uint, 0644);
 MODULE_PARM_DESC(ec_polling_guard, "Guard time(us) between EC accesses in 
polling modes");
 
-static unsigned int ec_event_clearing __read_mostly = 
ACPI_EC_EVT_TIMING_STATUS;
+static unsigned int ec_event_clearing __read_mostly = ACPI_EC_EVT_TIMING_QUERY;
 
 /*
  * If the number of false interrupts per one transaction exceeds
@@ -1385,10 +1385,13 @@ static int ec_validate_ecdt(const struct dmi_system_id 
*id)
return 0;
 }
 
+#if 0
 /*
- * Acer EC firmware refuses to respond QR_EC when SCI_EVT is not set, for
- * which case, we complete the QR_EC without issuing it to the firmware.
- * https://bugzilla.kernel.org/show_bug.cgi?id=86211
+ * Some EC firmware variations refuses to respond QR_EC when SCI_EVT is not
+ * set, for which case, we complete the QR_EC without issuing it to the
+ * firmware.
+ * https://bugzilla.kernel.org/show_bug.cgi?id=82611
+ * https://bugzilla.kernel.org/show_bug.cgi?id=97381
  */
 static int ec_flag_query_handshake(const struct dmi_system_id *id)
 {
@@ -1396,6 +1399,7 @@ static int ec_flag_query_handshake(const struct 
dmi_system_id *id)
EC_FLAGS_QUERY_HANDSHAKE = 1;
return 0;
 }
+#endif
 
 /*
  * On some hardware it is necessary to clear events accumulated by the EC 
during
@@ -1418,6 +1422,7 @@ static int ec_clear_on_resume(const struct dmi_system_id 
*id)
 {
pr_debug("Detected system needing EC poll on resume.\n");
EC_FLAGS_CLEAR_ON_RESUME = 1;
+   ec_event_clearing = ACPI_EC_EVT_TIMING_STATUS;
return 0;
 }
 
@@ -1447,9 +1452,6 @@ static struct dmi_system_id ec_dmi_table[] __initdata = {
{
ec_clear_on_resume, "Samsung hardware", {
DMI_MATCH(DMI_SYS_VENDOR, "SAMSUNG ELECTRONICS CO., LTD.")}, NULL},
-   {
-   ec_flag_query_handshake, "Acer hardware", {
-   DMI_MATCH(DMI_SYS_VENDOR, "Acer"), }, NULL},
{},
 };
 
-- 
1.7.10

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

[PATCH 0/6] ACPI / EC: Fix issues related to the event handling.

[Lv Zheng]

ACPI specification doesn't define the SCI_EVT clearing timing for the EC
firmware. There could be 4 possible positions the firmware may use to clear
the SCI_EVT indication:
 STATUS: After indicating SCI_EVT to the host via the status register
 (EC_SC), the target can clear SCI_EVT at any time.
 QUERY: After seeing the query request (QR_EC) written to the command
register (EC_CMD) by the host and having prepared the responding
event value in the data register (EC_DATA), the target can safely
clear SCI_EVT.
 EVENT: After seeing the event response read from the data register
(EC_DATA) by the host, the target can clear SCI_EVT.
 METHOD: After the event has been handled via the host _Qxx evaluation,
 the target can clear SCI_EVT.

The old EC driver re-checked SCI_EVT using the 3rd position, while during
the race fixes, the new EC driver was switched to re-check SCI_EVT using
the 1st position. Using the earliest position may help to reduce issues
when the other races are not fully fixed and there is an ACPI specification
statement around an expected behavior:
 The query value of zero is reserved for a spurious query result and
 indicates "no outstanding events."
This statement was the motivation of this choice.

But there are platforms do not follow this definition, since there is also
a coverity issue left in the new EC driver, the unmatched SCI_EVT clearing
timing finally was trapped by this coverity issue, and users can see that
the new EC driver stops processing further SCI_EVTs. The new EC driver then
implemented EC_FLAGS_QUERY_HANDSHAKE quirk as a workaround for such
platforms.
Now more and more reports can be seen for this SCI_EVT clearing timing
unmatched problem, we need to consider a better approach to fix all of them
instead of adding new EC_FLAGS_QUERY_HANDSHAKE quirk users.

This patchset thus finally implements 4 modes to handle the SCI_EVT
clearing timing variations. And according to the tests, chooses the next
earlier position (the 2rd position) as the default behavior.
This patchset also fixes the coverity problem so that even though the
default behavior still cannot match the Windows behavior, it is possible
for the new EC driver to proceed to handle further SCI_EVT indications.

Related bug reports are as follows:
Link: https://bugzilla.kernel.org/show_bug.cgi?id=44161
Link: https://bugzilla.kernel.org/show_bug.cgi?id=82611
Link: https://bugzilla.kernel.org/show_bug.cgi?id=94411
Link: https://bugzilla.kernel.org/show_bug.cgi?id=97381
Link: https://bugzilla.kernel.org/show_bug.cgi?id=98111

Lv Zheng (6):
  ACPI / EC: Cleanup transaction state transition.
  ACPI / EC: Cleanup _Qxx evaluation work item.
  ACPI / EC: Convert event handling work queue into loop style.
  ACPI / EC: Add event clearing variation support.
  ACPI / EC: Fix EC_FLAGS_QUERY_HANDSHAKE platforms using new event
clearing timing.
  ACPI / EC: Fix a code coverity issue when QR_EC transactions are
failed.

 drivers/acpi/ec.c   |  272 ++-
 drivers/acpi/internal.h |1 +
 2 files changed, 223 insertions(+), 50 deletions(-)

-- 
1.7.10

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

[PATCH v2] kernel/params.c: make use of unused but set variable

[Louis Langholtz]

While Rusty Russell wants the return value of sysfs_create_file
ignored, it's annotated '__must_check'. Tejun Heo made the annotaion
and suggests just using WARN_ON_ONCE(). Meanwhile the compiler warns that
the 'err' variable is set but unused. This patch uses Tejun's
suggestion. This eliminates the warning, satisfies the required check,
and warns if sysfs_create_file actually ever fails (something that Rusty
says should never happen when this code runs).

Signed-off-by: Louis Langholtz 
---

diff --git a/kernel/params.c b/kernel/params.c
index a22d6a7..49406f9 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -853,6 +853,7 @@ static void __init version_sysfs_builtin(void)
mk = locate_module_kobject(vattr->module_name);
if (mk) {
err = sysfs_create_file(&mk->kobj, &vattr->mattr.attr);
+   WARN_ON_ONCE(err);
kobject_uevent(&mk->kobj, KOBJ_ADD);
kobject_put(&mk->kobj);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] f2fs: setting discard option in parse_options()

[Chao Yu]

For the first mount of f2fs image with realtime discard option, we will
disable discard option if device is not supported, but for remount
operation, our discard option can still be set, this should be avoided.

This patch moves configuring of discard option to parse_options() to fix
this issue.

Signed-off-by: Chao Yu 
---
 fs/f2fs/super.c | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/fs/f2fs/super.c b/fs/f2fs/super.c
index fbbf785..a06b0b4 100644
--- a/fs/f2fs/super.c
+++ b/fs/f2fs/super.c
@@ -258,6 +258,7 @@ static void init_once(void *foo)
 static int parse_options(struct super_block *sb, char *options)
 {
struct f2fs_sb_info *sbi = F2FS_SB(sb);
+   struct request_queue *q;
substring_t args[MAX_OPT_ARGS];
char *p, *name;
int arg = 0;
@@ -302,7 +303,14 @@ static int parse_options(struct super_block *sb, char 
*options)
return -EINVAL;
break;
case Opt_discard:
-   set_opt(sbi, DISCARD);
+   q = bdev_get_queue(sb->s_bdev);
+   if (blk_queue_discard(q)) {
+   set_opt(sbi, DISCARD);
+   } else {
+   f2fs_msg(sb, KERN_WARNING,
+   "mounting with \"discard\" option, but "
+   "the device does not support discard");
+   }
break;
case Opt_noheap:
set_opt(sbi, NOHEAP);
@@ -1237,16 +1245,6 @@ try_onemore:
proc_create_data("segment_info", S_IRUGO, sbi->s_proc,
 &f2fs_seq_segment_info_fops, sb);
 
-   if (test_opt(sbi, DISCARD)) {
-   struct request_queue *q = bdev_get_queue(sb->s_bdev);
-   if (!blk_queue_discard(q)) {
-   f2fs_msg(sb, KERN_WARNING,
-   "mounting with \"discard\" option, but "
-   "the device does not support discard");
-   clear_opt(sbi, DISCARD);
-   }
-   }
-
sbi->s_kobj.kset = f2fs_kset;
init_completion(&sbi->s_kobj_unregister);
err = kobject_init_and_add(&sbi->s_kobj, &f2fs_ktype, NULL,
-- 
2.4.2


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

Re: [RESEND 1/2] usb: ehci-exynos: Make provision for vdd regulators

[Krzysztof Kozlowski]

2015-06-08 13:21 GMT+09:00 Anand Moon :
> Hi Krzysztof ,
>
> On 8 June 2015 at 07:40, Krzysztof Kozlowski  wrote:
>> On 07.06.2015 22:20, Anand Moon wrote:
>>> Facilitate getting required 3.3V and 1.0V VDD supply for
>>> EHCI controller on Exynos.
>>>
>>> With the patches for regulators' nodes merged in 3.15:
>>> c8c253f ARM: dts: Add regulator entries to smdk5420
>>> 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
>>> the exynos systems turn on only minimal number of regulators.
>>>
>>> Until now, the VDD regulator supplies were either turned on
>>> by the bootloader, or the regulators were enabled by default
>>> in the kernel, so that the controller drivers did not need to
>>> care about turning on these regulators on their own.
>>> This was rather bad about these controller drivers.
>>> So ensuring now that the controller driver requests the necessary
>>> VDD regulators (if available, unless there are direct VDD rails),
>>> and enable them so as to make them working.
>>>
>>> Signed-off-by: Vivek Gautam 
>>> Signed-off-by: Anand Moon 
>>> Cc: Jingoo Han 
>>> Cc: Alan Stern 
>>> ---
>>> Initial version of this patch was part of following series, though
>>> they are not dependent on each other, resubmitting after rebasing.
>>>
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266418.html
>>
>> So you just took Vivek's patch along with all the credits... That is not
>> how we usually do this.
>>
>> I would expect that rebasing a patch won't change the author unless this
>> is fine with Vivek.
>>
>
> Sorry If I have done some mistake on my part.
> I just looked at below mail chain. Before I send it.
>
> http://www.spinics.net/lists/linux-samsung-soc/msg44136.html

I don't get it. The patch you are referring to has a proper "From"
field. So please use it as an example.

>
> I don't want to take any credit out of it. I just re-base on the new kernel.
> I could not test this patch as it meant for exynos5440 boards.

Are you sure? I think the driver is used on almost all of Exynos SoCs
(Exynos4, Exynos5250, Exynos542x).

Untested code should not go to the kernel. Additionally you should
mark it as not-tested. Marking such patch as non-tested could help you
finding some independent tests (tests performed by someone else).

To summarize my point of view:
1. Unless Vivek's says otherwise, please give him the credits with
proper "from" field.
2. Issues mentioned in previous mail should be addressed (missing
IS_ERR(), how disabling the regulator during suspend affects waking
up).
3. The patchset must be tested, even after rebasing.

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

Re: [Xen-devel] [Patch V3 14/15] xen: allow more than 512 GB of RAM for 64 bit pv-domains

[Juergen Gross]

On 05/27/2015 07:05 PM, David Vrabel wrote:

On 27/05/15 17:25, David Vrabel wrote:

On 20/04/15 06:23, Juergen Gross wrote:

64 bit pv-domains under Xen are limited to 512 GB of RAM today. The
main reason has been the 3 level p2m tree, which was replaced by the
virtual mapped linear p2m list. Parallel to the p2m list which is
being used by the kernel itself there is a 3 level mfn tree for usage
by the Xen tools and eventually for crash dump analysis. For this tree
the linear p2m list can serve as a replacement, too. As the kernel
can't know whether the tools are capable of dealing with the p2m list
instead of the mfn tree, the limit of 512 GB can't be dropped in all
cases.

This patch replaces the hard limit by a kernel parameter which tells
the kernel to obey the 512 GB limit or not. The default is selected by
a configuration parameter which specifies whether the 512 GB limit
should be active per default for domUs (domain save/restore/migration
and crash dump analysis are affected).

Memory above the domain limit is returned to the hypervisor instead of
being identity mapped, which was wrong anyway.

The kernel configuration parameter to specify the maximum size of a
domain can be deleted, as it is not relevant any more.


Something in this patch breaks the hvc console in my test domU.

kernel BUG at /local/davidvr/work/k.org/tip/drivers/tty/hvc/hvc_xen.c:153

Which suggests the hvc driver mapped the wrong console ring frame.


Sorry, it's patch #13 (xen: move p2m list if conflicting with e820 map)
that seems to be bad.


I think I've found the reason: the console frame isn't being marked as
"reserved" any more. With moving the p2m list I had to change the call
of memblock_reserve() for it. Before that patch this call covered the
p2m list, the start_info page, the xenstore page and the console page.
I added a memblock_reserve() for start_info, but failed to do so for
xenstore and console.

I'll modify the patch and respin.

I have to check why I didn't hit this issue. Maybe my test machine was
too large and the memory in question didn't get reused until my test
was finished.


Thanks for testing,

Juergen

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

Re: [PATCH v3 2/3] ARM: rockchip: ensure CPU to enter WFI/WFE state

[Caesar Wang]

在 2015年06月06日 04:24, Doug Anderson 写道:

Russell,

On Fri, Jun 5, 2015 at 11:29 AM, Russell King - ARM Linux
 wrote:

1) v7_coherency_exit() is specific to v7 CPUs and can't be used by
generic code.

Oh, I see.  So (I think) you're saying that perhaps the reason that
Caesar needed his patch was that he needed the dying processor to
execute v7_exit_coherency_flush(), NOT that he needed the dying
processor to be in WFI/WFE.  That actually makes a lot more sense to
me!  :)  Thanks a lot for pointing that out, it's very helpful.



So, we're actually in a very sticky position over taking CPUs offline.
It seems to be something that the ARM architecture and kernel
architecture doesn't actually allow to be done safely.  So much so,
that in a similar way to the original Keystone 2 physical address
switch, I'm tempted to make taking a CPU offline taint the kernel!

Wow, that's going to suck.  So if you want to suspend / resume you
need to taint your kernel.  So much for saving the planet by going
into suspend...  ...or are you thinking that it won't taint the kernel
when the kernel takes CPUs offline for suspend/resume purposes?  ...or
are you thinking you've some solution that works for suspend/resume
that doesn't work for the general cpu offlining problem?  I'd be very
interested to hear...


I know I'm not a maintainer, but if I were and I knew that lots of
smart people had thought about the problem of CPU offlining and they
didn't have a solution and I could make my platform 99.%
reliable by allowing a very safe mdelay(1) where I had a pretty strong
guarantee that the 1ms was enough time, I would probably accept that
code...


So since I'm not a maintainer and I certainly couldn't ack such code,
I would certainly be happy to add my Reviewed-by to Caesar's patch if
he changed it mention that he needed to make sure that
v7_exit_coherency_flush() in rockchip_cpu_die() executed in time.


OK.
The dying processor to execute v7_exit_coherency_flush(),not that the 
dying processor to be in WFI/WFE.


It's needed to enter WFI/WFE state from the ARM refer document when CPU 
down.


But..

Here is my test: (won't to enter the WFI state)
@@ -331,8 +331,8 @@ static int rockchip_cpu_kill(unsigned int cpu)
 static void rockchip_cpu_die(unsigned int cpu)
 {
v7_exit_coherency_flush(louis);
-   while (1)
-   cpu_do_idle();
+   while (1);
+   //cpu_do_idle();
 }

echo 0 > /sys/module/printk/parameters/console_suspend
echo 1 > /sys/power/pm_print_times
echo mem > sys/power/state

You can play anything
or do some test for CPU up/down:

cd /sys/devices/system/cpu/
for i in $(seq 1); do
  echo "= $i "
  for j in $(seq 100); do
while [[ "$(cat cpu1/online)$(cat cpu2/online)$(cat cpu3/online)" 
!= "000" ]]; do


  echo 0 > cpu1/online
  echo 0 > cpu2/online
  echo 0 > cpu3/online
done
while [[ "$(cat cpu1/online)$(cat cpu2/online)$(cat cpu3/online)" 
!= "111" ]]; do

  echo 1 > cpu1/online
  echo 1 > cpu2/online
  echo 1 > cpu3/online
done
  done
done
Sometimes,the system will be restart when do the about test.
I'm no sure what's happen, That maybe abnormal won't to enter the WFI 
state.




-Doug





--
Thanks,
- Caesar


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

Re: linux-next: build failure after merge of the drivers-x86 tree

[Darren Hart]

On Fri, Jun 05, 2015 at 08:13:01PM +1000, Michael Ellerman wrote:
> Hi Darren,
> 
> After merging the drivers-x86 tree, today's linux-next build (x86_64 
> allmodconfig)
> failed like this:
> 
> ERROR: "acpi_bus_get_status_handle" [drivers/platform/x86/pvpanic.ko] 
> undefined!
> 
> Caused by commit b8f8cf6b02b6 ("pvpanic: handle missing _STA correctly").
> 
> I have applied the fixup patch from Radim for today
> (http://marc.info/?l=linux-next&m=143344030214935&w=2).

It is now fixed on my for-next HEAD.

I rolled this incremental fix into the original to avoid breaking bisect.

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

Re: [PATCH v5 2/2] soc: Add driver for Freescale Vybrid Platform

[maitysanchayan]

Hello Paul,

On 15-06-06 12:26:07, Paul Bolle wrote:
> On Fri, 2015-06-05 at 14:52 +0530, Sanchayan Maity wrote:
> > --- /dev/null
> > +++ b/drivers/soc/fsl/Kconfig
> 
> > +config SOC_BUS_VF610
> > +  tristate "SoC bus device for the Freescale Vybrid platform"
> > +  depends on SOC_VF610
> > +  select SOC_BUS
> > +  help
> > +Include support for the SoC bus on the Freescale Vybrid platform
> > +providing some sysfs information about the module variant.
> 
> > --- /dev/null
> > +++ b/drivers/soc/fsl/Makefile
> 
> > +obj-$(CONFIG_SOC_BUS_VF610)+= soc-vf610.o
> 
> > --- /dev/null
> > +++ b/drivers/soc/fsl/soc-vf610.c
> > @@ -0,0 +1,166 @@
> > +/*
> > + * Copyright 2015 Toradex AG
> > + *
> > + * Author: Sanchayan Maity 
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2, as
> > + * published by the Free Software Foundation.
> > + *
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +
> > +#define DRIVER_NAME "vf610-soc-bus"
> > +
> > +#define MSCM_CPxCOUNT_OFFSET   0x002C
> > +#define MSCM_CPxCFG1_OFFSET0x0014
> > +
> > +struct vf610_soc {
> > +   struct device *dev;
> > +   struct soc_device_attribute *soc_dev_attr;
> > +   struct soc_device *soc_dev;
> > +};
> > +
> > +static int vf610_soc_probe(struct platform_device *pdev)
> > +{
> > +   struct vf610_soc *info;
> > +   struct regmap *ocotp_regmap, *mscm_regmap, *rom_regmap;
> > +   struct device *dev = &pdev->dev;
> > +   struct device_node *node = pdev->dev.of_node;
> > +   struct device_node *soc_node;
> > +   struct of_phandle_args pargs;
> > +   char soc_type[] = "xx0";
> > +   u32 cfg0_offset, cfg1_offset, rom_rev_offset;
> > +   u32 soc_id1, soc_id2, rom_rev;
> > +   u32 cpxcount, cpxcfg1;
> > +   u64 soc_id;
> > +   int ret;
> > +
> > +   info = devm_kzalloc(&pdev->dev, sizeof(struct vf610_soc), GFP_KERNEL);
> > +   if (!info)
> > +   return -ENOMEM;
> > +
> > +   info->dev = &pdev->dev;
> > +   platform_set_drvdata(pdev, info);
> > +
> > +   mscm_regmap = syscon_node_to_regmap(node);
> > +   if (IS_ERR(mscm_regmap)) {
> > +   dev_err(dev, "regmap lookup for mscm failed\n");
> > +   return PTR_ERR(mscm_regmap);
> > +   }
> > +
> > +   soc_node = of_find_node_by_path("/soc");
> > +
> > +   ret = of_parse_phandle_with_fixed_args(soc_node,
> > +   "ocotp-cfg", 2, 0, &pargs);
> > +   if (ret) {
> > +   dev_err(dev, "lookup failed for ocotp-cfg node %d\n", ret);
> > +   return ret;
> > +   }
> > +
> > +   ocotp_regmap = syscon_node_to_regmap(pargs.np);
> > +   if (IS_ERR(ocotp_regmap)) {
> > +   of_node_put(pargs.np);
> > +   dev_err(dev, "regmap lookup for ocotp failed\n");
> > +   return PTR_ERR(ocotp_regmap);
> > +   }
> > +
> > +   cfg0_offset = pargs.args[0];
> > +   cfg1_offset = pargs.args[1];
> > +   of_node_put(pargs.np);
> > +
> > +   ret = of_parse_phandle_with_fixed_args(soc_node,
> > +   "rom-revision", 1, 0, &pargs);
> > +   if (ret) {
> > +   dev_err(dev, "lookup failed for rom-revision node %d\n", ret);
> > +   return ret;
> > +   }
> > +
> > +   rom_regmap = syscon_node_to_regmap(pargs.np);
> > +   if (IS_ERR(rom_regmap)) {
> > +   of_node_put(pargs.np);
> > +   dev_err(dev, "regmap lookup for ocrom failed\n");
> > +   return PTR_ERR(rom_regmap);
> > +   }
> > +
> > +   rom_rev_offset = pargs.args[0];
> > +   of_node_put(pargs.np);
> > +
> > +   ret = regmap_read(ocotp_regmap, cfg0_offset, &soc_id1);
> > +   if (ret)
> > +   return -ENODEV;
> > +
> > +   ret = regmap_read(ocotp_regmap, cfg1_offset, &soc_id2);
> > +   if (ret)
> > +   return -ENODEV;
> > +
> > +   soc_id = (u64) soc_id1 << 32 | soc_id2;
> > +   add_device_randomness(&soc_id, sizeof(soc_id));
> > +
> > +   ret = regmap_read(mscm_regmap, MSCM_CPxCOUNT_OFFSET, &cpxcount);
> > +   if (ret)
> > +   return -ENODEV;
> > +
> > +   ret = regmap_read(mscm_regmap, MSCM_CPxCFG1_OFFSET, &cpxcfg1);
> > +   if (ret)
> > +   return -ENODEV;
> > +
> > +   soc_type[0] = cpxcount ? '6' : '5'; /* Dual Core => VF6x0 */
> > +   soc_type[1] = cpxcfg1 ? '1' : '0'; /* L2 Cache => VFx10 */
> > +
> > +   ret = regmap_read(rom_regmap, rom_rev_offset, &rom_rev);
> > +   if (ret)
> > +   return -ENODEV;
> > +
> > +   info->soc_dev_attr = devm_kzalloc(&pdev->dev,
> > +   sizeof(info->soc_dev_attr), GFP_KERNEL);
> > +   if (!info->soc_dev_attr)
> > +   return -ENOMEM;
> > +
> > +   info->soc_dev_attr->machine = devm_kasprintf(&pdev->dev,
> > +   GFP_KERNEL, "Freescale Vybrid");
> > +   info->soc_dev_attr->soc_id = devm_kasprintf(&pdev->dev,
> > +   GFP_KERNEL, "%016llx", soc_id);
> > +   info->soc

Re: [PATCH v5 1/2] ARM: dts: vfxxx: Add OCOTP and OCROM nodes

[maitysanchayan]

Hello Maxime,

On 15-06-06 13:58:33, Maxime Ripard wrote:
> Hi,
> 
> On Fri, Jun 05, 2015 at 02:52:37PM +0530, Sanchayan Maity wrote:
> > Add a device tree node for the On-Chip One Time Programmable
> > Controller (OCOTP) and the On-Chip ROM.
> > 
> > Signed-off-by: Sanchayan Maity 
> > ---
> >  arch/arm/boot/dts/vfxxx.dtsi | 12 
> >  1 file changed, 12 insertions(+)
> > 
> > diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
> > index 2f4b04d..ed9b6b8 100644
> > --- a/arch/arm/boot/dts/vfxxx.dtsi
> > +++ b/arch/arm/boot/dts/vfxxx.dtsi
> > @@ -56,6 +56,13 @@
> > compatible = "simple-bus";
> > interrupt-parent = <&mscm_ir>;
> > ranges;
> > +   ocotp-cfg = <&ocotp 0x410 0x420>;
> > +   rom-revision = <&ocrom 0x80>;
> > +
> > +   ocrom: ocrom {
> > +   compatible = "fsl,vf610-ocrom", "syscon";
> > +   reg = <0x 0x18000>;
> > +   };
> 
> Shouldn't that use the new nvmem framework currently being discussed,
> instead of defining custom bindings?

I am aware of those nvmem framework patches by Srinivas, however from what
I can see that framework has not been merged yet atleast from the mail
chain that I see for v5 of the patchset so I have not properly looked into
that. Mark Brown did apply the regmap patches to his tree, but has the rest
of the framework been merged or is it expected to be merged?

If it is expected to be merged and if that framework is a fit for what we
are trying to do here and it seems so on a quick glance, then I can go with
that. However I still did like to hear from Arnd or have some more comments
before I go for that approach with the next respin.

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

A race condition between debugfs and seq_file operation

[Lisa Du]

Hi, All
Recently I met one race condition related to debugfs.

Take an example from ion.c in kernel3.14:
static int ion_debug_client_open(struct inode *inode, struct file *file)
{
return single_open(file, ion_debug_client_show, inode->i_private);
}

static const struct file_operations debug_client_fops = {
.open = ion_debug_client_open,
.read = seq_read,
.llseek = seq_lseek,
.release = single_release,
};
client->debug_root = debugfs_create_file(client->display_name, 0664,
dev->clients_debug_root,
client, &debug_client_fops);

I find during I read the debugfs node, driver can do 
debugfs_remove_recursive(dentry);
Is it expected?  

In this case, when do the seq_file read, it grabs the seq_file->lock;
While in debugfs_remove_recursive(), it graps "parent->d_inode->i_mutex".
So there seems no protection between the ion_debug_client_show() and 
debugfs_remove_recursive().

Please let me know if I didn't describe the issue clear.
Would you help to comment if there's method to avoid such issue?

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

Re: linux-next: build failure after merge of the drivers-x86 tree

[Darren Hart]

On Thu, Jun 04, 2015 at 07:51:36PM +0200, Radim Krčmář wrote:
> 2015-06-04 18:13+1000, Stephen Rothwell:
> > After merging the drivers-x86 tree, today's linux-next build (x86_64 
> > allmodconfig)
> > failed like this:
> > 
> > ERROR: "acpi_bus_get_status_handle" [drivers/platform/x86/pvpanic.ko] 
> > undefined!
> > 
> > Caused by commit b8f8cf6b02b6 ("pvpanic: handle missing _STA correctly").
> 
> Classic, I only built with Y, sorry.

While I, as a rule, build with both. My apologies for letting this slip through
into -next.

> 
> acpi_bus_get_status_handle is not exported, so a simple solution would
> be to make it so.  Or it's possible to rewrite the patch in a way that
> uses current infrastructure.
> 
> Would you prefer a patch to export it, a build fix on top of
> b8f8cf6b02b6 or a replacement patch?

I'll take the incremental below, but I will roll it into the existing one so
as not to break bisectability in Linus tree.

Thanks,

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

Re: [RESEND 1/2] usb: ehci-exynos: Make provision for vdd regulators

[Anand Moon]

Hi Krzysztof ,

On 8 June 2015 at 07:40, Krzysztof Kozlowski  wrote:
> On 07.06.2015 22:20, Anand Moon wrote:
>> Facilitate getting required 3.3V and 1.0V VDD supply for
>> EHCI controller on Exynos.
>>
>> With the patches for regulators' nodes merged in 3.15:
>> c8c253f ARM: dts: Add regulator entries to smdk5420
>> 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
>> the exynos systems turn on only minimal number of regulators.
>>
>> Until now, the VDD regulator supplies were either turned on
>> by the bootloader, or the regulators were enabled by default
>> in the kernel, so that the controller drivers did not need to
>> care about turning on these regulators on their own.
>> This was rather bad about these controller drivers.
>> So ensuring now that the controller driver requests the necessary
>> VDD regulators (if available, unless there are direct VDD rails),
>> and enable them so as to make them working.
>>
>> Signed-off-by: Vivek Gautam 
>> Signed-off-by: Anand Moon 
>> Cc: Jingoo Han 
>> Cc: Alan Stern 
>> ---
>> Initial version of this patch was part of following series, though
>> they are not dependent on each other, resubmitting after rebasing.
>>
>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266418.html
>
> So you just took Vivek's patch along with all the credits... That is not
> how we usually do this.
>
> I would expect that rebasing a patch won't change the author unless this
> is fine with Vivek.
>

Sorry If I have done some mistake on my part.
I just looked at below mail chain. Before I send it.

http://www.spinics.net/lists/linux-samsung-soc/msg44136.html

I don't want to take any credit out of it. I just re-base on the new kernel.
I could not test this patch as it meant for exynos5440 boards.

-Anand Moon

>> ---
>>  .../devicetree/bindings/usb/exynos-usb.txt |  2 +
>>  drivers/usb/host/ehci-exynos.c | 55 
>> +-
>>  2 files changed, 56 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt 
>> b/Documentation/devicetree/bindings/usb/exynos-usb.txt
>> index 9b4dbe3..776fa03 100644
>> --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
>> +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
>> @@ -23,6 +23,8 @@ Required properties:
>>  Optional properties:
>>   - samsung,vbus-gpio:  if present, specifies the GPIO that
>> needs to be pulled up for the bus to be powered.
>> + - vdd33-supply: handle to 3.3V Vdd supply regulator for the controller.
>> + - vdd10-supply: handle to 1.0V Vdd supply regulator for the controller.
>>
>>  Example:
>>
>> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
>> index df538fd..4f8f9d2 100644
>> --- a/drivers/usb/host/ehci-exynos.c
>> +++ b/drivers/usb/host/ehci-exynos.c
>> @@ -21,6 +21,7 @@
>>  #include 
>>  #include 
>>  #include 
>> +#include 
>>  #include 
>>  #include 
>>
>> @@ -45,6 +46,8 @@ static struct hc_driver __read_mostly 
>> exynos_ehci_hc_driver;
>>  struct exynos_ehci_hcd {
>>   struct clk *clk;
>>   struct phy *phy[PHY_NUMBER];
>> + struct regulator *vdd33;
>> + struct regulator *vdd10;
>>  };
>>
>>  #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd 
>> *)(hcd_to_ehci(hcd)->priv)
>> @@ -170,7 +173,27 @@ static int exynos_ehci_probe(struct platform_device 
>> *pdev)
>>
>>   err = exynos_ehci_get_phy(&pdev->dev, exynos_ehci);
>>   if (err)
>> - goto fail_clk;
>> + goto fail_regulator1;
>> +
>> + exynos_ehci->vdd33 = devm_regulator_get_optional(&pdev->dev, "vdd33");
>> + if (!IS_ERR(exynos_ehci->vdd33)) {
>> + err = regulator_enable(exynos_ehci->vdd33);
>> + if (err) {
>> + dev_err(&pdev->dev,
>> + "Failed to enable 3.3V Vdd supply\n");
>> + goto fail_regulator1;
>> + }
>> + }
>> +
>> + exynos_ehci->vdd10 = devm_regulator_get_optional(&pdev->dev, "vdd10");
>> + if (!IS_ERR(exynos_ehci->vdd10)) {
>> + err = regulator_enable(exynos_ehci->vdd10);
>> + if (err) {
>> + dev_err(&pdev->dev,
>> + "Failed to enable 1.0V Vdd supply\n");
>> + goto fail_regulator2;
>> + }
>> + }
>>
>>  skip_phy:
>>
>> @@ -231,6 +254,10 @@ fail_add_hcd:
>>  fail_io:
>>   clk_disable_unprepare(exynos_ehci->clk);
>>  fail_clk:
>> + regulator_disable(exynos_ehci->vdd10);
>> +fail_regulator2:
>> + regulator_disable(exynos_ehci->vdd33);
>
> if (!IS_ERR()).
>
>> +fail_regulator1:
>>   usb_put_hcd(hcd);
>>   return err;
>>  }
>> @@ -246,6 +273,11 @@ static int exynos_ehci_remove(struct platform_device 
>> *pdev)
>>
>>   clk_disable_unprepare(exynos_ehci->clk);
>>
>> + if (!IS_ERR(exynos_ehci->vdd33))
>> + regulator_disable(exynos_ehci->vdd33);
>> + if (!IS_ERR(exynos_ehci->vdd10))
>> + r

Re: [PATCH] added device tree support to gpio-generic driver

[Alexandre Courbot]

On Fri, Jun 5, 2015 at 3:51 PM, Romain Baeriswyl
 wrote:
> ---

Your patch is missing a detailed commit message.

>  .../devicetree/bindings/gpio/gpio-generic.txt  |   19 +
>  drivers/gpio/gpio-generic.c|   81 ++-
>  2 files changed, 78 insertions(+), 22 deletions(-)
>  create mode 100644 Documentation/devicetree/bindings/gpio/gpio-generic.txt
>
> diff --git a/Documentation/devicetree/bindings/gpio/gpio-generic.txt 
> b/Documentation/devicetree/bindings/gpio/gpio-generic.txt
> new file mode 100644
> index 000..c2c4b98
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/gpio/gpio-generic.txt
> @@ -0,0 +1,19 @@
> +Bindings for gpio-generic
> +
> +Required properties:
> +- compatible : "basic-mmio-gpio" for little endian register access or
> +   "basic-mmio-gpio-be" for big endian register access
> +- ngpios: Specifies the number of gpio mapped in the register. The value is
> +  limited to the number of bits of the LONG type.
> +
> +Optional properties:
> +- base: Allows to forces the gpio number base offset used to index the gpio 
> in
> +the device. If it is not see then the driver search autonoumously for
> +valid index range.

A base property for GPIO drivers is frown upon nowadays. >:/

> +
> +Examples:
> +
> +   gpio_a {
> +   compatible = "basic-mmio-gpio";
> +   ngpios = <32>;
> +   };
> diff --git a/drivers/gpio/gpio-generic.c b/drivers/gpio/gpio-generic.c
> index b92a690..9a4354c 100644
> --- a/drivers/gpio/gpio-generic.c
> +++ b/drivers/gpio/gpio-generic.c
> @@ -15,11 +15,11 @@
>   *  `.just a single "data" register, where GPIO state can be read and/or `
>   *`,..written. ,,..`` .``.`.`.~~.```.`.``.```
>   *`
> -___
> -_/~~|___/~|   . ```~~   ___/___\___ ,~.`.`.`.`.~~......
> -__|~$@~~~%~/o*o*o*o*o*o\   .. Implementing such a GPIO .
> -o` \___/` controller in FPGA is ,.`
> - `trivial..'~`.```.```
> + *   ___
> + * _/~~|___/~|   . ```~~   ___/___\___ 
> ,~.`.`.`.`.~~......
> + * __|~$@~~~%~/o*o*o*o*o*o\   .. Implementing such a 
> GPIO .
> + * o` \___/` controller in FPGA is 
> ,.`
> + *`trivial..'~`.```.```

Comment fix? Why not, but this is not related to the subject of this
patch. Please do this in a separate patch.

>   *```
>   *  .````..`.``.``.
>   * .  The driver supports  `...   ,..```.`~~~```.``,,
> @@ -61,6 +61,8 @@ o` \___/` 
> controller in FPGA is ,.`
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>
>  static void bgpio_write8(void __iomem *reg, unsigned long data)
>  {
> @@ -375,10 +377,9 @@ static int bgpio_setup_accessors(struct device *dev,
> dev_err(dev,
> "64 bit big endian byte order unsupported\n");
> return -EINVAL;
> -   } else {
> -   bgc->read_reg   = bgpio_read64;
> -   bgc->write_reg  = bgpio_write64;
> }
> +   bgc->read_reg   = bgpio_read64;
> +   bgc->write_reg  = bgpio_write64;

Why change this? This if/else sequence was consistent with the other
cases, I think it would be better to keep it that way.

> break;
>  #endif /* BITS_PER_LONG >= 64 */
> default:
> @@ -564,6 +565,27 @@ static void __iomem *bgpio_map(struct platform_device 
> *pdev,
> return ret;
>  }
>
> +static const struct platform_device_id bgpio_id_table[] = {
> +   { "basic-mmio-gpio",
> + .driver_data  = 0,
> +   }, { "basic-mmio-gpio-be",
> + .driver_data  = BGPIOF_BIG_ENDIAN
> +   },
> +   { },
> +};

Formatting is wrong here. Please keep the same formatting as the
original statement.

> +MODULE_DEVICE_TABLE(platform, bgpio_id_table);
> +
> +static const struct of_device_id  bgpio_dt_ids[] = {
> +   { .compatible = "basic-mmio-gpio",

Same remark about formatting.

> + .data = bgpio_id_table + 0

I would probably prefer &bgpio_id_table[0], but your call.

> +   },
> +   { .compatible = "basic-mmio-gpio-be",
> + .data = bgpio_id_table + 1
> +   },

Instead of having two different compatible strings, how about making
the big-endian option a boolean DT property?

> +   { }
> +};
> +MODULE_DEVICE_TABLE(of, bgpio_dt_ids);
> +
>  static int bgpio_pdev_probe(struct platform_device *pdev)
>  {
> struct device *dev = &pdev->dev;
> @@ -574,10 +596,37 @@ static int bgpio_pdev_probe(struct platform_devi

non-rotational USB stick?

[Harald Dunkel]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi folks,

Is there some way to make the kernel automatically recognize a
USB stick as a non-rotational device?

(My hope is that the CFQ IOPS mode patch might improve performance
of a USB stick as well :-)


Regards
Harri
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQEcBAEBCAAGBQJVdRWGAAoJEAqeKp5m04HLxLYH/AuECvumy3UkdNwRA7yOUHKo
3GyRC95iv+AzIVk2Iceqgcza6RV3uYnS22SDpWIz0/Y+ArdqzrMpWCdvnExLAQBR
PZg+wmDSpE7DFamAakGM6g0ca5LPXMqklLJx7TMMPQ3rIBqRdqOHJiLA6r+Qw8iI
ZqTfWDQILmv4j2O9FAzvV6ksoYAxUBSGivtaXirkWFPaCTH1hyUbFh3cPJl5x7r/
yfg04k68bevPVdYc/2ItplDpA0xVoYTg1gejKNla0v7cV8jL7RC7pZoWtyXFUjFi
X3+MOtCXDFJ8701Vt/J++t4t4jEsgXQZ2vemXw51RMwzFnMD12HeqP7itnkQzqg=
=ZPwG
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v5 0/3] Dell Airplane Mode Switch driver

[Darren Hart]

On Sat, Jun 06, 2015 at 10:23:27AM +0200, Pali Rohár wrote:
> This patch series add new acpi Dell Airplane Mode Switch driver (DELLABCE and
> DELRBTN acpi devices). It provides radio HW switch events (together with 
> current
> state of radio devices) and export them via rfkill interface. These events are
> also used in dell-laptop driver instead i8042 filter hook function (when acpi
> device is available).
> 
> In v2 was added support for laptops which have toggle button instead HW slider
> switch. For that I reused code done by Alex Hung.
> 
> v3 is just cleanup.
> 
> In v4 was fixed dependency problems.

Please be more specific in the future. You want people that haven't looked at
this for a couple of weeks to be able to quickly identify what changed and
confirm they agree. You want people to review your code, you want to reduce the
barrier to do so. Easy to do while it's fresh in your mind.

Thanks for the update, I have these qeueud to testing.

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

Re: [PATCH 0/6] x86: reduce paravirtualized spinlock overhead

[Juergen Gross]

Ping?

Anything missing from my side?

On 04/30/2015 12:53 PM, Juergen Gross wrote:

Paravirtualized spinlocks produce some overhead even if the kernel is
running on bare metal. The main reason are the more complex locking
and unlocking functions. Especially unlocking is no longer just one
instruction but so complex that it is no longer inlined.

This patch series addresses this issue by adding two more pvops
functions to reduce the size of the inlined spinlock functions. When
running on bare metal unlocking is again basically one instruction.

Compile tested with CONFIG_PARAVIRT_SPINLOCKS on and off, 32 and 64
bits.

Functional testing on bare metal and as Xen dom0.

Correct patching verified by disassembly of active kernel.

Juergen Gross (6):
   x86: use macro instead of "0" for setting TICKET_SLOWPATH_FLAG
   x86: move decision about clearing slowpath flag into arch_spin_lock()
   x86: introduce new pvops function clear_slowpath
   x86: introduce new pvops function spin_unlock
   x86: switch config from UNINLINE_SPIN_UNLOCK to INLINE_SPIN_UNLOCK
   x86: remove no longer needed paravirt_ticketlocks_enabled

  arch/x86/Kconfig  |  1 -
  arch/x86/include/asm/paravirt.h   | 13 +
  arch/x86/include/asm/paravirt_types.h | 12 
  arch/x86/include/asm/spinlock.h   | 53 ---
  arch/x86/include/asm/spinlock_types.h |  3 +-
  arch/x86/kernel/kvm.c | 14 +
  arch/x86/kernel/paravirt-spinlocks.c  | 42 +--
  arch/x86/kernel/paravirt.c| 12 
  arch/x86/kernel/paravirt_patch_32.c   | 25 +
  arch/x86/kernel/paravirt_patch_64.c   | 24 
  arch/x86/xen/spinlock.c   | 23 +--
  include/linux/spinlock_api_smp.h  |  2 +-
  kernel/Kconfig.locks  |  7 +++--
  kernel/Kconfig.preempt|  3 +-
  kernel/locking/spinlock.c |  2 +-
  lib/Kconfig.debug |  1 -
  16 files changed, 154 insertions(+), 83 deletions(-)


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

Re: [Patch v4 0/8] Consolidate ACPI PCI root common code into ACPI core

[Hanjun Guo]

On 2015年06月05日 00:29, Jiang Liu wrote:

On 2015/6/4 23:51, Mark Salter wrote:

On Thu, 2015-06-04 at 14:41 +0800, Jiang Liu wrote:

On 2015/6/4 14:31, Hanjun Guo wrote:

Hi Jiang,

On 2015年06月04日 09:54, Jiang Liu wrote:

On 2015/6/4 4:27, Al Stone wrote:

On 06/02/2015 12:12 AM, Jiang Liu wrote:

This patch set consolidates common code to support ACPI PCI root on x86
and IA64 platforms into ACPI core, to reproduce duplicated code and
simplify maintenance. And a patch set based on this to support ACPI
based
PCIe host bridge on ARM64 has been posted at:


Link is missing (or it's a typo of some flavor).

HI Al,
 Sorry, I missed the link. It has been posted at:
https://lkml.org/lkml/2015/5/26/207


I failed to get io resources for PCI hostbridge  when I was testing PCI
on ARM64 QEMU, I debugged this for quite a while, and finally found out
that ACPI resource parsing for IO is not suitable for ARM64, because io
space for x86 is 64K, but 16M for ARM64.

This issue is only found when the firmware representing the io resource
using the type ACPI_RESOURCE_TYPE_ADDRESS32, so the io address will
greater than 64k.

In drivers/acpi/resource.c:

static void acpi_dev_ioresource_flags(struct resource *res, u64 len,
   u8 io_decode, u8 translation_type)
{
 res->flags = IORESOURCE_IO;

[...]

 if (res->end >= 0x10003)
 res->flags |= IORESOURCE_DISABLED | IORESOURCE_UNSET;

[...]
}

so the code will filter out res->end >= 0x10003, and in my case, it will
more than 64K, so we can't get the IO resources.

I got a question, why we use if (res->end >= 0x10003) here?
I mean 64k will be 0x1, and in that case, we should use
if (res->end >= 0x1) here, not 0x10003, any history behind that?


Hi Hanjun,
This is a special tricky for x86. You may read a dword(four bytes) from
IO port 0x, so the effective io port space is 0x10003 bytes.



Is there something in ACPI spec which would limit PCI IO space to 64K?
PCI itself allows 32-bit IO addresses and at least some arm64 platforms
use PCI bus addresses above 64K for IO transactions. From a PCI view,
the (res->end >= 0x10003) check doesn't make sense. Am I missing
something?

HI Mark,
Something interesting here. According to my understanding,
the actually limitations are
1) the maximum size for each IO port space is 64k,
2) each PCI segment may only have one IO port space assigned at most.

Other than those, it's flexible for system designer to:
1) have multiple IO port spaces, each is 64K at most.
2) CPU may use MMIO transactions to access PCI IO space, and PCI host
bridge will do the translation from CPU side MMIO address to PCI side
IO port address.

For example, we may have following configuration on IA64 platforms:
1) CPU side physical address [0x1-0x10001] maps to IO space
[0x0-0x1] on PCI segment 0
2) CPU side physical address [0x10001-0x10002] maps to IO space
[0x0-0x1] on PCI segment 1
And ACPI resource descriptor provides 'translation_offset' to support
such an usage case. Hope this helps:)


Hi Jiang,

It seems the translation_offset for IA64 is assuming to zero in this
patch set, which have regressions if we use DworldIO() with offset
to report io port resources, am I missing something?

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

平时最多也就联系了三千家，全球还有十几万客户在哪里？

[iSayor]

您好:
   您还在用ali平台开发外贸客户?
  还在使用展会宣传企业和产品?
你out了!!!
当前外贸客户开发难，您是否也在寻找展会，B2B之外好的渠道？
行业全球十几万客户，平时最多也就联系了三千家，您是否想把剩下的也开发到？
加QQ2821117472给您演示下主动开发客户的方法，先用先受益，已经有近万家企业领先您使用！！。
广东省商业联合会推荐，主动开发客户第一品牌，近万家企业正在获益。您可以没有使用，但是不能没有了解。


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

Re: [PATCH 5/6] phy: twl4030-usb: add support for reading resistor on ID pin.

[Felipe Balbi]

On Sat, Jun 06, 2015 at 03:10:09PM +0200, Pavel Machek wrote:
> On Tue 2015-06-02 07:37:31, NeilBrown wrote:
> > On Mon, 1 Jun 2015 19:06:52 +0530 Kishon Vijay Abraham I 
> > wrote:
> > 
> > > Hi,
> > > 
> > > On Thursday 16 April 2015 01:33 PM, NeilBrown wrote:
> > > > From: NeilBrown 
> > > >
> > > > The twl4030 phy can measure, with low precision, the
> > > > resistance-to-ground of the ID pin.
> > > >
> > > > Add a function to read the value, and export the result
> > > > via sysfs.
> > > 
> > > Little sceptical about adding new sysfs entries. Do you have a good 
> > > reason to 
> > > add this?
> > 
> > The hardware can report the value, so why not present it to user-space?
> > 
> > I originally used this with a udev rule which would configure the maximum
> > current based on the resistance measure - to work with the particular 
> > charger
> > hardware I have.
> > 
> > More recent patches try to do all of the max-current configuration in the
> > kernel, so I could live without exporting the value via sysfs if that is a
> > show-stopper.
> > 
> > I can't see where the scepticism comes from though.  It is a well defined
> > and cleary documented feature of the hardware.  Why not expose it?
> 
> sysfs interface is supposed to work for different chargers, without userspace
> noticing.
> 
> Are these values the ones that are likely to be useful there?

These values come from Battery Charger specification 1.1+, IIRC, so no
other values should show up unless documented in future BC revisions.

> > > > +   Possible values are:
> > > > +   ground
> > > > +   102k
> > > > +   200k
> > > > +   440k
> > > > +   floating
> > > > +   unknown
> 
> ...or would it make more sense to export for example numerical ohms, as that's
> what are other chargers likely to provide?

How do you expose "floating" in Ohms ? UINT_MAX might be one way, but
that would have to be documented.

-- 
balbi


signature.asc
Description: Digital signature

Re: [PATCH] usb: gadget: nokia: Add mass storage driver to g_nokia

[Felipe Balbi]

On Sat, Jun 06, 2015 at 10:04:55AM +0200, Pali Rohár wrote:
> On Friday 05 June 2015 22:17:09 Felipe Balbi wrote:
> > Hi,
> > 
> > On Fri, Jun 05, 2015 at 10:09:03PM +0200, Pali Rohár wrote:
> > > On Friday 29 May 2015 18:57:06 Felipe Balbi wrote:
> > > > All right, I tried merging it and it added build breaks to the
> > > > tree. I'll wait for another version for v4.3 merge window.
> > > > 
> > > > cheers
> > > 
> > > Hello, version below compiles fine on top of linus tree. Please
> > > apply:
> > 
> > no signed-off-by,
> 
> Signed-off-by: Pali Rohár 
> 
> > not commit log.
> 
> This patch adds removable mass storage support to g_nokia gadget (for 
> N900). It means that at runtime block device can be exported or 
> unexported. So it does not export anything by default and thus allows to 
> use MyDocs partition as before...

sorry, but you gotta resend it, you're just a git commit && git
send-email -1 away.

-- 
balbi


signature.asc
Description: Digital signature

Linux 4.1-rc7

[Linus Torvalds]

Another Sunday, another rc release.

Normally rc7 tends to be the last rc release, and there's not a lot
going on to really merit anything else this time around. However, we
do still have some pending regressions, and as mentioned last week I
also have my yearly family vacation coming up, so we'll have an rc8
and an extra week before 4.1 actually gets released.

It's been quieting down nicely, though, and rc7 is certainly worth
testing out to verify that it all works for you. Because this is
pretty darn close to final, and it should be safe to test. The changes
that have come in the last week are all pretty small, the appended
shortlog should give you a flavor of what's going on. A lot of it is
one-liners, with a few slightly bigger patches to some architecture
files (x86 perf constraints, some sparc updates) and staging drivers.

Linus

---

Alban Bedel (1):
  MIPS: ath79: Add a missing new line in log message

Alex Deucher (1):
  drm/radeon: use proper ACR regisiter for DCE3.2

Alexander Duyck (3):
  ip_vti/ip6_vti: Do not touch skb->mark on xmit
  xfrm: Override skb->mark with tunnel->parm.i_key in xfrm_input
  ip_vti/ip6_vti: Preserve skb->mark after rcv_cb call

Alexander Shishkin (3):
  perf: Disallow sparse AUX allocations for non-SG PMUs in overwrite mode
  perf/x86/intel/pt: Untangle pt_buffer_reset_markers()
  perf/x86/intel/pt: Fix a refactoring bug

Alexandre Courbot (1):
  swiotlb: do not export map_single function

Alexei Starovoitov (1):
  perf: Fix race in BPF program unregister

Alexey Skidanov (1):
  drm/amdkfd: fix topology bug with capability attr.

Ander Conselvan de Oliveira (1):
  drm/i915: Include G4X/VLV/CHV in self refresh status

Andy Lutomirski (2):
  x86/asm/entry/32, selftests: Add a selftest for kernel entries
from VM86 mode
  x86/asm/irq: Stop relying on magic JMP behavior for early_idt_handlers

Arend van Spriel (1):
  brcmfmac: avoid null pointer access when brcmf_msgbuf_get_pktid() fails

Arnd Bergmann (1):
  NVMe: fix type warning on 32-bit

Arthur Demchenkov (1):
  usb: make module xhci_hcd removable

Arun Siluvery (1):
  drm/i915: Initialize HWS page address after GPU reset

Axel Lin (3):
  phy: core: Fix error checking in (devm_)phy_optional_get
  i2c: hix5hd2: Fix modalias to make module auto-loading work
  iio: adc: twl6030-gpadc: Fix modalias

Ben Hutchings (1):
  usb: musb: fix order of conditions for assigning end point operations

Bernhard Thaler (1):
  Revert "netfilter: ensure number of counters is >0 in do_replace()"

Chris Bainbridge (1):
  usb: host: xhci: add mutex for non-thread-safe data

Chris Leech (1):
  iscsi_ibft: filter null v4-mapped v6 addresses

Christophe Jaillet (1):
  sparc: kernel: GRPCI2: Remove a useless memset

Clemens Ladisch (2):
  ALSA: usb-audio: add MAYA44 USB+ mixer control names
  ALSA: usb-audio: fix missing input volume controls in MAYA44 USB(+)

Daniel Pieczko (1):
  sfc: free multiple Rx buffers when required

Dave Martin (1):
  serial/amba-pl011: Unconditionally poll for FIFO space before each TX char

David S. Miller (1):
  Revert "net: core: 'ethtool' issue with querying phy settings"

Don Zickus (1):
  perf/x86: Tweak broken BIOS rules during check_hw_exists()

Eric Dumazet (2):
  bridge: fix br_multicast_query_expired() bug
  udp: fix behavior of wrong checksums

Eric Snowberg (1):
  sparc64: pci slots information is not populated in sysfs

Eric Wong (1):
  ALSA: usb-audio: don't try to get Outlaw RR2150 sample rate

Fabio Estevam (2):
  usb: phy: ab8500-usb: Pass the IRQF_ONESHOT flag
  usb: phy: tahvo: Pass the IRQF_ONESHOT flag

Felipe Balbi (1):
  phy: fix Kconfig dependencies

Florian Fainelli (1):
  net: dsa: Properly propagate errors from dsa_switch_setup_one

Geert Uytterhoeven (1):
  of/dynamic: Fix test for PPC_PSERIES

Hans de Goede (2):
  Input: elantech - fix detection of touchpads where the revision
matches a known rate
  Input: alps - do not reduce trackpoint speed by half

Helge Deller (1):
  compat: cleanup coding in compat_get_bitmap() and compat_put_bitmap()

Herbert Xu (3):
  esp4: Use high-order sequence number bits for IV generation
  esp6: Use high-order sequence number bits for IV generation
  xfrm: Always zero high-order sequence number bits

Huacai Chen (1):
  MIPS: Loongson-3: Fix a cpu-hotplug issue in loongson3_ipi_interrupt()

Ian Campbell (2):
  xen: netback: fix printf format string warning
  xen: netback: read hotplug script once at start of day.

Ilan Peer (1):
  iwlwifi: pcie: fix tracking of cmd_in_flight

Ingo Molnar (1):
  x86/boot: Add CONFIG_PARAVIRT_SPINLOCKS quirk to
arch/x86/boot/compressed/misc.h

Ivan Vecera (3):
  bna: fix firmware loading on big-endian machines
  bna: remove unreasonable iocpf timer start
  bna: fix soft lock-up during firmware 

Help-desk Service Center requires your immediate re-activation of your Email account

[Bleser, S.H.R.]

Help-desk Service Center requires your immediate re-activation of your Email
account. This is to upgrade email account to the new anti spam virus detector
sever 2014. Inability to complete this procedure will render your account
inactivate. Activate by completing the survey procedure.
CLICK LINK:  to activate.
CLICK HERE:
Thank you for using Webmail
Copyright © 2014 Webmail Help Desk
Updating Webmail Technical Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC] percpu section full of holes

[Tejun Heo]

On Mon, Jun 08, 2015 at 12:09:32PM +0900, Tejun Heo wrote:
> For things we want to pack together, I suppose our only option is
> packing them into a struct and defining access macros into it.  It's
> unfortunately clumsier but expresses the intended effect clearer to
> both readers and toolchain.

One annoying thing is that we prolly have quite a few places where
people put things which are likely to be used together close to each
other intentionally and by convention and we're now losing all that
contextual information.  I have no idea whatsoever whether the gain
from toolchain shuffling symbols around is larger or smaller than
whatever gain which can be gained from such colocations.

Thanks.

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

Generous Donation

[Bill William And Andrea Groner]

I saw your email address during the course of my  research today. My name is 
Bill William Groner my wife and I won a Jackpot Lottery in December 2013, we 
are donating the part of our winnings to 6 lucky individual all over the world 
as part of our charity project and if you received this email then you are one 
of the luck recipients and all you have to do is get back to us with your 
details so we can forward it directly to the payout bank. 

Good luck,
Bill William And Andrea Groner

-- 
Ezen uzenet virusellenorzesen esett at, es virusmentesnek bizonyult.
MailScanner - Email Virus Scanner - http://www.mailscanner.info
Pentru orice informatii sau suport tehnic: http://www.smarttrend.ro 

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

Re: [RFC] percpu section full of holes

[Tejun Heo]

Hello, Eric.

On Sun, Jun 07, 2015 at 09:55:07AM -0700, Eric Dumazet wrote:
> In commit bdf977b37418cdf8a2252504779a7e12a09b7575
> ("x86, percpu: Collect hot percpu variables into one cacheline")
> 
> You wrote that forcing cacheline_aligned on
> current_task would put all hot variables together.
>
> However this seems not generally true.

Heh, that's way back.  It's likely something caused by changes in the
toolchain.

...
> compiler/linker do not seem to care about the order in the source file.

Indeed.  It seems to be related to the top level reordering.
-fno-toplevel-reorder seems to behave weirdly on gcc 5.1.1 - the
option reverses the symbols but the order is different from the source
code order regardless of the option.

Source code order.

 kernel_stack
 current_task
 irq_stack_ptr
 irq_count
 __preempt_count
 fpu_owner_task
 orig_ist
 debug_stack_usage
 debug_idt_ctr

w/o -fno-toplevel-reorder

 193: 0008 8 OBJECT  GLOBAL DEFAULT   27 fpu_owner_task
 151: 0010 4 OBJECT  GLOBAL DEFAULT   27 debug_stack_usage
 153: 0014 4 OBJECT  GLOBAL DEFAULT   27 debug_idt_ctr
 172: 0018 4 OBJECT  GLOBAL DEFAULT   27 __preempt_count
 187: 0020 8 OBJECT  GLOBAL DEFAULT   27 kernel_stack
 195: 0028 4 OBJECT  GLOBAL DEFAULT   27 irq_count
 196: 0030 8 OBJECT  GLOBAL DEFAULT   27 irq_stack_ptr
 164: 004056 OBJECT  GLOBAL DEFAULT   27 orig_ist
 167: 0080 8 OBJECT  GLOBAL DEFAULT   27 current_task
   
w/ -fno-toplevel-reorder (mirror image of w/o -fno-toplevel-reorder?)

  97:  8 OBJECT  GLOBAL DEFAULT6 current_task
 106: 002056 OBJECT  GLOBAL DEFAULT6 orig_ist
 108: 0058 8 OBJECT  GLOBAL DEFAULT6 irq_stack_ptr
 110: 0060 4 OBJECT  GLOBAL DEFAULT6 irq_count
 111: 0068 8 OBJECT  GLOBAL DEFAULT6 kernel_stack
 113: 0070 4 OBJECT  GLOBAL DEFAULT6 __preempt_count
 115: 0074 4 OBJECT  GLOBAL DEFAULT6 debug_idt_ctr
 116: 0078 4 OBJECT  GLOBAL DEFAULT6 debug_stack_usage
 117: 0080 8 OBJECT  GLOBAL DEFAULT6 fpu_owner_task

and then the linker goes onto interpose symbols from different object
files.

...
> I wish we had a way to remove the automatic alignment of ELF sections
> based on size of objects/structures.
> Why __alignof__ is not respected I dont know.

It's still following the alignments specified tho.  It's just that all
the symbols get shuffled.

> linker propagates the biggest alignment to various built-in.o builds,
> and we have all these holes.
> 
> objdump -h kernel/built-in.o | grep data..percpu
>  28 .data..percpu 3ce0      0011c940  2**6
> 283 .data..percpu..shared_aligned 1720    
>   00146e80  2**6
> 
> We might add a DEFINE_PER_CPU_SMALL() for objects less than sizeof(long),
> but this would mean a lot of changes in the tree.

ld has --sort-common option which sorts symbols by their alignments
which isn't ideal but could help packing smaller percpu variables.  I
can't find a way to prevent ld from interposing symbols and we seem to
have lost control over offset placement no matter what.

> And we would still have holes when per cpu objects are 40 bytes long,
> because we would not use the 24 bytes after them.

It's not like we didn't have holes before tho.  We just had holes
according to source code order and could control it when we explicitly
wanted to.  Overall, compiler / linker reshuffling them at least has
possibility of packing things better.

For things we want to pack together, I suppose our only option is
packing them into a struct and defining access macros into it.  It's
unfortunately clumsier but expresses the intended effect clearer to
both readers and toolchain.

Thanks.

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

Re: [PATCH 05/11] x86, pci, acpi: Move arch-agnostic MMCONFIG (aka ECAM) and ACPI code out of arch/x86/ directory

[Hanjun Guo]

On 2015年06月04日 20:28, Hanjun Guo wrote:

On 2015年06月04日 18:22, Lorenzo Pieralisi wrote:

Hi Hanjun,

On Thu, Jun 04, 2015 at 10:28:17AM +0100, Hanjun Guo wrote:

Hi Lorenzo,

On 2015???06???02??? 21:32, Lorenzo Pieralisi wrote:

On Wed, May 27, 2015 at 09:06:26AM +0100, Tomasz Nowicki wrote:

On 26.05.2015 19:08, Will Deacon wrote:

On Tue, May 26, 2015 at 01:49:18PM +0100, Hanjun Guo wrote:

From: Tomasz Nowicki 

ECAM standard and MCFG table are architecture independent and it
makes
sense to share common code across all architectures. Both are
going to
corresponding files - ecam.c and mcfg.c

While we are here, rename pci_parse_mcfg to acpi_parse_mcfg.
We already have acpi_parse_mcfg prototype which is used nowhere.
At the same time, we need pci_parse_mcfg been global so
acpi_parse_mcfg
can be used perfectly here.

Signed-off-by: Tomasz Nowicki 
Signed-off-by: Hanjun Guo 
Tested-by: Suravee Suthikulpanit 
---
arch/x86/Kconfig   |   3 +
arch/x86/include/asm/pci_x86.h |  33 --
arch/x86/pci/acpi.c|   1 +
arch/x86/pci/mmconfig-shared.c | 244
+---
arch/x86/pci/mmconfig_32.c |   1 +
arch/x86/pci/mmconfig_64.c |   1 +
arch/x86/pci/numachip.c|   1 +
drivers/acpi/Makefile  |   1 +
drivers/acpi/mcfg.c|  57 ++
drivers/pci/Kconfig|   7 ++
drivers/pci/Makefile   |   5 +
drivers/pci/ecam.c | 245
+


Why can't we make use of the ECAM implementation used by
pci-host-generic
and drivers/pci/access.c?


We had that question when I had posted MMCFG patch set separately,
please see:
https://lkml.org/lkml/2015/3/11/492


Yes, but the real question is, why do we need to have PCI config space
up and running before a bus struct is even created ? I think the
reason is
the PCI configuration address space format (ACPI 6.0, Table 5-27, page
108):

"PCI Configuration space addresses must be confined to devices on
PCI Segment Group 0, bus 0. This restriction exists to accommodate
access to fixed hardware prior to PCI bus enumeration".

On HW reduced platforms I do not even think this is required at all,
we have to look into this to avoid code duplication that might well
turn out useless.


This is only for the fixed hardware, which will be not available for
ARM64 (reduced hardware mode), but in Generic Hardware Programming
Model, we using OEM-provided ACPI Machine Language (AML) code to access
generic hardware registers, this will be available for reduced hardware
too.

So in ACPI spec, it says: (ACPI 6.0 page 66, last paragraph)

ACPI defines eight address spaces that may be accessed by generic
hardware implementations. These include:
* System I/O space
* System memory space
* PCI configuration space
* Embedded controller space
* System Management Bus (SMBus) space
* CMOS
* PCI BAR Target
* IPMI space

So if any device using the PCI address space for control, such
as a system reset control device, its address space can be reside
in PCI configuration space (who can prevent a OEM do that crazy
thing? :) ), and it should be accessible before the PCI bus is
created.


Us, by changing attitude and questioning features whose usefulness
is questionable. I will look into this and raise the point, I am not
thrilled by the idea of adding another set of PCI accessor functions
and drivers because we have to access a register through PCI before
enumerating the bus (and on arm64 this is totally useless since
we are not meant to support fixed HW anyway). Maybe we can make acpica
code use a "special" stub (ACPI specific, PCI configuration space address
space has restrictions anyway), I have to review this set in its
entirety to see how to do that (and I would kindly ask you to do
it too, before saying it is not possible to implement it).


I'm willing to do that, actually, if we don't need a mechanism to
access PCI config space before the bus is created, the code can be
simplified a lot.


After more investigation on the spec and the ACPI core code, I'm
still not convinced that accessing to PCI config space before PCI
bus creating is impossible, also there is no enough ARM64 hardware
to prove that too. But I think we can go in this way, reuse the
ECAM implementation by pci-host-generic for now, and implement the PCI
accessor functions before enumerating PCI bus when needed in the
future, does it make sense?

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

Re: [PATCH] isdn/hisax: Convert use of __constant_cpu_to_le16 to cpu_to_le16

[David Miller]

From: Vaishali Thakkar 
Date: Sat, 6 Jun 2015 06:44:00 +0530

> In big endian cases, macro cpu_to_le16 unfolds to __swab16 which
> provides special case for constants. In little endian cases,
> __constant_cpu_to_le16 and cpu_to_le16 expand directly to the
> same expression. So, replace __constant_cpu_to_le16 with
> cpu_to_le16 with the goal of getting rid of the definition of
> __constant_cpu_to_le16 completely.
> 
> The semantic patch that performs this transformation is as follows:
> 
> @@expression x;@@
> 
> - __constant_cpu_to_le16(x)
> + cpu_to_le16(x)
> 
> Signed-off-by: Vaishali Thakkar 

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

Re: [PATCH] kobject: avoid unnecessary assignment of kobj->parent

[Wei Yang]

On Sat, Jun 06, 2015 at 01:22:30PM +0900, Greg KH wrote:
>On Thu, Jun 04, 2015 at 10:13:50AM +0800, Wei Yang wrote:
>> kobj->parent is changed only when it is NULL originally.
>> 
>> This patch moves the assignment in the "if" to avoid unnecessary assignment.
>> 
>> Signed-off-by: Wei Yang 
>> ---
>>  lib/kobject.c |3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>> 
>> diff --git a/lib/kobject.c b/lib/kobject.c
>> index 03d4ab3..37b10bb 100644
>> --- a/lib/kobject.c
>> +++ b/lib/kobject.c
>> @@ -216,9 +216,8 @@ static int kobject_add_internal(struct kobject *kobj)
>>  /* join kset if set, use it as parent if we do not already have one */
>>  if (kobj->kset) {
>>  if (!parent)
>> -parent = kobject_get(&kobj->kset->kobj);
>> +parent = kobj->parent = kobject_get(&kobj->kset->kobj);
>>  kobj_kset_join(kobj);
>> -kobj->parent = parent;
>
>What is this "fixing"?  I hate multiple assignments on the same line,
>it makes it harder to read and understand.
>

Hi Greg

No. This one is not "fixing" anything. What it does is to not assign the
kobj->parent again when it is not changed.

No, this is not a "fixing". So it doesn't help on the functionality or
improve the performance. It just wants to make it clear that the kobj->parent
is changed when originally it is NULL, not for other cases. Hope this would
help a little.

I didn't noticed that you don't like this format, so I didn't want to offend
you intendedly. How about move "kobj->parent = parent" above and add a brace
to the if? For example like this:

/* join kset if set, use it as parent if we do not already have one */
if (kobj->kset) {
-   if (!parent)
+   if (!parent) {
parent = kobject_get(&kobj->kset->kobj);
+   kobj->parent = parent;
+   }
kobj_kset_join(kobj);
-   kobj->parent = parent;

>greg k-h

-- 
Richard Yang
Help you, Help me

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

Re: [PATCH] ethernet: micrel: use time_is_before_eq_jiffies

[David Miller]

From: Antonio Murdaca 
Date: Fri,  5 Jun 2015 18:58:38 +0200

> use time_is_before_eq_jiffies macro for time comparison
> 
> Signed-off-by: Antonio Murdaca 

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

Re: [PATCH] net: moxa: fix TX overrun memory leak

[David Miller]

From: Jonas Jensen 
Date: Fri,  5 Jun 2015 15:46:18 +0200

>   desc = priv->tx_desc_base + (TX_REG_DESC_SIZE * tx_head);
>  
> - spin_lock_irq(&priv->txlock);
> + if (CIRC_SPACE(tx_head, tx_tail, TX_DESC_NUM) == 0) {
> + priv->stats.tx_dropped++;
> + goto out_unlock;
> + }

You can't do this.

Whatever code creates this condition _must_ stop the TX queue
so that the core netdevice transmit layer does not call your
transmit method.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RESEND 1/2] usb: ehci-exynos: Make provision for vdd regulators

[Krzysztof Kozlowski]

On 07.06.2015 22:20, Anand Moon wrote:
> Facilitate getting required 3.3V and 1.0V VDD supply for
> EHCI controller on Exynos.
> 
> With the patches for regulators' nodes merged in 3.15:
> c8c253f ARM: dts: Add regulator entries to smdk5420
> 275dcd2 ARM: dts: add max77686 pmic node for smdk5250,
> the exynos systems turn on only minimal number of regulators.
> 
> Until now, the VDD regulator supplies were either turned on
> by the bootloader, or the regulators were enabled by default
> in the kernel, so that the controller drivers did not need to
> care about turning on these regulators on their own.
> This was rather bad about these controller drivers.
> So ensuring now that the controller driver requests the necessary
> VDD regulators (if available, unless there are direct VDD rails),
> and enable them so as to make them working.
> 
> Signed-off-by: Vivek Gautam 
> Signed-off-by: Anand Moon 
> Cc: Jingoo Han 
> Cc: Alan Stern 
> ---
> Initial version of this patch was part of following series, though
> they are not dependent on each other, resubmitting after rebasing.
> 
> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-June/266418.html

So you just took Vivek's patch along with all the credits... That is not
how we usually do this.

I would expect that rebasing a patch won't change the author unless this
is fine with Vivek.

> ---
>  .../devicetree/bindings/usb/exynos-usb.txt |  2 +
>  drivers/usb/host/ehci-exynos.c | 55 
> +-
>  2 files changed, 56 insertions(+), 1 deletion(-)
> 
> diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt 
> b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> index 9b4dbe3..776fa03 100644
> --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt
> +++ b/Documentation/devicetree/bindings/usb/exynos-usb.txt
> @@ -23,6 +23,8 @@ Required properties:
>  Optional properties:
>   - samsung,vbus-gpio:  if present, specifies the GPIO that
> needs to be pulled up for the bus to be powered.
> + - vdd33-supply: handle to 3.3V Vdd supply regulator for the controller.
> + - vdd10-supply: handle to 1.0V Vdd supply regulator for the controller.
>  
>  Example:
>  
> diff --git a/drivers/usb/host/ehci-exynos.c b/drivers/usb/host/ehci-exynos.c
> index df538fd..4f8f9d2 100644
> --- a/drivers/usb/host/ehci-exynos.c
> +++ b/drivers/usb/host/ehci-exynos.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  
> @@ -45,6 +46,8 @@ static struct hc_driver __read_mostly exynos_ehci_hc_driver;
>  struct exynos_ehci_hcd {
>   struct clk *clk;
>   struct phy *phy[PHY_NUMBER];
> + struct regulator *vdd33;
> + struct regulator *vdd10;
>  };
>  
>  #define to_exynos_ehci(hcd) (struct exynos_ehci_hcd 
> *)(hcd_to_ehci(hcd)->priv)
> @@ -170,7 +173,27 @@ static int exynos_ehci_probe(struct platform_device 
> *pdev)
>  
>   err = exynos_ehci_get_phy(&pdev->dev, exynos_ehci);
>   if (err)
> - goto fail_clk;
> + goto fail_regulator1;
> +
> + exynos_ehci->vdd33 = devm_regulator_get_optional(&pdev->dev, "vdd33");
> + if (!IS_ERR(exynos_ehci->vdd33)) {
> + err = regulator_enable(exynos_ehci->vdd33);
> + if (err) {
> + dev_err(&pdev->dev,
> + "Failed to enable 3.3V Vdd supply\n");
> + goto fail_regulator1;
> + }
> + }
> +
> + exynos_ehci->vdd10 = devm_regulator_get_optional(&pdev->dev, "vdd10");
> + if (!IS_ERR(exynos_ehci->vdd10)) {
> + err = regulator_enable(exynos_ehci->vdd10);
> + if (err) {
> + dev_err(&pdev->dev,
> + "Failed to enable 1.0V Vdd supply\n");
> + goto fail_regulator2;
> + }
> + }
>  
>  skip_phy:
>  
> @@ -231,6 +254,10 @@ fail_add_hcd:
>  fail_io:
>   clk_disable_unprepare(exynos_ehci->clk);
>  fail_clk:
> + regulator_disable(exynos_ehci->vdd10);
> +fail_regulator2:
> + regulator_disable(exynos_ehci->vdd33);

if (!IS_ERR()).

> +fail_regulator1:
>   usb_put_hcd(hcd);
>   return err;
>  }
> @@ -246,6 +273,11 @@ static int exynos_ehci_remove(struct platform_device 
> *pdev)
>  
>   clk_disable_unprepare(exynos_ehci->clk);
>  
> + if (!IS_ERR(exynos_ehci->vdd33))
> + regulator_disable(exynos_ehci->vdd33);
> + if (!IS_ERR(exynos_ehci->vdd10))
> + regulator_disable(exynos_ehci->vdd10);
> +
>   usb_put_hcd(hcd);
>  
>   return 0;
> @@ -268,6 +300,11 @@ static int exynos_ehci_suspend(struct device *dev)
>  
>   clk_disable_unprepare(exynos_ehci->clk);
>  
> + if (!IS_ERR(exynos_ehci->vdd33))
> + regulator_disable(exynos_ehci->vdd33);
> + if (!IS_ERR(exynos_ehci->vdd10))
> + regulator_disable(exynos_ehci->vdd10);
> +


Is EHCI a wakeup source? If yes then how disabling regulators during
suspend affect

RE: [v3 24/26] KVM: Update Posted-Interrupts Descriptor when vCPU is blocked

[Wu, Feng]

> -Original Message-
> From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
> Sent: Saturday, June 06, 2015 5:59 AM
> To: Wu, Feng
> Cc: h...@zytor.com; t...@linutronix.de; mi...@redhat.com; x...@kernel.org;
> g...@kernel.org; pbonz...@redhat.com; dw...@infradead.org;
> j...@8bytes.org; alex.william...@redhat.com; jiang@linux.intel.com;
> eric.au...@linaro.org; linux-kernel@vger.kernel.org;
> io...@lists.linux-foundation.org; k...@vger.kernel.org
> Subject: Re: [v3 24/26] KVM: Update Posted-Interrupts Descriptor when vCPU
> is blocked
> 
> On Tue, Apr 14, 2015 at 07:37:44AM +, Wu, Feng wrote:
> >
> >
> > > -Original Message-
> > > From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
> > > Sent: Tuesday, March 31, 2015 7:56 AM
> > > To: Wu, Feng
> > > Cc: h...@zytor.com; t...@linutronix.de; mi...@redhat.com;
> x...@kernel.org;
> > > g...@kernel.org; pbonz...@redhat.com; dw...@infradead.org;
> > > j...@8bytes.org; alex.william...@redhat.com; jiang@linux.intel.com;
> > > eric.au...@linaro.org; linux-kernel@vger.kernel.org;
> > > io...@lists.linux-foundation.org; k...@vger.kernel.org
> > > Subject: Re: [v3 24/26] KVM: Update Posted-Interrupts Descriptor when
> vCPU
> > > is blocked
> > >
> > > On Mon, Mar 30, 2015 at 04:46:55AM +, Wu, Feng wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Marcelo Tosatti [mailto:mtosa...@redhat.com]
> > > > > Sent: Saturday, March 28, 2015 3:30 AM
> > > > > To: Wu, Feng
> > > > > Cc: h...@zytor.com; t...@linutronix.de; mi...@redhat.com;
> > > x...@kernel.org;
> > > > > g...@kernel.org; pbonz...@redhat.com; dw...@infradead.org;
> > > > > j...@8bytes.org; alex.william...@redhat.com;
> jiang@linux.intel.com;
> > > > > eric.au...@linaro.org; linux-kernel@vger.kernel.org;
> > > > > io...@lists.linux-foundation.org; k...@vger.kernel.org
> > > > > Subject: Re: [v3 24/26] KVM: Update Posted-Interrupts Descriptor when
> > > vCPU
> > > > > is blocked
> > > > >
> > > > > On Fri, Mar 27, 2015 at 06:34:14AM +, Wu, Feng wrote:
> > > > > > > > Currently, the following code is executed before 
> > > > > > > > local_irq_disable()
> is
> > > > > called,
> > > > > > > > so do you mean 1)moving local_irq_disable() to the place before 
> > > > > > > > it.
> 2)
> > > after
> > > > > > > interrupt
> > > > > > > > is disabled, set KVM_REQ_EVENT in case the ON bit is set?
> > > > > > >
> > > > > > > 2) after interrupt is disabled, set KVM_REQ_EVENT in case the ON
> bit
> > > > > > > is set.
> > > > > >
> > > > > > Here is my understanding about your comments here:
> > > > > > - Disable interrupts
> > > > > > - Check 'ON'
> > > > > > - Set KVM_REQ_EVENT if 'ON' is set
> > > > > >
> > > > > > Then we can put the above code inside " if
> > > > > (kvm_check_request(KVM_REQ_EVENT, vcpu) || req_int_win) "
> > > > > > just like it used to be. However, I still have some questions about 
> > > > > > this
> > > > > comment:
> > > > > >
> > > > > > 1. Where should I set KVM_REQ_EVENT? In function
> vcpu_enter_guest(),
> > > or
> > > > > other places?
> > > > >
> > > > > See below:
> > > > >
> > > > > > If in vcpu_enter_guest(), since currently local_irq_disable() is 
> > > > > > called
> after
> > > > > 'KVM_REQ_EVENT'
> > > > > > is checked, is it helpful to set KVM_REQ_EVENT after
> local_irq_disable() is
> > > > > called?
> > > > >
> > > > > local_irq_disable();
> > > > >
> > > > >   *** add code here ***
> > > >
> > > > So we need add code like the following here, right?
> > > >
> > > >   if ('ON' is set)
> > > >   kvm_make_request(KVM_REQ_EVENT, vcpu);
> > >
> >
> > Hi Marcelo,
> >
> > I changed the code as above, then I found that the ping latency was
> extremely big, (70ms - 400ms).
> > I digged into it and got the root cause. We cannot use "checking-on" as the
> judgment, since 'ON'
> > can be cleared by hypervisor software in lots of places. In this case,
> KVM_REQ_EVENT cannot be
> > set when we check 'ON' bit, hence the interrupts are not injected to the 
> > guest
> in time.
> >
> > Please refer to the following code, in which 'ON' bit can be cleared:
> >
> > apic_find_highest_irr () --> vmx_sync_pir_to_irr () --> 
> > pi_test_and_clear_on()
> >
> > Searching from the code step by step, apic_find_highest_irr() can be called 
> > by
> many other guys.
> >
> > Thanks,
> 
> Ok then, ignore my suggestion.
> 
> Can you resend the latest version please ?

Thanks for your review, I will send the new version soon.

Thanks,
Feng

> 

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

[PATCH] thermal: exynos: Disable the regulator on probe failure

[Krzysztof Kozlowski]

During probe the regulator (if present) was enabled but not disabled in
case of failure. So an unsuccessful probe lead to enabling the
regulator which was actually not needed because the device was not
enabled.

Additionally each deferred probe lead to increase of regulator enable
count so it would not be effectively disabled during removal of the
device.

Signed-off-by: Krzysztof Kozlowski 
Fixes: 498d22f616f6 ("thermal: exynos: Support for TMU regulator defined at 
device tree")
Cc: 

---

I am not entirely convinced that this should go to stable. Leaving a
regulator enabled in case of probe failure (no exynos TMU device) or
after deferred probe (regulator won't be disabled during device removal)
is not a critical issue, just leaks power.
---
 drivers/thermal/samsung/exynos_tmu.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/thermal/samsung/exynos_tmu.c 
b/drivers/thermal/samsung/exynos_tmu.c
index 531f4b179871..13c3aceed19d 100644
--- a/drivers/thermal/samsung/exynos_tmu.c
+++ b/drivers/thermal/samsung/exynos_tmu.c
@@ -1392,6 +1392,8 @@ err_clk_sec:
if (!IS_ERR(data->clk_sec))
clk_unprepare(data->clk_sec);
 err_sensor:
+   if (!IS_ERR_OR_NULL(data->regulator))
+   regulator_disable(data->regulator);
thermal_zone_of_sensor_unregister(&pdev->dev, data->tzd);
 
return ret;
-- 
1.9.1

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

Re: Re: [PATCH] extcon: max77843: Clear IRQ bits state before request IRQ

[MyungJoo Ham]

>   
>  On 06/05/2015 01:54 PM, MyungJoo Ham wrote:
> >>   
> >>  IRQ signal before driver probe is needless because driver sends
> >> current state after platform booting done.
> >> So, this patch clears MUIC IRQ bits before request IRQ.
> >>
> >> Signed-off-by: Jaewon Kim 
> >> ---
> >>  drivers/extcon/extcon-max77843.c |9 +
> >>  1 file changed, 9 insertions(+)
> > 
> > Q1. Is this because the pending bits are USELESS?
> > or because the pendeing bits incurs INCORRECT behaviors?
> 
> The max77843 datasheet includes following sentence:
> - "All bits are cleared after a read" about INT1/INT2/INT3 register.
> There are no problem about interrupt handling.
> 
> > 
> > Q2. Does clearing (by reading) INT1 do everything you need?
> > What about INT2 and INT3?
> 
> The MAXIM MAX77843 MUIC support the one more interrupts (e.g., ADC1K, VBVolt, 
> ChgTyp ...).
> The each interrupt is included in the one register among INT1/2/3.
> 
> This patch clear the all interrupts of MAX77843 before requesting the 
> interrupts.
> 
> > 
> > Q3. I presume that "driver sends current state after..." is
> > coming from the invokation of "queue_delayed_work()" at the end 
> > of the probe function. It appears that you are only serving
> > the pending status of "cable detection" with it while INT1
> > seems to have more functionalities. Does that delayed work
> > do everything that are pending, really?
> 
> When completed kernel booting, the delayed work of extcon-max77843.c driver
> use the MAX77843_MUIC_STATUSx register to detect the type of connected
> external connectors. So, there are no problme about clearing all bits of 
> INT1/2/3 interrupt register.
> 
> If user-space platform don't finish the initialization of all user-process 
> daemons
> and extcon driver send the uevent during only kernel booting, the uevent is 
> not handled
> on user-space daemons.
> 
> Thanks,
> Chanwoo Choi

Ok. Looks Good. Thanks for the explanation.

Acked-by: MyungJoo Ham 


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

Re: [PATCH v2] power: max17042_battery: add HEALTH and TEMP_* properties support

[Krzysztof Kozlowski]

2015-05-24 12:41 GMT+09:00 Ramakrishna Pallala :
> This patch adds the support for following battery properties
> to max17042 fuel gauge driver.
>
> POWER_SUPPLY_PROP_TEMP_ALERT_MIN
> POWER_SUPPLY_PROP_TEMP_ALERT_MAX
> POWER_SUPPLY_PROP_TEMP_MIN
> POWER_SUPPLY_PROP_TEMP_MAX
> POWER_SUPPLY_PROP_HEALTH

I wonder, have you tested the patch? After booting on Trats2 device
(max77693 which identifies itself as 17047-like) the values are:
POWER_SUPPLY_TEMP_ALERT_MIN=1280
POWER_SUPPLY_TEMP_ALERT_MAX=1270
POWER_SUPPLY_TEMP=257
This is okay, datasheet says that register after booting will have
value of 0x7f80.

However setting them to some value which should trigger interrupts
(like 300 for MIN or 200 for MAX) does not trigger the interrupt. I
added a printk in max17042_thread_handler().

Is the temperature alert feature working?

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

RE: [v9 0/9] Add VT-d Posted-Interrupts support - IOMMU part

[Wu, Feng]

> -Original Message-
> From: Joerg Roedel [mailto:j...@8bytes.org]
> Sent: Friday, June 05, 2015 9:34 PM
> To: Thomas Gleixner
> Cc: Wu, Feng; dw...@infradead.org; jiang@linux.intel.com;
> io...@lists.linux-foundation.org; linux-kernel@vger.kernel.org
> Subject: Re: [v9 0/9] Add VT-d Posted-Interrupts support - IOMMU part
> 
> On Fri, Jun 05, 2015 at 01:47:06PM +0200, Thomas Gleixner wrote:
> > On Fri, 5 Jun 2015, Feng Wu wrote:
> > > Divide the whole series which contain multiple components into three
> parts:
> > > - Prerequisite changes to irq subsystem (already merged in tip tree 
> > > x86/apic
> branch)
> > > - IOMMU part (in this series)
> >
> > Please add
> >
> > Reviewed-by: Thomas Gleixner 
> >
> > Which tree should this go through? It depends on tip/x86/apic AFAICT,
> > so we can take it through that, if Joerg provides his ACK.
> 
> Yeah, these changes depend on tip/x86/apic, so it doesn't make sense to
> send them through the iommu tree. There will be some conflicts when
> merging tip/x86/apic and the iommu tree together, though, mainly because
> of the vt-d kdump fixing patches I have in my tree. The conflicts are
> spread over 3 files, but not too serious and easy to resolve.
> 
> Anyway, you have my
> 
> Acked-by: Joerg Roedel 
> 
> for those.
> 

Hi Joerg,

Thanks for your ACK on this series!

Hi Thomas,

Thanks a lot for your review!

Do you need me to send another version which adds the reviewed-by and acked-by 
tags,
or you can do it yourself on this version and merge it to tip/x86/apic?

Thanks,
Feng

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

[PATCH 2/2] ARM: dts: Set max17047 over heat and over voltage thresholds

[Krzysztof Kozlowski]

Add some safe values for over head and over voltage. The Trats2 uses 3.8
V battery and during testing it operated properly under 4.48 V.

Signed-off-by: Krzysztof Kozlowski 
---
 arch/arm/boot/dts/exynos4412-trats2.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/boot/dts/exynos4412-trats2.dts 
b/arch/arm/boot/dts/exynos4412-trats2.dts
index 0b228ee14c64..8a87d39a28a0 100644
--- a/arch/arm/boot/dts/exynos4412-trats2.dts
+++ b/arch/arm/boot/dts/exynos4412-trats2.dts
@@ -595,6 +595,9 @@
interrupt-parent = <&gpx2>;
interrupts = <3 IRQ_TYPE_EDGE_FALLING>;
reg = <0x36>;
+
+   maxim,over-heat-temp = <700>;
+   maxim,over-volt = <4500>;
};
};
 
-- 
1.9.1

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

[PATCH 1/2] power_supply: max17042: Add OF support for setting thresholds

[Krzysztof Kozlowski]

The commit edd4ab055931 ("power: max17042_battery: add HEALTH and TEMP_*
properties support") added support for setting voltage and temperature
thresholds with platform data. For DeviceTree default of 0 was always
used.

This caused reporting battery health always as over voltage or
over heated.

Signed-off-by: Krzysztof Kozlowski 
Fixes: edd4ab055931 ("power: max17042_battery: add HEALTH and TEMP_* properties 
support")
---
 .../devicetree/bindings/power_supply/max17042_battery.txt   | 13 +
 drivers/power/max17042_battery.c|  9 +
 2 files changed, 22 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/power_supply/max17042_battery.txt 
b/Documentation/devicetree/bindings/power_supply/max17042_battery.txt
index 5bc9b685cf8a..3f3894aaeebc 100644
--- a/Documentation/devicetree/bindings/power_supply/max17042_battery.txt
+++ b/Documentation/devicetree/bindings/power_supply/max17042_battery.txt
@@ -9,10 +9,23 @@ Optional properties :
  (datasheet-recommended value is 1).
Defining this property enables current-sense functionality.
 
+Optional threshold properties :
+ If skipped the condition won't be reported.
+ - maxim,cold-temp :  Temperature threshold to report battery
+  as cold (in tenths of degree Celsius).
+ - maxim,over-heat-temp : Temperature threshold to report battery
+  as over heated (in tenths of degree Celsius).
+ - maxim,dead-volt :  Voltage threshold to report battery
+  as dead (in mV).
+ - maxim,over-volt :  Voltage threshold to report battery
+  as over voltage (in mV).
+
 Example:
 
battery-charger@36 {
compatible = "maxim,max17042";
reg = <0x36>;
maxim,rsns-microohm = <1>;
+   maxim,over-heat-temp = <600>;
+   maxim,over-volt = <4300>;
};
diff --git a/drivers/power/max17042_battery.c b/drivers/power/max17042_battery.c
index 62908eba2763..a8e16364c2aa 100644
--- a/drivers/power/max17042_battery.c
+++ b/drivers/power/max17042_battery.c
@@ -818,6 +818,15 @@ max17042_get_pdata(struct device *dev)
pdata->enable_current_sense = true;
}
 
+   if (of_property_read_s32(np, "maxim,cold-temp", &pdata->temp_min))
+   pdata->temp_min = INT_MIN;
+   if (of_property_read_s32(np, "maxim,over-heat-temp", &pdata->temp_max))
+   pdata->temp_max = INT_MAX;
+   if (of_property_read_s32(np, "maxim,dead-volt", &pdata->vmin))
+   pdata->vmin = INT_MIN;
+   if (of_property_read_s32(np, "maxim,over-volt", &pdata->vmax))
+   pdata->vmax = INT_MAX;
+
return pdata;
 }
 #else
-- 
1.9.1

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

[PATCH] power_supply: sysfs: Bring back write to writeable properties

[Krzysztof Kozlowski]

The fix for NULL pointer exception related to calling uevent for not
finished probe caused to set all writeable properties as non-writeable.
This was caused by checking if property is writeable before the initial
increase of power supply usage counter and in the same time using
wrapper over property_is_writeable(). The wrapper returns ENODEV if the
usage counter is still 0.

The call trace looked like:
  device probe:
power_supply_register()
  use_cnt = 0;
  device_add()
create sysfs entries
  power_supply_attr_is_visible()
power_supply_property_is_writeable()
  if (use_cnt == 0) return -ENODEV;
  use_cnt++;

Replace the usage of wrapper with direct call to property_is_writeable()
from driver. This should be safe call during device probe because
implementations of this callback just return 0/1 for different
properties and they do not access any of the driver's internal data.

Fixes: 8e59c7f23410 ("power_supply: Fix NULL pointer dereference during 
bq27x00_battery probe")
Signed-off-by: Krzysztof Kozlowski 
---
 drivers/power/power_supply_sysfs.c | 2 +-
 include/linux/power_supply.h   | 5 +
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/power/power_supply_sysfs.c 
b/drivers/power/power_supply_sysfs.c
index af026806cba5..ed2d7fd0c734 100644
--- a/drivers/power/power_supply_sysfs.c
+++ b/drivers/power/power_supply_sysfs.c
@@ -223,7 +223,7 @@ static umode_t power_supply_attr_is_visible(struct kobject 
*kobj,
 
if (property == attrno) {
if (psy->desc->property_is_writeable &&
-   power_supply_property_is_writeable(psy, property) > 
0)
+   psy->desc->property_is_writeable(psy, property) > 0)
mode |= S_IWUSR;
 
return mode;
diff --git a/include/linux/power_supply.h b/include/linux/power_supply.h
index a80f1fd01ddb..0395bcb18ddb 100644
--- a/include/linux/power_supply.h
+++ b/include/linux/power_supply.h
@@ -206,6 +206,11 @@ struct power_supply_desc {
int (*set_property)(struct power_supply *psy,
enum power_supply_property psp,
const union power_supply_propval *val);
+   /*
+* property_is_writeable() will be called during registration
+* of power supply. If this happens during device probe then it must
+* not access internal data of device (because probe did not end).
+*/
int (*property_is_writeable)(struct power_supply *psy,
 enum power_supply_property psp);
void (*external_power_changed)(struct power_supply *psy);
-- 
1.9.1

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

Re: [PATCH] EDAC, altera: wrap edac pm with a CONFIG_PM

[atull]

On Sat, 6 Jun 2015, Borislav Petkov wrote:

> On Fri, Jun 05, 2015 at 04:40:29PM -0500, Thor Thayer wrote:
> > Yes, in our case, it is a hardware issue but I'm still gathering
> > information.
> > 
> > The IRQ vectors for OCRAM reside on DDR and in Suspend-to-RAM mode we're
> > executing out of OCRAM. If an ECC error occurs, we can't handle it so it was
> > decided to make them mutually exclusive.
> 
> Thanks Thor,
> 
> that's actually a good-enough explanation for me - I was just making
> sure that it is not some silly EDAC core limitation preventing you guys
> from doing suspend.
> 
> Anyway, I've committed the version below, if you still feel you want to
> improve the explanation, no problem - it is the topmost patch on the
> branch and I can amend it easily.
> 

Thanks Boris.  That looks good.

Regards,
Alan


> ---
> From: Alan Tull 
> Date: Fri, 5 Jun 2015 08:49:15 -0500
> Subject: [PATCH] EDAC, altera: Do not allow suspend when EDAC is enabled
> 
> Suspend-to-RAM and EDAC support are mutually exclusive on SOCFPGA. If
> EDAC is enabled, it will prevent the platform from going into suspend.
> 
> The reason is that the IRQ vectors for OCRAM reside on DDR and in
> Suspend-to-RAM mode we're executing out of OCRAM. If an ECC error
> occurs, we can't handle it so it was decided to make them mutually
> exclusive.
> 
> Signed-off-by: Alan Tull 
> Signed-off-by: Dinh Nguyen 
> Cc: dinh.li...@gmail.com
> Cc: dougthomp...@xmission.com
> Cc: linux-edac 
> Cc: mche...@osg.samsung.com
> Cc: ttha...@opensource.altera.com
> Link: 
> http://lkml.kernel.org/r/1433512155-9906-1-git-send-email-dingu...@opensource.altera.com
> Signed-off-by: Borislav Petkov 
> ---
>  drivers/edac/altera_edac.c | 20 
>  1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/edac/altera_edac.c b/drivers/edac/altera_edac.c
> index 182c741adf3e..23ef0917483c 100644
> --- a/drivers/edac/altera_edac.c
> +++ b/drivers/edac/altera_edac.c
> @@ -477,11 +477,31 @@ static int altr_sdram_remove(struct platform_device 
> *pdev)
>   return 0;
>  }
>  
> +/*
> + * If you want to suspend, need to disable EDAC by removing it
> + * from the device tree or defconfig.
> + */
> +#ifdef CONFIG_PM
> +static int altr_sdram_prepare(struct device *dev)
> +{
> + pr_err("Suspend not allowed when EDAC is enabled.\n");
> +
> + return -EPERM;
> +}
> +
> +static const struct dev_pm_ops altr_sdram_pm_ops = {
> + .prepare = altr_sdram_prepare,
> +};
> +#endif
> +
>  static struct platform_driver altr_sdram_edac_driver = {
>   .probe = altr_sdram_probe,
>   .remove = altr_sdram_remove,
>   .driver = {
>   .name = "altr_sdram_edac",
> +#ifdef CONFIG_PM
> + .pm = &altr_sdram_pm_ops,
> +#endif
>   .of_match_table = altr_sdram_ctrl_of_match,
>   },
>  };
> -- 
> 2.3.5
> 
> -- 
> Regards/Gruss,
> Boris.
> 
> ECO tip #101: Trim your mails when you reply.
> --
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kernel/params.c: make use of unused but set variable

[Tejun Heo]

On Sun, Jun 07, 2015 at 05:17:20PM -0700, Linus Torvalds wrote:
> At most, it could be a "WARN_ON_ONCE()". Maybe even just silently
> ignore the error. But BUG_ON()? Hell no.

Yeah, WARN_ON_ONCE() is the right one.  The short history here is that
sysfs_create_file() has __must_check on it which triggered this whole
discussion.  The rationale for having __must_check on the function was
that the function's failure leads to userland visible behavior
difference and it's very inviting to skip error handling on the
function as file creation is often the last operation to be performed
with no further dependency on it.

Thanks.

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

[PATCH] kernel/params.c: make use of unused but set variable

[Louis Langholtz]

While Rusty Russell wants the return value of sysfs_create_file
ignored, it's annotated '__must_check'. Tejun Heo made the annotaion
and suggests just using BUG_ON(). Meanwhile the compiler warns that
the 'err' variable is set but unused. This patch uses Tejun's
suggestion. This eliminates the warning, satisfies the required check,
and fails-fast with notice if sysfs_create_file actually ever fails
(something that Rusty says should never happen when this code runs).

Signed-off-by: Louis Langholtz 
---

diff --git a/kernel/params.c b/kernel/params.c
index a22d6a7..b04a752 100644
--- a/kernel/params.c
+++ b/kernel/params.c
@@ -853,6 +853,7 @@ static void __init version_sysfs_builtin(void)
mk = locate_module_kobject(vattr->module_name);
if (mk) {
err = sysfs_create_file(&mk->kobj, &vattr->mattr.attr);
+   BUG_ON(err);
kobject_uevent(&mk->kobj, KOBJ_ADD);
kobject_put(&mk->kobj);
}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v2 2/2] staging: rtl8723au: core: remove redundant endianness conversion

[David Decotigny]

Source and destination have the same little-endian annotation: this
patch removes incorrect byte-swap on non-LE cpus.

This addresses the following sparse warning:
drivers/staging/rtl8723au/core/rtw_mlme_ext.c:3911:56: warning: incorrect type 
in argument 1 (different base types)
drivers/staging/rtl8723au/core/rtw_mlme_ext.c:3911:56:expected unsigned 
short [unsigned] [usertype] val
drivers/staging/rtl8723au/core/rtw_mlme_ext.c:3911:56:got restricted __le16 
[usertype] BA_timeout_value

Signed-off-by: David Decotigny 
---
 drivers/staging/rtl8723au/core/rtw_mlme_ext.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_mlme_ext.c 
b/drivers/staging/rtl8723au/core/rtw_mlme_ext.c
index 7c3b5dd..142f214 100644
--- a/drivers/staging/rtl8723au/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723au/core/rtw_mlme_ext.c
@@ -3906,8 +3906,8 @@ void issue_action_BA23a(struct rtw_adapter *padapter,
put_unaligned_le16(BA_para_set,
   &mgmt->u.action.u.addba_resp.capab);
 
-   put_unaligned_le16(pmlmeinfo->ADDBA_req.BA_timeout_value,
-  &mgmt->u.action.u.addba_resp.timeout);
+   mgmt->u.action.u.addba_resp.timeout
+   = pmlmeinfo->ADDBA_req.BA_timeout_value;
 
pattrib->pktlen += 8;
break;
-- 
2.2.0.rc0.207.ga3a616c

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

[PATCH v2 1/2] staging: rtl8723au: core: avoid bitwise arithmetic with forced endianness

[David Decotigny]

This fixes bitwise arithmetic performed on the host on a variable
previously converted to little-endian, and subsequently converted
again to little-endian:
  - issue_action_BA23a() called with "status" crafted in host byte order
  - "status" converted to LE
  - bitwise arithmetic on the (LE) "status", performed with masks and
shifts in host byte order
  - result converted to LE (again) and stored in device structure

Sparse warning addressed by this patch:
  drivers/staging/rtl8723au/core/rtw_mlme_ext.c:3806:16: warning: incorrect 
type in assignment (different base types)
  drivers/staging/rtl8723au/core/rtw_mlme_ext.c:3806:16:expected unsigned 
short [unsigned] status
  drivers/staging/rtl8723au/core/rtw_mlme_ext.c:3806:16:got restricted 
__le16 [usertype] 

Additional notes: initial cpu_to_le16 was introduced by kernel bulk
  commit 5e93f3520 "staging: r8723au: Add source files for new driver
  - part 1", initially from github according to commit description. On
  github, this traces back to another bulk commit: 2896bda04353 "Add
  new files in core directory", which is the 1st version of the
  driver.

Signed-off-by: David Decotigny 
---
 drivers/staging/rtl8723au/core/rtw_mlme_ext.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/staging/rtl8723au/core/rtw_mlme_ext.c 
b/drivers/staging/rtl8723au/core/rtw_mlme_ext.c
index 196beaf..7c3b5dd 100644
--- a/drivers/staging/rtl8723au/core/rtw_mlme_ext.c
+++ b/drivers/staging/rtl8723au/core/rtw_mlme_ext.c
@@ -3803,8 +3803,6 @@ void issue_action_BA23a(struct rtw_adapter *padapter,
 
pattrib->pktlen = sizeof(struct ieee80211_hdr_3addr) + 1;
 
-   status = cpu_to_le16(status);
-
switch (action) {
case WLAN_ACTION_ADDBA_REQ:
pattrib->pktlen += sizeof(mgmt->u.action.u.addba_req);
-- 
2.2.0.rc0.207.ga3a616c

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

[PATCH v2 0/2] staging: rtl8723au: core: endianness issues

[David Decotigny]

The code shows a couple inconsistencies (described in commit
descriptions) which would not be an issue on little-endian cpus, but
could cause breakage on non-LE cpus. Note: I could not test on real
hardware, these patches created based on sparse reports.

Hostory:
  - resending the same patches to correct recipients, only changed
commit descriptions (credits to Dan Carpenter)


# Patch Set Summary:

David Decotigny (2):
  staging: rtl8723au: core: avoid bitwise arithmetic with forced
endianness
  staging: rtl8723au: core: remove redundant endianness conversion

 drivers/staging/rtl8723au/core/rtw_mlme_ext.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

-- 
2.2.0.rc0.207.ga3a616c

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

Re: [PATCH v2 1/2] staging: rtl8723au: core: avoid bitwise arithmetic with forced endianness

[David Decotigny]

This was introduced by kernel bulk commit 5e93f3520 "staging: r8723au:
Add source files for new driver - part 1", initially from github
according to commit description. On github, this traces back to
another bulk commit: 2896bda04353 "Add new files in core directory",
which is the 1st version of the driver. Not sure where to find the
parent repos.

PS: sorry for the incorrect To/Cc, going to resend to more appropriate
recipients.

On Sun, Jun 7, 2015 at 4:20 AM, Dan Carpenter  wrote:
> You're CC'ing all the lustre people on this by mistake.
>
> Can we find which patch introduced this bug, and add a Fixes: tag and
> CC whoever introduced it?
>
> Please, resend with the correct CC list.
>
> regards,
> dan carpenter
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] drivers: of/base: move of_init to driver_init

[Rob Herring]

On Sun, Jun 7, 2015 at 2:05 AM, Grant Likely  wrote:
> On Tue, 19 May 2015 10:17:32 -0700
> , Greg Kroah-Hartman 
>  wrote:
>> On Tue, May 19, 2015 at 01:29:16PM +0100, Sudeep Holla wrote:
>> > Hi Rob/Greg,
>> >
>> > On 14/05/15 15:28, Sudeep Holla wrote:
>> > >Commit 5590f3196b29 ("drivers/core/of: Add symlink to device-tree from
>> > >devices with an OF node") adds the symlink `of_node` for each device
>> > >pointing to it's device tree node while creating/initialising it.
>> > >
>> > >However the devicetree sysfs is created and setup in of_init which is
>> > >executed at core_initcall level. For all the devices created before
>> > >of_init, the following error is thrown:
>> > >   "Error -2(-ENOENT) creating of_node link"
>> > >
>> > >Like many other components in driver model, initialize the sysfs support
>> > >for OF/devicetree from driver_init so that it's ready before any devices
>> > >are created.
>> > >
>> > >Fixes: 5590f3196b29 ("drivers/core/of: Add symlink to device-tree from
>> > >   devices with an OF node")
>> > >Suggested-by: Rob Herring 
>> > >Cc: Grant Likely 
>> > >Cc: Rob Herring 
>> > >Cc: Pawel Moll 
>> > >Cc: Benjamin Herrenschmidt 
>> > >Cc: Greg Kroah-Hartman 
>> > >Signed-off-by: Sudeep Holla 
>> >
>> > I assume one of you will pick this up if there are no further comments ?
>>
>> I will once things settle down...
>
> I've picked it up. Yell if you'd prefer to take it by your tree.

Greg already applied it. It just hit Linus' tree Sat.

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

Re: [PATCH] kernel/params.c: make use of unused but set variable

[Linus Torvalds]

On Sun, Jun 7, 2015 at 5:00 PM, Tejun Heo  wrote:
> On Sun, Jun 07, 2015 at 05:54:30PM -0600, Louis Langholtz wrote:
>> @@ -853,6 +853,7 @@ static void __init version_sysfs_builtin(void)
>>   mk = locate_module_kobject(vattr->module_name);
>>   if (mk) {
>>   err = sysfs_create_file(&mk->kobj, &vattr->mattr.attr);
>> + BUG_ON(err);
>
> Maybe BUG_ON(sysfs_create_file(...)); is simpler?  Other than that,

Hell no.

Stop with the random BUG_ON() additions.

I have said this before, and apparently I need to sat this again, and
probably I will have to say it in the future.

We don't add BUG_ON's for random reasons.

The *ONLY* acceptable reason for a BUG_ON() is if the machine is dead
anyway because of some major internal corruption.

We have too many BUG_ON's. We've had people add BUG_ON's because "this
cannot happen", and then it turns out they were wrong, and they just
killed the machine.

Dammit, there's no reason to add a BUG_ON() here in the first place,
and the reason of "but but it's an unused error return": is f*cking
retarded.

Stop this idiocy. We don't write crap code just to satisfy some random
coding standard or shut up a compiler error.

At most, it could be a "WARN_ON_ONCE()". Maybe even just silently
ignore the error. But BUG_ON()? Hell no.

NO NO NO.

Quite frankly, if you want to add error handling, then dammit, add it
right. And no, BUG_ON() is _never_ proper error handling.

BUG_ON() is for things like "uhhuh, somebody is trying to free a page
that is already free". That is some serious internal corruption.

BUG_ON() is _not_ for "I'm not doing any error handling, so I'll
sprinkle random lines of BUG_ON() like fairy dust to make the compiler
happen".

Really.  I'm getting very tired indeed of people adding BUG_ON's like
that. Stop it.

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

Re: [PATCH] kernel/params.c: make use of unused but set variable

[Tejun Heo]

On Sun, Jun 07, 2015 at 05:54:30PM -0600, Louis Langholtz wrote:
> While Rusty Russell wants the return value of sysfs_create_file
> ignored, it's annotated '__must_check'. Tejun Heo made the annotaion
> and suggests just using BUG_ON(). Meanwhile the compiler warns that
> the 'err' variable is set but unused. This patch uses Tejun's
> suggestion. This eliminates the warning, satisfies the required check,
> and fails-fast with notice if sysfs_create_file actually ever fails
> (something that Rusty says should never happen when this code runs).
> 
> Signed-off-by: Louis Langholtz 
> ---
> 
> diff --git a/kernel/params.c b/kernel/params.c
> index a22d6a7..b04a752 100644
> --- a/kernel/params.c
> +++ b/kernel/params.c
> @@ -853,6 +853,7 @@ static void __init version_sysfs_builtin(void)
>   mk = locate_module_kobject(vattr->module_name);
>   if (mk) {
>   err = sysfs_create_file(&mk->kobj, &vattr->mattr.attr);
> + BUG_ON(err);

Maybe BUG_ON(sysfs_create_file(...)); is simpler?  Other than that,

 Acked-by: Tejun Heo 

Thanks.

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

[PATCH] usbtouchscreen: adds support for inverting X or Y axis (or both)

[Philippe Coval]

Invert Y is needed (together with swap XY) for some touchscreens :
- LeadingTouch screens (at least for some of them)
- cartft 8in4 (USB ID=0eef:0001)

Signed-off-by: Ondrej Zary 
Bug-Link: https://bugs.tizen.org/jira/browse/TC-2522
Cc: linux-in...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Philippe Coval 
---
 drivers/input/touchscreen/usbtouchscreen.c | 23 +++
 1 file changed, 19 insertions(+), 4 deletions(-)

diff --git a/drivers/input/touchscreen/usbtouchscreen.c 
b/drivers/input/touchscreen/usbtouchscreen.c
index f2c6c35..af7e6f3 100644
--- a/drivers/input/touchscreen/usbtouchscreen.c
+++ b/drivers/input/touchscreen/usbtouchscreen.c
@@ -63,6 +63,12 @@
 static bool swap_xy;
 module_param(swap_xy, bool, 0644);
 MODULE_PARM_DESC(swap_xy, "If set X and Y axes are swapped.");
+static int invert_x;
+module_param(invert_x, bool, 0644);
+MODULE_PARM_DESC(invert_x, "Invert X axis.");
+static int invert_y;
+module_param(invert_y, bool, 0644);
+MODULE_PARM_DESC(invert_y, "Invert Y axis.");
 
 static bool hwcalib_xy;
 module_param(hwcalib_xy, bool, 0644);
@@ -1303,6 +1309,7 @@ static void usbtouch_process_pkt(struct usbtouch_usb 
*usbtouch,
  unsigned char *pkt, int len)
 {
struct usbtouch_device_info *type = usbtouch->type;
+   int x, y;
 
if (!type->read_data(usbtouch, pkt))
return;
@@ -1310,12 +1317,20 @@ static void usbtouch_process_pkt(struct usbtouch_usb 
*usbtouch,
input_report_key(usbtouch->input, BTN_TOUCH, usbtouch->touch);
 
if (swap_xy) {
-   input_report_abs(usbtouch->input, ABS_X, usbtouch->y);
-   input_report_abs(usbtouch->input, ABS_Y, usbtouch->x);
+   x = usbtouch->y;
+   y = usbtouch->x;
} else {
-   input_report_abs(usbtouch->input, ABS_X, usbtouch->x);
-   input_report_abs(usbtouch->input, ABS_Y, usbtouch->y);
+   x = usbtouch->x;
+   y = usbtouch->y;
}
+   if (invert_x)
+   x = type->max_xc - x + type->min_xc;
+   if (invert_y)
+   y = type->max_yc - y + type->min_yc;
+
+   input_report_abs(usbtouch->input, ABS_X, x);
+   input_report_abs(usbtouch->input, ABS_Y, y);
+
if (type->max_press)
input_report_abs(usbtouch->input, ABS_PRESSURE, 
usbtouch->press);
input_sync(usbtouch->input);
-- 
2.1.4

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

Re: [PATCH 08/14] hrtimer: Allow hrtimer::function() to free the timer

[Oleg Nesterov]

On 06/08, Oleg Nesterov wrote:
>
> And I simply can not understand the complication in hrtimer_active(),
> please help!

Sorry for another off-topic email, but I don't even understand the
usage of hrtimer_active().

Say, do_nanosleep()

hrtimer_start_expires(&t->timer, mode);
if (!hrtimer_active(&t->timer))
t->task = NULL;

why? Assuming that hrtimer_active() is correct, it can only return
false if t->task was already cleared by hrtimer_wakeup().


OTOH. perf_cpu_hrtimer_restart() does

if (hrtimer_active(hr))
return;

if (!hrtimer_callback_running(hr))
__hrtimer_start_range_ns(...);

why it can't simply do

if (!hrtimer_active(hr)) // implies !hrtimer_callback_running()
__hrtimer_start_range_ns(...);


Confused.

Oleg.

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

Re: [PATCH 08/14] hrtimer: Allow hrtimer::function() to free the timer

[Oleg Nesterov]

Not sure I read this patch correctly, it doesn't apply to Linus's tree.

And I simply can not understand the complication in hrtimer_active(),
please help!

On 06/05, Peter Zijlstra wrote:
>
> +bool hrtimer_active(const struct hrtimer *timer)
> +{
> + struct hrtimer_cpu_base *cpu_base;
> + unsigned int seq;
> + bool active;
> +
> + do {
> + active = false;
> + cpu_base = READ_ONCE(timer->base->cpu_base);
> + seq = raw_read_seqcount(&cpu_base->seq);
> +
> + if (timer->state != HRTIMER_STATE_INACTIVE ||
> + cpu_base->running == timer)
> + active = true;

Why we can't simply return true in this case?

Unless you lock this timer, hrtimer_active() is inherently racy anyway.
Granted, it must not wrongly return False if the timer is pending or
running.

But "false positive" does not differ from the case when (say) the
running timer->function() finishes right after hrtimer_active() returns
True.

> + } while (read_seqcount_retry(&cpu_base->seq, seq) ||
> +  cpu_base != READ_ONCE(timer->base->cpu_base));

Why do we need to re-check >cpu_base?

I think we can ignore migrate_hrtimer_list(), it doesn't clear ->state.

Otherwise the timer can change its ->base only if it is not running and
inactive, and again I think we should only eliminate the false negative
return.

And I think there is a problem. Consider a timer TIMER which always
rearms itself using some "default" timeout.

In this case __hrtimer_start_range_ns(&TIMER, ...) must preserve
hrtimer_active(&TIMER) == T. By definition, and currently this is
true.

After this patch this is no longer true (afaics). If the timer is
pending but not running, __hrtimer_start_range_ns()->remove_hrtimer()
will clear ENQUEUED first, then set it again in enqueue_hrtimer().

This means that hrtimer_active() returns false in between. And note
that it doesn't matter if the timer changes its ->base or not, so
that 2nd cpu_base above can't help.

I think that __hrtimer_start_range_ns() should preserve ENQUEUED
like migrate_hrtimer_list() should do (see the previous email).


Finally. Suppose that timer->function() returns HRTIMER_RESTART
and hrtimer_active() is called right after __run_hrtimer() sets
cpu_base->running = NULL. I can't understand why hrtimer_active()
can't miss ENQUEUED in this case. We have wmb() in between, yes,
but then hrtimer_active() should do something like

active = cpu_base->running == timer;
if (!active) {
rmb();
active = state != HRTIMER_STATE_INACTIVE;
}

No?

But I am already sleeping and probably totally confused.

Oleg.

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

Re: [PATCH] net: ll_temac: Remove sparse warnings

[David Miller]

From: Michal Simek 
Date: Fri,  5 Jun 2015 10:49:17 +0200

> Remove sparse warnings:
> drivers/net/ethernet/xilinx/ll_temac_main.c:65:16: warning: cast removes
> address space of expression
> drivers/net/ethernet/xilinx/ll_temac_main.c:70:9: warning: cast removes
> address space of expression
> drivers/net/ethernet/xilinx/ll_temac_main.c:127:16: warning: cast
> removes address space of expression
> drivers/net/ethernet/xilinx/ll_temac_main.c:137:9: warning: cast removes
> address space of expression
> drivers/net/ethernet/xilinx/ll_temac_main.c:409:3: warning: symbol
> 'temac_options' was not declared. Should it be static?
> drivers/net/ethernet/xilinx/ll_temac_main.c:590:6: warning: symbol
> 'temac_adjust_link' was not declared. Should it be static?
> 
> Signed-off-by: Michal Simek 

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

Re: metag test failure in -next due to commit 'module: relocate module_init from init.h to module.h'

[Paul Gortmaker]

[Re: metag test failure in -next due to commit 'module: relocate module_init 
from init.h to module.h'] On 05/06/2015 (Fri 17:39) Guenter Roeck wrote:

> On 06/05/2015 02:39 PM, James Hogan wrote:
> [ ... ]
> >
> > From e12856c559d7dff2ad4f6497996610e12e7c7e2d Mon Sep 17 00:00:00 2001
> >From: James Hogan 
> >Date: Fri, 5 Jun 2015 22:17:18 +0100
> >Subject: [PATCH] tty/metag_da: Avoid module_init/module_exit
> >MIME-Version: 1.0
> >Content-Type: text/plain; charset=UTF-8
> >Content-Transfer-Encoding: 8bit
> >
> >The metag_da TTY driver can't get built as a module at the moment, but
> >it still uses module_init() and module_exit(). Those macros are moving
> >to module.h which isn't included by metag_da.c, which will result in the
> >following build warnings (remarkably no build errors) and an apparent
> >failure to boot as the TTY driver won't be loaded.
> >
> >drivers/tty/metag_da.c:660: warning: data definition has no type or storage 
> >class
> >drivers/tty/metag_da.c:660: warning: type defaults to ‘int’ in declaration 
> >of ‘module_init’
> >drivers/tty/metag_da.c:660: warning: parameter names (without types) in 
> >function declaration
> >drivers/tty/metag_da.c:661: warning: data definition has no type or storage 
> >class
> >drivers/tty/metag_da.c:661: warning: type defaults to ‘int’ in declaration 
> >of ‘module_exit’
> >drivers/tty/metag_da.c:661: warning: parameter names (without types) in 
> >function declaration
> >drivers/tty/metag_da.c:572: warning: ‘dashtty_init’ defined but not used
> >drivers/tty/metag_da.c:645: warning: ‘dashtty_exit’ defined but not used
> >drivers/tty/metag_da.c In function ‘dash_console_write’:
> >drivers/tty/metag_da.c:670 : warning: passing argument 4 of ‘chancall’ 
> >discards qualifiers from pointer target type
> >
> >Instead of just adding the module.h include, now would be a good time to
> >remove the use of these macros, replacing the module_init with
> >device_initcall, and removing the exit function altogether since it
> >isn't needed. If module support is added later the code can always be
> >resurrected.
> >
> >Reported-by: Guenter Roeck 
> >Signed-off-by: James Hogan 
> >Cc: Greg Kroah-Hartman 
> >Cc: Jiri Slaby 
> >Cc: Paul Gortmaker 
> >Cc: linux-me...@vger.kernel.org
> 
> Yes, that does the trick.
> 
> Tested-by: Guenter Roeck 

Thanks guys, I'll add that to the module_init-device_initcall conversion
branch, which will put it ahead of the code relocation commit.

I think most other arch run with -Werror-implicit (or whatever it is) so
that these kinds of things would not "leak" past into a silent boot
fail like this.

Paul.
--

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

Re: lustre: question about lov_request.c

[Julia Lawall]

On Sun, 7 Jun 2015, Drokin, Oleg wrote:

> Hello!
> 
>   You are right, set_pga seems to be a dead member. It was alive a once, but 
> somehow not fully removed now,
>   so it's safe to drop the whole if and also the struct member itself.
>   set_oabufs could be dropped as well.

Thanks. I will do that.

julia

> 
>   Thanks.
> 
> Bye,
> Oleg
> On Jun 7, 2015, at 4:11 PM, Julia Lawall wrote:
> 
> > Hello,
> > 
> > The function lov_finish_set in 
> > drivers/staging/lustre/lustre/lov/lov_request.c contains the code:
> > 
> >   if (set->set_pga) {
> >int len = set->set_oabufs * sizeof(*set->set_pga);
> >OBD_FREE_LARGE(set->set_pga, len);
> >}
> > 
> > If I change the call to OBD_FREE_LARGE to kvfree, then len is not useful 
> > any more.  But actually, at least with grep, I can't find anywhere that 
> > either the set_pga field or the set_oabufs field is set.  Am I missing 
> > something, or can the whole if be removed?  Can these two fields go too?
> > 
> > thanks,
> > julia
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: lustre: question about lov_request.c

[Drokin, Oleg]

Hello!

  You are right, set_pga seems to be a dead member. It was alive a once, but 
somehow not fully removed now,
  so it's safe to drop the whole if and also the struct member itself.
  set_oabufs could be dropped as well.

  Thanks.

Bye,
Oleg
On Jun 7, 2015, at 4:11 PM, Julia Lawall wrote:

> Hello,
> 
> The function lov_finish_set in 
> drivers/staging/lustre/lustre/lov/lov_request.c contains the code:
> 
>   if (set->set_pga) {
>int len = set->set_oabufs * sizeof(*set->set_pga);
>OBD_FREE_LARGE(set->set_pga, len);
>}
> 
> If I change the call to OBD_FREE_LARGE to kvfree, then len is not useful 
> any more.  But actually, at least with grep, I can't find anywhere that 
> either the set_pga field or the set_oabufs field is set.  Am I missing 
> something, or can the whole if be removed?  Can these two fields go too?
> 
> thanks,
> julia

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

lustre: question about lov_request.c

[Julia Lawall]

Hello,

The function lov_finish_set in 
drivers/staging/lustre/lustre/lov/lov_request.c contains the code:

   if (set->set_pga) {
int len = set->set_oabufs * sizeof(*set->set_pga);
OBD_FREE_LARGE(set->set_pga, len);
}

If I change the call to OBD_FREE_LARGE to kvfree, then len is not useful 
any more.  But actually, at least with grep, I can't find anywhere that 
either the set_pga field or the set_oabufs field is set.  Am I missing 
something, or can the whole if be removed?  Can these two fields go too?

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

[PATCH] dmaengine: fsl-edma: clear pending interrupts on initialization

[Stefan Agner]

Clear pending interrupts before requesting interrupts and move
interrupt initialization after channels have been initialized.
This avoids a NULL pointer dereference panic when using kexec
while DMA requests were running.

Signed-off-by: Stefan Agner 
---
 drivers/dma/fsl-edma.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/dma/fsl-edma.c b/drivers/dma/fsl-edma.c
index 09e2842..915eec3 100644
--- a/drivers/dma/fsl-edma.c
+++ b/drivers/dma/fsl-edma.c
@@ -881,10 +881,6 @@ static int fsl_edma_probe(struct platform_device *pdev)
 
}
 
-   ret = fsl_edma_irq_init(pdev, fsl_edma);
-   if (ret)
-   return ret;
-
fsl_edma->big_endian = of_property_read_bool(np, "big-endian");
 
INIT_LIST_HEAD(&fsl_edma->dma_dev.channels);
@@ -900,6 +896,11 @@ static int fsl_edma_probe(struct platform_device *pdev)
fsl_edma_chan_mux(fsl_chan, 0, false);
}
 
+   edma_writel(fsl_edma, ~0, fsl_edma->membase + EDMA_INTR);
+   ret = fsl_edma_irq_init(pdev, fsl_edma);
+   if (ret)
+   return ret;
+
dma_cap_set(DMA_PRIVATE, fsl_edma->dma_dev.cap_mask);
dma_cap_set(DMA_SLAVE, fsl_edma->dma_dev.cap_mask);
dma_cap_set(DMA_CYCLIC, fsl_edma->dma_dev.cap_mask);
-- 
2.4.2

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

Re: [PATCH RESEND 0/2] dmaengine: make transfers reusable

[Robert Jarzmik]

Robert Jarzmik  writes:

> Hi Vinod and Maxime,
>
> This very same patch was already submitted in [1]. It enables the reuse of
> transfers through their lifetime. I added to this serie the documentation 
> patch
> Maxime has been commenting, as it is tighly linked.
>
> The "RESEND" is a bit zealous as the documentation patch was fixed according 
> to
> Maxime's first 2 comments.
>
> Cheers.
>
> --
> Robert
>
> [1] https://lkml.org/lkml/2015/3/21/230
>
> Robert Jarzmik (2):
>   dmaengine: virt-dma: don't always free descriptor upon completion
>   Documentation: dmaengine: document DMA_CTRL_ACK
>
>  Documentation/dmaengine/provider.txt | 11 ++-
>  drivers/dma/virt-dma.c   | 19 +--
>  drivers/dma/virt-dma.h   | 13 -
>  3 files changed, 31 insertions(+), 12 deletions(-)

Hi Vinod,

Could I get your impressions on this serie ?

Cheers.

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

Re: [PATCH 08/14] hrtimer: Allow hrtimer::function() to free the timer

[Oleg Nesterov]

On 06/05, Peter Zijlstra wrote:
>
>  #define HRTIMER_STATE_INACTIVE   0x00
>  #define HRTIMER_STATE_ENQUEUED   0x01
> -#define HRTIMER_STATE_CALLBACK   0x02
> -#define HRTIMER_STATE_MIGRATE0x04
> +#define HRTIMER_STATE_MIGRATE0x02

Slightly pff-topic, but I do not understand HRTIMER_STATE_MIGRATE
with or without this change. Unless I am totally confused it looks
buggy and simply unneeded.

migrate_hrtimer_list() sets it to keep hrtimer_active() == T, but
this is not enough: this can fool, say, hrtimer_is_queued() in
dequeue_signal().

Can't migrate_hrtimer_list() simply use HRTIMER_STATE_ENQUEUED?
This fixes the race and we can kill STATE_MIGRATE.

Oleg.


--- x/include/linux/hrtimer.h
+++ x/include/linux/hrtimer.h
@@ -70,17 +70,13 @@ enum hrtimer_restart {
  * the handling of the timer.
  *
  * The HRTIMER_STATE_ENQUEUED bit is always or'ed to the current state
- * to preserve the HRTIMER_STATE_CALLBACK in the above scenario. This
- * also affects HRTIMER_STATE_MIGRATE where the preservation is not
- * necessary. HRTIMER_STATE_MIGRATE is cleared after the timer is
- * enqueued on the new cpu.
+ * to preserve the HRTIMER_STATE_CALLBACK in the above scenario.
  *
  * All state transitions are protected by cpu_base->lock.
  */
 #define HRTIMER_STATE_INACTIVE 0x00
 #define HRTIMER_STATE_ENQUEUED 0x01
 #define HRTIMER_STATE_CALLBACK 0x02
-#define HRTIMER_STATE_MIGRATE  0x04
 
 /**
  * struct hrtimer - the basic hrtimer structure
--- x/kernel/time/hrtimer.c
+++ x/kernel/time/hrtimer.c
@@ -1642,11 +1642,11 @@ static void migrate_hrtimer_list(struct 
debug_deactivate(timer);
 
/*
-* Mark it as STATE_MIGRATE not INACTIVE otherwise the
+* Mark it as ENQUEUED not INACTIVE otherwise the
 * timer could be seen as !active and just vanish away
 * under us on another CPU
 */
-   __remove_hrtimer(timer, old_base, HRTIMER_STATE_MIGRATE, 0);
+   __remove_hrtimer(timer, old_base, HRTIMER_STATE_ENQUEUED, 0);
timer->base = new_base;
/*
 * Enqueue the timers on the new cpu. This does not
@@ -1657,9 +1657,6 @@ static void migrate_hrtimer_list(struct 
 * event device.
 */
enqueue_hrtimer(timer, new_base);
-
-   /* Clear the migration state bit */
-   timer->state &= ~HRTIMER_STATE_MIGRATE;
}
 }
 

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

Re: [PATCH 06/11] staging: rtl8192e: Remove dead code: rtl_dm.[ch]

[Mateusz Kulikowski]

On 04.06.2015 15:52, Dan Carpenter wrote:
> On Tue, Jun 02, 2015 at 10:48:10PM +0200, Mateusz Kulikowski wrote:
>> - Remove unused fields in dig_t structures. Some of them were only
>>   initialized and never accessed.
>> - Remove unused enums/macros/defines in rtl_dm.h
>> - Remove duplicated function declarations
>> - Remove unused dm_change_dynamic_initgain_thresh() function
>> - Remove unused dm_shadow_init() function
> 
> Could you delete dm_shadow[] in a follow on patch.
Will do in v2

> 
> How I review these sorts of patches is that:
> 1) Ignore deleted variables.  If those are used then it will cause a
>compile problem so I don't worry about it.
> 
> 2) Verify that when we delete initialization, then we also delete the
>variable.  In this case we deleted the initialization of dm_shadow[]
>but not the variable itself, so I wondered if we were using
>unitialized data.  It turns out that it was just an oversight.
> 
> Reviewing these means a lot of searching, for each variable.  Next time
> if the patch were split up more it would make it a bit easier.

Ok; I assume this applies for next series, not v2.


Regards,
Mateusz

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

Re: [PATCH 07/11] staging: rtl8192e: Remove dead code: dig_t::dbg_mode

[Mateusz Kulikowski]

On 04.06.2015 08:06, Sudip Mukherjee wrote:
> On Thu, Jun 04, 2015 at 07:50:07AM +0200, Mateusz Kulikowski wrote:
>> On 04.06.2015 07:18, Sudip Mukherjee wrote:
>>> On Wed, Jun 03, 2015 at 08:21:02PM +0200, Mateusz Kulikowski wrote:
 On 03.06.2015 09:26, Sudip Mukherjee wrote:
> On Tue, Jun 02, 2015 at 10:48:11PM +0200, Mateusz Kulikowski wrote:

 No, I missed that - this one should also be removed - probably because of 
 similar naming (DbgMode, dbg_mode).
 Thanks for finding it - I'll fix that in v2.

 Apart from that - did you had time/courage to analyze rest of the patches 
 (so I can send v2)?
>>>
>>> at a first glance looked ok to me. I hope you have checked it on the
>>> hardware as well. but maybe Dan can find something.
>>> better send v2.
>>
>> Of course I have checked it, although - as I wrote in past - this driver has 
>> not very good performance.
> is there any other driver which has better performance on this hardware
> than this driver? and how are you measuring the performance?

What I meant is that this driver (at least on my HW/SW configuration) is not 
very reliable.

It drops a lot of packages and transmission speed is far from declared.
But - as far as I checked - it's not due to my changes (I checked that some 
time ago).

Perhaps my hardware has some issues - I have to buy another rtl8192e card 
and/or test on Windows 
to be sure (will do both steps probably).

As for measurement, I have simple tests on my home network (WPA2/CCMP):
- Scan available networks
- Download 1MB file, check md5
- Ping router/gateway

Regards,
Mateusz

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

Re: [PATCH v5 2/2] ARM: dts: add property for maximum ADC clock frequencies

[Stefan Agner]

On 2015-06-07 18:56, Jonathan Cameron wrote:
> On 27/05/15 13:47, Stefan Agner wrote:
>> The ADC clock frequency is limited depending on modes used. Add
>> device tree property which allow to set the mode used and the
>> maximum frequency ratings for the instance. These allows to
>> set the ADC clock to a frequency which is within specification
>> according to the actual mode used.
>>
>> Acked-by: Fugang Duan 
>> Signed-off-by: Stefan Agner 
> I'm happy to take this via IIO if people want me to, otherwise give
> it's connection to the previous patch that I just applied,

I guess the chances for conflicts are rather small. I don't have any
preferences, Shawn?

--
Stefan

> 
> Acked-by: Jonathan Cameron 
> 
>> ---
>>  arch/arm/boot/dts/vfxxx.dtsi | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/vfxxx.dtsi b/arch/arm/boot/dts/vfxxx.dtsi
>> index a29c7ce..c6609bd 100644
>> --- a/arch/arm/boot/dts/vfxxx.dtsi
>> +++ b/arch/arm/boot/dts/vfxxx.dtsi
>> @@ -189,6 +189,8 @@
>>  clocks = <&clks VF610_CLK_ADC0>;
>>  clock-names = "adc";
>>  status = "disabled";
>> +fsl,adck-max-frequency = <3000>, <4000>,
>> +<2000>;
>>  };
>>
>>  wdoga5: wdog@4003e000 {
>> @@ -387,6 +389,8 @@
>>  clocks = <&clks VF610_CLK_ADC1>;
>>  clock-names = "adc";
>>  status = "disabled";
>> +fsl,adck-max-frequency = <3000>, <4000>,
>> +<2000>;
>>  };
>>
>>  esdhc1: esdhc@400b2000 {
>>

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