Re: [PATCH] perf hist browser: change print format from lu to llu to fit u64 type

[Jiri Olsa]

On Tue, Nov 25, 2014 at 03:51:30PM -0800, Matt Mullins wrote:
> On Tue, Nov 18, 2014 at 05:00:27PM -0600, Tom Huynh wrote:
> > nr_events in tools/perf/ui/browsers/hists.c is of type u64, thus it should
> > be printed as %llu instead of %lu. The print format %lu causes perf report
> > to show 0 event count when running with 32-bit userspace without 
> > redirection. This patch fixes that problem.
> > 
> > Signed-off-by: Tom Huynh 
> > ---
> >  tools/perf/ui/browsers/hists.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
> > index cfb976b..49b2471 100644
> > --- a/tools/perf/ui/browsers/hists.c
> > +++ b/tools/perf/ui/browsers/hists.c
> > @@ -1254,7 +1254,7 @@ static int hists__browser_title(struct hists *hists,
> >  
> > nr_samples = convert_unit(nr_samples, );
> > printed = scnprintf(bf, size,
> > -  "Samples: %lu%c of event '%s', Event count 
> > (approx.): %lu",
> > +  "Samples: %lu%c of event '%s', Event count 
> > (approx.): %llu",
> >nr_samples, unit, ev_name, nr_events);
> 
> If I enable __attribute__((format(printf, ...))) on scnprintf, on a 64-bit
> build this gives me:
> 
> ui/browsers/hists.c: In function ‘hists__browser_title’:
> ui/browsers/hists.c:1258:7: error: format ‘%llu’ expects argument of type 
> ‘long long unsigned int’, but argument 7 has type ‘u64’ [-Werror=format=]
>nr_samples, unit, ev_name, nr_events);
>^
> 
> I would usually suggest using the PRIu64 macro which should(TM) evaluate to 
> the
> right string constant for the platform, but that appears to be a C99 thing.
> I'm not sure if that's kosher in tools/perf, but it does seem to build for me
> (on Fedora 20).

[jolsa@krava linux-perf]$ grep -rI PRIu64 tools/perf/ | wc -l
97

yep, it's kosher enough ;-)

jirka
--
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] ARM: EXYNOS: use u8 for val[] in struct exynos_pmu_conf

[Pankaj Dubey]

Hi Bartilomiej,


On Tuesday 08 July 2014 05:33 PM, Bartlomiej Zolnierkiewicz wrote:

Values stored in val[] are never bigger than a byte.

textdata bss dec hex filename
5264   4   452721498 arch/arm/mach-exynos/pmu.o.before
2992   4   43000 bb8 arch/arm/mach-exynos/pmu.o.after

Signed-off-by: Bartlomiej Zolnierkiewicz 
Acked-by: Kyungmin Park 


I tested this patch and it's really helpful to reduce size.
How about resubmitting this change? As this will not get applied on 
current tree.


Thanks,
Pankaj Dubey


---
  arch/arm/mach-exynos/common.h | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-exynos/common.h b/arch/arm/mach-exynos/common.h
index b850db4..55ff019 100644
--- a/arch/arm/mach-exynos/common.h
+++ b/arch/arm/mach-exynos/common.h
@@ -101,7 +101,7 @@ enum sys_powerdown {

  struct exynos_pmu_conf {
void __iomem *reg;
-   unsigned int val[NUM_SYS_POWERDOWN];
+   u8 val[NUM_SYS_POWERDOWN];
  };

  extern void exynos_sys_powerdown_conf(enum sys_powerdown mode);


--
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 v5 4/7] fs/fuse: support compiling out splice

[Pieter Smith]

On Tue, Nov 25, 2014 at 12:49:16PM -0800, j...@joshtriplett.org wrote:
> On Tue, Nov 25, 2014 at 08:42:42PM +0100, Pieter Smith wrote:
> > On Tue, Nov 25, 2014 at 03:17:13PM +0100, Miklos Szeredi wrote:
> > > [Trimming CC.  Please do the same for other patches.  I for one am not
> > > interested in the general tinification discussion]
> > > 
> > > On Tue, Nov 25, 2014 at 08:19:39AM +0100, Pieter Smith wrote:
> > > > To implement splice support, fs/fuse makes use of nosteal_pipe_buf_ops. 
> > > > This
> > > > struct is exported by fs/splice. The goal of the larger patch set is to
> > > > completely compile out fs/splice, so uses of the exported struct need 
> > > > to be
> > > > compiled out along with fs/splice.
> > > > 
> > > > This patch therefore compiles out splice support in fs/fuse when
> > > > CONFIG_SYSCALL_SPLICE is undefined.
> > > > 
> > > > Signed-off-by: Pieter Smith 
> > > > ---
> > > >  fs/fuse/dev.c | 9 +++--
> > > >  1 file changed, 7 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
> > > > index ca88731..e984302 100644
> > > > --- a/fs/fuse/dev.c
> > > > +++ b/fs/fuse/dev.c
> > > > @@ -1191,8 +1191,9 @@ __releases(fc->lock)
> > > >   * request_end().  Otherwise add it to the processing list, and set
> > > >   * the 'sent' flag.
> > > >   */
> > > > -static ssize_t fuse_dev_do_read(struct fuse_conn *fc, struct file 
> > > > *file,
> > > > -   struct fuse_copy_state *cs, size_t 
> > > > nbytes)
> > > > +static ssize_t __maybe_unused
> > > > +fuse_dev_do_read(struct fuse_conn *fc, struct file *file,
> > > > +struct fuse_copy_state *cs, size_t nbytes)
> > > 
> > > fuse_dev_do_read() is definitely going to remain used.  So no point in 
> > > adding
> > > __maybe_unused.
> > 
> > Off course, but at least gcc now also is aware that this is intentional and
> > nicely refrains from nagging you with a warning.
> 
> GCC shouldn't be warning about an unused fuse_dev_do_read; please
> recheck.  It will always get used by fuse_dev_read, which
> unconditionally gets used in the .aio_read field of fuse_dev_operations.
> 
> - Josh Triplett

Thanks for pointing this out. I was too hasty in my response.

- Pieter Smith
--
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 v5 4/7] fs/fuse: support compiling out splice

[Pieter Smith]

On Tue, Nov 25, 2014 at 08:42:42PM +0100, Pieter Smith wrote:
> On Tue, Nov 25, 2014 at 03:17:13PM +0100, Miklos Szeredi wrote:
> > [Trimming CC.  Please do the same for other patches.  I for one am not
> > interested in the general tinification discussion]
> > 
> > On Tue, Nov 25, 2014 at 08:19:39AM +0100, Pieter Smith wrote:
> > > To implement splice support, fs/fuse makes use of nosteal_pipe_buf_ops. 
> > > This
> > > struct is exported by fs/splice. The goal of the larger patch set is to
> > > completely compile out fs/splice, so uses of the exported struct need to 
> > > be
> > > compiled out along with fs/splice.
> > > 
> > > This patch therefore compiles out splice support in fs/fuse when
> > > CONFIG_SYSCALL_SPLICE is undefined.
> > > 
> > > Signed-off-by: Pieter Smith 
> > > ---
> > >  fs/fuse/dev.c | 9 +++--
> > >  1 file changed, 7 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/fs/fuse/dev.c b/fs/fuse/dev.c
> > > index ca88731..e984302 100644
> > > --- a/fs/fuse/dev.c
> > > +++ b/fs/fuse/dev.c
> > > @@ -1191,8 +1191,9 @@ __releases(fc->lock)
> > >   * request_end().  Otherwise add it to the processing list, and set
> > >   * the 'sent' flag.
> > >   */
> > > -static ssize_t fuse_dev_do_read(struct fuse_conn *fc, struct file *file,
> > > - struct fuse_copy_state *cs, size_t nbytes)
> > > +static ssize_t __maybe_unused
> > > +fuse_dev_do_read(struct fuse_conn *fc, struct file *file,
> > > +  struct fuse_copy_state *cs, size_t nbytes)
> > 
> > fuse_dev_do_read() is definitely going to remain used.  So no point in 
> > adding
> > __maybe_unused.
> 
> Off course, but at least gcc now also is aware that this is intentional and
> nicely refrains from nagging you with a warning.
> 
My apologies. My response was too hasty. You are right. This should not be
needed. I will revert this piece in v6 of this patch.
> > >  {
> > >   int err;
> > >   struct fuse_req *req;
> > > @@ -1291,6 +1292,7 @@ static ssize_t fuse_dev_read(struct kiocb *iocb, 
> > > const struct iovec *iov,
> > >   return fuse_dev_do_read(fc, file, , iov_length(iov, nr_segs));
> > >  }
> > >  
> > > +#ifdef CONFIG_SYSCALL_SPLICE
> > >  static ssize_t fuse_dev_splice_read(struct file *in, loff_t *ppos,
> > >   struct pipe_inode_info *pipe,
> > >   size_t len, unsigned int flags)
> > > @@ -1368,6 +1370,9 @@ out:
> > >   kfree(bufs);
> > >   return ret;
> > >  }
> > > +#else /* CONFIG_SYSCALL_SPLICE */
> > > +#define fuse_dev_splice_read NULL
> > > +#endif
> > 
> > This looks fine.
> > 
> > Thanks,
> > Miklos
> > 
> > >  
> > >  static int fuse_notify_poll(struct fuse_conn *fc, unsigned int size,
> > >   struct fuse_copy_state *cs)
> > > -- 
> > > 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/

[PATCH net-next V2] tun/macvtap: use consume_skb() instead of kfree_skb() when needed

[Jason Wang]

To be more friendly with drop monitor, we should only call kfree_skb() when
the packets were dropped and use consume_skb() in other cases.

Cc: Eric Dumazet 
Signed-off-by: Jason Wang 
---
Changes from V1:
- check the return value of tun/macvtap_put_user()
---
 drivers/net/macvtap.c | 5 -
 drivers/net/tun.c | 5 -
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 42a80d3..c171ab6 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -862,7 +862,10 @@ static ssize_t macvtap_do_read(struct macvtap_queue *q,
}
iov_iter_init(, READ, iv, segs, len);
ret = macvtap_put_user(q, skb, );
-   kfree_skb(skb);
+   if (ret < 0)
+   kfree_skb(skb);
+   else
+   consume_skb(skb);
break;
}
 
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index ac53a73..a21c130 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1363,7 +1363,10 @@ static ssize_t tun_do_read(struct tun_struct *tun, 
struct tun_file *tfile,
 
iov_iter_init(, READ, iv, segs, len);
ret = tun_put_user(tun, tfile, skb, );
-   kfree_skb(skb);
+   if (ret < 0)
+   kfree_skb(skb);
+   else
+   consume_skb(skb);
 
return ret;
 }
-- 
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/

[GIT PULL] irqchip: Core changes for v3.19 (round 3)

[Jason Cooper]

Thomas,

This round of changes includes the legacy orion platform gpio build
regression fix.  This adds a dependency on mvebu/fixes.  Both patches
are already a part of v3.18-rc5.  This is the cleanest way I could come
up with the resolve the issue.  Please let me know if you know of a
better way.

All changes have been in -next for a while except for

  2f90bce7ff1f ARM: orion: convert the irq_reg_{readl,writel} calls to the new 
API

I build-tested it against the legacy defconfigs before and after
applying and it did fix the regression.

This is an incremental pull request from tags/irqchip-core-3.19-2 up to
tags/irqchip-core-3.19-3 in the irqchip/core branch.

Please pull.

thx,

Jason.


The following changes since commit 1abbdbac362af44f337fdbae5dcbe8d9ced8d063:

  irqchip: brcmstb-l2: Convert driver to use irq_reg_{readl,writel} (2014-11-09 
04:03:35 +)

are available in the git repository at:

  git://git.infradead.org/users/jcooper/linux.git tags/irqchip-core-3.19-3

for you to fetch changes up to 377df64a1676fe069be9d9555edd862459d6090b:

  Merge branch 'irqchip/atmel' into irqchip/core (2014-11-26 07:02:27 +)


irqchip core changes for v3.19 (round 3)

 - orion gpio
- Use irq_reg_{readl,writel} API with a fix in mvebu

 - atmel-aic
- Migrate irq fixups from platform code to drivers


Boris BREZILLON (5):
  irqchip: atmel-aic: Add irq fixup for RTT block
  irqchip: atmel-aic: Add irq fixups for at91sam926x SoCs
  irqchip: atmel-aic: Add specific irq fixup function for sam9g45 and sam9rl
  irqchip: atmel-aic: Rename at91sam9_aic_irq_fixup for naming consistency
  irqchip: atmel-aic: Add missing entry for rm9200 irq fixups

Gregory CLEMENT (1):
  ARM: orion: convert the irq_reg_{readl,writel} calls to the new API

Jason Cooper (2):
  Merge tag 'tags/mvebu-fixes-3.18' into irqchip/core
  Merge branch 'irqchip/atmel' into irqchip/core

 drivers/irqchip/irq-atmel-aic-common.c | 26 
 drivers/irqchip/irq-atmel-aic-common.h |  2 ++
 drivers/irqchip/irq-atmel-aic.c| 26 +++-
 5 files changed, 82 insertions(+), 10 deletions(-)


NOTE:  The following changes are already in mainline and were removed
from the above summary:

Andrew Lunn (1):
  ARM: mvebu: armada xp: Generalize use of i2c quirk

Evgeniy Dushistov (1):
  ARM: orion: Fix for certain sequence of request_irq can cause irq storm

 arch/arm/mach-mvebu/board-v7.c |  2 +-
 arch/arm/plat-orion/gpio.c | 36 ++

The trailing chg/ins/del line has _not_ been adjusted to reflect this.

--
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 net-next 3/3] tuntap: reduce the size of tun_struct by using flex array.

[Pankaj Gupta]

> 
> From: Pankaj Gupta 
> Date: Tue, 25 Nov 2014 00:04:04 +0530
> 
> > This patch switches to flex array to implement the flow caches, it brings
> > several advantages:
> > 
> > - Reduce the size of the tun_struct structure, which allows us to increase
> > the
> >   upper limit of queues in future.
> > - Avoid higher order memory allocation. It will be useful when switching to
> >   pure hashing in flow cache which may demand a larger size array in
> >   future.
> > 
> > After this patch, the size of tun_struct on x86_64 reduced from 8512 to
> > 328
> > 
> > Signed-off-by: Jason Wang 
> > Signed-off-by: Pankaj Gupta 
> > Reviewed-by: David Gibson 
> 
> I see no reason to use flex arrays for this, you are preallocaing the
> memory so if anything flex array is adding an unnecessary level of
> redirection for every access in return for no real gains.
> 
> Just allocate the thing normally using kzalloc() or whatever.

I agree. Will do the changes and submit v3.
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-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 v14 0/3] Add drm driver for Rockchip Socs

[Joerg Roedel]

On Wed, Nov 26, 2014 at 01:37:51AM +0100, Heiko Stübner wrote:
> 
> Joerg, is your arm/rockchip branch [0] considered stable?
> 
> [0] 
> https://git.kernel.org/cgit/linux/kernel/git/joro/iommu.git/log/?h=arm/rockchip
>

Yes, this branch will not be rebased. It can be pulled into another
tree.


Joerg
--
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 v2] staging: lustre: fix pointer declarations

[Zahari Doychev]

This patch fixes pointer declarations from void * to void __user * in order
to remove some sparse warnings. The patch also enables again commented named
initializers for the iovec structures. The corrected pointers are used in
these structures as field member values.

lib-lnet.h:798:48: warning: incorrect type in initializer (different address 
spaces)
lib-lnet.h:798:48:expected void [noderef] *iov_base
lib-lnet.h:798:48:got void *dest
lib-lnet.h:787:47: warning: incorrect type in initializer (different address 
spaces)
lib-lnet.h:787:47:expected void [noderef] *iov_base
lib-lnet.h:787:47:got void *dest
lib-lnet.h:819:48: warning: incorrect type in initializer (different address 
spaces)
lib-lnet.h:819:48:expected void [noderef] *iov_base
lib-lnet.h:819:48:got void *src
lib-lnet.h:808:47: warning: incorrect type in initializer (different address 
spaces)
lib-lnet.h:808:47:expected void [noderef] *iov_base
lib-lnet.h:808:47:got void *src

Signed-off-by: Zahari Doychev 
---
 drivers/staging/lustre/include/linux/lnet/lib-lnet.h | 17 +
 1 file changed, 9 insertions(+), 8 deletions(-)

diff --git a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h 
b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
index 7e89b3b..c07fb04 100644
--- a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
+++ b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
@@ -780,22 +780,22 @@ void lnet_copy_kiov2kiov(unsigned int ndkiov, lnet_kiov_t 
*dkiov,
  unsigned int soffset, unsigned int nob);
 
 static inline void
