date:20161105

drivers/regulator/lp872x.c:773: undefined reference to `devm_gpio_request_one'

2016-11-05 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:   bc33b0ca11e3df46a4fa7639ba488c9d4911
commit: 2527ecc9195e9c66252af24c4689e8a67cd4ccb9 gpio: Fix OF build problem on 
UM
date:   3 months 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 `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 `mv88e6xxx_probe':
>> drivers/net/dsa/mv88e6xxx/chip.c:4022: undefined reference to 
>> `devm_gpiod_get_optional'
   drivers/built-in.o: In function `pps_gpio_probe':
>> drivers/pps/clients/pps-gpio.c:125: undefined reference to 
>> `devm_gpio_request'
   drivers/built-in.o: In function `max8903_probe':
   drivers/power/max8903_charger.c:248: undefined reference to 
`devm_gpio_request'

drivers/regulator/lp872x.c:773: undefined reference to `devm_gpio_request_one'

2016-11-05 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:   bc33b0ca11e3df46a4fa7639ba488c9d4911
commit: 2527ecc9195e9c66252af24c4689e8a67cd4ccb9 gpio: Fix OF build problem on 
UM
date:   3 months 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 `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 `mv88e6xxx_probe':
>> drivers/net/dsa/mv88e6xxx/chip.c:4022: undefined reference to 
>> `devm_gpiod_get_optional'
   drivers/built-in.o: In function `pps_gpio_probe':
>> drivers/pps/clients/pps-gpio.c:125: undefined reference to 
>> `devm_gpio_request'
   drivers/built-in.o: In function `max8903_probe':
   drivers/power/max8903_charger.c:248: undefined reference to 
`devm_gpio_request'

[PATCH] net: amd: pcnet32: use new api ethtool_{get|set}_link_ksettings

2016-11-05 Thread Philippe Reynes

The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/amd/pcnet32.c |   14 --
 1 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/amd/pcnet32.c 
b/drivers/net/ethernet/amd/pcnet32.c
index adc7ab9..41e58cc 100644
--- a/drivers/net/ethernet/amd/pcnet32.c
+++ b/drivers/net/ethernet/amd/pcnet32.c
@@ -677,7 +677,8 @@ static void pcnet32_poll_controller(struct net_device *dev)
 }
 #endif
 
-static int pcnet32_get_settings(struct net_device *dev, struct ethtool_cmd 
*cmd)
+static int pcnet32_get_link_ksettings(struct net_device *dev,
+ struct ethtool_link_ksettings *cmd)
 {
struct pcnet32_private *lp = netdev_priv(dev);
unsigned long flags;
@@ -685,14 +686,15 @@ static int pcnet32_get_settings(struct net_device *dev, 
struct ethtool_cmd *cmd)
 
if (lp->mii) {
spin_lock_irqsave(>lock, flags);
-   mii_ethtool_gset(>mii_if, cmd);
+   mii_ethtool_get_link_ksettings(>mii_if, cmd);
spin_unlock_irqrestore(>lock, flags);
r = 0;
}
return r;
 }
 
