Re: [PATCHv2] serial: samsung: drop the spinlock around uart_write_wakeup

[Anand Moon]

Hi Krzysztof,

On 21 February 2016 at 07:07, Krzysztof Kozlowski
 wrote:
> 2016-02-20 4:30 GMT+09:00 Peter Hurley :
>> [ +cc Krzysztof Kozlowski ]
>>
>> On 02/18/2016 09:15 PM, Anand Moon wrote:
>>> From: Anand Moon 
>>>
>>> drop the spin_unlock/lock around uart_write_wakeup to protect
>>> write wakeup for uart port.
>>
>> What Krzysztof was saying wrt v1 of this patch is that the
>> changelog should provide as much information as possible to
>> the maintainer(s) and driver author(s), and that you should
>> test that outcome.
>>
>> Here's what I would have written for a commit message:
>>
>>
>>   Remove deadlock workaround for line disciplines that invoke
>>   the tty driver's write() method directly from their write_wakeup()
>>   method. As documented for the write_wakeup() line discipline method
>>   in tty_ldisc.h, line disciplines must not attempt i/o directly
>>   from write_wakeup() as this will deadlock. Reviews of in-tree line
>>   disciplines confirm all defer i/o.
>>
>>   NB: This workaround was added in commit c15c3747ee32
>>   ("serial: samsung: fix potential soft lockup during uart write")
>>   which notes both slip and bluetooth hci attempt i/o directly from
>>   write_wakeup(). These issues were fixed in commits 661f7fda21b1
>>   ("slip: Fix deadlock in write_wakeup") and da64c27d3c93
>>   ("bluetooth: hci_ldisc: fix deadlock condition"), respectively.
>
> Thanks Peter for thorough analysis. It shouldn't be done by you but by
> the patch submitter... and I have big worries that Anand did not
> perform that analysis.
>
> Anand, could you at least test that this lockup does not happen
> anymore? You will need board with Bluetooth for that (and not USB
> Bluetooth...). If you cannot test it, maybe guys from Polish R could
> help you (Cc-ed), because they were working on DMA for serial used in
> Bluetooth.
>
> Best regards,
> Krzysztof

I have looked into the history of the changes,
commit c15c3747ee32 (serial: samsung: fix potential soft lockup during
uart write)
was added long time ago, that's why have missed this.

I don't have on-board Bluetooth enable boards with me,
so if their is potential lockup you people observer
do not consider this patch.

My change's were on the perception of the locking/unlocking.

Thanks for your inputs.

Best regards,
-Anand Moon

Re: [PATCHv2] serial: samsung: drop the spinlock around uart_write_wakeup

[Anand Moon]

Hi Krzysztof,

On 21 February 2016 at 07:07, Krzysztof Kozlowski
 wrote:
> 2016-02-20 4:30 GMT+09:00 Peter Hurley :
>> [ +cc Krzysztof Kozlowski ]
>>
>> On 02/18/2016 09:15 PM, Anand Moon wrote:
>>> From: Anand Moon 
>>>
>>> drop the spin_unlock/lock around uart_write_wakeup to protect
>>> write wakeup for uart port.
>>
>> What Krzysztof was saying wrt v1 of this patch is that the
>> changelog should provide as much information as possible to
>> the maintainer(s) and driver author(s), and that you should
>> test that outcome.
>>
>> Here's what I would have written for a commit message:
>>
>>
>>   Remove deadlock workaround for line disciplines that invoke
>>   the tty driver's write() method directly from their write_wakeup()
>>   method. As documented for the write_wakeup() line discipline method
>>   in tty_ldisc.h, line disciplines must not attempt i/o directly
>>   from write_wakeup() as this will deadlock. Reviews of in-tree line
>>   disciplines confirm all defer i/o.
>>
>>   NB: This workaround was added in commit c15c3747ee32
>>   ("serial: samsung: fix potential soft lockup during uart write")
>>   which notes both slip and bluetooth hci attempt i/o directly from
>>   write_wakeup(). These issues were fixed in commits 661f7fda21b1
>>   ("slip: Fix deadlock in write_wakeup") and da64c27d3c93
>>   ("bluetooth: hci_ldisc: fix deadlock condition"), respectively.
>
> Thanks Peter for thorough analysis. It shouldn't be done by you but by
> the patch submitter... and I have big worries that Anand did not
> perform that analysis.
>
> Anand, could you at least test that this lockup does not happen
> anymore? You will need board with Bluetooth for that (and not USB
> Bluetooth...). If you cannot test it, maybe guys from Polish R could
> help you (Cc-ed), because they were working on DMA for serial used in
> Bluetooth.
>
> Best regards,
> Krzysztof

I have looked into the history of the changes,
commit c15c3747ee32 (serial: samsung: fix potential soft lockup during
uart write)
was added long time ago, that's why have missed this.

I don't have on-board Bluetooth enable boards with me,
so if their is potential lockup you people observer
do not consider this patch.

My change's were on the perception of the locking/unlocking.

Thanks for your inputs.

Best regards,
-Anand Moon

Re: [PATCH v5 2/8] clk: rockchip: rk3036: fix and add node id for emac clock

[Caesar Wang]

Heiko,

在 2016年02月21日 10:26, Heiko Stuebner 写道:

Hi Caesar, Xing,

Am Dienstag, 2. Februar 2016, 11:48:19 schrieb Caesar Wang:

From: zhengxing 

In the emac driver, we need to refer HCLK_MAC since there are
only 3PLLs (APLL/GPLL/DPLL) on the rk3036, most clock are under the
GPLL, and it is unable to provide the accurate rate for mac_ref which
need to 50MHz probability, we should let it under the DPLL and are
able to set the freq which integer multiples of 50MHz, so we add these
emac node for reference.

Signed-off-by: Xing Zheng 
Signed-off-by: Caesar Wang 

[...]


--- a/drivers/clk/rockchip/clk-rk3036.c
+++ b/drivers/clk/rockchip/clk-rk3036.c
@@ -343,8 +343,11 @@ static struct rockchip_clk_branch
rk3036_clk_branches[] __initdata = { RK2928_CLKSEL_CON(16), 0, 2, MFLAGS,
2, 5, DFLAGS,
RK2928_CLKGATE_CON(10), 5, GFLAGS),

-   COMPOSITE_NOGATE(0, "mac_pll_src", mux_pll_src_3plls_p, 0,
-   RK2928_CLKSEL_CON(21), 0, 2, MFLAGS, 9, 5, DFLAGS),
+   MUX(SCLK_MACPLL, "mac_pll_pre", mux_pll_src_3plls_p, 0,
+   RK2928_CLKSEL_CON(21), 0, 2, MFLAGS),
+   DIV(0, "mac_pll_src", "mac_pll_pre", 0,
+   RK2928_CLKSEL_CON(21), 9, 5, DFLAGS),
+

CLK_SET_RATE_NO_REPARENT should do the trick as well.

And the whole hclk + clkid part should be separate patches. I took the
liberty of splitting them already in [0] to see if I could get the emac
running on my kylin board.

Probing emac + phy does suceed, but there is no link-detection.
Building your kylin-develop4.4 branch [1] results in the same (aka no
transmission).

Only with the original uboot + 4.1-based kernel that was already on the
device did I manage to get a network connection.


I guess you need apply the uboot patch[0].

patch[0]:
http://lists.denx.de/pipermail/u-boot/2016-February/245814.html

or get the uboot from rockchip github:
https://github.com/rockchip-linux/u-boot/commits/rk3036




Is there some additional setup missing somewhere?


Heiko

[0] https://github.com/mmind/linux-rockchip/commits/tmp/rk3036-emac
The 3 additional patches are not strictly necessary there.

[1] https://github.com/rockchip-linux/kernel/tree/kylin-develop4.4


The lastest kylin-develop.4.4.y from my github:
https://github.com/Caesar-github/rockchip/tree/kylin/develop-4.4.y





___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
Thanks,
Caesar

Re: [PATCH v5 2/8] clk: rockchip: rk3036: fix and add node id for emac clock

[Caesar Wang]

Heiko,

在 2016年02月21日 10:26, Heiko Stuebner 写道:

Hi Caesar, Xing,

Am Dienstag, 2. Februar 2016, 11:48:19 schrieb Caesar Wang:

From: zhengxing 

In the emac driver, we need to refer HCLK_MAC since there are
only 3PLLs (APLL/GPLL/DPLL) on the rk3036, most clock are under the
GPLL, and it is unable to provide the accurate rate for mac_ref which
need to 50MHz probability, we should let it under the DPLL and are
able to set the freq which integer multiples of 50MHz, so we add these
emac node for reference.

Signed-off-by: Xing Zheng 
Signed-off-by: Caesar Wang 

[...]


--- a/drivers/clk/rockchip/clk-rk3036.c
+++ b/drivers/clk/rockchip/clk-rk3036.c
@@ -343,8 +343,11 @@ static struct rockchip_clk_branch
rk3036_clk_branches[] __initdata = { RK2928_CLKSEL_CON(16), 0, 2, MFLAGS,
2, 5, DFLAGS,
RK2928_CLKGATE_CON(10), 5, GFLAGS),

-   COMPOSITE_NOGATE(0, "mac_pll_src", mux_pll_src_3plls_p, 0,
-   RK2928_CLKSEL_CON(21), 0, 2, MFLAGS, 9, 5, DFLAGS),
+   MUX(SCLK_MACPLL, "mac_pll_pre", mux_pll_src_3plls_p, 0,
+   RK2928_CLKSEL_CON(21), 0, 2, MFLAGS),
+   DIV(0, "mac_pll_src", "mac_pll_pre", 0,
+   RK2928_CLKSEL_CON(21), 9, 5, DFLAGS),
+

CLK_SET_RATE_NO_REPARENT should do the trick as well.

And the whole hclk + clkid part should be separate patches. I took the
liberty of splitting them already in [0] to see if I could get the emac
running on my kylin board.

Probing emac + phy does suceed, but there is no link-detection.
Building your kylin-develop4.4 branch [1] results in the same (aka no
transmission).

Only with the original uboot + 4.1-based kernel that was already on the
device did I manage to get a network connection.


I guess you need apply the uboot patch[0].

patch[0]:
http://lists.denx.de/pipermail/u-boot/2016-February/245814.html

or get the uboot from rockchip github:
https://github.com/rockchip-linux/u-boot/commits/rk3036




Is there some additional setup missing somewhere?


Heiko

[0] https://github.com/mmind/linux-rockchip/commits/tmp/rk3036-emac
The 3 additional patches are not strictly necessary there.

[1] https://github.com/rockchip-linux/kernel/tree/kylin-develop4.4


The lastest kylin-develop.4.4.y from my github:
https://github.com/Caesar-github/rockchip/tree/kylin/develop-4.4.y





___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
Thanks,
Caesar

Re: [PATCH v5 2/8] clk: rockchip: rk3036: fix and add node id for emac clock

[Heiko Stuebner]

Hi Caesar, Xing,

Am Dienstag, 2. Februar 2016, 11:48:19 schrieb Caesar Wang:
> From: zhengxing 
> 
> In the emac driver, we need to refer HCLK_MAC since there are
> only 3PLLs (APLL/GPLL/DPLL) on the rk3036, most clock are under the
> GPLL, and it is unable to provide the accurate rate for mac_ref which
> need to 50MHz probability, we should let it under the DPLL and are
> able to set the freq which integer multiples of 50MHz, so we add these
> emac node for reference.
> 
> Signed-off-by: Xing Zheng 
> Signed-off-by: Caesar Wang 

[...]

> --- a/drivers/clk/rockchip/clk-rk3036.c
> +++ b/drivers/clk/rockchip/clk-rk3036.c
> @@ -343,8 +343,11 @@ static struct rockchip_clk_branch
> rk3036_clk_branches[] __initdata = { RK2928_CLKSEL_CON(16), 0, 2, MFLAGS,
> 2, 5, DFLAGS,
>   RK2928_CLKGATE_CON(10), 5, GFLAGS),
> 
> - COMPOSITE_NOGATE(0, "mac_pll_src", mux_pll_src_3plls_p, 0,
> - RK2928_CLKSEL_CON(21), 0, 2, MFLAGS, 9, 5, DFLAGS),
> + MUX(SCLK_MACPLL, "mac_pll_pre", mux_pll_src_3plls_p, 0,
> + RK2928_CLKSEL_CON(21), 0, 2, MFLAGS),
> + DIV(0, "mac_pll_src", "mac_pll_pre", 0,
> + RK2928_CLKSEL_CON(21), 9, 5, DFLAGS),
> +

CLK_SET_RATE_NO_REPARENT should do the trick as well.

And the whole hclk + clkid part should be separate patches. I took the 
liberty of splitting them already in [0] to see if I could get the emac 
running on my kylin board.

Probing emac + phy does suceed, but there is no link-detection.
Building your kylin-develop4.4 branch [1] results in the same (aka no 
transmission). 

Only with the original uboot + 4.1-based kernel that was already on the 
device did I manage to get a network connection.

Is there some additional setup missing somewhere?


Heiko

[0] https://github.com/mmind/linux-rockchip/commits/tmp/rk3036-emac
The 3 additional patches are not strictly necessary there.

[1] https://github.com/rockchip-linux/kernel/tree/kylin-develop4.4

Re: [PATCH v5 2/8] clk: rockchip: rk3036: fix and add node id for emac clock

[Heiko Stuebner]

Hi Caesar, Xing,

Am Dienstag, 2. Februar 2016, 11:48:19 schrieb Caesar Wang:
> From: zhengxing 
> 
> In the emac driver, we need to refer HCLK_MAC since there are
> only 3PLLs (APLL/GPLL/DPLL) on the rk3036, most clock are under the
> GPLL, and it is unable to provide the accurate rate for mac_ref which
> need to 50MHz probability, we should let it under the DPLL and are
> able to set the freq which integer multiples of 50MHz, so we add these
> emac node for reference.
> 
> Signed-off-by: Xing Zheng 
> Signed-off-by: Caesar Wang 

[...]

> --- a/drivers/clk/rockchip/clk-rk3036.c
> +++ b/drivers/clk/rockchip/clk-rk3036.c
> @@ -343,8 +343,11 @@ static struct rockchip_clk_branch
> rk3036_clk_branches[] __initdata = { RK2928_CLKSEL_CON(16), 0, 2, MFLAGS,
> 2, 5, DFLAGS,
>   RK2928_CLKGATE_CON(10), 5, GFLAGS),
> 
> - COMPOSITE_NOGATE(0, "mac_pll_src", mux_pll_src_3plls_p, 0,
> - RK2928_CLKSEL_CON(21), 0, 2, MFLAGS, 9, 5, DFLAGS),
> + MUX(SCLK_MACPLL, "mac_pll_pre", mux_pll_src_3plls_p, 0,
> + RK2928_CLKSEL_CON(21), 0, 2, MFLAGS),
> + DIV(0, "mac_pll_src", "mac_pll_pre", 0,
> + RK2928_CLKSEL_CON(21), 9, 5, DFLAGS),
> +

CLK_SET_RATE_NO_REPARENT should do the trick as well.

And the whole hclk + clkid part should be separate patches. I took the 
liberty of splitting them already in [0] to see if I could get the emac 
running on my kylin board.

Probing emac + phy does suceed, but there is no link-detection.
Building your kylin-develop4.4 branch [1] results in the same (aka no 
transmission). 

Only with the original uboot + 4.1-based kernel that was already on the 
device did I manage to get a network connection.

Is there some additional setup missing somewhere?


Heiko

[0] https://github.com/mmind/linux-rockchip/commits/tmp/rk3036-emac
The 3 additional patches are not strictly necessary there.

[1] https://github.com/rockchip-linux/kernel/tree/kylin-develop4.4

Re: [PATCH v5 1/8] ARM: dts: rockchip: add hdmi/vop device node for rk3036

[Caesar Wang]

在 2016年02月21日 08:03, Heiko Stuebner 写道:

Am Dienstag, 2. Februar 2016, 11:40:50 schrieb Caesar Wang:

This patch adds the needed display info for rk3036 SOCs.

The rk3036 support two overlay plane and one hwc plane,
it supports IOMMU, and its IOMMU same as rk3288's.
Meanwhile, add the inno hdmi for HDMI display.

Signed-off-by: Caesar Wang 

I've split this into 3 patches (vop, hdmi, kylin enablement) and applied
this to my dts32 branch.


That's great, thanks.




Heiko

___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
Thanks,
Caesar

Re: [PATCH v5 1/8] ARM: dts: rockchip: add hdmi/vop device node for rk3036

[Caesar Wang]

在 2016年02月21日 08:03, Heiko Stuebner 写道:

Am Dienstag, 2. Februar 2016, 11:40:50 schrieb Caesar Wang:

This patch adds the needed display info for rk3036 SOCs.

The rk3036 support two overlay plane and one hwc plane,
it supports IOMMU, and its IOMMU same as rk3288's.
Meanwhile, add the inno hdmi for HDMI display.

Signed-off-by: Caesar Wang 

I've split this into 3 patches (vop, hdmi, kylin enablement) and applied
this to my dts32 branch.


That's great, thanks.




Heiko

___
Linux-rockchip mailing list
linux-rockc...@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip



--
Thanks,
Caesar

[PATCH 1/2] cpufreq: governor: Fix race in dbs_update_util_handler()

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

There is a scenarion that may lead to undesired results in
dbs_update_util_handler().  Namely, if two CPUs sharing a policy
enter the funtion at the same time, pass the sample delay check
and then one of them is stalled until dbs_work_handler() (queued
up by the other CPU) clears the work counter, it may update the
work counter and queue up another work item prematurely.

To prevent that from happening, use the observation that the CPU
queuing up a work item in dbs_update_util_handler() updates the
last sample time.  This means that if another CPU was stalling after
passing the sample delay check and now successfully updated the work
counter as a result of the race described above, it will see the new
value of the last sample time which is different from what it used in
the sample delay check before.  If that happens, the sample delay
check passed previously is not valid any more, so the CPU should not
continue, but leaving the funtion at that point might miss an
opportunity to take the next sample, so simply clear the work
counter and jump to the beginning of the function in that case.

Fixes: f17cbb53783c (cpufreq: governor: Avoid atomic operations in hot paths)
Signed-off-by: Rafael J. Wysocki 
---
 drivers/cpufreq/cpufreq_governor.c |   22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
