[PATCH] staging: lustre: ko2iblnd: Adapt to the removal of ib_get_dma_mr()

[Doug Oucharek]

In Linux kernel 4.9-rc1, the function ib_get_dma_mr()
was removed and a second parameter was added to ib_alloc_pd().
As this broke the building of the ko2iblnd module in
staging, the Kconfig for LNet has marked ko2iblnd as broken
and stopped building it.

This patch fixes this breakage by:

- Removing the BROKEN tag from lnet/Kconfig.
- Make it so the module parameter map_on_demand can no longer be
  zero (we have to configure FMR/FastReg pools; it can no longer be
  off).
- No longer try to use the global DMA memory region, but make use
  of the FMR/FastReg pool for all RDMA Tx operations.
- Everywhere we are using the device DMA mr to derive the
  L-key for non-registered memory regions, use the
  pd->local_dma_lkey value instead.
- Make the default map_on_demand = 256.  This will allow nodes with
  this patch to still connected to older nodes without this patch
  and FMR/FastReg turned off.  When FMR/FastReg is turned off, we
  use 256 as the max frags so the two sides will still be able to
  communicate and work.

Signed-off-by: Doug Oucharek 
Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-9026
---
 drivers/staging/lustre/lnet/Kconfig|  1 -
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c| 69 +-
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h|  3 -
 .../staging/lustre/lnet/klnds/o2iblnd/o2iblnd_cb.c | 17 +-
 .../lustre/lnet/klnds/o2iblnd/o2iblnd_modparams.c  | 12 ++--
 5 files changed, 12 insertions(+), 90 deletions(-)

diff --git a/drivers/staging/lustre/lnet/Kconfig 
b/drivers/staging/lustre/lnet/Kconfig
index 13b4327..2b59301 100644
--- a/drivers/staging/lustre/lnet/Kconfig
+++ b/drivers/staging/lustre/lnet/Kconfig
@@ -35,7 +35,6 @@ config LNET_SELFTEST
 config LNET_XPRT_IB
tristate "LNET infiniband support"
depends on LNET && INFINIBAND && INFINIBAND_ADDR_TRANS
-   depends on BROKEN
default LNET && INFINIBAND
help
  This option allows the LNET users to use infiniband as an
diff --git a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c 
b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
index b1e8508..d39ba14 100644
--- a/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
+++ b/drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.c
@@ -1281,27 +1281,6 @@ static void kiblnd_map_tx_pool(struct kib_tx_pool *tpo)
}
 }
 