-static int pcnet32_set_settings(struct net_device *dev, struct ethtool_cmd 
*cmd)
+static int pcnet32_set_link_ksettings(struct net_device *dev,
+ const struct ethtool_link_ksettings *cmd)
 {
struct pcnet32_private *lp = netdev_priv(dev);
unsigned long flags;
@@ -700,7 +702,7 @@ static int pcnet32_set_settings(struct net_device *dev, 
struct ethtool_cmd *cmd)
 
if (lp->mii) {
spin_lock_irqsave(>lock, flags);
-   r = mii_ethtool_sset(>mii_if, cmd);
+   r = mii_ethtool_set_link_ksettings(>mii_if, cmd);
spin_unlock_irqrestore(>lock, flags);
}
return r;
@@ -1440,8 +1442,6 @@ static void pcnet32_get_regs(struct net_device *dev, 
struct ethtool_regs *regs,
 }
 
 static const struct ethtool_ops pcnet32_ethtool_ops = {
-   .get_settings   = pcnet32_get_settings,
-   .set_settings   = pcnet32_set_settings,
.get_drvinfo= pcnet32_get_drvinfo,
.get_msglevel   = pcnet32_get_msglevel,
.set_msglevel   = pcnet32_set_msglevel,
@@ -1455,6 +1455,8 @@ static void pcnet32_get_regs(struct net_device *dev, 
struct ethtool_regs *regs,
.get_regs_len   = pcnet32_get_regs_len,
.get_regs   = pcnet32_get_regs,
.get_sset_count = pcnet32_get_sset_count,
+   .get_link_ksettings = pcnet32_get_link_ksettings,
+   .set_link_ksettings = pcnet32_set_link_ksettings,
 };
 
 /* only probes for non-PCI devices, the rest are handled by
-- 
1.7.4.4

[PATCH] net: amd: pcnet32: use new api ethtool_{get|set}_link_ksettings

2016-11-05 Thread Philippe Reynes

The ethtool api {get|set}_settings is deprecated.
We move this driver to new api {get|set}_link_ksettings.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/amd/pcnet32.c |   14 --
 1 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/drivers/net/ethernet/amd/pcnet32.c 
b/drivers/net/ethernet/amd/pcnet32.c
index adc7ab9..41e58cc 100644
--- a/drivers/net/ethernet/amd/pcnet32.c
+++ b/drivers/net/ethernet/amd/pcnet32.c
@@ -677,7 +677,8 @@ static void pcnet32_poll_controller(struct net_device *dev)
 }
 #endif
 
-static int pcnet32_get_settings(struct net_device *dev, struct ethtool_cmd 
*cmd)
+static int pcnet32_get_link_ksettings(struct net_device *dev,
+ struct ethtool_link_ksettings *cmd)
 {
struct pcnet32_private *lp = netdev_priv(dev);
unsigned long flags;
@@ -685,14 +686,15 @@ static int pcnet32_get_settings(struct net_device *dev, 
struct ethtool_cmd *cmd)
 
if (lp->mii) {
spin_lock_irqsave(>lock, flags);
-   mii_ethtool_gset(>mii_if, cmd);
+   mii_ethtool_get_link_ksettings(>mii_if, cmd);
spin_unlock_irqrestore(>lock, flags);
r = 0;
}
return r;
 }
 
-static int pcnet32_set_settings(struct net_device *dev, struct ethtool_cmd 
*cmd)
+static int pcnet32_set_link_ksettings(struct net_device *dev,
+ const struct ethtool_link_ksettings *cmd)
 {
struct pcnet32_private *lp = netdev_priv(dev);
unsigned long flags;
@@ -700,7 +702,7 @@ static int pcnet32_set_settings(struct net_device *dev, 
struct ethtool_cmd *cmd)
 
if (lp->mii) {
spin_lock_irqsave(>lock, flags);
-   r = mii_ethtool_sset(>mii_if, cmd);
+   r = mii_ethtool_set_link_ksettings(>mii_if, cmd);
spin_unlock_irqrestore(>lock, flags);
}
return r;
@@ -1440,8 +1442,6 @@ static void pcnet32_get_regs(struct net_device *dev, 
struct ethtool_regs *regs,
 }
 
 static const struct ethtool_ops pcnet32_ethtool_ops = {
-   .get_settings   = pcnet32_get_settings,
-   .set_settings   = pcnet32_set_settings,
.get_drvinfo= pcnet32_get_drvinfo,
.get_msglevel   = pcnet32_get_msglevel,
.set_msglevel   = pcnet32_set_msglevel,
@@ -1455,6 +1455,8 @@ static void pcnet32_get_regs(struct net_device *dev, 
struct ethtool_regs *regs,
.get_regs_len   = pcnet32_get_regs_len,
.get_regs   = pcnet32_get_regs,
.get_sset_count = pcnet32_get_sset_count,
+   .get_link_ksettings = pcnet32_get_link_ksettings,
+   .set_link_ksettings = pcnet32_set_link_ksettings,
 };
 
 /* only probes for non-PCI devices, the rest are handled by
-- 
1.7.4.4

Re: [PATCH] perf thread: cleanup with list_first_entry_or_null()

2016-11-05 Thread Arnaldo Carvalho de Melo

Em Sun, Nov 06, 2016 at 12:00:22PM +0900, Masahiro Yamada escreveu:
> Hi maintainers,
> 
> Does this patch look good?

>From a quick look it seems ok, I'll try and process it when back home.

- Arnaldo
 
> 2016-09-13 3:29 GMT+09:00 Masahiro Yamada :
> > The combo of list_empty() check and return list_first_entry()
> > can be replaced with list_first_entry_or_null().
> >
> > Signed-off-by: Masahiro Yamada 
> > ---
> >
> >  tools/perf/util/thread.c | 5 +
> >  1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
> > index 8b10a55..ea951df 100644
> > --- a/tools/perf/util/thread.c
> > +++ b/tools/perf/util/thread.c
> > @@ -107,10 +107,7 @@ void thread__put(struct thread *thread)
> >
> >  struct comm *thread__comm(const struct thread *thread)
> >  {
> > -   if (list_empty(>comm_list))
> > -   return NULL;
> > -
> > -   return list_first_entry(>comm_list, struct comm, list);
> > +   return list_first_entry_or_null(>comm_list, struct comm, 
> > list);
> >  }
> >
> >  struct comm *thread__exec_comm(const struct thread *thread)
> > --
> > 1.9.1
> >
> 
> 
> 
> -- 
> Best Regards
> Masahiro Yamada

Re: [PATCH] perf thread: cleanup with list_first_entry_or_null()

2016-11-05 Thread Arnaldo Carvalho de Melo

Em Sun, Nov 06, 2016 at 12:00:22PM +0900, Masahiro Yamada escreveu:
> Hi maintainers,
> 
> Does this patch look good?

>From a quick look it seems ok, I'll try and process it when back home.

- Arnaldo
 
> 2016-09-13 3:29 GMT+09:00 Masahiro Yamada :
> > The combo of list_empty() check and return list_first_entry()
> > can be replaced with list_first_entry_or_null().
> >
> > Signed-off-by: Masahiro Yamada 
> > ---
> >
> >  tools/perf/util/thread.c | 5 +
> >  1 file changed, 1 insertion(+), 4 deletions(-)
> >
> > diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
> > index 8b10a55..ea951df 100644
> > --- a/tools/perf/util/thread.c
> > +++ b/tools/perf/util/thread.c
> > @@ -107,10 +107,7 @@ void thread__put(struct thread *thread)
> >
> >  struct comm *thread__comm(const struct thread *thread)
> >  {
> > -   if (list_empty(>comm_list))
> > -   return NULL;
> > -
> > -   return list_first_entry(>comm_list, struct comm, list);
> > +   return list_first_entry_or_null(>comm_list, struct comm, 
> > list);
> >  }
> >
> >  struct comm *thread__exec_comm(const struct thread *thread)
> > --
> > 1.9.1
> >
> 
> 
> 
> -- 
> Best Regards
> Masahiro Yamada

cc1: error: '-march=r3000' requires '-mfp32'

2016-11-05 Thread kbuild test robot

Hi James,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   bc33b0ca11e3df46a4fa7639ba488c9d4911
commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of 
vdso.lds
date:   4 weeks 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 034827c727f7f3946a18355b63995b402c226c82
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> cc1: error: '-march=r3000' requires '-mfp32'

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


.config.gz
Description: application/gzip

cc1: error: '-march=r3000' requires '-mfp32'

2016-11-05 Thread kbuild test robot

Hi James,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   bc33b0ca11e3df46a4fa7639ba488c9d4911
commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of 
vdso.lds
date:   4 weeks 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 034827c727f7f3946a18355b63995b402c226c82
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> cc1: error: '-march=r3000' requires '-mfp32'

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


.config.gz
Description: application/gzip

[PATCH 1/2] s390: delete unneeded #include from facilities_src.h

2016-11-05 Thread Masahiro Yamada

The header facilities_src.h is only included from gen_facilities.c
and the tool is compiled with the following extra options:

HOSTCFLAGS_gen_facilities.o += -Wall $(LINUXINCLUDE)

Please note $(LINUXINCLUDE) is expanded into build options including:

-include $(srctree)/include/linux/kconfig.h

So, the Makefile always forces the tool to include kconfig.h, i.e.,
the #include  directive in the header is redundant.

Signed-off-by: Masahiro Yamada 
---

 arch/s390/include/asm/facilities_src.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/s390/include/asm/facilities_src.h 
b/arch/s390/include/asm/facilities_src.h
index 3b758f6..8b1a692 100644
--- a/arch/s390/include/asm/facilities_src.h
+++ b/arch/s390/include/asm/facilities_src.h
@@ -6,8 +6,6 @@
 #error "This file can only be included by gen_facilities.c"
 #endif
 
-#include 
-
 struct facility_def {
char *name;
int *bits;
-- 
1.9.1

[PATCH 1/2] s390: delete unneeded #include from facilities_src.h

2016-11-05 Thread Masahiro Yamada

The header facilities_src.h is only included from gen_facilities.c
and the tool is compiled with the following extra options:

HOSTCFLAGS_gen_facilities.o += -Wall $(LINUXINCLUDE)

Please note $(LINUXINCLUDE) is expanded into build options including:

-include $(srctree)/include/linux/kconfig.h

So, the Makefile always forces the tool to include kconfig.h, i.e.,
the #include  directive in the header is redundant.

Signed-off-by: Masahiro Yamada 
---

 arch/s390/include/asm/facilities_src.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/s390/include/asm/facilities_src.h 
b/arch/s390/include/asm/facilities_src.h
index 3b758f6..8b1a692 100644
--- a/arch/s390/include/asm/facilities_src.h
+++ b/arch/s390/include/asm/facilities_src.h
@@ -6,8 +6,6 @@
 #error "This file can only be included by gen_facilities.c"
 #endif
 
-#include 
-
 struct facility_def {
char *name;
int *bits;
-- 
1.9.1

[PATCH 2/2] s390: squash facilities_src.h into gen_facilities.c

2016-11-05 Thread Masahiro Yamada

We generally expect headers in arch/$(ARCH)/include/asm directory
are included from kernel sources, but facilities_src.h is not;
it is included from the arch/s390/tools/gen_facilities.c tool.

There is no reason to expose this header to the public include path.
Furthermore, facilities_src.h makes sure to be included only from
gen_facilities.c by the following:

  #ifndef S390_GEN_FACILITIES_C
  #error "This file can only be included by gen_facilities.c"
  #endif

This check can be removed by merging the two files.

Signed-off-by: Masahiro Yamada 
---

 arch/s390/include/asm/facilities_src.h | 80 --
 arch/s390/tools/gen_facilities.c   | 76 ++--
 2 files changed, 73 insertions(+), 83 deletions(-)
 delete mode 100644 arch/s390/include/asm/facilities_src.h

diff --git a/arch/s390/include/asm/facilities_src.h 
b/arch/s390/include/asm/facilities_src.h
deleted file mode 100644
index 8b1a692..000
--- a/arch/s390/include/asm/facilities_src.h
+++ /dev/null
@@ -1,80 +0,0 @@
-/*
- *Copyright IBM Corp. 2015
- */
-
-#ifndef S390_GEN_FACILITIES_C
-#error "This file can only be included by gen_facilities.c"
-#endif
-
-struct facility_def {
-   char *name;
-   int *bits;
-};
-
-static struct facility_def facility_defs[] = {
-   {
-   /*
-* FACILITIES_ALS contains the list of facilities that are
-* required to run a kernel that is compiled e.g. with
-* -march=.
-*/
-   .name = "FACILITIES_ALS",
-   .bits = (int[]){
-#ifdef CONFIG_HAVE_MARCH_Z900_FEATURES
-   0,  /* N3 instructions */
-   1,  /* z/Arch mode installed */
-#endif
-#ifdef CONFIG_HAVE_MARCH_Z990_FEATURES
-   18, /* long displacement facility */
-#endif
-#ifdef CONFIG_HAVE_MARCH_Z9_109_FEATURES
-   7,  /* stfle */
-   17, /* message security assist */
-   21, /* extended-immediate facility */
-   25, /* store clock fast */
-#endif
-#ifdef CONFIG_HAVE_MARCH_Z10_FEATURES
-   27, /* mvcos */
-   32, /* compare and swap and store */
-   33, /* compare and swap and store 2 */
-   34, /* general extension facility */
-   35, /* execute extensions */
-#endif
-#ifdef CONFIG_HAVE_MARCH_Z196_FEATURES
-   45, /* fast-BCR, etc. */
-#endif
-#ifdef CONFIG_HAVE_MARCH_ZEC12_FEATURES
-   49, /* misc-instruction-extensions */
-   52, /* interlocked facility 2 */
-#endif
-#ifdef CONFIG_HAVE_MARCH_Z13_FEATURES
-   53, /* load-and-zero-rightmost-byte, etc. */
-#endif
-   -1 /* END */
-   }
-   },
-   {
-   .name = "FACILITIES_KVM",
-   .bits = (int[]){
-   0,  /* N3 instructions */
-   1,  /* z/Arch mode installed */
-   2,  /* z/Arch mode active */
-   3,  /* DAT-enhancement */
-   4,  /* idte segment table */
-   5,  /* idte region table */
-   6,  /* ASN-and-LX reuse */
-   7,  /* stfle */
-   8,  /* enhanced-DAT 1 */
-   9,  /* sense-running-status */
-   10, /* conditional sske */
-   13, /* ipte-range */
-   14, /* nonquiescing key-setting */
-   73, /* transactional execution */
-   75, /* access-exception-fetch/store indication */
-   76, /* msa extension 3 */
-   77, /* msa extension 4 */
-   78, /* enhanced-DAT 2 */
-   -1  /* END */
-   }
-   },
-};
diff --git a/arch/s390/tools/gen_facilities.c b/arch/s390/tools/gen_facilities.c
index fe4e6c9..8cc53b1 100644
--- a/arch/s390/tools/gen_facilities.c
+++ b/arch/s390/tools/gen_facilities.c
@@ -7,13 +7,83 @@
  *
  */
 
-#define S390_GEN_FACILITIES_C
-
 #include 
 #include 
 #include 
 #include 
-#include 
+
+struct facility_def {
+   char *name;
+   int *bits;
+};
+
+static struct facility_def facility_defs[] = {
+   {
+   /*
+* FACILITIES_ALS contains the list of facilities that are
+* required to run a kernel that is compiled e.g. with
+* -march=.
+*/
+   .name = "FACILITIES_ALS",
+   .bits = (int[]){
+#ifdef CONFIG_HAVE_MARCH_Z900_FEATURES
+   0,  /* N3 instructions */
+   1,  /* z/Arch mode installed */
+#endif
+#ifdef CONFIG_HAVE_MARCH_Z990_FEATURES
+   18, /* long displacement

[PATCH 2/2] s390: squash facilities_src.h into gen_facilities.c

2016-11-05 Thread Masahiro Yamada

We generally expect headers in arch/$(ARCH)/include/asm directory
are included from kernel sources, but facilities_src.h is not;
it is included from the arch/s390/tools/gen_facilities.c tool.

There is no reason to expose this header to the public include path.
Furthermore, facilities_src.h makes sure to be included only from
gen_facilities.c by the following:

  #ifndef S390_GEN_FACILITIES_C
  #error "This file can only be included by gen_facilities.c"
  #endif

This check can be removed by merging the two files.

Signed-off-by: Masahiro Yamada 
---

 arch/s390/include/asm/facilities_src.h | 80 --
 arch/s390/tools/gen_facilities.c   | 76 ++--
 2 files changed, 73 insertions(+), 83 deletions(-)
 delete mode 100644 arch/s390/include/asm/facilities_src.h

diff --git a/arch/s390/include/asm/facilities_src.h 
b/arch/s390/include/asm/facilities_src.h
deleted file mode 100644
index 8b1a692..000
--- a/arch/s390/include/asm/facilities_src.h
+++ /dev/null
@@ -1,80 +0,0 @@
-/*
- *Copyright IBM Corp. 2015
- */
-
-#ifndef S390_GEN_FACILITIES_C
-#error "This file can only be included by gen_facilities.c"
-#endif
-
-struct facility_def {
-   char *name;
-   int *bits;
-};
-
-static struct facility_def facility_defs[] = {
-   {
-   /*
-* FACILITIES_ALS contains the list of facilities that are
-* required to run a kernel that is compiled e.g. with
-* -march=.
-*/
-   .name = "FACILITIES_ALS",
-   .bits = (int[]){
-#ifdef CONFIG_HAVE_MARCH_Z900_FEATURES
-   0,  /* N3 instructions */
-   1,  /* z/Arch mode installed */
-#endif
-#ifdef CONFIG_HAVE_MARCH_Z990_FEATURES
-   18, /* long displacement facility */
-#endif
-#ifdef CONFIG_HAVE_MARCH_Z9_109_FEATURES
-   7,  /* stfle */
-   17, /* message security assist */
-   21, /* extended-immediate facility */
-   25, /* store clock fast */
-#endif
-#ifdef CONFIG_HAVE_MARCH_Z10_FEATURES
-   27, /* mvcos */
-   32, /* compare and swap and store */
-   33, /* compare and swap and store 2 */
-   34, /* general extension facility */
-   35, /* execute extensions */
-#endif
-#ifdef CONFIG_HAVE_MARCH_Z196_FEATURES
-   45, /* fast-BCR, etc. */
-#endif
-#ifdef CONFIG_HAVE_MARCH_ZEC12_FEATURES
-   49, /* misc-instruction-extensions */
-   52, /* interlocked facility 2 */
-#endif
-#ifdef CONFIG_HAVE_MARCH_Z13_FEATURES
-   53, /* load-and-zero-rightmost-byte, etc. */
-#endif
-   -1 /* END */
-   }
-   },
-   {
-   .name = "FACILITIES_KVM",
-   .bits = (int[]){
-   0,  /* N3 instructions */
-   1,  /* z/Arch mode installed */
-   2,  /* z/Arch mode active */
-   3,  /* DAT-enhancement */
-   4,  /* idte segment table */
-   5,  /* idte region table */
-   6,  /* ASN-and-LX reuse */
-   7,  /* stfle */
-   8,  /* enhanced-DAT 1 */
-   9,  /* sense-running-status */
-   10, /* conditional sske */
-   13, /* ipte-range */
-   14, /* nonquiescing key-setting */
-   73, /* transactional execution */
-   75, /* access-exception-fetch/store indication */
-   76, /* msa extension 3 */
-   77, /* msa extension 4 */
-   78, /* enhanced-DAT 2 */
-   -1  /* END */
-   }
-   },
-};
diff --git a/arch/s390/tools/gen_facilities.c b/arch/s390/tools/gen_facilities.c
index fe4e6c9..8cc53b1 100644
--- a/arch/s390/tools/gen_facilities.c
+++ b/arch/s390/tools/gen_facilities.c
@@ -7,13 +7,83 @@
  *
  */
 
-#define S390_GEN_FACILITIES_C
-
 #include 
 #include 
 #include 
 #include 
-#include 
+
+struct facility_def {
+   char *name;
+   int *bits;
+};
+
+static struct facility_def facility_defs[] = {
+   {
+   /*
+* FACILITIES_ALS contains the list of facilities that are
+* required to run a kernel that is compiled e.g. with
+* -march=.
+*/
+   .name = "FACILITIES_ALS",
+   .bits = (int[]){
+#ifdef CONFIG_HAVE_MARCH_Z900_FEATURES
+   0,  /* N3 instructions */
+   1,  /* z/Arch mode installed */
+#endif
+#ifdef CONFIG_HAVE_MARCH_Z990_FEATURES
+   18, /* long displacement facility */
+#endif
+#ifdef

Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

2016-11-05 Thread Henrique de Moraes Holschuh

On Sat, 05 Nov 2016, Pavel Machek wrote:
> On Sat 2016-11-05 15:46:12, Henrique de Moraes Holschuh wrote:
> > On Sat, 05 Nov 2016, Pavel Machek wrote:
> > > Hmm, thanks for the pointer. But it seems like I'll have to build my
> > > own, as /proc/acpi/ibm does not follow the usual infrastructure...
> > 
> > /proc/acpi/ibm has been deprecated for years.  99% of the functionality
> > is available through more modern, standard interfaces.
> 
> Right, I see sensors can do it these days. Would it be good to expose
> them as /sys/class/thermal/thermal_zone*, too?

I don't like the idea of touching vendor-screwup-land like thermal
zones, especially when thinkpads *already* have thermal zones and they
must come from the very same sensors...

This would need a lot of careful studying and planning.

> Is it known what various fields in /proc/acpi/ibm/thermal measure?

It varies with each model.  You can map it out with better precision by
using a cold spray while doing an "open-heart" surgery on the thinkpad.
I kid you not, that's how they were mapped for some models.

Look for information about this in thinkwiki:
http://www.thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_X60

The battery-pack-related sensor that is stuck at 50°C is something the
Lenovo Yamato labs guys wouldn't be clear about.  They told me to look
at what the Windows drivers do, but that would require (1) Windows in
the first place, and (2) clean room reverse engineering protocols.

> Basically... 100C is okay for semiconductors, but I'd prefer not to
> kill the hard drive

Well, that first sensor getting to 100°C is your CPU for sure.

> > thinkpad-acpi is supposed to export standard hwmon temperature sensors
> > as well.  Try them instead, please.
> 
> Heh, I just finished python to work with /proc/acpi/ibm. Oh well.

Hey, I *did* properly document that driver, and the documentation is
even mostly up-to-date...  Please refer to
Documentation/laptops/thinkpad-acpi.txt in the kernel tree.

-- 
  Henrique Holschuh

Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

2016-11-05 Thread Henrique de Moraes Holschuh

On Sat, 05 Nov 2016, Pavel Machek wrote:
> On Sat 2016-11-05 15:46:12, Henrique de Moraes Holschuh wrote:
> > On Sat, 05 Nov 2016, Pavel Machek wrote:
> > > Hmm, thanks for the pointer. But it seems like I'll have to build my
> > > own, as /proc/acpi/ibm does not follow the usual infrastructure...
> > 
> > /proc/acpi/ibm has been deprecated for years.  99% of the functionality
> > is available through more modern, standard interfaces.
> 
> Right, I see sensors can do it these days. Would it be good to expose
> them as /sys/class/thermal/thermal_zone*, too?

I don't like the idea of touching vendor-screwup-land like thermal
zones, especially when thinkpads *already* have thermal zones and they
must come from the very same sensors...

This would need a lot of careful studying and planning.

> Is it known what various fields in /proc/acpi/ibm/thermal measure?

It varies with each model.  You can map it out with better precision by
using a cold spray while doing an "open-heart" surgery on the thinkpad.
I kid you not, that's how they were mapped for some models.

Look for information about this in thinkwiki:
http://www.thinkwiki.org/wiki/Thermal_Sensors#ThinkPad_X60

The battery-pack-related sensor that is stuck at 50°C is something the
Lenovo Yamato labs guys wouldn't be clear about.  They told me to look
at what the Windows drivers do, but that would require (1) Windows in
the first place, and (2) clean room reverse engineering protocols.

> Basically... 100C is okay for semiconductors, but I'd prefer not to
> kill the hard drive

Well, that first sensor getting to 100°C is your CPU for sure.

> > thinkpad-acpi is supposed to export standard hwmon temperature sensors
> > as well.  Try them instead, please.
> 
> Heh, I just finished python to work with /proc/acpi/ibm. Oh well.

Hey, I *did* properly document that driver, and the documentation is
even mostly up-to-date...  Please refer to
Documentation/laptops/thinkpad-acpi.txt in the kernel tree.

-- 
  Henrique Holschuh

Re: [PATCH v3] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines

2016-11-05 Thread Stephen Warren


On 10/27/2016 10:52 AM, Eric Anholt wrote:

From: Linus Walleij 

The idea is to give useful names to GPIO lines that an implementer
will be using from userspace, e.g. for maker type projects.  These are
user-visible using tools/gpio/lsgpio.c



 arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 65 +++
 arch/arm/boot/dts/bcm2835-rpi-a.dts  | 67 
 arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 66 +++
 arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 66 +++
 arch/arm/boot/dts/bcm2835-rpi-b.dts  | 67 


Aren't the A and B rev 2 pinouts the same. If so, why duplicate the 
content between the files instead of creating an inclue file? Same for 
A+, B+, Pi 2, and Pi 3. Shouldn't this patch update the Pi 2 and Pi 3 
DTs too?



diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts 
b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts



  {
+   /*
+* This is based on the unreleased schematic for the Model A+.
+*
+* Legend:
+* "NC" = not connected (no rail from the SoC)
+* "FOO" = GPIO line named "FOO" on the schematic
+* "FOO_N" = GPIO line named "FOO" on schematic, active low
+*/
+   gpio-line-names = "SDA0",
+ "SCL0",



diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts 
b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts



  {
+   /*
+* Taken from Raspberry-Pi-B-Plus-V1.2-Schematics.pdf
+* RPI-BPLUS sheet 1
+*
+* Legend:
+* "NC" = not connected (no rail from the SoC)
+* "FOO" = GPIO line named "FOO" on the schematic
+* "FOO_N" = GPIO line named "FOO" on schematic, active low
+*/
+   gpio-line-names = "ID_SD",
+ "ID_SC",


I think the whole point of naming GPIOs is to give users the same 
experience across the different boards where the same semantics exist in 
HW. Both the A+ and B+ use GPIO0/1 (a/k/a ID_SD/ID_SC a/k/a SDA0/SCL0) 
for the same semantic purpose and are exposed in the same externally 
visible way (same pins on the expansion header); the board ID EEPROM. 
Therefore I assert the names of these GPIOs should be identical on all 
boards that use them for that purpose, to allow SW (or human knowledge) 
portability between the boards.



+ "GPIO17",


This pin is known as GPIO_GEN0 on the expansion header. Given the 
expansion header is all end-users likely care about, and other pins 
(e.g. SPI_CE1_N) are named after the expansion header, shouldn't this 
patch use the GPIO expansion header naming for all pins that are routed 
to that header?

Re: [PATCH v3] ARM: bcm2835: Add names for the Raspberry Pi GPIO lines

2016-11-05 Thread Stephen Warren


On 10/27/2016 10:52 AM, Eric Anholt wrote:

From: Linus Walleij 

The idea is to give useful names to GPIO lines that an implementer
will be using from userspace, e.g. for maker type projects.  These are
user-visible using tools/gpio/lsgpio.c



 arch/arm/boot/dts/bcm2835-rpi-a-plus.dts | 65 +++
 arch/arm/boot/dts/bcm2835-rpi-a.dts  | 67 
 arch/arm/boot/dts/bcm2835-rpi-b-plus.dts | 66 +++
 arch/arm/boot/dts/bcm2835-rpi-b-rev2.dts | 66 +++
 arch/arm/boot/dts/bcm2835-rpi-b.dts  | 67 


Aren't the A and B rev 2 pinouts the same. If so, why duplicate the 
content between the files instead of creating an inclue file? Same for 
A+, B+, Pi 2, and Pi 3. Shouldn't this patch update the Pi 2 and Pi 3 
DTs too?



diff --git a/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts 
b/arch/arm/boot/dts/bcm2835-rpi-a-plus.dts



  {
+   /*
+* This is based on the unreleased schematic for the Model A+.
+*
+* Legend:
+* "NC" = not connected (no rail from the SoC)
+* "FOO" = GPIO line named "FOO" on the schematic
+* "FOO_N" = GPIO line named "FOO" on schematic, active low
+*/
+   gpio-line-names = "SDA0",
+ "SCL0",



diff --git a/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts 
b/arch/arm/boot/dts/bcm2835-rpi-b-plus.dts



  {
+   /*
+* Taken from Raspberry-Pi-B-Plus-V1.2-Schematics.pdf
+* RPI-BPLUS sheet 1
+*
+* Legend:
+* "NC" = not connected (no rail from the SoC)
+* "FOO" = GPIO line named "FOO" on the schematic
+* "FOO_N" = GPIO line named "FOO" on schematic, active low
+*/
+   gpio-line-names = "ID_SD",
+ "ID_SC",


I think the whole point of naming GPIOs is to give users the same 
experience across the different boards where the same semantics exist in 
HW. Both the A+ and B+ use GPIO0/1 (a/k/a ID_SD/ID_SC a/k/a SDA0/SCL0) 
for the same semantic purpose and are exposed in the same externally 
visible way (same pins on the expansion header); the board ID EEPROM. 
Therefore I assert the names of these GPIOs should be identical on all 
boards that use them for that purpose, to allow SW (or human knowledge) 
portability between the boards.



+ "GPIO17",


This pin is known as GPIO_GEN0 on the expansion header. Given the 
expansion header is all end-users likely care about, and other pins 
(e.g. SPI_CE1_N) are named after the expansion header, shouldn't this 
patch use the GPIO expansion header naming for all pins that are routed 
to that header?

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

2016-11-05 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:   bc33b0ca11e3df46a4fa7639ba488c9d4911
commit: 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e MIPS: VDSO: Fix build error 
with binutils 2.24 and earlier
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 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

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

2016-11-05 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:   bc33b0ca11e3df46a4fa7639ba488c9d4911
commit: 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e MIPS: VDSO: Fix build error 
with binutils 2.24 and earlier
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 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 v2 1/3] thinkpad_acpi: Move tablet detection into separate function

2016-11-05 Thread Henrique de Moraes Holschuh

On Sat, 05 Nov 2016, Darren Hart wrote:
> On Mon, Oct 31, 2016 at 07:56:40PM -0400, Lyude wrote:
> > Suggested by Daniel Martin 
> > 
> > Lenovo's having a bit of fun randomly changing what hotkey events and
> > acpi handles they use for reporting tablet mode, so unfortunately this
> > means we're definitely going to need to probe for multiple types of
> > tablet mode support. Since the hotkey_init() is already a lot larger
> > then it should be, let's split up this detection into it's own function
> > to make things a little easier to read.
> > 
> > As well, since we're going to have multiple types of tablet modes, make
> > hotkey_tablet into an enum so we can also use it to indicate the type of
> > tablet mode reporting the machine supports.
> > 
> > Changes since v1:
> > - Don't use bool for in_tablet_mode (fixes complaints from kbuild test
> >   robot)
> > 
> 
> This series doesn't apply cleanly now (simple fuzz).
> 
> Once we hear back from Henrique on his enum preference and thoughts on the
> refactoring (which looks reasonable to me), please resubmit this series and

I don't mind the enum usage, as long as it is correct.  As you said, the
driver is not consistent there.  I also don't mind the refactoring.

-- 
  Henrique Holschuh

Re: [PATCH v2 1/3] thinkpad_acpi: Move tablet detection into separate function

2016-11-05 Thread Henrique de Moraes Holschuh

On Sat, 05 Nov 2016, Darren Hart wrote:
> On Mon, Oct 31, 2016 at 07:56:40PM -0400, Lyude wrote:
> > Suggested by Daniel Martin 
> > 
> > Lenovo's having a bit of fun randomly changing what hotkey events and
> > acpi handles they use for reporting tablet mode, so unfortunately this
> > means we're definitely going to need to probe for multiple types of
> > tablet mode support. Since the hotkey_init() is already a lot larger
> > then it should be, let's split up this detection into it's own function
> > to make things a little easier to read.
> > 
> > As well, since we're going to have multiple types of tablet modes, make
> > hotkey_tablet into an enum so we can also use it to indicate the type of
> > tablet mode reporting the machine supports.
> > 
> > Changes since v1:
> > - Don't use bool for in_tablet_mode (fixes complaints from kbuild test
> >   robot)
> > 
> 
> This series doesn't apply cleanly now (simple fuzz).
> 
> Once we hear back from Henrique on his enum preference and thoughts on the
> refactoring (which looks reasonable to me), please resubmit this series and

I don't mind the enum usage, as long as it is correct.  As you said, the
driver is not consistent there.  I also don't mind the refactoring.

-- 
  Henrique Holschuh

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

2016-11-05 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:   bc33b0ca11e3df46a4fa7639ba488c9d4911
commit: ebb5e78cc63417a35254a791de66e1cc84f963cc MIPS: Initial implementation 
of a VDSO
date:   12 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-11-05 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:   bc33b0ca11e3df46a4fa7639ba488c9d4911
commit: ebb5e78cc63417a35254a791de66e1cc84f963cc MIPS: Initial implementation 
of a VDSO
date:   12 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: [PATCH] perf thread: cleanup with list_first_entry_or_null()

2016-11-05 Thread Masahiro Yamada

Hi maintainers,

Does this patch look good?

2016-09-13 3:29 GMT+09:00 Masahiro Yamada :
> The combo of list_empty() check and return list_first_entry()
> can be replaced with list_first_entry_or_null().
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  tools/perf/util/thread.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
> index 8b10a55..ea951df 100644
> --- a/tools/perf/util/thread.c
> +++ b/tools/perf/util/thread.c
> @@ -107,10 +107,7 @@ void thread__put(struct thread *thread)
>
>  struct comm *thread__comm(const struct thread *thread)
>  {
> -   if (list_empty(>comm_list))
> -   return NULL;
> -
> -   return list_first_entry(>comm_list, struct comm, list);
> +   return list_first_entry_or_null(>comm_list, struct comm, 
> list);
>  }
>
>  struct comm *thread__exec_comm(const struct thread *thread)
> --
> 1.9.1
>



-- 
Best Regards
Masahiro Yamada

Re: [PATCH] perf thread: cleanup with list_first_entry_or_null()

2016-11-05 Thread Masahiro Yamada

Hi maintainers,

Does this patch look good?

2016-09-13 3:29 GMT+09:00 Masahiro Yamada :
> The combo of list_empty() check and return list_first_entry()
> can be replaced with list_first_entry_or_null().
>
> Signed-off-by: Masahiro Yamada 
> ---
>
>  tools/perf/util/thread.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/tools/perf/util/thread.c b/tools/perf/util/thread.c
> index 8b10a55..ea951df 100644
> --- a/tools/perf/util/thread.c
> +++ b/tools/perf/util/thread.c
> @@ -107,10 +107,7 @@ void thread__put(struct thread *thread)
>
>  struct comm *thread__comm(const struct thread *thread)
>  {
> -   if (list_empty(>comm_list))
> -   return NULL;
> -
> -   return list_first_entry(>comm_list, struct comm, list);
> +   return list_first_entry_or_null(>comm_list, struct comm, 
> list);
>  }
>
>  struct comm *thread__exec_comm(const struct thread *thread)
> --
> 1.9.1
>



-- 
Best Regards
Masahiro Yamada

Re: [PATCH v2] platform/x86/asus-nb-wmi.c: Add X45U quirk

2016-11-05 Thread Marcos Paulo de Souza

Hi Darren,

On Sat, Nov 05, 2016 at 11:24:04AM -0700, Darren Hart wrote:
> On Mon, Oct 31, 2016 at 11:56:10PM -0200, Marcos Paulo de Souza wrote:
> > Without this patch, the Asus X45U wireless card can't be turned
> > on (hard-blocked), but after a suspend/resume it just starts working.
> > 
> > Following this bug report[1], there are other cases like this one, but
> > this Asus is the only model that I can test.
> > 
> > [1] https://ubuntuforums.org/showthread.php?t=2181558
> > 
> > Signed-off-by: Marcos Paulo de Souza 
> > Cc: 
> > 
> > ---
> > This patch applies smoothly in 4.8.6 and 4.4.29. I hope now I followed
> > the instructions correctly.
> 
> Hi Marcos,
> 
> You'll find exact steps in the stable_kernel_rules.txt document regarding how 
> to
> annotate the commit message with Cc lines indicating to which versions this
> patch should be applied.
> 
> If, for example, you have verified that this patch is relevant only to 4.4 and
> forward, you would include:
> 
> Cc:  # 4.4.x-
> 
> But this should mean that the patch is explicitly broken or otherwise
> inappropriate for 4.3 and earlier.

Yes, I have misread the documentation. I could apply the patch as is just in
the versions 4.8.6 and 4.4.29, but maybe I could rework te patch earlier 
versions.

But, aside from stable tree, do you agree with this change, since it fixes the
wireless problem in this laptop?

Thanks,

> 
> Thanks,
> 
> -- 
> Darren Hart
> Intel Open Source Technology Center

Re: [PATCH v2] platform/x86/asus-nb-wmi.c: Add X45U quirk

2016-11-05 Thread Marcos Paulo de Souza

Hi Darren,

On Sat, Nov 05, 2016 at 11:24:04AM -0700, Darren Hart wrote:
> On Mon, Oct 31, 2016 at 11:56:10PM -0200, Marcos Paulo de Souza wrote:
> > Without this patch, the Asus X45U wireless card can't be turned
> > on (hard-blocked), but after a suspend/resume it just starts working.
> > 
> > Following this bug report[1], there are other cases like this one, but
> > this Asus is the only model that I can test.
> > 
> > [1] https://ubuntuforums.org/showthread.php?t=2181558
> > 
> > Signed-off-by: Marcos Paulo de Souza 
> > Cc: 
> > 
> > ---
> > This patch applies smoothly in 4.8.6 and 4.4.29. I hope now I followed
> > the instructions correctly.
> 
> Hi Marcos,
> 
> You'll find exact steps in the stable_kernel_rules.txt document regarding how 
> to
> annotate the commit message with Cc lines indicating to which versions this
> patch should be applied.
> 
> If, for example, you have verified that this patch is relevant only to 4.4 and
> forward, you would include:
> 
> Cc:  # 4.4.x-
> 
> But this should mean that the patch is explicitly broken or otherwise
> inappropriate for 4.3 and earlier.

Yes, I have misread the documentation. I could apply the patch as is just in
the versions 4.8.6 and 4.4.29, but maybe I could rework te patch earlier 
versions.

But, aside from stable tree, do you agree with this change, since it fixes the
wireless problem in this laptop?

Thanks,

> 
> Thanks,
> 
> -- 
> Darren Hart
> Intel Open Source Technology Center

fs/xfs/xfs_ondisk.h:96:2: error: call to '__compiletime_assert_96' declared with attribute error: XFS: sizeof(xfs_dir2_sf_entry_t) is wrong, expected 3

2016-11-05 Thread kbuild test robot

Hi Dave,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   bc33b0ca11e3df46a4fa7639ba488c9d4911
commit: ab9d1e4f7b0217948a3b35a64178602ab30ff45d Merge branch 
'xfs-misc-fixes-4.6-3' into for-next
date:   8 months ago
config: openrisc-allmodconfig (attached as .config)
compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1
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 ab9d1e4f7b0217948a3b35a64178602ab30ff45d
# save the attached .config to linux build tree
make.cross ARCH=openrisc 

All errors (new ones prefixed by >>):

   In file included from fs/xfs/xfs_super.c:48:0:
   In function 'xfs_check_ondisk_structs',
   inlined from 'init_xfs_fs' at fs/xfs/xfs_super.c:1862:26:
   fs/xfs/xfs_ondisk.h:86:2: error: call to '__compiletime_assert_86' declared 
with attribute error: XFS: sizeof(xfs_dir2_data_unused_t) is wrong, expected 6
>> fs/xfs/xfs_ondisk.h:96:2: error: call to '__compiletime_assert_96' declared 
>> with attribute error: XFS: sizeof(xfs_dir2_sf_entry_t) is wrong, expected 3
   fs/xfs/xfs_ondisk.h:97:2: error: call to '__compiletime_assert_97' declared 
with attribute error: XFS: sizeof(xfs_dir2_sf_hdr_t) is wrong, expected 10

vim +/__compiletime_assert_96 +96 fs/xfs/xfs_ondisk.h

30cbc591 Darrick J. Wong 2016-03-09  80 
XFS_CHECK_STRUCT_SIZE(xfs_da_blkinfo_t, 12);
30cbc591 Darrick J. Wong 2016-03-09  81 
XFS_CHECK_STRUCT_SIZE(xfs_da_intnode_t, 16);
30cbc591 Darrick J. Wong 2016-03-09  82 
XFS_CHECK_STRUCT_SIZE(xfs_da_node_entry_t,  8);
30cbc591 Darrick J. Wong 2016-03-09  83 
XFS_CHECK_STRUCT_SIZE(xfs_da_node_hdr_t,16);
30cbc591 Darrick J. Wong 2016-03-09  84 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_data_free_t, 4);
30cbc591 Darrick J. Wong 2016-03-09  85 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_data_hdr_t,  16);
30cbc591 Darrick J. Wong 2016-03-09 @86 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_data_unused_t,   6);
30cbc591 Darrick J. Wong 2016-03-09  87 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_free_hdr_t,  16);
30cbc591 Darrick J. Wong 2016-03-09  88 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_free_t,  16);
30cbc591 Darrick J. Wong 2016-03-09  89 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_ino4_t,  4);
30cbc591 Darrick J. Wong 2016-03-09  90 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_ino8_t,  8);
30cbc591 Darrick J. Wong 2016-03-09  91 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_inou_t,  8);
30cbc591 Darrick J. Wong 2016-03-09  92 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_entry_t,8);
30cbc591 Darrick J. Wong 2016-03-09  93 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_hdr_t,  16);
30cbc591 Darrick J. Wong 2016-03-09  94 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_t,  16);
30cbc591 Darrick J. Wong 2016-03-09  95 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_tail_t, 4);
30cbc591 Darrick J. Wong 2016-03-09 @96 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_sf_entry_t,  3);
30cbc591 Darrick J. Wong 2016-03-09  97 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_sf_hdr_t,10);
30cbc591 Darrick J. Wong 2016-03-09  98 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_sf_off_t,2);
30cbc591 Darrick J. Wong 2016-03-09  99  

:: The code at line 96 was first introduced by commit
:: 30cbc591c34e680e8b5d6d675ea49effe42a0570 xfs: check sizes of XFS on-disk 
structures at compile time

:: TO: Darrick J. Wong 
:: CC: Dave Chinner 

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


.config.gz
Description: application/gzip

fs/xfs/xfs_ondisk.h:96:2: error: call to '__compiletime_assert_96' declared with attribute error: XFS: sizeof(xfs_dir2_sf_entry_t) is wrong, expected 3