-lnet_copy_iov2flat(int dlen, void *dest, unsigned int doffset,
+lnet_copy_iov2flat(int dlen, void __user *dest, unsigned int doffset,
   unsigned int nsiov, struct iovec *siov, unsigned int soffset,
   unsigned int nob)
 {
-   struct iovec diov = {/*.iov_base = */ dest, /*.iov_len = */ dlen};
+   struct iovec diov = {.iov_base = dest, .iov_len = dlen};
 
lnet_copy_iov2iov(1, , doffset,
  nsiov, siov, soffset, nob);
 }
 
 static inline void
-lnet_copy_kiov2flat(int dlen, void *dest, unsigned int doffset,
+lnet_copy_kiov2flat(int dlen, void __user *dest, unsigned int doffset,
unsigned int nsiov, lnet_kiov_t *skiov,
unsigned int soffset, unsigned int nob)
 {
-   struct iovec diov = {/* .iov_base = */ dest, /* .iov_len = */ dlen};
+   struct iovec diov = {.iov_base = dest, .iov_len = dlen};
 
lnet_copy_kiov2iov(1, , doffset,
   nsiov, skiov, soffset, nob);
@@ -803,9 +803,10 @@ lnet_copy_kiov2flat(int dlen, void *dest, unsigned int 
doffset,
 
 static inline void
 lnet_copy_flat2iov(unsigned int ndiov, struct iovec *diov, unsigned int 
doffset,
-  int slen, void *src, unsigned int soffset, unsigned int nob)
+  int slen, void __user *src, unsigned int soffset,
+  unsigned int nob)
 {
-   struct iovec siov = {/*.iov_base = */ src, /*.iov_len = */slen};
+   struct iovec siov = {.iov_base = src, .iov_len = slen};
 
lnet_copy_iov2iov(ndiov, diov, doffset,
  1, , soffset, nob);
@@ -813,10 +814,10 @@ lnet_copy_flat2iov(unsigned int ndiov, struct iovec 
*diov, unsigned int doffset,
 
 static inline void
 lnet_copy_flat2kiov(unsigned int ndiov, lnet_kiov_t *dkiov,
-   unsigned int doffset, int slen, void *src,
+   unsigned int doffset, int slen, void __user *src,
unsigned int soffset, unsigned int nob)
 {
-   struct iovec siov = {/* .iov_base = */ src, /* .iov_len = */ slen};
+   struct iovec siov = {.iov_base = src, .iov_len = slen};
 
lnet_copy_iov2kiov(ndiov, dkiov, doffset,
   1, , soffset, nob);
-- 
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 v2 3/4] pwm: kona: Fix enable, disable and config procedures

[Tim Kryger]

On Tue, Nov 25, 2014 at 11:40 AM, Scott Branden  wrote:
> From: Arun Ramamurthy 
>
> - Added helper functions to set and clear smooth and trigger bits
> - Added 400ns delays when clearing and setting trigger bit as requied
>   by spec
> - Added helper function to write prescale and other settings
> - Updated config procedure to match spec
> - Added code to handle pwn config when channel is disabled
> - Updated disable procedure to match spec
>
> Signed-off-by: Arun Ramamurthy 
> Reviewed-by: Ray Jui 
> Signed-off-by: Scott Branden 
> ---
>  drivers/pwm/pwm-bcm-kona.c | 100 
> +++--
>  1 file changed, 78 insertions(+), 22 deletions(-)

The driver is fairly small and this change rewrites a considerable amount of it.

Is there a actually specific deficiency that this change is intended to address?

I'm not sure all the extra helper functions improve readability.

>
> diff --git a/drivers/pwm/pwm-bcm-kona.c b/drivers/pwm/pwm-bcm-kona.c
> index fa0b5bf..06fa983 100644
> --- a/drivers/pwm/pwm-bcm-kona.c
> +++ b/drivers/pwm/pwm-bcm-kona.c
> @@ -65,6 +65,10 @@
>  #define DUTY_CYCLE_HIGH_MIN(0x)
>  #define DUTY_CYCLE_HIGH_MAX(0x00ff)
>
> +/* The delay required after clearing or setting
> +   PWMOUT_ENABLE*/
> +#define PWMOUT_ENABLE_HOLD_DELAY 400
> +
>  struct kona_pwmc {
> struct pwm_chip chip;
> void __iomem *base;
> @@ -76,28 +80,70 @@ static inline struct kona_pwmc *to_kona_pwmc(struct 
> pwm_chip *_chip)
> return container_of(_chip, struct kona_pwmc, chip);
>  }
>
> -static void kona_pwmc_apply_settings(struct kona_pwmc *kp, unsigned int chan)
> +static inline void kona_pwmc_set_trigger(struct kona_pwmc *kp,
> +unsigned int chan)
>  {
> unsigned int value = readl(kp->base + PWM_CONTROL_OFFSET);
>
> -   /* Clear trigger bit but set smooth bit to maintain old output */
> -   value |= 1 << PWM_CONTROL_SMOOTH_SHIFT(chan);
> +   /* set trigger bit to enable channel */
> +   value |= 1 << PWM_CONTROL_TRIGGER_SHIFT(chan);
> +   writel(value, kp->base + PWM_CONTROL_OFFSET);
> +   ndelay(PWMOUT_ENABLE_HOLD_DELAY);
> +}
> +static inline void kona_pwmc_clear_trigger(struct kona_pwmc *kp,
> +  unsigned int chan)
> +{
> +   unsigned int value = readl(kp->base + PWM_CONTROL_OFFSET);
> +
> +   /* Clear trigger bit */
> value &= ~(1 << PWM_CONTROL_TRIGGER_SHIFT(chan));
> writel(value, kp->base + PWM_CONTROL_OFFSET);
> +   ndelay(PWMOUT_ENABLE_HOLD_DELAY);
> +}
>
> -   /* Set trigger bit and clear smooth bit to apply new settings */
> +static inline void kona_pwmc_clear_smooth(struct kona_pwmc *kp,
> + unsigned int chan)
> +{
> +   unsigned int value = readl(kp->base + PWM_CONTROL_OFFSET);
> +
> +   /* Clear smooth bit */
> value &= ~(1 << PWM_CONTROL_SMOOTH_SHIFT(chan));
> -   value |= 1 << PWM_CONTROL_TRIGGER_SHIFT(chan);
> writel(value, kp->base + PWM_CONTROL_OFFSET);
>  }
>
> +static inline void kona_pwmc_set_smooth(struct kona_pwmc *kp, unsigned int 
> chan)
> +{
> +   unsigned int value = readl(kp->base + PWM_CONTROL_OFFSET);
> +
> +   /*  set smooth bit to maintain old output */
> +   value |= 1 << PWM_CONTROL_SMOOTH_SHIFT(chan);
> +   writel(value, kp->base + PWM_CONTROL_OFFSET);
> +}
> +
> +static void kona_pwmc_write_settings(struct kona_pwmc *kp, unsigned int chan,
> +unsigned long prescale, unsigned long pc,
> +unsigned long dc)
> +{
> +   unsigned int value;
> +
> +   value = readl(kp->base + PRESCALE_OFFSET);
> +   value &= ~PRESCALE_MASK(chan);
> +   value |= prescale << PRESCALE_SHIFT(chan);
> +   writel(value, kp->base + PRESCALE_OFFSET);
> +
> +   writel(pc, kp->base + PERIOD_COUNT_OFFSET(chan));
> +
> +   writel(dc, kp->base + DUTY_CYCLE_HIGH_OFFSET(chan));
> +
> +}
> +
>  static int kona_pwmc_config(struct pwm_chip *chip, struct pwm_device *pwm,
> int duty_ns, int period_ns)
>  {
> struct kona_pwmc *kp = to_kona_pwmc(chip);
> u64 val, div, rate;
> unsigned long prescale = PRESCALE_MIN, pc, dc;
> -   unsigned int value, chan = pwm->hwpwm;
> +   unsigned int ret, chan = pwm->hwpwm;
>
> /*
>  * Find period count, duty count and prescale to suit duty_ns and
> @@ -133,19 +179,30 @@ static int kona_pwmc_config(struct pwm_chip *chip, 
> struct pwm_device *pwm,
> return -EINVAL;
> }
>
> -   /* If the PWM channel is enabled, write the settings to the HW */
> -   if (test_bit(PWMF_ENABLED, >flags)) {
> -   value = readl(kp->base + PRESCALE_OFFSET);
> -   value &= ~PRESCALE_MASK(chan);
> -   value |= prescale << 

Re: [PATCH v3 3/3] mtd: block2mtd: Removes PAGE_MASK as a index to partition size

[Brian Norris]

On Sun, Nov 09, 2014 at 07:23:12AM -0500, Rodrigo Freire wrote:
> From: Felix Fietkau 
> 
> mtd: block2mtd: Removes PAGE_MASK as a index to partition size

You don't need to repeat the subject here.

> 
> PAGE_MASK is no longer needed with the new term.

This isn't too descriptive. What you probably mean is that we assume the
erase size is always larger than PAGE_SIZE.

> This patch keeps the device size aligned with the erase_size.
> 
> Signed-off-by: Felix Fietkau 
> Signed-off-by: Rodrigo Freire 
> Signed-off-by: Herton Krzesinski 
> ---
> V3: Separated on a single patch
> --- a/drivers/mtd/devices/block2mtd.c 2014-11-07 17:40:58.688747820 -0200
> +++ b/drivers/mtd/devices/block2mtd.c 2014-11-07 17:41:28.054750893 -0200
> @@ -291,8 +291,7 @@ static struct block2mtd_dev *add_device(
>   goto err_destroy_mutex;
>  
>   dev->mtd.name = name;
> -
> - dev->mtd.size = dev->blkdev->bd_inode->i_size & PAGE_MASK;
> + dev->mtd.size = dev->blkdev->bd_inode->i_size & ~(erase_size - 1);

You never guaranteed that erase_size is a power of two, so this doesn't
necessarily mask the way you'd like...

But also, why is this even necessary? I see that we should already have
errored out if this was actually significant, since we have above:

if ((long)dev->blkdev->bd_inode->i_size % erase_size) {
pr_err("erasesize must be a divisor of device size\n");
goto err_free_block2mtd;
}

>   dev->mtd.erasesize = erase_size;
>   dev->mtd.writesize = 1;
>   dev->mtd.writebufsize = PAGE_SIZE;

Brian
--
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/

[GIT PULL] irqchip: Core changes for v3.19 (round 2)

[Jason Cooper]

Thomas,

Here's the second round of changes for v3.19.  These have been in -next
for a while.  I'm sending this as a separate pull request so that the
next one doesn't color the summary with the contents of mvebu/fixes.

This is an incremental pull request from tags/irqchip-core-3.19 up to
tags/irqchip-core-3.19-2 in the irqchip/core branch.

Please pull.

thx,

Jason.


The following changes since commit 1dacf194b1468546a5715db58cbb65d50b598482:

  irqchip: irq-armada-370-xp: Use proper return value for ->set_affinity() 
(2014-11-09 03:56:37 +)

are available in the git repository at:

  git://git.infradead.org/users/jcooper/linux.git tags/irqchip-core-3.19-2

for you to fetch changes up to 1abbdbac362af44f337fdbae5dcbe8d9ced8d063:

  irqchip: brcmstb-l2: Convert driver to use irq_reg_{readl,writel} (2014-11-09 
04:03:35 +)


irqchip core changes for v3.19 (round 2)

 - genirq
- Modify irq_reg_{readl,writel} for big endian I/O accessors

 - bcm{stb,7120}-l2
- Allow sharing of driver between mips and arm


Kevin Cernekee (13):
  genirq: Generic chip: Change irq_reg_{readl,writel} arguments
  genirq: Generic chip: Allow irqchip drivers to override 
irq_reg_{readl,writel}
  genirq: Generic chip: Add big endian I/O accessors
  irqchip: brcmstb-l2: Eliminate dependency on ARM code
  irqchip: bcm7120-l2: Eliminate bad IRQ check
  irqchip: bcm7120-l2, brcmstb-l2: Remove ARM Kconfig dependency
  irqchip: bcm7120-l2: Make sure all register accesses use base+offset
  irqchip: bcm7120-l2: Fix missing nibble in gc->unused mask
  irqchip: bcm7120-l2: Use gc->mask_cache to simplify suspend/resume 
functions
  irqchip: bcm7120-l2: Extend driver to support 64+ bit controllers
  irqchip: bcm7120-l2: Decouple driver from brcmstb-l2
  irqchip: bcm7120-l2: Convert driver to use irq_reg_{readl,writel}
  irqchip: brcmstb-l2: Convert driver to use irq_reg_{readl,writel}

 .../interrupt-controller/brcm,bcm7120-l2-intc.txt  |  26 ++-
 arch/arm/mach-bcm/Kconfig  |   1 +
 drivers/irqchip/Kconfig|   6 +-
 drivers/irqchip/Makefile   |   4 +-
 drivers/irqchip/irq-atmel-aic.c|  40 ++---
 drivers/irqchip/irq-atmel-aic5.c   |  65 
 drivers/irqchip/irq-bcm7120-l2.c   | 174 +
 drivers/irqchip/irq-brcmstb-l2.c   |  41 +++--
 drivers/irqchip/irq-sunxi-nmi.c|   4 +-
 drivers/irqchip/irq-tb10x.c|   4 +-
 include/linux/irq.h|  32 +++-
 kernel/irq/generic-chip.c  |  36 +++--
 12 files changed, 263 insertions(+), 170 deletions(-)
--
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: Re: [PATCH ftrace/core v6 5/5] kselftest, ftrace: Add ftrace IPMODIFY flag test

[Masami Hiramatsu]

(2014/11/25 23:44), Shuah Khan wrote:
> On 11/25/2014 07:42 AM, Shuah Khan wrote:
>> On 11/24/2014 06:23 PM, Masami Hiramatsu wrote:
>>> (2014/11/25 1:18), Shuah Khan wrote:
 On 11/24/2014 07:11 AM, Masami Hiramatsu wrote:
> (CC'ed Shuah, since this is related to kselftest)
>
>
> So, if your server directory is mounted with noexec, it's an environmental
> problem. I guess you can not build any kernel drivers on that testbox, 
> can you?
>
> Anyway, this gives us a good question, "should test binaries be made by
> server or client(testbox) environment?" This ipmodify driver is a binary
> and it should be built with the kernel binary (by server) I think.
> But yes, I missed the Makefile didn't allow that (this always referred
> installed running kernel builddir).
>
> I hope to have CONFIG_KSELFTEST_BINARIES for Kconfig, or make 
> prep_kselftest
> target to build these binaries with kernel...
>
> Shuah, what would you think about this?

 I am working on patch series to add an install target to the
 main kernel makefile, so these tests can be built and installed
 on a target just like we do with kernel and modules. I hope to
 get this in 3.19 or definitely into 3.20

 This probably will help address the problem you are seeing.
 Install target is needed for qemu type environments as well.
>>>
>>> Yes, that is what we need for this test case!
>>> Please CC to me when sending the series. I'd like to try and
>>> know how it works :)
>>>
>>
>> Good. Please take a look at this thread and give it a try. Please
>> give me feedback as well. This is the first step to get the install
>> feature added and then we can refine it at the selftests level as
>> needed.
>>
>> https://lkml.org/lkml/2014/11/11/851

OK, I'll try that.
BTW, are those patches included in the below kernel.org tree ?

https://git.kernel.org/cgit/linux/kernel/git/shuah/linux-kselftest.git/

> Forgot to mention I didn't include ftrace in this first series for
> install, planning to add it in my next round of patches. I have the
> code ready for to do that.

No problem, I'll wait for your series :)

Thank you,


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu...@hitachi.com


--
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 tty tree with the tty.current tree

[Stephen Rothwell]

Hi Greg,

Today's linux-next merge of the tty tree got a conflict in
drivers/tty/serial/of_serial.c between commit a5e9ab291c60 ("Revert
"serial: of-serial: add PM suspend/resume support"") from the
tty.current tree and commit 513e43858102 ("serial: of-serial: fix up PM
ops on no_console_suspend and port type") from the tty tree.

I fixed it up (I assumed the tty tree version is correct and used that)
and can carry the fix as necessary (no action is required).

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

diff --cc drivers/tty/serial/of_serial.c
index f2fde9c21e9b,fd00e2521584..
--- a/drivers/tty/serial/of_serial.c
+++ b/drivers/tty/serial/of_serial.c
@@@ -269,7 -342,9 +342,8 @@@ static struct of_device_id of_platform_
  static struct platform_driver of_platform_serial_driver = {
.driver = {
.name = "of_serial",
 -  .owner = THIS_MODULE,
.of_match_table = of_platform_serial_table,
+   .pm = _serial_pm_ops,
},
.probe = of_platform_serial_probe,
.remove = of_platform_serial_remove,


pgpt0BAs45Lph.pgp
Description: OpenPGP digital signature

Re: [PATCH 1/2] virito: introduce methods of fixing device features

[Jason Wang]

- Original Message -
> Jason Wang  writes:
> > Buggy host may advertised buggy host features (a usual case is that host
> > advertise a feature whose dependencies were missed). In this case, driver
> > should detect and disable the buggy features by itself.
> 
> Sorry, I've been focussing elsewhere.
> 
> I would really prefer that drivers offer a "feature_depends" table,
> which can indicate that feature A depends on feature B, and have the
> core iterate, complain and fixup as necessary.
> 
> Is that expressive enough, or do we need more?
> 
> Thanks,
> Rusty.

I suggested something like this in https://lkml.org/lkml/2014/11/19/132, but
Michael does not like it ...
--
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 0/2] Reenable might_sleep() checks for might_fault() when atomic

[Michael S. Tsirkin]

On Tue, Nov 25, 2014 at 12:43:24PM +0100, David Hildenbrand wrote:
> I recently discovered that commit 662bbcb2747c2422cf98d3d97619509379eee466
> removed/skipped all might_sleep checks for might_fault() calls when in atomic.

Yes.  You can add e.g. might_sleep in your code if, for some reason, it is
illegal to call it in an atomic context.
But faults are legal in atomic if you handle the possible
errors, and faults do not necessary cause caller to sleep, so might_fault
should not call might_sleep.

> Reason was to allow calling copy_(to|from)_user while in pagefault_disabled(),
> because otherwise, CONFIG_DEBUG_ATOMIC_SLEEP would find false positives.

That wasn't the only reason BTW.
Andi Kleen also showed that compiler did a terrible job optimizing
get/put user when might_sleep was called.
See e.g. this thread:
https://lkml.org/lkml/2013/8/14/652
There was even an lwn.net article about it, that I don't seem to be
able to locate.
So might_sleep is not appropriate for lightweight operations like __get_user,
which people literally expect to be a single instruction.


I also have a project going which handles very short packets by copying
them into guest memory directly without waking up a thread.
I do it by calling recvmsg on a socket, then switching to
a thread if I get back EFAULT.
Not yet clean enough to upstream but it does seem to cut
the latency down quite a bit, so I'd like to have the option.


Generally, a caller that does something like this under a spinlock:
preempt_disable
pagefault_disable
error = copy_to_user
pagefault_enable
preempt_enable_no_resched

is not doing anything wrong and should not get a warning,
as long as error is handled correctly later.

You can also find the discussion around the patches
educational:
http://article.gmane.org/gmane.comp.emulators.kvm.devel/109928

> However
> we have the inatomic variants of these function for this purpose.

Does inatomic install fixups now?

Last I checked, it didn't so it did not satisfy this purpose.
See this comment from x86:

 * Copy data from kernel space to user space.  Caller must check
 * the specified block with access_ok() before calling this function.
 * The caller should also make sure he pins the user space address
 * so that we don't result in page fault and sleep.


Also - switching to inatomic would scatter if (atomic) all
over code. It's much better to simply call the same
function (e.g. recvmsg) and have it fail gracefully:
after all, we have code to handle get/put user errors
anyway.

> The result of this change was that all guest access (that correctly uses
> might_fault()) doesn't perform atomic checks when CONFIG_DEBUG_ATOMIC_SLEEP is
> enabled. We lost a mighty debugging feature for user access.

What's the path you are trying to debug?

If your code can faults, then it's safe to call
from atomic context.
If it can't, it must pin the page.  You can not do access_ok checks and
then assume access won't fault.

> As I wasn't able to come up with any other reason why this should be
> necessary, I suggest turning the might_sleep() checks on again in the
> might_fault() code.

Faults triggered with pagefault_disabled do not cause
caller to sleep, merely to fail and get an error,
so might_sleep is simply wrong.

> 
> pagefault_disable/pagefault_enable seems to be used mainly for futex, perf 
> event
> and kmap.
> 
> Going over all changes since that commit, it seems like most code already 
> uses the
> inatomic variants of copy_(to|from)_user. Code relying on (get|put)_user 
> during
> pagefault_disable() don't make use of any might_fault() in their 
> (get|put)_user
> implementation. Examples:
> - arch/m68k/include/asm/futex.h
> - arch/parisc/include/asm/futex.h
> - arch/sh/include/asm/futex-irq.h
> - arch/tile/include/asm/futex.h
> So changing might_fault() back to trigger might_sleep() won't change a thing 
> for
> them. Hope I haven't missed anything.

Did you check the generated code?
On x86 it seems to me this patchset is definitely going to
slow things down, in fact putting back in a performance regression
that Andi found.


> I only identified one might_fault() that would get triggered by get_user() on
> powerpc and fixed it by using the inatomic variant (not tested). I am not sure
> if we need some non-sleeping access_ok() prior to __get_user_inatomic().
> 
> By looking at the code I was wondering where the correct place for 
> might_fault()
> calls is? Doesn't seem to be very consistent. Examples:
> 
>| asm-generic | arm | arm64 | frv | m32r | x86 and s390
> ---
> get_user() |   Yes   | Yes | Yes   | No  | Yes  | Yes
> __get_user()   |   No| Yes | No| No  | Yes  | No
> put_user() |   Yes   | Yes | Yes   | No  | Yes  | Yes
> __put_user()   |   No| Yes | No| No  | Yes  | No
> copy_to_user() |   Yes   | No  | 

Re: frequent lockups in 3.18rc4

[Juergen Gross]

On 11/26/2014 07:21 AM, Linus Torvalds wrote:

On Tue, Nov 25, 2014 at 9:52 PM, Linus Torvalds
 wrote:


And leave it running for a while, and see if the trace is always the
same, or if there are variations on it...


Amusing.

Lookie here:


http://lists.xenproject.org/archives/html/xen-changelog/2005-08/msg00310.html

That's from 2005.


:-)



Anyway, I don't see why the cr3 issue matters, *unless* there is some
situation where the scheduler can run with interrupts enabled. And why
this is Xen-related, I have no idea.

The Xen patches seem to have lost that

  /* On Xen the line below does not always work. Needs investigating! */

line when backporting the 2.6.29 patches to Xen. And clearly nobody
investigated.

So please do get me back-traces, and we'll investigate. Better late
than never. But it does sound Xen-specific - although it's possible
that Xen just triggers some timing (and has apparently been able to
trigger it since 2005) that DaveJ now triggers on his one machine.


Yeah, this sounds plausible.

I'm working on the back traces right now, hope to have them soon.


Juergen



So DaveJ, even though this does appear Xen-centric (Xentric?) and
you're running on bare hardware, maybe you could do the same thing in
that x86-64 vmalloc_fault(). The timing with Jürgen is kind of
intriguing - if 3.18-rc made it happen much more often for him, maybe
it really is very timing-sensitive, and you actually are seeing a
non-Xen version of the same thing...

Linus



--
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] fs/binfmt_elf.c: fix inconsistent vma dump size

[Jungseung Lee]

Hello, Andrew.

2014-11-26 6:38 GMT+09:00 Andrew Morton :
> On Sun, 23 Nov 2014 04:16:39 +0900 Jungseung Lee  wrote:
>
>> vma_dump_size() has been used several times on actual dumper
>> and it is supposed to be same values for same vma.
>> But vma_dump_size() could be different, while coredump is procceeded.
>> (e.g. remove shared memory)
>>
>> In that case, header info and vma size could be inconsistent
>> and it cause wrong coredump file creation.
>>
>> Fix the problem by always using the same vma dump size
>> which is stored in vma_filsz.
>
> So concurrent shared memory removal causes inconsistencies.
>
> But concurrent shared memory removal can still cause inconsistency
> after this patch, can't it?  If it happens while vma_filesz[] is being
> populated or if it happens between vma_filesz[] population and
> vma_filesz[] usage.  This will result in a dump file which is
> internally consistent, but is inconsistent with reality?
>
Yes, you are right.

The problem is internally inconsistent between header and dump data in
core file that
cause wrong vma detection in gdb.
In my opinion, if the factor whether to dump or not is changed while
coredump is working it is
reasonable to choose anyone.
  (bit 1) anonymous shared memory vs  (bit 3) file-backed shared memory

> If my understanding is correct then please fully describe this scenario
> within the changelog and explain why it is tolerable, if it is
> tolerable.
>
OK, I'll.

>> @@ -2093,7 +2083,20 @@ static int elf_core_dump(struct coredump_params *cprm)
>>
>>   dataoff = offset = roundup(offset, ELF_EXEC_PAGESIZE);
>>
>> - offset += elf_core_vma_data_size(gate_vma, cprm->mm_flags);
>> + vma_filesz = kmalloc(sizeof(*vma_filesz) * (segs - 1), GFP_KERNEL);
>
> Use kmalloc_array() here, in case a disaster has occurred...
>
I'll try to find another way how to pass or save vma size with consistency.

>> + if (!vma_filesz)
>> + goto end_coredump;
>> +
>> + for (i = 0, vma = first_vma(current, gate_vma); vma != NULL;
>> + vma = next_vma(vma, gate_vma)) {
>> + unsigned long dump_size;
>> +
>> + dump_size = vma_dump_size(vma, cprm->mm_flags);
>> + vma_filesz[i++] = dump_size;
>> + vma_data_size += dump_size;
>> + }
>> +
>> + offset += vma_data_size;
>
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 1/1] MTD: Deletion of unnecessary checks before two function calls

[Brian Norris]

On Thu, Nov 20, 2014 at 01:55:23PM +0100, SF Markus Elfring wrote:
> From: Markus Elfring 
> Date: Thu, 20 Nov 2014 13:50:43 +0100
> 
> The functions kfree() and pci_dev_put() test whether their argument is NULL
> and then return immediately. Thus the test around the call is not needed.
> 
> This issue was detected by using the Coccinelle software.
> 
> Signed-off-by: Markus Elfring 

Applied to l2-mtd.git.

Brian
--
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] arm64: Kprobes with single stepping support

[David Long]

On 11/19/14 09:55, David Long wrote:

On 11/19/14 06:25, Will Deacon wrote:

On Wed, Nov 19, 2014 at 11:21:24AM +, Sandeepa Prabhu wrote:

On 18 November 2014 20:26, Will Deacon  wrote:


One thing I noticed looking through this patch is that we're
effectively
reinventing a bunch of the instruction decoding logic that we
already have
in the kernel (introduced since Sandeepa last sent his patch).

Could you take a look at include/asm/insn.h and kernel/insn.c
please, and
see if you can at least consolidate some of this? Some of it should
be easy
(i.e. reusing masks, using existing #defines to construct BRK
encodings),
but I appreciate there may be places where kprobes needs to add
extra bits,
in which case I'd really like to keep this all together if at all
possible.

We're currently in a position where the module loader, BPF jit,
ftrace and
the proposed alternative patching scheme are all using the same
instruction
manipulation functions, so we should try to continue that trend if
we can.

Will,

kernel/insn.c support generating instruction encodings(forming opcodes
with given specifications), so for kprobes, only BRK encoding can use
this mechanism.
For instruction simulation, the instruction behavior should be
simulated on saved pt_regs, which is not supported on insn.c routines,
so still need probes-simulate-insn.c. Please point me if I am missing
something here.


I was thinking of the magic hex numbers in the kprobes decode tables,
which
seem to correspond directly to the instruction classes described in
insn.c

Keeping the actual emulation code separate makes sense.

Will


Of course that follows the model of the much more complex arm32
kprobes/uprobes decoding.  I can have a go at replacing it with insn.c
calls.

-dl



While the existing aarch64_get_insn_class() function in insn.c is 
somewhat useful here what is really needed is a function that identifies 
if an instruction uses the pc (branch, load literal, load address). 
Such instructions cannot be arbitrarily moved around in isolation, and 
do not fall neatly into the existing "class"es.  I've written a simple 
aarch64_insn_uses_pc() function to add to insn.c but I'd like to hear 
agreement that this is a good approach before sending out the patch. 
Thoughts?


-dl

--
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/

[GIT PULL] irqchip: Fixes for v3.18 (round 2)

[Jason Cooper]

Thomas,

Here's the last couple of fixes.

This is an incremental pull request from tags/irqchip-urgent-3.18 up to
tags/irqchip-urgent-3.18-2 in the irqchip/urgent branch.

Please pull.

thx,

Jason.


The following changes since commit 758e8366754d3fa57da978fef9d2c652f7b55c02:

  irqchip: armada-370-xp: Fix MPIC interrupt handling (2014-11-02 01:31:10 
+)

are available in the git repository at:

  git://git.infradead.org/users/jcooper/linux.git tags/irqchip-urgent-3.18-2

for you to fetch changes up to d99ba4465a08138966083d6c256b2f66e85a5095:

  irqchip: brcmstb-l2: Fix error handling of irq_of_parse_and_map (2014-11-26 
06:28:42 +)


irqchip fixes for v3.18 (round 2)

 - atmel-aic
- Fix irqdomain init

 - bcm{7120,stb}-l2
- Fix error handling in irq_of_parse_and_map


Boris Brezillon (1):
  irqchip: atmel-aic: Fix irqdomain initialization

Dmitry Torokhov (2):
  irqchip: bcm7120-l2: Fix error handling of irq_of_parse_and_map
  irqchip: brcmstb-l2: Fix error handling of irq_of_parse_and_map

 drivers/irqchip/irq-atmel-aic-common.c | 6 +++---
 drivers/irqchip/irq-bcm7120-l2.c   | 4 ++--
 drivers/irqchip/irq-brcmstb-l2.c   | 4 ++--
 3 files changed, 7 insertions(+), 7 deletions(-)
--
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-next] tun/macvtap: use consume_skb() instead of kfree_skb() in tun/macvtap_do_read()

[Jason Wang]

On 11/26/2014 02:26 PM, Eric Dumazet wrote:
> On Wed, 2014-11-26 at 14:08 +0800, Jason Wang wrote:
>> To be more friendly with drop monitor, we should use comsume_skb() instead
>> of kfree_skb() in tun/macvtap_do_read(). Otherwise, the packets will be
>> marked as dropped.
>>
>> Signed-off-by: Jason Wang 
>> ---
>>  drivers/net/macvtap.c | 2 +-
>>  drivers/net/tun.c | 2 +-
>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
>> index 42a80d3..74d1b23 100644
>> --- a/drivers/net/macvtap.c
>> +++ b/drivers/net/macvtap.c
>> @@ -862,7 +862,7 @@ static ssize_t macvtap_do_read(struct macvtap_queue *q,
>>  }
>>  iov_iter_init(, READ, iv, segs, len);
>>  ret = macvtap_put_user(q, skb, );
>> -kfree_skb(skb);
>> +consume_skb(skb);
>>  break;
>>  }
>>  
>> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
>> index ac53a73..d7edeaf 100644
>> --- a/drivers/net/tun.c
>> +++ b/drivers/net/tun.c
>> @@ -1363,7 +1363,7 @@ static ssize_t tun_do_read(struct tun_struct *tun, 
>> struct tun_file *tfile,
>>  
>>  iov_iter_init(, READ, iv, segs, len);
>>  ret = tun_put_user(tun, tfile, skb, );
>> -kfree_skb(skb);
>> +consume_skb(skb);
>>  
>>  return ret;
>>  }
>
> These patches keep going on, but they are wrong.
>
> If you care about drop monitor, then you want to not hide drops but
> precisely report them.
>
> Surely tun_put_user() can return an error, and then packet _is_ dropped.

True, I miss this. Will post V2. 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 v4 0/2] mtd: hisilicon: add a new driver for NAND controller of hisilicon hip04 Soc

[Haojian Zhuang]

On Tue, Nov 4, 2014 at 8:46 PM, Zhou Wang  wrote:
> This patchset adds the support for NAND controller of hisilicon hip04 Soc.
> The NAND controller IP was developed by hisilicon and needs a new driver to
> support it. This patchset is based on v3.18-rc1. I have tested that NAND flash
> controller works fine in Hip04 D01 board.
>
> Changes in v4:
> - add mtd->dev.parent = >dev, thanks Frans Klaver.
> Changes in v3:
> - Modify code to eliminate some code style warnings.
> - add ecc-bits input check.
> - avoid using waterfall style in hisi_nfc_cmdfunc().
> Changes in v2:
> - Remove the patch for device tree, now patchset only has the driver and its
>   device tree binding documentation.
> - Change the file name: hisi_nand.c to hisi504_nand.c.
> Changes in v1:
> - Remove callback functions out of struct hinfc_host, and call them directly
>   in relative functions.
> - Change hinfc_read and hinfc_write from macros to inline functions.
> - Instead of putting pointers, embed struct nand_chip and struct mtd_info in
>   struct hinfc_host directly.
> - rewrite some unclear lines in device tree binding document, correct some
>   code style error.
>
> Link on v3:
> - https://lkml.org/lkml/2014/10/28/386
> Link on v2:
> - https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg750071.html
> Link on v1:
> - https://lkml.org/lkml/2014/7/15/198
>
> Zhou Wang (2):
>   mtd: hisilicon: add a new NAND controller driver for hisilicon hip04 Soc
>   mtd: hisilicon: add device tree binding documentation
>
>  .../devicetree/bindings/mtd/hisi504-nand.txt   |   40 +
>  drivers/mtd/nand/Kconfig   |5 +
>  drivers/mtd/nand/Makefile  |1 +
>  drivers/mtd/nand/hisi504_nand.c|  846 
> 
>  4 files changed, 892 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/mtd/hisi504-nand.txt
>  create mode 100644 drivers/mtd/nand/hisi504_nand.c
>
> --
> 1.7.9.5
>

Hi David & Brian,

How do you think about this nand patch set? Could it be merged into v3.19?

Best Regards
Haojian
--
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] irqchip: bcm7120-l2: fix error handling of irq_of_parse_and_map

[Jason Cooper]

On Fri, Nov 14, 2014 at 02:16:14PM -0800, Dmitry Torokhov wrote:
> Return value of irq_of_parse_and_map() is unsigned int, with 0
> indicating failure, so testing for negative result never works.
> 
> Signed-off-by: Dmitry Torokhov 
> ---
> 
> Not tested, found by casual code inspection.
> 
>  drivers/irqchip/irq-bcm7120-l2.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

Both applied to irqchip/urgent with Florian's Ack and Kevin's Tested-by.

thx,

Jason.
--
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: Value for policy-cpuinfo.transition_latency

[Viresh Kumar]

On 26 November 2014 at 03:30, nick  wrote:
> Greeting Viresh and Rafael,

Hi,

> I am wondering what the values for transition latency are set to in this file 
> our they nanoseconds or microseconds.
> As there seem to be two rather easy FIX MEs in this file, if someone tells me 
> the units of transition latency.

Which file? Solving FIXME's isn't that easy always. And all the information
you need is present in cpufreq core or documentation. Please search that.
This time I can help you: Documentation/cpu-freq/cpu-drivers.txt

If you are looking to fix FIXME's like this:

FIXME: what's the actual transition time?

Then forget it. It can only be done by people who have a board to fix it
+ they have to measure the time it takes to change freqs.
--
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] mtd: phram: Allow multiple phram devices on cmd line

[Brian Norris]

On Sun, Nov 09, 2014 at 04:24:44PM +, Rob Ward wrote:
> From 4e9b8ff3a6731a0ac43eac2e8bdf47101ff20ede Mon Sep 17 00:00:00 2001
> From: Rob Ward 
> Date: Tue, 21 Oct 2014 17:46:53 +0100
> Subject: [PATCH] mtd: phram: Allow multiple phram devices on cmd line
> 
> Allow the phram module the ability to create multiple phram mtd
> devices via the kernel command line.

Is the sysfs module parameter option not sufficient?

  /sys/module/phram/parameters/phram

It looks like it should be reusable for multiple device creations.

Notably, we use 000 permissions for module_param_call(), so the
parameter doesn't even show up by default AFAICT. I had to hack it to
0600 or similar.

> Currently the phram module only allows a single mtd device to be
> created via the kernel command line. This is due to the phram
> module having to store the values until it is initialised
> later. This storage is done using a single char[] meaning when
> the module_param_call is made the previous value is overidden.
> 
> This change modifies the phram system to use a char[][] allowing
> multiple devices to be created.
> 
> The array size if controlled using the new config option
> CONFIG_MTD_PHRAM_MAX_CMDLINE_ARGS that allows the maximum
> number of devices to be specified. Currently this option
> defaults to a value of 1 leaving the behaviour unchanged.
> 
> If the array is full a message is printed to the console and the
> module_param_call returns.
> 
> To test, in all cases an area of memory needs to be reserved via
> the command line e.g. memmap=10M$114M
> 
> To test with phram build into the kernel on the command line add
> the following:
> 
> phram.phram=alpha,114Mi,1Mi phram.phram=beta,115Mi,1Mi
> 
> If CONFIG_MTD_PHRAM_MAX_CMDLINE_ARGS is left as default i.e. 1
> then the first device, alpha will be created only. If the value of
> CONFIG_MTD_PHRAM_MAX_CMDLINE_ARGS is increased to 2 or more then
> both alpha and beta will be created.

I really don't think we want this to be a Kconfig option. We can
dynamically allocate and use a linked list instead, which would be more
flexible and avoid making a fixed compile-time choice.

> To test phram built as a module insmod with the following arguments:
> 
> phram=gamma,114Mi,1Mi phram=delta,115Mi,1Mi
> 
> In this case two devices should be created.
> 
> Signed-off-by: Rob Ward 
> ---
>  drivers/mtd/devices/Kconfig | 12 
>  drivers/mtd/devices/phram.c | 45 
> -
>  2 files changed, 52 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/mtd/devices/Kconfig b/drivers/mtd/devices/Kconfig
> index c49d0b1..5fdc80b 100644
> --- a/drivers/mtd/devices/Kconfig
> +++ b/drivers/mtd/devices/Kconfig
> @@ -136,6 +136,18 @@ config MTD_PHRAM
> doesn't have access to, memory beyond the mem=xxx limit, nvram,
> memory on the video card, etc...
>  
> +config MTD_PHRAM_MAX_CMDLINE_ARGS
> + int "Max number of devices via Kernel command line"
> + depends on MTD_PHRAM=y
> + default 1
> + help
> +   Specify the number of phram devices that can be initialised
> +   using the Kernel command line.
> +
> +   This option is only applicable when phram is built into the
> +   Kernel. When built as a module many devices can be specified
> +   at module insmod.
> +
>  config MTD_LART
>   tristate "28F160xx flash driver for LART"
>   depends on SA1100_LART
> diff --git a/drivers/mtd/devices/phram.c b/drivers/mtd/devices/phram.c
> index effd9a4..223f221 100644
> --- a/drivers/mtd/devices/phram.c
> +++ b/drivers/mtd/devices/phram.c
> @@ -212,9 +212,13 @@ static int phram_init_called;
>   * - phram.phram=,, for built-in case
>   * We leave 64 bytes for the device name, 20 for the address and 20 for the
>   * size.
> + *
> + * The maximum number of devices supported is controlled by the
> + * MTD_PHRAM_MAX_CMDLINE_ARGS config option
> + *
>   * Example: phram.phram=rootfs,0xa000,512Mi
>   */
> -static char phram_paramline[64 + 20 + 20];
> +static char phram_paramline[CONFIG_MTD_PHRAM_MAX_CMDLINE_ARGS][64 + 20 + 20];
>  #endif
>  
>  static int phram_setup(const char *val)
> @@ -271,6 +275,9 @@ static int phram_param_call(const char *val, struct 
> kernel_param *kp)
>  #ifdef MODULE
>   return phram_setup(val);
>  #else
> + int paramline_it = 0;
> + int arraysize = 0;

Neither of these need to be initialized here. And can you shorten the
long-ish names? We don't need an "iterator" -- it's just and index 'i'.

> +
>   /*
>* If more parameters are later passed in via
>* /sys/module/phram/parameters/phram
> @@ -290,9 +297,27 @@ static int phram_param_call(const char *val, struct 
> kernel_param *kp)
>* phram_setup().
>*/
>  
> - if (strlen(val) >= sizeof(phram_paramline))
> + if (strlen(val) >= sizeof(phram_paramline[0]))
>   return -ENOSPC;
> - strcpy(phram_paramline, val);
> +
> + arraysize = 

Re: [PATCH net-next] tun/macvtap: use consume_skb() instead of kfree_skb() in tun/macvtap_do_read()

[Eric Dumazet]

On Wed, 2014-11-26 at 14:08 +0800, Jason Wang wrote:
> To be more friendly with drop monitor, we should use comsume_skb() instead
> of kfree_skb() in tun/macvtap_do_read(). Otherwise, the packets will be
> marked as dropped.
> 
> Signed-off-by: Jason Wang 
> ---
>  drivers/net/macvtap.c | 2 +-
>  drivers/net/tun.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
> index 42a80d3..74d1b23 100644
> --- a/drivers/net/macvtap.c
> +++ b/drivers/net/macvtap.c
> @@ -862,7 +862,7 @@ static ssize_t macvtap_do_read(struct macvtap_queue *q,
>   }
>   iov_iter_init(, READ, iv, segs, len);
>   ret = macvtap_put_user(q, skb, );
> - kfree_skb(skb);
> + consume_skb(skb);
>   break;
>   }
>  
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index ac53a73..d7edeaf 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -1363,7 +1363,7 @@ static ssize_t tun_do_read(struct tun_struct *tun, 
> struct tun_file *tfile,
>  
>   iov_iter_init(, READ, iv, segs, len);
>   ret = tun_put_user(tun, tfile, skb, );
> - kfree_skb(skb);
> + consume_skb(skb);
>  
>   return ret;
>  }


These patches keep going on, but they are wrong.

If you care about drop monitor, then you want to not hide drops but
precisely report them.

Surely tun_put_user() can return an error, and then packet _is_ dropped.



--
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 01/19] usb: common: drd-lib: Add DRD lib for USB.

[Peter Chen]

On Tue, Nov 25, 2014 at 06:41:37PM +0530, George Cherian wrote:
> Add USB DRD library. This Library facilitates to
> switch roles between HOST and Device modes.
> 
> A DRD should be added to the library using usb_drd_add().
> Register the HOST and UDC using usb_drd_register_hcd/udc().
> Un-Register the HOST and UDC using usb_drd_unregister_hcd/udc().
> 
> Depending on the state of IP -
> Call the following to start/stop HOST controller
> usb_drd_start/stop_hcd().
> This internally calls usb_add/remove_hcd() or IP specific low level start/stop
> defined in ll_start/stop
> 
> Call the following to start/stop UDC
> usb_drd_start/stop_udc().
> This internally calls udc_start/udc_stop() or IP specific low level start/stop
> defined in ll_start/stop
> 
> Signed-off-by: George Cherian 
> ---
>  drivers/usb/Kconfig  |  15 ++
>  drivers/usb/common/Makefile  |   1 +
>  drivers/usb/common/drd-lib.c | 346 
> +++
>  include/linux/usb/drd.h  |  77 ++
>  4 files changed, 439 insertions(+)
>  create mode 100644 drivers/usb/common/drd-lib.c
>  create mode 100644 include/linux/usb/drd.h
> 
> diff --git a/drivers/usb/Kconfig b/drivers/usb/Kconfig
> index ae481c3..ea0d944 100644
> --- a/drivers/usb/Kconfig
> +++ b/drivers/usb/Kconfig
> @@ -34,6 +34,21 @@ config USB_COMMON
>   default y
>   depends on USB || USB_GADGET
>  
> +config DRD_LIB
> + tristate  "DRD Library support"
> + default y
> + depends on USB && USB_GADGET
> + ---help---
> +   This option adds DRD Library support for Universal Serial Bus (USB).
> +   DRD Library faciliatets the Role switching by HOST and DEVICE roles,
> +   If your hardware has a Dual Role Device.
> +
> +   The DRD Library uses USB core API's to start/stop HOST controllers,
> +   UDC API's to start/stop DEVICE controllers, ther by enabling to
> +   switch roles between HOST and Device modes.

%s/ther by/thereby

> +
> +   Say N if unsure.
> +
>  config USB_ARCH_HAS_HCD
>   def_bool y
>  
> diff --git a/drivers/usb/common/Makefile b/drivers/usb/common/Makefile
> index ca2f8bd..e2c1593 100644
> --- a/drivers/usb/common/Makefile
> +++ b/drivers/usb/common/Makefile
> @@ -7,3 +7,4 @@ usb-common-y+= common.o
>  usb-common-$(CONFIG_USB_LED_TRIG) += led.o
>  
>  obj-$(CONFIG_USB_OTG_FSM) += usb-otg-fsm.o
> +obj-$(CONFIG_DRD_LIB)   += drd-lib.o
> diff --git a/drivers/usb/common/drd-lib.c b/drivers/usb/common/drd-lib.c
> new file mode 100644
> index 000..6159436
> --- /dev/null
> +++ b/drivers/usb/common/drd-lib.c
> @@ -0,0 +1,346 @@
> +/**
> + * drd-lib.c - USB DRD library functions
> + *
> + * Copyright (C) 2014 Texas Instruments
> + * Author: George Cherian 
> + *
> + * This program is free software: you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2  of
> + * the License as published by the Free Software Foundation.
> + *
> + * 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.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program.  If not, see .
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +/**
> + * struct usb_drd - describes one dual role device
> + * @host - the HOST controller device of this drd
> + * @gadget - the gadget of drd
> + * @parent - the device to the actual controller
> + * @list - for use by the drd lib
> + * @state - specifies the current state
> + *
> + * This represents the internal data structure which is used by the UDC-class
> + * to hold information about udc driver and gadget together.
> + */