-struct ib_mr *kiblnd_find_rd_dma_mr(struct lnet_ni *ni, struct kib_rdma_desc 
*rd,
-   int negotiated_nfrags)
-{
-   struct kib_net *net = ni->ni_data;
-   struct kib_hca_dev *hdev = net->ibn_dev->ibd_hdev;
-   struct lnet_ioctl_config_o2iblnd_tunables *tunables;
-   __u16 nfrags;
-   int mod;
-
-   tunables = &ni->ni_lnd_tunables->lt_tun_u.lt_o2ib;
-   mod = tunables->lnd_map_on_demand;
-   nfrags = (negotiated_nfrags != -1) ? negotiated_nfrags : mod;
-
-   LASSERT(hdev->ibh_mrs);
-
-   if (mod > 0 && nfrags <= rd->rd_nfrags)
-   return NULL;
-
-   return hdev->ibh_mrs;
-}
-
 static void kiblnd_destroy_fmr_pool(struct kib_fmr_pool *fpo)
 {
LASSERT(!fpo->fpo_map_count);
@@ -2168,21 +2147,12 @@ static int kiblnd_net_init_pools(struct kib_net *net, 
lnet_ni_t *ni, __u32 *cpts
 int ncpts)
 {
struct lnet_ioctl_config_o2iblnd_tunables *tunables;
-   unsigned long flags;
int cpt;
int rc;
int i;
 
tunables = &ni->ni_lnd_tunables->lt_tun_u.lt_o2ib;
 
-   read_lock_irqsave(&kiblnd_data.kib_global_lock, flags);
-   if (!tunables->lnd_map_on_demand) {
-   read_unlock_irqrestore(&kiblnd_data.kib_global_lock, flags);
-   goto create_tx_pool;
-   }
-
-   read_unlock_irqrestore(&kiblnd_data.kib_global_lock, flags);
-
if (tunables->lnd_fmr_pool_size < *kiblnd_tunables.kib_ntx / 4) {
CERROR("Can't set fmr pool size (%d) < ntx / 4(%d)\n",
   tunables->lnd_fmr_pool_size,
@@ -2227,7 +2197,6 @@ static int kiblnd_net_init_pools(struct kib_net *net, 
lnet_ni_t *ni, __u32 *cpts
if (i > 0)
LASSERT(i == ncpts);
 
- create_tx_pool:
/*
 * cfs_precpt_alloc is creating an array of struct kib_tx_poolset
 * The number of struct kib_tx_poolsets create is equal to the
@@ -2283,20 +2252,8 @@ static int kiblnd_hdev_get_attr(struct kib_hca_dev *hdev)
return -EINVAL;
 }
 
-static void kiblnd_hdev_cleanup_mrs(struct kib_hca_dev *hdev)
-{
-   if (!hdev->ibh_mrs)
-   return;
-
-   ib_dereg_mr(hdev->ibh_mrs);
-
-   hdev->ibh_mrs = NULL;
-}
-
 void kiblnd_hdev_destroy(struct kib_hca_dev *hdev)
 {
-   kiblnd_hdev_cleanup_mrs(hdev);
-
if (hdev->ibh_pd)
ib_dealloc_pd(hdev->ibh_pd);
 
@@ -2306,28 +2263,6 @@ void kiblnd_hdev_destroy(struct kib_hca_dev *hdev)
LIBCFS_FREE(hdev, sizeof(*hdev));
 }
 
-static int kiblnd_hdev_setup_mrs(struct kib_hca_dev *hdev)
-{
-  

[PATCH 2/2] Staging: setup.c: fixed ERROR: trailing whitespace

[Kishore Karanala]

Fixed ERROR: trailing whitespace issues

Signed-off-by: Kishore Karanala 
---
 arch/x86/kernel/setup.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/kernel/setup.c b/arch/x86/kernel/setup.c
index 5fa3194..1a1e986 100644
--- a/arch/x86/kernel/setup.c
+++ b/arch/x86/kernel/setup.c
@@ -723,7 +723,7 @@ static void __init trim_snb_memory(void)
 * already been reserved.
 */
memblock_reserve(0, 1<<20);
-   
+
for (i = 0; i < ARRAY_SIZE(bad_pages); i++) {
if (memblock_reserve(bad_pages[i], PAGE_SIZE))
printk(KERN_WARNING "failed to reserve 0x%08lx\n",
@@ -815,7 +815,7 @@ static void __init trim_low_memory_range(void)
 {
memblock_reserve(0, ALIGN(reserve_low, PAGE_SIZE));
 }
-   
+
 /*
  * Dump out kernel offset information on panic.
  */
-- 
2.7.4

arch/xtensa/include/asm/initialize_mmu.h:41: Error: invalid register 'atomctl' for 'wsr' instruction

[kbuild test robot]

Hi Pete,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1ce42845f987e92eabfc6e026d44d826c25c74a5
commit: d0b73b488c55df905ea8faaad079f8535629ed26 xtensa: Add config files for 
Diamond 233L - Rev C processor variant
date:   4 years ago
config: xtensa-generic_kc705_defconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.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 d0b73b488c55df905ea8faaad079f8535629ed26
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All errors (new ones prefixed by >>):

   arch/xtensa/include/asm/initialize_mmu.h: Assembler messages:
>> arch/xtensa/include/asm/initialize_mmu.h:41: Error: invalid register 
>> 'atomctl' for 'wsr' instruction

vim +41 arch/xtensa/include/asm/initialize_mmu.h

c622b29d Max Filippov 2012-11-19  25  
c622b29d Max Filippov 2012-11-19  26  #ifdef __ASSEMBLY__
c622b29d Max Filippov 2012-11-19  27  
c622b29d Max Filippov 2012-11-19  28  #define XTENSA_HWVERSION_RC_2009_0 23
c622b29d Max Filippov 2012-11-19  29  
c622b29d Max Filippov 2012-11-19  30.macro  initialize_mmu
c622b29d Max Filippov 2012-11-19  31  
c622b29d Max Filippov 2012-11-19  32  #if XCHAL_HAVE_S32C1I && 
(XCHAL_HW_MIN_VERSION >= XTENSA_HWVERSION_RC_2009_0)
c622b29d Max Filippov 2012-11-19  33  /*
c622b29d Max Filippov 2012-11-19  34   * We Have Atomic Operation Control 
(ATOMCTL) Register; Initialize it.
c622b29d Max Filippov 2012-11-19  35   * For details see 
Documentation/xtensa/atomctl.txt
c622b29d Max Filippov 2012-11-19  36   */
c622b29d Max Filippov 2012-11-19  37  #if XCHAL_DCACHE_IS_COHERENT
c622b29d Max Filippov 2012-11-19  38movia3, 0x25/* For SMP/MX 
-- internal for writeback,
c622b29d Max Filippov 2012-11-19  39 * RCW otherwise
c622b29d Max Filippov 2012-11-19  40 */
c622b29d Max Filippov 2012-11-19 @41  #else
c622b29d Max Filippov 2012-11-19  42movia3, 0x29/* non-MX -- 
Most cores use Std Memory
c622b29d Max Filippov 2012-11-19  43 * Controlers 
which usually can't use RCW
c622b29d Max Filippov 2012-11-19  44 */
c622b29d Max Filippov 2012-11-19  45  #endif
c622b29d Max Filippov 2012-11-19  46wsr a3, atomctl
c622b29d Max Filippov 2012-11-19  47  #endif  /* XCHAL_HAVE_S32C1I &&
c622b29d Max Filippov 2012-11-19  48 * (XCHAL_HW_MIN_VERSION >= 
XTENSA_HWVERSION_RC_2009_0)
c622b29d Max Filippov 2012-11-19  49 */

:: The code at line 41 was first introduced by commit
:: c622b29d1f38021411965b7e0170ab01b257 xtensa: initialize atomctl SR

:: TO: Max Filippov 
:: CC: Chris Zankel 

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


.config.gz
Description: application/gzip

drivers/auxdisplay/img-ascii-lcd.c:384: undefined reference to `devm_ioremap_resource'

[kbuild test robot]

Hi Paul,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1ce42845f987e92eabfc6e026d44d826c25c74a5
commit: 0cad855fbd083ee5fd0584a47c2aaa7dca936fd4 auxdisplay: img-ascii-lcd: 
driver for simple ASCII LCD displays
date:   4 months ago
config: um-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 0cad855fbd083ee5fd0584a47c2aaa7dca936fd4
# 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+0xc781): 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+0xc5cc): 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+0xc8e5): 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+0x1d375): 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+0x1d415): 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+0x1d635): 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+0x1d467): 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:4028: undefined reference to 
`devm_gpiod_get_optional'
   drivers/built-in.o: In function `img_ascii_lcd_probe':
>> drivers/auxdisplay/img-ascii-lcd.c:384: undefined reference to 
>> `devm_ioremap_resource'
   drivers/built-in.o: In function `pps_gpio_probe':
   drivers/pps/clients/pps-gpio.c:125: undefined reference to 
`devm_gpio_request'
   dri

Re: include/linux/kprobes.h:361:2: error: invalid use of undefined type 'struct kprobe_ctlblk'

[Russell King - ARM Linux]

The facts of this are:

linux/kprobes.h includes asm/kprobes.h

linux/kprobes.h wants the architecture to define struct kprobe_ctlblk.
arch/mn10300/include/asm/kprobes.h fails to define this structure.

So, I've no idea how kprobes can even work on this architecture.  AFAICS
it should not allow kprobes to be enabled.

This problem needs resolving by the mn10300 maintainer.  I can do nothing
about it.

On Sun, Feb 12, 2017 at 03:41:10PM +0800, kbuild test robot wrote:
> Hi Russell,
> 
> FYI, the error/warning still remains.
> 
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   1ce42845f987e92eabfc6e026d44d826c25c74a5
> commit: b2c0b2cbb282f0cf42518ffacbe197e6f2884168 nmi: create generic NMI 
> backtrace implementation
> date:   1 year, 7 months ago
> config: mn10300-allyesconfig (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 b2c0b2cbb282f0cf42518ffacbe197e6f2884168
> # save the attached .config to linux build tree
> make.cross ARCH=mn10300 
> 
> All errors (new ones prefixed by >>):
> 
>In file included from lib/nmi_backtrace.c:17:0:
>include/linux/kprobes.h: In function 'get_kprobe_ctlblk':
> >> include/linux/kprobes.h:361:2: error: invalid use of undefined type 
> >> 'struct kprobe_ctlblk'
>  return this_cpu_ptr(&kprobe_ctlblk);
>  ^~
> 
> vim +361 include/linux/kprobes.h
> 
> e65845235 Ananth N Mavinakayanahalli 2005-11-07  355  {
> b76834bc1 Christoph Lameter  2010-12-06  356  
> __this_cpu_write(current_kprobe, NULL);
> e65845235 Ananth N Mavinakayanahalli 2005-11-07  357  }
> e65845235 Ananth N Mavinakayanahalli 2005-11-07  358  
> e65845235 Ananth N Mavinakayanahalli 2005-11-07  359  static inline struct 
> kprobe_ctlblk *get_kprobe_ctlblk(void)
> e65845235 Ananth N Mavinakayanahalli 2005-11-07  360  {
> bdffd893a Christoph Lameter  2014-04-29 @361  return 
> this_cpu_ptr(&kprobe_ctlblk);
> e65845235 Ananth N Mavinakayanahalli 2005-11-07  362  }
> e65845235 Ananth N Mavinakayanahalli 2005-11-07  363  
> ^1da177e4 Linus Torvalds 2005-04-16  364  int 
> register_kprobe(struct kprobe *p);
> 
> :: The code at line 361 was first introduced by commit
> :: bdffd893a0e9c431304142d12d9a0a21d365c502 tracing: Replace 
> __get_cpu_var uses with this_cpu_ptr
> 
> :: TO: Christoph Lameter 
> :: CC: Steven Rostedt 
> 
> ---
> 0-DAY kernel test infrastructureOpen Source Technology Center
> https://lists.01.org/pipermail/kbuild-all   Intel Corporation



-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

[PATCH] bcm2835-audio: Fix checkpatch errors

[Man Choy]

Fix following errors:

ERROR: do not initialise statics to NULL
+static struct snd_card *g_card = NULL;

ERROR: do not initialise statics to NULL
+static struct bcm2835_chip *g_chip = NULL;

Signed-off-by: Man Choy 
---
 drivers/staging/bcm2835-audio/bcm2835.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/bcm2835-audio/bcm2835.c 
b/drivers/staging/bcm2835-audio/bcm2835.c
index a84d74d..265fe55 100644
--- a/drivers/staging/bcm2835-audio/bcm2835.c
+++ b/drivers/staging/bcm2835-audio/bcm2835.c
@@ -28,8 +28,8 @@
  * to debug if we run into issues
  */
 
-static struct snd_card *g_card = NULL;
-static struct bcm2835_chip *g_chip = NULL;
+static struct snd_card *g_card;
+static struct bcm2835_chip *g_chip;
 
 static int snd_bcm2835_free(struct bcm2835_chip *chip)
 {
-- 
2.7.4

Re: [PATCH] ARM: dts: sun5i-gr8: Rename pwm0_pins_a to pwm0_pins

[kbuild test robot]

Hi Chen-Yu,

[auto build test ERROR on robh/for-next]
[also build test ERROR on v4.10-rc7 next-20170210]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chen-Yu-Tsai/ARM-dts-sun5i-gr8-Rename-pwm0_pins_a-to-pwm0_pins/20170210-122740
base:   https://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git for-next
config: arm-allyesconfig (attached as .config)
compiler: arm-linux-gnueabi-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
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

>> ERROR: Input tree has errors, aborting (use -f to force output)

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


.config.gz
Description: application/gzip

Re: [PATCH 00/22] m68k: Modernize printing of kernel messages

[Geert Uytterhoeven]

On Thu, Feb 9, 2017 at 2:25 PM, Geert Uytterhoeven  wrote:
> On Wed, Dec 7, 2016 at 4:08 PM, Geert Uytterhoeven  
> wrote:
>> This patch series modernizes the printing of kernel messages in the m68k
>> architecture core, which is mainly about converting from printk() to
>> pr_*().
>>
>> The trigger for (finally) doing this was the user-visible breakage
>> caused by commit 4bcc595ccd80decb ("printk: reinstate KERN_CONT for
>> printing continuation lines").
>>
>> I had hoped to sent this series much earlier, to be still included in
>> v4.9, but that didn't happen due to lack of time. Fortunately v4.9 will
>> be an LTS(I) kernel, so the first three patches (tagged with a "Fixes"
>> tag) will hopefully make it to v4.9.x later ;-)
>>
>> Compile-tested with my standard set of configs.
>> Boot-tested on ARAnyM.
>>
>> Thanks for your comments!
>>
>> Geert Uytterhoeven (22):
>>   m68k/atari: Modernize printing of kernel messages
>>   m68k/68000: Modernize printing of kernel messages
>>   m68k/bvme6000: Modernize printing of kernel messages
>>   m68k/mvme147: Modernize printing of kernel messages
>>   m68k/mvme16x: Modernize printing of kernel messages
>>   m68k/q40: Modernize printing of kernel messages
>>   m68k/sun3: Modernize printing of kernel messages
>>   m68k/sun3x: Modernize printing of kernel messages
>>   m68k/kernel: Modernize printing of kernel messages
>>   m68k/mm: sun3 - Modernize printing of kernel messages
>>   m68k/mm: Modernize printing of kernel messages
>>   m68k/include: Modernize printing of kernel messages
>
> I've applied and queued for v4.11 the subset above.

This time for real...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

[PATCH 15/15] staging: rtl8192u: Removing unnecessary parentheses

[simran singhal]

Removing unnecessary parentheses from an expression of the form &(x).
Issue found by checkpatch.

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_module.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
index 0b162bf..a9a92d8 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
@@ -141,8 +141,8 @@ struct net_device *alloc_ieee80211(int sizeof_priv)
spin_lock_init(&ieee->bw_spinlock);
spin_lock_init(&ieee->reorder_spinlock);
/* added by WB */
-   atomic_set(&(ieee->atm_chnlop), 0);
-   atomic_set(&(ieee->atm_swbw), 0);
+   atomic_set(&ieee->atm_chnlop, 0);
+   atomic_set(&ieee->atm_swbw, 0);
 
ieee->wpax_type_set = 0;
ieee->wpa_enabled = 0;
-- 
2.7.4

[PATCH] staging: lustre: lnet: fix type warning in lib-socket.c

[William Blough]

The local socket address is defined as a __be32 value.  However, if the
local ip address is not given, then the constant INADDR_ANY is used.

This patch converts INADDR_ANY to __be32 for type consistency.

Fixes the following sparse warnings:

drivers/staging/lustre/lnet/lnet/lib-socket.c:396:41: warning:
 incorrect type in assignment (different base types)
drivers/staging/lustre/lnet/lnet/lib-socket.c:397:56: warning:
 restricted __be32 degrades to integer

Signed-off-by: William Blough 
---
 drivers/staging/lustre/lnet/lnet/lib-socket.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/staging/lustre/lnet/lnet/lib-socket.c 
b/drivers/staging/lustre/lnet/lnet/lib-socket.c
index 654a7b2..b7b87ec 100644
--- a/drivers/staging/lustre/lnet/lnet/lib-socket.c
+++ b/drivers/staging/lustre/lnet/lnet/lib-socket.c
@@ -393,8 +393,10 @@ lnet_sock_create(struct socket **sockp, int *fatal, __u32 
local_ip,
memset(&locaddr, 0, sizeof(locaddr));
locaddr.sin_family = AF_INET;
locaddr.sin_port = htons(local_port);
-   locaddr.sin_addr.s_addr = !local_ip ?
- INADDR_ANY : htonl(local_ip);
+   if (!local_ip)
+   locaddr.sin_addr.s_addr = htonl(INADDR_ANY);
+   else
+   locaddr.sin_addr.s_addr = htonl(local_ip);
 
rc = kernel_bind(sock, (struct sockaddr *)&locaddr,
 sizeof(locaddr));
-- 
2.1.4

[PATCH] staging: rtl8192e: Aligning the * on each line in block comments

[Arushi]

This patch fixes the issue by aligning the * on each line in block
comments.

Signed-off-by: Arushi Singhal 
---
---
 drivers/staging/speakup/fakekey.c| 10 +-
 drivers/staging/speakup/i18n.c   | 14 +++---
 drivers/staging/speakup/main.c   |  2 +-
 drivers/staging/speakup/speakup_acntsa.c |  2 +-
 drivers/staging/speakup/speakup_apollo.c |  2 +-
 drivers/staging/speakup/speakup_decext.c |  2 +-
 drivers/staging/speakup/speakup_decpc.c  |  4 ++--
 drivers/staging/speakup/speakup_dtlk.c   |  2 +-
 drivers/staging/speakup/speakup_dtlk.h   | 10 +-
 drivers/staging/speakup/speakup_ltlk.c   |  2 +-
 10 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/drivers/staging/speakup/fakekey.c 
b/drivers/staging/speakup/fakekey.c
index 8f058b42f68d..d76da0a1382c 100644
--- a/drivers/staging/speakup/fakekey.c
+++ b/drivers/staging/speakup/fakekey.c
@@ -63,8 +63,8 @@ void speakup_remove_virtual_keyboard(void)
 }
 
 /*
-* Send a simulated down-arrow to the application.
-*/
+ * Send a simulated down-arrow to the application.
+ */
 void speakup_fake_down_arrow(void)
 {
unsigned long flags;
@@ -87,9 +87,9 @@ void speakup_fake_down_arrow(void)
 }
 
 /*
-* Are we handling a simulated keypress on the current CPU?
-* Returns a boolean.
-*/
+ * Are we handling a simulated keypress on the current CPU?
+ * Returns a boolean.
+ */
 bool speakup_fake_key_pressed(void)
 {
return this_cpu_read(reporting_keystroke);
diff --git a/drivers/staging/speakup/i18n.c b/drivers/staging/speakup/i18n.c
index 8960079e4d60..2f9b3df7f78d 100644
--- a/drivers/staging/speakup/i18n.c
+++ b/drivers/staging/speakup/i18n.c
@@ -401,7 +401,7 @@ char *spk_msg_get(enum msg_index_t index)
  * Finds the start of the next format specifier in the argument string.
  * Return value: pointer to start of format
  * specifier, or NULL if no specifier exists.
-*/
+ */
 static char *next_specifier(char *input)
 {
int found = 0;
@@ -450,7 +450,7 @@ static char *skip_width(char *input)
  * Note that this code only accepts a handful of conversion specifiers:
  * c d s x and ld.  Not accidental; these are exactly the ones used in
  * the default group of formatted messages.
-*/
+ */
 static char *skip_conversion(char *input)
 {
if ((input[0] == 'l') && (input[1] == 'd'))
@@ -463,7 +463,7 @@ static char *skip_conversion(char *input)
 /*
  * Function: find_specifier_end
  * Return a pointer to the end of the format specifier.
-*/
+ */
 static char *find_specifier_end(char *input)
 {
input++;/* Advance over %. */
@@ -478,7 +478,7 @@ static char *find_specifier_end(char *input)
  * Compare the format specifiers pointed to by *input1 and *input2.
  * Return 1 if they are the same, 0 otherwise.  Advance *input1 and *input2
  * so that they point to the character following the end of the specifier.
-*/
+ */
 static int compare_specifiers(char **input1, char **input2)
 {
int same = 0;
@@ -500,7 +500,7 @@ static int compare_specifiers(char **input1, char **input2)
  * Check that two format strings contain the same number of format specifiers,
  * and that the order of specifiers is the same in both strings.
  * Return 1 if the condition holds, 0 if it doesn't.
-*/
+ */
 static int fmt_validate(char *template, char *user)
 {
int valid = 1;
@@ -537,7 +537,7 @@ static int fmt_validate(char *template, char *user)
  * Failure conditions:
  * -EINVAL -  Invalid format specifiers in formatted message or illegal index.
  * -ENOMEM -  Unable to allocate memory.
-*/
+ */
 ssize_t spk_msg_set(enum msg_index_t index, char *text, size_t length)
 {
int rc = 0;
@@ -573,7 +573,7 @@ ssize_t spk_msg_set(enum msg_index_t index, char *text, 
size_t length)
 /*
  * Find a message group, given its name.  Return a pointer to the structure
  * if found, or NULL otherwise.
-*/
+ */
 struct msg_group_t *spk_find_msg_group(const char *group_name)
 {
struct msg_group_t *group = NULL;
diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index bf539d38..c2f70ef5b9b3 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -16,7 +16,7 @@
  *  but WITHOUT ANY WARRANTY; without even the implied warranty of
  *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  *  GNU General Public License for more details.
-*/
+ */
 
 #include 
 #include 
diff --git a/drivers/staging/speakup/speakup_acntsa.c 
b/drivers/staging/speakup/speakup_acntsa.c
index b4e49cdd2014..b2e352712766 100644
--- a/drivers/staging/speakup/speakup_acntsa.c
+++ b/drivers/staging/speakup/speakup_acntsa.c
@@ -1,6 +1,6 @@
 /*
  * originally written by: Kirk Reiser 
-* this version considerably modified by David Borowski, david...@rogers.com
+ * this version considerably modified by David Borowski, david...@rogers.com
  *
  * Copyright (C) 1998-99  Kirk Reiser.
  * Copyright (C) 2003 David Borowski.
diff -

Re: [PATCH 1/2] include: Fix checkpatch whitespace error and warning

[Sergei Shtylyov]

Hello!

On 2/12/2017 5:57 AM, Tobin C. Harding wrote:


This patch fixes two trivial whitespace messages (ERROR/WARNING).
Fixes trailing whitespace ERROR and fixes space before tabs WARNING.

Signed-off-by: Tobin C. Harding 
---
 include/linux/idr.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/idr.h b/include/linux/idr.h
index 3c01b89..4a8de2f 100644
--- a/include/linux/idr.h
+++ b/include/linux/idr.h
@@ -1,6 +1,6 @@
 /*
  * include/linux/idr.h
- *
+ *
  * 2002-10-18  written by Jim Houston jim.hous...@ccur.com
  * Copyright (C) 2002 by Concurrent Computer Corporation
  * Distributed under the GNU GPL license version 2.
@@ -183,7 +183,7 @@ static inline void *idr_find(struct idr *idr, int id)
  */
 #define IDA_CHUNK_SIZE 128 /* 128 bytes per chunk */
 #define IDA_BITMAP_LONGS   (IDA_CHUNK_SIZE / sizeof(long) - 1)
-#define IDA_BITMAP_BITS(IDA_BITMAP_LONGS * sizeof(long) * 8)
+#define IDA_BITMAP_BITS (IDA_BITMAP_LONGS * sizeof(long) * 8)


   Why replace tab with spaces?!

[...]

MBR, Sergei

Re: [PATCH 2/2] Staging: setup.c: fixed ERROR: trailing whitespace

[Thomas Gleixner]

On Sun, 12 Feb 2017, Kishore Karanala wrote:

You're not listening at all. I told you before:

   The proper subsystem for x86 is x86 and not staging.

You can chose to ignore my review comments, but then you don't have to
wonder that I'm going to ignore you as well.

Aside of that, you got at least TWO messages from your mail server, that
mail to 'g...@linutronix.de' cannot be delivered, but that seems to be
information to ignore as well.

> Fixed ERROR: trailing whitespace issues

What's the point of this?

You used checkpatch.pl on that file. Can you figure out from the name of
that script what's the purpose of that script?

The purpose is obviously to check patches for correctness. The fact that
you can run checkpatch.pl with the -f commandline option on an existing
file does not change that.

And trailing whitespace is the least of our worries, really. 

Thanks,

tglx

[PATCH] net: neterion: s2io: use new api ethtool_{get|set}_link_ksettings

[Philippe Reynes]

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

As I don't have the hardware, I'd be very pleased if
someone may test this patch.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/neterion/s2io.c |   51 +++--
 1 files changed, 29 insertions(+), 22 deletions(-)

diff --git a/drivers/net/ethernet/neterion/s2io.c 
b/drivers/net/ethernet/neterion/s2io.c
index 203abcb..c5c1d0e 100644
--- a/drivers/net/ethernet/neterion/s2io.c
+++ b/drivers/net/ethernet/neterion/s2io.c
@@ -5300,10 +5300,10 @@ static int do_s2io_prog_unicast(struct net_device *dev, 
u8 *addr)
 }
 
 /**
- * s2io_ethtool_sset - Sets different link parameters.
+ * s2io_ethtool_set_link_ksettings - Sets different link parameters.
  * @sp : private member of the device structure, which is a pointer to the
  * s2io_nic structure.
- * @info: pointer to the structure with parameters given by ethtool to set
+ * @cmd: pointer to the structure with parameters given by ethtool to set
  * link information.
  * Description:
  * The function sets different link parameters provided by the user onto
@@ -5312,13 +5312,14 @@ static int do_s2io_prog_unicast(struct net_device *dev, 
u8 *addr)
  * 0 on success.
  */
 
-static int s2io_ethtool_sset(struct net_device *dev,
-struct ethtool_cmd *info)
+static int
+s2io_ethtool_set_link_ksettings(struct net_device *dev,
+   const struct ethtool_link_ksettings *cmd)
 {
struct s2io_nic *sp = netdev_priv(dev);
-   if ((info->autoneg == AUTONEG_ENABLE) ||
-   (ethtool_cmd_speed(info) != SPEED_1) ||
-   (info->duplex != DUPLEX_FULL))
+   if ((cmd->base.autoneg == AUTONEG_ENABLE) ||
+   (cmd->base.speed != SPEED_1) ||
+   (cmd->base.duplex != DUPLEX_FULL))
return -EINVAL;
else {
s2io_close(sp->dev);
@@ -5329,10 +5330,10 @@ static int s2io_ethtool_sset(struct net_device *dev,
 }
 
 /**
- * s2io_ethtol_gset - Return link specific information.
+ * s2io_ethtol_get_link_ksettings - Return link specific information.
  * @sp : private member of the device structure, pointer to the
  *  s2io_nic structure.
- * @info : pointer to the structure with parameters given by ethtool
+ * @cmd : pointer to the structure with parameters given by ethtool
  * to return link information.
  * Description:
  * Returns link specific information like speed, duplex etc.. to ethtool.
@@ -5340,25 +5341,31 @@ static int s2io_ethtool_sset(struct net_device *dev,
  * return 0 on success.
  */
 
-static int s2io_ethtool_gset(struct net_device *dev, struct ethtool_cmd *info)
+static int
+s2io_ethtool_get_link_ksettings(struct net_device *dev,
+   struct ethtool_link_ksettings *cmd)
 {
struct s2io_nic *sp = netdev_priv(dev);
-   info->supported = (SUPPORTED_1baseT_Full | SUPPORTED_FIBRE);
-   info->advertising = (SUPPORTED_1baseT_Full | SUPPORTED_FIBRE);
-   info->port = PORT_FIBRE;
 
-   /* info->transceiver */
-   info->transceiver = XCVR_EXTERNAL;
+   ethtool_link_ksettings_zero_link_mode(cmd, supported);
+   ethtool_link_ksettings_add_link_mode(cmd, supported, 1baseT_Full);
+   ethtool_link_ksettings_add_link_mode(cmd, supported, FIBRE);
+
+   ethtool_link_ksettings_zero_link_mode(cmd, advertising);
+   ethtool_link_ksettings_add_link_mode(cmd, advertising, 1baseT_Full);
+   ethtool_link_ksettings_add_link_mode(cmd, advertising, FIBRE);
+
+   cmd->base.port = PORT_FIBRE;
 
if (netif_carrier_ok(sp->dev)) {
-   ethtool_cmd_speed_set(info, SPEED_1);
-   info->duplex = DUPLEX_FULL;
+   cmd->base.speed = SPEED_1;
+   cmd->base.duplex = DUPLEX_FULL;
} else {
-   ethtool_cmd_speed_set(info, SPEED_UNKNOWN);
-   info->duplex = DUPLEX_UNKNOWN;
+   cmd->base.speed = SPEED_UNKNOWN;
+   cmd->base.duplex = DUPLEX_UNKNOWN;
}
 
-   info->autoneg = AUTONEG_DISABLE;
+   cmd->base.autoneg = AUTONEG_DISABLE;
return 0;
 }
 
@@ -6626,8 +6633,6 @@ static int s2io_set_features(struct net_device *dev, 
netdev_features_t features)
 }
 
 static const struct ethtool_ops netdev_ethtool_ops = {
-   .get_settings = s2io_ethtool_gset,
-   .set_settings = s2io_ethtool_sset,
.get_drvinfo = s2io_ethtool_gdrvinfo,
.get_regs_len = s2io_ethtool_get_regs_len,
.get_regs = s2io_ethtool_gregs,
@@ -6643,6 +6648,8 @@ static int s2io_set_features(struct net_device *dev, 
netdev_features_t features)
.set_phys_id = s2io_ethtool_set_led,
.get_ethtool_stats = s2io_get_ethtool_stats,
.get_sset_count = s2io_get_sset_count,
+   .get_link_ksettings = s2io_ethtool_get_link_ksettings,
+   .set_link_ksettings = s2io_ethtool_set_link_ksettings,
 };
 
 /**
-- 
1.7.4

[PATCH] staging: rtl8192e: Aligning the * on each line in block comments

[Arushi Singhal]

This patch fixes the issue by aligning the * on each line in block
comments.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/speakup/fakekey.c| 10 +-
 drivers/staging/speakup/i18n.c   | 14 +++---
 drivers/staging/speakup/main.c   |  2 +-
 drivers/staging/speakup/speakup_acntsa.c |  2 +-
 drivers/staging/speakup/speakup_apollo.c |  2 +-
 drivers/staging/speakup/speakup_decext.c |  2 +-
 drivers/staging/speakup/speakup_decpc.c  |  4 ++--
 drivers/staging/speakup/speakup_dtlk.c   |  2 +-
 drivers/staging/speakup/speakup_dtlk.h   | 10 +-
 drivers/staging/speakup/speakup_ltlk.c   |  2 +-
 10 files changed, 25 insertions(+), 25 deletions(-)

diff --git a/drivers/staging/speakup/fakekey.c 
b/drivers/staging/speakup/fakekey.c
index 8f058b42f68d..d76da0a1382c 100644
--- a/drivers/staging/speakup/fakekey.c
+++ b/drivers/staging/speakup/fakekey.c
@@ -63,8 +63,8 @@ void speakup_remove_virtual_keyboard(void)
 }
 
 /*
-* Send a simulated down-arrow to the application.
-*/
+ * Send a simulated down-arrow to the application.
+ */
 void speakup_fake_down_arrow(void)
 {
unsigned long flags;
@@ -87,9 +87,9 @@ void speakup_fake_down_arrow(void)
 }
 
 /*
-* Are we handling a simulated keypress on the current CPU?
-* Returns a boolean.
-*/
+ * Are we handling a simulated keypress on the current CPU?
+ * Returns a boolean.
+ */
 bool speakup_fake_key_pressed(void)
 {
return this_cpu_read(reporting_keystroke);
diff --git a/drivers/staging/speakup/i18n.c b/drivers/staging/speakup/i18n.c
index 8960079e4d60..2f9b3df7f78d 100644
--- a/drivers/staging/speakup/i18n.c
+++ b/drivers/staging/speakup/i18n.c
@@ -401,7 +401,7 @@ char *spk_msg_get(enum msg_index_t index)
  * Finds the start of the next format specifier in the argument string.
  * Return value: pointer to start of format
  * specifier, or NULL if no specifier exists.
-*/
+ */
 static char *next_specifier(char *input)
 {
int found = 0;
@@ -450,7 +450,7 @@ static char *skip_width(char *input)
  * Note that this code only accepts a handful of conversion specifiers:
  * c d s x and ld.  Not accidental; these are exactly the ones used in
  * the default group of formatted messages.
-*/
+ */
 static char *skip_conversion(char *input)
 {
if ((input[0] == 'l') && (input[1] == 'd'))
@@ -463,7 +463,7 @@ static char *skip_conversion(char *input)
 /*
  * Function: find_specifier_end
  * Return a pointer to the end of the format specifier.
-*/
+ */
 static char *find_specifier_end(char *input)
 {
input++;/* Advance over %. */
@@ -478,7 +478,7 @@ static char *find_specifier_end(char *input)
  * Compare the format specifiers pointed to by *input1 and *input2.
  * Return 1 if they are the same, 0 otherwise.  Advance *input1 and *input2
  * so that they point to the character following the end of the specifier.
-*/
+ */
 static int compare_specifiers(char **input1, char **input2)
 {
int same = 0;
@@ -500,7 +500,7 @@ static int compare_specifiers(char **input1, char **input2)
  * Check that two format strings contain the same number of format specifiers,
  * and that the order of specifiers is the same in both strings.
  * Return 1 if the condition holds, 0 if it doesn't.
-*/
+ */
 static int fmt_validate(char *template, char *user)
 {
int valid = 1;
@@ -537,7 +537,7 @@ static int fmt_validate(char *template, char *user)
  * Failure conditions:
  * -EINVAL -  Invalid format specifiers in formatted message or illegal index.
  * -ENOMEM -  Unable to allocate memory.
-*/
+ */
 ssize_t spk_msg_set(enum msg_index_t index, char *text, size_t length)
 {
int rc = 0;
@@ -573,7 +573,7 @@ ssize_t spk_msg_set(enum msg_index_t index, char *text, 
size_t length)
 /*
  * Find a message group, given its name.  Return a pointer to the structure
  * if found, or NULL otherwise.
-*/
+ */
 struct msg_group_t *spk_find_msg_group(const char *group_name)
 {
struct msg_group_t *group = NULL;
diff --git a/drivers/staging/speakup/main.c b/drivers/staging/speakup/main.c
index bf539d38..c2f70ef5b9b3 100644
--- a/drivers/staging/speakup/main.c
+++ b/drivers/staging/speakup/main.c
@@ -16,7 +16,7 @@
  *  but WITHOUT ANY WARRANTY; without even the implied warranty of
  *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
  *  GNU General Public License for more details.
-*/
+ */
 
 #include 
 #include 
diff --git a/drivers/staging/speakup/speakup_acntsa.c 
b/drivers/staging/speakup/speakup_acntsa.c
index b4e49cdd2014..b2e352712766 100644
--- a/drivers/staging/speakup/speakup_acntsa.c
+++ b/drivers/staging/speakup/speakup_acntsa.c
@@ -1,6 +1,6 @@
 /*
  * originally written by: Kirk Reiser 
-* this version considerably modified by David Borowski, david...@rogers.com
+ * this version considerably modified by David Borowski, david...@rogers.com
  *
  * Copyright (C) 1998-99  Kirk Reiser.
  * Copyright (C) 2003 David Borowski.
diff --git

[PATCH v2 1/2] staging: iio: isl29028: change sampling frequencies available to use decimals

[Brian Masney]

The sysfs attribute in_proximity_sampling_frequency_available currently
shows the values 1 3 5 10 13 20 83 100. These values are supposed to
correspond to the sleep values 800 400 200 100 75 50 12 0 (all in ms).
When passing in a sampling frequency of 3, it actually uses a sleep
time of 200ms instead of the expected 400ms value. This patch changes
the value shown by this sysfs attribute to use decimal numbers so
that the correct sampling frequency is shown to the user. Only the
integer portion is actually passed to isl29028_set_proxim_sampling(),
but that is ok since the correct sleep time will still be selected.

Signed-off-by: Brian Masney 
---
 drivers/staging/iio/light/isl29028.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/iio/light/isl29028.c 
b/drivers/staging/iio/light/isl29028.c
index 5375e7a..c1d6540 100644
--- a/drivers/staging/iio/light/isl29028.c
+++ b/drivers/staging/iio/light/isl29028.c
@@ -472,7 +472,7 @@ static int isl29028_read_raw(struct iio_dev *indio_dev,
 }
 
 static IIO_CONST_ATTR(in_proximity_sampling_frequency_available,
-   "1 3 5 10 13 20 83 100");
+   "1.25 2.5 5 10 13.3 20 83.3 100");
 static IIO_CONST_ATTR(in_illuminance_scale_available, "125 2000");
 
 #define ISL29028_CONST_ATTR(name) (&iio_const_attr_##name.dev_attr.attr)
-- 
2.9.3

[PATCH v2 2/2] staging: iio: isl29028: move out of staging

[Brian Masney]

Move ISL29028 ALS / Proximity Sensor out of staging and into mainline.

Signed-off-by: Brian Masney 
---
 drivers/iio/light/Kconfig  | 10 ++
 drivers/iio/light/Makefile |  1 +
 drivers/{staging => }/iio/light/isl29028.c |  0
 drivers/staging/iio/light/Kconfig  | 10 --
 drivers/staging/iio/light/Makefile |  1 -
 5 files changed, 11 insertions(+), 11 deletions(-)
 rename drivers/{staging => }/iio/light/isl29028.c (100%)

diff --git a/drivers/iio/light/Kconfig b/drivers/iio/light/Kconfig
index 2afcbac..8b8c9e2 100644
--- a/drivers/iio/light/Kconfig
+++ b/drivers/iio/light/Kconfig
@@ -172,6 +172,16 @@ config SENSORS_ISL29018
 in lux, proximity infrared sensing and normal infrared sensing.
 Data from sensor is accessible via sysfs.
 
+config SENSORS_ISL29028
+   tristate "Intersil ISL29028 Concurrent Light and Proximity Sensor"
+   depends on I2C
+   select REGMAP_I2C
+   help
+Provides driver for the Intersil's ISL29028 device.
+This driver supports the sysfs interface to get the ALS, IR intensity,
+Proximity value via iio. The ISL29028 provides the concurrent sensing
+of ambient light and proximity.
+
 config ISL29125
tristate "Intersil ISL29125 digital color light sensor"
depends on I2C
diff --git a/drivers/iio/light/Makefile b/drivers/iio/light/Makefile
index edfd69b..2e730af 100644
--- a/drivers/iio/light/Makefile
+++ b/drivers/iio/light/Makefile
@@ -20,6 +20,7 @@ obj-$(CONFIG_GP2AP020A00F)+= gp2ap020a00f.o
 obj-$(CONFIG_HID_SENSOR_ALS)   += hid-sensor-als.o
 obj-$(CONFIG_HID_SENSOR_PROX)  += hid-sensor-prox.o
 obj-$(CONFIG_SENSORS_ISL29018) += isl29018.o
+obj-$(CONFIG_SENSORS_ISL29028) += isl29028.o
 obj-$(CONFIG_ISL29125) += isl29125.o
 obj-$(CONFIG_JSA1212)  += jsa1212.o
 obj-$(CONFIG_SENSORS_LM3533)   += lm3533-als.o
diff --git a/drivers/staging/iio/light/isl29028.c b/drivers/iio/light/isl29028.c
similarity index 100%
rename from drivers/staging/iio/light/isl29028.c
rename to drivers/iio/light/isl29028.c
diff --git a/drivers/staging/iio/light/Kconfig 
b/drivers/staging/iio/light/Kconfig
index 4fbf629..aacb0ae 100644
--- a/drivers/staging/iio/light/Kconfig
+++ b/drivers/staging/iio/light/Kconfig
@@ -3,16 +3,6 @@
 #
 menu "Light sensors"
 
-config SENSORS_ISL29028
-   tristate "Intersil ISL29028 Concurrent Light and Proximity Sensor"
-   depends on I2C
-   select REGMAP_I2C
-   help
-Provides driver for the Intersil's ISL29028 device.
-This driver supports the sysfs interface to get the ALS, IR intensity,
-Proximity value via iio. The ISL29028 provides the concurrent sensing
-of ambient light and proximity.
-
 config TSL2x7x
tristate "TAOS TSL/TMD2x71 and TSL/TMD2x72 Family of light and 
proximity sensors"
depends on I2C
diff --git a/drivers/staging/iio/light/Makefile 
b/drivers/staging/iio/light/Makefile
index f8693e9..10286c3 100644
--- a/drivers/staging/iio/light/Makefile
+++ b/drivers/staging/iio/light/Makefile
@@ -2,5 +2,4 @@
 # Makefile for industrial I/O Light sensors
 #
 
-obj-$(CONFIG_SENSORS_ISL29028) += isl29028.o
 obj-$(CONFIG_TSL2x7x)  += tsl2x7x_core.o
-- 
2.9.3

[PATCH v2 0/2] staging: iio: isl29028: move out of staging

[Brian Masney]

This is hopefully the last of the changes that are needed to move
this driver out of staging.

Datasheet:

http://www.intersil.com/content/dam/Intersil/documents/isl2/isl29028.pdf

Changes since v1:
- in_proximity_sampling_frequency_available sysfs attribute now shows
  decimals.

Brian Masney (2):
  staging: iio: isl29028: change sampling frequencies available to use
decimals
  staging: iio: isl29028: move out of staging

 drivers/iio/light/Kconfig  | 10 ++
 drivers/iio/light/Makefile |  1 +
 drivers/{staging => }/iio/light/isl29028.c |  2 +-
 drivers/staging/iio/light/Kconfig  | 10 --
 drivers/staging/iio/light/Makefile |  1 -
 5 files changed, 12 insertions(+), 12 deletions(-)
 rename drivers/{staging => }/iio/light/isl29028.c (99%)

-- 
2.9.3

Re: [PATCH 1/2] arch/x86: Fix sparse warning symbol not declared

[Thomas Gleixner]

On Sun, 12 Feb 2017, Tobin C. Harding wrote:

A few nitpicks.

> Subject: [PATCH 1/2] arch/x86: Fix sparse warning symbol not declared

arch/x86: is not the correct prefix. Run git log on a file to figure out
what the usual prefix is. The file was checked in with 'purgatory', but I'd
prefer 'x86/purgatory' for future changes.

> This patch adds static declaration to a number of variables. Fixes
> sparse symbol was not declared warnings.

Please read 'Documentation...SubmittingPatches' and look for 'This patch'.

I give you an example for a changelog:

  Sparse emits several 'symbol not declared' warnings.

  Make the variables and functions, which have only file scope static.

Now try to map that to the advise in Documentation.

Thanks,

tglx

Re: [PATCH v2 2/2] staging: iio: isl29028: move out of staging

[Brian Masney]

On Sun, Feb 12, 2017 at 05:55:34AM -0500, Brian Masney wrote:
> Move ISL29028 ALS / Proximity Sensor out of staging and into mainline.
> 
> Signed-off-by: Brian Masney 

Sorry, Jonathan, I forgot to run git format-patch with --no-renames and
didn't realize until the emails went out. I attached the driver source
to make it easier to review inline.

Brian
/*
 * IIO driver for the light sensor ISL29028.
 * ISL29028 is Concurrent Ambient Light and Proximity Sensor
 *
 * Copyright (c) 2012, NVIDIA CORPORATION.  All rights reserved.
 * Copyright (c) 2016-2017 Brian Masney 
 *
 * This program is free software; you can redistribute it and/or modify it
 * under the terms and conditions of the GNU General Public License,
 * version 2, as published by the Free Software Foundation.
 *
 * This program is distributed in the hope it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
 * more details.
 *
 * You should have received a copy of the GNU General Public License
 * along with this program.  If not, see .
 */

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#define ISL29028_CONV_TIME_MS			100

#define ISL29028_REG_CONFIGURE			0x01

#define ISL29028_CONF_ALS_IR_MODE_ALS		0
#define ISL29028_CONF_ALS_IR_MODE_IR		BIT(0)
#define ISL29028_CONF_ALS_IR_MODE_MASK		BIT(0)

#define ISL29028_CONF_ALS_RANGE_LOW_LUX		0
#define ISL29028_CONF_ALS_RANGE_HIGH_LUX	BIT(1)
#define ISL29028_CONF_ALS_RANGE_MASK		BIT(1)

#define ISL29028_CONF_ALS_DIS			0
#define ISL29028_CONF_ALS_EN			BIT(2)
#define ISL29028_CONF_ALS_EN_MASK		BIT(2)

#define ISL29028_CONF_PROX_SLP_SH		4
#define ISL29028_CONF_PROX_SLP_MASK		(7 << ISL29028_CONF_PROX_SLP_SH)

#define ISL29028_CONF_PROX_EN			BIT(7)
#define ISL29028_CONF_PROX_EN_MASK		BIT(7)

#define ISL29028_REG_INTERRUPT			0x02

#define ISL29028_REG_PROX_DATA			0x08
#define ISL29028_REG_ALSIR_L			0x09
#define ISL29028_REG_ALSIR_U			0x0A

#define ISL29028_REG_TEST1_MODE			0x0E
#define ISL29028_REG_TEST2_MODE			0x0F

#define ISL29028_NUM_REGS			(ISL29028_REG_TEST2_MODE + 1)

#define ISL29028_POWER_OFF_DELAY_MS		2000

static const unsigned int isl29028_prox_sleep_time[] = {800, 400, 200, 100, 75,
			50, 12, 0};

enum isl29028_als_ir_mode {
	ISL29028_MODE_NONE = 0,
	ISL29028_MODE_ALS,
	ISL29028_MODE_IR,
};

struct isl29028_chip {
	struct mutex			lock;
	struct regmap			*regmap;
	unsigned int			prox_sampling;
	boolenable_prox;
	intlux_scale;
	enum isl29028_als_ir_mode	als_ir_mode;
};

static int isl29028_find_prox_sleep_time_index(int sampling)
{
	unsigned int period = DIV_ROUND_UP(1000, sampling);
	int i;

	for (i = 0; i < ARRAY_SIZE(isl29028_prox_sleep_time); ++i) {
		if (period >= isl29028_prox_sleep_time[i])
			break;
	}

	return i;
}

static int isl29028_set_proxim_sampling(struct isl29028_chip *chip,
	unsigned int sampling)
{
	struct device *dev = regmap_get_device(chip->regmap);
	int sleep_index, ret;

	sleep_index = isl29028_find_prox_sleep_time_index(sampling);
	ret = regmap_update_bits(chip->regmap, ISL29028_REG_CONFIGURE,
 ISL29028_CONF_PROX_SLP_MASK,
 sleep_index << ISL29028_CONF_PROX_SLP_SH);

	if (ret < 0) {
		dev_err(dev, "%s(): Error %d setting the proximity sampling\n",
			__func__, ret);
		return ret;
	}

	chip->prox_sampling = sampling;

	return ret;
}

static int isl29028_enable_proximity(struct isl29028_chip *chip)
{
	int sleep_index, ret;

	ret = isl29028_set_proxim_sampling(chip, chip->prox_sampling);
	if (ret < 0)
		return ret;

	ret = regmap_update_bits(chip->regmap, ISL29028_REG_CONFIGURE,
 ISL29028_CONF_PROX_EN_MASK,
 ISL29028_CONF_PROX_EN);
	if (ret < 0)
		return ret;

	/* Wait for conversion to be complete for first sample */
	sleep_index = isl29028_find_prox_sleep_time_index(chip->prox_sampling);
	msleep(isl29028_prox_sleep_time[sleep_index]);

	return 0;
}

static int isl29028_set_als_scale(struct isl29028_chip *chip, int lux_scale)
{
	struct device *dev = regmap_get_device(chip->regmap);
	int val = (lux_scale == 2000) ? ISL29028_CONF_ALS_RANGE_HIGH_LUX :
	ISL29028_CONF_ALS_RANGE_LOW_LUX;
	int ret;

	ret = regmap_update_bits(chip->regmap, ISL29028_REG_CONFIGURE,
 ISL29028_CONF_ALS_RANGE_MASK, val);
	if (ret < 0) {
		dev_err(dev, "%s(): Error %d setting the ALS scale\n", __func__,
			ret);
		return ret;
	}

	chip->lux_scale = lux_scale;

	return ret;
}

static int isl29028_set_als_ir_mode(struct isl29028_chip *chip,
enum isl29028_als_ir_mode mode)
{
	int ret;

	if (chip->als_ir_mode == mode)
		return 0;

	ret = isl29028_set_als_scale(chip, chip->lux_scale);
	if (ret < 0)
		return ret;

	switch (mode) {
	case ISL29028_MODE_ALS:
		ret = regmap_update_bits(chip->regmap, ISL29028_REG_CONFIGURE,
	 ISL29028_CONF_ALS_IR_MODE_MASK,
	 ISL29028_CONF_ALS_IR_MODE_ALS);
		if (ret < 0)
			return ret;

		ret = regmap_update_bits(chip->re

Re: [PATCH v4 1/7] drm: Add DRM support for tiny LCD displays

[Andy Shevchenko]

On Sat, Feb 11, 2017 at 8:48 PM, Noralf Trønnes  wrote:
> tinydrm provides helpers for very simple displays that can use
> CMA backed framebuffers and need flushing on changes.

> +/**

> + * tinydrm_gem_cma_free_object - Free resources associated with a CMA GEM
> + *   object

Keep on one line?

> +const struct file_operations tinydrm_fops = {

> +   .owner  = THIS_MODULE,

Do we still need this?

> +static int tinydrm_init(struct device *parent, struct tinydrm_device *tdev,
> +   const struct drm_framebuffer_funcs *fb_funcs,
> +   struct drm_driver *driver)
> +{
> +   struct drm_device *drm;
> +
> +   mutex_init(&tdev->dirty_lock);
> +   tdev->fb_funcs = fb_funcs;
> +
> +   /*
> +* We don't embed drm_device, because that prevent us from using
> +* devm_kzalloc() to allocate tinydrm_device in the driver since

> +* drm_dev_unref() frees the structure. The devm_ functions provide

"devm_ functions" -> "devm_kzalloc()" ?

Otherwise what else do you refer to and why here?

> +* for easy error handling.
> +*/

> +static int tinydrm_register(struct tinydrm_device *tdev)
> +{
> +   struct drm_device *drm = tdev->drm;
> +   int bpp = drm->mode_config.preferred_depth;
> +   struct drm_fbdev_cma *fbdev;
> +   int ret;
> +
> +   ret = drm_dev_register(tdev->drm, 0);
> +   if (ret)
> +   return ret;
> +
> +   fbdev = drm_fbdev_cma_init_with_funcs(drm, bpp ? bpp : 32,
> + drm->mode_config.num_connector,
> + tdev->fb_funcs);

> +   if (IS_ERR(fbdev))
> +   DRM_ERROR("Failed to initialize fbdev: %ld\n", 
> PTR_ERR(fbdev));
> +   else
> +   tdev->fbdev_cma = fbdev;

Apparently I missed previous round of reviews, can you just put in
short words why error is not propagated here to the caller?

> +
> +   return 0;
> +}

> +/**
> + * tinydrm_display_pipe_init - Initialize display pipe
> + * @tdev: tinydrm device
> + * @funcs: Display pipe functions
> + * @connector_type: Connector type

> + * @formats: Array of supported formats (DRM_FORMAT\_\*)

DRM_FORMAT_* ?

> + * @format_count: Number of elements in @formats
> + * @mode: Supported mode
> + * @rotation: Initial @mode rotation in degrees Counter Clock Wise
> + *
> + * This function sets up a &drm_simple_display_pipe with a &drm_connector 
> that
> + * has one fixed &drm_display_mode which is rotated according to @rotation.
> + *
> + * Returns:
> + * Zero on success, negative error code on failure.
> + */

> +{
> +   struct drm_device *drm = tdev->drm;
> +   struct drm_display_mode *mode_copy;
> +   struct drm_connector *connector;
> +   int ret;

> +   connector = tinydrm_connector_create(drm, mode_copy, connector_type);
> +   if (IS_ERR(connector))
> +   return PTR_ERR(connector);
> +

> +   ret = drm_simple_display_pipe_init(drm, &tdev->pipe, funcs, formats,
> +  format_count, connector);
> +   if (ret)
> +   return ret;
> +
> +   return 0;

return drm_... ?

> +}
> +EXPORT_SYMBOL(tinydrm_display_pipe_init);

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH 2/2] arch/x86: Fix sparse warning symbol not declared

[Thomas Gleixner]

On Sun, 12 Feb 2017, Tobin C. Harding wrote:

> This patch adds function declaration in order to quiet sparse symbol
> not declared warning.

Same comment vs. 'This patch' as before. Hint, we already know that this is
a patch, otherwise it would be mislabeled.

> 
> Signed-off-by: Tobin C. Harding 
> ---
> 
> Unsure why adding declaration quiets sparse.

Because sparse finds a declaration before the definition.

> This may not be the correct solution.

Right, it's not.

> Only testing done is building and booting kernel.  Since 'purgatory' is
> called from assembler and does not need forward declaration the only
> advantage to this patch seems to be to save the next newbie from
> investigating the sparse warning.

Well, yes. But just quietening a checker by slapping a pointless forward
declaration into the code is not pretty either. A smarter checker might
catch that.

The proper solution is to have a local include file 'purgatory.h' and put
the declaration there. Include it in both files even if that's not required
for the ASM file. But that documents, that the function is used outside of
purgatory.c

Thanks,

tglx

Re: [PATCH v3 net-next 1/9] sunvnet: make sunvnet common code dynamically loadable

[Sergei Shtylyov]

Hello!

On 2/10/2017 8:38 PM, Shannon Nelson wrote:


When the sunvnet_common code was split out for use by both sunvnet
and the newer ldmvsw, it was made into a static kernel library, which
limits the usefulness of sunvnet and ldmvsw as loadables, since most
of the real work is being done in the shared code.  Also, this is
simply dead code in kernels that aren't running the LDoms.

This patch makes the sunvnet_common into a dynamically loadable
module and makes sunvnet and ldmvsw dependent on sunvnet_common.

Signed-off-by: Shannon Nelson 
---
 drivers/net/ethernet/sun/Kconfig  |8 ++--
 drivers/net/ethernet/sun/sunvnet_common.c |5 +
 2 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/sun/Kconfig b/drivers/net/ethernet/sun/Kconfig
index a4b40e3..a7d91da 100644
--- a/drivers/net/ethernet/sun/Kconfig
+++ b/drivers/net/ethernet/sun/Kconfig
@@ -70,19 +70,23 @@ config CASSINI
  
.

 config SUNVNET_COMMON
-   bool
+   tristate "Common routines to support Sun Virtual Networking"
depends on SUN_LDOMS
-   default y if SUN_LDOMS
+   default m if SUN_LDOMS


   Sounds tautological... maybe just "default m"?

[...]

MBR, Sergei

Re: [PATCH v7 0/5] Update LZ4 compressor module

[Sven Schmidt]

On 02/10/2017 01:13 AM, Minchan Kim wrote:
> Hello Sven,
>
> On Thu, Feb 09, 2017 at 11:56:17AM +0100, Sven Schmidt wrote:
>> Hey Minchan,
>>
>> On Thu, Feb 09, 2017 at 08:31:21AM +0900, Minchan Kim wrote:
>>> Hello Sven,
>>>
>>> On Sun, Feb 05, 2017 at 08:09:03PM +0100, Sven Schmidt wrote:

 This patchset is for updating the LZ4 compression module to a version based
 on LZ4 v1.7.3 allowing to use the fast compression algorithm aka LZ4 fast
 which provides an "acceleration" parameter as a tradeoff between
 high compression ratio and high compression speed.

 We want to use LZ4 fast in order to support compression in lustre
 and (mostly, based on that) investigate data reduction techniques in 
 behalf of
 storage systems.

 Also, it will be useful for other users of LZ4 compression, as with LZ4 
 fast
 it is possible to enable applications to use fast and/or high compression
 depending on the usecase.
 For instance, ZRAM is offering a LZ4 backend and could benefit from an 
 updated
 LZ4 in the kernel.

 LZ4 homepage: http://www.lz4.org/
 LZ4 source repository: https://github.com/lz4/lz4
 Source version: 1.7.3

 Benchmark (taken from [1], Core i5-4300U @1.9GHz):
 |--||--
 Compressor  | Compression  | Decompression  | Ratio
 |--||--
 memcpy  |  4200 MB/s   |  4200 MB/s | 1.000
 LZ4 fast 50 |  1080 MB/s   |  2650 MB/s | 1.375
 LZ4 fast 17 |   680 MB/s   |  2220 MB/s | 1.607
 LZ4 fast 5  |   475 MB/s   |  1920 MB/s | 1.886
 LZ4 default |   385 MB/s   |  1850 MB/s | 2.101

 [1] http://fastcompression.blogspot.de/2015/04/sampling-or-faster-lz4.html

 [PATCH 1/5] lib: Update LZ4 compressor module
 [PATCH 2/5] lib/decompress_unlz4: Change module to work with new LZ4 
 module version
 [PATCH 3/5] crypto: Change LZ4 modules to work with new LZ4 module version
 [PATCH 4/5] fs/pstore: fs/squashfs: Change usage of LZ4 to work with new 
 LZ4 version
 [PATCH 5/5] lib/lz4: Remove back-compat wrappers
>>>
>>> Today, I did zram-lz4 performance test with fio in current mmotm and
>>> found it makes regression about 20%.
>>>
>>> "lz4-update" means current mmots(git://git.cmpxchg.org/linux-mmots.git) so
>>> applied your 5 patches. (But now sure current mmots has recent uptodate
>>> patches)
>>> "revert" means I reverted your 5 patches in current mmots.
>>>
>>>  revertlz4-update
>>>
>>>   seq-write   1547   1339  86.55%
>>>  rand-write  22775  19381  85.10%
>>>seq-read   7035   5589  79.45%
>>>   rand-read  78556  68479  87.17%
>>>mixed-seq(R)   1305   1066  81.69%
>>>mixed-seq(W)   1205984  81.66%
>>>   mixed-rand(R)  17421  14993  86.06%
>>>   mixed-rand(W)  17391  14968  86.07%
>>
>> which parts of the output (as well as units) are these values exactly?
>> I did not work with fio until now, so I think I might ask before 
>> misinterpreting my results.
>
> It is IOPS.
>
>>  
>>> My fio description file
>>>
>>> [global]
>>> bs=4k
>>> ioengine=sync
>>> size=100m
>>> numjobs=1
>>> group_reporting
>>> buffer_compress_percentage=30
>>> scramble_buffers=0
>>> filename=/dev/zram0
>>> loops=10
>>> fsync_on_close=1
>>>
>>> [seq-write]
>>> bs=64k
>>> rw=write
>>> stonewall
>>>
>>> [rand-write]
>>> rw=randwrite
>>> stonewall
>>>
>>> [seq-read]
>>> bs=64k
>>> rw=read
>>> stonewall
>>>
>>> [rand-read]
>>> rw=randread
>>> stonewall
>>>
>>> [mixed-seq]
>>> bs=64k
>>> rw=rw
>>> stonewall
>>>
>>> [mixed-rand]
>>> rw=randrw
>>> stonewall
>>>
>>
>> Great, this makes it easy for me to reproduce your test.
>
> If you have trouble to reproduce, feel free to ask me. I'm happy to test it. 
> :)
>
> Thanks!
>

Hi Minchan,

I will send an updated patch as a reply to this E-Mail. Would be really 
grateful If you'd test it and provide feedback!
The patch should be applied to the current mmots tree.

In fact, the updated LZ4 _is_ slower than the current one in kernel. But I was 
not able to reproduce such large regressions
as you did. I now tried to define FORCE_INLINE as Eric suggested. I also 
inlined some functions which weren't in upstream LZ4,
but are defined as macros in the current kernel LZ4. The approach to replace 
LZ4_ARCH64 with the function call _seemed_ to behave
worse than the macro, so I withdrew the change.

The main difference is, that I replaced the read32/read16/write... etc. 
functions using memcpy with the other ones defined 
in upstream LZ4 (which can be switched using a macro). 
The comment of the author stated, that they're as fast as the memcpy variants 
(or faster), but not as portable
(which does not matter since we're not dependent for multiple compilers).

In m

[PATCH] lz4: fix performance regressions

[Sven Schmidt]

Fix performance regressions compared to current kernel LZ4

Signed-off-by: Sven Schmidt <4ssch...@informatik.uni-hamburg.de>
---
 include/linux/lz4.h  |   2 +-
 lib/lz4/lz4_compress.c   | 157 +++-
 lib/lz4/lz4_decompress.c |  50 
 lib/lz4/lz4defs.h| 203 ---
 lib/lz4/lz4hc_compress.c |   8 +-
 5 files changed, 281 insertions(+), 139 deletions(-)

diff --git a/include/linux/lz4.h b/include/linux/lz4.h
index a3912d7..394e3d9 100644
--- a/include/linux/lz4.h
+++ b/include/linux/lz4.h
@@ -82,7 +82,7 @@
 /*-
  * STREAMING CONSTANTS AND STRUCTURES
  **/
-#define LZ4_STREAMSIZE_U64 ((1 << (LZ4_MEMORY_USAGE-3)) + 4)
+#define LZ4_STREAMSIZE_U64 ((1 << (LZ4_MEMORY_USAGE - 3)) + 4)
 #define LZ4_STREAMSIZE (LZ4_STREAMSIZE_U64 * sizeof(unsigned long long))

 #define LZ4_STREAMHCSIZE262192
diff --git a/lib/lz4/lz4_compress.c b/lib/lz4/lz4_compress.c
index 697dbda..2cbbf99 100644
--- a/lib/lz4/lz4_compress.c
+++ b/lib/lz4/lz4_compress.c
@@ -39,27 +39,33 @@
 #include 
 #include 

+static const int LZ4_minLength = (MFLIMIT + 1);
+static const int LZ4_64Klimit = ((64 * KB) + (MFLIMIT - 1));
+
 /*-**
  * Compression functions
  /
-static U32 LZ4_hash4(U32 sequence, tableType_t const tableType)
+static FORCE_INLINE U32 LZ4_hash4(
+   U32 sequence,
+   tableType_t const tableType)
 {
if (tableType == byU16)
return ((sequence * 2654435761U)
-   >> ((MINMATCH*8) - (LZ4_HASHLOG + 1)));
+   >> ((MINMATCH * 8) - (LZ4_HASHLOG + 1)));
else
return ((sequence * 2654435761U)
-   >> ((MINMATCH*8) - LZ4_HASHLOG));
+   >> ((MINMATCH * 8) - LZ4_HASHLOG));
 }

-#if LZ4_ARCH64
-static U32 LZ4_hash5(U64 sequence, tableType_t const tableType)
+static FORCE_INLINE __maybe_unused U32 LZ4_hash5(
+   U64 sequence,
+   tableType_t const tableType)
 {
const U32 hashLog = (tableType == byU16)
? LZ4_HASHLOG + 1
: LZ4_HASHLOG;

-#ifdef __LITTLE_ENDIAN__
+#if LZ4_LITTLE_ENDIAN
static const U64 prime5bytes = 889523592379ULL;

return (U32)(((sequence << 24) * prime5bytes) >> (64 - hashLog));
@@ -69,9 +75,10 @@ static U32 LZ4_hash5(U64 sequence, tableType_t const 
tableType)
return (U32)(((sequence >> 24) * prime8bytes) >> (64 - hashLog));
 #endif
 }
-#endif

-static U32 LZ4_hashPosition(const void *p, tableType_t tableType)
+static FORCE_INLINE U32 LZ4_hashPosition(
+   const void *p,
+   tableType_t const tableType)
 {
 #if LZ4_ARCH64
if (tableType == byU32)
@@ -81,8 +88,12 @@ static U32 LZ4_hashPosition(const void *p, tableType_t 
tableType)
return LZ4_hash4(LZ4_read32(p), tableType);
 }

-static void LZ4_putPositionOnHash(const BYTE *p, U32 h, void *tableBase,
-   tableType_t const tableType, const BYTE *srcBase)
+static void LZ4_putPositionOnHash(
+   const BYTE *p,
+   U32 h,
+   void *tableBase,
+   tableType_t const tableType,
+   const BYTE *srcBase)
 {
switch (tableType) {
case byPtr:
@@ -109,16 +120,22 @@ static void LZ4_putPositionOnHash(const BYTE *p, U32 h, 
void *tableBase,
}
 }

-static inline void LZ4_putPosition(const BYTE *p, void *tableBase,
-   tableType_t tableType, const BYTE *srcBase)
+static FORCE_INLINE void LZ4_putPosition(
+   const BYTE *p,
+   void *tableBase,
+   tableType_t tableType,
+   const BYTE *srcBase)
 {
U32 const h = LZ4_hashPosition(p, tableType);

LZ4_putPositionOnHash(p, h, tableBase, tableType, srcBase);
 }

-static const BYTE *LZ4_getPositionOnHash(U32 h, void *tableBase,
-   tableType_t tableType, const BYTE *srcBase)
+static const BYTE *LZ4_getPositionOnHash(
+   U32 h,
+   void *tableBase,
+   tableType_t tableType,
+   const BYTE *srcBase)
 {
if (tableType == byPtr) {
const BYTE **hashTable = (const BYTE **) tableBase;
@@ -135,12 +152,16 @@ static const BYTE *LZ4_getPositionOnHash(U32 h, void 
*tableBase,
{
/* default, to ensure a return */
const U16 * const hashTable = (U16 *) tableBase;
+
return hashTable[h] + srcBase;
}
 }

-static inline const BYTE *LZ4_getPosition(const BYTE *p, void *tableBase,
-   tableType_t tableType, const BYTE *srcBase)
+static FORCE_INLINE const BYTE *LZ4_getPosition(
+   const BYTE *p,
+   void *tableBase,
+   tableType_t tableType,
+   const BYTE *srcBase)
 {
U32 const h = LZ4_hashPosition(p, tableType);

@@ -152,7 +173,7 @@ static inline const BYTE *LZ4_getPosition(const BYTE *p, 
void *tableBase,
  * LZ4_compress_generi

Re: [PATCH v4 2/7] drm/tinydrm: Add helper functions

[Andy Shevchenko]

On Sat, Feb 11, 2017 at 8:48 PM, Noralf Trønnes  wrote:
> Add common functionality needed by many tinydrm drivers.

> +int tinydrm_enable_backlight(struct backlight_device *backlight)
> +{
> +   unsigned int old_state;
> +   int ret;
> +
> +   if (!backlight)
> +   return 0;
> +
> +   old_state = backlight->props.state;
> +   backlight->props.state &= ~BL_CORE_FBBLANK;
> +   DRM_DEBUG_KMS("Backlight state: 0x%x -> 0x%x\n", old_state,
> + backlight->props.state);

"%#x" ?
(And elsewhere)

> +#if IS_ENABLED(CONFIG_SPI)

> +size_t tinydrm_spi_max_transfer_size(struct spi_device *spi, size_t max_len)
> +{
> +   size_t ret;
> +

> +   ret = min(spi_max_transfer_size(spi), spi->master->max_dma_len);

I don't get why DMA constrain somehow affects this framework?

What if max_dma_len is zero (imagine SPI master that works only by PIO
by some reason)?

> +   if (max_len)
> +   ret = min(ret, max_len);
> +   if (spi_max)
> +   ret = min_t(size_t, ret, spi_max);

> +   ret &= ~0x3;

Why alignment is that? Why do we need it? Isn't a busyness of SPI
framework to cope with it?

> +   if (ret < 4)

It's effectively check for 0.

> +   ret = 4;
> +
> +   return ret;

> +}
> +EXPORT_SYMBOL(tinydrm_spi_max_transfer_size);

> +static void
> +tinydrm_dbg_spi_print(struct spi_device *spi, struct spi_transfer *tr,
> + const void *buf, int idx, bool tx)
> +{
> +   u32 speed_hz = tr->speed_hz ? tr->speed_hz : spi->max_speed_hz;
> +   char linebuf[3 * 32];
> +

> +   hex_dump_to_buffer(buf, tr->len, 16,
> +  DIV_ROUND_UP(tr->bits_per_word, 8),
> +  linebuf, sizeof(linebuf), false);

> +
> +   printk(KERN_DEBUG
> +  "tr(%i): speed=%u%s, bpw=%i, len=%u, %s_buf=[%s%s]\n", idx,
> +  speed_hz > 100 ? speed_hz / 100 : speed_hz / 1000,
> +  speed_hz > 100 ? "MHz" : "kHz", tr->bits_per_word, tr->len,
> +  tx ? "tx" : "rx", linebuf, tr->len > 16 ? " ..." : "");

I hope at some point we will have some extension to print speeds,
sizes and so on based on algo in string_get_size().

> +}

> +int tinydrm_spi_transfer(struct spi_device *spi, u32 speed_hz,
> +struct spi_transfer *header, u8 bpw, const void *buf,
> +size_t len)
> +{
> +   struct spi_transfer tr = {
> +   .bits_per_word = bpw,
> +   .speed_hz = speed_hz,
> +   };
> +   struct spi_message m;
> +   u16 *swap_buf = NULL;
> +   size_t max_chunk;
> +   size_t chunk;
> +   int ret = 0;
> +
> +   if (WARN_ON_ONCE(bpw != 8 && bpw != 16))
> +   return -EINVAL;
> +
> +   max_chunk = tinydrm_spi_max_transfer_size(spi, 0);
> +

> +   if (drm_debug & DRM_UT_DRIVER)
> +   pr_debug("[drm:%s] bpw=%u, max_chunk=%zu, transfers:\n",
> +__func__, bpw, max_chunk);

For all of your dev_dbg() / pr_debug() __func__ argument might be
redundant. Dynamic Debug may include this by request from user.

> +/**
> + * tinydrm_machine_little_endian - Machine is little endian
> + *
> + * Returns:
> + * true if *defined(__LITTLE_ENDIAN)*, false otherwise
> + */
> +static inline bool tinydrm_machine_little_endian(void)
> +{
> +#if defined(__LITTLE_ENDIAN)
> +   return true;
> +#else
> +   return false;
> +#endif
> +}

Hmm... What is the typical code of a caller for this?

-- 
With Best Regards,
Andy Shevchenko

Re: v4.10-rc6 boot regression on Intel desktop, does not boot after cold boots, boots after reboot

[Pavel Machek]

Hi!

> > > > > Aha. So it looks difference is probably in "where is keyboard plugged
> > > > > in" but in "reboot" vs. "cold boot". I did not do a cold boot in quite
> > > > > a while :-(.
> > > > > 
> > > > > Booting to grub, then hitting ctrl-alt-del is enough to make it work. 
> > > > > Ouch.
> > > > > 
> > > > > It happens with current Linus' tree.
> > > > 
> > > > v4.10-rc6-feb3 : broken
> > > > v4.9 : ok
> > > > (v4.6 : ok)
> > > 
> > > All I can suggest is git bisect.  :-(  But I agree that the problem is 
> > > unlikely to be in the USB layer.
> > 
> > Yep. I'm hoping PCI people speak up adding printks there should be
> > possibility, too.
> > 
> > (And I guess I should remove you and usb people from the cc-list... in
> > the next mails).
> > 
> > (I verified it happens with 32bit configuration, too, FWIW).
> 
> v4.10-rc1 seems to work.

No, it is somehow harder to test. It is only problem after some cold
boots.

Today machine was off for few hours, and then v4.10-rc7 failed to
boot. On next reboot, I waited for grub, hit ctrl-alt-del, and it
booted ok.

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

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

[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:   1ce42845f987e92eabfc6e026d44d826c25c74a5
commit: ab9d1e4f7b0217948a3b35a64178602ab30ff45d Merge branch 
'xfs-misc-fixes-4.6-3' into for-next
date:   11 months ago
config: openrisc-allyesconfig (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 2/3] staging: lustre: llite: root inode checking for migration

[Greg Kroah-Hartman]

On Sat, Feb 11, 2017 at 12:12:38PM -0500, James Simmons wrote:
> From: wang di 
> 
> Do not migrate root inode.

That says _what_ happens here, but you aren't giving any hint as to
_why_ this is needed.

I'll take this, but be more careful about your changelog comments in the
future...

thanks,

greg k-h

Re: [PATCH] bcm2835-audio: Fix checkpatch errors

[Greg Kroah-Hartman]

On Sun, Feb 12, 2017 at 04:34:09AM +0800, Man Choy wrote:
> Fix following errors:
> 
> ERROR: do not initialise statics to NULL
> +static struct snd_card *g_card = NULL;
> 
> ERROR: do not initialise statics to NULL
> +static struct bcm2835_chip *g_chip = NULL;
> 
> Signed-off-by: Man Choy 
> ---
>  drivers/staging/bcm2835-audio/bcm2835.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/staging/bcm2835-audio/bcm2835.c 
> b/drivers/staging/bcm2835-audio/bcm2835.c
> index a84d74d..265fe55 100644
> --- a/drivers/staging/bcm2835-audio/bcm2835.c
> +++ b/drivers/staging/bcm2835-audio/bcm2835.c
> @@ -28,8 +28,8 @@
>   * to debug if we run into issues
>   */
>  
> -static struct snd_card *g_card = NULL;
> -static struct bcm2835_chip *g_chip = NULL;
> +static struct snd_card *g_card;
> +static struct bcm2835_chip *g_chip;
>  
>  static int snd_bcm2835_free(struct bcm2835_chip *chip)
>  {

Someone sent this same fix in before you did, a few days ago.  Be sure
to always use the most up-to-date tree.

sorry,

greg k-h

Re: [PATCH] Staging: media: bcm2048: Fixed an error

[Greg KH]

On Sat, Feb 11, 2017 at 12:41:29AM +0200, Ran Algawi wrote:
> Fixed an error where the system was given a code in the form of decimal
> instead of octal.

It's not really an "error", right?  Please be more descriptive of
exactly what is going on here (hint, it's a coding style warning...)

thanks,

greg k-h

RE: [PATCH 1/2] include: Fix checkpatch whitespace error and warning

[Matthew Wilcox]

Don't worry about this file; I have a complete rewrite already queued.

> -Original Message-
> From: Tobin C. Harding [mailto:m...@tobin.cc]
> Sent: Saturday, February 11, 2017 9:58 PM
> To: David S . Miller 
> Cc: Matthew Wilcox ; net...@vger.kernel.org;
> linux-kernel@vger.kernel.org; Tobin C. Harding 
> Subject: [PATCH 1/2] include: Fix checkpatch whitespace error and warning
> 
> This patch fixes two trivial whitespace messages (ERROR/WARNING).
> Fixes trailing whitespace ERROR and fixes space before tabs WARNING.
> 
> Signed-off-by: Tobin C. Harding 
> ---
>  include/linux/idr.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/idr.h b/include/linux/idr.h
> index 3c01b89..4a8de2f 100644
> --- a/include/linux/idr.h
> +++ b/include/linux/idr.h
> @@ -1,6 +1,6 @@
>  /*
>   * include/linux/idr.h
> - *
> + *
>   * 2002-10-18  written by Jim Houston jim.hous...@ccur.com
>   *   Copyright (C) 2002 by Concurrent Computer Corporation
>   *   Distributed under the GNU GPL license version 2.
> @@ -183,7 +183,7 @@ static inline void *idr_find(struct idr *idr, int id)
>   */
>  #define IDA_CHUNK_SIZE   128 /* 128 bytes per chunk */
>  #define IDA_BITMAP_LONGS (IDA_CHUNK_SIZE / sizeof(long) - 1)
> -#define IDA_BITMAP_BITS  (IDA_BITMAP_LONGS * sizeof(long) * 8)
> +#define IDA_BITMAP_BITS (IDA_BITMAP_LONGS * sizeof(long) * 8)
> 
>  struct ida_bitmap {
>   longnr_busy;
> --
> 2.7.4

Re: [PATCH v5] fork: free vmapped stacks in cache when cpus are offline

[Thomas Gleixner]

On Sun, 12 Feb 2017, Hoeun Ryu wrote:
> 
> > On Feb 12, 2017, at 5:19 AM, Thomas Gleixner  wrote:
> > 
> >> On Sat, 11 Feb 2017, kbuild test robot wrote:
> >> 
> >> Hi Hoeun,
> >> 
> >> [auto build test ERROR on linus/master]
> >> [also build test ERROR on v4.10-rc7 next-20170210]
> >> [if your patch is applied to the wrong git tree, please drop us a note to 
> >> help improve the system]
> >> 
> >> url:
> >> https://github.com/0day-ci/linux/commits/Hoeun-Ryu/fork-free-vmapped-stacks-in-cache-when-cpus-are-offline/20170211-183401
> >> 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
> >># save the attached .config to linux build tree
> >>make.cross ARCH=ia64 
> >> 
> >> All errors (new ones prefixed by >>):
> >> 
> >>   kernel/fork.c: In function 'fork_init':
>  kernel/fork.c:483:2: error: implicit declaration of function 
>  'vm_stack_cache_init' [-Werror=implicit-function-declaration]
> >> vm_stack_cache_init();
> >> ^~~
> > 
> > Right. This needs to move to a different place as that part is nested inside
> > 
> > #ifndef CONFIG_ARCH_THREAD_STACK_ALLOCATOR
> > 
> > That's an horrible ifdef maze in that file.
> > 
> 
> I think we should rollback to v4. Do you agree?

Sigh. Yes.

[tip:locking/core 46/49] drivers/scsi/fcoe/fcoe_ctlr.c:3097:1: internal compiler error: in reload_cse_simplify_operands, at postreload.c:396

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git locking/core
head:   bc88c10d7e6900916f5e1ba3829d66a9de92b633
commit: 10383aea2f445bce9b2a2b308def08134b438c8e [46/49] kref: Implement 
'struct kref' using refcount_t
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 10383aea2f445bce9b2a2b308def08134b438c8e
# save the attached .config to linux build tree
make.cross ARCH=openrisc 

All errors (new ones prefixed by >>):

   drivers/scsi/fcoe/fcoe_ctlr.c: In function 'fcoe_ctlr_vn_disc':
   drivers/scsi/fcoe/fcoe_ctlr.c:3097:1: error: insn does not satisfy its 
constraints:
   (call_insn/j 178 177 179 28 drivers/scsi/fcoe/fcoe_ctlr.c:3096 (parallel [
   (call (mem:SI (mem/c:SI (reg/f:SI 1 r1) [0 %sfp+-20 S4 A32]) [0 
S4 A32])
   (const_int 0 [0x0]))
   (use (reg:SI 9 r9))
   ]) 5 {sibcall_internal} (nil)
   (expr_list:REG_DEP_TRUE (use (reg:SI 4 r4))
   (expr_list:REG_DEP_TRUE (use (reg:SI 3 r3))
   (nil
>> drivers/scsi/fcoe/fcoe_ctlr.c:3097:1: internal compiler error: in 
>> reload_cse_simplify_operands, at postreload.c:396
   Please submit a full bug report,
   with preprocessed source if appropriate.
   See  for instructions.

vim +3097 drivers/scsi/fcoe/fcoe_ctlr.c

e10f8c66 drivers/scsi/fcoe/libfcoe.c   Joe Eykholt 2010-07-20  3081 
mutex_lock(&disc->disc_mutex);
e10f8c66 drivers/scsi/fcoe/libfcoe.c   Joe Eykholt 2010-07-20  3082 
callback = disc->pending ? disc->disc_callback : NULL;
e10f8c66 drivers/scsi/fcoe/libfcoe.c   Joe Eykholt 2010-07-20  3083 
disc->pending = 0;
a407c593 drivers/scsi/fcoe/fcoe_ctlr.c Hannes Reinecke 2016-09-30  3084 
mutex_unlock(&disc->disc_mutex);
a407c593 drivers/scsi/fcoe/fcoe_ctlr.c Hannes Reinecke 2016-09-30  3085 
rcu_read_lock();
e10f8c66 drivers/scsi/fcoe/libfcoe.c   Joe Eykholt 2010-07-20  3086 
list_for_each_entry_rcu(rdata, &disc->rports, peers) {
a407c593 drivers/scsi/fcoe/fcoe_ctlr.c Hannes Reinecke 2016-09-30  3087 
if (!kref_get_unless_zero(&rdata->kref))
a407c593 drivers/scsi/fcoe/fcoe_ctlr.c Hannes Reinecke 2016-09-30  3088 
continue;
e10f8c66 drivers/scsi/fcoe/libfcoe.c   Joe Eykholt 2010-07-20  3089 
frport = fcoe_ctlr_rport(rdata);
e10f8c66 drivers/scsi/fcoe/libfcoe.c   Joe Eykholt 2010-07-20  3090 
if (frport->time)
05d7d3b0 drivers/scsi/fcoe/fcoe_ctlr.c Hannes Reinecke 2016-10-18  3091 
fc_rport_login(rdata);
944ef968 drivers/scsi/fcoe/fcoe_ctlr.c Hannes Reinecke 2016-10-18  3092 
kref_put(&rdata->kref, fc_rport_destroy);
e10f8c66 drivers/scsi/fcoe/libfcoe.c   Joe Eykholt 2010-07-20  3093 
}
a407c593 drivers/scsi/fcoe/fcoe_ctlr.c Hannes Reinecke 2016-09-30  3094 
rcu_read_unlock();
e10f8c66 drivers/scsi/fcoe/libfcoe.c   Joe Eykholt 2010-07-20  3095 
if (callback)
e10f8c66 drivers/scsi/fcoe/libfcoe.c   Joe Eykholt 2010-07-20  3096 
callback(lport, DISC_EV_SUCCESS);
e10f8c66 drivers/scsi/fcoe/libfcoe.c   Joe Eykholt 2010-07-20 @3097  }
e10f8c66 drivers/scsi/fcoe/libfcoe.c   Joe Eykholt 2010-07-20  3098  
e10f8c66 drivers/scsi/fcoe/libfcoe.c   Joe Eykholt 2010-07-20  3099  /**
e10f8c66 drivers/scsi/fcoe/libfcoe.c   Joe Eykholt 2010-07-20  3100   * 
fcoe_ctlr_vn_timeout - timer work function for VN2VN mode.
e10f8c66 drivers/scsi/fcoe/libfcoe.c   Joe Eykholt 2010-07-20  3101   * 
@fip: The FCoE controller
e10f8c66 drivers/scsi/fcoe/libfcoe.c   Joe Eykholt 2010-07-20  3102   */
e10f8c66 drivers/scsi/fcoe/libfcoe.c   Joe Eykholt 2010-07-20  3103  static 
void fcoe_ctlr_vn_timeout(struct fcoe_ctlr *fip)
e10f8c66 drivers/scsi/fcoe/libfcoe.c   Joe Eykholt 2010-07-20  3104  {
e10f8c66 drivers/scsi/fcoe/libfcoe.c   Joe Eykholt 2010-07-20  3105 
unsigned long next_time;

:: The code at line 3097 was first introduced by commit
:: e10f8c667b874a57512c936089092a3d1ef7ab8a [SCSI] libfcoe: fcoe: fnic: add 
FIP VN2VN point-to-multipoint support

:: TO: Joe Eykholt 
:: CC: James Bottomley 

---
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/2] drm/cma-helper: Add multi buffer support for cma fbdev

[Laurent Pinchart]

Hi Maxime,

Thank you for the patch.

On Thursday 02 Feb 2017 11:31:56 Maxime Ripard wrote:
> From: Xinliang Liu 
> 
> This patch add a config to support to create multi buffer for cma fbdev.
> Such as double buffer and triple buffer.
> 
> Cma fbdev is convient to add a legency fbdev. And still many Android
> devices use fbdev now and at least double buffer is needed for these
> Android devices, so that a buffer flip can be operated. It will need
> some time for Android device vendors to abondon legency fbdev. So multi
> buffer for fbdev is needed.

How exactly do we expect Android to move away from fbdev if we add features to 
the fbdev compat layer ? I'd much rather make it clear to them that fbdev is a 
thing from the past and that they'd better migrate now.

> Signed-off-by: Xinliang Liu 
> [s.chr...@phytec.de: Picking patch from
>  https://lkml.org/lkml/2015/9/14/188]
> Signed-off-by: Stefan Christ 
> Signed-off-by: Maxime Ripard 
> ---
>  drivers/gpu/drm/Kconfig | 8 
>  drivers/gpu/drm/drm_fb_cma_helper.c | 8 +++-
>  2 files changed, 15 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> index ebfe8404c25f..2ca9bb26a4e4 100644
> --- a/drivers/gpu/drm/Kconfig
> +++ b/drivers/gpu/drm/Kconfig
> @@ -121,6 +121,14 @@ config DRM_KMS_CMA_HELPER
>   help
> Choose this if you need the KMS CMA helper functions
> 
> +config DRM_CMA_FBDEV_BUFFER_NUM
> + int "Cma Fbdev Buffer Number"
> + depends on DRM_KMS_CMA_HELPER
> + default 1
> + help
> +   Defines the buffer number of cma fbdev.  Default is one buffer.
> +   For double buffer please set to 2 and 3 for triple buffer.
> +
>  source "drivers/gpu/drm/i2c/Kconfig"
> 
>  source "drivers/gpu/drm/arm/Kconfig"
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> b/drivers/gpu/drm/drm_fb_cma_helper.c index 81b3558302b5..e3f8b9e720a0
> 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -411,6 +411,12 @@ static void drm_fbdev_cma_defio_fini(struct fb_info
> *fbi) kfree(fbi->fbops);
>  }
> 
> +static int fbdev_num_buffers = CONFIG_DRM_CMA_FBDEV_BUFFER_NUM;
> +module_param(fbdev_num_buffers, int, 0444);
> +MODULE_PARM_DESC(fbdev_num_buffers,
> +  "Number of frame buffers to allocate [default="
> +  __MODULE_STRING(CONFIG_DRM_CMA_FBDEV_BUFFER_NUM) "]");
> +
>  /*
>   * For use in a (struct drm_fb_helper_funcs *)->fb_probe callback function
> that * needs custom struct drm_framebuffer_funcs, like dirty() for
> deferred_io use. @@ -437,7 +443,7 @@ int
> drm_fbdev_cma_create_with_funcs(struct drm_fb_helper *helper,
> bytes_per_pixel = DIV_ROUND_UP(sizes->surface_bpp, 8);
> 
>   mode_cmd.width = sizes->surface_width;
> - mode_cmd.height = sizes->surface_height;
> + mode_cmd.height = sizes->surface_height * fbdev_num_buffers;
>   mode_cmd.pitches[0] = sizes->surface_width * bytes_per_pixel;
>   mode_cmd.pixel_format = drm_mode_legacy_fb_format(sizes->surface_bpp,
>   sizes->surface_depth);

-- 
Regards,

Laurent Pinchart

Re: [PATCH 18/25] Staging: rtl8192u: ieee80211: rtl819x_HT.h - style fix

[Greg KH]

On Sat, Feb 11, 2017 at 10:57:28PM +1300, Derek Robson wrote:
> Fixed style of block comments
> Found using checkpatch
> 
> Signed-off-by: Derek Robson 
> ---
>  drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h | 69 
> +
>  1 file changed, 35 insertions(+), 34 deletions(-)
> 
> diff --git a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h 
> b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> index c3aabbaac7ae..307ab45f528d 100644
> --- a/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> +++ b/drivers/staging/rtl8192u/ieee80211/rtl819x_HT.h
> @@ -86,38 +86,38 @@ typedef enum _CHNLOP{
>   ((_pHTInfo)->ChnlOp > CHNLOP_NONE) ? TRUE : FALSE
>  
>  /*
> -typedef  union _HT_CAPABILITY{
> - u16 ShortData;
> - u8  CharData[2];
> - struct
> - {
> - u16 AdvCoding:1;
> - u16 ChlWidth:1;
> - u16 MimoPwrSave:2;
> - u16 GreenField:1;
> - u16 ShortGI20Mhz:1;
> - u16 ShortGI40Mhz:1;
> - u16 STBC:1;
> - u16 BeamForm:1;
> - u16 DelayBA:1;
> - u16 MaxAMSDUSize:1;
> - u16 DssCCk:1;
> - u16 PSMP:1;
> - u16 Rsvd:3;
> - }Field;
> -}HT_CAPABILITY, *PHT_CAPABILITY;
> -
> -typedef  union _HT_CAPABILITY_MACPARA{
> - u8  ShortData;
> - u8  CharData[1];
> - struct
> - {
> - u8  MaxRxAMPDU:2;
> - u8  MPDUDensity:2;
> - u8  Rsvd:4;
> - }Field;
> -}HT_CAPABILITY_MACPARA, *PHT_CAPABILITY_MACPARA;
> -*/
> + * typedef   union _HT_CAPABILITY{
> + *   u16 ShortData;
> + *   u8  CharData[2];
> + *   struct
> + *   {
> + *   u16 AdvCoding:1;
> + *   u16 ChlWidth:1;
> + *   u16 MimoPwrSave:2;
> + *   u16 GreenField:1;
> + *   u16 ShortGI20Mhz:1;
> + *   u16 ShortGI40Mhz:1;
> + *   u16 STBC:1;
> + *   u16 BeamForm:1;
> + *   u16 DelayBA:1;
> + *   u16 MaxAMSDUSize:1;
> + *   u16 DssCCk:1;
> + *   u16 PSMP:1;
> + *   u16 Rsvd:3;
> + *   }Field;
> + * }HT_CAPABILITY, *PHT_CAPABILITY;
> + *
> + * typedef   union _HT_CAPABILITY_MACPARA{
> + *   u8  ShortData;
> + *   u8  CharData[1];
> + *   struct
> + *   {
> + *   u8  MaxRxAMPDU:2;
> + *   u8  MPDUDensity:2;
> + *   u8  Rsvd:4;
> + *   }Field;
> + * }HT_CAPABILITY_MACPARA, *PHT_CAPABILITY_MACPARA;
> + */
>  
>  typedef enum _HT_ACTION{
>   ACT_RECOMMAND_WIDTH = 0,

I'll take this, but shouldn't we just delete these structures that are
commented out?  Same goes for other patches in this series.

thanks,

greg k-h

Re: [PATCH 04/25] Staging: rtl8192u: r819xU_cmdpkt.c - style fix

[Greg KH]

On Sat, Feb 11, 2017 at 10:53:33PM +1300, Derek Robson wrote:
> Fixed style of block comments
> Found using checkpatch
> 
> Signed-off-by: Derek Robson 
> ---
>  drivers/staging/rtl8192u/r819xU_cmdpkt.c | 99 
> +++-
>  1 file changed, 60 insertions(+), 39 deletions(-)
> 
> diff --git a/drivers/staging/rtl8192u/r819xU_cmdpkt.c 
> b/drivers/staging/rtl8192u/r819xU_cmdpkt.c
> index 1168d133522e..671391a9cbf3 100644
> --- a/drivers/staging/rtl8192u/r819xU_cmdpkt.c
> +++ b/drivers/staging/rtl8192u/r819xU_cmdpkt.c
> @@ -34,7 +34,8 @@ rt_status SendTxCommandPacket(struct net_device *dev, void 
> *pData, u32 DataLen)
>   unsigned char   *ptr_buf;
>  
>   /* Get TCB and local buffer from common pool.
> -(It is shared by CmdQ, MgntQ, and USB coalesce DataQ) */
> +  *  (It is shared by CmdQ, MgntQ, and USB coalesce DataQ)
> +  */
>   skb  = dev_alloc_skb(USB_HWDESC_HEADER_LEN + DataLen + 4);
>   if (!skb)
>   return RT_STATUS_FAILURE;
> @@ -76,7 +77,8 @@ rt_status SendTxCommandPacket(struct net_device *dev, void 
> *pData, u32 DataLen)
>   *  When Who Remark
>   *  05/12/2008   amy Create Version 0 porting from windows 
> code.
>   *
> - 
> *---*/
> + *---
> + */
>  static void cmpk_count_txstatistic(struct net_device *dev, cmpk_txfb_t 
> *pstx_fb)
>  {
>   struct r8192_priv *priv = ieee80211_priv(dev);
> @@ -87,8 +89,9 @@ static void cmpk_count_txstatistic(struct net_device *dev, 
> cmpk_txfb_t *pstx_fb)
> (pu1Byte)(&rtState));
>  
>   /* When RF is off, we should not count the packet for hw/sw synchronize
> -reason, ie. there may be a duration while sw switch is changed and
> -hw switch is being changed. */
> +  *  reason, ie. there may be a duration while sw switch is changed and
> +  *  hw switch is being changed.
> +  */
>   if (rtState == eRfOff)
>   return;
>  #endif
> @@ -98,8 +101,9 @@ static void cmpk_count_txstatistic(struct net_device *dev, 
> cmpk_txfb_t *pstx_fb)
>   return;
>  #endif
>   /* We can not know the packet length and transmit type:
> -broadcast or uni or multicast. So the relative statistics
> -must be collected in tx feedback info. */
> +  * broadcast or uni or multicast. So the relative statistics
> +  * must be collected in tx feedback info.
> +  */
>   if (pstx_fb->tok) {
>   priv->stats.txfeedbackok++;
>   priv->stats.txoktotal++;
> @@ -155,7 +159,8 @@ static void cmpk_count_txstatistic(struct net_device 
> *dev, cmpk_txfb_t *pstx_fb)
>   *  When Who Remark
>   *  05/08/2008   amy Create Version 0 porting from windows 
> code.
>   *
> - 
> *---*/
> + *---
> + */
>  static void cmpk_handle_tx_feedback(struct net_device *dev, u8 *pmsg)
>  {
>   struct r8192_priv *priv = ieee80211_priv(dev);
> @@ -163,18 +168,19 @@ static void cmpk_handle_tx_feedback(struct net_device 
> *dev, u8 *pmsg)
>  
>   priv->stats.txfeedback++;
>  
> - /* 1. Extract TX feedback info from RFD to temp structure buffer. */
> - /* It seems that FW use big endian(MIPS) and DRV use little endian in
> -windows OS. So we have to read the content byte by byte or transfer
> -endian type before copy the message copy. */
> - /* Use pointer to transfer structure memory. */
> - memcpy((u8 *)&rx_tx_fb, pmsg, sizeof(cmpk_txfb_t));
> - /* 2. Use tx feedback info to count TX statistics. */
> - cmpk_count_txstatistic(dev, &rx_tx_fb);
> - /* Comment previous method for TX statistic function. */
> - /* Collect info TX feedback packet to fill TCB. */
> - /* We can not know the packet length and transmit type: broadcast or uni
> -or multicast. */
> + /* 1. Extract TX feedback info from RFD to temp structure buffer.
> +  *It seems that FW use big endian(MIPS) and DRV use little endian in
> +  *windows OS. So we have to read the content byte by byte or 
> transfer
> +  *endian type before copy the message copy.
> +  *Use pointer to transfer structure memory.
> +  *memcpy((u8 *)&rx_tx_fb, pmsg, sizeof(cmpk_txfb_t));
> +  * 2. Use tx feedback info to count TX statistics.
> +  *cmpk_count_txstatistic(dev, &rx_tx_fb);
> +  *Comment previous method for TX statistic function.
> +  *Collect info TX feedback packet to fill TCB.
> +  *We can not know the packet length and transmit type: broadcast or 
> uni
> +  *or multicast.
> +  */
>  }
>  
>  static void cmdpkt_beacontimerinterrupt_819xusb(struct net_device

Re: [PATCH 13/15] staging: rtl8192u: Prefer using the BIT macro

[Greg KH]

On Sun, Feb 12, 2017 at 11:17:58AM +0530, simran singhal wrote:
> This patch replaces bit shifting on 1 with the BIT(x) macro as it's
> extensively used by other function in this driver.
> 
> This was done with coccinelle:
> @@ int g; @@
> 
> -(1 << g)
> +BIT(g)
> 
> Signed-off-by: simran singhal 

ALWAYS test build your patches, otherwise you will get grumpy emails
from maintainers telling you to test build your patches!

Not good...

greg k-h

Re: [PATCH net-next v3 06/10] net: dsa: Migrate to device_find_class()

[Greg KH]

On Fri, Feb 10, 2017 at 10:30:58AM -0800, Florian Fainelli wrote:
> On 02/10/2017 05:02 AM, Greg KH wrote:
> > On Thu, Jan 19, 2017 at 04:51:55PM +, Russell King - ARM Linux wrote:
> >> (This is mainly for Greg's benefit to help him understand the issue.)
> >>
> >> I think the diagram you gave initially made this confusing, as it
> >> talks about a CPU(sic) producing the "RGMII" and "MII-MGMT".
> >>
> >> Let's instead show a better representation that hopefully helps Greg
> >> understand networking. :)
> >>
> >>
> >>   CPU
> >> System <-B->  Ethernet controller <-P-> } PHY <---> network cable
> >> } - - - - - - - or - - - - - - -
> >>   MDIO bus ---M---> } Switch <-P-> PHYs <--> network
> >>   `M^cables
> >>
> >> 'B' can be an on-SoC bus or something like PCI.
> >>
> >> 'P' are the high-speed connectivity between the ethernet controller and
> >> PHY which carries the packet data.  It has no addressing, it's a point
> >> to point link.  RGMII is just one wiring example, there are many
> >> different interfaces there (SGMII, AUI, XAUI, XGMII to name a few.)
> >>
> >> 'M' are the MDIO bus, which is the bus by which ethernet PHYs and
> >> switches can be identified and controlled.
> >>
> >> The MDIO bus has a bus_type, has host drivers which are sometimes
> >> part of the ethernet controller, but can also be stand-alone devices
> >> shared between multiple ethernet controllers.
> >>
> >> PHYs are a kind of MDIO device which are members of the MDIO bus
> >> type.  Each PHY (and switch) has a numerical address, and identifying
> >> numbers within its register set which identifies the manufacturer
> >> and device type.  We have device_driver objects for these.
> >>
> >> Expanding the above diagram to make it (hopefully) even clearer,
> >> we can have this classic setup:
> >>
> >>   CPU
> >> System <-B-> Ethernet controller <-P-> PHY <---> network cable
> >>  MDIO bus ---M--^
> >>
> >> Or, in the case of two DSA switches attached to an Ethernet controller:
> >>
> >>  ||
> >> System <-B-> Ethernet controller <-P-> Switch <-P-> PHY1 <--> network cable
> >>  MDIO bus +--M--->   1<-P-> PHY2 <--> network cable
> >>   |  |...|
> >>   |  |<-P-> PHYn <--> network cable
> >>   |  |^...|  |
> >>   |   |  `---M---'
> >>   |   P
> >>   |   |
> >>   |  |v~~~|
> >>   `--> Switch <-P-> PHY1 <--> network cable
> >>  |   2...|
> >>  |<-P-> PHYn <--> network cable
> >>  ||  |
> >>  `---M---'
> >>
> >> The problem that the DSA guys are trying to deal with is how to
> >> represent the link between the DSA switches (which are devices
> >> sitting off their controlling bus - the MDIO bus) and the ethernet
> >> controller associated with that collection of devices, be it a
> >> switch or PHY.
> > 
> > Why do they have to represent that link?  This is a driver that somehow
> > binds the two togther in some sort of "control plane"?
> 
> We have to represent that link because the CPU/host/management Ethernet
> MAC is physically connected to the CPU/management port of the switch. It
> does indeed participate in establishing the control plane.

But who uses that "link"?  What in userspace cares about it?  What in
the kernel cares?

> The basic idea of DSA is that the switch inserts vendor tags to indicate
> why the packet is sent towards the CPU in the first place: flooding,
> management, copy etc along with information as to which
> originating/destination port(s) this packet comes/goes from/to. On top
> of that, we demultiplex that tag to deliver normal Ethernet frames to
> per-port network devices (virtual network devices).
> 
> If we did leave the switch in an unmanaged mode and not logically
> attached to an Ethernet MAC for management, we'd lose all that
> information (we could use per-port VLANs to re-create it, but it would
> be inferior to what a switch with proprietary tags can do)
> 
> Code in net/dsa/dsa2.c that binds the two (switch and Ethernet MAC)
> together is not strictly a driver, it just is resident in memory and
> waits for dsa_register_switch() to be called until it tries to do this
> binding.

Ok, but when that "binding" happens, why do you need to show it in
sysfs?

> >> Merely changing the parent/child relationships to try and solve
> >> one issue just creates exactly the same problem elsewhere.
> > 
> > Fair enough.
> > 
> >> So, I h

[PATCH v6] fork: free vmapped stacks in cache when cpus are offline

[Hoeun Ryu]

 Using virtually mapped stack, kernel stacks are allocated via vmalloc.
In the current implementation, two stacks per cpu can be cached when
tasks are freed and the cached stacks are used again in task duplications.
but the cached stacks may remain unfreed even when cpu are offline.
 By adding a cpu hotplug callback to free the cached stacks when a cpu
goes offline, the pages of the cached stacks are not wasted.

Signed-off-by: Hoeun Ryu 
Acked-by: Michal Hocko 
---
v6:
 - rollback to v4, completely identical.
v5:
 - wrap cpuhp_setup_state() in a new function, vm_stack_cache_init() which
   actually do nothing when !CONFIG_VMAP_STACK
 - add __may_unused to free_vm_stack_cache()
v4:
 - use CPUHP_BP_PREPARE_DYN state for cpuhp setup
 - fix minor coding style
v3:
 - fix misuse of per-cpu api
 - fix location of function definition within CONFIG_VMAP_STACK
v2:
 - remove cpuhp callback for `startup`, only `teardown` callback is installed.

 kernel/fork.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/kernel/fork.c b/kernel/fork.c
index 937ba59..3ad0274 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -168,6 +168,24 @@ void __weak arch_release_thread_stack(unsigned long *stack)
  */
 #define NR_CACHED_STACKS 2
 static DEFINE_PER_CPU(struct vm_struct *, cached_stacks[NR_CACHED_STACKS]);
+
+static int free_vm_stack_cache(unsigned int cpu)
+{
+   struct vm_struct **cached_vm_stacks = per_cpu_ptr(cached_stacks, cpu);
+   int i;
+
+   for (i = 0; i < NR_CACHED_STACKS; i++) {
+   struct vm_struct *vm_stack = cached_vm_stacks[i];
+
+   if (!vm_stack)
+   continue;
+
+   vfree(vm_stack->addr);
+   cached_vm_stacks[i] = NULL;
+   }
+
+   return 0;
+}
 #endif
 
 static unsigned long *alloc_thread_stack_node(struct task_struct *tsk, int 
node)
@@ -456,6 +474,11 @@ void __init fork_init(void)
for (i = 0; i < UCOUNT_COUNTS; i++) {
init_user_ns.ucount_max[i] = max_threads/2;
}
+
+#ifdef CONFIG_VMAP_STACK
+   cpuhp_setup_state(CPUHP_BP_PREPARE_DYN, "fork:vm_stack_cache",
+ NULL, free_vm_stack_cache);
+#endif
 }
 
 int __weak arch_dup_task_struct(struct task_struct *dst,
-- 
2.7.4

Re: [PATCH v7 00/20] ILP32 for ARM64

[Andrew Pinski]

On Mon, Jan 9, 2017 at 3:29 AM, Yury Norov  wrote:
> This series enables aarch64 with ilp32 mode.
>
> As supporting work, it introduces ARCH_32BIT_OFF_T configuration
> option that is enabled for existing 32-bit architectures but disabled
> for new arches (so 64-bit off_t is is used by new userspace). Also it
> deprecates getrlimit and setrlimit syscalls prior to prlimit64.
>
> This version is based on linux-next from 2017-01-09. It works with
> glibc-2.25, and tested with LTP, glibc testsuite, trinity, lmbench,
> CPUSpec.
>
> This is not RFC anymore. I believe that all ABI and implementation
> issues are resolved now. The way that kernel clears registers top
> halves is probably the last question, and because there's no objection
> for current approach for more that 6 month, I think, community agrees
> with it.
>
> Patches 1, 2, 3 and 8 are general, and may be applied separately.
>
> Current version does not introduce ABI changes comparing to RFC3.
> Kernel and GLIBC trees:
> https://github.com/norov/linux/tree/ilp32-2017-01-09
> https://github.com/norov/glibc/tree/dev9
>
> (GLIBC patches are managed by Steve Ellsey, so my tree is only for
> reference.)

For folks concerned about performance, here is what we get for SPEC
CPU 2006 on ThunderX 2 CN99xx.
Positive means ILP32 is faster than LP64.  This core does not have
AARCH32 so I can't compare that.
Also my LP64 scores don't change with and without the patches.

Options:
-Ofast -flto=32 -mcpu=native -fno-aggressive-loop-optimizations
-funroll-loops -fprefetch-loop-arrays
GCC 7.0.1 r245361 with ilp32 multi-arch patch applied.
4.10rc2 Plus ILP32 patches

SPEC CPU 2006 INT ILP32/LP64
400.perlbench   5.23%
401.bzip2  7.83%
403.gcc 6.22%
429.mcf 14.25%
445.gobmk -1.33%
456.hmmer -0.61%
458.sjeng0.00%
462.libquantum-7.38%
464.h264ref 10.86%
471.omnetpp   13.53%
473.astar  1.38%
483.xalancbmk 3.73%
Score4.29%

Rate (32):
400.perlbench   6.10%
401.bzip2  7.10%
403.gcc 6.71%
429.mcf 57.29%
445.gobmk-0.87%
456.hmmer-0.19%
458.sjeng  0.22%
462.libquantum 0.00%
464.h264ref  11.19%
471.omnetpp11.80%
473.astar  -0.29%
483.xalancbmk 8.87%
Score   8.12%

Thanks,
Andrew Pinski

>
> Changes:
> v3: https://lkml.org/lkml/2014/9/3/704
> v4: https://lkml.org/lkml/2015/4/13/691
> v5: https://lkml.org/lkml/2015/9/29/911
> v6: https://lkml.org/lkml/2016/5/23/661
> v7: RFC nowrap:  https://lkml.org/lkml/2016/6/17/990
> v7: RFC2 nowrap: https://lkml.org/lkml/2016/8/17/245
> v7: RFC3 nowrap: https://lkml.org/lkml/2016/10/21/883
> v7: - 32-bit off_t deprecation is splitted for compat
>   and native 32-bit arches, as it was initially
>   done (patches 1, 2);
> - getrlimit() and setrlimit() syscalls deprecated for
>   aarch64/ilp32 and all new architectures;
> - documentation is cleaned up (patch 4);
> - compat-related definitions moved from
>   aarch64/include/elf.h to binfmt_elf32.c (patch 11)
> - for ptrace, execution mode detection is performed
>   at runtime, as it was in v4 (patch 18)
>
> Andrew Pinski (6):
>   arm64: rename COMPAT to AARCH32_EL0 in Kconfig
>   arm64: ensure the kernel is compiled for LP64
>   arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64
>   arm64: ilp32: add sys_ilp32.c and a separate table (in entry.S) to use
> it
>   arm64: ilp32: introduce ilp32-specific handlers for sigframe and
> ucontext
>   arm64:ilp32: add ARM64_ILP32 to Kconfig
>
> Philipp Tomsich (1):
>   arm64:ilp32: add vdso-ilp32 and use for signal return
>
> Yury Norov (13):
>   compat ABI: use non-compat openat and open_by_handle_at variants
>   32-bit ABI: introduce ARCH_32BIT_OFF_T config option
>   asm-generic: Drop getrlimit and setrlimit syscalls from default list
>   arm64: ilp32: add documentation on the ILP32 ABI for ARM64
>   thread: move thread bits accessors to separated file
>   arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat)
>   arm64: ilp32: add is_ilp32_compat_{task,thread} and TIF_32BIT_AARCH64
>   arm64: introduce binfmt_elf32.c
>   arm64: ilp32: introduce binfmt_ilp32.c
>   arm64: ilp32: share aarch32 syscall handlers
>   arm64: signal: share lp64 signal routines to ilp32
>   arm64: signal32: move ilp32 and aarch32 common code to separated file
>   arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32
>
>  Documentation/arm64/ilp32.txt |  45 +++
>  arch/Kconfig  |   4 +
>  arch/arc/Kconfig  |   1 +
>  arch/arc/include/uapi/asm/unistd.h|   1 +
>  arch/arm/Kconfig  |   1 +

Re: [PATCH] lz4: fix performance regressions

[Willy Tarreau]

Hi Sven,

On Sun, Feb 12, 2017 at 12:16:18PM +0100, Sven Schmidt wrote:
> Fix performance regressions compared to current kernel LZ4

Your patch contains mostly style cleanups which certainly are welcome
but make the whole patch hard to review. These cleanups would have been
better into a separate, preliminary patch IMHO.

Regards,
Willy

Re: [PATCHv2] v4l: split lane parsing code

[Pavel Machek]

Hi!

> The patch looks good to me. Could you post a patchset containing all the
> needed patches, maybe on top of the DT patches in the ccp2 branch, please?
> It'd be easier to handle this that way.

Ok, will do.

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: [PATCH v4 1/7] drm: Add DRM support for tiny LCD displays

[Noralf Trønnes]

Den 12.02.2017 12.05, skrev Andy Shevchenko:

On Sat, Feb 11, 2017 at 8:48 PM, Noralf Trønnes  wrote:

tinydrm provides helpers for very simple displays that can use
CMA backed framebuffers and need flushing on changes.
+/**
+ * tinydrm_gem_cma_free_object - Free resources associated with a CMA GEM
+ *   object

Keep on one line?


That means 81 columns and checkpatch complaint.
This in one of the annoying things about Linux
kernel coding. Always trying
to avoid
breaking up lines.
Because for me it hinders redability.


+const struct file_operations tinydrm_fops = {
+   .owner  = THIS_MODULE,

Do we still need this?


Looks like it, see drm_stub_open()


+static int tinydrm_init(struct device *parent, struct tinydrm_device *tdev,
+   const struct drm_framebuffer_funcs *fb_funcs,
+   struct drm_driver *driver)
+{
+   struct drm_device *drm;
+
+   mutex_init(&tdev->dirty_lock);
+   tdev->fb_funcs = fb_funcs;
+
+   /*
+* We don't embed drm_device, because that prevent us from using
+* devm_kzalloc() to allocate tinydrm_device in the driver since
+* drm_dev_unref() frees the structure. The devm_ functions provide

"devm_ functions" -> "devm_kzalloc()" ?

Otherwise what else do you refer to and why here?


yes, that last sentence can be dropped.


+* for easy error handling.
+*/
+static int tinydrm_register(struct tinydrm_device *tdev)
+{
+   struct drm_device *drm = tdev->drm;
+   int bpp = drm->mode_config.preferred_depth;
+   struct drm_fbdev_cma *fbdev;
+   int ret;
+
+   ret = drm_dev_register(tdev->drm, 0);
+   if (ret)
+   return ret;
+
+   fbdev = drm_fbdev_cma_init_with_funcs(drm, bpp ? bpp : 32,
+ drm->mode_config.num_connector,
+ tdev->fb_funcs);
+   if (IS_ERR(fbdev))
+   DRM_ERROR("Failed to initialize fbdev: %ld\n", PTR_ERR(fbdev));
+   else
+   tdev->fbdev_cma = fbdev;

Apparently I missed previous round of reviews, can you just put in
short words why error is not propagated here to the caller?


A comment might have helped here:
/* fbdev is of minor importance, don't let it stop us */


+
+   return 0;
+}
+/**
+ * tinydrm_display_pipe_init - Initialize display pipe
+ * @tdev: tinydrm device
+ * @funcs: Display pipe functions
+ * @connector_type: Connector type
+ * @formats: Array of supported formats (DRM_FORMAT\_\*)

DRM_FORMAT_* ?


sphinx wants it that way.


+ * @format_count: Number of elements in @formats
+ * @mode: Supported mode
+ * @rotation: Initial @mode rotation in degrees Counter Clock Wise
+ *
+ * This function sets up a &drm_simple_display_pipe with a &drm_connector that
+ * has one fixed &drm_display_mode which is rotated according to @rotation.
+ *
+ * Returns:
+ * Zero on success, negative error code on failure.
+ */
+{
+   struct drm_device *drm = tdev->drm;
+   struct drm_display_mode *mode_copy;
+   struct drm_connector *connector;
+   int ret;
+   connector = tinydrm_connector_create(drm, mode_copy, connector_type);
+   if (IS_ERR(connector))
+   return PTR_ERR(connector);
+
+   ret = drm_simple_display_pipe_init(drm, &tdev->pipe, funcs, formats,
+  format_count, connector);
+   if (ret)
+   return ret;
+
+   return 0;

return drm_... ?


Yep.


tinydrm will be merged the way it is now, unless someone points to
something that is broken. But I collect your comments for a later
cleanup patchset. It takes a lot of effort for me as an amateur to
keeps this code up-to-date out-of-tree for months. It's not even
sure that I've hit the mark with this, so there will most likely be
changes when I start converting fbtft drivers, and I'll implement the
remaining bits and pieces as I make changes. The core of tinydrm won't
change because of unforseen fbtft quirks, but other parts might.


Noralf.


+}
+EXPORT_SYMBOL(tinydrm_display_pipe_init);

[PATCH] softirq: Prevent looping on disabled tasklets

[Chris Wilson]

Disabling a tasklet causes it not to run during tasklet_action, but is
put back onto the runnable tasklet list, and a new softirq raised. As
the softirq is raised from within __do_softirq() this causing
__do_softirq() to loop constantly until its timeslice expires and is
transferred to the ksoftirq thread. ksoftirq then permanently spins,
as on each action, the disabled tasklet keeps reraising the softirq.

Break this vicious cycle by moving the softirq from the action to the
final tasklet_enable().

This behaviour appears to be historic (since the first git import).
However, the looping until timeslice duration (to a max of 2ms) was
first introduced in commit c10d73671ad3 ("softirq: reduce latencies"),
with the restart limit restored in commit 34376a50fb1f ("Fix lockup
related to stop_machine being stuck in __do_softirq.")

Reported-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Thomas Gleixner 
Cc: Hannes Reinecke 
Cc: Jens Axboe 
Cc: Bjorn Helgaas 
Cc: Alexander Potapenko 
Cc: Chen Fan 
Cc: Ingo Molnar 
Cc: "Peter Zijlstra (Intel)" 
Cc: Sebastian Andrzej Siewior 
Cc: Johannes Thumshirn 
Cc: Emese Revfy 
Cc: Sagi Grimberg 
Cc: Eric Dumazet 
Cc: Tom Herbert 
Cc: Ben Hutchings 
---
 include/linux/interrupt.h | 7 +--
 kernel/softirq.c  | 2 --
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 53144e78a369..12750f00d00d 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -613,8 +613,11 @@ static inline void tasklet_disable(struct tasklet_struct 
*t)
 
 static inline void tasklet_enable(struct tasklet_struct *t)
 {
-   smp_mb__before_atomic();
-   atomic_dec(&t->count);
+   if (!atomic_dec_and_test(&t->count))
+   return;
+
+   if (test_bit(TASKLET_STATE_SCHED, &t->state))
+   raise_softirq(HI_SOFTIRQ | TASKLET_SOFTIRQ);
 }
 
 extern void tasklet_kill(struct tasklet_struct *t);
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 744fa611cae0..5a359eb1a541 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -527,7 +527,6 @@ static __latent_entropy void tasklet_action(struct 
softirq_action *a)
t->next = NULL;
*__this_cpu_read(tasklet_vec.tail) = t;
__this_cpu_write(tasklet_vec.tail, &(t->next));
-   __raise_softirq_irqoff(TASKLET_SOFTIRQ);
local_irq_enable();
}
 }
@@ -563,7 +562,6 @@ static __latent_entropy void tasklet_hi_action(struct 
softirq_action *a)
t->next = NULL;
*__this_cpu_read(tasklet_hi_vec.tail) = t;
__this_cpu_write(tasklet_hi_vec.tail, &(t->next));
-   __raise_softirq_irqoff(HI_SOFTIRQ);
local_irq_enable();
}
 }
-- 
2.11.0

Re: [PATCH] x86/vm86: fix compilation warning on a unused variable

[Borislav Petkov]

On Fri, Dec 16, 2016 at 11:19:16PM -0500, Jérémy Lefaure wrote:
> I don't know why gcc raises a warning on that even if it is not used.
> Anyway, I'm sure that the warning is reproducible. Both of your
> solutions fix the issue.

I still see the warning here. You wanna choose one solution, write a
proper patch and send it out?

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: [PATCH] softirq: Prevent looping on disabled tasklets

[Chris Wilson]

On Sun, Feb 12, 2017 at 02:00:19PM +, Chris Wilson wrote:
> Disabling a tasklet causes it not to run during tasklet_action, but is
> put back onto the runnable tasklet list, and a new softirq raised. As
> the softirq is raised from within __do_softirq() this causing
> __do_softirq() to loop constantly until its timeslice expires and is
> transferred to the ksoftirq thread. ksoftirq then permanently spins,
> as on each action, the disabled tasklet keeps reraising the softirq.
> 
> Break this vicious cycle by moving the softirq from the action to the
> final tasklet_enable().
> 
> This behaviour appears to be historic (since the first git import).
> However, the looping until timeslice duration (to a max of 2ms) was
> first introduced in commit c10d73671ad3 ("softirq: reduce latencies"),
> with the restart limit restored in commit 34376a50fb1f ("Fix lockup
> related to stop_machine being stuck in __do_softirq.")
> 
> Reported-by: Tvrtko Ursulin 
> Signed-off-by: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Thomas Gleixner 
> Cc: Hannes Reinecke 
> Cc: Jens Axboe 
> Cc: Bjorn Helgaas 
> Cc: Alexander Potapenko 
> Cc: Chen Fan 
> Cc: Ingo Molnar 
> Cc: "Peter Zijlstra (Intel)" 
> Cc: Sebastian Andrzej Siewior 
> Cc: Johannes Thumshirn 
> Cc: Emese Revfy 
> Cc: Sagi Grimberg 
> Cc: Eric Dumazet 
> Cc: Tom Herbert 
> Cc: Ben Hutchings 
> ---
>  include/linux/interrupt.h | 7 +--
>  kernel/softirq.c  | 2 --
>  2 files changed, 5 insertions(+), 4 deletions(-)
> 
> diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
> index 53144e78a369..12750f00d00d 100644
> --- a/include/linux/interrupt.h
> +++ b/include/linux/interrupt.h
> @@ -613,8 +613,11 @@ static inline void tasklet_disable(struct tasklet_struct 
> *t)
>  
>  static inline void tasklet_enable(struct tasklet_struct *t)
>  {
> - smp_mb__before_atomic();
> - atomic_dec(&t->count);
> + if (!atomic_dec_and_test(&t->count))
> + return;
> +
> + if (test_bit(TASKLET_STATE_SCHED, &t->state))
> + raise_softirq(HI_SOFTIRQ | TASKLET_SOFTIRQ);

raise_softirq is not exported, so let's move tasklet_enable()
out-of-line and export that.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Trying to understand OOM killer

[Paul Menzel]

Dear Linux folks,


since some time, at Linux 4.8, 4.9, and 4.10-rc6, the OOM kicks in on a
8 GB machine.

```
Feb 12 08:21:50 asrocke350m1 kernel: updatedb.mlocat invoked oom-killer: 
gfp_mask=0x16040d0(GFP_TEMPORARY|__GFP_COMP|__GFP_NOTRACK), nodemask=
Feb 12 08:21:50 asrocke350m1 kernel: updatedb.mlocat cpuset=/ mems_allowed=0
Feb 12 08:21:50 asrocke350m1 kernel: CPU: 1 PID: 2314 Comm: updatedb.mlocat 
Tainted: G C  4.10.0-rc6-686-pae #1 Debian 4.10~rc6-1~
Feb 12 08:21:50 asrocke350m1 kernel: Hardware name: ASROCK E350M1/E350M1, BIOS 
4.5-964-gd96669e9db 02/11/2017
Feb 12 08:21:51 asrocke350m1 kernel: Call Trace:
Feb 12 08:21:51 asrocke350m1 kernel:  ? dump_stack+0x55/0x73
Feb 12 08:21:51 asrocke350m1 kernel:  ? dump_header+0x64/0x1ab
Feb 12 08:21:52 asrocke350m1 kernel:  ? ___ratelimit+0x9f/0x100
Feb 12 08:21:52 asrocke350m1 kernel:  ? oom_kill_process+0x221/0x3e0
Feb 12 08:21:52 asrocke350m1 kernel:  ? has_capability_noaudit+0x1a/0x30
Feb 12 08:21:52 asrocke350m1 kernel:  ? oom_badness.part.13+0xd7/0x150
Feb 12 08:21:52 asrocke350m1 kernel:  ? out_of_memory+0xe4/0x290
Feb 12 08:21:52 asrocke350m1 kernel:  ? __alloc_pages_nodemask+0xab8/0xbc0
Feb 12 08:21:52 asrocke350m1 kernel:  ? xfs_init_local_fork+0x8a/0xd0 [xfs]
Feb 12 08:21:52 asrocke350m1 kernel:  ? cache_grow_begin.isra.60+0x75/0x510
Feb 12 08:21:52 asrocke350m1 kernel:  ? xfs_buf_rele+0x43/0x2e0 [xfs]
Feb 12 08:21:52 asrocke350m1 kernel:  ? kmem_cache_alloc+0x1fa/0x530
Feb 12 08:21:52 asrocke350m1 kernel:  ? __d_alloc+0x23/0x180
Feb 12 08:21:52 asrocke350m1 kernel:  ? d_alloc+0x18/0x80
Feb 12 08:21:52 asrocke350m1 kernel:  ? d_alloc_parallel+0x47/0x450
Feb 12 08:21:52 asrocke350m1 kernel:  ? d_splice_alias+0x10d/0x3a0
Feb 12 08:21:53 asrocke350m1 kernel:  ? lockref_get_not_dead+0x8/0x40
Feb 12 08:21:53 asrocke350m1 kernel:  ? unlazy_walk+0xf9/0x1a0
Feb 12 08:21:53 asrocke350m1 kernel:  ? lookup_slow+0x5e/0x140
Feb 12 08:21:53 asrocke350m1 kernel:  ? walk_component+0x1b4/0x350
Feb 12 08:21:53 asrocke350m1 kernel:  ? path_lookupat+0x49/0xe0
Feb 12 08:21:53 asrocke350m1 kernel:  ? filename_lookup+0x99/0x190
Feb 12 08:21:53 asrocke350m1 kernel:  ? __check_object_size+0x9e/0x11c
Feb 12 08:21:53 asrocke350m1 kernel:  ? strncpy_from_user+0x39/0x140
Feb 12 08:21:53 asrocke350m1 kernel:  ? getname_flags+0x55/0x1a0
Feb 12 08:21:53 asrocke350m1 kernel:  ? vfs_fstatat+0x60/0xb0
Feb 12 08:21:53 asrocke350m1 kernel:  ? SyS_lstat64+0x2d/0x50
Feb 12 08:21:53 asrocke350m1 kernel:  ? sys_sync+0x9d/0xa0
Feb 12 08:21:53 asrocke350m1 kernel:  ? SyS_poll+0x6b/0x110
Feb 12 08:21:53 asrocke350m1 kernel:  ? do_fast_syscall_32+0x8a/0x150
Feb 12 08:21:53 asrocke350m1 kernel:  ? entry_SYSENTER_32+0x4e/0x7c
Feb 12 08:21:53 asrocke350m1 kernel: Mem-Info:
Feb 12 08:21:53 asrocke350m1 kernel: active_anon:119893 inactive_anon:17678 
isolated_anon:0
active_file:31461 inactive_file:219091 
isolated_file:0
unevictable:21 dirty:0 writeback:0 
unstable:0
slab_reclaimable:127609 
slab_unreclaimable:9519
mapped:63113 shmem:6177 pagetables:1601 
bounce:0
free:1381579 free_pcp:583 free_cma:0
Feb 12 08:21:53 asrocke350m1 kernel: Node 0 active_anon:479572kB 
inactive_anon:70712kB active_file:125844kB inactive_file:876364kB unevictable
Feb 12 08:21:53 asrocke350m1 kernel: DMA free:3840kB min:788kB low:984kB 
high:1180kB active_anon:0kB inactive_anon:0kB active_file:0kB inactiv
Feb 12 08:21:53 asrocke350m1 kernel: lowmem_reserve[]: 0 763 7663 7663
Feb 12 08:21:53 asrocke350m1 kernel: Normal free:38764kB min:38828kB 
low:48532kB high:58236kB active_anon:0kB inactive_anon:0kB active_file:16
Feb 12 08:21:53 asrocke350m1 kernel: lowmem_reserve[]: 0 0 55201 55201
Feb 12 08:21:53 asrocke350m1 kernel: HighMem free:5483712kB min:512kB 
low:88240kB high:175968kB active_anon:479572kB inactive_anon:70712kB act
Feb 12 08:21:54 asrocke350m1 kernel: lowmem_reserve[]: 0 0 0 0
Feb 12 08:21:54 asrocke350m1 kernel: DMA: 0*4kB 42*8kB (UE) 69*16kB (UE) 7*32kB 
(UE) 10*64kB (UE) 2*128kB (U) 1*256kB (U) 2*512kB (U) 0*1024kB
Feb 12 08:21:54 asrocke350m1 kernel: Normal: 17*4kB (UME) 583*8kB (UME) 
1983*16kB (UE) 72*32kB (ME) 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*
Feb 12 08:21:54 asrocke350m1 kernel: HighMem: 2156*4kB (UM) 1334*8kB (UM) 
2760*16kB (UM) 2087*32kB (UM) 1274*64kB (UM) 491*128kB (UM) 234*256k
Feb 12 08:21:54 asrocke350m1 kernel: Node 0 hugepages_total=0 hugepages_free=0 
hugepages_surp=0 hugepages_size=2048kB
Feb 12 08:21:54 asrocke350m1 kernel: 256720 total pagecache pages
Feb 12 08:21:54 asrocke350m1 kernel: 0 pages in swap cache
Feb 12 08:21:54 asrocke350m1 kernel: Swap cache stats: add 0, delete 0, find 0/0
Feb 12 08:21:54 asrocke350m1 kernel: Free swap  = 4194300kB
Feb 12 08:21:54 asrocke350m1 kernel: Total swap = 4194300kB
Feb 12 08:21:54 asrocke350m1 kernel: 1994197 pages RAM
Feb 12 08:21:54 asrocke35

[PATCH v2] softirq: Prevent looping on disabled tasklets

[Chris Wilson]

Disabling a tasklet causes it not to run during tasklet_action, but is
put back onto the runnable tasklet list, and a new softirq raised. As
the softirq is raised from within __do_softirq() this causing
__do_softirq() to loop constantly until its timeslice expires and is
transferred to the ksoftirq thread. ksoftirq then permanently spins,
as on each action, the disabled tasklet keeps reraising the softirq.

Break this vicious cycle by moving the softirq from the action to the
final tasklet_enable().

This behaviour appears to be historic (since the first git import).
However, the looping until timeslice duration (to a max of 2ms) was
first introduced in commit c10d73671ad3 ("softirq: reduce latencies"),
with the restart limit restored in commit 34376a50fb1f ("Fix lockup
related to stop_machine being stuck in __do_softirq.")

v2: Export tasklet_enable() to work with modules.

Reported-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Thomas Gleixner 
Cc: Hannes Reinecke 
Cc: Jens Axboe 
Cc: Bjorn Helgaas 
Cc: Alexander Potapenko 
Cc: Chen Fan 
Cc: Ingo Molnar 
Cc: "Peter Zijlstra (Intel)" 
Cc: Sebastian Andrzej Siewior 
Cc: Johannes Thumshirn 
Cc: Emese Revfy 
Cc: Sagi Grimberg 
Cc: Eric Dumazet 
Cc: Tom Herbert 
Cc: Ben Hutchings 
---
 include/linux/interrupt.h |  7 +--
 kernel/softirq.c  | 12 ++--
 2 files changed, 11 insertions(+), 8 deletions(-)

diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 53144e78a369..a1fa88e7e509 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -611,12 +611,7 @@ static inline void tasklet_disable(struct tasklet_struct 
*t)
smp_mb();
 }
 
-static inline void tasklet_enable(struct tasklet_struct *t)
-{
-   smp_mb__before_atomic();
-   atomic_dec(&t->count);
-}
-
+extern void tasklet_enable(struct tasklet_struct *t);
 extern void tasklet_kill(struct tasklet_struct *t);
 extern void tasklet_kill_immediate(struct tasklet_struct *t, unsigned int cpu);
 extern void tasklet_init(struct tasklet_struct *t,
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 080eb57789c4..ab8d9aeccb46 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -535,7 +535,6 @@ static __latent_entropy void tasklet_action(struct 
softirq_action *a)
t->next = NULL;
*__this_cpu_read(tasklet_vec.tail) = t;
__this_cpu_write(tasklet_vec.tail, &(t->next));
-   __raise_softirq_irqoff(TASKLET_SOFTIRQ);
local_irq_enable();
}
 }
@@ -571,7 +570,6 @@ static __latent_entropy void tasklet_hi_action(struct 
softirq_action *a)
t->next = NULL;
*__this_cpu_read(tasklet_hi_vec.tail) = t;
__this_cpu_write(tasklet_hi_vec.tail, &(t->next));
-   __raise_softirq_irqoff(HI_SOFTIRQ);
local_irq_enable();
}
 }
@@ -587,6 +585,16 @@ void tasklet_init(struct tasklet_struct *t,
 }
 EXPORT_SYMBOL(tasklet_init);
 
+void tasklet_enable(struct tasklet_struct *t)
+{
+   if (!atomic_dec_and_test(&t->count))
+   return;
+
+   if (test_bit(TASKLET_STATE_SCHED, &t->state))
+   raise_softirq(HI_SOFTIRQ | TASKLET_SOFTIRQ);
+}
+EXPORT_SYMBOL(tasklet_enable);
+
 void tasklet_kill(struct tasklet_struct *t)
 {
if (in_interrupt())
-- 
2.11.0

Re: [PATCH] smiapp: add CCP2 support

[kbuild test robot]

Hi Pavel,

[auto build test ERROR on linuxtv-media/master]
[also build test ERROR on v4.10-rc7 next-20170210]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Pavel-Machek/smiapp-add-CCP2-support/20170208-214729
base:   git://linuxtv.org/media_tree.git master
config: x86_64-randconfig-it0-02122030 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/media/i2c/smiapp/smiapp-core.c: In function 'smiapp_get_hwconfig':
   drivers/media/i2c/smiapp/smiapp-core.c:2812:7: error: 'V4L2_MBUS_CCP2' 
undeclared (first use in this function)
 case V4L2_MBUS_CCP2:
  ^
   drivers/media/i2c/smiapp/smiapp-core.c:2812:7: note: each undeclared 
identifier is reported only once for each function it appears in
>> drivers/media/i2c/smiapp/smiapp-core.c:2813:45: error: 'union ' 
>> has no member named 'mipi_csi1'
  hwcfg->csi_signalling_mode = (bus_cfg->bus.mipi_csi1.strobe) ?
^

vim +2813 drivers/media/i2c/smiapp/smiapp-core.c

  2806  
  2807  switch (bus_cfg->bus_type) {
  2808  case V4L2_MBUS_CSI2:
  2809  hwcfg->csi_signalling_mode = 
SMIAPP_CSI_SIGNALLING_MODE_CSI2;
  2810  hwcfg->lanes = bus_cfg->bus.mipi_csi2.num_data_lanes;
  2811  break;
> 2812  case V4L2_MBUS_CCP2:
> 2813  hwcfg->csi_signalling_mode = 
> (bus_cfg->bus.mipi_csi1.strobe) ?
  2814  SMIAPP_CSI_SIGNALLING_MODE_CCP2_DATA_STROBE :
  2815  SMIAPP_CSI_SIGNALLING_MODE_CCP2_DATA_CLOCK;
  2816  hwcfg->lanes = 1;

---
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] PCI: pciehp: Don't enable PME on runtime suspend

[Lukas Wunner]

On Thu, Feb 09, 2017 at 05:32:54AM +0100, Lukas Wunner wrote:
> On Wed, Feb 08, 2017 at 11:57:36AM -0600, Bjorn Helgaas wrote:
> > On Tue, Feb 07, 2017 at 07:21:01AM +0100, Lukas Wunner wrote:
> > > On Mon, Feb 06, 2017 at 04:15:02PM -0600, Bjorn Helgaas wrote:
> > > > On Mon, Feb 06, 2017 at 10:20:41PM +0100, Lukas Wunner wrote:
> > > > > On Mon, Feb 06, 2017 at 11:54:05AM -0600, Bjorn Helgaas wrote:
> > > > > > What is the hotplug event that causes generation of this wakeup 
> > > > > > event?
> > > > > 
> > > > > If you had read all e-mails in this thread or looked at the bugzilla
> > > > > entry I've created, you wouldn't have to ask this question.
> > > > 
> > > > I'm sorry, I don't necessarily have time to sort through all the
> > > > emails.  My idea is that the changelog should be a self-contained
> > > > justification for the patch.  The bugzilla is for supporting details
> > > > and future archaeologists.
> > > > 
> [...]
> > > > If you think a bugzilla is onerous
> > > 
> > > Hold on.  I didn't say a bugzilla is onerous, I said I'm disappointed
> > > that you're asking me to create one and then don't look at it.
> > 
> > I looked at it, and it had a few details, but no analysis of the
> > situation.  Ideally, I'm looking for a précis of the situation in
> > the changelog, with complete analysis and supporting details in the
> > bugzilla.
> 
> It's irrelevant whether the bugzilla contains an analysis or not.
> 
> You were asking what type of event caused the wakeup.  The information
> was in the bugzilla.  So you either didn't look at the bugzilla or
> didn't look hard enough.
> 
> Please tell me why in the future I should comply with your requests to
> create a bugzilla if you don't look at it and the bug reporter doesn't
> bother attaching any further information.  It would also have been
> possible for you to glean the information you were asking for from the
> reporter's e-mails but you didn't read those either.  And you're paid
> to do this, I'm not.  If you look at the timestamps of my e-mails you
> may notice that they're either early in the morning, late at night or
> on weekends.  Guess what, I'm doing this in my spare time, in addition
> to my day job.

My apologies Bjorn, it was clearly inappropriate for me to assume that
maintenance of the PCI subsystem is at all part of your job contract,
or talk about it on a public mailing list.

Kind regards,

Lukas

[PATCH] video/viafbdev: Make PROC_FS dependency explicit

[Borislav Petkov]

From: Borislav Petkov 

Fix:

  drivers/video/fbdev/via/viafbdev.c: In function ‘viafb_remove_proc’:
  drivers/video/fbdev/via/viafbdev.c:1635:4: warning: unused variable 
‘iga2_entry’ [-Wunused-variable]
 *iga2_entry = shared->iga2_proc_entry;
  ^~
  drivers/video/fbdev/via/viafbdev.c:1634:4: warning: unused variable 
‘iga1_entry’ [-Wunused-variable]
 *iga1_entry = shared->iga1_proc_entry,

build warning from randconfig builds.

Signed-off-by: Borislav Petkov 
---
 drivers/video/fbdev/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index 5d3b0db5ce0a..86ec39784c5a 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -1539,7 +1539,7 @@ config FB_SIS_315
 
 config FB_VIA
tristate "VIA UniChrome (Pro) and Chrome9 display support"
-   depends on FB && PCI && X86 && GPIOLIB && I2C
+   depends on FB && PCI && X86 && GPIOLIB && I2C && PROC_FS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
-- 
2.11.0

[PATCH v2] [media] dvb-usb-firmware: don't do DMA on stack

[Stefan Brüns]

The buffer allocation for the firmware data was changed in
commit 43fab9793c1f ("dvb-usb: don't use stack for firmware load"),
but the same applies for the reset value.

Signed-off-by: Stefan Brüns 
---
This patch replaces the earlier submission conflicting with commit
43fab9793c1f, which was a subset of the submitted patch.

 drivers/media/usb/dvb-usb/dvb-usb-firmware.c | 21 -
 1 file changed, 12 insertions(+), 9 deletions(-)

diff --git a/drivers/media/usb/dvb-usb/dvb-usb-firmware.c 
b/drivers/media/usb/dvb-usb/dvb-usb-firmware.c
index 3271b3fee1f4..1f008f354282 100644
--- a/drivers/media/usb/dvb-usb/dvb-usb-firmware.c
+++ b/drivers/media/usb/dvb-usb/dvb-usb-firmware.c
@@ -36,16 +36,19 @@ static int usb_cypress_writemem(struct usb_device *udev,u16 
addr,u8 *data, u8 le
 int usb_cypress_load_firmware(struct usb_device *udev, const struct firmware 
*fw, int type)
 {
struct hexline *hx;
-   u8 reset;
+   u8 *buf;
+   u8 *reset;
int ret,pos=0;
+   u16 cpu_cs_register = cypress[type].cpu_cs_register;
 
-   hx = kmalloc(sizeof(*hx), GFP_KERNEL);
-   if (!hx)
+   buf = kmalloc(sizeof(*hx), GFP_KERNEL);
+   if (!buf)
return -ENOMEM;
+   hx = (struct hexline *)buf;
 
/* stop the CPU */
-   reset = 1;
-   if ((ret = 
usb_cypress_writemem(udev,cypress[type].cpu_cs_register,&reset,1)) != 1)
+   buf[0] = 1;
+   if (usb_cypress_writemem(udev, cpu_cs_register, buf, 1) != 1)
err("could not stop the USB controller CPU.");
 
while ((ret = dvb_usb_get_hexline(fw, hx, &pos)) > 0) {
@@ -61,21 +64,21 @@ int usb_cypress_load_firmware(struct usb_device *udev, 
const struct firmware *fw
}
if (ret < 0) {
err("firmware download failed at %d with %d",pos,ret);
-   kfree(hx);
+   kfree(buf);
return ret;
}
 
if (ret == 0) {
/* restart the CPU */
-   reset = 0;
-   if (ret || 
usb_cypress_writemem(udev,cypress[type].cpu_cs_register,&reset,1) != 1) {
+   buf[0] = 0;
+   if (usb_cypress_writemem(udev, cpu_cs_register, buf, 1) != 1) {
err("could not restart the USB controller CPU.");
ret = -EINVAL;
}
} else
ret = -EIO;
 
-   kfree(hx);
+   kfree(buf);
 
return ret;
 }
-- 
2.11.0

Re: [Intel-gfx] [PATCH] softirq: Prevent looping on disabled tasklets

[kbuild test robot]

Hi Chris,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc7 next-20170210]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/softirq-Prevent-looping-on-disabled-tasklets/20170212-220435
config: x86_64-lkp (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "raise_softirq" [net/mac80211/mac80211.ko] undefined!

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


.config.gz
Description: application/gzip

[PATCH RFC] crypto: testmgr drop wrong init_completion

[Nicholas Mc Guire]

init_completion() is called here to reinitialize a completion object
that was already re-initialized in wait_async_op() by 
reinit_completion() if complete (via tcrypt_complete()) had been called
and wait_for_completion() returned, so no need to reinit it here.


Fixes: commit 946cc46372dc ("crypto: testmgr - add tests vectors for RSA")
Signed-off-by: Nicholas Mc Guire 
---

Found by experimental coccinelle script
./crypto/testmgr.c:2174:1-16: WARNING: possible duplicate init_completion

Only based on code review and no testing. In case I am overlooking something
and the re-initialization of the completion object is actually needed it
should be using reinit_completion() and not init_completion() anyway.
But as wait_async_op() will leave with the completion object re-initialized
it really should not be needed here (found no path in between that could
have called completion()).

Patch was only compile tested with: x86_64_defconfig (implies cryptomgr-y)

Patch is against linux-4.10-rc6 (localversion-next is next-20170210)

 crypto/testmgr.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 98eb097..15fb453 100644
--- a/crypto/testmgr.c
+++ b/crypto/testmgr.c
@@ -2171,7 +2171,6 @@ static int test_akcipher_one(struct crypto_akcipher *tfm,
 
sg_init_one(&src, xbuf[0], vecs->c_size);
sg_init_one(&dst, outbuf_dec, out_len_max);
-   init_completion(&result.completion);
akcipher_request_set_crypt(req, &src, &dst, vecs->c_size, out_len_max);
 
/* Run RSA decrypt - m = c^d mod n;*/
-- 
2.1.4

Re: [Intel-gfx] [PATCH] softirq: Prevent looping on disabled tasklets

[kbuild test robot]

Hi Chris,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.10-rc7 next-20170210]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/softirq-Prevent-looping-on-disabled-tasklets/20170212-220435
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

>> ERROR: "raise_softirq" [sound/pci/asihpi/snd-asihpi.ko] undefined!
>> ERROR: "raise_softirq" [net/mac802154/mac802154.ko] undefined!
   ERROR: "raise_softirq" [net/mac80211/mac80211.ko] undefined!
>> ERROR: "raise_softirq" [drivers/usb/atm/usbatm.ko] undefined!
>> ERROR: "raise_softirq" [drivers/net/ethernet/jme.ko] undefined!
>> ERROR: "raise_softirq" [drivers/media/pci/mantis/mantis_core.ko] undefined!
>> ERROR: "raise_softirq" [drivers/hv/hv_vmbus.ko] undefined!
>> ERROR: "raise_softirq" [drivers/firewire/firewire-ohci.ko] undefined!

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


.config.gz
Description: application/gzip

Re: [PATCH v9 0/8] drivers: touchscreen: tsc2007 and ads7846/tsc2046 improvements (use common touchscreen bindings, pre-calibration, spi fix and provide iio raw values)

[H. Nikolaus Schaller]

Hi Dmitry,

> Am 28.01.2017 um 19:16 schrieb H. Nikolaus Schaller :
> 
> Hi Dmitry,
> there have been no further comments/complaints about this patch series in the 
> last month.
> And it appears as if only your action is needed.
> 
> What is missing for this patch series to be finally accepted?

Did you find time to look into my comment on patch 1/9 and make a decision on 
patch 6/8?

Is there anything open which prohibits inclusion to (and further testing 
within) linux/next?

BR and thanks,
Nikolaus

Re: [PATCH] lz4: fix performance regressions

[Sven Schmidt]

On Sun, Feb 12, 2017 at 02:05:08PM +0100, Willy Tarreau wrote:
> Hi Sven,
> 
> On Sun, Feb 12, 2017 at 12:16:18PM +0100, Sven Schmidt wrote:
> > Fix performance regressions compared to current kernel LZ4
> 
> Your patch contains mostly style cleanups which certainly are welcome
> but make the whole patch hard to review. These cleanups would have been
> better into a separate, preliminary patch IMHO.
> 
> Regards,
> Willy

Hi Willy,

the problem was, I wanted to compare my version to the upstream LZ4 to find 
bugs (as with my last patch version: wrong indentation in LZ4HC 
in two for loops). But since the LZ4 code is a pain to read, I made additional 
style cleanups "on the way".
Hope you can manage to review the patch though, because it is difficult to 
separate the cleanups now.
Please feel free to ask if you stumble upon something.

Greetings,

Sven 

Re: [PATCH v6] fork: free vmapped stacks in cache when cpus are offline

[Thomas Gleixner]

On Sun, 12 Feb 2017, Hoeun Ryu wrote:

>  Using virtually mapped stack, kernel stacks are allocated via vmalloc.
> In the current implementation, two stacks per cpu can be cached when
> tasks are freed and the cached stacks are used again in task duplications.
> but the cached stacks may remain unfreed even when cpu are offline.
>  By adding a cpu hotplug callback to free the cached stacks when a cpu
> goes offline, the pages of the cached stacks are not wasted.
> 
> Signed-off-by: Hoeun Ryu 
> Acked-by: Michal Hocko 

Reviewed-by: Thomas Gleixner 

[PATCH 1/3] [media] si2157: Add support for Si2141-A10

[Stefan Brüns]

The Si2141 needs two distinct commands for powerup/reset, otherwise it
will not respond to chip revision requests. It also needs a firmware
to run properly.

Signed-off-by: Stefan Brüns 
---
 drivers/media/tuners/si2157.c  | 23 +--
 drivers/media/tuners/si2157_priv.h |  2 ++
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/drivers/media/tuners/si2157.c b/drivers/media/tuners/si2157.c
index 57b250847cd3..e35b1faf0ddc 100644
--- a/drivers/media/tuners/si2157.c
+++ b/drivers/media/tuners/si2157.c
@@ -106,6 +106,9 @@ static int si2157_init(struct dvb_frontend *fe)
if (dev->chiptype == SI2157_CHIPTYPE_SI2146) {
memcpy(cmd.args, "\xc0\x05\x01\x00\x00\x0b\x00\x00\x01", 9);
cmd.wlen = 9;
+   } else if (dev->chiptype == SI2157_CHIPTYPE_SI2141) {
+   memcpy(cmd.args, "\xc0\x00\x0d\x0e\x00\x01\x01\x01\x01\x03", 
10);
+   cmd.wlen = 10;
} else {
memcpy(cmd.args, 
"\xc0\x00\x0c\x00\x00\x01\x01\x01\x01\x01\x01\x02\x00\x00\x01", 15);
cmd.wlen = 15;
@@ -115,6 +118,15 @@ static int si2157_init(struct dvb_frontend *fe)
if (ret)
goto err;
 
+   /* Si2141 needs a second command before it answers the revision query */
+   if (dev->chiptype == SI2157_CHIPTYPE_SI2141) {
+   memcpy(cmd.args, "\xc0\x08\x01\x02\x00\x00\x01", 7);
+   cmd.wlen = 7;
+   ret = si2157_cmd_execute(client, &cmd);
+   if (ret)
+   goto err;
+   }
+
/* query chip revision */
memcpy(cmd.args, "\x02", 1);
cmd.wlen = 1;
@@ -131,12 +143,16 @@ static int si2157_init(struct dvb_frontend *fe)
#define SI2157_A30 ('A' << 24 | 57 << 16 | '3' << 8 | '0' << 0)
#define SI2147_A30 ('A' << 24 | 47 << 16 | '3' << 8 | '0' << 0)
#define SI2146_A10 ('A' << 24 | 46 << 16 | '1' << 8 | '0' << 0)
+   #define SI2141_A10 ('A' << 24 | 41 << 16 | '1' << 8 | '0' << 0)
 
switch (chip_id) {
case SI2158_A20:
case SI2148_A20:
fw_name = SI2158_A20_FIRMWARE;
break;
+   case SI2141_A10:
+   fw_name = SI2141_A10_FIRMWARE;
+   break;
case SI2157_A30:
case SI2147_A30:
case SI2146_A10:
@@ -371,7 +387,7 @@ static int si2157_get_if_frequency(struct dvb_frontend *fe, 
u32 *frequency)
 
 static const struct dvb_tuner_ops si2157_ops = {
.info = {
-   .name   = "Silicon Labs Si2146/2147/2148/2157/2158",
+   .name   = "Silicon Labs 
Si2141/Si2146/2147/2148/2157/2158",
.frequency_min  = 4200,
.frequency_max  = 87000,
},
@@ -471,6 +487,7 @@ static int si2157_probe(struct i2c_client *client,
 #endif
 
dev_info(&client->dev, "Silicon Labs %s successfully attached\n",
+   dev->chiptype == SI2157_CHIPTYPE_SI2141 ?  "Si2141" :
dev->chiptype == SI2157_CHIPTYPE_SI2146 ?
"Si2146" : "Si2147/2148/2157/2158");
 
@@ -508,6 +525,7 @@ static int si2157_remove(struct i2c_client *client)
 static const struct i2c_device_id si2157_id_table[] = {
{"si2157", SI2157_CHIPTYPE_SI2157},
{"si2146", SI2157_CHIPTYPE_SI2146},
+   {"si2141", SI2157_CHIPTYPE_SI2141},
{}
 };
 MODULE_DEVICE_TABLE(i2c, si2157_id_table);
@@ -524,7 +542,8 @@ static struct i2c_driver si2157_driver = {
 
 module_i2c_driver(si2157_driver);
 
-MODULE_DESCRIPTION("Silicon Labs Si2146/2147/2148/2157/2158 silicon tuner 
driver");
+MODULE_DESCRIPTION("Silicon Labs Si2141/Si2146/2147/2148/2157/2158 silicon 
tuner driver");
 MODULE_AUTHOR("Antti Palosaari ");
 MODULE_LICENSE("GPL");
 MODULE_FIRMWARE(SI2158_A20_FIRMWARE);
+MODULE_FIRMWARE(SI2141_A10_FIRMWARE);
diff --git a/drivers/media/tuners/si2157_priv.h 
b/drivers/media/tuners/si2157_priv.h
index d6b2c7b44053..e6436f74abaa 100644
--- a/drivers/media/tuners/si2157_priv.h
+++ b/drivers/media/tuners/si2157_priv.h
@@ -42,6 +42,7 @@ struct si2157_dev {
 
 #define SI2157_CHIPTYPE_SI2157 0
 #define SI2157_CHIPTYPE_SI2146 1
+#define SI2157_CHIPTYPE_SI2141 2
 
 /* firmware command struct */
 #define SI2157_ARGLEN  30
@@ -52,5 +53,6 @@ struct si2157_cmd {
 };
 
 #define SI2158_A20_FIRMWARE "dvb-tuner-si2158-a20-01.fw"
+#define SI2141_A10_FIRMWARE "dvb-tuner-si2141-a10-01.fw"
 
 #endif
-- 
2.11.0

[PATCH 3/3] [media] cxusb: MyGica T230C support

[Stefan Brüns]

Mygica T230 DVB-T/T2/C USB stick support. It uses the same FX2/Si2168
bridge/demodulator combo as the T230, but uses the Si2141 tuner.
Factor out the common code and pass the tuner type and if port as
parameter, to avoid duplicating the initialization code.

Signed-off-by: Stefan Brüns 
---
 drivers/media/dvb-core/dvb-usb-ids.h |  1 +
 drivers/media/usb/dvb-usb/cxusb.c| 80 ++--
 2 files changed, 77 insertions(+), 4 deletions(-)

diff --git a/drivers/media/dvb-core/dvb-usb-ids.h 
b/drivers/media/dvb-core/dvb-usb-ids.h
index a7a4674ccc40..ce4a3d574dd7 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -380,6 +380,7 @@
 #define USB_PID_SONY_PLAYTV0x0003
 #define USB_PID_MYGICA_D6890xd811
 #define USB_PID_MYGICA_T2300xc688
+#define USB_PID_MYGICA_T230C   0xc689
 #define USB_PID_ELGATO_EYETV_DIVERSITY 0x0011
 #define USB_PID_ELGATO_EYETV_DTT   0x0021
 #define USB_PID_ELGATO_EYETV_DTT_2 0x003f
diff --git a/drivers/media/usb/dvb-usb/cxusb.c 
b/drivers/media/usb/dvb-usb/cxusb.c
index 9fd43a37154c..967f4f74309c 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -1305,7 +1305,9 @@ static int cxusb_mygica_d689_frontend_attach(struct 
dvb_usb_adapter *adap)
return 0;
 }
 
-static int cxusb_mygica_t230_frontend_attach(struct dvb_usb_adapter *adap)
+static int cxusb_mygica_t230_common_frontend_attach(struct dvb_usb_adapter 
*adap,
+   const char *tuner_name,
+   u8 tuner_if_port)
 {
struct dvb_usb_device *d = adap->dev;
struct cxusb_state *st = d->priv;
@@ -1352,12 +1354,12 @@ static int cxusb_mygica_t230_frontend_attach(struct 
dvb_usb_adapter *adap)
/* attach tuner */
memset(&si2157_config, 0, sizeof(si2157_config));
si2157_config.fe = adap->fe_adap[0].fe;
-   si2157_config.if_port = 1;
+   si2157_config.if_port = tuner_if_port;
memset(&info, 0, sizeof(struct i2c_board_info));
-   strlcpy(info.type, "si2157", I2C_NAME_SIZE);
+   strlcpy(info.type, tuner_name, I2C_NAME_SIZE);
info.addr = 0x60;
info.platform_data = &si2157_config;
-   request_module(info.type);
+   request_module("si2157");
client_tuner = i2c_new_device(adapter, &info);
if (client_tuner == NULL || client_tuner->dev.driver == NULL) {
module_put(client_demod->dev.driver->owner);
@@ -1376,6 +1378,16 @@ static int cxusb_mygica_t230_frontend_attach(struct 
dvb_usb_adapter *adap)
return 0;
 }
 
+static int cxusb_mygica_t230_frontend_attach(struct dvb_usb_adapter *adap)
+{
+   return cxusb_mygica_t230_common_frontend_attach(adap, "si2157", 1);
+}
+
+static int cxusb_mygica_t230c_frontend_attach(struct dvb_usb_adapter *adap)
+{
+   return cxusb_mygica_t230_common_frontend_attach(adap, "si2141", 0);
+}
+
 /*
  * DViCO has shipped two devices with the same USB ID, but only one of them
  * needs a firmware download.  Check the device class details to see if they
@@ -1458,6 +1470,7 @@ static struct dvb_usb_device_properties 
cxusb_aver_a868r_properties;
 static struct dvb_usb_device_properties cxusb_d680_dmb_properties;
 static struct dvb_usb_device_properties cxusb_mygica_d689_properties;
 static struct dvb_usb_device_properties cxusb_mygica_t230_properties;
+static struct dvb_usb_device_properties cxusb_mygica_t230c_properties;
 
 static int cxusb_probe(struct usb_interface *intf,
   const struct usb_device_id *id)
@@ -1490,6 +1503,8 @@ static int cxusb_probe(struct usb_interface *intf,
 THIS_MODULE, NULL, adapter_nr) ||
0 == dvb_usb_device_init(intf, &cxusb_mygica_t230_properties,
 THIS_MODULE, NULL, adapter_nr) ||
+   0 == dvb_usb_device_init(intf, &cxusb_mygica_t230c_properties,
+THIS_MODULE, NULL, adapter_nr) ||
0)
return 0;
 
@@ -1541,6 +1556,7 @@ enum cxusb_table_index {
CONEXANT_D680_DMB,
MYGICA_D689,
MYGICA_T230,
+   MYGICA_T230C,
NR__cxusb_table_index
 };
 
@@ -1608,6 +1624,9 @@ static struct usb_device_id 
cxusb_table[NR__cxusb_table_index + 1] = {
[MYGICA_T230] = {
USB_DEVICE(USB_VID_CONEXANT, USB_PID_MYGICA_T230)
},
+   [MYGICA_T230C] = {
+   USB_DEVICE(USB_VID_CONEXANT, USB_PID_MYGICA_T230C)
+   },
{}  /* Terminating entry */
 };
 MODULE_DEVICE_TABLE (usb, cxusb_table);
@@ -2307,6 +2326,59 @@ static struct dvb_usb_device_properties 
cxusb_mygica_t230_properties = {
}
 };
 
+static struct dvb_usb_device_properties cxusb_mygica_t230c_properties = {
+  

[PATCH 0/3] Add support for MyGica T230C DVB-T2 stick

[Stefan Brüns]

The required command sequence for the new tuner (Si2141) was traced from the
current Windows driver and verified with a small python script/libusb.
The changes to the Si2168 and cxusb driver are mostly addition of the
required IDs and some glue code.

Stefan Brüns (3):
  [media] si2157: Add support for Si2141-A10
  [media] si2168: add support for Si2168-D60
  [media] cxusb: MyGica T230C support

 drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
 drivers/media/dvb-frontends/si2168.c  |  4 ++
 drivers/media/dvb-frontends/si2168_priv.h |  2 +
 drivers/media/tuners/si2157.c | 23 -
 drivers/media/tuners/si2157_priv.h|  2 +
 drivers/media/usb/dvb-usb/cxusb.c | 80 +--
 6 files changed, 106 insertions(+), 6 deletions(-)

-- 
2.11.0

[PATCH 2/3] [media] si2168: add support for Si2168-D60

[Stefan Brüns]

Add handling for new revision, requiring new firmware.

Signed-off-by: Stefan Brüns 
---
 drivers/media/dvb-frontends/si2168.c  | 4 
 drivers/media/dvb-frontends/si2168_priv.h | 2 ++
 2 files changed, 6 insertions(+)

diff --git a/drivers/media/dvb-frontends/si2168.c 
b/drivers/media/dvb-frontends/si2168.c
index 20b4a659e2e4..28f3bbe0af25 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -674,6 +674,9 @@ static int si2168_probe(struct i2c_client *client,
case SI2168_CHIP_ID_B40:
dev->firmware_name = SI2168_B40_FIRMWARE;
break;
+   case SI2168_CHIP_ID_D60:
+   dev->firmware_name = SI2168_D60_FIRMWARE;
+   break;
default:
dev_dbg(&client->dev, "unknown chip version Si21%d-%c%c%c\n",
cmd.args[2], cmd.args[1], cmd.args[3], cmd.args[4]);
@@ -761,3 +764,4 @@ MODULE_LICENSE("GPL");
 MODULE_FIRMWARE(SI2168_A20_FIRMWARE);
 MODULE_FIRMWARE(SI2168_A30_FIRMWARE);
 MODULE_FIRMWARE(SI2168_B40_FIRMWARE);
+MODULE_FIRMWARE(SI2168_D60_FIRMWARE);
diff --git a/drivers/media/dvb-frontends/si2168_priv.h 
b/drivers/media/dvb-frontends/si2168_priv.h
index 7843ccb448a0..4baa95b7d648 100644
--- a/drivers/media/dvb-frontends/si2168_priv.h
+++ b/drivers/media/dvb-frontends/si2168_priv.h
@@ -25,6 +25,7 @@
 #define SI2168_A20_FIRMWARE "dvb-demod-si2168-a20-01.fw"
 #define SI2168_A30_FIRMWARE "dvb-demod-si2168-a30-01.fw"
 #define SI2168_B40_FIRMWARE "dvb-demod-si2168-b40-01.fw"
+#define SI2168_D60_FIRMWARE "dvb-demod-si2168-d60-01.fw"
 #define SI2168_B40_FIRMWARE_FALLBACK "dvb-demod-si2168-02.fw"
 
 /* state struct */
@@ -37,6 +38,7 @@ struct si2168_dev {
#define SI2168_CHIP_ID_A20 ('A' << 24 | 68 << 16 | '2' << 8 | '0' << 0)
#define SI2168_CHIP_ID_A30 ('A' << 24 | 68 << 16 | '3' << 8 | '0' << 0)
#define SI2168_CHIP_ID_B40 ('B' << 24 | 68 << 16 | '4' << 8 | '0' << 0)
+   #define SI2168_CHIP_ID_D60 ('D' << 24 | 68 << 16 | '6' << 8 | '0' << 0)
unsigned int chip_id;
unsigned int version;
const char *firmware_name;
-- 
2.11.0

[PATCH] genirq: devres: use dev_name(dev) as default for devname

[Heiner Kallweit]

Allow the devname parameter to be NULL and use dev_name(dev) in this case.
This should be an appropriate default for most use cases.

Signed-off-by: Heiner Kallweit 
---
 kernel/irq/devres.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/kernel/irq/devres.c b/kernel/irq/devres.c
index 74d90a75..adb0baa6 100644
--- a/kernel/irq/devres.c
+++ b/kernel/irq/devres.c
@@ -33,7 +33,7 @@ static int devm_irq_match(struct device *dev, void *res, void 
*data)
  * @thread_fn: function to be called in a threaded interrupt context. NULL
  * for devices which handle everything in @handler
  * @irqflags: Interrupt type flags
- * @devname: An ascii name for the claiming device
+ * @devname: An ascii name for the claiming device, dev_name(dev) if NULL
  * @dev_id: A cookie passed back to the handler function
  *
  * Except for the extra @dev argument, this function takes the
@@ -57,6 +57,9 @@ int devm_request_threaded_irq(struct device *dev, unsigned 
int irq,
if (!dr)
return -ENOMEM;
 
+   if (!devname)
+   devname = dev_name(dev);
+
rc = request_threaded_irq(irq, handler, thread_fn, irqflags, devname,
  dev_id);
if (rc) {
@@ -80,7 +83,7 @@ EXPORT_SYMBOL(devm_request_threaded_irq);
  * @thread_fn: function to be called in a threaded interrupt context. NULL
  * for devices which handle everything in @handler
  * @irqflags: Interrupt type flags
- * @devname: An ascii name for the claiming device
+ * @devname: An ascii name for the claiming device, dev_name(dev) if NULL
  * @dev_id: A cookie passed back to the handler function
  *
  * Except for the extra @dev argument, this function takes the
@@ -103,6 +106,9 @@ int devm_request_any_context_irq(struct device *dev, 
unsigned int irq,
if (!dr)
return -ENOMEM;
 
+   if (!devname)
+   devname = dev_name(dev);
+
rc = request_any_context_irq(irq, handler, irqflags, devname, dev_id);
if (rc < 0) {
devres_free(dr);
-- 
2.11.1

Re: [PATCH v4 2/7] drm/tinydrm: Add helper functions

[Noralf Trønnes]

Den 12.02.2017 12.50, skrev Andy Shevchenko:

On Sat, Feb 11, 2017 at 8:48 PM, Noralf Trønnes  wrote:

Add common functionality needed by many tinydrm drivers.
+int tinydrm_enable_backlight(struct backlight_device *backlight)
+{
+   unsigned int old_state;
+   int ret;
+
+   if (!backlight)
+   return 0;
+
+   old_state = backlight->props.state;
+   backlight->props.state &= ~BL_CORE_FBBLANK;
+   DRM_DEBUG_KMS("Backlight state: 0x%x -> 0x%x\n", old_state,
+ backlight->props.state);

"%#x" ?
(And elsewhere)


+#if IS_ENABLED(CONFIG_SPI)
+size_t tinydrm_spi_max_transfer_size(struct spi_device *spi, size_t max_len)
+{
+   size_t ret;
+
+   ret = min(spi_max_transfer_size(spi), spi->master->max_dma_len);

I don't get why DMA constrain somehow affects this framework?


The reason is that spi-bcm2835 reverts to PIO on larger buffers.
Looking at __spi_map_msg() and spi_map_buf() it becomes clear that the
core breaks up the buffer into manageable parts. So this must be a bug
in spi-bcm2835 (and spi-pxa2xx) since no other drivers have a upper
limit in the .can_dma() callback.
So you're rightly confused, with drivers fixed, this limit can be lifted.


What if max_dma_len is zero (imagine SPI master that works only by PIO
by some reason)?


It can't be zero:

int spi_register_master(struct spi_master *master)
{
...
if (!master->max_dma_len)
master->max_dma_len = INT_MAX;


+   if (max_len)
+   ret = min(ret, max_len);
+   if (spi_max)
+   ret = min_t(size_t, ret, spi_max);
+   ret &= ~0x3;

Why alignment is that? Why do we need it? Isn't a busyness of SPI
framework to cope with it?


This minimum capping doesn't look good. I should probably put >16
instead, that would cover the minimum for the 9-bit emulation code.

The reason I let the user change the transfer size, is that some usb
audio card on Raspberry Pi stuttered with 4k fbtft transfers.


+   if (ret < 4)

It's effectively check for 0.


+   ret = 4;
+
+   return ret;
+}
+EXPORT_SYMBOL(tinydrm_spi_max_transfer_size);
+static void
+tinydrm_dbg_spi_print(struct spi_device *spi, struct spi_transfer *tr,
+ const void *buf, int idx, bool tx)
+{
+   u32 speed_hz = tr->speed_hz ? tr->speed_hz : spi->max_speed_hz;
+   char linebuf[3 * 32];
+
+   hex_dump_to_buffer(buf, tr->len, 16,
+  DIV_ROUND_UP(tr->bits_per_word, 8),
+  linebuf, sizeof(linebuf), false);
+
+   printk(KERN_DEBUG
+  "tr(%i): speed=%u%s, bpw=%i, len=%u, %s_buf=[%s%s]\n", idx,
+  speed_hz > 100 ? speed_hz / 100 : speed_hz / 1000,
+  speed_hz > 100 ? "MHz" : "kHz", tr->bits_per_word, tr->len,
+  tx ? "tx" : "rx", linebuf, tr->len > 16 ? " ..." : "");

I hope at some point we will have some extension to print speeds,
sizes and so on based on algo in string_get_size().


+}
+int tinydrm_spi_transfer(struct spi_device *spi, u32 speed_hz,
+struct spi_transfer *header, u8 bpw, const void *buf,
+size_t len)
+{
+   struct spi_transfer tr = {
+   .bits_per_word = bpw,
+   .speed_hz = speed_hz,
+   };
+   struct spi_message m;
+   u16 *swap_buf = NULL;
+   size_t max_chunk;
+   size_t chunk;
+   int ret = 0;
+
+   if (WARN_ON_ONCE(bpw != 8 && bpw != 16))
+   return -EINVAL;
+
+   max_chunk = tinydrm_spi_max_transfer_size(spi, 0);
+
+   if (drm_debug & DRM_UT_DRIVER)
+   pr_debug("[drm:%s] bpw=%u, max_chunk=%zu, transfers:\n",
+__func__, bpw, max_chunk);

For all of your dev_dbg() / pr_debug() __func__ argument might be
redundant. Dynamic Debug may include this by request from user.


+/**
+ * tinydrm_machine_little_endian - Machine is little endian
+ *
+ * Returns:
+ * true if *defined(__LITTLE_ENDIAN)*, false otherwise
+ */
+static inline bool tinydrm_machine_little_endian(void)
+{
+#if defined(__LITTLE_ENDIAN)
+   return true;
+#else
+   return false;
+#endif
+}

Hmm... What is the typical code of a caller for this?


If the bus can't do 16-bit natively, it will have to swap the bytes on
little endian machines before transfer as 8-bit (Raspberry Pi can't do
16-bit SPI with it's DMA capable controller).
So this function is to avoid #ifdef's elsewhere.

Re: 4.10-rc1: thinkpad x60: who ate my cpu?

[Woody Suwalski]

Woody Suwalski wrote:

Pavel Machek wrote:

On Sat 2017-01-14 12:30:54, Pavel Machek wrote:

Hi!

On Thu 2017-01-12 20:19:31, Woody Suwalski wrote:

Pavel Machek wrote:

Hi!

I used to have two cpus, and Thinkpad X60 should have two cores, 
but I

only see one on 4.10-rc1. This machine went through many
suspend/resume cycles. When backups finish, I'll try -rc2.

Whoever did it, he seems to have returned the cpu in -rc3. All seems
to be good now.
Actually since you have mentioned - I have checked my x60 - same 
problem -
only one CPU. However I was running 4.8.13 with uptime 33 days, 
multiple

sleep/wake-ups.
Installed a current EOL 4.8.17 and rebooted - I see 2 CPUs. So the 
issue is

older then 4.10 kernel, and I suspect it is the CPU hotplug / wakeup
related...

Hmm. So I seen two cores in -rc3 after boot. But it is quite well
possible that -rc1 was ok just after boot, too, and problem happened
sometime later (probably during suspend/resume cycles). Let me go back
to -rc1 to check.

Indeed in -rc1 I see both CPUs after boot. So we have hard to
reproduce case where 4.8 to 4.10 kernels lose one of the cpu cores...



Managed to duplicate - but it took again a long time - I have an 
uptime of 29 days.
It must have happened in the last day, as I kept checking as often as 
I remembered.


The kernel is 4.8.17 EOL, installed almost a month ago.
Platform ThinkPad x60,  Intel(R) Core(TM) Duo CPU  T2400  @ 1.83GHz

In dmesg I see that it used to be when 2 CPUs were OK:
[690409.476107] PM: noirq suspend of devices complete after 79.914 msecs
[690409.476547] ACPI: Preparing to enter system sleep state S3
[690409.780081] ACPI : EC: EC stopped
[690409.780083] PM: Saving platform NVS memory
[690409.780284] Disabling non-boot CPUs ...
[690409.805284] smpboot: CPU 1 is now offline
[690409.816464] ACPI: Low-level resume complete
[690409.816464] ACPI : EC: EC started
[690409.816464] PM: Restoring platform NVS memory
[690409.816464] Enabling non-boot CPUs ...
[690409.840574] x86: Booting SMP configuration:
[690409.840576] smpboot: Booting Node 0 Processor 1 APIC 0x1
[690409.805271] Initializing CPU#1
[690409.805271] Disabled fast string operations
[690409.888252]  cache: parent cpu1 should not be sleeping
[690409.920185] CPU1 is up
[690409.922288] ACPI: Waking up from system sleep state S3

Then the CPU1 failed to start:

[691329.776108] PM: noirq suspend of devices complete after 79.941 msecs
[691329.776550] ACPI: Preparing to enter system sleep state S3
[691330.080081] ACPI : EC: EC stopped
[691330.080083] PM: Saving platform NVS memory
[691330.080284] Disabling non-boot CPUs ...
[691330.105303] smpboot: CPU 1 is now offline
[691330.116477] ACPI: Low-level resume complete
[691330.116477] ACPI : EC: EC started
[691330.116477] PM: Restoring platform NVS memory
[691330.116477] Enabling non-boot CPUs ...
[691330.140570] x86: Booting SMP configuration:
[691330.140572] smpboot: Booting Node 0 Processor 1 APIC 0x1
[691340.140015] smpboot: do_boot_cpu failed(-1) to wakeup CPU#1
[691340.164445] Error taking CPU1 up: -5
[691340.166309] ACPI: Waking up from system sleep state S3

And now it is:
[692517.868523] ACPI: Preparing to enter system sleep state S3
[692518.172074] ACPI : EC: EC stopped
[692518.172076] PM: Saving platform NVS memory
[692518.172269] Disabling non-boot CPUs ...
[692518.172269] ACPI: Low-level resume complete
[692518.172269] ACPI : EC: EC started
[692518.172269] PM: Restoring platform NVS memory
[692518.172269] ACPI: Waking up from system sleep state S3

Is there any test I could do on the CPU wakeup while in that state?

Woody


Is there a way to kick the offline-CPU into operation from /sys level?

S2ram + btrfs with recent kernel => soft lockup warning and hard hang

[Bastien ROUCARIES]

Hi,

Since 3.8 s2ram on btrfs system lead to hang.

Could not save a trace will try to get a few picture but trace are similar to :
https://github.com/docker/docker/issues/15654
and
https://patchwork.kernel.org/patch/8352811/

It is 100% reproducible.

mount table
/dev/mapper/portable2015--bastien--vg-HOME on /var/cache/pbuilder type
btrfs 
(rw,relatime,lazytime,compress=zlib,space_cache,subvolid=934,subvol=/pbuilder)
/dev/mapper/portable2015--bastien--vg-HOME on /home type btrfs
(rw,nosuid,nodev,relatime,lazytime,compress=zlib,space_cache,subvolid=933,subvol=/home)

btrfs is over dm-crypt

Bastien

[PATCH v3] softirq: Prevent looping on disabled tasklets

[Chris Wilson]

Disabling a tasklet causes it not to run during tasklet_action, but is
put back onto the runnable tasklet list, and a new softirq raised. As
the softirq is raised from within __do_softirq() this causing
__do_softirq() to loop constantly until its timeslice expires and is
transferred to the ksoftirq thread. ksoftirq then permanently spins,
as on each action, the disabled tasklet keeps reraising the softirq.

Break this vicious cycle by moving the softirq from the action to the
final tasklet_enable().

This behaviour appears to be historic (since the first git import).
However, the looping until timeslice duration (to a max of 2ms) was
first introduced in commit c10d73671ad3 ("softirq: reduce latencies"),
with the restart limit restored in commit 34376a50fb1f ("Fix lockup
related to stop_machine being stuck in __do_softirq.")

v2: Export tasklet_enable() to work with modules.
v3: Restore the looping over a failed tasklet_trylock()

Reported-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Thomas Gleixner 
Cc: Hannes Reinecke 
Cc: Jens Axboe 
Cc: Bjorn Helgaas 
Cc: Alexander Potapenko 
Cc: Chen Fan 
Cc: Ingo Molnar 
Cc: "Peter Zijlstra (Intel)" 
Cc: Sebastian Andrzej Siewior 
Cc: Johannes Thumshirn 
Cc: Emese Revfy 
Cc: Sagi Grimberg 
Cc: Eric Dumazet 
Cc: Tom Herbert 
Cc: Ben Hutchings 
---
 include/linux/interrupt.h |  7 +--
 kernel/softirq.c  | 20 ++--
 2 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index 53144e78a369..a1fa88e7e509 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -611,12 +611,7 @@ static inline void tasklet_disable(struct tasklet_struct 
*t)
smp_mb();
 }
 
-static inline void tasklet_enable(struct tasklet_struct *t)
-{
-   smp_mb__before_atomic();
-   atomic_dec(&t->count);
-}
-
+extern void tasklet_enable(struct tasklet_struct *t);
 extern void tasklet_kill(struct tasklet_struct *t);
 extern void tasklet_kill_immediate(struct tasklet_struct *t, unsigned int cpu);
 extern void tasklet_init(struct tasklet_struct *t,
diff --git a/kernel/softirq.c b/kernel/softirq.c
index 080eb57789c4..47c8933d315e 100644
--- a/kernel/softirq.c
+++ b/kernel/softirq.c
@@ -516,6 +516,7 @@ static __latent_entropy void tasklet_action(struct 
softirq_action *a)
 
while (list) {
struct tasklet_struct *t = list;
+   bool raise_softirq = true;
 
list = list->next;
 
@@ -529,13 +530,15 @@ static __latent_entropy void tasklet_action(struct 
softirq_action *a)
continue;
}
tasklet_unlock(t);
+   raise_softirq = false;
}
 
local_irq_disable();
t->next = NULL;
*__this_cpu_read(tasklet_vec.tail) = t;
__this_cpu_write(tasklet_vec.tail, &(t->next));
-   __raise_softirq_irqoff(TASKLET_SOFTIRQ);
+   if (raise_softirq)
+   __raise_softirq_irqoff(TASKLET_SOFTIRQ);
local_irq_enable();
}
 }
@@ -552,6 +555,7 @@ static __latent_entropy void tasklet_hi_action(struct 
softirq_action *a)
 
while (list) {
struct tasklet_struct *t = list;
+   bool raise_softirq = true;
 
list = list->next;
 
@@ -565,13 +569,15 @@ static __latent_entropy void tasklet_hi_action(struct 
softirq_action *a)
continue;
}
tasklet_unlock(t);
+   raise_softirq = false;
}
 
local_irq_disable();
t->next = NULL;
*__this_cpu_read(tasklet_hi_vec.tail) = t;
__this_cpu_write(tasklet_hi_vec.tail, &(t->next));
-   __raise_softirq_irqoff(HI_SOFTIRQ);
+   if (raise_softirq)
+   __raise_softirq_irqoff(HI_SOFTIRQ);
local_irq_enable();
}
 }
@@ -587,6 +593,16 @@ void tasklet_init(struct tasklet_struct *t,
 }
 EXPORT_SYMBOL(tasklet_init);
 
+void tasklet_enable(struct tasklet_struct *t)
+{
+   if (!atomic_dec_and_test(&t->count))
+   return;
+
+   if (test_bit(TASKLET_STATE_SCHED, &t->state))
+   raise_softirq(HI_SOFTIRQ | TASKLET_SOFTIRQ);
+}
+EXPORT_SYMBOL(tasklet_enable);
+
 void tasklet_kill(struct tasklet_struct *t)
 {
if (in_interrupt())
-- 
2.11.0

Re: [REGRESSION] Two issues that prevent process accounting (taskstats) from working correctly

[Dmitry Romanov]

On Mon, Dec 19, 2016 at 01:06:00PM +0100, Martin Steigerwald wrote:
>
> 1) Sometimes process accounting does not work at all.
>
> The acct() system call (to activate process accounting) return value 0, 
> which means that process accounting is activated successfully.
> However, no process accounting records are written whatsoever. This 
> situation can be reproduced with the program 'acctdemo.c'
> that you can find as attachment. When this program gives the message 
> "found a process accounting record!", the situation is okay
> and process accounting works fine to the file '/tmp/mypacct'. When the 
> message 'No process accounting record yet' is repeatedly given,
> process accounting does not work and will not work at all. It might be 
> that you have to start this program several times before you get
> this situation (preferably start/finish lots of processes in the mean time).
> This problem is probably caused by a new mechanism introduced in the 
> kernel code (/linux/kernel/acct.c) that is called 'slow accounting'
> and has to be solved in the kernel code.
>
> I experience this problem on Debian8 with a 4.8 kernel and on CentOS7 
> with a 4.8 kernel.

I reported same problem on bugzilla as:

Bug 180841 - Process accounting sometimes do not append records for terminated 
processes 
https://bugzilla.kernel.org/show_bug.cgi?id=180841

I think I found cause of this problem and can suggest patch which correct this 
problem.

Problem arise in such situation:

Problem arise if between process accounting activation with call acct(...) and
first termination of process pass not less than one jiffy. (Note,  acct() return
successfully, with zero.) In such situation records for terminated processes 
do nod append to accounting file, until process accounting is restarted.

I wrote test program test.c for illustration described problem for kernel 
version 3.17-rc1 and later. This program create empty file for accounting, 
call system call acct() with this file, sleep for not less than one jiffy, 
create new process and exit this process. Then, program test size of accounting 
file. If size of file remain zero, it seems problem and program display message 
"Accounting file size = 0, process accounting did not add record to accounting 
file!".
On my system problem reproduce almost always by this test.c.

--
test.c
--
#include 
#include 
#include 
#include 
#include 
#include 

/* Accounting file name : */
#define ACCTFILENAME "/var/log/pacct"

int main() 
{
int fd;
int pid;
struct stat sb;

/* Turn off accounting */
if ( acct(NULL) < 0 ) {
perror("Process accounting off");
return -1;
}

/* Create empty accounting file */
fd = creat(ACCTFILENAME, S_IRUSR | S_IWUSR);
if ( fd == -1 ) {
perror("Accounting file creation");
return -1;
}
if ( close(fd) == -1) {
perror("Accounting file closing");
return -1;
}

/* Switch accounting on */
if ( acct(ACCTFILENAME) < 0 ) {
perror("Process accounting on");
return -1;
}

/* Delay must be at least 1 jiffy. 
For reproducing bug, some process exit must not happen during first 
jiffy.
If HZ >= 100, need delay minimum 10 ms. */
usleep(1);

/* Create and exit child process. The record for this process must be 
append 
by activated process accounting. */
pid = fork();
if (pid < 0) {
perror("Child process creating");
return -1;
}
/* Exit child process */
if (pid == 0) {
exit(0);
}
/* Wait for child process termination */
wait(NULL);

/* Get size of accounting file. */
if ( stat(ACCTFILENAME, &sb) == -1 ) {
perror("Getting accounting file status");
return -1;
}

if ( sb.st_size == 0 ) {
printf("Accounting file size = 0, process accounting did not 
add record to accounting file!\n");
}
else {
printf("Accounting file size > 0, expected behaviour.\n");
}

/* Turn off accounting and remove accounting file*/
if ( acct(NULL) < 0 ) {
perror("Process accounting off");
return -1;
}
if ( remove(ACCTFILENAME) == -1 ) {
perror("Removing accounting file");
return -1;
}

return 0;

}
--

I suppose that this problem may be solve in kernel versions 3.17-rc1 and 
later by following patch:

Signed-off-by: Dmitry Romanov 
---
 kernel/acct.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/acct.c b/kernel/acct.c
index 74963d1..37f1dc6 100644
--- a/kernel/acct.c
+++ b/kernel/acct.c
@@ -99,7 +99,7 @@ static int check_free_sp

[PATCH] staging:vt6656:channel.h: fix function definition argument without identifier name issue

[Arushi Singhal]

Function definitions arguments should also have an identifier name as
reported by checkpatch.pl.

Signed-off-by: Arushi Singhal 
---
 drivers/staging/vt6656/channel.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/vt6656/channel.h b/drivers/staging/vt6656/channel.h
index fcea6995fe26..62f18a959098 100644
--- a/drivers/staging/vt6656/channel.h
+++ b/drivers/staging/vt6656/channel.h
@@ -28,6 +28,6 @@
 
 #include "device.h"
 
-void vnt_init_bands(struct vnt_private *);
+void vnt_init_bands(struct vnt_private *priv);
 
 #endif  /* _CHANNEL_H_ */
-- 
2.11.0

Re: [PATCH v3] softirq: Prevent looping on disabled tasklets

[Chris Wilson]

On Sun, Feb 12, 2017 at 03:46:09PM +, Chris Wilson wrote:
> +void tasklet_enable(struct tasklet_struct *t)
> +{
> + if (!atomic_dec_and_test(&t->count))
> + return;
> +
> + if (test_bit(TASKLET_STATE_SCHED, &t->state))
> + raise_softirq(HI_SOFTIRQ | TASKLET_SOFTIRQ);

And of course this can't work as raise_softirq() is local to the cpu.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH v5 7/8] thunderbolt: Power down controller when idle

[Lukas Wunner]

On Sat, Jan 28, 2017 at 05:32:37PM -0600, Bjorn Helgaas wrote:
> On Sun, Jan 15, 2017 at 09:03:45PM +0100, Lukas Wunner wrote:
> > A Thunderbolt controller appears to the OS as a set of virtual devices:
> > One upstream bridge, multiple downstream bridges and one NHI (Native
> > Host Interface).  The upstream and downstream bridges represent a PCIe
> > switch (see definition of a switch in the PCIe spec).  The NHI device is
> > used to manage the switch fabric.  Hotplugged devices appear behind the
> > downstream bridges:
> > 
> >   (Root Port)  Upstream Bridge --+-- Downstream Bridge 0  NHI
> >  +-- Downstream Bridge 1 --
> >  +-- Downstream Bridge 2 --
> >  ...
> > 
> > Power is cut to the entire set of devices.  The Linux pm model is
> > hierarchical and assumes that a child cannot resume before its parent.
> > To conform to this model, power control must be governed by the
> > Thunderbolt controller's topmost device, which is the upstream bridge.
> > The NHI and downstream bridges go to D3hot independently and the
> > upstream bridge goes to D3cold once all its children have suspended.
> > This commit only adds runtime pm for the upstream bridge.  Runtime pm
> > for the NHI is added in a separate commit to signify its independence.
> > Runtime pm for the downstream bridges is handled by the pcieport driver.
> > 
> > Because Apple's ACPI methods are nonstandard, a struct dev_pm_domain is
> > used to override the PCI bus pm_ops.  The thunderbolt driver binds to
> 
> What are the default PCI bus pm_ops?  I looked briefly for it to see
> if there was some way to use hooks there instead of using
> dev_pm_domain_set() with its weird out-of-orderness.

The default PCI bus pm_ops are defined in drivers/pci/pci-driver.c as
struct dev_pm_ops pci_dev_pm_ops.

I did hook into those callbacks in an earlier version of this series
but it required more patches and more modifications to the PCI core
and PCIe port services driver to get Thunderbolt runpm to work:
https://www.spinics.net/lists/linux-pci/msg51158.html

Using dev_pm_domain_set() is the de facto standard to solve this,
vga_switcheroo does the same, that's why I settled on this approach.
(see drivers/gpu/vga/vga_switcheroo.c:vga_switcheroo_init_domain_pm_ops())


> I guess what you do in thunderbolt_power_init() is copy the upstream
> device's bus's ops, then override a few of them?  Seems like we then
> have the problem of keeping the Thunderbolt ones in sync with the
> generic ones, e.g., if something got added to the generic one,
> somebody should look at the Thunderbolt one to see if it's also need
> there?

Not a problem.  upstream_runtime_suspend() essentially does this:

// call pci_dev_pm_ops ->runtime_suspend hook:
ret = dev->bus->pm->runtime_suspend(dev);
// power down:
acpi_execute_simple_method(power->set, NULL, 0)
// enable wake interrupt:
acpi_enable_gpe(NULL, power->wake_gpe)

So any changes to the pci_dev_pm_ops are inherited.  Again,
vga_switcheroo does the same (see vga_switcheroo_runtime_suspend()).


> > +#define pr_fmt(fmt) KBUILD_MODNAME " %s: " fmt, dev_name(dev)
[...]
> > +   /* prevent interrupts during system sleep transition */
> > +   if (ACPI_FAILURE(acpi_disable_gpe(NULL, power->wake_gpe))) {
> > +   pr_err("cannot disable wake GPE, resuming\n");
> 
> Can you use dev_err() here and below?  This is related to a specific
> device, and it'd be nice to know which one.

See above, the device name is included in pr_fmt.  The reason to use
pr_err() instead of dev_err() is to get the error message prefixed
with "thunderbolt" instead of "pcieport".  Recall that this function
is executed in the context of the upstream bridge, whose driver name
is pcieport.  I would like to prevent people from grepping the portdrv
code for the error message.  You're the second person to raise this
question (Andy Shevchenko made the same comment on an earlier version
of this patch), so I've now added a comment to explain it.


> > +void thunderbolt_power_init(struct tb *tb)
> > +{
> > +   struct device *upstream_dev, *nhi_dev = &tb->nhi->pdev->dev;
> > +   struct tb_power *power = NULL;
> 
> Unnecessary initialization.

Good point.

Thanks,

Lukas

[PATCH] net: neterion: vxge: use new api ethtool_{get|set}_link_ksettings

[Philippe Reynes]

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

As I don't have the hardware, I'd be very pleased if
someone may test this patch.

Signed-off-by: Philippe Reynes 
---
 drivers/net/ethernet/neterion/vxge/vxge-ethtool.c |   47 -
 1 files changed, 27 insertions(+), 20 deletions(-)

diff --git a/drivers/net/ethernet/neterion/vxge/vxge-ethtool.c 
b/drivers/net/ethernet/neterion/vxge/vxge-ethtool.c
index 9a29670..db55e6d 100644
--- a/drivers/net/ethernet/neterion/vxge/vxge-ethtool.c
+++ b/drivers/net/ethernet/neterion/vxge/vxge-ethtool.c
@@ -38,9 +38,9 @@
 };
 
 /**
- * vxge_ethtool_sset - Sets different link parameters.
+ * vxge_ethtool_set_link_ksettings - Sets different link parameters.
  * @dev: device pointer.
- * @info: pointer to the structure with parameters given by ethtool to set
+ * @cmd: pointer to the structure with parameters given by ethtool to set
  * link information.
  *
  * The function sets different link parameters provided by the user onto
@@ -48,44 +48,51 @@
  * Return value:
  * 0 on success.
  */
-static int vxge_ethtool_sset(struct net_device *dev, struct ethtool_cmd *info)
+static int
+vxge_ethtool_set_link_ksettings(struct net_device *dev,
+   const struct ethtool_link_ksettings *cmd)
 {
/* We currently only support 10Gb/FULL */
-   if ((info->autoneg == AUTONEG_ENABLE) ||
-   (ethtool_cmd_speed(info) != SPEED_1) ||
-   (info->duplex != DUPLEX_FULL))
+   if ((cmd->base.autoneg == AUTONEG_ENABLE) ||
+   (cmd->base.speed != SPEED_1) ||
+   (cmd->base.duplex != DUPLEX_FULL))
return -EINVAL;
 
return 0;
 }
 
 /**
- * vxge_ethtool_gset - Return link specific information.
+ * vxge_ethtool_get_link_ksettings - Return link specific information.
  * @dev: device pointer.
- * @info: pointer to the structure with parameters given by ethtool
+ * @cmd: pointer to the structure with parameters given by ethtool
  * to return link information.
  *
  * Returns link specific information like speed, duplex etc.. to ethtool.
  * Return value :
  * return 0 on success.
  */
-static int vxge_ethtool_gset(struct net_device *dev, struct ethtool_cmd *info)
+static int vxge_ethtool_get_link_ksettings(struct net_device *dev,
+  struct ethtool_link_ksettings *cmd)
 {
-   info->supported = (SUPPORTED_1baseT_Full | SUPPORTED_FIBRE);
-   info->advertising = (ADVERTISED_1baseT_Full | ADVERTISED_FIBRE);
-   info->port = PORT_FIBRE;
+   ethtool_link_ksettings_zero_link_mode(cmd, supported);
+   ethtool_link_ksettings_add_link_mode(cmd, supported, 1baseT_Full);
+   ethtool_link_ksettings_add_link_mode(cmd, supported, FIBRE);
 
-   info->transceiver = XCVR_EXTERNAL;
+   ethtool_link_ksettings_zero_link_mode(cmd, advertising);
+   ethtool_link_ksettings_add_link_mode(cmd, advertising, 1baseT_Full);
+   ethtool_link_ksettings_add_link_mode(cmd, advertising, FIBRE);
+
+   cmd->base.port = PORT_FIBRE;
 
if (netif_carrier_ok(dev)) {
-   ethtool_cmd_speed_set(info, SPEED_1);
-   info->duplex = DUPLEX_FULL;
+   cmd->base.speed = SPEED_1;
+   cmd->base.duplex = DUPLEX_FULL;
} else {
-   ethtool_cmd_speed_set(info, SPEED_UNKNOWN);
-   info->duplex = DUPLEX_UNKNOWN;
+   cmd->base.speed = SPEED_UNKNOWN;
+   cmd->base.duplex = DUPLEX_UNKNOWN;
}
 
-   info->autoneg = AUTONEG_DISABLE;
+   cmd->base.autoneg = AUTONEG_DISABLE;
return 0;
 }
 
@@ -1126,8 +1133,6 @@ static int vxge_fw_flash(struct net_device *dev, struct 
ethtool_flash *parms)
 }
 
 static const struct ethtool_ops vxge_ethtool_ops = {
-   .get_settings   = vxge_ethtool_gset,
-   .set_settings   = vxge_ethtool_sset,
.get_drvinfo= vxge_ethtool_gdrvinfo,
.get_regs_len   = vxge_ethtool_get_regs_len,
.get_regs   = vxge_ethtool_gregs,
@@ -1139,6 +1144,8 @@ static int vxge_fw_flash(struct net_device *dev, struct 
ethtool_flash *parms)
.get_sset_count = vxge_ethtool_get_sset_count,
.get_ethtool_stats  = vxge_get_ethtool_stats,
.flash_device   = vxge_fw_flash,
+   .get_link_ksettings = vxge_ethtool_get_link_ksettings,
+   .set_link_ksettings = vxge_ethtool_set_link_ksettings,
 };
 
 void vxge_initialize_ethtool_ops(struct net_device *ndev)
-- 
1.7.4.4

[PATCH] spi-nor: use true/false for bool

[Nicholas Mc Guire]

writeable in struct intel_spi is a boolean and assignment should be to 
true/false not 1/0 as recommended by boolinit.cocci.

Signed-off-by: Nicholas Mc Guire 
---

make coccicheck complained with:
 ./drivers/mtd/spi-nor/intel-spi.c:707:3-18: WARNING: Assignment of bool to 0/1

Patch was compile tested with: multi_v7_defconfig (implies CONFIG_MTD_SPI_NOR=y)

Patch is against 4.10-rc6 (localversion-next is next-20170210)

 drivers/mtd/spi-nor/intel-spi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/intel-spi.c b/drivers/mtd/spi-nor/intel-spi.c
index a10f602..e43ce63 100644
--- a/drivers/mtd/spi-nor/intel-spi.c
+++ b/drivers/mtd/spi-nor/intel-spi.c
@@ -704,7 +704,7 @@ static void intel_spi_fill_partition(struct intel_spi *ispi,
 * whole partition read-only to be on the safe side.
 */
if (intel_spi_is_protected(ispi, base, limit))
-   ispi->writeable = 0;
+   ispi->writeable = false;
 
end = (limit << 12) + 4096;
if (end > part->size)
-- 
2.1.4

[PATCH] spi-nor: use ERR_CAST in return

[Nicholas Mc Guire]

This fixes a sparse warning about 

Signed-off-by: Nicholas Mc Guire 
---

sparse complained about:
drivers/mtd/spi-nor/intel-spi.c:731:28: warning: incorrect type in return 
expression (different address spaces)
drivers/mtd/spi-nor/intel-spi.c:731:28:expected struct intel_spi *
drivers/mtd/spi-nor/intel-spi.c:731:28:got void [noderef] *base

Patch was compile tested with: multi_v7_defconfig (implies CONFIG_MTD_SPI_NOR=y)

Patch is against 4.10-rc6 (localversion-next is next-20170210)

 drivers/mtd/spi-nor/intel-spi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/intel-spi.c b/drivers/mtd/spi-nor/intel-spi.c
index e43ce63..986a3d0 100644
--- a/drivers/mtd/spi-nor/intel-spi.c
+++ b/drivers/mtd/spi-nor/intel-spi.c
@@ -728,7 +728,7 @@ struct intel_spi *intel_spi_probe(struct device *dev,
 
ispi->base = devm_ioremap_resource(dev, mem);
if (IS_ERR(ispi->base))
-   return ispi->base;
+   return ERR_CAST(ispi->base);
 
ispi->dev = dev;
ispi->info = info;
-- 
2.1.4

[PATCH RFC] spi-nor: provide a range for poll_timout

[Nicholas Mc Guire]

The overall poll time here is INTEL_SPI_TIMEOUT * 1000 which is 
5000 * 1000 - so 5seconds and it is coded as a tight loop here delay_us
to readl_poll_timeout() is set to 0. As this is never called in an atomic
context sleeping should be no issue and there is no reasons for the
tight-loop here.

Signed-off-by: Nicholas Mc Guire 
---

Problem located by experimental coccinelle script:
./drivers/mtd/spi-nor/intel-spi.c:265:8-26: WARNING: usleep_range min=0 for 
delay INTEL_SPI_TIMEOUT * 1000
./drivers/mtd/spi-nor/intel-spi.c:274:8-26: WARNING: usleep_range min=0 for 
delay INTEL_SPI_TIMEOUT * 1000

The rational for setting the delay_us here to 40 is that readx_poll_timeout()
will take delay_us >> 2 + 1 as min value and that should be at least 10us (see
Documentation/timers/timers-howto.txt). Ideally the delay would be made
even larger to keep the load on the hrtimer subsystem low as these delays
here do not seem to be critical. Someone that knows the details of this device
would need to check if a larger delay would be ok here.

Patch was compile tested with: multi_v7_defconfig (implies CONFIG_MTD_SPI_NOR=y)
one coccicheck finding reported and one spars finding (in separate patches)

Patch is against 4.10-rc6 (localversion-next is next-20170210)

 drivers/mtd/spi-nor/intel-spi.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/spi-nor/intel-spi.c b/drivers/mtd/spi-nor/intel-spi.c
index a10f602..371bcf9 100644
--- a/drivers/mtd/spi-nor/intel-spi.c
+++ b/drivers/mtd/spi-nor/intel-spi.c
@@ -263,7 +263,7 @@ static int intel_spi_wait_hw_busy(struct intel_spi *ispi)
u32 val;
 
return readl_poll_timeout(ispi->base + HSFSTS_CTL, val,
- !(val & HSFSTS_CTL_SCIP), 0,
+ !(val & HSFSTS_CTL_SCIP), 40,
  INTEL_SPI_TIMEOUT * 1000);
 }
 
@@ -272,7 +272,7 @@ static int intel_spi_wait_sw_busy(struct intel_spi *ispi)
u32 val;
 
return readl_poll_timeout(ispi->sregs + SSFSTS_CTL, val,
- !(val & SSFSTS_CTL_SCIP), 0,
+ !(val & SSFSTS_CTL_SCIP), 40,
  INTEL_SPI_TIMEOUT * 1000);
 }
 
-- 
2.1.4

net/llc: BUG in llc_sap_state_process/skb_set_owner_r

[Andrey Konovalov]

Hi,

I've got the following error report while fuzzing the kernel with syzkaller.

On commit 926af6273fc683cd98cd0ce7bf0d04a02eed6742.

A reproducer and .config are attached

kernel BUG at ./include/linux/skbuff.h:2389!
invalid opcode:  [#1] SMP KASAN
Dumping ftrace buffer:
   (ftrace buffer empty)
Modules linked in:
CPU: 0 PID: 9315 Comm: syz-executor2 Not tainted 4.10.0-rc7+ #126
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: 88006861c480 task.stack: 88006a988000
RIP: 0010:skb_set_owner_r include/linux/skbuff.h:2389 [inline]
RIP: 0010:__sock_queue_rcv_skb+0x8c0/0xda0 net/core/sock.c:425
RSP: 0018:88003ec06b58 EFLAGS: 00010206
RAX: 88006861c480 RBX: 8800371c2568 RCX: 
RDX: 0100 RSI: 110006ba08ab RDI: 880035d04560
RBP: 88003ec06dc0 R08: 0002 R09: 0001
R10:  R11: dc00 R12: 880035d04540
R13: 88003ec06d98 R14: 8800371c2590 R15: 880035d045a0
FS:  7fa8005ac700() GS:88003ec0() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 004a6f68 CR3: 38e25000 CR4: 06f0
Call Trace:
 
 sock_queue_rcv_skb+0x3a/0x50 net/core/sock.c:451
 llc_sap_state_process+0x3e3/0x4e0 net/llc/llc_sap.c:220
 llc_sap_rcv net/llc/llc_sap.c:294 [inline]
 llc_sap_handler+0x695/0x1320 net/llc/llc_sap.c:434
 llc_rcv+0x6da/0xed0 net/llc/llc_input.c:208
 __netif_receive_skb_core+0x1ae5/0x3400 net/core/dev.c:4190
 __netif_receive_skb+0x2a/0x170 net/core/dev.c:4228
 process_backlog+0xe5/0x6c0 net/core/dev.c:4839
 napi_poll net/core/dev.c:5202 [inline]
 net_rx_action+0xe70/0x1900 net/core/dev.c:5267
 __do_softirq+0x2fb/0xb7d kernel/softirq.c:284
 do_softirq_own_stack+0x1c/0x30 arch/x86/entry/entry_64.S:902
 
 do_softirq.part.17+0x1e8/0x230 kernel/softirq.c:328
 do_softirq kernel/softirq.c:176 [inline]
 __local_bh_enable_ip+0x1f2/0x200 kernel/softirq.c:181
 local_bh_enable include/linux/bottom_half.h:31 [inline]
 rcu_read_unlock_bh include/linux/rcupdate.h:971 [inline]
 __dev_queue_xmit+0xd87/0x2860 net/core/dev.c:3399
 dev_queue_xmit+0x17/0x20 net/core/dev.c:3405
 llc_build_and_send_ui_pkt+0x240/0x330 net/llc/llc_output.c:74
 llc_ui_sendmsg+0x98d/0x1430 net/llc/af_llc.c:928
 sock_sendmsg_nosec net/socket.c:635 [inline]
 sock_sendmsg+0xca/0x110 net/socket.c:645
 ___sys_sendmsg+0x9d2/0xae0 net/socket.c:1985
 __sys_sendmsg+0x138/0x320 net/socket.c:2019
 SYSC_sendmsg net/socket.c:2030 [inline]
 SyS_sendmsg+0x2d/0x50 net/socket.c:2026
 entry_SYSCALL_64_fastpath+0x1f/0xc2
RIP: 0033:0x4458b9
RSP: 002b:7fa8005abb58 EFLAGS: 0286 ORIG_RAX: 002e
RAX: ffda RBX: 0006 RCX: 004458b9
RDX: 00040880 RSI: 20003000 RDI: 0006
RBP: 006e1b00 R08:  R09: 
R10:  R11: 0286 R12: 00708000
R13: 0082 R14: 2000 R15: 
Code: 4b 50 fe e9 b1 f8 ff ff e8 3e 4a 50 fe e9 78 f8 ff ff e8 34 4a
50 fe e9 6d f9 ff ff e8 2a 4a 50 fe e9 93 f9 ff ff e8 20 0a 26 fe <0f>
0b e8 19 0a 26 fe be 3c 01 00 00 48 c7 c7 e0 e9 22 85 e8 b8
RIP: skb_set_owner_r include/linux/skbuff.h:2389 [inline] RSP: 88003ec06b58
RIP: __sock_queue_rcv_skb+0x8c0/0xda0 net/core/sock.c:425 RSP: 88003ec06b58
---[ end trace 58af2d02ad7f84f0 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Dumping ftrace buffer:
   (ftrace buffer empty)
Kernel Offset: disabled
Rebooting in 86400 seconds..
// autogenerated by syzkaller (http://github.com/google/syzkaller)

#ifndef __NR_sendmsg
#define __NR_sendmsg 46
#endif
#ifndef __NR_mmap
#define __NR_mmap 9
#endif
#ifndef __NR_socket
#define __NR_socket 41
#endif
#ifndef __NR_connect
#define __NR_connect 42
#endif

#define _GNU_SOURCE

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

const int kFailStatus = 67;
const int kErrorStatus = 68;
const int kRetryStatus = 69;

__attribute__((noreturn)) void doexit(int status)
{
  volatile unsigned i;
  syscall(__NR_exit_group, status);
  for (i = 0;; i++) {
  }
}

__attribute__((noreturn)) void fail(const char* msg, ...)
{
  int e = errno;
  fflush(stdout);
  va_list args;
  va_start(args, msg);
  vfprintf(stderr, msg, args);
  va_end(args);
  fprintf(stderr, " (errno %d)\n", e);
  doexit(e == ENOMEM ? kRetryStatus : kFailStatus);
}

__attribute__((noreturn)) void exitf(const char* msg, ...)
{
  int e = errno;
  fflush(stdout);
  va_list args;
  va_start(args, msg);
  vfprintf(stderr, msg, args);
  va_end(args);
  fprintf(stderr, " (errno %d)\n", e);
  doexit(kRetryStatus);
}

static int flag_debug;

void debug(const char* 

Re: net/llc: bug in llc_pdu_init_as_xid_cmd/skb_over_panic

[Andrey Konovalov]

On Fri, Feb 10, 2017 at 4:12 PM, Andrey Konovalov  wrote:
> Hi,
>
> I've got the following error report while fuzzing the kernel with syzkaller.
>
> On commit 926af6273fc683cd98cd0ce7bf0d04a02eed6742.
>
> A reproducer and .config are attached
>
> kernel BUG at net/core/skbuff.c:105!
> invalid opcode:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 2 PID: 6558 Comm: syz-executor4 Not tainted 4.10.0-rc7+ #126
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> task: 88003c49c480 task.stack: 88003a5c
> RIP: 0010:skb_panic+0x16f/0x200 net/core/skbuff.c:101
> RSP: 0018:88003a5c77d0 EFLAGS: 00010286
> RAX: 0082 RBX: 88006be991c0 RCX: 
> RDX: 0082 RSI: 814567fc RDI: ed00074b8eec
> RBP: 88003a5c7838 R08: 0001 R09: 
> R10: 0002 R11: 0001 R12: 85231ee0
> R13: 834a6722 R14: 0003 R15: 88006c81c580
> FS:  7f89298c7700() GS:88006de0() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 20ee5000 CR3: 58697000 CR4: 06e0
> Call Trace:
>  skb_over_panic net/core/skbuff.c:110 [inline]
>  skb_put+0x18d/0x1d0 net/core/skbuff.c:1437
>  llc_pdu_init_as_xid_cmd include/net/llc_pdu.h:377 [inline]
>  llc_sap_action_send_xid_c+0x2a2/0x3b0 net/llc/llc_s_ac.c:82
>  llc_exec_sap_trans_actions net/llc/llc_sap.c:152 [inline]
>  llc_sap_next_state net/llc/llc_sap.c:181 [inline]
>  llc_sap_state_process+0x26b/0x4e0 net/llc/llc_sap.c:212
>  llc_build_and_send_xid_pkt+0x19f/0x200 net/llc/llc_sap.c:276
>  llc_ui_sendmsg+0xad9/0x1430 net/llc/af_llc.c:938
>  sock_sendmsg_nosec net/socket.c:635 [inline]
>  sock_sendmsg+0xca/0x110 net/socket.c:645
>  ___sys_sendmsg+0x9d2/0xae0 net/socket.c:1985
>  __sys_sendmsg+0x138/0x320 net/socket.c:2019
>  SYSC_sendmsg net/socket.c:2030 [inline]
>  SyS_sendmsg+0x2d/0x50 net/socket.c:2026
>  entry_SYSCALL_64_fastpath+0x1f/0xc2
> RIP: 0033:0x4458b9
> RSP: 002b:7f89298c6b58 EFLAGS: 0286 ORIG_RAX: 002e
> RAX: ffda RBX: 0005 RCX: 004458b9
> RDX: 00040085 RSI: 20001fc8 RDI: 0005
> RBP: 006e1ae0 R08:  R09: 
> R10:  R11: 0286 R12: 00708000
> R13:  R14: c0206434 R15: 201fcfe0
> Code: 00 00 00 48 89 54 24 10 48 c7 c7 60 19 23 85 48 89 74 24 08 4c
> 89 04 24 4c 89 ea 4c 89 7c 24 18 45 89 f0 4c 89 e6 e8 1e c0 38 fe <0f>
> 0b 4c 89 4d b8 4c 89 45 c0 48 89 75 c8 48 89 55 d0 e8 6a 5e
> RIP: skb_panic+0x16f/0x200 net/core/skbuff.c:101 RSP: 88003a5c77d0
> ---[ end trace 89f0ca2ea5bc3ead ]---
> Kernel panic - not syncing: Fatal exception
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..

+a...@redhat.com

Re: [PATCH v5 1/8] PCI: Recognize Thunderbolt devices

[Lukas Wunner]

On Fri, Feb 10, 2017 at 11:42:50AM -0600, Bjorn Helgaas wrote:
> On Sun, Jan 29, 2017 at 01:26:16AM +0100, Lukas Wunner wrote:
> > On Sat, Jan 28, 2017 at 03:52:08PM -0600, Bjorn Helgaas wrote:
> > > On Sun, Jan 15, 2017 at 09:03:45PM +0100, Lukas Wunner wrote:
> 
> > > > +static void set_pcie_vendor_specific(struct pci_dev *dev)
> > > 
> > > This is very specific to Thunderbolt, so let's name it something that
> > > conveys that information.  The fact that we use a vendor-specific
> > > capability to figure it out isn't really relevant in the caller.
> > 
> > I thought that we may have the necessity in the future to parse other
> > VSECs on device probe, so I gave the function this generic name.
> > 
> > Think about it, every VSEC that needs to be parsed needs the while loop
> > below.  It's more efficient to have only a single while loop that handles
> > *all* VSECs at once.
> > 
> > If someone needs to parse another VSEC, they just add it to this function.
> > So IMO the way I've solved it is preferable to just adding a Thunderbolt-
> > specific function.
> > 
> > Are you sure you want this renamed? (y/n)
> 
> Sorry for the delay; I missed this question.  If this has already been
> merged somewhere as-is, that's fine.

No, none of the patches in this series have been merged so far.  Greg's
tree is closed for the duration of the merge window, which is expected
to open today.  Therefore, please merge whatever patches in this series
you feel comfortable with.  It would be good if you could merge at least
patch [1/8] as it would allow me to fix the issues in apple-gmux and
vga_switcheroo that I'm mentioning in the changelog in v4.12.  Also,
patch [2/8] seems uncontroversial.

Greg has acked v5 of this series and suggested that you take it due to
all the PCI changes:
https://lkml.org/lkml/2017/1/19/177

Andreas Noever acked and tested v2 of this series:
https://www.spinics.net/lists/linux-pci/msg51274.html


> If you repost it for any reason,
> I would prefer to rename it so it reflects the functionality rather
> than the source of the information.  This isn't a performance path, so
> readability is more important than optimization.

Sure, I've renamed it.

Thanks,

Lukas

Re: net/ipv6: use-after-free in sock_wfree

[Andrey Konovalov]

On Mon, Jan 9, 2017 at 6:21 PM, Eric Dumazet  wrote:
> On Mon, Jan 9, 2017 at 9:11 AM, Andrey Konovalov  
> wrote:
>> On Mon, Jan 9, 2017 at 6:08 PM, Andrey Konovalov  
>> wrote:
>>> Hi!
>>>
>>> I've got the following error report while running the syzkaller fuzzer.
>>>
>>> On commit a121103c922847ba5010819a3f250f1f7fc84ab8 (4.10-rc3).
>>>
>>> A reproducer is attached.
>>>
>>> ==
>>> BUG: KASAN: use-after-free in sock_wfree+0x118/0x120
>>> Read of size 8 at addr 880062da0060 by task a.out/4140
>>>
>>> page:ea00018b6800 count:1 mapcount:0 mapping:  (null)
>>> index:0x0 compound_mapcount: 0
>>> flags: 0x1008100(slab|head)
>>> raw: 01008100   000180130013
>>> raw: dead0100 dead0200 88006741f140 
>>> page dumped because: kasan: bad access detected
>>>
>>> CPU: 0 PID: 4140 Comm: a.out Not tainted 4.10.0-rc3+ #59
>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>>> Call Trace:
>>>  __dump_stack lib/dump_stack.c:15
>>>  dump_stack+0x292/0x398 lib/dump_stack.c:51
>>>  describe_address mm/kasan/report.c:262
>>>  kasan_report_error+0x121/0x560 mm/kasan/report.c:370
>>>  kasan_report mm/kasan/report.c:392
>>>  __asan_report_load8_noabort+0x3e/0x40 mm/kasan/report.c:413
>>>  sock_flag ./arch/x86/include/asm/bitops.h:324
>>>  sock_wfree+0x118/0x120 net/core/sock.c:1631
>>>  skb_release_head_state+0xfc/0x250 net/core/skbuff.c:655
>>>  skb_release_all+0x15/0x60 net/core/skbuff.c:668
>>>  __kfree_skb+0x15/0x20 net/core/skbuff.c:684
>>>  kfree_skb+0x16e/0x4e0 net/core/skbuff.c:705
>>>  inet_frag_destroy+0x121/0x290 net/ipv4/inet_fragment.c:304
>>>  inet_frag_put ./include/net/inet_frag.h:133
>>>  nf_ct_frag6_gather+0x1125/0x38b0 
>>> net/ipv6/netfilter/nf_conntrack_reasm.c:617
>>>  ipv6_defrag+0x21b/0x350 net/ipv6/netfilter/nf_defrag_ipv6_hooks.c:68
>>>  nf_hook_entry_hookfn ./include/linux/netfilter.h:102
>>>  nf_hook_slow+0xc3/0x290 net/netfilter/core.c:310
>>>  nf_hook ./include/linux/netfilter.h:212
>>>  __ip6_local_out+0x52c/0xaf0 net/ipv6/output_core.c:160
>>>  ip6_local_out+0x2d/0x170 net/ipv6/output_core.c:170
>>>  ip6_send_skb+0xa1/0x340 net/ipv6/ip6_output.c:1722
>>>  ip6_push_pending_frames+0xb3/0xe0 net/ipv6/ip6_output.c:1742
>>>  rawv6_push_pending_frames net/ipv6/raw.c:613
>>>  rawv6_sendmsg+0x2cff/0x4130 net/ipv6/raw.c:927
>>>  inet_sendmsg+0x164/0x5b0 net/ipv4/af_inet.c:744
>>>  sock_sendmsg_nosec net/socket.c:635
>>>  sock_sendmsg+0xca/0x110 net/socket.c:645
>>>  sock_write_iter+0x326/0x620 net/socket.c:848
>>>  new_sync_write fs/read_write.c:499
>>>  __vfs_write+0x483/0x760 fs/read_write.c:512
>>>  vfs_write+0x187/0x530 fs/read_write.c:560
>>>  SYSC_write fs/read_write.c:607
>>>  SyS_write+0xfb/0x230 fs/read_write.c:599
>>>  entry_SYSCALL_64_fastpath+0x1f/0xc2 arch/x86/entry/entry_64.S:203
>>> RIP: 0033:0x7ff26e6f5b79
>>> RSP: 002b:7ff268e0ed98 EFLAGS: 0206 ORIG_RAX: 0001
>>> RAX: ffda RBX: 7ff268e0f9c0 RCX: 7ff26e6f5b79
>>> RDX: 0010 RSI: 20f50fe1 RDI: 0003
>>> RBP: 7ff26ebc1220 R08:  R09: 
>>> R10:  R11: 0206 R12: 
>>> R13: 7ff268e0f9c0 R14: 7ff26efec040 R15: 0003
>>>
>>> The buggy address belongs to the object at 880062da
>>>  which belongs to the cache RAWv6 of size 1504
>>> The buggy address 880062da0060 is located 96 bytes inside
>>>  of 1504-byte region [880062da, 880062da05e0)
>>>
>>> Freed by task 4113:
>>>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
>>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:502
>>>  set_track mm/kasan/kasan.c:514
>>>  kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:578
>>>  slab_free_hook mm/slub.c:1352
>>>  slab_free_freelist_hook mm/slub.c:1374
>>>  slab_free mm/slub.c:2951
>>>  kmem_cache_free+0xb2/0x2c0 mm/slub.c:2973
>>>  sk_prot_free net/core/sock.c:1377
>>>  __sk_destruct+0x49c/0x6e0 net/core/sock.c:1452
>>>  sk_destruct+0x47/0x80 net/core/sock.c:1460
>>>  __sk_free+0x57/0x230 net/core/sock.c:1468
>>>  sk_free+0x23/0x30 net/core/sock.c:1479
>>>  sock_put ./include/net/sock.h:1638
>>>  sk_common_release+0x31e/0x4e0 net/core/sock.c:2782
>>>  rawv6_close+0x54/0x80 net/ipv6/raw.c:1214
>>>  inet_release+0xed/0x1c0 net/ipv4/af_inet.c:425
>>>  inet6_release+0x50/0x70 net/ipv6/af_inet6.c:431
>>>  sock_release+0x8d/0x1e0 net/socket.c:599
>>>  sock_close+0x16/0x20 net/socket.c:1063
>>>  __fput+0x332/0x7f0 fs/file_table.c:208
>>>  fput+0x15/0x20 fs/file_table.c:244
>>>  task_work_run+0x19b/0x270 kernel/task_work.c:116
>>>  exit_task_work ./include/linux/task_work.h:21
>>>  do_exit+0x186b/0x2800 kernel/exit.c:839
>>>  do_group_exit+0x149/0x420 kernel/exit.c:943
>>>  SYSC_exit_group kernel/exit.c:954
>>>  SyS_exit_group+0x1d/0x20 kernel/exit.c:952
>>>  entry_SYSCALL_64_fastpath+0x

[PATCH 1/20] staging: rtl8192u: Replace symbolic permissions with octal permissions

[simran singhal]

WARNING: Symbolic permissions 'S_IRUGO | S_IWUSR' are not preferred.
Consider using octal permissions '0644'.
This warning is detected by checkpatch.pl

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_module.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
index a9a92d8..2ebc320 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_module.c
@@ -283,7 +283,7 @@ int __init ieee80211_debug_init(void)
" proc directory\n");
return -EIO;
}
-   e = proc_create("debug_level", S_IRUGO | S_IWUSR,
+   e = proc_create("debug_level", 0644,
  ieee80211_proc, &fops);
if (!e) {
remove_proc_entry(DRV_NAME, init_net.proc_net);
-- 
2.7.4

[PATCH 2/20] staging: rtl8192u: Fixed 'tabstop' coding style warnings

[simran singhal]

Fixed checkpatch warning "Statements should start on a tabstop" in
rtl8192u module.

Signed-off-by: simran singhal 
---
 drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c 
b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
index 563d7fe..814ab5a 100644
--- a/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
+++ b/drivers/staging/rtl8192u/ieee80211/ieee80211_wx.c
@@ -666,7 +666,7 @@ int ieee80211_wx_set_encode_ext(struct ieee80211_device 
*ieee,
if (ieee->set_security)
ieee->set_security(ieee->dev, &sec);
 
-if (ieee->reset_on_keychange &&
+   if (ieee->reset_on_keychange &&
ieee->iw_mode != IW_MODE_INFRA &&
ieee->reset_port && ieee->reset_port(dev)) {
IEEE80211_DEBUG_WX("%s: reset_port failed\n", dev->name);
-- 
2.7.4

Re: net/llc: BUG in llc_sap_state_process/skb_set_owner_r

[Eric Dumazet]

On Sun, Feb 12, 2017 at 8:44 AM, Andrey Konovalov  wrote:
> Hi,
>
> I've got the following error report while fuzzing the kernel with syzkaller.
>
> On commit 926af6273fc683cd98cd0ce7bf0d04a02eed6742.
>
> A reproducer and .config are attached

Thanks for the report.

llc sets skb->sk   without corresponding skb->destructor.

This is considered invalid by our current standards.

As I added the sanity check in skb_destructor() back in linux-3.12
(!!!), I will send the corresponding LLC fix.

( commit 376c7311bdb6efea3322310333576a04d73fbe4c )

Re: [PATCH v5 3/8] PCI: Don't block runtime PM for Thunderbolt host hotplug ports

[Lukas Wunner]

On Fri, Feb 10, 2017 at 12:39:12PM -0600, Bjorn Helgaas wrote:
> On Sun, Jan 15, 2017 at 09:03:45PM +0100, Lukas Wunner wrote:
> > Hotplug ports generally block their parents from suspending to D3hot as
> > otherwise their interrupts couldn't be delivered.
> 
> This sounds related to PCIe r3.1, sec 5.3.1.4, which says functions
> supporting PME generation from D3 must support it for both D3cold and
> D3hot.  I think in PCIe, PMEs mean PME Messages, and the 5.3.1
> implementation note says Messages are not affected by the PM state of
> virtual bridges.
> 
> So that seems to say that hotplug ports *should* be able to deliver
> PMEs even while in D3hot.
> 
> Maybe you're referring to the hotplug interrupts themselves, not the
> PME?  I assume a hotplug event (presence detect, attention button,
> etc) would first cause a PME, then the OS would return the path to D0,
> then the hotplug interrupt would be delivered.
> 
> > An exception are Thunderbolt host controllers:  They have a separate
> > GPIO pin to side-band signal plug events even if the controller is
> > powered down or its parent ports are suspended to D3.  They can be told
> > apart from Thunderbolt controllers in attached devices by checking if
> > they're situated below a non-Thunderbolt device (typically a root port,
> > or the downstream port of a PCIe switch in the case of the MacPro6,1).
> 
> In PCIe terms, does a "Thunderbolt host controller" look like a
> downstream port that supports hotplug?
> 
> It seems like the PCIe PME mechanism *should* work pretty much like
> this sideband GPIO.  But I might be reading the spec wrong.

I am dropping this patch in v6 of my Thunderbolt runpm series.

The "Light Ridge" Thunderbolt controller in my machine claims to support
PME, but its WAKE# pin is not connected.  (It's pulled up to 3.3V.)
I also have an external Thunderbolt chassis with the same controller,
and the controller likewise claims to support PME, but its WAKE# pin is
not connected to the PCIe root im my machine in any way.

This led me to the conclusion that PME is not reliable and therefore
in a Thunderbolt daisy chain, which is a cascade of PCIe switches,
only the hotplug port at the farthest end of the chain may suspend to
D3hot, whereas all the ports between it and the root bridge must stay
awake for interrupts to come through.

What I failed to see, due to poor understanding of the (undocumented)
Thunderbolt technology, is that even though ports in the middle of the
chain may be in D3hot and prevent PCIe interrupts from coming through,
the network of Converged I/O switches underlying the PCI tunnels
continues to function and deliver plug events.  It is thus the NHI
driver's job to runtime resume the PCIe switch where a CIO plug event
occurred, as well as its parents, to ensure delivery of PCIe interrupts.
The CIO plug event essentially serves as a sideband signal.  So far the
thunderbolt NHI driver does not support daisy chaining, so this is not
yet an issue.  (Only for tunnels established by the EFI driver.)

Thanks,

Lukas

Клиентские базы +79139230330 Skype: prodawez390 Email: prodawez...@gmail.com Узнайте подробнее!

[linux-kernel]

Клиентские базы +79139230330 Skype: prodawez390 Email: prodawez...@gmail.com 
Узнайте подробнее!

Re: [PATCH] clocksource: add __ro_after_init to cyclecounter

[Bhumika Goyal]

On Sun, Feb 12, 2017 at 2:01 AM, Ard Biesheuvel
 wrote:
> On 11 February 2017 at 19:20, Bhumika Goyal  wrote:
>> The object cyclecounter of type cyclecounter is not getting modified
>> after getting initialized by arch_counter_register. Apart from
>> initialization in arch_counter_register it is also passed as an argument
>> to the function timecounter_init but this argument is of type const.
>> Therefore, add __ro_after_init to its declaration.
>>
>
> I think adding __ro_after_init is fine if this struct is never
> modified after init. But the reference in the commit log to the
> constness of the timecounter_init() argument  makes no sense: that
> only means timecounter_init() will not modify the object, which allows
> pointers to const objects to be passed to it as well. The opposite is
> not true, though: there is no requirement whatsoever that objects
> passed into const pointer arguments should be const themselves.
>
>

Yes, true. I will change the commit log and send a v2. Thanks for explaining.

Thanks,
Bhumika

>> Signed-off-by: Bhumika Goyal 
>> ---
>>  drivers/clocksource/arm_arch_timer.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/clocksource/arm_arch_timer.c 
>> b/drivers/clocksource/arm_arch_timer.c
>> index 4c8c3fb..a10506b 100644
>> --- a/drivers/clocksource/arm_arch_timer.c
>> +++ b/drivers/clocksource/arm_arch_timer.c
>> @@ -580,7 +580,7 @@ static u64 arch_counter_read_cc(const struct 
>> cyclecounter *cc)
>> .flags  = CLOCK_SOURCE_IS_CONTINUOUS,
>>  };
>>
>> -static struct cyclecounter cyclecounter = {
>> +static struct cyclecounter cyclecounter __ro_after_init = {
>> .read   = arch_counter_read_cc,
>> .mask   = CLOCKSOURCE_MASK(56),
>>  };
>> --
>> 1.9.1
>>
>>
>> ___
>> linux-arm-kernel mailing list
>> linux-arm-ker...@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH] clocksource: add __ro_after_init to cyclecounter

[Bhumika Goyal]

On Sun, Feb 12, 2017 at 2:05 AM, Thomas Gleixner  wrote:
> On Sun, 12 Feb 2017, Bhumika Goyal wrote:
>
> Please be more careful with your subject line. The prefix for this is
> definitely not 'clocksource'. git log would have told you the proper one:
>
> clocksource/drivers/arm_arch_timer
>
> 'clocksource' is the general subsystem and used for system wide changes or
> core changes, but not for a particular driver.
>

I will be more careful about this in future.

Thanks,
Bhumika

>> The object cyclecounter of type cyclecounter is not getting modified
>> after getting initialized by arch_counter_register. Apart from
>> initialization in arch_counter_register it is also passed as an argument
>> to the function timecounter_init but this argument is of type const.
>> Therefore, add __ro_after_init to its declaration.
>
> Other than that this is fine. I'll fix it up when applying.
>
> Thanks,
>
> tglx

Re: [ibm-acpi-devel] [PATCH 1/1] thinkpad_acpi: Add support for status (external cover) LED

[Sebastian Reichel]

Hi,

On Tue, Feb 07, 2017 at 11:01:32PM -0200, Henrique de Moraes Holschuh wrote:
> Hello Adam,
> 
> I apologise for the delay on answering you.
> 
> On Tue, 31 Jan 2017, Adam Goode wrote:
> > On Thu, Jan 19, 2017 at 12:21 PM, Adam Goode  wrote:
> > > This allows the control of the red status LED, which is the dot of the "i"
> > > in the word "ThinkPad" on the outside cover of newer models.
> > >
> > > In the manual, both this LED and the power LED are referred to as
> > > the "system-status indicators" without distinction between the two, so
> > > I chose "status" as the LED name.
> 
> I seem to recall this LED had an ACPI interface that was specific for
> it, and allowed it to on/off/sine-wave?

I don't know what the ACPI interface looks like, but the lid status
led goes into sine-wave mode during suspend. Note, that the power-led
also goes into sine-wave mode during suspend and is already supported
by thinkpad-acpi's LED code (without the sine-wave feature as far
as I can tell).

> > > Signed-off-by: Adam Goode 
> > >
> > > diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/
> > > thinkpad_acpi.c
> > > index cacb43fb1df7..6577bf8e5635 100644
> > > --- a/drivers/platform/x86/thinkpad_acpi.c
> > > +++ b/drivers/platform/x86/thinkpad_acpi.c
> > > @@ -5611,11 +5611,11 @@ static const char * const
> > > tpacpi_led_names[TPACPI_LED_NUMLEDS] = {
> > > "tpacpi::standby",
> > > "tpacpi::dock_status1",
> > > "tpacpi::dock_status2",
> > > -   "tpacpi::unknown_led2",
> > > +   "tpacpi::status",

"status" looks a bit generic. I suggest "external_lid_status".

> > > "tpacpi::unknown_led3",
> > > "tpacpi::thinkvantage",
> > >  };
> > > -#define TPACPI_SAFE_LEDS   0x1081U
> > > +#define TPACPI_SAFE_LEDS   0x1481U
> 
> What happens on older Lenovo models (x00, x10, x20 series?)?  I think
> the T410 already had it...
> 
> Also, please add code to not export it to userspace (as a led class) on
> IBM.

Adam, can you prepare an updated patch? I would like to use this
led to notify myself about events (i.e. compilation finished)
while my thinkpad's lid is closed.

-- Sebastian


signature.asc
Description: PGP signature

Re: [ibm-acpi-devel] [PATCH 1/1] thinkpad_acpi: Add support for status (external cover) LED

[Adam Goode]

On Sun, Feb 12, 2017 at 1:22 PM, Sebastian Reichel  wrote:
> Hi,
>
> On Tue, Feb 07, 2017 at 11:01:32PM -0200, Henrique de Moraes Holschuh wrote:
>> Hello Adam,
>>
>> I apologise for the delay on answering you.
>>
>> On Tue, 31 Jan 2017, Adam Goode wrote:
>> > On Thu, Jan 19, 2017 at 12:21 PM, Adam Goode  wrote:
>> > > This allows the control of the red status LED, which is the dot of the 
>> > > "i"
>> > > in the word "ThinkPad" on the outside cover of newer models.
>> > >
>> > > In the manual, both this LED and the power LED are referred to as
>> > > the "system-status indicators" without distinction between the two, so
>> > > I chose "status" as the LED name.
>>
>> I seem to recall this LED had an ACPI interface that was specific for
>> it, and allowed it to on/off/sine-wave?
>
> I don't know what the ACPI interface looks like, but the lid status
> led goes into sine-wave mode during suspend. Note, that the power-led
> also goes into sine-wave mode during suspend and is already supported
> by thinkpad-acpi's LED code (without the sine-wave feature as far
> as I can tell).
>
>> > > Signed-off-by: Adam Goode 
>> > >
>> > > diff --git a/drivers/platform/x86/thinkpad_acpi.c b/drivers/platform/x86/
>> > > thinkpad_acpi.c
>> > > index cacb43fb1df7..6577bf8e5635 100644
>> > > --- a/drivers/platform/x86/thinkpad_acpi.c
>> > > +++ b/drivers/platform/x86/thinkpad_acpi.c
>> > > @@ -5611,11 +5611,11 @@ static const char * const
>> > > tpacpi_led_names[TPACPI_LED_NUMLEDS] = {
>> > > "tpacpi::standby",
>> > > "tpacpi::dock_status1",
>> > > "tpacpi::dock_status2",
>> > > -   "tpacpi::unknown_led2",
>> > > +   "tpacpi::status",
>
> "status" looks a bit generic. I suggest "external_lid_status".
>
>> > > "tpacpi::unknown_led3",
>> > > "tpacpi::thinkvantage",
>> > >  };
>> > > -#define TPACPI_SAFE_LEDS   0x1081U
>> > > +#define TPACPI_SAFE_LEDS   0x1481U
>>
>> What happens on older Lenovo models (x00, x10, x20 series?)?  I think
>> the T410 already had it...
>>
>> Also, please add code to not export it to userspace (as a led class) on
>> IBM.
>
> Adam, can you prepare an updated patch? I would like to use this
> led to notify myself about events (i.e. compilation finished)
> while my thinkpad's lid is closed.
>

Yes, I will definitely prepare a new patch at some point. The only
hardware I have to test this on is an old IBM X40 and the Lenovo X260.
(I have a T410 with a busted screen that I could try it on maybe.) But
not much else.

I don't know if I can get to this in the next few weeks, since I am
travelling. If someone would like to clean up the patch and move
forward without me, no problem. Otherwise I will get to it eventually.


Thanks,

Adam


> -- Sebastian

[PATCH] usb: misc: usbtest: remove redundant check on retval < 0

[Colin King]

From: Colin Ian King 

The check for retval being less than zero is always true since
retval equal to -EPIPE at that point.  Replace the existing
conditional with just return retval.

Detected with CoverityScan, CID#114349 ("Logically dead code")

Signed-off-by: Colin Ian King 
---
 drivers/usb/misc/usbtest.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/usb/misc/usbtest.c b/drivers/usb/misc/usbtest.c
index 3525626..17c0810 100644
--- a/drivers/usb/misc/usbtest.c
+++ b/drivers/usb/misc/usbtest.c
@@ -992,7 +992,7 @@ static int ch9_postconfig(struct usbtest_dev *dev)
dev_err(&iface->dev,
"hs dev qualifier --> %d\n",
retval);
-   return (retval < 0) ? retval : -EDOM;
+   return retval;
}
/* usb2.0 but not high-speed capable; fine */
} else if (retval != sizeof(struct usb_qualifier_descriptor)) {
-- 
2.10.2

[tip:irq/core] genirq/devres: Use dev_name(dev) as default for devname

[tip-bot for Heiner Kallweit]

Commit-ID:  899b5fbf9d3fcb721690b4d58cf58cc018517003
Gitweb: http://git.kernel.org/tip/899b5fbf9d3fcb721690b4d58cf58cc018517003
Author: Heiner Kallweit 
AuthorDate: Sun, 12 Feb 2017 16:31:44 +0100
Committer:  Thomas Gleixner 
CommitDate: Sun, 12 Feb 2017 19:49:25 +0100

genirq/devres: Use dev_name(dev) as default for devname

Allow the devname parameter to be NULL and use dev_name(dev) in this case.
This should be an appropriate default for most use cases.

Signed-off-by: Heiner Kallweit 
Link: http://lkml.kernel.org/r/05c63d67-30b4-7026-02d5-ce7fb7bc1...@gmail.com
Signed-off-by: Thomas Gleixner 

---
 kernel/irq/devres.c | 10 --
 1 file changed, 8 insertions(+), 2 deletions(-)

diff --git a/kernel/irq/devres.c b/kernel/irq/devres.c
index 18babef..1613bfd 100644
--- a/kernel/irq/devres.c
+++ b/kernel/irq/devres.c
@@ -34,7 +34,7 @@ static int devm_irq_match(struct device *dev, void *res, void 
*data)
  * @thread_fn: function to be called in a threaded interrupt context. NULL
  * for devices which handle everything in @handler
  * @irqflags: Interrupt type flags
- * @devname: An ascii name for the claiming device
+ * @devname: An ascii name for the claiming device, dev_name(dev) if NULL
  * @dev_id: A cookie passed back to the handler function
  *
  * Except for the extra @dev argument, this function takes the
@@ -58,6 +58,9 @@ int devm_request_threaded_irq(struct device *dev, unsigned 
int irq,
if (!dr)
return -ENOMEM;
 
+   if (!devname)
+   devname = dev_name(dev);
+
rc = request_threaded_irq(irq, handler, thread_fn, irqflags, devname,
  dev_id);
if (rc) {
@@ -81,7 +84,7 @@ EXPORT_SYMBOL(devm_request_threaded_irq);
  * @thread_fn: function to be called in a threaded interrupt context. NULL
  * for devices which handle everything in @handler
  * @irqflags: Interrupt type flags
- * @devname: An ascii name for the claiming device
+ * @devname: An ascii name for the claiming device, dev_name(dev) if NULL
  * @dev_id: A cookie passed back to the handler function
  *
  * Except for the extra @dev argument, this function takes the
@@ -104,6 +107,9 @@ int devm_request_any_context_irq(struct device *dev, 
unsigned int irq,
if (!dr)
return -ENOMEM;
 
+   if (!devname)
+   devname = dev_name(dev);
+
rc = request_any_context_irq(irq, handler, irqflags, devname, dev_id);
if (rc < 0) {
devres_free(dr);

Re: [PATCH] clocksource: add __ro_after_init to cyclecounter

[Thomas Gleixner]

On Sun, 12 Feb 2017, Bhumika Goyal wrote:

> On Sun, Feb 12, 2017 at 2:01 AM, Ard Biesheuvel
>  wrote:
> > On 11 February 2017 at 19:20, Bhumika Goyal  wrote:
> >> The object cyclecounter of type cyclecounter is not getting modified
> >> after getting initialized by arch_counter_register. Apart from
> >> initialization in arch_counter_register it is also passed as an argument
> >> to the function timecounter_init but this argument is of type const.
> >> Therefore, add __ro_after_init to its declaration.
> >>
> >
> > I think adding __ro_after_init is fine if this struct is never
> > modified after init. But the reference in the commit log to the
> > constness of the timecounter_init() argument  makes no sense: that
> > only means timecounter_init() will not modify the object, which allows
> > pointers to const objects to be passed to it as well. The opposite is
> > not true, though: there is no requirement whatsoever that objects
> > passed into const pointer arguments should be const themselves.
> >
> >
> 
> Yes, true. I will change the commit log and send a v2. Thanks for explaining.

I've applied it already and fixed up the subject/changelog. You should have
mail from tip-bot ...

Re: [PATCH] clocksource: add __ro_after_init to cyclecounter

[Bhumika Goyal]

On Mon, Feb 13, 2017 at 12:26 AM, Thomas Gleixner  wrote:
> On Sun, 12 Feb 2017, Bhumika Goyal wrote:
>
>> On Sun, Feb 12, 2017 at 2:01 AM, Ard Biesheuvel
>>  wrote:
>> > On 11 February 2017 at 19:20, Bhumika Goyal  wrote:
>> >> The object cyclecounter of type cyclecounter is not getting modified
>> >> after getting initialized by arch_counter_register. Apart from
>> >> initialization in arch_counter_register it is also passed as an argument
>> >> to the function timecounter_init but this argument is of type const.
>> >> Therefore, add __ro_after_init to its declaration.
>> >>
>> >
>> > I think adding __ro_after_init is fine if this struct is never
>> > modified after init. But the reference in the commit log to the
>> > constness of the timecounter_init() argument  makes no sense: that
>> > only means timecounter_init() will not modify the object, which allows
>> > pointers to const objects to be passed to it as well. The opposite is
>> > not true, though: there is no requirement whatsoever that objects
>> > passed into const pointer arguments should be const themselves.
>> >
>> >
>>
>> Yes, true. I will change the commit log and send a v2. Thanks for explaining.
>
> I've applied it already and fixed up the subject/changelog. You should have
> mail from tip-bot ...

Okay. Thanks. I thought the patch is not applied yet because I haven't
received a mail from tip-bot yet.

Thanks,
Bhumika

Re: [GIT PULL] PCI fixes for v4.10

[Lukas Wunner]

On Fri, Feb 10, 2017 at 06:39:16PM -0800, Yinghai Lu wrote:
> On Thu, Feb 9, 2017 at 12:11 PM, Bjorn Helgaas  wrote:
> > On Thu, Feb 09, 2017 at 09:09:50AM -0600, Bjorn Helgaas wrote:
> > > On Thu, Feb 09, 2017 at 05:06:48AM +0100, Lukas Wunner wrote:
> > > > https://patchwork.kernel.org/patch/9557113/
> > > > https://patchwork.kernel.org/patch/9562007/
> >
> > I apologize: I had quirks on the brain, but neither of the patches
> > above is device-specific.  So neither is claiming broken hardware.
> >
> > However, 9557113 claims we get unwanted PME interrupts if the slot is
> > occupied when we suspend to D3hot.  This is what I want to explore
> > further, because that hardware behavior doesn't really make sense to
> > me.
> >
> > 9562007 apparently fixes something, but at this point it's a debugging
> > patch (no changelog or signed-off-by) so not a candidate for tossing
> > into v4.10 at this late date.
> 
> Agreed. It should need more test coverage.  Found more problems.
> 
> Actually we don't need 9557113 as even with that, we still saw link up
> when power off slots with some cards.
> 
> please check updated version of 9562007, that fix power on/off link up
> problem.

Thank you for debugging this further.  The patch I've submitted today
reinstates runtime PM for hotplug ports but constrains it to those on
a Thunderbolt daisy chain.  The patch allows enabling the feature on
other hardware by booting with pcie_port_pm=force.

A few things to keep in mind:

* On Thunderbolt hotplug ports, interrupts are sent even if the port
  is in D3hot, which as Bjorn has pointed out contradicts the PCI PM
  spec r1.2, table 5-4.  This may be caused by liberal interpretation
  of the spec by Intel when designing the Thunderbolt controllers,
  or perhaps Thunderbolt controllers simply do not possess a "real",
  fully-fledged PCIe switch.  I let the hotplug ports go to D3hot,
  expecting them to continue delivering interrupts but YMMV.

* You've reported that the hotplug port must be in D0 to enable and
  disable power on the slot.  I think this is not required by the spec.
  Thunderbolt hotplug ports do not support power control.  My suspicion
  is that the ports on your machine must remain in D0 as long as the
  slot is occupied, i.e. they must not runtime suspend to D3hot.  Can
  this happen?  Yes.  I release the runtime PM ref once a slot has been
  enabled or disabled.  The device remains runtime active as long as it
  has active children.  If all children runtime suspend, the port will
  go to D3hot, which might cause trouble if this implies that slot power
  is turned off.  To test this you need a card whose Linux driver supports
  runtime PM (e.g. Nvidia GPU, boot with nouveau.runpm=1).

* If the hotplug slot has runtime suspended to D3hot and there are ports
  above it that also runtime suspend to D3hot, its config space is no
  longer accessible and in-band interrupts won't come through.  A side-band
  signaling method such as PME WAKE# is required to deliver interrupts from
  this state.  Also, the hotplug_slot_ops defined for pciehp will have to
  be augmented with calls to pm_runtime_get_sync() and pm_runtime_put()
  to wake the parent of the hotplug port so that config space is accessible
  when interacting with the slot via sysfs.

* If pciehp_poll_mode is used, it may be necessary to call
  pm_runtime_forbid(). (Or alternatively runtime resume it whenever config
  space is polled, but that seems silly.)


> --- linux-2.6.orig/drivers/pci/hotplug/pciehp_ctrl.c
> +++ linux-2.6/drivers/pci/hotplug/pciehp_ctrl.c
> @@ -89,17 +89,17 @@ static int board_added(struct slot *p_sl
>   struct controller *ctrl = p_slot->ctrl;
>   struct pci_bus *parent = ctrl->pcie->port->subordinate;
>  
> + pm_runtime_get_sync(&ctrl->pcie->port->dev);
>   if (POWER_CTRL(ctrl)) {
>   /* Power on slot */
>   retval = pciehp_power_on_slot(p_slot);
>   if (retval)
> - return retval;
> + goto err_exit;
>   }
>  
>   pciehp_green_led_blink(p_slot);
>  
>   /* Check link training status */
> - pm_runtime_get_sync(&ctrl->pcie->port->dev);
>   retval = pciehp_check_link_status(ctrl);
>   if (retval) {
>   ctrl_err(ctrl, "Failed to check link status\n");

Well, it may be simpler to just move the pm_runtime_get_sync() / _put()
to the caller of board_added() and remove_board().  That way it's not
necessary to insert a pm_runtime_put() into every error path.  The
patch I've submitted today does exactly that.

In fact, v2 of my Thunderbolt runtime PM series, posted in May 2016,
already did that:
http://www.spinics.net/lists/linux-pci/msg51153.html

But for v3 I decided to move the pm_runtime_get_sync() / _put() down
the call stack into board_added() and remove_board() to make more
precise exactly which operations require the hotplug port to be in D0.
Guess that wasn't a good idea. :-(

Thanks,

Lukas

Re: [RFC][PATCH 2/7] x86, mpx: update MPX to grok larger bounds tables

[Thomas Gleixner]

On Wed, 1 Feb 2017, Dave Hansen wrote:
>  /*
> - * The upper 28 bits [47:20] of the virtual address in 64-bit
> - * are used to index into bounds directory (BD).
> + * The uppermost bits [56:20] of the virtual address in 64-bit
> + * are used to index into bounds directory (BD).  On processors
> + * with support for smaller virtual address space size, the "56"
> + * is obviously smaller.

 ... space size, the upper limit is adjusted accordingly.

Or something like that,

> +/*
> + * Note: size of tables on 64-bit is not constant, so we have no
> + * fixed definition for MPX_BD_NR_ENTRIES_64.
> + *
> + * The 5-Level Paging Whitepaper says:  "A bound directory
> + * comprises 2^(28+MAWA) 64-bit entries."  Since MAWA=0 in
> + * legacy mode:
> + */
> +#define MPX_BD_LEGACY_NR_ENTRIES_64  (1UL<<28)

(1UL << 28) please

>  
> +static inline int mpx_bd_size_shift(struct mm_struct *mm)
> +{
> + return mm->context.mpx_bd_shift;
> +}

Do we really need that helper?

>  static inline unsigned long mpx_bd_size_bytes(struct mm_struct *mm)
>  {
> - if (is_64bit_mm(mm))
> - return MPX_BD_SIZE_BYTES_64;
> - else
> + if (!is_64bit_mm(mm))
>   return MPX_BD_SIZE_BYTES_32;
> +
> + /*
> +  * The bounds directory grows with the address space size.
> +  * The "legacy" shift is 0.
> +  */
> + return MPX_BD_BASE_SIZE_BYTES_64 << mpx_bd_shift_shift(mm);

shift_shift. I wonder how that compiles...

Looks good otherwise.

Thanks,

tglx

Re: [RFC][PATCH 3/7] x86, mpx: extend MPX prctl() to pass in size of bounds directory

[Thomas Gleixner]

On Wed, 1 Feb 2017, Dave Hansen wrote:
> FIXME: we also need to ensure that we check the current state of the
> larger address space opt-in.  If we've opted in to larger address spaces
> we can not allow a small bounds directory to be used.  Also, if we've
> not opted in, we can not allow the larger bounds directory to be used.
> This can be fixed once the in-kernel API for opting in/out is settled.

Ok.

>  /* Register/unregister a process' MPX related resource */
> -#define MPX_ENABLE_MANAGEMENT()  mpx_enable_management()
> +#define MPX_ENABLE_MANAGEMENT(bd_size)   mpx_enable_management(bd_size)
>  #define MPX_DISABLE_MANAGEMENT() mpx_disable_management()

Please add another tab before mpx_disable so both are aligned.

> -int mpx_enable_management(void)
> +int mpx_set_mm_bd_size(unsigned long bd_size)

static ?

> +{
> + struct mm_struct *mm = current->mm;
> +
> + switch ((unsigned long long)bd_size) {
> + case 0:
> + /* Legacy call to prctl(): */
> + mm->context.mpx_bd_shift = 0;
> + return 0;
> + case MPX_BD_SIZE_BYTES_32:
> + /* 32-bit, legacy-sized bounds directory: */
> + if (is_64bit_mm(mm))
> + return -EINVAL;
> + mm->context.mpx_bd_shift = 0;
> + return 0;
> + case MPX_BD_BASE_SIZE_BYTES_64:
> + /* 64-bit, legacy-sized bounds directory: */
> + if (!is_64bit_mm(mm)
> + // FIXME && ! opted-in to larger address space

Hmm. Confused. This is where we enable MPX and decode the requested address
space. How can an already opt in happen?

If that's a enable call for an already enabled thing, then we should catch
that at the call site, I think.

> + case MPX_BD_BASE_SIZE_BYTES_64 << MPX_LARGE_BOUNDS_DIR_SHIFT:
> + /*
> +  * Non-legacy call, with larger directory.
> +  * Note that there is no 32-bit equivalent for
> +  * this case since its address space does not
> +  * change sizes.
> +  */
> + if (!is_64bit_mm(mm))
> + return -EINVAL;
> + /*
> +  * Do not let this be enabled unles we are on
> +  * 5-level hardware *and* have that feature
> +  * enabled. FIXME: need runtime check

Runtime check? Isn't the feature bit enough?

Thanks,

tglx

[tip:timers/core] clocksource/drivers/arm_arch_timer:: Mark cyclecounter __ro_after_init

[tip-bot for Bhumika Goyal]

Commit-ID:  3d837bc01c2153565333b2ce71d613b6e7cc761c
Gitweb: http://git.kernel.org/tip/3d837bc01c2153565333b2ce71d613b6e7cc761c
Author: Bhumika Goyal 
AuthorDate: Sun, 12 Feb 2017 00:50:18 +0530
Committer:  Thomas Gleixner 
CommitDate: Sat, 11 Feb 2017 21:39:04 +0100

clocksource/drivers/arm_arch_timer:: Mark cyclecounter __ro_after_init

The object cyclecounter of type cyclecounter is only modified during
initialization in arch_counter_register. So it can be marked
__ro_after_init.

Signed-off-by: Bhumika Goyal 
Cc: mark.rutl...@arm.com
Cc: keesc...@chromium.org
Cc: marc.zyng...@arm.com
Cc: daniel.lezc...@linaro.org
Cc: julia.law...@lip6.fr
Cc: linux-arm-ker...@lists.infradead.org
Link: 
http://lkml.kernel.org/r/1486840818-22214-1-git-send-email-bhumi...@gmail.com
Signed-off-by: Thomas Gleixner 

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

diff --git a/drivers/clocksource/arm_arch_timer.c 
b/drivers/clocksource/arm_arch_timer.c
index 7b06aef..93aa136 100644
--- a/drivers/clocksource/arm_arch_timer.c
+++ b/drivers/clocksource/arm_arch_timer.c
@@ -646,7 +646,7 @@ static struct clocksource clocksource_counter = {
.flags  = CLOCK_SOURCE_IS_CONTINUOUS,
 };
 
-static struct cyclecounter cyclecounter = {
+static struct cyclecounter cyclecounter __ro_after_init = {
.read   = arch_counter_read_cc,
.mask   = CLOCKSOURCE_MASK(56),
 };

drivers/base/power/opp/core.c:241:15: error: redefinition of 'dev_pm_opp_get_max_volt_latency'

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   1ce42845f987e92eabfc6e026d44d826c25c74a5
commit: 655c9df961751ce21466f6e97e8033932c27a675 PM / OPP: Introduce 
dev_pm_opp_get_max_volt_latency()
date:   1 year ago
config: x86_64-randconfig-x008-201707 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 655c9df961751ce21466f6e97e8033932c27a675
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/base/power/opp/core.c:124:15: error: redefinition of 
'dev_pm_opp_get_voltage'
unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *opp)
  ^~
   In file included from drivers/base/power/opp/opp.h:21:0,
from drivers/base/power/opp/core.c:24:
   include/linux/pm_opp.h:67:29: note: previous definition of 
'dev_pm_opp_get_voltage' was here
static inline unsigned long dev_pm_opp_get_voltage(struct dev_pm_opp *opp)
^~
   drivers/base/power/opp/core.c:156:15: error: redefinition of 
'dev_pm_opp_get_freq'
unsigned long dev_pm_opp_get_freq(struct dev_pm_opp *opp)
  ^~~
   In file included from drivers/base/power/opp/opp.h:21:0,
from drivers/base/power/opp/core.c:24:
   include/linux/pm_opp.h:72:29: note: previous definition of 
'dev_pm_opp_get_freq' was here
static inline unsigned long dev_pm_opp_get_freq(struct dev_pm_opp *opp)
^~~
   drivers/base/power/opp/core.c:191:6: error: redefinition of 
'dev_pm_opp_is_turbo'
bool dev_pm_opp_is_turbo(struct dev_pm_opp *opp)
 ^~~
   In file included from drivers/base/power/opp/opp.h:21:0,
from drivers/base/power/opp/core.c:24:
   include/linux/pm_opp.h:77:20: note: previous definition of 
'dev_pm_opp_is_turbo' was here
static inline bool dev_pm_opp_is_turbo(struct dev_pm_opp *opp)
   ^~~
   drivers/base/power/opp/core.c:215:15: error: redefinition of 
'dev_pm_opp_get_max_clock_latency'
unsigned long dev_pm_opp_get_max_clock_latency(struct device *dev)
  ^~~~
   In file included from drivers/base/power/opp/opp.h:21:0,
from drivers/base/power/opp/core.c:24:
   include/linux/pm_opp.h:87:29: note: previous definition of 
'dev_pm_opp_get_max_clock_latency' was here
static inline unsigned long dev_pm_opp_get_max_clock_latency(struct device 
*dev)
^~~~
>> drivers/base/power/opp/core.c:241:15: error: redefinition of 
>> 'dev_pm_opp_get_max_volt_latency'
unsigned long dev_pm_opp_get_max_volt_latency(struct device *dev)
  ^~~
   In file included from drivers/base/power/opp/opp.h:21:0,
from drivers/base/power/opp/core.c:24:
   include/linux/pm_opp.h:92:29: note: previous definition of 
'dev_pm_opp_get_max_volt_latency' was here
static inline unsigned long dev_pm_opp_get_max_volt_latency(struct device 
*dev)
^~~
   drivers/base/power/opp/core.c:305:20: error: redefinition of 
'dev_pm_opp_get_suspend_opp'
struct dev_pm_opp *dev_pm_opp_get_suspend_opp(struct device *dev)
   ^~
   In file included from drivers/base/power/opp/opp.h:21:0,
from drivers/base/power/opp/core.c:24:
   include/linux/pm_opp.h:97:34: note: previous definition of 
'dev_pm_opp_get_suspend_opp' was here
static inline struct dev_pm_opp *dev_pm_opp_get_suspend_opp(struct device 
*dev)
 ^~
   drivers/base/power/opp/core.c:329:5: error: redefinition of 
'dev_pm_opp_get_opp_count'
int dev_pm_opp_get_opp_count(struct device *dev)
^~~~
   In file included from drivers/base/power/opp/opp.h:21:0,
from drivers/base/power/opp/core.c:24:
   include/linux/pm_opp.h:82:19: note: previous definition of 
'dev_pm_opp_get_opp_count' was here
static inline int dev_pm_opp_get_opp_count(struct device *dev)
  ^~~~
   drivers/base/power/opp/core.c:382:20: error: redefinition of 
'dev_pm_opp_find_freq_exact'
struct dev_pm_opp *dev_pm_opp_find_freq_exact(struct device *dev,
   ^~
   In file included from drivers/base/power/opp/opp.h:21:0,
from drivers/base/power/opp/core.c:24:
   include/linux/pm_opp.h:102:34: note: previous definition of 
'dev_pm_opp_find_freq_exact' was here
static inline struct dev_pm_opp *dev_pm_opp_find_freq_exact(struct device 
*dev,
 ^~
   dr

Re: [RFC][PATCH 4/7] x86, mpx: context-switch new MPX address size MSR

[Thomas Gleixner]

On Wed, 1 Feb 2017, Dave Hansen wrote:
> +/*
> + * The MPX tables change sizes based on the size of the virtual
> + * (aka. linear) address space.  There is an MSR to tell the CPU
> + * whether we want the legacy-style ones or the larger ones when
> + * we are running with an eXtended virtual address space.
> + */
> +static inline void switch_mpx_bd(struct mm_struct *prev, struct mm_struct 
> *next)
> +{
> + /*
> +  * Note: there is one and only one bit in use in the MSR
> +  * at this time, so we do not have to be concerned with
> +  * preserving any of the other bits.  Just write 0 or 1.
> +  */
> + u32 IA32_MPX_LAX_ENABLE_MASK = 0x0001;
> +
> + /*
> +  * Avoid the MSR on CPUs without MPX, obviously:
> +  */
> + if (!cpu_feature_enabled(X86_FEATURE_MPX))
> + return;
> + /*
> +  * FIXME: do we want a check here for the 5-level paging
> +  * CR4 bit or CPUID bit, or is the mawa check below OK?
> +  * It's not obvious what would be the fastest or if it
> +  * matters.
> +  */

Well, you could use a static key which is enabled when 5 level paging and
MPX is enabled.

> + /*
> +  * Avoid the relatively costly MSR if we are not changing
> +  * MAWA state.  All processes not using MPX will have a
> +  * mpx_mawa_shift()=0, so we do not need to check
> +  * separately for whether MPX management is enabled.
> +  */
> + if (likely(mpx_bd_size_shift(prev) == mpx_bd_size_shift(next)))
> + return;

So this switches back unconditionally if the previous task was using the
large tables even if the next task is not using MPX at all. It's probably a
non issue.

Thanks,

tglx

drivers/staging/rtl8192u

[Colin Ian King]

Hi,

Static analysis via CoverityScan picked up an issue in
cmpk_handle_query_config_rx where the following operation on an u8 is
clearly not correct:

rx_query_cfg.cfg_action = (pmsg[4] & 0x8000) >> 31;

The result of this operation is always zero. I suspect this should be:

x_query_cfg.cfg_action = (pmsg[4] & 0x80) >> 7;

..but without a datasheet I cannot check if this assumption is correct
or not. Anyhow, it is clearly a bug that needs attention.

Colin