2016-11-05 Thread kbuild test robot

Hi Dave,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   bc33b0ca11e3df46a4fa7639ba488c9d4911
commit: ab9d1e4f7b0217948a3b35a64178602ab30ff45d Merge branch 
'xfs-misc-fixes-4.6-3' into for-next
date:   8 months ago
config: openrisc-allmodconfig (attached as .config)
compiler: or32-linux-gcc (GCC) 4.5.1-or32-1.0rc1
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 ab9d1e4f7b0217948a3b35a64178602ab30ff45d
# save the attached .config to linux build tree
make.cross ARCH=openrisc 

All errors (new ones prefixed by >>):

   In file included from fs/xfs/xfs_super.c:48:0:
   In function 'xfs_check_ondisk_structs',
   inlined from 'init_xfs_fs' at fs/xfs/xfs_super.c:1862:26:
   fs/xfs/xfs_ondisk.h:86:2: error: call to '__compiletime_assert_86' declared 
with attribute error: XFS: sizeof(xfs_dir2_data_unused_t) is wrong, expected 6
>> fs/xfs/xfs_ondisk.h:96:2: error: call to '__compiletime_assert_96' declared 
>> with attribute error: XFS: sizeof(xfs_dir2_sf_entry_t) is wrong, expected 3
   fs/xfs/xfs_ondisk.h:97:2: error: call to '__compiletime_assert_97' declared 
with attribute error: XFS: sizeof(xfs_dir2_sf_hdr_t) is wrong, expected 10

vim +/__compiletime_assert_96 +96 fs/xfs/xfs_ondisk.h

30cbc591 Darrick J. Wong 2016-03-09  80 
XFS_CHECK_STRUCT_SIZE(xfs_da_blkinfo_t, 12);
30cbc591 Darrick J. Wong 2016-03-09  81 
XFS_CHECK_STRUCT_SIZE(xfs_da_intnode_t, 16);
30cbc591 Darrick J. Wong 2016-03-09  82 
XFS_CHECK_STRUCT_SIZE(xfs_da_node_entry_t,  8);
30cbc591 Darrick J. Wong 2016-03-09  83 
XFS_CHECK_STRUCT_SIZE(xfs_da_node_hdr_t,16);
30cbc591 Darrick J. Wong 2016-03-09  84 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_data_free_t, 4);
30cbc591 Darrick J. Wong 2016-03-09  85 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_data_hdr_t,  16);
30cbc591 Darrick J. Wong 2016-03-09 @86 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_data_unused_t,   6);
30cbc591 Darrick J. Wong 2016-03-09  87 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_free_hdr_t,  16);
30cbc591 Darrick J. Wong 2016-03-09  88 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_free_t,  16);
30cbc591 Darrick J. Wong 2016-03-09  89 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_ino4_t,  4);
30cbc591 Darrick J. Wong 2016-03-09  90 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_ino8_t,  8);
30cbc591 Darrick J. Wong 2016-03-09  91 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_inou_t,  8);
30cbc591 Darrick J. Wong 2016-03-09  92 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_entry_t,8);
30cbc591 Darrick J. Wong 2016-03-09  93 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_hdr_t,  16);
30cbc591 Darrick J. Wong 2016-03-09  94 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_t,  16);
30cbc591 Darrick J. Wong 2016-03-09  95 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_leaf_tail_t, 4);
30cbc591 Darrick J. Wong 2016-03-09 @96 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_sf_entry_t,  3);
30cbc591 Darrick J. Wong 2016-03-09  97 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_sf_hdr_t,10);
30cbc591 Darrick J. Wong 2016-03-09  98 
XFS_CHECK_STRUCT_SIZE(xfs_dir2_sf_off_t,2);
30cbc591 Darrick J. Wong 2016-03-09  99  

:: The code at line 96 was first introduced by commit
:: 30cbc591c34e680e8b5d6d675ea49effe42a0570 xfs: check sizes of XFS on-disk 
structures at compile time

:: TO: Darrick J. Wong 
:: CC: Dave Chinner 

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


.config.gz
Description: application/gzip

Re: [PATCH 13/22] mtd: nand: lpc32xx: return error code of nand_scan_ident/tail() on error

2016-11-05 Thread Vladimir Zapolskiy


On 11/04/2016 12:43 PM, Masahiro Yamada wrote:

The nand_scan_ident/tail() returns an appropriate error value when
it fails.  Use it instead of the fixed error code -ENXIO.

Signed-off-by: Masahiro Yamada 
---


Acked-by: Vladimir Zapolskiy 

Thank you for the change.

--
With best wishes,
Vladimir

Re: [PATCH 13/22] mtd: nand: lpc32xx: return error code of nand_scan_ident/tail() on error

2016-11-05 Thread Vladimir Zapolskiy


On 11/04/2016 12:43 PM, Masahiro Yamada wrote:

The nand_scan_ident/tail() returns an appropriate error value when
it fails.  Use it instead of the fixed error code -ENXIO.

Signed-off-by: Masahiro Yamada 
---


Acked-by: Vladimir Zapolskiy 

Thank you for the change.

--
With best wishes,
Vladimir

arch/ia64/kernel/fsys.S:67: Error: Operand 3 of `add' should be a general register r0-r3

2016-11-05 Thread kbuild test robot

Hi Will,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   ffbcbfca846ed117e3d4009acfbf1e1590c56b2f
commit: da48d094ce5d7c7dcdad9011648a81c42fd1c2ef Kconfig: remove 
HAVE_LATENCYTOP_SUPPORT
date:   10 months ago
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
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 da48d094ce5d7c7dcdad9011648a81c42fd1c2ef
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   arch/ia64/kernel/fsys.S: Assembler messages:
>> arch/ia64/kernel/fsys.S:67: Error: Operand 3 of `add' should be a general 
>> register r0-r3
   arch/ia64/kernel/fsys.S:97: Error: Operand 3 of `add' should be a general 
register r0-r3
   arch/ia64/kernel/fsys.S:193: Error: Operand 3 of `add' should be a general 
register r0-r3
   arch/ia64/kernel/fsys.S:336: Error: Operand 3 of `add' should be a general 
register r0-r3
   arch/ia64/kernel/fsys.S:338: Error: Operand 3 of `add' should be a general 
register r0-r3

vim +67 arch/ia64/kernel/fsys.S

^1da177e Linus Torvalds  2005-04-16  51  ENTRY(fsys_ni_syscall)
^1da177e Linus Torvalds  2005-04-16  52 .prologue
^1da177e Linus Torvalds  2005-04-16  53 .altrp b6
^1da177e Linus Torvalds  2005-04-16  54 .body
^1da177e Linus Torvalds  2005-04-16  55 mov r8=ENOSYS
^1da177e Linus Torvalds  2005-04-16  56 mov r10=-1
^1da177e Linus Torvalds  2005-04-16  57 FSYS_RETURN
^1da177e Linus Torvalds  2005-04-16  58  END(fsys_ni_syscall)
^1da177e Linus Torvalds  2005-04-16  59  
^1da177e Linus Torvalds  2005-04-16  60  ENTRY(fsys_getpid)
^1da177e Linus Torvalds  2005-04-16  61 .prologue
^1da177e Linus Torvalds  2005-04-16  62 .altrp b6
^1da177e Linus Torvalds  2005-04-16  63 .body
96ded9da Pavel Emelyanov 2008-03-28  64 add 
r17=IA64_TASK_GROUP_LEADER_OFFSET,r16
96ded9da Pavel Emelyanov 2008-03-28  65 ;;
96ded9da Pavel Emelyanov 2008-03-28  66 ld8 r17=[r17]   
// r17 = current->group_leader
^1da177e Linus Torvalds  2005-04-16 @67 add 
r9=TI_FLAGS+IA64_TASK_SIZE,r16
^1da177e Linus Torvalds  2005-04-16  68 ;;
^1da177e Linus Torvalds  2005-04-16  69 ld4 r9=[r9]
96ded9da Pavel Emelyanov 2008-03-28  70 add 
r17=IA64_TASK_TGIDLINK_OFFSET,r17
^1da177e Linus Torvalds  2005-04-16  71 ;;
^1da177e Linus Torvalds  2005-04-16  72 and r9=TIF_ALLWORK_MASK,r9
96ded9da Pavel Emelyanov 2008-03-28  73 ld8 r17=[r17]   
// r17 = current->group_leader->pids[PIDTYPE_PID].pid
96ded9da Pavel Emelyanov 2008-03-28  74 ;;
96ded9da Pavel Emelyanov 2008-03-28  75 add r8=IA64_PID_LEVEL_OFFSET,r17

:: The code at line 67 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:: TO: Linus Torvalds 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip

arch/ia64/kernel/fsys.S:67: Error: Operand 3 of `add' should be a general register r0-r3

2016-11-05 Thread kbuild test robot

Hi Will,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   ffbcbfca846ed117e3d4009acfbf1e1590c56b2f
commit: da48d094ce5d7c7dcdad9011648a81c42fd1c2ef Kconfig: remove 
HAVE_LATENCYTOP_SUPPORT
date:   10 months ago
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
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 da48d094ce5d7c7dcdad9011648a81c42fd1c2ef
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   arch/ia64/kernel/fsys.S: Assembler messages:
>> arch/ia64/kernel/fsys.S:67: Error: Operand 3 of `add' should be a general 
>> register r0-r3
   arch/ia64/kernel/fsys.S:97: Error: Operand 3 of `add' should be a general 
register r0-r3
   arch/ia64/kernel/fsys.S:193: Error: Operand 3 of `add' should be a general 
register r0-r3
   arch/ia64/kernel/fsys.S:336: Error: Operand 3 of `add' should be a general 
register r0-r3
   arch/ia64/kernel/fsys.S:338: Error: Operand 3 of `add' should be a general 
register r0-r3

vim +67 arch/ia64/kernel/fsys.S

^1da177e Linus Torvalds  2005-04-16  51  ENTRY(fsys_ni_syscall)
^1da177e Linus Torvalds  2005-04-16  52 .prologue
^1da177e Linus Torvalds  2005-04-16  53 .altrp b6
^1da177e Linus Torvalds  2005-04-16  54 .body
^1da177e Linus Torvalds  2005-04-16  55 mov r8=ENOSYS
^1da177e Linus Torvalds  2005-04-16  56 mov r10=-1
^1da177e Linus Torvalds  2005-04-16  57 FSYS_RETURN
^1da177e Linus Torvalds  2005-04-16  58  END(fsys_ni_syscall)
^1da177e Linus Torvalds  2005-04-16  59  
^1da177e Linus Torvalds  2005-04-16  60  ENTRY(fsys_getpid)
^1da177e Linus Torvalds  2005-04-16  61 .prologue
^1da177e Linus Torvalds  2005-04-16  62 .altrp b6
^1da177e Linus Torvalds  2005-04-16  63 .body
96ded9da Pavel Emelyanov 2008-03-28  64 add 
r17=IA64_TASK_GROUP_LEADER_OFFSET,r16
96ded9da Pavel Emelyanov 2008-03-28  65 ;;
96ded9da Pavel Emelyanov 2008-03-28  66 ld8 r17=[r17]   
// r17 = current->group_leader
^1da177e Linus Torvalds  2005-04-16 @67 add 
r9=TI_FLAGS+IA64_TASK_SIZE,r16
^1da177e Linus Torvalds  2005-04-16  68 ;;
^1da177e Linus Torvalds  2005-04-16  69 ld4 r9=[r9]
96ded9da Pavel Emelyanov 2008-03-28  70 add 
r17=IA64_TASK_TGIDLINK_OFFSET,r17
^1da177e Linus Torvalds  2005-04-16  71 ;;
^1da177e Linus Torvalds  2005-04-16  72 and r9=TIF_ALLWORK_MASK,r9
96ded9da Pavel Emelyanov 2008-03-28  73 ld8 r17=[r17]   
// r17 = current->group_leader->pids[PIDTYPE_PID].pid
96ded9da Pavel Emelyanov 2008-03-28  74 ;;
96ded9da Pavel Emelyanov 2008-03-28  75 add r8=IA64_PID_LEVEL_OFFSET,r17

:: The code at line 67 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:: TO: Linus Torvalds 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip

cc1: error: '-march=r3900' requires '-mfp32'

2016-11-05 Thread kbuild test robot

Hi James,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   fb415f222c26d0d1fa19615af1d102bf5f5b3ca2
commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of 
vdso.lds
date:   4 weeks ago
config: mips-jmr3927_defconfig (attached as .config)
compiler: mips-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 034827c727f7f3946a18355b63995b402c226c82
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> cc1: error: '-march=r3900' requires '-mfp32'

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


.config.gz
Description: application/gzip

cc1: error: '-march=r3900' requires '-mfp32'

2016-11-05 Thread kbuild test robot

Hi James,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   fb415f222c26d0d1fa19615af1d102bf5f5b3ca2
commit: 034827c727f7f3946a18355b63995b402c226c82 MIPS: Fix -mabi=64 build of 
vdso.lds
date:   4 weeks ago
config: mips-jmr3927_defconfig (attached as .config)
compiler: mips-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 034827c727f7f3946a18355b63995b402c226c82
# save the attached .config to linux build tree
make.cross ARCH=mips 

All errors (new ones prefixed by >>):

>> cc1: error: '-march=r3900' requires '-mfp32'

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


.config.gz
Description: application/gzip

arch/ia64/kernel/entry.S:621: Error: Operand 2 of `adds' should be a 14-bit integer (-8192-8191)

2016-11-05 Thread kbuild test robot

Hi Will,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   fb415f222c26d0d1fa19615af1d102bf5f5b3ca2
commit: da48d094ce5d7c7dcdad9011648a81c42fd1c2ef Kconfig: remove 
HAVE_LATENCYTOP_SUPPORT
date:   10 months ago
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
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 da48d094ce5d7c7dcdad9011648a81c42fd1c2ef
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   arch/ia64/kernel/entry.S: Assembler messages:
>> arch/ia64/kernel/entry.S:621: Error: Operand 2 of `adds' should be a 14-bit 
>> integer (-8192-8191)
   arch/ia64/kernel/entry.S:728: Error: Operand 2 of `adds' should be a 14-bit 
integer (-8192-8191)
   arch/ia64/kernel/entry.S:859: Error: Operand 2 of `adds' should be a 14-bit 
integer (-8192-8191)
--
   arch/ia64/kernel/ivt.S: Assembler messages:
>> arch/ia64/kernel/ivt.S:759: Error: Operand 3 of `add' should be a general 
>> register r0-r3

vim +621 arch/ia64/kernel/entry.S

^1da177e Linus Torvalds 2005-04-16  605 PT_REGS_UNWIND_INFO(0)
^1da177e Linus Torvalds 2005-04-16  606  {  /*
^1da177e Linus Torvalds 2005-04-16  607  * Some versions of gas 
generate bad unwind info if the first instruction of a
^1da177e Linus Torvalds 2005-04-16  608  * procedure doesn't go into 
the first slot of a bundle.  This is a workaround.
^1da177e Linus Torvalds 2005-04-16  609  */
^1da177e Linus Torvalds 2005-04-16  610 nop.m 0
^1da177e Linus Torvalds 2005-04-16  611 nop.i 0
^1da177e Linus Torvalds 2005-04-16  612 /*
^1da177e Linus Torvalds 2005-04-16  613  * We need to call 
schedule_tail() to complete the scheduling process.
^1da177e Linus Torvalds 2005-04-16  614  * Called by ia64_switch_to() 
after do_fork()->copy_thread().  r8 contains the
^1da177e Linus Torvalds 2005-04-16  615  * address of the previously 
executing task.
^1da177e Linus Torvalds 2005-04-16  616  */
^1da177e Linus Torvalds 2005-04-16  617 br.call.sptk.many 
rp=ia64_invoke_schedule_tail
^1da177e Linus Torvalds 2005-04-16  618  }
^1da177e Linus Torvalds 2005-04-16  619  .ret8:
54d496c3 Al Viro2012-10-14  620  (pKStk)br.call.sptk.many 
rp=call_payload
^1da177e Linus Torvalds 2005-04-16 @621 adds 
r2=TI_FLAGS+IA64_TASK_SIZE,r13
^1da177e Linus Torvalds 2005-04-16  622 ;;
^1da177e Linus Torvalds 2005-04-16  623 ld4 r2=[r2]
^1da177e Linus Torvalds 2005-04-16  624 ;;
^1da177e Linus Torvalds 2005-04-16  625 mov r8=0
^1da177e Linus Torvalds 2005-04-16  626 and 
r2=_TIF_SYSCALL_TRACEAUDIT,r2
^1da177e Linus Torvalds 2005-04-16  627 ;;
^1da177e Linus Torvalds 2005-04-16  628 cmp.ne p6,p0=r2,r0
^1da177e Linus Torvalds 2005-04-16  629  (p6)   br.cond.spnt 
.strace_check_retval

:: The code at line 621 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:: TO: Linus Torvalds 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip

arch/ia64/kernel/entry.S:621: Error: Operand 2 of `adds' should be a 14-bit integer (-8192-8191)

2016-11-05 Thread kbuild test robot

Hi Will,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   fb415f222c26d0d1fa19615af1d102bf5f5b3ca2
commit: da48d094ce5d7c7dcdad9011648a81c42fd1c2ef Kconfig: remove 
HAVE_LATENCYTOP_SUPPORT
date:   10 months ago
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
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 da48d094ce5d7c7dcdad9011648a81c42fd1c2ef
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   arch/ia64/kernel/entry.S: Assembler messages:
>> arch/ia64/kernel/entry.S:621: Error: Operand 2 of `adds' should be a 14-bit 
>> integer (-8192-8191)
   arch/ia64/kernel/entry.S:728: Error: Operand 2 of `adds' should be a 14-bit 
integer (-8192-8191)
   arch/ia64/kernel/entry.S:859: Error: Operand 2 of `adds' should be a 14-bit 
integer (-8192-8191)
--
   arch/ia64/kernel/ivt.S: Assembler messages:
>> arch/ia64/kernel/ivt.S:759: Error: Operand 3 of `add' should be a general 
>> register r0-r3

vim +621 arch/ia64/kernel/entry.S

^1da177e Linus Torvalds 2005-04-16  605 PT_REGS_UNWIND_INFO(0)
^1da177e Linus Torvalds 2005-04-16  606  {  /*
^1da177e Linus Torvalds 2005-04-16  607  * Some versions of gas 
generate bad unwind info if the first instruction of a
^1da177e Linus Torvalds 2005-04-16  608  * procedure doesn't go into 
the first slot of a bundle.  This is a workaround.
^1da177e Linus Torvalds 2005-04-16  609  */
^1da177e Linus Torvalds 2005-04-16  610 nop.m 0
^1da177e Linus Torvalds 2005-04-16  611 nop.i 0
^1da177e Linus Torvalds 2005-04-16  612 /*
^1da177e Linus Torvalds 2005-04-16  613  * We need to call 
schedule_tail() to complete the scheduling process.
^1da177e Linus Torvalds 2005-04-16  614  * Called by ia64_switch_to() 
after do_fork()->copy_thread().  r8 contains the
^1da177e Linus Torvalds 2005-04-16  615  * address of the previously 
executing task.
^1da177e Linus Torvalds 2005-04-16  616  */
^1da177e Linus Torvalds 2005-04-16  617 br.call.sptk.many 
rp=ia64_invoke_schedule_tail
^1da177e Linus Torvalds 2005-04-16  618  }
^1da177e Linus Torvalds 2005-04-16  619  .ret8:
54d496c3 Al Viro2012-10-14  620  (pKStk)br.call.sptk.many 
rp=call_payload
^1da177e Linus Torvalds 2005-04-16 @621 adds 
r2=TI_FLAGS+IA64_TASK_SIZE,r13
^1da177e Linus Torvalds 2005-04-16  622 ;;
^1da177e Linus Torvalds 2005-04-16  623 ld4 r2=[r2]
^1da177e Linus Torvalds 2005-04-16  624 ;;
^1da177e Linus Torvalds 2005-04-16  625 mov r8=0
^1da177e Linus Torvalds 2005-04-16  626 and 
r2=_TIF_SYSCALL_TRACEAUDIT,r2
^1da177e Linus Torvalds 2005-04-16  627 ;;
^1da177e Linus Torvalds 2005-04-16  628 cmp.ne p6,p0=r2,r0
^1da177e Linus Torvalds 2005-04-16  629  (p6)   br.cond.spnt 
.strace_check_retval

:: The code at line 621 was first introduced by commit
:: 1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 Linux-2.6.12-rc2

:: TO: Linus Torvalds 
:: CC: Linus Torvalds 

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


.config.gz
Description: application/gzip

drivers/gpu/drm/i915/i915_gem_gtt.c:2367: error: 'gtt_entry' may be used uninitialized in this function

2016-11-05 Thread kbuild test robot

Hi Dave,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   ffbcbfca846ed117e3d4009acfbf1e1590c56b2f
commit: 85d1225ec066b2ef46fbd0ed1bae78ae1f3e6c91 drm/i915: Introduce & use new 
lightweight SGL iterators
date:   6 months ago
config: x86_64-randconfig-s0-11060725 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
git checkout 85d1225ec066b2ef46fbd0ed1bae78ae1f3e6c91
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All errors (new ones prefixed by >>):

   cc1: warnings being treated as errors
   drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen8_ggtt_insert_entries':
>> drivers/gpu/drm/i915/i915_gem_gtt.c:2367: error: 'gtt_entry' may be used 
>> uninitialized in this function
   drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen6_ggtt_insert_entries':
   drivers/gpu/drm/i915/i915_gem_gtt.c:2442: error: 'gtt_entry' may be used 
uninitialized in this function

vim +/gtt_entry +2367 drivers/gpu/drm/i915/i915_gem_gtt.c

  2361   enum i915_cache_level level, u32 
