drivers/gpio/gpiolib.c:3215: undefined reference to `of_get_named_gpiod_flags'

2016-09-17 Thread kbuild test robot
Hi Linus,

It's probably a bug fix that unveils the link errors.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   d4690f1e1cdabb4d61207b6787b1605a0dc0aeab
commit: 2527ecc9195e9c66252af24c4689e8a67cd4ccb9 gpio: Fix OF build problem on 
UM
date:   4 weeks ago
config: um-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 2527ecc9195e9c66252af24c4689e8a67cd4ccb9
# save the attached .config to linux build tree
make ARCH=um 

All errors (new ones prefixed by >>):

   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc7d1): warning: Using 'getgrnam' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc61c): warning: Using 'getpwuid' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc935): warning: Using 'getaddrinfo' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoaddr':
   (.text+0x1d3c5): warning: Using 'gethostbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametonetaddr':
   (.text+0x1d465): warning: Using 'getnetbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoproto':
   (.text+0x1d685): warning: Using 'getprotobyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoport':
   (.text+0x1d4b7): warning: Using 'getservbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   drivers/built-in.o: In function `fwnode_get_named_gpiod':
>> drivers/gpio/gpiolib.c:3215: undefined reference to 
>> `of_get_named_gpiod_flags'
   drivers/built-in.o: In function `gpiod_get_index':
   drivers/gpio/gpiolib.c:3140: undefined reference to 
`of_get_named_gpiod_flags'
   drivers/built-in.o: In function `bgpio_map':
   drivers/gpio/gpio-mmio.c:571: undefined reference to `devm_ioremap_resource'
   drivers/built-in.o: In function `dwapb_gpio_probe':
   drivers/gpio/gpio-dwapb.c:554: undefined reference to `devm_ioremap_resource'
   drivers/built-in.o: In function `zx_gpio_probe':
>> drivers/gpio/gpio-zx.c:229: undefined reference to `devm_ioremap_resource'
   drivers/built-in.o: In function `lp872x_probe':
   drivers/regulator/lp872x.c:773: undefined reference to 
`devm_gpio_request_one'
   drivers/regulator/lp872x.c:746: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `max8952_pmic_probe':
   drivers/regulator/max8952.c:249: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `max8973_probe':
   drivers/regulator/max8973-regulator.c:715: undefined reference to 
`devm_gpio_request_one'
   drivers/regulator/max8973-regulator.c:770: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `pwm_regulator_probe':
   drivers/regulator/pwm-regulator.c:387: undefined reference to 
`devm_gpiod_get_optional'
   drivers/built-in.o: In function `tps62360_probe':
   drivers/regulator/tps62360-regulator.c:433: undefined reference to 
`devm_gpio_request_one'
   drivers/regulator/tps62360-regulator.c:444: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `fdp_nci_i2c_probe':
   drivers/nfc/fdp/i2c.c:326: undefined reference to `devm_gpiod_get'
   drivers/built-in.o: In function `nfcmrvl_nci_unregister_dev':
   drivers/nfc/nfcmrvl/main.c:198: undefined reference to `devm_gpio_free'
   drivers/built-in.o: In function `nfcmrvl_nci_register_dev':
   drivers/nfc/nfcmrvl/main.c:127: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `st21nfca_hci_i2c_probe':
   drivers/nfc/st21nfca/i2c.c:597: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `st_nci_i2c_probe':
   drivers/nfc/st-nci/i2c.c:300: undefined reference to `devm_gpio_request_one'
   drivers/built-in.o: In function `nxp_nci_i2c_probe':
   drivers/nfc/nxp-nci/i2c.c:361: undefined reference to `devm_gpio_request_one'
   drivers/built-in.o: In function `mdio_gpio_probe':
   drivers/net/phy/mdio-gpio.c:177: undefined reference to `devm_gpio_request'
   drivers/built-in.o: In function `at803x_probe':
   drivers/net/phy/at803x.c:283: undefined reference to 
`devm_gpiod_get_optional'
   drivers/built-in.o: In function `xgene_mdio_probe':
   

drivers/gpio/gpiolib.c:3215: undefined reference to `of_get_named_gpiod_flags'

2016-09-17 Thread kbuild test robot
Hi Linus,

It's probably a bug fix that unveils the link errors.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   d4690f1e1cdabb4d61207b6787b1605a0dc0aeab
commit: 2527ecc9195e9c66252af24c4689e8a67cd4ccb9 gpio: Fix OF build problem on 
UM
date:   4 weeks ago
config: um-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 2527ecc9195e9c66252af24c4689e8a67cd4ccb9
# save the attached .config to linux build tree
make ARCH=um 

All errors (new ones prefixed by >>):

   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc7d1): warning: Using 'getgrnam' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc61c): warning: Using 'getpwuid' in statically linked applications 
requires at runtime the shared libraries from the glibc version used for linking
   arch/um/drivers/built-in.o: In function `vde_open_real':
   (.text+0xc935): warning: Using 'getaddrinfo' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoaddr':
   (.text+0x1d3c5): warning: Using 'gethostbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametonetaddr':
   (.text+0x1d465): warning: Using 'getnetbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoproto':
   (.text+0x1d685): warning: Using 'getprotobyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   arch/um/drivers/built-in.o: In function `pcap_nametoport':
   (.text+0x1d4b7): warning: Using 'getservbyname' in statically linked 
applications requires at runtime the shared libraries from the glibc version 
used for linking
   drivers/built-in.o: In function `fwnode_get_named_gpiod':
>> drivers/gpio/gpiolib.c:3215: undefined reference to 
>> `of_get_named_gpiod_flags'
   drivers/built-in.o: In function `gpiod_get_index':
   drivers/gpio/gpiolib.c:3140: undefined reference to 
`of_get_named_gpiod_flags'
   drivers/built-in.o: In function `bgpio_map':
   drivers/gpio/gpio-mmio.c:571: undefined reference to `devm_ioremap_resource'
   drivers/built-in.o: In function `dwapb_gpio_probe':
   drivers/gpio/gpio-dwapb.c:554: undefined reference to `devm_ioremap_resource'
   drivers/built-in.o: In function `zx_gpio_probe':
>> drivers/gpio/gpio-zx.c:229: undefined reference to `devm_ioremap_resource'
   drivers/built-in.o: In function `lp872x_probe':
   drivers/regulator/lp872x.c:773: undefined reference to 
`devm_gpio_request_one'
   drivers/regulator/lp872x.c:746: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `max8952_pmic_probe':
   drivers/regulator/max8952.c:249: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `max8973_probe':
   drivers/regulator/max8973-regulator.c:715: undefined reference to 
`devm_gpio_request_one'
   drivers/regulator/max8973-regulator.c:770: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `pwm_regulator_probe':
   drivers/regulator/pwm-regulator.c:387: undefined reference to 
`devm_gpiod_get_optional'
   drivers/built-in.o: In function `tps62360_probe':
   drivers/regulator/tps62360-regulator.c:433: undefined reference to 
