Re: [PATCH 1/2] staging: dgnc: fix 'line over 80 characters'

2016-03-24 Thread Joe Perches
On Fri, 2016-03-25 at 14:42 +0900, DaeSeok Youn wrote:
> 2016-03-25 12:19 GMT+09:00 Joe Perches :
> > On Fri, 2016-03-25 at 11:44 +0900, Daeseok Youn wrote:
> > > fix checkpatch.pl warning about 'line over 80 characters'
> > > in dgnc_neo.c
[]
> > > diff --git a/drivers/staging/dgnc/dgnc_neo.c 
> > > b/drivers/staging/dgnc/dgnc_neo.c
[]
> > > @@ -116,7 +117,8 @@ static inline void neo_set_cts_flow_control(struct 
> > > channel_t *ch)
> > >   writeb(efr, >ch_neo_uart->efr);
> > > 
> > >   /* Turn on table D, with 8 char hi/low watermarks */
> > > - writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY), 
> > > >ch_neo_uart->fctr);
> > > + writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY),
> > > + >ch_neo_uart->fctr);
> > You could remove parentheses here around the CONST | CONST
> OK. I got it. but it also, I will send a patch after fixing this, not
> in this, right?

Right.



Re: [PATCH 1/2] staging: dgnc: fix 'line over 80 characters'

2016-03-24 Thread Joe Perches
On Fri, 2016-03-25 at 14:42 +0900, DaeSeok Youn wrote:
> 2016-03-25 12:19 GMT+09:00 Joe Perches :
> > On Fri, 2016-03-25 at 11:44 +0900, Daeseok Youn wrote:
> > > fix checkpatch.pl warning about 'line over 80 characters'
> > > in dgnc_neo.c
[]
> > > diff --git a/drivers/staging/dgnc/dgnc_neo.c 
> > > b/drivers/staging/dgnc/dgnc_neo.c
[]
> > > @@ -116,7 +117,8 @@ static inline void neo_set_cts_flow_control(struct 
> > > channel_t *ch)
> > >   writeb(efr, >ch_neo_uart->efr);
> > > 
> > >   /* Turn on table D, with 8 char hi/low watermarks */
> > > - writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY), 
> > > >ch_neo_uart->fctr);
> > > + writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY),
> > > + >ch_neo_uart->fctr);
> > You could remove parentheses here around the CONST | CONST
> OK. I got it. but it also, I will send a patch after fixing this, not
> in this, right?

Right.



Re: [PATCH] ARM: dts: exynos: Fix invalid maximum voltage for buck9 supplying SD card

2016-03-24 Thread Javier Martinez Canillas
Hello Krzysztof,

On 03/24/2016 05:12 AM, Krzysztof Kozlowski wrote:
> The buck9 regulator of S2MPS11 PMIC had incorrect maximum voltage -
> lower by 5 mV than specified by datasheet. This buck9 provides power to
> other regulators, including LDO13 and LDO19 which supply the MMC2 (SD
> card).
> 
> When constraints were applied, the depending regulators were not
> providing enough power, leading to SD card detection errors:
>   mmc1: card never left busy state
>   mmc1: error -110 whilst initialising SD card
> 
> Fixes: 86a2d2ac5e5d ("ARM: dts: Add dts file for Odroid XU3 board")
> Signed-off-by: Krzysztof Kozlowski <k.kozlow...@samsung.com>
> 
> ---
> 
> The issue can be reproduced on next-20160324 with
> bae4fdc88d7f7dda1 (regulator: core: Ensure we are at least in bounds for our 
> constraints).
> ---
>  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 
> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> index 1bd507bfa750..82b2ba632cf6 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -299,7 +299,7 @@
>   buck9_reg: BUCK9 {
>   regulator-name = "vdd_2.8v_ldo";
>   regulator-min-microvolt = <300>;
> - regulator-max-microvolt = <375>;
> + regulator-max-microvolt = <3755000>;
>   regulator-always-on;
>   regulator-boot-on;
>   };
> 

I tested next-20160324 + $SUBJECT on an Odroid XU4 (with exynos_defconfig)
and while it's true that the patch makes the SD card error to go away, I see
that the s2mps11 regulator driver fails to probe due an -EINVAL being return
by machine_constraints_voltage() -> _regulator_do_set_voltage():

[1.710300] vdd_2.8v_ldo: failed to apply 3755000-3755000uV constraint(-22)
[1.716387] s2mps11-pmic s2mps11-regulator: regulator init failed for 46
[1.734878] s2mps11-pmic: probe of s2mps11-regulator failed with error -22

I wonder how neither Markus nor you saw this issue when testing so maybe I'm
doing something wrong? Since AFAICT it's only working because the driver fails
to probe so the same effect can be achieved disabling CONFIG_REGULATOR_S2MPS11.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America


Re: [PATCH] ARM: dts: exynos: Fix invalid maximum voltage for buck9 supplying SD card

2016-03-24 Thread Javier Martinez Canillas
Hello Krzysztof,

On 03/24/2016 05:12 AM, Krzysztof Kozlowski wrote:
> The buck9 regulator of S2MPS11 PMIC had incorrect maximum voltage -
> lower by 5 mV than specified by datasheet. This buck9 provides power to
> other regulators, including LDO13 and LDO19 which supply the MMC2 (SD
> card).
> 
> When constraints were applied, the depending regulators were not
> providing enough power, leading to SD card detection errors:
>   mmc1: card never left busy state
>   mmc1: error -110 whilst initialising SD card
> 
> Fixes: 86a2d2ac5e5d ("ARM: dts: Add dts file for Odroid XU3 board")
> Signed-off-by: Krzysztof Kozlowski 
> 
> ---
> 
> The issue can be reproduced on next-20160324 with
> bae4fdc88d7f7dda1 (regulator: core: Ensure we are at least in bounds for our 
> constraints).
> ---
>  arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi 
> b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> index 1bd507bfa750..82b2ba632cf6 100644
> --- a/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> +++ b/arch/arm/boot/dts/exynos5422-odroidxu3-common.dtsi
> @@ -299,7 +299,7 @@
>   buck9_reg: BUCK9 {
>   regulator-name = "vdd_2.8v_ldo";
>   regulator-min-microvolt = <300>;
> - regulator-max-microvolt = <375>;
> + regulator-max-microvolt = <3755000>;
>   regulator-always-on;
>   regulator-boot-on;
>   };
> 

I tested next-20160324 + $SUBJECT on an Odroid XU4 (with exynos_defconfig)
and while it's true that the patch makes the SD card error to go away, I see
that the s2mps11 regulator driver fails to probe due an -EINVAL being return
by machine_constraints_voltage() -> _regulator_do_set_voltage():

[1.710300] vdd_2.8v_ldo: failed to apply 3755000-3755000uV constraint(-22)
[1.716387] s2mps11-pmic s2mps11-regulator: regulator init failed for 46
[1.734878] s2mps11-pmic: probe of s2mps11-regulator failed with error -22

I wonder how neither Markus nor you saw this issue when testing so maybe I'm
doing something wrong? Since AFAICT it's only working because the driver fails
to probe so the same effect can be achieved disabling CONFIG_REGULATOR_S2MPS11.

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America


Re: [PATCH 1/2] staging: dgnc: fix 'line over 80 characters'

2016-03-24 Thread DaeSeok Youn
2016-03-25 12:19 GMT+09:00 Joe Perches :
> On Fri, 2016-03-25 at 11:44 +0900, Daeseok Youn wrote:
>> fix checkpatch.pl warning about 'line over 80 characters'
>> in dgnc_neo.c
> []
>> diff --git a/drivers/staging/dgnc/dgnc_neo.c 
>> b/drivers/staging/dgnc/dgnc_neo.c
> []
>> @@ -77,7 +77,8 @@ struct board_ops dgnc_neo_ops = {
>>   .send_immediate_char =  neo_send_immediate_char
>>  };
>>
>> -static uint dgnc_offset_table[8] = { 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 
>> 0x40, 0x80 };
>> +static uint dgnc_offset_table[8] = { 0x01, 0x02, 0x04, 0x08,
>> +  0x10, 0x20, 0x40, 0x80 };
>
Hi, Joe.

> It may be better to remove this array and use BIT or << where
> dgnc_offset_table is used instead.
Yes, I will remove this array, and use BIT or '<<' instead of using table.
But "a patch" as to have one meaning so I think this patch will be
sent with another one.
>
> If not, this should be const.
>
> static const uint dgnc_offset_table[] = {
> 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80
> };
>
>> @@ -116,7 +117,8 @@ static inline void neo_set_cts_flow_control(struct 
>> channel_t *ch)
>>   writeb(efr, >ch_neo_uart->efr);
>>
>>   /* Turn on table D, with 8 char hi/low watermarks */
>> - writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY), 
>> >ch_neo_uart->fctr);
>> + writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY),
>> + >ch_neo_uart->fctr);
>
> You could remove parentheses here around the CONST | CONST
OK. I got it. but it also, I will send a patch after fixing this, not
in this, right?
>
>> @@ -150,7 +152,8 @@ static inline void neo_set_rts_flow_control(struct 
>> channel_t *ch)
>>   /* Turn on UART enhanced bits */
>>   writeb(efr, >ch_neo_uart->efr);
>>
>> - writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY), 
>> >ch_neo_uart->fctr);
>> + writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY),
>> + >ch_neo_uart->fctr);
>
> and here and all the other writeb uses
Thanks.

regards,
Daeseok.
>


Re: [PATCH 1/2] staging: dgnc: fix 'line over 80 characters'

2016-03-24 Thread DaeSeok Youn
2016-03-25 12:19 GMT+09:00 Joe Perches :
> On Fri, 2016-03-25 at 11:44 +0900, Daeseok Youn wrote:
>> fix checkpatch.pl warning about 'line over 80 characters'
>> in dgnc_neo.c
> []
>> diff --git a/drivers/staging/dgnc/dgnc_neo.c 
>> b/drivers/staging/dgnc/dgnc_neo.c
> []
>> @@ -77,7 +77,8 @@ struct board_ops dgnc_neo_ops = {
>>   .send_immediate_char =  neo_send_immediate_char
>>  };
>>
>> -static uint dgnc_offset_table[8] = { 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 
>> 0x40, 0x80 };
>> +static uint dgnc_offset_table[8] = { 0x01, 0x02, 0x04, 0x08,
>> +  0x10, 0x20, 0x40, 0x80 };
>
Hi, Joe.

> It may be better to remove this array and use BIT or << where
> dgnc_offset_table is used instead.
Yes, I will remove this array, and use BIT or '<<' instead of using table.
But "a patch" as to have one meaning so I think this patch will be
sent with another one.
>
> If not, this should be const.
>
> static const uint dgnc_offset_table[] = {
> 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80
> };
>
>> @@ -116,7 +117,8 @@ static inline void neo_set_cts_flow_control(struct 
>> channel_t *ch)
>>   writeb(efr, >ch_neo_uart->efr);
>>
>>   /* Turn on table D, with 8 char hi/low watermarks */
>> - writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY), 
>> >ch_neo_uart->fctr);
>> + writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY),
>> + >ch_neo_uart->fctr);
>
> You could remove parentheses here around the CONST | CONST
OK. I got it. but it also, I will send a patch after fixing this, not
in this, right?
>
>> @@ -150,7 +152,8 @@ static inline void neo_set_rts_flow_control(struct 
>> channel_t *ch)
>>   /* Turn on UART enhanced bits */
>>   writeb(efr, >ch_neo_uart->efr);
>>
>> - writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY), 
>> >ch_neo_uart->fctr);
>> + writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY),
>> + >ch_neo_uart->fctr);
>
> and here and all the other writeb uses
Thanks.

regards,
Daeseok.
>


Re: [PATCH RT 4/6] rt/locking: Reenable migration accross schedule

2016-03-24 Thread Mike Galbraith
On Thu, 2016-03-24 at 12:06 +0100, Mike Galbraith wrote:
> On Thu, 2016-03-24 at 11:44 +0100, Thomas Gleixner wrote:
> >  
> > > On the bright side, with the busted migrate enable business reverted,
> > > plus one dinky change from me [1], master-rt.today has completed 100
> > > iterations of Steven's hotplug stress script along side endless
> > > futexstress, and is happily doing another 900 as I write this, so the
> > > next -rt should finally be hotplug deadlock free.
> > > 
> > > Thomas's state machinery seems to work wonders.  'course this being
> > > hotplug, the other shoe will likely apply itself to my backside soon.
> > 
> > That's a given :)
> 
> blk-mq applied it shortly after I was satisfied enough to poke xmit.

The other shoe is that notifiers can depend upon RCU grace periods, so
when pin_current_cpu() snags rcu_sched, the hotplug game is over.

blk_mq_queue_reinit_notify:
/*
 * We need to freeze and reinit all existing queues.  Freezing
 * involves synchronous wait for an RCU grace period and doing it
 * one by one may take a long time.  Start freezing all queues in
 * one swoop and then wait for the completions so that freezing can
 * take place in parallel.
 */