unused)
  2362  {
  2363  struct drm_i915_private *dev_priv = to_i915(vm->dev);
  2364  struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
  2365  struct sgt_iter sgt_iter;
  2366  gen8_pte_t __iomem *gtt_entries;
> 2367  gen8_pte_t gtt_entry;
  2368  dma_addr_t addr;
  2369  int rpm_atomic_seq;
  2370  int i = 0;

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


.config.gz
Description: application/gzip

drivers/gpu/drm/i915/i915_gem_gtt.c:2367: error: 'gtt_entry' may be used uninitialized in this function

2016-11-05 Thread kbuild test robot

Hi Dave,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   ffbcbfca846ed117e3d4009acfbf1e1590c56b2f
commit: 85d1225ec066b2ef46fbd0ed1bae78ae1f3e6c91 drm/i915: Introduce & use new 
lightweight SGL iterators
date:   6 months ago
config: x86_64-randconfig-s0-11060725 (attached as .config)
compiler: gcc-4.4 (Debian 4.4.7-8) 4.4.7
reproduce:
git checkout 85d1225ec066b2ef46fbd0ed1bae78ae1f3e6c91
# save the attached .config to linux build tree
make ARCH=x86_64 

Note: it may well be a FALSE warning. FWIW you are at least aware of it now.
http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings

All errors (new ones prefixed by >>):

   cc1: warnings being treated as errors
   drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen8_ggtt_insert_entries':
>> drivers/gpu/drm/i915/i915_gem_gtt.c:2367: error: 'gtt_entry' may be used 
>> uninitialized in this function
   drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen6_ggtt_insert_entries':
   drivers/gpu/drm/i915/i915_gem_gtt.c:2442: error: 'gtt_entry' may be used 
uninitialized in this function

vim +/gtt_entry +2367 drivers/gpu/drm/i915/i915_gem_gtt.c

  2361   enum i915_cache_level level, u32 
unused)
  2362  {
  2363  struct drm_i915_private *dev_priv = to_i915(vm->dev);
  2364  struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
  2365  struct sgt_iter sgt_iter;
  2366  gen8_pte_t __iomem *gtt_entries;
> 2367  gen8_pte_t gtt_entry;
  2368  dma_addr_t addr;
  2369  int rpm_atomic_seq;
  2370  int i = 0;

---
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/gettimeofday.c:1:0: error: '-march=r3900' requires '-mfp32'

2016-11-05 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:   fb415f222c26d0d1fa19615af1d102bf5f5b3ca2
commit: 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e MIPS: VDSO: Fix build error 
with binutils 2.24 and earlier
date:   10 months ago
config: mips-jmr3927_defconfig (attached as .config)
compiler: mips-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=r3900' 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

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

2016-11-05 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:   fb415f222c26d0d1fa19615af1d102bf5f5b3ca2
commit: 398c7500a1f5f74e207bd2edca1b1721b3cc1f1e MIPS: VDSO: Fix build error 
with binutils 2.24 and earlier
date:   10 months ago
config: mips-jmr3927_defconfig (attached as .config)
compiler: mips-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=r3900' 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

Linux 4.9-rc4

2016-11-05 Thread Linus Torvalds

So it's once again a Saturday afternoon rather than Sunday, this time
because I felt this rc was already big enough.

Part of the size likely comes just from the fact that 4.9 is big and
has some fundamental changes: we have various fixups for drivers and
filesystems that triggered the whole "stack is now viirtually mapped,
and physical addresses don't work" issue.

But a larger part is simply that the first batch of networking fixes
came in just after the rc3 release, which accounts for a large portion
of this rc (about a third in bulk, slightly more in number of commits
- spread out both over network drivers and core networking).

So I'm not going to lie: this is not a small rc, and I'd have been
happier if it was. But it's not unreasonably large for this (big)
release either, so it's not like I'd start worrying.  I'm currently
still assuming that we'll end up with the usual seven release
candidates, assuming things start calming down. We'll see how that
goes as we get closer to a release.

Anyway, about half the changes are to drivers (networking being a
notable part of it, but also media and gpu, with misc other noise).
About a third is architecture updates (sparc and mips stand out, but
there's some x86 and parisc too, and some tiny arm updates). The
remainder is mostly core networking, with a smattering of other
changes (filesystems, tests). And Arnd continues to get his
uninitialized variable warning fixes in, so that we hopefully can
re-enable that warning for 4.9 final. Let's see.

The appended shortlog isn't tiny, but you can kind of scan it for an
overview of the kinds of things that happened the past week.

   Linus

---

Adam Williamson (1):
  ath6kl: add Dell OEM SDIO I/O for the Venue 8 Pro

Alex Deucher (10):
  drm/amdgpu/powerplay/smu7: fix static checker warning
  drm/amdgpu: drop atom scratch save/restore in gpu reset
  drm/amdgpu: move atom scratch register save/restore to common code
  drm/amdgpu/st: move ATC CG golden init from gfx to mc
  drm/amdgpu: explicitly set pg_flags for ST
  drm/amdgpu: cancel reset work on fini
  drm/amdgpu/dpm: flush any thermal work on fini
  drm/amdgpu/vce3: only enable 3 rings on new enough firmware (v2)
  drm/radeon/si_dpm: workaround for SI kickers
  drm/amdgpu/si_dpm: workaround for SI kickers

Alexander Alemayhu (1):
  Documentation/networking: update git urls to use https over http

Alexey Khoroshilov (1):
  vmxnet3: avoid assumption about invalid dma_pa in vmxnet3_set_mc()

Anders K. Pedersen (1):
  netfilter: nft_dynset: fix element timeout for HZ != 1000

Andy Lutomirski (1):
  fork: Add task stack refcounting sanity check and prevent
premature task stack freeing

Ard Biesheuvel (2):
  r8169: set coherent DMA mask as well as streaming DMA mask
  mac80211: move struct aead_req off the stack

Arnd Bergmann (10):
  drm/imx: hide an unused label
  netfilter: nf_tables: avoid uninitialized variable warning
  net: bcm63xx: avoid referencing uninitialized variable
  net/hyperv: avoid uninitialized variable
  rocker: fix maybe-uninitialized warning
  spi: fsl-espi: avoid processing uninitalized data on error
  kalmia: avoid potential uninitialized variable use
  flow_dissector: fix vlan tag handling
  mtd: mtk: avoid warning in mtk_ecc_encode
  IB/mlx4: avoid a -Wmaybe-uninitialize warning

Atish Patra (1):
  sparc64: Setup a scheduling domain for highest level cache.

Boris Brezillon (2):
  MAINTAINERS: add more people to the MTD maintainer team
  mtd: nand: Fix data interface configuration logic

Borislav Petkov (1):
  kvm/x86: Show WRMSR data is in hex

Brenden Blanco (1):
  net/mlx4_en: fixup xdp tx irq to match rx

Charles Keepax (1):
  regmap: Rename ret variable in regmap_read_poll_timeout

Ching Huang (1):
  scsi: arcmsr: Send SYNCHRONIZE_CACHE command to firmware

Chris Wilson (1):
  drm/i915: Use fence_write() from rpm resume

Chuck Lever (2):
  svcrdma: backchannel cannot share a page for send and rcv buffers
  nfsd: Fix general protection fault in release_lock_stateid()

Colin Ian King (2):
  cxgb4: fix memory leak of qe on error exit path
  net: bgmac: fix spelling mistake: "connecton" -> "connection"

Craig Gallek (1):
  inet: Fix missing return value in inet6_hash

Cyrille Pitchen (1):
  MAINTAINERS: add a maintainer for the SPI NOR subsystem

Dan Carpenter (7):
  afs: unmapping the wrong buffer
  stmmac: fix an error code in stmmac_ptp_register()
  netfilter: nf_tables: underflow in nft_parse_u32_check()
  netfilter: nft_exthdr: fix error handling in nft_exthdr_init()
  drm/imx: drm_dev_alloc() returns error pointers
  Btrfs: remove some no-op casts
  drm/i915: fix a read size argument

Daniel Borkmann (2):
  bpf, test: fix ld_abs + vlan push/pop stress test
  bpf: fix samples to add fake KBUILD_MODNAME

Daniel Jurgens

Linux 4.9-rc4

2016-11-05 Thread Linus Torvalds

So it's once again a Saturday afternoon rather than Sunday, this time
because I felt this rc was already big enough.

Part of the size likely comes just from the fact that 4.9 is big and
has some fundamental changes: we have various fixups for drivers and
filesystems that triggered the whole "stack is now viirtually mapped,
and physical addresses don't work" issue.

But a larger part is simply that the first batch of networking fixes
came in just after the rc3 release, which accounts for a large portion
of this rc (about a third in bulk, slightly more in number of commits
- spread out both over network drivers and core networking).

So I'm not going to lie: this is not a small rc, and I'd have been
happier if it was. But it's not unreasonably large for this (big)
release either, so it's not like I'd start worrying.  I'm currently
still assuming that we'll end up with the usual seven release
candidates, assuming things start calming down. We'll see how that
goes as we get closer to a release.

Anyway, about half the changes are to drivers (networking being a
notable part of it, but also media and gpu, with misc other noise).
About a third is architecture updates (sparc and mips stand out, but
there's some x86 and parisc too, and some tiny arm updates). The
remainder is mostly core networking, with a smattering of other
changes (filesystems, tests). And Arnd continues to get his
uninitialized variable warning fixes in, so that we hopefully can
re-enable that warning for 4.9 final. Let's see.

The appended shortlog isn't tiny, but you can kind of scan it for an
overview of the kinds of things that happened the past week.

   Linus

---

Adam Williamson (1):
  ath6kl: add Dell OEM SDIO I/O for the Venue 8 Pro

Alex Deucher (10):
  drm/amdgpu/powerplay/smu7: fix static checker warning
  drm/amdgpu: drop atom scratch save/restore in gpu reset
  drm/amdgpu: move atom scratch register save/restore to common code
  drm/amdgpu/st: move ATC CG golden init from gfx to mc
  drm/amdgpu: explicitly set pg_flags for ST
  drm/amdgpu: cancel reset work on fini
  drm/amdgpu/dpm: flush any thermal work on fini
  drm/amdgpu/vce3: only enable 3 rings on new enough firmware (v2)
  drm/radeon/si_dpm: workaround for SI kickers
  drm/amdgpu/si_dpm: workaround for SI kickers

Alexander Alemayhu (1):
  Documentation/networking: update git urls to use https over http

Alexey Khoroshilov (1):
  vmxnet3: avoid assumption about invalid dma_pa in vmxnet3_set_mc()

Anders K. Pedersen (1):
  netfilter: nft_dynset: fix element timeout for HZ != 1000

Andy Lutomirski (1):
  fork: Add task stack refcounting sanity check and prevent
premature task stack freeing

Ard Biesheuvel (2):
  r8169: set coherent DMA mask as well as streaming DMA mask
  mac80211: move struct aead_req off the stack

Arnd Bergmann (10):
  drm/imx: hide an unused label
  netfilter: nf_tables: avoid uninitialized variable warning
  net: bcm63xx: avoid referencing uninitialized variable
  net/hyperv: avoid uninitialized variable
  rocker: fix maybe-uninitialized warning
  spi: fsl-espi: avoid processing uninitalized data on error
  kalmia: avoid potential uninitialized variable use
  flow_dissector: fix vlan tag handling
  mtd: mtk: avoid warning in mtk_ecc_encode
  IB/mlx4: avoid a -Wmaybe-uninitialize warning

Atish Patra (1):
  sparc64: Setup a scheduling domain for highest level cache.

Boris Brezillon (2):
  MAINTAINERS: add more people to the MTD maintainer team
  mtd: nand: Fix data interface configuration logic

Borislav Petkov (1):
  kvm/x86: Show WRMSR data is in hex

Brenden Blanco (1):
  net/mlx4_en: fixup xdp tx irq to match rx

Charles Keepax (1):
  regmap: Rename ret variable in regmap_read_poll_timeout

Ching Huang (1):
  scsi: arcmsr: Send SYNCHRONIZE_CACHE command to firmware

Chris Wilson (1):
  drm/i915: Use fence_write() from rpm resume

Chuck Lever (2):
  svcrdma: backchannel cannot share a page for send and rcv buffers
  nfsd: Fix general protection fault in release_lock_stateid()

Colin Ian King (2):
  cxgb4: fix memory leak of qe on error exit path
  net: bgmac: fix spelling mistake: "connecton" -> "connection"

Craig Gallek (1):
  inet: Fix missing return value in inet6_hash

Cyrille Pitchen (1):
  MAINTAINERS: add a maintainer for the SPI NOR subsystem

Dan Carpenter (7):
  afs: unmapping the wrong buffer
  stmmac: fix an error code in stmmac_ptp_register()
  netfilter: nf_tables: underflow in nft_parse_u32_check()
  netfilter: nft_exthdr: fix error handling in nft_exthdr_init()
  drm/imx: drm_dev_alloc() returns error pointers
  Btrfs: remove some no-op casts
  drm/i915: fix a read size argument

Daniel Borkmann (2):
  bpf, test: fix ld_abs + vlan push/pop stress test
  bpf: fix samples to add fake KBUILD_MODNAME

Daniel Jurgens

Re: console issue since 3.6, console=ttyS1 hangs

2016-11-05 Thread Maciej W. Rozycki

On Fri, 4 Nov 2016, Peter Hurley wrote:

> > These bios screens do not have any mention of PNP settings.
> > I am getting output over the console (via ipmi) until the boot hangs.
> 
> Yeah, probably the device actually decodes io address access anyway,
> but in the disabled state probably has not routed IRQ.
> 
> I have no idea how to help you with the bios, sorry.

 I'd look out for serial port, Super-I/O or COM1 port (which is how PC-DOS 
named the device some 35 years ago) settings rather than anything to do 
with PNP.  Typically you'd be able to choose from a few classic combined 
I/O space address and IRQ assignments in addition to a `Disabled' setting.

 There might be a genuine BIOS bug there as well of course as serial ports 
seem to be less used these days and the issue may have escaped validation.

  Maciej

Re: console issue since 3.6, console=ttyS1 hangs

2016-11-05 Thread Maciej W. Rozycki

On Fri, 4 Nov 2016, Peter Hurley wrote:

> > These bios screens do not have any mention of PNP settings.
> > I am getting output over the console (via ipmi) until the boot hangs.
> 
> Yeah, probably the device actually decodes io address access anyway,
> but in the disabled state probably has not routed IRQ.
> 
> I have no idea how to help you with the bios, sorry.

 I'd look out for serial port, Super-I/O or COM1 port (which is how PC-DOS 
named the device some 35 years ago) settings rather than anything to do 
with PNP.  Typically you'd be able to choose from a few classic combined 
I/O space address and IRQ assignments in addition to a `Disabled' setting.

 There might be a genuine BIOS bug there as well of course as serial ports 
seem to be less used these days and the issue may have escaped validation.

  Maciej

DO YOU NEED A LOAN?

2016-11-05 Thread bancoleite

We offer loan at 3% if interested reply us with your email for full info

DO YOU NEED A LOAN?

2016-11-05 Thread bancoleite

We offer loan at 3% if interested reply us with your email for full info

Re: [PATCH/RFC] z3fold: use per-page read/write lock

2016-11-05 Thread Andi Kleen

Vitaly Wool  writes:

> Most of z3fold operations are in-page, such as modifying z3fold
> page header or moving z3fold objects within a page. Taking
> per-pool spinlock to protect per-page objects is therefore
> suboptimal, and the idea of having a per-page spinlock (or rwlock)
> has been around for some time. However, adding one directly to the
> z3fold header makes the latter quite big on some systems so that
> it won't fit in a signle chunk.

> + atomic_t page_lock;

This doesnt make much sense. A standard spinlock is not bigger
than 4 bytes either. Also reinventing locks is usually a bad
idea: they are tricky to get right, you have no debugging support,
hard to analyze, etc.

-Andi

Re: [PATCH/RFC] z3fold: use per-page read/write lock

2016-11-05 Thread Andi Kleen

Vitaly Wool  writes:

> Most of z3fold operations are in-page, such as modifying z3fold
> page header or moving z3fold objects within a page. Taking
> per-pool spinlock to protect per-page objects is therefore
> suboptimal, and the idea of having a per-page spinlock (or rwlock)
> has been around for some time. However, adding one directly to the
> z3fold header makes the latter quite big on some systems so that
> it won't fit in a signle chunk.

> + atomic_t page_lock;

This doesnt make much sense. A standard spinlock is not bigger
than 4 bytes either. Also reinventing locks is usually a bad
idea: they are tricky to get right, you have no debugging support,
hard to analyze, etc.

-Andi

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

2016-11-05 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:   fb415f222c26d0d1fa19615af1d102bf5f5b3ca2
commit: ebb5e78cc63417a35254a791de66e1cc84f963cc MIPS: Initial implementation 
of a VDSO
date:   12 months ago
config: mips-jmr3927_defconfig (attached as .config)
compiler: mips-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=r3900' requires '-mfp32'
/*

--
>> arch/mips/vdso/sigreturn.S:1:0: error: '-march=r3900' 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=r3900' requires '-mfp32'

2016-11-05 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:   fb415f222c26d0d1fa19615af1d102bf5f5b3ca2
commit: ebb5e78cc63417a35254a791de66e1cc84f963cc MIPS: Initial implementation 
of a VDSO
date:   12 months ago
config: mips-jmr3927_defconfig (attached as .config)
compiler: mips-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=r3900' requires '-mfp32'
/*

--
>> arch/mips/vdso/sigreturn.S:1:0: error: '-march=r3900' 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

core.c:undefined reference to `fpu_save'

2016-11-05 Thread kbuild test robot

Hi Andrew,

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:   ffbcbfca846ed117e3d4009acfbf1e1590c56b2f
commit: c60f169202c7643991a8b4bfeea60e06843d5b5a 
arch/mn10300/kernel/fpu-nofpu.c: needs asm/elf.h
date:   8 months ago
config: mn10300-allnoconfig (attached as .config)
compiler: am33_2.0-linux-gcc (GCC) 6.2.0
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 c60f169202c7643991a8b4bfeea60e06843d5b5a
# save the attached .config to linux build tree
make.cross ARCH=mn10300 

All errors (new ones prefixed by >>):

   kernel/built-in.o: In function `.L410':
>> core.c:(.sched.text+0x28a): undefined reference to `fpu_save'

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


.config.gz
Description: application/gzip

include/linux/unaligned/access_ok.h:37:20: error: redefinition of 'put_unaligned_le16'

2016-11-05 Thread kbuild test robot

Hi Vincent,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   fb415f222c26d0d1fa19615af1d102bf5f5b3ca2
commit: 3194c6870158e305dac2af52f83681e9cb67280f NFC: nfcmrvl: add firmware 
download support
date:   1 year ago
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
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 3194c6870158e305dac2af52f83681e9cb67280f
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
   include/linux/unaligned/access_ok.h:7:19: error: redefinition of 
'get_unaligned_le16'
static inline u16 get_unaligned_le16(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/le_struct.h:6:19: note: previous definition of 
'get_unaligned_le16' was here
static inline u16 get_unaligned_le16(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
   include/linux/unaligned/access_ok.h:12:19: error: redefinition of 
'get_unaligned_le32'
static inline u32 get_unaligned_le32(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/le_struct.h:11:19: note: previous definition of 
'get_unaligned_le32' was here
static inline u32 get_unaligned_le32(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
   include/linux/unaligned/access_ok.h:17:19: error: redefinition of 
'get_unaligned_le64'
static inline u64 get_unaligned_le64(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/le_struct.h:16:19: note: previous definition of 
'get_unaligned_le64' was here
static inline u64 get_unaligned_le64(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
   include/linux/unaligned/access_ok.h:22:19: error: redefinition of 
'get_unaligned_be16'
static inline u16 get_unaligned_be16(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:5:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/be_byteshift.h:40:19: note: previous definition of 
'get_unaligned_be16' was here
static inline u16 get_unaligned_be16(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
   include/linux/unaligned/access_ok.h:27:19: error: redefinition of 
'get_unaligned_be32'
static inline u32 get_unaligned_be32(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:5:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,

core.c:undefined reference to `fpu_save'

2016-11-05 Thread kbuild test robot

Hi Andrew,

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:   ffbcbfca846ed117e3d4009acfbf1e1590c56b2f
commit: c60f169202c7643991a8b4bfeea60e06843d5b5a 
arch/mn10300/kernel/fpu-nofpu.c: needs asm/elf.h
date:   8 months ago
config: mn10300-allnoconfig (attached as .config)
compiler: am33_2.0-linux-gcc (GCC) 6.2.0
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 c60f169202c7643991a8b4bfeea60e06843d5b5a
# save the attached .config to linux build tree
make.cross ARCH=mn10300 

All errors (new ones prefixed by >>):

   kernel/built-in.o: In function `.L410':
>> core.c:(.sched.text+0x28a): undefined reference to `fpu_save'

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


.config.gz
Description: application/gzip

include/linux/unaligned/access_ok.h:37:20: error: redefinition of 'put_unaligned_le16'

2016-11-05 Thread kbuild test robot

Hi Vincent,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   fb415f222c26d0d1fa19615af1d102bf5f5b3ca2
commit: 3194c6870158e305dac2af52f83681e9cb67280f NFC: nfcmrvl: add firmware 
download support
date:   1 year ago
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
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 3194c6870158e305dac2af52f83681e9cb67280f
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
   include/linux/unaligned/access_ok.h:7:19: error: redefinition of 
'get_unaligned_le16'
static inline u16 get_unaligned_le16(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/le_struct.h:6:19: note: previous definition of 
'get_unaligned_le16' was here
static inline u16 get_unaligned_le16(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
   include/linux/unaligned/access_ok.h:12:19: error: redefinition of 
'get_unaligned_le32'
static inline u32 get_unaligned_le32(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/le_struct.h:11:19: note: previous definition of 
'get_unaligned_le32' was here
static inline u32 get_unaligned_le32(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
   include/linux/unaligned/access_ok.h:17:19: error: redefinition of 
'get_unaligned_le64'
static inline u64 get_unaligned_le64(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/le_struct.h:16:19: note: previous definition of 
'get_unaligned_le64' was here
static inline u64 get_unaligned_le64(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
   include/linux/unaligned/access_ok.h:22:19: error: redefinition of 
'get_unaligned_be16'
static inline u16 get_unaligned_be16(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:5:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/be_byteshift.h:40:19: note: previous definition of 
'get_unaligned_be16' was here
static inline u16 get_unaligned_be16(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
   include/linux/unaligned/access_ok.h:27:19: error: redefinition of 
'get_unaligned_be32'
static inline u32 get_unaligned_be32(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:5:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,

include/linux/unaligned/access_ok.h:7:19: error: redefinition of 'get_unaligned_le16'

2016-11-05 Thread kbuild test robot

Hi Vincent,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   ffbcbfca846ed117e3d4009acfbf1e1590c56b2f
commit: 3194c6870158e305dac2af52f83681e9cb67280f NFC: nfcmrvl: add firmware 
download support
date:   1 year ago
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
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 3194c6870158e305dac2af52f83681e9cb67280f
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
>> include/linux/unaligned/access_ok.h:7:19: error: redefinition of 
>> 'get_unaligned_le16'
static inline u16 get_unaligned_le16(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/le_struct.h:6:19: note: previous definition of 
'get_unaligned_le16' was here
static inline u16 get_unaligned_le16(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
>> include/linux/unaligned/access_ok.h:12:19: error: redefinition of 
>> 'get_unaligned_le32'
static inline u32 get_unaligned_le32(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/le_struct.h:11:19: note: previous definition of 
'get_unaligned_le32' was here
static inline u32 get_unaligned_le32(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
>> include/linux/unaligned/access_ok.h:17:19: error: redefinition of 
>> 'get_unaligned_le64'
static inline u64 get_unaligned_le64(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/le_struct.h:16:19: note: previous definition of 
'get_unaligned_le64' was here
static inline u64 get_unaligned_le64(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
>> include/linux/unaligned/access_ok.h:22:19: error: redefinition of 
>> 'get_unaligned_be16'
static inline u16 get_unaligned_be16(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:5:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/be_byteshift.h:40:19: note: previous definition of 
'get_unaligned_be16' was here
static inline u16 get_unaligned_be16(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
>> include/linux/unaligned/access_ok.h:27:19: error: redefinition of 
>> 'get_unaligned_be32'
static inline u32 get_unaligned_be32(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:5:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,

include/linux/unaligned/access_ok.h:7:19: error: redefinition of 'get_unaligned_le16'

2016-11-05 Thread kbuild test robot

Hi Vincent,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   ffbcbfca846ed117e3d4009acfbf1e1590c56b2f
commit: 3194c6870158e305dac2af52f83681e9cb67280f NFC: nfcmrvl: add firmware 
download support
date:   1 year ago
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 6.2.0
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 3194c6870158e305dac2af52f83681e9cb67280f
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All errors (new ones prefixed by >>):

   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
>> include/linux/unaligned/access_ok.h:7:19: error: redefinition of 
>> 'get_unaligned_le16'
static inline u16 get_unaligned_le16(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/le_struct.h:6:19: note: previous definition of 
'get_unaligned_le16' was here
static inline u16 get_unaligned_le16(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
>> include/linux/unaligned/access_ok.h:12:19: error: redefinition of 
>> 'get_unaligned_le32'
static inline u32 get_unaligned_le32(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/le_struct.h:11:19: note: previous definition of 
'get_unaligned_le32' was here
static inline u32 get_unaligned_le32(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
>> include/linux/unaligned/access_ok.h:17:19: error: redefinition of 
>> 'get_unaligned_le64'
static inline u64 get_unaligned_le64(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:4:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/le_struct.h:16:19: note: previous definition of 
'get_unaligned_le64' was here
static inline u64 get_unaligned_le64(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
>> include/linux/unaligned/access_ok.h:22:19: error: redefinition of 
>> 'get_unaligned_be16'
static inline u16 get_unaligned_be16(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:5:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,
from include/linux/topology.h:33,
from include/linux/gfp.h:8,
from include/linux/kmod.h:22,
from include/linux/module.h:13,
from drivers/nfc/nfcmrvl/fw_dnld.c:19:
   include/linux/unaligned/be_byteshift.h:40:19: note: previous definition of 
'get_unaligned_be16' was here
static inline u16 get_unaligned_be16(const void *p)
  ^~
   In file included from drivers/nfc/nfcmrvl/fw_dnld.c:20:0:
>> include/linux/unaligned/access_ok.h:27:19: error: redefinition of 
>> 'get_unaligned_be32'
static inline u32 get_unaligned_be32(const void *p)
  ^~
   In file included from arch/ia64/include/asm/unaligned.h:5:0,
from arch/ia64/include/asm/io.h:22,
from arch/ia64/include/asm/smp.h:20,
from include/linux/smp.h:59,

[PATCH] ASoC: fsl: fix fsl_spdif.c build errors

2016-11-05 Thread Randy Dunlap

From: Randy Dunlap 

Fix build errors in sound/soc/fsl/fsl_spdif.c by selecting BITREVERSE.
Fixes these build errors:

sound/built-in.o: In function `spdif_write_channel_status':
fsl_spdif.c:(.text+0xbe39d): undefined reference to `byte_rev_table'
fsl_spdif.c:(.text+0xbe3a8): undefined reference to `byte_rev_table'
fsl_spdif.c:(.text+0xbe3be): undefined reference to `byte_rev_table'
fsl_spdif.c:(.text+0xbe3d8): undefined reference to `byte_rev_table'

Signed-off-by: Randy Dunlap 
Reported-by: kbuild test robot 
Applies-to: all 3.x, all 4.x
---
 sound/soc/fsl/Kconfig |1 +
 1 file changed, 1 insertion(+)

--- lnx-49-rc3.orig/sound/soc/fsl/Kconfig
+++ lnx-49-rc3/sound/soc/fsl/Kconfig
@@ -40,6 +40,7 @@ config SND_SOC_FSL_SPDIF
select REGMAP_MMIO
select SND_SOC_IMX_PCM_DMA if SND_IMX_SOC != n
select SND_SOC_IMX_PCM_FIQ if SND_IMX_SOC != n && (MXC_TZIC || MXC_AVIC)
+   select BITREVERSE
help
  Say Y if you want to add Sony/Philips Digital Interface (SPDIF)
  support for the Freescale CPUs.

[PATCH] ASoC: fsl: fix fsl_spdif.c build errors

2016-11-05 Thread Randy Dunlap

From: Randy Dunlap 

Fix build errors in sound/soc/fsl/fsl_spdif.c by selecting BITREVERSE.
Fixes these build errors:

sound/built-in.o: In function `spdif_write_channel_status':
fsl_spdif.c:(.text+0xbe39d): undefined reference to `byte_rev_table'
fsl_spdif.c:(.text+0xbe3a8): undefined reference to `byte_rev_table'
fsl_spdif.c:(.text+0xbe3be): undefined reference to `byte_rev_table'
fsl_spdif.c:(.text+0xbe3d8): undefined reference to `byte_rev_table'

Signed-off-by: Randy Dunlap 
Reported-by: kbuild test robot 
Applies-to: all 3.x, all 4.x
---
 sound/soc/fsl/Kconfig |1 +
 1 file changed, 1 insertion(+)

--- lnx-49-rc3.orig/sound/soc/fsl/Kconfig
+++ lnx-49-rc3/sound/soc/fsl/Kconfig
@@ -40,6 +40,7 @@ config SND_SOC_FSL_SPDIF
select REGMAP_MMIO
select SND_SOC_IMX_PCM_DMA if SND_IMX_SOC != n
select SND_SOC_IMX_PCM_FIQ if SND_IMX_SOC != n && (MXC_TZIC || MXC_AVIC)
+   select BITREVERSE
help
  Say Y if you want to add Sony/Philips Digital Interface (SPDIF)
  support for the Freescale CPUs.

Re: [mm PATCH v2 03/26] swiotlb: Add support for DMA_ATTR_SKIP_CPU_SYNC

2016-11-05 Thread Alexander Duyck

On Sat, Nov 5, 2016 at 12:39 PM, Konrad Rzeszutek Wilk
 wrote:
> .. snip..
>> @@ -561,6 +565,7 @@ void swiotlb_tbl_unmap_single(struct device *hwdev, 
>> phys_addr_t tlb_addr,
>>* First, sync the memory before unmapping the entry
>>*/
>>   if (orig_addr != INVALID_PHYS_ADDR &&
>> + !(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
>>   ((dir == DMA_FROM_DEVICE) || (dir == DMA_BIDIRECTIONAL)))
>>   swiotlb_bounce(orig_addr, tlb_addr, size, DMA_FROM_DEVICE);
>>
>> @@ -654,7 +659,8 @@ void swiotlb_tbl_sync_single(struct device *hwdev, 
>> phys_addr_t tlb_addr,
>>* GFP_DMA memory; fall back on map_single(), which
>>* will grab memory from the lowest available address range.
>>*/
>> - phys_addr_t paddr = map_single(hwdev, 0, size, 
>> DMA_FROM_DEVICE);
>> + phys_addr_t paddr = map_single(hwdev, 0, size,
>> +DMA_FROM_DEVICE, 0);
>>   if (paddr == SWIOTLB_MAP_ERROR)
>>   goto err_warn;
>>
>> @@ -669,7 +675,8 @@ void swiotlb_tbl_sync_single(struct device *hwdev, 
>> phys_addr_t tlb_addr,
>>
>>   /* DMA_TO_DEVICE to avoid memcpy in unmap_single */
>>   swiotlb_tbl_unmap_single(hwdev, paddr,
>> -  size, DMA_TO_DEVICE);
>> +  size, DMA_TO_DEVICE,
>> +  DMA_ATTR_SKIP_CPU_SYNC);
>
> This I believe is redundant. That is swiotlb_tbl_unmap_single only
> does an bounce if the dir is DMA_FROM_DEVICE or DMA_BIDIRECTIONAL.
>
> I added /* optional. */

You are probably right.  I don't need to add the DMA_ATTR_SKIP_CPU_SYNC here.

>>   goto err_warn;
>>   }
>>   }
>> @@ -699,7 +706,7 @@ void swiotlb_tbl_sync_single(struct device *hwdev, 
>> phys_addr_t tlb_addr,
>>   free_pages((unsigned long)vaddr, get_order(size));
>>   else
>>   /* DMA_TO_DEVICE to avoid memcpy in swiotlb_tbl_unmap_single */
>> - swiotlb_tbl_unmap_single(hwdev, paddr, size, DMA_TO_DEVICE);
>> + swiotlb_tbl_unmap_single(hwdev, paddr, size, DMA_TO_DEVICE, 0);
>
> .. but here you choose to put 0? I changed that to
> DMA_ATTR_SKIP_CPU_SYNC and expanded the comment above.
>
> Time to test the patches.

I think I had probably realized the fact that I didn't need it above
and so just used 0 here.  I can clean this up and resubmit if you
want.

Do you want me to just split this patch set up so that I submit the
swiotlb patches to you and leave the rest of the patches for the mm
tree?

Thanks.

- Alex

Re: [GIT PULL] overlayfs fixes for 4.9-rc3

2016-11-05 Thread Peter Rosin

> And the thing is, backward incompatibility is less of an issue for
> overlayfs than for normal filesystems, because it's usually not
> something people store their root filesystems on, and if so they can
> simply not turn off this feature.

That got my attention. What backwards incompatible thing is it that
I simply cannot turn off for the overlayfs that I use as root fs?
Now, we don't boot straight into the overlay as root fs, buy we do
pivot it in early enough. If you are somehow suggesting that
overlayfs as root fs is not something that needs considering you
need to think again. We depend on it, and I will flag any regression
that we are walking into.

But hopefully you just messed up the negations, and you meant that we
*can* simply turn  off?

Cheers,
Peter

[I hope threading works, got the message-id from an archive]

Re: [mm PATCH v2 03/26] swiotlb: Add support for DMA_ATTR_SKIP_CPU_SYNC

2016-11-05 Thread Alexander Duyck

On Sat, Nov 5, 2016 at 12:39 PM, Konrad Rzeszutek Wilk
 wrote:
> .. snip..
>> @@ -561,6 +565,7 @@ void swiotlb_tbl_unmap_single(struct device *hwdev, 
>> phys_addr_t tlb_addr,
>>* First, sync the memory before unmapping the entry
>>*/
>>   if (orig_addr != INVALID_PHYS_ADDR &&
>> + !(attrs & DMA_ATTR_SKIP_CPU_SYNC) &&
>>   ((dir == DMA_FROM_DEVICE) || (dir == DMA_BIDIRECTIONAL)))
>>   swiotlb_bounce(orig_addr, tlb_addr, size, DMA_FROM_DEVICE);
>>
>> @@ -654,7 +659,8 @@ void swiotlb_tbl_sync_single(struct device *hwdev, 
>> phys_addr_t tlb_addr,
>>* GFP_DMA memory; fall back on map_single(), which
>>* will grab memory from the lowest available address range.
>>*/
>> - phys_addr_t paddr = map_single(hwdev, 0, size, 
>> DMA_FROM_DEVICE);
>> + phys_addr_t paddr = map_single(hwdev, 0, size,
>> +DMA_FROM_DEVICE, 0);
>>   if (paddr == SWIOTLB_MAP_ERROR)
>>   goto err_warn;
>>
>> @@ -669,7 +675,8 @@ void swiotlb_tbl_sync_single(struct device *hwdev, 
>> phys_addr_t tlb_addr,
>>
>>   /* DMA_TO_DEVICE to avoid memcpy in unmap_single */
>>   swiotlb_tbl_unmap_single(hwdev, paddr,
>> -  size, DMA_TO_DEVICE);
>> +  size, DMA_TO_DEVICE,
>> +  DMA_ATTR_SKIP_CPU_SYNC);
>
> This I believe is redundant. That is swiotlb_tbl_unmap_single only
> does an bounce if the dir is DMA_FROM_DEVICE or DMA_BIDIRECTIONAL.
>
> I added /* optional. */

You are probably right.  I don't need to add the DMA_ATTR_SKIP_CPU_SYNC here.

>>   goto err_warn;
>>   }
>>   }
>> @@ -699,7 +706,7 @@ void swiotlb_tbl_sync_single(struct device *hwdev, 
>> phys_addr_t tlb_addr,
>>   free_pages((unsigned long)vaddr, get_order(size));
>>   else
>>   /* DMA_TO_DEVICE to avoid memcpy in swiotlb_tbl_unmap_single */
>> - swiotlb_tbl_unmap_single(hwdev, paddr, size, DMA_TO_DEVICE);
>> + swiotlb_tbl_unmap_single(hwdev, paddr, size, DMA_TO_DEVICE, 0);
>
> .. but here you choose to put 0? I changed that to
> DMA_ATTR_SKIP_CPU_SYNC and expanded the comment above.
>
> Time to test the patches.

I think I had probably realized the fact that I didn't need it above
and so just used 0 here.  I can clean this up and resubmit if you
want.

Do you want me to just split this patch set up so that I submit the
swiotlb patches to you and leave the rest of the patches for the mm
tree?

Thanks.

- Alex

Re: [GIT PULL] overlayfs fixes for 4.9-rc3

2016-11-05 Thread Peter Rosin

> And the thing is, backward incompatibility is less of an issue for
> overlayfs than for normal filesystems, because it's usually not
> something people store their root filesystems on, and if so they can
> simply not turn off this feature.

That got my attention. What backwards incompatible thing is it that
I simply cannot turn off for the overlayfs that I use as root fs?
Now, we don't boot straight into the overlay as root fs, buy we do
pivot it in early enough. If you are somehow suggesting that
overlayfs as root fs is not something that needs considering you
need to think again. We depend on it, and I will flag any regression
that we are walking into.

But hopefully you just messed up the negations, and you meant that we
*can* simply turn  off?

Cheers,
Peter

[I hope threading works, got the message-id from an archive]

scripts/gcc-plugins/gcc-common.h:4:22: fatal error: bversion.h: No such file or directory

2016-11-05 Thread kbuild test robot

Hi Emese,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   ffbcbfca846ed117e3d4009acfbf1e1590c56b2f
commit: 543c37cb165049c3be24a0d4733e67caa2b33eef Add sancov plugin
date:   5 months ago
config: x86_64-randconfig-in0-11060649 (attached as .config)
compiler: gcc-4.6 (Debian 4.6.4-7) 4.6.4
reproduce:
git checkout 543c37cb165049c3be24a0d4733e67caa2b33eef
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   scripts/Makefile.gcc-plugins:17: warning: cannot use CONFIG_KCOV: 
-fsanitize-coverage=trace-pc is not supported by compiler
   ++(scripts/gcc-plugin.sh:2): main(): dirname scripts/gcc-plugin.sh
   +(scripts/gcc-plugin.sh:2): main(): srctree=scripts
   ++(scripts/gcc-plugin.sh:3): main(): gcc-4.6 -print-file-name=plugin
   +(scripts/gcc-plugin.sh:3): main(): gccplugins_dir=plugin
   ++(scripts/gcc-plugin.sh:12): main(): gcc-4.6 -E -x c++ - -o /dev/null 
-Iscripts/gcc-plugins -Iplugin/include
   +(scripts/gcc-plugin.sh:12): main(): plugincc='In file included from 
:1:0:
>> scripts/gcc-plugins/gcc-common.h:4:22: fatal error: bversion.h: No such file 
>> or directory
   compilation terminated.'
   +(scripts/gcc-plugin.sh:14): main(): '[' 1 -ne 0 ']'
   +(scripts/gcc-plugin.sh:16): main(): exit 1
   scripts/Makefile.gcc-plugins:30: warning: your gcc installation does not 
support plugins, perhaps the necessary headers are missing?
   In file included from scripts/gcc-plugins/sancov_plugin.c:22:0:
>> scripts/gcc-plugins/gcc-common.h:4:22: fatal error: bversion.h: No such file 
>> or directory
#include "bversion.h"
 ^
   compilation terminated.
   make[2]: *** [scripts/gcc-plugins/sancov_plugin.o] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [gcc-plugins] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +4 scripts/gcc-plugins/gcc-common.h

6b90bd4b Emese Revfy 2016-05-24  1  #ifndef GCC_COMMON_H_INCLUDED
6b90bd4b Emese Revfy 2016-05-24  2  #define GCC_COMMON_H_INCLUDED
6b90bd4b Emese Revfy 2016-05-24  3  
6b90bd4b Emese Revfy 2016-05-24 @4  #include "bversion.h"
6b90bd4b Emese Revfy 2016-05-24  5  #if BUILDING_GCC_VERSION >= 6000
6b90bd4b Emese Revfy 2016-05-24  6  #include "gcc-plugin.h"
6b90bd4b Emese Revfy 2016-05-24  7  #else

:: The code at line 4 was first introduced by commit
:: 6b90bd4ba40b38dc13c2782469c1c77e4ed79915 GCC plugin infrastructure

:: TO: Emese Revfy 
:: CC: Michal Marek 

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


.config.gz
Description: application/gzip

scripts/gcc-plugins/gcc-common.h:4:22: fatal error: bversion.h: No such file or directory

2016-11-05 Thread kbuild test robot

Hi Emese,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   ffbcbfca846ed117e3d4009acfbf1e1590c56b2f
commit: 543c37cb165049c3be24a0d4733e67caa2b33eef Add sancov plugin
date:   5 months ago
config: x86_64-randconfig-in0-11060649 (attached as .config)
compiler: gcc-4.6 (Debian 4.6.4-7) 4.6.4
reproduce:
git checkout 543c37cb165049c3be24a0d4733e67caa2b33eef
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   scripts/Makefile.gcc-plugins:17: warning: cannot use CONFIG_KCOV: 
-fsanitize-coverage=trace-pc is not supported by compiler
   ++(scripts/gcc-plugin.sh:2): main(): dirname scripts/gcc-plugin.sh
   +(scripts/gcc-plugin.sh:2): main(): srctree=scripts
   ++(scripts/gcc-plugin.sh:3): main(): gcc-4.6 -print-file-name=plugin
   +(scripts/gcc-plugin.sh:3): main(): gccplugins_dir=plugin
   ++(scripts/gcc-plugin.sh:12): main(): gcc-4.6 -E -x c++ - -o /dev/null 
-Iscripts/gcc-plugins -Iplugin/include
   +(scripts/gcc-plugin.sh:12): main(): plugincc='In file included from 
:1:0:
>> scripts/gcc-plugins/gcc-common.h:4:22: fatal error: bversion.h: No such file 
>> or directory
   compilation terminated.'
   +(scripts/gcc-plugin.sh:14): main(): '[' 1 -ne 0 ']'
   +(scripts/gcc-plugin.sh:16): main(): exit 1
   scripts/Makefile.gcc-plugins:30: warning: your gcc installation does not 
support plugins, perhaps the necessary headers are missing?
   In file included from scripts/gcc-plugins/sancov_plugin.c:22:0:
>> scripts/gcc-plugins/gcc-common.h:4:22: fatal error: bversion.h: No such file 
>> or directory
#include "bversion.h"
 ^
   compilation terminated.
   make[2]: *** [scripts/gcc-plugins/sancov_plugin.o] Error 1
   make[2]: Target '__build' not remade because of errors.
   make[1]: *** [gcc-plugins] Error 2
   make[1]: Target 'prepare' not remade because of errors.
   make: *** [sub-make] Error 2

vim +4 scripts/gcc-plugins/gcc-common.h

6b90bd4b Emese Revfy 2016-05-24  1  #ifndef GCC_COMMON_H_INCLUDED
6b90bd4b Emese Revfy 2016-05-24  2  #define GCC_COMMON_H_INCLUDED
6b90bd4b Emese Revfy 2016-05-24  3  
6b90bd4b Emese Revfy 2016-05-24 @4  #include "bversion.h"
6b90bd4b Emese Revfy 2016-05-24  5  #if BUILDING_GCC_VERSION >= 6000
6b90bd4b Emese Revfy 2016-05-24  6  #include "gcc-plugin.h"
6b90bd4b Emese Revfy 2016-05-24  7  #else

:: The code at line 4 was first introduced by commit
:: 6b90bd4ba40b38dc13c2782469c1c77e4ed79915 GCC plugin infrastructure

:: TO: Emese Revfy 
:: CC: Michal Marek 

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


.config.gz
Description: application/gzip

Linux 4.9-rcX: rcu_preempt detected stalls on CPUs/tasks messages

2016-11-05 Thread Gabriel C

Hello ,


I've tested 4.9-rcX and Linus git tree and have on this box the following 
messages :

.

Nov 05 20:26:40 zwerg kernel: INFO: rcu_preempt detected stalls on CPUs/tasks:
Nov 05 20:26:40 zwerg kernel: Tasks blocked on level-0 rcu_node (CPUs 
0-15): P0
Nov 05 20:26:40 zwerg kernel: (detected by 8, t=60002 jiffies, g=2426, 
c=2425, q=789)
Nov 05 20:26:40 zwerg kernel: swapper/0   R  running task0 0
  0 0x0020
Nov 05 20:26:40 zwerg kernel:   88043fc0c6c0 
810ca25e 0004
Nov 05 20:26:40 zwerg kernel:  0002 0003 
0010 814b936f
Nov 05 20:26:40 zwerg kernel:  88043fc1d600 81893f00 
0003 81893de0
Nov 05 20:26:40 zwerg kernel: Call Trace:
Nov 05 20:26:40 zwerg kernel:  [] ? 
__tick_broadcast_oneshot_control+0x5e/0x220
Nov 05 20:26:40 zwerg kernel:  [] ? intel_idle+0xef/0xfe
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpuidle_enter_state+0x125/0x200
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpu_startup_entry+0x13f/0x230
Nov 05 20:26:40 zwerg kernel:  [] ? start_kernel+0x428/0x430
Nov 05 20:26:40 zwerg kernel:  [] ? 
early_idt_handler_array+0x120/0x120
Nov 05 20:26:40 zwerg kernel:  [] ? 
x86_64_start_kernel+0xef/0xfe
Nov 05 20:26:40 zwerg kernel: swapper/0   R  running task0 0
  0 0x0020
Nov 05 20:26:40 zwerg kernel:   88043fc0c6c0 
810ca25e 0004
Nov 05 20:26:40 zwerg kernel:  0002 0003 
0010 814b936f
Nov 05 20:26:40 zwerg kernel:  88043fc1d600 81893f00 
0003 81893de0
Nov 05 20:26:40 zwerg kernel: Call Trace:
Nov 05 20:26:40 zwerg kernel:  [] ? 
__tick_broadcast_oneshot_control+0x5e/0x220
Nov 05 20:26:40 zwerg kernel:  [] ? intel_idle+0xef/0xfe
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpuidle_enter_state+0x125/0x200
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpu_startup_entry+0x13f/0x230
Nov 05 20:26:40 zwerg kernel:  [] ? start_kernel+0x428/0x430
Nov 05 20:26:40 zwerg kernel:  [] ? 
early_idt_handler_array+0x120/0x120
Nov 05 20:26:40 zwerg kernel:  [] ? 
x86_64_start_kernel+0xef/0xfe

.

When I boot to console mode the system seems to work at least when I'm loggen 
in from tty1.
Switching to other tty's sometimes works sometimes not.. Starting X makes the 
box hang.. sddm starts but I
never get to the logn screen. After some minutes I have to hard reset the box..

Latest tested git kernel is 4.9.0-rc3-00429-g03daa36 , the box is a FUJITSU 
PRIMERGY TX200 S5.

config used and dmesg can be found there :

http://ftp.frugalware.org/pub/other/people/crazy/kernel/

Best Regards

Gabriel C

Linux 4.9-rcX: rcu_preempt detected stalls on CPUs/tasks messages

2016-11-05 Thread Gabriel C

Hello ,


I've tested 4.9-rcX and Linus git tree and have on this box the following 
messages :

.

Nov 05 20:26:40 zwerg kernel: INFO: rcu_preempt detected stalls on CPUs/tasks:
Nov 05 20:26:40 zwerg kernel: Tasks blocked on level-0 rcu_node (CPUs 
0-15): P0
Nov 05 20:26:40 zwerg kernel: (detected by 8, t=60002 jiffies, g=2426, 
c=2425, q=789)
Nov 05 20:26:40 zwerg kernel: swapper/0   R  running task0 0
  0 0x0020
Nov 05 20:26:40 zwerg kernel:   88043fc0c6c0 
810ca25e 0004
Nov 05 20:26:40 zwerg kernel:  0002 0003 
0010 814b936f
Nov 05 20:26:40 zwerg kernel:  88043fc1d600 81893f00 
0003 81893de0
Nov 05 20:26:40 zwerg kernel: Call Trace:
Nov 05 20:26:40 zwerg kernel:  [] ? 
__tick_broadcast_oneshot_control+0x5e/0x220
Nov 05 20:26:40 zwerg kernel:  [] ? intel_idle+0xef/0xfe
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpuidle_enter_state+0x125/0x200
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpu_startup_entry+0x13f/0x230
Nov 05 20:26:40 zwerg kernel:  [] ? start_kernel+0x428/0x430
Nov 05 20:26:40 zwerg kernel:  [] ? 
early_idt_handler_array+0x120/0x120
Nov 05 20:26:40 zwerg kernel:  [] ? 
x86_64_start_kernel+0xef/0xfe
Nov 05 20:26:40 zwerg kernel: swapper/0   R  running task0 0
  0 0x0020
Nov 05 20:26:40 zwerg kernel:   88043fc0c6c0 
810ca25e 0004
Nov 05 20:26:40 zwerg kernel:  0002 0003 
0010 814b936f
Nov 05 20:26:40 zwerg kernel:  88043fc1d600 81893f00 
0003 81893de0
Nov 05 20:26:40 zwerg kernel: Call Trace:
Nov 05 20:26:40 zwerg kernel:  [] ? 
__tick_broadcast_oneshot_control+0x5e/0x220
Nov 05 20:26:40 zwerg kernel:  [] ? intel_idle+0xef/0xfe
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpuidle_enter_state+0x125/0x200
Nov 05 20:26:40 zwerg kernel:  [] ? 
cpu_startup_entry+0x13f/0x230
Nov 05 20:26:40 zwerg kernel:  [] ? start_kernel+0x428/0x430
Nov 05 20:26:40 zwerg kernel:  [] ? 
early_idt_handler_array+0x120/0x120
Nov 05 20:26:40 zwerg kernel:  [] ? 
x86_64_start_kernel+0xef/0xfe

.

When I boot to console mode the system seems to work at least when I'm loggen 
in from tty1.
Switching to other tty's sometimes works sometimes not.. Starting X makes the 
box hang.. sddm starts but I
never get to the logn screen. After some minutes I have to hard reset the box..

Latest tested git kernel is 4.9.0-rc3-00429-g03daa36 , the box is a FUJITSU 
PRIMERGY TX200 S5.

config used and dmesg can be found there :

http://ftp.frugalware.org/pub/other/people/crazy/kernel/

Best Regards

Gabriel C

Re: [PATCH 5/8] block: add code to track actual device queue depth

2016-11-05 Thread Jan Kara

On Tue 01-11-16 15:08:48, Jens Axboe wrote:
> For blk-mq, ->nr_requests does track queue depth, at least at init
> time. But for the older queue paths, it's simply a soft setting.
> On top of that, it's generally larger than the hardware setting
> on purpose, to allow backup of requests for merging.
> 
> Fill a hole in struct request with a 'queue_depth' member, that
> drivers can call to more closely inform the block layer of the
> real queue depth.
> 
> Signed-off-by: Jens Axboe 

The patch looks good to me. You can add:

Reviewed-by: Jan Kara 

Honza
> ---
>  block/blk-settings.c   | 12 
>  drivers/scsi/scsi.c|  3 +++
>  include/linux/blkdev.h | 11 +++
>  3 files changed, 26 insertions(+)
> 
> diff --git a/block/blk-settings.c b/block/blk-settings.c
> index 55369a65dea2..9cf053759363 100644
> --- a/block/blk-settings.c
> +++ b/block/blk-settings.c
> @@ -837,6 +837,18 @@ void blk_queue_flush_queueable(struct request_queue *q, 
> bool queueable)
>  EXPORT_SYMBOL_GPL(blk_queue_flush_queueable);
>  
>  /**
> + * blk_set_queue_depth - tell the block layer about the device queue depth
> + * @q:   the request queue for the device
> + * @depth:   queue depth
> + *
> + */
> +void blk_set_queue_depth(struct request_queue *q, unsigned int depth)
> +{
> + q->queue_depth = depth;
> +}
> +EXPORT_SYMBOL(blk_set_queue_depth);
> +
> +/**
>   * blk_queue_write_cache - configure queue's write cache
>   * @q:   the request queue for the device
>   * @wc:  write back cache on or off
> diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
> index 1deb6adc411f..75455d4dab68 100644
> --- a/drivers/scsi/scsi.c
> +++ b/drivers/scsi/scsi.c
> @@ -621,6 +621,9 @@ int scsi_change_queue_depth(struct scsi_device *sdev, int 
> depth)
>   wmb();
>   }
>  
> + if (sdev->request_queue)
> + blk_set_queue_depth(sdev->request_queue, depth);
> +
>   return sdev->queue_depth;
>  }
>  EXPORT_SYMBOL(scsi_change_queue_depth);
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index 8396da2bb698..0c677fb35ce4 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -405,6 +405,8 @@ struct request_queue {
>   struct blk_mq_ctx __percpu  *queue_ctx;
>   unsigned intnr_queues;
>  
> + unsigned intqueue_depth;
> +
>   /* hw dispatch queues */
>   struct blk_mq_hw_ctx**queue_hw_ctx;
>   unsigned intnr_hw_queues;
> @@ -777,6 +779,14 @@ static inline bool blk_write_same_mergeable(struct bio 
> *a, struct bio *b)
>   return false;
>  }
>  
> +static inline unsigned int blk_queue_depth(struct request_queue *q)
> +{
> + if (q->queue_depth)
> + return q->queue_depth;
> +
> + return q->nr_requests;
> +}
> +
>  /*
>   * q->prep_rq_fn return values
>   */
> @@ -1093,6 +1103,7 @@ extern void blk_limits_io_min(struct queue_limits 
> *limits, unsigned int min);
>  extern void blk_queue_io_min(struct request_queue *q, unsigned int min);
>  extern void blk_limits_io_opt(struct queue_limits *limits, unsigned int opt);
>  extern void blk_queue_io_opt(struct request_queue *q, unsigned int opt);
> +extern void blk_set_queue_depth(struct request_queue *q, unsigned int depth);
>  extern void blk_set_default_limits(struct queue_limits *lim);
>  extern void blk_set_stacking_limits(struct queue_limits *lim);
>  extern int blk_stack_limits(struct queue_limits *t, struct queue_limits *b,
> -- 
> 2.7.4
> 
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH 5/8] block: add code to track actual device queue depth

2016-11-05 Thread Jan Kara

On Tue 01-11-16 15:08:48, Jens Axboe wrote:
> For blk-mq, ->nr_requests does track queue depth, at least at init
> time. But for the older queue paths, it's simply a soft setting.
> On top of that, it's generally larger than the hardware setting
> on purpose, to allow backup of requests for merging.
> 
> Fill a hole in struct request with a 'queue_depth' member, that
> drivers can call to more closely inform the block layer of the
> real queue depth.
> 
> Signed-off-by: Jens Axboe 

The patch looks good to me. You can add:

Reviewed-by: Jan Kara 

Honza
> ---
>  block/blk-settings.c   | 12 
>  drivers/scsi/scsi.c|  3 +++
>  include/linux/blkdev.h | 11 +++
>  3 files changed, 26 insertions(+)
> 
> diff --git a/block/blk-settings.c b/block/blk-settings.c
> index 55369a65dea2..9cf053759363 100644
> --- a/block/blk-settings.c
> +++ b/block/blk-settings.c
> @@ -837,6 +837,18 @@ void blk_queue_flush_queueable(struct request_queue *q, 
> bool queueable)
>  EXPORT_SYMBOL_GPL(blk_queue_flush_queueable);
>  
>  /**
> + * blk_set_queue_depth - tell the block layer about the device queue depth
> + * @q:   the request queue for the device
> + * @depth:   queue depth
> + *
> + */
> +void blk_set_queue_depth(struct request_queue *q, unsigned int depth)
> +{
> + q->queue_depth = depth;
> +}
> +EXPORT_SYMBOL(blk_set_queue_depth);
> +
> +/**
>   * blk_queue_write_cache - configure queue's write cache
>   * @q:   the request queue for the device
>   * @wc:  write back cache on or off
> diff --git a/drivers/scsi/scsi.c b/drivers/scsi/scsi.c
> index 1deb6adc411f..75455d4dab68 100644
> --- a/drivers/scsi/scsi.c
> +++ b/drivers/scsi/scsi.c
> @@ -621,6 +621,9 @@ int scsi_change_queue_depth(struct scsi_device *sdev, int 
> depth)
>   wmb();
>   }
>  
> + if (sdev->request_queue)
> + blk_set_queue_depth(sdev->request_queue, depth);
> +
>   return sdev->queue_depth;
>  }
>  EXPORT_SYMBOL(scsi_change_queue_depth);
> diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> index 8396da2bb698..0c677fb35ce4 100644
> --- a/include/linux/blkdev.h
> +++ b/include/linux/blkdev.h
> @@ -405,6 +405,8 @@ struct request_queue {
>   struct blk_mq_ctx __percpu  *queue_ctx;
>   unsigned intnr_queues;
>  
> + unsigned intqueue_depth;
> +
>   /* hw dispatch queues */
>   struct blk_mq_hw_ctx**queue_hw_ctx;
>   unsigned intnr_hw_queues;
> @@ -777,6 +779,14 @@ static inline bool blk_write_same_mergeable(struct bio 
> *a, struct bio *b)
>   return false;
>  }
>  
> +static inline unsigned int blk_queue_depth(struct request_queue *q)
> +{
> + if (q->queue_depth)
> + return q->queue_depth;
> +
> + return q->nr_requests;
> +}
> +
>  /*
>   * q->prep_rq_fn return values
>   */
> @@ -1093,6 +1103,7 @@ extern void blk_limits_io_min(struct queue_limits 
> *limits, unsigned int min);
>  extern void blk_queue_io_min(struct request_queue *q, unsigned int min);
>  extern void blk_limits_io_opt(struct queue_limits *limits, unsigned int opt);
>  extern void blk_queue_io_opt(struct request_queue *q, unsigned int opt);
> +extern void blk_set_queue_depth(struct request_queue *q, unsigned int depth);
>  extern void blk_set_default_limits(struct queue_limits *lim);
>  extern void blk_set_stacking_limits(struct queue_limits *lim);
>  extern int blk_stack_limits(struct queue_limits *t, struct queue_limits *b,
> -- 
> 2.7.4
> 
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH 3/8] writeback: mark background writeback as such

2016-11-05 Thread Jan Kara

On Tue 01-11-16 15:08:46, Jens Axboe wrote:
> If we're doing background type writes, then use the appropriate
> background write flags for that.
> 
> Signed-off-by: Jens Axboe 

Looks good. You can add:

Reviewed-by: Jan Kara 

Honza

> ---
>  include/linux/writeback.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/linux/writeback.h b/include/linux/writeback.h
> index 50c96ee8108f..c78f9f0920b5 100644
> --- a/include/linux/writeback.h
> +++ b/include/linux/writeback.h
> @@ -107,6 +107,8 @@ static inline int wbc_to_write_flags(struct 
> writeback_control *wbc)
>  {
>   if (wbc->sync_mode == WB_SYNC_ALL)
>   return REQ_SYNC;
> + else if (wbc->for_kupdate || wbc->for_background)
> + return REQ_BACKGROUND;
>  
>   return 0;
>  }
> -- 
> 2.7.4
> 
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH 1/8] block: add WRITE_BACKGROUND

2016-11-05 Thread Jan Kara

On Tue 01-11-16 15:08:44, Jens Axboe wrote:
> This adds a new request flag, REQ_BACKGROUND, that callers can use to
> tell the block layer that this is background (non-urgent) IO.
> 
> Signed-off-by: Jens Axboe 

Looks good. You can add:

Reviewed-by: Jan Kara 

Honza

> ---
>  include/linux/blk_types.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
> index bb921028e7c5..562ac46cb790 100644
> --- a/include/linux/blk_types.h
> +++ b/include/linux/blk_types.h
> @@ -177,6 +177,7 @@ enum req_flag_bits {
>   __REQ_FUA,  /* forced unit access */
>   __REQ_PREFLUSH, /* request for cache flush */
>   __REQ_RAHEAD,   /* read ahead, can fail anytime */
> + __REQ_BACKGROUND,   /* background IO */
>   __REQ_NR_BITS,  /* stops here */
>  };
>  
> @@ -192,6 +193,7 @@ enum req_flag_bits {
>  #define REQ_FUA  (1ULL << __REQ_FUA)
>  #define REQ_PREFLUSH (1ULL << __REQ_PREFLUSH)
>  #define REQ_RAHEAD   (1ULL << __REQ_RAHEAD)
> +#define REQ_BACKGROUND   (1ULL << __REQ_BACKGROUND)
>  
>  #define REQ_FAILFAST_MASK \
>   (REQ_FAILFAST_DEV | REQ_FAILFAST_TRANSPORT | REQ_FAILFAST_DRIVER)
> -- 
> 2.7.4
> 
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH 3/8] writeback: mark background writeback as such

2016-11-05 Thread Jan Kara

On Tue 01-11-16 15:08:46, Jens Axboe wrote:
> If we're doing background type writes, then use the appropriate
> background write flags for that.
> 
> Signed-off-by: Jens Axboe 

Looks good. You can add:

Reviewed-by: Jan Kara 

Honza

> ---
>  include/linux/writeback.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/linux/writeback.h b/include/linux/writeback.h
> index 50c96ee8108f..c78f9f0920b5 100644
> --- a/include/linux/writeback.h
> +++ b/include/linux/writeback.h
> @@ -107,6 +107,8 @@ static inline int wbc_to_write_flags(struct 
> writeback_control *wbc)
>  {
>   if (wbc->sync_mode == WB_SYNC_ALL)
>   return REQ_SYNC;
> + else if (wbc->for_kupdate || wbc->for_background)
> + return REQ_BACKGROUND;
>  
>   return 0;
>  }
> -- 
> 2.7.4
> 
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH 1/8] block: add WRITE_BACKGROUND

