[PATCH] serial: of_serial: use devm_clk_get() instead of clk_get()

[Masahiro Yamada]

The probe method of this driver calls clk_get(), but clk_put() is
missing from the remove callback.

Using the managed clk function is easier than fixing other parts.

Signed-off-by: Masahiro Yamada 
---

 drivers/tty/serial/of_serial.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/tty/serial/of_serial.c b/drivers/tty/serial/of_serial.c
index 28b9b47..d353fdf 100644
--- a/drivers/tty/serial/of_serial.c
+++ b/drivers/tty/serial/of_serial.c
@@ -67,7 +67,7 @@ static int of_platform_serial_setup(struct platform_device 
*ofdev,
if (of_property_read_u32(np, "clock-frequency", )) {
 
/* Get clk rate through clk driver if present */
-   info->clk = clk_get(>dev, NULL);
+   info->clk = devm_clk_get(>dev, NULL);
if (IS_ERR(info->clk)) {
dev_warn(>dev,
"clk or clock-frequency not defined\n");
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] cgroup: add explicit cast and comment for return type conversion

[Nicholas Mc Guire]

On Sun, 24 May 2015, Tejun Heo wrote:

> Hello,
> 
> On Sun, May 24, 2015 at 03:07:52PM +0200, Nicholas Mc Guire wrote:
> > Type-checking coccinelle spatches are being used to locate type mismatches
> > between function signatures and return values in this case this produced:
> > ./kernel/cgroup.c:2525 WARNING: return of wrong type
> > ssize_t != size_t, 
> > 
> > Returning unsigned types converted to a signed type can be problematic
> > but in this case the size_t is <= PATH_MAX which is less than ulong/2 so
> > the conversion is safe - to make static code checking happy this is 
> > resolved by an explicit cast and appropriate comment.
> > 
> > Patch was compile tested with x86_64_defconfig (implies CONFIG_CGROUPS=y)
> > 
> > Patch is against 4.1-rc4 (localversion-next is -next-20150522)
> > 
> > Signed-off-by: Nicholas Mc Guire 
> > ---
> > 
> > Not sure if "cleanups" like this are acceptable - in this case I did not
> > find any better way to make static code checkers happy though.
> > 
> >  kernel/cgroup.c |6 +-
> >  1 file changed, 5 insertions(+), 1 deletion(-)
> > 
> > diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> > index b91177f..04de621 100644
> > --- a/kernel/cgroup.c
> > +++ b/kernel/cgroup.c
> > @@ -2523,7 +2523,11 @@ static ssize_t cgroup_release_agent_write(struct 
> > kernfs_open_file *of,
> > sizeof(cgrp->root->release_agent_path));
> > spin_unlock(_agent_path_lock);
> > cgroup_kn_unlock(of->kn);
> > -   return nbytes;
> > +
> > +   /* the path of the release notifier is <= PATH_MAX
> > +* so "downsizing" to signed long is safe here
> > +*/
> > +   return (ssize_t)nbytes;
> 
> idk, does this actually help anything?  This isn't different from any
> other implicit type casts.  Are we gonna convert all downward implicit
> casts to be explicit?
>
nop not downward but signed/unsigned  if it were down it would not be
a problem but signed/unsigned can be - for those cases where it can't
be fixed up by changing the declarations or return variable types 
explicit cast might make sense - as noted in the patch Im not sure either
if this form of cleanups is helpful. 

In the kernel core there are about 400 signed/unsigned implicit 
conversions (about 3k in the entire kernel) which is what Im trying to 
remove or if that is not possible in a resonable way mark as false positive.

thx!
hofrat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] video/logo: introduce new system state for checking if logos are freed

[Tomi Valkeinen]

On 06/05/15 10:09, Heiko Schocher wrote:
> commit 92b004d1aa9f ("video/logo: prevent use of logos after they have been 
> freed")
> 
> added a late_initcall function to mark the logos as freed. In reality
> the logos are freed later, and fbdev probe may be ran between this
> late_initcall and the freeing of the logos. In that case the logos
> would not be drawn. To prevent this introduced a new system_state
> SYSTEM_FREEING_MEM and set this state before freeing memory. This
> state could be checked now in fb_find_logo(). This system state
> is maybe useful on other places too.
> 
> Signed-off-by: Heiko Schocher 
> 
> ---
> Found this issue on an imx6 based board with a display which needs
> a spi initialization. With 3.18.2 I see a perfect logo, but with
> current ml, bootlogo is missing, because drm gets probed before
> spi display, which leads in drm probing is deferred until the
> spi display is probed. After that drm is probed again ... but
> this is too late for showing the bootlogo.
> With this patch, bootlogo is drawn again. I am not sure, if it
> is so easy to add a new system state ... but we should have a
> possibility to detect if initdata is freed or not. this is maybe
> also for other modules interesting. Maybe we add a
> kernel_initdata_freed()
> function instead of a new system state?
> 
>  drivers/video/logo/logo.c | 15 ---
>  include/linux/kernel.h|  1 +
>  init/main.c   |  1 +
>  3 files changed, 6 insertions(+), 11 deletions(-)
> 
> diff --git a/drivers/video/logo/logo.c b/drivers/video/logo/logo.c
> index 10fbfd8..d798a9f 100644
> --- a/drivers/video/logo/logo.c
> +++ b/drivers/video/logo/logo.c
> @@ -26,16 +26,6 @@ MODULE_PARM_DESC(nologo, "Disables startup logo");
>   * Use late_init to mark the logos as freed to prevent any further use.
>   */
>  
> -static bool logos_freed;
> -
> -static int __init fb_logo_late_init(void)
> -{
> - logos_freed = true;
> - return 0;
> -}
> -
> -late_initcall(fb_logo_late_init);
> -
>  /* logo's are marked __initdata. Use __init_refok to tell
>   * modpost that it is intended that this function uses data
>   * marked __initdata.
> @@ -44,7 +34,10 @@ const struct linux_logo * __init_refok fb_find_logo(int 
> depth)
>  {
>   const struct linux_logo *logo = NULL;
>  
> - if (nologo || logos_freed)
> + if (system_state >= SYSTEM_FREEING_MEM)
> + return NULL;
> +
> + if (nologo)
>   return NULL;
>  
>   if (depth >= 1) {
> diff --git a/include/linux/kernel.h b/include/linux/kernel.h
> index 3a5b48e..e5875bf 100644
> --- a/include/linux/kernel.h
> +++ b/include/linux/kernel.h
> @@ -462,6 +462,7 @@ extern bool early_boot_irqs_disabled;
>  /* Values used for system_state */
>  extern enum system_states {
>   SYSTEM_BOOTING,
> + SYSTEM_FREEING_MEM,
>   SYSTEM_RUNNING,
>   SYSTEM_HALT,
>   SYSTEM_POWER_OFF,
> diff --git a/init/main.c b/init/main.c
> index 2115055..4965ed0 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -931,6 +931,7 @@ static int __ref kernel_init(void *unused)
>   kernel_init_freeable();
>   /* need to finish all async __init code before freeing the memory */
>   async_synchronize_full();
> + system_state = SYSTEM_FREEING_MEM;
>   free_initmem();
>   mark_rodata_ro();
>   system_state = SYSTEM_RUNNING;

Without locking, the initmem may be freed while fb_find_logo() is running.

 Tomi



signature.asc
Description: OpenPGP digital signature

Re: [PATCH] net: use msecs_to_jiffies for conversion to jiffies

[Nicholas Mc Guire]

On Sun, 24 May 2015, David Miller wrote:

> From: Nicholas Mc Guire 
> Date: Sat, 23 May 2015 15:43:36 +0200
> 
> > API compliance scanning with coccinelle flagged:
> > ./net/irda/timer.c:63:35-37: use of msecs_to_jiffies probably perferable
> > 
> > Converting milliseconds to jiffies by "val * HZ / 1000" technically
> > is not a clean solution as it does not handle all corner cases correctly.
> > By changing the conversion to use msecs_to_jiffies(val) conversion is
> > correct in all cases. Further the () around the arithmetic expression
> > was dropped.
> > 
> > Patch was compile tested for x86_64_defconfig + CONFIG_IRDA=m
> > 
> > Patch is against 4.1-rc4 (localversion-next is -next-20150522)
> > 
> > Signed-off-by: Nicholas Mc Guire 
> 
> The appropriate subsystem prefix for this change is not "net: "
> but rather "irda: ", please update your Subject line accordingly
> and resubmit.
>
sorry - the net: cam from looking at the output of 
hofrat@debian:~/git/linux-next$ git log --oneline net/irda/timer.c
d82603c treewide: Replace incomming with incoming in all comments and strings
9ffc93f Remove all #inclusions of asm/system.h
25985ed Fix common misspellings
5eaa65b net: Make static
db955170 more UTF-8 conversions
6819bc2 [NET] IRDA: Fix whitespace errors.
6ab3d56 Remove obsolete #include 

where it was not really clear what prefix to use - and net: seemed the most
fitting. will fix it up and resend.

thx!
hofrat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 08/11] block: kill merge_bvec_fn() completely

[NeilBrown]

On Fri, 22 May 2015 11:18:40 -0700 Ming Lin  wrote:

> From: Kent Overstreet 
> 
> As generic_make_request() is now able to handle arbitrarily sized bios,
> it's no longer necessary for each individual block driver to define its
> own ->merge_bvec_fn() callback. Remove every invocation completely.
> 
> Cc: Jens Axboe 
> Cc: Lars Ellenberg 
> Cc: drbd-u...@lists.linbit.com
> Cc: Jiri Kosina 
> Cc: Yehuda Sadeh 
> Cc: Sage Weil 
> Cc: Alex Elder 
> Cc: ceph-de...@vger.kernel.org
> Cc: Alasdair Kergon 
> Cc: Mike Snitzer 
> Cc: dm-de...@redhat.com
> Cc: Neil Brown 
> Cc: linux-r...@vger.kernel.org
> Cc: Christoph Hellwig 
> Cc: "Martin K. Petersen" 
> Signed-off-by: Kent Overstreet 
> [dpark: also remove ->merge_bvec_fn() in dm-thin as well as
>  dm-era-target, and resolve merge conflicts]
> Signed-off-by: Dongsu Park 
> Signed-off-by: Ming Lin 

Acked-by: NeilBrown  (for the 'md' bits)

Very happy to see this happening!

Thanks,
NeilBrown


> ---
>  block/blk-merge.c  |  17 +-
>  block/blk-settings.c   |  22 
>  drivers/block/drbd/drbd_int.h  |   1 -
>  drivers/block/drbd/drbd_main.c |   1 -
>  drivers/block/drbd/drbd_req.c  |  35 
>  drivers/block/pktcdvd.c|  21 ---
>  drivers/block/rbd.c|  47 
>  drivers/md/dm-cache-target.c   |  21 ---
>  drivers/md/dm-crypt.c  |  16 --
>  drivers/md/dm-era-target.c |  15 -
>  drivers/md/dm-flakey.c |  16 --
>  drivers/md/dm-linear.c |  16 --
>  drivers/md/dm-log-writes.c |  16 --
>  drivers/md/dm-snap.c   |  15 -
>  drivers/md/dm-stripe.c |  21 ---
>  drivers/md/dm-table.c  |   8 ---
>  drivers/md/dm-thin.c   |  31 ---
>  drivers/md/dm-verity.c |  16 --
>  drivers/md/dm.c| 120 +---
>  drivers/md/dm.h|   2 -
>  drivers/md/linear.c|  43 ---
>  drivers/md/md.c|  26 -
>  drivers/md/md.h|  12 
>  drivers/md/multipath.c |  21 ---
>  drivers/md/raid0.c |  56 ---
>  drivers/md/raid0.h |   2 -
>  drivers/md/raid1.c |  58 +---
>  drivers/md/raid10.c| 121 
> +
>  drivers/md/raid5.c |  32 ---
>  include/linux/blkdev.h |  10 
>  include/linux/device-mapper.h  |   4 --
>  31 files changed, 9 insertions(+), 833 deletions(-)
> 
> diff --git a/block/blk-merge.c b/block/blk-merge.c
> index dc14255..25cafb8 100644
> --- a/block/blk-merge.c
> +++ b/block/blk-merge.c
> @@ -69,24 +69,13 @@ static struct bio *blk_bio_segment_split(struct 
> request_queue *q,
>   struct bio *split;
>   struct bio_vec bv, bvprv;
>   struct bvec_iter iter;
> - unsigned seg_size = 0, nsegs = 0;
> + unsigned seg_size = 0, nsegs = 0, sectors = 0;
>   int prev = 0;
>  
> - struct bvec_merge_data bvm = {
> - .bi_bdev= bio->bi_bdev,
> - .bi_sector  = bio->bi_iter.bi_sector,
> - .bi_size= 0,
> - .bi_rw  = bio->bi_rw,
> - };
> -
>   bio_for_each_segment(bv, bio, iter) {
> - if (q->merge_bvec_fn &&
> - q->merge_bvec_fn(q, , ) < (int) bv.bv_len)
> - goto split;
> -
> - bvm.bi_size += bv.bv_len;
> + sectors += bv.bv_len >> 9;
>  
> - if (bvm.bi_size >> 9 > queue_max_sectors(q))
> + if (sectors > queue_max_sectors(q))
>   goto split;
>  
>   /*
> diff --git a/block/blk-settings.c b/block/blk-settings.c
> index 12600bf..e90d477 100644
> --- a/block/blk-settings.c
> +++ b/block/blk-settings.c
> @@ -53,28 +53,6 @@ void blk_queue_unprep_rq(struct request_queue *q, 
> unprep_rq_fn *ufn)
>  }
>  EXPORT_SYMBOL(blk_queue_unprep_rq);
>  
> -/**
> - * blk_queue_merge_bvec - set a merge_bvec function for queue
> - * @q:   queue
> - * @mbfn:merge_bvec_fn
> - *
> - * Usually queues have static limitations on the max sectors or segments that
> - * we can put in a request. Stacking drivers may have some settings that
> - * are dynamic, and thus we have to query the queue whether it is ok to
> - * add a new bio_vec to a bio at a given offset or not. If the block device
> - * has such limitations, it needs to register a merge_bvec_fn to control
> - * the size of bio's sent to it. Note that a block device *must* allow a
> - * single page to be added to an empty bio. The block device driver may want
> - * to use the bio_split() function to deal with these bio's. By default
> - * no merge_bvec_fn is defined for a queue, and only the fixed limits are
> - * honored.
> - */
> -void blk_queue_merge_bvec(struct request_queue *q, merge_bvec_fn *mbfn)
> -{
> - q->merge_bvec_fn = mbfn;
> -}
> 

Re: [PATCH 1/1] dmaengine: pl330: Initialize pl330 for pl330_prep_dma_memcpy after NULL check of pch

[Vinod Koul]

On Sun, May 24, 2015 at 06:30:36PM +0530, Maninder Singh wrote:
> git send-email missed one line
> Add it in description too
> 
> On 24 May 2015 18:11, "Maninder Singh"  wrote:
> >
> > From: Maninder Singh 
> >
> 
> Currently pch pointer is already dereferenced before NULL check
> And thus we are getting below warning:
> Warn: variable dereferenced before check 'pch'
no you resend the patch with this description and this is something we need
here

-- 
~Vinod

> 
> > So initialize struct pl330_dmac *pl330 after NULL check
> > of dma_pl330_chan *pch.
> >
> > Signed-off-by: Maninder Singh 
> > Reviewed-by: Vaneet Narang 
> > ---
> >  drivers/dma/pl330.c |4 +++-
> >  1 files changed, 3 insertions(+), 1 deletions(-)
> > diff --git a/drivers/dma/pl330.c b/drivers/dma/pl330.c
> > index a7d9d30..7e27144 100644
> > --- a/drivers/dma/pl330.c
> > +++ b/drivers/dma/pl330.c
> > @@ -2581,12 +2581,14 @@ pl330_prep_dma_memcpy(struct dma_chan *chan,
> dma_addr_t dst,
> >  {
> > struct dma_pl330_desc *desc;
> > struct dma_pl330_chan *pch = to_pchan(chan);
> > -   struct pl330_dmac *pl330 = pch->dmac;
> > +   struct pl330_dmac *pl330;
> > int burst;
> >
> > if (unlikely(!pch || !len))
> > return NULL;
> >
> > +   pl330 = pch->dmac;
> > +
> > desc = __pl330_prep_dma_memcpy(pch, dst, src, len);
> > if (!desc)
> > return NULL;
> > --
> > 1.7.1

-- 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 06/11] md/raid5: get rid of bio_fits_rdev()

[NeilBrown]

On Fri, 22 May 2015 11:18:38 -0700 Ming Lin  wrote:

> From: Kent Overstreet 
> 
> Remove bio_fits_rdev() completely, because ->merge_bvec_fn() has now
> gone. There's no point in calling bio_fits_rdev() only for ensuring
> aligned read from rdev.

Surely this patch should come *before* 
  [PATCH v4 07/11] md/raid5: split bio for chunk_aligned_read

and the comment says ->merge_bvec_fn() has gone, but that isn't until
  [PATCH v4 08/11] block: kill merge_bvec_fn() completely


If those issues are resolved, then

  Acked-by: NeilBrown 

Thanks,
NeilBrown


> 
> Cc: Neil Brown 
> Cc: linux-r...@vger.kernel.org
> Signed-off-by: Kent Overstreet 
> [dpark: add more description in commit message]
> Signed-off-by: Dongsu Park 
> Signed-off-by: Ming Lin 
> ---
>  drivers/md/raid5.c | 23 +--
>  1 file changed, 1 insertion(+), 22 deletions(-)
> 
> diff --git a/drivers/md/raid5.c b/drivers/md/raid5.c
> index 1ba97fd..b303ded 100644
> --- a/drivers/md/raid5.c
> +++ b/drivers/md/raid5.c
> @@ -4743,25 +4743,6 @@ static void raid5_align_endio(struct bio *bi, int 
> error)
>   add_bio_to_retry(raid_bi, conf);
>  }
>  
> -static int bio_fits_rdev(struct bio *bi)
> -{
> - struct request_queue *q = bdev_get_queue(bi->bi_bdev);
> -
> - if (bio_sectors(bi) > queue_max_sectors(q))
> - return 0;
> - blk_recount_segments(q, bi);
> - if (bi->bi_phys_segments > queue_max_segments(q))
> - return 0;
> -
> - if (q->merge_bvec_fn)
> - /* it's too hard to apply the merge_bvec_fn at this stage,
> -  * just just give up
> -  */
> - return 0;
> -
> - return 1;
> -}
> -
>  static int chunk_aligned_read(struct mddev *mddev, struct bio * raid_bio)
>  {
>   struct r5conf *conf = mddev->private;
> @@ -4815,11 +4796,9 @@ static int chunk_aligned_read(struct mddev *mddev, 
> struct bio * raid_bio)
>   align_bi->bi_bdev =  rdev->bdev;
>   __clear_bit(BIO_SEG_VALID, _bi->bi_flags);
>  
> - if (!bio_fits_rdev(align_bi) ||
> - is_badblock(rdev, align_bi->bi_iter.bi_sector,
> + if (is_badblock(rdev, align_bi->bi_iter.bi_sector,
>   bio_sectors(align_bi),
>   _bad, _sectors)) {
> - /* too big in some way, or has a known bad block */
>   bio_put(align_bi);
>   rdev_dec_pending(rdev, mddev);
>   return 0;



pgpoMuu3Fw6cq.pgp
Description: OpenPGP digital signature

[PATCH] drivers:usb:fsl: Replace macros with enumerated type

[Nikhil Badola]

Replace macros with enumerated type to represent usb ip controller
version

Signed-off-by: Nikhil Badola 
---
Depends on "drivers: usb :fsl: Add support for USB controller version-2.5"

 include/linux/fsl_devices.h | 13 -
 1 file changed, 8 insertions(+), 5 deletions(-)

diff --git a/include/linux/fsl_devices.h b/include/linux/fsl_devices.h
index 2a2f56b..035ead7 100644
--- a/include/linux/fsl_devices.h
+++ b/include/linux/fsl_devices.h
@@ -20,11 +20,6 @@
 #define FSL_UTMI_PHY_DLY   10  /*As per P1010RM, delay for UTMI
PHY CLK to become stable - 10ms*/
 #define FSL_USB_PHY_CLK_TIMEOUT1   /* uSec */
-#define FSL_USB_VER_OLD0
-#define FSL_USB_VER_1_61
-#define FSL_USB_VER_2_22
-#define FSL_USB_VER_2_43
-#define FSL_USB_VER_2_54
 
 #include 
 
@@ -52,6 +47,14 @@
  *
  */
 
+enum fsl_usb2_controller_ver {
+   FSL_USB_VER_OLD,
+   FSL_USB_VER_1_6,
+   FSL_USB_VER_2_2,
+   FSL_USB_VER_2_4,
+   FSL_USB_VER_2_5,
+};
+
 enum fsl_usb2_operating_modes {
FSL_USB2_MPH_HOST,
FSL_USB2_DR_HOST,
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v4 01/11] block: make generic_make_request handle arbitrarily sized bios

[NeilBrown]

On Fri, 22 May 2015 11:18:33 -0700 Ming Lin  wrote:

> From: Kent Overstreet 
> 
> The way the block layer is currently written, it goes to great lengths
> to avoid having to split bios; upper layer code (such as bio_add_page())
> checks what the underlying device can handle and tries to always create
> bios that don't need to be split.
> 
> But this approach becomes unwieldy and eventually breaks down with
> stacked devices and devices with dynamic limits, and it adds a lot of
> complexity. If the block layer could split bios as needed, we could
> eliminate a lot of complexity elsewhere - particularly in stacked
> drivers. Code that creates bios can then create whatever size bios are
> convenient, and more importantly stacked drivers don't have to deal with
> both their own bio size limitations and the limitations of the
> (potentially multiple) devices underneath them.  In the future this will
> let us delete merge_bvec_fn and a bunch of other code.
> 
> We do this by adding calls to blk_queue_split() to the various
> make_request functions that need it - a few can already handle arbitrary
> size bios. Note that we add the call _after_ any call to
> blk_queue_bounce(); this means that blk_queue_split() and
> blk_recalc_rq_segments() don't need to be concerned with bouncing
> affecting segment merging.
> 
> Some make_request_fn() callbacks were simple enough to audit and verify
> they don't need blk_queue_split() calls. The skipped ones are:
> 
>  * nfhd_make_request (arch/m68k/emu/nfblock.c)
>  * axon_ram_make_request (arch/powerpc/sysdev/axonram.c)
>  * simdisk_make_request (arch/xtensa/platforms/iss/simdisk.c)
>  * brd_make_request (ramdisk - drivers/block/brd.c)
>  * mtip_submit_request (drivers/block/mtip32xx/mtip32xx.c)
>  * loop_make_request
>  * null_queue_bio
>  * bcache's make_request fns
> 
> Some others are almost certainly safe to remove now, but will be left
> for future patches.
> 
> Cc: Jens Axboe 
> Cc: Christoph Hellwig 
> Cc: Al Viro 
> Cc: Ming Lei 
> Cc: Neil Brown 
> Cc: Alasdair Kergon 
> Cc: Mike Snitzer 
> Cc: dm-de...@redhat.com
> Cc: Lars Ellenberg 
> Cc: drbd-u...@lists.linbit.com
> Cc: Jiri Kosina 
> Cc: Geoff Levand 
> Cc: Jim Paris 
> Cc: Joshua Morris 
> Cc: Philip Kelleher 
> Cc: Minchan Kim 
> Cc: Nitin Gupta 
> Cc: Oleg Drokin 
> Cc: Andreas Dilger 
> Signed-off-by: Kent Overstreet 
> [dpark: skip more mq-based drivers, resolve merge conflicts, etc.]
> Signed-off-by: Dongsu Park 
> Signed-off-by: Ming Lin 


Acked-by: NeilBrown 

For the 'md/md.c' bits.

Thanks,
NeilBrown


> ---
>  block/blk-core.c|  19 ++--
>  block/blk-merge.c   | 159 
> ++--
>  block/blk-mq.c  |   4 +
>  drivers/block/drbd/drbd_req.c   |   2 +
>  drivers/block/pktcdvd.c |   6 +-
>  drivers/block/ps3vram.c |   2 +
>  drivers/block/rsxx/dev.c|   2 +
>  drivers/block/umem.c|   2 +
>  drivers/block/zram/zram_drv.c   |   2 +
>  drivers/md/dm.c |   2 +
>  drivers/md/md.c |   2 +
>  drivers/s390/block/dcssblk.c|   2 +
>  drivers/s390/block/xpram.c  |   2 +
>  drivers/staging/lustre/lustre/llite/lloop.c |   2 +
>  include/linux/blkdev.h  |   3 +
>  15 files changed, 189 insertions(+), 22 deletions(-)
> 
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 7871603..fbbb337 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -619,6 +619,10 @@ struct request_queue *blk_alloc_queue_node(gfp_t 
> gfp_mask, int node_id)
>   if (q->id < 0)
>   goto fail_q;
>  
> + q->bio_split = bioset_create(BIO_POOL_SIZE, 0);
> + if (!q->bio_split)
> + goto fail_id;
> +
>   q->backing_dev_info.ra_pages =
>   (VM_MAX_READAHEAD * 1024) / PAGE_CACHE_SIZE;
>   q->backing_dev_info.state = 0;
> @@ -628,7 +632,7 @@ struct request_queue *blk_alloc_queue_node(gfp_t 
> gfp_mask, int node_id)
>  
>   err = bdi_init(>backing_dev_info);
>   if (err)
> - goto fail_id;
> + goto fail_split;
>  
>   setup_timer(>backing_dev_info.laptop_mode_wb_timer,
>   laptop_mode_timer_fn, (unsigned long) q);
> @@ -670,6 +674,8 @@ struct request_queue *blk_alloc_queue_node(gfp_t 
> gfp_mask, int node_id)
>  
>  fail_bdi:
>   bdi_destroy(>backing_dev_info);
> +fail_split:
> + bioset_free(q->bio_split);
>  fail_id:
>   ida_simple_remove(_queue_ida, q->id);
>  fail_q:
> @@ -1586,6 +1592,8 @@ void blk_queue_bio(struct request_queue *q, struct bio 
> *bio)
>   struct request *req;
>   unsigned int request_count = 0;
>  
> + blk_queue_split(q, , q->bio_split);
> +
>   /*
>* low level driver can indicate that it wants pages above a
>* certain limit bounced to low memory (ie for 

Re: [PATCH] locking: type cleanup when accessing fast_read_ctr

[Nicholas Mc Guire]

On Sun, 24 May 2015, Oleg Nesterov wrote:

> On 05/23, Nicholas Mc Guire wrote:
> >
> > On Wed, 20 May 2015, Oleg Nesterov wrote:
> >
> > > On 05/19, Nicholas Mc Guire wrote:
> > > >
> > > > I assumed it would not matter but did not see a simple way of getting it
> > > > type clean with unsigned either mainly due to the atomic_t being int and
> > > > val in update_fast_ctr() being passed as -1.
> > >
> > > Perhaps clear_fast_ctr() should have a comment to explain why it returns
> > > "int"... even if "unsigned" should work too.
> > >
> > Might not be into c99 standard far enough but from reviewing 6.5/J.2
> > I do not see this argument here.
> >
> > The "well defined modulo 2**n" behavior for unsigned int can be
> > found stated in a few places - but not in the c99 standard for
> > arithmetic overflow.
> >
> > The "well defined overflow behavior" as far as I understand c99,
> > *only* applies to left shift operations when overflowing - see 6.5.7 "
> > Bitwise shift operators" -> Semantics -> 4) -  further for the counter
> > problem this well defined behavior is of little help as the sum would
> > be wrong in both cases.
> >
> > I still do not see the point in the implicit/automatic type conversion
> > here and why that should be an advantage - could somone point me to
> > the right c99 clauses ?
> 
> Sorry, I don't really understand your question...
>
> Once again. Signed overflow is undefined behaviour according to C standard.
> That is why ->fast_read_ctr is "unsigned long", this counter can actually
> over/underflow if down/up happens on different CPU's.

that signed overflow is undefind is clear - just that unsigned overflow is
well defined is not clear - simply did not find this defined behavior for
unsigned int/long in c99 except for the bitshift operators. So my question
simply was where is the behavior on arithmetic overflow defined ? 

> 
> clear_fast_ctr() returns "signed int" just because this looks better to me,
> it can actually return the negative number. If you make it return "unsigned"
> you will simply shift this implicit/automatic type conversion to atomic_add()
> which accepts "int i".

yup - that is clear - which is one of the reasons why the conversion was 
towards int.

> 
> Let me also quote Linus:
> 
>   Now, I doubt you'll find an architecture or C compiler where this will
>   actually ever make a difference,
> 
> Yes. So this all is actually cosmetic.
>
If there is no simple way of getting it out - and there are sound reasons 
to do it this way then I'll just mark it as false positive. 
The intent of the patch was just to cleanup type conversions that did not 
really look necessary and simplify automatic code checking.

thanks for the clarification !

thx!
hofrat
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[v7 1/8] iommu: Add new member capability to struct irq_remap_ops

[Feng Wu]

This patch adds a new member capability to struct irq_remap_ops,
this new function ops can be used to check whether some
features are supported, such as VT-d Posted-Interrupts.

Signed-off-by: Feng Wu 
Reviewed-by: Jiang Liu 
---
 arch/x86/include/asm/irq_remapping.h | 4 
 drivers/iommu/irq_remapping.h| 3 +++
 2 files changed, 7 insertions(+)

diff --git a/arch/x86/include/asm/irq_remapping.h 
b/arch/x86/include/asm/irq_remapping.h
index 78974fb..0953723 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -31,6 +31,10 @@ struct irq_alloc_info;
 
 #ifdef CONFIG_IRQ_REMAP
 
+enum irq_remap_cap {
+   IRQ_POSTING_CAP = 0,
+};
+
 extern void set_irq_remapping_broken(void);
 extern int irq_remapping_prepare(void);
 extern int irq_remapping_enable(void);
diff --git a/drivers/iommu/irq_remapping.h b/drivers/iommu/irq_remapping.h
index 91d5a11..b6ca30d 100644
--- a/drivers/iommu/irq_remapping.h
+++ b/drivers/iommu/irq_remapping.h
@@ -35,6 +35,9 @@ extern int no_x2apic_optout;
 extern int irq_remapping_enabled;
 
 struct irq_remap_ops {
+   /* The supported capabilities */
+   int capability;
+
/* Initializes hardware and makes it ready for remapping interrupts */
int  (*prepare)(void);
 
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[v7 5/8] iommu, x86: Add cap_pi_support() to detect VT-d PI capability

[Feng Wu]

Add helper function to detect VT-d Posted-Interrupts capability.

Signed-off-by: Feng Wu 
Reviewed-by: Jiang Liu 
Acked-by: David Woodhouse 
---
 include/linux/intel-iommu.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/linux/intel-iommu.h b/include/linux/intel-iommu.h
index 0af9b03..0c251be 100644
--- a/include/linux/intel-iommu.h
+++ b/include/linux/intel-iommu.h
@@ -87,6 +87,7 @@ static inline void dmar_writeq(void __iomem *addr, u64 val)
 /*
  * Decoding Capability Register
  */
+#define cap_pi_support(c)  (((c) >> 59) & 1)
 #define cap_read_drain(c)  (((c) >> 55) & 1)
 #define cap_write_drain(c) (((c) >> 54) & 1)
 #define cap_max_amask_val(c)   (((c) >> 48) & 0x3f)
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[v7 2/8] iommu: dmar: Extend struct irte for VT-d Posted-Interrupts

[Feng Wu]

From: Thomas Gleixner 

The IRTE (Interrupt Remapping Table Entry) is either an entry for
remapped or for posted interrupts. The hardware distiguishes between
remapped and posted entries by bit 15 in the low 64 bit of the
IRTE. If cleared the entry is remapped, if set it's posted.

The entries have common fields and dependent on the posted bit fields
with different meanings.

Extend struct irte to handle the differences between remap and posted
mode by having three structs in the unions:

- Shared
- Remapped
- Posted

Signed-off-by: Thomas Gleixner 
Signed-off-by: Feng Wu 
---
 include/linux/dmar.h | 70 +---
 1 file changed, 55 insertions(+), 15 deletions(-)

diff --git a/include/linux/dmar.h b/include/linux/dmar.h
index 8473756..0dbcabc 100644
--- a/include/linux/dmar.h
+++ b/include/linux/dmar.h
@@ -185,33 +185,73 @@ static inline int dmar_device_remove(void *handle)
 
 struct irte {
union {
+   /* Shared between remapped and posted mode*/
struct {
-   __u64   present : 1,
-   fpd : 1,
-   dst_mode: 1,
-   redir_hint  : 1,
-   trigger_mode: 1,
-   dlvry_mode  : 3,
-   avail   : 4,
-   __reserved_1: 4,
-   vector  : 8,
-   __reserved_2: 8,
-   dest_id : 32;
+   __u64   present : 1,  /*  0  */
+   fpd : 1,  /*  1  */
+   __res0  : 6,  /*  2 -  6 */
+   avail   : 4,  /*  8 - 11 */
+   __res1  : 3,  /* 12 - 14 */
+   pst : 1,  /* 15  */
+   vector  : 8,  /* 16 - 23 */
+   __res2  : 40; /* 24 - 63 */
+   };
+
+   /* Remapped mode */
+   struct {
+   __u64   r_present   : 1,  /*  0  */
+   r_fpd   : 1,  /*  1  */
+   dst_mode: 1,  /*  2  */
+   redir_hint  : 1,  /*  3  */
+   trigger_mode: 1,  /*  4  */
+   dlvry_mode  : 3,  /*  5 -  7 */
+   r_avail : 4,  /*  8 - 11 */
+   r_res0  : 4,  /* 12 - 15 */
+   r_vector: 8,  /* 16 - 23 */
+   r_res1  : 8,  /* 24 - 31 */
+   dest_id : 32; /* 32 - 63 */
+   };
+
+   /* Posted mode */
+   struct {
+   __u64   p_present   : 1,  /*  0  */
+   p_fpd   : 1,  /*  1  */
+   p_res0  : 6,  /*  2 -  7 */
+   p_avail : 4,  /*  8 - 11 */
+   p_res1  : 2,  /* 12 - 13 */
+   p_urgent: 1,  /* 14  */
+   p_pst   : 1,  /* 15  */
+   p_vector: 8,  /* 16 - 23 */
+   p_res2  : 14, /* 24 - 37 */
+   pda_l   : 26; /* 38 - 63 */
};
__u64 low;
};
 
union {
+   /* Shared between remapped and posted mode*/
struct {
-   __u64   sid : 16,
-   sq  : 2,
-   svt : 2,
-   __reserved_3: 44;
+   __u64   sid : 16,  /* 64 - 79  */
+   sq  : 2,   /* 80 - 81  */
+   svt : 2,   /* 82 - 83  */
+   __res3  : 44;  /* 84 - 127 */
+   };
+
+   /* Posted mode*/
+   struct {
+   __u64   p_sid   : 16,  /* 64 - 79  */
+   p_sq: 2,   /* 80 - 81  */
+   p_svt   : 2,   /* 82 - 83  */
+   p_res3  : 12,  /* 84 - 95  */
+   pda_h   : 32;  /* 96 - 127 */
};
__u64 high;
};
 };
 
+#define PDA_LOW_BIT26
+#define PDA_HIGH_BIT   32
+
 

Re: [PATCH 1/3 v3] drivers: hwspinlock: add CSR atlas7 implementation

[Barry Song]

2015-05-23 6:51 GMT+08:00 Suman Anna :
> Hi Barry,
>
> On 05/19/2015 01:41 AM, Barry Song wrote:
>> From: Wei Chen 
>>
>> Add hwspinlock support for the CSR atlas7 SoC.
>>
>> The Hardware Spinlock device on atlas7 provides hardware assistance
>> for synchronization between the multiple processors in the system
>> (dual Cortex-A7, CAN bus Cortex-M3 and audio DSP).
>>
>> Cc: Suman Anna 
>> Cc: Bjorn Andersson 
>> Signed-off-by: Wei Chen 
>> Signed-off-by: Barry Song 
>> ---
>>  -v3:
>>  use #hwlock-cells and general hwspinlock dt-binding;
>>  drop relax();
>>  drop num-spinlocks in dts;
>>  re-order Kconfig and Makefile;
>>  other codingstyle issues.
>>  Thanks Suman, Bjorn and Ohad
>>
>>  drivers/hwspinlock/Kconfig   |  12 
>>  drivers/hwspinlock/Makefile  |   1 +
>>  drivers/hwspinlock/sirf_hwspinlock.c | 135 
>> +++
>>  3 files changed, 148 insertions(+)
>>  create mode 100644 drivers/hwspinlock/sirf_hwspinlock.c
>>
>> diff --git a/drivers/hwspinlock/Kconfig b/drivers/hwspinlock/Kconfig
>> index b5b4f52..73a4016 100644
>> --- a/drivers/hwspinlock/Kconfig
>> +++ b/drivers/hwspinlock/Kconfig
>> @@ -30,6 +30,18 @@ config HWSPINLOCK_QCOM
>>
>> If unsure, say N.
>>
>> +config HWSPINLOCK_SIRF
>> + tristate "SIRF Hardware Spinlock device"
>> + depends on ARCH_SIRF
>> + select HWSPINLOCK
>> + help
>> +   Say y here to support the SIRF Hardware Spinlock device, which
>> +   provides a synchronisation mechanism for the various processors
>> +   on the SoC.
>> +
>> +   It's safe to say n here if you're not interested in SIRF hardware
>> +   spinlock or just want a bare minimum kernel.
>> +
>>  config HSEM_U8500
>>   tristate "STE Hardware Semaphore functionality"
>>   depends on ARCH_U8500
>> diff --git a/drivers/hwspinlock/Makefile b/drivers/hwspinlock/Makefile
>> index 68f95d9..6b59cb5a 100644
>> --- a/drivers/hwspinlock/Makefile
>> +++ b/drivers/hwspinlock/Makefile
>> @@ -5,4 +5,5 @@
>>  obj-$(CONFIG_HWSPINLOCK) += hwspinlock_core.o
>>  obj-$(CONFIG_HWSPINLOCK_OMAP)+= omap_hwspinlock.o
>>  obj-$(CONFIG_HWSPINLOCK_QCOM)+= qcom_hwspinlock.o
>> +obj-$(CONFIG_HWSPINLOCK_SIRF)+= sirf_hwspinlock.o
>>  obj-$(CONFIG_HSEM_U8500) += u8500_hsem.o
>> diff --git a/drivers/hwspinlock/sirf_hwspinlock.c 
>> b/drivers/hwspinlock/sirf_hwspinlock.c
>> new file mode 100644
>> index 000..e7e5ba6
>> --- /dev/null
>> +++ b/drivers/hwspinlock/sirf_hwspinlock.c
>> @@ -0,0 +1,135 @@
>> +/*
>> + * SIRF hardware spinlock driver
>> + *
>> + * Copyright (c) 2014 Cambridge Silicon Radio Limited, a CSR plc group 
>> company.
>
> Not sure on this, but 2015 is here and now..
>
>> + *
>> + * Licensed under GPLv2.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +#include "hwspinlock_internal.h"
>> +
>> +struct sirf_hwspinlock {
>> + void __iomem *io_base;
>> + struct hwspinlock_device bank;
>> +};
>> +
>> +/* Number of Hardware Spinlocks*/
>> +#define  HW_SPINLOCK_NUMBER  30
>> +
>> +/* Hardware spinlock register offsets */
>> +#define HW_SPINLOCK_BASE 0x404
>> +#define HW_SPINLOCK_OFFSET(x)(HW_SPINLOCK_BASE + 0x4 * (x))
>> +
>> +static int sirf_hwspinlock_trylock(struct hwspinlock *lock)
>> +{
>> + void __iomem *lock_addr = lock->priv;
>> +
>> + /* attempt to acquire the lock by reading value == 1 from it */
>> + return !!readl(lock_addr);
>> +}
>> +
>> +static void sirf_hwspinlock_unlock(struct hwspinlock *lock)
>> +{
>> + void __iomem *lock_addr = lock->priv;
>> +
>> + /* release the lock by writing 0 to it */
>> + writel(0, lock_addr);
>> +}
>> +
>> +static const struct hwspinlock_ops sirf_hwspinlock_ops = {
>> + .trylock = sirf_hwspinlock_trylock,
>> + .unlock = sirf_hwspinlock_unlock,
>> +};
>> +
>> +static int sirf_hwspinlock_probe(struct platform_device *pdev)
>> +{
>> + struct sirf_hwspinlock *hwspin;
>> + struct hwspinlock *hwlock;
>> + int idx, ret;
>> +
>> + if (!pdev->dev.of_node)
>> + return -ENODEV;
>> +
>> + hwspin = devm_kzalloc(>dev, sizeof(*hwspin) +
>> + sizeof(*hwlock) * HW_SPINLOCK_NUMBER, GFP_KERNEL);
>> + if (!hwspin)
>> + return -ENOMEM;
>> +
>> + /* retrieve io base */
>> + hwspin->io_base = of_iomap(pdev->dev.of_node, 0);
>> + if (!hwspin->io_base)
>> + ret = -ENOMEM;
>
> You are missing the bail out here.

real. it should be "return -ENOMEM"

>
>> +
>> + for (idx = 0; idx < HW_SPINLOCK_NUMBER; idx++) {
>> + hwlock = >bank.lock[idx];
>> + hwlock->priv = hwspin->io_base + HW_SPINLOCK_OFFSET(idx);
>> + }
>> +
>> + platform_set_drvdata(pdev, hwspin);
>> +
>> + pm_runtime_enable(>dev);
>> +
>> + ret = hwspin_lock_register(>bank, 

[v7 4/8] iommu, x86: No need to migrating irq for VT-d Posted-Interrupts

[Feng Wu]

We don't need to migrate the irqs for VT-d Posted-Interrupts here.
When 'pst' is set in IRTE, the associated irq will be posted to
guests instead of interrupt remapping. The destination of the
interrupt is set in Posted-Interrupts Descriptor, and the migration
happens during vCPU scheduling.

However, we still update the cached irte here, which can be used
when changing back to remapping mode.

Signed-off-by: Feng Wu 
Reviewed-by: Jiang Liu 
Acked-by: David Woodhouse 
---
 drivers/iommu/intel_irq_remapping.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/intel_irq_remapping.c 
b/drivers/iommu/intel_irq_remapping.c
index 1955b09..646f4cf 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -994,7 +994,10 @@ intel_ir_set_affinity(struct irq_data *data, const struct 
cpumask *mask,
 */
irte->vector = cfg->vector;
irte->dest_id = IRTE_DEST(cfg->dest_apicid);
-   modify_irte(_data->irq_2_iommu, irte);
+
+   /* We don't need to modify irte if the interrupt is for posting. */
+   if (irte->pst != 1)
+   modify_irte(_data->irq_2_iommu, irte);
 
/*
 * After this point, all the interrupts will start arriving
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[v7 7/8] iommu, x86: define irq_remapping_cap()

[Feng Wu]

This patch adds a new interface irq_remapping_cap() to detect
whether irq remapping supports new features, such as VT-d
Posted-Interrupts. We export this function out, so that KVM
code can check this and use this mechanism properly.

Signed-off-by: Feng Wu 
Reviewed-by: Jiang Liu 
---
 arch/x86/include/asm/irq_remapping.h | 2 ++
 drivers/iommu/irq_remapping.c| 9 +
 2 files changed, 11 insertions(+)

diff --git a/arch/x86/include/asm/irq_remapping.h 
b/arch/x86/include/asm/irq_remapping.h
index 202e040..61aa8ad 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -35,6 +35,7 @@ enum irq_remap_cap {
IRQ_POSTING_CAP = 0,
 };
 
+extern bool irq_remapping_cap(enum irq_remap_cap cap);
 extern void set_irq_remapping_broken(void);
 extern int irq_remapping_prepare(void);
 extern int irq_remapping_enable(void);
@@ -64,6 +65,7 @@ struct vcpu_data {
 
 #else  /* CONFIG_IRQ_REMAP */
 
+static bool irq_remapping_cap(enum irq_remap_cap cap) { return 0; }
 static inline void set_irq_remapping_broken(void) { }
 static inline int irq_remapping_prepare(void) { return -ENODEV; }
 static inline int irq_remapping_enable(void) { return -ENODEV; }
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index ed605a9..2d99930 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -81,6 +81,15 @@ void set_irq_remapping_broken(void)
irq_remap_broken = 1;
 }
 
+bool irq_remapping_cap(enum irq_remap_cap cap)
+{
+   if (!remap_ops || disable_irq_post)
+   return 0;
+
+   return (remap_ops->capability & (1 << cap));
+}
+EXPORT_SYMBOL_GPL(irq_remapping_cap);
+
 int __init irq_remapping_prepare(void)
 {
if (disable_irq_remap)
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[v7 3/8] iommu, x86: Implement irq_set_vcpu_affinity for intel_ir_chip

[Feng Wu]

Implement irq_set_vcpu_affinity for intel_ir_chip.

Signed-off-by: Feng Wu 
Reviewed-by: Jiang Liu 
Acked-by: David Woodhouse 
---
 arch/x86/include/asm/irq_remapping.h |  5 
 drivers/iommu/intel_irq_remapping.c  | 46 
 2 files changed, 51 insertions(+)

diff --git a/arch/x86/include/asm/irq_remapping.h 
b/arch/x86/include/asm/irq_remapping.h
index 0953723..202e040 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -57,6 +57,11 @@ static inline struct irq_domain 
*arch_get_ir_parent_domain(void)
return x86_vector_domain;
 }
 
+struct vcpu_data {
+   u64 pi_desc_addr;   /* Physical address of PI Descriptor */
+   u32 vector; /* Guest vector of the interrupt */
+};
+
 #else  /* CONFIG_IRQ_REMAP */
 
 static inline void set_irq_remapping_broken(void) { }
diff --git a/drivers/iommu/intel_irq_remapping.c 
b/drivers/iommu/intel_irq_remapping.c
index 8fad71c..1955b09 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -42,6 +42,7 @@ struct irq_2_iommu {
 struct intel_ir_data {
struct irq_2_iommu  irq_2_iommu;
struct irte irte_entry;
+   struct irte irte_pi_entry;
union {
struct msi_msg  msi_entry;
};
@@ -1013,10 +1014,55 @@ static void intel_ir_compose_msi_msg(struct irq_data 
*irq_data,
*msg = ir_data->msi_entry;
 }
 
+static int intel_ir_set_vcpu_affinity(struct irq_data *data, void *vcpu_info)
+{
+   struct intel_ir_data *ir_data = data->chip_data;
+   struct irte *irte_pi = _data->irte_pi_entry;
+   struct vcpu_data *vcpu_pi_info;
+
+   /* stop posting interrupts, back to remapping mode */
+   if (!vcpu_info) {
+   modify_irte(_data->irq_2_iommu, _data->irte_entry);
+   } else {
+   vcpu_pi_info = (struct vcpu_data *)vcpu_info;
+
+   /*
+* "ir_data->irte_entry" saves the remapped format of IRTE,
+* which being a cached irte is still updated when setting
+* the affinity even when we are in posted mode. So this make
+* it possible to switch back to remapped mode from posted mode,
+* we can just set "ir_data->irte_entry" to hardware for that
+* purpose. Here we store the posted format of IRTE in another
+* new member "ir_data->irte_pi_entry" to not corrupt
+* "ir_data->irte_entry".
+*/
+   memcpy(irte_pi, _data->irte_entry, sizeof(struct irte));
+
+   irte_pi->p_urgent = 0;
+   irte_pi->p_vector = vcpu_pi_info->vector;
+   irte_pi->pda_l = (vcpu_pi_info->pi_desc_addr >>
+(32 - PDA_LOW_BIT)) & ~(-1UL << PDA_LOW_BIT);
+   irte_pi->pda_h = (vcpu_pi_info->pi_desc_addr >> 32) &
+~(-1UL << PDA_HIGH_BIT);
+
+   irte_pi->p_res0 = 0;
+   irte_pi->p_res1 = 0;
+   irte_pi->p_res2 = 0;
+   irte_pi->p_res3 = 0;
+
+   irte_pi->p_pst = 1;
+
+   modify_irte(_data->irq_2_iommu, irte_pi);
+   }
+
+   return 0;
+}
+
 static struct irq_chip intel_ir_chip = {
.irq_ack = ir_ack_apic_edge,
.irq_set_affinity = intel_ir_set_affinity,
.irq_compose_msi_msg = intel_ir_compose_msi_msg,
+   .irq_set_vcpu_affinity = intel_ir_set_vcpu_affinity,
 };
 
 static void intel_irq_remapping_prepare_irte(struct intel_ir_data *data,
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[v7 6/8] iommu, x86: Setup Posted-Interrupts capability for Intel iommu

[Feng Wu]

Set Posted-Interrupts capability for Intel iommu when IR is enabled,
clear it when IR is disabled.

Signed-off-by: Feng Wu 
---
 drivers/iommu/intel_irq_remapping.c | 30 ++
 drivers/iommu/irq_remapping.c   |  2 ++
 drivers/iommu/irq_remapping.h   |  3 +++
 3 files changed, 35 insertions(+)

diff --git a/drivers/iommu/intel_irq_remapping.c 
b/drivers/iommu/intel_irq_remapping.c
index 646f4cf..9f7f378 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -572,6 +572,26 @@ error:
return -ENODEV;
 }
 
+/*
+ * Set Posted-Interrupts capability.
+ */
+static inline void set_irq_posting_cap(void)
+{
+   struct dmar_drhd_unit *drhd;
+   struct intel_iommu *iommu;
+
+   if (!disable_irq_post) {
+   intel_irq_remap_ops.capability |= 1 << IRQ_POSTING_CAP;
+
+   for_each_iommu(iommu, drhd)
+   if (!cap_pi_support(iommu->cap)) {
+   intel_irq_remap_ops.capability &=
+   ~(1 << IRQ_POSTING_CAP);
+   break;
+   }
+   }
+}
+
 static int __init intel_enable_irq_remapping(void)
 {
struct dmar_drhd_unit *drhd;
@@ -647,6 +667,8 @@ static int __init intel_enable_irq_remapping(void)
 
irq_remapping_enabled = 1;
 
+   set_irq_posting_cap();
+
pr_info("Enabled IRQ remapping in %s mode\n", eim ? "x2apic" : "xapic");
 
return eim ? IRQ_REMAP_X2APIC_MODE : IRQ_REMAP_XAPIC_MODE;
@@ -847,6 +869,12 @@ static void disable_irq_remapping(void)
 
iommu_disable_irq_remapping(iommu);
}
+
+   /*
+* Clear Posted-Interrupts capability.
+*/
+   if (!disable_irq_post)
+   intel_irq_remap_ops.capability &= ~(1 << IRQ_POSTING_CAP);
 }
 
 static int reenable_irq_remapping(int eim)
@@ -874,6 +902,8 @@ static int reenable_irq_remapping(int eim)
if (!setup)
goto error;
 
+   set_irq_posting_cap();
+
return 0;
 
 error:
diff --git a/drivers/iommu/irq_remapping.c b/drivers/iommu/irq_remapping.c
index fc78b0d..ed605a9 100644
--- a/drivers/iommu/irq_remapping.c
+++ b/drivers/iommu/irq_remapping.c
@@ -22,6 +22,8 @@ int irq_remap_broken;
 int disable_sourceid_checking;
 int no_x2apic_optout;
 
+int disable_irq_post = 1;
+
 static int disable_irq_remap;
 static struct irq_remap_ops *remap_ops;
 
diff --git a/drivers/iommu/irq_remapping.h b/drivers/iommu/irq_remapping.h
index b6ca30d..039c7af 100644
--- a/drivers/iommu/irq_remapping.h
+++ b/drivers/iommu/irq_remapping.h
@@ -34,6 +34,8 @@ extern int disable_sourceid_checking;
 extern int no_x2apic_optout;
 extern int irq_remapping_enabled;
 
+extern int disable_irq_post;
+
 struct irq_remap_ops {
/* The supported capabilities */
int capability;
@@ -69,6 +71,7 @@ extern void ir_ack_apic_edge(struct irq_data *data);
 
 #define irq_remapping_enabled 0
 #define irq_remap_broken  0
+#define disable_irq_post  1
 
 #endif /* CONFIG_IRQ_REMAP */
 
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[v7 8/8] iommu, x86: Properly handler PI for IOMMU hotplug

[Feng Wu]

Return error when inserting a new IOMMU which doesn't support PI
if PI is currently in use.

Signed-off-by: Feng Wu 
---
 drivers/iommu/intel_irq_remapping.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/iommu/intel_irq_remapping.c 
b/drivers/iommu/intel_irq_remapping.c
index 9f7f378..79ca56e 100644
--- a/drivers/iommu/intel_irq_remapping.c
+++ b/drivers/iommu/intel_irq_remapping.c
@@ -1354,6 +1354,9 @@ int dmar_ir_hotplug(struct dmar_drhd_unit *dmaru, bool 
insert)
return -EINVAL;
if (!ecap_ir_support(iommu->ecap))
return 0;
+   if (irq_remapping_cap(IRQ_POSTING_CAP) &&
+   !cap_pi_support(iommu->cap))
+   return -EBUSY;
 
if (insert) {
if (!iommu->ir_table)
-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[v7 0/8] Add VT-d Posted-Interrupts support - IOMMU part

[Feng Wu]

VT-d Posted-Interrupts is an enhancement to CPU side Posted-Interrupt.
With VT-d Posted-Interrupts enabled, external interrupts from
direct-assigned devices can be delivered to guests without VMM
intervention when guest is running in non-root mode.

You can find the VT-d Posted-Interrtups Spec. in the following URL:
http://www.intel.com/content/www/us/en/intelligent-systems/intel-technology/vt-directed-io-spec.html

This series was part of http://thread.gmane.org/gmane.linux.kernel.iommu/7708. 
To make things clear, send out IOMMU part here.

This patch-set is based on the lastest x86/apic branch of tip tree.

Divide the whole series which contain multiple components into three parts:
- Prerequisite changes to irq subsystem (already merged in tip tree x86/apic 
branch)
- IOMMU part (in this series)
- KVM and VFIO parts (will send out this part once the first two parts are 
accepted)

v6->v7:
* Add an static inline helper function set_irq_posting_cap() to set
the PI capability.
* Add some comments for the new member "ir_data->irte_pi_entry".

v5->v6:
* Extend 'struct irte' for VT-d Posted-Interrupts, combine remapped
and posted mode into one irte structure.

v4->v5:
* Abstract modify_irte() to accept two format of irte.

v3->v4:
* Change capability to a int variant flags instead of a function call.
* Add hotplug case for VT-d PI.

Feng Wu (7):
  iommu: Add new member capability to struct irq_remap_ops
  iommu, x86: Implement irq_set_vcpu_affinity for intel_ir_chip
  iommu, x86: No need to migrating irq for VT-d Posted-Interrupts
  iommu, x86: Add cap_pi_support() to detect VT-d PI capability
  iommu, x86: Setup Posted-Interrupts capability for Intel iommu
  iommu, x86: define irq_remapping_cap()
  iommu, x86: Properly handler PI for IOMMU hotplug

Thomas Gleixner (1):
  iommu: dmar: Extend struct irte for VT-d Posted-Interrupts

 arch/x86/include/asm/irq_remapping.h | 11 +
 drivers/iommu/intel_irq_remapping.c  | 84 +++-
 drivers/iommu/irq_remapping.c| 11 +
 drivers/iommu/irq_remapping.h|  6 +++
 include/linux/dmar.h | 70 +++---
 include/linux/intel-iommu.h  |  1 +
 6 files changed, 167 insertions(+), 16 deletions(-)

-- 
2.1.0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/3 v3] Documentation: dt: add the CSR atlas7 hwspinlock bindings document

[Barry Song]

2015-05-23 6:44 GMT+08:00 Suman Anna :
> Hi Barry,
>
> On 05/19/2015 01:41 AM, Barry Song wrote:
>> From: Wei Chen 
>>
>> The Hardware Spinlock device on atlas7 provides hardware assistance
>> for synchronization between the multiple processors in the system
>> (dual Cortex-A7, CAN bus Cortex-M3 and audio DSP).
>> This patch adds the DT bindings information for this hwspinlock
>> module.
>>
>> Cc: Suman Anna 
>> Cc: Bjorn Andersson 
>> Signed-off-by: Wei Chen 
>> Signed-off-by: Barry Song 
>> ---
>>  .../devicetree/bindings/hwlock/sirf,hwspinlock.txt | 25 
>> ++
>>  1 file changed, 25 insertions(+)
>>  create mode 100644 
>> Documentation/devicetree/bindings/hwlock/sirf,hwspinlock.txt
>>
>> diff --git a/Documentation/devicetree/bindings/hwlock/sirf,hwspinlock.txt 
>> b/Documentation/devicetree/bindings/hwlock/sirf,hwspinlock.txt
>> new file mode 100644
>> index 000..cc6d351
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/hwlock/sirf,hwspinlock.txt
>> @@ -0,0 +1,25 @@
>> +SIRF Hardware spinlock device Binding
>> +---
>> +
>> +Required properties :
>> +- compatible : shall contain only one of the following:
>> + "sirf,hwspinlock"
>> +
>> +- reg : the register address of hwspinlock
>
> Also suggest to document the value to be used for #hwlock-cells, the
> generic hwlock binding does not mention that.

do you think whether we can put one line like?

#hwlock-cells : <1>, as required by generic hwspinlock binding.
>
>> +
>> +Please look at the generic hwlock binding for usage information for 
>> consumers,
>> +"Documentation/devicetree/bindings/hwlock/hwlock.txt"
>> +
>
> regards
> Suman
>

-barry
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC V7 PATCH 6/7] vhost: interrupt coalescing support

[Jason Wang]

This patch implements basic interrupt coalescing support. This is done
by introducing two new per virtqueue parameters:

- max_coalescced_buffers: maximum number of buffers before trying to
  issue an interrupt.
- coalesce_usecs: maximum number of microseconds waited if at least
  one buffer is pending before trying to issue an interrupt.

A new ioctl was also introduced for userspace to set or get the above
two values.

The number of coalesced buffers were increased in vhost_add_used_n()
and vhost_signal() was modified that it will only try to issue an
interrupt when:

- The number of coalesced buffers exceed or is equal to
  max_coalesced_buffes.
- The time since last signal trying exceed or is equal to
  coalesce_usecs.

When neither of the above two conditions were met, the interrupt was
delayed and during exit of a round of processing, device specific code
will call vhost_check_coalesce_and_signal() to check the above two
conditions again and schedule a timer for delayed interrupt if the
conditions were still not met.

Signed-off-by: Jason Wang 
---
 drivers/vhost/vhost.c  | 88 --
 drivers/vhost/vhost.h  | 20 +++
 include/uapi/linux/vhost.h | 13 ++-
 3 files changed, 117 insertions(+), 4 deletions(-)

diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
index 2ee2826..7739112 100644
--- a/drivers/vhost/vhost.c
+++ b/drivers/vhost/vhost.c
@@ -199,6 +199,11 @@ static void vhost_vq_reset(struct vhost_dev *dev,
vq->call = NULL;
vq->log_ctx = NULL;
vq->memory = NULL;
+   vq->coalesce_usecs = ktime_set(0, 0);
+   vq->max_coalesced_buffers = 0;
+   vq->coalesced = 0;
+   vq->last_signal = ktime_get();
+   hrtimer_cancel(>ctimer);
 }
 
 static int vhost_worker(void *data)
@@ -291,6 +296,23 @@ static void vhost_dev_free_iovecs(struct vhost_dev *dev)
vhost_vq_free_iovecs(dev->vqs[i]);
 }
 
+void vhost_check_coalesce_and_signal(struct vhost_dev *dev,
+struct vhost_virtqueue *vq,
+   bool timer);
+static enum hrtimer_restart vhost_ctimer_handler(struct hrtimer *timer)
+{
+   struct vhost_virtqueue *vq =
+   container_of(timer, struct vhost_virtqueue, ctimer);
+
+   if (mutex_trylock(>mutex)) {
+   vhost_check_coalesce_and_signal(vq->dev, vq, false);
+   mutex_unlock(>mutex);
+   } else
+   vhost_poll_queue(>poll);
+
+   return HRTIMER_NORESTART;
+}
+
 void vhost_dev_init(struct vhost_dev *dev,
struct vhost_virtqueue **vqs, int nvqs)
 {
@@ -315,6 +337,8 @@ void vhost_dev_init(struct vhost_dev *dev,
vq->heads = NULL;
vq->dev = dev;
mutex_init(>mutex);
+   hrtimer_init(>ctimer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
+   vq->ctimer.function = vhost_ctimer_handler;
vhost_vq_reset(dev, vq);
if (vq->handle_kick)
vhost_poll_init(>poll, vq->handle_kick,
@@ -640,6 +664,7 @@ long vhost_vring_ioctl(struct vhost_dev *d, int ioctl, void 
__user *argp)
struct vhost_vring_state s;
struct vhost_vring_file f;
struct vhost_vring_addr a;
+   struct vhost_vring_coalesce c;
u32 idx;
long r;
 
@@ -696,6 +721,19 @@ long vhost_vring_ioctl(struct vhost_dev *d, int ioctl, 
void __user *argp)
if (copy_to_user(argp, , sizeof s))
r = -EFAULT;
break;
+   case VHOST_SET_VRING_COALESCE:
+   if (copy_from_user(, argp, sizeof c)) {
+   r = -EFAULT;
+   break;
+   }
+   vq->coalesce_usecs = ns_to_ktime(c.coalesce_usecs * 
NSEC_PER_USEC) ;
+   vq->max_coalesced_buffers = c.max_coalesced_buffers;
+   break;
+   case VHOST_GET_VRING_COALESCE:
+   s.index = idx;
+   if (copy_to_user(argp, , sizeof c))
+   r = -EFAULT;
+   break;
case VHOST_SET_VRING_ADDR:
if (copy_from_user(, argp, sizeof a)) {
r = -EFAULT;
@@ -1415,6 +1453,9 @@ int vhost_add_used_n(struct vhost_virtqueue *vq, struct 
vring_used_elem *heads,
 {
int start, n, r;
 
+   if (vq->max_coalesced_buffers && ktime_to_ns(vq->coalesce_usecs))
+   vq->coalesced += count;
+
start = vq->last_used_idx % vq->num;
n = vq->num - start;
if (n < count) {
@@ -1440,6 +1481,7 @@ int vhost_add_used_n(struct vhost_virtqueue *vq, struct 
vring_used_elem *heads,
if (vq->log_ctx)
eventfd_signal(vq->log_ctx, 1);
}
+
return r;
 }
 EXPORT_SYMBOL_GPL(vhost_add_used_n);
@@ -1481,15 +1523,55 @@ static bool vhost_notify(struct vhost_dev *dev, struct 
vhost_virtqueue *vq)
return 

[RFC V7 PATCH 7/7] vhost_net: add interrupt coalescing support

[Jason Wang]

Signed-off-by: Jason Wang 
---
 drivers/vhost/net.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
index 7d137a4..5ee28b7 100644
--- a/drivers/vhost/net.c
+++ b/drivers/vhost/net.c
@@ -320,6 +320,9 @@ static void handle_tx(struct vhost_net *net)
hdr_size = nvq->vhost_hlen;
zcopy = nvq->ubufs;
 
+   /* Finish pending interrupts first */
+   vhost_check_coalesce_and_signal(vq->dev, vq, false);
+
for (;;) {
/* Release DMAs done buffers first */
if (zcopy)
@@ -415,6 +418,7 @@ static void handle_tx(struct vhost_net *net)
}
}
 out:
+   vhost_check_coalesce_and_signal(vq->dev, vq, true);
mutex_unlock(>mutex);
 }
 
@@ -554,6 +558,9 @@ static void handle_rx(struct vhost_net *net)
vq->log : NULL;
mergeable = vhost_has_feature(vq, VIRTIO_NET_F_MRG_RXBUF);
 
+   /* Finish pending interrupts first */
+   vhost_check_coalesce_and_signal(vq->dev, vq, false);
+
while ((sock_len = peek_head_len(sock->sk))) {
sock_len += sock_hlen;
vhost_len = sock_len + vhost_hlen;
@@ -638,6 +645,7 @@ static void handle_rx(struct vhost_net *net)
}
}
 out:
+   vhost_check_coalesce_and_signal(vq->dev, vq, true);
mutex_unlock(>mutex);
 }
 
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC V7 PATCH 1/7] virito-pci: add coalescing parameters setting

[Jason Wang]

This patch introduces a transport specific methods to set or get the
coalescing parameters and implement the pci methods.

Signed-off-by: Jason Wang 
---
 drivers/virtio/virtio_pci_modern.c | 15 +++
 include/linux/virtio_config.h  |  8 
 include/uapi/linux/virtio_pci.h|  4 
 3 files changed, 27 insertions(+)

diff --git a/drivers/virtio/virtio_pci_modern.c 
b/drivers/virtio/virtio_pci_modern.c
index e88e099..ce801ae 100644
--- a/drivers/virtio/virtio_pci_modern.c
+++ b/drivers/virtio/virtio_pci_modern.c
@@ -266,6 +266,16 @@ static void vp_set_status(struct virtio_device *vdev, u8 
status)
vp_iowrite8(status, _dev->common->device_status);
 }
 
+static void vp_set_coalesce(struct virtio_device *vdev, int n,
+   u32 coalesce_count, u32 coalesce_us)
+{
+   struct virtio_pci_device *vp_dev = to_vp_device(vdev);
+
+   iowrite16(n, _dev->common->queue_select);
+   iowrite32(coalesce_count, _dev->common->queue_coalesce_count);
+   iowrite32(coalesce_us, _dev->common->queue_coalesce_us);
+}
+
 static void vp_reset(struct virtio_device *vdev)
 {
struct virtio_pci_device *vp_dev = to_vp_device(vdev);
@@ -481,6 +491,7 @@ static const struct virtio_config_ops virtio_pci_config_ops 
= {
.generation = vp_generation,
.get_status = vp_get_status,
.set_status = vp_set_status,
+   .set_coalesce   = vp_set_coalesce,
.reset  = vp_reset,
.find_vqs   = vp_modern_find_vqs,
.del_vqs= vp_del_vqs,
@@ -588,6 +599,10 @@ static inline void check_offsets(void)
 offsetof(struct virtio_pci_common_cfg, queue_used_lo));
BUILD_BUG_ON(VIRTIO_PCI_COMMON_Q_USEDHI !=
 offsetof(struct virtio_pci_common_cfg, queue_used_hi));
+   BUILD_BUG_ON(VIRTIO_PCI_COMMON_Q_COALESCE_C !=
+   offsetof(struct virtio_pci_common_cfg, queue_coalesce_count));
+   BUILD_BUG_ON(VIRTIO_PCI_COMMON_Q_COALESCE_U !=
+   offsetof(struct virtio_pci_common_cfg, queue_coalesce_us));
 }
 
 /* the PCI probing function */
diff --git a/include/linux/virtio_config.h b/include/linux/virtio_config.h
index 1e306f7..d100c32 100644
--- a/include/linux/virtio_config.h
+++ b/include/linux/virtio_config.h
@@ -28,6 +28,12 @@
  * @set_status: write the status byte
  * vdev: the virtio_device
  * status: the new status byte
+ * @set_coalesce: set coalescing parameters
+ * vdev: the virtio_device
+ * n: the queue index
+ * coalesce_count: maximum coalesced count before issuing interrupt
+ *  coalesce_count: maximum micro seconds to wait if there's a
+ *  pending buffer
  * @reset: reset the device
  * vdev: the virtio device
  * After this, status and feature negotiation must be done again
@@ -66,6 +72,8 @@ struct virtio_config_ops {
u32 (*generation)(struct virtio_device *vdev);
u8 (*get_status)(struct virtio_device *vdev);
void (*set_status)(struct virtio_device *vdev, u8 status);
+   void (*set_coalesce)(struct virtio_device *vdev, int n,
+u32 coalesce_count, u32 coalesce_us);
void (*reset)(struct virtio_device *vdev);
int (*find_vqs)(struct virtio_device *, unsigned nvqs,
struct virtqueue *vqs[],
diff --git a/include/uapi/linux/virtio_pci.h b/include/uapi/linux/virtio_pci.h
index 7530146..3396026 100644
--- a/include/uapi/linux/virtio_pci.h
+++ b/include/uapi/linux/virtio_pci.h
@@ -155,6 +155,8 @@ struct virtio_pci_common_cfg {
__le32 queue_avail_hi;  /* read-write */
__le32 queue_used_lo;   /* read-write */
__le32 queue_used_hi;   /* read-write */
+   __le32 queue_coalesce_count;/* read-write */
+   __le32 queue_coalesce_us;   /* read-write */
 };
 
 /* Macro versions of offsets for the Old Timers! */
@@ -187,6 +189,8 @@ struct virtio_pci_common_cfg {
 #define VIRTIO_PCI_COMMON_Q_AVAILHI44
 #define VIRTIO_PCI_COMMON_Q_USEDLO 48
 #define VIRTIO_PCI_COMMON_Q_USEDHI 52
+#define VIRTIO_PCI_COMMON_Q_COALESCE_C  56
+#define VIRTIO_PCI_COMMON_Q_COALESCE_U  60
 
 #endif /* VIRTIO_PCI_NO_MODERN */
 
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC V7 PATCH 5/7] virtio_net: enable tx interrupt

[Jason Wang]

This patch enable tx interrupt for virtio-net driver. This can make
socket accounting works again and help to reduce the buffer bloat. To
reduce the performance impacts, only enable tx interrupt on newer host
with interrupt coalescing support.

Signed-off-by: Jason Wang 
---
 drivers/net/virtio_net.c | 214 ---
 1 file changed, 164 insertions(+), 50 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 4ad739f..a48b1f9 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -72,6 +72,8 @@ struct send_queue {
 
/* Name of the send queue: output.$index */
char name[40];
+
+   struct napi_struct napi;
 };
 
 /* Internal representation of a receive virtqueue */
@@ -123,6 +125,9 @@ struct virtnet_info {
/* Host can handle any s/g split between our header and packet data */
bool any_header_sg;
 
+   /* Host can coalesce interrupts */
+   bool intr_coalescing;
+
/* Packet virtio header size */
u8 hdr_len;
 
@@ -215,15 +220,54 @@ static struct page *get_a_page(struct receive_queue *rq, 
gfp_t gfp_mask)
return p;
 }
 
+static unsigned int free_old_xmit_skbs(struct netdev_queue *txq,
+  struct send_queue *sq, int budget)
+{
+   struct sk_buff *skb;
+   unsigned int len;
+   struct virtnet_info *vi = sq->vq->vdev->priv;
+   struct virtnet_stats *stats = this_cpu_ptr(vi->stats);
+   unsigned int packets = 0, bytes = 0;
+
+   while (packets < budget &&
+  (skb = virtqueue_get_buf(sq->vq, )) != NULL) {
+   pr_debug("Sent skb %p\n", skb);
+
+   bytes += skb->len;
+   packets++;
+
+   dev_kfree_skb_any(skb);
+   }
+
+   if (vi->intr_coalescing &&
+   sq->vq->num_free >= 2 + MAX_SKB_FRAGS)
+   netif_wake_subqueue(vi->dev, vq2txq(sq->vq));
+
+   u64_stats_update_begin(>tx_syncp);
+   stats->tx_bytes += bytes;
+   stats->tx_packets += packets;
+   u64_stats_update_end(>tx_syncp);
+
+   return packets;
+}
+
 static void skb_xmit_done(struct virtqueue *vq)
 {
struct virtnet_info *vi = vq->vdev->priv;
+   struct send_queue *sq = >sq[vq2txq(vq)];
 
-   /* Suppress further interrupts. */
-   virtqueue_disable_cb(vq);
+   if (vi->intr_coalescing) {
+   if (napi_schedule_prep(>napi)) {
+   virtqueue_disable_cb(sq->vq);
+   __napi_schedule(>napi);
+   }
+   } else {
+   /* Suppress further interrupts. */
+   virtqueue_disable_cb(vq);
 
-   /* We were probably waiting for more output buffers. */
-   netif_wake_subqueue(vi->dev, vq2txq(vq));
+   /* We were probably waiting for more output buffers. */
+   netif_wake_subqueue(vi->dev, vq2txq(vq));
+   }
 }
 
 static unsigned int mergeable_ctx_to_buf_truesize(unsigned long mrg_ctx)
@@ -775,6 +819,30 @@ static int virtnet_poll(struct napi_struct *napi, int 
budget)
return received;
 }
 
+static int virtnet_poll_tx(struct napi_struct *napi, int budget)
+{
+   struct send_queue *sq =
+   container_of(napi, struct send_queue, napi);
+   struct virtnet_info *vi = sq->vq->vdev->priv;
+   struct netdev_queue *txq = netdev_get_tx_queue(vi->dev, vq2txq(sq->vq));
+   u32 limit = vi->tx_work_limit;
+   unsigned int r, sent;
+
+   __netif_tx_lock(txq, smp_processor_id());
+   sent = free_old_xmit_skbs(txq, sq, limit);
+   if (sent < limit) {
+   r = virtqueue_enable_cb_prepare(sq->vq);
+   napi_complete(napi);
+   if (unlikely(virtqueue_poll(sq->vq, r)) &&
+   napi_schedule_prep(napi)) {
+   virtqueue_disable_cb(sq->vq);
+   __napi_schedule(napi);
+   }
+   }
+   __netif_tx_unlock(txq);
+   return sent < limit ? 0 : budget;
+}
+
 #ifdef CONFIG_NET_RX_BUSY_POLL
 /* must be called with local_bh_disable()d */
 static int virtnet_busy_poll(struct napi_struct *napi)
@@ -823,40 +891,12 @@ static int virtnet_open(struct net_device *dev)
if (!try_fill_recv(vi, >rq[i], GFP_KERNEL))
schedule_delayed_work(>refill, 0);
virtnet_napi_enable(>rq[i]);
+   napi_enable(>sq[i].napi);
}
 
return 0;
 }
 
-static void free_old_xmit_skbs(struct send_queue *sq)
-{
-   struct sk_buff *skb;
-   unsigned int len;
-   struct virtnet_info *vi = sq->vq->vdev->priv;
-   struct virtnet_stats *stats = this_cpu_ptr(vi->stats);
-   unsigned int packets = 0, bytes = 0;
-
-   while ((skb = virtqueue_get_buf(sq->vq, )) != NULL) {
-   pr_debug("Sent skb %p\n", skb);
-
-   bytes += skb->len;
-   packets++;
-
-   dev_kfree_skb_any(skb);

[RFC V7 PATCH 2/7] virtio_ring: try to disable event index callbacks in virtqueue_disable_cb()

[Jason Wang]

Currently, we do nothing to prevent the callbacks in virtqueue_disable_cb() when
event index is used. This may cause spurious interrupts which may damage the
performance. This patch tries to publish last_used_idx as the used even to 
prevent
the callbacks.

Signed-off-by: Jason Wang 
---
 drivers/virtio/virtio_ring.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index 096b857..a83aebc 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -538,6 +538,7 @@ void virtqueue_disable_cb(struct virtqueue *_vq)
struct vring_virtqueue *vq = to_vvq(_vq);
 
vq->vring.avail->flags |= cpu_to_virtio16(_vq->vdev, 
VRING_AVAIL_F_NO_INTERRUPT);
+   vring_used_event(>vring) = cpu_to_virtio16(_vq->vdev, 
vq->last_used_idx);
 }
 EXPORT_SYMBOL_GPL(virtqueue_disable_cb);
 
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC V7 PATCH 3/7] virtio-net: optimize free_old_xmit_skbs stats

[Jason Wang]

We already have counters for sent packets and sent bytes.
Use them to reduce the number of u64_stats_update_begin/end().

Take care not to bother with stats update when called
speculatively.

Cc: Rusty Russell 
Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
Signed-off-by: Michael S. Tsirkin 
---
 drivers/net/virtio_net.c | 18 ++
 1 file changed, 14 insertions(+), 4 deletions(-)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 63c7810..744f0b1 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -826,17 +826,27 @@ static void free_old_xmit_skbs(struct send_queue *sq)
unsigned int len;
struct virtnet_info *vi = sq->vq->vdev->priv;
struct virtnet_stats *stats = this_cpu_ptr(vi->stats);
+   unsigned int packets = 0, bytes = 0;
 
while ((skb = virtqueue_get_buf(sq->vq, )) != NULL) {
pr_debug("Sent skb %p\n", skb);
 
-   u64_stats_update_begin(>tx_syncp);
-   stats->tx_bytes += skb->len;
-   stats->tx_packets++;
-   u64_stats_update_end(>tx_syncp);
+   bytes += skb->len;
+   packets++;
 
dev_kfree_skb_any(skb);
}
+
+   /* Avoid overhead when no packets have been processed
+* happens when called speculatively from start_xmit.
+*/
+   if (!packets)
+   return ;
+
+   u64_stats_update_begin(>tx_syncp);
+   stats->tx_bytes += bytes;
+   stats->tx_packets += packets;
+   u64_stats_update_end(>tx_syncp);
 }
 
 static int xmit_skb(struct send_queue *sq, struct sk_buff *skb)
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC V7 PATCH 0/7] enable tx interrupts for virtio-net

[Jason Wang]

Hi:

This is a new version of trying to enable tx interrupts for
virtio-net.

We used to try to avoid tx interrupts and orphan packets before
transmission for virtio-net. This breaks socket accounting and can
lead serveral other side effects e.g:

- Several other functions which depends on socket accounting can not
  work correctly (e.g  TCP Small Queue)
- No tx completion which make BQL or packet generator can not work
  correctly.

This series tries to solve the issue by enabling tx interrupts. To
minize the performance impacts of this, several optimizations were
used:

- In guest side, try to use delayed callbacks as much as possible.
- In host side, try to use interrupt coalescing for reduce
  interrupts. About 10% - 15% performance were improved with this.

Perforamnce test shows:
- Few regression (10% - 15%) were noticed TCP_RR were noticed, this
  regresssion were not seen in previous version. Still not clear the
  reason.
- CPU utilization is increased in some cases.
- All other cases, tx interrupts can perform equal or better than
  orphaning especially for small packet tx

TODO:
- Try to fix the regressions of TCP_RR
- Determine a suitable coalescing paramters

Test Environmets:
- Two Intel Xeon E5620  @ 2.40GHz with back to back connected Intel 82599EB
- Both host and guest were 4.1-rc4
- Vhost zerocopy disabled
- idle=poll
- Netperf 2.6.0
- tx-frames=8 tx-usecs=64 (which was chosen to be the best performance
  during testing other combinations)
- Irqbalance were disabled by host, and smp affinity were set manually
- Using default ixgbe coalescing parameters

Test Result:

1 VCPU guest 1 Queue

Guest TX
size/session/+thu%/+normalize%
   64/ 1/  +22%/  +23%
   64/ 2/  +25%/  +26%
   64/ 4/  +24%/  +24%
   64/ 8/  +24%/  +25%
  256/ 1/ +134%/ +141%
  256/ 2/ +126%/ +132%
  256/ 4/ +126%/ +134%
  256/ 8/ +130%/ +135%
  512/ 1/ +157%/ +170%
  512/ 2/ +155%/ +169%
  512/ 4/ +153%/ +168%
  512/ 8/ +162%/ +176%
 1024/ 1/  +84%/ +119%
 1024/ 2/ +120%/ +146%
 1024/ 4/ +105%/ +131%
 1024/ 8/ +103%/ +134%
 2048/ 1/  +20%/  +97%
 2048/ 2/  +29%/  +76%
 2048/ 4/0%/  +11%
 2048/ 8/0%/   +3%
16384/ 1/0%/   -5%
16384/ 2/0%/  -10%
16384/ 4/0%/   -3%
16384/ 8/0%/0%
65535/ 1/0%/  -10%
65535/ 2/0%/   -5%
65535/ 4/0%/   -3%
65535/ 8/0%/   -5%

TCP_RR
size/session/+thu%/+normalize%
1/ 1/0%/   -9%
1/25/   -5%/   -5%
1/50/   -4%/   -3%
   64/ 1/0%/   -7%
   64/25/   -5%/   -6%
   64/50/   -5%/   -6%
  256/ 1/0%/   -6%
  256/25/  -14%/  -14%
  256/50/  -14%/  -14%

Guest RX
size/session/+thu%/+normalize%
   64/ 1/0%/   -1%
   64/ 2/   +3%/   +3%
   64/ 4/0%/   -1%
   64/ 8/0%/0%
  256/ 1/   +5%/   +1%
  256/ 2/   -9%/  -13%
  256/ 4/0%/   -2%
  256/ 8/0%/   -3%
  512/ 1/   +1%/   -2%
  512/ 2/   -3%/   -6%
  512/ 4/0%/   -3%
  512/ 8/0%/   -1%
 1024/ 1/  +11%/  +16%
 1024/ 2/0%/   -3%
 1024/ 4/0%/   -2%
 1024/ 8/0%/   -1%
 2048/ 1/0%/   -3%
 2048/ 2/0%/   -1%
 2048/ 4/0%/   -1%
 2048/ 8/0%/   -2%
16384/ 1/0%/   -2%
16384/ 2/0%/   -4%
16384/ 4/0%/   -3%
16384/ 8/0%/   -3%
65535/ 1/0%/   -2%
65535/ 2/0%/   -5%
65535/ 4/0%/   -1%
65535/ 8/   +1%/0%

4 VCPU guest 4 QUEUE
Guest TX
size/session/+thu%/+normalize%
   64/ 1/  +42%/  +38%
   64/ 2/  +33%/  +33%
   64/ 4/  +16%/  +19%
   64/ 8/  +19%/  +22%
  256/ 1/ +139%/ +134%
  256/ 2/  +43%/  +52%
  256/ 4/   +1%/   +6%
  256/ 8/0%/   +4%
  512/ 1/ +171%/ +175%
  512/ 2/   -1%/  +26%
  512/ 4/   +9%/   +8%
  512/ 8/  +48%/  +31%
 1024/ 1/ +162%/ +171%
 1024/ 2/0%/   +2%
 1024/ 4/   +3%/0%
 1024/ 8/   +6%/   +2%
 2048/ 1/  +60%/  +94%
 2048/ 2/0%/   +2%
 2048/ 4/  +23%/  +11%
 2048/ 8/   -1%/   -6%
16384/ 1/0%/  -12%
16384/ 2/0%/   -8%
16384/ 4/0%/   -9%
16384/ 8/0%/  -11%
65535/ 1/0%/  -15%
65535/ 2/0%/  -10%
65535/ 4/0%/   -6%
65535/ 8/   +1%/  -10%

TCP_RR
size/session/+thu%/+normalize%
1/ 1/0%/  -15%
1/25/  -14%/   -9%
1/50/   +3%/   +3%
   64/ 1/   -3%/  -10%
   64/25/  -13%/   -4%
   64/50/   -7%/   -4%
  256/ 1/   -1%/  -19%
  256/25/  -15%/   -3%
  256/50/  -16%/   -9%

Guest RX
size/session/+thu%/+normalize%
   64/ 1/   +4%/  +21%
   64/ 2/  +81%/ +140%
   64/ 4/  +51%/ +196%
   64/ 8/  -10%/  +33%
  256/ 1/ +139%/ +216%
  256/ 2/  +53%/ +114%
  256/ 4/   -9%/   -5%
  256/ 8/   -9%/  -14%
  512/ 1/ +257%/ +413%
  512/ 2/  +11%/  +32%
  512/ 4/   -4%/   -6%
  512/ 8/   -7%/  -10%
 1024/ 1/  +98%/ 

[RFC V7 PATCH 4/7] virtio-net: add basic interrupt coalescing support

[Jason Wang]

This patch enables the interrupt coalescing setting through ethtool.

Cc: Rusty Russell 
Cc: Michael S. Tsirkin 
Signed-off-by: Jason Wang 
---
 drivers/net/virtio_net.c | 62 
 drivers/virtio/virtio_ring.c |  2 ++
 include/uapi/linux/virtio_ring.h |  1 +
 3 files changed, 65 insertions(+)

diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
index 744f0b1..4ad739f 100644
--- a/drivers/net/virtio_net.c
+++ b/drivers/net/virtio_net.c
@@ -140,6 +140,14 @@ struct virtnet_info {
 
/* CPU hot plug notifier */
struct notifier_block nb;
+
+   /* Budget for polling tx completion */
+   u32 tx_work_limit;
+
+   __u32 rx_coalesce_usecs;
+   __u32 rx_max_coalesced_frames;
+   __u32 tx_coalesce_usecs;
+   __u32 tx_max_coalesced_frames;
 };
 
 struct padded_vnet_hdr {
@@ -1384,6 +1392,58 @@ static void virtnet_get_channels(struct net_device *dev,
channels->other_count = 0;
 }
 
+static int virtnet_set_coalesce(struct net_device *dev,
+   struct ethtool_coalesce *ec)
+{
+   struct virtnet_info *vi = netdev_priv(dev);
+   int i;
+
+   if (!vi->vdev->config->set_coalesce) {
+   dev_warn(>dev, "Transport does not support coalescing.\n");
+   return -EINVAL;
+   }
+
+   if (vi->rx_coalesce_usecs != ec->rx_coalesce_usecs ||
+   vi->rx_max_coalesced_frames != ec->rx_max_coalesced_frames) {
+   for (i = 0; i < vi->max_queue_pairs; i++) {
+   vi->vdev->config->set_coalesce(vi->vdev, rxq2vq(i),
+   ec->rx_max_coalesced_frames,
+   ec->rx_coalesce_usecs);
+   }
+   vi->rx_coalesce_usecs = ec->rx_coalesce_usecs;
+   vi->rx_max_coalesced_frames = ec->rx_max_coalesced_frames;
+   }
+
+   if (vi->tx_coalesce_usecs != ec->tx_coalesce_usecs ||
+   vi->tx_max_coalesced_frames != ec->tx_max_coalesced_frames) {
+   for (i = 0; i < vi->max_queue_pairs; i++) {
+   vi->vdev->config->set_coalesce(vi->vdev, txq2vq(i),
+   ec->tx_max_coalesced_frames,
+   ec->tx_coalesce_usecs);
+   }
+   vi->tx_coalesce_usecs = ec->tx_coalesce_usecs;
+   vi->tx_max_coalesced_frames = ec->tx_max_coalesced_frames;
+   }
+
+   vi->tx_work_limit = ec->tx_max_coalesced_frames_irq;
+
+   return 0;
+}
+
+static int virtnet_get_coalesce(struct net_device *dev,
+   struct ethtool_coalesce *ec)
+{
+   struct virtnet_info *vi = netdev_priv(dev);
+
+   ec->rx_coalesce_usecs = vi->rx_coalesce_usecs;
+   ec->rx_max_coalesced_frames = vi->rx_max_coalesced_frames;
+   ec->tx_coalesce_usecs = vi->tx_coalesce_usecs;
+   ec->tx_max_coalesced_frames = vi->tx_max_coalesced_frames;
+   ec->tx_max_coalesced_frames_irq = vi->tx_work_limit;
+
+   return 0;
+}
+
 static const struct ethtool_ops virtnet_ethtool_ops = {
.get_drvinfo = virtnet_get_drvinfo,
.get_link = ethtool_op_get_link,
@@ -1391,6 +1451,8 @@ static const struct ethtool_ops virtnet_ethtool_ops = {
.set_channels = virtnet_set_channels,
.get_channels = virtnet_get_channels,
.get_ts_info = ethtool_op_get_ts_info,
+   .set_coalesce = virtnet_set_coalesce,
+   .get_coalesce = virtnet_get_coalesce,
 };
 
 #define MIN_MTU 68
diff --git a/drivers/virtio/virtio_ring.c b/drivers/virtio/virtio_ring.c
index a83aebc..a2cdbe3 100644
--- a/drivers/virtio/virtio_ring.c
+++ b/drivers/virtio/virtio_ring.c
@@ -780,6 +780,8 @@ void vring_transport_features(struct virtio_device *vdev)
break;
case VIRTIO_RING_F_EVENT_IDX:
break;
+   case VIRTIO_RING_F_INTR_COALESCING:
+   break;
case VIRTIO_F_VERSION_1:
break;
default:
diff --git a/include/uapi/linux/virtio_ring.h b/include/uapi/linux/virtio_ring.h
index 915980a..e9756d8 100644
--- a/include/uapi/linux/virtio_ring.h
+++ b/include/uapi/linux/virtio_ring.h
@@ -58,6 +58,7 @@
 /* The Host publishes the avail index for which it expects a kick
  * at the end of the used ring. Guest should ignore the used->flags field. */
 #define VIRTIO_RING_F_EVENT_IDX29
+#define VIRTIO_RING_F_INTR_COALESCING   31
 
 /* Virtio ring descriptors: 16 bytes.  These can chain together via "next". */
 struct vring_desc {
-- 
1.8.3.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] init/do_mounts: Add create_dev() failure log

[Vishnu Pratap Singh]

if create_dev() function fails to create the root mount device (/dev/root),
then it goes to panic as root device not found but there is no check/log
present in case of failure, So i have added the log in case it fails to create
the root device. It will help in debugging.

Signed-off-by: Vishnu Pratap Singh 
---
 init/do_mounts.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/init/do_mounts.c b/init/do_mounts.c
index 8369ffa..a68aaf6 100644
--- a/init/do_mounts.c
+++ b/init/do_mounts.c
@@ -532,7 +532,8 @@ void __init mount_root(void)
}
 #endif
 #ifdef CONFIG_BLOCK
-   create_dev("/dev/root", ROOT_DEV);
+   if(create_dev("/dev/root", ROOT_DEV) < 0)
+   printk(KERN_ERR "Failed to create %s device !!\n", "/dev/root");
mount_block_root("/dev/root", root_mountflags);
 #endif
 }
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] w1: masters: omap_hdq: Add support for 1-wire mode

[Vignesh R]

On Monday 18 May 2015 05:39 PM, Vignesh R wrote:
> This patches makes following changes to omap_hdq driver
>  - Enable 1-wire mode.
>  - Implement w1_triplet callback to facilitate search rom
>procedure and auto detection of 1-wire slaves.
>  - Proper enabling and disabling of interrupt.
>  - Cleanups (formatting and return value checks).
> 
> HDQ mode remains unchanged.
> 
> Signed-off-by: Vignesh R 
> ---

Gentle ping...

> 
> v2:
>  * report error if RX/TX_COMPLETE times out.
> 
>  Documentation/devicetree/bindings/w1/omap-hdq.txt |   7 +-
>  Documentation/w1/masters/omap-hdq |   6 +
>  drivers/w1/masters/omap_hdq.c | 224 
> ++
>  3 files changed, 203 insertions(+), 34 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/w1/omap-hdq.txt 
> b/Documentation/devicetree/bindings/w1/omap-hdq.txt
> index fef794741bd1..913c5f91a0f9 100644
> --- a/Documentation/devicetree/bindings/w1/omap-hdq.txt
> +++ b/Documentation/devicetree/bindings/w1/omap-hdq.txt
> @@ -1,11 +1,15 @@
>  * OMAP HDQ One wire bus master controller
>  
>  Required properties:
> -- compatible : should be "ti,omap3-1w"
> +- compatible : should be "ti,omap3-1w" or "ti,am4372-hdq"
>  - reg : Address and length of the register set for the device
>  - interrupts : interrupt line.
>  - ti,hwmods : "hdq1w"
>  
> +Optional properties:
> +- ti,mode: should be "hdq": HDQ mode  "1w": one-wire mode.
> +If not specified HDQ mode is implied.
> +
>  Example:
>  
>  - From omap3.dtsi
> @@ -14,4 +18,5 @@ Example:
>   reg = <0x480b2000 0x1000>;
>   interrupts = <58>;
>   ti,hwmods = "hdq1w";
> + ti,mode = "hdq";
>};
> diff --git a/Documentation/w1/masters/omap-hdq 
> b/Documentation/w1/masters/omap-hdq
> index 884dc284b215..234522709a5f 100644
> --- a/Documentation/w1/masters/omap-hdq
> +++ b/Documentation/w1/masters/omap-hdq
> @@ -44,3 +44,9 @@ e.g:
>  insmod omap_hdq.ko W1_ID=2
>  inamod w1_bq27000.ko F_ID=2
>  
> +The driver also supports 1-wire mode. In this mode, there is no need to
> +pass slave ID as parameter. The driver will auto-detect slaves connected
> +to the bus using SEARCH_ROM procedure. 1-wire mode can be selected by
> +setting "ti,mode" property to "1w" in DT (see
> +Documentation/devicetree/bindings/w1/omap-hdq.txt for more details).
> +By default driver is in HDQ mode.
> diff --git a/drivers/w1/masters/omap_hdq.c b/drivers/w1/masters/omap_hdq.c
> index e7d448963a24..0e2f43bccf1f 100644
> --- a/drivers/w1/masters/omap_hdq.c
> +++ b/drivers/w1/masters/omap_hdq.c
> @@ -17,6 +17,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "../w1.h"
>  #include "../w1_int.h"
> @@ -27,21 +28,23 @@
>  #define OMAP_HDQ_TX_DATA 0x04
>  #define OMAP_HDQ_RX_DATA 0x08
>  #define OMAP_HDQ_CTRL_STATUS 0x0c
> -#define OMAP_HDQ_CTRL_STATUS_INTERRUPTMASK   (1<<6)
> -#define OMAP_HDQ_CTRL_STATUS_CLOCKENABLE (1<<5)
> -#define OMAP_HDQ_CTRL_STATUS_GO  (1<<4)
> -#define OMAP_HDQ_CTRL_STATUS_INITIALIZATION  (1<<2)
> -#define OMAP_HDQ_CTRL_STATUS_DIR (1<<1)
> -#define OMAP_HDQ_CTRL_STATUS_MODE(1<<0)
> +#define OMAP_HDQ_CTRL_STATUS_SINGLE  BIT(7)
> +#define OMAP_HDQ_CTRL_STATUS_INTERRUPTMASK   BIT(6)
> +#define OMAP_HDQ_CTRL_STATUS_CLOCKENABLE BIT(5)
> +#define OMAP_HDQ_CTRL_STATUS_GO BIT(4)
> +#define OMAP_HDQ_CTRL_STATUS_PRESENCEBIT(3)
> +#define OMAP_HDQ_CTRL_STATUS_INITIALIZATION  BIT(2)
> +#define OMAP_HDQ_CTRL_STATUS_DIR BIT(1)
>  #define OMAP_HDQ_INT_STATUS  0x10
> -#define OMAP_HDQ_INT_STATUS_TXCOMPLETE   (1<<2)
> -#define OMAP_HDQ_INT_STATUS_RXCOMPLETE   (1<<1)
> -#define OMAP_HDQ_INT_STATUS_TIMEOUT  (1<<0)
> +#define OMAP_HDQ_INT_STATUS_TXCOMPLETE   BIT(2)
> +#define OMAP_HDQ_INT_STATUS_RXCOMPLETE   BIT(1)
> +#define OMAP_HDQ_INT_STATUS_TIMEOUT  BIT(0)
>  #define OMAP_HDQ_SYSCONFIG   0x14
> -#define OMAP_HDQ_SYSCONFIG_SOFTRESET (1<<1)
> -#define OMAP_HDQ_SYSCONFIG_AUTOIDLE  (1<<0)
> +#define OMAP_HDQ_SYSCONFIG_SOFTRESET BIT(1)
> +#define OMAP_HDQ_SYSCONFIG_AUTOIDLE  BIT(0)
> +#define OMAP_HDQ_SYSCONFIG_NOIDLE0x0
>  #define OMAP_HDQ_SYSSTATUS   0x18
> -#define OMAP_HDQ_SYSSTATUS_RESETDONE (1<<0)
> +#define OMAP_HDQ_SYSSTATUS_RESETDONE BIT(0)
>  
>  #define OMAP_HDQ_FLAG_CLEAR  0
>  #define OMAP_HDQ_FLAG_SET1
> @@ -67,6 +70,10 @@ struct hdq_data {
>* the data wrire or read.
>*/
>   int init_trans;
> + int rrw;
> + /* mode: 0-HDQ 1-W1 */
> + int mode;
> +
>  };
>  
>  static int omap_hdq_probe(struct platform_device *pdev);
> @@ -74,6 +81,7 @@ static int omap_hdq_remove(struct platform_device 

Re: [PATCH] drm/msm/mdp5: Always generate active-high sync signals for DSI

[Archit Taneja]

On 05/22/2015 07:46 PM, Hai Li wrote:

DSI video mode engine can only take active-high sync signals. This
change prevents MDP5 sending active-low sync signals to DSI in any
case.

Signed-off-by: Hai Li 


Tested-by: Archit Taneja 


---
  drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c | 12 
  1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
index 53bb1f7..2e98ce0 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_encoder.c
@@ -144,10 +144,14 @@ static void mdp5_encoder_mode_set(struct drm_encoder 
*encoder,
mode->type, mode->flags);

ctrl_pol = 0;
-   if (mode->flags & DRM_MODE_FLAG_NHSYNC)
-   ctrl_pol |= MDP5_INTF_POLARITY_CTL_HSYNC_LOW;
-   if (mode->flags & DRM_MODE_FLAG_NVSYNC)
-   ctrl_pol |= MDP5_INTF_POLARITY_CTL_VSYNC_LOW;
+
+   /* DSI controller cannot handle active-low sync signals. */
+   if (mdp5_encoder->intf.type != INTF_DSI) {
+   if (mode->flags & DRM_MODE_FLAG_NHSYNC)
+   ctrl_pol |= MDP5_INTF_POLARITY_CTL_HSYNC_LOW;
+   if (mode->flags & DRM_MODE_FLAG_NVSYNC)
+   ctrl_pol |= MDP5_INTF_POLARITY_CTL_VSYNC_LOW;
+   }
/* probably need to get DATA_EN polarity from panel.. */

dtv_hsync_skew = 0;  /* get this from panel? */



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dell_rbtn - kernel panic at boot...

[Matthew Garrett]

On Sun, May 24, 2015 at 09:44:32PM -0700, Darren Hart wrote:

> Greg, Matthew, I'm tempted to recommend this 434 line driver be rolled into
> dell-laptop.c. Any strong opinions?

Mrm. It's slightly conceptually nasty in that one's an ACPI driver and 
one's calling a Dell custom interface, but I think merging them is 
probably the last bad answer.

-- 
Matthew Garrett | mj...@srcf.ucam.org
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dell_rbtn - kernel panic at boot...

[Darren Hart]

On Sat, May 23, 2015 at 03:05:36AM +0200, Pali Rohár wrote:
> On Saturday 23 May 2015 00:53:16 Dmitry Torokhov wrote:
> > On Thu, May 21, 2015 at 7:06 PM, Valdis Kletnieks
> > 
> >  wrote:
> > > So after I made both config variables =y, the resulting kernel
> > > built, but died a glorious death at boot.
> > 
> > I guess if both are built-in then, according to link order,
> > dell-laptop starts first, before dell-rbtn, and dies in
> > dell_rbtn_notifier_register() in call to
> > driver_for_each_device(_driver.drv, ...) because rbtn_driver has
> > not been registered yet and thus half-initlalized.
> > 
> > Thanks.
> 
> pr_debug() messages could be useful... but no idea if we can get them.
> 
> Is there any way to fix that dependency race condition? Could 
> driver_attach() function call help?

I believe you can avoid this by moving dell-rbtn earlier in the Makefile than
dell-laptop - but this is fragile and a hack to resolve a dependency problem.

I suppose this is why thinkpad-acpi.c is huge, and why having separate drivers
talk to eachother is discouraged.

dell-laptop seems to be the base, while dell-rbtn is the more specific of the
two - which makes dell-laptop calling a dell-rbtn function which requires
dell-rbtn to have been initialized prior a poor approach.

Greg, Matthew, I'm tempted to recommend this 434 line driver be rolled into
dell-laptop.c. Any strong opinions?

-- 
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: [char-misc-next 11/11] mei: revamp mei bus code

[Winkler, Tomas]

> > > This is a lot to do in just one patch.  Any chance you can split it up
> > > into reviewable pieces?
> >
> > I thought it would be harder to swallow but I'm not sure how to really
> > split this into working pieces w/o do some artificial steps which
> >  I will have to validate again to keep the code bisectable.
> 
> That's fine, that's your job to do :)

I'd would prefer to do something that wasn't' already done.

> 
> > What could be naturally factored out is already in separate  patches in this
> series.
> > The patch is maybe bigger because of code moves between files but what has
> really changes is just bus.c
> 
> Then do the movement of functions around in one patch, and then the
> logical changes in others.  Come on, you know how this whole thing
> works, don't be lazy here...
> 
Yep, I know how it works, but here it just didn't fit as the logical changes 
moved also the code.
Okay, I will split the code but allow me one comment, I think that you were 
lazy too  go into details and  you didn't send us to hell when we first 
submitted that bus code.
Tomas


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: randconfig build error with next-20150521, in drivers/platform/x86/dell-rbtn.c

[Darren Hart]

On Thu, May 21, 2015 at 10:07:11PM +0200, Pali Rohár wrote:
> On Thursday 21 May 2015 21:56:15 Darren Hart wrote:
> > On Thu, May 21, 2015 at 10:36:15AM -0700, Jim Davis wrote:
> > > Building with the attached random configuration file,
> > > 
> > > drivers/built-in.o: In function `rbtn_remove':
> > > dell-rbtn.c:(.text+0x31d7f4): undefined reference to
> > > `input_unregister_device' drivers/built-in.o: In function
> > > `rbtn_notify':
> > > dell-rbtn.c:(.text+0x31d8e5): undefined reference to `input_event'
> > > dell-rbtn.c:(.text+0x31d8f8): undefined reference to `input_event'
> > > dell-rbtn.c:(.text+0x31d911): undefined reference to `input_event'
> > > dell-rbtn.c:(.text+0x31d924): undefined reference to `input_event'
> > > drivers/built-in.o: In function `rbtn_add':
> > > dell-rbtn.c:(.text+0x31da11): undefined reference to
> > > `input_allocate_device' dell-rbtn.c:(.text+0x31da4a): undefined
> > > reference to `input_register_device' dell-rbtn.c:(.text+0x31da5e):
> > > undefined reference to `input_free_device' Makefile:938: recipe
> > > for target 'vmlinux' failed
> > 
> > Thanks Jim,
> > 
> > Pali, the DELL_RBTN needs to ensure if it it's built-in, that INPUT
> > is too. ...
> > 
> > > CONFIG_INPUT=m
> > > CONFIG_INPUT_FF_MEMLESS=m
> > > CONFIG_INPUT_POLLDEV=m
> > > CONFIG_INPUT_SPARSEKMAP=m
> > > CONFIG_INPUT_MATRIXKMAP=m
> > 
> > ...
> > 
> > > CONFIG_DELL_RBTN=y
> > 
> > Please submit a fix as a new patch.
> 
> I believe that this patch is needed:
> 
> diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
> index 8c03223..d025fd8 100644
> --- a/drivers/platform/x86/Kconfig
> +++ b/drivers/platform/x86/Kconfig
> @@ -141,6 +141,7 @@ config DELL_SMO8800
>  config DELL_RBTN
>   tristate "Dell Airplane Mode Switch driver"
>   depends on ACPI
> + depends on INPUT
>   depends on RFKILL
>   ---help---
> Say Y here if you want to support Dell Airplane Mode Switch ACPI
> 
> I did not tested it yet, but all other drivers depends on INPUT.

This looks reasonable to me. Please test it with the various configs and send
the patch if it passes the tests.


-- 
Darren Hart
Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 6/7] Watchdog: introduce ARM SBSA watchdog driver

[Fu Wei]

Hi Timur.


On 25 May 2015 at 11:46, Timur Tabi  wrote:
> Fu Wei wrote:
>>
>> Once the Linux kernel has KVM support and is in hyp mode. we
>> may need to use arch_counter_get_cntpct.
>
>
> arch_counter_get_cntpct() does not appear to be valid for ARM64:
>
> http://lxr.free-electrons.com/source/arch/arm64/include/asm/arch_timer.h#L108

Great thank for correction, that make sense.

>
>
> --
> Sent by an employee of the Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the
> Code Aurora Forum, hosted by The Linux Foundation.



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] fbdev: radeon: Remove 'struct timeval' usage

[Tina Ruchandani]

'struct timeval' uses a 32-bit representation for the
seconds field which will overflow in the year 2038 and beyond.
This patch replaces the usage of 'struct timeval' with
ktime_t which uses a 64-bit time representation and does not
suffer from the y2038 problem. This patch is part of a larger
effort to remove all instances of 'struct timeval', 'struct
timespec', time_t and other 32-bit timekeeping variables
from the kernel.
The patch also replaces the use of real time (do_gettimeofday)
with monotonic time (ktime_get).

Signed-off-by: Tina Ruchandani 
---
 drivers/video/fbdev/aty/radeon_base.c | 29 ++---
 1 file changed, 14 insertions(+), 15 deletions(-)

diff --git a/drivers/video/fbdev/aty/radeon_base.c 
b/drivers/video/fbdev/aty/radeon_base.c
index 01237c8..9747e9e 100644
--- a/drivers/video/fbdev/aty/radeon_base.c
+++ b/drivers/video/fbdev/aty/radeon_base.c
@@ -64,6 +64,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -461,8 +462,8 @@ static int radeon_probe_pll_params(struct radeonfb_info 
*rinfo)
int hTotal, vTotal, num, denom, m, n;
unsigned long long hz, vclk;
long xtal;
-   struct timeval start_tv, stop_tv;
-   long total_secs, total_usecs;
+   ktime_t start, stop;
+   s64 delta;
int i;
 
/* Ugh, we cut interrupts, bad bad bad, but we want some precision
@@ -478,7 +479,7 @@ static int radeon_probe_pll_params(struct radeonfb_info 
*rinfo)
if (((INREG(CRTC_VLINE_CRNT_VLINE) >> 16) & 0x3ff) == 0)
break;
 
-   do_gettimeofday(_tv);
+   start = ktime_get();
 
for(i=0; i<100; i++)
if (((INREG(CRTC_VLINE_CRNT_VLINE) >> 16) & 0x3ff) != 0)
@@ -487,20 +488,18 @@ static int radeon_probe_pll_params(struct radeonfb_info 
*rinfo)
for(i=0; i<100; i++)
if (((INREG(CRTC_VLINE_CRNT_VLINE) >> 16) & 0x3ff) == 0)
break;
-   
-   do_gettimeofday(_tv);
-   
+
+   stop = ktime_get();
+
local_irq_enable();
 
-   total_secs = stop_tv.tv_sec - start_tv.tv_sec;
-   if (total_secs > 10)
+   delta = ktime_us_delta(stop, start);
+
+   /* Return -1 if more than 10 seconds have elapsed */
+   if (delta > (10*100))
return -1;
-   total_usecs = stop_tv.tv_usec - start_tv.tv_usec;
-   total_usecs += total_secs * 100;
-   if (total_usecs < 0)
-   total_usecs = -total_usecs;
-   hz = 100/total_usecs;
- 
+   hz = 100/delta;
+
hTotal = ((INREG(CRTC_H_TOTAL_DISP) & 0x1ff) + 1) * 8;
vTotal = ((INREG(CRTC_V_TOTAL_DISP) & 0x3ff) + 1);
vclk = (long long)hTotal * (long long)vTotal * hz;
@@ -548,7 +547,7 @@ static int radeon_probe_pll_params(struct radeonfb_info 
*rinfo)
denom *= 3;
break;
case 6:
-   denom *= 6;   
+   denom *= 6;
break;
case 7:
denom *= 12;
-- 
2.2.0.rc0.207.ga3a616c

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] zram: check compressor name before setting it

[Sergey Senozhatsky]

On (05/22/15 22:14), Minchan Kim wrote:
> > > >second, there is not much value in exposing zcomp internals,
> > > >especially when the result is just another line in dmesg output.
> > > 
> > > From the other hand, the only valid values that can be written are
> > > in 'comp_algorithm'.
> > > So when writing other one, returning -EINVAL seems to be reasonable.
> > > The user would get immediately information that he can't do that,
> > > now the information can be very deferred in time.
> > 
> > it's not.
> > the error message appears in syslog right before we return -EINVAL
> > back to user.
> 
> Although Marcin's description is rather misleading, I like the patch.
> Every admin doesn't watch dmesg output. Even people could change loglevel
> simply so KERN_INFO would be void in that case.

there is no -EUNSPPORTEDCOMPRESSIONALGORITHM errno that we can return
back to userspace and expect it [userspace] to magically transform it
into a meaningful error message; users must check syslog/dmesg. that's
the way it is.

# echo LZ4 > /sys/block/zram0/comp_algorithm
# -bash: echo: write error: Device or resource busy

- hm why?
- well, that's why:
dmesg
[  249.745335] zram: Can't change algorithm for initialized device


> Instant error propagation is more strighforward for user point of view
> rather than delaying with depending on another event.

I'd rather just add two lines of code, w/o making zcomp internals visible.

it seems that we are trying to solve a problem that does not really
exist. I think what we really need to do is to rewrite zram documentation
and to propose zramctl usage as a recommended way of managing zram devices.
zramctl does not do `typo' errors. if somebody wants to configure zram
manually, then he simply must check syslog. it's simple.

---

 drivers/block/zram/zcomp.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index a1a8b8e..d96da53 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -54,11 +54,16 @@ static struct zcomp_backend *backends[] = {
 static struct zcomp_backend *find_backend(const char *compress)
 {
int i = 0;
+
while (backends[i]) {
if (sysfs_streq(compress, backends[i]->name))
break;
i++;
}
+
+   if (!backends[i])
+   pr_err("Error: unknown compression algorithm: %s\n",
+   compress);
return backends[i];
 }
 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/1] serial: earlycon: Add support for big-endian MMIO accesses

[Noam Camus]

From: Noam Camus 

Support command line parameters of the form:
earlycon=,io|mmio|mmio32|mmio32be,,

This commit seem to be needed even after commit:
serial: 8250: Add support for big-endian MMIO accesses
c627f2ceb692e8a9358b64ac2d139314e7bb0d17

Signed-off-by: Noam Camus 
---
 Documentation/kernel-parameters.txt |9 +
 drivers/tty/serial/earlycon.c   |9 ++---
 drivers/tty/serial/serial_core.c|7 +--
 3 files changed, 16 insertions(+), 9 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 61ab162..55bb093 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -959,14 +959,15 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
uart[8250],io,[,options]
uart[8250],mmio,[,options]
uart[8250],mmio32,[,options]
+   uart[8250],mmio32be,[,options]
uart[8250],0x[,options]
Start an early, polled-mode console on the 8250/16550
UART at the specified I/O port or MMIO address.
MMIO inter-register address stride is either 8-bit
-   (mmio) or 32-bit (mmio32).
-   If none of [io|mmio|mmio32],  is assumed to be
-   equivalent to 'mmio'. 'options' are specified in the
-   same format described for "console=ttyS"; if
+   (mmio) or 32-bit (mmio32 or mmio32be).
+   If none of [io|mmio|mmio32|mmio32be],  is assumed
+   to be equivalent to 'mmio'. 'options' are specified
+   in the same format described for "console=ttyS"; if
unspecified, the h/w is not initialized.
 
pl011,
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
index 5fdc9f3..a840732 100644
--- a/drivers/tty/serial/earlycon.c
+++ b/drivers/tty/serial/earlycon.c
@@ -72,6 +72,7 @@ static int __init parse_options(struct earlycon_device 
*device, char *options)
 
switch (port->iotype) {
case UPIO_MEM32:
+   case UPIO_MEM32BE:
port->regshift = 2; /* fall-through */
case UPIO_MEM:
port->mapbase = addr;
@@ -90,9 +91,11 @@ static int __init parse_options(struct earlycon_device 
*device, char *options)
strlcpy(device->options, options, length);
}
 
-   if (port->iotype == UPIO_MEM || port->iotype == UPIO_MEM32)
+   if (port->iotype == UPIO_MEM || port->iotype == UPIO_MEM32 ||
+   port->iotype == UPIO_MEM32BE)
pr_info("Early serial console at MMIO%s 0x%llx (options 
'%s')\n",
-   (port->iotype == UPIO_MEM32) ? "32" : "",
+   (port->iotype == UPIO_MEM) ? "" :
+   (port->iotype == UPIO_MEM32) ? "32" : "32be",
(unsigned long long)port->mapbase,
device->options);
else
@@ -133,7 +136,7 @@ static int __init register_earlycon(char *buf, const struct 
earlycon_id *match)
  *
  * Registers the earlycon console matching the earlycon specified
  * in the param string @buf. Acceptable param strings are of the form
- *,io|mmio|mmio32,,
+ *,io|mmio|mmio32|mmio32be,,
  *,0x,
  *,
  *
diff --git a/drivers/tty/serial/serial_core.c b/drivers/tty/serial/serial_core.c
index 0b7bb12..1124090 100644
--- a/drivers/tty/serial/serial_core.c
+++ b/drivers/tty/serial/serial_core.c
@@ -1816,8 +1816,8 @@ uart_get_console(struct uart_port *ports, int nr, struct 
console *co)
  * @options: ptr for  field; NULL if not present (out)
  *
  * Decodes earlycon kernel command line parameters of the form
- *earlycon=,io|mmio|mmio32,,
- *console=,io|mmio|mmio32,,
+ *earlycon=,io|mmio|mmio32|mmio32be,,
+ *console=,io|mmio|mmio32|mmio32be,,
  *
  * The optional form
  *earlycon=,0x,
@@ -1835,6 +1835,9 @@ int uart_parse_earlycon(char *p, unsigned char *iotype, 
unsigned long *addr,
} else if (strncmp(p, "mmio32,", 7) == 0) {
*iotype = UPIO_MEM32;
p += 7;
+   } else if (strncmp(p, "mmio32be,", 9) == 0) {
+   *iotype = UPIO_MEM32BE;
+   p += 9;
} else if (strncmp(p, "io,", 3) == 0) {
*iotype = UPIO_PORT;
p += 3;
-- 
1.7.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 6/7] Watchdog: introduce ARM SBSA watchdog driver

[Timur Tabi]

Fu Wei wrote:

Once the Linux kernel has KVM support and is in hyp mode. we
may need to use arch_counter_get_cntpct.


arch_counter_get_cntpct() does not appear to be valid for ARM64:

http://lxr.free-electrons.com/source/arch/arm64/include/asm/arch_timer.h#L108

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the
Code Aurora Forum, hosted by The Linux Foundation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6] serial: 8250_uniphier: add UniPhier serial driver

[Masahiro Yamada]

Add the driver for on-chip UART used on UniPhier SoCs.

This hardware is similar to 8250, but the register mapping is
slightly different:
  - The offset to FCR, MCR is different.
  - The divisor latch access bit does not exist.  Instead, the
divisor latch register is available at offset 9.

This driver overrides serial_{in,out}, dl_{read,write} callbacks,
but wants to borrow most of code from 8250_core.c.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Matthias Brugger 
---

Changes in v6:
  - Drop unnecessary #include 
(it is covered by #include "8250.h")

Changes in v5:
  - Set up.port.mapsize
  - Pass NULL rahter than 0 to the second argument of devm_clk_get()

Changes in v4:
  - Use spin_lock for read-modify-write register access
  - Add /* fall through */ comments where I intentionally
did not add "break";
  - Drop unnecessary #include 
  - Drop unnecessary #include 
  - Add an empty line between #include <> and ""
  - Use platform_get_irq() instead of platform_get_resource()

Changes in v3:
  - Just add *_SHIFT macro for the special case

Changes in v2:
  - Drop unnecessary #include 
  - Sort includes in alphabetical order
  - Use devm_clk_get() rather than of_clk_get()
  - Delete unneeded clk_put() from uniphier_uart_remove callback
  - Delete unneeded IS_ERR_OR_NULL check from uniphier_uart_remove callback
  - Use UNIPHIER_UART_*_SHIFT instead of hard-coded shift values
  - Change the first argument type of uniphier_of_serial_setup()
from (struct platform_device *) to (struct device *) for code-cleanup.

 drivers/tty/serial/8250/8250_uniphier.c | 257 
 drivers/tty/serial/8250/Kconfig |   7 +
 drivers/tty/serial/8250/Makefile|   1 +
 3 files changed, 265 insertions(+)
 create mode 100644 drivers/tty/serial/8250/8250_uniphier.c

diff --git a/drivers/tty/serial/8250/8250_uniphier.c 
b/drivers/tty/serial/8250/8250_uniphier.c
new file mode 100644
index 000..6f1e997
--- /dev/null
+++ b/drivers/tty/serial/8250/8250_uniphier.c
@@ -0,0 +1,257 @@
+/*
+ * Copyright (C) 2015 Masahiro Yamada 
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "8250.h"
+
+/* Most (but not all) of UniPhier UART devices have 64-depth FIFO. */
+#define UNIPHIER_UART_DEFAULT_FIFO_SIZE64
+
+#define UNIPHIER_UART_CHAR_FCR 3   /* Character / FIFO Control Register */
+#define UNIPHIER_UART_LCR_MCR  4   /* Line/Modem Control Register */
+#define   UNIPHIER_UART_LCR_SHIFT  8
+#define UNIPHIER_UART_DLR  9   /* Divisor Latch Register */
+
+struct uniphier8250_priv {
+   int line;
+   struct clk *clk;
+   spinlock_t atomic_write_lock;
+};
+
+/*
+ * The register map is slightly different from that of 8250.
+ * IO callbacks must be overridden for correct access to FCR, LCR, and MCR.
+ */
+static unsigned int uniphier_serial_in(struct uart_port *p, int offset)
+{
+   int valshift = 0;
+
+   switch (offset) {
+   case UART_LCR:
+   valshift = UNIPHIER_UART_LCR_SHIFT;
+   /* fall through */
+   case UART_MCR:
+   offset = UNIPHIER_UART_LCR_MCR;
+   break;
+   default:
+   break;
+   }
+
+   offset <<= p->regshift;
+
+   /*
+* The return value must be masked with 0xff because LCR and MCR reside
+* in the same register that must be accessed by 32-bit write/read.
+* 8 or 16 bit access to this hardware result in unexpected behavior.
+*/
+   return (readl(p->membase + offset) >> valshift) & 0xff;
+}
+
+static void uniphier_serial_out(struct uart_port *p, int offset, int value)
+{
+   int valshift = 0;
+   bool normal = false;
+
+   switch (offset) {
+   case UART_FCR:
+   offset = UNIPHIER_UART_CHAR_FCR;
+   break;
+   case UART_LCR:
+   valshift = UNIPHIER_UART_LCR_SHIFT;
+   /* Divisor latch access bit does not exist. */
+   value &= ~(UART_LCR_DLAB << valshift);
+   /* fall through */
+   case UART_MCR:
+   offset = UNIPHIER_UART_LCR_MCR;
+   break;
+   default:
+   normal = true;
+   break;
+   }
+
+   offset <<= p->regshift;
+
+   if (normal) {
+   writel(value, p->membase + offset);
+   } else {
+   /*
+* Special case: two registers share the same address that
+* must be 

Re: [PATCH v2 6/7] Watchdog: introduce ARM SBSA watchdog driver

[Fu Wei]

Hi Guenter,

On 21 May 2015 at 23:28, Guenter Roeck  wrote:
> On Thu, May 21, 2015 at 08:09:02AM -0500, Timur Tabi wrote:
>> Guenter Roeck wrote:
>> >>
>> >>+static unsigned int sbsa_gwdt_get_timeleft(struct watchdog_device *wdd)
>> >>+{
>> >>+struct sbsa_gwdt *gwdt = to_sbsa_gwdt(wdd);
>> >>+u64 timeleft = sbsa_gwdt_get_wcv(wdd) - arch_counter_get_cntvct();
>> >>+
>> >
>> >Still not happy about the use of arch_counter_get_cntvct
>> >instead of using the clock subsystem. I am quite sure this could be done,
>> >possibly through arch_sys_counter, though at this point I am getting wary
>> >of bringing it up, so I guess I'll just let it go.
>>
>> You made the same comment with my driver, and I keep asking for
>> clarification.  The clk_get_sys() API does not work on my system, because
>> there are not clocks defined.  That must be an ACPI limitation that I can't
>> fix.
>>
> Would it be possible to define such clocks ?
>
>> The alternative to arch_counter_get_cntvct() is arch_timer_read_counter(),
>> which is not exported.  So we have two choices,
>>
>> 1) Continue to use arch_counter_get_cntvct(), which works on all ARM64
>> platforms that this driver supports anyway
>>
>> 2) Export arch_timer_read_counter()
>>
>> I prefer option #1.
>>
> Do we have any feedback from the arm maintainers ?
>
> My problem is that I don't want to be the first one to permit using
> those functions outside architecture and clock code. If we do this,
> we should get an Ack from an arm maintainer specifically for the use
> of arch_counter_get_cntvct() and arch_timer_get_rate().

IMO, we may need to use  arch_timer_read_counter.
Reason:  Once the Linux kernel has KVM support and is in hyp mode. we
may need to use arch_counter_get_cntpct.
So arch_timer driver have helped us to make arch_timer_read_counter
point to the right function.
and arch_timer_read_counter is in the
include/clocksource/arm_arch_timer.h,  just like arch_timer_get_rate
as a interface




>
> Thanks,
> Guenter
> --
> To unsubscribe from this list: send the line "unsubscribe devicetree" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Payment

[Finance Department]

Dear Winner,

You have been awarded the sum of  8,000,000.00 (Eight Million Pounds sterling) 
with reference number 77100146. This compensation funds from the United 
Nation.Send us your personal details to deliver your funds.

Gloria Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 5/7] Watchdog: introduce "pretimeout" into framework

[Fu Wei]

Hi Guenter,

Great thanks for your suggestion,

I have put this kind of validation into watchdog_pretimeout_invalid
and watchdog_timeout_invalid.

So :

(1)
 set_timeout(10);   --> if this setting is successful
 set_pretimeout(20); ->  return fail (-EINVAL)


(2)
set_timeout(10);  --> if this setting is successful
set_pretimeout(10); ->  return fail (-EINVAL)

this kind of situation will not result in an invalid / unexpected timeout value.

you will see this change in my next patchset

On 21 May 2015 at 23:32, Guenter Roeck  wrote:
> On Thu, May 21, 2015 at 04:32:34PM +0800, fu@linaro.org wrote:
>> From: Fu Wei 
>>
>> Also update Documentation/watchdog/watchdog-kernel-api.txt to
>> introduce:
>> (1)the new elements in the watchdog_device and watchdog_ops struct;
>> (2)the new API "watchdog_init_timeouts".
>>
>> Reasons:
>> (1)kernel already has two watchdog drivers are using "pretimeout":
>>   drivers/char/ipmi/ipmi_watchdog.c
>>   drivers/watchdog/kempld_wdt.c(but the definition is different)
>> (2)some other dirvers are going to use this: ARM SBSA Generic Watchdog
>>
>> Signed-off-by: Fu Wei 
>> ---
>
> [ ... ]
>
>>
>> +/* Use the following function to check if a pretimeout value is invalid */
>> +static inline bool watchdog_pretimeout_invalid(struct watchdog_device *wdd,
>> +unsigned int t)
>> +{
>> + return ((wdd->max_pretimeout != 0) &&
>> + (t < wdd->min_pretimeout || t > wdd->max_pretimeout));
>> +}
>
> Should this function also enforce "t < wdd->timeout", and
> should watchdog_timeout_invalid() enforce "t > wdd->pretimeout" ?
>
> Thanks,
> Guenter



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

linux-next: manual merge of the wireless-drivers-next tree with the wireless-drivers tree

[Stephen Rothwell]

Hi Kalle,

Today's linux-next merge of the wireless-drivers-next tree got a
conflict in drivers/net/wireless/iwlwifi/Kconfig between commit
ed65918735a5 ("iwlwifi: 7000: modify the firmware name for 3165") from
the wireless-drivers tree and commit 87411456834a ("iwlwifi: clarify
the device / firmware mapping in Kconfig") from the
wireless-drivers-next tree.

I fixed it up (see below) and can carry the fix as necessary (no action
is required).

-- 
Cheers,
Stephen Rothwells...@canb.auug.org.au

diff --cc drivers/net/wireless/iwlwifi/Kconfig
index f89f446e5c8a,99f9760fc11e..
--- a/drivers/net/wireless/iwlwifi/Kconfig
+++ b/drivers/net/wireless/iwlwifi/Kconfig
@@@ -21,7 -21,7 +21,8 @@@ config IWLWIF
Intel 7260 Wi-Fi Adapter
Intel 3160 Wi-Fi Adapter
Intel 7265 Wi-Fi Adapter
 +  Intel 3165 Wi-Fi Adapter
+   Intel 8260 Wi-Fi Adapter
  
  
  This driver uses the kernel's mac80211 subsystem.


pgpLTUHJw2dsR.pgp
Description: OpenPGP digital signature

Re: [PATCH trivial] enic: Grammar s/an negative/a negative/

[David Miller]

From: Geert Uytterhoeven 
Date: Thu, 21 May 2015 14:09:14 +0200

> Signed-off-by: Geert Uytterhoeven 

Applied to net-next, thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH 2/4] x86, mwaitt: introduce mwaitx idle with a configurable timer

[Huang Rui]

On Wed, May 20, 2015 at 07:11:20PM +0800, Ingo Molnar wrote:
> 
> * Borislav Petkov  wrote:
> 
> > On Wed, May 20, 2015 at 12:22:58PM +0200, Ingo Molnar wrote:
> >
> > > Well, HLT does not get any hint from the OS how long the idling is 
> > > expected to last.
> > 
> > MWAIT on AMD doesn't either:
> 
> Yeah, MWAIT clearly doesn't, but I was talking about MWAITX, which 
> takes a timeout parameter as per these patches.
> 
> > > Another MWAITX round - we've got no crystal ball, so the hint 
> > > might be wrong if an external event occurs that we did not 
> > > anticipate.
> > 
> > So if we end up doing a bunch of MWAITX rounds instead of HLT and 
> > MWAITX saves less power than HLT, then we practically are worse.
> 
> So the way I think it would work ideally is (and note that this is 
> different from how you think it works):
> 
>   - MWAITX takes a 'timeout' parameter, but otherwise behaves exactly 
> like MWAIT: i.e. once idle it won't exit idle on its own
> 
>   - based on the 'timeout' hint, MWAITX can internally optimize how 
> deep sleep it enters. If the timeout is large it goes deep, if 
> it's small, it goes shallow. This does not change the fact that no 
> matter which state it enters, it will come back the moment an 
> interrupt is posted.

No, the timeout value doesn't decide how 'deep' the power state enters.
Basically, the same power consumption with any timeout.

I summarized the comparison of mwait and mwaitx

MWAIT   MWAITX
opcode  0f 01 c9   |0f 01 fb
ECX[0]  value of RFLAGS.IF seen by instruction
ECX[1]  unused/#GP if set  |enable timer if set
ECX[31:2] unused/#GP if set
EAX unused
EBX[31:0]   unused |max wait time (loops)


MONITOR MONITORX
opcode  0f 01 c8   |0f 01 fa
EAX (logical) address to monitor
ECX #GP if not zero

Thanks,
Rui
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Payment

[Finance Department]

Dear Winner,

You have been awarded the sum of  8,000,000.00 (Eight Million Pounds sterling) 
with reference number 77100146. This compensation funds from the United 
Nation.Send us your personal details to deliver your funds.

Gloria Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] i2c: designware: Avoid unnecessary resuming during system suspend

[Jisheng Zhang]

Dear Wolfram, Mika,

On Thu, 21 May 2015 14:40:49 +0300
Mika Westerberg  wrote:

> [Adding Jarkko, just in case he has concerns about this]
> 
> On Wed, May 20, 2015 at 10:33:13PM +0800, Jisheng Zhang wrote:
> > Commit 1fc2fe204cb9 ("i2c: designware: Add runtime PM hooks") adds
> > runtime pm support using the same ops for system pm and runtime pm.
> > When suspend to ram, the i2c host may have been runtime suspended, thus
> > i2c_dw_disable() hangs.
> > 
> > Previously, I fixed this issue by separating ops for system pm and
> > runtime pm, then in the system suspend/resume path, runtime pm apis are
> > used to ensure the device is at correct state.
> > 
> > But as Mika Westerberg pointed out: it sounds a bit silly to resume the
> > device just because you want to call i2c_dw_disable() for it before
> > suspending again. He then suggested an elegant solution which keeps the
> > device runtime suspended during system suspend with the help of
> > 'dev->power.direct_complete'. This patch adopted this solution, and in
> > fact Mika provided the main code.
> > 
> > Signed-off-by: Jisheng Zhang 
> > ---
> >  v2 change:
> > - adopt Mika's suggestion to make use of direct_complete flag
> > 
> >  drivers/i2c/busses/i2c-designware-platdrv.c | 33 
> > +
> >  1 file changed, 29 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c 
> > b/drivers/i2c/busses/i2c-designware-platdrv.c
> > index 0a80e4a..f89650f 100644
> > --- a/drivers/i2c/busses/i2c-designware-platdrv.c
> > +++ b/drivers/i2c/busses/i2c-designware-platdrv.c
> > @@ -298,6 +298,22 @@ static const struct of_device_id dw_i2c_of_match[] = {
> >  MODULE_DEVICE_TABLE(of, dw_i2c_of_match);
> >  #endif
> >  
> > +#ifdef CONFIG_PM_SLEEP
> > +static int dw_i2c_prepare(struct device *dev)
> > +{
> > +   return pm_runtime_suspended(dev);
> > +}
> > +
> > +static void dw_i2c_complete(struct device *dev)
> > +{
> > +   if (dev->power.direct_complete)
> > +   pm_request_resume(dev);
> > +}
> > +#else
> > +#define dw_i2c_prepare NULL
> > +#define dw_i2c_completeNULL
> > +#endif
> > +
> >  #ifdef CONFIG_PM
> >  static int dw_i2c_suspend(struct device *dev)
> >  {
> > @@ -322,10 +338,19 @@ static int dw_i2c_resume(struct device *dev)
> >  
> > return 0;
> >  }
> > -#endif
> >  
> > -static UNIVERSAL_DEV_PM_OPS(dw_i2c_dev_pm_ops, dw_i2c_suspend,
> > -   dw_i2c_resume, NULL);
> > +static const struct dev_pm_ops dw_i2c_dev_pm_ops = {
> > +   .prepare = dw_i2c_prepare,
> > +   .complete = dw_i2c_complete,
> > +   SET_SYSTEM_SLEEP_PM_OPS(dw_i2c_suspend, dw_i2c_resume)
> > +   SET_RUNTIME_PM_OPS(dw_i2c_suspend,
> > +   dw_i2c_resume, NULL)
> 
> No need to wrap here. It will fit into 80 chars limit.

OOPs, yes. Do I need to send a new version?

> 
> Otherwise looks good to me. I also tested this on Braswell and Skylake
> machines where it didn't cause any problems,
> 
> Acked-by: Mika Westerberg 
> Tested-by: Mika Westerberg 
> 

Thanks for these.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v5] serial: 8250_uniphier: add UniPhier serial driver

[Masahiro Yamada]

Add the driver for on-chip UART used on UniPhier SoCs.

This hardware is similar to 8250, but the register mapping is
slightly different:
  - The offset to FCR, MCR is different.
  - The divisor latch access bit does not exist.  Instead, the
divisor latch register is available at offset 9.

This driver overrides serial_{in,out}, dl_{read,write} callbacks,
but wants to borrow most of code from 8250_core.c.

Signed-off-by: Masahiro Yamada 
Reviewed-by: Matthias Brugger 
---

Changes in v5:
  - Set up.port.mapsize
  - Pass NULL rahter than 0 to the second argument of devm_clk_get()

Changes in v4:
  - Use spin_lock for read-modify-write register access
  - Add /* fall through */ comments where I intentionally
did not add "break";
  - Drop unnecessary #include 
  - Drop unnecessary #include 
  - Add an empty line between #include <> and ""
  - Use platform_get_irq() instead of platform_get_resource()

Changes in v3:
  - Just add *_SHIFT macro for the special case

Changes in v2:
  - Drop unnecessary #include 
  - Sort includes in alphabetical order
  - Use devm_clk_get() rather than of_clk_get()
  - Delete unneeded clk_put() from uniphier_uart_remove callback
  - Delete unneeded IS_ERR_OR_NULL check from uniphier_uart_remove callback
  - Use UNIPHIER_UART_*_SHIFT instead of hard-coded shift values
  - Change the first argument type of uniphier_of_serial_setup()
from (struct platform_device *) to (struct device *) for code-cleanup.

 drivers/tty/serial/8250/8250_uniphier.c | 258 
 drivers/tty/serial/8250/Kconfig |   7 +
 drivers/tty/serial/8250/Makefile|   1 +
 3 files changed, 266 insertions(+)
 create mode 100644 drivers/tty/serial/8250/8250_uniphier.c

diff --git a/drivers/tty/serial/8250/8250_uniphier.c 
b/drivers/tty/serial/8250/8250_uniphier.c
new file mode 100644
index 000..13cc66b
--- /dev/null
+++ b/drivers/tty/serial/8250/8250_uniphier.c
@@ -0,0 +1,258 @@
+/*
+ * Copyright (C) 2015 Masahiro Yamada 
+ *
+ * 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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "8250.h"
+
+/* Most (but not all) of UniPhier UART devices have 64-depth FIFO. */
+#define UNIPHIER_UART_DEFAULT_FIFO_SIZE64
+
+#define UNIPHIER_UART_CHAR_FCR 3   /* Character / FIFO Control Register */
+#define UNIPHIER_UART_LCR_MCR  4   /* Line/Modem Control Register */
+#define   UNIPHIER_UART_LCR_SHIFT  8
+#define UNIPHIER_UART_DLR  9   /* Divisor Latch Register */
+
+struct uniphier8250_priv {
+   int line;
+   struct clk *clk;
+   spinlock_t atomic_write_lock;
+};
+
+/*
+ * The register map is slightly different from that of 8250.
+ * IO callbacks must be overridden for correct access to FCR, LCR, and MCR.
+ */
+static unsigned int uniphier_serial_in(struct uart_port *p, int offset)
+{
+   int valshift = 0;
+
+   switch (offset) {
+   case UART_LCR:
+   valshift = UNIPHIER_UART_LCR_SHIFT;
+   /* fall through */
+   case UART_MCR:
+   offset = UNIPHIER_UART_LCR_MCR;
+   break;
+   default:
+   break;
+   }
+
+   offset <<= p->regshift;
+
+   /*
+* The return value must be masked with 0xff because LCR and MCR reside
+* in the same register that must be accessed by 32-bit write/read.
+* 8 or 16 bit access to this hardware result in unexpected behavior.
+*/
+   return (readl(p->membase + offset) >> valshift) & 0xff;
+}
+
+static void uniphier_serial_out(struct uart_port *p, int offset, int value)
+{
+   int valshift = 0;
+   bool normal = false;
+
+   switch (offset) {
+   case UART_FCR:
+   offset = UNIPHIER_UART_CHAR_FCR;
+   break;
+   case UART_LCR:
+   valshift = UNIPHIER_UART_LCR_SHIFT;
+   /* Divisor latch access bit does not exist. */
+   value &= ~(UART_LCR_DLAB << valshift);
+   /* fall through */
+   case UART_MCR:
+   offset = UNIPHIER_UART_LCR_MCR;
+   break;
+   default:
+   normal = true;
+   break;
+   }
+
+   offset <<= p->regshift;
+
+   if (normal) {
+   writel(value, p->membase + offset);
+   } else {
+   /*
+* Special case: two registers share the same address that
+* must be 32-bit accessed.  As this is not longer atomic safe,
+* take a 

[PATCH] base:cacheinfo - Fix for typos in comment and pr_warn log message

[Shailendra Verma]

Signed-off-by: Shailendra Verma 
---
 drivers/base/cacheinfo.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c
index 9c2ba1c..c75bda8 100644
--- a/drivers/base/cacheinfo.c
+++ b/drivers/base/cacheinfo.c
@@ -191,12 +191,12 @@ static int detect_cache_attributes(unsigned int cpu)
if (ret)
goto free_ci;
/*
-* For systems using DT for cache hierarcy, of_node and shared_cpu_map
+* For systems using DT for cache hierarchy, of_node and shared_cpu_map
 * will be set up here only if they are not populated already
 */
ret = cache_shared_cpu_map_setup(cpu);
if (ret) {
-   pr_warn("Unable to detect cache hierarcy from DT for CPU %d\n",
+   pr_warn("Unable to detect cache hierarchy from DT for CPU %d\n",
cpu);
goto free_ci;
}
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 0/2] Add MediaTek display PWM driver

[Yingjoe Chen]

On Thu, 2015-05-21 at 21:29 +0800, YH Huang wrote:
> YH Huang (2):
>   dt-bindings: pwm: add MediaTek display PWM bindings
>   pwm: add MediaTek display PWM driver support
> 
>  .../devicetree/bindings/pwm/pwm-mtk-disp.txt   |  25 +++
>  drivers/pwm/Kconfig|  10 +
>  drivers/pwm/Makefile   |   1 +
>  drivers/pwm/pwm-mtk-disp.c | 228 
> +
>  4 files changed, 264 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt
>  create mode 100644 drivers/pwm/pwm-mtk-disp.c

Hi YH,

It would be easier for reviewer if you have a summary here on what you
have changed compare to last version.
Also, please add patch series summary even for v2, it remind reviewer
what this series is about.

Joe.C

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] extcon: Add extcon_set_cable_line_state() to inform the additional state of external connectors

[Peter Chen]

On Fri, May 22, 2015 at 07:49:49PM +0900, Chanwoo Choi wrote:
> This patch adds the extcon_set_cable_line_state() function to inform
> the additional state of each external connector and 'enum extcon_line_state'
> enumeration which include the specific states of each external connector.
> 
> The each external connector might need the different line state. So, current
> 'extcon_line_state' enumeration contains the specific state for USB as
> following:
> 
> - Following the state mean the state of both ID and VBUS line for USB:
> enum extcon_line_state {
>   EXTCON_USB_ID_LOW   = BIT(1),   /* ID line is low. */
>   EXTCON_USB_ID_HIGH  = BIT(2),   /* ID line is high. */
>   EXTCON_USB_VBUS_LOW = BIT(3),   /* VBUS line is low. */
>   EXTCON_USB_VBUS_HIGH= BIT(4),   /* VBUS line is high. */
> };
> 
> Cc: Myungjoo Ham 
> Signed-off-by: Chanwoo Choi 
> ---
>  drivers/extcon/extcon.c | 74 
> -
>  include/linux/extcon.h  | 24 
>  2 files changed, 97 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c
> index 5099c11..2f7db54 100644
> --- a/drivers/extcon/extcon.c
> +++ b/drivers/extcon/extcon.c
> @@ -279,7 +279,9 @@ int extcon_update_state(struct extcon_dev *edev, u32 
> mask, u32 state)
>  
>   for (index = 0; index < edev->max_supported; index++) {
>   if (is_extcon_changed(edev->state, state, index, 
> ))
> - raw_notifier_call_chain(>nh[index], 
> attached, edev);
> + raw_notifier_call_chain(>nh[index],
> + attached ? EXTCON_ATTACHED :
> + EXTCON_DETACHED, edev);
>   }
>  
>   edev->state &= ~mask;
> @@ -418,6 +420,69 @@ int extcon_set_cable_state(struct extcon_dev *edev,
>  EXPORT_SYMBOL_GPL(extcon_set_cable_state);
>  
>  /**
> + * extcon_set_cable_line_state() - Set the line state of specific cable.
> + * @edev:the extcon device that has the cable.
> + * @id:  the unique id of each external connector.
> + * @state:   the line state for specific cable.
> + *
> + * Note that this function support the only USB connector to inform the state
> + * of both ID and VBUS line until now. This function may be extended to 
> support
> + * the additional external connectors.
> + *
> + * If the id is EXTCON_USB, it can support only following line states:
> + * - EXTCON_USB_ID_LOW
> + * - EXTCON_USB_ID_HIGH,
> + * - EXTCON_USB_VBUS_LOW
> + * - EXTCON_USB_VBUS_HIGH
> + */
> +int extcon_set_cable_line_state(struct extcon_dev *edev, enum extcon id,
> + enum extcon_line_state state)
> +{
> + unsigned long flags;
> + unsigned long line_state;
> + int ret = 0, index;
> +
> + index = find_cable_index_by_id(edev, id);
> + if (index < 0)
> + return index;
> +
> + spin_lock_irqsave(>lock, flags);
> + line_state = edev->line_state[index];
> +
> + switch (id) {
> + case EXTCON_USB:
> + if (line_state & state) {
> + dev_info(>dev,
> + "0x%x state is already set for %s\n",
> + state, extcon_name[id]);
> + goto err;
> + }

dev_warning?


-- 

Best Regards,
Peter Chen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] cpufreq:exynos-cpufreq - Fix for memory leak in case SOC name does not match.

[Shailendra Verma]

During probe free the memory allocated to "exynos_info" in case of
unknown SOC type.

Signed-off-by: Shailendra Verma 
---
 drivers/cpufreq/exynos-cpufreq.c |6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/cpufreq/exynos-cpufreq.c b/drivers/cpufreq/exynos-cpufreq.c
index 82d2fbb..8682378 100644
--- a/drivers/cpufreq/exynos-cpufreq.c
+++ b/drivers/cpufreq/exynos-cpufreq.c
@@ -182,7 +182,7 @@ static int exynos_cpufreq_probe(struct platform_device 
*pdev)
ret = exynos5250_cpufreq_init(exynos_info);
} else {
pr_err("%s: Unknown SoC type\n", __func__);
-   return -ENODEV;
+   ret = -ENODEV;
}
 
if (ret)
@@ -190,12 +190,14 @@ static int exynos_cpufreq_probe(struct platform_device 
*pdev)
 
if (exynos_info->set_freq == NULL) {
dev_err(>dev, "No set_freq function (ERR)\n");
+   ret = -EINVAL;
goto err_vdd_arm;
}
 
arm_regulator = regulator_get(NULL, "vdd_arm");
if (IS_ERR(arm_regulator)) {
dev_err(>dev, "failed to get resource vdd_arm\n");
+   ret = -EINVAL;
goto err_vdd_arm;
}
 
@@ -227,7 +229,7 @@ err_cpufreq_reg:
regulator_put(arm_regulator);
 err_vdd_arm:
kfree(exynos_info);
-   return -EINVAL;
+   return ret;
 }
 
 static struct platform_driver exynos_cpufreq_platdrv = {
-- 
1.7.9.5

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Payment

[Finance Department]

Dear Winner,

You have been awarded the sum of  8,000,000.00 (Eight Million Pounds sterling) 
with reference number 77100146. This compensation funds from the United 
Nation.Send us your personal details to deliver your funds.

Gloria Peter
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 6/7] Watchdog: introduce ARM SBSA watchdog driver

[Fu Wei]

Hi Guenter,


On 25 May 2015 at 01:47, Timur Tabi  wrote:
> Guenter Roeck wrote:
>>
>>
>> The pseudo-code in the specification suggests that if WCV is configured,
>>  WS0 = WCV
>>  WS1 = WCV + WOR
>>
>> Assuming that the implementation follows the pseudo-code in the
>> specification,
>> we would have separately programmable values. Since the pretimeout (per
>> ABI)
>> is the difference in seconds to the timeout, and not an absolute value,
>> we would have to program the registers as follows.
>>
>>  WCV = timeout - pretimeout;
>>  WOR = pretimeout;
>>
>> Does this make sense ?

And actually all the patchset  I sent to upstream are all follow this
design, and have been test on Foundation model and Seattle B0

>
>
> Yes, thank you.  I will test this on my hardware.
>
>
> --
> Sent by an employee of the Qualcomm Innovation Center, Inc.
> The Qualcomm Innovation Center, Inc. is a member of the
> Code Aurora Forum, hosted by The Linux Foundation.



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 6/7] Watchdog: introduce ARM SBSA watchdog driver

[Fu Wei]

Hi, Guenter,



On 25 May 2015 at 01:32, Guenter Roeck  wrote:
> On 05/24/2015 10:19 AM, Timur Tabi wrote:
>>
>> Fu Wei wrote:
>>>
>>> I don't know why you want to do this tricky way.  you can always
>>> register the interrupt handler,
>>> if pre-timeout is 0, system will just trigger WS1 right after WS0
>>
>>
>> But that only works if the pre-timeout and timeout can be programmed to
>> separate values.  And as Guenter says, the SBSA may not guarantee that.
>>
>
> The pseudo-code in the specification suggests that if WCV is configured,
> WS0 = WCV
> WS1 = WCV + WOR
>
> Assuming that the implementation follows the pseudo-code in the
> specification,
> we would have separately programmable values. Since the pretimeout (per ABI)
> is the difference in seconds to the timeout, and not an absolute value,
> we would have to program the registers as follows.
>
> WCV = timeout - pretimeout;
> WOR = pretimeout;

yes, this patchset is doing this way.

>
> Does this make sense ?
>
> Thanks,
> Guenter
>



-- 
Best regards,

Fu Wei
Software Engineer
Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch
Ph: +86 21 61221326(direct)
Ph: +86 186 2020 4684 (mobile)
Room 1512, Regus One Corporate Avenue,Level 15,
One Corporate Avenue,222 Hubin Road,Huangpu District,
Shanghai,China 200021
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: usb: gadget: f_fs: O_NONBLOCK waits MAX_SCHEDULE_TIMEOUT

[Peter Chen]

 
> >>>
> >>> FunctionFS is very specific, because read/write operations are
> >>> directly translated into USB requests, which are asynchronous, so
> >>> you cannot use O_NONBLOCK.
> >>>
> >>> If you need non-blocking API you can use Asynchronous I/O (AIO). You
> >>> can find some examples in kernel sources (tools/usb/ffs-aio-example/).
> >>>
> >>> Br,
> >>> Robert Baldyga
> >>>
> >>
> >> Thank you, that sounds like the best approach.
> >> In this case I think perhaps the long wait without any data is an
> >> problem with the imx6 Chipidea USB controller.
> >
> > What's the possible problem?
> 
> Sorry for the delay in replying, I have been getting some more details with a
> USB Analyser.
> 
> The scenario is that the NCM  device is enumerating so we see the messages to:
> 
> SetAddress (1)
> GetDescriptor (Device)
> GetDescriptor (StringN)
> GetDescriptor (Configuration)
> SetConfiguration (1)
> GetDescriptor (String iInterface)
> GetDescriptor (String iInterface)
> 
> At this point the NCM host sends Writes to the F_FS EP0 but for some reason
> the host device does not respond and only issues SOF packets for hours. This
> happens occasionally and is fixed by turning the device off and on again.
> 
> 

We may find this 'some reason', is it device error or host error?

Do you have below patch in your code:

commit 953c66469735aed8d2ada639a72b150f01dae605
Author: Abbas Raza 
Date:   Thu Jul 17 19:34:31 2014 +0800

usb: chipidea: udc: Disable auto ZLP generation on ep0

There are 2 methods for ZLP (zero-length packet) generation:
1) In software
2) Automatic generation by device controller

1) is implemented in UDC driver and it attaches ZLP to IN packet if
   descriptor->size < wLength
2) can be enabled/disabled by setting ZLT bit in the QH

Peter

> Unless I am mistaken from a NCM gadget point of view the attached device is
> working correctly and there is no way to know it has failed, is that correct?
> 
> >
> >>
> >> I guess it should suspend and drop the connections if there is no
> >> traffic for more than 10ms?
> >>
> >
> > If the Device side NAK host's IN/OUT token continually, the pipe will
> > not be stopped, the host will send token continually until the
> > application cancel this request.
> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] serial: 8250: remove return statements from void function

[Masahiro Yamada]

2015-05-25 4:46 GMT+09:00 Greg Kroah-Hartman :
> On Mon, May 11, 2015 at 12:30:22PM +0900, Masahiro Yamada wrote:
>> serial8250_set_mctrl() is a void type function.  Returning something
>> does not look nice.
>>
>> Signed-off-by: Masahiro Yamada 
>> ---
>>
>>  drivers/tty/serial/8250/8250_core.c | 5 +++--
>>  1 file changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/tty/serial/8250/8250_core.c 
>> b/drivers/tty/serial/8250/8250_core.c
>> index 4882027..146f56c 100644
>> --- a/drivers/tty/serial/8250/8250_core.c
>> +++ b/drivers/tty/serial/8250/8250_core.c
>> @@ -2019,8 +2019,9 @@ EXPORT_SYMBOL_GPL(serial8250_do_set_mctrl);
>>  static void serial8250_set_mctrl(struct uart_port *port, unsigned int mctrl)
>>  {
>>   if (port->set_mctrl)
>> - return port->set_mctrl(port, mctrl);
>> - return serial8250_do_set_mctrl(port, mctrl);
>> + port->set_mctrl(port, mctrl);
>> + else
>> + serial8250_do_set_mctrl(port, mctrl);
>>  }
>
> You just changed the logic here!


Could you tell me why?

The logic still looks the same to me.




-- 
Best Regards
Masahiro Yamada
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [char-misc-next 11/11] mei: revamp mei bus code

[Greg KH]

On Sun, May 24, 2015 at 09:29:41PM +, Winkler, Tomas wrote:
> > 
> > On Thu, May 07, 2015 at 03:54:08PM +0300, Tomas Winkler wrote:
> > > MEI bus was designed around nfc and was hard to extend.
> > > Instead of hard coded way of adding the devices on the mei bus
> > > we scan whole me client list and create a device for each
> > > eligible me client; currently we support only clients with
> > > single connection and fixed address clients.
> > > NFC radio name detection is run as a fixup routine
> > >
> > > Cc: Samuel Ortiz 
> > > Signed-off-by: Tomas Winkler 
> > > ---
> > >  drivers/misc/mei/Makefile|   2 +-
> > >  drivers/misc/mei/bus-fixup.c | 306 ++
> > >  drivers/misc/mei/bus.c   | 975 
> > > 
> > ---
> > >  drivers/misc/mei/client.c|   9 +-
> > >  drivers/misc/mei/init.c  |   5 +-
> > >  drivers/misc/mei/mei_dev.h   |  24 +-
> > >  drivers/misc/mei/nfc.c   | 414 --
> > >  include/linux/mei_cl_bus.h   |  12 +
> > >  8 files changed, 968 insertions(+), 779 deletions(-)
> > >  create mode 100644 drivers/misc/mei/bus-fixup.c
> > >  delete mode 100644 drivers/misc/mei/nfc.c
> > 
> > This is a lot to do in just one patch.  Any chance you can split it up
> > into reviewable pieces?
> 
> I thought it would be harder to swallow but I'm not sure how to really 
> split this into working pieces w/o do some artificial steps which
>  I will have to validate again to keep the code bisectable. 

That's fine, that's your job to do :)

> What could be naturally factored out is already in separate  patches in this 
> series. 
> The patch is maybe bigger because of code moves between files but what has 
> really changes is just bus.c 

Then do the movement of functions around in one patch, and then the
logical changes in others.  Come on, you know how this whole thing
works, don't be lazy here...

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-sunxi] [PATCH 1/2] mmc: sunxi: fix timeout in sunxi_mmc_oclk_onoff