list_for_each_entry(q, _q_list, all_q_node)
blk_mq_freeze_queue_start(q);
list_for_each_entry(q, _q_list, all_q_node) {
blk_mq_freeze_queue_wait(q);

Hohum (sharpens rock), next.

-Mike


Re: [PATCH RT 4/6] rt/locking: Reenable migration accross schedule

2016-03-24 Thread Mike Galbraith
On Thu, 2016-03-24 at 12:06 +0100, Mike Galbraith wrote:
> On Thu, 2016-03-24 at 11:44 +0100, Thomas Gleixner wrote:
> >  
> > > On the bright side, with the busted migrate enable business reverted,
> > > plus one dinky change from me [1], master-rt.today has completed 100
> > > iterations of Steven's hotplug stress script along side endless
> > > futexstress, and is happily doing another 900 as I write this, so the
> > > next -rt should finally be hotplug deadlock free.
> > > 
> > > Thomas's state machinery seems to work wonders.  'course this being
> > > hotplug, the other shoe will likely apply itself to my backside soon.
> > 
> > That's a given :)
> 
> blk-mq applied it shortly after I was satisfied enough to poke xmit.

The other shoe is that notifiers can depend upon RCU grace periods, so
when pin_current_cpu() snags rcu_sched, the hotplug game is over.

blk_mq_queue_reinit_notify:
/*
 * We need to freeze and reinit all existing queues.  Freezing
 * involves synchronous wait for an RCU grace period and doing it
 * one by one may take a long time.  Start freezing all queues in
 * one swoop and then wait for the completions so that freezing can
 * take place in parallel.
 */
list_for_each_entry(q, _q_list, all_q_node)
blk_mq_freeze_queue_start(q);
list_for_each_entry(q, _q_list, all_q_node) {
blk_mq_freeze_queue_wait(q);

Hohum (sharpens rock), next.

-Mike


Re: [PATCH V8 00/14] Add T210 support in Tegra soctherm

2016-03-24 Thread Wei Ni
Hi, Eduardo
Will you take this series, it seems no more comments.

Thanks.
Wei.

On 2016年03月16日 16:55, Wei Ni wrote:
> This patchset adds following functions for tegra_soctherm driver:
> 1. add T210 support.
> 2. export debugfs to show some registers.
> 3. add thermtrip funciton.
> 4. add suspend/resume function.
> 
> The v7 series is in:
> https://patchwork.kernel.org/patch/8561681/
> The v6 series is in:
> https://lkml.org/lkml/2016/2/22/66
> The v5 series is in:
> http://www.spinics.net/lists/linux-tegra/msg25079.html
> The v4 series is in:
> http://www.spinics.net/lists/linux-tegra/msg24972.html
> The V3 series is in:
> http://www.spinics.net/lists/linux-tegra/msg24911.html
> The V2 series is in:
> http://www.spinics.net/lists/linux-tegra/msg24901.html
> The V1 series is in:
> http://www.spinics.net/lists/linux-tegra/msg24808.html
> 
> Main changes from V7:
> 1. Split PM support patch into three smaller patches.
> 2. Few changes per Eduardo's comments.
> 
> Main changes from V6:
> 1. rebased patches on Eduardo's
> [PATCH 00/13] thermal: convert users of thermal_zone_of_sensor_register to 
> devm_
> 
> Main changes from V5:
> 1. Change to use linux thermal framework to implement
> thermtrip funciton, per Rob's comment.
> 2. Add .set_trip_temp() in of-thermal driver, so that
> we can set trips on hardware.
> 
> Main changes from V4:
> 1. Change description of devicetree binding per Rob's comment.
> 2. Call of_node_put to decrement refcount of the node.
> 
> Main changes from V3:
> 1. Change structures to "const" in chip specific files.
> 2. Minor changes per Thieery's comments.
> 
> Main changes from V2:
> 1. Fix build error in patch [1/11].
> 2. Use of_get_child_by_name instead of of_find_node_by_name in patch [8/11].
> 3. Use debugfs_remove_recursive to remove debugfs in patch [6/11].
> 
> Main changes from V1:
> 1. Use the new type to handl different Tegra chips in one driver, which 
> suggested by Thierry.
> 2. Changes per Thieery's other comments.
> 
> Wei Ni (14):
>   thermal: tegra: move tegra thermal files into tegra directory
>   thermal: tegra: combine sensor group-related data
>   thermal: tegra: get rid of PDIV/HOTSPOT hack
>   thermal: tegra: split tegra_soctherm driver
>   thermal: tegra: add Tegra210 specific SOC_THERM driver
>   thermal: tegra: add a debugfs to show registers
>   thermal: of-thermal: allow setting trip_temp on hardware
>   of: add notes of critical trips for soctherm
>   thermal: tegra: add thermtrip function
>   thermal: tegra: handle clocks in one function
>   thermal: tegra: handle HW initialization in one funcotion
>   thermal: tegra: add PM support
>   arm64: tegra: add soctherm node for Tegra210
>   arm: tegra: set critical trips for Tegra124
> 
>  .../devicetree/bindings/thermal/tegra-soctherm.txt |  12 +
>  arch/arm/boot/dts/tegra124-jetson-tk1.dts  |  18 +-
>  arch/arm/boot/dts/tegra124.dtsi|  48 ++
>  arch/arm64/boot/dts/nvidia/tegra210.dtsi   |  92 +++
>  drivers/thermal/Kconfig|  12 +-
>  drivers/thermal/Makefile   |   2 +-
>  drivers/thermal/of-thermal.c   |   8 +
>  drivers/thermal/tegra/Kconfig  |  13 +
>  drivers/thermal/tegra/Makefile |   5 +
>  drivers/thermal/tegra/soctherm-fuse.c  | 169 +
>  drivers/thermal/tegra/soctherm.c   | 682 
> +
>  drivers/thermal/tegra/soctherm.h   | 123 
>  drivers/thermal/tegra/tegra124-soctherm.c  | 196 ++
>  drivers/thermal/tegra/tegra210-soctherm.c  | 197 ++
>  drivers/thermal/tegra_soctherm.c   | 463 --
>  include/dt-bindings/thermal/tegra124-soctherm.h|   1 +
>  include/linux/thermal.h|   1 +
>  17 files changed, 1553 insertions(+), 489 deletions(-)
>  create mode 100644 drivers/thermal/tegra/Kconfig
>  create mode 100644 drivers/thermal/tegra/Makefile
>  create mode 100644 drivers/thermal/tegra/soctherm-fuse.c
>  create mode 100644 drivers/thermal/tegra/soctherm.c
>  create mode 100644 drivers/thermal/tegra/soctherm.h
>  create mode 100644 drivers/thermal/tegra/tegra124-soctherm.c
>  create mode 100644 drivers/thermal/tegra/tegra210-soctherm.c
>  delete mode 100644 drivers/thermal/tegra_soctherm.c
> 


Re: [PATCH V8 00/14] Add T210 support in Tegra soctherm

2016-03-24 Thread Wei Ni
Hi, Eduardo
Will you take this series, it seems no more comments.

Thanks.
Wei.

On 2016年03月16日 16:55, Wei Ni wrote:
> This patchset adds following functions for tegra_soctherm driver:
> 1. add T210 support.
> 2. export debugfs to show some registers.
> 3. add thermtrip funciton.
> 4. add suspend/resume function.
> 
> The v7 series is in:
> https://patchwork.kernel.org/patch/8561681/
> The v6 series is in:
> https://lkml.org/lkml/2016/2/22/66
> The v5 series is in:
> http://www.spinics.net/lists/linux-tegra/msg25079.html
> The v4 series is in:
> http://www.spinics.net/lists/linux-tegra/msg24972.html
> The V3 series is in:
> http://www.spinics.net/lists/linux-tegra/msg24911.html
> The V2 series is in:
> http://www.spinics.net/lists/linux-tegra/msg24901.html
> The V1 series is in:
> http://www.spinics.net/lists/linux-tegra/msg24808.html
> 
> Main changes from V7:
> 1. Split PM support patch into three smaller patches.
> 2. Few changes per Eduardo's comments.
> 
> Main changes from V6:
> 1. rebased patches on Eduardo's
> [PATCH 00/13] thermal: convert users of thermal_zone_of_sensor_register to 
> devm_
> 
> Main changes from V5:
> 1. Change to use linux thermal framework to implement
> thermtrip funciton, per Rob's comment.
> 2. Add .set_trip_temp() in of-thermal driver, so that
> we can set trips on hardware.
> 
> Main changes from V4:
> 1. Change description of devicetree binding per Rob's comment.
> 2. Call of_node_put to decrement refcount of the node.
> 
> Main changes from V3:
> 1. Change structures to "const" in chip specific files.
> 2. Minor changes per Thieery's comments.
> 
> Main changes from V2:
> 1. Fix build error in patch [1/11].
> 2. Use of_get_child_by_name instead of of_find_node_by_name in patch [8/11].
> 3. Use debugfs_remove_recursive to remove debugfs in patch [6/11].
> 
> Main changes from V1:
> 1. Use the new type to handl different Tegra chips in one driver, which 
> suggested by Thierry.
> 2. Changes per Thieery's other comments.
> 
> Wei Ni (14):
>   thermal: tegra: move tegra thermal files into tegra directory
>   thermal: tegra: combine sensor group-related data
>   thermal: tegra: get rid of PDIV/HOTSPOT hack
>   thermal: tegra: split tegra_soctherm driver
>   thermal: tegra: add Tegra210 specific SOC_THERM driver
>   thermal: tegra: add a debugfs to show registers
>   thermal: of-thermal: allow setting trip_temp on hardware
>   of: add notes of critical trips for soctherm
>   thermal: tegra: add thermtrip function
>   thermal: tegra: handle clocks in one function
>   thermal: tegra: handle HW initialization in one funcotion
>   thermal: tegra: add PM support
>   arm64: tegra: add soctherm node for Tegra210
>   arm: tegra: set critical trips for Tegra124
> 
>  .../devicetree/bindings/thermal/tegra-soctherm.txt |  12 +
>  arch/arm/boot/dts/tegra124-jetson-tk1.dts  |  18 +-
>  arch/arm/boot/dts/tegra124.dtsi|  48 ++
>  arch/arm64/boot/dts/nvidia/tegra210.dtsi   |  92 +++
>  drivers/thermal/Kconfig|  12 +-
>  drivers/thermal/Makefile   |   2 +-
>  drivers/thermal/of-thermal.c   |   8 +
>  drivers/thermal/tegra/Kconfig  |  13 +
>  drivers/thermal/tegra/Makefile |   5 +
>  drivers/thermal/tegra/soctherm-fuse.c  | 169 +
>  drivers/thermal/tegra/soctherm.c   | 682 
> +
>  drivers/thermal/tegra/soctherm.h   | 123 
>  drivers/thermal/tegra/tegra124-soctherm.c  | 196 ++
>  drivers/thermal/tegra/tegra210-soctherm.c  | 197 ++
>  drivers/thermal/tegra_soctherm.c   | 463 --
>  include/dt-bindings/thermal/tegra124-soctherm.h|   1 +
>  include/linux/thermal.h|   1 +
>  17 files changed, 1553 insertions(+), 489 deletions(-)
>  create mode 100644 drivers/thermal/tegra/Kconfig
>  create mode 100644 drivers/thermal/tegra/Makefile
>  create mode 100644 drivers/thermal/tegra/soctherm-fuse.c
>  create mode 100644 drivers/thermal/tegra/soctherm.c
>  create mode 100644 drivers/thermal/tegra/soctherm.h
>  create mode 100644 drivers/thermal/tegra/tegra124-soctherm.c
>  create mode 100644 drivers/thermal/tegra/tegra210-soctherm.c
>  delete mode 100644 drivers/thermal/tegra_soctherm.c
> 


[PATCH] driver: input :touchscreen : add Raydium I2C touch driver

2016-03-24 Thread jeffrey.lin
Raydium I2C touch driver.

Signed-off-by: jeffrey.lin 
---
 drivers/input/touchscreen/Kconfig  |  12 +
 drivers/input/touchscreen/Makefile |   1 +
 drivers/input/touchscreen/raydium_i2c_ts.c | 932 +
 3 files changed, 945 insertions(+)
 create mode 100644 drivers/input/touchscreen/raydium_i2c_ts.c

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index 3f3f6ee..df0e2ed 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -915,6 +915,18 @@ config TOUCHSCREEN_PCAP
  To compile this driver as a module, choose M here: the
  module will be called pcap_ts.
 
+config TOUCHSCREEN_RM_TS
+   tristate "Raydium I2C Touchscreen"
+   depends on I2C
+   help
+ Say Y here if you have Raydium series I2C touchscreen,
+ such as RM32380,connected to your system.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called raydium_i2c_ts.
+
 config TOUCHSCREEN_ST1232
tristate "Sitronix ST1232 touchscreen controllers"
depends on I2C
diff --git a/drivers/input/touchscreen/Makefile 
b/drivers/input/touchscreen/Makefile
index 4941f2d..99e08cf 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_TOUCHSCREEN_USB_COMPOSITE)   += 
usbtouchscreen.o
 obj-$(CONFIG_TOUCHSCREEN_PCAP) += pcap_ts.o
 obj-$(CONFIG_TOUCHSCREEN_PENMOUNT) += penmount.o
 obj-$(CONFIG_TOUCHSCREEN_PIXCIR)   += pixcir_i2c_ts.o
+obj-$(CONFIG_TOUCHSCREEN_RM_TS)+= raydium_i2c_ts.o
 obj-$(CONFIG_TOUCHSCREEN_S3C2410)  += s3c2410_ts.o
 obj-$(CONFIG_TOUCHSCREEN_ST1232)   += st1232.o
 obj-$(CONFIG_TOUCHSCREEN_STMPE)+= stmpe-ts.o
diff --git a/drivers/input/touchscreen/raydium_i2c_ts.c 
b/drivers/input/touchscreen/raydium_i2c_ts.c
new file mode 100644
index 000..e1ff49a
--- /dev/null
+++ b/drivers/input/touchscreen/raydium_i2c_ts.c
@@ -0,0 +1,932 @@
+/*
+ * Raydium touchscreen I2C driver.
+ *
+ * Copyright (C) 2012-2014, Raydium Semiconductor Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2, and only version 2, as published by the
+ * Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Raydium reserves the right to make changes without further notice
+ * to the materials described herein. Raydium does not assume any
+ * liability arising out of the application described herein.
+ *
+ * Contact Raydium Semiconductor Corporation at www.rad-ic.com
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Device, Driver information */
+#define DEVICE_NAME"rm_ts"
+
+/* Slave I2C mode*/
+#define RM_BOOT_BLDR   0x02
+#define RM_BOOT_MAIN   0x03
+
+/*I2C command */
+#define CMD_QUERY_BANK 0x2B
+#define CMD_DATA_BANK  0x4D
+#define CMD_ENTER_SLEEP0x4E
+#define CMD_BOOT_ACK   0x0A
+#define CMD_BOOT_WRT   0x5B
+#define CMD_BOOT_CHK   0x0C
+#define CMD_BANK_SWITCH0xAA
+
+/* Touch relative info */
+#define MAX_RETRIES3
+#define MAX_FW_UPDATE_RETRIES  30
+#define MAX_TOUCH_NUM  10
+#define MAX_PACKET_SIZE60
+#define BOOT_DELAY_MS  100
+
+#define RAYDIUM_FW_PAGESIZE128
+#define RAYDIUM_POWERON_DELAY_USEC 500
+#define RAYDIUM_RESET_DELAY_MSEC   50
+
+#define ADDR_INDEX 0x03
+#define DATA_INDEX 0x04
+
+#define HEADER_SIZE4
+
+enum raydium_boot_mode {
+   RAYDIUM_TS_MAIN = 0,
+   RAYDIUM_TS_BLDR,
+};
+
+enum raydium_abs_idx {
+   POS_STATE = 0,/*1:touch, 0:no touch*/
+   POS_X,
+   POS_Y = 3,
+   POS_PRESSURE,
+   WIDTH_X,
+   WIDTH_Y,
+};
+
+struct raydium_info {
+   u32 hw_ver; /*device ver, __le32*/
+   u8 main_ver;
+   u8 sub_ver;
+   u16 ft_ver; /*test ver, __le16*/
+   u8 x_num;
+   u8 y_num;
+   u16 x_max;  /*disp reso, __le16*/
+   u16 y_max;  /*disp reso, __le16*/
+   u8 x_res;   /* units/mm */
+   u8 y_res;   /* units/mm */
+};
+
+struct raydium_object {
+   u32 data_bank_addr;
+   u8 pkg_size;
+   u8 tp_info_size;
+};
+
+/* struct raydium_data - represents state of Raydium touchscreen device */
+struct raydium_data {
+   struct i2c_client *client;
+   struct input_dev *input;
+
+   struct regulator *avdd;
+   struct regulator *vccio;
+   struct gpio_desc 

[PATCH] driver: input :touchscreen : add Raydium I2C touch driver

2016-03-24 Thread jeffrey.lin
Raydium I2C touch driver.

Signed-off-by: jeffrey.lin 
---
 drivers/input/touchscreen/Kconfig  |  12 +
 drivers/input/touchscreen/Makefile |   1 +
 drivers/input/touchscreen/raydium_i2c_ts.c | 932 +
 3 files changed, 945 insertions(+)
 create mode 100644 drivers/input/touchscreen/raydium_i2c_ts.c

diff --git a/drivers/input/touchscreen/Kconfig 
b/drivers/input/touchscreen/Kconfig
index 3f3f6ee..df0e2ed 100644
--- a/drivers/input/touchscreen/Kconfig
+++ b/drivers/input/touchscreen/Kconfig
@@ -915,6 +915,18 @@ config TOUCHSCREEN_PCAP
  To compile this driver as a module, choose M here: the
  module will be called pcap_ts.
 
+config TOUCHSCREEN_RM_TS
+   tristate "Raydium I2C Touchscreen"
+   depends on I2C
+   help
+ Say Y here if you have Raydium series I2C touchscreen,
+ such as RM32380,connected to your system.
+
+ If unsure, say N.
+
+ To compile this driver as a module, choose M here: the
+ module will be called raydium_i2c_ts.
+
 config TOUCHSCREEN_ST1232
tristate "Sitronix ST1232 touchscreen controllers"
depends on I2C
diff --git a/drivers/input/touchscreen/Makefile 
b/drivers/input/touchscreen/Makefile
index 4941f2d..99e08cf 100644
--- a/drivers/input/touchscreen/Makefile
+++ b/drivers/input/touchscreen/Makefile
@@ -55,6 +55,7 @@ obj-$(CONFIG_TOUCHSCREEN_USB_COMPOSITE)   += 
usbtouchscreen.o
 obj-$(CONFIG_TOUCHSCREEN_PCAP) += pcap_ts.o
 obj-$(CONFIG_TOUCHSCREEN_PENMOUNT) += penmount.o
 obj-$(CONFIG_TOUCHSCREEN_PIXCIR)   += pixcir_i2c_ts.o
+obj-$(CONFIG_TOUCHSCREEN_RM_TS)+= raydium_i2c_ts.o
 obj-$(CONFIG_TOUCHSCREEN_S3C2410)  += s3c2410_ts.o
 obj-$(CONFIG_TOUCHSCREEN_ST1232)   += st1232.o
 obj-$(CONFIG_TOUCHSCREEN_STMPE)+= stmpe-ts.o
diff --git a/drivers/input/touchscreen/raydium_i2c_ts.c 
b/drivers/input/touchscreen/raydium_i2c_ts.c
new file mode 100644
index 000..e1ff49a
--- /dev/null
+++ b/drivers/input/touchscreen/raydium_i2c_ts.c
@@ -0,0 +1,932 @@
+/*
+ * Raydium touchscreen I2C driver.
+ *
+ * Copyright (C) 2012-2014, Raydium Semiconductor Corporation.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2, and only version 2, as published by the
+ * Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Raydium reserves the right to make changes without further notice
+ * to the materials described herein. Raydium does not assume any
+ * liability arising out of the application described herein.
+ *
+ * Contact Raydium Semiconductor Corporation at www.rad-ic.com
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/* Device, Driver information */
+#define DEVICE_NAME"rm_ts"
+
+/* Slave I2C mode*/
+#define RM_BOOT_BLDR   0x02
+#define RM_BOOT_MAIN   0x03
+
+/*I2C command */
+#define CMD_QUERY_BANK 0x2B
+#define CMD_DATA_BANK  0x4D
+#define CMD_ENTER_SLEEP0x4E
+#define CMD_BOOT_ACK   0x0A
+#define CMD_BOOT_WRT   0x5B
+#define CMD_BOOT_CHK   0x0C
+#define CMD_BANK_SWITCH0xAA
+
+/* Touch relative info */
+#define MAX_RETRIES3
+#define MAX_FW_UPDATE_RETRIES  30
+#define MAX_TOUCH_NUM  10
+#define MAX_PACKET_SIZE60
+#define BOOT_DELAY_MS  100
+
+#define RAYDIUM_FW_PAGESIZE128
+#define RAYDIUM_POWERON_DELAY_USEC 500
+#define RAYDIUM_RESET_DELAY_MSEC   50
+
+#define ADDR_INDEX 0x03
+#define DATA_INDEX 0x04
+
+#define HEADER_SIZE4
+
+enum raydium_boot_mode {
+   RAYDIUM_TS_MAIN = 0,
+   RAYDIUM_TS_BLDR,
+};
+
+enum raydium_abs_idx {
+   POS_STATE = 0,/*1:touch, 0:no touch*/
+   POS_X,
+   POS_Y = 3,
+   POS_PRESSURE,
+   WIDTH_X,
+   WIDTH_Y,
+};
+
+struct raydium_info {
+   u32 hw_ver; /*device ver, __le32*/
+   u8 main_ver;
+   u8 sub_ver;
+   u16 ft_ver; /*test ver, __le16*/
+   u8 x_num;
+   u8 y_num;
+   u16 x_max;  /*disp reso, __le16*/
+   u16 y_max;  /*disp reso, __le16*/
+   u8 x_res;   /* units/mm */
+   u8 y_res;   /* units/mm */
+};
+
+struct raydium_object {
+   u32 data_bank_addr;
+   u8 pkg_size;
+   u8 tp_info_size;
+};
+
+/* struct raydium_data - represents state of Raydium touchscreen device */
+struct raydium_data {
+   struct i2c_client *client;
+   struct input_dev *input;
+
+   struct regulator *avdd;
+   struct regulator *vccio;
+   struct gpio_desc *reset_gpio;
+
+   u32 

Re: [PATCH v2] cpufreq: rockchip: add driver

2016-03-24 Thread Viresh Kumar
On 24-03-16, 23:09, Finley Xiao wrote:
> --- a/arch/arm64/boot/dts/rockchip/rk3366.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3366.dtsi
> +   cpufreq {
> +   compatible = "***,***";
> +   }
> 
> Does it create a DT node for a dummy device too ?

Yes, its not allowed.

-- 
viresh


Re: [PATCH v2] cpufreq: rockchip: add driver

2016-03-24 Thread Viresh Kumar
On 24-03-16, 23:09, Finley Xiao wrote:
> --- a/arch/arm64/boot/dts/rockchip/rk3366.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3366.dtsi
> +   cpufreq {
> +   compatible = "***,***";
> +   }
> 
> Does it create a DT node for a dummy device too ?

Yes, its not allowed.

-- 
viresh


Re: [PATCH 1/1] usb: chipidea: add DMA mask configuration API

2016-03-24 Thread kbuild test robot
Hi Peter,

[auto build test ERROR on v4.5-rc7]
[also build test ERROR on next-20160324]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Peter-Chen/usb-chipidea-add-DMA-mask-configuration-API/20160325-120535
config: i386-randconfig-s1-201612 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> ERROR: "ci_hdrc_set_dma_mask" [drivers/usb/chipidea/ci_hdrc_msm.ko] 
>> undefined!

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


.config.gz
Description: Binary data


Re: [PATCH 1/1] usb: chipidea: add DMA mask configuration API

2016-03-24 Thread kbuild test robot
Hi Peter,

[auto build test ERROR on v4.5-rc7]
[also build test ERROR on next-20160324]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Peter-Chen/usb-chipidea-add-DMA-mask-configuration-API/20160325-120535
config: i386-randconfig-s1-201612 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> ERROR: "ci_hdrc_set_dma_mask" [drivers/usb/chipidea/ci_hdrc_msm.ko] 
>> undefined!

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


.config.gz
Description: Binary data


Re: [PATCH] arm64/dma-mapping: Add DMA_ATTR_ALLOC_SINGLE_PAGES support

2016-03-24 Thread Doug Anderson
Hi,

On Thu, Mar 24, 2016 at 4:50 AM, Will Deacon  wrote:
>> > I have a slight snag with this, in that you don't consult the IOMMU
>> > pgsize_bitmap at any point, and assume that it can map pages at the
>> > same granularity as the CPU. The documentation for
>> > DMA_ATTR_ALLOC_SINGLE_PAGES seems to be weaker than that.
>>
>> Interesting.  Is that something that exists in the real world?  ...or
>> something you think is coming soon?
>
> All it would take is for an IOMMU driver to choose a granule size that
> differs from the CPU. For example, if the SMMU driver chose 64k pages
> and the CPU was using 4k pages, then you'd have this problem.
>
>> I'd argue that such a case existed in the real world then probably
>> we're already broken.  Unless I'm misreading, existing code will
>> already fall all the way back to order 0 allocations.  ...so while
>> existing code might could work if it was called on a totally
>> unfragmented system, it would already break once some fragmentation
>> was introduced.
>
> I disagree. For example, in the case I described previously, they may
> well settle on a common supported granule (e.g. 2M), assuming that
> contiguous pages were implemented in the page table code.

I'm still a little confused how existing code could have worked if
IOMMU has 64K pages and CPU has 4K pages if memory is fragmented.
Presumably existing code in __iommu_dma_alloc_pages() would keep
failing the "alloc_pages(gfp | __GFP_NORETRY, order);" call until
order got down to 0.  Then we'd allocate order 0 (4K) pages and we'd
hit a bug.


>> I'm not saying that we shouldn't fix the code to handle this, I'm just
>> saying that Yong Wu's patch doesn't appear to break any code that
>> wasn't already broken.  That might be reason to land his code first,
>> then debate the finer points of whether IOMMUs with less granularity
>> are likely to exist and whether we need to add complexity to the code
>> to handle them (or just detect this case and return an error).
>>
>> From looking at a WIP patch provided to me by Yong Wu, it looks as if
>> he thinks several more functions need to change to handle this need
>> for IOMMUs that can't handle small pages.  That seems to be further
>> evidence that the work should be done in a separate patch.
>
> Sure, my observations weren't intended to hold up this patch, but we
> should double-check that we're no regressing any of the existing IOMMU
> drivers/platforms by going straight to order 0 allocations.

Argh.  I see why I was confused and thought it got complicated.  When
I looked at diffs I thought Yong Wu's patch was more complicated
because he rebased it and my diff showed some other unrelated patches.
Dumb.

OK, you're right that this is pretty simple.

In any case, you're right that we should fix this.  ...though assuming
my argument above isn't wrong, then existing code is already broken or
has a latent bug if you've got an IOMMU that can't map at least as
granular as the CPU.  To me that means adding that new feature (or
fixing that latent bug) should be done in a separate patch.  It could
come in sequence either before or after this one.  Of course, if
everyone else thinks it should be one patch I won't block that...

-Doug


Re: [PATCH] arm64/dma-mapping: Add DMA_ATTR_ALLOC_SINGLE_PAGES support

2016-03-24 Thread Doug Anderson
Hi,

On Thu, Mar 24, 2016 at 4:50 AM, Will Deacon  wrote:
>> > I have a slight snag with this, in that you don't consult the IOMMU
>> > pgsize_bitmap at any point, and assume that it can map pages at the
>> > same granularity as the CPU. The documentation for
>> > DMA_ATTR_ALLOC_SINGLE_PAGES seems to be weaker than that.
>>
>> Interesting.  Is that something that exists in the real world?  ...or
>> something you think is coming soon?
>
> All it would take is for an IOMMU driver to choose a granule size that
> differs from the CPU. For example, if the SMMU driver chose 64k pages
> and the CPU was using 4k pages, then you'd have this problem.
>
>> I'd argue that such a case existed in the real world then probably
>> we're already broken.  Unless I'm misreading, existing code will
>> already fall all the way back to order 0 allocations.  ...so while
>> existing code might could work if it was called on a totally
>> unfragmented system, it would already break once some fragmentation
>> was introduced.
>
> I disagree. For example, in the case I described previously, they may
> well settle on a common supported granule (e.g. 2M), assuming that
> contiguous pages were implemented in the page table code.

I'm still a little confused how existing code could have worked if
IOMMU has 64K pages and CPU has 4K pages if memory is fragmented.
Presumably existing code in __iommu_dma_alloc_pages() would keep
failing the "alloc_pages(gfp | __GFP_NORETRY, order);" call until
order got down to 0.  Then we'd allocate order 0 (4K) pages and we'd
hit a bug.


>> I'm not saying that we shouldn't fix the code to handle this, I'm just
>> saying that Yong Wu's patch doesn't appear to break any code that
>> wasn't already broken.  That might be reason to land his code first,
>> then debate the finer points of whether IOMMUs with less granularity
>> are likely to exist and whether we need to add complexity to the code
>> to handle them (or just detect this case and return an error).
>>
>> From looking at a WIP patch provided to me by Yong Wu, it looks as if
>> he thinks several more functions need to change to handle this need
>> for IOMMUs that can't handle small pages.  That seems to be further
>> evidence that the work should be done in a separate patch.
>
> Sure, my observations weren't intended to hold up this patch, but we
> should double-check that we're no regressing any of the existing IOMMU
> drivers/platforms by going straight to order 0 allocations.

Argh.  I see why I was confused and thought it got complicated.  When
I looked at diffs I thought Yong Wu's patch was more complicated
because he rebased it and my diff showed some other unrelated patches.
Dumb.

OK, you're right that this is pretty simple.

In any case, you're right that we should fix this.  ...though assuming
my argument above isn't wrong, then existing code is already broken or
has a latent bug if you've got an IOMMU that can't map at least as
granular as the CPU.  To me that means adding that new feature (or
fixing that latent bug) should be done in a separate patch.  It could
come in sequence either before or after this one.  Of course, if
everyone else thinks it should be one patch I won't block that...

-Doug


Re: [PATCH 1/6] block: ensure we don't truncate top bits of the request command flags

2016-03-24 Thread Jens Axboe

On 03/24/2016 08:08 PM, Mike Christie wrote:

On 03/22/2016 02:01 PM, Jens Axboe wrote:

On 03/22/2016 12:59 PM, Christoph Hellwig wrote:

On Tue, Mar 22, 2016 at 11:55:15AM -0600, Jens Axboe wrote:

Some of the flags that we want to use from the make_request_fn path
are now larger than 32-bit, so change the functions involved to
accept an u64 instead of an unsigned int.


When did we start doing that?  We really should merge Mike's split
of the operation style flags into the cmd_type before making things
even worse in the flags area.


Just now, and I ran into it last week as well, for a test patch on cfq
that passed in higher flags for get_request -> may_queue() as well. We
can do Mike's split first, I think it's a good cleanup. As a standalone
series, I needed it though.



Hey, did you want any changes on that patchset? I was going to repost it
with the kbuild fix against linux-next, but I can make any changes you
wanted first.


I don't believe I've ever been CC'ed on the posting, or it even being 
posted on the block list? If so, I don't see it... I did become aware of 
it since Christoph CC'ed me in. In general, I think it looks good, at 
least the end results. It's a bit murky in the middle, and the commit 
messages need some help. So go over everything, sanitize it, and repost 
it. I don't like the current pure flag based scheme we have, it's a mess 
of ops and modifiers. So splitting that up is definitely a good thing.


--
Jens Axboe



Re: [PATCH 1/6] block: ensure we don't truncate top bits of the request command flags

2016-03-24 Thread Jens Axboe

On 03/24/2016 08:08 PM, Mike Christie wrote:

On 03/22/2016 02:01 PM, Jens Axboe wrote:

On 03/22/2016 12:59 PM, Christoph Hellwig wrote:

On Tue, Mar 22, 2016 at 11:55:15AM -0600, Jens Axboe wrote:

Some of the flags that we want to use from the make_request_fn path
are now larger than 32-bit, so change the functions involved to
accept an u64 instead of an unsigned int.


When did we start doing that?  We really should merge Mike's split
of the operation style flags into the cmd_type before making things
even worse in the flags area.


Just now, and I ran into it last week as well, for a test patch on cfq
that passed in higher flags for get_request -> may_queue() as well. We
can do Mike's split first, I think it's a good cleanup. As a standalone
series, I needed it though.



Hey, did you want any changes on that patchset? I was going to repost it
with the kbuild fix against linux-next, but I can make any changes you
wanted first.


I don't believe I've ever been CC'ed on the posting, or it even being 
posted on the block list? If so, I don't see it... I did become aware of 
it since Christoph CC'ed me in. In general, I think it looks good, at 
least the end results. It's a bit murky in the middle, and the commit 
messages need some help. So go over everything, sanitize it, and repost 
it. I don't like the current pure flag based scheme we have, it's a mess 
of ops and modifiers. So splitting that up is definitely a good thing.


--
Jens Axboe



Re: [PATCH] usb: chipidea: Configure DMA properties and ops from DT

2016-03-24 Thread Peter Chen
On Tue, Mar 08, 2016 at 07:40:08PM -0800, Bjorn Andersson wrote:
> On Tue, Mar 8, 2016 at 11:52 AM, Li Yang  wrote:
> > On Wed, Mar 2, 2016 at 4:59 PM, Li Yang  wrote:
> >> On Mon, Feb 22, 2016 at 4:07 PM, Bjorn Andersson
> >>  wrote:
> >>> On Mon 22 Feb 02:03 PST 2016, Srinivas Kandagatla wrote:
> >>>
> 
> 
>  On 22/02/16 05:32, Bjorn Andersson wrote:
>  >On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly set
>  >to be able to do DMA allocations, so use the of_dma_configure() helper
>  >to populate the dma properties and assign an appropriate dma_ops.
> [..]
>  None of the drivers call of_dma_configure() explicitly, which makes me 
>  feel
>  that we are doing something wrong. TBH, this should be handled in more
>  generic way rather than driver like this having an explicit call to
>  of_dma_configure().
> 
> >>>
> 
> I had the chance to go through this with Arnd and the verdict is that
> devices not described in DT should not do DMA (or allocate buffers for
> doing DMA).
> 
> So I believe the solution is to fall back on Peter's description; the
> chipidea driver is the core driver and the Qualcomm code should just
> be a platform layer.
> 
> My suggestion is that we turn the chipidea core into a set of APIs
> that can called by the platform specific pieces. That way we will have
> the chipidea core be the device described in the DT.
> 

Hi Bjorn,

After reading the DMA documentation Russell supplied and several related
DMA APIs, would you please try below patch on your ARM64 platform?
Since the core device has no device node at all, I don't know why
your patch can work, or am I missing something?

>From bcf7eaf694d29fb7557a9406fb6c89213216069c Mon Sep 17 00:00:00 2001
From: Peter Chen 
Date: Fri, 25 Mar 2016 11:54:21 +0800
Subject: [PATCH 1/1] usb: chipidea: add DMA mask configuration API

Signed-off-by: Peter Chen 
---
 drivers/usb/chipidea/ci_hdrc_msm.c |6 ++
 drivers/usb/chipidea/core.c|   25 +
 include/linux/usb/chipidea.h   |2 ++
 3 files changed, 33 insertions(+)

diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
b/drivers/usb/chipidea/ci_hdrc_msm.c
index 3889809..43ceb38 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -5,6 +5,7 @@
  * only version 2 as published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -56,6 +57,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
 {
struct platform_device *plat_ci;
struct usb_phy *phy;
+   int ret;
 
dev_dbg(>dev, "ci_hdrc_msm_probe\n");
 
@@ -70,6 +72,10 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
 
ci_hdrc_msm_platdata.usb_phy = phy;
 
+   ret = ci_hdrc_set_dma_mask(>dev, DMA_BIT_MASK(64));
+   if (ret)
+   return ret;
+
plat_ci = ci_hdrc_add_device(>dev,
pdev->resource, pdev->num_resources,
_hdrc_msm_platdata);
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 69426e6..b8ca5e3 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -62,6 +62,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -811,6 +812,30 @@ static void ci_extcon_unregister(struct ci_hdrc *ci)
 
 static DEFINE_IDA(ci_ida);
 
+/**
+ * ci_hdrc_set_dma_mask
+ *
+ * Set dma mask and coherent dma mask for glue layer device, and the core
+ * device will inherit these values. If the 'dma-ranges' is specified at
+ * DT, it will use this value for both dma mask and coherent dma mask.
+ *
+ * @dev: a pointer to the device struct of glue layer device
+ * @ci_coherent_dma_mask: the mask for both dma_mask and cohrent_dma_mask
+ */
+int ci_hdrc_set_dma_mask(struct device *dev, u64 ci_coherent_dma_mask)
+{
+   int ret = dma_set_mask_and_coherent(dev, ci_coherent_dma_mask);
+   if (ret) {
+   dev_err(dev, "dma_set_mask_and_coherent fails\n");
+   return ret;
+   }
+
+   if (dev_of_node(dev))
+   of_dma_configure(dev, dev->of_node);
+
+   return ret;
+}
+
 struct platform_device *ci_hdrc_add_device(struct device *dev,
struct resource *res, int nres,
struct ci_hdrc_platform_data *platdata)
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index 5dd75fa..8649930 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -84,4 +84,6 @@ struct platform_device *ci_hdrc_add_device(struct device *dev,
 /* Remove ci hdrc device */
 void ci_hdrc_remove_device(struct platform_device *pdev);
 
+int ci_hdrc_set_dma_mask(struct device *dev, u64 ci_coherent_dma_mask);
+
 #endif

-- 
Best Regards,
Peter Chen


Re: [GIT PULL] Ceph fixes for -rc7

2016-03-24 Thread NeilBrown
On Sun, Mar 06 2016, Sage Weil wrote:

> Hi Linus,
>
> Please pull the following Ceph patch from
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus
>
> This is a final commit we missed to align the protocol compatibility with 
> the feature bits.  It decodes a few extra fields in two different messages 
> and reports EIO when they are used (not yet supported).
>
> Thanks!
> sage
>
>
> 
> Yan, Zheng (1):
>   ceph: initial CEPH_FEATURE_FS_FILE_LAYOUT_V2 support

Just wondering, but was CEPH_FEATURE_FS_FILE_LAYOUT_V2 supposed to have
exactly the same value as CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (and
CEPH_FEATURE_CRUSH_TUNABLES5)??
Because when I backported this patch (and many others) to some ancient
enterprise kernel, it caused mounts to fail.  If it really is meant to
be the same value, then I must have some other backported issue to find
and fix.

Thanks,
NeilBrown


>
>  fs/ceph/addr.c |  4 
>  fs/ceph/caps.c | 27 ---
>  fs/ceph/inode.c|  2 ++
>  fs/ceph/mds_client.c   | 16 
>  fs/ceph/mds_client.h   |  1 +
>  fs/ceph/super.h|  1 +
>  include/linux/ceph/ceph_features.h |  1 +
>  7 files changed, 49 insertions(+), 3 deletions(-)


signature.asc
Description: PGP signature


Re: [PATCH] usb: chipidea: Configure DMA properties and ops from DT

2016-03-24 Thread Peter Chen
On Tue, Mar 08, 2016 at 07:40:08PM -0800, Bjorn Andersson wrote:
> On Tue, Mar 8, 2016 at 11:52 AM, Li Yang  wrote:
> > On Wed, Mar 2, 2016 at 4:59 PM, Li Yang  wrote:
> >> On Mon, Feb 22, 2016 at 4:07 PM, Bjorn Andersson
> >>  wrote:
> >>> On Mon 22 Feb 02:03 PST 2016, Srinivas Kandagatla wrote:
> >>>
> 
> 
>  On 22/02/16 05:32, Bjorn Andersson wrote:
>  >On certain platforms (e.g. ARM64) the dma_ops needs to be explicitly set
>  >to be able to do DMA allocations, so use the of_dma_configure() helper
>  >to populate the dma properties and assign an appropriate dma_ops.
> [..]
>  None of the drivers call of_dma_configure() explicitly, which makes me 
>  feel
>  that we are doing something wrong. TBH, this should be handled in more
>  generic way rather than driver like this having an explicit call to
>  of_dma_configure().
> 
> >>>
> 
> I had the chance to go through this with Arnd and the verdict is that
> devices not described in DT should not do DMA (or allocate buffers for
> doing DMA).
> 
> So I believe the solution is to fall back on Peter's description; the
> chipidea driver is the core driver and the Qualcomm code should just
> be a platform layer.
> 
> My suggestion is that we turn the chipidea core into a set of APIs
> that can called by the platform specific pieces. That way we will have
> the chipidea core be the device described in the DT.
> 

Hi Bjorn,

After reading the DMA documentation Russell supplied and several related
DMA APIs, would you please try below patch on your ARM64 platform?
Since the core device has no device node at all, I don't know why
your patch can work, or am I missing something?

>From bcf7eaf694d29fb7557a9406fb6c89213216069c Mon Sep 17 00:00:00 2001
From: Peter Chen 
Date: Fri, 25 Mar 2016 11:54:21 +0800
Subject: [PATCH 1/1] usb: chipidea: add DMA mask configuration API

Signed-off-by: Peter Chen 
---
 drivers/usb/chipidea/ci_hdrc_msm.c |6 ++
 drivers/usb/chipidea/core.c|   25 +
 include/linux/usb/chipidea.h   |2 ++
 3 files changed, 33 insertions(+)

diff --git a/drivers/usb/chipidea/ci_hdrc_msm.c 
b/drivers/usb/chipidea/ci_hdrc_msm.c
index 3889809..43ceb38 100644
--- a/drivers/usb/chipidea/ci_hdrc_msm.c
+++ b/drivers/usb/chipidea/ci_hdrc_msm.c
@@ -5,6 +5,7 @@
  * only version 2 as published by the Free Software Foundation.
  */
 
+#include 
 #include 
 #include 
 #include 
@@ -56,6 +57,7 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
 {
struct platform_device *plat_ci;
struct usb_phy *phy;
+   int ret;
 
dev_dbg(>dev, "ci_hdrc_msm_probe\n");
 
@@ -70,6 +72,10 @@ static int ci_hdrc_msm_probe(struct platform_device *pdev)
 
ci_hdrc_msm_platdata.usb_phy = phy;
 
+   ret = ci_hdrc_set_dma_mask(>dev, DMA_BIT_MASK(64));
+   if (ret)
+   return ret;
+
plat_ci = ci_hdrc_add_device(>dev,
pdev->resource, pdev->num_resources,
_hdrc_msm_platdata);
diff --git a/drivers/usb/chipidea/core.c b/drivers/usb/chipidea/core.c
index 69426e6..b8ca5e3 100644
--- a/drivers/usb/chipidea/core.c
+++ b/drivers/usb/chipidea/core.c
@@ -62,6 +62,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -811,6 +812,30 @@ static void ci_extcon_unregister(struct ci_hdrc *ci)
 
 static DEFINE_IDA(ci_ida);
 
+/**
+ * ci_hdrc_set_dma_mask
+ *
+ * Set dma mask and coherent dma mask for glue layer device, and the core
+ * device will inherit these values. If the 'dma-ranges' is specified at
+ * DT, it will use this value for both dma mask and coherent dma mask.
+ *
+ * @dev: a pointer to the device struct of glue layer device
+ * @ci_coherent_dma_mask: the mask for both dma_mask and cohrent_dma_mask
+ */
+int ci_hdrc_set_dma_mask(struct device *dev, u64 ci_coherent_dma_mask)
+{
+   int ret = dma_set_mask_and_coherent(dev, ci_coherent_dma_mask);
+   if (ret) {
+   dev_err(dev, "dma_set_mask_and_coherent fails\n");
+   return ret;
+   }
+
+   if (dev_of_node(dev))
+   of_dma_configure(dev, dev->of_node);
+
+   return ret;
+}
+
 struct platform_device *ci_hdrc_add_device(struct device *dev,
struct resource *res, int nres,
struct ci_hdrc_platform_data *platdata)
diff --git a/include/linux/usb/chipidea.h b/include/linux/usb/chipidea.h
index 5dd75fa..8649930 100644
--- a/include/linux/usb/chipidea.h
+++ b/include/linux/usb/chipidea.h
@@ -84,4 +84,6 @@ struct platform_device *ci_hdrc_add_device(struct device *dev,
 /* Remove ci hdrc device */
 void ci_hdrc_remove_device(struct platform_device *pdev);
 
+int ci_hdrc_set_dma_mask(struct device *dev, u64 ci_coherent_dma_mask);
+
 #endif

-- 
Best Regards,
Peter Chen


Re: [GIT PULL] Ceph fixes for -rc7

2016-03-24 Thread NeilBrown
On Sun, Mar 06 2016, Sage Weil wrote:

> Hi Linus,
>
> Please pull the following Ceph patch from
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/sage/ceph-client.git for-linus
>
> This is a final commit we missed to align the protocol compatibility with 
> the feature bits.  It decodes a few extra fields in two different messages 
> and reports EIO when they are used (not yet supported).
>
> Thanks!
> sage
>
>
> 
> Yan, Zheng (1):
>   ceph: initial CEPH_FEATURE_FS_FILE_LAYOUT_V2 support

Just wondering, but was CEPH_FEATURE_FS_FILE_LAYOUT_V2 supposed to have
exactly the same value as CEPH_FEATURE_NEW_OSDOPREPLY_ENCODING (and
CEPH_FEATURE_CRUSH_TUNABLES5)??
Because when I backported this patch (and many others) to some ancient
enterprise kernel, it caused mounts to fail.  If it really is meant to
be the same value, then I must have some other backported issue to find
and fix.

Thanks,
NeilBrown


>
>  fs/ceph/addr.c |  4 
>  fs/ceph/caps.c | 27 ---
>  fs/ceph/inode.c|  2 ++
>  fs/ceph/mds_client.c   | 16 
>  fs/ceph/mds_client.h   |  1 +
>  fs/ceph/super.h|  1 +
>  include/linux/ceph/ceph_features.h |  1 +
>  7 files changed, 49 insertions(+), 3 deletions(-)


signature.asc
Description: PGP signature


[PATCH] ASoC: mediatek: Add second I2S on mt8173-rt5650 machine driver

2016-03-24 Thread PC Liao
This patch adds second I2S for rt5650 codec on mt8173-rt5650 machine driver.

Signed-off-by: PC Liao 
---
 .../devicetree/bindings/sound/mt8173-rt5650.txt|6 +++
 sound/soc/mediatek/mt8173-rt5650.c |   55 ++--
 2 files changed, 56 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt 
b/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt
index fe5a5ef..0046926 100644
--- a/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt
+++ b/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt
@@ -5,11 +5,17 @@ Required properties:
 - mediatek,audio-codec: the phandles of rt5650 codecs
 - mediatek,platform: the phandle of MT8173 ASoC platform
 
+Optional properties:
+- mediatek,rt5650_i2s: I2S mode of rt5650
+  0: using I2S1 on rt5650 for record
+  1: using I2S2 on rt5650 for record
+
 Example:
 
sound {
compatible = "mediatek,mt8173-rt5650";
mediatek,audio-codec = <>;
mediatek,platform = <>;
+   mediatek,rt5650_i2s = <0>;
};
 
diff --git a/sound/soc/mediatek/mt8173-rt5650.c 
b/sound/soc/mediatek/mt8173-rt5650.c
index bb09bb1..ab4c806 100644
--- a/sound/soc/mediatek/mt8173-rt5650.c
+++ b/sound/soc/mediatek/mt8173-rt5650.c
@@ -23,6 +23,20 @@
 
 #define MCLK_FOR_CODECS12288000
 
+struct mt8173_rt5650_platform_data {
+   unsigned int rt5650_i2s;
+   /* 0 = I2S1; 1 = I2S2 */
+};
+
+static struct mt8173_rt5650_platform_data mt8173_rt5650_priv = {
+   .rt5650_i2s = 0,
+};
+
+enum mt8173_rt5650_i2s {
+   MT8173_RT5650_I2S1 = 0,
+   MT8173_RT5650_I2S2,
+};
+
 static const struct snd_soc_dapm_widget mt8173_rt5650_widgets[] = {
SND_SOC_DAPM_SPK("Speaker", NULL),
SND_SOC_DAPM_MIC("Int Mic", NULL),
@@ -87,10 +101,25 @@ static int mt8173_rt5650_init(struct snd_soc_pcm_runtime 
*runtime)
struct snd_soc_codec *codec = runtime->codec_dais[0]->codec;
int ret;
 
-   rt5645_sel_asrc_clk_src(codec,
-   RT5645_DA_STEREO_FILTER |
-   RT5645_AD_STEREO_FILTER,
-   RT5645_CLK_SEL_I2S1_ASRC);
+   switch (mt8173_rt5650_priv.rt5650_i2s) {
+   case MT8173_RT5650_I2S1:
+   rt5645_sel_asrc_clk_src(codec,
+   RT5645_DA_STEREO_FILTER |
+   RT5645_AD_STEREO_FILTER,
+   RT5645_CLK_SEL_I2S1_ASRC);
+   break;
+   case MT8173_RT5650_I2S2:
+   rt5645_sel_asrc_clk_src(codec,
+   RT5645_DA_STEREO_FILTER,
+   RT5645_CLK_SEL_I2S1_ASRC);
+   rt5645_sel_asrc_clk_src(codec,
+   RT5645_AD_STEREO_FILTER,
+   RT5645_CLK_SEL_I2S2_ASRC);
+   break;
+   default:
+   break;
+   }
+
/* enable jack detection */
ret = snd_soc_card_jack_new(card, "Headset Jack",
SND_JACK_HEADPHONE | SND_JACK_MICROPHONE |
@@ -112,6 +141,9 @@ static struct snd_soc_dai_link_component 
mt8173_rt5650_codecs[] = {
{
.dai_name = "rt5645-aif1",
},
+   {
+   .dai_name = "rt5645-aif2",
+   },
 };
 
 enum {
@@ -149,7 +181,7 @@ static struct snd_soc_dai_link mt8173_rt5650_dais[] = {
.cpu_dai_name = "I2S",
.no_pcm = 1,
.codecs = mt8173_rt5650_codecs,
-   .num_codecs = 1,
+   .num_codecs = 2,
.init = mt8173_rt5650_init,
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
   SND_SOC_DAIFMT_CBS_CFS,
@@ -199,6 +231,19 @@ static int mt8173_rt5650_dev_probe(struct platform_device 
*pdev)
"Property 'audio-codec' missing or invalid\n");
return -EINVAL;
}
+   mt8173_rt5650_codecs[1].of_node = mt8173_rt5650_codecs[0].of_node;
+
+   if (device_property_present(>dev, "mediatek,rt5650_i2s")) {
+   ret = device_property_read_u32(>dev,
+  "mediatek,rt5650_i2s",
+  _rt5650_priv.rt5650_i2s);
+   if (ret) {
+   dev_err(>dev,
+   "%s snd_soc_register_card fail %d\n",
+   __func__, ret);
+   }
+   }
+
card->dev = >dev;
platform_set_drvdata(pdev, card);
 
-- 
1.7.9.5



[PATCH] ASoC: mediatek: Add second I2S on mt8173-rt5650 machine driver

2016-03-24 Thread PC Liao
This patch adds second I2S for rt5650 codec on mt8173-rt5650 machine driver.

Signed-off-by: PC Liao 
---
 .../devicetree/bindings/sound/mt8173-rt5650.txt|6 +++
 sound/soc/mediatek/mt8173-rt5650.c |   55 ++--
 2 files changed, 56 insertions(+), 5 deletions(-)

diff --git a/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt 
b/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt
index fe5a5ef..0046926 100644
--- a/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt
+++ b/Documentation/devicetree/bindings/sound/mt8173-rt5650.txt
@@ -5,11 +5,17 @@ Required properties:
 - mediatek,audio-codec: the phandles of rt5650 codecs
 - mediatek,platform: the phandle of MT8173 ASoC platform
 
+Optional properties:
+- mediatek,rt5650_i2s: I2S mode of rt5650
+  0: using I2S1 on rt5650 for record
+  1: using I2S2 on rt5650 for record
+
 Example:
 
sound {
compatible = "mediatek,mt8173-rt5650";
mediatek,audio-codec = <>;
mediatek,platform = <>;
+   mediatek,rt5650_i2s = <0>;
};
 
diff --git a/sound/soc/mediatek/mt8173-rt5650.c 
b/sound/soc/mediatek/mt8173-rt5650.c
index bb09bb1..ab4c806 100644
--- a/sound/soc/mediatek/mt8173-rt5650.c
+++ b/sound/soc/mediatek/mt8173-rt5650.c
@@ -23,6 +23,20 @@
 
 #define MCLK_FOR_CODECS12288000
 
+struct mt8173_rt5650_platform_data {
+   unsigned int rt5650_i2s;
+   /* 0 = I2S1; 1 = I2S2 */
+};
+
+static struct mt8173_rt5650_platform_data mt8173_rt5650_priv = {
+   .rt5650_i2s = 0,
+};
+
+enum mt8173_rt5650_i2s {
+   MT8173_RT5650_I2S1 = 0,
+   MT8173_RT5650_I2S2,
+};
+
 static const struct snd_soc_dapm_widget mt8173_rt5650_widgets[] = {
SND_SOC_DAPM_SPK("Speaker", NULL),
SND_SOC_DAPM_MIC("Int Mic", NULL),
@@ -87,10 +101,25 @@ static int mt8173_rt5650_init(struct snd_soc_pcm_runtime 
*runtime)
struct snd_soc_codec *codec = runtime->codec_dais[0]->codec;
int ret;
 
-   rt5645_sel_asrc_clk_src(codec,
-   RT5645_DA_STEREO_FILTER |
-   RT5645_AD_STEREO_FILTER,
-   RT5645_CLK_SEL_I2S1_ASRC);
+   switch (mt8173_rt5650_priv.rt5650_i2s) {
+   case MT8173_RT5650_I2S1:
+   rt5645_sel_asrc_clk_src(codec,
+   RT5645_DA_STEREO_FILTER |
+   RT5645_AD_STEREO_FILTER,
+   RT5645_CLK_SEL_I2S1_ASRC);
+   break;
+   case MT8173_RT5650_I2S2:
+   rt5645_sel_asrc_clk_src(codec,
+   RT5645_DA_STEREO_FILTER,
+   RT5645_CLK_SEL_I2S1_ASRC);
+   rt5645_sel_asrc_clk_src(codec,
+   RT5645_AD_STEREO_FILTER,
+   RT5645_CLK_SEL_I2S2_ASRC);
+   break;
+   default:
+   break;
+   }
+
/* enable jack detection */
ret = snd_soc_card_jack_new(card, "Headset Jack",
SND_JACK_HEADPHONE | SND_JACK_MICROPHONE |
@@ -112,6 +141,9 @@ static struct snd_soc_dai_link_component 
mt8173_rt5650_codecs[] = {
{
.dai_name = "rt5645-aif1",
},
+   {
+   .dai_name = "rt5645-aif2",
+   },
 };
 
 enum {
@@ -149,7 +181,7 @@ static struct snd_soc_dai_link mt8173_rt5650_dais[] = {
.cpu_dai_name = "I2S",
.no_pcm = 1,
.codecs = mt8173_rt5650_codecs,
-   .num_codecs = 1,
+   .num_codecs = 2,
.init = mt8173_rt5650_init,
.dai_fmt = SND_SOC_DAIFMT_I2S | SND_SOC_DAIFMT_NB_NF |
   SND_SOC_DAIFMT_CBS_CFS,
@@ -199,6 +231,19 @@ static int mt8173_rt5650_dev_probe(struct platform_device 
*pdev)
"Property 'audio-codec' missing or invalid\n");
return -EINVAL;
}
+   mt8173_rt5650_codecs[1].of_node = mt8173_rt5650_codecs[0].of_node;
+
+   if (device_property_present(>dev, "mediatek,rt5650_i2s")) {
+   ret = device_property_read_u32(>dev,
+  "mediatek,rt5650_i2s",
+  _rt5650_priv.rt5650_i2s);
+   if (ret) {
+   dev_err(>dev,
+   "%s snd_soc_register_card fail %d\n",
+   __func__, ret);
+   }
+   }
+
card->dev = >dev;
platform_set_drvdata(pdev, card);
 
-- 
1.7.9.5



[PATCH] dt-bindings: input: add Raydium I2C touch bindings

2016-03-24 Thread jeffrey.lin
Document the device tree binfings of Raydium I2C touch.

Signed-off-by: jeffrey.lin 
---
 .../devicetree/bindings/input/raydium_i2c_ts.txt | 20 
 .../devicetree/bindings/vendor-prefixes.txt  |  1 +
 2 files changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/raydium_i2c_ts.txt

diff --git a/Documentation/devicetree/bindings/input/raydium_i2c_ts.txt 
b/Documentation/devicetree/bindings/input/raydium_i2c_ts.txt
new file mode 100644
index 000..52a7bf0
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/raydium_i2c_ts.txt
@@ -0,0 +1,20 @@
+Raydium I2C touchscreen
+
+Required properties:
+- compatible : must be "raydium,rm32380"
+- reg: The I2C address of the device
+- interrupt-parent: the phandle for the interrupt controller
+- interrupts: interrupt to which the chip is connected
+See ../interrupt-controller/interrupts.txt
+Optional properties:
+- avdd-supply : analog power supply needed to power device
+- vccio-supply : IO Power source
+- reset-gpios : reset gpio the chip is connected to.
+
+Example:
+   raydium_i2c@39 {
+   compatible = "raydium,rm32380";
+   reg = <0x39>;
+   interrupt-parent = <>;
+   interrupts = <0x0 IRQ_TYPE_EDGE_FALLING>;
+   };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index af49e0f..5b6224b 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -126,6 +126,7 @@ radxa   Radxa
 raidsonic  RaidSonic Technology GmbH
 ralink Mediatek/Ralink Technology Corp.
 ramtronRamtron International
+raydium Raydium Semiconductor Corp.
 realtek Realtek Semiconductor Corp.
 renesasRenesas Electronics Corporation
 ricoh  Ricoh Co. Ltd.
-- 
2.1.2



[PATCH] dt-bindings: input: add Raydium I2C touch bindings

2016-03-24 Thread jeffrey.lin
Document the device tree binfings of Raydium I2C touch.

Signed-off-by: jeffrey.lin 
---
 .../devicetree/bindings/input/raydium_i2c_ts.txt | 20 
 .../devicetree/bindings/vendor-prefixes.txt  |  1 +
 2 files changed, 21 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/input/raydium_i2c_ts.txt

diff --git a/Documentation/devicetree/bindings/input/raydium_i2c_ts.txt 
b/Documentation/devicetree/bindings/input/raydium_i2c_ts.txt
new file mode 100644
index 000..52a7bf0
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/raydium_i2c_ts.txt
@@ -0,0 +1,20 @@
+Raydium I2C touchscreen
+
+Required properties:
+- compatible : must be "raydium,rm32380"
+- reg: The I2C address of the device
+- interrupt-parent: the phandle for the interrupt controller
+- interrupts: interrupt to which the chip is connected
+See ../interrupt-controller/interrupts.txt
+Optional properties:
+- avdd-supply : analog power supply needed to power device
+- vccio-supply : IO Power source
+- reset-gpios : reset gpio the chip is connected to.
+
+Example:
+   raydium_i2c@39 {
+   compatible = "raydium,rm32380";
+   reg = <0x39>;
+   interrupt-parent = <>;
+   interrupts = <0x0 IRQ_TYPE_EDGE_FALLING>;
+   };
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index af49e0f..5b6224b 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -126,6 +126,7 @@ radxa   Radxa
 raidsonic  RaidSonic Technology GmbH
 ralink Mediatek/Ralink Technology Corp.
 ramtronRamtron International
+raydium Raydium Semiconductor Corp.
 realtek Realtek Semiconductor Corp.
 renesasRenesas Electronics Corporation
 ricoh  Ricoh Co. Ltd.
-- 
2.1.2



Perf misreports userspace args to unoptimized functions

2016-03-24 Thread Dima Kogan
Hi.

I'm seeing an issue with the way perf interfaces with uprobes that
results in incorrect printing of function arguments under fairly normal
conditions. Example:

Let's say I have a trivial C program tst.c:

=
  #include 
  #include 
  int f(int x)
  {
  return !printf("%d\n", x);
  }
  int main(int argc, char* argv[])
  {
  return f(argc);
  }
==

I ask perf to trap all calls to f() and to give me the value of the x
argument:

==
  $ gcc-5 -g -o tst tst.c &&
perf probe -x tst --add 'f x' &&
perf record -eprobe_tst:f ./tst 2 3 4 &&
perf script

  Added new event:
probe_tst:f  (on f in /tmp/tst with x)

  You can now use it in all perf tools, such as:

  perf record -e probe_tst:f -aR sleep 1

  4
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.016 MB perf.data (1 samples) ]
   tst 24626 [003] 98586.485680: probe_tst:f: (4004e6) x=0
==

Note that the value passed to f() was 4, but perf reported it as 0
instead.

If I look at what uprobes was actually asked to report, I see this:

==
  $ cat /sys/kernel/debug/tracing/uprobe_events 

  p:probe_tst/f /tmp/tst:0x04e6 x=-12(%sp):s32
==

The corresponding disassembly is:

==
  $ objdump -d tst | awk '/:/,/^$/'
  004004e6 :
4004e6:   55  push   %rbp
4004e7:   48 89 e5mov%rsp,%rbp
4004ea:   48 83 ec 10 sub$0x10,%rsp
4004ee:   89 7d fcmov%edi,-0x4(%rbp)
4004f1:   8b 45 fcmov-0x4(%rbp),%eax
4004f4:   89 c6   mov%eax,%esi
4004f6:   bf b4 05 40 00  mov$0x4005b4,%edi
4004fb:   b8 00 00 00 00  mov$0x0,%eax
400500:   e8 bb fe ff ff  callq  4003c0 
400505:   85 c0   test   %eax,%eax
400507:   0f 94 c0sete   %al
40050a:   0f b6 c0movzbl %al,%eax
40050d:   c9  leaveq 
40050e:   c3  retq   
==

So uprobes was looking at the argument as a local stack variable.
However the trap was placed at the start of the function, where the
stack variable wasn't yet available (the argument is still in %di).

This doesn't happen with optimized code, because (at least in this
simple example) the variable is simply kept in %di, the DWARF data
indicates this, and perf picks that up. Any particular thoughts about
how to solve this? Options are

1. place the trace after the local variables are set (4004f1 in this
   example)
2. Look at %di instead of the stack variable

Is there enough information in the DWARF to know to do either of these?
I didn't see anything obvious. Is either option reliable? I.e. could the
optimizer break them?

Thanks
dima


Perf misreports userspace args to unoptimized functions

2016-03-24 Thread Dima Kogan
Hi.

I'm seeing an issue with the way perf interfaces with uprobes that
results in incorrect printing of function arguments under fairly normal
conditions. Example:

Let's say I have a trivial C program tst.c:

=
  #include 
  #include 
  int f(int x)
  {
  return !printf("%d\n", x);
  }
  int main(int argc, char* argv[])
  {
  return f(argc);
  }
==

I ask perf to trap all calls to f() and to give me the value of the x
argument:

==
  $ gcc-5 -g -o tst tst.c &&
perf probe -x tst --add 'f x' &&
perf record -eprobe_tst:f ./tst 2 3 4 &&
perf script

  Added new event:
probe_tst:f  (on f in /tmp/tst with x)

  You can now use it in all perf tools, such as:

  perf record -e probe_tst:f -aR sleep 1

  4
  [ perf record: Woken up 1 times to write data ]
  [ perf record: Captured and wrote 0.016 MB perf.data (1 samples) ]
   tst 24626 [003] 98586.485680: probe_tst:f: (4004e6) x=0
==

Note that the value passed to f() was 4, but perf reported it as 0
instead.

If I look at what uprobes was actually asked to report, I see this:

==
  $ cat /sys/kernel/debug/tracing/uprobe_events 

  p:probe_tst/f /tmp/tst:0x04e6 x=-12(%sp):s32
==

The corresponding disassembly is:

==
  $ objdump -d tst | awk '/:/,/^$/'
  004004e6 :
4004e6:   55  push   %rbp
4004e7:   48 89 e5mov%rsp,%rbp
4004ea:   48 83 ec 10 sub$0x10,%rsp
4004ee:   89 7d fcmov%edi,-0x4(%rbp)
4004f1:   8b 45 fcmov-0x4(%rbp),%eax
4004f4:   89 c6   mov%eax,%esi
4004f6:   bf b4 05 40 00  mov$0x4005b4,%edi
4004fb:   b8 00 00 00 00  mov$0x0,%eax
400500:   e8 bb fe ff ff  callq  4003c0 
400505:   85 c0   test   %eax,%eax
400507:   0f 94 c0sete   %al
40050a:   0f b6 c0movzbl %al,%eax
40050d:   c9  leaveq 
40050e:   c3  retq   
==

So uprobes was looking at the argument as a local stack variable.
However the trap was placed at the start of the function, where the
stack variable wasn't yet available (the argument is still in %di).

This doesn't happen with optimized code, because (at least in this
simple example) the variable is simply kept in %di, the DWARF data
indicates this, and perf picks that up. Any particular thoughts about
how to solve this? Options are

1. place the trace after the local variables are set (4004f1 in this
   example)
2. Look at %di instead of the stack variable

Is there enough information in the DWARF to know to do either of these?
I didn't see anything obvious. Is either option reliable? I.e. could the
optimizer break them?

Thanks
dima


Re: usb: gadget breakage on N900: bind UDC by name passed via usb_gadget_driver structure

2016-03-24 Thread Ruslan Bilovol
OK, so at last I finished charging of my N900; found 1.8V USB
to UART adapter and soldered it to the phone.

I managed to boot N900 with working USB gadget (builtin g_ether)
in boardfile mode, can ping it from PC and transfer data. I don't
see any issue (except of musb name issue in twl phy driver, I've
already sent a fix for that: https://lkml.org/lkml/2016/3/24/670 )

Pavel, I still don't see how you've got your issue, please share
more detials

Regards,
Ruslan

On Thu, Mar 24, 2016 at 2:45 AM, Ruslan Bilovol
 wrote:
> Hi Pavel,
>
> I didn't use my N900 for years, it is deeply discharged and can't
> boot, so I left it connected overnight to the wall adapter to let it
> get some juice.
>
> Meanwhile I looked into sources and still can't understand how
> it happens.
> Could you please attach your full .config and also dmesg
> without hacks?
>
> Regards,
> Ruslan
>
> On Wed, Mar 23, 2016 at 2:21 PM, Pavel Machek  wrote:
>> On Mon 2016-03-21 12:51:51, Marek Szyprowski wrote:
>>> Hi
>>>
>>> On 2016-03-18 21:20, Pavel Machek wrote:
>>> >Hi!
>>> >
>>> >>>USB gadget stops working for me on n900, if I merge
>>> >>Could you please give us more details?
>>> >>Which gadget driver do you use (g_nokia?)
>>> >Ok, so I could get it to work with v4.5, and this patch. I'm including
>>> >my config, too. No, I don't think I'm using g_nokia.
>>>
>>> This shows that there are some serious problems, probably with your udc
>>> driver, which doesn't handle deferred probe properly. Your patch workaround
>>> it by waiting some predefined time before registering gadget driver, however
>>> this is not the proper way. Please try to isolate what exactly is needed to
>>> get the gadget driver registered properly in your system or at least please
>>> provide some logs from the failed case.
>>
>> Well, Ruslan said he has n900 available, so I provided requested
>> information.
>>
>> This is the dmesg with the hack:
>>
>> [0.623138] of_get_named_gpiod_flags: parsed 'ti,power-gpio'
>> property of node '/ocp/spi@480ba00
>> 0/wl1251@0[0]' - status (0)
>> [0.623565] wl1251: ERROR vio regulator missing: -517
>> [0.624359] musb probe HACK cf9a9e00
>> [0.624420] musb probe HACK/2 cf9a9e00
>> [0.624511] musb probe HACK/3 cf9a9e00
>> [0.624755] HS USB OTG: no transceiver configured
>> [0.624847] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed
>> with status -517
>> [0.626525] mousedev: PS/2 mouse device common for all mice
>> ...
>> [2.877441] ieee80211 phy1: Selected rate control algorithm
>> 'minstrel'
>> [2.879882] wl1251: loaded
>> [2.889617] wl1251: initialized
>> [2.897521] Two musb controllers?  HACK
>> [2.904968] musb probe HACK cf9a9e00
>> [2.912048] musb probe HACK/2 cf9a9e00
>> [2.918823] musb probe HACK/3 cf9a9e00
>> [2.928985] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk
>> combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
>> [2.929016] musb-hdrc: MHDRC RTL version 1.400
>> [2.929046] musb-hdrc: setup fifo_mode 4
>> [2.929077] musb-hdrc: 28/31 max ep, 16384/16384 memory
>> [2.930511] tsc2005 spi1.0: GPIO lookup for consumer reset
>> [2.930541] tsc2005 spi1.0: using device tree for GPIO lookup
>>
>> In the kernel without the hack, there'll be only the first part of the
>> dmesg, AFAICT.
>>
>> If there's an interest, I can repeat the test without the hack.
>>
>> Thanks,
>> Pavel
>>
>>
>>> >diff --git a/drivers/usb/gadget/udc/udc-core.c 
>>> >b/drivers/usb/gadget/udc/udc-core.c
>>> >index b86a6f0..bee109f 100644
>>> >--- a/drivers/usb/gadget/udc/udc-core.c
>>> >+++ b/drivers/usb/gadget/udc/udc-core.c
>>> >@@ -542,14 +542,37 @@ err1:
>>> > return ret;
>>> >  }
>>> >-int usb_gadget_probe_driver(struct usb_gadget_driver *driver)
>>> >+int usb_udc_attach_driver(const char *name, struct usb_gadget_driver 
>>> >*driver)
>>> >+{
>>> >+struct usb_udc *udc = NULL;
>>> >+int ret = -ENODEV;
>>> >+
>>> >+mutex_lock(_lock);
>>> >+list_for_each_entry(udc, _list, list) {
>>> >+ret = strcmp(name, dev_name(>dev));
>>> >+if (!ret)
>>> >+break;
>>> >+}
>>> >+if (ret) {
>>> >+ret = -ENODEV;
>>> >+goto out;
>>> >+}
>>> >+if (udc->driver) {
>>> >+ret = -EBUSY;
>>> >+goto out;
>>> >+}
>>> >+ret = udc_bind_to_driver(udc, driver);
>>> >+out:
>>> >+mutex_unlock(_lock);
>>> >+return ret;
>>> >+}
>>> >+EXPORT_SYMBOL_GPL(usb_udc_attach_driver);
>>> >+
>>> >+int __usb_gadget_probe_driver(struct usb_gadget_driver *driver)
>>> >  {
>>> > struct usb_udc  *udc = NULL;
>>> > int ret = -ENODEV;
>>> >-if (!driver || !driver->bind || !driver->setup)
>>> >-return -EINVAL;
>>> >-
>>> > mutex_lock(_lock);
>>> > if (driver->udc_name) {
>>> > 

Re: usb: gadget breakage on N900: bind UDC by name passed via usb_gadget_driver structure

2016-03-24 Thread Ruslan Bilovol
OK, so at last I finished charging of my N900; found 1.8V USB
to UART adapter and soldered it to the phone.

I managed to boot N900 with working USB gadget (builtin g_ether)
in boardfile mode, can ping it from PC and transfer data. I don't
see any issue (except of musb name issue in twl phy driver, I've
already sent a fix for that: https://lkml.org/lkml/2016/3/24/670 )

Pavel, I still don't see how you've got your issue, please share
more detials

Regards,
Ruslan

On Thu, Mar 24, 2016 at 2:45 AM, Ruslan Bilovol
 wrote:
> Hi Pavel,
>
> I didn't use my N900 for years, it is deeply discharged and can't
> boot, so I left it connected overnight to the wall adapter to let it
> get some juice.
>
> Meanwhile I looked into sources and still can't understand how
> it happens.
> Could you please attach your full .config and also dmesg
> without hacks?
>
> Regards,
> Ruslan
>
> On Wed, Mar 23, 2016 at 2:21 PM, Pavel Machek  wrote:
>> On Mon 2016-03-21 12:51:51, Marek Szyprowski wrote:
>>> Hi
>>>
>>> On 2016-03-18 21:20, Pavel Machek wrote:
>>> >Hi!
>>> >
>>> >>>USB gadget stops working for me on n900, if I merge
>>> >>Could you please give us more details?
>>> >>Which gadget driver do you use (g_nokia?)
>>> >Ok, so I could get it to work with v4.5, and this patch. I'm including
>>> >my config, too. No, I don't think I'm using g_nokia.
>>>
>>> This shows that there are some serious problems, probably with your udc
>>> driver, which doesn't handle deferred probe properly. Your patch workaround
>>> it by waiting some predefined time before registering gadget driver, however
>>> this is not the proper way. Please try to isolate what exactly is needed to
>>> get the gadget driver registered properly in your system or at least please
>>> provide some logs from the failed case.
>>
>> Well, Ruslan said he has n900 available, so I provided requested
>> information.
>>
>> This is the dmesg with the hack:
>>
>> [0.623138] of_get_named_gpiod_flags: parsed 'ti,power-gpio'
>> property of node '/ocp/spi@480ba00
>> 0/wl1251@0[0]' - status (0)
>> [0.623565] wl1251: ERROR vio regulator missing: -517
>> [0.624359] musb probe HACK cf9a9e00
>> [0.624420] musb probe HACK/2 cf9a9e00
>> [0.624511] musb probe HACK/3 cf9a9e00
>> [0.624755] HS USB OTG: no transceiver configured
>> [0.624847] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed
>> with status -517
>> [0.626525] mousedev: PS/2 mouse device common for all mice
>> ...
>> [2.877441] ieee80211 phy1: Selected rate control algorithm
>> 'minstrel'
>> [2.879882] wl1251: loaded
>> [2.889617] wl1251: initialized
>> [2.897521] Two musb controllers?  HACK
>> [2.904968] musb probe HACK cf9a9e00
>> [2.912048] musb probe HACK/2 cf9a9e00
>> [2.918823] musb probe HACK/3 cf9a9e00
>> [2.928985] musb-hdrc: ConfigData=0xde (UTMI-8, dyn FIFOs, bulk
>> combine, bulk split, HB-ISO Rx, HB-ISO Tx, SoftConn)
>> [2.929016] musb-hdrc: MHDRC RTL version 1.400
>> [2.929046] musb-hdrc: setup fifo_mode 4
>> [2.929077] musb-hdrc: 28/31 max ep, 16384/16384 memory
>> [2.930511] tsc2005 spi1.0: GPIO lookup for consumer reset
>> [2.930541] tsc2005 spi1.0: using device tree for GPIO lookup
>>
>> In the kernel without the hack, there'll be only the first part of the
>> dmesg, AFAICT.
>>
>> If there's an interest, I can repeat the test without the hack.
>>
>> Thanks,
>> Pavel
>>
>>
>>> >diff --git a/drivers/usb/gadget/udc/udc-core.c 
>>> >b/drivers/usb/gadget/udc/udc-core.c
>>> >index b86a6f0..bee109f 100644
>>> >--- a/drivers/usb/gadget/udc/udc-core.c
>>> >+++ b/drivers/usb/gadget/udc/udc-core.c
>>> >@@ -542,14 +542,37 @@ err1:
>>> > return ret;
>>> >  }
>>> >-int usb_gadget_probe_driver(struct usb_gadget_driver *driver)
>>> >+int usb_udc_attach_driver(const char *name, struct usb_gadget_driver 
>>> >*driver)
>>> >+{
>>> >+struct usb_udc *udc = NULL;
>>> >+int ret = -ENODEV;
>>> >+
>>> >+mutex_lock(_lock);
>>> >+list_for_each_entry(udc, _list, list) {
>>> >+ret = strcmp(name, dev_name(>dev));
>>> >+if (!ret)
>>> >+break;
>>> >+}
>>> >+if (ret) {
>>> >+ret = -ENODEV;
>>> >+goto out;
>>> >+}
>>> >+if (udc->driver) {
>>> >+ret = -EBUSY;
>>> >+goto out;
>>> >+}
>>> >+ret = udc_bind_to_driver(udc, driver);
>>> >+out:
>>> >+mutex_unlock(_lock);
>>> >+return ret;
>>> >+}
>>> >+EXPORT_SYMBOL_GPL(usb_udc_attach_driver);
>>> >+
>>> >+int __usb_gadget_probe_driver(struct usb_gadget_driver *driver)
>>> >  {
>>> > struct usb_udc  *udc = NULL;
>>> > int ret = -ENODEV;
>>> >-if (!driver || !driver->bind || !driver->setup)
>>> >-return -EINVAL;
>>> >-
>>> > mutex_lock(_lock);
>>> > if (driver->udc_name) {
>>> > list_for_each_entry(udc, _list, list) {
>>> >@@ -567,16 

Re: [PATCH 1/2] staging: dgnc: fix 'line over 80 characters'

2016-03-24 Thread Joe Perches
On Fri, 2016-03-25 at 11:44 +0900, Daeseok Youn wrote:
> fix checkpatch.pl warning about 'line over 80 characters'
> in dgnc_neo.c
[]
> diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
[]
> @@ -77,7 +77,8 @@ struct board_ops dgnc_neo_ops = {
>   .send_immediate_char =  neo_send_immediate_char
>  };
>  
> -static uint dgnc_offset_table[8] = { 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 
> 0x40, 0x80 };
> +static uint dgnc_offset_table[8] = { 0x01, 0x02, 0x04, 0x08,
> +  0x10, 0x20, 0x40, 0x80 };

It may be better to remove this array and use BIT or << where
dgnc_offset_table is used instead.

If not, this should be const.

static const uint dgnc_offset_table[] = {
0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80
};

> @@ -116,7 +117,8 @@ static inline void neo_set_cts_flow_control(struct 
> channel_t *ch)
>   writeb(efr, >ch_neo_uart->efr);
>  
>   /* Turn on table D, with 8 char hi/low watermarks */
> - writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY), 
> >ch_neo_uart->fctr);
> + writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY),
> + >ch_neo_uart->fctr);

You could remove parentheses here around the CONST | CONST

> @@ -150,7 +152,8 @@ static inline void neo_set_rts_flow_control(struct 
> channel_t *ch)
>   /* Turn on UART enhanced bits */
>   writeb(efr, >ch_neo_uart->efr);
>  
> - writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY), 
> >ch_neo_uart->fctr);
> + writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY),
> + >ch_neo_uart->fctr);

and here and all the other writeb uses



Re: [PATCH 1/2] staging: dgnc: fix 'line over 80 characters'

2016-03-24 Thread Joe Perches
On Fri, 2016-03-25 at 11:44 +0900, Daeseok Youn wrote:
> fix checkpatch.pl warning about 'line over 80 characters'
> in dgnc_neo.c
[]
> diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
[]
> @@ -77,7 +77,8 @@ struct board_ops dgnc_neo_ops = {
>   .send_immediate_char =  neo_send_immediate_char
>  };
>  
> -static uint dgnc_offset_table[8] = { 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 
> 0x40, 0x80 };
> +static uint dgnc_offset_table[8] = { 0x01, 0x02, 0x04, 0x08,
> +  0x10, 0x20, 0x40, 0x80 };

It may be better to remove this array and use BIT or << where
dgnc_offset_table is used instead.

If not, this should be const.

static const uint dgnc_offset_table[] = {
0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 0x80
};

> @@ -116,7 +117,8 @@ static inline void neo_set_cts_flow_control(struct 
> channel_t *ch)
>   writeb(efr, >ch_neo_uart->efr);
>  
>   /* Turn on table D, with 8 char hi/low watermarks */
> - writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY), 
> >ch_neo_uart->fctr);
> + writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY),
> + >ch_neo_uart->fctr);

You could remove parentheses here around the CONST | CONST

> @@ -150,7 +152,8 @@ static inline void neo_set_rts_flow_control(struct 
> channel_t *ch)
>   /* Turn on UART enhanced bits */
>   writeb(efr, >ch_neo_uart->efr);
>  
> - writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY), 
> >ch_neo_uart->fctr);
> + writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY),
> + >ch_neo_uart->fctr);