===
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
+++ linux-pm/drivers/cpufreq/cpufreq_governor.c
@@ -341,8 +341,9 @@ static void dbs_update_util_handler(stru
 {
struct cpu_dbs_info *cdbs = container_of(data, struct cpu_dbs_info, 
update_util);
struct policy_dbs_info *policy_dbs = cdbs->policy_dbs;
-   u64 delta_ns;
+   u64 delta_ns, lst;
 
+ start:
/*
 * The work may not be allowed to be queued up right now.
 * Possible reasons:
@@ -357,7 +358,8 @@ static void dbs_update_util_handler(stru
 * of sample_delay_ns used in the computation may be stale.
 */
smp_rmb();
-   delta_ns = time - policy_dbs->last_sample_time;
+   lst = ACCESS_ONCE(policy_dbs->last_sample_time);
+   delta_ns = time - lst;
if ((s64)delta_ns < policy_dbs->sample_delay_ns)
return;
 
@@ -366,9 +368,19 @@ static void dbs_update_util_handler(stru
 * at this point.  Otherwise, we need to ensure that only one of the
 * CPUs sharing the policy will do that.
 */
-   if (policy_dbs->is_shared &&
-   !atomic_add_unless(_dbs->work_count, 1, 1))
-   return;
+   if (policy_dbs->is_shared) {
+   if (!atomic_add_unless(_dbs->work_count, 1, 1))
+   return;
+
+   /*
+* If another CPU updated last_sample_time in the meantime, we
+* shouldn't be here, so clear the work counter and try again.
+*/
+   if (unlikely(lst != ACCESS_ONCE(policy_dbs->last_sample_time))) 
{
+   atomic_set(_dbs->work_count, 0);
+   goto start;
+   }
+   }
 
policy_dbs->last_sample_time = time;
policy_dbs->work_in_progress = true;

[PATCH 1/2] cpufreq: governor: Fix race in dbs_update_util_handler()

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

There is a scenarion that may lead to undesired results in
dbs_update_util_handler().  Namely, if two CPUs sharing a policy
enter the funtion at the same time, pass the sample delay check
and then one of them is stalled until dbs_work_handler() (queued
up by the other CPU) clears the work counter, it may update the
work counter and queue up another work item prematurely.

To prevent that from happening, use the observation that the CPU
queuing up a work item in dbs_update_util_handler() updates the
last sample time.  This means that if another CPU was stalling after
passing the sample delay check and now successfully updated the work
counter as a result of the race described above, it will see the new
value of the last sample time which is different from what it used in
the sample delay check before.  If that happens, the sample delay
check passed previously is not valid any more, so the CPU should not
continue, but leaving the funtion at that point might miss an
opportunity to take the next sample, so simply clear the work
counter and jump to the beginning of the function in that case.

Fixes: f17cbb53783c (cpufreq: governor: Avoid atomic operations in hot paths)
Signed-off-by: Rafael J. Wysocki 
---
 drivers/cpufreq/cpufreq_governor.c |   22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
===
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
+++ linux-pm/drivers/cpufreq/cpufreq_governor.c
@@ -341,8 +341,9 @@ static void dbs_update_util_handler(stru
 {
struct cpu_dbs_info *cdbs = container_of(data, struct cpu_dbs_info, 
update_util);
struct policy_dbs_info *policy_dbs = cdbs->policy_dbs;
-   u64 delta_ns;
+   u64 delta_ns, lst;
 
+ start:
/*
 * The work may not be allowed to be queued up right now.
 * Possible reasons:
@@ -357,7 +358,8 @@ static void dbs_update_util_handler(stru
 * of sample_delay_ns used in the computation may be stale.
 */
smp_rmb();
-   delta_ns = time - policy_dbs->last_sample_time;
+   lst = ACCESS_ONCE(policy_dbs->last_sample_time);
+   delta_ns = time - lst;
if ((s64)delta_ns < policy_dbs->sample_delay_ns)
return;
 
@@ -366,9 +368,19 @@ static void dbs_update_util_handler(stru
 * at this point.  Otherwise, we need to ensure that only one of the
 * CPUs sharing the policy will do that.
 */
-   if (policy_dbs->is_shared &&
-   !atomic_add_unless(_dbs->work_count, 1, 1))
-   return;
+   if (policy_dbs->is_shared) {
+   if (!atomic_add_unless(_dbs->work_count, 1, 1))
+   return;
+
+   /*
+* If another CPU updated last_sample_time in the meantime, we
+* shouldn't be here, so clear the work counter and try again.
+*/
+   if (unlikely(lst != ACCESS_ONCE(policy_dbs->last_sample_time))) 
{
+   atomic_set(_dbs->work_count, 0);
+   goto start;
+   }
+   }
 
policy_dbs->last_sample_time = time;
policy_dbs->work_in_progress = true;

[PATCH 0/2] cpufreq: governor: Fixups on top of recent changes

[Rafael J. Wysocki]

Hi,

Two fixups on top of recent cpufreq governor changes in the linux-next
branch of linux-pm.git.

[1/2] closes a tiny theoretical race in dbs_update_util_handler()
  that may lead to taking a sample prematurely in some weird
  cases.

[2/2] removes an unnecessary function export.

Thanks,
Rafael

[PATCH 2/2] cpufreq: governor: Make gov_set_update_util() static

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

The gov_set_update_util() routine is only used internally by the
common governor code and it doesn't need to be exported, so make
it static.

No functional changes.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/cpufreq/cpufreq_governor.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
===
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
+++ linux-pm/drivers/cpufreq/cpufreq_governor.c
@@ -261,8 +261,8 @@ unsigned int dbs_update(struct cpufreq_p
 }
 EXPORT_SYMBOL_GPL(dbs_update);
 
-void gov_set_update_util(struct policy_dbs_info *policy_dbs,
-unsigned int delay_us)
+static void gov_set_update_util(struct policy_dbs_info *policy_dbs,
+   unsigned int delay_us)
 {
struct cpufreq_policy *policy = policy_dbs->policy;
int cpu;
@@ -276,7 +276,6 @@ void gov_set_update_util(struct policy_d
cpufreq_set_update_util_data(cpu, >update_util);
}
 }
-EXPORT_SYMBOL_GPL(gov_set_update_util);
 
 static inline void gov_clear_update_util(struct cpufreq_policy *policy)
 {

[PATCH 0/2] cpufreq: governor: Fixups on top of recent changes

[Rafael J. Wysocki]

Hi,

Two fixups on top of recent cpufreq governor changes in the linux-next
branch of linux-pm.git.

[1/2] closes a tiny theoretical race in dbs_update_util_handler()
  that may lead to taking a sample prematurely in some weird
  cases.

[2/2] removes an unnecessary function export.

Thanks,
Rafael

[PATCH 2/2] cpufreq: governor: Make gov_set_update_util() static

[Rafael J. Wysocki]

From: Rafael J. Wysocki 

The gov_set_update_util() routine is only used internally by the
common governor code and it doesn't need to be exported, so make
it static.

No functional changes.

Signed-off-by: Rafael J. Wysocki 
---
 drivers/cpufreq/cpufreq_governor.c |5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

Index: linux-pm/drivers/cpufreq/cpufreq_governor.c
===
--- linux-pm.orig/drivers/cpufreq/cpufreq_governor.c
+++ linux-pm/drivers/cpufreq/cpufreq_governor.c
@@ -261,8 +261,8 @@ unsigned int dbs_update(struct cpufreq_p
 }
 EXPORT_SYMBOL_GPL(dbs_update);
 
-void gov_set_update_util(struct policy_dbs_info *policy_dbs,
-unsigned int delay_us)
+static void gov_set_update_util(struct policy_dbs_info *policy_dbs,
+   unsigned int delay_us)
 {
struct cpufreq_policy *policy = policy_dbs->policy;
int cpu;
@@ -276,7 +276,6 @@ void gov_set_update_util(struct policy_d
cpufreq_set_update_util_data(cpu, >update_util);
}
 }
-EXPORT_SYMBOL_GPL(gov_set_update_util);
 
 static inline void gov_clear_update_util(struct cpufreq_policy *policy)
 {

Re: [PATCH] btrfs: backref: Fixed checkpatch warning of over 80 characters

[Simon Quigley]

I apologize, I had my text editor set to a 4 space tab instead of 8 so I 
couldn't see this clearly. That's fixed now, and it won't happen again. 
Is this what you wanted? It seems to line up exactly like you proposed.


On 02/20/2016 08:06 PM, Simon Quigley wrote:

checkpatch.pl reported a warning of over 80 characters on line 1833

Adjusted to put  and  on a different line

Signed-off-by: Simon Quigley 
---
  fs/btrfs/backref.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index f6dac40..81b0863 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -1830,8 +1830,8 @@ static int iterate_inode_extrefs(u64 inum, struct 
btrfs_root *fs_root,
unsigned long ptr;

while (1) {
-   ret = btrfs_find_one_extref(fs_root, inum, offset, path, 
,
-   );
+   ret = btrfs_find_one_extref(fs_root, inum, offset, path,
+   , );
if (ret < 0)
break;
if (ret) {

Re: [PATCH] btrfs: backref: Fixed checkpatch warning of over 80 characters

[Simon Quigley]

I apologize, I had my text editor set to a 4 space tab instead of 8 so I 
couldn't see this clearly. That's fixed now, and it won't happen again. 
Is this what you wanted? It seems to line up exactly like you proposed.


On 02/20/2016 08:06 PM, Simon Quigley wrote:

checkpatch.pl reported a warning of over 80 characters on line 1833

Adjusted to put  and  on a different line

Signed-off-by: Simon Quigley 
---
  fs/btrfs/backref.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index f6dac40..81b0863 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -1830,8 +1830,8 @@ static int iterate_inode_extrefs(u64 inum, struct 
btrfs_root *fs_root,
unsigned long ptr;

while (1) {
-   ret = btrfs_find_one_extref(fs_root, inum, offset, path, 
,
-   );
+   ret = btrfs_find_one_extref(fs_root, inum, offset, path,
+   , );
if (ret < 0)
break;
if (ret) {

[PATCH] btrfs: backref: Fixed checkpatch warning of over 80 characters

[Simon Quigley]

checkpatch.pl reported a warning of over 80 characters on line 1833

Adjusted to put  and  on a different line

Signed-off-by: Simon Quigley 
---
 fs/btrfs/backref.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index f6dac40..81b0863 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -1830,8 +1830,8 @@ static int iterate_inode_extrefs(u64 inum, struct 
btrfs_root *fs_root,
unsigned long ptr;
 
while (1) {
-   ret = btrfs_find_one_extref(fs_root, inum, offset, path, 
,
-   );
+   ret = btrfs_find_one_extref(fs_root, inum, offset, path,
+   , );
if (ret < 0)
break;
if (ret) {
-- 
2.7.0

[PATCH] btrfs: backref: Fixed checkpatch warning of over 80 characters

[Simon Quigley]

checkpatch.pl reported a warning of over 80 characters on line 1833

Adjusted to put  and  on a different line

Signed-off-by: Simon Quigley 
---
 fs/btrfs/backref.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index f6dac40..81b0863 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -1830,8 +1830,8 @@ static int iterate_inode_extrefs(u64 inum, struct 
btrfs_root *fs_root,
unsigned long ptr;
 
while (1) {
-   ret = btrfs_find_one_extref(fs_root, inum, offset, path, 
,
-   );
+   ret = btrfs_find_one_extref(fs_root, inum, offset, path,
+   , );
if (ret < 0)
break;
if (ret) {
-- 
2.7.0

[PATCH v2] Fix sun7i pin assignment for IRQ's

[hp197]

After testing IRQ pins we found some bugs in the pinctrl declaration.

Signed-off-by: hp197 
---

Changes in v2:
After some more testing we found irq on PI pins.
they where on mux6 so this is included in my patch.

Also included is a warning for PI17, this pin was not working
on apritzel his bPI and he thinks it might be correlated to
GIC and IRQ 29.
---
 drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c | 25 +++--
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c 
b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
index cf1ce0c..0fe173e 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
@@ -344,25 +344,21 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
  SUNXI_FUNCTION(0x1, "gpio_out"),
  SUNXI_FUNCTION(0x2, "nand0"), /* NCE4 */
  SUNXI_FUNCTION(0x3, "spi2"),  /* CS0 */
- SUNXI_FUNCTION_IRQ(0x6, 12)), /* EINT12 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 20),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
  SUNXI_FUNCTION(0x2, "nand0"), /* NCE5 */
  SUNXI_FUNCTION(0x3, "spi2"),  /* CLK */
- SUNXI_FUNCTION_IRQ(0x6, 13)), /* EINT13 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 21),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
  SUNXI_FUNCTION(0x2, "nand0"), /* NCE6 */
  SUNXI_FUNCTION(0x3, "spi2"),  /* MOSI */
- SUNXI_FUNCTION_IRQ(0x6, 14)), /* EINT14 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 22),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
  SUNXI_FUNCTION(0x2, "nand0"), /* NCE7 */
  SUNXI_FUNCTION(0x3, "spi2"),  /* MISO */
- SUNXI_FUNCTION_IRQ(0x6, 15)), /* EINT15 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 23),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
@@ -960,65 +956,66 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
  SUNXI_FUNCTION(0x1, "gpio_out"),
  SUNXI_FUNCTION(0x2, "spi0"),  /* CS0 */
  SUNXI_FUNCTION(0x3, "uart5"), /* TX */
- SUNXI_FUNCTION_IRQ(0x5, 22)), /* EINT22 */
+ SUNXI_FUNCTION_IRQ(0x6, 22)), /* EINT22 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 11),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
  SUNXI_FUNCTION(0x2, "spi0"),  /* CLK */
  SUNXI_FUNCTION(0x3, "uart5"), /* RX */
- SUNXI_FUNCTION_IRQ(0x5, 23)), /* EINT23 */
+ SUNXI_FUNCTION_IRQ(0x6, 23)), /* EINT23 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 12),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
  SUNXI_FUNCTION(0x2, "spi0"),  /* MOSI */
  SUNXI_FUNCTION(0x3, "uart6"), /* TX */
  SUNXI_FUNCTION(0x4, "clk_out_a"), /* CLK_OUT_A */
- SUNXI_FUNCTION_IRQ(0x5, 24)), /* EINT24 */
+ SUNXI_FUNCTION_IRQ(0x6, 24)), /* EINT24 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 13),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
  SUNXI_FUNCTION(0x2, "spi0"),  /* MISO */
  SUNXI_FUNCTION(0x3, "uart6"), /* RX */
  SUNXI_FUNCTION(0x4, "clk_out_b"), /* CLK_OUT_B */
- SUNXI_FUNCTION_IRQ(0x5, 25)), /* EINT25 */
+ SUNXI_FUNCTION_IRQ(0x6, 25)), /* EINT25 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 14),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
  SUNXI_FUNCTION(0x2, "spi0"),  /* CS1 */
  SUNXI_FUNCTION(0x3, "ps2"),   /* SCK1 */
  SUNXI_FUNCTION(0x4, "timer4"),/* TCLKIN0 */
- SUNXI_FUNCTION_IRQ(0x5, 26)), /* EINT26 */
+ SUNXI_FUNCTION_IRQ(0x6, 26)), /* EINT26 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 15),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
  SUNXI_FUNCTION(0x2, "spi1"),  /* CS1 */
  SUNXI_FUNCTION(0x3, "ps2"),   /* SDA1 */
  SUNXI_FUNCTION(0x4, "timer5"),/* TCLKIN1 */
- SUNXI_FUNCTION_IRQ(0x5, 27)), /* EINT27 */
+ 

[PATCH v2] Fix sun7i pin assignment for IRQ's

[hp197]

After testing IRQ pins we found some bugs in the pinctrl declaration.

Signed-off-by: hp197 
---

Changes in v2:
After some more testing we found irq on PI pins.
they where on mux6 so this is included in my patch.

Also included is a warning for PI17, this pin was not working
on apritzel his bPI and he thinks it might be correlated to
GIC and IRQ 29.
---
 drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c | 25 +++--
 1 file changed, 11 insertions(+), 14 deletions(-)

diff --git a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c 
b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
index cf1ce0c..0fe173e 100644
--- a/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
+++ b/drivers/pinctrl/sunxi/pinctrl-sun7i-a20.c
@@ -344,25 +344,21 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
  SUNXI_FUNCTION(0x1, "gpio_out"),
  SUNXI_FUNCTION(0x2, "nand0"), /* NCE4 */
  SUNXI_FUNCTION(0x3, "spi2"),  /* CS0 */
- SUNXI_FUNCTION_IRQ(0x6, 12)), /* EINT12 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 20),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
  SUNXI_FUNCTION(0x2, "nand0"), /* NCE5 */
  SUNXI_FUNCTION(0x3, "spi2"),  /* CLK */
- SUNXI_FUNCTION_IRQ(0x6, 13)), /* EINT13 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 21),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
  SUNXI_FUNCTION(0x2, "nand0"), /* NCE6 */
  SUNXI_FUNCTION(0x3, "spi2"),  /* MOSI */
- SUNXI_FUNCTION_IRQ(0x6, 14)), /* EINT14 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 22),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
  SUNXI_FUNCTION(0x2, "nand0"), /* NCE7 */
  SUNXI_FUNCTION(0x3, "spi2"),  /* MISO */
- SUNXI_FUNCTION_IRQ(0x6, 15)), /* EINT15 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(C, 23),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
@@ -960,65 +956,66 @@ static const struct sunxi_desc_pin sun7i_a20_pins[] = {
  SUNXI_FUNCTION(0x1, "gpio_out"),
  SUNXI_FUNCTION(0x2, "spi0"),  /* CS0 */
  SUNXI_FUNCTION(0x3, "uart5"), /* TX */
- SUNXI_FUNCTION_IRQ(0x5, 22)), /* EINT22 */
+ SUNXI_FUNCTION_IRQ(0x6, 22)), /* EINT22 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 11),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
  SUNXI_FUNCTION(0x2, "spi0"),  /* CLK */
  SUNXI_FUNCTION(0x3, "uart5"), /* RX */
- SUNXI_FUNCTION_IRQ(0x5, 23)), /* EINT23 */
+ SUNXI_FUNCTION_IRQ(0x6, 23)), /* EINT23 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 12),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
  SUNXI_FUNCTION(0x2, "spi0"),  /* MOSI */
  SUNXI_FUNCTION(0x3, "uart6"), /* TX */
  SUNXI_FUNCTION(0x4, "clk_out_a"), /* CLK_OUT_A */
- SUNXI_FUNCTION_IRQ(0x5, 24)), /* EINT24 */
+ SUNXI_FUNCTION_IRQ(0x6, 24)), /* EINT24 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 13),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
  SUNXI_FUNCTION(0x2, "spi0"),  /* MISO */
  SUNXI_FUNCTION(0x3, "uart6"), /* RX */
  SUNXI_FUNCTION(0x4, "clk_out_b"), /* CLK_OUT_B */
- SUNXI_FUNCTION_IRQ(0x5, 25)), /* EINT25 */
+ SUNXI_FUNCTION_IRQ(0x6, 25)), /* EINT25 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 14),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
  SUNXI_FUNCTION(0x2, "spi0"),  /* CS1 */
  SUNXI_FUNCTION(0x3, "ps2"),   /* SCK1 */
  SUNXI_FUNCTION(0x4, "timer4"),/* TCLKIN0 */