[Julian Calaby]

Hi Michal,

On Mon, May 25, 2015 at 4:07 AM, Michal Suchanek  wrote:
> The 250ms timeout is too short.
>
> On my system enabling the oclk takes under 50ms and disabling slightly
> over 100ms when idle. Under load disabling the clock can take over
> 350ms.
>
> This does not make mmc clock gating look like good option to have on
> sunxi but the system should not crash with mmc clock gating enabled
> nonetheless.
>
> This patch sets the timeout to 750ms and adds debug prints which show
> how long enabling/disabling the clock took so more data can be collected
> from other systems.
>
> Signed-off-by: Michal Suchanek 
> ---
>  drivers/mmc/host/sunxi-mmc.c | 22 +++---
>  1 file changed, 19 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/mmc/host/sunxi-mmc.c b/drivers/mmc/host/sunxi-mmc.c
> index 4d3e1ff..7cdeecd 100644
> --- a/drivers/mmc/host/sunxi-mmc.c
> +++ b/drivers/mmc/host/sunxi-mmc.c
> @@ -595,7 +595,7 @@ static irqreturn_t sunxi_mmc_handle_manual_stop(int irq, 
> void *dev_id)
>
>  static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host *host, u32 oclk_en)
>  {
> -   unsigned long expire = jiffies + msecs_to_jiffies(250);
> +   unsigned long start, end;
> u32 rval;
>
> rval = mmc_readl(host, REG_CLKCR);
> @@ -604,6 +604,8 @@ static int sunxi_mmc_oclk_onoff(struct sunxi_mmc_host 
> *host, u32 oclk_en)
> if (oclk_en)
> rval |= SDXC_CARD_CLOCK_ON;
>
> +   start = jiffies;
> +   end = start + msecs_to_jiffies(750);

You might want to make the timeout value a #define so it's not buried
in the code like this.

Thanks,

-- 
Julian Calaby

Email: julian.cal...@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 4.1-rc5

[Linus Torvalds]

I'm back on my usual Sunday schedule, and rc5 is back to its usual
size after a small bump in rc4.

Things continue to look pretty normal. We've got about two thirds
driver updates (gpu, infiniband, sound, networking, scsi, thermal),
and almost half of the remainder is networking updates. The rest is
mostly arch updates and some filesystem fixes. But all of it is pretty
small.

So we're on schedule for a normal 4.1 release, if it wasn't for the
fact that the timing looks like the next merge window would hit our
yearly family vacation. So we'll see how that turns out, I might end
up delaying the release just to avoid that (or just delay opening the
merge window). I haven't decided yet.

But please keep testing,

   Linus

---

Alex Deucher (2):
  drm/radeon: retry dcpd fetch
  drm/radeon: fix error flag checking in native aux path

Alexey Kardashevskiy (1):
  lpfc: Fix breakage on big endian kernels

Andrea Arcangeli (1):
  kvm: fix crash in kvm_vcpu_reload_apic_access_page

Aneesh Kumar K.V (2):
  powerpc/thp: Serialize pmd clear against a linux page table walk.
  powerpc/mm: Return NULL for not present hugetlb page

Ansgar Hegerfeld (1):
  ALSA: hda/realtek - ALC292 dock fix for Thinkpad L450

Anton Blanchard (1):
  powerpc: Align TOC to 256 bytes

Archit Taneja (1):
  drm: msm: Fix build when legacy fbdev support isn't set

Arnd Bergmann (1):
  ALSA: sound/atmel/ac97c.c: remove unused variable

Arun Parameswaran (1):
  net: core: 'ethtool' issue with querying phy settings

Axel Lin (2):
  ASoC: mc13783: Fix wrong mask value used in mc13xxx_reg_rmw() calls
  ASoC: rt5645: Fix mask for setting RT5645_DMIC_2_DP_GPIO12 bit

Benjamin Tissoires (2):
  Revert "HID: logitech-hidpp: support combo keyboard touchpad TK820"
  Input: elantech - fix semi-mt protocol for v3 HW

Bjorn Helgaas (1):
  net/mlx4: Avoid 'may be used uninitialized' warnings

Bjørn Mork (1):
  cdc_ncm: Fix tx_bytes statistics

Boris Ostrovsky (1):
  xen/arm: Define xen_arch_suspend()

Chanwoo Choi (3):
  clk: Use CONFIG_ARCH_EXYNOS instead of CONFIG_ARCH_EXYNOS5433
  clk: exynos5433: Fix wrong parent clock of sclk_apollo clock
  clk: exynos5433: Fix wrong PMS value of exynos5433_pll_rates

Chris Mason (1):
  Btrfs: fix regression in raid level conversion

Christoph Hellwig (1):
  nvme: fix kernel memory corruption with short INQUIRY buffers

Chuck Lever (1):
  nfs: stat(2) fails during cthon04 basic test5 on NFSv4.0

Daniel Axtens (1):
  powerpc/mce: fix off by one errors in mce event handling

Daniel Borkmann (1):
  net: sched: fix call_rcu() race on classifier module unloads

Dave Jones (1):
  netfilter: ensure number of counters is >0 in do_replace()

David Henningsson (3):
  ALSA: hda - Add headset mic quirk for Dell Inspiron 5548
  ALSA: hda - Fix headset mic and mic-in for a Dell desktop
  ALSA: hda - Add Conexant codecs CX20721, CX20722, CX20723 and CX20724

David Vrabel (1):
  xen/events: don't bind non-percpu VIRQs with percpu chip

Devesh Sharma (3):
  RDMA/ocrdma: Report EQ full fatal error
  RDMA/ocrdma: Fix QP state transition in destroy_qp
  RDMA/ocrdma: Use VID 0 if PFC is enabled and vlan is not configured

Dmitry Torokhov (1):
  Input: sx8654 - fix memory allocation check

Dmitry Tunin (1):
  Bluetooth: ath3k: add support of 04ca:300f AR3012 device

Dong Aisheng (1):
  clk: add missing lock when call clk_core_enable in clk_set_parent

Eric Dumazet (4):
  netlink: move nl_table in read_mostly section
  inet: properly align icsk_ca_priv
  tcp: fix a potential deadlock in tcp_get_info()
  bridge: fix lockdep splat

Eric W. Biederman (1):
  ipv4: Avoid crashing in ip_error

Eric Work (1):
  md/raid0: fix restore to sector variable in raid0_make_request

Fang, Yang A (1):
  ASoC: rt5645: Add ACPI match ID

Filipe Manana (1):
  Btrfs: fix racy system chunk allocation when setting block group ro

Florent Fourcot (1):
  tcp/ipv6: fix flow label setting in TIME_WAIT state

Florian Fainelli (1):
  net: phy: Allow EEE for all RGMII variants

Florian Westphal (2):
  netfilter: avoid build error if TPROXY/SOCKET=y && NF_DEFRAG_IPV6=m
  Revert "netfilter: bridge: query conntrack about skb dnat"

Francesco Ruggeri (1):
  netfilter: nfnetlink_{log,queue}: Register pernet in first place

Georgi Djakov (2):
  clk: qcom: Fix MSM8916 venus divider value
  clk: qcom: Fix MSM8916 gfx3d_clk_src configuration

Hai Li (3):
  drm/msm/dsi: Fixup missing *break* statement during cmd rx
  drm/msm: Attach assigned encoder to eDP and DSI connectors
  drm/msm/dsi: Simplify the code to get the number of read byte

Hans de Goede (1):
  Input: alps - fix finger jumps on lifting 2 fingers on v7 touchpad

Harald Freudenberger (2):
  s390/crypto: fix stckf loop
  crypto: s390/ghash - Fix incorrect ghash icv buffer 

Re: BUG: rwlock bad magic on CPU#1, NetworkManager/

[Jeremiah Mahler]

Johannes,

On Tue, May 19, 2015 at 12:15:28AM -0700, Jeremiah Mahler wrote:
> Johannes,
> 
> You mentioned off-list that you might have a fix for this somewhere in
> mac80211-next.  Do you have any idea when this will make it in to -next?
> It is still broken as of -next 20150518.
> 
> -- 
> - Jeremiah Mahler

As of next-20150522 this bug is fixed.

Thanks Johannes.

-- 
- Jeremiah Mahler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v6 2/2] kconfig: add xenconfig defconfig helper