and here and all the other writeb uses



[REDO PATCH] x86/perf: Move events_sysfs_show() outside CPU_SUP_INTEL

2016-03-24 Thread Huang Rui
This patch moves events_sysfs_show outside CONFIG_CPU_SUP_INTEL, because
this interface will be also used in an AMD power reporting PMU driver.

Otherwise, below build error would be encountered:

All error/warnings (new ones prefixed by >>):

 In file included from include/linux/kobject.h:21:0,
  from include/linux/module.h:17,
  from arch/x86/kernel/cpu/perf_event_amd_power.c:13:
  >> arch/x86/kernel/cpu/perf_event.h:663:31: error: 'events_sysfs_show' 
undeclared here (not in a function)
   .attr  = __ATTR(_name, 0444, events_sysfs_show, NULL), \
^
 include/linux/sysfs.h:103:10: note: in definition of macro '__ATTR'
   .show = _show,  \
   ^
  >> arch/x86/kernel/cpu/perf_event_amd_power.c:244:1: note: in expansion of 
macro 'EVENT_ATTR_STR'
  EVENT_ATTR_STR(power-pkg, power_pkg, "event=0x01");
  ^

Reported-by: Randy Dunlap 
Reported-by: build test robot 
Signed-off-by: Huang Rui 
Cc: Stephen Rothwell 
Cc: a...@kernel.org
---

