[PATCH] staging:vme Fix use BIT macro

[Janani Sankara Babu]

This patch is created to solve the following warning shown by the checkpatch
script Warning: Replace all occurences of (1<
---
 drivers/staging/vme/devices/vme_pio2.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/vme/devices/vme_pio2.h 
b/drivers/staging/vme/devices/vme_pio2.h
index ac4a4ba..e9c3cf6 100644
--- a/drivers/staging/vme/devices/vme_pio2.h
+++ b/drivers/staging/vme/devices/vme_pio2.h
@@ -179,7 +179,7 @@
PIO2_REGS_CTRL_WRD1 };
 
 #define PIO2_CNTR_SC_DEV0  0
-#define PIO2_CNTR_SC_DEV1  (1 << 6)
+#define PIO2_CNTR_SC_DEV1  BIT(6)
 #define PIO2_CNTR_SC_DEV2  (2 << 6)
 #define PIO2_CNTR_SC_RDBACK(3 << 6)
 
@@ -188,12 +188,12 @@
PIO2_CNTR_SC_DEV1, PIO2_CNTR_SC_DEV2 };
 
 #define PIO2_CNTR_RW_LATCH 0
-#define PIO2_CNTR_RW_LSB   (1 << 4)
+#define PIO2_CNTR_RW_LSB   BIT(4)
 #define PIO2_CNTR_RW_MSB   (2 << 4)
 #define PIO2_CNTR_RW_BOTH  (3 << 4)
 
 #define PIO2_CNTR_MODE00
-#define PIO2_CNTR_MODE1(1 << 1)
+#define PIO2_CNTR_MODE1BIT(1)
 #define PIO2_CNTR_MODE2(2 << 1)
 #define PIO2_CNTR_MODE3(3 << 1)
 #define PIO2_CNTR_MODE4(4 << 1)
-- 
1.9.1

[PATCH] staging:vme Fix use BIT macro

[Janani Sankara Babu]

This patch is created to solve the following warning shown by the checkpatch
script Warning: Replace all occurences of (1<
---
 drivers/staging/vme/devices/vme_pio2.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/staging/vme/devices/vme_pio2.h 
b/drivers/staging/vme/devices/vme_pio2.h
index ac4a4ba..e9c3cf6 100644
--- a/drivers/staging/vme/devices/vme_pio2.h
+++ b/drivers/staging/vme/devices/vme_pio2.h
@@ -179,7 +179,7 @@
PIO2_REGS_CTRL_WRD1 };
 
 #define PIO2_CNTR_SC_DEV0  0
-#define PIO2_CNTR_SC_DEV1  (1 << 6)
+#define PIO2_CNTR_SC_DEV1  BIT(6)
 #define PIO2_CNTR_SC_DEV2  (2 << 6)
 #define PIO2_CNTR_SC_RDBACK(3 << 6)
 
@@ -188,12 +188,12 @@
PIO2_CNTR_SC_DEV1, PIO2_CNTR_SC_DEV2 };
 
 #define PIO2_CNTR_RW_LATCH 0
-#define PIO2_CNTR_RW_LSB   (1 << 4)
+#define PIO2_CNTR_RW_LSB   BIT(4)
 #define PIO2_CNTR_RW_MSB   (2 << 4)
 #define PIO2_CNTR_RW_BOTH  (3 << 4)
 
 #define PIO2_CNTR_MODE00
-#define PIO2_CNTR_MODE1(1 << 1)
+#define PIO2_CNTR_MODE1BIT(1)
 #define PIO2_CNTR_MODE2(2 << 1)
 #define PIO2_CNTR_MODE3(3 << 1)
 #define PIO2_CNTR_MODE4(4 << 1)
-- 
1.9.1

Re: [RFC] sched/fair: Use wake_q length as a hint for wake_wide

[Joel Fernandes]

On Wed, Sep 20, 2017 at 2:17 PM, Atish Patra  wrote:
> On 09/20/2017 03:23 PM, Joel Fernandes wrote:
>>
>> On Wed, Sep 20, 2017 at 2:33 AM, Brendan Jackman
>>  wrote:
>>>
>>>
>>> On Wed, Sep 20 2017 at 05:06, Joel Fernandes wrote:
>
> On Tue, Sep 19, 2017 at 3:05 AM, Brendan Jackman
>  wrote:
>>
>> On Mon, Sep 18 2017 at 22:15, Joel Fernandes wrote:

 [..]

 IIUC, if wake_affine() behaves correctly this trick wouldn't be
 necessary on SMP systems, so it might be best guarded by the
 presence