[Masahiro Yamada]

Hi Luis,

2015-05-22 3:47 GMT+09:00 Luis R. Rodriguez :
> On Thu, May 21, 2015 at 11:49:17PM +0900, Masahiro Yamada wrote:
>> Hi,
>>
>> I am not familiar with xen at all, just some comments
>> from the build system side.
>>
>>
>>
>> 2015-05-21 3:53 GMT+09:00 Luis R. Rodriguez :
>> > From: "Luis R. Rodriguez" 
>> >
>> > This lets you build a kernel which can support xen dom0
>> > or xen guests on i386, x86-64 and arm64 by just using:
>> >
>> >make xenconfig
>> >
>> > You can start from an allnoconfig and then switch to xenconfig.
>> > This also splits out the options which are available currently
>> > to be built with x86 and 'make ARCH=arm64' under a shared config.
>> >
>> > Technically xen supports a dom0 kernel and also a guest
>> > kernel configuration but upon review with the xen team
>> > since we don't have many dom0 options its best to just
>> > combine these two into one.
>> >
>> > A few generic notes: we enable both of these:
>> >
>> > CONFIG_INET=y
>> > CONFIG_BINFMT_ELF=y
>> >
>> > although technically not required given you likely will
>> > end up with a pretty useless system otherwise.
>> >
>> > A few architectural differences worth noting:
>> >
>> > $ make allnoconfig; make xenconfig > /dev/null ; \
>> > grep XEN .config > 64-bit-config
>> > $ make ARCH=i386 allnoconfig; make ARCH=i386 xenconfig > /dev/null; \
>> > grep XEN .config > 32-bit-config
>> > $ make ARCH=arm64 allnoconfig; make ARCH=arm64 xenconfig > /dev/null; \
>> > grep XEN .config > arm64-config
>> >
>> > Since the options are already split up with a generic config and
>> > architecture specific configs you anything on the x86 configs
>> > are known to only work right now on x86. For instance arm64 doesn't
>> > support MEMORY_HOTPLUG yet as such although we try to enabe it
>> > generically arm64 doesn't have it yet, so we leave the xen
>> > specific kconfig option XEN_BALLOON_MEMORY_HOTPLUG on x86's config
>> > file to set expecations correctly.
>> >
>> > Then on x86 we have differences between i386 and x86-64. The difference
>> > between 64-bit-config and 32-bit-config is you don't get XEN_MCE_LOG as
>> > this is only supported on 64-bit. You also do not get on i386
>> > XEN_BALLOON_MEMORY_HOTPLUG, there does not seem to be any technical
>> > reasons to not allow this but I gave up after a few attempts.
>> >
>> > Cc: Josh Triplett 
>> > Cc: Borislav Petkov 
>> > Cc: Pekka Enberg 
>> > Cc: David Rientjes 
>> > Cc: Michal Marek 
>> > Cc: Randy Dunlap 
>> > Cc: penb...@kernel.org
>> > Cc: levinsasha...@gmail.com
>> > Cc: mtosa...@redhat.com
>> > Cc: fengguang...@intel.com
>> > Cc: David Vrabel 
>> > Cc: Ian Campbell 
>> > Cc: Konrad Rzeszutek Wilk 
>> > Cc: xen-de...@lists.xenproject.org
>> > Acked-by: Stefano Stabellini 
>> > Acked-by: Julien Grall 
>> > Acked-by: Michal Marek 
>> > Acked-by: David Rientjes 
>> > Reviewed-by: Josh Triplett 
>> > Signed-off-by: Luis R. Rodriguez 
>> > ---
>>
>> > diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
>> > index 6950032..f52abae 100644
>> > --- a/scripts/kconfig/Makefile
>> > +++ b/scripts/kconfig/Makefile
>> > @@ -115,6 +115,10 @@ PHONY += kvmconfig
>> >  kvmconfig: kvm_guest.config
>> > @:
>> >
>> > +PHONY += xenconfig
>> > +xenconfig: xen.config
>> > +   @:
>> > +
>> >  PHONY += tinyconfig
>> >  tinyconfig:
>> > $(Q)$(MAKE) -f $(srctree)/Makefile allnoconfig tiny.config
>>
>>
>> "make xenconfig" is equivalent to "make xen.config"
>> and only saves one character.
>>
>> Now we have only three targets for mergeconfig (tiny, kvm, xen),
>> so it is OK to add this as an alias.
>> But if we have more such targets, we might have
>> to consider to use generic targets (*.config) at some point.
>
> I'm frankly terrified of all these config target options growing more and
> the possible large collateral of patches to Kconfig files in the future. Since
> this is a small specialized group now, I think we should treat it as such but
> I think what you say has good merit long run.
>
> For now I'm more of a fan we limit what we stuff in here and if this explodes
> then only have new options use the subject.config target. Thoughts?