2016-11-05 Thread Jan Kara

On Tue 01-11-16 15:08:44, Jens Axboe wrote:
> This adds a new request flag, REQ_BACKGROUND, that callers can use to
> tell the block layer that this is background (non-urgent) IO.
> 
> Signed-off-by: Jens Axboe 

Looks good. You can add:

Reviewed-by: Jan Kara 

Honza

> ---
>  include/linux/blk_types.h | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/include/linux/blk_types.h b/include/linux/blk_types.h
> index bb921028e7c5..562ac46cb790 100644
> --- a/include/linux/blk_types.h
> +++ b/include/linux/blk_types.h
> @@ -177,6 +177,7 @@ enum req_flag_bits {
>   __REQ_FUA,  /* forced unit access */
>   __REQ_PREFLUSH, /* request for cache flush */
>   __REQ_RAHEAD,   /* read ahead, can fail anytime */
> + __REQ_BACKGROUND,   /* background IO */
>   __REQ_NR_BITS,  /* stops here */
>  };
>  
> @@ -192,6 +193,7 @@ enum req_flag_bits {
>  #define REQ_FUA  (1ULL << __REQ_FUA)
>  #define REQ_PREFLUSH (1ULL << __REQ_PREFLUSH)
>  #define REQ_RAHEAD   (1ULL << __REQ_RAHEAD)
> +#define REQ_BACKGROUND   (1ULL << __REQ_BACKGROUND)
>  
>  #define REQ_FAILFAST_MASK \
>   (REQ_FAILFAST_DEV | REQ_FAILFAST_TRANSPORT | REQ_FAILFAST_DRIVER)
> -- 
> 2.7.4
> 
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH] clk: rockchip: Ignore frac divisor for PLL equivalence when it's unused