It is dual role struct, why you only talk about device?

> +struct usb_drd {
> + struct usb_drd_host *host;
> + struct usb_drd_gadget   *gadget;
> + struct device   *parent;
> + struct list_headlist;
> + unsigned intstate;
> +};
> +
> +static LIST_HEAD(drd_list);
> +static DEFINE_SPINLOCK(drd_lock);
> +
> +static struct usb_drd *usb_drd_get_dev(struct device *parent)
> +{
> + struct usb_drd *drd;
> +
> + spin_lock(_lock);
> + list_for_each_entry(drd, _list, list)
> + if (drd->parent == parent)
> + goto out;
> + drd = NULL;
> +out:
> + spin_unlock(_lock);
> +
> + return drd;
> +}
> +
> +int usb_drd_get_state(struct device *parent)
> +{
> + struct usb_drd  *drd;
> +
> + drd = usb_drd_get_dev(parent);
> + if (!drd)
> + return -ENODEV;
> +
> + return drd->state;
> +}
> +EXPORT_SYMBOL_GPL(usb_drd_get_state);
> +
> +int usb_drd_release(struct device *parent)
> +{
> + struct usb_drd  

Re: virtio_blk: fix defaults for max_hw_sectors and max_segment_size

[Rusty Russell]

Mike Snitzer  writes:
> On Thu, Nov 20 2014 at  3:30pm -0500,
> Michael S. Tsirkin  wrote:
>
>> On Thu, Nov 20, 2014 at 02:00:59PM -0500, Mike Snitzer wrote:
>> > virtio_blk incorrectly established -1U as the default for these
>> > queue_limits.  Set these limits to sane default values to avoid crashing
>> > the kernel.
> ...
>> > Attempting to mkfs.xfs against a thin device from this thin-pool quickly
>> > resulted in fs/direct-io.c:dio_send_cur_page()'s BUG_ON.
>> 
>> Why exactly does it BUG_ON?
>> Did some memory allocation fail?
>
> No idea, kernel log doesn't say.. all it has is "kernel BUG" pointing to
> fs/direct-io.c:dio_send_cur_page()'s BUG_ON.
>
> I could dig deeper on _why_ but honestly, there really isn't much point.

There is *always* a point in understanding the code you are modifying.

> virtio-blk doesn't get to live in fantasy-land just because it happens
> to think it is limitless.

Calm down please.

We don't have a sector limit.  We have a segment limit, which is set
above this line.

Cheers,
Rusty.
--
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/4] pwm: kona: Fix incorrect enable after channel polarity change

[Tim Kryger]

On Tue, Nov 25, 2014 at 11:40 AM, Scott Branden  wrote:
> From: Arun Ramamurthy 
>
> The pwm core code requires a separate call for enabling the channel
> and hence the driver does not need to set pwm_trigger after a
> polarity change

The framework does restrict when polarity changes can occur but it
isn't clear to me that there is any reason to delay applying the
polarity change.  Keep in mind that polarity matters even when a PWM
is disabled.  While disabled, the output should be equivalent to an
enabled configuration with zero duty.  Thus for normal polarity the
output is constant low and for inversed polarity the output is
constant high. I believe there is an expectation that the output is
updated to reflect the requested polarity change prior to returning to
the caller.

>
> Signed-off-by: Arun Ramamurthy 
> Reviewed-by: Ray Jui 
> Signed-off-by: Scott Branden 
> ---
>  drivers/pwm/pwm-bcm-kona.c | 5 -
>  1 file changed, 5 deletions(-)
>
> diff --git a/drivers/pwm/pwm-bcm-kona.c b/drivers/pwm/pwm-bcm-kona.c
> index 29eef9e..fa0b5bf 100644
> --- a/drivers/pwm/pwm-bcm-kona.c
> +++ b/drivers/pwm/pwm-bcm-kona.c
> @@ -173,11 +173,6 @@ static int kona_pwmc_set_polarity(struct pwm_chip *chip, 
> struct pwm_device *pwm,
>
> writel(value, kp->base + PWM_CONTROL_OFFSET);
>
> -   kona_pwmc_apply_settings(kp, chan);
> -
> -   /* Wait for waveform to settle before gating off the clock */
> -   ndelay(400);
> -
> clk_disable_unprepare(kp->clk);
>
> return 0;
> --
> 2.1.3
>
--
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: frequent lockups in 3.18rc4

[Linus Torvalds]

On Tue, Nov 25, 2014 at 9:52 PM, Linus Torvalds
 wrote:
>
> And leave it running for a while, and see if the trace is always the
> same, or if there are variations on it...

Amusing.

Lookie here:

   http://lists.xenproject.org/archives/html/xen-changelog/2005-08/msg00310.html

That's from 2005.

Anyway, I don't see why the cr3 issue matters, *unless* there is some
situation where the scheduler can run with interrupts enabled. And why
this is Xen-related, I have no idea.

The Xen patches seem to have lost that

 /* On Xen the line below does not always work. Needs investigating! */

line when backporting the 2.6.29 patches to Xen. And clearly nobody
investigated.

So please do get me back-traces, and we'll investigate. Better late
than never. But it does sound Xen-specific - although it's possible
that Xen just triggers some timing (and has apparently been able to
trigger it since 2005) that DaveJ now triggers on his one machine.

So DaveJ, even though this does appear Xen-centric (Xentric?) and
you're running on bare hardware, maybe you could do the same thing in
that x86-64 vmalloc_fault(). The timing with Jürgen is kind of
intriguing - if 3.18-rc made it happen much more often for him, maybe
it really is very timing-sensitive, and you actually are seeing a
non-Xen version of the same thing...

   Linus
--
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 kvm-arm tree with the kvm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the kvm-arm tree got a conflict in
arch/ia64/kvm/kvm-ia64.c between commit 003f7de62589 ("KVM: ia64:
remove") from the kvm tree and commit bf4bea8e9a90 ("kvm: fix
kvm_is_mmio_pfn() and rename to kvm_is_reserved_pfn()") from the
kvm-arm tree.

I fixed it up (the former removed the file, so I did that) and can
carry the fix as necessary (no action is required).

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


pgpiXNtxsocFG.pgp
Description: OpenPGP digital signature

Re: [PATCH] x86: Allow 1GB pages to be SPECIAL similar to 2MB

[Kirill A. Shutemov]

On Tue, Nov 25, 2014 at 01:23:04PM -0800, Andrew Morton wrote:
> On Thu, 25 Sep 2014 09:40:24 -0500 James Custer  wrote:
> 
> > Superpages allocated by SGI's superpages module can be backed by 1GB pages,
> > but direct i/o cannot be used. The superpages module uses _PAGE_BIT_SPECIAL
> > to disable direct i/o because some code depends on the memory being backed
> > by page structures. But, because superpages have no backing page structures
> > this causes a panic.
> > 
> > This is the way direct i/o on 1GB pages fails:
> > 
> >BUG: unable to handle kernel paging request at 
> > ea003800
> > [60463.203795] IP: [] gup_huge_pud+0x9a/0xe0
> > [60463.210058] PGD 83ffd3067 PUD 83ffd2067 PMD 0
> > [60463.215052] Oops:  [#1] SMP
> > 
> > Stack traceback for pid 77136
> > 0x8867a88ae3007713674825  1   56   R  0x8867a88ae970 
> > *readdirectsp
> >  [] gup_huge_pud+0x9a/0xe0
> >  [] gup_pud_range+0x173/0x1b0
> >  [] get_user_pages_fast+0xe7/0x1b0
> >  [] dio_get_page+0x83/0x150
> >  [] do_direct_IO+0x81/0x420
> >  [] direct_io_worker+0x1a9/0x340
> >  [] ext3_direct_IO+0xe8/0x2c0 [ext3]
> >  [] generic_file_aio_read+0x237/0x260
> >  [] do_sync_read+0xc8/0x110
> >  [] vfs_read+0xc7/0x130
> >  [] sys_read+0x53/0xa0
> >  [] system_call_fastpath+0x16/0x1b
> > 
> > gup_huge_pud() is trying to find the page structure, and with superpages 
> > there
> > is none.
> > 
> > With direct i/o on 2MB pages:
> > 
> > static int gup_pmd_range(pud_t pud, unsigned long addr, unsigned long end,
> > int write, struct page **pages, int *nr)
> > {
> >  ...
> > if (pmd_none(pmd) || pmd_trans_splitting(pmd))
> > return 0;
> > 
> > and pmd_trans_splitting() is testing _PAGE_SPLITTING, which is an alias
> > for _PAGE_SPECIAL which we set on the 2MB or 1GB pages mapped in by 
> > superpages.
> > 
> > But gup_pud_range() has no such check:
> > 
> > static int gup_pud_range(pgd_t pgd, unsigned long addr, unsigned long end,
> > int write, struct page **pages, int *nr)
> > {
> >   ...
> > if (pud_none(pud))
> > return 0;
> > 
> > Therefore direct i/o on 1GB pages attempts to get a page structure and 
> > panics.
> > 
> > ...
> >
> > @@ -223,7 +221,7 @@ static int gup_pud_range(pgd_t pgd, unsigned long addr, 
> > unsigned long end,
> > pud_t pud = *pudp;
> >  
> > next = pud_addr_end(addr, end);
> > -   if (pud_none(pud))
> > +   if (pud_none(pud) || (pud_val(pud) & _PAGE_SPECIAL))
> > return 0;
> > if (unlikely(pud_large(pud))) {
> > if (!gup_huge_pud(pud, addr, next, write, pages, nr))
> 
> If I'm understanding it correctly, this patch is only needed by SGI's
> superpages module, yes?
> 
> That being said, it looks like a reasonable precaution and we could
> easily carry it.

Previously we used PSE + SOFTW1 in pmd_t for pmd_trans_splitting().
I don't think it's good idea to reserve a bit in page table entries for
use-case kernel by itself doesn't support. Especially, that it's a bit in
present entry.

-- 
 Kirill A. Shutemov
--
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: [BUG] [PATCH] next: cyapa: fix inop touchpad after resume on Acer C720

[Dudley Du]

More info: I did all testings based on kernel 3.14.0 on Acer C70.

Thanks,
Dudley

> -Original Message-
> From: Dudley Du
> Sent: 2014?11?26? 14:01
> To: 'Jeremiah Mahler'
> Cc: 'linux-kernel@vger.kernel.org'
> Subject: RE: [BUG] [PATCH] next: cyapa: fix inop touchpad after resume on Acer
> C720
>
> Hi Jermiah,
>
> Does your code merged from chromiumos gerrit?
> If so, the patch you used seems very old, because the log shown the cyapa 
> driver
> module name still be "cyapa", and it has already been changed to "cyapatp" 
> for log
> time.
> Currently, I have already removed all old pathces from the gerrit system, now 
> only
> v11 pathces existing in gerrit system.
> Could you please try to refetch again,
> or
> could you try the v11 patches that from
> http://patchwork.kernel.org/bundle/dudlx/input_cyapa_v11/
> or
> The attached zip file contians the v11 patches for chromiumos projects, same 
> as
> currently existing in gerrit system.
> Besides the first and the latest patches which are specifical for chromionos, 
> the
> reset pathces are exactly same as the cyapa v11 pathces that submitted to this
> kernel commuinty.
>
> Thanks,
> Dudley
>
> > -Original Message-
> > From: Jeremiah Mahler [mailto:jmmah...@gmail.com]
> > Sent: 2014?11?25? 18:07
> > To: Dudley Du
> > Cc: linux-kernel@vger.kernel.org
> > Subject: [BUG] [PATCH] next: cyapa: fix inop touchpad after resume on Acer 
> > C720
> >
> > On an Acer C720 running linux-next (20141124) the touchpad will become
> > inoperative after a resume.  Reloading the cyapa driver restores normal
> > operation.
> >
> > The following trace appeared in dmesg after a resume.
> >
> >   [   21.803878] [ cut here ]
> >   [   21.803886] WARNING: CPU: 0 PID: 901 at kernel/irq/manage.c:444
> > enable_irq+0x3a/0x80()
> >   [   21.803886] Unbalanced enable for IRQ 0
> >   [   21.803927] Modules linked in: binfmt_misc bnep ecb ath3k btusb
> bluetooth
> > uvcvideo videobuf2_vmalloc videobuf2_memops videobuf2_core v4l2_common
> > videodev media nfsd auth_rpcgss oid_registry nfs_acl nfs lockd grace fscache
> > sunrpc arc4 ath9k snd_hda_codec_hdmi ath9k_common ath9k_hw ath
> > tpm_infineon mac80211 i915 joydev x86_pkg_temp_thermal iTCO_wdt
> > intel_powerclamp cyapa iTCO_vendor_support intel_rapl iosf_mbi coretemp
> > kvm_intel kvm cfg80211 snd_hda_codec_realtek snd_hda_codec_generic
> > chromeos_laptop crct10dif_pclmul crc32_pclmul i2c_algo_bit crc32c_intel
> > snd_hda_intel drm_kms_helper xhci_pci xhci_hcd ghash_clmulni_intel
> > snd_hda_controller snd_hda_codec cryptd rfkill drm usbcore evdev pcspkr
> > snd_hwdep serio_raw snd_pcm i2c_i801 shpchp snd_timer usb_common lpc_ich
> > snd tpm_tis mfd_core video i2c_designware_pci
> >   [   21.803941]  tpm battery ac soundcore i2c_designware_platform
> > i2c_designware_core i2c_core processor button fuse autofs4 ext4 crc16 
> > mbcache
> > jbd2 sg sd_mod ahci libahci libata scsi_mod fan thermal thermal_sys 
> > sdhci_acpi
> > sdhci mmc_core
> >   [   21.803945] CPU: 0 PID: 901 Comm: systemd-sleep Not tainted
> > 3.18.0-rc5-next-20141121 #50
> >   [   21.803946] Hardware name: Acer Peppy, BIOS  04/30/2014
> >   [   21.803949]   81725091 81535c6c
> > 8800740cbc78
> >   [   21.803951]  81069f61 880100405400 
> > 88006c9c1c20
> >   [   21.803953]  88006ae73220 0010 81069fda
> > 8171bbb8
> >   [   21.803953] Call Trace:
> >   [   21.803959]  [] ? dump_stack+0x40/0x50
> >   [   21.803964]  [] ? warn_slowpath_common+0x81/0xb0
> >   [   21.803967]  [] ? warn_slowpath_fmt+0x4a/0x50
> >   [   21.803969]  [] ? __irq_get_desc_lock+0x52/0x90
> >   [   21.803971]  [] ? enable_irq+0x3a/0x80
> >   [   21.803976]  [] ? cyapa_resume+0x85/0xb0 [cyapa]
> >   [   21.803984]  [] ? i2c_device_pm_thaw+0x40/0x40
> > [i2c_core]
> >   [   21.803988]  [] ? dpm_run_callback+0x4a/0x100
> >   [   21.803991]  [] ? device_resume+0xd6/0x210
> >   [   21.803994]  [] ? dpm_resume+0x109/0x2c0
> >   [   21.803997]  [] ? dpm_resume_end+0xd/0x20
> >   [   21.804000]  [] ?
> > suspend_devices_and_enter+0x137/0x630
> >   [   21.804003]  [] ? pm_suspend+0x352/0x3d0
> >   [   21.804005]  [] ? state_store+0x76/0xf0
> >   [   21.804010]  [] ? kernfs_fop_write+0x12c/0x180
> >   [   21.804013]  [] ? vfs_write+0xb2/0x1f0
> >   [   21.804015]  [] ? SyS_write+0x42/0xb0
> >   [   21.804018]  [] ? system_call_fastpath+0x16/0x1b
> >   [   21.804020] ---[ end trace 83d258439f6abe06 ]---
> >
> > Performing a bisect on the kernel revealed that the following commit
> > introduced the bug.
> >
> >   commit b1cfa7b4388285c0f0b486f152ab0cb18612c779
> >   Author: Dudley Du 
> >   Date:   Sun Nov 9 12:36:34 2014 -0800
> >
> >   Input: cyapa - switch to using managed resources
> >
> >   Use of managed resources simplifies error handling and device removal
> > code.
> >
> >   Signed-off-by: Dudley Du 
> >   [Dmitry: added open/close 

[PATCH net-next] tun/macvtap: use consume_skb() instead of kfree_skb() in tun/macvtap_do_read()

[Jason Wang]

To be more friendly with drop monitor, we should use comsume_skb() instead
of kfree_skb() in tun/macvtap_do_read(). Otherwise, the packets will be
marked as dropped.

Signed-off-by: Jason Wang 
---
 drivers/net/macvtap.c | 2 +-
 drivers/net/tun.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/net/macvtap.c b/drivers/net/macvtap.c
index 42a80d3..74d1b23 100644
--- a/drivers/net/macvtap.c
+++ b/drivers/net/macvtap.c
@@ -862,7 +862,7 @@ static ssize_t macvtap_do_read(struct macvtap_queue *q,
}
iov_iter_init(, READ, iv, segs, len);
ret = macvtap_put_user(q, skb, );
-   kfree_skb(skb);
+   consume_skb(skb);
break;
}
 
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index ac53a73..d7edeaf 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -1363,7 +1363,7 @@ static ssize_t tun_do_read(struct tun_struct *tun, struct 
tun_file *tfile,
 
iov_iter_init(, READ, iv, segs, len);
ret = tun_put_user(tun, tfile, skb, );
-   kfree_skb(skb);
+   consume_skb(skb);
 
return ret;
 }
-- 
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: frequent lockups in 3.18rc4

[Linus Torvalds]

On Tue, Nov 25, 2014 at 9:24 PM, Juergen Gross  wrote:
>
> Working on it. Triggering it via sysrq(l) isn't working: machine hung
> up. I'll try a dump, but this might take some time due to the machine
> size...

Actually, in that patch that did this:

-   pgd = pgd_offset(current->active_mm, address);
+   pgd = (pgd_t *)__va(read_cr3()) + pgd_index(address);

make the code do:

pgd = (pgd_t *)__va(read_cr3()) + pgd_index(address);
WARN_ON(pdg != pgd_offset(current->active_mm, address));

and now you should get a nice backtrace for exactly when it happens,
but it's on a working kernel, so nothing will lock up.

Hmm?

And leave it running for a while, and see if the trace is always the
same, or if there are variations on it...

Thanks,

  Linus
--
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 1/4] pwm: kona: Remove setting default smooth type and polarity for all channels

[Tim Kryger]

On Tue, Nov 25, 2014 at 11:40 AM, Scott Branden  wrote:
> From: Arun Ramamurthy 
>
> The probe routine unnecessarily sets the smooth type and polarity for
> all channels. This causes the channel for the speaker to click at the same
> time the backlight turns on. The smooth type and polarity should be set 
> individually
> for each channel as required and no defaults need to be set.

I am guessing you are talking about a PWM controlled beeper/buzzer.

Can you mention what board you are observing this issue on?

Also please explain why setting these bits result in an audible click.

>
> Signed-off-by: Arun Ramamurthy 
> Reviewed-by: Ray Jui 
> Signed-off-by: Scott Branden 
> ---
>  drivers/pwm/pwm-bcm-kona.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/pwm/pwm-bcm-kona.c b/drivers/pwm/pwm-bcm-kona.c
> index 02bc048..29eef9e 100644
> --- a/drivers/pwm/pwm-bcm-kona.c
> +++ b/drivers/pwm/pwm-bcm-kona.c
> @@ -266,12 +266,9 @@ static int kona_pwmc_probe(struct platform_device *pdev)
> return ret;
> }
>
> -   /* Set smooth mode, push/pull, and normal polarity for all channels */
> -   for (chan = 0; chan < kp->chip.npwm; chan++) {
> -   value |= (1 << PWM_CONTROL_SMOOTH_SHIFT(chan));
> +   /* Set push/pull for all channels */
> +   for (chan = 0; chan < kp->chip.npwm; chan++)
> value |= (1 << PWM_CONTROL_TYPE_SHIFT(chan));
> -   value |= (1 << PWM_CONTROL_POLARITY_SHIFT(chan));
> -   }
>
> writel(value, kp->base + PWM_CONTROL_OFFSET);

While the smooth bit need not be set here, it is important that the
polarity bit be set.

Otherwise software will report the polarity as normal when it it is
actually inversed.

Consider the case where a userspace process is controlling the PWM via sysfs.
--
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 1/2] Input: add regulator haptic driver

[Pankaj Dubey]

Hi Jaewon,

On Monday 24 November 2014 08:20 PM, Jaewon Kim wrote:

This patch adds support for haptic driver controlled by
voltage of regulator. And this driver support for
Force Feedback interface from input framework

Signed-off-by: Jaewon Kim 
Signed-off-by: Hyunhee Kim 
Acked-by: Kyungmin Park 
---
  .../devicetree/bindings/input/regulator-haptic.txt |   24 ++
  drivers/input/misc/Kconfig |   11 +
  drivers/input/misc/Makefile|1 +
  drivers/input/misc/regulator-haptic.c  |  247 
  include/linux/input/regulator-haptic.h |   30 +++
  5 files changed, 313 insertions(+)
  create mode 100644 
Documentation/devicetree/bindings/input/regulator-haptic.txt
  create mode 100644 drivers/input/misc/regulator-haptic.c
  create mode 100644 include/linux/input/regulator-haptic.h

diff --git a/Documentation/devicetree/bindings/input/regulator-haptic.txt 
b/Documentation/devicetree/bindings/input/regulator-haptic.txt
new file mode 100644
index 000..5a44e8f
--- /dev/null
+++ b/Documentation/devicetree/bindings/input/regulator-haptic.txt
@@ -0,0 +1,24 @@
+* Requlator Haptic Device Tree Bindings


Nit: %s/Requlator/Regulator


+
+The regulator haptic driver controlled by voltage of regulator.
+This driver implemented via Force Feedback interface.
+


[Snip]


diff --git a/include/linux/input/regulator-haptic.h 
b/include/linux/input/regulator-haptic.h
new file mode 100644
index 000..15a629c
--- /dev/null
+++ b/include/linux/input/regulator-haptic.h
@@ -0,0 +1,30 @@
+/*
+ * Regulator Haptic Platform Data
+ *
+ * Copyright (c) 2014 Samsung Electronics Co., Ltd.
+ * Author: Jaewon Kim 
+ * Author: Hyunhee Kim 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef _REGULATOR_HAPTIC_H
+


Please define _REGULATOR_HAPTIC_H here as:
#define _REGULATOR_HAPTIC_H


+/*
+ * struct regulator_haptic_data - Platform device data
+ *
+ * @regulator: Power supply to the haptic motor
+ * @max_volt: maximum voltage value supplied to the haptic motor.
+ * 
+ * @min_volt: minimum voltage value supplied to the haptic motor.
+ * 
+ */
+struct regulator_haptic_data {
+   struct regulator *regulator;
+   unsigned int max_volt;
+   unsigned int min_volt;
+};
+
+#endif /* _REGULATOR_HAPTIC_H */



With these two minor fixes please feel free to add:

Reviewed-by: Pankaj Dubey 


Thanks,
Pankaj Dubey
--
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] virito: introduce methods of fixing device features

[Rusty Russell]

Jason Wang  writes:
> Buggy host may advertised buggy host features (a usual case is that host
> advertise a feature whose dependencies were missed). In this case, driver
> should detect and disable the buggy features by itself.

Sorry, I've been focussing elsewhere.

I would really prefer that drivers offer a "feature_depends" table,
which can indicate that feature A depends on feature B, and have the
core iterate, complain and fixup as necessary.

Is that expressive enough, or do we need more?

Thanks,
Rusty.
--
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: frequent lockups in 3.18rc4

[Juergen Gross]

On 11/26/2014 06:09 AM, Linus Torvalds wrote:


On Nov 25, 2014 8:39 PM, "Jürgen Groß" mailto:jgr...@suse.com>> wrote:
 >
 > I COULD trigger it with 3.17. Took much longer, but I've seen it once.
 > And from Xen hypervisor data it was clear it was the same bug (cpu
 > spinning in pmd_lock()).

I'm still hoping you can give a back trace. I'd like to know what access
it is that can trigger this, and preferably what the call chain to it was...


Working on it. Triggering it via sysrq(l) isn't working: machine hung
up. I'll try a dump, but this might take some time due to the machine
size...

If this isn't working I can always modify the hypervisor to show me
more of the kernel stack in that situation. This will be a pure dump,
but it should be possible to extract the back trace from that.



I do believe it happened in 3.17, I just want to understand the but more
- not just apply the fix..


Sure.



Most of Dave's lockup back traces did not have the whole page fault in
them, so while Dave has seen this too, there might be different symptoms...


Stay tuned... :-)


Juergen

--
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 6/7] ARM: mvebu: add PHY support to the dts for the USB controllers on Armada 375

[Kishon Vijay Abraham I]

On Wednesday 26 November 2014 10:47 AM, Jason Cooper wrote:
> On Wed, Nov 26, 2014 at 10:43:08AM +0530, Kishon Vijay Abraham I wrote:
>> Hi,
>>
>> On Wednesday 26 November 2014 09:29 AM, Jason Cooper wrote:
>>> On Sat, Nov 22, 2014 at 10:20:43AM +0100, Gregory CLEMENT wrote:
 Hi Jason,

 On 22/11/2014 03:08, Jason Cooper wrote:
> On Thu, Nov 13, 2014 at 12:47:48PM +0100, Gregory CLEMENT wrote:
>> Now that the USB cluster node has been added, use it as a PHY provider
>> for the USB controller linked to it: the first EHCI and the xHCI.
>>
>> Signed-off-by: Gregory CLEMENT 
>>
>> Looks like I'm not cc'ed in v4 of this patch series :-(
> 
> I've bounced emails maybe three times in my life.  Thought it might work
> here.  Did it?

Actually I'm CC'ed, just that search didn't find it. Sorry for the noise.

Thanks
Kishon
> 
> thx,
> 
> Jason.
> 
--
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 06/11] irqchip: bcm7120-l2: Change DT binding to allow non-contiguous IRQEN/IRQSTAT

[Kevin Cernekee]

On Mon, Nov 24, 2014 at 6:31 AM, Jonas Gorski  wrote:
> On Mon, Nov 24, 2014 at 3:40 AM, Kevin Cernekee  wrote:
>> To date, all supported controllers have had the IRQEN register at offset
>> 0x00 and the IRQSTAT register at 0x04.  So in DT we would typically see
>> something like:
>>
>> reg = <0xf0406800 0x8>;
>>
>> We still want to support this format, but we also need to support cases
>> where IRQEN and IRQSTAT aren't adjacent.  So, we will amend the driver to
>> accept an alternate format that looks like this:
>>
>> reg = <0xf0406800 0x4 0xf0406804 0x4>;
>>
>> i.e. if the first resource_size() == 4, assume that the first resource
>> points to IRQEN and that the next resource points to IRQSTAT.  If the
>> first resource_size() == 8, retain the current behavior.
>>
>> Signed-off-by: Kevin Cernekee 
>
> Hmm ... the more I think about this, the less I like it.
>
> Using the amount and size of the reg-properties to infer a certain
> layout seems rather hackish and dirty to me. Maybe we should just use
> different compatible match ids for that? E.g. brcm,bm7120-l2-intc for
> the 32-bit en/stat pairs, and e.g. brcm,bcm6368-l2-intc for the 64-bit
> wide one. Or maybe make the bcm63xx one a separate driver and let it
> share code with the bcm7120-l2-intc driver.

In my current proposal, it is easy to specify an arbitrary number of
enable/status pairs located in any order and spread across different
parts of the register space.  Even register indices (0,2,4,...) are
enable registers, and odd register indices are status registers.

If I'm interpreting your post correctly, you don't agree that we need
this level of flexibility.  But looking over the register listings,
here are the cases we need to cover:


6828,6318: 4x mask(exthi,extlo,hi,lo),status(exthi,extlo,hi,lo)

TP0ExtIrqMaskHi
TP0ExtIrqMaskLo
TP0IrqMaskHi
TP0IrqMaskLo
TP0ExtIrqStatusHi
TP0ExtIrqStatusLo
TP0IrqStatusHi
TP0IrqStatusLo

TP1ExtIrqMaskHi
TP1ExtIrqMaskLo
...


6816,6362,6328: 2x extmask,mask,extstatus,status

ExtraChipIrqMask
ChipIrqMask
ExtraChipIrqStatus
ChipIrqStatus
ExtraChipIrqMask1 [1=TP1]
ChipIrqMask1
ExtraChipIrqStatus1
ChipIrqStatus1


6368: similar to above, but with yet another naming convention:

IRQMASK_MIPS0_Hi
IRQMASK_MIPS0_Lo
IRQSTATUS_MIPS0_Hi
IRQSTATUS_MIPS0_Lo
IRQMASK_MIPS1_Hi
IRQMASK_MIPS1_Lo
IRQSTATUS_MIPS1_Hi
IRQSTATUS_MIPS1_Lo



6838,3384: interleaved "mystery meat" mask/status (same IRQ source
names, with the output of each bcm7120-l2 routed to several different
processors/threads):

PeriphIRQMASK0
PeriphIRQSTATUS0
PeriphIRQMASK1 <- mine, if running on Zephyr
PeriphIRQSTATUS1 <- mine, if running on Zephyr
PeriphIRQMASK2
PeriphIRQSTATUS2
PeriphIRQMASK3 <- mine, if running on Viper
PeriphIRQSTATUS3 <- mine, if running on Viper

But wait, there's more!  There wasn't enough space in this block for
>32 IRQ bits, so the upper bits spilled over into a separate
"INT_EXT_PER" block that lives elsewhere in the register space:

PeriphIRQMASK0_2
PeriphIRQSTATUS0_2
PeriphIRQMASK1_2 <- mine, if running on Zephyr
PeriphIRQSTATUS1_2 <- mine, if running on Zephyr
PeriphIRQMASK2_2
PeriphIRQSTATUS2_2
PeriphIRQMASK3_2 <- mine, if running on Viper
PeriphIRQSTATUS3_2 <- mine, if running on Viper

The "INT_PER" and "INT_EXT_PER" outputs are ORed into the same MIPS
IRQ lines, so we need to treat them as two sides of a single
controller.  AFAICT, unlike a shared device IRQ, there is no way to
share a MIPS IRQ line between two controller instances.

Additionally, we have a few other random MASK/STATUS pairs scattered
around (ZMIPS, CMIPS blocks), and then we also have DQM IRQs with
multiple mask registers + single status register:

CMIPS_NOT_EMPTY_IRQ_MSK
CMIPS1_NOT_EMPTY_IRQ_MSK <- mine, if running on Viper
ZMIPS_NOT_EMPTY_IRQ_MSK <- mine, if running on Zephyr
PMC_NOT_EMPTY_IRQ_MSK
DFAP_NOT_EMPTY_IRQ_MSK
NOT_EMPTY_IRQ_STS

I suppose another alternative is to ioremap() a range large enough to
cover enable + status, and then specify the offset of each one in
another property.  This does run the risk of overlapping mappings.


> This would avoid having to specify a lot of regs (let's assume we also
> add support for affinity)

I concede that I have no idea how affinity should be handled here.
AFAICT it is completely off limits on BCM3384 because we just don't
have enough L2 outputs to offer proper masking for all of the
threads/CPUs in the system.

Perhaps we could write a simple, SMP-capable driver for the
saner/newer SoCs, and use the flexible-but-non-SMP version for the
complicated ones.


> and cause a lot of io(re)map calls

Is the ioremap() call really that big of a deal?

On MIPS it's basically computing CKSEG1ADDR(phys_addr).  On ARM, the
top level (with 64 to 128+ IRQs) goes through the GIC.  On both,
ioremap() is a one-time cost at startup.
--
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  

Re: [PATCH v9 05/10] sched: make scale_rt invariant with frequency

[Wanpeng Li]

Hi Vincent,
On 11/25/14, 9:52 PM, Vincent Guittot wrote:

On 25 November 2014 at 03:24, Wanpeng Li  wrote:

Hi Vincent,
On 11/4/14, 12:54 AM, Vincent Guittot wrote:

The average running time of RT tasks is used to estimate the remaining
compute
capacity for CFS tasks. This remaining capacity is the original capacity
scaled
down by a factor (aka scale_rt_capacity). This estimation of available
capacity
must also be invariant with frequency scaling.

A frequency scaling factor is applied on the running time of the RT tasks
for
computing scale_rt_capacity.

In sched_rt_avg_update, we scale the RT execution time like below:
rq->rt_avg += rt_delta * arch_scale_freq_capacity() >>
SCHED_CAPACITY_SHIFT

Then, scale_rt_capacity can be summarized by:
scale_rt_capacity = SCHED_CAPACITY_SCALE -
 ((rq->rt_avg << SCHED_CAPACITY_SHIFT) / period)


The 'period' aka 'total' in the scale_rt_capacity(), why it is
sched_avg_period() + delta instead of sched_avg_period()?

The default value of sched_avg_period is 1sec which is "long" so we
take into account the time consumed by RT tasks in the ongoing period
.


Do you mean 'sched_avg_period() + delta' should be replaced by 'delta' 
since sched_avg_period() is "long"?


Regards,
Wanpeng Li




Regards,
Wanpeng Li



We can optimize by removing right and left shift in the computation of
rq->rt_avg
and scale_rt_capacity

The call to arch_scale_frequency_capacity in the rt scheduling path might
be
a concern for RT folks because I'm not sure whether we can rely on
arch_scale_freq_capacity to be short and efficient ?

Signed-off-by: Vincent Guittot 
---
   kernel/sched/fair.c  | 17 +
   kernel/sched/sched.h |  4 +++-
   2 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index a5039da..b37c27b 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -5785,7 +5785,7 @@ unsigned long __weak arch_scale_cpu_capacity(struct
sched_domain *sd, int cpu)
   static unsigned long scale_rt_capacity(int cpu)
   {
 struct rq *rq = cpu_rq(cpu);
-   u64 total, available, age_stamp, avg;
+   u64 total, used, age_stamp, avg;
 s64 delta;
 /*
@@ -5801,19 +5801,12 @@ static unsigned long scale_rt_capacity(int cpu)
 total = sched_avg_period() + delta;
   - if (unlikely(total < avg)) {
-   /* Ensures that capacity won't end up being negative */
-   available = 0;
-   } else {
-   available = total - avg;
-   }
+   used = div_u64(avg, total);
   - if (unlikely((s64)total < SCHED_CAPACITY_SCALE))
-   total = SCHED_CAPACITY_SCALE;
+   if (likely(used < SCHED_CAPACITY_SCALE))
+   return SCHED_CAPACITY_SCALE - used;
   - total >>= SCHED_CAPACITY_SHIFT;
-
-   return div_u64(available, total);
+   return 1;
   }
 static void update_cpu_capacity(struct sched_domain *sd, int cpu)
diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h
index c34bd11..fc5b152 100644
--- a/kernel/sched/sched.h
+++ b/kernel/sched/sched.h
@@ -1312,9 +1312,11 @@ static inline int hrtick_enabled(struct rq *rq)
 #ifdef CONFIG_SMP
   extern void sched_avg_update(struct rq *rq);
+extern unsigned long arch_scale_freq_capacity(struct sched_domain *sd,
int cpu);
+
   static inline void sched_rt_avg_update(struct rq *rq, u64 rt_delta)
   {
-   rq->rt_avg += rt_delta;
+   rq->rt_avg += rt_delta * arch_scale_freq_capacity(NULL,
cpu_of(rq));
 sched_avg_update(rq);
   }
   #else




--
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 6/7] ARM: mvebu: add PHY support to the dts for the USB controllers on Armada 375

[Jason Cooper]

On Wed, Nov 26, 2014 at 10:43:08AM +0530, Kishon Vijay Abraham I wrote:
> Hi,
> 
> On Wednesday 26 November 2014 09:29 AM, Jason Cooper wrote:
> > On Sat, Nov 22, 2014 at 10:20:43AM +0100, Gregory CLEMENT wrote:
> >> Hi Jason,
> >>
> >> On 22/11/2014 03:08, Jason Cooper wrote:
> >>> On Thu, Nov 13, 2014 at 12:47:48PM +0100, Gregory CLEMENT wrote:
>  Now that the USB cluster node has been added, use it as a PHY provider
>  for the USB controller linked to it: the first EHCI and the xHCI.
> 
>  Signed-off-by: Gregory CLEMENT 
> 
> Looks like I'm not cc'ed in v4 of this patch series :-(

I've bounced emails maybe three times in my life.  Thought it might work
here.  Did it?

thx,

Jason.
--
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] Bluetooth: automatically flushable packets aren't allowed on LE links

[Marcel Holtmann]

Hi Steven,

 I think Marcel was after just providing a clarifying code comment in
 both places - having two branches of an if-statement doing exactly the
 same thing looks a bit weird to me. To make thins completely clear I'd
 suggest adding a simple helper function that you can call from both
 places to get the needed flags, something like the following:
>>> 
>>> I am actually fine with just adding a comment explaining the complex if
>>> statement on why it is correct. It is just a helper for everybody to
>>> understand what and why it is done that way.
>> 
>> 
>> Is the comment I added sufficient, or should I add one for the other if
>> condition as well?  To me, the second condition is pretty straightforward:
>> if the caller requested it and the hardware supports it, use NO_FLUSH.  The
>> relationship between FLUSH/NO_FLUSH and low-energy is much less clear and
>> more justifies a comment, in my opinion.
> 
> Did a miss a reply to this?  How would you like the next iteration of
> the patch to look?

can you just send a v4 and I have a look at it. I thing it is best to keep the 
original patch with the rather complicated if statement you had. And then add a 
comment in front of it, why it is that way and that it is correct this way.

Regards

Marcel

--
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/4] powernv: cpuidle: Redesign idle states management

[Preeti U Murthy]

Hi,

I ran hackbench to evaluate this patchset and found good improvements in
the results.

I modified hackbench to take in a 'loops' parameter along with
num_groups which ensures that the test runs long enough to observe and
debug issues. The idea was to find out how latency sensitive workloads
can get affected by modification in cpuidle heuristics since it is easy
to measure the impact on these workloads.

The experiment was conducted on a Power8 system with 1 socket and 6
cores on it.

The first experiment was carried out by pinning hackbench to the first
thread in each core while the rest of the smt threads were idle and
below are the results. This would ensure the core entered deep idle
states more often.

num_grps %improvement with patchset
33.6
6   10.6
12   5.0
24   5.0

The second experiment was carried out by allowing hackbench to run on
the smt threads of two cores and % improvement with the patchset was in
range of 4-7%.

I ran the experiments on the vanilla kernel. This means the performance
improvements is primarily due to avoiding having to do a timebase sync
by every thread in the core. The power numbers have very little
variation between the runs with and without the patchset.

Thanks

Regards
Preeti U Murthy

On 11/25/2014 04:47 PM, Shreyas B. Prabhu wrote:
> Deep idle states like sleep and winkle are per core idle states. A core
> enters these states only when all the threads enter either the particular
> idle state or a deeper one. There are tasks like fastsleep hardware bug
> workaround and hypervisor core state save which have to be done only by
> the last thread of the core entering deep idle state and similarly tasks
> like timebase resync, hypervisor core register restore that have to be
> done only by the first thread waking up from these states. 
> 
> The current idle state management does not have a way to distinguish the
> first/last thread of the core waking/entering idle states. Tasks like
> timebase resync are done for all the threads. This is not only is suboptimal,
> but can cause functionality issues when subcores are involved.
> 
> Winkle is deeper idle state compared to fastsleep. In this state the power
> supply to the chiplet, i.e core, private L2 and private L3 is turned off.
> This results in a total hypervisor state loss. This patch set adds support
> for winkle and provides a way to track the idle states of the threads of the
> core and use it for idle state management of idle states sleep and winkle.
> 
> 
> Changes in v2:
> --
> -Using PNV_THREAD_NAP/SLEEP defines while calling power7_powersave_common
> -Comment changes based on review
> -Rebased on top of 3.18-rc6
> 
> 
> Cc: Benjamin Herrenschmidt 
> Cc: Paul Mackerras 
> Cc: Michael Ellerman 
> Cc: Rafael J. Wysocki 
> Cc: linux...@vger.kernel.org
> Cc: linuxppc-...@lists.ozlabs.org
> Cc: Vaidyanathan Srinivasan 
> Cc: Preeti U Murthy 
> 
> Paul Mackerras (1):
>   powerpc: powernv: Switch off MMU before entering nap/sleep/rvwinkle
> mode
> 
> Preeti U. Murthy (1):
>   powerpc/powernv: Enable Offline CPUs to enter deep idle states
> 
> Shreyas B. Prabhu (2):
>   powernv: cpuidle: Redesign idle states management
>   powernv: powerpc: Add winkle support for offline cpus
> 
>  arch/powerpc/include/asm/cpuidle.h |  14 ++
>  arch/powerpc/include/asm/opal.h|  13 +
>  arch/powerpc/include/asm/paca.h|   6 +
>  arch/powerpc/include/asm/ppc-opcode.h  |   2 +
>  arch/powerpc/include/asm/processor.h   |   1 +
>  arch/powerpc/include/asm/reg.h |   4 +
>  arch/powerpc/kernel/asm-offsets.c  |   6 +
>  arch/powerpc/kernel/cpu_setup_power.S  |   4 +
>  arch/powerpc/kernel/exceptions-64s.S   |  30 ++-
>  arch/powerpc/kernel/idle_power7.S  | 332 
> +
>  arch/powerpc/platforms/powernv/opal-wrappers.S |  39 +++
>  arch/powerpc/platforms/powernv/powernv.h   |   2 +
>  arch/powerpc/platforms/powernv/setup.c | 160 
>  arch/powerpc/platforms/powernv/smp.c   |  10 +-
>  arch/powerpc/platforms/powernv/subcore.c   |  34 +++
>  arch/powerpc/platforms/powernv/subcore.h   |   1 +
>  drivers/cpuidle/cpuidle-powernv.c  |  10 +-
>  17 files changed, 608 insertions(+), 60 deletions(-)
>  create mode 100644 arch/powerpc/include/asm/cpuidle.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: bluetooth related firmware loader spew on resume.

[Marcel Holtmann]

Hi Takashi,

>> Since the addition of 10d4c6736ea "Bluetooth: btusb: Add Broadcom patch
>> RAM support", I (and a number of other people[*]) have been seeing
>> this trace on resume from suspend.
>> 
>> WARNING: CPU: 1 PID: 8565 at drivers/base/firmware_class.c:1127 
>> _request_firmware+0x4c1/0x7c0()
>> CPU: 1 PID: 8565 Comm: kworker/u17:0 Not tainted 3.17.2-200.fc20.x86_64 #1
>> Hardware name: LENOVO 2356JK8/2356JK8, BIOS G7ET94WW (2.54 ) 04/30/2013
>> Workqueue: hci0 hci_power_on [bluetooth]
>>  f52a564b 8800a8c63be8 817271cc
>>  8800a8c63c20 81094ced 8800a8c63d10
>> 8801365ddf00 8801387b4b00 8800a8c63d08 fff5
>> Call Trace:
>> [] dump_stack+0x45/0x56
>> [] warn_slowpath_common+0x7d/0xa0
>> [] warn_slowpath_null+0x1a/0x20
>> [] _request_firmware+0x4c1/0x7c0
>> [] ? snprintf+0x49/0x70
>> [] request_firmware+0x31/0x50
>> [] btusb_setup_bcm_patchram+0x83/0x550 [btusb]
>> [] ? rpm_idle+0xd6/0x2b0
>> [] hci_dev_do_open+0xe1/0xa60 [bluetooth]
>> ACPI: \_SB_.PCI0.LPC_.EC__.BAT1: docking
>> Restarting tasks ... 
>> [] ? ttwu_do_activate.constprop.90+0x5d/0x70
>> [] hci_power_on+0x40/0x1e0 [bluetooth]
>> [] ? lock_timer_base.isra.34+0x2b/0x50
>> [] process_one_work+0x149/0x3d0
>> [] worker_thread+0x11b/0x490
>> [] ? rescuer_thread+0x2e0/0x2e0
>> [] kthread+0xd8/0xf0
>> [] ? kthread_create_on_node+0x190/0x190
>> [] ret_from_fork+0x7c/0xb0
>> [] ? kthread_create_on_node+0x190/0x190
>> ---[ end trace 75a0e9c7f33ebb4c ]---
>> bluetooth hci0: firmware: brcm/BCM20702A0-0a5c-21e6.hcd will not be loaded
>> Bluetooth: hci0: BCM: patch brcm/BCM20702A0-0a5c-21e6.hcd not found
>> 
>> 
>> At first I thought it was just over-reaction to the file being missing, but
>> looking at the WARN_ON, it appears that we're trying to invoke the firmware
>> loader before userspace is back up ?
>> 
>> In this (and probably other related) kernel, CONFIG_FW_LOADER_USER_HELPER is 
>> unset,
>> in case that matters at all.
> 
> If it's the case where no matching firmware file is present, the patch
> below might help.  It's only compile-tested.
> 
> 
> Takashi
> 
> -- 8< --
> From: Takashi Iwai 
> Subject: [PATCH] btusb: Give up firmware loading once when failed
> 
> Otherwise it may trigger request_firmware() for the non-existing file
> in the resume path, resulting in a warning.  For the success paths,
> calling request_firmware() is fine, as it's cached properly at
> suspend.  The problem is only for the error paths.
> 
> Signed-off-by: Takashi Iwai 
> ---
> drivers/bluetooth/btusb.c | 2 ++
> 1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/bluetooth/btusb.c b/drivers/bluetooth/btusb.c
> index edfc17bfcd44..62d8e23fd3cb 100644
> --- a/drivers/bluetooth/btusb.c
> +++ b/drivers/bluetooth/btusb.c
> @@ -1569,6 +1569,7 @@ static int btusb_setup_intel(struct hci_dev *hdev)
>   if (!fw) {
>   kfree_skb(skb);
>   btusb_check_bdaddr_intel(hdev);
> + hdev->setup = NULL;
>   return 0;
>   }
>   fw_ptr = fw->data;
> @@ -1756,6 +1757,7 @@ static int btusb_setup_bcm_patchram(struct hci_dev 
> *hdev)
>   ret = request_firmware(, fw_name, >dev);
>   if (ret < 0) {
>   BT_INFO("%s: BCM: patch %s not found", hdev->name, fw_name);
> + hdev->setup = NULL;
>   return 0;
>   }

the hdev->setup callback is only called once for each new device found. This 
means that setting it back to NULL from the its own handler is not making any 
difference.

Also the problem is that hdev->setup is really there to load firmware. Devices 
might work without the firmware, but then they run off an old ROM firmware 
which is not a good idea in most cases. So we can not just close our eyes and 
hope for the best. The firmware should really be loaded.

I think the problem is that the devices physically disappear from the USB bus 
during suspend and will show up as a newly attached device after resume. So we 
have the cold plug case here. And there we need to firmware. Plain and simple. 
As stated above hdev->setup is only after run once. The only way to run it a 
second time is by unplugging and replugging the device. A BIOS that takes the 
power of the Bluetooth USB device is essentially simulating this behavior.

We are seeing a hci_power_on call since that is triggered exactly once when the 
device is plugged in. If we wanted to be super smart, then we could delay that 
initial call until the first userspace opens any Bluetooth socket. In theory 
that would work, but could be also way to complicated to realized. However it 
would mean the initial firmware loading and setup of the device is delayed 
until bluetoothd has been started. For bluetoothd this will be not a problem 
since it can handle hotplug of Bluetooth controllers, but for all other command 
line tools it might be a real problem. 

Regards

Marcel

--
To unsubscribe from this list: send the line "unsubscribe 

Re: [PATCH v4 6/7] ARM: mvebu: add PHY support to the dts for the USB controllers on Armada 375

[Kishon Vijay Abraham I]

Hi,

On Wednesday 26 November 2014 09:29 AM, Jason Cooper wrote:
> On Sat, Nov 22, 2014 at 10:20:43AM +0100, Gregory CLEMENT wrote:
>> Hi Jason,
>>
>> On 22/11/2014 03:08, Jason Cooper wrote:
>>> On Thu, Nov 13, 2014 at 12:47:48PM +0100, Gregory CLEMENT wrote:
 Now that the USB cluster node has been added, use it as a PHY provider
 for the USB controller linked to it: the first EHCI and the xHCI.

 Signed-off-by: Gregory CLEMENT 

Looks like I'm not cc'ed in v4 of this patch series :-(

-Kishon
 ---
  arch/arm/boot/dts/armada-375.dtsi | 5 +
  1 file changed, 5 insertions(+)

 diff --git a/arch/arm/boot/dts/armada-375.dtsi 
 b/arch/arm/boot/dts/armada-375.dtsi
 index 8f45cf5d2a50..f344ec420c95 100644
 --- a/arch/arm/boot/dts/armada-375.dtsi
 +++ b/arch/arm/boot/dts/armada-375.dtsi
 @@ -14,6 +14,7 @@
  #include "skeleton.dtsi"
  #include 
  #include 
 +#include 
>>>
>>> Odd.  The previous patch in this series simply adds a line to phy.h,
>>> however, I get the following error during 'make dtbs':
>>>
>>> 
>>>   DTC arch/arm/boot/dts/armada-375-db.dtb
>>> In file included from 
>>> arch/arm/boot/dts/armada-375-db.dts:17:0:arch/arm/boot/dts/armada-375.dtsi:17:33:
>>> fatal error: dt-bindings/phy/phy.h: No such file or directory
>>>  #include 
>>>  ^
>>> compilation terminated.
>>> scripts/Makefile.lib:282: recipe for target 'arch/arm/boot/dts/armada-37 
>>> 5-db.dtb' failed
>>> 
>>>
>>> mvebu/dt is based on v3.18-rc1.  Is there a missing dependency
>>> somewhere?  Perhaps we should let Kishon take the whole series and
>>> handle the (hopefully trivial) merge conflict?
>>
>> Actually Kishon asked me to use the dt-bindings/phy/phy.h file which
>> was introduced by the patch "phy: Add PHY header file for DT x Driver
>> defines". So indeed I had to have a dependency on the phy_dt_header
>> branch (which is based on v3.18-rc4 and have only this single commit).
>> The git tree is located at
>> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git
>>
>>
>> Maybe we could add this branch in mvebu as a dependency as it is done
>> on arm-soc. I suggest this because I would prefer that we continue to
>> be the only ones to merge the device tree files in order to reduce the
>> merge conflict.
> 
> Ok, I've applied patches 5 and 6 to mvebu/dt-usb_phy with a dependency
> on tags/phy-dt-header.
> 
> Patches 1-4:
> 
> Acked-by: Jason Cooper 
> 
> thx,
> 
> Jason.
> 
--
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: frequent lockups in 3.18rc4

[Dave Jones]

On Tue, Nov 25, 2014 at 09:09:45PM -0800, Linus Torvalds wrote:
 > On Nov 25, 2014 8:39 PM, "Jürgen Groß"  wrote:
 > >
 > > I COULD trigger it with 3.17. Took much longer, but I've seen it once.
 > > And from Xen hypervisor data it was clear it was the same bug (cpu
 > > spinning in pmd_lock()).
 > 
 > I'm still hoping you can give a back trace. I'd like to know what access it
 > is that can trigger this, and preferably what the call chain to it was...
 > 
 > I do believe it happened in 3.17, I just want to understand the but more -
 > not just apply the fix..
 > 
 > Most of Dave's lockup back traces did not have the whole page fault in
 > them, so while Dave has seen this too, there might be different symptoms...

Before giving 3.17 a multi-day workout, I'll try rc6 with Jürgen's patch
to see if that makes any difference at all for me.

Dave

--
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: [V5 7/7] selftests, powerpc: Add test case for TM related ptrace interface

[Anshuman Khandual]

On 11/25/2014 10:36 PM, Shuah Khan wrote:
> On 11/25/2014 01:05 AM, Anshuman Khandual wrote:
>> > This patch adds one more test case called 'tm-ptrace' targeting TM
>> > related ptrace interface. This test creates one child process to
>> > run some basic TM transactions and the parent process attaches the
>> > child to do some ptrace probing using the recently added regset
>> > interfaces. The parent process then compares the received values
>> > against the expected values to verify whether it has passed the
>> > given test or not.
>> > 
>> > Signed-off-by: Anshuman Khandual 
>> > ---
>> >  tools/testing/selftests/powerpc/tm/Makefile|   2 +-
>> >  tools/testing/selftests/powerpc/tm/tm-ptrace.c | 542 
>> > +
>> >  2 files changed, 543 insertions(+), 1 deletion(-)
>> >  create mode 100644 tools/testing/selftests/powerpc/tm/tm-ptrace.c
>> > 
>> > diff --git a/tools/testing/selftests/powerpc/tm/Makefile 
>> > b/tools/testing/selftests/powerpc/tm/Makefile
>> > index 2cede23..71d400a 100644
>> > --- a/tools/testing/selftests/powerpc/tm/Makefile
>> > +++ b/tools/testing/selftests/powerpc/tm/Makefile
>> > @@ -1,4 +1,4 @@
>> > -PROGS := tm-resched-dscr
>> > +PROGS := tm-resched-dscr tm-ptrace
>> >  
> Could you please add .gitignore for the binaries in this directory
> to avoid git status including the binaries it in its output.

Sure, will add one.

--
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] ath3k: Add support of MCI 13d3:3408 bt device

[Marcel Holtmann]

Hi Dmitry,

> Add support for bluetooth MCI WB335 (AR9565) Wi-Fi+bt module.
> This bluetooth module requires loading patch and sysconfig by ath3k driver.
> 
> T:  Bus=01 Lev=02 Prnt=03 Port=00 Cnt=01 Dev#= 20 Spd=12   MxCh= 0
> D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
> P:  Vendor=13d3 ProdID=3408 Rev= 0.02
> C:* #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
> A:  FirstIf#= 0 IfCount= 2 Cls=e0(wlcon) Sub=01 Prot=01
> I:* If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=81(I) Atr=03(Int.) MxPS=  16 Ivl=1ms
> E:  Ad=82(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
> I:* If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=83(I) Atr=01(Isoc) MxPS=   0 Ivl=1ms
> E:  Ad=03(O) Atr=01(Isoc) MxPS=   0 Ivl=1ms
> I:  If#= 1 Alt= 1 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=83(I) Atr=01(Isoc) MxPS=   9 Ivl=1ms
> E:  Ad=03(O) Atr=01(Isoc) MxPS=   9 Ivl=1ms
> I:  If#= 1 Alt= 2 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=83(I) Atr=01(Isoc) MxPS=  17 Ivl=1ms
> E:  Ad=03(O) Atr=01(Isoc) MxPS=  17 Ivl=1ms
> I:  If#= 1 Alt= 3 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=83(I) Atr=01(Isoc) MxPS=  25 Ivl=1ms
> E:  Ad=03(O) Atr=01(Isoc) MxPS=  25 Ivl=1ms
> I:  If#= 1 Alt= 4 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=83(I) Atr=01(Isoc) MxPS=  33 Ivl=1ms
> E:  Ad=03(O) Atr=01(Isoc) MxPS=  33 Ivl=1ms
> I:  If#= 1 Alt= 5 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
> E:  Ad=83(I) Atr=01(Isoc) MxPS=  49 Ivl=1ms
> E:  Ad=03(O) Atr=01(Isoc) MxPS=  49 Ivl=1ms
> 
> 
> CC: sta...@vger.kernel.org
> Signed-off-by: Dmitry Tunin 

so you really need to make sure to send only one version. I now have two 
patches labeled as v6 and I have no idea which one is recent and which one I am 
suppose to apply.

I tried applying this one, but it failed. Patches need to be based against 
bluetooth-next tree.

Applying: ath3k: Add support of MCI 13d3:3408 bt device
error: patch failed: drivers/bluetooth/ath3k.c:105
error: drivers/bluetooth/ath3k.c: patch does not apply
error: patch failed: drivers/bluetooth/btusb.c:182
error: drivers/bluetooth/btusb.c: patch does not apply
Patch failed at 0001 ath3k: Add support of MCI 13d3:3408 bt device

Regards

Marcel

--
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 3.17 100/141] x86, microcode: Fix accessing dis_ucode_ldr on 32-bit

[Boris Ostrovsky]

On 11/25/2014 05:18 PM, Borislav Petkov wrote:

Adding x86 people.

On Tue, Nov 25, 2014 at 04:59:34PM -0500, Boris Ostrovsky wrote:

This should be cpuid(0x1, , , , ). Otherwise we are not
getting bits that the hypervisor wants the guest to see (on Xen cpuid()
turns into hypercall, on baremetal it's native).

With that change it works and

Tested-by: Boris Ostrovsky 


Sigh... I take this back. It breaks 32-bit baremetal. I haven't looked 
any further but it seems to be dying very early. I suspect cpuid pv_op 
is not set up yet. If that's true, perhaps you could check whether it is 
valid in x86_guest()?


I won't be able to do anything tomorrow morning, the best I can hope for 
is evening.



-boris




Thanks for testing.


(May be worth adding a comment as to what is_guest() is checking for since
31 is a magic number).

See below.


BTW, the crash had nothing to do with accessing dis_ucode_ldr, we are
crashing much later, in load_ucode_intel_ap(), trying to access
*initrd_start_p. And the reason we didn't crash before was because compiler
optimized out whole load_ucode_ap() since check_loader_disabled_ap() was
always true.

Right, and my fix actually uncovered the original issue :-\

Ok, here's a v2 which adds the check to the late loader too, for
completeness. I'll write a proper commit message tomorrow.

---
diff --git a/arch/x86/include/asm/microcode.h b/arch/x86/include/asm/microcode.h
index 64dc362506b7..654907db5f09 100644
--- a/arch/x86/include/asm/microcode.h
+++ b/arch/x86/include/asm/microcode.h
@@ -87,4 +87,9 @@ static inline int __init save_microcode_in_initrd(void)
  }
  #endif
  
+/* Check whether we're running as a guest on a hypervisor. */

+static inline bool x86_guest(void)
+{
+   return !!(cpuid_ecx(1) & BIT(31));
+}
  #endif /* _ASM_X86_MICROCODE_H */
diff --git a/arch/x86/kernel/cpu/microcode/core.c 
b/arch/x86/kernel/cpu/microcode/core.c
index 2ce9051174e6..0b6db2a97f61 100644
--- a/arch/x86/kernel/cpu/microcode/core.c
+++ b/arch/x86/kernel/cpu/microcode/core.c
@@ -557,6 +557,9 @@ static int __init microcode_init(void)
struct cpuinfo_x86 *c = _data(0);
int error;
  
+	if (x86_guest())

+   return 0;
+
if (dis_ucode_ldr)
return 0;
  
diff --git a/arch/x86/kernel/cpu/microcode/core_early.c b/arch/x86/kernel/cpu/microcode/core_early.c