Sounds good to me.






>> I do not intend to block this.
>> Just take my comment with a grain of salt..
>>
>>
>> > @@ -140,6 +144,7 @@ help:
>> > @echo  '  listnewconfig   - List new options'
>> > @echo  '  olddefconfig- Same as silentoldconfig but sets new 
>> > symbols to their default value'
>> > @echo  '  kvmconfig   - Enable additional options for kvm 
>> > guest kernel support'
>> > +   @echo  '  xenconfig   - Enable additional options for xen dom0 
>> > and guest kernel support'
>> > @echo  '  tinyconfig  - Configure the tiniest possible kernel'
>> >
>> >  # lxdialog stuff
>>
>>
>> If kvmconfig and xenconfig are only available for x86,
>> is it better to enclose those helps with
>> ifeq ($(ARCH),x86)
>>  ...
>> endif
>
> That's true if kvm was only 

Question about "Make sched entity usage tracking scale-invariant"

[Chao Xie]

hi
I saw the patch “sched: Make sched entity usage tracking scale-invariant” that 
will make the usage to be freq scaled.
So if delta period that the calculation of usage based on cross a frequency 
change, so how can you make sure the usage calculation is correct?
The delta period may last hundreds of microseconds, and frequency change window 
may be 10-20 microseconds, so many frequency change can happen during the delta 
period.
It seems the patch does not consider about it, and it just pick up the current 
one.
So how can you resolve this issue?