Hi Peter, Ingo, Randy,

According to the comments of below thread, I rebased this fix to
latest kernel.

http://lkml.kernel.org/r/56f41e3f.8000...@infradead.org

Orignal patch:
https://git.kernel.org/cgit/linux/kernel/git/bp/bp.git/commit/?h=tip-perf=f5ba42d22cb478d32363b2b8e92e14b1fd190ce1

Thanks,
Rui

---
 arch/x86/events/perf_event.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h
index ba6ef18..a6771e2 100644
--- a/arch/x86/events/perf_event.h
+++ b/arch/x86/events/perf_event.h
@@ -795,6 +795,9 @@ ssize_t intel_event_sysfs_show(char *page, u64 config);
 
 struct attribute **merge_attr(struct attribute **a, struct attribute **b);
 
+ssize_t events_sysfs_show(struct device *dev, struct device_attribute *attr,
+ char *page);
+
 #ifdef CONFIG_CPU_SUP_AMD
 
 int amd_pmu_init(void);
@@ -925,9 +928,6 @@ int p6_pmu_init(void);
 
 int knc_pmu_init(void);
 
-ssize_t events_sysfs_show(struct device *dev, struct device_attribute *attr,
- char *page);
-
 static inline int is_ht_workaround_enabled(void)
 {
return !!(x86_pmu.flags & PMU_FL_EXCL_ENABLED);
-- 
1.9.1



[REDO PATCH] x86/perf: Move events_sysfs_show() outside CPU_SUP_INTEL

2016-03-24 Thread Huang Rui
This patch moves events_sysfs_show outside CONFIG_CPU_SUP_INTEL, because
this interface will be also used in an AMD power reporting PMU driver.

Otherwise, below build error would be encountered:

All error/warnings (new ones prefixed by >>):

 In file included from include/linux/kobject.h:21:0,
  from include/linux/module.h:17,
  from arch/x86/kernel/cpu/perf_event_amd_power.c:13:
  >> arch/x86/kernel/cpu/perf_event.h:663:31: error: 'events_sysfs_show' 
undeclared here (not in a function)
   .attr  = __ATTR(_name, 0444, events_sysfs_show, NULL), \
^
 include/linux/sysfs.h:103:10: note: in definition of macro '__ATTR'
   .show = _show,  \
   ^
  >> arch/x86/kernel/cpu/perf_event_amd_power.c:244:1: note: in expansion of 
macro 'EVENT_ATTR_STR'
  EVENT_ATTR_STR(power-pkg, power_pkg, "event=0x01");
  ^

Reported-by: Randy Dunlap 
Reported-by: build test robot 
Signed-off-by: Huang Rui 
Cc: Stephen Rothwell 
Cc: a...@kernel.org
---

Hi Peter, Ingo, Randy,

According to the comments of below thread, I rebased this fix to
latest kernel.

http://lkml.kernel.org/r/56f41e3f.8000...@infradead.org

Orignal patch:
https://git.kernel.org/cgit/linux/kernel/git/bp/bp.git/commit/?h=tip-perf=f5ba42d22cb478d32363b2b8e92e14b1fd190ce1

Thanks,
Rui

---
 arch/x86/events/perf_event.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h
index ba6ef18..a6771e2 100644
--- a/arch/x86/events/perf_event.h
+++ b/arch/x86/events/perf_event.h
@@ -795,6 +795,9 @@ ssize_t intel_event_sysfs_show(char *page, u64 config);
 
 struct attribute **merge_attr(struct attribute **a, struct attribute **b);
 
+ssize_t events_sysfs_show(struct device *dev, struct device_attribute *attr,
+ char *page);
+
 #ifdef CONFIG_CPU_SUP_AMD
 
 int amd_pmu_init(void);
@@ -925,9 +928,6 @@ int p6_pmu_init(void);
 
 int knc_pmu_init(void);
 
-ssize_t events_sysfs_show(struct device *dev, struct device_attribute *attr,
- char *page);
-
 static inline int is_ht_workaround_enabled(void)
 {
return !!(x86_pmu.flags & PMU_FL_EXCL_ENABLED);
-- 
1.9.1



Re: [PATCH v2] ARM: exynos_defconfig: Enable Samsung media platform drivers as modules

2016-03-24 Thread Javier Martinez Canillas
Hello Krzysztof,

On 03/23/2016 10:00 PM, Krzysztof Kozlowski wrote:
> On 24.03.2016 09:26, Javier Martinez Canillas wrote:
>> There are a bunch of media platform drivers under drivers/media/platform/
>> that are for Samsung SoCs but are not being built with exynos_defconfig.
>>
>> This patch enables them as a module to improve build coverage for these
>> drivers and also to allow people use them with proper hardware if modules
>> are installed. The S5P MFC driver wasn't enabled since it fails to probe.
>>
>> Only the boolean Kconfig symbols are enabled as built-in, since drivers
>> are not critical and also to keep the kernel binary image size as small
>> as possible.
>>
>> Signed-off-by: Javier Martinez Canillas 
>>
>> ---
>>
>> Changes in v2:
>> - Remove S5P G2D and GSC symbols since overlaps with Exynos DRM 
>> functionality.
>>   Suggested by Tobias Jakobi
>>
>>  arch/arm/configs/exynos_defconfig | 10 ++
>>  1 file changed, 10 insertions(+)
> 
> Looks good.
> Reviewed-by: Krzysztof Kozlowski 
>

Thanks for the review.
 
> 
> How about doing the same for multi_v7?
>

I didn't consider multi_v7 because media drivers aren't necessary for booting
the boards and so it could increase build times for not real benefits in most
machines. But I can enable it in multi_v7 as a follow-up if you think that it
makes sense there too.
 
> 
> Best regards,
> 
> Krzysztof
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America


Re: [PATCH v2] ARM: exynos_defconfig: Enable Samsung media platform drivers as modules

2016-03-24 Thread Javier Martinez Canillas
Hello Krzysztof,

On 03/23/2016 10:00 PM, Krzysztof Kozlowski wrote:
> On 24.03.2016 09:26, Javier Martinez Canillas wrote:
>> There are a bunch of media platform drivers under drivers/media/platform/
>> that are for Samsung SoCs but are not being built with exynos_defconfig.
>>
>> This patch enables them as a module to improve build coverage for these
>> drivers and also to allow people use them with proper hardware if modules
>> are installed. The S5P MFC driver wasn't enabled since it fails to probe.
>>
>> Only the boolean Kconfig symbols are enabled as built-in, since drivers
>> are not critical and also to keep the kernel binary image size as small
>> as possible.
>>
>> Signed-off-by: Javier Martinez Canillas 
>>
>> ---
>>
>> Changes in v2:
>> - Remove S5P G2D and GSC symbols since overlaps with Exynos DRM 
>> functionality.
>>   Suggested by Tobias Jakobi
>>
>>  arch/arm/configs/exynos_defconfig | 10 ++
>>  1 file changed, 10 insertions(+)
> 
> Looks good.
> Reviewed-by: Krzysztof Kozlowski 
>

Thanks for the review.
 
> 
> How about doing the same for multi_v7?
>

I didn't consider multi_v7 because media drivers aren't necessary for booting
the boards and so it could increase build times for not real benefits in most
machines. But I can enable it in multi_v7 as a follow-up if you think that it
makes sense there too.
 
> 
> Best regards,
> 
> Krzysztof
> 

Best regards,
-- 
Javier Martinez Canillas
Open Source Group
Samsung Research America


[PATCH v2] arm64: cpuidle: make arm_cpuidle_suspend() a bit more efficient

2016-03-24 Thread Jisheng Zhang
Currently, we check two pointers: cpu_ops and cpu_suspend on every idle
state entry. These pointers check can be avoided:

If cpu_ops has not been registered, arm_cpuidle_init() will return
-EOPNOTSUPP, so arm_cpuidle_suspend() will never have chance to
run. In other word, the cpu_ops check can be avoid.

Similarly, the cpu_suspend check could be avoided in this hot path by
moving it into arm_cpuidle_init().

I measured the 4096 * time from arm_cpuidle_suspend entry point to the
cpu_psci_cpu_suspend entry point. HW platform is Marvell BG4CT STB
board.

1. only one shell, no other process, hot-unplug secondary cpus, execute
the following cmd

while true
do
sleep 0.2
done

before the patch: 1581220ns

after the patch: 1579630ns

reduced by 0.1%

2. only one shell, no other process, hot-unplug secondary cpus, execute
the following cmd

while true
do
md5sum /tmp/testfile
sleep 0.2
done

NOTE: the testfile size should be larger than L1+L2 cache size

before the patch: 1961960ns
after the patch: 1912500ns

reduced by 2.5%

So the more complex the system load, the bigger the improvement.

Signed-off-by: Jisheng Zhang 
Acked-by: Lorenzo Pieralisi 
---
Since v1:
 - add performance numbers
 - combine two small patches into one
 - add Lorenzo's ack

 arch/arm64/kernel/cpuidle.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/kernel/cpuidle.c b/arch/arm64/kernel/cpuidle.c
index 9047cab6..e11857f 100644
--- a/arch/arm64/kernel/cpuidle.c
+++ b/arch/arm64/kernel/cpuidle.c
@@ -19,7 +19,8 @@ int __init arm_cpuidle_init(unsigned int cpu)
 {
int ret = -EOPNOTSUPP;
 
-   if (cpu_ops[cpu] && cpu_ops[cpu]->cpu_init_idle)
+   if (cpu_ops[cpu] && cpu_ops[cpu]->cpu_suspend &&
+   cpu_ops[cpu]->cpu_init_idle)
ret = cpu_ops[cpu]->cpu_init_idle(cpu);
 
return ret;
@@ -36,11 +37,5 @@ int arm_cpuidle_suspend(int index)
 {
int cpu = smp_processor_id();
 
-   /*
-* If cpu_ops have not been registered or suspend
-* has not been initialized, cpu_suspend call fails early.
-*/
-   if (!cpu_ops[cpu] || !cpu_ops[cpu]->cpu_suspend)
-   return -EOPNOTSUPP;
return cpu_ops[cpu]->cpu_suspend(index);
 }
-- 
2.8.0.rc3



[PATCH v2] arm64: cpuidle: make arm_cpuidle_suspend() a bit more efficient

2016-03-24 Thread Jisheng Zhang
Currently, we check two pointers: cpu_ops and cpu_suspend on every idle
state entry. These pointers check can be avoided:

If cpu_ops has not been registered, arm_cpuidle_init() will return
-EOPNOTSUPP, so arm_cpuidle_suspend() will never have chance to
run. In other word, the cpu_ops check can be avoid.

Similarly, the cpu_suspend check could be avoided in this hot path by
moving it into arm_cpuidle_init().

I measured the 4096 * time from arm_cpuidle_suspend entry point to the
cpu_psci_cpu_suspend entry point. HW platform is Marvell BG4CT STB
board.

1. only one shell, no other process, hot-unplug secondary cpus, execute
the following cmd

while true
do
sleep 0.2
done

before the patch: 1581220ns

after the patch: 1579630ns

reduced by 0.1%

2. only one shell, no other process, hot-unplug secondary cpus, execute
the following cmd

while true
do
md5sum /tmp/testfile
sleep 0.2
done

NOTE: the testfile size should be larger than L1+L2 cache size

before the patch: 1961960ns
after the patch: 1912500ns

reduced by 2.5%

So the more complex the system load, the bigger the improvement.

Signed-off-by: Jisheng Zhang 
Acked-by: Lorenzo Pieralisi 
---
Since v1:
 - add performance numbers
 - combine two small patches into one
 - add Lorenzo's ack

 arch/arm64/kernel/cpuidle.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/arch/arm64/kernel/cpuidle.c b/arch/arm64/kernel/cpuidle.c
index 9047cab6..e11857f 100644
--- a/arch/arm64/kernel/cpuidle.c
+++ b/arch/arm64/kernel/cpuidle.c
@@ -19,7 +19,8 @@ int __init arm_cpuidle_init(unsigned int cpu)
 {
int ret = -EOPNOTSUPP;
 
-   if (cpu_ops[cpu] && cpu_ops[cpu]->cpu_init_idle)
+   if (cpu_ops[cpu] && cpu_ops[cpu]->cpu_suspend &&
+   cpu_ops[cpu]->cpu_init_idle)
ret = cpu_ops[cpu]->cpu_init_idle(cpu);
 
return ret;
@@ -36,11 +37,5 @@ int arm_cpuidle_suspend(int index)
 {
int cpu = smp_processor_id();
 
-   /*
-* If cpu_ops have not been registered or suspend
-* has not been initialized, cpu_suspend call fails early.
-*/
-   if (!cpu_ops[cpu] || !cpu_ops[cpu]->cpu_suspend)
-   return -EOPNOTSUPP;
return cpu_ops[cpu]->cpu_suspend(index);
 }
-- 
2.8.0.rc3



Re: [PATCH] sbs-battery: fix power status when battery is dry

2016-03-24 Thread Daniel Kurtz
On Thu, Mar 24, 2016 at 2:43 PM, YH Huang  wrote:
>
> Hi Daniel,
>
> On Thu, 2016-03-24 at 12:01 +0800, Daniel Kurtz wrote:
> > Hi YH,
> >
> > On Wed, Mar 23, 2016 at 5:53 PM, YH Huang  wrote:
> > > When the battery is dry and BATTERY_FULL_DISCHARGED is set,
> > > we should check BATTERY_DISCHARGING to decide the power status.
> > > If BATTERY_DISCHARGING is set, the power status is not charging.
> > > Or the power status should be charging.
> > >
> > > Signed-off-by: YH Huang 
> > > ---
> > >  drivers/power/sbs-battery.c |   22 --
> > >  1 file changed, 12 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/power/sbs-battery.c b/drivers/power/sbs-battery.c
> > > index d6226d6..d86db0e 100644
> > > --- a/drivers/power/sbs-battery.c
> > > +++ b/drivers/power/sbs-battery.c
> > > @@ -382,11 +382,12 @@ static int sbs_get_battery_property(struct 
> > > i2c_client *client,
> > >
> > > if (ret & BATTERY_FULL_CHARGED)
> > > val->intval = POWER_SUPPLY_STATUS_FULL;
> > > -   else if (ret & BATTERY_FULL_DISCHARGED)
> > > -   val->intval = POWER_SUPPLY_STATUS_NOT_CHARGING;
> > > -   else if (ret & BATTERY_DISCHARGING)
> > > -   val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
> > > -   else
> > > +   else if (ret & BATTERY_DISCHARGING) {
> > > +   if (ret & BATTERY_FULL_DISCHARGED)
> > > +   val->intval = 
> > > POWER_SUPPLY_STATUS_NOT_CHARGING;
> > > +   else
> > > +   val->intval = 
> > > POWER_SUPPLY_STATUS_DISCHARGING;
> > > +   } else
> >
> >
> > I think (BATTERY_DISCHARGING && BATTERY_FULL_DISCHARGED) is still
> > POWER_SUPPLY_STATUS_DISCHARGING.
> > So, let's just report what the battery says and do:
> >
> >else if (ret & BATTERY_DISCHARGING)
> >val->intval = 
> > POWER_SUPPLY_STATUS_DISCHARGING;
> >
> So we just ignore the special situation (BATTERY_DISCHARGING &&
> BATTERY_FULL_DISCHARGED).
> Isn't POWER_SUPPLY_STATUS_NOT_CHARGING a useful information?

The battery is discharging.  The fact that it is also reporting that
it is already "discharged" just seems premature.   I would expect to
only see NOT_CHARGING if completely discharged *and* not discharging.

>
>
> Regards,
> YH Huang
>


Re: [PATCH] sbs-battery: fix power status when battery is dry

2016-03-24 Thread Daniel Kurtz
On Thu, Mar 24, 2016 at 2:43 PM, YH Huang  wrote:
>
> Hi Daniel,
>
> On Thu, 2016-03-24 at 12:01 +0800, Daniel Kurtz wrote:
> > Hi YH,
> >
> > On Wed, Mar 23, 2016 at 5:53 PM, YH Huang  wrote:
> > > When the battery is dry and BATTERY_FULL_DISCHARGED is set,
> > > we should check BATTERY_DISCHARGING to decide the power status.
> > > If BATTERY_DISCHARGING is set, the power status is not charging.
> > > Or the power status should be charging.
> > >
> > > Signed-off-by: YH Huang 
> > > ---
> > >  drivers/power/sbs-battery.c |   22 --
> > >  1 file changed, 12 insertions(+), 10 deletions(-)
> > >
> > > diff --git a/drivers/power/sbs-battery.c b/drivers/power/sbs-battery.c
> > > index d6226d6..d86db0e 100644
> > > --- a/drivers/power/sbs-battery.c
> > > +++ b/drivers/power/sbs-battery.c
> > > @@ -382,11 +382,12 @@ static int sbs_get_battery_property(struct 
> > > i2c_client *client,
> > >
> > > if (ret & BATTERY_FULL_CHARGED)
> > > val->intval = POWER_SUPPLY_STATUS_FULL;
> > > -   else if (ret & BATTERY_FULL_DISCHARGED)
> > > -   val->intval = POWER_SUPPLY_STATUS_NOT_CHARGING;
> > > -   else if (ret & BATTERY_DISCHARGING)
> > > -   val->intval = POWER_SUPPLY_STATUS_DISCHARGING;
> > > -   else
> > > +   else if (ret & BATTERY_DISCHARGING) {
> > > +   if (ret & BATTERY_FULL_DISCHARGED)
> > > +   val->intval = 
> > > POWER_SUPPLY_STATUS_NOT_CHARGING;
> > > +   else
> > > +   val->intval = 
> > > POWER_SUPPLY_STATUS_DISCHARGING;
> > > +   } else
> >
> >
> > I think (BATTERY_DISCHARGING && BATTERY_FULL_DISCHARGED) is still
> > POWER_SUPPLY_STATUS_DISCHARGING.
> > So, let's just report what the battery says and do:
> >
> >else if (ret & BATTERY_DISCHARGING)
> >val->intval = 
> > POWER_SUPPLY_STATUS_DISCHARGING;
> >
> So we just ignore the special situation (BATTERY_DISCHARGING &&
> BATTERY_FULL_DISCHARGED).
> Isn't POWER_SUPPLY_STATUS_NOT_CHARGING a useful information?

The battery is discharging.  The fact that it is also reporting that
it is already "discharged" just seems premature.   I would expect to
only see NOT_CHARGING if completely discharged *and* not discharging.

>
>
> Regards,
> YH Huang
>


[PATCH] phy: twl4030-usb: fix musb-hdrc name for non-dt case

2016-03-24 Thread Ruslan Bilovol
musb device is allocated with PLATFORM_DEVID_AUTO, fix
incorrect lookup name in non-dt case.
This fixes issue with musb initialization on Nokia N900
in boardfile boot mode.

Signed-off-by: Ruslan Bilovol 
---
 drivers/phy/phy-twl4030-usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 840f3ea..a48214f 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -735,7 +735,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
}
 
if (pdata)
-   err = phy_create_lookup(phy, "usb", "musb-hdrc.0");
+   err = phy_create_lookup(phy, "usb", "musb-hdrc.0.auto");
if (err)
return err;
 
-- 
1.9.1



[PATCH] phy: twl4030-usb: fix musb-hdrc name for non-dt case

2016-03-24 Thread Ruslan Bilovol
musb device is allocated with PLATFORM_DEVID_AUTO, fix
incorrect lookup name in non-dt case.
This fixes issue with musb initialization on Nokia N900
in boardfile boot mode.

Signed-off-by: Ruslan Bilovol 
---
 drivers/phy/phy-twl4030-usb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/phy/phy-twl4030-usb.c b/drivers/phy/phy-twl4030-usb.c
index 840f3ea..a48214f 100644
--- a/drivers/phy/phy-twl4030-usb.c
+++ b/drivers/phy/phy-twl4030-usb.c
@@ -735,7 +735,7 @@ static int twl4030_usb_probe(struct platform_device *pdev)
}
 
if (pdata)
-   err = phy_create_lookup(phy, "usb", "musb-hdrc.0");
+   err = phy_create_lookup(phy, "usb", "musb-hdrc.0.auto");
if (err)
return err;
 
-- 
1.9.1



Re: [PATCH 2/2] ARM: sun7i: dt: Enable dram gate 5 (tve0 clock) for simplefb TV output

2016-03-24 Thread Chen-Yu Tsai
On Fri, Mar 25, 2016 at 2:08 AM, Priit Laes  wrote:
> From: Priit Laes 
>
> Seems like dram_gate 5 was forgotten when DRAM gating driver was added.
>
> Enable it.
>
> Signed-off-by: Priit Laes 


Fixes: 0b4bf5a5200b ("ARM: dts: sun7i: Add DRAM gates")

Thanks!

> ---
>  arch/arm/boot/dts/sun7i-a20.dtsi | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi 
> b/arch/arm/boot/dts/sun7i-a20.dtsi
> index 0940a78..ee4e8e7 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -85,8 +85,9 @@
> compatible = "allwinner,simple-framebuffer",
>  "simple-framebuffer";
> allwinner,pipeline = "de_be0-lcd0-tve0";
> -   clocks = < 1>, <_gates 34>, <_gates 36>,
> -<_gates 44>, <_gates 26>;
> +   clocks = < 1>,
> +<_gates 34>, <_gates 36>, 
> <_gates 44>,
> +<_gates 5>, <_gates 26>;
> status = "disabled";
> };
> };
> --
> 2.5.0
>


Re: [PATCH 2/2] ARM: sun7i: dt: Enable dram gate 5 (tve0 clock) for simplefb TV output

2016-03-24 Thread Chen-Yu Tsai
On Fri, Mar 25, 2016 at 2:08 AM, Priit Laes  wrote:
> From: Priit Laes 
>
> Seems like dram_gate 5 was forgotten when DRAM gating driver was added.
>
> Enable it.
>
> Signed-off-by: Priit Laes 


Fixes: 0b4bf5a5200b ("ARM: dts: sun7i: Add DRAM gates")

Thanks!

> ---
>  arch/arm/boot/dts/sun7i-a20.dtsi | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi 
> b/arch/arm/boot/dts/sun7i-a20.dtsi
> index 0940a78..ee4e8e7 100644
> --- a/arch/arm/boot/dts/sun7i-a20.dtsi
> +++ b/arch/arm/boot/dts/sun7i-a20.dtsi
> @@ -85,8 +85,9 @@
> compatible = "allwinner,simple-framebuffer",
>  "simple-framebuffer";
> allwinner,pipeline = "de_be0-lcd0-tve0";
> -   clocks = < 1>, <_gates 34>, <_gates 36>,
> -<_gates 44>, <_gates 26>;
> +   clocks = < 1>,
> +<_gates 34>, <_gates 36>, 
> <_gates 44>,
> +<_gates 5>, <_gates 26>;
> status = "disabled";
> };
> };
> --
> 2.5.0
>