2016-11-05 Thread Heiko Stuebner

Am Mittwoch, 2. November 2016, 16:43:24 CET schrieb Julius Werner:
> Rockchip RK3399 PLLs can be used in two separate modes: integral and
> fractional. We can select between these two modes with the unambiguously
> named DSMPD bit.
> 
> During boot, we check all PLL settings to confirm that they match our
> PLL table for that frequency, and reinitialize the PLLs where they
> don't. The settings checked for this include the fractional divider
> field that is only used in fractional mode, even if we're in integral
> mode (DSMPD = 1) and that field has no effect.
> 
> This patch changes the check to only compare the fractional divider if
> we're actually in fractional mode. This way, we won't reinitialize the
> PLL in cases where there's absolutely no reason for that, which may
> avoid glitching child clocks that should better not be glitched (e.g.
> PWM regulators).
> 
> Signed-off-by: Julius Werner 

I took the liberty to clone the fix to the rk3036 pll type as well, which is
quite similar and only differs in the actual register layout.

As sugested by the above, I've applied this to my clk branch for 4.10 [0]


Thanks for fixing this
Heiko


[0] 
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/commit/?id=bf92384b6d729b22916ba832b4a225ca196e98ba

Re: [PATCH] clk: rockchip: Ignore frac divisor for PLL equivalence when it's unused

2016-11-05 Thread Heiko Stuebner

Am Mittwoch, 2. November 2016, 16:43:24 CET schrieb Julius Werner:
> Rockchip RK3399 PLLs can be used in two separate modes: integral and
> fractional. We can select between these two modes with the unambiguously
> named DSMPD bit.
> 
> During boot, we check all PLL settings to confirm that they match our
> PLL table for that frequency, and reinitialize the PLLs where they
> don't. The settings checked for this include the fractional divider
> field that is only used in fractional mode, even if we're in integral
> mode (DSMPD = 1) and that field has no effect.
> 
> This patch changes the check to only compare the fractional divider if
> we're actually in fractional mode. This way, we won't reinitialize the
> PLL in cases where there's absolutely no reason for that, which may
> avoid glitching child clocks that should better not be glitched (e.g.
> PWM regulators).
> 
> Signed-off-by: Julius Werner 

I took the liberty to clone the fix to the rk3036 pll type as well, which is
quite similar and only differs in the actual register layout.

As sugested by the above, I've applied this to my clk branch for 4.10 [0]


Thanks for fixing this
Heiko


[0] 
https://git.kernel.org/cgit/linux/kernel/git/mmind/linux-rockchip.git/commit/?id=bf92384b6d729b22916ba832b4a225ca196e98ba

[PULL REQUEST] i2c for 4.9

2016-11-05 Thread Wolfram Sang

Linus,

here is a bugfix for the I2C core fixing a (rare) race condition.

Please pull.

Thanks,

   Wolfram


The following changes since commit a909d3e636995ba7c349e2ca5dbb528154d4ac30:

  Linux 4.9-rc3 (2016-10-29 13:52:02 -0700)

are available in the git repository at:

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

for you to fetch changes up to 147b36d5b70c083cc76770c47d60b347e8eaf231:

  i2c: core: fix NULL pointer dereference under race condition (2016-11-04 
20:36:58 +0100)


Vladimir Zapolskiy (1):
  i2c: core: fix NULL pointer dereference under race condition

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


signature.asc
Description: PGP signature

[PULL REQUEST] i2c for 4.9

2016-11-05 Thread Wolfram Sang

Linus,

here is a bugfix for the I2C core fixing a (rare) race condition.

Please pull.

Thanks,

   Wolfram


The following changes since commit a909d3e636995ba7c349e2ca5dbb528154d4ac30:

  Linux 4.9-rc3 (2016-10-29 13:52:02 -0700)

are available in the git repository at:

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

for you to fetch changes up to 147b36d5b70c083cc76770c47d60b347e8eaf231:

  i2c: core: fix NULL pointer dereference under race condition (2016-11-04 
20:36:58 +0100)


Vladimir Zapolskiy (1):
  i2c: core: fix NULL pointer dereference under race condition

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


signature.asc
Description: PGP signature

Re: [PATCH] clk: rockchip: remove more CLK_IGNORE_UNUSED for rk3399 clocktree

2016-11-05 Thread Heiko Stuebner

Am Donnerstag, 3. November 2016, 11:38:53 CET schrieb Jianqun Xu:
> Optimize rk3399 clocktree by removing CLK_IGNORE_UNUSED of some clocks.
> 
> clocks will managered by usb:
> - clk_usbphy0_480m_src
> - clk_usbphy1_480m_src
> - clk_usbphy_480m
> 
> clocks will be managered by pvtm:
> - clk_pvtm_core_l
> - clk_pvtm_core_b
> - clk_pvtm_ddr
> 
> clocks will be managered by dfi:
> - pclk_ddr_mon
> - clk_dfimon0_timer
> - clk_dfimon1_timer
> - aclk_dcf
> - pclk_dcf
> 
> Signed-off-by: Jianqun Xu 

I gave this a test on a rk3399-gru device and was still able to boot 
sucessfully. So I've applied the patch to my clk-branch for 4.10

Thanks
Heiko

Re: [PATCH] clk: rockchip: remove more CLK_IGNORE_UNUSED for rk3399 clocktree

2016-11-05 Thread Heiko Stuebner

Am Donnerstag, 3. November 2016, 11:38:53 CET schrieb Jianqun Xu:
> Optimize rk3399 clocktree by removing CLK_IGNORE_UNUSED of some clocks.
> 
> clocks will managered by usb:
> - clk_usbphy0_480m_src
> - clk_usbphy1_480m_src
> - clk_usbphy_480m
> 
> clocks will be managered by pvtm:
> - clk_pvtm_core_l
> - clk_pvtm_core_b
> - clk_pvtm_ddr
> 
> clocks will be managered by dfi:
> - pclk_ddr_mon
> - clk_dfimon0_timer
> - clk_dfimon1_timer
> - aclk_dcf
> - pclk_dcf
> 
> Signed-off-by: Jianqun Xu 

I gave this a test on a rk3399-gru device and was still able to boot 
sucessfully. So I've applied the patch to my clk-branch for 4.10