Thanks.N嫥叉靣笡y氊b瞂千v豝�)藓{.n�+壏{睉赙zXФ洝塄}财爖�:+v墾�珣赙zZ+€�+zf＂穐殘啳嗃iz�畐ア�?櫒璀�&�)撷f旟^j谦y呩@A玜囤
0鹅h�鍜i

Re: RaspberryPi "is this a real kernel?"

[Valdis . Kletnieks]

On Sun, 24 May 2015 11:32:36 +0100, John Whitmore said:

> $ ./mkknlimg ../../linux/arch/arm/boot/zImage 3.18.0-can+.img
> tail: +: invalid number of bytes
> * Is this a valid kernel? In pass-through mode.

Looks like they try to use 'tail' to skip over something, but the + sign
in your uname -r gives it indigestion.  Try building with a version name
that doesn't include a + sign, and complain to the maintainers of mkknlimg
that they've probably got a parameter quoting problem (most likely, there's
someplace a

tail -this -that $foo

needs to be

tail -this -that "$foo"


pgp4W08Xen4Zt.pgp
Description: PGP signature

Re: [PATCH 2/9 linux-next] nilfs2: remove dir_pages() declaration

[Ryusuke Konishi]

On Sun, 24 May 2015 17:19:42 +0200, Fabian Frederick  wrote:
> dir_pages() is now declared in pagemap.h
> 
> Signed-off-by: Fabian Frederick 
> ---
>  fs/nilfs2/dir.c | 5 -
>  1 file changed, 5 deletions(-)
> 
> diff --git a/fs/nilfs2/dir.c b/fs/nilfs2/dir.c
> index 0ee0bed..6b8b92b 100644
> --- a/fs/nilfs2/dir.c
> +++ b/fs/nilfs2/dir.c
> @@ -61,11 +61,6 @@ static inline void nilfs_put_page(struct page *page)
>   page_cache_release(page);
>  }
>  
> -static inline unsigned long dir_pages(struct inode *inode)
> -{
> - return (inode->i_size+PAGE_CACHE_SIZE-1)>>PAGE_CACHE_SHIFT;
> -}
> -

