Re: [RFC PATCH net] net/core: don't increment rx_dropped on inactive slaves

2016-01-25 Thread Jarod Wilson
On Mon, Jan 25, 2016 at 09:27:20AM -0500, Jarod Wilson wrote:
> On Sun, Jan 24, 2016 at 10:42:22PM -0800, David Miller wrote:
> > From: Jarod Wilson 
> > Date: Fri, 22 Jan 2016 14:11:22 -0500
> > 
> > > diff --git a/net/core/dev.c b/net/core/dev.c
> > > index 8cba3d8..1354c7b 100644
> > > --- a/net/core/dev.c
> > > +++ b/net/core/dev.c
> > > @@ -4153,8 +4153,11 @@ ncls:
> > >   else
> > >   ret = pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
> > >   } else {
> > > + if (deliver_exact)
> > > + goto inactive; /* bond or team inactive slave */
> > >  drop:
> > >   atomic_long_inc(>dev->rx_dropped);
> > > +inactive:
> > >   kfree_skb(skb);
> > >   /* Jamal, now you will not able to escape explaining
> > >* me how you were going to use this. :-)
> > 
> > I agree that rx_dropped is not the correct stat to bump here, but
> > I'm totally against the event disappearing completely into thin
> > air.
> > 
> > You have to replace the rx_dropped bump with _something_.
> > 
> > The only reason this hasn't been "fixed" yet is that everyone is
> > too damn lazy to implement that "something".
> 
> Would you want to see all things that shouldn't increment rx_dropped come
> in one shot, along with the four or so other counters, as discussed in the
> prior thread, or can they be done piecemeal? To date, I'm really only
> familiar with this particular case, and could probably get something
> together this week. To address the rest, I'd have to poke around a bit
> more and see what there is to see and do.

Spent a while hacking around today, now have this, p7p1 and p5p2 are
the inactive slaves in the bond:

[root@dell-per720-06 ~]# cat /proc/net/dev
Inter-|   Receive   |  
Transmit
 face |bytespackets errs drop drop_i fifo frame compressed multicast|bytes  
  packets errs drop fifo colls carrier compressed
  p6p1:   16024 23800  00 0  0   521
0   0000 0   0  0
  p7p1: 1691386   1653700  165680 0  0   488
0   0000 0   0  0
  p7p2: 1709438   1671800  00 0  0   561
0   0000 0   0  0
 bond0: 6183056   6306500  331510 0  0 13964
24747 193000 0   0  0
  p4p1:   0   000  00 0  0 0
0   0000 0   0  0
  p4p2:   0   000  00 0  0 0
0   0000 0   0  0
lo:4928  5000  00 0  0 0 
4928  50000 0   0  0
  p5p1: 2259498   2340100  00 0  0  6740
24747 193000 0   0  0
  p5p2: 2232172   2312700  165830 0  0  6736
0   0000 0   0  0
   em4: 2347251   1822400  00 0  090 
4541  47000 0   0  0
   em2: 1590296   1606100  00 0  081
0   0000 0   0  0
   em1: 1590180   1606000  00 0  079
0   0000 0   0  0
   em3: 2343156   1820900  00 0  094
0   0000 0   0  0
[root@dell-per720-06 ~]# cat 
/sys/devices/virtual/net/bond0/statistics/rx_dropped_inactive
33181

Haven't yet thrown together anything for ethtool -S output as Eric had
suggested, but I'll dig into that tomorrow.

-- 
Jarod Wilson
ja...@redhat.com



Re: [linux-review:James-Hogan/kbuild-Remove-stale-asm-generic-wrappers/20160119-183642] d979f99e9cc14e2667e9b6e268db695977e4197a BUILD DONE

2016-01-25 Thread Fengguang Wu
Hi Arnd,

Sorry for the delay! I lost access to my email account for some week.

On Tue, Jan 19, 2016 at 03:26:16PM +0100, Arnd Bergmann wrote:
> On Tuesday 19 January 2016 19:27:55 kbuild test robot wrote:
> > arm   allnoconfig
> > arm at91_dt_defconfig
> > arm  at_hdmac
> > armep93xx
> > arm   imx_v6_v7_defconfig
> > arm  iop-adma
> > arm  marzen_defconfig
> > arm  prima2_defconfig
> > armsa1100
> > arm   samsung
> > armsh
> > arm   spear13xx_defconfig
> > 
> 
> Hi Fengguang,
> 
> Sorry for hijacking this thread. I have never seen the list of arm defconfigs
> you are building before, and it seems to be a surprising selection, as a 
> number
> of platforms (ep93xx, iop, sa1100, spear13xx) are rather obscure, but the
> configurations that I tend to use most (multi_v7_defconfig, 
> multi_v5_defconfig,
> allmodconfig) are not included.
> 
> Do you always build the same set of configurations, or is this a different
> each time?

There are a fixed set of config files for fast build tests (which I
selected randomly, feel free to ask me to change the list to more
reasonable ones):

arm-allnoconfig
arm-at91_dt_defconfig
arm-at_hdmac
arm-ep93xx
arm-imx_v6_v7_defconfig
arm-iop-adma
arm-marzen_defconfig
arm-prima2_defconfig
arm-sa1100
arm-samsung
arm-sh
arm-spear13xx_defconfig

The more configs included in arch/*/configs will be tested in a more
slow pace. So not included in this email does not mean they are not
tested -- they are likely not quick enough to catch this notification
email.

> Can you always include the three I mentioned?

Sure.

Thanks,
Fengguang


Re: [RFC PATCH] PPC32: Fix build failure caused by missing dirty pte handlers

2016-01-25 Thread Pranith Kumar
On Mon, Jan 25, 2016 at 10:13 PM, Michael Ellerman  wrote:
> On Mon, 2016-01-25 at 09:22 -0500, Pranith Kumar wrote:
>
>> In 4.5-rc1, I am getting a build failure as follows:
>>
>> mm/memory.c: In function ‘do_swap_page’:
>> mm/memory.c:2573:9: error: implicit declaration of function 
>> ‘pte_mksoft_dirty’
>> [-Werror=implicit-function-declaration]
>>pte = pte_mksoft_dirty(pte);
>>
>> The soft dirty pte handlers are declared only for PPC64 on PPC_BOOK3S in
>> arch/powerpc/include/asm/book3s/64/hash.h and missing in the 32-bit arch.
>>
>> Avoid this error by not setting HAVE_ARCH_SOFT_DIRTY for 32-bit system.
>
> It's building for me, what config are you using?
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/12597204/
>

I am not sure where I messed up, but I am getting the following error now.
Config attached. The same patch fixes this error.

In file included from fs/proc/task_mmu.c:14:0:
include/linux/swapops.h: In function ‘pte_to_swp_entry’:
include/linux/swapops.h:69:6: error: implicit declaration of function
‘pte_swp_soft_dirty’ [-Werror=implicit-function-declaration]
  if (pte_swp_soft_dirty(pte))
  ^
include/linux/swapops.h:70:9: error: implicit declaration of function
‘pte_swp_clear_soft_dirty’ [-Werror=implicit-function-declaration]
   pte = pte_swp_clear_soft_dirty(pte);
 ^
fs/proc/task_mmu.c: In function ‘clear_soft_dirty’:
fs/proc/task_mmu.c:876:11: error: implicit declaration of function
‘pte_clear_soft_dirty’ [-Werror=implicit-function-declaration]
   ptent = pte_clear_soft_dirty(ptent);
   ^
fs/proc/task_mmu.c: In function ‘pte_to_pagemap_entry’:
fs/proc/task_mmu.c:1158:7: error: implicit declaration of function
‘pte_soft_dirty’ [-Werror=implicit-function-declaration]
   if (pte_soft_dirty(pte))
   ^
cc1: some warnings being treated as errors



-- 
Pranith


config-failure
Description: Binary data


Re: [RFC][PATCH 1/3] mm/debug-pagealloc.c: Split out page poisoning from debug page_alloc

2016-01-25 Thread Jianyu Zhan
On Tue, Jan 26, 2016 at 12:55 AM, Laura Abbott
 wrote:
> +static bool __page_poisoning_enabled __read_mostly;
> +static bool want_page_poisoning __read_mostly =
> +   !IS_ENABLED(CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC);
> +


I would say this patch is nice with regard to decoupling
CONFIG_DEBUG_PAGEALLOC and CONFIG_PAGE_POISONING.

But  since when we enable CONFIG_DEBUG_PAGEALLOC,
CONFIG_PAGE_POISONING will be selected.

So it would be better to make page_poison.c totally
CONFIG_DEBUG_PAGEALLOC agnostic,  in case we latter have
more PAGE_POISONING users(currently only DEBUG_PAGEALLOC ). How about like this:

+static bool want_page_poisoning __read_mostly =
+   !IS_ENABLED(CONFIG_PAGE_POISONING );

Or just let it default to 'true',  since we only compile this
page_poison.c when we enable CONFIG_PAGE_POISONING.


Thanks,
Jianyu Zhan


Re: [PATCH v5 1/5] doc: bindings: Add document for mfd hi665x PMIC

2016-01-25 Thread chenfeng


On 2016/1/25 20:53, Lee Jones wrote:
> On Mon, 11 Jan 2016, Chen Feng wrote:
> 
>> Add document for mfd driver hi655x pmic driver
>>
>> Signed-off-by: Chen Feng 
>> Signed-off-by: Fei Wang 
>> Signed-off-by: Xinwei Kong 
>> ---
>>  .../devicetree/bindings/mfd/hisilicon,hi655x.txt   | 28 
>> ++
>>  1 file changed, 28 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
>>
>> diff --git a/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt 
>> b/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
>> new file mode 100644
>> index 000..3180c40
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/mfd/hisilicon,hi655x.txt
>> @@ -0,0 +1,28 @@
>> +Hisilicon hi655x Power Management Integrated Circuit (PMIC)
>> +
>> +The hardware layout for access PMIC Hi655x from AP SoC Hi6220.
>> +Between PMIC Hi655x and Hi6220, the physical signal channel is SSI.
>> +We can use memory-mapped I/O to communicate.
>> +
>> +++ +-+
>> +|| | |
>> +|Hi6220  |   SSI bus   |   Hi655x|
>> +||-| |
>> +||(REGMAP_MMIO)| |
>> +++ +-+
>> +
>> +Required properties:
>> +- compatible: Should be "hisilicon,hi655x-pmic"
>> +- reg: Base address of PMIC on hi6220 soc
> 
> SoC
> 
>> +- interrupt-controller: Hi655x has internal IRQs (has own IRQ domain).
>> +- pmic-gpios: The gpio used by pmic irq.
> 
> PMIC IRQ
> 
>> +
>> +Example:
>> +pmic: pmic@f800 {
>> +compatible = "hisilicon,hi655x-pmic";
>> +reg = <0x0 0xf800 0x0 0x1000>;
>> +#interrupt-cells = <2>;
>> +interrupt-controller;
>> +pmic-gpios = < 2 0>;
> 
> What's the last cell for here?  If they are flags, there is probably a
> #define you can use in dt-include.
ok, I will use the irq flag in dt-include.
> 
>> +status = "disabled";
> 
> What's the point in disabling example code?
It's just copy from the dts, I will drop this.
> 
>> +}
> 



[PATCH 1/2] f2fs: introduce get_next_page_offset to speed up SEEK_DATA

2016-01-25 Thread Chao Yu
When seeking data in ->llseek, if we encounter a big hole which covers
several dnode pages, we will try to seek data from index of page which
is the first page of next dnode page, at most we could skip searching
(ADDRS_PER_BLOCK - 1) pages.

However it's still not efficient, because if our indirect/double-indirect
pointer are NULL, there are no dnode page locate in the tree indirect/
double-indirect pointer point to, it's not necessary to search the whole
region.

This patch introduces get_next_page_offset to calculate next page offset
based on current searching level and max searching level returned from
get_dnode_of_data, with this, we could skip searching the entire area
indirect or double-indirect node block is not exist.

Signed-off-by: Chao Yu 
---
 fs/f2fs/f2fs.h |  3 +++
 fs/f2fs/file.c |  2 +-
 fs/f2fs/node.c | 37 -
 3 files changed, 40 insertions(+), 2 deletions(-)

diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 4bcc512..3e1ba0a 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -552,6 +552,8 @@ struct dnode_of_data {
unsigned int ofs_in_node;   /* data offset in the node page */
bool inode_page_locked; /* inode page is locked or not */
bool node_changed;  /* is node block changed */
+   char cur_level; /* level of hole node page */
+   char max_level; /* level of current page located */
block_t data_blkaddr;   /* block address of the node block */
 };
 
@@ -1783,6 +1785,7 @@ int need_dentry_mark(struct f2fs_sb_info *, nid_t);
 bool is_checkpointed_node(struct f2fs_sb_info *, nid_t);
 bool need_inode_block_update(struct f2fs_sb_info *, nid_t);
 void get_node_info(struct f2fs_sb_info *, nid_t, struct node_info *);
+pgoff_t get_next_page_offset(struct dnode_of_data *, pgoff_t);
 int get_dnode_of_data(struct dnode_of_data *, pgoff_t, int);
 int truncate_inode_blocks(struct inode *, pgoff_t);
 int truncate_xattr_node(struct inode *, struct page *);
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index f2b14e3..2d73f14 100644
--- a/fs/f2fs/file.c
+++ b/fs/f2fs/file.c
@@ -358,7 +358,7 @@ static loff_t f2fs_seek_block(struct file *file, loff_t 
offset, int whence)
} else if (err == -ENOENT) {
/* direct node does not exists */
if (whence == SEEK_DATA) {
-   pgofs = PGOFS_OF_NEXT_DNODE(pgofs, inode);
+   pgofs = get_next_page_offset(, pgofs);
continue;
} else {
goto found;
diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 97a4695..77a35f9 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -403,6 +403,37 @@ cache:
up_write(_i->nat_tree_lock);
 }
 
+pgoff_t get_next_page_offset(struct dnode_of_data *dn, pgoff_t pgofs)
+{
+   const long direct_index = ADDRS_PER_INODE(dn->inode);
+   const long direct_blks = ADDRS_PER_BLOCK;
+   const long indirect_blks = ADDRS_PER_BLOCK * NIDS_PER_BLOCK;
+   unsigned int skipped_unit = ADDRS_PER_BLOCK;
+   int cur_level = dn->cur_level;
+   int max_level = dn->max_level;
+   pgoff_t base = 0;
+
+   if (!dn->max_level)
+   return pgofs + 1;
+
+   while (max_level-- > cur_level)
+   skipped_unit *= NIDS_PER_BLOCK;
+
+   switch (dn->max_level) {
+   case 3:
+   base += 2 * indirect_blks;
+   case 2:
+   base += 2 * direct_blks;
+   case 1:
+   base += direct_index;
+   break;
+   default:
+   f2fs_bug_on(F2FS_I_SB(dn->inode), 1);
+   }
+
+   return ((pgofs - base) / skipped_unit + 1) * skipped_unit + base;
+}
+
 /*
  * The maximum depth is four.
  * Offset[0] will have raw inode offset.
@@ -495,7 +526,7 @@ int get_dnode_of_data(struct dnode_of_data *dn, pgoff_t 
index, int mode)
int offset[4];
unsigned int noffset[4];
nid_t nids[4];
-   int level, i;
+   int level, i = 0;
int err = 0;
 
level = get_node_path(dn->inode, index, offset, noffset);
@@ -585,6 +616,10 @@ release_pages:
 release_out:
dn->inode_page = NULL;
dn->node_page = NULL;
+   if (err == -ENOENT) {
+   dn->cur_level = i;
+   dn->max_level = level;
+   }
return err;
 }
 
-- 
2.7.0.2.g1b0b6dd




[PATCH v4 3/7] mtd: spi-nor: fsl-quadspi: add support for layerscape

2016-01-25 Thread Yuan Yao
LS1043a and LS2080A in the Layerscape family also support Freescale Quad
SPI, make Quad SPI selectable for these hardwares.

Signed-off-by: Yuan Yao 
---
Changed in v4:
No changes.

Changed in v3:
No changes.

Changed in v2:
Update my email to 
---
 drivers/mtd/spi-nor/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index a28c278..6b53deb 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -30,7 +30,7 @@ config MTD_SPI_NOR_USE_4K_SECTORS
 
 config SPI_FSL_QUADSPI
tristate "Freescale Quad SPI controller"
-   depends on ARCH_MXC || SOC_LS1021A || COMPILE_TEST
+   depends on ARCH_MXC || SOC_LS1021A || ARCH_LAYERSCAPE || COMPILE_TEST
depends on HAS_IOMEM
help
  This enables support for the Quad SPI controller in master mode.
-- 
2.1.0.27.g96db324



Re: mm: WARNING in __delete_from_page_cache

2016-01-25 Thread Williams, Dan J
On Mon, 2016-01-25 at 13:22 +0100, Jan Kara wrote:
[..]
> Thanks. Despite the huge list of recipients the author of the changes
> hasn't been CCed :) I've added Dan to CC since he wrote DAX support
> for
> block devices. It seems somehow the write didn't go through the DAX
> path
> but through the standard page cache write path. Ah, I see, only
> file->f_mapping->host has S_DAX set but io_is_direct() which decides
> whether DAX or pagecache path should be used for writes uses file-
> >f_inode
> which is something different for block devices... 

Thanks, yes, the following silences the warning for me:

8<- (git am --scissors)
Subject: fs, block: force direct-I/O for dax-enabled block devices

From: Dan Williams 

Similar to the file I/O path, re-direct all I/O to the DAX path for I/O
to a block-device special file.

Otherwise, we confuse the DAX code that does not expect to find live
data in the page cache:

[ cut here ]
WARNING: CPU: 0 PID: 7676 at mm/filemap.c:217
__delete_from_page_cache+0x9f6/0xb60()
Modules linked in:
CPU: 0 PID: 7676 Comm: a.out Not tainted 4.4.0+ #276
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
  88006d3f7738 82999e2d 
 8800620a 86473d20 88006d3f7778 81352089
 81658d36 86473d20 00d9 ea009d60
Call Trace:
 [< inline >] __dump_stack lib/dump_stack.c:15
 [] dump_stack+0x6f/0xa2 lib/dump_stack.c:50
 [] warn_slowpath_common+0xd9/0x140 kernel/panic.c:482
 [] warn_slowpath_null+0x29/0x30 kernel/panic.c:515
 [] __delete_from_page_cache+0x9f6/0xb60 mm/filemap.c:217
 [] delete_from_page_cache+0x112/0x200 mm/filemap.c:244
 [] __dax_fault+0x859/0x1800 fs/dax.c:487
 [] blkdev_dax_fault+0x26/0x30 fs/block_dev.c:1730
 [< inline >] wp_pfn_shared mm/memory.c:2208
 [] do_wp_page+0xc85/0x14f0 mm/memory.c:2307
 [< inline >] handle_pte_fault mm/memory.c:3323
 [< inline >] __handle_mm_fault mm/memory.c:3417
 [] handle_mm_fault+0x2483/0x4640 mm/memory.c:3446
 [] __do_page_fault+0x376/0x960 arch/x86/mm/fault.c:1238
 [] trace_do_page_fault+0xe8/0x420 
arch/x86/mm/fault.c:1331
 [] do_async_page_fault+0x14/0xd0 
arch/x86/kernel/kvm.c:264
 [] async_page_fault+0x28/0x30 
arch/x86/entry/entry_64.S:986
 [] entry_SYSCALL_64_fastpath+0x16/0x7a
arch/x86/entry/entry_64.S:185
---[ end trace dae21e0f85f1f98c ]---

Cc: Matthew Wilcox 
Cc: Ross Zwisler 
Fixes: 5a023cdba50c ("block: enable dax for raw block devices")
Reported-by: Dmitry Vyukov 
Reported-by: Kirill A. Shutemov 
Suggested-by: Jan Kara 
Signed-off-by: Dan Williams 
---
 fs/block_dev.c |5 -
 include/linux/fs.h |   12 +++-
 2 files changed, 11 insertions(+), 6 deletions(-)

diff --git a/fs/block_dev.c b/fs/block_dev.c
index 7b9cd49622b1..277008617b2d 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -156,11 +156,6 @@ blkdev_get_block(struct inode *inode, sector_t iblock,
    return 0;
 }
 
-static struct inode *bdev_file_inode(struct file *file)
-{
-   return file->f_mapping->host;
-}
-
 static ssize_t
 blkdev_direct_IO(struct kiocb *iocb, struct iov_iter *iter, loff_t offset)
 {
diff --git a/include/linux/fs.h b/include/linux/fs.h
index 1a2046275cdf..a4c4314eed48 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1237,6 +1237,11 @@ static inline struct inode *file_inode(const struct file 
*f)
    return f->f_inode;
 }
 
+static inline struct inode *bdev_file_inode(struct file *file)
+{
+   return file->f_mapping->host;
+}
+
 static inline int locks_lock_file_wait(struct file *filp, struct file_lock *fl)
 {
    return locks_lock_inode_wait(file_inode(filp), fl);
@@ -2907,7 +2912,12 @@ extern void replace_mount_options(struct super_block 
*sb, char *options);
 
 static inline bool io_is_direct(struct file *filp)
 {
-   return (filp->f_flags & O_DIRECT) || IS_DAX(file_inode(filp));
+   struct inode *inode = file_inode(filp);
+
+   if (S_ISBLK(inode->i_mode))
+   inode = bdev_file_inode(filp);
+
+   return (filp->f_flags & O_DIRECT) || IS_DAX(inode);
 }
 
 static inline int iocb_flags(struct file *file)


[PATCH v6 00/12] usb: early: add support for early printk through USB3 debug port

2016-01-25 Thread Lu Baolu
Hi,

This patch series adds support for early printk through USB3 debug port.
USB3 debug port is described in xHCI specification as an optional extended
capability.

The first patch adds a file in sysfs, through which users can check
whether the debug capability is supported by a specific host controller,
and the hardware state.

Patch 2 to 10 add the driver for xHCI debug capability. It interfaces with
the register set and provides the required ops (read/write/control) to upper
layers. Early printk is one consumer of these ops. The hooks for early printk
are introduced in patch 9. This design is similar to what we have done in
drivers/usb/early/ehci-dbgp.c.

Patch 11 is a minor change to usb_debug module. This change is required to
bind usb_debug with the USB3 debug device.

Patch 12 is the design document and user guide.

Change log:
v1->v2:
(1) Patch 1 re-implemented. "debugfs" has been replaced with sysfs.
The scope reduced from all extended capabilities to debug port
specific.
(2) Patch 11 changed. Removed unnecessary .bulk_out_size setting.

v2->v3:
(1) Patch 11 got acked by Johan Hovold.

v3->v4:
(1) Patch 1 code refactored by using xhci_find_ext_cap_by_id() helper.
(2) Patch 3 "bus hung state" changed to "port hung state" in commit message.
(3) Patch 12 added verified platform information.

v4->v5:
(1) Patch 1 & 3 code refactored by using xhci_find_next_ext_cap() helper.
(2) Patch 12 updated with more user guide information.
(3) All patches rebased to the new usb-next branch which contains commit
d5ddcdf(xhci: rework xhci extended capability list parsing functions).

v5->v6:
(1) refresh the patches against 4.5-rc1.
(2) change "usb: xhci: dbc" to "usb: dbc" in the patch titles as they
are not part of xhci driver.

Lu Baolu (12):
  usb: xhci: add sysfs file for xHCI debug port
  x86: fixmap: add permanent fixmap for xhci debug port
  usb: dbc: probe and setup xhci debug capability
  usb: dbc: add support for Intel xHCI dbc quirk
  usb: dbc: add debug buffer
  usb: dbc: add bulk out and bulk in interfaces
  usb: dbc: handle dbc-configured exit
  usb: dbc: handle endpoint stall
  x86: early_printk: add USB3 debug port earlyprintk support
  usb: dbc: add handshake between debug target and host
  usb: serial: usb_debug: add support for dbc debug device
  usb: doc: add document for xHCI DbC driver

 .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd |   23 +
 Documentation/kernel-parameters.txt|1 +
 Documentation/usb/xhci-dbc.txt |  350 +
 MAINTAINERS|8 +
 arch/x86/Kconfig.debug |   12 +
 arch/x86/include/asm/fixmap.h  |4 +
 arch/x86/kernel/early_printk.c |5 +
 drivers/usb/early/Makefile |1 +
 drivers/usb/early/xhci-dbc.c   | 1394 
 drivers/usb/host/Makefile  |2 +-
 drivers/usb/host/xhci-ext-caps.h   |5 +
 drivers/usb/host/xhci-sysfs.c  |   65 +
 drivers/usb/host/xhci.c|4 +
 drivers/usb/host/xhci.h|4 +
 drivers/usb/serial/usb_debug.c |   28 +-
 include/linux/usb/xhci-dbc.h   |  224 
 16 files changed, 2126 insertions(+), 4 deletions(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
 create mode 100644 Documentation/usb/xhci-dbc.txt
 create mode 100644 drivers/usb/early/xhci-dbc.c
 create mode 100644 drivers/usb/host/xhci-sysfs.c
 create mode 100644 include/linux/usb/xhci-dbc.h

-- 
2.1.4



[PATCH v6 02/12] x86: fixmap: add permanent fixmap for xhci debug port

2016-01-25 Thread Lu Baolu
xHCI compatible USB3 host controller may provide debug capability
which enables low-level system debug over USB. In order to probing
this debug capability, Linux kernel needs to map and access the
mmio of the host controller during early boot.

This patch adds permenent fixmap pages in fixed_addresses table for
xHCI mmio access.

Signed-off-by: Lu Baolu 
---
 arch/x86/include/asm/fixmap.h | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/x86/include/asm/fixmap.h b/arch/x86/include/asm/fixmap.h
index 6d7d0e5..84298cb 100644
--- a/arch/x86/include/asm/fixmap.h
+++ b/arch/x86/include/asm/fixmap.h
@@ -77,6 +77,10 @@ enum fixed_addresses {
 #ifdef CONFIG_PROVIDE_OHCI1394_DMA_INIT
FIX_OHCI1394_BASE,
 #endif
+#ifdef CONFIG_EARLY_PRINTK_XDBC
+   FIX_XDBC_BASE,
+   FIX_XDBC_END = FIX_XDBC_BASE + 15,
+#endif
 #ifdef CONFIG_X86_LOCAL_APIC
FIX_APIC_BASE,  /* local (CPU) APIC) -- required for SMP or not */
 #endif
-- 
2.1.4



[PATCH v6 03/12] usb: dbc: probe and setup xhci debug capability

2016-01-25 Thread Lu Baolu
xHCI debug capability (DbC) is an optional functionality provided
by an xHCI host controller. Software learns this capability by
walking through the extended capability list in mmio of the host.

This patch introduces the code to probe and initialize the debug
capability hardware during early boot. With hardware initialization
done, the debug target (system under debug which has DbC enabled)
will present a debug device through the debug port. The debug device
is fully compliant with the USB framework and provides the equivalent
of a very high performance (USB3) full-duplex serial link between the
debug host and target.

Signed-off-by: Lu Baolu 
---
 MAINTAINERS  |   7 +
 arch/x86/Kconfig.debug   |  12 +
 drivers/usb/early/Makefile   |   1 +
 drivers/usb/early/xhci-dbc.c | 774 +++
 include/linux/usb/xhci-dbc.h | 187 +++
 5 files changed, 981 insertions(+)
 create mode 100644 drivers/usb/early/xhci-dbc.c
 create mode 100644 include/linux/usb/xhci-dbc.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 30aca4a..e6d7076 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -11505,6 +11505,13 @@ S: Supported
 F: drivers/usb/host/xhci*
 F: drivers/usb/host/pci-quirks*
 
+USB XHCI DEBUG PORT
+M: Lu Baolu 
+L: linux-...@vger.kernel.org
+S: Supported
+F: drivers/usb/early/xhci-dbc.c
+F: include/linux/usb/xhci-dbc.h
+
 USB ZD1201 DRIVER
 L: linux-wirel...@vger.kernel.org
 W: http://linux-lc100020.sourceforge.net
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 9b18ed9..ba60cb1 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -48,6 +48,18 @@ config EARLY_PRINTK_EFI
  This is useful for kernel debugging when your machine crashes very
  early before the console code is initialized.
 
+config EARLY_PRINTK_XDBC
+   bool "Early printk via xHCI debug port"
+   depends on EARLY_PRINTK && PCI
+   ---help---
+ Write kernel log output directly into the xHCI debug port.
+
+ This is useful for kernel debugging when your machine crashes very
+ early before the console code is initialized. For normal operation
+ it is not recommended because it looks ugly and doesn't cooperate
+ with klogd/syslogd or the X server. You should normally N here,
+ unless you want to debug such a crash.
+
 config X86_PTDUMP_CORE
def_bool n
 
diff --git a/drivers/usb/early/Makefile b/drivers/usb/early/Makefile
index 24bbe51..2db5906 100644
--- a/drivers/usb/early/Makefile
+++ b/drivers/usb/early/Makefile
@@ -3,3 +3,4 @@
 #
 
 obj-$(CONFIG_EARLY_PRINTK_DBGP) += ehci-dbgp.o
+obj-$(CONFIG_EARLY_PRINTK_XDBC) += xhci-dbc.o
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
new file mode 100644
index 000..254a0a8
--- /dev/null
+++ b/drivers/usb/early/xhci-dbc.c
@@ -0,0 +1,774 @@
+/**
+ * xhci-dbc.c - xHCI debug capability driver
+ *
+ * Copyright (C) 2015 Intel Corporation
+ *
+ * Author: Lu Baolu 
+ * Some code shared with EHCI debug port and xHCI driver.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../host/xhci.h"
+
+#defineXDBC_PROTOCOL   1   /* GNU Remote Debug Command Set 
*/
+#defineXDBC_VENDOR_ID  0x1d6b  /* Linux Foundation 0x1d6b */
+#defineXDBC_PRODUCT_ID 0x0004  /* __le16 idProduct; device 
0004 */
+#defineXDBC_DEVICE_REV 0x0010  /* 0.10 */
+
+static struct xdbc_state xdbc_stat;
+static struct xdbc_state *xdbcp = _stat;
+
+#ifdef DBC_DEBUG
+/* place holder */
+#definexdbc_trace  printk
+static void xdbc_dbg_dump_regs(char *str)
+{
+   if (!xdbcp->xdbc_reg) {
+   xdbc_trace("register not mapped\n");
+   return;
+   }
+
+   xdbc_trace("XDBC registers: %s\n", str);
+   xdbc_trace("  Capability: %08x\n",
+   readl(>xdbc_reg->capability));
+   xdbc_trace("  Door bell: %08x\n",
+   readl(>xdbc_reg->doorbell));
+   xdbc_trace("  Event Ring Segment Table Size: %08x\n",
+   readl(>xdbc_reg->ersts));
+   xdbc_trace("  Event Ring Segment Table Base Address: %16llx\n",
+   xdbc_read64(>xdbc_reg->erstba));
+   xdbc_trace("  Event Ring Dequeue Pointer: %16llx\n",
+   xdbc_read64(>xdbc_reg->erdp));
+   xdbc_trace("  Port status and control: %08x\n",
+   readl(>xdbc_reg->portsc));
+   xdbc_trace("  Debug Capability Context Pointer: %16llx\n",
+   xdbc_read64(>xdbc_reg->dccp));
+   xdbc_trace("  

[linux-review:Jason-Baron/convert-dynamic_debug-to-use-jump-labels/20160126-055359] 30e241d11bfa30ea56c42028ef9776135d422b57 BUILD DONE

2016-01-25 Thread kbuild test robot
https://github.com/0day-ci/linux  
Jason-Baron/convert-dynamic_debug-to-use-jump-labels/20160126-055359
30e241d11bfa30ea56c42028ef9776135d422b57  dynamic_debug: add jump label support

arch/powerpc/include/asm/bug.h:101:4: error: implicit declaration of function 
'__WARN' [-Werror=implicit-function-declaration]
arch/powerpc/include/asm/bug.h:107:24: error: 'TAINT_WARN' undeclared (first 
use in this function)
arch/powerpc/include/asm/bug.h:108:17: error: invalid application of 'sizeof' 
to incomplete type 'struct bug_entry'
arch/powerpc/include/asm/thread_info.h:151:2: error: implicit declaration of 
function 'WARN_ON' [-Werror=implicit-function-declaration]
arch/powerpc/include/asm/thread_info.h:151:2: note: in expansion of macro 
'WARN_ON'
arch/x86/include/asm/paravirt.h:25:2: note: in expansion of macro 'PVOP_VCALL2'
arch/x86/include/asm/paravirt_types.h:542:28: error: implicit declaration of 
function 'BUG_ON' [-Werror=implicit-function-declaration]
arch/x86/include/asm/paravirt_types.h:592:3: note: in expansion of macro 
'PVOP_TEST_NULL'
arch/x86/include/asm/paravirt_types.h:604:2: note: in expansion of macro 
'PVOP_VCALL'
arch/x86/include/asm/paravirt_types.h:641:2: note: in expansion of macro 
'__PVOP_VCALL'
include/linux/bitmap.h:186:22: note: in expansion of macro 'BITS_TO_LONGS'
include/linux/bitmap.h:186:3: error: implicit declaration of function 
'DIV_ROUND_UP' [-Werror=implicit-function-declaration]
include/linux/bitops.h:13:27: error: implicit declaration of function 
'DIV_ROUND_UP' [-Werror=implicit-function-declaration]
include/linux/cpumask.h:117:2: error: implicit declaration of function 
'WARN_ON_ONCE' [-Werror=implicit-function-declaration]
include/linux/cpumask.h:15:41: error: variably modified 'bits' at file scope
include/linux/cpumask.h:708:29: error: variably modified 'cpu_all_bits' at file 
scope
include/linux/cpumask.h:712:29: error: variably modified 'cpu_all_bits' at file 
scope
include/linux/cpumask.h:754:2: error: variably modified 'cpu_bit_bitmap' at 
file scope
include/linux/cpumask.h:793:2: error: variably modified 'cpu_bit_bitmap' at 
file scope
include/linux/dynamic_debug.h:100:2: note: in expansion of macro 
'static_branch_unlikely'
include/linux/dynamic_debug.h:119:6: note: in expansion of macro 'DDEBUG_BRANCH'
include/linux/jump_label_branch.h:183:59: warning: format '%llx' expects 
argument of type 'long long unsigned int', but argument 8 has type 'dma_addr_t' 
[-Wformat=]
include/linux/jump_label_branch.h:51:2: error: implicit declaration of function 
'atomic_read' [-Werror=implicit-function-declaration]
include/linux/jump_label_branch.h:51:9: error: implicit declaration of function 
'atomic_read' [-Werror=implicit-function-declaration]
include/linux/thread_info.h:128:2: error: implicit declaration of function 
'WARN_ON' [-Werror=implicit-function-declaration]
include/linux/thread_info.h:129:2: error: implicit declaration of function 
'WARN_ON' [-Werror=implicit-function-declaration]

Error ids grouped by kconfigs:

recent_errors
├── i386-randconfig-s0-201604
│   ├── arch-x86-include-asm-paravirt.h:note:in-expansion-of-macro-PVOP_VCALL2
│   ├── 
arch-x86-include-asm-paravirt_types.h:error:implicit-declaration-of-function-BUG_ON
│   ├── 
arch-x86-include-asm-paravirt_types.h:note:in-expansion-of-macro-PVOP_TEST_NULL
│   ├── 
arch-x86-include-asm-paravirt_types.h:note:in-expansion-of-macro-PVOP_VCALL
│   ├── 
arch-x86-include-asm-paravirt_types.h:note:in-expansion-of-macro-__PVOP_VCALL
│   ├── include-linux-bitmap.h:note:in-expansion-of-macro-BITS_TO_LONGS
│   ├── 
include-linux-bitops.h:error:implicit-declaration-of-function-DIV_ROUND_UP
│   ├── include-linux-cpumask.h:error:variably-modified-bits-at-file-scope
│   ├── 
include-linux-cpumask.h:error:variably-modified-cpu_all_bits-at-file-scope
│   └── 
include-linux-cpumask.h:error:variably-modified-cpu_bit_bitmap-at-file-scope
├── i386-randconfig-s1-201604
│   ├── include-linux-bitmap.h:note:in-expansion-of-macro-BITS_TO_LONGS
│   ├── 
include-linux-bitops.h:error:implicit-declaration-of-function-DIV_ROUND_UP
│   ├── include-linux-cpumask.h:error:variably-modified-bits-at-file-scope
│   ├── 
include-linux-cpumask.h:error:variably-modified-cpu_all_bits-at-file-scope
│   └── 
include-linux-cpumask.h:error:variably-modified-cpu_bit_bitmap-at-file-scope
├── i386-randconfig-x003-01251232
│   ├── arch-x86-include-asm-paravirt.h:note:in-expansion-of-macro-PVOP_VCALL2
│   ├── 
arch-x86-include-asm-paravirt_types.h:error:implicit-declaration-of-function-BUG_ON
│   ├── 
arch-x86-include-asm-paravirt_types.h:note:in-expansion-of-macro-PVOP_TEST_NULL
│   ├── 
arch-x86-include-asm-paravirt_types.h:note:in-expansion-of-macro-PVOP_VCALL
│   └── 
arch-x86-include-asm-paravirt_types.h:note:in-expansion-of-macro-__PVOP_VCALL
├── i386-tinyconfig
│   ├── include-linux-bitmap.h:note:in-expansion-of-macro-BITS_TO_LONGS
│   ├── 
include-linux-bitops.h:error:implicit-declaration-of-function-DIV_ROUND_UP
│   ├── 

Re: wireless-drivers: random cleanup patches piling up

2016-01-25 Thread Sudip Mukherjee
On Fri, Jan 22, 2016 at 05:54:12PM +0200, Kalle Valo wrote:
> "John W. Linville"  writes:
> 
> > On Fri, Jan 22, 2016 at 02:21:20PM +0200, Kalle Valo wrote:
> >> Joe Perches  writes:
> >> 
> >> > On Thu, 2016-01-21 at 16:58 +0200, Kalle Valo wrote:
> >> >> Hi,
> >> >> 
> >> >> I have quite a lot of random cleanup patches from new developers waiting
> >> >> in my queue:
> >> >> 
> >> >> https://patchwork.kernel.org/project/linux-wireless/list/?state=10=25621=date
> >> >> 
> >> >> (Not all of them are cleanup patches, there are also few patches
> >> >> deferred due to other reasons, but you get the idea.)
> >> >> 
> >> >> These cleanup patches usually take quite a lot of my time and I'm
> >> >> starting to doubt the benefit, compared to the time needed to dig
> >> >> through them and figuring out what to apply. And this is of course time
> >> >> away from other patches, so it's slowing down "real" development.
> >> >> 
> >> >> I really don't know what to do. Part of me is saying that I just should
> >> >> drop them unless it's reviewed by a more experienced developer but on
> >> >> the other hand this is a good way get new developers onboard.
> >> >> 
> >> >> What others think? Are these kind of patches useful?
> >> >
> >> > Some yes, mostly not really.
> >> >
> >> > While whitespace style patches have some small value,
> >> > very few of the new contributors that use tools like
> >> > "scripts/checkpatch.pl -f" on various kernel files 
> >> > actually continue on to submit actual defect fixing
> >> > or optimization or code clarity patches.
> >> 
> >> That's also my experience from maintaining wireless-drivers for a year,
> >> this seems to be a "hit and run" type of phenomenon.
> >
> > Should we be looking for someone to run a "wireless-driver-cleanups"
> > tree?  They could handle the cleanups and trivial stuff, and send
> > you a pull request a couple of times per release...?
> 
> Not a bad idea! But I don't think we need a separate tree as applying
> patches from patchwork is easy. It should be doable that we add an
> account to patchwork and whenever I see a this type of trivial cleanup
> patch I'll assign it to the cleanup maintainer and whenever he/she
> thinks it's ready he assigns the patch back to me and I'll apply it.
> 
> The only difficult part is finding a victim/volunteer to
> do that ;)

I can be a volunteer (victim?). Though i donot know much about
wireless-drivers, but I do know a little about cleanup patches.
And maybe, in the process I will start knowing wireless-drivers.

regards
sudip


Linux 3.18.26

2016-01-25 Thread Sasha Levin
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm announcing the release of the 3.18.26 kernel.

All users of the 3.18 kernel series must upgrade.

The updated 3.18.y git tree can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-3.18.y
and can be browsed at the normal kernel.org git web browser:

http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary


- 
Linux 3.18.26

- 
Alan Stern (1):
  USB: add quirk for devices with broken LPM

Alexey Khoroshilov (1):
  USB: whci-hcd: add check for dma mapping error

Arnd Bergmann (2):
  ceph: fix message length computation
  usb: musb: USB_TI_CPPI41_DMA requires dmaengine support

Ben Hutchings (1):
  usb: Use the USB_SS_MULT() macro to decode burst multiplier for log 
message

Benjamin Coddington (1):
  nfs4: start callback_ident at idr 1

Daeho Jeong (1):
  ext4, jbd2: ensure entering into panic after recording an error in 
superblock

David Howells (1):
  KEYS: Fix race between read and revoke

David S. Miller (1):
  bluetooth: Validate socket address length in sco_sock_bind().

Emmanuel Grumbach (2):
  iwlwifi: 7000: fix reported firmware name for 7265D
  iwlwifi: bump firmware API for mvm devices to 12

Eric Dumazet (2):
  ipv6: sctp: clone options to avoid use after free
  net: fix IP early demux races

Felipe Balbi (1):
  usb: gadget: pxa27x: fix suspend callback

Filipe Manana (4):
  Btrfs: fix file corruption and data loss after cloning inline extents
  Btrfs: fix race leading to incorrect item deletion when dropping extents
  Btrfs: fix race leading to BUG_ON when running delalloc for nodatacow
  Btrfs: fix race when listing an inode's xattrs

Hannes Frederic Sowa (2):
  net: add validation for the socket syscall protocol argument
  fou: clean up socket with kfree_rcu

Hans Yang (1):
  usb: core : hub: Fix BOS 'NULL pointer' kernel panic

Ilya Dryomov (2):
  rbd: don't put snap_context twice in rbd_queue_workfn()
  rbd: don't leak parent_spec in rbd_dev_probe_parent()

Jeff Layton (2):
  nfsd: serialize state seqid morphing operations
  nfs: if we have no valid attrs, then don't declare the attribute cache 
valid

Jonas Jonsson (2):
  USB: cdc_acm: Ignore Infineon Flash Loader utility
  USB: serial: Another Infineon flash loader USB ID

Junxiao Bi (1):
  ocfs2: fix umask ignored issue

Konstantin Shkolnyy (1):
  USB: cp210x: Remove CP2110 ID from compatibility list

Lu, Han (1):
  ALSA: hda/hdmi - apply Skylake fix-ups to Broxton display codec

Marcelo Ricardo Leitner (3):
  sctp: use the same clock as if sock source timestamps were on
  sctp: update the netstamp_needed counter when copying sockets
  sctp: also copy sk_tsflags when copying the socket

Nicolas Dichtel (1):
  gre6: allow to update all parameters via rtnl

Pavel Machek (1):
  atl1c: Improve driver not to do order 4 GFP_ATOMIC allocation

Quentin Casasnovas (1):
  RDS: fix race condition when sending a message on unbound socket

Rainer Weikusat (2):
  af_unix: Revert 'lock_interruptible' in stream receive code
  unix: avoid use-after-free in ep_remove_wait_queue

Sasha Levin (3):
  RDS: verify the underlying transport exists before creating a connection
  Revert "workqueue: make sure delayed work run in local cpu"
  Linux 3.18.26

Sergei Shtylyov (1):
  sh_eth: fix kernel oops in skb_put()

Stefan Richter (1):
  firewire: ohci: fix JMicron JMB38x IT context discovery

Stefan Wahren (1):
  net: qca_spi: fix transmit queue timeout handling

Vlad Yasevich (2):
  vlan: Fix untag operations of stacked vlans with REORDER_HEADER off
  skbuff: Fix offset error in skb_reorder_vlan_header

WANG Cong (2):
  pptp: verify sockaddr_len in pptp_bind() and pptp_connect()
  net: check both type and procotol for tcp sockets

Yevgeny Pats (1):
  KEYS: Fix keyring ref leak in join_session_keyring()

 Makefile|   2 +-
 drivers/block/rbd.c |  36 ++---
 drivers/firewire/ohci.c |   5 +
 drivers/net/ethernet/atheros/atl1c/atl1c_main.c |   7 +-
 drivers/net/ethernet/qualcomm/qca_spi.c |   5 +-
 drivers/net/ethernet/renesas/sh_eth.c   |   4 +-
 drivers/net/ppp/pptp.c  |   6 +
 drivers/net/wireless/iwlwifi/iwl-7000.c |   6 +-
 drivers/net/wireless/iwlwifi/iwl-8000.c |   2 +-
 drivers/usb/class/cdc-acm.c |   5 +
 drivers/usb/core/config.c   |   3 +-
 drivers/usb/core/hub.c  |  22 ++-
 drivers/usb/core/quirks.c   |   6 +
 drivers/usb/gadget/udc/pxa27x_udc.c |   3 +
 

[PATCH] usb: dwc2: host: fix the data toggle error in full speed descriptor dma

2016-01-25 Thread Jianqiang Tang
From: "Tang, Jianqiang" 

There will be data toggle error happen for full speed buld-out transfer.
The data toggle bit is saved in qh for non-control transfers, it is wrong
to  check the qtd for that case.

Also fix one static analysis tool issue after fix the data toggle error.

Signed-off-by: Dyson Lee 
Signed-off-by: Tang, Jianqiang 
---
 drivers/usb/dwc2/hcd_ddma.c | 2 +-
 drivers/usb/dwc2/hcd_intr.c | 4 
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/usb/dwc2/hcd_ddma.c b/drivers/usb/dwc2/hcd_ddma.c
index 36606fc..6b18956 100644
--- a/drivers/usb/dwc2/hcd_ddma.c
+++ b/drivers/usb/dwc2/hcd_ddma.c
@@ -1258,7 +1258,7 @@ static void dwc2_complete_non_isoc_xfer_ddma(struct 
dwc2_hsotg *hsotg,
 */
if (halt_status == DWC2_HC_XFER_STALL)
qh->data_toggle = DWC2_HC_PID_DATA0;
-   else if (qtd)
+   else
dwc2_hcd_save_data_toggle(hsotg, chan, chnum, qtd);
}
 
diff --git a/drivers/usb/dwc2/hcd_intr.c b/drivers/usb/dwc2/hcd_intr.c
index f825380..918773f 100644
--- a/drivers/usb/dwc2/hcd_intr.c
+++ b/drivers/usb/dwc2/hcd_intr.c
@@ -530,6 +530,10 @@ void dwc2_hcd_save_data_toggle(struct dwc2_hsotg *hsotg,
else
chan->qh->data_toggle = DWC2_HC_PID_DATA1;
} else {
+   if (!qtd) {
+   dev_err(hsotg->dev, "qtd is null, return\n");
+   return;
+   }
if (pid == TSIZ_SC_MC_PID_DATA0)
qtd->data_toggle = DWC2_HC_PID_DATA0;
else
-- 
1.9.1



Re: [PATCH] drm/exynos: fix building without CONFIG_PM_SLEEP

2016-01-25 Thread Inki Dae
Hi Arnd,

Sorry for late.

2015년 11월 18일 00:08에 Arnd Bergmann 이(가) 쓴 글:
> The runtime PM operations use the suspend/resume functions
> even when CONFIG_PM_SLEEP is not set, but this now fails
> for the exynos DRM driver:
> 
> exynos_mixer.c:1289:61: error: 'exynos_mixer_resume' undeclared here (not in 
> a function)
>   SET_RUNTIME_PM_OPS(exynos_mixer_suspend, exynos_mixer_resume, NULL)
> 
> This removes the #ifdef and instead marks the functions as
> __maybe_unused, which does the right thing in all cases and
> also looks nicer.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: ("drm/exynos: add pm_runtime to Mixer")
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
> b/drivers/gpu/drm/exynos/exynos_mixer.c
> index 7498c6e76a53..fcaf71df77c1 100644
> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
> @@ -1230,8 +1230,7 @@ static int mixer_remove(struct platform_device *pdev)
>   return 0;
>  }
>  
> -#ifdef CONFIG_PM_SLEEP

How about just changing it to CONFIG_PM for consistency of other kms drivers?
Actually, I had modified it to PM since original auther, Gustavo Padovan, 
posted runtime pm support.
However, it seems missing this one.

Thanks,
Inki Dae

> -static int exynos_mixer_suspend(struct device *dev)
> +static int __maybe_unused exynos_mixer_suspend(struct device *dev)
>  {
>   struct mixer_context *ctx = dev_get_drvdata(dev);
>   struct mixer_resources *res = >mixer_res;
> @@ -1247,7 +1246,7 @@ static int exynos_mixer_suspend(struct device *dev)
>   return 0;
>  }
>  
> -static int exynos_mixer_resume(struct device *dev)
> +static int __maybe_unused exynos_mixer_resume(struct device *dev)
>  {
>   struct mixer_context *ctx = dev_get_drvdata(dev);
>   struct mixer_resources *res = >mixer_res;
> @@ -1283,7 +1282,6 @@ static int exynos_mixer_resume(struct device *dev)
>  
>   return 0;
>  }
> -#endif
>  
>  static const struct dev_pm_ops exynos_mixer_pm_ops = {
>   SET_RUNTIME_PM_OPS(exynos_mixer_suspend, exynos_mixer_resume, NULL)
> 
> 


Re: [RFC][PATCH 2/3] mm/page_poison.c: Enable PAGE_POISONING as a separate option

2016-01-25 Thread Jianyu Zhan
On Tue, Jan 26, 2016 at 12:55 AM, Laura Abbott
 wrote:
> --- a/mm/debug-pagealloc.c
> +++ b/mm/debug-pagealloc.c
> @@ -8,11 +8,5 @@
>
>  void __kernel_map_pages(struct page *page, int numpages, int enable)
>  {
> -   if (!page_poisoning_enabled())
> -   return;
> -
> -   if (enable)
> -   unpoison_pages(page, numpages);
> -   else
> -   poison_pages(page, numpages);
> +   kernel_poison_pages(page, numpages, enable);
>  }
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 63358d9..c733421 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -1002,6 +1002,7 @@ static bool free_pages_prepare(struct page *page, 
> unsigned int order)
>PAGE_SIZE << order);
> }
> arch_free_page(page, order);
> +   kernel_poison_pages(page, 1 << order, 0);
> kernel_map_pages(page, 1 << order, 0);
>
> return true;
> @@ -1396,6 +1397,7 @@ static int prep_new_page(struct page *page, unsigned 
> int order, gfp_t gfp_flags,
> set_page_refcounted(page);
>
> arch_alloc_page(page, order);
> +   kernel_poison_pages(page, 1 << order, 1);
> kernel_map_pages(page, 1 << order, 1);
> kasan_alloc_pages(page, order);
>

kernel_map_pages() will fall back to page poisoning scheme for
!ARCH_SUPPORTS_DEBUG_PAGEALLOC.

IIUC,  calling kernel_poison_pages() before kernel_map_pages() will be
equivalent to call kernel_poison_pages()
twice?!




Thanks,
Jianyu Zhan


RE: [f2fs-dev] [PATCH 1/2] f2fs: avoid multiple node page writes due to inline_data

2016-01-25 Thread Chao Yu
Hi Jaegeuk,

> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, January 26, 2016 3:18 AM
> To: Chao Yu
> Cc: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Subject: Re: [f2fs-dev] [PATCH 1/2] f2fs: avoid multiple node page writes due 
> to inline_data
> 
> Hi Chao,
> 
> On Mon, Jan 25, 2016 at 05:42:40PM +0800, Chao Yu wrote:
> > Hi Jaegeuk,
> >
> > > -Original Message-
> > > From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> > > Sent: Sunday, January 24, 2016 4:16 AM
> > > To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> > > linux-f2fs-de...@lists.sourceforge.net
> > > Cc: Jaegeuk Kim
> > > Subject: [f2fs-dev] [PATCH 1/2] f2fs: avoid multiple node page writes due 
> > > to inline_data
> > >
> > > The sceanrio is:
> > > 1. create fully node blocks
> > > 2. flush node blocks
> > > 3. write inline_data for all the node blocks again
> > > 4. flush node blocks redundantly
> > >
> > > Signed-off-by: Jaegeuk Kim 
> > > ---
> > >  fs/f2fs/data.c | 14 +++---
> > >  1 file changed, 11 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> > > index 8d0d9ec..011456e 100644
> > > --- a/fs/f2fs/data.c
> > > +++ b/fs/f2fs/data.c
> > > @@ -1622,14 +1622,22 @@ static int f2fs_write_end(struct file *file,
> > >
> > >   trace_f2fs_write_end(inode, pos, len, copied);
> > >
> > > - set_page_dirty(page);
> > > -
> > >   if (pos + copied > i_size_read(inode)) {
> > >   i_size_write(inode, pos + copied);
> > >   mark_inode_dirty(inode);
> > > - update_inode_page(inode);
> > >   }
> > >
> > > + if (f2fs_has_inline_data(inode) &&
> > > + is_inode_flag_set(F2FS_I(inode), FI_DATA_EXIST)) {
> > > + int err = f2fs_write_inline_data(inode, page);
> >
> > Oh, I'm sure this can fix that issue, but IMO:
> > a) this implementation has side-effect, it triggers inline data copying
> > between data page and node page whenever user write inline datas, so if
> > user updates inline data frequently, write-through approach would cause
> > memory copy overhead.
> 
> Agreed.
> 
> > b) inline storm should be a rare case, as we didn't get any report about
> > problem for long time until Dave's, and write_end is a hot path, I think
> > it's better to be cautious to change our inline data cache policy for
> > fixing a rare issue in hot path.
> >
> > What about delaying the merge operation? like:
> > 1) as I proposed before, merging inline page into inode page when
> > detecting free_sections <= (node_secs + 2 * dent_secs + inline_secs).
> > 2) merge inline page into inode page before writeback inode page in
> > sync_node_pages.
> 
> Okay, I'm thinking more general way where we can get rid of every inlien_data
> write when we flush node pages.

