Re: [PATCH 1/3] usb: orion-echi: Add support for the Armada 3700

[Thomas Petazzoni]

Hello,

On Wed,  8 Mar 2017 17:24:21 +0100, Gregory CLEMENT wrote:

> Signed-off-by: jinghua 

I think you need a full first name + last name for this Signed-off-by.

Best regards,

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [tpmdd-devel] [PATCH] vTPM: Fix missing NULL check

[Jason Gunthorpe]

On Wed, Mar 08, 2017 at 03:28:11PM -0500, Hon Ching(Vicky) Lo wrote:
> On Wed, 2017-03-08 at 10:17 -0700, Jason Gunthorpe wrote:
> > On Tue, Mar 07, 2017 at 11:12:43PM -0500, Hon Ching(Vicky) Lo wrote:
> > > On Mon, 2017-03-06 at 16:19 -0700, Jason Gunthorpe wrote:
> > 
> > > > Also, how does locking work here? Does the vio core prevent
> > > > tpm_ibmvtpm_get_desired_dma and tpm_ibmvtpm_remove from running
> > > > concurrently?
> > > 
> > > No, vio core doesn't prevent tpm_ibmvtpm_get_desired_dma and 
> > > tpm_ibmvtpm_remove
> > > from running concurrently.
> > > 
> > > vio_bus_probe calls vio_cmo_bus_probe which calls 
> > > tpm_ibmvtpm_get_desired_dma.
> > > tpm_ibmvtpm_get_desired_dma is called before the code enters critical 
> > > section.
> > > 
> > > There is no locking mechanism around tpm_ibmvtpm_remove in vio_bus_remove.
> > > 
> > > What's the concern here?
> > 
> > tpm_ibmvtpm_remove makes the pointer that tpm_ibmvtpm_get_desired_dma
> > is accessing invalid, so some kind of locking is technically required
> > so that the two things do not create a use after free race:
> 
> I don't think we need to worry about locking in this specific case. 
> tpm_ibmvtpm_get_desired_dma was designed to return a default value
> in the case when the chip is not available.

You have to worry about it to prevent a use after free race:

  CPU0CPU1
tpm_ibmvtpm_remove() tpm_ibmvtpm_get_desired_dma()

 chip = dev_get_drvdata(dev);
dev_set_drvdata(>dev, NULL);
 if (chip)
ibmvtpm = dev_get_drvdata(>dev);
kfree(ibmvtpm);
// *ibmvtpm is now a use-after-free

Jason

Re: [PATCH v1 3/4] arm/syscalls: Specific usage of verify_pre_usermode_state

[Russell King - ARM Linux]

On Wed, Mar 08, 2017 at 01:38:43PM -0800, Thomas Garnier wrote:
> Implement specific usage of verify_pre_usermode_state for user-mode
> returns for arm.
> ---
> Based on next-20170308
> ---
>  arch/arm/Kconfig   | 1 +
>  arch/arm/kernel/entry-common.S | 5 +
>  2 files changed, 6 insertions(+)
> 
> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> index 0d4e71b42c77..704fd8f197fa 100644
> --- a/arch/arm/Kconfig
> +++ b/arch/arm/Kconfig
> @@ -12,6 +12,7 @@ config ARM
>   select ARCH_HAVE_CUSTOM_GPIO_H
>   select ARCH_HAS_GCOV_PROFILE_ALL
>   select ARCH_MIGHT_HAVE_PC_PARPORT
> + select ARCH_NO_SYSCALL_VERIFY_PRE_USERMODE_STATE
>   select ARCH_OPTIONAL_KERNEL_RWX if ARCH_HAS_STRICT_KERNEL_RWX
>   select ARCH_OPTIONAL_KERNEL_RWX_DEFAULT if CPU_V7
>   select ARCH_SUPPORTS_ATOMIC_RMW
> diff --git a/arch/arm/kernel/entry-common.S b/arch/arm/kernel/entry-common.S
> index eb5cd77bf1d8..80cfdc7fabde 100644
> --- a/arch/arm/kernel/entry-common.S
> +++ b/arch/arm/kernel/entry-common.S
> @@ -39,6 +39,9 @@
>  ret_fast_syscall:
>   UNWIND(.fnstart )
>   UNWIND(.cantunwind  )
> + push{r0}@ save returned r0
> + bl  verify_pre_usermode_state
> + pop {r0}@ restore r0

This really makes the fast exit utterly pointless, and we might as well
rip all that out.

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

Re: Dell Inspiron 5558/0VNM2T hangs at resume from suspend when USB 3 is enabled

[Diego Viola]

On Wed, Mar 8, 2017 at 3:49 PM, Diego Viola  wrote:
> It hangs on resume from suspend if I have USB 3.0 enabled on the BIOS,
> it works fine with ehci_hcd or USB 2.0.
>
> The way I reproduce the problem is with this command:
>
> $ i3lock && systemctl suspend
>
> This is what I see on the screen when it hangs:
>
> https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170308_095000.jpg
> https://dl.dropboxusercontent.com/u/6005119/dell/IMG_20170307_133928.jpg
>
> Some logs:
>
> https://dl.dropboxusercontent.com/u/6005119/dell/dmesg1.txt
> https://dl.dropboxusercontent.com/u/6005119/dell/dmesg2.txt
>
> I'm on Arch Linux x86_64, kernel 4.9.11-1-ARCH.
>
> I also tried Linux 4.10.1 and I could reproduce this problem there as well.
>
> Please let me know if I could provide more info.
>
> Thanks,
> Diego

I've created a bug report here.

https://bugzilla.kernel.org/show_bug.cgi?id=194819

Diego

Re: [PATCH] f2fs: allocate a bio for discarding when actually issuing it

[Jaegeuk Kim]

On 03/08, Christoph Hellwig wrote:
> On Tue, Mar 07, 2017 at 06:33:33PM -0800, Jaegeuk Kim wrote:
> > Let's allocate a bio when issuing discard commands later.
> 
> Does this solve the issue with your queue stalls?

No, the patch just changes bio_alloc timings, but the stall happens when doing
submit_bio.

Thanks,