Re: [PATCH 1/2] ARM: sun4i: dt: Enable dram gate 5 (tve0 clock) for simplefb TV output

2016-03-24 Thread Chen-Yu Tsai
On Fri, Mar 25, 2016 at 2:08 AM, Priit Laes  wrote:
> From: Priit Laes 
>
> Seems like dram_gate 5 was forgotten when DRAM gate driver was added.
>
> Enable it.
>
> Signed-off-by: Priit Laes 

Fixes: 82f8582feef4 ("ARM: dts: sun4i: Add DRAM gates")

Thanks!

> ---
>  arch/arm/boot/dts/sun4i-a10.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi 
> b/arch/arm/boot/dts/sun4i-a10.dtsi
> index 2c8f5e6..bf70d0a 100644
> --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> @@ -96,7 +96,7 @@
> allwinner,pipeline = "de_fe0-de_be0-lcd0-tve0";
> clocks = < 1>, <_gates 34>, <_gates 36>,
>  <_gates 44>, <_gates 46>,
> -<_gates 25>, <_gates 26>;
> +<_gates 5>, <_gates 25>, 
> <_gates 26>;
> status = "disabled";
> };
> };
> --
> 2.5.0
>


Re: [PATCH 1/2] ARM: sun4i: dt: Enable dram gate 5 (tve0 clock) for simplefb TV output

2016-03-24 Thread Chen-Yu Tsai
On Fri, Mar 25, 2016 at 2:08 AM, Priit Laes  wrote:
> From: Priit Laes 
>
> Seems like dram_gate 5 was forgotten when DRAM gate driver was added.
>
> Enable it.
>
> Signed-off-by: Priit Laes 

Fixes: 82f8582feef4 ("ARM: dts: sun4i: Add DRAM gates")

Thanks!

> ---
>  arch/arm/boot/dts/sun4i-a10.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm/boot/dts/sun4i-a10.dtsi 
> b/arch/arm/boot/dts/sun4i-a10.dtsi
> index 2c8f5e6..bf70d0a 100644
> --- a/arch/arm/boot/dts/sun4i-a10.dtsi
> +++ b/arch/arm/boot/dts/sun4i-a10.dtsi
> @@ -96,7 +96,7 @@
> allwinner,pipeline = "de_fe0-de_be0-lcd0-tve0";
> clocks = < 1>, <_gates 34>, <_gates 36>,
>  <_gates 44>, <_gates 46>,
> -<_gates 25>, <_gates 26>;
> +<_gates 5>, <_gates 25>, 
> <_gates 26>;
> status = "disabled";
> };
> };
> --
> 2.5.0
>


4.4: INFO: rcu_sched self-detected stall on CPU

2016-03-24 Thread Steven Haigh
Hi all,

Firstly, I've cross-posted this to xen-devel and the lkml - as this
problem seems to only exist when using kernel 4.4 as a Xen DomU kernel.
I have also CC'ed Greg KH for his awesome insight as maintainer.

Please CC myself into replies - as I'm not a member of the kernel
mailing list - I may miss replies from monitoring the archives.

I've noticed recently that heavy disk IO is causing rcu_sched to detect
stalls. The process mentioned usually goes to 100% CPU usage, and
eventually processes start segfaulting and dying. The only fix to
recover the system is to use 'xl destroy' to force-kill the VM and to
start it again.

The majority of these issues seem to mention ext4 in the trace. This may
indicate an issue there - or may be a red herring.

The gritty details:
INFO: rcu_sched self-detected stall on CPU
#0110-...: (20999 ticks this GP) idle=327/141/0
softirq=1101493/1101493 fqs=6973
#011 (t=21000 jiffies g=827095 c=827094 q=524)
Task dump for CPU 0:
rsync   R  running task0  2446   2444 0x0088
818d0c00 88007fc03c58 810a625f 
818d0c00 88007fc03c70 810a8699 0001
88007fc03ca0 810d0e5a 88007fc170c0 818d0c00
Call Trace:
  [] sched_show_task+0xaf/0x110
[] dump_cpu_task+0x39/0x40
[] rcu_dump_cpu_stacks+0x8a/0xc0
[] rcu_check_callbacks+0x424/0x7a0
[] ? account_system_time+0x81/0x110
[] ? account_process_tick+0x61/0x160
[] ? tick_sched_do_timer+0x30/0x30
[] update_process_times+0x39/0x60
[] tick_sched_handle.isra.15+0x36/0x50
[] tick_sched_timer+0x3d/0x70
[] __hrtimer_run_queues+0xf2/0x250
[] hrtimer_interrupt+0xa8/0x190
[] xen_timer_interrupt+0x2e/0x140
[] handle_irq_event_percpu+0x55/0x1e0
[] handle_percpu_irq+0x3a/0x50
[] generic_handle_irq+0x22/0x30
[] __evtchn_fifo_handle_events+0x15f/0x180
[] evtchn_fifo_handle_events+0x10/0x20
[] __xen_evtchn_do_upcall+0x43/0x80
[] xen_evtchn_do_upcall+0x30/0x50
[] xen_hvm_callback_vector+0x82/0x90
  [] ? queued_write_lock_slowpath+0x3d/0x80
[] _raw_write_lock+0x1e/0x30
[] ext4_es_remove_extent+0x43/0xc0
[] ext4_clear_inode+0x39/0x80
[] ext4_evict_inode+0x8d/0x4e0
[] evict+0xb7/0x180
[] dispose_list+0x36/0x50
[] prune_icache_sb+0x4b/0x60
[] super_cache_scan+0x141/0x190
[] shrink_slab.part.37+0x1ee/0x390
[] shrink_zone+0x26c/0x280
[] do_try_to_free_pages+0x15c/0x410
[] try_to_free_pages+0xba/0x170
[] __alloc_pages_nodemask+0x525/0xa60
[] ? kmem_cache_free+0xcc/0x2c0
[] alloc_pages_current+0x8d/0x120
[] __page_cache_alloc+0x91/0xc0
[] pagecache_get_page+0x56/0x1e0
[] grab_cache_page_write_begin+0x26/0x40
[] ext4_da_write_begin+0xa1/0x300
[] ? ext4_da_write_end+0x124/0x2b0
[] generic_perform_write+0xc0/0x1a0
[] __generic_file_write_iter+0x188/0x1e0
[] ext4_file_write_iter+0xf0/0x340
[] __vfs_write+0xaa/0xe0
[] vfs_write+0xa2/0x1a0
[] SyS_write+0x46/0xa0
[] entry_SYSCALL_64_fastpath+0x12/0x71

Some 11 hours later:
sshd[785]: segfault at 1f0 ip 7f03bb94ae5c sp 7ffe9eb54470 error
4 in ld-2.17.so[7f03bb94+21000]
sh[787]: segfault at 1f0 ip 7f6b4a0dfe5c sp 7ffe3d4a71e0 error 4
in ld-2.17.so[7f6b4a0d5000+21000]
systemd-cgroups[788]: segfault at 1f0 ip 7f4baa82ce5c sp
7ffd28e4c4b0 error 4 in ld-2.17.so[7f4baa822000+21000]
sshd[791]: segfault at 1f0 ip 7ff8c8a8ce5c sp 7ffede9e1c20 error
4 in ld-2.17.so[7ff8c8a82000+21000]
sshd[792]: segfault at 1f0 ip 7f183cf75e5c sp 7ffc81ab7160 error
4 in ld-2.17.so[7f183cf6b000+21000]
sshd[793]: segfault at 1f0 ip 7f3c665ece5c sp 7ffd9a13c850 error
4 in ld-2.17.so[7f3c665e2000+21000]

From isolated testing, this does not occur on kernel 4.5.x - however I
have not verified this myself.

The kernel config used can be found in the kernel-xen git repo if it
assists in debugging:
http://xen.crc.id.au/git/?p=kernel-xen;a=summary

-- 
Steven Haigh

Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897



signature.asc
Description: OpenPGP digital signature


4.4: INFO: rcu_sched self-detected stall on CPU

2016-03-24 Thread Steven Haigh
Hi all,

Firstly, I've cross-posted this to xen-devel and the lkml - as this
problem seems to only exist when using kernel 4.4 as a Xen DomU kernel.
I have also CC'ed Greg KH for his awesome insight as maintainer.

Please CC myself into replies - as I'm not a member of the kernel
mailing list - I may miss replies from monitoring the archives.

I've noticed recently that heavy disk IO is causing rcu_sched to detect
stalls. The process mentioned usually goes to 100% CPU usage, and
eventually processes start segfaulting and dying. The only fix to
recover the system is to use 'xl destroy' to force-kill the VM and to
start it again.

The majority of these issues seem to mention ext4 in the trace. This may
indicate an issue there - or may be a red herring.

The gritty details:
INFO: rcu_sched self-detected stall on CPU
#0110-...: (20999 ticks this GP) idle=327/141/0
softirq=1101493/1101493 fqs=6973
#011 (t=21000 jiffies g=827095 c=827094 q=524)
Task dump for CPU 0:
rsync   R  running task0  2446   2444 0x0088
818d0c00 88007fc03c58 810a625f 
818d0c00 88007fc03c70 810a8699 0001
88007fc03ca0 810d0e5a 88007fc170c0 818d0c00
Call Trace:
  [] sched_show_task+0xaf/0x110
[] dump_cpu_task+0x39/0x40
[] rcu_dump_cpu_stacks+0x8a/0xc0
[] rcu_check_callbacks+0x424/0x7a0
[] ? account_system_time+0x81/0x110
[] ? account_process_tick+0x61/0x160
[] ? tick_sched_do_timer+0x30/0x30
[] update_process_times+0x39/0x60
[] tick_sched_handle.isra.15+0x36/0x50
[] tick_sched_timer+0x3d/0x70
[] __hrtimer_run_queues+0xf2/0x250
[] hrtimer_interrupt+0xa8/0x190
[] xen_timer_interrupt+0x2e/0x140
[] handle_irq_event_percpu+0x55/0x1e0
[] handle_percpu_irq+0x3a/0x50
[] generic_handle_irq+0x22/0x30
[] __evtchn_fifo_handle_events+0x15f/0x180
[] evtchn_fifo_handle_events+0x10/0x20
[] __xen_evtchn_do_upcall+0x43/0x80
[] xen_evtchn_do_upcall+0x30/0x50
[] xen_hvm_callback_vector+0x82/0x90
  [] ? queued_write_lock_slowpath+0x3d/0x80
[] _raw_write_lock+0x1e/0x30
[] ext4_es_remove_extent+0x43/0xc0
[] ext4_clear_inode+0x39/0x80
[] ext4_evict_inode+0x8d/0x4e0
[] evict+0xb7/0x180
[] dispose_list+0x36/0x50
[] prune_icache_sb+0x4b/0x60
[] super_cache_scan+0x141/0x190
[] shrink_slab.part.37+0x1ee/0x390
[] shrink_zone+0x26c/0x280
[] do_try_to_free_pages+0x15c/0x410
[] try_to_free_pages+0xba/0x170
[] __alloc_pages_nodemask+0x525/0xa60
[] ? kmem_cache_free+0xcc/0x2c0
[] alloc_pages_current+0x8d/0x120
[] __page_cache_alloc+0x91/0xc0
[] pagecache_get_page+0x56/0x1e0
[] grab_cache_page_write_begin+0x26/0x40
[] ext4_da_write_begin+0xa1/0x300
[] ? ext4_da_write_end+0x124/0x2b0
[] generic_perform_write+0xc0/0x1a0
[] __generic_file_write_iter+0x188/0x1e0
[] ext4_file_write_iter+0xf0/0x340
[] __vfs_write+0xaa/0xe0
[] vfs_write+0xa2/0x1a0
[] SyS_write+0x46/0xa0
[] entry_SYSCALL_64_fastpath+0x12/0x71

Some 11 hours later:
sshd[785]: segfault at 1f0 ip 7f03bb94ae5c sp 7ffe9eb54470 error
4 in ld-2.17.so[7f03bb94+21000]
sh[787]: segfault at 1f0 ip 7f6b4a0dfe5c sp 7ffe3d4a71e0 error 4
in ld-2.17.so[7f6b4a0d5000+21000]
systemd-cgroups[788]: segfault at 1f0 ip 7f4baa82ce5c sp
7ffd28e4c4b0 error 4 in ld-2.17.so[7f4baa822000+21000]
sshd[791]: segfault at 1f0 ip 7ff8c8a8ce5c sp 7ffede9e1c20 error
4 in ld-2.17.so[7ff8c8a82000+21000]
sshd[792]: segfault at 1f0 ip 7f183cf75e5c sp 7ffc81ab7160 error
4 in ld-2.17.so[7f183cf6b000+21000]
sshd[793]: segfault at 1f0 ip 7f3c665ece5c sp 7ffd9a13c850 error
4 in ld-2.17.so[7f3c665e2000+21000]

From isolated testing, this does not occur on kernel 4.5.x - however I
have not verified this myself.

The kernel config used can be found in the kernel-xen git repo if it
assists in debugging:
http://xen.crc.id.au/git/?p=kernel-xen;a=summary

-- 
Steven Haigh

Email: net...@crc.id.au
Web: https://www.crc.id.au
Phone: (03) 9001 6090 - 0412 935 897



signature.asc
Description: OpenPGP digital signature


[PATCH v2] netpoll: Fix extra refcount release in netpoll_cleanup()

2016-03-24 Thread Bjorn Helgaas
netpoll_setup() does a dev_hold() on np->dev, the netpoll device.  If it
fails, it correctly does a dev_put() but leaves np->dev set.  If we call
netpoll_cleanup() after the failure, np->dev is still set so we do another
dev_put(), which decrements the refcount an extra time.

It's questionable to call netpoll_cleanup() after netpoll_setup() fails,
but it can be difficult to find the problem, and we can easily avoid it in
this case.  The extra decrements can lead to hangs like this:

  unregister_netdevice: waiting for bond0 to become free. Usage count = -3

Set and clear np->dev at the points where we dev_hold() and dev_put() the
device.

Signed-off-by: Bjorn Helgaas 
---
 net/core/netpoll.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 94acfc8..a57bd17 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -603,7 +603,6 @@ int __netpoll_setup(struct netpoll *np, struct net_device 
*ndev)
const struct net_device_ops *ops;
int err;
 
-   np->dev = ndev;
strlcpy(np->dev_name, ndev->name, IFNAMSIZ);
INIT_WORK(>cleanup_work, netpoll_async_cleanup);
 
@@ -670,6 +669,7 @@ int netpoll_setup(struct netpoll *np)
goto unlock;
}
dev_hold(ndev);
+   np->dev = ndev;
 
if (netdev_master_upper_dev_get(ndev)) {
np_err(np, "%s is a slave device, aborting\n", np->dev_name);
@@ -770,6 +770,7 @@ int netpoll_setup(struct netpoll *np)
return 0;
 
 put:
+   np->dev = NULL;
dev_put(ndev);
 unlock:
rtnl_unlock();



[PATCH v2] netpoll: Fix extra refcount release in netpoll_cleanup()

2016-03-24 Thread Bjorn Helgaas
netpoll_setup() does a dev_hold() on np->dev, the netpoll device.  If it
fails, it correctly does a dev_put() but leaves np->dev set.  If we call
netpoll_cleanup() after the failure, np->dev is still set so we do another
dev_put(), which decrements the refcount an extra time.

It's questionable to call netpoll_cleanup() after netpoll_setup() fails,
but it can be difficult to find the problem, and we can easily avoid it in
this case.  The extra decrements can lead to hangs like this:

  unregister_netdevice: waiting for bond0 to become free. Usage count = -3

Set and clear np->dev at the points where we dev_hold() and dev_put() the
device.

Signed-off-by: Bjorn Helgaas 
---
 net/core/netpoll.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 94acfc8..a57bd17 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -603,7 +603,6 @@ int __netpoll_setup(struct netpoll *np, struct net_device 
*ndev)
const struct net_device_ops *ops;
int err;
 
-   np->dev = ndev;
strlcpy(np->dev_name, ndev->name, IFNAMSIZ);
INIT_WORK(>cleanup_work, netpoll_async_cleanup);
 
@@ -670,6 +669,7 @@ int netpoll_setup(struct netpoll *np)
goto unlock;
}
dev_hold(ndev);
+   np->dev = ndev;
 
if (netdev_master_upper_dev_get(ndev)) {
np_err(np, "%s is a slave device, aborting\n", np->dev_name);
@@ -770,6 +770,7 @@ int netpoll_setup(struct netpoll *np)
return 0;
 
 put:
+   np->dev = NULL;
dev_put(ndev);
 unlock:
rtnl_unlock();



Re: [PATCH 0/5] drivers/mtd: make several functions return bool

2016-03-24 Thread Dongsheng Yang

ccing: Brian and Richard

Hi Yao,
Is that really necessary? I am not sure how much benefit we can 
achieve from this change.

Could you explain more?

Yang

On 03/25/2016 10:41 AM, Yaowei Bai wrote:

This series only make several funcitons return bool to improve
readability, no other funcitonal changes.

Yaowei Bai (5):
   drivers/mtd: mtd_is_partition can be boolean
   drivers/mtd: cfi_interleave_supported can be boolean
   drivers/mtd: map_bankwidth_supported can be boolean
   drivers/mtd: mtd_nand_has_bch can be boolean
   drivers/mtd/nand: nand_opcode_8bits can be boolean

  drivers/mtd/mtdpart.c  | 6 +++---
  include/linux/mtd/cfi.h| 6 +++---
  include/linux/mtd/map.h| 6 +++---
  include/linux/mtd/nand.h   | 6 +++---
  include/linux/mtd/nand_bch.h   | 4 ++--
  include/linux/mtd/partitions.h | 2 +-
  6 files changed, 15 insertions(+), 15 deletions(-)





Re: [PATCH 0/5] drivers/mtd: make several functions return bool

2016-03-24 Thread Dongsheng Yang

ccing: Brian and Richard

Hi Yao,
Is that really necessary? I am not sure how much benefit we can 
achieve from this change.

Could you explain more?

Yang

On 03/25/2016 10:41 AM, Yaowei Bai wrote:

This series only make several funcitons return bool to improve
readability, no other funcitonal changes.

Yaowei Bai (5):
   drivers/mtd: mtd_is_partition can be boolean
   drivers/mtd: cfi_interleave_supported can be boolean
   drivers/mtd: map_bankwidth_supported can be boolean
   drivers/mtd: mtd_nand_has_bch can be boolean
   drivers/mtd/nand: nand_opcode_8bits can be boolean

  drivers/mtd/mtdpart.c  | 6 +++---
  include/linux/mtd/cfi.h| 6 +++---
  include/linux/mtd/map.h| 6 +++---
  include/linux/mtd/nand.h   | 6 +++---
  include/linux/mtd/nand_bch.h   | 4 ++--
  include/linux/mtd/partitions.h | 2 +-
  6 files changed, 15 insertions(+), 15 deletions(-)





[PATCH net-next] phy: keep the BCMR_LOOPBACK bit while setup forced mode

2016-03-24 Thread Weidong Wang
When tested the PHY SGMII Loopback,:
1.set the LOOPBACK bit,
2.set the autoneg to AUTONEG_DISABLE, it calls the
genphy_setup_forced which will clear the bit.

So just keep the LOOPBACK bit while setup forced mode.

Signed-off-by: Weidong Wang 
---
 drivers/net/phy/phy_device.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index e551f3a..8da4b80 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1124,7 +1124,9 @@ static int genphy_config_advert(struct phy_device *phydev)
 int genphy_setup_forced(struct phy_device *phydev)
 {
int ctl = 0;
+   int val = phy_read(phydev, MII_BMCR);

+   ctl |= val & BMCR_LOOPBACK;
phydev->pause = 0;
phydev->asym_pause = 0;

-- 
2.7.0




[PATCH net-next] phy: keep the BCMR_LOOPBACK bit while setup forced mode

2016-03-24 Thread Weidong Wang
When tested the PHY SGMII Loopback,:
1.set the LOOPBACK bit,
2.set the autoneg to AUTONEG_DISABLE, it calls the
genphy_setup_forced which will clear the bit.

So just keep the LOOPBACK bit while setup forced mode.

Signed-off-by: Weidong Wang 
---
 drivers/net/phy/phy_device.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
index e551f3a..8da4b80 100644
--- a/drivers/net/phy/phy_device.c
+++ b/drivers/net/phy/phy_device.c
@@ -1124,7 +1124,9 @@ static int genphy_config_advert(struct phy_device *phydev)
 int genphy_setup_forced(struct phy_device *phydev)
 {
int ctl = 0;
+   int val = phy_read(phydev, MII_BMCR);

+   ctl |= val & BMCR_LOOPBACK;
phydev->pause = 0;
phydev->asym_pause = 0;

-- 
2.7.0




[PATCH 2/2] staging: dgnc: fix Logical continuations should be on the

2016-03-24 Thread Daeseok Youn
fix checkpatch.pl warning about 'Logical continuations
should be on the previous line' in dgnc_neo.c file.

I think the 'force' need to check first, because if the 'force' is true,
it doesn't need to call another function call.

Signed-off-by: Daeseok Youn 
---
 drivers/staging/dgnc/dgnc_neo.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index 10b596f..d732e6e 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -359,8 +359,8 @@ static inline void neo_clear_break(struct channel_t *ch, 
int force)
 
/* Turn break off, and unset some variables */
if (ch->ch_flags & CH_BREAK_SENDING) {
-   if (time_after_eq(jiffies, ch->ch_stop_sending_break)
-   || force) {
+   if (force ||
+   time_after_eq(jiffies, ch->ch_stop_sending_break)) {
unsigned char temp = readb(>ch_neo_uart->lcr);
 
writeb((temp & ~UART_LCR_SBC), >ch_neo_uart->lcr);
-- 
1.9.1



[PATCH 2/2] staging: dgnc: fix Logical continuations should be on the

2016-03-24 Thread Daeseok Youn
fix checkpatch.pl warning about 'Logical continuations
should be on the previous line' in dgnc_neo.c file.

I think the 'force' need to check first, because if the 'force' is true,
it doesn't need to call another function call.

Signed-off-by: Daeseok Youn 
---
 drivers/staging/dgnc/dgnc_neo.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index 10b596f..d732e6e 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -359,8 +359,8 @@ static inline void neo_clear_break(struct channel_t *ch, 
int force)
 
/* Turn break off, and unset some variables */
if (ch->ch_flags & CH_BREAK_SENDING) {
-   if (time_after_eq(jiffies, ch->ch_stop_sending_break)
-   || force) {
+   if (force ||
+   time_after_eq(jiffies, ch->ch_stop_sending_break)) {
unsigned char temp = readb(>ch_neo_uart->lcr);
 
writeb((temp & ~UART_LCR_SBC), >ch_neo_uart->lcr);
-- 
1.9.1



Re: [PATCH 0/2] arm64: cpuidle: make arm_cpuidle_suspend() more efficient

2016-03-24 Thread Jisheng Zhang
Hi Lorenzo,

On Thu, 24 Mar 2016 16:44:19 +
Lorenzo Pieralisi  wrote:

> On Thu, Mar 24, 2016 at 09:18:53PM +0800, Jisheng Zhang wrote:
> > Hi Will,
> > 
> > On Thu, 24 Mar 2016 11:15:07 + Will Deacon wrote:
> >   
> > > On Thu, Mar 24, 2016 at 01:08:48PM +0800, Jisheng Zhang wrote:  
> > > > This series is to improve the arm_cpuidle_suspend() a bit by 
> > > > removing/moving
> > > > out checks from this hot path.
> > > > 
> > > > Jisheng Zhang (2):
> > > >   arm64: cpuidle: remove cpu_ops check from arm_cpuidle_suspend()
> > > >   arm64: cpuidle: make arm_cpuidle_suspend() a bit more efficient
> > > > 
> > > >  arch/arm64/kernel/cpuidle.c | 9 ++---
> > > >  1 file changed, 2 insertions(+), 7 deletions(-)
> > > 
> > > These look fine to me, but do you have any rough numbers showing what
> > > sort of improvement we get from this change?  
> > 
> > Good question. Here it is:
> > 
> > I measured the 4096 * time from arm_cpuidle_suspend entry point to the
> > cpu_psci_cpu_suspend entry point. HW platform is Marvell BG4CT STB board.
> > 
> > 1. only one shell, no other process, hot-unplug secondary cpus, execute the
> > following cmd
> > 
> > while true
> > do
> > sleep 0.2
> > done
> > 
> > before the patch: 1581220ns
> > 
> > after the patch: 1579630ns
> > 
> > reduced by 0.1%
> > 
> > 2. only one shell, no other process, hot-unplug secondary cpus, execute the
> > following cmd
> > 
> > while true
> > do
> > md5sum /tmp/testfile
> > sleep 0.2
> > done
> > 
> > NOTE the testfile size should be larger than L1+L2 cache size
> > 
> > before the patch: 1961960ns
> > after the patch: 1912500ns
> > 
> > reduced by 2.5%
> > 
> > So the more complex the system load, the bigger the improvement.  
> 
> So between arm_cpuidle_suspend() and psci_cpu_suspend_enter() the
> checks that you are removing are almost the *only* code that is
> currently executed and this patch saves us best case 12ns per idle state
> entry (which is noise compared to CPU PM notifiers/FW execution time)
> if I am not mistaken, I can't wait to use that energy for something more
> useful :)
> 
> Anyway, as a clean-up your patches are fine it is sloppy to check those
> pointers on every idle state entry (do you really need two patches ?), so:

hmm, yes, it makes more sense to combined them into one patch.

> 
> Acked-by: Lorenzo Pieralisi 

Thanks for reviewing,
Jisheng


Re: [PATCH 0/2] arm64: cpuidle: make arm_cpuidle_suspend() more efficient

2016-03-24 Thread Jisheng Zhang
Hi Lorenzo,

On Thu, 24 Mar 2016 16:44:19 +
Lorenzo Pieralisi  wrote:

> On Thu, Mar 24, 2016 at 09:18:53PM +0800, Jisheng Zhang wrote:
> > Hi Will,
> > 
> > On Thu, 24 Mar 2016 11:15:07 + Will Deacon wrote:
> >   
> > > On Thu, Mar 24, 2016 at 01:08:48PM +0800, Jisheng Zhang wrote:  
> > > > This series is to improve the arm_cpuidle_suspend() a bit by 
> > > > removing/moving
> > > > out checks from this hot path.
> > > > 
> > > > Jisheng Zhang (2):
> > > >   arm64: cpuidle: remove cpu_ops check from arm_cpuidle_suspend()
> > > >   arm64: cpuidle: make arm_cpuidle_suspend() a bit more efficient
> > > > 
> > > >  arch/arm64/kernel/cpuidle.c | 9 ++---
> > > >  1 file changed, 2 insertions(+), 7 deletions(-)
> > > 
> > > These look fine to me, but do you have any rough numbers showing what
> > > sort of improvement we get from this change?  
> > 
> > Good question. Here it is:
> > 
> > I measured the 4096 * time from arm_cpuidle_suspend entry point to the
> > cpu_psci_cpu_suspend entry point. HW platform is Marvell BG4CT STB board.
> > 
> > 1. only one shell, no other process, hot-unplug secondary cpus, execute the
> > following cmd
> > 
> > while true
> > do
> > sleep 0.2
> > done
> > 
> > before the patch: 1581220ns
> > 
> > after the patch: 1579630ns
> > 
> > reduced by 0.1%
> > 
> > 2. only one shell, no other process, hot-unplug secondary cpus, execute the
> > following cmd
> > 
> > while true
> > do
> > md5sum /tmp/testfile
> > sleep 0.2
> > done
> > 
> > NOTE the testfile size should be larger than L1+L2 cache size
> > 
> > before the patch: 1961960ns
> > after the patch: 1912500ns
> > 
> > reduced by 2.5%
> > 
> > So the more complex the system load, the bigger the improvement.  
> 
> So between arm_cpuidle_suspend() and psci_cpu_suspend_enter() the
> checks that you are removing are almost the *only* code that is
> currently executed and this patch saves us best case 12ns per idle state
> entry (which is noise compared to CPU PM notifiers/FW execution time)
> if I am not mistaken, I can't wait to use that energy for something more
> useful :)
> 
> Anyway, as a clean-up your patches are fine it is sloppy to check those
> pointers on every idle state entry (do you really need two patches ?), so:

hmm, yes, it makes more sense to combined them into one patch.

> 
> Acked-by: Lorenzo Pieralisi 

Thanks for reviewing,
Jisheng


[PATCH 1/2] staging: dgnc: fix 'line over 80 characters'

2016-03-24 Thread Daeseok Youn
fix checkpatch.pl warning about 'line over 80 characters'
in dgnc_neo.c

Signed-off-by: Daeseok Youn 
---
 drivers/staging/dgnc/dgnc_neo.c | 66 +++--
 1 file changed, 44 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index 31ac437..10b596f 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -77,7 +77,8 @@ struct board_ops dgnc_neo_ops = {
.send_immediate_char =  neo_send_immediate_char
 };
 
-static uint dgnc_offset_table[8] = { 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 
0x80 };
+static uint dgnc_offset_table[8] = { 0x01, 0x02, 0x04, 0x08,
+0x10, 0x20, 0x40, 0x80 };
 
 /*
  * This function allows calls to ensure that all outstanding
@@ -116,7 +117,8 @@ static inline void neo_set_cts_flow_control(struct 
channel_t *ch)
writeb(efr, >ch_neo_uart->efr);
 
/* Turn on table D, with 8 char hi/low watermarks */
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY), 
>ch_neo_uart->fctr);
+   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY),
+   >ch_neo_uart->fctr);
 
/* Feed the UART our trigger levels */
writeb(8, >ch_neo_uart->tfifo);
@@ -150,7 +152,8 @@ static inline void neo_set_rts_flow_control(struct 
channel_t *ch)
/* Turn on UART enhanced bits */
writeb(efr, >ch_neo_uart->efr);
 
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY), 
>ch_neo_uart->fctr);
+   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY),
+   >ch_neo_uart->fctr);
ch->ch_r_watermark = 4;
 