`devm_gpio_request_one'
   drivers/regulator/tps62360-regulator.c:444: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `fdp_nci_i2c_probe':
   drivers/nfc/fdp/i2c.c:326: undefined reference to `devm_gpiod_get'
   drivers/built-in.o: In function `nfcmrvl_nci_unregister_dev':
   drivers/nfc/nfcmrvl/main.c:198: undefined reference to `devm_gpio_free'
   drivers/built-in.o: In function `nfcmrvl_nci_register_dev':
   drivers/nfc/nfcmrvl/main.c:127: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `st21nfca_hci_i2c_probe':
   drivers/nfc/st21nfca/i2c.c:597: undefined reference to 
`devm_gpio_request_one'
   drivers/built-in.o: In function `st_nci_i2c_probe':
   drivers/nfc/st-nci/i2c.c:300: undefined reference to `devm_gpio_request_one'
   drivers/built-in.o: In function `nxp_nci_i2c_probe':
   drivers/nfc/nxp-nci/i2c.c:361: undefined reference to `devm_gpio_request_one'
   drivers/built-in.o: In function `mdio_gpio_probe':
   drivers/net/phy/mdio-gpio.c:177: undefined reference to `devm_gpio_request'
   drivers/built-in.o: In function `at803x_probe':
   drivers/net/phy/at803x.c:283: undefined reference to 
`devm_gpiod_get_optional'
   drivers/built-in.o: In function `xgene_mdio_probe':
   

Re: [PATCH 4/5] ipc/msg: Lockless security checks for msgsnd

2016-09-17 Thread Manfred Spraul

Hi Davidlohr,


Just as with msgrcv (along with the rest of sysvipc since a few years
ago), perform the security checks without holding the ipc object lock.

Thinking about it: isn't this wrong?

CPU1:
* msgrcv()
* ipcperms()


CPU2:
* msgctl(), change permissions
** msgctl() returns, new permissions should now be in effect
* msgsnd(), send secret message
** msgsnd() returns, new message stored.

CPU1: resumes, receives secret message

Obviously, we could argue that the msgrcv() was already ongoing and 
therefore the old permissions still apply - but then we don't need to 
recheck after sleeping at all.




This also reduces the hogging of the lock for the entire duration of a
sender, as we drop the lock upon every iteration -- and this is 
exactly

why we also check for racing with RMID in the first place.


Which hogging do you mean? The lock is dopped uppon every iteration, the 
schedule() is in the middle.

Which your patch, the lock are now dropped twice:

-
for (;;) {
struct msg_sender s;
  
  		err = -EACCES;

if (ipcperms(ns, >q_perm, S_IWUGO))
-   goto out_unlock0;
+   goto out_unlock1;
+
+   ipc_lock_object(>q_perm);
  
  		/* raced with RMID? */

if (!ipc_valid_object(>q_perm)) {
@@ -681,6 +681,7 @@ long do_msgsnd(int msqid, long mtype, void __user *mtext,
goto out_unlock0;
}
  
+		ipc_unlock_object(>q_perm);

}



This means the lock is dropped, just for ipcperms().
This doubles the lock acquire/release cycles.

--
Manfred


Re: [PATCH 4/5] ipc/msg: Lockless security checks for msgsnd

2016-09-17 Thread Manfred Spraul

Hi Davidlohr,


Just as with msgrcv (along with the rest of sysvipc since a few years
ago), perform the security checks without holding the ipc object lock.

Thinking about it: isn't this wrong?

CPU1:
* msgrcv()
* ipcperms()


CPU2:
* msgctl(), change permissions
** msgctl() returns, new permissions should now be in effect
* msgsnd(), send secret message
** msgsnd() returns, new message stored.

CPU1: resumes, receives secret message

Obviously, we could argue that the msgrcv() was already ongoing and 
therefore the old permissions still apply - but then we don't need to 
recheck after sleeping at all.




This also reduces the hogging of the lock for the entire duration of a
sender, as we drop the lock upon every iteration -- and this is 
exactly

why we also check for racing with RMID in the first place.


Which hogging do you mean? The lock is dopped uppon every iteration, the 
schedule() is in the middle.

Which your patch, the lock are now dropped twice:

-
for (;;) {
struct msg_sender s;
  
  		err = -EACCES;

if (ipcperms(ns, >q_perm, S_IWUGO))
-   goto out_unlock0;
+   goto out_unlock1;
+
+   ipc_lock_object(>q_perm);
  
  		/* raced with RMID? */

if (!ipc_valid_object(>q_perm)) {
@@ -681,6 +681,7 @@ long do_msgsnd(int msqid, long mtype, void __user *mtext,
goto out_unlock0;
}
  
+		ipc_unlock_object(>q_perm);

}



This means the lock is dropped, just for ipcperms().
This doubles the lock acquire/release cycles.

--
Manfred


Re: Possible code defects: macros and precedence

2016-09-17 Thread Julia Lawall


On Sat, 17 Sep 2016, Joe Perches wrote:

> On Sat, 2016-09-17 at 22:24 +0200, Julia Lawall wrote:
> > diff -u -p a/lib/sha1.c b/lib/sha1.c
> []
> > @@ -49,18 +49,18 @@
> >   * the input data, the next mix it from the 512-bit array.
> >   */
> >  #define SHA_SRC(t) get_unaligned_be32((__u32 *)data + t)
> > -#define SHA_MIX(t) rol32(W(t+13) ^ W(t+8) ^ W(t+2) ^ W(t), 1)
> > +#define SHA_MIX(t) rol32(W((t)+13) ^ W((t)+8) ^ W((t)+2) ^ W(t), 1)
> >
> >  #define SHA_ROUND(t, input, fn, constant, A, B, C, D, E) do { \
> > __u32 TEMP = input(t); setW(t, TEMP); \
> > E += TEMP + rol32(A,5) + (fn) + (constant); \
> > B = ror32(B, 2); } while (0)
> >
> > -#define T_0_15(t, A, B, C, D, E)  SHA_ROUND(t, SHA_SRC, (((C^D))^D) , 
> > 0x5a827999, A, B, C, D, E )
> > -#define T_16_19(t, A, B, C, D, E) SHA_ROUND(t, SHA_MIX, (((C^D))^D) , 
> > 0x5a827999, A, B, C, D, E )
> > -#define T_20_39(t, A, B, C, D, E) SHA_ROUND(t, SHA_MIX, (B^C^D) , 
> > 0x6ed9eba1, A, B, C, D, E )
> > -#define T_40_59(t, A, B, C, D, E) SHA_ROUND(t, SHA_MIX, ((B)+(D&(B^C))) 
> > , 0x8f1bbcdc, A, B, C, D, E )
> > -#define T_60_79(t, A, B, C, D, E) SHA_ROUND(t, SHA_MIX, (B^C^D) ,  
> > 0xca62c1d6, A, B, C, D, E )
> > +#define T_0_15(t, A, B, C, D, E)  SHA_ROUND(t, SHA_SRC, C)^D))^D) , 
> > 0x5a827999, A, B, C, D, E )
> > +#define T_16_19(t, A, B, C, D, E) SHA_ROUND(t, SHA_MIX, C)^D))^D) , 
> > 0x5a827999, A, B, C, D, E )
> > +#define T_20_39(t, A, B, C, D, E) SHA_ROUND(t, SHA_MIX, ((B)^C^D) , 
> > 0x6ed9eba1, A, B, C, D, E )
> > +#define T_40_59(t, A, B, C, D, E) SHA_ROUND(t, SHA_MIX, 
> > (((B))+((D)&((B)^C))) , 0x8f1bbcdc, A, B, C, D, E )
> > +#define T_60_79(t, A, B, C, D, E) SHA_ROUND(t, SHA_MIX, ((B)^C^D) ,  
> > 0xca62c1d6, A, B, C, D, E )
>
> I didn't look at much of the patch.
>
> It looks as if the coccinelle code doesn't do the
> transformation on each possible macro argument.
>
> In the transform above, only the first referenced arg
> is updated with parentheses and subsequent args are not.

No, actually it looks like only the left argument is getting transformed.
For example, T_40_59 has a term that started as ((B)+(D&(B^C))) and ends
up as (((B))+((D)&((B)^C))).  I can fix this.

> Many or most of the uses of these various macros always
> pass a single argument to these macros so there isn't a
> real possibility of a precedence defect for those uses.
>
> Is it possible to check the macro users for arguments that
> might produce precedence defects and only report those
> possible defects?

It could be possible.  Coccinelle is not always able to associate header
files to C files, if the header files are in strange paths, but perhaps
one could also rely on the names, since some names may be unique in the
kernel.

> I also submitted a similar checkpatch addition that looks
> for non-comma operators used macro arguments in function
> definitions.
>
> The checkpatch test has the same weakness as the coccinelle
> test. It doesn't check uses, just the macro definition.

I wonder if it is really a weakness?  Does anyone care if a macro
definition has more parentheses than what is necessary for the current
usage?

julia

> Commits in -next:
>
> From 75bd22fe82d1fd698894e4a5d21e33ffdf7d4492 Mon Sep 17 00:00:00 2001
> From: Joe Perches 
> Date: Thu, 15 Sep 2016 10:29:22 +1000
> Subject: [PATCH] checkpatch: improve MACRO_ARG_PRECEDENCE test
>
> It is possible for a multiple line macro definition to have a false positive
> report when an argument is used on a line after a continuation \.
>
> This line might have a leading '+' as the initial character that could be
> confused by checkpatch as an operator.
>
> Avoid the leading character on multiple line macro definitions.
>
> Link: 
> http://lkml.kernel.org/r/60229d13399f9b6509db5a32e30d4c16951a60cd.1473836073.git@perches.com
> Signed-off-by: Joe Perches 
> Signed-off-by: Andrew Morton 
>
> From 0158682614df6006752ac932b2e65475384a87b3 Mon Sep 17 00:00:00 2001
> From: Joe Perches 
> Date: Thu, 15 Sep 2016 10:29:22 +1000
> Subject: [PATCH] checkpatch: add --strict test for precedence challenged 
> macro arguments
>
> Add a test for macro arguents that have a non-comma leading or trailing
> operator where the argument isn't parenthesized to avoid possible precedence
> issues.
>
> Link: 
> http://lkml.kernel.org/r/47715508972f8d786f435e583ff881dbeee3a114.1473745855.git@perches.com
> Signed-off-by: Joe Perches 
> Cc: Andy Whitcroft 
> Cc: Julia Lawall 
> Cc: Dan Carpenter 
> Signed-off-by: Andrew Morton 
>
>

Re: Possible code defects: macros and precedence

2016-09-17 Thread Julia Lawall


On Sat, 17 Sep 2016, Joe Perches wrote:

> On Sat, 2016-09-17 at 22:24 +0200, Julia Lawall wrote:
> > diff -u -p a/lib/sha1.c b/lib/sha1.c
> []
> > @@ -49,18 +49,18 @@
> >   * the input data, the next mix it from the 512-bit array.
> >   */
> >  #define SHA_SRC(t) get_unaligned_be32((__u32 *)data + t)
> > -#define SHA_MIX(t) rol32(W(t+13) ^ W(t+8) ^ W(t+2) ^ W(t), 1)
> > +#define SHA_MIX(t) rol32(W((t)+13) ^ W((t)+8) ^ W((t)+2) ^ W(t), 1)
> >
> >  #define SHA_ROUND(t, input, fn, constant, A, B, C, D, E) do { \
> > __u32 TEMP = input(t); setW(t, TEMP); \
> > E += TEMP + rol32(A,5) + (fn) + (constant); \
> > B = ror32(B, 2); } while (0)
> >
> > -#define T_0_15(t, A, B, C, D, E)  SHA_ROUND(t, SHA_SRC, (((C^D))^D) , 
> > 0x5a827999, A, B, C, D, E )
> > -#define T_16_19(t, A, B, C, D, E) SHA_ROUND(t, SHA_MIX, (((C^D))^D) , 
> > 0x5a827999, A, B, C, D, E )
> > -#define T_20_39(t, A, B, C, D, E) SHA_ROUND(t, SHA_MIX, (B^C^D) , 
> > 0x6ed9eba1, A, B, C, D, E )
> > -#define T_40_59(t, A, B, C, D, E) SHA_ROUND(t, SHA_MIX, ((B)+(D&(B^C))) 
> > , 0x8f1bbcdc, A, B, C, D, E )
> > -#define T_60_79(t, A, B, C, D, E) SHA_ROUND(t, SHA_MIX, (B^C^D) ,  
> > 0xca62c1d6, A, B, C, D, E )
> > +#define T_0_15(t, A, B, C, D, E)  SHA_ROUND(t, SHA_SRC, C)^D))^D) , 
> > 0x5a827999, A, B, C, D, E )
> > +#define T_16_19(t, A, B, C, D, E) SHA_ROUND(t, SHA_MIX, C)^D))^D) , 
> > 0x5a827999, A, B, C, D, E )
> > +#define T_20_39(t, A, B, C, D, E) SHA_ROUND(t, SHA_MIX, ((B)^C^D) , 
> > 0x6ed9eba1, A, B, C, D, E )
> > +#define T_40_59(t, A, B, C, D, E) SHA_ROUND(t, SHA_MIX, 
> > (((B))+((D)&((B)^C))) , 0x8f1bbcdc, A, B, C, D, E )
> > +#define T_60_79(t, A, B, C, D, E) SHA_ROUND(t, SHA_MIX, ((B)^C^D) ,  
> > 0xca62c1d6, A, B, C, D, E )
>
> I didn't look at much of the patch.
>
> It looks as if the coccinelle code doesn't do the
> transformation on each possible macro argument.
>
> In the transform above, only the first referenced arg
> is updated with parentheses and subsequent args are not.

No, actually it looks like only the left argument is getting transformed.
For example, T_40_59 has a term that started as ((B)+(D&(B^C))) and ends
up as (((B))+((D)&((B)^C))).  I can fix this.

> Many or most of the uses of these various macros always
> pass a single argument to these macros so there isn't a
> real possibility of a precedence defect for those uses.
>
> Is it possible to check the macro users for arguments that
> might produce precedence defects and only report those
> possible defects?

It could be possible.  Coccinelle is not always able to associate header
files to C files, if the header files are in strange paths, but perhaps
one could also rely on the names, since some names may be unique in the
kernel.

> I also submitted a similar checkpatch addition that looks
> for non-comma operators used macro arguments in function
> definitions.
>
> The checkpatch test has the same weakness as the coccinelle
> test. It doesn't check uses, just the macro definition.

I wonder if it is really a weakness?  Does anyone care if a macro
definition has more parentheses than what is necessary for the current
usage?

julia

> Commits in -next:
>
> From 75bd22fe82d1fd698894e4a5d21e33ffdf7d4492 Mon Sep 17 00:00:00 2001
> From: Joe Perches 
> Date: Thu, 15 Sep 2016 10:29:22 +1000
> Subject: [PATCH] checkpatch: improve MACRO_ARG_PRECEDENCE test
>
> It is possible for a multiple line macro definition to have a false positive
> report when an argument is used on a line after a continuation \.
>
> This line might have a leading '+' as the initial character that could be
> confused by checkpatch as an operator.
>
> Avoid the leading character on multiple line macro definitions.
>
> Link: 
> http://lkml.kernel.org/r/60229d13399f9b6509db5a32e30d4c16951a60cd.1473836073.git@perches.com
> Signed-off-by: Joe Perches 
> Signed-off-by: Andrew Morton 
>
> From 0158682614df6006752ac932b2e65475384a87b3 Mon Sep 17 00:00:00 2001
> From: Joe Perches 
> Date: Thu, 15 Sep 2016 10:29:22 +1000
> Subject: [PATCH] checkpatch: add --strict test for precedence challenged 
> macro arguments
>
> Add a test for macro arguents that have a non-comma leading or trailing
> operator where the argument isn't parenthesized to avoid possible precedence
> issues.
>
> Link: 
> http://lkml.kernel.org/r/47715508972f8d786f435e583ff881dbeee3a114.1473745855.git@perches.com
> Signed-off-by: Joe Perches 
> Cc: Andy Whitcroft 
> Cc: Julia Lawall 
> Cc: Dan Carpenter 
> Signed-off-by: Andrew Morton 
>
>

Re: [PATCH v2 2/2] usb: dwc3: Wait for control tranfer completed when stopping gadget

2016-09-17 Thread Baolin Wang
Hi Felipe,

On 9 September 2016 at 19:03, Felipe Balbi  wrote:
>
> Hi,
>
> Baolin Wang  writes:
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 057739d..22787b6 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -999,6 +999,7 @@ static int dwc3_probe(struct platform_device *pdev)
>>   goto err0;
>>
>>   spin_lock_init(>lock);
>> + init_completion(>ep0_completed);
>
> this should be done only when gadget is required; meaning that this
> should be moved to dwc3_gadget_init()

OK.

>
>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>> index b2317e7..858e661 100644
>> --- a/drivers/usb/dwc3/core.h
>> +++ b/drivers/usb/dwc3/core.h
>
> [...]
>
>> @@ -843,6 +844,7 @@ struct dwc3 {
>>   dma_addr_t  ep0_bounce_addr;
>>   dma_addr_t  scratch_addr;
>>   struct dwc3_request ep0_usb_req;
>> + struct completion   ep0_completed;
>
> when you call this "ep0_completed" it seems like you're defining a flag,
> but you're not :) How about "ep0_in_setup" instead? That conveys the
> idea that we're waiting for ep0 to reach setup phase.

Make sense and will change it.

>
>> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
>> index 632e5a4..baf932d 100644
>> --- a/drivers/usb/dwc3/ep0.c
>> +++ b/drivers/usb/dwc3/ep0.c
>> @@ -286,6 +286,7 @@ static void dwc3_ep0_stall_and_restart(struct dwc3 *dwc)
>>
>>   dwc->ep0state = EP0_SETUP_PHASE;
>>   dwc3_ep0_out_start(dwc);
>> + complete(>ep0_completed);
>
> no, this is wrong. I see what you're trying to do here, but we don't
> want to duplicate this call to complete() right? One thing we can
> realize is that *always* after STATUS phase or after a STALL, we will go
> through dwc3_ep0_out_start(), this mean we can call complete() before
> starting the following SETUP phase.
>
> Single place to call complete() ;-)

Make sense to me and I will fix that in next version.

>
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index 1a33308..c9026ce 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -1441,6 +1441,15 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int 
>> is_on, int suspend)
>>   if (pm_runtime_suspended(dwc->dev))
>>   return 0;
>>
>> + /*
>> +  * Per databook, when we want to stop the gadget, if a control transfer
>> +  * is still in process, complete it and get the core into setup phase.
>> +  */
>> + if (!is_on && dwc->ep0state != EP0_SETUP_PHASE) {
>> + reinit_completion(>ep0_completed);
>
> this seems unnecessary to me. Also, why return here so the caller has to

We should re-init the completion due to it will complete control
transfer many times before we try to stop gadget.

> wait? You could just have called wait_for_completion() here straight
> away:
>
> if (!is_on && dwc->ep0state != EP0_SETUP_PHASE) {
> /* should this be interruptible? */
> ret = wait_for_completion_timeout(>ep0_in_setup,
> msecs_to_jiffies(500));
> if (ret == 0) {
> dwc3_trace(trace_dwc3_gadget, "RUN/STOP timeout");
> return -ETIMEDOUT;
> }
> }
>
> There's also no need for that "try_again" trickery. We either can halt
> the controller within 500ms or we cannot.

But this is in atomic context and we can not issue
wait_for_completion_timeout() in atomic context, then we should just
return here.

-- 
Baolin.wang
Best Regards


Re: [PATCH v2 2/2] usb: dwc3: Wait for control tranfer completed when stopping gadget

2016-09-17 Thread Baolin Wang
Hi Felipe,

On 9 September 2016 at 19:03, Felipe Balbi  wrote:
>
> Hi,
>
> Baolin Wang  writes:
>> diff --git a/drivers/usb/dwc3/core.c b/drivers/usb/dwc3/core.c
>> index 057739d..22787b6 100644
>> --- a/drivers/usb/dwc3/core.c
>> +++ b/drivers/usb/dwc3/core.c
>> @@ -999,6 +999,7 @@ static int dwc3_probe(struct platform_device *pdev)
>>   goto err0;
>>
>>   spin_lock_init(>lock);
>> + init_completion(>ep0_completed);
>
> this should be done only when gadget is required; meaning that this
> should be moved to dwc3_gadget_init()

OK.

>
>> diff --git a/drivers/usb/dwc3/core.h b/drivers/usb/dwc3/core.h
>> index b2317e7..858e661 100644
>> --- a/drivers/usb/dwc3/core.h
>> +++ b/drivers/usb/dwc3/core.h
>
> [...]
>
>> @@ -843,6 +844,7 @@ struct dwc3 {
>>   dma_addr_t  ep0_bounce_addr;
>>   dma_addr_t  scratch_addr;
>>   struct dwc3_request ep0_usb_req;
>> + struct completion   ep0_completed;
>
> when you call this "ep0_completed" it seems like you're defining a flag,
> but you're not :) How about "ep0_in_setup" instead? That conveys the
> idea that we're waiting for ep0 to reach setup phase.

Make sense and will change it.

>
>> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
>> index 632e5a4..baf932d 100644
>> --- a/drivers/usb/dwc3/ep0.c
>> +++ b/drivers/usb/dwc3/ep0.c
>> @@ -286,6 +286,7 @@ static void dwc3_ep0_stall_and_restart(struct dwc3 *dwc)
>>
>>   dwc->ep0state = EP0_SETUP_PHASE;
>>   dwc3_ep0_out_start(dwc);
>> + complete(>ep0_completed);
>
> no, this is wrong. I see what you're trying to do here, but we don't
> want to duplicate this call to complete() right? One thing we can
> realize is that *always* after STATUS phase or after a STALL, we will go
> through dwc3_ep0_out_start(), this mean we can call complete() before
> starting the following SETUP phase.
>
> Single place to call complete() ;-)

Make sense to me and I will fix that in next version.

>
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index 1a33308..c9026ce 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -1441,6 +1441,15 @@ static int dwc3_gadget_run_stop(struct dwc3 *dwc, int 
>> is_on, int suspend)
>>   if (pm_runtime_suspended(dwc->dev))
>>   return 0;
>>
>> + /*
>> +  * Per databook, when we want to stop the gadget, if a control transfer
>> +  * is still in process, complete it and get the core into setup phase.
>> +  */
>> + if (!is_on && dwc->ep0state != EP0_SETUP_PHASE) {
>> + reinit_completion(>ep0_completed);
>
> this seems unnecessary to me. Also, why return here so the caller has to

We should re-init the completion due to it will complete control
transfer many times before we try to stop gadget.

> wait? You could just have called wait_for_completion() here straight
> away:
>
> if (!is_on && dwc->ep0state != EP0_SETUP_PHASE) {
> /* should this be interruptible? */
> ret = wait_for_completion_timeout(>ep0_in_setup,
> msecs_to_jiffies(500));
> if (ret == 0) {
> dwc3_trace(trace_dwc3_gadget, "RUN/STOP timeout");
> return -ETIMEDOUT;
> }
> }
>
> There's also no need for that "try_again" trickery. We either can halt
> the controller within 500ms or we cannot.

But this is in atomic context and we can not issue
wait_for_completion_timeout() in atomic context, then we should just
return here.

-- 
Baolin.wang
Best Regards


Re: Possible code defects: macros and precedence

2016-09-17 Thread Julia Lawall


On Sat, 17 Sep 2016, Joe Perches wrote:

> On Sat, 2016-09-17 at 22:24 +0200, Julia Lawall wrote:
>
> (A 2.2MB message that (perhaps thankfully) didn't get through to lkml)
>
> > Below is the Coccinelle output for the case where the definition of the
> > macro is a single expression.  There is also the case where it is a
> > sequence of statements, but that finds very few results.  Note that
> > Coccinelle will only match code that it can parse, which is definitely not
> > always the case for macros, so some things may be missed.
> >
> > There are a huge number of results.  To the extent that you have the
> > patience to look through them, do you see anything undesirable?
> >
> > thanks,
> > julia
> >
> > diff -u -p a/lib/lz4/lz4defs.h b/lib/lz4/lz4defs.h
> > --- a/lib/lz4/lz4defs.h
> > +++ b/lib/lz4/lz4defs.h
> > @@ -34,7 +34,7 @@ typedef struct _U64_S { u64 v; } U64_S;
> >  #define PUT8(s, d) (A64(d) = A64(s))
> >
> >  #define LZ4_READ_LITTLEENDIAN_16(d, s, p)  \
> > -   (d = s - A16(p))
> > +   (d = (s) - A16(p))
> >
> >  #define LZ4_WRITE_LITTLEENDIAN_16(p, v)\
> > do {\
> > @@ -53,7 +53,7 @@ typedef struct _U64_S { u64 v; } U64_S;
> > put_unaligned(get_unaligned((const u64 *) s), (u64 *) d)
> >
> >  #define LZ4_READ_LITTLEENDIAN_16(d, s, p)  \
> > -   (d = s - get_unaligned_le16(p))
> > +   (d = (s) - get_unaligned_le16(p))
> >
> >  #define LZ4_WRITE_LITTLEENDIAN_16(p, v)\
> > do {\
>
> Here's the equivalent checkpatch output for that file.
> It has a few more instances.
> Is what checkpatch suggests unreasonable?

Not as far as I can see.  As I mentioned, Coccinelle will only process
what it can parse.  A do ... while with no semicolon at the end is not
correct C (even though it is completely appropriate in the context of a
macro).  Actually, I thought we did something for this case, but maybe it
is not being parsed as what my rule matches.

You did say that checkpatch was giving a lot of noise.  In the end, is it
actually just that there are a lot of changes to make?

julia


> $ ./scripts/checkpatch.pl -f --strict lib/lz4/lz4defs.h 
> --types=macro_arg_precedence
> CHECK: Macro argument 's' may be better as '(s)' to avoid precedence issues
> #36: FILE: lib/lz4/lz4defs.h:36:
> +#define LZ4_READ_LITTLEENDIAN_16(d, s, p)\
> + (d = s - A16(p))
>
> CHECK: Macro argument 's' may be better as '(s)' to avoid precedence issues
> #55: FILE: lib/lz4/lz4defs.h:55:
> +#define LZ4_READ_LITTLEENDIAN_16(d, s, p)\
> + (d = s - get_unaligned_le16(p))
>
> CHECK: Macro argument 'd' may be better as '(d)' to avoid precedence issues
> #106: FILE: lib/lz4/lz4defs.h:106:
> +#define LZ4_SECURECOPY(s, d, e)  \
> + do {\
> + if (d < e) {\
> + LZ4_WILDCOPY(s, d, e);  \
> + }   \
> + } while (0)
>
> CHECK: Macro argument 'e' may be better as '(e)' to avoid precedence issues
> #106: FILE: lib/lz4/lz4defs.h:106:
> +#define LZ4_SECURECOPY(s, d, e)  \
> + do {\
> + if (d < e) {\
> + LZ4_WILDCOPY(s, d, e);  \
> + }   \
> + } while (0)
>
> CHECK: Macro argument 'e' may be better as '(e)' to avoid precedence issues
> #147: FILE: lib/lz4/lz4defs.h:147:
> +#define LZ4_WILDCOPY(s, d, e)\
> + do {\
> + LZ4_COPYPACKET(s, d);   \
> + } while (d < e)
>
> CHECK: Macro argument 'l' may be better as '(l)' to avoid precedence issues
> #152: FILE: lib/lz4/lz4defs.h:152:
> +#define LZ4_BLINDCOPY(s, d, l)   \
> + do {\
> + u8 *e = (d) + l;\
> + LZ4_WILDCOPY(s, d, e);  \
> + d = e;  \
> + } while (0)
>
> total: 0 errors, 0 warnings, 6 checks, 157 lines checked
>
> NOTE: For some of the reported defects, checkpatch may be able to
>   mechanically convert to the typical style using --fix or --fix-inplace.
>
> lib/lz4/lz4defs.h has style problems, please review.
>
> NOTE: Used message types: MACRO_ARG_PRECEDENCE
>
> NOTE: If any of the errors are false positives, please report
>   them to the maintainer, see CHECKPATCH in MAINTAINERS.
>

Re: Possible code defects: macros and precedence

2016-09-17 Thread Julia Lawall


On Sat, 17 Sep 2016, Joe Perches wrote:

> On Sat, 2016-09-17 at 22:24 +0200, Julia Lawall wrote:
>
> (A 2.2MB message that (perhaps thankfully) didn't get through to lkml)
>
> > Below is the Coccinelle output for the case where the definition of the
> > macro is a single expression.  There is also the case where it is a
> > sequence of statements, but that finds very few results.  Note that
> > Coccinelle will only match code that it can parse, which is definitely not
> > always the case for macros, so some things may be missed.
> >
> > There are a huge number of results.  To the extent that you have the
> > patience to look through them, do you see anything undesirable?
> >
> > thanks,
> > julia
> >
> > diff -u -p a/lib/lz4/lz4defs.h b/lib/lz4/lz4defs.h
> > --- a/lib/lz4/lz4defs.h
> > +++ b/lib/lz4/lz4defs.h
> > @@ -34,7 +34,7 @@ typedef struct _U64_S { u64 v; } U64_S;
> >  #define PUT8(s, d) (A64(d) = A64(s))
> >
> >  #define LZ4_READ_LITTLEENDIAN_16(d, s, p)  \
> > -   (d = s - A16(p))
> > +   (d = (s) - A16(p))
> >
> >  #define LZ4_WRITE_LITTLEENDIAN_16(p, v)\
> > do {\
> > @@ -53,7 +53,7 @@ typedef struct _U64_S { u64 v; } U64_S;
> > put_unaligned(get_unaligned((const u64 *) s), (u64 *) d)
> >
> >  #define LZ4_READ_LITTLEENDIAN_16(d, s, p)  \
> > -   (d = s - get_unaligned_le16(p))
> > +   (d = (s) - get_unaligned_le16(p))
> >
> >  #define LZ4_WRITE_LITTLEENDIAN_16(p, v)\
> > do {\
>
> Here's the equivalent checkpatch output for that file.
> It has a few more instances.
> Is what checkpatch suggests unreasonable?

Not as far as I can see.  As I mentioned, Coccinelle will only process
what it can parse.  A do ... while with no semicolon at the end is not
correct C (even though it is completely appropriate in the context of a
macro).  Actually, I thought we did something for this case, but maybe it
is not being parsed as what my rule matches.

You did say that checkpatch was giving a lot of noise.  In the end, is it
actually just that there are a lot of changes to make?

julia


> $ ./scripts/checkpatch.pl -f --strict lib/lz4/lz4defs.h 
> --types=macro_arg_precedence
> CHECK: Macro argument 's' may be better as '(s)' to avoid precedence issues
> #36: FILE: lib/lz4/lz4defs.h:36:
> +#define LZ4_READ_LITTLEENDIAN_16(d, s, p)\
> + (d = s - A16(p))
>
> CHECK: Macro argument 's' may be better as '(s)' to avoid precedence issues
> #55: FILE: lib/lz4/lz4defs.h:55:
> +#define LZ4_READ_LITTLEENDIAN_16(d, s, p)\
> + (d = s - get_unaligned_le16(p))
>
> CHECK: Macro argument 'd' may be better as '(d)' to avoid precedence issues
> #106: FILE: lib/lz4/lz4defs.h:106:
> +#define LZ4_SECURECOPY(s, d, e)  \
> + do {\
> + if (d < e) {\
> + LZ4_WILDCOPY(s, d, e);  \
> + }   \
> + } while (0)
>
> CHECK: Macro argument 'e' may be better as '(e)' to avoid precedence issues
> #106: FILE: lib/lz4/lz4defs.h:106:
> +#define LZ4_SECURECOPY(s, d, e)  \
> + do {\
> + if (d < e) {\
> + LZ4_WILDCOPY(s, d, e);  \
> + }   \
> + } while (0)
>
> CHECK: Macro argument 'e' may be better as '(e)' to avoid precedence issues
> #147: FILE: lib/lz4/lz4defs.h:147:
> +#define LZ4_WILDCOPY(s, d, e)\
> + do {\
> + LZ4_COPYPACKET(s, d);   \
> + } while (d < e)
>
> CHECK: Macro argument 'l' may be better as '(l)' to avoid precedence issues
> #152: FILE: lib/lz4/lz4defs.h:152:
> +#define LZ4_BLINDCOPY(s, d, l)   \
> + do {\
> + u8 *e = (d) + l;\
> + LZ4_WILDCOPY(s, d, e);  \
> + d = e;  \
> + } while (0)
>
> total: 0 errors, 0 warnings, 6 checks, 157 lines checked
>
> NOTE: For some of the reported defects, checkpatch may be able to
>   mechanically convert to the typical style using --fix or --fix-inplace.
>
> lib/lz4/lz4defs.h has style problems, please review.
>
> NOTE: Used message types: MACRO_ARG_PRECEDENCE
>
> NOTE: If any of the errors are false positives, please report
>   them to the maintainer, see CHECKPATCH in MAINTAINERS.
>

Re: [PATCH v2 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically

2016-09-17 Thread Baolin Wang
Hi Felipe,

Sorry for late reply due to my holiday.

On 9 September 2016 at 18:47, Felipe Balbi  wrote:
>
> Hi,
>
> Baolin Wang  writes:
>> When system has stpped the gadget, we should avoid queuing any requests
>> which will cause tranfer failed. Thus adding some disconnect checking to
>> avoid this situation.
>>
>> Signed-off-by: Baolin Wang 
>
> do you mind if we discuss this for a little longer?

Sure.

>
>> ---
>> Changes since v1:
>>  - Split into 2 separate ptaches.
>>  - Choose complete mechanism instead of polling.
>> ---
>>  drivers/usb/dwc3/ep0.c|8 
>>  drivers/usb/dwc3/gadget.c |   12 +---
>>  2 files changed, 17 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
>> index fe79d77..632e5a4 100644
>> --- a/drivers/usb/dwc3/ep0.c
>> +++ b/drivers/usb/dwc3/ep0.c
>> @@ -228,6 +228,14 @@ int dwc3_gadget_ep0_queue(struct usb_ep *ep, struct 
>> usb_request *request,
>>   int ret;
>>
>>   spin_lock_irqsave(>lock, flags);
>> + if (!dwc->pullups_connected) {
>> + dwc3_trace(trace_dwc3_ep0,
>> + "queuing request %p to %s when gadget is disconnected",
>> + request, dep->name);
>> + ret = -ESHUTDOWN;
>> + goto out;
>> + }
>
> I have been thinking about this branch here. It's not a problem to queue
> a request with pullups disconnected. It's only a problem to issue
> START_TRANSFER without RUN_STOP bit set.
>
> So maybe this check should be done in dwc3_send_gadget_ep_cmd(). By
> doing that we also make sure to do the check in one place and one place
> only because all endpoints rely dwc3_send_gadget_ep_cmd().

OK, that makes sense to me.

>
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index 1783406..1a33308 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -1040,6 +1040,13 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep 
>> *dep, struct dwc3_request *req)
>>   struct dwc3 *dwc = dep->dwc;
>>   int ret;
>>
>> + if (!dwc->pullups_connected) {
>> + dwc3_trace(trace_dwc3_gadget,
>> + "queuing request %p to %s when gadget is disconnected",
>> + >request, dep->endpoint.name);
>> + return -ESHUTDOWN;
>> + }
>> +
>>   if (!dep->endpoint.desc) {
>>   dwc3_trace(trace_dwc3_gadget,
>>   "trying to queue request %p to disabled %s",
>> @@ -1984,13 +1991,12 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc, 
>> struct dwc3_ep *dep,
>>   if (ret)
>>   break;
>>   }
>> -
>
> trailing change.

Ah, sorry. Will remove it.

>
>>   /*
>>* Our endpoint might get disabled by another thread during
>>* dwc3_gadget_giveback(). If that happens, we're just gonna return 1
>>* early on so DWC3_EP_BUSY flag gets cleared
>>*/
>> - if (!dep->endpoint.desc)
>> + if (!dep->endpoint.desc || !dwc->pullups_connected)
>
> I'm still considering this as well. Sure, we kill pullups before the
> descriptor is set to NULL, but that shouldn't be a problem. What will
> happen is:
>
> usb_gadget_disconnect();
> udc->driver->disconnect();
>  for_each_ep() {
>   for_each_request() {
>usb_ep_dequeue();
>   }
>   usb_ep_disable();
>dep->endpoint.desc = NULL;
>  }
> udc->driver->unbind();
> usb_gadget_udc_stop();
>
> I don't see a problem here. Did you manage to trigger any failure when
> you didn't have this check? Care to show some logs? We might have a bug
> elsewhere which we don't want to mask by adding this check here.

If we did not add this 'pullups_connected' checking here, it maybe
will kick one transfer to cause a problem of TART_TRANSFER, but it
also can be removed if we check in dwc3_send_gadget_ep_cmd() as you
suggested. Thanks for your comments and I will send out the new patch.


-- 
Baolin.wang
Best Regards


Re: [PATCH v2 1/2] usb: dwc3: gadget: Add disconnect checking when changing function dynamically

2016-09-17 Thread Baolin Wang
Hi Felipe,

Sorry for late reply due to my holiday.

On 9 September 2016 at 18:47, Felipe Balbi  wrote:
>
> Hi,
>
> Baolin Wang  writes:
>> When system has stpped the gadget, we should avoid queuing any requests
>> which will cause tranfer failed. Thus adding some disconnect checking to
>> avoid this situation.
>>
>> Signed-off-by: Baolin Wang 
>
> do you mind if we discuss this for a little longer?

Sure.

>
>> ---
>> Changes since v1:
>>  - Split into 2 separate ptaches.
>>  - Choose complete mechanism instead of polling.
>> ---
>>  drivers/usb/dwc3/ep0.c|8 
>>  drivers/usb/dwc3/gadget.c |   12 +---
>>  2 files changed, 17 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/usb/dwc3/ep0.c b/drivers/usb/dwc3/ep0.c
>> index fe79d77..632e5a4 100644
>> --- a/drivers/usb/dwc3/ep0.c
>> +++ b/drivers/usb/dwc3/ep0.c
>> @@ -228,6 +228,14 @@ int dwc3_gadget_ep0_queue(struct usb_ep *ep, struct 
>> usb_request *request,
>>   int ret;
>>
>>   spin_lock_irqsave(>lock, flags);
>> + if (!dwc->pullups_connected) {
>> + dwc3_trace(trace_dwc3_ep0,
>> + "queuing request %p to %s when gadget is disconnected",
>> + request, dep->name);
>> + ret = -ESHUTDOWN;
>> + goto out;
>> + }
>
> I have been thinking about this branch here. It's not a problem to queue
> a request with pullups disconnected. It's only a problem to issue
> START_TRANSFER without RUN_STOP bit set.
>
> So maybe this check should be done in dwc3_send_gadget_ep_cmd(). By
> doing that we also make sure to do the check in one place and one place
> only because all endpoints rely dwc3_send_gadget_ep_cmd().

OK, that makes sense to me.

>
>> diff --git a/drivers/usb/dwc3/gadget.c b/drivers/usb/dwc3/gadget.c
>> index 1783406..1a33308 100644
>> --- a/drivers/usb/dwc3/gadget.c
>> +++ b/drivers/usb/dwc3/gadget.c
>> @@ -1040,6 +1040,13 @@ static int __dwc3_gadget_ep_queue(struct dwc3_ep 
>> *dep, struct dwc3_request *req)
>>   struct dwc3 *dwc = dep->dwc;
>>   int ret;
>>
>> + if (!dwc->pullups_connected) {
>> + dwc3_trace(trace_dwc3_gadget,
>> + "queuing request %p to %s when gadget is disconnected",
>> + >request, dep->endpoint.name);
>> + return -ESHUTDOWN;
>> + }
>> +
>>   if (!dep->endpoint.desc) {
>>   dwc3_trace(trace_dwc3_gadget,
>>   "trying to queue request %p to disabled %s",
>> @@ -1984,13 +1991,12 @@ static int dwc3_cleanup_done_reqs(struct dwc3 *dwc, 
>> struct dwc3_ep *dep,
>>   if (ret)
>>   break;
>>   }
>> -
>
> trailing change.

Ah, sorry. Will remove it.

>
>>   /*
>>* Our endpoint might get disabled by another thread during
>>* dwc3_gadget_giveback(). If that happens, we're just gonna return 1
>>* early on so DWC3_EP_BUSY flag gets cleared
>>*/
>> - if (!dep->endpoint.desc)
>> + if (!dep->endpoint.desc || !dwc->pullups_connected)
>
> I'm still considering this as well. Sure, we kill pullups before the
> descriptor is set to NULL, but that shouldn't be a problem. What will
> happen is:
>
> usb_gadget_disconnect();
> udc->driver->disconnect();
>  for_each_ep() {
>   for_each_request() {
>usb_ep_dequeue();
>   }
>   usb_ep_disable();
>dep->endpoint.desc = NULL;
>  }
> udc->driver->unbind();
> usb_gadget_udc_stop();
>
> I don't see a problem here. Did you manage to trigger any failure when
> you didn't have this check? Care to show some logs? We might have a bug
> elsewhere which we don't want to mask by adding this check here.

If we did not add this 'pullups_connected' checking here, it maybe
will kick one transfer to cause a problem of TART_TRANSFER, but it
also can be removed if we check in dwc3_send_gadget_ep_cmd() as you
suggested. Thanks for your comments and I will send out the new patch.


-- 
Baolin.wang
Best Regards


Re: Runtime failure running sh:qemu in -next due to 'sh: fix copy_from_user()'

2016-09-17 Thread Rob Landley


On 09/16/2016 09:23 PM, Guenter Roeck wrote:
> On 09/16/2016 04:32 PM, Rich Felker wrote:
>>> 4.6.3 from kernel.org.
>>
>> That is utterly ancient and probaby very buggy. I would recommend 5.x+
>> or at the very least 4.7 or 4.8.
>>
> Unfortunately that is the latest one available from kernel.org :-(.
> I'll try to build one myself.

Rich, you really, really need to get an actual release version of
https://github.com/richfelker/musl-cross-make posted.

Rob


Re: Runtime failure running sh:qemu in -next due to 'sh: fix copy_from_user()'

2016-09-17 Thread Rob Landley


On 09/16/2016 09:23 PM, Guenter Roeck wrote:
> On 09/16/2016 04:32 PM, Rich Felker wrote:
>>> 4.6.3 from kernel.org.
>>
>> That is utterly ancient and probaby very buggy. I would recommend 5.x+
>> or at the very least 4.7 or 4.8.
>>
> Unfortunately that is the latest one available from kernel.org :-(.
> I'll try to build one myself.

Rich, you really, really need to get an actual release version of
https://github.com/richfelker/musl-cross-make posted.

Rob


Re: [PATCH 2/8] drm/rockchip: Get rid of some unnecessary code

2016-09-17 Thread Tomasz Figa
Hi Mark,

On Sun, Sep 18, 2016 at 10:50 AM, Mark yao  wrote:
> On 2016年09月14日 20:54, Tomasz Figa wrote:
>>
>> Current code implements prepare_fb and cleanup_fb callbacks only to
>> grab/release fb references, which is already done by atomic framework
>> when creating/destryoing plane state. Let's remove these
>> unused bits.
>>
>> Signed-off-by: Tomasz Figa 
>> ---
>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 --
>>   1 file changed, 18 deletions(-)
>
>
> Hi Tomasz
>
> I think we can't get rid of the prepare_fb and cleanup_fb

I think I have to disagree. Please see below for detailed explanation.

>
> see the reason:
> commit 44d0237a26395ac94160cf23f32769013b365590
> Author: Mark Yao 
> Date:   Fri Apr 29 11:37:20 2016 +0800
>
> drm/rockchip: vop: fix iommu crash with async atomic
>
> After async atomic_commit callback, drm_atomic_clean_old_fb will
> clean all old fb, but because async, the old fb may be also on
> the vop hardware, dma will access the old fb buffer, clean old
> fb will cause iommu page fault.

I think the above is not quite right. Atomic plane state holds a
reference to its fb and old state is not supposed to be destroyed
until the flip completes.

Indeed current rockchip_atomic_commit implementation has following
order of calls: rockchip_atomic_wait_for_complete(),
drm_atomic_helper_cleanup_planes(), drm_atomic_state_free(). This
means that .cleanup_fb() is called from
drm_atomic_helper_cleanup_planes() just before drm_atomic_state_free()
will release references by destroying old plane states. Note that both
are called already after rockchip_atomic_wait_for_complete(), so it
should be already safe to free the old fbs.

So the above fix doesn't really do anything, possibly just covers the
race condition of the original wait for vblank function by delaying
drm_atomic_state_free() a bit.

Moreover, the whole series has been thoroughly tested in Chrome OS 4.4
kernel, including async commits. (There is still a possibility some
newer upstream changes slightly modified the semantics, but I couldn't
find such difference. Actually one of the advantages of atomic helpers
was to avoid manually refcounting the fbs from the driver.)

Best regards,
Tomasz


Re: [PATCH 2/8] drm/rockchip: Get rid of some unnecessary code

2016-09-17 Thread Tomasz Figa
Hi Mark,

On Sun, Sep 18, 2016 at 10:50 AM, Mark yao  wrote:
> On 2016年09月14日 20:54, Tomasz Figa wrote:
>>
>> Current code implements prepare_fb and cleanup_fb callbacks only to
>> grab/release fb references, which is already done by atomic framework
>> when creating/destryoing plane state. Let's remove these
>> unused bits.
>>
>> Signed-off-by: Tomasz Figa 
>> ---
>>   drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 --
>>   1 file changed, 18 deletions(-)
>
>
> Hi Tomasz
>
> I think we can't get rid of the prepare_fb and cleanup_fb

I think I have to disagree. Please see below for detailed explanation.

>
> see the reason:
> commit 44d0237a26395ac94160cf23f32769013b365590
> Author: Mark Yao 
> Date:   Fri Apr 29 11:37:20 2016 +0800
>
> drm/rockchip: vop: fix iommu crash with async atomic
>
> After async atomic_commit callback, drm_atomic_clean_old_fb will
> clean all old fb, but because async, the old fb may be also on
> the vop hardware, dma will access the old fb buffer, clean old
> fb will cause iommu page fault.

I think the above is not quite right. Atomic plane state holds a
reference to its fb and old state is not supposed to be destroyed
until the flip completes.

Indeed current rockchip_atomic_commit implementation has following
order of calls: rockchip_atomic_wait_for_complete(),
drm_atomic_helper_cleanup_planes(), drm_atomic_state_free(). This
means that .cleanup_fb() is called from
drm_atomic_helper_cleanup_planes() just before drm_atomic_state_free()
will release references by destroying old plane states. Note that both
are called already after rockchip_atomic_wait_for_complete(), so it
should be already safe to free the old fbs.

So the above fix doesn't really do anything, possibly just covers the
race condition of the original wait for vblank function by delaying
drm_atomic_state_free() a bit.

Moreover, the whole series has been thoroughly tested in Chrome OS 4.4
kernel, including async commits. (There is still a possibility some
newer upstream changes slightly modified the semantics, but I couldn't
find such difference. Actually one of the advantages of atomic helpers
was to avoid manually refcounting the fbs from the driver.)

Best regards,
Tomasz


Re: [PATCH V3 1/4] ARM64 LPC: Indirect ISA port IO introduced

2016-09-17 Thread zhichang
Hi, Arnd,


On 2016年09月14日 22:23, Arnd Bergmann wrote:
> On Wednesday, September 14, 2016 10:16:28 PM CEST zhichang.yuan wrote:
>>>
>>> No need to guard includes with an #ifdef.
>> If remove #ifdef here, extio.h should not contain any function external 
>> declarations whose definitions are in
>> extio.c compiled only when CONFIG_ARM64_INDIRECT_PIO is yes.
>  
> There is no problem with making declarations visible for functions that
> are not part of the kernel, we do that all the time.
> 
 +#define BUILDS_RW(bwl, type)  
   \
 +static inline void reads##bwl(const volatile void __iomem *addr,\
 +void *buffer, unsigned int count)   \
 +{   \
 +if (count) {\
 +type *buf = buffer; \
 +\
 +do {\
 +type x = __raw_read##bwl(addr); \
 +*buf++ = x; \
 +} while (--count);  \
 +}   \
 +}   \
 +\
 +static inline void writes##bwl(volatile void __iomem *addr, \
 +const void *buffer, unsigned int count) \
 +{   \
 +if (count) {\
 +const type *buf = buffer;   \
 +\
 +do {\
 +__raw_write##bwl(*buf++, addr); \
 +} while (--count);  \
 +}   \
 +}
 +
 +BUILDS_RW(b, u8)
>>>
>>> Why is this in here?
>> the readsb/writesb are defined in asm-generic/io.h which is included later, 
>> but the redefined insb/outsb need
>> to call them. Without these readsb/writesb definition before insb/outsb 
>> redefined, compile error occur.
>>
>> It seems that copy all the definitions of "asm-generic/io.h" is not a good 
>> idea, so I move the definitions of
>> those function needed here
>>
>> Ok. I think your idea below defining in(s)/out(s) in a c file can solve this 
>> issue.
>>
>> #ifdef CONFIG_ARM64_INDIRECT_PIO
>> #define inb inb
>> extern u8 inb(unsigned long addr);
>>
>> #define outb outb
>> extern void outb(u8 value, unsigned long addr);
>>
>> #define insb insb
>> extern void insb(unsigned long addr, void *buffer, unsigned int count);
>>
>> #define outsb outsb
>> extern void outsb(unsigned long addr, const void *buffer, unsigned int 
>> count);
>> #endif
>>
>> and definitions of all these functions are in extio.c :
>>
>> u8 inb(unsigned long addr)
>> {
>> if (!arm64_extio_ops || arm64_extio_ops->start > addr ||
>> arm64_extio_ops->end < addr)
>> return readb(PCI_IOBASE + addr);
>> else
>> return arm64_extio_ops->pfin ?
>> arm64_extio_ops->pfin(arm64_extio_ops->devpara,
>> addr + arm64_extio_ops->ptoffset, NULL,
>> sizeof(u8), 1) : -1;
>> }
>> .
> 
> Yes, sounds good.
> 
 @@ -149,6 +185,60 @@ static inline u64 __raw_readq(const volatile void 
 __iomem *addr)
  #define IO_SPACE_LIMIT  (PCI_IO_SIZE - 1)
  #define PCI_IOBASE  ((void __iomem *)PCI_IO_START)
  
 +
 +/*
 + * redefine the in(s)b/out(s)b for indirect-IO.
 + */
 +#define inb inb
 +static inline u8 inb(unsigned long addr)
 +{
 +#ifdef CONFIG_ARM64_INDIRECT_PIO
 +if (arm64_extio_ops && arm64_extio_ops->start <= addr &&
 +addr <= arm64_extio_ops->end)
 +return extio_inb(addr);
 +#endif
 +return readb(PCI_IOBASE + addr);
 +}
 +
>>>
>>> Looks ok, but you only seem to do this for the 8-bit
>>> accessors, when it should be done for 16-bit and 32-bit
>>> ones as well for consistency.
>> Hip06 LPC only support 8-bit I/O operations on the designated port.
> 
> That is an interesting limitation. Maybe still call the extio operations
> and have them do WARN_ON_ONCE() instead?
> 
> If you get a driver that calls inw/outw on the range that is owned
> by the LPC bus, you otherwise get an unhandled page fault in 

Re: [PATCH V3 1/4] ARM64 LPC: Indirect ISA port IO introduced

2016-09-17 Thread zhichang
Hi, Arnd,


On 2016年09月14日 22:23, Arnd Bergmann wrote:
> On Wednesday, September 14, 2016 10:16:28 PM CEST zhichang.yuan wrote:
>>>
>>> No need to guard includes with an #ifdef.
>> If remove #ifdef here, extio.h should not contain any function external 
>> declarations whose definitions are in
>> extio.c compiled only when CONFIG_ARM64_INDIRECT_PIO is yes.
>  
> There is no problem with making declarations visible for functions that
> are not part of the kernel, we do that all the time.
> 
 +#define BUILDS_RW(bwl, type)  
   \
 +static inline void reads##bwl(const volatile void __iomem *addr,\
 +void *buffer, unsigned int count)   \
 +{   \
 +if (count) {\
 +type *buf = buffer; \
 +\
 +do {\
 +type x = __raw_read##bwl(addr); \
 +*buf++ = x; \
 +} while (--count);  \
 +}   \
 +}   \
 +\
 +static inline void writes##bwl(volatile void __iomem *addr, \
 +const void *buffer, unsigned int count) \
 +{   \
 +if (count) {\
 +const type *buf = buffer;   \
 +\
 +do {\
 +__raw_write##bwl(*buf++, addr); \
 +} while (--count);  \
 +}   \
 +}
 +
 +BUILDS_RW(b, u8)
>>>
>>> Why is this in here?
>> the readsb/writesb are defined in asm-generic/io.h which is included later, 
>> but the redefined insb/outsb need
>> to call them. Without these readsb/writesb definition before insb/outsb 
>> redefined, compile error occur.
>>
>> It seems that copy all the definitions of "asm-generic/io.h" is not a good 
>> idea, so I move the definitions of
>> those function needed here
>>
>> Ok. I think your idea below defining in(s)/out(s) in a c file can solve this 
>> issue.
>>
>> #ifdef CONFIG_ARM64_INDIRECT_PIO
>> #define inb inb
>> extern u8 inb(unsigned long addr);
>>
>> #define outb outb
>> extern void outb(u8 value, unsigned long addr);
>>
>> #define insb insb
>> extern void insb(unsigned long addr, void *buffer, unsigned int count);
>>
>> #define outsb outsb
>> extern void outsb(unsigned long addr, const void *buffer, unsigned int 
>> count);
>> #endif
>>
>> and definitions of all these functions are in extio.c :
>>
>> u8 inb(unsigned long addr)
>> {
>> if (!arm64_extio_ops || arm64_extio_ops->start > addr ||
>> arm64_extio_ops->end < addr)
>> return readb(PCI_IOBASE + addr);
>> else
>> return arm64_extio_ops->pfin ?
>> arm64_extio_ops->pfin(arm64_extio_ops->devpara,
>> addr + arm64_extio_ops->ptoffset, NULL,
>> sizeof(u8), 1) : -1;
>> }
>> .
> 
> Yes, sounds good.
> 
 @@ -149,6 +185,60 @@ static inline u64 __raw_readq(const volatile void 
 __iomem *addr)
  #define IO_SPACE_LIMIT  (PCI_IO_SIZE - 1)
  #define PCI_IOBASE  ((void __iomem *)PCI_IO_START)
  
 +
 +/*
 + * redefine the in(s)b/out(s)b for indirect-IO.
 + */
 +#define inb inb
 +static inline u8 inb(unsigned long addr)
 +{
 +#ifdef CONFIG_ARM64_INDIRECT_PIO
 +if (arm64_extio_ops && arm64_extio_ops->start <= addr &&
 +addr <= arm64_extio_ops->end)
 +return extio_inb(addr);
 +#endif
 +return readb(PCI_IOBASE + addr);
 +}
 +
>>>
>>> Looks ok, but you only seem to do this for the 8-bit
>>> accessors, when it should be done for 16-bit and 32-bit
>>> ones as well for consistency.
>> Hip06 LPC only support 8-bit I/O operations on the designated port.
> 
> That is an interesting limitation. Maybe still call the extio operations
> and have them do WARN_ON_ONCE() instead?
> 
> If you get a driver that calls inw/outw on the range that is owned
> by the LPC bus, you otherwise get an unhandled page fault in 

RE: [PATCH v5 3/3] pci:aer: add support aer interrupt with none MSI/MSI-X/INTx mode

2016-09-17 Thread Po Liu
Hi Shawn,


>  -Original Message-
>  From: Shawn Guo [mailto:shawn...@kernel.org]
>  Sent: Sunday, September 18, 2016 8:52 AM
>  To: Po Liu
>  Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
>  linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; Roy Zang; Arnd
>  Bergmann; Marc Zyngier; Stuart Yoder; Leo Li; M.H. Lian; Murali
>  Karicheri; Bjorn Helgaas; Mingkai Hu
>  Subject: Re: [PATCH v5 3/3] pci:aer: add support aer interrupt with none
>  MSI/MSI-X/INTx mode
>  
>  On Tue, Sep 13, 2016 at 12:40:59PM +0800, Po Liu wrote:
>  > On some platforms, root port doesn't support MSI/MSI-X/INTx in RC mode.
>  > When chip support the aer interrupt with none MSI/MSI-X/INTx mode,
>  > maybe there is interrupt line for aer pme etc. Search the interrupt
>  > number in the fdt file. Then fixup the dev->irq with it.
>  >
>  > Signed-off-by: Po Liu 
>  
>  Will the new kernel work with existing/old DTB?  I'm trying to
>  understand the dependency between driver and DTS changes.

Yes, We've never use name 'intr' before. So we remove it is ok. 
'aer' is a dts name for researching it's true interrupt number by kernel. This 
patch is first time to use name 'aer'. So it must be compatible with 
existing/old DTB.

>  
>  Shawn
>  
>  > ---
>  > changes for v5:
>  >- Add clear 'aer' interrup-names description
>  >
>  >  .../devicetree/bindings/pci/layerscape-pci.txt | 11 +---
>  >  drivers/pci/pcie/portdrv_core.c| 31
>  +++---
>  >  2 files changed, 35 insertions(+), 7 deletions(-)
>  >
>  > diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>  > b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>  > index 41e9f55..101d0a7 100644
>  > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>  > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>  > @@ -18,8 +18,10 @@ Required properties:
>  >  - reg: base addresses and lengths of the PCIe controller
>  >  - interrupts: A list of interrupt outputs of the controller. Must
>  contain an
>  >entry for each entry in the interrupt-names property.
>  > -- interrupt-names: Must include the following entries:
>  > -  "intr": The interrupt that is asserted for controller interrupts
>  > +- interrupt-names: It may be include the following entries:
>  > +  "aer": The interrupt that is asserted for aer interrupt
>  > +  "pme": The interrupt that is asserted for pme interrupt
>  > +  ..
>  >  - fsl,pcie-scfg: Must include two entries.
>  >The first entry must be a link to the SCFG device node
>  >The second entry must be '0' or '1' based on physical PCIe
>  controller index.
>  > @@ -35,8 +37,9 @@ Example:
>  >reg = <0x00 0x0340 0x0 0x0001   /* controller
>  registers */
>  >   0x40 0x 0x0 0x2000>; /* configuration
>  space */
>  >reg-names = "regs", "config";
>  > -  interrupts = ; /*
>  controller interrupt */
>  > -  interrupt-names = "intr";
>  > +  interrupts = , /* aer
>  interrupt */
>  > +  ; /* pme interrupt */
>  > +  interrupt-names = "aer", "pme";
>  >fsl,pcie-scfg = < 0>;
>  >#address-cells = <3>;
>  >#size-cells = <2>;
>  > diff --git a/drivers/pci/pcie/portdrv_core.c
>  > b/drivers/pci/pcie/portdrv_core.c index e9270b4..7c4943d 100644
>  > --- a/drivers/pci/pcie/portdrv_core.c
>  > +++ b/drivers/pci/pcie/portdrv_core.c
>  > @@ -16,6 +16,7 @@
>  >  #include 
>  >  #include 
>  >  #include 
>  > +#include 
>  >
>  >  #include "../pci.h"
>  >  #include "portdrv.h"
>  > @@ -200,6 +201,28 @@ static int pcie_port_enable_msix(struct pci_dev
>  > *dev, int *vectors, int mask)  static int init_service_irqs(struct
>  > pci_dev *dev, int *irqs, int mask)  {
>  >int i, irq = -1;
>  > +  int ret;
>  > +  struct device_node *np = NULL;
>  > +
>  > +  for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
>  > +  irqs[i] = 0;
>  > +
>  > +  if (dev->bus->dev.of_node)
>  > +  np = dev->bus->dev.of_node;
>  > +
>  > +  /* If root port doesn't support MSI/MSI-X/INTx in RC mode,
>  > +   * request irq for aer
>  > +   */
>  > +  if (IS_ENABLED(CONFIG_OF_IRQ) && np &&
>  > +  (mask & PCIE_PORT_SERVICE_PME)) {
>  > +  ret = of_irq_get_byname(np, "aer");
>  > +  if (ret > 0) {
>  > +  irqs[PCIE_PORT_SERVICE_AER_SHIFT] = ret;
>  > +  if (dev->irq)
>  > +  irq = dev->irq;
>  > +  goto no_msi;
>  > +  }
>  > +  }
>  >
>  >/*
>  > * If MSI cannot be used for PCIe PME or hotplug, we have to use
>  @@
>  > -225,11 +248,13 @@ static int init_service_irqs(struct pci_dev *dev,
>  int *irqs, int mask)
>  >irq = dev->irq;
>  >
>  >   no_msi:
>  > -  for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
>  > -  irqs[i] = irq;
>  > +  for (i = 0; i < 

RE: [PATCH v5 3/3] pci:aer: add support aer interrupt with none MSI/MSI-X/INTx mode

2016-09-17 Thread Po Liu
Hi Shawn,


>  -Original Message-
>  From: Shawn Guo [mailto:shawn...@kernel.org]
>  Sent: Sunday, September 18, 2016 8:52 AM
>  To: Po Liu
>  Cc: linux-...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
>  linux-kernel@vger.kernel.org; devicet...@vger.kernel.org; Roy Zang; Arnd
>  Bergmann; Marc Zyngier; Stuart Yoder; Leo Li; M.H. Lian; Murali
>  Karicheri; Bjorn Helgaas; Mingkai Hu
>  Subject: Re: [PATCH v5 3/3] pci:aer: add support aer interrupt with none
>  MSI/MSI-X/INTx mode
>  
>  On Tue, Sep 13, 2016 at 12:40:59PM +0800, Po Liu wrote:
>  > On some platforms, root port doesn't support MSI/MSI-X/INTx in RC mode.
>  > When chip support the aer interrupt with none MSI/MSI-X/INTx mode,
>  > maybe there is interrupt line for aer pme etc. Search the interrupt
>  > number in the fdt file. Then fixup the dev->irq with it.
>  >
>  > Signed-off-by: Po Liu 
>  
>  Will the new kernel work with existing/old DTB?  I'm trying to
>  understand the dependency between driver and DTS changes.

Yes, We've never use name 'intr' before. So we remove it is ok. 
'aer' is a dts name for researching it's true interrupt number by kernel. This 
patch is first time to use name 'aer'. So it must be compatible with 
existing/old DTB.

>  
>  Shawn
>  
>  > ---
>  > changes for v5:
>  >- Add clear 'aer' interrup-names description
>  >
>  >  .../devicetree/bindings/pci/layerscape-pci.txt | 11 +---
>  >  drivers/pci/pcie/portdrv_core.c| 31
>  +++---
>  >  2 files changed, 35 insertions(+), 7 deletions(-)
>  >
>  > diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>  > b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>  > index 41e9f55..101d0a7 100644
>  > --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>  > +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
>  > @@ -18,8 +18,10 @@ Required properties:
>  >  - reg: base addresses and lengths of the PCIe controller
>  >  - interrupts: A list of interrupt outputs of the controller. Must
>  contain an
>  >entry for each entry in the interrupt-names property.
>  > -- interrupt-names: Must include the following entries:
>  > -  "intr": The interrupt that is asserted for controller interrupts
>  > +- interrupt-names: It may be include the following entries:
>  > +  "aer": The interrupt that is asserted for aer interrupt
>  > +  "pme": The interrupt that is asserted for pme interrupt
>  > +  ..
>  >  - fsl,pcie-scfg: Must include two entries.
>  >The first entry must be a link to the SCFG device node
>  >The second entry must be '0' or '1' based on physical PCIe
>  controller index.
>  > @@ -35,8 +37,9 @@ Example:
>  >reg = <0x00 0x0340 0x0 0x0001   /* controller
>  registers */
>  >   0x40 0x 0x0 0x2000>; /* configuration
>  space */
>  >reg-names = "regs", "config";
>  > -  interrupts = ; /*
>  controller interrupt */
>  > -  interrupt-names = "intr";
>  > +  interrupts = , /* aer
>  interrupt */
>  > +  ; /* pme interrupt */
>  > +  interrupt-names = "aer", "pme";
>  >fsl,pcie-scfg = < 0>;
>  >#address-cells = <3>;
>  >#size-cells = <2>;
>  > diff --git a/drivers/pci/pcie/portdrv_core.c
>  > b/drivers/pci/pcie/portdrv_core.c index e9270b4..7c4943d 100644
>  > --- a/drivers/pci/pcie/portdrv_core.c
>  > +++ b/drivers/pci/pcie/portdrv_core.c
>  > @@ -16,6 +16,7 @@
>  >  #include 
>  >  #include 
>  >  #include 
>  > +#include 
>  >
>  >  #include "../pci.h"
>  >  #include "portdrv.h"
>  > @@ -200,6 +201,28 @@ static int pcie_port_enable_msix(struct pci_dev
>  > *dev, int *vectors, int mask)  static int init_service_irqs(struct
>  > pci_dev *dev, int *irqs, int mask)  {
>  >int i, irq = -1;
>  > +  int ret;
>  > +  struct device_node *np = NULL;
>  > +
>  > +  for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
>  > +  irqs[i] = 0;
>  > +
>  > +  if (dev->bus->dev.of_node)
>  > +  np = dev->bus->dev.of_node;
>  > +
>  > +  /* If root port doesn't support MSI/MSI-X/INTx in RC mode,
>  > +   * request irq for aer
>  > +   */
>  > +  if (IS_ENABLED(CONFIG_OF_IRQ) && np &&
>  > +  (mask & PCIE_PORT_SERVICE_PME)) {
>  > +  ret = of_irq_get_byname(np, "aer");
>  > +  if (ret > 0) {
>  > +  irqs[PCIE_PORT_SERVICE_AER_SHIFT] = ret;
>  > +  if (dev->irq)
>  > +  irq = dev->irq;
>  > +  goto no_msi;
>  > +  }
>  > +  }
>  >
>  >/*
>  > * If MSI cannot be used for PCIe PME or hotplug, we have to use
>  @@
>  > -225,11 +248,13 @@ static int init_service_irqs(struct pci_dev *dev,
>  int *irqs, int mask)
>  >irq = dev->irq;
>  >
>  >   no_msi:
>  > -  for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
>  > -  irqs[i] = irq;
>  > +  for (i = 0; i < 

Re: [PATCH] jbd2: move more common code into journal_init_common()

2016-09-17 Thread Geliang Tang
On Thu, Sep 15, 2016 at 03:58:18PM -0400, Theodore Ts'o wrote:
> On Thu, Sep 15, 2016 at 12:03:09PM -0400, Theodore Ts'o wrote:
> > On Wed, Sep 07, 2016 at 03:16:24PM +0200, Jan Kara wrote:
> > > On Wed 07-09-16 20:41:13, Geliang Tang wrote:
> > > > There are some repetitive code in jbd2_journal_init_dev() and
> > > > jbd2_journal_init_inode(). So this patch moves the common code into
> > > > journal_init_common() helper to simplify the code. And fix the coding
> > > > style warnings reported by checkpatch.pl by the way.
> > > > 
> > > > Signed-off-by: Geliang Tang 
> > > 
> > > The patch looks good to me. You can add:
> > > 
> > > Reviewed-by: Jan Kara 
> > 
> > Applied, thanks.
> > 
> 
> Hi Geiliang,
> 
> This patch is causing a WARN_ON:
> 
> [   13.923139] [ cut here ]
> [   13.924644] WARNING: CPU: 0 PID: 2534 at 
> /usr/projects/linux/ext4/fs/proc/generic.c:369 __proc_create+0xe1/0x156
> [   13.926751] name len 0
> [   13.927283] Modules linked in:
> [   13.927954] CPU: 0 PID: 2534 Comm: mount Tainted: GW   
> 4.8.0-rc4-00139-g52c4278 #685
> [   13.929809] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> Debian-1.8.2-1 04/01/2014
> [   13.931643]   0246 f3c1dd3c c13faa3e f3c1dd68 c11cc9c1 
> f3c1dd54 c1087d00
> [   13.933425]  0171 f4727b0c f3c1ddac f5183bc0 f3c1dd70 c1087d44 
> 0009 
> [   13.935199]  f3c1dd68 c1969704 f3c1dd84 f3c1dda0 c11cc9c1 c19696d9 
> 0171 c1969704
> [   13.936987] Call Trace:
> [   13.937507]  [] dump_stack+0x73/0xa5
> [   13.938438]  [] ? __proc_create+0xe1/0x156
> [   13.939503]  [] __warn+0xbc/0xd3
> [   13.940404]  [] warn_slowpath_fmt+0x2d/0x32
> [   13.941470]  [] __proc_create+0xe1/0x156
> [   13.942461]  [] proc_mkdir_data+0x2c/0x6e
> [   13.943484]  [] proc_mkdir+0x13/0x15
> [   13.944425]  [] journal_init_common+0x1a8/0x26a
> [   13.945539]  [] jbd2_journal_init_inode+0xa9/0xfd
> [   13.946702]  [] ext4_fill_super+0x18e5/0x2a92
> [   13.947794]  [] ? bitmap_string.isra.6+0xa9/0xc1
> [   13.948926]  [] mount_bdev+0x114/0x15f
> [   13.950333]  [] ext4_mount+0x15/0x17
> [   13.951985]  [] ? ext4_calculate_overhead+0x30e/0x30e
> [   13.954172]  [] mount_fs+0x58/0x115
> [   13.955789]  [] vfs_kern_mount+0x4c/0xae
> [   13.957588]  [] do_mount+0x6b0/0x8d7
> [   13.959270]  [] ? _copy_from_user+0x44/0x57
> [   13.961140]  [] ? strndup_user+0x31/0x42
> [   13.962919]  [] SyS_mount+0x57/0x7b
> [   13.964609]  [] do_int80_syscall_32+0x4d/0x5f
> [   13.966555]  [] entry_INT80_32+0x2f/0x2f
> [   13.968402] ---[ end trace 2eb7cc6d9a94f309 ]---
> [   14.017482] EXT4-fs (vdc): mounted filesystem with ordered data mode. 
> Opts: (null)
> 
> The problem is that journal->j_devname isn't initialized until *after*
> journal_init_common(), and it's used by jbd2_stats_proc_init(), which
> is called by journal_init_common().
> 
> To fix it I applied the following fix on top of your patch.
> 
>- Ted
> 
> diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
> index 07e14ef..927da49 100644
> --- a/fs/jbd2/journal.c
> +++ b/fs/jbd2/journal.c
> @@ -1141,13 +1141,11 @@ static journal_t *journal_init_common(struct 
> block_device *bdev,
>   journal->j_fs_dev = fs_dev;
>   journal->j_blk_offset = start;
>   journal->j_maxlen = len;
> - jbd2_stats_proc_init(journal);
>   n = journal->j_blocksize / sizeof(journal_block_tag_t);
>   journal->j_wbufsize = n;
>   journal->j_wbuf = kmalloc_array(n, sizeof(struct buffer_head *),
>   GFP_KERNEL);
>   if (!journal->j_wbuf) {
> - jbd2_stats_proc_exit(journal);
>   kfree(journal);
>   return NULL;
>   }
> @@ -1157,7 +1155,6 @@ static journal_t *journal_init_common(struct 
> block_device *bdev,
>   pr_err("%s: Cannot get buffer for journal superblock\n",
>   __func__);
>   kfree(journal->j_wbuf);
> - jbd2_stats_proc_exit(journal);
>   kfree(journal);
>   return NULL;
>   }
> @@ -1202,6 +1199,7 @@ journal_t *jbd2_journal_init_dev(struct block_device 
> *bdev,
>  
>   bdevname(journal->j_dev, journal->j_devname);
>   strreplace(journal->j_devname, '/', '!');
> + jbd2_stats_proc_init(journal);
>  
>   return journal;
>  }
> @@ -1241,6 +1239,7 @@ journal_t *jbd2_journal_init_inode(struct inode *inode)
>   bdevname(journal->j_dev, journal->j_devname);
>   p = strreplace(journal->j_devname, '/', '!');
>   sprintf(p, "-%lu", journal->j_inode->i_ino);
> + jbd2_stats_proc_init(journal);
>  
>   return journal;
>  }

Thanks Ted, this looks fine to me.

-Geliang


Re: [PATCH] jbd2: move more common code into journal_init_common()

2016-09-17 Thread Geliang Tang
On Thu, Sep 15, 2016 at 03:58:18PM -0400, Theodore Ts'o wrote:
> On Thu, Sep 15, 2016 at 12:03:09PM -0400, Theodore Ts'o wrote:
> > On Wed, Sep 07, 2016 at 03:16:24PM +0200, Jan Kara wrote:
> > > On Wed 07-09-16 20:41:13, Geliang Tang wrote:
> > > > There are some repetitive code in jbd2_journal_init_dev() and
> > > > jbd2_journal_init_inode(). So this patch moves the common code into
> > > > journal_init_common() helper to simplify the code. And fix the coding
> > > > style warnings reported by checkpatch.pl by the way.
> > > > 
> > > > Signed-off-by: Geliang Tang 
> > > 
> > > The patch looks good to me. You can add:
> > > 
> > > Reviewed-by: Jan Kara 
> > 
> > Applied, thanks.
> > 
> 
> Hi Geiliang,
> 
> This patch is causing a WARN_ON:
> 
> [   13.923139] [ cut here ]
> [   13.924644] WARNING: CPU: 0 PID: 2534 at 
> /usr/projects/linux/ext4/fs/proc/generic.c:369 __proc_create+0xe1/0x156
> [   13.926751] name len 0
> [   13.927283] Modules linked in:
> [   13.927954] CPU: 0 PID: 2534 Comm: mount Tainted: GW   
> 4.8.0-rc4-00139-g52c4278 #685
> [   13.929809] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
> Debian-1.8.2-1 04/01/2014
> [   13.931643]   0246 f3c1dd3c c13faa3e f3c1dd68 c11cc9c1 
> f3c1dd54 c1087d00
> [   13.933425]  0171 f4727b0c f3c1ddac f5183bc0 f3c1dd70 c1087d44 
> 0009 
> [   13.935199]  f3c1dd68 c1969704 f3c1dd84 f3c1dda0 c11cc9c1 c19696d9 
> 0171 c1969704
> [   13.936987] Call Trace:
> [   13.937507]  [] dump_stack+0x73/0xa5
> [   13.938438]  [] ? __proc_create+0xe1/0x156
> [   13.939503]  [] __warn+0xbc/0xd3
> [   13.940404]  [] warn_slowpath_fmt+0x2d/0x32
> [   13.941470]  [] __proc_create+0xe1/0x156
> [   13.942461]  [] proc_mkdir_data+0x2c/0x6e
> [   13.943484]  [] proc_mkdir+0x13/0x15
> [   13.944425]  [] journal_init_common+0x1a8/0x26a
> [   13.945539]  [] jbd2_journal_init_inode+0xa9/0xfd
> [   13.946702]  [] ext4_fill_super+0x18e5/0x2a92
> [   13.947794]  [] ? bitmap_string.isra.6+0xa9/0xc1
> [   13.948926]  [] mount_bdev+0x114/0x15f
> [   13.950333]  [] ext4_mount+0x15/0x17
> [   13.951985]  [] ? ext4_calculate_overhead+0x30e/0x30e
> [   13.954172]  [] mount_fs+0x58/0x115
> [   13.955789]  [] vfs_kern_mount+0x4c/0xae
> [   13.957588]  [] do_mount+0x6b0/0x8d7
> [   13.959270]  [] ? _copy_from_user+0x44/0x57
> [   13.961140]  [] ? strndup_user+0x31/0x42
> [   13.962919]  [] SyS_mount+0x57/0x7b
> [   13.964609]  [] do_int80_syscall_32+0x4d/0x5f
> [   13.966555]  [] entry_INT80_32+0x2f/0x2f
> [   13.968402] ---[ end trace 2eb7cc6d9a94f309 ]---
> [   14.017482] EXT4-fs (vdc): mounted filesystem with ordered data mode. 
> Opts: (null)
> 
> The problem is that journal->j_devname isn't initialized until *after*
> journal_init_common(), and it's used by jbd2_stats_proc_init(), which
> is called by journal_init_common().
> 
> To fix it I applied the following fix on top of your patch.
> 
>- Ted
> 
> diff --git a/fs/jbd2/journal.c b/fs/jbd2/journal.c
> index 07e14ef..927da49 100644
> --- a/fs/jbd2/journal.c
> +++ b/fs/jbd2/journal.c
> @@ -1141,13 +1141,11 @@ static journal_t *journal_init_common(struct 
> block_device *bdev,
>   journal->j_fs_dev = fs_dev;
>   journal->j_blk_offset = start;
>   journal->j_maxlen = len;
> - jbd2_stats_proc_init(journal);
>   n = journal->j_blocksize / sizeof(journal_block_tag_t);
>   journal->j_wbufsize = n;
>   journal->j_wbuf = kmalloc_array(n, sizeof(struct buffer_head *),
>   GFP_KERNEL);
>   if (!journal->j_wbuf) {
> - jbd2_stats_proc_exit(journal);
>   kfree(journal);
>   return NULL;
>   }
> @@ -1157,7 +1155,6 @@ static journal_t *journal_init_common(struct 
> block_device *bdev,
>   pr_err("%s: Cannot get buffer for journal superblock\n",
>   __func__);
>   kfree(journal->j_wbuf);
> - jbd2_stats_proc_exit(journal);
>   kfree(journal);
>   return NULL;
>   }
> @@ -1202,6 +1199,7 @@ journal_t *jbd2_journal_init_dev(struct block_device 
> *bdev,
>  
>   bdevname(journal->j_dev, journal->j_devname);
>   strreplace(journal->j_devname, '/', '!');
> + jbd2_stats_proc_init(journal);
>  
>   return journal;
>  }
> @@ -1241,6 +1239,7 @@ journal_t *jbd2_journal_init_inode(struct inode *inode)
>   bdevname(journal->j_dev, journal->j_devname);
>   p = strreplace(journal->j_devname, '/', '!');
>   sprintf(p, "-%lu", journal->j_inode->i_ino);
> + jbd2_stats_proc_init(journal);
>  
>   return journal;
>  }

Thanks Ted, this looks fine to me.

-Geliang


Hello

2016-09-17 Thread Hasher Al Maktoum
Dear Friend,

Your contact details came to me by recommendation, I am interested in investing 
in your country and I believe you have the capabilities of providing the needed 
assistance, solutions and advise in actualizing this, Let me know if you are 
willing to understake this task for me so we can discuss more. I hope to hear 
from you soon.

Regards,
Hasher Al Maktoum
Chairman/Chief Executive Officer
Dubai International Holding Company.


Hello

2016-09-17 Thread Hasher Al Maktoum
Dear Friend,

Your contact details came to me by recommendation, I am interested in investing 
in your country and I believe you have the capabilities of providing the needed 
assistance, solutions and advise in actualizing this, Let me know if you are 
willing to understake this task for me so we can discuss more. I hope to hear 
from you soon.

Regards,
Hasher Al Maktoum
Chairman/Chief Executive Officer
Dubai International Holding Company.


Your payment Released

2016-09-17 Thread First Mile Consulting Inc.
Hello

We want to let you know that record available to us states that sometime ago, 
you were contacted by some people who said they wanted to wire some money into 
your account and you people share at an agreed ratio. You opened communication 
with the consulting company then but after sometime, you cut off communication 
when you were asked to pay certain amount of money to facilitate the transfer 
of the said fund to your account. That transaction is real. It is not a scam.

They want to pay you now. Do reply so that we tell you the steps to follow and 
your get your money within the next few weeks.

Waiting for your reply



John Kulpinski
CEO
First Mile Consulting Inc.


Your payment Released

2016-09-17 Thread First Mile Consulting Inc.
Hello

We want to let you know that record available to us states that sometime ago, 
you were contacted by some people who said they wanted to wire some money into 
your account and you people share at an agreed ratio. You opened communication 
with the consulting company then but after sometime, you cut off communication 
when you were asked to pay certain amount of money to facilitate the transfer 
of the said fund to your account. That transaction is real. It is not a scam.

They want to pay you now. Do reply so that we tell you the steps to follow and 
your get your money within the next few weeks.

Waiting for your reply



John Kulpinski
CEO
First Mile Consulting Inc.


Re: [PATCH linux-firmware 10/12] WHENCE: List new radeon CI and SI smc firmware

2016-09-17 Thread Ben Hutchings
On Sun, Sep 18, 2016 at 03:03:43AM +0100, Ben Hutchings wrote:
[...]
> @@ -2957,6 +2964,7 @@ File: qat_c3xxx.bin
>  File: qat_c3xxx_mmp.bin
>  File: qat_c62x.bin
>  File: qat_c62x_mmp.bin
> +Link: qat_mmp.bin -> qat_895xcc_mmp.bin
>  
>  Licence: Redistributable. See LICENCE.qat_firmware for details
>  
> 

Oops, I'll move that last bit to a separate commit.

Ben.

-- 
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison


signature.asc
Description: Digital signature


Re: [PATCH linux-firmware 10/12] WHENCE: List new radeon CI and SI smc firmware

2016-09-17 Thread Ben Hutchings
On Sun, Sep 18, 2016 at 03:03:43AM +0100, Ben Hutchings wrote:
[...]
> @@ -2957,6 +2964,7 @@ File: qat_c3xxx.bin
>  File: qat_c3xxx_mmp.bin
>  File: qat_c62x.bin
>  File: qat_c62x_mmp.bin
> +Link: qat_mmp.bin -> qat_895xcc_mmp.bin
>  
>  Licence: Redistributable. See LICENCE.qat_firmware for details
>  
> 

Oops, I'll move that last bit to a separate commit.

Ben.

-- 
Ben Hutchings
For every action, there is an equal and opposite criticism. - Harrison


signature.asc
Description: Digital signature


Re: [PATCH v4] stop_machine: Avoid a sleep and wakeup in the stop_one_cpu()

2016-09-17 Thread Cheng Chao
Hi Peter,

  What should I do next? Thanks.

Cheng

on 09/14/2016 10:01 AM, Cheng Chao wrote:
> In case @cpu == smp_proccessor_id(), we can avoid a sleep+wakeup
> by doing a preemption.
> 
> the caller such as sched_exec can benefit from this change.
> 
> Signed-off-by: Cheng Chao 
> Cc: Oleg Nesterov 
> Cc: Peter Zijlstra 
> ---
>  kernel/sched/core.c   | 8 ++--
>  kernel/stop_machine.c | 5 +
>  2 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index a0086a5..283b662 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1063,8 +1063,12 @@ static int migration_cpu_stop(void *data)
>* holding rq->lock, if p->on_rq == 0 it cannot get enqueued because
>* we're holding p->pi_lock.
>*/
> - if (task_rq(p) == rq && task_on_rq_queued(p))
> - rq = __migrate_task(rq, p, arg->dest_cpu);
> + if (task_rq(p) == rq) {
> + if (task_on_rq_queued(p))
> + rq = __migrate_task(rq, p, arg->dest_cpu);
> + else
> + p->wake_cpu = arg->dest_cpu;
> + }
>   raw_spin_unlock(>lock);
>   raw_spin_unlock(>pi_lock);
>  
> diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
> index 4a1ca5f..1a24890 100644
> --- a/kernel/stop_machine.c
> +++ b/kernel/stop_machine.c
> @@ -126,6 +126,11 @@ int stop_one_cpu(unsigned int cpu, cpu_stop_fn_t fn, 
> void *arg)
>   cpu_stop_init_done(, 1);
>   if (!cpu_stop_queue_work(cpu, ))
>   return -ENOENT;
> + /*
> +  * In case @cpu == smp_proccessor_id() we can avoid a sleep+wakeup
> +  * by doing a preemption.
> +  */
> + cond_resched();
>   wait_for_completion();
>   return done.ret;
>  }
> 


Re: [PATCH v4] stop_machine: Avoid a sleep and wakeup in the stop_one_cpu()

2016-09-17 Thread Cheng Chao
Hi Peter,

  What should I do next? Thanks.

Cheng

on 09/14/2016 10:01 AM, Cheng Chao wrote:
> In case @cpu == smp_proccessor_id(), we can avoid a sleep+wakeup
> by doing a preemption.
> 
> the caller such as sched_exec can benefit from this change.
> 
> Signed-off-by: Cheng Chao 
> Cc: Oleg Nesterov 
> Cc: Peter Zijlstra 
> ---
>  kernel/sched/core.c   | 8 ++--
>  kernel/stop_machine.c | 5 +
>  2 files changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index a0086a5..283b662 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1063,8 +1063,12 @@ static int migration_cpu_stop(void *data)
>* holding rq->lock, if p->on_rq == 0 it cannot get enqueued because
>* we're holding p->pi_lock.
>*/
> - if (task_rq(p) == rq && task_on_rq_queued(p))
> - rq = __migrate_task(rq, p, arg->dest_cpu);
> + if (task_rq(p) == rq) {
> + if (task_on_rq_queued(p))
> + rq = __migrate_task(rq, p, arg->dest_cpu);
> + else
> + p->wake_cpu = arg->dest_cpu;
> + }
>   raw_spin_unlock(>lock);
>   raw_spin_unlock(>pi_lock);
>  
> diff --git a/kernel/stop_machine.c b/kernel/stop_machine.c
> index 4a1ca5f..1a24890 100644
> --- a/kernel/stop_machine.c
> +++ b/kernel/stop_machine.c
> @@ -126,6 +126,11 @@ int stop_one_cpu(unsigned int cpu, cpu_stop_fn_t fn, 
> void *arg)
>   cpu_stop_init_done(, 1);
>   if (!cpu_stop_queue_work(cpu, ))
>   return -ENOENT;
> + /*
> +  * In case @cpu == smp_proccessor_id() we can avoid a sleep+wakeup
> +  * by doing a preemption.
> +  */
> + cond_resched();
>   wait_for_completion();
>   return done.ret;
>  }
> 


[PATCH linux-firmware 12/12] README: Say that files must be listed in WHENCE, and how to check it

2016-09-17 Thread Ben Hutchings
- Say that new files must, not 'should', be listed in WHENCE
- State the expected form of a reference to a separate licence file
- Mention 'make check'

Signed-off-by: Ben Hutchings 
---
 README | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/README b/README
index cdaecf04b46e..77ff0106c483 100644
--- a/README
+++ b/README
@@ -16,16 +16,19 @@ diff or preferably a git pull request to:
   linux-firmw...@kernel.org
 and also cc: to related mailing lists.
 
-Your commit should include an update to the WHENCE file clearly
-identifying the license under which the firmware is available, and
+If your commit adds new firmware, it must update the WHENCE file to
+clearly state the license under which the firmware is available, and
 that it is redistributable. Being redistributable includes ensuring
 the firmware license provided includes an implicit or explicit
 patent grant to end users to ensure full functionality of device
 operation with the firmware. If the license is long and involved, it's
 permitted to include it in a separate file and refer to it from the
-WHENCE file.
+WHENCE file ('See LICENSE.foo for details.').
 And if it were possible, a changelog of the firmware itself.
 
+Run 'make check' to check that WHENCE is consistent with the
+repository contents.
+
 Ideally, your commit should contain a Signed-Off-By: from someone
 authoritative on the licensing of the firmware in question (i.e. from
 within the company that owns the code).


signature.asc
Description: Digital signature


[PATCH linux-firmware 11/12] WHENCE: Add reference to 'qca/NOTICE.txt'

2016-09-17 Thread Ben Hutchings
Signed-off-by: Ben Hutchings 
---
 WHENCE | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/WHENCE b/WHENCE
index 64fea97a20dc..aafd503f9447 100644
--- a/WHENCE
+++ b/WHENCE
@@ -3144,7 +3144,7 @@ File: qca/rampatch_usb_0302.bin
 File: qca/rampatch_00130300.bin
 File: qca/rampatch_00130302.bin
 
-Licence: Redistributable. See LICENSE.QualcommAtheros_ath10k for details
+Licence: Redistributable. See LICENSE.QualcommAtheros_ath10k and 
qca/NOTICE.txt for details
 
 --
 



signature.asc
Description: Digital signature


[PATCH linux-firmware 12/12] README: Say that files must be listed in WHENCE, and how to check it

2016-09-17 Thread Ben Hutchings
- Say that new files must, not 'should', be listed in WHENCE
- State the expected form of a reference to a separate licence file
- Mention 'make check'

Signed-off-by: Ben Hutchings 
---
 README | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/README b/README
index cdaecf04b46e..77ff0106c483 100644
--- a/README
+++ b/README
@@ -16,16 +16,19 @@ diff or preferably a git pull request to:
   linux-firmw...@kernel.org
 and also cc: to related mailing lists.
 
-Your commit should include an update to the WHENCE file clearly
-identifying the license under which the firmware is available, and
+If your commit adds new firmware, it must update the WHENCE file to
+clearly state the license under which the firmware is available, and
 that it is redistributable. Being redistributable includes ensuring
 the firmware license provided includes an implicit or explicit
 patent grant to end users to ensure full functionality of device
 operation with the firmware. If the license is long and involved, it's
 permitted to include it in a separate file and refer to it from the
-WHENCE file.
+WHENCE file ('See LICENSE.foo for details.').
 And if it were possible, a changelog of the firmware itself.
 
+Run 'make check' to check that WHENCE is consistent with the
+repository contents.
+
 Ideally, your commit should contain a Signed-Off-By: from someone
 authoritative on the licensing of the firmware in question (i.e. from
 within the company that owns the code).


signature.asc
Description: Digital signature


[PATCH linux-firmware 11/12] WHENCE: Add reference to 'qca/NOTICE.txt'

2016-09-17 Thread Ben Hutchings
Signed-off-by: Ben Hutchings 
---
 WHENCE | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/WHENCE b/WHENCE
index 64fea97a20dc..aafd503f9447 100644
--- a/WHENCE
+++ b/WHENCE
@@ -3144,7 +3144,7 @@ File: qca/rampatch_usb_0302.bin
 File: qca/rampatch_00130300.bin
 File: qca/rampatch_00130302.bin
 
-Licence: Redistributable. See LICENSE.QualcommAtheros_ath10k for details
+Licence: Redistributable. See LICENSE.QualcommAtheros_ath10k and 
qca/NOTICE.txt for details
 
 --
 



signature.asc
Description: Digital signature


[PATCH linux-firmware 10/12] WHENCE: List new radeon CI and SI smc firmware

2016-09-17 Thread Ben Hutchings
These were added in commits 406964300821, 9693ff6d749d.

Signed-off-by: Ben Hutchings 
---
 WHENCE | 8 
 1 file changed, 8 insertions(+)

diff --git a/WHENCE b/WHENCE
index df69dd8cbc75..64fea97a20dc 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1743,36 +1743,42 @@ File: radeon/MULLINS_pfp.bin
 File: radeon/MULLINS_rlc.bin
 File: radeon/MULLINS_sdma.bin
 File: radeon/pitcairn_ce.bin
+File: radeon/pitcairn_k_smc.bin
 File: radeon/pitcairn_mc.bin
 File: radeon/pitcairn_me.bin
 File: radeon/pitcairn_pfp.bin
 File: radeon/pitcairn_rlc.bin
 File: radeon/pitcairn_smc.bin
 File: radeon/tahiti_ce.bin
+File: radeon/tahiti_k_smc.bin
 File: radeon/tahiti_mc.bin
 File: radeon/tahiti_me.bin
 File: radeon/tahiti_pfp.bin
 File: radeon/tahiti_rlc.bin
 File: radeon/tahiti_smc.bin
 File: radeon/verde_ce.bin
+File: radeon/verde_k_smc.bin
 File: radeon/verde_mc.bin
 File: radeon/verde_me.bin
 File: radeon/verde_pfp.bin
 File: radeon/verde_rlc.bin
 File: radeon/verde_smc.bin
 File: radeon/oland_ce.bin
+File: radeon/oland_k_smc.bin
 File: radeon/oland_mc.bin
 File: radeon/oland_me.bin
 File: radeon/oland_pfp.bin
 File: radeon/oland_rlc.bin
 File: radeon/oland_smc.bin
 File: radeon/hainan_ce.bin
+File: radeon/hainan_k_smc.bin
 File: radeon/hainan_mc.bin
 File: radeon/hainan_me.bin
 File: radeon/hainan_pfp.bin
 File: radeon/hainan_rlc.bin
 File: radeon/hainan_smc.bin
 File: radeon/bonaire_ce.bin
+File: radeon/bonaire_k_smc.bin
 File: radeon/bonaire_mc.bin
 File: radeon/bonaire_me.bin
 File: radeon/bonaire_mec.bin
@@ -1803,6 +1809,7 @@ File: radeon/kaveri_sdma1.bin
 File: radeon/kaveri_uvd.bin
 File: radeon/kaveri_vce.bin
 File: radeon/hawaii_ce.bin
+File: radeon/hawaii_k_smc.bin
 File: radeon/hawaii_mc.bin
 File: radeon/hawaii_me.bin
 File: radeon/hawaii_mec.bin
@@ -2957,6 +2964,7 @@ File: qat_c3xxx.bin
 File: qat_c3xxx_mmp.bin
 File: qat_c62x.bin
 File: qat_c62x_mmp.bin
+Link: qat_mmp.bin -> qat_895xcc_mmp.bin
 
 Licence: Redistributable. See LICENCE.qat_firmware for details
 



signature.asc
Description: Digital signature


[PATCH linux-firmware 08/12] WHENCE: Adjust some licence file references to satisfy check_whence.py

2016-09-17 Thread Ben Hutchings
Signed-off-by: Ben Hutchings 
---
 WHENCE | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/WHENCE b/WHENCE
index 93927fcfe627..17dda3bfb16f 100644
--- a/WHENCE
+++ b/WHENCE
@@ -469,8 +469,7 @@ Version: 1.4.0
 File: ath9k_htc/htc_9271-1.4.0.fw
 Version: 1.4.0
 
-Licence: Redistributable (full source code is available under free
-software licences). See LICENCE.open-ath9k-htc-firmware for details
+Licence: Free software. See LICENCE.open-ath9k-htc-firmware for details
 
 --
 
@@ -2959,7 +2958,8 @@ File: qat_c3xxx_mmp.bin
 File: qat_c62x.bin
 File: qat_c62x_mmp.bin
 
-Licence: Redistributable. See LICENCE.qat_firmware
+Licence: Redistributable. See LICENCE.qat_firmware for details
+
 --
 
 Driver: rsi -- Redpine Signals Inc 91x driver



signature.asc
Description: Digital signature


[PATCH linux-firmware 09/12] WHENCE: Fix metadata for snd-soc-skl firmware

2016-09-17 Thread Ben Hutchings
Fix filename 'intel/dsp_fw_bxtn.bin'.  List all the files and their
versions, not just the symlinks.  Delete the non-standard 'md5sum'
fields.

Signed-off-by: Ben Hutchings 
---
 WHENCE | 30 --
 1 file changed, 24 insertions(+), 6 deletions(-)

diff --git a/WHENCE b/WHENCE
index 17dda3bfb16f..df69dd8cbc75 100644
--- a/WHENCE
+++ b/WHENCE
@@ -3041,21 +3041,39 @@ License: Redistributable. See LICENCE.fw_sst_0f28 for 
details
 
 Driver: snd-soc-skl
 
-File: intel/dsp_fw_release.bin
+File: intel/dsp_fw_release_v827.bin
+Version: 8.20.00.927
+File: intel/dsp_fw_release_v869.bin
+Version; 8.20.00.869
+File: intel/dsp_fw_release_v896.bin
+Version: 8.20.00.896
+File: intel/dsp_fw_release_v927.bin
+Version: 8.20.00.927
+File: intel/dsp_fw_release_v948.bin
+Version: 8.20.00.948
+File: intel/dsp_fw_release_v951.bin
+Version: 8.20.00.951
+File: intel/dsp_fw_release_v958.bin
 Version: 8.20.00.958
-md5sum: 02bd300f5ef85ae04afffd7c0ef50c46
+Link: intel/dsp_fw_release.bin -> dsp_fw_release_v958.bin
 
 License: Redistributable. See LICENCE.adsp_sst for details
 
-File: intel/dsp_fw_bxt.bin
+File: intel/dsp_fw_bxtn_v430.bin
+Version: 9.00.00.430
+File: intel/dsp_fw_bxtn_v702.bin
+Version: 9.00.00.702
+File: intel/dsp_fw_bxtn_v1118.bin
 Version: 9.22.00.1118
-md5sum: 469dfcf5b2ebbc58505a0cca23303723
+Link: intel/dsp_fw_bxtn.bin -> dsp_fw_bxtn_v1118.bin
 
 License: Redistributable. See LICENCE.adsp_sst for details
 
-File: intel/dsp_fw_kbl.bin
+File: intel/dsp_fw_kbl_v701.bin
+Version: 9.21.00.701
+File: intel/dsp_fw_kbl_v1037.bin
 Version: 09.21.00.1037
-md5sum: e71a2421565fadae228b3924d9510bcb
+Link: intel/dsp_fw_kbl.bin -> dsp_fw_kbl_v1037.bin
 
 License: Redistributable. See LICENCE.adsp_sst for details
 



signature.asc
Description: Digital signature


[PATCH linux-firmware 08/12] WHENCE: Adjust some licence file references to satisfy check_whence.py

2016-09-17 Thread Ben Hutchings
Signed-off-by: Ben Hutchings 
---
 WHENCE | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/WHENCE b/WHENCE
index 93927fcfe627..17dda3bfb16f 100644
--- a/WHENCE
+++ b/WHENCE
@@ -469,8 +469,7 @@ Version: 1.4.0
 File: ath9k_htc/htc_9271-1.4.0.fw
 Version: 1.4.0
 
-Licence: Redistributable (full source code is available under free
-software licences). See LICENCE.open-ath9k-htc-firmware for details
+Licence: Free software. See LICENCE.open-ath9k-htc-firmware for details
 
 --
 
@@ -2959,7 +2958,8 @@ File: qat_c3xxx_mmp.bin
 File: qat_c62x.bin
 File: qat_c62x_mmp.bin
 
-Licence: Redistributable. See LICENCE.qat_firmware
+Licence: Redistributable. See LICENCE.qat_firmware for details
+
 --
 
 Driver: rsi -- Redpine Signals Inc 91x driver



signature.asc
Description: Digital signature


[PATCH linux-firmware 09/12] WHENCE: Fix metadata for snd-soc-skl firmware

2016-09-17 Thread Ben Hutchings
Fix filename 'intel/dsp_fw_bxtn.bin'.  List all the files and their
versions, not just the symlinks.  Delete the non-standard 'md5sum'
fields.

Signed-off-by: Ben Hutchings 
---
 WHENCE | 30 --
 1 file changed, 24 insertions(+), 6 deletions(-)

diff --git a/WHENCE b/WHENCE
index 17dda3bfb16f..df69dd8cbc75 100644
--- a/WHENCE
+++ b/WHENCE
@@ -3041,21 +3041,39 @@ License: Redistributable. See LICENCE.fw_sst_0f28 for 
details
 
 Driver: snd-soc-skl
 
-File: intel/dsp_fw_release.bin
+File: intel/dsp_fw_release_v827.bin
+Version: 8.20.00.927
+File: intel/dsp_fw_release_v869.bin
+Version; 8.20.00.869
+File: intel/dsp_fw_release_v896.bin
+Version: 8.20.00.896
+File: intel/dsp_fw_release_v927.bin
+Version: 8.20.00.927
+File: intel/dsp_fw_release_v948.bin
+Version: 8.20.00.948
+File: intel/dsp_fw_release_v951.bin
+Version: 8.20.00.951
+File: intel/dsp_fw_release_v958.bin
 Version: 8.20.00.958
-md5sum: 02bd300f5ef85ae04afffd7c0ef50c46
+Link: intel/dsp_fw_release.bin -> dsp_fw_release_v958.bin
 
 License: Redistributable. See LICENCE.adsp_sst for details
 
-File: intel/dsp_fw_bxt.bin
+File: intel/dsp_fw_bxtn_v430.bin
+Version: 9.00.00.430
+File: intel/dsp_fw_bxtn_v702.bin
+Version: 9.00.00.702
+File: intel/dsp_fw_bxtn_v1118.bin
 Version: 9.22.00.1118
-md5sum: 469dfcf5b2ebbc58505a0cca23303723
+Link: intel/dsp_fw_bxtn.bin -> dsp_fw_bxtn_v1118.bin
 
 License: Redistributable. See LICENCE.adsp_sst for details
 
-File: intel/dsp_fw_kbl.bin
+File: intel/dsp_fw_kbl_v701.bin
+Version: 9.21.00.701
+File: intel/dsp_fw_kbl_v1037.bin
 Version: 09.21.00.1037
-md5sum: e71a2421565fadae228b3924d9510bcb
+Link: intel/dsp_fw_kbl.bin -> dsp_fw_kbl_v1037.bin
 
 License: Redistributable. See LICENCE.adsp_sst for details
 



signature.asc
Description: Digital signature


[PATCH linux-firmware 10/12] WHENCE: List new radeon CI and SI smc firmware

2016-09-17 Thread Ben Hutchings
These were added in commits 406964300821, 9693ff6d749d.

Signed-off-by: Ben Hutchings 
---
 WHENCE | 8 
 1 file changed, 8 insertions(+)

diff --git a/WHENCE b/WHENCE
index df69dd8cbc75..64fea97a20dc 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1743,36 +1743,42 @@ File: radeon/MULLINS_pfp.bin
 File: radeon/MULLINS_rlc.bin
 File: radeon/MULLINS_sdma.bin
 File: radeon/pitcairn_ce.bin
+File: radeon/pitcairn_k_smc.bin
 File: radeon/pitcairn_mc.bin
 File: radeon/pitcairn_me.bin
 File: radeon/pitcairn_pfp.bin
 File: radeon/pitcairn_rlc.bin
 File: radeon/pitcairn_smc.bin
 File: radeon/tahiti_ce.bin
+File: radeon/tahiti_k_smc.bin
 File: radeon/tahiti_mc.bin
 File: radeon/tahiti_me.bin
 File: radeon/tahiti_pfp.bin
 File: radeon/tahiti_rlc.bin
 File: radeon/tahiti_smc.bin
 File: radeon/verde_ce.bin
+File: radeon/verde_k_smc.bin
 File: radeon/verde_mc.bin
 File: radeon/verde_me.bin
 File: radeon/verde_pfp.bin
 File: radeon/verde_rlc.bin
 File: radeon/verde_smc.bin
 File: radeon/oland_ce.bin
+File: radeon/oland_k_smc.bin
 File: radeon/oland_mc.bin
 File: radeon/oland_me.bin
 File: radeon/oland_pfp.bin
 File: radeon/oland_rlc.bin
 File: radeon/oland_smc.bin
 File: radeon/hainan_ce.bin
+File: radeon/hainan_k_smc.bin
 File: radeon/hainan_mc.bin
 File: radeon/hainan_me.bin
 File: radeon/hainan_pfp.bin
 File: radeon/hainan_rlc.bin
 File: radeon/hainan_smc.bin
 File: radeon/bonaire_ce.bin
+File: radeon/bonaire_k_smc.bin
 File: radeon/bonaire_mc.bin
 File: radeon/bonaire_me.bin
 File: radeon/bonaire_mec.bin
@@ -1803,6 +1809,7 @@ File: radeon/kaveri_sdma1.bin
 File: radeon/kaveri_uvd.bin
 File: radeon/kaveri_vce.bin
 File: radeon/hawaii_ce.bin
+File: radeon/hawaii_k_smc.bin
 File: radeon/hawaii_mc.bin
 File: radeon/hawaii_me.bin
 File: radeon/hawaii_mec.bin
@@ -2957,6 +2964,7 @@ File: qat_c3xxx.bin
 File: qat_c3xxx_mmp.bin
 File: qat_c62x.bin
 File: qat_c62x_mmp.bin
+Link: qat_mmp.bin -> qat_895xcc_mmp.bin
 
 Licence: Redistributable. See LICENCE.qat_firmware for details
 



signature.asc
Description: Digital signature


[PATCH linux-firmware 07/12] Remove unused 'LICENCE.mwl8335'

2016-09-17 Thread Ben Hutchings
This was the licence text for mwl8335_duplex.fw which has already been
removed.

Signed-off-by: Ben Hutchings 
---
 LICENCE.mwl8335 | 52 
 1 file changed, 52 deletions(-)
 delete mode 100644 LICENCE.mwl8335

diff --git a/LICENCE.mwl8335 b/LICENCE.mwl8335
deleted file mode 100644
index 0b824521bfdf..
--- a/LICENCE.mwl8335
+++ /dev/null
@@ -1,52 +0,0 @@
-FIRMWARE LICENSE TERMS
-
-
-Copyright (c) Marvell International Ltd.
-
-All rights reserved.
-
-Redistribution. Redistribution and use in binary form, without modification, 
are
-permitted provided that the following conditions are met:
-
-* Redistributions must reproduce the above copyright notice and the following
-disclaimer in the documentation and/or other materials provided with the
-distribution.
-
-* Neither the name of Marvell International Ltd. nor the names of its suppliers
-may be used to endorse or promote products derived from this software without
-specific prior written permission.
-
-* No reverse engineering, decompilation, or disassembly of this software is
-permitted.
-
-Limited patent license. Marvell International Ltd. grants a world-wide,
-royalty-free, non-exclusive license under patents it now or hereafter owns or
-controls to make, have made, use, import, offer to sell and sell ("Utilize")
-this software, but solely to the extent that any such patent is necessary to
-Utilize the software alone, or in combination with an operating system licensed
-under an approved Open Source license as listed by the Open Source Initiative 
at
-http://opensource.org/licenses. The patent license shall not apply to any other
-combinations which include this software. No hardware per se is licensed
-hereunder.
-
-DISCLAIMER. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
-THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE
-FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
-SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
-CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 
OR
-TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
-THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
-
-
-NOTE: this firmware was generated from img_cb35_fw_duplex.h contained in the
-GPL source release of the Maxtor Shared Storage II product available here:
-
-http://www.seagate.com/staticfiles/maxtor/en_us/downloads/MSSII_3.1.2.src.tgz
-
-Explicit permission from Marvell was obtained to upload this firmware to the
-linux-firmware git repository under the Marvell firmware license above.
-



signature.asc
Description: Digital signature


[PATCH linux-firmware 06/12] WHENCE: Remove references to two nvidia firmware files that were never added

2016-09-17 Thread Ben Hutchings
Signed-off-by: Ben Hutchings 
---
 WHENCE | 2 --
 1 file changed, 2 deletions(-)

diff --git a/WHENCE b/WHENCE
index 60028347b443..93927fcfe627 100644
--- a/WHENCE
+++ b/WHENCE
@@ -3227,10 +3227,8 @@ File: nvidia/gm20b/gr/fecs_bl.bin
 File: nvidia/gm20b/gr/fecs_data.bin
 File: nvidia/gm20b/gr/fecs_inst.bin
 File: nvidia/gm20b/gr/fecs_sig.bin
-File: nvidia/gm20b/gr/gpccs_bl.bin
 File: nvidia/gm20b/gr/gpccs_data.bin
 File: nvidia/gm20b/gr/gpccs_inst.bin
-File: nvidia/gm20b/gr/gpccs_sig.bin
 File: nvidia/gm20b/gr/sw_bundle_init.bin
 File: nvidia/gm20b/gr/sw_ctx.bin
 File: nvidia/gm20b/gr/sw_method_init.bin



signature.asc
Description: Digital signature


[PATCH linux-firmware 07/12] Remove unused 'LICENCE.mwl8335'

2016-09-17 Thread Ben Hutchings
This was the licence text for mwl8335_duplex.fw which has already been
removed.

Signed-off-by: Ben Hutchings 
---
 LICENCE.mwl8335 | 52 
 1 file changed, 52 deletions(-)
 delete mode 100644 LICENCE.mwl8335

diff --git a/LICENCE.mwl8335 b/LICENCE.mwl8335
deleted file mode 100644
index 0b824521bfdf..
--- a/LICENCE.mwl8335
+++ /dev/null
@@ -1,52 +0,0 @@
-FIRMWARE LICENSE TERMS
-
-
-Copyright (c) Marvell International Ltd.
-
-All rights reserved.
-
-Redistribution. Redistribution and use in binary form, without modification, 
are
-permitted provided that the following conditions are met:
-
-* Redistributions must reproduce the above copyright notice and the following
-disclaimer in the documentation and/or other materials provided with the
-distribution.
-
-* Neither the name of Marvell International Ltd. nor the names of its suppliers
-may be used to endorse or promote products derived from this software without
-specific prior written permission.
-
-* No reverse engineering, decompilation, or disassembly of this software is
-permitted.
-
-Limited patent license. Marvell International Ltd. grants a world-wide,
-royalty-free, non-exclusive license under patents it now or hereafter owns or
-controls to make, have made, use, import, offer to sell and sell ("Utilize")
-this software, but solely to the extent that any such patent is necessary to
-Utilize the software alone, or in combination with an operating system licensed
-under an approved Open Source license as listed by the Open Source Initiative 
at
-http://opensource.org/licenses. The patent license shall not apply to any other
-combinations which include this software. No hardware per se is licensed
-hereunder.
-
-DISCLAIMER. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
-"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO,
-THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
-ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE
-FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
-DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
-SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
-CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, 
OR
-TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
-THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
-
-
-
-NOTE: this firmware was generated from img_cb35_fw_duplex.h contained in the
-GPL source release of the Maxtor Shared Storage II product available here:
-
-http://www.seagate.com/staticfiles/maxtor/en_us/downloads/MSSII_3.1.2.src.tgz
-
-Explicit permission from Marvell was obtained to upload this firmware to the
-linux-firmware git repository under the Marvell firmware license above.
-



signature.asc
Description: Digital signature


[PATCH linux-firmware 06/12] WHENCE: Remove references to two nvidia firmware files that were never added

2016-09-17 Thread Ben Hutchings
Signed-off-by: Ben Hutchings 
---
 WHENCE | 2 --
 1 file changed, 2 deletions(-)

diff --git a/WHENCE b/WHENCE
index 60028347b443..93927fcfe627 100644
--- a/WHENCE
+++ b/WHENCE
@@ -3227,10 +3227,8 @@ File: nvidia/gm20b/gr/fecs_bl.bin
 File: nvidia/gm20b/gr/fecs_data.bin
 File: nvidia/gm20b/gr/fecs_inst.bin
 File: nvidia/gm20b/gr/fecs_sig.bin
-File: nvidia/gm20b/gr/gpccs_bl.bin
 File: nvidia/gm20b/gr/gpccs_data.bin
 File: nvidia/gm20b/gr/gpccs_inst.bin
-File: nvidia/gm20b/gr/gpccs_sig.bin
 File: nvidia/gm20b/gr/sw_bundle_init.bin
 File: nvidia/gm20b/gr/sw_ctx.bin
 File: nvidia/gm20b/gr/sw_method_init.bin



signature.asc
Description: Digital signature


[PATCH linux-firmware 03/12] Add copy of GPL v2 and references to the GPL-2 and GPL-3 files

2016-09-17 Thread Ben Hutchings
Signed-off-by: Ben Hutchings 
---
 GPL-2  | 339 +
 WHENCE |  16 ++--
 2 files changed, 347 insertions(+), 8 deletions(-)
 create mode 100644 GPL-2

diff --git a/GPL-2 b/GPL-2
new file mode 100644
index ..d159169d1050
--- /dev/null
+++ b/GPL-2
@@ -0,0 +1,339 @@
+GNU GENERAL PUBLIC LICENSE
+   Version 2, June 1991
+
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
+ 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+Preamble
+
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users.  This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it.  (Some other Free Software Foundation software is covered by
+the GNU Lesser General Public License instead.)  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+  To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have.  You must make sure that they, too, receive or can get the
+source code.  And you must show them these terms so they know their
+rights.
+
+  We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+  Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software.  If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+  Finally, any free program is threatened constantly by software
+patents.  We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary.  To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+GNU GENERAL PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License.  The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language.  (Hereinafter, translation is included without limitation in
+the term "modification".)  Each licensee is addressed as "you".
+
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope.  The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.
+
+  1. You may copy and distribute verbatim copies of the Program's
+source code as you receive it, in any medium, provided that you
+conspicuously and appropriately publish on each copy an appropriate
+copyright notice and disclaimer of warranty; keep intact all the
+notices that refer to this License and to the absence of any warranty;
+and give any other recipients of the Program a copy of this License
+along with the Program.
+
+You may charge a fee for the physical act of transferring a copy, and
+you may at your option offer warranty 

[PATCH linux-firmware 05/12] WHENCE: Remove references to source for emi62 firmware

2016-09-17 Thread Ben Hutchings
The 'sources' appear to be the names of ihex files, not actual source
code, and in any case those files are not included in this repository.

Signed-off-by: Ben Hutchings 
---
 WHENCE | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/WHENCE b/WHENCE
index 372f111c1b01..60028347b443 100644
--- a/WHENCE
+++ b/WHENCE
@@ -221,17 +221,14 @@ Version: 1.0.0.191
 Info: DATE= 2002oct28
 
 File: emi62/loader.fw
-Source: EMILOAD.HEX
 Version: 1.0.2.002
 Info: DATE=10.01.2002
 
 File: emi62/midi.fw
-Source: EMI62MFW.HEX
 Version: 1.04.062
 Info: DATE=16.10.2002
 
 File: emi62/spdif.fw
-Source: EMI62SFW.HEX
 Version: 1.04.062
 Info: DATE=16.10.2002
 



signature.asc
Description: Digital signature


[PATCH linux-firmware 04/12] WHENCE: Specify source directories for cis, isci, and usbdux firmware

2016-09-17 Thread Ben Hutchings
This stops check_whence.py complaining about Makefiles etc.

Signed-off-by: Ben Hutchings 
---
 WHENCE | 18 +++---
 1 file changed, 3 insertions(+), 15 deletions(-)

diff --git a/WHENCE b/WHENCE
index 6ca42394eeb7..372f111c1b01 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1074,13 +1074,7 @@ File: cis/NE2K.cis
 File: cis/tamarack.cis
 File: cis/PE-200.cis
 File: cis/PE520.cis
-Source: cis/src/LA-PCM.cis
-Source: cis/src/PCMLM28.cis
-Source: cis/src/DP83903.cis
-Source: cis/src/NE2K.cis
-Source: cis/src/tamarack.cis
-Source: cis/src/PE-200.cis
-Source: cis/src/PE520.cis
+Source: cis/
 
 Licence: Dual GPLv2/MPL
 
@@ -1450,10 +1444,7 @@ Driver: usbdux/usbduxfast/usbduxsigma - usbdux data 
acquisition cards
 File: usbdux_firmware.bin
 File: usbduxfast_firmware.bin
 File: usbduxsigma_firmware.bin
-Source: usbdux/fx2-include.asm
-Source: usbdux/usbduxfast_firmware.asm
-Source: usbdux/usbdux_firmware.asm
-Source: usbdux/usbduxsigma_firmware.asm
+Source: usbdux/
 
 Licence: GPLv2. See GPL-2 for details.
 
@@ -2704,10 +2695,7 @@ Licence: Redistributable. See LICENCE.ene_firmware for 
details.
 Driver: isci -- Intel C600 SAS controller driver
 
 File: isci/isci_firmware.bin
-Source: isci/create_fw.c
-Source: isci/create_fw.h
-Source: isci/probe_roms.h
-Source: isci/Makefile
+Source: isci/
 
 Licence: GPLv2. See GPL-2 for details.
 



signature.asc
Description: Digital signature


[PATCH linux-firmware 03/12] Add copy of GPL v2 and references to the GPL-2 and GPL-3 files

2016-09-17 Thread Ben Hutchings
Signed-off-by: Ben Hutchings 
---
 GPL-2  | 339 +
 WHENCE |  16 ++--
 2 files changed, 347 insertions(+), 8 deletions(-)
 create mode 100644 GPL-2

diff --git a/GPL-2 b/GPL-2
new file mode 100644
index ..d159169d1050
--- /dev/null
+++ b/GPL-2
@@ -0,0 +1,339 @@
+GNU GENERAL PUBLIC LICENSE
+   Version 2, June 1991
+
+ Copyright (C) 1989, 1991 Free Software Foundation, Inc.,
+ 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ Everyone is permitted to copy and distribute verbatim copies
+ of this license document, but changing it is not allowed.
+
+Preamble
+
+  The licenses for most software are designed to take away your
+freedom to share and change it.  By contrast, the GNU General Public
+License is intended to guarantee your freedom to share and change free
+software--to make sure the software is free for all its users.  This
+General Public License applies to most of the Free Software
+Foundation's software and to any other program whose authors commit to
+using it.  (Some other Free Software Foundation software is covered by
+the GNU Lesser General Public License instead.)  You can apply it to
+your programs, too.
+
+  When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+this service if you wish), that you receive source code or can get it
+if you want it, that you can change the software or use pieces of it
+in new free programs; and that you know you can do these things.
+
+  To protect your rights, we need to make restrictions that forbid
+anyone to deny you these rights or to ask you to surrender the rights.
+These restrictions translate to certain responsibilities for you if you
+distribute copies of the software, or if you modify it.
+
+  For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must give the recipients all the rights that
+you have.  You must make sure that they, too, receive or can get the
+source code.  And you must show them these terms so they know their
+rights.
+
+  We protect your rights with two steps: (1) copyright the software, and
+(2) offer you this license which gives you legal permission to copy,
+distribute and/or modify the software.
+
+  Also, for each author's protection and ours, we want to make certain
+that everyone understands that there is no warranty for this free
+software.  If the software is modified by someone else and passed on, we
+want its recipients to know that what they have is not the original, so
+that any problems introduced by others will not reflect on the original
+authors' reputations.
+
+  Finally, any free program is threatened constantly by software
+patents.  We wish to avoid the danger that redistributors of a free
+program will individually obtain patent licenses, in effect making the
+program proprietary.  To prevent this, we have made it clear that any
+patent must be licensed for everyone's free use or not licensed at all.
+
+  The precise terms and conditions for copying, distribution and
+modification follow.
+
+GNU GENERAL PUBLIC LICENSE
+   TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
+
+  0. This License applies to any program or other work which contains
+a notice placed by the copyright holder saying it may be distributed
+under the terms of this General Public License.  The "Program", below,
+refers to any such program or work, and a "work based on the Program"
+means either the Program or any derivative work under copyright law:
+that is to say, a work containing the Program or a portion of it,
+either verbatim or with modifications and/or translated into another
+language.  (Hereinafter, translation is included without limitation in
+the term "modification".)  Each licensee is addressed as "you".
+
+Activities other than copying, distribution and modification are not
+covered by this License; they are outside its scope.  The act of
+running the Program is not restricted, and the output from the Program
+is covered only if its contents constitute a work based on the
+Program (independent of having been made by running the Program).
+Whether that is true depends on what the Program does.
+
+  1. You may copy and distribute verbatim copies of the Program's
+source code as you receive it, in any medium, provided that you
+conspicuously and appropriately publish on each copy an appropriate
+copyright notice and disclaimer of warranty; keep intact all the
+notices that refer to this License and to the absence of any warranty;
+and give any other recipients of the Program a copy of this License
+along with the Program.
+
+You may charge a fee for the physical act of transferring a copy, and
+you may at your option offer warranty protection in 

[PATCH linux-firmware 05/12] WHENCE: Remove references to source for emi62 firmware

2016-09-17 Thread Ben Hutchings
The 'sources' appear to be the names of ihex files, not actual source
code, and in any case those files are not included in this repository.

Signed-off-by: Ben Hutchings 
---
 WHENCE | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/WHENCE b/WHENCE
index 372f111c1b01..60028347b443 100644
--- a/WHENCE
+++ b/WHENCE
@@ -221,17 +221,14 @@ Version: 1.0.0.191
 Info: DATE= 2002oct28
 
 File: emi62/loader.fw
-Source: EMILOAD.HEX
 Version: 1.0.2.002
 Info: DATE=10.01.2002
 
 File: emi62/midi.fw
-Source: EMI62MFW.HEX
 Version: 1.04.062
 Info: DATE=16.10.2002
 
 File: emi62/spdif.fw
-Source: EMI62SFW.HEX
 Version: 1.04.062
 Info: DATE=16.10.2002
 



signature.asc
Description: Digital signature


[PATCH linux-firmware 04/12] WHENCE: Specify source directories for cis, isci, and usbdux firmware

2016-09-17 Thread Ben Hutchings
This stops check_whence.py complaining about Makefiles etc.

Signed-off-by: Ben Hutchings 
---
 WHENCE | 18 +++---
 1 file changed, 3 insertions(+), 15 deletions(-)

diff --git a/WHENCE b/WHENCE
index 6ca42394eeb7..372f111c1b01 100644
--- a/WHENCE
+++ b/WHENCE
@@ -1074,13 +1074,7 @@ File: cis/NE2K.cis
 File: cis/tamarack.cis
 File: cis/PE-200.cis
 File: cis/PE520.cis
-Source: cis/src/LA-PCM.cis
-Source: cis/src/PCMLM28.cis
-Source: cis/src/DP83903.cis
-Source: cis/src/NE2K.cis
-Source: cis/src/tamarack.cis
-Source: cis/src/PE-200.cis
-Source: cis/src/PE520.cis
+Source: cis/
 
 Licence: Dual GPLv2/MPL
 
@@ -1450,10 +1444,7 @@ Driver: usbdux/usbduxfast/usbduxsigma - usbdux data 
acquisition cards
 File: usbdux_firmware.bin
 File: usbduxfast_firmware.bin
 File: usbduxsigma_firmware.bin
-Source: usbdux/fx2-include.asm
-Source: usbdux/usbduxfast_firmware.asm
-Source: usbdux/usbdux_firmware.asm
-Source: usbdux/usbduxsigma_firmware.asm
+Source: usbdux/
 
 Licence: GPLv2. See GPL-2 for details.
 
@@ -2704,10 +2695,7 @@ Licence: Redistributable. See LICENCE.ene_firmware for 
details.
 Driver: isci -- Intel C600 SAS controller driver
 
 File: isci/isci_firmware.bin
-Source: isci/create_fw.c
-Source: isci/create_fw.h
-Source: isci/probe_roms.h
-Source: isci/Makefile
+Source: isci/
 
 Licence: GPLv2. See GPL-2 for details.
 



signature.asc
Description: Digital signature


[PATCH linux-firmware 02/12] WHENCE: Correct filename of LICENCE.moxa

2016-09-17 Thread Ben Hutchings
Signed-off-by: Ben Hutchings 
---
 WHENCE | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/WHENCE b/WHENCE
index d7feede2b4da..5abdd8d3f49f 100644
--- a/WHENCE
+++ b/WHENCE
@@ -2889,7 +2889,7 @@ File: moxa/moxa-1131.fw
 File: moxa/moxa-1150.fw
 File: moxa/moxa-1151.fw
 
-License: Redistributable. See LICENSE.moxa for details
+License: Redistributable. See LICENCE.moxa for details
 
 --
 
@@ -2905,7 +2905,7 @@ File: moxa/moxa-1618.fw
 File: moxa/moxa-1653.fw
 File: moxa/moxa-1658.fw
 
-License: Redistributable. See LICENSE.moxa for details
+License: Redistributable. See LICENCE.moxa for details
 
 --
 



signature.asc
Description: Digital signature


[PATCH linux-firmware 02/12] WHENCE: Correct filename of LICENCE.moxa

2016-09-17 Thread Ben Hutchings
Signed-off-by: Ben Hutchings 
---
 WHENCE | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/WHENCE b/WHENCE
index d7feede2b4da..5abdd8d3f49f 100644
--- a/WHENCE
+++ b/WHENCE
@@ -2889,7 +2889,7 @@ File: moxa/moxa-1131.fw
 File: moxa/moxa-1150.fw
 File: moxa/moxa-1151.fw
 
-License: Redistributable. See LICENSE.moxa for details
+License: Redistributable. See LICENCE.moxa for details
 
 --
 
@@ -2905,7 +2905,7 @@ File: moxa/moxa-1618.fw
 File: moxa/moxa-1653.fw
 File: moxa/moxa-1658.fw
 
-License: Redistributable. See LICENSE.moxa for details
+License: Redistributable. See LICENCE.moxa for details
 
 --
 



signature.asc
Description: Digital signature


Re: [PATCH v2] sched/core: remove unnecessary initialization in sched_init()

2016-09-17 Thread Cheng Chao
Hi Peter,

  Would you please review this patch? thanks.

Cheng

on 09/14/2016 10:23 AM, Cheng Chao wrote:
> init_idle() is called immediately after current->sched_class
> = _sched_class, init_idle() sets current->sched_class
> = _sched_class.
> 
> Signed-off-by: Cheng Chao 
> Cc: sta...@vger.kernel.org
> ---
>  kernel/sched/core.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index a0086a5..ed4f4fe 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -7557,11 +7557,6 @@ void __init sched_init(void)
>   enter_lazy_tlb(_mm, current);
>  
>   /*
> -  * During early bootup we pretend to be a normal task:
> -  */
> - current->sched_class = _sched_class;
> -
> - /*
>* Make us the idle thread. Technically, schedule() should not be
>* called from this thread, however somewhere below it might be,
>* but because we are the idle thread, we just pick up running again
> 


Re: [PATCH v2] sched/core: remove unnecessary initialization in sched_init()

2016-09-17 Thread Cheng Chao
Hi Peter,

  Would you please review this patch? thanks.

Cheng

on 09/14/2016 10:23 AM, Cheng Chao wrote:
> init_idle() is called immediately after current->sched_class
> = _sched_class, init_idle() sets current->sched_class
> = _sched_class.
> 
> Signed-off-by: Cheng Chao 
> Cc: sta...@vger.kernel.org
> ---
>  kernel/sched/core.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index a0086a5..ed4f4fe 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -7557,11 +7557,6 @@ void __init sched_init(void)
>   enter_lazy_tlb(_mm, current);
>  
>   /*
> -  * During early bootup we pretend to be a normal task:
> -  */
> - current->sched_class = _sched_class;
> -
> - /*
>* Make us the idle thread. Technically, schedule() should not be
>* called from this thread, however somewhere below it might be,
>* but because we are the idle thread, we just pick up running again
> 


[PATCH linux-firmware 01/12] Add a metadata consistency check script

2016-09-17 Thread Ben Hutchings
The script compares the files listed in WHENCE (or otherwise expected)
and the files known to git, and reports all differences as errors.

Add a 'check' rule to the Makefile that runs this.

Signed-off-by: Ben Hutchings 
---
 Makefile|  3 +++
 check_whence.py | 56 
 2 files changed, 59 insertions(+)
 create mode 100755 check_whence.py

diff --git a/Makefile b/Makefile
index 1b1aa2836c97..d1163b871096 100644
--- a/Makefile
+++ b/Makefile
@@ -5,6 +5,9 @@ FIRMWAREDIR = /lib/firmware
 
 all:
 
+check:
+   ./check_whence.py
+
 install:
mkdir -p $(DESTDIR)$(FIRMWAREDIR)
cp -r * $(DESTDIR)$(FIRMWAREDIR)
diff --git a/check_whence.py b/check_whence.py
new file mode 100755
index ..f83fb197aa57
--- /dev/null
+++ b/check_whence.py
@@ -0,0 +1,56 @@
+#!/usr/bin/python
+
+import os, re, sys
+
+def list_whence():
+with open('WHENCE') as whence:
+for line in whence:
+match = re.match(r'(?:File|Link|Source):\s*(\S*)', line)
+if match:
+yield match.group(1)
+continue
+match = re.match(r'Licen[cs]e: (?:.*\bSee (.*) for 
details\.?|(\S*))\n',
+ line)
+if match:
+if match.group(1):
+for name in re.split(r', | and ', match.group(1)):
+yield name
+continue
+if match.group(2):
+# Just one word - may or may not be a filename
+if not re.search(r'unknown|distributable', match.group(2),
+ re.IGNORECASE):
+yield match.group(2)
+continue
+
+def list_git():
+with os.popen('git ls-files') as git_files:
+for line in git_files:
+yield line.rstrip('\n')
+
+def main():
+whence_list = list(list_whence())
+known_files = set(name for name in whence_list if not name.endswith('/')) 
| \
+  set(['check_whence.py', 'configure', 'Makefile',
+   'README', 'WHENCE'])
+known_prefixes = set(name for name in whence_list if name.endswith('/'))
+git_files = set(list_git())
+
+for name in sorted(list(known_files - git_files)):
+sys.stderr.write('E: %s listed in WHENCE does not exist\n' % name)
+
+for name in sorted(list(git_files - known_files)):
+# Ignore subdirectory changelogs and GPG detached signatures
+if (name.endswith('/ChangeLog') or
+(name.endswith('.asc') and name[:-4] in known_files)):
+continue
+
+# Ignore unknown files in known directories
+for prefix in known_prefixes:
+if name.startswith(prefix):
+break
+else:
+sys.stderr.write('E: %s not listed in WHENCE\n' % name)
+
+if __name__ == '__main__':
+main()



signature.asc
Description: Digital signature


[PATCH linux-firmware 01/12] Add a metadata consistency check script

2016-09-17 Thread Ben Hutchings
The script compares the files listed in WHENCE (or otherwise expected)
and the files known to git, and reports all differences as errors.

Add a 'check' rule to the Makefile that runs this.

Signed-off-by: Ben Hutchings 
---
 Makefile|  3 +++
 check_whence.py | 56 
 2 files changed, 59 insertions(+)
 create mode 100755 check_whence.py

diff --git a/Makefile b/Makefile
index 1b1aa2836c97..d1163b871096 100644
--- a/Makefile
+++ b/Makefile
@@ -5,6 +5,9 @@ FIRMWAREDIR = /lib/firmware
 
 all:
 
+check:
+   ./check_whence.py
+
 install:
mkdir -p $(DESTDIR)$(FIRMWAREDIR)
cp -r * $(DESTDIR)$(FIRMWAREDIR)
diff --git a/check_whence.py b/check_whence.py
new file mode 100755
index ..f83fb197aa57
--- /dev/null
+++ b/check_whence.py
@@ -0,0 +1,56 @@
+#!/usr/bin/python
+
+import os, re, sys
+
+def list_whence():
+with open('WHENCE') as whence:
+for line in whence:
+match = re.match(r'(?:File|Link|Source):\s*(\S*)', line)
+if match:
+yield match.group(1)
+continue
+match = re.match(r'Licen[cs]e: (?:.*\bSee (.*) for 
details\.?|(\S*))\n',
+ line)
+if match:
+if match.group(1):
+for name in re.split(r', | and ', match.group(1)):
+yield name
+continue
+if match.group(2):
+# Just one word - may or may not be a filename
+if not re.search(r'unknown|distributable', match.group(2),
+ re.IGNORECASE):
+yield match.group(2)
+continue
+
+def list_git():
+with os.popen('git ls-files') as git_files:
+for line in git_files:
+yield line.rstrip('\n')
+
+def main():
+whence_list = list(list_whence())
+known_files = set(name for name in whence_list if not name.endswith('/')) 
| \
+  set(['check_whence.py', 'configure', 'Makefile',
+   'README', 'WHENCE'])
+known_prefixes = set(name for name in whence_list if name.endswith('/'))
+git_files = set(list_git())
+
+for name in sorted(list(known_files - git_files)):
+sys.stderr.write('E: %s listed in WHENCE does not exist\n' % name)
+
+for name in sorted(list(git_files - known_files)):
+# Ignore subdirectory changelogs and GPG detached signatures
+if (name.endswith('/ChangeLog') or
+(name.endswith('.asc') and name[:-4] in known_files)):
+continue
+
+# Ignore unknown files in known directories
+for prefix in known_prefixes:
+if name.startswith(prefix):
+break
+else:
+sys.stderr.write('E: %s not listed in WHENCE\n' % name)
+
+if __name__ == '__main__':
+main()



signature.asc
Description: Digital signature


[PATCH linux-firmware 00/12] Fix metadata for linux-firmware

2016-09-17 Thread Ben Hutchings
This series adds a metadata consistency check script, fixes all the
errors it found, and adds a reference to it in README.

If I don't hear any objections, I'll apply these changes next week.

Ben.

Ben Hutchings (12):
  Add a metadata consistency check script
  WHENCE: Correct filename of LICENCE.moxa
  Add copy of GPL v2 and references to the GPL-2 and GPL-3 files
  WHENCE: Specify source directories for cis, isci, and usbdux firmware
  WHENCE: Remove references to source for emi62 firmware
  WHENCE: Remove references to two nvidia firmware files that were never
added
  Remove unused 'LICENCE.mwl8335'
  WHENCE: Adjust some licence file references to satisfy check_whence.py
  WHENCE: Fix metadata for snd-soc-skl firmware
  WHENCE: List new radeon CI and SI smc firmware
  WHENCE: Add reference to 'qca/NOTICE.txt'
  README: Say that files must be listed in WHENCE, and how to check it

 GPL-2   | 339 
 LICENCE.mwl8335 |  52 -
 Makefile|   3 +
 README  |   9 +-
 WHENCE  |  89 ---
 check_whence.py |  56 ++
 6 files changed, 453 insertions(+), 95 deletions(-)
 create mode 100644 GPL-2
 delete mode 100644 LICENCE.mwl8335
 create mode 100755 check_whence.py

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy
others.


signature.asc
Description: This is a digitally signed message part


[PATCH linux-firmware 00/12] Fix metadata for linux-firmware

2016-09-17 Thread Ben Hutchings
This series adds a metadata consistency check script, fixes all the
errors it found, and adds a reference to it in README.

If I don't hear any objections, I'll apply these changes next week.

Ben.

Ben Hutchings (12):
  Add a metadata consistency check script
  WHENCE: Correct filename of LICENCE.moxa
  Add copy of GPL v2 and references to the GPL-2 and GPL-3 files
  WHENCE: Specify source directories for cis, isci, and usbdux firmware
  WHENCE: Remove references to source for emi62 firmware
  WHENCE: Remove references to two nvidia firmware files that were never
added
  Remove unused 'LICENCE.mwl8335'
  WHENCE: Adjust some licence file references to satisfy check_whence.py
  WHENCE: Fix metadata for snd-soc-skl firmware
  WHENCE: List new radeon CI and SI smc firmware
  WHENCE: Add reference to 'qca/NOTICE.txt'
  README: Say that files must be listed in WHENCE, and how to check it

 GPL-2   | 339 
 LICENCE.mwl8335 |  52 -
 Makefile|   3 +
 README  |   9 +-
 WHENCE  |  89 ---
 check_whence.py |  56 ++
 6 files changed, 453 insertions(+), 95 deletions(-)
 create mode 100644 GPL-2
 delete mode 100644 LICENCE.mwl8335
 create mode 100755 check_whence.py

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
A fail-safe circuit will destroy
others.


signature.asc
Description: This is a digitally signed message part


Re: [PATCH -v3 00/10] THP swap: Delay splitting THP during swapping out

2016-09-17 Thread Huang, Ying
Minchan Kim  writes:

> On Tue, Sep 13, 2016 at 04:53:49PM +0800, Huang, Ying wrote:
>> Minchan Kim  writes:
>> > On Tue, Sep 13, 2016 at 02:40:00PM +0800, Huang, Ying wrote:
>> >> Minchan Kim  writes:
>> >> 
>> >> > Hi Huang,
>> >> >
>> >> > On Fri, Sep 09, 2016 at 01:35:12PM -0700, Huang, Ying wrote:
>> >> >
>> >> > < snip >
>> >> >
>> >> >> >> Recently, the performance of the storage devices improved so fast 
>> >> >> >> that
>> >> >> >> we cannot saturate the disk bandwidth when do page swap out even on 
>> >> >> >> a
>> >> >> >> high-end server machine.  Because the performance of the storage
>> >> >> >> device improved faster than that of CPU.  And it seems that the 
>> >> >> >> trend
>> >> >> >> will not change in the near future.  On the other hand, the THP
>> >> >> >> becomes more and more popular because of increased memory size.  So 
>> >> >> >> it
>> >> >> >> becomes necessary to optimize THP swap performance.
>> >> >> >> 
>> >> >> >> The advantages of the THP swap support include:
>> >> >> >> 
>> >> >> >> - Batch the swap operations for the THP to reduce lock
>> >> >> >>   acquiring/releasing, including allocating/freeing the swap space,
>> >> >> >>   adding/deleting to/from the swap cache, and writing/reading the 
>> >> >> >> swap
>> >> >> >>   space, etc.  This will help improve the performance of the THP 
>> >> >> >> swap.
>> >> >> >> 
>> >> >> >> - The THP swap space read/write will be 2M sequential IO.  It is
>> >> >> >>   particularly helpful for the swap read, which usually are 4k 
>> >> >> >> random
>> >> >> >>   IO.  This will improve the performance of the THP swap too.
>> >> >> >> 
>> >> >> >> - It will help the memory fragmentation, especially when the THP is
>> >> >> >>   heavily used by the applications.  The 2M continuous pages will be
>> >> >> >>   free up after THP swapping out.
>> >> >> >
>> >> >> > I just read patchset right now and still doubt why the all changes
>> >> >> > should be coupled with THP tightly. Many parts(e.g., you introduced
>> >> >> > or modifying existing functions for making them THP specific) could
>> >> >> > just take page_list and the number of pages then would handle them
>> >> >> > without THP awareness.
>> >> >> 
>> >> >> I am glad if my change could help normal pages swapping too.  And we 
>> >> >> can
>> >> >> change these functions to work for normal pages when necessary.
>> >> >
>> >> > Sure but it would be less painful that THP awareness swapout is
>> >> > based on multiple normal pages swapout. For exmaple, we don't
>> >> > touch delay THP split part(i.e., split a THP into 512 pages like
>> >> > as-is) and enhances swapout further like Tim's suggestion
>> >> > for mulitple normal pages swapout. With that, it might be enough
>> >> > for fast-storage without needing THP awareness.
>> >> >
>> >> > My *point* is let's approach step by step.
>> >> > First of all, go with batching normal pages swapout and if it's
>> >> > not enough, dive into further optimization like introducing
>> >> > THP-aware swapout.
>> >> >
>> >> > I believe it's natural development process to evolve things
>> >> > without over-engineering.
>> >> 
>> >> My target is not only the THP swap out acceleration, but also the full
>> >> THP swap out/in support without splitting THP.  This patchset is just
>> >> the first step of the full THP swap support.
>> >> 
>> >> >> > For example, if the nr_pages is larger than SWAPFILE_CLUSTER, we
>> >> >> > can try to allocate new cluster. With that, we could allocate new
>> >> >> > clusters to meet nr_pages requested or bail out if we fail to 
>> >> >> > allocate
>> >> >> > and fallback to 0-order page swapout. With that, swap layer could
>> >> >> > support multiple order-0 pages by batch.
>> >> >> >
>> >> >> > IMO, I really want to land Tim Chen's batching swapout work first.
>> >> >> > With Tim Chen's work, I expect we can make better refactoring
>> >> >> > for batching swap before adding more confuse to the swap layer.
>> >> >> > (I expect it would share several pieces of code for or would be base
>> >> >> > for batching allocation of swapcache, swapslot)
>> >> >> 
>> >> >> I don't think there is hard conflict between normal pages swapping
>> >> >> optimizing and THP swap optimizing.  Some code may be shared between
>> >> >> them.  That is good for both sides.
>> >> >> 
>> >> >> > After that, we could enhance swap for big contiguous batching
>> >> >> > like THP and finally we might make it be aware of THP specific to
>> >> >> > enhance further.
>> >> >> >
>> >> >> > A thing I remember you aruged: you want to swapin 512 pages
>> >> >> > all at once unconditionally. It's really worth to discuss if
>> >> >> > your design is going for the way.
>> >> >> > I doubt it's generally good idea. Because, currently, we try to
>> >> >> > swap in swapped out pages in THP page with conservative approach
>> >> >> > but your direction is going to opposite way.
>> >> >> >
>> >> >> > [mm, thp: 

Re: [PATCH -v3 00/10] THP swap: Delay splitting THP during swapping out

2016-09-17 Thread Huang, Ying
Minchan Kim  writes:

> On Tue, Sep 13, 2016 at 04:53:49PM +0800, Huang, Ying wrote:
>> Minchan Kim  writes:
>> > On Tue, Sep 13, 2016 at 02:40:00PM +0800, Huang, Ying wrote:
>> >> Minchan Kim  writes:
>> >> 
>> >> > Hi Huang,
>> >> >
>> >> > On Fri, Sep 09, 2016 at 01:35:12PM -0700, Huang, Ying wrote:
>> >> >
>> >> > < snip >
>> >> >
>> >> >> >> Recently, the performance of the storage devices improved so fast 
>> >> >> >> that
>> >> >> >> we cannot saturate the disk bandwidth when do page swap out even on 
>> >> >> >> a
>> >> >> >> high-end server machine.  Because the performance of the storage
>> >> >> >> device improved faster than that of CPU.  And it seems that the 
>> >> >> >> trend
>> >> >> >> will not change in the near future.  On the other hand, the THP
>> >> >> >> becomes more and more popular because of increased memory size.  So 
>> >> >> >> it
>> >> >> >> becomes necessary to optimize THP swap performance.
>> >> >> >> 
>> >> >> >> The advantages of the THP swap support include:
>> >> >> >> 
>> >> >> >> - Batch the swap operations for the THP to reduce lock
>> >> >> >>   acquiring/releasing, including allocating/freeing the swap space,
>> >> >> >>   adding/deleting to/from the swap cache, and writing/reading the 
>> >> >> >> swap
>> >> >> >>   space, etc.  This will help improve the performance of the THP 
>> >> >> >> swap.
>> >> >> >> 
>> >> >> >> - The THP swap space read/write will be 2M sequential IO.  It is
>> >> >> >>   particularly helpful for the swap read, which usually are 4k 
>> >> >> >> random
>> >> >> >>   IO.  This will improve the performance of the THP swap too.
>> >> >> >> 
>> >> >> >> - It will help the memory fragmentation, especially when the THP is
>> >> >> >>   heavily used by the applications.  The 2M continuous pages will be
>> >> >> >>   free up after THP swapping out.
>> >> >> >
>> >> >> > I just read patchset right now and still doubt why the all changes
>> >> >> > should be coupled with THP tightly. Many parts(e.g., you introduced
>> >> >> > or modifying existing functions for making them THP specific) could
>> >> >> > just take page_list and the number of pages then would handle them
>> >> >> > without THP awareness.
>> >> >> 
>> >> >> I am glad if my change could help normal pages swapping too.  And we 
>> >> >> can
>> >> >> change these functions to work for normal pages when necessary.
>> >> >
>> >> > Sure but it would be less painful that THP awareness swapout is
>> >> > based on multiple normal pages swapout. For exmaple, we don't
>> >> > touch delay THP split part(i.e., split a THP into 512 pages like
>> >> > as-is) and enhances swapout further like Tim's suggestion
>> >> > for mulitple normal pages swapout. With that, it might be enough
>> >> > for fast-storage without needing THP awareness.
>> >> >
>> >> > My *point* is let's approach step by step.
>> >> > First of all, go with batching normal pages swapout and if it's
>> >> > not enough, dive into further optimization like introducing
>> >> > THP-aware swapout.
>> >> >
>> >> > I believe it's natural development process to evolve things
>> >> > without over-engineering.
>> >> 
>> >> My target is not only the THP swap out acceleration, but also the full
>> >> THP swap out/in support without splitting THP.  This patchset is just
>> >> the first step of the full THP swap support.
>> >> 
>> >> >> > For example, if the nr_pages is larger than SWAPFILE_CLUSTER, we
>> >> >> > can try to allocate new cluster. With that, we could allocate new
>> >> >> > clusters to meet nr_pages requested or bail out if we fail to 
>> >> >> > allocate
>> >> >> > and fallback to 0-order page swapout. With that, swap layer could
>> >> >> > support multiple order-0 pages by batch.
>> >> >> >
>> >> >> > IMO, I really want to land Tim Chen's batching swapout work first.
>> >> >> > With Tim Chen's work, I expect we can make better refactoring
>> >> >> > for batching swap before adding more confuse to the swap layer.
>> >> >> > (I expect it would share several pieces of code for or would be base
>> >> >> > for batching allocation of swapcache, swapslot)
>> >> >> 
>> >> >> I don't think there is hard conflict between normal pages swapping
>> >> >> optimizing and THP swap optimizing.  Some code may be shared between
>> >> >> them.  That is good for both sides.
>> >> >> 
>> >> >> > After that, we could enhance swap for big contiguous batching
>> >> >> > like THP and finally we might make it be aware of THP specific to
>> >> >> > enhance further.
>> >> >> >
>> >> >> > A thing I remember you aruged: you want to swapin 512 pages
>> >> >> > all at once unconditionally. It's really worth to discuss if
>> >> >> > your design is going for the way.
>> >> >> > I doubt it's generally good idea. Because, currently, we try to
>> >> >> > swap in swapped out pages in THP page with conservative approach
>> >> >> > but your direction is going to opposite way.
>> >> >> >
>> >> >> > [mm, thp: convert from optimistic swapin collapsing to conservative]
>> >> 

Re: [PATCH 2/8] drm/rockchip: Get rid of some unnecessary code

2016-09-17 Thread Mark yao

On 2016年09月14日 20:54, Tomasz Figa wrote:

Current code implements prepare_fb and cleanup_fb callbacks only to
grab/release fb references, which is already done by atomic framework
when creating/destryoing plane state. Let's remove these
unused bits.

Signed-off-by: Tomasz Figa 
---
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 --
  1 file changed, 18 deletions(-)


Hi Tomasz

I think we can't get rid of the prepare_fb and cleanup_fb

see the reason:
commit 44d0237a26395ac94160cf23f32769013b365590
Author: Mark Yao 
Date:   Fri Apr 29 11:37:20 2016 +0800

drm/rockchip: vop: fix iommu crash with async atomic

After async atomic_commit callback, drm_atomic_clean_old_fb will
clean all old fb, but because async, the old fb may be also on
the vop hardware, dma will access the old fb buffer, clean old
fb will cause iommu page fault.

Reference the fb and unreference it when the fb actuall swap out
from vop hardware.



diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 7e811cf..68988c6 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -641,22 +641,6 @@ static void vop_plane_destroy(struct drm_plane *plane)
drm_plane_cleanup(plane);
  }
  
-static int vop_plane_prepare_fb(struct drm_plane *plane,

-   struct drm_plane_state *new_state)
-{
-   if (plane->state->fb)
-   drm_framebuffer_reference(plane->state->fb);
-
-   return 0;
-}
-
-static void vop_plane_cleanup_fb(struct drm_plane *plane,
-struct drm_plane_state *old_state)
-{
-   if (old_state->fb)
-   drm_framebuffer_unreference(old_state->fb);
-}
-
  static int vop_plane_atomic_check(struct drm_plane *plane,
   struct drm_plane_state *state)
  {
@@ -849,8 +833,6 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
  }
  
  static const struct drm_plane_helper_funcs plane_helper_funcs = {

-   .prepare_fb = vop_plane_prepare_fb,
-   .cleanup_fb = vop_plane_cleanup_fb,
.atomic_check = vop_plane_atomic_check,
.atomic_update = vop_plane_atomic_update,
.atomic_disable = vop_plane_atomic_disable,



--
Mark Yao




Re: [PATCH 2/8] drm/rockchip: Get rid of some unnecessary code

2016-09-17 Thread Mark yao

On 2016年09月14日 20:54, Tomasz Figa wrote:

Current code implements prepare_fb and cleanup_fb callbacks only to
grab/release fb references, which is already done by atomic framework
when creating/destryoing plane state. Let's remove these
unused bits.

Signed-off-by: Tomasz Figa 
---
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 18 --
  1 file changed, 18 deletions(-)


Hi Tomasz

I think we can't get rid of the prepare_fb and cleanup_fb

see the reason:
commit 44d0237a26395ac94160cf23f32769013b365590
Author: Mark Yao 
Date:   Fri Apr 29 11:37:20 2016 +0800

drm/rockchip: vop: fix iommu crash with async atomic

After async atomic_commit callback, drm_atomic_clean_old_fb will
clean all old fb, but because async, the old fb may be also on
the vop hardware, dma will access the old fb buffer, clean old
fb will cause iommu page fault.

Reference the fb and unreference it when the fb actuall swap out
from vop hardware.



diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 7e811cf..68988c6 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -641,22 +641,6 @@ static void vop_plane_destroy(struct drm_plane *plane)
drm_plane_cleanup(plane);
  }
  
-static int vop_plane_prepare_fb(struct drm_plane *plane,

-   struct drm_plane_state *new_state)
-{
-   if (plane->state->fb)
-   drm_framebuffer_reference(plane->state->fb);
-
-   return 0;
-}
-
-static void vop_plane_cleanup_fb(struct drm_plane *plane,
-struct drm_plane_state *old_state)
-{
-   if (old_state->fb)
-   drm_framebuffer_unreference(old_state->fb);
-}
-
  static int vop_plane_atomic_check(struct drm_plane *plane,
   struct drm_plane_state *state)
  {
@@ -849,8 +833,6 @@ static void vop_plane_atomic_update(struct drm_plane *plane,
  }
  
  static const struct drm_plane_helper_funcs plane_helper_funcs = {

-   .prepare_fb = vop_plane_prepare_fb,
-   .cleanup_fb = vop_plane_cleanup_fb,
.atomic_check = vop_plane_atomic_check,
.atomic_update = vop_plane_atomic_update,
.atomic_disable = vop_plane_atomic_disable,



--
Mark Yao




Re: [PATCH] clk: hisilicon: add CRG driver for Hi3798CV200 SoC

2016-09-17 Thread Jiancheng Xue
On 2016/9/15 5:01, Stephen Boyd wrote:
> On 09/12, Jiancheng Xue wrote:
>> Add CRG driver for Hi3798CV200 SoC. CRG(Clock and Reset
>> Generator) module generates clock and reset signals used
>> by other module blocks on SoC.
>>
>> Signed-off-by: Jiancheng Xue 
> 
> Overall looks fine. Just a few nitpicks.
> 
Hi Stephen,

Thanks for all your comments. I'll refine this patch
according to your suggestions and send a new version.

Best Regards,
Jiancheng

>> ---
>>  .../devicetree/bindings/clock/hi3519-crg.txt   |  46 
>>  .../devicetree/bindings/clock/hisi-crg.txt |  49 
> 
> I wonder if git format-patch -M would make it more apparent about
> what's changed across the file rename?
> 
>>  drivers/clk/hisilicon/Kconfig  |   8 +
>>  drivers/clk/hisilicon/Makefile |   1 +
>>  drivers/clk/hisilicon/crg-hi3798cv200.c| 304 
>> +
>>  drivers/clk/hisilicon/crg.h|  39 +++
>>  include/dt-bindings/clock/histb-clock.h|  64 +
>>  7 files changed, 465 insertions(+), 46 deletions(-)
>>  delete mode 100644 Documentation/devicetree/bindings/clock/hi3519-crg.txt
>>  create mode 100644 Documentation/devicetree/bindings/clock/hisi-crg.txt
>>  create mode 100644 drivers/clk/hisilicon/crg-hi3798cv200.c
>>  create mode 100644 drivers/clk/hisilicon/crg.h
>>  create mode 100644 include/dt-bindings/clock/histb-clock.h
>>
>> diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
>> index e169ec7..233d809 100644
>> --- a/drivers/clk/hisilicon/Makefile
>> +++ b/drivers/clk/hisilicon/Makefile
>> @@ -8,6 +8,7 @@ obj-$(CONFIG_ARCH_HI3xxx)+= clk-hi3620.o
>>  obj-$(CONFIG_ARCH_HIP04)+= clk-hip04.o
>>  obj-$(CONFIG_ARCH_HIX5HD2)  += clk-hix5hd2.o
>>  obj-$(CONFIG_COMMON_CLK_HI3519) += clk-hi3519.o
>> +obj-$(CONFIG_COMMON_CLK_HI3798CV200) += crg-hi3798cv200.o
> 
> Tab this out?
> 
>>  obj-$(CONFIG_COMMON_CLK_HI6220) += clk-hi6220.o
>>  obj-$(CONFIG_RESET_HISI)+= reset.o
>>  obj-$(CONFIG_STUB_CLK_HI6220)   += clk-hi6220-stub.o
>> diff --git a/drivers/clk/hisilicon/crg-hi3798cv200.c 
>> b/drivers/clk/hisilicon/crg-hi3798cv200.c
>> new file mode 100644
>> index 000..b763b99
>> --- /dev/null
>> +++ b/drivers/clk/hisilicon/crg-hi3798cv200.c
>> @@ -0,0 +1,304 @@
> [...]
>> +
>> +static struct hisi_crg_funcs hi3798cv200_crg_funcs = {
> 
> const?
> 
>> +.register_clks = hi3798cv200_clk_register,
>> +.unregister_clks = hi3798cv200_clk_unregister,
>> +};
>> +
>> +/* hi3798CV200 sysctrl CRG */
>> +
>> +#define HI3798CV200_SYSCTRL_NR_CLKS 16
>> +
>> +static const struct hisi_gate_clock hi3798cv200_sysctrl_gate_clks[] = {
>> +{ IR_CLK, "clk_ir", "100m",
>> +CLK_SET_RATE_PARENT, 0x48, 4, 0, },
>> +{ TIMER01_CLK, "clk_timer01", "24m",
>> +CLK_SET_RATE_PARENT, 0x48, 6, 0, },
>> +{ UART0_CLK, "clk_uart0", "75m",
>> +CLK_SET_RATE_PARENT, 0x48, 10, 0, },
>> +};
>> +
>> +static struct hisi_clock_data *hi3798cv200_sysctrl_clk_register(
>> +struct platform_device *pdev)
>> +{
>> +struct hisi_clock_data *clk_data;
>> +int ret;
>> +
>> +clk_data = hisi_clk_alloc(pdev, HI3798CV200_SYSCTRL_NR_CLKS);
>> +if (!clk_data)
>> +return ERR_PTR(-ENOMEM);
>> +
>> +ret = hisi_clk_register_gate(hi3798cv200_sysctrl_gate_clks,
>> +ARRAY_SIZE(hi3798cv200_sysctrl_gate_clks),
>> +clk_data);
>> +if (ret)
>> +return ERR_PTR(ret);
>> +
>> +ret = of_clk_add_provider(pdev->dev.of_node,
>> +of_clk_src_onecell_get, _data->clk_data);
>> +if (ret)
>> +goto unregister_gate;
>> +
>> +return clk_data;
>> +
>> +unregister_gate:
>> +hisi_clk_unregister_gate(hi3798cv200_sysctrl_gate_clks,
>> +ARRAY_SIZE(hi3798cv200_sysctrl_gate_clks),
>> +clk_data);
>> +return ERR_PTR(ret);
>> +}
>> +
>> +static void hi3798cv200_sysctrl_clk_unregister(struct platform_device *pdev)
>> +{
>> +struct hisi_crg_dev *crg = platform_get_drvdata(pdev);
>> +
>> +of_clk_del_provider(pdev->dev.of_node);
>> +
>> +hisi_clk_unregister_gate(hi3798cv200_sysctrl_gate_clks,
>> +ARRAY_SIZE(hi3798cv200_sysctrl_gate_clks),
>> +crg->clk_data);
>> +}
>> +
>> +static struct hisi_crg_funcs hi3798cv200_sysctrl_funcs = {
> 
> const?
> 
>> +.register_clks = hi3798cv200_sysctrl_clk_register,
>> +.unregister_clks = hi3798cv200_sysctrl_clk_unregister,
>> +};
>> +
>> +static const struct of_device_id hi3798cv200_crg_match_table[] = {
>> +{ .compatible = "hisilicon,hi3798cv200-crg",
>> +.data = _crg_funcs},
> 
> Nitpick: please add a space before }
> 
>> +{ .compatible = "hisilicon,hi3798cv200-sysctrl",
>> +.data = _sysctrl_funcs},
> 
> 

Re: [PATCH] clk: hisilicon: add CRG driver for Hi3798CV200 SoC

2016-09-17 Thread Jiancheng Xue
On 2016/9/15 5:01, Stephen Boyd wrote:
> On 09/12, Jiancheng Xue wrote:
>> Add CRG driver for Hi3798CV200 SoC. CRG(Clock and Reset
>> Generator) module generates clock and reset signals used
>> by other module blocks on SoC.
>>
>> Signed-off-by: Jiancheng Xue 
> 
> Overall looks fine. Just a few nitpicks.
> 
Hi Stephen,

Thanks for all your comments. I'll refine this patch
according to your suggestions and send a new version.

Best Regards,
Jiancheng

>> ---
>>  .../devicetree/bindings/clock/hi3519-crg.txt   |  46 
>>  .../devicetree/bindings/clock/hisi-crg.txt |  49 
> 
> I wonder if git format-patch -M would make it more apparent about
> what's changed across the file rename?
> 
>>  drivers/clk/hisilicon/Kconfig  |   8 +
>>  drivers/clk/hisilicon/Makefile |   1 +
>>  drivers/clk/hisilicon/crg-hi3798cv200.c| 304 
>> +
>>  drivers/clk/hisilicon/crg.h|  39 +++
>>  include/dt-bindings/clock/histb-clock.h|  64 +
>>  7 files changed, 465 insertions(+), 46 deletions(-)
>>  delete mode 100644 Documentation/devicetree/bindings/clock/hi3519-crg.txt
>>  create mode 100644 Documentation/devicetree/bindings/clock/hisi-crg.txt
>>  create mode 100644 drivers/clk/hisilicon/crg-hi3798cv200.c
>>  create mode 100644 drivers/clk/hisilicon/crg.h
>>  create mode 100644 include/dt-bindings/clock/histb-clock.h
>>
>> diff --git a/drivers/clk/hisilicon/Makefile b/drivers/clk/hisilicon/Makefile
>> index e169ec7..233d809 100644
>> --- a/drivers/clk/hisilicon/Makefile
>> +++ b/drivers/clk/hisilicon/Makefile
>> @@ -8,6 +8,7 @@ obj-$(CONFIG_ARCH_HI3xxx)+= clk-hi3620.o
>>  obj-$(CONFIG_ARCH_HIP04)+= clk-hip04.o
>>  obj-$(CONFIG_ARCH_HIX5HD2)  += clk-hix5hd2.o
>>  obj-$(CONFIG_COMMON_CLK_HI3519) += clk-hi3519.o
>> +obj-$(CONFIG_COMMON_CLK_HI3798CV200) += crg-hi3798cv200.o
> 
> Tab this out?
> 
>>  obj-$(CONFIG_COMMON_CLK_HI6220) += clk-hi6220.o
>>  obj-$(CONFIG_RESET_HISI)+= reset.o
>>  obj-$(CONFIG_STUB_CLK_HI6220)   += clk-hi6220-stub.o
>> diff --git a/drivers/clk/hisilicon/crg-hi3798cv200.c 
>> b/drivers/clk/hisilicon/crg-hi3798cv200.c
>> new file mode 100644
>> index 000..b763b99
>> --- /dev/null
>> +++ b/drivers/clk/hisilicon/crg-hi3798cv200.c
>> @@ -0,0 +1,304 @@
> [...]
>> +
>> +static struct hisi_crg_funcs hi3798cv200_crg_funcs = {
> 
> const?
> 
>> +.register_clks = hi3798cv200_clk_register,
>> +.unregister_clks = hi3798cv200_clk_unregister,
>> +};
>> +
>> +/* hi3798CV200 sysctrl CRG */
>> +
>> +#define HI3798CV200_SYSCTRL_NR_CLKS 16
>> +
>> +static const struct hisi_gate_clock hi3798cv200_sysctrl_gate_clks[] = {
>> +{ IR_CLK, "clk_ir", "100m",
>> +CLK_SET_RATE_PARENT, 0x48, 4, 0, },
>> +{ TIMER01_CLK, "clk_timer01", "24m",
>> +CLK_SET_RATE_PARENT, 0x48, 6, 0, },
>> +{ UART0_CLK, "clk_uart0", "75m",
>> +CLK_SET_RATE_PARENT, 0x48, 10, 0, },
>> +};
>> +
>> +static struct hisi_clock_data *hi3798cv200_sysctrl_clk_register(
>> +struct platform_device *pdev)
>> +{
>> +struct hisi_clock_data *clk_data;
>> +int ret;
>> +
>> +clk_data = hisi_clk_alloc(pdev, HI3798CV200_SYSCTRL_NR_CLKS);
>> +if (!clk_data)
>> +return ERR_PTR(-ENOMEM);
>> +
>> +ret = hisi_clk_register_gate(hi3798cv200_sysctrl_gate_clks,
>> +ARRAY_SIZE(hi3798cv200_sysctrl_gate_clks),
>> +clk_data);
>> +if (ret)
>> +return ERR_PTR(ret);
>> +
>> +ret = of_clk_add_provider(pdev->dev.of_node,
>> +of_clk_src_onecell_get, _data->clk_data);
>> +if (ret)
>> +goto unregister_gate;
>> +
>> +return clk_data;
>> +
>> +unregister_gate:
>> +hisi_clk_unregister_gate(hi3798cv200_sysctrl_gate_clks,
>> +ARRAY_SIZE(hi3798cv200_sysctrl_gate_clks),
>> +clk_data);
>> +return ERR_PTR(ret);
>> +}
>> +
>> +static void hi3798cv200_sysctrl_clk_unregister(struct platform_device *pdev)
>> +{
>> +struct hisi_crg_dev *crg = platform_get_drvdata(pdev);
>> +
>> +of_clk_del_provider(pdev->dev.of_node);
>> +
>> +hisi_clk_unregister_gate(hi3798cv200_sysctrl_gate_clks,
>> +ARRAY_SIZE(hi3798cv200_sysctrl_gate_clks),
>> +crg->clk_data);
>> +}
>> +
>> +static struct hisi_crg_funcs hi3798cv200_sysctrl_funcs = {
> 
> const?
> 
>> +.register_clks = hi3798cv200_sysctrl_clk_register,
>> +.unregister_clks = hi3798cv200_sysctrl_clk_unregister,
>> +};
>> +
>> +static const struct of_device_id hi3798cv200_crg_match_table[] = {
>> +{ .compatible = "hisilicon,hi3798cv200-crg",
>> +.data = _crg_funcs},
> 
> Nitpick: please add a space before }
> 
>> +{ .compatible = "hisilicon,hi3798cv200-sysctrl",
>> +.data = _sysctrl_funcs},
> 
> Nitpick: please add a space 

Re: Cannot load linux after recent efi-related changes

2016-09-17 Thread Mike Krinkin
On Sat, Sep 17, 2016 at 07:23:57PM +0300, Mike Krinkin wrote:
> Hello,
> 
> after commit 3dad6f7f6975 ("x86/efi: Defer efi_esrt_init until after
> memblock_x86_fill") kernel hits BUG_ON __efi_enter_virtual_mode because
> efi.systab is NULL. With older kernel versions i face the problem with
> efi_mem_reserve described in the commit.
> 
> AFAICS, get_systab_virt_addr called from efi_map_regions should set
> efi.systab, but i dumped memory desciptors in efi_map_regions and
> apparently none of them describes region that contains efi_phys.systab,
> so efi.systab remains unset.

I investigated it a bit further, and apparently problem occurs because
efi_esrt_init calls efi_mem_reserve with unaligned range boundaries, and
efi_memmap_insert doesn't handle unaligned ranges properly. The following
fix solves problem for me:

>From 23f7134a6dd3a3c47f875395933a68e1a83d0f0e Mon Sep 17 00:00:00 2001
From: Mike Krinkin 
Date: Sun, 18 Sep 2016 03:53:52 +0300
Subject: [PATCH] efi: force page alignment in efi_mem_insert

efi_mem_insert might be called with unaligned range boundaries,
for example, for me it happens because esrt size is not page
aligned, that, in turn, results in wrong memory map and triggers
BUG_ON in __efi_enter_virtual_mode.

Force page alignment on memory range boundaries in efi_mem_insert.

Signed-off-by: Mike Krinkin 
---
 drivers/firmware/efi/memmap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c
index cd96086..34322d1 100644
--- a/drivers/firmware/efi/memmap.c
+++ b/drivers/firmware/efi/memmap.c
@@ -221,8 +221,8 @@ void __init efi_memmap_insert(struct efi_memory_map 
*old_memmap, void *buf,
void *old, *new;
 
/* modifying range */
-   m_start = mem->range.start;
-   m_end = mem->range.end;
+   m_start = mem->range.start & ~(u64)EFI_PAGE_SIZE;
+   m_end = ALIGN(mem->range.end, EFI_PAGE_SIZE) - 1;
m_attr = mem->attribute;
 
for (old = old_memmap->map, new = buf;
-- 
2.7.4



Re: Cannot load linux after recent efi-related changes

2016-09-17 Thread Mike Krinkin
On Sat, Sep 17, 2016 at 07:23:57PM +0300, Mike Krinkin wrote:
> Hello,
> 
> after commit 3dad6f7f6975 ("x86/efi: Defer efi_esrt_init until after
> memblock_x86_fill") kernel hits BUG_ON __efi_enter_virtual_mode because
> efi.systab is NULL. With older kernel versions i face the problem with
> efi_mem_reserve described in the commit.
> 
> AFAICS, get_systab_virt_addr called from efi_map_regions should set
> efi.systab, but i dumped memory desciptors in efi_map_regions and
> apparently none of them describes region that contains efi_phys.systab,
> so efi.systab remains unset.

I investigated it a bit further, and apparently problem occurs because
efi_esrt_init calls efi_mem_reserve with unaligned range boundaries, and
efi_memmap_insert doesn't handle unaligned ranges properly. The following
fix solves problem for me:

>From 23f7134a6dd3a3c47f875395933a68e1a83d0f0e Mon Sep 17 00:00:00 2001
From: Mike Krinkin 
Date: Sun, 18 Sep 2016 03:53:52 +0300
Subject: [PATCH] efi: force page alignment in efi_mem_insert

efi_mem_insert might be called with unaligned range boundaries,
for example, for me it happens because esrt size is not page
aligned, that, in turn, results in wrong memory map and triggers
BUG_ON in __efi_enter_virtual_mode.

Force page alignment on memory range boundaries in efi_mem_insert.

Signed-off-by: Mike Krinkin 
---
 drivers/firmware/efi/memmap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/firmware/efi/memmap.c b/drivers/firmware/efi/memmap.c
index cd96086..34322d1 100644
--- a/drivers/firmware/efi/memmap.c
+++ b/drivers/firmware/efi/memmap.c
@@ -221,8 +221,8 @@ void __init efi_memmap_insert(struct efi_memory_map 
*old_memmap, void *buf,
void *old, *new;
 
/* modifying range */
-   m_start = mem->range.start;
-   m_end = mem->range.end;
+   m_start = mem->range.start & ~(u64)EFI_PAGE_SIZE;
+   m_end = ALIGN(mem->range.end, EFI_PAGE_SIZE) - 1;
m_attr = mem->attribute;
 
for (old = old_memmap->map, new = buf;
-- 
2.7.4



[PATCH] perf, tools: Handle events including .c and .o

2016-09-17 Thread Andi Kleen
From: Andi Kleen 

This is a generic bug fix, but it helps with Sukadev's JSON event tree
where such events can happen.

Any event inclduing a .c/.o/.bpf currently triggers BPF compilation or loading
and then an error.  This can happen for some Intel JSON events, which cannot
be used.

Fix the scanner to only match for .o or .c or .bpf at the end.
This will prevent loading multiple BPF scripts separated with comma,
but I assume this is acceptable.

Cc: wangn...@huawei.com
Cc: suka...@linux.vnet.ibm.com
Signed-off-by: Andi Kleen 
---
 tools/perf/util/parse-events.l | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
index 7a2519435da0..64ca26e4ed2d 100644
--- a/tools/perf/util/parse-events.l
+++ b/tools/perf/util/parse-events.l
@@ -162,8 +162,8 @@ modifier_bp [rwx]{1,3}
}
 
 {event_pmu}|
-{bpf_object}   |
-{bpf_source}   |
+({bpf_object}$)|
+({bpf_source}$)|
 {event}{
BEGIN(INITIAL);
REWIND(1);
-- 
2.5.5



[PATCH] perf, tools: Handle events including .c and .o

2016-09-17 Thread Andi Kleen
From: Andi Kleen 

This is a generic bug fix, but it helps with Sukadev's JSON event tree
where such events can happen.

Any event inclduing a .c/.o/.bpf currently triggers BPF compilation or loading
and then an error.  This can happen for some Intel JSON events, which cannot
be used.

Fix the scanner to only match for .o or .c or .bpf at the end.
This will prevent loading multiple BPF scripts separated with comma,
but I assume this is acceptable.

Cc: wangn...@huawei.com
Cc: suka...@linux.vnet.ibm.com
Signed-off-by: Andi Kleen 
---
 tools/perf/util/parse-events.l | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/parse-events.l b/tools/perf/util/parse-events.l
index 7a2519435da0..64ca26e4ed2d 100644
--- a/tools/perf/util/parse-events.l
+++ b/tools/perf/util/parse-events.l
@@ -162,8 +162,8 @@ modifier_bp [rwx]{1,3}
}
 
 {event_pmu}|
-{bpf_object}   |
-{bpf_source}   |
+({bpf_object}$)|
+({bpf_source}$)|
 {event}{
BEGIN(INITIAL);
REWIND(1);
-- 
2.5.5



Re: Crashing 'kzm' target in next-20160913 due to 'gpio: mxc: shift gpio_mxc_init() to subsys_initcall level'

2016-09-17 Thread Guenter Roeck

On 09/17/2016 05:08 PM, Shawn Guo wrote:

Hi Guenter,

On Thu, Sep 15, 2016 at 04:35:04PM +0300, Vladimir Zapolskiy wrote:

The proper fix in this particular case should be like this one:



Does Vladimir's patch below fix your problem?



Yes, it does. Feel free to add
Tested-by: Guenter Roeck 
to an official patch.

Guenter


Shawn


diff --git a/arch/arm/mach-imx/mach-kzm_arm11_01.c 
b/arch/arm/mach-imx/mach-kzm_arm11_01.c
index 31df4361996f..8288acfe7221 100644
--- a/arch/arm/mach-imx/mach-kzm_arm11_01.c
+++ b/arch/arm/mach-imx/mach-kzm_arm11_01.c
@@ -245,13 +245,17 @@ static void __init kzm_board_init(void)
mxc_iomux_setup_multiple_pins(kzm_pins,
  ARRAY_SIZE(kzm_pins), "kzm");
-   kzm_init_ext_uart();
-   kzm_init_smsc9118();
kzm_init_imx_uart();
pr_info("Clock input source is 26MHz\n");
 }
+static void __init kzm_late_init(void)
+{
+   kzm_init_ext_uart();
+   kzm_init_smsc9118();
+}
+
 /*
  * This structure defines static mappings for the kzm-arm11-01 board.
  */
@@ -291,5 +295,6 @@ MACHINE_START(KZM_ARM11_01, "Kyoto Microcomputer Co., Ltd. 
KZM-ARM11-01")
.init_irq = mx31_init_irq,
.init_time  = kzm_timer_init,
.init_machine = kzm_board_init,
+   .init_late  = kzm_late_init,
.restart= mxc_restart,
 MACHINE_END
--






Re: Crashing 'kzm' target in next-20160913 due to 'gpio: mxc: shift gpio_mxc_init() to subsys_initcall level'

2016-09-17 Thread Guenter Roeck

On 09/17/2016 05:08 PM, Shawn Guo wrote:

Hi Guenter,

On Thu, Sep 15, 2016 at 04:35:04PM +0300, Vladimir Zapolskiy wrote:

The proper fix in this particular case should be like this one:



Does Vladimir's patch below fix your problem?



Yes, it does. Feel free to add
Tested-by: Guenter Roeck 
to an official patch.

Guenter


Shawn


diff --git a/arch/arm/mach-imx/mach-kzm_arm11_01.c 
b/arch/arm/mach-imx/mach-kzm_arm11_01.c
index 31df4361996f..8288acfe7221 100644
--- a/arch/arm/mach-imx/mach-kzm_arm11_01.c
+++ b/arch/arm/mach-imx/mach-kzm_arm11_01.c
@@ -245,13 +245,17 @@ static void __init kzm_board_init(void)
mxc_iomux_setup_multiple_pins(kzm_pins,
  ARRAY_SIZE(kzm_pins), "kzm");
-   kzm_init_ext_uart();
-   kzm_init_smsc9118();
kzm_init_imx_uart();
pr_info("Clock input source is 26MHz\n");
 }
+static void __init kzm_late_init(void)
+{
+   kzm_init_ext_uart();
+   kzm_init_smsc9118();
+}
+
 /*
  * This structure defines static mappings for the kzm-arm11-01 board.
  */
@@ -291,5 +295,6 @@ MACHINE_START(KZM_ARM11_01, "Kyoto Microcomputer Co., Ltd. 
KZM-ARM11-01")
.init_irq = mx31_init_irq,
.init_time  = kzm_timer_init,
.init_machine = kzm_board_init,
+   .init_late  = kzm_late_init,
.restart= mxc_restart,
 MACHINE_END
--






Re: [PATCH v5 3/3] pci:aer: add support aer interrupt with none MSI/MSI-X/INTx mode

2016-09-17 Thread Shawn Guo
On Tue, Sep 13, 2016 at 12:40:59PM +0800, Po Liu wrote:
> On some platforms, root port doesn't support MSI/MSI-X/INTx in RC mode.
> When chip support the aer interrupt with none MSI/MSI-X/INTx mode,
> maybe there is interrupt line for aer pme etc. Search the interrupt
> number in the fdt file. Then fixup the dev->irq with it.
> 
> Signed-off-by: Po Liu 

Will the new kernel work with existing/old DTB?  I'm trying to
understand the dependency between driver and DTS changes.

Shawn

> ---
> changes for v5:
>   - Add clear 'aer' interrup-names description
> 
>  .../devicetree/bindings/pci/layerscape-pci.txt | 11 +---
>  drivers/pci/pcie/portdrv_core.c| 31 
> +++---
>  2 files changed, 35 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt 
> b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> index 41e9f55..101d0a7 100644
> --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> @@ -18,8 +18,10 @@ Required properties:
>  - reg: base addresses and lengths of the PCIe controller
>  - interrupts: A list of interrupt outputs of the controller. Must contain an
>entry for each entry in the interrupt-names property.
> -- interrupt-names: Must include the following entries:
> -  "intr": The interrupt that is asserted for controller interrupts
> +- interrupt-names: It may be include the following entries:
> +  "aer": The interrupt that is asserted for aer interrupt
> +  "pme": The interrupt that is asserted for pme interrupt
> +  ..
>  - fsl,pcie-scfg: Must include two entries.
>The first entry must be a link to the SCFG device node
>The second entry must be '0' or '1' based on physical PCIe controller 
> index.
> @@ -35,8 +37,9 @@ Example:
>   reg = <0x00 0x0340 0x0 0x0001   /* controller registers 
> */
>  0x40 0x 0x0 0x2000>; /* configuration space 
> */
>   reg-names = "regs", "config";
> - interrupts = ; /* controller 
> interrupt */
> - interrupt-names = "intr";
> + interrupts = , /* aer 
> interrupt */
> + ; /* pme interrupt */
> + interrupt-names = "aer", "pme";
>   fsl,pcie-scfg = < 0>;
>   #address-cells = <3>;
>   #size-cells = <2>;
> diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
> index e9270b4..7c4943d 100644
> --- a/drivers/pci/pcie/portdrv_core.c
> +++ b/drivers/pci/pcie/portdrv_core.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "../pci.h"
>  #include "portdrv.h"
> @@ -200,6 +201,28 @@ static int pcie_port_enable_msix(struct pci_dev *dev, 
> int *vectors, int mask)
>  static int init_service_irqs(struct pci_dev *dev, int *irqs, int mask)
>  {
>   int i, irq = -1;
> + int ret;
> + struct device_node *np = NULL;
> +
> + for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
> + irqs[i] = 0;
> +
> + if (dev->bus->dev.of_node)
> + np = dev->bus->dev.of_node;
> +
> + /* If root port doesn't support MSI/MSI-X/INTx in RC mode,
> +  * request irq for aer
> +  */
> + if (IS_ENABLED(CONFIG_OF_IRQ) && np &&
> + (mask & PCIE_PORT_SERVICE_PME)) {
> + ret = of_irq_get_byname(np, "aer");
> + if (ret > 0) {
> + irqs[PCIE_PORT_SERVICE_AER_SHIFT] = ret;
> + if (dev->irq)
> + irq = dev->irq;
> + goto no_msi;
> + }
> + }
>  
>   /*
>* If MSI cannot be used for PCIe PME or hotplug, we have to use
> @@ -225,11 +248,13 @@ static int init_service_irqs(struct pci_dev *dev, int 
> *irqs, int mask)
>   irq = dev->irq;
>  
>   no_msi:
> - for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
> - irqs[i] = irq;
> + for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++) {
> + if (!irqs[i])
> + irqs[i] = irq;
> + }
>   irqs[PCIE_PORT_SERVICE_VC_SHIFT] = -1;
>  
> - if (irq < 0)
> + if (irq < 0 && irqs[PCIE_PORT_SERVICE_AER_SHIFT] < 0)
>   return -ENODEV;
>   return 0;
>  }
> -- 
> 2.1.0.27.g96db324
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


Re: [PATCH v5 3/3] pci:aer: add support aer interrupt with none MSI/MSI-X/INTx mode

2016-09-17 Thread Shawn Guo
On Tue, Sep 13, 2016 at 12:40:59PM +0800, Po Liu wrote:
> On some platforms, root port doesn't support MSI/MSI-X/INTx in RC mode.
> When chip support the aer interrupt with none MSI/MSI-X/INTx mode,
> maybe there is interrupt line for aer pme etc. Search the interrupt
> number in the fdt file. Then fixup the dev->irq with it.
> 
> Signed-off-by: Po Liu 

Will the new kernel work with existing/old DTB?  I'm trying to
understand the dependency between driver and DTS changes.

Shawn

> ---
> changes for v5:
>   - Add clear 'aer' interrup-names description
> 
>  .../devicetree/bindings/pci/layerscape-pci.txt | 11 +---
>  drivers/pci/pcie/portdrv_core.c| 31 
> +++---
>  2 files changed, 35 insertions(+), 7 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/pci/layerscape-pci.txt 
> b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> index 41e9f55..101d0a7 100644
> --- a/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> +++ b/Documentation/devicetree/bindings/pci/layerscape-pci.txt
> @@ -18,8 +18,10 @@ Required properties:
>  - reg: base addresses and lengths of the PCIe controller
>  - interrupts: A list of interrupt outputs of the controller. Must contain an
>entry for each entry in the interrupt-names property.
> -- interrupt-names: Must include the following entries:
> -  "intr": The interrupt that is asserted for controller interrupts
> +- interrupt-names: It may be include the following entries:
> +  "aer": The interrupt that is asserted for aer interrupt
> +  "pme": The interrupt that is asserted for pme interrupt
> +  ..
>  - fsl,pcie-scfg: Must include two entries.
>The first entry must be a link to the SCFG device node
>The second entry must be '0' or '1' based on physical PCIe controller 
> index.
> @@ -35,8 +37,9 @@ Example:
>   reg = <0x00 0x0340 0x0 0x0001   /* controller registers 
> */
>  0x40 0x 0x0 0x2000>; /* configuration space 
> */
>   reg-names = "regs", "config";
> - interrupts = ; /* controller 
> interrupt */
> - interrupt-names = "intr";
> + interrupts = , /* aer 
> interrupt */
> + ; /* pme interrupt */
> + interrupt-names = "aer", "pme";
>   fsl,pcie-scfg = < 0>;
>   #address-cells = <3>;
>   #size-cells = <2>;
> diff --git a/drivers/pci/pcie/portdrv_core.c b/drivers/pci/pcie/portdrv_core.c
> index e9270b4..7c4943d 100644
> --- a/drivers/pci/pcie/portdrv_core.c
> +++ b/drivers/pci/pcie/portdrv_core.c
> @@ -16,6 +16,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "../pci.h"
>  #include "portdrv.h"
> @@ -200,6 +201,28 @@ static int pcie_port_enable_msix(struct pci_dev *dev, 
> int *vectors, int mask)
>  static int init_service_irqs(struct pci_dev *dev, int *irqs, int mask)
>  {
>   int i, irq = -1;
> + int ret;
> + struct device_node *np = NULL;
> +
> + for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
> + irqs[i] = 0;
> +
> + if (dev->bus->dev.of_node)
> + np = dev->bus->dev.of_node;
> +
> + /* If root port doesn't support MSI/MSI-X/INTx in RC mode,
> +  * request irq for aer
> +  */
> + if (IS_ENABLED(CONFIG_OF_IRQ) && np &&
> + (mask & PCIE_PORT_SERVICE_PME)) {
> + ret = of_irq_get_byname(np, "aer");
> + if (ret > 0) {
> + irqs[PCIE_PORT_SERVICE_AER_SHIFT] = ret;
> + if (dev->irq)
> + irq = dev->irq;
> + goto no_msi;
> + }
> + }
>  
>   /*
>* If MSI cannot be used for PCIe PME or hotplug, we have to use
> @@ -225,11 +248,13 @@ static int init_service_irqs(struct pci_dev *dev, int 
> *irqs, int mask)
>   irq = dev->irq;
>  
>   no_msi:
> - for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++)
> - irqs[i] = irq;
> + for (i = 0; i < PCIE_PORT_DEVICE_MAXSERVICES; i++) {
> + if (!irqs[i])
> + irqs[i] = irq;
> + }
>   irqs[PCIE_PORT_SERVICE_VC_SHIFT] = -1;
>  
> - if (irq < 0)
> + if (irq < 0 && irqs[PCIE_PORT_SERVICE_AER_SHIFT] < 0)
>   return -ENODEV;
>   return 0;
>  }
> -- 
> 2.1.0.27.g96db324
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


Re: [PATCH 1/1] ARM: imx5: Add clocks configuration

2016-09-17 Thread Shawn Guo
On Sun, Sep 18, 2016 at 08:21:59AM +0800, Shawn Guo wrote:
> On Thu, Sep 15, 2016 at 08:42:33PM +0300, Alexander Shiyan wrote:
> > >Четверг, 15 сентября 2016, 13:13 +03:00 от Fabien Lahoudere 
> > >:
> > >
> > >From: Kalle Kankare < kalle.kank...@vincit.fi >
> > >
> > >Add clocks configuration for CSI, FIRI and IEEE1588.
> > >
> > >Signed-off-by: Fabien Lahoudere < fabien.lahoud...@collabora.co.uk >
> > >---
> > > drivers/clk/imx/clk-imx51-imx53.c  | 20 
> > > include/dt-bindings/clock/imx5-clock.h | 15 ++-
> > > 2 files changed, 34 insertions(+), 1 deletion(-)
> > >
> > >diff --git a/drivers/clk/imx/clk-imx51-imx53.c 
> > >b/drivers/clk/imx/clk-imx51-imx53.c
> > >index 29d4c44..1e3c9ea 100644
> > >--- a/drivers/clk/imx/clk-imx51-imx53.c
> > >+++ b/drivers/clk/imx/clk-imx51-imx53.c
> > >@@ -126,6 +126,7 @@ static const char *spdif0_com_sel[] = { "spdif0_podf", 
> > >"ssi1_root_gate", };
> > > static const char *mx51_spdif1_com_sel[] = { "spdif1_podf", 
> > >"ssi2_root_gate", };
> > > static const char *step_sels[] = { "lp_apm", };
> > > static const char *cpu_podf_sels[] = { "pll1_sw", "step_sel" };
> > >+static const char *ieee1588_sels[] = { "pll3_sw", "pll4_sw", "dummy" /* 
> > >usbphy2_clk */, "dummy" /* fec_phy_clk */ };
> > > 
> > > static struct clk *clk[IMX5_CLK_END];
> > > static struct clk_onecell_data clk_data;
> > >@@ -543,6 +544,25 @@ static void __init mx53_clocks_init(struct 
> > >device_node *np)
> > ...
> > 
> > 2 Shawn Guo: Since the change affects only on i.MX53 architecture,
> > I would ask to change the subject to i.MX53 if it possible.
> 
> Yes.  Actually, since clock driver is not moved to drivers/clk, we

s/not/now

> shouldn't prefix it with "ARM: " any longer.

Shawn


arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3000' requires '-mfp32'

2016-09-17 Thread kbuild test robot
Hi Guenter,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   d4690f1e1cdabb4d61207b6787b1605a0dc0aeab
commit: 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e MIPS: VDSO: Fix build error 
with binutils 2.24 and earlier
date:   9 months ago
config: mips-decstation_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3000' requires '-mfp32'
/*


vim +1 arch/mips/vdso/gettimeofday.c

a7f4df4e Alex Smith 2015-10-21 @1  /*
a7f4df4e Alex Smith 2015-10-21  2   * Copyright (C) 2015 Imagination 
Technologies
a7f4df4e Alex Smith 2015-10-21  3   * Author: Alex Smith 
a7f4df4e Alex Smith 2015-10-21  4   *
a7f4df4e Alex Smith 2015-10-21  5   * This program is free software; you can 
redistribute it and/or modify it
a7f4df4e Alex Smith 2015-10-21  6   * under the terms of the GNU General Public 
License as published by the
a7f4df4e Alex Smith 2015-10-21  7   * Free Software Foundation;  either version 
2 of the  License, or (at your
a7f4df4e Alex Smith 2015-10-21  8   * option) any later version.
a7f4df4e Alex Smith 2015-10-21  9   */

:: The code at line 1 was first introduced by commit
:: a7f4df4e21dd8a8dab96e88acd2c9c5017b83fc6 MIPS: VDSO: Add implementations 
of gettimeofday() and clock_gettime()

:: TO: Alex Smith 
:: CC: Ralf Baechle 

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


.config.gz
Description: application/gzip


Re: [PATCH 1/1] ARM: imx5: Add clocks configuration

2016-09-17 Thread Shawn Guo
On Sun, Sep 18, 2016 at 08:21:59AM +0800, Shawn Guo wrote:
> On Thu, Sep 15, 2016 at 08:42:33PM +0300, Alexander Shiyan wrote:
> > >Четверг, 15 сентября 2016, 13:13 +03:00 от Fabien Lahoudere 
> > >:
> > >
> > >From: Kalle Kankare < kalle.kank...@vincit.fi >
> > >
> > >Add clocks configuration for CSI, FIRI and IEEE1588.
> > >
> > >Signed-off-by: Fabien Lahoudere < fabien.lahoud...@collabora.co.uk >
> > >---
> > > drivers/clk/imx/clk-imx51-imx53.c  | 20 
> > > include/dt-bindings/clock/imx5-clock.h | 15 ++-
> > > 2 files changed, 34 insertions(+), 1 deletion(-)
> > >
> > >diff --git a/drivers/clk/imx/clk-imx51-imx53.c 
> > >b/drivers/clk/imx/clk-imx51-imx53.c
> > >index 29d4c44..1e3c9ea 100644
> > >--- a/drivers/clk/imx/clk-imx51-imx53.c
> > >+++ b/drivers/clk/imx/clk-imx51-imx53.c
> > >@@ -126,6 +126,7 @@ static const char *spdif0_com_sel[] = { "spdif0_podf", 
> > >"ssi1_root_gate", };
> > > static const char *mx51_spdif1_com_sel[] = { "spdif1_podf", 
> > >"ssi2_root_gate", };
> > > static const char *step_sels[] = { "lp_apm", };
> > > static const char *cpu_podf_sels[] = { "pll1_sw", "step_sel" };
> > >+static const char *ieee1588_sels[] = { "pll3_sw", "pll4_sw", "dummy" /* 
> > >usbphy2_clk */, "dummy" /* fec_phy_clk */ };
> > > 
> > > static struct clk *clk[IMX5_CLK_END];
> > > static struct clk_onecell_data clk_data;
> > >@@ -543,6 +544,25 @@ static void __init mx53_clocks_init(struct 
> > >device_node *np)
> > ...
> > 
> > 2 Shawn Guo: Since the change affects only on i.MX53 architecture,
> > I would ask to change the subject to i.MX53 if it possible.
> 
> Yes.  Actually, since clock driver is not moved to drivers/clk, we

s/not/now

> shouldn't prefix it with "ARM: " any longer.

Shawn


arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3000' requires '-mfp32'

2016-09-17 Thread kbuild test robot
Hi Guenter,

First bad commit (maybe != root cause):

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   d4690f1e1cdabb4d61207b6787b1605a0dc0aeab
commit: 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e MIPS: VDSO: Fix build error 
with binutils 2.24 and earlier
date:   9 months ago
config: mips-decstation_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> arch/mips/vdso/gettimeofday.c:1:0: error: '-march=r3000' requires '-mfp32'
/*


vim +1 arch/mips/vdso/gettimeofday.c

a7f4df4e Alex Smith 2015-10-21 @1  /*
a7f4df4e Alex Smith 2015-10-21  2   * Copyright (C) 2015 Imagination 
Technologies
a7f4df4e Alex Smith 2015-10-21  3   * Author: Alex Smith 
a7f4df4e Alex Smith 2015-10-21  4   *
a7f4df4e Alex Smith 2015-10-21  5   * This program is free software; you can 
redistribute it and/or modify it
a7f4df4e Alex Smith 2015-10-21  6   * under the terms of the GNU General Public 
License as published by the
a7f4df4e Alex Smith 2015-10-21  7   * Free Software Foundation;  either version 
2 of the  License, or (at your
a7f4df4e Alex Smith 2015-10-21  8   * option) any later version.
a7f4df4e Alex Smith 2015-10-21  9   */

:: The code at line 1 was first introduced by commit
:: a7f4df4e21dd8a8dab96e88acd2c9c5017b83fc6 MIPS: VDSO: Add implementations 
of gettimeofday() and clock_gettime()

:: TO: Alex Smith 
:: CC: Ralf Baechle 

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


.config.gz
Description: application/gzip


Re: [PATCH 1/1] ARM: imx5: Add clocks configuration

2016-09-17 Thread Shawn Guo
On Thu, Sep 15, 2016 at 08:42:33PM +0300, Alexander Shiyan wrote:
> >Четверг, 15 сентября 2016, 13:13 +03:00 от Fabien Lahoudere 
> >:
> >
> >From: Kalle Kankare < kalle.kank...@vincit.fi >
> >
> >Add clocks configuration for CSI, FIRI and IEEE1588.
> >
> >Signed-off-by: Fabien Lahoudere < fabien.lahoud...@collabora.co.uk >
> >---
> > drivers/clk/imx/clk-imx51-imx53.c  | 20 
> > include/dt-bindings/clock/imx5-clock.h | 15 ++-
> > 2 files changed, 34 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/clk/imx/clk-imx51-imx53.c 
> >b/drivers/clk/imx/clk-imx51-imx53.c
> >index 29d4c44..1e3c9ea 100644
> >--- a/drivers/clk/imx/clk-imx51-imx53.c
> >+++ b/drivers/clk/imx/clk-imx51-imx53.c
> >@@ -126,6 +126,7 @@ static const char *spdif0_com_sel[] = { "spdif0_podf", 
> >"ssi1_root_gate", };
> > static const char *mx51_spdif1_com_sel[] = { "spdif1_podf", 
> >"ssi2_root_gate", };
> > static const char *step_sels[] = { "lp_apm", };
> > static const char *cpu_podf_sels[] = { "pll1_sw", "step_sel" };
> >+static const char *ieee1588_sels[] = { "pll3_sw", "pll4_sw", "dummy" /* 
> >usbphy2_clk */, "dummy" /* fec_phy_clk */ };
> > 
> > static struct clk *clk[IMX5_CLK_END];
> > static struct clk_onecell_data clk_data;
> >@@ -543,6 +544,25 @@ static void __init mx53_clocks_init(struct device_node 
> >*np)
> ...
> 
> 2 Shawn Guo: Since the change affects only on i.MX53 architecture,
> I would ask to change the subject to i.MX53 if it possible.

Yes.  Actually, since clock driver is not moved to drivers/clk, we
shouldn't prefix it with "ARM: " any longer.

Shawn


Re: [PATCH 1/1] ARM: imx5: Add clocks configuration

2016-09-17 Thread Shawn Guo
On Thu, Sep 15, 2016 at 08:42:33PM +0300, Alexander Shiyan wrote:
> >Четверг, 15 сентября 2016, 13:13 +03:00 от Fabien Lahoudere 
> >:
> >
> >From: Kalle Kankare < kalle.kank...@vincit.fi >
> >
> >Add clocks configuration for CSI, FIRI and IEEE1588.
> >
> >Signed-off-by: Fabien Lahoudere < fabien.lahoud...@collabora.co.uk >
> >---
> > drivers/clk/imx/clk-imx51-imx53.c  | 20 
> > include/dt-bindings/clock/imx5-clock.h | 15 ++-
> > 2 files changed, 34 insertions(+), 1 deletion(-)
> >
> >diff --git a/drivers/clk/imx/clk-imx51-imx53.c 
> >b/drivers/clk/imx/clk-imx51-imx53.c
> >index 29d4c44..1e3c9ea 100644
> >--- a/drivers/clk/imx/clk-imx51-imx53.c
> >+++ b/drivers/clk/imx/clk-imx51-imx53.c
> >@@ -126,6 +126,7 @@ static const char *spdif0_com_sel[] = { "spdif0_podf", 
> >"ssi1_root_gate", };
> > static const char *mx51_spdif1_com_sel[] = { "spdif1_podf", 
> >"ssi2_root_gate", };
> > static const char *step_sels[] = { "lp_apm", };
> > static const char *cpu_podf_sels[] = { "pll1_sw", "step_sel" };
> >+static const char *ieee1588_sels[] = { "pll3_sw", "pll4_sw", "dummy" /* 
> >usbphy2_clk */, "dummy" /* fec_phy_clk */ };
> > 
> > static struct clk *clk[IMX5_CLK_END];
> > static struct clk_onecell_data clk_data;
> >@@ -543,6 +544,25 @@ static void __init mx53_clocks_init(struct device_node 
> >*np)
> ...
> 
> 2 Shawn Guo: Since the change affects only on i.MX53 architecture,
> I would ask to change the subject to i.MX53 if it possible.

Yes.  Actually, since clock driver is not moved to drivers/clk, we
shouldn't prefix it with "ARM: " any longer.

Shawn


arch/mips/vdso/elf.S:1:0: error: '-march=r3000' requires '-mfp32'

2016-09-17 Thread kbuild test robot
Hi Alex,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   d4690f1e1cdabb4d61207b6787b1605a0dc0aeab
commit: ebb5e78cc63417a35254a791de66e1cc84f963cc MIPS: Initial implementation 
of a VDSO
date:   10 months ago
config: mips-decstation_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ebb5e78cc63417a35254a791de66e1cc84f963cc
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> arch/mips/vdso/elf.S:1:0: error: '-march=r3000' requires '-mfp32'
/*

--
>> arch/mips/vdso/sigreturn.S:1:0: error: '-march=r3000' requires '-mfp32'
/*


vim +1 arch/mips/vdso/elf.S

   > 1  /*
 2   * Copyright (C) 2015 Imagination Technologies
 3   * Author: Alex Smith 
 4   *

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


.config.gz
Description: application/gzip


arch/mips/vdso/elf.S:1:0: error: '-march=r3000' requires '-mfp32'

2016-09-17 Thread kbuild test robot
Hi Alex,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   d4690f1e1cdabb4d61207b6787b1605a0dc0aeab
commit: ebb5e78cc63417a35254a791de66e1cc84f963cc MIPS: Initial implementation 
of a VDSO
date:   10 months ago
config: mips-decstation_defconfig (attached as .config)
compiler: mipsel-linux-gnu-gcc (Debian 6.1.1-9) 6.1.1 20160705
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
git checkout ebb5e78cc63417a35254a791de66e1cc84f963cc
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> arch/mips/vdso/elf.S:1:0: error: '-march=r3000' requires '-mfp32'
/*

--
>> arch/mips/vdso/sigreturn.S:1:0: error: '-march=r3000' requires '-mfp32'
/*


vim +1 arch/mips/vdso/elf.S

   > 1  /*
 2   * Copyright (C) 2015 Imagination Technologies
 3   * Author: Alex Smith 
 4   *

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


.config.gz
Description: application/gzip


Re: Crashing 'kzm' target in next-20160913 due to 'gpio: mxc: shift gpio_mxc_init() to subsys_initcall level'

2016-09-17 Thread Shawn Guo
Hi Guenter,

On Thu, Sep 15, 2016 at 04:35:04PM +0300, Vladimir Zapolskiy wrote:
> The proper fix in this particular case should be like this one:
> 

Does Vladimir's patch below fix your problem?

Shawn

> diff --git a/arch/arm/mach-imx/mach-kzm_arm11_01.c 
> b/arch/arm/mach-imx/mach-kzm_arm11_01.c
> index 31df4361996f..8288acfe7221 100644
> --- a/arch/arm/mach-imx/mach-kzm_arm11_01.c
> +++ b/arch/arm/mach-imx/mach-kzm_arm11_01.c
> @@ -245,13 +245,17 @@ static void __init kzm_board_init(void)
>   mxc_iomux_setup_multiple_pins(kzm_pins,
> ARRAY_SIZE(kzm_pins), "kzm");
> - kzm_init_ext_uart();
> - kzm_init_smsc9118();
>   kzm_init_imx_uart();
>   pr_info("Clock input source is 26MHz\n");
>  }
> +static void __init kzm_late_init(void)
> +{
> + kzm_init_ext_uart();
> + kzm_init_smsc9118();
> +}
> +
>  /*
>   * This structure defines static mappings for the kzm-arm11-01 board.
>   */
> @@ -291,5 +295,6 @@ MACHINE_START(KZM_ARM11_01, "Kyoto Microcomputer Co., 
> Ltd. KZM-ARM11-01")
>   .init_irq = mx31_init_irq,
>   .init_time  = kzm_timer_init,
>   .init_machine = kzm_board_init,
> + .init_late  = kzm_late_init,
>   .restart= mxc_restart,
>  MACHINE_END
> --


Re: Crashing 'kzm' target in next-20160913 due to 'gpio: mxc: shift gpio_mxc_init() to subsys_initcall level'

2016-09-17 Thread Shawn Guo
Hi Guenter,

On Thu, Sep 15, 2016 at 04:35:04PM +0300, Vladimir Zapolskiy wrote:
> The proper fix in this particular case should be like this one:
> 

Does Vladimir's patch below fix your problem?

Shawn

> diff --git a/arch/arm/mach-imx/mach-kzm_arm11_01.c 
> b/arch/arm/mach-imx/mach-kzm_arm11_01.c
> index 31df4361996f..8288acfe7221 100644
> --- a/arch/arm/mach-imx/mach-kzm_arm11_01.c
> +++ b/arch/arm/mach-imx/mach-kzm_arm11_01.c
> @@ -245,13 +245,17 @@ static void __init kzm_board_init(void)
>   mxc_iomux_setup_multiple_pins(kzm_pins,
> ARRAY_SIZE(kzm_pins), "kzm");
> - kzm_init_ext_uart();
> - kzm_init_smsc9118();
>   kzm_init_imx_uart();
>   pr_info("Clock input source is 26MHz\n");
>  }
> +static void __init kzm_late_init(void)
> +{
> + kzm_init_ext_uart();
> + kzm_init_smsc9118();
> +}
> +
>  /*
>   * This structure defines static mappings for the kzm-arm11-01 board.
>   */
> @@ -291,5 +295,6 @@ MACHINE_START(KZM_ARM11_01, "Kyoto Microcomputer Co., 
> Ltd. KZM-ARM11-01")
>   .init_irq = mx31_init_irq,
>   .init_time  = kzm_timer_init,
>   .init_machine = kzm_board_init,
> + .init_late  = kzm_late_init,
>   .restart= mxc_restart,
>  MACHINE_END
> --


Re: [PATCH] sched: Fix SCHED_HRTICK bug leading to late preemption of tasks

2016-09-17 Thread Wanpeng Li
2016-09-17 9:28 GMT+08:00 Joonwoo Park :
> From: Srivatsa Vaddagiri 
>
> SCHED_HRTICK feature is useful to preempt SCHED_FAIR tasks on-the-dot
> (just when they would have exceeded their ideal_runtime). It makes use
> of a per-cpu hrtimer resource and hence alarming that hrtimer should
> be based on total SCHED_FAIR tasks a cpu has across its various cfs_rqs,
> rather than being based on number of tasks in a particular cfs_rq (as
> implemented currently). As a result, with current code, its possible for
> a running task (which is the sole task in its cfs_rq) to be preempted

not be preempted much, right?

> much after its ideal_runtime has elapsed, resulting in increased latency
> for tasks in other cfs_rq on same cpu.
>
> Fix this by alarming sched hrtimer based on total number of SCHED_FAIR
> tasks a CPU has across its various cfs_rqs.
>
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Srivatsa Vaddagiri 
> Signed-off-by: Joonwoo Park 
> ---
>
>  joonwoop: Do we also need to update or remove if-statement inside
>  hrtick_update()?
>  I guess not because hrtick_update() doesn't want to start hrtick when cfs_rq
>  has large number of nr_running where slice is longer than sched_latency.
>
>  kernel/sched/fair.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 4088eed..c55c566 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4458,7 +4458,7 @@ static void hrtick_start_fair(struct rq *rq, struct 
> task_struct *p)
>
> WARN_ON(task_rq(p) != rq);
>
> -   if (cfs_rq->nr_running > 1) {
> +   if (rq->cfs.h_nr_running > 1) {
> u64 slice = sched_slice(cfs_rq, se);
> u64 ran = se->sum_exec_runtime - se->prev_sum_exec_runtime;
> s64 delta = slice - ran;
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>


Re: [PATCH] sched: Fix SCHED_HRTICK bug leading to late preemption of tasks

2016-09-17 Thread Wanpeng Li
2016-09-17 9:28 GMT+08:00 Joonwoo Park :
> From: Srivatsa Vaddagiri 
>
> SCHED_HRTICK feature is useful to preempt SCHED_FAIR tasks on-the-dot
> (just when they would have exceeded their ideal_runtime). It makes use
> of a per-cpu hrtimer resource and hence alarming that hrtimer should
> be based on total SCHED_FAIR tasks a cpu has across its various cfs_rqs,
> rather than being based on number of tasks in a particular cfs_rq (as
> implemented currently). As a result, with current code, its possible for
> a running task (which is the sole task in its cfs_rq) to be preempted

not be preempted much, right?

> much after its ideal_runtime has elapsed, resulting in increased latency
> for tasks in other cfs_rq on same cpu.
>
> Fix this by alarming sched hrtimer based on total number of SCHED_FAIR
> tasks a CPU has across its various cfs_rqs.
>
> Cc: Ingo Molnar 
> Cc: Peter Zijlstra 
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Srivatsa Vaddagiri 
> Signed-off-by: Joonwoo Park 
> ---
>
>  joonwoop: Do we also need to update or remove if-statement inside
>  hrtick_update()?
>  I guess not because hrtick_update() doesn't want to start hrtick when cfs_rq
>  has large number of nr_running where slice is longer than sched_latency.
>
>  kernel/sched/fair.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 4088eed..c55c566 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -4458,7 +4458,7 @@ static void hrtick_start_fair(struct rq *rq, struct 
> task_struct *p)
>
> WARN_ON(task_rq(p) != rq);
>
> -   if (cfs_rq->nr_running > 1) {
> +   if (rq->cfs.h_nr_running > 1) {
> u64 slice = sched_slice(cfs_rq, se);
> u64 ran = se->sum_exec_runtime - se->prev_sum_exec_runtime;
> s64 delta = slice - ran;
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>


[PATCH net-next 00/11] rxrpc: Tracepoint addition and improvement

2016-09-17 Thread David Howells

Here is a set of patches that add some more tracepoints and improve a couple
of existing ones.  New additions include:

 (1) Connection refcount tracking.

 (2) Client connection state machine tracking.

 (3) Tx and Rx packet lifecycle.

 (4) ACK reception and transmission.

 (5) recvmsg processing.

Updates include:

 (1) Print the symbolic packet name in the Rx packet tracepoint.

 (2) Additional call refcount trace events.

 (3) Improvements to sk_buff tracking with AF_RXRPC.

In addition:

 (1) Config option to inject packet loss during both transmission and
 reception.

 (2) Removal of some printks.

This series needs to be applied on top of the previously posted fixes.

The patches can be found here also:


http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-rewrite

Tagged thusly:

git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
rxrpc-rewrite-20160917-2

David
---
David Howells (11):
  rxrpc: Print the packet type name in the Rx packet trace
  rxrpc: Add some additional call tracing
  rxrpc: Add connection tracepoint and client conn state tracepoint
  rxrpc: Add a tracepoint to follow the life of a packet in the Tx buffer
  rxrpc: Add a tracepoint to log received ACK packets
  rxrpc: Add a tracepoint to log ACK transmission
  rxrpc: Add a tracepoint to follow packets in the Rx buffer
  rxrpc: Add a tracepoint to follow what recvmsg does
  rxrpc: Remove printks from rxrpc_recvmsg_data() to fix uninit var
  rxrpc: Improve skb tracing
  rxrpc: Add config to inject packet loss


 include/trace/events/rxrpc.h |  226 --
 net/rxrpc/Kconfig|7 +
 net/rxrpc/af_rxrpc.c |5 +
 net/rxrpc/ar-internal.h  |  159 +++---
 net/rxrpc/call_accept.c  |7 +
 net/rxrpc/call_event.c   |8 +
 net/rxrpc/call_object.c  |   31 --
 net/rxrpc/conn_client.c  |   82 +++
 net/rxrpc/conn_event.c   |   11 +-
 net/rxrpc/conn_object.c  |   72 +
 net/rxrpc/conn_service.c |4 +
 net/rxrpc/input.c|   31 --
 net/rxrpc/local_event.c  |4 -
 net/rxrpc/misc.c |   81 +++
 net/rxrpc/output.c   |   20 +++-
 net/rxrpc/peer_event.c   |   10 +-
 net/rxrpc/recvmsg.c  |   60 ---
 net/rxrpc/sendmsg.c  |   19 ++--
 net/rxrpc/skbuff.c   |   53 +++---
 19 files changed, 740 insertions(+), 150 deletions(-)



[PATCH net-next 01/11] rxrpc: Print the packet type name in the Rx packet trace

2016-09-17 Thread David Howells
Print a symbolic packet type name for each valid received packet in the
trace output, not just a number.

Signed-off-by: David Howells 
---

 include/trace/events/rxrpc.h |5 +++--
 net/rxrpc/ar-internal.h  |6 +++---
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/include/trace/events/rxrpc.h b/include/trace/events/rxrpc.h
index ea3b10ed91a8..0a30c673509c 100644
--- a/include/trace/events/rxrpc.h
+++ b/include/trace/events/rxrpc.h
@@ -93,11 +93,12 @@ TRACE_EVENT(rxrpc_rx_packet,
memcpy(&__entry->hdr, >hdr, sizeof(__entry->hdr));
   ),
 
-   TP_printk("%08x:%08x:%08x:%04x %08x %08x %02x %02x",
+   TP_printk("%08x:%08x:%08x:%04x %08x %08x %02x %02x %s",
  __entry->hdr.epoch, __entry->hdr.cid,
  __entry->hdr.callNumber, __entry->hdr.serviceId,
  __entry->hdr.serial, __entry->hdr.seq,
- __entry->hdr.type, __entry->hdr.flags)
+ __entry->hdr.type, __entry->hdr.flags,
+ __entry->hdr.type <= 15 ? rxrpc_pkts[__entry->hdr.type] : 
"?UNK")
);
 
 TRACE_EVENT(rxrpc_rx_done,
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index e78c40b37db5..0f6fafa2c271 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -551,6 +551,9 @@ enum rxrpc_call_trace {
 
 extern const char rxrpc_call_traces[rxrpc_call__nr_trace][4];
 
+extern const char *const rxrpc_pkts[];
+extern const char *rxrpc_acks(u8 reason);
+
 #include 
 
 /*
@@ -851,11 +854,8 @@ extern unsigned int rxrpc_rx_mtu;
 extern unsigned int rxrpc_rx_jumbo_max;
 extern unsigned int rxrpc_resend_timeout;
 
-extern const char *const rxrpc_pkts[];
 extern const s8 rxrpc_ack_priority[];
 
-extern const char *rxrpc_acks(u8 reason);
-
 /*
  * output.c
  */



[PATCH net-next 00/11] rxrpc: Tracepoint addition and improvement

2016-09-17 Thread David Howells

Here is a set of patches that add some more tracepoints and improve a couple
of existing ones.  New additions include:

 (1) Connection refcount tracking.

 (2) Client connection state machine tracking.

 (3) Tx and Rx packet lifecycle.

 (4) ACK reception and transmission.

 (5) recvmsg processing.

Updates include:

 (1) Print the symbolic packet name in the Rx packet tracepoint.

 (2) Additional call refcount trace events.

 (3) Improvements to sk_buff tracking with AF_RXRPC.

In addition:

 (1) Config option to inject packet loss during both transmission and
 reception.

 (2) Removal of some printks.

This series needs to be applied on top of the previously posted fixes.

The patches can be found here also:


http://git.kernel.org/cgit/linux/kernel/git/dhowells/linux-fs.git/log/?h=rxrpc-rewrite

Tagged thusly:

git://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git
rxrpc-rewrite-20160917-2

David
---
David Howells (11):
  rxrpc: Print the packet type name in the Rx packet trace
  rxrpc: Add some additional call tracing
  rxrpc: Add connection tracepoint and client conn state tracepoint
  rxrpc: Add a tracepoint to follow the life of a packet in the Tx buffer
  rxrpc: Add a tracepoint to log received ACK packets
  rxrpc: Add a tracepoint to log ACK transmission
  rxrpc: Add a tracepoint to follow packets in the Rx buffer
  rxrpc: Add a tracepoint to follow what recvmsg does
  rxrpc: Remove printks from rxrpc_recvmsg_data() to fix uninit var
  rxrpc: Improve skb tracing
  rxrpc: Add config to inject packet loss


 include/trace/events/rxrpc.h |  226 --
 net/rxrpc/Kconfig|7 +
 net/rxrpc/af_rxrpc.c |5 +
 net/rxrpc/ar-internal.h  |  159 +++---
 net/rxrpc/call_accept.c  |7 +
 net/rxrpc/call_event.c   |8 +
 net/rxrpc/call_object.c  |   31 --
 net/rxrpc/conn_client.c  |   82 +++
 net/rxrpc/conn_event.c   |   11 +-
 net/rxrpc/conn_object.c  |   72 +
 net/rxrpc/conn_service.c |4 +
 net/rxrpc/input.c|   31 --
 net/rxrpc/local_event.c  |4 -
 net/rxrpc/misc.c |   81 +++
 net/rxrpc/output.c   |   20 +++-
 net/rxrpc/peer_event.c   |   10 +-
 net/rxrpc/recvmsg.c  |   60 ---
 net/rxrpc/sendmsg.c  |   19 ++--
 net/rxrpc/skbuff.c   |   53 +++---
 19 files changed, 740 insertions(+), 150 deletions(-)



[PATCH net-next 01/11] rxrpc: Print the packet type name in the Rx packet trace

2016-09-17 Thread David Howells
Print a symbolic packet type name for each valid received packet in the
trace output, not just a number.

Signed-off-by: David Howells 
---

 include/trace/events/rxrpc.h |5 +++--
 net/rxrpc/ar-internal.h  |6 +++---
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/include/trace/events/rxrpc.h b/include/trace/events/rxrpc.h
index ea3b10ed91a8..0a30c673509c 100644
--- a/include/trace/events/rxrpc.h
+++ b/include/trace/events/rxrpc.h
@@ -93,11 +93,12 @@ TRACE_EVENT(rxrpc_rx_packet,
memcpy(&__entry->hdr, >hdr, sizeof(__entry->hdr));
   ),
 
-   TP_printk("%08x:%08x:%08x:%04x %08x %08x %02x %02x",
+   TP_printk("%08x:%08x:%08x:%04x %08x %08x %02x %02x %s",
  __entry->hdr.epoch, __entry->hdr.cid,
  __entry->hdr.callNumber, __entry->hdr.serviceId,
  __entry->hdr.serial, __entry->hdr.seq,
- __entry->hdr.type, __entry->hdr.flags)
+ __entry->hdr.type, __entry->hdr.flags,
+ __entry->hdr.type <= 15 ? rxrpc_pkts[__entry->hdr.type] : 
"?UNK")
);
 
 TRACE_EVENT(rxrpc_rx_done,
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index e78c40b37db5..0f6fafa2c271 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -551,6 +551,9 @@ enum rxrpc_call_trace {
 
 extern const char rxrpc_call_traces[rxrpc_call__nr_trace][4];
 
+extern const char *const rxrpc_pkts[];
+extern const char *rxrpc_acks(u8 reason);
+
 #include 
 
 /*
@@ -851,11 +854,8 @@ extern unsigned int rxrpc_rx_mtu;
 extern unsigned int rxrpc_rx_jumbo_max;
 extern unsigned int rxrpc_resend_timeout;
 
-extern const char *const rxrpc_pkts[];
 extern const s8 rxrpc_ack_priority[];
 
-extern const char *rxrpc_acks(u8 reason);
-
 /*
  * output.c
  */



[PATCH net-next 04/11] rxrpc: Add a tracepoint to follow the life of a packet in the Tx buffer

2016-09-17 Thread David Howells
Add a tracepoint to follow the insertion of a packet into the transmit
buffer, its transmission and its rotation out of the buffer.

Signed-off-by: David Howells 
---

 include/trace/events/rxrpc.h |   26 ++
 net/rxrpc/ar-internal.h  |   12 
 net/rxrpc/input.c|2 ++
 net/rxrpc/misc.c |9 +
 net/rxrpc/sendmsg.c  |9 -
 5 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/include/trace/events/rxrpc.h b/include/trace/events/rxrpc.h
index c0c496c83f31..ffc74b3e5b76 100644
--- a/include/trace/events/rxrpc.h
+++ b/include/trace/events/rxrpc.h
@@ -208,6 +208,32 @@ TRACE_EVENT(rxrpc_abort,
  __entry->abort_code, __entry->error, __entry->why)
);
 
+TRACE_EVENT(rxrpc_transmit,
+   TP_PROTO(struct rxrpc_call *call, enum rxrpc_transmit_trace why),
+
+   TP_ARGS(call, why),
+
+   TP_STRUCT__entry(
+   __field(struct rxrpc_call *,call)
+   __field(enum rxrpc_transmit_trace,  why )
+   __field(rxrpc_seq_t,tx_hard_ack )
+   __field(rxrpc_seq_t,tx_top  )
+),
+
+   TP_fast_assign(
+   __entry->call = call;
+   __entry->why = why;
+   __entry->tx_hard_ack = call->tx_hard_ack;
+   __entry->tx_top = call->tx_top;
+  ),
+
+   TP_printk("c=%p %s f=%08x n=%u",
+ __entry->call,
+ rxrpc_transmit_traces[__entry->why],
+ __entry->tx_hard_ack + 1,
+ __entry->tx_top - __entry->tx_hard_ack)
+   );
+
 #endif /* _TRACE_RXRPC_H */
 
 /* This part must be outside protection */
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index 6ca40eea3022..afa5dcc05fe0 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -593,6 +593,18 @@ enum rxrpc_call_trace {
 
 extern const char rxrpc_call_traces[rxrpc_call__nr_trace][4];
 
+enum rxrpc_transmit_trace {
+   rxrpc_transmit_wait,
+   rxrpc_transmit_queue,
+   rxrpc_transmit_queue_reqack,
+   rxrpc_transmit_queue_last,
+   rxrpc_transmit_rotate,
+   rxrpc_transmit_end,
+   rxrpc_transmit__nr_trace
+};
+
+extern const char rxrpc_transmit_traces[rxrpc_transmit__nr_trace][4];
+
 extern const char *const rxrpc_pkts[];
 extern const char *rxrpc_acks(u8 reason);
 
diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c
index c1f83d22f9b7..c7eb5104e91a 100644
--- a/net/rxrpc/input.c
+++ b/net/rxrpc/input.c
@@ -59,6 +59,7 @@ static void rxrpc_rotate_tx_window(struct rxrpc_call *call, 
rxrpc_seq_t to)
 
spin_unlock(>lock);
 
+   trace_rxrpc_transmit(call, rxrpc_transmit_rotate);
wake_up(>waitq);
 
while (list) {
@@ -107,6 +108,7 @@ static bool rxrpc_end_tx_phase(struct rxrpc_call *call, 
const char *abort_why)
}
 
write_unlock(>state_lock);
+   trace_rxrpc_transmit(call, rxrpc_transmit_end);
_leave(" = ok");
return true;
 }
diff --git a/net/rxrpc/misc.c b/net/rxrpc/misc.c
index 598064d3bdd2..dca89995f03e 100644
--- a/net/rxrpc/misc.c
+++ b/net/rxrpc/misc.c
@@ -132,3 +132,12 @@ const char rxrpc_client_traces[rxrpc_client__nr_trace][7] 
= {
[rxrpc_client_to_waiting]   = "->Wait",
[rxrpc_client_uncount]  = "Uncoun",
 };
+
+const char rxrpc_transmit_traces[rxrpc_transmit__nr_trace][4] = {
+   [rxrpc_transmit_wait]   = "WAI",
+   [rxrpc_transmit_queue]  = "QUE",
+   [rxrpc_transmit_queue_reqack]   = "QRA",
+   [rxrpc_transmit_queue_last] = "QLS",
+   [rxrpc_transmit_rotate] = "ROT",
+   [rxrpc_transmit_end]= "END",
+};
diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
index 8bfddf4e338c..28d8f73cf11d 100644
--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -56,6 +56,7 @@ static int rxrpc_wait_for_tx_window(struct rxrpc_sock *rx,
break;
}
 
+   trace_rxrpc_transmit(call, rxrpc_transmit_wait);
release_sock(>sk);
*timeo = schedule_timeout(*timeo);
lock_sock(>sk);
@@ -104,8 +105,14 @@ static void rxrpc_queue_packet(struct rxrpc_call *call, 
struct sk_buff *skb,
smp_wmb();
call->rxtx_buffer[ix] = skb;
call->tx_top = seq;
-   if (last)
+   if (last) {
set_bit(RXRPC_CALL_TX_LAST, >flags);
+   trace_rxrpc_transmit(call, rxrpc_transmit_queue_last);
+   } else if (sp->hdr.flags & RXRPC_REQUEST_ACK) {
+   trace_rxrpc_transmit(call, rxrpc_transmit_queue_reqack);
+   } else {
+   trace_rxrpc_transmit(call, rxrpc_transmit_queue);
+   }
 
if (last || call->state == 

[PATCH net-next 04/11] rxrpc: Add a tracepoint to follow the life of a packet in the Tx buffer

2016-09-17 Thread David Howells
Add a tracepoint to follow the insertion of a packet into the transmit
buffer, its transmission and its rotation out of the buffer.

Signed-off-by: David Howells 
---

 include/trace/events/rxrpc.h |   26 ++
 net/rxrpc/ar-internal.h  |   12 
 net/rxrpc/input.c|2 ++
 net/rxrpc/misc.c |9 +
 net/rxrpc/sendmsg.c  |9 -
 5 files changed, 57 insertions(+), 1 deletion(-)

diff --git a/include/trace/events/rxrpc.h b/include/trace/events/rxrpc.h
index c0c496c83f31..ffc74b3e5b76 100644
--- a/include/trace/events/rxrpc.h
+++ b/include/trace/events/rxrpc.h
@@ -208,6 +208,32 @@ TRACE_EVENT(rxrpc_abort,
  __entry->abort_code, __entry->error, __entry->why)
);
 
+TRACE_EVENT(rxrpc_transmit,
+   TP_PROTO(struct rxrpc_call *call, enum rxrpc_transmit_trace why),
+
+   TP_ARGS(call, why),
+
+   TP_STRUCT__entry(
+   __field(struct rxrpc_call *,call)
+   __field(enum rxrpc_transmit_trace,  why )
+   __field(rxrpc_seq_t,tx_hard_ack )
+   __field(rxrpc_seq_t,tx_top  )
+),
+
+   TP_fast_assign(
+   __entry->call = call;
+   __entry->why = why;
+   __entry->tx_hard_ack = call->tx_hard_ack;
+   __entry->tx_top = call->tx_top;
+  ),
+
+   TP_printk("c=%p %s f=%08x n=%u",
+ __entry->call,
+ rxrpc_transmit_traces[__entry->why],
+ __entry->tx_hard_ack + 1,
+ __entry->tx_top - __entry->tx_hard_ack)
+   );
+
 #endif /* _TRACE_RXRPC_H */
 
 /* This part must be outside protection */
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index 6ca40eea3022..afa5dcc05fe0 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -593,6 +593,18 @@ enum rxrpc_call_trace {
 
 extern const char rxrpc_call_traces[rxrpc_call__nr_trace][4];
 
+enum rxrpc_transmit_trace {
+   rxrpc_transmit_wait,
+   rxrpc_transmit_queue,
+   rxrpc_transmit_queue_reqack,
+   rxrpc_transmit_queue_last,
+   rxrpc_transmit_rotate,
+   rxrpc_transmit_end,
+   rxrpc_transmit__nr_trace
+};
+
+extern const char rxrpc_transmit_traces[rxrpc_transmit__nr_trace][4];
+
 extern const char *const rxrpc_pkts[];
 extern const char *rxrpc_acks(u8 reason);
 
diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c
index c1f83d22f9b7..c7eb5104e91a 100644
--- a/net/rxrpc/input.c
+++ b/net/rxrpc/input.c
@@ -59,6 +59,7 @@ static void rxrpc_rotate_tx_window(struct rxrpc_call *call, 
rxrpc_seq_t to)
 
spin_unlock(>lock);
 
+   trace_rxrpc_transmit(call, rxrpc_transmit_rotate);
wake_up(>waitq);
 
while (list) {
@@ -107,6 +108,7 @@ static bool rxrpc_end_tx_phase(struct rxrpc_call *call, 
const char *abort_why)
}
 
write_unlock(>state_lock);
+   trace_rxrpc_transmit(call, rxrpc_transmit_end);
_leave(" = ok");
return true;
 }
diff --git a/net/rxrpc/misc.c b/net/rxrpc/misc.c
index 598064d3bdd2..dca89995f03e 100644
--- a/net/rxrpc/misc.c
+++ b/net/rxrpc/misc.c
@@ -132,3 +132,12 @@ const char rxrpc_client_traces[rxrpc_client__nr_trace][7] 
= {
[rxrpc_client_to_waiting]   = "->Wait",
[rxrpc_client_uncount]  = "Uncoun",
 };
+
+const char rxrpc_transmit_traces[rxrpc_transmit__nr_trace][4] = {
+   [rxrpc_transmit_wait]   = "WAI",
+   [rxrpc_transmit_queue]  = "QUE",
+   [rxrpc_transmit_queue_reqack]   = "QRA",
+   [rxrpc_transmit_queue_last] = "QLS",
+   [rxrpc_transmit_rotate] = "ROT",
+   [rxrpc_transmit_end]= "END",
+};
diff --git a/net/rxrpc/sendmsg.c b/net/rxrpc/sendmsg.c
index 8bfddf4e338c..28d8f73cf11d 100644
--- a/net/rxrpc/sendmsg.c
+++ b/net/rxrpc/sendmsg.c
@@ -56,6 +56,7 @@ static int rxrpc_wait_for_tx_window(struct rxrpc_sock *rx,
break;
}
 
+   trace_rxrpc_transmit(call, rxrpc_transmit_wait);
release_sock(>sk);
*timeo = schedule_timeout(*timeo);
lock_sock(>sk);
@@ -104,8 +105,14 @@ static void rxrpc_queue_packet(struct rxrpc_call *call, 
struct sk_buff *skb,
smp_wmb();
call->rxtx_buffer[ix] = skb;
call->tx_top = seq;
-   if (last)
+   if (last) {
set_bit(RXRPC_CALL_TX_LAST, >flags);
+   trace_rxrpc_transmit(call, rxrpc_transmit_queue_last);
+   } else if (sp->hdr.flags & RXRPC_REQUEST_ACK) {
+   trace_rxrpc_transmit(call, rxrpc_transmit_queue_reqack);
+   } else {
+   trace_rxrpc_transmit(call, rxrpc_transmit_queue);
+   }
 
if (last || call->state == RXRPC_CALL_SERVER_ACK_REQUEST) {

[PATCH net-next 03/11] rxrpc: Add connection tracepoint and client conn state tracepoint

2016-09-17 Thread David Howells
Add a pair of tracepoints, one to track rxrpc_connection struct ref
counting and the other to track the client connection cache state.

Signed-off-by: David Howells 
---

 include/trace/events/rxrpc.h |   60 +++
 net/rxrpc/ar-internal.h  |   76 +--
 net/rxrpc/call_accept.c  |4 ++
 net/rxrpc/call_object.c  |2 -
 net/rxrpc/conn_client.c  |   82 +-
 net/rxrpc/conn_event.c   |2 +
 net/rxrpc/conn_object.c  |   72 +++--
 net/rxrpc/conn_service.c |4 ++
 net/rxrpc/misc.c |   31 
 9 files changed, 274 insertions(+), 59 deletions(-)

diff --git a/include/trace/events/rxrpc.h b/include/trace/events/rxrpc.h
index 0a30c673509c..c0c496c83f31 100644
--- a/include/trace/events/rxrpc.h
+++ b/include/trace/events/rxrpc.h
@@ -16,6 +16,66 @@
 
 #include 
 
+TRACE_EVENT(rxrpc_conn,
+   TP_PROTO(struct rxrpc_connection *conn, enum rxrpc_conn_trace op,
+int usage, const void *where),
+
+   TP_ARGS(conn, op, usage, where),
+
+   TP_STRUCT__entry(
+   __field(struct rxrpc_connection *,  conn)
+   __field(int,op  )
+   __field(int,usage   )
+   __field(const void *,   where   )
+),
+
+   TP_fast_assign(
+   __entry->conn = conn;
+   __entry->op = op;
+   __entry->usage = usage;
+   __entry->where = where;
+  ),
+
+   TP_printk("C=%p %s u=%d sp=%pSR",
+ __entry->conn,
+ rxrpc_conn_traces[__entry->op],
+ __entry->usage,
+ __entry->where)
+   );
+
+TRACE_EVENT(rxrpc_client,
+   TP_PROTO(struct rxrpc_connection *conn, int channel,
+enum rxrpc_client_trace op),
+
+   TP_ARGS(conn, channel, op),
+
+   TP_STRUCT__entry(
+   __field(struct rxrpc_connection *,  conn)
+   __field(u32,cid )
+   __field(int,channel )
+   __field(int,usage   )
+   __field(enum rxrpc_client_trace,op  )
+   __field(enum rxrpc_conn_cache_state, cs )
+),
+
+   TP_fast_assign(
+   __entry->conn = conn;
+   __entry->channel = channel;
+   __entry->usage = atomic_read(>usage);
+   __entry->op = op;
+   __entry->cid = conn->proto.cid;
+   __entry->cs = conn->cache_state;
+  ),
+
+   TP_printk("C=%p h=%2d %s %s i=%08x u=%d",
+ __entry->conn,
+ __entry->channel,
+ rxrpc_client_traces[__entry->op],
+ rxrpc_conn_cache_states[__entry->cs],
+ __entry->cid,
+ __entry->usage)
+   );
+
 TRACE_EVENT(rxrpc_call,
TP_PROTO(struct rxrpc_call *call, enum rxrpc_call_trace op,
 int usage, const void *where, const void *aux),
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index 4a73c20d9436..6ca40eea3022 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -314,6 +314,7 @@ enum rxrpc_conn_cache_state {
RXRPC_CONN_CLIENT_ACTIVE,   /* Conn is on active list, doing calls 
*/
RXRPC_CONN_CLIENT_CULLED,   /* Conn is culled and delisted, doing 
calls */
RXRPC_CONN_CLIENT_IDLE, /* Conn is on idle list, doing mostly 
nothing */
+   RXRPC_CONN__NR_CACHE_STATES
 };
 
 /*
@@ -533,6 +534,44 @@ struct rxrpc_call {
rxrpc_serial_t  acks_latest;/* serial number of latest ACK 
received */
 };
 
+enum rxrpc_conn_trace {
+   rxrpc_conn_new_client,
+   rxrpc_conn_new_service,
+   rxrpc_conn_queued,
+   rxrpc_conn_seen,
+   rxrpc_conn_got,
+   rxrpc_conn_put_client,
+   rxrpc_conn_put_service,
+   rxrpc_conn__nr_trace
+};
+
+extern const char rxrpc_conn_traces[rxrpc_conn__nr_trace][4];
+
+enum rxrpc_client_trace {
+   rxrpc_client_activate_chans,
+   rxrpc_client_alloc,
+   rxrpc_client_chan_activate,
+   rxrpc_client_chan_disconnect,
+   rxrpc_client_chan_pass,
+   rxrpc_client_chan_unstarted,
+   rxrpc_client_cleanup,
+   rxrpc_client_count,
+   rxrpc_client_discard,
+   rxrpc_client_duplicate,
+   rxrpc_client_exposed,
+   rxrpc_client_replace,
+   rxrpc_client_to_active,
+   

[PATCH net-next 03/11] rxrpc: Add connection tracepoint and client conn state tracepoint

2016-09-17 Thread David Howells
Add a pair of tracepoints, one to track rxrpc_connection struct ref
counting and the other to track the client connection cache state.

Signed-off-by: David Howells 
---

 include/trace/events/rxrpc.h |   60 +++
 net/rxrpc/ar-internal.h  |   76 +--
 net/rxrpc/call_accept.c  |4 ++
 net/rxrpc/call_object.c  |2 -
 net/rxrpc/conn_client.c  |   82 +-
 net/rxrpc/conn_event.c   |2 +
 net/rxrpc/conn_object.c  |   72 +++--
 net/rxrpc/conn_service.c |4 ++
 net/rxrpc/misc.c |   31 
 9 files changed, 274 insertions(+), 59 deletions(-)

diff --git a/include/trace/events/rxrpc.h b/include/trace/events/rxrpc.h
index 0a30c673509c..c0c496c83f31 100644
--- a/include/trace/events/rxrpc.h
+++ b/include/trace/events/rxrpc.h
@@ -16,6 +16,66 @@
 
 #include 
 
+TRACE_EVENT(rxrpc_conn,
+   TP_PROTO(struct rxrpc_connection *conn, enum rxrpc_conn_trace op,
+int usage, const void *where),
+
+   TP_ARGS(conn, op, usage, where),
+
+   TP_STRUCT__entry(
+   __field(struct rxrpc_connection *,  conn)
+   __field(int,op  )
+   __field(int,usage   )
+   __field(const void *,   where   )
+),
+
+   TP_fast_assign(
+   __entry->conn = conn;
+   __entry->op = op;
+   __entry->usage = usage;
+   __entry->where = where;
+  ),
+
+   TP_printk("C=%p %s u=%d sp=%pSR",
+ __entry->conn,
+ rxrpc_conn_traces[__entry->op],
+ __entry->usage,
+ __entry->where)
+   );
+
+TRACE_EVENT(rxrpc_client,
+   TP_PROTO(struct rxrpc_connection *conn, int channel,
+enum rxrpc_client_trace op),
+
+   TP_ARGS(conn, channel, op),
+
+   TP_STRUCT__entry(
+   __field(struct rxrpc_connection *,  conn)
+   __field(u32,cid )
+   __field(int,channel )
+   __field(int,usage   )
+   __field(enum rxrpc_client_trace,op  )
+   __field(enum rxrpc_conn_cache_state, cs )
+),
+
+   TP_fast_assign(
+   __entry->conn = conn;
+   __entry->channel = channel;
+   __entry->usage = atomic_read(>usage);
+   __entry->op = op;
+   __entry->cid = conn->proto.cid;
+   __entry->cs = conn->cache_state;
+  ),
+
+   TP_printk("C=%p h=%2d %s %s i=%08x u=%d",
+ __entry->conn,
+ __entry->channel,
+ rxrpc_client_traces[__entry->op],
+ rxrpc_conn_cache_states[__entry->cs],
+ __entry->cid,
+ __entry->usage)
+   );
+
 TRACE_EVENT(rxrpc_call,
TP_PROTO(struct rxrpc_call *call, enum rxrpc_call_trace op,
 int usage, const void *where, const void *aux),
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index 4a73c20d9436..6ca40eea3022 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -314,6 +314,7 @@ enum rxrpc_conn_cache_state {
RXRPC_CONN_CLIENT_ACTIVE,   /* Conn is on active list, doing calls 
*/
RXRPC_CONN_CLIENT_CULLED,   /* Conn is culled and delisted, doing 
calls */
RXRPC_CONN_CLIENT_IDLE, /* Conn is on idle list, doing mostly 
nothing */
+   RXRPC_CONN__NR_CACHE_STATES
 };
 
 /*
@@ -533,6 +534,44 @@ struct rxrpc_call {
rxrpc_serial_t  acks_latest;/* serial number of latest ACK 
received */
 };
 
+enum rxrpc_conn_trace {
+   rxrpc_conn_new_client,
+   rxrpc_conn_new_service,
+   rxrpc_conn_queued,
+   rxrpc_conn_seen,
+   rxrpc_conn_got,
+   rxrpc_conn_put_client,
+   rxrpc_conn_put_service,
+   rxrpc_conn__nr_trace
+};
+
+extern const char rxrpc_conn_traces[rxrpc_conn__nr_trace][4];
+
+enum rxrpc_client_trace {
+   rxrpc_client_activate_chans,
+   rxrpc_client_alloc,
+   rxrpc_client_chan_activate,
+   rxrpc_client_chan_disconnect,
+   rxrpc_client_chan_pass,
+   rxrpc_client_chan_unstarted,
+   rxrpc_client_cleanup,
+   rxrpc_client_count,
+   rxrpc_client_discard,
+   rxrpc_client_duplicate,
+   rxrpc_client_exposed,
+   rxrpc_client_replace,
+   rxrpc_client_to_active,
+   rxrpc_client_to_culled,
+   

[PATCH net-next 09/11] rxrpc: Remove printks from rxrpc_recvmsg_data() to fix uninit var

2016-09-17 Thread David Howells
Remove _enter/_debug/_leave calls from rxrpc_recvmsg_data() of which one
uses an uninitialised variable.

Signed-off-by: David Howells 
---

 net/rxrpc/recvmsg.c |8 
 1 file changed, 8 deletions(-)

diff --git a/net/rxrpc/recvmsg.c b/net/rxrpc/recvmsg.c
index b62a08151895..79e65668bc58 100644
--- a/net/rxrpc/recvmsg.c
+++ b/net/rxrpc/recvmsg.c
@@ -296,8 +296,6 @@ static int rxrpc_recvmsg_data(struct socket *sock, struct 
rxrpc_call *call,
unsigned int rx_pkt_offset, rx_pkt_len;
int ix, copy, ret = -EAGAIN, ret2;
 
-   _enter("");
-
rx_pkt_offset = call->rx_pkt_offset;
rx_pkt_len = call->rx_pkt_len;
 
@@ -343,8 +341,6 @@ static int rxrpc_recvmsg_data(struct socket *sock, struct 
rxrpc_call *call,
trace_rxrpc_recvmsg(call, rxrpc_recvmsg_cont, seq,
rx_pkt_offset, rx_pkt_len, 0);
}
-   _debug("recvmsg %x DATA #%u { %d, %d }",
-  sp->hdr.callNumber, seq, rx_pkt_offset, rx_pkt_len);
 
/* We have to handle short, empty and used-up DATA packets. */
remain = len - *_offset;
@@ -360,8 +356,6 @@ static int rxrpc_recvmsg_data(struct socket *sock, struct 
rxrpc_call *call,
}
 
/* handle piecemeal consumption of data packets */
-   _debug("copied %d @%zu", copy, *_offset);
-
rx_pkt_offset += copy;
rx_pkt_len -= copy;
*_offset += copy;
@@ -370,7 +364,6 @@ static int rxrpc_recvmsg_data(struct socket *sock, struct 
rxrpc_call *call,
if (rx_pkt_len > 0) {
trace_rxrpc_recvmsg(call, rxrpc_recvmsg_full, seq,
rx_pkt_offset, rx_pkt_len, 0);
-   _debug("buffer full");
ASSERTCMP(*_offset, ==, len);
ret = 0;
break;
@@ -398,7 +391,6 @@ out:
 done:
trace_rxrpc_recvmsg(call, rxrpc_recvmsg_data_return, seq,
rx_pkt_offset, rx_pkt_len, ret);
-   _leave(" = %d [%u/%u]", ret, seq, top);
return ret;
 }
 



[PATCH net-next 11/11] rxrpc: Add config to inject packet loss

2016-09-17 Thread David Howells
Add a configuration option to inject packet loss by discarding
approximately every 8th packet received and approximately every 8th DATA
packet transmitted.

Note that no locking is used, but it shouldn't really matter.

Signed-off-by: David Howells 
---

 net/rxrpc/Kconfig  |7 +++
 net/rxrpc/input.c  |8 
 net/rxrpc/output.c |9 +
 3 files changed, 24 insertions(+)

diff --git a/net/rxrpc/Kconfig b/net/rxrpc/Kconfig
index 13396c74b5c1..86f8853a038c 100644
--- a/net/rxrpc/Kconfig
+++ b/net/rxrpc/Kconfig
@@ -26,6 +26,13 @@ config AF_RXRPC_IPV6
  Say Y here to allow AF_RXRPC to use IPV6 UDP as well as IPV4 UDP as
  its network transport.
 
+config AF_RXRPC_INJECT_LOSS
+   bool "Inject packet loss into RxRPC packet stream"
+   depends on AF_RXRPC
+   help
+ Say Y here to inject packet loss by discarding some received and some
+ transmitted packets.
+
 
 config AF_RXRPC_DEBUG
bool "RxRPC dynamic debugging"
diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c
index 84bb16d47b85..7ac1edf3aac7 100644
--- a/net/rxrpc/input.c
+++ b/net/rxrpc/input.c
@@ -712,6 +712,14 @@ void rxrpc_data_ready(struct sock *udp_sk)
skb_orphan(skb);
sp = rxrpc_skb(skb);
 
+   if (IS_ENABLED(CONFIG_AF_RXRPC_INJECT_LOSS)) {
+   static int lose;
+   if ((lose++ & 7) == 7) {
+   rxrpc_lose_skb(skb, rxrpc_skb_rx_lost);
+   return;
+   }
+   }
+
_net("Rx UDP packet from %08x:%04hu",
 ntohl(ip_hdr(skb)->saddr), ntohs(udp_hdr(skb)->source));
 
diff --git a/net/rxrpc/output.c b/net/rxrpc/output.c
index a2cad5ce7416..16e18a94ffa6 100644
--- a/net/rxrpc/output.c
+++ b/net/rxrpc/output.c
@@ -225,6 +225,15 @@ int rxrpc_send_data_packet(struct rxrpc_connection *conn, 
struct sk_buff *skb)
msg.msg_controllen = 0;
msg.msg_flags = 0;
 
+   if (IS_ENABLED(CONFIG_AF_RXRPC_INJECT_LOSS)) {
+   static int lose;
+   if ((lose++ & 7) == 7) {
+   rxrpc_lose_skb(skb, rxrpc_skb_tx_lost);
+   _leave(" = 0 [lose]");
+   return 0;
+   }
+   }
+
/* send the packet with the don't fragment bit set if we currently
 * think it's small enough */
if (skb->len - sizeof(struct rxrpc_wire_header) < 
conn->params.peer->maxdata) {



[PATCH net-next 08/11] rxrpc: Add a tracepoint to follow what recvmsg does

2016-09-17 Thread David Howells
Add a tracepoint to follow what recvmsg does within AF_RXRPC.

Signed-off-by: David Howells 
---

 include/trace/events/rxrpc.h |   34 ++
 net/rxrpc/ar-internal.h  |   17 +
 net/rxrpc/misc.c |   14 ++
 net/rxrpc/recvmsg.c  |   34 ++
 4 files changed, 91 insertions(+), 8 deletions(-)

diff --git a/include/trace/events/rxrpc.h b/include/trace/events/rxrpc.h
index 7dd5f0188681..58732202e9f0 100644
--- a/include/trace/events/rxrpc.h
+++ b/include/trace/events/rxrpc.h
@@ -323,6 +323,40 @@ TRACE_EVENT(rxrpc_receive,
  __entry->top)
);
 
+TRACE_EVENT(rxrpc_recvmsg,
+   TP_PROTO(struct rxrpc_call *call, enum rxrpc_recvmsg_trace why,
+rxrpc_seq_t seq, unsigned int offset, unsigned int len,
+int ret),
+
+   TP_ARGS(call, why, seq, offset, len, ret),
+
+   TP_STRUCT__entry(
+   __field(struct rxrpc_call *,call)
+   __field(enum rxrpc_recvmsg_trace,   why )
+   __field(rxrpc_seq_t,seq )
+   __field(unsigned int,   offset  )
+   __field(unsigned int,   len )
+   __field(int,ret )
+),
+
+   TP_fast_assign(
+   __entry->call = call;
+   __entry->why = why;
+   __entry->seq = seq;
+   __entry->offset = offset;
+   __entry->len = len;
+   __entry->ret = ret;
+  ),
+
+   TP_printk("c=%p %s q=%08x o=%u l=%u ret=%d",
+ __entry->call,
+ rxrpc_recvmsg_traces[__entry->why],
+ __entry->seq,
+ __entry->offset,
+ __entry->len,
+ __entry->ret)
+   );
+
 #endif /* _TRACE_RXRPC_H */
 
 /* This part must be outside protection */
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index e5d2f2fb8e41..a17341d2df3d 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -617,6 +617,23 @@ enum rxrpc_receive_trace {
 
 extern const char rxrpc_receive_traces[rxrpc_receive__nr_trace][4];
 
+enum rxrpc_recvmsg_trace {
+   rxrpc_recvmsg_enter,
+   rxrpc_recvmsg_wait,
+   rxrpc_recvmsg_dequeue,
+   rxrpc_recvmsg_hole,
+   rxrpc_recvmsg_next,
+   rxrpc_recvmsg_cont,
+   rxrpc_recvmsg_full,
+   rxrpc_recvmsg_data_return,
+   rxrpc_recvmsg_terminal,
+   rxrpc_recvmsg_to_be_accepted,
+   rxrpc_recvmsg_return,
+   rxrpc_recvmsg__nr_trace
+};
+
+extern const char rxrpc_recvmsg_traces[rxrpc_recvmsg__nr_trace][5];
+
 extern const char *const rxrpc_pkts[];
 extern const char *rxrpc_acks(u8 reason);
 
diff --git a/net/rxrpc/misc.c b/net/rxrpc/misc.c
index db5f1d54fc90..c7065d893d1e 100644
--- a/net/rxrpc/misc.c
+++ b/net/rxrpc/misc.c
@@ -150,3 +150,17 @@ const char 
rxrpc_receive_traces[rxrpc_receive__nr_trace][4] = {
[rxrpc_receive_rotate]  = "ROT",
[rxrpc_receive_end] = "END",
 };
+
+const char rxrpc_recvmsg_traces[rxrpc_recvmsg__nr_trace][5] = {
+   [rxrpc_recvmsg_enter]   = "ENTR",
+   [rxrpc_recvmsg_wait]= "WAIT",
+   [rxrpc_recvmsg_dequeue] = "DEQU",
+   [rxrpc_recvmsg_hole]= "HOLE",
+   [rxrpc_recvmsg_next]= "NEXT",
+   [rxrpc_recvmsg_cont]= "CONT",
+   [rxrpc_recvmsg_full]= "FULL",
+   [rxrpc_recvmsg_data_return] = "DATA",
+   [rxrpc_recvmsg_terminal]= "TERM",
+   [rxrpc_recvmsg_to_be_accepted]  = "TBAC",
+   [rxrpc_recvmsg_return]  = "RETN",
+};
diff --git a/net/rxrpc/recvmsg.c b/net/rxrpc/recvmsg.c
index 22d51087c580..b62a08151895 100644
--- a/net/rxrpc/recvmsg.c
+++ b/net/rxrpc/recvmsg.c
@@ -94,6 +94,8 @@ static int rxrpc_recvmsg_term(struct rxrpc_call *call, struct 
msghdr *msg)
break;
}
 
+   trace_rxrpc_recvmsg(call, rxrpc_recvmsg_terminal, call->rx_hard_ack,
+   call->rx_pkt_offset, call->rx_pkt_len, ret);
return ret;
 }
 
@@ -124,6 +126,7 @@ static int rxrpc_recvmsg_new_call(struct rxrpc_sock *rx,
write_unlock(>call_lock);
}
 
+   trace_rxrpc_recvmsg(call, rxrpc_recvmsg_to_be_accepted, 1, 0, 0, ret);
return ret;
 }
 
@@ -310,8 +313,11 @@ static int rxrpc_recvmsg_data(struct socket *sock, struct 
rxrpc_call *call,
for (seq = hard_ack + 1; before_eq(seq, top); seq++) {
ix = seq & RXRPC_RXTX_BUFF_MASK;
skb = call->rxtx_buffer[ix];
-   if (!skb)
+   if (!skb) {
+   

[PATCH net-next 10/11] rxrpc: Improve skb tracing

2016-09-17 Thread David Howells
Improve sk_buff tracing within AF_RXRPC by the following means:

 (1) Use an enum to note the event type rather than plain integers and use
 an array of event names rather than a big multi ?: list.

 (2) Distinguish Rx from Tx packets and account them separately.  This
 requires the call phase to be tracked so that we know what we might
 find in rxtx_buffer[].

 (3) Add a parameter to rxrpc_{new,see,get,free}_skb() to indicate the
 event type.

 (4) A pair of 'rotate' events are added to indicate packets that are about
 to be rotated out of the Rx and Tx windows.

 (5) A pair of 'lost' events are added, along with rxrpc_lose_skb() for
 packet loss injection recording.

Signed-off-by: David Howells 
---

 include/trace/events/rxrpc.h |   12 +++---
 net/rxrpc/af_rxrpc.c |5 ++--
 net/rxrpc/ar-internal.h  |   33 ++
 net/rxrpc/call_event.c   |8 +++---
 net/rxrpc/call_object.c  |   11 ++---
 net/rxrpc/conn_event.c   |6 ++---
 net/rxrpc/input.c|   13 ++
 net/rxrpc/local_event.c  |4 ++-
 net/rxrpc/misc.c |   18 ++
 net/rxrpc/output.c   |4 ++-
 net/rxrpc/peer_event.c   |   10 
 net/rxrpc/recvmsg.c  |7 +++---
 net/rxrpc/sendmsg.c  |   10 
 net/rxrpc/skbuff.c   |   53 ++
 14 files changed, 131 insertions(+), 63 deletions(-)

diff --git a/include/trace/events/rxrpc.h b/include/trace/events/rxrpc.h
index 58732202e9f0..75a5d8bf50e1 100644
--- a/include/trace/events/rxrpc.h
+++ b/include/trace/events/rxrpc.h
@@ -107,14 +107,14 @@ TRACE_EVENT(rxrpc_call,
);
 
 TRACE_EVENT(rxrpc_skb,
-   TP_PROTO(struct sk_buff *skb, int op, int usage, int mod_count,
-const void *where),
+   TP_PROTO(struct sk_buff *skb, enum rxrpc_skb_trace op,
+int usage, int mod_count, const void *where),
 
TP_ARGS(skb, op, usage, mod_count, where),
 
TP_STRUCT__entry(
__field(struct sk_buff *,   skb )
-   __field(int,op  )
+   __field(enum rxrpc_skb_trace,   op  )
__field(int,usage   )
__field(int,mod_count   )
__field(const void *,   where   )
@@ -130,11 +130,7 @@ TRACE_EVENT(rxrpc_skb,
 
TP_printk("s=%p %s u=%d m=%d p=%pSR",
  __entry->skb,
- (__entry->op == 0 ? "NEW" :
-  __entry->op == 1 ? "SEE" :
-  __entry->op == 2 ? "GET" :
-  __entry->op == 3 ? "FRE" :
-  "PUR"),
+ rxrpc_skb_traces[__entry->op],
  __entry->usage,
  __entry->mod_count,
  __entry->where)
diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
index 09f81befc705..8dbf7bed2cc4 100644
--- a/net/rxrpc/af_rxrpc.c
+++ b/net/rxrpc/af_rxrpc.c
@@ -45,7 +45,7 @@ u32 rxrpc_epoch;
 atomic_t rxrpc_debug_id;
 
 /* count of skbs currently in use */
-atomic_t rxrpc_n_skbs;
+atomic_t rxrpc_n_tx_skbs, rxrpc_n_rx_skbs;
 
 struct workqueue_struct *rxrpc_workqueue;
 
@@ -867,7 +867,8 @@ static void __exit af_rxrpc_exit(void)
proto_unregister(_proto);
rxrpc_destroy_all_calls();
rxrpc_destroy_all_connections();
-   ASSERTCMP(atomic_read(_n_skbs), ==, 0);
+   ASSERTCMP(atomic_read(_n_tx_skbs), ==, 0);
+   ASSERTCMP(atomic_read(_n_rx_skbs), ==, 0);
rxrpc_destroy_all_locals();
 
remove_proc_entry("rxrpc_conns", init_net.proc_net);
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index a17341d2df3d..034f525f2235 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -520,6 +520,7 @@ struct rxrpc_call {
rxrpc_seq_t rx_expect_next; /* Expected next packet 
sequence number */
u8  rx_winsize; /* Size of Rx window */
u8  tx_winsize; /* Maximum size of Tx window */
+   booltx_phase;   /* T if transmission phase, F 
if receive phase */
u8  nr_jumbo_bad;   /* Number of jumbo 
dups/exceeds-windows */
 
/* receive-phase ACK management */
@@ -534,6 +535,27 @@ struct rxrpc_call {
rxrpc_serial_t  acks_latest;/* serial number of latest ACK 
received */
 };
 
+enum rxrpc_skb_trace {
+   rxrpc_skb_rx_cleaned,
+   rxrpc_skb_rx_freed,
+   rxrpc_skb_rx_got,
+   rxrpc_skb_rx_lost,
+   rxrpc_skb_rx_received,
+   rxrpc_skb_rx_rotated,
+   rxrpc_skb_rx_purged,
+   rxrpc_skb_rx_seen,
+   rxrpc_skb_tx_cleaned,
+   

[PATCH net-next 09/11] rxrpc: Remove printks from rxrpc_recvmsg_data() to fix uninit var

2016-09-17 Thread David Howells
Remove _enter/_debug/_leave calls from rxrpc_recvmsg_data() of which one
uses an uninitialised variable.

Signed-off-by: David Howells 
---

 net/rxrpc/recvmsg.c |8 
 1 file changed, 8 deletions(-)

diff --git a/net/rxrpc/recvmsg.c b/net/rxrpc/recvmsg.c
index b62a08151895..79e65668bc58 100644
--- a/net/rxrpc/recvmsg.c
+++ b/net/rxrpc/recvmsg.c
@@ -296,8 +296,6 @@ static int rxrpc_recvmsg_data(struct socket *sock, struct 
rxrpc_call *call,
unsigned int rx_pkt_offset, rx_pkt_len;
int ix, copy, ret = -EAGAIN, ret2;
 
-   _enter("");
-
rx_pkt_offset = call->rx_pkt_offset;
rx_pkt_len = call->rx_pkt_len;
 
@@ -343,8 +341,6 @@ static int rxrpc_recvmsg_data(struct socket *sock, struct 
rxrpc_call *call,
trace_rxrpc_recvmsg(call, rxrpc_recvmsg_cont, seq,
rx_pkt_offset, rx_pkt_len, 0);
}
-   _debug("recvmsg %x DATA #%u { %d, %d }",
-  sp->hdr.callNumber, seq, rx_pkt_offset, rx_pkt_len);
 
/* We have to handle short, empty and used-up DATA packets. */
remain = len - *_offset;
@@ -360,8 +356,6 @@ static int rxrpc_recvmsg_data(struct socket *sock, struct 
rxrpc_call *call,
}
 
/* handle piecemeal consumption of data packets */
-   _debug("copied %d @%zu", copy, *_offset);
-
rx_pkt_offset += copy;
rx_pkt_len -= copy;
*_offset += copy;
@@ -370,7 +364,6 @@ static int rxrpc_recvmsg_data(struct socket *sock, struct 
rxrpc_call *call,
if (rx_pkt_len > 0) {
trace_rxrpc_recvmsg(call, rxrpc_recvmsg_full, seq,
rx_pkt_offset, rx_pkt_len, 0);
-   _debug("buffer full");
ASSERTCMP(*_offset, ==, len);
ret = 0;
break;
@@ -398,7 +391,6 @@ out:
 done:
trace_rxrpc_recvmsg(call, rxrpc_recvmsg_data_return, seq,
rx_pkt_offset, rx_pkt_len, ret);
-   _leave(" = %d [%u/%u]", ret, seq, top);
return ret;
 }
 



[PATCH net-next 11/11] rxrpc: Add config to inject packet loss

2016-09-17 Thread David Howells
Add a configuration option to inject packet loss by discarding
approximately every 8th packet received and approximately every 8th DATA
packet transmitted.

Note that no locking is used, but it shouldn't really matter.

Signed-off-by: David Howells 
---

 net/rxrpc/Kconfig  |7 +++
 net/rxrpc/input.c  |8 
 net/rxrpc/output.c |9 +
 3 files changed, 24 insertions(+)

diff --git a/net/rxrpc/Kconfig b/net/rxrpc/Kconfig
index 13396c74b5c1..86f8853a038c 100644
--- a/net/rxrpc/Kconfig
+++ b/net/rxrpc/Kconfig
@@ -26,6 +26,13 @@ config AF_RXRPC_IPV6
  Say Y here to allow AF_RXRPC to use IPV6 UDP as well as IPV4 UDP as
  its network transport.
 
+config AF_RXRPC_INJECT_LOSS
+   bool "Inject packet loss into RxRPC packet stream"
+   depends on AF_RXRPC
+   help
+ Say Y here to inject packet loss by discarding some received and some
+ transmitted packets.
+
 
 config AF_RXRPC_DEBUG
bool "RxRPC dynamic debugging"
diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c
index 84bb16d47b85..7ac1edf3aac7 100644
--- a/net/rxrpc/input.c
+++ b/net/rxrpc/input.c
@@ -712,6 +712,14 @@ void rxrpc_data_ready(struct sock *udp_sk)
skb_orphan(skb);
sp = rxrpc_skb(skb);
 
+   if (IS_ENABLED(CONFIG_AF_RXRPC_INJECT_LOSS)) {
+   static int lose;
+   if ((lose++ & 7) == 7) {
+   rxrpc_lose_skb(skb, rxrpc_skb_rx_lost);
+   return;
+   }
+   }
+
_net("Rx UDP packet from %08x:%04hu",
 ntohl(ip_hdr(skb)->saddr), ntohs(udp_hdr(skb)->source));
 
diff --git a/net/rxrpc/output.c b/net/rxrpc/output.c
index a2cad5ce7416..16e18a94ffa6 100644
--- a/net/rxrpc/output.c
+++ b/net/rxrpc/output.c
@@ -225,6 +225,15 @@ int rxrpc_send_data_packet(struct rxrpc_connection *conn, 
struct sk_buff *skb)
msg.msg_controllen = 0;
msg.msg_flags = 0;
 
+   if (IS_ENABLED(CONFIG_AF_RXRPC_INJECT_LOSS)) {
+   static int lose;
+   if ((lose++ & 7) == 7) {
+   rxrpc_lose_skb(skb, rxrpc_skb_tx_lost);
+   _leave(" = 0 [lose]");
+   return 0;
+   }
+   }
+
/* send the packet with the don't fragment bit set if we currently
 * think it's small enough */
if (skb->len - sizeof(struct rxrpc_wire_header) < 
conn->params.peer->maxdata) {



[PATCH net-next 08/11] rxrpc: Add a tracepoint to follow what recvmsg does

2016-09-17 Thread David Howells
Add a tracepoint to follow what recvmsg does within AF_RXRPC.

Signed-off-by: David Howells 
---

 include/trace/events/rxrpc.h |   34 ++
 net/rxrpc/ar-internal.h  |   17 +
 net/rxrpc/misc.c |   14 ++
 net/rxrpc/recvmsg.c  |   34 ++
 4 files changed, 91 insertions(+), 8 deletions(-)

diff --git a/include/trace/events/rxrpc.h b/include/trace/events/rxrpc.h
index 7dd5f0188681..58732202e9f0 100644
--- a/include/trace/events/rxrpc.h
+++ b/include/trace/events/rxrpc.h
@@ -323,6 +323,40 @@ TRACE_EVENT(rxrpc_receive,
  __entry->top)
);
 
+TRACE_EVENT(rxrpc_recvmsg,
+   TP_PROTO(struct rxrpc_call *call, enum rxrpc_recvmsg_trace why,
+rxrpc_seq_t seq, unsigned int offset, unsigned int len,
+int ret),
+
+   TP_ARGS(call, why, seq, offset, len, ret),
+
+   TP_STRUCT__entry(
+   __field(struct rxrpc_call *,call)
+   __field(enum rxrpc_recvmsg_trace,   why )
+   __field(rxrpc_seq_t,seq )
+   __field(unsigned int,   offset  )
+   __field(unsigned int,   len )
+   __field(int,ret )
+),
+
+   TP_fast_assign(
+   __entry->call = call;
+   __entry->why = why;
+   __entry->seq = seq;
+   __entry->offset = offset;
+   __entry->len = len;
+   __entry->ret = ret;
+  ),
+
+   TP_printk("c=%p %s q=%08x o=%u l=%u ret=%d",
+ __entry->call,
+ rxrpc_recvmsg_traces[__entry->why],
+ __entry->seq,
+ __entry->offset,
+ __entry->len,
+ __entry->ret)
+   );
+
 #endif /* _TRACE_RXRPC_H */
 
 /* This part must be outside protection */
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index e5d2f2fb8e41..a17341d2df3d 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -617,6 +617,23 @@ enum rxrpc_receive_trace {
 
 extern const char rxrpc_receive_traces[rxrpc_receive__nr_trace][4];
 
+enum rxrpc_recvmsg_trace {
+   rxrpc_recvmsg_enter,
+   rxrpc_recvmsg_wait,
+   rxrpc_recvmsg_dequeue,
+   rxrpc_recvmsg_hole,
+   rxrpc_recvmsg_next,
+   rxrpc_recvmsg_cont,
+   rxrpc_recvmsg_full,
+   rxrpc_recvmsg_data_return,
+   rxrpc_recvmsg_terminal,
+   rxrpc_recvmsg_to_be_accepted,
+   rxrpc_recvmsg_return,
+   rxrpc_recvmsg__nr_trace
+};
+
+extern const char rxrpc_recvmsg_traces[rxrpc_recvmsg__nr_trace][5];
+
 extern const char *const rxrpc_pkts[];
 extern const char *rxrpc_acks(u8 reason);
 
diff --git a/net/rxrpc/misc.c b/net/rxrpc/misc.c
index db5f1d54fc90..c7065d893d1e 100644
--- a/net/rxrpc/misc.c
+++ b/net/rxrpc/misc.c
@@ -150,3 +150,17 @@ const char 
rxrpc_receive_traces[rxrpc_receive__nr_trace][4] = {
[rxrpc_receive_rotate]  = "ROT",
[rxrpc_receive_end] = "END",
 };
+
+const char rxrpc_recvmsg_traces[rxrpc_recvmsg__nr_trace][5] = {
+   [rxrpc_recvmsg_enter]   = "ENTR",
+   [rxrpc_recvmsg_wait]= "WAIT",
+   [rxrpc_recvmsg_dequeue] = "DEQU",
+   [rxrpc_recvmsg_hole]= "HOLE",
+   [rxrpc_recvmsg_next]= "NEXT",
+   [rxrpc_recvmsg_cont]= "CONT",
+   [rxrpc_recvmsg_full]= "FULL",
+   [rxrpc_recvmsg_data_return] = "DATA",
+   [rxrpc_recvmsg_terminal]= "TERM",
+   [rxrpc_recvmsg_to_be_accepted]  = "TBAC",
+   [rxrpc_recvmsg_return]  = "RETN",
+};
diff --git a/net/rxrpc/recvmsg.c b/net/rxrpc/recvmsg.c
index 22d51087c580..b62a08151895 100644
--- a/net/rxrpc/recvmsg.c
+++ b/net/rxrpc/recvmsg.c
@@ -94,6 +94,8 @@ static int rxrpc_recvmsg_term(struct rxrpc_call *call, struct 
msghdr *msg)
break;
}
 
+   trace_rxrpc_recvmsg(call, rxrpc_recvmsg_terminal, call->rx_hard_ack,
+   call->rx_pkt_offset, call->rx_pkt_len, ret);
return ret;
 }
 
@@ -124,6 +126,7 @@ static int rxrpc_recvmsg_new_call(struct rxrpc_sock *rx,
write_unlock(>call_lock);
}
 
+   trace_rxrpc_recvmsg(call, rxrpc_recvmsg_to_be_accepted, 1, 0, 0, ret);
return ret;
 }
 
@@ -310,8 +313,11 @@ static int rxrpc_recvmsg_data(struct socket *sock, struct 
rxrpc_call *call,
for (seq = hard_ack + 1; before_eq(seq, top); seq++) {
ix = seq & RXRPC_RXTX_BUFF_MASK;
skb = call->rxtx_buffer[ix];
-   if (!skb)
+   if (!skb) {
+   trace_rxrpc_recvmsg(call, 

[PATCH net-next 10/11] rxrpc: Improve skb tracing

2016-09-17 Thread David Howells
Improve sk_buff tracing within AF_RXRPC by the following means:

 (1) Use an enum to note the event type rather than plain integers and use
 an array of event names rather than a big multi ?: list.

 (2) Distinguish Rx from Tx packets and account them separately.  This
 requires the call phase to be tracked so that we know what we might
 find in rxtx_buffer[].

 (3) Add a parameter to rxrpc_{new,see,get,free}_skb() to indicate the
 event type.

 (4) A pair of 'rotate' events are added to indicate packets that are about
 to be rotated out of the Rx and Tx windows.

 (5) A pair of 'lost' events are added, along with rxrpc_lose_skb() for
 packet loss injection recording.

Signed-off-by: David Howells 
---

 include/trace/events/rxrpc.h |   12 +++---
 net/rxrpc/af_rxrpc.c |5 ++--
 net/rxrpc/ar-internal.h  |   33 ++
 net/rxrpc/call_event.c   |8 +++---
 net/rxrpc/call_object.c  |   11 ++---
 net/rxrpc/conn_event.c   |6 ++---
 net/rxrpc/input.c|   13 ++
 net/rxrpc/local_event.c  |4 ++-
 net/rxrpc/misc.c |   18 ++
 net/rxrpc/output.c   |4 ++-
 net/rxrpc/peer_event.c   |   10 
 net/rxrpc/recvmsg.c  |7 +++---
 net/rxrpc/sendmsg.c  |   10 
 net/rxrpc/skbuff.c   |   53 ++
 14 files changed, 131 insertions(+), 63 deletions(-)

diff --git a/include/trace/events/rxrpc.h b/include/trace/events/rxrpc.h
index 58732202e9f0..75a5d8bf50e1 100644
--- a/include/trace/events/rxrpc.h
+++ b/include/trace/events/rxrpc.h
@@ -107,14 +107,14 @@ TRACE_EVENT(rxrpc_call,
);
 
 TRACE_EVENT(rxrpc_skb,
-   TP_PROTO(struct sk_buff *skb, int op, int usage, int mod_count,
-const void *where),
+   TP_PROTO(struct sk_buff *skb, enum rxrpc_skb_trace op,
+int usage, int mod_count, const void *where),
 
TP_ARGS(skb, op, usage, mod_count, where),
 
TP_STRUCT__entry(
__field(struct sk_buff *,   skb )
-   __field(int,op  )
+   __field(enum rxrpc_skb_trace,   op  )
__field(int,usage   )
__field(int,mod_count   )
__field(const void *,   where   )
@@ -130,11 +130,7 @@ TRACE_EVENT(rxrpc_skb,
 
TP_printk("s=%p %s u=%d m=%d p=%pSR",
  __entry->skb,
- (__entry->op == 0 ? "NEW" :
-  __entry->op == 1 ? "SEE" :
-  __entry->op == 2 ? "GET" :
-  __entry->op == 3 ? "FRE" :
-  "PUR"),
+ rxrpc_skb_traces[__entry->op],
  __entry->usage,
  __entry->mod_count,
  __entry->where)
diff --git a/net/rxrpc/af_rxrpc.c b/net/rxrpc/af_rxrpc.c
index 09f81befc705..8dbf7bed2cc4 100644
--- a/net/rxrpc/af_rxrpc.c
+++ b/net/rxrpc/af_rxrpc.c
@@ -45,7 +45,7 @@ u32 rxrpc_epoch;
 atomic_t rxrpc_debug_id;
 
 /* count of skbs currently in use */
-atomic_t rxrpc_n_skbs;
+atomic_t rxrpc_n_tx_skbs, rxrpc_n_rx_skbs;
 
 struct workqueue_struct *rxrpc_workqueue;
 
@@ -867,7 +867,8 @@ static void __exit af_rxrpc_exit(void)
proto_unregister(_proto);
rxrpc_destroy_all_calls();
rxrpc_destroy_all_connections();
-   ASSERTCMP(atomic_read(_n_skbs), ==, 0);
+   ASSERTCMP(atomic_read(_n_tx_skbs), ==, 0);
+   ASSERTCMP(atomic_read(_n_rx_skbs), ==, 0);
rxrpc_destroy_all_locals();
 
remove_proc_entry("rxrpc_conns", init_net.proc_net);
diff --git a/net/rxrpc/ar-internal.h b/net/rxrpc/ar-internal.h
index a17341d2df3d..034f525f2235 100644
--- a/net/rxrpc/ar-internal.h
+++ b/net/rxrpc/ar-internal.h
@@ -520,6 +520,7 @@ struct rxrpc_call {
rxrpc_seq_t rx_expect_next; /* Expected next packet 
sequence number */
u8  rx_winsize; /* Size of Rx window */
u8  tx_winsize; /* Maximum size of Tx window */
+   booltx_phase;   /* T if transmission phase, F 
if receive phase */
u8  nr_jumbo_bad;   /* Number of jumbo 
dups/exceeds-windows */
 
/* receive-phase ACK management */
@@ -534,6 +535,27 @@ struct rxrpc_call {
rxrpc_serial_t  acks_latest;/* serial number of latest ACK 
received */
 };
 
+enum rxrpc_skb_trace {
+   rxrpc_skb_rx_cleaned,
+   rxrpc_skb_rx_freed,
+   rxrpc_skb_rx_got,
+   rxrpc_skb_rx_lost,
+   rxrpc_skb_rx_received,
+   rxrpc_skb_rx_rotated,
+   rxrpc_skb_rx_purged,
+   rxrpc_skb_rx_seen,
+   rxrpc_skb_tx_cleaned,
+   rxrpc_skb_tx_freed,
+   

  1   2   3   4   5   >