index 2c017f242a78..dfa93e74c370 100644
--- a/arch/x86/kernel/cpu/microcode/core_early.c
+++ b/arch/x86/kernel/cpu/microcode/core_early.c
@@ -98,6 +98,9 @@ void __init load_ucode_bsp(void)
  {
int vendor, x86;
  
+	if (x86_guest())

+   return;
+
if (check_loader_disabled_bsp())
return;
  
@@ -134,6 +137,9 @@ void load_ucode_ap(void)

  {
int vendor, x86;
  
+	if (x86_guest())

+   return;
+
if (check_loader_disabled_ap())
return;
  



--
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] block: fix regression where bio_integrity_process uses wrong bio_vec iterator

[Martin K. Petersen]

> "Darrick" == Darrick J Wong  writes:

Darrick> Therefore, teach bio_integrity_process() to use
Darrick> bio_for_each_segment() to iterate the bio_vecs, since the
Darrick> per-bio iterator tracks which bio_vecs are associated with that
Darrick> particular bio.  The integrity handling code is effectively
Darrick> part of the "driver" (it's not the bio owner), so it must use
Darrick> the correct iterator function.

Acked-by: Martin K. Petersen 

-- 
Martin K. Petersen  Oracle Linux Engineering
--
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] arm64: amd-seattle: Adding device tree for AMD Seattle platform

[suravee.suthikulpanit]

From: Suravee Suthikulpanit 

Initial revision of device tree for AMD Seattle Development platform.

Cc: Arnd Bergmann 
Cc: Marc Zyngier 
Cc: Mark Rutland 
Cc: Will Deacon 
Cc: Catalin Marinas 
Signed-off-by: Suravee Suthikulpanit 
Signed-off-by: Thomas Lendacky 
Signed-off-by: Joel Schopp 
---
V5 Changes:
  * Rebase to arm-soc for-next (per Olof)
  * Restructure the DTS/DTSI into board and SoC configurations (per Olof)
  * Add model property at the top level (per Olof)
  * Move pcie0 under smb and change smb's ranges property to empty since pcie
is not in the same range. (per Olof)
  * Change v2m0's ranges property (per Arnd)
  * Change timer interrupt type to level-trigger (per Marc)

 arch/arm64/Kconfig|   5 +
 arch/arm64/boot/dts/Makefile  |   1 +
 arch/arm64/boot/dts/amd/Makefile  |   5 +
 arch/arm64/boot/dts/amd/amd-overdrive.dts |  66 ++
 arch/arm64/boot/dts/amd/amd-seattle-clks.dtsi |  54 
 arch/arm64/boot/dts/amd/amd-seattle-soc.dtsi  | 172 ++
 6 files changed, 303 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9532f8d..ddc0196 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -142,6 +142,11 @@ source "kernel/Kconfig.freezer"
 
 menu "Platform selection"
 
+config ARCH_SEATTLE
+   bool "AMD Seattle SoC Family"
+   help
+ This enables support for AMD Seattle SOC Family
+
 config ARCH_THUNDER
bool "Cavium Inc. Thunder SoC Family"
help
diff --git a/arch/arm64/boot/dts/Makefile b/arch/arm64/boot/dts/Makefile
index e8efc8f..3b8d427 100644
--- a/arch/arm64/boot/dts/Makefile
+++ b/arch/arm64/boot/dts/Makefile
@@ -1,3 +1,4 @@
+dts-dirs += amd
 dts-dirs += apm
 dts-dirs += arm
 dts-dirs += cavium
diff --git a/arch/arm64/boot/dts/amd/Makefile b/arch/arm64/boot/dts/amd/Makefile
new file mode 100644
index 000..cfdf701
--- /dev/null
+++ b/arch/arm64/boot/dts/amd/Makefile
@@ -0,0 +1,5 @@
+dtb-$(CONFIG_ARCH_SEATTLE) += amd-overdrive.dtb
+
+always := $(dtb-y)
+subdir-y   := $(dts-dirs)
+clean-files:= *.dtb
diff --git a/arch/arm64/boot/dts/amd/amd-overdrive.dts 
b/arch/arm64/boot/dts/amd/amd-overdrive.dts
new file mode 100644
index 000..564a3f7
--- /dev/null
+++ b/arch/arm64/boot/dts/amd/amd-overdrive.dts
@@ -0,0 +1,66 @@
+/*
+ * DTS file for AMD Seattle Overdrive Development Board
+ *
+ * Copyright (C) 2014 Advanced Micro Devices, Inc.
+ */
+
+/dts-v1/;
+
+/include/ "amd-seattle-soc.dtsi"
+
+/ {
+   model = "AMD Seattle Development Board (Overdrive)";
+   compatible = "amd,seattle-overdrive", "amd,seattle";
+
+   chosen {
+   stdout-path = 
+   linux,pci-probe-only;
+   };
+};
+
+ {
+   status = "ok";
+};
+
+ {
+   status = "ok";
+};
+
+ {
+   status = "ok";
+};
+
+ {
+   status = "ok";
+};
+
+ {
+   status = "ok";
+};
+
+ {
+   status = "ok";
+};
+
+ {
+   status = "ok";
+   sdcard0: sdcard@0 {
+   compatible = "mmc-spi-slot";
+   reg = <0>;
+   spi-max-frequency = <2000>;
+   voltage-ranges = <3200 3400>;
+   gpios = < 7 0>;
+   interrupt-parent = <>;
+   interrupts = <7 3>;
+   pl022,hierarchy = <0>;
+   pl022,interface = <0>;
+   pl022,com-mode = <0x0>;
+   pl022,rx-level-trig = <0>;
+   pl022,tx-level-trig = <0>;
+   };
+};
+
+ {
+   arm,msi-base-spi = <64>;
+   arm,msi-num-spis = <256>;
+};
diff --git a/arch/arm64/boot/dts/amd/amd-seattle-clks.dtsi 
b/arch/arm64/boot/dts/amd/amd-seattle-clks.dtsi
new file mode 100644
index 000..f623c46
--- /dev/null
+++ b/arch/arm64/boot/dts/amd/amd-seattle-clks.dtsi
@@ -0,0 +1,54 @@
+/*
+ * DTS file for AMD Seattle Clocks
+ *
+ * Copyright (C) 2014 Advanced Micro Devices, Inc.
+ */
+
+   adl3clk_100mhz: clk100mhz_0 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <1>;
+   clock-output-names = "adl3clk_100mhz";
+   };
+
+   ccpclk_375mhz: clk375mhz {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <37500>;
+   clock-output-names = "ccpclk_375mhz";
+   };
+
+   sataclk_333mhz: clk333mhz {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <33300>;
+   clock-output-names = "sataclk_333mhz";
+   };
+
+   pcieclk_500mhz: clk500mhz_0 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <5>;
+   clock-output-names = "pcieclk_500mhz";
+   };
+
+   dmaclk_500mhz: clk500mhz_1 {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = 

[PATCH v9 6/6] arm64: add seccomp support

[AKASHI Takahiro]

secure_computing() is called first in syscall_trace_enter() so that
a system call will be aborted quickly without doing succeeding syscall
tracing if seccomp rules want to deny that system call.

On compat task, syscall numbers for system calls allowed in seccomp mode 1
are different from those on normal tasks, and so _NR_seccomp_xxx_32's need
to be redefined.

Signed-off-by: AKASHI Takahiro 
---
 arch/arm64/Kconfig   |   14 ++
 arch/arm64/include/asm/seccomp.h |   25 +
 arch/arm64/include/asm/unistd.h  |3 +++
 arch/arm64/kernel/ptrace.c   |5 +
 4 files changed, 47 insertions(+)
 create mode 100644 arch/arm64/include/asm/seccomp.h

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9532f8d..f495d3c 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -37,6 +37,7 @@ config ARM64
select HAVE_ARCH_AUDITSYSCALL
select HAVE_ARCH_JUMP_LABEL
select HAVE_ARCH_KGDB
+   select HAVE_ARCH_SECCOMP_FILTER
select HAVE_ARCH_TRACEHOOK
select HAVE_BPF_JIT
select HAVE_C_RECORDMCOUNT
@@ -345,6 +346,19 @@ config ARCH_HAS_CACHE_LINE_SIZE
 
 source "mm/Kconfig"
 
+config SECCOMP
+   bool "Enable seccomp to safely compute untrusted bytecode"
+   ---help---
+ This kernel feature is useful for number crunching applications
+ that may need to compute untrusted bytecode during their
+ execution. By using pipes or other transports made available to
+ the process as file descriptors supporting the read/write
+ syscalls, it's possible to isolate those applications in
+ their own address space using seccomp. Once seccomp is
+ enabled via prctl(PR_SET_SECCOMP), it cannot be disabled
+ and the task is only allowed to execute a few safe syscalls
+ defined by each seccomp mode.
+
 config XEN_DOM0
def_bool y
depends on XEN
diff --git a/arch/arm64/include/asm/seccomp.h b/arch/arm64/include/asm/seccomp.h
new file mode 100644
index 000..c76fac9
--- /dev/null
+++ b/arch/arm64/include/asm/seccomp.h
@@ -0,0 +1,25 @@
+/*
+ * arch/arm64/include/asm/seccomp.h
+ *
+ * Copyright (C) 2014 Linaro Limited
+ * Author: AKASHI Takahiro 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef _ASM_SECCOMP_H
+#define _ASM_SECCOMP_H
+
+#include 
+
+#ifdef CONFIG_COMPAT
+#define __NR_seccomp_read_32   __NR_compat_read
+#define __NR_seccomp_write_32  __NR_compat_write
+#define __NR_seccomp_exit_32   __NR_compat_exit
+#define __NR_seccomp_sigreturn_32  __NR_compat_rt_sigreturn
+#endif /* CONFIG_COMPAT */
+
+#include 
+
+#endif /* _ASM_SECCOMP_H */
diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h
index 6d2bf41..49c9aef 100644
--- a/arch/arm64/include/asm/unistd.h
+++ b/arch/arm64/include/asm/unistd.h
@@ -31,6 +31,9 @@
  * Compat syscall numbers used by the AArch64 kernel.
  */
 #define __NR_compat_restart_syscall0
+#define __NR_compat_exit   1
+#define __NR_compat_read   3
+#define __NR_compat_write  4
 #define __NR_compat_sigreturn  119
 #define __NR_compat_rt_sigreturn   173
 
diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 8b98781..d894eab 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -27,6 +27,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1149,6 +1150,10 @@ static void tracehook_report_syscall(struct pt_regs 
*regs,
 
 asmlinkage int syscall_trace_enter(struct pt_regs *regs)
 {
+   /* Do the secure computing check first; failures should be fast. */
+   if (secure_computing() == -1)
+   return -1;
+
if (test_thread_flag(TIF_SYSCALL_TRACE))
tracehook_report_syscall(regs, PTRACE_SYSCALL_ENTER);
 
-- 
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/

[PATCH v9 5/6] arm64: add SIGSYS siginfo for compat task

[AKASHI Takahiro]

SIGSYS is primarily used in secure computing to notify tracer of syscall
events. This patch allows signal handler on compat task to get correct
information with SA_SIGINFO specified when this signal is delivered.

Reviewed-by: Kees Cook 
Signed-off-by: AKASHI Takahiro 
---
 arch/arm64/include/asm/compat.h |7 +++
 arch/arm64/kernel/signal32.c|6 ++
 2 files changed, 13 insertions(+)

diff --git a/arch/arm64/include/asm/compat.h b/arch/arm64/include/asm/compat.h
index 56de5aa..3fb053f 100644
--- a/arch/arm64/include/asm/compat.h
+++ b/arch/arm64/include/asm/compat.h
@@ -205,6 +205,13 @@ typedef struct compat_siginfo {
compat_long_t _band;/* POLL_IN, POLL_OUT, POLL_MSG 
*/
int _fd;
} _sigpoll;
+
+   /* SIGSYS */
+   struct {
+   compat_uptr_t _call_addr; /* calling user insn */
+   int _syscall;   /* triggering system call number */
+   compat_uint_t _arch;/* AUDIT_ARCH_* of syscall */
+   } _sigsys;
} _sifields;
 } compat_siginfo_t;
 
diff --git a/arch/arm64/kernel/signal32.c b/arch/arm64/kernel/signal32.c
index 1b9ad02..5a1ba6e 100644
--- a/arch/arm64/kernel/signal32.c
+++ b/arch/arm64/kernel/signal32.c
@@ -186,6 +186,12 @@ int copy_siginfo_to_user32(compat_siginfo_t __user *to, 
const siginfo_t *from)
err |= __put_user(from->si_uid, >si_uid);
err |= __put_user((compat_uptr_t)(unsigned long)from->si_ptr, 
>si_ptr);
break;
+   case __SI_SYS:
+   err |= __put_user((compat_uptr_t)(unsigned long)
+   from->si_call_addr, >si_call_addr);
+   err |= __put_user(from->si_syscall, >si_syscall);
+   err |= __put_user(from->si_arch, >si_arch);
+   break;
default: /* this is just in case for now ... */
err |= __put_user(from->si_pid, >si_pid);
err |= __put_user(from->si_uid, >si_uid);
-- 
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/

[PATCH v9 3/6] asm-generic: add generic seccomp.h for secure computing mode 1

[AKASHI Takahiro]

Those values (__NR_seccomp_*) are used solely in secure_computing()
to identify mode 1 system calls. If compat system calls have different
syscall numbers, asm/seccomp.h may override them.

Acked-by: Arnd Bergmann 
Reviewed-by: Kees Cook 
Signed-off-by: AKASHI Takahiro 
---
 include/asm-generic/seccomp.h |   30 ++
 1 file changed, 30 insertions(+)
 create mode 100644 include/asm-generic/seccomp.h

diff --git a/include/asm-generic/seccomp.h b/include/asm-generic/seccomp.h
new file mode 100644
index 000..9fa1f65
--- /dev/null
+++ b/include/asm-generic/seccomp.h
@@ -0,0 +1,30 @@
+/*
+ * include/asm-generic/seccomp.h
+ *
+ * Copyright (C) 2014 Linaro Limited
+ * Author: AKASHI Takahiro 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#ifndef _ASM_GENERIC_SECCOMP_H
+#define _ASM_GENERIC_SECCOMP_H
+
+#include 
+
+#if defined(CONFIG_COMPAT) && !defined(__NR_seccomp_read_32)
+#define __NR_seccomp_read_32   __NR_read
+#define __NR_seccomp_write_32  __NR_write
+#define __NR_seccomp_exit_32   __NR_exit
+#define __NR_seccomp_sigreturn_32  __NR_rt_sigreturn
+#endif /* CONFIG_COMPAT && ! already defined */
+
+#define __NR_seccomp_read  __NR_read
+#define __NR_seccomp_write __NR_write
+#define __NR_seccomp_exit  __NR_exit
+#ifndef __NR_seccomp_sigreturn
+#define __NR_seccomp_sigreturn __NR_rt_sigreturn
+#endif
+
+#endif /* _ASM_GENERIC_SECCOMP_H */
-- 
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/

[PATCH v9 4/6] arm64: add seccomp syscall for compat task

[AKASHI Takahiro]

This patch allows compat task to issue seccomp() system call.

Reviewed-by: Kees Cook 
Signed-off-by: AKASHI Takahiro 
---
 arch/arm64/include/asm/unistd32.h |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/unistd32.h 
b/arch/arm64/include/asm/unistd32.h
index 9dfdac4..8893ceb 100644
--- a/arch/arm64/include/asm/unistd32.h
+++ b/arch/arm64/include/asm/unistd32.h
@@ -787,7 +787,8 @@ __SYSCALL(__NR_sched_setattr, sys_sched_setattr)
 __SYSCALL(__NR_sched_getattr, sys_sched_getattr)
 #define __NR_renameat2 382
 __SYSCALL(__NR_renameat2, sys_renameat2)
-   /* 383 for seccomp */
+#define __NR_seccomp 383
+__SYSCALL(__NR_seccomp, sys_seccomp)
 #define __NR_getrandom 384
 __SYSCALL(__NR_getrandom, sys_getrandom)
 #define __NR_memfd_create 385
-- 
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/

[PATCH v9 2/6] arm64: ptrace: allow tracer to skip a system call

[AKASHI Takahiro]

If tracer modifies a syscall number to -1, this traced system call should
be skipped with a return value specified in x0.
This patch implements this semantics.

Please note:
* syscall entry tracing and syscall exit tracing (ftrace tracepoint and
  audit) are always executed, if enabled, even when skipping a system call
  (that is, -1).
  In this way, we can avoid a potential bug where audit_syscall_entry()
  might be called without audit_syscall_exit() at the previous system call
  being called, that would cause OOPs in audit_syscall_entry().

Signed-off-by: AKASHI Takahiro 
---
 arch/arm64/kernel/entry.S |   10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 726b910..946ec52 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -161,6 +161,7 @@
  */
 sc_nr  .reqx25 // number of system calls
 scno   .reqx26 // syscall number
+scno_w .reqw26 // syscall number (lower 32 bits)
 stbl   .reqx27 // syscall table pointer
 tsk.reqx28 // current thread_info
 
@@ -668,8 +669,14 @@ ENDPROC(el0_svc)
 * switches, and waiting for our parent to respond.
 */
 __sys_trace:
-   mov x0, sp
+   cmp scno_w, #-1 // set default errno for
+   b.ne1f  // user-issued syscall(-1)
+   mov x0, #-ENOSYS
+   str x0, [sp]
+1: mov x0, sp
bl  syscall_trace_enter
+   cmp w0, #-1 // skip the syscall?
+   b.eq__sys_trace_return_skipped
adr lr, __sys_trace_return  // return address
uxtwscno, w0// syscall number (possibly new)
mov x1, sp  // pointer to regs
@@ -684,6 +691,7 @@ __sys_trace:
 
 __sys_trace_return:
str x0, [sp]// save returned x0
+__sys_trace_return_skipped:
mov x0, sp
bl  syscall_trace_exit
b   ret_to_user
-- 
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/

[PATCH v9 0/6] arm64: add seccomp support

[AKASHI Takahiro]

This patch series enables secure computing (system call filtering) on arm64,
and contains related enhancements and bug fixes.

  NOTE: This versions contain a workaround against possible BUG_ON() failure
  at audit_syscall_exit(), but doesn't contain an extra optimization, as I
  submitted for arm, of excluding syscall enter/exit tracing against invalid
  system calls due to an issue that I reported in:
   
http://lists.infradead.org/pipermail/linux-arm-kernel/2014-October/292170.html

The code was tested on ARMv8 fast model with 64-bit/32-bit userspace using:
 * libseccomp v2.1.1 with modifications for arm64, especially its "live"
   tests: No.20, 21 and 24.
 * modified version of Kees' seccomp test for 'changing/skipping a syscall'
   and seccomp() system call
 * in-house tests for 'changing/skipping a system call' by tracing with
   ptrace(SETREGSET, NT_SYSTEM_CALL) (that is, not via seccomp filter)'
with and without audit tracing.


Changes v8 -> v9:
* removed a restriction on syscall(-1) by setting a default errno [2/6]

Changes v7 -> v8:
* changed an interface of changing a syscall number from ptrace(SET_SYSCALL)
  to ptrace(SETREGSET, NT_ARM_SYSTEM_CALL) [1/6]
* removed IS_SKILL_SYSCALL macro [2/6]
* clarified comments in syscall_trace_enter() [2/6]
* changed unsigned int to compat_uint_t in compat_siginfo._sigsys [5/6]
* moved to a new calling interface of secure_computing(void) [6/6]

Changes v6 -> v7:
* simplified the condition of checking for user-issued syscall(-1) at
  syscall_trace_enter() [2/6]
* defines __NR_seccomp_sigreturn only if arch-specific def doesn't exist.
  As Kees suggests, this is necessary for x86 and others. [3/6]
* removed "#ifdef __ARCH_SIGSYS" which is always true on arm64. [5/6]
* changed to call syscall_trace_exit() even if secure_computing fails. [6/6]
  In v6, syscall_trace_enter() returns RET_SYSCALL_SKIP_TRACE (== -2) and
  skips syscall_trace_exit() to minimize the overhead, but this case can be
  easily confused with user-issued (and invalid) syscall(-2).
  Anyway, this is now a consistent behavior with arm and other archs.

Changes v5 -> v6:
* rebased to v3.17-rc
* changed the interface of changing/skipping a system call from re-writing
  x8 register [v5 1/3] to using dedicated PTRACE_SET_SYSCALL command
  [1/6, 2/6]
  Patch [1/6] contains a checkpatch error around a switch statement, but it
  won't be fixed as in compat_arch_ptrace().
* added a new system call, seccomp(), for compat task [4/6]
* added SIGSYS siginfo for compat task [5/6]
* changed to always execute audit exit tracing to avoid OOPs [2/6, 6/6]

Changes v4 -> v5:
* rebased to v3.16-rc
* add patch [1/3] to allow ptrace to change a system call
  (please note that this patch should be applied even without seccomp.)

Changes v3 -> v4:
* removed the following patch and moved it to "arm64: prerequisites for
  audit and ftrace" patchset since it is required for audit and ftrace in
  case of !COMPAT, too.
  "arm64: is_compat_task is defined both in asm/compat.h and linux/compat.h"

Changes v2 -> v3:
* removed unnecessary 'type cast' operations [2/3]
* check for a return value (-1) of secure_computing() explicitly [2/3]
* aligned with the patch, "arm64: split syscall_trace() into separate
  functions for enter/exit" [2/3]
* changed default of CONFIG_SECCOMP to n [2/3]

Changes v1 -> v2:
* added generic seccomp.h for arm64 to utilize it [1,2/3] 
* changed syscall_trace() to return more meaningful value (-EPERM)
  on seccomp failure case [2/3]
* aligned with the change in "arm64: make a single hook to syscall_trace()
  for all syscall features" v2 [2/3]
* removed is_compat_task() definition from compat.h [3/3]

AKASHI Takahiro (6):
  arm64: ptrace: add NT_ARM_SYSTEM_CALL regset
  arm64: ptrace: allow tracer to skip a system call
  asm-generic: add generic seccomp.h for secure computing mode 1
  arm64: add seccomp syscall for compat task
  arm64: add SIGSYS siginfo for compat task
  arm64: add seccomp support

 arch/arm64/Kconfig|   14 +
 arch/arm64/include/asm/compat.h   |7 +++
 arch/arm64/include/asm/seccomp.h  |   25 +++
 arch/arm64/include/asm/unistd.h   |3 +++
 arch/arm64/include/asm/unistd32.h |3 ++-
 arch/arm64/kernel/entry.S |   10 +-
 arch/arm64/kernel/ptrace.c|   40 +
 arch/arm64/kernel/signal32.c  |6 ++
 include/asm-generic/seccomp.h |   30 
 include/uapi/linux/elf.h  |1 +
 10 files changed, 137 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm64/include/asm/seccomp.h
 create mode 100644 include/asm-generic/seccomp.h

-- 
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/

[PATCH v9 1/6] arm64: ptrace: add NT_ARM_SYSTEM_CALL regset

[AKASHI Takahiro]

This regeset is intended to be used to get and set a system call number
while tracing.
There was some discussion about possible approaches to do so:

(1) modify x8 register with ptrace(PTRACE_SETREGSET) indirectly,
and update regs->syscallno later on in syscall_trace_enter(), or
(2) define a dedicated regset for this purpose as on s390, or
(3) support ptrace(PTRACE_SET_SYSCALL) as on arch/arm

Thinking of the fact that user_pt_regs doesn't expose 'syscallno' to
tracer as well as that secure_computing() expects a changed syscall number,
especially case of -1, to be visible before this function returns in
syscall_trace_enter(), (1) doesn't work well.
We will take (2) since it looks much cleaner.

Signed-off-by: AKASHI Takahiro 
---
 arch/arm64/kernel/ptrace.c |   35 +++
 include/uapi/linux/elf.h   |1 +
 2 files changed, 36 insertions(+)

diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
index 8a4ae8e..8b98781 100644
--- a/arch/arm64/kernel/ptrace.c
+++ b/arch/arm64/kernel/ptrace.c
@@ -551,6 +551,32 @@ static int tls_set(struct task_struct *target, const 
struct user_regset *regset,
return ret;
 }
 
+static int system_call_get(struct task_struct *target,
+  const struct user_regset *regset,
+  unsigned int pos, unsigned int count,
+  void *kbuf, void __user *ubuf)
+{
+   struct pt_regs *regs = task_pt_regs(target);
+
+   return user_regset_copyout(, , , ,
+  >syscallno, 0, -1);
+}
+
+static int system_call_set(struct task_struct *target,
+  const struct user_regset *regset,
+  unsigned int pos, unsigned int count,
+  const void *kbuf, const void __user *ubuf)
+{
+   int syscallno, ret;
+
+   ret = user_regset_copyin(, , , , , 0, -1);
+   if (ret)
+   return ret;
+
+   task_pt_regs(target)->syscallno = syscallno;
+   return ret;
+}
+
 enum aarch64_regset {
REGSET_GPR,
REGSET_FPR,
@@ -559,6 +585,7 @@ enum aarch64_regset {
REGSET_HW_BREAK,
REGSET_HW_WATCH,
 #endif
+   REGSET_SYSTEM_CALL,
 };
 
 static const struct user_regset aarch64_regsets[] = {
@@ -608,6 +635,14 @@ static const struct user_regset aarch64_regsets[] = {
.set = hw_break_set,
},
 #endif
+   [REGSET_SYSTEM_CALL] = {
+   .core_note_type = NT_ARM_SYSTEM_CALL,
+   .n = 1,
+   .size = sizeof(int),
+   .align = sizeof(int),
+   .get = system_call_get,
+   .set = system_call_set,
+   },
 };
 
 static const struct user_regset_view user_aarch64_view = {
diff --git a/include/uapi/linux/elf.h b/include/uapi/linux/elf.h
index ea9bf25..71e1d0e 100644
--- a/include/uapi/linux/elf.h
+++ b/include/uapi/linux/elf.h
@@ -397,6 +397,7 @@ typedef struct elf64_shdr {
 #define NT_ARM_TLS 0x401   /* ARM TLS register */
 #define NT_ARM_HW_BREAK0x402   /* ARM hardware breakpoint 
registers */
 #define NT_ARM_HW_WATCH0x403   /* ARM hardware watchpoint 
registers */
+#define NT_ARM_SYSTEM_CALL 0x404   /* ARM system call number */
 #define NT_METAG_CBUF  0x500   /* Metag catch buffer registers */
 #define NT_METAG_RPIPE 0x501   /* Metag read pipeline state */
 #define NT_METAG_TLS   0x502   /* Metag TLS pointer */
-- 
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/

[PATCHv4 3/3] gpio: sch: Enable IRQ support for Quark X1000

[Chang Rebecca Swee Fun]

ntel Quark X1000 GPIO controller supports interrupt handling for
both core power well and resume power well. This patch is to enable
the IRQ support and provide IRQ handling for Intel Quark X1000
GPIO-SCH device driver.

This piece of work is derived from Dan O'Donovan's initial work for
Quark X1000 enabling.

Signed-off-by: Chang Rebecca Swee Fun 
---
 drivers/gpio/gpio-sch.c |  231 +--
 1 file changed, 224 insertions(+), 7 deletions(-)

diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c
index 1a465bb..498746c 100644
--- a/drivers/gpio/gpio-sch.c
+++ b/drivers/gpio/gpio-sch.c
@@ -28,17 +28,30 @@
 #include 
 
 #include 
+#include 
+#include 
 
 #define GEN0x00
 #define GIO0x04
 #define GLV0x08
+#define GTPE   0x0C
+#define GTNE   0x10
+#define GGPE   0x14
+#define GSMI   0x18
+#define GTS0x1C
+#define CGNMIEN0x40
+#define RGNMIEN0x44
 
 struct sch_gpio {
struct gpio_chip chip;
+   struct irq_data data;
spinlock_t lock;
unsigned short iobase;
unsigned short core_base;
unsigned short resume_base;
+   int irq;
+   int irq_base;
+   bool irq_support;
 };
 
 #define to_sch_gpio(c) container_of(c, struct sch_gpio, chip)
@@ -98,10 +111,11 @@ static void sch_gpio_reg_set(struct gpio_chip *gc, 
unsigned gpio, unsigned reg,
 static int sch_gpio_direction_in(struct gpio_chip *gc, unsigned gpio_num)
 {
struct sch_gpio *sch = to_sch_gpio(gc);
+   unsigned long flags;
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
sch_gpio_reg_set(sch, gpio_num, GIO, 1);
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
return 0;
 }
 
@@ -113,20 +127,22 @@ static int sch_gpio_get(struct gpio_chip *gc, unsigned 
gpio_num)
 static void sch_gpio_set(struct gpio_chip *gc, unsigned gpio_num, int val)
 {
struct sch_gpio *sch = to_sch_gpio(gc);
+   unsigned long flags;
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
sch_gpio_reg_set(gc, gpio_num, GLV, val);
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 }
 
 static int sch_gpio_direction_out(struct gpio_chip *gc, unsigned gpio_num,
  int val)
 {
struct sch_gpio *sch = to_sch_gpio(gc);
+   unsigned long flags;
 
-   spin_lock(>lock);
+   spin_lock_irqsave(>lock, flags);
sch_gpio_reg_set(sch, gpio_num, GIO, 0);
-   spin_unlock(>lock);
+   spin_unlock_irqrestore(>lock, flags);
 
/*
 * according to the datasheet, writing to the level register has no
@@ -141,6 +157,13 @@ static int sch_gpio_direction_out(struct gpio_chip *gc, 
unsigned gpio_num,
return 0;
 }
 
+static int sch_gpio_to_irq(struct gpio_chip *gc, unsigned offset)
+{
+   struct sch_gpio *sch = to_sch_gpio(gc);
+
+   return sch->irq_base + offset;
+}
+
 static struct gpio_chip sch_gpio_chip = {
.label  = "sch_gpio",
.owner  = THIS_MODULE,
@@ -148,12 +171,155 @@ static struct gpio_chip sch_gpio_chip = {
.get= sch_gpio_get,
.direction_output   = sch_gpio_direction_out,
.set= sch_gpio_set,
+   .to_irq = sch_gpio_to_irq,
+};
+
+static void sch_gpio_irq_enable(struct irq_data *d)
+{
+   struct sch_gpio *sch = container_of(d, struct sch_gpio, data);
+   u32 gpio_num;
+
+   gpio_num = d->irq - sch->irq_base;
+   sch_gpio_reg_set(sch, gpio_num, GGPE, 1);
+}
+
+static void sch_gpio_irq_disable(struct irq_data *d)
+{
+   struct sch_gpio *sch = container_of(d, struct sch_gpio, data);
+   u32 gpio_num;
+
+   gpio_num = d->irq - sch->irq_base;
+   sch_gpio_reg_set(sch, gpio_num, GGPE, 0);
+}
+
+static void sch_gpio_irq_ack(struct irq_data *d)
+{
+   struct sch_gpio *sch = container_of(d, struct sch_gpio, data);
+   u32 gpio_num;
+
+   gpio_num = d->irq - sch->irq_base;
+   sch_gpio_reg_set(&(sch->chip), gpio_num, GTS, 1);
+}
+
+static int sch_gpio_irq_type(struct irq_data *d, unsigned type)
+{
+   struct sch_gpio *sch = container_of(d, struct sch_gpio, data);
+   unsigned long flags;
+   u32 gpio_num;
+
+   gpio_num = d->irq - sch->irq_base;
+
+   spin_lock_irqsave(>lock, flags);
+
+   switch (type) {
+   case IRQ_TYPE_EDGE_RISING:
+   sch_gpio_reg_set(sch, gpio_num, GTPE, 1);
+   sch_gpio_reg_set(sch, gpio_num, GTNE, 0);
+   break;
+
+   case IRQ_TYPE_EDGE_FALLING:
+   sch_gpio_reg_set(sch, gpio_num, GTNE, 1);
+   sch_gpio_reg_set(sch, gpio_num, GTPE, 0);
+   break;
+
+   case IRQ_TYPE_EDGE_BOTH:
+   sch_gpio_reg_set(sch, gpio_num, GTPE, 1);
+   sch_gpio_reg_set(sch, gpio_num, GTNE, 1);
+   break;
+
+   case IRQ_TYPE_NONE:
+   

[PATCHv4 2/3] gpio: sch: Add support for Intel Quark X1000 SoC

[Chang Rebecca Swee Fun]

Intel Quark X1000 provides a total of 16 GPIOs. The GPIOs are split between
the legacy I/O bridge and the GPIO controller.

GPIO-SCH is the GPIO pins on legacy bridge for Intel Quark SoC.
Intel Quark X1000 has 2 GPIOs powered by the core power well and 6 from
the suspend power well.

This piece of work is derived from Dan O'Donovan's initial work for Quark
X1000 enabling.

Signed-off-by: Chang Rebecca Swee Fun 
Reviewed-by: Mika Westerberg 
---
 drivers/gpio/Kconfig|   11 +--
 drivers/gpio/gpio-sch.c |6 ++
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
index 414d055..24c4f83 100644
--- a/drivers/gpio/Kconfig
+++ b/drivers/gpio/Kconfig
@@ -394,25 +394,32 @@ config GPIO_VR41XX
  Say yes here to support the NEC VR4100 series General-purpose I/O Uint
 
 config GPIO_SCH
-   tristate "Intel SCH/TunnelCreek/Centerton GPIO"
+   tristate "Intel SCH/TunnelCreek/Centerton/Quark X1000 GPIO"
depends on PCI && X86
select MFD_CORE
select LPC_SCH
help
  Say yes here to support GPIO interface on Intel Poulsbo SCH,
- Intel Tunnel Creek processor or Intel Centerton processor.
+ Intel Tunnel Creek processor, Intel Centerton processor or
+ Intel Quark X1000 SoC.
+
  The Intel SCH contains a total of 14 GPIO pins. Ten GPIOs are
  powered by the core power rail and are turned off during sleep
  modes (S3 and higher). The remaining four GPIOs are powered by
  the Intel SCH suspend power supply. These GPIOs remain
  active during S3. The suspend powered GPIOs can be used to wake the
  system from the Suspend-to-RAM state.
+
  The Intel Tunnel Creek processor has 5 GPIOs powered by the
  core power rail and 9 from suspend power supply.
+
  The Intel Centerton processor has a total of 30 GPIO pins.
  Twenty-one are powered by the core power rail and 9 from the
  suspend power supply.
 
+ The Intel Quark X1000 SoC has 2 GPIOs powered by the core
+ power well and 6 from the suspend power well.
+
 config GPIO_ICH
tristate "Intel ICH GPIO"
depends on PCI && X86
diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c
index 7967f14..1a465bb 100644
--- a/drivers/gpio/gpio-sch.c
+++ b/drivers/gpio/gpio-sch.c
@@ -205,6 +205,12 @@ static int sch_gpio_probe(struct platform_device *pdev)
sch->chip.ngpio = 30;
break;
 
+   case PCI_DEVICE_ID_INTEL_QUARK_X1000_ILB:
+   sch->core_base = 0;
+   sch->resume_base = 2;
+   sch->chip.ngpio = 8;
+   break;
+
default:
return -ENODEV;
}
-- 
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/

[PATCHv4 1/3] gpio: sch: Consolidate similar algorithms

[Chang Rebecca Swee Fun]

Consolidating similar algorithms into common functions to make
GPIO SCH simpler and manageable.

Signed-off-by: Chang Rebecca Swee Fun 
---
 drivers/gpio/gpio-sch.c |   81 ---
 1 file changed, 28 insertions(+), 53 deletions(-)

diff --git a/drivers/gpio/gpio-sch.c b/drivers/gpio/gpio-sch.c
index 99720c8..7967f14 100644
--- a/drivers/gpio/gpio-sch.c
+++ b/drivers/gpio/gpio-sch.c
@@ -63,75 +63,59 @@ static unsigned sch_gpio_bit(struct sch_gpio *sch, unsigned 
gpio)
return gpio % 8;
 }
 
-static void sch_gpio_enable(struct sch_gpio *sch, unsigned gpio)
+static int sch_gpio_reg_get(struct gpio_chip *gc, unsigned gpio, unsigned reg)
 {
+   struct sch_gpio *sch = to_sch_gpio(gc);
unsigned short offset, bit;
-   u8 enable;
-
-   spin_lock(>lock);
+   u8 curr_dirs;
 
-   offset = sch_gpio_offset(sch, gpio, GEN);
+   offset = sch_gpio_offset(sch, gpio, reg);
bit = sch_gpio_bit(sch, gpio);
 
-   enable = inb(sch->iobase + offset);
-   if (!(enable & (1 << bit)))
-   outb(enable | (1 << bit), sch->iobase + offset);
+   curr_dirs = !!(inb(sch->iobase + offset) & BIT(bit));
 
-   spin_unlock(>lock);
+   return curr_dirs;
 }
 
-static int sch_gpio_direction_in(struct gpio_chip *gc, unsigned  gpio_num)
+static void sch_gpio_reg_set(struct gpio_chip *gc, unsigned gpio, unsigned reg,
+int val)
 {
struct sch_gpio *sch = to_sch_gpio(gc);
-   u8 curr_dirs;
unsigned short offset, bit;
+   u8 curr_dirs;
 
-   spin_lock(>lock);
-
-   offset = sch_gpio_offset(sch, gpio_num, GIO);
-   bit = sch_gpio_bit(sch, gpio_num);
+   offset = sch_gpio_offset(sch, gpio, reg);
+   bit = sch_gpio_bit(sch, gpio);
 
curr_dirs = inb(sch->iobase + offset);
 
-   if (!(curr_dirs & (1 << bit)))
-   outb(curr_dirs | (1 << bit), sch->iobase + offset);
+   if (val)
+   outb(curr_dirs | BIT(bit), sch->iobase + offset);
+   else
+   outb((curr_dirs & ~BIT(bit)), sch->iobase + offset);
+}
 
+static int sch_gpio_direction_in(struct gpio_chip *gc, unsigned gpio_num)
+{
+   struct sch_gpio *sch = to_sch_gpio(gc);
+
+   spin_lock(>lock);
+   sch_gpio_reg_set(sch, gpio_num, GIO, 1);
spin_unlock(>lock);
return 0;
 }
 
 static int sch_gpio_get(struct gpio_chip *gc, unsigned gpio_num)
 {
-   struct sch_gpio *sch = to_sch_gpio(gc);
-   int res;
-   unsigned short offset, bit;
-
-   offset = sch_gpio_offset(sch, gpio_num, GLV);
-   bit = sch_gpio_bit(sch, gpio_num);
-
-   res = !!(inb(sch->iobase + offset) & (1 << bit));
-
-   return res;
+   return sch_gpio_reg_get(gc, gpio_num, GLV);
 }
 
 static void sch_gpio_set(struct gpio_chip *gc, unsigned gpio_num, int val)
 {
struct sch_gpio *sch = to_sch_gpio(gc);
-   u8 curr_vals;
-   unsigned short offset, bit;
 
spin_lock(>lock);
-
-   offset = sch_gpio_offset(sch, gpio_num, GLV);
-   bit = sch_gpio_bit(sch, gpio_num);
-
-   curr_vals = inb(sch->iobase + offset);
-
-   if (val)
-   outb(curr_vals | (1 << bit), sch->iobase + offset);
-   else
-   outb((curr_vals & ~(1 << bit)), sch->iobase + offset);
-
+   sch_gpio_reg_set(gc, gpio_num, GLV, val);
spin_unlock(>lock);
 }
 
@@ -139,18 +123,9 @@ static int sch_gpio_direction_out(struct gpio_chip *gc, 
unsigned gpio_num,
  int val)
 {
struct sch_gpio *sch = to_sch_gpio(gc);
-   u8 curr_dirs;
-   unsigned short offset, bit;
 
spin_lock(>lock);
-
-   offset = sch_gpio_offset(sch, gpio_num, GIO);
-   bit = sch_gpio_bit(sch, gpio_num);
-
-   curr_dirs = inb(sch->iobase + offset);
-   if (curr_dirs & (1 << bit))
-   outb(curr_dirs & ~(1 << bit), sch->iobase + offset);
-
+   sch_gpio_reg_set(sch, gpio_num, GIO, 0);
spin_unlock(>lock);
 
/*
@@ -209,13 +184,13 @@ static int sch_gpio_probe(struct platform_device *pdev)
 * GPIO7 is configured by the CMC as SLPIOVR
 * Enable GPIO[9:8] core powered gpios explicitly
 */
-   sch_gpio_enable(sch, 8);
-   sch_gpio_enable(sch, 9);
+   sch_gpio_reg_set(sch, 8, GEN, 1);
+   sch_gpio_reg_set(sch, 9, GEN, 1);
/*
 * SUS_GPIO[2:0] enabled by default
 * Enable SUS_GPIO3 resume powered gpio explicitly
 */
-   sch_gpio_enable(sch, 13);
+   sch_gpio_reg_set(sch, 13, GEN, 1);
break;
 
case PCI_DEVICE_ID_INTEL_ITC_LPC:
-- 
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  

[PATCHv4 0/3] Enable Quark X1000 support in gpio-sch

[Chang Rebecca Swee Fun]

Hi all,

This is a revised version for enabling Quark X1000 support in gpio-sch.
This version of patch series had changed according to the feedback provided
by Alexandre and Mika.

Change log for V4:
Patch 1:
- Removed redundant/duplicated functions of sch_gpio_register_set() and
  sch_gpio_register_clear(). The function call had been replaced by
  sch_gpio_reg_set(gc, gpio, reg, 1) in place of sch_gpio_register_set() and
  sch_gpio_reg_set(gc, gpio, reg, 0) for sch_gpio_register_clear().
- Resolved double spinlock issue caught by Alexandre.

Patch 3:
- Dropped the usage of "if" block that checking irq_data struct
- Restructured the irq detect by using platform_get_irq(pdev, 0) instead of
  platform_get_resource(pdev, IORESOURCE_IRQ, 0) to get IRQ resources from
  MFD LPS-SCH.

The patches need to be patched on top of Mika Westerberg's commit at:
gpio: sch: Consolidate core and resume banks
http://marc.info/?l=linux-kernel=141392647225885=2

The patches has been verifed and tested working on Galileo Board. GPIO sysfs
was able to export gpio pins and changing pin direction. GPIO values were
able to controlled and interrupt was enabled.

Please help to review the patches so that we can make it to upstream kernel
as soon as possible. Thanks for all the review comments during this period of
review cycle.

Regards,
Rebecca

Change log for V3:
Patch 3:
- Change variable type of irq_support to bool.
- Update error message and remove redundant code.
- Revert gpiochip_remove() to avoid it to return a value.

Change log for V2:
Patch 1:
- Move sch_gpio_get() and sch_gpio_set() to avoid forward declaration.
- Changed sch_gpio_enable()/sch_gpio_disable() to sch_gpio_register_set()/
  sch_gpio_register_clear().

Patch 3:
- Changed all sch_gpio_enable()/sch_gpio_disable() to sch_gpio_register_set()/
  sch_gpio_register_clear().

Version 1:
Initial version.

Chang Rebecca Swee Fun (3):
  gpio: sch: Consolidate similar algorithms
  gpio: sch: Add support for Intel Quark X1000 SoC
  gpio: sch: Enable IRQ support for Quark X1000

 drivers/gpio/Kconfig|   11 +-
 drivers/gpio/gpio-sch.c |  316 ++-
 2 files changed, 266 insertions(+), 61 deletions(-)

-- 
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/

linux-next: manual merge of the devicetree tree with the pm, mfd and regulator trees

[Stephen Rothwell]

Hi Grant,

Today's linux-next merge of the devicetree tree got a conflict in
include/linux/of.h between commits b31384fa5de3 ("Driver core: Unified
device properties interface for platform firmware") from the pm tree
and a4b4e0461ec5 ("of: Add standard property for poweroff capability")
from the mfd and regulator trees and commit 7518b5890d8a ("of/overlay:
Introduce DT overlay support") from the devicetree 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 include/linux/of.h
index facd94e45462,aa01cf5852f8..
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@@ -23,7 -23,7 +23,8 @@@
  #include 
  #include 
  #include 
 +#include 
+ #include 
  
  #include 
  #include 
@@@ -108,27 -111,18 +114,27 @@@ static inline struct device_node *of_no
  static inline void of_node_put(struct device_node *node) { }
  #endif /* !CONFIG_OF_DYNAMIC */
  
 -#ifdef CONFIG_OF
 -
  /* Pointer for first entry in chain of all nodes. */
- extern struct device_node *of_allnodes;
+ extern struct device_node *of_root;
  extern struct device_node *of_chosen;
  extern struct device_node *of_aliases;
  extern struct device_node *of_stdout;
  extern raw_spinlock_t devtree_lock;
  
 +#ifdef CONFIG_OF
 +static inline bool is_of_node(struct fwnode_handle *fwnode)
 +{
 +  return fwnode && fwnode->type == FWNODE_OF;
 +}
 +
 +static inline struct device_node *of_node(struct fwnode_handle *fwnode)
 +{
 +  return fwnode ? container_of(fwnode, struct device_node, fwnode) : NULL;
 +}
 +
  static inline bool of_have_populated_dt(void)
  {
-   return of_allnodes != NULL;
+   return of_root != NULL;
  }
  
  static inline bool of_node_is_root(const struct device_node *node)
@@@ -956,14 -959,33 +992,44 @@@ static inline int of_reconfig_get_state
  extern int of_resolve_phandles(struct device_node *tree);
  
  /**
 + * of_system_has_poweroff_source - Tells if poweroff-source is found for 
device_node
 + * @np: Pointer to the given device_node
 + *
 + * return true if present false otherwise
 + */
 +static inline bool of_system_has_poweroff_source(const struct device_node *np)
 +{
 +  return of_property_read_bool(np, "poweroff-source");
 +}
 +
++/**
+  * Overlay support
+  */
+ 
+ #ifdef CONFIG_OF_OVERLAY
+ 
+ /* ID based overlays; the API for external users */
+ int of_overlay_create(struct device_node *tree);
+ int of_overlay_destroy(int id);
+ int of_overlay_destroy_all(void);
+ 
+ #else
+ 
+ static inline int of_overlay_create(struct device_node *tree)
+ {
+   return -ENOTSUPP;
+ }
+ 
+ static inline int of_overlay_destroy(int id)
+ {
+   return -ENOTSUPP;
+ }
+ 
+ static inline int of_overlay_destroy_all(void)
+ {
+   return -ENOTSUPP;
+ }
+ 
+ #endif
+ 
  #endif /* _LINUX_OF_H */


pgp2THNEJtfFj.pgp
Description: OpenPGP digital signature

Re: frequent lockups in 3.18rc4

[Jürgen Groß]

On 11/26/2014 02:48 AM, Linus Torvalds wrote:

On Tue, Nov 25, 2014 at 4:25 PM, Dave Jones  wrote:


The reason I'm checking in at this point, is that I'm starting to see different
bugs at this point, so I don't know if I can call this good or bad, unless
someone has a fix for what I'm seeing now.


Hmm. The three last "bad" biisects are all just 3.17-rc1 plus staging fixes.


Reminiscent of a bug a couple releases ago. Processes about to exit, but stuck
in the kernel continuously faulting..
http://codemonkey.org.uk/junk/weird-hang.txt
The one I'm thinking of got fixed way before 3.17 though.


Well, the staging tree was based on that 3.17-rc1 tree, so it may well
have the bug without the fix.

You have also marked 3.18-rc1 bad *twice*, along with the network
merge, and the tty merge. That's just odd. But it doesn't make the
bisect wrong, it just means that you fat-fingered thing and marked the
same thing bad a couple of times.

Nothing to worry about, unless it's a sign of early Parkinsons...


Does that trace ring a bell of something else I could try on top of
each bisection point ?


Hmm.

Smells somewhat like the "pipe/page fault oddness" bug you reported.

That one caused endless page faults on fault_in_pages_writeable()
because of a page table entry that the VM thought was present, but the
CPU thought was missing.

That caused the whole "pte_protnone()" thing, and trying to get rid of
the PTE_NUMA bit, but those patches have *not* been merged. And you
were ever able to reproduce it., so we left it as pending.

But if you actually really think that the bisect log you posted is
real and true and actually is the bug you're chasing, I have bad news
for you: do a "gitk --bisect", and you'll see that all the remaining
commits are just to staging drivers.

So that would either imply you have some staging driver (unlikely), or
more likely that 3.17 really already has the problem, it's just that
it needs some particular code alignment or phase of the moon or
something to trigger.


I COULD trigger it with 3.17. Took much longer, but I've seen it once.
And from Xen hypervisor data it was clear it was the same bug (cpu
spinning in pmd_lock()).


Juergen

--
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 devicetree tree with the i2c tree

[Stephen Rothwell]

Hi Grant,

Today's linux-next merge of the devicetree tree got a conflict in
drivers/i2c/i2c-core.c between commit 2fd36c552649 ("i2c: core: Map OF
IRQ at probe time") from the  i2c tree and commit a430a3455f2c
("i2c/of: Factor out Devicetree registration code") from the devicetree
tree.

I fixed it up (thanks for the heads up, but please see below) and can
carry the fix as necessary (no action is required).

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

diff --cc drivers/i2c/i2c-core.c
index 19800033e75d,d8afd3f28ca4..
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@@ -1380,61 -1369,69 +1381,67 @@@ static void i2c_scan_static_board_info(
  /* OF support code */
  
  #if IS_ENABLED(CONFIG_OF)
- static void of_i2c_register_devices(struct i2c_adapter *adap)
+ static struct i2c_client *of_i2c_register_device(struct i2c_adapter *adap,
+struct device_node *node)
  {
-   void *result;
-   struct device_node *node;
+   struct i2c_client *result;
+   struct i2c_board_info info = {};
+   struct dev_archdata dev_ad = {};
+   const __be32 *addr;
+   int len;
  
-   /* Only register child devices if the adapter has a node pointer set */
-   if (!adap->dev.of_node)
-   return;
+   dev_dbg(>dev, "of_i2c: register %s\n", node->full_name);
  
-   dev_dbg(>dev, "of_i2c: walking child nodes\n");
+   if (of_modalias_node(node, info.type, sizeof(info.type)) < 0) {
+   dev_err(>dev, "of_i2c: modalias failure on %s\n",
+   node->full_name);
+   return ERR_PTR(-EINVAL);
+   }
  
-   for_each_available_child_of_node(adap->dev.of_node, node) {
-   struct i2c_board_info info = {};
-   struct dev_archdata dev_ad = {};
-   const __be32 *addr;
-   int len;
+   addr = of_get_property(node, "reg", );
+   if (!addr || (len < sizeof(int))) {
+   dev_err(>dev, "of_i2c: invalid reg on %s\n",
+   node->full_name);
+   return ERR_PTR(-EINVAL);
+   }
  
-   dev_dbg(>dev, "of_i2c: register %s\n", node->full_name);
+   info.addr = be32_to_cpup(addr);
+   if (info.addr > (1 << 10) - 1) {
+   dev_err(>dev, "of_i2c: invalid addr=%x on %s\n",
+   info.addr, node->full_name);
+   return ERR_PTR(-EINVAL);
+   }
  
-   if (of_modalias_node(node, info.type, sizeof(info.type)) < 0) {
-   dev_err(>dev, "of_i2c: modalias failure on %s\n",
-   node->full_name);
-   continue;
-   }
 -  info.irq = irq_of_parse_and_map(node, 0);
+   info.of_node = of_node_get(node);
+   info.archdata = _ad;
  
-   addr = of_get_property(node, "reg", );
-   if (!addr || (len < sizeof(int))) {
-   dev_err(>dev, "of_i2c: invalid reg on %s\n",
-   node->full_name);
-   continue;
-   }
+   if (of_get_property(node, "wakeup-source", NULL))
+   info.flags |= I2C_CLIENT_WAKE;
  
-   info.addr = be32_to_cpup(addr);
-   if (info.addr > (1 << 10) - 1) {
-   dev_err(>dev, "of_i2c: invalid addr=%x on %s\n",
-   info.addr, node->full_name);
-   continue;
-   }
+   request_module("%s%s", I2C_MODULE_PREFIX, info.type);
  
-   info.of_node = of_node_get(node);
-   info.archdata = _ad;
+   result = i2c_new_device(adap, );
+   if (result == NULL) {
+   dev_err(>dev, "of_i2c: Failure registering %s\n",
+   node->full_name);
+   of_node_put(node);
 -  irq_dispose_mapping(info.irq);
+   return ERR_PTR(-EINVAL);
+   }
+   return result;
+ }
  
-   if (of_get_property(node, "wakeup-source", NULL))
-   info.flags |= I2C_CLIENT_WAKE;
+ static void of_i2c_register_devices(struct i2c_adapter *adap)
+ {
+   struct device_node *node;
  
-   request_module("%s%s", I2C_MODULE_PREFIX, info.type);
+   /* Only register child devices if the adapter has a node pointer set */
+   if (!adap->dev.of_node)
+   return;
  
-   result = i2c_new_device(adap, );
-   if (result == NULL) {
-   dev_err(>dev, "of_i2c: Failure registering %s\n",
-   node->full_name);
-   of_node_put(node);
-   continue;
-   }
-   }
+   dev_dbg(>dev, "of_i2c: walking child nodes\n");
+ 
+   for_each_available_child_of_node(adap->dev.of_node, node)
+   of_i2c_register_device(adap, node);
  }
  
  static int 

Re: [V5 PATCH 1/1] driver:mtd:spi-nor: Add quad I/O support for Micron spi nor

[Brian Norris]

On Thu, Nov 06, 2014 at 03:09:06AM +, bpqw wrote:
> This patch adds code which enables Quad I/O mode on Micron SPI NOR flashes.
> 
> For Micron SPI NOR flash,enabling or disabling quad I/O protocol is controlled
> by EVCR (Enhanced Volatile Configuration Register), Quad I/O protocol bit 7.
> When EVCR bit 7 is reset to 0,the SPI NOR flash will operate in quad I/O mode.
> 
> Signed-off-by: bean huo 
> Acked-by: Marek Vasut 
> ---
>  v1-v2:
>   Modified to that capture wait_till_ready()
>   return value,if error,directly return its
>   the value.
>  v2-v3:
>   Directly use the reurning error value of
>   read_reg and write_reg,instead of -EINVAL.
>  v3-v4:
>   Modify commit logs that wraped into 80 columns 
>  v4-v5:
>   Rebuild new patch based on latest linux-mtd

You probably aren't based on l2-mtd.git. Your patch still doesn't build.
I can fix it up if it's easy, but FYI. Still reviewing...

drivers/mtd/spi-nor/spi-nor.c: In function ‘micron_quad_enable’:
drivers/mtd/spi-nor/spi-nor.c:874:2: warning: passing argument 3 of 
‘nor->read_reg’ from incompatible pointer type [enabled by default]
  ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
  ^
drivers/mtd/spi-nor/spi-nor.c:874:2: note: expected ‘u8 *’ but argument is of 
type ‘int *’
drivers/mtd/spi-nor/spi-nor.c:891:2: error: implicit declaration of function 
‘wait_till_ready’ [-Werror=implicit-function-declaration]
  ret = wait_till_ready(nor);
  ^
drivers/mtd/spi-nor/spi-nor.c:896:2: warning: passing argument 3 of 
‘nor->read_reg’ from incompatible pointer type [enabled by default]
  ret = nor->read_reg(nor, SPINOR_OP_RD_EVCR, , 1);
  ^
drivers/mtd/spi-nor/spi-nor.c:896:2: note: expected ‘u8 *’ but argument is of 
type ‘int *’

Brian
--
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 0/4] support GMAC driver for RK3288

[Kever Yang]

Hi Roger,

Please use the --in-reply-to option for patches other than 0/4
with the git send-email.

On 11/25/2014 05:07 PM, Roger Chen wrote:

Roger Chen (4):
   patch1: add driver for Rockchip RK3288 SoCs integrated GMAC
   patch2: modify CRU config for Rockchip RK3288 SoCs integrated GMAC
   patch3: dts: add gmac info for rk3288
   patch4: dts: enable gmac on RK3288 evb board

tested on rk3288 SDK board:
busybox ifconfig eth0 up
busybox ifconfig eth0 192.168.1.111
ping 192.168.1.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: [PATCHv3 08/16] clk: mvebu: add suspend/resume for gatable clocks

[Jason Cooper]

On Tue, Nov 25, 2014 at 07:48:01AM +0100, Thomas Petazzoni wrote:
> Mike,
> 
> On Mon, 24 Nov 2014 22:07:00 -0800, Mike Turquette wrote:
> > Quoting Thomas Petazzoni (2014-11-21 08:00:05)
> > > This commit adds suspend/resume support for the gatable clock driver
> > > used on Marvell EBU platforms. When getting out of suspend, the
> > > Marvell EBU platforms go through the bootloader, which re-enables all
> > > gatable clocks. However, upon resume, the clock framework will not
> > > disable again all gatable clocks that are not used.
> > > 
> > > Therefore, if the clock driver does not save/restore the state of the
> > > gatable clocks, all gatable clocks that are not claimed by any device
> > > driver will remain enabled after a resume. This is why this driver
> > > saves and restores the state of those clocks.
> > > 
> > > Since clocks aren't real devices, we don't have the normal ->suspend()
> > > and ->resume() of the device model, and have to use the ->suspend()
> > > and ->resume() hooks of the syscore_ops mechanism. This mechanism has
> > > the unfortunate idea of not providing a way of passing private data,
> > > which requires us to change the driver to make the assumption that
> > > there is only once instance of the gatable clock control structure.
> > > 
> > > Signed-off-by: Thomas Petazzoni 
> > > Cc: Mike Turquette 
> > > Cc: linux-kernel@vger.kernel.org
> > > Acked-by: Gregory CLEMENT 
> > 
> > Looks good to me. Which tree do you plan to take this through?
> 
> I don't have any specific plans. Jason, do you have other clk changes
> for 3.19, which justify a pull request from you to Mike? Or could Mike
> just take this patch in his tree? There is no build dependency between
> this patch and the other patches in the series, so it can go through
> whatever tree.

Well, I pulled the whole series into mvebu/soc-suspend to give it some
time in -next.  It'd be easiest, with my current schedule, to send a
PR for it as-is.  If that's ok with Mike, I'd appreciate it.  Obviously,
I wouldn't make a habit of it... :-P

thx,

Jason.
--
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: [dm-devel] dm-bufio: fix memleak when using a dm_buffer's inline bio

[Darrick J. Wong]

On Tue, Nov 25, 2014 at 10:41:04PM -0500, Mike Snitzer wrote:
> On Tue, Nov 25 2014 at  8:45pm -0500,
> Darrick J. Wong  wrote:
> 
> > When dm-bufio sets out to use the bio built into a struct dm_buffer to
> > issue an IO, it needs to call bio_reset after it's done with the bio
> > so that we can free things attached to the bio such as the integrity
> > payload.  Therefore, inject our own endio callback to take care of
> > the bio_reset after calling submit_io's end_io callback.
> > 
> > Test case:
> > 1. modprobe scsi_debug delay=0 dif=1 dix=199 ato=1 dev_size_mb=300
> > 2. Set up a dm-bufio client, e.g. dm-verity, on the scsi_debug device
> > 3. Repeatedly read metadata and watch kmalloc-192 leak!
> > 
> > Fix is against 3.18-rc6.
> > 
> > Signed-off-by: Darrick J. Wong 
> 
> Thanks for reporting/fixing this.
> 
> Alternatively I think we could just call bio_reset() in submit_io(),
> e.g.:
> 
> diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c
> index afe7971..e7036e3 100644
> --- a/drivers/md/dm-bufio.c
> +++ b/drivers/md/dm-bufio.c
> @@ -579,6 +579,8 @@ static void submit_io(struct dm_buffer *b, int rw, 
> sector_t block,
>   if (rw == WRITE && b->c->write_callback)
>   b->c->write_callback(b);
>  
> + bio_reset(>bio);
> +
>   if (b->c->block_size <= DM_BUFIO_INLINE_VECS * PAGE_SIZE &&
>   b->data_mode != DATA_MODE_VMALLOC)
>   use_inline_bio(b, rw, block, end_io);
> 
> What do you think?

I decided to call bio_reset after calling end_io so that we can free
the integrity buffer as soon as we're done with the bio.  Calling
bio_reset just prior to the next submit_bio as this snippet does means
that the integrity buffer remains attached to the bio until just
before the next submit_bio call, which could be a while.

Also, I think use_dmio results in a new bio being used instead of the
bio embedded in the dm_buffer, so it shouldn't be necessary to reset
the bio if the previous IO had use_dmio'd.

--D

> 
> --
> dm-devel mailing list
> dm-de...@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel
--
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 6/7] ARM: mvebu: add PHY support to the dts for the USB controllers on Armada 375

[Jason Cooper]

On Sat, Nov 22, 2014 at 10:20:43AM +0100, Gregory CLEMENT wrote:
> Hi Jason,
> 
> On 22/11/2014 03:08, Jason Cooper wrote:
> > On Thu, Nov 13, 2014 at 12:47:48PM +0100, Gregory CLEMENT wrote:
> >> Now that the USB cluster node has been added, use it as a PHY provider
> >> for the USB controller linked to it: the first EHCI and the xHCI.
> >>
> >> Signed-off-by: Gregory CLEMENT 
> >> ---
> >>  arch/arm/boot/dts/armada-375.dtsi | 5 +
> >>  1 file changed, 5 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/armada-375.dtsi 
> >> b/arch/arm/boot/dts/armada-375.dtsi
> >> index 8f45cf5d2a50..f344ec420c95 100644
> >> --- a/arch/arm/boot/dts/armada-375.dtsi
> >> +++ b/arch/arm/boot/dts/armada-375.dtsi
> >> @@ -14,6 +14,7 @@
> >>  #include "skeleton.dtsi"
> >>  #include 
> >>  #include 
> >> +#include 
> > 
> > Odd.  The previous patch in this series simply adds a line to phy.h,
> > however, I get the following error during 'make dtbs':
> > 
> > 
> >   DTC arch/arm/boot/dts/armada-375-db.dtb
> > In file included from 
> > arch/arm/boot/dts/armada-375-db.dts:17:0:arch/arm/boot/dts/armada-375.dtsi:17:33:
> > fatal error: dt-bindings/phy/phy.h: No such file or directory
> >  #include 
> >  ^
> > compilation terminated.
> > scripts/Makefile.lib:282: recipe for target 'arch/arm/boot/dts/armada-37 
> > 5-db.dtb' failed
> > 
> > 
> > mvebu/dt is based on v3.18-rc1.  Is there a missing dependency
> > somewhere?  Perhaps we should let Kishon take the whole series and
> > handle the (hopefully trivial) merge conflict?
> 
> Actually Kishon asked me to use the dt-bindings/phy/phy.h file which
> was introduced by the patch "phy: Add PHY header file for DT x Driver
> defines". So indeed I had to have a dependency on the phy_dt_header
> branch (which is based on v3.18-rc4 and have only this single commit).
> The git tree is located at
> git://git.kernel.org/pub/scm/linux/kernel/git/kishon/linux-phy.git
> 
> 
> Maybe we could add this branch in mvebu as a dependency as it is done
> on arm-soc. I suggest this because I would prefer that we continue to
> be the only ones to merge the device tree files in order to reduce the
> merge conflict.

Ok, I've applied patches 5 and 6 to mvebu/dt-usb_phy with a dependency
on tags/phy-dt-header.

Patches 1-4:

Acked-by: Jason Cooper 

thx,

Jason.
--
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 7/7] MAINTAINERS: add entry for the Armada 375 USB cluster PHY driver

[Jason Cooper]

On Thu, Nov 13, 2014 at 12:47:49PM +0100, Gregory CLEMENT wrote:
> Add MAINTAINERS add entry for the Armada 375 USB cluster PHY driver.
> 
> Signed-off-by: Gregory CLEMENT 
> ---
>  MAINTAINERS | 6 ++
>  1 file changed, 6 insertions(+)

Not that i do anything with, phy, but just so you know I'm not taking
it:

Acked-by: Jason Cooper 

thx,

Jason.
--
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: dm-bufio: fix memleak when using a dm_buffer's inline bio

[Mike Snitzer]

On Tue, Nov 25 2014 at  8:45pm -0500,
Darrick J. Wong  wrote:

> When dm-bufio sets out to use the bio built into a struct dm_buffer to
> issue an IO, it needs to call bio_reset after it's done with the bio
> so that we can free things attached to the bio such as the integrity
> payload.  Therefore, inject our own endio callback to take care of
> the bio_reset after calling submit_io's end_io callback.
> 
> Test case:
> 1. modprobe scsi_debug delay=0 dif=1 dix=199 ato=1 dev_size_mb=300
> 2. Set up a dm-bufio client, e.g. dm-verity, on the scsi_debug device
> 3. Repeatedly read metadata and watch kmalloc-192 leak!
> 
> Fix is against 3.18-rc6.
> 
> Signed-off-by: Darrick J. Wong 

Thanks for reporting/fixing this.

Alternatively I think we could just call bio_reset() in submit_io(),
e.g.:

diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c
index afe7971..e7036e3 100644
--- a/drivers/md/dm-bufio.c
+++ b/drivers/md/dm-bufio.c
@@ -579,6 +579,8 @@ static void submit_io(struct dm_buffer *b, int rw, sector_t 
block,
if (rw == WRITE && b->c->write_callback)
b->c->write_callback(b);
 
+   bio_reset(>bio);
+
if (b->c->block_size <= DM_BUFIO_INLINE_VECS * PAGE_SIZE &&
b->data_mode != DATA_MODE_VMALLOC)
use_inline_bio(b, rw, block, end_io);

What do you think?
--
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] mtd: block2mtd: Present block2mtd timely on boot time

[Brian Norris]

On Sun, Nov 09, 2014 at 07:18:05AM -0500, Rodrigo Freire wrote:
> > From: "Brian Norris" 
> > Sent: Wednesday, November 5, 2014 6:23:03 PM
> 
> > This still seems like a bad idea (using a block device + block2mtd +
> > JFFS2). Why are you doing this? See comments here:
> > http://www.linux-mtd.infradead.org/faq/jffs2.html#L_hdd_jffs2
> 
> As Felix stated on a previous message to the thread, I am using JFFS2 over
> block2mtd where regular filesystems failed to do so well. There are several
> [1] threads pointing this issue, and JFFS2 over block2mtd works like a charm
> on more harsh scenarios.
[...]
> [1] - http://bit.ly/1smGvwa

OK, so there are definitely problems with cheap SD card power cut
tolerance. That's not news. But that doesn't mean block2mtd + JFFS2 is a
good solution. In fact, when I add 'jffs2' to your Google search query
of 'raspberry pi corrupt sd card', the only mentions I see are those who
agree that this is not the right choice.

But anyway, we can look at supporting block2mtd (since you provided the
patches), even if we don't agree how it should be used. And in fact, I
might argue there are no good (production) uses for block2mtd, so I
suppose I don't have much stake in it :)

Brian
--
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: pseries/le: Fix endiannes issue in RTAS call from xmon

[Michael Ellerman]

On Mon, 2014-24-11 at 14:07:53 UTC, Laurent Dufour wrote:
> On pseries system (LPAR) xmon failed to enter when running in LE mode, system
> is hunging. Inititating xmon will lead to such an output on the console:

OK. You say "LPAR", by which you mean "under phyp" I think. I haven't seen this
under KVM, and it looks like KVM doesn't implement "set-indicator" so that
would explain that.

I'll take this as a bug fix and CC it to stable.

cheers
--
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 3/3] ARM: at91: sama5d4: Add SFR

[Josh Wu]

Hi, Alexandre

On 11/26/2014 12:40 AM, Alexandre Belloni wrote:

The sama4d4 has Special Function Registers that allow to manage DDR, OHCI, EBI
and AIC interrupt redirection.


Just a nitpick, It should be sama5d4, not sama4d4.

Best Regards,
Josh Wu



Signed-off-by: Alexandre Belloni 
Acked-by: Boris Brezillon 
---
  arch/arm/boot/dts/sama5d4.dtsi | 5 +
  1 file changed, 5 insertions(+)

diff --git a/arch/arm/boot/dts/sama5d4.dtsi b/arch/arm/boot/dts/sama5d4.dtsi
index e0157b0f075c..9e281e22d591 100644
--- a/arch/arm/boot/dts/sama5d4.dtsi
+++ b/arch/arm/boot/dts/sama5d4.dtsi
@@ -826,6 +826,11 @@
status = "disabled";
};
  
+			sfr: sfr@f8028000 {

+   compatible = "atmel,sama5d4-sfr", "syscon";
+   reg = <0xf8028000 0x4000>;
+   };
+
mmc1: mmc@fc00 {
compatible = "atmel,hsmci";
reg = <0xfc00 0x600>;


--
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 07/14] of/reconfig: Always use the same structure for notifiers

[Nathan Fontenot]

On 11/25/2014 05:07 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2014-11-24 at 22:33 +, Grant Likely wrote:
>> The OF_RECONFIG notifier callback uses a different structure depending
>> on whether it is a node change or a property change. This is silly, and
>> not very safe. Rework the code to use the same data structure regardless
>> of the type of notifier.
> 
> I fell pretty good about this one except...
> 
>> diff --git a/arch/powerpc/mm/numa.c b/arch/powerpc/mm/numa.c
>> index b9d1dfdbe5bb..9fe6002c1d5a 100644
>> --- a/arch/powerpc/mm/numa.c
>> +++ b/arch/powerpc/mm/numa.c
>> @@ -1711,12 +1711,11 @@ static void stage_topology_update(int core_id)
>>  static int dt_update_callback(struct notifier_block *nb,
>>  unsigned long action, void *data)
>>  {
>> -struct of_prop_reconfig *update;
>> +struct of_reconfig_data *update = data;
>>  int rc = NOTIFY_DONE;
>>  
>>  switch (action) {
>>  case OF_RECONFIG_UPDATE_PROPERTY:
>> -update = (struct of_prop_reconfig *)data;
> 
> Should we assert/bug on !update->dn / update->prop ?
> 
> (Same for the rest of the patch)
> 
> Or do you reckon it's pointless ?
> 

I'm not sure it's worth it, if those are NULL pointers the drivers/of
code would have tried to use them before invoking the notifier chain.
We won't make it this far if they're NULL.

Otherwise the patch looks good to me,

Reviewed-by: Nathan Fontenot 

-Nathan

--
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 4/5] arm64: Add support for Spreadtrum's Sharkl64 Platform in Kconfig and defconfig

[Lyra Zhang]

2014-11-25 20:57 GMT+08:00 Arnd Bergmann :
>
> On Tuesday 25 November 2014 20:16:57 Chunyan Zhang wrote:
> >
> > +menuconfig ARCH_SPRD
> > +   bool "Spreadtrum SoC platform"
> > +   depends on ARM64
> > +   help
> > + Support for Spreadtrum ARM based SoCs
> > +
> > +if ARCH_SPRD
> > +
> > +config ARCH_SHARKL64
> > +   bool "Sharkl64 SoC Platform"
> > +   help
> > + Sharkl64 is a Spreadtrum's SoC Platform which is based
> > + on ARM 64-bit processor core including
> > +   sc9836
> > +
> > +endif #ARCH_SPRD
> > +
>
> I don't think we need multiple levels here, it should be enough to
> have either ARCH_SPRD or ARCH_SHARKL64, because all device drivers
> are going to be optional anyway. Typically a Kconfig symbol covers
> all SoCs that are related, so if you Spreadtrum are doing both
> phone and server chips and these are designed independently, you
> would have two symbols, but if you only expect to see phone chips
> here that are all derived from the same product line, using ARCH_SPRD
> to refer to all of them should be enough.
>
> Arnd


For now, we have only one platform(Sharkl64) based on ARM64 been
submitted, but we're intending to add support for more our platforms
based on ARM64 or ARM32 in the future. There are many common devices
on these platforms, such as serial. Our idea would be that if we had a
'menuconfig ARCH_SPRD' in the Kconfig, these common devices only need
to depend on ARCH_SPRD in the respective Kconfig, otherwise they may
depend on a few Kconfig symbols for every platforms which include
these common devices.

So, do you think whether we should define a menuconfig(ARCH_SPRD) in
the Kconfig for this case ?

Thanks!

Best regards,
Chunyan
--
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/5] hwmon: ina2xx: bail-out from ina2xx_probe() in case of configuration errors

[Guenter Roeck]

On 11/25/2014 10:30 AM, Guenter Roeck wrote:

On 11/25/2014 10:22 AM, Bartosz Golaszewski wrote:

2014-11-25 18:59 GMT+01:00 Guenter Roeck :

It seems to me this is a problem of your architecture. That doesn't
make it a generic problem. Your architecture should detect that a
probe was disconnected and de-instantiate the device automatically
if so, and re-instantiate it if it is re-inserted. Ultimately this
should be done with, for example, devicetree overlays.


You're right and it's planned to be done this way in the future, when
this project exits its prototype phase (around Q2 2015). Nevertheless
I still think that if we're adding a set function, it should behave
like the getters and check the value returned by
i2c_smbus_write_word_swapped().



I do not question that. I question changing the return value to -ENODEV.

Repeating my earlier question: Is the resistor value changed by software
or by changing the probe ?



Looking into the available documents, I am quite sure that the resistor
is changed by replacing the probe, in other words by pulling the board
with the ina226 and replacing it with another one. Given that, configuring
the shunt resistor value with a sysfs attribute is really the wrong way
to do it; you should use probe specific devicetree overlays instead.

Guenter

--
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 3/4] GMAC: dts: add gmac info for rk3288

[Roger]

On 2014/11/25 22:39, Heiko Stübner wrote:

Am Dienstag, 25. November 2014, 16:40:59 schrieb Sergei Shtylyov:

Hello.

On 11/25/2014 12:08 PM, Roger Chen wrote:

add gmac info in rk3288.dtsi for GMAC driver

Signed-off-by: Roger Chen 
---

   arch/arm/boot/dts/rk3288.dtsi |   59
   + 1 file changed, 59
   insertions(+)

diff --git a/arch/arm/boot/dts/rk3288.dtsi b/arch/arm/boot/dts/rk3288.dtsi
index 0f50d5d..949675d 100644
--- a/arch/arm/boot/dts/rk3288.dtsi
+++ b/arch/arm/boot/dts/rk3288.dtsi

[...]


@@ -490,6 +497,25 @@

reg = <0xff74 0x1000>;

};

+   gmac: eth@ff29 {

 Please name the node "ethernet@ff29" to comply with the ePAPR
standard.

+   compatible = "rockchip,rk3288-gmac";
+   reg = <0xff29 0x1>;
+   interrupts = ;  /*irq=59*/
+   interrupt-names = "macirq";
+   rockchip,grf = <>;
+   clocks = < SCLK_MAC>, < SCLK_MAC_PLL>,
+   < SCLK_MAC_RX>, < SCLK_MAC_TX>,
+   < SCLK_MACREF>, < SCLK_MACREF_OUT>,
+   < ACLK_GMAC>, < PCLK_GMAC>;
+   clock-names = "stmmaceth", "clk_mac_pll",
+   "mac_clk_rx", "mac_clk_tx",
+   "clk_mac_ref", "clk_mac_refout",
+   "aclk_mac", "pclk_mac";
+   phy-mode = "rgmii";
+   pinctrl-names = "default";
+   pinctrl-0 = <_pin /*_pin*/>;

 Hm, pinctrl props in a .dtsi file? Those are usually board dependent.

yep, especially as there is a board-dependent selection needed of what to use
[rgmii or rmii] depending on the phy on the board.


of course pinctrl props is redefined in the rk3288-evb-rk808.dts,
IMO, pinctrl props in .dtsi is used to fit for the "phy-mode" prop as default.
if pinctrl props should be removed, how about "phy-mode" prop?


[...]


@@ -1040,5 +1066,38 @@

rockchip,pins = <7 23 3 _pull_none>;

};

};

+
+   gmac {
+   rgmii_pin: rgmii-pins {

please add the "s" to the label - "rgmii_pins"



+   rockchip,pins = <3 30 3 _pull_none>,
+   <3 31 3 _pull_none>,
+   <3 26 3 _pull_none>,
+   <3 27 3 _pull_none>,
+   <3 28 3 _pull_none>,
+   <3 29 3 _pull_none>,
+   <3 24 3 _pull_none>,
+   <3 25 3 _pull_none>,
+   <4 0 3 _pull_none>,
+   <4 5 3 _pull_none>,
+   <4 6 3 _pull_none>,
+   <4 9 3 _pull_none>,
+   <4 4 3 _pull_none>,
+   <4 1 3 _pull_none>,
+   <4 3 3 _pull_none>;
+   };
+
+   rmii_pin: rmii-pins {

same here



+   rockchip,pins = <3 30 3 _pull_none>,
+   <3 31 3 _pull_none>,
+   <3 28 3 _pull_none>,
+   <3 29 3 _pull_none>,
+   <4 0 3 _pull_none>,
+   <4 5 3 _pull_none>,
+   <4 4 3 _pull_none>,
+   <4 1 3 _pull_none>,
+   <4 2 3 _pull_none>,
+   <4 3 3 _pull_none>;
+   };
+   };

 These are usually define in the board .dts file...

The pinctrl settings itself are soc-specific, i.e. the pins and their settings
to use to enable r{g}mii functionality are the same for all boards using this
soc, so the pinctrl definitions should stay here and not be redefined in each
and every board file.


Heiko






--
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 v4] SPI: spi-pxa2xx: Add helpers for regiseters' accessing

[Weike Chen]

There are several registers for SPI, and the registers of 'SSCR0' and 'SSCR1'
are accessed frequently. This path is to introduce helper functions to
simplify the accessing of 'SSCR0' and 'SSCR1'.

Reviewed-by: Andy Shevchenko 
Acked-by: Mika Westerberg 
Signed-off-by: Weike Chen 
---
 drivers/spi/spi-pxa2xx.c |  107 --
 1 file changed, 84 insertions(+), 23 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index d8a105f..770b581 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -80,6 +80,73 @@ static bool is_lpss_ssp(const struct driver_data *drv_data)
return drv_data->ssp_type == LPSS_SSP;
 }
 
+static u32 pxa2xx_spi_get_ssrc1_change_mask(const struct driver_data *drv_data)
+{
+   switch (drv_data->ssp_type) {
+   default:
+   return SSCR1_CHANGE_MASK;
+   }
+}
+
+static u32
+pxa2xx_spi_get_rx_default_thre(const struct driver_data *drv_data)
+{
+   switch (drv_data->ssp_type) {
+   default:
+   return RX_THRESH_DFLT;
+   }
+}
+
+static bool pxa2xx_spi_txfifo_full(const struct driver_data *drv_data)
+{
+   void __iomem *reg = drv_data->ioaddr;
+   u32 mask;
+
+   switch (drv_data->ssp_type) {
+   default:
+   mask = SSSR_TFL_MASK;
+   break;
+   }
+
+   return (read_SSSR(reg) & mask) == mask;
+}
+
+static void pxa2xx_spi_clear_rx_thre(const struct driver_data *drv_data,
+u32 *sccr1_reg)
+{
+   u32 mask;
+
+   switch (drv_data->ssp_type) {
+   default:
+   mask = SSCR1_RFT;
+   break;
+   }
+   *sccr1_reg &= ~mask;
+}
+
+static void pxa2xx_spi_set_rx_thre(const struct driver_data *drv_data,
+  u32 *sccr1_reg, u32 threshold)
+{
+   switch (drv_data->ssp_type) {
+   default:
+   *sccr1_reg |= SSCR1_RxTresh(threshold);
+   break;
+   }
+}
+
+static u32 pxa2xx_configure_sscr0(const struct driver_data *drv_data,
+ u32 clk_div, u8 bits)
+{
+   switch (drv_data->ssp_type) {
+   default:
+   return clk_div
+   | SSCR0_Motorola
+   | SSCR0_DataSize(bits > 16 ? bits - 16 : bits)
+   | SSCR0_SSE
+   | (bits > 16 ? SSCR0_EDSS : 0);
+   }
+}
+
 /*
  * Read and write LPSS SSP private registers. Caller must first check that
  * is_lpss_ssp() returns true before these can be called.
@@ -234,7 +301,7 @@ static int null_writer(struct driver_data *drv_data)
void __iomem *reg = drv_data->ioaddr;
u8 n_bytes = drv_data->n_bytes;
 
-   if (((read_SSSR(reg) & SSSR_TFL_MASK) == SSSR_TFL_MASK)
+   if (pxa2xx_spi_txfifo_full(drv_data)
|| (drv_data->tx == drv_data->tx_end))
return 0;
 
@@ -262,7 +329,7 @@ static int u8_writer(struct driver_data *drv_data)
 {
void __iomem *reg = drv_data->ioaddr;
 
-   if (((read_SSSR(reg) & SSSR_TFL_MASK) == SSSR_TFL_MASK)
+   if (pxa2xx_spi_txfifo_full(drv_data)
|| (drv_data->tx == drv_data->tx_end))
return 0;
 
@@ -289,7 +356,7 @@ static int u16_writer(struct driver_data *drv_data)
 {
void __iomem *reg = drv_data->ioaddr;
 
-   if (((read_SSSR(reg) & SSSR_TFL_MASK) == SSSR_TFL_MASK)
+   if (pxa2xx_spi_txfifo_full(drv_data)
|| (drv_data->tx == drv_data->tx_end))
return 0;
 
@@ -316,7 +383,7 @@ static int u32_writer(struct driver_data *drv_data)
 {
void __iomem *reg = drv_data->ioaddr;
 
-   if (((read_SSSR(reg) & SSSR_TFL_MASK) == SSSR_TFL_MASK)
+   if (pxa2xx_spi_txfifo_full(drv_data)
|| (drv_data->tx == drv_data->tx_end))
return 0;
 
@@ -508,8 +575,9 @@ static irqreturn_t interrupt_transfer(struct driver_data 
*drv_data)
 * remaining RX bytes.
 */
if (pxa25x_ssp_comp(drv_data)) {
+   u32 rx_thre;
 
-   sccr1_reg &= ~SSCR1_RFT;
+   pxa2xx_spi_clear_rx_thre(drv_data, _reg);
 
bytes_left = drv_data->rx_end - drv_data->rx;
switch (drv_data->n_bytes) {
@@ -519,10 +587,11 @@ static irqreturn_t interrupt_transfer(struct driver_data 
*drv_data)
bytes_left >>= 1;
}
 
-   if (bytes_left > RX_THRESH_DFLT)
-   bytes_left = RX_THRESH_DFLT;
+   rx_thre = pxa2xx_spi_get_rx_default_thre(drv_data);
+   if (rx_thre > bytes_left)
+   rx_thre = bytes_left;
 
-   sccr1_reg |= SSCR1_RxTresh(bytes_left);
+   pxa2xx_spi_set_rx_thre(drv_data, _reg, rx_thre);
}

[PATCH 0/2 v4] SPI: spi-pxa2xx: Add support for Intel Quark X1000 SPI controller

[Weike Chen]

Hi,
Intel Quark X1000 consists of two SPI controllers which can be PCI enumerated.
SPI-PXA2XX PCI layer doesn't support it. Thus, we add support for Intel Quark
X1000 SPI as well.

---
v4:
[PATCH 1/2]
* No changes.
[PATCH 2/2]
* Move all Quark specific macros out of #ifdef 'CONFIG_ARCH_PXA'.

v3:
[PATCH 1/2]
* Improve the commit message.
* A couple of minor fixes.
[PATCH 2/2]
* Set '.num_chipselect' to '1' instead of '4'.
* A couple of minor fixes.

v2:
  Split into two patches: one is for helper functions,
  and another is for quark supporting.

[PATCH 1/2]
* Add helper functions to access registers.
* Use 'switch' instead of 'if-else'.
[PATCH 2/2]
* Use 'switch' instead of 'if-else'.
* Add comments for the 'dds'&'clk_div' caculation.
* A couple of minor fixes.

Weike Chen (2):
  SPI: spi-pxa2xx: Add helpers for regiseters' accessing
  SPI: spi-pxa2xx: SPI support for Intel Quark X1000

 drivers/spi/spi-pxa2xx-pci.c |8 ++
 drivers/spi/spi-pxa2xx.c |  304 --
 drivers/spi/spi-pxa2xx.h |   16 ++-
 include/linux/pxa2xx_ssp.h   |   20 +++
 4 files changed, 303 insertions(+), 45 deletions(-)

-- 
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/

[PATCH 2/2 v4] SPI: spi-pxa2xx: SPI support for Intel Quark X1000

[Weike Chen]

There are two SPI controllers exported by PCI subsystem for Intel Quark X1000.
The SPI memory mapped I/O registers supported by Quark are different from
the current implementation, and Quark only supports the registers of 'SSCR0',
'SSCR1', 'SSSR', 'SSDR', and 'DDS_RATE'. This patch is to enable the SPI for
Intel Quark X1000.

This piece of work is derived from Dan O'Donovan's initial work for Intel Quark
X1000 SPI enabling.

Reviewed-by: Andy Shevchenko 
Acked-by: Mika Westerberg 
Signed-off-by: Weike Chen 
---
 drivers/spi/spi-pxa2xx-pci.c |8 ++
 drivers/spi/spi-pxa2xx.c |  197 ++
 drivers/spi/spi-pxa2xx.h |   16 ++--
 include/linux/pxa2xx_ssp.h   |   20 +
 4 files changed, 219 insertions(+), 22 deletions(-)

diff --git a/drivers/spi/spi-pxa2xx-pci.c b/drivers/spi/spi-pxa2xx-pci.c
index 6beee8c..fa7399e 100644
--- a/drivers/spi/spi-pxa2xx-pci.c
+++ b/drivers/spi/spi-pxa2xx-pci.c
@@ -19,6 +19,7 @@ enum {
PORT_BSW0,
PORT_BSW1,
PORT_BSW2,
+   PORT_QUARK_X1000,
 };
 
 struct pxa_spi_info {
@@ -92,6 +93,12 @@ static struct pxa_spi_info spi_info_configs[] = {
.tx_param = _tx_param,
.rx_param = _rx_param,
},
+   [PORT_QUARK_X1000] = {
+   .type = QUARK_X1000_SSP,
+   .port_id = -1,
+   .num_chipselect = 1,
+   .max_clk_rate = 5000,
+   },
 };
 
 static int pxa2xx_spi_pci_probe(struct pci_dev *dev,
@@ -191,6 +198,7 @@ static void pxa2xx_spi_pci_remove(struct pci_dev *dev)
 
 static const struct pci_device_id pxa2xx_spi_pci_devices[] = {
{ PCI_VDEVICE(INTEL, 0x2e6a), PORT_CE4100 },
+   { PCI_VDEVICE(INTEL, 0x0935), PORT_QUARK_X1000 },
{ PCI_VDEVICE(INTEL, 0x0f0e), PORT_BYT },
{ PCI_VDEVICE(INTEL, 0x228e), PORT_BSW0 },
{ PCI_VDEVICE(INTEL, 0x2290), PORT_BSW1 },
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c
index 770b581..d8ed3e0 100644
--- a/drivers/spi/spi-pxa2xx.c
+++ b/drivers/spi/spi-pxa2xx.c
@@ -63,10 +63,64 @@ MODULE_ALIAS("platform:pxa2xx-spi");
| SSCR1_RFT | SSCR1_TFT | SSCR1_MWDS \
| SSCR1_SPH | SSCR1_SPO | SSCR1_LBM)
 
+#define QUARK_X1000_SSCR1_CHANGE_MASK (QUARK_X1000_SSCR1_STRF  \
+   | QUARK_X1000_SSCR1_EFWR\
+   | QUARK_X1000_SSCR1_RFT \
+   | QUARK_X1000_SSCR1_TFT \
+   | SSCR1_SPH | SSCR1_SPO | SSCR1_LBM)
+
 #define LPSS_RX_THRESH_DFLT64
 #define LPSS_TX_LOTHRESH_DFLT  160
 #define LPSS_TX_HITHRESH_DFLT  224
 
+struct quark_spi_rate {
+   u32 bitrate;
+   u32 dds_clk_rate;
+   u32 clk_div;
+};
+
+/*
+ * 'rate', 'dds', 'clk_div' lookup table, which is defined in
+ * the Quark SPI datasheet.
+ */
+static const struct quark_spi_rate quark_spi_rate_table[] = {
+/* bitrate,dds_clk_rate,   clk_div */
+   {5000,  0x80,   0},
+   {4000,  0x66,   0},
+   {2500,  0x40,   0},
+   {2000,  0x66,   1},
+   {16667000,  0x80,   2},
+   {1000,  0x66,   2},
+   {1250,  0x20,   0},
+   {1000,  0x80,   4},
+   {800,   0x66,   4},
+   {625,   0x40,   3},
+   {500,   0x40,   4},
+   {400,   0x66,   9},
+   {3125000,   0x8,0},
+   {250,   0x40,   9},
+   {200,   0x66,   19},
+   {1563000,   0x4,0},
+   {125,   0x20,   9},
+   {100,   0x40,   24},
+   {80,0x66,   49},
+   {781250,0x2,0},
+   {625000,0x20,   19},
+   {50,0x40,   49},
+   {40,0x66,   99},
+   {390625,0x1,0},
+   {25,0x40,   99},
+   {20,0x66,   199},
+   {195313,0x8000, 0},
+   {125000,0x10,   49},
+   {10,0x20,   124},
+   {5, 0x10,   124},
+   {25000, 0x8,124},
+   {10016, 0x2,77},
+   {5040,  0x2,154},
+   {1002,  0x8000, 194},
+};
+
 /* Offset from drv_data->lpss_base */
 #define GENERAL_REG0x08
 #define GENERAL_REG_RXTO_HOLDOFF_DISABLE BIT(24)
@@ -80,9 +134,16 @@ static bool is_lpss_ssp(const struct driver_data *drv_data)
return drv_data->ssp_type == LPSS_SSP;
 }
 