Thanks
Heiko

fsl_spdif.c:undefined reference to `byte_rev_table'

2016-11-05 Thread kbuild test robot

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   fb415f222c26d0d1fa19615af1d102bf5f5b3ca2
commit: 8cfc8ddc99df9509a46043b14af81f5c6a223eab pstore: add lzo/lz4 
compression support
date:   5 months ago
config: x86_64-randconfig-x001-201645 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 8cfc8ddc99df9509a46043b14af81f5c6a223eab
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   sound/built-in.o: In function `spdif_write_channel_status':
>> fsl_spdif.c:(.text+0xf3fd5): undefined reference to `byte_rev_table'
   fsl_spdif.c:(.text+0xf3fe0): undefined reference to `byte_rev_table'
   fsl_spdif.c:(.text+0xf3ff3): undefined reference to `byte_rev_table'
   fsl_spdif.c:(.text+0xf400d): undefined reference to `byte_rev_table'

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


.config.gz
Description: application/gzip

fsl_spdif.c:undefined reference to `byte_rev_table'

2016-11-05 Thread kbuild test robot

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   fb415f222c26d0d1fa19615af1d102bf5f5b3ca2
commit: 8cfc8ddc99df9509a46043b14af81f5c6a223eab pstore: add lzo/lz4 
compression support
date:   5 months ago
config: x86_64-randconfig-x001-201645 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 8cfc8ddc99df9509a46043b14af81f5c6a223eab
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   sound/built-in.o: In function `spdif_write_channel_status':
>> fsl_spdif.c:(.text+0xf3fd5): undefined reference to `byte_rev_table'
   fsl_spdif.c:(.text+0xf3fe0): undefined reference to `byte_rev_table'
   fsl_spdif.c:(.text+0xf3ff3): undefined reference to `byte_rev_table'
   fsl_spdif.c:(.text+0xf400d): undefined reference to `byte_rev_table'

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


.config.gz
Description: application/gzip

Re: fsnotify_mark_srcu wtf?

2016-11-05 Thread Jan Kara

On Thu 03-11-16 12:25:13, Amir Goldstein wrote:
> On Thu, Nov 3, 2016 at 12:09 AM, Miklos Szeredi  wrote:
> > We've got a report where a fanotify daemon that implements permission checks
> > screws up and doesn't send a reply.  This then causes widespread hangs due 
> > to
> > fsnotify_mark_srcu read side lock being held and thus causing 
> > synchronize_srcu()
> > called from e.g. inotify_release()-> fsnotify_destroy_group()->
> > fsnotify_mark_destroy_list() to block.
> >
> > Below program demonstrates the issue.  It should output a single line:
> >
> > close(inotify_fd): success
> >
> > Instead it outputs nothing, which means that close(inotify_fd) got blocked 
> > by
> > the waiting permission event.
> >
> > Wouldn't making the srcu per-group fix this?  Would that be too expensive?
> >
> 
> IIUC, the purpose of fsnotify_mark_srcu is to protect the inode and vfsmount
> mark lists, which are used to iterate the groups to send events to.
> So you cannot make it per group as far as I can tell.
> 
> OTOH, specifically, for fanotify, once you can passed
> fanotify_should_send_event(),
> there is no need to keep a reference to the mark, so it may be safely 
> destroyed,
> you only need a reference to the group.
> 
> I tested this patch on top of my fanotify super block watch development branch
> and it seems to fix the problem you reported, but I am not savvy enough with
> srcu to say that this is correct.
> Jan, what do you think?

So the way you've written it is definitely buggy. The inode_node and
vfsmount_node pointers may become invalid once you drop SRCU lock and so
you cannot dereference them even after regaining that lock. Also frankly
your solution looks a bit ugly. I'll think whether we can somehow fix the
problem...

Honza