Can you include this and similar changes in the first patch
"pagemap.h: declare dir_pages()" ?

The first patch transiently breaks build because it inserts a
duplicate definition of the dir_pages() inline function until it gets
removed from each file system by the successive patches.

This series looks non-divisible except the patch of ufs.

Regards,
Ryusuke Konishi

>  /*
>   * Return the offset into page `page_nr' of the last valid
>   * byte in that page, plus one.
> -- 
> 2.4.1
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/2] ACPICA: Fix for ill-formed GUID strings for NFIT tables.

[Lv Zheng]

From: Bob Moore 

ACPICA commit 60052949ba2aa7377106870da69b237193d10dc1

Error in transcription from the ACPI spec.

Link: https://github.com/acpica/acpica/commit/60052949
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 include/acpi/acuuid.h |   16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/include/acpi/acuuid.h b/include/acpi/acuuid.h
index 7c6cbb0..80fe8cf 100644
--- a/include/acpi/acuuid.h
+++ b/include/acpi/acuuid.h
@@ -69,14 +69,14 @@
 
 /* NVDIMM - NFIT table */
 
-#define UUID_VOLATILE_MEMORY"4f940573-dafd-e344-b16c-3f22d252e5d0"
-#define UUID_PERSISTENT_MEMORY  "79d3f066-f3b4-7440-ac43-0d3318b78cdb"
-#define UUID_CONTROL_REGION "f601f792-b413-5d40-910b-299367e8234c"
-#define UUID_DATA_REGION"3005af91-865d-0e47-a6b0-0a2db9408249"
-#define UUID_VOLATILE_VIRTUAL_DISK  "5a53ab77-fc45-4b62-5560-f7b281d1f96e"
-#define UUID_VOLATILE_VIRTUAL_CD"30bd5a3d-7541-ce87-6d64-d2ade523c4bb"
-#define UUID_PERSISTENT_VIRTUAL_DISK"c902ea5c-074d-69d3-269f-4496fbe096f9"
-#define UUID_PERSISTENT_VIRTUAL_CD  "88810108-cd42-48bb-100f-5387d53ded3d"
+#define UUID_VOLATILE_MEMORY"7305944f-fdda-44e3-b16c-3f22d252e5d0"
+#define UUID_PERSISTENT_MEMORY  "66f0d379-b4f3-4074-ac43-0d3318b78cdb"
+#define UUID_CONTROL_REGION "92f701f6-13b4-405d-910b-299367e8234c"
+#define UUID_DATA_REGION"91af0530-5d86-470e-a6b0-0a2db9408249"
+#define UUID_VOLATILE_VIRTUAL_DISK  "77ab535a-45fc-624b-5560-f7b281d1f96e"
+#define UUID_VOLATILE_VIRTUAL_CD"3d5abd30-4175-87ce-6d64-d2ade523c4bb"
+#define UUID_PERSISTENT_VIRTUAL_DISK"5cea02c9-4d07-69d3-269f-4496fbe096f9"
+#define UUID_PERSISTENT_VIRTUAL_CD  "08018188-42cd-bb48-100f-5387d53ded3d"
 
 /* Miscellaneous */
 
-- 
1.7.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/2] ACPICA: acpihelp: Update for new NFIT table GUIDs.

[Lv Zheng]

From: Bob Moore 

ACPICA commit 83727bed8f715685a63a9f668e73c60496a06054

Add original UUIDs/GUIDs to the acuuid.h file.
Cleanup acpihelp output for UUIDs/GUIDs.

Link: https://github.com/acpica/acpica/commit/83727bed
Signed-off-by: Bob Moore 
Signed-off-by: Lv Zheng 
---
 include/acpi/acuuid.h |   43 ++-
 1 file changed, 34 insertions(+), 9 deletions(-)

diff --git a/include/acpi/acuuid.h b/include/acpi/acuuid.h
index 4955d5e..7c6cbb0 100644
--- a/include/acpi/acuuid.h
+++ b/include/acpi/acuuid.h
@@ -50,15 +50,40 @@
  * Note2: This file is standalone and should remain that way.
  */
 
-/* NFIT/NVDIMM */
+/* Controllers */
 
-#define UUID_VOLATILE_MEMORY"4F940573-DAFD-E344-B16C-3F22D252E5D0"
-#define UUID_PERSISTENT_MEMORY  "79D3F066-F3B4-7440-AC43-0D3318B78CDB"
-#define UUID_CONTROL_REGION "F601F792-B413-5D40-910B-299367E8234C"
-#define UUID_DATA_REGION"3005AF91-865D-0E47-A6B0-0A2DB9408249"
-#define UUID_VOLATILE_VIRTUAL_DISK  "5A53AB77-FC45-4B62-5560-F7B281D1F96E"
-#define UUID_VOLATILE_VIRTUAL_CD"30BD5A3D-7541-CE87-6D64-D2ADE523C4BB"
-#define UUID_PERSISTENT_VIRTUAL_DISK"C902EA5C-074D-69D3-269F-4496FBE096F9"
-#define UUID_PERSISTENT_VIRTUAL_CD  "88810108-CD42-48BB-100F-5387D53DED3D"
+#define UUID_GPIO_CONTROLLER"4f248f40-d5e2-499f-834c-27758ea1cd3f"
+#define UUID_USB_CONTROLLER "ce2ee385-00e6-48cb-9f05-2edb927c4899"
+#define UUID_SATA_CONTROLLER"e4db149b-fcfe-425b-a6d8-92357d78fc7f"
+
+/* Devices */
+
+#define UUID_PCI_HOST_BRIDGE"33db4d5b-1ff7-401c-9657-7441c03dd766"
+#define UUID_I2C_DEVICE "3cdff6f7-4267-4555-ad05-b30a3d8938de"
+#define UUID_POWER_BUTTON   "dfbcf3c5-e7a5-44e6-9c1f-29c76f6e059c"
+
+/* Interfaces */
+
+#define UUID_DEVICE_LABELING"e5c937d0-3553-4d7a-9117-ea4d19c3434d"
+#define UUID_PHYSICAL_PRESENCE  "3dddfaa6-361b-4eb4-a424-8d10089d1653"
+
+/* NVDIMM - NFIT table */
+
+#define UUID_VOLATILE_MEMORY"4f940573-dafd-e344-b16c-3f22d252e5d0"
+#define UUID_PERSISTENT_MEMORY  "79d3f066-f3b4-7440-ac43-0d3318b78cdb"
+#define UUID_CONTROL_REGION "f601f792-b413-5d40-910b-299367e8234c"
+#define UUID_DATA_REGION"3005af91-865d-0e47-a6b0-0a2db9408249"
+#define UUID_VOLATILE_VIRTUAL_DISK  "5a53ab77-fc45-4b62-5560-f7b281d1f96e"
+#define UUID_VOLATILE_VIRTUAL_CD"30bd5a3d-7541-ce87-6d64-d2ade523c4bb"
+#define UUID_PERSISTENT_VIRTUAL_DISK"c902ea5c-074d-69d3-269f-4496fbe096f9"
+#define UUID_PERSISTENT_VIRTUAL_CD  "88810108-cd42-48bb-100f-5387d53ded3d"
+
+/* Miscellaneous */
+
+#define UUID_PLATFORM_CAPABILITIES  "0811b06e-4a27-44f9-8d60-3cbbc22e7b48"
+#define UUID_DYNAMIC_ENUMERATION"d8c1a3a6-be9b-4c9b-91bf-c3cb81fc5daf"
+#define UUID_BATTERY_THERMAL_LIMIT  "4c2067e3-887d-475c-9720-4af1d3ed602e"
+#define UUID_THERMAL_EXTENSIONS "14d399cd-7a27-4b18-8fb4-7cb7b9f4e500"
+#define UUID_DEVICE_PROPERTIES  "daffd814-6eba-4d8c-8a91-bc9bbf4aa301"
 
 #endif /* __AUUID_H__ */