> 
> > 
> > Signed-off-by: Jaegeuk Kim 
> > ---
> >  fs/f2fs/f2fs.h|   4 +-
> >  fs/f2fs/segment.c | 113 
> > --
> >  2 files changed, 62 insertions(+), 55 deletions(-)
> > 
> > diff --git a/fs/f2fs/f2fs.h b/fs/f2fs/f2fs.h
> > index a58c2e43bd2a..870bb4d9bc65 100644
> > --- a/fs/f2fs/f2fs.h
> > +++ b/fs/f2fs/f2fs.h
> > @@ -197,10 +197,12 @@ enum {
> >  struct discard_cmd {
> > struct list_head list;  /* command list */
> > struct completion wait; /* compleation */
> > +   struct block_device *bdev;  /* bdev */
> > block_t lstart; /* logical start address */
> > +   block_t start;  /* actual start address in dev */
> > block_t len;/* length */
> > -   struct bio *bio;/* bio */
> > int state;  /* state */
> > +   int error;  /* bio error */
> >  };
> >  
> >  struct discard_cmd_control {
> > diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> > index 50c65cc4645a..d8f9e6c895cd 100644
> > --- a/fs/f2fs/segment.c
> > +++ b/fs/f2fs/segment.c
> > @@ -636,7 +636,8 @@ static void locate_dirty_segment(struct f2fs_sb_info 
> > *sbi, unsigned int segno)
> >  }
> >  
> >  static void __add_discard_cmd(struct f2fs_sb_info *sbi,
> > -   struct bio *bio, block_t lstart, block_t len)
> > +   struct block_device *bdev, block_t lstart,
> > +   block_t start, block_t len)
> >  {
> > struct discard_cmd_control *dcc = SM_I(sbi)->dcc_info;
> > struct list_head *cmd_list = &(dcc->discard_cmd_list);
> > @@ -644,9 +645,9 @@ static void __add_discard_cmd(struct f2fs_sb_info *sbi,
> >  
> > dc = f2fs_kmem_cache_alloc(discard_cmd_slab, GFP_NOFS);
> > INIT_LIST_HEAD(>list);
> > -   dc->bio = bio;
> > -   bio->bi_private = dc;
> > +   dc->bdev = bdev;
> > dc->lstart = lstart;
> > +   dc->start = start;
> > dc->len = len;
> > dc->state = D_PREP;
> > init_completion(>wait);
> > @@ -658,22 +659,66 @@ static void __add_discard_cmd(struct f2fs_sb_info 
> > *sbi,
> >  
> >  static void __remove_discard_cmd(struct f2fs_sb_info *sbi, struct 
> > discard_cmd *dc)
> >  {
> > -   int err = dc->bio->bi_error;
> > -
> > if (dc->state == D_DONE)
> > atomic_dec(&(SM_I(sbi)->dcc_info->submit_discard));
> >  
> > -   if (err == -EOPNOTSUPP)
> > -   err = 0;
> > +   if (dc->error == -EOPNOTSUPP)
> > +   dc->error = 0;
> >  
> > -   if (err)
> > +   if (dc->error)
> > f2fs_msg(sbi->sb, KERN_INFO,
> > -   "Issue discard failed, ret: %d", err);
> > -   bio_put(dc->bio);
> > +   "Issue discard failed, ret: %d", dc->error);
> > list_del(>list);
> > kmem_cache_free(discard_cmd_slab, dc);
> >  }
> >  
> > +static void f2fs_submit_discard_endio(struct bio *bio)
> > +{
> > +   struct discard_cmd *dc = (struct discard_cmd *)bio->bi_private;
> > +
> > +   complete(>wait);
> > +   dc->error = bio->bi_error;
> > +   dc->state = D_DONE;
> > +   bio_put(bio);
> > +}
> > +
> > +/* this function is copied from blkdev_issue_discard from block/blk-lib.c 
> > */
> > +static int __submit_discard_cmd(struct discard_cmd *dc)
> > +{
> > +   struct bio *bio = NULL;
> > +   int err;
> > +
> > +   err = __blkdev_issue_discard(dc->bdev,
> > +   SECTOR_FROM_BLOCK(dc->start),
> > +   SECTOR_FROM_BLOCK(dc->len),
> > +   GFP_NOFS, 0, );
> > +   if (!err && bio) {
> > +   bio->bi_private = dc;
> > +   bio->bi_end_io = f2fs_submit_discard_endio;
> > +   bio->bi_opf |= REQ_SYNC;
> > +   submit_bio(bio);
> > +   }
> > +   dc->state = D_SUBMIT;
> > +   return err;
> > +}
> > +
> > +static int __queue_discard_cmd(struct f2fs_sb_info *sbi,
> > +   struct block_device *bdev, block_t blkstart, block_t blklen)
> > +{
> > +   block_t lblkstart = blkstart;
> > +
> > +   trace_f2fs_issue_discard(bdev, blkstart, blklen);
> > +
> > +   if (sbi->s_ndevs) {
> > +   int devi = f2fs_target_device_index(sbi, blkstart);
> > +
> > +   blkstart -= FDEV(devi).start_blk;
> > +   }
> > +   __add_discard_cmd(sbi, bdev, lblkstart, blkstart, blklen);
> > +   wake_up(_I(sbi)->dcc_info->discard_wait_queue);
> > +   return 0;
> > +}
> > +
> >  /* This should be covered by global mutex, _i->sentry_lock */
> >  void f2fs_wait_discard_bio(struct f2fs_sb_info *sbi, block_t blkaddr)
> >  {
> > @@ -690,8 +735,7 @@ void f2fs_wait_discard_bio(struct f2fs_sb_info *sbi, 
> > block_t blkaddr)
> >  
> >   

Re: [Question] devm_kmalloc() for DMA ?

[Lars-Peter Clausen]

On 03/08/2017 07:06 PM, Masahiro Yamada wrote:
> Hi Robin,
> 
> 
> 2017-03-08 20:15 GMT+09:00 Robin Murphy :
>> On 08/03/17 10:59, Masahiro Yamada wrote:
>>> Hi experts,
>>>
>>> I have a question about
>>> how to allocate DMA-safe buffer.
>>>
>>>
>>> In my understanding, kmalloc() returns
>>> memory with DMA safe alignment
>>> in order to avoid cache-sharing problem when used for DMA.
>>>
>>> The alignment is decided by ARCH_DMA_MINALIGN.
>>> For example, on modern ARM 32bit boards, this value is typically 64.
>>> So, memory returned by kmalloc() has
>>> at least 64 byte alignment.
>>>
>>>
>>> On the other hand, devm_kmalloc() does not return
>>> enough-aligned memory.
>>
>> How so? If anything returned by kmalloc() is guaranteed to occupy some
>> multiple of ARCH_DMA_MINALIGN bytes in order to avoid two allocations
>> falling into the same cache line, I don't see how stealing the first 16
>> bytes *of a single allocation* could make it start sharing cache lines
>> with another? :/
> 
> I just thought of traverse of the linked list of devres_node
> on a different thread, but it should not happen.

When the DMA memory is mapped for reading from the device the associated
cachelines are invalidated without writeback. There is no guarantee that the
changes made to the devres_node have made it to main memory yet, or is
there? So those updates could be lost and you'd get a data structure corruption.

[PATCH 3/5] sym53c8xx_2: Convert to use memset32()

[Matthew Wilcox]

From: Matthew Wilcox 

memset32() can be used to initialise these three arrays.  Minor code
footprint reduction.

Signed-off-by: Matthew Wilcox 
---
 drivers/scsi/sym53c8xx_2/sym_hipd.c | 11 +++
 1 file changed, 3 insertions(+), 8 deletions(-)

diff --git a/drivers/scsi/sym53c8xx_2/sym_hipd.c 
b/drivers/scsi/sym53c8xx_2/sym_hipd.c
index 6b349e301869..b886b10e3499 100644
--- a/drivers/scsi/sym53c8xx_2/sym_hipd.c
+++ b/drivers/scsi/sym53c8xx_2/sym_hipd.c
@@ -4985,13 +4985,10 @@ struct sym_lcb *sym_alloc_lcb (struct sym_hcb *np, 
u_char tn, u_char ln)
 *  Compute the bus address of this table.
 */
if (ln && !tp->luntbl) {
-   int i;
-
tp->luntbl = sym_calloc_dma(256, "LUNTBL");
if (!tp->luntbl)
goto fail;
-   for (i = 0 ; i < 64 ; i++)
-   tp->luntbl[i] = cpu_to_scr(vtobus(>badlun_sa));
+   memset32(tp->luntbl, cpu_to_scr(vtobus(>badlun_sa)), 64);
tp->head.luntbl_sa = cpu_to_scr(vtobus(tp->luntbl));
}
 
@@ -5077,8 +5074,7 @@ static void sym_alloc_lcb_tags (struct sym_hcb *np, 
u_char tn, u_char ln)
/*
 *  Initialize the task table with invalid entries.
 */
-   for (i = 0 ; i < SYM_CONF_MAX_TASK ; i++)
-   lp->itlq_tbl[i] = cpu_to_scr(np->notask_ba);
+   memset32(lp->itlq_tbl, cpu_to_scr(np->notask_ba), SYM_CONF_MAX_TASK);
 
/*
 *  Fill up the tag buffer with tag numbers.
@@ -5764,8 +5760,7 @@ int sym_hcb_attach(struct Scsi_Host *shost, struct sym_fw 
*fw, struct sym_nvram
goto attach_failed;
 
np->badlun_sa = cpu_to_scr(SCRIPTB_BA(np, resel_bad_lun));
-   for (i = 0 ; i < 64 ; i++)  /* 64 luns/target, no less */
-   np->badluntbl[i] = cpu_to_scr(vtobus(>badlun_sa));
+   memset32(np->badluntbl, cpu_to_scr(vtobus(>badlun_sa)), 64);
 
/*
 *  Prepare the bus address array that contains the bus 
-- 
2.11.0

[RFC 0/5] memset_l and memfill

[Matthew Wilcox]

From: Matthew Wilcox 

zram was recently enhanced to support compressing pages with a repeating
pattern up to the size of an unsigned long.  As part of the discussion,
we noted it would be nice if architectures had optimised routines to
fill regions of memory with patterns larger than those contained in a
single byte.

The memfill() function exists as part of Lars Wirzenius' publib, but
it's not necessarily the most convenient interface to use.  So I offer
four interfaces as part of this patchset -- memset_l (long), memset32
(32-bit), memset64 (64-bit) and memfill (arbitrary length).

We have one user in this patchset for each of memset32() and memset_l().
Patches to convert more users would be welcome.  In particular, there
aren't any users for the generic memfill() yet.  Requests for memset_p
(pointer), memset16 and memset_s (short) would be interesting.  memset_ll
(long long), or other suggestions that would lead to compiling memset64()
on 32-bit would also be interesting.

I'd also like to see assembly language mavens produce optimised
memset32/memset64 implementations for their pet architecture.  I've
included my awful test-suite for your benefit; it did find a few bugs
in memfill() while I was getting the edge cases nailed down.

Matthew Wilcox (5):
  Add memset_l(), memset32() and memset64()
  zram: Convert to using memset_l()
  sym53c8xx_2: Convert to use memset32()
  Add memfill()
  Hacky testsuite for memfill() and memset_l()

 drivers/block/zram/zram_drv.c | 15 +
 drivers/scsi/sym53c8xx_2/sym_hipd.c   | 11 +---
 include/linux/string.h| 16 +
 lib/string.c  | 85 +++
 tools/include/linux/compiler.h|  5 ++
 tools/include/linux/string.h  | 11 
 tools/testing/radix-tree/asm/page.h   |  0
 tools/testing/radix-tree/asm/word-at-a-time.h |  1 +
 tools/testing/radix-tree/linux/ctype.h|  0
 tools/testing/radix-tree/linux/kernel.h   |  2 +
 tools/testing/radix-tree/string.c | 53 +
 11 files changed, 179 insertions(+), 20 deletions(-)
 create mode 100644 tools/testing/radix-tree/asm/page.h
 create mode 100644 tools/testing/radix-tree/asm/word-at-a-time.h
 create mode 100644 tools/testing/radix-tree/linux/ctype.h
 create mode 100644 tools/testing/radix-tree/string.c

-- 
2.11.0

[PATCH] [media] vcodec: mediatek: fix platform_no_drv_owner.cocci warnings

[kbuild test robot]

drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c:1296:3-8: No need to set .owner 
here. The core will do it.

 Remove .owner field if calls are used which set it automatically

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

CC: Rick Chang 
Signed-off-by: Fengguang Wu 
---

 mtk_jpeg_core.c |1 -
 1 file changed, 1 deletion(-)

--- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
+++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
@@ -1293,7 +1293,6 @@ static struct platform_driver mtk_jpeg_d
.probe = mtk_jpeg_probe,
.remove = mtk_jpeg_remove,
.driver = {
-   .owner  = THIS_MODULE,
.name   = MTK_JPEG_NAME,
.of_match_table = mtk_jpeg_match,
.pm = _jpeg_pm_ops,

Re: [PATCH 5/7] xen/9pfs: send requests to the backend

[Boris Ostrovsky]

>> There is no extra read of prod/cons.
> Yes, there are: just after this if statement we would have to read them
> again to calculate masked_prod and masked_cons.

Ah, of course. Thanks.

-boris

Re: [PATCH v3] Input: sparse-keymap - use a managed allocation for keymap copy

[Andy Shevchenko]

On Wed, Mar 8, 2017 at 8:12 PM, Dmitry Torokhov
 wrote:
> On Wed, Mar 08, 2017 at 09:22:17AM +0100, Michał Kępień wrote:
>> Some platform drivers use devm_input_allocate_device() together with
>> sparse_keymap_setup() in their .probe callbacks.  While using the former
>> simplifies error handling, using the latter necessitates calling
>> sparse_keymap_free() in the error path and upon module unloading to
>> avoid leaking the copy of the keymap allocated by sparse_keymap_setup().
>>
>> To help prevent such leaks and enable simpler error handling, make
>> sparse_keymap_setup() use devm_kmemdup() to create the keymap copy so
>> that it gets automatically freed.
>>
>> This works for both managed and non-managed input devices as the keymap
>> is freed after the last reference to the input device is dropped.
>>
>> Note that actions previously taken by sparse_keymap_free(), i.e. taking
>> the input device's mutex and zeroing its keycode and keycodemax fields,
>> are now redundant because the managed keymap will always be freed after
>> the input device is unregistered.

> OK, I think this looks good. Do platform folks want an immutable branch
> off 4.10 with this change so we can start cleaning sparse_keymap_free()
> users in this cycle?

If there PDx86 related patches are anticipated this cycle, definitely
we need an immutable branch (perhaps based on v4.11-rc1).

-- 
With Best Regards,
Andy Shevchenko

Re: [PATCH v3] Input: sparse-keymap - use a managed allocation for keymap copy

[Dmitry Torokhov]

On Wed, Mar 08, 2017 at 10:50:16PM +0200, Andy Shevchenko wrote:
> On Wed, Mar 8, 2017 at 8:12 PM, Dmitry Torokhov
>  wrote:
> > On Wed, Mar 08, 2017 at 09:22:17AM +0100, Michał Kępień wrote:
> >> Some platform drivers use devm_input_allocate_device() together with
> >> sparse_keymap_setup() in their .probe callbacks.  While using the former
> >> simplifies error handling, using the latter necessitates calling
> >> sparse_keymap_free() in the error path and upon module unloading to
> >> avoid leaking the copy of the keymap allocated by sparse_keymap_setup().
> >>
> >> To help prevent such leaks and enable simpler error handling, make
> >> sparse_keymap_setup() use devm_kmemdup() to create the keymap copy so
> >> that it gets automatically freed.
> >>
> >> This works for both managed and non-managed input devices as the keymap
> >> is freed after the last reference to the input device is dropped.
> >>
> >> Note that actions previously taken by sparse_keymap_free(), i.e. taking
> >> the input device's mutex and zeroing its keycode and keycodemax fields,
> >> are now redundant because the managed keymap will always be freed after
> >> the input device is unregistered.
> 
> > OK, I think this looks good. Do platform folks want an immutable branch
> > off 4.10 with this change so we can start cleaning sparse_keymap_free()
> > users in this cycle?
> 
> If there PDx86 related patches are anticipated this cycle, definitely
> we need an immutable branch (perhaps based on v4.11-rc1).

OK, I'll make one (based on 4.10 final - the patch should apply cleanly
there and there is no point of forcing anyone's workflow to use kernel
in the beginning of stabilization cycle).

As to whether there are PDx86 patches - I hope Michał will supply them
;) I'll take care of the 2 instances in drivers/input/misc.

Thanks.

-- 
Dmitry

[PATCH 2/2] MIPS: NI 169445 board support

[Nathan Sullivan]

Support the National Instruments 169445 board.

Signed-off-by: Nathan Sullivan 
---
 Documentation/devicetree/bindings/mips/ni.txt   |   7 ++
 MAINTAINERS |   8 ++
 arch/mips/boot/dts/Makefile |   1 +
 arch/mips/boot/dts/ni/169445.dts| 101 
 arch/mips/boot/dts/ni/Makefile  |   7 ++
 arch/mips/configs/generic/board-ni169445.config |  27 +++
 arch/mips/generic/Kconfig   |   6 ++
 arch/mips/generic/vmlinux.its.S |  25 ++
 8 files changed, 182 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/mips/ni.txt
 create mode 100644 arch/mips/boot/dts/ni/169445.dts
 create mode 100644 arch/mips/boot/dts/ni/Makefile
 create mode 100644 arch/mips/configs/generic/board-ni169445.config

diff --git a/Documentation/devicetree/bindings/mips/ni.txt 
b/Documentation/devicetree/bindings/mips/ni.txt
new file mode 100644
index 000..722bf2d
--- /dev/null
+++ b/Documentation/devicetree/bindings/mips/ni.txt
@@ -0,0 +1,7 @@
+National Instruments MIPS platforms
+
+required root node properties:
+   - compatible: must be "ni,169445"
+
+CPU Nodes
+   - compatible: must be "mti,mips14KEc"
diff --git a/MAINTAINERS b/MAINTAINERS
index c265a5f..b72f059 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8887,6 +8887,14 @@ F:   include/linux/sunrpc/
 F: include/uapi/linux/nfs*
 F: include/uapi/linux/sunrpc/
 
+NI169445 MIPS ARCHITECTURE
+M: Nathan Sullivan 
+L: linux-m...@linux-mips.org
+S: Maintained
+F: arch/mips/boot/dts/ni/
+F: arch/mips/configs/generic/board-ni169445.config
+F: Documentation/devicetree/bindings/mips/ni.txt
+
 NILFS2 FILESYSTEM
 M: Ryusuke Konishi 
 L: linux-ni...@vger.kernel.org
diff --git a/arch/mips/boot/dts/Makefile b/arch/mips/boot/dts/Makefile
index b9db492..27b0f37 100644
--- a/arch/mips/boot/dts/Makefile
+++ b/arch/mips/boot/dts/Makefile
@@ -4,6 +4,7 @@ dts-dirs+= img
 dts-dirs   += ingenic
 dts-dirs   += lantiq
 dts-dirs   += mti
+dts-dirs   += ni
 dts-dirs   += netlogic
 dts-dirs   += pic32
 dts-dirs   += qca
diff --git a/arch/mips/boot/dts/ni/169445.dts b/arch/mips/boot/dts/ni/169445.dts
new file mode 100644
index 000..58e74b5
--- /dev/null
+++ b/arch/mips/boot/dts/ni/169445.dts
@@ -0,0 +1,101 @@
+/dts-v1/;
+
+/ {
+   #address-cells = <1>;
+   #size-cells = <1>;
+   compatible = "ni,169445";
+
+   cpus {
+   #address-cells = <1>;
+   #size-cells = <0>;
+   cpu@0 {
+   device_type = "cpu";
+   compatible = "mti,mips14KEc";
+   clocks = <>;
+   reg = <0>;
+   };
+   };
+
+   memory@0 {
+   device_type = "memory";
+   reg = <0x0 0x1000>;
+   };
+
+   baseclk: baseclock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <5000>;
+   };
+
+   cpu_intc: cpu_intc {
+   #address-cells = <0>;
+   compatible = "mti,cpu-interrupt-controller";
+   interrupt-controller;
+   #interrupt-cells = <1>;
+   };
+
+   ahb@0 {
+   compatible = "simple-bus";
+   #address-cells = <1>;
+   #size-cells = <1>;
+   ranges = <0x0 0x1f30 0x80FFF>;
+
+   gpio1:gpio-controller@1f300010 {
+   compatible = "ni,169445-nand-gpio";
+   reg = <0x10 0x4>;
+   reg-names = "dat";
+   gpio-controller;
+   #gpio-cells = <2>;
+   ngpios = <5>;
+   };
+
+   gpio2:gpio-controller@1f300014 {
+   compatible = "ni,169445-nand-gpio";
+   reg = <0x14 0x4>;
+   reg-names = "dat";
+   gpio-controller;
+   #gpio-cells = <2>;
+   ngpios = <1>;
+   };
+
+   nand@1f30 {
+   compatible = "gpio-control-nand";
+   nand-on-flash-bbt;
+   nand-ecc-mode = "soft_bch";
+   nand-ecc-step-size = <512>;
+   nand-ecc-strength = <4>;
+   reg = <0x0 4>;
+   gpios = < 0 0>, /* rdy */
+   < 1 0>, /* nce */
+   < 2 0>, /* ale */
+   < 3 0>, /* cle */
+   < 4 0>; /* nwp */
+   };
+
+   serial@1f38 {
+   compatible = "ns16550a";
+   reg = <0x8 0x1000>;
+  

Re: [Question] devm_kmalloc() for DMA ?

[Russell King - ARM Linux]

On Wed, Mar 08, 2017 at 09:44:17PM +0100, Lars-Peter Clausen wrote:
> On 03/08/2017 08:59 PM, Russell King - ARM Linux wrote:
> > On Wed, Mar 08, 2017 at 08:48:31PM +0100, Lars-Peter Clausen wrote:
> >> When the DMA memory is mapped for reading from the device the associated
> >> cachelines are invalidated without writeback. There is no guarantee that
> >> the changes made to the devres_node have made it to main memory yet, or
> >> is there?
> > 
> > That is incorrect.
> > 
> > Overlapping cache lines are always written back on transitions from CPU
> > to device ownership of the buffer (eg, dma_map_*().)
> 
> On ARM. But my understanding is that this is not a universal requirement
> according to DMA-API.txt. It says that mappings must be cache line aligned
> and otherwise behavior is undefined.

There is no use of the term "undefined" in the document you refer to.

There is the recommendation that regions are cache line aligned, but
there is quite a bit of history in the kernel where DMA has been to
regions that are not cache line aligned, and where the DMA region
overlaps with data that has recent accesses made to it.

The situation is improving (in that DMA buffers are being allocated
separately, rather than being part of some other structure) but that
doesn't mean that it's safe to assume that overlapping cache lines can
be invalidated.

In any case, DMA with devm allocated buffers really is not a good idea.
The lifetime of devm allocated buffers is between their allocation and
the point that the driver is unbound (either via probe failure or
removal.)  If that turns out to be shorter than DMA, then you end up
scribbing over free'd memory.

Moreover, any memory that is dma_map'd must be dma_unmap'd before
being freed.

So, unless we're going to get devm_* stuff for DMA API and for ensuring
that DMA is disabled, I don't think using devm_k*alloc() with DMA is
really a good idea.

Take the fact that it returns memory that is not cache line aligned to
be a big clue that it shouldn't be used for this purpose.

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

Re: [PATCH 5/7] xen/9pfs: send requests to the backend

[Stefano Stabellini]

On Wed, 8 Mar 2017, Boris Ostrovsky wrote:
> On 03/08/2017 02:33 PM, Stefano Stabellini wrote:
> > On Wed, 8 Mar 2017, Boris Ostrovsky wrote:
> > +}
> > +
> > +static int p9_xen_write_todo(struct xen_9pfs_dataring *ring, RING_IDX 
> > size)
> > +{
> > +   RING_IDX cons, prod;
> > +
> > +   cons = ring->intf->out_cons;
> > +   prod = ring->intf->out_prod;
> > +   mb();
> > +
> > +   if (XEN_9PFS_RING_SIZE - xen_9pfs_queued(prod, cons, 
> > XEN_9PFS_RING_SIZE) >= size)
> > +   return 1;
> > +   else
> > +   return 0;
> >  }
> >  
> >  static int p9_xen_request(struct p9_client *client, struct p9_req_t 
> > *p9_req)
> >  {
> > +   struct xen_9pfs_front_priv *priv = NULL;
> > +   RING_IDX cons, prod, masked_cons, masked_prod;
> > +   unsigned long flags;
> > +   uint32_t size = p9_req->tc->size;
> > +   struct xen_9pfs_dataring *ring;
> > +   int num;
> > +
> > +   list_for_each_entry(priv, _9pfs_devs, list) {
> > +   if (priv->client == client)
> > +   break;
> > +   }
> > +   if (priv == NULL || priv->client != client)
> > +   return -EINVAL;
> > +
> > +   num = p9_req->tc->tag % priv->num_rings;
> > +   ring = >rings[num];
> > +
> > +again:
> > +   while (wait_event_interruptible(ring->wq,
> > +   p9_xen_write_todo(ring, size) > 0) != 
> > 0);
> > +
> > +   spin_lock_irqsave(>lock, flags);
> > +   cons = ring->intf->out_cons;
> > +   prod = ring->intf->out_prod;
> > +   mb();
> > +
> > +   if (XEN_9PFS_RING_SIZE - xen_9pfs_queued(prod, cons, 
> > XEN_9PFS_RING_SIZE) < size) {
>  This looks like p9_xen_write_todo().
> >>> p9_xen_write_todo is just a wrapper around xen_9pfs_queued to provide
> >>> a return value that works well with wait_event_interruptible.
> >>>
> >>> I would prefer not to call p9_xen_write_todo here, because it's simpler
> >>> if we don't read prod and cons twice.
> >> I was referring to the whole code fragment after spin_lock_irqsave(),
> >> not just the last line. Isn't it exactly !p9_xen_write_todo()?
> > Yes, it is true they are almost the same. The difference, and the reason
> > for p9_xen_write_todo to exist, is that p9_xen_write_todo is called in
> > the wait_event_interruptible loop, as such it needs to read prod and
> > cons every time. On the other end, here we want to read them once. Does
> > it make sense?
> 
> 
> I am clearly being particularly dense here but what I was thinking was:
> 
> again:
>   while (wait_event_interruptible(ring->wq,
>   p9_xen_write_todo(ring, size) > 0) != 0);
> 
>   spin_lock_irqsave(>lock, flags);
>   if (!p9_xen_write_todo(ring, size)) {
>   spin_unlock_irqrestore(>lock, flags);
>   goto again;
>   }
> 
> There is no extra read of prod/cons.

Yes, there are: just after this if statement we would have to read them
again to calculate masked_prod and masked_cons.

Re: v4.10: kernel stack frame pointer .. has bad value (null)

[Josh Poimboeuf]

[adding Steven Rostedt to CC as an FYI]

On Wed, Mar 08, 2017 at 10:25:01AM -0800, Linus Torvalds wrote:
> On Wed, Mar 8, 2017 at 9:37 AM, Josh Poimboeuf  wrote:
> > - CONFIG_FUNCTION_GRAPH_TRACER sets it on x86-32 because of a gcc bug
> >   where the stack gets aligned before the mcount call.  This issue
> >   should be mostly obsolete as most modern compilers now have -mfentry.
> >   We could make it dependent on CC_USING_FENTRY.
> 
> Yeah. At some point we might even upgrade the compiler requirements to
> no longer accept the mcount model.

The plot slightly thickens...

So I was mistaken about this problem not existing with newer versions of
gcc, because the x86-32 ftrace code doesn't use -mfentry.  It still
relies on mcount.  So CONFIG_FUNCTION_GRAPH_TRACER will still need
-maccumulate-outgoing-args for *all* versions of gcc on x86-32.

(Of course, that situation would improve if ftrace on x86-32 were ported
to use -mfentry.)

Also, since -Os tells gcc to ignore -maccumulate-outgoing-args, this
means that CONFIG_FUNCTION_GRAPH_TRACER with mcount needs a dependency
on CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE.

I suspect these issues also affect x86-64 with gcc 4.4.x and 4.5.x,
which corresponds to the window after the funky DRAP prologue was
introduced but before -mfentry was introduced.

In summary, here are the changes I'm looking at:

- set -maccumulate-outgoing-args if CONFIG_FUNCTION_GRAPH_TRACER &&
  !CC_USING_ENTRY
  (for both 32- and 64-bit)

- somehow make CONFIG_FUNCTION_GRAPH_TRACER depend on either
  CC_USING_FENTRY or CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE
  (for both 32- and 64-bit)

  (not sure how to do that -- maybe just fail the build in the
  graph tracer + mcount + '-Os' case)

- set -maccumulate-outgoing-args if CONFIG_JUMP_LABEL && gcc < 4.5.2
  (for both 32-bit and 64-bit)

-- 
Josh

[PATCH v3 02/09] iommu/ipmmu-vmsa: Add optional root device feature

[Magnus Damm]

From: Magnus Damm 

Add root device handling to the IPMMU driver by allowing certain
DT compat strings to enable has_cache_leaf_nodes that in turn will
support both root devices with interrupts and leaf devices that
face the actual IPMMU consumer devices.

Signed-off-by: Magnus Damm 
---

 Changes since V2:
 - Fixed a bug in ipmmu_find_root() when only leaf devices are present
 - Broke out __ipmmu_find_root() to allow ->xlate() check for root devices

 Changes since V1:
 - Moved patch to earlier in the series
 - Updated code to work with recent changes in:
   [PATCH v3 00/06] iommu/ipmmu-vmsa: IPMMU multi-arch update V3

 drivers/iommu/ipmmu-vmsa.c |   95 
 1 file changed, 78 insertions(+), 17 deletions(-)

--- 0011/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2017-03-08 17:56:51.770607110 +0900
@@ -34,6 +34,7 @@
 
 struct ipmmu_features {
bool use_ns_alias_offset;
+   bool has_cache_leaf_nodes;
 };
 
 struct ipmmu_vmsa_device {
@@ -41,6 +42,7 @@ struct ipmmu_vmsa_device {
void __iomem *base;
struct list_head list;
const struct ipmmu_features *features;
+   bool is_leaf;
unsigned int num_utlbs;
spinlock_t lock;/* Protects ctx and domains[] */
DECLARE_BITMAP(ctx, IPMMU_CTX_MAX);
@@ -51,6 +53,7 @@ struct ipmmu_vmsa_device {
 
 struct ipmmu_vmsa_domain {
struct ipmmu_vmsa_device *mmu;
+   struct ipmmu_vmsa_device *root;
struct iommu_domain io_domain;
 
struct io_pgtable_cfg cfg;
@@ -216,6 +219,44 @@ static void set_archdata(struct device *
 #define IMUASID_ASID0_SHIFT0
 
 /* 
-
+ * Root device handling
+ */
+
+static bool ipmmu_is_root(struct ipmmu_vmsa_device *mmu)
+{
+   if (mmu->features->has_cache_leaf_nodes)
+   return mmu->is_leaf ? false : true;
+   else
+   return true; /* older IPMMU hardware treated as single root */
+}
+
+static struct ipmmu_vmsa_device *__ipmmu_find_root(void)
+{
+   struct ipmmu_vmsa_device *mmu;
+   bool found = false;
+
+   spin_lock(_devices_lock);
+
+   list_for_each_entry(mmu, _devices, list) {
+   if (ipmmu_is_root(mmu)) {
+   found = true;
+   break;
+   }
+   }
+
+   spin_unlock(_devices_lock);
+   return found ? mmu : NULL;
+}
+
+static struct ipmmu_vmsa_device *ipmmu_find_root(struct ipmmu_vmsa_device 
*leaf)
+{
+   if (ipmmu_is_root(leaf))
+   return leaf;
+   else
+   return __ipmmu_find_root();
+}
+
+/* 
-
  * Read/Write Access
  */
 
@@ -232,13 +273,13 @@ static void ipmmu_write(struct ipmmu_vms
 
 static u32 ipmmu_ctx_read(struct ipmmu_vmsa_domain *domain, unsigned int reg)
 {
-   return ipmmu_read(domain->mmu, domain->context_id * IM_CTX_SIZE + reg);
+   return ipmmu_read(domain->root, domain->context_id * IM_CTX_SIZE + reg);
 }
 
 static void ipmmu_ctx_write(struct ipmmu_vmsa_domain *domain, unsigned int reg,
u32 data)
 {
-   ipmmu_write(domain->mmu, domain->context_id * IM_CTX_SIZE + reg, data);
+   ipmmu_write(domain->root, domain->context_id * IM_CTX_SIZE + reg, data);
 }
 
 /* 
-
@@ -373,7 +414,7 @@ static int ipmmu_domain_init_context(str
 * TODO: Add support for coherent walk through CCI with DVM and remove
 * cache handling. For now, delegate it to the io-pgtable code.
 */
-   domain->cfg.iommu_dev = domain->mmu->dev;
+   domain->cfg.iommu_dev = domain->root->dev;
 
domain->iop = alloc_io_pgtable_ops(ARM_32_LPAE_S1, >cfg,
   domain);
@@ -383,7 +424,7 @@ static int ipmmu_domain_init_context(str
/*
 * Find an unused context.
 */
-   ret = ipmmu_domain_allocate_context(domain->mmu, domain);
+   ret = ipmmu_domain_allocate_context(domain->root, domain);
if (ret == IPMMU_CTX_MAX) {
free_io_pgtable_ops(domain->iop);
return -EBUSY;
@@ -454,7 +495,7 @@ static void ipmmu_domain_destroy_context
 */
ipmmu_ctx_write(domain, IMCTR, IMCTR_FLUSH);
ipmmu_tlb_sync(domain);
-   ipmmu_domain_free_context(domain->mmu, domain->context_id);
+   ipmmu_domain_free_context(domain->root, domain->context_id);
 }
 
 /* 
-
@@ -567,7 +608,7 @@ static int ipmmu_attach_device(struct io
   struct device *dev)
 {
struct ipmmu_vmsa_archdata *archdata = to_archdata(dev);
-   struct ipmmu_vmsa_device *mmu = archdata->mmu;
+   

[Question] devm_kmalloc() for DMA ?

[Masahiro Yamada]

Hi experts,

I have a question about
how to allocate DMA-safe buffer.


In my understanding, kmalloc() returns
memory with DMA safe alignment
in order to avoid cache-sharing problem when used for DMA.

The alignment is decided by ARCH_DMA_MINALIGN.
For example, on modern ARM 32bit boards, this value is typically 64.
So, memory returned by kmalloc() has
at least 64 byte alignment.


On the other hand, devm_kmalloc() does not return
enough-aligned memory.


On my board (ARM 32bit), devm_kmalloc() returns
(ARCH_DMA_MINALIGN aligned address) + 0x10.



The reason of the offset 0x10 is obvious.

struct devres {
struct devres_node node;
/* -- 3 pointers */
unsigned long long data[]; /* guarantee ull alignment */
};


Management data is located at the top of struct devres.
Then, devm_kmalloc() returns dr->data.

The "unsigned long long" guarantees
the returned memory has 0x10 alignment,
but I think this may not be enough for DMA.

I noticed this when I was seeing drivers/mtd/nand/denali.c

The code looks as follows:


denali->buf.buf = devm_kzalloc(denali->dev,
 mtd->writesize + mtd->oobsize,
 GFP_KERNEL);
if (!denali->buf.buf) {
ret = -ENOMEM;
goto failed_req_irq;
}

/* Is 32-bit DMA supported? */
ret = dma_set_mask(denali->dev, DMA_BIT_MASK(32));
if (ret) {
dev_err(denali->dev, "No usable DMA configuration\n");
goto failed_req_irq;
}

denali->buf.dma_buf = dma_map_single(denali->dev, denali->buf.buf,
 mtd->writesize + mtd->oobsize,
 DMA_BIDIRECTIONAL);




Memory buffer is allocated by devm_kzalloc(), then
passed to dma_map_single().



Could this be a potential problem in general?

Is devm_kmalloc() not recommended
for buffer that can be DMA-mapped?


Any advice is appreciated.


-- 
Best Regards
Masahiro Yamada

Re: About boot time Tux logo with -EPROBE_DEFER

[Kuninori Morimoto]

Hi Geert

Thanks.
I asked this because some maintainer doesn't accept the patch which
exchanges xxx_initcall.
But, I will try it with your Reviewed-by.

> > I want to ask you about boot time Tux logo.
> >
> > For some reasons, current our video driver returns -EPROBE_DEFER when
> > probe timing, but logo init function doesn't care it.
> > Thus, our kernel can't have logo when boot time.
> >
> > I think this is not only our issue, but general issue ?
> >
> > Thus, I think logo init function should care about -EPROBE_DEFER
> > or something. In our quick hack, this issue was solved by below patch,
> > but I don't know this is OK.
> 
> The important part is that fb_logo_late_init() is called
>   - as late as possible, to allow to draw the logo as late as possible,
>   - but before free_initmem(), to avoid using freed memory.
> 
> kernel_init()
> {
> kernel_init_freeable()
> {
> ...
> do_basic_setup()
> {
> ...
> do_initcalls();
> ...
> }
> ...
> }
> /* need to finish all async __init code before freeing the memory */
> async_synchronize_full();
> free_initmem();
> ...
> }
> 
> According to the call graph above, the latest initcall() should be OK.
> 
> > So, how to solve this issue ? do you have nice idea ?
> > or can maintainer accept below patch ?
> >
> > ---
> > diff --git a/drivers/video/logo/logo.c b/drivers/video/logo/logo.c
> > index b6bc4a0bda2a..4d50bfd13e7c 100644
> > --- a/drivers/video/logo/logo.c
> > +++ b/drivers/video/logo/logo.c
> > @@ -34,7 +34,7 @@ static int __init fb_logo_late_init(void)
> >  return 0;
> >  }
> >
> > -late_initcall(fb_logo_late_init);
> > +late_initcall_sync(fb_logo_late_init);
> >
> >  /* logo's are marked __initdata. Use __ref to tell
> >   * modpost that it is intended that this function uses data
> 
> Reviewed-by: Geert Uytterhoeven 
> 
> Gr{oetje,eeting}s,
> 
> Geert
> 
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- 
> ge...@linux-m68k.org
> 
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like 
> that.
> -- Linus Torvalds

[PATCH -mm -v6 1/9] mm, swap: Make swap cluster size same of THP size on x86_64

[Huang, Ying]

From: Huang Ying 

In this patch, the size of the swap cluster is changed to that of the
THP (Transparent Huge Page) on x86_64 architecture (512).  This is for
the THP swap support on x86_64.  Where one swap cluster will be used to
hold the contents of each THP swapped out.  And some information of the
swapped out THP (such as compound map count) will be recorded in the
swap_cluster_info data structure.

For other architectures which want THP swap support,
ARCH_USES_THP_SWAP_CLUSTER need to be selected in the Kconfig file for
the architecture.

In effect, this will enlarge swap cluster size by 2 times on x86_64.
Which may make it harder to find a free cluster when the swap space
becomes fragmented.  So that, this may reduce the continuous swap space
allocation and sequential write in theory.  The performance test in 0day
shows no regressions caused by this.

Cc: Hugh Dickins 
Cc: Shaohua Li 
Cc: Minchan Kim 
Cc: Rik van Riel 
Suggested-by: Andrew Morton 
Signed-off-by: "Huang, Ying" 
---
 arch/x86/Kconfig |  1 +
 mm/Kconfig   | 13 +
 mm/swapfile.c|  4 
 3 files changed, 18 insertions(+)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 005df7c825f5..94908127c83e 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -176,6 +176,7 @@ config X86
select USER_STACKTRACE_SUPPORT
select VIRT_TO_BUS
select X86_FEATURE_NAMESif PROC_FS
+   select ARCH_USES_THP_SWAP_CLUSTER   if X86_64
 
 config INSTRUCTION_DECODER
def_bool y
diff --git a/mm/Kconfig b/mm/Kconfig
index 9b8fccb969dc..7b708e200c29 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -499,6 +499,19 @@ config FRONTSWAP
 
  If unsure, say Y to enable frontswap.
 
+config ARCH_USES_THP_SWAP_CLUSTER
+   bool
+   default n
+
+config THP_SWAP_CLUSTER
+   bool
+   depends on SWAP && TRANSPARENT_HUGEPAGE && ARCH_USES_THP_SWAP_CLUSTER
+   default y
+   help
+ Use one swap cluster to hold the contents of the THP
+ (Transparent Huge Page) swapped out.  The size of the swap
+ cluster will be same as that of THP.
+
 config CMA
bool "Contiguous Memory Allocator"
depends on HAVE_MEMBLOCK && MMU
diff --git a/mm/swapfile.c b/mm/swapfile.c
index 5e1e9bffa3e2..2396e1a350c8 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -199,7 +199,11 @@ static void discard_swap_cluster(struct swap_info_struct 
*si,
}
 }
 
+#ifdef CONFIG_THP_SWAP_CLUSTER
+#define SWAPFILE_CLUSTER   HPAGE_PMD_NR
+#else
 #define SWAPFILE_CLUSTER   256
+#endif
 #define LATENCY_LIMIT  256
 
 static inline void cluster_set_flag(struct swap_cluster_info *info,
-- 
2.11.0

Re: [PATCH v5 5/5] perf: powerpc: choose local entry point with kretprobes

[Naveen N. Rao]

On 2017/03/08 11:31AM, Masami Hiramatsu wrote:
> On Wed,  8 Mar 2017 13:56:10 +0530
> "Naveen N. Rao"  wrote:
> 
> > perf now uses an offset from _text/_stext for kretprobes if the kernel
> > supports it, rather than the actual function name. As such, let's choose
> > the LEP for powerpc ABIv2 so as to ensure the probe gets hit. Do it only
> > if the kernel supports specifying offsets with kretprobes.
> 
> Acked-by: Masami Hiramatsu 
> 
> This patch is OK. And I found that most of functions in sym-handling.c
> are used only when libelf is supported. (e.g. probe-event.c itself
> is not built when we have no libelf)
> So, for the next cleanup, this file should not be compiled without
> libelf.

There are still a few functions there which work without libelf. But, I 
agree that the file has far too many #ifdefs between ABIv2 and libelf. I 
will see if I can simplify this file.

Thanks,
Naveen

[PATCH] driver core: add devices to deferred probe list when unbinding consumers

[Lucas Stach]

When a device is unbound due to the provider of one of the resources going
away, add it to the deferred probe list. This way the consumer device
driver gets a chance to rebind itself if the provider is rebound later on.

Signed-off-by: Lucas Stach 
---
 drivers/base/base.h | 1 +
 drivers/base/core.c | 2 ++
 drivers/base/dd.c   | 2 +-
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/base/base.h b/drivers/base/base.h
index e19b1008e5fb..c37d42450886 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -113,6 +113,7 @@ extern void device_release_driver_internal(struct device 
*dev,
 
 extern void driver_detach(struct device_driver *drv);
 extern int driver_probe_device(struct device_driver *drv, struct device *dev);
+extern void driver_deferred_probe_add(struct device *dev);
 extern void driver_deferred_probe_del(struct device *dev);
 static inline int driver_match_device(struct device_driver *drv,
  struct device *dev)
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 8c25e68e67d7..860e1cf195b9 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -572,6 +572,8 @@ void device_links_unbind_consumers(struct device *dev)
 
device_release_driver_internal(consumer, NULL,
   consumer->parent);
+   driver_deferred_probe_add(consumer);
+
put_device(consumer);
goto start;
}
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index a1fbf55c4d3a..a0217d76a0f2 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -115,7 +115,7 @@ static void deferred_probe_work_func(struct work_struct 
*work)
 }
 static DECLARE_WORK(deferred_probe_work, deferred_probe_work_func);
 
-static void driver_deferred_probe_add(struct device *dev)
+void driver_deferred_probe_add(struct device *dev)
 {
mutex_lock(_probe_mutex);
if (list_empty(>p->deferred_probe)) {
-- 
2.11.0

Re: [PATCH] clk: tegra: mark TEGRA210_CLK_DBGAPB as always on

[Jon Hunter]

On 08/03/17 11:38, Geert Uytterhoeven wrote:
> Hi Jon,
> 
> On Wed, Mar 8, 2017 at 11:13 AM, Jon Hunter  wrote:
>>> I had a similar issue with SH-Mobile AG5, where the power domain containing
>>> the JTAG interface is powered down.
>>
>> This reminds me, does your patch assume that the DFD power domain is
>> enabled? I am guessing that it needs to be for JTAG to work.
> 
> Yes. The pm-rmobile driver looks for "arm,coresight-etm3x" devices, and
> marks the corresponding PM Domain as always-on, as long as the
> Coresight code doesn't handle runtime PM.

Sorry Geert, but I was asking Peter specifically about the power-domain
on Tegra as I have a feeling we may have the same scenario ;-)

Jon

-- 
nvpublic

[PATCH v3 05/09] iommu/ipmmu-vmsa: IPMMU device is 40-bit bus master

[Magnus Damm]

From: Magnus Damm 

The r8a7795 IPMMU supports 40-bit bus mastering. Both
the coherent DMA mask and the streaming DMA mask are
set to unlock the 40-bit address space for coherent
allocations and streaming operations.

Signed-off-by: Magnus Damm 
---

 Changes since V2:
 - Updated the code and commit message to use 40 bits instead of 64 bits

 Changes since V1:
 - Updated the commit message

 drivers/iommu/ipmmu-vmsa.c |1 +
 1 file changed, 1 insertion(+)

--- 0016/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2017-03-08 18:29:56.390607110 +0900
@@ -1103,6 +1103,7 @@ static int ipmmu_probe(struct platform_d
spin_lock_init(>lock);
bitmap_zero(mmu->ctx, IPMMU_CTX_MAX);
mmu->features = match->data;
+   dma_set_mask_and_coherent(>dev, DMA_BIT_MASK(40));
 
/* Map I/O memory and request IRQ. */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);

Re: [f2fs-dev] [PATCH 1/2] f2fs: don't need to invalidate wrong node page

[Chao Yu]

On 2017/3/7 5:51, Jaegeuk Kim wrote:
> If f2fs_new_inode() is failed, the bad inode will invalidate 0'th node page
> during f2fs_evict_inode(), which doesn't need to do.

Hmm...should not allow other using of inode->i_ino in following codes of
f2fs_evict_inode, right?

Thanks,

> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/inode.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/fs/f2fs/inode.c b/fs/f2fs/inode.c
> index 24bb8213d974..ef8610bf950f 100644
> --- a/fs/f2fs/inode.c
> +++ b/fs/f2fs/inode.c
> @@ -411,7 +411,10 @@ void f2fs_evict_inode(struct inode *inode)
>   stat_dec_inline_dir(inode);
>   stat_dec_inline_inode(inode);
>  
> - invalidate_mapping_pages(NODE_MAPPING(sbi), inode->i_ino, inode->i_ino);
> + /* ino == 0, if f2fs_new_inode() was failed t*/
> + if (inode->i_ino)
> + invalidate_mapping_pages(NODE_MAPPING(sbi), inode->i_ino,
> + inode->i_ino);
>   if (xnid)
>   invalidate_mapping_pages(NODE_MAPPING(sbi), xnid, xnid);
>   if (inode->i_nlink) {
> 

[PATCH] zswap: Zero-filled pages handling

[Srividya Desireddy]

On Sat, Mar 4, 2017 at 02:55 AM, Dan Streetman  wrote:
> On Sat, Feb 25, 2017 at 12:18 PM, Sarbojit Ganguly
>  wrote:
>> On 25 February 2017 at 20:12, Srividya Desireddy
>>  wrote:
>>> From: Srividya Desireddy 
>>> Date: Thu, 23 Feb 2017 15:04:06 +0530
>>> Subject: [PATCH] zswap: Zero-filled pages handling
>
> your email is base64-encoded; please send plain text emails.
>
>>>
>>> Zswap is a cache which compresses the pages that are being swapped out
>>> and stores them into a dynamically allocated RAM-based memory pool.
>>> Experiments have shown that around 10-20% of pages stored in zswap
>>> are zero-filled pages (i.e. contents of the page are all zeros), but
>
> 20%?  that's a LOT of zero pages...which seems like applications are
> wasting a lot of memory.  what kind of workload are you testing with?
>

I have tested this patch with different workloaded on different devices.
On Ubuntu PC with 2GB RAM, while executing kernel build and other test 
scripts ~15% of pages in zswap were zero pages. With multimedia workload
more than 20% of zswap pages were found to be zero pages.
On a ARM Quad Core 32-bit device with 1.5GB RAM an average 10% of zero
pages were found on launching and relaunching 15 applications.

>>> these pages are handled as normal pages by compressing and allocating
>>> memory in the pool.
>>>
>>> This patch adds a check in zswap_frontswap_store() to identify zero-filled
>>> page before compression of the page. If the page is a zero-filled page, set
>>> zswap_entry.zeroflag and skip the compression of the page and alloction
>>> of memory in zpool. In zswap_frontswap_load(), check if the zeroflag is
>>> set for the page in zswap_entry. If the flag is set, memset the page with
>>> zero. This saves the decompression time during load.
>>>
>>> The overall overhead caused to check for a zero-filled page is very minimal
>>> when compared to the time saved by avoiding compression and allocation in
>>> case of zero-filled pages. Although, compressed size of a zero-filled page
>>> is very less, with this patch load time of a zero-filled page is reduced by
>>> 80% when compared to baseline.
>>
>> Is it possible to share the benchmark details?
>
> Was there an answer to this?
>

This patch is tested on a ARM Quad Core 32-bit device with 1.5GB RAM by
launching and relaunching different applications. With the patch, an
average of 5000 pages zero pages found in zswap out of the ~5 pages
stored in zswap and application launch time improved by ~3%.

Test Parameters BaselineWith patch  Improvement
---
Total RAM   1343MB  1343MB 
Available RAM   451MB   445MB -6MB
Avg. Memfree69MB70MB  1MB
Avg. Swap Used  226MB   215MB -11MB
Avg. App entry time 644msec 623msec   3%

With patch, every page swapped to zswap is checked if it is a zero
page or not and for all the zero pages compression and memory allocation
operations are skipped. Overall there is an improvement of 30% in zswap
store time.
In case of non-zero pages there is no overhead during zswap page load. For 
zero pages there is a improvement of more than 60% in the zswap load time 
as the zero page decompression is avoided.

The below table shows the execution time profiling of the patch.

Zswap Store Operation BaselineWith patch  % Improvement
--
* Zero page check-- 22.5ms
 (for non-zero pages)
* Zero page check-- 24ms
 (for zero pages)
* Compression time  55ms --
 (of zero pages)
* Allocation time   14ms --
 (to store compressed 
  zero pages)
-   
Total   69ms46.5ms 32%

Zswap Load Operation BaselineWith patch  % Improvement
-
* Decompression time  30.4ms--
 (of zero pages)
* Zero page check +-- 10.04ms
 memset operation
 (of zero pages)
-   
Total 30.4ms  10.04ms   66%

*The execution times may vary with test device used.

>>
>>
>>>
>>> Signed-off-by: Srividya Desireddy 
>>> ---
>>>  mm/zswap.c |   48 +---
>>>  1 file changed, 45 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/mm/zswap.c b/mm/zswap.c
>>> index 067a0d6..a574008 100644
>>> --- a/mm/zswap.c
>>> +++ b/mm/zswap.c
>>> @@ -49,6 +49,8 @@
>>>  static u64 zswap_pool_total_size;
>>>  /* The number of compressed pages currently stored in zswap */
>>>  static atomic_t zswap_stored_pages = ATOMIC_INIT(0);
>>> +/* The number of zero filled pages 

Re: net: heap out-of-bounds in fib6_clean_node/rt6_fill_node/fib6_age/fib6_prune_clone

[Dmitry Vyukov]

On Tue, Mar 7, 2017 at 9:00 PM, Dmitry Vyukov  wrote:
> On Tue, Mar 7, 2017 at 8:30 PM, Dmitry Vyukov  wrote:
 On 3/7/17 11:13 AM, Dmitry Vyukov wrote:
>> on this warning:
>>
>> /* dst.next really should not be set at this point */
>> if (rt->dst.next && rt->dst.next->ops->family != AF_INET6) {
>> pr_warn("fib6_add: adding rt with bad next -- family %d dst
>> flags %x\n",
>> rt->dst.next->ops->family, rt->dst.next->flags);
>>
>> WARN_ON(1);
>> }
>>
>> You should have seen the pr_warn in the log preceding the WARN_ON dump.
>
> Right. They all have the same "IPv6: fib6_add: adding rt with bad next
> -- family 2 dst flags 6"

 remove the previous changes and try the attached.
>>>
>>>
>>> Doing this now.
>>> FWIW I've also applied your last patch with missing "iter->dst.flags
>>> &= ~DST_IN_FIB;" and restored the warning in rt6_rcu_free and it did
>>> not fire (in a limited run). I only saw the "WARNING in fib6_add" that
>>> I already reported.
>>
>>
>> So far I've hit only:
>> [ 1103.840031] BUG: KASAN: slab-out-of-bounds in fib6_age+0x3fd/0x480
>> at addr 8800799d2254
>> without any preceeding warnings.
>> But note that since the kernel is heavily stressed I can reliably get
>> any pr_err output if it happens right before BUG/WARNING. Anything
>> that happens minutes before will be lots because there are tons of
>> output.
>
>
>
> So far 6 "KASAN: slab-out-of-bounds Read in fib6_age" but no other warnings.


I've got a bunch of the crashes that I was getting previously, but no
new warnings.

Re: [PATCH] pciehp: Fix race condition handling surprise link-down

[Raj, Ashok]

On Mon, Mar 06, 2017 at 06:24:17PM -0600, Bjorn Helgaas wrote:
> On Fri, Feb 03, 2017 at 10:51:04AM -0600, Bjorn Helgaas wrote:
> 
> Hi Ashok,
> 
> Just a ping to make sure we're not deadlocked.  I'm waiting for you,
> so I hope you're not also waiting for me :)  I'm not trying to rush you;
> I just don't want to drop this by mistake.
> 
Hi Bjorn

no we aren't deadlocked :-). I didn't get around changing it to ordered
queue yet, mostly worried about having to retest all the different 
combinations with ATTN, POWER_CTL, SLD.

I'm depending on other folks to test SLD. They are tied up with other
issues ATM.

I have had another OEM test with several disks and multiple ATTN's 
pressed/cancel and current code seems to be working well so far, except the 
SLD case.

The change in the patch was only ensuring that we don't start another 
POWER_ON or POWER_OFF before the earlier operation was complete.

Would it be alright to fix SLD with this version while we can probe a clean
approach that can give us sufficient time to test a clean approach that works
with all the different combinations and OEM systems?

Cheers
Ashok

Re: [PATCH v3 4/6] drm: bridge: dw-hdmi: Switch to V4L bus format and encodings

[Neil Armstrong]

On 03/07/2017 06:35 PM, Jose Abreu wrote:
> Hi Neil,
> 
> 
> On 07-03-2017 16:42, Neil Armstrong wrote:
>> Some display pipelines can only provide non-RBG input pixels to the HDMI TX
>> Controller, this patch takes the pixel format from the plat_data if provided.
>>
>> Signed-off-by: Neil Armstrong 
>> ---
>>  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 322 
>> +-
>>  include/drm/bridge/dw_hdmi.h  |  63 ++
>>  2 files changed, 290 insertions(+), 95 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
>> b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> index 1ed8bc1..348311c 100644
>> --- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> +++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
>> @@ -30,17 +30,14 @@
>>  #include 
>>  #include 
>>  
>> +#include 
>> +#include 
>> +
>>  #include "dw-hdmi.h"
>>  #include "dw-hdmi-audio.h"
>>  
>>  #define HDMI_EDID_LEN   512
>>  
>> -#define RGB 0
>> -#define YCBCR4441
>> -#define YCBCR422_16BITS 2
>> -#define YCBCR422_8BITS  3
>> -#define XVYCC4444
>> -
>>  enum hdmi_datamap {
>>  RGB444_8B = 0x01,
>>  RGB444_10B = 0x03,
>> @@ -94,10 +91,10 @@ struct hdmi_vmode {
>>  };
>>  
>>  struct hdmi_data_info {
>> -unsigned int enc_in_format;
>> -unsigned int enc_out_format;
>> -unsigned int enc_color_depth;
>> -unsigned int colorimetry;
>> +unsigned int enc_in_bus_format;
>> +unsigned int enc_out_bus_format;
>> +unsigned int enc_in_encoding;
>> +unsigned int enc_out_encoding;
>>  unsigned int pix_repet_factor;
>>  unsigned int hdcp_enable;
>>  struct hdmi_vmode video_mode;
>> @@ -557,6 +554,92 @@ void dw_hdmi_audio_disable(struct dw_hdmi *hdmi)
>>  }
>>  EXPORT_SYMBOL_GPL(dw_hdmi_audio_disable);
>>  
>> +static bool hdmi_bus_fmt_is_rgb(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_RGB888_1X24:
>> +case MEDIA_BUS_FMT_RGB101010_1X30:
>> +case MEDIA_BUS_FMT_RGB121212_1X36:
>> +case MEDIA_BUS_FMT_RGB161616_1X48:
>> +return true;
>> +
>> +default:
>> +return false;
>> +}
>> +}
>> +
>> +static bool hdmi_bus_fmt_is_yuv444(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_YUV8_1X24:
>> +case MEDIA_BUS_FMT_YUV10_1X30:
>> +case MEDIA_BUS_FMT_YUV12_1X36:
>> +case MEDIA_BUS_FMT_YUV16_1X48:
>> +return true;
>> +
>> +default:
>> +return false;
>> +}
>> +}
>> +
>> +static bool hdmi_bus_fmt_is_yuv422(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_UYVY8_1X16:
>> +case MEDIA_BUS_FMT_UYVY10_1X20:
>> +case MEDIA_BUS_FMT_UYVY12_1X24:
>> +return true;
>> +
>> +default:
>> +return false;
>> +}
>> +}
>> +
>> +static bool hdmi_bus_fmt_is_yuv420(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_UYVY8_1_1X24:
>> +case MEDIA_BUS_FMT_UYVY10_1_1X30:
>> +case MEDIA_BUS_FMT_UYVY12_1_1X36:
>> +case MEDIA_BUS_FMT_UYVY16_1_1X48:
>> +return true;
>> +
>> +default:
>> +return false;
>> +}
>> +}
>> +
>> +static int hdmi_bus_fmt_color_depth(unsigned int bus_format)
>> +{
>> +switch (bus_format) {
>> +case MEDIA_BUS_FMT_RGB888_1X24:
>> +case MEDIA_BUS_FMT_YUV8_1X24:
>> +case MEDIA_BUS_FMT_UYVY8_1X16:
>> +case MEDIA_BUS_FMT_UYVY8_1_1X24:
>> +return 8;
>> +
>> +case MEDIA_BUS_FMT_RGB101010_1X30:
>> +case MEDIA_BUS_FMT_YUV10_1X30:
>> +case MEDIA_BUS_FMT_UYVY10_1X20:
>> +case MEDIA_BUS_FMT_UYVY10_1_1X30:
>> +return 10;
>> +
>> +case MEDIA_BUS_FMT_RGB121212_1X36:
>> +case MEDIA_BUS_FMT_YUV12_1X36:
>> +case MEDIA_BUS_FMT_UYVY12_1X24:
>> +case MEDIA_BUS_FMT_UYVY12_1_1X36:
>> +return 12;
>> +
>> +case MEDIA_BUS_FMT_RGB161616_1X48:
>> +case MEDIA_BUS_FMT_YUV16_1X48:
>> +case MEDIA_BUS_FMT_UYVY16_1_1X48:
>> +return 16;
>> +
>> +default:
>> +return 0;
> 
> Maybe fallback to 8bpp in case of error as this is the most
> common supported.
> 
>> +}
>> +}
>> +
>>  /*
>>   * this submodule is responsible for the video data synchronization.
>>   * for example, for RGB 4:4:4 input, the data map is defined as
>> @@ -569,37 +652,45 @@ static void hdmi_video_sample(struct dw_hdmi *hdmi)
>>  int color_format = 0;
>>  u8 val;
>>  
>> -if (hdmi->hdmi_data.enc_in_format == RGB) {
>> -if (hdmi->hdmi_data.enc_color_depth == 8)
>> -color_format = 0x01;
>> -else if (hdmi->hdmi_data.enc_color_depth == 10)
>> -color_format = 0x03;
>> -else if (hdmi->hdmi_data.enc_color_depth == 12)
>> -color_format = 0x05;
>> -else if (hdmi->hdmi_data.enc_color_depth == 16)
>> -

Re: [PATCH -next] soc: zte: pm_domains: Remove redundant dev_err call in zx2967_pd_probe()

[Shawn Guo]

On Mon, Feb 06, 2017 at 04:23:02PM +, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> There is a error message within devm_ioremap_resource
> already, so remove the dev_err call to avoid redundant
> error message.
> 
> Signed-off-by: Wei Yongjun 

Applied, thanks.

Re: [PATCH v4 2/7] perf/sdt: Directly record SDT events with 'perf record'

[Masami Hiramatsu]

Hi Ravi,

On Mon,  6 Mar 2017 18:42:59 +0530
Ravi Bangoria  wrote:

> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index bc84a37..e87b19b 100644
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -39,6 +39,7 @@
>  #include "util/trigger.h"
>  #include "util/perf-hooks.h"
>  #include "asm/bug.h"
> +#include "util/probe-file.h"
>  
>  #include 
>  #include 
> @@ -73,6 +74,7 @@ struct record {
>   booltimestamp_filename;
>   struct switch_outputswitch_output;
>   unsigned long long  samples;
> + struct list_headsdt_event_list;
>  };
>  
>  static volatile int auxtrace_record__snapshot_started;
> @@ -1503,6 +1505,26 @@ static struct record record = {
>   },
>  };
>  
> +void sdt_event_list__add(struct list_head *sdt_event_list)
> +{
> + if (list_empty(sdt_event_list))
> + return;
> + list_splice(sdt_event_list, _event_list);
> +}
> +
> +bool is_cmd_record(void)
> +{
> + return (record.evlist != NULL);
> +}

Hmm, exporting this from builtin-record.c makes inverted reference from
builtin-record.o to libperf. I think it is not good way to do.

[...]
> diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
> index 54355d3..1fcc9d13 100644
> --- a/tools/perf/util/parse-events.c
> +++ b/tools/perf/util/parse-events.c
> @@ -1727,12 +1727,66 @@ static void parse_events_print_error(struct 
> parse_events_error *err,
>  
>  #undef MAX_WIDTH
>  
> +/* SDT event needs LIBELF support for creating a probe point */
> +#ifdef HAVE_LIBELF_SUPPORT
> +static int parse_sdt_event(struct perf_evlist *evlist, const char *str,
> +struct parse_events_error *err)
> +{
> + char *ptr = NULL;
> + int ret;
> + struct list_head *sdt_evlist;
> + struct sdt_event_list *sdt_event;
> +
> + if (str[0] == '%')
> + str++;
> +
> + ptr = strdup(str);
> + if (ptr == NULL)
> + return -ENOMEM;
> +
> + sdt_evlist = zalloc(sizeof(*sdt_evlist));
> + if (!sdt_evlist) {
> + free(ptr);
> + pr_debug("Error in sdt_evlist memory allocation\n");
> + return -ENOMEM;
> + }
> + INIT_LIST_HEAD(sdt_evlist);
> +
> + /*
> +  * If there is an error in this call, no need to free
> +  * up sdt_evlist, its already free'ed up in the previous
> +  * call. Free up 'ptr' though.
> +  */
> + ret = add_sdt_event(ptr, sdt_evlist);
> + if (!ret) {
> + list_for_each_entry(sdt_event, sdt_evlist, list) {
> + ret = parse_events(evlist, sdt_event->name, err);
> + if (ret < 0)
> + goto ret;
> + }
> + /* Add it to the record struct */
> + sdt_event_list__add(sdt_evlist);
> + }
> +
> +ret:
> + free(ptr);
> + return ret;
> +}
> +#endif /* HAVE_LIBELF_SUPPORT */
> +
>  int parse_events_option(const struct option *opt, const char *str,
>   int unset __maybe_unused)
>  {
>   struct perf_evlist *evlist = *(struct perf_evlist **)opt->value;
>   struct parse_events_error err = { .idx = 0, };
> - int ret = parse_events(evlist, str, );
> + int ret = 0;
> +
> +#ifdef HAVE_LIBELF_SUPPORT
> + if (is_sdt_event((char *)str) && is_cmd_record())
> + ret = parse_sdt_event(evlist, str, );
> + else
> +#endif

To avoid these ifdefs, could you add a dummy (error return) function
of add_sdt_event() for !HAVE_LIBELF_SUPPORT case in probe-event.h?



> + ret = parse_events(evlist, str, );
>  
>   if (ret)
>   parse_events_print_error(, str);
> diff --git a/tools/perf/util/parse-events.h b/tools/perf/util/parse-events.h
> index c6172cd..0887269 100644
> --- a/tools/perf/util/parse-events.h
> +++ b/tools/perf/util/parse-events.h
> @@ -208,4 +208,6 @@ static inline bool is_sdt_event(char *str)
>   (!strncmp(str, "sdt_", 4) &&
>!!strchr(str, ':') && !strchr(str, '=')));
>  }
> +
> +void sdt_event_list__add(struct list_head *sdt_event_list);
>  #endif /* __PERF_PARSE_EVENTS_H */
> diff --git a/tools/perf/util/probe-event.c b/tools/perf/util/probe-event.c
> index 2b1409f..b879076 100644
> --- a/tools/perf/util/probe-event.c
> +++ b/tools/perf/util/probe-event.c
> @@ -1293,7 +1293,7 @@ int parse_line_range_desc(const char *arg, struct 
> line_range *lr)
>   return err;
>  }
>  
> -static int parse_perf_probe_event_name(char **arg, struct perf_probe_event 
> *pev)
> +int parse_perf_probe_event_name(char **arg, struct perf_probe_event *pev)
>  {
>   char *ptr;
>  
> @@ -3125,8 +3125,8 @@ static int find_cached_events(struct perf_probe_event 
> *pev,
>  }
>  
>  /* Try to find probe_trace_event from all probe caches */
> -static int find_cached_events_all(struct perf_probe_event *pev,
> -struct 

Re: [PATCH 1/2] reset: add reset-simple to unify socfpga, stm32, and sunxi

[Philipp Zabel]

On Wed, 2017-03-08 at 12:05 +0100, Alexandre Torgue wrote:
> Hi Philipp,
> 
> On 03/08/2017 11:19 AM, Andre Przywara wrote:
> > Hi,
> >
> > On 08/03/17 09:54, Philipp Zabel wrote:
> >> Reset operations for simple reset controllers with reset lines that can
> >> be controlled by toggling bits in (mostly) contiguous register ranges
> >> using read-modify-write cycles under a spinlock. So far this covers the
> >> socfpga, stm32, and sunxi drivers.
> >
> > Wow, that looks nice, thanks for that.
> >
> > But can't we go one step further and unify those driver into one file then?
> > And either have different probe functions to cover the different DT
> > requirements or to just have one unified probe checking for the super
> > set of all properties?
> 
> I agree with Andre. It looks nice and it should be a good thing to have 
> a common probe inside reset-simple.c
> Maybe only "nresets" and "inverted"  DT properties are needed.

Adding DT properties is not an option, as the driver would have to work
with the existing bindings. We could merge them into one file, with a
single probe function that configures different parameters depending on
the of_device_id returned by of_match_device.

regards
Philipp

Re: [PATCH -next] soc: zte: pm_domains: Remove .owner field for driver

[Shawn Guo]

On Mon, Feb 06, 2017 at 04:23:18PM +, Wei Yongjun wrote:
> From: Wei Yongjun 
> 
> Remove .owner field if calls are used which set it automatically.
> 
> Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci
> 
> Signed-off-by: Wei Yongjun 

Applied, thanks.

Re: [PATCH v5 2/5] powerpc: kretprobes: override default function entry offset

[Michael Ellerman]

"Naveen N. Rao"  writes:

> With ABIv2, we offset 8 bytes into a function to get at the local entry
> point.
>
> Acked-by: Ananth N Mavinakayanahalli 
> Acked-by: Michael Ellerman 
> Signed-off-by: Naveen N. Rao 
> ---
>  arch/powerpc/kernel/kprobes.c | 9 +
>  1 file changed, 9 insertions(+)

I'm OK with this change, and I'm happy for it to go with the rest of the
series via acme's tree:

Acked-by: Michael Ellerman 


But, you've also sent a series to do KPROBES_ON_FTRACE, and that also
touches this function, see the 2nd to last hunk at:

  https://patchwork.ozlabs.org/patch/730675/


If this goes via acme's tree it will be awkward for me to merge the
series above via the powerpc tree.

So we could do topic branches and so on, or we could just drop this
patch from this series, and I'll merge it as part of the other series.
It won't do anything useful until it's merged with a tree that also has
the rest of this series. Or something else I haven't thought of.

cheers

> diff --git a/arch/powerpc/kernel/kprobes.c b/arch/powerpc/kernel/kprobes.c
> index fce05a38851c..331751701fed 100644
> --- a/arch/powerpc/kernel/kprobes.c
> +++ b/arch/powerpc/kernel/kprobes.c
> @@ -131,6 +131,15 @@ static void __kprobes set_current_kprobe(struct kprobe 
> *p, struct pt_regs *regs,
>   kcb->kprobe_saved_msr = regs->msr;
>  }
>  
> +bool arch_function_offset_within_entry(unsigned long offset)
> +{
> +#ifdef PPC64_ELF_ABI_v2
> + return offset <= 8;
> +#else
> + return !offset;
> +#endif
> +}
> +
>  void __kprobes arch_prepare_kretprobe(struct kretprobe_instance *ri,
> struct pt_regs *regs)
>  {
> -- 
> 2.11.1

[PATCH] x86/apic: Remove the SET_APIC_ID(x) macro

[Dou Liyang]

-remove the SET_APIC_ID(x) macro
 -simplify the call flow
 -add a comment

Signed-off-by: Dou Liyang 
---
 arch/x86/include/asm/apic.h | 7 +--
 arch/x86/kernel/apic/apic.c | 2 +-
 2 files changed, 2 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/apic.h b/arch/x86/include/asm/apic.h
index 730ef65..b0b4b43 100644
--- a/arch/x86/include/asm/apic.h
+++ b/arch/x86/include/asm/apic.h
@@ -252,12 +252,6 @@ static inline int x2apic_enabled(void) { return 0; }
 #definex2apic_supported()  (0)
 #endif /* !CONFIG_X86_X2APIC */
 
-#ifdef CONFIG_X86_64
-#defineSET_APIC_ID(x)  (apic->set_apic_id(x))
-#else
-
-#endif
-
 /*
  * Copyright 2004 James Cleverdon, IBM.
  * Subject to the GNU Public License, v.2
@@ -299,6 +293,7 @@ struct apic {
int (*phys_pkg_id)(int cpuid_apic, int index_msb);
 
unsigned int (*get_apic_id)(unsigned long x);
+   /* Cann't be NULL on 64-bit. */
unsigned long (*set_apic_id)(unsigned int id);
 
int (*cpu_mask_to_apicid_and)(const struct cpumask *cpumask,
diff --git a/arch/x86/kernel/apic/apic.c b/arch/x86/kernel/apic/apic.c
index aee7ded..f3034ba 100644
--- a/arch/x86/kernel/apic/apic.c
+++ b/arch/x86/kernel/apic/apic.c
@@ -2249,7 +2249,7 @@ void __init apic_set_eoi_write(void (*eoi_write)(u32 reg, 
u32 v))
 static void __init apic_bsp_up_setup(void)
 {
 #ifdef CONFIG_X86_64
-   apic_write(APIC_ID, SET_APIC_ID(boot_cpu_physical_apicid));
+   apic_write(APIC_ID, apic->set_apic_id(boot_cpu_physical_apicid));
 #else
/*
 * Hack: In case of kdump, after a crash, kernel might be booting
-- 
2.5.5

[PATCH v3 1/7] PCI: dwc: designware: Add new *ops* for cpu addr fixup

[Kishon Vijay Abraham I]

Some platforms (like dra7xx) require only the least 28 bits of the
corresponding 32 bit CPU address to be programmed in the address
translation unit. This modified address is stored in io_base/mem_base/
cfg0_base/cfg1_base in dra7xx_pcie_host_init. While this is okay for
host mode where the address range is fixed, device mode requires
different addresses to be programmed based on the host buffer address.
Add a new ops to get the least 28 bits of the corresponding 32 bit
CPU address and invoke it before programming the address translation
unit.

Signed-off-by: Kishon Vijay Abraham I 
---
 drivers/pci/dwc/pcie-designware.c |3 +++
 drivers/pci/dwc/pcie-designware.h |1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/pci/dwc/pcie-designware.c 
b/drivers/pci/dwc/pcie-designware.c
index 7e1fb7d..14ee7a3 100644
--- a/drivers/pci/dwc/pcie-designware.c
+++ b/drivers/pci/dwc/pcie-designware.c
@@ -97,6 +97,9 @@ void dw_pcie_prog_outbound_atu(struct dw_pcie *pci, int 
index, int type,
 {
u32 retries, val;
 
+   if (pp->ops->cpu_addr_fixup)
+   cpu_addr = pp->ops->cpu_addr_fixup(cpu_addr);
+
if (pci->iatu_unroll_enabled) {
dw_pcie_writel_unroll(pci, index, PCIE_ATU_UNR_LOWER_BASE,
  lower_32_bits(cpu_addr));
diff --git a/drivers/pci/dwc/pcie-designware.h 
b/drivers/pci/dwc/pcie-designware.h
index cd3b871..8f3dcb2 100644
--- a/drivers/pci/dwc/pcie-designware.h
+++ b/drivers/pci/dwc/pcie-designware.h
@@ -143,6 +143,7 @@ struct pcie_port {
 };
 
 struct dw_pcie_ops {
+   u64 (*cpu_addr_fixup)(u64 cpu_addr);
u32 (*readl_dbi)(struct dw_pcie *pcie, u32 reg);
void(*writel_dbi)(struct dw_pcie *pcie, u32 reg, u32 val);
int (*link_up)(struct dw_pcie *pcie);
-- 
1.7.9.5

Re: [PATCH 3/3] cpufreq: schedutil: remove redundant code from sugov_next_freq_shared()

[Viresh Kumar]

On 08-03-17, 11:50, Rafael J. Wysocki wrote:
> So overall, maybe you can move the flags check to
> sugov_update_shared(), so that you don't need to pass flags to
> sugov_next_freq_shared(), and then do what you did to util and max.

Just to confirm, below is what you are suggesting ?

-8<-
 
 1 file changed, 9 insertions(+), 16 deletions(-)

diff --git a/kernel/sched/cpufreq_schedutil.c b/kernel/sched/cpufreq_schedutil.c
index 78468aa051ab..f5ffe241812e 100644
--- a/kernel/sched/cpufreq_schedutil.c
+++ b/kernel/sched/cpufreq_schedutil.c
@@ -217,30 +217,19 @@ static void sugov_update_single(struct update_util_data 
*hook, u64 time,
sugov_update_commit(sg_policy, time, next_f);
 }
 
-static unsigned int sugov_next_freq_shared(struct sugov_cpu *sg_cpu,
-  unsigned long util, unsigned long 
max,
-  unsigned int flags)
+static unsigned int sugov_next_freq_shared(struct sugov_cpu *sg_cpu)
 {
struct sugov_policy *sg_policy = sg_cpu->sg_policy;
struct cpufreq_policy *policy = sg_policy->policy;
-   unsigned int max_f = policy->cpuinfo.max_freq;
u64 last_freq_update_time = sg_policy->last_freq_update_time;
+   unsigned long util = 0, max = 1;
unsigned int j;
 
-   if (flags & SCHED_CPUFREQ_RT_DL)
-   return max_f;
-
-   sugov_iowait_boost(sg_cpu, , );
-
for_each_cpu(j, policy->cpus) {
-   struct sugov_cpu *j_sg_cpu;
+   struct sugov_cpu *j_sg_cpu = _cpu(sugov_cpu, j);
unsigned long j_util, j_max;
s64 delta_ns;
 
-   if (j == smp_processor_id())
-   continue;
-
-   j_sg_cpu = _cpu(sugov_cpu, j);
/*
 * If the CPU utilization was last updated before the previous
 * frequency update and the time elapsed between the last update
@@ -254,7 +243,7 @@ static unsigned int sugov_next_freq_shared(struct sugov_cpu 
*sg_cpu,
continue;
}
if (j_sg_cpu->flags & SCHED_CPUFREQ_RT_DL)
-   return max_f;
+   return policy->cpuinfo.max_freq;
 
j_util = j_sg_cpu->util;
j_max = j_sg_cpu->max;
@@ -289,7 +278,11 @@ static void sugov_update_shared(struct update_util_data 
*hook, u64 time,
sg_cpu->last_update = time;
 
if (sugov_should_update_freq(sg_policy, time)) {
-   next_f = sugov_next_freq_shared(sg_cpu, util, max, flags);
+   if (flags & SCHED_CPUFREQ_RT_DL)
+   next_f = sg_policy->policy->cpuinfo.max_freq;
+   else
+   next_f = sugov_next_freq_shared(sg_cpu);
+
sugov_update_commit(sg_policy, time, next_f);
}
 
> But that would be a 4.12 change anyway.

Sure.

Re: [Question] devm_kmalloc() for DMA ?

[Robin Murphy]

On 08/03/17 10:59, Masahiro Yamada wrote:
> Hi experts,
> 
> I have a question about
> how to allocate DMA-safe buffer.
> 
> 
> In my understanding, kmalloc() returns
> memory with DMA safe alignment
> in order to avoid cache-sharing problem when used for DMA.
> 
> The alignment is decided by ARCH_DMA_MINALIGN.
> For example, on modern ARM 32bit boards, this value is typically 64.
> So, memory returned by kmalloc() has
> at least 64 byte alignment.
> 
> 
> On the other hand, devm_kmalloc() does not return
> enough-aligned memory.

How so? If anything returned by kmalloc() is guaranteed to occupy some
multiple of ARCH_DMA_MINALIGN bytes in order to avoid two allocations
falling into the same cache line, I don't see how stealing the first 16
bytes *of a single allocation* could make it start sharing cache lines
with another? :/

If a particular device has a problem with:

p = kmalloc(...);
d = dma_map_single(p + 0x10, ...);
do_something_with(d);

that's a separate issue altogether.

Robin.

> On my board (ARM 32bit), devm_kmalloc() returns
> (ARCH_DMA_MINALIGN aligned address) + 0x10.
> 
> 
> 
> The reason of the offset 0x10 is obvious.
> 
> struct devres {
> struct devres_node node;
> /* -- 3 pointers */
> unsigned long long data[]; /* guarantee ull alignment */
> };
> 
> 
> Management data is located at the top of struct devres.
> Then, devm_kmalloc() returns dr->data.
> 
> The "unsigned long long" guarantees
> the returned memory has 0x10 alignment,
> but I think this may not be enough for DMA.
> 
> I noticed this when I was seeing drivers/mtd/nand/denali.c
> 
> The code looks as follows:
> 
> 
> denali->buf.buf = devm_kzalloc(denali->dev,
>  mtd->writesize + mtd->oobsize,
>  GFP_KERNEL);
> if (!denali->buf.buf) {
> ret = -ENOMEM;
> goto failed_req_irq;
> }
> 
> /* Is 32-bit DMA supported? */
> ret = dma_set_mask(denali->dev, DMA_BIT_MASK(32));
> if (ret) {
> dev_err(denali->dev, "No usable DMA configuration\n");
> goto failed_req_irq;
> }
> 
> denali->buf.dma_buf = dma_map_single(denali->dev, denali->buf.buf,
>  mtd->writesize + mtd->oobsize,
>  DMA_BIDIRECTIONAL);
> 
> 
> 
> 
> Memory buffer is allocated by devm_kzalloc(), then
> passed to dma_map_single().
> 
> 
> 
> Could this be a potential problem in general?
> 
> Is devm_kmalloc() not recommended
> for buffer that can be DMA-mapped?
> 
> 
> Any advice is appreciated.
> 
> 

[PATCH v3 06/09] iommu/ipmmu-vmsa: Write IMCTR twice

[Magnus Damm]

From: Magnus Damm 

Write IMCTR both in the root device and the leaf node.

Signed-off-by: Magnus Damm 
---

 Changes since V2:
 - None

 Changes since V1:
 - None

 drivers/iommu/ipmmu-vmsa.c |   17 ++---
 1 file changed, 14 insertions(+), 3 deletions(-)

--- 0018/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2017-03-08 18:30:36.870607110 +0900
@@ -286,6 +286,16 @@ static void ipmmu_ctx_write(struct ipmmu
ipmmu_write(domain->root, domain->context_id * IM_CTX_SIZE + reg, data);
 }
 
+static void ipmmu_ctx_write2(struct ipmmu_vmsa_domain *domain, unsigned int 
reg,
+u32 data)
+{
+   if (domain->mmu != domain->root)
+   ipmmu_write(domain->mmu,
+   domain->context_id * IM_CTX_SIZE + reg, data);
+
+   ipmmu_write(domain->root, domain->context_id * IM_CTX_SIZE + reg, data);
+}
+
 /* 
-
  * TLB and microTLB Management
  */
@@ -312,7 +322,7 @@ static void ipmmu_tlb_invalidate(struct
 
reg = ipmmu_ctx_read(domain, IMCTR);
reg |= IMCTR_FLUSH;
-   ipmmu_ctx_write(domain, IMCTR, reg);
+   ipmmu_ctx_write2(domain, IMCTR, reg);
 
ipmmu_tlb_sync(domain);
 }
@@ -472,7 +482,8 @@ static int ipmmu_domain_init_context(str
 * software management as we have no use for it. Flush the TLB as
 * required when modifying the context registers.
 */
-   ipmmu_ctx_write(domain, IMCTR, IMCTR_INTEN | IMCTR_FLUSH | IMCTR_MMUEN);
+   ipmmu_ctx_write2(domain, IMCTR,
+IMCTR_INTEN | IMCTR_FLUSH | IMCTR_MMUEN);
 
return 0;
 }
@@ -498,7 +509,7 @@ static void ipmmu_domain_destroy_context
 *
 * TODO: Is TLB flush really needed ?
 */
-   ipmmu_ctx_write(domain, IMCTR, IMCTR_FLUSH);
+   ipmmu_ctx_write2(domain, IMCTR, IMCTR_FLUSH);
ipmmu_tlb_sync(domain);
ipmmu_domain_free_context(domain->root, domain->context_id);
 }

Re: [PATCH 2/2] Staging: comedi: comedi_fops: Fix "out of minor numbers for board device files"

[Ian Abbott]

On 08/03/17 10:08, Cheah Kok Cheong wrote:

Dear Dan,
  Thanks for reviewing this patch.

On Wed, Mar 08, 2017 at 08:54:47AM +0300, Dan Carpenter wrote:

On Sun, Mar 05, 2017 at 03:22:33AM +0800, Cheah Kok Cheong wrote:

If comedi module is loaded with the following max allowed parameter
[comedi_num_legacy_minors=48], subsequent loading of an auto-configured
device will fail.


Don't set comedi_num_legacy_minors=48, then?

This doesn't seem like the right fix at all.  Why only allow one auto
configured board?  Why not 5 or 10?



Let me explain, the original intended behaviour is to allow user to
reserve up to 48 minor numbers for legacy devices.

Therefore [sudo modprobe comedi comedi_num_legacy_minors=3]
will allocate minor number 0, 1, 2 for legacy devices.
Subsequent loading of an auto-configured device will use minor number 3.
And the next one number 4 so on and so forth.

Now for the corner case of [comedi_num_legacy_minors=48] which
is supposed to reserve minor number 0 till 47 for legacy devices,
and is supposed to allocate number 48 and so on for auto-configured
devices, does not allocate number 48 anymore after commit
38b9722a4414.


Both legacy and auto-configured devices will have minor numbers less 
than 48, which is the total number of devices currently supported by 
Comedi.  Minor numbers 48 and above have been reserved for dynamic 
allocation to those Comedi subdevices that support asynchronous commands.



This is due to the changes in comedi_alloc_board_minor().

As to why I chose to limit [comedi_num_legacy_minors=47], is given
in the commit log.

This will allow user to allocate 0 till 46 for legacy devices and
subsequent auto-configured devices will start from 47 and so forth.

I don't think anybody will miss one less number for legacy devices
otherwise there'll be complains earlier on.


As Dan implies above, if you want auto-configured devices to work, set 
comedi_num_legacy_minors to a value less than 48.  Further limiting 
comedi_num_legacy_minors to 47 seems a bit arbitrary.


The comedi_test module mentioned in your commit can still be used when 
comedi_num_legacy_minors=48 by configuring a "legacy" comedi_test 
device.  Most of the other Comedi drivers support "legacy" devices 
exclusive-or auto-configured devices.



Thanks.

Brgds,
CheahKC


regards,
dan carpenter




--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-

[PATCH v1 2/2] x86/platform/intel-mid: Add support power button for Merrifield

[Andy Shevchenko]

Intel Merrifield platform has Basin Cove PMIC to handle in particular
power button events. Add necessary bits here to enable it.

Signed-off-by: Andy Shevchenko 
---
- it would be nice to have it in v4.11-rc2, v4.11-rc1 has all preparatory work 
done
 arch/x86/platform/intel-mid/device_libs/Makefile   |  1 +
 .../device_libs/platform_mrfld_power_btn.c | 82 ++
 2 files changed, 83 insertions(+)
 create mode 100644 
arch/x86/platform/intel-mid/device_libs/platform_mrfld_power_btn.c

diff --git a/arch/x86/platform/intel-mid/device_libs/Makefile 
b/arch/x86/platform/intel-mid/device_libs/Makefile
index a7dbec4dce27..3dbde04febdc 100644
--- a/arch/x86/platform/intel-mid/device_libs/Makefile
+++ b/arch/x86/platform/intel-mid/device_libs/Makefile
@@ -26,5 +26,6 @@ obj-$(subst m,y,$(CONFIG_GPIO_PCA953X)) += 
platform_pcal9555a.o
 obj-$(subst m,y,$(CONFIG_GPIO_PCA953X)) += platform_tca6416.o
 # MISC Devices
 obj-$(subst m,y,$(CONFIG_KEYBOARD_GPIO)) += platform_gpio_keys.o
+obj-$(subst m,y,$(CONFIG_INTEL_MID_POWER_BUTTON)) += platform_mrfld_power_btn.o
 obj-$(subst m,y,$(CONFIG_RTC_DRV_CMOS)) += platform_mrfld_rtc.o
 obj-$(subst m,y,$(CONFIG_INTEL_MID_WATCHDOG)) += platform_mrfld_wdt.o
diff --git a/arch/x86/platform/intel-mid/device_libs/platform_mrfld_power_btn.c 
b/arch/x86/platform/intel-mid/device_libs/platform_mrfld_power_btn.c
new file mode 100644
index ..a6c3705a28ad
--- /dev/null
+++ b/arch/x86/platform/intel-mid/device_libs/platform_mrfld_power_btn.c
@@ -0,0 +1,82 @@
+/*
+ * Intel Merrifield power button support
+ *
+ * (C) Copyright 2017 Intel Corporation
+ *
+ * Author: Andy Shevchenko 
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; version 2
+ * of the License.
+ */
+
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static struct resource mrfld_power_btn_resources[] = {
+   {
+   .flags  = IORESOURCE_IRQ,
+   },
+};
+
+static struct platform_device mrfld_power_btn_dev = {
+   .name   = "msic_power_btn",
+   .id = PLATFORM_DEVID_NONE,
+   .num_resources  = ARRAY_SIZE(mrfld_power_btn_resources),
+   .resource   = mrfld_power_btn_resources,
+};
+
+static int mrfld_power_btn_scu_status_change(struct notifier_block *nb,
+unsigned long code, void *data)
+{
+   if (code == SCU_DOWN) {
+   platform_device_unregister(_power_btn_dev);
+   return 0;
+   }
+
+   return platform_device_register(_power_btn_dev);
+}
+
+static struct notifier_block mrfld_power_btn_scu_notifier = {
+   .notifier_call  = mrfld_power_btn_scu_status_change,
+};
+
+static int __init register_mrfld_power_btn(void)
+{
+   if (intel_mid_identify_cpu() != INTEL_MID_CPU_CHIP_TANGIER)
+   return -ENODEV;
+
+   /*
+* We need to be sure that the SCU IPC is ready before
+* PMIC power button device can be registered:
+*/
+   intel_scu_notifier_add(_power_btn_scu_notifier);
+
+   return 0;
+}
+arch_initcall(register_mrfld_power_btn);
+
+static void __init *mrfld_power_btn_platform_data(void *info)
+{
+   struct resource *res = mrfld_power_btn_resources;
+   struct sfi_device_table_entry *pentry = info;
+
+   res->start = res->end = pentry->irq;
+   return NULL;
+}
+
+static const struct devs_id mrfld_power_btn_dev_id __initconst = {
+   .name   = "bcove_power_btn",
+   .type   = SFI_DEV_TYPE_IPC,
+   .delay  = 1,
+   .msic   = 1,
+   .get_platform_data  = _power_btn_platform_data,
+};
+
+sfi_device(mrfld_power_btn_dev_id);
-- 
2.11.0

Re: [PATCH 1/2] mm: Change generic FALLBACK zonelist creation process

[John Hubbard]

On 03/08/2017 01:21 AM, Anshuman Khandual wrote:

Kernel allocation to CDM node has already been prevented by putting it's
entire memory in ZONE_MOVABLE. But the CDM nodes must also be isolated
from implicit allocations happening on the system.

Any isolation seeking CDM node requires isolation from implicit memory
allocations from user space but at the same time there should also have
an explicit way to do the memory allocation.

Platform node's both zonelists are fundamental to where the memory comes
from when there is an allocation request. In order to achieve these two
objectives as stated above, zonelists building process has to change as
both zonelists (i.e FALLBACK and NOFALLBACK) gives access to the node's
memory zones during any kind of memory allocation. The following changes
are implemented in this regard.

* CDM node's zones are not part of any other node's FALLBACK zonelist
* CDM node's FALLBACK list contains it's own memory zones followed by
  all system RAM zones in regular order as before


There was a discussion, on an earlier version of this patchset, in which someone 
pointed out that a slight over-allocation on a device that has much more memory than 
the CPU has, could use up system memory. Your latest approach here does not address 
this.


I'm thinking that, until oversubscription between NUMA nodes is more fully 
implemented in a way that can be properly controlled, you'd probably better just not 
fallback to system memory. In other words, a CDM node really is *isolated* from 
other nodes--no automatic use in either direction.


Also, naming and purpose: maybe this is a "Limited NUMA Node", rather than a 
Coherent Device Memory node. Because: the real point of this thing is to limit the 
normal operation of NUMA, just enough to work with what I am *told* is 
memory-that-is-too-fragile-for-kernel-use (I remain soemwhat on the fence, there, 
even though you did talk me into it earlier, heh).


On process: it would probably help if you gathered up previous discussion points and 
carefully, concisely addressed each one, somewhere, (maybe in a cover letter). 
Because otherwise, it's too easy for earlier, important problems to be forgotten. 
And reviewers don't want to have to repeat themselves, of course.


thanks
John Hubbard
NVIDIA


* CDM node's zones are part of it's own NOFALLBACK zonelist

These above changes ensure the following which in turn isolates the CDM
nodes as desired.

* There wont be any implicit memory allocation ending up in the CDM node
* Only __GFP_THISNODE marked allocations will come from the CDM node
* CDM node memory can be allocated through mbind(MPOL_BIND) interface
* System RAM memory will be used as fallback option in regular order in
  case the CDM memory is insufficient during targted allocation request

Sample zonelist configuration:

[NODE (0)]  RAM
ZONELIST_FALLBACK (0xc140da00)
(0) (node 0) (DMA 0xc140c000)
(1) (node 1) (DMA 0xc001)
ZONELIST_NOFALLBACK (0xc1411a10)
(0) (node 0) (DMA 0xc140c000)
[NODE (1)]  RAM
ZONELIST_FALLBACK (0xc0011a00)
(0) (node 1) (DMA 0xc001)
(1) (node 0) (DMA 0xc140c000)
ZONELIST_NOFALLBACK (0xc0015a10)
(0) (node 1) (DMA 0xc001)
[NODE (2)]  CDM
ZONELIST_FALLBACK (0xc1427700)
(0) (node 2) (Movable 0xc1427080)
(1) (node 0) (DMA 0xc140c000)
(2) (node 1) (DMA 0xc001)
ZONELIST_NOFALLBACK (0xc142b710)
(0) (node 2) (Movable 0xc1427080)
[NODE (3)]  CDM
ZONELIST_FALLBACK (0xc1431400)
(0) (node 3) (Movable 0xc1430d80)
(1) (node 0) (DMA 0xc140c000)
(2) (node 1) (DMA 0xc001)
ZONELIST_NOFALLBACK (0xc1435410)
(0) (node 3) (Movable 0xc1430d80)
[NODE (4)]  CDM
ZONELIST_FALLBACK (0xc143b100)
(0) (node 4) (Movable 0xc143aa80)
(1) (node 0) (DMA 0xc140c000)
(2) (node 1) (DMA 0xc001)
ZONELIST_NOFALLBACK (0xc143f110)
(0) (node 4) (Movable 0xc143aa80)

Signed-off-by: Anshuman Khandual 
---
 mm/page_alloc.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 40908de..6f7dddc 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4825,6 +4825,16 @@ static void build_zonelists(pg_data_t *pgdat)
i = 

Re: [PATCH 0/1] refcount: restore kref_get and kref_put to non-GPL status

[John Hubbard]

On 03/08/2017 01:48 AM, Greg Kroah-Hartman wrote:

On Wed, Mar 08, 2017 at 01:25:48AM -0800, john.hubb...@gmail.com wrote:

From: John Hubbard 

Hi,

Say, I'm 99% sure that this was just an oversight, so
I'm sticking my neck out here and floating a patch to
Put Things Back. I'm hoping that there is not some
firm reason to GPL-protect the basic kref_get and
kref_put routines, because when designing some
recent new (open-source, yay!) device drivers, we relied
on this being available, even for MIT-licensed code.


MIT-licensed code should be just fine with GPL symbols, just use the
correct MODULE_LICENSE() setting and all is good.


Actually, we're still using this license string:

   MODULE_LICENSE("MIT");

which I understand does *not* grant access to GPL symbols. So I guess we'd have to 
switch over to "MIT/GPL", if I understand correctly, in order to be all correct here.




As all of the previous kref functions were in a GPL-only header file,
and included directly that way, they were already GPL-only symbols, so
there really was no change here except now the linker checks them.  If
you have questions about using inline GPL-only functions from a .h file,
in a non-GPL codebase, please consult your corporate lawyer to get
clarification.


As much as I do enjoy chatting with those guys, I think I'll pass this time. :)

thanks,
John Hubbard
NVIDIA



thanks,

greg k-h

Re: [PATCH] clk: tegra: mark TEGRA210_CLK_DBGAPB as always on

[Jon Hunter]

Hi Peter,

On 06/03/17 15:53, Geert Uytterhoeven wrote:
> Hi Peter,
> 
> On Mon, Mar 6, 2017 at 3:28 PM, Peter De Schrijver
>  wrote:
>> On Mon, Mar 06, 2017 at 09:58:29AM +, Jon Hunter wrote:
>>> On 06/03/17 08:38, Peter De Schrijver wrote:
 On Thu, Mar 02, 2017 at 05:56:49PM +, Jon Hunter wrote:
> On 28/02/17 15:19, Peter De Schrijver wrote:
>> This is needed to make the JTAG debugging interface work.
>>
>> Signed-off-by: Peter De Schrijver 
>> ---
>>  drivers/clk/tegra/clk-tegra210.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/clk/tegra/clk-tegra210.c 
>> b/drivers/clk/tegra/clk-tegra210.c
>> index 9a2512a..708f5f1 100644
>> --- a/drivers/clk/tegra/clk-tegra210.c
>> +++ b/drivers/clk/tegra/clk-tegra210.c
>> @@ -2680,6 +2680,7 @@ static void tegra210_cpu_clock_resume(void)
>>   { TEGRA210_CLK_EMC, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>   { TEGRA210_CLK_MSELECT, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>   { TEGRA210_CLK_CSITE, TEGRA210_CLK_CLK_MAX, 0, 1 },
>> + { TEGRA210_CLK_DBGAPB, TEGRA210_CLK_CLK_MAX, 0, 1 },
>>   { TEGRA210_CLK_TSENSOR, TEGRA210_CLK_CLK_M, 40, 0 },
>>   { TEGRA210_CLK_I2C1, TEGRA210_CLK_PLL_P, 0, 0 },
>>   { TEGRA210_CLK_I2C2, TEGRA210_CLK_PLL_P, 0, 0 },
>
> Should there be some dependency on say CONFIG_DEBUG_KERNEL? I am not
> sure we always want this on for all cases.

 Why would you not want it to be always on?
>>>
>>> Purely for power reasons. I do not know how much power keeping this
>>
>> I don't expect it to be significant but I don't have any numbers.
>>
>>> clock running consumes, but I don't like the idea of clocks running all
>>> the time when they are not needed.
>>
>> Problem is that in this case there is no easy way to determine if the clock
>> needs to be on.
> 
> I had a similar issue with SH-Mobile AG5, where the power domain containing
> the JTAG interface is powered down.

This reminds me, does your patch assume that the DFD power domain is
enabled? I am guessing that it needs to be for JTAG to work.

Cheers
Jon

-- 
nvpublic

Re: [PATCH v2 08/22] PCI: dwc: designware: Add EP mode support

[Joao Pinto]

Às 11:35 AM de 3/8/2017, Kishon Vijay Abraham I escreveu:
> Hi,
> 
> On Wednesday 08 March 2017 05:02 PM, Joao Pinto wrote:
>>
>> Hi Kishon,
>>
 Can you provide PCIE_GET_ATU_INB_UNR_REG_OFFSET (similar to
 PCIE_GET_ATU_OUTB_UNR_REG_OFFSET)?
>>>
>>> Yes of course, I will send you the definition soon.
>>
>> As promissed here is the definition for Inbound:
>>
>> +/* register address builder */
>> +#define PCIE_GET_ATU_INB_UNR_REG_ADDR(region, register) \
>> +((0x3 << 20) | (region << 9) |  \
>> +(0x1 << 8) | (register << 2))
> 
> Cool, thanks!

No problem! If you have doubts, please let me know.

Thanks,
Joao

> 
> -Kishon
>>
>> Thanks,
>> Joao
>>
>>>
>>> Thanks,
>>> Joao
>>>

 Thanks
 Kishon

>>>
>>

Re: [PATCH v4] soc/imx: Add GPCv2 power gating driver

[Shawn Guo]

On Tue, Feb 28, 2017 at 04:09:16PM -0800, Andrey Smirnov wrote:
> Add code allowing for control of various power domains managed by GPCv2

GPCv2, is it the name used in i.MX7 SoC manual?

> IP block found in i.MX7 series of SoCs. Power domains covered by this
> patch are:
> 
> - PCIE PHY
> - MIPI PHY
> - USB HSIC PHY
> - USB OTG1/2 PHY
> 
> Support for any other power domain controlled by GPC is not present, and
> can be added at some later point.
> 
> Testing of this code was done against a PCIe driver.
> 
> Cc: yurov...@gmail.com
> Cc: Lucas Stach 
> Cc: Rob Herring 
> Cc: Mark Rutland 
> Cc: Fabio Estevam 
> Cc: devicet...@vger.kernel.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-kernel@vger.kernel.org
> Acked-by: Rob Herring 
> Signed-off-by: Andrey Smirnov 
> ---
> 
> Changes since v3 (see [v3]):
> 
>   - Minor device tree bindings documentation fixes as per
>   feedback from Rob Herring
>   - Collect Acked-by from Rob
> 
> Changes since v2 (see [v2]):
> 
>   - Fix a critical bug where incorrect state of a bit was
>   expected in a busy wait loop (bit set instead of bit
>   cleared) imx7_gpc_pu_pgc_sw_pxx_req()
> 
>   - Add missing step (setting of PCR in GPC_PGC_nCTRL) in power
>   down procedure
> 
> Changes since v1 (see [v1]):
> 
>   - Various small DT bindings description fixes as per feedback
>   from Rob Herring
> 
> 
> [v1] https://lkml.org/lkml/2017/2/6/554
> [v2] https://lkml.org/lkml/2017/2/13/489
> [v3] https://lkml.org/lkml/2017/2/20/338
> 
>  .../devicetree/bindings/power/fsl,imx-gpcv2.txt|  71 
>  drivers/soc/imx/Makefile   |   2 +-
>  drivers/soc/imx/gpcv2.c| 397 
> +
>  include/dt-bindings/power/imx7-power.h |  18 +

Please have fsl,imx-gpcv2.txt and imx7-power.h in a separate dt-bindings
patch, and attach Rob's ACK to it.

>  4 files changed, 487 insertions(+), 1 deletion(-)
>  create mode 100644 Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
>  create mode 100644 drivers/soc/imx/gpcv2.c
>  create mode 100644 include/dt-bindings/power/imx7-power.h
> 
> diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt 
> b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
> new file mode 100644
> index 000..02f45c6
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.txt
> @@ -0,0 +1,71 @@
> +Freescale i.MX General Power Controller v2
> +==
> +
> +The i.MX7S/D General Power Control (GPC) block contains Power Gating
> +Control (PGC) for various power domains.
> +
> +Required properties:
> +
> +- compatible: Should be "fsl,imx7d-gpc"
> +
> +- reg: should be register base and length as documented in the
> +  datasheet
> +
> +- interrupts: Should contain GPC interrupt request 1
> +
> +Power domains contained within GPC node are generic power domain
> +providers, documented in
> +Documentation/devicetree/bindings/power/power_domain.txt, which are
> +described as subnodes of the power gating controller 'pgc' node,
> +which, in turn, is expected to contain the following:
> +
> +Required properties:
> +
> +- reg: Power domain index. Valid values are defined in
> +  include/dt-bindings/power/imx7-power.h
> +
> +- #power-domain-cells: Should be 0
> +
> +Optional properties:
> +
> +- power-supply: Power supply used to power the domain
> +
> +Example:
> +
> + gpc: gpc@303a {
> + compatible = "fsl,imx7d-gpc";
> + reg = <0x303a 0x1000>;
> + interrupt-controller;
> + interrupts = ;
> + #interrupt-cells = <3>;
> + interrupt-parent = <>;
> +
> + pgc {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + pgc_pcie_phy: power-domain@3 {
> + #power-domain-cells = <0>;
> +
> + reg = ;
> + power-supply = <_1p0d>;
> + };
> + };
> + };
> +
> +
> +Specifying power domain for IP modules
> +==
> +
> +IP cores belonging to a power domain should contain a 'power-domains'
> +property that is a phandle for PGC node representing the domain.
> +
> +Example of a device that is part of the PCIE_PHY power domain:
> +
> + pcie: pcie@3380 {
> +   reg = <0x3380 0x4000>,
> + <0x4ff0 0x8>;
> + /* ... */
> + power-domains = <_pcie_phy>;
> + /* ... */
> + };
> diff --git a/drivers/soc/imx/Makefile b/drivers/soc/imx/Makefile
> index 35861f5..7bcc933 100644
> --- a/drivers/soc/imx/Makefile
> +++ b/drivers/soc/imx/Makefile
> @@ -1 +1 @@
> 

Re: [PATCH v2 08/22] PCI: dwc: designware: Add EP mode support

[Kishon Vijay Abraham I]

Hi,

On Wednesday 08 March 2017 05:02 PM, Joao Pinto wrote:
> 
> Hi Kishon,
> 
>>> Can you provide PCIE_GET_ATU_INB_UNR_REG_OFFSET (similar to
>>> PCIE_GET_ATU_OUTB_UNR_REG_OFFSET)?
>>
>> Yes of course, I will send you the definition soon.
> 
> As promissed here is the definition for Inbound:
> 
> +/* register address builder */
> +#define PCIE_GET_ATU_INB_UNR_REG_ADDR(region, register)  \
> + ((0x3 << 20) | (region << 9) |  \
> + (0x1 << 8) | (register << 2))

Cool, thanks!

-Kishon
> 
> Thanks,
> Joao
> 
>>
>> Thanks,
>> Joao
>>
>>>
>>> Thanks
>>> Kishon
>>>
>>
> 

Re: [PATCH] mm: drop "wait" parameter from write_one_page

[Jeff Layton]

On Wed, 2017-03-08 at 00:34 -0800, John Hubbard wrote:
> On 03/05/2017 05:23 AM, Jeff Layton wrote:
> > The callers all have it set to 1 anyway. Also, make it clear that this
> > function will not set any sort of AS_* error, and that the caller must
> > do so if necessary.
> 
> Hi Jeff,
> 
> Silly nit: The above bit about not setting AS_* errors seems to not have made 
> it 
> into the write_one_page() comment header. I see that it now says it will 
> (unconditionally) wait on IO, which implies no async IO errors, that's true. 
> But 
> also the part about the caller setting having to set that...makes it look 
> like you 
> intended to document this in the code, but got interrupted, maybe?
> 
> The code changes look perfect, though. And although I'm not a fs guy, it 
> seems 
> pretty clear that with all the callers passing in 1 all this time, nobody is 
> likely 
> to complain about this simplification.
> 
> thanks,
> John Hubbard
> NVIDIA
> 

Thanks for having a look. That blurb in the changelog refers to the
kerneldoc comment over write_one_page below...

> 
>   No existing caller uses this on normal files, so
> > none of them need it.
> > 
> > Signed-off-by: Jeff Layton 
> > ---
> >  fs/exofs/dir.c|  2 +-
> >  fs/ext2/dir.c |  2 +-
> >  fs/jfs/jfs_metapage.c |  4 ++--
> >  fs/minix/dir.c|  2 +-
> >  fs/sysv/dir.c |  2 +-
> >  fs/ufs/dir.c  |  2 +-
> >  include/linux/mm.h|  2 +-
> >  mm/page-writeback.c   | 14 +++---
> >  8 files changed, 15 insertions(+), 15 deletions(-)
> > 
> > diff --git a/fs/exofs/dir.c b/fs/exofs/dir.c
> > index 42f9a0a0c4ca..e163ed980c20 100644
> > --- a/fs/exofs/dir.c
> > +++ b/fs/exofs/dir.c
> > @@ -72,7 +72,7 @@ static int exofs_commit_chunk(struct page *page, loff_t 
> > pos, unsigned len)
> > set_page_dirty(page);
> > 
> > if (IS_DIRSYNC(dir))
> > -   err = write_one_page(page, 1);
> > +   err = write_one_page(page);
> > else
> > unlock_page(page);
> > 
> > diff --git a/fs/ext2/dir.c b/fs/ext2/dir.c
> > index d9650c9508e4..e2709695b177 100644
> > --- a/fs/ext2/dir.c
> > +++ b/fs/ext2/dir.c
> > @@ -100,7 +100,7 @@ static int ext2_commit_chunk(struct page *page, loff_t 
> > pos, unsigned len)
> > }
> > 
> > if (IS_DIRSYNC(dir)) {
> > -   err = write_one_page(page, 1);
> > +   err = write_one_page(page);
> > if (!err)
> > err = sync_inode_metadata(dir, 1);
> > } else {
> > diff --git a/fs/jfs/jfs_metapage.c b/fs/jfs/jfs_metapage.c
> > index 489aaa1403e5..744fa3c079e6 100644
> > --- a/fs/jfs/jfs_metapage.c
> > +++ b/fs/jfs/jfs_metapage.c
> > @@ -711,7 +711,7 @@ void force_metapage(struct metapage *mp)
> > get_page(page);
> > lock_page(page);
> > set_page_dirty(page);
> > -   write_one_page(page, 1);
> > +   write_one_page(page);
> > clear_bit(META_forcewrite, >flag);
> > put_page(page);
> >  }
> > @@ -756,7 +756,7 @@ void release_metapage(struct metapage * mp)
> > set_page_dirty(page);
> > if (test_bit(META_sync, >flag)) {
> > clear_bit(META_sync, >flag);
> > -   write_one_page(page, 1);
> > +   write_one_page(page);
> > lock_page(page); /* write_one_page unlocks the page */
> > }
> > } else if (mp->lsn) /* discard_metapage doesn't remove it */
> > diff --git a/fs/minix/dir.c b/fs/minix/dir.c
> > index 7edc9b395700..baa9721f1299 100644
> > --- a/fs/minix/dir.c
> > +++ b/fs/minix/dir.c
> > @@ -57,7 +57,7 @@ static int dir_commit_chunk(struct page *page, loff_t 
> > pos, unsigned len)
> > mark_inode_dirty(dir);
> > }
> > if (IS_DIRSYNC(dir))
> > -   err = write_one_page(page, 1);
> > +   err = write_one_page(page);
> > else
> > unlock_page(page);
> > return err;
> > diff --git a/fs/sysv/dir.c b/fs/sysv/dir.c
> > index 5bdae85ceef7..f5191cb2c947 100644
> > --- a/fs/sysv/dir.c
> > +++ b/fs/sysv/dir.c
> > @@ -45,7 +45,7 @@ static int dir_commit_chunk(struct page *page, loff_t 
> > pos, unsigned len)
> > mark_inode_dirty(dir);
> > }
> > if (IS_DIRSYNC(dir))
> > -   err = write_one_page(page, 1);
> > +   err = write_one_page(page);
> > else
> > unlock_page(page);
> > return err;
> > diff --git a/fs/ufs/dir.c b/fs/ufs/dir.c
> > index de01b8f2aa78..48609f1d9580 100644
> > --- a/fs/ufs/dir.c
> > +++ b/fs/ufs/dir.c
> > @@ -53,7 +53,7 @@ static int ufs_commit_chunk(struct page *page, loff_t 
> > pos, unsigned len)
> > mark_inode_dirty(dir);
> > }
> > if (IS_DIRSYNC(dir))
> > -   err = write_one_page(page, 1);
> > +   err = write_one_page(page);
> > else
> > unlock_page(page);
> > return err;
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index b84615b0f64c..e17ebedba623 100644
> > --- a/include/linux/mm.h
> > 

Re: [PATCH v2 1/2] Staging: comedi: comedi_fops: Change comedi_num_legacy_minors type

[Ian Abbott]

On 07/03/17 18:13, Cheah Kok Cheong wrote:

Change to unsigned to allow removal of negative value check in
init section. Use smaller data type since the max possible
value currently is 48.

Signed-off-by: Cheah Kok Cheong 
---

V2:
-No changes.

 drivers/staging/comedi/comedi_fops.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/comedi/comedi_fops.c 
b/drivers/staging/comedi/comedi_fops.c
index 57e8599..354d264 100644
--- a/drivers/staging/comedi/comedi_fops.c
+++ b/drivers/staging/comedi/comedi_fops.c
@@ -76,8 +76,8 @@ struct comedi_file {
 #define COMEDI_NUM_SUBDEVICE_MINORS\
(COMEDI_NUM_MINORS - COMEDI_NUM_BOARD_MINORS)

-static int comedi_num_legacy_minors;
-module_param(comedi_num_legacy_minors, int, 0444);
+static unsigned short comedi_num_legacy_minors;
+module_param(comedi_num_legacy_minors, ushort, 0444);
 MODULE_PARM_DESC(comedi_num_legacy_minors,
 "number of comedi minor devices to reserve for non-auto-configured 
devices (default 0)"
);
@@ -2857,8 +2857,7 @@ static int __init comedi_init(void)

pr_info("version " COMEDI_RELEASE " - http://www.comedi.org\n;);

-   if (comedi_num_legacy_minors < 0 ||
-   comedi_num_legacy_minors > COMEDI_NUM_BOARD_MINORS) {
+   if (comedi_num_legacy_minors > COMEDI_NUM_BOARD_MINORS) {
pr_err("invalid value for module parameter 
\"comedi_num_legacy_minors\".  Valid values are 0 through %i.\n",
   COMEDI_NUM_BOARD_MINORS);
return -EINVAL;



Thanks.  (There is no harm in making the parameter unsigned short rather 
than unsigned int, although it's probably not worth it as you still need 
to check the value.  It doesn't matter either way.)


Reviewed-by: Ian Abbott 

--
-=( Ian Abbott @ MEV Ltd.E-mail:  )=-
-=(  Web: http://www.mev.co.uk/  )=-

Re: [tip:x86/asm] x86/asm: Optimize clear_page()

[Ingo Molnar]

* Yinghai Lu  wrote:

> On Mon, Mar 6, 2017 at 11:30 PM, Ingo Molnar  wrote:
> >
> > * Yinghai Lu  wrote:
> >
> >> On Wed, Mar 1, 2017 at 1:47 AM, tip-bot for Borislav Petkov
> >>  wrote:
> >> > Commit-ID:  49ca7bb328c630dd43be626534b49e19513296fd
> >> > Gitweb: 
> >> > http://git.kernel.org/tip/49ca7bb328c630dd43be626534b49e19513296fd
> >> > Author: Borislav Petkov 
> >> > AuthorDate: Thu, 9 Feb 2017 01:34:49 +0100
> >> > Committer:  Ingo Molnar 
> >> > CommitDate: Wed, 1 Mar 2017 10:18:32 +0100
> >> >
> >> > x86/asm: Optimize clear_page()
> >> >
> >> > Currently, we CALL clear_page() which then JMPs to the proper function
> >> > chosen by the alternatives.
> >> >
> >> > What we should do instead is CALL the proper function directly. (This
> >> > was something Ingo suggested a while ago). So let's do that.
> >>
> >> looks like this one broke the kexec.
> >> after revert it back, kexec work again.
> >
> > Ok, this should be fixed in the new version I just pushed out:
> >
> >   f25d38475519 x86/asm: Optimize clear_page()
> >
> > Please let me know if it doesn't.
> 
> Yes. new commit works with kexec.
> 
> Thanks

Thanks for testing!

Ingo

Re: counting file descriptors with a cgroup controller

[Krzysztof Opasiak]

On 03/07/2017 09:48 PM, Tejun Heo wrote:

Hello,

On Tue, Mar 07, 2017 at 09:06:49PM +0100, Krzysztof Opasiak wrote:

Personally, I don't want to use rlimit for this as it ends up returning
error code from for example open() when we hit the limit. This may lead to
some unpredictable crashes in  services (esp. those poor proprietary binary
blobs). Instead of injecting errors to service we would like to just get
notification that this service has more opened fds than it should and ask it
to restart in a polite way.

For memory seems to be quite easy to achieve as we can just get eventfd
notification when application passes given memory usage using memory cgroup
controller. Maybe you know some efficient method to do the same for fds?


So, if all you wanna do is reliably detecting open(2) failures, can't
you do that with bpf tracing?



Well detecting failures of open is not enough and it has couple of problems:

1) open(2) is not the only syscall which creates fd. In addition to 
other syscalls like socket(2), dup(2), some ioctl() on drivers (for 
example video) also creates fds. I'm not sure if we have any other 
mechanism than grep through kernel source to find out which ioctl() 
creates fd or and which not.


2) As far as I know (I'm not a bpf specialist so please correct me if 
I'm wrong), with bpf we are able only to detect such events but we are 
unable to prevent them from getting to caller. It means that service 
will know that it run out of fds and will need to handle this properly. 
If there is a bug in this error path service may crash.
What we would like to get is just a notification to external process 
that some limit has been reached without returning error to service itself.


3) Theoretically we could do this using bpf or syscall auditing and 
count fds for each userspace process or check /proc/ after each 
notification but it's getting very heavy for production environment.


Best regards,
--
Krzysztof Opasiak
Samsung R Institute Poland
Samsung Electronics

Re: [PATCH RESEND^2] usb: gadget: udc: atmel: fix debug output

[Felipe Balbi]

Hi,

Arnd Bergmann  writes:
> The debug output now contains the wrong variable, as seen from the compiler
> warning:
>
> drivers/usb/gadget/udc/atmel_usba_udc.c: In function 'usba_ep_enable':
> drivers/usb/gadget/udc/atmel_usba_udc.c:632:550: error: 'ept_cfg' may be used 
> uninitialized in this function [-Werror=maybe-uninitialized]
>   DBG(DBG_ERR, "%s: EPT_CFG = 0x%lx (maxpacket = %lu)\n",
>
> This changes the debug output the same way as the other code.
>
> Fixes: 741d2558bf0a ("usb: gadget: udc: atmel: Update endpoint allocation 
> scheme")
> Signed-off-by: Arnd Bergmann 
> Acked-by: Alexandre Belloni 
> Acked-by: Nicolas Ferre 
> ---
> Originally this broke on Feb 1 and I sent this fix,
> I resent it after it wasn't applied by Feb 22.
>
> This is now one of only two build regressions that made it into
> 4.11-rc1 that are still broken on linux-next. Please apply

heh, it's in my queue. Just gimme time, I have a day job that's 100%
dedicated to mainline ;-)

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH V3 0/4] Define coherent device memory node

[Anshuman Khandual]

On 03/01/2017 04:29 PM, Balbir Singh wrote:
> On Wed, Mar 1, 2017 at 8:55 PM, Mel Gorman  wrote:
>> On Wed, Mar 01, 2017 at 01:42:40PM +1100, Balbir Singh wrote:
>> The idea of this patchset was to introduce
>> the concept of memory that is not necessarily system memory, but is 
>> coherent
>> in terms of visibility/access with some restrictions
>>
> Which should be done without special casing the page allocator, cpusets 
> and
> special casing how cpusets are handled. It's not necessary for any other
> mechanism used to restrict access to portions of memory such as cpusets,
> mempolicies or even memblock reservations.
 Agreed, I mentioned a limitation that we see a cpusets. I do agree that
 we should reuse any infrastructure we have, but cpusets are more static
 in nature and inheritence compared to the requirements of CDM.

>>> Mel, I went back and looked at cpusets and found some limitations that
>>> I mentioned earlier, isolating a particular node requires some amount
>>> of laborious work in terms of isolating all tasks away from the root cpuset
>>> and then creating a hierarchy where the root cpuset is empty and now
>>> belong to a child cpuset that has everything but the node we intend to
>>> ioslate. Even with hardwalling, it does not prevent allocations from
>>> the parent cpuset.
>>>
>> That it is difficult does not in itself justify adding a third mechanism
>> specific to one type of device for controlling access to memory.
>>
> Not only is it difficult, but there are several tasks that refuse to
> change cpusets once created. I also noticed that the isolation may
> begin a little too late, some allocations may end up on the node to
> isolate.
> 
> I also want to eventually control whether auto-numa
> balancing/kswapd/reclaim etc run on this node (something that cpusets
> do not provide). The reason for these decisions is very dependent on
> the properties of the node. The isolation mechanism that exists today
> is insufficient. Moreover the correct abstraction for device memory
> would be a class similar to N_MEMORY, but limited in what we include
> (which is why I was asking if questions 3 and 4 are clear). You might
> argue these are not NUMA nodes then, but these are in general sense
> NUMA nodes (with non-uniform properties and access times). NUMA allows
> with the right hardware expose the right programming model. Please
> consider reading the full details at
> 
> https://patchwork.kernel.org/patch/9566393/
> https://lkml.org/lkml/2016/11/22/339

As explained by Balbir, right now cpuset mechanism gives only isolation
and is insufficient for creating other properties required for full
fledged CDM representation. NUMA representation is the close match for
CDM memory which represents non uniform attributes instead of distance
as the only differentiating property. Once represented as a NUMA node
in the kernel, we can achieve the isolation requirement either through
buddy allocator changes as proposed in this series or can look into
some alternative approaches as well. As I had mentioned in the last
RFC there is another way to achieve isolation through zonelist rebuild
process changes and mbind() implementation changes. Please find those
two relevant commits here.

https://github.com/akhandual/linux/commit/da1093599db29c31d12422a34d4e0cbf4683618f
https://github.com/akhandual/linux/commit/faadab4e9dc9685ab7a564a84d4a06bde8fc79d8

Will post these commits on this thread for further discussion. Do let
me know your views and suggestions on this approach.

[PATCH] f2fs: don't allow rename unencrypted file to encrypted directory

[Chao Yu]

In commit d9cdc9033181 ("ext4 crypto: enforce context consistency") we
declared that:

2) All files or directories in a directory must be protected using the
same key as their containing directory.

But in f2fs_cross_rename there is a vulnerability that allow to cross
rename unencrypted file into encrypted directory, it needs to be refused.

Signed-off-by: Chao Yu 
---
 fs/f2fs/namei.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/fs/f2fs/namei.c b/fs/f2fs/namei.c
index 25c073f6c7d4..8de684b84cb9 100644
--- a/fs/f2fs/namei.c
+++ b/fs/f2fs/namei.c
@@ -855,6 +855,10 @@ static int f2fs_cross_rename(struct inode *old_dir, struct 
dentry *old_dentry,
!fscrypt_has_encryption_key(new_dir)))
return -ENOKEY;
 
+   if (f2fs_encrypted_inode(old_dir) && !f2fs_encrypted_inode(new_inode) ||
+   f2fs_encrypted_inode(new_dir) && 
!f2fs_encrypted_inode(old_inode))
+   return -EPERM;
+
if ((f2fs_encrypted_inode(old_dir) || f2fs_encrypted_inode(new_dir)) &&
(old_dir != new_dir) &&
(!fscrypt_has_permitted_context(new_dir, old_inode) ||
-- 
2.8.2.295.g3f1c1d0

Re: linux-next: build failure after merge of the rcu tree

[Daniel Vetter]

On Wed, Mar 08, 2017 at 12:16:45PM +1100, Stephen Rothwell wrote:
> Hi Paul,
> 
> After merging the rcu tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
> In file included from include/linux/resource_ext.h:19:0,
>  from include/linux/pci.h:32,
>  from include/drm/drmP.h:50,
>  from drivers/gpu/drm/i915/i915_gem.c:28:
> drivers/gpu/drm/i915/selftests/mock_gem_device.c: In function 
> 'mock_gem_device':
> drivers/gpu/drm/i915/selftests/mock_gem_device.c:177:9: error: 
> 'SLAB_DESTROY_BY_RCU' undeclared (first use in this function)
>  SLAB_DESTROY_BY_RCU);
>  ^
> include/linux/slab.h:149:4: note: in definition of macro 'KMEM_CACHE'
>(__flags), NULL)
> ^
> drivers/gpu/drm/i915/selftests/mock_gem_device.c:177:9: note: each undeclared 
> identifier is reported only once for each function it appears in
>  SLAB_DESTROY_BY_RCU);
>  ^
> include/linux/slab.h:149:4: note: in definition of macro 'KMEM_CACHE'
>(__flags), NULL)
> ^
> /
> 
> Caused by commit
> 
>   24b7cb25b8d1 ("mm: Rename SLAB_DESTROY_BY_RCU to SLAB_TYPESAFE_BY_RCU")

Awesome rename. Count us in among the people who first thought this
provides more guarantees than it does.

> interacting with commit
> 
>   0daf0113cff6 ("drm/i915: Mock infrastructure for request emission")
> 
> from the drm-intel tree.
> 
> I added the following merge fix patch:
> 
> From: Stephen Rothwell 
> Date: Wed, 8 Mar 2017 12:09:49 +1100
> Subject: [PATCH] drm/i915: merge fix for "mm: Rename SLAB_DESTROY_BY_RCU to
>  SLAB_TYPESAFE_BY_RCU"
> 
> Signed-off-by: Stephen Rothwell 

Should we handle this with a topic branch? It's trivial to resolve, but I
fear the note that this conflict exists might get lost somewhere between
now and when the drm pull lands in Linus' inbox in 2 months ...

Otoh he's probably going to compile test drm extra carefully and will
notice :-)
-Daniel

> ---
>  drivers/gpu/drm/i915/selftests/mock_gem_device.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
> b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> index 6a8258eacdcb..9f24c5da3f8d 100644
> --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
> @@ -174,7 +174,7 @@ struct drm_i915_private *mock_gem_device(void)
>   i915->requests = KMEM_CACHE(mock_request,
>   SLAB_HWCACHE_ALIGN |
>   SLAB_RECLAIM_ACCOUNT |
> - SLAB_DESTROY_BY_RCU);
> + SLAB_TYPESAFE_BY_RCU);
>   if (!i915->requests)
>   goto err_vmas;
>  
> -- 
> 2.11.0
> 
> -- 
> Cheers,
> Stephen Rothwell

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH v3] f2fs: combine nat_bits and free_nid_bitmap cache

[Chao Yu]

Both nat_bits cache and free_nid_bitmap cache provide same functionality
as a intermediate cache between free nid cache and disk, but with
different granularity of indicating free nid range, and different
persistence policy. nat_bits cache provides better persistence ability,
and free_nid_bitmap provides better granularity.

In this patch we combine advantage of both caches, so finally policy of
the intermediate cache would be:
- init: load free nid status from nat_bits into free_nid_bitmap
- lookup: scan free_nid_bitmap before load NAT blocks
- update: update free_nid_bitmap in real-time
- persistence: udpate and persist nat_bits in checkpoint

Signed-off-by: Chao Yu 
Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/node.c | 125 ++---
 1 file changed, 47 insertions(+), 78 deletions(-)

diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
index 4b441cadd2ba..0a1ea59c9d31 100644
--- a/fs/f2fs/node.c
+++ b/fs/f2fs/node.c
@@ -332,9 +332,6 @@ static void set_node_addr(struct f2fs_sb_info *sbi, struct 
node_info *ni,
set_nat_flag(e, IS_CHECKPOINTED, false);
__set_nat_cache_dirty(nm_i, e);
 
-   if (enabled_nat_bits(sbi, NULL) && new_blkaddr == NEW_ADDR)
-   clear_bit_le(NAT_BLOCK_OFFSET(ni->nid), nm_i->empty_nat_bits);
-
/* update fsync_mark if its inode nat entry is still alive */
if (ni->nid != ni->ino)
e = __lookup_nat_cache(nm_i, ni->ino);
@@ -1818,7 +1815,7 @@ static void remove_free_nid(struct f2fs_sb_info *sbi, 
nid_t nid)
 }
 
 void update_free_nid_bitmap(struct f2fs_sb_info *sbi, nid_t nid,
-   bool set, bool build)
+   bool set, bool build, bool locked)
 {
struct f2fs_nm_info *nm_i = NM_I(sbi);
unsigned int nat_ofs = NAT_BLOCK_OFFSET(nid);
@@ -1832,12 +1829,14 @@ void update_free_nid_bitmap(struct f2fs_sb_info *sbi, 
nid_t nid,
else
__clear_bit_le(nid_ofs, nm_i->free_nid_bitmap[nat_ofs]);
 
-   spin_lock(_i->free_nid_lock);
+   if (!locked)
+   spin_lock(_i->free_nid_lock);
if (set)
nm_i->free_nid_count[nat_ofs]++;
else if (!build)
nm_i->free_nid_count[nat_ofs]--;
-   spin_unlock(_i->free_nid_lock);
+   if (!locked)
+   spin_unlock(_i->free_nid_lock);
 }
 
 static void scan_nat_page(struct f2fs_sb_info *sbi,
@@ -1866,7 +1865,7 @@ static void scan_nat_page(struct f2fs_sb_info *sbi,
f2fs_bug_on(sbi, blk_addr == NEW_ADDR);
if (blk_addr == NULL_ADDR)
freed = add_free_nid(sbi, start_nid, true);
-   update_free_nid_bitmap(sbi, start_nid, freed, true);
+   update_free_nid_bitmap(sbi, start_nid, freed, true, false);
}
 }
 
@@ -1914,58 +1913,6 @@ static void scan_free_nid_bits(struct f2fs_sb_info *sbi)
up_read(_i->nat_tree_lock);
 }
 