> 
> From 28da34cdf9bf71fe9bbac13ded11a19da3b7a48e Mon Sep 17 00:00:00 2001
> From: Amir Goldstein 
> Date: Thu, 3 Nov 2016 11:55:46 +0200
> Subject: [PATCH] fanotify: handle permission events without holding
>  fsnotify_mark_srcu
> 
> Handling fanotify events does not entail dereferencing fsnotify_mask
> beyond the point of fanotify_should_send_event().
> 
> For the case of permission events, which may block indefinetely,
> return -EAGAIN and then fsnotify() will call handle_event() again
> without a reference to the mark.
> 
> Without a reference to the mark, there is no need to call
> handle_event() under fsnotify_mark_srcu read side lock
> which is protecting the inode/vfsmount mark lists.
> We just need to hold a reference to the group
> 
> Signed-off-by: Amir Goldstein 
> ---
>  fs/notify/fanotify/fanotify.c | 14 +++---
>  fs/notify/fsnotify.c  | 26 ++
>  2 files changed, 33 insertions(+), 7 deletions(-)
> 
> diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> index 604e307..0ffa9ed 100644
> --- a/fs/notify/fanotify/fanotify.c
> +++ b/fs/notify/fanotify/fanotify.c
> @@ -298,9 +298,17 @@ static int fanotify_handle_event(struct
> fsnotify_group *group,
> BUILD_BUG_ON(FAN_ACCESS_PERM != FS_ACCESS_PERM);
> BUILD_BUG_ON(FAN_ONDIR != FS_ISDIR);
> 
> -   if (!fanotify_should_send_event(inode_mark, vfsmnt_mark, mask, data
> -   data_type))
> -   return 0;
> +   if (inode_mark || vfsmnt_mark) {
> +   if (!fanotify_should_send_event(inode_mark, vfsmnt_mark, mask,
> +   data, data_type))
> +   return 0;
> +
> +#ifdef CONFIG_FANOTIFY_ACCESS_PERMISSIONS
> +   /* Ask to be called again without a reference to mark */
> +   if (mask & FAN_ALL_PERM_EVENTS)
> +   return -EAGAIN;
> +#endif
> +   }
> 
> pr_debug("%s: group=%p inode=%p mask=%x\n", __func__, group, inode,
>  mask);
> diff --git a/fs/notify/fsnotify.c b/fs/notify/fsnotify.c
> index 34bccbe..dc0c86e 100644
> --- a/fs/notify/fsnotify.c
> +++ b/fs/notify/fsnotify.c
> @@ -199,7 +199,7 @@ int fsnotify(struct inode *to_tell, __u32 mask,
> void *data, int data_is,
>  {
> struct hlist_node *inode_node = NULL, *vfsmount_node = NULL;
> struct fsnotify_mark *inode_mark = NULL, *vfsmount_mark = NULL;
> -   struct fsnotify_group *inode_group, *vfsmount_group;
> +   struct fsnotify_group *inode_group, *vfsmount_group, *group;
> struct mount *mnt;
> int idx, ret = 0;
> /* global tests shouldn't care about events on child only the
> specific event */
> @@ -282,15 +282,33 @@ int fsnotify(struct inode *to_tell, __u32 mask,
> void *data, int data_is,
> ret = send_to_group(to_tell, inode_mark, vfsmount_mark, mask,
> data, data_is, cookie, file_name);
> 
> -   if (ret && (mask & ALL_FSNOTIFY_PERM_EVENTS))
> -   goto

Re: fsnotify_mark_srcu wtf?

2016-11-05 Thread Jan Kara

On Thu 03-11-16 12:25:13, Amir Goldstein wrote:
> On Thu, Nov 3, 2016 at 12:09 AM, Miklos Szeredi  wrote:
> > We've got a report where a fanotify daemon that implements permission checks
> > screws up and doesn't send a reply.  This then causes widespread hangs due 
> > to
> > fsnotify_mark_srcu read side lock being held and thus causing 
> > synchronize_srcu()
> > called from e.g. inotify_release()-> fsnotify_destroy_group()->
> > fsnotify_mark_destroy_list() to block.
> >
> > Below program demonstrates the issue.  It should output a single line:
> >
> > close(inotify_fd): success
> >
> > Instead it outputs nothing, which means that close(inotify_fd) got blocked 
> > by
> > the waiting permission event.
> >
> > Wouldn't making the srcu per-group fix this?  Would that be too expensive?
> >
> 
> IIUC, the purpose of fsnotify_mark_srcu is to protect the inode and vfsmount
> mark lists, which are used to iterate the groups to send events to.
> So you cannot make it per group as far as I can tell.
> 
> OTOH, specifically, for fanotify, once you can passed
> fanotify_should_send_event(),
> there is no need to keep a reference to the mark, so it may be safely 
> destroyed,
> you only need a reference to the group.
> 
> I tested this patch on top of my fanotify super block watch development branch
> and it seems to fix the problem you reported, but I am not savvy enough with
> srcu to say that this is correct.
> Jan, what do you think?

So the way you've written it is definitely buggy. The inode_node and
vfsmount_node pointers may become invalid once you drop SRCU lock and so
you cannot dereference them even after regaining that lock. Also frankly
your solution looks a bit ugly. I'll think whether we can somehow fix the
problem...

Honza

> 
> From 28da34cdf9bf71fe9bbac13ded11a19da3b7a48e Mon Sep 17 00:00:00 2001
> From: Amir Goldstein 
> Date: Thu, 3 Nov 2016 11:55:46 +0200
> Subject: [PATCH] fanotify: handle permission events without holding
>  fsnotify_mark_srcu
> 
> Handling fanotify events does not entail dereferencing fsnotify_mask
> beyond the point of fanotify_should_send_event().
> 
> For the case of permission events, which may block indefinetely,
> return -EAGAIN and then fsnotify() will call handle_event() again
> without a reference to the mark.
> 
> Without a reference to the mark, there is no need to call
> handle_event() under fsnotify_mark_srcu read side lock
> which is protecting the inode/vfsmount mark lists.
> We just need to hold a reference to the group
> 
> Signed-off-by: Amir Goldstein 
> ---
>  fs/notify/fanotify/fanotify.c | 14 +++---
>  fs/notify/fsnotify.c  | 26 ++
>  2 files changed, 33 insertions(+), 7 deletions(-)
> 
> diff --git a/fs/notify/fanotify/fanotify.c b/fs/notify/fanotify/fanotify.c
> index 604e307..0ffa9ed 100644
> --- a/fs/notify/fanotify/fanotify.c
> +++ b/fs/notify/fanotify/fanotify.c
> @@ -298,9 +298,17 @@ static int fanotify_handle_event(struct
> fsnotify_group *group,
> BUILD_BUG_ON(FAN_ACCESS_PERM != FS_ACCESS_PERM);
> BUILD_BUG_ON(FAN_ONDIR != FS_ISDIR);
> 
> -   if (!fanotify_should_send_event(inode_mark, vfsmnt_mark, mask, data
> -   data_type))
> -   return 0;
> +   if (inode_mark || vfsmnt_mark) {
> +   if (!fanotify_should_send_event(inode_mark, vfsmnt_mark, mask,
> +   data, data_type))
> +   return 0;
> +
> +#ifdef CONFIG_FANOTIFY_ACCESS_PERMISSIONS
> +   /* Ask to be called again without a reference to mark */
> +   if (mask & FAN_ALL_PERM_EVENTS)
> +   return -EAGAIN;
> +#endif
> +   }
> 
> pr_debug("%s: group=%p inode=%p mask=%x\n", __func__, group, inode,
>  mask);
> diff --git a/fs/notify/fsnotify.c b/fs/notify/fsnotify.c
> index 34bccbe..dc0c86e 100644
> --- a/fs/notify/fsnotify.c
> +++ b/fs/notify/fsnotify.c
> @@ -199,7 +199,7 @@ int fsnotify(struct inode *to_tell, __u32 mask,
> void *data, int data_is,
>  {
> struct hlist_node *inode_node = NULL, *vfsmount_node = NULL;
> struct fsnotify_mark *inode_mark = NULL, *vfsmount_mark = NULL;
> -   struct fsnotify_group *inode_group, *vfsmount_group;
> +   struct fsnotify_group *inode_group, *vfsmount_group, *group;
> struct mount *mnt;
> int idx, ret = 0;
> /* global tests shouldn't care about events on child only the
> specific event */
> @@ -282,15 +282,33 @@ int fsnotify(struct inode *to_tell, __u32 mask,
> void *data, int data_is,
> ret = send_to_group(to_tell, inode_mark, vfsmount_mark, mask,
> data, data_is, cookie, file_name);
> 
> -   if (ret && (mask & ALL_FSNOTIFY_PERM_EVENTS))
> -   goto out;
> -
> if (inode_group)
>

Re: fsnotify_mark_srcu wtf?

2016-11-05 Thread Jan Kara

On Wed 02-11-16 23:09:26, Miklos Szeredi wrote:
> We've got a report where a fanotify daemon that implements permission checks
> screws up and doesn't send a reply.  This then causes widespread hangs due to
> fsnotify_mark_srcu read side lock being held and thus causing 
> synchronize_srcu()
> called from e.g. inotify_release()-> fsnotify_destroy_group()->
> fsnotify_mark_destroy_list() to block.

Yes. But if a program implementing permission checks does not reply, your
system is likely hosed anyway. We can only try to somewhat limit the
damage...

> Below program demonstrates the issue.  It should output a single line:
> 
> close(inotify_fd): success
> 
> Instead it outputs nothing, which means that close(inotify_fd) got blocked by
> the waiting permission event.
> 
> Wouldn't making the srcu per-group fix this?  Would that be too expensive?

Per-group would be IMHO too expensive. You can have lots of groups and I'm
not sure srcu would scale to that. Furthermore the SRCU protects the list
of groups that need to get notification so it would not even be easily
possible. Also Amir's solution is buggy - I'll comment on that as a reply
to his patch. I'll try to find something to improve the situation but so
far I have no good idea...

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: fsnotify_mark_srcu wtf?

2016-11-05 Thread Jan Kara

On Wed 02-11-16 23:09:26, Miklos Szeredi wrote:
> We've got a report where a fanotify daemon that implements permission checks
> screws up and doesn't send a reply.  This then causes widespread hangs due to
> fsnotify_mark_srcu read side lock being held and thus causing 
> synchronize_srcu()
> called from e.g. inotify_release()-> fsnotify_destroy_group()->
> fsnotify_mark_destroy_list() to block.

Yes. But if a program implementing permission checks does not reply, your
system is likely hosed anyway. We can only try to somewhat limit the
damage...

> Below program demonstrates the issue.  It should output a single line:
> 
> close(inotify_fd): success
> 
> Instead it outputs nothing, which means that close(inotify_fd) got blocked by
> the waiting permission event.
> 
> Wouldn't making the srcu per-group fix this?  Would that be too expensive?

Per-group would be IMHO too expensive. You can have lots of groups and I'm
not sure srcu would scale to that. Furthermore the SRCU protects the list
of groups that need to get notification so it would not even be easily
possible. Also Amir's solution is buggy - I'll comment on that as a reply
to his patch. I'll try to find something to improve the situation but so
far I have no good idea...

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: [GIT PULL] overlayfs fixes for 4.9-rc3

2016-11-05 Thread Linus Torvalds

On Sat, Nov 5, 2016 at 12:45 PM, Miklos Szeredi  wrote:
>
> The feature that would be introduced is this: allow directory renames
> to work without having to recursively copy-up the subtree.  Whatever
> mechanism is devised to do this will be backward incompatible.  Maybe
> it's a misguided idea, but it's been through several rounds of reviews
> on the relevant mailing lists and there weren't any objections (yet).
>
> And the thing is, backward incompatibility is less of an issue for
> overlayfs than for normal filesystems, because it's usually not
> something people store their root filesystems on, and if so they can
> simply not turn off this feature.

(a) that should be explained

(b) that has nothing to do with being marked for stable

(c) that new doesn't actually explain in any way why you'd want
"feature flags" thing, for exactly the same "backwards incompatibility
is less of an issue" reason that you state.

Why not "just do it", in other words. For exactly the reasons you say.
Make it a mount option that people can choose to use or not.

> overlayfs relies on xattr to create opaque directories

Yes and no. It relies on it for THAT ONE FEATURE, which you don't have
to use. As far as I can tell, overlayfs does *not* rely on xattrs in
general.

   Linus

Re: [GIT PULL] overlayfs fixes for 4.9-rc3

2016-11-05 Thread Linus Torvalds

On Sat, Nov 5, 2016 at 12:45 PM, Miklos Szeredi  wrote:
>
> The feature that would be introduced is this: allow directory renames
> to work without having to recursively copy-up the subtree.  Whatever
> mechanism is devised to do this will be backward incompatible.  Maybe
> it's a misguided idea, but it's been through several rounds of reviews
> on the relevant mailing lists and there weren't any objections (yet).
>
> And the thing is, backward incompatibility is less of an issue for
> overlayfs than for normal filesystems, because it's usually not
> something people store their root filesystems on, and if so they can
> simply not turn off this feature.

(a) that should be explained

(b) that has nothing to do with being marked for stable

(c) that new doesn't actually explain in any way why you'd want
"feature flags" thing, for exactly the same "backwards incompatibility
is less of an issue" reason that you state.

Why not "just do it", in other words. For exactly the reasons you say.
Make it a mount option that people can choose to use or not.

> overlayfs relies on xattr to create opaque directories

Yes and no. It relies on it for THAT ONE FEATURE, which you don't have
to use. As far as I can tell, overlayfs does *not* rely on xattrs in
general.

   Linus

Re: [PATCH v3 0/2] Add TI SCI Reset Driver

2016-11-05 Thread santosh.shilim...@oracle.com




On 11/4/16 11:42 AM, Andrew F. Davis wrote:

Hello all,

This series adds a reset controller driver that uses the TI SCI
protocol to manage resets.

The TI SCI protocol is used to communicate with power management
controllers used by some SoCs. These controllers manage the various
power domains, clocks, and resets available on a SoC.

This series is based on drivers for TI SCI and the first two controlled
elements above, these series can be found here:

TI-SCI: http://www.spinics.net/lists/arm-kernel/msg536851.html
PM Domains: http://www.spinics.net/lists/devicetree/msg146621.html
Clocks: https://www.spinics.net/lists/linux-clk/msg12785.html

Thanks,
Andrew

Changes from v2:
 - Merged DT binding patch and reset header patch
 - Added locking for reset bit mask

Changes from v1:
 - Revised dt binding
 - CC Linux ARM list

Andrew F. Davis (2):
  Documentation: dt: reset: Add TI SCI reset binding
  reset: Add the TI SCI reset driver


Acked-by: Santosh Shilimkar

Re: [PATCH v3 0/2] Add TI SCI Reset Driver

2016-11-05 Thread santosh.shilim...@oracle.com




On 11/4/16 11:42 AM, Andrew F. Davis wrote:

Hello all,

This series adds a reset controller driver that uses the TI SCI
protocol to manage resets.

The TI SCI protocol is used to communicate with power management
controllers used by some SoCs. These controllers manage the various
power domains, clocks, and resets available on a SoC.

This series is based on drivers for TI SCI and the first two controlled
elements above, these series can be found here:

TI-SCI: http://www.spinics.net/lists/arm-kernel/msg536851.html
PM Domains: http://www.spinics.net/lists/devicetree/msg146621.html
Clocks: https://www.spinics.net/lists/linux-clk/msg12785.html

Thanks,
Andrew

Changes from v2:
 - Merged DT binding patch and reset header patch
 - Added locking for reset bit mask

Changes from v1:
 - Revised dt binding
 - CC Linux ARM list

Andrew F. Davis (2):
  Documentation: dt: reset: Add TI SCI reset binding
  reset: Add the TI SCI reset driver


Acked-by: Santosh Shilimkar

Re: [PATCH 1/4] block: add scalable completion tracking of requests

2016-11-05 Thread Jens Axboe


On 11/04/2016 05:13 PM, Ming Lei wrote:

Yes, that might be a good idea, since it doesn't cost us anything.
For the mq case, I'm hard pressed to think of areas where we could
complete IO in parallel on the same software queue. You'll never have
a software queue mapped to multiple hardware queues. So we should
essentially be serialized.


For blk-mq, blk_mq_stat_add() is called in __blk_mq_complete_request()
which is often run from interrupt handler, and the CPU serving the
interrupt can be different with the submitting CPU for rq->mq_ctx. And
there can be several CPUs handling the interrupts originating from
same sw queue.


BTW, one small improvement might be to call blk_mq_stat_add() on the
curent ctx, in case it's different than rq->mq_ctx. That can happen if
we have multiple CPUs per hardware queue. In reality, even for that
case, a real race is rare. You'd have to rebalance interrupt masks
basically, at least on x86 where multiple CPUs in the IRQ affinity mask
still always trigger on the first one.

So while we could just grab the current ctx instead, I don't think it's
going to make a difference in practice.


--
Jens Axboe

Re: [PATCH 1/4] block: add scalable completion tracking of requests

2016-11-05 Thread Jens Axboe


On 11/04/2016 05:13 PM, Ming Lei wrote:

Yes, that might be a good idea, since it doesn't cost us anything.
For the mq case, I'm hard pressed to think of areas where we could
complete IO in parallel on the same software queue. You'll never have
a software queue mapped to multiple hardware queues. So we should
essentially be serialized.


For blk-mq, blk_mq_stat_add() is called in __blk_mq_complete_request()
which is often run from interrupt handler, and the CPU serving the
interrupt can be different with the submitting CPU for rq->mq_ctx. And
there can be several CPUs handling the interrupts originating from
same sw queue.


BTW, one small improvement might be to call blk_mq_stat_add() on the
curent ctx, in case it's different than rq->mq_ctx. That can happen if
we have multiple CPUs per hardware queue. In reality, even for that
case, a real race is rare. You'd have to rebalance interrupt masks
basically, at least on x86 where multiple CPUs in the IRQ affinity mask
still always trigger on the first one.

So while we could just grab the current ctx instead, I don't think it's
going to make a difference in practice.


--
Jens Axboe

Re: [PATCH 1/4] block: add scalable completion tracking of requests

2016-11-05 Thread Jens Axboe


On 11/04/2016 05:13 PM, Ming Lei wrote:

Even though it is true, the statistics still may become a mess with rare
collisons.



How so? Not saying we could not improve it, but we're trading off
precision for scalability. My claim is that the existing code is good
enough. I've run a TON of testing on it, since I've used it for multiple
projects, and it's been solid.


+static void blk_stat_flush_batch(struct blk_rq_stat *stat)
+{
+   if (!stat->nr_batch)
+   return;
+   if (!stat->nr_samples)
+   stat->mean = div64_s64(stat->batch, stat->nr_batch);

For example, two reqs(A & B) are completed at the same time, and A is
on CPU0, and B is on CPU1.

If the two last writting in the function is reordered observed from
CPU1, for B, CPU1 runs the above branch when it just sees stat->batch
is set as zero, but nr_samples isn't updated yet, then div_zero is
triggered.


We should probably just have the nr_batch be a READ_ONCE(). I'm fine
with the stats being a bit off in the rare case of a collision, but we
can't have a divide-by-zero, obviously.



+   else {
+   stat->mean = div64_s64((stat->mean * stat->nr_samples) +
+   stat->batch,
+   stat->nr_samples + stat->nr_batch);
+   }

BTW, the above 'if else' can be removed, and 'stat->mean' can be computed
in the 2nd way.


True, they could be collapsed.


Yes, that might be a good idea, since it doesn't cost us anything. For
the mq case, I'm hard pressed to think of areas where we could complete
IO in parallel on the same software queue. You'll never have a software
queue mapped to multiple hardware queues. So we should essentially be
serialized.


For blk-mq, blk_mq_stat_add() is called in __blk_mq_complete_request()
which is often run from interrupt handler, and the CPU serving the interrupt
can be different with the submitting CPU for rq->mq_ctx. And there can be
several CPUs handling the interrupts originating from same sw queue.

BTW, I don't object to this patch actually, but maybe we should add
comment about this kind of race. Cause in the future someone might find
the statistics becomes not accurate, and they may understand or
try to improve.


I'm fine with documenting it. For the two use cases I have, I'm fine
with it not being 100% stable. For by far the majority of the windows,
it'll be just fine. I'll fix the divide-by-zero, though.

--
Jens Axboe

Re: [PATCH 1/4] block: add scalable completion tracking of requests

2016-11-05 Thread Jens Axboe


On 11/04/2016 05:13 PM, Ming Lei wrote:

Even though it is true, the statistics still may become a mess with rare
collisons.



How so? Not saying we could not improve it, but we're trading off
precision for scalability. My claim is that the existing code is good
enough. I've run a TON of testing on it, since I've used it for multiple
projects, and it's been solid.


+static void blk_stat_flush_batch(struct blk_rq_stat *stat)
+{
+   if (!stat->nr_batch)
+   return;
+   if (!stat->nr_samples)
+   stat->mean = div64_s64(stat->batch, stat->nr_batch);

For example, two reqs(A & B) are completed at the same time, and A is
on CPU0, and B is on CPU1.

If the two last writting in the function is reordered observed from
CPU1, for B, CPU1 runs the above branch when it just sees stat->batch
is set as zero, but nr_samples isn't updated yet, then div_zero is
triggered.


We should probably just have the nr_batch be a READ_ONCE(). I'm fine
with the stats being a bit off in the rare case of a collision, but we
can't have a divide-by-zero, obviously.



+   else {
+   stat->mean = div64_s64((stat->mean * stat->nr_samples) +
+   stat->batch,
+   stat->nr_samples + stat->nr_batch);
+   }

BTW, the above 'if else' can be removed, and 'stat->mean' can be computed
in the 2nd way.


True, they could be collapsed.


Yes, that might be a good idea, since it doesn't cost us anything. For
the mq case, I'm hard pressed to think of areas where we could complete
IO in parallel on the same software queue. You'll never have a software
queue mapped to multiple hardware queues. So we should essentially be
serialized.


For blk-mq, blk_mq_stat_add() is called in __blk_mq_complete_request()
which is often run from interrupt handler, and the CPU serving the interrupt
can be different with the submitting CPU for rq->mq_ctx. And there can be
several CPUs handling the interrupts originating from same sw queue.

BTW, I don't object to this patch actually, but maybe we should add
comment about this kind of race. Cause in the future someone might find
the statistics becomes not accurate, and they may understand or
try to improve.


I'm fine with documenting it. For the two use cases I have, I'm fine
with it not being 100% stable. For by far the majority of the windows,
it'll be just fine. I'll fix the divide-by-zero, though.

--
Jens Axboe

Re: [PATCH 1/3] ovl: check fs features

2016-11-05 Thread Amir Goldstein

On Tue, Oct 25, 2016 at 2:24 PM, Amir Goldstein  wrote:
> On Tue, Oct 25, 2016 at 10:34 AM, Miklos Szeredi  wrote:
>> To allow adding new, backward incompatible features to overlayfs, we need a
>> way to store the list of features in the overlay.  This is done via
>> "trusted.overlay.features" xattr on the root of the upper layer (or one of
>> the lower layers, that previously acted as an upper layer).  It's a comma
>> separated list of case sensitive strings.
>>
>> If an overlay has an unknown feature, mount shall return an error.  So
>> mechanism should only be used for backward incompatible features.
>
> So maybe be explicit and call the attribute trusted.overlay.incompat_features,
> to allow future addition of compat and rocompat feature sets?
>

On top of the proposed features xattr,
for the sake of being backward compatible with old kernels,
how about creating a file 3 levels down from work dir (e.g. /work/work/a/b/c)
This would cause old kernels to mount overlay read-only,
which is sufficient to keep them from corrupting the redirect structure.

And once again, I suggest learning from the elders fs, who have
successfully gone through many on-disk format upgrades,
and copy the design of the feature trio (compat/incompat/rocompat)

Amir.

Re: [PATCH 1/3] ovl: check fs features

2016-11-05 Thread Amir Goldstein

On Tue, Oct 25, 2016 at 2:24 PM, Amir Goldstein  wrote:
> On Tue, Oct 25, 2016 at 10:34 AM, Miklos Szeredi  wrote:
>> To allow adding new, backward incompatible features to overlayfs, we need a
>> way to store the list of features in the overlay.  This is done via
>> "trusted.overlay.features" xattr on the root of the upper layer (or one of
>> the lower layers, that previously acted as an upper layer).  It's a comma
>> separated list of case sensitive strings.
>>
>> If an overlay has an unknown feature, mount shall return an error.  So
>> mechanism should only be used for backward incompatible features.
>
> So maybe be explicit and call the attribute trusted.overlay.incompat_features,
> to allow future addition of compat and rocompat feature sets?
>

On top of the proposed features xattr,
for the sake of being backward compatible with old kernels,
how about creating a file 3 levels down from work dir (e.g. /work/work/a/b/c)
This would cause old kernels to mount overlay read-only,
which is sufficient to keep them from corrupting the redirect structure.

And once again, I suggest learning from the elders fs, who have
successfully gone through many on-disk format upgrades,
and copy the design of the feature trio (compat/incompat/rocompat)

Amir.

[PATCH] Staging: vme: vme_pio2: Prefer using the BIT macro

2016-11-05 Thread Shiva Kerdel

Replace all occurences of (1 << x) by BIT(x) in the file vme_pio2.h to
get rid of checkpatch.pl "check" output "Prefer using the BIT macro".

Signed-off-by: Shiva Kerdel 
---
 drivers/staging/vme/devices/vme_pio2.h | 86 +-
 1 file changed, 43 insertions(+), 43 deletions(-)

diff --git a/drivers/staging/vme/devices/vme_pio2.h 
b/drivers/staging/vme/devices/vme_pio2.h
index d5d94c4..495b698 100644
--- a/drivers/staging/vme/devices/vme_pio2.h
+++ b/drivers/staging/vme/devices/vme_pio2.h
@@ -71,38 +71,38 @@ static const int PIO2_CHANNEL_BANK[32] = { 0, 0, 0, 0, 0, 
0, 0, 0,
2, 2, 2, 2, 2, 2, 2, 2,
3, 3, 3, 3, 3, 3, 3, 3 };
 
-#define PIO2_CHANNEL0_BIT  (1 << 0)
-#define PIO2_CHANNEL1_BIT  (1 << 1)
-#define PIO2_CHANNEL2_BIT  (1 << 2)
-#define PIO2_CHANNEL3_BIT  (1 << 3)
-#define PIO2_CHANNEL4_BIT  (1 << 4)
-#define PIO2_CHANNEL5_BIT  (1 << 5)
-#define PIO2_CHANNEL6_BIT  (1 << 6)
-#define PIO2_CHANNEL7_BIT  (1 << 7)
-#define PIO2_CHANNEL8_BIT  (1 << 0)
-#define PIO2_CHANNEL9_BIT  (1 << 1)
-#define PIO2_CHANNEL10_BIT (1 << 2)
-#define PIO2_CHANNEL11_BIT (1 << 3)
-#define PIO2_CHANNEL12_BIT (1 << 4)
-#define PIO2_CHANNEL13_BIT (1 << 5)
-#define PIO2_CHANNEL14_BIT (1 << 6)
-#define PIO2_CHANNEL15_BIT (1 << 7)
-#define PIO2_CHANNEL16_BIT (1 << 0)
-#define PIO2_CHANNEL17_BIT (1 << 1)
-#define PIO2_CHANNEL18_BIT (1 << 2)
-#define PIO2_CHANNEL19_BIT (1 << 3)
-#define PIO2_CHANNEL20_BIT (1 << 4)
-#define PIO2_CHANNEL21_BIT (1 << 5)
-#define PIO2_CHANNEL22_BIT (1 << 6)
-#define PIO2_CHANNEL23_BIT (1 << 7)
-#define PIO2_CHANNEL24_BIT (1 << 0)
-#define PIO2_CHANNEL25_BIT (1 << 1)
-#define PIO2_CHANNEL26_BIT (1 << 2)
-#define PIO2_CHANNEL27_BIT (1 << 3)
-#define PIO2_CHANNEL28_BIT (1 << 4)
-#define PIO2_CHANNEL29_BIT (1 << 5)
-#define PIO2_CHANNEL30_BIT (1 << 6)
-#define PIO2_CHANNEL31_BIT (1 << 7)
+#define PIO2_CHANNEL0_BIT  BIT(0)
+#define PIO2_CHANNEL1_BIT  BIT(1)
+#define PIO2_CHANNEL2_BIT  BIT(2)
+#define PIO2_CHANNEL3_BIT  BIT(3)
+#define PIO2_CHANNEL4_BIT  BIT(4)
+#define PIO2_CHANNEL5_BIT  BIT(5)
+#define PIO2_CHANNEL6_BIT  BIT(6)
+#define PIO2_CHANNEL7_BIT  BIT(7)
+#define PIO2_CHANNEL8_BIT  BIT(0)
+#define PIO2_CHANNEL9_BIT  BIT(1)
+#define PIO2_CHANNEL10_BIT BIT(2)
+#define PIO2_CHANNEL11_BIT BIT(3)
+#define PIO2_CHANNEL12_BIT BIT(4)
+#define PIO2_CHANNEL13_BIT BIT(5)
+#define PIO2_CHANNEL14_BIT BIT(6)
+#define PIO2_CHANNEL15_BIT BIT(7)
+#define PIO2_CHANNEL16_BIT BIT(0)
+#define PIO2_CHANNEL17_BIT BIT(1)
+#define PIO2_CHANNEL18_BIT BIT(2)
+#define PIO2_CHANNEL19_BIT BIT(3)
+#define PIO2_CHANNEL20_BIT BIT(4)
+#define PIO2_CHANNEL21_BIT BIT(5)
+#define PIO2_CHANNEL22_BIT BIT(6)
+#define PIO2_CHANNEL23_BIT BIT(7)
+#define PIO2_CHANNEL24_BIT BIT(0)
+#define PIO2_CHANNEL25_BIT BIT(1)
+#define PIO2_CHANNEL26_BIT BIT(2)
+#define PIO2_CHANNEL27_BIT BIT(3)
+#define PIO2_CHANNEL28_BIT BIT(4)
+#define PIO2_CHANNEL29_BIT BIT(5)
+#define PIO2_CHANNEL30_BIT BIT(6)
+#define PIO2_CHANNEL31_BIT BIT(7)
 
 static const int PIO2_CHANNEL_BIT[32] = { PIO2_CHANNEL0_BIT, PIO2_CHANNEL1_BIT,
PIO2_CHANNEL2_BIT, PIO2_CHANNEL3_BIT,
@@ -123,12 +123,12 @@ static const int PIO2_CHANNEL_BIT[32] = { 
PIO2_CHANNEL0_BIT, PIO2_CHANNEL1_BIT,
};
 
 /* PIO2_REGS_INT_STAT_CNTR (0xc) */
-#define PIO2_COUNTER0  (1 << 0)
-#define PIO2_COUNTER1  (1 << 1)
-#define PIO2_COUNTER2  (1 << 2)
-#define PIO2_COUNTER3  (1 << 3)
-#define PIO2_COUNTER4  (1 << 4)
-#define PIO2_COUNTER5  (1 << 5)
+#define PIO2_COUNTER0  BIT(0)
+#define PIO2_COUNTER1  BIT(1)
+#define PIO2_COUNTER2  BIT(2)
+#define PIO2_COUNTER3  BIT(3)
+#define PIO2_COUNTER4  BIT(4)
+#define PIO2_COUNTER5  BIT(5)
 
 static const int PIO2_COUNTER[6] = { PIO2_COUNTER0, PIO2_COUNTER1,
PIO2_COUNTER2, PIO2_COUNTER3,
@@ -136,8 +136,8 @@ static const int PIO2_COUNTER[6] = { PIO2_COUNTER0, 
PIO2_COUNTER1,
 
 /*

[PATCH] Staging: vme: vme_pio2: Prefer using the BIT macro

2016-11-05 Thread Shiva Kerdel

Replace all occurences of (1 << x) by BIT(x) in the file vme_pio2.h to
get rid of checkpatch.pl "check" output "Prefer using the BIT macro".

Signed-off-by: Shiva Kerdel 
---
 drivers/staging/vme/devices/vme_pio2.h | 86 +-
 1 file changed, 43 insertions(+), 43 deletions(-)

diff --git a/drivers/staging/vme/devices/vme_pio2.h 
b/drivers/staging/vme/devices/vme_pio2.h
index d5d94c4..495b698 100644
--- a/drivers/staging/vme/devices/vme_pio2.h
+++ b/drivers/staging/vme/devices/vme_pio2.h
@@ -71,38 +71,38 @@ static const int PIO2_CHANNEL_BANK[32] = { 0, 0, 0, 0, 0, 
0, 0, 0,
2, 2, 2, 2, 2, 2, 2, 2,
3, 3, 3, 3, 3, 3, 3, 3 };
 
-#define PIO2_CHANNEL0_BIT  (1 << 0)
-#define PIO2_CHANNEL1_BIT  (1 << 1)
-#define PIO2_CHANNEL2_BIT  (1 << 2)
-#define PIO2_CHANNEL3_BIT  (1 << 3)
-#define PIO2_CHANNEL4_BIT  (1 << 4)
-#define PIO2_CHANNEL5_BIT  (1 << 5)
-#define PIO2_CHANNEL6_BIT  (1 << 6)
-#define PIO2_CHANNEL7_BIT  (1 << 7)
-#define PIO2_CHANNEL8_BIT  (1 << 0)
-#define PIO2_CHANNEL9_BIT  (1 << 1)
-#define PIO2_CHANNEL10_BIT (1 << 2)
-#define PIO2_CHANNEL11_BIT (1 << 3)
-#define PIO2_CHANNEL12_BIT (1 << 4)
-#define PIO2_CHANNEL13_BIT (1 << 5)
-#define PIO2_CHANNEL14_BIT (1 << 6)
-#define PIO2_CHANNEL15_BIT (1 << 7)
-#define PIO2_CHANNEL16_BIT (1 << 0)
-#define PIO2_CHANNEL17_BIT (1 << 1)
-#define PIO2_CHANNEL18_BIT (1 << 2)
-#define PIO2_CHANNEL19_BIT (1 << 3)
-#define PIO2_CHANNEL20_BIT (1 << 4)
-#define PIO2_CHANNEL21_BIT (1 << 5)
-#define PIO2_CHANNEL22_BIT (1 << 6)
-#define PIO2_CHANNEL23_BIT (1 << 7)
-#define PIO2_CHANNEL24_BIT (1 << 0)
-#define PIO2_CHANNEL25_BIT (1 << 1)
-#define PIO2_CHANNEL26_BIT (1 << 2)
-#define PIO2_CHANNEL27_BIT (1 << 3)
-#define PIO2_CHANNEL28_BIT (1 << 4)
-#define PIO2_CHANNEL29_BIT (1 << 5)
-#define PIO2_CHANNEL30_BIT (1 << 6)
-#define PIO2_CHANNEL31_BIT (1 << 7)
+#define PIO2_CHANNEL0_BIT  BIT(0)
+#define PIO2_CHANNEL1_BIT  BIT(1)
+#define PIO2_CHANNEL2_BIT  BIT(2)
+#define PIO2_CHANNEL3_BIT  BIT(3)
+#define PIO2_CHANNEL4_BIT  BIT(4)
+#define PIO2_CHANNEL5_BIT  BIT(5)
+#define PIO2_CHANNEL6_BIT  BIT(6)
+#define PIO2_CHANNEL7_BIT  BIT(7)
+#define PIO2_CHANNEL8_BIT  BIT(0)
+#define PIO2_CHANNEL9_BIT  BIT(1)
+#define PIO2_CHANNEL10_BIT BIT(2)
+#define PIO2_CHANNEL11_BIT BIT(3)
+#define PIO2_CHANNEL12_BIT BIT(4)
+#define PIO2_CHANNEL13_BIT BIT(5)
+#define PIO2_CHANNEL14_BIT BIT(6)
+#define PIO2_CHANNEL15_BIT BIT(7)
+#define PIO2_CHANNEL16_BIT BIT(0)
+#define PIO2_CHANNEL17_BIT BIT(1)
+#define PIO2_CHANNEL18_BIT BIT(2)
+#define PIO2_CHANNEL19_BIT BIT(3)
+#define PIO2_CHANNEL20_BIT BIT(4)
+#define PIO2_CHANNEL21_BIT BIT(5)
+#define PIO2_CHANNEL22_BIT BIT(6)
+#define PIO2_CHANNEL23_BIT BIT(7)
+#define PIO2_CHANNEL24_BIT BIT(0)
+#define PIO2_CHANNEL25_BIT BIT(1)
+#define PIO2_CHANNEL26_BIT BIT(2)
+#define PIO2_CHANNEL27_BIT BIT(3)
+#define PIO2_CHANNEL28_BIT BIT(4)
+#define PIO2_CHANNEL29_BIT BIT(5)
+#define PIO2_CHANNEL30_BIT BIT(6)
+#define PIO2_CHANNEL31_BIT BIT(7)
 
 static const int PIO2_CHANNEL_BIT[32] = { PIO2_CHANNEL0_BIT, PIO2_CHANNEL1_BIT,
PIO2_CHANNEL2_BIT, PIO2_CHANNEL3_BIT,
@@ -123,12 +123,12 @@ static const int PIO2_CHANNEL_BIT[32] = { 
PIO2_CHANNEL0_BIT, PIO2_CHANNEL1_BIT,
};
 
 /* PIO2_REGS_INT_STAT_CNTR (0xc) */
-#define PIO2_COUNTER0  (1 << 0)
-#define PIO2_COUNTER1  (1 << 1)
-#define PIO2_COUNTER2  (1 << 2)
-#define PIO2_COUNTER3  (1 << 3)
-#define PIO2_COUNTER4  (1 << 4)
-#define PIO2_COUNTER5  (1 << 5)
+#define PIO2_COUNTER0  BIT(0)
+#define PIO2_COUNTER1  BIT(1)
+#define PIO2_COUNTER2  BIT(2)
+#define PIO2_COUNTER3  BIT(3)
+#define PIO2_COUNTER4  BIT(4)
+#define PIO2_COUNTER5  BIT(5)
 
 static const int PIO2_COUNTER[6] = { PIO2_COUNTER0, PIO2_COUNTER1,
PIO2_COUNTER2, PIO2_COUNTER3,
@@ -136,8 +136,8 @@ static const int PIO2_COUNTER[6] = { PIO2_COUNTER0, 
PIO2_COUNTER1,
 
 /* PIO2_REGS_CTRL (0x18) */

Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

2016-11-05 Thread Pavel Machek

Hi!

BTW.. This machine has nasty habit of hanging during kernel boot when
it is "hot".. which makes reboots unplesant here. Ideas would be
welcome how to debug that.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

2016-11-05 Thread Pavel Machek

Hi!

BTW.. This machine has nasty habit of hanging during kernel boot when
it is "hot".. which makes reboots unplesant here. Ideas would be
welcome how to debug that.

Best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

2016-11-05 Thread Pavel Machek

On Sat 2016-11-05 16:04:58, Henrique de Moraes Holschuh wrote:
> On Sat, 05 Nov 2016, Pavel Machek wrote:
> > [  825.759661] thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something 
> > is extremely hot!
> > [  825.761935] thinkpad_acpi: temperatures (Celsius): 101 49 N/A 78 33 N/A 
> > 33 N/A 47 50 N/A N/A N/A N/A N/A N/A
> 
> Oh boy, that must be the second time in a decade that I see that
> codepath triggering.  It is the second-level alert that the ThinkPad is
> about to catch fire.
> 
> It should have logged a "is too hot!" first-level alert earlier, but
> this depends on the EC and not the driver.  Maybe the temperature raised
> too fast.

I don't think I'm seeing the "is too hot" messages. Actually.. even
the "THERMAL EMERGENCY" messages seem to have too low severity, so
they are hidden in syslogs -- they don't go to all the consoles.

> In Windows, the system would attempt to hibernate or shutdown.  I would
> be quite happy to have thinkpad-acpi trigger such behavior as well,
> patches (or guidance) are welcome ;-)

Sorry, just guidance for now:

+#include 
+   orderly_poweroff(true);

[can be called from weird contexts, afaict]. 

> Anyway, if that temperature goes about 1~2°C higher, the EC should cut
> power to your motherboard.  Apparently, the built-in thermal protection
> clock modulation on the Intel processor is somehow saving your box from
> that forced power-off.

Actually, the machine _will_ shut down some time after that. It seems
that one of acpi trip points jumps to 128C which forces shutdown.

Thanks and best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: v4.8-rc1: thinkpad x60: running at low frequency even during kernel build

2016-11-05 Thread Pavel Machek

On Sat 2016-11-05 16:04:58, Henrique de Moraes Holschuh wrote:
> On Sat, 05 Nov 2016, Pavel Machek wrote:
> > [  825.759661] thinkpad_acpi: THERMAL EMERGENCY: a sensor reports something 
> > is extremely hot!
> > [  825.761935] thinkpad_acpi: temperatures (Celsius): 101 49 N/A 78 33 N/A 
> > 33 N/A 47 50 N/A N/A N/A N/A N/A N/A
> 
> Oh boy, that must be the second time in a decade that I see that
> codepath triggering.  It is the second-level alert that the ThinkPad is
> about to catch fire.
> 
> It should have logged a "is too hot!" first-level alert earlier, but
> this depends on the EC and not the driver.  Maybe the temperature raised
> too fast.

I don't think I'm seeing the "is too hot" messages. Actually.. even
the "THERMAL EMERGENCY" messages seem to have too low severity, so
they are hidden in syslogs -- they don't go to all the consoles.

> In Windows, the system would attempt to hibernate or shutdown.  I would
> be quite happy to have thinkpad-acpi trigger such behavior as well,
> patches (or guidance) are welcome ;-)

Sorry, just guidance for now:

+#include 
+   orderly_poweroff(true);

[can be called from weird contexts, afaict]. 

> Anyway, if that temperature goes about 1~2°C higher, the EC should cut
> power to your motherboard.  Apparently, the built-in thermal protection
> clock modulation on the Intel processor is somehow saving your box from
> that forced power-off.

Actually, the machine _will_ shut down some time after that. It seems
that one of acpi trip points jumps to 128C which forces shutdown.

Thanks and best regards,
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

1 2 3 4 >

1 - 100 of 338 matches

Mail list logo