writeb(32, >ch_neo_uart->rfifo);
@@ -187,7 +190,8 @@ static inline void neo_set_ixon_flow_control(struct 
channel_t *ch)
/* Turn on UART enhanced bits */
writeb(efr, >ch_neo_uart->efr);
 
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY), 
>ch_neo_uart->fctr);
+   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY),
+  >ch_neo_uart->fctr);
ch->ch_r_watermark = 4;
 
writeb(32, >ch_neo_uart->rfifo);
@@ -225,7 +229,8 @@ static inline void neo_set_ixoff_flow_control(struct 
channel_t *ch)
writeb(efr, >ch_neo_uart->efr);
 
/* Turn on table D, with 8 char hi/low watermarks */
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY), 
>ch_neo_uart->fctr);
+   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY),
+   >ch_neo_uart->fctr);
 
writeb(8, >ch_neo_uart->tfifo);
ch->ch_t_tlevel = 8;
@@ -265,7 +270,8 @@ static inline void neo_set_no_input_flow_control(struct 
channel_t *ch)
writeb(efr, >ch_neo_uart->efr);
 
/* Turn on table D, with 8 char hi/low watermarks */
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY), 
>ch_neo_uart->fctr);
+   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY),
+   >ch_neo_uart->fctr);
 
ch->ch_r_watermark = 0;
 
@@ -302,7 +308,8 @@ static inline void neo_set_no_output_flow_control(struct 
channel_t *ch)
writeb(efr, >ch_neo_uart->efr);
 
/* Turn on table D, with 8 char hi/low watermarks */
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY), 
>ch_neo_uart->fctr);
+   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY),
+   >ch_neo_uart->fctr);
 
ch->ch_r_watermark = 0;
 
@@ -321,7 +328,8 @@ static inline void neo_set_no_output_flow_control(struct 
channel_t *ch)
 static inline void neo_set_new_start_stop_chars(struct channel_t *ch)
 {
/* if hardware flow control is set, then skip this whole thing */
-   if (ch->ch_digi.digi_flags & (CTSPACE | RTSPACE) || ch->ch_c_cflag & 
CRTSCTS)
+   if (ch->ch_digi.digi_flags & (CTSPACE | RTSPACE) ||
+   ch->ch_c_cflag & CRTSCTS)
return;
 
/* Tell UART what start/stop chars it should be looking for */
@@ -393,7 +401,8 @@ static inline void neo_parse_isr(struct dgnc_board *brd, 
uint port)
break;
 
/*
-* Yank off the upper 2 bits, which just show that the FIFO's 
are enabled.
+* Yank off the upper 2 bits,
+* which just show that the FIFO's are enabled.
 */
isr &= ~(UART_17158_IIR_FIFO_ENABLED);
 
@@ -666,7 +675,8 @@ static void neo_param(struct tty_struct *tty)
};
 
/* Only use the TXPrint baud rate if the terminal unit is NOT 
open */
-   if (!(ch->ch_tun.un_flags & UN_ISOPEN) && (un->un_type == 
DGNC_PRINT))
+   if (!(ch->ch_tun.un_flags & UN_ISOPEN) &&
+   (un->un_type == DGNC_PRINT))
baud = C_BAUD(ch->ch_pun.un_tty) & 0xff;
else
baud = C_BAUD(ch->ch_tun.un_tty) & 0xff;
@@ -679,7 +689,8 @@ 

[PATCH 1/2] staging: dgnc: fix 'line over 80 characters'

2016-03-24 Thread Daeseok Youn
fix checkpatch.pl warning about 'line over 80 characters'
in dgnc_neo.c

Signed-off-by: Daeseok Youn 
---
 drivers/staging/dgnc/dgnc_neo.c | 66 +++--
 1 file changed, 44 insertions(+), 22 deletions(-)

diff --git a/drivers/staging/dgnc/dgnc_neo.c b/drivers/staging/dgnc/dgnc_neo.c
index 31ac437..10b596f 100644
--- a/drivers/staging/dgnc/dgnc_neo.c
+++ b/drivers/staging/dgnc/dgnc_neo.c
@@ -77,7 +77,8 @@ struct board_ops dgnc_neo_ops = {
.send_immediate_char =  neo_send_immediate_char
 };
 
-static uint dgnc_offset_table[8] = { 0x01, 0x02, 0x04, 0x08, 0x10, 0x20, 0x40, 
0x80 };
+static uint dgnc_offset_table[8] = { 0x01, 0x02, 0x04, 0x08,
+0x10, 0x20, 0x40, 0x80 };
 
 /*
  * This function allows calls to ensure that all outstanding
@@ -116,7 +117,8 @@ static inline void neo_set_cts_flow_control(struct 
channel_t *ch)
writeb(efr, >ch_neo_uart->efr);
 
/* Turn on table D, with 8 char hi/low watermarks */
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY), 
>ch_neo_uart->fctr);
+   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY),
+   >ch_neo_uart->fctr);
 
/* Feed the UART our trigger levels */
writeb(8, >ch_neo_uart->tfifo);
@@ -150,7 +152,8 @@ static inline void neo_set_rts_flow_control(struct 
channel_t *ch)
/* Turn on UART enhanced bits */
writeb(efr, >ch_neo_uart->efr);
 
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY), 
>ch_neo_uart->fctr);
+   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_4DELAY),
+   >ch_neo_uart->fctr);
ch->ch_r_watermark = 4;
 
writeb(32, >ch_neo_uart->rfifo);
@@ -187,7 +190,8 @@ static inline void neo_set_ixon_flow_control(struct 
channel_t *ch)
/* Turn on UART enhanced bits */
writeb(efr, >ch_neo_uart->efr);
 
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY), 
>ch_neo_uart->fctr);
+   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY),
+  >ch_neo_uart->fctr);
ch->ch_r_watermark = 4;
 
writeb(32, >ch_neo_uart->rfifo);
@@ -225,7 +229,8 @@ static inline void neo_set_ixoff_flow_control(struct 
channel_t *ch)
writeb(efr, >ch_neo_uart->efr);
 
/* Turn on table D, with 8 char hi/low watermarks */
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY), 
>ch_neo_uart->fctr);
+   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY),
+   >ch_neo_uart->fctr);
 
writeb(8, >ch_neo_uart->tfifo);
ch->ch_t_tlevel = 8;
@@ -265,7 +270,8 @@ static inline void neo_set_no_input_flow_control(struct 
channel_t *ch)
writeb(efr, >ch_neo_uart->efr);
 
/* Turn on table D, with 8 char hi/low watermarks */
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY), 
>ch_neo_uart->fctr);
+   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY),
+   >ch_neo_uart->fctr);
 
ch->ch_r_watermark = 0;
 
@@ -302,7 +308,8 @@ static inline void neo_set_no_output_flow_control(struct 
channel_t *ch)
writeb(efr, >ch_neo_uart->efr);
 
/* Turn on table D, with 8 char hi/low watermarks */
-   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY), 
>ch_neo_uart->fctr);
+   writeb((UART_17158_FCTR_TRGD | UART_17158_FCTR_RTS_8DELAY),
+   >ch_neo_uart->fctr);
 
ch->ch_r_watermark = 0;
 
@@ -321,7 +328,8 @@ static inline void neo_set_no_output_flow_control(struct 
channel_t *ch)
 static inline void neo_set_new_start_stop_chars(struct channel_t *ch)
 {
/* if hardware flow control is set, then skip this whole thing */
-   if (ch->ch_digi.digi_flags & (CTSPACE | RTSPACE) || ch->ch_c_cflag & 
CRTSCTS)
+   if (ch->ch_digi.digi_flags & (CTSPACE | RTSPACE) ||
+   ch->ch_c_cflag & CRTSCTS)
return;
 
/* Tell UART what start/stop chars it should be looking for */
@@ -393,7 +401,8 @@ static inline void neo_parse_isr(struct dgnc_board *brd, 
uint port)
break;
 
/*
-* Yank off the upper 2 bits, which just show that the FIFO's 
are enabled.
+* Yank off the upper 2 bits,
+* which just show that the FIFO's are enabled.
 */
isr &= ~(UART_17158_IIR_FIFO_ENABLED);
 
@@ -666,7 +675,8 @@ static void neo_param(struct tty_struct *tty)
};
 
/* Only use the TXPrint baud rate if the terminal unit is NOT 
open */
-   if (!(ch->ch_tun.un_flags & UN_ISOPEN) && (un->un_type == 
DGNC_PRINT))
+   if (!(ch->ch_tun.un_flags & UN_ISOPEN) &&
+   (un->un_type == DGNC_PRINT))
baud = C_BAUD(ch->ch_pun.un_tty) & 0xff;
else
baud = C_BAUD(ch->ch_tun.un_tty) & 0xff;
@@ -679,7 +689,8 @@ static void 

[PATCH 1/5] drivers/mtd: mtd_is_partition can be boolean

2016-03-24 Thread Yaowei Bai
This patch makes mtd_is_partition return bool to improve
readability due to this particular function only using either
one or zero as its return value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 drivers/mtd/mtdpart.c  | 6 +++---
 include/linux/mtd/partitions.h | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 10bf304..1aae1f4 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -829,15 +829,15 @@ void mtd_part_parser_cleanup(struct mtd_partitions *parts)
}
 }
 
-int mtd_is_partition(const struct mtd_info *mtd)
+bool mtd_is_partition(const struct mtd_info *mtd)
 {
struct mtd_part *part;
-   int ispart = 0;
+   bool ispart = false;
 
mutex_lock(_partitions_mutex);
list_for_each_entry(part, _partitions, list)
if (>mtd == mtd) {
-   ispart = 1;
+   ispart = true;
break;
}
mutex_unlock(_partitions_mutex);
diff --git a/include/linux/mtd/partitions.h b/include/linux/mtd/partitions.h
index 70736e1..042f3be 100644
--- a/include/linux/mtd/partitions.h
+++ b/include/linux/mtd/partitions.h
@@ -96,7 +96,7 @@ extern void deregister_mtd_parser(struct mtd_part_parser 
*parser);
module_driver(__mtd_part_parser, register_mtd_parser, \
  deregister_mtd_parser)
 
-int mtd_is_partition(const struct mtd_info *mtd);
+bool mtd_is_partition(const struct mtd_info *mtd);
 int mtd_add_partition(struct mtd_info *master, const char *name,
  long long offset, long long length);
 int mtd_del_partition(struct mtd_info *master, int partno);
-- 
1.9.1





[PATCH 2/5] drivers/mtd: cfi_interleave_supported can be boolean

2016-03-24 Thread Yaowei Bai
This patch makes cfi_interleave_supported return bool due to this
particular function only using either one or zero as its return
value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/mtd/cfi.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/mtd/cfi.h b/include/linux/mtd/cfi.h
index 9b57a9b..68323bc 100644
--- a/include/linux/mtd/cfi.h
+++ b/include/linux/mtd/cfi.h
@@ -81,7 +81,7 @@ static inline int cfi_interleave(void *cfi)
 }
 #endif
 
-static inline int cfi_interleave_supported(int i)
+static inline bool cfi_interleave_supported(int i)
 {
switch (i) {
 #ifdef CONFIG_MTD_CFI_I1
@@ -96,10 +96,10 @@ static inline int cfi_interleave_supported(int i)
 #ifdef CONFIG_MTD_CFI_I8
case 8:
 #endif
-   return 1;
+   return true;
 
default:
-   return 0;
+   return false;
}
 }
 
-- 
1.9.1





[PATCH 3/5] drivers/mtd: map_bankwidth_supported can be boolean

2016-03-24 Thread Yaowei Bai
This patch makes map_bankwidth_supported return bool due to this
particular function only using either one or zero as its return
value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/mtd/map.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h
index 58f3ba7..130a1b3 100644
--- a/include/linux/mtd/map.h
+++ b/include/linux/mtd/map.h
@@ -155,7 +155,7 @@ static inline int map_bankwidth(void *map)
 #define MAX_MAP_BANKWIDTH 1
 #endif
 
-static inline int map_bankwidth_supported(int w)
+static inline bool map_bankwidth_supported(int w)
 {
switch (w) {
 #ifdef CONFIG_MTD_MAP_BANK_WIDTH_1
@@ -176,10 +176,10 @@ static inline int map_bankwidth_supported(int w)
 #ifdef CONFIG_MTD_MAP_BANK_WIDTH_32
case 32:
 #endif
-   return 1;
+   return true;
 
default:
-   return 0;
+   return false;
}
 }
 
-- 
1.9.1





[PATCH 1/5] drivers/mtd: mtd_is_partition can be boolean

2016-03-24 Thread Yaowei Bai
This patch makes mtd_is_partition return bool to improve
readability due to this particular function only using either
one or zero as its return value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 drivers/mtd/mtdpart.c  | 6 +++---
 include/linux/mtd/partitions.h | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c
index 10bf304..1aae1f4 100644
--- a/drivers/mtd/mtdpart.c
+++ b/drivers/mtd/mtdpart.c
@@ -829,15 +829,15 @@ void mtd_part_parser_cleanup(struct mtd_partitions *parts)
}
 }
 
-int mtd_is_partition(const struct mtd_info *mtd)
+bool mtd_is_partition(const struct mtd_info *mtd)
 {
struct mtd_part *part;
-   int ispart = 0;
+   bool ispart = false;
 
mutex_lock(_partitions_mutex);
list_for_each_entry(part, _partitions, list)
if (>mtd == mtd) {
-   ispart = 1;
+   ispart = true;
break;
}
mutex_unlock(_partitions_mutex);
diff --git a/include/linux/mtd/partitions.h b/include/linux/mtd/partitions.h
index 70736e1..042f3be 100644
--- a/include/linux/mtd/partitions.h
+++ b/include/linux/mtd/partitions.h
@@ -96,7 +96,7 @@ extern void deregister_mtd_parser(struct mtd_part_parser 
*parser);
module_driver(__mtd_part_parser, register_mtd_parser, \
  deregister_mtd_parser)
 
-int mtd_is_partition(const struct mtd_info *mtd);
+bool mtd_is_partition(const struct mtd_info *mtd);
 int mtd_add_partition(struct mtd_info *master, const char *name,
  long long offset, long long length);
 int mtd_del_partition(struct mtd_info *master, int partno);
-- 
1.9.1





[PATCH 2/5] drivers/mtd: cfi_interleave_supported can be boolean

2016-03-24 Thread Yaowei Bai
This patch makes cfi_interleave_supported return bool due to this
particular function only using either one or zero as its return
value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/mtd/cfi.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/mtd/cfi.h b/include/linux/mtd/cfi.h
index 9b57a9b..68323bc 100644
--- a/include/linux/mtd/cfi.h
+++ b/include/linux/mtd/cfi.h
@@ -81,7 +81,7 @@ static inline int cfi_interleave(void *cfi)
 }
 #endif
 
-static inline int cfi_interleave_supported(int i)
+static inline bool cfi_interleave_supported(int i)
 {
switch (i) {
 #ifdef CONFIG_MTD_CFI_I1
@@ -96,10 +96,10 @@ static inline int cfi_interleave_supported(int i)
 #ifdef CONFIG_MTD_CFI_I8
case 8:
 #endif
-   return 1;
+   return true;
 
default:
-   return 0;
+   return false;
}
 }
 
-- 
1.9.1





[PATCH 3/5] drivers/mtd: map_bankwidth_supported can be boolean

2016-03-24 Thread Yaowei Bai
This patch makes map_bankwidth_supported return bool due to this
particular function only using either one or zero as its return
value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/mtd/map.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/mtd/map.h b/include/linux/mtd/map.h
index 58f3ba7..130a1b3 100644
--- a/include/linux/mtd/map.h
+++ b/include/linux/mtd/map.h
@@ -155,7 +155,7 @@ static inline int map_bankwidth(void *map)
 #define MAX_MAP_BANKWIDTH 1
 #endif
 
-static inline int map_bankwidth_supported(int w)
+static inline bool map_bankwidth_supported(int w)
 {
switch (w) {
 #ifdef CONFIG_MTD_MAP_BANK_WIDTH_1
@@ -176,10 +176,10 @@ static inline int map_bankwidth_supported(int w)
 #ifdef CONFIG_MTD_MAP_BANK_WIDTH_32
case 32:
 #endif
-   return 1;
+   return true;
 
default:
-   return 0;
+   return false;
}
 }
 
-- 
1.9.1





[PATCH 5/5] drivers/mtd/nand: nand_opcode_8bits can be boolean

2016-03-24 Thread Yaowei Bai
This patch makes nand_opcode_8bits return bool due to this
particular function only using either one or zero as its return
value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/mtd/nand.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index bdd68e2..dd79eae 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -989,18 +989,18 @@ static inline bool nand_is_slc(struct nand_chip *chip)
  * Check if the opcode's address should be sent only on the lower 8 bits
  * @command: opcode to check
  */
-static inline int nand_opcode_8bits(unsigned int command)
+static inline bool nand_opcode_8bits(unsigned int command)
 {
switch (command) {
case NAND_CMD_READID:
case NAND_CMD_PARAM:
case NAND_CMD_GET_FEATURES:
case NAND_CMD_SET_FEATURES:
-   return 1;
+   return true;
default:
break;
}
-   return 0;
+   return false;
 }
 
 /* return the supported JEDEC features. */
-- 
1.9.1





[PATCH 5/5] drivers/mtd/nand: nand_opcode_8bits can be boolean

2016-03-24 Thread Yaowei Bai
This patch makes nand_opcode_8bits return bool due to this
particular function only using either one or zero as its return
value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/mtd/nand.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/linux/mtd/nand.h b/include/linux/mtd/nand.h
index bdd68e2..dd79eae 100644
--- a/include/linux/mtd/nand.h
+++ b/include/linux/mtd/nand.h
@@ -989,18 +989,18 @@ static inline bool nand_is_slc(struct nand_chip *chip)
  * Check if the opcode's address should be sent only on the lower 8 bits
  * @command: opcode to check
  */
-static inline int nand_opcode_8bits(unsigned int command)
+static inline bool nand_opcode_8bits(unsigned int command)
 {
switch (command) {
case NAND_CMD_READID:
case NAND_CMD_PARAM:
case NAND_CMD_GET_FEATURES:
case NAND_CMD_SET_FEATURES:
-   return 1;
+   return true;
default:
break;
}
-   return 0;
+   return false;
 }
 
 /* return the supported JEDEC features. */
-- 
1.9.1





[PATCH 0/5] drivers/mtd: make several functions return bool

2016-03-24 Thread Yaowei Bai
This series only make several funcitons return bool to improve
readability, no other funcitonal changes.

Yaowei Bai (5):
  drivers/mtd: mtd_is_partition can be boolean
  drivers/mtd: cfi_interleave_supported can be boolean
  drivers/mtd: map_bankwidth_supported can be boolean
  drivers/mtd: mtd_nand_has_bch can be boolean
  drivers/mtd/nand: nand_opcode_8bits can be boolean

 drivers/mtd/mtdpart.c  | 6 +++---
 include/linux/mtd/cfi.h| 6 +++---
 include/linux/mtd/map.h| 6 +++---
 include/linux/mtd/nand.h   | 6 +++---
 include/linux/mtd/nand_bch.h   | 4 ++--
 include/linux/mtd/partitions.h | 2 +-
 6 files changed, 15 insertions(+), 15 deletions(-)

-- 
1.9.1





[PATCH 4/5] drivers/mtd: mtd_nand_has_bch can be boolean

2016-03-24 Thread Yaowei Bai
This patch makes mtd_nand_has_bch return bool to improve readability
due to this particular function only using either one or zero as its return
value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/mtd/nand_bch.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/mtd/nand_bch.h b/include/linux/mtd/nand_bch.h
index fb0bc34..8778c79 100644
--- a/include/linux/mtd/nand_bch.h
+++ b/include/linux/mtd/nand_bch.h
@@ -16,7 +16,7 @@ struct nand_bch_control;
 
 #if defined(CONFIG_MTD_NAND_ECC_BCH)
 
-static inline int mtd_nand_has_bch(void) { return 1; }
+static inline bool mtd_nand_has_bch(void) { return true; }
 
 /*
  * Calculate BCH ecc code
@@ -42,7 +42,7 @@ void nand_bch_free(struct nand_bch_control *nbc);
 
 #else /* !CONFIG_MTD_NAND_ECC_BCH */
 