-static int scan_nat_bits(struct f2fs_sb_info *sbi)
-{
-   struct f2fs_nm_info *nm_i = NM_I(sbi);
-   struct page *page;
-   unsigned int i = 0;
-   nid_t nid;
-
-   if (!enabled_nat_bits(sbi, NULL))
-   return -EAGAIN;
-
-   down_read(_i->nat_tree_lock);
-check_empty:
-   i = find_next_bit_le(nm_i->empty_nat_bits, nm_i->nat_blocks, i);
-   if (i >= nm_i->nat_blocks) {
-   i = 0;
-   goto check_partial;
-   }
-
-   for (nid = i * NAT_ENTRY_PER_BLOCK; nid < (i + 1) * NAT_ENTRY_PER_BLOCK;
-   nid++) {
-   if (unlikely(nid >= nm_i->max_nid))
-   break;
-   add_free_nid(sbi, nid, true);
-   }
-
-   if (nm_i->nid_cnt[FREE_NID_LIST] >= MAX_FREE_NIDS)
-   goto out;
-   i++;
-   goto check_empty;
-
-check_partial:
-   i = find_next_zero_bit_le(nm_i->full_nat_bits, nm_i->nat_blocks, i);
-   if (i >= nm_i->nat_blocks) {
-   disable_nat_bits(sbi, true);
-   up_read(_i->nat_tree_lock);
-   return -EINVAL;
-   }
-
-   nid = i * NAT_ENTRY_PER_BLOCK;
-   page = get_current_nat_page(sbi, nid);
-   scan_nat_page(sbi, page, nid);
-   f2fs_put_page(page, 1);
-
-   if (nm_i->nid_cnt[FREE_NID_LIST] < MAX_FREE_NIDS) {
-   i++;
-   goto check_partial;
-   }
-out:
-   up_read(_i->nat_tree_lock);
-   return 0;
-}
-
 static void __build_free_nids(struct f2fs_sb_info *sbi, bool sync, bool mount)
 {
struct f2fs_nm_info *nm_i = NM_I(sbi);
@@ -1987,21 +1934,6 @@ static void __build_free_nids(struct f2fs_sb_info *sbi, 
bool sync, bool mount)
 
if (nm_i->nid_cnt[FREE_NID_LIST])
return;
-
-   /* try to find free nids with nat_bits */
-   if (!scan_nat_bits(sbi) && 

Re: [lkp-robot] [locking/ww_mutex] 857811a371: INFO:task_blocked_for_more_than#seconds

[Chris Wilson]

On Wed, Mar 08, 2017 at 09:08:54AM +0800, kernel test robot wrote:
> 
> FYI, we noticed the following commit:
> 
> commit: 857811a37129f5d2ba162d7be3986eff44724014 ("locking/ww_mutex: Adjust 
> the lock number for stress test")
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> 
> in testcase: boot
> 
> on test machine: qemu-system-i386 -enable-kvm -m 320M
> 
> caused below changes (please refer to attached dmesg/kmsg for entire 
> log/backtrace):

Now the test is running, it takes too long. :)

wait_for_completion_interruptible() would stop the hung task check? That
leaves NMI watchdog to check if we hit a deadlock between the workers.

And add a timeout to the stress test.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre

Re: [PATCH v4 3/7] mmc: bcm2835: add sdhost controller to devicetree

[Stefan Wahren]

Am 08.03.2017 um 10:19 schrieb Gerd Hoffmann:

Signed-off-by: Gerd Hoffmann 
Acked-by: Eric Anholt 


Acked-by: Stefan Wahren 


---
  arch/arm/boot/dts/bcm2835-rpi.dtsi |  6 ++
  arch/arm/boot/dts/bcm283x.dtsi | 10 ++
  2 files changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/bcm2835-rpi.dtsi 
b/arch/arm/boot/dts/bcm2835-rpi.dtsi
index 1e00a28..8b95832 100644
--- a/arch/arm/boot/dts/bcm2835-rpi.dtsi
+++ b/arch/arm/boot/dts/bcm2835-rpi.dtsi
@@ -69,6 +69,12 @@
bus-width = <4>;
  };
  
+ {

+   pinctrl-names = "default";
+   pinctrl-0 = <_gpio48>;
+   bus-width = <4>;
+};
+
   {
pinctrl-names = "default";
pinctrl-0 = <_gpio40 _gpio45>;
diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
index 9798bc9..19099a5 100644
--- a/arch/arm/boot/dts/bcm283x.dtsi
+++ b/arch/arm/boot/dts/bcm283x.dtsi
@@ -350,6 +350,16 @@
arm,primecell-periphid = <0x00241011>;
};
  
+		sdhost: mmc@7e202000 {

+   compatible = "brcm,bcm2835-sdhost";
+   reg = <0x7e202000 0x100>;
+   interrupts = <2 24>;
+   clocks = < BCM2835_CLOCK_VPU>;
+   dmas = < 13>;
+   dma-names = "rx-tx";
+   status = "disabled";
+   };
+
i2s: i2s@7e203000 {
compatible = "brcm,bcm2835-i2s";
reg = <0x7e203000 0x20>,

Re: [PATCH 0/1] refcount: restore kref_get and kref_put to non-GPL status

[John Hubbard]

On 03/08/2017 02:12 AM, Greg Kroah-Hartman wrote:

On Wed, Mar 08, 2017 at 01:59:33AM -0800, John Hubbard wrote:



On 03/08/2017 01:48 AM, Greg Kroah-Hartman wrote:

On Wed, Mar 08, 2017 at 01:25:48AM -0800, john.hubb...@gmail.com wrote:

From: John Hubbard 

Hi,

Say, I'm 99% sure that this was just an oversight, so
I'm sticking my neck out here and floating a patch to
Put Things Back. I'm hoping that there is not some
firm reason to GPL-protect the basic kref_get and
kref_put routines, because when designing some
recent new (open-source, yay!) device drivers, we relied
on this being available, even for MIT-licensed code.


MIT-licensed code should be just fine with GPL symbols, just use the
correct MODULE_LICENSE() setting and all is good.


Actually, we're still using this license string:

   MODULE_LICENSE("MIT");

which I understand does *not* grant access to GPL symbols. So I guess we'd
have to switch over to "MIT/GPL", if I understand correctly, in order to be
all correct here.


You need to write this as:
MODULE_LICENSE("Dual MIT/GPL");
for the linker to handle this properly as that is the string it is
looking for.


Yes, understood. I thought from your previous response that maybe "MIT" alone was 
*intended* to provide access, but this makes sense and matches what I'd thought 
earlier. And of course, your other point (about the header itself being licensed) 
overrides this, but it's nice to get clarification on this detail, as long as I'm 
stuck--for now--on "MIT".


Appreciate your time and quick responses on this, I know it's probably tiresome to 
answer these sorts of questions.


thanks again,
john h




thanks,

greg k-h

[RFC PATCH, -v2] sched/wait: Introduce new, more compact wait_event*() primitives

[Ingo Molnar]

* Ingo Molnar  wrote:

> + if (___wait_is_interruptible(0) && wes->ret) {

So that line is dumb and bogus, it should be:

if (___wait_is_interruptible(TASK_UNINTERRUPTIBLE) && wes->ret) {

... which in the final version will be passed in parametrically within wait.c 
itself (but probably not passed in from the macro space, to lower the call site 
overhead), that is why I preserved the __wait_is_interruptible() check to begin 
with.

(This bug could perhaps explain the boot hang Peter saw.)

I also removed the bool state variables Peter disliked and added (a tiny ...) 
bit 
more documentation, the latest version is attached below.

Still not signed off, due to the _v1/_v2 devel hack - and it's of course still 
very incomplete, as only wait_event() is converted.

But this should be a reviewable demo of the new wait-event state machine logic.

I'd hesitate to put much more work into this without first having consensus 
over 
whether this is a good idea to begin with.

Thanks,

Ingo

==>
>From 2a918b9bb21e1e1daf047797f598cadb75bba241 Mon Sep 17 00:00:00 2001
From: Ingo Molnar 
Date: Sun, 5 Mar 2017 14:28:09 +0100
Subject: [PATCH] sched/wait: Introduce new, more compact wait_event*() 
primitives

Turn the wait_event() interface into a state machine.

Only very lightly tested, but should demonstrate the principle.

Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-kernel@vger.kernel.org
Not-Signed-off-by: Ingo Molnar 
---
 include/linux/wait.h | 34 ++-
 kernel/sched/wait.c  | 57 
 2 files changed, 90 insertions(+), 1 deletion(-)

diff --git a/include/linux/wait.h b/include/linux/wait.h
index bdcca46ae54a..b1291cdb9b53 100644
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -226,6 +226,36 @@ void __wake_up_sync(struct wait_queue_head *wq_head, 
unsigned int mode, int nr);
 extern void init_wait_entry(struct wait_queue_entry *wq_entry, int flags);
 
 /*
+ * The current state that the wait_event() loop operates
+ * over. This minimally initialized by the macro and then
+ * iterated inside the wait_event_loop() iterator:
+ */
+struct wait_event_state {
+   charqueued;
+   charprepared;
+   chardone;
+
+   longret;
+   struct wait_queue_entry wq_entry;
+};
+
+extern long wait_event_loop(struct wait_queue_head *wq_head, struct 
wait_event_state *wes, int condition);
+
+#define wait_event_v2(wq_head, condition)  
\
+({ 
\
+   struct wait_event_state __wes;  
\
+   long __ret; 
\
+   
\
+   __wes.queued = 0;   
\
+   
\
+   do {
\
+   __ret = wait_event_loop(&(wq_head), &__wes, (condition) != 0);  
\
+   } while (!__wes.done);  
\
+   
\
+   __ret;  
\
+})
+
+/*
  * The below macro ___wait_event() has an explicit shadow of the __ret
  * variable when used from the wait_event_*() macros.
  *
@@ -277,7 +307,7 @@ __out:  __ret;  
\
  * wake_up() has to be called after changing any variable that could
  * change the result of the wait condition.
  */
-#define wait_event(wq_head, condition) 
\
+#define wait_event_v1(wq_head, condition)  
\
 do {   
\
might_sleep();  
\
if (condition)  
\
@@ -285,6 +315,8 @@ do {
\
__wait_event(wq_head, condition);   
\
 } while (0)
 
+#define wait_event wait_event_v2
+
 #define __io_wait_event(wq_head, condition)
\
(void)___wait_event(wq_head, condition, TASK_UNINTERRUPTIBLE, 0, 0, 
\
io_schedule())
diff --git a/kernel/sched/wait.c b/kernel/sched/wait.c

Re: [PATCH v3 01/09] iommu/ipmmu-vmsa: Introduce features, break out alias

[Robin Murphy]

Hi Magnus,

On 08/03/17 11:01, Magnus Damm wrote:
> From: Magnus Damm 
> 
> Introduce struct ipmmu_features to track various hardware
> and software implementation changes inside the driver for
> different kinds of IPMMU hardware. Add use_ns_alias_offset
> as a first example of a feature to control if the secure
> register bank offset should be used or not.
> 
> Signed-off-by: Magnus Damm 
> ---
> 
>  Changes since V2:
>  - None
> 
>  Changes since V1:
>  - Moved patch to front of the series
> 
>  drivers/iommu/ipmmu-vmsa.c |   35 ---
>  1 file changed, 28 insertions(+), 7 deletions(-)
> 
> --- 0007/drivers/iommu/ipmmu-vmsa.c
> +++ work/drivers/iommu/ipmmu-vmsa.c   2017-03-07 12:25:47.0 +0900
> @@ -32,11 +32,15 @@
>  
>  #define IPMMU_CTX_MAX 1
>  
> +struct ipmmu_features {
> + bool use_ns_alias_offset;
> +};
> +
>  struct ipmmu_vmsa_device {
>   struct device *dev;
>   void __iomem *base;
>   struct list_head list;
> -
> + const struct ipmmu_features *features;
>   unsigned int num_utlbs;
>   spinlock_t lock;/* Protects ctx and domains[] */
>   DECLARE_BITMAP(ctx, IPMMU_CTX_MAX);
> @@ -999,13 +1003,33 @@ static void ipmmu_device_reset(struct ip
>   ipmmu_write(mmu, i * IM_CTX_SIZE + IMCTR, 0);
>  }
>  
> +static const struct ipmmu_features ipmmu_features_default = {
> + .use_ns_alias_offset = true,
> +};
> +
> +static const struct of_device_id ipmmu_of_ids[] = {
> + {
> + .compatible = "renesas,ipmmu-vmsa",
> + .data = _features_default,
> + }, {
> + /* Terminator */
> + },
> +};
> +
> +MODULE_DEVICE_TABLE(of, ipmmu_of_ids);
> +
>  static int ipmmu_probe(struct platform_device *pdev)
>  {
>   struct ipmmu_vmsa_device *mmu;
> + const struct of_device_id *match;
>   struct resource *res;
>   int irq;
>   int ret;
>  
> + match = of_match_node(ipmmu_of_ids, pdev->dev.of_node);

of_device_get_match_data() makes this a lot easier.

> + if (!match)
> + return -EINVAL;

Also, if the driver is DT-only per the other series, note that this
cannot happen anyway, since of_driver_match_device() would have to have
found a match for your probe function to be called in the first place.

Robin.

> +
>   mmu = devm_kzalloc(>dev, sizeof(*mmu), GFP_KERNEL);
>   if (!mmu) {
>   dev_err(>dev, "cannot allocate device data\n");
> @@ -1016,6 +1040,7 @@ static int ipmmu_probe(struct platform_d
>   mmu->num_utlbs = 32;
>   spin_lock_init(>lock);
>   bitmap_zero(mmu->ctx, IPMMU_CTX_MAX);
> + mmu->features = match->data;
>  
>   /* Map I/O memory and request IRQ. */
>   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> @@ -1035,7 +1060,8 @@ static int ipmmu_probe(struct platform_d
>* Offset the registers base unconditionally to point to the non-secure
>* alias space for now.
>*/
> - mmu->base += IM_NS_ALIAS_OFFSET;
> + if (mmu->features->use_ns_alias_offset)
> + mmu->base += IM_NS_ALIAS_OFFSET;
>  
>   irq = platform_get_irq(pdev, 0);
>   if (irq < 0) {
> @@ -1084,11 +1110,6 @@ static int ipmmu_remove(struct platform_
>   return 0;
>  }
>  
> -static const struct of_device_id ipmmu_of_ids[] = {
> - { .compatible = "renesas,ipmmu-vmsa", },
> - { }
> -};
> -
>  static struct platform_driver ipmmu_driver = {
>   .driver = {
>   .name = "ipmmu-vmsa",
> 

Re: [PATCH] livepatch: make klp_mutex proper part of API

[Miroslav Benes]

On Wed, 8 Mar 2017, Jiri Kosina wrote:

> From: Jiri Kosina 
> 
> klp_mutex is shared between core.c and transition.c, and as such would 
> rather be properly located in livepatch.h so that we don't have to play 
> 'extern' games from .c sources.
> 
> This also silences sparse warning (wrongly) suggesting that klp_mutex 
> should be defined static.
> 
> Signed-off-by: Jiri Kosina 
> ---
>  include/linux/livepatch.h | 2 ++
>  kernel/livepatch/transition.c | 2 --
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/include/linux/livepatch.h b/include/linux/livepatch.h
> index 194991ef9347..4efa89f95dd7 100644
> --- a/include/linux/livepatch.h
> +++ b/include/linux/livepatch.h
> @@ -138,6 +138,8 @@ struct klp_patch {
>func->old_name || func->new_func || func->old_sympos; \
>func++)
>  
> +extern struct mutex klp_mutex;
> +
>  int klp_register_patch(struct klp_patch *);
>  int klp_unregister_patch(struct klp_patch *);
>  int klp_enable_patch(struct klp_patch *);
> diff --git a/kernel/livepatch/transition.c b/kernel/livepatch/transition.c
> index 0ab7abd53b0b..14f7ce64b002 100644
> --- a/kernel/livepatch/transition.c
> +++ b/kernel/livepatch/transition.c
> @@ -28,8 +28,6 @@
>  #define MAX_STACK_ENTRIES  100
>  #define STACK_ERR_BUF_SIZE 128
>  
> -extern struct mutex klp_mutex;
> -

A nit, but could you also include "linux/livepatch.h" in transition.c to 
make the dependency explicit (and not through patch.h or transition.h)?

Anyway, not a big deal and you can add my

Acked-by: Miroslav Benes 

Miroslav

[PATCH v2 1/2] net: sched: make default fifo qdiscs appear in the dump

[Jiri Kosina]

From: Jiri Kosina 

The original reason [1] for having hidden qdiscs (potential scalability
issues in qdisc_match_from_root() with single linked list in case of large
amount of qdiscs) has been invalidated by 59cc1f61f0 ("net: sched: convert
qdisc linked list to hashtable").

This allows us for bringing more clarity and determinism into the dump by
making default pfifo qdiscs visible.

We're not turning this on by default though, at it was deemed [2] too
intrusive / unnecessary change of default behavior towards userspace.
Instead, TCA_DUMP_INVISIBLE netlink attribute is introduced, which allows
applications to request complete qdisc hierarchy dump, including the
ones that have always been implicit/invisible.

Singleton noop_qdisc stays invisible, as teaching the whole infrastructure
about singletons would require quite some surgery with very little gain
(seeing no qdisc or seeing noop qdisc in the dump is probably setting
the same user expectation).

[1] 
http://lkml.kernel.org/r/1460732328.10638.74.ca...@edumazet-glaptop3.roam.corp.google.com
[2] 
http://lkml.kernel.org/r/20161021.105935.1907696543877061916.da...@davemloft.net

Signed-off-by: Jiri Kosina 
---

v1 -> v2: introduce exception for singleton noop_qdisc

 include/net/pkt_sched.h|  2 +-
 include/net/sch_generic.h  |  1 +
 include/uapi/linux/rtnetlink.h |  1 +
 net/sched/sch_api.c| 42 ++
 net/sched/sch_cbq.c|  5 +
 net/sched/sch_drr.c|  2 ++
 net/sched/sch_dsmark.c |  2 ++
 net/sched/sch_generic.c|  2 +-
 net/sched/sch_hfsc.c   |  4 
 net/sched/sch_htb.c|  2 ++
 net/sched/sch_mq.c |  2 +-
 net/sched/sch_mqprio.c |  2 +-
 net/sched/sch_multiq.c |  2 ++
 net/sched/sch_prio.c   |  5 -
 net/sched/sch_qfq.c|  2 ++
 net/sched/sch_red.c|  2 ++
 net/sched/sch_sfb.c|  2 ++
 net/sched/sch_tbf.c|  2 ++
 18 files changed, 65 insertions(+), 17 deletions(-)

diff --git a/include/net/pkt_sched.h b/include/net/pkt_sched.h
index cd334c9584e9..0625eac2c601 100644
--- a/include/net/pkt_sched.h
+++ b/include/net/pkt_sched.h
@@ -90,7 +90,7 @@ int unregister_qdisc(struct Qdisc_ops *qops);
 void qdisc_get_default(char *id, size_t len);
 int qdisc_set_default(const char *id);
 
-void qdisc_hash_add(struct Qdisc *q);
+void qdisc_hash_add(struct Qdisc *q, bool invisible);
 void qdisc_hash_del(struct Qdisc *q);
 struct Qdisc *qdisc_lookup(struct net_device *dev, u32 handle);
 struct Qdisc *qdisc_lookup_class(struct net_device *dev, u32 handle);
diff --git a/include/net/sch_generic.h b/include/net/sch_generic.h
index e6aa0a249672..e7dca250d115 100644
--- a/include/net/sch_generic.h
+++ b/include/net/sch_generic.h
@@ -66,6 +66,7 @@ struct Qdisc {
 #define TCQ_F_NOPARENT 0x40 /* root of its hierarchy :
  * qdisc_tree_decrease_qlen() should stop.
  */
+#define TCQ_F_INVISIBLE0x80 /* invisible by default in dump */
u32 limit;
const struct Qdisc_ops  *ops;
struct qdisc_size_table __rcu *stab;
diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
index 262f0379d83a..c7de00e09797 100644
--- a/include/uapi/linux/rtnetlink.h
+++ b/include/uapi/linux/rtnetlink.h
@@ -542,6 +542,7 @@ enum {
TCA_FCNT,
TCA_STATS2,
TCA_STAB,
+   TCA_DUMP_INVISIBLE,
TCA_PAD,
__TCA_MAX
 };
diff --git a/net/sched/sch_api.c b/net/sched/sch_api.c
index 206dc24add3a..8e4e6ab1847a 100644
--- a/net/sched/sch_api.c
+++ b/net/sched/sch_api.c
@@ -274,7 +274,7 @@ static struct Qdisc *qdisc_match_from_root(struct Qdisc 
*root, u32 handle)
return NULL;
 }
 
-void qdisc_hash_add(struct Qdisc *q)
+void qdisc_hash_add(struct Qdisc *q, bool invisible)
 {
if ((q->parent != TC_H_ROOT) && !(q->flags & TCQ_F_INGRESS)) {
struct Qdisc *root = qdisc_dev(q)->qdisc;
@@ -282,6 +282,8 @@ void qdisc_hash_add(struct Qdisc *q)
WARN_ON_ONCE(root == _qdisc);
ASSERT_RTNL();
hash_add_rcu(qdisc_dev(q)->qdisc_hash, >hash, q->handle);
+   if (invisible)
+   q->flags |= TCQ_F_INVISIBLE;
}
 }
 EXPORT_SYMBOL(qdisc_hash_add);
@@ -1004,7 +1006,7 @@ static struct Qdisc *qdisc_create(struct net_device *dev,
goto err_out4;
}
 
-   qdisc_hash_add(sch);
+   qdisc_hash_add(sch, false);
 
return sch;
}
@@ -1400,9 +1402,14 @@ static int tc_fill_qdisc(struct sk_buff *skb, struct 
Qdisc *q, u32 clid,
return -1;
 }
 
-static bool tc_qdisc_dump_ignore(struct Qdisc *q)
+static bool tc_qdisc_dump_ignore(struct Qdisc *q, bool dump_invisible)
 {
-   return (q->flags & TCQ_F_BUILTIN) ? 

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

[Noralf Trønnes]

Den 07.03.2017 23.21, skrev Daniel Vetter:

On Sat, Feb 11, 2017 at 07:48:52PM +0100, Noralf Trønnes wrote:

+const struct file_operations tinydrm_fops = {
+   .owner  = THIS_MODULE,
+   .open   = drm_open,
+   .release= drm_release,
+   .unlocked_ioctl = drm_ioctl,
+#ifdef CONFIG_COMPAT
+   .compat_ioctl   = drm_compat_ioctl,
+#endif
+   .poll   = drm_poll,
+   .read   = drm_read,
+   .llseek = no_llseek,
+   .mmap   = drm_gem_cma_mmap,
+};
+EXPORT_SYMBOL(tinydrm_fops);

Just spotted this while doing a drive-by refactoring, this doesn't really
work. The THIS_MODULE must be in the source code for your driver, and
can't be in some helper library module like tinydrm.ko.


Yeah, you're right.


I'm working on a macro to make this easier, and I guess you could try to
integrate that into your driver macro somehow (probably simplest to
generate the entire structure and just pass name+desc to that macro,
everything else is boilerplate anyway).

I'll cc you on that patch.


Thanks.

Noralf.

[PATCH v2 2/2] iproute2: add support for invisible qdisc dumping

[Jiri Kosina]

From: Jiri Kosina 

Support the new TCA_DUMP_INVISIBLE netlink attribute that allows asking 
kernel to perform 'full qdisc dump', as for historical reasons some of the 
default qdiscs are being hidden by the kernel.

The command syntax is being extended by voluntary 'invisible' argument to
'tc qdisc show'.

Signed-off-by: Jiri Kosina 
---

v1 -> v2: fix the format of help message

 tc/tc_qdisc.c | 25 +++--
 1 file changed, 23 insertions(+), 2 deletions(-)

diff --git a/tc/tc_qdisc.c b/tc/tc_qdisc.c
index 3a3701c2..1e9d9097 100644
--- a/tc/tc_qdisc.c
+++ b/tc/tc_qdisc.c
@@ -34,7 +34,7 @@ static int usage(void)
fprintf(stderr, "   [ stab [ help | STAB_OPTIONS] ]\n");
fprintf(stderr, "   [ [ QDISC_KIND ] [ help | OPTIONS ] ]\n");
fprintf(stderr, "\n");
-   fprintf(stderr, "   tc qdisc show [ dev STRING ] [ ingress | clsact 
]\n");
+   fprintf(stderr, "   tc qdisc show [ dev STRING ] [ ingress | clsact 
] [ invisible ]\n");
fprintf(stderr, "Where:\n");
fprintf(stderr, "QDISC_KIND := { [p|b]fifo | tbf | prio | cbq | red | 
etc. }\n");
fprintf(stderr, "OPTIONS := ... try tc qdisc add  
help\n");
@@ -292,6 +292,7 @@ static int tc_qdisc_list(int argc, char **argv)
 {
struct tcmsg t = { .tcm_family = AF_UNSPEC };
char d[16] = {};
+   bool dump_invisible = false;
 
while (argc > 0) {
if (strcmp(*argv, "dev") == 0) {
@@ -306,6 +307,8 @@ static int tc_qdisc_list(int argc, char **argv)
t.tcm_parent = TC_H_INGRESS;
} else if (matches(*argv, "help") == 0) {
usage();
+   } else if (strcmp(*argv, "invisible") == 0) {
+   dump_invisible = true;
} else {
fprintf(stderr, "What is \"%s\"? Try \"tc qdisc 
help\".\n", *argv);
return -1;
@@ -325,7 +328,25 @@ static int tc_qdisc_list(int argc, char **argv)
filter_ifindex = t.tcm_ifindex;
}
 
-   if (rtnl_dump_request(, RTM_GETQDISC, , sizeof(t)) < 0) {
+   if (dump_invisible) {
+   struct {
+   struct nlmsghdr n;
+   struct tcmsg t;
+   char buf[256];
+   } req = {
+   .n.nlmsg_type = RTM_GETQDISC,
+   .n.nlmsg_len = NLMSG_LENGTH(sizeof(struct tcmsg)),
+   };
+
+   req.t.tcm_family = AF_UNSPEC;
+
+   addattr(, 256, TCA_DUMP_INVISIBLE);
+   if (rtnl_dump_request_n(, ) < 0) {
+   perror("Cannot send dump request");
+   return 1;
+   }
+
+   } else if (rtnl_dump_request(, RTM_GETQDISC, , sizeof(t)) < 0) {
perror("Cannot send dump request");
return 1;
}
-- 
Jiri Kosina
SUSE Labs

Re: [Xen-devel] [PATCH 4/7] xen/9pfs: connect to the backend

[Julien Grall]

Hi Stefano,

On 08/03/17 00:49, Stefano Stabellini wrote:

On Tue, 7 Mar 2017, Julien Grall wrote:

On 03/06/2017 08:01 PM, Stefano Stabellini wrote:

+   if (ring->bytes == NULL)
+   goto error;
+   for (i = 0; i < (1 << XEN_9PFS_RING_ORDER); i++)
+   ring->intf->ref[i] =
gnttab_grant_foreign_access(dev->otherend_id,
pfn_to_gfn(virt_to_pfn((void*)ring->bytes) + i), 0);.


Please use virt_to_gfn rather than pfn_to_gfn(virt_to_pfn).


OK



Also, this is not going to work on 64K kernel because you will grant access to
noncontiguous memory (e.g 0-4K, 64K-68K,...).


By using virt_to_gfn like you suggested, the loop will correctly iterate
on a 4K by 4K basis, even on a 64K kernel:

  ring->bytes = (void*)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
  XEN_9PFS_RING_ORDER - (PAGE_SHIFT - XEN_PAGE_SHIFT));
  for (i = 0; i < (1 << XEN_9PFS_RING_ORDER); i++)
  ring->intf->ref[i] = gnttab_grant_foreign_access(dev->otherend_id, 
virt_to_gfn((void*)ring->bytes) + i, 0);


BTW, the cast (void *) is not necessary.



where XEN_9PFS_RING_ORDER specifies the order at 4K granularity. Am I
missing something?


I think it is fine. You could move virt_to_gfn(...) outside and avoid to 
do the translation everytime.


Cheers,

--
Julien Grall

[PATCH] phy: phy-exynos-pcie: fix the wrong error return

[Jaehoon Chung]

When it doesn't get the blk_base's resource, it was returned
the error about phy_base, not blk_base.
This patch is for fixing the wrong error return about blk_base.

Fixes: cf0adb8e281b ("phy: phy-exynos-pcie: Add support for Exynos PCIe PHY")

Signed-off-by: Jaehoon Chung 
---
 drivers/phy/phy-exynos-pcie.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/phy/phy-exynos-pcie.c b/drivers/phy/phy-exynos-pcie.c
index 4f60b83..60baf25 100644
--- a/drivers/phy/phy-exynos-pcie.c
+++ b/drivers/phy/phy-exynos-pcie.c
@@ -254,8 +254,8 @@ static int exynos_pcie_phy_probe(struct platform_device 
*pdev)
 
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
exynos_phy->blk_base = devm_ioremap_resource(dev, res);
-   if (IS_ERR(exynos_phy->phy_base))
-   return PTR_ERR(exynos_phy->phy_base);
+   if (IS_ERR(exynos_phy->blk_base))
+   return PTR_ERR(exynos_phy->blk_base);
 
exynos_phy->drv_data = drv_data;
 
-- 
2.10.2

Re: [PATCH] MAINTAINERS: Remove self from Tegra maintainers

[Thierry Reding]

On Mon, Mar 06, 2017 at 03:11:34PM +0900, Alexandre Courbot wrote:
> I have not been doing any Tegra maintainance work for a while, and this
> is unlikely to change in the foreseeable future. Better reflect the
> actual state of things by removing myself from the list.
> 
> Signed-off-by: Alexandre Courbot 
> ---
>  MAINTAINERS | 1 -
>  1 file changed, 1 deletion(-)

Applied to for-4.12/misc, thanks.

Thierry


signature.asc
Description: PGP signature

[PATCH 02/26] IB/ocrdma: Use kcalloc() in ocrdma_mbx_alloc_pd_range()

[SF Markus Elfring]

From: Markus Elfring 
Date: Tue, 7 Mar 2017 18:23:54 +0100

* Multiplications for the size determination of memory allocations
  indicated that array data structures should be processed.
  Thus reuse the corresponding function "kcalloc".

  This issue was detected by using the Coccinelle software.

* Delete the local variable "pd_bitmap_size" which became unnecessary with
  this refactoring.

Signed-off-by: Markus Elfring 
---
 drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c 
b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
index cbac41b15d94..d5a3127b6df8 100644
--- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
+++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
@@ -1505,7 +1505,6 @@ int ocrdma_mbx_dealloc_pd(struct ocrdma_dev *dev, struct 
ocrdma_pd *pd)
 static int ocrdma_mbx_alloc_pd_range(struct ocrdma_dev *dev)
 {
int status = -ENOMEM;
-   size_t pd_bitmap_size;
struct ocrdma_alloc_pd_range *cmd;
struct ocrdma_alloc_pd_range_rsp *rsp;
 
@@ -1527,10 +1526,10 @@ static int ocrdma_mbx_alloc_pd_range(struct ocrdma_dev 
*dev)
dev->pd_mgr->pd_dpp_start = rsp->dpp_page_pdid &
OCRDMA_ALLOC_PD_RNG_RSP_START_PDID_MASK;
dev->pd_mgr->max_dpp_pd = rsp->pd_count;
-   pd_bitmap_size =
-   BITS_TO_LONGS(rsp->pd_count) * sizeof(long);
-   dev->pd_mgr->pd_dpp_bitmap = kzalloc(pd_bitmap_size,
-GFP_KERNEL);
+   dev->pd_mgr->pd_dpp_bitmap
+   = kcalloc(BITS_TO_LONGS(rsp->pd_count),
+   sizeof(long),
+   GFP_KERNEL);
}
kfree(cmd);
}
@@ -1546,9 +1545,10 @@ static int ocrdma_mbx_alloc_pd_range(struct ocrdma_dev 
*dev)
dev->pd_mgr->pd_norm_start = rsp->dpp_page_pdid &
OCRDMA_ALLOC_PD_RNG_RSP_START_PDID_MASK;
dev->pd_mgr->max_normal_pd = rsp->pd_count;
-   pd_bitmap_size = BITS_TO_LONGS(rsp->pd_count) * sizeof(long);
-   dev->pd_mgr->pd_norm_bitmap = kzalloc(pd_bitmap_size,
- GFP_KERNEL);
+   dev->pd_mgr->pd_norm_bitmap
+   = kcalloc(BITS_TO_LONGS(rsp->pd_count),
+   sizeof(long),
+   GFP_KERNEL);
}
kfree(cmd);
 
-- 
2.12.0

Re: [PATCH V3 0/4] megachips-stdpxxxx-ge-b850v3-fw

[Lucas Stach]

Am Mittwoch, den 08.03.2017, 10:42 +0100 schrieb Peter Senna Tschudin:
> On Mon, Mar 06, 2017 at 03:27:16PM +0530, Archit Taneja wrote:
> Hi Archit,
> 
> > Hi,
> > 
> > On 3/3/2017 9:27 PM, Peter Senna Tschudin wrote:
> > > The video processing pipeline on the second output on the GE B850v3:
> > > 
> > >   Host -> LVDS|--(STDP4028)--|DP -> DP|--(STDP2690)--|DP++ -> Video output
> > > 
> > > Each bridge has a dedicated flash containing firmware for supporting the
> > > custom design. The result is that in this design neither the STDP4028
> > > nor the STDP2690 behave as the stock bridges would. The compatible
> > > strings include the suffix "-ge-b850v3-fw" to make it clear that the
> > > driver is for the bridges with the firmware which is specific for the GE
> > > B850v3.
> > > 
> > > The driver is powerless to control the video processing pipeline, as the
> > > two bridges behaves as a single one. The driver is only needed for
> > > telling the host about EDID / HPD, and for giving the host powers to ack
> > > interrupts.
> > 
> > queued Patches 1,2 and 3 to drm-misc-next. Made stdp2690_get_edid static
> > in Patch #3 to fix a sparse warning.
> 
> What about 4/4, aka the dt change? Do I need an ack from Rob Herring?
> 
> Thanks a lot!

This one needs to go through Shawn Guo. Now that the driver and binding
are in it is probably best to ask him directly to pick it up.

Regards,
Lucas

[PATCH v3 03/09] iommu/ipmmu-vmsa: Enable multi context support

[Magnus Damm]

From: Magnus Damm 

Add support for up to 8 contexts. Each context is mapped to one
domain. One domain is assigned one or more slave devices. Contexts
are allocated dynamically and slave devices are grouped together
based on which IPMMU device they are connected to. This makes slave
devices tied to the same IPMMU device share the same IOVA space.

Signed-off-by: Magnus Damm 
---

 Changes since V2:
 - Updated patch description to reflect code included in:
   [PATCH v7 00/07] iommu/ipmmu-vmsa: IPMMU multi-arch update V7

 Changes since V1:
 - Support up to 8 contexts instead of 4
 - Use feature flag and runtime handling
 - Default to single context

 drivers/iommu/ipmmu-vmsa.c |   38 ++
 1 file changed, 30 insertions(+), 8 deletions(-)

--- 0012/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2017-03-08 17:59:19.900607110 +0900
@@ -30,11 +30,12 @@
 
 #include "io-pgtable.h"
 
-#define IPMMU_CTX_MAX 1
+#define IPMMU_CTX_MAX 8
 
 struct ipmmu_features {
bool use_ns_alias_offset;
bool has_cache_leaf_nodes;
+   bool has_eight_ctx;
 };
 
 struct ipmmu_vmsa_device {
@@ -44,6 +45,7 @@ struct ipmmu_vmsa_device {
const struct ipmmu_features *features;
bool is_leaf;
unsigned int num_utlbs;
+   unsigned int num_ctx;
spinlock_t lock;/* Protects ctx and domains[] */
DECLARE_BITMAP(ctx, IPMMU_CTX_MAX);
struct ipmmu_vmsa_domain *domains[IPMMU_CTX_MAX];
@@ -376,11 +378,12 @@ static int ipmmu_domain_allocate_context
 
spin_lock_irqsave(>lock, flags);
 
-   ret = find_first_zero_bit(mmu->ctx, IPMMU_CTX_MAX);
-   if (ret != IPMMU_CTX_MAX) {
+   ret = find_first_zero_bit(mmu->ctx, mmu->num_ctx);
+   if (ret != mmu->num_ctx) {
mmu->domains[ret] = domain;
set_bit(ret, mmu->ctx);
-   }
+   } else
+   ret = -EBUSY;
 
spin_unlock_irqrestore(>lock, flags);
 
@@ -425,9 +428,9 @@ static int ipmmu_domain_init_context(str
 * Find an unused context.
 */
ret = ipmmu_domain_allocate_context(domain->root, domain);
-   if (ret == IPMMU_CTX_MAX) {
+   if (ret < 0) {
free_io_pgtable_ops(domain->iop);
-   return -EBUSY;
+   return ret;
}
 
domain->context_id = ret;
@@ -562,7 +565,7 @@ static irqreturn_t ipmmu_irq(int irq, vo
/*
 * Check interrupts for all active contexts.
 */
-   for (i = 0; i < IPMMU_CTX_MAX; i++) {
+   for (i = 0; i < mmu->num_ctx; i++) {
if (!mmu->domains[i])
continue;
if (ipmmu_domain_irq(mmu->domains[i]) == IRQ_HANDLED)
@@ -632,6 +635,13 @@ static int ipmmu_attach_device(struct io
domain->mmu = mmu;
domain->root = root;
ret = ipmmu_domain_init_context(domain);
+   if (ret < 0) {
+   dev_err(dev, "Unable to initialize IPMMU context\n");
+   domain->mmu = NULL;
+   } else {
+   dev_info(dev, "Using IPMMU context %u\n",
+domain->context_id);
+   }
} else if (domain->mmu != mmu) {
/*
 * Something is wrong, we can't attach two devices using
@@ -1047,13 +1057,14 @@ static void ipmmu_device_reset(struct ip
unsigned int i;
 
/* Disable all contexts. */
-   for (i = 0; i < 4; ++i)
+   for (i = 0; i < mmu->num_ctx; ++i)
ipmmu_write(mmu, i * IM_CTX_SIZE + IMCTR, 0);
 }
 
 static const struct ipmmu_features ipmmu_features_default = {
.use_ns_alias_offset = true,
.has_cache_leaf_nodes = false,
+   .has_eight_ctx = false,
 };
 
 static const struct of_device_id ipmmu_of_ids[] = {
@@ -1112,6 +1123,17 @@ static int ipmmu_probe(struct platform_d
if (mmu->features->use_ns_alias_offset)
mmu->base += IM_NS_ALIAS_OFFSET;
 
+   /*
+* The number of contexts varies with generation and instance.
+* Newer SoCs get a total of 8 contexts enabled, older ones just one.
+*/
+   if (mmu->features->has_eight_ctx)
+   mmu->num_ctx = 8;
+   else
+   mmu->num_ctx = 1;
+
+   WARN_ON(mmu->num_ctx > IPMMU_CTX_MAX);
+
irq = platform_get_irq(pdev, 0);
 
/*

[PATCH v3 09/09] iommu/ipmmu-vmsa: Hook up r8a7795 DT matching code

[Magnus Damm]

From: Magnus Damm 

Tie in r8a7795 features and update the IOMMU_OF_DECLARE
compat string to include the updated compat string.

TODO:
 - Consider making use of iommu_fwspec_add_ids() for uTLB handling
 Needed to coexist with non-OF R-Car Gen2 somehow...
 - Break out stuff useful for R-Car Gen2 from this series
 Fix up the Gen2 IPMMU support code
   and/or
 Fold more stuff into the multi-arch series
 - Add support for sysfs and iommu_device_link()/unlink()

Signed-off-by: Magnus Damm 
---

 Changes since V2:
 - Check for lack of root device in ->xlate()
   This fixed a bug when IPMMU-MM is disabled in DT the system hangs on boot
 - Added code to ipmmu_init_platform_device() to handle multiple ->xlate() calls
 - Include empty white list by default
 - Updated TODO list

 Changes since V1:
 - Enable multi context feature
 - Update TODO list

 drivers/iommu/ipmmu-vmsa.c |   41 +
 1 file changed, 41 insertions(+)

--- 0018/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2017-03-08 19:11:53.600607110 +0900
@@ -23,6 +23,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #if defined(CONFIG_ARM) && !defined(CONFIG_IOMMU_DMA)
 #include 
@@ -770,6 +771,10 @@ static int ipmmu_init_platform_device(st
int num_utlbs;
int ret = -ENODEV;
 
+   /* Initialize once - xlate() will call multiple times */
+   if (to_archdata(dev))
+   return 0;
+
/* Find the master corresponding to the device. */
 
num_utlbs = of_count_phandle_with_args(dev->of_node, "iommus",
@@ -1043,6 +1048,17 @@ static struct iommu_group *ipmmu_find_gr
return group;
 }
 
+static bool ipmmu_slave_whitelist(struct device *dev)
+{
+   /* By default, do not allow use of IPMMU */
+   return false;
+}
+
+static const struct soc_device_attribute soc_r8a7795[] = {
+   { .soc_id = "r8a7795", },
+   { /* sentinel */ }
+};
+
 static int ipmmu_of_xlate_dma(struct device *dev,
  struct of_phandle_args *spec)
 {
@@ -1053,6 +1069,18 @@ static int ipmmu_of_xlate_dma(struct dev
if (!of_device_is_available(spec->np))
return -ENODEV;
 
+   /* Failing in ->attach_device() results in a hang, so make
+* sure the root device is installed before going there
+*/
+   if (!__ipmmu_find_root()) {
+   dev_info(dev, "Unable to locate IPMMU root device\n");
+   return -ENODEV;
+   }
+
+   /* For R-Car Gen3 use a white list to opt-in slave devices */
+   if (soc_device_match(soc_r8a7795) && !ipmmu_slave_whitelist(dev))
+   return -ENODEV;
+
return ipmmu_init_platform_device(dev);
 }
 
@@ -1095,11 +1123,22 @@ static const struct ipmmu_features ipmmu
.twobit_imttbcr_sl0 = false,
 };
 
+static const struct ipmmu_features ipmmu_features_r8a7795 = {
+   .use_ns_alias_offset = false,
+   .has_cache_leaf_nodes = true,
+   .has_eight_ctx = true,
+   .setup_imbuscr = false,
+   .twobit_imttbcr_sl0 = true,
+};
+
 static const struct of_device_id ipmmu_of_ids[] = {
{
.compatible = "renesas,ipmmu-vmsa",
.data = _features_default,
}, {
+   .compatible = "renesas,ipmmu-r8a7795",
+   .data = _features_r8a7795,
+   }, {
/* Terminator */
},
 };
@@ -1288,6 +1327,8 @@ static int __init ipmmu_vmsa_iommu_of_se
 
 IOMMU_OF_DECLARE(ipmmu_vmsa_iommu_of, "renesas,ipmmu-vmsa",
 ipmmu_vmsa_iommu_of_setup);
+IOMMU_OF_DECLARE(ipmmu_r8a7795_iommu_of, "renesas,ipmmu-r8a7795",
+ipmmu_vmsa_iommu_of_setup);
 #endif
 
 MODULE_DESCRIPTION("IOMMU API for Renesas VMSA-compatible IPMMU");

[PATCH v3 07/09] iommu/ipmmu-vmsa: Make IMBUSCTR setup optional

[Magnus Damm]

From: Magnus Damm 

Introduce a feature to allow opt-out of setting up
IMBUSCR. The default case is unchanged.

Signed-off-by: Magnus Damm 
---

 Changes since V2:
 - None

 Changes since V1:
 - Updated the commit message
 - Reworked patch to coexist with the multi context feature

 drivers/iommu/ipmmu-vmsa.c |   10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

--- 0020/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2017-03-08 18:32:26.280607110 +0900
@@ -37,6 +37,7 @@ struct ipmmu_features {
bool use_ns_alias_offset;
bool has_cache_leaf_nodes;
bool has_eight_ctx;
+   bool setup_imbuscr;
 };
 
 struct ipmmu_vmsa_device {
@@ -465,10 +466,10 @@ static int ipmmu_domain_init_context(str
ipmmu_ctx_write(domain, IMMAIR0, domain->cfg.arm_lpae_s1_cfg.mair[0]);
 
/* IMBUSCR */
-   ipmmu_ctx_write(domain, IMBUSCR,
-   ipmmu_ctx_read(domain, IMBUSCR) &
-   ~(IMBUSCR_DVM | IMBUSCR_BUSSEL_MASK));
-
+   if (domain->root->features->setup_imbuscr)
+   ipmmu_ctx_write(domain, IMBUSCR,
+   ipmmu_ctx_read(domain, IMBUSCR) &
+   ~(IMBUSCR_DVM | IMBUSCR_BUSSEL_MASK));
/*
 * IMSTR
 * Clear all interrupt flags.
@@ -1078,6 +1079,7 @@ static const struct ipmmu_features ipmmu
.use_ns_alias_offset = true,
.has_cache_leaf_nodes = false,
.has_eight_ctx = false,
+   .setup_imbuscr = true,
 };
 
 static const struct of_device_id ipmmu_of_ids[] = {

[PATCH v3 08/09] iommu/ipmmu-vmsa: Allow two bit SL0

[Magnus Damm]

From: Magnus Damm 

Introduce support for two bit SL0 bitfield in IMTTBCR
by using a separate feature flag.

Signed-off-by: Magnus Damm 
---

 Changes since V2:
 - None

 Changes since V1:
 - None

 drivers/iommu/ipmmu-vmsa.c |   15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

--- 0022/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2017-03-08 18:33:07.630607110 +0900
@@ -38,6 +38,7 @@ struct ipmmu_features {
bool has_cache_leaf_nodes;
bool has_eight_ctx;
bool setup_imbuscr;
+   bool twobit_imttbcr_sl0;
 };
 
 struct ipmmu_vmsa_device {
@@ -163,6 +164,10 @@ static void set_archdata(struct device *
 #define IMTTBCR_TSZ0_MASK  (7 << 0)
 #define IMTTBCR_TSZ0_SHIFT O
 
+#define IMTTBCR_SL0_TWOBIT_LVL_3   (0 << 6)
+#define IMTTBCR_SL0_TWOBIT_LVL_2   (1 << 6)
+#define IMTTBCR_SL0_TWOBIT_LVL_1   (2 << 6)
+
 #define IMBUSCR0x000c
 #define IMBUSCR_DVM(1 << 2)
 #define IMBUSCR_BUSSEL_SYS (0 << 0)
@@ -406,6 +411,7 @@ static int ipmmu_domain_allocate_context
 static int ipmmu_domain_init_context(struct ipmmu_vmsa_domain *domain)
 {
u64 ttbr;
+   u32 tmp;
int ret;
 
/*
@@ -458,9 +464,15 @@ static int ipmmu_domain_init_context(str
 * We use long descriptors with inner-shareable WBWA tables and allocate
 * the whole 32-bit VA space to TTBR0.
 */
+
+   if (domain->root->features->twobit_imttbcr_sl0)
+   tmp = IMTTBCR_SL0_TWOBIT_LVL_1;
+   else
+   tmp = IMTTBCR_SL0_LVL_1;
+
ipmmu_ctx_write(domain, IMTTBCR, IMTTBCR_EAE |
IMTTBCR_SH0_INNER_SHAREABLE | IMTTBCR_ORGN0_WB_WA |
-   IMTTBCR_IRGN0_WB_WA | IMTTBCR_SL0_LVL_1);
+   IMTTBCR_IRGN0_WB_WA | tmp);
 
/* MAIR0 */
ipmmu_ctx_write(domain, IMMAIR0, domain->cfg.arm_lpae_s1_cfg.mair[0]);
@@ -1080,6 +1092,7 @@ static const struct ipmmu_features ipmmu
.has_cache_leaf_nodes = false,
.has_eight_ctx = false,
.setup_imbuscr = true,
+   .twobit_imttbcr_sl0 = false,
 };
 
 static const struct of_device_id ipmmu_of_ids[] = {

[PATCH] staging: android: ashmem: lseek failed due to no FMODE_LSEEK.

[zhangshuxiaomi]

From: zhangshuxiao 

vfs_llseek will check whether the file mode has
FMODE_LSEEK, no return failure. But ashmem can be
lseek, so add FMODE_LSEEK to ashmem file.

Signed-off-by: zhangshuxiao 
---
 drivers/staging/android/ashmem.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/staging/android/ashmem.c b/drivers/staging/android/ashmem.c
index 3f11332..e4530ac 100644
--- a/drivers/staging/android/ashmem.c
+++ b/drivers/staging/android/ashmem.c
@@ -392,6 +392,7 @@ static int ashmem_mmap(struct file *file, struct 
vm_area_struct *vma)
ret = PTR_ERR(vmfile);
goto out;
}
+   vmfile->f_mode |= FMODE_LSEEK;
asma->file = vmfile;
}
get_file(asma->file);
-- 
1.9.1

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

[Richard Genoud]

Cc += Al Viro

2017-02-12 16:44 GMT+01:00 Dmitry Romanov :
> On Mon, Dec 19, 2016 at 01:06:00PM +0100, Martin Steigerwald wrote:
>>
>> 1) Sometimes process accounting does not work at all.
>>
>> The acct() system call (to activate process accounting) return value 0,
>> which means that process accounting is activated successfully.
>> However, no process accounting records are written whatsoever. This
>> situation can be reproduced with the program 'acctdemo.c'
>> that you can find as attachment. When this program gives the message
>> "found a process accounting record!", the situation is okay
>> and process accounting works fine to the file '/tmp/mypacct'. When the
>> message 'No process accounting record yet' is repeatedly given,
>> process accounting does not work and will not work at all. It might be
>> that you have to start this program several times before you get
>> this situation (preferably start/finish lots of processes in the mean time).
>> This problem is probably caused by a new mechanism introduced in the
>> kernel code (/linux/kernel/acct.c) that is called 'slow accounting'
>> and has to be solved in the kernel code.
>>
>> I experience this problem on Debian8 with a 4.8 kernel and on CentOS7
>> with a 4.8 kernel.
>
> I reported same problem on bugzilla as:
>
> Bug 180841 - Process accounting sometimes do not append records for terminated
> processes
> https://bugzilla.kernel.org/show_bug.cgi?id=180841
>
> I think I found cause of this problem and can suggest patch which correct this
> problem.
>
> Problem arise in such situation:
>
> Problem arise if between process accounting activation with call acct(...) and
> first termination of process pass not less than one jiffy. (Note,  acct() 
> return
> successfully, with zero.) In such situation records for terminated processes
> do nod append to accounting file, until process accounting is restarted.
>
> I wrote test program test.c for illustration described problem for kernel
> version 3.17-rc1 and later. This program create empty file for accounting,
> call system call acct() with this file, sleep for not less than one jiffy,
> create new process and exit this process. Then, program test size of 
> accounting
> file. If size of file remain zero, it seems problem and program display 
> message
> "Accounting file size = 0, process accounting did not add record to accounting
> file!".
> On my system problem reproduce almost always by this test.c.
>
> --
> test.c
> --
> #include 
> #include 
> #include 
> #include 
> #include 
> #include 
>
> /* Accounting file name : */
> #define ACCTFILENAME "/var/log/pacct"
>
> int main()
> {
> int fd;
> int pid;
> struct stat sb;
>
> /* Turn off accounting */
> if ( acct(NULL) < 0 ) {
> perror("Process accounting off");
> return -1;
> }
>
> /* Create empty accounting file */
> fd = creat(ACCTFILENAME, S_IRUSR | S_IWUSR);
> if ( fd == -1 ) {
> perror("Accounting file creation");
> return -1;
> }
> if ( close(fd) == -1) {
> perror("Accounting file closing");
> return -1;
> }
>
> /* Switch accounting on */
> if ( acct(ACCTFILENAME) < 0 ) {
> perror("Process accounting on");
> return -1;
> }
>
> /* Delay must be at least 1 jiffy.
> For reproducing bug, some process exit must not happen during first 
> jiffy.
> If HZ >= 100, need delay minimum 10 ms. */
> usleep(1);
>
> /* Create and exit child process. The record for this process must be 
> append
> by activated process accounting. */
> pid = fork();
> if (pid < 0) {
> perror("Child process creating");
> return -1;
> }
> /* Exit child process */
> if (pid == 0) {
> exit(0);
> }
> /* Wait for child process termination */
> wait(NULL);
>
> /* Get size of accounting file. */
> if ( stat(ACCTFILENAME, ) == -1 ) {
> perror("Getting accounting file status");
> return -1;
> }
>
> if ( sb.st_size == 0 ) {
> printf("Accounting file size = 0, process accounting did not 
> add record to accounting file!\n");
> }
> else {
> printf("Accounting file size > 0, expected behaviour.\n");
> }
>
> /* Turn off accounting and remove accounting file*/
> if ( acct(NULL) < 0 ) {
> perror("Process accounting off");
> return -1;
> }
> if ( remove(ACCTFILENAME) == -1 ) {
> perror("Removing accounting file");
> return -1;
> }
>
> return 0;
>
> }
> --
>
> I suppose that this problem may be solve in kernel 

Re: [RFC PATCH 3/4] xfs: map KM_MAYFAIL to __GFP_RETRY_MAYFAIL

[Tetsuo Handa]

On 2017/03/08 0:48, Michal Hocko wrote:
> From: Michal Hocko 
> 
> KM_MAYFAIL didn't have any suitable GFP_FOO counterpart until recently
> so it relied on the default page allocator behavior for the given set
> of flags. This means that small allocations actually never failed.
> 
> Now that we have __GFP_RETRY_MAYFAIL flag which works independently on the
> allocation request size we can map KM_MAYFAIL to it. The allocator will
> try as hard as it can to fulfill the request but fails eventually if
> the progress cannot be made.
> 
> Cc: Darrick J. Wong 
> Signed-off-by: Michal Hocko 
> ---
>  fs/xfs/kmem.h | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/fs/xfs/kmem.h b/fs/xfs/kmem.h
> index ae08cfd9552a..ac80a4855c83 100644
> --- a/fs/xfs/kmem.h
> +++ b/fs/xfs/kmem.h
> @@ -54,6 +54,16 @@ kmem_flags_convert(xfs_km_flags_t flags)
>   lflags &= ~__GFP_FS;
>   }
>  
> + /*
> +  * Default page/slab allocator behavior is to retry for ever
> +  * for small allocations. We can override this behavior by using
> +  * __GFP_RETRY_MAYFAIL which will tell the allocator to retry as long
> +  * as it is feasible but rather fail than retry for ever for all
> +  * request sizes.
> +  */
> + if (flags & KM_MAYFAIL)
> + lflags |= __GFP_RETRY_MAYFAIL;

I don't see advantages of supporting both __GFP_NORETRY and __GFP_RETRY_MAYFAIL.
kmem_flags_convert() can always set __GFP_NORETRY because the callers use
opencoded __GFP_NOFAIL loop (with possible allocation lockup warning) unless
KM_MAYFAIL is set.

> +
>   if (flags & KM_ZERO)
>   lflags |= __GFP_ZERO;
>  
> 

Well, commit 9a67f6488eca926f ("mm: consolidate GFP_NOFAIL checks in the
allocator slowpath") unexpectedly changed to always give up without using
memory reserves (unless __GFP_NOFAIL is set) if TIF_MEMDIE is set to current
thread when current thread is inside __alloc_pages_may_oom() (precisely 
speaking,
if TIF_MEMDIE is set when current thread is after

if (gfp_pfmemalloc_allowed(gfp_mask))
alloc_flags = ALLOC_NO_WATERMARKS;

line and before

/* Avoid allocations with no watermarks from looping endlessly */
if (test_thread_flag(TIF_MEMDIE))
goto nopage;

line, which is likely always true); but this is off-topic for this thread.

The lines which are executed only when __GFP_RETRY_MAYFAIL is set rather than
__GFP_NORETRY is set are

/* Do not loop if specifically requested */
if (gfp_mask & __GFP_NORETRY)
goto nopage;

/*
 * Do not retry costly high order allocations unless they are
 * __GFP_RETRY_MAYFAIL
 */
if (order > PAGE_ALLOC_COSTLY_ORDER && !(gfp_mask & 
__GFP_RETRY_MAYFAIL))
goto nopage;

if (should_reclaim_retry(gfp_mask, order, ac, alloc_flags,
 did_some_progress > 0, _progress_loops))
goto retry;

/*
 * It doesn't make any sense to retry for the compaction if the order-0
 * reclaim is not able to make any progress because the current
 * implementation of the compaction depends on the sufficient amount
 * of free memory (see __compaction_suitable)
 */
if (did_some_progress > 0 &&
should_compact_retry(ac, order, alloc_flags,
compact_result, _priority,
_retries))
goto retry;

/*
 * It's possible we raced with cpuset update so the OOM would be
 * premature (see below the nopage: label for full explanation).
 */
if (read_mems_allowed_retry(cpuset_mems_cookie))
goto retry_cpuset;

/* Reclaim has failed us, start killing things */
page = __alloc_pages_may_oom(gfp_mask, order, ac, _some_progress);
if (page)
goto got_pg;

__alloc_pages_may_oom(gfp_t gfp_mask, unsigned int order,
const struct alloc_context *ac, unsigned long *did_some_progress)
{
struct oom_control oc = {
.zonelist = ac->zonelist,
.nodemask = ac->nodemask,
.memcg = NULL,
.gfp_mask = gfp_mask,
.order = order,
};
struct page *page;

*did_some_progress = 0;

/*
 * Acquire the oom lock.  If that fails, somebody else is
 * making progress for us.
 */
if (!mutex_trylock(_lock)) {
*did_some_progress = 1;
schedule_timeout_uninterruptible(1);
return NULL;
}

/*
 * Go through the zonelist yet one more time, keep very high watermark
 * here, this is only to catch a parallel oom killing, we must fail if
 * we're still under heavy pressure.
 */

[PATCH 3/5] fs, xfs: convert xlog_ticket.t_ref from atomic_t to refcount_t

[Elena Reshetova]

refcount_t type and corresponding API should be
used instead of atomic_t when the variable is used as
a reference counter. This allows to avoid accidental
refcounter overflows that might lead to use-after-free
situations.

Signed-off-by: Elena Reshetova 
Signed-off-by: Hans Liljestrand 
Signed-off-by: Kees Cook 
Signed-off-by: David Windsor 
---
 fs/xfs/xfs_log.c  | 10 +-
 fs/xfs/xfs_log_priv.h |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c
index b1469f0..c127fa0 100644
--- a/fs/xfs/xfs_log.c
+++ b/fs/xfs/xfs_log.c
@@ -3500,8 +3500,8 @@ void
 xfs_log_ticket_put(
xlog_ticket_t   *ticket)
 {
-   ASSERT(atomic_read(>t_ref) > 0);
-   if (atomic_dec_and_test(>t_ref))
+   ASSERT(refcount_read(>t_ref) > 0);
+   if (refcount_dec_and_test(>t_ref))
kmem_zone_free(xfs_log_ticket_zone, ticket);
 }
 
@@ -3509,8 +3509,8 @@ xlog_ticket_t *
 xfs_log_ticket_get(
xlog_ticket_t   *ticket)
 {
-   ASSERT(atomic_read(>t_ref) > 0);
-   atomic_inc(>t_ref);
+   ASSERT(refcount_read(>t_ref) > 0);
+   refcount_inc(>t_ref);
return ticket;
 }
 
@@ -3632,7 +3632,7 @@ xlog_ticket_alloc(
 
unit_res = xfs_log_calc_unit_res(log->l_mp, unit_bytes);
 
-   atomic_set(>t_ref, 1);
+   refcount_set(>t_ref, 1);
tic->t_task = current;
INIT_LIST_HEAD(>t_queue);
tic->t_unit_res = unit_res;
diff --git a/fs/xfs/xfs_log_priv.h b/fs/xfs/xfs_log_priv.h
index c2604a5..3fc4aba 100644
--- a/fs/xfs/xfs_log_priv.h
+++ b/fs/xfs/xfs_log_priv.h
@@ -168,7 +168,7 @@ typedef struct xlog_ticket {
struct list_head   t_queue;  /* reserve/write queue */
struct task_struct *t_task;  /* task that owns this ticket */
xlog_tid_t t_tid;/* transaction identifier   : 4  */
-   atomic_t   t_ref;/* ticket reference count   : 4  */
+   refcount_t t_ref;/* ticket reference count   : 4  */
intt_curr_res;   /* current reservation in bytes : 4  */
intt_unit_res;   /* unit reservation in bytes: 4  */
char   t_ocnt;   /* original count   : 1  */
-- 
2.7.4

[PATCH v3 04/09] iommu/ipmmu-vmsa: Make use of IOMMU_OF_DECLARE()

[Magnus Damm]

From: Magnus Damm 

Hook up IOMMU_OF_DECLARE() support in case CONFIG_IOMMU_DMA
is enabled. The only current supported case for 32-bit ARM
is disabled, however for 64-bit ARM usage of OF is required.

Signed-off-by: Magnus Damm 
---

 Changes since V2:
 - Reworked registration code to make use of recently introduced:
 iommu_device_register()
 iommu_device_set_ops()
 iommu_device_set_fwnode()

 Changes since V1:
 - Reworked slightly to fit updated patch order and
   [PATCH v3 00/06] iommu/ipmmu-vmsa: IPMMU multi-arch update V3

 drivers/iommu/ipmmu-vmsa.c |   39 +++
 1 file changed, 39 insertions(+)

--- 0012/drivers/iommu/ipmmu-vmsa.c
+++ work/drivers/iommu/ipmmu-vmsa.c 2017-03-08 19:08:31.610607110 +0900
@@ -19,6 +19,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -41,6 +42,7 @@ struct ipmmu_features {
 struct ipmmu_vmsa_device {
struct device *dev;
void __iomem *base;
+   struct iommu_device iommu;
struct list_head list;
const struct ipmmu_features *features;
bool is_leaf;
@@ -1161,6 +1163,25 @@ static int ipmmu_probe(struct platform_d
ipmmu_device_reset(mmu);
}
 
+#if defined(CONFIG_IOMMU_DMA)
+   /*
+* Register the IPMMU to the IOMMU subsystem in the following cases:
+* - R-Car Gen2 IPMMU (all devices registered)
+* - R-Car Gen3 IPMMU (leaf devices only - skip root IPMMU-MM device)
+*/
+   if (!mmu->features->has_cache_leaf_nodes || mmu->is_leaf) {
+   ret = iommu_device_register(>iommu);
+   if (ret)
+   return ret;
+
+   iommu_device_set_ops(>iommu, _ops);
+   iommu_device_set_fwnode(>iommu,
+   >dev.of_node->fwnode);
+
+   if (!iommu_present(_bus_type))
+   bus_set_iommu(_bus_type, _ops);
+   }
+#endif
/*
 * We can't create the ARM mapping here as it requires the bus to have
 * an IOMMU, which only happens when bus_set_iommu() is called in
@@ -1204,15 +1225,22 @@ static struct platform_driver ipmmu_driv
 
 static int __init ipmmu_init(void)
 {
+   static bool setup_done;
int ret;
 
+   if (setup_done)
+   return 0;
+
ret = platform_driver_register(_driver);
if (ret < 0)
return ret;
 
+#if defined(CONFIG_ARM) && !defined(CONFIG_IOMMU_DMA)
if (!iommu_present(_bus_type))
bus_set_iommu(_bus_type, _ops);
+#endif
 
+   setup_done = true;
return 0;
 }
 
@@ -1224,6 +1252,17 @@ static void __exit ipmmu_exit(void)
 subsys_initcall(ipmmu_init);
 module_exit(ipmmu_exit);
 
+#ifdef CONFIG_IOMMU_DMA
+static int __init ipmmu_vmsa_iommu_of_setup(struct device_node *np)
+{
+   ipmmu_init();
+   return 0;
+}
+
+IOMMU_OF_DECLARE(ipmmu_vmsa_iommu_of, "renesas,ipmmu-vmsa",
+ipmmu_vmsa_iommu_of_setup);
+#endif
+
 MODULE_DESCRIPTION("IOMMU API for Renesas VMSA-compatible IPMMU");
 MODULE_AUTHOR("Laurent Pinchart ");
 MODULE_LICENSE("GPL v2");

Re: [PATCH v2] f2fs: combine nat_bits and free_nid_bitmap cache

[Chao Yu]

Hi Jaegeuk,

On 2017/3/8 6:27, Jaegeuk Kim wrote:
> Hi Chao,
> 
> There were two reasons for slow down; one is set_bit_le and the other was 
> spin_lock calls.
> 
> I think it would'b good to merge this patch in yours as well.
> Let me know. I'm ready to integrate together and test them.

The change looks good to me. ;)

Anyway I will send last updated patch which you have merged in order to tracking
others' comments if there will be.

Thanks,

> 
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/node.c | 22 +-
>  1 file changed, 13 insertions(+), 9 deletions(-)
> 
> diff --git a/fs/f2fs/node.c b/fs/f2fs/node.c
> index 3377a512e299..0a1ea59c9d31 100644
> --- a/fs/f2fs/node.c
> +++ b/fs/f2fs/node.c
> @@ -1815,7 +1815,7 @@ static void remove_free_nid(struct f2fs_sb_info *sbi, 
> nid_t nid)
>  }
>  
>  void update_free_nid_bitmap(struct f2fs_sb_info *sbi, nid_t nid,
> - bool set, bool build)
> + bool set, bool build, bool locked)
>  {
>   struct f2fs_nm_info *nm_i = NM_I(sbi);
>   unsigned int nat_ofs = NAT_BLOCK_OFFSET(nid);
> @@ -1829,12 +1829,14 @@ void update_free_nid_bitmap(struct f2fs_sb_info *sbi, 
> nid_t nid,
>   else
>   __clear_bit_le(nid_ofs, nm_i->free_nid_bitmap[nat_ofs]);
>  
> - spin_lock(_i->free_nid_lock);
> + if (!locked)
> + spin_lock(_i->free_nid_lock);
>   if (set)
>   nm_i->free_nid_count[nat_ofs]++;
>   else if (!build)
>   nm_i->free_nid_count[nat_ofs]--;
> - spin_unlock(_i->free_nid_lock);
> + if (!locked)
> + spin_unlock(_i->free_nid_lock);
>  }
>  
>  static void scan_nat_page(struct f2fs_sb_info *sbi,
> @@ -1863,7 +1865,7 @@ static void scan_nat_page(struct f2fs_sb_info *sbi,
>   f2fs_bug_on(sbi, blk_addr == NEW_ADDR);
>   if (blk_addr == NULL_ADDR)
>   freed = add_free_nid(sbi, start_nid, true);
> - update_free_nid_bitmap(sbi, start_nid, freed, true);
> + update_free_nid_bitmap(sbi, start_nid, freed, true, false);
>   }
>  }
>  
> @@ -2018,7 +2020,7 @@ bool alloc_nid(struct f2fs_sb_info *sbi, nid_t *nid)
>   __insert_nid_to_list(sbi, i, ALLOC_NID_LIST, false);
>   nm_i->available_nids--;
>  
> - update_free_nid_bitmap(sbi, *nid, false, false);
> + update_free_nid_bitmap(sbi, *nid, false, false, false);
>  
>   spin_unlock(_i->nid_list_lock);
>   return true;
> @@ -2074,7 +2076,7 @@ void alloc_nid_failed(struct f2fs_sb_info *sbi, nid_t 
> nid)
>  
>   nm_i->available_nids++;
>  
> - update_free_nid_bitmap(sbi, nid, true, false);
> + update_free_nid_bitmap(sbi, nid, true, false, false);
>  
>   spin_unlock(_i->nid_list_lock);
>  
> @@ -2404,11 +2406,11 @@ static void __flush_nat_entry_set(struct f2fs_sb_info 
> *sbi,
>   add_free_nid(sbi, nid, false);
>   spin_lock(_I(sbi)->nid_list_lock);
>   NM_I(sbi)->available_nids++;
> - update_free_nid_bitmap(sbi, nid, true, false);
> + update_free_nid_bitmap(sbi, nid, true, false, false);
>   spin_unlock(_I(sbi)->nid_list_lock);
>   } else {
>   spin_lock(_I(sbi)->nid_list_lock);
> - update_free_nid_bitmap(sbi, nid, false, false);
> + update_free_nid_bitmap(sbi, nid, false, false, false);
>   spin_unlock(_I(sbi)->nid_list_lock);
>   }
>   }
> @@ -2533,8 +2535,10 @@ inline void load_free_nid_bitmap(struct f2fs_sb_info 
> *sbi)
>   nid = i * NAT_ENTRY_PER_BLOCK;
>   last_nid = (i + 1) * NAT_ENTRY_PER_BLOCK;
>  
> + spin_lock(_i->free_nid_lock);
>   for (; nid < last_nid; nid++)
> - update_free_nid_bitmap(sbi, nid, true, true);
> + update_free_nid_bitmap(sbi, nid, true, true, true);
> + spin_unlock(_i->free_nid_lock);
>   }
>  
>   for (i = 0; i < nm_i->nat_blocks; i++) {
> 

Re: [PATCH v2 08/22] PCI: dwc: designware: Add EP mode support

[Joao Pinto]

Hi Kishon,

>> Can you provide PCIE_GET_ATU_INB_UNR_REG_OFFSET (similar to
>> PCIE_GET_ATU_OUTB_UNR_REG_OFFSET)?
> 
> Yes of course, I will send you the definition soon.

As promissed here is the definition for Inbound:

+/* register address builder */
+#define PCIE_GET_ATU_INB_UNR_REG_ADDR(region, register)\
+   ((0x3 << 20) | (region << 9) |  \
+   (0x1 << 8) | (register << 2))

Thanks,
Joao

> 
> Thanks,
> Joao
> 
>>
>> Thanks
>> Kishon
>>
> 

[PATCH 1/2] mm: Change generic FALLBACK zonelist creation process

[Anshuman Khandual]

Kernel allocation to CDM node has already been prevented by putting it's
entire memory in ZONE_MOVABLE. But the CDM nodes must also be isolated
from implicit allocations happening on the system.

Any isolation seeking CDM node requires isolation from implicit memory
allocations from user space but at the same time there should also have
an explicit way to do the memory allocation.

Platform node's both zonelists are fundamental to where the memory comes
from when there is an allocation request. In order to achieve these two
objectives as stated above, zonelists building process has to change as
both zonelists (i.e FALLBACK and NOFALLBACK) gives access to the node's
memory zones during any kind of memory allocation. The following changes
are implemented in this regard.

* CDM node's zones are not part of any other node's FALLBACK zonelist
* CDM node's FALLBACK list contains it's own memory zones followed by
  all system RAM zones in regular order as before
* CDM node's zones are part of it's own NOFALLBACK zonelist

These above changes ensure the following which in turn isolates the CDM
nodes as desired.

* There wont be any implicit memory allocation ending up in the CDM node
* Only __GFP_THISNODE marked allocations will come from the CDM node
* CDM node memory can be allocated through mbind(MPOL_BIND) interface
* System RAM memory will be used as fallback option in regular order in
  case the CDM memory is insufficient during targted allocation request

Sample zonelist configuration:

[NODE (0)]  RAM
ZONELIST_FALLBACK (0xc140da00)
(0) (node 0) (DMA 0xc140c000)
(1) (node 1) (DMA 0xc001)
ZONELIST_NOFALLBACK (0xc1411a10)
(0) (node 0) (DMA 0xc140c000)
[NODE (1)]  RAM
ZONELIST_FALLBACK (0xc0011a00)
(0) (node 1) (DMA 0xc001)
(1) (node 0) (DMA 0xc140c000)
ZONELIST_NOFALLBACK (0xc0015a10)
(0) (node 1) (DMA 0xc001)
[NODE (2)]  CDM
ZONELIST_FALLBACK (0xc1427700)
(0) (node 2) (Movable 0xc1427080)
(1) (node 0) (DMA 0xc140c000)
(2) (node 1) (DMA 0xc001)
ZONELIST_NOFALLBACK (0xc142b710)
(0) (node 2) (Movable 0xc1427080)
[NODE (3)]  CDM
ZONELIST_FALLBACK (0xc1431400)
(0) (node 3) (Movable 0xc1430d80)
(1) (node 0) (DMA 0xc140c000)
(2) (node 1) (DMA 0xc001)
ZONELIST_NOFALLBACK (0xc1435410)
(0) (node 3) (Movable 0xc1430d80)
[NODE (4)]  CDM
ZONELIST_FALLBACK (0xc143b100)
(0) (node 4) (Movable 0xc143aa80)
(1) (node 0) (DMA 0xc140c000)
(2) (node 1) (DMA 0xc001)
ZONELIST_NOFALLBACK (0xc143f110)
(0) (node 4) (Movable 0xc143aa80)

Signed-off-by: Anshuman Khandual 
---
 mm/page_alloc.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 40908de..6f7dddc 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4825,6 +4825,16 @@ static void build_zonelists(pg_data_t *pgdat)
i = 0;
 
while ((node = find_next_best_node(local_node, _mask)) >= 0) {
+#ifdef CONFIG_COHERENT_DEVICE
+   /*
+* CDM node's own zones should not be part of any other
+* node's fallback zonelist but only it's own fallback
+* zonelist.
+*/
+   if (is_cdm_node(node) && (pgdat->node_id != node))
+   continue;
+#endif
+
/*
 * We don't want to pressure a particular node.
 * So adding penalty to the first node in same
-- 
2.9.3

Re: [PATCH -mm -v6 2/9] mm, memcg: Support to charge/uncharge multiple swap entries

[Balbir Singh]

On Wed, 2017-03-08 at 15:26 +0800, Huang, Ying wrote:
> From: Huang Ying 
> 
> This patch make it possible to charge or uncharge a set of continuous
> swap entries in the swap cgroup.  The number of swap entries is
> specified via an added parameter.
> 
> This will be used for the THP (Transparent Huge Page) swap support.
> Where a swap cluster backing a THP may be allocated and freed as a
> whole.  So a set of (HPAGE_PMD_NR) continuous swap entries backing one
> THP need to be charged or uncharged together.  This will batch the
> cgroup operations for the THP swap too.

A quick look at the patches makes it look sane. I wonder if we would
make sense to track THP swapout separately as well
(from a memory.stat perspective)

Balbir Singh

[PATCH v1 1/2] x86/platform/intel-mid: Use common power off sequence

[Andy Shevchenko]

Intel Medfield may use common for Intel MID devices power sequence.
Remove unneded custom power off stub.

While here, remove function forward declaration.

Signed-off-by: Andy Shevchenko 
---
 arch/x86/platform/intel-mid/mfld.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/arch/x86/platform/intel-mid/mfld.c 
b/arch/x86/platform/intel-mid/mfld.c
index e793fe509971..e42978d4deaf 100644
--- a/arch/x86/platform/intel-mid/mfld.c
+++ b/arch/x86/platform/intel-mid/mfld.c
@@ -17,16 +17,6 @@
 
 #include "intel_mid_weak_decls.h"
 
-static void penwell_arch_setup(void);
-/* penwell arch ops */
-static struct intel_mid_ops penwell_ops = {
-   .arch_setup = penwell_arch_setup,
-};
-
-static void mfld_power_off(void)
-{
-}
-
 static unsigned long __init mfld_calibrate_tsc(void)
 {
unsigned long fast_calibrate;
@@ -63,9 +53,12 @@ static unsigned long __init mfld_calibrate_tsc(void)
 static void __init penwell_arch_setup(void)
 {
x86_platform.calibrate_tsc = mfld_calibrate_tsc;
-   pm_power_off = mfld_power_off;
 }
 
+static struct intel_mid_ops penwell_ops = {
+   .arch_setup = penwell_arch_setup,
+};
+
 void *get_penwell_ops(void)
 {
return _ops;
-- 
2.11.0

Re: [Xen-devel] [PATCH 1/7] xen: import new ring macros in ring.h

[Julien Grall]

Hi Stefano,

On 08/03/17 00:12, Stefano Stabellini wrote:

On Tue, 7 Mar 2017, Julien Grall wrote:

Hi Stefano,

On 03/06/2017 08:01 PM, Stefano Stabellini wrote:

Sync the ring.h file with upstream Xen, to introduce the new ring macros.
They will be used by the Xen transport for 9pfs.

Signed-off-by: Stefano Stabellini 
CC: konrad.w...@oracle.com
CC: boris.ostrov...@oracle.com
CC: jgr...@suse.com

---
NB: The new macros have not been committed to Xen yet. Do not apply this
patch until they do.
---
---
 include/xen/interface/io/ring.h | 131

 1 file changed, 131 insertions(+)

diff --git a/include/xen/interface/io/ring.h
b/include/xen/interface/io/ring.h
index 21f4fbd..e16aa92 100644
--- a/include/xen/interface/io/ring.h
+++ b/include/xen/interface/io/ring.h


[...]


+#define XEN_FLEX_RING_SIZE(order)
\
+(1UL << (order + PAGE_SHIFT - 1))


This will need to be XEN_PAGE_SHIFT in order to works with 64K kernel.


Good point! I had it right at the beginning but I lost the change in one
of the updates from xen.git.


It is probably worth to consider introducing XEN_PAGE_SIZE in the 
hypervisor code because we are likely to miss the change when the 
headers will be re-sync in the future.


Cheers,

--
Julien Grall

Re: [PATCH] clk: tegra: mark TEGRA210_CLK_DBGAPB as always on

[Geert Uytterhoeven]

Hi Jon,

On Wed, Mar 8, 2017 at 11:13 AM, Jon Hunter  wrote:
>> I had a similar issue with SH-Mobile AG5, where the power domain containing
>> the JTAG interface is powered down.
>
> This reminds me, does your patch assume that the DFD power domain is
> enabled? I am guessing that it needs to be for JTAG to work.

Yes. The pm-rmobile driver looks for "arm,coresight-etm3x" devices, and
marks the corresponding PM Domain as always-on, as long as the
Coresight code doesn't handle runtime PM.

For R-Mobile A1 and APE6 I already have added such device nodes, as any access
to a debug register hangs when the debug power domain is powered down.
For SH-Mobile AG5, I hadn't, as the debug power domain needs to be powered
for JTAG functionality only.

For the latter, perhaps we also need a command line parameter to change
a device status from "disabled" to "enabled"?

Gr{oetje,eeting}s,

Geert

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

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

[PATCH] serial: 8250: 8250_core: Use dev_name() during request_irq()

[Vignesh R]

Passing "serial" as name during request_irq() results in all serial port
irqs have same name. This does not help much to easily identify which
irq belongs to which serial port instance. Therefore pass dev_name()
during request_irq() so that better identifiable name is listed for
serial ports in cat /proc/interrupts output.

Output of cat /proc/interrupts
Before this patch:
 26:689  0 GICv2 309 Edge  serial
After this patch:
 26:696  0 GICv2 309 Edge  2530c00.serial

Signed-off-by: Vignesh R 
---
 drivers/tty/serial/8250/8250_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/8250/8250_core.c 
b/drivers/tty/serial/8250/8250_core.c
index 76e03a7de9cc..f83b69f30987 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -218,7 +218,7 @@ static int serial_link_irq_chain(struct uart_8250_port *up)
spin_unlock_irq(>lock);
irq_flags |= up->port.irqflags;
ret = request_irq(up->port.irq, serial8250_interrupt,
- irq_flags, "serial", i);
+ irq_flags, dev_name(up->port.dev), i);
if (ret < 0)
serial_do_unlink(i, up);
}
-- 
2.11.0

Re: [f2fs-dev] [PATCH 2/2] f2fs: don't overwrite node block by SSR

[Chao Yu]

On 2017/3/7 5:51, Jaegeuk Kim wrote:
> This patch fixes that SSR can overwrite previous warm node block consisting of
> a node chain since the last checkpoint.

Good catch!

Need to consider the impact to other accesser, e.g. is_checkpointed_data,
add_discard_addrs?

Thanks,

> 
> Fixes: 5b6c6be2d878 ("f2fs: use SSR for warm node as well")
> Signed-off-by: Jaegeuk Kim 
> ---
>  fs/f2fs/segment.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/fs/f2fs/segment.c b/fs/f2fs/segment.c
> index 2ae36d04d03e..684b869e1861 100644
> --- a/fs/f2fs/segment.c
> +++ b/fs/f2fs/segment.c
> @@ -1177,6 +1177,12 @@ static void update_sit_entry(struct f2fs_sb_info *sbi, 
> block_t blkaddr, int del)
>   if (f2fs_discard_en(sbi) &&
>   !f2fs_test_and_set_bit(offset, se->discard_map))
>   sbi->discard_blks--;
> +
> + /* don't overwrite by SSR to keep node chain */
> + if (se->type == CURSEG_WARM_NODE) {
> + if (!f2fs_test_and_set_bit(offset, se->ckpt_valid_map))
> + se->ckpt_valid_blocks++;
> + }
>   } else {
>   if (!f2fs_test_and_clear_bit(offset, se->cur_valid_map)) {
>  #ifdef CONFIG_F2FS_CHECK_FS
> 

[PATCH] platform/x86: dell-laptop: Handle return error form dell_get_intensity.

[Arvind Yadav]

Here, dell_get_intensity can return an error. So we can assgine
props.brightness as max_brightness.

This change is done using Coccinelle.

Signed-off-by: Arvind Yadav 
---
 drivers/platform/x86/dell-laptop.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/platform/x86/dell-laptop.c 
b/drivers/platform/x86/dell-laptop.c
index f57dd28..0891de3 100644
--- a/drivers/platform/x86/dell-laptop.c
+++ b/drivers/platform/x86/dell-laptop.c
@@ -2053,6 +2053,9 @@ static int __init dell_init(void)
 
dell_backlight_device->props.brightness =
dell_get_intensity(dell_backlight_device);
+   if (dell_backlight_device->props.brightness < 0) {
+   dell_backlight_device->props.brightness = 
props.max_brightness;
+   }
backlight_update_status(dell_backlight_device);
}
 
-- 
1.9.1

Re: [PATCH v3 06/09] iommu/ipmmu-vmsa: Write IMCTR twice

[Robin Murphy]

On 08/03/17 11:02, Magnus Damm wrote:
> From: Magnus Damm 
> 
> Write IMCTR both in the root device and the leaf node.
> 
> Signed-off-by: Magnus Damm 
> ---
> 
>  Changes since V2:
>  - None
> 
>  Changes since V1:
>  - None
> 
>  drivers/iommu/ipmmu-vmsa.c |   17 ++---
>  1 file changed, 14 insertions(+), 3 deletions(-)
> 
> --- 0018/drivers/iommu/ipmmu-vmsa.c
> +++ work/drivers/iommu/ipmmu-vmsa.c   2017-03-08 18:30:36.870607110 +0900
> @@ -286,6 +286,16 @@ static void ipmmu_ctx_write(struct ipmmu
>   ipmmu_write(domain->root, domain->context_id * IM_CTX_SIZE + reg, data);
>  }
>  
> +static void ipmmu_ctx_write2(struct ipmmu_vmsa_domain *domain, unsigned int 
> reg,
> +  u32 data)

That's pretty cryptic. Maybe both functions could do with less ambiguous
names - something like ipmmu_ctx_write_root() vs. ipmmu_ctx_write_all(),
perhaps? (and if there's a more specific hardware term than "all" that
describes this kind of configuration, even better).

Robin.

> +{
> + if (domain->mmu != domain->root)
> + ipmmu_write(domain->mmu,
> + domain->context_id * IM_CTX_SIZE + reg, data);
> +
> + ipmmu_write(domain->root, domain->context_id * IM_CTX_SIZE + reg, data);
> +}
> +
>  /* 
> -
>   * TLB and microTLB Management
>   */
> @@ -312,7 +322,7 @@ static void ipmmu_tlb_invalidate(struct
>  
>   reg = ipmmu_ctx_read(domain, IMCTR);
>   reg |= IMCTR_FLUSH;
> - ipmmu_ctx_write(domain, IMCTR, reg);
> + ipmmu_ctx_write2(domain, IMCTR, reg);
>  
>   ipmmu_tlb_sync(domain);
>  }
> @@ -472,7 +482,8 @@ static int ipmmu_domain_init_context(str
>* software management as we have no use for it. Flush the TLB as
>* required when modifying the context registers.
>*/
> - ipmmu_ctx_write(domain, IMCTR, IMCTR_INTEN | IMCTR_FLUSH | IMCTR_MMUEN);
> + ipmmu_ctx_write2(domain, IMCTR,
> +  IMCTR_INTEN | IMCTR_FLUSH | IMCTR_MMUEN);
>  
>   return 0;
>  }
> @@ -498,7 +509,7 @@ static void ipmmu_domain_destroy_context
>*
>* TODO: Is TLB flush really needed ?
>*/
> - ipmmu_ctx_write(domain, IMCTR, IMCTR_FLUSH);
> + ipmmu_ctx_write2(domain, IMCTR, IMCTR_FLUSH);
>   ipmmu_tlb_sync(domain);
>   ipmmu_domain_free_context(domain->root, domain->context_id);
>  }
> 

Re: [PATCH] serial: 8250: 8250_core: Use dev_name() during request_irq()

[Greg Kroah-Hartman]

On Wed, Mar 08, 2017 at 05:49:43PM +0530, Vignesh R wrote:
> Passing "serial" as name during request_irq() results in all serial port
> irqs have same name. This does not help much to easily identify which
> irq belongs to which serial port instance. Therefore pass dev_name()
> during request_irq() so that better identifiable name is listed for
> serial ports in cat /proc/interrupts output.
> 
> Output of cat /proc/interrupts
> Before this patch:
>  26:689  0 GICv2 309 Edge  serial
> After this patch:
>  26:696  0 GICv2 309 Edge  2530c00.serial
> 
> Signed-off-by: Vignesh R 

I need a "full" name here, unless you really do sign legal documents
with just one letter as a last/sur-name?

thanks,

greg k-h

Re: kasan behavior when built with unsupported compiler

[Dmitry Vyukov]

On Wed, Mar 8, 2017 at 9:10 AM, Nikolay Borisov
 wrote:
>
>
> On  7.03.2017 17:54, Dmitry Vyukov wrote:
>> On Tue, Mar 7, 2017 at 4:35 PM, Nikolay Borisov
>>  wrote:
>>> Hello,
>>>
>>> I've been chasing a particular UAF as reported by kasan
>>> (https://www.spinics.net/lists/kernel/msg2458136.html). However, one
>>> thing which I took notice of rather lately is that I was building my
>>> kernel with gcc 4.7.4 which is not supported by kasan as indicated by
>>> the following string:
>>>
>>> scripts/Makefile.kasan:19: Cannot use CONFIG_KASAN:
>>> -fsanitize=kernel-address is not supported by compiler
>>>
>>>
>>> Nevertheless, the kernel compiles and when I boot it I see the kasan
>>> splats as per the referenced thread. If, however, I build the kernel
>>> with a newer compiler version 5.4.0 kasan no longer complains.
>>>
>>>
>>> At this point I'm wondering whether the splats can be due to old
>>> compiler being used e.g. false positives or are they genuine splats and
>>> gcc 5 somehow obfuscates them ? Clearly despite the warning about not
>>> being able to use CONFIG_KASAN it is still working since I'm seeing the
>>> splats. Is this valid behavior ?
>>
>>
>> Hi,
>>
>> Re the message that kasan is not supported while it's still enabled in the 
>> end.
>> I think it's an issue related to gcc plugins. Originally kasan was
>> supported with 5.0+ thus the message. However, later we extended this
>> support to 4.5+ with gcc plugins. However, that confusing message from
>> build system was not fixed. So yes, it's confusing and it's something
>> to fix, but mostly you can just ignore it.
>>
>> Re false positives with 4.7. By default I would assume that it is true
>> positive. Should be easy to check with manual printfs.
>
> So apparently this is indeed a false positive, resulting from using the old
> compiler. I used the attached patch to verify it.
>
> And what it prints is :
> [   17.184288] Assigned fbdev-blacklist.conff(880001ea8020)20 whole 
> object: 88006ae8fdb0 inode:88006bff60d0
> [   17.185808] Calling filldir with 88006ae8fdb0
>
> So the first line essentially happens when the object 88006ae8fdb0 is
> being allocated and the second when it's used in filldir. The warning in
> ext4_ext_map_blocks doesn't trigger. However, if I remove the check for
> the value of ext4_global_pointer then I see multiple lines such as:
> [   17.386283] ext4_ext_map_blocks:freeing  pointer used in 
> ext4_htree_store_dirent: 88006ae8fdb0 inode: 88006bff60d0
> [   17.387601] Assigned fbdev-blacklist.conff(880001eb3020)20 whole 
> object: 88006ae8fdb0 inode:88006bff60d0
> [   17.388740] Calling filldir with 88006ae8fdb0
>
> so that same object was used right before it is allocated again in
> ext4_htree_store_dirent. And when you think about it it is logical since
> before filling in the dentry names in ext4_htree_store_dirent ext4 has to 
> fetch the
> contents of the directory from disk.
>
> This leads me to believe that kasan is getting confused thinking that
> the object is being freed AFTER being allocated in
> ext4_htree_store_dirent but testing shows it's being freed BEFORE. So
> I deem this a false positive, triggered by the compiler.


I am not following how compiler version can affect any of this. But if
you say this is a false positive, let it be so. gcc 4.7 is old.

Re: counting file descriptors with a cgroup controller

[Tejun Heo]

Hello,

On Tue, Mar 07, 2017 at 09:06:49PM +0100, Krzysztof Opasiak wrote:
> Personally, I don't want to use rlimit for this as it ends up returning
> error code from for example open() when we hit the limit. This may lead to
> some unpredictable crashes in  services (esp. those poor proprietary binary
> blobs). Instead of injecting errors to service we would like to just get
> notification that this service has more opened fds than it should and ask it
> to restart in a polite way.
> 
> For memory seems to be quite easy to achieve as we can just get eventfd
> notification when application passes given memory usage using memory cgroup
> controller. Maybe you know some efficient method to do the same for fds?

So, if all you wanna do is reliably detecting open(2) failures, can't
you do that with bpf tracing?

Thanks.

-- 
tejun

Re: [PATCH v2 1/2] net: sched: make default fifo qdiscs appear in the dump

[Jiri Pirko]

Wed, Mar 08, 2017 at 01:03:42PM CET, ji...@kernel.org wrote:
>From: Jiri Kosina 
>
>The original reason [1] for having hidden qdiscs (potential scalability
>issues in qdisc_match_from_root() with single linked list in case of large
>amount of qdiscs) has been invalidated by 59cc1f61f0 ("net: sched: convert
>qdisc linked list to hashtable").
>
>This allows us for bringing more clarity and determinism into the dump by
>making default pfifo qdiscs visible.
>
>We're not turning this on by default though, at it was deemed [2] too
>intrusive / unnecessary change of default behavior towards userspace.
>Instead, TCA_DUMP_INVISIBLE netlink attribute is introduced, which allows
>applications to request complete qdisc hierarchy dump, including the
>ones that have always been implicit/invisible.
>
>Singleton noop_qdisc stays invisible, as teaching the whole infrastructure
>about singletons would require quite some surgery with very little gain
>(seeing no qdisc or seeing noop qdisc in the dump is probably setting
>the same user expectation).
>
>[1] 
>http://lkml.kernel.org/r/1460732328.10638.74.ca...@edumazet-glaptop3.roam.corp.google.com
>[2] 
>http://lkml.kernel.org/r/20161021.105935.1907696543877061916.da...@davemloft.net
>
>Signed-off-by: Jiri Kosina 
>---

[...]


>diff --git a/include/uapi/linux/rtnetlink.h b/include/uapi/linux/rtnetlink.h
>index 262f0379d83a..c7de00e09797 100644
>--- a/include/uapi/linux/rtnetlink.h
>+++ b/include/uapi/linux/rtnetlink.h
>@@ -542,6 +542,7 @@ enum {
>   TCA_FCNT,
>   TCA_STATS2,
>   TCA_STAB,
>+  TCA_DUMP_INVISIBLE,
>   TCA_PAD,

You are changing UAPI value of TCA_PAD...


>   __TCA_MAX
> };

Re: Kernel without RTC

[Hadimani, Jagadish]

Hello Alexandre,

I guess the Linux kernel uses HPET timer...
But can we can force Linux kernel to use Tsc or per core timer...

Sent from my iPhone

> On 8 Mar 2017, at 6:47 PM, Alexandre Belloni 
>  wrote:
> 
> Hi,
> 
>> On 07/03/2017 at 00:48:18 +0530, Shah, Nehal-bakulchandra wrote:
>> Hi,
>> 
>> Currently we are having hardware which does not have RTC. It is single 
>> processor system. However it does have TSC timer.
>> 
>> Now, how to use scheduler with only TSC as current kernel scheduler leverage 
>> the RTC for scheduling? I had seen one old patch
>> 
>> http://marc.info/?l=linux-kernel=112013203625990=2 
>> 
>> But i guess this patch was later on not taken, It will be great if you can 
>> some pointers to move forward?
>> 
> 
> The kernel doesn't use the RTC for its time source so it can
> already work without an RTC.
> 
> 
> -- 
> Alexandre Belloni, Free Electrons
> Embedded Linux and Kernel engineering
> http://free-electrons.com

Re: [PATCH 11/26] IB/ocrdma: Delete unnecessary braces

[Devesh Sharma]

On Wed, Mar 8, 2017 at 6:34 PM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Tue, 7 Mar 2017 21:12:56 +0100
>
> Do not use curly brackets at some source code places
> where a single statement should be sufficient.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/infiniband/hw/ocrdma/ocrdma_hw.c | 17 -
>  1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c 
> b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
> index aa32bc9f323d..d5b988b011d1 100644
> --- a/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
> +++ b/drivers/infiniband/hw/ocrdma/ocrdma_hw.c
> @@ -1092,14 +1092,14 @@ static int ocrdma_mbx_cmd(struct ocrdma_dev *dev, 
> struct ocrdma_mqe *mqe)
> if (cqe_status || ext_status) {
> pr_err("%s() cqe_status=0x%x, ext_status=0x%x,",
>__func__, cqe_status, ext_status);
> -   if (rsp) {
> +   if (rsp)
> /* This is for embedded cmds. */
> pr_err("opcode=0x%x, subsystem=0x%x\n",
>(rsp->subsys_op & OCRDMA_MBX_RSP_OPCODE_MASK) 
> >>
> OCRDMA_MBX_RSP_OPCODE_SHIFT,
> (rsp->subsys_op & OCRDMA_MBX_RSP_SUBSYS_MASK) 
> >>
> OCRDMA_MBX_RSP_SUBSYS_SHIFT);
> -   }
> +
> status = ocrdma_get_mbx_cqe_errno(cqe_status);
> goto mbx_err;
> }
> @@ -1600,10 +1600,9 @@ void ocrdma_alloc_pd_pool(struct ocrdma_dev *dev)
> return;
>
> status = ocrdma_mbx_alloc_pd_range(dev);
> -   if (status) {
> +   if (status)
> pr_err("%s(%d) Unable to initialize PD pool, using 
> default.\n",
>  __func__, dev->id);
> -   }
>  }
>
>  static void ocrdma_free_pd_pool(struct ocrdma_dev *dev)
> @@ -2997,11 +2996,10 @@ static int ocrdma_parse_dcbxcfg_rsp(struct ocrdma_dev 
> *dev, int ptype,
> goto out;
> }
> }
> -   if (slindx == OCRDMA_MAX_SERVICE_LEVEL_INDEX) {
> +   if (slindx == OCRDMA_MAX_SERVICE_LEVEL_INDEX)
> pr_info("%s ocrdma%d application priority not 
> set for 0x%x protocol\n",
> dev_name(>nic_info.pdev->dev),
> dev->id, proto);
> -   }
> }
> }
>
> @@ -3158,16 +3156,17 @@ static int ocrdma_modify_eqd(struct ocrdma_dev *dev, 
> struct ocrdma_eq *eq,
>  int num)
>  {
> int num_eqs, i = 0;
> -   if (num > 8) {
> +
> +   if (num > 8)
> while (num) {
> num_eqs = min(num, 8);
> ocrdma_mbx_modify_eqd(dev, [i], num_eqs);
> i += num_eqs;
> num -= num_eqs;
> }

May be compiler would give you a warning here, could you check once?

> -   } else {
> +   else
> ocrdma_mbx_modify_eqd(dev, eq, num);
> -   }
> +
> return 0;
>  }
>
> --
> 2.12.0
>

Re: [PATCH v2 06/21] x86/xen: split off enlighten_pv.c

[Juergen Gross]

On 02/03/17 18:53, Vitaly Kuznetsov wrote:
> Basically, enlighten.c is renamed to enlighten_pv.c and some code moved
> out to common enlighten.c.
> 
> Signed-off-by: Vitaly Kuznetsov 

Reviewed-by: Juergen Gross 


Juergen

Re: [RFC PATCH v4 28/28] x86: Add support to make use of Secure Memory Encryption

[Borislav Petkov]

On Tue, Mar 07, 2017 at 10:05:00AM -0600, Tom Lendacky wrote:
> > And then you need to correct the function signature in the
> > !CONFIG_AMD_MEM_ENCRYPT case, at the end of this file, too:
> > 
> > unsigned long __init sme_enable(struct boot_params *bp) { 
> > return 0; }
> 
> Yup, missed that.  I'll make it match.

Or, you can do this:

unsigned long __init sme_enable(void *boot_data)
{
#ifdef CONFIG_AMD_MEM_ENCRYPT
struct boot_params *bp = boot_data;
unsigned int eax, ebx, ecx, edx;
unsigned long cmdline_ptr;

...

out:
#endif /* CONFIG_AMD_MEM_ENCRYPT */
return sme_me_mask;
}

and never worry for function headers going out of whack.

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[PATCH v3 3/3] Input: add a PS/2 to SMBus platform module

[Benjamin Tissoires]

This driver is a glue between PS/2 devices that enumerate
the RMI4 devices and Elan touchpads to the RMI4 (or Elan)
SMBus driver.

We use an intermediate platform device to not add a
dependency between psmouse and I2C. It also handles
the subtleties of going around the serio mutex lock by
deferring the i2c creation/destruction in a separate
thread.

Signed-off-by: Benjamin Tissoires 

---

changes in v3:
- integrate the suspend/resume followup patch
- removed the Kconfig dance for RMI4_SMBUS selecting PS2_SMBUS

changes in v2:
- use our own ps2 driver (detach psmouse and reattach ours)
---
 drivers/input/misc/Kconfig |  11 ++
 drivers/input/misc/Makefile|   1 +
 drivers/input/misc/ps2_smbus.c | 424 +
 3 files changed, 436 insertions(+)
 create mode 100644 drivers/input/misc/ps2_smbus.c

diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
index 5b6c522..64362ba 100644
--- a/drivers/input/misc/Kconfig
+++ b/drivers/input/misc/Kconfig
@@ -822,4 +822,15 @@ config INPUT_HISI_POWERKEY
  To compile this driver as a module, choose M here: the
  module will be called hisi_powerkey.
 
+config PS2_SMBUS
+   tristate "Platform Support for PS/2 Nodes also connected over SMBus"
+   depends on I2C
+   help
+ Say Y here if you want to support RMI4 or Elan devices connected to
+ an SMB bus but enumerated through PS/2.
+
+ if unsure, say N.
+ To compile this driver as a module, choose M here: the module will be
+ called ps2_smbus.
+
 endif
diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
index b10523f..59406da 100644
--- a/drivers/input/misc/Makefile
+++ b/drivers/input/misc/Makefile
@@ -56,6 +56,7 @@ obj-$(CONFIG_INPUT_PCSPKR)+= pcspkr.o
 obj-$(CONFIG_INPUT_PM8941_PWRKEY)  += pm8941-pwrkey.o
 obj-$(CONFIG_INPUT_PM8XXX_VIBRATOR)+= pm8xxx-vibrator.o
 obj-$(CONFIG_INPUT_PMIC8XXX_PWRKEY)+= pmic8xxx-pwrkey.o
+obj-$(CONFIG_PS2_SMBUS)+= ps2_smbus.o
 obj-$(CONFIG_INPUT_POWERMATE)  += powermate.o
 obj-$(CONFIG_INPUT_PWM_BEEPER) += pwm-beeper.o
 obj-$(CONFIG_INPUT_RB532_BUTTON)   += rb532_button.o
diff --git a/drivers/input/misc/ps2_smbus.c b/drivers/input/misc/ps2_smbus.c
new file mode 100644
index 000..0b03224
--- /dev/null
+++ b/drivers/input/misc/ps2_smbus.c
@@ -0,0 +1,424 @@
+/*
+ * Copyright (c) 2017 Red Hat, Inc
+ *
+ * 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 
+
+MODULE_AUTHOR("Benjamin Tissoires ");
+MODULE_DESCRIPTION("Platform PS/2 - SMBus bridge driver");
+MODULE_LICENSE("GPL");
+
+static struct workqueue_struct *kps2smbus_wq;
+static DECLARE_WAIT_QUEUE_HEAD(ps2smbus_serio_wait);
+static DEFINE_MUTEX(ps2smbus_mutex);
+
+enum ps2smbus_type {
+   PS2SMBUS_SYNAPTICS_RMI4,
+};
+
+struct ps2smbus {
+   struct serio *serio;
+   struct i2c_client *smbus_client;
+   struct notifier_block i2c_notifier;
+   enum ps2smbus_type type;
+   void *pdata;
+};
+
+enum ps2smbus_event_type {
+   PS2SMBUS_REGISTER_DEVICE,
+   PS2SMBUS_UNREGISTER_DEVICE,
+};
+
+struct ps2smbus_work {
+   struct work_struct work;
+   enum ps2smbus_event_type type;
+   struct ps2smbus *ps2smbus;
+   struct i2c_adapter *adap;
+};
+
+struct ps2smbus_serio {
+   struct ps2dev ps2dev;
+   bool suspended;
+};
+
+static struct serio_device_id ps2smbus_serio_ids[] = {
+   {
+   .type   = SERIO_8042,
+   .proto  = SERIO_ANY,
+   .id = SERIO_ANY,
+   .extra  = SERIO_ANY,
+   },
+   { 0 }
+};
+
+MODULE_DEVICE_TABLE(serio, ps2smbus_serio_ids);
+
+static irqreturn_t ps2smbus_interrupt(struct serio *serio,
+   unsigned char data, unsigned int flags)
+{
+   struct ps2smbus_serio *ps2smbus = serio_get_drvdata(serio);
+
+   if (unlikely((flags & SERIO_TIMEOUT) || (flags & SERIO_PARITY))) {
+   ps2_cmd_aborted(>ps2dev);
+   goto out;
+   }
+
+   if (unlikely(ps2smbus->ps2dev.flags & PS2_FLAG_ACK))
+   if (ps2_handle_ack(>ps2dev, data))
+   goto out;
+
+   if (unlikely(ps2smbus->ps2dev.flags & PS2_FLAG_CMD))
+   if (ps2_handle_response(>ps2dev, data))
+   goto out;
+
+out:
+   return IRQ_HANDLED;
+}
+
+#define PSMOUSE_CMD_DISABLE0x00f5
+
+static int ps2smbus_connect(struct serio *serio, struct serio_driver *drv)
+{
+   int error;
+   struct ps2smbus_serio *ps2smbus;
+
+   ps2smbus = kzalloc(sizeof(struct ps2smbus_serio), GFP_KERNEL);
+
+   ps2_init(>ps2dev, serio);
+
+   serio_set_drvdata(serio, 

Re: [PATCH 21/26] IB/ocrdma: Improve another size determination in ocrdma_create_srq()

[Devesh Sharma]

Acked-By: Devesh Sharma 

On Wed, Mar 8, 2017 at 6:54 PM, SF Markus Elfring
 wrote:
> From: Markus Elfring 
> Date: Wed, 8 Mar 2017 10:10:50 +0100
>
> Replace the specification of a data type by a pointer dereference
> as the parameter for the operator "sizeof" to make the corresponding size
> determination a bit safer according to the Linux coding style convention.
>
> Signed-off-by: Markus Elfring 
> ---
>  drivers/infiniband/hw/ocrdma/ocrdma_verbs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c 
> b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> index af8798fd35b1..bedc229be89d 100644
> --- a/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> +++ b/drivers/infiniband/hw/ocrdma/ocrdma_verbs.c
> @@ -1915,7 +1915,7 @@ struct ib_srq *ocrdma_create_srq(struct ib_pd *ibpd,
> if (srq->idx_bit_fields == NULL)
> goto arm_err;
> memset(srq->idx_bit_fields, 0xff,
> -  srq->bit_fields_len * sizeof(u32));
> +  srq->bit_fields_len * sizeof(*srq->idx_bit_fields));
> }
>
> if (init_attr->attr.srq_limit) {
> --
> 2.12.0
>