+static bool is_quark_x1000_ssp(const struct driver_data *drv_data)
+{
+   return drv_data->ssp_type == QUARK_X1000_SSP;
+}
+
 static u32 pxa2xx_spi_get_ssrc1_change_mask(const struct driver_data 

Re: [PATCH v3 0/3] Support PMIC operation region for CrystalCove and XPower

[Aaron Lu]

On 11/26/2014 10:35 AM, Aaron Lu wrote:
> On 11/26/2014 04:41 AM, Rafael J. Wysocki wrote:
>> On Tuesday, November 25, 2014 07:52:31 PM Aaron Lu wrote:
>>> On 11/25/2014 09:47 AM, Rafael J. Wysocki wrote:
 On Friday, November 21, 2014 03:11:48 PM Aaron Lu wrote:
> v3:
> Only some function/variable name changes, no functiona changes:
> - Replace the dptf/DPTF word originate from the BIOS ACPI table with more
>   meaningful word thermal/THERMAL in all places;
> - Eliminate the soc part in various structure and function names to make
>   them shorter:
>   intel_soc_pmic_opregion -> intel_pmic_opregion
>   intel_soc_pmic_pmop_handler -> intel_pmic_pmop_handler
>   intel_soc_pmic_install_opregion_handler -> 
> intel_pmic_install_opregion_handler
>   etc.
>
>
> v2:
> Place PMIC operation files under drivers/acpi/pmic instead of
> drivers/acpi/pmic_opregion as suggested by Rafael;
> Rename PMIC operation files to make them shorter as suggested by Rafael.
>
> v1:
> On Intel Baytrail-T and Baytrail-T-CR platforms, there are two customized
> ACPI operation regions defined for the Power Management Integrated Circuit
> device, one is for power resource handling and one is for thermal: sensor
> temperature reporting, trip point setting, etc. There are different PMIC
> chips used on those platforms and though each has the same two operation
> regions and functionality, their implementation is different so every PMIC
> will need a driver. But since their functionality is similar, some common
> code is abstracted into the intel_soc_pmic_opregion.c.
>
> The last version is posted here:
> https://lkml.org/lkml/2014/9/8/801
>
> Changes since then:
> 1 Move to drivers/acpi as discussed on the above thread;
> 2 Added support for XPower AXP288 PMIC operation region support;
> 3 Since operation region handler can not be removed(at the moment at 
> least),
>   use bool for the two operation region driver configs instead of 
> tristate;
>   Another reason to do this is that, with Mika's MFD ACPI support patch, 
> all
>   those MFD cell devices created will have the same modalias as their 
> parent's
>   so it doesn't make much sense to compile these drivers into modules.
>
> Patch 1 applies on top of Rafael's pm-next branch, and then patch 2 and
> patch 3 needs merge of Lee's mfd/ib-mfd-iio-3.19 branch where the PMIC
> driver XPower AXP288 and iio driver axp288_adc is located.
>
>
> Aaron Lu (3):
>   ACPI / PMIC: support PMIC operation region for CrystalCove
>   ACPI / PMIC: support PMIC operation region for XPower AXP288
>   ACPI / PMIC: AXP288: support virtual GPIO in ACPI table

 OK

 I've pulled the Lee's 'mfd/ib-mfd-iio-3.19' branch and applied your updated
 three on top of that.  Please check the bleeding-edge branch of 
 linux-pm.git
 for the result.
>>>
>>> Thanks, and a fix patch is here:
>>>
>>> From: Aaron Lu 
>>> Date: Tue, 25 Nov 2014 14:35:38 +0800
>>> Subject: [PATCH] ACPI / PMIC: Make it possible to build PMIC driver as a 
>>> module
>>>
>>> This can solve a problem that when axp288_adc driver is built as a
>>> module and the PMIC driver is builtin, following error would ocur:
>>
>> I would prefer that to be sloved by requiring axp288_adc to be built in
>> if the PMIC stuff is selected.  Otherwise we may need to deal with some
>> nasty module load ordering dependencies.
> 
> Good point, and I saw you have solved this problem in the bleeding-edge
> branch, thanks!
> 
>>
>>>  drivers/built-in.o: In function `intel_xpower_pmic_get_raw_temp':
>>>  intel_pmic_xpower.c:(.text+0xdfaa7): undefined reference to 
>>> `iio_channel_get'
>>>  intel_pmic_xpower.c:(.text+0xdfb24): undefined reference to 
>>> `iio_read_channel_raw'
>>>  intel_pmic_xpower.c:(.text+0xdfb4e): undefined reference to 
>>> `iio_channel_release'
>>>
>>> Also, with the fix commit: 52870786ff5d ("ACPI: Use ACPI companion to
>>> match only the first physical device"), the MFD cell device will have
>>> its own platform modalias instead of its parent's ACPI modalias, this
>>> made it possible for the module to be autoloaded.
>>>
>>> Reported-by: kbuild test robot 
>>> Signed-off-by: Aaron Lu 
>>> ---
>>>  drivers/acpi/Kconfig  |  6 +++---
>>>  drivers/acpi/pmic/intel_pmic_crc.c| 12 +++-
>>>  drivers/acpi/pmic/intel_pmic_xpower.c | 12 +++-
>>>  3 files changed, 25 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>>> index 227f0692cbff..f9459ba4ce59 100644
>>> --- a/drivers/acpi/Kconfig
>>> +++ b/drivers/acpi/Kconfig
>>> @@ -394,7 +394,7 @@ config ACPI_EXTLOG
>>>   tracepoint which carries that information to userspace.
>>>  
>>>  menuconfig PMIC_OPREGION
>>> -   bool "PMIC (Power Management Integrated Circuit) operation region 
>>> 

linux-next: manual merge of the block tree with the ext4 tree

[Stephen Rothwell]

Hi Jens,

Today's linux-next merge of the block tree got a conflict in
fs/fs-writeback.c between commit 74ba19abbeae ("vfs: add support for a
lazytime mount option") from the ext4 tree and commit 9c6ac78eb352
("writeback: fix a subtle race condition in I_DIRTY clearing") from the
block tree.

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

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

diff --cc fs/fs-writeback.c
index cab2d6d74828,2d609a5fbfea..
--- a/fs/fs-writeback.c
+++ b/fs/fs-writeback.c
@@@ -480,12 -479,28 +480,28 @@@ __writeback_single_inode(struct inode *
 * write_inode()
 */
spin_lock(>i_lock);
-   /* Clear I_DIRTY_PAGES if we've written out all dirty pages */
-   if (!mapping_tagged(mapping, PAGECACHE_TAG_DIRTY))
-   inode->i_state &= ~I_DIRTY_PAGES;
+ 
dirty = inode->i_state & I_DIRTY;
-   inode->i_state &= ~(I_DIRTY_SYNC | I_DIRTY_DATASYNC | I_DIRTY_TIME);
 -  inode->i_state &= ~I_DIRTY;
++  inode->i_state &= ~(I_DIRTY | I_DIRTY_TIME);
+ 
+   /*
+* Paired with smp_mb() in __mark_inode_dirty().  This allows
+* __mark_inode_dirty() to test i_state without grabbing i_lock -
+* either they see the I_DIRTY bits cleared or we see the dirtied
+* inode.
+*
+* I_DIRTY_PAGES is always cleared together above even if @mapping
+* still has dirty pages.  The flag is reinstated after smp_mb() if
+* necessary.  This guarantees that either __mark_inode_dirty()
+* sees clear I_DIRTY_PAGES or we see PAGECACHE_TAG_DIRTY.
+*/
+   smp_mb();
+ 
+   if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY))
+   inode->i_state |= I_DIRTY_PAGES;
+ 
spin_unlock(>i_lock);
+ 
/* Don't write the inode if only I_DIRTY_PAGES was set */
if (dirty & (I_DIRTY_SYNC | I_DIRTY_DATASYNC)) {
int err = write_inode(inode, wbc);


pgpPApXpNBj2x.pgp
Description: OpenPGP digital signature

Re: frequent lockups in 3.18rc4

[Dave Jones]

On Tue, Nov 25, 2014 at 05:48:15PM -0800, Linus Torvalds wrote:

 > You have also marked 3.18-rc1 bad *twice*, along with the network
 > merge, and the tty merge. That's just odd. But it doesn't make the
 > bisect wrong, it just means that you fat-fingered thing and marked the
 > same thing bad a couple of times.
 > 
 > Nothing to worry about, unless it's a sign of early Parkinsons...

Intentional on my part, without realizing the first one was recorded.
First time, it printed the usual bisect text, but then complained my
tree was dirty (which it was). I unapplied the stuff I had, and did
the bisect command a 2nd time..

 > > Does that trace ring a bell of something else I could try on top of
 > > each bisection point ?
 > 
 > Hmm.
 > 
 > Smells somewhat like the "pipe/page fault oddness" bug you reported.
 > 
 > That one caused endless page faults on fault_in_pages_writeable()
 > because of a page table entry that the VM thought was present, but the
 > CPU thought was missing.
 > 
 > That caused the whole "pte_protnone()" thing, and trying to get rid of
 > the PTE_NUMA bit, but those patches have *not* been merged. And you
 > were ever able to reproduce it., so we left it as pending.

ah, yeah, now it comes back to me.

 > But if you actually really think that the bisect log you posted is
 > real and true and actually is the bug you're chasing, I have bad news
 > for you: do a "gitk --bisect", and you'll see that all the remaining
 > commits are just to staging drivers.
 > 
 > So that would either imply you have some staging driver (unlikely), or
 > more likely that 3.17 really already has the problem, it's just that
 > it needs some particular code alignment or phase of the moon or
 > something to trigger.

Maybe I'll try 3.17 + perf fix for an even longer runtime.
Like over thanksgiving or something.

If some of the bisection points so far had been 'good', I would
go back and re-check, but every step of the way I've been able
to reproduce it.

Dave

--
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/3] Support PMIC operation region for CrystalCove and XPower

[Aaron Lu]

On 11/26/2014 04:41 AM, Rafael J. Wysocki wrote:
> On Tuesday, November 25, 2014 07:52:31 PM Aaron Lu wrote:
>> On 11/25/2014 09:47 AM, Rafael J. Wysocki wrote:
>>> On Friday, November 21, 2014 03:11:48 PM Aaron Lu wrote:
 v3:
 Only some function/variable name changes, no functiona changes:
 - Replace the dptf/DPTF word originate from the BIOS ACPI table with more
   meaningful word thermal/THERMAL in all places;
 - Eliminate the soc part in various structure and function names to make
   them shorter:
   intel_soc_pmic_opregion -> intel_pmic_opregion
   intel_soc_pmic_pmop_handler -> intel_pmic_pmop_handler
   intel_soc_pmic_install_opregion_handler -> 
 intel_pmic_install_opregion_handler
   etc.


 v2:
 Place PMIC operation files under drivers/acpi/pmic instead of
 drivers/acpi/pmic_opregion as suggested by Rafael;
 Rename PMIC operation files to make them shorter as suggested by Rafael.

 v1:
 On Intel Baytrail-T and Baytrail-T-CR platforms, there are two customized
 ACPI operation regions defined for the Power Management Integrated Circuit
 device, one is for power resource handling and one is for thermal: sensor
 temperature reporting, trip point setting, etc. There are different PMIC
 chips used on those platforms and though each has the same two operation
 regions and functionality, their implementation is different so every PMIC
 will need a driver. But since their functionality is similar, some common
 code is abstracted into the intel_soc_pmic_opregion.c.

 The last version is posted here:
 https://lkml.org/lkml/2014/9/8/801

 Changes since then:
 1 Move to drivers/acpi as discussed on the above thread;
 2 Added support for XPower AXP288 PMIC operation region support;
 3 Since operation region handler can not be removed(at the moment at 
 least),
   use bool for the two operation region driver configs instead of tristate;
   Another reason to do this is that, with Mika's MFD ACPI support patch, 
 all
   those MFD cell devices created will have the same modalias as their 
 parent's
   so it doesn't make much sense to compile these drivers into modules.

 Patch 1 applies on top of Rafael's pm-next branch, and then patch 2 and
 patch 3 needs merge of Lee's mfd/ib-mfd-iio-3.19 branch where the PMIC
 driver XPower AXP288 and iio driver axp288_adc is located.


 Aaron Lu (3):
   ACPI / PMIC: support PMIC operation region for CrystalCove
   ACPI / PMIC: support PMIC operation region for XPower AXP288
   ACPI / PMIC: AXP288: support virtual GPIO in ACPI table
>>>
>>> OK
>>>
>>> I've pulled the Lee's 'mfd/ib-mfd-iio-3.19' branch and applied your updated
>>> three on top of that.  Please check the bleeding-edge branch of linux-pm.git
>>> for the result.
>>
>> Thanks, and a fix patch is here:
>>
>> From: Aaron Lu 
>> Date: Tue, 25 Nov 2014 14:35:38 +0800
>> Subject: [PATCH] ACPI / PMIC: Make it possible to build PMIC driver as a 
>> module
>>
>> This can solve a problem that when axp288_adc driver is built as a
>> module and the PMIC driver is builtin, following error would ocur:
> 
> I would prefer that to be sloved by requiring axp288_adc to be built in
> if the PMIC stuff is selected.  Otherwise we may need to deal with some
> nasty module load ordering dependencies.

Good point, and I saw you have solved this problem in the bleeding-edge
branch, thanks!

> 
>>  drivers/built-in.o: In function `intel_xpower_pmic_get_raw_temp':
>>  intel_pmic_xpower.c:(.text+0xdfaa7): undefined reference to 
>> `iio_channel_get'
>>  intel_pmic_xpower.c:(.text+0xdfb24): undefined reference to 
>> `iio_read_channel_raw'
>>  intel_pmic_xpower.c:(.text+0xdfb4e): undefined reference to 
>> `iio_channel_release'
>>
>> Also, with the fix commit: 52870786ff5d ("ACPI: Use ACPI companion to
>> match only the first physical device"), the MFD cell device will have
>> its own platform modalias instead of its parent's ACPI modalias, this
>> made it possible for the module to be autoloaded.
>>
>> Reported-by: kbuild test robot 
>> Signed-off-by: Aaron Lu 
>> ---
>>  drivers/acpi/Kconfig  |  6 +++---
>>  drivers/acpi/pmic/intel_pmic_crc.c| 12 +++-
>>  drivers/acpi/pmic/intel_pmic_xpower.c | 12 +++-
>>  3 files changed, 25 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>> index 227f0692cbff..f9459ba4ce59 100644
>> --- a/drivers/acpi/Kconfig
>> +++ b/drivers/acpi/Kconfig
>> @@ -394,7 +394,7 @@ config ACPI_EXTLOG
>>tracepoint which carries that information to userspace.
>>  
>>  menuconfig PMIC_OPREGION
>> -bool "PMIC (Power Management Integrated Circuit) operation region 
>> support"
>> +tristate "PMIC (Power Management Integrated Circuit) operation region 
>> support"
>>  help
>>Select this option to enable support for ACPI 

Re: [PATCH 1/4] GMAC: add driver for Rockchip RK3288 SoCs integrated GMAC

[Roger]

Hi! Giuseppe CAVALLARO

在 2014/11/25 18:05, Giuseppe CAVALLARO 写道:

Hello Roger

thx for these patches, my comments inline below

On 11/25/2014 10:07 AM, Roger Chen wrote:

This driver is based on stmmac driver.

Signed-off-by: Roger Chen 
---
  drivers/net/ethernet/stmicro/stmmac/Makefile   |2 +-
  drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c |  629 


  .../net/ethernet/stmicro/stmmac/stmmac_platform.c  |3 +
  .../net/ethernet/stmicro/stmmac/stmmac_platform.h  |1 +
  4 files changed, 634 insertions(+), 1 deletion(-)
  create mode 100644 drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c

diff --git a/drivers/net/ethernet/stmicro/stmmac/Makefile 
b/drivers/net/ethernet/stmicro/stmmac/Makefile

index ac4d562..73c2715 100644
--- a/drivers/net/ethernet/stmicro/stmmac/Makefile
+++ b/drivers/net/ethernet/stmicro/stmmac/Makefile
@@ -6,7 +6,7 @@ stmmac-objs:= stmmac_main.o stmmac_ethtool.o 
stmmac_mdio.o ring_mode.o\


  obj-$(CONFIG_STMMAC_PLATFORM) += stmmac-platform.o
  stmmac-platform-objs:= stmmac_platform.o dwmac-meson.o 
dwmac-sunxi.o\

-   dwmac-sti.o dwmac-socfpga.o
+   dwmac-sti.o dwmac-socfpga.o dwmac-rk.o

  obj-$(CONFIG_STMMAC_PCI) += stmmac-pci.o
  stmmac-pci-objs:= stmmac_pci.o
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c

new file mode 100644
index 000..9e50b37
--- /dev/null
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-rk.c
@@ -0,0 +1,629 @@
+/**
+ * dwmac-rk.c - Rockchip RK3288 DWMAC specific glue layer
+ *
+ * Copyright (C) 2014 Chen-Zhi (Roger Chen)
+ *
+ * Chen-Zhi (Roger Chen) 
+ *
+ * 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 
+#include 
+#include 
+#include 
+#include 
+
+struct rk_priv_data {
+struct platform_device *pdev;
+int phy_iface;
+bool power_ctrl_by_pmu;
+char pmu_regulator[32];
+int pmu_enable_level;
+
+int power_io;
+int power_io_level;
+int reset_io;
+int reset_io_level;
+int phyirq_io;
+int phyirq_io_level;
+
+bool clk_enabled;
+bool clock_input;
+
+struct clk *clk_mac;
+struct clk *clk_mac_pll;
+struct clk *gmac_clkin;
+struct clk *mac_clk_rx;
+struct clk *mac_clk_tx;
+struct clk *clk_mac_ref;
+struct clk *clk_mac_refout;
+struct clk *aclk_mac;
+struct clk *pclk_mac;
+
+int tx_delay;
+int rx_delay;
+
+struct regmap *grf;
+};
+
+#define RK3288_GRF_SOC_CON1 0x0248
+#define RK3288_GRF_SOC_CON3 0x0250
+#define RK3288_GRF_GPIO3D_E 0x01ec
+#define RK3288_GRF_GPIO4A_E 0x01f0
+#define RK3288_GRF_GPIO4B_E 0x01f4
+
+/*RK3288_GRF_SOC_CON1*/
+#define GMAC_PHY_INTF_SEL_RGMII ((0x01C0 << 16) | (0x0040))
+#define GMAC_PHY_INTF_SEL_RMII  ((0x01C0 << 16) | (0x0100))
+#define GMAC_FLOW_CTRL  ((0x0200 << 16) | (0x0200))
+#define GMAC_FLOW_CTRL_CLR  ((0x0200 << 16) | (0x))
+#define GMAC_SPEED_10M  ((0x0400 << 16) | (0x))
+#define GMAC_SPEED_100M ((0x0400 << 16) | (0x0400))
+#define GMAC_RMII_CLK_25M   ((0x0800 << 16) | (0x0800))
+#define GMAC_RMII_CLK_2_5M  ((0x0800 << 16) | (0x))
+#define GMAC_CLK_125M   ((0x3000 << 16) | (0x))
+#define GMAC_CLK_25M((0x3000 << 16) | (0x3000))
+#define GMAC_CLK_2_5M   ((0x3000 << 16) | (0x2000))
+#define GMAC_RMII_MODE  ((0x4000 << 16) | (0x4000))
+#define GMAC_RMII_MODE_CLR  ((0x4000 << 16) | (0x))
+
+/*RK3288_GRF_SOC_CON3*/
+#define GMAC_TXCLK_DLY_ENABLE   ((0x4000 << 16) | (0x4000))
+#define GMAC_TXCLK_DLY_DISABLE  ((0x4000 << 16) | (0x))
+#define GMAC_RXCLK_DLY_ENABLE   ((0x8000 << 16) | (0x8000))
+#define GMAC_RXCLK_DLY_DISABLE  ((0x8000 << 16) | (0x))
+#define GMAC_CLK_RX_DL_CFG(val) ((0x3F80 << 16) | (val<<7))
+#define GMAC_CLK_TX_DL_CFG(val) ((0x007F << 16) | (val))


why do not use BIT and BIT_MASK where possible?


+static void set_to_rgmii(struct rk_priv_data *bsp_priv,
+ int tx_delay, int rx_delay)
+{
+if (IS_ERR(bsp_priv->grf)) {
+pr_err("%s: Missing rockchip,grf property\n", __func__);
+return;
+}
+
+regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON1,
+ GMAC_PHY_INTF_SEL_RGMII);
+regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON1,
+ GMAC_RMII_MODE_CLR);


maybe you could perform just one write unless there is some HW
constraint.


+regmap_write(bsp_priv->grf, RK3288_GRF_SOC_CON3,
+ 

Re: [PATCH v12 0/11] dw-hdmi: convert imx hdmi to bridge/dw_hdmi

[Andy Yan]

Hi Fabio:

On 2014年11月26日 10:14, Fabio Estevam wrote:

Hi Andy,

On Mon, Nov 17, 2014 at 8:53 AM, Andy Yan  wrote:


Andy Yan (11):
   staging: imx-drm: imx-hdmi: make checkpatch happy
   staging: imx-drm: imx-hdmi: return defer if can't get ddc i2c adapter
   staging: imx-drm: imx-hdmi: convert imx-hdmi to drm_bridge mode
   staging: imx-drm: imx-hdmi: move imx-hdmi to bridge/dw_hdmi

imx-drm has moved out of staging.

Please see Phillip's patch:
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next=6556f7f82b9c401950d703072c0d8137b6f9f516

So you need to re-submit your series against drm-next.


  Thanks very much for you pointing out this, I will re-submit my 
patch  set against drm-next  soon.



--
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] xen-netfront: Remove BUGs on paged skb data which crosses a page boundary

[Seth Forshee]

These BUGs can be erroneously triggered by frags which refer to
tail pages within a compound page. The data in these pages may
overrun the hardware page while still being contained within the
compound page, but since compound_order() evaluates to 0 for tail
pages the assertion fails. The code already iterates through
subsequent pages correctly in this scenario, so the BUGs are
unnecessary and can be removed.

Fixes: f36c374782e4 ("xen/netfront: handle compound page fragments on transmit")
Cc:  # 3.7+
Signed-off-by: Seth Forshee 
---
 drivers/net/xen-netfront.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/net/xen-netfront.c b/drivers/net/xen-netfront.c
index cca871346a0f..ece8d1804d13 100644
--- a/drivers/net/xen-netfront.c
+++ b/drivers/net/xen-netfront.c
@@ -496,9 +496,6 @@ static void xennet_make_frags(struct sk_buff *skb, struct 
netfront_queue *queue,
len = skb_frag_size(frag);
offset = frag->page_offset;
 
-   /* Data must not cross a page boundary. */
-   BUG_ON(len + offset > PAGE_SIZE<> PAGE_SHIFT;
offset &= ~PAGE_MASK;
@@ -506,8 +503,6 @@ static void xennet_make_frags(struct sk_buff *skb, struct 
netfront_queue *queue,
while (len > 0) {
unsigned long bytes;
 
-   BUG_ON(offset >= PAGE_SIZE);
-
bytes = PAGE_SIZE - offset;
if (bytes > len)
bytes = len;
-- 
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/

[Patch Part3 v4] x86, PCI, MSI: Use hierarchy irqdomain to manage MSI interrupts

[Jiang Liu]

Enhance MSI code to support hierarchy irqdomain, it helps to make
the architecture more clear.

Signed-off-by: Jiang Liu 
---
Hi Thomas,
Sorry, my branch hasn't been updated to the latest tip/x86/apic
branch. With this patch rebased, all following patches should apply
cleanly without conflicts.
Regards!
Gerry
---
 arch/x86/Kconfig |1 +
 arch/x86/include/asm/hw_irq.h|9 ++-
 arch/x86/include/asm/irq_remapping.h |6 +-
 arch/x86/include/asm/msi.h   |7 ++
 arch/x86/kernel/apic/msi.c   |  141 ++
 arch/x86/kernel/apic/vector.c|2 +
 drivers/iommu/irq_remapping.c|1 -
 7 files changed, 94 insertions(+), 73 deletions(-)
 create mode 100644 arch/x86/include/asm/msi.h

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 14385ebfd560..e05be74d713d 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -883,6 +883,7 @@ config X86_LOCAL_APIC
depends on X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_APIC || 
PCI_MSI
select GENERIC_IRQ_LEGACY_ALLOC_HWIRQ
select IRQ_DOMAIN_HIERARCHY
+   select PCI_MSI_IRQ_DOMAIN if PCI_MSI
 
 config X86_IO_APIC
def_bool X86_64 || SMP || X86_32_NON_STANDARD || X86_UP_IOAPIC
diff --git a/arch/x86/include/asm/hw_irq.h b/arch/x86/include/asm/hw_irq.h
index bd7881c5a57a..270c432971f8 100644
--- a/arch/x86/include/asm/hw_irq.h
+++ b/arch/x86/include/asm/hw_irq.h
@@ -110,9 +110,10 @@ struct irq_2_irte {
 };
 #endif /* CONFIG_IRQ_REMAP */
 
+struct irq_domain;
+
 #ifdef CONFIG_X86_LOCAL_APIC
 struct irq_data;
-struct irq_domain;
 struct pci_dev;
 struct msi_desc;
 
@@ -214,6 +215,12 @@ static inline void lock_vector_lock(void) {}
 static inline void unlock_vector_lock(void) {}
 #endif /* CONFIG_X86_LOCAL_APIC */
 
+#ifdef CONFIG_PCI_MSI
+extern void arch_init_msi_domain(struct irq_domain *domain);
+#else
+static inline void arch_init_msi_domain(struct irq_domain *domain) { }
+#endif
+
 /* Statistics */
 extern atomic_t irq_err_count;
 extern atomic_t irq_mis_count;
diff --git a/arch/x86/include/asm/irq_remapping.h 
b/arch/x86/include/asm/irq_remapping.h
index 3421f10456d8..3b11f5a3e092 100644
--- a/arch/x86/include/asm/irq_remapping.h
+++ b/arch/x86/include/asm/irq_remapping.h
@@ -68,11 +68,7 @@ irq_remapping_get_irq_domain(struct irq_alloc_info *info);
 extern void irq_remapping_print_chip(struct irq_data *data, struct seq_file 
*p);
 
 /* Create PCI MSI/MSIx irqdomain, use @parent as the parent irqdomain. */
-static inline struct irq_domain *
-arch_create_msi_irq_domain(struct irq_domain *parent)
-{
-   return NULL;
-}
+extern struct irq_domain *arch_create_msi_irq_domain(struct irq_domain 
*parent);
 
 /* Get parent irqdomain for interrupt remapping irqdomain */
 static inline struct irq_domain *arch_get_ir_parent_domain(void)
diff --git a/arch/x86/include/asm/msi.h b/arch/x86/include/asm/msi.h
new file mode 100644
index ..93724cc62177
--- /dev/null
+++ b/arch/x86/include/asm/msi.h
@@ -0,0 +1,7 @@
+#ifndef _ASM_X86_MSI_H
+#define _ASM_X86_MSI_H
+#include 
+
+typedef struct irq_alloc_info msi_alloc_info_t;
+
+#endif /* _ASM_X86_MSI_H */
diff --git a/arch/x86/kernel/apic/msi.c b/arch/x86/kernel/apic/msi.c
index 10d9ae8f2166..e82ab7973477 100644
--- a/arch/x86/kernel/apic/msi.c
+++ b/arch/x86/kernel/apic/msi.c
@@ -3,6 +3,8 @@
  *
  * Copyright (C) 1997, 1998, 1999, 2000, 2009 Ingo Molnar, Hajnalka Szabo
  * Moved from arch/x86/kernel/apic/io_apic.c.
+ * Jiang Liu 
+ * Convert to hierarchy irqdomain
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -21,6 +23,8 @@
 #include 
 #include 
 
+static struct irq_domain *msi_default_domain;
+
 void native_compose_msi_msg(struct pci_dev *pdev,
unsigned int irq, unsigned int dest,
struct msi_msg *msg, u8 hpet_id)
@@ -114,102 +118,107 @@ static int msi_compose_msg(struct pci_dev *pdev, 
unsigned int irq,
return 0;
 }
 
-static int
-msi_set_affinity(struct irq_data *data, const struct cpumask *mask, bool force)
-{
-   struct irq_cfg *cfg = irqd_cfg(data);
-   struct msi_msg msg;
-   unsigned int dest;
-   int ret;
-
-   ret = apic_set_affinity(data, mask, );
-   if (ret)
-   return ret;
-
-   __get_cached_msi_msg(data->msi_desc, );
-
-   msg.data &= ~MSI_DATA_VECTOR_MASK;
-   msg.data |= MSI_DATA_VECTOR(cfg->vector);
-   msg.address_lo &= ~MSI_ADDR_DEST_ID_MASK;
-   msg.address_lo |= MSI_ADDR_DEST_ID(dest);
-
-   __pci_write_msi_msg(data->msi_desc, );
-
-   return IRQ_SET_MASK_OK_NOCOPY;
-}
-
 /*
  * IRQ Chip for MSI PCI/PCI-X/PCI-Express Devices,
  * which implement the MSI or MSI-X Capability Structure.
  */
-static struct irq_chip msi_chip = {
+static struct irq_chip pci_msi_controller = {
.name   = "PCI-MSI",

Re: [PATCH v12 0/11] dw-hdmi: convert imx hdmi to bridge/dw_hdmi

[Fabio Estevam]

Hi Andy,

On Mon, Nov 17, 2014 at 8:53 AM, Andy Yan  wrote:

> Andy Yan (11):
>   staging: imx-drm: imx-hdmi: make checkpatch happy
>   staging: imx-drm: imx-hdmi: return defer if can't get ddc i2c adapter
>   staging: imx-drm: imx-hdmi: convert imx-hdmi to drm_bridge mode
>   staging: imx-drm: imx-hdmi: move imx-hdmi to bridge/dw_hdmi

imx-drm has moved out of staging.

Please see Phillip's patch:
http://cgit.freedesktop.org/~airlied/linux/commit/?h=drm-next=6556f7f82b9c401950d703072c0d8137b6f9f516

So you need to re-submit your series against drm-next.
--
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/

LED-LENSER flashlight

[LED-LENSER flashlight and headlamp Wholesale]

Many thanks for your valuable time to read my letter.

This is Hellen from JRS Technology Co.,Ltd.
We do LED LENSER flashlight and headlamp Wholesale business. Many models are 
available with competitive price.
For more information, please contact us in any time
it will be our honor to serve you well and be your supplier
Waitting for your reply.

Thanks and best regards

Hellen

JRS Technology Co.,Ltd

E-mail : sa...@jrs-tech.net
Msn: techj...@msn.cn
Skype:   techjrsa
http://www.jrs-tech.net

we would be grateful if you will be our led lenser catalogue reserved for your 
supervisor.

[PATCH] f2fs: fix to recover converted inline_data

[Jaegeuk Kim]

If an inode has converted inline_data which was written to the disk, we should
set its inode flag for further fsync so that this inline_data can be recovered
from sudden power off.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/inline.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
index e27f290..f2d3c58 100644
--- a/fs/f2fs/inline.c
+++ b/fs/f2fs/inline.c
@@ -122,6 +122,9 @@ no_update:
if (dirty)
inode_dec_dirty_pages(dn->inode);
 
+   /* this converted inline_data should be recovered. */
+   set_inode_flag(F2FS_I(dn->inode), FI_APPEND_WRITE);
+
/* clear inline data and flag after data writeback */
truncate_inline_data(dn->inode_page, 0);
 clear_out:
-- 
2.1.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 1/2] media: v4l2-image-sizes.h: add SVGA, XGA and UXGA size definitions

[Josh Wu]

Hi, Sylwester and Mauro

On 11/25/2014 6:34 PM, Sylwester Nawrocki wrote:

Hi Josh,

On 25/11/14 09:54, Josh Wu wrote:

Add SVGA, UXGA and XGA size definitions to v4l2-image-sizes.h.
The definitions are sorted by alphabet order.

Signed-off-by: Josh Wu 
---
  include/media/v4l2-image-sizes.h | 9 +
  1 file changed, 9 insertions(+)

diff --git a/include/media/v4l2-image-sizes.h b/include/media/v4l2-image-sizes.h
index 10daf92..c70c917 100644
--- a/include/media/v4l2-image-sizes.h
+++ b/include/media/v4l2-image-sizes.h
@@ -25,10 +25,19 @@
  #define QVGA_WIDTH320
  #define QVGA_HEIGHT   240
  
+#define SVGA_WIDTH	800

+#define SVGA_HEIGHT680

I think this should be 600. With that fixed, for both patches:


Yes, right, It should be 600. It's my bad with such terrible typo here.

Hi, Mauro

I saw this patch is already merged in the media_tree. But not changing 
the SVGA_HEIGHT to 600.


Would it possible for you to re-modify this commit in the media_tree to 
fix the SVGA_HEIGHT as 600?

Or need I resend the patch or a fix for this?

Sorry for such an inconvinencie.



Acked-by: Sylwester Nawrocki 

Thanks a again.

Best Regards,
Josh Wu



  #define SXGA_WIDTH1280
  #define SXGA_HEIGHT   1024
  
  #define VGA_WIDTH	640

  #define VGA_HEIGHT480
  
+#define UXGA_WIDTH	1600

+#define UXGA_HEIGHT1200
+
+#define XGA_WIDTH  1024
+#define XGA_HEIGHT 768
+
  #endif /* _IMAGE_SIZES_H */

--
Regards,
Sylwester


--
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 v2] f2fs: make clean the page before writing

[Jaegeuk Kim]

Change log from v1:
 o fix to handle # of dirty pages

If a page is set to be written to the disk, we can make clean the page.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/inline.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/fs/f2fs/inline.c b/fs/f2fs/inline.c
index 914b6d3..e27f290 100644
--- a/fs/f2fs/inline.c
+++ b/fs/f2fs/inline.c
@@ -84,7 +84,7 @@ int f2fs_convert_inline_page(struct dnode_of_data *dn, struct 
page *page)
.type = DATA,
.rw = WRITE_SYNC | REQ_PRIO,
};
-   int err;
+   int dirty, err;
 
f2fs_bug_on(F2FS_I_SB(dn->inode), page->index);
 
@@ -110,12 +110,17 @@ int f2fs_convert_inline_page(struct dnode_of_data *dn, 
struct page *page)
kunmap_atomic(dst_addr);
SetPageUptodate(page);
 no_update:
+   /* clear dirty state */
+   dirty = clear_page_dirty_for_io(page);
+
/* write data page to try to make data consistent */
set_page_writeback(page);
 
write_data_page(page, dn, _blk_addr, );
update_extent_cache(new_blk_addr, dn);
f2fs_wait_on_page_writeback(page, DATA);
+   if (dirty)
+   inode_dec_dirty_pages(dn->inode);
 
/* clear inline data and flag after data writeback */
truncate_inline_data(dn->inode_page, 0);
-- 
2.1.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] staging: lustre: fix pointer declarations

[Joe Perches]

On Tue, 2014-11-25 at 21:44 +0100, Zahari Doychev wrote:
> This patch fixes pointer declarations from void * to void __user * in order
> to remove some sparse warnings.

This patch does more than that.

Please make sure to describe all of the changes
in a patch in the commit message.

> diff --git a/drivers/staging/lustre/include/linux/lnet/lib-lnet.h 
> b/drivers/staging/lustre/include/linux/lnet/lib-lnet.h
[]
> @@ -780,22 +780,22 @@ void lnet_copy_kiov2kiov(unsigned int ndkiov, 
> lnet_kiov_t *dkiov,
> unsigned int soffset, unsigned int nob);
>  
>  static inline void
> -lnet_copy_iov2flat(int dlen, void *dest, unsigned int doffset,
> +lnet_copy_iov2flat(int dlen, void __user *dest, unsigned int doffset,
>  unsigned int nsiov, struct iovec *siov, unsigned int soffset,
>  unsigned int nob)
>  {
> - struct iovec diov = {/*.iov_base = */ dest, /*.iov_len = */ dlen};
> + struct iovec diov = {.iov_base = dest, .iov_len = dlen};

Now using named initializers too.


--
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/2] MAINTAINERS: ARM Versatile Express platform

[Joe Perches]

On Tue, 2014-11-25 at 17:54 -0800, Mike Turquette wrote:
> Quoting Pawel Moll (2014-11-25 10:17:35)
> > This patch adds a separate section for the ARM
> > Versatile Express platform maintainers, listing
> > all different bits and bobs used by it.
[]
> > diff --git a/MAINTAINERS b/MAINTAINERS
[]
> > +ARM/VERSATILE EXPRESS PLATFORM
[]
> > +F: arch/arm/boot/dts/vexpress-*
> > +F: arch/arm/mach-vexpress/*
> > +F: drivers/bus/vexpress-config.c
> > +F: drivers/clk/versatile/clk-vexpress-osc.c
> > +F: drivers/clocksource/versatile.c
> > +F: drivers/cpufreq/vexpress-spc-cpufreq.c
> > +F: drivers/hwmon/vexpress.c
> > +F: drivers/mfd/vexpress-sysreg.c
> > +F: drivers/misc/vexpress-vexpress-syscfg.c
> > +F: drivers/power/reset/vexpress-poweroff.c
> > +F: drivers/regulator/vexpress.c
> > +F: include/linux/vexpress.h
> >

maybe
F:  arch/arm/boot/dts/vexpress*
F:  arch/arm/mach-vexpress/
F:  */*/vexpress*
F:  */*/*/*vexpress*
F:  drivers/clocksource/versatile.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/