-- 
1.7.10

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/5] Documentation: devicetree: add Broadcom SATA binding

[Tejun Heo]

On Tue, May 12, 2015 at 04:28:19PM -0700, Brian Norris wrote:
> Signed-off-by: Brian Norris 

Applied to libata/for-4.2.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 0/5] AHCI and SATA PHY support for Broadcom STB SoCs

[Tejun Heo]

Hello, Brian.

On Thu, May 21, 2015 at 03:38:25PM -0700, Brian Norris wrote:
> It's possible you're confusing binding documentation with .dts source
> files? The DTS files (arch/*/boot/dts/) go through arch trees. For
> instance, the arm-soc maintainers have a structured process by which
> sub-architecture maintainers track .dts(i) file updates for their
> boards/chips and filter them up to Arnd, Olof, etc., via their separate
> 'dts' branches. That's why Florian took patch 5 to his tree.

Yeah, I think that's why I'm constantly getting confused, so the
binding documentation and actual libata changes through libata and the
rest through arch trees.  Got it.

Thanks for the explanation.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] fs: sysfs: don't pass count == 0 to bin file readers

[Tejun Heo]

On Fri, May 22, 2015 at 03:46:51AM +0300, Vladimir Zapolskiy wrote:
> Hello Tejun,
> 
> On 22.05.2015 02:26, Tejun Heo wrote:
> > Hello, Vladimir.
> > 
> > On Fri, May 22, 2015 at 02:04:31AM +0300, Vladimir Zapolskiy wrote:
> >> But "!size" is a special case,
> >>
> >>if (!count || pos >= size)
> >>return 0;
> >>
> >> seems to be incorrect in case of !size ===> (pos >= size) == true.
> > 
> > Hmmm... Why is that wrong tho?  If size is zero and pos is zero,
> > there's nothing to do, no?
> 
> positive size value in the context means the fixed exact length of the
> file and if size == 0, then it represents some undefined size, often
> dynamic in runtime. So, if size is zero and pos is zero it stands for
> reading from the beginning of the file as many bytes as allowed by
> battr->read() realization. This special case is utilized by quite many
> bin_attribute users, probably more than half of them set .size to 0.

Ah, right, I completely forgot about that.  Please feel free to add

 Acked-by: Tejun Heo 

to the original patch.

Thanks for the patience.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2015 Loan Program

[Cash-reincarnate USA]

Forretnings- og personlig lån på 3% uten kredittsjekk og umiddelbar godkjenning,
Søk nå!

Programmet gjennom e-post;

Evelyn s.
evelyn.c...@reincarnate.com

Mark Unrue.
info.c...@reincarnate.com,

Kathy Ellis
kathy.c...@reincarnate.com

Takk og hilsen.
Kontanter reinkarnerer Usa
Woodbridge Lane Portage Michigan.

Business and personal loan at 3% with no credit check and Instant approval,
Apply now!!!

Application Through Email;

 Evelyn P.
 evelyn.c...@reincarnate.com

 Mark Unrue.
 info.c...@reincarnate.com,

 Kathy Ellis
 kathy.c...@reincarnate.com

Thanks and Regards.
Cash Reincarnate Usa
Woodbridge Lane Portage Michigan.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/PATCH 6/9] drivers: platform: Configure dma operations at probe time

[Laurent Pinchart]

Hi Robin,

On Tuesday 19 May 2015 11:39:17 Robin Murphy wrote:
> On 15/05/15 00:00, Laurent Pinchart wrote:
> > Configuring DMA ops at probe time will allow deferring device probe when
> > the IOMMU isn't available yet.
> 
> This is great, as I think it also subtly solves the ordering problem the
> current domain allocation has with platform devices. WRT to your comment
> on the other thread, this actually makes things slightly saner for IOMMU
> groups - the group assignment has to happen after device creation or
> else some sysfs stuff blows up, so of_xlate is far too early and the
> add_device callback is a reasonable place for it to be (until we can
> move it out of every driver and into bus code). However, we're currently
> attaching the device to the automatic domain long before that, so things
> happen logically backwards and drivers like the ARM SMMU which actually
> use the group to store relevant data get all confused.
> 
> With this change, the existing attach_device call in arch_setup_dma_ops
> will actually work far more reliably, and I might be able to revive my
> attempt to port the ARM SMMU driver over to of_xlate :D

Please do :-) I second IOMMU driver using the of_xlate + probe deferral 
mechanism would help validate this patch series.

> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >   drivers/base/platform.c | 9 +
> >   drivers/of/platform.c   | 7 +++
> >   2 files changed, 12 insertions(+), 4 deletions(-)
> > 
> > diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> > index ebf034b97278..508a866859dc 100644
> > --- a/drivers/base/platform.c
> > +++ b/drivers/base/platform.c
> > @@ -516,6 +516,10 @@ static int platform_drv_probe(struct device *_dev)
> > if (ret < 0)
> > return ret;
> > 
> > +   ret = of_dma_configure_ops(_dev, _dev->of_node);
> > +   if (ret < 0)
> > +   goto done;
> > +
> > ret = dev_pm_domain_attach(_dev, true);
> > if (ret != -EPROBE_DEFER) {
> > ret = drv->probe(dev);
> > @@ -523,6 +527,10 @@ static int platform_drv_probe(struct device *_dev)
> > dev_pm_domain_detach(_dev, true);
> > }
> > 
> > +   if (ret)
> > +   of_dma_deconfigure(_dev);
> > +
> > 
> > +done:
> > if (drv->prevent_deferred_probe && ret == -EPROBE_DEFER) {
> > dev_warn(_dev, "probe deferral not supported\n");
> > ret = -ENXIO;
> > @@ -544,6 +552,7 @@ static int platform_drv_remove(struct device *_dev)
> > 
> > ret = drv->remove(dev);
> > dev_pm_domain_detach(_dev, true);
> > +   of_dma_deconfigure(_dev);
> > return ret;
> >   }
> > 
> > diff --git a/drivers/of/platform.c b/drivers/of/platform.c
> > index 9a29f09b7723..fc939bec799e 100644
> > --- a/drivers/of/platform.c
> > +++ b/drivers/of/platform.c
> > @@ -178,10 +178,8 @@ static struct platform_device
> > *of_platform_device_create_pdata(
> > dev->dev.bus = _bus_type;
> > dev->dev.platform_data = platform_data;
> > of_dma_configure_masks(>dev, dev->dev.of_node);
> > -   of_dma_configure_ops(>dev, dev->dev.of_node);
> > 
> > if (of_device_add(dev) != 0) {
> > -   of_dma_deconfigure(>dev);
> > platform_device_put(dev);
> > goto err_clear_flag;
> > }
> > @@ -465,11 +463,12 @@ static int of_platform_device_destroy(struct device
> > *dev, void *data)
> > if (dev->bus == _bus_type)
> > platform_device_unregister(to_platform_device(dev));
> >   
> >   #ifdef CONFIG_ARM_AMBA
> > -   else if (dev->bus == _bustype)
> > +   else if (dev->bus == _bustype) {
> > amba_device_unregister(to_amba_device(dev));
> > +   of_dma_deconfigure(dev);
> > +   }
> >   #endif
> > 
> > -   of_dma_deconfigure(dev);
> > of_node_clear_flag(dev->of_node, OF_POPULATED);
> > of_node_clear_flag(dev->of_node, OF_POPULATED_BUS);
> > return 0;

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH v6 07/37] MIPS: JZ4740: probe CPU interrupt controller via DT

[Paul Burton]

Use the generic irqchip_init function to probe irqchip drivers using DT,
and add the appropriate node to the JZ4740 devicetree in place of the
call to mips_cpu_irq_init.

Signed-off-by: Paul Burton 
Cc: Ian Campbell 
Cc: Kumar Gala 
Cc: Lars-Peter Clausen 
Cc: Mark Rutland 
Cc: Pawel Moll 
Cc: Ralf Baechle 
Cc: Rob Herring 
Cc: devicet...@vger.kernel.org
Cc: linux-m...@linux-mips.org
---

Changes in v6:
- Rename cpuintc DT node interrupt-controller@0.

Changes in v5: None
Changes in v4: None
Changes in v3:
- Rebase.

Changes in v2: None

 arch/mips/boot/dts/ingenic/jz4740.dtsi | 7 +++
 arch/mips/jz4740/irq.c | 4 ++--
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/arch/mips/boot/dts/ingenic/jz4740.dtsi 
b/arch/mips/boot/dts/ingenic/jz4740.dtsi
index c538691f..dd3642f 100644
--- a/arch/mips/boot/dts/ingenic/jz4740.dtsi
+++ b/arch/mips/boot/dts/ingenic/jz4740.dtsi
@@ -2,4 +2,11 @@
#address-cells = <1>;
#size-cells = <1>;
compatible = "ingenic,jz4740";
+
+   cpuintc: interrupt-controller@0 {
+   #address-cells = <0>;
+   #interrupt-cells = <1>;
+   interrupt-controller;
+   compatible = "mti,cpu-interrupt-controller";
+   };
 };
diff --git a/arch/mips/jz4740/irq.c b/arch/mips/jz4740/irq.c
index 97206b3..3ec90875 100644
--- a/arch/mips/jz4740/irq.c
+++ b/arch/mips/jz4740/irq.c
@@ -18,6 +18,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -27,7 +28,6 @@
 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -84,7 +84,7 @@ void __init arch_init_irq(void)
struct irq_chip_generic *gc;
struct irq_chip_type *ct;
 
-   mips_cpu_irq_init();
+   irqchip_init();
 
jz_intc_base = ioremap(JZ4740_INTC_BASE_ADDR, 0x14);
 
-- 
2.4.1

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC/PATCH 2/9] arm: dma-mapping: Support IOMMU mappings spanning the full 32 bits range

[Laurent Pinchart]

Hi Robin,

On Tuesday 19 May 2015 11:17:32 Robin Murphy wrote:
> On 15/05/15 00:00, Laurent Pinchart wrote:
> > The arm_iommu_create_mapping() function takes the IOMMU mapping size as
> > a size_t, limiting the size to 4GB - 1 on 32 bit platforms while most
> > bus masters would support the full 32 bits range. Fix this by passing
> > the size as a 64 bits integer, and limiting it to 4GB for now.
> 
> FYI there's already an almost-identical patch in -rc3 from Marek fixing
> this: 1424532b2163 ("ARM: 8347/1: dma-mapping: fix off-by-one check in
> arm_setup_iommu_dma_ops").

Indeed, I should have rebased on top of -rc3. I suppose it's a good indication 
that I was on the right track :-) I'll drop this patch from my series.

> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >   arch/arm/include/asm/dma-iommu.h |  2 +-
> >   arch/arm/mm/dma-mapping.c| 12 +++-
> >   2 files changed, 4 insertions(+), 10 deletions(-)
> > 
> > diff --git a/arch/arm/include/asm/dma-iommu.h
> > b/arch/arm/include/asm/dma-iommu.h index 8e3fcb924db6..2ef282f96651
> > 100644
> > --- a/arch/arm/include/asm/dma-iommu.h
> > +++ b/arch/arm/include/asm/dma-iommu.h
> > @@ -25,7 +25,7 @@ struct dma_iommu_mapping {
> >   };
> >   
> >   struct dma_iommu_mapping *
> > -arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t
> > size);
> > +arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, u64
> > size);
> >   void arm_iommu_release_mapping(struct dma_iommu_mapping *mapping);
> > 
> > diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
> > index 7aa5e339a596..c69e216a0cf9 100644
> > --- a/arch/arm/mm/dma-mapping.c
> > +++ b/arch/arm/mm/dma-mapping.c
> > @@ -1878,7 +1878,7 @@ struct dma_map_ops iommu_coherent_ops = {
> > 
> >* arm_iommu_attach_device function.
> >*/
> >   
> >   struct dma_iommu_mapping *
> > 
> > -arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base, size_t
> > size) +arm_iommu_create_mapping(struct bus_type *bus, dma_addr_t base,
> > u64 size)
> >   {
> > unsigned int bits = size >> PAGE_SHIFT;
> > unsigned int bitmap_size = BITS_TO_LONGS(bits) * sizeof(long);
> > @@ -1886,7 +1886,8 @@ arm_iommu_create_mapping(struct bus_type *bus,
> > dma_addr_t base, size_t size)
> > int extensions = 1;
> > int err = -ENOMEM;
> > 
> > -   if (!bitmap_size)
> > +   /* Limit the size to 4GB for now. */
> > +   if (!size || size > (1ULL << 32))
> > return ERR_PTR(-EINVAL);
> > 
> > if (bitmap_size > PAGE_SIZE) {
> > @@ -2057,13 +2058,6 @@ static bool arm_setup_iommu_dma_ops(struct device
> > *dev, u64 dma_base, u64 size,
> > if (!iommu)
> > return false;
> > 
> > -   /*
> > -* currently arm_iommu_create_mapping() takes a max of size_t
> > -* for size param. So check this limit for now.
> > -*/
> > -   if (size > SIZE_MAX)
> > -   return false;
> > -
> > mapping = arm_iommu_create_mapping(dev->bus, dma_base, size);
> > if (IS_ERR(mapping)) {
> > pr_warn("Failed to create %llu-byte IOMMU mapping for device 
%s\n",

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: uvcvideo: Race on dev->state between uvc_disconnect() and uvc_v4l2_open()

[Laurent Pinchart]

Hi Eugene,

On Wednesday 20 May 2015 17:48:41 Eugene Shatokhin wrote:
> Hi,
> 
> There is a race in uvcvideo module between uvc_disconnect() and
> uvc_v4l2_open() on dev->state. Checked and reproduced that with kernel
> 4.1-rc1.
> 
> drivers/media/usb/uvc/uvc_driver.c, uvc_disconnect():
> 
>   dev->state |= UVC_DEV_DISCONNECTED;
> 
> drivers/media/usb/uvc/uvc_v4l2.c, uvc_v4l2_open():
> 
>   if (stream->dev->state & UVC_DEV_DISCONNECTED)
>   return -ENODEV;
> 
> I checked that the race does happen by introducing a delay in
> uvc_disconnect() right before that assignment and armed a hardware
> breakpoint to detect the access to stream->dev->state from
> uvc_v4l2_open(). When I disconnected the webcam while Google Hangout was
> running, the hardware breakpoint triggered several times for that read
> in uvc_v4l2_open (uvc_v4l2.c:484). uvc_v4l2_open() was called in the
> context of GoogleTalkPlugin processes.
> 
> Not sure if the race is intentional but I guess, better to report it
> anyway. Nothing has crashed during my (brief) testing yet, but still.

The race condition between disconnect and open is unavoidable. What is 
avoidable, though, is the crashes and other ill side-effects that could result 
from it. The following commit handles that.

commit ca9afe6f87b569cdf8e797395381f18ae23a2905
Author: Hans Verkuil 
Date:   Fri Nov 26 06:54:53 2010 -0300

[media] v4l2-dev: fix race condition

The unregister function had a race condition with the v4l2_open
function. Ensure that both functions test and clear the REGISTER
flag from within a critical section.

Thanks to Laurent Pinchart for finding this race.

Signed-off-by: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 


The race was previously handled by the uvcvideo driver, and the code got 
removed in the following commit after the above commit got merged.

commit 716fdee110ceb816cca8c46c0890d08c5a1addb9
Author: Laurent Pinchart 
Date:   Tue Sep 29 21:07:19 2009 -0300

V4L/DVB (13152): uvcvideo: Rely on videodev to reference-count the device

The uvcvideo driver has a driver-wide lock and a reference count to 
protect
against a disconnect/open race. Now that videodev handles the race itself,
reference-counting in the driver can be removed.

Signed-off-by: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 


Setting the UVC_DEV_DISCONNECTED flag seems unneeded nowadays. I'll have to 
carefully think about it though, and it's too late right now to do so :-)

-- 
Regards,

Laurent Pinchart

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Linux 2.6.32.66

[Willy Tarreau]

Hello,

I've just released Linux 2.6.32.66.

The patch and changelog will appear soon at the following locations:
  https://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/
  
https://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/patch-2.6.32.66.xz
  
https://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/patch-2.6.32.66.gz
  
https://www.kernel.org/pub/linux/kernel/v2.6/longterm/v2.6.32/ChangeLog-2.6.32.66

The updated 2.6.32.y git tree can be found at:
   git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-2.6.32.y
  http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 
linux-2.6.32.y

The tree can be browsed on the gitweb interface:
  
http://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/log/?h=linux-2.6.32.y

  Testing status (build/boot, OK/FAIL, otherwise not tested) :

 ARCH  | CONFIGURATION
   +---
   |  allmodconfig other-config
x86_64 |build:OK boot:OK
  i386 |build:OK-

Thanks to all reviewers, and to Greg for the final packaging.
Willy

-
 Makefile   |  2 +-
 arch/x86/include/asm/desc.h| 20 ++---
 arch/x86/include/asm/ldt.h |  7 
 arch/x86/include/asm/msr-index.h   |  1 +
 arch/x86/kernel/apic/apic.c| 12 +++---
 arch/x86/kernel/cpu/amd.c  | 10 +
 arch/x86/kernel/entry_64.S | 13 +++---
 arch/x86/kernel/kvm.c  |  9 -
 arch/x86/kernel/kvmclock.c |  1 -
 arch/x86/kernel/tls.c  | 62 +++-
 arch/x86/kernel/traps.c|  4 +-
 arch/x86/mm/mmap.c |  6 +--
 arch/x86/vdso/vma.c| 36 -
 block/scsi_ioctl.c |  3 +-
 drivers/infiniband/core/umem.c |  8 
 drivers/infiniband/core/uverbs_main.c  |  1 +
 drivers/net/ppp_deflate.c  |  2 +-
 drivers/serial/samsung.c   |  4 ++
 drivers/spi/spidev.c   |  5 ++-
 fs/binfmt_elf.c|  5 ++-
 fs/exec.c  | 65 ++
 fs/hfsplus/brec.c  | 20 -
 fs/isofs/rock.c|  9 +
 fs/lockd/mon.c |  6 +++
 fs/ocfs2/file.c|  8 +++-
 fs/proc/task_mmu.c | 10 +
 fs/splice.c|  8 +++-
 kernel/posix-timers.c  |  1 +
 net/compat.c   |  7 
 net/core/dev.c |  2 +-
 net/core/sysctl_net_core.c | 19 +++--
 net/ipv4/fib_semantics.c   |  2 +-
 net/ipv4/ip_forward.c  |  3 ++
 net/ipv4/ip_output.c   |  3 +-
 net/ipv4/sysctl_net_ipv4.c | 13 --
 net/ipv4/tcp_output.c  | 52 +---
 net/ipv6/ip6_output.c  |  3 +-
 net/ipv6/ndisc.c   |  9 -
 net/llc/sysctl_net_llc.c   |  8 ++--
 net/netfilter/ipvs/ip_vs_ftp.c | 10 ++---
 net/netfilter/nf_conntrack_proto_generic.c | 26 +++-
 net/rds/iw_rdma.c  | 40 +-
 net/rds/sysctl.c   |  4 +-
 net/rxrpc/ar-recvmsg.c |  2 +-
 net/sched/ematch.c |  1 +
 net/sctp/associola.c   |  1 -
 net/sctp/auth.c|  2 -
 net/socket.c   |  3 ++
 sound/oss/sequencer.c  | 12 +-
 49 files changed, 400 insertions(+), 160 deletions(-)

Summary of changes from 2.6.32.65 to 2.6.32.66
==
Al Viro (1):
  rxrpc: bogus MSG_PEEK test in rxrpc_recvmsg()

Alexey Khoroshilov (1):
  sound/oss: fix deadlock in sequencer_ioctl(SNDCTL_SEQ_OUTOFBAND)

Alexey Kodanev (1):
  net: sysctl_net_core: check SNDBUF and RCVBUF for min length

Andy Lutomirski (9):
  x86/asm/traps: Disable tracing and kprobes in fixup_bad_iret and sync_regs
  x86/tls: Validate TLS entries to protect espfix
  x86, tls, ldt: Stop checking lm in LDT_empty
  x86, tls: Interpret an all-zero struct user_desc as "no segment"
  x86/tls: Disallow unusual TLS segments
  x86/tls: Don't validate lm in set_thread_area() after all
  x86, kvm: Clear paravirt_enabled on KVM guests for espfix32's benefit
  x86_64, vdso: Fix the vdso address randomization algorithm
  x86/asm/entry/64: Remove a bogus 'ret_from_fork' optimization

Ani Sinha (1):
  net:socket: set msg_namelen to 0 if msg_name is passed as NULL in msghdr 

RE: [char-misc-next 11/11] mei: revamp mei bus code

[Winkler, Tomas]

> 
> On Thu, May 07, 2015 at 03:54:08PM +0300, Tomas Winkler wrote:
> > MEI bus was designed around nfc and was hard to extend.
> > Instead of hard coded way of adding the devices on the mei bus
> > we scan whole me client list and create a device for each
> > eligible me client; currently we support only clients with
> > single connection and fixed address clients.
> > NFC radio name detection is run as a fixup routine
> >
> > Cc: Samuel Ortiz 
> > Signed-off-by: Tomas Winkler 
> > ---
> >  drivers/misc/mei/Makefile|   2 +-
> >  drivers/misc/mei/bus-fixup.c | 306 ++
> >  drivers/misc/mei/bus.c   | 975 
> ---
> >  drivers/misc/mei/client.c|   9 +-
> >  drivers/misc/mei/init.c  |   5 +-
> >  drivers/misc/mei/mei_dev.h   |  24 +-
> >  drivers/misc/mei/nfc.c   | 414 --
> >  include/linux/mei_cl_bus.h   |  12 +
> >  8 files changed, 968 insertions(+), 779 deletions(-)
> >  create mode 100644 drivers/misc/mei/bus-fixup.c
> >  delete mode 100644 drivers/misc/mei/nfc.c
> 
> This is a lot to do in just one patch.  Any chance you can split it up
> into reviewable pieces?

I thought it would be harder to swallow but I'm not sure how to really 
split this into working pieces w/o do some artificial steps which
 I will have to validate again to keep the code bisectable. 
What could be naturally factored out is already in separate  patches in this 
series. 
The patch is maybe bigger because of code moves between files but what has 
really changes is just bus.c 
Please reconsider.
Thanks
Tomas 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 11/51] memcg: implement mem_cgroup_css_from_page()

[Tejun Heo]

Hello,

On Fri, May 22, 2015 at 07:28:31PM -0400, Johannes Weiner wrote:
> replace_page_cache() can clear page->mem_cgroup even when the page
> still has references, so unfortunately you must hold the page lock
> when calling this function.
> 
> I haven't checked how you use this - chances are you always have the
> page locked anyways - but it probably needs a comment.

Hmmm... as replace_page_cache_page() is used only by fuse and fuse's
bdi doesn't go through the usual writeback accounting which is
necessary for cgroup writeback support anyway, so I don't think this
presents an actual problem.  I'll add a warning in
replace_page_cache_page() which triggers when it's used on a bdi which
has cgroup writeback enabled and add comments explaining what's going
on.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [ANNOUNCE] 4.0.4-rt1

[Fernando Lopez-Lezcano]

On 05/19/2015 02:39 PM, Sebastian Andrzej Siewior wrote:

Dear RT folks!

I'm pleased to announce the v4.0.4-rt1 patch set.


Great!!


Changes since v3.18.13-rt10

- Rebase to v4.0.

- David Hildenbrand's series of decouple of preempt_disable from
   pagefault_disable is part of the series.

While doing the v4.0 I stumbled upon a few things. Therefore I plan to
reorder the -RT queue and merge patches where possible. Also I intend to
drop PREEMPT_RTB and PREEMPT_RT_BASE unless there is need for it…


...

I had to do this to get it to build (looks like it is not rt specific, 
probably just a typo in mainline):



--- linux-4.0/sound/soc/intel/sst/sst.c~2015-04-12 15:12:50.0 
-0700
+++ linux-4.0/sound/soc/intel/sst/sst.c 2015-05-23 21:51:46.0 -0700
@@ -368,8 +368,8 @@
 * initialize by FW or driver when firmware is loaded
 */
spin_lock_irqsave(>ipc_spin_lock, irq_flags);
-   sst_shim_write64(shim, SST_IMRX, shim_regs->imrx),
-   sst_shim_write64(shim, SST_CSR, shim_regs->csr),
+   sst_shim_write64(shim, SST_IMRX, shim_regs->imrx);
+   sst_shim_write64(shim, SST_CSR, shim_regs->csr);
spin_unlock_irqrestore(>ipc_spin_lock, irq_flags);
 }



On a desktop with an i7-3770k it seems to run fine (but I have not have 
time to test for latency problems).


On my laptop, a lenovo w540, I get this continuously - so it is not 
really usable at this point:



May 24 13:51:41 localhost kernel: [ cut here ]
May 24 13:51:41 localhost kernel: WARNING: CPU: 5 PID: 361 at 
drivers/gpu/drm/i915/intel_display.c:9748 
intel_check_page_flip+0xaa/0xf0 [i915]()

May 24 13:51:41 localhost kernel: WARN_ON(!in_interrupt())
May 24 13:51:41 localhost kernel: Modules linked in:
May 24 13:51:41 localhost kernel: rfcomm fuse ccm xt_CHECKSUM 
ipt_MASQUERADE nf_nat_masquerade_ipv4 nf_conntrack_netbios_ns 
nf_conntrack_broadcast ip6t_rpfilter ip6t_REJ\
ECT nf_reject_ipv6 xt_conntrack ebtable_nat ebtable_broute bridge stp 
llc ebtable_filter ebtables ip6table_nat nf_conntrack_ipv6 
nf_defrag_ipv6 nf_nat_ipv6 ip6table_mang\
le ip6table_security ip6table_raw ip6table_filter ip6_tables iptable_nat 
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack 
iptable_mangle iptable_security\
 iptable_raw bnep bbswitch(OE) vfat fat iTCO_wdt iTCO_vendor_support 
arc4 intel_rapl iosf_mbi coretemp kvm_intel kvm uvcvideo 
crct10dif_pclmul videobuf2_vmalloc videobuf\
2_core crc32_pclmul crc32c_intel videobuf2_memops ghash_clmulni_intel 
v4l2_common videodev media iwlmvm btusb serio_raw mac80211 bluetooth 
snd_hda_codec_realtek
May 24 13:51:41 localhost kernel: snd_hda_codec_hdmi 
snd_hda_codec_generic iwlwifi snd_hda_intel sdhci_pci snd_hda_controller 
cfg80211 sdhci snd_hda_codec mmc_core snd_h\
wdep lpc_ich snd_seq mei_me i2c_i801 mfd_core snd_seq_device mei snd_pcm 
thinkpad_acpi snd_timer ie31200_edac snd shpchp edac_core soundcore 
tpm_tis rfkill tpm nfsd auth\
_rpcgss nfs_acl lockd grace sunrpc i915 i2c_algo_bit e1000e 
drm_kms_helper ptp drm pps_core wmi video
May 24 13:51:41 localhost kernel: CPU: 5 PID: 361 Comm: irq/30-i915 
Tainted: GW  OE   4.0.4-201.rt1.2.fc21.ccrma.x86_64+rt #1
May 24 13:51:41 localhost kernel: Hardware name: LENOVO 
20BGCTO1WW/20BGCTO1WW, BIOS GNET65WW (2.13 ) 06/20/2014
May 24 13:51:41 localhost kernel:  1f35af7b 
8804651afc78 8179c0b9
May 24 13:51:41 localhost kernel:  8804651afcd0 
8804651afcb8 8109ee1a
May 24 13:51:41 localhost kernel: 8804651afcb8 88046638c000 
880469dd7800 0001

May 24 13:51:41 localhost kernel: Call Trace:
May 24 13:51:41 localhost kernel: [] dump_stack+0x4c/0x81
May 24 13:51:41 localhost kernel: [] 
warn_slowpath_common+0x8a/0xe0
May 24 13:51:41 localhost kernel: [] 
warn_slowpath_fmt+0x55/0x70
May 24 13:51:41 localhost kernel: [] 
intel_check_page_flip+0xaa/0xf0 [i915]
May 24 13:51:41 localhost kernel: [] 
ironlake_irq_handler+0x2e8/0x1000 [i915]
May 24 13:51:41 localhost kernel: [] ? 
__switch_to+0x150/0x610
May 24 13:51:41 localhost kernel: [] ? 
irq_thread_fn+0x50/0x50
May 24 13:51:41 localhost kernel: [] 
irq_forced_thread_fn+0x27/0x80
May 24 13:51:41 localhost kernel: [] 
irq_thread+0x12f/0x180
May 24 13:51:41 localhost kernel: [] ? 
wake_threads_waitq+0x30/0x30
May 24 13:51:41 localhost kernel: [] ? 
irq_thread_check_affinity+0x90/0x90

May 24 13:51:41 localhost kernel: [] kthread+0xca/0xe0
May 24 13:51:41 localhost kernel: [] ? 
kthread_worker_fn+0x180/0x180
May 24 13:51:41 localhost kernel: [] 
ret_from_fork+0x58/0x90
May 24 13:51:41 localhost kernel: [] ? 
kthread_worker_fn+0x180/0x180

May 24 13:51:41 localhost kernel: ---[ end trace 05fe ]---
May 24 13:51:41 localhost kernel: [ cut here ]


Any patches I could try to fix this?
-- Fernando

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the 

Re: [PATCH v9 2/5] clockevents/drivers: Add STM32 Timer driver

[Daniel Lezcano]

On 05/22/2015 11:03 PM, Maxime Coquelin wrote:

STM32 MCUs feature 16 and 32 bits general purpose timers with prescalers.
The drivers detects whether the time is 16 or 32 bits, and applies a
1024 prescaler value if it is 16 bits.

Reviewed-by: Linus Walleij 
Tested-by: Chanwoo Choi 
Signed-off-by: Maxime Coquelin 


Applied to my tree for 4.2

Thanks !

  -- Daniel


--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v9 1/5] dt-bindings: Document the STM32 timer bindings

[Daniel Lezcano]

On 05/22/2015 11:03 PM, Maxime Coquelin wrote:

This adds documentation of device tree bindings for the
STM32 timer.

Tested-by: Chanwoo Choi 
Acked-by: Rob Herring 
Signed-off-by: Maxime Coquelin 


Applied to my tree for 4.2.



--
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] kernel:workqueue - Fix typos in comments.

[Tejun Heo]

One hunk was already fixed.  Applied the rest to wq/for-4.2.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/2] capabilities: Add a securebit to disable PR_CAP_AMBIENT_RAISE