- SUNXI_FUNCTION_IRQ(0x5, 26)), /* EINT26 */
+ SUNXI_FUNCTION_IRQ(0x6, 26)), /* EINT26 */
SUNXI_PIN(SUNXI_PINCTRL_PIN(I, 15),
  SUNXI_FUNCTION(0x0, "gpio_in"),
  SUNXI_FUNCTION(0x1, "gpio_out"),
  SUNXI_FUNCTION(0x2, "spi1"),  /* CS1 */
  SUNXI_FUNCTION(0x3, "ps2"),   /* SDA1 */
  SUNXI_FUNCTION(0x4, "timer5"),/* TCLKIN1 */
- SUNXI_FUNCTION_IRQ(0x5, 27)), /* EINT27 */
+ SUNXI_FUNCTION_IRQ(0x6, 27)), /* 

Re: [PATCH 1/4] ASoC: wm9713: add binding for WM9713 codec

[Mark Brown]

On Sat, Feb 20, 2016 at 11:24:02PM +0100, Robert Jarzmik wrote:

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

> Mark Brown  writes:
> > On Sat, Feb 20, 2016 at 09:32:58PM +0100, Robert Jarzmik wrote:

> > It will eumerate the AC'97 bus by itself and does not need the CODEC to
> > be described.

> I think I still don't get it.

> So let's rephrase it another way : how will the function wm9713_probe() be
> called, ie. what is the possible function backtrace leading to that call ?

It will not be called, the generic AC'97 code will be used.

> > They should be created as a function of enumerating the CODEC.  If you
> > use the genric AC'97 stuff it doesn't use ASoC at all and this happens
> > as a side effect.

> I don't get that either. For me sound/soc/pci/ac97/ac97_codec.c is PCI 
> specific,
> not generic, so what is "generic AC'97 stuff" ? I will never be able to use it
> as on my platforms CONFIG_PCI=n.

That is the generic code, there is no PCI dependency.

> Do you have a devicetree example somewhere, with (ac97 host, audio codec) 
> pair I
> can have a look at to understand ?

Some Atmel boards do this IIRC, as does the AACI driver (via AMBA but
same effect).


signature.asc
Description: PGP signature

Re: [PATCH 1/4] ASoC: wm9713: add binding for WM9713 codec

[Mark Brown]

On Sat, Feb 20, 2016 at 11:24:02PM +0100, Robert Jarzmik wrote:

Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns.  Doing this makes your messages much
easier to read and reply to.

> Mark Brown  writes:
> > On Sat, Feb 20, 2016 at 09:32:58PM +0100, Robert Jarzmik wrote:

> > It will eumerate the AC'97 bus by itself and does not need the CODEC to
> > be described.

> I think I still don't get it.

> So let's rephrase it another way : how will the function wm9713_probe() be
> called, ie. what is the possible function backtrace leading to that call ?

It will not be called, the generic AC'97 code will be used.

> > They should be created as a function of enumerating the CODEC.  If you
> > use the genric AC'97 stuff it doesn't use ASoC at all and this happens
> > as a side effect.

> I don't get that either. For me sound/soc/pci/ac97/ac97_codec.c is PCI 
> specific,
> not generic, so what is "generic AC'97 stuff" ? I will never be able to use it
> as on my platforms CONFIG_PCI=n.

That is the generic code, there is no PCI dependency.

> Do you have a devicetree example somewhere, with (ac97 host, audio codec) 
> pair I
> can have a look at to understand ?

Some Atmel boards do this IIRC, as does the AACI driver (via AMBA but
same effect).


signature.asc
Description: PGP signature

Re: [PATCH] btrfs: backref: Fixed checkpatch warning of over 80

[Joe Perches]

On Sat, 2016-02-20 at 18:57 -0600, Simon Quigley wrote:
> Better?

No, not really.

The alignment should be to the open parenthesis
as I wrote in the first reply.

> On 02/20/2016 06:56 PM, Simon Quigley wrote:
> > checkpatch.pl reported a warning of over 80 characters on line 1833
> > 
> > Adjusted to put  and  on a different line
> > 
> > Signed-off-by: Simon Quigley 
> > ---
> >   fs/btrfs/backref.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
> > index f6dac40..956fffa 100644
> > --- a/fs/btrfs/backref.c
> > +++ b/fs/btrfs/backref.c
> > @@ -1830,8 +1830,8 @@ static int iterate_inode_extrefs(u64 inum,
> > struct btrfs_root *fs_root,
> >     unsigned long ptr;
> > 
> >     while (1) {
> > -   ret = btrfs_find_one_extref(fs_root, inum, offset,
> > path, ,
> > -   );
> > +   ret = btrfs_find_one_extref(fs_root, inum, offset,
> > path,
> > +   ,
> > );
> >     if (ret < 0)
> >     break;
> >     if (ret) {
> > 

Re: [PATCH] btrfs: backref: Fixed checkpatch warning of over 80

[Joe Perches]

On Sat, 2016-02-20 at 18:57 -0600, Simon Quigley wrote:
> Better?

No, not really.

The alignment should be to the open parenthesis
as I wrote in the first reply.

> On 02/20/2016 06:56 PM, Simon Quigley wrote:
> > checkpatch.pl reported a warning of over 80 characters on line 1833
> > 
> > Adjusted to put  and  on a different line
> > 
> > Signed-off-by: Simon Quigley 
> > ---
> >   fs/btrfs/backref.c | 4 ++--
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
> > index f6dac40..956fffa 100644
> > --- a/fs/btrfs/backref.c
> > +++ b/fs/btrfs/backref.c
> > @@ -1830,8 +1830,8 @@ static int iterate_inode_extrefs(u64 inum,
> > struct btrfs_root *fs_root,
> >     unsigned long ptr;
> > 
> >     while (1) {
> > -   ret = btrfs_find_one_extref(fs_root, inum, offset,
> > path, ,
> > -   );
> > +   ret = btrfs_find_one_extref(fs_root, inum, offset,
> > path,
> > +   ,
> > );
> >     if (ret < 0)
> >     break;
> >     if (ret) {
> > 

Re: [PATCHv2] serial: samsung: drop the spinlock around uart_write_wakeup

[Krzysztof Kozlowski]

2016-02-20 4:30 GMT+09:00 Peter Hurley :
> [ +cc Krzysztof Kozlowski ]
>
> On 02/18/2016 09:15 PM, Anand Moon wrote:
>> From: Anand Moon 
>>
>> drop the spin_unlock/lock around uart_write_wakeup to protect
>> write wakeup for uart port.
>
> What Krzysztof was saying wrt v1 of this patch is that the
> changelog should provide as much information as possible to
> the maintainer(s) and driver author(s), and that you should
> test that outcome.
>
> Here's what I would have written for a commit message:
>
>
>   Remove deadlock workaround for line disciplines that invoke
>   the tty driver's write() method directly from their write_wakeup()
>   method. As documented for the write_wakeup() line discipline method
>   in tty_ldisc.h, line disciplines must not attempt i/o directly
>   from write_wakeup() as this will deadlock. Reviews of in-tree line
>   disciplines confirm all defer i/o.
>
>   NB: This workaround was added in commit c15c3747ee32
>   ("serial: samsung: fix potential soft lockup during uart write")
>   which notes both slip and bluetooth hci attempt i/o directly from
>   write_wakeup(). These issues were fixed in commits 661f7fda21b1
>   ("slip: Fix deadlock in write_wakeup") and da64c27d3c93
>   ("bluetooth: hci_ldisc: fix deadlock condition"), respectively.

Thanks Peter for thorough analysis. It shouldn't be done by you but by
the patch submitter... and I have big worries that Anand did not
perform that analysis.

Anand, could you at least test that this lockup does not happen
anymore? You will need board with Bluetooth for that (and not USB
Bluetooth...). If you cannot test it, maybe guys from Polish R could
help you (Cc-ed), because they were working on DMA for serial used in
Bluetooth.

Best regards,
Krzysztof

Re: [PATCHv2] serial: samsung: drop the spinlock around uart_write_wakeup

[Krzysztof Kozlowski]

2016-02-20 4:30 GMT+09:00 Peter Hurley :
> [ +cc Krzysztof Kozlowski ]
>
> On 02/18/2016 09:15 PM, Anand Moon wrote:
>> From: Anand Moon 
>>
>> drop the spin_unlock/lock around uart_write_wakeup to protect
>> write wakeup for uart port.
>
> What Krzysztof was saying wrt v1 of this patch is that the
> changelog should provide as much information as possible to
> the maintainer(s) and driver author(s), and that you should
> test that outcome.
>
> Here's what I would have written for a commit message:
>
>
>   Remove deadlock workaround for line disciplines that invoke
>   the tty driver's write() method directly from their write_wakeup()
>   method. As documented for the write_wakeup() line discipline method
>   in tty_ldisc.h, line disciplines must not attempt i/o directly
>   from write_wakeup() as this will deadlock. Reviews of in-tree line
>   disciplines confirm all defer i/o.
>
>   NB: This workaround was added in commit c15c3747ee32
>   ("serial: samsung: fix potential soft lockup during uart write")
>   which notes both slip and bluetooth hci attempt i/o directly from
>   write_wakeup(). These issues were fixed in commits 661f7fda21b1
>   ("slip: Fix deadlock in write_wakeup") and da64c27d3c93
>   ("bluetooth: hci_ldisc: fix deadlock condition"), respectively.

Thanks Peter for thorough analysis. It shouldn't be done by you but by
the patch submitter... and I have big worries that Anand did not
perform that analysis.

Anand, could you at least test that this lockup does not happen
anymore? You will need board with Bluetooth for that (and not USB
Bluetooth...). If you cannot test it, maybe guys from Polish R could
help you (Cc-ed), because they were working on DMA for serial used in
Bluetooth.

Best regards,
Krzysztof

[PATCH 1/3] btrfs: backref: String formatting fixes

[Simon Quigley]

Checkpatch warns about a multi-line string

This fixes that issue and seperates the variables to another line

Signed-off-by: Simon Quigley 
---
 fs/btrfs/backref.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index 956fffa..a2c0595 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -1795,9 +1795,9 @@ static int iterate_inode_refs(u64 inum, struct btrfs_root 
*fs_root,
for (cur = 0; cur < btrfs_item_size(eb, item); cur += len) {
name_len = btrfs_inode_ref_name_len(eb, iref);
/* path must be released before calling iterate()! */
-   pr_debug("following ref at offset %u for inode %llu in "
-"tree %llu\n", cur, found_key.objectid,
-fs_root->objectid);
+   pr_debug("following ref at offset %u for inode %llu in 
tree %llu\n",
+   cur, found_key.objectid,
+   fs_root->objectid);
ret = iterate(parent, name_len,
  (unsigned long)(iref + 1), eb, ctx);
if (ret)
-- 
2.7.0

[PATCH 2/3] btrfs: backref: Fixed string formatting error

[Simon Quigley]

Checkpatch reported an error that there was a multi-line string.

This puts the string on one line and the variables on another.