-static inline int mtd_nand_has_bch(void) { return 0; }
+static inline bool mtd_nand_has_bch(void) { return false; }
 
 static inline int
 nand_bch_calculate_ecc(struct mtd_info *mtd, const u_char *dat,
-- 
1.9.1





[PATCH 0/5] drivers/mtd: make several functions return bool

2016-03-24 Thread Yaowei Bai
This series only make several funcitons return bool to improve
readability, no other funcitonal changes.

Yaowei Bai (5):
  drivers/mtd: mtd_is_partition can be boolean
  drivers/mtd: cfi_interleave_supported can be boolean
  drivers/mtd: map_bankwidth_supported can be boolean
  drivers/mtd: mtd_nand_has_bch can be boolean
  drivers/mtd/nand: nand_opcode_8bits can be boolean

 drivers/mtd/mtdpart.c  | 6 +++---
 include/linux/mtd/cfi.h| 6 +++---
 include/linux/mtd/map.h| 6 +++---
 include/linux/mtd/nand.h   | 6 +++---
 include/linux/mtd/nand_bch.h   | 4 ++--
 include/linux/mtd/partitions.h | 2 +-
 6 files changed, 15 insertions(+), 15 deletions(-)

-- 
1.9.1





[PATCH 4/5] drivers/mtd: mtd_nand_has_bch can be boolean

2016-03-24 Thread Yaowei Bai
This patch makes mtd_nand_has_bch return bool to improve readability
due to this particular function only using either one or zero as its return
value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/mtd/nand_bch.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/mtd/nand_bch.h b/include/linux/mtd/nand_bch.h
index fb0bc34..8778c79 100644
--- a/include/linux/mtd/nand_bch.h
+++ b/include/linux/mtd/nand_bch.h
@@ -16,7 +16,7 @@ struct nand_bch_control;
 
 #if defined(CONFIG_MTD_NAND_ECC_BCH)
 
-static inline int mtd_nand_has_bch(void) { return 1; }
+static inline bool mtd_nand_has_bch(void) { return true; }
 
 /*
  * Calculate BCH ecc code
@@ -42,7 +42,7 @@ void nand_bch_free(struct nand_bch_control *nbc);
 
 #else /* !CONFIG_MTD_NAND_ECC_BCH */
 
-static inline int mtd_nand_has_bch(void) { return 0; }
+static inline bool mtd_nand_has_bch(void) { return false; }
 
 static inline int
 nand_bch_calculate_ecc(struct mtd_info *mtd, const u_char *dat,
-- 
1.9.1





Re: linux-next: Tree for Mar 24 (events/amd/power)

2016-03-24 Thread Huang Rui
On Thu, Mar 24, 2016 at 10:05:03AM -0700, Randy Dunlap wrote:
> On 03/23/16 19:09, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Please do not add any v4.7 related material to your linux-next included
> > trees until after v4.6-rc1 is released.
> > 
> > Changes since 20160323:
> > 
> 
> on i386:
> 
> when CONFIG_CPU_SUP_INTEL is not enabled:
> 
> In file included from ../include/linux/kobject.h:21:0,
>  from ../include/linux/module.h:17,
>  from ../arch/x86/events/amd/power.c:13:
> ../arch/x86/events/amd/../perf_event.h:660:31: error: 'events_sysfs_show' 
> undeclared here (not in a function)
>   .attr  = __ATTR(_name, 0444, events_sysfs_show, NULL), \
>^
> ../include/linux/sysfs.h:103:10: note: in definition of macro '__ATTR'
>   .show = _show,  \
>   ^
> ../arch/x86/events/amd/power.c:181:1: note: in expansion of macro 
> 'EVENT_ATTR_STR'
>  EVENT_ATTR_STR(power-pkg, power_pkg, "event=0x01");
>  ^
> ../scripts/Makefile.build:291: recipe for target 
> 'arch/x86/events/amd/power.o' failed
> 

Randy, thanks to report it.
Actually, because one patch is missed to apply.

https://git.kernel.org/cgit/linux/kernel/git/bp/bp.git/commit/?h=tip-perf=f5ba42d22cb478d32363b2b8e92e14b1fd190ce1

I will rebase and re-send it.

Thanks,
Rui


Re: linux-next: Tree for Mar 24 (events/amd/power)

2016-03-24 Thread Huang Rui
On Thu, Mar 24, 2016 at 10:05:03AM -0700, Randy Dunlap wrote:
> On 03/23/16 19:09, Stephen Rothwell wrote:
> > Hi all,
> > 
> > Please do not add any v4.7 related material to your linux-next included
> > trees until after v4.6-rc1 is released.
> > 
> > Changes since 20160323:
> > 
> 
> on i386:
> 
> when CONFIG_CPU_SUP_INTEL is not enabled:
> 
> In file included from ../include/linux/kobject.h:21:0,
>  from ../include/linux/module.h:17,
>  from ../arch/x86/events/amd/power.c:13:
> ../arch/x86/events/amd/../perf_event.h:660:31: error: 'events_sysfs_show' 
> undeclared here (not in a function)
>   .attr  = __ATTR(_name, 0444, events_sysfs_show, NULL), \
>^
> ../include/linux/sysfs.h:103:10: note: in definition of macro '__ATTR'
>   .show = _show,  \
>   ^
> ../arch/x86/events/amd/power.c:181:1: note: in expansion of macro 
> 'EVENT_ATTR_STR'
>  EVENT_ATTR_STR(power-pkg, power_pkg, "event=0x01");
>  ^
> ../scripts/Makefile.build:291: recipe for target 
> 'arch/x86/events/amd/power.o' failed
> 

Randy, thanks to report it.
Actually, because one patch is missed to apply.

https://git.kernel.org/cgit/linux/kernel/git/bp/bp.git/commit/?h=tip-perf=f5ba42d22cb478d32363b2b8e92e14b1fd190ce1

I will rebase and re-send it.

Thanks,
Rui


[RFC PATCH V2 1/2] vhost: convert pre sorted vhost memory array to interval tree

2016-03-24 Thread Jason Wang
Current pre-sorted memory region array has some limitations for future
device IOTLB conversion:

1) need extra work for adding and removing a single region, and it's
   expected to be slow because of sorting or memory re-allocation.
2) need extra work of removing a large range which may intersect
   several regions with different size.
3) need trick for a replacement policy like LRU

To overcome the above shortcomings, this patch convert it to interval
tree which can easily address the above issue with almost no extra
work.

The patch could be used for:

- Extend the current API and only let the userspace to send diffs of
  memory table.
- Simplify Device IOTLB implementation.

Signed-off-by: Jason Wang 
---
 drivers/vhost/net.c   |   8 +--
 drivers/vhost/vhost.c | 182 --
 drivers/vhost/vhost.h |  27 ++--
 3 files changed, 128 insertions(+), 89 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 9eda69e..481db96 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -968,20 +968,20 @@ static long vhost_net_reset_owner(struct vhost_net *n)
struct socket *tx_sock = NULL;
struct socket *rx_sock = NULL;
long err;
-   struct vhost_memory *memory;
+   struct vhost_umem *umem;
 
mutex_lock(>dev.mutex);
err = vhost_dev_check_owner(>dev);
if (err)
goto done;
-   memory = vhost_dev_reset_owner_prepare();
-   if (!memory) {
+   umem = vhost_dev_reset_owner_prepare();
+   if (!umem) {
err = -ENOMEM;
goto done;
}
vhost_net_stop(n, _sock, _sock);
vhost_net_flush(n);
-   vhost_dev_reset_owner(>dev, memory);
+   vhost_dev_reset_owner(>dev, umem);
vhost_net_vq_reset(n);
 done:
mutex_unlock(>dev.mutex);
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index ad2146a..32c35a9 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "vhost.h"
 
@@ -42,6 +43,10 @@ enum {
 #define vhost_used_event(vq) ((__virtio16 __user *)>avail->ring[vq->num])
 #define vhost_avail_event(vq) ((__virtio16 __user *)>used->ring[vq->num])
 
+INTERVAL_TREE_DEFINE(struct vhost_umem_node,
+rb, __u64, __subtree_last,
+START, LAST, , vhost_umem_interval_tree);
+
 #ifdef CONFIG_VHOST_CROSS_ENDIAN_LEGACY
 static void vhost_vq_reset_user_be(struct vhost_virtqueue *vq)
 {
@@ -275,7 +280,7 @@ static void vhost_vq_reset(struct vhost_dev *dev,
vq->call_ctx = NULL;
vq->call = NULL;
vq->log_ctx = NULL;
-   vq->memory = NULL;
+   vq->umem = NULL;
vq->is_le = virtio_legacy_is_little_endian();
vhost_vq_reset_user_be(vq);
 }
@@ -381,7 +386,7 @@ void vhost_dev_init(struct vhost_dev *dev,
mutex_init(>mutex);
dev->log_ctx = NULL;
dev->log_file = NULL;
-   dev->memory = NULL;
+   dev->umem = NULL;
dev->mm = NULL;
spin_lock_init(>work_lock);
INIT_LIST_HEAD(>work_list);
@@ -486,27 +491,36 @@ err_mm:
 }
 EXPORT_SYMBOL_GPL(vhost_dev_set_owner);
 
-struct vhost_memory *vhost_dev_reset_owner_prepare(void)
+static void *vhost_kvzalloc(unsigned long size)
+{
+   void *n = kzalloc(size, GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT);
+
+   if (!n)
+   n = vzalloc(size);
+   return n;
+}
+
+struct vhost_umem *vhost_dev_reset_owner_prepare(void)
 {
-   return kmalloc(offsetof(struct vhost_memory, regions), GFP_KERNEL);
+   return vhost_kvzalloc(sizeof(struct vhost_umem));
 }
 EXPORT_SYMBOL_GPL(vhost_dev_reset_owner_prepare);
 
 /* Caller should have device mutex */
-void vhost_dev_reset_owner(struct vhost_dev *dev, struct vhost_memory *memory)
+void vhost_dev_reset_owner(struct vhost_dev *dev, struct vhost_umem *umem)
 {
int i;
 
vhost_dev_cleanup(dev, true);
 
/* Restore memory to default empty mapping. */
-   memory->nregions = 0;
-   dev->memory = memory;
+   INIT_LIST_HEAD(>umem_list);
+   dev->umem = umem;
/* We don't need VQ locks below since vhost_dev_cleanup makes sure
 * VQs aren't running.
 */
for (i = 0; i < dev->nvqs; ++i)
-   dev->vqs[i]->memory = memory;
+   dev->vqs[i]->umem = umem;
 }
 EXPORT_SYMBOL_GPL(vhost_dev_reset_owner);
 
@@ -523,6 +537,21 @@ void vhost_dev_stop(struct vhost_dev *dev)
 }
 EXPORT_SYMBOL_GPL(vhost_dev_stop);
 
+static void vhost_umem_clean(struct vhost_umem *umem)
+{
+   struct vhost_umem_node *node, *tmp;
+
+   if (!umem)
+   return;
+
+   list_for_each_entry_safe(node, tmp, >umem_list, link) {
+   vhost_umem_interval_tree_remove(node, >umem_tree);
+   list_del(>link);
+   kvfree(node);
+   }
+   kvfree(umem);
+}
+
 /* Caller should have device mutex if and 

[RFC PATCH V2 1/2] vhost: convert pre sorted vhost memory array to interval tree

2016-03-24 Thread Jason Wang
Current pre-sorted memory region array has some limitations for future
device IOTLB conversion:

1) need extra work for adding and removing a single region, and it's
   expected to be slow because of sorting or memory re-allocation.
2) need extra work of removing a large range which may intersect
   several regions with different size.
3) need trick for a replacement policy like LRU

To overcome the above shortcomings, this patch convert it to interval
tree which can easily address the above issue with almost no extra
work.

The patch could be used for:

- Extend the current API and only let the userspace to send diffs of
  memory table.
- Simplify Device IOTLB implementation.

Signed-off-by: Jason Wang 
---
 drivers/vhost/net.c   |   8 +--
 drivers/vhost/vhost.c | 182 --
 drivers/vhost/vhost.h |  27 ++--
 3 files changed, 128 insertions(+), 89 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 9eda69e..481db96 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -968,20 +968,20 @@ static long vhost_net_reset_owner(struct vhost_net *n)
struct socket *tx_sock = NULL;
struct socket *rx_sock = NULL;
long err;
-   struct vhost_memory *memory;
+   struct vhost_umem *umem;
 
mutex_lock(>dev.mutex);
err = vhost_dev_check_owner(>dev);
if (err)
goto done;
-   memory = vhost_dev_reset_owner_prepare();
-   if (!memory) {
+   umem = vhost_dev_reset_owner_prepare();
+   if (!umem) {
err = -ENOMEM;
goto done;
}
vhost_net_stop(n, _sock, _sock);
vhost_net_flush(n);
-   vhost_dev_reset_owner(>dev, memory);
+   vhost_dev_reset_owner(>dev, umem);
vhost_net_vq_reset(n);
 done:
mutex_unlock(>dev.mutex);
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index ad2146a..32c35a9 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "vhost.h"
 
@@ -42,6 +43,10 @@ enum {
 #define vhost_used_event(vq) ((__virtio16 __user *)>avail->ring[vq->num])
 #define vhost_avail_event(vq) ((__virtio16 __user *)>used->ring[vq->num])
 
+INTERVAL_TREE_DEFINE(struct vhost_umem_node,
+rb, __u64, __subtree_last,
+START, LAST, , vhost_umem_interval_tree);
+
 #ifdef CONFIG_VHOST_CROSS_ENDIAN_LEGACY
 static void vhost_vq_reset_user_be(struct vhost_virtqueue *vq)
 {
@@ -275,7 +280,7 @@ static void vhost_vq_reset(struct vhost_dev *dev,
vq->call_ctx = NULL;
vq->call = NULL;
vq->log_ctx = NULL;
-   vq->memory = NULL;
+   vq->umem = NULL;
vq->is_le = virtio_legacy_is_little_endian();
vhost_vq_reset_user_be(vq);
 }
@@ -381,7 +386,7 @@ void vhost_dev_init(struct vhost_dev *dev,
mutex_init(>mutex);
dev->log_ctx = NULL;
dev->log_file = NULL;
-   dev->memory = NULL;
+   dev->umem = NULL;
dev->mm = NULL;
spin_lock_init(>work_lock);
INIT_LIST_HEAD(>work_list);
@@ -486,27 +491,36 @@ err_mm:
 }
 EXPORT_SYMBOL_GPL(vhost_dev_set_owner);
 
-struct vhost_memory *vhost_dev_reset_owner_prepare(void)
+static void *vhost_kvzalloc(unsigned long size)
+{
+   void *n = kzalloc(size, GFP_KERNEL | __GFP_NOWARN | __GFP_REPEAT);
+
+   if (!n)
+   n = vzalloc(size);
+   return n;
+}
+
+struct vhost_umem *vhost_dev_reset_owner_prepare(void)
 {
-   return kmalloc(offsetof(struct vhost_memory, regions), GFP_KERNEL);
+   return vhost_kvzalloc(sizeof(struct vhost_umem));
 }
 EXPORT_SYMBOL_GPL(vhost_dev_reset_owner_prepare);
 
 /* Caller should have device mutex */
-void vhost_dev_reset_owner(struct vhost_dev *dev, struct vhost_memory *memory)
+void vhost_dev_reset_owner(struct vhost_dev *dev, struct vhost_umem *umem)
 {
int i;
 
vhost_dev_cleanup(dev, true);
 
/* Restore memory to default empty mapping. */
-   memory->nregions = 0;
-   dev->memory = memory;
+   INIT_LIST_HEAD(>umem_list);
+   dev->umem = umem;
/* We don't need VQ locks below since vhost_dev_cleanup makes sure
 * VQs aren't running.
 */
for (i = 0; i < dev->nvqs; ++i)
-   dev->vqs[i]->memory = memory;
+   dev->vqs[i]->umem = umem;
 }
 EXPORT_SYMBOL_GPL(vhost_dev_reset_owner);
 
@@ -523,6 +537,21 @@ void vhost_dev_stop(struct vhost_dev *dev)
 }
 EXPORT_SYMBOL_GPL(vhost_dev_stop);
 
+static void vhost_umem_clean(struct vhost_umem *umem)
+{
+   struct vhost_umem_node *node, *tmp;
+
+   if (!umem)
+   return;
+
+   list_for_each_entry_safe(node, tmp, >umem_list, link) {
+   vhost_umem_interval_tree_remove(node, >umem_tree);
+   list_del(>link);
+   kvfree(node);
+   }
+   kvfree(umem);
+}
+
 /* Caller should have device mutex if and only if locked is set 

[RFC PATCH V2 2/2] vhost: device IOTLB API

2016-03-24 Thread Jason Wang
This patch tries to implement an device IOTLB for vhost. This could be
used with for co-operation with userspace(qemu) implementation of DMA
remapping.

The idea is simple. When vhost meets an IOTLB miss, it will request
the assistance of userspace to do the translation, this is done
through:

- Fill the translation request in a preset userspace address (This
  address is set through ioctl VHOST_SET_IOTLB_REQUEST_ENTRY).
- Notify userspace through eventfd (This eventfd was set through ioctl
  VHOST_SET_IOTLB_FD).
- device IOTLB were started and stopped through VHOST_RUN_IOTLB ioctl

When userspace finishes the translation, it will update the vhost
IOTLB through VHOST_UPDATE_IOTLB ioctl. Userspace is also in charge of
snooping the IOTLB invalidation of IOMMU IOTLB and use
VHOST_UPDATE_IOTLB to invalidate the possible entry in vhost.

Signed-off-by: Jason Wang 
---
 drivers/vhost/net.c|   6 +-
 drivers/vhost/vhost.c  | 301 +++--
 drivers/vhost/vhost.h  |  17 ++-
 fs/eventfd.c   |   3 +-
 include/uapi/linux/vhost.h |  35 ++
 5 files changed, 320 insertions(+), 42 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 481db96..7cbdeed 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -334,7 +334,7 @@ static void handle_tx(struct vhost_net *net)
head = vhost_get_vq_desc(vq, vq->iov,
 ARRAY_SIZE(vq->iov),
 , ,
-NULL, NULL);
+NULL, NULL, VHOST_ACCESS_RO);
/* On error, stop handling until the next kick. */
if (unlikely(head < 0))
break;
@@ -470,7 +470,7 @@ static int get_rx_bufs(struct vhost_virtqueue *vq,
}
r = vhost_get_vq_desc(vq, vq->iov + seg,
  ARRAY_SIZE(vq->iov) - seg, ,
- , log, log_num);
+ , log, log_num, VHOST_ACCESS_WO);
if (unlikely(r < 0))
goto err;
 
@@ -1083,7 +1083,7 @@ static long vhost_net_ioctl(struct file *f, unsigned int 
ioctl,
r = vhost_dev_ioctl(>dev, ioctl, argp);
if (r == -ENOIOCTLCMD)
r = vhost_vring_ioctl(>dev, ioctl, argp);
-   else
+   else if (ioctl != VHOST_UPDATE_IOTLB)
vhost_net_flush(n);
mutex_unlock(>dev.mutex);
return r;
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 32c35a9..1dd43e8 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -280,6 +280,10 @@ static void vhost_vq_reset(struct vhost_dev *dev,
vq->call_ctx = NULL;
vq->call = NULL;
vq->log_ctx = NULL;
+   vq->iotlb_call = NULL;
+   vq->iotlb_call_ctx = NULL;
+   vq->iotlb_request = NULL;
+   vq->pending_request.flags.type = VHOST_IOTLB_INVALIDATE;
vq->umem = NULL;
vq->is_le = virtio_legacy_is_little_endian();
vhost_vq_reset_user_be(vq);
@@ -387,8 +391,10 @@ void vhost_dev_init(struct vhost_dev *dev,
dev->log_ctx = NULL;
dev->log_file = NULL;
dev->umem = NULL;
+   dev->iotlb = NULL;
dev->mm = NULL;
spin_lock_init(>work_lock);
+   spin_lock_init(>iotlb_lock);
INIT_LIST_HEAD(>work_list);
dev->worker = NULL;
 
@@ -537,6 +543,15 @@ void vhost_dev_stop(struct vhost_dev *dev)
 }
 EXPORT_SYMBOL_GPL(vhost_dev_stop);
 
+static void vhost_umem_free(struct vhost_umem *umem,
+   struct vhost_umem_node *node)
+{
+   vhost_umem_interval_tree_remove(node, >umem_tree);
+   list_del(>link);
+   kfree(node);
+   umem->numem--;
+}
+
 static void vhost_umem_clean(struct vhost_umem *umem)
 {
struct vhost_umem_node *node, *tmp;
@@ -544,11 +559,9 @@ static void vhost_umem_clean(struct vhost_umem *umem)
if (!umem)
return;
 
-   list_for_each_entry_safe(node, tmp, >umem_list, link) {
-   vhost_umem_interval_tree_remove(node, >umem_tree);
-   list_del(>link);
-   kvfree(node);
-   }
+   list_for_each_entry_safe(node, tmp, >umem_list, link)
+   vhost_umem_free(umem, node);
+
kvfree(umem);
 }
 
@@ -580,6 +593,8 @@ void vhost_dev_cleanup(struct vhost_dev *dev, bool locked)
/* No one will access memory at this point */
vhost_umem_clean(dev->umem);
dev->umem = NULL;
+   vhost_umem_clean(dev->iotlb);
+   dev->iotlb = NULL;
WARN_ON(!list_empty(>work_list));
if (dev->worker) {
kthread_stop(dev->worker);
@@ -699,11 +714,61 @@ int vhost_vq_access_ok(struct vhost_virtqueue *vq)
 }
 EXPORT_SYMBOL_GPL(vhost_vq_access_ok);
 
+static int 

[RFC PATCH V2 0/2] basic device IOTLB support

2016-03-24 Thread Jason Wang
This patch tries to implement an device IOTLB for vhost. This could be
used with for co-operation with userspace(qemu) implementation of
iommu for a secure DMA environment (DMAR) in guest.

The idea is simple. When vhost meets an IOTLB miss, it will request
the assistance of userspace to do the translation, this is done
through:

- Fill the translation request in a preset userspace address (This
  address is set through ioctl VHOST_SET_IOTLB_REQUEST_ENTRY).
- Notify userspace through eventfd (This eventfd was set through ioctl
  VHOST_SET_IOTLB_FD).

When userspace finishes the translation, it will update the vhost
IOTLB through VHOST_UPDATE_IOTLB ioctl. Userspace is also in charge of
snooping the IOTLB invalidation of IOMMU IOTLB and use
VHOST_UPDATE_IOTLB to invalidate the possible entry in vhost.

The codes were designed to be architecture independent. It should be
easily ported to any architecture.

Changes from V1:
- support any size/range of updating and invalidation through
  introducing the interval tree.
- convert from per device iotlb request to per virtqueue iotlb
  request, this solves the possible deadlock in V1.
- read/write permission check support.

Please review.

Thanks

Jason Wang (2):
  vhost: convert pre sorted vhost memory array to interval tree
  vhost: device IOTLB API

 drivers/vhost/net.c|  14 +-
 drivers/vhost/vhost.c  | 427 +++--
 drivers/vhost/vhost.h  |  42 -
 fs/eventfd.c   |   3 +-
 include/uapi/linux/vhost.h |  35 
 5 files changed, 419 insertions(+), 102 deletions(-)

-- 
2.5.0



[RFC PATCH V2 2/2] vhost: device IOTLB API

2016-03-24 Thread Jason Wang
This patch tries to implement an device IOTLB for vhost. This could be
used with for co-operation with userspace(qemu) implementation of DMA
remapping.

The idea is simple. When vhost meets an IOTLB miss, it will request
the assistance of userspace to do the translation, this is done
through:

- Fill the translation request in a preset userspace address (This
  address is set through ioctl VHOST_SET_IOTLB_REQUEST_ENTRY).
- Notify userspace through eventfd (This eventfd was set through ioctl
  VHOST_SET_IOTLB_FD).
- device IOTLB were started and stopped through VHOST_RUN_IOTLB ioctl

When userspace finishes the translation, it will update the vhost
IOTLB through VHOST_UPDATE_IOTLB ioctl. Userspace is also in charge of
snooping the IOTLB invalidation of IOMMU IOTLB and use
VHOST_UPDATE_IOTLB to invalidate the possible entry in vhost.

Signed-off-by: Jason Wang 
---
 drivers/vhost/net.c|   6 +-
 drivers/vhost/vhost.c  | 301 +++--
 drivers/vhost/vhost.h  |  17 ++-
 fs/eventfd.c   |   3 +-
 include/uapi/linux/vhost.h |  35 ++
 5 files changed, 320 insertions(+), 42 deletions(-)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 481db96..7cbdeed 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -334,7 +334,7 @@ static void handle_tx(struct vhost_net *net)
head = vhost_get_vq_desc(vq, vq->iov,
 ARRAY_SIZE(vq->iov),
 , ,
-NULL, NULL);
+NULL, NULL, VHOST_ACCESS_RO);
/* On error, stop handling until the next kick. */
if (unlikely(head < 0))
break;
@@ -470,7 +470,7 @@ static int get_rx_bufs(struct vhost_virtqueue *vq,
}
r = vhost_get_vq_desc(vq, vq->iov + seg,
  ARRAY_SIZE(vq->iov) - seg, ,
- , log, log_num);
+ , log, log_num, VHOST_ACCESS_WO);
if (unlikely(r < 0))
goto err;
 