[Andrew G. Morgan]

Thanks

Acked-By: Andrew G. Morgan 


On Sat, May 23, 2015 at 12:45 PM, Serge E. Hallyn  wrote:
> On Thu, May 14, 2015 at 11:39:49PM -0700, Andy Lutomirski wrote:
>> Per Andrew Morgan's request, add a securebit to allow admins to
>> disable PR_CAP_AMBIENT_RAISE.  This securebit will prevent processes
>> from adding capabilities to their ambient set.
>>
>> For simplicity, this disables PR_CAP_AMBIENT_RAISE entirely rather
>> than just disabling setting previously cleared bits.
>>
>> Requested-by: Andrew G. Morgan 
>> Cc: Kees Cook 
>> Cc: Christoph Lameter 
>> Cc: Serge Hallyn 
>> Cc: Andy Lutomirski 
>> Cc: Jonathan Corbet 
>> Cc: Aaron Jones 
>> CC: Ted Ts'o 
>> Cc: linux-security-mod...@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: linux-...@vger.kernel.org
>> Cc: a...@linuxfoundation.org
>> Cc: Andrew G. Morgan 
>> Cc: Mimi Zohar 
>> Cc: Austin S Hemmelgarn 
>> Cc: Markku Savela 
>> Cc: Jarkko Sakkinen 
>> Cc: Michael Kerrisk 
>> Signed-off-by: Andy Lutomirski 
>
> Interesting - at first I thought this wouldn't please Andrew as he'd
> want the inverse, but I guess this way keeps the pure-capabilities
> mode (with SECURE_ALL_BITS set) ambient-free which I suppose is
> really the important thing.
>
> Acked-by: Serge Hallyn 
>
>> ---
>>  include/uapi/linux/securebits.h | 11 ++-
>>  security/commoncap.c|  3 ++-
>>  2 files changed, 12 insertions(+), 2 deletions(-)
>>
>> diff --git a/include/uapi/linux/securebits.h 
>> b/include/uapi/linux/securebits.h
>> index 985aac9e6bf8..35ac35cef217 100644
>> --- a/include/uapi/linux/securebits.h
>> +++ b/include/uapi/linux/securebits.h
>> @@ -43,9 +43,18 @@
>>  #define SECBIT_KEEP_CAPS (issecure_mask(SECURE_KEEP_CAPS))
>>  #define SECBIT_KEEP_CAPS_LOCKED (issecure_mask(SECURE_KEEP_CAPS_LOCKED))
>>
>> +/* When set, a process cannot add new capabilities to its ambient set. */
>> +#define SECURE_NO_CAP_AMBIENT_RAISE  6
>> +#define SECURE_NO_CAP_AMBIENT_RAISE_LOCKED   7  /* make bit-6 immutable */
>> +
>> +#define SECBIT_NO_CAP_AMBIENT_RAISE 
>> (issecure_mask(SECURE_NO_CAP_AMBIENT_RAISE))
>> +#define SECBIT_NO_CAP_AMBIENT_RAISE_LOCKED \
>> + (issecure_mask(SECURE_NO_CAP_AMBIENT_RAISE_LOCKED))
>> +
>>  #define SECURE_ALL_BITS  (issecure_mask(SECURE_NOROOT) | \
>>issecure_mask(SECURE_NO_SETUID_FIXUP) | \
>> -  issecure_mask(SECURE_KEEP_CAPS))
>> +  issecure_mask(SECURE_KEEP_CAPS) | \
>> +  issecure_mask(SECURE_NO_CAP_AMBIENT_RAISE))
>>  #define SECURE_ALL_LOCKS (SECURE_ALL_BITS << 1)
>>
>>  #endif /* _UAPI_LINUX_SECUREBITS_H */
>> diff --git a/security/commoncap.c b/security/commoncap.c
>> index 09541a6a85a0..98aa1b129c12 100644
>> --- a/security/commoncap.c
>> +++ b/security/commoncap.c
>> @@ -983,7 +983,8 @@ int cap_task_prctl(int option, unsigned long arg2, 
>> unsigned long arg3,
>>   if (arg2 == PR_CAP_AMBIENT_RAISE &&
>>   (!cap_raised(current_cred()->cap_permitted, arg3) 
>> ||
>>!cap_raised(current_cred()->cap_inheritable,
>> -  arg3)))
>> +  arg3) ||
>> +  issecure(SECURE_NO_CAP_AMBIENT_RAISE)))
>>   return -EPERM;
>>
>>   new = prepare_creds();
>> --
>> 2.1.0
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] cgroup: add explicit cast and comment for return type conversion

[Tejun Heo]

Hello,

On Sun, May 24, 2015 at 03:07:52PM +0200, Nicholas Mc Guire wrote:
> Type-checking coccinelle spatches are being used to locate type mismatches
> between function signatures and return values in this case this produced:
> ./kernel/cgroup.c:2525 WARNING: return of wrong type
>   ssize_t != size_t, 
> 
> Returning unsigned types converted to a signed type can be problematic
> but in this case the size_t is <= PATH_MAX which is less than ulong/2 so
> the conversion is safe - to make static code checking happy this is 
> resolved by an explicit cast and appropriate comment.
> 
> Patch was compile tested with x86_64_defconfig (implies CONFIG_CGROUPS=y)
> 
> Patch is against 4.1-rc4 (localversion-next is -next-20150522)
> 
> Signed-off-by: Nicholas Mc Guire 
> ---
> 
> Not sure if "cleanups" like this are acceptable - in this case I did not
> find any better way to make static code checkers happy though.
> 
>  kernel/cgroup.c |6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/cgroup.c b/kernel/cgroup.c
> index b91177f..04de621 100644
> --- a/kernel/cgroup.c
> +++ b/kernel/cgroup.c
> @@ -2523,7 +2523,11 @@ static ssize_t cgroup_release_agent_write(struct 
> kernfs_open_file *of,
>   sizeof(cgrp->root->release_agent_path));
>   spin_unlock(_agent_path_lock);
>   cgroup_kn_unlock(of->kn);
> - return nbytes;
> +
> + /* the path of the release notifier is <= PATH_MAX
> +  * so "downsizing" to signed long is safe here
> +  */
> + return (ssize_t)nbytes;

idk, does this actually help anything?  This isn't different from any
other implicit type casts.  Are we gonna convert all downward implicit
casts to be explicit?

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: unisys: remove braces from single statement blocks

[Greg KH]

On Sun, May 17, 2015 at 03:46:36PM -0700, Isaac Assegai wrote:
> Remove the braces to satisfy this checkpatch warning:
> WARNING: braces {} are not necessary for single statement blocks
> 
> Signed-off-by: Isaac Assegai 
> ---
>  drivers/staging/unisys/virthba/virthba.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)

Doesn't apply to my tree :(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/1] drivers: staging: unisys: visorbus: visorchipset.c: private functions should be declared static

[Greg Kroah-Hartman]

On Fri, May 15, 2015 at 09:22:21PM -0700, Tolga Ceylan wrote:
> visorchipset_file_init() and visorchipset_file_cleanup() functions
> do not seem to be used from anywhere else and now are declared
> as static. Sparse emitted "not declared" warnings for these two
> functions.
> 
> Signed-off-by: Tolga Ceylan 
> ---
>  drivers/staging/unisys/visorbus/visorchipset.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Doesn't apply to my tree :(
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/4] ozwpan: Use proper check to prevent heap overflow

[Greg Kroah-Hartman]

On Wed, May 13, 2015 at 08:58:17PM +0200, Jason A. Donenfeld wrote:
> Since elt->length is a u8, we can make this variable a u8. Then we can
> do proper bounds checking more easily. Without this, a potentially
> negative value is passed to the memcpy inside oz_hcd_get_desc_cnf,
> resulting in a remotely exploitable heap overflow with network
> supplied data.
> 
> This could result in remote code execution. A PoC which obtains DoS
> follows below. It requires the ozprotocol.h file from this module.
> 
> =-=-=-=-=-=
> 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
>  #include 
> 
>  #define u8 uint8_t
>  #define u16 uint16_t
>  #define u32 uint32_t
>  #define __packed __attribute__((__packed__))
>  #include "ozprotocol.h"
> 
> static int hex2num(char c)
> {
>   if (c >= '0' && c <= '9')
>   return c - '0';
>   if (c >= 'a' && c <= 'f')
>   return c - 'a' + 10;
>   if (c >= 'A' && c <= 'F')
>   return c - 'A' + 10;
>   return -1;
> }
> static int hwaddr_aton(const char *txt, uint8_t *addr)
> {
>   int i;
>   for (i = 0; i < 6; i++) {
>   int a, b;
>   a = hex2num(*txt++);
>   if (a < 0)
>   return -1;
>   b = hex2num(*txt++);
>   if (b < 0)
>   return -1;
>   *addr++ = (a << 4) | b;
>   if (i < 5 && *txt++ != ':')
>   return -1;
>   }
>   return 0;
> }
> 
> int main(int argc, char *argv[])
> {
>   if (argc < 3) {
>   fprintf(stderr, "Usage: %s interface destination_mac\n", 
> argv[0]);
>   return 1;
>   }
> 
>   uint8_t dest_mac[6];
>   if (hwaddr_aton(argv[2], dest_mac)) {
>   fprintf(stderr, "Invalid mac address.\n");
>   return 1;
>   }
> 
>   int sockfd = socket(AF_PACKET, SOCK_RAW, IPPROTO_RAW);
>   if (sockfd < 0) {
>   perror("socket");
>   return 1;
>   }
> 
>   struct ifreq if_idx;
>   int interface_index;
>   strncpy(if_idx.ifr_ifrn.ifrn_name, argv[1], IFNAMSIZ - 1);
>   if (ioctl(sockfd, SIOCGIFINDEX, _idx) < 0) {
>   perror("SIOCGIFINDEX");
>   return 1;
>   }
>   interface_index = if_idx.ifr_ifindex;
>   if (ioctl(sockfd, SIOCGIFHWADDR, _idx) < 0) {
>   perror("SIOCGIFHWADDR");
>   return 1;
>   }
>   uint8_t *src_mac = (uint8_t *)_idx.ifr_hwaddr.sa_data;
> 
>   struct {
>   struct ether_header ether_header;
>   struct oz_hdr oz_hdr;
>   struct oz_elt oz_elt;
>   struct oz_elt_connect_req oz_elt_connect_req;
>   } __packed connect_packet = {
>   .ether_header = {
>   .ether_type = htons(OZ_ETHERTYPE),
>   .ether_shost = { src_mac[0], src_mac[1], src_mac[2], 
> src_mac[3], src_mac[4], src_mac[5] },
>   .ether_dhost = { dest_mac[0], dest_mac[1], dest_mac[2], 
> dest_mac[3], dest_mac[4], dest_mac[5] }
>   },
>   .oz_hdr = {
>   .control = OZ_F_ACK_REQUESTED | (OZ_PROTOCOL_VERSION << 
> OZ_VERSION_SHIFT),
>   .last_pkt_num = 0,
>   .pkt_num = htole32(0)
>   },
>   .oz_elt = {
>   .type = OZ_ELT_CONNECT_REQ,
>   .length = sizeof(struct oz_elt_connect_req)
>   },
>   .oz_elt_connect_req = {
>   .mode = 0,
>   .resv1 = {0},
>   .pd_info = 0,
>   .session_id = 0,
>   .presleep = 35,
>   .ms_isoc_latency = 0,
>   .host_vendor = 0,
>   .keep_alive = 0,
>   .apps = htole16((1 << OZ_APPID_USB) | 0x1),
>   .max_len_div16 = 0,
>   .ms_per_isoc = 0,
>   .up_audio_buf = 0,
>   .ms_per_elt = 0
>   }
>   };
> 
>   struct {
>   struct ether_header ether_header;
>   struct oz_hdr oz_hdr;
>   struct oz_elt oz_elt;
>   struct oz_get_desc_rsp oz_get_desc_rsp;
>   } __packed pwn_packet = {
>   .ether_header = {
>   .ether_type = htons(OZ_ETHERTYPE),
>   .ether_shost = { src_mac[0], src_mac[1], src_mac[2], 
> src_mac[3], src_mac[4], src_mac[5] },
>   .ether_dhost = { dest_mac[0], dest_mac[1], dest_mac[2], 
> dest_mac[3], dest_mac[4], dest_mac[5] }
>   },
>   .oz_hdr = {
>   .control = OZ_F_ACK_REQUESTED | (OZ_PROTOCOL_VERSION << 
> OZ_VERSION_SHIFT),
>   .last_pkt_num = 0,
>   .pkt_num 

Re: [PATCH] staging : comedi/drivers/pcl*.c: coding style fixes

[Greg Kroah-Hartman]

On Sun, May 24, 2015 at 12:42:43PM -0700, Matthew Needes wrote:
> pcl812.c / pcl816.c:
> 
> Fixed indentation errors.
> Fixed lines exceeding 80 columns, spelling errors.

That's multiple things in the same patch, please do this in separate
patches, each one only doing one thing each.

> Verified code compiles.

This should be without saying :)

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 1/9] misc: sram: fix enabled clock leak on error path

[Vladimir Zapolskiy]

Hi Philipp,

On 20.05.2015 14:30, Philipp Zabel wrote:
> Hi Vladimir,
> 
> Am Dienstag, den 19.05.2015, 16:11 +0300 schrieb Vladimir Zapolskiy:
>> Hi Philipp,
>>
>> On 19.05.2015 13:41, Philipp Zabel wrote:
>>> Am Montag, den 18.05.2015, 22:08 +0300 schrieb Vladimir Zapolskiy:
 If devm_gen_pool_create() fails, the previously enabled sram->clk is
 not disabled on probe() exit.

 Signed-off-by: Vladimir Zapolskiy 
 ---
  drivers/misc/sram.c | 9 +
  1 file changed, 5 insertions(+), 4 deletions(-)

 diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
 index eeaaf5f..b44a423 100644
 --- a/drivers/misc/sram.c
 +++ b/drivers/misc/sram.c
 @@ -90,16 +90,17 @@ static int sram_probe(struct platform_device *pdev)
if (!sram)
return -ENOMEM;
  
 +  sram->pool = devm_gen_pool_create(>dev,
 +ilog2(SRAM_GRANULARITY), -1);
 +  if (!sram->pool)
 +  return -ENOMEM;
 +
sram->clk = devm_clk_get(>dev, NULL);
if (IS_ERR(sram->clk))
sram->clk = NULL;
else
clk_prepare_enable(sram->clk);
>>>
>>> Here you move sram->clk around, and later in patch 7 it gets moved
>>> again. To me it looks like the two should be squashed together.
>>
>> I agree with you, instead of moving sram->pool up it is better to place
>> sram->clk right at the end of probe(), in other words this patch can be
>> safely merged with patch 7 and the series becomes a bit shorter.
>>
>> Thank you for the finding, I'm going to resend the change, please let me
>> know your opinion about "%pa" vs "0x%llx", if it is needed to be changed
>> or not.
> 
> I'd prefer to use %pa for the phys_addr_t types. You could argue that
> %pa is inappropriate as those are addresses relative to the SRAM region,
> not physical addresses as seen by the CPU. But following that argument,
> using phys_addr_t in the first place would not be correct either.

The driver utilizes genalloc gen_pool_add_virt() function, whose
corresponding argument is of phys_addr_t type (and it is correct in my
opinion), the interface to this function dictates the type of its
arguments on client's side.

> Which leads me to question whether we will see larger than 4 GiB SRAM
> regions in the foreseeable future?

The question is not only about SRAM region size, but mainly it is about
the base address of SRAM, and don't want to exclude a situation, when
some kind of SRAM device is found outside of u32 addressable memory
space. Actually I believe an arbitrary physical memory region may be
claimed as it were a "SRAM device" and the driver still works fine.

If phys_addr_t arguments are accepted, then back to "%pa" vs "0x%llx"
question:

From: Philipp Zabel 
Date: Tue, 19 May 2015 12:38:37 +0200
In-Reply-To:
<1431976122-4228-4-git-send-email-vladimir_zapols...@mentor.com>

> Now that block->start is of type phys_addr_t, is there a reason
> not to use %pa ?

[snip]

>> -dev_dbg(>dev, "adding chunk 0x%lx-0x%lx\n",
>> -cur_start, cur_start + cur_size);
>> +dev_dbg(>dev, "adding chunk 0x%llx-0x%llx\n",
>> +(unsigned long long)cur_start,
>> +(unsigned long long)cur_start + cur_size);
>
>   dev_dbg(>dev, "adding chunk 0x%pa-0x%pa\n",
>   _start, >start);
>

I see that the change preserves the functionality, so I'll change printk
format to "%pa", will resend the series tomorrow.

--
With best wishes,
Vladimir

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] staging: comedi: fix coding style issues

[Greg KH]

On Wed, May 20, 2015 at 02:54:16PM +, Geliang Tang wrote:
> On Mon, May 18, 2015 at 12:37:09PM +0100, Ian Abbott wrote:
> > On 16/05/15 05:16, Geliang Tang wrote:
> > >1) Fixed an error found by checkpatch.pl.
> > >ERROR: space required after that ',' (ctx:VxV)
> > >./drivers/ni_mio_common.c:3764
> > >2) Changed "register 0x%x" to "register=0x%x" to keep the consistency
> > >of this file.
> > >3) The kernel version is next-20150515, 4.1.0-rc3.
> > 
> > You shouldn't mention point 3 in the commit message as it will look a bit
> > strange when it ends up in the commit log.  If you need to mention that, it
> > should go after the commit message, separated from the patch by a "---" line
> > like this:
> > 
> > Body of commit message goes here.
> > 
> > Signed off by and Cc lines go here.
> > ---
> > Additional patch commentary goes here.
> > ---
> > Actual patch goes here.
> > 
> > Git will ignore the additional commentary when the patch is applied.
> > 
> > >
> > >Signed-off-by: Geliang Tang 
> > >---
> > >  drivers/staging/comedi/drivers/ni_mio_common.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > >diff --git a/drivers/staging/comedi/drivers/ni_mio_common.c 
> > >b/drivers/staging/comedi/drivers/ni_mio_common.c
> > >index 9dfd4e6..6cc304a 100644
> > >--- a/drivers/staging/comedi/drivers/ni_mio_common.c
> > >+++ b/drivers/staging/comedi/drivers/ni_mio_common.c
> > >@@ -3761,7 +3761,7 @@ static unsigned int ni_gpct_to_stc_register(struct 
> > >comedi_device *dev,
> > >   if (reg < ARRAY_SIZE(ni_gpct_to_stc_regmap)) {
> > >   regmap = _gpct_to_stc_regmap[reg];
> > >   } else {
> > >-  dev_warn(dev->class_dev,"%s: unhandled register 0x%x\n",
> > >+  dev_warn(dev->class_dev, "%s: unhandled register=0x%x\n",
> > >__func__, reg);
> > >   return 0;
> > >   }
> > >
> > 
> > Apart from that niggle, the patch looks good!
> > 
> > Reviewed-by: Ian Abbott 
> > 
> > -- 
> > -=( Ian Abbott @ MEV Ltd.E-mail:  )=-
> > -=(  Web: http://www.mev.co.uk/  )=-
> 
> Thank you for your review. I revised the patch as you suggested.
> Here it is.

> >From d864f6af18a44031a241e10e64d98f9e6b8c0660 Mon Sep 17 00:00:00 2001
> From: Geliang Tang 
> Date: Wed, 20 May 2015 14:26:13 +
> Subject: [PATCH v2] staging: comedi: fix coding style issues
> 
> 1) Fixed an error found by checkpatch.pl.
>ERROR: space required after that ',' (ctx:VxV)
>./drivers/ni_mio_common.c:3764
> 2) Changed "register 0x%x" to "register=0x%x" to keep the consistency
>of this file.

That's multiple things in one patch :(

Also, this is an attachment, which I can't apply, please resend it as a
proper email.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] net: use msecs_to_jiffies for conversion to jiffies

[David Miller]

From: Nicholas Mc Guire 
Date: Sat, 23 May 2015 15:43:36 +0200

> API compliance scanning with coccinelle flagged:
> ./net/irda/timer.c:63:35-37: use of msecs_to_jiffies probably perferable
> 
> Converting milliseconds to jiffies by "val * HZ / 1000" technically
> is not a clean solution as it does not handle all corner cases correctly.
> By changing the conversion to use msecs_to_jiffies(val) conversion is
> correct in all cases. Further the () around the arithmetic expression
> was dropped.
> 
> Patch was compile tested for x86_64_defconfig + CONFIG_IRDA=m
> 
> Patch is against 4.1-rc4 (localversion-next is -next-20150522)
> 
> Signed-off-by: Nicholas Mc Guire 

The appropriate subsystem prefix for this change is not "net: "
but rather "irda: ", please update your Subject line accordingly
and resubmit.

Thanks.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] sparc: Resolve conflict between sparc v9 and M7 on usage of bit 9 of TTE

[David Miller]

From: Khalid Aziz 
Date: Fri, 15 May 2015 11:48:15 -0600

> diff --git a/arch/sparc/kernel/setup_64.c b/arch/sparc/kernel/setup_64.c
> index c38d19f..606e3f9 100644
> --- a/arch/sparc/kernel/setup_64.c
> +++ b/arch/sparc/kernel/setup_64.c
> @@ -255,6 +255,30 @@ void sun4v_patch_2insn_range(struct 
> sun4v_2insn_patch_entry *start,
>   }
>  }
>  
> +void sun_m7_patch_2insn_range(struct sun4v_2insn_patch_entry *start,
> +  struct sun4v_2insn_patch_entry *end)
> +{
> + while (start < end) {
> + unsigned long addr = start->addr;
> +
> + *(unsigned int *) (addr +  0) = start->insns[0];
> + /* We are updating an instruction. Make sure it is
> +  * written out
> +  */
> + wmb();
> + __asm__ __volatile__("flush %0" : : "r" (addr +  0));
> +
> + *(unsigned int *) (addr +  4) = start->insns[1];
> + /* We are updating an instruction. Make sure it is
> +  * written out
> +  */
> + wmb();
> + __asm__ __volatile__("flush %0" : : "r" (addr +  4));

There is no reason to say this in a comment, none of the other code
patching routines mention this, and it's even more excessive to say it
twice in quick succession basically in the same place.

Please just remove these comments, anyone reading this code knows we
are code patching and will realize that there are memory barrier
requirements.

Alternatively if you think it's worth mentioning, submit a separate
patch that adds the comment to all of the code patching routines for
consistency.

> @@ -267,6 +291,9 @@ static void __init sun4v_patch(void)
>  
>   sun4v_patch_2insn_range(&__sun4v_2insn_patch,
>   &__sun4v_2insn_patch_end);
> + if (sun4v_chip_type == SUN4V_CHIP_SPARC_M7)
> + sun_m7_patch_2insn_range(&__sun_m7_2insn_patch,
> + &__sun_m7_2insn_patch_end);

When a function call spans multiple lines, the second and subsequent line
must start at exactly the first column after the openning parenthesis of
the first line.  You must use the appropriate number of TAB and SPACE
characters necessary to achieve this.

Look at how the sun4v_patch_2insn_range() call before the one you added is
indented.

> @@ -2312,8 +2345,7 @@ int __meminit vmemmap_populate(unsigned long vstart, 
> unsigned long vend,
>   _PAGE_P_4U | _PAGE_W_4U);
>   if (tlb_type == hypervisor)
>   pte_base = (_PAGE_VALID | _PAGE_SZ4MB_4V |
> - _PAGE_CP_4V | _PAGE_CV_4V |
> - _PAGE_P_4V | _PAGE_W_4V);
> + page_cache4v_flag | _PAGE_P_4V | _PAGE_W_4V);

The existing indentation of these lines after the first of the
pte_base assignment were correct, please do not change how it is
indented.

> @@ -2465,8 +2497,8 @@ static void __init sun4v_pgprot_init(void)
>   kern_linear_pte_xor[0] = (_PAGE_VALID | _PAGE_SZ4MB_4V) ^
>   PAGE_OFFSET;
>  #endif
> - kern_linear_pte_xor[0] |= (_PAGE_CP_4V | _PAGE_CV_4V |
> -_PAGE_P_4V | _PAGE_W_4V);
> + kern_linear_pte_xor[0] |= (page_cache4v_flag | _PAGE_P_4V |
> + _PAGE_W_4V);

Likewise.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] PM / AVS: rockchip-io: depend on CONFIG_POWER_AVS

[Sebastian Reichel]

Hi,

On Sat, May 23, 2015 at 03:41:30PM +0200, Heiko Stuebner wrote:
> The rockchip io-domain driver currently only depends on ARCH_ROCKCHIP
> itself. This makes it possible to select the power-domain driver, but
> not the POWER_AVS class and results in the iodomain-driver not getting
> build in this case.
> 
> So add the additional dependency, which also results in the driver
> config option now being placed nicely into the AVS submenu.
> 
> Fixes: 662a958638bd ("PM / AVS: rockchip-io: add driver handling Rockchip io 
> domains")
> Signed-off-by: Heiko Stuebner 

Looks like the power supply entry in the MAINTAINERS file is missing
an "X: drivers/power/avs/" entry.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v4 1/2] serial_core: add pci uart early console support

[Greg Kroah-Hartman]

On Fri, May 22, 2015 at 09:06:59AM -0700, Bin Gao wrote:
> On some Intel Atom SoCs, the legacy IO port UART(0x3F8) is not available.
> Instead, a 8250 compatible PCI uart can be used as early console.
> This patch adds pci support to the 8250 early console driver uart8250.
> For example, to enable pci uart(00:21.3) as early console on these
> platforms, append the following line to the kernel command line
> (assume baud rate is 115200):
> earlyprintk=uart8250,pci32,0:24.2,115200n8
> 
> Signed-off-by: Bin Gao 
> ---
> Changes in v4:
>  - moved PCI_EARLY definition from arch/x86/Kconfig to drivers/pci/Kconfig
>  - added 'earlyprintk' for x86 as alias to the early param 'earlycon'

What about the changes in earlier versions?

And why do I have 3 copies of different "v4" patches in my inbox?

Please resend this, as v5, correctly, and we can review it that way.

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] power: max17042_battery: add HEALTH and TEMP_* properties support

[Sebastian Reichel]

Hi,

On Sun, May 24, 2015 at 09:11:58AM +0530, Ramakrishna Pallala wrote:
> This patch adds the support for following battery properties
> to max17042 fuel gauge driver.
> 
> POWER_SUPPLY_PROP_TEMP_ALERT_MIN
> POWER_SUPPLY_PROP_TEMP_ALERT_MAX
> POWER_SUPPLY_PROP_TEMP_MIN
> POWER_SUPPLY_PROP_TEMP_MAX
> POWER_SUPPLY_PROP_HEALTH

Thanks, queued.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH v2 0/2] Add support for BQ25890 charger chip

[Sebastian Reichel]

Hi,

On Tue, May 19, 2015 at 04:24:38PM +0300, Laurentiu Palcu wrote:
> Changes since v1:
>  * add comment in DT bindings regarding default driver behavior when
>"ti,thermal-regulation-threshold" property is missing;
>  * addressed all Krzysztof's comments, including addition of a reset
>check counter. Better to be safe than sorry :)
> 
> Hi,
> 
> This series adds support for BQ25890 USB charger chip. Information about
> the chip can be found here:
> 
> http://www.ti.com/product/bq25890

Thanks, queued.

-- Sebastian


signature.asc
Description: Digital signature

Re: [PATCH 0/2] power_supply: Small improvements for 4.2

[Sebastian Reichel]

Hi,

On Tue, May 19, 2015 at 04:16:28PM +0900, Krzysztof Kozlowski wrote:
> I send these separately because they are not fixes for current
> RC cycle.
> 
> The patch 1 could look like fix... but still this is for theoretical
> race condition.

Thanks, queued.


signature.asc
Description: Digital signature