I encountered deadlock issue, could you have a look at it?

==
 [ INFO: possible circular locking dependency detected ]
 4.5.0-rc1 #45 Tainted: G   O
 ---
 fstrim/15301 is trying to acquire lock:
  (sb_internal#2){..}, at: [] __sb_start_write+0xda/0xf0

 but task is already holding lock:
  (>cp_rwsem){..}, at: [] 
block_operations+0x82/0x130 [f2fs]

 which lock already depends on the new lock.


 the existing dependency chain (in reverse order) is:

 -> #1 (>cp_rwsem){..}:
[] lock_acquire+0xb7/0x130
[] down_read+0x39/0x50
[] f2fs_evict_inode+0x26f/0x370 [f2fs]
[] evict+0xdd/0x1d0
[] iput+0x19f/0x250
[] do_unlinkat+0x20d/0x310
[] SyS_unlinkat+0x22/0x40
[] entry_SYSCALL_64_fastpath+0x12/0x6f

 -> #0 (sb_internal#2){..}:
[] __lock_acquire+0x132b/0x1770
[] lock_acquire+0xb7/0x130
[] percpu_down_read+0x3c/0x80
[] __sb_start_write+0xda/0xf0
[] f2fs_evict_inode+0x221/0x370 [f2fs]
[] evict+0xdd/0x1d0
[] iput+0x19f/0x250
[] sync_node_pages+0x703/0x900 [f2fs]
[] block_operations+0x10a/0x130 [f2fs]
[] write_checkpoint+0xc4/0xb80 [f2fs]
[] f2fs_trim_fs+0x122/0x1d0 [f2fs]
[] f2fs_ioctl+0x7fa/0x9d0 [f2fs]
[] vfs_ioctl+0x18/0x40
[] do_vfs_ioctl+0x96/0x680
[] SyS_ioctl+0x92/0xa0
[] entry_SYSCALL_64_fastpath+0x12/0x6f

 other info that might help us debug this:

  Possible unsafe locking scenario:

CPU0CPU1

   lock(>cp_rwsem);
lock(sb_internal#2);
lock(>cp_rwsem);
   lock(sb_internal#2);

  *** DEADLOCK ***

Thanks,

> 
> I've been testing this patch.
> 
> From ebddf607c64da691fef08cf68a8ecadafd5d896b Mon Sep 17 00:00:00 2001
> From: Jaegeuk Kim 
> Date: Mon, 25 Jan 2016 05:57:05 -0800
> Subject: [PATCH] f2fs: avoid multiple node page 

[PATCH v4 1/7] mtd: spi-nor: fsl-quadspi: add big-endian support

2016-01-25 Thread Yuan Yao
Add R/W functions for big- or little-endian registers:
The qSPI controller's endian is independent of the CPU core's endian.
So far, the qSPI have two versions for big-endian and little-endian.

Signed-off-by: Yuan Yao 
Acked-by: Han xu 
---
Changed in v4:
No changes.

Changed in v3:
Update my email to 

Changed in v2:
Rebase to the lastest code.
---
 drivers/mtd/spi-nor/fsl-quadspi.c | 157 +++---
 1 file changed, 97 insertions(+), 60 deletions(-)

diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c 
b/drivers/mtd/spi-nor/fsl-quadspi.c
index 54640f1..04e8a93 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -275,6 +275,7 @@ struct fsl_qspi {
u32 clk_rate;
unsigned int chip_base_addr; /* We may support two chips. */
bool has_second_chip;
+   bool big_endian;
struct mutex lock;
struct pm_qos_request pm_qos_req;
 };
@@ -300,6 +301,28 @@ static inline int needs_wakeup_wait_mode(struct fsl_qspi 
*q)
 }
 
 /*
+ * R/W functions for big- or little-endian registers:
+ * The qSPI controller's endian is independent of the CPU core's endian.
+ * So far, although the CPU core is little-endian but the qSPI have two
+ * versions for big-endian and little-endian.
+ */
+static void qspi_writel(struct fsl_qspi *q, u32 val, void __iomem *addr)
+{
+   if (q->big_endian)
+   iowrite32be(val, addr);
+   else
+   iowrite32(val, addr);
+}
+
+static u32 qspi_readl(struct fsl_qspi *q, void __iomem *addr)
+{
+   if (q->big_endian)
+   return ioread32be(addr);
+   else
+   return ioread32(addr);
+}
+
+/*
  * An IC bug makes us to re-arrange the 32-bit data.
  * The following chips, such as IMX6SLX, have fixed this bug.
  */
@@ -310,14 +333,14 @@ static inline u32 fsl_qspi_endian_xchg(struct fsl_qspi 
*q, u32 a)
 
 static inline void fsl_qspi_unlock_lut(struct fsl_qspi *q)
 {
-   writel(QUADSPI_LUTKEY_VALUE, q->iobase + QUADSPI_LUTKEY);
-   writel(QUADSPI_LCKER_UNLOCK, q->iobase + QUADSPI_LCKCR);
+   qspi_writel(q, QUADSPI_LUTKEY_VALUE, q->iobase + QUADSPI_LUTKEY);
+   qspi_writel(q, QUADSPI_LCKER_UNLOCK, q->iobase + QUADSPI_LCKCR);
 }
 
 static inline void fsl_qspi_lock_lut(struct fsl_qspi *q)
 {
-   writel(QUADSPI_LUTKEY_VALUE, q->iobase + QUADSPI_LUTKEY);
-   writel(QUADSPI_LCKER_LOCK, q->iobase + QUADSPI_LCKCR);
+   qspi_writel(q, QUADSPI_LUTKEY_VALUE, q->iobase + QUADSPI_LUTKEY);
+   qspi_writel(q, QUADSPI_LCKER_LOCK, q->iobase + QUADSPI_LCKCR);
 }
 
 static irqreturn_t fsl_qspi_irq_handler(int irq, void *dev_id)
@@ -326,8 +349,8 @@ static irqreturn_t fsl_qspi_irq_handler(int irq, void 
*dev_id)
u32 reg;
 
/* clear interrupt */
-   reg = readl(q->iobase + QUADSPI_FR);
-   writel(reg, q->iobase + QUADSPI_FR);
+   reg = qspi_readl(q, q->iobase + QUADSPI_FR);
+   qspi_writel(q, reg, q->iobase + QUADSPI_FR);
 
if (reg & QUADSPI_FR_TFF_MASK)
complete(>c);
@@ -348,7 +371,7 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
 
/* Clear all the LUT table */
for (i = 0; i < QUADSPI_LUT_NUM; i++)
-   writel(0, base + QUADSPI_LUT_BASE + i * 4);
+   qspi_writel(q, 0, base + QUADSPI_LUT_BASE + i * 4);
 
/* Quad Read */
lut_base = SEQID_QUAD_READ * 4;
@@ -364,14 +387,15 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
dummy = 8;
}
 
-   writel(LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
+   qspi_writel(q, LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
base + QUADSPI_LUT(lut_base));
-   writel(LUT0(DUMMY, PAD1, dummy) | LUT1(FSL_READ, PAD4, rxfifo),
+   qspi_writel(q, LUT0(DUMMY, PAD1, dummy) | LUT1(FSL_READ, PAD4, rxfifo),
base + QUADSPI_LUT(lut_base + 1));
 
/* Write enable */
lut_base = SEQID_WREN * 4;
-   writel(LUT0(CMD, PAD1, SPINOR_OP_WREN), base + QUADSPI_LUT(lut_base));
+   qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_WREN),
+   base + QUADSPI_LUT(lut_base));
 
/* Page Program */
lut_base = SEQID_PP * 4;
@@ -385,13 +409,15 @@ static void fsl_qspi_init_lut(struct fsl_qspi *q)
addrlen = ADDR32BIT;
}
 