>>>
>>>
>>> Actually wake_affine doesn't check for balance if previous/next cpu
>>> are within the same shared cache domain. The difference is some time
>>> ago it would return true for shared cache but now it returns false
as
>>> of 4.14-rc1:
>>>
>>>
http://elixir.free-electrons.com/linux/v4.14-rc1/source/kernel/sched/fair.c#L5466
>>>
>>> Since it would return false in the above wake up cases for task 1
and
>>> 2, it would then run select_idle_sibling on the previous CPU which
is
>>> also within the big cluster, so I don't think it will make a
>>> difference in this case... Infact what it returns probably doesn't
>>> matter.
>>
>>
>> So my paragraph here was making a leap in reasoning, let me try to
>> fill
>> the gap: On SMP these tasks never need to move around. If by some
>> chance
>> they did get coscheduled, the first load balance would spread them
out
>> and
>> then every time they wake up from then on, prev_cpu is the sensible
>> choice. So it will look something like:
>>
>> v CPU v   ->time->
>>
>> -
>>  {  0  (SAME)   111
>>   cache  {  -
>>  {  1  (SAME)   |
>> -
>>  {  2  (SAME)   333
>>   cache  {  -
>>  {  3  (SAME)   444
>> -
>>
>> So here, task 2 wakes up the other guys and when it's doing tasks 3
>> and
>> 4, prev_cpu and smp_processor_id() don't share a cache, so IIUC its'
>> basically wake_affine's job to decide between prev_cpu and
>> smp_processor_id(). So "if wake_affine is behaving correctly" the
>> problem that this patch aims to solve (i.e. the fact that we overload
>> the waker's LLC domain because of bias towards prev_cpu) does not
>> arise
>> on SMP.
>>
>
> Yes SMP, but your patch is for solving a problem for non-SMP. So your
> original statement about wake_affine solving any problem for SMP is
> not relevant I feel :-P. I guess you can just kill this para from the
> commit message to prevent confusion.


 Ok I take that back, you were talking about guarding this feature by
 the SD_ASYM_CPUCAPACITY flag.

 I don't think that protection would be helpful because you can have
 the same issue if the tasks do different amount of work on SMP. So in
 that case some threads might still complete before the others and you
 run into the same thing.
>>>
>>>
>>> Well assuming we're still talking about one task per CPU, if you have
>>> tasks doing different amount of work there's still no reason to move the
>>> longer-running threads around. The only reason that happens in my
>>> example is because of the asym capacity.
>>
>>
>> Yes but you can very well have RT pressure and things that temporarily
>> change the capacity equality. Also this is a simple benchmark and for
>> any reason you have more than 1 task running on those other CPUs and
>> then the idle CPUs run some of the tasks and you run into a similar
>> situation that might need your patch..
>>
> The patch would be helpful only if it doesn't cross NUMA boundary. right ?
>
> If NUMA comes into picture, not sure searching across NUMA may hurt more
> than help, especially in this case.

I don't understand what you mean by "searching across NUMA", :-(, do you
mean the slow path?

As I said, if the SD_BALANCE_WAKE flag for the sched domain flag is not
set, then a full wide search isn't done anyway. You have this code that
sets the sd variable:

if (tmp->flags & sd_flag)
sd = tmp;

Since sd = NULL if the sched domain (tmp->flags) isn't set, you will
always have select_idle_sibling running and not doing the full search
if I understand correctly.

Further adding the ASYM protection isn't sensible if capacities are
affected by RT and IRQ time etc anyway. Does that make sense?

I am glad I understand the code a bit better now after staring at it
for quite some time but I think some more staring is needed.

- Joel

Re: [RFC] sched/fair: Use wake_q length as a hint for wake_wide

[Joel Fernandes]

On Wed, Sep 20, 2017 at 2:17 PM, Atish Patra  wrote:
> On 09/20/2017 03:23 PM, Joel Fernandes wrote:
>>
>> On Wed, Sep 20, 2017 at 2:33 AM, Brendan Jackman
>>  wrote:
>>>
>>>
>>> On Wed, Sep 20 2017 at 05:06, Joel Fernandes wrote:
>
> On Tue, Sep 19, 2017 at 3:05 AM, Brendan Jackman
>  wrote:
>>
>> On Mon, Sep 18 2017 at 22:15, Joel Fernandes wrote:

 [..]

 IIUC, if wake_affine() behaves correctly this trick wouldn't be
 necessary on SMP systems, so it might be best guarded by the
 presence
>>>
>>>
>>> Actually wake_affine doesn't check for balance if previous/next cpu
>>> are within the same shared cache domain. The difference is some time
>>> ago it would return true for shared cache but now it returns false
as
>>> of 4.14-rc1:
>>>
>>>
http://elixir.free-electrons.com/linux/v4.14-rc1/source/kernel/sched/fair.c#L5466
>>>
>>> Since it would return false in the above wake up cases for task 1
and
>>> 2, it would then run select_idle_sibling on the previous CPU which
is
>>> also within the big cluster, so I don't think it will make a
>>> difference in this case... Infact what it returns probably doesn't
>>> matter.
>>
>>
>> So my paragraph here was making a leap in reasoning, let me try to
>> fill
>> the gap: On SMP these tasks never need to move around. If by some
>> chance
>> they did get coscheduled, the first load balance would spread them
out
>> and
>> then every time they wake up from then on, prev_cpu is the sensible
>> choice. So it will look something like:
>>
>> v CPU v   ->time->
>>
>> -
>>  {  0  (SAME)   111
>>   cache  {  -
>>  {  1  (SAME)   |
>> -
>>  {  2  (SAME)   333
>>   cache  {  -
>>  {  3  (SAME)   444
>> -
>>
>> So here, task 2 wakes up the other guys and when it's doing tasks 3
>> and
>> 4, prev_cpu and smp_processor_id() don't share a cache, so IIUC its'
>> basically wake_affine's job to decide between prev_cpu and
>> smp_processor_id(). So "if wake_affine is behaving correctly" the
>> problem that this patch aims to solve (i.e. the fact that we overload
>> the waker's LLC domain because of bias towards prev_cpu) does not
>> arise
>> on SMP.
>>
>
> Yes SMP, but your patch is for solving a problem for non-SMP. So your
> original statement about wake_affine solving any problem for SMP is
> not relevant I feel :-P. I guess you can just kill this para from the
> commit message to prevent confusion.


 Ok I take that back, you were talking about guarding this feature by
 the SD_ASYM_CPUCAPACITY flag.

 I don't think that protection would be helpful because you can have
 the same issue if the tasks do different amount of work on SMP. So in
 that case some threads might still complete before the others and you
 run into the same thing.
>>>
>>>
>>> Well assuming we're still talking about one task per CPU, if you have
>>> tasks doing different amount of work there's still no reason to move the
>>> longer-running threads around. The only reason that happens in my
>>> example is because of the asym capacity.
>>
>>
>> Yes but you can very well have RT pressure and things that temporarily
>> change the capacity equality. Also this is a simple benchmark and for
>> any reason you have more than 1 task running on those other CPUs and
>> then the idle CPUs run some of the tasks and you run into a similar
>> situation that might need your patch..
>>
> The patch would be helpful only if it doesn't cross NUMA boundary. right ?
>
> If NUMA comes into picture, not sure searching across NUMA may hurt more
> than help, especially in this case.

I don't understand what you mean by "searching across NUMA", :-(, do you
mean the slow path?

As I said, if the SD_BALANCE_WAKE flag for the sched domain flag is not
set, then a full wide search isn't done anyway. You have this code that
sets the sd variable:

if (tmp->flags & sd_flag)
sd = tmp;

Since sd = NULL if the sched domain (tmp->flags) isn't set, you will
always have select_idle_sibling running and not doing the full search
if I understand correctly.

Further adding the ASYM protection isn't sensible if capacities are
affected by RT and IRQ time etc anyway. Does that make sense?

I am glad I understand the code a bit better now after staring at it
for quite some time but I think some more staring is needed.

- Joel

[PATCH] staging:rtl8188eu Fix remove semicolon in do {}while(0)

[Janani Sankara Babu]

This patch removes the semicolon at the end of while statement in the
do while macro , inorder to avoid it behaving like compound statement.

Signed-off-by: Janani Sankara Babu 
---
 drivers/staging/rtl8188eu/core/rtw_security.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c 
b/drivers/staging/rtl8188eu/core/rtw_security.c
index b283a490..5b1ef22 100644
--- a/drivers/staging/rtl8188eu/core/rtw_security.c
+++ b/drivers/staging/rtl8188eu/core/rtw_security.c
@@ -1690,4 +1690,4 @@ u32   rtw_aes_decrypt(struct adapter *padapter, u8 
*precvframe)
d##1 = TE0(s##1) ^ TE1(s##2) ^ TE2(s##3) ^ TE3(s##0) ^ rk[4 * i + 1]; \
d##2 = TE0(s##2) ^ TE1(s##3) ^ TE2(s##0) ^ TE3(s##1) ^ rk[4 * i + 2]; \
d##3 = TE0(s##3) ^ TE1(s##0) ^ TE2(s##1) ^ TE3(s##2) ^ rk[4 * i + 3]; \
-} while (0);
+} while (0)
-- 
1.9.1

[PATCH] staging:rtl8188eu Fix remove semicolon in do {}while(0)

[Janani Sankara Babu]

This patch removes the semicolon at the end of while statement in the
do while macro , inorder to avoid it behaving like compound statement.

Signed-off-by: Janani Sankara Babu 
---
 drivers/staging/rtl8188eu/core/rtw_security.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/core/rtw_security.c 
b/drivers/staging/rtl8188eu/core/rtw_security.c
index b283a490..5b1ef22 100644
--- a/drivers/staging/rtl8188eu/core/rtw_security.c
+++ b/drivers/staging/rtl8188eu/core/rtw_security.c
@@ -1690,4 +1690,4 @@ u32   rtw_aes_decrypt(struct adapter *padapter, u8 
*precvframe)
d##1 = TE0(s##1) ^ TE1(s##2) ^ TE2(s##3) ^ TE3(s##0) ^ rk[4 * i + 1]; \
d##2 = TE0(s##2) ^ TE1(s##3) ^ TE2(s##0) ^ TE3(s##1) ^ rk[4 * i + 2]; \
d##3 = TE0(s##3) ^ TE1(s##0) ^ TE2(s##1) ^ TE3(s##2) ^ rk[4 * i + 3]; \
-} while (0);
+} while (0)
-- 
1.9.1

[PATCH v2] PM / OPP: Use snprintf to avoid kasprintf and kfree

[Arvind Yadav]

Use snprintf to avoid unnecessary initializations, avoid calling kfree.

Signed-off-by: Arvind Yadav 
---
changes in v2:
 Remove kasprintf instead of error checking.

 drivers/base/power/opp/debugfs.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/base/power/opp/debugfs.c b/drivers/base/power/opp/debugfs.c
index 81cf120..a2fa785 100644
--- a/drivers/base/power/opp/debugfs.c
+++ b/drivers/base/power/opp/debugfs.c
@@ -41,16 +41,15 @@ static bool opp_debug_create_supplies(struct dev_pm_opp 
*opp,
 {
struct dentry *d;
int i;
-   char *name;
 
for (i = 0; i < opp_table->regulator_count; i++) {
-   name = kasprintf(GFP_KERNEL, "supply-%d", i);
+   char name[15];
+
+   snprintf(name, sizeof(name), "supply-%d", i);
 
/* Create per-opp directory */
d = debugfs_create_dir(name, pdentry);
 
-   kfree(name);
-
if (!d)
return false;
 
-- 
1.9.1

[PATCH v2] PM / OPP: Use snprintf to avoid kasprintf and kfree

[Arvind Yadav]

Use snprintf to avoid unnecessary initializations, avoid calling kfree.

Signed-off-by: Arvind Yadav 
---
changes in v2:
 Remove kasprintf instead of error checking.

 drivers/base/power/opp/debugfs.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/base/power/opp/debugfs.c b/drivers/base/power/opp/debugfs.c
index 81cf120..a2fa785 100644
--- a/drivers/base/power/opp/debugfs.c
+++ b/drivers/base/power/opp/debugfs.c
@@ -41,16 +41,15 @@ static bool opp_debug_create_supplies(struct dev_pm_opp 
*opp,
 {
struct dentry *d;
int i;
-   char *name;
 
for (i = 0; i < opp_table->regulator_count; i++) {
-   name = kasprintf(GFP_KERNEL, "supply-%d", i);
+   char name[15];
+
+   snprintf(name, sizeof(name), "supply-%d", i);
 
/* Create per-opp directory */
d = debugfs_create_dir(name, pdentry);
 
-   kfree(name);
-
if (!d)
return false;
 
-- 
1.9.1

[PATCH] staging:rtl8188eu:hal Fix wrong comparison to False

[Janani Sankara Babu]

This patch solves the warning "Using comparison to false is error prone"

Signed-off-by: Janani Sankara Babu 
---
 drivers/staging/rtl8188eu/hal/odm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/hal/odm.c 
b/drivers/staging/rtl8188eu/hal/odm.c
index ec8aae7..001d626 100644
--- a/drivers/staging/rtl8188eu/hal/odm.c
+++ b/drivers/staging/rtl8188eu/hal/odm.c
@@ -382,7 +382,7 @@ void odm_DIG(struct odm_dm_struct *pDM_Odm)
}
 
/* add by Neil Chen to avoid PSD is processing */
-   if (pDM_Odm->bDMInitialGainEnable == false) {
+   if (!pDM_Odm->bDMInitialGainEnable) {
ODM_RT_TRACE(pDM_Odm, ODM_COMP_DIG, ODM_DBG_LOUD, ("odm_DIG() 
Return: PSD is Processing\n"));
return;
}
-- 
1.9.1

[PATCH] staging:rtl8188eu:hal Fix wrong comparison to False

[Janani Sankara Babu]

This patch solves the warning "Using comparison to false is error prone"

Signed-off-by: Janani Sankara Babu 
---
 drivers/staging/rtl8188eu/hal/odm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8188eu/hal/odm.c 
b/drivers/staging/rtl8188eu/hal/odm.c
index ec8aae7..001d626 100644
--- a/drivers/staging/rtl8188eu/hal/odm.c
+++ b/drivers/staging/rtl8188eu/hal/odm.c
@@ -382,7 +382,7 @@ void odm_DIG(struct odm_dm_struct *pDM_Odm)
}
 
/* add by Neil Chen to avoid PSD is processing */
-   if (pDM_Odm->bDMInitialGainEnable == false) {
+   if (!pDM_Odm->bDMInitialGainEnable) {
ODM_RT_TRACE(pDM_Odm, ODM_COMP_DIG, ODM_DBG_LOUD, ("odm_DIG() 
Return: PSD is Processing\n"));
return;
}
-- 
1.9.1

Re: Memory hotplug regression in 4.13

[Seth Forshee]

On Wed, Sep 20, 2017 at 11:29:31AM +0200, Michal Hocko wrote:
> Hi,
> I am currently at a conference so I will most probably get to this next
> week but I will try to ASAP.
> 
> On Tue 19-09-17 11:41:14, Seth Forshee wrote:
> > Hi Michal,
> > 
> > I'm seeing oopses in various locations when hotplugging memory in an x86
> > vm while running a 32-bit kernel. The config I'm using is attached. To
> > reproduce I'm using kvm with the memory options "-m
> > size=512M,slots=3,maxmem=2G". Then in the qemu monitor I run:
> > 
> >   object_add memory-backend-ram,id=mem1,size=512M
> >   device_add pc-dimm,id=dimm1,memdev=mem1
> > 
> > Not long after that I'll see an oops, not always in the same location
> > but most often in wp_page_copy, like this one:
> 
> This is rather surprising. How do you online the memory?

The kernel has CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y.

> > [   24.673623] BUG: unable to handle kernel paging request at d000
> > [   24.675569] IP: wp_page_copy+0xa8/0x660
> 
> could you resolve the IP into the source line?

It seems I don't have that kernel anymore, but I've got a 4.14-rc1 build
and the problem still occurs there. It's pointing to the call to
__builtin_memcpy in memcpy (include/linux/string.h line 340), which we
get to via wp_page_copy -> cow_user_page -> copy_user_highpage.

Thanks,
Seth

Re: Memory hotplug regression in 4.13

[Seth Forshee]

On Wed, Sep 20, 2017 at 11:29:31AM +0200, Michal Hocko wrote:
> Hi,
> I am currently at a conference so I will most probably get to this next
> week but I will try to ASAP.
> 
> On Tue 19-09-17 11:41:14, Seth Forshee wrote:
> > Hi Michal,
> > 
> > I'm seeing oopses in various locations when hotplugging memory in an x86
> > vm while running a 32-bit kernel. The config I'm using is attached. To
> > reproduce I'm using kvm with the memory options "-m
> > size=512M,slots=3,maxmem=2G". Then in the qemu monitor I run:
> > 
> >   object_add memory-backend-ram,id=mem1,size=512M
> >   device_add pc-dimm,id=dimm1,memdev=mem1
> > 
> > Not long after that I'll see an oops, not always in the same location
> > but most often in wp_page_copy, like this one:
> 
> This is rather surprising. How do you online the memory?

The kernel has CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y.

> > [   24.673623] BUG: unable to handle kernel paging request at d000
> > [   24.675569] IP: wp_page_copy+0xa8/0x660
> 
> could you resolve the IP into the source line?

It seems I don't have that kernel anymore, but I've got a 4.14-rc1 build
and the problem still occurs there. It's pointing to the call to
__builtin_memcpy in memcpy (include/linux/string.h line 340), which we
get to via wp_page_copy -> cow_user_page -> copy_user_highpage.

Thanks,
Seth

Re: [PATCH] dt-bindings: nand: denali: reduce the register space in the example

[Masahiro Yamada]

Hi.


2017-09-14 18:06 GMT+09:00 Oleksij Rempel :
> On 14.09.2017 10:16, Masahiro Yamada wrote:
>>
>> Hi.
>>
>>
>> 2017-09-14 17:04 GMT+09:00 Oleksij Rempel :
>>>
>>> Hi,
>>>
>>> i assume arch/arm/boot/dts/socfpga.dtsi should be update as well. Right?
>>
>>
>> I think so.
>> (also arch/arm/boot/dts/socfpga_arria10.dtsi in the same way)
>
>
> Hm.. according to
> https://www.altera.com/en_US/pdfs/literature/hb/cyclone-v/cyclone5_handbook.pdf
> Table 13-18: NAND Controller Module Data Space Address Range
>
> Module Instance   Start AddressEnd Address
> NAND_DATA 0xFF90   0xFF9F
>
> So <0xff90 0x10> seems to be a proper value.
>

The Alrera's SOCFPGA document describes so.
It is up to each SoC vendor how to describe the register space.

I am focusing on the Denali IP
because this IP is used among several SoCs.



You can see the peripheral region map
starting at page 1-18 of the document you referred to:

Slave ID  Description  Base Addr  Size
---
L3REGSL3 interconnect GPV  0xFF80  1 MB
NANDDATA  NAND flash controller data   0xFF90 64 KB
QSPIDATA  Quad SPI flash data  0xFFA0  1 MB

(In the doc, the base is described as 0xFFB90, but this is
apparently a typo.)


The rationale of the "End Address 0xFF9F" of NAND_DATA
is the fact that the base address of the next peripheral (QSPIDATA) is
0xFFA0.




One more, if you look at the next page,

Slave ID  Description  Base Addr Size
---
NANDREGS  NAND flash controller registers   0xFFB8   64 KB
FPGAMGRDATA   FPGA manager configuration data   0xFFB94 KB


The size of NAND register space is described as 64KB,
but the rationale is just the start of the next peripheral is 0xFFB9.

(0xFFB9 - 0xFFB8 = 0x1 = 64KB)



Altera apparently reserved address space just for the purpose
of matching the end address to the base address of the next peripheral.


That means, this document specifies address region
much bigger than the IP actually provides.


If you look at page 13-6, there are only two registers
in NANDDATA space.

Table 13-4: Register Map for Indexed Addressing
Control   0x0
Data  0x10



For NANDREGS, in page 13-106, the following is the last register
in the NANDREGS space.

lun_status_cmd
Offset 0x7A0

Obviously, 0x1000 (4KB) is enough for NANDREGS.





To conclude this, this binding document was written
based on the Altera's SOCFPGA specification.

Altera specifies the region size
so that end address matches to the base of the next peripheral.
This is just a matter of SOCFPGA address mapping.

In my opinion, the binding document should not be oriented
to a particular SoC, which is not true for other SoCs.




-- 
Best Regards
Masahiro Yamada

Re: [PATCH] dt-bindings: nand: denali: reduce the register space in the example

[Masahiro Yamada]

Hi.


2017-09-14 18:06 GMT+09:00 Oleksij Rempel :
> On 14.09.2017 10:16, Masahiro Yamada wrote:
>>
>> Hi.
>>
>>
>> 2017-09-14 17:04 GMT+09:00 Oleksij Rempel :
>>>
>>> Hi,
>>>
>>> i assume arch/arm/boot/dts/socfpga.dtsi should be update as well. Right?
>>
>>
>> I think so.
>> (also arch/arm/boot/dts/socfpga_arria10.dtsi in the same way)
>
>
> Hm.. according to
> https://www.altera.com/en_US/pdfs/literature/hb/cyclone-v/cyclone5_handbook.pdf
> Table 13-18: NAND Controller Module Data Space Address Range
>
> Module Instance   Start AddressEnd Address
> NAND_DATA 0xFF90   0xFF9F
>
> So <0xff90 0x10> seems to be a proper value.
>

The Alrera's SOCFPGA document describes so.
It is up to each SoC vendor how to describe the register space.

I am focusing on the Denali IP
because this IP is used among several SoCs.



You can see the peripheral region map
starting at page 1-18 of the document you referred to:

Slave ID  Description  Base Addr  Size
---
L3REGSL3 interconnect GPV  0xFF80  1 MB
NANDDATA  NAND flash controller data   0xFF90 64 KB
QSPIDATA  Quad SPI flash data  0xFFA0  1 MB

(In the doc, the base is described as 0xFFB90, but this is
apparently a typo.)


The rationale of the "End Address 0xFF9F" of NAND_DATA
is the fact that the base address of the next peripheral (QSPIDATA) is
0xFFA0.




One more, if you look at the next page,

Slave ID  Description  Base Addr Size
---
NANDREGS  NAND flash controller registers   0xFFB8   64 KB
FPGAMGRDATA   FPGA manager configuration data   0xFFB94 KB


The size of NAND register space is described as 64KB,
but the rationale is just the start of the next peripheral is 0xFFB9.

(0xFFB9 - 0xFFB8 = 0x1 = 64KB)



Altera apparently reserved address space just for the purpose
of matching the end address to the base address of the next peripheral.


That means, this document specifies address region
much bigger than the IP actually provides.


If you look at page 13-6, there are only two registers
in NANDDATA space.

Table 13-4: Register Map for Indexed Addressing
Control   0x0
Data  0x10



For NANDREGS, in page 13-106, the following is the last register
in the NANDREGS space.

lun_status_cmd
Offset 0x7A0

Obviously, 0x1000 (4KB) is enough for NANDREGS.





To conclude this, this binding document was written
based on the Altera's SOCFPGA specification.

Altera specifies the region size
so that end address matches to the base of the next peripheral.
This is just a matter of SOCFPGA address mapping.

In my opinion, the binding document should not be oriented
to a particular SoC, which is not true for other SoCs.




-- 
Best Regards
Masahiro Yamada

[PATCH v2 2/3] ASoC: fsl-asoc-card: Handle return value of devm_kasprintf

[Arvind Yadav]

devm_kasprintf() can fail here and we must check its return value.

Signed-off-by: Arvind Yadav 
---
changes in v2:
   Set return 'ret' to -ENOMEM.

 sound/soc/fsl/fsl-asoc-card.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 2db4d0c..a389885 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -639,6 +639,10 @@ static int fsl_asoc_card_probe(struct platform_device 
*pdev)
devm_kasprintf(>dev, GFP_KERNEL,
   "ac97-codec.%u",
   (unsigned int)idx);
+   if (!priv->dai_link[0].codec_name) {
+   ret = -ENOMEM;
+   goto asrc_fail;
+   }
}
 
priv->dai_link[0].platform_of_node = cpu_np;
-- 
1.9.1

[PATCH v2 2/3] ASoC: fsl-asoc-card: Handle return value of devm_kasprintf

[Arvind Yadav]

devm_kasprintf() can fail here and we must check its return value.

Signed-off-by: Arvind Yadav 
---
changes in v2:
   Set return 'ret' to -ENOMEM.

 sound/soc/fsl/fsl-asoc-card.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/sound/soc/fsl/fsl-asoc-card.c b/sound/soc/fsl/fsl-asoc-card.c
index 2db4d0c..a389885 100644
--- a/sound/soc/fsl/fsl-asoc-card.c
+++ b/sound/soc/fsl/fsl-asoc-card.c
@@ -639,6 +639,10 @@ static int fsl_asoc_card_probe(struct platform_device 
*pdev)
devm_kasprintf(>dev, GFP_KERNEL,
   "ac97-codec.%u",
   (unsigned int)idx);
+   if (!priv->dai_link[0].codec_name) {
+   ret = -ENOMEM;
+   goto asrc_fail;
+   }
}
 
priv->dai_link[0].platform_of_node = cpu_np;
-- 
1.9.1

Re: [PATCH] nvme: make controller 'state' sysfs attribute pollable

[Johannes Thumshirn]

On Wed, Sep 20, 2017 at 04:59:31PM +0200, Christoph Hellwig wrote:
> On Wed, Sep 20, 2017 at 12:40:32PM +0200, Johannes Thumshirn wrote:
> > Notify sysfs about changes of a nvme controller so user-space can watch the
> > file via poll() or select() in order to react to a state change.
> 
> Userspace has no business polling for the state.

So why exposing it then in the first time? I know you don't want dm-mpath in
NVMe (neither do I) but we have to have something until your patchset and ANA
is merged. And with this patch it's trivial to build a path checker that just
looks at the state attribute in sysfs.

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

Re: [PATCH] nvme: make controller 'state' sysfs attribute pollable

[Johannes Thumshirn]

On Wed, Sep 20, 2017 at 04:59:31PM +0200, Christoph Hellwig wrote:
> On Wed, Sep 20, 2017 at 12:40:32PM +0200, Johannes Thumshirn wrote:
> > Notify sysfs about changes of a nvme controller so user-space can watch the
> > file via poll() or select() in order to react to a state change.
> 
> Userspace has no business polling for the state.

So why exposing it then in the first time? I know you don't want dm-mpath in
NVMe (neither do I) but we have to have something until your patchset and ANA
is merged. And with this patch it's trivial to build a path checker that just
looks at the state attribute in sysfs.

-- 
Johannes Thumshirn  Storage
jthumsh...@suse.de+49 911 74053 689
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg
GF: Felix Imendörffer, Jane Smithard, Graham Norton
HRB 21284 (AG Nürnberg)
Key fingerprint = EC38 9CAB C2C4 F25D 8600 D0D0 0393 969D 2D76 0850

[PATCH v2 1/2] gpio: brcmstb: Handle return value of devm_kasprintf

[Arvind Yadav]

devm_kasprintf() can fail here and we must check its return value.

Signed-off-by: Arvind Yadav 
---
changes in v2 :
Set return 'err' to -ENOMEM.

 drivers/gpio/gpio-brcmstb.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpio/gpio-brcmstb.c b/drivers/gpio/gpio-brcmstb.c
index dd0308c..27e92e5 100644
--- a/drivers/gpio/gpio-brcmstb.c
+++ b/drivers/gpio/gpio-brcmstb.c
@@ -485,6 +485,10 @@ static int brcmstb_gpio_probe(struct platform_device *pdev)
gc->of_node = np;
gc->owner = THIS_MODULE;
gc->label = devm_kasprintf(dev, GFP_KERNEL, "%pOF", 
dev->of_node);
+   if (!gc->label) {
+   err = -ENOMEM;
+   goto fail;
+   }
gc->base = gpio_base;
gc->of_gpio_n_cells = 2;
gc->of_xlate = brcmstb_gpio_of_xlate;
-- 
1.9.1

[PATCH v2 1/2] gpio: brcmstb: Handle return value of devm_kasprintf

[Arvind Yadav]

devm_kasprintf() can fail here and we must check its return value.

Signed-off-by: Arvind Yadav 
---
changes in v2 :
Set return 'err' to -ENOMEM.

 drivers/gpio/gpio-brcmstb.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpio/gpio-brcmstb.c b/drivers/gpio/gpio-brcmstb.c
index dd0308c..27e92e5 100644
--- a/drivers/gpio/gpio-brcmstb.c
+++ b/drivers/gpio/gpio-brcmstb.c
@@ -485,6 +485,10 @@ static int brcmstb_gpio_probe(struct platform_device *pdev)
gc->of_node = np;
gc->owner = THIS_MODULE;
gc->label = devm_kasprintf(dev, GFP_KERNEL, "%pOF", 
dev->of_node);
+   if (!gc->label) {
+   err = -ENOMEM;
+   goto fail;
+   }
gc->base = gpio_base;
gc->of_gpio_n_cells = 2;
gc->of_xlate = brcmstb_gpio_of_xlate;
-- 
1.9.1

Re: [PATCH net-next] net: dsa: use dedicated CPU port

[Florian Fainelli]

On 09/20/2017 09:28 AM, Vivien Didelot wrote:
> Each port in DSA has its own dedicated CPU port currently available in
> its parent switch's ds->ports[port].cpu_dp. Use it instead of getting
> the unique tree CPU port, which will be deprecated soon.
> 
> Signed-off-by: Vivien Didelot 
> ---
>  drivers/net/dsa/b53/b53_common.c | 4 ++--
>  drivers/net/dsa/bcm_sf2.c| 6 +++---
Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH net-next] net: dsa: use dedicated CPU port

[Florian Fainelli]

On 09/20/2017 09:28 AM, Vivien Didelot wrote:
> Each port in DSA has its own dedicated CPU port currently available in
> its parent switch's ds->ports[port].cpu_dp. Use it instead of getting
> the unique tree CPU port, which will be deprecated soon.
> 
> Signed-off-by: Vivien Didelot 
> ---
>  drivers/net/dsa/b53/b53_common.c | 4 ++--
>  drivers/net/dsa/bcm_sf2.c| 6 +++---
Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH net-next] net: dsa: add port fdb dump

[Florian Fainelli]

On 09/20/2017 04:32 PM, Vivien Didelot wrote:
> Dumping a DSA port's FDB entries is not specific to a DSA slave, so add
> a dsa_port_fdb_dump function, similarly to dsa_port_fdb_add and
> dsa_port_fdb_del.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH net-next] net: dsa: add port fdb dump

[Florian Fainelli]

On 09/20/2017 04:32 PM, Vivien Didelot wrote:
> Dumping a DSA port's FDB entries is not specific to a DSA slave, so add
> a dsa_port_fdb_dump function, similarly to dsa_port_fdb_add and
> dsa_port_fdb_del.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH net-next] net: dsa: better scoping of slave functions

[Florian Fainelli]

On 09/20/2017 04:31 PM, Vivien Didelot wrote:
> A few DSA slave functions take a dsa_slave_priv pointer as first
> argument, whereas the scope of the slave.c functions is the slave
> net_device structure. Fix this and rename dsa_netpoll_send_skb to
> dsa_slave_netpoll_send_skb.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH net-next] net: dsa: better scoping of slave functions

[Florian Fainelli]

On 09/20/2017 04:31 PM, Vivien Didelot wrote:
> A few DSA slave functions take a dsa_slave_priv pointer as first
> argument, whereas the scope of the slave.c functions is the slave
> net_device structure. Fix this and rename dsa_netpoll_send_skb to
> dsa_slave_netpoll_send_skb.
> 
> Signed-off-by: Vivien Didelot 

Reviewed-by: Florian Fainelli 
-- 
Florian

Re: [PATCH v2] vfs: introduce UMOUNT_WAIT which waits for umount completion

[Jaegeuk Kim]

On 09/21, Al Viro wrote:
> On Wed, Sep 20, 2017 at 05:34:09PM -0700, Jaegeuk Kim wrote:
> > >   flush_delayed_fput()
> > >   does nothing, the list is empty
> > 
> > how about waiting for workqueue completion here?
> > 
> > >   
> > 
> > If all the __fput()s are not finished, do_umount() will return -EBUSY.
> 
> Hell, no.  That's only when they are all on the same vfsmount.  And in that
> case you don't need any waiting - if any of those mntput() is not past the
> unlock_mount_hash() in mntput_no_expire(), you will get -EBUSY.  And if they
> all are, the caller of umount(2) will end up dropping the last reference.  
> In which case the shutdown will be scheduled via task_work_add() and processed
> before umount(2) returns to userland.

Yes, what I'm trying to do with this flag would be waiting for releasing
mnt_count in the same vfsmount as well as sb->s_active across namespaces.
So, here at first, I wanted to wait for delayed_fput which grabs mnt_count
in the same vfsmount, so that do_umount() could be succeeded in time. If
this is the last remaining namespace, waiting for delayed_mntput enables
us to shut the filesystem down by task_work at the end of umount(2).

> The whole problem is that you have several vfsmounts over the same filesystem
> (== same struct super_block), some of them held by kernel threads of yours.
> umount(2) doesn't affect those and isn't affected by those.  What you do is,
> AFAICS,
>   ask the kernel threads to start shutting down
>   umount()
>   shut device down, hoping that all vfsmounts that used
> to be held by those threads are gone by that point.

Yes, and actually, android retries umount(2) for several seconds, if it gets
failure. So, first I thought it'd be better to make umount() more deterministic.

> Your patch tries to stick "flush the pending work" in the umount().
> With no warranty that it will catch that stuff in the stage where
> flushing will affect anything.
> 
> > +void flush_delayed_fput_wait(void)
> > +{
> > +   delayed_fput(NULL);
> > +   flush_delayed_work(_fput_work);
> > +}
> 
> > +void flush_delayed_mntput_wait(void)
> > +{
> > +   delayed_mntput(NULL);
> > +   flush_delayed_work(_mntput_work);
> > +}
> 
> It's still a broken approach.  What I don't understand is why bother
> with that sort of brittle logics in the first place.  Why not simply
> open the damn thing with O_EXCL before proceeding to device shutdown?
> And if you get "busy" from that, wait and retry...

I'm not sure how many times we can retry and wait for this. IMHO, it'd be better
to use this together with the new flag, since this can detect unclosed namespace
given successful umount(2).

Re: [PATCH v2] vfs: introduce UMOUNT_WAIT which waits for umount completion

[Jaegeuk Kim]

On 09/21, Al Viro wrote:
> On Wed, Sep 20, 2017 at 05:34:09PM -0700, Jaegeuk Kim wrote:
> > >   flush_delayed_fput()
> > >   does nothing, the list is empty
> > 
> > how about waiting for workqueue completion here?
> > 
> > >   
> > 
> > If all the __fput()s are not finished, do_umount() will return -EBUSY.
> 
> Hell, no.  That's only when they are all on the same vfsmount.  And in that
> case you don't need any waiting - if any of those mntput() is not past the
> unlock_mount_hash() in mntput_no_expire(), you will get -EBUSY.  And if they
> all are, the caller of umount(2) will end up dropping the last reference.  
> In which case the shutdown will be scheduled via task_work_add() and processed
> before umount(2) returns to userland.

Yes, what I'm trying to do with this flag would be waiting for releasing
mnt_count in the same vfsmount as well as sb->s_active across namespaces.
So, here at first, I wanted to wait for delayed_fput which grabs mnt_count
in the same vfsmount, so that do_umount() could be succeeded in time. If
this is the last remaining namespace, waiting for delayed_mntput enables
us to shut the filesystem down by task_work at the end of umount(2).

> The whole problem is that you have several vfsmounts over the same filesystem
> (== same struct super_block), some of them held by kernel threads of yours.
> umount(2) doesn't affect those and isn't affected by those.  What you do is,
> AFAICS,
>   ask the kernel threads to start shutting down
>   umount()
>   shut device down, hoping that all vfsmounts that used
> to be held by those threads are gone by that point.

Yes, and actually, android retries umount(2) for several seconds, if it gets
failure. So, first I thought it'd be better to make umount() more deterministic.

> Your patch tries to stick "flush the pending work" in the umount().
> With no warranty that it will catch that stuff in the stage where
> flushing will affect anything.
> 
> > +void flush_delayed_fput_wait(void)
> > +{
> > +   delayed_fput(NULL);
> > +   flush_delayed_work(_fput_work);
> > +}
> 
> > +void flush_delayed_mntput_wait(void)
> > +{
> > +   delayed_mntput(NULL);
> > +   flush_delayed_work(_mntput_work);
> > +}
> 
> It's still a broken approach.  What I don't understand is why bother
> with that sort of brittle logics in the first place.  Why not simply
> open the damn thing with O_EXCL before proceeding to device shutdown?
> And if you get "busy" from that, wait and retry...

I'm not sure how many times we can retry and wait for this. IMHO, it'd be better
to use this together with the new flag, since this can detect unclosed namespace
given successful umount(2).

Re: [PATCH v2 8/8] PM / devfreq: exynos-bus: Register cooling device

[Chanwoo Choi]

Dear all,

Please ignore this patch. It has some problem.
I'll fix and resend this patch on v2.

Chanwoo Choi
Samsung Electronics

On 2017년 09월 21일 09:33, Chanwoo Choi wrote:
> This patch registers the Exynos Bus-Frequency scaling device
> as a cooling device of thermal management.
> 
> Signed-off-by: Chanwoo Choi 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  drivers/devfreq/Kconfig  |  1 +
>  drivers/devfreq/exynos-bus.c | 11 +++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 6a172d338f6d..eb8128e08b2c 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -81,6 +81,7 @@ config ARM_EXYNOS_BUS_DEVFREQ
>   select DEVFREQ_GOV_SIMPLE_ONDEMAND
>   select DEVFREQ_GOV_PASSIVE
>   select DEVFREQ_EVENT_EXYNOS_PPMU
> + select DEVFREQ_THERMAL
>   select PM_DEVFREQ_EVENT
>   select PM_OPP
>   help
> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> index c25658b26598..200ca0d11834 100644
> --- a/drivers/devfreq/exynos-bus.c
> +++ b/drivers/devfreq/exynos-bus.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -41,6 +42,8 @@ struct exynos_bus {
>   struct clk *clk;
>   unsigned int voltage_tolerance;
>   unsigned int ratio;
> +
> + struct thermal_cooling_device *cdev;
>  };
>  
>  /*
> @@ -468,6 +471,14 @@ static int exynos_bus_probe(struct platform_device *pdev)
>   goto err;
>   }
>  
> + /* Register devfreq cooling device */
> + bus->cdev = of_devfreq_cooling_register(np, bus->devfreq);
> + if (IS_ERR(bus->cdev) < 0) {
> + dev_err(dev, "failed to register cooling device\n");
> + ret = PTR_ERR(bus->cdev);
> + goto err;
> + }
> +
>   goto out;
>  passive:
>   /* Initialize the struct profile and governor data for passive device */
> 

Re: [PATCH v2 8/8] PM / devfreq: exynos-bus: Register cooling device

[Chanwoo Choi]

Dear all,

Please ignore this patch. It has some problem.
I'll fix and resend this patch on v2.

Chanwoo Choi
Samsung Electronics

On 2017년 09월 21일 09:33, Chanwoo Choi wrote:
> This patch registers the Exynos Bus-Frequency scaling device
> as a cooling device of thermal management.
> 
> Signed-off-by: Chanwoo Choi 
> Cc: Kukjin Kim 
> Cc: Krzysztof Kozlowski 
> Cc: linux-samsung-...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> ---
>  drivers/devfreq/Kconfig  |  1 +
>  drivers/devfreq/exynos-bus.c | 11 +++
>  2 files changed, 12 insertions(+)
> 
> diff --git a/drivers/devfreq/Kconfig b/drivers/devfreq/Kconfig
> index 6a172d338f6d..eb8128e08b2c 100644
> --- a/drivers/devfreq/Kconfig
> +++ b/drivers/devfreq/Kconfig
> @@ -81,6 +81,7 @@ config ARM_EXYNOS_BUS_DEVFREQ
>   select DEVFREQ_GOV_SIMPLE_ONDEMAND
>   select DEVFREQ_GOV_PASSIVE
>   select DEVFREQ_EVENT_EXYNOS_PPMU
> + select DEVFREQ_THERMAL
>   select PM_DEVFREQ_EVENT
>   select PM_OPP
>   help
> diff --git a/drivers/devfreq/exynos-bus.c b/drivers/devfreq/exynos-bus.c
> index c25658b26598..200ca0d11834 100644
> --- a/drivers/devfreq/exynos-bus.c
> +++ b/drivers/devfreq/exynos-bus.c
> @@ -15,6 +15,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -41,6 +42,8 @@ struct exynos_bus {
>   struct clk *clk;
>   unsigned int voltage_tolerance;
>   unsigned int ratio;
> +
> + struct thermal_cooling_device *cdev;
>  };
>  
>  /*
> @@ -468,6 +471,14 @@ static int exynos_bus_probe(struct platform_device *pdev)
>   goto err;
>   }
>  
> + /* Register devfreq cooling device */
> + bus->cdev = of_devfreq_cooling_register(np, bus->devfreq);
> + if (IS_ERR(bus->cdev) < 0) {
> + dev_err(dev, "failed to register cooling device\n");
> + ret = PTR_ERR(bus->cdev);
> + goto err;
> + }
> +
>   goto out;
>  passive:
>   /* Initialize the struct profile and governor data for passive device */
> 

Re:Re: [PATCH net-next] net: Remove useless function skb_header_release

[Gao Feng]

At 2017-09-21 05:30:46, "David Miller"  wrote:
>From: gfree.w...@vip.163.com
>Date: Tue, 19 Sep 2017 22:32:48 +0800
>
>> From: Gao Feng 
>> 
>> There is no one which would invokes the function skb_header_release.
>> So just remove it now.
>> 
>> Signed-off-by: Gao Feng 
>
>Networking patches must be at least CC:'d to net...@vger.kernel.org,
>thank you.

Thanks your reminder.
I just used the result of get_maintainer.pl, and didn't noticed this point you 
mentioned.

I would send it again.

Regards
Feng

Re:Re: [PATCH net-next] net: Remove useless function skb_header_release

[Gao Feng]

At 2017-09-21 05:30:46, "David Miller"  wrote:
>From: gfree.w...@vip.163.com
>Date: Tue, 19 Sep 2017 22:32:48 +0800
>
>> From: Gao Feng 
>> 
>> There is no one which would invokes the function skb_header_release.
>> So just remove it now.
>> 
>> Signed-off-by: Gao Feng 
>
>Networking patches must be at least CC:'d to net...@vger.kernel.org,
>thank you.

Thanks your reminder.
I just used the result of get_maintainer.pl, and didn't noticed this point you 
mentioned.

I would send it again.

Regards
Feng

Re: [PATCH] powerpc/perf: Fix for core/nest imc call trace on cpuhotplug

[Michael Ellerman]

Anju T Sudhakar  writes:

> Nest/core pmu units are enabled only when it is used. A reference count is
> maintained for the events which uses the nest/core pmu units. Currently in
> *_imc_counters_release function a WARN() is used for notification of any
> underflow of ref count. Replace WARN() with a pr_info since it is an overkill.

As discussed elsewhere this is not the right solution.

If it's OK for the reference count to be negative, then we shouldn't
print anything when it is.

But I don't understand how it can be OK for the refcount to be negative.
That means someone has a negative number of references to something?

cheers

Re: [PATCH] powerpc/perf: Fix for core/nest imc call trace on cpuhotplug

[Michael Ellerman]

Anju T Sudhakar  writes:

> Nest/core pmu units are enabled only when it is used. A reference count is
> maintained for the events which uses the nest/core pmu units. Currently in
> *_imc_counters_release function a WARN() is used for notification of any
> underflow of ref count. Replace WARN() with a pr_info since it is an overkill.

As discussed elsewhere this is not the right solution.

If it's OK for the reference count to be negative, then we shouldn't
print anything when it is.

But I don't understand how it can be OK for the refcount to be negative.
That means someone has a negative number of references to something?

cheers

Re: [PATCH V6 2/3] dma-mapping: Rework dma_get_cache_alignment()function

[陈华才]

Hi, Christoph,

I have changed dma_get_cache_alignment's return value, and I don't know whether 
those drivers want to return ARCH_DMA_MINALIGN unconditionally. So I pass a 
NULL for those drivers, in order to keep their old behavior.
 
Huacai
 
-- Original --
From:  "Christoph Hellwig";
Date:  Tue, Sep 19, 2017 11:02 PM
To:  "Huacai Chen"; 
Cc:  "Christoph Hellwig"; "Marek 
Szyprowski"; "Robin Murphy"; 
"Andrew Morton"; "Fuxin Zhang"; 
"linux-kernel"; "James E . J . 
Bottomley"; "Martin K . 
Petersen"; 
"linux-scsi"; "stable"; 
Subject:  Re: [PATCH V6 2/3] dma-mapping: Rework 
dma_get_cache_alignment()function

 
>   mdev->limits.reserved_mtts = ALIGN(mdev->limits.reserved_mtts * 
> mdev->limits.mtt_seg_size,
> -dma_get_cache_alignment()) / 
> mdev->limits.mtt_seg_size;
> +dma_get_cache_alignment(NULL)) / 
> mdev->limits.mtt_seg_size;
>  
>   mdev->mr_table.mtt_table = mthca_alloc_icm_table(mdev, 
> init_hca->mtt_base,

Please pass the actually relevant struct device for each call.

Re: [PATCH V6 2/3] dma-mapping: Rework dma_get_cache_alignment()function

[陈华才]

Hi, Christoph,

I have changed dma_get_cache_alignment's return value, and I don't know whether 
those drivers want to return ARCH_DMA_MINALIGN unconditionally. So I pass a 
NULL for those drivers, in order to keep their old behavior.
 
Huacai
 
-- Original --
From:  "Christoph Hellwig";
Date:  Tue, Sep 19, 2017 11:02 PM
To:  "Huacai Chen"; 
Cc:  "Christoph Hellwig"; "Marek 
Szyprowski"; "Robin Murphy"; 
"Andrew Morton"; "Fuxin Zhang"; 
"linux-kernel"; "James E . J . 
Bottomley"; "Martin K . 
Petersen"; 
"linux-scsi"; "stable"; 
Subject:  Re: [PATCH V6 2/3] dma-mapping: Rework 
dma_get_cache_alignment()function

 
>   mdev->limits.reserved_mtts = ALIGN(mdev->limits.reserved_mtts * 
> mdev->limits.mtt_seg_size,
> -dma_get_cache_alignment()) / 
> mdev->limits.mtt_seg_size;
> +dma_get_cache_alignment(NULL)) / 
> mdev->limits.mtt_seg_size;
>  
>   mdev->mr_table.mtt_table = mthca_alloc_icm_table(mdev, 
> init_hca->mtt_base,

Please pass the actually relevant struct device for each call.

[PATCH v2 5/5] clk: aspeed: Add reset controller

[Joel Stanley]

There are some resets that are not associated with gates. These are
represented by a reset controller.

Signed-off-by: Joel Stanley 
---
 drivers/clk/clk-aspeed.c | 82 +++-
 include/dt-bindings/clock/aspeed-clock.h |  9 
 2 files changed, 90 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk-aspeed.c b/drivers/clk/clk-aspeed.c
index dec9db4ec47b..db97c0f9f99e 100644
--- a/drivers/clk/clk-aspeed.c
+++ b/drivers/clk/clk-aspeed.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -256,6 +257,68 @@ static const struct clk_ops aspeed_clk_gate_ops = {
.is_enabled = aspeed_clk_is_enabled,
 };
 
+/**
+ * struct aspeed_reset - Aspeed reset controller
+ * @map: regmap to access the containing system controller
+ * @rcdev: reset controller device
+ */
+struct aspeed_reset {
+   struct regmap   *map;
+   struct reset_controller_dev rcdev;
+};
+
+#define to_aspeed_reset(p) container_of((p), struct aspeed_reset, rcdev)
+
+static const u8 aspeed_resets[] = {
+   25, /* x-dma */
+   24, /* mctp */
+   23, /* adc */
+   22, /* jtag-master */
+   18, /* mic */
+9, /* pwm */
+8, /* pci-vga */
+2, /* i2c */
+1, /* ahb */
+};
+
+static int aspeed_reset_deassert(struct reset_controller_dev *rcdev,
+unsigned long id)
+{
+   struct aspeed_reset *ar = to_aspeed_reset(rcdev);
+   u32 rst = BIT(aspeed_resets[id]);
+
+   return regmap_update_bits(ar->map, ASPEED_RESET_CTRL, rst, 0);
+}
+
+static int aspeed_reset_assert(struct reset_controller_dev *rcdev,
+  unsigned long id)
+{
+   struct aspeed_reset *ar = to_aspeed_reset(rcdev);
+   u32 rst = BIT(aspeed_resets[id]);
+
+   return regmap_update_bits(ar->map, ASPEED_RESET_CTRL, rst, rst);
+}
+
+static int aspeed_reset_status(struct reset_controller_dev *rcdev,
+  unsigned long id)
+{
+   struct aspeed_reset *ar = to_aspeed_reset(rcdev);
+   u32 val, rst = BIT(aspeed_resets[id]);
+   int ret;
+
+   ret = regmap_read(ar->map, ASPEED_RESET_CTRL, );
+   if (ret)
+   return ret;
+
+   return !!(val & rst);
+}
+
+static const struct reset_control_ops aspeed_reset_ops = {
+   .assert = aspeed_reset_assert,
+   .deassert = aspeed_reset_deassert,
+   .status = aspeed_reset_status,
+};
+
 static struct clk_hw *aspeed_clk_hw_register_gate(struct device *dev,
const char *name, const char *parent_name, unsigned long flags,
struct regmap *map, u8 clock_idx, u8 reset_idx,
@@ -299,10 +362,11 @@ static int __init aspeed_clk_probe(struct platform_device 
*pdev)
const struct clk_div_table *mac_div_table;
const struct clk_div_table *div_table;
struct device *dev = >dev;
+   struct aspeed_reset *ar;
struct regmap *map;
struct clk_hw *hw;
u32 val, rate;
-   int i;
+   int i, ret;
 
map = syscon_node_to_regmap(dev->of_node);
if (IS_ERR(map)) {
@@ -310,6 +374,22 @@ static int __init aspeed_clk_probe(struct platform_device 
*pdev)
return PTR_ERR(map);
}
 
+   ar = devm_kzalloc(dev, sizeof(*ar), GFP_KERNEL);
+   if (!ar)
+   return -ENOMEM;
+
+   ar->map = map;
+   ar->rcdev.owner = THIS_MODULE;
+   ar->rcdev.nr_resets = ARRAY_SIZE(aspeed_resets);
+   ar->rcdev.ops = _reset_ops;
+   ar->rcdev.of_node = dev->of_node;
+
+   ret = devm_reset_controller_register(dev, >rcdev);
+   if (ret) {
+   dev_err(dev, "could not register reset controller\n");
+   return ret;
+   }
+
/* SoC generations share common layouts but have different divisors */
soc_data = of_device_get_match_data(>dev);
div_table = soc_data->div_table;
diff --git a/include/dt-bindings/clock/aspeed-clock.h 
b/include/dt-bindings/clock/aspeed-clock.h
index afe06b77562d..a9d552b6bbd2 100644
--- a/include/dt-bindings/clock/aspeed-clock.h
+++ b/include/dt-bindings/clock/aspeed-clock.h
@@ -40,4 +40,13 @@
 #define ASPEED_CLK_GATE_SDCLKCLK   (22 + ASPEED_CLK_GATES)
 #define ASPEED_CLK_GATE_LHCCLK (23 + ASPEED_CLK_GATES)
 
+#define ASPEED_RESET_XDMA  0
+#define ASPEED_RESET_MCTP  1
+#define ASPEED_RESET_JTAG_MASTER   2
+#define ASPEED_RESET_MIC   3
+#define ASPEED_RESET_PWM   4
+#define ASPEED_RESET_PCIVGA5
+#define ASPEED_RESET_I2C   6
+#define ASPEED_RESET_AHB   7
+
 #endif
-- 
2.14.1

[PATCH v2 4/5] clk: aspeed: Register gated clocks

[Joel Stanley]

The majority of the clocks in the system are gates paired with a reset
controller that holds the IP in reset.

This borrows from clk_hw_register_gate, but registers two 'gates', one
to control the clock enable register and the other to control the reset
IP. This allows us to enforce the ordering:

 1. Place IP in reset
 2. Enable clock
 3. Delay
 4. Release reset

There are some gates that do not have an associated reset; these are
handled by using -1 as the index for the reset.

Signed-off-by: Joel Stanley 
---
 drivers/clk/clk-aspeed.c | 128 +++
 1 file changed, 128 insertions(+)

diff --git a/drivers/clk/clk-aspeed.c b/drivers/clk/clk-aspeed.c
index 19531798e040..dec9db4ec47b 100644
--- a/drivers/clk/clk-aspeed.c
+++ b/drivers/clk/clk-aspeed.c
@@ -191,6 +191,108 @@ static struct clk_hw *aspeed_calc_pll(const char *name, 
u32 val)
mult, div);
 }
 
+static int aspeed_clk_enable(struct clk_hw *hw)
+{
+   struct aspeed_clk_gate *gate = to_aspeed_clk_gate(hw);
+   unsigned long flags;
+   u32 clk = BIT(gate->clock_idx);
+   u32 rst = BIT(gate->reset_idx);
+
+   spin_lock_irqsave(gate->lock, flags);
+
+   if (gate->reset_idx >= 0) {
+   /* Put IP in reset */
+   regmap_update_bits(gate->map, ASPEED_RESET_CTRL, rst, rst);
+
+   /* Delay 100us */
+   udelay(100);
+   }
+
+   /* Enable clock */
+   regmap_update_bits(gate->map, ASPEED_CLK_STOP_CTRL, clk, 0);
+
+   if (gate->reset_idx >= 0) {
+   /* Delay 10ms */
+   /* TODO: can we sleep here? */
+   msleep(10);
+
+   /* Take IP out of reset */
+   regmap_update_bits(gate->map, ASPEED_RESET_CTRL, rst, 0);
+   }
+
+   spin_unlock_irqrestore(gate->lock, flags);
+
+   return 0;
+}
+
+static void aspeed_clk_disable(struct clk_hw *hw)
+{
+   struct aspeed_clk_gate *gate = to_aspeed_clk_gate(hw);
+   unsigned long flags;
+   u32 clk = BIT(gate->clock_idx);
+
+   spin_lock_irqsave(gate->lock, flags);
+
+   /* Disable clock */
+   regmap_update_bits(gate->map, ASPEED_CLK_STOP_CTRL, clk, clk);
+
+   spin_unlock_irqrestore(gate->lock, flags);
+}
+
+static int aspeed_clk_is_enabled(struct clk_hw *hw)
+{
+   struct aspeed_clk_gate *gate = to_aspeed_clk_gate(hw);
+   u32 clk = BIT(gate->clock_idx);
+   u32 reg;
+
+   regmap_read(gate->map, ASPEED_CLK_STOP_CTRL, );
+
+   return (reg & clk) ? 0 : 1;
+}
+
+static const struct clk_ops aspeed_clk_gate_ops = {
+   .enable = aspeed_clk_enable,
+   .disable = aspeed_clk_disable,
+   .is_enabled = aspeed_clk_is_enabled,
+};
+
+static struct clk_hw *aspeed_clk_hw_register_gate(struct device *dev,
+   const char *name, const char *parent_name, unsigned long flags,
+   struct regmap *map, u8 clock_idx, u8 reset_idx,
+   u8 clk_gate_flags, spinlock_t *lock)
+{
+   struct aspeed_clk_gate *gate;
+   struct clk_init_data init;
+   struct clk_hw *hw;
+   int ret;
+
+   gate = kzalloc(sizeof(*gate), GFP_KERNEL);
+   if (!gate)
+   return ERR_PTR(-ENOMEM);
+
+   init.name = name;
+   init.ops = _clk_gate_ops;
+   init.flags = flags | CLK_IS_BASIC;
+   init.parent_names = parent_name ? _name : NULL;
+   init.num_parents = parent_name ? 1 : 0;
+
+   gate->map = map;
+   gate->clock_idx = clock_idx;
+   gate->reset_idx = reset_idx;
+   gate->flags = clk_gate_flags;
+   gate->lock = lock;
+   gate->hw.init = 
+
+   hw = >hw;
+   ret = clk_hw_register(dev, hw);
+   if (ret) {
+   kfree(gate);
+   hw = ERR_PTR(ret);
+   }
+
+   return hw;
+}
+
 static int __init aspeed_clk_probe(struct platform_device *pdev)
 {
const struct aspeed_clk_soc_data *soc_data;
@@ -200,6 +302,7 @@ static int __init aspeed_clk_probe(struct platform_device 
*pdev)
struct regmap *map;
struct clk_hw *hw;
u32 val, rate;
+   int i;
 
map = syscon_node_to_regmap(dev->of_node);
if (IS_ERR(map)) {
@@ -269,6 +372,31 @@ static int __init aspeed_clk_probe(struct platform_device 
*pdev)
_clk_lock);
aspeed_clk_data->hws[ASPEED_CLK_BCLK] = hw;
 
+   /* There are a number of clocks that not included in this driver as
+* more information is required:
+*   D2-PLL
+*   D-PLL
+*   YCLK
+*   RGMII
+*   RMII
+*   UART[1..5] clock source mux
+*/
+
+   for (i = 0; i < ARRAY_SIZE(aspeed_gates); i++) {
+   const struct aspeed_gate_data *gd;
+
+   gd = _gates[i];
+   aspeed_clk_data->hws[ASPEED_CLK_GATES + i] =
+   aspeed_clk_hw_register_gate(NULL, gd->name,
+gd->parent_name,
+

[PATCH v2 3/5] clk: aspeed: Add platform driver and register PLLs

[Joel Stanley]

This registers a platform driver to set up all of the non-core clocks.

The clocks that have configurable rates are now registered.

Signed-off-by: Joel Stanley 
---
 drivers/clk/clk-aspeed.c | 129 +++
 1 file changed, 129 insertions(+)

diff --git a/drivers/clk/clk-aspeed.c b/drivers/clk/clk-aspeed.c
index e614c61b82d2..19531798e040 100644
--- a/drivers/clk/clk-aspeed.c
+++ b/drivers/clk/clk-aspeed.c
@@ -14,6 +14,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -115,6 +117,20 @@ static const struct aspeed_gate_data aspeed_gates[] 
__initconst = {
/* 31: reserved */
 };
 
+static const char * const eclk_parents[] = {"d1pll", "hpll", "mpll"};
+
+static const struct clk_div_table ast2500_mac_div_table[] = {
+   { 0x0, 4 }, /* Yep, really. Aspeed confirmed this is correct */
+   { 0x1, 4 },
+   { 0x2, 6 },
+   { 0x3, 8 },
+   { 0x4, 10 },
+   { 0x5, 12 },
+   { 0x6, 14 },
+   { 0x7, 16 },
+   { 0 }
+};
+
 static const struct clk_div_table ast2400_div_table[] = {
{ 0x0, 2 },
{ 0x1, 4 },
@@ -139,6 +155,21 @@ static const struct clk_div_table ast2500_div_table[] = {
{ 0 }
 };
 
+struct aspeed_clk_soc_data {
+   const struct clk_div_table *div_table;
+   const struct clk_div_table *mac_div_table;
+};
+
+static const struct aspeed_clk_soc_data ast2500_data = {
+   .div_table = ast2500_div_table,
+   .mac_div_table = ast2500_mac_div_table,
+};
+
+static const struct aspeed_clk_soc_data ast2400_data = {
+   .div_table = ast2400_div_table,
+   .mac_div_table = ast2400_div_table,
+};
+
 static struct clk_hw *aspeed_calc_pll(const char *name, u32 val)
 {
unsigned int mult, div;
@@ -160,6 +191,104 @@ static struct clk_hw *aspeed_calc_pll(const char *name, 
u32 val)
mult, div);
 }
 
+static int __init aspeed_clk_probe(struct platform_device *pdev)
+{
+   const struct aspeed_clk_soc_data *soc_data;
+   const struct clk_div_table *mac_div_table;
+   const struct clk_div_table *div_table;
+   struct device *dev = >dev;
+   struct regmap *map;
+   struct clk_hw *hw;
+   u32 val, rate;
+
+   map = syscon_node_to_regmap(dev->of_node);
+   if (IS_ERR(map)) {
+   dev_err(dev, "no syscon regmap\n");
+   return PTR_ERR(map);
+   }
+
+   /* SoC generations share common layouts but have different divisors */
+   soc_data = of_device_get_match_data(>dev);
+   div_table = soc_data->div_table;
+   mac_div_table = soc_data->mac_div_table;
+
+   /* UART clock div13 setting */
+   regmap_read(map, ASPEED_MISC_CTRL, );
+   if (val & BIT(12))
+   rate = 2400 / 13;
+   else
+   rate = 2400;
+   /* TODO: Find the parent data for the uart clock */
+   hw = clk_hw_register_fixed_rate(NULL, "uart", NULL, 0, rate);
+   aspeed_clk_data->hws[ASPEED_CLK_UART] = hw;
+
+   /*
+* Memory controller (M-PLL) PLL. This clock is configured by the
+* bootloader, and is exposed to Linux as a read-only clock rate.
+*/
+   regmap_read(map, ASPEED_MPLL_PARAM, );
+   aspeed_clk_data->hws[ASPEED_CLK_MPLL] = aspeed_calc_pll("mpll", val);
+
+   /* SD/SDIO clock divider (TODO: There's a gate too) */
+   hw = clk_hw_register_divider_table(NULL, "sdio", "hpll", 0,
+   scu_base + ASPEED_CLK_SELECTION, 12, 3, 0,
+   div_table,
+   _clk_lock);
+   aspeed_clk_data->hws[ASPEED_CLK_SDIO] = hw;
+
+   /* MAC AHB bus clock divider */
+   hw = clk_hw_register_divider_table(NULL, "mac", "hpll", 0,
+   scu_base + ASPEED_CLK_SELECTION, 16, 3, 0,
+   mac_div_table,
+   _clk_lock);
+   aspeed_clk_data->hws[ASPEED_CLK_MAC] = hw;
+
+   /* LPC Host (LHCLK) clock divider */
+   hw = clk_hw_register_divider_table(NULL, "lhclk", "hpll", 0,
+   scu_base + ASPEED_CLK_SELECTION, 20, 3, 0,
+   div_table,
+   _clk_lock);
+   aspeed_clk_data->hws[ASPEED_CLK_LHCLK] = hw;
+
+   /* Video Engine (ECLK) mux and clock divider */
+   hw = clk_hw_register_mux(NULL, "eclk_mux",
+   eclk_parents, ARRAY_SIZE(eclk_parents), 0,
+   scu_base + ASPEED_CLK_SELECTION, 2, 2,
+   0, _clk_lock);
+   aspeed_clk_data->hws[ASPEED_CLK_ECLK_MUX] = hw;
+   hw = clk_hw_register_divider_table(NULL, "eclk", "eclk_mux", 0,
+   scu_base + ASPEED_CLK_SELECTION, 20, 3, 0,
+   div_table,
+   _clk_lock);
+   aspeed_clk_data->hws[ASPEED_CLK_ECLK] = hw;
+
+   /* P-Bus (BCLK) clock divider */
+   hw = clk_hw_register_divider_table(NULL, "bclk", "hpll", 0,
+

[PATCH v2 5/5] clk: aspeed: Add reset controller

[Joel Stanley]

There are some resets that are not associated with gates. These are
represented by a reset controller.

Signed-off-by: Joel Stanley 
---
 drivers/clk/clk-aspeed.c | 82 +++-
 include/dt-bindings/clock/aspeed-clock.h |  9 
 2 files changed, 90 insertions(+), 1 deletion(-)

diff --git a/drivers/clk/clk-aspeed.c b/drivers/clk/clk-aspeed.c
index dec9db4ec47b..db97c0f9f99e 100644
--- a/drivers/clk/clk-aspeed.c
+++ b/drivers/clk/clk-aspeed.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -256,6 +257,68 @@ static const struct clk_ops aspeed_clk_gate_ops = {
.is_enabled = aspeed_clk_is_enabled,
 };
 
+/**
+ * struct aspeed_reset - Aspeed reset controller
+ * @map: regmap to access the containing system controller
+ * @rcdev: reset controller device
+ */
+struct aspeed_reset {
+   struct regmap   *map;
+   struct reset_controller_dev rcdev;
+};
+
+#define to_aspeed_reset(p) container_of((p), struct aspeed_reset, rcdev)
+
+static const u8 aspeed_resets[] = {
+   25, /* x-dma */
+   24, /* mctp */
+   23, /* adc */
+   22, /* jtag-master */
+   18, /* mic */
+9, /* pwm */
+8, /* pci-vga */
+2, /* i2c */
+1, /* ahb */
+};
+
+static int aspeed_reset_deassert(struct reset_controller_dev *rcdev,
+unsigned long id)
+{
+   struct aspeed_reset *ar = to_aspeed_reset(rcdev);
+   u32 rst = BIT(aspeed_resets[id]);
+
+   return regmap_update_bits(ar->map, ASPEED_RESET_CTRL, rst, 0);
+}
+
+static int aspeed_reset_assert(struct reset_controller_dev *rcdev,
+  unsigned long id)
+{
+   struct aspeed_reset *ar = to_aspeed_reset(rcdev);
+   u32 rst = BIT(aspeed_resets[id]);
+
+   return regmap_update_bits(ar->map, ASPEED_RESET_CTRL, rst, rst);
+}
+
+static int aspeed_reset_status(struct reset_controller_dev *rcdev,
+  unsigned long id)
+{
+   struct aspeed_reset *ar = to_aspeed_reset(rcdev);
+   u32 val, rst = BIT(aspeed_resets[id]);
+   int ret;
+
+   ret = regmap_read(ar->map, ASPEED_RESET_CTRL, );
+   if (ret)
+   return ret;
+
+   return !!(val & rst);
+}
+
+static const struct reset_control_ops aspeed_reset_ops = {
+   .assert = aspeed_reset_assert,
+   .deassert = aspeed_reset_deassert,
+   .status = aspeed_reset_status,
+};
+
 static struct clk_hw *aspeed_clk_hw_register_gate(struct device *dev,
const char *name, const char *parent_name, unsigned long flags,
struct regmap *map, u8 clock_idx, u8 reset_idx,
@@ -299,10 +362,11 @@ static int __init aspeed_clk_probe(struct platform_device 
*pdev)
const struct clk_div_table *mac_div_table;
const struct clk_div_table *div_table;
struct device *dev = >dev;
+   struct aspeed_reset *ar;
struct regmap *map;
struct clk_hw *hw;
u32 val, rate;
-   int i;
+   int i, ret;
 
map = syscon_node_to_regmap(dev->of_node);
if (IS_ERR(map)) {
@@ -310,6 +374,22 @@ static int __init aspeed_clk_probe(struct platform_device 
*pdev)
return PTR_ERR(map);
}
 
+   ar = devm_kzalloc(dev, sizeof(*ar), GFP_KERNEL);
+   if (!ar)
+   return -ENOMEM;
+
+   ar->map = map;
+   ar->rcdev.owner = THIS_MODULE;
+   ar->rcdev.nr_resets = ARRAY_SIZE(aspeed_resets);
+   ar->rcdev.ops = _reset_ops;
+   ar->rcdev.of_node = dev->of_node;
+
+   ret = devm_reset_controller_register(dev, >rcdev);
+   if (ret) {
+   dev_err(dev, "could not register reset controller\n");
+   return ret;
+   }
+
/* SoC generations share common layouts but have different divisors */
soc_data = of_device_get_match_data(>dev);
div_table = soc_data->div_table;
diff --git a/include/dt-bindings/clock/aspeed-clock.h 
b/include/dt-bindings/clock/aspeed-clock.h
index afe06b77562d..a9d552b6bbd2 100644
--- a/include/dt-bindings/clock/aspeed-clock.h
+++ b/include/dt-bindings/clock/aspeed-clock.h
@@ -40,4 +40,13 @@
 #define ASPEED_CLK_GATE_SDCLKCLK   (22 + ASPEED_CLK_GATES)
 #define ASPEED_CLK_GATE_LHCCLK (23 + ASPEED_CLK_GATES)
 
+#define ASPEED_RESET_XDMA  0
+#define ASPEED_RESET_MCTP  1
+#define ASPEED_RESET_JTAG_MASTER   2
+#define ASPEED_RESET_MIC   3
+#define ASPEED_RESET_PWM   4
+#define ASPEED_RESET_PCIVGA5
+#define ASPEED_RESET_I2C   6
+#define ASPEED_RESET_AHB   7
+
 #endif
-- 
2.14.1

[PATCH v2 4/5] clk: aspeed: Register gated clocks

[Joel Stanley]

The majority of the clocks in the system are gates paired with a reset
controller that holds the IP in reset.

This borrows from clk_hw_register_gate, but registers two 'gates', one
to control the clock enable register and the other to control the reset
IP. This allows us to enforce the ordering:

 1. Place IP in reset
 2. Enable clock
 3. Delay
 4. Release reset

There are some gates that do not have an associated reset; these are
handled by using -1 as the index for the reset.

Signed-off-by: Joel Stanley 
---
 drivers/clk/clk-aspeed.c | 128 +++
 1 file changed, 128 insertions(+)

diff --git a/drivers/clk/clk-aspeed.c b/drivers/clk/clk-aspeed.c
index 19531798e040..dec9db4ec47b 100644
--- a/drivers/clk/clk-aspeed.c
+++ b/drivers/clk/clk-aspeed.c
@@ -191,6 +191,108 @@ static struct clk_hw *aspeed_calc_pll(const char *name, 
u32 val)
mult, div);
 }
 
+static int aspeed_clk_enable(struct clk_hw *hw)
+{
+   struct aspeed_clk_gate *gate = to_aspeed_clk_gate(hw);
+   unsigned long flags;
+   u32 clk = BIT(gate->clock_idx);
+   u32 rst = BIT(gate->reset_idx);
+
+   spin_lock_irqsave(gate->lock, flags);
+
+   if (gate->reset_idx >= 0) {
+   /* Put IP in reset */
+   regmap_update_bits(gate->map, ASPEED_RESET_CTRL, rst, rst);
+
+   /* Delay 100us */
+   udelay(100);
+   }
+
+   /* Enable clock */
+   regmap_update_bits(gate->map, ASPEED_CLK_STOP_CTRL, clk, 0);
+
+   if (gate->reset_idx >= 0) {
+   /* Delay 10ms */
+   /* TODO: can we sleep here? */
+   msleep(10);
+
+   /* Take IP out of reset */
+   regmap_update_bits(gate->map, ASPEED_RESET_CTRL, rst, 0);
+   }
+
+   spin_unlock_irqrestore(gate->lock, flags);
+
+   return 0;
+}
+
+static void aspeed_clk_disable(struct clk_hw *hw)
+{
+   struct aspeed_clk_gate *gate = to_aspeed_clk_gate(hw);
+   unsigned long flags;
+   u32 clk = BIT(gate->clock_idx);
+
+   spin_lock_irqsave(gate->lock, flags);
+
+   /* Disable clock */
+   regmap_update_bits(gate->map, ASPEED_CLK_STOP_CTRL, clk, clk);
+
+   spin_unlock_irqrestore(gate->lock, flags);
+}
+
+static int aspeed_clk_is_enabled(struct clk_hw *hw)
+{
+   struct aspeed_clk_gate *gate = to_aspeed_clk_gate(hw);
+   u32 clk = BIT(gate->clock_idx);
+   u32 reg;
+
+   regmap_read(gate->map, ASPEED_CLK_STOP_CTRL, );
+
+   return (reg & clk) ? 0 : 1;
+}
+
+static const struct clk_ops aspeed_clk_gate_ops = {
+   .enable = aspeed_clk_enable,
+   .disable = aspeed_clk_disable,
+   .is_enabled = aspeed_clk_is_enabled,
+};
+
+static struct clk_hw *aspeed_clk_hw_register_gate(struct device *dev,
+   const char *name, const char *parent_name, unsigned long flags,
+   struct regmap *map, u8 clock_idx, u8 reset_idx,
+   u8 clk_gate_flags, spinlock_t *lock)
+{
+   struct aspeed_clk_gate *gate;
+   struct clk_init_data init;
+   struct clk_hw *hw;
+   int ret;
+
+   gate = kzalloc(sizeof(*gate), GFP_KERNEL);
+   if (!gate)
+   return ERR_PTR(-ENOMEM);
+
+   init.name = name;
+   init.ops = _clk_gate_ops;
+   init.flags = flags | CLK_IS_BASIC;
+   init.parent_names = parent_name ? _name : NULL;
+   init.num_parents = parent_name ? 1 : 0;
+
+   gate->map = map;
+   gate->clock_idx = clock_idx;
+   gate->reset_idx = reset_idx;
+   gate->flags = clk_gate_flags;
+   gate->lock = lock;
+   gate->hw.init = 
+
+   hw = >hw;
+   ret = clk_hw_register(dev, hw);
+   if (ret) {
+   kfree(gate);
+   hw = ERR_PTR(ret);
+   }
+
+   return hw;
+}
+
 static int __init aspeed_clk_probe(struct platform_device *pdev)
 {
const struct aspeed_clk_soc_data *soc_data;
@@ -200,6 +302,7 @@ static int __init aspeed_clk_probe(struct platform_device 
*pdev)
struct regmap *map;
struct clk_hw *hw;
u32 val, rate;
+   int i;
 
map = syscon_node_to_regmap(dev->of_node);
if (IS_ERR(map)) {
@@ -269,6 +372,31 @@ static int __init aspeed_clk_probe(struct platform_device 
*pdev)
_clk_lock);
aspeed_clk_data->hws[ASPEED_CLK_BCLK] = hw;
 
+   /* There are a number of clocks that not included in this driver as
+* more information is required:
+*   D2-PLL
+*   D-PLL
+*   YCLK
+*   RGMII
+*   RMII
+*   UART[1..5] clock source mux
+*/
+
+   for (i = 0; i < ARRAY_SIZE(aspeed_gates); i++) {
+   const struct aspeed_gate_data *gd;
+
+   gd = _gates[i];
+   aspeed_clk_data->hws[ASPEED_CLK_GATES + i] =
+   aspeed_clk_hw_register_gate(NULL, gd->name,
+gd->parent_name,
+

[PATCH v2 3/5] clk: aspeed: Add platform driver and register PLLs

[Joel Stanley]

This registers a platform driver to set up all of the non-core clocks.

The clocks that have configurable rates are now registered.

Signed-off-by: Joel Stanley 
---
 drivers/clk/clk-aspeed.c | 129 +++
 1 file changed, 129 insertions(+)

diff --git a/drivers/clk/clk-aspeed.c b/drivers/clk/clk-aspeed.c
index e614c61b82d2..19531798e040 100644
--- a/drivers/clk/clk-aspeed.c
+++ b/drivers/clk/clk-aspeed.c
@@ -14,6 +14,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 #include 
 #include 
@@ -115,6 +117,20 @@ static const struct aspeed_gate_data aspeed_gates[] 
__initconst = {
/* 31: reserved */
 };
 
+static const char * const eclk_parents[] = {"d1pll", "hpll", "mpll"};
+
+static const struct clk_div_table ast2500_mac_div_table[] = {
+   { 0x0, 4 }, /* Yep, really. Aspeed confirmed this is correct */
+   { 0x1, 4 },
+   { 0x2, 6 },
+   { 0x3, 8 },
+   { 0x4, 10 },
+   { 0x5, 12 },
+   { 0x6, 14 },
+   { 0x7, 16 },
+   { 0 }
+};
+
 static const struct clk_div_table ast2400_div_table[] = {
{ 0x0, 2 },
{ 0x1, 4 },
@@ -139,6 +155,21 @@ static const struct clk_div_table ast2500_div_table[] = {
{ 0 }
 };
 
+struct aspeed_clk_soc_data {
+   const struct clk_div_table *div_table;
+   const struct clk_div_table *mac_div_table;
+};
+
+static const struct aspeed_clk_soc_data ast2500_data = {
+   .div_table = ast2500_div_table,
+   .mac_div_table = ast2500_mac_div_table,
+};
+
+static const struct aspeed_clk_soc_data ast2400_data = {
+   .div_table = ast2400_div_table,
+   .mac_div_table = ast2400_div_table,
+};
+
 static struct clk_hw *aspeed_calc_pll(const char *name, u32 val)
 {
unsigned int mult, div;
@@ -160,6 +191,104 @@ static struct clk_hw *aspeed_calc_pll(const char *name, 
u32 val)
mult, div);
 }
 
+static int __init aspeed_clk_probe(struct platform_device *pdev)
+{
+   const struct aspeed_clk_soc_data *soc_data;
+   const struct clk_div_table *mac_div_table;
+   const struct clk_div_table *div_table;
+   struct device *dev = >dev;
+   struct regmap *map;
+   struct clk_hw *hw;
+   u32 val, rate;
+
+   map = syscon_node_to_regmap(dev->of_node);
+   if (IS_ERR(map)) {
+   dev_err(dev, "no syscon regmap\n");
+   return PTR_ERR(map);
+   }
+
+   /* SoC generations share common layouts but have different divisors */
+   soc_data = of_device_get_match_data(>dev);
+   div_table = soc_data->div_table;
+   mac_div_table = soc_data->mac_div_table;
+
+   /* UART clock div13 setting */
+   regmap_read(map, ASPEED_MISC_CTRL, );
+   if (val & BIT(12))
+   rate = 2400 / 13;
+   else
+   rate = 2400;
+   /* TODO: Find the parent data for the uart clock */
+   hw = clk_hw_register_fixed_rate(NULL, "uart", NULL, 0, rate);
+   aspeed_clk_data->hws[ASPEED_CLK_UART] = hw;
+
+   /*
+* Memory controller (M-PLL) PLL. This clock is configured by the
+* bootloader, and is exposed to Linux as a read-only clock rate.
+*/
+   regmap_read(map, ASPEED_MPLL_PARAM, );
+   aspeed_clk_data->hws[ASPEED_CLK_MPLL] = aspeed_calc_pll("mpll", val);
+
+   /* SD/SDIO clock divider (TODO: There's a gate too) */
+   hw = clk_hw_register_divider_table(NULL, "sdio", "hpll", 0,
+   scu_base + ASPEED_CLK_SELECTION, 12, 3, 0,
+   div_table,
+   _clk_lock);
+   aspeed_clk_data->hws[ASPEED_CLK_SDIO] = hw;
+
+   /* MAC AHB bus clock divider */
+   hw = clk_hw_register_divider_table(NULL, "mac", "hpll", 0,
+   scu_base + ASPEED_CLK_SELECTION, 16, 3, 0,
+   mac_div_table,
+   _clk_lock);
+   aspeed_clk_data->hws[ASPEED_CLK_MAC] = hw;
+
+   /* LPC Host (LHCLK) clock divider */
+   hw = clk_hw_register_divider_table(NULL, "lhclk", "hpll", 0,
+   scu_base + ASPEED_CLK_SELECTION, 20, 3, 0,
+   div_table,
+   _clk_lock);
+   aspeed_clk_data->hws[ASPEED_CLK_LHCLK] = hw;
+
+   /* Video Engine (ECLK) mux and clock divider */
+   hw = clk_hw_register_mux(NULL, "eclk_mux",
+   eclk_parents, ARRAY_SIZE(eclk_parents), 0,
+   scu_base + ASPEED_CLK_SELECTION, 2, 2,
+   0, _clk_lock);
+   aspeed_clk_data->hws[ASPEED_CLK_ECLK_MUX] = hw;
+   hw = clk_hw_register_divider_table(NULL, "eclk", "eclk_mux", 0,
+   scu_base + ASPEED_CLK_SELECTION, 20, 3, 0,
+   div_table,
+   _clk_lock);
+   aspeed_clk_data->hws[ASPEED_CLK_ECLK] = hw;
+
+   /* P-Bus (BCLK) clock divider */
+   hw = clk_hw_register_divider_table(NULL, "bclk", "hpll", 0,
+   scu_base + 

[PATCH v2 1/5] clk: Add clock driver for ASPEED BMC SoCs

[Joel Stanley]

This adds the stub of a driver for the ASPEED SoCs. The clocks are
defined and the static registration is set up.

Signed-off-by: Joel Stanley 
---
 drivers/clk/Kconfig  |  12 +++
 drivers/clk/Makefile |   1 +
 drivers/clk/clk-aspeed.c | 162 +++
 include/dt-bindings/clock/aspeed-clock.h |  43 
 4 files changed, 218 insertions(+)
 create mode 100644 drivers/clk/clk-aspeed.c
 create mode 100644 include/dt-bindings/clock/aspeed-clock.h

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 1c4e1aa6767e..9abe063ef8d2 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -142,6 +142,18 @@ config COMMON_CLK_GEMINI
  This driver supports the SoC clocks on the Cortina Systems Gemini
  platform, also known as SL3516 or CS3516.
 
+config COMMON_CLK_ASPEED
+   bool "Clock driver for Aspeed BMC SoCs"
+   depends on ARCH_ASPEED || COMPILE_TEST
+   default ARCH_ASPEED
+   select MFD_SYSCON
+   select RESET_CONTROLLER
+   ---help---
+ This driver supports the SoC clocks on the Aspeed BMC platforms.
+
+ The G4 and G5 series, including the ast2400 and ast2500, are supported
+ by this driver.
+
 config COMMON_CLK_S2MPS11
tristate "Clock driver for S2MPS1X/S5M8767 MFD"
depends on MFD_SEC_CORE || COMPILE_TEST
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index c99f363826f0..575c68919d9b 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_ARCH_CLPS711X)   += clk-clps711x.o
 obj-$(CONFIG_COMMON_CLK_CS2000_CP) += clk-cs2000-cp.o
 obj-$(CONFIG_ARCH_EFM32)   += clk-efm32gg.o
 obj-$(CONFIG_COMMON_CLK_GEMINI)+= clk-gemini.o
+obj-$(CONFIG_COMMON_CLK_ASPEED)+= clk-aspeed.o
 obj-$(CONFIG_ARCH_HIGHBANK)+= clk-highbank.o
 obj-$(CONFIG_CLK_HSDK) += clk-hsdk-pll.o
 obj-$(CONFIG_COMMON_CLK_MAX77686)  += clk-max77686.o
diff --git a/drivers/clk/clk-aspeed.c b/drivers/clk/clk-aspeed.c
new file mode 100644
index ..824c54767009
--- /dev/null
+++ b/drivers/clk/clk-aspeed.c
@@ -0,0 +1,162 @@
+/*
+ * Copyright 2017 IBM Corporation
+ *
+ * Joel Stanley 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#define pr_fmt(fmt) "clk-aspeed: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define ASPEED_RESET_CTRL  0x04
+#define ASPEED_CLK_SELECTION   0x08
+#define ASPEED_CLK_STOP_CTRL   0x0c
+#define ASPEED_MPLL_PARAM  0x20
+#define ASPEED_HPLL_PARAM  0x24
+#define ASPEED_MISC_CTRL   0x2c
+#define ASPEED_STRAP   0x70
+
+/* Keeps track of all clocks */
+static struct clk_hw_onecell_data *aspeed_clk_data;
+
+static void __iomem *scu_base;
+
+/**
+ * struct aspeed_gate_data - Aspeed gated clocks
+ * @clock_idx: bit used to gate this clock in the clock register
+ * @reset_idx: bit used to reset this IP in the reset register. -1 if no
+ * reset is required when enabling the clock
+ * @name: the clock name
+ * @parent_name: the name of the parent clock
+ * @flags: standard clock framework flags
+ */
+struct aspeed_gate_data {
+   u8  clock_idx;
+   s8  reset_idx;
+   const char  *name;
+   const char  *parent_name;
+   unsigned long   flags;
+};
+
+/**
+ * struct aspeed_clk_gate - Aspeed specific clk_gate structure
+ * @hw:handle between common and hardware-specific interfaces
+ * @reg:   register controlling gate
+ * @clock_idx: bit used to gate this clock in the clock register
+ * @reset_idx: bit used to reset this IP in the reset register. -1 if no
+ * reset is required when enabling the clock
+ * @flags: hardware-specific flags
+ * @lock:  register lock
+ *
+ * Some of the clocks in the Aspeed SoC must be put in reset before enabling.
+ * This modified version of clk_gate allows an optional reset bit to be
+ * specified.
+ */
+struct aspeed_clk_gate {
+   struct clk_hw   hw;
+   struct regmap   *map;
+   u8  clock_idx;
+   s8  reset_idx;
+   u8  flags;
+   spinlock_t  *lock;
+};
+
+#define to_aspeed_clk_gate(_hw) container_of(_hw, struct aspeed_clk_gate, hw)
+
+/* TODO: ask Aspeed about the actual parent data */
+static const struct aspeed_gate_data aspeed_gates[] __initconst = {
+/*  clk rst   name parent  flags   */
+   {  0, -1, "eclk-gate",  "eclk", 0 }, /* Video Engine */
+   {  1,  7, "gclk-gate",  NULL,   0 }, /* 2D engine */
+   {  2, -1, "mclk-gate",  "mpll", 

[PATCH v2 1/5] clk: Add clock driver for ASPEED BMC SoCs

[Joel Stanley]

This adds the stub of a driver for the ASPEED SoCs. The clocks are
defined and the static registration is set up.

Signed-off-by: Joel Stanley 
---
 drivers/clk/Kconfig  |  12 +++
 drivers/clk/Makefile |   1 +
 drivers/clk/clk-aspeed.c | 162 +++
 include/dt-bindings/clock/aspeed-clock.h |  43 
 4 files changed, 218 insertions(+)
 create mode 100644 drivers/clk/clk-aspeed.c
 create mode 100644 include/dt-bindings/clock/aspeed-clock.h

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 1c4e1aa6767e..9abe063ef8d2 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -142,6 +142,18 @@ config COMMON_CLK_GEMINI
  This driver supports the SoC clocks on the Cortina Systems Gemini
  platform, also known as SL3516 or CS3516.
 
+config COMMON_CLK_ASPEED
+   bool "Clock driver for Aspeed BMC SoCs"
+   depends on ARCH_ASPEED || COMPILE_TEST
+   default ARCH_ASPEED
+   select MFD_SYSCON
+   select RESET_CONTROLLER
+   ---help---
+ This driver supports the SoC clocks on the Aspeed BMC platforms.
+
+ The G4 and G5 series, including the ast2400 and ast2500, are supported
+ by this driver.
+
 config COMMON_CLK_S2MPS11
tristate "Clock driver for S2MPS1X/S5M8767 MFD"
depends on MFD_SEC_CORE || COMPILE_TEST
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index c99f363826f0..575c68919d9b 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -26,6 +26,7 @@ obj-$(CONFIG_ARCH_CLPS711X)   += clk-clps711x.o
 obj-$(CONFIG_COMMON_CLK_CS2000_CP) += clk-cs2000-cp.o
 obj-$(CONFIG_ARCH_EFM32)   += clk-efm32gg.o
 obj-$(CONFIG_COMMON_CLK_GEMINI)+= clk-gemini.o
+obj-$(CONFIG_COMMON_CLK_ASPEED)+= clk-aspeed.o
 obj-$(CONFIG_ARCH_HIGHBANK)+= clk-highbank.o
 obj-$(CONFIG_CLK_HSDK) += clk-hsdk-pll.o
 obj-$(CONFIG_COMMON_CLK_MAX77686)  += clk-max77686.o
diff --git a/drivers/clk/clk-aspeed.c b/drivers/clk/clk-aspeed.c
new file mode 100644
index ..824c54767009
--- /dev/null
+++ b/drivers/clk/clk-aspeed.c
@@ -0,0 +1,162 @@
+/*
+ * Copyright 2017 IBM Corporation
+ *
+ * Joel Stanley 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#define pr_fmt(fmt) "clk-aspeed: " fmt
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+
+#define ASPEED_RESET_CTRL  0x04
+#define ASPEED_CLK_SELECTION   0x08
+#define ASPEED_CLK_STOP_CTRL   0x0c
+#define ASPEED_MPLL_PARAM  0x20
+#define ASPEED_HPLL_PARAM  0x24
+#define ASPEED_MISC_CTRL   0x2c
+#define ASPEED_STRAP   0x70
+
+/* Keeps track of all clocks */
+static struct clk_hw_onecell_data *aspeed_clk_data;
+
+static void __iomem *scu_base;
+
+/**
+ * struct aspeed_gate_data - Aspeed gated clocks
+ * @clock_idx: bit used to gate this clock in the clock register
+ * @reset_idx: bit used to reset this IP in the reset register. -1 if no
+ * reset is required when enabling the clock
+ * @name: the clock name
+ * @parent_name: the name of the parent clock
+ * @flags: standard clock framework flags
+ */
+struct aspeed_gate_data {
+   u8  clock_idx;
+   s8  reset_idx;
+   const char  *name;
+   const char  *parent_name;
+   unsigned long   flags;
+};
+
+/**
+ * struct aspeed_clk_gate - Aspeed specific clk_gate structure
+ * @hw:handle between common and hardware-specific interfaces
+ * @reg:   register controlling gate
+ * @clock_idx: bit used to gate this clock in the clock register
+ * @reset_idx: bit used to reset this IP in the reset register. -1 if no
+ * reset is required when enabling the clock
+ * @flags: hardware-specific flags
+ * @lock:  register lock
+ *
+ * Some of the clocks in the Aspeed SoC must be put in reset before enabling.
+ * This modified version of clk_gate allows an optional reset bit to be
+ * specified.
+ */
+struct aspeed_clk_gate {
+   struct clk_hw   hw;
+   struct regmap   *map;
+   u8  clock_idx;
+   s8  reset_idx;
+   u8  flags;
+   spinlock_t  *lock;
+};
+
+#define to_aspeed_clk_gate(_hw) container_of(_hw, struct aspeed_clk_gate, hw)
+
+/* TODO: ask Aspeed about the actual parent data */
+static const struct aspeed_gate_data aspeed_gates[] __initconst = {
+/*  clk rst   name parent  flags   */
+   {  0, -1, "eclk-gate",  "eclk", 0 }, /* Video Engine */
+   {  1,  7, "gclk-gate",  NULL,   0 }, /* 2D engine */
+   {  2, -1, "mclk-gate",  "mpll", CLK_IS_CRITICAL }, /* 

[PATCH v2 0/5] clk: Add Aspeed clock driver

[Joel Stanley]

This driver supports the ast2500, ast2400 (and derivative) BMC SoCs from
Aspeed.

This is version two of the series. Version one contained two patches; an update
to the binding document and a single patch for the driver. Lee has merged the
bindings change, so that is dropped from this series, and I split the driver
out into a series of patches to make them easier to review.

All of the important clocks are supported, with most non-essential ones
also implemented where information is available. I am working with
Aspeed to clear up some of the missing information, including the
missing parent-sibling relationships.

We need to know the rate of the apb clock in order to correctly program
the clocksource driver, so the apb and it's parents are created in the
CLK_OF_DECLARE_DRIVER callback.

The rest of the clocks are created at normal driver probe time. I
followed the Gemini driver's lead with using the regmap where I could,
but also having a pointer to the base address for use with the common
clock callbacks.

The driver borrows from the clk_gate common clock infra spruce, but modifies
it in order to support the clock gate and reset pair that most of the clocks
have. This pair must be reset-ungated-released, with appropriate delays,
according to the datasheet.

The first patch introduces the core clock registration parts, and describes
the clocks. The second creates the core clocks, giving the system enough to
boot (but without uart). Next come the non-core clocks, and finally the reset
controller that is used for the few cocks that don't have a gate to go with 
their
reset pair.

Please review!

Cheers,

Joel


Joel Stanley (5):
  clk: Add clock driver for ASPEED BMC SoCs
  clk: aspeed: Register core clocks
  clk: aspeed: Add platform driver and register PLLs
  clk: aspeed: Register gated clocks
  clk: aspeed: Add reset controller

 drivers/clk/Kconfig  |  12 +
 drivers/clk/Makefile |   1 +
 drivers/clk/clk-aspeed.c | 645 +++
 include/dt-bindings/clock/aspeed-clock.h |  52 +++
 4 files changed, 710 insertions(+)
 create mode 100644 drivers/clk/clk-aspeed.c
 create mode 100644 include/dt-bindings/clock/aspeed-clock.h

-- 
2.14.1

[PATCH v2 2/5] clk: aspeed: Register core clocks

[Joel Stanley]

This registers the core clocks; those which are required to calculate
the rate of the timer periperhal so the system can load a clocksource
driver.

Signed-off-by: Joel Stanley 
---
 drivers/clk/clk-aspeed.c | 152 ++-
 1 file changed, 149 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk-aspeed.c b/drivers/clk/clk-aspeed.c
index 824c54767009..e614c61b82d2 100644
--- a/drivers/clk/clk-aspeed.c
+++ b/drivers/clk/clk-aspeed.c
@@ -11,12 +11,12 @@
 
 #define pr_fmt(fmt) "clk-aspeed: " fmt
 
-#include 
-#include 
 #include 
+#include 
+#include 
 #include 
+#include 
 #include 
-#include 
 
 #include 
 
@@ -28,6 +28,9 @@
 #define ASPEED_MISC_CTRL   0x2c
 #define ASPEED_STRAP   0x70
 
+/* Globally visible clocks */
+static DEFINE_SPINLOCK(aspeed_clk_lock);
+
 /* Keeps track of all clocks */
 static struct clk_hw_onecell_data *aspeed_clk_data;
 
@@ -112,9 +115,137 @@ static const struct aspeed_gate_data aspeed_gates[] 
__initconst = {
/* 31: reserved */
 };
 
+static const struct clk_div_table ast2400_div_table[] = {
+   { 0x0, 2 },
+   { 0x1, 4 },
+   { 0x2, 6 },
+   { 0x3, 8 },
+   { 0x4, 10 },
+   { 0x5, 12 },
+   { 0x6, 14 },
+   { 0x7, 16 },
+   { 0 }
+};
+
+static const struct clk_div_table ast2500_div_table[] = {
+   { 0x0, 4 },
+   { 0x1, 8 },
+   { 0x2, 12 },
+   { 0x3, 16 },
+   { 0x4, 20 },
+   { 0x5, 24 },
+   { 0x6, 28 },
+   { 0x7, 32 },
+   { 0 }
+};
+
+static struct clk_hw *aspeed_calc_pll(const char *name, u32 val)
+{
+   unsigned int mult, div;
+
+   if (val & BIT(20)) {
+   /* Pass through mode */
+   mult = div = 1;
+   } else {
+   /* F = clkin * [(M+1) / (N+1)] / (P + 1) */
+   u32 p = (val >> 13) & 0x3f;
+   u32 m = (val >> 5) & 0xff;
+   u32 n = val & 0x1f;
+
+   mult = (m + 1) / (n + 1);
+   div = p + 1;
+   }
+
+   return clk_hw_register_fixed_factor(NULL, name, "clkin", 0,
+   mult, div);
+}
+
+static void __init aspeed_ast2400_cc(struct regmap *map)
+{
+   struct clk_hw *hw;
+   u32 val, div, mult;
+
+   /*
+* High-speed PLL clock derived from the crystal. This the CPU clock,
+* and we assume that it is enabled
+*/
+   regmap_read(map, ASPEED_HPLL_PARAM, );
+   WARN(val & BIT(18), "clock is strapped not configured");
+   if (val & BIT(17)) {
+   /* Pass through mode */
+   mult = div = 1;
+   } else {
+   /* F = 24Mhz * (2-OD) * [(N + 2) / (D + 1)] */
+   u32 n = (val >> 5) & 0x3f;
+   u32 od = (val >> 4) & 0x1;
+   u32 d = val & 0xf;
+
+   mult = (2 - od) * (n + 2);
+   div = d + 1;
+   }
+   hw = clk_hw_register_fixed_factor(NULL, "hpll", "clkin", 0, mult, div);
+   aspeed_clk_data->hws[ASPEED_CLK_HPLL] = hw;
+
+   /*
+* Strap bits 11:10 define the CPU/AHB clock frequency ratio (aka HCLK)
+*   00: Select CPU:AHB = 1:1
+*   01: Select CPU:AHB = 2:1
+*   10: Select CPU:AHB = 4:1
+*   11: Select CPU:AHB = 3:1
+*/
+   regmap_read(map, ASPEED_STRAP, );
+   val = (val >> 10) & 0x3;
+   div = val + 1;
+   if (div == 2)
+   div = 3;
+   else if (div == 3)
+   div = 2;
+   hw = clk_hw_register_fixed_factor(NULL, "ahb", "hpll", 0, 1, div);
+   aspeed_clk_data->hws[ASPEED_CLK_AHB] = hw;
+
+   /* APB clock clock selection register SCU08 (aka PCLK) */
+   hw = clk_hw_register_divider_table(NULL, "apb", "hpll", 0,
+   scu_base + ASPEED_CLK_SELECTION, 23, 3, 0,
+   ast2400_div_table,
+   _clk_lock);
+   aspeed_clk_data->hws[ASPEED_CLK_APB] = hw;
+}
+
+static void __init aspeed_ast2500_cc(struct regmap *map)
+{
+   struct clk_hw *hw;
+   u32 val, div;
+
+   /*
+* High-speed PLL clock derived from the crystal. This the CPU clock,
+* and we assume that it is enabled
+*/
+   regmap_read(map, ASPEED_HPLL_PARAM, );
+   aspeed_clk_data->hws[ASPEED_CLK_HPLL] = aspeed_calc_pll("hpll", val);
+
+   /* Strap bits 11:9 define the AXI/AHB clock frequency ratio (aka HCLK)*/
+   regmap_read(map, ASPEED_STRAP, );
+   val = (val >> 9) & 0x7;
+   WARN_ON(val == 0);
+   div = 2 * (val + 1);
+   hw = clk_hw_register_fixed_factor(NULL, "ahb", "hpll", 0, 1, div);
+   aspeed_clk_data->hws[ASPEED_CLK_AHB] = hw;
+
+   /* APB clock clock selection register SCU08 (aka PCLK) */
+   /* TODO: this is wrong! */
+   regmap_read(map, ASPEED_CLK_SELECTION, );
+   val = (val >> 23) & 0x7;
+   div = 4 * (val + 1);
+   hw = clk_hw_register_fixed_factor(NULL, "apb", "hpll", 0, 1, div);
+   

[PATCH v2 2/5] clk: aspeed: Register core clocks

[Joel Stanley]

This registers the core clocks; those which are required to calculate
the rate of the timer periperhal so the system can load a clocksource
driver.

Signed-off-by: Joel Stanley 
---
 drivers/clk/clk-aspeed.c | 152 ++-
 1 file changed, 149 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/clk-aspeed.c b/drivers/clk/clk-aspeed.c
index 824c54767009..e614c61b82d2 100644
--- a/drivers/clk/clk-aspeed.c
+++ b/drivers/clk/clk-aspeed.c
@@ -11,12 +11,12 @@
 
 #define pr_fmt(fmt) "clk-aspeed: " fmt
 
-#include 
-#include 
 #include 
+#include 
+#include 
 #include 
+#include 
 #include 
-#include 
 
 #include 
 
@@ -28,6 +28,9 @@
 #define ASPEED_MISC_CTRL   0x2c
 #define ASPEED_STRAP   0x70
 
+/* Globally visible clocks */
+static DEFINE_SPINLOCK(aspeed_clk_lock);
+
 /* Keeps track of all clocks */
 static struct clk_hw_onecell_data *aspeed_clk_data;
 
@@ -112,9 +115,137 @@ static const struct aspeed_gate_data aspeed_gates[] 
__initconst = {
/* 31: reserved */
 };
 
+static const struct clk_div_table ast2400_div_table[] = {
+   { 0x0, 2 },
+   { 0x1, 4 },
+   { 0x2, 6 },
+   { 0x3, 8 },
+   { 0x4, 10 },
+   { 0x5, 12 },
+   { 0x6, 14 },
+   { 0x7, 16 },
+   { 0 }
+};
+
+static const struct clk_div_table ast2500_div_table[] = {
+   { 0x0, 4 },
+   { 0x1, 8 },
+   { 0x2, 12 },
+   { 0x3, 16 },
+   { 0x4, 20 },
+   { 0x5, 24 },
+   { 0x6, 28 },
+   { 0x7, 32 },
+   { 0 }
+};
+
+static struct clk_hw *aspeed_calc_pll(const char *name, u32 val)
+{
+   unsigned int mult, div;
+
+   if (val & BIT(20)) {
+   /* Pass through mode */
+   mult = div = 1;
+   } else {
+   /* F = clkin * [(M+1) / (N+1)] / (P + 1) */
+   u32 p = (val >> 13) & 0x3f;
+   u32 m = (val >> 5) & 0xff;
+   u32 n = val & 0x1f;
+
+   mult = (m + 1) / (n + 1);
+   div = p + 1;
+   }
+
+   return clk_hw_register_fixed_factor(NULL, name, "clkin", 0,
+   mult, div);
+}
+
+static void __init aspeed_ast2400_cc(struct regmap *map)
+{
+   struct clk_hw *hw;
+   u32 val, div, mult;
+
+   /*
+* High-speed PLL clock derived from the crystal. This the CPU clock,
+* and we assume that it is enabled
+*/
+   regmap_read(map, ASPEED_HPLL_PARAM, );
+   WARN(val & BIT(18), "clock is strapped not configured");
+   if (val & BIT(17)) {
+   /* Pass through mode */
+   mult = div = 1;
+   } else {
+   /* F = 24Mhz * (2-OD) * [(N + 2) / (D + 1)] */
+   u32 n = (val >> 5) & 0x3f;
+   u32 od = (val >> 4) & 0x1;
+   u32 d = val & 0xf;
+
+   mult = (2 - od) * (n + 2);
+   div = d + 1;
+   }
+   hw = clk_hw_register_fixed_factor(NULL, "hpll", "clkin", 0, mult, div);
+   aspeed_clk_data->hws[ASPEED_CLK_HPLL] = hw;
+
+   /*
+* Strap bits 11:10 define the CPU/AHB clock frequency ratio (aka HCLK)
+*   00: Select CPU:AHB = 1:1
+*   01: Select CPU:AHB = 2:1
+*   10: Select CPU:AHB = 4:1
+*   11: Select CPU:AHB = 3:1
+*/
+   regmap_read(map, ASPEED_STRAP, );
+   val = (val >> 10) & 0x3;
+   div = val + 1;
+   if (div == 2)
+   div = 3;
+   else if (div == 3)
+   div = 2;
+   hw = clk_hw_register_fixed_factor(NULL, "ahb", "hpll", 0, 1, div);
+   aspeed_clk_data->hws[ASPEED_CLK_AHB] = hw;
+
+   /* APB clock clock selection register SCU08 (aka PCLK) */
+   hw = clk_hw_register_divider_table(NULL, "apb", "hpll", 0,
+   scu_base + ASPEED_CLK_SELECTION, 23, 3, 0,
+   ast2400_div_table,
+   _clk_lock);
+   aspeed_clk_data->hws[ASPEED_CLK_APB] = hw;
+}
+
+static void __init aspeed_ast2500_cc(struct regmap *map)
+{
+   struct clk_hw *hw;
+   u32 val, div;
+
+   /*
+* High-speed PLL clock derived from the crystal. This the CPU clock,
+* and we assume that it is enabled
+*/
+   regmap_read(map, ASPEED_HPLL_PARAM, );
+   aspeed_clk_data->hws[ASPEED_CLK_HPLL] = aspeed_calc_pll("hpll", val);
+
+   /* Strap bits 11:9 define the AXI/AHB clock frequency ratio (aka HCLK)*/
+   regmap_read(map, ASPEED_STRAP, );
+   val = (val >> 9) & 0x7;
+   WARN_ON(val == 0);
+   div = 2 * (val + 1);
+   hw = clk_hw_register_fixed_factor(NULL, "ahb", "hpll", 0, 1, div);
+   aspeed_clk_data->hws[ASPEED_CLK_AHB] = hw;
+
+   /* APB clock clock selection register SCU08 (aka PCLK) */
+   /* TODO: this is wrong! */
+   regmap_read(map, ASPEED_CLK_SELECTION, );
+   val = (val >> 23) & 0x7;
+   div = 4 * (val + 1);
+   hw = clk_hw_register_fixed_factor(NULL, "apb", "hpll", 0, 1, div);
+   aspeed_clk_data->hws[ASPEED_CLK_APB] = hw;

[PATCH v2 0/5] clk: Add Aspeed clock driver

[Joel Stanley]

This driver supports the ast2500, ast2400 (and derivative) BMC SoCs from
Aspeed.

This is version two of the series. Version one contained two patches; an update
to the binding document and a single patch for the driver. Lee has merged the
bindings change, so that is dropped from this series, and I split the driver
out into a series of patches to make them easier to review.

All of the important clocks are supported, with most non-essential ones
also implemented where information is available. I am working with
Aspeed to clear up some of the missing information, including the
missing parent-sibling relationships.

We need to know the rate of the apb clock in order to correctly program
the clocksource driver, so the apb and it's parents are created in the
CLK_OF_DECLARE_DRIVER callback.

The rest of the clocks are created at normal driver probe time. I
followed the Gemini driver's lead with using the regmap where I could,
but also having a pointer to the base address for use with the common
clock callbacks.

The driver borrows from the clk_gate common clock infra spruce, but modifies
it in order to support the clock gate and reset pair that most of the clocks
have. This pair must be reset-ungated-released, with appropriate delays,
according to the datasheet.

The first patch introduces the core clock registration parts, and describes
the clocks. The second creates the core clocks, giving the system enough to
boot (but without uart). Next come the non-core clocks, and finally the reset
controller that is used for the few cocks that don't have a gate to go with 
their
reset pair.

Please review!

Cheers,

Joel


Joel Stanley (5):
  clk: Add clock driver for ASPEED BMC SoCs
  clk: aspeed: Register core clocks
  clk: aspeed: Add platform driver and register PLLs
  clk: aspeed: Register gated clocks
  clk: aspeed: Add reset controller

 drivers/clk/Kconfig  |  12 +
 drivers/clk/Makefile |   1 +
 drivers/clk/clk-aspeed.c | 645 +++
 include/dt-bindings/clock/aspeed-clock.h |  52 +++
 4 files changed, 710 insertions(+)
 create mode 100644 drivers/clk/clk-aspeed.c
 create mode 100644 include/dt-bindings/clock/aspeed-clock.h

-- 
2.14.1

[git pull][vfs.git] a couple of fixes

[Al Viro]

A couple of regression fixes, one for this merge window, one for
the previous cycle.

The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:

  Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus

for you to fetch changes up to 58aff0af757356065f33290d96a9cd46dfbcae88:

  ipc/shm: Fix order of parameters when calling copy_compat_shmid_to_user 
(2017-09-20 23:27:48 -0400)


Petar Penkov (1):
  iov_iter: fix page_copy_sane for compound pages

Will Deacon (1):
  ipc/shm: Fix order of parameters when calling copy_compat_shmid_to_user

 ipc/shm.c  | 2 +-
 lib/iov_iter.c | 6 --
 2 files changed, 5 insertions(+), 3 deletions(-)

[git pull][vfs.git] a couple of fixes

[Al Viro]

A couple of regression fixes, one for this merge window, one for
the previous cycle.

The following changes since commit 2bd6bf03f4c1c59381d62c61d03f6cc3fe71f66e:

  Linux 4.14-rc1 (2017-09-16 15:47:51 -0700)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git for-linus

for you to fetch changes up to 58aff0af757356065f33290d96a9cd46dfbcae88:

  ipc/shm: Fix order of parameters when calling copy_compat_shmid_to_user 
(2017-09-20 23:27:48 -0400)


Petar Penkov (1):
  iov_iter: fix page_copy_sane for compound pages

Will Deacon (1):
  ipc/shm: Fix order of parameters when calling copy_compat_shmid_to_user

 ipc/shm.c  | 2 +-
 lib/iov_iter.c | 6 --
 2 files changed, 5 insertions(+), 3 deletions(-)

linux-next: Tree for Sep 21

[Stephen Rothwell]

Hi all,

Changes since 20170920:

Linus' tree lost its build failure.

The sound-asoc tree lost its build failure.

Non-merge commits (relative to Linus' tree): 1337
 1200 files changed, 49498 insertions(+), 15649 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And
finally, a simple boot test of the powerpc pseries_le_defconfig kernel
in qemu.

Below is a summary of the state of the merge.

I am currently merging 267 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (c52f56a69d10 Merge tag 'trace-v4.14-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace)
Merging fixes/master (820bf5c419e4 Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging kbuild-current/fixes (25b080bd53f2 kbuild: rpm-pkg: fix version number 
handling)
Merging arc-current/for-curr (307b30e26861 ARC: [plat-eznps] Update platform 
maintainer as Noam left)
Merging arm-current/fixes (746a272e4414 ARM: 8692/1: mm: abort uaccess retries 
upon fatal signal)
Merging m68k-current/for-linus (558d5ad276c9 m68k/mac: Avoid soft-lockup 
warning after mach_power_off)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (8afafa6fba78 powerpc/kprobes: Update optprobes to 
use emulate_update_regs())
Merging sparc/master (6470812e2226 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (6cc40834b480 Merge branch 'hns3-tm-fixes')
Merging ipsec/master (23e9fcfef1f3 vti: fix NULL dereference in xfrm_input())
Merging netfilter/master (7f4f7dd4417d netfilter: ipset: ipset list may return 
wrong member count for set with timeout)
Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook 
mask only if set)
Merging wireless-drivers/master (a715b3a0efe7 qtnfmac: cancel scans on wireless 
interface changes)
Merging mac80211/master (265698d7e613 nl80211: fix null-ptr dereference on 
invalid mesh configuration)
Merging sound-current/for-linus (0dcd020b7abb ALSA: usb-audio: Add sample rate 
quirk for Plantronics C310/C520-M)
Merging pci-current/for-linus (749aaf3372b8 PCI: endpoint: Use correct "end of 
test" interrupt)
Merging driver-core.current/driver-core-linus (850fdec8d2fd driver core: remove 
DRIVER_ATTR)
Merging tty.current/tty-linus (c91261437985 serial: sccnxp: Fix error handling 
in sccnxp_probe())
Merging usb.current/usb-linus (bd7a3fe770eb USB: fix out-of-bounds in 
usb_set_configuration)
Merging usb-gadget-fixes/fixes (7661ca09b2ff usb: gadget: dummy: fix 
nonsensical comparisons)
Merging usb-serial-fixes/usb-linus (c496ad835c31 USB: serial: cp210x: add 
support for ELV TFD500)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (5771a8c08880 Linux v4.13-rc1)
Merging staging.current/staging-linus (974d4d03fc02 staging: vchiq_2835_arm: 
Fix NULL ptr dereference in free_pagelist)
Merging char-misc.current/char-misc-linus (aad8d097c922 nvmem: add missing 
of_node_put() in of_nvmem_cell_get())
Merging input-current/for-linus (bbc8608755da Merge branch 'next' into 
for-linus)
Merging crypto-current/master (e117765a117d crypto: af_alg - update correct dst 
SGL entry)
Merging ide/master (b671e1703394 PN

linux-next: Tree for Sep 21

[Stephen Rothwell]

Hi all,

Changes since 20170920:

Linus' tree lost its build failure.

The sound-asoc tree lost its build failure.

Non-merge commits (relative to Linus' tree): 1337
 1200 files changed, 49498 insertions(+), 15649 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc and an allmodconfig (with
CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a
native build of tools/perf. After the final fixups (if any), I do an
x86_64 modules_install followed by builds for x86_64 allnoconfig,
powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig
and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And
finally, a simple boot test of the powerpc pseries_le_defconfig kernel
in qemu.

Below is a summary of the state of the merge.

I am currently merging 267 trees (counting Linus' and 41 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (c52f56a69d10 Merge tag 'trace-v4.14-rc1' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace)
Merging fixes/master (820bf5c419e4 Merge tag 'scsi-fixes' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi)
Merging kbuild-current/fixes (25b080bd53f2 kbuild: rpm-pkg: fix version number 
handling)
Merging arc-current/for-curr (307b30e26861 ARC: [plat-eznps] Update platform 
maintainer as Noam left)
Merging arm-current/fixes (746a272e4414 ARM: 8692/1: mm: abort uaccess retries 
upon fatal signal)
Merging m68k-current/for-linus (558d5ad276c9 m68k/mac: Avoid soft-lockup 
warning after mach_power_off)
Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups)
Merging powerpc-fixes/fixes (8afafa6fba78 powerpc/kprobes: Update optprobes to 
use emulate_update_regs())
Merging sparc/master (6470812e2226 Merge 
git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc)
Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and 
linking special files)
Merging net/master (6cc40834b480 Merge branch 'hns3-tm-fixes')
Merging ipsec/master (23e9fcfef1f3 vti: fix NULL dereference in xfrm_input())
Merging netfilter/master (7f4f7dd4417d netfilter: ipset: ipset list may return 
wrong member count for set with timeout)
Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook 
mask only if set)
Merging wireless-drivers/master (a715b3a0efe7 qtnfmac: cancel scans on wireless 
interface changes)
Merging mac80211/master (265698d7e613 nl80211: fix null-ptr dereference on 
invalid mesh configuration)
Merging sound-current/for-linus (0dcd020b7abb ALSA: usb-audio: Add sample rate 
quirk for Plantronics C310/C520-M)
Merging pci-current/for-linus (749aaf3372b8 PCI: endpoint: Use correct "end of 
test" interrupt)
Merging driver-core.current/driver-core-linus (850fdec8d2fd driver core: remove 
DRIVER_ATTR)
Merging tty.current/tty-linus (c91261437985 serial: sccnxp: Fix error handling 
in sccnxp_probe())
Merging usb.current/usb-linus (bd7a3fe770eb USB: fix out-of-bounds in 
usb_set_configuration)
Merging usb-gadget-fixes/fixes (7661ca09b2ff usb: gadget: dummy: fix 
nonsensical comparisons)
Merging usb-serial-fixes/usb-linus (c496ad835c31 USB: serial: cp210x: add 
support for ELV TFD500)
Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: 
check before accessing ci_role in ci_role_show)
Merging phy/fixes (5771a8c08880 Linux v4.13-rc1)
Merging staging.current/staging-linus (974d4d03fc02 staging: vchiq_2835_arm: 
Fix NULL ptr dereference in free_pagelist)
Merging char-misc.current/char-misc-linus (aad8d097c922 nvmem: add missing 
of_node_put() in of_nvmem_cell_get())
Merging input-current/for-linus (bbc8608755da Merge branch 'next' into 
for-linus)
Merging crypto-current/master (e117765a117d crypto: af_alg - update correct dst 
SGL entry)
Merging ide/master (b671e1703394 PN

Re: [PATCH] mpt3sas: downgrade full copy_from_user to access_ok check

[Meng Xu]

> On Sep 20, 2017, at 11:26 PM, Al Viro  wrote:
> 
> On Tue, Sep 19, 2017 at 11:11:11PM -0400, Meng Xu wrote:
>> Since right after the user copy, we are going to
>> memset(, 0, sizeof(karg)), I guess an access_ok check is enough?
> 
> access_ok() is *NOT* "will copy_from_user() succeed?"  Not even close.
> On a bunch of architectures (sparc64, for one) access_ok() is always
> true.
> 
> All it does is checking that address is not a kernel one - e.g. on
> i386 anything in range 0..3Gb qualifies.  Whether anything's mapped
> at that address or not.
> 
> Why bother with that copy_from_user() at all?  The same ioctl()
> proceeds to copy_to_user() on exact same range; all you get from
> it is "if the area passed by caller is writable, but not readable,
> fail with -EFAULT".  Who cares?
> 
> Just drop that copy_from_user() completely.  Anything access_ok()
> might've caught will be caught by copy_to_user() anyway.

Yes, Christoph has suggested the same thing and I have submitted 
another patch with copy_from_user removed entirely.

Re: [PATCH] mpt3sas: downgrade full copy_from_user to access_ok check

[Meng Xu]

> On Sep 20, 2017, at 11:26 PM, Al Viro  wrote:
> 
> On Tue, Sep 19, 2017 at 11:11:11PM -0400, Meng Xu wrote:
>> Since right after the user copy, we are going to
>> memset(, 0, sizeof(karg)), I guess an access_ok check is enough?
> 
> access_ok() is *NOT* "will copy_from_user() succeed?"  Not even close.
> On a bunch of architectures (sparc64, for one) access_ok() is always
> true.
> 
> All it does is checking that address is not a kernel one - e.g. on
> i386 anything in range 0..3Gb qualifies.  Whether anything's mapped
> at that address or not.
> 
> Why bother with that copy_from_user() at all?  The same ioctl()
> proceeds to copy_to_user() on exact same range; all you get from
> it is "if the area passed by caller is writable, but not readable,
> fail with -EFAULT".  Who cares?
> 
> Just drop that copy_from_user() completely.  Anything access_ok()
> might've caught will be caught by copy_to_user() anyway.

Yes, Christoph has suggested the same thing and I have submitted 
another patch with copy_from_user removed entirely.

Re: [lkp-robot] [drivers] ceed73a2cf: drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c:#suspicious_rcu_dereference_check()usage

[Subash Abhinov Kasiviswanathan]

On 2017-09-19 19:55, kernel test robot wrote:

FYI, we noticed the following commit:

commit: ceed73a2cf4aff2921802aa3d21d45280677547d ("drivers: net:
ethernet: qualcomm: rmnet: Initial implementation")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master

in testcase: boot

on test machine: qemu-system-i386 -enable-kvm -cpu Haswell,+smep,+smap 
-m 360M


caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):


+-+++
|
   | cdf4969c42 | ceed73a2cf |
+-+++
| boot_successes
   | 52 | 44 |
| boot_failures
   | 0  | 8  |
|
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c:#suspicious_rcu_dereference_check()usage
| 0  | 8  |
+-+++



[  101.364846] WARNING: suspicious RCU usage
[  101.365654] 4.13.0-rc6-01701-gceed73a #1 Not tainted
[  101.370873] -
[  101.372472] drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c:57
suspicious rcu_dereference_check() usage!
[  101.374427]
[  101.374427] other info that might help us debug this:
[  101.374427]
[  101.387491]
[  101.387491] rcu_scheduler_active = 2, debug_locks = 1
[  101.389368] 1 lock held by trinity-main/2809:
[  101.390736]  #0:  (rtnl_mutex){+.+.+.}, at: [<8146085b>] 
rtnl_lock+0xf/0x11

[  101.395482]
[  101.395482] stack backtrace:
[  101.396948] CPU: 0 PID: 2809 Comm: trinity-main Not tainted
4.13.0-rc6-01701-gceed73a #1
[  101.398857] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
[  101.401079] Call Trace:
[  101.401656]  dump_stack+0xa1/0xeb
[  101.402871]  lockdep_rcu_suspicious+0xc7/0xd0
[  101.403665]  rmnet_is_real_dev_registered+0x40/0x4e
[  101.405199]  rmnet_config_notify_cb+0x2c/0x142
[  101.406344]  ? wireless_nlevent_flush+0x47/0x71
[  101.407385]  notifier_call_chain+0x2d/0x47
[  101.408645]  raw_notifier_call_chain+0xc/0xe
[  101.409882]  call_netdevice_notifiers_info+0x41/0x49
[  101.411402]  call_netdevice_notifiers+0xc/0xe
[  101.412713]  rollback_registered_many+0x268/0x36e
[  101.413702]  rollback_registered+0x39/0x56
[  101.414965]  unregister_netdevice_queue+0x79/0x88
[  101.415908]  unregister_netdev+0x16/0x1d
[  101.417030]  gprs_attach+0x129/0x133
[  101.417700]  pep_setsockopt+0xa2/0x118
[  101.418851]  sock_common_setsockopt+0x13/0x18
[  101.420462]  SyS_setsockopt+0x59/0x77
[  101.421196]  SyS_socketcall+0x16c/0x1cf
[  101.422148]  do_int80_syscall_32+0x57/0x11d
[  101.423137]  entry_INT80_32+0x33/0x33
[  101.423827] EIP: 0x77fc61b2
[  101.424802] EFLAGS: 0206 CPU: 0
[  101.425465] EAX: ffda EBX: 000e ECX: 7fc2cc50 EDX: 7fc2ccd0
[  101.426928] ESI: 0005 EDI: 0152 EBP: 77da037c ESP: 7fc2cc48
[  101.428482]  DS: 007b ES: 007b FS:  GS: 0033 SS: 007b

To reproduce:

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached
in this email



Thanks,
Xiaolong


Hi Xiaolong

Thanks for the report.

I am somehow unable to reproduce this on my system.
There are some errors while running lkp.
I'll try to see if I can reproduce this some other way locally.

//some startup errors
cpio: root:lkp: invalid group

...
//errors while executing.

[child0:2600] move_pages (317) returned ENOSYS, marking as inactive.
*** glibc detected *** /trinity: double free or corruption (out): 
0x0863 ***

=== Backtrace: =
/lib/i386-linux-gnu/libc.so.6(+0x73e42)[0x77e96e42]
/trinity[0x8058af6]
/trinity[0x8051888]
/trinity[0x8054894]
/trinity[0x804a9f5]
/trinity[0x804e3be]
/trinity[0x804a085]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x77e3c4d3]
...

//seems like there is an error while connecting to system bus.
//If this is a known error, is there a workaround for this?
[   88.296910] init: tty6 main process ended, respawning
error: 'rc.local' exited outside the expected code flow.
[   97.252708] init: Failed to create pty - disabling logging for job
[   97.253484] init: Temporary process spawn error: No such file or 
directory

[   97.272202] init: rc main process (330) killed by TERM signal
unable to connect to system bus: Failed to connect to socket 
/var/run/dbus/system_bus_socket: No such file or directory

[   97.274761] init: tty4 main process (2618) killed by TERM signal
[   97.276215] init: tty5 main process (2619) killed by TERM signal
[   97.277613] init: tty2 main process (2620) killed by TERM signal
[   97.279151] init: tty3 main process (2621) killed by TERM signal
[   97.280569] init: tty6 main process (2622) killed by TERM signal
[   

Re: [lkp-robot] [drivers] ceed73a2cf: drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c:#suspicious_rcu_dereference_check()usage

[Subash Abhinov Kasiviswanathan]

On 2017-09-19 19:55, kernel test robot wrote:

FYI, we noticed the following commit:

commit: ceed73a2cf4aff2921802aa3d21d45280677547d ("drivers: net:
ethernet: qualcomm: rmnet: Initial implementation")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master

in testcase: boot

on test machine: qemu-system-i386 -enable-kvm -cpu Haswell,+smep,+smap 
-m 360M


caused below changes (please refer to attached dmesg/kmsg for entire
log/backtrace):


+-+++
|
   | cdf4969c42 | ceed73a2cf |
+-+++
| boot_successes
   | 52 | 44 |
| boot_failures
   | 0  | 8  |
|
drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c:#suspicious_rcu_dereference_check()usage
| 0  | 8  |
+-+++



[  101.364846] WARNING: suspicious RCU usage
[  101.365654] 4.13.0-rc6-01701-gceed73a #1 Not tainted
[  101.370873] -
[  101.372472] drivers/net/ethernet/qualcomm/rmnet/rmnet_config.c:57
suspicious rcu_dereference_check() usage!
[  101.374427]
[  101.374427] other info that might help us debug this:
[  101.374427]
[  101.387491]
[  101.387491] rcu_scheduler_active = 2, debug_locks = 1
[  101.389368] 1 lock held by trinity-main/2809:
[  101.390736]  #0:  (rtnl_mutex){+.+.+.}, at: [<8146085b>] 
rtnl_lock+0xf/0x11

[  101.395482]
[  101.395482] stack backtrace:
[  101.396948] CPU: 0 PID: 2809 Comm: trinity-main Not tainted
4.13.0-rc6-01701-gceed73a #1
[  101.398857] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS 1.9.3-20161025_171302-gandalf 04/01/2014
[  101.401079] Call Trace:
[  101.401656]  dump_stack+0xa1/0xeb
[  101.402871]  lockdep_rcu_suspicious+0xc7/0xd0
[  101.403665]  rmnet_is_real_dev_registered+0x40/0x4e
[  101.405199]  rmnet_config_notify_cb+0x2c/0x142
[  101.406344]  ? wireless_nlevent_flush+0x47/0x71
[  101.407385]  notifier_call_chain+0x2d/0x47
[  101.408645]  raw_notifier_call_chain+0xc/0xe
[  101.409882]  call_netdevice_notifiers_info+0x41/0x49
[  101.411402]  call_netdevice_notifiers+0xc/0xe
[  101.412713]  rollback_registered_many+0x268/0x36e
[  101.413702]  rollback_registered+0x39/0x56
[  101.414965]  unregister_netdevice_queue+0x79/0x88
[  101.415908]  unregister_netdev+0x16/0x1d
[  101.417030]  gprs_attach+0x129/0x133
[  101.417700]  pep_setsockopt+0xa2/0x118
[  101.418851]  sock_common_setsockopt+0x13/0x18
[  101.420462]  SyS_setsockopt+0x59/0x77
[  101.421196]  SyS_socketcall+0x16c/0x1cf
[  101.422148]  do_int80_syscall_32+0x57/0x11d
[  101.423137]  entry_INT80_32+0x33/0x33
[  101.423827] EIP: 0x77fc61b2
[  101.424802] EFLAGS: 0206 CPU: 0
[  101.425465] EAX: ffda EBX: 000e ECX: 7fc2cc50 EDX: 7fc2ccd0
[  101.426928] ESI: 0005 EDI: 0152 EBP: 77da037c ESP: 7fc2cc48
[  101.428482]  DS: 007b ES: 007b FS:  GS: 0033 SS: 007b

To reproduce:

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached
in this email



Thanks,
Xiaolong


Hi Xiaolong

Thanks for the report.

I am somehow unable to reproduce this on my system.
There are some errors while running lkp.
I'll try to see if I can reproduce this some other way locally.

//some startup errors
cpio: root:lkp: invalid group

...
//errors while executing.

[child0:2600] move_pages (317) returned ENOSYS, marking as inactive.
*** glibc detected *** /trinity: double free or corruption (out): 
0x0863 ***

=== Backtrace: =
/lib/i386-linux-gnu/libc.so.6(+0x73e42)[0x77e96e42]
/trinity[0x8058af6]
/trinity[0x8051888]
/trinity[0x8054894]
/trinity[0x804a9f5]
/trinity[0x804e3be]
/trinity[0x804a085]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0x77e3c4d3]
...

//seems like there is an error while connecting to system bus.
//If this is a known error, is there a workaround for this?
[   88.296910] init: tty6 main process ended, respawning
error: 'rc.local' exited outside the expected code flow.
[   97.252708] init: Failed to create pty - disabling logging for job
[   97.253484] init: Temporary process spawn error: No such file or 
directory

[   97.272202] init: rc main process (330) killed by TERM signal
unable to connect to system bus: Failed to connect to socket 
/var/run/dbus/system_bus_socket: No such file or directory

[   97.274761] init: tty4 main process (2618) killed by TERM signal
[   97.276215] init: tty5 main process (2619) killed by TERM signal
[   97.277613] init: tty2 main process (2620) killed by TERM signal
[   97.279151] init: tty3 main process (2621) killed by TERM signal
[   97.280569] init: tty6 main process (2622) killed by TERM signal
[   

Re: [PATCH] mpt3sas: downgrade full copy_from_user to access_ok check

[Al Viro]

On Tue, Sep 19, 2017 at 11:11:11PM -0400, Meng Xu wrote:
> Since right after the user copy, we are going to
> memset(, 0, sizeof(karg)), I guess an access_ok check is enough?

access_ok() is *NOT* "will copy_from_user() succeed?"  Not even close.
On a bunch of architectures (sparc64, for one) access_ok() is always
true.

All it does is checking that address is not a kernel one - e.g. on
i386 anything in range 0..3Gb qualifies.  Whether anything's mapped
at that address or not.

Why bother with that copy_from_user() at all?  The same ioctl()
proceeds to copy_to_user() on exact same range; all you get from
it is "if the area passed by caller is writable, but not readable,
fail with -EFAULT".  Who cares?

Just drop that copy_from_user() completely.  Anything access_ok()
might've caught will be caught by copy_to_user() anyway.

Re: [PATCH] mpt3sas: downgrade full copy_from_user to access_ok check

[Al Viro]

On Tue, Sep 19, 2017 at 11:11:11PM -0400, Meng Xu wrote:
> Since right after the user copy, we are going to
> memset(, 0, sizeof(karg)), I guess an access_ok check is enough?

access_ok() is *NOT* "will copy_from_user() succeed?"  Not even close.
On a bunch of architectures (sparc64, for one) access_ok() is always
true.

All it does is checking that address is not a kernel one - e.g. on
i386 anything in range 0..3Gb qualifies.  Whether anything's mapped
at that address or not.

Why bother with that copy_from_user() at all?  The same ioctl()
proceeds to copy_to_user() on exact same range; all you get from
it is "if the area passed by caller is writable, but not readable,
fail with -EFAULT".  Who cares?

Just drop that copy_from_user() completely.  Anything access_ok()
might've caught will be caught by copy_to_user() anyway.

Re: [PATCH 1/2] gpio: brcmstb: Handle return value of devm_kasprintf

[Gregory Fong]

On Wed, Sep 20, 2017 at 12:13 AM, Arvind Yadav
 wrote:
> devm_kasprintf() can fail here and we must check its return value.
>
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/gpio/gpio-brcmstb.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpio/gpio-brcmstb.c b/drivers/gpio/gpio-brcmstb.c
> index dd0308c..1227d6e 100644
> --- a/drivers/gpio/gpio-brcmstb.c
> +++ b/drivers/gpio/gpio-brcmstb.c
> @@ -485,6 +485,9 @@ static int brcmstb_gpio_probe(struct platform_device 
> *pdev)
> gc->of_node = np;
> gc->owner = THIS_MODULE;
> gc->label = devm_kasprintf(dev, GFP_KERNEL, "%pOF", 
> dev->of_node);
> +   if (!gc->label)
> +   goto fail;

Please also set err to -ENOMEM.

> +
> gc->base = gpio_base;
> gc->of_gpio_n_cells = 2;
> gc->of_xlate = brcmstb_gpio_of_xlate;
> --
> 1.9.1
>

Thanks,
Gregory

Re: [PATCH 1/2] gpio: brcmstb: Handle return value of devm_kasprintf

[Gregory Fong]

On Wed, Sep 20, 2017 at 12:13 AM, Arvind Yadav
 wrote:
> devm_kasprintf() can fail here and we must check its return value.
>
> Signed-off-by: Arvind Yadav 
> ---
>  drivers/gpio/gpio-brcmstb.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpio/gpio-brcmstb.c b/drivers/gpio/gpio-brcmstb.c
> index dd0308c..1227d6e 100644
> --- a/drivers/gpio/gpio-brcmstb.c
> +++ b/drivers/gpio/gpio-brcmstb.c
> @@ -485,6 +485,9 @@ static int brcmstb_gpio_probe(struct platform_device 
> *pdev)
> gc->of_node = np;
> gc->owner = THIS_MODULE;
> gc->label = devm_kasprintf(dev, GFP_KERNEL, "%pOF", 
> dev->of_node);
> +   if (!gc->label)
> +   goto fail;

Please also set err to -ENOMEM.

> +
> gc->base = gpio_base;
> gc->of_gpio_n_cells = 2;
> gc->of_xlate = brcmstb_gpio_of_xlate;
> --
> 1.9.1
>

Thanks,
Gregory

Re: Read-only `slaves` with shared subtrees?

[Dawid Ciezarkiewicz]

On Wed, Sep 20, 2017 at 5:39 PM, Ram Pai  wrote:
> Anyway; so something like this should be possible without breaking
> existing semantics.
>
> mount -o bind,remount,ro /mnt
> mount --make-pass-on-access  /mnt
>
> anything that gets mounted under /mnt will inherit the
> 'ro' attribute from its parent.  And when a mount-event propagates
> to a read-only-slave-mount, that new mount will automatically
> inherit the read-only attribute from its slave-parent.
>
> Dawid: will that work for you?


Yes. It is even more universal.

Regards,
Dawid Ciezarkiewicz

Re: Read-only `slaves` with shared subtrees?

[Dawid Ciezarkiewicz]

On Wed, Sep 20, 2017 at 5:39 PM, Ram Pai  wrote:
> Anyway; so something like this should be possible without breaking
> existing semantics.
>
> mount -o bind,remount,ro /mnt
> mount --make-pass-on-access  /mnt
>
> anything that gets mounted under /mnt will inherit the
> 'ro' attribute from its parent.  And when a mount-event propagates
> to a read-only-slave-mount, that new mount will automatically
> inherit the read-only attribute from its slave-parent.
>
> Dawid: will that work for you?


Yes. It is even more universal.

Regards,
Dawid Ciezarkiewicz

[PATCH v2] block: consider merge of segments when merge bio into rq

[Jianchao Wang]

When account the nr_phys_segments during merging bios into rq,
only consider segments merging in individual bio but not all
the bios in a rq. This leads to the bigger nr_phys_segments of
rq than the real one when the segments of bios in rq are
contiguous and mergeable. The nr_phys_segments of rq will exceed
max_segmets of q and stop merging while the sectors of rq maybe
far away from the max_sectors of q.

In practice, the merging will stop due to max_segmets limit while
the segments in the rq are contiguous and mergeable during the
mkfs.ext4 workload on my local. This could be harmful to the
performance of sequential operations.

To fix it, consider the segments merge when account nr_phys_segments
of rq during merging bio into rq. Decrease the nr_phys_segments of rq
by 1 when the adjacent segments in bio and rq are contiguous and
mergeable. Consequently get more fully merging and better performance
in sequential operations. In addition, it could eliminate the wasting of
scatterlist structure.

On my local mkfs.ext4 workload, the final size of rq issued raise from
168 sectors (max_segmets is 168) to 2560 sectors (max_sector_kb is 1280).

V2 : Add more comment to elaborate how this issue found and result after
apply the patch.

Signed-off-by: Jianchao Wang 
---
 block/blk-merge.c | 98 ---
 1 file changed, 64 insertions(+), 34 deletions(-)

diff --git a/block/blk-merge.c b/block/blk-merge.c
index 14b6e37..b2f54fd 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -472,54 +472,60 @@ int blk_rq_map_sg(struct request_queue *q, struct request 
*rq,
 }
 EXPORT_SYMBOL(blk_rq_map_sg);
 
-static inline int ll_new_hw_segment(struct request_queue *q,
-   struct request *req,
-   struct bio *bio)
-{
-   int nr_phys_segs = bio_phys_segments(q, bio);
-
-   if (req->nr_phys_segments + nr_phys_segs > queue_max_segments(q))
-   goto no_merge;
-
-   if (blk_integrity_merge_bio(q, req, bio) == false)
-   goto no_merge;
-
-   /*
-* This will form the start of a new hw segment.  Bump both
-* counters.
-*/
-   req->nr_phys_segments += nr_phys_segs;
-   return 1;
-
-no_merge:
-   req_set_nomerge(q, req);
-   return 0;
-}
-
 int ll_back_merge_fn(struct request_queue *q, struct request *req,
 struct bio *bio)
 {
+   unsigned int seg_size;
+   int total_nr_phys_segs;
+   bool contig;
+
if (req_gap_back_merge(req, bio))
return 0;
if (blk_integrity_rq(req) &&
integrity_req_gap_back_merge(req, bio))
return 0;
if (blk_rq_sectors(req) + bio_sectors(bio) >
-   blk_rq_get_max_sectors(req, blk_rq_pos(req))) {
-   req_set_nomerge(q, req);
-   return 0;
-   }
+   blk_rq_get_max_sectors(req, blk_rq_pos(req)))
+   goto no_merge;
+
if (!bio_flagged(req->biotail, BIO_SEG_VALID))
blk_recount_segments(q, req->biotail);
if (!bio_flagged(bio, BIO_SEG_VALID))
blk_recount_segments(q, bio);
 
-   return ll_new_hw_segment(q, req, bio);
+   if (blk_integrity_merge_bio(q, req, bio) == false)
+   goto no_merge;
+
+   seg_size = req->biotail->bi_seg_back_size + bio->bi_seg_front_size;
+   total_nr_phys_segs = req->nr_phys_segments + bio_phys_segments(q, bio);
+
+   contig = blk_phys_contig_segment(q, req->biotail, bio);
+   if (contig)
+   total_nr_phys_segs--;
+
+   if (unlikely(total_nr_phys_segs > queue_max_segments(q)))
+   goto no_merge;
+
+   if (contig) {
+   if (req->nr_phys_segments == 1)
+   req->bio->bi_seg_front_size = seg_size;
+   if (bio->bi_phys_segments == 1)
+   bio->bi_seg_back_size = seg_size;
+   }
+   req->nr_phys_segments = total_nr_phys_segs;
+   return 1;
+
+no_merge:
+   req_set_nomerge(q, req);
+   return 0;
 }
 
 int ll_front_merge_fn(struct request_queue *q, struct request *req,
  struct bio *bio)
 {
+   unsigned int seg_size;
+   int total_nr_phys_segs;
+   bool contig;
 
if (req_gap_front_merge(req, bio))
return 0;
@@ -527,16 +533,40 @@ int ll_front_merge_fn(struct request_queue *q, struct 
request *req,
integrity_req_gap_front_merge(req, bio))
return 0;
if (blk_rq_sectors(req) + bio_sectors(bio) >
-   blk_rq_get_max_sectors(req, bio->bi_iter.bi_sector)) {
-   req_set_nomerge(q, req);
-   return 0;
-   }
+   blk_rq_get_max_sectors(req, bio->bi_iter.bi_sector))
+   goto no_merge;
+
if (!bio_flagged(bio, BIO_SEG_VALID))
blk_recount_segments(q, bio);
if (!bio_flagged(req->bio, 

[PATCH v2] block: consider merge of segments when merge bio into rq

[Jianchao Wang]

When account the nr_phys_segments during merging bios into rq,
only consider segments merging in individual bio but not all
the bios in a rq. This leads to the bigger nr_phys_segments of
rq than the real one when the segments of bios in rq are
contiguous and mergeable. The nr_phys_segments of rq will exceed
max_segmets of q and stop merging while the sectors of rq maybe
far away from the max_sectors of q.

In practice, the merging will stop due to max_segmets limit while
the segments in the rq are contiguous and mergeable during the
mkfs.ext4 workload on my local. This could be harmful to the
performance of sequential operations.

To fix it, consider the segments merge when account nr_phys_segments
of rq during merging bio into rq. Decrease the nr_phys_segments of rq
by 1 when the adjacent segments in bio and rq are contiguous and
mergeable. Consequently get more fully merging and better performance
in sequential operations. In addition, it could eliminate the wasting of
scatterlist structure.

On my local mkfs.ext4 workload, the final size of rq issued raise from
168 sectors (max_segmets is 168) to 2560 sectors (max_sector_kb is 1280).

V2 : Add more comment to elaborate how this issue found and result after
apply the patch.

Signed-off-by: Jianchao Wang 
---
 block/blk-merge.c | 98 ---
 1 file changed, 64 insertions(+), 34 deletions(-)

diff --git a/block/blk-merge.c b/block/blk-merge.c
index 14b6e37..b2f54fd 100644
--- a/block/blk-merge.c
+++ b/block/blk-merge.c
@@ -472,54 +472,60 @@ int blk_rq_map_sg(struct request_queue *q, struct request 
*rq,
 }
 EXPORT_SYMBOL(blk_rq_map_sg);
 
-static inline int ll_new_hw_segment(struct request_queue *q,
-   struct request *req,
-   struct bio *bio)
-{
-   int nr_phys_segs = bio_phys_segments(q, bio);
-
-   if (req->nr_phys_segments + nr_phys_segs > queue_max_segments(q))
-   goto no_merge;
-
-   if (blk_integrity_merge_bio(q, req, bio) == false)
-   goto no_merge;
-
-   /*
-* This will form the start of a new hw segment.  Bump both
-* counters.
-*/
-   req->nr_phys_segments += nr_phys_segs;
-   return 1;
-
-no_merge:
-   req_set_nomerge(q, req);
-   return 0;
-}
-
 int ll_back_merge_fn(struct request_queue *q, struct request *req,
 struct bio *bio)
 {
+   unsigned int seg_size;
+   int total_nr_phys_segs;
+   bool contig;
+
if (req_gap_back_merge(req, bio))
return 0;
if (blk_integrity_rq(req) &&
integrity_req_gap_back_merge(req, bio))
return 0;
if (blk_rq_sectors(req) + bio_sectors(bio) >
-   blk_rq_get_max_sectors(req, blk_rq_pos(req))) {
-   req_set_nomerge(q, req);
-   return 0;
-   }
+   blk_rq_get_max_sectors(req, blk_rq_pos(req)))
+   goto no_merge;
+
if (!bio_flagged(req->biotail, BIO_SEG_VALID))
blk_recount_segments(q, req->biotail);
if (!bio_flagged(bio, BIO_SEG_VALID))
blk_recount_segments(q, bio);
 
-   return ll_new_hw_segment(q, req, bio);
+   if (blk_integrity_merge_bio(q, req, bio) == false)
+   goto no_merge;
+
+   seg_size = req->biotail->bi_seg_back_size + bio->bi_seg_front_size;
+   total_nr_phys_segs = req->nr_phys_segments + bio_phys_segments(q, bio);
+
+   contig = blk_phys_contig_segment(q, req->biotail, bio);
+   if (contig)
+   total_nr_phys_segs--;
+
+   if (unlikely(total_nr_phys_segs > queue_max_segments(q)))
+   goto no_merge;
+
+   if (contig) {
+   if (req->nr_phys_segments == 1)
+   req->bio->bi_seg_front_size = seg_size;
+   if (bio->bi_phys_segments == 1)
+   bio->bi_seg_back_size = seg_size;
+   }
+   req->nr_phys_segments = total_nr_phys_segs;
+   return 1;
+
+no_merge:
+   req_set_nomerge(q, req);
+   return 0;
 }
 
 int ll_front_merge_fn(struct request_queue *q, struct request *req,
  struct bio *bio)
 {
+   unsigned int seg_size;
+   int total_nr_phys_segs;
+   bool contig;
 
if (req_gap_front_merge(req, bio))
return 0;
@@ -527,16 +533,40 @@ int ll_front_merge_fn(struct request_queue *q, struct 
request *req,
integrity_req_gap_front_merge(req, bio))
return 0;
if (blk_rq_sectors(req) + bio_sectors(bio) >
-   blk_rq_get_max_sectors(req, bio->bi_iter.bi_sector)) {
-   req_set_nomerge(q, req);
-   return 0;
-   }
+   blk_rq_get_max_sectors(req, bio->bi_iter.bi_sector))
+   goto no_merge;
+
if (!bio_flagged(bio, BIO_SEG_VALID))
blk_recount_segments(q, bio);
if (!bio_flagged(req->bio, BIO_SEG_VALID))
 

Re: [PATCH] block: consider merge of segments when merge bio into rq

[jianchao.wang]

On 09/21/2017 09:29 AM, Christoph Hellwig wrote:
> So the check change here looks good to me.
> 
> I don't like like the duplicate code, can you look into sharing
> the new segment checks between the two functions and the existing
> instance in ll_merge_requests_fn by passing say two struct bio *bio1
> and struct bio *bio2 pointer instead of using req->bio and req->biotail?
> 
> Also please include the information that you posted in the reply to
> the other patch in the description for this one.
> 
I have looked into the ll_back/front_merge_fn() and ll_merge_requests_fn().
It seems that segments check code fragment looks similar but not unified.
We could unify the part of calculation of variable of seg_size and contig,
but not the positions where use these two.
Especially the calculation of total_phys_segments and judgment of 
'nr_phys_segments == 1', rq variable cannot be avoided there. And the update
of bi_seg_front/back_size is also very tricky. If force to merge these code 
fragments together, the code may become hard to read.

So please refer to the V2 patch which contain more comment about the issue
and result.

Thanks
Jianchao

Re: [PATCH] block: consider merge of segments when merge bio into rq

[jianchao.wang]

On 09/21/2017 09:29 AM, Christoph Hellwig wrote:
> So the check change here looks good to me.
> 
> I don't like like the duplicate code, can you look into sharing
> the new segment checks between the two functions and the existing
> instance in ll_merge_requests_fn by passing say two struct bio *bio1
> and struct bio *bio2 pointer instead of using req->bio and req->biotail?
> 
> Also please include the information that you posted in the reply to
> the other patch in the description for this one.
> 
I have looked into the ll_back/front_merge_fn() and ll_merge_requests_fn().
It seems that segments check code fragment looks similar but not unified.
We could unify the part of calculation of variable of seg_size and contig,
but not the positions where use these two.
Especially the calculation of total_phys_segments and judgment of 
'nr_phys_segments == 1', rq variable cannot be avoided there. And the update
of bi_seg_front/back_size is also very tricky. If force to merge these code 
fragments together, the code may become hard to read.

So please refer to the V2 patch which contain more comment about the issue
and result.

Thanks
Jianchao

[lkp-robot] [blk] 47e0fb461f: BUG:unable_to_handle_kernel

[kernel test robot]

FYI, we noticed the following commit:

commit: 47e0fb461fca1a68a566c82fcc006cc787312d8c ("blk: make the bioset 
rescue_workqueue optional.")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-x86_64 -enable-kvm -cpu IvyBridge -m 420M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+---+++
|   | 011067b056 | 
47e0fb461f |
+---+++
| boot_successes| 0  | 0
  |
| boot_failures | 6  | 6
  |
| WARNING:at_drivers/ata/libata-core.c:#ata_host_detach | 6  | 6
  |
| EIP:ata_host_detach   | 6  | 6
  |
| BUG:unable_to_handle_kernel   | 0  | 6
  |
| Oops:#[##]| 0  | 6
  |
| EIP:ata_dev_next  | 0  | 6
  |
| Kernel_panic-not_syncing:Fatal_exception  | 0  | 6
  |
+---+++



[   60.775694] BUG: unable to handle kernel paging request at 2480
[   60.776801] IP: ata_dev_next+0x74/0xd4
[   60.777629] *pdpt =  *pde = f000ff53f000ff53 
[   60.777635] 
[   60.779284] Oops:  [#1]
[   60.780019] CPU: 0 PID: 44 Comm: kworker/u2:3 Tainted: G S  W   
4.12.0-rc5-00126-g47e0fb46 #1
[   60.781816] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   60.783712] Workqueue: events_unbound async_run_entry_fn
[   60.784703] task: d4bfe940 task.stack: d515e000
[   60.785615] EIP: ata_dev_next+0x74/0xd4
[   60.786453] EFLAGS: 00210286 CPU: 0
[   60.787248] EAX: d5f85e80 EBX:  ECX: 0001 EDX: d5f85640
[   60.788329] ESI: d5f858a0 EDI:  EBP: d515fef4 ESP: d515fee8
[   60.789416]  DS: 007b ES: 007b FS:  GS: 00e0 SS: 0068
[   60.790419] CR0: 80050033 CR2: 2480 CR3: 02a75000 CR4: 001406b0
[   60.791506] Call Trace:
[   60.792195]  ata_scsi_scan_host+0x38/0x131
[   60.793051]  async_port_probe+0x43/0x48
[   60.793886]  async_run_entry_fn+0x3b/0x13b
[   60.794746]  process_one_work+0x11f/0x26c
[   60.795595]  worker_thread+0x1b2/0x26f
[   60.796419]  kthread+0xf9/0xfe
[   60.797168]  ? process_scheduled_works+0x24/0x24
[   60.798074]  ? __kthread_create_on_node+0x109/0x109
[   60.799021]  ret_from_fork+0x19/0x30
[   60.799829] Code: 41 69 c9 e0 05 00 00 8d 84 08 20 fa ff ff eb 2f 83 fb 03 
74 66 05 e0 05 00 00 8b 3a 8d 8f 40 16 00 00 39 ca 74 49 b9 01 00 00 00 <39> 97 
80 24 00 00 74 3c 69 c9 e0 05 00 00 01 f1 39 c8 73 45 83
[   60.802985] EIP: ata_dev_next+0x74/0xd4 SS:ESP: 0068:d515fee8
[   60.804012] CR2: 2480
[   60.804794] ---[ end trace a06f3b23fe961bc3 ]---


To reproduce:

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.12.0-rc5 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=3
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y

[lkp-robot] [blk] 47e0fb461f: BUG:unable_to_handle_kernel

[kernel test robot]

FYI, we noticed the following commit:

commit: 47e0fb461fca1a68a566c82fcc006cc787312d8c ("blk: make the bioset 
rescue_workqueue optional.")
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master

in testcase: trinity
with following parameters:

runtime: 300s

test-description: Trinity is a linux system call fuzz tester.
test-url: http://codemonkey.org.uk/projects/trinity/


on test machine: qemu-system-x86_64 -enable-kvm -cpu IvyBridge -m 420M

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+---+++
|   | 011067b056 | 
47e0fb461f |
+---+++
| boot_successes| 0  | 0
  |
| boot_failures | 6  | 6
  |
| WARNING:at_drivers/ata/libata-core.c:#ata_host_detach | 6  | 6
  |
| EIP:ata_host_detach   | 6  | 6
  |
| BUG:unable_to_handle_kernel   | 0  | 6
  |
| Oops:#[##]| 0  | 6
  |
| EIP:ata_dev_next  | 0  | 6
  |
| Kernel_panic-not_syncing:Fatal_exception  | 0  | 6
  |
+---+++



[   60.775694] BUG: unable to handle kernel paging request at 2480
[   60.776801] IP: ata_dev_next+0x74/0xd4
[   60.777629] *pdpt =  *pde = f000ff53f000ff53 
[   60.777635] 
[   60.779284] Oops:  [#1]
[   60.780019] CPU: 0 PID: 44 Comm: kworker/u2:3 Tainted: G S  W   
4.12.0-rc5-00126-g47e0fb46 #1
[   60.781816] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.9.3-20161025_171302-gandalf 04/01/2014
[   60.783712] Workqueue: events_unbound async_run_entry_fn
[   60.784703] task: d4bfe940 task.stack: d515e000
[   60.785615] EIP: ata_dev_next+0x74/0xd4
[   60.786453] EFLAGS: 00210286 CPU: 0
[   60.787248] EAX: d5f85e80 EBX:  ECX: 0001 EDX: d5f85640
[   60.788329] ESI: d5f858a0 EDI:  EBP: d515fef4 ESP: d515fee8
[   60.789416]  DS: 007b ES: 007b FS:  GS: 00e0 SS: 0068
[   60.790419] CR0: 80050033 CR2: 2480 CR3: 02a75000 CR4: 001406b0
[   60.791506] Call Trace:
[   60.792195]  ata_scsi_scan_host+0x38/0x131
[   60.793051]  async_port_probe+0x43/0x48
[   60.793886]  async_run_entry_fn+0x3b/0x13b
[   60.794746]  process_one_work+0x11f/0x26c
[   60.795595]  worker_thread+0x1b2/0x26f
[   60.796419]  kthread+0xf9/0xfe
[   60.797168]  ? process_scheduled_works+0x24/0x24
[   60.798074]  ? __kthread_create_on_node+0x109/0x109
[   60.799021]  ret_from_fork+0x19/0x30
[   60.799829] Code: 41 69 c9 e0 05 00 00 8d 84 08 20 fa ff ff eb 2f 83 fb 03 
74 66 05 e0 05 00 00 8b 3a 8d 8f 40 16 00 00 39 ca 74 49 b9 01 00 00 00 <39> 97 
80 24 00 00 74 3c 69 c9 e0 05 00 00 01 f1 39 c8 73 45 83
[   60.802985] EIP: ata_dev_next+0x74/0xd4 SS:ESP: 0068:d515fee8
[   60.804012] CR2: 2480
[   60.804794] ---[ end trace a06f3b23fe961bc3 ]---


To reproduce:

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script  # job-script is attached in this 
email



Thanks,
Xiaolong
#
# Automatically generated file; DO NOT EDIT.
# Linux/i386 4.12.0-rc5 Kernel Configuration
#
# CONFIG_64BIT is not set
CONFIG_X86_32=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf32-i386"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/i386_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_BITS_MAX=16
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=3
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y

RE: [PATCHv2 0/3] arm64: dts: ls1012a: add the DTS node for DSPI support

[Z.q. Hou]

Hi Shawn,

> -Original Message-
> From: Shawn Guo [mailto:shawn...@kernel.org]
> Sent: 2017年9月20日 22:11
> To: Z.q. Hou 
> Cc: linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; dw...@infradead.org; robh...@kernel.org;
> mark.rutl...@arm.com; computersforpe...@gmail.com
> Subject: Re: [PATCHv2 0/3] arm64: dts: ls1012a: add the DTS node for DSPI
> support
> 
> On Wed, Aug 30, 2017 at 06:12:35PM +0800, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > Corrected the subject for 3/5 patch v1.
> >
> > Yuan Yao (3):
> >   arm64: dts: ls1012a: add the DTS node for DSPI support
> >   Documentation: fsl: dspi: Add fsl,ls1012a-dspi compatible string
> >   Documentation: dt: mtd: add sst25wf040b and en25s64 to the SPI NOR
> > support list
> 
> I edited bindings doc patch subject a bit, and applied all.

Thanks a lot!

- Zhiqiang

RE: [PATCHv2 0/3] arm64: dts: ls1012a: add the DTS node for DSPI support

[Z.q. Hou]

Hi Shawn,

> -Original Message-
> From: Shawn Guo [mailto:shawn...@kernel.org]
> Sent: 2017年9月20日 22:11
> To: Z.q. Hou 
> Cc: linux-arm-ker...@lists.infradead.org; devicet...@vger.kernel.org;
> linux-kernel@vger.kernel.org; dw...@infradead.org; robh...@kernel.org;
> mark.rutl...@arm.com; computersforpe...@gmail.com
> Subject: Re: [PATCHv2 0/3] arm64: dts: ls1012a: add the DTS node for DSPI
> support
> 
> On Wed, Aug 30, 2017 at 06:12:35PM +0800, Zhiqiang Hou wrote:
> > From: Hou Zhiqiang 
> >
> > Corrected the subject for 3/5 patch v1.
> >
> > Yuan Yao (3):
> >   arm64: dts: ls1012a: add the DTS node for DSPI support
> >   Documentation: fsl: dspi: Add fsl,ls1012a-dspi compatible string
> >   Documentation: dt: mtd: add sst25wf040b and en25s64 to the SPI NOR
> > support list
> 
> I edited bindings doc patch subject a bit, and applied all.

Thanks a lot!

- Zhiqiang

Re: [PATCH v2] vfs: introduce UMOUNT_WAIT which waits for umount completion

[Al Viro]

On Wed, Sep 20, 2017 at 05:34:09PM -0700, Jaegeuk Kim wrote:
> > flush_delayed_fput()
> > does nothing, the list is empty
> 
>   how about waiting for workqueue completion here?
> 
> > 
> 
>   If all the __fput()s are not finished, do_umount() will return -EBUSY.

Hell, no.  That's only when they are all on the same vfsmount.  And in that
case you don't need any waiting - if any of those mntput() is not past the
unlock_mount_hash() in mntput_no_expire(), you will get -EBUSY.  And if they
all are, the caller of umount(2) will end up dropping the last reference.  
In which case the shutdown will be scheduled via task_work_add() and processed
before umount(2) returns to userland.

The whole problem is that you have several vfsmounts over the same filesystem
(== same struct super_block), some of them held by kernel threads of yours.
umount(2) doesn't affect those and isn't affected by those.  What you do is,
AFAICS,
ask the kernel threads to start shutting down
umount()
shut device down, hoping that all vfsmounts that used
to be held by those threads are gone by that point.

Your patch tries to stick "flush the pending work" in the umount().
With no warranty that it will catch that stuff in the stage where
flushing will affect anything.

> +void flush_delayed_fput_wait(void)
> +{
> + delayed_fput(NULL);
> + flush_delayed_work(_fput_work);
> +}

> +void flush_delayed_mntput_wait(void)
> +{
> + delayed_mntput(NULL);
> + flush_delayed_work(_mntput_work);
> +}

It's still a broken approach.  What I don't understand is why bother
with that sort of brittle logics in the first place.  Why not simply
open the damn thing with O_EXCL before proceeding to device shutdown?
And if you get "busy" from that, wait and retry...

Re: [PATCH v2] vfs: introduce UMOUNT_WAIT which waits for umount completion

[Al Viro]

On Wed, Sep 20, 2017 at 05:34:09PM -0700, Jaegeuk Kim wrote:
> > flush_delayed_fput()
> > does nothing, the list is empty
> 
>   how about waiting for workqueue completion here?
> 
> > 
> 
>   If all the __fput()s are not finished, do_umount() will return -EBUSY.

Hell, no.  That's only when they are all on the same vfsmount.  And in that
case you don't need any waiting - if any of those mntput() is not past the
unlock_mount_hash() in mntput_no_expire(), you will get -EBUSY.  And if they
all are, the caller of umount(2) will end up dropping the last reference.  
In which case the shutdown will be scheduled via task_work_add() and processed
before umount(2) returns to userland.

The whole problem is that you have several vfsmounts over the same filesystem
(== same struct super_block), some of them held by kernel threads of yours.
umount(2) doesn't affect those and isn't affected by those.  What you do is,
AFAICS,
ask the kernel threads to start shutting down
umount()
shut device down, hoping that all vfsmounts that used
to be held by those threads are gone by that point.

Your patch tries to stick "flush the pending work" in the umount().
With no warranty that it will catch that stuff in the stage where
flushing will affect anything.

> +void flush_delayed_fput_wait(void)
> +{
> + delayed_fput(NULL);
> + flush_delayed_work(_fput_work);
> +}

> +void flush_delayed_mntput_wait(void)
> +{
> + delayed_mntput(NULL);
> + flush_delayed_work(_mntput_work);
> +}

It's still a broken approach.  What I don't understand is why bother
with that sort of brittle logics in the first place.  Why not simply
open the damn thing with O_EXCL before proceeding to device shutdown?
And if you get "busy" from that, wait and retry...

[PATCH v2 2/2] security: keys: Replace time_t with time64_t for struct key_preparsed_payload

[Baolin Wang]

The 'struct key_preparsed_payload' will use 'time_t' which we will
try to remove in the kernel, since 'time_t' is not year 2038 safe on
32bits systems.

Thus this patch replaces 'time_t' with 'time64_t' which is year 2038
safe on 32 bits system for 'struct key_preparsed_payload', moreover
we should use the 'TIME64_MAX' macro to initialize the 'time64_t'
type variable.

Signed-off-by: Baolin Wang 
Reviewed-by: Arnd Bergmann 
---
 include/linux/key-type.h |2 +-
 security/keys/key.c  |8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/linux/key-type.h b/include/linux/key-type.h
index 9520fc3..05d8fb5 100644
--- a/include/linux/key-type.h
+++ b/include/linux/key-type.h
@@ -44,7 +44,7 @@ struct key_preparsed_payload {
const void  *data;  /* Raw data */
size_t  datalen;/* Raw datalen */
size_t  quotalen;   /* Quota length for proposed payload */
-   time_t  expiry; /* Expiry time of key */
+   time64_texpiry; /* Expiry time of key */
 } __randomize_layout;
 
 typedef int (*request_key_actor_t)(struct key_construction *key,
diff --git a/security/keys/key.c b/security/keys/key.c
index 291a67c..d5c8941 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -446,7 +446,7 @@ static int __key_instantiate_and_link(struct key *key,
if (authkey)
key_revoke(authkey);
 
-   if (prep->expiry != TIME_T_MAX) {
+   if (prep->expiry != TIME64_MAX) {
key->expiry = prep->expiry;
key_schedule_gc(prep->expiry + key_gc_delay);
}
@@ -492,7 +492,7 @@ int key_instantiate_and_link(struct key *key,
prep.data = data;
prep.datalen = datalen;
prep.quotalen = key->type->def_datalen;
-   prep.expiry = TIME_T_MAX;
+   prep.expiry = TIME64_MAX;
if (key->type->preparse) {
ret = key->type->preparse();
if (ret < 0)
@@ -834,7 +834,7 @@ key_ref_t key_create_or_update(key_ref_t keyring_ref,
prep.data = payload;
prep.datalen = plen;
prep.quotalen = index_key.type->def_datalen;
-   prep.expiry = TIME_T_MAX;
+   prep.expiry = TIME64_MAX;
if (index_key.type->preparse) {
ret = index_key.type->preparse();
if (ret < 0) {
@@ -968,7 +968,7 @@ int key_update(key_ref_t key_ref, const void *payload, 
size_t plen)
prep.data = payload;
prep.datalen = plen;
prep.quotalen = key->type->def_datalen;
-   prep.expiry = TIME_T_MAX;
+   prep.expiry = TIME64_MAX;
if (key->type->preparse) {
ret = key->type->preparse();
if (ret < 0)
-- 
1.7.9.5

[PATCH v2 2/2] security: keys: Replace time_t with time64_t for struct key_preparsed_payload

[Baolin Wang]

The 'struct key_preparsed_payload' will use 'time_t' which we will
try to remove in the kernel, since 'time_t' is not year 2038 safe on
32bits systems.

Thus this patch replaces 'time_t' with 'time64_t' which is year 2038
safe on 32 bits system for 'struct key_preparsed_payload', moreover
we should use the 'TIME64_MAX' macro to initialize the 'time64_t'
type variable.

Signed-off-by: Baolin Wang 
Reviewed-by: Arnd Bergmann 
---
 include/linux/key-type.h |2 +-
 security/keys/key.c  |8 
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/include/linux/key-type.h b/include/linux/key-type.h
index 9520fc3..05d8fb5 100644
--- a/include/linux/key-type.h
+++ b/include/linux/key-type.h
@@ -44,7 +44,7 @@ struct key_preparsed_payload {
const void  *data;  /* Raw data */
size_t  datalen;/* Raw datalen */
size_t  quotalen;   /* Quota length for proposed payload */
-   time_t  expiry; /* Expiry time of key */
+   time64_texpiry; /* Expiry time of key */
 } __randomize_layout;
 
 typedef int (*request_key_actor_t)(struct key_construction *key,
diff --git a/security/keys/key.c b/security/keys/key.c
index 291a67c..d5c8941 100644
--- a/security/keys/key.c
+++ b/security/keys/key.c
@@ -446,7 +446,7 @@ static int __key_instantiate_and_link(struct key *key,
if (authkey)
key_revoke(authkey);
 
-   if (prep->expiry != TIME_T_MAX) {
+   if (prep->expiry != TIME64_MAX) {
key->expiry = prep->expiry;
key_schedule_gc(prep->expiry + key_gc_delay);
}
@@ -492,7 +492,7 @@ int key_instantiate_and_link(struct key *key,
prep.data = data;
prep.datalen = datalen;
prep.quotalen = key->type->def_datalen;
-   prep.expiry = TIME_T_MAX;
+   prep.expiry = TIME64_MAX;
if (key->type->preparse) {
ret = key->type->preparse();
if (ret < 0)
@@ -834,7 +834,7 @@ key_ref_t key_create_or_update(key_ref_t keyring_ref,
prep.data = payload;
prep.datalen = plen;
prep.quotalen = index_key.type->def_datalen;
-   prep.expiry = TIME_T_MAX;
+   prep.expiry = TIME64_MAX;
if (index_key.type->preparse) {
ret = index_key.type->preparse();
if (ret < 0) {
@@ -968,7 +968,7 @@ int key_update(key_ref_t key_ref, const void *payload, 
size_t plen)
prep.data = payload;
prep.datalen = plen;
prep.quotalen = key->type->def_datalen;
-   prep.expiry = TIME_T_MAX;
+   prep.expiry = TIME64_MAX;
if (key->type->preparse) {
ret = key->type->preparse();
if (ret < 0)
-- 
1.7.9.5

[PATCH v2 1/2] security: keys: Replace time_t/timespec with time64_t

[Baolin Wang]

The 'struct key' will use 'time_t' which we try to remove in the
kernel, since 'time_t' is not year 2038 safe on 32bit systems.
Also the 'struct keyring_search_context' will use 'timespec' type
to record current time, which is also not year 2038 safe on 32bit
systems.

Thus this patch replaces 'time_t' with 'time64_t' which is year 2038
safe for 'struct key', and replace 'timespec' with 'time64_t' for the
'struct keyring_search_context', since we only look at the the seconds
part of 'timespec' variable. Moreover we also change the codes where
using the 'time_t' and 'timespec', and we can get current time by
ktime_get_real_seconds() instead of current_kernel_time(), and use
'TIME64_MAX' macro to initialize the 'time64_t' type variable.

Especially in proc.c file, we have replaced 'unsigned long' and 'timespec'
type with 'u64' and 'time64_t' type to save the timeout value, which means
user will get one 'u64' type timeout value by issuing proc_keys_show()
function.

Signed-off-by: Baolin Wang 
Reviewed-by: Arnd Bergmann 
---
 include/linux/key.h  |7 ---
 security/keys/gc.c   |   20 ++--
 security/keys/internal.h |8 
 security/keys/key.c  |   19 ++-
 security/keys/keyring.c  |   18 +-
 security/keys/permission.c   |3 +--
 security/keys/proc.c |   20 ++--
 security/keys/process_keys.c |2 +-
 8 files changed, 45 insertions(+), 52 deletions(-)

diff --git a/include/linux/key.h b/include/linux/key.h
index 0441141..6d10f84 100644
--- a/include/linux/key.h
+++ b/include/linux/key.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef __KERNEL__
 #include 
@@ -157,10 +158,10 @@ struct key {
struct key_user *user;  /* owner of this key */
void*security;  /* security data for this key */
union {
-   time_t  expiry; /* time at which key expires 
(or 0) */
-   time_t  revoked_at; /* time at which key was 
revoked */
+   time64_texpiry; /* time at which key expires 
(or 0) */
+   time64_trevoked_at; /* time at which key was 
revoked */
};
-   time_t  last_used_at;   /* last time used for LRU 
keyring discard */
+   time64_tlast_used_at;   /* last time used for LRU 
keyring discard */
kuid_t  uid;
kgid_t  gid;
key_perm_t  perm;   /* access permissions */
diff --git a/security/keys/gc.c b/security/keys/gc.c
index 87cb260..c99700e 100644
--- a/security/keys/gc.c
+++ b/security/keys/gc.c
@@ -32,7 +32,7 @@
 static void key_gc_timer_func(unsigned long);
 static DEFINE_TIMER(key_gc_timer, key_gc_timer_func, 0, 0);
 
-static time_t key_gc_next_run = LONG_MAX;
+static time64_t key_gc_next_run = TIME64_MAX;
 static struct key_type *key_gc_dead_keytype;
 
 static unsigned long key_gc_flags;
@@ -53,12 +53,12 @@ struct key_type key_type_dead = {
  * Schedule a garbage collection run.
  * - time precision isn't particularly important
  */
-void key_schedule_gc(time_t gc_at)
+void key_schedule_gc(time64_t gc_at)
 {
unsigned long expires;
-   time_t now = current_kernel_time().tv_sec;
+   time64_t now = ktime_get_real_seconds();
 
-   kenter("%ld", gc_at - now);
+   kenter("%lld", gc_at - now);
 
if (gc_at <= now || test_bit(KEY_GC_REAP_KEYTYPE, _gc_flags)) {
kdebug("IMMEDIATE");
@@ -87,7 +87,7 @@ void key_schedule_gc_links(void)
 static void key_gc_timer_func(unsigned long data)
 {
kenter("");
-   key_gc_next_run = LONG_MAX;
+   key_gc_next_run = TIME64_MAX;
key_schedule_gc_links();
 }
 
@@ -184,11 +184,11 @@ static void key_garbage_collector(struct work_struct 
*work)
 
struct rb_node *cursor;
struct key *key;
-   time_t new_timer, limit;
+   time64_t new_timer, limit;
 
kenter("[%lx,%x]", key_gc_flags, gc_state);
 
-   limit = current_kernel_time().tv_sec;
+   limit = ktime_get_real_seconds();
if (limit > key_gc_delay)
limit -= key_gc_delay;
else
@@ -204,7 +204,7 @@ static void key_garbage_collector(struct work_struct *work)
gc_state |= KEY_GC_REAPING_DEAD_1;
kdebug("new pass %x", gc_state);
 
-   new_timer = LONG_MAX;
+   new_timer = TIME64_MAX;
 
/* As only this function is permitted to remove things from the key
 * serial tree, if cursor is non-NULL then it will always point to a
@@ -235,7 +235,7 @@ static void key_garbage_collector(struct work_struct *work)
 
if (gc_state & KEY_GC_SET_TIMER) {
if (key->expiry > limit && key->expiry < new_timer) {
-   kdebug("will expire %x in %ld",
+

[PATCH v2 1/2] security: keys: Replace time_t/timespec with time64_t

[Baolin Wang]

The 'struct key' will use 'time_t' which we try to remove in the
kernel, since 'time_t' is not year 2038 safe on 32bit systems.
Also the 'struct keyring_search_context' will use 'timespec' type
to record current time, which is also not year 2038 safe on 32bit
systems.

Thus this patch replaces 'time_t' with 'time64_t' which is year 2038
safe for 'struct key', and replace 'timespec' with 'time64_t' for the
'struct keyring_search_context', since we only look at the the seconds
part of 'timespec' variable. Moreover we also change the codes where
using the 'time_t' and 'timespec', and we can get current time by
ktime_get_real_seconds() instead of current_kernel_time(), and use
'TIME64_MAX' macro to initialize the 'time64_t' type variable.

Especially in proc.c file, we have replaced 'unsigned long' and 'timespec'
type with 'u64' and 'time64_t' type to save the timeout value, which means
user will get one 'u64' type timeout value by issuing proc_keys_show()
function.

Signed-off-by: Baolin Wang 
Reviewed-by: Arnd Bergmann 
---
 include/linux/key.h  |7 ---
 security/keys/gc.c   |   20 ++--
 security/keys/internal.h |8 
 security/keys/key.c  |   19 ++-
 security/keys/keyring.c  |   18 +-
 security/keys/permission.c   |3 +--
 security/keys/proc.c |   20 ++--
 security/keys/process_keys.c |2 +-
 8 files changed, 45 insertions(+), 52 deletions(-)

diff --git a/include/linux/key.h b/include/linux/key.h
index 0441141..6d10f84 100644
--- a/include/linux/key.h
+++ b/include/linux/key.h
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #ifdef __KERNEL__
 #include 
@@ -157,10 +158,10 @@ struct key {
struct key_user *user;  /* owner of this key */
void*security;  /* security data for this key */
union {
-   time_t  expiry; /* time at which key expires 
(or 0) */
-   time_t  revoked_at; /* time at which key was 
revoked */
+   time64_texpiry; /* time at which key expires 
(or 0) */
+   time64_trevoked_at; /* time at which key was 
revoked */
};
-   time_t  last_used_at;   /* last time used for LRU 
keyring discard */
+   time64_tlast_used_at;   /* last time used for LRU 
keyring discard */
kuid_t  uid;
kgid_t  gid;
key_perm_t  perm;   /* access permissions */
diff --git a/security/keys/gc.c b/security/keys/gc.c
index 87cb260..c99700e 100644
--- a/security/keys/gc.c
+++ b/security/keys/gc.c
@@ -32,7 +32,7 @@
 static void key_gc_timer_func(unsigned long);
 static DEFINE_TIMER(key_gc_timer, key_gc_timer_func, 0, 0);
 
-static time_t key_gc_next_run = LONG_MAX;
+static time64_t key_gc_next_run = TIME64_MAX;
 static struct key_type *key_gc_dead_keytype;
 
 static unsigned long key_gc_flags;
@@ -53,12 +53,12 @@ struct key_type key_type_dead = {
  * Schedule a garbage collection run.
  * - time precision isn't particularly important
  */
-void key_schedule_gc(time_t gc_at)
+void key_schedule_gc(time64_t gc_at)
 {
unsigned long expires;
-   time_t now = current_kernel_time().tv_sec;
+   time64_t now = ktime_get_real_seconds();
 
-   kenter("%ld", gc_at - now);
+   kenter("%lld", gc_at - now);
 
if (gc_at <= now || test_bit(KEY_GC_REAP_KEYTYPE, _gc_flags)) {
kdebug("IMMEDIATE");
@@ -87,7 +87,7 @@ void key_schedule_gc_links(void)
 static void key_gc_timer_func(unsigned long data)
 {
kenter("");
-   key_gc_next_run = LONG_MAX;
+   key_gc_next_run = TIME64_MAX;
key_schedule_gc_links();
 }
 
@@ -184,11 +184,11 @@ static void key_garbage_collector(struct work_struct 
*work)
 
struct rb_node *cursor;
struct key *key;
-   time_t new_timer, limit;
+   time64_t new_timer, limit;
 
kenter("[%lx,%x]", key_gc_flags, gc_state);
 
-   limit = current_kernel_time().tv_sec;
+   limit = ktime_get_real_seconds();
if (limit > key_gc_delay)
limit -= key_gc_delay;
else
@@ -204,7 +204,7 @@ static void key_garbage_collector(struct work_struct *work)
gc_state |= KEY_GC_REAPING_DEAD_1;
kdebug("new pass %x", gc_state);
 
-   new_timer = LONG_MAX;
+   new_timer = TIME64_MAX;
 
/* As only this function is permitted to remove things from the key
 * serial tree, if cursor is non-NULL then it will always point to a
@@ -235,7 +235,7 @@ static void key_garbage_collector(struct work_struct *work)
 
if (gc_state & KEY_GC_SET_TIMER) {
if (key->expiry > limit && key->expiry < new_timer) {
-   kdebug("will expire %x in %ld",
+   kdebug("will expire %x in 

[PATCH v2 0/2] Fix y2038 issues for security/keys subsystem

[Baolin Wang]

Since 'time_t', 'timeval' and 'timespec' types are not year 2038 safe on
32 bits system, this patchset tries to fix this issues for security/keys
subsystem.

Changes since v1:
 - Add reviewed tag from Arnd.
 - Drop Patch 3 which had been merged into kernel 4.14 by David.

Baolin Wang (2):
  security: keys: Replace time_t/timespec with time64_t
  security: keys: Replace time_t with time64_t for struct
key_preparsed_payload

 include/linux/key-type.h |2 +-
 include/linux/key.h  |7 ---
 security/keys/gc.c   |   20 ++--
 security/keys/internal.h |8 
 security/keys/key.c  |   27 ++-
 security/keys/keyring.c  |   18 +-
 security/keys/permission.c   |3 +--
 security/keys/proc.c |   20 ++--
 security/keys/process_keys.c |2 +-
 9 files changed, 50 insertions(+), 57 deletions(-)

-- 
1.7.9.5

[PATCH v2 0/2] Fix y2038 issues for security/keys subsystem

[Baolin Wang]

Since 'time_t', 'timeval' and 'timespec' types are not year 2038 safe on
32 bits system, this patchset tries to fix this issues for security/keys
subsystem.

Changes since v1:
 - Add reviewed tag from Arnd.
 - Drop Patch 3 which had been merged into kernel 4.14 by David.

Baolin Wang (2):
  security: keys: Replace time_t/timespec with time64_t
  security: keys: Replace time_t with time64_t for struct
key_preparsed_payload

 include/linux/key-type.h |2 +-
 include/linux/key.h  |7 ---
 security/keys/gc.c   |   20 ++--
 security/keys/internal.h |8 
 security/keys/key.c  |   27 ++-
 security/keys/keyring.c  |   18 +-
 security/keys/permission.c   |3 +--
 security/keys/proc.c |   20 ++--
 security/keys/process_keys.c |2 +-
 9 files changed, 50 insertions(+), 57 deletions(-)

-- 
1.7.9.5

Re: [RFC][PATCH v2 7/7] checkpatch: add pF/pf deprecation warning

[Joe Perches]

On Thu, 2017-09-21 at 09:27 +0900, Sergey Senozhatsky wrote:
> On (09/20/17 10:38), Joe Perches wrote:
> > On Thu, 2017-09-21 at 01:29 +0900, Sergey Senozhatsky wrote:
> > > We deprecated '%pF/%pf' printk specifiers, since '%pS/%ps' is now smart
> > > enough to handle function pointer dereference on platforms where such
> > > dereference is required.
> > > 
> > > checkpatch warning example:
> > > 
> > > WARNING: Use '%pS/%ps' instead. This pointer extension was deprecated: 
> > > '%pF'
> > 
> > If this series is accepted,  I think this message
> > is unclear and would prefer something like:
> 
> sure, can tweak the patch.
> 
> [..]
> >     if ($bad_extension ne "") {
> >     my $stat_real = raw_line($linenr, 0);
> > +   my $ext_type = "Invalid";
> > +   my $use = "";
> >     for (my $count = $linenr + 1; $count <= $lc; 
> > $count++) {
> >     $stat_real = $stat_real . "\n" . 
> > raw_line($count, 0);
> >     }
> > +   if ($bad_extension =~ /p[Ff]/i) {
> 
>   I think /i is not necessary here

You are right, it's not.

Re: [RFC][PATCH v2 7/7] checkpatch: add pF/pf deprecation warning

[Joe Perches]

On Thu, 2017-09-21 at 09:27 +0900, Sergey Senozhatsky wrote:
> On (09/20/17 10:38), Joe Perches wrote:
> > On Thu, 2017-09-21 at 01:29 +0900, Sergey Senozhatsky wrote:
> > > We deprecated '%pF/%pf' printk specifiers, since '%pS/%ps' is now smart
> > > enough to handle function pointer dereference on platforms where such
> > > dereference is required.
> > > 
> > > checkpatch warning example:
> > > 
> > > WARNING: Use '%pS/%ps' instead. This pointer extension was deprecated: 
> > > '%pF'
> > 
> > If this series is accepted,  I think this message
> > is unclear and would prefer something like:
> 
> sure, can tweak the patch.
> 
> [..]
> >     if ($bad_extension ne "") {
> >     my $stat_real = raw_line($linenr, 0);
> > +   my $ext_type = "Invalid";
> > +   my $use = "";
> >     for (my $count = $linenr + 1; $count <= $lc; 
> > $count++) {
> >     $stat_real = $stat_real . "\n" . 
> > raw_line($count, 0);
> >     }
> > +   if ($bad_extension =~ /p[Ff]/i) {
> 
>   I think /i is not necessary here

You are right, it's not.

Re: [RFC RESEND 3/3] arm: dts: add Hi3521A dts

[Marty E. Plummer]

On Thu, Sep 21, 2017 at 01:08:39AM +, Rob Herring wrote:
> On Wed, Sep 20, 2017 at 6:04 PM, Marty E. Plummer
>  wrote:
> > On Wed, Sep 20, 2017 at 08:53:03PM +, Rob Herring wrote:
> >> On Sun, Sep 17, 2017 at 03:23:27AM -0500, Marty E. Plummer wrote:
> >> > Add hi3521a.dtsi and hi3521a-rs-dm290e.dts for RaySharp CCTV systems,
> >> > marketed under the name Samsung SDR-B74301N
> >> >
> >> > Signed-off-by: Marty E. Plummer 
> >> > ---
> >> >  arch/arm/boot/dts/Makefile  |   2 +
> >> >  arch/arm/boot/dts/hi3521a-rs-dm290e.dts |  52 ++
> >> >  arch/arm/boot/dts/hi3521a.dtsi  | 310 
> >> > 
> >> >  3 files changed, 364 insertions(+)
> >> >  create mode 100644 arch/arm/boot/dts/hi3521a-rs-dm290e.dts
> >> >  create mode 100644 arch/arm/boot/dts/hi3521a.dtsi
> >> >
> >> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> >> > index faf46abaa4a2..e7b9b5dde20f 100644
> >> > --- a/arch/arm/boot/dts/Makefile
> >> > +++ b/arch/arm/boot/dts/Makefile
> >> > @@ -189,6 +189,8 @@ dtb-$(CONFIG_ARCH_GEMINI) += \
> >> > gemini-sq201.dtb \
> >> > gemini-wbd111.dtb \
> >> > gemini-wbd222.dtb
> >> > +dtb-$(CONFIG_ARCH_HI3521A) += \
> >> > +   hi3521a-rs-dm290e.dtb
> >> >  dtb-$(CONFIG_ARCH_HI3xxx) += \
> >> > hi3620-hi4511.dtb
> >> >  dtb-$(CONFIG_ARCH_HIGHBANK) += \
> >> > diff --git a/arch/arm/boot/dts/hi3521a-rs-dm290e.dts 
> >> > b/arch/arm/boot/dts/hi3521a-rs-dm290e.dts
> >> > new file mode 100644
> >> > index ..b32c8392c93f
> >> > --- /dev/null
> >> > +++ b/arch/arm/boot/dts/hi3521a-rs-dm290e.dts
> >> > @@ -0,0 +1,52 @@
> >> > +/*
> >> > + * Copyright (C) 2017 Marty Plummer 
> >> > + *
> >> > + * This program is free software: you can redistribute it and/or modify
> >> > + * it under the terms of the GNU General Public License as published by
> >> > + * the Free Software Foundation, either version 3 of the License, or
> >> > + * (at your option) any later version.
> >>
> >> Should be version 2 or later? Doesn't really matter to me from a DT
> >> perspective, but it is in the kernel tree.
> >>
> >> You can use SPDX tags if you want.
> >>
> > Oh, that's a good idea. I hadn't seen any SPDX tags in the tree that I
> > noticed before. I ended up just using the :Gpl command from neovim.
> >> > + *
> >> > + * This program is distributed in the hope that it will be useful,
> >> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >> > + * GNU General Public License for more details.
> >> > + *
> >> > + * You should have received a copy of the GNU General Public License
> >> > + * along with this program.  If not, see .
> >> > + */
> >> > +
> >> > +/dts-v1/;
> >> > +#include "hi3521a.dtsi"
> >> > +
> >> > +/ {
> >> > +   model = "RaySharp RS-DM-290E DVR Board";
> >> > +   compatible = "hisilicon,hi3521a";
> >>
> >> Needs a board compatible too.
> >>
> > Something like `compatible = "hisilicon,hi3521a", "raysharp,rs-dm-290e";` ?
> 
> Yes, but flip the order. Most specific compatible first.
> 
> >> > +
> >> > +   aliases {
> >> > +   serial0 = 
> >> > +   serial1 = 
> >> > +   serial2 = 
> >> > +   };
> >> > +
> >> > +   memory {
> >>
> >> Needs a unit-address.
> >>
> > Could you explain what you mean here? As in, memory@someaddr? What would
> > I use here?
> 
> "memory@8000". Building with W=2 will tell you.
> 
Ah, nice trick. Suppose that makes sense, as every other thing was the
same on that sort of thing. Not sure if I've ever seen memory@addr
before.
> >> > +   device_type = "memory";
> >> > +   reg = <0x8000 0xf0>;
> >> > +   };
> >> > +};
> >> > +
> >> > +_sfc {
> >> > +   status = "okay";
> >> > +   spi-nor@0 {
> >> > +   compatible = "jedec,spi-nor";
> >>
> >> I don't remember offhand, but I think this should have a device specific
> >> compatible too.
> >>
> > Instead of "jedec,spi-nor" ? Specific to the SPI chip?
> 
> No, both with jedec,spi-nor 2nd.
> 
Gotcha, will fix it up.
> >> > +   reg = <0>;
> >> > +   spi-max-frequency = <10400>;
> >> > +   };
> >> > +};
> >> > +
> >> > + {
> >> > +   status = "okay";
> >> > +};
> >> > +
> >> > +_timer0 {
> >> > +   status = "okay";
> >> > +};
> >> > diff --git a/arch/arm/boot/dts/hi3521a.dtsi 
> >> > b/arch/arm/boot/dts/hi3521a.dtsi
> >> > new file mode 100644
> >> > index ..2af746fdec46
> >> > --- /dev/null
> >> > +++ b/arch/arm/boot/dts/hi3521a.dtsi
> >> > @@ -0,0 +1,310 @@
> >> > +/*
> >> > + * Copyright (C) 2017 Marty Plummer 
> >> > + *
> >> > + * This program is free software: you can redistribute it and/or modify
> >> > + * it under the terms of the GNU General Public License as published by
> >> > + * the Free Software Foundation, either version 3 of the 

Re: [RFC RESEND 3/3] arm: dts: add Hi3521A dts

[Marty E. Plummer]

On Thu, Sep 21, 2017 at 01:08:39AM +, Rob Herring wrote:
> On Wed, Sep 20, 2017 at 6:04 PM, Marty E. Plummer
>  wrote:
> > On Wed, Sep 20, 2017 at 08:53:03PM +, Rob Herring wrote:
> >> On Sun, Sep 17, 2017 at 03:23:27AM -0500, Marty E. Plummer wrote:
> >> > Add hi3521a.dtsi and hi3521a-rs-dm290e.dts for RaySharp CCTV systems,
> >> > marketed under the name Samsung SDR-B74301N
> >> >
> >> > Signed-off-by: Marty E. Plummer 
> >> > ---
> >> >  arch/arm/boot/dts/Makefile  |   2 +
> >> >  arch/arm/boot/dts/hi3521a-rs-dm290e.dts |  52 ++
> >> >  arch/arm/boot/dts/hi3521a.dtsi  | 310 
> >> > 
> >> >  3 files changed, 364 insertions(+)
> >> >  create mode 100644 arch/arm/boot/dts/hi3521a-rs-dm290e.dts
> >> >  create mode 100644 arch/arm/boot/dts/hi3521a.dtsi
> >> >
> >> > diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> >> > index faf46abaa4a2..e7b9b5dde20f 100644
> >> > --- a/arch/arm/boot/dts/Makefile
> >> > +++ b/arch/arm/boot/dts/Makefile
> >> > @@ -189,6 +189,8 @@ dtb-$(CONFIG_ARCH_GEMINI) += \
> >> > gemini-sq201.dtb \
> >> > gemini-wbd111.dtb \
> >> > gemini-wbd222.dtb
> >> > +dtb-$(CONFIG_ARCH_HI3521A) += \
> >> > +   hi3521a-rs-dm290e.dtb
> >> >  dtb-$(CONFIG_ARCH_HI3xxx) += \
> >> > hi3620-hi4511.dtb
> >> >  dtb-$(CONFIG_ARCH_HIGHBANK) += \
> >> > diff --git a/arch/arm/boot/dts/hi3521a-rs-dm290e.dts 
> >> > b/arch/arm/boot/dts/hi3521a-rs-dm290e.dts
> >> > new file mode 100644
> >> > index ..b32c8392c93f
> >> > --- /dev/null
> >> > +++ b/arch/arm/boot/dts/hi3521a-rs-dm290e.dts
> >> > @@ -0,0 +1,52 @@
> >> > +/*
> >> > + * Copyright (C) 2017 Marty Plummer 
> >> > + *
> >> > + * This program is free software: you can redistribute it and/or modify
> >> > + * it under the terms of the GNU General Public License as published by
> >> > + * the Free Software Foundation, either version 3 of the License, or
> >> > + * (at your option) any later version.
> >>
> >> Should be version 2 or later? Doesn't really matter to me from a DT
> >> perspective, but it is in the kernel tree.
> >>
> >> You can use SPDX tags if you want.
> >>
> > Oh, that's a good idea. I hadn't seen any SPDX tags in the tree that I
> > noticed before. I ended up just using the :Gpl command from neovim.
> >> > + *
> >> > + * This program is distributed in the hope that it will be useful,
> >> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> >> > + * GNU General Public License for more details.
> >> > + *
> >> > + * You should have received a copy of the GNU General Public License
> >> > + * along with this program.  If not, see .
> >> > + */
> >> > +
> >> > +/dts-v1/;
> >> > +#include "hi3521a.dtsi"
> >> > +
> >> > +/ {
> >> > +   model = "RaySharp RS-DM-290E DVR Board";
> >> > +   compatible = "hisilicon,hi3521a";
> >>
> >> Needs a board compatible too.
> >>
> > Something like `compatible = "hisilicon,hi3521a", "raysharp,rs-dm-290e";` ?
> 
> Yes, but flip the order. Most specific compatible first.
> 
> >> > +
> >> > +   aliases {
> >> > +   serial0 = 
> >> > +   serial1 = 
> >> > +   serial2 = 
> >> > +   };
> >> > +
> >> > +   memory {
> >>
> >> Needs a unit-address.
> >>
> > Could you explain what you mean here? As in, memory@someaddr? What would
> > I use here?
> 
> "memory@8000". Building with W=2 will tell you.
> 
Ah, nice trick. Suppose that makes sense, as every other thing was the
same on that sort of thing. Not sure if I've ever seen memory@addr
before.
> >> > +   device_type = "memory";
> >> > +   reg = <0x8000 0xf0>;
> >> > +   };
> >> > +};
> >> > +
> >> > +_sfc {
> >> > +   status = "okay";
> >> > +   spi-nor@0 {
> >> > +   compatible = "jedec,spi-nor";
> >>
> >> I don't remember offhand, but I think this should have a device specific
> >> compatible too.
> >>
> > Instead of "jedec,spi-nor" ? Specific to the SPI chip?
> 
> No, both with jedec,spi-nor 2nd.
> 
Gotcha, will fix it up.
> >> > +   reg = <0>;
> >> > +   spi-max-frequency = <10400>;
> >> > +   };
> >> > +};
> >> > +
> >> > + {
> >> > +   status = "okay";
> >> > +};
> >> > +
> >> > +_timer0 {
> >> > +   status = "okay";
> >> > +};
> >> > diff --git a/arch/arm/boot/dts/hi3521a.dtsi 
> >> > b/arch/arm/boot/dts/hi3521a.dtsi
> >> > new file mode 100644
> >> > index ..2af746fdec46
> >> > --- /dev/null
> >> > +++ b/arch/arm/boot/dts/hi3521a.dtsi
> >> > @@ -0,0 +1,310 @@
> >> > +/*
> >> > + * Copyright (C) 2017 Marty Plummer 
> >> > + *
> >> > + * This program is free software: you can redistribute it and/or modify
> >> > + * it under the terms of the GNU General Public License as published by
> >> > + * the Free Software Foundation, either version 3 of the License, or
> >> > + * (at your option) any later version.
> >> > + *
> >> > + * This program is 

RE: [PATCH 1/7] PM / OPP: Add platform specific set_clk function

[A.s. Dong]

> -Original Message-
> From: Viresh Kumar [mailto:viresh.ku...@linaro.org]
> Sent: Thursday, September 21, 2017 4:31 AM
> To: Dong Aisheng
> Cc: A.s. Dong; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; sb...@codeaurora.org;
> vire...@kernel.org; n...@ti.com; r...@rjwysocki.net; shawn...@kernel.org;
> Anson Huang; Jacky Bai
> Subject: Re: [PATCH 1/7] PM / OPP: Add platform specific set_clk function
> 
> On 20-09-17, 15:03, Dong Aisheng wrote:
> > I've been thinking of that before.
> > Actually IMX already does some similar thing for MX5 (no for MX6).
> > See: clk_cpu_set_rate() in drivers/clk/imx/clk-cpu.c.
> >
> > After some diggings, it seems MX7ULP is a bit more complicated than
> > before mainly due to two reasons:
> > 1) It requires to switch to different CPU mode accordingly when
> > setting clocks rate. That means we need handle this in clock driver as
> > well which looks not quite suitable although we could do if really want.
> >
> > 2) It uses different clocks for different CPU mode (RUN 416M or HSRUN
> > 528M), and those clocks have some dependency.
> > e.g. when setting HSRUN clock, we need change RUN clock parent to make
> > sure the SPLL_PFD is got disabled before changing rate, as both CPU
> > mode using the same parent SPLL_PFD clock. Doing this in clock driver
> > also make things a bit more complicated.
> >
> > The whole follow would be something like below:
> > static int imx7ulp_set_clk(struct device *dev, struct clk *clk,
> >unsigned long old_freq, unsigned long
> > new_freq) {
> > u32 val;
> >
> > /*
> >  * Before changing the ARM core PLL, change the ARM clock soure
> >  * to FIRC first.
> >  */
> > if (new_freq >= HSRUN_FREQ) {
> > clk_set_parent(clks[RUN_SCS_SEL].clk, clks[FIRC].clk);
> >
> > /* switch to HSRUN mode */
> > val = readl_relaxed(smc_base + SMC_PMCTRL);
> > val |= (0x3 << 8);
> > writel_relaxed(val, smc_base + SMC_PMCTRL);
> >
> > /* change the clock rate in HSRUN */
> > clk_set_rate(clks[SPLL_PFD0].clk, new_freq);
> > clk_set_parent(clks[HSRUN_SCS_SEL].clk,
> clks[SPLL_SEL].clk);
> > } else {
> > /* change the HSRUN clock to firc */
> > clk_set_parent(clks[HSRUN_SCS_SEL].clk,
> > clks[FIRC].clk);
> >
> > /* switch to RUN mode */
> > val = readl_relaxed(smc_base + SMC_PMCTRL);
> > val &= ~(0x3 << 8);
> > writel_relaxed(val, smc_base + SMC_PMCTRL);
> >
> > clk_set_rate(clks[SPLL_PFD0].clk, new_freq);
> > clk_set_parent(clks[RUN_SCS_SEL].clk,
> clks[SPLL_SEL].clk);
> > }
> >
> > return 0;
> > }
> 
> Right and we have the same thing in the cpufreq driver now. It will stay
> at some place and we need to find the best one, keeping in mind that we
> may or may not want to solve this problem in a generic way.
> 
> > That's why i thought if we can make OPP core provide a way to handle
> > such complicated things in platform specific cpufreq driver.
> >
> > How would you suggest for this issue?
> 
> I wouldn't add an API into the OPP framework if I were you. There is just
> too much code to add to the core to handle such platform specific stuff,
> which you are anyway going to keep somewhere as it is. IMHO, keeping that
> in the clock driver is a better thing to do than this.
> 

Okay, I will give a try in CLK driver.
Thanks for the suggestion.

Regards
Dong Aisheng

> --
> viresh

RE: [PATCH 1/7] PM / OPP: Add platform specific set_clk function

[A.s. Dong]

> -Original Message-
> From: Viresh Kumar [mailto:viresh.ku...@linaro.org]
> Sent: Thursday, September 21, 2017 4:31 AM
> To: Dong Aisheng
> Cc: A.s. Dong; linux...@vger.kernel.org; linux-kernel@vger.kernel.org;
> linux-arm-ker...@lists.infradead.org; sb...@codeaurora.org;
> vire...@kernel.org; n...@ti.com; r...@rjwysocki.net; shawn...@kernel.org;
> Anson Huang; Jacky Bai
> Subject: Re: [PATCH 1/7] PM / OPP: Add platform specific set_clk function
> 
> On 20-09-17, 15:03, Dong Aisheng wrote:
> > I've been thinking of that before.
> > Actually IMX already does some similar thing for MX5 (no for MX6).
> > See: clk_cpu_set_rate() in drivers/clk/imx/clk-cpu.c.
> >
> > After some diggings, it seems MX7ULP is a bit more complicated than
> > before mainly due to two reasons:
> > 1) It requires to switch to different CPU mode accordingly when
> > setting clocks rate. That means we need handle this in clock driver as
> > well which looks not quite suitable although we could do if really want.
> >
> > 2) It uses different clocks for different CPU mode (RUN 416M or HSRUN
> > 528M), and those clocks have some dependency.
> > e.g. when setting HSRUN clock, we need change RUN clock parent to make
> > sure the SPLL_PFD is got disabled before changing rate, as both CPU
> > mode using the same parent SPLL_PFD clock. Doing this in clock driver
> > also make things a bit more complicated.
> >
> > The whole follow would be something like below:
> > static int imx7ulp_set_clk(struct device *dev, struct clk *clk,
> >unsigned long old_freq, unsigned long
> > new_freq) {
> > u32 val;
> >
> > /*
> >  * Before changing the ARM core PLL, change the ARM clock soure
> >  * to FIRC first.
> >  */
> > if (new_freq >= HSRUN_FREQ) {
> > clk_set_parent(clks[RUN_SCS_SEL].clk, clks[FIRC].clk);
> >
> > /* switch to HSRUN mode */
> > val = readl_relaxed(smc_base + SMC_PMCTRL);
> > val |= (0x3 << 8);
> > writel_relaxed(val, smc_base + SMC_PMCTRL);
> >
> > /* change the clock rate in HSRUN */
> > clk_set_rate(clks[SPLL_PFD0].clk, new_freq);
> > clk_set_parent(clks[HSRUN_SCS_SEL].clk,
> clks[SPLL_SEL].clk);
> > } else {
> > /* change the HSRUN clock to firc */
> > clk_set_parent(clks[HSRUN_SCS_SEL].clk,
> > clks[FIRC].clk);
> >
> > /* switch to RUN mode */
> > val = readl_relaxed(smc_base + SMC_PMCTRL);
> > val &= ~(0x3 << 8);
> > writel_relaxed(val, smc_base + SMC_PMCTRL);
> >
> > clk_set_rate(clks[SPLL_PFD0].clk, new_freq);
> > clk_set_parent(clks[RUN_SCS_SEL].clk,
> clks[SPLL_SEL].clk);
> > }
> >
> > return 0;
> > }
> 
> Right and we have the same thing in the cpufreq driver now. It will stay
> at some place and we need to find the best one, keeping in mind that we
> may or may not want to solve this problem in a generic way.
> 
> > That's why i thought if we can make OPP core provide a way to handle
> > such complicated things in platform specific cpufreq driver.
> >
> > How would you suggest for this issue?
> 
> I wouldn't add an API into the OPP framework if I were you. There is just
> too much code to add to the core to handle such platform specific stuff,
> which you are anyway going to keep somewhere as it is. IMHO, keeping that
> in the clock driver is a better thing to do than this.
> 

Okay, I will give a try in CLK driver.
Thanks for the suggestion.

Regards
Dong Aisheng

> --
> viresh

Re: [PATCH 2/5] nvmem: mtk-efuse: use stack for nvmem_config instead of malloc'ing it

[Masahiro Yamada]

Hi Sean,


2017-09-21 1:32 GMT+09:00 Sean Wang :
> Hi, Masahiro
>
> For maintainability, I felt it's better if we use the same way to
> register nvmem as that most drivers does under nvmem usually using
> static structure. Otherwise, they should also be changed to use the
> one-time data in stack to avoid extra bytes to keep them.
>
> Sean


Srinivas and I discussed the best practice for allocating nvmem_config.
https://lkml.org/lkml/2017/9/11/4

>From the discussion, static structure is possible only when
the system has one instance of the device.

If you know this is the case for mediatek,
yes, you can turn it into static,
but it is not always possible.
For example, Socionext SoCs have
two banks of efuse devices.

So, if we want to align the coding style for consistency,
nvmem in stack is safe and efficient, I think.


Moving one-time data into stack slightly
reduces the kernel image size.


-- 
Best Regards
Masahiro Yamada

Re: [PATCH 2/5] nvmem: mtk-efuse: use stack for nvmem_config instead of malloc'ing it

[Masahiro Yamada]

Hi Sean,


2017-09-21 1:32 GMT+09:00 Sean Wang :
> Hi, Masahiro
>
> For maintainability, I felt it's better if we use the same way to
> register nvmem as that most drivers does under nvmem usually using
> static structure. Otherwise, they should also be changed to use the
> one-time data in stack to avoid extra bytes to keep them.
>
> Sean


Srinivas and I discussed the best practice for allocating nvmem_config.
https://lkml.org/lkml/2017/9/11/4

>From the discussion, static structure is possible only when
the system has one instance of the device.

If you know this is the case for mediatek,
yes, you can turn it into static,
but it is not always possible.
For example, Socionext SoCs have
two banks of efuse devices.

So, if we want to align the coding style for consistency,
nvmem in stack is safe and efficient, I think.


Moving one-time data into stack slightly
reduces the kernel image size.


-- 
Best Regards
Masahiro Yamada

Re: 4.13 breaks suspend to ram wakeup

[Norbert Preining]

Hi Ming,

> So could you share us how often it is triggered? and what is your underlying
> disk behind dm-crypt?

It is triggered *every* time I suspend.
Underlying disk is 
scsi 1:0:0:0: Direct-Access ATA  WDC WD10JPVX-08J 1A07 PQ: 0 ANSI: 5

I checked the values in 
/sys/block/dm-?/dm/use_blk_mq
and they are all set to 0.

> BTW, you can debug and collect some dmesg log during system suspend/resume
> without serial console:

I will try that tonight, now I am at work.

> Please get the patches backported to v4.13 in the following tree:

Thanks

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: 4.13 breaks suspend to ram wakeup

[Norbert Preining]

Hi Ming,

> So could you share us how often it is triggered? and what is your underlying
> disk behind dm-crypt?

It is triggered *every* time I suspend.
Underlying disk is 
scsi 1:0:0:0: Direct-Access ATA  WDC WD10JPVX-08J 1A07 PQ: 0 ANSI: 5

I checked the values in 
/sys/block/dm-?/dm/use_blk_mq
and they are all set to 0.

> BTW, you can debug and collect some dmesg log during system suspend/resume
> without serial console:

I will try that tonight, now I am at work.

> Please get the patches backported to v4.13 in the following tree:

Thanks

Norbert

--
PREINING Norbert   http://www.preining.info
Accelia Inc. +JAIST +TeX Live +Debian Developer
GPG: 0x860CDC13   fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13

Re: [Patch v3 1/3] ipv4: Namespaceify tcp_fastopen knob

[严海双]

> On 2017年9月21日, at 上午5:22, David Miller  wrote:
> 
> From: Haishuang Yan 
> Date: Tue, 19 Sep 2017 17:38:14 +0800
> 
>> -if ((sysctl_tcp_fastopen & TFO_SERVER_WO_SOCKOPT1) &&
>> -(sysctl_tcp_fastopen & TFO_SERVER_ENABLE) &&
>> +tcp_fastopen =  sock_net(sk)->ipv4.sysctl_tcp_fastopen;
>  ^^
> 
> Please change that to one space.
> 
> And also please provide an appropriate "[PATCH vX 0/3] " header
> posting when you respin this series.

Sorry, it’s my mistake, thanks David.
> 
>> @@ -282,18 +280,19 @@ struct sock *tcp_try_fastopen(struct sock *sk, struct 
>> sk_buff *skb,
>>  struct tcp_fastopen_cookie valid_foc = { .len = -1 };
>>  bool syn_data = TCP_SKB_CB(skb)->end_seq != TCP_SKB_CB(skb)->seq + 1;
>>  struct sock *child;
>> +int tcp_fastopen = sock_net(sk)->ipv4.sysctl_tcp_fastopen;
> 
> Please order local variables from longest to shortest line (aka. reverse
> christmas tree format).
> 

Okay, I’ll take care of such coding style in next commit, thanks!

Re: [Patch v3 1/3] ipv4: Namespaceify tcp_fastopen knob

[严海双]

> On 2017年9月21日, at 上午5:22, David Miller  wrote:
> 
> From: Haishuang Yan 
> Date: Tue, 19 Sep 2017 17:38:14 +0800
> 
>> -if ((sysctl_tcp_fastopen & TFO_SERVER_WO_SOCKOPT1) &&
>> -(sysctl_tcp_fastopen & TFO_SERVER_ENABLE) &&
>> +tcp_fastopen =  sock_net(sk)->ipv4.sysctl_tcp_fastopen;
>  ^^
> 
> Please change that to one space.
> 
> And also please provide an appropriate "[PATCH vX 0/3] " header
> posting when you respin this series.

Sorry, it’s my mistake, thanks David.
> 
>> @@ -282,18 +280,19 @@ struct sock *tcp_try_fastopen(struct sock *sk, struct 
>> sk_buff *skb,
>>  struct tcp_fastopen_cookie valid_foc = { .len = -1 };
>>  bool syn_data = TCP_SKB_CB(skb)->end_seq != TCP_SKB_CB(skb)->seq + 1;
>>  struct sock *child;
>> +int tcp_fastopen = sock_net(sk)->ipv4.sysctl_tcp_fastopen;
> 
> Please order local variables from longest to shortest line (aka. reverse
> christmas tree format).
> 

Okay, I’ll take care of such coding style in next commit, thanks!

[PATCH v2] mmc: dt-bindings: Add reg/source_cg/latch-ck for Mediatek MMC bindings

[Chaotian Jing]

Change the comptiable for support of multi-platform
Add description for reg
Add description for source_cg
Add description for mediatek,latch-ck
Note that source_cg and mediatek,latch-ck are optional for some projects,
eg, MT2701 do not have source_cg, and MT2712 do not need
mediatek,latch-ck

Signed-off-by: Chaotian Jing 
---
 Documentation/devicetree/bindings/mmc/mtk-sd.txt | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt 
b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
index 4182ea3..405cd06 100644
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
@@ -7,10 +7,15 @@ This file documents differences between the core properties 
in mmc.txt
 and the properties used by the msdc driver.
 
 Required properties:
-- compatible: Should be "mediatek,mt8173-mmc","mediatek,mt8135-mmc"
+- compatible: value should be either of the following.
+   "mediatek,mt8135-mmc": for mmc host ip compatible with mt8135
+   "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173
+   "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701
+   "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712
+- reg: physical base address of the controller and length
 - interrupts: Should contain MSDC interrupt number
-- clocks: MSDC source clock, HCLK
-- clock-names: "source", "hclk"
+- clocks: MSDC source clock, HCLK, source_cg
+- clock-names: "source", "hclk", "source_cg"
 - pinctrl-names: should be "default", "state_uhs"
 - pinctrl-0: should contain default/high speed pin ctrl
 - pinctrl-1: should contain uhs mode pin ctrl
@@ -30,6 +35,8 @@ Optional properties:
 - mediatek,hs400-cmd-resp-sel-rising:  HS400 command response sample selection
   If present,HS400 command responses are 
sampled on rising edges.
   If not present,HS400 command responses 
are sampled on falling edges.
+- mediatek,latch-ck: Some projects do not support enhance_rx, need set correct 
latch-ck to avoid data crc
+error caused by stop clock(fifo full)
 
 Examples:
 mmc0: mmc@1123 {
-- 
1.8.1.1.dirty

[PATCH v2] mmc: dt-bindings: Add reg/source_cg/latch-ck for Mediatek MMC bindings

[Chaotian Jing]

Change the comptiable for support of multi-platform
Add description for reg
Add description for source_cg
Add description for mediatek,latch-ck
Note that source_cg and mediatek,latch-ck are optional for some projects,
eg, MT2701 do not have source_cg, and MT2712 do not need
mediatek,latch-ck

Signed-off-by: Chaotian Jing 
---
 Documentation/devicetree/bindings/mmc/mtk-sd.txt | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.txt 
b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
index 4182ea3..405cd06 100644
--- a/Documentation/devicetree/bindings/mmc/mtk-sd.txt
+++ b/Documentation/devicetree/bindings/mmc/mtk-sd.txt
@@ -7,10 +7,15 @@ This file documents differences between the core properties 
in mmc.txt
 and the properties used by the msdc driver.
 
 Required properties:
-- compatible: Should be "mediatek,mt8173-mmc","mediatek,mt8135-mmc"
+- compatible: value should be either of the following.
+   "mediatek,mt8135-mmc": for mmc host ip compatible with mt8135
+   "mediatek,mt8173-mmc": for mmc host ip compatible with mt8173
+   "mediatek,mt2701-mmc": for mmc host ip compatible with mt2701
+   "mediatek,mt2712-mmc": for mmc host ip compatible with mt2712
+- reg: physical base address of the controller and length
 - interrupts: Should contain MSDC interrupt number
-- clocks: MSDC source clock, HCLK
-- clock-names: "source", "hclk"
+- clocks: MSDC source clock, HCLK, source_cg
+- clock-names: "source", "hclk", "source_cg"
 - pinctrl-names: should be "default", "state_uhs"
 - pinctrl-0: should contain default/high speed pin ctrl
 - pinctrl-1: should contain uhs mode pin ctrl
@@ -30,6 +35,8 @@ Optional properties:
 - mediatek,hs400-cmd-resp-sel-rising:  HS400 command response sample selection
   If present,HS400 command responses are 
sampled on rising edges.
   If not present,HS400 command responses 
are sampled on falling edges.
+- mediatek,latch-ck: Some projects do not support enhance_rx, need set correct 
latch-ck to avoid data crc
+error caused by stop clock(fifo full)
 
 Examples:
 mmc0: mmc@1123 {
-- 
1.8.1.1.dirty

Re: [REGRESSION] Warning in tcp_fastretrans_alert() of net/ipv4/tcp_input.c

[Roman Gushchin]

> Hello.
>
> Since, IIRC, v4.11, there is some regression in TCP stack resulting in the 
> warning shown below. Most of the time it is harmless, but rarely it just 
> causes either freeze or (I believe, this is related too) panic in 
> tcp_sacktag_walk() (because sk_buff passed to this function is NULL). 
> Unfortunately, I still do not have proper stacktrace from panic, but will try 
> to capture it if possible.
> 
> Also, I have custom settings regarding TCP stack, shown below as well. ifb is 
> used to shape traffic with tc.
> 
> Please note this regression was already reported as BZ [1] and as a letter to 
> ML [2], but got neither attention nor resolution. It is reproducible for (not 
> only) me on my home router since v4.11 till v4.13.1 incl.
> 
> Please advise on how to deal with it. I'll provide any additional info if 
> necessary, also ready to test patches if any.
> 
> Thanks.
> 
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=195835
> [2] https://www.spinics.net/lists/netdev/msg436158.html

We're experiencing the same problems on some machines in our fleet.
Exactly the same symptoms: tcp_fastretrans_alert() warnings and
sometimes panics in tcp_sacktag_walk().

Here is an example of a backtrace with the panic log:

978.210080]  fuse
[973978.214099]  sg
[973978.217789]  loop
[973978.221829]  efivarfs
[973978.226544]  autofs4
[973978.231109] CPU: 12 PID: 3806320 Comm: ld:srv:W20 Tainted: GW   
4.11.3-7_fbk1_1174_ga56eebf #7
[973978.250563] Hardware name: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM06   
10/28/2016
[973978.266558] Call Trace:
[973978.271615]  
[973978.275817]  dump_stack+0x4d/0x70
[973978.282626]  __warn+0xd3/0xf0
[973978.288727]  warn_slowpath_null+0x1e/0x20
[973978.296910]  tcp_fastretrans_alert+0xacf/0xbd0
[973978.305974]  tcp_ack+0xbce/0x1390
[973978.312770]  tcp_rcv_established+0x1ce/0x740
[973978.321488]  tcp_v6_do_rcv+0x195/0x440
[973978.329166]  tcp_v6_rcv+0x94c/0x9f0
[973978.336323]  ip6_input_finish+0xea/0x430
[973978.344330]  ip6_input+0x32/0xa0
[973978.350968]  ? ip6_rcv_finish+0xa0/0xa0
[973978.358799]  ip6_rcv_finish+0x4b/0xa0
[973978.366289]  ipv6_rcv+0x2ec/0x4f0
[973978.373082]  ? ip6_make_skb+0x1c0/0x1c0
[973978.380919]  __netif_receive_skb_core+0x2d5/0x9a0
[973978.390505]  __netif_receive_skb+0x16/0x70
[973978.398875]  netif_receive_skb_internal+0x23/0x80
[973978.408462]  napi_gro_receive+0x113/0x1d0
[973978.416657]  mlx5e_handle_rx_cqe_mpwrq+0x5b6/0x8d0
[973978.426398]  mlx5e_poll_rx_cq+0x7c/0x7f0
[973978.434405]  mlx5e_napi_poll+0x8c/0x380
[973978.442238]  ? mlx5_cq_completion+0x54/0xb0
[973978.450770]  net_rx_action+0x22e/0x380
[973978.458447]  __do_softirq+0x106/0x2e8
[973978.465950]  irq_exit+0xb0/0xc0
[973978.472396]  do_IRQ+0x4f/0xd0
[973978.478495]  common_interrupt+0x86/0x86
[973978.486329] RIP: 0033:0x7f8dee58d8ae
[973978.493642] RSP: 002b:7f8cb925f078 EFLAGS: 0206
[973978.504251]  ORIG_RAX: ff5f
[973978.512085] RAX: 7f8cb925f1a8 RBX: 4800 RCX: 
7f8764bd6a80
[973978.526508] RDX: 01ba RSI: 7f7cb4ca3410 RDI: 
7f7cb4ca3410
[973978.540927] RBP: 000d R08: 7f8764bd6b00 R09: 
7f8764bd6b80
[973978.555347] R10: 2400 R11: 7f8dee58e240 R12: 
d3273c84146e8c29
[973978.569766] R13: 9dac83ddf04c235c R14: 7f7cb4ca33b0 R15: 
7f7cb4ca4f50
[973978.584189]  
[973978.588650] ---[ end trace 5d1c83e12a57d039 ]---
[973995.178183] BUG: unable to handle kernel 
[973995.186385] NULL pointer dereference
[973995.193692]  at 0028
[973995.200323] IP: tcp_sacktag_walk+0x2b7/0x460
[973995.209032] PGD 102d856067 
[973995.214789] PUD fded0d067 
[973995.220385] PMD 0 
[973995.224577] 
[973995.227732] [ cut here ]
[973995.237128] Oops:  [#1] SMP
[973995.243575] Modules linked in:
[973995.249868]  mptctl
[973995.254251]  mptbase
[973995.258792]  xt_DSCP
[973995.263331]  xt_set
[973995.267698]  ip_set_hash_ip
[973995.273452]  cls_u32
[973995.277993]  sch_sfq
[973995.282535]  cls_fw
[973995.286904]  sch_htb
[973995.291444]  mpt3sas
[973995.295982]  raid_class
[973995.301044]  ip6table_mangle
[973995.306973]  iptable_mangle
[973995.312726]  cls_bpf
[973995.317268]  tcp_diag
[973995.321983]  udp_diag
[973995.326697]  inet_diag
[973995.331585]  ip6table_filter
[973995.337513]  xt_NFLOG
[973995.342226]  nfnetlink_log
[973995.347807]  xt_comment
[973995.352866]  xt_statistic
[973995.358276]  iptable_filter
[973995.364029]  xt_mark
[973995.368572]  sb_edac
[973995.373113]  edac_core
[973995.378001]  x86_pkg_temp_thermal
[973995.384795]  intel_powerclamp
[973995.390897]  coretemp
[973995.395608]  kvm_intel
[973995.400498]  kvm
[973995.404345]  irqbypass
[973995.409235]  ses
[973995.413078]  iTCO_wdt
[973995.417794]  iTCO_vendor_support
[973995.424415]  enclosure
[973995.429301]  lpc_ich
[973995.433843]  scsi_transport_sas
[973995.440292]  mfd_core
[973995.445007]  efivars
[973995.449548]  ipmi_si
[973995.454087]  ipmi_devintf
[973995.459496]  

Re: [REGRESSION] Warning in tcp_fastretrans_alert() of net/ipv4/tcp_input.c

[Roman Gushchin]

> Hello.
>
> Since, IIRC, v4.11, there is some regression in TCP stack resulting in the 
> warning shown below. Most of the time it is harmless, but rarely it just 
> causes either freeze or (I believe, this is related too) panic in 
> tcp_sacktag_walk() (because sk_buff passed to this function is NULL). 
> Unfortunately, I still do not have proper stacktrace from panic, but will try 
> to capture it if possible.
> 
> Also, I have custom settings regarding TCP stack, shown below as well. ifb is 
> used to shape traffic with tc.
> 
> Please note this regression was already reported as BZ [1] and as a letter to 
> ML [2], but got neither attention nor resolution. It is reproducible for (not 
> only) me on my home router since v4.11 till v4.13.1 incl.
> 
> Please advise on how to deal with it. I'll provide any additional info if 
> necessary, also ready to test patches if any.
> 
> Thanks.
> 
> [1] https://bugzilla.kernel.org/show_bug.cgi?id=195835
> [2] https://www.spinics.net/lists/netdev/msg436158.html

We're experiencing the same problems on some machines in our fleet.
Exactly the same symptoms: tcp_fastretrans_alert() warnings and
sometimes panics in tcp_sacktag_walk().

Here is an example of a backtrace with the panic log:

978.210080]  fuse
[973978.214099]  sg
[973978.217789]  loop
[973978.221829]  efivarfs
[973978.226544]  autofs4
[973978.231109] CPU: 12 PID: 3806320 Comm: ld:srv:W20 Tainted: GW   
4.11.3-7_fbk1_1174_ga56eebf #7
[973978.250563] Hardware name: Wiwynn Leopard-Orv2/Leopard-DDR BW, BIOS LBM06   
10/28/2016
[973978.266558] Call Trace:
[973978.271615]  
[973978.275817]  dump_stack+0x4d/0x70
[973978.282626]  __warn+0xd3/0xf0
[973978.288727]  warn_slowpath_null+0x1e/0x20
[973978.296910]  tcp_fastretrans_alert+0xacf/0xbd0
[973978.305974]  tcp_ack+0xbce/0x1390
[973978.312770]  tcp_rcv_established+0x1ce/0x740
[973978.321488]  tcp_v6_do_rcv+0x195/0x440
[973978.329166]  tcp_v6_rcv+0x94c/0x9f0
[973978.336323]  ip6_input_finish+0xea/0x430
[973978.344330]  ip6_input+0x32/0xa0
[973978.350968]  ? ip6_rcv_finish+0xa0/0xa0
[973978.358799]  ip6_rcv_finish+0x4b/0xa0
[973978.366289]  ipv6_rcv+0x2ec/0x4f0
[973978.373082]  ? ip6_make_skb+0x1c0/0x1c0
[973978.380919]  __netif_receive_skb_core+0x2d5/0x9a0
[973978.390505]  __netif_receive_skb+0x16/0x70
[973978.398875]  netif_receive_skb_internal+0x23/0x80
[973978.408462]  napi_gro_receive+0x113/0x1d0
[973978.416657]  mlx5e_handle_rx_cqe_mpwrq+0x5b6/0x8d0
[973978.426398]  mlx5e_poll_rx_cq+0x7c/0x7f0
[973978.434405]  mlx5e_napi_poll+0x8c/0x380
[973978.442238]  ? mlx5_cq_completion+0x54/0xb0
[973978.450770]  net_rx_action+0x22e/0x380
[973978.458447]  __do_softirq+0x106/0x2e8
[973978.465950]  irq_exit+0xb0/0xc0
[973978.472396]  do_IRQ+0x4f/0xd0
[973978.478495]  common_interrupt+0x86/0x86
[973978.486329] RIP: 0033:0x7f8dee58d8ae
[973978.493642] RSP: 002b:7f8cb925f078 EFLAGS: 0206
[973978.504251]  ORIG_RAX: ff5f
[973978.512085] RAX: 7f8cb925f1a8 RBX: 4800 RCX: 
7f8764bd6a80
[973978.526508] RDX: 01ba RSI: 7f7cb4ca3410 RDI: 
7f7cb4ca3410
[973978.540927] RBP: 000d R08: 7f8764bd6b00 R09: 
7f8764bd6b80
[973978.555347] R10: 2400 R11: 7f8dee58e240 R12: 
d3273c84146e8c29
[973978.569766] R13: 9dac83ddf04c235c R14: 7f7cb4ca33b0 R15: 
7f7cb4ca4f50
[973978.584189]  
[973978.588650] ---[ end trace 5d1c83e12a57d039 ]---
[973995.178183] BUG: unable to handle kernel 
[973995.186385] NULL pointer dereference
[973995.193692]  at 0028
[973995.200323] IP: tcp_sacktag_walk+0x2b7/0x460
[973995.209032] PGD 102d856067 
[973995.214789] PUD fded0d067 
[973995.220385] PMD 0 
[973995.224577] 
[973995.227732] [ cut here ]
[973995.237128] Oops:  [#1] SMP
[973995.243575] Modules linked in:
[973995.249868]  mptctl
[973995.254251]  mptbase
[973995.258792]  xt_DSCP
[973995.263331]  xt_set
[973995.267698]  ip_set_hash_ip
[973995.273452]  cls_u32
[973995.277993]  sch_sfq
[973995.282535]  cls_fw
[973995.286904]  sch_htb
[973995.291444]  mpt3sas
[973995.295982]  raid_class
[973995.301044]  ip6table_mangle
[973995.306973]  iptable_mangle
[973995.312726]  cls_bpf
[973995.317268]  tcp_diag
[973995.321983]  udp_diag
[973995.326697]  inet_diag
[973995.331585]  ip6table_filter
[973995.337513]  xt_NFLOG
[973995.342226]  nfnetlink_log
[973995.347807]  xt_comment
[973995.352866]  xt_statistic
[973995.358276]  iptable_filter
[973995.364029]  xt_mark
[973995.368572]  sb_edac
[973995.373113]  edac_core
[973995.378001]  x86_pkg_temp_thermal
[973995.384795]  intel_powerclamp
[973995.390897]  coretemp
[973995.395608]  kvm_intel
[973995.400498]  kvm
[973995.404345]  irqbypass
[973995.409235]  ses
[973995.413078]  iTCO_wdt
[973995.417794]  iTCO_vendor_support
[973995.424415]  enclosure
[973995.429301]  lpc_ich
[973995.433843]  scsi_transport_sas
[973995.440292]  mfd_core
[973995.445007]  efivars
[973995.449548]  ipmi_si
[973995.454087]  ipmi_devintf
[973995.459496]  

Re: powerpc/sysrq: Fix oops whem ppmu is not registered

[Michael Ellerman]

On Tue, 2017-09-19 at 06:17:06 UTC, Ravi Bangoria wrote:
> Kernel crashes if power pmu is not registered and user tries to dump
> regs with 'echo p > /proc/sysrq-trigger'. Sample log:
> 
>   Unable to handle kernel paging request for data at address 0x0008
>   Faulting instruction address: 0xc00d52f0
> 
>   NIP [c00d52f0] perf_event_print_debug+0x10/0x230
>   LR [c058a938] sysrq_handle_showregs+0x38/0x50
>   Call Trace:
>printk+0x38/0x4c (unreliable)
>__handle_sysrq+0xe4/0x270
>write_sysrq_trigger+0x64/0x80
>proc_reg_write+0x80/0xd0
>__vfs_write+0x40/0x200
>vfs_write+0xc8/0x240
>SyS_write+0x60/0x110
>system_call+0x58/0x6c
> 
> Signed-off-by: Ravi Bangoria 
> Reviewed-by: Kamalesh Babulal 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/4917fcb58cc73f6b81455e3c5f9601

cheers

Re: powerpc/powernv: Clear LPCR[PECE1] via stop-api only for deep state offline

[Michael Ellerman]

On Thu, 2017-08-31 at 11:47:41 UTC, "Gautham R. Shenoy" wrote:
> From: "Gautham R. Shenoy" 
> 
> commit 24be85a23d1f ("powerpc/powernv: Clear PECE1 in LPCR via
> stop-api only on Hotplug") clears the PECE1 bit of the LPCR via
> stop-api during CPU-Hotplug to prevent wakeup due to a decrementer on
> an offlined CPU which is in a deep stop state.
> 
> In the case where the stop-api support is found to be lacking, the
> commit 785a12afdb4a ("powerpc/powernv/idle: Disable LOSE_FULL_CONTEXT
> states when stop-api fails") disables deep states that lose hypervisor
> context. Thus in this case, the offlined CPU will be put to some
> shallow idle state.
> 
> However, we currently unconditionally clear the PECE1 in LPCR via
> stop-api during CPU-Hotplug even when deep states are disabled due to
> stop-api failure.
> 
> Fix this by clearing PECE1 of LPCR via stop-api during CPU-Hotplug
> *only* when the offlined CPU will be put to a deep state that loses
> hypervisor context.
> 
> Fixes: commit 24be85a23d1f ("powerpc/powernv: Clear PECE1 in LPCR via
> stop-api only on Hotplug")
> 
> Reported-by: Pavithra Prakash 
> Signed-off-by: Gautham R. Shenoy 
> Reviewed-by: Nicholas Piggin 
> Tested-by: Pavithra Prakash 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/5d298baa41883fc421acfd932799c0

cheers

Re: powerpc/sysrq: Fix oops whem ppmu is not registered

[Michael Ellerman]

On Tue, 2017-09-19 at 06:17:06 UTC, Ravi Bangoria wrote:
> Kernel crashes if power pmu is not registered and user tries to dump
> regs with 'echo p > /proc/sysrq-trigger'. Sample log:
> 
>   Unable to handle kernel paging request for data at address 0x0008
>   Faulting instruction address: 0xc00d52f0
> 
>   NIP [c00d52f0] perf_event_print_debug+0x10/0x230
>   LR [c058a938] sysrq_handle_showregs+0x38/0x50
>   Call Trace:
>printk+0x38/0x4c (unreliable)
>__handle_sysrq+0xe4/0x270
>write_sysrq_trigger+0x64/0x80
>proc_reg_write+0x80/0xd0
>__vfs_write+0x40/0x200
>vfs_write+0xc8/0x240
>SyS_write+0x60/0x110
>system_call+0x58/0x6c
> 
> Signed-off-by: Ravi Bangoria 
> Reviewed-by: Kamalesh Babulal 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/4917fcb58cc73f6b81455e3c5f9601

cheers

Re: powerpc/powernv: Clear LPCR[PECE1] via stop-api only for deep state offline

[Michael Ellerman]

On Thu, 2017-08-31 at 11:47:41 UTC, "Gautham R. Shenoy" wrote:
> From: "Gautham R. Shenoy" 
> 
> commit 24be85a23d1f ("powerpc/powernv: Clear PECE1 in LPCR via
> stop-api only on Hotplug") clears the PECE1 bit of the LPCR via
> stop-api during CPU-Hotplug to prevent wakeup due to a decrementer on
> an offlined CPU which is in a deep stop state.
> 
> In the case where the stop-api support is found to be lacking, the
> commit 785a12afdb4a ("powerpc/powernv/idle: Disable LOSE_FULL_CONTEXT
> states when stop-api fails") disables deep states that lose hypervisor
> context. Thus in this case, the offlined CPU will be put to some
> shallow idle state.
> 
> However, we currently unconditionally clear the PECE1 in LPCR via
> stop-api during CPU-Hotplug even when deep states are disabled due to
> stop-api failure.
> 
> Fix this by clearing PECE1 of LPCR via stop-api during CPU-Hotplug
> *only* when the offlined CPU will be put to a deep state that loses
> hypervisor context.
> 
> Fixes: commit 24be85a23d1f ("powerpc/powernv: Clear PECE1 in LPCR via
> stop-api only on Hotplug")
> 
> Reported-by: Pavithra Prakash 
> Signed-off-by: Gautham R. Shenoy 
> Reviewed-by: Nicholas Piggin 
> Tested-by: Pavithra Prakash 

Applied to powerpc fixes, thanks.

https://git.kernel.org/powerpc/c/5d298baa41883fc421acfd932799c0

cheers

Re: [PATCH v2] mm: introduce validity check on vm dirtiness settings

[Yafang Shao]

2017-09-20 23:33 GMT+08:00 Jan Kara :
> On Tue 19-09-17 19:48:00, Yafang Shao wrote:
>> 2017-09-19 16:35 GMT+08:00 Jan Kara :
>> > On Tue 19-09-17 06:53:00, Yafang Shao wrote:
>> >> + if (vm_dirty_bytes == 0 && vm_dirty_ratio == 0 &&
>> >> + (dirty_background_bytes != 0 || dirty_background_ratio != 
>> >> 0))
>> >> + ret = false;
>> >
>> > Hum, why not just:
>> > if ((vm_dirty_bytes == 0 && vm_dirty_ratio == 0) ||
>> > (dirty_background_bytes == 0 && dirty_background_ratio == 0))
>> > ret = false;
>> >
>> > IMHO setting either tunable to 0 is just wrong and actively dangerous...
>> >
>>
>> Because these four variables all could be set to 0 before, and I'm not
>> sure if this
>> is needed under some certain conditions, although I think this is
>> dangerous but I have
>> to keep it as before.
>>
>> If you think that is wrong, then I will modified it as you suggested.
>
> OK, I see but see below.
>
>> >>  int dirty_background_ratio_handler(struct ctl_table *table, int write,
>> >>   void __user *buffer, size_t *lenp,
>> >>   loff_t *ppos)
>> >>  {
>> >>   int ret;
>> >> + int old_ratio = dirty_background_ratio;
>> >>
>> >>   ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
>> >> - if (ret == 0 && write)
>> >> - dirty_background_bytes = 0;
>> >> + if (ret == 0 && write) {
>> >> + if (dirty_background_ratio != old_ratio &&
>> >> + !vm_dirty_settings_valid()) {
>> >
>> > Why do you check whether new ratio is different here? If it is really
>> > needed, it would deserve a comment.
>> >
>>
>> There're two reseaons,
>> 1.  if you set a value same with the old value, it's needn't to do this 
>> check.
>> 2. there's another behavior that I'm not sure whether it is reaonable.  i.e.
>>  if the old value is,
>> vm.dirty_background_bytes = 0;
>> vm.dirty_background_ratio=10;
>>   then I execute the bellow command,
>> sysctl -w vm.dirty_background_bytes=0
>>  at the end these two values will be,
>> vm.dirty_background_bytes = 0;
>> vm.dirty_background_ratio=0;
>> I'm not sure if this is needed under some certain conditons, So I have
>> to keep it as before.
>
> OK, this is somewhat the problem of the switching logic between _bytes and
> _ratio bytes and also the fact that '0' has a special meaning in these
> files. I think the cleanest would be to just refuse writing of '0' into any
> of these files which would deal with the problem as well.
Got it.
I will submit a new patch then.

>
> Honza
> --
> Jan Kara 
> SUSE Labs, CR

Re: usb/hid: slab-out-of-bounds read in usbhid_parse

[Jaejoong Kim]

Hi Alan

2017-09-21 0:50 GMT+09:00 Alan Stern :
> On Wed, 20 Sep 2017, Kim Jaejoong wrote:
>
>> To. usb & input guys.
>>
>> While dig this report, i was wondering about bNumDescriptors in HID 
>> descriptor.
>> HID document from usb.org said, 'this number must be at least one (1)
>> as a Report descriptor will always be present.'
>>
>> There is no mention of the order of class descriptors. Suppose you
>> have a HID device with a report descriptor and a physical descriptor.
>>
>> If you have the following hid descriptor in this case,
>> HID descriptor
>>bLength: 12
>>bDescriptor Type: HID
>>.. skip
>>bNumDescriptors: 2
>>bDescriptorType: physical
>>bDescriptorLength: any
>>bDescriptorType: Report
>>bDescriptorLength: any
>>
>> If the order of the report descriptor is the second as above,
>> usbhid_parse () will fail because my patch is only check the first
>> bDescriptor Type.
>> But If the order of the report descriptor is always first, there is no
>> problem. How do you think this?
>
> The descriptors can appear in any order.  You should not assume that
> the report descriptor will always come first.

Thanks for clarifying. I will resend patch with modification.

Jaejoong

>
> Alan Stern
>