@@ -1083,7 +1083,7 @@ static long vhost_net_ioctl(struct file *f, unsigned int 
ioctl,
r = vhost_dev_ioctl(>dev, ioctl, argp);
if (r == -ENOIOCTLCMD)
r = vhost_vring_ioctl(>dev, ioctl, argp);
-   else
+   else if (ioctl != VHOST_UPDATE_IOTLB)
vhost_net_flush(n);
mutex_unlock(>dev.mutex);
return r;
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 32c35a9..1dd43e8 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -280,6 +280,10 @@ static void vhost_vq_reset(struct vhost_dev *dev,
vq->call_ctx = NULL;
vq->call = NULL;
vq->log_ctx = NULL;
+   vq->iotlb_call = NULL;
+   vq->iotlb_call_ctx = NULL;
+   vq->iotlb_request = NULL;
+   vq->pending_request.flags.type = VHOST_IOTLB_INVALIDATE;
vq->umem = NULL;
vq->is_le = virtio_legacy_is_little_endian();
vhost_vq_reset_user_be(vq);
@@ -387,8 +391,10 @@ void vhost_dev_init(struct vhost_dev *dev,
dev->log_ctx = NULL;
dev->log_file = NULL;
dev->umem = NULL;
+   dev->iotlb = NULL;
dev->mm = NULL;
spin_lock_init(>work_lock);
+   spin_lock_init(>iotlb_lock);
INIT_LIST_HEAD(>work_list);
dev->worker = NULL;
 
@@ -537,6 +543,15 @@ void vhost_dev_stop(struct vhost_dev *dev)
 }
 EXPORT_SYMBOL_GPL(vhost_dev_stop);
 
+static void vhost_umem_free(struct vhost_umem *umem,
+   struct vhost_umem_node *node)
+{
+   vhost_umem_interval_tree_remove(node, >umem_tree);
+   list_del(>link);
+   kfree(node);
+   umem->numem--;
+}
+
 static void vhost_umem_clean(struct vhost_umem *umem)
 {
struct vhost_umem_node *node, *tmp;
@@ -544,11 +559,9 @@ static void vhost_umem_clean(struct vhost_umem *umem)
if (!umem)
return;
 
-   list_for_each_entry_safe(node, tmp, >umem_list, link) {
-   vhost_umem_interval_tree_remove(node, >umem_tree);
-   list_del(>link);
-   kvfree(node);
-   }
+   list_for_each_entry_safe(node, tmp, >umem_list, link)
+   vhost_umem_free(umem, node);
+
kvfree(umem);
 }
 
@@ -580,6 +593,8 @@ void vhost_dev_cleanup(struct vhost_dev *dev, bool locked)
/* No one will access memory at this point */
vhost_umem_clean(dev->umem);
dev->umem = NULL;
+   vhost_umem_clean(dev->iotlb);
+   dev->iotlb = NULL;
WARN_ON(!list_empty(>work_list));
if (dev->worker) {
kthread_stop(dev->worker);
@@ -699,11 +714,61 @@ int vhost_vq_access_ok(struct vhost_virtqueue *vq)
 }
 EXPORT_SYMBOL_GPL(vhost_vq_access_ok);
 
+static int 

[RFC PATCH V2 0/2] basic device IOTLB support

2016-03-24 Thread Jason Wang
This patch tries to implement an device IOTLB for vhost. This could be
used with for co-operation with userspace(qemu) implementation of
iommu for a secure DMA environment (DMAR) in guest.

The idea is simple. When vhost meets an IOTLB miss, it will request
the assistance of userspace to do the translation, this is done
through:

- Fill the translation request in a preset userspace address (This
  address is set through ioctl VHOST_SET_IOTLB_REQUEST_ENTRY).
- Notify userspace through eventfd (This eventfd was set through ioctl
  VHOST_SET_IOTLB_FD).

When userspace finishes the translation, it will update the vhost
IOTLB through VHOST_UPDATE_IOTLB ioctl. Userspace is also in charge of
snooping the IOTLB invalidation of IOMMU IOTLB and use
VHOST_UPDATE_IOTLB to invalidate the possible entry in vhost.

The codes were designed to be architecture independent. It should be
easily ported to any architecture.

Changes from V1:
- support any size/range of updating and invalidation through
  introducing the interval tree.
- convert from per device iotlb request to per virtqueue iotlb
  request, this solves the possible deadlock in V1.
- read/write permission check support.

Please review.

Thanks

Jason Wang (2):
  vhost: convert pre sorted vhost memory array to interval tree
  vhost: device IOTLB API

 drivers/vhost/net.c|  14 +-
 drivers/vhost/vhost.c  | 427 +++--
 drivers/vhost/vhost.h  |  42 -
 fs/eventfd.c   |   3 +-
 include/uapi/linux/vhost.h |  35 
 5 files changed, 419 insertions(+), 102 deletions(-)

-- 
2.5.0



Re: [PATCH 4/3] rtmutex: Avoid barrier in rt_mutex_handle_deadlock

2016-03-24 Thread Davidlohr Bueso

Adding a few more Cc's for bcache.

On Tue, 22 Mar 2016, Peter Zijlstra wrote:


On Mon, Mar 21, 2016 at 11:16:22AM -0700, Davidlohr Bueso wrote:


+/*
+ * Helpers for modifying the state of either the current task, or a foreign
+ * task. Each of these calls come in both full barrier and weak flavors:
+ *
+ *   Weak
+ * set_task_state()   __set_task_state()
+ * set_current_state()__set_current_state()
+ *
+ * Where set_current_state() and set_task_state() includes a full smp barrier
+ * -after- the write of ->state is correctly serialized with the later test
+ * of whether to actually sleep:
+ *
+ * for (;;) {
+ * set_current_state(TASK_UNINTERRUPTIBLE);
+ * if (event_indicated)
+ * break;
+ * schedule();
+ * }
+ *
+ * This is commonly necessary for processes sleeping and waking through flag
+ * based events. If the caller does not need such serialization, then use
+ * weaker counterparts, which simply writes the state.
+ *
+ * Refer to Documentation/memory-barriers.txt
+ */


I would prefer to pretend set_task_state() does not exist, using it on
anything other than task==current is very very tricky.

With the below patch; we're only left with:

arch/s390/mm/fault.c:   __set_task_state(tsk, 
TASK_UNINTERRUPTIBLE);
arch/s390/mm/fault.c:   __set_task_state(tsk, 
TASK_UNINTERRUPTIBLE);
drivers/md/bcache/btree.c:  set_task_state(c->gc_thread, 
TASK_INTERRUPTIBLE);
kernel/exit.c:  set_task_state(tsk, TASK_UNINTERRUPTIBLE);
kernel/exit.c:  __set_task_state(tsk, TASK_RUNNING);

exit most probably also has tsk==current, but I didn't check.


Right, and only user is do_exit -> exit_mm() which is always current.



bacache seems to rely on the fact that the task is not running after
kthread_create() to change the state. But I've no idea why; the only
think I can come up with is because load accounting, a new thread blocks
in UNINTERRUPTIBLE which adds to load. But by setting it to
INTERRUPTIBLE before waking up it can actually mess that up. This really
should be fixed.


No idea why either.



And s390 does something entirely vile, no idea what.


So this is solved.

I'll send an updated patch based on this one that removes set_task_state 
iff we get rid of the bcache situation obviously.


Thanks,
Davidlohr



---
arch/um/drivers/random.c |  2 +-
drivers/md/dm-bufio.c|  2 +-
drivers/md/persistent-data/dm-block-manager.c|  4 ++--
drivers/staging/lustre/lustre/libcfs/linux/linux-debug.c |  6 --
drivers/tty/tty_ldsem.c  | 10 +-
kernel/locking/mutex.c   |  4 ++--
kernel/locking/rwsem-spinlock.c  | 12 +---
kernel/locking/rwsem-xadd.c  |  4 ++--
kernel/locking/semaphore.c   |  2 +-
9 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/arch/um/drivers/random.c b/arch/um/drivers/random.c
index dd16c902ff70..19d41a583288 100644
--- a/arch/um/drivers/random.c
+++ b/arch/um/drivers/random.c
@@ -76,7 +76,7 @@ static ssize_t rng_dev_read (struct file *filp, char __user 
*buf, size_t size,
add_sigio_fd(random_fd);

add_wait_queue(_read_wait, );
-   set_task_state(current, TASK_INTERRUPTIBLE);
+   set_current_state(TASK_INTERRUPTIBLE);

schedule();
remove_wait_queue(_read_wait, );
diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c
index cd77216beff1..c5e89f358d98 100644
--- a/drivers/md/dm-bufio.c
+++ b/drivers/md/dm-bufio.c
@@ -807,7 +807,7 @@ static void __wait_for_free_buffer(struct dm_bufio_client 
*c)
DECLARE_WAITQUEUE(wait, current);

add_wait_queue(>free_buffer_wait, );
-   set_task_state(current, TASK_UNINTERRUPTIBLE);
+   set_current_state(TASK_UNINTERRUPTIBLE);
dm_bufio_unlock(c);

io_schedule();
diff --git a/drivers/md/persistent-data/dm-block-manager.c 
b/drivers/md/persistent-data/dm-block-manager.c
index 1e33dd51c21f..821a26b934c2 100644
--- a/drivers/md/persistent-data/dm-block-manager.c
+++ b/drivers/md/persistent-data/dm-block-manager.c
@@ -118,7 +118,7 @@ static int __check_holder(struct block_lock *lock)
static void __wait(struct waiter *w)
{
for (;;) {
-   set_task_state(current, TASK_UNINTERRUPTIBLE);
+   set_current_state(TASK_UNINTERRUPTIBLE);

if (!w->task)
break;
@@ -126,7 +126,7 @@ static void __wait(struct waiter *w)
schedule();
}

-   set_task_state(current, TASK_RUNNING);
+   set_current_state(TASK_RUNNING);
}

static void __wake_waiter(struct waiter *w)
diff --git 

Re: [PATCH 4/3] rtmutex: Avoid barrier in rt_mutex_handle_deadlock

2016-03-24 Thread Davidlohr Bueso

Adding a few more Cc's for bcache.

On Tue, 22 Mar 2016, Peter Zijlstra wrote:


On Mon, Mar 21, 2016 at 11:16:22AM -0700, Davidlohr Bueso wrote:


+/*
+ * Helpers for modifying the state of either the current task, or a foreign
+ * task. Each of these calls come in both full barrier and weak flavors:
+ *
+ *   Weak
+ * set_task_state()   __set_task_state()
+ * set_current_state()__set_current_state()
+ *
+ * Where set_current_state() and set_task_state() includes a full smp barrier
+ * -after- the write of ->state is correctly serialized with the later test
+ * of whether to actually sleep:
+ *
+ * for (;;) {
+ * set_current_state(TASK_UNINTERRUPTIBLE);
+ * if (event_indicated)
+ * break;
+ * schedule();
+ * }
+ *
+ * This is commonly necessary for processes sleeping and waking through flag
+ * based events. If the caller does not need such serialization, then use
+ * weaker counterparts, which simply writes the state.
+ *
+ * Refer to Documentation/memory-barriers.txt
+ */


I would prefer to pretend set_task_state() does not exist, using it on
anything other than task==current is very very tricky.

With the below patch; we're only left with:

arch/s390/mm/fault.c:   __set_task_state(tsk, 
TASK_UNINTERRUPTIBLE);
arch/s390/mm/fault.c:   __set_task_state(tsk, 
TASK_UNINTERRUPTIBLE);
drivers/md/bcache/btree.c:  set_task_state(c->gc_thread, 
TASK_INTERRUPTIBLE);
kernel/exit.c:  set_task_state(tsk, TASK_UNINTERRUPTIBLE);
kernel/exit.c:  __set_task_state(tsk, TASK_RUNNING);

exit most probably also has tsk==current, but I didn't check.


Right, and only user is do_exit -> exit_mm() which is always current.



bacache seems to rely on the fact that the task is not running after
kthread_create() to change the state. But I've no idea why; the only
think I can come up with is because load accounting, a new thread blocks
in UNINTERRUPTIBLE which adds to load. But by setting it to
INTERRUPTIBLE before waking up it can actually mess that up. This really
should be fixed.


No idea why either.



And s390 does something entirely vile, no idea what.


So this is solved.

I'll send an updated patch based on this one that removes set_task_state 
iff we get rid of the bcache situation obviously.


Thanks,
Davidlohr



---
arch/um/drivers/random.c |  2 +-
drivers/md/dm-bufio.c|  2 +-
drivers/md/persistent-data/dm-block-manager.c|  4 ++--
drivers/staging/lustre/lustre/libcfs/linux/linux-debug.c |  6 --
drivers/tty/tty_ldsem.c  | 10 +-
kernel/locking/mutex.c   |  4 ++--
kernel/locking/rwsem-spinlock.c  | 12 +---
kernel/locking/rwsem-xadd.c  |  4 ++--
kernel/locking/semaphore.c   |  2 +-
9 files changed, 23 insertions(+), 23 deletions(-)

diff --git a/arch/um/drivers/random.c b/arch/um/drivers/random.c
index dd16c902ff70..19d41a583288 100644
--- a/arch/um/drivers/random.c
+++ b/arch/um/drivers/random.c
@@ -76,7 +76,7 @@ static ssize_t rng_dev_read (struct file *filp, char __user 
*buf, size_t size,
add_sigio_fd(random_fd);

add_wait_queue(_read_wait, );
-   set_task_state(current, TASK_INTERRUPTIBLE);
+   set_current_state(TASK_INTERRUPTIBLE);

schedule();
remove_wait_queue(_read_wait, );
diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c
index cd77216beff1..c5e89f358d98 100644
--- a/drivers/md/dm-bufio.c
+++ b/drivers/md/dm-bufio.c
@@ -807,7 +807,7 @@ static void __wait_for_free_buffer(struct dm_bufio_client 
*c)
DECLARE_WAITQUEUE(wait, current);

add_wait_queue(>free_buffer_wait, );
-   set_task_state(current, TASK_UNINTERRUPTIBLE);
+   set_current_state(TASK_UNINTERRUPTIBLE);
dm_bufio_unlock(c);

io_schedule();
diff --git a/drivers/md/persistent-data/dm-block-manager.c 
b/drivers/md/persistent-data/dm-block-manager.c
index 1e33dd51c21f..821a26b934c2 100644
--- a/drivers/md/persistent-data/dm-block-manager.c
+++ b/drivers/md/persistent-data/dm-block-manager.c
@@ -118,7 +118,7 @@ static int __check_holder(struct block_lock *lock)
static void __wait(struct waiter *w)
{
for (;;) {
-   set_task_state(current, TASK_UNINTERRUPTIBLE);
+   set_current_state(TASK_UNINTERRUPTIBLE);

if (!w->task)
break;
@@ -126,7 +126,7 @@ static void __wait(struct waiter *w)
schedule();
}

-   set_task_state(current, TASK_RUNNING);
+   set_current_state(TASK_RUNNING);
}

static void __wake_waiter(struct waiter *w)
diff --git 

[PATCH] ARM: uniphier: drop weird sizeof()

2016-03-24 Thread Masahiro Yamada
My intention was to ioremap a 4-byte register.  Coincidentally enough,
sizeof(SZ_4) equals to SZ_4, but this code is weird anyway.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/platsmp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-uniphier/platsmp.c b/arch/arm/mach-uniphier/platsmp.c
index 6914135..db04142 100644
--- a/arch/arm/mach-uniphier/platsmp.c
+++ b/arch/arm/mach-uniphier/platsmp.c
@@ -120,7 +120,7 @@ static int __init uniphier_smp_prepare_trampoline(unsigned 
int max_cpus)
if (ret)
return ret;
 
-   uniphier_smp_rom_boot_rsv2 = ioremap(rom_rsv2_phys, sizeof(SZ_4));
+   uniphier_smp_rom_boot_rsv2 = ioremap(rom_rsv2_phys, SZ_4);
if (!uniphier_smp_rom_boot_rsv2) {
pr_err("failed to map ROM_BOOT_RSV2 register\n");
return -ENOMEM;
-- 
1.9.1



[PATCH] ARM: uniphier: drop weird sizeof()

2016-03-24 Thread Masahiro Yamada
My intention was to ioremap a 4-byte register.  Coincidentally enough,
sizeof(SZ_4) equals to SZ_4, but this code is weird anyway.

Signed-off-by: Masahiro Yamada 
---

 arch/arm/mach-uniphier/platsmp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-uniphier/platsmp.c b/arch/arm/mach-uniphier/platsmp.c
index 6914135..db04142 100644
--- a/arch/arm/mach-uniphier/platsmp.c
+++ b/arch/arm/mach-uniphier/platsmp.c
@@ -120,7 +120,7 @@ static int __init uniphier_smp_prepare_trampoline(unsigned 
int max_cpus)
if (ret)
return ret;
 
-   uniphier_smp_rom_boot_rsv2 = ioremap(rom_rsv2_phys, sizeof(SZ_4));
+   uniphier_smp_rom_boot_rsv2 = ioremap(rom_rsv2_phys, SZ_4);
if (!uniphier_smp_rom_boot_rsv2) {
pr_err("failed to map ROM_BOOT_RSV2 register\n");
return -ENOMEM;
-- 
1.9.1



[PATCH 2/2] drivers/ata: make ata_using_udma return directly and bool

2016-03-24 Thread Yaowei Bai
This patch makes ata_using_udma return bool due to this
particular function only using either one or zero as its return
value.

This patch also makes ata_using_udma return directly by removing
if condition.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/libata.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/include/linux/libata.h b/include/linux/libata.h
index 2b01760..5dc2083 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -1759,11 +1759,9 @@ static inline unsigned long ata_deadline(unsigned long 
from_jiffies,
change in future hardware and specs, secondly 0xFF means 'no DMA' but is
> UDMA_0. Dyma ddreigiau */
 
-static inline int ata_using_udma(struct ata_device *adev)
+static inline bool ata_using_udma(struct ata_device *adev)
 {
-   if (adev->dma_mode >= XFER_UDMA_0 && adev->dma_mode <= XFER_UDMA_7)
-   return 1;
-   return 0;
+   return adev->dma_mode >= XFER_UDMA_0 && adev->dma_mode <= XFER_UDMA_7;
 }
 
 static inline int ata_dma_enabled(struct ata_device *adev)
-- 
1.9.1





[PATCH 2/2] drivers/ata: make ata_using_udma return directly and bool

2016-03-24 Thread Yaowei Bai
This patch makes ata_using_udma return bool due to this
particular function only using either one or zero as its return
value.

This patch also makes ata_using_udma return directly by removing
if condition.

No functional change.

Signed-off-by: Yaowei Bai 
---
 include/linux/libata.h | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/include/linux/libata.h b/include/linux/libata.h
index 2b01760..5dc2083 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -1759,11 +1759,9 @@ static inline unsigned long ata_deadline(unsigned long 
from_jiffies,
change in future hardware and specs, secondly 0xFF means 'no DMA' but is
> UDMA_0. Dyma ddreigiau */
 
-static inline int ata_using_udma(struct ata_device *adev)
+static inline bool ata_using_udma(struct ata_device *adev)
 {
-   if (adev->dma_mode >= XFER_UDMA_0 && adev->dma_mode <= XFER_UDMA_7)
-   return 1;
-   return 0;
+   return adev->dma_mode >= XFER_UDMA_0 && adev->dma_mode <= XFER_UDMA_7;
 }
 
 static inline int ata_dma_enabled(struct ata_device *adev)
-- 
1.9.1





[PATCH 1/2] drivers/ata: delete unused ata_using_mwdma function

2016-03-24 Thread Yaowei Bai
There's no user of ata_using_mwdma since introduced by commit
b15b3ebae ("libata: Fix a large collection of DMA mode mismatches")
in 2008, so remove it.

Signed-off-by: Yaowei Bai 
---
 include/linux/libata.h | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/include/linux/libata.h b/include/linux/libata.h
index 2c4ebef..2b01760 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -1759,13 +1759,6 @@ static inline unsigned long ata_deadline(unsigned long 
from_jiffies,
change in future hardware and specs, secondly 0xFF means 'no DMA' but is
> UDMA_0. Dyma ddreigiau */
 
-static inline int ata_using_mwdma(struct ata_device *adev)
-{
-   if (adev->dma_mode >= XFER_MW_DMA_0 && adev->dma_mode <= XFER_MW_DMA_4)
-   return 1;
-   return 0;
-}
-
 static inline int ata_using_udma(struct ata_device *adev)
 {
if (adev->dma_mode >= XFER_UDMA_0 && adev->dma_mode <= XFER_UDMA_7)
-- 
1.9.1





[PATCH 1/2] drivers/ata: delete unused ata_using_mwdma function

2016-03-24 Thread Yaowei Bai
There's no user of ata_using_mwdma since introduced by commit
b15b3ebae ("libata: Fix a large collection of DMA mode mismatches")
in 2008, so remove it.

Signed-off-by: Yaowei Bai 
---
 include/linux/libata.h | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/include/linux/libata.h b/include/linux/libata.h
index 2c4ebef..2b01760 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -1759,13 +1759,6 @@ static inline unsigned long ata_deadline(unsigned long 
from_jiffies,
change in future hardware and specs, secondly 0xFF means 'no DMA' but is
> UDMA_0. Dyma ddreigiau */
 
-static inline int ata_using_mwdma(struct ata_device *adev)
-{
-   if (adev->dma_mode >= XFER_MW_DMA_0 && adev->dma_mode <= XFER_MW_DMA_4)
-   return 1;
-   return 0;
-}
-
 static inline int ata_using_udma(struct ata_device *adev)
 {
if (adev->dma_mode >= XFER_UDMA_0 && adev->dma_mode <= XFER_UDMA_7)
-- 
1.9.1





Re: [PATCH v2] phy: rcar-gen3-usb2, rcar-gen2: Use ARCH_RENESAS

2016-03-24 Thread Simon Horman
On Mon, Mar 07, 2016 at 09:01:48AM +0100, Geert Uytterhoeven wrote:
> On Mon, Mar 7, 2016 at 2:14 AM, Simon Horman  
> wrote:
> > Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.
> > A now redundant dependency on OF is also dropped.
> >
> > This is part of an ongoing process to migrate from ARCH_SHMOBILE to
> > ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
> > appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
> >
> > Signed-off-by: Simon Horman 
> > Acked-by: Yoshihiro Shimoda 
> 
> Acked-by: Geert Uytterhoeven 

Hi Kishon,

I am wondering if you could consider applying this series too.

Thanks in advance!


Re: [PATCH v2] phy: rcar-gen3-usb2, rcar-gen2: Use ARCH_RENESAS

2016-03-24 Thread Simon Horman
On Mon, Mar 07, 2016 at 09:01:48AM +0100, Geert Uytterhoeven wrote:
> On Mon, Mar 7, 2016 at 2:14 AM, Simon Horman  
> wrote:
> > Make use of ARCH_RENESAS in place of ARCH_SHMOBILE.
> > A now redundant dependency on OF is also dropped.
> >
> > This is part of an ongoing process to migrate from ARCH_SHMOBILE to
> > ARCH_RENESAS the motivation for which being that RENESAS seems to be a more
> > appropriate name than SHMOBILE for the majority of Renesas ARM based SoCs.
> >
> > Signed-off-by: Simon Horman 
> > Acked-by: Yoshihiro Shimoda 
> 
> Acked-by: Geert Uytterhoeven 

Hi Kishon,

I am wondering if you could consider applying this series too.

Thanks in advance!


Re: [PATCH 1/6] block: ensure we don't truncate top bits of the request command flags

2016-03-24 Thread Mike Christie
On 03/22/2016 02:01 PM, Jens Axboe wrote:
> On 03/22/2016 12:59 PM, Christoph Hellwig wrote:
>> On Tue, Mar 22, 2016 at 11:55:15AM -0600, Jens Axboe wrote:
>>> Some of the flags that we want to use from the make_request_fn path
>>> are now larger than 32-bit, so change the functions involved to
>>> accept an u64 instead of an unsigned int.
>>
>> When did we start doing that?  We really should merge Mike's split
>> of the operation style flags into the cmd_type before making things
>> even worse in the flags area.
> 
> Just now, and I ran into it last week as well, for a test patch on cfq
> that passed in higher flags for get_request -> may_queue() as well. We
> can do Mike's split first, I think it's a good cleanup. As a standalone
> series, I needed it though.
> 

Hey, did you want any changes on that patchset? I was going to repost it
with the kbuild fix against linux-next, but I can make any changes you
wanted first.


Re: [PATCH 1/6] block: ensure we don't truncate top bits of the request command flags

2016-03-24 Thread Mike Christie
On 03/22/2016 02:01 PM, Jens Axboe wrote:
> On 03/22/2016 12:59 PM, Christoph Hellwig wrote:
>> On Tue, Mar 22, 2016 at 11:55:15AM -0600, Jens Axboe wrote:
>>> Some of the flags that we want to use from the make_request_fn path
>>> are now larger than 32-bit, so change the functions involved to
>>> accept an u64 instead of an unsigned int.
>>
>> When did we start doing that?  We really should merge Mike's split
>> of the operation style flags into the cmd_type before making things
>> even worse in the flags area.
> 
> Just now, and I ran into it last week as well, for a test patch on cfq
> that passed in higher flags for get_request -> may_queue() as well. We
> can do Mike's split first, I think it's a good cleanup. As a standalone
> series, I needed it though.
> 

Hey, did you want any changes on that patchset? I was going to repost it
with the kbuild fix against linux-next, but I can make any changes you
wanted first.


Re: [PATCH v3 0/2] phy: rcar-gen2, rcar-gen3-usb2: add fallback binding

2016-03-24 Thread Simon Horman
On Mon, Mar 07, 2016 at 10:58:39AM +0900, Simon Horman wrote:
> Add fallback compatibility strings for rcar phy drivers.
> 
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
> relationship between IP blocks might be. For example, I believe that
> r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
> descendant of the former or vice versa.
> 
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
> 
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.

Hi Kishon,

I am wondering if you could consider applying this series.

Thanks!

> 
> Changes in v3:
> * Added Acks
> * Corrected whitespace in examples
> 
> Changes in v2:
> * Update new compatibility strings to match the preferred scheme for
>   ordering elements
> * Rebase
> 
> Simon Horman (2):
>   phy: rcar-gen2: add fallback binding
>   phy: rcar-gen3-usb2: add fallback binding
> 
>  Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt  |  8 +++-
>  Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 10 --
>  drivers/phy/phy-rcar-gen2.c  |  1 +
>  drivers/phy/phy-rcar-gen3-usb2.c |  1 +
>  4 files changed, 17 insertions(+), 3 deletions(-)
> 
> -- 
> 2.1.4
> 


Re: [PATCH v3 0/2] phy: rcar-gen2, rcar-gen3-usb2: add fallback binding

2016-03-24 Thread Simon Horman
On Mon, Mar 07, 2016 at 10:58:39AM +0900, Simon Horman wrote:
> Add fallback compatibility strings for rcar phy drivers.
> 
> In the case of Renesas R-Car hardware we know that there are generations of
> SoCs, e.g. Gen 2 and Gen 3. But beyond that its not clear what the
> relationship between IP blocks might be. For example, I believe that
> r8a7790 is older than r8a7791 but that doesn't imply that the latter is a
> descendant of the former or vice versa.
> 
> We can, however, by examining the documentation and behaviour of the
> hardware at run-time observe that the current driver implementation appears
> to be compatible with the IP blocks on SoCs within a given generation.
> 
> For the above reasons and convenience when enabling new SoCs a
> per-generation fallback compatibility string scheme being adopted for
> drivers for Renesas SoCs.

Hi Kishon,

I am wondering if you could consider applying this series.

Thanks!

> 
> Changes in v3:
> * Added Acks
> * Corrected whitespace in examples
> 
> Changes in v2:
> * Update new compatibility strings to match the preferred scheme for
>   ordering elements
> * Rebase
> 
> Simon Horman (2):
>   phy: rcar-gen2: add fallback binding
>   phy: rcar-gen3-usb2: add fallback binding
> 
>  Documentation/devicetree/bindings/phy/rcar-gen2-phy.txt  |  8 +++-
>  Documentation/devicetree/bindings/phy/rcar-gen3-phy-usb2.txt | 10 --
>  drivers/phy/phy-rcar-gen2.c  |  1 +
>  drivers/phy/phy-rcar-gen3-usb2.c |  1 +
>  4 files changed, 17 insertions(+), 3 deletions(-)
> 
> -- 
> 2.1.4
> 


[PATCH] x86/cpu: add some advanced power management bits

2016-03-24 Thread Huang Rui
Bit 11 of CPUID 8000_0007 edx is processor feedback interface.
Bit 12 of CPUID 8000_0007 edx is accumulated power.

So this patch fixes the output of cpuinfo, and add some new names to
make it more meaningful.

Reported-by: Borislav Petkov 
Signed-off-by: Huang Rui 
---
 arch/x86/kernel/cpu/powerflags.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kernel/cpu/powerflags.c b/arch/x86/kernel/cpu/powerflags.c
index 31f0f33..1dd8294 100644
--- a/arch/x86/kernel/cpu/powerflags.c
+++ b/arch/x86/kernel/cpu/powerflags.c
@@ -18,4 +18,6 @@ const char *const x86_power_flags[32] = {
"", /* tsc invariant mapped to constant_tsc */
"cpb",  /* core performance boost */
"eff_freq_ro", /* Readonly aperf/mperf */
+   "proc_feedback", /* processor feedback interface */
+   "acc_power", /* accumulated power mechanism */
 };
-- 
1.9.1



[PATCH] x86/cpu: add some advanced power management bits

2016-03-24 Thread Huang Rui
Bit 11 of CPUID 8000_0007 edx is processor feedback interface.
Bit 12 of CPUID 8000_0007 edx is accumulated power.

So this patch fixes the output of cpuinfo, and add some new names to
make it more meaningful.

Reported-by: Borislav Petkov 
Signed-off-by: Huang Rui 
---
 arch/x86/kernel/cpu/powerflags.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kernel/cpu/powerflags.c b/arch/x86/kernel/cpu/powerflags.c
index 31f0f33..1dd8294 100644
--- a/arch/x86/kernel/cpu/powerflags.c
+++ b/arch/x86/kernel/cpu/powerflags.c
@@ -18,4 +18,6 @@ const char *const x86_power_flags[32] = {
"", /* tsc invariant mapped to constant_tsc */
"cpb",  /* core performance boost */
"eff_freq_ro", /* Readonly aperf/mperf */
+   "proc_feedback", /* processor feedback interface */
+   "acc_power", /* accumulated power mechanism */
 };
-- 
1.9.1



[PATCH] fs/vfs: improve __mnt_is_readonly

2016-03-24 Thread Yaowei Bai
This patch refactors __mnt_is_readonly and makes it return bool to
improve readability due to this particular function only using either
one or zero as its return value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 fs/namespace.c| 9 +++--
 include/linux/mount.h | 2 +-
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index 4fb1691..4f2facd 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -271,13 +271,10 @@ out_free_cache:
  * mnt_want/drop_write() will _keep_ the filesystem
  * r/w.
  */
-int __mnt_is_readonly(struct vfsmount *mnt)
+bool __mnt_is_readonly(struct vfsmount *mnt)
 {
-   if (mnt->mnt_flags & MNT_READONLY)
-   return 1;
-   if (mnt->mnt_sb->s_flags & MS_RDONLY)
-   return 1;
-   return 0;
+   return mnt->mnt_flags & MNT_READONLY ||
+   mnt->mnt_sb->s_flags & MS_RDONLY;
 }
 EXPORT_SYMBOL_GPL(__mnt_is_readonly);
 
diff --git a/include/linux/mount.h b/include/linux/mount.h
index f822c3c..c143e15 100644
--- a/include/linux/mount.h
+++ b/include/linux/mount.h
@@ -80,7 +80,7 @@ extern void mnt_drop_write_file(struct file *file);
 extern void mntput(struct vfsmount *mnt);
 extern struct vfsmount *mntget(struct vfsmount *mnt);
 extern struct vfsmount *mnt_clone_internal(struct path *path);
-extern int __mnt_is_readonly(struct vfsmount *mnt);
+extern bool __mnt_is_readonly(struct vfsmount *mnt);
 
 struct path;
 extern struct vfsmount *clone_private_mount(struct path *path);
-- 
1.9.1





[PATCH] fs/vfs: improve __mnt_is_readonly

2016-03-24 Thread Yaowei Bai
This patch refactors __mnt_is_readonly and makes it return bool to
improve readability due to this particular function only using either
one or zero as its return value.

No functional change.

Signed-off-by: Yaowei Bai 
---
 fs/namespace.c| 9 +++--
 include/linux/mount.h | 2 +-
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/fs/namespace.c b/fs/namespace.c
index 4fb1691..4f2facd 100644
--- a/fs/namespace.c
+++ b/fs/namespace.c
@@ -271,13 +271,10 @@ out_free_cache:
  * mnt_want/drop_write() will _keep_ the filesystem
  * r/w.
  */
-int __mnt_is_readonly(struct vfsmount *mnt)
+bool __mnt_is_readonly(struct vfsmount *mnt)
 {
-   if (mnt->mnt_flags & MNT_READONLY)
-   return 1;
-   if (mnt->mnt_sb->s_flags & MS_RDONLY)
-   return 1;
-   return 0;
+   return mnt->mnt_flags & MNT_READONLY ||
+   mnt->mnt_sb->s_flags & MS_RDONLY;
 }
 EXPORT_SYMBOL_GPL(__mnt_is_readonly);
 
diff --git a/include/linux/mount.h b/include/linux/mount.h
index f822c3c..c143e15 100644
--- a/include/linux/mount.h
+++ b/include/linux/mount.h
@@ -80,7 +80,7 @@ extern void mnt_drop_write_file(struct file *file);
 extern void mntput(struct vfsmount *mnt);
 extern struct vfsmount *mntget(struct vfsmount *mnt);
 extern struct vfsmount *mnt_clone_internal(struct path *path);
-extern int __mnt_is_readonly(struct vfsmount *mnt);
+extern bool __mnt_is_readonly(struct vfsmount *mnt);
 
 struct path;
 extern struct vfsmount *clone_private_mount(struct path *path);
-- 
1.9.1





  1   2   3   4   5   6   7   8   9   10   >