-   writel(LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
+   qspi_writel(q, LUT0(CMD, PAD1, cmd) | LUT1(ADDR, PAD1, addrlen),
base + QUADSPI_LUT(lut_base));
-   writel(LUT0(FSL_WRITE, PAD1, 0), base + QUADSPI_LUT(lut_base + 1));
+   qspi_writel(q, LUT0(FSL_WRITE, PAD1, 0),
+   base + QUADSPI_LUT(lut_base + 1));
 
/* Read Status */
lut_base = SEQID_RDSR * 4;
-   writel(LUT0(CMD, PAD1, SPINOR_OP_RDSR) | LUT1(FSL_READ, PAD1, 0x1),
+   qspi_writel(q, LUT0(CMD, PAD1, SPINOR_OP_RDSR) |
+   

[PATCH v4 7/7] Documentation: fsl-quadspi: Add optional properties

2016-01-25 Thread Yuan Yao
Add optional properties for QSPI:
big-endian
if the register is big endian on this platform.

Signed-off-by: Yuan Yao 
Acked-by: Rob Herring 
---
Changed in v4:
No changes.

Changed in v3:
No changes.

Changed in v2:
Update my email to 
---
 Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt 
b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
index 0df2f3a..0333ec8 100644
--- a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
+++ b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
@@ -21,6 +21,7 @@ Optional properties:
  But if there are two NOR flashes connected to the
  bus, you should enable this property.
  (Please check the board's schematic.)
+  - big-endian : That means the IP register is big endian
 
 Example:
 
-- 
2.1.0.27.g96db324



[PATCH v4 4/7] Documentation: fsl-quadspi: Add fsl,ls2080a-dspi compatible string

2016-01-25 Thread Yuan Yao
new compatible string: "fsl,ls2080a-qspi".

Signed-off-by: Yuan Yao 
Acked-by: Rob Herring 
---
Changed in v4:
No changes.

Changed in v3:
Add the modifier for new compatible string like:
"fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"

Changed in v2:
Update my email to 
---
 Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt 
b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
index fa77f87..1ad0fe3 100644
--- a/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
+++ b/Documentation/devicetree/bindings/spi/spi-fsl-dspi.txt
@@ -1,7 +1,10 @@
 ARM Freescale DSPI controller
 
 Required properties:
-- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi", "fsl,ls2085a-dspi"
+- compatible : "fsl,vf610-dspi", "fsl,ls1021a-v1.0-dspi",
+   "fsl,ls2085a-dspi"
+   or
+   "fsl,ls2080a-dspi" followed by "fsl,ls2085a-dspi"
 - reg : Offset and length of the register set for the device
 - interrupts : Should contain SPI controller interrupt
 - clocks: from common clock binding: handle to dspi clock.
-- 
2.1.0.27.g96db324



Re: [PATCH V2 4/4] mfd: mediatek: add MT6323 support to MT6397 driver

2016-01-25 Thread Henry Chen
On Mon, 2016-01-25 at 19:59 +0100, John Crispin wrote:
> 
> On 25/01/2016 19:44, Matthias Brugger wrote:
> > On Monday 25 Jan 2016 16:36:40 John Crispin wrote:
> >> Hi,
> >>
> >> On 25/01/2016 13:41, Lee Jones wrote:
> >>> Please honour the subject format of the subsystem you are contributing
> >>> to.
> >>>
> >>> `git log --oneline -- $subsystem` gives you this.
> >>>
> >>> On Mon, 25 Jan 2016, John Crispin wrote:
>  Signed-off-by: John Crispin 
>  ---
> >>
> >> [...]
> >>
>  @@ -261,6 +271,15 @@ static int mt6397_probe(struct platform_device
>  *pdev)
> 
>   }
>   
>   switch (id & 0xff) {
> 
>  +case MT6323_CID_CODE:
>  +mt6397->int_con[0] = MT6323_INT_CON0;
> >>>
> >>> This is confusing.  You're still using memory allocated for a mt6397
> >>> device.
> >>
> >> the variable is currently defined as struct mt6397_chip *mt6397;
> >> shall i only change the name or also create a patch to rename the struct ?
> >>
> > 
> > I think we should rename the struct and the file as well.
> > 
> > Cheers,
> > Matthias
> 
> Hi,
> 
> that would have been my next question. renaming the struct would imply
> renaming the driver and the whole namespace contained within. We would
> then also need to change the Kconfig and Makefile. I am happy to do this
> but want to be sure that is is actually wanted.
> 
>   John
Hi,

Since mt6323 was similar with mt6397, I think we can reuse the
mt6397_chip without duplicate code.

Maybe we can rename the local variable name to avoid confusing.

struct mt6397_chip *mt_pmic;
...
...
switch (id & 0xff) {
case MT6323_CID_CODE:
mt_pmic->int_con[0] = MT6323_INT_CON0;
mt_pmic->int_con[1] = MT6323_INT_CON1;
...
...

Henry




Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled

2016-01-25 Thread Eric W. Biederman
Kees Cook  writes:

> On Mon, Jan 25, 2016 at 11:33 AM, Eric W. Biederman
>  wrote:
>> Kees Cook  writes:
>>>
>>> Well, I don't know about less weird, but it would leave a unneeded
>>> hole in the permission checks.
>>
>> To be clear the current patch has my:
>>
>> Nacked-by: "Eric W. Biederman" 
>>
>> The code is buggy, and poorly thought through.  Your lack of interest in
>> fixing the bugs in your patch is distressing.
>
> I'm not sure where you see me having a "lack of interest". The
> existing cap-checking sysctls have a corner-case bug, which is
> orthogonal to this change.

That certainly doesn't sound like you have any plans to change anything
there.

>> So broken code, not willing to fix.  No. We are not merging this sysctl.
>
> I think you're jumping to conclusions. :)

I think I am the maintainer.

What you are proposing is very much something that is only of interst to
people who are not using user namespaces.  It is fatally flawed as
a way to avoid new attack surfaces for people who don't care as the
sysctl leaves user namespaces enabled by default.  It is fatally flawed
as remediation to recommend to people to change if a new user namespace
related but is discovered.  Any running process that happens to be
created while user namespace creation was enabled will continue to
exist.  Effectively a reboot will be required as part of a mitigation.
Many sysadmins will get that wrong.

I can't possibly see your sysctl as proposed achieving it's goals.  A
person has to be entirely too aware of subtlety and nuance to use it
effectively.

> This feature is already implemented by two distros, and likely wanted
> by others. We cannot ignore that. The sysctl default doesn't change
> the existing behavior, so this doesn't get in your way at all. Can you
> please respond to my earlier email where I rebutted each of your
> arguments against it? Just saying "no" and putting words in my mouth
> isn't very productive.

Calling people who make mistakes insane is not a rebuttal.  In security
usability matters, and your sysctl has low usability.

Further you seem to have missed something crucial in your understanding.
As was explained earlier the sysctl was added to ubuntu to allow early
adopters to experiment not as a long term way of managing user
namespaces.


What sounds like a generally useful feature that would cover your use
case and many others is a per user limit on the number of user
namespaces users may create.

Eric


Re: [PATCH] signals: work around random wakeups in sigsuspend()

2016-01-25 Thread Ingo Molnar

* Sasha Levin  wrote:

> A random wakeup can get us out of sigsuspend() without TIF_SIGPENDING
> being set.
> 
> Avoid that by making sure we were signaled, like sys_pause() does.
> 
> Signed-off-by: Sasha Levin 
> ---
>  kernel/signal.c |6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/signal.c b/kernel/signal.c
> index 5da9180..3256c7e 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -3528,8 +3528,10 @@ static int sigsuspend(sigset_t *set)
>   current->saved_sigmask = current->blocked;
>   set_current_blocked(set);
>  
> - __set_current_state(TASK_INTERRUPTIBLE);
> - schedule();
> + while (!signal_pending(current)) {
> + __set_current_state(TASK_INTERRUPTIBLE);
> + schedule();
> + }
>   set_restore_sigmask();
>   return -ERESTARTNOHAND;
>  }

So this does not appear to be anything new, right?

I agree with the fix, but I'm somewhat worried about the potential ABI impact: 
does anything exist out there that has learned to rely on spurious returns from 
SyS_sigsuspend() or SyS_rt_sigsuspend() system calls? These are one of the most 
frequently used system calls in signal based event loops.

Thanks,

Ingo


Re: [PATCH V2 4/4] mfd: mediatek: add MT6323 support to MT6397 driver

2016-01-25 Thread John Crispin


On 26/01/2016 04:07, Henry Chen wrote:
> On Mon, 2016-01-25 at 19:59 +0100, John Crispin wrote:
>>
>> On 25/01/2016 19:44, Matthias Brugger wrote:
>>> On Monday 25 Jan 2016 16:36:40 John Crispin wrote:
 Hi,

 On 25/01/2016 13:41, Lee Jones wrote:
> Please honour the subject format of the subsystem you are contributing
> to.
>
> `git log --oneline -- $subsystem` gives you this.
>
> On Mon, 25 Jan 2016, John Crispin wrote:
>> Signed-off-by: John Crispin 
>> ---

 [...]

>> @@ -261,6 +271,15 @@ static int mt6397_probe(struct platform_device
>> *pdev)
>>
>>  }
>>  
>>  switch (id & 0xff) {
>>
>> +case MT6323_CID_CODE:
>> +mt6397->int_con[0] = MT6323_INT_CON0;
>
> This is confusing.  You're still using memory allocated for a mt6397
> device.

 the variable is currently defined as struct mt6397_chip *mt6397;
 shall i only change the name or also create a patch to rename the struct ?

>>>
>>> I think we should rename the struct and the file as well.
>>>
>>> Cheers,
>>> Matthias
>>
>> Hi,
>>
>> that would have been my next question. renaming the struct would imply
>> renaming the driver and the whole namespace contained within. We would
>> then also need to change the Kconfig and Makefile. I am happy to do this
>> but want to be sure that is is actually wanted.
>>
>>  John
> Hi,
> 
> Since mt6323 was similar with mt6397, I think we can reuse the
> mt6397_chip without duplicate code.
> 
> Maybe we can rename the local variable name to avoid confusing.
> 
> struct mt6397_chip *mt_pmic;
> ...
> ...
> switch (id & 0xff) {
>   case MT6323_CID_CODE:
>   mt_pmic->int_con[0] = MT6323_INT_CON0;
>   mt_pmic->int_con[1] = MT6323_INT_CON1;
> ...
> ...
> 
> Henry

Hi,

IMHO we should either rename the namespace or not. renaming some
variables seems weird as that will just move the confusion/inconsistency
to another place in the code. I am however rather indifferent on this
matter.

John


[PATCH 2/2] MIPS: ath79: Remove the builtin DTB support

2016-01-25 Thread Alban Bedel
Now that appended DTB is usable we can drop the builtin DTB support.

Signed-off-by: Alban Bedel 
---
 arch/mips/ath79/Kconfig | 12 
 arch/mips/ath79/setup.c |  4 
 arch/mips/boot/dts/qca/Makefile |  3 ---
 3 files changed, 19 deletions(-)

diff --git a/arch/mips/ath79/Kconfig b/arch/mips/ath79/Kconfig
index 13c04cf..dfc6020 100644
--- a/arch/mips/ath79/Kconfig
+++ b/arch/mips/ath79/Kconfig
@@ -71,18 +71,6 @@ config ATH79_MACH_UBNT_XM
  Say 'Y' here if you want your kernel to support the
  Ubiquiti Networks XM (rev 1.0) board.
 
-choice
-   prompt "Build a DTB in the kernel"
-   optional
-   help
- Select a devicetree that should be built into the kernel.
-
-   config DTB_TL_WR1043ND_V1
-   bool "TL-WR1043ND Version 1"
-   select BUILTIN_DTB
-   select SOC_AR913X
-endchoice
-
 endmenu
 
 config SOC_AR71XX
diff --git a/arch/mips/ath79/setup.c b/arch/mips/ath79/setup.c
index 2895e45..01808e8 100644
--- a/arch/mips/ath79/setup.c
+++ b/arch/mips/ath79/setup.c
@@ -205,10 +205,6 @@ void __init plat_mem_setup(void)
__dt_setup_arch((void *)KSEG0ADDR(fdt_start));
else if (fw_arg0 == -2)
__dt_setup_arch((void *)KSEG0ADDR(fw_arg1));
-#ifdef CONFIG_BUILTIN_DTB
-   else
-   __dt_setup_arch(__dtb_start);
-#endif
 
ath79_reset_base = ioremap_nocache(AR71XX_RESET_BASE,
   AR71XX_RESET_SIZE);
diff --git a/arch/mips/boot/dts/qca/Makefile b/arch/mips/boot/dts/qca/Makefile
index 2d61455d..14bd225 100644
--- a/arch/mips/boot/dts/qca/Makefile
+++ b/arch/mips/boot/dts/qca/Makefile
@@ -1,9 +1,6 @@
 # All DTBs
 dtb-$(CONFIG_ATH79)+= ar9132_tl_wr1043nd_v1.dtb
 
-# Select a DTB to build in the kernel
-obj-$(CONFIG_DTB_TL_WR1043ND_V1)   += ar9132_tl_wr1043nd_v1.dtb.o
-
 # Force kbuild to make empty built-in.o if necessary
 obj-   += dummy.o
 
-- 
2.0.0



[PATCH 2/2] f2fs: speed up handling holes in fiemap

2016-01-25 Thread Chao Yu
This patch makes f2fs_map_blocks supporting returning next potential
page offset which skips hole region in indirect tree of inode, and
use it to speed up fiemap in handling big hole case.

Test method:
xfs_io -f /mnt/f2fs/file  -c "pwrite 1099511627776 4096"
time xfs_io -f /mnt/f2fs/file -c "fiemap -v"

Before:
time xfs_io -f /mnt/f2fs/file -c "fiemap -v"
/mnt/f2fs/file:
 EXT: FILE-OFFSET  BLOCK-RANGE  TOTAL FLAGS
   0: [0..2147483647]: hole 2147483648
   1: [2147483648..2147483655]: 81920..81927 8   0x1

real3m3.518s
user0m0.000s
sys 3m3.456s

After:
time xfs_io -f /mnt/f2fs/file -c "fiemap -v"
/mnt/f2fs/file:
 EXT: FILE-OFFSET  BLOCK-RANGE  TOTAL FLAGS
   0: [0..2147483647]: hole 2147483648
   1: [2147483648..2147483655]: 81920..81927 8   0x1

real0m0.008s
user0m0.000s
sys 0m0.008s

Signed-off-by: Chao Yu 
---
 fs/f2fs/data.c | 35 ++-
 fs/f2fs/f2fs.h |  1 +
 fs/f2fs/file.c |  2 +-
 3 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 0956219..59460af 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -540,6 +540,7 @@ static int __allocate_data_blocks(struct inode *inode, 
loff_t offset,
 
map.m_lblk = F2FS_BYTES_TO_BLK(offset);
map.m_len = F2FS_BYTES_TO_BLK(count);
+   map.m_next_pgofs = NULL;
 
return f2fs_map_blocks(inode, , 1, F2FS_GET_BLOCK_DIO);
 }
@@ -587,8 +588,12 @@ next_dnode:
set_new_dnode(, inode, NULL, NULL, 0);
err = get_dnode_of_data(, pgofs, mode);
if (err) {
-   if (err == -ENOENT)
+   if (err == -ENOENT) {
err = 0;
+   if (map->m_next_pgofs)
+   *map->m_next_pgofs =
+   get_next_page_offset(, pgofs);
+   }
goto unlock_out;
}
 
@@ -610,6 +615,11 @@ next_block:
map->m_flags = F2FS_MAP_NEW;
blkaddr = dn.data_blkaddr;
} else {
+   if (flag == F2FS_GET_BLOCK_FIEMAP &&
+   blkaddr == NULL_ADDR) {
+   if (map->m_next_pgofs)
+   *map->m_next_pgofs = pgofs + 1;
+   }
if (flag != F2FS_GET_BLOCK_FIEMAP ||
blkaddr != NEW_ADDR) {
if (flag == F2FS_GET_BLOCK_BMAP)
@@ -670,13 +680,15 @@ out:
 }
 
 static int __get_data_block(struct inode *inode, sector_t iblock,
-   struct buffer_head *bh, int create, int flag)
+   struct buffer_head *bh, int create, int flag,
+   pgoff_t *next_pgofs)
 {
struct f2fs_map_blocks map;
int ret;
 
map.m_lblk = iblock;
map.m_len = bh->b_size >> inode->i_blkbits;
+   map.m_next_pgofs = next_pgofs;
 
ret = f2fs_map_blocks(inode, , create, flag);
if (!ret) {
@@ -688,16 +700,18 @@ static int __get_data_block(struct inode *inode, sector_t 
iblock,
 }
 
 static int get_data_block(struct inode *inode, sector_t iblock,
-   struct buffer_head *bh_result, int create, int flag)
+   struct buffer_head *bh_result, int create, int flag,
+   pgoff_t *next_pgofs)
 {
-   return __get_data_block(inode, iblock, bh_result, create, flag);
+   return __get_data_block(inode, iblock, bh_result, create,
+   flag, next_pgofs);
 }
 
 static int get_data_block_dio(struct inode *inode, sector_t iblock,
struct buffer_head *bh_result, int create)
 {
return __get_data_block(inode, iblock, bh_result, create,
-   F2FS_GET_BLOCK_DIO);
+   F2FS_GET_BLOCK_DIO, NULL);
 }
 
 static int get_data_block_bmap(struct inode *inode, sector_t iblock,
@@ -708,7 +722,7 @@ static int get_data_block_bmap(struct inode *inode, 
sector_t iblock,
return -EFBIG;
 
return __get_data_block(inode, iblock, bh_result, create,
-   F2FS_GET_BLOCK_BMAP);
+   F2FS_GET_BLOCK_BMAP, NULL);
 }
 
 static inline sector_t logical_to_blk(struct inode *inode, loff_t offset)
@@ -726,6 +740,7 @@ int f2fs_fiemap(struct inode *inode, struct 
fiemap_extent_info *fieinfo,
 {
struct buffer_head map_bh;
sector_t start_blk, last_blk;
+   pgoff_t next_pgofs;
loff_t isize;
u64 logical = 0, phys = 0, size = 0;
u32 flags = 0;
@@ -761,14 +776,15 @@ next:
map_bh.b_size = len;
 
ret = get_data_block(inode, 

Re: [PATCH v2] pci: fix unavailable irq number 255 reported by BIOS

2016-01-25 Thread Guenter Roeck
On Mon, Jan 25, 2016 at 02:58:04PM -0600, Bjorn Helgaas wrote:
> [+cc Thomas]
> 
[ ... ]

> 
> I don't like the x86 ifdef.  I'd prefer:
> 
>   static inline bool irq_valid(unsigned int irq)
>   {
> if (irq < NR_IRQS)
>   return true;
> return false;
>   }
> 

Or:

static inline bool irq_valid(unsigned int irq)
{
return irq < NR_IRQS;
}

Guenter


Re: [BUG REPORT] Soft Lockup in smp_call_function_single+0xD8

2016-01-25 Thread Jeff Merkey
On 1/25/16, Jeff Merkey  wrote:
> On 1/24/16, Jeff Merkey  wrote:
>> On 1/24/16, Jeff Merkey  wrote:
>>> If I single step with either kgdb, kgdb, or mdb kernel debuggers over
>>> a sysret instruction anywhere in the OS,  the system hard hangs in
>>> smp_call_function_single after the debugger releases the system and it
>>> resumes normal operation.The specific place the kernel hangs is in
>>> the loop below.   The softlockup detector will periodically detect
>>> this condition when it occurs, but not always, most of the time the
>>> system is just hung and unresponsive.
>>>
>>> (2)> u smp_call_function_single+d8
>>>  hard hang in this loop with EDX=3
>>> 0x810fce48 8B55E0  movedx,DWORD PTR
>>> [rbp-32]=0xCE037DC0
>>> 0x810fce4b 83E201  andedx,0x1
>>> 0x810fce4e 75F6jne
>>> smp_call_function_single+0xd6 (0x810fce46) (up)
>>> <
>>> 0x810fce50 EBC3jmp
>>> smp_call_function_single+0xa5 (0x810fce15) (up)
>>> 0x810fce52 8B05E08EC700moveax,[oops_in_progress]=0x0
>>> 0x810fce58 85C0test   eax,eax
>>> 0x810fce5a 7585jne
>>> smp_call_function_single+0x71 (0x810fcde1) (up)
>>> 0x810fce5c 803D8E0C9D  cmp[__warned.20610]=0x00,0x0
>>> 0x810fce63 0F8578FFjne
>>> smp_call_function_single+0x71 (0x810fcde1) (up)
>>> 0x810fce69 BE2401  movesi,0x124
>>> 0x810fce6e 48C7C796B08C81  movrdi,0x818cb096
>>> 0x810fce75 894DBC  movDWORD PTR [rbp-68]=0x0,ecx
>>> 0x810fce78 488955C0movQWORD PTR
>>> [rbp-64]=0xFF10,rdx
>>> 0x810fce7c E8FF21F8FF  call   warn_slowpath_null
>>> 0x810fce81 C605690C9D0001  mov[__warned.20610]=0x00,0x1
>>> 0x810fce88 8B4DBC  movecx,DWORD PTR [rbp-68]=0x0
>>> 0x810fce8b 488B55C0movrdx,QWORD PTR
>>> [rbp-64]=0xFF10
>>> 0x810fce8f E94DFF  jmp
>>> smp_call_function_single+0x71 (0x810fcde1) (up)
>>> 0x810fce94 E8A71EF8FF  call   __stack_chk_fail
>>> 0x810fce99 0F1F80  nopDWORD PTR [rax]=0x0
>>> (2)> g
>>>
>>>
>>> The stack backtrace when the bug occurs is:
>>>
>>> smp_call_function_single+0xd8
>>> unmap_page_range+0x613
>>> flush_tlb_func+0x0
>>> smp_call_function_many+215
>>> native_flush_tlb_others+0x118
>>> flush_tlb_mm_range+0x61
>>> tlb_flush_mmu_tlbonly+0x6b
>>> tlb_finish_mmu+0x14
>>> unmap_region+0xe2
>>> vma_rb_erase+0x10f
>>> do_unmap+0x217
>>> vm_unmap+0x41
>>> SyS_munmap+0x22
>>> entry_SYSCALL_64_fastpath+0x12
>>>
>>> I traced through this code a bunch of times in just normal operations
>>> without triggering the bug to get a feel for what it normally sees in
>>> EDX and it looks like someone has coded a looping function that always
>>> has EDX=0 in every case I saw in the except for when this bug occurs.
>>>
>>> So the exact C code this maps fro objdump of kernel/smp.o is:
>>>
>>>  469:   e8 62 fe ff ff  callq  2d0 
>>>  46e:   8b 55 e0mov-0x20(%rbp),%edx
>>>  * previous function call. For multi-cpu calls its even more interesting
>>>  * as we'll have to ensure no other cpu is observing our csd.
>>>  */
>>> static void csd_lock_wait(struct call_single_data *csd)
>>> {
>>> while (smp_load_acquire(>flags) & CSD_FLAG_LOCK)
>>>  471:   83 e2 01and$0x1,%edx
>>>  474:   74 cf   je 445 
>>> 
>>>  476:   f3 90   pause
>>> <<
>>>  478:   8b 55 e0mov-0x20(%rbp),%edx
>>>  47b:   83 e2 01and$0x1,%edx
>>>  47e:   75 f6   jne476 
>>> 
>>> <<<
>>>  480:   eb c3   jmp445 
>>> 
>>>  * Can deadlock when called with interrupts disabled.
>>>  * We allow cpu's that are not yet online though, as no one else can
>>>  * send smp call function interrupt to this cpu and as such deadlocks
>>>  * can't happen.
>>>  */
>>> WARN_ON_ONCE(cpu_online(this_cpu) && irqs_disabled()
>>>
>>> Each time this bug occurs csd->flags is always set to a value of 3 and
>>> never changes.  When the system is just running normally, it seems to
>>> be 0 the rest of the time.   Setting EDX=0 from the debugger console
>>> clears the hang condition and the system seems to recover except the
>>> system reports this error from the console when you attempt to load
>>> programs, indicating the ability of the system to load shared objects
>>> is fritzed.
>>>
>>> #
>>> # ls -l
>>> /lib64/libc.so.6 version GLI not found   << this error and no shared
>>> objects will load
>>> #
>>> #
>>>
>>> Jeff
>>>
>>
>> I am running down a trace of the 

Re: [PATCH] Add hard/soft lockup debugger entry points

2016-01-25 Thread kbuild test robot
Hi Jeff,

[auto build test ERROR on v4.5-rc1]
[also build test ERROR on next-20160125]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Jeff-Merkey/Add-hard-soft-lockup-debugger-entry-points/20160126-103801
config: powerpc-defconfig (attached as .config)
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=powerpc 

All errors (new ones prefixed by >>):

   {standard input}: Assembler messages:
>> {standard input}:550: Error: unrecognized opcode: `int'
   {standard input}:1121: Error: unrecognized opcode: `int'

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


.config.gz
Description: Binary data


[PATCH v2 1/3] f2fs: simplify f2fs_map_blocks

2016-01-25 Thread Chao Yu
In f2fs_map_blocks, we use duplicated codes to handle first block mapping
and the following blocks mapping, it's unnecessary. This patch simplifies
f2fs_map_blocks to avoid using copied codes.

Signed-off-by: Chao Yu 
---

 V2:
 - rebase on last dev-test

 fs/f2fs/data.c | 101 ++---
 1 file changed, 32 insertions(+), 69 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index c85acbc..f570d37 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -632,6 +632,7 @@ int f2fs_map_blocks(struct inode *inode, struct 
f2fs_map_blocks *map,
goto out;
}
 
+next_dnode:
if (create)
f2fs_lock_op(sbi);
 
@@ -644,47 +645,57 @@ int f2fs_map_blocks(struct inode *inode, struct 
f2fs_map_blocks *map,
goto unlock_out;
}
 
-   if (dn.data_blkaddr == NEW_ADDR || dn.data_blkaddr == NULL_ADDR) {
+   end_offset = ADDRS_PER_PAGE(dn.node_page, F2FS_I(inode));
+
+next_block:
+   blkaddr = datablock_addr(dn.node_page, dn.ofs_in_node);
+
+   if (blkaddr == NEW_ADDR || blkaddr == NULL_ADDR) {
if (create) {
if (unlikely(f2fs_cp_error(sbi))) {
err = -EIO;
-   goto put_out;
+   goto sync_out;
}
err = __allocate_data_block();
if (err)
-   goto put_out;
+   goto sync_out;
allocated = true;
map->m_flags = F2FS_MAP_NEW;
+   blkaddr = dn.data_blkaddr;
} else {
if (flag != F2FS_GET_BLOCK_FIEMAP ||
-   dn.data_blkaddr != NEW_ADDR) {
+   blkaddr != NEW_ADDR) {
if (flag == F2FS_GET_BLOCK_BMAP)
err = -ENOENT;
-   goto put_out;
+   goto sync_out;
}
-
-   /*
-* preallocated unwritten block should be mapped
-* for fiemap.
-*/
-   if (dn.data_blkaddr == NEW_ADDR)
-   map->m_flags = F2FS_MAP_UNWRITTEN;
}
}
 
-   map->m_flags |= F2FS_MAP_MAPPED;
-   map->m_pblk = dn.data_blkaddr;
-   map->m_len = 1;
+   if (map->m_len == 0) {
+   /* preallocated unwritten block should be mapped for fiemap. */
+   if (blkaddr == NEW_ADDR)
+   map->m_flags |= F2FS_MAP_UNWRITTEN;
+   map->m_flags |= F2FS_MAP_MAPPED;
+
+   map->m_pblk = blkaddr;
+   map->m_len = 1;
+   } else if ((map->m_pblk != NEW_ADDR &&
+   blkaddr == (map->m_pblk + ofs)) ||
+   (map->m_pblk == NEW_ADDR && blkaddr == NEW_ADDR)) {
+   ofs++;
+   map->m_len++;
+   } else {
+   goto sync_out;
+   }
 
-   end_offset = ADDRS_PER_PAGE(dn.node_page, F2FS_I(inode));
dn.ofs_in_node++;
pgofs++;
 
-get_next:
-   if (map->m_len >= maxblocks)
-   goto sync_out;
+   if (map->m_len < maxblocks) {
+   if (dn.ofs_in_node < end_offset)
+   goto next_block;
 
-   if (dn.ofs_in_node >= end_offset) {
if (allocated)
sync_inode_page();
f2fs_put_dnode();
@@ -692,62 +703,14 @@ get_next:
if (create) {
f2fs_unlock_op(sbi);
f2fs_balance_fs(sbi, allocated);
-   f2fs_lock_op(sbi);
}
allocated = false;
-
-   set_new_dnode(, inode, NULL, NULL, 0);
-   err = get_dnode_of_data(, pgofs, mode);
-   if (err) {
-   if (err == -ENOENT)
-   err = 0;
-   goto unlock_out;
-   }
-
-   end_offset = ADDRS_PER_PAGE(dn.node_page, F2FS_I(inode));
-   }
-
-   blkaddr = datablock_addr(dn.node_page, dn.ofs_in_node);
-
-   if (blkaddr == NEW_ADDR || blkaddr == NULL_ADDR) {
-   if (create) {
-   if (unlikely(f2fs_cp_error(sbi))) {
-   err = -EIO;
-   goto sync_out;
-   }
-   err = __allocate_data_block();
-   if (err)
-   goto sync_out;
-   allocated = true;
-   map->m_flags |= F2FS_MAP_NEW;
-   blkaddr = dn.data_blkaddr;
-   } else {

RE: [lkp] [pci] 2910b5bdc5: pci 0000:06:00.0: Unable to allocate DMA alias mask.

2016-01-25 Thread Lawrynowicz, Jacek
Wow. It's very cool that you do automated tests for upcoming changes :)
This particular bug was already caught in review by Bjorn.

Regards,
Jacek

-Original Message-
From: kernel test robot [mailto:ying.hu...@linux.intel.com] 
Sent: Tuesday, January 26, 2016 1:59 AM
To: Lawrynowicz, Jacek 
Cc: l...@01.org; LKML ; Joerg Roedel 
; Woodhouse, David ; Wu, Fengguang 

Subject: [lkp] [pci] 2910b5bdc5: pci :06:00.0: Unable to allocate DMA alias 
mask.

FYI, we noticed the below changes on

https://github.com/0day-ci/linux 
Jacek-Lawrynowicz/pci-Add-support-for-multiple-DMA-aliases/20160119-001005
commit 2910b5bdc5788de99e9c533be97b0e8f57be0386 ("pci: Add support for multiple 
DMA aliases")

We found the following new message in kernel log after your commit.

[0.217837] pci :06:00.0: Unable to allocate DMA alias mask.

Thanks,
Ying Huang


[PATCH] clk: rockchip: fix wrong mmc phase shift for rk3228

2016-01-25 Thread Shawn Lin
mmc sample shift is 0 for rk3228 refer to user manaul.
So it's broken if we enable mmc tuning for rk3228.

Fixes: 307a2e9ac ("clk: rockchip: add clock controller for rk3228")
Cc: Xing Zheng 
Cc: Jeffy Chen 
Signed-off-by: Shawn Lin 
---

 drivers/clk/rockchip/clk-rk3228.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/clk/rockchip/clk-rk3228.c 
b/drivers/clk/rockchip/clk-rk3228.c
index 981a502..97f49aa 100644
--- a/drivers/clk/rockchip/clk-rk3228.c
+++ b/drivers/clk/rockchip/clk-rk3228.c
@@ -605,13 +605,13 @@ static struct rockchip_clk_branch rk3228_clk_branches[] 
__initdata = {
 
/* PD_MMC */
MMC(SCLK_SDMMC_DRV,"sdmmc_drv","sclk_sdmmc", RK3228_SDMMC_CON0, 
1),
-   MMC(SCLK_SDMMC_SAMPLE, "sdmmc_sample", "sclk_sdmmc", RK3228_SDMMC_CON1, 
1),
+   MMC(SCLK_SDMMC_SAMPLE, "sdmmc_sample", "sclk_sdmmc", RK3228_SDMMC_CON1, 
0),
 
MMC(SCLK_SDIO_DRV, "sdio_drv", "sclk_sdio",  RK3228_SDIO_CON0,  
1),
-   MMC(SCLK_SDIO_SAMPLE,  "sdio_sample",  "sclk_sdio",  RK3228_SDIO_CON1,  
1),
+   MMC(SCLK_SDIO_SAMPLE,  "sdio_sample",  "sclk_sdio",  RK3228_SDIO_CON1,  
0),
 
MMC(SCLK_EMMC_DRV, "emmc_drv", "sclk_emmc",  RK3228_EMMC_CON0,  
1),
-   MMC(SCLK_EMMC_SAMPLE,  "emmc_sample",  "sclk_emmc",  RK3228_EMMC_CON1,  
1),
+   MMC(SCLK_EMMC_SAMPLE,  "emmc_sample",  "sclk_emmc",  RK3228_EMMC_CON1,  
0),
 };
 
 static const char *const rk3228_critical_clocks[] __initconst = {
-- 
2.3.7




Re: [PATCH] autofs: show pipe inode in mount options

2016-01-25 Thread Ian Kent
On Mon, 2016-01-25 at 15:48 -0800, Andrew Morton wrote:
> On Tue, 26 Jan 2016 10:19:07 +1100 Stephen Rothwell <
> s...@canb.auug.org.au> wrote:
> 
> > Hi Ian,
> > 
> > On Sat, 23 Jan 2016 08:30:17 +0800 Ian Kent 
> > wrote:
> > > 
> > > I haven't had anything significant enough for autofs to warrant
> > > maintaining a tree and sending push requests so I'll need to ask
> > > Stephen what I need to do (perhaps you could offer some advise on
> > > that
> > > now Stephen, please).
> > 
> > I guess if its just a few patches every now and then, then Andrew
> > Morton may be the best person to shepherd them upstream.
> 
> yup, send 'em along.
> 
> I actually was handling the autofs4 stuff back in 2014 for a bit.

Thanks Andrew.

Last time I tried to send the module rename series we got confused some
how, patches not seen leading to conflicts in applying later patches
IIRC, which lead to the recommendation I send them to linux-next.

The series has grown a bit too now but I'm thinking I should send them
in smaller groups, such as coding style fixes and white space fixes,
change to use pr* logging, etc.

Hopefully that will make the process much more straight forward.

The thing is the patches are mostly not urgent which is why I keep
postponing sending them when higher priority things come up.

As for the patch from Stanislav, I'll put that at the top of my patch
queue, have a quick look at it and send it over so that, hopefully, it
can get merged.

I'll probably send a couple of others too to get things going on with
(what I'm calling) the module rename series.

Ian


Re: [4.5.0-rc1/-next] unaligned bio-s

2016-01-25 Thread Sergey Senozhatsky
Hello,

On (01/25/16 19:45), Jens Axboe wrote:
> On 01/25/2016 06:49 PM, Sergey Senozhatsky wrote:
> >Hello,
> >
> >With 4.5.0-rc1/linux-next I see unaligned requests passed to zram block
> >device.
> >
> >bio->bi_iter.bi_size is expected to be ZRAM_LOGICAL_BLOCK_SIZE (1 << 12) 
> >aligned.
> 
> This is current in my for-linus, if you pull in:
> 
> git://git.kernel.dk/linux-block.git for-linus
> 
> and re-test. It'll go into mainline soon.


Works for me, thanks!


FWIW,
Tested-by: Sergey Senozhatsky 

-ss


Re: [PATCH 2/2] ASoC: s3c24xx: use const snd_soc_component_driver pointer

2016-01-25 Thread Krzysztof Kozlowski
On 26.01.2016 02:07, Arnd Bergmann wrote:
> An older patch to convert the API in the s3c i2s driver
> ended up passing a const pointer into a function that takes
> a non-const pointer, so we now get a warning:
> 
> sound/soc/samsung/s3c2412-i2s.c: In function 's3c2412_iis_dev_probe':
> sound/soc/samsung/s3c2412-i2s.c:172:9: error: passing argument 3 of 
> 's3c_i2sv2_register_component' discards 'const' qualifier from pointer target 
> type [-Werror=discarded-qualifiers]
> 
> However, the s3c_i2sv2_register_component() function again
> passes the pointer into another function taking a const, so
> we just need to change its prototype.
> 
> Signed-off-by: Arnd Bergmann 
> Fixes: eca3b01d0885 ("ASoC: switch over to use snd_soc_register_component() 
> on s3c i2s")
> ---
>  sound/soc/samsung/s3c-i2s-v2.c | 2 +-
>  sound/soc/samsung/s3c-i2s-v2.h | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 

Reviewed-by: Krzysztof Kozlowski 

Best regards,
Krzysztof



[RFC][PATCH v2] prctl: Add PR_SET_TIMERSLACK_PID for setting timer slack of an arbitrary thread.

2016-01-25 Thread John Stultz
From: Ruchi Kandoi 

This allows power/performance management software to set timer
slack for other threads according to its policy for the thread
(such as when the thread is designated foreground vs. background
activity)

Second argument is similar to PR_SET_TIMERSLACK, if non-zero
then the slack is set to that value otherwise sets it to the
default for the thread.

Takes PID of the thread as the third argument.

This interface checks that the calling task has permissions to
to use PTRACE_MODE_ATTACH on the target task, so that we can
ensure arbitrary apps do not change the timer slack for other
apps.

Additional fixes from Ruchi and Micha Kalfon 
have been folded into this patch to make it easier to reivew.

Cc: Arjan van de Ven 
Cc: Thomas Gleixner 
Cc: Oren Laadan 
Cc: Micha Kalfon 
Cc: Ruchi Kandoi 
Cc: Rom Lemarchand 
Cc: Android Kernel Team 
Signed-off-by: Ruchi Kandoi 
[jstultz:
 * Folded in CAP_SYS_NICE check from Ruchi.
 * Folded in fix misplaced PR_SET_TIMERSLACK_PID case fix from
   Micha.
 * Folded in make PR_SET_TIMERSLACK_PID pid namespace aware fix
   from Micha.
 * Changed PR_SET_TIMERSLACK_PID so it didn't collide with
   already upstream prctrl values.
 * Reworked commit message.
 * Moved from CAP_SYS_NICE to PTRACE_MODE_ATTACH for permissions
   checks]
Signed-off-by: John Stultz 
---
New in v2:
* Changed from CAP_SYS_NICE to PTRACE_MODE_ATTACH permissions
  checking on Arjan's suggestion

 include/uapi/linux/prctl.h |  7 +++
 kernel/sys.c   | 25 +
 2 files changed, 32 insertions(+)

diff --git a/include/uapi/linux/prctl.h b/include/uapi/linux/prctl.h
index a8d0759..1a13c2b 100644
--- a/include/uapi/linux/prctl.h
+++ b/include/uapi/linux/prctl.h
@@ -187,6 +187,13 @@ struct prctl_mm_map {
 
 #define PR_SET_FP_MODE 45
 #define PR_GET_FP_MODE 46
+
+/* Sets the timerslack for arbitrary threads
+ * arg2 slack value, 0 means "use default"
+ * arg3 pid of the thread whose timer slack needs to be set
+ */
+#define PR_SET_TIMERSLACK_PID  47
+
 # define PR_FP_MODE_FR (1 << 0)/* 64b FP registers */
 # define PR_FP_MODE_FRE(1 << 1)/* 32b compatibility */
 
diff --git a/kernel/sys.c b/kernel/sys.c
index 78947de..5189378 100644
--- a/kernel/sys.c
+++ b/kernel/sys.c
@@ -41,6 +41,9 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 
 #include 
 #include 
@@ -2076,6 +2079,7 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, 
unsigned long, arg3,
unsigned long, arg4, unsigned long, arg5)
 {
struct task_struct *me = current;
+   struct task_struct *tsk;
unsigned char comm[sizeof(me->comm)];
long error;
 
@@ -2218,6 +,27 @@ SYSCALL_DEFINE5(prctl, int, option, unsigned long, arg2, 
unsigned long, arg3,
case PR_GET_TID_ADDRESS:
error = prctl_get_tid_address(me, (int __user **)arg2);
break;
+   case PR_SET_TIMERSLACK_PID:
+   rcu_read_lock();
+   tsk = find_task_by_vpid((pid_t)arg3);
+   if (tsk == NULL) {
+   rcu_read_unlock();
+   return -EINVAL;
+   }
+   get_task_struct(tsk);
+   rcu_read_unlock();
+   if (ptrace_may_access(tsk, PTRACE_MODE_ATTACH)) {
+   put_task_struct(tsk);
+   return -EPERM;
+   }
+   if (arg2 <= 0)
+   tsk->timer_slack_ns =
+   tsk->default_timer_slack_ns;
+   else
+   tsk->timer_slack_ns = arg2;
+   put_task_struct(tsk);
+   error = 0;
+   break;
case PR_SET_CHILD_SUBREAPER:
me->signal->is_child_subreaper = !!arg2;
break;
-- 
1.9.1



Re: [PATCH] Add hard/soft lockup debugger entry points

2016-01-25 Thread kbuild test robot
Hi Jeff,

[auto build test ERROR on v4.5-rc1]
[also build test ERROR on next-20160125]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Jeff-Merkey/Add-hard-soft-lockup-debugger-entry-points/20160126-103801
config: sparc64-defconfig (attached as .config)
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=sparc64 

All errors (new ones prefixed by >>):

   {standard input}: Assembler messages:
>> {standard input}:335: Error: Unknown opcode: `int'

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


.config.gz
Description: Binary data


Re: [PATCH 3/3] input: touchscreen: ad7879: add device tree support

2016-01-25 Thread kbuild test robot
Hi Stefan,

[auto build test ERROR on input/next]
[also build test ERROR on v4.5-rc1 next-20160125]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Stefan-Agner/input-touchscreen-ad7879-move-header-to-input-subdirectory/20160126-110813
base:   https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
config: sh-allmodconfig (attached as .config)
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=sh 

All errors (new ones prefixed by >>):

   drivers/input/touchscreen/ad7879-i2c.c:151:1: error: 'st1232_ts_dt_ids' 
undeclared here (not in a function)
>> drivers/input/touchscreen/ad7879-i2c.c:151:1: error: 
>> '__mod_of__st1232_ts_dt_ids_device_table' aliased to undefined symbol 
>> 'st1232_ts_dt_ids'

vim +151 drivers/input/touchscreen/ad7879-i2c.c

   145  
   146  #ifdef CONFIG_OF
   147  static const struct of_device_id ad7879_dt_ids[] = {
   148  { .compatible = "adi,ad7879-1", },
   149  { }
   150  };
 > 151  MODULE_DEVICE_TABLE(of, st1232_ts_dt_ids);
   152  #endif
   153  
   154  static struct i2c_driver ad7879_i2c_driver = {

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


.config.gz
Description: Binary data


[lkp] [kallsyms] f5fc9abc4e: BUG: KASAN: null-ptr-deref on address (null)

2016-01-25 Thread kernel test robot
FYI, we noticed the below changes on

https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git kallsyms
commit f5fc9abc4e23dccfa1fc35892cf36a416d1e6aee ("kallsyms: add support for 
relative offsets in kallsyms address table")


+---+--++
|   | v4.5-rc1 | 
f5fc9abc4e |
+---+--++
| boot_successes| 41   | 0  
|
| boot_failures | 197  | 26 
|
| Kernel_panic-not_syncing:Attempted_to_kill_init!exitcode= | 169  |
|
| BUG:kernel_test_oversize  | 19   |
|
| BUG:workqueue_lockup-pool_cpus=#flags=#nice=#stuck_for#s  | 1|
|
| IP-Config:Auto-configuration_of_network_failed| 8|
|
| BUG:KASAN:null-ptr-deref_on_address(null) | 0| 26 
|
| BUG:unable_to_handle_kernel   | 0| 26 
|
+---+--++



[0.354394] Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0
[0.355210] CPU: Intel QEMU Virtual CPU version 2.4.0 (family: 0x6, model: 
0x6, stepping: 0x3)
[0.363389] 
==
[0.364468] BUG: KASAN: null-ptr-deref on address   (null)
[0.365282] Read of size 8 by task swapper/1
[0.365967] CPU: 0 PID: 1 Comm: swapper Not tainted 4.5.0-rc1-1-gf5fc9ab 
#2
[0.367025] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
Debian-1.8.2-1 04/01/2014
[0.368241]  88000e0ff928 88000e0ff720 926c2d59 
88000e0ff7a8
[0.369551]  9221e54a   
0286
[0.370894]     

[0.372206] Call Trace:
[0.372646] BUG: unable to handle kernel paging request at 1100
[0.373669] IP:
Elapsed time: 10
qemu-system-x86_64 -enable-kvm -kernel 
/pkg/linux/x86_64-randconfig-s2-01260945/gcc-5/f5fc9abc4e23dccfa1fc35892cf36a416d1e6aee/vmlinuz-4.5.0-rc1-1-gf5fc9ab
 -append 'root=/dev/ram0 user=lkp 
job=/lkp/scheduled/vm-vp-quantal-x86_64-4/bisect_boot-1-quantal-core-x86_64.cgz-x86_64-randconfig-s2-01260945-f5fc9abc4e23dccfa1fc35892cf36a416d1e6aee-20160126-54763-e8aynf-0.yaml
 ARCH=x86_64 kconfig=x86_64-randconfig-s2-01260945 
branch=linux-devel/devel-hourly-2016012607 
commit=f5fc9abc4e23dccfa1fc35892cf36a416d1e6aee 
BOOT_IMAGE=/pkg/linux/x86_64-randconfig-s2-01260945/gcc-5/f5fc9abc4e23dccfa1fc35892cf36a416d1e6aee/vmlinuz-4.5.0-rc1-1-gf5fc9ab
 max_uptime=600 
RESULT_ROOT=/result/boot/1/vm-vp-quantal-x86_64/quantal-core-x86_64.cgz/x86_64-randconfig-s2-01260945/gcc-5/f5fc9abc4e23dccfa1fc35892cf36a416d1e6aee/0
 LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug apic=debug 
sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100 panic=-1 
softlockup_panic=1 nmi_watchdog=panic oops=panic load_ramdisk=2 
prompt_ramdisk=0 console=ttyS0,115200 console=tty0 vga=normal rw 
ip=vm-vp-quantal-x86_64-4::dhcp drbd.minor_count=8'  -initrd 
/fs/sdh1/initrd-vm-vp-quantal-x86_64-4 -m 360 -smp 2 -device e1000,netdev=net0 
-netdev user,id=net0 -boot order=nc -no-reboot -watchdog i6300esb -rtc 
base=localtime -pidfile /dev/shm/kboot/pid-vm-vp-quantal-x86_64-4 -serial 
file:/dev/shm/kboot/serial-vm-vp-quantal-x86_64-4 -daemonize -display none 
-monitor null 





Thanks,
Kernel Test Robot
#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 4.5.0-rc1 Kernel Configuration
#
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_PERF_EVENTS_INTEL_UNCORE=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_KASAN_SHADOW_OFFSET=0xdc00

Re: [PATCH/RFC] mm/debug_pagealloc: enable it by default

2016-01-25 Thread Joonsoo Kim
On Mon, Jan 25, 2016 at 08:51:56PM +0100, Christian Borntraeger wrote:
> On 01/25/2016 08:38 PM, Dave Jones wrote:
> >  Content preview:  On Mon, Jan 25, 2016 at 02:22:10PM -0500, Dave Jones 
> > wrote:
> > > > A default mode would be ok for me as it makes things obvious. Will 
> > send
> > > > a patch. > > The messaging around changing a default like this was 
> > really
> > poor. > When we do behaviour changes like this, we typically rename the 
> > CONFIG
> > option > to make it obvious that things aren't as they used to be. 
> > [...] 
> > 
> >  Content analysis details:   (-2.9 points, 5.0 required)
> > 
> >   pts rule name  description
> >   -- 
> > --
> >  -1.0 ALL_TRUSTEDPassed through trusted hosts only via SMTP
> >  -1.9 BAYES_00   BODY: Bayes spam probability is 0 to 1%
> >  [score: 0.]
> > X-ZLA-Header: unknown; 0
> > X-ZLA-DetailInfo: BA=6.4114; NDR=6.0001; ZLA=6.0005; 
> > ZF=6.0009; ZB=6.; ZH=6.; ZP=6.; ZU=6.0002; 
> > UDB=6.00294159; UTC=2016-01-25 19:38:24
> > x-cbid: 16012519-0041---074865D5
> > X-IBM-ISS-SpamDetectors: Score=0.40962; FLB=0; FLI=0; BY=0; FL=0; FP=0; 
> > FZ=0;
> >  HX=0; KW=0; PH=0; RB=0; SC=0.40962; ST=0; TS=0; UL=0; ISC=
> > X-IBM-ISS-DetailInfo:  BY=3.4831; HX=3.0240; KW=3.0007;
> >  PH=3.0004; SC=3.0137; SDB=6.00650474; UDB=6.00294159; 
> > UTC=2016-01-25
> >  19:38:24
> > X-TM-AS-MML: disable
> > 
> > On Mon, Jan 25, 2016 at 02:22:10PM -0500, Dave Jones wrote:
> > 
> >  >  > A default mode would be ok for me as it makes things obvious. Will 
> > send
> >  >  > a patch.
> >  > 
> >  > The messaging around changing a default like this was really poor.
> >  > When we do behaviour changes like this, we typically rename the CONFIG 
> > option
> >  > to make it obvious that things aren't as they used to be.
> > 
> > Looking at this closer, shouldn't the original diff to make this runtime
> > have also changed the x86 implementation details in arch/x86/mm/pageattr.c ?
> > Even when we don't boot with the enable flag, we're doing the "split 2M 
> > page into 4Ks"
> > thing.  It looks like a s/debug_pagealloc/debug_pagealloc_enabled()/ might
> > do the right thing maybe ?
> 
> I have some patches ready, that fix the identity mapping for s390 and x86. 
> sparc
> is hard to do as it allocates the TSB very early. Will send around what I 
> have soon.

Thanks for taking care of this.

I searched other sites using "#ifdef CONFIG_DEBUG_PAGEALLOC" and found
that we can do more. Maybe, powerpc and tile also can get benefit from such
a change. And, could you handle vmap_debug_free_range() and
get_freepointer_safe(), too?

And, when debug_pagealloc is disabled, it's better not to print
DEBUG_PAGEALLOC in some error logs.

Thanks.


[PATCH 0/2 v2] set_memory_xx fixes

2016-01-25 Thread mika.penttila
Recent changes (4.4.0+) in module loader triggered oops on ARM.

The module in question is in-tree module :
drivers/misc/ti-st/st_drv.ko

The BUG is here :

[ 53.638335] [ cut here ]
[ 53.642967] kernel BUG at mm/memory.c:1878!
[ 53.647153] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP ARM
[ 53.652987] Modules linked in:
[ 53.656061] CPU: 0 PID: 483 Comm: insmod Not tainted 4.4.0 #3
[ 53.661808] Hardware name: Freescale i.MX6 Quad/DualLite (Device Tree)
[ 53.668338] task: a989d400 ti: 9e6a2000 task.ti: 9e6a2000
[ 53.673751] PC is at apply_to_page_range+0x204/0x224
[ 53.678723] LR is at change_memory_common+0x90/0xdc
[ 53.683604] pc : [<800ca0ec>] lr : [<8001d668>] psr: 600b0013
[ 53.683604] sp : 9e6a3e38 ip : 8001d6b4 fp : 7f0042fc
[ 53.695082] r10:  r9 : 9e6a3e90 r8 : 0080
[ 53.700309] r7 :  r6 : 7f008000 r5 : 7f008000 r4 : 7f008000
[ 53.706837] r3 : 8001d5a4 r2 : 7f008000 r1 : 7f008000 r0 : 80b8d3c0
[ 53.713368] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 53.720504] Control: 10c5387d Table: 2e6b804a DAC: 0055
[ 53.726252] Process insmod (pid: 483, stack limit = 0x9e6a2210)
[ 53.732173] Stack: (0x9e6a3e38 to 0x9e6a4000)
[ 53.736532] 3e20: 7f007fff 7f008000
[ 53.744714] 3e40: 80b8d3c0 80b8d3c0  7f007000 7f00426c 7f008000 
 7f008000
[ 53.752895] 3e60: 7f004140 7f008000  0080   
7f0042fc 8001d668
[ 53.761076] 3e80: 9e6a3e90  8001d6b4 7f00426c 0080  
9e6a3f58 7f004140
[ 53.769257] 3ea0: 7f004240 7f00414c  8008bbe0  7f00 
 
[ 53.777438] 3ec0: a8b12f00 0001cfd4 7f004250 7f004240 80b8159c  
00e0 7f0042fc
[ 53.785619] 3ee0: c183d000 74f8 18fd  0b3c  
 7f002024
[ 53.793800] 3f00: 0002      
 
[ 53.801980] 3f20:     0040  
0003 0001cfd4
[ 53.810161] 3f40: 017b 8000f7e4 9e6a2000  0002 8008c498 
c183d000 74f8
[ 53.818342] 3f60: c1841588 c1841409 c1842950 5000 52a0  
 
[ 53.826523] 3f80: 0023 0024 001a 001e 0016  
 
[ 53.834703] 3fa0: 003e3d60 8000f640   0003 0001cfd4 
 003e3d60
[ 53.842884] 3fc0:   003e3d60 017b 003e3d20 7eabc9d4 
76f2c000 0002
[ 53.851065] 3fe0: 7eabc990 7eabc980 00016320 76e81d00 600b0010 0003 
 
[ 53.859256] [<800ca0ec>] (apply_to_page_range) from [<8001d668>] 
(change_memory_common+0x90/0xdc)
[ 53.868139] [<8001d668>] (change_memory_common) from [<8008bbe0>] 
(load_module+0x194c/0x2068)
[ 53.876671] [<8008bbe0>] (load_module) from [<8008c498>] 
(SyS_finit_module+0x64/0x74)
[ 53.884512] [<8008c498>] (SyS_finit_module) from [<8000f640>] 
(ret_fast_syscall+0x0/0x34)
[ 53.892694] Code: e0834104 eabc e51a1008 eaac (e7f001f2)
[ 53.898792] ---[ end trace fe43fc78ebde29a3 ]---


apply_to_page_range gets zero length resulting in triggering :

  BUG_ON(addr >= end)

This is regression and a consequence of changes in module section handling.

Fix by making arm and arm64 check for zero size update in 
change_memory_common(),
letting set_memory_xx(addr, 0); succeed. This makes behavior similar to x86.

Also, BUG_ON() in apply_to_page_range is too strong, make it WARN_ON()
and return -EINVAL instead. There may be other caller expecting !size
to succeed.

v2:
  - drop patch 1/4 for the bounds check, it has been submitted before
  - merge arm/arm64 changes into one patch

--Mika

[PATCH 1/2] arm, arm64: change_memory_common with numpages == 0 should be no-op.
[PATCH 2/2] make apply_to_page_range() more robust.

 arch/arm/mm/pageattr.c   | 3 +++
 arch/arm64/mm/pageattr.c | 3 +++
 mm/memory.c  | 4 +++-
 3 files changed, 9 insertions(+), 1 deletion(-)





Re: [PATCH v5 3/5] mfd: hi655x: Add hi665x pmic driver

2016-01-25 Thread chenfeng


On 2016/1/25 22:22, Lee Jones wrote:
> On Mon, 11 Jan 2016, Chen Feng wrote:
> 
>> Add pmic mfd driver to support hisilicon hi665x.
> 
> PMIC MFD
> 

ok.

>> Signed-off-by: Chen Feng 
>> Signed-off-by: Fei Wang 
>> Signed-off-by: Xinwei Kong 
>> ---
>>  drivers/mfd/Kconfig |  10 +++
>>  drivers/mfd/Makefile|   1 +
>>  drivers/mfd/hi655x-pmic.c   | 169 
>> 
>>  include/linux/mfd/hi655x-pmic.h |  56 +
>>  4 files changed, 236 insertions(+)
>>  create mode 100644 drivers/mfd/hi655x-pmic.c
>>  create mode 100644 include/linux/mfd/hi655x-pmic.h
>>
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index 4d92df6..299d972 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -284,6 +284,16 @@ config MFD_HI6421_PMIC
>>menus in order to enable them.
>>We communicate with the Hi6421 via memory-mapped I/O.
>>  
>> +config MFD_HI655X_PMIC
>> +tristate "HiSilicon Hi655X series PMU/Codec IC"
>> +depends on ARCH_HISI || (COMPILE_TEST && ARM64)
> 
> Why not just COMPILE_TEST?

ok, the V6 already just COMPILE_TEST.
> 
>> +depends on OF
> 
> So this will not COMPILE_TEST if OF is not enabled.
> 
>> +select MFD_CORE
>> +select REGMAP_MMIO
>> +select REGMAP_IRQ
>> +help
>> +  Select this option to enable Hisilicon hi655x series pmic driver.
>> +
>>  config HTC_EGPIO
>>  bool "HTC EGPIO support"
>>  depends on GPIOLIB && ARM
>> diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
>> index a8b76b8..6a7b0e1 100644
>> --- a/drivers/mfd/Makefile
>> +++ b/drivers/mfd/Makefile
>> @@ -186,6 +186,7 @@ obj-$(CONFIG_MFD_STW481X)+= stw481x.o
>>  obj-$(CONFIG_MFD_IPAQ_MICRO)+= ipaq-micro.o
>>  obj-$(CONFIG_MFD_MENF21BMC) += menf21bmc.o
>>  obj-$(CONFIG_MFD_HI6421_PMIC)   += hi6421-pmic-core.o
>> +obj-$(CONFIG_MFD_HI655X_PMIC)   += hi655x-pmic.o
>>  obj-$(CONFIG_MFD_DLN2)  += dln2.o
>>  obj-$(CONFIG_MFD_RT5033)+= rt5033.o
>>  obj-$(CONFIG_MFD_SKY81452)  += sky81452.o
>> diff --git a/drivers/mfd/hi655x-pmic.c b/drivers/mfd/hi655x-pmic.c
>> new file mode 100644
>> index 000..aab18f7
>> --- /dev/null
>> +++ b/drivers/mfd/hi655x-pmic.c
>> @@ -0,0 +1,169 @@
>> +/*
>> + * Device driver for regulators in hi655x IC
> 
> We know it's a device driver.  And I hope it's not a regulator driver.
> 
ok, I will change the name.
>> + * Copyright (c) 2016 Hisilicon.
>> + *
>> + * Chen Feng 
>> + * Fei  Wang 
> 
> Author(s): 
> 
ok.
>> + * This program is free software; you can redistribute it and/or modify
>> + * it under the terms of the GNU General Public License version 2 as
>> + * published by the Free Software Foundation.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
> 
> Alphabetical please.
> 
ok.
>> +static const struct mfd_cell hi655x_pmic_devs[] = {
>> +{ .name = "hi655x-regulator", },
>> +};
> 
> What other devices are there?
> 

These patches only add regulator,the RTC and Power-key
will be added later.

So I just list the regulator this time.

>> +static const struct regmap_irq hi655x_irqs[] = {
>> +{ .reg_offset = 0, .mask = OTMP_D1R_INT },
>> +{ .reg_offset = 0, .mask = VSYS_2P5_R_INT },
>> +{ .reg_offset = 0, .mask = VSYS_UV_D3R_INT },
>> +{ .reg_offset = 0, .mask = VSYS_6P0_D200UR_INT },
>> +{ .reg_offset = 0, .mask = PWRON_D4SR_INT },
>> +{ .reg_offset = 0, .mask = PWRON_D20F_INT },
>> +{ .reg_offset = 0, .mask = PWRON_D20R_INT },
>> +{ .reg_offset = 0, .mask = RESERVE_INT },
>> +};
>> +
>> +static const struct regmap_irq_chip hi655x_irq_chip = {
>> +.name = "hi655x-pmic",
>> +.irqs = hi655x_irqs,
>> +.num_regs = 1,
>> +.num_irqs = ARRAY_SIZE(hi655x_irqs),
>> +.status_base = HI655X_IRQ_STAT_BASE,
>> +.mask_base = HI655X_IRQ_MASK_BASE,
>> +};
>> +
>> +static unsigned int hi655x_pmic_get_version(struct hi655x_pmic *pmic)
>> +{
>> +u32 val;
>> +
>> +regmap_read(pmic->regmap,
>> +HI655X_BUS_ADDR(HI655X_VER_REG), );
>> +
>> +return val;
>> +}
> 
> This is a small function that you only use once.
> 
> Probably better just to call regmap_read() directly from below.
> 
ok.

>> +static struct regmap_config hi655x_regmap_config = {
>> +.reg_bits = 32,
>> +.reg_stride = HI655X_STRIDE,
>> +.val_bits = 8,
>> +.max_register = HI655X_BUS_ADDR(0xFFF),
>> +};
>> +
>> +static void hi655x_local_irq_clear(struct regmap *map)
>> +{
>> +int i;
>> +
>> +regmap_write(map, HI655X_ANA_IRQM_BASE, HI655X_IRQ_CLR);
>> +for (i = 0; i < HI655X_IRQ_ARRAY; i++) {
>> +regmap_write(map, HI655X_IRQ_STAT_BASE + i * HI655X_STRIDE,
>> + HI655X_IRQ_CLR);
>> +}
>> +}
>> +
>> +static int 

[PATCH 2/2 v2] make apply_to_page_range() more robust.

2016-01-25 Thread mika.penttila
From: Mika Penttilä 

Now the arm/arm64 don't trigger this BUG_ON() any more,
but WARN_ON() is here enough to catch buggy callers
but still let potential other !size callers pass with warning.

Signed-off-by: Mika Penttilä mika.pentt...@nextfour.com
Reviewed-by: Pekka Enberg 
Acked-by: David Rientjes 

---
 mm/memory.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/mm/memory.c b/mm/memory.c
index 30991f8..9178ee6 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1871,7 +1871,9 @@ int apply_to_page_range(struct mm_struct *mm, unsigned 
long addr,
unsigned long end = addr + size;
int err;
 
-   BUG_ON(addr >= end);
+   if (WARN_ON(addr >= end))
+   return -EINVAL;
+
pgd = pgd_offset(mm, addr);
do {
next = pgd_addr_end(addr, end);
-- 
1.9.1



[PATCH 1/2 v2] arm, arm64: change_memory_common with numpages == 0 should be no-op.

2016-01-25 Thread mika.penttila
From: Mika Penttilä 

This makes the caller set_memory_xx() consistent with x86.

arm64 part is rebased on 4.5.0-rc1 with Ard's patch
 lkml.kernel.org/g/<1453125665-26627-1-git-send-email-ard.biesheu...@linaro.org>
applied.

Signed-off-by: Mika Penttilä mika.pentt...@nextfour.com
Reviewed-by: Laura Abbott 
Acked-by: David Rientjes 

---
 arch/arm/mm/pageattr.c   | 3 +++
 arch/arm64/mm/pageattr.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/arch/arm/mm/pageattr.c b/arch/arm/mm/pageattr.c
index cf30daf..d19b1ad 100644
--- a/arch/arm/mm/pageattr.c
+++ b/arch/arm/mm/pageattr.c
@@ -49,6 +49,9 @@ static int change_memory_common(unsigned long addr, int 
numpages,
WARN_ON_ONCE(1);
}
 
+   if (!numpages)
+   return 0;
+
if (start < MODULES_VADDR || start >= MODULES_END)
return -EINVAL;
 
diff --git a/arch/arm64/mm/pageattr.c b/arch/arm64/mm/pageattr.c
index 1360a02..b582fc2 100644
--- a/arch/arm64/mm/pageattr.c
+++ b/arch/arm64/mm/pageattr.c
@@ -53,6 +53,9 @@ static int change_memory_common(unsigned long addr, int 
numpages,
WARN_ON_ONCE(1);
}
 
+   if (!numpages)
+   return 0;
+
/*
 * Kernel VA mappings are always live, and splitting live section
 * mappings into page mappings may cause TLB conflicts. This means
-- 
1.9.1



Re: [PATCH v6 03/12] usb: dbc: probe and setup xhci debug capability

2016-01-25 Thread Greg Kroah-Hartman
On Tue, Jan 26, 2016 at 12:14:16PM +0800, Lu Baolu wrote:
> xHCI debug capability (DbC) is an optional functionality provided
> by an xHCI host controller. Software learns this capability by
> walking through the extended capability list in mmio of the host.
> 
> This patch introduces the code to probe and initialize the debug
> capability hardware during early boot. With hardware initialization
> done, the debug target (system under debug which has DbC enabled)
> will present a debug device through the debug port. The debug device
> is fully compliant with the USB framework and provides the equivalent
> of a very high performance (USB3) full-duplex serial link between the
> debug host and target.
> 
> Signed-off-by: Lu Baolu 
> ---
>  MAINTAINERS  |   7 +
>  arch/x86/Kconfig.debug   |  12 +
>  drivers/usb/early/Makefile   |   1 +

Why did you make a whole new subdirectory, just for your one driver?
Please don't do that, just put it in the host controller directory where
it belongs...



Re: [PATCH v2 1/4] dt-bindings: power: reset: add document for reboot-mode driver

2016-01-25 Thread Andy Yan

Hi Rob:

On 2016年01月26日 01:11, Rob Herring wrote:

On Thu, Jan 21, 2016 at 02:27:57PM +0800, Andy Yan wrote:

Hi Rob:
thanks for your review.
On 2016年01月21日 02:28, Rob Herring wrote:

On Tue, Jan 12, 2016 at 07:29:49PM +0800, Andy Yan wrote:

add device tree binding document for reboot-mode driver

Signed-off-by: Andy Yan 

---

Changes in v2: None
Changes in v1: None

  .../bindings/power/reset/reboot-mode.txt   | 41 +
  .../bindings/power/reset/syscon-reboot-mode.txt| 52 ++
  2 files changed, 93 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/power/reset/reboot-mode.txt
  create mode 100644 
Documentation/devicetree/bindings/power/reset/syscon-reboot-mode.txt

diff --git a/Documentation/devicetree/bindings/power/reset/reboot-mode.txt 
b/Documentation/devicetree/bindings/power/reset/reboot-mode.txt
new file mode 100644
index 000..81d9f66
--- /dev/null
+++ b/Documentation/devicetree/bindings/power/reset/reboot-mode.txt
@@ -0,0 +1,41 @@
+Generic reboot mode core map driver

[...]


+   compatible = "syscon-reboot-mode";
+   offset = <0x40>;

This doc by itself is a little confusing. For example, is a child of the
syscon node? I would remove offset (and perhaps compatible) from this
example.

Yes, is a child of a syscon mapped node. For example, Rockchip platform
use a register of PMU(rk3066/rk3288) or GRF(rk3036), PMU and GRF are aleady
mapped by syscon.
offset and compatible are used by write interface driver like
syscon-reboot-mode.c. If you don't like it appear in the core map doc, I
will move it to the syscon-reboot-mode.txt?

Yes, try to make this doc stand on its own. It will obviously be
incomplete lacking information on where in the DT it goes. So perhaps a
note stating reboot-mode node location is defined in platform specific
binding docs.


+
+   loader {
+   linux,mode = "loader";
+   loader,magic = ;
+   };

Sorry, my previous suggestion was not clear. I'm suggesting get rid of
the subnodes and just do properties like this:

loader = ;
maskrom = ;

That's the same amount of information unless node names and linux,mode
values are going to diverge. Do they need to? I can't see a reason.

 Because the command"linux,mode" and value"loader,magic" is vendor
specific. I don't know what commands and how many mode other platform will
use. So as John says in his reply, this sort of flexibility help us adapt
the driver to different hardware/system environments.

The only part of "reboot to fastboot" that is vendor specific would be
the magic value. While we can have custom modes, we should standardize
the common ones as much as possible. As I pointed out in my reply to
John, we can still support vendor specific modes with just a property.


Based your reply to John, I rebuild the code like bellow, I hope this
is what you mean.

DTS file:
reboot-mode {
compatible = "syscon-reboot-mode";
offset = <0x94>;
mode-normal = ;
mode-recovery = ;
mode-fastboot = ;
mode-loader = ;
mode-maskrom = ;
};


   driver:

#define PREFIX "mode-"

struct property *prop;
size_t len = strlen(PREFIX);
for_each_property_of_node(dev->of_node, prop) {
if (len > strlen(prop->name) || strncmp(prop->name, 
PREFIX, len))

continue;
info = devm_kzalloc(dev, sizeof(*info), GFP_KERNEL);
if (!info)
return -ENOMEM;
strcpy(info->mode, prop->name + len);
if (of_property_read_u32(dev->of_node, prop->name, 
>magic)) {
dev_err(dev, "reboot mode %s without magic 
number\n",

info->mode);
devm_kfree(dev, info);
continue;
}
list_add_tail(>list, >head);
}



We need to be clear what loader means. More specifically, it is boot
into bootloader shell.

 Actually, Rockchip platform will reboot into a bootloader download mode
with this command. This mode can download faster than maskrom download mode.

My point is proven. I assumed one thing and you meant something else.
Doesn't matter what the mode is, just needs to be clear.

Rob








Re: [PATCH v2] perf: Synchronously cleanup child events

2016-01-25 Thread Alexei Starovoitov
On Mon, Jan 25, 2016 at 10:04:10PM +0100, Peter Zijlstra wrote:
> On Mon, Jan 25, 2016 at 03:54:14PM +0100, Peter Zijlstra wrote:
> > Alexander, Alexei,
> > 
> > How about the below? That uses event->state == PERF_EVENT_STATE_EXIT to
> > indicate the event has been given up by its 'owner' and decouples us
> > from the actual event->owner logic.
> > 
> > This retains the event->owner and event->owner_list thing purely for the
> > prclt(.option = PR_TASK_PERF_EVENTS_{EN,DIS}ABLE) calls, but does give
> > us strict 'owner' semantics in that:
> > 
> >   struct perf_event *my_event = perf_event_create_kernel_counter();
> > 
> >   /* ... */
> > 
> >   perf_event_release_kernel(my_event);
> > 
> > Or
> > 
> >   int fd = sys_perf_event_open(...);
> > 
> >   close(fd); /* last, calls fops::release */
> > 
> > Will destroy the event dead. event::refcount will 'retain' the object
> > but it will become non functional and is strictly meant as a temporal
> > existence guarantee (for when RCU isn't good enough).
> > 
> > So this should restore the scm_rights case, which preserves the fd but
> > could result in not having event->owner (and therefore being removed
> > from its owner_list), which is fine.
> > 
> > BPF still needs to get fixed to use filedesc references instead.
> 
> Still no BPF, but this one actually 'works', as in it doesn't have the
> blatant exit races and has survived a few hours of runtime.
> 
> ---
>  include/linux/perf_event.h |3 
>  kernel/events/core.c   |  304 
> ++---
>  2 files changed, 150 insertions(+), 157 deletions(-)

I think I understand what you're trying to do and
the patch looks good to me.
As far as BPF side I did the following...
does it match the model you outlined above?
I did basic testing and it looks fine.

Subject: [PATCH ] perf,bpf: convert perf_event_array to use struct file

Signed-off-by: Alexei Starovoitov 
---
 include/linux/perf_event.h |  4 ++--
 kernel/bpf/arraymap.c  | 21 +++--
 kernel/events/core.c   | 20 
 kernel/trace/bpf_trace.c   | 14 ++
 4 files changed, 31 insertions(+), 28 deletions(-)

diff --git a/include/linux/perf_event.h b/include/linux/perf_event.h
index f9828a48f16a..df275020fde9 100644
--- a/include/linux/perf_event.h
+++ b/include/linux/perf_event.h
@@ -729,7 +729,7 @@ extern int perf_event_init_task(struct task_struct *child);
 extern void perf_event_exit_task(struct task_struct *child);
 extern void perf_event_free_task(struct task_struct *task);
 extern void perf_event_delayed_put(struct task_struct *task);
-extern struct perf_event *perf_event_get(unsigned int fd);
+extern struct file *perf_event_get(unsigned int fd);
 extern const struct perf_event_attr *perf_event_attrs(struct perf_event 
*event);
 extern void perf_event_print_debug(void);
 extern void perf_pmu_disable(struct pmu *pmu);
@@ -1070,7 +1070,7 @@ static inline int perf_event_init_task(struct task_struct 
*child) { return 0; }
 static inline void perf_event_exit_task(struct task_struct *child) { }
 static inline void perf_event_free_task(struct task_struct *task)  { }
 static inline void perf_event_delayed_put(struct task_struct *task){ }
-static inline struct perf_event *perf_event_get(unsigned int fd)   { 
return ERR_PTR(-EINVAL); }
+static inline struct file *perf_event_get(unsigned int fd) { return 
ERR_PTR(-EINVAL); }
 static inline const struct perf_event_attr *perf_event_attrs(struct perf_event 
*event)
 {
return ERR_PTR(-EINVAL);
diff --git a/kernel/bpf/arraymap.c b/kernel/bpf/arraymap.c
index b0799bced518..89ebbc4d1164 100644
--- a/kernel/bpf/arraymap.c
+++ b/kernel/bpf/arraymap.c
@@ -291,10 +291,13 @@ static void *perf_event_fd_array_get_ptr(struct bpf_map 
*map, int fd)
 {
struct perf_event *event;
const struct perf_event_attr *attr;
+   struct file *file;
 
-   event = perf_event_get(fd);
-   if (IS_ERR(event))
-   return event;
+   file = perf_event_get(fd);
+   if (IS_ERR(file))
+   return file;
+
+   event = file->private_data;
 
attr = perf_event_attrs(event);
if (IS_ERR(attr))
@@ -304,24 +307,22 @@ static void *perf_event_fd_array_get_ptr(struct bpf_map 
*map, int fd)
goto err;
 
if (attr->type == PERF_TYPE_RAW)
-   return event;
+   return file;
 
if (attr->type == PERF_TYPE_HARDWARE)
-   return event;
+   return file;
 
if (attr->type == PERF_TYPE_SOFTWARE &&
attr->config == PERF_COUNT_SW_BPF_OUTPUT)
-   return event;
+   return file;
 err:
-   perf_event_release_kernel(event);
+   fput(file);
return ERR_PTR(-EINVAL);
 }
 
 static void perf_event_fd_array_put_ptr(void *ptr)
 {
-   struct perf_event *event = ptr;
-
-   perf_event_release_kernel(event);
+   fput((struct file *)ptr);
 }
 
 

Re: [linux-review:James-Hogan/kbuild-Remove-stale-asm-generic-wrappers/20160119-183642] d979f99e9cc14e2667e9b6e268db695977e4197a BUILD DONE

2016-01-25 Thread Fengguang Wu
On Tue, Jan 26, 2016 at 01:30:50PM +0800, Fengguang Wu wrote:
> Hi Arnd,
> 
> Sorry for the delay! I lost access to my email account for some week.
> 
> On Tue, Jan 19, 2016 at 03:26:16PM +0100, Arnd Bergmann wrote:
> > On Tuesday 19 January 2016 19:27:55 kbuild test robot wrote:
> > > arm   allnoconfig
> > > arm at91_dt_defconfig
> > > arm  at_hdmac
> > > armep93xx
> > > arm   imx_v6_v7_defconfig
> > > arm  iop-adma
> > > arm  marzen_defconfig
> > > arm  prima2_defconfig
> > > armsa1100
> > > arm   samsung
> > > armsh
> > > arm   spear13xx_defconfig
> > > 
> > 
> > Hi Fengguang,
> > 
> > Sorry for hijacking this thread. I have never seen the list of arm 
> > defconfigs
> > you are building before, and it seems to be a surprising selection, as a 
> > number
> > of platforms (ep93xx, iop, sa1100, spear13xx) are rather obscure, but the
> > configurations that I tend to use most (multi_v7_defconfig, 
> > multi_v5_defconfig,
> > allmodconfig) are not included.
> > 
> > Do you always build the same set of configurations, or is this a different
> > each time?
> 
> There are a fixed set of config files for fast build tests (which I
> selected randomly, feel free to ask me to change the list to more
> reasonable ones):
> 
>   arm-allnoconfig
>   arm-at91_dt_defconfig
>   arm-at_hdmac
>   arm-ep93xx
>   arm-imx_v6_v7_defconfig
>   arm-iop-adma
>   arm-marzen_defconfig
>   arm-prima2_defconfig
>   arm-sa1100
>   arm-samsung
>   arm-sh
>   arm-spear13xx_defconfig

And there is another set of best effort configs whose priority is
in-between the above list and the arch/*/configs/* ones.

arm-arm5
arm-arm67
arm-mmp
arm-omap2plus_defconfig
arm-s3c2410_defconfig
arm-tegra_defconfig

Thanks,
Fengguang

> The more configs included in arch/*/configs will be tested in a more
> slow pace. So not included in this email does not mean they are not
> tested -- they are likely not quick enough to catch this notification
> email.
> 
> > Can you always include the three I mentioned?
> 
> Sure.
> 
> Thanks,
> Fengguang


Re: [v3,11/41] mips: reuse asm-generic/barrier.h

2016-01-25 Thread Paul E. McKenney
On Mon, Jan 25, 2016 at 06:02:34PM +, Will Deacon wrote:
> Hi Paul,
> 
> On Fri, Jan 15, 2016 at 09:39:12AM -0800, Paul E. McKenney wrote:
> > On Fri, Jan 15, 2016 at 09:55:54AM +0100, Peter Zijlstra wrote:
> > > On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote:
> > > > So smp_mb() provides transitivity, as do pairs of smp_store_release()
> > > > and smp_read_acquire(), 
> > > 
> > > But they provide different grades of transitivity, which is where all
> > > the confusion lays.
> > > 
> > > smp_mb() is strongly/globally transitive, all CPUs will agree on the 
> > > order.
> > > 
> > > Whereas the RCpc release+acquire is weakly so, only the two cpus
> > > involved in the handover will agree on the order.
> > 
> > Good point!
> > 
> > Using grace periods in place of smp_mb() also provides strong/global
> > transitivity, but also insanely high latencies.  ;-)
> > 
> > The patch below updates Documentation/memory-barriers.txt to define
> > local vs. global transitivity.  The corresponding ppcmem litmus test
> > is included below as well.
> > 
> > Should we start putting litmus tests for the various examples
> > somewhere, perhaps in a litmus-tests directory within each participating
> > architecture?  I have a pile of powerpc-related litmus tests on my laptop,
> > but they probably aren't doing all that much good there.
> 
> I too would like to have the litmus tests in the kernel so that we can
> refer to them from memory-barriers.txt. Ideally they wouldn't be targetted
> to a particular arch, however.

Agreed.  Working on it...

> > PPC local-transitive
> > ""
> > {
> > 0:r1=1; 0:r2=u; 0:r3=v; 0:r4=x; 0:r5=y; 0:r6=z;
> > 1:r1=1; 1:r2=u; 1:r3=v; 1:r4=x; 1:r5=y; 1:r6=z;
> > 2:r1=1; 2:r2=u; 2:r3=v; 2:r4=x; 2:r5=y; 2:r6=z;
> > 3:r1=1; 3:r2=u; 3:r3=v; 3:r4=x; 3:r5=y; 3:r6=z;
> > }
> >  P0   | P1   | P2   | P3   ;
> >  lwz r9,0(r4) | lwz r9,0(r5) | lwz r9,0(r6) | stw r1,0(r3) ;
> >  lwsync   | lwsync   | lwsync   | sync ;
> >  stw r1,0(r2) | lwz r8,0(r3) | stw r1,0(r7) | lwz r9,0(r2) ;
> >  lwsync   | lwz r7,0(r2) |  |  ;
> >  stw r1,0(r5) | lwsync   |  |  ;
> >   | stw r1,0(r6) |  |  ;
> > exists
> > (* (0:r9=0 /\ 1:r9=1 /\ 2:r9=1 /\ 1:r8=0 /\ 3:r9=0) *)
> > (* (0:r9=1 /\ 1:r9=1 /\ 2:r9=1) *)
> > (* (0:r9=0 /\ 1:r9=1 /\ 2:r9=1 /\ 1:r7=0) *)
> > (0:r9=0 /\ 1:r9=1 /\ 2:r9=1 /\ 1:r7=0)
> 
> i.e. we should rewrite this using READ_ONCE/WRITE_ONCE and smp_mb() etc.

Yep!

> > 
> > 
> > commit 2cb4e83a1b5c89c8e39b8a64bd89269d05913e41
> > Author: Paul E. McKenney 
> > Date:   Fri Jan 15 09:30:42 2016 -0800
> > 
> > documentation: Distinguish between local and global transitivity
> > 
> > The introduction of smp_load_acquire() and smp_store_release() had
> > the side effect of introducing a weaker notion of transitivity:
> > The transitivity of full smp_mb() barriers is global, but that
> > of smp_store_release()/smp_load_acquire() chains is local.  This
> > commit therefore introduces the notion of local transitivity and
> > gives an example.
> > 
> > Reported-by: Peter Zijlstra 
> > Reported-by: Will Deacon 
> > Signed-off-by: Paul E. McKenney 
> > 
> > diff --git a/Documentation/memory-barriers.txt 
> > b/Documentation/memory-barriers.txt
> > index c66ba46d8079..d8109ed99342 100644
> > --- a/Documentation/memory-barriers.txt
> > +++ b/Documentation/memory-barriers.txt
> > @@ -1318,8 +1318,82 @@ or a level of cache, CPU 2 might have early access 
> > to CPU 1's writes.
> >  General barriers are therefore required to ensure that all CPUs agree
> >  on the combined order of CPU 1's and CPU 2's accesses.
> >  
> > -To reiterate, if your code requires transitivity, use general barriers
> > -throughout.
> > +General barriers provide "global transitivity", so that all CPUs will
> > +agree on the order of operations.  In contrast, a chain of release-acquire
> > +pairs provides only "local transitivity", so that only those CPUs on
> > +the chain are guaranteed to agree on the combined order of the accesses.
> 
> Thanks for having a go at this. I tried defining something axiomatically,
> but got stuck pretty quickly. In my scheme, I used "data-directed
> transitivity" instead of "local transitivity", since the latter seems to
> be a bit of a misnomer.

I figured that "local" meant local to the CPUs participating in the
release-acquire chain.  As opposed to smp_mb() chains where the ordering
is "global" as in visible to all CPUs, whether on the chain or not.
Does that help?

> > +For example, switching to C code in deference to Herman Hollerith:
> > +
> > +   int u, v, x, y, z;
> > +
> > +   void cpu0(void)
> > +   {
> > +   r0 = 

[PATCH] mn10300: Wire up mn10300_dma_supported

2016-01-25 Thread Guenter Roeck
From: Guenter Roeck 

Commit f151341ca00e ("mn10300: convert to dma_map_ops") declares
mn10300_dma_supported, but does not wire it up. This results in
the following build warning.

arch/mn10300/mm/dma-alloc.c: warning:
'mn10300_dma_supported' defined but not used

Fixes: f151341ca00e ("mn10300: convert to dma_map_ops")
Cc: Christoph Hellwig 
Signed-off-by: Guenter Roeck 
---
 arch/mn10300/mm/dma-alloc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/mn10300/mm/dma-alloc.c b/arch/mn10300/mm/dma-alloc.c
index 8842394cb49a..5ff49d67f55a 100644
--- a/arch/mn10300/mm/dma-alloc.c
+++ b/arch/mn10300/mm/dma-alloc.c
@@ -128,4 +128,5 @@ struct dma_map_ops mn10300_dma_ops = {
.map_sg = mn10300_dma_map_sg,
.sync_single_for_device = mn10300_dma_sync_single_for_device,
.sync_sg_for_device = mn10300_dma_sync_sg_for_device,
+   .dma_supported  = mn10300_dma_supported,
 };
-- 
2.1.4



Re: [PATCH] media: platform: exynos4-is: media-dev: Add missing of_node_put

2016-01-25 Thread Krzysztof Kozlowski
On 26.01.2016 15:24, Julia Lawall wrote:
> 
> 
> On Tue, 26 Jan 2016, Krzysztof Kozlowski wrote:
> 
>> On 26.01.2016 00:21, Amitoj Kaur Chawla wrote:
>>> for_each_available_child_of_node and for_each_child_of_node perform an
>>> of_node_get on each iteration, so to break out of the loop an of_node_put is
>>> required.
>>>
>>> Found using Coccinelle. The simplified version of the semantic patch
>>> that is used for this is as follows:
>>>
>>> // 
>>> @@
>>> local idexpression n;
>>> expression e,r;
>>> @@
>>>
>>>  for_each_available_child_of_node(r,n) {
>>>...
>>> (
>>>of_node_put(n);
>>> |
>>>e = n
>>> |
>>> +  of_node_put(n);
>>> ?  break;
>>> )
>>>...
>>>  }
>>> ... when != n
>>> // 
>>
>> Patch iselft looks correct but why are you pasting coccinelle script
>> into the message?
>>
>> The script is already present in Linux kernel:
>> scripts/coccinelle/iterators/device_node_continue.cocci
> 
> I don't think so.  The continue one takes care of the case where there is 
> an extraneous of_node_put before a continue, not a missing one before a 
> break.  But OK to drop it if it doesn't seem useful.
> 
> julia

You are right - this is not covered by that cocci patch... but I think
is covered by scripts/coccinelle/iterators/fen.cocci, isn't it?

BR,
Krzysztof

> 
>> This just extends the commit message without any meaningful data so with
>> removal of coccinelle script above:
>> Reviewed-by: Krzysztof Kozlowski 
>>
>> Best regards,
>> Krzysztof
>>
>>>
>>> Signed-off-by: Amitoj Kaur Chawla 
>>> ---
>>>  drivers/media/platform/exynos4-is/media-dev.c | 12 +---
>>>  1 file changed, 9 insertions(+), 3 deletions(-)



[PATCH v4 2/7] mtd: spi-nor: fsl-quadspi: add support for ls1021a

2016-01-25 Thread Yuan Yao
LS1021a also support Freescale Quad SPI controller.
Add fsl-quadspi support for ls1021a chip and make SPI_FSL_QUADSPI
selectable for LS1021A SOC hardwares.

Signed-off-by: Yuan Yao 
Acked-by: Han xu 
---
Changed in v4:
No changes.

Changed in v3:
No changes.

Changed in v2:
Update my email to 
---
 drivers/mtd/spi-nor/Kconfig   |  2 +-
 drivers/mtd/spi-nor/fsl-quadspi.c | 10 ++
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/mtd/spi-nor/Kconfig b/drivers/mtd/spi-nor/Kconfig
index 0dc9275..a28c278 100644
--- a/drivers/mtd/spi-nor/Kconfig
+++ b/drivers/mtd/spi-nor/Kconfig
@@ -30,7 +30,7 @@ config MTD_SPI_NOR_USE_4K_SECTORS
 
 config SPI_FSL_QUADSPI
tristate "Freescale Quad SPI controller"
-   depends on ARCH_MXC || COMPILE_TEST
+   depends on ARCH_MXC || SOC_LS1021A || COMPILE_TEST
depends on HAS_IOMEM
help
  This enables support for the Quad SPI controller in master mode.
diff --git a/drivers/mtd/spi-nor/fsl-quadspi.c 
b/drivers/mtd/spi-nor/fsl-quadspi.c
index 04e8a93..9ab2b51 100644
--- a/drivers/mtd/spi-nor/fsl-quadspi.c
+++ b/drivers/mtd/spi-nor/fsl-quadspi.c
@@ -213,6 +213,7 @@ enum fsl_qspi_devtype {
FSL_QUADSPI_IMX6SX,
FSL_QUADSPI_IMX7D,
FSL_QUADSPI_IMX6UL,
+   FSL_QUADSPI_LS1021A,
 };
 
 struct fsl_qspi_devtype_data {
@@ -258,6 +259,14 @@ static struct fsl_qspi_devtype_data imx6ul_data = {
   | QUADSPI_QUIRK_4X_INT_CLK,
 };
 
+static struct fsl_qspi_devtype_data ls1021a_data = {
+   .devtype = FSL_QUADSPI_LS1021A,
+   .rxfifo = 128,
+   .txfifo = 64,
+   .ahb_buf_size = 1024,
+   .driver_data = 0,
+};
+
 #define FSL_QSPI_MAX_CHIP  4
 struct fsl_qspi {
struct spi_nor nor[FSL_QSPI_MAX_CHIP];
@@ -812,6 +821,7 @@ static const struct of_device_id fsl_qspi_dt_ids[] = {
{ .compatible = "fsl,imx6sx-qspi", .data = (void *)_data, },
{ .compatible = "fsl,imx7d-qspi", .data = (void *)_data, },
{ .compatible = "fsl,imx6ul-qspi", .data = (void *)_data, },
+   { .compatible = "fsl,ls1021a-qspi", .data = (void *)_data, },
{ /* sentinel */ }
 };
 MODULE_DEVICE_TABLE(of, fsl_qspi_dt_ids);
-- 
2.1.0.27.g96db324



[PATCH v4 6/7] dts/ls2080a: update the DTS for QSPI and DSPI support

2016-01-25 Thread Yuan Yao
Signed-off-by: Yuan Yao 
---
Changed in v4:
No changes.

Changed in v3:
No changes.

Changed in v2:
Update my email to 
---
 arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts | 9 -
 arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi| 4 ++--
 2 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts 
b/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
index 4cb996d..e8801fa 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a-qds.dts
@@ -178,7 +178,14 @@
 
  {
status = "okay";
-   qflash0: s25fl008k {
+   flash0: s25fl256s1@0 {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "st,m25p80";
+   spi-max-frequency = <2000>;
+   reg = <0>;
+   };
+   flash2: s25fl256s1@2 {
#address-cells = <1>;
#size-cells = <1>;
compatible = "st,m25p80";
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi 
b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
index 2b23d03..65e612a 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
+++ b/arch/arm64/boot/dts/freescale/fsl-ls2080a.dtsi
@@ -318,7 +318,7 @@
 
dspi: dspi@210 {
status = "disabled";
-   compatible = "fsl,vf610-dspi";
+   compatible = "fsl,ls2080a-dspi", "fsl,ls2085a-dspi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x210 0x0 0x1>;
@@ -444,7 +444,7 @@
 
qspi: quadspi@20c {
status = "disabled";
-   compatible = "fsl,vf610-qspi";
+   compatible = "fsl,ls2080a-qspi", "fsl,ls1021a-qspi";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x0 0x20c 0x0 0x1>,
-- 
2.1.0.27.g96db324



[PATCH v4 5/7] Documentation: fsl-quadspi: Add fsl, ls2080a-qspi compatible string

2016-01-25 Thread Yuan Yao
new compatible string: "fsl,ls2080a-qspi".

Signed-off-by: Yuan Yao 
Acked-by: Rob Herring 
---
Changed in v4:
No changes.

Changed in v3:
Add the modifier for new compatible string like:
"fsl,ls2080a-qspi" followed by "fsl,ls1021a-qspi"

Changed in v2:
Update my email to 
---
 Documentation/devicetree/bindings/mtd/fsl-quadspi.txt | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt 
b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
index 00c587b..0df2f3a 100644
--- a/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
+++ b/Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
@@ -3,7 +3,9 @@
 Required properties:
   - compatible : Should be "fsl,vf610-qspi", "fsl,imx6sx-qspi",
 "fsl,imx7d-qspi", "fsl,imx6ul-qspi",
-"fsl,ls1021-qspi"
+"fsl,ls1021a-qspi"
+or
+"fsl,ls2080a-qspi" followed by "fsl,ls1021a-qspi"
   - reg : the first contains the register location and length,
   the second contains the memory mapping address and length
   - reg-names: Should contain the reg names "QuadSPI" and "QuadSPI-memory"
-- 
2.1.0.27.g96db324



[PATCH v6 04/12] usb: dbc: add support for Intel xHCI dbc quirk

2016-01-25 Thread Lu Baolu
On Intel platforms, if the debug target is connected with debug
host, enabling DCE bit in command register leads to a port hung
state. In the hung state, the host system will not see a port
connected status bit set. Hence debug target fails to be probed.

The state could be resolved by performing a port reset to the
debug port from the host xHCI. This patch introduces this work
around.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 52 
 include/linux/usb/xhci-dbc.h |  2 ++
 2 files changed, 54 insertions(+)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 254a0a8..41ce116 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -255,6 +255,8 @@ static void __iomem *xdbc_map_pci_mmio(u32 bus,
xdbcp->bar = bar;
xdbcp->xhci_base = base;
xdbcp->xhci_length = sz64;
+   xdbcp->vendor = read_pci_config_16(bus, dev, func, PCI_VENDOR_ID);
+   xdbcp->device = read_pci_config_16(bus, dev, func, PCI_DEVICE_ID);
 
if (length)
*length = sz64;
@@ -638,6 +640,52 @@ static int xdbc_mem_init(void)
return 0;
 }
 
+static void xdbc_reset_debug_port_callback(int cap_offset, void *data)
+{
+   u8 major;
+   u32 val, port_offset, port_count;
+   u32 cap_length;
+   void __iomem *ops_reg;
+   void __iomem *portsc;
+   int i;
+
+   val = readl(xdbcp->xhci_base + cap_offset);
+   major = (u8) XHCI_EXT_PORT_MAJOR(val);
+
+   /* only reset super-speed port */
+   if (major != 0x3)
+   return;
+
+   val = readl(xdbcp->xhci_base + cap_offset + 8);
+   port_offset = XHCI_EXT_PORT_OFF(val);
+   port_count = XHCI_EXT_PORT_COUNT(val);
+   xdbc_trace("Extcap Port offset %d count %d\n",
+   port_offset, port_count);
+
+   cap_length = readl(xdbcp->xhci_base) & 0xff;
+   ops_reg = xdbcp->xhci_base + cap_length;
+
+   port_offset--;
+   for (i = port_offset; i < (port_offset + port_count); i++) {
+   portsc = ops_reg + 0x400 + i * 0x10;
+   val = readl(portsc);
+   /* reset the port if CCS bit is cleared */
+   if (!(val & 0x1))
+   writel(val | (1 << 4), portsc);
+   }
+}
+
+static void xdbc_reset_debug_port(void)
+{
+   xdbc_walk_excap(xdbcp->bus,
+   xdbcp->dev,
+   xdbcp->func,
+   XHCI_EXT_CAPS_PROTOCOL,
+   false,
+   xdbc_reset_debug_port_callback,
+   NULL);
+}
+
 /*
  * xdbc_start: start DbC
  *
@@ -656,6 +704,10 @@ static int xdbc_start(void)
return -ENODEV;
}
 
+   /* reset port to avoid bus hang */
+   if (xdbcp->vendor == PCI_VENDOR_ID_INTEL)
+   xdbc_reset_debug_port();
+
/* wait for port connection */
if (handshake(>xdbc_reg->portsc, PORTSC_CCS,
PORTSC_CCS, 500, 100) < 0) {
diff --git a/include/linux/usb/xhci-dbc.h b/include/linux/usb/xhci-dbc.h
index 153fb87..fc0ef9a 100644
--- a/include/linux/usb/xhci-dbc.h
+++ b/include/linux/usb/xhci-dbc.h
@@ -128,6 +128,8 @@ struct xdbc_state {
u32 dev;
u32 func;
u8  bar;
+   u16 vendor;
+   u16 device;
void __iomem*xhci_base;
size_t  xhci_length;
 #defineXDBC_PCI_MAX_BUSES  256
-- 
2.1.4



[PATCH v6 06/12] usb: dbc: add bulk out and bulk in interfaces

2016-01-25 Thread Lu Baolu
This patch adds interfaces for bulk out and bulk in ops. These
interfaces could be used to implement early printk bootconsole
or hook to various system debuggers.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 373 +++
 include/linux/usb/xhci-dbc.h |  30 
 2 files changed, 403 insertions(+)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 6855048..f59c80ef 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -219,11 +219,21 @@ static void xdbc_dbg_dump_data(char *str)
xdbc_dbg_dump_string("String Descriptor:");
 }
 
+static void xdbc_dbg_dump_trb(struct xdbc_trb *trb, char *str)
+{
+   xdbc_trace("DBC trb: %s\n", str);
+   xdbc_trace("@%016llx %08x %08x %08x %08x\n", (u64)__pa(trb),
+   le32_to_cpu(trb->field[0]),
+   le32_to_cpu(trb->field[1]),
+   le32_to_cpu(trb->field[2]),
+   le32_to_cpu(trb->field[3]));
+}
 #else
 static inline void xdbc_trace(const char *fmt, ...) { }
 static inline void xdbc_dump_debug_buffer(void) { }
 static inline void xdbc_dbg_dump_regs(char *str) { }
 static inline void xdbc_dbg_dump_data(char *str) { }
+static inline void xdbc_dbg_dump_trb(struct xdbc_trb *trb, char *str) { }
 #endif /* DBC_DEBUG */
 
 /*
@@ -334,6 +344,7 @@ static void *xdbc_get_page(dma_addr_t *dma_addr,
static char in_ring_page[PAGE_SIZE] __aligned(PAGE_SIZE);
static char out_ring_page[PAGE_SIZE] __aligned(PAGE_SIZE);
static char table_page[PAGE_SIZE] __aligned(PAGE_SIZE);
+   static char bulk_buf_page[PAGE_SIZE] __aligned(PAGE_SIZE);
 
switch (type) {
case XDBC_PAGE_EVENT:
@@ -348,6 +359,9 @@ static void *xdbc_get_page(dma_addr_t *dma_addr,
case XDBC_PAGE_TABLE:
virt = (void *)table_page;
break;
+   case XDBC_PAGE_BUFFER:
+   virt = (void *)bulk_buf_page;
+   break;
default:
return NULL;
}
@@ -694,6 +708,12 @@ static int xdbc_mem_init(void)
dev_info = cpu_to_le32((XDBC_DEVICE_REV << 16) | XDBC_PRODUCT_ID);
writel(dev_info, >xdbc_reg->devinfo2);
 
+   /* get and store the transfer buffer */
+   xdbcp->out_buf = xdbc_get_page(>out_dma,
+   XDBC_PAGE_BUFFER);
+   xdbcp->in_buf = xdbcp->out_buf + XDBC_MAX_PACKET;
+   xdbcp->in_dma = xdbcp->out_dma + XDBC_MAX_PACKET;
+
return 0;
 }
 
@@ -789,6 +809,9 @@ static int xdbc_start(void)
 
xdbc_trace("root hub port number %d\n", DCST_DPN(status));
 
+   xdbcp->in_ep_state = EP_RUNNING;
+   xdbcp->out_ep_state = EP_RUNNING;
+
xdbc_trace("DbC is running now, control 0x%08x\n",
readl(>xdbc_reg->control));
 
@@ -882,3 +905,353 @@ int __init early_xdbc_init(char *s)
 
return 0;
 }
+
+static void xdbc_queue_trb(struct xdbc_ring *ring,
+   u32 field1, u32 field2, u32 field3, u32 field4)
+{
+   struct xdbc_trb *trb, *link_trb;
+
+   trb = ring->enqueue;
+   trb->field[0] = cpu_to_le32(field1);
+   trb->field[1] = cpu_to_le32(field2);
+   trb->field[2] = cpu_to_le32(field3);
+   trb->field[3] = cpu_to_le32(field4);
+
+   xdbc_dbg_dump_trb(trb, "enqueue trb");
+
+   ++(ring->enqueue);
+   if (ring->enqueue >= >segment->trbs[TRBS_PER_SEGMENT - 1]) {
+   link_trb = ring->enqueue;
+   if (ring->cycle_state)
+   link_trb->field[3] |= cpu_to_le32(TRB_CYCLE);
+   else
+   link_trb->field[3] &= cpu_to_le32(~TRB_CYCLE);
+
+   ring->enqueue = ring->segment->trbs;
+   ring->cycle_state ^= 1;
+   }
+}
+
+static void xdbc_ring_doorbell(int target)
+{
+   writel(DOOR_BELL_TARGET(target), >xdbc_reg->doorbell);
+}
+
+static void xdbc_handle_port_status(struct xdbc_trb *evt_trb)
+{
+   u32 port_reg;
+
+   port_reg = readl(>xdbc_reg->portsc);
+
+   if (port_reg & PORTSC_CSC) {
+   xdbc_trace("%s: connect status change event\n", __func__);
+   writel(port_reg | PORTSC_CSC, >xdbc_reg->portsc);
+   port_reg = readl(>xdbc_reg->portsc);
+   }
+
+   if (port_reg & PORTSC_PRC) {
+   xdbc_trace("%s: port reset change event\n", __func__);
+   writel(port_reg | PORTSC_PRC, >xdbc_reg->portsc);
+   port_reg = readl(>xdbc_reg->portsc);
+   }
+
+   if (port_reg & PORTSC_PLC) {
+   xdbc_trace("%s: port link status change event\n", __func__);
+   writel(port_reg | PORTSC_PLC, >xdbc_reg->portsc);
+   port_reg = readl(>xdbc_reg->portsc);
+   }
+
+   if (port_reg & PORTSC_CEC) {
+   xdbc_trace("%s: config error change\n", __func__);
+   writel(port_reg | PORTSC_CEC, 

[PATCH v6 01/12] usb: xhci: add sysfs file for xHCI debug port

2016-01-25 Thread Lu Baolu
This patch adds a sysfs file for users to check 1) whether the debug
capability is implemented by hardware; 2) if supported, which state
does it stay at.

With a host that supports debug port, a file named "debug_port_state"
will be created under the device sysfs directory. Reading this file
will show users the state (disabled, enabled or configured) of the
debug port.

With a host that does NOT support debug port, "debug_port_state" file
won't be created.

Signed-off-by: Lu Baolu 
---
 .../ABI/testing/sysfs-bus-pci-drivers-xhci_hcd | 23 
 drivers/usb/host/Makefile  |  2 +-
 drivers/usb/host/xhci-ext-caps.h   |  5 ++
 drivers/usb/host/xhci-sysfs.c  | 65 ++
 drivers/usb/host/xhci.c|  4 ++
 drivers/usb/host/xhci.h|  4 ++
 6 files changed, 102 insertions(+), 1 deletion(-)
 create mode 100644 Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
 create mode 100644 drivers/usb/host/xhci-sysfs.c

diff --git a/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd 
b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
new file mode 100644
index 000..5d0a7d3
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-bus-pci-drivers-xhci_hcd
@@ -0,0 +1,23 @@
+What:  /sys/bus/pci/drivers/xhci_hcd/.../debug_port_state
+Date:  November 2015
+KernelVersion: 4.4.0
+Contact:   Lu Baolu 
+Description:
+   This file is designed for users to check the state of a
+   USB3 debug port. On a machine which supports USB3 debug
+   port, this file will be created. Reading this file will
+   show the state (disabled, enabled or configured) of the
+   debug port. On a machine that doesn't support USB3 debug
+   port, this file doesn't exist.
+
+   The state of a debug port could be:
+   1) disabled: The debug port is not enabled and the root
+   port has been switched to xHCI host as a normal
+   root port.
+   2) enabled: The debug port is enabled. The debug port
+   has been assigned to debug capability. The debug
+   capability is able to handle the control requests
+   defined in USB3 spec.
+   3) configured: The debug port has been enumerated by the
+   debug host as a debug device. The debug port is
+   in use now.
diff --git a/drivers/usb/host/Makefile b/drivers/usb/host/Makefile
index 65a06b4..aba2bf5 100644
--- a/drivers/usb/host/Makefile
+++ b/drivers/usb/host/Makefile
@@ -12,7 +12,7 @@ fhci-$(CONFIG_FHCI_DEBUG) += fhci-dbg.o
 
 xhci-hcd-y := xhci.o xhci-mem.o
 xhci-hcd-y += xhci-ring.o xhci-hub.o xhci-dbg.o
-xhci-hcd-y += xhci-trace.o
+xhci-hcd-y += xhci-trace.o xhci-sysfs.o
 ifneq ($(CONFIG_USB_XHCI_MTK), )
xhci-hcd-y += xhci-mtk-sch.o
 endif
diff --git a/drivers/usb/host/xhci-ext-caps.h b/drivers/usb/host/xhci-ext-caps.h
index 04ce6b1..c4b49c5 100644
--- a/drivers/usb/host/xhci-ext-caps.h
+++ b/drivers/usb/host/xhci-ext-caps.h
@@ -73,6 +73,11 @@
 #define XHCI_HLC   (1 << 19)
 #define XHCI_BLC   (1 << 20)
 
+/* Debug capability - section 7.6.8 */
+#define XHCI_DBC_DCCTRL0x20
+#define XHCI_DBC_DCCTRL_DCR(1 << 0)
+#define XHCI_DBC_DCCTRL_DCE(1 << 31)
+
 /* command register values to disable interrupts and halt the HC */
 /* start/stop HC execution - do not write unless HC is halted*/
 #define XHCI_CMD_RUN   (1 << 0)
diff --git a/drivers/usb/host/xhci-sysfs.c b/drivers/usb/host/xhci-sysfs.c
new file mode 100644
index 000..9feb727
--- /dev/null
+++ b/drivers/usb/host/xhci-sysfs.c
@@ -0,0 +1,65 @@
+/*
+ * sysfs interface for xHCI host controller driver
+ *
+ * Copyright (C) 2015 Intel Corp.
+ *
+ * Author: Lu Baolu 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+
+#include "xhci.h"
+
+#define GET_DBC_EXT_CAP_OFFSET(h)  \
+   xhci_find_next_ext_cap(&(h)->cap_regs->hc_capbase, \
+   0, XHCI_EXT_CAPS_DEBUG)
+
+static ssize_t debug_port_state_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   int count = 0, offset;
+   char*state;
+   void __iomem*dbc_base;
+   u32 dcctrl_reg;
+   struct xhci_hcd *xhci = hcd_to_xhci(dev_get_drvdata(dev));
+
+   offset = GET_DBC_EXT_CAP_OFFSET(xhci);
+   if (!offset)
+   return 0;
+
+   dbc_base = (void __iomem *) xhci->cap_regs + offset;
+   dcctrl_reg = readl(dbc_base + XHCI_DBC_DCCTRL);
+
+   if 

[PATCH v6 05/12] usb: dbc: add debug buffer

2016-01-25 Thread Lu Baolu
"printk" is not suitable for dbc debugging especially when console
is in usage. This patch adds a debug buffer in dbc driver and puts
the debug messages in this local buffer. The debug buffer could be
dumped whenever the console is not in use. This part of code will
not be visible unless DBC_DEBUG is defined.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 62 ++--
 1 file changed, 60 insertions(+), 2 deletions(-)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 41ce116..6855048 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -32,8 +32,64 @@ static struct xdbc_state xdbc_stat;
 static struct xdbc_state *xdbcp = _stat;
 
 #ifdef DBC_DEBUG
-/* place holder */
-#definexdbc_trace  printk
+#defineXDBC_DEBUG_BUF_SIZE (PAGE_SIZE * 32)
+#defineMSG_MAX_LINE128
+static char xdbc_debug_buf[XDBC_DEBUG_BUF_SIZE];
+static void xdbc_trace(const char *fmt, ...)
+{
+   int i, size;
+   va_list args;
+   static int pos;
+   char temp_buf[MSG_MAX_LINE];
+
+   if (pos >= XDBC_DEBUG_BUF_SIZE - 1)
+   return;
+
+   memset(temp_buf, 0, MSG_MAX_LINE);
+   va_start(args, fmt);
+   vsnprintf(temp_buf, MSG_MAX_LINE - 1, fmt, args);
+   va_end(args);
+
+   i = 0;
+   size = strlen(temp_buf);
+   while (i < size) {
+   xdbc_debug_buf[pos] = temp_buf[i];
+   pos++;
+   i++;
+
+   if (pos >= XDBC_DEBUG_BUF_SIZE - 1)
+   break;
+   }
+}
+
+static void xdbc_dump_debug_buffer(void)
+{
+   int index = 0;
+   int count = 0;
+   char dump_buf[MSG_MAX_LINE];
+
+   xdbc_trace("The end of DbC trace buffer\n");
+   pr_notice("DBC debug buffer:\n");
+   memset(dump_buf, 0, MSG_MAX_LINE);
+
+   while (index < XDBC_DEBUG_BUF_SIZE) {
+   if (!xdbc_debug_buf[index])
+   break;
+
+   if (xdbc_debug_buf[index] == '\n' ||
+   count >= MSG_MAX_LINE - 1) {
+   pr_notice("DBC: @%08x %s\n", index, dump_buf);
+   memset(dump_buf, 0, MSG_MAX_LINE);
+   count = 0;
+   } else {
+   dump_buf[count] = xdbc_debug_buf[index];
+   count++;
+   }
+
+   index++;
+   }
+}
+
 static void xdbc_dbg_dump_regs(char *str)
 {
if (!xdbcp->xdbc_reg) {
@@ -165,6 +221,7 @@ static void xdbc_dbg_dump_data(char *str)
 
 #else
 static inline void xdbc_trace(const char *fmt, ...) { }
+static inline void xdbc_dump_debug_buffer(void) { }
 static inline void xdbc_dbg_dump_regs(char *str) { }
 static inline void xdbc_dbg_dump_data(char *str) { }
 #endif /* DBC_DEBUG */
@@ -819,6 +876,7 @@ int __init early_xdbc_init(char *s)
pr_notice("failed to setup xHCI DbC connection\n");
xdbcp->xhci_base = NULL;
xdbcp->xdbc_reg = NULL;
+   xdbc_dump_debug_buffer();
return ret;
}
 
-- 
2.1.4



Re: [RFC][PATCH 0/3] Sanitization of buddy pages

2016-01-25 Thread Sasha Levin
On 01/25/2016 11:55 AM, Laura Abbott wrote:
> Hi,
> 
> This is an implementation of page poisoning/sanitization for all arches. It
> takes advantage of the existing implementation for
> !ARCH_SUPPORTS_DEBUG_PAGEALLOC arches. This is a different approach than what
> the Grsecurity patches were taking but should provide equivalent 
> functionality.
> 
> For those who aren't familiar with this, the goal of sanitization is to reduce
> the severity of use after free and uninitialized data bugs. Memory is cleared
> on free so any sensitive data is no longer available. Discussion of
> sanitization was brough up in a thread about CVEs
> (lkml.kernel.org/g/<20160119112812.GA10818@mwanda>)
> 
> I eventually expect Kconfig names will want to be changed and or moved if this
> is going to be used for security but that can happen later.
> 
> Credit to Mathias Krause for the version in grsecurity
> 
> Laura Abbott (3):
>   mm/debug-pagealloc.c: Split out page poisoning from debug page_alloc
>   mm/page_poison.c: Enable PAGE_POISONING as a separate option
>   mm/page_poisoning.c: Allow for zero poisoning
> 
>  Documentation/kernel-parameters.txt |   5 ++
>  include/linux/mm.h  |  13 +++
>  include/linux/poison.h  |   4 +
>  mm/Kconfig.debug|  35 +++-
>  mm/Makefile |   5 +-
>  mm/debug-pagealloc.c| 127 +
>  mm/page_alloc.c |  10 ++-
>  mm/page_poison.c| 158 
> 
>  8 files changed, 228 insertions(+), 129 deletions(-)
>  create mode 100644 mm/page_poison.c
> 

Should poisoning of this kind be using kasan rather than "old fashioned"
poisoning?


Thanks,
Sasha


Re: [PATCH] brcmfmac: sdio: Increase the default timeouts a bit

2016-01-25 Thread Arend van Spriel
On 26-01-16 00:41, Julian Calaby wrote:
> Hi Arend,
> 
> On Tue, Jan 26, 2016 at 2:39 AM, Arend van Spriel  wrote:
>> On 25-01-16 12:06, Julian Calaby wrote:
>>> Hi Sjoerd,
>>>
>>> On Mon, Jan 25, 2016 at 9:47 PM, Sjoerd Simons
>>>  wrote:
 On a Radxa Rock2 board with a Ampak AP6335 (Broadcom 4339 core) it seems
 the card responds very quickly most of the time, unfortunately during
 initialisation it sometimes seems to take just a bit over 2 seconds to
 respond.

 This results intialization failing with message like:
   brcmf_c_preinit_dcmds: Retreiving cur_etheraddr failed, -52
   brcmf_bus_start: failed: -52
   brcmf_sdio_firmware_callback: dongle is not responding

 Increasing the timeout to allow for a bit more headroom allows the
 card to initialize reliably.

 A quick search online after diagnosing/fixing this showed that Google
 has a similar patch in their ChromeOS tree, so this doesn't seem
 specific to the board I'm using.

 Signed-off-by: Sjoerd Simons 
>>>
>>> Looks sane to me.
>>>
>>> Reviewed-by: Julian Calaby 
>>
>> Not really a cleanup patch :-p , but thanks for the review.
> 
> I'm trying to review any "small" patch from (relatively) new people.

And it is surely appreciated. Just read your reply in "cleanup patch
pile" thread and felt I had to make the stupid remark with just fun
intended.

Regards,
Arend


Re: [PATCH v6 09/12] x86: early_printk: add USB3 debug port earlyprintk support

2016-01-25 Thread kbuild test robot
Hi Lu,

[auto build test ERROR on usb/usb-testing]
[also build test ERROR on v4.5-rc1 next-20160125]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Lu-Baolu/usb-early-add-support-for-early-printk-through-USB3-debug-port/20160126-122049
base:   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git 
usb-testing
config: x86_64-randconfig-h0-01261334 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   arch/x86/built-in.o: In function `setup_early_printk':
>> early_printk.c:(.init.text+0xceba): undefined reference to `early_xdbc_init'
>> early_printk.c:(.init.text+0xcec8): undefined reference to 
>> `early_xdbc_console'

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


.config.gz
Description: Binary data


Re: [PATCH] media: platform: exynos4-is: media-dev: Add missing of_node_put

2016-01-25 Thread Julia Lawall


On Tue, 26 Jan 2016, Krzysztof Kozlowski wrote:

> On 26.01.2016 15:24, Julia Lawall wrote:
> > 
> > 
> > On Tue, 26 Jan 2016, Krzysztof Kozlowski wrote:
> > 
> >> On 26.01.2016 00:21, Amitoj Kaur Chawla wrote:
> >>> for_each_available_child_of_node and for_each_child_of_node perform an
> >>> of_node_get on each iteration, so to break out of the loop an of_node_put 
> >>> is
> >>> required.
> >>>
> >>> Found using Coccinelle. The simplified version of the semantic patch
> >>> that is used for this is as follows:
> >>>
> >>> // 
> >>> @@
> >>> local idexpression n;
> >>> expression e,r;
> >>> @@
> >>>
> >>>  for_each_available_child_of_node(r,n) {
> >>>...
> >>> (
> >>>of_node_put(n);
> >>> |
> >>>e = n
> >>> |
> >>> +  of_node_put(n);
> >>> ?  break;
> >>> )
> >>>...
> >>>  }
> >>> ... when != n
> >>> // 
> >>
> >> Patch iselft looks correct but why are you pasting coccinelle script
> >> into the message?
> >>
> >> The script is already present in Linux kernel:
> >> scripts/coccinelle/iterators/device_node_continue.cocci
> > 
> > I don't think so.  The continue one takes care of the case where there is 
> > an extraneous of_node_put before a continue, not a missing one before a 
> > break.  But OK to drop it if it doesn't seem useful.
> > 
> > julia
> 
> You are right - this is not covered by that cocci patch... but I think
> is covered by scripts/coccinelle/iterators/fen.cocci, isn't it?

Not quite.  That is for of_node_puts after normal loop completion (not 
sure that this problem comes up any more, but at one point there were a 
number of them). There are indeed a lot of ways in which the management of 
reference counts can go wrong...

Anyway, the rule that Amitoj used seems to be pretty reliable, so I'll try 
to get it into the kernel source tree some day soon.

julia

> 
> BR,
> Krzysztof
> 
> > 
> >> This just extends the commit message without any meaningful data so with
> >> removal of coccinelle script above:
> >> Reviewed-by: Krzysztof Kozlowski 
> >>
> >> Best regards,
> >> Krzysztof
> >>
> >>>
> >>> Signed-off-by: Amitoj Kaur Chawla 
> >>> ---
> >>>  drivers/media/platform/exynos4-is/media-dev.c | 12 +---
> >>>  1 file changed, 9 insertions(+), 3 deletions(-)
> 
> 


[PATCH 1/2] MIPS: ath79: Add support for DTB passed using the UHI boot protocol

2016-01-25 Thread Alban Bedel
This is needed for bootloader supporting UHI and to support appended
DTB.

Signed-off-by: Alban Bedel 
---
 arch/mips/ath79/setup.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/mips/ath79/setup.c b/arch/mips/ath79/setup.c
index 2fdba24..2895e45 100644
--- a/arch/mips/ath79/setup.c
+++ b/arch/mips/ath79/setup.c
@@ -203,6 +203,8 @@ void __init plat_mem_setup(void)
fdt_start = fw_getenvl("fdt_start");
if (fdt_start)
__dt_setup_arch((void *)KSEG0ADDR(fdt_start));
+   else if (fw_arg0 == -2)
+   __dt_setup_arch((void *)KSEG0ADDR(fw_arg1));
 #ifdef CONFIG_BUILTIN_DTB
else
__dt_setup_arch(__dtb_start);
-- 
2.0.0



[PATCH v2 2/3] f2fs: simplify __allocate_data_blocks

2016-01-25 Thread Chao Yu
This patch uses existing function f2fs_map_block to simplify implementation
of __allocate_data_blocks.

Signed-off-by: Chao Yu 
---

 V2:
 - rebase on last dev-test.

 fs/f2fs/data.c | 60 --
 1 file changed, 4 insertions(+), 56 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index f570d37..2f8ecfe 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -537,64 +537,12 @@ alloc:
 static int __allocate_data_blocks(struct inode *inode, loff_t offset,
size_t count)
 {
-   struct f2fs_sb_info *sbi = F2FS_I_SB(inode);
-   struct dnode_of_data dn;
-   u64 start = F2FS_BYTES_TO_BLK(offset);
-   u64 len = F2FS_BYTES_TO_BLK(count);
-   bool allocated = false;
-   u64 end_offset;
-   int err = 0;
-
-   while (len) {
-   f2fs_lock_op(sbi);
-
-   /* When reading holes, we need its node page */
-   set_new_dnode(, inode, NULL, NULL, 0);
-   err = get_dnode_of_data(, start, ALLOC_NODE);
-   if (err)
-   goto out;
-
-   allocated = false;
-   end_offset = ADDRS_PER_PAGE(dn.node_page, F2FS_I(inode));
-
-   while (dn.ofs_in_node < end_offset && len) {
-   block_t blkaddr;
-
-   if (unlikely(f2fs_cp_error(sbi))) {
-   err = -EIO;
-   goto sync_out;
-   }
-
-   blkaddr = datablock_addr(dn.node_page, dn.ofs_in_node);
-   if (blkaddr == NULL_ADDR || blkaddr == NEW_ADDR) {
-   err = __allocate_data_block();
-   if (err)
-   goto sync_out;
-   allocated = true;
-   }
-   len--;
-   start++;
-   dn.ofs_in_node++;
-   }
-
-   if (allocated)
-   sync_inode_page();
-
-   f2fs_put_dnode();
-   f2fs_unlock_op(sbi);
+   struct f2fs_map_blocks map;
 
-   f2fs_balance_fs(sbi, allocated);
-   }
-   return err;
+   map.m_lblk = F2FS_BYTES_TO_BLK(offset);
+   map.m_len = F2FS_BYTES_TO_BLK(count);
 
-sync_out:
-   if (allocated)
-   sync_inode_page();
-   f2fs_put_dnode();
-out:
-   f2fs_unlock_op(sbi);
-   f2fs_balance_fs(sbi, allocated);
-   return err;
+   return f2fs_map_blocks(inode, , 1, F2FS_GET_BLOCK_DIO);
 }
 
 /*
-- 
2.7.0.2.g1b0b6dd




Re: [kernel-hardening] Re: [PATCH 0/2] sysctl: allow CLONE_NEWUSER to be disabled

2016-01-25 Thread Serge Hallyn
Quoting Kees Cook (keesc...@chromium.org):
> On Fri, Jan 22, 2016 at 7:02 PM, Eric W. Biederman
> > So I have concerns about both efficacy and usability with the proposed
> > sysctl.
> 
> Two distros already have this sysctl because it was so strongly
> requested by their users. This needs to be upstream so we can manage
> the effects correctly.

Which two distros?  Was it in fact requested by their users?

My opinion remains that long-term this is a bad thing.  If we're going to
have this upstream, it should be clearly marked so as to be easily
removable at some point down the road.  Userspace that cannot count on a
feature (in the best case) won't use it or (much worse) will fall back
to broken behavior in one case or the other.


Re: Delivery notification..(View the attachment for confirmation of your delivery address)

2016-01-25 Thread FedEx Express Delivery


FedEx-Delivery Post (USA).docx
Description: MS-Word 2007 document


Re: [PATCH 3/3] input: touchscreen: ad7879: add device tree support

2016-01-25 Thread kbuild test robot
Hi Stefan,

[auto build test ERROR on input/next]
[also build test ERROR on v4.5-rc1 next-20160125]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Stefan-Agner/input-touchscreen-ad7879-move-header-to-input-subdirectory/20160126-110813
base:   https://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git next
config: x86_64-randconfig-s4-01261112 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All error/warnings (new ones prefixed by >>):

   In file included from drivers/input/touchscreen/ad7879-i2c.c:11:0:
>> drivers/input/touchscreen/ad7879-i2c.c:151:25: error: 'st1232_ts_dt_ids' 
>> undeclared here (not in a function)
MODULE_DEVICE_TABLE(of, st1232_ts_dt_ids);
^
   include/linux/module.h:223:21: note: in definition of macro 
'MODULE_DEVICE_TABLE'
extern const typeof(name) __mod_##type##__##name##_device_table  \
^
>> include/linux/module.h:223:27: error: 
>> '__mod_of__st1232_ts_dt_ids_device_table' aliased to undefined symbol 
>> 'st1232_ts_dt_ids'
extern const typeof(name) __mod_##type##__##name##_device_table  \
  ^
>> drivers/input/touchscreen/ad7879-i2c.c:151:1: note: in expansion of macro 
>> 'MODULE_DEVICE_TABLE'
MODULE_DEVICE_TABLE(of, st1232_ts_dt_ids);
^

vim +/st1232_ts_dt_ids +151 drivers/input/touchscreen/ad7879-i2c.c

 5   *
 6   * Licensed under the GPL-2 or later.
 7   */
 8  
 9  #include /* BUS_I2C */
10  #include 
  > 11  #include 
12  #include 
13  #include 
14  #include 
15  
16  #include "ad7879.h"
17  
18  #define AD7879_DEVID0x79/* AD7879-1/AD7889-1 */
19  
20  /* All registers are word-sized.
21   * AD7879 uses a high-byte first convention.
22   */
23  static int ad7879_i2c_read(struct device *dev, u8 reg)
24  {
25  struct i2c_client *client = to_i2c_client(dev);
26  
27  return i2c_smbus_read_word_swapped(client, reg);
28  }
29  
30  static int ad7879_i2c_multi_read(struct device *dev,
31   u8 first_reg, u8 count, u16 *buf)
32  {
33  struct i2c_client *client = to_i2c_client(dev);
34  u8 idx;
35  
36  i2c_smbus_read_i2c_block_data(client, first_reg, count * 2, (u8 
*)buf);
37  
38  for (idx = 0; idx < count; ++idx)
39  buf[idx] = swab16(buf[idx]);
40  
41  return 0;
42  }
43  
44  static int ad7879_i2c_write(struct device *dev, u8 reg, u16 val)
45  {
46  struct i2c_client *client = to_i2c_client(dev);
47  
48  return i2c_smbus_write_word_swapped(client, reg, val);
49  }
50  
51  static const struct ad7879_bus_ops ad7879_i2c_bus_ops = {
52  .bustype= BUS_I2C,
53  .read   = ad7879_i2c_read,
54  .multi_read = ad7879_i2c_multi_read,
55  .write  = ad7879_i2c_write,
56  };
57  
58  static struct ad7879_platform_data *ad7879_parse_dt(struct device *dev)
59  {
60  struct ad7879_platform_data *pdata;
61  struct device_node *np = dev->of_node;
62  int err;
63  u32 tmp;
64  
65  if (!np)
66  return NULL;
67  
68  pdata = devm_kzalloc(dev, sizeof(*pdata), GFP_KERNEL);
69  
70  if (!pdata)
71  return ERR_PTR(-ENOMEM);
72  
73  err = of_property_read_u32(np, "resistance-plate-x", );
74  if (err) {
75  dev_err(dev, "failed to get resistance-plate-x 
property\n");
76  return ERR_PTR(err);
77  }
78  pdata->x_plate_ohms = (u16)tmp;
79  
80  err = of_property_read_u32(np, "touchscreen-max-pressure", 
);
81  if (err) {
82  dev_err(dev, "failed to get touchscreen-max-pressure 
property\n");
83  return ERR_PTR(err);
84  }
85  pdata->pressure_min = (u16)tmp;
86  
87  of_property_read_u8(np, "first-conversion-delay", 
>first_conversion_delay);
88  of_property_read_u8(np, "acquisition-time", 
>acquisition_time);
89  of_property_read_u8(np, "median-filter-size", >median);
90  of_property_read_u8(np, "averaging", >averaging);
91  of_property_read_u8(np, "conversion-interval", 
>pen_down_acc_interval);
92  
93  pdata->swap_xy = o

Re: [PATCH] Add hard/soft lockup debugger entry points

2016-01-25 Thread kbuild test robot
Hi Jeff,

[auto build test ERROR on v4.5-rc1]
[also build test ERROR on next-20160125]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improving the system]

url:
https://github.com/0day-ci/linux/commits/Jeff-Merkey/Add-hard-soft-lockup-debugger-entry-points/20160126-103801
config: arm64-defconfig (attached as .config)
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=arm64 

All errors (new ones prefixed by >>):

   /tmp/cc3NhccY.s: Assembler messages:
>> /tmp/cc3NhccY.s:1030: Error: unknown mnemonic `int' -- `int $0x03'

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


.config.gz
Description: Binary data


RE: [f2fs-dev] [PATCH 4/6] f2fs: avoid multiple node page writes due to inline_data

2016-01-25 Thread Chao Yu
Hi Jaegeuk,

> -Original Message-
> From: Jaegeuk Kim [mailto:jaeg...@kernel.org]
> Sent: Tuesday, January 26, 2016 6:05 AM
> To: linux-kernel@vger.kernel.org; linux-fsde...@vger.kernel.org;
> linux-f2fs-de...@lists.sourceforge.net
> Cc: Jaegeuk Kim
> Subject: [f2fs-dev] [PATCH 4/6] f2fs: avoid multiple node page writes due to 
> inline_data
> 
> The sceanrio is:
> 1. create fully node blocks
> 2. flush node blocks
> 3. write inline_data for all the node blocks again
> 4. flush node blocks redundantly
> 
> So, this patch tries to flush inline_data when flushing node blocks.
> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/data.c   |  1 +
>  fs/f2fs/inline.c |  2 ++
>  fs/f2fs/node.c   | 39 +++
>  fs/f2fs/node.h   | 15 +++
>  4 files changed, 57 insertions(+)
> 
> diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
> index 89a37ba..260c0eb 100644
> --- a/fs/f2fs/data.c
> +++ b/fs/f2fs/data.c
> @@ -1463,6 +1463,7 @@ restart:
>   if (pos + len <= MAX_INLINE_DATA) {
>   read_inline_data(page, ipage);
>   set_inode_flag(F2FS_I(inode), FI_DATA_EXIST);
> + set_inline_node(ipage);
>   sync_inode_page();
>   } else {
>   err = f2fs_convert_inline_page(, page);
> diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
> index 8df13e5..fc4d298 100644
> --- a/fs/f2fs/inline.c
> +++ b/fs/f2fs/inline.c
> @@ -159,6 +159,7 @@ no_update:
> 
>   /* clear inline data and flag after data writeback */
>   truncate_inline_inode(dn->inode_page, 0);
> + clear_inline_node(dn->inode_page);
>  clear_out:
>   stat_dec_inline_inode(dn->inode);
>   f2fs_clear_inline_inode(dn->inode);
> @@ -233,6 +234,7 @@ int f2fs_write_inline_data(struct inode *inode, struct 
> page *page)
>   set_inode_flag(F2FS_I(inode), FI_DATA_EXIST);
> 
>   sync_inode_page();
> + clear_inline_node(dn.inode_page);
>   f2fs_put_dnode();
>   return 0;
>  }
> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> index 23b800d..94a6755 100644
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -1154,6 +1154,37 @@ void sync_inode_page(struct dnode_of_data *dn)
>   dn->node_changed = ret ? true: false;
>  }
> 
> +static void flush_inline_data(struct f2fs_sb_info *sbi, nid_t ino)
> +{
> + struct inode *inode;
> + struct page *page;
> +
> + /* should flush inline_data before evict_inode */
> + inode = ilookup(sbi->sb, ino);
> + if (!inode)
> + return;
> +
> + page = pagecache_get_page(inode->i_mapping, 0, FGP_LOCK|FGP_NOWAIT, 0);
> + if (!page)
> + goto iput_out;
> +
> + if (!PageUptodate(page))
> + goto page_out;
> +
> + if (!PageDirty(page))
> + goto page_out;
> +
> + if (!clear_page_dirty_for_io(page))
> + goto page_out;
> +
> + if (!f2fs_write_inline_data(inode, page))

better to redirty the page when fail except -EAGAIN?

> + inode_dec_dirty_pages(inode);
> +page_out:
> + f2fs_put_page(page, 1);
> +iput_out:
> + iput(inode);
> +}
> +
>  int sync_node_pages(struct f2fs_sb_info *sbi, nid_t ino,
>   struct writeback_control *wbc)
>  {
> @@ -1221,6 +1252,14 @@ continue_unlock:
>   goto continue_unlock;
>   }
> 
> + /* flush inline_data */
> + if (!ino && is_inline_node(page)) {
> + clear_inline_node(page);

Should clear after flushed inline data? otherwise if we failed to flush
inline data, we will lose the change to flush it before node flush.

Thanks,

> + unlock_page(page);
> + flush_inline_data(sbi, ino_of_node(page));
> + continue;
> + }
> +
>   if (!clear_page_dirty_for_io(page))
>   goto continue_unlock;
> 
> diff --git a/fs/f2fs/node.h b/fs/f2fs/node.h
> index 23bd992..1f4f9d4 100644
> --- a/fs/f2fs/node.h
> +++ b/fs/f2fs/node.h
> @@ -379,6 +379,21 @@ static inline int is_node(struct page *page, int type)
>  #define is_fsync_dnode(page) is_node(page, FSYNC_BIT_SHIFT)
>  #define is_dent_dnode(page)  is_node(page, DENT_BIT_SHIFT)
> 
> +static inline int is_inline_node(struct page *page)
> +{
> + return PageChecked(page);
> +}
> +
> +static inline void set_inline_node(struct page *page)
> +{
> + SetPageChecked(page);
> +}
> +
> +static inline void clear_inline_node(struct page *page)
> +{
> + ClearPageChecked(page);
> +}
> +
>  static inline void set_cold_node(struct inode *inode, struct page *page)
>  {
>   struct f2fs_node *rn = F2FS_NODE(page);
> --
> 2.6.3
> 
> 
> --
> Site24x7 APM Insight: Get Deep Visibility into Application 

Re: [v3,11/41] mips: reuse asm-generic/barrier.h

2016-01-25 Thread Paul E. McKenney
On Mon, Jan 25, 2016 at 04:42:43PM +, Will Deacon wrote:
> On Fri, Jan 15, 2016 at 01:58:53PM -0800, Paul E. McKenney wrote:
> > On Fri, Jan 15, 2016 at 10:27:14PM +0100, Peter Zijlstra wrote:
> > > On Fri, Jan 15, 2016 at 09:46:12AM -0800, Paul E. McKenney wrote:
> > > > On Fri, Jan 15, 2016 at 10:13:48AM +0100, Peter Zijlstra wrote:
> > > 
> > > > > And the stuff we're confused about is how best to express the 
> > > > > difference
> > > > > and guarantees of these two forms of transitivity and how exactly they
> > > > > interact.
> > > > 
> > > > Hoping my memory-barrier.txt patch helps here...
> > > 
> > > Yes, that seems a good start. But yesterday you raised the 'fun' point
> > > of two globally ordered sequences connected by a single local link.
> > 
> > The conclusion that I am slowly coming to is that litmus tests should
> > not be thought of as linear chains, but rather as cycles.  If you think
> > of it as a cycle, then it doesn't matter where the local link is, just
> > how many of them and how they are connected.
> 
> Do you have some examples of this? I'm struggling to make it work in my
> mind, or are you talking specifically in the context of the kernel
> memory model?

Now that you mention it, maybe it would be best to keep the transitive
and non-transitive separate for the time being anyway.  Just because it
might be possible to deal with does not necessarily mean that we should
be encouraging it.  ;-)

> > But I will admit that there are some rather strange litmus tests that
> > challenge this cycle-centric view, for example, the one shown below.
> > It turns out that herd and ppcmem disagree on the outcome.  (The Power
> > architects side with ppcmem.)
> > 
> > > And I think I'm still confused on LWSYNC (in the smp_wmb case) when one
> > > of the stores looses a conflict, and if that scenario matters. If it
> > > does, we should inspect the same case for other barriers.
> > 
> > Indeed.  I am still working on how these should be described.  My
> > current thought is to be quite conservative on what ordering is
> > actually respected, however, the current task is formalizing how
> > RCU plays with the rest of the memory model.
> > 
> > Thanx, Paul
> > 
> > 
> > 
> > PPC Overlapping Group-B sets version 4
> > ""
> > (* When the Group-B sets from two different barriers involve instructions in
> >the same thread, within that thread one set must contain the other.
> > 
> > P0  P1  P2
> > Rx=1Wy=1Wz=2
> > dep.lwsync  lwsync
> > Ry=0Wz=1Wx=1
> > Rz=1
> > 
> > assert(!(z=2))
> > 
> >Forbidden by ppcmem, allowed by herd.
> > *)
> > {
> > 0:r1=x; 0:r2=y; 0:r3=z;
> > 1:r1=x; 1:r2=y; 1:r3=z; 1:r4=1;
> > 2:r1=x; 2:r2=y; 2:r3=z; 2:r4=1; 2:r5=2;
> > }
> >  P0 | P1| P2;
> >  lwz r6,0(r1)   | stw r4,0(r2)  | stw r5,0(r3)  ;
> >  xor r7,r6,r6   | lwsync| lwsync;
> >  lwzx r7,r7,r2  | stw r4,0(r3)  | stw r4,0(r1)  ;
> >  lwz r8,0(r3)   |   |   ;
> > 
> > exists
> > (z=2 /\ 0:r6=1 /\ 0:r7=0 /\ 0:r8=1)
> 
> That really hurts. Assuming that the "assert(!(z=2))" is actually there
> to constrain the coherence order of z to be {0->1->2}, then I think that
> this test is forbidden on arm using dmb instead of lwsync. That said, I
> also don't think the Rz=1 in P0 changes anything.

What about the smp_wmb() variant of dmb that orders only stores?

> The double negatives don't help here! (it is forbidden to guarantee that
> z is not always 2).

Yes, this is a weird one, and I don't know of any use of it.

Thanx, Paul



Re: [PATCH V4 07/11] of: Add bindings of hw-trip-points for soctherm

2016-01-25 Thread Wei Ni


On 2016年01月26日 10:41, Rob Herring wrote:
> On Mon, Jan 25, 2016 at 06:46:36PM +0800, Wei Ni wrote:
>> Add hw-trips sub-node for soctherm, which is
>> used to describe the hardware trip points for
>> each soctherm sensors.
> 
> This seems like something that should be common. There was a hwmon 
> binding just the other day with temperature set points.

I have checked the thermal_hwmon.c, but we can't use it. Because we use
of-thermal to register thermal zone, but it doesn't support to register to
hwmon. And it only support to show the critical temperature.
I think this sub-node is used for Tegra's soctherm specifically. And it's not
only for shutdown/reset, it also will be used to describe the hw-throttle
function in next serial patches (I'm preparing it, didn't send out yet).

BTW, I didn't find the hwmon binding to introduce the hw trips in TOT
kernel-next, could you show me it?

> 
>> Signed-off-by: Wei Ni 
>> ---
>>  .../devicetree/bindings/thermal/tegra-soctherm.txt | 24 
>> ++
>>  1 file changed, 24 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/thermal/tegra-soctherm.txt 
>> b/Documentation/devicetree/bindings/thermal/tegra-soctherm.txt
>> index 6b68cd150405..75dc9dbe7e1a 100644
>> --- a/Documentation/devicetree/bindings/thermal/tegra-soctherm.txt
>> +++ b/Documentation/devicetree/bindings/thermal/tegra-soctherm.txt
>> @@ -26,6 +26,15 @@ Required properties :
>>  of this property. See  for a
>>  list of valid values when referring to thermal sensors.
>>  
>> +Optional properties:
>> +- hw-trip-points : A sub-node which is a container of hardware trip points
>> +for each sensors.
>> +  * sensors: Sub-nodes which are used to describe the HW trip points info,
>> +must be named as "cpu", "gpu", "mem", "pll".
>> +  Properties:
>> +  - thermtrip-temperature : Shutdown or reset temperature in 
>> millicelsius,
>> +once the temperature of this sensor is higher than the
>> +thermtrip-temperature, the system will be shutdown or reset.
> 
> Append units and temperature is a bit redundant. Something like 
> thermtrip-mC or thermtrip-milliC

Hmm, got it, will change it in next version.

> 
> You could easily have multiple levels of trip points, so perhaps the 
> name needs to reflect the action (i.e. shutdown).

This temperature can trigger shutdown or reset, it depends on the platform
design, and the Tegra's SPEC call it as thermtrip, so I use this name. I prefer
to use "thermtgrip-mC".

> 
> Rob
> 


Re: [PATCH] media: platform: exynos4-is: media-dev: Add missing of_node_put

2016-01-25 Thread Julia Lawall


On Tue, 26 Jan 2016, Krzysztof Kozlowski wrote:

> On 26.01.2016 00:21, Amitoj Kaur Chawla wrote:
> > for_each_available_child_of_node and for_each_child_of_node perform an
> > of_node_get on each iteration, so to break out of the loop an of_node_put is
> > required.
> > 
> > Found using Coccinelle. The simplified version of the semantic patch
> > that is used for this is as follows:
> > 
> > // 
> > @@
> > local idexpression n;
> > expression e,r;
> > @@
> > 
> >  for_each_available_child_of_node(r,n) {
> >...
> > (
> >of_node_put(n);
> > |
> >e = n
> > |
> > +  of_node_put(n);
> > ?  break;
> > )
> >...
> >  }
> > ... when != n
> > // 
> 
> Patch iselft looks correct but why are you pasting coccinelle script
> into the message?
> 
> The script is already present in Linux kernel:
> scripts/coccinelle/iterators/device_node_continue.cocci

I don't think so.  The continue one takes care of the case where there is 
an extraneous of_node_put before a continue, not a missing one before a 
break.  But OK to drop it if it doesn't seem useful.

julia

> This just extends the commit message without any meaningful data so with
> removal of coccinelle script above:
> Reviewed-by: Krzysztof Kozlowski 
> 
> Best regards,
> Krzysztof
> 
> > 
> > Signed-off-by: Amitoj Kaur Chawla 
> > ---
> >  drivers/media/platform/exynos4-is/media-dev.c | 12 +---
> >  1 file changed, 9 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/media/platform/exynos4-is/media-dev.c 
> > b/drivers/media/platform/exynos4-is/media-dev.c
> > index 4f5586a..09f6e54 100644
> > --- a/drivers/media/platform/exynos4-is/media-dev.c
> > +++ b/drivers/media/platform/exynos4-is/media-dev.c
> > @@ -430,8 +430,10 @@ static int fimc_md_register_sensor_entities(struct 
> > fimc_md *fmd)
> > continue;
> >  
> > ret = fimc_md_parse_port_node(fmd, port, index);
> > -   if (ret < 0)
> > +   if (ret < 0) {
> > +   of_node_put(node);
> > goto rpm_put;
> > +   }
> > index++;
> > }
> >  
> > @@ -442,8 +444,10 @@ static int fimc_md_register_sensor_entities(struct 
> > fimc_md *fmd)
> >  
> > for_each_child_of_node(ports, node) {
> > ret = fimc_md_parse_port_node(fmd, node, index);
> > -   if (ret < 0)
> > +   if (ret < 0) {
> > +   of_node_put(node);
> > break;
> > +   }
> > index++;
> > }
> >  rpm_put:
> > @@ -651,8 +655,10 @@ static int fimc_md_register_platform_entities(struct 
> > fimc_md *fmd,
> > ret = fimc_md_register_platform_entity(fmd, pdev,
> > plat_entity);
> > put_device(>dev);
> > -   if (ret < 0)
> > +   if (ret < 0) {
> > +   of_node_put(node);
> > break;
> > +   }
> > }
> >  
> > return ret;
> > 
> 
> 


Re: [RFC][PATCH 0/3] Speed up SLUB poisoning + disable checks

2016-01-25 Thread Joonsoo Kim
On Mon, Jan 25, 2016 at 05:15:10PM -0800, Laura Abbott wrote:
> Hi,
> 
> Based on the discussion from the series to add slab sanitization
> (lkml.kernel.org/g/<1450755641-7856-1-git-send-email-la...@labbott.name>)
> the existing SLAB_POISON mechanism already covers similar behavior.
> The performance of SLAB_POISON isn't very good. With hackbench -g 20 -l 1000
> on QEMU with one cpu:

I doesn't follow up that discussion, but, I think that reusing
SLAB_POISON for slab sanitization needs more changes. I assume that
completeness and performance is matter for slab sanitization.

1) SLAB_POISON isn't applied to specific kmem_cache which has
constructor or SLAB_DESTROY_BY_RCU flag. For debug, it's not necessary
to be applied, but, for slab sanitization, it is better to apply it to
all caches.

2) SLAB_POISON makes object size bigger so natural alignment will be
broken. For example, kmalloc(256) cache's size is 256 in normal
case but it would be 264 when SLAB_POISON is enabled. This causes
memory waste.

In fact, I'd prefer not reusing SLAB_POISON. It would make thing
simpler. But, it's up to Christoph.

Thanks.



[PATCH v2 3/3] f2fs: remove unneeded pointer conversion

2016-01-25 Thread Chao Yu
There are redundant pointer conversion in following call stack:
 - at position a, inode was been converted to f2fs_file_info.
 - at position b, f2fs_file_info was been converted to inode again.

 - truncate_blocks(inode,..)
  - fi = F2FS_I(inode)  ---a
  - ADDRS_PER_PAGE(node_page, fi)
   - addrs_per_inode(fi)
- inode = >vfs_inode---b
- f2fs_has_inline_xattr(inode)
 - fi = F2FS_I(inode)
 - is_inode_flag_set(fi,..)

In order to avoid unneeded conversion, alter ADDRS_PER_PAGE and
addrs_per_inode to acept parameter with type of inode pointer.

Signed-off-by: Chao Yu 
---

 V2:
 - rebase on last dev-test.

 fs/f2fs/data.c  |  5 ++---
 fs/f2fs/extent_cache.c  |  5 ++---
 fs/f2fs/f2fs.h  | 14 +++---
 fs/f2fs/file.c  | 11 +--
 fs/f2fs/gc.c|  8 
 fs/f2fs/node.c  |  8 
 fs/f2fs/recovery.c  | 10 --
 include/linux/f2fs_fs.h |  6 +++---
 8 files changed, 31 insertions(+), 36 deletions(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 2f8ecfe..0956219 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -498,7 +498,6 @@ got_it:
 static int __allocate_data_block(struct dnode_of_data *dn)
 {
struct f2fs_sb_info *sbi = F2FS_I_SB(dn->inode);
-   struct f2fs_inode_info *fi = F2FS_I(dn->inode);
struct f2fs_summary sum;
struct node_info ni;
int seg = CURSEG_WARM_DATA;
@@ -526,7 +525,7 @@ alloc:
set_data_blkaddr(dn);
 
/* update i_size */
-   fofs = start_bidx_of_node(ofs_of_node(dn->node_page), fi) +
+   fofs = start_bidx_of_node(ofs_of_node(dn->node_page), dn->inode) +
dn->ofs_in_node;
if (i_size_read(dn->inode) < ((loff_t)(fofs + 1) << PAGE_CACHE_SHIFT))
i_size_write(dn->inode,
@@ -593,7 +592,7 @@ next_dnode:
goto unlock_out;
}
 
-   end_offset = ADDRS_PER_PAGE(dn.node_page, F2FS_I(inode));
+   end_offset = ADDRS_PER_PAGE(dn.node_page, inode);
 
 next_block:
blkaddr = datablock_addr(dn.node_page, dn.ofs_in_node);
diff --git a/fs/f2fs/extent_cache.c b/fs/f2fs/extent_cache.c
index 7dbf691..4168207 100644
--- a/fs/f2fs/extent_cache.c
+++ b/fs/f2fs/extent_cache.c
@@ -700,7 +700,6 @@ bool f2fs_lookup_extent_cache(struct inode *inode, pgoff_t 
pgofs,
 
 void f2fs_update_extent_cache(struct dnode_of_data *dn)
 {
-   struct f2fs_inode_info *fi = F2FS_I(dn->inode);
pgoff_t fofs;
 
if (!f2fs_may_extent_tree(dn->inode))
@@ -708,8 +707,8 @@ void f2fs_update_extent_cache(struct dnode_of_data *dn)
 
f2fs_bug_on(F2FS_I_SB(dn->inode), dn->data_blkaddr == NEW_ADDR);
 
-   fofs = start_bidx_of_node(ofs_of_node(dn->node_page), fi) +
-   dn->ofs_in_node;
+   fofs = start_bidx_of_node(ofs_of_node(dn->node_page), dn->inode) +
+   dn->ofs_in_node;
 
if (f2fs_update_extent_tree_range(dn->inode, fofs, dn->data_blkaddr, 1))
sync_inode_page(dn);
diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
index 0bbbfed..4bcc512 100644
--- a/fs/f2fs/f2fs.h
+++ b/fs/f2fs/f2fs.h
@@ -1528,9 +1528,9 @@ static inline int f2fs_has_inline_xattr(struct inode 
*inode)
return is_inode_flag_set(F2FS_I(inode), FI_INLINE_XATTR);
 }
 
-static inline unsigned int addrs_per_inode(struct f2fs_inode_info *fi)
+static inline unsigned int addrs_per_inode(struct inode *inode)
 {
-   if (f2fs_has_inline_xattr(>vfs_inode))
+   if (f2fs_has_inline_xattr(inode))
return DEF_ADDRS_PER_INODE - F2FS_INLINE_XATTR_ADDRS;
return DEF_ADDRS_PER_INODE;
 }
@@ -1684,10 +1684,10 @@ static inline void *f2fs_kvzalloc(size_t size, gfp_t 
flags)
 (F2FS_I(i)->i_acl_mode) : ((i)->i_mode))
 
 /* get offset of first page in next direct node */
-#define PGOFS_OF_NEXT_DNODE(pgofs, fi) \
-   ((pgofs < ADDRS_PER_INODE(fi)) ? ADDRS_PER_INODE(fi) :  \
-   (pgofs - ADDRS_PER_INODE(fi) + ADDRS_PER_BLOCK) /   \
-   ADDRS_PER_BLOCK * ADDRS_PER_BLOCK + ADDRS_PER_INODE(fi))
+#define PGOFS_OF_NEXT_DNODE(pgofs, inode)  \
+   ((pgofs < ADDRS_PER_INODE(inode)) ? ADDRS_PER_INODE(inode) :\
+   (pgofs - ADDRS_PER_INODE(inode) + ADDRS_PER_BLOCK) /\
+   ADDRS_PER_BLOCK * ADDRS_PER_BLOCK + ADDRS_PER_INODE(inode))
 
 /*
  * file.c
@@ -1906,7 +1906,7 @@ int f2fs_release_page(struct page *, gfp_t);
  */
 int start_gc_thread(struct f2fs_sb_info *);
 void stop_gc_thread(struct f2fs_sb_info *);
-block_t start_bidx_of_node(unsigned int, struct f2fs_inode_info *);
+block_t start_bidx_of_node(unsigned int, struct inode *);
 int f2fs_gc(struct f2fs_sb_info *, bool);
 void build_gc_manager(struct f2fs_sb_info *);
 
diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
index b19617e..f2b14e3 100644
--- a/fs/f2fs/file.c
+++ 

Re: connection failure after "tcp: remove max_qlen_log"

2016-01-25 Thread Kui Zhang
I was using 2.7.11.

Older version did set backlog to 1 ( http://bugs.python.org/issue8498 ).



On Sun, Jan 24, 2016 at 7:18 PM, Eric Dumazet  wrote:
> On Sun, Jan 24, 2016 at 2:17 AM, Kui Zhang  wrote:
>> We licensed the java software. As far as I can tell, the connection is
>> for IPC with a child process. There should not be large RTT.
>>
>> I will contact vendor regarding to listen(fd,0) issue, on Monday.
>>
>> I am not fully convinced, that is the problem. I saw that man page for
>> listen. However accept() works, in python, with backlog = 0. The java
>> software works with kernel build one commit before.
>
> Note that python (2.4.6 here) translates sock.listen(0) to listen(fd,
> 1), maybe to avoid surprises on some OS ;)
>
> $ cat lis.py
> #!/usr/bin/python
>
> import socket
> sock = socket.socket()
> sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
> sock.bind(('127.0.0.1',42000))
> sock.listen(0)
> s, a= sock.accept()
>
> s.send('test')
>
> $ strace ./lis.py
> ...
> close(5)= 0
> close(4)= 0
> close(3)= 0
> futex(0x8d8e460, FUTEX_WAKE, 1) = 0
> socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
> setsockopt(3, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
> bind(3, {sa_family=AF_INET, sin_port=htons(42000),
> sin_addr=inet_addr("127.0.0.1")}, 16) = 0
> listen(3, 1)= 0
> accept(3,


[PATCH v6 08/12] usb: dbc: handle endpoint stall

2016-01-25 Thread Lu Baolu
In case of endpoint stall, software is able to detect the situation
by reading DCCTRL.HIT or DCCTRL.HOT bits. DbC follows the normal USB
framework to handle endpoint stall. When software detects endpoint
stall situation, it should wait until endpoint is recovered before
read or write oprations.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 36 
 1 file changed, 36 insertions(+)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index c81df40..344d93e 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -1163,6 +1163,37 @@ static int xdbc_wait_until_dbc_configured(void)
return -ETIMEDOUT;
 }
 
+static int xdbc_wait_until_epstall_cleared(bool read)
+{
+   int timeout = 0;
+
+   if (read) {
+   do {
+   if (!(readl(>xdbc_reg->control) & CTRL_HIT)) {
+   xdbcp->in_ep_state = EP_RUNNING;
+
+   return 0;
+   }
+
+   xdbcp->in_ep_state = EP_HALTED;
+   xdbc_udelay(10);
+   } while (timeout++ < XDBC_LOOPS);
+   } else {
+   do {
+   if (!(readl(>xdbc_reg->control) & CTRL_HOT)) {
+   xdbcp->out_ep_state = EP_RUNNING;
+
+   return 0;
+   }
+
+   xdbcp->out_ep_state = EP_HALTED;
+   xdbc_udelay(10);
+   } while (timeout++ < XDBC_LOOPS);
+   }
+
+   return -ETIMEDOUT;
+}
+
 static int xdbc_bulk_transfer(void *data, int size, int loops, bool read)
 {
u64 addr;
@@ -1182,6 +1213,11 @@ static int xdbc_bulk_transfer(void *data, int size, int 
loops, bool read)
return -EPERM;
}
 
+   if (xdbc_wait_until_epstall_cleared(read)) {
+   xdbc_trace("%s: endpoint not ready\n", __func__);
+   return -EPERM;
+   }
+
ring = (read ? >in_ring : >out_ring);
trb = ring->enqueue;
cycle = ring->cycle_state;
-- 
2.1.4



[PATCH v6 11/12] usb: serial: usb_debug: add support for dbc debug device

2016-01-25 Thread Lu Baolu
This patch add dbc debug device support in usb_debug driver.

Signed-off-by: Lu Baolu 
Acked-by: Johan Hovold 
---
 drivers/usb/serial/usb_debug.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/drivers/usb/serial/usb_debug.c b/drivers/usb/serial/usb_debug.c
index ca2fa5b..92f7e5c 100644
--- a/drivers/usb/serial/usb_debug.c
+++ b/drivers/usb/serial/usb_debug.c
@@ -32,7 +32,18 @@ static const struct usb_device_id id_table[] = {
{ USB_DEVICE(0x0525, 0x127a) },
{ },
 };
-MODULE_DEVICE_TABLE(usb, id_table);
+
+static const struct usb_device_id dbc_id_table[] = {
+   { USB_DEVICE(0x1d6b, 0x0004) },
+   { },
+};
+
+static const struct usb_device_id id_table_combined[] = {
+   { USB_DEVICE(0x0525, 0x127a) },
+   { USB_DEVICE(0x1d6b, 0x0004) },
+   { },
+};
+MODULE_DEVICE_TABLE(usb, id_table_combined);
 
 /* This HW really does not support a serial break, so one will be
  * emulated when ever the break state is set to true.
@@ -71,9 +82,20 @@ static struct usb_serial_driver debug_device = {
.process_read_urb = usb_debug_process_read_urb,
 };
 
+static struct usb_serial_driver dbc_device = {
+   .driver = {
+   .owner =THIS_MODULE,
+   .name = "xhci_dbc",
+   },
+   .id_table = dbc_id_table,
+   .num_ports =1,
+   .break_ctl =usb_debug_break_ctl,
+   .process_read_urb = usb_debug_process_read_urb,
+};
+
 static struct usb_serial_driver * const serial_drivers[] = {
-   _device, NULL
+   _device, _device, NULL
 };
 
-module_usb_serial_driver(serial_drivers, id_table);
+module_usb_serial_driver(serial_drivers, id_table_combined);
 MODULE_LICENSE("GPL");
-- 
2.1.4



[PATCH v6 12/12] usb: doc: add document for xHCI DbC driver

2016-01-25 Thread Lu Baolu
Add Documentation/usb/xhci-dbc.txt. This document includes
development status and user guide for USB3 debug port.

Signed-off-by: Lu Baolu 
---
 Documentation/usb/xhci-dbc.txt | 350 +
 MAINTAINERS|   1 +
 drivers/usb/early/xhci-dbc.c   |   3 +
 3 files changed, 354 insertions(+)
 create mode 100644 Documentation/usb/xhci-dbc.txt

diff --git a/Documentation/usb/xhci-dbc.txt b/Documentation/usb/xhci-dbc.txt
new file mode 100644
index 000..564fd8f
--- /dev/null
+++ b/Documentation/usb/xhci-dbc.txt
@@ -0,0 +1,350 @@
+xHCI debug capability driver
+
+ Lu Baolu 
+
+Last-updated: September 2015
+
+
+   Contents:
+   -
+   * What is xHCI DbC?
+   * Debug topologies
+   * Debug stacks
+   * Port Multiplexing
+   * Hardware initialization
+   * External reset
+   * Port reset
+   * Interrupt/DMA/Memory during early boot
+   * Endpoint STALL
+   * Debug device information
+   * How to use DbC early printk?
+   * Limitations
+
+   What is xHCI DbC?
+   -
+
+The xHCI Debugging Capability defined in section 7.6 of xHCI spec 1.1
+provides an optional functionality that enables low-level system debug
+over USB. It provides a means of connecting two systems where one system
+is a Debug Host and the other a Debug Target (System Under Test). The
+Debug Capability provides an interface that is completely independent
+of the xHCI interface. A Debug Target enumerates as a USB debug device
+to the Debug Host, allowing a Debug Host to access a Debug Target through
+the standard USB software stack.
+
+   Debug topologies
+   
+
+Multiple Debug Targets may be attached to a single Debug Host. Debug
+Targets may be connected to any downstream facing port below a Debug
+Host (i.e. anywhere in the fabric, root port or external hub puts).
+A Debug Target may only connect to a Debug Host through a Root Hub port
+of the target. That means connection of a Debug Target to a Debug Host
+through the ports of an external hub is not supported.
+
+Below is a typical connection between Debug Host and Debug target. Two
+Debug targets are connected to a single Debug host.
+
+
+ 
+|   Debug Host   |  |  Debug Target  |
+||  ||
+|xHC without DbC |  |  xHC with DbC  |
+|or DbC disabled |  | enabled|
+||  ||
+|P1|  |p2|  |P1|  |p2|
+|__|  |__|  |__|  |__|
+  || |
+  ||_|
+  |_
+|
+ ___|
+|   HUB  |  |  Debug Target  |
+||  ||
+| Superspeed hub |  |  xHC with DbC  |
+||  | enabled|
+||  ||
+|P1|  |p2|  |P1|  |p2|
+|__|  |__|  |__|  |__|
+   | |
+   |_|
+
+   Debug stacks
+   
+
+Below is a software stack diagram of both Debug Host and Debug Target.
+
+ 
+|   Debug Host   |  |  Debug Target  |
+||  ||
+|   debug App|  ||
+||  | system debug   |
+|   usb_debug|  | hooks  |
+||  ||
+|usbcore |  ||
+||  |debug capability|
+|xhci_hcd|  | driver |
+||  ||
+|xHC without DbC |  |  xHC with DbC  |
+|or DbC disabled |  | enabled|
+||  ||
+|P1|  |p2|  |P1|  |p2|
+|__|  |__|  |__|  |__|
+   | |
+   |_|
+
+
+   Port Multiplexing
+   -
+
+A debug port is always multiplexed with the first xHCI root hub port.
+Whenever debug capability is supported and enabled, and the first root
+hub port is detected to be connected to a downstream super-speed port
+of a Debug Host, the root hub port 

[PATCH v6 10/12] usb: dbc: add handshake between debug target and host

2016-01-25 Thread Lu Baolu
After DbC setup, debug target needs to wait until tty driver and
application (e.g. mincom) on debug taget start.  Otherwise, out
messages might be ignored.

This patch adds a ping/pong mechanism between debug target and
host. Debug target will be waiting there until user presses 'Y'
or 'y' in the tty application.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 6c24ba0..37c5c87 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -32,6 +32,9 @@
 static struct xdbc_state xdbc_stat;
 static struct xdbc_state *xdbcp = _stat;
 
+static int early_xdbc_read(struct console *con, char *str, unsigned n);
+static void early_xdbc_write(struct console *con, const char *str, u32 n);
+
 #ifdef DBC_DEBUG
 #defineXDBC_DEBUG_BUF_SIZE (PAGE_SIZE * 32)
 #defineMSG_MAX_LINE128
@@ -860,8 +863,12 @@ int __init early_xdbc_init(char *s)
 {
u32 bus = 0, dev = 0, func = 0;
unsigned long dbgp_num = 0;
+   char *ping = "Press Y to continue...\n";
+   char pong[64];
+   size_t size;
u32 offset;
int ret;
+   int retry = 20;
 
if (!early_pci_allowed())
return -EPERM;
@@ -904,6 +911,21 @@ int __init early_xdbc_init(char *s)
return ret;
}
 
+   while (retry > 0) {
+   early_xdbc_write(NULL, ping, strlen(ping));
+   size = early_xdbc_read(NULL, pong, 64);
+   if (size > 0) {
+   xdbc_trace("%s: pong message: %s\n", __func__, pong);
+   if (pong[0] == 'Y' || pong[0] == 'y')
+   break;
+   } else {
+   xdbc_trace("%s: pong message error %d\n",
+   __func__, size);
+   }
+
+   retry--;
+   }
+
return 0;
 }
 
@@ -1325,6 +1347,11 @@ int xdbc_bulk_write(const char *bytes, int size)
  * Start a bulk-in or bulk-out transfer, wait until transfer completion
  * or error. Return the count of actually transferred bytes or error.
  */
+static int early_xdbc_read(struct console *con, char *str, unsigned n)
+{
+   return xdbc_bulk_read(str, n, 0);
+}
+
 static void early_xdbc_write(struct console *con, const char *str, u32 n)
 {
int chunk, ret;
-- 
2.1.4



[PATCH v6 09/12] x86: early_printk: add USB3 debug port earlyprintk support

2016-01-25 Thread Lu Baolu
Add support for early printk by writing debug messages to the USB3
debug port. Users can use this type of early printk by specifying
kernel parameter of "earlyprintk=xdbc". This gives users a chance
of providing debug output.

Signed-off-by: Lu Baolu 
---
 Documentation/kernel-parameters.txt |  1 +
 arch/x86/kernel/early_printk.c  |  5 +
 drivers/usb/early/xhci-dbc.c| 43 +
 include/linux/usb/xhci-dbc.h|  5 +
 4 files changed, 54 insertions(+)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 87d40a7..460dc73 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -1067,6 +1067,7 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
earlyprintk=ttySn[,baudrate]
earlyprintk=dbgp[debugController#]
earlyprintk=pciserial,bus:device.function[,baudrate]
+   earlyprintk=xdbc[xhciController#]
 
earlyprintk is useful when the kernel crashes before
the normal console is initialized. It is not enabled by
diff --git a/arch/x86/kernel/early_printk.c b/arch/x86/kernel/early_printk.c
index 21bf924..ba4c471 100644
--- a/arch/x86/kernel/early_printk.c
+++ b/arch/x86/kernel/early_printk.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -373,6 +374,10 @@ static int __init setup_early_printk(char *buf)
if (!strncmp(buf, "dbgp", 4) && !early_dbgp_init(buf + 4))
early_console_register(_dbgp_console, keep);
 #endif
+#ifdef CONFIG_EARLY_PRINTK_XDBC
+   if (!strncmp(buf, "xdbc", 4) && !early_xdbc_init(buf + 4))
+   early_console_register(_xdbc_console, keep);
+#endif
 #ifdef CONFIG_HVC_XEN
if (!strncmp(buf, "xen", 3))
early_console_register(_console, keep);
diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index 344d93e..6c24ba0 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -10,6 +10,7 @@
  * it under the terms of the GNU General Public License version 2 as
  * published by the Free Software Foundation.
  */
+#include 
 #include 
 #include 
 #include 
@@ -1319,3 +1320,45 @@ int xdbc_bulk_write(const char *bytes, int size)
 
return ret;
 }
+
+/*
+ * Start a bulk-in or bulk-out transfer, wait until transfer completion
+ * or error. Return the count of actually transferred bytes or error.
+ */
+static void early_xdbc_write(struct console *con, const char *str, u32 n)
+{
+   int chunk, ret;
+   static char buf[XDBC_MAX_PACKET];
+   int use_cr = 0;
+
+   if (!xdbcp->xdbc_reg)
+   return;
+   memset(buf, 0, XDBC_MAX_PACKET);
+   while (n > 0) {
+   for (chunk = 0; chunk < XDBC_MAX_PACKET && n > 0;
+str++, chunk++, n--) {
+   if (!use_cr && *str == '\n') {
+   use_cr = 1;
+   buf[chunk] = '\r';
+   str--;
+   n++;
+   continue;
+   }
+   if (use_cr)
+   use_cr = 0;
+   buf[chunk] = *str;
+   }
+   if (chunk > 0) {
+   ret = xdbc_bulk_write(buf, chunk);
+   if (ret < 0)
+   break;
+   }
+   }
+}
+
+struct console early_xdbc_console = {
+   .name = "earlyxdbc",
+   .write =early_xdbc_write,
+   .flags =CON_PRINTBUFFER,
+   .index =-1,
+};
diff --git a/include/linux/usb/xhci-dbc.h b/include/linux/usb/xhci-dbc.h
index 289ba58..a556eb8 100644
--- a/include/linux/usb/xhci-dbc.h
+++ b/include/linux/usb/xhci-dbc.h
@@ -216,4 +216,9 @@ struct xdbc_state {
 #definexdbc_read64(regs)   xhci_read_64(NULL, (regs))
 #definexdbc_write64(val, regs) xhci_write_64(NULL, (val), (regs))
 
+#ifdef CONFIG_EARLY_PRINTK_XDBC
+extern int early_xdbc_init(char *s);
+extern struct console early_xdbc_console;
+#endif /* CONFIG_EARLY_PRINTK_XDBC */
+
 #endif /* __LINUX_XHCI_DBC_H */
-- 
2.1.4



[PATCH v6 07/12] usb: dbc: handle dbc-configured exit

2016-01-25 Thread Lu Baolu
DbC might exit configured state in some cases (refer to 7.6.4.4 in
xHCI spec 1.1). Software needs detect and clear this situation by
clearing DCCTRL.DCR and wait until the DbC configured before read
or write oprations.

Signed-off-by: Lu Baolu 
---
 drivers/usb/early/xhci-dbc.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/drivers/usb/early/xhci-dbc.c b/drivers/usb/early/xhci-dbc.c
index f59c80ef..c81df40 100644
--- a/drivers/usb/early/xhci-dbc.c
+++ b/drivers/usb/early/xhci-dbc.c
@@ -1140,6 +1140,29 @@ static int xdbc_wait_until_bulk_done(struct xdbc_trb 
*trb, int loops)
return -EIO;
 }
 
+static int xdbc_wait_until_dbc_configured(void)
+{
+   int timeout = 0;
+   u32 reg;
+
+   /* Port exits configured state */
+   reg = readl(>xdbc_reg->control);
+   if (!(reg & CTRL_DRC))
+   return 0;
+
+   /* clear run change bit (RW1C) */
+   writel(reg | CTRL_DRC, >xdbc_reg->control);
+
+   do {
+   if (readl(>xdbc_reg->control) & CTRL_DCR)
+   return 0;
+
+   xdbc_udelay(10);
+   } while (timeout++ < XDBC_LOOPS);
+
+   return -ETIMEDOUT;
+}
+
 static int xdbc_bulk_transfer(void *data, int size, int loops, bool read)
 {
u64 addr;
@@ -1154,6 +1177,11 @@ static int xdbc_bulk_transfer(void *data, int size, int 
loops, bool read)
return -EINVAL;
}
 
+   if (xdbc_wait_until_dbc_configured()) {
+   xdbc_trace("%s: hardware not ready\n", __func__);
+   return -EPERM;
+   }
+
ring = (read ? >in_ring : >out_ring);
trb = ring->enqueue;
cycle = ring->cycle_state;
-- 
2.1.4



Re: [PATCH] drm/exynos: fix building without CONFIG_PM_SLEEP

2016-01-25 Thread Inki Dae


2016년 01월 26일 08:40에 Krzysztof Kozlowski 이(가) 쓴 글:
> 2015-11-18 0:08 GMT+09:00 Arnd Bergmann :
>> The runtime PM operations use the suspend/resume functions
>> even when CONFIG_PM_SLEEP is not set, but this now fails
>> for the exynos DRM driver:
>>
>> exynos_mixer.c:1289:61: error: 'exynos_mixer_resume' undeclared here (not in 
>> a function)
>>   SET_RUNTIME_PM_OPS(exynos_mixer_suspend, exynos_mixer_resume, NULL)
>>
>> This removes the #ifdef and instead marks the functions as
>> __maybe_unused, which does the right thing in all cases and
>> also looks nicer.
>>
>> Signed-off-by: Arnd Bergmann 
>> Fixes:   ("drm/exynos: add pm_runtime to Mixer")
> 
> Dear Inki,
> 
> Ping? On 4.5-rc1 this is still broken. Can you apply this for fixes
> for current rc-cycle?

Got it.

Thanks,
Inki Dae

> 
> Reviewed-by: Krzysztof Kozlowski 
> 
> Best regards,
> Krzysztof
> 
> 
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c 
>> b/drivers/gpu/drm/exynos/exynos_mixer.c
>> index 7498c6e76a53..fcaf71df77c1 100644
>> --- a/drivers/gpu/drm/exynos/exynos_mixer.c
>> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c
>> @@ -1230,8 +1230,7 @@ static int mixer_remove(struct platform_device *pdev)
>> return 0;
>>  }
>>
>> -#ifdef CONFIG_PM_SLEEP
>> -static int exynos_mixer_suspend(struct device *dev)
>> +static int __maybe_unused exynos_mixer_suspend(struct device *dev)
>>  {
>> struct mixer_context *ctx = dev_get_drvdata(dev);
>> struct mixer_resources *res = >mixer_res;
>> @@ -1247,7 +1246,7 @@ static int exynos_mixer_suspend(struct device *dev)
>> return 0;
>>  }
>>
>> -static int exynos_mixer_resume(struct device *dev)
>> +static int __maybe_unused exynos_mixer_resume(struct device *dev)
>>  {
>> struct mixer_context *ctx = dev_get_drvdata(dev);
>> struct mixer_resources *res = >mixer_res;
>> @@ -1283,7 +1282,6 @@ static int exynos_mixer_resume(struct device *dev)
>>
>> return 0;
>>  }
>> -#endif
>>
>>  static const struct dev_pm_ops exynos_mixer_pm_ops = {
>> SET_RUNTIME_PM_OPS(exynos_mixer_suspend, exynos_mixer_resume, NULL)
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
>> in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> --
> To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" 
> in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
> 


Re: [PATCH] Add hard/soft lockup debugger entry points

2016-01-25 Thread Jeff Merkey
On 1/25/16, kbuild test robot <l...@intel.com> wrote:
> Hi Jeff,
>
> [auto build test ERROR on v4.5-rc1]
> [also build test ERROR on next-20160125]
> [if your patch is applied to the wrong git tree, please drop us a note to
> help improving the system]
>
> url:
> https://github.com/0day-ci/linux/commits/Jeff-Merkey/Add-hard-soft-lockup-debugger-entry-points/20160126-103801
> config: sparc64-defconfig (attached as .config)
> 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=sparc64
>
> All errors (new ones prefixed by >>):
>
>{standard input}: Assembler messages:
>>> {standard input}:335: Error: Unknown opcode: `int'
>
> ---
> 0-DAY kernel test infrastructureOpen Source Technology
> Center
> https://lists.01.org/pipermail/kbuild-all   Intel
> Corporation
>

I am resubmitting this with the correct arch_hw_bp.  Wow, That test
robot is very efficient.

Jeff


Re: [PATCH] rtc: mt6397: add IRQ domain dependency

2016-01-25 Thread Eddie Huang
On Mon, 2016-01-25 at 17:04 +0100, Arnd Bergmann wrote:
> The mt6397 RTC driver can be built either when the MFD_MT6397 driver
> is enabled (which selects IRQ_DOMAIN), or when compile testing.
> The latter however fails without IRQ domains:
> 
> drivers/rtc/rtc-mt6397.c: In function 'mtk_rtc_probe':
> drivers/rtc/rtc-mt6397.c:326:13: error: implicit declaration of function 
> 'irq_create_mapping' [-Werror=implicit-function-declaration]
>   rtc->irq = irq_create_mapping(mt6397_chip->irq_domain, res->start);
> 
> This adds an explicit dependency for the COMPILE_TEST case.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/rtc/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index 376322f71fd5..4395608bf7fc 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -1603,7 +1603,7 @@ config RTC_DRV_MOXART
>  
>  config RTC_DRV_MT6397
>   tristate "Mediatek Real Time Clock driver"
> - depends on MFD_MT6397 || COMPILE_TEST
> + depends on MFD_MT6397 || (COMPILE_TEST && IRQ_DOMAIN)
>   help
> This selects the Mediatek(R) RTC driver. RTC is part of Mediatek
> MT6397 PMIC. You should enable MT6397 PMIC MFD before select

Hi Arnd,

Thanks your correction.
Acked-by: Eddie Huang 

Regards,
Eddie




Re: [v3,11/41] mips: reuse asm-generic/barrier.h

2016-01-25 Thread Paul E. McKenney
On Mon, Jan 25, 2016 at 02:41:34PM +, Will Deacon wrote:
> On Fri, Jan 15, 2016 at 11:28:45AM -0800, Paul E. McKenney wrote:
> > On Fri, Jan 15, 2016 at 09:54:01AM -0800, Paul E. McKenney wrote:
> > > On Fri, Jan 15, 2016 at 10:24:32AM +, Will Deacon wrote:
> > > > See my earlier reply [1] (but also, your WRC Linux example looks more
> > > > like a variant on WWC and I couldn't really follow it).
> > > 
> > > I will revisit my WRC Linux example.  And yes, creating litmus tests
> > > that use non-fake dependencies is still a bit of an undertaking.  :-/
> > > I am sure that it will seem more natural with time and experience...
> > 
> > Hmmm...  You are quite right, I did do WWC.  I need to change cpu2()'s
> > last access from a store to a load to get WRC.  Plus the levels of
> > indirection definitely didn't match up, did they?
> 
> Nope, it was pretty baffling!

"It is a service that I provide."  ;-)

> > struct foo {
> > struct foo *next;
> > };
> > struct foo a;
> > struct foo b;
> > struct foo c = {  };
> > struct foo d = {  };
> > struct foo x = {  };
> > struct foo y = {  };
> > struct foo *r1, *r2, *r3;
> > 
> > void cpu0(void)
> > {
> > WRITE_ONCE(x.next, );
> > }
> > 
> > void cpu1(void)
> > {
> > r1 = lockless_dereference(x.next);
> > WRITE_ONCE(r1->next, );
> > }
> > 
> > void cpu2(void)
> > {
> > r2 = lockless_dereference(y.next);
> > r3 = READ_ONCE(r2->next);
> > }
> > 
> > In this case, it is legal to end the run with:
> > 
> > r1 ==  && r2 ==  && r3 == 
> > 
> > Please see below for a ppcmem litmus test.
> > 
> > So, did I get it right this time?  ;-)
> 
> The code above looks correct to me (in that it matches WRC+addrs),
> but your litmus test:
> 
> > PPC WRCnf+addrs
> > ""
> > {
> > 0:r2=x; 0:r3=y;
> > 1:r2=x; 1:r3=y;
> > 2:r2=x; 2:r3=y;
> > c=a; d=b; x=c; y=d;
> > }
> >  P0   | P1| P2;
> >  stw r3,0(r2) | lwz r8,0(r2)  | lwz r8,0(r3)  ;
> >   | stw r2,0(r3)  | lwz r9,0(r8)  ;
> > exists
> > (1:r8=y /\ 2:r8=x /\ 2:r9=c)
> 
> Seems to be missing the address dependency on P1.

You are quite correct!  How about the following?

As before, both herd and ppcmem say that the cycle is allowed, as
expected, given non-transitive ordering.  To prohibit the cycle, P1
needs a suitable memory-barrier instruction.

Thanx, Paul



PPC WRCnf+addrs
""
{
0:r2=x; 0:r3=y;
1:r2=x; 1:r3=y;
2:r2=x; 2:r3=y;
c=a; d=b; x=c; y=d;
}
 P0   | P1| P2;
 stw r3,0(r2) | lwz r8,0(r2)  | lwz r8,0(r3)  ;
  | stw r2,0(r8)  | lwz r9,0(r8)  ;
exists
(1:r8=y /\ 2:r8=x /\ 2:r9=c)

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



Re: [RFC PATCH] mm: support CONFIG_ZONE_DEVICE + CONFIG_ZONE_DMA

2016-01-25 Thread Sudip Mukherjee
On Mon, Jan 25, 2016 at 04:06:40PM -0800, Dan Williams wrote:
> It appears devices requiring ZONE_DMA are still prevalent (see link
> below).  For this reason the proposal to require turning off ZONE_DMA to
> enable ZONE_DEVICE is untenable in the short term.  We want a single
> kernel image to be able to support legacy devices as well as next
> generation persistent memory platforms.
> 
> Towards this end, alias ZONE_DMA and ZONE_DEVICE to work around needing
> to maintain a unique zone number for ZONE_DEVICE.  Record the geometry
> of ZONE_DMA at init (->init_spanned_pages) and use that information in
> is_zone_device_page() to differentiate pages allocated via
> devm_memremap_pages() vs true ZONE_DMA pages.  Otherwise, use the
> simpler definition of is_zone_device_page() when ZONE_DMA is turned off.
> 
> Note that this also teaches the memory hot remove path that the zone may
> not have sections for all pfn spans (->zone_dyn_start_pfn).
> 
> A user visible implication of this change is potentially an unexpectedly
> high "spanned" value in /proc/zoneinfo for the DMA zone.
> 
> Cc: H. Peter Anvin 
> Cc: Ingo Molnar 
> Cc: Rik van Riel 
> Cc: Mel Gorman 
> Cc: Jerome Glisse 
> Cc: Christoph Hellwig 
> Cc: Dave Hansen 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=110931
> Fixes: 033fbae988fc ("mm: ZONE_DEVICE for "device memory"")
> Reported-by: Sudip Mukherjee 

It should actually be Reported-by: Mark 

Hi Mark,
Can you please test this patch available at 
https://patchwork.kernel.org/patch/8116991/
in your setup..

regards
sudip


Re: [alsa-devel] [PATCH] ALSA: bebob: Use a signed return type for get_formation_index

2016-01-25 Thread Takashi Iwai
On Mon, 25 Jan 2016 22:30:23 +0100,
Lucas Tanure wrote:
> 
> The return type "unsigned int" was used by the get_formation_index function
> despite of the aspect that it will eventually return a negative   error 
> code.
> So, change to signed int and get index by reference in the parameters.
> 
> Done with the help of Coccinelle.
> 
> Signed-off-by: Lucas Tanure 

Applied, thanks.


Takashi

> ---
>  sound/firewire/bebob/bebob_stream.c | 11 +++
>  1 file changed, 7 insertions(+), 4 deletions(-)
> 
> diff --git a/sound/firewire/bebob/bebob_stream.c 
> b/sound/firewire/bebob/bebob_stream.c
> index 926e5dc..79940e3 100644
> --- a/sound/firewire/bebob/bebob_stream.c
> +++ b/sound/firewire/bebob/bebob_stream.c
> @@ -47,14 +47,15 @@ static const unsigned int bridgeco_freq_table[] = {
>   [6] = 0x07,
>  };
>  
> -static unsigned int
> -get_formation_index(unsigned int rate)
> +static int
> +get_formation_index(unsigned int rate, unsigned int *index)
>  {
>   unsigned int i;
>  
>   for (i = 0; i < ARRAY_SIZE(snd_bebob_rate_table); i++) {
>   if (snd_bebob_rate_table[i] == rate)
> - return i;
> + *index = i;
> + return 0;
>   }
>   return -EINVAL;
>  }
> @@ -425,7 +426,9 @@ make_both_connections(struct snd_bebob *bebob, unsigned 
> int rate)
>   goto end;
>  
>   /* confirm params for both streams */
> - index = get_formation_index(rate);
> + err = get_formation_index(rate, );
> + if (err < 0)
> + goto end;
>   pcm_channels = bebob->tx_stream_formations[index].pcm;
>   midi_channels = bebob->tx_stream_formations[index].midi;
>   err = amdtp_am824_set_parameters(>tx_stream, rate,
> -- 
> 2.7.0
> 
> ___
> Alsa-devel mailing list
> alsa-de...@alsa-project.org
> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> 


[PATCH] x86/dmi: Switch dmi_remap to ioremap_cache

2016-01-25 Thread Andy Lutomirski
DMI cacheability is very confused on x86.

dmi_early_remap uses early_ioremap, which uses FIXMAP_PAGE_IO, which
is __PAGE_KERNEL_IO, which is __PAGE_KERNEL, which is cached.  Don't
ask me why this makes any sense.

dmi_remap uses ioremap, which requests an uncached mapping.
However, on non-EFI systems, the DMI data generally lives between
0xf and 0x10, which is in the legacy ISA range, which
triggers a special case in the PAT code that overrides the cache
mode requested by ioremap and forces a WB mapping.

On a UEFI boot, however, the DMI table can live at any physical
address.  On my laptop, it's around 0x77dd.  That's nowhere near
the legacy ISA range, so the ioremap implicit uncached type is
honored and we end up with a UC- mapping.

UC- is a very, very slow way to read from main memory, so dmi_walk
is likely to take much longer than necessary.

Given that, even on UEFI, we do early cached DMI reads, it seems
safe to just ask for cached access.  Switch to ioremap_cache.

I haven't tried to benchmark this, but I'd guess it saves several
milliseconds of boot time.

Signed-off-by: Andy Lutomirski 
---
 arch/x86/include/asm/dmi.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/include/asm/dmi.h b/arch/x86/include/asm/dmi.h
index 535192f6bfad..3c69fed215c5 100644
--- a/arch/x86/include/asm/dmi.h
+++ b/arch/x86/include/asm/dmi.h
@@ -15,7 +15,7 @@ static __always_inline __init void *dmi_alloc(unsigned len)
 /* Use early IO mappings for DMI because it's initialized early */
 #define dmi_early_remapearly_ioremap
 #define dmi_early_unmapearly_iounmap
-#define dmi_remap  ioremap
+#define dmi_remap  ioremap_cache
 #define dmi_unmap  iounmap
 
 #endif /* _ASM_X86_DMI_H */
-- 
2.5.0



Re: [Patch V2 1/9] clk: tegra: Fix divider on VI_I2C

2016-01-25 Thread Thierry Reding
On Thu, Jan 14, 2016 at 02:24:30PM -0500, Rhyland Klein wrote:
> VI-I2C has 16 bits available for its divider. Switch the divider
> width to 16 instead of 8 so correct rates can be set.
> 
> Signed-off-by: Rhyland Klein 
> ---
>  drivers/clk/tegra/clk-tegra-periph.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature


Re: [PATCH 1/3] gpio: gpio-ich: add support for Intel Baytrail

2016-01-25 Thread Lee Jones
On Sat, 23 Jan 2016, Antoine Tenart wrote:

> This patch adds support for the Braytrail series, with the hardware
> blink capability.
> 
> Signed-off-by: Antoine Tenart 
> ---
>  drivers/gpio/gpio-ich.c | 12 
>  include/linux/mfd/lpc_ich.h |  1 +

Acked-by: Lee Jones 

>  2 files changed, 13 insertions(+)
> 
> diff --git a/drivers/gpio/gpio-ich.c b/drivers/gpio/gpio-ich.c
> index 4ba7ed502131..6f5fcae32855 100644
> --- a/drivers/gpio/gpio-ich.c
> +++ b/drivers/gpio/gpio-ich.c
> @@ -384,6 +384,15 @@ static struct ichx_desc avoton_desc = {
>   .use_outlvl_cache = true,
>  };
>  
> +/* Baytrail */
> +static struct ichx_desc baytrail_desc = {
> + .ngpio = 96,
> + .regs = ichx_regs,
> + .reglen = ichx_reglen,
> + .have_blink = true,
> + .use_outlvl_cache = true,
> +};
> +
>  static int ichx_gpio_request_regions(struct resource *res_base,
>   const char *name, u8 use_gpio)
>  {
> @@ -461,6 +470,9 @@ static int ichx_gpio_probe(struct platform_device *pdev)
>   case AVOTON_GPIO:
>   ichx_priv.desc = _desc;
>   break;
> + case ICH_BAYTRAIL_GPIO:
> + ichx_priv.desc = _desc;
> + break;
>   default:
>   return -ENODEV;
>   }
> diff --git a/include/linux/mfd/lpc_ich.h b/include/linux/mfd/lpc_ich.h
> index 2b300b44f994..659a1cd875d8 100644
> --- a/include/linux/mfd/lpc_ich.h
> +++ b/include/linux/mfd/lpc_ich.h
> @@ -34,6 +34,7 @@ enum {
>   ICH_V10CORP_GPIO,
>   ICH_V10CONS_GPIO,
>   AVOTON_GPIO,
> + ICH_BAYTRAIL_GPIO,
>  };
>  
>  struct lpc_ich_info {

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH 2/3] mfd: lpc_ich: use a correct mask for the GPIO base address

2016-01-25 Thread Lee Jones
On Sat, 23 Jan 2016, Antoine Tenart wrote:

> The GPIO base address is read from the GPIOBASE register. The first
> bit must be cleared as it can be hardwired to 1 to represent the i/o
> space. Other bits are either containing the base address of are
> reserved. They should not be cleared as all the chipsets do not have
> the same reserved bits.
> 
> Signed-off-by: Antoine Tenart 
> ---
>  drivers/mfd/lpc_ich.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Applied, thanks.

> diff --git a/drivers/mfd/lpc_ich.c b/drivers/mfd/lpc_ich.c
> index b514f3cf140d..f13a5ded3958 100644
> --- a/drivers/mfd/lpc_ich.c
> +++ b/drivers/mfd/lpc_ich.c
> @@ -921,7 +921,10 @@ static int lpc_ich_init_gpio(struct pci_dev *dev)
>  gpe0_done:
>   /* Setup GPIO base register */
>   pci_read_config_dword(dev, priv->gbase, _addr_cfg);
> - base_addr = base_addr_cfg & 0xff80;
> +
> + /* Clear the i/o flag */
> + base_addr = base_addr_cfg & ~BIT(0);
> +
>   if (!base_addr) {
>   dev_notice(>dev, "I/O space for GPIO uninitialized\n");
>   ret = -ENODEV;

-- 
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog


Re: [PATCH v2 3/4] arm64: Enable the timer on Rockchip architecture

2016-01-25 Thread Heiko Stübner
Am Freitag, 25. September 2015, 10:14:57 schrieb Caesar Wang:
> On the RK3368 SoC, support the APB timers for rockchip platform.
> 
> Signed-off-by: Caesar Wang 

applied to my soc64 branch for 4.6


Heiko


Re: [PATCH 1/2] regulator: ltc3589: make IRQ optional

2016-01-25 Thread Mark Brown
On Mon, Jan 25, 2016 at 01:51:09PM +0100, Lothar Waßmann wrote:
> On Mon, 25 Jan 2016 12:41:23 + Mark Brown wrote:

> > The above, for example - make the interrupt optional.

> This will make it impossible to notify the system about
> overtemperature (and undervoltage).
> I implemented polling to be able to get at least overtemperature
> warnings.
> (Undervoltage cannot be handled sensibly without interrupt anyway)

I'm not convinced that justifies constantly polling, if the system
designers cared you'd hope they'd have wired it up to a working
interrupt.  People commonly don't, realistically thermal warnings are
usually set near the point where the silicon will be physically damaged
and typically by the time they fire the system is already experiencing
catastrophic problems at a system level.

The polling is at the very least a separate change, and making the
interrupt work would be a much better option.


signature.asc
Description: PGP signature


[PATCH] mm/page-writeback: fix dirty_ratelimit calculation

2016-01-25 Thread Andrey Ryabinin
Calculation of dirty_ratelimit sometimes is not correct.
E.g. initial values of dirty_ratelimit == INIT_BW and step == 0,
lead to the following result:

   UBSAN: Undefined behaviour in ../mm/page-writeback.c:1286:7
   shift exponent 25600 is too large for 64-bit type 'long unsigned int'

The fix is straightforward - make step 0 if the shift exponent is too big.

Signed-off-by: Andrey Ryabinin 
---
 mm/page-writeback.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/mm/page-writeback.c b/mm/page-writeback.c
index 6fe7d15..d782cba 100644
--- a/mm/page-writeback.c
+++ b/mm/page-writeback.c
@@ -1169,6 +1169,7 @@ static void wb_update_dirty_ratelimit(struct 
dirty_throttle_control *dtc,
unsigned long balanced_dirty_ratelimit;
unsigned long step;
unsigned long x;
+   unsigned long shift;
 
/*
 * The dirty rate will match the writeout rate in long term, except
@@ -1293,11 +1294,11 @@ static void wb_update_dirty_ratelimit(struct 
dirty_throttle_control *dtc,
 * rate itself is constantly fluctuating. So decrease the track speed
 * when it gets close to the target. Helps eliminate pointless tremors.
 */
-   step >>= dirty_ratelimit / (2 * step + 1);
-   /*
-* Limit the tracking speed to avoid overshooting.
-*/
-   step = (step + 7) / 8;
+   shift = dirty_ratelimit / (2 * step + 1);
+   if (shift < BITS_PER_LONG)
+   step = DIV_ROUND_UP(step >> shift, 8);
+   else
+   step = 0;
 
if (dirty_ratelimit < balanced_dirty_ratelimit)
dirty_ratelimit += step;
-- 
2.4.10



[PATCH v4 3/3] kallsyms: add support for relative offsets in kallsyms address table

2016-01-25 Thread Ard Biesheuvel
Similar to how relative extables are implemented, it is possible to emit
the kallsyms table in such a way that it contains offsets relative to some
anchor point in the kernel image rather than absolute addresses.

On 64-bit architectures, it cuts the size of the kallsyms address table in
half, since offsets between kernel symbols can typically be expressed in 32
bits. This saves several hundreds of kilobytes of permanent .rodata on
average. In addition, the kallsyms address table is no longer subject to
dynamic relocation when CONFIG_RELOCATABLE is in effect, so the relocation
work done after decompression now doesn't have to do relocation updates for
all these values. This saves up to 24 bytes (i.e., the size of a ELF64 RELA
relocation table entry) per value, which easily adds up to a couple of
megabytes of uncompressed __init data on ppc64 or arm64. Even if these
relocation entries typically compress well, the combined size reduction of
2.8 MB uncompressed for a ppc64_defconfig build (of which 2.4 MB is __init
data) results in a ~500 KB space saving in the compressed image.

Since it is useful for some architectures (like x86) to retain the ability
to emit absolute values as well, this patch adds support for both, by
emitting absolute addresses as positive 32-bit values, and addresses
relative to the lowest encountered relative symbol as negative values,
which are subtracted from the runtime address of this base symbol to
produce the actual address.

Support for the above is enabled by default for all architectures except
IA-64, whose symbols are too far apart to capture in this manner.

Signed-off-by: Ard Biesheuvel 
---
 init/Kconfig| 16 
 kernel/kallsyms.c   | 38 +++--
 scripts/kallsyms.c  | 88 +---
 scripts/link-vmlinux.sh |  4 +
 scripts/namespace.pl|  2 +
 5 files changed, 129 insertions(+), 19 deletions(-)

diff --git a/init/Kconfig b/init/Kconfig
index 22320804fbaf..1cc72a068afc 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -1420,6 +1420,22 @@ config KALLSYMS_ALL
 
   Say N unless you really need all symbols.
 
+config KALLSYMS_BASE_RELATIVE
+   bool
+   depends on KALLSYMS
+   default !IA64
+   help
+ Instead of emitting them as absolute values in the native word size,
+ emit the symbol references in the kallsyms table as 32-bit entries,
+ each containing either an absolute value in the range [0, S32_MAX] or
+ a relative value in the range [base, base + S32_MAX], where base is
+ the lowest relative symbol address encountered in the image.
+
+ On 64-bit builds, this reduces the size of the address table by 50%,
+ but more importantly, it results in entries whose values are build
+ time constants, and no relocation pass is required at runtime to fix
+ up the entries based on the runtime load address of the kernel.
+
 config PRINTK
default y
bool "Enable support for printk" if EXPERT
diff --git a/kernel/kallsyms.c b/kernel/kallsyms.c
index 5c5987f10819..10a8af9d5744 100644
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -38,6 +38,7 @@
  * during the second link stage.
  */
 extern const unsigned long kallsyms_addresses[] __weak;
+extern const int kallsyms_offsets[] __weak;
 extern const u8 kallsyms_names[] __weak;
 
 /*
@@ -47,6 +48,9 @@ extern const u8 kallsyms_names[] __weak;
 extern const unsigned long kallsyms_num_syms
 __attribute__((weak, section(".rodata")));
 
+extern const unsigned long kallsyms_relative_base
+__attribute__((weak, section(".rodata")));
+
 extern const u8 kallsyms_token_table[] __weak;
 extern const u16 kallsyms_token_index[] __weak;
 
@@ -176,6 +180,19 @@ static unsigned int get_symbol_offset(unsigned long pos)
return name - kallsyms_names;
 }
 
+static unsigned long kallsyms_sym_address(int idx)
+{
+   if (!IS_ENABLED(CONFIG_KALLSYMS_BASE_RELATIVE))
+   return kallsyms_addresses[idx];
+
+   /* positive offsets are absolute values */
+   if (kallsyms_offsets[idx] >= 0)
+   return kallsyms_offsets[idx];
+
+   /* negative offsets are relative to kallsyms_relative_base - 1 */
+   return kallsyms_relative_base - 1 - kallsyms_offsets[idx];
+}
+
 /* Lookup the address for this symbol. Returns 0 if not found. */
 unsigned long kallsyms_lookup_name(const char *name)
 {
@@ -187,7 +204,7 @@ unsigned long kallsyms_lookup_name(const char *name)
off = kallsyms_expand_symbol(off, namebuf, ARRAY_SIZE(namebuf));
 
if (strcmp(namebuf, name) == 0)
-   return kallsyms_addresses[i];
+   return kallsyms_sym_address(i);
}
return module_kallsyms_lookup_name(name);
 }
@@ -204,7 +221,7 @@ int kallsyms_on_each_symbol(int (*fn)(void *, const char *, 
struct module *,
 
for (i = 0, off = 0; i < kallsyms_num_syms; i++) {
off = 

[PATCH v4 0/3] kallsyms base relative series

2016-01-25 Thread Ard Biesheuvel
This v4 of my kallsyms base relative implementation is now a 3 piece series,
since it caused some problems due to the way absolute symbols are handled
by the absolute per cpu code. As it turns out, that code was probably wrong
in the sense that it caused non-relocated symbol addresses to be emitted
for values that are in fact relative to the address of the kernel text.

Patch #1 fixes the scripts/kallsyms invocation to only pass the x86_64
specific --absolute-percpu option if CONFIG_SMP is also set.

Patch #2 reworks the absolute percpu code to only emit those percpu symbols
as absolute, and not symbols that have been classified as 'A' (absolute) by
the linker, since that does not mean quite the same thing.

Patch #3 is the original kallsyms base relative patch, with some
modifications:
- folded the s/ULLONG_MAX/-1ULL? change made by Andrew
- ensured that the kallsyms_relative_base value itself is relocated as
  required.
- dropped all of the acks and other tags, as they have become outdated with
  the recent changes to this patch.

Ard Biesheuvel (3):
  x86: kallsyms: disable absolute percpu symbols on !SMP
  kallsyms: don't overload absolute symbol type for percpu symbols
  kallsyms: add support for relative offsets in kallsyms address table

 init/Kconfig|  16 +++
 kernel/kallsyms.c   |  38 ++--
 scripts/kallsyms.c  | 102 +---
 scripts/link-vmlinux.sh |   6 +-
 scripts/namespace.pl|   2 +
 5 files changed, 142 insertions(+), 22 deletions(-)

-- 
2.5.0



Re: net/sctp: out-of-bounds access in sctp_add_bind_addr

2016-01-25 Thread Neil Horman
On Mon, Jan 25, 2016 at 03:02:38PM +0100, Dmitry Vyukov wrote:
> Hello,
> 
> I've git the following error report while running syzkaller fuzzer:
> 
> ==
> BUG: KASAN: slab-out-of-bounds in memcpy+0x1d/0x40 at addr 88006c6361e8
> Read of size 28 by task syz-executor/12551
> =
> BUG kmalloc-16 (Not tainted): kasan: bad access detected
> -
> 
> INFO: Allocated in sctp_setsockopt_bindx+0xd2/0x3e0 age=12 cpu=2 pid=12551
> [< inline >] kmalloc include/linux/slab.h:468
> [<  none  >] sctp_setsockopt_bindx+0xd2/0x3e0 net/sctp/socket.c:975
> [<  none  >] sctp_setsockopt+0x1493/0x3630 net/sctp/socket.c:3711
> [<  none  >] sock_common_setsockopt+0x97/0xd0 net/core/sock.c:2620
> [< inline >] SYSC_setsockopt net/socket.c:1752
> [<  none  >] SyS_setsockopt+0x15b/0x250 net/socket.c:1731
> [<  none  >] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
> 
> INFO: Slab 0xea0001b18d80 objects=16 used=4 fp=0x88006c6376e0
> flags=0x5fffc004080
> INFO: Object 0x88006c6361e8 @offset=488 fp=0x0002
> Bytes b4 88006c6361d8: 00 00 00 00 00 00 00 00 2f 98 34 88 ff ff
> ff ff  /.4.
> Object 88006c6361e8: 02 00 00 00 00 00 00 00 02 00 ab 07 7f 00 00
> 01  
> CPU: 2 PID: 12551 Comm: syz-executor Tainted: GB   4.5.0-rc1+ #278
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>   880036397928 8299a02d 88003e807900
>  88006c6361e8 88006c636000 880036397958 81752814
>  88003e807900 ea0001b18d80 88006c6361e8 88006c6361e8
> 
> Call Trace:
>  [] __asan_loadN+0x124/0x1a0 mm/kasan/kasan.c:512
>  [] memcpy+0x1d/0x40 mm/kasan/kasan.c:297
>  [] sctp_add_bind_addr+0xa9/0x270 net/sctp/bind_addr.c:162
>  [] sctp_do_bind+0x336/0x580 net/sctp/socket.c:389
>  [] sctp_bindx_add+0xac/0x1a0 net/sctp/socket.c:471
>  [] sctp_setsockopt_bindx+0x2f8/0x3e0 net/sctp/socket.c:1010
>  [] sctp_setsockopt+0x1493/0x3630 net/sctp/socket.c:3711
>  [] sock_common_setsockopt+0x97/0xd0 net/core/sock.c:2620
>  [< inline >] SYSC_setsockopt net/socket.c:1752
>  [] SyS_setsockopt+0x15b/0x250 net/socket.c:1731
>  [] entry_SYSCALL_64_fastpath+0x16/0x7a
> arch/x86/entry/entry_64.S:185
> 
> Memory state around the buggy address:
>  88006c636080: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>  88006c636100: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> >88006c636180: fc fc fc fc fc fc fc fc fc fc fc fc fc 00 00 fc
> ^
>  88006c636200: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
>  88006c636280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
> ==
> 
> 
> sctp_setsockopt_bindx verifies that the user-passed address has valid
> len for the specified family, but then sctp_add_bind_addr copies whole
> sctp_addr from there. This causes heap out-of-bounds access and can
> crash kernel. Not sure if it is possible to copy out the trailing
> garbage to user-space later.
> 

It does more than that though.  sctp_setsockopt_bindx checks the following:
1) That passed addr_size is greater than zero
2) that the entire range of memory between addrs and addrs+addr_size is readable
3) That at least one address structure worth of data is available (implicit in
the while (walk_size < addr_size) loop).

Could one of the sockaddr_len fields in one of the addresses have been mangled
so that it appeared shorter in the the while loop from (3), so that a copy of
sizeof(sctp_addr in sctp_add_bind_addr overrun the allocated memory?

Neil

> On commit 92e963f50fc74041b5e9e744c330dca48e04f08d (Jan 25).
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 


Re: [PATCH 1/4] hw_random: bcm63xx-rng: remove unused variables

2016-01-25 Thread Herbert Xu
On Sun, Jan 17, 2016 at 10:03:54AM +0100, Álvaro Fernández Rojas wrote:
> These variables where left as unused in commit 6229c16060fe
> ("hwrng: bcm63xx - make use of devm_hwrng_register")
> 
> Fixes the following warning:
> drivers/char/hw_random/bcm63xx-rng.c: In function 'bcm63xx_rng_probe':
> drivers/char/hw_random/bcm63xx-rng.c:85:16: warning: unused variable 'rng'
> [-Wunused-variable]
>   struct hwrng *rng;
> ^
> drivers/char/hw_random/bcm63xx-rng.c:82:14: warning: unused variable 'clk'
> [-Wunused-variable]
>   struct clk *clk;
> 
> Signed-off-by: Álvaro Fernández Rojas 

All applied.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


Re: [PATCH 0/5] crypto: atmel-sha: fix registration issue and other bugs

2016-01-25 Thread Herbert Xu
On Fri, Jan 15, 2016 at 03:49:30PM +0100, Cyrille Pitchen wrote:
> Hi all,
> 
> This series of patches fixes many issues such as the algo registration failure
> or the broken support of context switches.
> 
> This series was applied to linux-next and tested on a sama5d2 xplained
> ultra board. We now pass the tcrypt tests in the following modes:
> -  2: sha1
> -  6: sha256
> - 11: sha384
> - 12: sha512
> - 33: sha224
> 
> The context switch fix was tested with a userspace program using the cryptodev
> module. This single thread program computes the SHA256 hashes of many files
> by splitting then into fixed size chunks. The chunks of each file are
> processed by calling 'update' operations using a round robin algorithm.
> 
> However, the .import() / .export() implementation was NOT tested!
> Nonetheless the last patch is needed to fix the registration issue, otherwise
> atmel_sha_probe() would still fail.

Patch 1-4 applied.  Please fix the alignment issue with patch 5.
-- 
Email: Herbert Xu 
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt


  1   2   3   4   5   6   7   8   9   10   >