Signed-off-by: Simon Quigley 
---
 fs/btrfs/backref.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index a2c0595..632845a 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -1696,9 +1696,8 @@ int iterate_extent_inodes(struct btrfs_fs_info *fs_info,
break;
ULIST_ITER_INIT(_uiter);
while (!ret && (root_node = ulist_next(roots, _uiter))) {
-   pr_debug("root %llu references leaf %llu, data list "
-"%#llx\n", root_node->val, ref_node->val,
-ref_node->aux);
+   pr_debug("root %llu references leaf %llu, data list 
%#llx\n",
+   root_node->val, ref_node->val, ref_node->aux);
ret = iterate_leaf_refs((struct extent_inode_elem *)
(uintptr_t)ref_node->aux,
root_node->val,
-- 
2.7.0

[PATCH 1/3] btrfs: backref: String formatting fixes

[Simon Quigley]

Checkpatch warns about a multi-line string

This fixes that issue and seperates the variables to another line

Signed-off-by: Simon Quigley 
---
 fs/btrfs/backref.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index 956fffa..a2c0595 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -1795,9 +1795,9 @@ static int iterate_inode_refs(u64 inum, struct btrfs_root 
*fs_root,
for (cur = 0; cur < btrfs_item_size(eb, item); cur += len) {
name_len = btrfs_inode_ref_name_len(eb, iref);
/* path must be released before calling iterate()! */
-   pr_debug("following ref at offset %u for inode %llu in "
-"tree %llu\n", cur, found_key.objectid,
-fs_root->objectid);
+   pr_debug("following ref at offset %u for inode %llu in 
tree %llu\n",
+   cur, found_key.objectid,
+   fs_root->objectid);
ret = iterate(parent, name_len,
  (unsigned long)(iref + 1), eb, ctx);
if (ret)
-- 
2.7.0

[PATCH 2/3] btrfs: backref: Fixed string formatting error

[Simon Quigley]

Checkpatch reported an error that there was a multi-line string.

This puts the string on one line and the variables on another.

Signed-off-by: Simon Quigley 
---
 fs/btrfs/backref.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index a2c0595..632845a 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -1696,9 +1696,8 @@ int iterate_extent_inodes(struct btrfs_fs_info *fs_info,
break;
ULIST_ITER_INIT(_uiter);
while (!ret && (root_node = ulist_next(roots, _uiter))) {
-   pr_debug("root %llu references leaf %llu, data list "
-"%#llx\n", root_node->val, ref_node->val,
-ref_node->aux);
+   pr_debug("root %llu references leaf %llu, data list 
%#llx\n",
+   root_node->val, ref_node->val, ref_node->aux);
ret = iterate_leaf_refs((struct extent_inode_elem *)
(uintptr_t)ref_node->aux,
root_node->val,
-- 
2.7.0

[PATCH 3/3] btrfs: backref: Fixed string error generated by Checkpatch

[Simon Quigley]

Checkpatch threw an error that this string was on two lines.

I put the string on one line and the variables on the other

Signed-off-by: Simon Quigley 
---
 fs/btrfs/backref.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index 632845a..6e694f7 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -1636,9 +1636,8 @@ static int iterate_leaf_refs(struct extent_inode_elem 
*inode_list,
int ret = 0;
 
for (eie = inode_list; eie; eie = eie->next) {
-   pr_debug("ref for %llu resolved, key (%llu EXTEND_DATA %llu), "
-"root %llu\n", extent_item_objectid,
-eie->inum, eie->offset, root);
+   pr_debug("ref for %llu resolved, key (%llu EXTEND_DATA %llu), 
root %llu\n",
+   extent_item_objectid, eie->inum, eie->offset, root);
ret = iterate(eie->inum, eie->offset, root, ctx);
if (ret) {
pr_debug("stopping iteration for %llu due to ret=%d\n",
-- 
2.7.0

[PATCH 3/3] btrfs: backref: Fixed string error generated by Checkpatch

[Simon Quigley]

Checkpatch threw an error that this string was on two lines.

I put the string on one line and the variables on the other

Signed-off-by: Simon Quigley 
---
 fs/btrfs/backref.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index 632845a..6e694f7 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -1636,9 +1636,8 @@ static int iterate_leaf_refs(struct extent_inode_elem 
*inode_list,
int ret = 0;
 
for (eie = inode_list; eie; eie = eie->next) {
-   pr_debug("ref for %llu resolved, key (%llu EXTEND_DATA %llu), "
-"root %llu\n", extent_item_objectid,
-eie->inum, eie->offset, root);
+   pr_debug("ref for %llu resolved, key (%llu EXTEND_DATA %llu), 
root %llu\n",
+   extent_item_objectid, eie->inum, eie->offset, root);
ret = iterate(eie->inum, eie->offset, root, ctx);
if (ret) {
pr_debug("stopping iteration for %llu due to ret=%d\n",
-- 
2.7.0

Re: [PATCH] serial: samsung: fix the inconsistency in spinlock

[Krzysztof Kozlowski]

>>> In my next patch I have tried to remove the spin_unlock/spin_lock over
>>> uart_write_wakeup(port);
>>
>> Which may create lockups. Previously there was no port locking around
>> uart_write_wakeup. Now there will be. You are effectively adding locking
>> over uart_write_wakeup().
>> Again, we are back at the Peter's message - just check the damned lockups...
>>
>> BR,
>> Krzysztof
>>
>> BR
>>
>
> Lets drop this patch. I have send new one earlier.
> https://lkml.org/lkml/2016/2/19/2
>
> If you have any comment on that.
> Sorry for the confusion.

I was commenting your future patch about dropping spinlocks.
Apparently there is huge misunderstanding here...

Best regards,
Krzysztof

Re: [PATCH] serial: samsung: fix the inconsistency in spinlock

[Krzysztof Kozlowski]

>>> In my next patch I have tried to remove the spin_unlock/spin_lock over
>>> uart_write_wakeup(port);
>>
>> Which may create lockups. Previously there was no port locking around
>> uart_write_wakeup. Now there will be. You are effectively adding locking
>> over uart_write_wakeup().
>> Again, we are back at the Peter's message - just check the damned lockups...
>>
>> BR,
>> Krzysztof
>>
>> BR
>>
>
> Lets drop this patch. I have send new one earlier.
> https://lkml.org/lkml/2016/2/19/2
>
> If you have any comment on that.
> Sorry for the confusion.

I was commenting your future patch about dropping spinlocks.
Apparently there is huge misunderstanding here...

Best regards,
Krzysztof

Re: [PATCH] btrfs: backref: Fixed checkpatch warning of over 80

[Simon Quigley]

Better?

On 02/20/2016 06:56 PM, Simon Quigley wrote:

checkpatch.pl reported a warning of over 80 characters on line 1833

Adjusted to put  and  on a different line

Signed-off-by: Simon Quigley 
---
  fs/btrfs/backref.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index f6dac40..956fffa 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -1830,8 +1830,8 @@ static int iterate_inode_extrefs(u64 inum, struct 
btrfs_root *fs_root,
unsigned long ptr;

while (1) {
-   ret = btrfs_find_one_extref(fs_root, inum, offset, path, 
,
-   );
+   ret = btrfs_find_one_extref(fs_root, inum, offset, path,
+   , );
if (ret < 0)
break;
if (ret) {

[PATCH] btrfs: backref: Fixed checkpatch warning of over 80

[Simon Quigley]

checkpatch.pl reported a warning of over 80 characters on line 1833

Adjusted to put  and  on a different line

Signed-off-by: Simon Quigley 
---
 fs/btrfs/backref.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index f6dac40..956fffa 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -1830,8 +1830,8 @@ static int iterate_inode_extrefs(u64 inum, struct 
btrfs_root *fs_root,
unsigned long ptr;
 
while (1) {
-   ret = btrfs_find_one_extref(fs_root, inum, offset, path, 
,
-   );
+   ret = btrfs_find_one_extref(fs_root, inum, offset, path,
+   , );
if (ret < 0)
break;
if (ret) {
-- 
2.7.0

Re: [PATCH] btrfs: backref: Fixed checkpatch warning of over 80

[Simon Quigley]

Better?

On 02/20/2016 06:56 PM, Simon Quigley wrote:

checkpatch.pl reported a warning of over 80 characters on line 1833

Adjusted to put  and  on a different line

Signed-off-by: Simon Quigley 
---
  fs/btrfs/backref.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index f6dac40..956fffa 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -1830,8 +1830,8 @@ static int iterate_inode_extrefs(u64 inum, struct 
btrfs_root *fs_root,
unsigned long ptr;

while (1) {
-   ret = btrfs_find_one_extref(fs_root, inum, offset, path, 
,
-   );
+   ret = btrfs_find_one_extref(fs_root, inum, offset, path,
+   , );
if (ret < 0)
break;
if (ret) {

[PATCH] btrfs: backref: Fixed checkpatch warning of over 80

[Simon Quigley]

checkpatch.pl reported a warning of over 80 characters on line 1833

Adjusted to put  and  on a different line

Signed-off-by: Simon Quigley 
---
 fs/btrfs/backref.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
index f6dac40..956fffa 100644
--- a/fs/btrfs/backref.c
+++ b/fs/btrfs/backref.c
@@ -1830,8 +1830,8 @@ static int iterate_inode_extrefs(u64 inum, struct 
btrfs_root *fs_root,
unsigned long ptr;
 
while (1) {
-   ret = btrfs_find_one_extref(fs_root, inum, offset, path, 
,
-   );
+   ret = btrfs_find_one_extref(fs_root, inum, offset, path,
+   , );
if (ret < 0)
break;
if (ret) {
-- 
2.7.0

Re: [PATCH V6 1/2] regulator: Add document for MT6323 regulator

[Mark Brown]

On Wed, Feb 17, 2016 at 12:37:35PM +0100, John Crispin wrote:
> Signed-off-by: John Crispin 
> Cc: devicet...@vger.kernel.org

...and dropped due to the dependency on MFD changes that you didn't
mention :/  I can't apply this without a pull request from Lee with the
MFD changes for the chip that I can depend on, there's no separate
Kconfig symbol and the MFD is already merged causing build failures
(you've had mail from 0day about that).


signature.asc
Description: PGP signature

Re: [PATCH V6 1/2] regulator: Add document for MT6323 regulator

[Mark Brown]

On Wed, Feb 17, 2016 at 12:37:35PM +0100, John Crispin wrote:
> Signed-off-by: John Crispin 
> Cc: devicet...@vger.kernel.org

...and dropped due to the dependency on MFD changes that you didn't
mention :/  I can't apply this without a pull request from Lee with the
MFD changes for the chip that I can depend on, there's no separate
Kconfig symbol and the MFD is already merged causing build failures
(you've had mail from 0day about that).


signature.asc
Description: PGP signature

Re: [PATCH v5 1/8] ARM: dts: rockchip: add hdmi/vop device node for rk3036

[Heiko Stuebner]

Am Dienstag, 2. Februar 2016, 11:40:50 schrieb Caesar Wang:
> This patch adds the needed display info for rk3036 SOCs.
> 
> The rk3036 support two overlay plane and one hwc plane,
> it supports IOMMU, and its IOMMU same as rk3288's.
> Meanwhile, add the inno hdmi for HDMI display.
> 
> Signed-off-by: Caesar Wang 

I've split this into 3 patches (vop, hdmi, kylin enablement) and applied 
this to my dts32 branch.


Heiko

Re: [PATCH v5 1/8] ARM: dts: rockchip: add hdmi/vop device node for rk3036

[Heiko Stuebner]

Am Dienstag, 2. Februar 2016, 11:40:50 schrieb Caesar Wang:
> This patch adds the needed display info for rk3036 SOCs.
> 
> The rk3036 support two overlay plane and one hwc plane,
> it supports IOMMU, and its IOMMU same as rk3288's.
> Meanwhile, add the inno hdmi for HDMI display.
> 
> Signed-off-by: Caesar Wang 

I've split this into 3 patches (vop, hdmi, kylin enablement) and applied 
this to my dts32 branch.


Heiko

Re: [PATCH] jme: remove the jme driver as it is no longer maintained

[Diego Viola]

On Sat, Feb 20, 2016 at 10:16 PM, David Miller  wrote:
>
> Sorry, this is not how things work.
>
> You can suggest marking the driver unmaintained in MAINTAINERS if the
> listed developer has been unresponsive for a very long time.
>
> But removing the driver altogether is not prudent at all.
>
> Just because it doesn't work %100 the way you like, and nobody
> has worked on fixing your specific problems, isn't a reason to
> remove an entire driver _nor_ move it to -staging.
>
> In fact, this driver is quite cleanly written, follows all of the
> various coding style rules we have, and uses the vast majority of the
> kernel APIs properly.
>
> And those are the criteria for having something in staging, not that
> it has bugs.
>
> In fact it is so cleanly written, that you should be able to read it
> and figure out what the suspend/resume problem might be.  These are
> exactly the kind of drivers we want to keep in the tree.
>
> I'm sorry that your bugs didn't get fixed, but your response to that
> happening is not reasonable at all.

OK my sincere apologies.

I've been very frustrated trying to deal with this bug and I couldn't
find a solution yet, but I will continue to see what I can do to fix
it.

I would appreciate some hint from someone who is more experienced with drivers.

Anyways, sorry about my behavior.

Diego

Re: [PATCH] jme: remove the jme driver as it is no longer maintained

[Diego Viola]

On Sat, Feb 20, 2016 at 10:16 PM, David Miller  wrote:
>
> Sorry, this is not how things work.
>
> You can suggest marking the driver unmaintained in MAINTAINERS if the
> listed developer has been unresponsive for a very long time.
>
> But removing the driver altogether is not prudent at all.
>
> Just because it doesn't work %100 the way you like, and nobody
> has worked on fixing your specific problems, isn't a reason to
> remove an entire driver _nor_ move it to -staging.
>
> In fact, this driver is quite cleanly written, follows all of the
> various coding style rules we have, and uses the vast majority of the
> kernel APIs properly.
>
> And those are the criteria for having something in staging, not that
> it has bugs.
>
> In fact it is so cleanly written, that you should be able to read it
> and figure out what the suspend/resume problem might be.  These are
> exactly the kind of drivers we want to keep in the tree.
>
> I'm sorry that your bugs didn't get fixed, but your response to that
> happening is not reasonable at all.

OK my sincere apologies.

I've been very frustrated trying to deal with this bug and I couldn't
find a solution yet, but I will continue to see what I can do to fix
it.

I would appreciate some hint from someone who is more experienced with drivers.

Anyways, sorry about my behavior.

Diego

Re: [PATCH] jme: remove the jme driver as it is no longer maintained

[David Miller]

Sorry, this is not how things work.

You can suggest marking the driver unmaintained in MAINTAINERS if the
listed developer has been unresponsive for a very long time.

But removing the driver altogether is not prudent at all.

Just because it doesn't work %100 the way you like, and nobody
has worked on fixing your specific problems, isn't a reason to
remove an entire driver _nor_ move it to -staging.

In fact, this driver is quite cleanly written, follows all of the
various coding style rules we have, and uses the vast majority of the
kernel APIs properly.

And those are the criteria for having something in staging, not that
it has bugs.

In fact it is so cleanly written, that you should be able to read it
and figure out what the suspend/resume problem might be.  These are
exactly the kind of drivers we want to keep in the tree.

I'm sorry that your bugs didn't get fixed, but your response to that
happening is not reasonable at all.

Re: [PATCH] jme: remove the jme driver as it is no longer maintained

[David Miller]

Sorry, this is not how things work.

You can suggest marking the driver unmaintained in MAINTAINERS if the
listed developer has been unresponsive for a very long time.

But removing the driver altogether is not prudent at all.

Just because it doesn't work %100 the way you like, and nobody
has worked on fixing your specific problems, isn't a reason to
remove an entire driver _nor_ move it to -staging.

In fact, this driver is quite cleanly written, follows all of the
various coding style rules we have, and uses the vast majority of the
kernel APIs properly.

And those are the criteria for having something in staging, not that
it has bugs.

In fact it is so cleanly written, that you should be able to read it
and figure out what the suspend/resume problem might be.  These are
exactly the kind of drivers we want to keep in the tree.

I'm sorry that your bugs didn't get fixed, but your response to that
happening is not reasonable at all.

Re: [PATCH] btrfs: backref: Fixed checkpatch warning of over 80 characters

[Joe Perches]

On Sat, 2016-02-20 at 12:17 -0600, Simon Quigley wrote:
> checkpatch.pl reported a warning of over 80 characters on line 1833
[]
> diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
[]
> @@ -1830,7 +1830,11 @@ static int iterate_inode_extrefs(u64 inum, struct 
> btrfs_root *fs_root,
>   unsigned long ptr;
>  
>   while (1) {
> - ret = btrfs_find_one_extref(fs_root, inum, offset, path, 
> ,
> + ret = btrfs_find_one_extref(fs_root,
> + inum,
> + offset,
> + path,
> + ,
>   );

I think this is poor because all the arguments aren't aligned.

It'd be nicer like:

ret = btrfs_find_one_extref(fs_root, inum, offset, path,
, );

Re: [PATCH] btrfs: backref: Fixed checkpatch warning of over 80 characters

[Joe Perches]

On Sat, 2016-02-20 at 12:17 -0600, Simon Quigley wrote:
> checkpatch.pl reported a warning of over 80 characters on line 1833
[]
> diff --git a/fs/btrfs/backref.c b/fs/btrfs/backref.c
[]
> @@ -1830,7 +1830,11 @@ static int iterate_inode_extrefs(u64 inum, struct 
> btrfs_root *fs_root,
>   unsigned long ptr;
>  
>   while (1) {
> - ret = btrfs_find_one_extref(fs_root, inum, offset, path, 
> ,
> + ret = btrfs_find_one_extref(fs_root,
> + inum,
> + offset,
> + path,
> + ,
>   );

I think this is poor because all the arguments aren't aligned.

It'd be nicer like:

ret = btrfs_find_one_extref(fs_root, inum, offset, path,
, );

Re: [PATCH] rtc: Add an option to invalidate dates in 2038

[Alexandre Belloni]

On 21/02/2016 at 00:17:02 +0100, Alexandre Belloni wrote :
> All the failures seem quite random to me but the reports I get are not
> that precise.
> 
> I know it happens with PCF8523 and that can be true because the
> datasheet says the date is undefined at reset. The handling of the OS
> bit (that bit indicates the date is probably wrong) has to be fixed and
> I will take care of that.
> 
> If that is the only RTC with that particular issue, we clearly don't
> need my workaround. But As I say, I can ask but I don't have a clear
> list of the affected system and their RTC.
> 

I add that it also seem to affect the Allwinner A20 RTC. I'm not sure
how much we can trust the datasheet but it claims the reset value is 0
and I don't think there is a way to know whether the date is correct or
not.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH] rtc: Add an option to invalidate dates in 2038

[Alexandre Belloni]

On 21/02/2016 at 00:17:02 +0100, Alexandre Belloni wrote :
> All the failures seem quite random to me but the reports I get are not
> that precise.
> 
> I know it happens with PCF8523 and that can be true because the
> datasheet says the date is undefined at reset. The handling of the OS
> bit (that bit indicates the date is probably wrong) has to be fixed and
> I will take care of that.
> 
> If that is the only RTC with that particular issue, we clearly don't
> need my workaround. But As I say, I can ask but I don't have a clear
> list of the affected system and their RTC.
> 

I add that it also seem to affect the Allwinner A20 RTC. I'm not sure
how much we can trust the datasheet but it claims the reset value is 0
and I don't think there is a way to know whether the date is correct or
not.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [RESEND PATCH] drivers: android: correct the size of struct binder_uintptr_t for BC_DEAD_BINDER_DONE

[Greg Kroah-Hartman]

On Fri, Feb 19, 2016 at 07:08:40AM -0800, Olof Johansson wrote:
> Hi,
> 
> On Tue, Feb 16, 2016 at 5:32 PM, Nicolas Boichat  
> wrote:
> > From: Lisa Du 
> >
> > There's one point was missed in the patch commit da49889deb34 ("staging:
> > binder: Support concurrent 32 bit and 64 bit processes."). When configure
> > BINDER_IPC_32BIT, the size of binder_uintptr_t was 32bits, but size of
> > void * is 64bit on 64bit system. Correct it here.
> >
> > Signed-off-by: Lisa Du 
> > Signed-off-by: Nicolas Boichat 
> 
> Fixes: da49889deb34 ("staging: binder: Support concurrent 32 bit and
> 64 bit processes.")
> Cc: 
> Acked-by: Olof Johansson 
> 
> (Hopefully Greg's script adds all 3 tags when he applies the patch. :)

Now added, thanks.

greg k-h

Re: [RESEND PATCH] drivers: android: correct the size of struct binder_uintptr_t for BC_DEAD_BINDER_DONE

[Greg Kroah-Hartman]

On Fri, Feb 19, 2016 at 07:08:40AM -0800, Olof Johansson wrote:
> Hi,
> 
> On Tue, Feb 16, 2016 at 5:32 PM, Nicolas Boichat  
> wrote:
> > From: Lisa Du 
> >
> > There's one point was missed in the patch commit da49889deb34 ("staging:
> > binder: Support concurrent 32 bit and 64 bit processes."). When configure
> > BINDER_IPC_32BIT, the size of binder_uintptr_t was 32bits, but size of
> > void * is 64bit on 64bit system. Correct it here.
> >
> > Signed-off-by: Lisa Du 
> > Signed-off-by: Nicolas Boichat 
> 
> Fixes: da49889deb34 ("staging: binder: Support concurrent 32 bit and
> 64 bit processes.")
> Cc: 
> Acked-by: Olof Johansson 
> 
> (Hopefully Greg's script adds all 3 tags when he applies the patch. :)

Now added, thanks.

greg k-h

Re: [PATCH] staging: xgifb: Fix comment style

[Kroah-Hartman]

On Wed, Feb 17, 2016 at 02:53:34PM +0800, Bo YU wrote:
> Fix comments to use trailing */ on separate lines.
> 
> Signed-off-by: YU BO 
> ---
>   drivers/staging/xgifb/vb_init.c |   10 +-
>   1 file changed, 5 insertions(+), 5 deletions(-)

Patch doesn't apply :(

Re: [PATCH] staging: xgifb: Fix comment style

[Kroah-Hartman]

On Wed, Feb 17, 2016 at 02:53:34PM +0800, Bo YU wrote:
> Fix comments to use trailing */ on separate lines.
> 
> Signed-off-by: YU BO 
> ---
>   drivers/staging/xgifb/vb_init.c |   10 +-
>   1 file changed, 5 insertions(+), 5 deletions(-)

Patch doesn't apply :(

Re: [PATCH] staging: lusture: obdclass: Remove unnecessary NULL check

[Greg Kroah-Hartman]

On Thu, Feb 18, 2016 at 08:55:39PM +0530, Bhaktipriya Shridhar wrote:
> NULL check before the  debugfs_remove_recursive function is not needed.
> 
> This was detected using scripts/coccinelle/free/ifnullfree.cocci
> 
> Signed-off-by: Bhaktipriya Shridhar 
> ---
>  drivers/staging/lustre/lustre/obdclass/linux/linux-module.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)


Doesn't apply to my tree :(

Re: [PATCH] staging: lusture: obdclass: Remove unnecessary NULL check

[Greg Kroah-Hartman]

On Thu, Feb 18, 2016 at 08:55:39PM +0530, Bhaktipriya Shridhar wrote:
> NULL check before the  debugfs_remove_recursive function is not needed.
> 
> This was detected using scripts/coccinelle/free/ifnullfree.cocci
> 
> Signed-off-by: Bhaktipriya Shridhar 
> ---
>  drivers/staging/lustre/lustre/obdclass/linux/linux-module.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)


Doesn't apply to my tree :(

Re: [PATCH v6 20/25] perf hists browser: Implement hierarchy output

[Jiri Olsa]

On Tue, Feb 16, 2016 at 11:08:38PM +0900, Namhyung Kim wrote:
> Implement hierarchy mode in TUI.  The output is look like stdio but it
> also supports to fold/unfold children dynamically.
> 
> Acked-by: Pekka Enberg 
> Signed-off-by: Namhyung Kim 
> ---
>  tools/perf/ui/browsers/hists.c | 269 
> +
>  1 file changed, 247 insertions(+), 22 deletions(-)
> 
> diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
> index 857b9beb0aab..d209cf07bd12 100644
> --- a/tools/perf/ui/browsers/hists.c
> +++ b/tools/perf/ui/browsers/hists.c
> @@ -1260,6 +1260,137 @@ static int hist_browser__show_entry(struct 
> hist_browser *browser,
>   return printed;
>  }
>  
> +static int hist_browser__show_hierarchy_entry(struct hist_browser *browser,
> +   struct hist_entry *entry,
> +   unsigned short row,
> +   int level, int nr_sort_keys)
> +{

SNIP

> +
> + hists__for_each_format(entry->hists, fmt) {
> + if (perf_hpp__should_skip(fmt, entry->hists) ||
> + column++ < browser->b.horiz_scroll)
> + continue;
> +
> + if (perf_hpp__is_sort_entry(fmt) ||
> + perf_hpp__is_dynamic_entry(fmt))
> + break;
> +
> + if (current_entry && browser->b.navkeypressed) {
> + ui_browser__set_color(>b,
> +   HE_COLORSET_SELECTED);
> + } else {
> + ui_browser__set_color(>b,
> +   HE_COLORSET_NORMAL);
> + }
> +
> + if (first) {
> + ui_browser__printf(>b, "%c", folded_sign);
> + width--;
> + first = false;
> + } else {
> + ui_browser__printf(>b, "  ");
> + width -= 2;
> + }
> +
> + if (fmt->color) {
> + width -= fmt->color(fmt, , entry);
> + } else {
> + width -= fmt->entry(fmt, , entry);
> + ui_browser__printf(>b, "%s", s);
> + }

same as for stdio patch comment, you might want to use
hist_entry__snprintf_alignment in here

jirka

Re: [PATCH v6 10/25] perf hists: Resort hist entries with hierarchy

[Jiri Olsa]

On Tue, Feb 16, 2016 at 11:08:28PM +0900, Namhyung Kim wrote:

SNIP

> @@ -1349,6 +1427,17 @@ static void output_resort(struct hists *hists, struct 
> ui_progress *prog,
>  
>   min_callchain_hits = callchain_total * (callchain_param.min_percent / 
> 100);
>  
> + hists__reset_stats(hists);
> + hists__reset_col_len(hists);
> +
> + if (symbol_conf.report_hierarchy) {
> + return hists__hierarchy_output_resort(hists, prog,
> +   >entries_collapsed,
> +   >entries,
> +   min_callchain_hits,
> +   use_callchain);
> + }
> +
>   if (sort__need_collapse)
>   root = >entries_collapsed;
>   else
> @@ -1357,9 +1446,6 @@ static void output_resort(struct hists *hists, struct 
> ui_progress *prog,
>   next = rb_first(root);
>   hists->entries = RB_ROOT;

above line could be moved together with those 2 below
and you can then remove *root_out = RB_ROOT; line in
hists__hierarchy_output_resort

jirka

>  
> - hists__reset_stats(hists);
> - hists__reset_col_len(hists);
> -
>   while (next) {
>   n = rb_entry(next, struct hist_entry, rb_node_in);
>   next = rb_next(>rb_node_in);
> -- 
> 2.7.1
> 

Re: [PATCH v6 25/25] perf top: Add --hierarchy option

[Jiri Olsa]

On Tue, Feb 16, 2016 at 11:08:43PM +0900, Namhyung Kim wrote:
> Support hierarchy output for perf-top using --hierarchy option.
> 
> Acked-by: Pekka Enberg 
> Signed-off-by: Namhyung Kim 
> ---
>  tools/perf/Documentation/perf-top.txt |  3 +++
>  tools/perf/builtin-top.c  | 15 +++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/tools/perf/Documentation/perf-top.txt 
> b/tools/perf/Documentation/perf-top.txt
> index b0e60e17db38..19f046f027cd 100644
> --- a/tools/perf/Documentation/perf-top.txt
> +++ b/tools/perf/Documentation/perf-top.txt
> @@ -233,6 +233,9 @@ Default is to monitor all CPUS.
>  --raw-trace::
>   When displaying traceevent output, do not use print fmt or plugins.
>  
> +--hierarchy::
> + Enable hierarchy output.
> +
>  INTERACTIVE PROMPTING KEYS
>  --
>  
> diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
> index a75de3940b97..b86b623e8799 100644
> --- a/tools/perf/builtin-top.c
> +++ b/tools/perf/builtin-top.c
> @@ -1214,6 +1214,8 @@ int cmd_top(int argc, const char **argv, const char 
> *prefix __maybe_unused)
>parse_branch_stack),
>   OPT_BOOLEAN(0, "raw-trace", _conf.raw_trace,
>   "Show raw trace event output (do not use print fmt or 
> plugins)"),
> + OPT_BOOLEAN(0, "hierarchy", _conf.report_hierarchy,
> + "Show entries in a hierarchy"),

hum, I'm not getting --children (default) output with hierarchy?

I can't see this was intentional.. haven't found the reason yet

thanks,
jirka

Re: [PATCH v6 20/25] perf hists browser: Implement hierarchy output

[Jiri Olsa]

On Tue, Feb 16, 2016 at 11:08:38PM +0900, Namhyung Kim wrote:
> Implement hierarchy mode in TUI.  The output is look like stdio but it
> also supports to fold/unfold children dynamically.
> 
> Acked-by: Pekka Enberg 
> Signed-off-by: Namhyung Kim 
> ---
>  tools/perf/ui/browsers/hists.c | 269 
> +
>  1 file changed, 247 insertions(+), 22 deletions(-)
> 
> diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
> index 857b9beb0aab..d209cf07bd12 100644
> --- a/tools/perf/ui/browsers/hists.c
> +++ b/tools/perf/ui/browsers/hists.c
> @@ -1260,6 +1260,137 @@ static int hist_browser__show_entry(struct 
> hist_browser *browser,
>   return printed;
>  }
>  
> +static int hist_browser__show_hierarchy_entry(struct hist_browser *browser,
> +   struct hist_entry *entry,
> +   unsigned short row,
> +   int level, int nr_sort_keys)
> +{

SNIP

> +
> + hists__for_each_format(entry->hists, fmt) {
> + if (perf_hpp__should_skip(fmt, entry->hists) ||
> + column++ < browser->b.horiz_scroll)
> + continue;
> +
> + if (perf_hpp__is_sort_entry(fmt) ||
> + perf_hpp__is_dynamic_entry(fmt))
> + break;
> +
> + if (current_entry && browser->b.navkeypressed) {
> + ui_browser__set_color(>b,
> +   HE_COLORSET_SELECTED);
> + } else {
> + ui_browser__set_color(>b,
> +   HE_COLORSET_NORMAL);
> + }
> +
> + if (first) {
> + ui_browser__printf(>b, "%c", folded_sign);
> + width--;
> + first = false;
> + } else {
> + ui_browser__printf(>b, "  ");
> + width -= 2;
> + }
> +
> + if (fmt->color) {
> + width -= fmt->color(fmt, , entry);
> + } else {
> + width -= fmt->entry(fmt, , entry);
> + ui_browser__printf(>b, "%s", s);
> + }

same as for stdio patch comment, you might want to use
hist_entry__snprintf_alignment in here

jirka

Re: [PATCH v6 10/25] perf hists: Resort hist entries with hierarchy

[Jiri Olsa]

On Tue, Feb 16, 2016 at 11:08:28PM +0900, Namhyung Kim wrote:

SNIP

> @@ -1349,6 +1427,17 @@ static void output_resort(struct hists *hists, struct 
> ui_progress *prog,
>  
>   min_callchain_hits = callchain_total * (callchain_param.min_percent / 
> 100);
>  
> + hists__reset_stats(hists);
> + hists__reset_col_len(hists);
> +
> + if (symbol_conf.report_hierarchy) {
> + return hists__hierarchy_output_resort(hists, prog,
> +   >entries_collapsed,
> +   >entries,
> +   min_callchain_hits,
> +   use_callchain);
> + }
> +
>   if (sort__need_collapse)
>   root = >entries_collapsed;
>   else
> @@ -1357,9 +1446,6 @@ static void output_resort(struct hists *hists, struct 
> ui_progress *prog,
>   next = rb_first(root);
>   hists->entries = RB_ROOT;

above line could be moved together with those 2 below
and you can then remove *root_out = RB_ROOT; line in
hists__hierarchy_output_resort

jirka

>  
> - hists__reset_stats(hists);
> - hists__reset_col_len(hists);
> -
>   while (next) {
>   n = rb_entry(next, struct hist_entry, rb_node_in);
>   next = rb_next(>rb_node_in);
> -- 
> 2.7.1
> 

Re: [PATCH v6 25/25] perf top: Add --hierarchy option

[Jiri Olsa]

On Tue, Feb 16, 2016 at 11:08:43PM +0900, Namhyung Kim wrote:
> Support hierarchy output for perf-top using --hierarchy option.
> 
> Acked-by: Pekka Enberg 
> Signed-off-by: Namhyung Kim 
> ---
>  tools/perf/Documentation/perf-top.txt |  3 +++
>  tools/perf/builtin-top.c  | 15 +++
>  2 files changed, 18 insertions(+)
> 
> diff --git a/tools/perf/Documentation/perf-top.txt 
> b/tools/perf/Documentation/perf-top.txt
> index b0e60e17db38..19f046f027cd 100644
> --- a/tools/perf/Documentation/perf-top.txt
> +++ b/tools/perf/Documentation/perf-top.txt
> @@ -233,6 +233,9 @@ Default is to monitor all CPUS.
>  --raw-trace::
>   When displaying traceevent output, do not use print fmt or plugins.
>  
> +--hierarchy::
> + Enable hierarchy output.
> +
>  INTERACTIVE PROMPTING KEYS
>  --
>  
> diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
> index a75de3940b97..b86b623e8799 100644
> --- a/tools/perf/builtin-top.c
> +++ b/tools/perf/builtin-top.c
> @@ -1214,6 +1214,8 @@ int cmd_top(int argc, const char **argv, const char 
> *prefix __maybe_unused)
>parse_branch_stack),
>   OPT_BOOLEAN(0, "raw-trace", _conf.raw_trace,
>   "Show raw trace event output (do not use print fmt or 
> plugins)"),
> + OPT_BOOLEAN(0, "hierarchy", _conf.report_hierarchy,
> + "Show entries in a hierarchy"),

hum, I'm not getting --children (default) output with hierarchy?

I can't see this was intentional.. haven't found the reason yet

thanks,
jirka

Re: [PATCH v6 09/25] perf hists: Basic support of hierarchical report view

[Jiri Olsa]

On Tue, Feb 16, 2016 at 11:08:27PM +0900, Namhyung Kim wrote:

SNIP

> + int64_t cmp;
> +
> + while (*p != NULL) {
> + parent = *p;
> + iter = rb_entry(parent, struct hist_entry, rb_node_in);
> +
> + cmp = fmt->collapse(fmt, iter, he);
> + if (!cmp) {
> + he_stat__add_stat(>stat, >stat);
> + return iter;
> + }
> +
> + if (cmp < 0)
> + p = >rb_left;
> + else
> + p = >rb_right;
> + }
> +
> + new = hist_entry__new(he, true);
> + if (new == NULL)
> + return NULL;
> +
> + hists__apply_filters(hists, new);
> + hists->nr_entries++;
> +
> + /* save related format for output */
> + new->fmt = fmt;
> +
> + /* it's now passed to 'new' */
> + he->trace_output = NULL;

should you do the same to he->srcline ?

jirka

Re: [PATCH v6 09/25] perf hists: Basic support of hierarchical report view

[Jiri Olsa]

On Tue, Feb 16, 2016 at 11:08:27PM +0900, Namhyung Kim wrote:

SNIP

> + int64_t cmp;
> +
> + while (*p != NULL) {
> + parent = *p;
> + iter = rb_entry(parent, struct hist_entry, rb_node_in);
> +
> + cmp = fmt->collapse(fmt, iter, he);
> + if (!cmp) {
> + he_stat__add_stat(>stat, >stat);
> + return iter;
> + }
> +
> + if (cmp < 0)
> + p = >rb_left;
> + else
> + p = >rb_right;
> + }
> +
> + new = hist_entry__new(he, true);
> + if (new == NULL)
> + return NULL;
> +
> + hists__apply_filters(hists, new);
> + hists->nr_entries++;
> +
> + /* save related format for output */
> + new->fmt = fmt;
> +
> + /* it's now passed to 'new' */
> + he->trace_output = NULL;

should you do the same to he->srcline ?

jirka

Re: [PATCH v6 16/25] perf ui/stdio: Implement hierarchy output mode

[Jiri Olsa]

On Tue, Feb 16, 2016 at 11:08:34PM +0900, Namhyung Kim wrote:

SNIP

> +static int hist_entry__hierarchy_fprintf(struct hist_entry *he,
> +  struct perf_hpp *hpp,
> +  int nr_sort_key, struct hists *hists,
> +  FILE *fp)
> +{
> + const char *sep = symbol_conf.field_sep;
> + struct perf_hpp_fmt *fmt;
> + char *buf = hpp->buf;
> + int ret, printed = 0;
> + bool first = true;
> +
> + if (symbol_conf.exclude_other && !he->parent)
> + return 0;
> +
> + ret = scnprintf(hpp->buf, hpp->size, "%*s", he->depth * 
> HIERARCHY_INDENT, "");
> + advance_hpp(hpp, ret);
> +
> + hists__for_each_format(he->hists, fmt) {
> + if (perf_hpp__is_sort_entry(fmt) || 
> perf_hpp__is_dynamic_entry(fmt))
> + break;
> +
> + /*
> +  * If there's no field_sep, we still need
> +  * to display initial '  '.
> +  */
> + if (!sep || !first) {
> + ret = scnprintf(hpp->buf, hpp->size, "%s", sep ?: "  ");
> + advance_hpp(hpp, ret);
> + } else
> + first = false;
> +
> + if (perf_hpp__use_color() && fmt->color)
> + ret = fmt->color(fmt, hpp, he);
> + else
> + ret = fmt->entry(fmt, hpp, he);
> +
> + advance_hpp(hpp, ret);

there's new hist_entry__snprintf_alignment function for
proper alignment now used in hist_entry__hierarchy_fprintf

you might wat to use it in here as well

jirka

Re: [PATCH v6 16/25] perf ui/stdio: Implement hierarchy output mode

[Jiri Olsa]

On Tue, Feb 16, 2016 at 11:08:34PM +0900, Namhyung Kim wrote:

SNIP

> +static int hist_entry__hierarchy_fprintf(struct hist_entry *he,
> +  struct perf_hpp *hpp,
> +  int nr_sort_key, struct hists *hists,
> +  FILE *fp)
> +{
> + const char *sep = symbol_conf.field_sep;
> + struct perf_hpp_fmt *fmt;
> + char *buf = hpp->buf;
> + int ret, printed = 0;
> + bool first = true;
> +
> + if (symbol_conf.exclude_other && !he->parent)
> + return 0;
> +
> + ret = scnprintf(hpp->buf, hpp->size, "%*s", he->depth * 
> HIERARCHY_INDENT, "");
> + advance_hpp(hpp, ret);
> +
> + hists__for_each_format(he->hists, fmt) {
> + if (perf_hpp__is_sort_entry(fmt) || 
> perf_hpp__is_dynamic_entry(fmt))
> + break;
> +
> + /*
> +  * If there's no field_sep, we still need
> +  * to display initial '  '.
> +  */
> + if (!sep || !first) {
> + ret = scnprintf(hpp->buf, hpp->size, "%s", sep ?: "  ");
> + advance_hpp(hpp, ret);
> + } else
> + first = false;
> +
> + if (perf_hpp__use_color() && fmt->color)
> + ret = fmt->color(fmt, hpp, he);
> + else
> + ret = fmt->entry(fmt, hpp, he);
> +
> + advance_hpp(hpp, ret);

there's new hist_entry__snprintf_alignment function for
proper alignment now used in hist_entry__hierarchy_fprintf

you might wat to use it in here as well

jirka

Re: [PATCH] rtc: Add an option to invalidate dates in 2038

[Alexandre Belloni]

On 20/02/2016 at 23:16:48 +0100, Arnd Bergmann wrote :
> On Saturday 20 February 2016 21:47:15 Alexandre Belloni wrote:
> > 
> > Actually, I'm not trying to solve the 2038 issue.
> > 
> > But in the current state on 32 bit platforms, while the kernel is able
> > to handle a 64bit date, userspace is not. The main issue is that
> > distributions use HCTOSYS so if the RTC is set to a date after 2038
> > (which we know is currently bogus), the kernel will set a system time to
> > that date.
> > 
> > This result in a system that fails when using timerfd, The timerfd will
> > always fire immediately (until, as some people pointed out, we have
> > relative timers).
> > 
> > This is know to break systemd [1] but I have had reports for other
> > failing applications.
> > 
> > I understand this is a workaround and I plan to switch the default to n
> > once libc and critical userspace is able to handle 64 bit time.
> > 
> > The other way of solving that is to get back to a 32 bit time_t
> > internally until we switch the whole userspace to a 64 bit time_t but I
> > don't think this is practical.
> > 
> > [1] https://github.com/systemd/systemd/issues/1143
> > 
> 
> I think in both cases you introduce a new 2038 problem though:
> as long as you have a kernel that tries to support an old
> 32-bit systemd build, the kernel becomes incompatible with RTC
> times beyond 2038, even on 64-bit systems and 32-bit systems
> that have fixed system call table and fixed user space.
> 

It doesn't change anything for 64-bit systems, I've excluded them by
using "depends on !64BIT". Right now, it doesn't change anything for
32-bit systems because either way, they will fail in 2038.

> This is bad because it means we still have to break systemd
> eventually in order to fix the 2038 overflow.
> 

Won't we have to recompile every application to support 64-bit time on
32-bit system anyway? That will be a good time to remove that option.

> The plan to revert this after glibc has been converted is
> problematic because a lot of 32-bit distros will likely never
> recompile with 64-bit time_t in order to avoid breaking
> backwards compatibility. While we could require that user
> space and kernel must match here (either support 64-bit time_t
> everywhere or nowhere), that makes it much harder to deal
> with the migration, and it has always been a strict requirement
> that none of the changes for y2038 compatibility break existing
> user space (which of course is what happened for RTC and what
> we need to fix here).

If the distribution don't recompile to support a 64-bit time, then the
32-bit systems will break in 2038 anyway and they will absolutely
require my patch or something along those lines to still boot using
systemd.

> 
> Has the problem of random RTC times been observed on more than
> one RTC driver yet? Maybe we can just apply your workaround
> to that one driver that saw it instead.
> 
> Have you figured out whether there is a pattern in the reported
> times? Is it just completely random or could we perhaps
> detect an RTC that reports an invalid time other than by 
> looking at the year?
> 

All the failures seem quite random to me but the reports I get are not
that precise.

I know it happens with PCF8523 and that can be true because the
datasheet says the date is undefined at reset. The handling of the OS
bit (that bit indicates the date is probably wrong) has to be fixed and
I will take care of that.

If that is the only RTC with that particular issue, we clearly don't
need my workaround. But As I say, I can ask but I don't have a clear
list of the affected system and their RTC.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Re: [PATCH] rtc: Add an option to invalidate dates in 2038

[Alexandre Belloni]

On 20/02/2016 at 23:16:48 +0100, Arnd Bergmann wrote :
> On Saturday 20 February 2016 21:47:15 Alexandre Belloni wrote:
> > 
> > Actually, I'm not trying to solve the 2038 issue.
> > 
> > But in the current state on 32 bit platforms, while the kernel is able
> > to handle a 64bit date, userspace is not. The main issue is that
> > distributions use HCTOSYS so if the RTC is set to a date after 2038
> > (which we know is currently bogus), the kernel will set a system time to
> > that date.
> > 
> > This result in a system that fails when using timerfd, The timerfd will
> > always fire immediately (until, as some people pointed out, we have
> > relative timers).
> > 
> > This is know to break systemd [1] but I have had reports for other
> > failing applications.
> > 
> > I understand this is a workaround and I plan to switch the default to n
> > once libc and critical userspace is able to handle 64 bit time.
> > 
> > The other way of solving that is to get back to a 32 bit time_t
> > internally until we switch the whole userspace to a 64 bit time_t but I
> > don't think this is practical.
> > 
> > [1] https://github.com/systemd/systemd/issues/1143
> > 
> 
> I think in both cases you introduce a new 2038 problem though:
> as long as you have a kernel that tries to support an old
> 32-bit systemd build, the kernel becomes incompatible with RTC
> times beyond 2038, even on 64-bit systems and 32-bit systems
> that have fixed system call table and fixed user space.
> 

It doesn't change anything for 64-bit systems, I've excluded them by
using "depends on !64BIT". Right now, it doesn't change anything for
32-bit systems because either way, they will fail in 2038.

> This is bad because it means we still have to break systemd
> eventually in order to fix the 2038 overflow.
> 

Won't we have to recompile every application to support 64-bit time on
32-bit system anyway? That will be a good time to remove that option.

> The plan to revert this after glibc has been converted is
> problematic because a lot of 32-bit distros will likely never
> recompile with 64-bit time_t in order to avoid breaking
> backwards compatibility. While we could require that user
> space and kernel must match here (either support 64-bit time_t
> everywhere or nowhere), that makes it much harder to deal
> with the migration, and it has always been a strict requirement
> that none of the changes for y2038 compatibility break existing
> user space (which of course is what happened for RTC and what
> we need to fix here).

If the distribution don't recompile to support a 64-bit time, then the
32-bit systems will break in 2038 anyway and they will absolutely
require my patch or something along those lines to still boot using
systemd.

> 
> Has the problem of random RTC times been observed on more than
> one RTC driver yet? Maybe we can just apply your workaround
> to that one driver that saw it instead.
> 
> Have you figured out whether there is a pattern in the reported
> times? Is it just completely random or could we perhaps
> detect an RTC that reports an invalid time other than by 
> looking at the year?
> 

All the failures seem quite random to me but the reports I get are not
that precise.

I know it happens with PCF8523 and that can be true because the
datasheet says the date is undefined at reset. The handling of the OS
bit (that bit indicates the date is probably wrong) has to be fixed and
I will take care of that.

If that is the only RTC with that particular issue, we clearly don't
need my workaround. But As I say, I can ask but I don't have a clear
list of the affected system and their RTC.


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

hello,

[Jack]

My name is Jack Antonik. I'm 45 years old, from the US. I'm in Syria right now 
fighting IS. I want to get to know you better, if I may be so bold. I consider 
myself an easy-going man, and I am currently looking for a relationship in 
which I feel loved.

Please tell me more about yourself, if you don't mind.

hello,

[Jack]

My name is Jack Antonik. I'm 45 years old, from the US. I'm in Syria right now 
fighting IS. I want to get to know you better, if I may be so bold. I consider 
myself an easy-going man, and I am currently looking for a relationship in 
which I feel loved.

Please tell me more about yourself, if you don't mind.

Re: [PATCH] Documentation/memory-barriers: fix wrong comment in example

[SeongJae Park]

On Sun, Feb 21, 2016 at 4:57 AM, Paul E. McKenney
 wrote:
> On Sat, Feb 20, 2016 at 03:01:08PM +0900, SeongJae Park wrote:
>> There is wrong comment in example for compiler store omit behavior.  It
>> shows example of the problem and than problem solved version code.
>> However, the comment in the solved version is still same with not solved
>> version.  Fix the wrong statement with this commit.
>>
>> Signed-off-by: SeongJae Park 
>
> Hmmm...  The code between the two stores of zero to "a" is intended to
> remain the same in the broken and fixed versions.  So the only change
> is from "a = 0" to "WRITE_ONCE(a, 0)".  Note that it is some other
> CPU that did the third store to "a".

Agree, of course.

>
> Or am I missing your point here?

My point is about the comment.
I thought the comment in broken version is saying "Below line(a = 0) says
it will store to variable 'a', but it will not in actual because a compiler can
omit it".
However, in fixed version, because the compiler cannot omit the store
now, I thought the comment also should be changed to say the difference
between broken and fixed version.

If I am understanding anything wrong, please let me know.


Thanks,
SeongJae Park

>
> Thanx, Paul
>
>> ---
>>  Documentation/memory-barriers.txt | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/memory-barriers.txt 
>> b/Documentation/memory-barriers.txt
>> index 061ff29..b4754c7 100644
>> --- a/Documentation/memory-barriers.txt
>> +++ b/Documentation/memory-barriers.txt
>> @@ -1471,7 +1471,7 @@ of optimizations:
>>   wrong guess:
>>
>>   WRITE_ONCE(a, 0);
>> - /* Code that does not store to variable a. */
>> + /* Code that does store to variable a. */
>>   WRITE_ONCE(a, 0);
>>
>>   (*) The compiler is within its rights to reorder memory accesses unless
>> --
>> 1.9.1
>>
>

Re: [PATCH] Documentation/memory-barriers: fix wrong comment in example

[SeongJae Park]

On Sun, Feb 21, 2016 at 4:57 AM, Paul E. McKenney
 wrote:
> On Sat, Feb 20, 2016 at 03:01:08PM +0900, SeongJae Park wrote:
>> There is wrong comment in example for compiler store omit behavior.  It
>> shows example of the problem and than problem solved version code.
>> However, the comment in the solved version is still same with not solved
>> version.  Fix the wrong statement with this commit.
>>
>> Signed-off-by: SeongJae Park 
>
> Hmmm...  The code between the two stores of zero to "a" is intended to
> remain the same in the broken and fixed versions.  So the only change
> is from "a = 0" to "WRITE_ONCE(a, 0)".  Note that it is some other
> CPU that did the third store to "a".

Agree, of course.

>
> Or am I missing your point here?

My point is about the comment.
I thought the comment in broken version is saying "Below line(a = 0) says
it will store to variable 'a', but it will not in actual because a compiler can
omit it".
However, in fixed version, because the compiler cannot omit the store
now, I thought the comment also should be changed to say the difference
between broken and fixed version.

If I am understanding anything wrong, please let me know.


Thanks,
SeongJae Park

>
> Thanx, Paul
>
>> ---
>>  Documentation/memory-barriers.txt | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/Documentation/memory-barriers.txt 
>> b/Documentation/memory-barriers.txt
>> index 061ff29..b4754c7 100644
>> --- a/Documentation/memory-barriers.txt
>> +++ b/Documentation/memory-barriers.txt
>> @@ -1471,7 +1471,7 @@ of optimizations:
>>   wrong guess:
>>
>>   WRITE_ONCE(a, 0);
>> - /* Code that does not store to variable a. */
>> + /* Code that does store to variable a. */
>>   WRITE_ONCE(a, 0);
>>
>>   (*) The compiler is within its rights to reorder memory accesses unless
>> --
>> 1.9.1
>>
>

Re: Requesting Thunderbolt 3 support

[Jeremy Carter]

On Sat, Feb 20, 2016 at 5:02 PM, Greg KH  wrote:
> Do you have any hardware that supports this that isn't working with the
> current Thunderbolt drivers?

I don't, but I may have access to some in the next week or two to test.

I assumed TB3 wouldn't be supported because it's different than TB2,
and there was nothing mentioned about TB3 in the kernel commits. Also
no-one on Freenode knew if TB3 was working on Linux.

I'll send an update to the list if I have to opportunity to confirm
whether or not it's working with the current driver.

Thanks,
Jeremy Carter

Re: Requesting Thunderbolt 3 support

[Jeremy Carter]

On Sat, Feb 20, 2016 at 5:02 PM, Greg KH  wrote:
> Do you have any hardware that supports this that isn't working with the
> current Thunderbolt drivers?

I don't, but I may have access to some in the next week or two to test.

I assumed TB3 wouldn't be supported because it's different than TB2,
and there was nothing mentioned about TB3 in the kernel commits. Also
no-one on Freenode knew if TB3 was working on Linux.

I'll send an update to the list if I have to opportunity to confirm
whether or not it's working with the current driver.

Thanks,
Jeremy Carter

Re: [RFC PATCH] drivers: ata: Read Rx water mark value from device-tree

[Arnd Bergmann]

On Saturday 20 February 2016 18:48:22 Anurag Kumar Vulisha wrote:
> index 7ca8b97..7e48dfc 100644
> --- a/Documentation/devicetree/bindings/ata/ahci-ceva.txt
> +++ b/Documentation/devicetree/bindings/ata/ahci-ceva.txt
> @@ -8,6 +8,7 @@ Required properties:
>  
>  Optional properties:
>- ceva,broken-gen2: limit to gen1 speed instead of gen2.
> +  - ceva,rx-watermark: RX fifo water mark level for SATA controller.
>  
>  Examples:
> ahci@fd0c {
> @@ -17,4 +18,5 @@ Examples:
> interrupts = <0 133 4>;
> clocks = < SATA_CLK_ID>;
> ceva,broken-gen2;
> +   ceva,rx-watermark = <0x40>;
> };
> 

How would a hardware integrator know which value is right for a
particular SoC?

Could it be keyed off the hardware ID? Could the bootloader
perhaps set an appropriate value in the AHCI_VEND_PTC
register at boot time and the driver read the initial
value from it?

>From the description, it sounds like this is a policy decision
rather than hardware description, and shouldn't really be
in here.

Arnd

Re: [RFC PATCH] drivers: ata: Read Rx water mark value from device-tree

[Arnd Bergmann]

On Saturday 20 February 2016 18:48:22 Anurag Kumar Vulisha wrote:
> index 7ca8b97..7e48dfc 100644
> --- a/Documentation/devicetree/bindings/ata/ahci-ceva.txt
> +++ b/Documentation/devicetree/bindings/ata/ahci-ceva.txt
> @@ -8,6 +8,7 @@ Required properties:
>  
>  Optional properties:
>- ceva,broken-gen2: limit to gen1 speed instead of gen2.
> +  - ceva,rx-watermark: RX fifo water mark level for SATA controller.
>  
>  Examples:
> ahci@fd0c {
> @@ -17,4 +18,5 @@ Examples:
> interrupts = <0 133 4>;
> clocks = < SATA_CLK_ID>;
> ceva,broken-gen2;
> +   ceva,rx-watermark = <0x40>;
> };
> 

How would a hardware integrator know which value is right for a
particular SoC?

Could it be keyed off the hardware ID? Could the bootloader
perhaps set an appropriate value in the AHCI_VEND_PTC
register at boot time and the driver read the initial
value from it?

>From the description, it sounds like this is a policy decision
rather than hardware description, and shouldn't really be
in here.

Arnd

Re: [PATCH 43/45] staging/lustre/libcfs: Replace use of printk with pr_

[Greg Kroah-Hartman]

On Tue, Feb 16, 2016 at 11:12:14AM -0500, Oleg Drokin wrote:
> 
> On Feb 16, 2016, at 12:55 AM, Joe Perches wrote:
> 
> > On Tue, 2016-02-16 at 00:47 -0500, gr...@linuxhacker.ru wrote:
> >> From: Oleg Drokin 
> >> 
> >> This pacifies checkpatch amongst other things, also is shorter to write
> >> and avoiding calls to printk_ratelimit() is also good.
> > []
> >> diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-tracefile.c 
> >> b/drivers/staging/lustre/lustre/libcfs/linux/linux-tracefile.c
> > []
> >> @@ -244,11 +244,11 @@ void cfs_print_to_console(struct ptldebug_header 
> >> *hdr, int mask,
> >>}
> >>  
> >>if ((mask & D_CONSOLE) != 0) {
> >> -  printk("%s%s: %.*s", ptype, prefix, len, buf);
> >> +  pr_err("%s%s: %.*s", ptype, prefix, len, buf);
> >>} else {
> >> -  printk("%s%s: %d:%d:(%s:%d:%s()) %.*s", ptype, prefix,
> >> - hdr->ph_pid, hdr->ph_extern_pid, file, hdr->ph_line_num,
> >> - fn, len, buf);
> >> +  pr_warn("%s%s: %d:%d:(%s:%d:%s()) %.*s", ptype, prefix,
> >> +  hdr->ph_pid, hdr->ph_extern_pid, file, hdr->ph_line_num,
> >> +  fn, len, buf);
> >>}
> >>  }
> > 
> > This breaks the currently correct output.
> 
> Hm, you are right. Thanks!
> I guess this patch just needs some redoing.
> 
> Greg, if you can skip this patch but still apply the rest of the series, that 
> would be great.
> I just tested that the whole thing builds and runs fine with this patch 
> omitted.

Ok, now skipped, thanks.

greg k-h

Re: [PATCH 43/45] staging/lustre/libcfs: Replace use of printk with pr_

[Greg Kroah-Hartman]

On Tue, Feb 16, 2016 at 11:12:14AM -0500, Oleg Drokin wrote:
> 
> On Feb 16, 2016, at 12:55 AM, Joe Perches wrote:
> 
> > On Tue, 2016-02-16 at 00:47 -0500, gr...@linuxhacker.ru wrote:
> >> From: Oleg Drokin 
> >> 
> >> This pacifies checkpatch amongst other things, also is shorter to write
> >> and avoiding calls to printk_ratelimit() is also good.
> > []
> >> diff --git a/drivers/staging/lustre/lustre/libcfs/linux/linux-tracefile.c 
> >> b/drivers/staging/lustre/lustre/libcfs/linux/linux-tracefile.c
> > []
> >> @@ -244,11 +244,11 @@ void cfs_print_to_console(struct ptldebug_header 
> >> *hdr, int mask,
> >>}
> >>  
> >>if ((mask & D_CONSOLE) != 0) {
> >> -  printk("%s%s: %.*s", ptype, prefix, len, buf);
> >> +  pr_err("%s%s: %.*s", ptype, prefix, len, buf);
> >>} else {
> >> -  printk("%s%s: %d:%d:(%s:%d:%s()) %.*s", ptype, prefix,
> >> - hdr->ph_pid, hdr->ph_extern_pid, file, hdr->ph_line_num,
> >> - fn, len, buf);
> >> +  pr_warn("%s%s: %d:%d:(%s:%d:%s()) %.*s", ptype, prefix,
> >> +  hdr->ph_pid, hdr->ph_extern_pid, file, hdr->ph_line_num,
> >> +  fn, len, buf);
> >>}
> >>  }
> > 
> > This breaks the currently correct output.
> 
> Hm, you are right. Thanks!
> I guess this patch just needs some redoing.
> 
> Greg, if you can skip this patch but still apply the rest of the series, that 
> would be great.
> I just tested that the whole thing builds and runs fine with this patch 
> omitted.

Ok, now skipped, thanks.

greg k-h

at76c50x-usb: usb_put_dev() if at76_load_internal_fw() succeed

[Alexey Khoroshilov]

I do not see any reason to call usb_put_dev() if at76_load_internal_fw() 
succeed.
But it is here from the very beginning. Any suggestions?

--
Thank you,
Alexey

at76c50x-usb: usb_put_dev() if at76_load_internal_fw() succeed

[Alexey Khoroshilov]

I do not see any reason to call usb_put_dev() if at76_load_internal_fw() 
succeed.
But it is here from the very beginning. Any suggestions?

--
Thank you,
Alexey

[PATCH] at76c50x-usb: avoid double usb_put_dev() after downloading internal firmware in at76_probe()

[Alexey Khoroshilov]

There is no need in usb_put_dev() if at76_load_internal_fw() succeed.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
---
 drivers/net/wireless/atmel/at76c50x-usb.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/wireless/atmel/at76c50x-usb.c 
b/drivers/net/wireless/atmel/at76c50x-usb.c
index dab25136214a..1efb1d66e0b7 100644
--- a/drivers/net/wireless/atmel/at76c50x-usb.c
+++ b/drivers/net/wireless/atmel/at76c50x-usb.c
@@ -2481,9 +2481,7 @@ static int at76_probe(struct usb_interface *interface,
dev_err(>dev,
"error %d downloading internal firmware\n",
ret);
-   goto exit;
}
-   usb_put_dev(udev);
goto exit;
}
 
-- 
1.9.1

[PATCH] at76c50x-usb: avoid double usb_put_dev() after downloading internal firmware in at76_probe()

[Alexey Khoroshilov]

There is no need in usb_put_dev() if at76_load_internal_fw() succeed.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
---
 drivers/net/wireless/atmel/at76c50x-usb.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/net/wireless/atmel/at76c50x-usb.c 
b/drivers/net/wireless/atmel/at76c50x-usb.c
index dab25136214a..1efb1d66e0b7 100644
--- a/drivers/net/wireless/atmel/at76c50x-usb.c
+++ b/drivers/net/wireless/atmel/at76c50x-usb.c
@@ -2481,9 +2481,7 @@ static int at76_probe(struct usb_interface *interface,
dev_err(>dev,
"error %d downloading internal firmware\n",
ret);
-   goto exit;
}
-   usb_put_dev(udev);
goto exit;
}
 
-- 
1.9.1

Re: [PATCH 1/4] ASoC: wm9713: add binding for WM9713 codec

[Robert Jarzmik]

Mark Brown  writes:

> On Sat, Feb 20, 2016 at 09:32:58PM +0100, Robert Jarzmik wrote:
>> Mark Brown  writes:
>> > On Sat, Feb 20, 2016 at 07:22:04PM +0100, Robert Jarzmik wrote:
>> I will. By now I fail to see how this will help in the wm9713 probing and
>> detection ...
>
> It will eumerate the AC'97 bus by itself and does not need the CODEC to
> be described.
I think I still don't get it.

So let's rephrase it another way : how will the function wm9713_probe() be
called, ie. what is the possible function backtrace leading to that call ?

>> Until I make the try, here is what I have as a device-tree extract in [1],
>> which is my candidate for sound/soc/pxa/zylonite.c replacement.. If we
>> conclude that wm9713 shouldn't be in device-tree, then I'm curious how the
>> DAI bindings (simple-audio-card,dai-link*) should be handled.
>
> They should be created as a function of enumerating the CODEC.  If you
> use the genric AC'97 stuff it doesn't use ASoC at all and this happens
> as a side effect.
I don't get that either. For me sound/soc/pci/ac97/ac97_codec.c is PCI specific,
not generic, so what is "generic AC'97 stuff" ? I will never be able to use it
as on my platforms CONFIG_PCI=n.

Do you have a devicetree example somewhere, with (ac97 host, audio codec) pair I
can have a look at to understand ?

Cheers.

-- 
Robert

Re: [PATCH 1/4] ASoC: wm9713: add binding for WM9713 codec

[Robert Jarzmik]

Mark Brown  writes:

> On Sat, Feb 20, 2016 at 09:32:58PM +0100, Robert Jarzmik wrote:
>> Mark Brown  writes:
>> > On Sat, Feb 20, 2016 at 07:22:04PM +0100, Robert Jarzmik wrote:
>> I will. By now I fail to see how this will help in the wm9713 probing and
>> detection ...
>
> It will eumerate the AC'97 bus by itself and does not need the CODEC to
> be described.
I think I still don't get it.

So let's rephrase it another way : how will the function wm9713_probe() be
called, ie. what is the possible function backtrace leading to that call ?

>> Until I make the try, here is what I have as a device-tree extract in [1],
>> which is my candidate for sound/soc/pxa/zylonite.c replacement.. If we
>> conclude that wm9713 shouldn't be in device-tree, then I'm curious how the
>> DAI bindings (simple-audio-card,dai-link*) should be handled.
>
> They should be created as a function of enumerating the CODEC.  If you
> use the genric AC'97 stuff it doesn't use ASoC at all and this happens
> as a side effect.
I don't get that either. For me sound/soc/pci/ac97/ac97_codec.c is PCI specific,
not generic, so what is "generic AC'97 stuff" ? I will never be able to use it
as on my platforms CONFIG_PCI=n.

Do you have a devicetree example somewhere, with (ac97 host, audio codec) pair I
can have a look at to understand ?

Cheers.

-- 
Robert

Re: [PATCH] kernel/resource.c: fix muxed resource handling in __request_region()

[Jesse Barnes]

On February 20, 2016 9:12:01 AM Linus Torvalds 
 wrote:



On Fri, Feb 19, 2016 at 3:25 PM, Jesse Barnes  wrote:

+Linus (the de-facto resource guy).

On 02/19/2016 01:10 PM, Vincent Pelletier wrote:

Tested-by: Vincent Pelletier 


Hmm.

So I'm not entirely happy with the patch, because I think the problem
with using a possibly free'd parent resource at restart still exists.

As far as I can tell, if we hit the IORESOURCE_MUXED case *after* we
have successfully delved into a resource that wasn't busy, we will
have updated "parent" in a previous iteration of the loop, and we'll
not use the original parent when we then re-start after the sleep. So
quite frankly, I suspect any user of MUXED memory regions is still
fundamentally buggy, and IORESOURCE_MUXED has always been a hacky and
broken thing.

That said, I ended up applying the patch anyway, even if I despise it.
For all I know, muxed users never end up having those non-busy
sub-resources in practice, and maybe there is some serialization at
the top level for the drivers that use it. So if testing has shown
that it helps some actual case, I'll believe the testing. But the code
still looks rather debatable, and the whole IORESOURCE_MUXED approach
looks broken.

Jesse, that came in through you and the drm tree, I think. Alan is
marked as author, and there are other people who actually use and can
test the code. Can you guys think about the code a bit more.

I'm wondering if the *real* fix ends up being to reset the 'parent'
pointer to the original top-level parent after the sleep?

To recap: the patch is in my tree, but I'm not all that happy about it.


Thanks, yeah i think testing wins in this case.  I'll revisit the muxed 
stuff; I do

remember being dubious at the time, but iirc Alan needed it for something,
and others had been pushing for these sorts of usages for awhile even though
we have some good alternatives in the form of bus and platform drivers that
can manage the appropriate serialization and keep things from stomping
on one another.

(And sorry if this message comes across in some bullshit format, I'm trying
out a new ChromeOS based mail client for fun here.)

Thanks,
Jesse

Re: [PATCH] kernel/resource.c: fix muxed resource handling in __request_region()

[Jesse Barnes]

On February 20, 2016 9:12:01 AM Linus Torvalds 
 wrote:



On Fri, Feb 19, 2016 at 3:25 PM, Jesse Barnes  wrote:

+Linus (the de-facto resource guy).

On 02/19/2016 01:10 PM, Vincent Pelletier wrote:

Tested-by: Vincent Pelletier 


Hmm.

So I'm not entirely happy with the patch, because I think the problem
with using a possibly free'd parent resource at restart still exists.

As far as I can tell, if we hit the IORESOURCE_MUXED case *after* we
have successfully delved into a resource that wasn't busy, we will
have updated "parent" in a previous iteration of the loop, and we'll
not use the original parent when we then re-start after the sleep. So
quite frankly, I suspect any user of MUXED memory regions is still
fundamentally buggy, and IORESOURCE_MUXED has always been a hacky and
broken thing.

That said, I ended up applying the patch anyway, even if I despise it.
For all I know, muxed users never end up having those non-busy
sub-resources in practice, and maybe there is some serialization at
the top level for the drivers that use it. So if testing has shown
that it helps some actual case, I'll believe the testing. But the code
still looks rather debatable, and the whole IORESOURCE_MUXED approach
looks broken.

Jesse, that came in through you and the drm tree, I think. Alan is
marked as author, and there are other people who actually use and can
test the code. Can you guys think about the code a bit more.

I'm wondering if the *real* fix ends up being to reset the 'parent'
pointer to the original top-level parent after the sleep?

To recap: the patch is in my tree, but I'm not all that happy about it.


Thanks, yeah i think testing wins in this case.  I'll revisit the muxed 
stuff; I do

remember being dubious at the time, but iirc Alan needed it for something,
and others had been pushing for these sorts of usages for awhile even though
we have some good alternatives in the form of bus and platform drivers that
can manage the appropriate serialization and keep things from stomping
on one another.

(And sorry if this message comes across in some bullshit format, I'm trying
out a new ChromeOS based mail client for fun here.)

Thanks,
Jesse

[PATCH] thermal: rcar: check for NULL return of of_match_device

[Colin King]

From: Colin Ian King 

of_match_device can potentially return NULL, so we need to check for
this case to avoid a null pointer dereference on of_id

Signed-off-by: Colin Ian King 
---
 drivers/thermal/rcar_thermal.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index 0e735ac..5943881 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -431,13 +431,17 @@ static int rcar_thermal_probe(struct platform_device 
*pdev)
struct device *dev = >dev;
struct resource *res, *irq;
const struct of_device_id *of_id = of_match_device(rcar_thermal_dt_ids, 
dev);
-   unsigned long of_data = (unsigned long)of_id->data;
+   unsigned long of_data;
int mres = 0;
int i;
int ret = -ENODEV;
int idle = IDLE_INTERVAL;
u32 enr_bits = 0;
 
+   if (!of_id)
+   return ret;
+   of_data = (unsigned long)of_id->data;
+
common = devm_kzalloc(dev, sizeof(*common), GFP_KERNEL);
if (!common)
return -ENOMEM;
-- 
2.7.0

[PATCH] thermal: rcar: check for NULL return of of_match_device

[Colin King]

From: Colin Ian King 

of_match_device can potentially return NULL, so we need to check for
this case to avoid a null pointer dereference on of_id

Signed-off-by: Colin Ian King 
---
 drivers/thermal/rcar_thermal.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/thermal/rcar_thermal.c b/drivers/thermal/rcar_thermal.c
index 0e735ac..5943881 100644
--- a/drivers/thermal/rcar_thermal.c
+++ b/drivers/thermal/rcar_thermal.c
@@ -431,13 +431,17 @@ static int rcar_thermal_probe(struct platform_device 
*pdev)
struct device *dev = >dev;
struct resource *res, *irq;
const struct of_device_id *of_id = of_match_device(rcar_thermal_dt_ids, 
dev);
-   unsigned long of_data = (unsigned long)of_id->data;
+   unsigned long of_data;
int mres = 0;
int i;
int ret = -ENODEV;
int idle = IDLE_INTERVAL;
u32 enr_bits = 0;
 
+   if (!of_id)
+   return ret;
+   of_data = (unsigned long)of_id->data;
+
common = devm_kzalloc(dev, sizeof(*common), GFP_KERNEL);
if (!common)
return -ENOMEM;
-- 
2.7.0

Re: [PATCH] rtc: Add an option to invalidate dates in 2038

[Arnd Bergmann]

On Saturday 20 February 2016 21:47:15 Alexandre Belloni wrote:
> 
> Actually, I'm not trying to solve the 2038 issue.
> 
> But in the current state on 32 bit platforms, while the kernel is able
> to handle a 64bit date, userspace is not. The main issue is that
> distributions use HCTOSYS so if the RTC is set to a date after 2038
> (which we know is currently bogus), the kernel will set a system time to
> that date.
> 
> This result in a system that fails when using timerfd, The timerfd will
> always fire immediately (until, as some people pointed out, we have
> relative timers).
> 
> This is know to break systemd [1] but I have had reports for other
> failing applications.
> 
> I understand this is a workaround and I plan to switch the default to n
> once libc and critical userspace is able to handle 64 bit time.
> 
> The other way of solving that is to get back to a 32 bit time_t
> internally until we switch the whole userspace to a 64 bit time_t but I
> don't think this is practical.
> 
> [1] https://github.com/systemd/systemd/issues/1143
> 

I think in both cases you introduce a new 2038 problem though:
as long as you have a kernel that tries to support an old
32-bit systemd build, the kernel becomes incompatible with RTC
times beyond 2038, even on 64-bit systems and 32-bit systems
that have fixed system call table and fixed user space.

This is bad because it means we still have to break systemd
eventually in order to fix the 2038 overflow.

The plan to revert this after glibc has been converted is
problematic because a lot of 32-bit distros will likely never
recompile with 64-bit time_t in order to avoid breaking
backwards compatibility. While we could require that user
space and kernel must match here (either support 64-bit time_t
everywhere or nowhere), that makes it much harder to deal
with the migration, and it has always been a strict requirement
that none of the changes for y2038 compatibility break existing
user space (which of course is what happened for RTC and what
we need to fix here).

Has the problem of random RTC times been observed on more than
one RTC driver yet? Maybe we can just apply your workaround
to that one driver that saw it instead.

Have you figured out whether there is a pattern in the reported
times? Is it just completely random or could we perhaps
detect an RTC that reports an invalid time other than by 
looking at the year?

Arnd

Re: [PATCH] rtc: Add an option to invalidate dates in 2038

[Arnd Bergmann]

On Saturday 20 February 2016 21:47:15 Alexandre Belloni wrote:
> 
> Actually, I'm not trying to solve the 2038 issue.
> 
> But in the current state on 32 bit platforms, while the kernel is able
> to handle a 64bit date, userspace is not. The main issue is that
> distributions use HCTOSYS so if the RTC is set to a date after 2038
> (which we know is currently bogus), the kernel will set a system time to
> that date.
> 
> This result in a system that fails when using timerfd, The timerfd will
> always fire immediately (until, as some people pointed out, we have
> relative timers).
> 
> This is know to break systemd [1] but I have had reports for other
> failing applications.
> 
> I understand this is a workaround and I plan to switch the default to n
> once libc and critical userspace is able to handle 64 bit time.
> 
> The other way of solving that is to get back to a 32 bit time_t
> internally until we switch the whole userspace to a 64 bit time_t but I
> don't think this is practical.
> 
> [1] https://github.com/systemd/systemd/issues/1143
> 

I think in both cases you introduce a new 2038 problem though:
as long as you have a kernel that tries to support an old
32-bit systemd build, the kernel becomes incompatible with RTC
times beyond 2038, even on 64-bit systems and 32-bit systems
that have fixed system call table and fixed user space.

This is bad because it means we still have to break systemd
eventually in order to fix the 2038 overflow.

The plan to revert this after glibc has been converted is
problematic because a lot of 32-bit distros will likely never
recompile with 64-bit time_t in order to avoid breaking
backwards compatibility. While we could require that user
space and kernel must match here (either support 64-bit time_t
everywhere or nowhere), that makes it much harder to deal
with the migration, and it has always been a strict requirement
that none of the changes for y2038 compatibility break existing
user space (which of course is what happened for RTC and what
we need to fix here).

Has the problem of random RTC times been observed on more than
one RTC driver yet? Maybe we can just apply your workaround
to that one driver that saw it instead.

Have you figured out whether there is a pattern in the reported
times? Is it just completely random or could we perhaps
detect an RTC that reports an invalid time other than by 
looking at the year?

Arnd

[PULL REQUEST] i2c for 4.5

[Wolfram Sang]

Linus,

some bugfixes from I2C for you:

A fix for a RuntimePM regression with OMAP, a fix to enable TCO for
Lewisburg platforms, and a typo fix while we are here.

Please pull. Thanks,

   Wolfram


The following changes since commit 388f7b1d6e8ca06762e2454d28d6c3c55ad0fe95:

  Linux 4.5-rc3 (2016-02-07 15:38:30 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current

for you to fetch changes up to 1a1503c5396eb7f2edf4b8ef6067853014478c0c:

  i2c: i801: Adding Intel Lewisburg support for iTCO (2016-02-18 13:18:48 +0100)


Alexandra Yates (1):
  i2c: i801: Adding Intel Lewisburg support for iTCO

Masahiro Yamada (1):
  i2c: uniphier: fix typos in error messages

Tony Lindgren (1):
  i2c: omap: Fix PM regression with deferred probe for pm_runtime_reinit

 drivers/i2c/busses/i2c-i801.c   | 2 ++
 drivers/i2c/busses/i2c-omap.c   | 4 +++-
 drivers/i2c/busses/i2c-uniphier-f.c | 2 +-
 drivers/i2c/busses/i2c-uniphier.c   | 2 +-
 4 files changed, 7 insertions(+), 3 deletions(-)


signature.asc
Description: PGP signature

[PULL REQUEST] i2c for 4.5

[Wolfram Sang]

Linus,

some bugfixes from I2C for you:

A fix for a RuntimePM regression with OMAP, a fix to enable TCO for
Lewisburg platforms, and a typo fix while we are here.

Please pull. Thanks,

   Wolfram


The following changes since commit 388f7b1d6e8ca06762e2454d28d6c3c55ad0fe95:

  Linux 4.5-rc3 (2016-02-07 15:38:30 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux.git i2c/for-current

for you to fetch changes up to 1a1503c5396eb7f2edf4b8ef6067853014478c0c:

  i2c: i801: Adding Intel Lewisburg support for iTCO (2016-02-18 13:18:48 +0100)


Alexandra Yates (1):
  i2c: i801: Adding Intel Lewisburg support for iTCO

Masahiro Yamada (1):
  i2c: uniphier: fix typos in error messages

Tony Lindgren (1):
  i2c: omap: Fix PM regression with deferred probe for pm_runtime_reinit

 drivers/i2c/busses/i2c-i801.c   | 2 ++
 drivers/i2c/busses/i2c-omap.c   | 4 +++-
 drivers/i2c/busses/i2c-uniphier-f.c | 2 +-
 drivers/i2c/busses/i2c-uniphier.c   | 2 +-
 4 files changed, 7 insertions(+), 3 deletions(-)


signature.asc
Description: PGP signature

[PATCH] rtlwifi: pass struct rtl_stats by reference as it is more efficient

[Colin King]

From: Colin Ian King 

passing rtl_stats by value is inefficient; the structure is over 300
bytes in size and generally just one field (packet_report_type)
is being accessed, so the pass by value is a relatively large overhead.
This change just affects just the rx_command_packet calls.

Signed-off-by: Colin Ian King 
---
 drivers/net/wireless/realtek/rtlwifi/pci.c   | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.h | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c | 6 +++---
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.h | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.c | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.h | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/trx.c | 4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/trx.h | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/trx.c | 4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/trx.h | 2 +-
 drivers/net/wireless/realtek/rtlwifi/wifi.h  | 2 +-
 12 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c 
b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 7f471bf..4153e7f 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -855,7 +855,7 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
}
/* handle command packet here */
if (rtlpriv->cfg->ops->rx_command_packet &&
-   rtlpriv->cfg->ops->rx_command_packet(hw, stats, skb)) {
+   rtlpriv->cfg->ops->rx_command_packet(hw, , skb)) {
dev_kfree_skb_any(skb);
goto new_trx_end;
}
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
index 791efbe..b4d57da 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
@@ -851,7 +851,7 @@ void rtl88ee_tx_polling(struct ieee80211_hw *hw, u8 
hw_queue)
 }
 
 u32 rtl88ee_rx_command_packet(struct ieee80211_hw *hw,
- struct rtl_stats status,
+ struct rtl_stats *status,
  struct sk_buff *skb)
 {
return 0;
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.h 
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.h
index eab5ae0..26fc12b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.h
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.h
@@ -790,7 +790,7 @@ void rtl88ee_tx_fill_cmddesc(struct ieee80211_hw *hw, u8 
*pdesc,
 bool firstseg, bool lastseg,
 struct sk_buff *skb);
 u32 rtl88ee_rx_command_packet(struct ieee80211_hw *hw,
- struct rtl_stats status,
+ struct rtl_stats *status,
  struct sk_buff *skb);
 
 #endif
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c
index d39ee67..32cb096 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c
@@ -1105,13 +1105,13 @@ void rtl92ee_tx_polling(struct ieee80211_hw *hw, u8 
hw_queue)
 }
 
 u32 rtl92ee_rx_command_packet(struct ieee80211_hw *hw,
- struct rtl_stats status,
+ struct rtl_stats *status,
  struct sk_buff *skb)
 {
u32 result = 0;
struct rtl_priv *rtlpriv = rtl_priv(hw);
 
-   switch (status.packet_report_type) {
+   switch (status->packet_report_type) {
case NORMAL_RX:
result = 0;
break;
@@ -1121,7 +1121,7 @@ u32 rtl92ee_rx_command_packet(struct ieee80211_hw *hw,
break;
default:
RT_TRACE(rtlpriv, COMP_RECV, DBG_TRACE,
-"Unknown packet type %d\n", status.packet_report_type);
+"Unknown packet type %d\n", 
status->packet_report_type);
break;
}
 
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.h 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.h
index 8f78ac9..b12fc03 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.h
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.h
@@ -857,6 +857,6 @@ void rtl92ee_tx_fill_cmddesc(struct ieee80211_hw *hw, u8 
*pdesc,
 bool firstseg, bool lastseg,
 struct sk_buff *skb);
 u32 rtl92ee_rx_command_packet(struct ieee80211_hw *hw,
- struct rtl_stats status,
+ struct rtl_stats *status,

[PATCH] rtlwifi: pass struct rtl_stats by reference as it is more efficient

[Colin King]

From: Colin Ian King 

passing rtl_stats by value is inefficient; the structure is over 300
bytes in size and generally just one field (packet_report_type)
is being accessed, so the pass by value is a relatively large overhead.
This change just affects just the rx_command_packet calls.

Signed-off-by: Colin Ian King 
---
 drivers/net/wireless/realtek/rtlwifi/pci.c   | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.h | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c | 6 +++---
 drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.h | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.c | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8723ae/trx.h | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/trx.c | 4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8723be/trx.h | 2 +-
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/trx.c | 4 ++--
 drivers/net/wireless/realtek/rtlwifi/rtl8821ae/trx.h | 2 +-
 drivers/net/wireless/realtek/rtlwifi/wifi.h  | 2 +-
 12 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/drivers/net/wireless/realtek/rtlwifi/pci.c 
b/drivers/net/wireless/realtek/rtlwifi/pci.c
index 7f471bf..4153e7f 100644
--- a/drivers/net/wireless/realtek/rtlwifi/pci.c
+++ b/drivers/net/wireless/realtek/rtlwifi/pci.c
@@ -855,7 +855,7 @@ static void _rtl_pci_rx_interrupt(struct ieee80211_hw *hw)
}
/* handle command packet here */
if (rtlpriv->cfg->ops->rx_command_packet &&
-   rtlpriv->cfg->ops->rx_command_packet(hw, stats, skb)) {
+   rtlpriv->cfg->ops->rx_command_packet(hw, , skb)) {
dev_kfree_skb_any(skb);
goto new_trx_end;
}
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
index 791efbe..b4d57da 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.c
@@ -851,7 +851,7 @@ void rtl88ee_tx_polling(struct ieee80211_hw *hw, u8 
hw_queue)
 }
 
 u32 rtl88ee_rx_command_packet(struct ieee80211_hw *hw,
- struct rtl_stats status,
+ struct rtl_stats *status,
  struct sk_buff *skb)
 {
return 0;
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.h 
b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.h
index eab5ae0..26fc12b 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.h
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8188ee/trx.h
@@ -790,7 +790,7 @@ void rtl88ee_tx_fill_cmddesc(struct ieee80211_hw *hw, u8 
*pdesc,
 bool firstseg, bool lastseg,
 struct sk_buff *skb);
 u32 rtl88ee_rx_command_packet(struct ieee80211_hw *hw,
- struct rtl_stats status,
+ struct rtl_stats *status,
  struct sk_buff *skb);
 
 #endif
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c
index d39ee67..32cb096 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.c
@@ -1105,13 +1105,13 @@ void rtl92ee_tx_polling(struct ieee80211_hw *hw, u8 
hw_queue)
 }
 
 u32 rtl92ee_rx_command_packet(struct ieee80211_hw *hw,
- struct rtl_stats status,
+ struct rtl_stats *status,
  struct sk_buff *skb)
 {
u32 result = 0;
struct rtl_priv *rtlpriv = rtl_priv(hw);
 
-   switch (status.packet_report_type) {
+   switch (status->packet_report_type) {
case NORMAL_RX:
result = 0;
break;
@@ -1121,7 +1121,7 @@ u32 rtl92ee_rx_command_packet(struct ieee80211_hw *hw,
break;
default:
RT_TRACE(rtlpriv, COMP_RECV, DBG_TRACE,
-"Unknown packet type %d\n", status.packet_report_type);
+"Unknown packet type %d\n", 
status->packet_report_type);
break;
}
 
diff --git a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.h 
b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.h
index 8f78ac9..b12fc03 100644
--- a/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.h
+++ b/drivers/net/wireless/realtek/rtlwifi/rtl8192ee/trx.h
@@ -857,6 +857,6 @@ void rtl92ee_tx_fill_cmddesc(struct ieee80211_hw *hw, u8 
*pdesc,
 bool firstseg, bool lastseg,
 struct sk_buff *skb);
 u32 rtl92ee_rx_command_packet(struct ieee80211_hw *hw,
- struct rtl_stats status,
+ struct rtl_stats *status,
  struct sk_buff *skb);
 

Re: Requesting Thunderbolt 3 support

[Greg KH]

On Sat, Feb 20, 2016 at 02:32:55PM -0500, Jeremy Carter wrote:
> Hi,
> 
> Please CC replies to me since I'm not subscribed to the list.
> 
> I'm wondering if anyone is working on thunderbolt 3 support, and if
> not I would like to request thunderbolt 3 support in the kernel.
> 
> Thunderbolt 3 looks great, since it is really fast and uses USB
> cables. Is anyone else interested in TB3?

Do you have any hardware that supports this that isn't working with the
current Thunderbolt drivers?

thanks,

greg k-h

Re: Requesting Thunderbolt 3 support

[Greg KH]

On Sat, Feb 20, 2016 at 02:32:55PM -0500, Jeremy Carter wrote:
> Hi,
> 
> Please CC replies to me since I'm not subscribed to the list.
> 
> I'm wondering if anyone is working on thunderbolt 3 support, and if
> not I would like to request thunderbolt 3 support in the kernel.
> 
> Thunderbolt 3 looks great, since it is really fast and uses USB
> cables. Is anyone else interested in TB3?

Do you have any hardware that supports this that isn't working with the
current Thunderbolt drivers?

thanks,

greg k-h

Linux 4.5-rc5

[Linus Torvalds]

Things continue to look normal, and things hav ebeen fairly calm. Yes,
the VM THP cleanup seems to still be problematic on s390, but other
than that I don't see anything particularly worrisome.

So another week, another rc. The patch looks pretty normal, with about
55% drivers (drm and clk drivers stand out, but aren't alone) and
almost 20% arch updates (arm, m68k, powerpc, s390, x86). The rest is
spread out - filesystems (ext4, efi, cifs), some core kernel and
header files. And a few documentation updates. Everything fairly
small.

The shortlog is appended.

---

Alan Cox (1):
  blk: fix overflow in queue_discard_max_hw_show

Alexey Kardashevskiy (1):
  powerpc/ioda: Set "read" permission when "write" is set

Amitoj Kaur Chawla (1):
  clk: tegra: Add missing of_node_put()

Andre Przywara (1):
  KVM: arm/arm64: Fix reference to uninitialised VGIC

Andreas Schwab (1):
  powerpc: Fix dedotify for binutils >= 2.26

Andrew Bresticker (1):
  clk: tegra: pll: Fix potential sleeping-while-atomic

Andrzej Hajda (1):
  drm/exynos/decon: fix disable clocks order

Andy Shevchenko (2):
  dmaengine: dw: pci: add ID for WildcatPoint PCH
  dmaengine: dw: disable BLOCK IRQs for non-cyclic xfer

Aneesh Kumar K.V (2):
  powerpc/book3s_32: Fix build error with checkpoint restart
  powerpc/mm: Fix Multi hit ERAT cause by recent THP update

Anton Protopopov (3):
  cifs: fix erroneous return value
  ext4: ioctl: fix erroneous return value
  drm/qxl: fix erroneous return value

Arnd Bergmann (3):
  spi: fix counting in spi-loopback-test code
  pinctrl: nomadik: hide unused functions
  tracing: Fix freak link error caused by branch tracer

Axel Lin (1):
  clk: scpi: Fix checking return value of platform_device_register_simple()

Biao Huang (1):
  pinctrl: mediatek: fix direction control issue

Bob Liu (1):
  xen/blkfront: realloc ring info in blkif_resume

CQ Tang (1):
  iommu/vt-d: Fix 64-bit accesses to 32-bit DMAR_GSTS_REG

Chris Wilson (1):
  drm/i915: Allow i915_gem_object_get_page() on userptr as well

Christian Borntraeger (1):
  s390: fix DAT off memory access, e.g. on kdump

Christoph Hellwig (1):
  nvme: fix Kconfig description for BLK_DEV_NVME_SCSI

Colin Ian King (1):
  cifs: remove redundant check for null string pointer

Cyrille Pitchen (1):
  spi: atmel: fix gpio chip-select in case of non-DT platform

Dave Airlie (1):
  Revert "drm/dp/mst: change MST detection scheme"

Dave Jiang (1):
  dmaengine: IOATDMA: fix timer code that continues to restart
channels during idle

David Woodhouse (2):
  iommu/vt-d: Fix mm refcounting to hold mm_count not mm_users
  iommu/vt-d: Clear PPR bit to ensure we get more page request interrupts

Denis Kirjanov (1):
  powerpc/pseries: Don't trace hcalls on offline CPUs

Dmitry Safonov (1):
  mm: slab: free kmem_cache_node after destroy sysfs file

Eric Anholt (8):
  drm/vc4: Validate that WAIT_BO padding is cleared.
  drm/vc4: Fix the clear color for the first tile rendered.
  drm/vc4: Return an ERR_PTR from BO creation instead of NULL.
  drm/vc4: Fix -ERESTARTSYS error return from BO waits.
  drm/vc4: Drop error message on seqno wait timeouts.
  drm/vc4: Fix spurious GPU resets due to BO reuse.
  drm/vc4: Enable runtime PM.
  drm/vc4: Use runtime PM to power cycle the device when the GPU hangs.

Eryu Guan (2):
  ext4: don't read blocks from disk after extents being swapped
  ext4: remove unused parameter "newblock" in convert_initialized_extent()

EunTaik Lee (1):
  arm64: mm: allow the kernel to handle alignment faults on user accesses

Fabio Estevam (1):
  serial: fsl-imx-uart: Fix typo in fsl,dte-mode description

Filipe Manana (1):
  Btrfs: fix direct IO requests not reporting IO error to user space

Gao Pan (1):
  spi: imx: fix spi resource leak with dma transfer

Gavin Shan (2):
  powerpc/eeh: Fix stale cached primary bus
  powerpc/powernv: Fix stale PE primary bus

Geert Uytterhoeven (2):
  m68k: Wire up copy_file_range
  m68k/defconfig: Update defconfigs for v4.5-rc1

Gerd Hoffmann (1):
  drm/qxl: use kmalloc_array to alloc reloc_info in
qxl_process_single_command

Hannes Reinecke (1):
  bio: return EINTR if copying to user space got interrupted

Heiko Carstens (8):
  s390/stacktrace: fix save_stack_trace_tsk() for current task
  s390/stacktrace: fix address ranges for asynchronous and panic stack
  s390/stacktrace: add missing end marker
  s390/stacktrace: save full stack traces
  s390/perf_event: fix address range for asynchronous stack
  s390/oprofile: fix address range for asynchronous stack
  s390/diag: avoid lockdep recursion
  s390/maccess: reduce stnsm instructions

Hou Zhiqiang (1):
  spi/fsl-espi: Correct the maximum transaction length

Huaitong Han (1):
  ext4: add a line break for proc mb_groups display

Hugh Dickins (1):

Linux 4.5-rc5

[Linus Torvalds]

Things continue to look normal, and things hav ebeen fairly calm. Yes,
the VM THP cleanup seems to still be problematic on s390, but other
than that I don't see anything particularly worrisome.

So another week, another rc. The patch looks pretty normal, with about
55% drivers (drm and clk drivers stand out, but aren't alone) and
almost 20% arch updates (arm, m68k, powerpc, s390, x86). The rest is
spread out - filesystems (ext4, efi, cifs), some core kernel and
header files. And a few documentation updates. Everything fairly
small.

The shortlog is appended.

---

Alan Cox (1):
  blk: fix overflow in queue_discard_max_hw_show

Alexey Kardashevskiy (1):
  powerpc/ioda: Set "read" permission when "write" is set

Amitoj Kaur Chawla (1):
  clk: tegra: Add missing of_node_put()

Andre Przywara (1):
  KVM: arm/arm64: Fix reference to uninitialised VGIC

Andreas Schwab (1):
  powerpc: Fix dedotify for binutils >= 2.26

Andrew Bresticker (1):
  clk: tegra: pll: Fix potential sleeping-while-atomic

Andrzej Hajda (1):
  drm/exynos/decon: fix disable clocks order

Andy Shevchenko (2):
  dmaengine: dw: pci: add ID for WildcatPoint PCH
  dmaengine: dw: disable BLOCK IRQs for non-cyclic xfer

Aneesh Kumar K.V (2):
  powerpc/book3s_32: Fix build error with checkpoint restart
  powerpc/mm: Fix Multi hit ERAT cause by recent THP update

Anton Protopopov (3):
  cifs: fix erroneous return value
  ext4: ioctl: fix erroneous return value
  drm/qxl: fix erroneous return value

Arnd Bergmann (3):
  spi: fix counting in spi-loopback-test code
  pinctrl: nomadik: hide unused functions
  tracing: Fix freak link error caused by branch tracer

Axel Lin (1):
  clk: scpi: Fix checking return value of platform_device_register_simple()

Biao Huang (1):
  pinctrl: mediatek: fix direction control issue

Bob Liu (1):
  xen/blkfront: realloc ring info in blkif_resume

CQ Tang (1):
  iommu/vt-d: Fix 64-bit accesses to 32-bit DMAR_GSTS_REG

Chris Wilson (1):
  drm/i915: Allow i915_gem_object_get_page() on userptr as well

Christian Borntraeger (1):
  s390: fix DAT off memory access, e.g. on kdump

Christoph Hellwig (1):
  nvme: fix Kconfig description for BLK_DEV_NVME_SCSI

Colin Ian King (1):
  cifs: remove redundant check for null string pointer

Cyrille Pitchen (1):
  spi: atmel: fix gpio chip-select in case of non-DT platform

Dave Airlie (1):
  Revert "drm/dp/mst: change MST detection scheme"

Dave Jiang (1):
  dmaengine: IOATDMA: fix timer code that continues to restart
channels during idle

David Woodhouse (2):
  iommu/vt-d: Fix mm refcounting to hold mm_count not mm_users
  iommu/vt-d: Clear PPR bit to ensure we get more page request interrupts

Denis Kirjanov (1):
  powerpc/pseries: Don't trace hcalls on offline CPUs

Dmitry Safonov (1):
  mm: slab: free kmem_cache_node after destroy sysfs file

Eric Anholt (8):
  drm/vc4: Validate that WAIT_BO padding is cleared.
  drm/vc4: Fix the clear color for the first tile rendered.
  drm/vc4: Return an ERR_PTR from BO creation instead of NULL.
  drm/vc4: Fix -ERESTARTSYS error return from BO waits.
  drm/vc4: Drop error message on seqno wait timeouts.
  drm/vc4: Fix spurious GPU resets due to BO reuse.
  drm/vc4: Enable runtime PM.
  drm/vc4: Use runtime PM to power cycle the device when the GPU hangs.

Eryu Guan (2):
  ext4: don't read blocks from disk after extents being swapped
  ext4: remove unused parameter "newblock" in convert_initialized_extent()

EunTaik Lee (1):
  arm64: mm: allow the kernel to handle alignment faults on user accesses

Fabio Estevam (1):
  serial: fsl-imx-uart: Fix typo in fsl,dte-mode description

Filipe Manana (1):
  Btrfs: fix direct IO requests not reporting IO error to user space

Gao Pan (1):
  spi: imx: fix spi resource leak with dma transfer

Gavin Shan (2):
  powerpc/eeh: Fix stale cached primary bus
  powerpc/powernv: Fix stale PE primary bus

Geert Uytterhoeven (2):
  m68k: Wire up copy_file_range
  m68k/defconfig: Update defconfigs for v4.5-rc1

Gerd Hoffmann (1):
  drm/qxl: use kmalloc_array to alloc reloc_info in
qxl_process_single_command

Hannes Reinecke (1):
  bio: return EINTR if copying to user space got interrupted

Heiko Carstens (8):
  s390/stacktrace: fix save_stack_trace_tsk() for current task
  s390/stacktrace: fix address ranges for asynchronous and panic stack
  s390/stacktrace: add missing end marker
  s390/stacktrace: save full stack traces
  s390/perf_event: fix address range for asynchronous stack
  s390/oprofile: fix address range for asynchronous stack
  s390/diag: avoid lockdep recursion
  s390/maccess: reduce stnsm instructions

Hou Zhiqiang (1):
  spi/fsl-espi: Correct the maximum transaction length

Huaitong Han (1):
  ext4: add a line break for proc mb_groups display

Hugh Dickins (1):

Re: [PATCH 12/15] ACPICA: ACPI 6.1: Add full support for this version of ACPI spec

[Abdulhamid, Harb]

On 2/19/2016 1:17 AM, Lv Zheng wrote:
> From: Bob Moore 
> 
> ACPICA commit 5f21bddaa2cec035ca80608803ce2f0858d4f387
> 
> Small changes:
> 1) A couple new predefined names
> 2) New _HID values
I don't see where you are adding new _HID values in this patch.

> 3) New subtable for HEST
> 
> Link: https://github.com/acpica/acpica/commit/5f21bdda
> Signed-off-by: Bob Moore 
> Signed-off-by: Lv Zheng 
> ---
>  drivers/acpi/acpica/acpredef.h |9 +
>  drivers/acpi/acpica/utdecode.c |   30 +-
>  include/acpi/actbl.h   |2 +-
>  include/acpi/actbl1.h  |   29 ++---
>  include/acpi/actypes.h |3 ++-
>  5 files changed, 55 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/acpi/acpica/acpredef.h b/drivers/acpi/acpica/acpredef.h
> index 5faeab4..4ca426b 100644
> --- a/drivers/acpi/acpica/acpredef.h
> +++ b/drivers/acpi/acpica/acpredef.h
> @@ -523,6 +523,9 @@ const union acpi_predefined_info 
> acpi_gbl_predefined_methods[] = {
> METHOD_RETURNS(ACPI_RTYPE_PACKAGE)}}, /* Fixed-length (4 Int) */
>   PACKAGE_INFO(ACPI_PTYPE1_FIXED, ACPI_RTYPE_INTEGER, 4, 0, 0, 0),
>  
> + {{"_FIT", METHOD_0ARGS,
> +   METHOD_RETURNS(ACPI_RTYPE_BUFFER)}},  /* ACPI 6.0 */
> +
>   {{"_FIX", METHOD_0ARGS,
> METHOD_RETURNS(ACPI_RTYPE_PACKAGE)}}, /* Variable-length (Ints) */
>   PACKAGE_INFO(ACPI_PTYPE1_VAR, ACPI_RTYPE_INTEGER, 0, 0, 0, 0),
> @@ -1053,6 +1056,12 @@ const union acpi_predefined_info 
> acpi_gbl_predefined_methods[] = {
> METHOD_RETURNS(ACPI_RTYPE_INTEGER | ACPI_RTYPE_STRING |
>ACPI_RTYPE_BUFFER)}},
>  
> + {{"_WPC", METHOD_0ARGS,
> +   METHOD_RETURNS(ACPI_RTYPE_INTEGER)}}, /* ACPI 6.1 */
> +
> + {{"_WPP", METHOD_0ARGS,
> +   METHOD_RETURNS(ACPI_RTYPE_INTEGER)}}, /* ACPI 6.1 */
> +
>   PACKAGE_INFO(0, 0, 0, 0, 0, 0)  /* Table terminator */
>  };
>  #else
> diff --git a/drivers/acpi/acpica/utdecode.c b/drivers/acpi/acpica/utdecode.c
> index 6ba65b0..efd7988 100644
> --- a/drivers/acpi/acpica/utdecode.c
> +++ b/drivers/acpi/acpica/utdecode.c
> @@ -446,7 +446,7 @@ const char *acpi_ut_get_mutex_name(u32 mutex_id)
>  
>  /* Names for Notify() values, used for debug output */
>  
> -static const char *acpi_gbl_generic_notify[ACPI_NOTIFY_MAX + 1] = {
> +static const char *acpi_gbl_generic_notify[ACPI_GENERIC_NOTIFY_MAX + 1] = {
>   /* 00 */ "Bus Check",
>   /* 01 */ "Device Check",
>   /* 02 */ "Device Wake",
> @@ -459,49 +459,53 @@ static const char 
> *acpi_gbl_generic_notify[ACPI_NOTIFY_MAX + 1] = {
>   /* 09 */ "Device PLD Check",
>   /* 0A */ "Reserved",
>   /* 0B */ "System Locality Update",
> - /* 0C */ "Shutdown Request",
> + /* 0C */ "Shutdown Request",
> + /* Reserved in ACPI 6.0 */
>   /* 0D */ "System Resource Affinity Update"
>  };
>  
> -static const char *acpi_gbl_device_notify[4] = {
> +static const char *acpi_gbl_device_notify[5] = {
>   /* 80 */ "Status Change",
>   /* 81 */ "Information Change",
>   /* 82 */ "Device-Specific Change",
> - /* 83 */ "Device-Specific Change"
> + /* 83 */ "Device-Specific Change",
> + /* 84 */ "Reserved"
>  };
>  
> -static const char *acpi_gbl_processor_notify[4] = {
> +static const char *acpi_gbl_processor_notify[5] = {
>   /* 80 */ "Performance Capability Change",
>   /* 81 */ "C-State Change",
>   /* 82 */ "Throttling Capability Change",
> - /* 83 */ "Device-Specific Change"
> + /* 83 */ "Guaranteed Change",
> + /* 84 */ "Minimum Excursion"
>  };
>  
> -static const char *acpi_gbl_thermal_notify[4] = {
> +static const char *acpi_gbl_thermal_notify[5] = {
>   /* 80 */ "Thermal Status Change",
>   /* 81 */ "Thermal Trip Point Change",
>   /* 82 */ "Thermal Device List Change",
> - /* 83 */ "Thermal Relationship Change"
> + /* 83 */ "Thermal Relationship Change",
> + /* 84 */ "Reserved"
>  };
>  
>  const char *acpi_ut_get_notify_name(u32 notify_value, acpi_object_type type)
>  {
>  
> - /* 00 - 0D are common to all object types */
> + /* 00 - 0D are "common to all object types" (from ACPI Spec) */
>  
> - if (notify_value <= ACPI_NOTIFY_MAX) {
> + if (notify_value <= ACPI_GENERIC_NOTIFY_MAX) {
>   return (acpi_gbl_generic_notify[notify_value]);
>   }
>  
> - /* 0D - 7F are reserved */
> + /* 0E - 7F are reserved */
>  
>   if (notify_value <= ACPI_MAX_SYS_NOTIFY) {
>   return ("Reserved");
>   }
>  
> - /* 80 - 83 are per-object-type */
> + /* 80 - 84 are per-object-type */
>  
> - if (notify_value <= 0x83) {
> + if (notify_value <= ACPI_SPECIFIC_NOTIFY_MAX) {
>   switch (type) {
>   case ACPI_TYPE_ANY:
>   case ACPI_TYPE_DEVICE:
> diff --git 

Re: [PATCH 12/15] ACPICA: ACPI 6.1: Add full support for this version of ACPI spec

[Abdulhamid, Harb]

On 2/19/2016 1:17 AM, Lv Zheng wrote:
> From: Bob Moore 
> 
> ACPICA commit 5f21bddaa2cec035ca80608803ce2f0858d4f387
> 
> Small changes:
> 1) A couple new predefined names
> 2) New _HID values
I don't see where you are adding new _HID values in this patch.

> 3) New subtable for HEST
> 
> Link: https://github.com/acpica/acpica/commit/5f21bdda
> Signed-off-by: Bob Moore 
> Signed-off-by: Lv Zheng 
> ---
>  drivers/acpi/acpica/acpredef.h |9 +
>  drivers/acpi/acpica/utdecode.c |   30 +-
>  include/acpi/actbl.h   |2 +-
>  include/acpi/actbl1.h  |   29 ++---
>  include/acpi/actypes.h |3 ++-
>  5 files changed, 55 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/acpi/acpica/acpredef.h b/drivers/acpi/acpica/acpredef.h
> index 5faeab4..4ca426b 100644
> --- a/drivers/acpi/acpica/acpredef.h
> +++ b/drivers/acpi/acpica/acpredef.h
> @@ -523,6 +523,9 @@ const union acpi_predefined_info 
> acpi_gbl_predefined_methods[] = {
> METHOD_RETURNS(ACPI_RTYPE_PACKAGE)}}, /* Fixed-length (4 Int) */
>   PACKAGE_INFO(ACPI_PTYPE1_FIXED, ACPI_RTYPE_INTEGER, 4, 0, 0, 0),
>  
> + {{"_FIT", METHOD_0ARGS,
> +   METHOD_RETURNS(ACPI_RTYPE_BUFFER)}},  /* ACPI 6.0 */
> +
>   {{"_FIX", METHOD_0ARGS,
> METHOD_RETURNS(ACPI_RTYPE_PACKAGE)}}, /* Variable-length (Ints) */
>   PACKAGE_INFO(ACPI_PTYPE1_VAR, ACPI_RTYPE_INTEGER, 0, 0, 0, 0),
> @@ -1053,6 +1056,12 @@ const union acpi_predefined_info 
> acpi_gbl_predefined_methods[] = {
> METHOD_RETURNS(ACPI_RTYPE_INTEGER | ACPI_RTYPE_STRING |
>ACPI_RTYPE_BUFFER)}},
>  
> + {{"_WPC", METHOD_0ARGS,
> +   METHOD_RETURNS(ACPI_RTYPE_INTEGER)}}, /* ACPI 6.1 */
> +
> + {{"_WPP", METHOD_0ARGS,
> +   METHOD_RETURNS(ACPI_RTYPE_INTEGER)}}, /* ACPI 6.1 */
> +
>   PACKAGE_INFO(0, 0, 0, 0, 0, 0)  /* Table terminator */
>  };
>  #else
> diff --git a/drivers/acpi/acpica/utdecode.c b/drivers/acpi/acpica/utdecode.c
> index 6ba65b0..efd7988 100644
> --- a/drivers/acpi/acpica/utdecode.c
> +++ b/drivers/acpi/acpica/utdecode.c
> @@ -446,7 +446,7 @@ const char *acpi_ut_get_mutex_name(u32 mutex_id)
>  
>  /* Names for Notify() values, used for debug output */
>  
> -static const char *acpi_gbl_generic_notify[ACPI_NOTIFY_MAX + 1] = {
> +static const char *acpi_gbl_generic_notify[ACPI_GENERIC_NOTIFY_MAX + 1] = {
>   /* 00 */ "Bus Check",
>   /* 01 */ "Device Check",
>   /* 02 */ "Device Wake",
> @@ -459,49 +459,53 @@ static const char 
> *acpi_gbl_generic_notify[ACPI_NOTIFY_MAX + 1] = {
>   /* 09 */ "Device PLD Check",
>   /* 0A */ "Reserved",
>   /* 0B */ "System Locality Update",
> - /* 0C */ "Shutdown Request",
> + /* 0C */ "Shutdown Request",
> + /* Reserved in ACPI 6.0 */
>   /* 0D */ "System Resource Affinity Update"
>  };
>  
> -static const char *acpi_gbl_device_notify[4] = {
> +static const char *acpi_gbl_device_notify[5] = {
>   /* 80 */ "Status Change",
>   /* 81 */ "Information Change",
>   /* 82 */ "Device-Specific Change",
> - /* 83 */ "Device-Specific Change"
> + /* 83 */ "Device-Specific Change",
> + /* 84 */ "Reserved"
>  };
>  
> -static const char *acpi_gbl_processor_notify[4] = {
> +static const char *acpi_gbl_processor_notify[5] = {
>   /* 80 */ "Performance Capability Change",
>   /* 81 */ "C-State Change",
>   /* 82 */ "Throttling Capability Change",
> - /* 83 */ "Device-Specific Change"
> + /* 83 */ "Guaranteed Change",
> + /* 84 */ "Minimum Excursion"
>  };
>  
> -static const char *acpi_gbl_thermal_notify[4] = {
> +static const char *acpi_gbl_thermal_notify[5] = {
>   /* 80 */ "Thermal Status Change",
>   /* 81 */ "Thermal Trip Point Change",
>   /* 82 */ "Thermal Device List Change",
> - /* 83 */ "Thermal Relationship Change"
> + /* 83 */ "Thermal Relationship Change",
> + /* 84 */ "Reserved"
>  };
>  
>  const char *acpi_ut_get_notify_name(u32 notify_value, acpi_object_type type)
>  {
>  
> - /* 00 - 0D are common to all object types */
> + /* 00 - 0D are "common to all object types" (from ACPI Spec) */
>  
> - if (notify_value <= ACPI_NOTIFY_MAX) {
> + if (notify_value <= ACPI_GENERIC_NOTIFY_MAX) {
>   return (acpi_gbl_generic_notify[notify_value]);
>   }
>  
> - /* 0D - 7F are reserved */
> + /* 0E - 7F are reserved */
>  
>   if (notify_value <= ACPI_MAX_SYS_NOTIFY) {
>   return ("Reserved");
>   }
>  
> - /* 80 - 83 are per-object-type */
> + /* 80 - 84 are per-object-type */
>  
> - if (notify_value <= 0x83) {
> + if (notify_value <= ACPI_SPECIFIC_NOTIFY_MAX) {
>   switch (type) {
>   case ACPI_TYPE_ANY:
>   case ACPI_TYPE_DEVICE:
> diff --git a/include/acpi/actbl.h b/include/acpi/actbl.h
> index 0cb1a00..6a4e521 100644
>